NICE TO HAVE: users can edit scenario 'user values' for scenarios they own

Now that we are using regional scenario's to support clients from Gelderland, Groningen, Ameland and (hopefully soon) Goeree-Overflakkee, we are coming upon an unfortunate shortcoming of the way we store scenario settings. Scenario files are completely off-limits to our clients. It would be ideal if 'ETM literate' users could edit some of these themselves.
Since these regional scenario's often involve quite a bit of scaling and tweaking before 'present' energy use accurately reproduce statistics, these scenario files contain a long 'pre-amble' of input statements. Since only Quintel staff can access these scenario files, only they can perform or amend such 'tweaking'. Several clients have already inquired if they can have access. For transparency's sake and because we claim to be 'completely' open source, I believe it is desirable to have the ability to give users access to scenario files they own.
I suggest only giving access to scenarios and scenario-scaling tables and only particular fields or columns in those tables at that. I realize this is probably a nightmare to set up and to make sure stuff doesn't break, but I would appreciate it if we gave this issue some thought.
notifying @ChaelKruip @jorisberkhout @antw @grdw @RobTerwel

I think it would be a bad idea or even impossible to given user (limited) access to the database. Correct me if I'm wrong here @antw.
One possible route to a solution would be to make it possible to store scaled scenario's as presets (possibly hidden from the menu). The '.ad'-file containing the scenario would then be available on Github and can be edited by anyone with a Github account...

To clarify: we only need the user to edit the 'user_values' field of his own scenarios and perhaps the description field. No help no additional input statements. Just a possibility to change the numbers we put in there using our custom analysis for a scaled scenario project.
This should be a plain and simple interface solution. I understand etmodel will have to talk to etengine and this requires API stuff. @Dennisschoenmakers please elaborate

There are some tricky technical issues with this, as

the user_values exist on et-engine, and cannot be set by its entirety through the API (yet),
access and editing through etengine would be cumbersome, since we lack user authority levels there to enable only update this field without e.g. being able to import etsource commits. 😅

I suggest we check out updating the user_values over the API first. Will update you guys!

Updating through API seems the best idea to me. This will be a lot more intuitive to users as well.

I'm not entirely sure I understand, so please correct me if I'm wrong. The problem is:

Scaled-down regional scenarios need the present scenario to be tweaked to suit the region,
Sliders to alter the present scenario do not exist in the ETM.

If so, can't just add those sliders to ETModel, with a suitable warning about it being an experimental feature, for advanced users only?

If so, can't just add those sliders to ETModel, with a suitable warning about it being an experimental feature, for advanced users only?

We could also do that. These inputs however are a bit unusual to say the least, and of course we are lacking labels and any background information.
Perhaps a special page with a form where you can enter values of these 'special' inputs would be an alternative to editing the whole user_values in a text field?

Perhaps a special page with a form where you can enter values of these 'special' inputs would be an alternative to editing the whole user_values in a text field?

I like this option because it will limit the number of people that end up on this page accidentally.
Something along the lines of this page but with editable entries and specific for a scenario would do the trick right?

Something along the lines of this page but with editable entries and specific for a scenario would do the trick right?

Yes, but I think this page has to be incorporated in etmodel, not etengine.

Does something prevent these inputs being represented as sliders? Showing them a sliders has many advantages:

The rest of the ETM uses them, so users will be familiar with how they work.
(Nearly) instant feedback to changes.
Little to no extra code. (!!!)

Showing a list of inputs with raw keys and simple text fields is not a very user-friendly experience.
To prevent accidental modification of the "present day" sliders, we could require the user to read a message – and click a button.

(click the button, we'll show the sliders, and remember not to show the message again).

I like that @antw. Do you envision a general setting like 'adjust present values' or something similar?

Do you envision a general setting like 'adjust present values' or something similar?

It depends what you mean by that. If you mean the user ticks a box and future sliders magically become present sliders, then no. 😆
If you mean that the present sliders are hidden by default – and shown once the user enables them – then sure.

We'd add a new tab to the sidebar for the "Present day scenario", and new sliders/inputs for things that the user is allowed to edit. Depending on how many sliders we need to add, perhaps it will have to be split into multiple tabs.

I'm not sure about the styling, and perhaps even that tab can be hidden until the visitor enables a setting from the drop-down box?
Alternatively, they could be placed with the future sliders like so:

When the user first tries to view the present sliders, show them the caution message.
Once they click "Continue", show the sliders.

@antw

I'm not entirely sure I understand, so please correct me if I'm wrong. The problem is:

Scaled-down regional scenarios need the present scenario to be tweaked to suit the region,
Sliders to alter the present scenario do not exist in the ETM

Well, quite a few of these input statements concern both statements. The reason is that when you scale present demand, you also want to scale future demand, so a graph in question appears flat when all (future) sliders are set to 0.
Part of the scenario file for GEA looks like this:
households_solar_pv_solar_radiation_market_penetration_both: 1.8703215012591
households_solar_pv_solar_radiation_market_penetration: 9.6

The first statement is used to get to the correct numbers for this area. The second is a future scenario specific statement. This is also used for useful_demand statements that first scale this to the right value using households_useful_demand_heat_per_person_both and then set a future slider to a particular position, because we want to communicate to GEA people that we anticipate a fall or rise in future useful demand.
By now I'm sure you have gotten my point. The elegant solution you are proposing would work if w ealso included both sliders. These don't work in all cases, though (technology shares is one), which is very confusing to users. That in turn would require us to do a lot of explaining.
The solution I am looking for only allows users to modify the existing input statements (present, future and both) in a scenario file, or use other existing ones not found in the scenario file IF they have the technical nous. They can copy these input statements from the analysis we have already shared with them. This analysis was made by @RobTerwel and shows exactly how we took energy numbers and arrived at input statements for the scenario. Should they change the energy numbers, the input statements will change and need to be copied into the relevant scenario files.
This also illustrates the need / desirability to be able to edit the scenario description field, where a user can document his actions.

p.s. The reason we use these both statements and not just the present and future statements is that this makes it (almost) possible to do all the 'tweaking' in something we might call a 'preamble' to the scenario file. All the stuff a user adds to such a scenario by saving a new version gets appended to this preamble.
This does not quite work, as the technology share sliders cannot be set using both sliders, so those `future

Thanks for the explanation @AlexanderWirtz. I agree that including the present/both sliders inline with future sliders is perhaps not the best solution.
However, I still think editing preset files is really user-unfriendly. Revealing internal details (such as input keys) could give us all sorts of headaches down the line. For example, maybe a visitor gets used to copy/pasting households_solar_pv_solar_radiation_market_penetration_both into a "preamble" field, only for something to break if we decide to rename that input.
This feature will be much more future-proof – and user friendly – if we can find a way to use sliders to take input from the visitor. Maybe we can instead put them all into a "Scenario Setup" or "Preamble" section?

In here we'd show the preamble inputs as sliders which the visitor could edit. Maybe we could even include a drop-down selection of other preamble sliders which they can add to their scenario? When they've made their changes, the scenario can be saved like any other.

Thanks @antw and @AlexanderWirtz for sharing your thoughts.
I think what adds to the complexity, is that users do not even wish to set slider values. It rather is a poor man's solution.
Let me show this by the example provided above:
households_solar_pv_solar_radiation_market_penetration_both: 1.8703215012591
households_solar_pv_solar_radiation_market_penetration: 9.6

The first line is a result of an spreadsheet calculation, where the market penetration for solar pv in the present graph for this local scenario is different, e.g. 12.5% in stead of the 'average' 10%. As the scenario covers 12 years (2025 - 2013), the 'yearly growth'* is calculated as 1.87% per annum. This is calculated in an Excel sheet.
It would be a bit weird if we would enable users to input this rather far fetched number, the 'yearly growth' number in a very convenient way, while really, they just want to adjust a present number.

= it is a bit counterintuitive that the end year is used to for yearly sliders for the present_graph, and this leads to all kinds of unwanted effects.

What I am asking myself: is there not a more direct way possible to get what we want? To enable users/ourselves to adjust the present dataset of scaled scenario?

However, I still think editing preset files is really user-unfriendly. Revealing internal details (such as input keys) could give us all sorts of headaches down the line.

Good points, @antw. Note that I am not requesting the possibility to edit preset files, but the possibility to edit the user_values fields in the scenarios tables in the etengine database. Equally ugly and error-prone, but the latter cannot be done through GitHub.

I think what adds to the complexity, is that users do not even wish to set slider values. It rather is a poor man's solution.

Spot on. The reason we have this preamble is to really tweak numbers to fit the know energy uses in the various sectors. The example @dennisschoenmakers mentions does not concern a 'per annum' slider, but his point is still valid.
I know we want something prettier and easier than editing these user_values fields. My problem right now is that clients are a little grumpy about the fact that they cannot themselves influence the input data for the regional models.

What I am asking myself: is there not a more direct way possible to get what we want? To enable users/ourselves to adjust the present dataset of scaled scenario?

@dennisschoenmakers there might well be, but we do not have budget to come up with one and implement it, IMO.

What I am asking myself: is there not a more direct way possible to get what we want? To enable users/ourselves to adjust the present dataset of scaled scenario?

A bit out-of-the-box perhaps but why not let the user set the demands directly on the nodes (or edges) of the present graph and area variables? Essentially, changing the present graph is equivalent to making a new dataset, so why not do that?
Advantages:

direct: what you see is what you get
already possible through the data-analysis. This could be very similar to making a dataset for a new country which has the added value of the present scenario being thoroughly documented and version controlled

Disadvantages:

it is quite a bit of work and requires effort from the client
We have to investigate how the 'scaling'-aspect of the scenario can be dealt with when making a new dataset

My worry with the more indirect solutions proposed above is that we will have to assist the client anyways because it can be counter-intuitive to set the present graph with sliders (what is the reference?!). The _present and _both input statements where a hacky solution in the first place and we will make it increasingly more difficult to replace them with a more solid and future-proof solution if we facilitate outsiders to use them.

@dennisschoenmakers there might well be, but we do not have budget to come up with one and implement it, IMO.

If the ETM will be used for local situations more often in the future (which I hope and anticipate), the need for a better solution is worth the headache and investment now. If we don't have budget, we should not do something quick and dirty that will bite us in the behind later IMO.

A bit out-of-the-box perhaps but why not let the user set the demands directly on the nodes (or edges) of the present graph and area variables? Essentially, changing the present graph is equivalent to making a new dataset, so why not do that?

This is very complicated for a region, because in our experience the data are essentially lacking, not to mention the know-how. It is also surprisingly time consuming. @jorisberkhout had a look at this before and warned me it was not a great idea.
The scaling method is nice, because it allows us or other users to circumvent all kinds of questions about who is responsible for what energy use in what part of the energy system. Any additional research to tweak the numbers improves such a scaled scenario.

We have to investigate how the 'scaling'-aspect of the scenario can be dealt with when making a new dataset

This is indeed very interesting. We could scale the energy balance and autoproducer table, production timecurves etc and then perform the analysis steps. If we go to that level of detail though, we might as well think about changing the EB altogether and nixing the metals sector for a region that has no metallurgic industry etc. A bit of a can of worms.

My worry with the more indirect solutions proposed above is that we will have to assist the client anyways because it can be counter-intuitive to set the present graph with sliders (what is the reference?!).

I understand. This is why for know i want to tell the client he can use our regional analysis to recalculate the numbers and input statements to be put into user_values, but any assistance from us would have to be paid for. Managing expectations can go some way to cover this. It is of course bound to go wrong at some point too.

If we don't have budget, we should not do something quick and dirty that will bite us in the behind later IMO.

I disagree. This is a direct wish from a client who has just agreed to work with us for the coming years. If we manage expectations by saying that for no budget we can give them something that is technically complicated and likely to break, I think this is worth doing in it's most simplistic form. Also because I do not see how it will 'bite us in the ass' so badly. Scenario's can break, sure, but that is already the case for scenario's over a year old.
We can make it quite clear that if they want a more user friendly option, we need to find someone to pay for it. It may even be more user friendly for us, as it may make it easier and less risky to edit existing scenarios.

I would like to press for a conclusion as the GEA project is drawing to a close (for now) and I want to know what to tell the client about this. Can we give clients access to their own scenario files?

Weighing all ins and outs, I suggest we create a simple page where people can edit theor user_values and description, comparable to the compare/merge view. We would need user authorization with this, because we wouldn't allow anybody to edit all scenarios. :smirk:

... or we could only allow the user to only create a 'new' scenario with this view, then we wouldn't have the authorization issue.

... or we could only allow the user to only create a 'new' scenario with this view, then we wouldn't have the authorization issue.

Sounds like a safe solution to me.

We would need user authorization with this, because we wouldn't allow anybody to edit all scenarios.

Any person can already edit any scenario by PUTing to ETEngine's /api/v3/scenarios/:id.
I agree that ETModel should create a new scenario when a user makes direct edits to user_values.

Any person can already edit any scenario by PUTing to ETEngine's /api/v3/scenarios/:id.
reac

I know. :grin:
I agree that ETModel should create a new scenario when a user makes direct edits to user_values.
:+1: Then I think we have come to a conclusion. 🎉


Ctrl+F5 does not start without debugging

VSCode Version: Code 1.18.0 (dcee2202709a4f223185514b9275aa4229841aa7, 2017-11-08T21:22:49.932Z)
OS Version: Windows_NT x64 10.0.16299
Extensions:

Extension
Author (truncated)
Version

python
ms-
0.8.0

cpptools
ms-
0.14.2

Steps to Reproduce:

Install Microsoft Python extension
Run any .py program once using Ctrl+F5
"Debugging" cannot be stopped, bottom status bar remains active
Ctrl+F5 becomes useless

Reproduces without extensions: Yes/No

This issue was moved to Microsoft/vscode-python#235

Please file python issues against Python repo.


JSON output on ruff check --fix does not show any thing related to fixes

ruff 0.4.3 (1e91a0991 2024-05-03)
I am trying to parse the output of ruff check --fix --fix-only --show-fixes to validate what has been changed. When using output = text or full, I get:
- my_file.py:
    1 × E703 (useless-semicolon)

That is byproduct of the "--show-fixes", but I think this format is not very stable as it has changed before and also it has a non ascii character that prints weird in some places.
I would expect to get something meaningful out of json output when using show-fixes, but the process output is always empty (not even the [] from checks since I use --fix-only)
I have tried all commands with --isolated and it behaves the same.

You can extract the fix from the JSON output directly without providing any other flags:
$ ruff check --output-format=json src/lsp.py
[
  {
    "cell": null,
    "code": "F401",
    "end_location": {
      "column": 25,
      "row": 3
    },
    "filename": "/Users/dhruv/playground/ruff/src/lsp.py",
    "fix": {
      "applicability": "safe",
      "edits": [
        {
          "content": "",
          "end_location": {
            "column": 1,
            "row": 4
          },
          "location": {
            "column": 1,
            "row": 3
          }
        }
      ],
      "message": "Remove unused import: `pathlib.Path`"
    },
    "location": {
      "column": 21,
      "row": 3
    },
    "message": "`pathlib.Path` imported but unused",
    "noqa_row": 3,
    "url": "https://docs.astral.sh/ruff/rules/unused-import"
  },
  {
    "cell": null,
    "code": "T201",
    "end_location": {
      "column": 6,
      "row": 5
    },
    "filename": "/Users/dhruv/playground/ruff/src/lsp.py",
    "fix": {
      "applicability": "unsafe",
      "edits": [
        {
          "content": "",
          "end_location": {
            "column": 1,
            "row": 12
          },
          "location": {
            "column": 1,
            "row": 5
          }
        }
      ],
      "message": "Remove `print`"
    },
    "location": {
      "column": 1,
      "row": 5
    },
    "message": "`print` found",
    "noqa_row": 5,
    "url": "https://docs.astral.sh/ruff/rules/print"
  }
]

Does this help?

Hi @dhruvmanila, thank you for the reply.
Then I have to run the code twice, one to find all issues in files that are fixable and a second time to actually fix them.
I believe this feature should already work but some combination of --fix, --show-fixes and --fix-only prevents anything from being output.

Do you mean that you want the JSON output and that Ruff applies the fix?

Yes, correct.
If the information is available in one output type I think it makes sense it is available in all of them.
Otherwise --show-fixes is useless with json output

Thanks for confirming!
I think this is an ideal behavior although it's not enforced on the CLI. This is because --output-format flag shouldn't affect the format of --show-* flags which themselves have their own output format (e.g., --show-files, --show-settings).
Can you provide the use-case for this behavior? What kind of information are you looking for with the applied fixes?

This is because --output-format flag shouldn't affect the format of --show-* flags which themselves have their own output format

Well, it does affect right now because JSON output prevents --show-fixes from displaying anything

Can you provide the use-case for this behavior?

Right now I am trying to display to users what have been changed on their code. This is part of a pre-commit script

Right now I am trying to display to users what have been changed on their code. This is part of a pre-commit script

Thank you for providing your use-case!

Well, it does affect right now because JSON output prevents --show-fixes from displaying anything

I see. Looking at the following code:
https://github.com/astral-sh/ruff/blob/1f794077eca93207c9aad9c0eeca67d19722c8ac/crates/ruff/src/lib.rs#L295-L301
Ruff would always prefer to display violations unless either the --diff or --fix-only flag was supplied.
And as per the following code:
https://github.com/astral-sh/ruff/blob/1f794077eca93207c9aad9c0eeca67d19722c8ac/crates/ruff/src/printer.rs#L219-L235
Ruff wouldn't display the fix summary if the output format isn't either "full", "concise", or "grouped".
So, I think this behavior is correct because if someone wants to output in JSON, it's likely to be post-processed where it wouldn't make sense to provide additional output including the fix summary.

I would expect to get something meaningful out of json output when using show-fixes, but the process output is always empty (not even the [] from checks since I use --fix-only)

I think this is an expected behavior. The JSON output should only include the violations that are leftover after the fixes has been applied. It wouldn't include the violations which has been fixed.
tl;dr

The --output-format=json is for changing the format of the detected violations. For fixes, these are the remaining violations after the fixes have been applied.
The --show-fixes is to append a summary of the fixed violations after the diagnostic output but if output format is JSON, it's suppressed
The --fix-only is to only apply the fix which means no diagnostics will be displayed

(Sorry for the long explanation, but it's helpful to know the context.)

I'm a bit torn. It could make sense to include the fixed violations but we'd of course be changing the meaning of the API (right now, the contract is: these are the violations that Ruff found that exist in your files). Including fixed violations is a bit strange because (e.g.) the locations no longer make sense, since the file has changed.
I'd probably be open to changing it (curious to hear @dhruvmanila take) but wouldn't prioritize it unless someone wanted to take it on. I don't think we even have the information we'd need to power this in reporter right now.
We could also consider using an entirely different JSON output for --show-fixes where we just write the existing output but structured as JSON.


sft on downstream tasks

Thanks for your working.
What kind of computing resources does seeclick need when sft is performed on downstream tasks (i.e. Mind2Web)? I tried to sft seeclick on 1*A100, even though batch_size is set to 1, cuda out of memory error is still reported. Thanks!

Hi, 1*80G A100 should be enough for LoRA fine-tuning. Did you use LoRA or full fine-tune?

Thanks! I am trying to use Lora.

In my experience, full fine-tuning requires 2*80G A100 or more. For more training information, you can also check https://github.com/QwenLM/Qwen-VL, since SeeClick is fine-tuned on Qwen-VL.

Thank for your reply. I found that I could sft Qwen-VL-Chat with lora on 1A100 (40G), but sft SeeClick with lora on 1A100 (40G) would get "cuda out of memory". Is it because SeeClick unlocked the visual encoder and adds some customized LoRA parameters?

I think that's possible. You can try to modify the LoRA parameters in https://github.com/njucckevin/SeeClick/blob/ca9e2d5eb6154312c9ce92d2216ef82f9a8a4781/finetune/finetune.py#L315

感谢您的回复！我还有一个疑问，就是在mind2web数据集上进行评估时，seeClick与其基础模型Qwen-VL进行了对比。请问Qwen-VL在mind2web数据集上的结果是通过对Qwen-VL-Chat在mind2web训练集上（sft数据）进行LoRA微调后得到的吗？如果是的话，您的超参数是怎么设置的呢？因为我对Qwen-VL-Chat使用LoRA进行sft后，得到的Ele.Acc、Op.F1、Step SR都要低于论文中的结果。期待您的回复。

Qwen-VL的结果是通过对Qwen-VL-Chat进行sft得到的，和用SeeClick微调唯一的区别就是加载的基模型（SeeClick和Qwen-VL-Chat），所以应该是只需要把现在的微调脚本换一个基模型路径--pretrain-ckpt就可以？其他超参数是不变的，但和seeclick微调一样同样打开了视觉编码器的lora。您是怎么微调的，Qwen-VL-Chat的结果差很多是吗？

好像lock了视觉编码器。我再按您的参数试试！感谢回复。


Function URL under Manage tab is missing the Code on query string

It has it under develop tab, but not Manage.

https://github.com/projectkudu/AzureFunctionsPortal/issues/476 related


Adding the ability to define dedicated Kibana clients.

There's a full discussion on this patch here:
https://github.com/Viasat/opendistro-elastic-community/pull/10
This was completed prior to the helm chart merge.
This adds the ability to deploy dedicate clients to an existing release.

Can I get some eyes on this?

@rishabh6788 Added you as reviewer, other community members are welcome to provide review feedback too.

@DandyDeveloper sorry for the late reply, and thanks for the contribution. have you tested it locally?

@weicongs-amazon It was at the time but it has been a while, I may have to double check things.

close this firstly. feel free to reopen it

You're closing this 6 days after my reply, after taking 4 months of this being open?
Come in lads, you're better then this.
Pretty disappointing to have to see this.

@DandyDeveloper my bad. we mistakenly put a pending flag to this PR, and I didn't check it before closing it. We are just trying to use some new process to manage PRs. Feel very sorry for this. Reopen it.

Hi @DandyDeveloper any updates on this PR and your local testings?

Hi @DandyDeveloper it has been 14 days since my last comment and we have not receive any responses.
Therefore, we will close this PR as of now.
Please feel free to re-open it and confirm your tests to this feature so we can go through the next step. Thanks.


Dockerize

Adds docker support (Dockerfile & README) to DynDREST

@th-schwarz unfortunately, you did not merge this. Was this on purpose?

Hi @egmont1227, thanx for your comment. I didn't realize that I've closed this ticket without a comment, SORRY.
i must admit, i have little idea about docker. If I'm right, it's mostly configuration stuff, right?
For this reason, i prefer to document this in the wiki, with a prominent hint and link in the README. Having docker specific config files is src/test/resources doesn't make sense for me, because nobody sees it.
You are very wellcome to make a pull-request for the wiki. Thanx a lot in advance.


Questions about JakartaValidationPlugin and validation logic for creating fixture objects

Describe your question
My understanding is that the JakartaValidationPlugin reads the settings in the validation annotation and creates a fixture object with values that match the settings.
This is not exact, but the way I understand the above logic to work is as follows.

Create a fixture object
Validate that the field in the fixture object has a value assigned to it that meets the validation annotation conditions
Return the Fixture object if validation succeeds for all fields, otherwise recreate the Fixture object

It seems to be repeating the process of creating an object by first filling the fields with random values and then validating that the object is valid, rather than filling the fields with the validated values from the beginning.
So, I think if we can, it would be better to create the object when all the fields of the object have values that satisfy the conditions.
Of course, since Fixture Monkey uses the logic of the hibernate validator, in some ways I think creating an object and running the validation logic is a natural and much more common implementation.
I'm curious about the design history or opinions of the maintainer on this.

@doljae
Hello, I think the bug causes the misunderstanding.
Fixture Monkey works as follows.

It seems to be repeating the process of creating an object by first filling the fields with random values and then validating that the object is valid, rather than filling the fields with the validated values from the beginning.

Fixture Monkey has two logical flows to satisfy the validation.

Repeat to generate a value within each property that satisfies the condition constraints given by the validation annotation.
2.Repeat to generate an instance until validated by the validator(ex, Hibernate Validator).

For better understanding, you can check the classes below.

JakartaValidationConstraintGenerator,
JqwikJavaArbitraryResolver

Thank you.

Thanks for your detailed explanation.
Which jqwik-related classes actually generate values please?

@doljae

Which jqwik-related classes actually generate values please?

I didn't understand it properly. Can you elaborate on that?


Merge Clue-wasm and Clue

Since Clue-wasm is very outdated and Clue 3.0 will already use Cargo's workspace feature we could use it to merge the 2 repositories together.

With the introduction of clue_core the outdated part of this has been resolved, although merging it to the workspace is still undecided

considering how unsure we are and the fact 3.1 is big already, maybe we should do this in 3.2 instead?

It has been decided that Clue-wasm will be integrated into clue_core in 3.2


Relative imports

[NF] Change the repository organization according to #79 to be able to install pyleecan.
Now, it can be installed with the following command:
python setup.py install
Once pyleecan is installed, the GUI can be lauched with the command:
python -m pyleecan
The relative imports are now only in the pyleecan folder.

Thank you very much for this important step :)


Add authors to LibraryVersions.

fixes #1325

I have the authors listed after maintainers right now, is that right?

Authors should come first :) And can you please set the Author labels in Boost Mustard, with the Maintainer labels in site green?

@rbbeeston someone qualified needs to review this

We may want Author on it's own line? in a future version it may be separated out from the "This release" content as well, so I'd like to be sure we can do that at some point.
so the Authors and Maintainers would be 500 weight, and use the same green as before for the maintainers
I've asked Dave to review as well.

If we keep the avatar together with the text and label then I think its fine to just put Authors first in the grid. Followed by maintainers and then contributors.


VSCode should respect the Metered Connection flag on Windows, and not download updates

general info

I've only found #27758 to be slightly related, that's more of a feature request, while I consider this to be a bug, where a MS product, on a MS platform does not respect the 'metered connection' setting.

On VSCode Insiders - sorry, I'm on a metered connection right now - and do not currently have vscode insiders installed on this machine. I will update this issue later.

VSCode Version:
Version: 1.28.0 (user setup)
Commit: 431ef9da3cf88a7e164f9d33bf62695e07c6c2a9
Date: 2018-10-05T14:58:53.203Z
Electron: 2.0.9
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64
OS Version:
1083 build 17134.285

Steps to Reproduce:

Have a version of VSCode installed that's one or more updates behind.
Set update settings to default. (automatically update)
disconnect from any wired network
connect to a wireless network, and flag it as 'Metered Connection'

Does this issue occur when all extensions are disabled?: Yes/No
Yes
Actual behaviour
VSCode detects a newer version is avaliable, and starts downloading it, even while on a metered connection.
Expected behaviour
VSCode detects that i'm on a metered connection and only indicates that an update is available, but does not automatically download it.
Remarks
I love VSCode, and I would love it more if it also respected my wallet :-)
Work-around: disable updates by unchecking 'windows background update' and set updates to 'none'.

Thank you @vscodebot, but since #8540 is already closed, I would like to leave this issue open. The only way I can work with VSCode now, while on a metered connection, is by disabling alle update-settings.

Duplicate of https://github.com/Microsoft/vscode/issues/8540

Thank you @egemma, please help me understand why this is not considered a bug - I noticed you added the feature label. Thanks!

I've found this documentation by Microsoft on detecting metered connections from javascript: https://msdn.microsoft.com/en-us/library/hh750310
And I think the place where a change would have to be made in
vscode/src/vs/platform/update/electron-main/updateService.win32.ts
Am I on the right track with this? If so - i'm willing to consider proposing a pr. Will wait for guidance.

I'm abandoning this idea, various reasons.


Difficult in finding docs (should be sorted)

Problem
As of now, It is difficult to navigate docs as they are not sorted
Solution
So, we can sort the docs in descending order so that they appear on the top

So, It should be easy to navigate

Screencast1.webm

Working on it..


num count using map

Pull Request Type
What kind of change does this PR introduce?
[x] Solved an issue/task
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:
Issue Number: #1442
What is the new behavior?
Implemented an int count using a map in java

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


bug: Account credentials are cached between installs

Cody Version
latest nightly (this is PANW's issue)
IDE Information
PANW is using the latest nightly build of JetBrains.
Describe the bug

Install Cody
Log in / create account+token and make sure you can use Cody
Uninstall Cody
restart IDE
Reinstall Cody
Your old account info is shown, and in fact may still be logged in

Expected behavior
You should be logged out and have no cached account info or credentials.
Additional context
PANW demoed this bug to us live.

I believe this is the behavior in VS Code as well. Why do we need to log the user out when they uninstall? (I'm guessing it's a security issue?)

I'm marking this as P1. We can revisit after GA.


Provide lib/target suggestions for findLast/findLastIndex

Once https://github.com/microsoft/TypeScript/pull/49636 goes in, we should ensure that a user gets suggestions for using findLast/findLastIndex when their output target or lib is too low.
function findLastZeroIndex(arr: number[]) {
  return arr.findLastIndex(0);
}

We already do this for other missing methods.

Are you happy for anyone to take a look at this? Looking to find an issue to work on

Go for it. The code is in getScriptTargetFeatures. Add a new entry for es2023 containing entries for Array and all the TypedArray variants.
https://github.com/microsoft/TypeScript/blob/cb4c7689e69203feeaa32f075c2cb8c7240c2c64/src/compiler/utilities.ts#L1180


Branches that failed the build should still be available in !branches if built before

Not sure about the best approach here, open to discussion.


MARKDOWN SUPPORT: Temporary solution for MarCom

As a PO, I'd like to have a temporary solution for MarCom to write blog posts. We can achieve this by adding blog post field to the beaconCMS pages

@leandrocp found the proper way: #186


Make Context Menu shortcut programmable in all settings

For certain cases (like when the sidebar has focus, eg the file explorer), the only way to "right click" on a highlighted element via the keyboard is via the default shift + f10 binding, as described in https://github.com/microsoft/vscode/issues/123534.  It would be nice to be able to set overwrite this keybinding in keybindings.json, and more generally, to be able set the "open context menu" shortcut for all areas of focus (today, only editor.action.showContextMenu is possible).

Each component that shows a context menu would need to create a specific command and then that command could be bound via keybindings. #123534 mentions the explorer, so we could start there.


Modules used only by deprecated ODataModel still relevant?

The old sap.ui.model.odata.ODataModel has been deprecated since many years ago. But there are some modules which are not yet deprecated even though they are relevant only when being used together with the deprecated ODataModel:

sap.ui.model.odata.ODataListBinding
sap.ui.model.odata.ODataContextBinding
sap.ui.model.odata.ODataAnnotations

For each of them, there is a .v2 equivalent module. It would be nice if modules, that were only relevant to the currently deprecated modules and won't be relevant in the future, can become also marked as deprecated in order to avoid possible confusion and also to clean up the API reference tree (in case "Include deprecated" is not active).

Hello @boghyon ,
Thank you for sharing this finding. I've created an internal incident<PHONE_NUMBER>. The status of the issue will be updated here in GitHub.
Regards,
Wenqian


Add deprecated console warning to the Angular 2 directive

Connected to vaadin/components-team-tasks#142

This change is

Previously, platosha (Anton Platonov) wrote…
> #### Add deprecated console warning to the Angular 2 directive
>
> Connected to vaadin/components-team-tasks#142
>
>
>

Reviewed 3 of 3 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Parameterized translations

It would be beneficial to allow translations that require some dynamic values in them to be directly used with the TranslatePipe and TranslateService.  Looking around at what other projects offer, ng2-translation allows parameters to be used as substitutions in the translate pipe and RC6's i18n will use placeholders.
A proposed usage would be:
en.json:
{
  "UserNotifications": "{{ user }}, you have {{ numMessages }} new messages"
}

HTML:

{{ "UserNotifications" | translate:lang:{ user: username, numMessages: messages.length } }}

Typescript:
const params = {
  user: username,
  numMessages: messages.length
};
const translated = this.localizationService.translate("UserNotifications", params);

Ok, thanks for the suggestion. I will implement this feature as soon as possible.

I added the commit that allows you to use parameters.
If you want to test it, you can do so:

Uninstall this library from your application
Download this repository
Follow the instructions of the README file to build the library and install it in your application

You can use:

{{ "UserNotifications" | translate:lang:{ user: username, NoMessages: messages.length } }}

and if you need, even the nested localization:

{{ "UserNotifications" | translate:lang:{ user: username | translate:lang, NoMessages: messages.length | localeDecimal:defaultLocale:'1.2-2' } }}

Please let me know if it works as you expect.

Sorry for the delay, I finally got a chance to test this on a separate project.  This works as expected, thanks!

Hi,
I have included this feature in the new version compatible with rc.7.
Greetings


Typst blocks for globals variables

Not familiar with the codebase of typst or this plugin, but is this possible? Would be great to have some file-scoped globals, or, for example, some typst inside the settings for wide-scoped things.

Do you mean defining a variable in one code block then importing it from another? I was thinking implementing that at some point.
There are also preambles in the settings...

Preamble is great. I think that there should be either a switch in the settings that lets you define all blocks in the file as a scope, so that you can use variables from other blocks (kinda like jupyter notebook), or a special kind of block that makes it global on file scope


Add optional data parameter to SetPrototypeMethod

The v8::FunctionTemplate that Nan::SetPrototypeMethod creates can take some user data to thread through to the callback, but SetPrototypeMethod doesn't currently expose this parameter like some of the other NAN functions. I'm using a patched version of SetPrototypeMethod to work around this in my own project, but it's a simple change to upstream and would reduce a little of my future maintenance burden.

This seems to be valid, but could you add a regression test as well?

Closing since this was rolled into #876.


Multiple Problems

Not sure if AWS is maintaining this anymore but for anyone finding this and trying to run it, I'll save you a little time getting it to work.

The way the lambda policy is written you must use a lower case stack name or else the lambda will not be able to execute a Redshift query
The glue job is missing parameter: num_level_to_denormalize.  Add it.
There are multiple problems with the glue script
a. Function find_tbl_nested_level: the returned dict has a key that is different from the one that the script expects later.  Add key 'number_nested_levels': lvl
b. In the for loop updating the table names:

This:
tables_to_join_map[str(next_join_lvl)][child_tbl_name] = {
'join_to_tbls': [], 'join_col': [], 'has_child': False}
Should be:
tables_to_join_map[str(child_tbl_join_lvl)][child_tbl_name] = {
'join_to_tbls': [], 'join_col': [], 'has_child': False}
c. (I'm not 100% on this one but this is what I did)
In the denormalize loop at the end, I commented the second predicate in the if.  I cannot figure out what it was meant to be..:
if table_with_nested_level['table_nested_level'] <= start_join_level:
if table_with_nested_level['table_found'] == 1: #and table_to_be_joined_with_level['table_nested_level'] == start_join_level

Thanks for letting us know, I have fixed the issue in the CloudFormation and pointed it to the right Glue script. Further more I added a comment in the code hoping to have clarified why the second If was there.


Update picture command sequence diagram

Coverage remained the same at 88.976% when pulling 4a0546197249353eb57fae66b34e76aff81cb954 on denzelchung:pic-seq-diagram into 6eb111042cd7ffd900c59931f32961e5e777b675 on CS2103-AY1819S1-W13-1:master.


Stream API speed and accessing multiple streams at once

Hi,
I have started using tweetInvi stream API to get filtered streams, it's working as expected. But, it's taking almost 1 sec to return 1 tweet. Is there any way I can increase this speed..? Also, from arguments we get one tweet at a time, Is there any way I can get a list of tweets available at that given point of time.?
        stream.MatchingTweetReceived += (sender, args) =>
        {
               .....
              Console.WriteLine(args.Tweet.Text);
        };

Hello there,
From the testing Tweetinvi is capable of handling hundreds of millions tweets per day from a stream.
Are you sure that your stream filters are supposed to return more than 1 tweet per second?

Thanks, @linvi , you were right... I changed the stream filter for trending hashtag and its returning lot of tweets as expected. However, I have seen my stream getting stuck(paused) by itself after some time... I am not getting any exceptions, I have only one stream which is currently running and I did not get any stream stopped or stream paused event. Any idea why is this happening..?

Not really, if you do not receive any StreamStopped event the Stream must be running.
To get more information can you check the JsonObjectReceived event that actually returns ALL the events retrieved by the stream, including the non expected events.
Let me know when you have more information about it.


Proposal for CLI redesign

I have to admit, that apart from asking for an option to use CLI to validate only selected resource defined in a package (and do similarly sub-resource oriented actions) it turned into request to redesign CLI what is not a small thing.
Please, bear with me. Frictionless Data seem to be my fulfilled dream (I was in search for something like that for years), on the other hand I got confused by CLI too many times. As creating CLI tools is something I do for many years, I tried to describe an alternative, which could probably remove some problems I have experienced.
Real world example: validate single resource from a package
I have 24 CSV files, some of them rather long, and want to specify package. The structure is complex, there are constraints, primary keys, foreign keys.
frictionless describe *.CSV > package.yaml creates one large package descriptor, but for fine tuning resource definitions I need to validate them repeatedly.
It is possible today to validate only the whole package what takes time. It would be very helpful, if I could validate only selected resource defined within the package, e.g. by: frictionless validate --resource countries package.yaml
Note, that due to the current CLI design, which tries to assume or detect many things, it is not always very clear what is going to happen, e.g.:

what type of object is expected as source of information for validation
what object will be really validated

Gallery of similar scenarios

extract single table from tabular data package
extract single table from Excel file (table defined on sheet named "classes")
validate single table from Excel file (table defined on sheet named "classes")
extract single table from SQL database (table named "classes")
validate single table from SQL database (table named "classes")

Aspects of CLI call
The CLI call must explicitly or implicitly decide set of questions:

what type of operation to perform:

describe
validate
extract
summary

definition of rules to follow

data package descriptor

explicitly stated
inferred

resource descriptor

explicitly stated
inferred

schema descriptor

explicitly stated
inferred

object to operate on:

whole data package (all it's resources)
specific resource

named resource within a descriptor
sheet in Excel file
table in SQL database
etc (plugin dependent)

output content modifier

e.g. filters on columns, rows, offset, limit...

output format

plain text (incl. tables)
JSON
YAML
CSV

Personally I got surprised a few times:

the CSV files to operate on can be specified explicitly or indirectly by resource or package descriptor - nice
frictionless describe *.csv creates data package descriptor with inferred schemas for all the CSV files - nice
frictionless describe *.resource.yaml creates data package consisting of the *.resource.yaml files and does not take into account the resources defined in them - bad
frictionless extract package.yaml complained about unexpected structures in the descriptor (which was not tabular). It would be better to expect very specific input and complain, that the profile declare is not the one expected

I understand the intention to provide "easy to use and intuitive tool" but in fact, auto-detection of things might bring confusion which finally make things more complicated and less predictable.
Technical options for CLI
There is click library which is currently used. click allows nested sub-commands (without real limit in nesting). This concept shall be expressive enough to provide all required input information. Another advantage of more specific (sub)commands is, that they could be more strict on provided input and complain in more specific way addressing the thing to fix more specifically.
Another option is similar to current frictionless transform where the pipeline can be very specific on what shall be done. Anyway, I am afraid this approach would be less user friendly as it requires to learn how to define the pipeline.
Last option is to use some (sub)resource addressing scheme similarly as pytest specifies which test to run, e.g. pytest test_mod.py::test_func. Similar approach could be used to specify a tabular resource defined within tabular data package.
Some CLI examples
Here are some examples of alternative CLI design. It builds on:

"verb-noun" design
(click) sub-commands
rule: do not pass values for always required arguments via options but as positional arguments.
rule: if some (positional) arguments are variable in number of occurrences, they must go as last ones
keep separate CLI signature for each specific case. This allows the CLI to be very specific and do not mess with options or arguments which are not relevant.

If you would agree on it, I could contribute stub click command implementation to prove, it would be very instructive to users.

Hi @vlcinsky,
Thanks for a great and detailed issue! I don't think we can introduce such breaking change for the whole CLI so might be an alternative CLI runner package might be an option?

Do you mean separate python package (installed independently from frictionless-py) or alternative CLI within existing package?
You are right, the change is extensive. In long term I could imagine, we start with alternative CLI within frictionless-py, keep it marked as experimental or beta for a while until it matures and finally deprecate the existing CLI to keep it more manageable.

Yes I think an additional CLI runner package similar to js projects like webpack-cli. It might be a good first step to test the idea

It is possible today to validate only the whole package what takes time. It would be very helpful, if I could validate only selected resource defined within the package, e.g. by: frictionless validate --resource countries package.yaml

Just wanted to point out that after https://github.com/frictionlessdata/framework/pull/1112 it's possible to validate a single resource from a data package with
frictionless validate --json --resource-name foo datapackage.json

This will correctly identify eventual validation errors coming from foreign keys constraints.


Missing EDCSA keys should be autodetected

qDup should emit an explanatory message when it cannot connect due to missing EDCSA keys.

How did qDup show the error in the current release? I'm not sure how we could add a test case for that

11:14:54@rvansa qDup$ jbang ./docs/examples/runQDup.java
11:15:01.164 [main] INFO  io.hyperfoil.tools.qdup.JarMain - Starting with output path = /tmp/qDup4505339498182214548
11:15:01.347 [main] INFO  io.hyperfoil.tools.qdup.JsonServer - listening on port 31337
11:15:01.414 Running qDup version 0.6.2 @ unkonown
11:15:01.417 run-1663146901062 starting state:
 GREETING = Hello qDup!
 USER = rvansa
 HOST = rvansa

11:15:01.424 [main] INFO  i.h.tools.qdup.cmd.Dispatcher - starting 0 scripts
11:15:01.514 [qdup-command-1] INFO  o.a.s.c.u.s.e.EdDSASecurityProviderRegistrar - getOrCreateProvider(EdDSA) created instance of net.i2p.crypto.eddsa.EdDSASecurityProvider
11:15:01.558 [qdup-command-1] INFO  o.a.s.c.i.DefaultIoServiceFactoryFactory - No detected/configured IoServiceFactoryFactory using Nio2ServiceFactoryFactory
11:15:01.565 [qdup-command-1] INFO  o.a.s.c.c.h.DefaultConfigFileHostEntryResolver - resolveEffectiveResolver(rvansa@rvansa:22) loaded 23 entries from /home/rvansa/.ssh/config
11:15:01.772 [qdup-command-1] ERROR io.hyperfoil.tools.qdup.Run - failed to connect rvansa@rvansa:22
11:15:01.773 failed to connect all ssh sessions for run
11:15:01.774 [qdup-command-0] WARN  i.h.tools.qdup.cmd.Dispatcher - ignoring stop call when already stopped

However as I found (#132) it's not the current release.

And the current jBang command does not work with 0.6.12...

the failed to connect rvansa@rvansa:22 message is meant to point out the issue. I've added
logger.error("failed to connect "+host.getSafeString()
        +(host.hasPassword() ?
            ", verify ssh works with the provided username and password" :
            ", verify password-less ssh works with the selected keys"
        )
);

Is that what you are recommending or is there something else we could add to help users?

What are 'selected keys'? If plain ssh rvansa@rvansa:22  works using id_rsa, I would not understand why qDup can't. If qDup requires id_ecdsa it should check if new File(home + ".ssh/id_ecdsa").canRead() and explain that.

selected keys means either whatever is the default in ~/.ssh or what is passed in with -i --identity
If ssh rvansa@rvansa:22 works then qDup should also work.

I've used an older version of qDup, but in my case just id_rsa always worked with plain ssh but it was not the case with qDup. Shall I remove my id_ecdsa and try with most recent version of qDup?

I only have an id_rsa so I am confused what is not working. Please try the most recent qDup and see if you can reproduce the login failure while still being able the ssh without a password.
If you could do it with either an id_rsa you can share (so not your normal one) or do it with containers in the test suite like SshTestBase does with the getHost() getSession() and createContainer()

Okay, I can confirm that while I can reproduce it when running qDup 0.6.2 it is not reproducible with 0.6.12. I guess the userauth_pubkey fix described in https://github.com/Hyperfoil/qDup/blob/master/docs/ssh-config.adoc#11-userauth_pubkey-key-type-ssh-rsa-not-in-pubkeyacceptedalgorithms is not needed anymore.


Link against internally defined libraries

Neither #2595 nor #2758 fully addressed the underlying issue that final netcdf target linking was failing due to missing dependencies previously defined in other internal targets. While a valid solution to manually specify linking dependencies again, part of the effort is to make use of the target structure in cmake to further inform future linking.
The usage of the generator expression $<TARGET_OBJECTS:...> negates any target-specific linking that ought to be inherited to the netcdf target. To avoid this issue internal targets such as dispatch should be directly linked. Since target netcdf does not have PUBLIC/PRIVATE definitions for its  linking, a compromise for now is to use the $<TARGET_NAME_IF_EXISTS:...> generator expression which will fully fix linking even prior to #2595 / #2758 and a valid config able to be found/imported by other cmake projects.

I've re-queued them and we will see what happens :)


NaN > NaN and NaN >= NaN do not adhere to IEEE-754

IEEE-754 requires that all comparisons between NaN and any other number (including NaN) return false (except not-equals, which naturally returns true).  Elm, however, returns true for both NaN > NaN and NaN >= NaN.
In addition, Elm's handling of NaN in Basics.compare is questionable.  Borrowing from https://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false-for-ieee754-nan-values, clause 5.11, paragraph 2 of the 754-2008 standard:

Four mutually exclusive relations are possible: less than, equal, greater than, and unordered. The last case arises when at least one operand is NaN. Every NaN shall compare unordered with everything, including itself.

Basics.compare, however, can only return one of LT, EQ, or GT, and ends up returning GT for any combination of inputs involving NaN, e.g. it effectively asserts both 1 > NaN and NaN > 1 in addition to the behavior above.  I realize changing the Basics.compare behavior to permit a fourth relation would break quite a lot of code, and leaves unanswered any question as how to, e.g., sort Lists containing NaNs among other Floats.  (Right now, where the NaNs end up depends on where they occur in the input list.  Further, Dicts and Sets can insert multiple NaNs but cannot find them!)
Accordingly, I respectfully recommend (1) fixing infix operators > and >= to return false for any NaN input and (2), in the interest of supporting NaNs in Dicts, Sets, and List.sort, adjusting Basics.compare to regard NaN as equal to itself and greater than all other input.  While this makes Basics.compare behave differently from the infix operators, I note this is already the case, and is more or less necessary without adding a fourth Order value.

This is related to but distinct from #988.  Depending on if Basics.compare is implicitly called by == for composite types, addressing (2) may result in such objects consistently comparing equal.  However, NaN == NaN should still return false to agree with IEEE-754.


cleanup warnings throughout codebase

The code generated by #[derive(Arbitrary)] is triggering the clippy::unit_arg lint, I'll open an upstream issue / PR to get that cleaned up so we can remove these allows

I had to mess with the match statement in zebra-network/src/protocol/external/codec.rs a bunch which made it more verbose, but I was getting weird compiler errors that were probably entirely from rust-analyzer and not indicative of a real problem. It seems like the use Message::* was name collisions with other types that were already in scope which was just making rust-analyzer fall over. Either that or rust analyzer exports some special setting that more comprehensively tests our code when it runs our code, but messing with the body of the code seemed to introduce compiler errors so im assuming it was all compiling fine.


Arduino UNO Arducam 4 cameras adapter board problem

Hello,
Im trying to get 2 Arducam mini 2mp running on an Arduino UNO together with the Adapter board. Unfortunately I can't get any feed in the host app running on my macbook. Ive tried the ArduCam_Mini_Video_Streaming example and the ArduCam_Mini_4CAM_VideoStreaming. The memory saver.h looks fine and I guess the wiring is given since I'm using the adapter board straight on to the Arduino board. It mostly say something like this:
"COM is open!
���瑓
囂�
ArduCAM single
"L'�
Lg"
Any clues?
Best regards,

@WilliamJohnsson
Hi,
Very sorry to hear it.
Our host for Arducam 4cam has some bugs
and we will optimize it as soon as possible.
Regards,
ArduCAM support team.

Yeah I coult tell. It reminds me of this issue that I think was solved (?):
https://github.com/ArduCAM/Arduino/issues/138
Maybe the hostapp for Mac is still the old one (1.0) ?
Regards,


Documentation required

For now, this repo does not have official documentation except Dr. Wilcox's ppt requirements.
A good way to start this would be a markdown file for documenting these function, for example, what to do with it? What are these parameters mean? some examples using this function, as well as developer's comment.

resources:
https://towardsdatascience.com/how-to-set-up-your-python-project-docs-for-success-aab613f79626


Julia extension in the core VS Code product

It seems like the grammar of a number of popular languages are shipped out-of-the box with VS Code because they have an extension in https://github.com/microsoft/vscode/tree/master/extensions.
What are the criteria for being included there? Would Julia be a potential candidate to also ship like this? Would be great if you could share a bit about the pros and cons of that, I think I don't fully understand the implications at the moment of being included there.
We (the Julia extension team) could probably prepare a PR that would add this and would also be happy to maintain this.
Are there any guidelines about splitting a given language support up into one extension that ships with the core product and then a second extension that ships on the marketplace?

Given the rising popularity of Julia we'd be interested to include a basic language extension in VSCode!
However, we need some expertise, so if you can help, that would be fantastic!
Basic language extensions just define declarative language contributions (no code):
The language definition, the language configuration as well as a grammar.
Some extensions also provide a set of snippets but we try to avoid this as it's a better user experience if snippets are coming from separate extensions.
The pros of having a basic language extension are of course the better out-of-the-box editing experience for end users. Also, it will help Julia extension authors to avoid duplication of the definitions mentioned above.
The cons are be the additional maintenance efforts (handling issues and PRs, having the language knowledge to be able to answer these correctly) on our side. But with your help we will be fine.
We don't want to own any TextMate grammars so it's important is that we can rely on a well maintained TextMate grammar.
I've seen that you use a patched version of https://github.com/JuliaEditorSupport/atom-language-julia. The repo looks good: MIT license and regular updates.
I was wondering, would it be possible to avoid the patching, e.g. by contributing the changes back to the original repo?

Awesome! Do you want me to open a PR where I just copy the relevant parts from the existing Julia extension over into this repo here? And then we can iterate on any changes you think we need to make before it can get merged?
On the grammar: I'll discuss that with the team next week. The whole team that worked on the Julia extension for Atom (and maintained that existing upstream grammar repo) joined the VS Code extension effort a couple of months ago, so the Julia-Atom effort is essentially in maintenance mode now. It probably makes most sense for us to just move the "truth" for the TextMate grammar somewhere else, and make the VS Code team the primary maintainer for it, so that we can just do a 1:1 copy of that grammar into the VS Code repo somewhat regularly.

Yes, great, sounds like a plan. Let's iterate on a PR.
For the repo, also good, I suggest to create a new GitHub repo just for the grammar and continue the development & maintenance it there. https://github.com/Microsoft/TypeScript-TmLanguage is an example of such a grammar repo.
With the VS Code team you mean the the Julia VS Code extension team?

Alright, it took a while but the VSCode-specific grammar is now included in JuliaEditorSupport/atom-language-julia.
Let me know how you want to proceed to get that into VSCode core.

Alright, it took a while but the VSCode-specific grammar is now included in JuliaEditorSupport/atom-language-julia.
Let me know how you want to proceed to get that into VSCode core.

Amazing, thanks @pfitzseb
@rchiodo is there any jupyter specific stuff we need to be aware of?

Amazing, thanks @pfitzseb
@rchiodo is there any jupyter specific stuff we need to be aware of?

Amazing, thanks @pfitzseb
@rchiodo is there any jupyter specific stuff we need to be aware of?

@jlperla I believe this issue is talking about adding the grammar to VS code. That should make it just work for both our old webview notebooks and the new native notebook support in VS code insiders. So with regards to the grammar (which gets colorization to work correctly), this should just work inside of jupyter.

Amazing, thanks @pfitzseb
@rchiodo is there any jupyter specific stuff we need to be aware of?

@jlperla I believe this issue is talking about adding the grammar to VS code. That should make it just work for both our old webview notebooks and the new native notebook support in VS code insiders. So with regards to the grammar (which gets colorization to work correctly), this should just work inside of jupyter.

@aeschli Now that we have the grammar, is there a rough timeline for when this sort of thing would hit the released vscode?  Not expecting anything fast, of course, just tryign to do some planning for when I am likely to be able to rely on it.

@aeschli Now that we have the grammar, is there a rough timeline for when this sort of thing would hit the released vscode?  Not expecting anything fast, of course, just tryign to do some planning for when I am likely to be able to rely on it.

Can you make a PR for the rest of the file needed for the extension? Here's an example of another basic language:
https://github.com/microsoft/vscode/tree/master/extensions/razor

Can you make a PR for the rest of the file needed for the extension? Here's an example of another basic language:
https://github.com/microsoft/vscode/tree/master/extensions/razor


feat!:  fix after-create-window, add after-window-load event

Previously the after-create-window event was fired after loadURL is resolved. This fixes that.
BREAKING CHANGE:
after-create-window now happens earlier during the window creation lifecycle.
Alternatively this could be implemented as a non breaking change: after-create-window would stay the same and an event name like real-after-create-window could be introduced instead.

superseded by #370
this PR can be closed

Closing, see #370


Is it possible to validate only a block of CSS code?

Hi, is it possible to validate a block of CSS code instead of an entire CSS file?
For example, I want to validate this
display: grid;
grid-template-columns: 2fr 5fr 1fr;
grid-gap: 1rem;

instead of
.grid-container {
  display: grid;
  grid-template-columns: 2fr 5fr 1fr;
  grid-gap: 1rem;
}

I've looked through the docs and was not able to find anything related to this.
It's for a project I'm working on https://www.cssgridplayground.com and I would like to sanitize individual sections of a CSS code.
Thanks

There's no was as input needs to be valid CSS. You can always wrap it in a dummy selector if that's possible.

Thanks, I ended up doing that. :-)

:+1:


CAM16 implementation

It seems that the state-of-the-art currently in colour spaces is the CAM16 colour space. @nschloe wrote a paper concerning improvements to the colour space, which they then implemented in Python as part of a larger colour space library. I know very little about colour spaces or mathematics, so I don’t know how much I could do apart from mechanically porting the Python implementation to Rust. Is this something that would be helpful?

It's definitely interesting! Thanks for bringing it up. Porting the Python implementation seems fine to me, but it will of course have a few more bells and whistles to be in line with the rest of the library. Feel free to give it a try if you want to. A lot of these things are mechanical copies of implementations or specifications, so it wouldn't be the first. Don't hesitate to ask if you decide to try it and run into trouble.

It's definitely interesting! Thanks for bringing it up. Porting the Python implementation seems fine to me, but it will of course have a few more bells and whistles to be in line with the rest of the library. Feel free to give it a try if you want to. A lot of these things are mechanical copies of implementations or specifications, so it wouldn't be the first. Don't hesitate to ask if you decide to try it and run into trouble.

The link has moved to  @https://github.com/nschloe/colorio/blob/main/colorio/cs/_cam16.py. The "bells and whistles" can be at least initially reduced by always using the CAM16-UCS viewing conditions. Implementing CAM16 would also contribute to the CAM02 issue, since a lot of code is shared between them.

Thanks for the heads up! And yeah, it would be nice if code can be shared there.

I implemented a color crate, without knowing about "palette" and implemented different color spaces rgb, linear rgb, XYZ... and also color appearance model: Lab, Cam16 and  Android HTC for a project of my business. I did it in one week so it has the quality of a crate written in one week. Palette is really superior.
I would prefer to switch to palette but I need Cam16 and HTC. Are you still interested in the implementation of Cam16 in Palette?

I have seen your code, there are cryptic macros "palette_internal". If you explain me I can try to implement Cam16 otherwise, here is an implementation:
#![allow(non_snake_case)]
use super::{ChromaticAdaptation, ViewingCondition as SpecViewingCondition};
use crate::cam::{ColourAppearanceModel, ColourAppearanceTransform};
use crate::color_spaces::AbsoluteWhite;
use crate::color_spaces::{
    ColorModel, Illuminant, LinearColorSpacePrimaries, WhitePoint, RELATIVE_TRISTIMULUS_SCALE,
};
use crate::illuminant::E;
use crate::rgb::TristimulusRgb;
use crate::utils::{angle_degree, to_rad};
use crate::xyz::{ChromaticityXy, RelativeXYZ};
use nalgebra::{matrix, vector, Matrix3, Vector3};

#[derive(Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Default)]
struct Cam16ColorSpace;

#[derive(Copy, Clone, Debug)]
pub struct Cam16 {
    pub hue: f32,
    pub lightness: f32,
    pub brightness: f32,
    pub chroma: f32,
    pub colorfulness: f32,
    pub saturation: f32,
}
impl_eq_hash! {Cam16, floats(
hue,
lightness,
brightness,
chroma,
colorfulness,
saturation
)}

#[derive(Copy, Clone, Debug, PartialEq)]
pub struct ViewingCondition {
    D_rgb: Vector3<f32>,
    Fl: f32,
    Nbb: f32,
    Aw: f32,
    c: f32,
    z: f32,
    Nc: f32,
    n: f32,
}
#[derive(Copy, Clone, Debug)]
pub struct Cam16Hcl {
    pub hue: f32,
    pub colorfulness: f32,
    pub lightness: f32,
}
impl_eq_hash! {Cam16Hcl, floats(
hue,
colorfulness,
lightness
)}
#[derive(Copy, Clone, Debug)]
pub struct Cam16Jab {
    pub lightness: f32,
    pub a: f32,
    pub b: f32,
}
impl_eq_hash! {Cam16Jab, floats(
lightness,
a,
b
)}

impl From<Cam16> for Cam16Hcl {
    fn from(v: Cam16) -> Self {
        let J = v.lightness;
        let M = v.colorfulness;
        let h = v.hue;
        Self {
            lightness: 1.7 * J / (1. + 0.007 * J),
            colorfulness: (0.0228 * M).ln_1p() / 0.0228,
            hue: h,
        }
    }
}
impl From<Cam16Hcl> for Cam16Jab {
    fn from(v: Cam16Hcl) -> Self {
        let M = v.colorfulness;
        let h = v.hue;
        let a = M * to_rad(h).cos();
        let b = M * to_rad(h).sin();
        Self {
            lightness: v.lightness,
            a,
            b,
        }
    }
}
impl From<Cam16Jab> for Cam16Hcl {
    fn from(v: Cam16Jab) -> Self {
        let M = v.a.hypot(v.b);
        let h = angle_degree(v.b, v.a);
        Self {
            lightness: v.lightness,
            colorfulness: M,
            hue: h,
        }
    }
}
impl From<Cam16> for Cam16Jab {
    fn from(v: Cam16) -> Cam16Jab {
        let inter: Cam16Hcl = v.into();
        inter.into()
    }
}

impl ColourAppearanceModel for Cam16Jab {
    type ViewingCondition = ViewingCondition;
    fn to_tristimulus_in<T: AbsoluteWhite>(
        &self,
        condition: &Self::ViewingCondition,
    ) -> RelativeXYZ<T> {
        Cam16Hcl::to_tristimulus_in(&(*self).into(), condition)
    }
    fn from_tristimulus_in<T: AbsoluteWhite>(
        c: RelativeXYZ<T>,
        condition: &Self::ViewingCondition,
    ) -> Self {
        Cam16::from_tristimulus_in(c, condition).into()
    }
    fn distance(&self, other: &Self) -> f32 {
        let dj = self.lightness - other.lightness;
        let da = self.a - other.a;
        let db = self.b - other.b;
        let de = (dj * dj + da * da + db * db).sqrt();
        1.41 * de.powf(0.63)
    }
    fn grey_of_lightness(lightness_scale: f32, _condition: &Self::ViewingCondition) -> Self {
        Self {
            lightness: lightness_scale,
            a: 0.,
            b: 0.,
        }
    }

    fn lightness_scale(&self) -> f32 {
        self.lightness
    }

    fn color_scale(&self) -> f32 {
        self.a.hypot(self.b)
    }

    fn hue(&self) -> f32 {
        angle_degree(self.b, self.a)
    }

    fn set_lightness_scale(&mut self, lightness_scale: f32) -> &mut Self {
        self.lightness = lightness_scale;
        self
    }

    fn set_color_scale(&mut self, color_scale: f32) -> &mut Self {
        let cur = self.color_scale();
        if color_scale != cur {
            assert!(
                cur != 0.,
                "cannot give back color to grey Cam16Jab color appearance"
            );
            let coef = color_scale / cur;
            self.a *= coef;
            self.b *= coef;
        }
        self
    }

    fn set_hue(&mut self, hue: f32) -> &mut Self {
        let c = self.color_scale();
        self.a = c * to_rad(hue).cos();
        self.b = c * to_rad(hue).sin();
        self
    }

    fn from_hue_color_lightness_scales(
        hue: f32,
        color_scale: f32,
        lightness_scale: f32,
        _: &ViewingCondition,
    ) -> Self {
        let a = color_scale * to_rad(hue).cos();
        let b = color_scale * to_rad(hue).sin();
        Self {
            lightness: lightness_scale,
            a,
            b,
        }
    }
}

impl ColourAppearanceModel for Cam16Hcl {
    type ViewingCondition = ViewingCondition;
    fn to_tristimulus_in<T: AbsoluteWhite>(
        &self,
        condition: &Self::ViewingCondition,
    ) -> RelativeXYZ<T> {
        let J = 142.86 * self.lightness / (242.86 - self.lightness);
        let M = (self.colorfulness * 0.0228).exp_m1() / 0.0228;
        let C = M / condition.Fl.powf(0.25);
        let h = self.hue;
        appearance_to_tristimulus(J, C, h, condition)
    }
    fn from_tristimulus_in<T: AbsoluteWhite>(
        c: RelativeXYZ<T>,
        condition: &Self::ViewingCondition,
    ) -> Self {
        Cam16::from_tristimulus_in(c, condition).into()
    }
    fn distance(&self, other: &Self) -> f32 {
        let s: Cam16Jab = (*self).into();
        let o: Cam16Jab = (*other).into();
        s.distance(&o)
    }

    fn grey_of_lightness(lightness_scale: f32, _condition: &Self::ViewingCondition) -> Self {
        Self {
            lightness: lightness_scale,
            hue: 0.,
            colorfulness: 0.,
        }
    }

    fn lightness_scale(&self) -> f32 {
        self.lightness
    }

    fn color_scale(&self) -> f32 {
        self.colorfulness
    }

    fn hue(&self) -> f32 {
        self.hue
    }

    fn set_lightness_scale(&mut self, lightness_scale: f32) -> &mut Self {
        self.lightness = lightness_scale;
        self
    }

    fn set_color_scale(&mut self, color_scale: f32) -> &mut Self {
        self.colorfulness = color_scale;
        self
    }

    fn set_hue(&mut self, hue: f32) -> &mut Self {
        self.hue = hue;
        self
    }

    fn from_hue_color_lightness_scales(
        hue: f32,
        color_scale: f32,
        lightness_scale: f32,
        _: &ViewingCondition,
    ) -> Self {
        Self {
            hue,
            lightness: lightness_scale,
            colorfulness: color_scale,
        }
    }
}

impl ColourAppearanceModel for Cam16 {
    type ViewingCondition = ViewingCondition;

    fn to_tristimulus_in<T: AbsoluteWhite>(
        &self,
        condition: &Self::ViewingCondition,
    ) -> RelativeXYZ<T> {
        let J = self.lightness;
        let C = self.chroma;
        let h = self.hue;
        appearance_to_tristimulus(J, C, h, condition)
    }

    fn from_tristimulus_in<T: AbsoluteWhite>(
        c: RelativeXYZ<T>,
        condition: &Self::ViewingCondition,
    ) -> Self {
        let rgb: TristimulusRgb<Cam16ColorSpace> =
            RelativeXYZ::<Cam16ColorSpace>::from_vector(c.into_vector()).into();
        let C_rgb = condition.D_rgb.component_mul(&rgb.into_vector());

        let a_rgb = C_rgb.apply_into(|v| {
            if *v >= 0. {
                let c = (condition.Fl * *v).powf(0.42);
                *v = 400. * c / (c + 27.13);
                //*v = 400. * c / (c + 27.13) + 0.1;
            } else {
                let c = (-condition.Fl * *v).powf(0.42);
                *v = -400. * c / (c + 27.13);
                // *v = -400. * c / (c + 27.13) + 0.1;
            }
        });
        let (Ra, Ga, Ba) = (a_rgb.x, a_rgb.y, a_rgb.z);
        let a = Ra - 12. * Ga / 11. + Ba / 11.;
        let b = (Ra + Ga - 2. * Ba) / 9.;
        let h = angle_degree(b, a);

        let A = (2. * Ra + Ga + Ba / 20.) * condition.Nbb;
        //let A = (2. * Ra + Ga + Ba / 20. - 0.305) * condition.Nbb;
        let J_1 = (A / condition.Aw).powf(condition.c * condition.z);
        let J = J_1 * 100.;
        let Q = (4. / condition.c) * J_1.sqrt() * (condition.Aw + 4.) * condition.Fl.powf(0.25);
        let h_prime = if h < 20.14 { h + 360. } else { h };
        let et = 0.25 * ((to_rad(h_prime) + 2.).cos() + 3.8);
        let t = (50_000. / 13.) * condition.Nc * condition.Nbb * et * a.hypot(b)
            / (Ra + Ga + (21. / 20.) * Ba + 0.305);
        // / (Ra + Ga + (21. / 20.) * Ba);
        let C = t.powf(0.9) * J_1.sqrt() * (1.64 - 0.29f32.powf(condition.n)).powf(0.73);
        let M = C * condition.Fl.powf(0.25);
        let s = 100. * (M / Q).sqrt();
        Self {
            hue: h,
            lightness: J,
            brightness: Q,
            chroma: C,
            colorfulness: M,
            saturation: s,
        }
    }
    fn from_hue_color_lightness_scales(
        hue: f32,
        color_scale: f32,
        lightness_scale: f32,
        condition: &Self::ViewingCondition,
    ) -> Self {
        let h = hue;
        let J = lightness_scale;
        let s = color_scale;
        let J_1 = J / 100.;
        let Q = (4. / condition.c) * J_1.sqrt() * (condition.Aw + 4.) * condition.Fl.powf(0.25);
        let M = (s / 100.).powi(2) * Q;
        let C = M / condition.Fl.powf(0.25);
        Self {
            hue: h,
            lightness: J,
            brightness: Q,
            chroma: C,
            colorfulness: M,
            saturation: s,
        }
    }
    fn distance(&self, other: &Self) -> f32 {
        let s: Cam16Hcl = (*self).into();
        let o: Cam16Hcl = (*other).into();
        s.distance(&o)
    }

    fn grey_of_lightness(lightness: f32, condition: &Self::ViewingCondition) -> Self {
        let Q =
            (4. / condition.c) * (lightness / 100.) * (condition.Aw + 4.) * condition.Fl.powf(0.25);
        Self {
            hue: 0.,
            lightness,
            brightness: Q,
            chroma: 0.,
            colorfulness: 0.,
            saturation: 0.,
        }
    }

    fn lightness_scale(&self) -> f32 {
        self.lightness
    }

    fn color_scale(&self) -> f32 {
        self.saturation
    }

    fn hue(&self) -> f32 {
        self.hue
    }

    fn set_lightness_scale(&mut self, lightness: f32) -> &mut Self {
        let Q0 = self.brightness;
        let J0 = self.lightness;
        let C0 = self.chroma;
        let jc0 = (J0 / 100.).sqrt();
        let jc1 = (lightness / 100.).sqrt();
        let f = jc1 / jc0;
        let Q1 = Q0 * f;
        let C1 = C0 * f;
        let M1 = self.colorfulness * (C1 / C0);
        self.lightness = lightness;
        self.brightness = Q1;
        self.chroma = C1;
        self.colorfulness = M1;
        self
    }
    fn set_color_scale(&mut self, saturation: f32) -> &mut Self {
        let colorfulness = (saturation / 100.).powi(2) * self.brightness;
        let mc_coef = self.chroma / self.colorfulness;
        let chroma = colorfulness * mc_coef;
        self.saturation = saturation;
        self.colorfulness = colorfulness;
        self.chroma = chroma;
        self
    }

    fn set_hue(&mut self, hue: f32) -> &mut Self {
        self.hue = hue;
        self
    }
}
impl Cam16 {
    pub fn set_lightness_at_constant_colorfulness(&mut self, lightness: f32) -> &mut Self {
        let Q0 = self.brightness;
        let J0 = self.lightness;
        let jc0 = (J0 / 100.).sqrt();
        let jc1 = (lightness / 100.).sqrt();
        let f = jc1 / jc0;
        let Q1 = Q0 * f;
        self.lightness = lightness;
        self.brightness = Q1;
        self.saturation = 100. * (self.colorfulness / Q1).sqrt();
        self
    }
    pub fn set_saturation_at_constant_colorfulness(&mut self, saturation: f32) -> &mut Self {
        if saturation != self.saturation {
            assert!(self.lightness != 0. && saturation != 0.);
            let brightness = self.colorfulness / (saturation / 50.).powi(2);
            let jf = (self.lightness / 100.).sqrt();
            let f = self.brightness / jf;
            let lightness = (brightness / f).powi(2) * 100.;
            self.brightness = brightness;
            self.lightness = lightness;
            self.saturation = saturation;
        }
        self
    }
    pub fn set_colorfulness_at_constant_saturation(&mut self, colorfulness: f32) -> &mut Self {
        assert!(self.saturation != 0.);
        let mq = self.chroma / self.colorfulness;
        let chroma = mq * colorfulness;
        let brightness = colorfulness / (self.saturation / 50.).powi(2);
        let jf = (self.lightness / 100.).sqrt();
        let f = self.brightness / jf;
        let lightness = (brightness / f).powi(2) * 100.;
        self.lightness = lightness;
        self.brightness = brightness;
        self.chroma = chroma;
        self.colorfulness = colorfulness;
        self
    }
}
fn appearance_to_tristimulus<T: AbsoluteWhite>(
    J: f32,
    C: f32,
    h: f32,
    condition: &ViewingCondition,
) -> RelativeXYZ<T> {
    let h_rad = to_rad(h);
    let t = if C == 0. || J == 0. {
        0.
    } else {
        (C / ((J / 100.).sqrt() * (1.64 - 0.29f32.powf(condition.n)).powf(0.73))).powf(1. / 0.9)
    };
    let et = 0.25 * ((h_rad + 2.).cos() + 3.8);
    let A = condition.Aw * (J / 100.).powf(1. / (condition.c * condition.z));
    let p2 = A / condition.Nbb;
    //let p2 = A / condition.Nbb + 0.305;

    let p1 = (50_000. / 13. * condition.Nc * condition.Nbb) * et;
    let h_sin = h_rad.sin();
    let h_cos = h_rad.cos();
    let gamma = 23. * (p2 + 0.305) * t / (23. * p1 + 11. * t * h_cos + 108. * t * h_sin);
    let a = gamma * h_cos;
    let b = gamma * h_sin;
    //let (a, b) = if t == 0.0 {
    //    (0., 0.)
    //} else {
    //    let p1 = (50_000. / 13. * condition.Nc * condition.Nbb) * et / t;
    //    let p3 = 21. / 20.;
    //    let h_sin = h_rad.sin();
    //    let h_cos = h_rad.cos();
    //    if h_sin.abs() >= h_cos.abs() {
    //        let p4 = p1 / h_sin;
    //        let h_cotan = h_cos / h_sin;
    //        let b = p2 * (2. + p3) * (460. / 1403.)
    //            / (p4 + (2. + p3) * (220. / 1403.) * h_cotan - (27. / 1403.)
    //                + p3 * (6300. / 1403.));
    //        (b * h_cotan, b)
    //    } else {
    //        let p5 = p1 / h_cos;
    //        let h_tan = h_sin / h_cos;
    //        let a = p2 * (2. + p3) * (460. / 1403.)
    //            / (p5 + (2. + p3) * (220. / 1403.)
    //                - ((27. / 1403.) - p3 * (6300. / 1403.)) * h_tan);
    //        (a, a * h_tan)
    //    }
    //};
    let Ra = 460. / 1403. * p2 + 451. / 1403. * a + 288. / 1403. * b;
    let Ga = 460. / 1403. * p2 - 891. / 1403. * a - 261. / 1403. * b;
    let Ba = 460. / 1403. * p2 - 220. / 1403. * a - 6300. / 1403. * b;
    let C_rgb = vector![Ra, Ga, Ba].apply_into(|a| {
        let am = *a;
        //let am = *a - 0.1;
        let gc = (27.13 * am.abs() / (400. - am.abs())).clamp(0., f32::MAX);
        *a = am.signum() * 1. / condition.Fl * gc.powf(1. / 0.42);
    });

    let rgb = C_rgb.component_div(&condition.D_rgb);
    let xyz =
        RelativeXYZ::<Cam16ColorSpace>::from(TristimulusRgb::<Cam16ColorSpace>::from_vector(rgb));
    RelativeXYZ::from_vector(xyz.into_vector())
}

impl ColourAppearanceTransform for Cam16 {
    fn adaptation_to(adapting_field_luminance: f32, surround_relative_luminance: f32) -> f32 {
        let F = 0.8 + surround_relative_luminance / 2.;
        (F * (1. - (1. / 3.6) * ((-adapting_field_luminance - 42.) / 92.).exp())).clamp(0., 1.)
    }
    fn illuminant_transform_matrix(
        source_white: RelativeXYZ,
        target_white: RelativeXYZ,
        adaptation: f32,
    ) -> Matrix3<f32> {
        let e = RelativeXYZ::<Cam16ColorSpace>::from_chroma_relative_luminance(
            E::CHROMA,
            RELATIVE_TRISTIMULUS_SCALE,
        );

        let e_rgb: TristimulusRgb<_> = e.into();
        let w_source_rgb: TristimulusRgb<_> =
            source_white.cast_illuminant::<Cam16ColorSpace>().into();
        let w_target_rgb: TristimulusRgb<_> =
            target_white.cast_illuminant::<Cam16ColorSpace>().into();

        let mut delta_e_target = Matrix3::from_diagonal(
            &e_rgb
                .into_vector()
                .component_div(&w_target_rgb.into_vector()),
        );
        let mut delta_e_source = Matrix3::from_diagonal(
            &e_rgb
                .into_vector()
                .component_div(&w_source_rgb.into_vector()),
        );

        delta_e_target.apply(|v| *v = adaptation * *v + 1. - adaptation);
        delta_e_source.apply(|v| *v = adaptation * *v + 1. - adaptation);

        let delta_e_target_m1 = delta_e_target.try_inverse().unwrap();

        Cam16ColorSpace::linear_rgb_to_relative_xyz_matrix()
            * delta_e_target_m1
            * delta_e_source
            * Cam16ColorSpace::relative_xyz_to_linear_rgb_matrix()
    }
}
impl ColourAppearanceTransform for Cam16Jab {
    fn adaptation_to(adapting_field_luminance: f32, surround_relative_luminance: f32) -> f32 {
        Cam16::adaptation_to(adapting_field_luminance, surround_relative_luminance)
    }
    fn illuminant_transform_matrix(
        source_white: RelativeXYZ,
        target_white: RelativeXYZ,
        adaptation: f32,
    ) -> Matrix3<f32> {
        Cam16::illuminant_transform_matrix(source_white, target_white, adaptation)
    }
}
impl ColourAppearanceTransform for Cam16Hcl {
    fn adaptation_to(adapting_field_luminance: f32, surround_relative_luminance: f32) -> f32 {
        Cam16::adaptation_to(adapting_field_luminance, surround_relative_luminance)
    }
    fn illuminant_transform_matrix(
        source_white: RelativeXYZ,
        target_white: RelativeXYZ,
        adaptation: f32,
    ) -> Matrix3<f32> {
        Cam16::illuminant_transform_matrix(source_white, target_white, adaptation)
    }
}

impl WhitePoint for Cam16ColorSpace {
    type WhitePoint = E;
}
impl LinearColorSpacePrimaries for Cam16ColorSpace {
    const PRIMARY_RED: ChromaticityXy = ChromaticityXy {
        x: 0.83360,
        y: 0.17349,
    };
    const PRIMARY_GREEN: ChromaticityXy = ChromaticityXy {
        x: 2.3854,
        y: -1.4659,
    };
    const PRIMARY_BLUE: ChromaticityXy = ChromaticityXy {
        x: 0.53343,
        y: -0.00402,
    };
}
impl ColorModel for Cam16ColorSpace {
    type LinearColorSpacePrimaries = Self;
    #[allow(clippy::excessive_precision)]
    fn linear_rgb_to_relative_xyz_matrix() -> Matrix3<f32> {
        matrix![
            1.86206786, -1.01125463, 0.14918677;
            0.38752654, 0.62144744, -0.00897398;
            -0.01584150, -0.03412294, 1.04996444
        ]
    }
    #[allow(clippy::excessive_precision)]
    fn relative_xyz_to_linear_rgb_matrix() -> Matrix3<f32> {
        matrix![
            0.401288, 0.650173, -0.051461;
            -0.250268, 1.204414, 0.045854;
            -0.002079, 0.048952, 0.953127
        ]
        //Self::linear_rgb_to_relative_xyz_matrix()
        //    .try_inverse()
        //    .unwrap()
    }
}

impl From<SpecViewingCondition> for ViewingCondition {
    fn from(v: SpecViewingCondition) -> Self {
        let La = v.adapting_field_luminance;

        let F = 0.8 + v.surround_relative_luminance / 2.;
        let c = if F >= 0.9 {
            0.59 + (F - 0.9) * 10. * (0.69 - 0.59)
        } else {
            0.525 + (F - 0.8) * 10. * (0.69 - 0.525)
        };
        let Nc = F;

        let D = match v.chromatic_adaptation {
            ChromaticAdaptation::Full => 1.,
            ChromaticAdaptation::None => 0.,
            ChromaticAdaptation::Intermediate => {
                (F * (1. - (1. / 3.6) * ((-La - 42.) / 92.).exp())).clamp(0., 1.)
            }
        };

        let white_rgb: TristimulusRgb<Cam16ColorSpace> =
            RelativeXYZ::<Cam16ColorSpace>::from_vector(v.adopted_white.into_vector()).into();

        let Yw = v.adopted_white.y;

        let D_rgb = white_rgb
            .into_vector()
            .apply_into(|v| *v = D * 1. / *v + 1. - D);
        //.apply_into(|v| *v = D * Yw / *v + 1. - D);

        let k = 1. / (5. * La + 1.);
        let k4 = k.powi(4);
        let Fl = k4 * La + 0.1 * (1. - k4).powi(2) * (5. * La).cbrt();

        let n = v.background_relative_luminance / Yw;
        let z = 1.48 + n.sqrt();

        let Nbb = 0.725 * (1. / n).powf(0.2);
        //let Ncb = Nbb;

        let Wc_rgb = D_rgb.component_mul(&white_rgb.into_vector());

        let Aw_rgb = Wc_rgb.apply_into(|v| {
            let c = (Fl * *v).powf(0.42);
            *v = 400. * (c / (c + 27.13))
            //*v = 400. * (c / (c + 27.13)) + 0.1
        });
        let Aw = (2. * Aw_rgb.x + Aw_rgb.y + Aw_rgb.z / 20.) * Nbb;
        //let Aw = (2. * Aw_rgb.x + Aw_rgb.y + Aw_rgb.z / 20. - 0.305) * Nbb;

        Self {
            D_rgb,
            Fl,
            Nbb,
            Aw,
            c,
            z,
            Nc,
            n,
        }
    }
}

Hi! I'm happy to see that you are finding Palette useful. I still think CAM16 could be a nice addition, so it would be amazing if you are up for adapting this implementation. Keep in mind, though, that I haven't gotten around to read up on all the details yet. It's not my main field, so it will be more of a contributor driven feature. I will do my best to look into it along the way, but you'll be the expert and I'll probably have questions. Another alternative is of course to keep CAM16 separate and depend on Palette, if you prefer that.
The funny palette_internal attribute is just a marker that tells the derive macros that they should look for Palette types under crate::, instead of palette::, so it's mostly relevant for color space types. A more general thing to keep in mind is that the code should be generic over the number type and avoid Copy, if possible. Ideally also allow SIMD types. You can take it one bit at the time, since it can turn a bit ugly with all the traits. The SIMD part is extra credits at the moment, since it's still a bit experimental. I think this code will be pretty straight forward to SIMD convert, though, since it doesn't seem to have a lot of complex branches and loops.

Ok, I'll try to implement it. How do we do? I have never worked with GitHub collaboratively. I have forked your repo. Should I push changes to the forked repo and inform you here about the changes here?

No worries! You will be able to open a pull request here once you have pushed something to your fork. Don't hesitate to push and open a PR for a work in progress if you want feedback or help along the way.

What about caching the rgb_to_xyz matrix and its inverse in the trait Primaries? This will dramatically increase conversion performance.
It would be implemented as trait methods whose default implementation call functions of the module num.

That would be a very nice way of doing it! I have wanted something like this for a while but not decided on how. I think this is a good starting point.


Merge branch 1.5.x to master

There are multiple fixes in Branch 1.5 which I merged into the master (plus fixing optional dependency to guava):

Compile Error with JDK5:
ma.glasnost.orika.impl.generator.VariableRef line 56 contains the call Collections.newSetFromMap(..,) which only exists since 1.6:
https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#newSetFromMap(java.util.Map)
I simply updated the maven-compiler-plugin in the pom.xml line 315&316 to 1.6 (because there is no open jdk-5 issue obviously no-one use orika with jdk5):
https://github.com/brabenetz/orika/commit/c360935c779aba80cb9e02e0522eaa017eaf1a30

Eclipse Settings folder ".settings" removed:
most likely committed accidentally.

Travis-CI:
I'm not sure what the difference of the Travis-CI instances are, but I suppose that my instance is a newer container-based instance:
My Travis-CI instance: https://travis-ci.org/brabenetz/orika/builds
Orikas Travis-CI instance: https://travis-ci.org/orika-mapper/orika/builds
The Results often differ in the results.
At least for the container-based Travis-CI the following changes are required:

limit maven-surefire-plugin in memory: because the container based Travis-CI has only 3 GB ram which is less then the default VM. And some Memory-Consumption-Tests fills the memory with garbage to force the release of weak references.
set "sudo: false" in ".travis.yml" because container based Travice-CI doesn't allow sudo.

I also added openjdk6 to the build.

Fix Optional dependency to Guava:
ma.glasnost.orika.metadata.Type and ma.glasnost.orika.impl.DefaultConcreteTypeMap uses the guva class ImmutableMap which make Guava not optional anymore.
I refactored it with Collections.unmodifiableSet(...) and Collections.unmodifiableMap(...).
The dependency commes in with the last merge of #157 and #155:
https://github.com/orika-mapper/orika/pull/155
https://github.com/orika-mapper/orika/pull/157

TypeFactory.refineBounds(...) line 388:
The old code contained two iteratores of one collections which produced under wired circumstances concurrent mocification Exception.
Tests for the new codes where added in TypeFactoryTestCase.

Sub-Project "tests-jdk8":
Special JDK8 Tests. e.g. with Interface default methods.
This tests also failed because of the non-optional guava-dependency.

It makes sense support java 6, which has reached the support's end more than 3 years ago?
For the rest I'm in agreement with the whole pull request (sorry for the guava issue, I saw it into dependencies and I though it was not a problem to use it :) )

No Problem, that could happened to anybody.
I only recognized it by the additional sub-project for special jdk8-tests.
I only updated the compiler-plugin from jdk 1.5 to 1.6.
For me, jdk 7 would be also valid (I simply didn't had the guts to do that jump :D ).

Anyway, what could be that error on travis' jdk6 build?
I tried to take a look but with no success

I have no clue, because I cannot reproduce it locally nor on my Travis-CI instance:
https://travis-ci.org/brabenetz/orika/builds/177276275

Is it possible to update the orika travis-ci instance to a container-based instance?
If nothing can fix the jdk6 build, the easiest way would be a fixation on minimum JDK7 version.
Only maven-compiler-plugin and travis.yml should be required to update for this.

I'm trying to compare the raw logs, and on orika travis-ci log:
"This job is running on container-based infrastructure"

I can't find significant differences in the logs between them...

You are right.
The test seems to be stuck in MultiThreadedTestCase.
Maybe it has something to do with #147
But this are only assumptions because I cannot reproduce it locally.

I tried too, but without success...
I suggest to remove jdk6 from .travis and then merge this request, so we can go with 1.5.0 release.
Just for interest, the jdk6 was removed from the CI 4 years ago for some problems:
https://github.com/orika-mapper/orika/commit/e1415f51ac0bea0c776585514ce43611f9f35ccb

I fully agree with you.
Nice work to find the commend 4 years ago.

I will remove the jdk6 travis-ci build and provide a new pull request.

If I remove the JDK6 travis-ci build, then I will add the animal-sniffer-maven-plugin to validate that no newer API as available in JDK6 is used (e.g.: the use of StandardCharsets.UTF_8 must fail, because it doesn't exist in JDK-6 ).

Ok for me.


feat(split-button): DLT-1819 vue3 version

Split button - Vue 3
Obligatory GIF (super important!)

:hammer_and_wrench: Type Of Change
These types will increment the version number on release:

[x] Feature

:book: Jira Ticket
https://dialpad.atlassian.net/browse/DLT-1819
:book: Description

Vue 3 version of #420
Added examples to documentation

:bulb: Context
Documentation of this component was waiting for the vue 3 version to be ready to be able to create examples.
:pencil: Checklist
For all PRs:

[x] I have ensured no private Dialpad links or info are in the code or pull request description (Dialtone is a public repo!).
[x] I have reviewed my changes.
[x] I have added all relevant documentation.

For all Vue changes:

[x] I have made my changes in Vue 2 and Vue 3. Note: you may sync your changes from Vue 2 to Vue 3 (or vice versa) using the ./scripts/dialtone-vue-sync.sh script. Read docs here: Dialtone Vue Sync Script

:crystal_ball: Next Steps

Add missing content @francisrupert, @fede-dp can you help me with that please? Added the examples but don't know what to add related to more complete component descriptions and information.

:camera: Screenshots / GIFs

https://dialtone.dialpad.com/deploy-previews/pr-438/components/split-button.html
https://dialtone.dialpad.com/vue3/deploy-previews/pr-438/?path=/story/components-split-button--default
https://dialtone.dialpad.com/vue3/deploy-previews/pr-438/?path=/story/components-split-button--variants

Added no-visual-test tag as the base is the Francis branch so all the snapshots are going to be "new".
Will run visual tests on #373 once this one is merged.


Fix component test fragility on Travis CI due to timing issues

Codecov Report

Merging #55 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #55   +/-   ##
=========================================
  Coverage     99.11%   99.11%
  Complexity      617      617
=========================================
  Files            44       44
  Lines          1461     1461
  Branches        161      161
=========================================
  Hits           1448     1448
  Misses            4        4
  Partials          9        9

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2620f0c...09ddea9. Read the comment docs.