Gimel Studio in Blender

Here seems to start a project which could be a door opener for Gimel Studio in Blender. Just as an idea.
https://blenderartists.org/t/pip-for-blender/1259938

Thanks for the idea!

What exactly were you thinking with this? :)

All other post-pro add-ons in Blender always work in the slow compositor. For still image renderings, it would be great to have Gimel Studio directly in Blender. Gimmel Studio would certainly benefit from the large Blender community. Most people are annoyed with the slow compositor and most of them render still images as well.  It could use the Blender node system and the whole workflow would be easier.

You will definitely have issues if you plan on implementing this in wxPy as blender uses gl and frames and whatnot will smear the blender gui without hacks or wx support from the blender side.
This may or maynot still work with the new blender releases, but you will get the idea if you try and implement it in wxPy
See https://github.com/Metallicow/wxBlender

Tho you could make a blender plugin that starts up the gimel editor from within blender so you could communicate thru subprocess pipe. That might work better and might not smear up the gui as it should be a separate process...

Tho you could make a blender plugin that starts up the gimel editor from within blender so you could communicate thru subprocess pipe. That might work better and might not smear up the gui as it should be a separate process...

@Metallicow, yes this is the thought/method of doing it (through subprocess) I had a while back for possibly integrating Gimel Studio with another application, but this could work with blender too (I hadn't thought about blender till @MarioPeper mentioned it!)
I had seen your wxblender project and it looked neat. My guess is that you had smearing issues with it though, right?
@MarioPeper, This is a good idea, though it probably wouldn't use the blender node editor itself and probably be run separately through subprocess, etc as @Metallicow suggested. (see above),
Thanks.

@Metallicow @Correct-Syntax That would certainly be easier and I don't think I needs pip. There are some addons that simply work as a bridge between blender and other programs e.g. Instant Meshes.
But I did not have that in my mind. I actually thought about a replacement for the compositor. Anyway, for such an addon I would pay 15-20€ immediately. And with Blendermarket and gumroad the blender ecosystem is already there. Having a bridge is nice to have but in the end it only saves a few clicks. That is no big difference in workflow for me.

@Correct-Syntax Well, yea smearing sorta sometimes. Most of the smearing issues was I was trying to use wxPy from within blender and I had to hack refresh the screen a lot to get it to work. Tho at the time blender was going thru their ui debate with the community and I whipped it up mainly for mockups. One thing folks had an issue with was using custom icons in menus. Those work fine, tho if you create a frame and drag it over the blender gui it will smear without the hack.
There are numerous ways to deal with that type of stuff, but the easiest would probably be hook into blenders refresh window functions when you move a frame over their gui. My plugin is more useful for popups and whatnot, as regular frames doesn't fit in with blenders gui like wx.aui or similar advanced docking systems.
The hard way would be to fork your own copy of blender and integrate wxPython functionality from the blender end. This would be similar to the many zillions of custom builds you can get here and there.

I  actually thought about a replacement for the compositor...

@MarioPeper, technically Gimel Studio aims to be a replacement for blenders compositor. :)
Obviously, it's not directly in blender, but maybe a bridge would help to ease that.
My most recent thought is maybe to have the addon for blender as said before, but also have a node in Gimel Studio and/or blender that would allow for communicating between blenders node editor and the current Gimel studio node graph or something.....
@MarioPeper, What exactly is the workflow you're looking for?
@Metallicow, yeah I thought so.... It probably would not pay to do it that way anyway.
Thanks again for the ideas and thoughts on this. 👍

@Correct-Syntax As we have already discussed, for a good post-pro workflow outside Blender you need Blenders own multilayer .exr format. But at the moment I know only 2 programs that can handle it: Krita and Natron. Although this is pretty cool, it is more complicated than working directly in Blender. If only the compositor was not so slow.
So I thought, with new ways to bring PIP into Blender, it would be easier to have Gimmel Studio in Blender. In the end, it should do the same as the compositor (not so complex of course). Gimel Studio should have more nodes. I don't know how easy or difficult that is. It would be nice for you: you could leave Gimmel Studio free and make money with the Blender add-on. I'm sure many people would want to have it if the most important nodes were included. The younger developers often do it in such a way that they first offer the addon at a lower price, so that first a few bite and then increase the price with every update. Also, this is a good way to find out what people want in it (with a Blerderartist topic)

for a good post-pro workflow outside Blender you need Blenders own multilayer .exr format.

@MarioPeper, I have been looking into using the openimageio library instead of pillow (the imaging library I am using now), which supports exr files, color space conversions and 32 bit images.
With our discussion before and the suggestion of @ttddee (#11), it seems to me that Gimel Studio needs to go in the direction of supporting professional image file formats, etc. I haven't really done too much testing with openimageio yet, though to see if it is a real possibility for replacing pillow.

But at the moment I know only 2 programs that can handle it: Krita and Natron.

Yeah. There might be a reason why....

In the end, it should do the same as the compositor (not so complex of course).

Could you elaborate on this? I have been trying to make Gimel Studio not-so-complex.

Gimel Studio should have more nodes.

Of course. Though, it will be easier to add more nodes post v1.0.0. Right now I am still working out things and thus I don;t want a huge amount of nodes to change every time I change the API. (Hint: You could write your own nodes too!) 👍

It would be nice for you: you could leave Gimmel Studio free and make money with the Blender add-on. I'm sure many people would want to have it if the most important nodes were included.

Gimel Studio will always be free as far as I am concerned. Would there really be that much of a demand for a blender addon like I described -you think? Or, I suppose you might be talking about an addon like you were saying?
I'm considering accepting donations for Gimel Studio (hoping I could then have the chance to spend more time making It stable/adding features), though I have questioned how much demand there is for a niche application like Gimel Studio and whether its a good idea or not.
In any case, thanks for the conversation. :)

I am also not sure how complex it would be to implement exr file support as well...which is what I was alluding to in my last comment.... :)

@Correct-Syntax As we have already discussed, for a good post-pro workflow outside Blender you need Blenders own multilayer .exr format. But at the moment I know only 2 programs that can handle it: Krita and Natron.

Hi guys! I have been following this with great interest, since I think the world needs a node-based still image editor. I am working on something similar. Multi-channel EXRs are not an exclusive Blender thing. It has been an industry standard in Film for a long time. All the professional comp and 3D packages support it. Nuke, Flame, Fusion, Maya etc...
With OpenImageIO it is really easy to integrate, the details are here: https://openimageio.readthedocs.io/en/release-<IP_ADDRESS>/builtinplugins.html#openexr

Could you elaborate on this? I have been trying to make Gimel Studio not-so-complex.

I mean not so many knots as in the Blender Compositor.

Gimel Studio will always be free as far as I am concerned. Would there really be that much of a demand for a blender addon like I described -you think? Or, I suppose you might be talking about an addon like you were saying?

Like i were saying.
But a simple bridge would increase the attention on Gimel Studio enormously. Whether and how much money would be required for this is difficult to answer. In my estimation, I would leave that empty. But perhaps others will come with the request to integrate the Gimel Studio deeper into Blender. That should then definitely land on Blendermarket.

@ttddee Thank you for pointing this out. I only use open source software, so I didn't know that. But all the more reason to have this in Gimel Studio.

@Correct-Syntax Basically what @MarioPeper  is trying to say in a nutshell is
I mean not so many Nodes as in the Blender Compositor.
Basically whether or not you charge for a plugin to bridge programs, the point stands like with my noding needs.
You have implemented a dynamic way to generate code, therefore you have to accept the fact that there is an infinite amount of nodes, which is why Mario or others may consider it complex or complicated.
Basically what would also need to be done is you would want to also develop a "installer" or "manager" to manage all these "node" types so as not to confuse or scare away simple users. Ex: no need for just blender users to install complex debugging nodes for a code editor or other program when all they want to do and know how to do is create 3D art in a modeler program such as blender with simple images they provide themselves.
As far as the manager that would require a ton of extra development time, so yea most folks would want some sort of small sponsor funding to sustain while it is being developed. Actually you could use wrye bash to install nodes, but unless your a guru then it would scare most users.
So in conclusion I would say that it should KISS based. (Keep it simple stupid).

@MarioPeper,

But a simple bridge would increase the attention on Gimel Studio enormously

I agree. It might open up other possibilities as well -like you were saying.

The easiest way is via gumroad with a voluntary amount.

That sounds like a good idea. :)

In my opinion Gimel Studio will not be in a niche for long if it is firmly integrated into Blender. ;-)

Yeah, that's true. Integrating with blender would probably attract a lot of people who wouldn't use something like Gimel Studio otherwise.

@Correct-Syntax

That sounds like a good idea. :)

As an addon collector I want to give you the following tips:
Addons with a 0 € price suggestion usually get hardly any money.
Addons with a higher price suggestion rather. But not really much.
The same goes for those that offer a price but additionally present the gitub link.
Everything with a minimum price below 5€ is always possible (I have some I have never used).
The next pain threshold is at 12€ and anything over 20€ I think about carefully.
The payments also work in $.
I like the newer approach of some to start with smaller amounts first and then increase per update.
This gives some the early bird advantage and encourages the successors to follow suit. An example: The last addon I bought started with 3€ and is now at 10€. This works particularly well at Blendermarket, where you can see how many have already been sold.
It also looks much more professional when you are also at blendermarket. But it is more complicated and takes longer to get started.

@Metallicow, thank you for clarifying what @MarioPeper was saying.

You have implemented a dynamic way to generate code, therefore you have to accept the fact that there is an infinite amount of nodes, which is why Mario or others may consider it complex or complicated.

Certainly. I can understand how it can be overwhelming when there are a lot of nodes to sort through, like many other based programs I have seen......

Basically what would also need to be done is you would want to also develop a "installer" or "manager" to manage all these "node" types so as not to confuse or scare away simple users. Ex: no need for just blender users to install complex debugging nodes for a code editor or other program when all they want to do and know how to do is create 3D art in a modeler program such as blender with simple images they provide themselves.

This is a great idea. This was somewhat the core concept behind "core" and "custom" nodes in Gimel Studio, though, right now you have to do it the manual way, with some know-how. :)
A nice gui for managing nodes sounds like a great idea for better usability. Then, it could just show the nodes the particular user wanted/needed at any given time. If you have any ideas for how the more manager should work, please comment (#13)have

So in conclusion I would say that it should KISS based. (Keep it simple stupid).

Yeah. It's easier said than done!

@MarioPeper, thanks for the advice. You Do seem to be quite an addon collector, so your advice is probably spot-on. :)
Do you think this applies to donations, etc. in general or just blender addons?
I've been brainstorming ideas for how the bridge addon could work. I have created a blender addon for my own personal use before, but that was in the 2.7x series.

therefore you have to accept the fact that there is an infinite amount of nodes, which is why Mario or others may consider it complex or complicated.

Unfortunately I am not sure if I understand @Metallicow correctly. Therefore here again what I mean with complex.
Over the years more and more nodes have been added to the compositor in blender (due to user requests). But now there are so many that I only need 30% of them for my normal work. That's why I think it's good if not so many of them come into Gimel studio. The question is of course which are the important ones and everyone will see it differently. So that more and more will be added via the updates. So I think it's good to always make sure that it doesn't turn to COMPLEX ;-)

Do you think this applies to donations, etc. in general or just blender addons?

This is indeed very specific to blender, but also groundbreaking.
Blender's ecosystem does the open source world a big favour by showing how money can be made with open source without destroying the basic idea. The cult of Blender produces customers who are willing to pay for something that is actually free. It also shows appreciation for the fact that a coder takes into account special wishes that make my own Blender personal.
In my opinion, no other open source project has succeeded in this.

bridge addon could work

A simple bridging addon between Gimel Studio and Blender should  open the render result as it is (the displayed render pass) in Gimel Studio by clicking on a button. I need to have the option to open a new file or to load the (next) render pass into the already opened file.

Blender is definitely unique when it comes to their market for plugins. Just because a software is GPL'd doesn't mean that people cannot sell it or try to make money off of it. Your freedom comes in the form, legally that no-one can close-source your code. This is a blessing and yet also a burden of the GPL. Basically if you GPL your code, you are basically saying that you will never work in the "company" and are forcing others to do the same. This does not mean that you cannot be an independent. On the other hand the output files and plugins are your own creation so you are free to do with them as you please.
A good example of a blender plugin is like many have done in the past. The developer wants to support his development time financially while plugin is being developed but also wants to keep the code free. What usually happens is that dev will charge $10-20 for the plugin and at a certain point when they recover the dev costs and make themselves a few bucks, they then relicense the plugin to be ZLIB/MIT/BSD/Apache etc, so that the company man can benefit also.
One thing to note about GPL is that while a individual might pay for your plugin... Lets say that they work within a studio and only paid 10 bucks for it. It is not illegal for that one person to share that plugin with the whole studio or family/friends. On the other hand this is why most studios would more likely send you 200-300 bucks instead of 10 for an individual license.
And yes, basically what Mario said about using only 20% of the nodes is exactly what I mean overcomplicates it for normal/simple users. A Poweruser of studio worker might use 95% of the nodes for example. Hence having a node manager is similar to why blender has different tabs/workspaces for modeling/uv/sculpting/scripting/etc/etc..

@Metallicow,

Your freedom comes in the form, legally that no-one can close-source your code. This is a blessing and yet also a burden of the GPL.

I have found this to be true with GPL code. Before I open-sourced Gimel Studio, I was debating about whether to license it under GPL or Apache. To me, the copyleft of the GPL is both a burden and a blessing.  I know you're biased against Apache  ;)  and I am leaning towards changing Gimel Studio's license to GPL because I'd rather keep the code open-source. -Just a little wary of the copyleft thing....

A good example of a blender plugin is like many have done in the past. The developer wants to support his development time financially while plugin is being developed but also wants to keep the code free. What usually happens is that dev will charge $10-20 for the plugin and at a certain point when they recover the dev costs and make themselves a few bucks, they then relicense the plugin to be ZLIB/MIT/BSD/Apache etc, so that the company man can benefit also.

Interesting idea. It makes sense, but seems like a bit of a roundabout way to do it(!).

One thing to note about GPL is that while a individual might pay for your plugin... Lets say that they work within a studio and only paid 10 bucks for it. It is not illegal for that one person to share that plugin with the whole studio or family/friends. On the other hand this is why most studios would more likely send you 200-300 bucks instead of 10 for an individual license.

Yeah. That's the nature of open source.

And yes, basically what Mario said about using only 20% of the nodes is exactly what I mean overcomplicates it for normal/simple users. A Poweruser of studio worker might use 95% of the nodes for example.

Yes. I think there are some nodes in blender I have never used, so I can understand that.

Hence having a node manager is similar to why blender has different tabs/workspaces for modeling/uv/sculpting/scripting/etc/etc..

Definitely. I see that the node manager is really a necessary thing for catering to different needs and skill levels. It's one thing if a program such as Gimel Studio or Blender just do color-correction (for example), but it's quite different when it can do an (almost) infinite amount of things (or even just a handful, really...).

Over the years more and more nodes have been added to the compositor in blender (due to user requests). But now there are so many that I only need 20% of them for my normal work. That's why I think it's good if not so many of them come into Gimel studio.

I understand. Though, can I really say that I use even 75% of most of the software I use. Not really. It's probably more of just how things are organized and showing only what is needed for each particular user's needs so that it's not overwhelming. That is my plan with the Node Manager.

The question is of course which are the important ones and everyone will see it differently. So that more and more will be added via the updates. So I think it's good to always make sure that it doesn't turn to COMPLEX ;-)

Hence the need for a Node Manager in Gimel Studio so that only what the user needs they can install/show. I am trying to think about how software like FilterForge does it. (I haven't ever used it myself, but I see that it is popular.) More nodes are inevitably going to get added to Gimel Studio, it's just that they need to be organized in such a way as to not be complex.

It also shows appreciation for the fact that a coder takes into account special wishes that make my own Blender personal. So the end result (add-on) is more a service than a product.

I hadn't thought about it that way, but that is certainly true. Neat.

A simple bridging addon between Gimel Studio and Blender should open the render result as it is (the displayed render pass) in Gimel Studio by clicking on a button. I need to have the option to open a new file or to load the (next) render pass into the already opened file.

I am planning to mock this up and maybe do a bit of coding to see what I can do as far as this blender addon. The thing I have (unnecessarily!) been stuck on is where to place the button. Kinda silly to be concerned about that, but it is important.

Additionally multilayer .exr would be nice of course but this can also be included in a later update.

I do plan to (attemp) implementing openimageio into Gimel Studio and along with it would come exr support. :)

where to place the button

In the N panel of the render window and/or the compositor. The render passes are displayed there. Or in the view Layer Properties if no visual feedback should be included.

Personally I consider the GPL evil because of the whole closed source thing, because it is a viral license.
If I was you I'd avoid the GPL.
wxWidgets is a good choice also if you intend it to be a library/program as it is essentially LGPL with the exception to do what you please with the compiled binary.
The best one you can get is Zlib. At least with that no one will misrepresent you or run your name thru the mud, and it benefits everyone equally. MIT/BSD2 is basically saying I don't care what you do with my name, just here is some code. Apache adds on to this by protecting from patent trolls, but it has a undesirable changelog clause, so anyone that will use/fork gimel studio and use it in their software probably 99% of the time will not make changes to it or improve it any way.
As for public domain, some contries dont respect that so a CC0 is the best way to do a "whatever you want license"

The blender addon is WIP, by the way.
I am starting out very simple with it, but hopefully in the future it will be more integrated into blender.

Where can I download it ?

You can download it at https://github.com/Correct-Syntax/Blender-Gimel-Studio-Addon.

It works so far. Didn't you post it on Blenderartist?
Do I see it right that it just starts Gimel Studio without loading the render result ?
I think at the latest when it shows the render result you should post it on blenderartist. Best on a friday then most of them are there. But with every comment it is on top of the list again.

@MarioPeper,

It works so far.

Good. It's WIP. :)

Didn't you post it on Blenderartist?

No, not yet.

Do I see it right that it just starts Gimel Studio without loading the render result ?

Yes, you are seeing correctly. The furthest progress I have reached is that. I have yet to do the Gimel Studio side of the "bridge" and "glue" them together. If you would like to give feedback on panel positioning, text, etc that would be great. Just open an issue in the repo @iwoithe had mentioned. Also, if you "watch" that repo (via Github), you will be notified when I actually make a release of the addon, etc. As always, please report bugs!

I think at the latest when it shows the render result you should post it on blenderartist. Best on a friday then most of them are there. But with every comment it is on top of the list again.

Yeah, I will make a release when I get to that point and see about posting it on blenderartists. How helpful do you think the addon will be once it reaches that (very si mple) point? Would Roman "friday" really be a good day to post it then?

In the end, the day of the week doesn't matter as long as the discussion is ongoing. This "simple point" makes a huge difference in the workflow. Besides, Blenderartist is not primarily used for advertising but to initiate a discussion about improvements. However, I would like to have a few more nodes for Gimel Studio (still at 4.2). But the discussion will also help with that, and it's better to start it earlier than if it becomes difficult to change something fundamental.

In the end, the day of the week doesn't matter as long as the discussion is ongoing.

Sure. (Except to me it would matter - I wouldn't post it on Roman Saturday, as that is the Sabbath day.)

This "simple point" makes a huge difference in the workflow.

Good.

Besides, Blenderartist is not primarily used for advertising but to initiate a discussion about improvements

I've noticed that sometimes it seems to be effective in advertising (for particular addons) too. :) Feedback is good.

However, I would like to have a few more nodes for Gimel Studio (still at 4.2). But the discussion will also help with that, and it's better to start it earlier than if it becomes difficult to change something fundamental.

Yes, you will have to let me know what nodes you're looking for. @iwoithe had been working on a few new (and nice) nodes for v0.5.0. Yes, getting feedback as early as possible is important. Thanks.

The first release for the addon is here. Still WIP, but "working". You will need to build the executable from the latest Gimel Studio source in order for it to work.

I get a "Permissions denied" error even when I release Gimel Studio with chmod -x. Also "make" hangs at the end. But Gimel Studio runs when I start it with Python. I wait until a stable version is released. I'm really not a fan of building it myself. But when it works, I use it for post pro tasks. Because it is faster.

@MarioPeper I recall if you are using wxPy within blender you have to use the version built for PythonX that is bundled with blender, but since it is using subprocess, you don't have to have a built exe I recall. You should be able to modify the blender plugin to call the gimel studio py file and execute it with whatever version python you are targeting.
Ex: if I have a program that uses Python2 and Classic wxPython I can call that in the subprocess call. Blender bundles its own python so do note that when using python/another python from within blender.

@MarioPeper,

I get a "Permissions denied" error even when I release Gimel Studio with chmod -x.

Hmmm.... ./make in the root directory works for me. This is as root user, so maybe you need to throw a sudo in front of it?
Or, if you are talking about running the executable, I have included some screenshots below of what I have to do sometimes to allow applications to run as executable.

Also "make" hangs at the end. But Gimel Studio runs when I start it with Python.

I am not exactly sure what you are referring to, but I know that it does appear to hang at the end -and that is expected.

I wait until a stable version is released. I'm really not a fan of building it myself.

That's O.K. I can understand that. It can be frustrating to build from source. Most of the time, I am inclined to give up too. (Except that you do happen to be setup to build the executable.)

But when it works, I use it for post pro tasks. Because it is faster.

O.K great.
Thank you for your feedback! You've helped a lot.

@Metallicow,
Currently, the addon doesn't work that way. It does require a build executable, but isn't so integrated into blender that @MarioPeper should need to mess with it otherwise.
Sorry if there is/was some confusion about this.

    sysExe = sys.executable
    # dprint('sys.executable = %s' % str(sysExe))
    # dprint(sys.argv[0])
    # dprint(__file__)
    os.chdir(gAppDir)

    ## if sys.argv[0].lower().endswith('.exe'):  # How to restart from pyinstaller-built exe.
    if __file__.lower().endswith('.exe'):  # How to restart from pyinstaller-built exe.
        exePath = sysExe
    else:
        pyPath = sysExe
    ## args = exePath
    args = [pyPath, __file__]
    subprocess.Popen(args)

This should help explain your issue how to start/restart a script/exe.

Unless I am missing something here, @MarioPeper and @Metallicow?

If you are using linux, I recall it isnt exe as an extension. So you might have to check if the file is executable. I forget what extension mac uses. But the sample I posted above is fairly straight forward if you are using windows. As long as you understand how sys.executable works and __file__ is normally only available when run as python code. This can be modded if you put that into your gimel code before it is compiled, so that __file__ "could" be present if running a frozen program.

@MarioPeper Another thing to note is that if you or anyone else is not familiar with python or reading the code, then the method @Correct-Syntax  posted about changing file permissions to executable should be heeded with extreme caution in most cases. But since it is open source and everyone here can see that nothing fishy is going on in the code, then this is at your disgression.
Linux on the other hand is the more secure than the other 2 in general. But only if you are strict yourself.
Ex: if someone sent code in a email or other non-public way and gives you a tutorial how to execute it, you should always beware.
The most secure way is to read the code yourself to make sure nothing is fishy going on, and then build your own executable.
@Correct-Syntax Making some pyinstaller build scripts would help with users building their own exe locally in a single call or two. Pyinstaller isn't too hard to maintain after you build a few and get the hang of it.

@Metallicow Thanks for the help. But just in the last weeks I had a lot of installation and Linux problems with addons etc. So I just want to wait until Gimel Studio 0.5 is ready. After 2 years and more than 200 addons and trying out a lot of open source software I have my Blender workflow (after a 10 year break) to make 3d art. And then I don't want to compile, try or learn anymore ;-)
@Correct-Syntax Thank you for making Gimel Studio (for Blender). I think this will become a great helper in 3d rendering.

@MarioPeper I understand. I do it often when I make a box build. Box builds should be LTS(Long term service) or otherwise the software that is installed default on the OS is what you will live with until you upgrade or your PC dies of old age. Completely understandable.
This Works. This is Stable and Tested. I don't want to upgrade. Period. Understandable.

@Metallicow, thanks for helping @MarioPeper. I am still a bit confused (I feel like I missed part of the conversation here or something) as to what @MarioPeper was asking and what you were suggesting. Anyway....

Another thing to note is that if you or anyone else is not familiar with python or reading the code, then the method @Correct-Syntax posted about changing file permissions to executable should be heeded with extreme caution in most cases. But since it is open source and everyone here can see that nothing fishy is going on in the code, then this is at your disgression.

I agree. I'm sorry if, by suggesting that, it seemed fishy to someone. That wasn't my intention. In this case, @MarioPeper was building this himself, so I didn't see an issue here. But you are totally right, @Metallicow -it shouldn't be used without care.

Making some pyinstaller build scripts would help with users building their own exe locally in a single call or two. Pyinstaller isn't too hard to maintain after you build a few and get the hang of it.

O.K. I believe you are referring to creating scripts to build the executable? If so, I do have those already (though I should complete them as they don't copy the customnodes directory, etc): https://github.com/Correct-Syntax/Gimel-Studio/blob/master/Make.bat and https://github.com/Correct-Syntax/Gimel-Studio/blob/master/make
Thanks again for your help!

@MarioPeper,

After 2 years and more than 200 addons and trying out a lot of open source software I have my Blender workflow (after a 10 year break) to make 3d art. And then I don't want to compile, try or learn anymore ;-)

Sounds like you've really worked and spent a lot of time to get your workflow right, so I can understand your position. ;)

Thank you for making Gimel Studio (for Blender). I think this will become a great helper in 3d rendering.

Great. I hope it will be. Your feedback has really helped both for the addon (otherwise the blender addon idea might not have come around for awhile) and for Gimel Studio itself. :+1:

Running Pyinstaller on your init script for the program should generate at least basic build files. *.spec, etc... spending a bit more time to make sure it is right when initialized on other platforms is best.
Usually you would do pyinstaller myscriptlead.py to do the initial try build. Afterwards you may need to tweak what is going on or if it is failing building at some point. You may want to generate the spec/etc... before the build command. It is different for everyone on the 3 major different platforms...
Tho I do think, PyInstaller is the easiest of all the exe/frozen builders, and it does what it does rather well.

Sounds like you've really worked and spent a lot of time to get your workflow right

It was above all a learning and relearning task. But now I finally feel finished. The material/texture task and the slow compositor were the main problem. The main goal was to achieve everything with open source.

@Metallicow, unfortunately I don't fully understand your last comment. Could you clarify, please?
@MarioPeper,

It was above all a learning and relearning task. But now I finally feel finished. The material/texture task and the slow compositor were the main problem. The main goal was to achieve everything with open source.

Certainly. I hope it all works out for you. Maybe you could share your workflow sometime. :)

PyInstaller is a frozen executable builder. It isn't a cross-compiler so when you use it on linux it builds a exe for linux(same thing goes for when you use it on ther platforms). It bundles Python and all its dependencies for you when you use it on your program on at least the 3 major OSes. It has options to dump it to a directory which can be zipped up or depending on the OS is has a single file exe way you can do also if you dont like a lot of files floating around.
You can download it from the website and or whl from pypi and extract it and run it to create a executable. you can even pip install it if you are comfortable with that.
Other frozen exe builders exist but some are unmaintained and others are harder to use, etc... For most simple projects PyInstaller works out of the box, so is easier for noobs and occasional users to build one themselves with a small bit of reading the fine manual(technical).

I have started a blenderartists thread for gathering feedback for improving the blender Gimel Studio bridge addon here.
Thanks for the feedback already given in this Github issue!

Alright, I am closing this issue as the Blender addon is WIP. :)


[WIP] IPA integration to dankrad-3

Move KZG to its own file, and protect it with a flag, ipa becomes the default value.
Not covered by this PR:

endianness when serializing data, this PR is using big endian when the spec requires little endian
deduplication of commitments/fis/yis in multiproof

Codecov Report

Merging #105 (0a94904) into dankrad3-impl (c1df5fb) will decrease coverage by 3.90%.
The diff coverage is 96.66%.

@@                Coverage Diff                @@
##           dankrad3-impl     #105      +/-   ##
=================================================
- Coverage          86.82%   82.91%   -3.91%
=================================================
  Files                  6        8       +2
  Lines                774      521     -253
=================================================
- Hits                 672      432     -240
+ Misses                78       70       -8
+ Partials              24       19       -5

Impacted Files
Coverage Δ

config.go
66.66% <ø> (-28.79%)
:arrow_down:

empty.go
33.33% <66.66%> (ø)

hashednode.go
52.00% <85.71%> (ø)

tree.go
85.01% <96.15%> (+1.72%)
:arrow_up:

config_ipa.go
100.00% <100.00%> (ø)

encoding.go
84.31% <100.00%> (ø)

ipa.go
100.00% <100.00%> (ø)

proof_ipa.go
100.00% <100.00%> (ø)

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 c1df5fb...0a94904. Read the comment docs.


where & how are you translating app ?

couple of commits on project page says that translations are updated.
if you are doing on web, please update README or create CONTRIBUTING page.

Thank you for noticing.
That info is on the Wiki page: https://github.com/andstatus/andstatus/wiki but I agree that it should be moved/copied to README.

thanks a lot :)


added random access test generator

This commit includes a test generator for purely random accesses. Students can play with the parameters to create tests of different sizes. I want to also publish a generator for sequential access tests tomorrow.
@powerjg Can you perhaps give some input as to good approaches for more realistic test scenarios, like block access, etc.?

Why wouldn't you use python for this?!? :)
Testing for cache correctness is really hard. If someone knows a good method it would be a good research paper.
My advice is to think of each feature you need to implement (e.g., in a two way SA cache, you should be able to store exactly two blocks in a set or in a non blocking cache you should be able to have a hit while a miss is outstanding) and make a directed test for each of these. I would use these large random tests at the end of my testing to make sure there aren't any corner cases that I'm missing.
Another hint: make tests that stress corner cases like read/writing different bytes/words from the same block.

Well, I chose to keep it in C++ because I already had the mechanism for writing records to a file written in the record_store code.


Add go:generate command for largest_field_number.canoto.go

largest_field_number.canoto.go is not currently auto-generated when using go generate ./...

The canoto flag defaults to yes so we don't need a separate command here


sw-registration.js is fingerprinted incorrectly when rootURL is set.

I am trying to setup service workers for an ember 3.4 app.  The app is served from a sub directory '/mobile/' so the config/environment.js rootURL is set to '/mobile/'.
In development the sw-registration.js script is added to the index.html page and mobile is prepended.  However when deployed via ember-cli-deploy the  sw-registration.js is fingerprinted and a incorrect '/mobile/' path is added.  (I say incorrect because all other assets are not prefixed by a mobile path).
All assets are fingerprinted and served from a cdn.  I am unsure how or if the app should fingerprint the sw-registration.js file.

I believe it is correct to append the rootURL to the path as the sw.js and sw-registration.js files are not asset files but rather application files.   The difference being asset files can be served from a cdn.

Yes, sw.js and sw-registration.js should have rootURL.
Only sw.js is an 'application' file. It's totally harmless to fingerprint sw-registration and can be served from CDN.

Okay good to know.   If the sw-registration.js file is fingerprinted then shouldn't it be treated like every other asset file and the rootURL not appended?

https://ember-cli.com/user-guide/#deployments
"the asset URLs will not use rootURL and will instead be: https://cdn.example.com/assets/vendor-3b1b39893d8e34a6d0bd44095afcd5c4.js."

Looks like you can update https://github.com/DockYard/ember-service-worker/blob/master/index.js#L47 to make that behaviour work.

Thanks @martndemus for the suggestion.  I started to refactor the add-on to omit the rootURL from the sw-registration.js src if the fingerprint prepend option is present.  But because _getRootURL() function is used by the sw.js file as well, so I punted.
It turns out there is a config option that handles this better any how.  By using the inline registrationStrategy we don't have to worry about the rootURL being appended to the fingerprint.prepend string.
    //ember-cli-build.js
    'ember-service-worker': {
      registrationStrategy: 'inline'
    }

Just ran into this as well, would be good to be able to manually specify this

I've taken a stab at adjusting this. Seems the current logic is fine unless we are dealing with a fingerprinted asset (sw-registration) in production. The serviceWorkerBuilder only uses the root url for the sw.js file so I made that more explicit. Otherwise, the rest of the calls are for sw-registration.js for different registration strategies. Still have tests to write, but figured I'd check to see if this seems like it's going in the right direction.

@eshtadc it looks good to me.  I will pull it into my application and give it a try.

Thanks @arenoir - would love to hear how it works for your scenario "in the wild".

@arenoir Have you had a chance to try this out? I've got a little time to work on it again and add tests, etc. if the approach is reasonable.

My current issue related to this is that my rootURL is set like rootUrl: "", and prepend: "" and yet it's still coming out at /sw-registration-58fcbda0b51af71b8d090b023db785db.js

@jfrux Is that using the PR that we were testing for this issue? https://github.com/DockYard/ember-service-worker/pull/152


Test: Update regenerate.sh

What is the problem that this fixes or functionality that this introduces? Does it fix any open issues?
https://github.com/OpenDevin/OpenDevin/pull/2824#issuecomment-2212309414 Removing the current directory in WSL makes the OS unstable.
Give a brief summary of what the PR does, explaining any non-trivial design decisions
Just removing the directory's content only.

I read #2824 (comment) but I don't understand why this change would result in any useful change in behavior and fix the problem. Could you please provide more evidence or justification for this change?

The detail is around here:
https://github.com/OpenDevin/OpenDevin/pull/2824#issuecomment-2212324325
The regenerate whilst running removes the carpet below the script's feet and then a "getcwd()" call causes an exception and shows up as EFileNotFoundError. It's an annoying circumstance. One has to actually change the folder and get back to re-start the script without error, it's weird.
This should go in, imo.


Fix PHP SDK Demo Error Response Handling

In the PHP SDK, a demo error response is not handled properly as it always shows An error occurred.  While using the demo.
The expected behavior is it needs to show proper error message returned From Loginradius API.

Update LoginRadius new Logo.
Change customObjectByToken  function with getCustomObjectByToken as it is throwing error.

#23


Fixed erratic tests that were relying on previous behaviour

Addressing #414
I fixed test that I could find (there were more than one actually) and deleted a test that was freezing int was deleted (I guess previous behaviour was using ints to increase DateTime and it was meant to make sure the Freeze call didn't affect that).
I ran each test in a loop 5000 times to check and they all passed.

Thank you for your contribution!


More descriptive error upon transfer simulation failure when placing order

Fixes #1085
We have gotten mutliple complaints from people trying to integrate with CowSwap that our order creation errors are the same (InsufficientFunds) in these two cases

User doesn't have enough balance of the token
User hasn't given sufficient allowance to the vault relayer

This PR makes these order creation errors distinct. In particular we use the following errors in the following scenarios:

InsufficientFunds - user doesn't have enough Balance
InsufficientAllowance - Vault Relayer doesn't have enough allowance on behalf of the user
SellAmountOverflows - sell amount (U256) + fee amount (U256) overflow U256 (very pathological case)
TransferSimulationFailure - transfer failed for other reasons (e.g. the token being paused at the moment)

In order to not create more roundtrips in the happy path (e.g. for frontends that make sure users cannot place orders without having given prior approval) we keep the transfer simulation (which covers all 3 cases in one call) and only check the exact failure reason in case it fails.
Test Plan
Added an integration test for the balance fetcher functions. It would be nice to use the order placement script with a custom endpoint (so I can easily create test orders locally)

Codecov Report

Merging #1458 (d11d1f9) into main (3eef426) will decrease coverage by 0.27%.
The diff coverage is 10.48%.

@@            Coverage Diff             @@
##             main    #1458      +/-   ##
==========================================
- Coverage   65.76%   65.49%   -0.28%
==========================================
  Files         155      155
  Lines       30396    30538     +142
==========================================
+ Hits        19991    20001      +10
- Misses      10405    10537     +132

I would agree with @nlordell comment about converting return value of can_transfer from Result to Result<(), TransferError>, would make the code a bit clearer.

I removed has_sufficient_balance and has_sufficient_allowance in favour of a more expressive can_transfer return type (should have already been there for the last two reviews).
Would you be able to take another look if this works now?


Clarifications, Annotations, Cleanup

Some changes that accumulated while reviewing the code in preparation for continuous-billing branch.
Might be a good idea to merge this before it creates unneeded merging conflicts.

Other then the small ned-server change that is still needed, looks good to me


lazy load wallets on startup

Is this an SDK param @tzarebczan ? If you tell me it, I can test it out to make sure it doesn't have any user implications.

No, the proxy needs to load them based on user activity.

@tzarebczan I have a feeling this is solved by https://github.com/lbryio/lbrytv/pull/138


Add image gallery which previews the themes

It would be nice to have a preview of the theme

possible idea https://github.com/opieters/jekyll-image-gallery-example/tree/gh-pages
https://dmnfarrell.github.io/software/jekyll-galleries

I was thinking about this idea too!
I'm not a programmer so I hope somebody can make this.
I keep posting the screenshots here.

Hi, I'm new to open source and want to try to solve some simple problems. Can you assign this issue to me? I would appreciate it!

Hi, I am a university student in Software Engineering Fundamentals at KTH, Stockholm. We, as a group of 5 students, would like to work on this issue. Could you assign us ? (@JEANPRBT, @rickardo-cornelli, @lola20b, @zaina-ram, @Raahitya-14)

I can only assign one person, but you are welcome to work on a solution!

I am so sorry, I had not noticed this was on the secondary project themes.jabref.org.
I will find another issue since we are required to work on the main project. You can un-assign me, I apologize for the inconvenience.

Ah okay, no problem

Yes I am interested ! You can assign me on this one (https://github.com/JabRef/jabref/issues/10661).

Hello, I am a student at the Australian National University. For our team project, we need to contribute to an open-source project. May I be assigned to this task?

I am a member of the Australian National University team.
The issue has been solved on the main repo: https://github.com/JabRef/jabref/pull/12104


build client performance test rigs

**Is your feature request related to a problem? Please describe.
Build the tests that measure the performance bottlenecks
**Describe the solution you'd like
Use design from #733
**Describe alternatives you've considered
NA
**Additional context
NA

See comment  for more reference

[ ] Notification Latency test
As part of notification latency,  Added tests that include

a sender, that sends a notification text (notify: text) continuously to a receiver without any expiry,
sender_test

the first receiver that only receives(without sync), and
receiver_test

a second receiver that listens to the notification from the sender and also updates a key for every 500ms i.e..,( with sync )
receiver2_test

Observations
The latency results were better for the receiver that only received notifications compared to the receiver that received notifications and updated a key simultaneously.
A graphical representation of the same can be found here.
https://docs.google.com/spreadsheets/d/1wY9eFI1OdqaexyR7Ho7ctT6IyNdsdIIB/edit#gid=63467969

Re-tested with the skip_latestNotificationId. Now the latency results are better compared to the previous results. Results can be found in the following sheet.
Tab -1 Previous results(without the fix for skipping latestnotification Id)
Tab 2 - After fix (Receiver that only listens to the notification)
Tab -3 After fix (Receiver that listens to the notifications and updates the key )
https://docs.google.com/spreadsheets/d/1wY9eFI1OdqaexyR7Ho7ctT6IyNdsdIIB/edit#gid=1926778118

Latency tests have been re-verified again after the fix for "skipping latest notification Id ". The results have been better than the previous results that have been taken without the fix. Results can be found in the following sheet.
https://docs.google.com/spreadsheets/d/1wY9eFI1OdqaexyR7Ho7ctT6IyNdsdIIB/edit#gid=243961569
Tab 2 and 3

A sample isolate program.
sample_receiver_isolate.txt

Moving to backlog as the core work in PR50 will be to continue to focus on sync tests, rearchitecting for secure element,  future-proofing our encryption and of course bug fixing


Versioning plan for F# in VS 15.6 and moving forward

This is a more detailed breakdown and tracking issue for #4112.
We have strong motivation to decouple versioning of the F# compiler and tools from the F# language and core library.  We also wish to keep the F# language and F# Core library coupled in version numbers.  The reasoning is as follows:

The F# major language version number will change more and more slowly over time.  Proposed and approved new features still fit snugly in the minor version number.
The F# minor language version is expected to change, but not as often as tooling and SDK versions.
Decoupling the FSharp.Compiler.Service version from the language version has proven to be a good thing, as it has allowed the adoption of SemVer and rapid iteration.  A similar model can be applied for the F# compiler and tooling.
Coupling the compiler version with the language version is not always done in other languages (e.g., C#), and such decoupling hasn't been a problem.

Here's what it should look like:

Visual Studio version
15.5 (current)
15.6
15.7
vNext

F# language version
4.1
4.1
4.4
4.x

FSharp.Core version
<IP_ADDRESS>
4.4.3.x
4.4.4.x
4.4.x.y

FSharp.Core NuGet package version
4.2.x
4.3.x
4.4.x
4.x.y

F# compiler banner
F# Compiler 4.1
F# Compiler 10.x.y for F# 4.1
F# Compiler 11.x.y for F# 4.4
F# Compiler XX.y.z for F# 4.x

VS product Name
Visual F# 4.1
Visual F# 10.x.y for F# 4.1
Visual F# 11.x.y for F# 4.4
Visual F# XX.y.z for F# 4.x

VS product details
Microsoft Visual F# 4.1
Microsoft Visual F# 10.x.y for F# 4.1
Microsoft Visual F# 11.x.y for F# 4.4
Microsoft Visual F# XX.y.z for F# 4.x

F# SDK version
4.1
10.x
11.x
ZZ.x

F# Compiler .dll version
<IP_ADDRESS>
10.x.y.z
11.x.y.z
WW.x.y.z

FSharp.Compiler.Tools version
4.1.x
10.x.y for F# 4.1
11.x.y for F# 4.4
XX.y.z for F# 4.x

VS Assembly versions
15.4.x.y
15.6.x.y
15.7.x.y
vNext.x.y

You'll note a few things:

There will be no F# 4.2 or F# 4.3 language version - it will skip to F# 4.4.  This is because it will bring the F# language, FSharp.Core, and FSharp.Core NuGet package back into sync.
The Compiler and SDK version will start at 10.x.y, and so on. This is to ensure that the F# language version will never catch up, and lets us start on the path of SemVer.
Visual Studio assembly versions will match the VS release. It should be plainly obvious if an assembly is a part of Visual Studio this way.
FSharp.Compiler.Service is not a part of this plan.  Given that it has already been on this separate versioning path, and may need to version independently of the assets Microsoft produces for a number of reasons, we intend on keeping it as-is.

We believe that this will make versioning a bit more sane moving forward, as it gives us the ability to rev tooling at a faster pace than the language, while also laying out a plan to align F# language versions, FSharp.Core versions, and FSharp.Core NuGet package versions.

What if there's features in the Core library that could be released out of band from language changes?

I wish we could find a way to sync the nuget version with the dll version

Agree with @forki, the package version and the DLL versions not matching has caused issues for teams on many occasions.
Related: https://github.com/Microsoft/visualfsharp/issues/3204

@isaacabraham In general, I don't think we plan on releasing FSharp.Core functionality out of band from language choices, but the current versioning scheme of the binary and package do open up that possibility.  It's up for discussion if that final version will be interpreted as a SemVer-style patch version or "new small features" version.  I'd rather keep that version number for bug fixes.
@forki / @chillitom I'm not opposed to making the package version the same as the .dll version.  @dsyme / @KevinRansom?

I mean nobody cares about the concrete version number of anything. (outside of Redmond that is. Redmond has special rules). Just make it predictable and consistent. Like go over to 4.5 for everything. People will appreciate that.

@forki do you have feedback on the above plan with respect to predictability?  From our vantage point, this buys us that, largely because the compiler and tooling is free to follow SemVer and rev as-needed rather than attempt to align with a language version somehow.

@forki's suggest to skip to F# 4.5 at next language update (and thus sync the assembly version and nuget package first two digits) looks quite reasonable:

Visual Studio version
15.5 (current)
15.6
15.7
vNext

F# language version
4.1
4.1
4.5
4.x

FSharp.Core version
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
4.x.0.0

FSharp.Core NuGet package version
4.2.x
4.3.x
4.5.0.x
4.x.0

F# compiler banner
F# Compiler 4.1
F# Compiler 10.x.y for F# 4.1
F# Compiler 11.x.y for F# 4.5
F# Compiler XX.y.z for F# 4.x

VS product Name
Visual F# 4.1
Visual F# 10.x.y for F# 4.1
Visual F# 11.x.y for F# 4.5
Visual F# XX.y.z for F# 4.x

VS product details
Microsoft Visual F# 4.1
Microsoft Visual F# 10.x.y for F# 4.1
Microsoft Visual F# 11.x.y for F# 4.5
Microsoft Visual F# XX.y.z for F# 4.x

F# SDK version
4.1
10.x
11.x
ZZ.x

F# Compiler .dll version
<IP_ADDRESS>
10.x.y.z
11.x.y.z
WW.x.y.z

FSharp.Compiler.Tools version
4.1.x
10.x.y for F# 4.1
11.x.y for F# 4.5
XX.y.z for F# 4.x

VS Assembly versions
15.4.x.y
15.6.x.y
15.7.x.y
vNext.x.y

Any technical concerns with other tools? I like the idea overall.

I spoke with @KevinRansom today, and we don't currently see a technical issue with aligning the FSharp.Core binary and FSharp.Core package to <IP_ADDRESS> and 4.5.0, respectively, in a 15.7 timeframe.  Let's assume that this is the plan.
There is, however, the question that @isaacabraham raised, and @KevinRansom and I spoke about it a bit.  Imagine the following situation:

F# language version revs once over a year
FSharp.Core version could version twice over a year
F# compiler version will version at least twice over a year

In the current proposal, FSharp.Core is held off from versioning due to the F# language version not being ready.  @dsyme, what would be your reasoning for keeping FSharp.Core and F# language versions in lockstep?

I've created an RFC here: https://github.com/fsharp/fslang-design/pull/249
It's probably best to discuss there

In the current proposal, FSharp.Core is held off from versioning due to the F# language version not being ready. @dsyme, what would be your reasoning for keeping FSharp.Core and F# language versions in lockstep?

There's a lot of simplicity value to keeping the versions aligned.  So I think we should probably make it that from 4.5 onwards F# minor language revisions can just be "small" or even empty (i.e. F# 4.8 might be the same language as F# 4.7 with some improvements/adjustments to FSharp.Core).

Traceability is also important. It would be great if there was a way to to get the git commit used for each version produced. Ideally, this information would be available multiple ways:

git tags for versions
the sha in an assembly attribute
some versions document or wiki page

Today, I'm trying to hunt down a sprintf problem causing Unity to blow up and it is really difficult to trace. The F# Compiler version shipping with Mono is not kept in sync with the one from dotnet sdk or Visual Studio. It would be great if there was a way to keep them in sync. Long term, I'm hoping we can just use dotnet from Unity and not have to deal with these differences, but not sure how far out that is.

@ctaggart In terms of process, tags are the easiest option. We'll have to be disciplined about tagging each release.


Ndca_premier_feed needs to support late entries

implemented

closed by pull request #154

Add support for quarter-final round

closed again by pull request #156


JetBrains IDEs Plugin

It would be nice to have JetBrains IDEs support.
https://plugins.jetbrains.com/docs/intellij/developing-plugins.html

This is definitely on the roadmap, see also https://github.com/TypeFox/open-collaboration-tools/issues/67.


Let optional type parameters be names rather than nonTypeNames

The current P4-16 grammar requires all optional type parameters to be non-type names.
But one could want to shadow locally a name that is already a type name with a type parameter.
Examples of files doing so can be found at:
nested-tuple.p4
and
type-shadow.p4 .
I suggest allowing optional type parameters to be any name.
In fact, it already is the case that the P4-16 compiler allows optional type parameters to be any name and not just non-type names.
I will open a PR that modifies the grammar accordingly to this suggestion.

Pull request #636 introduces this suggestion into the grammar.
There is nothing to change in the compiler, as it already works this way.

Associated Pull Request #636 was merged.


[cf-buttons] Incorrect Hover State

Moved from https://github.com/cfpb/cf-buttons/issues/50
Buttons shouldn't use the link:hover color, the contrast is too low. Should use the same white color as the default state.
Current Hover State

Correct Hover State

I noticed this is fixed.
https://cfpb.github.io/capital-framework/components/cf-buttons/


Export context objects that depend on accessing parent context to work when nested

🙋 Feature Request

Export context objects from @react-aria that depend on accessing parent context to function properly. This would allow for forwarding the context to micro frontend applications where each application is isolated in a separate React tree.
🤔 Expected Behavior

It would be great if FocusContext in @react-aria/focus/src/FocusScope and Context in @react-aria/overlays/src/useModal were exported.
😯 Current Behavior

The context objects are not exported.
💁 Possible Solution

Export the context objects. Something like: #3310
🔦 Context

I work on a project which is using webpack module federation to enable micro frontend architecture. Each micro frontend application is isolated in a separate React tree. The isolation has some benefits and was done for a reason but it also comes with a downside of the context values provided in the parent being inaccessible in a micro frontend app, since it's in a different React tree. When you nest components that use ModalProvider or FocusScope, they require accessing data from parent context to function properly. An example of this would be a Dialog component which contains a micro frontend application inside it and that micro application contains a Picker. If the picker dropdown does not have the connection to Dialog's Focus/Modal context, things don't work as expected (for example, selecting an option within the picker dropdown counts as clicking outside the dialog and the dialog does not get aria-hidden attribute when picker's dropdown is open). In order to get components that use @react-aria's FocusScope and ModalProvider to work with this setup, we would need to use the context and render the provider with the same value in the React root of the micro frontend app.
Is exporting these context objects something you would be open to?

We'd prefer not to expose internal contexts. These are implementation details and could change at any time. If we exposed them, this would no longer be possible as they'd become public API.
Without much information, it sounds to me like perhaps your micro frontend architecture is too granular? If you split it such that all components within a modal live within the same react root, you might have an easier time.
In addition, React itself strongly discourages having multiple roots on the page at once. You might want to consider an approach where you expose React components from your split points, and render these within a host component rather than rendering directly into a DOM element as a separate root. This way, everything would be in a single React root, but still split into multiple builds.

We are considering rendering in the same react tree because of these issues and potential concurrency issues in react 18, but at least theoretically it seems to make sense in our setup to isolate our micro frontends as much as possible. In our setup there is a shell application which loads many micro frontends. The most important consideration in rendering those micro frontends in the same react tree is the implicit coupling of the shell application and micro frontends, by having all context providers of the shell application accessible from the micro frontends.
It's true that there is usually some higher level public API on top of each context, and there is no need for directly using context objects. But there are edge cases like this and there are some ways of accommodating for such use case, without compromising on the public API.

Undocumented export with UNSAFE_ prefix. That's what react-router does.
Undocumented export, excluded from typings, while one can ts-expect-error the import and use it on their own risk. Kind of similar to how getCollectionNode is excluded from the public API, but nothing prevents one from accessing it on their own risk.
Exporting a utility, specific to this use case. Recoil.js provides useRecoilBridgeAcrossReactRoots, as an example. But I'm guessing you wouldn't be a fan of it :D

Is any of these approaches something you would consider @devongovett ?

In lack of any better solution, we have been using a custom webpack loader to patch @react-aria/overlays and @react-aria/focus to export the context objects. It's obviously a quite fragile patch, causing lots of maintenance overhead so far.
Considering the suggested ways of exporting those context objects won't affect the public API, could you consider exporting them? :)

Closing as we do not want to expose these contexts right now.


A Conf2ScopeMapping is not used when added after a call to MavenPom.whenConfigured

Expected Behavior
When using the maven plugin, it should be possible to add a Conf2ScopeMapping at any time before the pom is produced irrespective of whether whenConfigured actions have been registered or not.
Current Behavior
If a Conf2ScopeMapping is added after the whenConfigured action then that mapping is not available to the PomDependenciesConverter when DefaultMavenPom.getEffectivePom is called.
As a result, the generated pom.xml may be missing some dependencies and is thus invalid.
This appears to occur because org.gradle.api.publication.maven.internal.pom.DefaultMavenPomFactory.create() is implemented as follows
public MavenPom create() {
    return new DefaultMavenPom(configurationContainer,
            new DefaultConf2ScopeMappingContainer(conf2ScopeMappingContainer.getMappings()), pomDependenciesConverter, fileResolver);
}

i.e. the mappings are copied from Conf2ScopeMappingContainer into a new DefaultConf2ScopeMappingContainer when the MavenPom is created
secondly org.gradle.api.publication.maven.internal.BasePomFilterContainer.pom(Closure) is implemented as
public MavenPom pom(Closure configureClosure) {
    return ConfigureUtil.configure(configureClosure, getPom());
}

i.e. this triggers the creation of the maven pom and hence the mappings are copied.
Context
This situation has been noticed when

a project as multiple sourceSets with different compile configurations
the sourcesets are combined into a single artifact published to a maven repository
the build uses a variety of plugins that configure the underlying gradle project based on the contents of the build.gradle (and hence the plugin defers its configuration using projectsEvaluated and/or configuration tasks

Steps to Reproduce (for bugs)
The following build.gradle can reproduce the issue
apply plugin: 'java'
apply plugin: 'maven'

sourceSets {
	generated
}

configurations {
	generatedCompile
	compile {
		extendsFrom generatedCompile
	}
}

dependencies {
	compile sourceSets.generated.output
}

project.tasks.jar {
	from sourceSets.generated.output
}

dependencies {
	generatedCompile 'com.google.guava:guava:20.0'
	compile 'com.google.inject:guice:4.+'
	testCompile 'org.testng:testng:6.8+'
	testCompile 'org.hamcrest:hamcrest-all:1.3+'
}

repositories {
	mavenCentral()
}

if (project.hasProperty('triggerBug')) {
	gradle.projectsEvaluated {
		project.conf2ScopeMappings.addMapping(MavenPlugin.COMPILE_PRIORITY + 1, configurations.generatedCompile, Conf2ScopeMappingContainer.COMPILE)
	}
} else {
	project.conf2ScopeMappings.addMapping(MavenPlugin.COMPILE_PRIORITY + 1, configurations.generatedCompile, Conf2ScopeMappingContainer.COMPILE)
}

tasks.install {
	group = 'Upload'
	repositories.mavenInstaller {
		pom.whenConfigured { generatedPom ->
			generatedPom.project {
				name = 'this is a test install'
				description = 'it really is a test install'
			}
		}
	}
}

Execute as
gradle clean install

the resulting pom.xml will contain
<name>this is a test install</name>
<description>it really is a test install</description>
<dependencies>
  <dependency>
	<groupId>com.google.inject</groupId>
	<artifactId>guice</artifactId>
	<version>4.+</version>
	<scope>compile</scope>
  </dependency>
  <dependency>
	<groupId>com.google.guava</groupId>
	<artifactId>guava</artifactId>
	<version>20.0</version>
	<scope>compile</scope>
  </dependency>
  <dependency>
	<groupId>org.testng</groupId>
	<artifactId>testng</artifactId>
	<version>6.8+</version>
	<scope>test</scope>
  </dependency>
  <dependency>
	<groupId>org.hamcrest</groupId>
	<artifactId>hamcrest-all</artifactId>
	<version>1.3+</version>
	<scope>test</scope>
  </dependency>
</dependencies>

Execute as
gradle -PtriggerBug=true clean install

the resulting pom.xml will contain
<name>this is a test install</name>
<description>it really is a test install</description>
<dependencies>
  <dependency>
	<groupId>com.google.inject</groupId>
	<artifactId>guice</artifactId>
	<version>4.+</version>
	<scope>compile</scope>
  </dependency>
  <dependency>
	<groupId>org.testng</groupId>
	<artifactId>testng</artifactId>
	<version>6.8+</version>
	<scope>test</scope>
  </dependency>
  <dependency>
	<groupId>org.hamcrest</groupId>
	<artifactId>hamcrest-all</artifactId>
	<version>1.3+</version>
	<scope>test</scope>
  </dependency>
</dependencies>

This means

when Conf2ScopeMapping.addMapping is called before MavenPom.whenConfigured, the mapping is accounted for during dependency conversion
when Conf2ScopeMapping.addMapping is called after MavenPom.whenConfigured, the mapping is NOT accounted for during dependency conversion
the action registered on the MavenPom is executed in either case

Your Environment
I am unable to upload information to a cloud service. The build environment is a vanilla gradle 3.2.1 running a recent java8
$ ./gradlew -version

------------------------------------------------------------
Gradle 3.2.1
------------------------------------------------------------

Build time:   2016-11-22 15:19:54 UTC
Revision:     83b485b914fd4f335ad0e66af9d14aad458d2cc5

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_101 (Oracle Corporation 25.101-b13)
OS:           Windows 7 6.1 amd64

http://gradle.1045684.n5.nabble.com/pom-generation-and-inherited-dependencies-td1436197.html

The maven plugin (together with the core Upload task) are being replaced by the maven-publish plugin. As such, we don't plan on making changes to improve the (now legacy) Conf2ScopeMapping. Expect to see this type deprecated in Gradle 6.0, for possible removal in Gradle 7.0.


Feature ancestry

Feature adds the ability for an inline pattern to define a list of ancestor tag names that should be avoided.  If a pattern would create a descendant of one of the listed tag names, the pattern will not match.

Suggested changes have been made, so I'm all done unless there are more suggestions.  Whenever you get back, just let me know if there is anything else that needs to be addressed.


trouble running tests for smaller-image class

Challenge Size your Images has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14.
Please describe how to reproduce this issue, and include links to screenshots if possible.
 But your code is incorrect.
GitHub Issues are for reporting bugs on the website only.
Please use the HelpJavaScript chat room for getting challenge related help.
Happy Coding.


Set up CI to auto-publish @misk/* packages to NPM on each master commit

Need to be able to store NPM token in CI https://rushjs.io/pages/maintainer/publishing/

Fixed with https://github.com/cashapp/misk-web/pull/840


Auto-update go-utils to latest version

Beep boop I am a bot
This is an automatically created PR to change keptn/go-utils to version af3fbfee0dea5fc6828b3e80bac73af106b3c221.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #2553   +/-   ##
=======================================
  Coverage   33.20%   33.20%
=======================================
  Files         160      160
  Lines        8879     8879
  Branches      185      185
=======================================
  Hits         2948     2948
  Misses       5433     5433
  Partials      498      498

Flag
Coverage Δ

#moduleA
23.09% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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 3eb1ec0...a799567. Read the comment docs.


Update admin-users-licenses-roles.md

The DvDSUser got renamed in latest iteration to more meaningful name.


Add different interface to distinguish the SQLTokens for startIndex and stopIndex.

Fixes #2275.

Pull Request Test Coverage Report for Build 7891

11 of 22 (50.0%)  changed or added relevant lines in 7 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.002%) to 55.686%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sharding-core/sharding-core-parse/sharding-core-parse-common/src/main/java/org/apache/shardingsphere/core/parse/antlr/extractor/impl/common/table/TableExtractor.java
0
1
0.0%

sharding-core/sharding-core-parse/sharding-core-parse-common/src/main/java/org/apache/shardingsphere/core/parse/antlr/sql/token/ItemsToken.java
0
1
0.0%

sharding-core/sharding-core-parse/sharding-core-parse-common/src/main/java/org/apache/shardingsphere/core/parse/old/parser/sql/dml/select/AbstractSelectParser.java
0
1
0.0%

sharding-core/sharding-core-parse/sharding-core-parse-mysql/src/main/java/org/apache/shardingsphere/core/parse/optimizer/MySQLSelectOptimizer.java
0
1
0.0%

sharding-core/sharding-core-parse/sharding-core-parse-common/src/main/java/org/apache/shardingsphere/core/parse/antlr/sql/token/TableToken.java
0
2
0.0%

sharding-core/sharding-core-rewrite/src/main/java/org/apache/shardingsphere/core/rewrite/EncryptSQLRewriteEngine.java
4
6
66.67%

sharding-core/sharding-core-rewrite/src/main/java/org/apache/shardingsphere/core/rewrite/SQLRewriteEngine.java
7
10
70.0%

Files with Coverage Reduction
New Missed Lines
%

sharding-core/sharding-core-parse/sharding-core-parse-common/src/main/java/org/apache/shardingsphere/core/parse/antlr/sql/token/TableToken.java
2
0.0%

Totals

Change from base Build 7890:
0.002%

Covered Lines:
8726

Relevant Lines:
15670

💛  - Coveralls


feat(STONEINTG-523): Report status of integration tests into snapshot

An annotation (test.appstudio.openshift.io/status) is added to snapshot and updated when condition of integration tests changes.
This annotation contains metadata of all tests which have been created for the particular snapshot.
Example:
test.appstudio.openshift.io/status: [
  {
    "scenario": "scenario-1",
    "Status": "EnvironmentProvisionError",
    "timestamp": "2023-07-26T16:57:49+02:00",
    "details": "Failed ..."
  }
]

TODOs

[x] agrree on struct/constants/functions naming
[x] docstrings
[x] unittest coverage
[x] devtesting if conflicts are not happening
[x] missing code: SEB controller, for reporting statuses of SEBs
[x] missing code: testpipeline controller, for reporting statuses of PLRs
[x] may we need another status to cover phase when env is being provisioned, but test PLR is not running yet?
[x] update predicates to ignore annotation changes in snapshot
[x] performance improvement to prevent fetching test task results too many times
[x] update controller diagrams
[ ] remove all // TODO comments
[x] validation of snapshot data loaded from json value
[x] get details why SEB deployment failed into details

Maintainers will complete the following section

[ ] Commit messages are descriptive enough (hints)
[ ] Code coverage from testing does not decrease and new code is covered
[ ] Controllers diagrams are updated when PR changes controllers code  (if applicable)

Example:
oc get snapshot application-sample-tlxhn -o json | jq -r '.metadata.annotations["test.appstudio.openshift.io/status"]' | jq
[
  {
    "scenario": "example-fail",
    "status": "Pending",
    "timestamp": "2023-08-17T09:46:01.931815806Z",
    "details": "Pending"
  },
  {
    "scenario": "example-int-pass-yes",
    "status": "Pending",
    "timestamp": "2023-08-17T09:46:01.931828139Z",
    "details": "Pending"
  },
  {
    "scenario": "example-pass",
    "status": "Pending",
    "timestamp": "2023-08-17T09:46:01.931832387Z",
    "details": "Pending"
  }
]

rebased onto https://github.com/redhat-appstudio/integration-service/pull/284

Looks good so far, will check again once the solution for update conflict is included.

Conflict resolved and rebased

rebased & resolved conflict

LGTM, just how to deal with the code coverage?

LGTM, just how to deal with the code coverage?

We agreed to make follow up story to increase it


Support non pre-parsed PSR-7 request body

Because PSR-7 specification only specify that getParsedBody() may
return the parsed body for application/json, we cannot assume that it
is always the case. So if the value returned parsed body is an empty array,
it means we should try to parse it ourselves (null would mean no body at
all according to spec).
With this modification we try to used given parsed body, but fallback on
trying to parse the body if necessary. This leave the door open to custom
implementation of parsing if needed, while making it easier to use out of
the box.
This is in direct response to https://github.com/webonyx/graphql-php/issues/120#issuecomment-346949979

Coverage increased (+0.003%) to 92.649% when pulling 11c9429fabd8b646356fc30c65e7bb7a4e7f8a17 on PowerKiKi:support-non-parsed-psr7 into eaadae4a5b3fe989ee4f614ab1c0ada7df4180cd on webonyx:master.


(flux with helm) fluxctl release --user is not respected

$ fluxctl release --controller=default:fluxhelmrelease/bc-release-service --update-all-images --user<EMAIL_ADDRESS>--message "BC-3916: update latest image" -vv
Submitting release ...
CONTROLLER                                  STATUS   UPDATES
default:fluxhelmrelease/bc-release-service  success  chart-image: bcdocker-staging-rnd-artifacts.intelerad.com/bc-release-service:1.0.0 -> 1.0.1-lvu-testing
Commit pushed:  e93cf00
Commit applied: e93cf00

fluxd logs:
ts=2018-09-27T16:23:03.208744265Z caller=daemon.go:582 component=daemon event="Released: bcdocker-staging-rnd-artifacts.intelerad.com/bc-release-service:1.0.1-lvu-testing to default:fluxhelmrelease/bc-release-service, by<EMAIL_ADDRESS>with message \"BC-3916: update latest image\"" logupstream=false

But the actual commit to the Flux repo is using the user previously given by --set git.user= and --set git.email= when we helm install the flux chart into k8s.
I would have expected the commit to use the --user value supplied to fluxctl.

Have you given fluxd the flag --git-set-author as well? It's a bit counter-intuitive, but you need that as well.

Have you given fluxd the flag --git-set-author as well? It's a bit counter-intuitive, but you need that as well.

Nope, we didn't do that.  That would correspond do the chart value git.setAuthor I assume.
Will test and report back.

Yup using helm install flux with --set git.setAuthor=true does honor the --user option with fluxctl.
However, it even use my git user configured in my ~/.gitconfig even if I did not supply the --user with fluxctl while I have given --set git.user= and --set git.email= when installing flux helm chart.
I guess I can live with this behavior but can you just confirm this is by design and not a sneaky bug?

can you just confirm this is by design and not a sneaky bug?

It's by design -- fluxctl gets those values from git config, deliberately. It was intended as a convenience; if it's not what you expected or wanted, maybe we could add a flag or environment variable to disable that behaviour.

As I use this, I think I like the current convenience behavior. Closing.


c.req.valid() showing some errors when using validator module in a route

What version of Hono are you using?
4.1.4
What runtime/platform is your app running on?
Bun
What steps can reproduce the bug?
ts error is raised when using the hono built in validator for a route setup in this general format
The error occurs when using c.req.valid(). The function still works but it just gives this weird parsing error about type assignments
Argument of type 'string' is not assignable to parameter of type 'never'.ts(2345)
app.get("someroute", (c) => {...})
.post(valdator("form", (value, c) => {...}), (c) => {
const {data1, data2} = c.req.valid("form") //error shown here
})

I am working around it doing this:
app.get("someroute", (c) => {...});
.post("someroute", valdator("form", (value, c) => {...}), (c) => {
const {data1, data2} = c.req.valid("form")
})

I'm adding redundant route declarations which is not ideal
What is the expected behavior?
there should be no error
What do you see instead?
Argument of type 'string' is not assignable to parameter of type 'never'.ts(2345)
Additional information
thanks in advance!
No response

Hi @szabbbbu
You should return the actual values having expected types in the validator:
app
  .get('someroute', (c) => {
    return c.json({})
  })
  .post(
    validator('form', (value, c) => {
      return {
        data1: 'abc',
        data2: 'abc'
      }
    }),
    (c) => {
      const { data1, data2 } = c.req.valid('form')
      return c.json({})
    }
  )


Windows tags are not remembered upon restart

When Workspacer restarts itself, for example by switching screen or disconnecting the HDMI cable, upon restart, it forgot where windows should go. It doesn't even execute the auto-tagging of configuration which is only executed during startup I guess. But the main issue is that the windows tags are not remembered. I think that it is the job of the Workspacer Watcher, but it doesn't work in 0.9.10.

This is a long-standing issuee document by rick himself in #15. I had a look at the code and I believe the issues lies somewhere with the InitializeWithState function. While it adds the right filters to the global filter list (as far as I csn tell) it does not seem to apply them afterwards.
Another critical issue in my view, will prioritize this along with #207. Hopefully we can get these fixed ASAP


Don't default to permanent if falsy permitType

The permit type field should never be falsy, but at times javascript eludes understanding
Notion ticket link
[16] For new temporary permit holders, under their Past APPs section, it lists them as having a permanent permit despite their recent permit request being a temporary one

Implementation description

I have still been unable to replicate this bug on my end, however I think it may be worth asking rcd if this change has any effect on their end.

Checklist

[ ] My PR name is descriptive, is in imperative tense and starts with one of the following: [Feature],[Improvement] or [Fix],
[ ] I have run the appropriate linter(s)
[ ] I have requested a review from the RCD team on GitHub, or specific people who are associated with this ticket

but at times JavaScript eludes understanding

😂
@ChinemeremChigbo one thought, I think this may be related to #273, another of the unreleased fixes. If permit type was previously not queried from the backend, then it would be defaulting to PERMANENT on the frontend

but at times JavaScript eludes understanding

😂
@ChinemeremChigbo one thought, I think this may be related to #273, another of the unreleased fixes. If permit type was previously not queried from the backend, then it would be defaulting to PERMANENT on the frontend

Ahh interesting, should I close this PR then? I don't think that this permitType should ever be falsy, so I don't really think this change will make any difference.

@ChinemeremChigbo Yeah let's close it. It seems #273 was indeed the fix based on RCD's latest email.


Receiving messages is stopping intermittently

From last three days, I am observing that the message-receiving is getting stopped intermittently for 40 mins to an hour and then messages incoming starts again. Anyone has faced this issue recently or earlier?
I am using tdlib version: 1.8.23, which was working fine before 3-4 days.
Kindly help.

How many items are returned by the call to getActiveSessions?

@levlam thanks for the response.
How can I find that in the service which is already running?

Check in any other app of the user.

@levlam
There are multiple tdLib sessions, out of which one is current and 4 are historical.
Can this be the reason for message interruption?

Can someone please provide any hints around this? Additionally, the message volume is reduced to less than half.

There should be no issues. Do you have the issue in a specific joined chat?

yes, there are multiple chats from which the messages are not coming in. The messages were coming earlier from the same channel earlier.

yes. I am part of the chats.

Despite possible. I see no specific reason for message delivery delays to be that big.


[Request Local Procedure] table 7317 "Warehouse Receipt Line" - CalcBaseQty

Describe the request
Old code:
local procedure CalcBaseQty(Qty: Decimal; FromFieldName: Text; ToFieldName: Text): Decimal

New code:
procedure CalcBaseQty(Qty: Decimal; FromFieldName: Text; ToFieldName: Text): Decimal

Additional context
In table 7321 "Warehouse Shipment Line" the local procedure CalcBaseQty has been made global in an earlier release. Why not perform the same action on the receipt side
Internal work item: AB#498959

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 18704.


Use connection customizer

Summary
I discovered that our connection pool (R2D2) has a more native way to apply operations to each of the underlying Sqlite connections. You can specify a struct that implements the CustomizeConnection trait when you are setting up the pool. The on_acquire function will then be called on each new connection created by the pool.
This seems preferable to applying it to the connections after they've already been pulled from the pool, since we don't know whether the connection is new or is being re-used.

While this seems like a good idea, when I combine it with PRAGMA journal_mode = WAL in any way I get something like 10 database is locked errors per unit test, which is weird. The tests actually pass, but it can't be a good sign. Trying to figure out how to resolve that before merging.


Changed .gif image to data-uri

Hi!
For the android banner, your css links to one .gif image.
To simplify deployment, I converted that image to a base64 data-uri.
According to http://caniuse.com/#feat=datauri it should be supported on all Android versions.

Dup of #48


ci(workflow): add yarn' cache from setup-node action to 'e2e-with-cypress' job

Summary
Follow up from https://github.com/netlify/netlify-cms/pull/5924

Opened PR to follow up https://github.com/netlify/netlify-cms/pull/5924 @erezrokah

Once this PR is merged and assure everything is good I will go for the performance comparison for the rest: https://github.com/netlify/netlify-cms/pull/5924#issuecomment-956336755


Server not started when trying to trigger calculation

When I try to evaluate an expression by shorcut e.g. Ctrl+Shift+Alt+N, VS Code will pop a Activating the server... Please retry for a moment., but eventually it is not activated. Not sure if this Violation is related, which only shows up during such unsuccessful attempts:
[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider
marking event handler as 'passive' to make the page more responsive. See
https://www.chromestatus.com/feature/5745543795965952

However, I can manually start the server by entering the extension path and python server.py.
Version: 1.6.0
VS Code: 1.85.0-insider
OS: Debian 6.5.10-1 x86_64 GNU/Linux

When I try to evaluate an expression by shorcut e.g. Ctrl+Shift+Alt+N, VS Code will pop a Activating the server... Please retry for a moment., but eventually it is not activated. Not sure if this Violation is related, which only shows up during such unsuccessful attempts:
[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider
marking event handler as 'passive' to make the page more responsive. See
https://www.chromestatus.com/feature/5745543795965952

However, I can manually start the server by entering the extension path and python server.py.
Version: 1.6.0 VS Code: 1.85.0-insider OS: Debian 6.5.10-1 x86_64 GNU/Linux

hello,i encountered the same problem and tried for many times with no success, have you finished it?

I appear to be having the same issue, have either of you found a solution?

There is a work around. Start the server manually, similarly to the following:
Using Windows:
C:\Users\charl.vscode\extensions\orangex4.latex-sympy-calculator-1.6.0>python server.py
This allows the calculator to work.


add py.typed to package

Codecov Report
Base: 71.61% // Head: 70.40% // Decreases project coverage by -1.21% :warning:

Coverage data is based on head (dcfb605) compared to base (e5355c7).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #184      +/-   ##
==========================================
- Coverage   71.61%   70.40%   -1.22%
==========================================
  Files          25       25
  Lines        1649     1649
  Branches      207      171      -36
==========================================
- Hits         1181     1161      -20
- Misses        438      459      +21
+ Partials       30       29       -1

Impacted Files
Coverage Δ

src/dvc_objects/fs/system.py
63.23% <0.00%> (-20.59%)
:arrow_down:

tests/test_reflink.py
87.50% <0.00%> (-12.50%)
:arrow_down:

src/dvc_objects/fs/path.py
51.48% <0.00%> (-1.99%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


python3Packages.aiohue: 2.5.0 -> 2.5.1

Motivation for this change
Update to latest upstream release 2.5.1
Change log: https://github.com/home-assistant-libs/aiohue/releases/tag/2.5.1

Related Home Assistant change: https://github.com/home-assistant/core/pull/51447
Target Home Assistant release: current (only dependency update, no code changes)

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 127512 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.aiohue
python39Packages.aiohue


Regular vehicles can get out of the way for emergency vehicles

Bokker12: "I see that emergency cars stop for other cars at junctions, roundabounds etc. can you mod your mod that ai cars go to the side if there is an emergency car comming up? I know this is a job what is pretty hard I guess, but I'd like to know your answer if you are gonna do that or try it?"

moved


Implement common graphics primitives

Implement common graphics options like fillpattern (I'd expect to see it as a property on Paint), or expose a method for user-defined Shaders to be used for adding complex stroking/filling operations.
Something like:
https://developer.apple.com/reference/coregraphics/cgcontext/1456334-setfillpattern

Can you give a few details on what the use case is? Thanks!

https://docs.google.com/drawings/d/1GdnpumvTsGcTjRbh2tYf2LPFUFiklktUfggYsbEusuY/edit?usp=sharing

Nice! Bonus points for the diagrams. Very cool.

Is this just about dashed lines, or something else?

Dashed lines is the current case (we want them for some Aplos charts), but imagine somebody who wants to implement drawings.google.com in Flutter.

https://fiddle.skia.org/c/@skpaint_path_1d_path_effect

I recommend filing one issue per specific request. I'm focusing this one on dashed lines.
I don't think we should expose dedicated dashed lines APIs. It goes contrary to our design principles, which is to expose features that are fast and features which cannot be done any other way. Dashed lines are, as I understand it, quite slow, and can already be done (just do the dashing manually and draw the resulting path). I don't think we should expose a dedicated dashed line API because it will make people think that the feature is fast when it isn't.

Let's double-check the performance to put some numbers behind fast and slow.  I think it would be useful to know the performance ratio between the following:

Drawing a undashed line.
Drawing a dashed line with a stroke style.
Drawing a dashed line with individual drawRect calls.

Specifically, your argument is the strongest when (2) and (3) are close to each other but far from (1).  If (1) and (2) are close but far from (3), then we might want to add support for (2).

(Maybe (3) should be a Path)

Looks like Skia already has a similar benchmark in DashBench.  We can ask them what it shows.

Looks like they have a specialized GPU ops for dashed lines and circles (see GrDashOp), which makes use a the fragment shader.

I completely agree that if (1) and (2) are closer to each other than (2) and some variant of (3), then it makes sense to expose a dedicated API.

Dupe of 4858.

Looks like Skia already has a similar benchmark in DashBench. We can ask them what it shows.

@abarth Did you get the benchmark result ?

Did you get the benchmark result ?

I did not.

Looks like they have a specialized GPU ops for dashed lines and circles (see GrDashOp), which makes use a the fragment shader.

That sounds like it should be performant enough..
Does flutter provide access to that by any means?  I.E. using that hardware accelerated drawing of dashed lines.
Regardless, this is clearly a feature people are going to want, and that should be convenient to use.
Android, iOS, and web support dashed lines, when one of those developers comes to flutter and sees it isn't an option in the BorderStyles enum they go "Wow, flutter doesn't have dashed borders yet?  That's an indicator that it's missing some key features alternatives have".
As a note of the prevelance of dashed lines, even the editor I'm using to type right now is displaying a dashed line above "Attach files" and below the text editing area.
The example use case I have is that there a page that graphically displays data with colored boxes positioned based on certain values, the color indicates which "driver" pertains to the item being displayed by the box.  You can change drivers using a dropdown as you plan things out, but until they're saved the client wants to indicate that it's a "drafted" selection of driver by putting a dashed line around the box.  This should be as easy as adding a border to the box.
Am I correct in understanding I have to do something like use a canvas and paint a path?  That seems like a poor experience for flutter developers wanting to do something usually trivial.

how do I create a dotter circle with custom painter in flutter. I use this code it gives me a normal circle but I want to have a dotted circle:!!
canvas.DashedCircle(Offset(-A, LEN), 170, paint);
thnx :)

@zhen1991
Please consider asking support questions in one of the other channels listed at http://flutter.io/support .


Faster newHead notifications

Describe the feature
Currently we're emitting a new chain event after we've committed new block(s) to disk on FCU
By this time we already know the chain is valid but need to flush to disk first to update the "latest". A db commit is only expected to fail in the event of a db error because the new chain has been validated.
This guarantees that once we've emitted a new chain event the corresponding state for the new head is available.
This is also slow and means that newHead updates can be trailing by a few 100ms.
When we're committing a new block we have the corresponding (valid) state in memory, which means we could map this to the "latest" tag right away and emit a chain update earlier.
Emitting chain updates before the db commit could introduce a few race conditions, for example
user receives newHead event, queries state using the newHead's hash, which is currently being inserted.
To mitigate these, we'd need to keep track of in progress inserts and account for this, we also need to make the state that's being inserted available before we emit the event:
struct LatestState {
  committing: AtomicBool,
  latestState: RwLock<Option<Block + State>>
}

which needs to be checked by the provider when handling BlockId conversions, this part needs to cover all edge cases.
Reorgs and multiblock commits are problematic and even more complex, so those should be processed as we do currently.
this is somewhat related to #6104
Additional context
No response

Maybe I can take a look?

we haven't decided on a path forward for this but eventually, there'll be some tasks

Getting the head block with the same speed as geth is critical for many kinds of real-time chain analytics.

this is important! happy to help

I run both geth and reth, and just keeping geth atm because I need fast heads.
If reth can notify and access state as fast as geth, I can finally drop geth and just relay on reth, as it will  be on par or better in all aspects.
This will be nice to have since running multiple nodes it's a bit of headache and have its problems (bandwidth, storage etc)
I think many other people are in the same situation as me.

Any progress om this one?

Will this fix arrive in the Beta version?

+1 on this one.
(I remember there was another issue opened about the same topic)
On Wed, Mar 20, 2024 at 9:48 PM github-actions[bot] <
@.***> wrote:

This issue is stale because it has been open for 21 days with no activity.
—
Reply to this email directly, view it on GitHub
https://github.com/paradigmxyz/reth/issues/6286#issuecomment-2011037780,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BF5TRZZULTR3PK4GBWYFMF3YZI37LAVCNFSM6AAAAABCRPVXUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJRGAZTONZYGA
.
You are receiving this because you commented.Message ID:
@.***>

closing in favor #8742 which solves this


visit question token

Fixes https://github.com/Microsoft/TypeScript/issues/16707

Can you take another look, @rbuckton ?


Comparison operations API

About implementing comparison operations as functions, before I'd like to discuss the API first.
Operations: http://php.net/manual/en/language.operators.comparison.php
Suggestions are:

PHP Doc Name
API

Equal
equal, equals, eq

Identical
identical, strict_eq, seq

Not equal
not_equal, not_equals, neq

Not identical
not_identical, not_strict_eq, nseq

Less than
less_than, lt

Greater than
greater_than, gt

Less than or equal to
less_than_or_eq, lte

Greater than or equal to
greater_than_or_eq, gte

Spaceship
spaceship, lteqgt

I personally prefer the abbreviations. e.g.:
// using cond/always from #123

$message = cond([
    [lte(16), always('Can drive in USA')],
    [lte(18), always('Can drive and drink in Brazil')],
    [lte(21), always('Can drink in USA')],
    [gte(60), always('Getting old')],
]);

echo $message(18); // ~> Can drive and drink in Brazil
echo $message(60); // ~> Getting old

Here are my preferences:

PHP Doc Name
API

Equal
equal

Identical
identical

Not equal
not_equal

Not identical
not_identical

Less than
less_than

Greater than
greater_than

Less than or equal to
less_than_or_equal

Greater than or equal to
greater_than_or_equal

Spaceship
lexicographic_compare

Ok, seems good, just crossed my mind that would be better to use full names and let abbreviations for use alias:
use Functional\greater_than_or_equal as gte;