Fix a misleading point in the guide with generic type aliases for functions

There's nothing really blocking type aliases for functions for being generic themselves, and the alternative (the right way) to do this was never presented in the guide.
I've fixed 03-getting-started/-9multiple-generic-types.md, but not the rest. You have permission to edit this PR, so feel free to take over from here!

Ooo, using a type definition to define a generic function is slick!
I thought the proposal said generic func defs were unsupported, and when I tried it seemed to confirm this.
Did I just get the syntax wrong? Have you tested yours?

@akutz https://gotipplay.golang.org/p/3Xlrpb4_ncG
I think the syntax was wrong yeah. Although, I feel like there is a subtle difference between the two. But I think in this case, they were aiming to do the same thing?

Yeah, definitely attempting the same. Am I imagining the note about generic function defs not being supported?

I think you're referencing https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods
So I dont think you're imagining it, just that it's talking about something slightly different? I can't tell though, the language in this is so dense.

I think you're referencing https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods
So I dont think you're imagining it, just that it's talking about something slightly different? I can't tell though, the language in this is so dense.

Yep, that's it! I am mobile at the moment, so I will update this when I get home.
Yep, I definitely misunderstood this, and my wrong syntax only strengthened my invalid conclusion.
Thanks again for catching this!

dense

Agreed. That was part of the reason for this repo. I was trying to break things down more cleanly, into smaller, bite-sized chunks.

FYI, I have not forgot about this. I just want to merge it with a fix for the other locations/examples/etc. all at once. Right now everything is inconsistent together. I do not want some fixed and some not because then it is even more confusing. I was focused first on 1c3fe10e6824d4a7a670ed584fb51015d13293e3, which was not small...

Sounds good to me, I got lazy and didn't go and update everything 😅

Thank you @aaomidi , your commit, along with the follow-up, is now merged. I do not know why it closed this PR instead of showing it as merged. I kept your commit intact -- https://github.com/akutz/go-generics-the-hard-way/commit/0f78907ff091f3de6c115bce6393943f7a0d13d1.  Weird.


Particle System - Hair with Object/Group render

I have a scene with an hair system set to "Group", in the viewport it works without problems but when I try to render, the mesh generated by the hair system doesn't gets rendered
I tried with "Object", same problem... in "Path" mode, it gets rendered :(
Is this not supported by PRMan-for-Blender? or I am doing something wrong?
hair-problem.zip

I'll take a look at this tomorrow. Thank you for providing an example scene.

I think I found the issue. I should have time to fix it tomorrow. Thank you for your patience.

Fixed.

Fixed.

https://github.com/bsavery/PRMan-for-Blender/commit/1791bc5b4d0261cc78c829e938b5898f7c231423

https://github.com/bsavery/PRMan-for-Blender/commit/1791bc5b4d0261cc78c829e938b5898f7c231423


Release v0.5.1-alpha1

Closes: https://github.com/docker/dev-tooling-team/issues/2

Closing because the release could be tested in without having to release a version just for it


Graphical upgrade

After the great presentation of @kinow showing the Cylc GUI, I noticed some desire from the team to have a more friendly and aesthetic GUI.
So, I took a little time to mock up a better Home page style to start the discussion about the importance of making an upgrade to the GUI soon.

@mcastril what do you think about this? I know that this is not a priority nowadays, but might be relevant sooner or later.

In GitLab by @kinow on Nov 22, 2023, 11:03

Upgrade from normal CSS to SASS for better stylesheet organization.

+1 :100:

Changes in the UI library. We can stay using Bootstrap 4.6.0 or upgrade it to a newer version like 5.3. Also, we can change to a highly customizable UI library like Tailwind CSS.

:thumbsup: we adopted a Material library in Cylc, but in hindsight that was not the best choice, because when we had to upgrade Vue2 to Vue3 that library blocked for >1 year the upgrade. I don't think that applies to React libraries (faster development).
Said that, the library still helped a lot to speed up our development, instead of relying on Bootstrap or pure CSS.

Consider changing graphical libraries like the one used for the graph view vis-network to a more customizable one like React Flow.

React Flow looks amazing. We just need to make sure its features cover everything that we have (or that we want to have). But the look and feel and docs look really good.

removed 2 designs

In GitLab by @kinow on Nov 23, 2023, 10:38

IMO if we want general faster development, Bootstrap is the way. But if we need high out-of-the-box customization, Tailwind will do better.

:thumbsup: agreed, and I trust to make the best choice here! :medal:

added 2 designs

:thumbsup: we adopted a Material library in Cylc, but in hindsight that was not the best choice, because when we had to upgrade Vue2 to Vue3 that library blocked for >1 year the upgrade. I don't think that applies to React libraries (faster development).

That's good to know! I don't think there will be a block if we avoid using UI React component libraries.
In this case, Bootstrap and Tailwind can be used with just HTML, CSS, and Javascript.
Bootstrap does include some style classes and functions to implement common components, but sometimes they are difficult to customize.
On the other hand, Tailwind has many customizable styling class options without dealing too much with CSS. Also, it gives plenty of "recipes" to deal with common things with a lot of flexibility, but some of them need to add dependencies for the functional side.
IMO if we want general faster development, Bootstrap is the way. But if we need high out-of-the-box customization, Tailwind will do better.

Additional things to consider for the graphical upgrade:

Upgrade from normal CSS to SASS for better stylesheet organization.
Changes in the UI library. We can stay using Bootstrap 4.6.0 or upgrade it to a newer version like 5.3. Also, we can change to a highly customizable UI library like Tailwind CSS.
Consider changing graphical libraries like the one used for the graph view vis-network to a more customizable one like React Flow.

As discussed, one way to validate these mockups is by sending a poll to a group of users. I'm thinking of adding these questions to focus on usability and feedback:

What are your initial thoughts or feelings about the design?
Is the navigation intuitive? Can you easily find what you're looking for? Are there any elements that are confusing or difficult to understand?
What specific changes would you recommend to enhance the user experience?
Are there any additional features or functionalities you'd like to see?

As suggested by @mcastril, we could contact Eric and Gilbert to build this group of users, or send this poll to a mailing list.

added 4 designs

updated 1 design

As part of the Graphical Upgrade taking into account issue #92 and the new API route distribution, I have listed the tasks to do:

[x] Node version updated to lts/iron
[x] Dependencies updated to their latest version using npm-check-updates
[x] Migration from CSS to Sass
[x] Migrate CDN dependencies (bootstrap, fancytree, vis-network, fontawesome) to their bundled ones
[x] Include Redux Toolkit for better state management
[x] Include RTK Query for better API calling (with cache and polling) and support v3 and v4 API
[x] Update authentication handler
[x] Migrate Home View
[x] Migrate Summary Modal -> Table View
[x] Migrate Quick View
[x] Migrate Tree View
[x] Migrate Monitor Tree
[x] Migrate select historical run in Tree View
[x] Migrate Job Selection (?)
[x] Migrate Graph Standard View
[x] Migrate Selection helpers (status, wrappers) in Graph View
[ ] Migrate Graph extra views (?)
[x] Migrate Monitor Graph
[x] Migrate Run Log View
[x] Migrate Configuration View
[x] Migrate Statistics View
[x] Migrate Performance View

In GitLab by @mcastril on Jan 2, 2024, 18:58
These are good questions Luiggi.
We have a couple of persons with expertise in UX/UI in BSC-ES. We could ask them about their opinion concerning these questions.
Yes, contact Eric and Gilbert as soon as possible. I understand that you don't need a full upgrade (the list of tasks below) before the session, just a few pages. Otherwise, in case the users asked for major changes you would have saved time.

mentioned in commit 274a9b684e2049e86f583a85ef0b14edd8d9be65

added 1 design

added 1 design

In GitLab by @kinow on Jan 12, 2024, 12:27
Sounds good, @LuiggiTenorioK ! Maybe we can add a few small improvements adapting features from Cylc or ecFlow's UI. But I think you will probably have a lot to address just with the new layout :slight_smile: Let's see how much work that will require, and maybe add a few other improvements (some may not require user feedback, e.g. use a websocket instead of polling every N seconds).

Here is a summary of the form that was submitted last week (5 out of 12 responses):

Users liked the "modern" style of the new design
Users find it intuitive and easy to use
They feel it preserves the "old" setup, so they don't feel they have to learn something new
The new design has too many dark colors. Contrast adjustments are highly suggested by the users.
"Select previous runs" button was missing and seems to be an important feature
Apart from the new design they asked for improvements to visualize big experiments
Also, they asked about "setstatus" buttons which are aligned with our work for EDITO
Improve visualization of wrappers (and their status) and retries
A button to watch just your experiments on the homepage
Also: https://earth.bsc.es/gitlab/es/autosubmitreact/-/issues/69

CSV: Autosubmit_GUI_Update.csv

mentioned in commit 2e152ea2f145b1df1ce7d470ed17c67e4ae01cfd

updated 1 design

updated 6 designs

added 1 design

@mcastril After talking with Eric and Gilbert about relevant users of the Autosubmit GUI we got the following possible users to validate the designs:
In AC:

Montse Costa
Luka Ilic

In CES:

Gilbert Montané
Eric Ferrer
Miriam Olid
Alejandro Garcia

In CVC:

Valentina Sicardi
Aude Carreric

Also, it will be good to include some people from Destination Earth:

Aina Gaya
Francesc Roura
Leo Arriola

Now I have some inquiries on how to handle this validation. Instead of having a session with everyone, I think it will be better to start with a form sent to everyone asking for feedback (with the questions set above). Then, with this initial feedback, make an interactive mockup in Figma (or complete the implementation (?) ). Afterwards, it would be better to have small sessions (15-30min) with small groups (2-3), so the users can have more freedom to share their opinions.
@kinow what do you think? Maybe we can add some things done in Cylc :eyes:

In GitLab by @kinow on Jan 18, 2024, 10:34
Feedback from AS meeting today:
@dbeltrankyl: maybe make the boxes smaller, use two different ways to display it (list/table)
@kinow: I like big fonts, it doesn't render well on my viewport/browser

updated 1 design

In GitLab by @mcastril on Jan 12, 2024, 16:41
Thanks @LuiggiTenorioK, for sharing the list. From AC, you could also involve Rubén Sousse, who is always running different experiments.
Send a form beforehand if you consider it a useful source of information. I thing it would be.
About Figma and completing the implementation, maybe there is a compromise solution that does not represent an overhead and allows us to re-use most of the work. For example, leaving a few sections uncomplete. The most important ones for the users are the search view and tree view, and later the quick view and the graph view.
If you want to do it in small groups, I agree but I wouldn't split them so much. Maybe one session with AC and CVC and another one with CES (including DE).
Finally, I would leave the suggestions for new features noted so that we can evaluate them together and create issues. In any case, it would be work for later. After the graphical upgrade, we should go first for the deployment in Climate DT and the write-mode endpints.
Thanks for this work

I remember Cristian recommended a move to Tailwind before leaving. But it's worth to consider staying in Bootstrap and upgrade.

Yes, to do the upgrade faster I did have to stay with Bootstrap (and extend it a little more with Sass). Still, Bootstrap is way more limited in customization than using Tailwind with a compatible component library like Radix. So, we might consider migrating it in the future.

After this upgrade, I considered creating a new repo for this new GUI. This is mainly, to keep the old issue list of the old GUI here because they will mostly not apply to the new one. Also, we can take the opportunity to rename it from autosubmitreact.
@mcastril WDYT?

Agree! For me is better to keep this repo. The only fallbacks that I think I'll have is to manage the issues list between the old and new GUI, and if there were another additional reason why this repo is private (sensitive data maybe? but I remember this was not the case).

In GitLab by @kinow on Feb 1, 2024, 12:13
Wouldn't it be easier to keep using this repo, so that we can link issues/commits, and - more importantly - the Git history? +1 to renaming it though :100: !

In GitLab by @mcastril on Jan 31, 2024, 18:06
I remember Cristian recommended a move to Tailwind before leaving. But it's worth to consider staying in Bootstrap and upgrade.

React Flow looks amazing. We just need to make sure its features cover everything that we have (or that we want to have). But the look and feel and docs look really good.

I agree with Bruno. Maybe you have already seen that, the Graph display is a delicate one. In the first versions of the GUI, the elements were not positioned as we liked (following the chunk order, in rows and spatiated as we used to). At some point, I think that Wilmer had to take the coordinates of the nodes generated by Graphviz in Autosubmit to provide them to the graph library used in the GUI.
The other issue was the rendering of bigger graphs, which were taking much time. For that reason, he created a worker (populate_graph.py) to generate and extract these coordinates offline.
I don't know if this workflow is compatible with React Flow and if that's more performant. Just things to take into account.

About the missing issues:

Improve visualization of wrappers (and their status) and retries: #41 #68 are more or less related
A button to watch just your experiments on the homepage: No issue related but can be done easily with the new endpoints but we have to improve the synchronization with the DDBBs
Improvements to visualize big experiments: The suggestion here was to limit the number of items in the tree view but the current job filter should work fine IMO because the jobs are already grouped. Not sure if this could be an issue. We might want to have more feedback about this in the further small sessions.

In GitLab by @mcastril on Jan 31, 2024, 18:17
Thanks a lot, Luiggi, for taking the initiative, for holding the session, and for providing the answers summarized here!
Sorry for my delay catching up with this. Last week we had a deadline for submitting a National Project (prepared by CES).
I wonder what they really meant with the setstatus helper. There is a "helper" already (CHANGE STATUS), that prints (and copies in the clipboard) a setstatus command that the user can directly type in the command-line. I don't know if the user was aware of this feature. But if you were there, maybe you are more certain that they really wanted to have the action button.
Regarding the size of the boxes, that was also my opinion. The current setup could work well in a tablet or phone thoug, but on bigger screens, we should show more experiments.
Concerning the loading time, it's true for bigger workloads. The filter only works after everything is loaded.
About improving the visualization for big experiments, we started to work on that with the group buttons in the Graph. In the tree, they are already grouped and there is a filter as you are saying.

In GitLab by @kinow on Jan 22, 2024, 10:37
Great feedback, thanks for summarizing it, @LuiggiTenorioK. And kudos for keeping the old setup. I think that will really help existing users.
I think most of the items can be fixed in this issue. #69 is for the performance metrics, the setstatus I think depends on https://earth.bsc.es/gitlab/es/autosubmit_api/-/issues/55.
Do we have issues already for “Improve visualization of wrappers (and their status) and retries”, ”A button to watch just your experiments on the homepage”, and for “Apart from the new design they asked for improvements to visualize big experiments”?

In GitLab by @mcastril on Feb 2, 2024, 17:48
I am also in favor of keeping this repository. As Bruno said, you can close issues that are not valid anymore (commenting that they were fixed in the new release) and keep the other ones.
If we were going to maintain both versions I would say that you can create labels for v3 and v4, but I don't think this is going to be the case.
Regarding the project path, it can be renamed when we decide.
And regarding the public repo, it's as Bruno said.

Actually, I think this is a very good idea. Why not use one of the next MWT meetings (the non-reporting ones) to showcase the GUI and ask people for feedback? You could complement it with the sharing of the form, before or after.

It will be fun to do it that way. As a disclaimer, it might not be a presentation, instead, it will be an interactive session where we will ask people to do some tasks with the GUI and ask for feedback immediately. I'll add it to the backlog.

So, do you mean adding the tasks to be changed in an overlay instead of just selecting them?

Yes, it is not so different from how the "ACTIVATE SELECTION MODE" button works in the old GUI.

When do you plan to have this session?

I wanted to do it after deploying it publicly to the CES members so they have enough time to try it before the session. But now, it seems quicker to send a form like the last time than to look for a free spot from everyone. Maybe the form can be shared in the next MWT meeting to get the attention of everyone. WDYT?

The first one shouldn't be an option. Different users from the scientific groups said that this one was very helpful. Even if we allowed the status to be changed directly with the GUI, it would still be a nice help for the CLI.

Yes, I got that feedback from some Climate DT people already. I was thinking of implementing it as a shopping cart like in UniProt (people from life sciences will love it) so it can be easily extended to have multiple features.

As said through Slack, I think that the experiment's detailed view should either have a button or be accessed by clicking on any part of the card. Using only the header is not intuitive, in my opinion. Title bars are normally used for dragging.

Yes, that is on the to do list for the next version. The only fallback I see is that the user will not be able to select and copy text inside the card easily but this seems meaningless.

mentioned in issue digital-twins/de_340/project_management#534

In GitLab by @mcastril on Mar 19, 2024, 17:16

I wanted to do it after deploying it publicly to the CES members so they have enough time to try it before the session. But now, it seems quicker to send a form like the last time than to look for a free spot from everyone. Maybe the form can be shared in the next MWT meeting to get the attention of everyone. WDYT?

Actually, I think this is a very good idea. Why not use one of the next MWT meetings (the non-reporting ones) to showcase the GUI and ask people for feedback? You could complement it with the sharing of the form, before or after.
There are some presentations/sessions in the backlog, but I don't think that they have any objection to letting you a spot in the next weeks: https://trello.com/c/991ldOUj/164-models-workflows-team

Yes, I got that feedback from some Climate DT people already. I was thinking of implementing it as a shopping cart like in UniProt (people from life sciences will love it) so it can be easily extended to have multiple features.

So, do you mean adding the tasks to be changed in an overlay instead of just selecting them?

Yes, that is on the to do list for the next version. The only fallback I see is that the user will not be able to select and copy text inside the card easily but this seems meaningless.

I see. Well, maybe you can leave a part of the card as non-clickable (the part of the text) using another colour and some kind of border. You'd have to test it to see if it's fine

In GitLab by @mcastril on Mar 19, 2024, 16:24
@LuiggiTenorioK, thanks for deploying the new GUI, it looks very nice.
When do you plan to have this session?
Regarding the questions:

Do you need the job "change status" command generator? Do you need to select multiple jobs in it? Do you need another command to be generated?

The first one shouldn't be an option. Different users from the scientific groups said that this one was very helpful. Even if we allowed the status to be changed directly with the GUI, it would still be a nice help for the CLI.
As said through Slack, I think that the experiment's detailed view should either have a button or be accessed by clicking on any part of the card. Using only the header is not intuitive, in my opinion. Title bars are normally used for dragging.

I'm preparing the first hands-on session to validate the new GUI using the already developed and deployed in our development environment (https://bscesautosubmitdev01.bsc.es/autosubmitGUI). This will be a 30-minute (or maybe more?) session with the people of MWT and DE:

Aina Gaya
Francesc Roura
Leo Arriola
Gilbert Montané
Eric Ferrer
Miriam Olid
Alejandro Garcia

Then, the following questions will be set for this session:

What are your initial thoughts? Do you like it? It is easy to use?
How do you feel about the color palette? Do you want a dark mode?
Do you need other "order by" options on the home page?
Do you need the other views in the experiment graph? Any suggestion to improve visualization?
Do you need the job "change status" command generator? Do you need to select multiple jobs in it? Do you need another command to be generated?
Any additional suggestions?

After this session, the next step will be to focus on the suggestions of the DE people aiming to be the ones that will first use it.
Consequently, in ES, we can also deploy the new GUI in parallel like it is the development environment. But to do that we have to request the BSC CAS maintainers add the service names to the CAS whitelist. In this case, add https://earth.bsc.es/autosubmitGUI and https://bscesautosubmitdev01.bsc.es/autosubmitGUI. Is that possible @mcastril?

In GitLab by @kinow on Feb 1, 2024, 13:23
If there are things that are not valid anymore, we can close it as won't fix, or add a label that it needs discussion/etc.
As for being private, I think it was only until we made it portable, and had reviewed it to make sure there were no security issues. I don't believe we have any passwords or sensitive information here (we always kept destine/edito/etc. info on issues in those projects' repositories).

Most of the requirements gathered in the testing session are resolved by now.
So, I gathered the remaining ones and assigned an effort/priority estimation here:
(@mcastril what do you think about the priority estimations?)

Requirement
Observations
Effort
Priority

Have a public documentation (Read The Docs)
Done! :white_check_mark:
Mid
High

Migrate status and date-member graph views

Mid
Mid

Add order by total jobs
Require API changes to DDBB
High
Mid

Add order by # of chunks
Require API changes to DDBB
High
Mid

Generalize performance metrics to other job sections
Deep API refactor
High
Low

Retrieve storage usage per experiment
Require API changes
Mid
Low

Filter only differences in configuration view
Improve current logic in API
Mid
Low

Add advanced search
Require API changes and will add maintenance cost
High
Low

Add an “experiment overview” page
Must be defined first
?
?

The strategy that I suggest is to complete the documentation requirement (first one) and release the official v4.0.0 release for public use. The other requirements will be moved for future releases depending on the needs of our users.

A quick debrief of the user testing session of today:

[x] Add a warning to the Home search suggesting to disable the "Only active" option
[x] Rename "Created (asc/desc)" with something more descriptive like Newest/Latest
[ ] Add order by total jobs or # of chunks
[x] Filter by AS version
[ ] Retrieve storage usage of the experiment (If it is possible)
[ ] Add an "Advanced search" with AND/OR operators
[x] Test GUI with big screens
[x] Modify page size in experiment search
[x] Add project/branch information
[ ] Checking the last run was not intuitive. Might add some documentation on how to do it.
[x] Selecting multiple jobs was not intuitive in the tree/graph view. Add some helping text.
[x] Job detail panel collides with the job basket in smaller screens. Reduce the initial size of the job detail panel. Could be expandable.
[x] Job basket selected jobs should be highlighted in the tree
[x] Go back to the default tree view after expanding or collapsing all
[x] In Graph, add a button to change the status of multiple selected nodes (like the old GUI). The job basket could be used here but should be synced with what is currently selected and highlighted.
[x] Add a job history button (like the old GUI)
[x] Show a legend in the graph view (select by status works like a legend)
[x] Add a status filter. It could iterate through the results by continuously clicking it.
[x] Add a message on the top of the configuration view when there is a difference and explain what the tooltip means.
[ ] Add a filter to just show the differences in the configuration view
[ ] It might be good to have an "Experiment overview" section. Might iterate again with the users to see what could be inside.
[ ] Generalize performance metrics to be calculated not only for SIM jobs and could be used for other job sections.

Thanks @mcastril for the notes :raised_hands:

In GitLab by @mcastril on Mar 19, 2024, 17:34

It will be fun to do it that way. As a disclaimer, it might not be a presentation, instead, it will be an interactive session where we will ask people to do some tasks with the GUI and ask for feedback immediately. I'll add it to the backlog.

I like the idea. You can use the format that you think it'll work best, but this one sounds like a nice team activity.


System.CommandLine - Add overload to store value to object properties

syntax.DefineOption and other similar methods require a ref argument to store the parsed value:
DefineOption(string name, ref bool value, bool requireValue, string help);
This makes it harder than it should to store the parsed option to an object property. E.g. the following is impossible:
syntax.DefineOption("v|verbose", ref _optionsGlobal.IsVerbose);
One solution is to use a local variable, which is cumbersome.
What could be better is to provide an overload where the value can be stored via an anonymous function, something like:
syntax.DefineOption("v|verbose", value => _optionsGlobal.IsVerbose = value);

I don't seem to have any trouble storing to an object property:
https://github.com/Wyamio/Wyam/blob/develop/src/clients/Wyam/Commands/BuildCommand.cs#L67
Not saying that this wouldn't make for a good enhancement generally, just that I'm wondering why you're having trouble with this specific use case...

@daveaglick I'm quite new to .net but I believe the explanation is that you are not using public fields (without getters and setters): https://github.com/Wyamio/Wyam/blob/develop/src/clients/Wyam/Commands/ConfigOptions.cs
If you did, you wouldn't be able to use the "ref" keyword: https://stackoverflow.com/a/1403036/184404
Also, I'm using properties as fields are not allowed in an Interface: https://stackoverflow.com/a/5698494/184404
Does that make sense ?

@jonjbar Ah, of course - that's a total brain fart on my part. Properties won't work because they're just syntactic sugar for getter and/or setter methods which obviously can't be passed by ref. I typically name fields with an _ prefix but named these ones like properties for this very reason.

Well, to give @daveaglick a little credit, you can make this work with properties:
    class Program
    {
        public bool _isVerbose;
        public ref bool IsVerbose
        {
            get
            {
                return ref _isVerbose;
            }
        }

        void Foo()
        {
            ArgumentSyntax syntax = null;
            syntax.DefineOption("v|verbose", ref IsVerbose, true, "Is verbose, duh.");
        }

        static void Main()
        {
        }
    }

But yeah, ref properties are probably not the solution here. An overload that takes Action<T> is probably cleaner.

@vcsjones Don't give me too much credit - I had no idea you could use C# 7 ref returns for properties like this. That's super cool.


prost-build triggers rebuild on arbitrary file change

Hello
Let's say I have some rust project and have done cargo build. Now I touch an arbitrary file around there, eg touch x. If I run cargo build now, it is very fast and mostly figures out it doesn't need to do anything.
However, this changes if I introduce prost-build into the project. Now the cargo build will rebuild the whole crate (and all the tests and other things if it is not cargo build but eg. cargo test --all).
My guess is, this has something to do with the fact that the file change provokes build.rs to be re-run. That one, in turn, overwrites the rs files generated from protobufs, which triggers the rebuild (even though the produced files are the same).
If my guess is correct, would it make sense to generate them to some temporary file first (eg. generated_file.rs.tmp), compare with the previous version (if present) and then move it into place only if it differs?

Hmm. That workaround doesn't seem to help :-(, must be something else.

It seems like it's worth documenting this at the very least. AFAICT setting it has caused no problems for me (it's not like cargo no longer detects changes in src/blah.rs after setting it).
Not sure what you mean by it changes the crate root though.

I was referring to the link to the todo comment above.

Sorry got my bug numbers wrong - it actually fixes #231 - not sure if it fixes this.

Shouldn't this solve the issue?
    println!("cargo:rerun-if-changed=proto/schema.proto");
    prost_build::compile_protos(&["proto/schema.proto"], &["proto/"]).unwrap();

Shouldn't this solve the issue?

I think it should.  I'd support adding an option to prost_build::Config to do that for each argument to compile_protos.  It maybe should even be enabled by default.  Would love if someone with more Cargo expertise could weigh in here, since I suspect there are subtleties at play.


Autocomplete value from datasource instead text

If you have a data source like
const dataSource =[{text: "This is text 1", value: 1}, {text: "This is text 2", value: 2}]
The value selected in the JSON is always text field and not value

Closing this due to inactivity. please feel free to re-open if issue still persist.


updating doc to reflect Muse working on Linux without a dongle

muse-lsl does seem to work on Linux without a dongle using this workaround: https://github.com/alexandrebarachant/muse-lsl/pull/141 This PR modifies the documentation to reflect this.
We should probably wait for https://github.com/alexandrebarachant/muse-lsl/pull/141 to be merged, or another solution to be found, before merging this PR.

I see your editor has applied the same whitespace fixes mine did (that I had surgically tried to avoid committing for my own PRs to keep the diff clean laughing), so I welcome this change! (and wouldn't mind if you could give your two cents on #30)

Oops, I should have been more careful... Ultimately I guess it's probably the way to go though. WIll take a look at #30 !


Swipe motion on suggestions makes switching between suggesters hard

Swiping on suggested songs currently triggers the favorite/remove functions, which makes it almost impossible to swipe between suggester pages.

I'm aware of the issue, not sure how to fix it best though. My best idea is to add an delete button and remove the favorite action. I think more than one button will make it look much to crowded.
Other options like double taps or long press are possible but then the controls are too inconsistent between sections.

Third option would be a context menu. Also the search should have the same issue with one action less so maybe less present.

I think it would be a-ok to limit the favorite action to songs in the queue/currently playing.
As for the remove action: a remove button is probably the most obvious way to show the users about that feature, so I'm all for it.
Regarding consistency: I think adding a song from the favorites tab should probably work by tapping it instead of swiping it.


2 ways to represent "amino acid editing activity"

see image

D- aminoacyl-tRNA deacylase activity is_a aminoacyl-tRNA editing activity
@hdrabkin  do these need to merge?
V

I can see how adding the link GO:0051499 is_a GO:0002161 would make sense, but I don't see why any terms would merge. GO:0051499 is specific for D-amino acids, whereas GO:0002161 is not.

OK also there might be other mechanisms..
so just add parent...

So action is
D-aminoacyl-tRNA deacylase activity
add parent
is_a aminoacyl-tRNA editing activity
@hdrabkin

done


Add chrF(++) Metric Card

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Building Package from fresh - errors

Thumbs up on all of this...  just in case you don't know, a fresh run of your installation instructions results in these errors (at least for me.)
PointFreeCo Build Errors.rtfd.zip
Thanks!

Ah! Yeah we haven't updated since we got database stuff going. Getting up-and-running may be as simple as installing PostgreSQL (via brew install postgres), though we'll have to take a deeper look soon.


update commandLineArgs example

commandLineArgs used to take an optional argv array as its second parameter.
Now it takes an optional options object with an optional argv property instead.
This change updates the usage example to reflect that change.

cheers mate 👍


Setting colormap to None after material has been rendered results in error

Reproducer
import imageio.v3 as iio
import pygfx as gfx
from imgui_bundle import imgui
from wgpu.gui.auto import WgpuCanvas, run
from wgpu.utils.imgui import ImguiRenderer

scene = gfx.Scene()
canvas = WgpuCanvas(size=(800, 600), title="Set cmap to None")
renderer = gfx.renderers.WgpuRenderer(canvas)
camera = gfx.PerspectiveCamera(0)
camera.local.scale_y = -1
controller = gfx.PanZoomController(camera, register_events=renderer)

image = iio.imread("imageio:astronaut.png")[:, :, 0]

texture = gfx.Texture(image, dim=2)
geometry = gfx.Geometry(grid=texture)
material = gfx.ImageBasicMaterial(clim=(0, 255), pick_write=True)
gfx_image = gfx.Image(geometry, material)
gfx_image.material.map = gfx.cm.viridis

scene.add(gfx_image)
camera.show_object(scene, view_dir=(0, 0, 1))

gui_renderer = ImguiRenderer(renderer.device, canvas)

def draw_imgui():
    imgui.new_frame()
    imgui.begin("Controls")

    if imgui.button("Set map to None"):
        gfx_image.material.map = None

    if imgui.button("New material no cmap"):
        new_material = gfx.ImageBasicMaterial(clim=(0, 255))
        gfx_image.material = new_material

    imgui.end()
    imgui.render()
    return imgui.get_draw_data()

gui_renderer.set_gui(draw_imgui)

def animate():
    renderer.render(scene, camera)
    gui_renderer.render()
    canvas.request_draw()

if __name__ == "__main__":
    renderer.request_draw(animate)
    run()

Traceback

Traceback (most recent call last):
  File "/home/clay/miniforge3/envs/mcam_dev/lib/python3.10/site-packages/wgpu/gui/_gui_utils.py", line 77, in log_exception
    yield
  File "/home/clay/miniforge3/envs/mcam_dev/lib/python3.10/site-packages/wgpu/gui/base.py", line 135, in _draw_frame_and_present
    self.draw_frame()
  File "/tmp/editing-mode.lV2/minpls.py", line 51, in animate
    renderer.render(scene, camera)
  File "/home/clay/git/forks/pygfx/pygfx/renderers/wgpu/engine/renderer.py", line 511, in render
    container_group = get_pipeline_container_group(wobject, environment)
  File "/home/clay/git/forks/pygfx/pygfx/renderers/wgpu/engine/pipeline.py", line 159, in get_pipeline_container_group
    pipeline_container_group.update(wobject, environment, changed_labels)
  File "/home/clay/git/forks/pygfx/pygfx/renderers/wgpu/engine/pipeline.py", line 239, in update
    container.update(wobject, environment, env_hash, changed)
  File "/home/clay/git/forks/pygfx/pygfx/renderers/wgpu/engine/pipeline.py", line 324, in update
    raise err
  File "/home/clay/git/forks/pygfx/pygfx/renderers/wgpu/engine/pipeline.py", line 321, in update
    self.update_wgpu_data(environment, env_hash, changed)
  File "/home/clay/git/forks/pygfx/pygfx/renderers/wgpu/engine/pipeline.py", line 400, in update_wgpu_data
    env_pipelines[pass_index] = self._compose_pipeline(
  File "/home/clay/git/forks/pygfx/pygfx/renderers/wgpu/engine/pipeline.py", line 621, in _compose_pipeline
    return get_cached_render_pipeline(
  File "/home/clay/git/forks/pygfx/pygfx/renderers/wgpu/engine/pipeline.py", line 109, in get_cached_render_pipeline
    result = device.create_render_pipeline(
  File "/home/clay/miniforge3/envs/mcam_dev/lib/python3.10/site-packages/wgpu/backends/wgpu_native/_api.py", line 1765, in create_render_pipeline
    id = libf.wgpuDeviceCreateRenderPipeline(self._internal, struct)
  File "/home/clay/miniforge3/envs/mcam_dev/lib/python3.10/site-packages/wgpu/backends/wgpu_native/_helpers.py", line 329, in proxy_func
    raise wgpu_error  # the frame above is more interesting ↑↑
wgpu._classes.GPUValidationError: Validation Error

Caused by:
  In wgpuDeviceCreateRenderPipeline
    Error matching ShaderStages(FRAGMENT) shader requirements against the pipeline
      Shader global ResourceBinding { group: 0, binding: 5 } is not available in the pipeline layout
        Binding is missing from the pipeline layout

The way I am reading the setter I would think this operation is allowed.
If I am doing something wrong what would be the correct way to remove the colormap from a material?

I definitely hit this months ago too.
Interestingly, adding these two lines:
    if imgui.button("cividis cmap"):
        gfx_image.material.map = gfx.cm.cividis
    if imgui.button("viridis cmap"):
        gfx_image.material.map = gfx.cm.viridis

makes you able to change colormaps.
(actually this bug is why we always have a colormap within our application clay).
I feel like the shader code isn't being invalidated somewhere.... because the "5th binding" is the colormap that is created in https://github.com/pygfx/pygfx/blob/main/pygfx/renderers/wgpu/shaders/imageshader.py#L69 that is only conditionally defined.
Some other related though not exactly the same bugs are https://github.com/pygfx/pygfx/issues/686


Fix ordering and extra node issue in transformer

Codecov Report

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

@@           Coverage Diff           @@
##           master   #23653   +/-   ##
=======================================
  Coverage   14.59%   14.59%
=======================================
  Files          51       51
  Lines        1411     1411
  Branches      219      219
=======================================
  Hits          206      206
  Misses       1189     1189
  Partials       16       16

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 1e4989a...e5322ae. Read the comment docs.


CORE-11469: Pointing to branch for testing

Do not merge. Pointing to dev branch for testing purposes

@seanbrereton converted this PR to a draft one to reduce notification noise


Add possibility to specify number of following arguments

Like in python argparse module, add possibility to set if the flag is followd by N arguments or unspecified number of argument.
https://docs.python.org/2.7/library/argparse.html#nargs

@gossel-j give #105 a spin:
npm install yargs@next
It introduces the nargs option.

@gossel-j implemented in https://github.com/bcoe/yargs/pull/105, published to npm as<EMAIL_ADDRESS>


test: unixise path for Parse.source_locs (NFCI)

Use the Unix style path for the test.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 7895a4e6d569b3bf4362f8e9d998b7a6ecea9c78

@swift-ci please test


128.0.6557.2

Update to 128.0.6557.2

the branch for this has the wrong version number 🙄 closing this to reopen under a correctly named branch


chore: add preparation commit command pnpm adorno

Description
Fixes #19
Checklist
Ensure you completed all of the steps below before submitting your pull request:

[ ] Added natspec comments?
[ ] Ran forge snapshot?
[ ] Ran pnpm gas-report?
[ ] Ran pnpm lint?
[ ] Ran forge test?
[ ] Ran pnpm verify?

@3esmit FYI: if you still want to rename this commit message, you can still do it and then merge (or merge right away)

I cant merge this, button is grayed out.

@3esmit the reason it's grayed out is because your commits are signed.
You might want to set up GPG for this: https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

Also, tip for the future:
We probably don't want to merge main into developing branches.
The developing branches should always be rebased on top of main, and then get merged into main.
That avoids us introducing these merge commits: https://github.com/vacp2p/foundry-template/pull/23/commits/e1f6eb12a9b8a808aa7fa89afcf22038120a4b29

@3esmit FYI: I've rebased your adorno commit on top of latest main so this can be merged fast-forward.

I don't mind, just want to understand the reason behind putting adorno as last command in package.json instead of how I left?

@3esmit Ah, no particular reason. There was a merge conflict as there was the release command and the adorno command both modifying the same line in package.json.
I just resolved the conflict without paying much attention to the order of the commands.
Feel free to change this.


Removed dependency on parodus to be available and forced scheduler to…

… start if a binary file were present.

Codecov Report

Merging #45 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #45      +/-   ##
==========================================
+ Coverage   72.38%   72.45%   +0.07%
==========================================
  Files           5        5
  Lines         373      374       +1
  Branches       72       72
==========================================
+ Hits          270      271       +1
  Misses         59       59
  Partials       44       44

Impacted Files
Coverage Δ

src/process_data.c
54.54% <100%> (+0.84%)
:arrow_up:

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 df78712...2644abe. Read the comment docs.


Output files return with 0 bytes (0B)

I created a simple animation and start recording it using captureMotionWithStream with expected result as MP4. But I don't know what's wrong since I follow the example. It's a simple app, so I think I'm gonna attach the code here
Code
class RenderAnimationPage extends StatefulWidget {
  const RenderAnimationPage({super.key});

  @override
  State<RenderAnimationPage> createState() => _RenderAnimationPageState();
}

class _RenderAnimationPageState extends State<RenderAnimationPage> {
  final renderController = RenderController(logLevel: LogLevel.debug);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.white,
      floatingActionButton: Padding(
        padding: const EdgeInsets.only(bottom: 32),
        child: FloatingActionButton.extended(
          onPressed: onRecord,
          backgroundColor: Colors.green,
          label: const Text('RECORD'),
        ),
      ),
      floatingActionButtonLocation: FloatingActionButtonLocation.centerDocked,
      body: SafeArea(
        child: Render(
          controller: renderController,
          child: Stack(
            fit: StackFit.expand,
            children: [
              animationWidget,
            ],
          ),
        ),
      ),
    );
  }

  void onRecord() async {
    final stream = renderController.captureMotionWithStream(
      const Duration(seconds: 5),
      settings: const MotionSettings(pixelRatio: 5),
      format: const MovFormat(),
    );

    stream.listen((event) {
      if (event.isActivity) {
        final activity = event as RenderActivity;
        log("Process: ${activity.progressPercentage}");
      }
    });

    final result = await stream.firstWhere((element) => element.isResult);

    saveToGallery(result as RenderResult);
  }

  void saveToGallery(RenderResult renderResult) {
    log(renderResult.output.path);
    GallerySaver.saveVideo(renderResult.output.path, toDcim: true).then((value) {
      if (value != null && value) {
        print("saved export to gallery");
      } else {
        print("failed to save it to gallery");
      }
    });
  }

  Widget get animationWidget {
    return MirrorAnimationBuilder<double>(
      tween: Tween(begin: 10, end: 100),
      duration: const Duration(seconds: 2),
      builder: (context, value, child) {
        return Positioned(
          left: value,
          top: 100,
          child: Container(
            width: 100,
            height: 100,
            color: Colors.red,
            child: child,
          ),
        );
      },
      curve: Curves.easeInOut,
      child: const Text('Hello World'),
    );
  }
}

Current Result
An MP4 file with 0B, so it can't be played using Media Player
Expected behavior
A playable MP4 video
Package version
I use the Render v.0.0.7

Thanks for opening this issue. The code seems to be alright, but I am currently on vacation till next week with no way to debug.
Have you tried to to use different output formats or render functions? Also check if the example of my plugin works for you!
This seems to be a valid concern and I will be debugging on that as soon as I am back to work! Sorry for the waiting time. Until then I might be able to help you out by providing me with the debug log (not necessarily for each frame)?!

Thanks for replying this issue. I already tried different output formats and render functions. But I found some interesting thing. It seems that if I record widget with bigger dimensions I have to increase the pixelRatio and also decrease simultaneousCaptureHandlers. But the probability of the video successfully rendering is no more than 20%. Sometime it works and sometime it doesn't. Also the more bigger pixelRatio will make the rendering animation will go laggy.

Thanks for opening this issue. The code seems to be alright, but I am currently on vacation till next week with no way to debug.
Have you tried to to use different output formats or render functions? Also check if the example of my plugin works for you!
This seems to be a valid concern and I will be debugging on that as soon as I am back to work! Sorry for the waiting time. Until then I might be able to help you out by providing me with the debug log (not necessarily for each frame)?!

Yes I already tried the example of your code. It works fine, but if I increase the size of the widget from width=100 to width=500 it will returns the MP4 with 0B. But it will works fine if I increase the pixelRatio=8 but it will going to be laggy

The laggy rendering when capturing at high quality is a known device limitation, described under "limitation" in the docs. (Including the reason)
The result should never be 0bytes though. Is the process capturing the frames? It might be a conversation issue of FFmpeg, which I am unaware until now. It might very well help if you send me the logs with the `logLevel = LogLevel.debug'.

Thanks for the issue.  I was able to reproduce the problem. The problem is with an expanded widgets, that the first frame somehow has a different size than the others. A temporary fix for you is to give your widget fixed constraints.
I will address the issue within an update in the next days, by forcing(converting) same-size frames.

Thanks for the response. I think there is another problem, that is if I use Container(width=200, height=200) with RenderSetting(pixelRatio=1, frameRate=30) it will also make the output become 0B too. I don't really know what's going on since the debug didn't say anything.

Alright, I was wrong in my assumption that this is a different-size-frame issue.
The problem you are probably experiencing is due to frame sizes not being dividable by two, which throws an error on the FFmpeg (the conversion engine) side.
With the ca8fed7a3fac2af1544fc6c8107bd79789d38b96 release (or render: ^0.0.9) I have addressed all issues you had and side issues, that appeared while debugging your case:

safe size frame (dividable by 2)
same-size frames (enforced)
debug logging also for stream functions (so you don't have to listen to the stream, but simply setlogInConsole: true,)
raise render error on FFmpeg error (the reason why you received files with 0B and not an error)

Please check if this resolves your issues and make sure to close the issue.
PS.: You should not have any problems with expandable widgets anymore.


IDA UI Fixes and Addition

Closes #42, #38, #36, #35
Yeah, this was a massive update.

added support for user and struct info in the info panel
fixed all time-related issues for struct syncing
made all artifacts in binsync now have a last_change parameter for tracking
fixed UI showing too many functions when syncing


go mod vendor support

I tried to vendor my dependencies but it failed because the libdeflate darwin library is not installed / copied over. Not sure how to fix that.
# github.com/4kills/go-libdeflate/native
clang: error: no such file or directory: '/xxx/vendor/github.com/4kills/go-libdeflate/native/libs/libdeflate_darwin_amd64.a'
FAIL	xxx/yyy [build failed]

Hm, I will look into it. I guess the problem is that vendor does not correctly take third party C libraries into consideration properly.

This might be hard to implement ; to be honest I am not using your library anymore, so I don't really need this to be fixed myself.

Thanks for checking though.


Stopping tedge-mapper-c8y does not stop the FsWatcher actor gracefully

Describe the bug
When tedge-mapper-c8y is stopped using ^c or using systemctl it does not stop the FsWacher actor gracefully
To Reproduce

Install thin-edge.io
tedge connect c8y
wait for a while,  Stop mapper sudo systemctl stop tedge-mapper-c8y
Observe logs sudo systemctl status tedge-mapper-c8y
Observe there is an error log

ERROR Runtime: Actor FsWatcher-6 has finished unsuccessfully: ChannelE>
Expected behavior
Stopping mapper must stop all the actors properly/gracefully.
Screenshots
○ tedge-mapper-c8y.service - tedge-mapper-c8y converts Thin Edge JSON measurements to Cumulocity JSON format.
Loaded: loaded (/lib/systemd/system/tedge-mapper-c8y.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Tue 2023-05-16 10:24:07 IST; 5s ago
Process: 161123 ExecStart=/usr/bin/tedge-mapper c8y (code=exited, status=0/SUCCESS)
Main PID: 161123 (code=exited, status=0/SUCCESS)
CPU: 192ms
May 16 10:24:07 ubuntu tedge-mapper[161123]: 2023-05-16T04:54:07.44217156Z  INFO Runtime: Actor has finished: C8Y-REST-5
May 16 10:24:07 ubuntu tedge-mapper[161123]: 2023-05-16T04:54:07.44222366Z  INFO Runtime: Actor has finished: Timer-7
May 16 10:24:07 ubuntu tedge-mapper[161123]: 2023-05-16T04:54:07.442280461Z  INFO Runtime: Actor has finished: HTTP-4
May 16 10:24:07 ubuntu tedge-mapper[161123]: 2023-05-16T04:54:07.442344261Z ERROR Runtime: Actor FsWatcher-6 has finished unsuccessfully: ChannelE>
May 16 10:24:07 ubuntu tedge-mapper[161123]: 2023-05-16T04:54:07.442401861Z  INFO Runtime: Actor has finished: HealthMonitorActor-1
May 16 10:24:07 ubuntu tedge-mapper[161123]: 2023-05-16T04:54:07.442734662Z  INFO Runtime: Actor has finished: CumulocityMapper-8
May 16 10:24:07 ubuntu tedge-mapper[161123]: 2023-05-16T04:54:07.443021964Z  INFO Runtime: Actor has finished: Signal-Handler-0
May 16 10:24:07 ubuntu tedge-mapper[161123]: 2023-05-16T04:54:07.443083764Z  INFO Runtime: All actors have finished
May 16 10:24:07 ubuntu systemd[1]: tedge-mapper-c8y.service: Deactivated successfully.
May 16 10:24:07 ubuntu systemd[1]: Stopped tedge-mapper-c8y converts Thin Edge JSON measurements to Cumulocity JSON format..
Environment (please complete the following information):

OS [incl. version]: Ubuntu
Hardware [incl. revision] X64
System-Architecture [e.g. result of "uname -a"]
thin-edge.io version [e.g. 0.1.0] 0.10.0

Additional context

Closed by https://github.com/thin-edge/thin-edge.io/pull/1984
To verify the fix, just follow the instructions in the ticket and make sure that the reported error log messages are not appearing when the mapper is stopped.

QA has thoroughly checked the feature and here are the results:

[ ] Test for ticket exists in the test suite.
[x] QA has tested the bug and could not reproduce it anymore.


Stream CAR and CAR.zst files directly to the block store

Issue summary
Forest prefers to download snapshots with aria2c for better download speeds in non-western countries. Unfortunately, using aria2c means we cannot stream data directly into our block store. Files have to be downloaded separately and then imported into the block store. If we use a CDN (either DO CDN or CloudFlare), we won't need to use aria2c anymore.

[ ] Upload new snapshots to CloudFlare.
[ ] Update snapshot URLs to point to CloudFlare.
[ ] Remove support for aria2c.
[ ] Check hash digests when streaming CAR and CAR.zst files.
[ ] Run the GC to clear unused data from the block store if anything goes wrong.

Other information and links
Download speeds from China:

Source
Single connection speed
Multi connection speed (aria2c -x5)

NonCDN
27 KiB/s
230 KiB/s

DO CDN
6.5 MiB/s
19 MiB/s

CloudFlare
7.8 MiB/s
11MiB/s

Note: ForestCAR.zst files will soon be used directly as block stores. This means we won't have to copy the data into parityDB.

ForestCAR.zst should not be streamed into ParityDB. See: https://github.com/ChainSafe/forest/issues/3334

It is no longer on the roadmap, as we'll nearly always be using .forest.car.zst files.


feat: add Invoice::void

Summary
Adds the Invoice:void method closing #517
Checklist

[X] ran cargo make fmt
[X] using conventional commits to hightlight user-facing fixes and features

Running CI, TY

Merge? @arlyon

TY!

:tada: This PR is included in version 0.37.2 :tada:
The release is available on:

v0.37.2
GitHub release

Your semantic-release bot :package::rocket:


Observer.onNext() does not timeout

I've a simple command that just returns its thread id in its run method. This command is transformed to an Observable via call to command.toObservable(). Then an observer subscribes to the observable. The observer simply Thread.sleeps()s in the onNext() methods for a period much longer than the timeout configured for the command. What I expect is the observer to time out and to be interrupted by hystrix, but this does not happen.
Here is my code for the timing out observer:
class TimingOutOnNextObserver implements Observer<Long>{
    private CountDownLatch latch = new CountDownLatch(1);
    private Throwable throwable;
    private long start;

    public void onCompleted() {
        final long end = System.currentTimeMillis();
        System.out.println("ON COMPLETED AFTER: " + (end - start));
        latch.countDown();
    }

    public void onError(Throwable e) {
        final long end = System.currentTimeMillis();
        System.out.println("ON ERROR AFTER: "  + (end - start) + " With Exception: " + e);
        throwable = e;
        latch.countDown();
    }

    public void onNext(Long aLong) {
        System.out.println("ON NEXT EXECUTED IN THREAD: " + aLong);
        start = System.currentTimeMillis();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException ex) {
            final long end = System.currentTimeMillis();
            System.out.println("ON NEXT TIMEOUT AFTER: " + (end - start));
            throw new HystrixRuntimeException(null, null, "TIMEOUT", ex, null);
        }
        final long end = System.currentTimeMillis();
        System.out.println("ON NEXT DINDN'T TIMEOUT AFTER: " + (end - start));
    }
    public void verify() throws Throwable {
        latch.await(2000, TimeUnit.MILLISECONDS);
        if (null != throwable) {
            throw throwable;
        }

        System.out.println("TEST THREAD: " + Thread.currentThread().getId());
        fail("On next didn't time out. Latch count:  " + latch.toString());
    }
}

And here is the failing test method:
@Test(expected = HystrixRuntimeException.class)
    public void testObservableOnNextWithOnNextTimeout() throws Throwable {
        Observable<Long> observable = command.toObservable();
        TimingOutOnNextObserver observer = new TimingOutOnNextObserver();
        observable.subscribe(observer);
        observer.verify();
    }

And the relevant console output:
RUN EXECUTED IN THREAD: 14
ON NEXT EXECUTED IN THREAD: 14
ON NEXT DINDN'T TIMEOUT AFTER: 1001
ON COMPLETED AFTER: 1004
TEST THREAD: 1

Any command could be used for testing. Mine just returns Thread.currentthread().getId();
Here is the command configuration:
Setter.withGroupKey(key).andCommandPropertiesDefaults(HystrixCommandProperties.defaultSetter()
                .withExecutionTimeoutEnabled(true)
                .withExecutionTimeoutInMilliseconds(100)
                .withExecutionIsolationThreadInterruptOnTimeout(true)
                //we don't want the CB to interfere with the tests
                .withCircuitBreakerEnabled(false)
                .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD))

PS: Hystrix version: 1.4.23

This is not a bug :cry: . You are confused where the timeout check happens.  It happens earlier in the pipeline on the actual execution of the command and not your subscription. There is no way Hystrix  can or should know what happens on subscription as it could be a completely different thread (see rxjava subscribeOn or observeOn). That is the execution of the item didn't really timeout... you just wait and block the thread but the item is already processed (onSuccess is called earlier upstream).
If you really want timeout like behavior on a rxjava  subscription (ie Observer) you can wrap a HystrixCommand into an Executor and then turn the Executor into a rxjava Scheduler.
	public static Scheduler hystrixScheduler(final HystrixCommandGroupKey key) {
		return Schedulers.from(new Executor() {
			@Override
			public void execute(final Runnable command) {
				new HystrixCommand<Void>(key) {
					@Override
					protected Void run() throws Exception {
						command.run();
						return null;
					}

				}.execute();
			}
		});
	}

Now you can do a timeout like:
        Observable<Long> observable = command.toObservable();
        TimingOutOnNextObserver observer = new TimingOutOnNextObserver();
        observable.observeOn(hystrixScheduler(key));
        observable.subscribe(observer);

There is general confusion on how Hystrix should deal with streams as well the difference between Command and ObservableCommand (see #1103). Regardless Hystrix only times out on the producer (the original Observable aka Publisher) and not the consumer (Observer).

I see, thanks a lot for the detailed explanation!


resource_action_workflow#create_request call

I fixed resource_action_workflow so it properly calls create_request
as a side effect, the logging now displays the actual event instead of a generic was: "resource_action_request_created", now: "service_reconfigure_request_created". I can change to the old value, but this seems to work better.
/cc @gmcculloug this is the bug we found today. Updated spec to be more thorough, and to detect this error as well.

:+1: The updated event_name is used for audit logging and the more specific name being passed now is better.  Please clean up the two rubocop warnings.


Convert Points to interface

Ground work for replacing the implementation of Points with a byte buffer backed version.

@jwilder i don't know if you've seen #2513 - even if you don't fix it, it might help to be aware of it.


How to change speed dial logos (from logos.kiwibrowser.com)

I have a problem with adding speed dials where a bunch of them are showing me the wrong website icon.
The source code says that all of them come from logos.kiwibrowser.com.
How do we change these? There doesn't seem to be a repo named logos under kiwibrowser.

Since that issue it's old and the default homepage will not undergo changes and implementation of new features, over time was born an alternative more customizable NextNTP which includes among other things the editing of logo source

NextNTP is a web page right? Not a browser built-in feature?

NextNTP is a web page right? Not a browser built-in feature?

For now it's a webpage only . Built-in could be an option in future builds

Still no way to change a bad speed dial icon????


email_mirror: Rename "include-footers" option to "include-footer".

As requested in https://github.com/zulip/zulip/issues/12500

When will this be merged?
Will it?

@daschuer you can just use the "include-footers" option for now, and change when this gets merged

Merged, thanks @mateuszmandera!


Don't write output if nothing goes wrong

Writing to stderr will cause the K8up backup to fail.
Fixes #16

Checklist

[x] Keep pull requests small so they can be easily reviewed.
[x] Update the documentation.
[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking, dependency
as they show up in the changelog
[x] Link this PR to related issues.

Probably best to run this through shellcheck.com and fix the issues that pop up there
I considered this but the list is pretty long so I didn't do it :P

Had two smaller remarks, the rest LGTM

@Kidswiss Yes I considered this as well, but since the verbose flag would produce some ADDITIONAL output I left it as is. I'm fine with both.

No hard feelings, both is fine.


New VM type cloud property for CPU reservation

Rebase on original PR failed: https://github.com/cloudfoundry/bosh-vsphere-cpi-release/pull/281 so opening new PR here.

Opted against adding a full integration spec, since the feature takes a multiple of the ESXi host CPU MHz, which wouldn't be very predictable depending on the environment the tests are run.
We did manually deploy a VM using a VM extension to set cpu_reserve_full_mhz: true and saw in vCenter that the VM had reserve CPU equal to the ESXi host it was deployed on. All other VMs had 0 MHz reservation.

Corresponding docs PR: https://github.com/cloudfoundry/docs-bosh/pull/846

I wish it was a % of CPU to reserve, rather than just 0 or 100. Like I might choose to reserve 1 pCPU (which is in terms of physical ghz) for every 2 vCPUs to let the hyperthreading do its thing.

Also what about taking the MIN(cpufreq) across the cluster rather than the largest node? Or we think they're the same usually?

@svrc as the author of the original PR, do you happen to remember the reasoning behind the current logic?

@dsboulder & @rkoster doesn't seem like we're going to get a response on this. What direction do you want to go with it?

Sorry for not responding earlier,  IIRC the logic for using the minimum CPU in the cluster is that you want to allow the workload to fit on any host in the cluster, not the largest host.   If you pick the largest host it will only be scheduled there.


K3s should log directly to journal instead of stdout/stderr on systemd systems

Today, K3s logs to stdout and stderr and the logs then get captured and categorized under the corresponding K3s unit.
We also have a mismatch issue of formatting for all of the logs that come out of K3s: more information on this can be found here: https://github.com/k3s-io/k3s/issues/3420
Ideally, if we can log to journald directly, for the same reasons as listed here: https://github.com/rancher/rke2/issues/1111 we will make our logs easier to ingest.

This should be reopened. Having a central logging instance can help tremendously. Especially when having to handle security - going through a single journald log would help a lot.
Imagine having a dedicated remote logging server!


Outdated LLM Model

The LLM model - meta-llama/llama-2-70b-chat seems to be outdated.
Error message:
{"status":404,"body":{"errors":[{"code":"model_not_supported","message":"Model 'meta-llama/llama-2-70b-chat ' is not supported"}],"trace":"40819749768344339ad9507aa34dfc6f","status_code":404}}

Closing because this issue is resolved.

I had to use a different project ID.


[FLINK-22585] Add deprecated message when -m yarn-cluster is used

What is the purpose of the change
(For example: This pull request makes task deployment go through the blob server, rather than through RPC. That way we avoid re-transferring them on each deployment (during recovery).)
Brief change log
(for example:)

The unified executor interface has been introduced for a long time, which could be activated by "--target yarn-per-job/yarn-session/kubernetes-application".
It is more descriptive and clearer. We should try to deprecate "-m yarn-cluster" and suggest our users to use the new CLI commands.

Verifying this change
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (100MB)
Extended integration test for recovery after master (JobManager) failure
Added test that validates that TaskInfo is transferred only once across recoveries
Manually verified the change by running a 4 node cluser with 2 JobManagers and 4 TaskManagers, a stateful streaming program, and killing one JobManager and two TaskManagers during the execution, verifying that recovery happens correctly.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@flinkbot run azure

@wangyang0918 do you think that you can review this PR before the 1.14 feature freeze?

@wangyang0918 and @lixmgl do you think that we can finish this PR for the 1.14 release? I think it would be a valuable addition so that we can delete this option with the next release.

@tillrohrmann yes, I will update it shortly.

@tillrohrmann Thanks for the comments. I will keep an eye on this PR and help with reviewing once the comments are addressed. BTW, since we do not take any concrete behavior change in this PR, I think it is reasonable to merge this PR after the code freeze. Right?

Yes, I think we can merge this PR after the feature freeze.


Fix transfers for rotated authkeys

@zmanian Happy to see contributions, could You please recreate this PR against canary branch?


DOM.querySelectorAll returns error with code -32000

Component
Version

Operating system
Ubuntu 14.04 LTS

Node.js
v7.10.0 (meteor node version is v8.8.1

Chrome/Chromium/...
61.0.3163.79

chrome-remote-interface
<EMAIL_ADDRESS>

Is Chrome running in a container?  NO
Hi, I'd like get the all href property of
To do this, I added code based on your previous q & a ( https://github.com/cyrus-and/chrome-remote-interface/issues/64)
and following is my code.
DOM.getDocument((error, params) => {
  const options = {
    nodeId: params.root.nodeId,
    selector: 'a'
  };
  if (error)
  DOM.querySelectorAll(options, (error, params) => {
    if (error) {
      console.error(params);
      return;
    }
  });

console.error(params); >> always show error code.
{ code: -32000, message: 'Could not find node with given id' }
I have searched about  it, and some people it is timing issue,
so I tried to add sleep code, but it deosn't work for me :(
Do you know what is the problem ?

Hi! That code is incomplete, I'm trying with the code from #64 (using 'a' instead of 'img' as selector):
const CDP = require('chrome-remote-interface');

CDP((chrome) => {
    chrome.DOM.getDocument((error, params) => {
        if (error) {
            console.error(params);
            return;
        }
        const options = {
            nodeId: params.root.nodeId,
            selector: 'a'
        };
        chrome.DOM.querySelectorAll(options, (error, params) => {
            if (error) {
                console.error(params);
                return;
            }
            params.nodeIds.forEach((nodeId) => {
                const options = {
                    nodeId: nodeId
                };
                chrome.DOM.getAttributes(options, (error, params) => {
                    if (error) {
                        console.error(params);
                        return;
                    }
                    console.log(params.attributes);
                });
            });
        });
    });
}).on('error', (err) => {
    console.error(err);
});

This code works fine and prints all the attributes of <a> elements (you can fetch the href from there).

Time has passed since that issue, you can rewrite the above code more conveniently:
const CDP = require('chrome-remote-interface');

CDP(async (client) => {
    const {DOM} = client;
    try {
        // get root document id
        const {root: {nodeId}} = await DOM.getDocument();
        // get all the <a> elements
        const {nodeIds} = await DOM.querySelectorAll({nodeId, selector: 'a'});
        // for each <a> element print its attributes
        nodeIds.forEach(async (nodeId) => {
            const {attributes} = await DOM.getAttributes({nodeId});
            console.log(attributes);
        });
    } catch (err) {
        console.error(err);
    } finally {
        client.close();
    }
}).on('error', (err) => {
    console.error(err);
});

Thank you, it was really helpful. -32000 error was because document had been changed so that nodeId is not valid anymore :)


Bug(ramsql): E2E tests are failing when upgrading ramsql from v0.0.1 to v0.1.0

Regression in ramsql, logged an issue with them - https://github.com/proullon/ramsql/issues/86

Closed as we switched from RAMSQL to SQLite


[ISSUE-2] additional webhook overrides

Fixes https://github.com/Ginxo/github-api-massive/issues/2

@Ginxo I tried to make it as flexible as possible such that whenever a new webhook config is present it would be enough to add it here https://github.com/Ginxo/github-api-massive/pull/3/files#diff-930b7300b0725ae03e018a7801f2bf6192c87321c220fb9fc0e99a7a7a400496R25
Wdyt? any other better approach?


Clarification needed around "objectType"

README says
objectType: secret        # object types: secret, key or cert

What does it mean to have a "key" objectType. Azure Key Vault does not let importing private keys. So, is it just the public key that would be retrieved and mounted as a secret?

objectType: secret fetches the private key along with chain of certs.
objectType: key fetches only the public key
Ref doc: https://github.com/Azure/secrets-store-csi-driver-provider-azure/blob/master/docs/getting-certs-and-keys.md


just updated app not starting

Please provide some detail.  This isn't an app so much as a workflow


[1.16-pre2] Server crash on start

Log:  https://gist.github.com/kwpugh/2a99dc2dd144f8867c6ff54b52005817

Heh, and this is why we test on dedicated servers before releasing, even if it's just a version port. Sorry I didn't see this issue earlier, unfortunately I didn't see the email!
Fixed in <IP_ADDRESS>.

Thanks.


none result in fssd-mobilenet and yolo-v3-mobilebnet

when i run the demo, i found this problem as blew:
File "F:\DeepLearning\mobilenetv2_fssd\ssds_pytorch\lib\layers\functions\detection.py", line 149, in forward
ids, count = nms(boxes, scores, self.nms_thresh, self.top_k)
ValueError: not enough values to unpack (expected 2, got 0)

The answer is here.
In the ssds.py,
change the line
scale = torch.Tensor([img.shape[1::-1], img.shape[1::-1]])
to
scale = torch.Tensor([img.shape[1], img.shape[0], img.shape[1], img.shape[0]])
and
if scores.dim() == 0:
to
if scores.dim() == 0 or scores.size(0) == 0:
then it will work.
This is because of the version of Pytorch. It supports on Pytorch 1.0.1

@seongkyun , thanks a lot for solve this. I tried and it works for me.
The code "scale = torch.Tensor([img.shape[1::-1], img.shape[1::-1]])" is located in ssd.py
The code "if scores.dim() == 0:" is located in detection.py
This changes can work on torch >= 0.4 (it seems that torch uses tensor.size() to describe the dim in 0.4+ and if it is a (1,) u should use .item() .


include a dropdown on my orders widget to separate from open/closed orders.

Tasks:

[ ] Change "My Orders" to "My Trades"
[ ] Add Dropdown with filter open, closed
[ ] Show closed buy and sells from user

I guess we can close this... or we are closing it once it's in production ?

yeah, after it is tested for a while... then we are closing it.


Added remove-all-metrics function. It's necessary (but not sufficient)

if you want to cleanly shut down a metric-registry, during testing.

Better?