use relative paths in qt.conf

qt.conf supports relative paths, it's not necessary to hard code the conda environment prefix. We use this successfully in portable conda environments with PyMOL.

removes the post-link script on Windows
removes Binaries and Libraries entries from qt.conf, since they already have default values

Thanks for your help on this, sorry it has taken is so long to review. Since this is an older PR, I'll close it. We'll take this into account though as we move forward.


Custom Cell: Can not link from custom .xib to the optionalLabel of the DropDownCell

I have installed DropDown via Carthage.
and of course it lets me using the build version of DropDown in my project.
So i have no way to connect my UILabel from my custom cell to the DropDownCell.
Any solution to resolve this problem?

Bump @kevin-hirsch - is it possible to use Custom Layouts when using DropDown via Carthage?


New Community Toolkit Compositable Icon/Logo Branding

Following up from discussions here and here from other repos.
Background
I wanted to 'revamp' the discussion here in our design repo as we move forward with more/new toolkits and our Toolkit Labs in the future.
At present our current 'Toolkit' icon is pretty basic and flat from the prior MDL2 asset set, as @niels9001 pointed out in the issue above. We need to evaluate about updating to the more modern revamp going on across Microsoft.
In addition, we've been branching to multiple related projects as we've grown our mission as well as starting with more incubation and experimental projects.
Goals
I think it'd be useful for us to have a core logo/icon that is connected to our Community Toolkit branding/mission:

We want to be the home for .NET based Community Toolkits which are partnering the community with engineers, Microsoft MVPs, and the teams working on those technologies.

Something that we can use in our GitHub branding and general communications when talking about the 'Community Toolkit' effort as a whole.
In addition, we have different sub-projects which would be nice to have connected, but unique branding to associate with their project.
We really want to feel like a cohesive entity when engaging our different communities. At the same time, we also want it to be clear when packages/projects are targeted towards specific technologies/platforms within .NET so that they can aid in directly developers to the proper project/resources when looking for resources or engaging the project on GitHub itself.
Proposal
I think having a composable system would be useful here where we can take the main core mark and add either a technology mark or our 'experimental' mark branding on top of it in a coherent way. (Think Edge/VS with their dev/canary/beta labels.)
This would also let us expand in the future if we onboard new toolkits in the future.
As our core active projects, we currently have:

.NET Community Toolkit
MAUI Community Toolkit
Windows Community Toolkit

And we have the new Labs for Windows coming as well. (And may still do more with Graph in the future ~2023, though we currently brand that under Windows mainly.)
Example
To be clear, everything in this section is for illustration purposes only towards the concept of compositing elements for a system and not part of a proposal to use these emojis as the branding itself. 😉
For instance, suppose we had a new logo like this for our central mark (which we can use for the GitHub org and central landing sites for docs/wiki):

And if we had specific sub-marks for each tech like .NET, MAUI, and Windows:

And a separate mark for Labs:

So then we could combine them for each project:

Or to reference Labs in general:

Or to reference a specific project for Labs, like Labs for Windows:

Challenges

Finding something that won't be cluttered when combining all three bits of information?
Testing with community if distinguished enough to convey the project branding?
Still associated as a central brand together?

Thoughts?
FYI @brminnick @sergio0694 @nmetulev @niels9001 @mdtauk

Great initial questions @mdtauk, thanks!

Does this "master" brand/mark need to be distinctive, as in a brand that works without wordmark and context, or just illustrative of a "toolkit", and feel Fluent?

I think the main/core mark would rarely be used on its own without any context. So, it'll always probably show up as "🧰 Community Toolkits" or something either as part of the GitHub org/docs/wikis here or in any communications we send out. It certainly needs to have some distinctiveness as a mark, but it doesn't need to convey everything alone. I think you called out the proper keyword of 'toolkit' there though for sure. It's probably most important for the Core + Tech marks to stand out the best, as they'd end up as our NuGet icons for instance which will be tied to other misc names and more stand-alone until someone digs into descriptions/info.

Does it need to reflect the technology, so Visual Studio branded, or in Microsoft colours?

I think if we aligned to any color scheme or guidance it'd be around the .NET branding guidelines. We definitely want some association to the .NET world as that's our main focus/expertise in the communities we've been engaging. Thought at the same time, I don't think that has to be a core tenant to convey if it's at odds with the other goals here.

Do we use existing technology marks with this? (WinUI logo, WPF icons, XAML, C# icons and colouring?)

This is a good question on usage rights of those things, and I don't think all technologies have a mark at the moment (like MAUI for instance). It may of course help with recognition I suppose. At least on the WinUI side I know @ryandemopoulos could maybe chime in here for us about thoughts on more tightly-coupling the brandings together or not.
I think the main concern here with direct usage is if folks would get confused about ownership of the projects or associations for support.

Regarding the use of existing logos/icons - we could take inspiration from Edge Canary, Dev, Beta icons, and just use a text badge

I like the badge idea to indicate the different frameworks - especially since Maui / .NET don't have very destinctive icons. We could use color to indicate if it's a "Labs" type or not (like VS Code does with blue vs. green).
The .NET visual style for icons is different than that of Windows (I think Azure or the Business Applicationa, like Power Platform or Dynamics, are more similiar to Windows/Fluent) so that might be another thing to take into account. Feels like we need to create a little framework on how this could work.

I like the badge idea to indicate the different frameworks - especially since Maui / .NET don't have very destinctive icons. We could use color to indicate if it's a "Labs" type or not (like VS Code does with blue vs. green).
The .NET visual style for icons is different than that of Windows (I think Azure or the Business Applicationa, like Power Platform or Dynamics, are more similiar to Windows/Fluent) so that might be another thing to take into account. Feels like we need to create a little framework on how this could work.

Everyone watching this thread could be contributing ideas and suggestions - and those maintaining can run them through the theoretical use cases, and provide feedback on where ideas fall short.

I like the idea of using text (especially for things that don't have their own icons) however, I wonder if it will be hard to distinguish between "WinUI" and "Win32" at small sizes.
Is it worth varying by color for each different platform?
Could then add an adornment for the labs versions of each.

I like the idea of using text (especially for things that don't have their own icons) however, I wonder if it will be hard to distinguish between "WinUI" and "Win32" at small sizes.
Is it worth varying by color for each different platform?
Could then add an adornment for the labs versions of each.

Visual Studio uses different colours for things, but with Windows, everything seems to be blue.  .Net is a shade of purple. But its all very similar.
In what circumstances will the Toolkit for Win32 Icon be used?  Is it for web branding, or does it need to fit into the 32 x 32 icons?
There is also the possibility that the toolkit icon, becomes a badge to other larger icons...

Why not put the badge as a label on the toolbox itself atleast in larger versions, >96px?

Looks like we have an effective resolution of 32x32 for distinction in NuGet icons (within VS at least):

So, if we apply @mdtauk's current labels as a mock, we can see that here:

It does seem like text alone would be pretty small and hard to distinguish (unless enlarged which may take over the design); so I do like the idea of color banding/changes based on technology.
In terms of text labels, if we go with that, I think we could have .NET, UWP, MAUI, and WinAppSDK or WinUI3? @mrlacy, I don't see us having/using a Win32 label, so I don't think we have to worry about overlap there?
If we used Purple for .NET and Blues for UWP/WinUI3 (though we may need another distinguisher), I'm not sure what colors we'd use for MAUI... @brminnick it's usually been tied to the .NET colors, eh?

Perhaps the Icon can be the badge, something like this?

@mdtauk that's an interesting idea. Though that ties into the open question around permissions/associations with the branding of the other projects. And some of those projects may have brand guidelines (like .NET) about compositing their logo to begin with.
Though if we create our own branding for each sub-project, this could be a cool way to do the inverse of compositing I had suggested originally that may be easier to make work or at least highlight the main technology. 🤔

@mdtauk that's an interesting idea. Though that ties into the open question around permissions/associations with the branding of the other projects. And some of those projects may have brand guidelines (like .NET) about compositing their logo to begin with.
Though if we create our own branding for each sub-project, this could be a cool way to do the inverse of compositing I had suggested originally that may be easier to make work or at least highlight the main technology. 🤔

Anything involving a lot of text, will be problematic, such as WinAppSDK - getting that at 32x32 is a tall order

I absolutely love @mdtauk's idea. I think it looks great, and we could go talk to the various teams involved in case we needed special permissions to use their logos (after all all of those projects are themselves from Microsoft anyway). Something like that would help immensely letting the community know those projects are 1st party, as the logo would immediately be recognizable when browsing packages. I think conceptually it also conveys exactly what the Toolkit-s are: extensions for each major project, that are not built-in into the various platforms/SDKs but still develop in collaboration with the various teams and overall by Microsoft in general.

To @michael-hawker 's point: I can imagine there are (strict) guidelines on when to use product icons, in what context or composition. But I guess that those aren't public so someone at Microsoft might be qble to find out :).
For clarification. Where do we expect these icons to show up?

Branding (e.g. docs, repository, slides)
NuGet icon
App icon for the sample gallery apps

I think the app icon could be slightly different than the branding/NuGet icons (like the .xlxs icon is similiar, but different from the Excel app icon) to respect platform app icon conventions.
In NuGet, the UI already provides the title and description - so having tags/labels in the icon there might not be needed?

I don't see us having/using a Win32 label, so I don't think we have to worry about overlap there?

I know this (https://github.com/CommunityToolkit/Microsoft.Toolkit.Win32) hasn't been touched in a while but does a lack of a need to consider it mean it doesn't have a future?

I don't see us having/using a Win32 label, so I don't think we have to worry about overlap there?

I know this (https://github.com/CommunityToolkit/Microsoft.Toolkit.Win32) hasn't been touched in a while but does a lack of a need to consider it mean it doesn't have a future?

It probably gets subsumed into WinAppSDK support right?

I don't see us having/using a Win32 label, so I don't think we have to worry about overlap there?

I know this (https://github.com/CommunityToolkit/Microsoft.Toolkit.Win32) hasn't been touched in a while but does a lack of a need to consider it mean it doesn't have a future?

The Win32 repo is managed by the WinUI team. It has effectively been just waiting for XAML Islands support to come to WinUI 3 to be archived. So, there is no future for it in terms of branding we need to consider for the project moving forward. Consider it part of "Toolkit Legacy".

Based on the ideas @mdtauk showed, I made a quick iteration (this needs work big time.. some of the sizes and colors are off) that shows a concept/composition that might scale:

Color + logo indicate the type of toolkit (MAUI vs. .NET vs. WinUI)
Colored banner to indicate e.g. a Labs or preview version (following the Edge/VS Code / Terminal way of doing that)

Am wondering how this will hold up at the smallest sizes, but I do really like the composition of the toolbox itself

I love these new icons!
Just one quick nit - we can't use the Xamarin logo on the .NET MAUI Community Toolkit because Microsoft is sunsetting the Xamarin brand. (As a former Xamarin employee, it truly does break my heart 😢).
I'm unsure if .NET MAUI has its own official unique branding outside of using the .NET branding. The most common logo I've seen for .NET MAUI is the surfing .NET Bot:

(Kind of unrelated, but also kind of related) I've created an image of the .NET Bot + Toolkit that we use as the logo for our monthly .NET MAUI Community Toolkit standup on the .NET Foundation YouTube Channel, and the team is welcome to leverage it if you'd like!

@niels9001 love that toolbox and how well it plays with the color variations too, and it does scale well.
I find the Labs label doesn't hold up quite as well for the small size though, the logos shrinking is a bit hard to distinguish as well, but the color variation helps to hold up the distinction. Wonder if we could change the ratio/proportion of logo to toolbox size as things got smaller and make the logos larger? I'll ask the WinUI team the next time I connect with them about using their mark like this. I like the notion of just keeping it mono-colored.
@brminnick according to the .NET brand guidelines I think the .NET Bot is supposed to be more of a communications tool only vs. any specific logo, so I don't think we could use the surfing one here for the logo/icon of the toolkit itself. Though it'd probably also not shrink down well.
Is there anyone on the MAUI team we could reach out to in order to find out if they have any branding plans for release to give MAUI a branding like Xamarin had with the "Hex-X"?
@niels9001 thoughts on what the org/base mark would be? Would it just be a gray toolbox? Would we have "Community" or a representation/gathering of people (for community) on it maybe?

@niels9001 love that toolbox and how well it plays with the color variations too, and it does scale well.
I find the Labs label doesn't hold up quite as well for the small size though, the logos shrinking is a bit hard to distinguish as well, but the color variation helps to hold up the distinction. Wonder if we could change the ratio/proportion of logo to toolbox size as things got smaller and make the logos larger? I'll ask the WinUI team the next time I connect with them about using their mark like this. I like the notion of just keeping it mono-colored.

Yeah, for smaller sizes we'd need to create specific assets (increasing the icon or banner on smaller sizes) instead of shrinking the original version like I did.

Is there anyone on the MAUI team we could reach out to in order to find out if they have any branding plans for release to give MAUI a branding like Xamarin had with the "Hex-X"?

The X used was more of a placeholder. I was hoping for a similiar one with a M but couldn't find one. What does the app icon for Maui apps look like?

@niels9001 thoughts on what the org/base mark would be? Would it just be a gray toolbox? Would we have "Community" or a representation/gathering of people (for community) on it maybe?

Oh that's a nice idea👌.
What are the combinations of icons would be required to have?

Base / community
.NET + Labs
MAUI + Labs
WinUI + Labs (would this include both WinAppsSDK and UWP?)

In terms of total assets which we'd need to start with, the list would be around 5 or 7 (depending on UWP/WinUI split/varience):

General / Community (GitHub org, general communications, doc landing page, etc...)
.NET
MAUI
UWP/WinUI (we'd have to figure out how we want to distinguish these I think)
UWP/WinUI + Labs (Labs right now is mostly focused on the Windows side of things, but may later get picked up by our other two main .NET/MAUI projects in the future.)

For reference the UWP/WinUI 3 naming/packaging identity discussion is occurring here.

RE: .NET MAUI Toolkit Icon
I spoke with Beth Massi (Director who basically owns .NET Marketing at MSFT) and here's what she said:

Does .NET MAUI have an official logo?

"No, app models don't have their own logos. The only official logo is the .NET logo"

Can we use the .NET Bot in out Community Toolkit logo?

"No, you need to follow the branding guidelines on logo lockup rules"

Is anything changing the future?

"The UX team is looking at potentially rebranding .NET at some point and we will look at iconography for app models and languages"

"The UX team is looking at potentially rebranding .NET at some point"

Unrelated, but... What 👀

"The UX team is looking at potentially rebranding .NET at some point"

Unrelated, but... What 👀

I would assume this doesn't mean renaming .NET itself, vs. refreshing the branding of .NET itself (i.e. the purple color, the logo, etc...).
@brminnick assuming no timeline was provided for that? In which case we should probably figure out a solution that works for us in the interim and we can always update based on our model in the future.

I would assume this doesn't mean renaming .NET itself, vs. refreshing the branding of .NET itself (i.e. the purple color, the logo, etc...).

This is my assumption as well

assuming no timeline was provided for that? In which case we should probably figure out a solution that works for us in the interim and we can always update based on our model in the future.

Correct, and agreed 💯

@brminnick going off the surfing bot for inspiration, what about a wave 🌊 or surfboard as the icon for the MAUI Community Toolkit? Or maybe poll the MAUI community on Twitter for ideas?

Incase anyone wanted to see the more generic toolbox icon at all the sizes...

In terms of total assets which we'd need to start with, the list would be around 5 or 7 (depending on UWP/WinUI split/varience):

General / Community (GitHub org, general communications, doc landing page, etc...)
.NET
MAUI
UWP/WinUI (we'd have to figure out how we want to distinguish these I think)
UWP/WinUI + Labs (Labs right now is mostly focused on the Windows side of things, but may later get picked up by our other two main .NET/MAUI projects in the future.)

For reference the UWP/WinUI 3 naming/packaging identity discussion is occurring here.

Here's another iteration:

Added a community icon (as suggested by @michael-hawker ). Hard to find a good "neutral" color so grey for now :). I could imagine replacing the "people" icon with e.g. a code icon (to indicate that it's a coding toolkit).
Adopting @mdtauk corner radii, sizes and overall composition which makes it look way better imo.
Added a soft gradient on the icons (similar to the Windows folder icons) and its using the correct shadows and gradient directions used across Fluent icons. Labs is a bit better readable now on the smallest sizes.

That looks pretty nice! 👀
You already mentioned this, but yeah I guess the community icon seems a bit "sad" now, could use some more colors/life 😄

That looks pretty nice! 👀
You already mentioned this, but yeah I guess the community icon seems a bit "sad" now, could use some more colors/life 😄

What if we had a diverse group of people (4) each colored one colored with Red, Green, Blue, and Yellow shirts? 🤔 Subtle hint at our support/connections to Microsoft still preserved?

How about this, colours taken from the Windows 11 Downloads Folder Icon

Has any progress been made on these?

@mdtauk thanks for reaching out! We've been fairly heads-down on some tech work for our Labs project. @niels9001 is actually starting with our team next week! 🙂 So, I'm hoping this is something he can help us pick up again as he onboards to help us drive to final state. 😉

@niels9001 since we've started using the new designs and plan to start using them more in the future, we should make sure the files are in this repo, eh?

Checked in the new assets in #2 so closing this issue. Thanks @niels9001 and everyone for their feedback and suggestions!


Math Magicians: React initial setup

Changes:

React application initial setup
Linters

Hi @Movgto Please fix your linter error 🙏🏼


Identity flow accesses the camera even without permission

Bug Description
Even when the app has no permission to access the camera, the camera is opened and used during the identity flow.
Note that on iPhone, a dlg pops up informing the user and redirecting him to phone settings, if he agrees.
Note also that it works as expected for the address book in Android when adding a receiver.
Steps to Reproduce

Disable camera access permission for the Concordium app.
Initiate the identity flow with Notabene.

Expected Result
A dlg should pop up informing the user that camera access is disabled. If he agrees, he should be redirected to settings to enable the permission.
Actual Result
The camera can be used to take pictures of documents and selfies.
Versions

Concordium wallet 1.0.14
Android 9

It's Chrome not camera permissions that are relevant.


Set Prometheus Resource limits from cluster enable page

What kind of request is this (question/bug/enhancement/feature request):
Enhancement
Steps to reproduce (least amount of steps as possible):
The memory resource limit on the Prometheus instance is low by default. In a cluster with 50 nodes, you need close 1.5GB of Ram on the Prometheus pod to collect cluster metrics. The pod starts running into OOM killed issues very quickly.
The resource limits should be configurable from the page where the user enables monitoring.
Environment information
rancher/rancher:v2.2.0-rc3
Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): RKE Custom
Machine type (cloud/VM/metal) and specifications (CPU/memory): Google Compute Engine n1-standard-1

50 nodes.
k8s-1.13

Also, to reinforce the settings being configurable here, any changes on the deployment are overwritten when make a change at the monitoring enable page. For instance changing the retention period, resets the updated resource limit settings on the container.

SGTM.
Now the resource limit will be reset to 500Mi when we add prometheus.resources.core.limits.memory=2048Mi to catalog app cluster-monitoring.

Version: Master 2.2 (3/8/19) bda75638b43f
Used RKE on EC2, k8s v1.13.4
10 worker nodes, test scaling up (to 45 worker nodes) upon increasing prometheus memory. (Ran into machine limit for ec2)
Confirmed enhancement.
Validate default and custom settings upon form submit:

prometheus.resources.core.limits.cpu: "1111m"
prometheus.resources.core.limits.memory: "499Mi"
prometheus.resources.core.requests.cpu: "222m"
prometheus.resources.core.requests.memory: "150Mi"

Validate settings made it in API.
Validate settings in prometheus-cluster-monitoring Security & Host Config in UI:

(Also check prometheus container)
Validate that when we edit a setting for monitoring config form resends all fields, all values get updated. Ensure http/API/UI look correct.
Increased limits took effect:

Scale up nodes significantly to about 45 (ran into machine limit for ec2). Ensure monitoring is still working as expected (no OOM issues, etc); smoke test monitoring.
I observed memory utilization mainly on prometheus container and prometheus-cluster-monitoring pod to get an idea on memory utilization, etc. I smoke tested and did not observe any issues.


Update X logo to 𝕏 on the website's footer

In the footer, we still have the old bird icon for Twitter. I suggest we update that to 𝕏.

That's correct.  However, if I'm the one to fix it, it's going to wait until I can add the icons for all our social media accounts.

Yes. Probably an update to the Docsy version is required to use the latest fontawesome icons (which would also impact the entire site).
Here's a similar issue, for the kubernetes.io site: https://github.com/kubernetes/website/issues/46405


Training with lazy dataset finishes prematurely after first epoch

Make automatic rewind of the file handle after it is read to the end.

Fixed


API/ENH: allow Period to be a first-class type via a PeriodBlockinternal type

Instead of having a represenation of an array of Period objects (object dtype) in a Series/DataFrame. Allow an internal type of PeriodBlock to represent, similary to DatetimeBlock.
Here is a usecase. The following would be very simple if to_period(...) returned a PeriodIndex
In [59]: df = DataFrame({'date' : pd.date_range('20130101 00:01:00',periods=5,freq='61s')})

In [60]: df
Out[60]:
                 date
0 2013-01-01 00:01:00
1 2013-01-01 00:02:01
2 2013-01-01 00:03:02
3 2013-01-01 00:04:03
4 2013-01-01 00:05:04

In [61]: df.date.dt.to_period('T')
Out[61]:
0    2013-01-01 00:01
1    2013-01-01 00:02
2    2013-01-01 00:03
3    2013-01-01 00:04
4    2013-01-01 00:05
dtype: object

In [62]: pd.Series(pd.PeriodIndex(df.date.dt.to_period('T')+1).to_timestamp())
Out[62]:
0   2013-01-01 00:02:00
1   2013-01-01 00:03:00
2   2013-01-01 00:04:00
3   2013-01-01 00:05:00
4   2013-01-01 00:06:00
dtype: datetime64[ns]

xref: #10718. We can fix PeriodIndex.dtype_str when we have period dtype.

I'm working on this recently, and found we should to fix some dtype issues first (#12619 and #12758).

https://github.com/pydata/pandas/compare/master...sinhrks:periodblock2

you might be better off sub-classing the Block from DatetimelikeBlcok no?

Going to make it a PeriodArray extension array


Getting TypeError when using the code with

This is running under Safari :
[Error] TypeError: null is not an object (evaluating 'container.querySelector')

createSvg (chartist.js, line 188)
createChart (chartist.js, line 1905)
initialize (chartist.js, line 1145)
initialize ([native code], line 0)

var draw = function (name) {
    // clean everything from parent tag
    $("#graph").empty();

    new Chartist.Line('#chart', {
        labels: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri'],
        series: [
            [2, 3, 2, 4, 5],
            [0, 2.5, 3, 2, 3],
            [1, 2, 2.5, 3.5, 4]
        ]
    }, {
        width: 320,
        height: 240
    });
};

var setEvents = function () {
    $("#controls").find("button").click(function() {
        var name = $(this).html().toLowerCase();

        console.log(name + " button clicked");
        draw(name);
    })
};

window.onload = setEvents();

The code is the simple example I found on the smashing magazine site. It just seemingly doesn't work along bootstrap.
The HTML code is also very simple. Take a look here
The error seems to be internal to the library. It requires a lot of tracing calls. It'd be simpler if I get some help here.

Hey there. The problem is that charist cant find any element matching #chart. After the call $("#graph").empty(); the containing div is removed from the DOM.

 -_-
Seriosuly, thanks for making me feel like one.


Can't load coco checkpoint

I followed all the steps in downloading the .tar file and then using the convert_weight.py to get the demo checkpoint. However when I execute train.py it cannot find the coco demo checkpoint. So, it trains from the beginning...

I have met the same problem,have u already solven it?

I have met the same problem,have u already solven it?

I followed all the steps in downloading the .tar file and then using the convert_weight.py to get the demo checkpoint. However when I execute train.py it cannot find the coco demo checkpoint. So, it trains from the beginning...

hi,I come throught the same problem,have you sovled this problem??


Page jump on reload with hash: true

I am upgrading from 1.2.8 to 1.4.0 and noticed something new: using hash: true, on page reload of example.com/#my-hash (i.e. #my-hash is somewhere in the page), there is now a jump from top of the page to the position of #my-hash.
Previously, the smooth scroll would happen on click but not on reload.
This is due to this block, which assumes that if hash: true is set, not only the hash of the selected link, will appear on the address bar (per L47) but also that I want to animate scroll on page load.
Is there a way to disable the second part of that statement? If not, would you be open to adding a new setting (load: true/false?) that would enable/disable this block?

Hi @astorije I think the current behavior is what the large majority expects. The plugin has existed for many years and this is the first time this comes up. I think we can leave the issue as closed and if many users complain we can revisit this.
I don't think it's worth adding another option just for this because, I think, you can get the expected behavior by passing an onBefore() callback to the plugin and changing the duration based on whether it's this first jump or not (setting it to 0 on page load ofc).
What do you think?

Hi @astorije I think the current behavior is what the large majority expects. The plugin has existed for many years and this is the first time this comes up.

I know this is anecdotic, but I've been using this plugin for years (thanks a lot for your great work, btw ❤) but always in outdated versions. The "new" (as in, new a couple years ago lol) feels much sloppier than the previous one, which is why I directly noticed it.
Of course, by sloppy I don't mean your work being sloppy, but the end result once put on a very basic website since refreshing the page will incur a flickering/jumping.
It seems to me that the alternative (i.e. v1.2.8 behavior) feels more natural than the current behavior. You are mentioning that the large majority would expect current behavior but I could have sworn the other way around. Am I missing some context? (Sorry if I appear sarcastic or anything, I'm really trying to understand and avoid making assumptions for others)

you can get the expected behavior by passing an onBefore() callback to the plugin and changing the duration based on whether it's this first jump or not (setting it to 0 on page load ofc).

So if I understand correctly, you are suggesting the following:
$(...).localScroll({
  duration: "slow",
  hash: true,
  onBefore: function() { /* If first jump AND the URL ends with `#something`, set `duration` to 0 */ }
});

I get the intent, but there is a lot of room for errors and edge cases, IMO.
Right now, I went for a safer but much hackier solution of commenting out the initial block and this works fine. I would however much prefer not hacking my own fork/local copy and contribute to make this project better, however :)
Hence my suggestion for an option, if simply going back to the previous behavior is not something you'd consider. I think I see how the current behavior would be useful in a slideshow/app type of thing, but not so much in a regular document-based website (not trying to shameless plug but this is what I'm talking about).
If you're still not in favor of making this possible then feel free to close this issue, but otherwise I'm happy to discuss and help with this :)

I understand your point perfectly, indeed the behavior became unavoidable on the newer version. Let's wait to see if it's something that is widely problematic.
Thanks for reporting!

(May I ask what minifier you use to build your .min.js?)

I use Dean Edwards's Packer, with Shrink Variables on  but Base62 Encode off. The header part I do manually.

Thanks!
Just FYI, I have noticed a slightly better minification by using https://javascript-minifier.com/ or https://jscompress.com/ (they both produce the same output, probably the same engine?) going from 1326 chars to 1215 chars (9.2%). Not worth changing it at all cost, but I figured I should share.
Also, I didn't test that minified version 😅


Java Indexer: print stack trace signature generation failed [phab:D937]

Created by schroederc at 2016-06-17 18:50:53:
Most TODO nodes are a result of failing to generate a signature.  This
logs useful information to debug the failures.

shahms commented inline (context lost during migration) at 2016-06-20 18:04:23:
The rest look fine, but is there really no better way to dump a stack trace than this?
logger.exception() or something?

schroederc wrote at 2016-07-11 16:11:05:
Use logger

schroederc commented inline (context lost during migration) at 2016-07-11 16:12:20:
It's not much "better", but...

shahms accepted this revision at 2016-07-11 16:17:01

schroederc closed via commit 835879a9e319d62f3cfbc569d324e12cb3952df0 at 2016-07-11 16:17:36


Update log4j_checker_beta.sh

missing

this patch is the wrong way to go. # is not missing. instead, the script functions need to be defined before they're used.

Fixed in https://github.com/rubo77/log4j_checker_beta/commit/0f5a3df2b583dde82fa1e69d49511c79aa8ac834#diff-16c18e323971e496f558700372d7e8d1f113510b0759fccae18fd09567df6f0d


Wrap NFT request

Native NFT chainid (Andromeda 1088, Stardust 588, Ethereum 1, Rinkeby 4):588
Native NFT contract address:0x6babD8ABFB079039bf53A032CBe5EFEc63b692E6
Deployed wrap NFT contract address: 0xc286a3177a2aa16f3061c742cf230c6f361484b9
Transaction hash of the contract deployment:10.11

Already added


docs(Theme): update Theme docs with new guidance/usage

partially closes #11293
Updates the /code page for Themes with new usage/guidance clarity based on some support work we've done

I've totally overhauled this one with a bunch of theme related changes. Please re-review and let me know what you think.

@tw15egan No! Good distinction. In this case it means that instead of having @carbon/themes installed and doing:
@use '@carbon/themes/scss/theme';

You can instead access this stuff from @carbon/react
@use '@carbon/react/scss/theme';

This is limited to just the styles as well. If someone's wanting to get the exports for usage  in javascript, they'll need to install the @carbon/themes package.
I'll update this verbiage to say "you likely don't need to install the themes package" instead of "there's no reason to install the themes package"


Adding AddRole method so that this bug can be fixed: #3568

This is a pretty serious bug and limits what we can achieve with production grade deployments on Azure: https://github.com/hashicorp/terraform/issues/3568
As a first step to fix this bug, I propose that we add an "AddRole" method to azure-sdk-for-go for the virtualmachine client. This is a missing API now. Azure already has a REST API for this: https://msdn.microsoft.com/en-us/library/azure/jj157186.aspx
However, azure-sdk-for-go does not have a corresponding method that calls this REST API. Hence, we cannot add a new VM to an existing deployment or cloud service today.
Please accept this straightforward change. It is just the addition of a base method that is missing. Once accepted and merged, I plan to use it from terraform and fix the issue. Thanks again!
I have tested this method thoroughly.

Hi @kbxkb, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Koushik Biswas). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

Hi guys,
The Travis CI build is failing due to an unrelated error... "The command "go get -u github.com/golang/lint/golint" failed and exited with 1 during ." Any idea how can I kick off the build again? Thanks!

LGTM


EOS-26647 : Multipart object replication

Problem Statement

Updated the complete multipart upload class to get the request state
Created a new class of multipart object replicator to add functionality of get range read and multipart PUT.
Implemented the multipart transfer test and added a new config file
Added few future references
Signed-off-by: Priyanka Salunke<EMAIL_ADDRESS>
Design

For Bug, Describe the fix here.
For Feature, Post the link for design

Coding
Checklist for Author

[ ] Coding conventions are followed and code is consistent

Testing
Checklist for Author

[ ] Unit and System Tests are added
[ ] Test Cases cover Happy Path, Non-Happy Path and Scalability
[ ] Testing was performed with RPM

Impact Analysis
Checklist for Author/Reviewer/GateKeeper

[ ] Interface change (if any) are documented
[ ] Side effects on other features (deployment/upgrade)
[ ] Dependencies on other component(s)

Review Checklist
Checklist for Author

[ ] JIRA number/GitHub Issue added to PR
[ ] PR is self reviewed
[ ] Jira and state/status is updated and JIRA is updated with PR link
[ ] Check if the description is clear and explained

Documentation
Checklist for Author

[ ] Changes done to WIKI / Confluence page / Quick Start Guide

Jenkins build is passed - http://eos-jenkins.colo.seagate.com/job/Multisite/job/Run-Tests/20/

I was going to merge this but github won't let me because it is marked as draft. Please remove draft status if you want me to merge this.

@johnbent I have removed the PR from draft. Please merge it.


Show "downloading binary..." message when using elan filetype detection

At the moment, if you open up a Lean file in a project with a version of Lean that elan hasn't downloaded yet, this will break the filetype detection. You can work around it by waiting for a bit and then doing :edit, but it would be best for the plugin to handle this itself.

I have no direct opinion on elan but yeah sounds good, we can address on that future PR.


Add method to list all supported countries

We are using holidays in Home Assistant to allow the users to get information about workdays. We maintain a copy of the supported countries to have configuration validation. With the proposed addition (list_supported_countries()) it would be possible to get the supported countries from the module itself. This would help us to avoid issue like  https://github.com/home-assistant/home-assistant/issues/28977.
$ python3
Python 3.7.5 (default, Oct 17 2019, 12:16:48)
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import holidays
>>> holidays.list_supported_countries()
['AR', 'AT', 'AU', 'AW', 'Argentina', 'Aruba', 'Australia', 'Austria', 'BE', 'BG', 'BR', 'BY', 'Belarus', 'Belgium', 'Brazil', 'Bulgaria', 'CA', 'CH', 'CO', 'CZ', 'Canada', 'Colombia', 'Croatia', 'Czech', 'Czechia', 'DE', 'DK', 'Denmark', 'ECB', 'EE', 'ES', 'England', 'Estonia', 'EuropeanCentralBank', 'FI', 'FRA', 'Finland', 'France', 'GB', 'Germany', 'HK', 'HND', 'HR', 'HU', 'HolidayBase', 'Honduras', 'HongKong', 'Hungary', 'IE', 'IND', 'IS', 'IT', 'Iceland', 'India', 'Ireland', 'IsleOfMan', 'Italy', 'JP', 'Japan', 'KE', 'Kenya', 'LT', 'LU', 'Lithuania', 'Luxembourg', 'MX', 'Mexico', 'NL', 'NO', 'NZ', 'Netherlands', 'NewZealand', 'NorthernIreland', 'Norway', 'PE', 'PL', 'PT', 'PTE', 'Peru', 'Poland', 'Polish', 'Portugal', 'PortugalExt', 'RU', 'Russia', 'SE', 'SI', 'SK', 'Scotland', 'Slovak', 'Slovakia', 'Slovenia', 'SouthAfrica', 'Spain', 'Sweden', 'Switzerland', 'TAR', 'UA', 'UK', 'US', 'Ukraine', 'UnitedKingdom', 'UnitedStates', 'Wales', 'ZA']

Pull Request Test Coverage Report for Build 627

3 of 4 (75.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 99.985%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

holidays.py
3
4
75.0%

Totals

Change from base Build 584:
-0.01%

Covered Lines:
54200

Relevant Lines:
54208

💛  - Coveralls

Pull Request Test Coverage Report for Build 627

3 of 4 (75.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 99.985%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

holidays.py
3
4
75.0%

Totals

Change from base Build 584:
-0.01%

Covered Lines:
60975

Relevant Lines:
60984

💛  - Coveralls

Hi,
thank you for your work!
To accept this update, you should:

target beta branch
nice to have: keep test coverage at 100%
Would you please check and let me know?

Thank you very much, cheers
dr-p

Thank you very much!
Cheers
dr-p


Latest two versions of Safari should be fully supported in legacy plugin

Describe the bug
I noticed the legacy plugin uses this Browserslist query: last 2 versions and not dead, > 0.3%, Firefox ESR
Unfortunately, because of how Browserslist works, this only includes some of the last 2 major versions of Safari, since last 2 versions only includes the last 2 minor versions, and > 0.3% excludes some minor versions due to low usage.
I suggest using last 2 major versions and not dead, > 0.3%, Firefox ESR instead. This could potentially expand supported browser usage by 2.7% in the US. If you'd like I can send a PR.
Reproduction
https://browsersl.ist/#q=last+2+versions+and+not+dead%2C+>+0.3%25%2C+Firefox+ESR
Steps to reproduce

Run Browserslist query
Note that Safari versions >= 15 and < 16.5 are missing

Suggested labels

bug
plugin: legacy

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Please don't make this change.
It is incorrect.
Safari majors are just marketing versions.
Safari minors contain web engine features and have multiple releases a year, just like Chrome major versions.

It is incorrect.

No, I've proven statistically that Safari majors are more similar to majors in other browsers: https://github.com/orgs/browserslist/discussions/781#discussioncomment-6516951

Safari majors are just marketing versions.

All browser versions are marketing versions!

Safari minors contain web engine features and have multiple releases a year, just like Chrome major versions.

This only helps for comparing updates at a basic level, but isn't practical in this case. If this argument were valid, fixing it wouldn't increase the market share of supported Safari versions!

If the intention is to cover a percentage of users you should change the browserslist query to a >n% query.
These are two different kinds of queries and both have a specific purpose.
Changing it to an >n% query is a valid request.
But please don't change it to major safari as a flawed proxy for a wider user base.

No, I've proven statistically that Safari majors are more similar to majors in other browsers: https://github.com/orgs/browserslist/discussions/781#discussioncomment-6516951

With all due respect, this is untrue.
These is from an actual WebKit engineer working at Apple : https://github.com/web-platform-dx/feature-set/issues/173#issuecomment-1555386336

This discussion is already continuing elsewhere in https://github.com/web-platform-dx/feature-set/issues/264 and https://github.com/facebook/docusaurus/issues/9173. I'll skip copying replies to here for now to reduce notifications, until a maintainer or other contributor wants to reply.

The last 2 versions part is to give less used browsers a fair chance to increase their usage (https://github.com/browserslist/browserslist#:~:text=If you want,setting with caution). Given that the Safari minor releases are shiped at similar intervals as Chrome, I think the last 2 versions is fine.

This could potentially expand supported browser usage

This is not relevant as the intent of the last 2 versions part isn't to expand the supported browser usage. Moreover, last 2 versions and not dead, > 0.3%, Firefox ESR includes more lower Safari version (14.1, iOS 12.2, ...) than the second-to-last major version (15.0), so the second-to-last major version will be supported indirectly.
Also this is just a default and users can expand the range if they want to.

Closing as I think the current default is fine.


Cannot login with (admin) user

Hi, after I have set up the system and after I have created the admin user, I cannot login with the newly created account. I enter correct username and password, and submit, but nothing happens.
I am using Saltcorn 0.8.2 Docker. I have tested with both Firefox and Chrome. Some of the errors I found using dev tools:

Multiple JS resources are not loaded: scripts might be missing
text/javascript type when they are loaded (in index.html)

The resource from
“http://<IP_ADDRESS>:3000/static_assets/5c5d9ce98466257e/saltcorn.js” was
blocked due to MIME type (“text/html”) mismatch
(X-Content-Type-Options: nosniff).
The resource from
“http://<IP_ADDRESS>:3000/static_assets/5c5d9ce98466257e/jquery-3.6.0.min.js”
was blocked due to MIME type (“text/html”) mismatch
(X-Content-Type-Options: nosniff).
The resource from
“http://<IP_ADDRESS>:3000/static_assets/5c5d9ce98466257e/saltcorn-common.js”
was blocked due to MIME type (“text/html”) mismatch
(X-Content-Type-Options: nosniff).

Resource favicon.ico is missing. Although not an error per se, fixing this would make it easier to find SaltCorn for tens of open tabs.

A warning of cookie “connect.sid” does not have a proper “SameSite”
attribute value. Soon, cookies without the “SameSite” attribute or
with an invalid value will be treated as “Lax”. This means that the
cookie will no longer be sent in third-party contexts. If your
application depends on this cookie being available in such contexts,
please add the “SameSite=None“ attribute to it. To know more about the
“SameSite“ attribute, read
https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Did you set the session secret environment variable SALTCORN_SESSION_SECRET ?


make everything better

fix build warnings
remove packages files on build
remove documentation files on build
only build for .net 6

yea looks good methinks


cannot run example

Hi,
I'm trying to run your example, but seeing
[/root/.cache/huggingface/modules/transformers_modules/lightonai/RITA_s/rita_modeling_ad8dfe2e2240d5a6abcfa9ea52f3868a35f07f4670c887c31d420f6bba0fdc5f_3db732a66a256d53b183fe3a079bbfbf2db700c63f7789178c37924666055f28.py](https://localhost:8080/#) in <module>()
     18 from transformers.utils import logging
     19
---> 20 from .rita_configuration import RITAConfig
     21 import torch.nn.functional as F
     22 logger = logging.get_logger(__name__)

ModuleNotFoundError: No module named 'transformers_modules.lightonai.RITA_s.rita_configuration'

Hrm, I cannot reproduce this issue
Here's a colab running the example:
https://colab.research.google.com/drive/16GO9fhJwCjcrFBL3MrGHsa9fyBAgth2n?usp=sharing
Maybe try upgrading transformers and clearing the cache?


Ignore SBOM URLs for other images

Ref: EC-930

Updated commit message to reference the new issue IDs.


--config failing

Command
svg-sprite --config config.json *.svg

config.json
{
    "mode": {
        "symbol": true
    }
}

stderr
/usr/local/lib/node_modules/svg-sprite/bin/svg-sprite.js:231
		if ((render in this) && !argv[arg]
		               ^

TypeError: Cannot use 'in' operator to search for 'css' in undefined
    at /usr/local/lib/node_modules/svg-sprite/bin/svg-sprite.js:231:18
    at Array.forEach (native)
    at Object.<anonymous> (/usr/local/lib/node_modules/svg-sprite/bin/svg-sprite.js:229:34)
    at Array.forEach (native)
    at Object.<anonymous> (/usr/local/lib/node_modules/svg-sprite/bin/svg-sprite.js:222:44)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)

Working commands
svg-sprite *.svg
svg-sprite --symbol *.svg

Please also provide the contents of your config.json. Thanks.

It's there

Sorry, must have overseen it (only on my mobile phone atm)

No worries :)

The problem was the shorthand definition of the symbol mode (by simply setting it to true). This needed to be expanded by the CLI script ... Thanks for reporting! :)

Makes sense! Thanks


docs: Simplify and update README, CONTRIBUTING and others

Description

Replaced mentions of "Superface SDK" with "OneSDK" or "Superface OneSDK"
Simplified README, removed most of the SDK-specific docs in favor of linking to documentation

Some specific explanations, like working with results object and environment variables are missing now; I will move them to docs.

Renamed CONTRIBUTION_GUIDE to CONTRIBUTING since that's file recognized by GitHub
Updated CONTRIBUTING guide
Removed ToC since the whole README is short enough; also, broke away from Standard Readme, I don't think it's suitable for projects.
Added direct links to SF website, docs, Discord, and repeated them a lot in the README just in case someone missed it.

For reference, I was inspired by recommendations and featured projects in this article.

Full README preview
Motivation and Context
The README was pretty outdated.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have updated the documentation accordingly. If you are changing code related to user secrets you need to really make sure that security documentation is correct.
[x] I have read the CONTRIBUTION_GUIDE document.
[x] I haven't repeated the code. (DRY)
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@zdne Thanks for the feedback! I have added your suggestions beside the SECURITY which I'd like to tackle separately.
I'd like to hear from SDK authors, especially @lukas-valenta, @Jakub-Vacek, and @TheEdward162. Any ideas / suggestions?

I love it! Much much better. I'd still add one or two lines on "benefits" why you want to use it instead of anything else...

@zdne I thought about adding a "Features" section with the list of benefits we shared in early access email:

One simple to use Node.js SDK for all the APIs you want to use
No need to read API docs
Immunity to API changes
Integration monitoring and testing
Clean, hexagonal architecture for your integrations
Platform-less integration, harmonization and aggregation without a middleman
Reduction of your application's code base
The super power for your app to self-integrate
Automatic fail-overs*
No vendor locks*

However, most of these apply to Superface as a whole and I feel it's kinda misleading to attribute these features to OneSDK. For example, "no need to read API docs" and "immunity to API changes" applies only if you are not building the use-cases yourself, but on the other hand this is one of the benefits of OneSDK.
But if you'd like to emphasise these features, maybe we could add this:

Features

One Node.js SDK for all the APIs you want to use
Automatic fail-overs
Built-in support for integration monitoring
Clean, hexagonal architecture for integrations
Platform-less integration, harmonization, and aggregation without a middleman
Reduction of your application's code base

Maybe also add something like "full control over integrations' code" or somehow underline the customizability of integrations.


gitlab-glab: bump to 1.12.1

Existing package

[X] I am the maintainer of this package.

Thanks! We are waiting for this update

Thanks! We are waiting for this update

Thanks! We are waiting for this update

Will be updated day after tomorrow, I've been away for a while.

Thanks! We are waiting for this update

Will be updated day after tomorrow, I've been away for a while.


ISPN-6113 Make Consistent Hashes persistable to the global state

https://issues.jboss.org/browse/ISPN-6113

@danberindei I've moved the constants.

Are there any integration tests for this? The tests added are all unit tests which run without a Cache/CacheManager

No integration tests yet, in the way you intend them, since that will happen once I send the PR that actually performs the graceful start and will restore the CH into a cache.

Fixed the interface.

Integrated, thanks Tristan!


Chores: Twitter URL, Discord invite URL, robots.txt file

Description

Updates Discord invite link to https://discord.com/invite/celo
Updates Twitter link to https://twitter.com/Celo
Adds a robots.txt file in /public folder

References
What are robots.txt files good for? https://developers.google.com/search/docs/crawling-indexing/robots/intro
Where should robots.txt files live in Next.js projects? https://nextjs.org/learn-pages-router/seo/crawling-and-indexing/robots-txt
Tested
Using the Vercel preview:

manually clicked the Twitter and Discord icons

manually checked https://staked-celo-web-app-git-arthurgousset-chores-c-labs.vercel.app/robots.txt

Related issues
N/A
Backwards compatibility
Yes, no change to feature set.
Documentation
N/A

Considering adding this too:

https://github.com/celo-org/staked-celo-web-app/issues/219


chore: Make traces use same context

copilot:all

Current dependencies on/for this PR:

main

PR #2934   👈

This comment was auto-generated by Graphite.


feat: Add a mid point for linear elements

⚠ This feature is in progress ⚠

🔥 🔥 🔥 looking forward for this one !

🔥 🔥 🔥 looking forward for this one !

On the way 😉

The goal is for the mid-point to be "phantom" until you click/drag on it. This way there's no actual point, unlike in current version where the point is always there, making the arrow 3-point from the start.
And in the future we may also allow adding more midpoints "forever" (until a given threshold).
Figma:

We should also decide whether double-clicking on a point outside the editor should remove it.

Behavior is different if I drag the arrow (the mid point is added) and if I click, move the pointer and double click (the mid point is not added).
I agree with @dwelle that the mid-point should be invisible until used. If line sloppiness is cartoonist the mid-point breaks the continuity of the line which stylistically does not look very nice.
I also agree that this would make sense if mid-points would continue to sub sections of the line. In its current form I don't yet see the value add of this feature, rather the contrary, because of the line break effect as shown on the video. If you want a multi-point line you can click-move-click-move-doubleclick.
https://user-images.githubusercontent.com/14358394/182838021-ae1d3b20-9f62-4f86-b207-98647fdf80f2.mp4
.

@zsviczian yes the point will be a phantom point. As for the initial release it will be just on mid of linear elements.
I am not sure if we should allow deleting via double click outside editor once added, I am thinking we can leave it for the line editor for deleting the points but its still open for discussion.
As per mid points between segments, we will be discussing that post the initial release.


Support for elasticsearch 6.2 by monogo-connector

Is elasticsearch version 6.2.4 supported?

@anand4321 @CadsoftBrianW @lbolla @redox @HonzaKral

see #796


Revive protoc plugin mode as protoc-gen-prost

This revives PR #313. With the advent of v1.0 of buf.build, the ecosystem for generating polyglot code from protobuf heavily favors the plugin model. It very easily slots into the buf generate model. This revival creates a distinct protoc-gen-prost crate to host the binary, rather than the prior method of putting the binary in the prost-build crate. This makes installation using cargo install protoc-gen-prost more convenient.
In my opinion, Prost would benefit from integrating into this model, so I wanted to revive the old protoc plugin. Even with this very basic PR (which doesn't handle options), I have confirmed that puting the binary onto the PATH and running buf generate results in precisely the Rust code I would expect over a somewhat complicated hierarchy of protobuf files.

This has now been updated to an even smaller, minimum viable set of changes to support an external plugin executable. I've create that executable now at https://github.com/neoeinstein/protoc-gen-prost. Presuming this looks good, I'll be in a position to push up a protoc plugin crate binary.

I believe that this is ready for a new review.


build: update packages in api directory to the latest

this commit update the packages in API directory and also update the mention of go version in the same. The go version 1.16 and 1.17 have already hit EOL.
Signed-off-by: Humble Chirammal<EMAIL_ADDRESS>

@Mergifyio rebase

@humblec why was the ok-to-test label removed and re-added? This caused double the CI jobs, which will now cause additional timeouts and requires more retries later :sob:

@humblec why was the ok-to-test label removed and re-added? This caused double the CI jobs, which will now cause additional timeouts and requires more retries later sob

noticed 6 jobs atleast stuck.. so removed the ok-to-test , may be I would have manually retriggered it.

@nixpanic noticed 6 jobs atleast stuck.. so removed the ok-to-test , may be I would have manually retriggered it. :(

Please define stuck.
Depending on the way it is "stuck" a manual abort in Jenkins can free-up a worker node, or prevent one from being allocated for a test where the results already have been cancelled.


Error with multiple classes in datepicker

I have this code
http://plnkr.co/edit/oyzleZeoWfdGLeIzLepq?p=preview
and I want to show the actual week and the week of the selected day, the console log return correct data about the selected week, but the calendar don't change the classes of these days.

is related with #4227 but still without a great solution

Closing as a duplicate issue


Failed to load the Power BI Desk top or performance analyzer(.json) file

Describe the bug
Followed the instructions in https://github.com/m-kovalsky/ReportAnalyzer, I downloaded and installed Report Analyzer, but in Step 5, I selected the folder which contains both Power BI desktop and Performance Analyzer file, it pop out a window says :"Must select a folder with a Power BI Desktop or Power BI Template file."
To Reproduce
Steps to reproduce the behavior:

Go to 'https://github.com/m-kovalsky/ReportAnalyzer'
Follow the instructions, download and install Report Analyzer
3.Open Report Analyzer, select the folder which contains both Power BI desktop and Performance Analyzer file
See error 'Must select a folder with a Power BI Desktop or Power BI Template file.'

Expected behavior
Could use Report Analyzer normally.
Screenshots
If applicable, add screenshots to help explain your problem.

Version Number (please complete the following information):

Version [Report Analyzer 1.6.0]
Version [Power BI 2.107.841.0 64-bit (July 2022)]

Additional context
Add any other context about the problem here.

Would you share a screenshot of the folder you are attempting to select?

Please see attachment file. Thanks.
At 2022-08-05 17:49:24, "m-kovalsky" @.***> wrote:
Would you share a screenshot of the folder you are attempting to select?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Would you share a screenshot of the folder you are attempting to select?

Is this still a problem in v1.6.3?


[rv_plic] D2(S) Signoff

Description
Ensure D2(S) signoff criteria are still maintained (this is not a focus area block).

Commits since Earlgrey-ES tapeout
$ git rev-parse --short HEAD

c5faa9b8b3
$ git log Earlgrey-M2.5.2-RC0..HEAD --oneline hw

4a9a881d44 [topgen] Pass topname key/value pair to ipgen
de31bdf1c2 [reggen] Remove the devmode input
620bd3401f [rv_plic,sival] List rv_plic features in its hjson file
eee74c3d2e [ip_templates,hjson] Remove clutter
7688e714e8 [reggen] Add initial support for version and cip_id hjson fields
fbd888eea8 Revert "[reggen] Add CIP_IDs and bump all major versions"
0ba10b3cd3 [reggen] Add CIP_IDs and bump all major versions
Issues closed since the Earlgrey-ES tapeout
None
Currently open issues

#21414
#21034
#21001
#17412
#17307
#15584
#14839
#12848
#8440
#3421
#270

Summary

@GregAC @msfschaffner @andreaskurth PTAL


Release-0.6.1

@JuliaRegistrator register

Comments on pull requests will not trigger Registrator, as it is disabled. Please try commenting on a commit or issue.


"app:checkDebugDuplicateClasses" error for Android.

What were you trying to do?
Hey
I am also trying to use a vision-camera-code-scanner. The app works fine for iOS, but I get the "app:checkDebugDuplicateClasses" error for Android.
Here are my versions:
"react-native": "0.68.1",
"react-native-reanimated": "^2.8.0",
"react-native-vision-camera": "^2.14.1",
"vision-camera-code-scanner": "^0.2.0"
Reproduceable Code
No response
What happened instead?

Relevant log output
It is working fine for iOS. This issue comes only for android devices

Device
Android devices
VisionCamera Version
0.68.1
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

Same happening for me after upgrading jdk to 17 and gradle to 7.6


build: new system to build dependencies locally if needed

High level TLDR:

If checked_find_package doesn't find a dependency (or it is not an
acceptable version), it looks for src/cmake/build_<pkg>.cmake and
if that exists, includes it. It can do anything, but is expected to
somehow provide the dependency so that a second find_package will
find it and then proceed as if it were a system install.

I've implemented these scripts so far for Imath, OpenEXR,
OpenColorIO, fmt, and robin-map, that download, build, install the
package in OIIO's build area. More to come later?

This is really simple with a new build_dependency_with_cmake macro,
much simpler than ExternalProject_Add, as I've seen it used
elsewhere.

Just look at any of the new build_blah.cmake files to see how simple
it is for each new dependency we set up this way.

By default, pre-installed packages it can find always take precedent
over building locally. So if you have all the dependencies already
installed, none of this should behave any differntly than before.
But there are variables that let you override on a package by package
basis, giving the option of never building locally, building locally
if the package is missing, or forcing a local build to always happen.

Various details:
A bunch of cmake things (including checked_find_package) have been
moved into a new file, dependency_utils.cmake.
build_Imath.cmake, build_OpenColorIO.cmake, build_OpenEXR.cmake,
build_Robinmap.cmake, and build_fmt.cmake implement local builds of
those packages. They're very simple, and lean heavily on common
infrastructure of build_dependency_with_cmake, which also can be found
in dependency_utils.cmake.
Robinmap and fmt are extra simple because we use them as header-only
libraries.
For Imath and OpenEXR, I build them as static libraries, so they will
be incorporated into libOpenImageIO (and/or _Util) libraries to be
totally internal to them, there should be no symbols exposed outside
our libraries. This should mean that the resulting libOpenImageIO
should be perfectly safe to link in an application that also links
against OpenEXR, Imath, or OpenColorIO, even different versions
thereof, without any interference. Note that none of those packages
are used in our public APIs, only internally.
OpenColorIO was a little trickier. It builds its own dependencies as
static libraries that are internalized, but OCIO itself is a dynamic
library. So we end up having to make it part of our install, but I use
OCIO's build system to make a custom symbol namespace and a custom
library name, so it still should not interfere with any other OCIO
linked into the application.
We'll see how it goes for furture dependencies we want to add.  The
header only, static libraries incorporated and hidden, and dynamic
library but renamed and with custom namespace, are all techniques that
work well. I'm not sure I'd advocate doing local builds of any
dependency that we can't incorporate in one of these ways, but I guess
we'll cross that bridge when we get to it.
New option_utils.cmake has two handy new utilities: set_cache() is
much like the built-in set() when making a cache variable, and
set_option() is much like build-in option(). The biggest difference is
that both allow an environment variable of the same name, if it
exists, to supply the default value. This is something that cmake does
with many of its own controls, like CMAKE_BUILD_TYPE, but does not
make any provision for built-in set() or option() let users do it.
checked_find_package() has moved to dependency_utils.cmake, and has
been enhanced to take several new options, and also so that if the
enclosed find_package() fails and there is a
src/cmake/build_PKG.cmake, it will run it to build the dependency
itself in the build area. If that build_PKG sets a variable called
PKG_REFIND, it will try find_package again to find the one just built.
build_dependency_with_cmake() is given a git repo and tag, and
basically clones the repo, checks out the tag, configures, builds, and
installs it (all in our own build area).

I've marked this as a draft because I noticed that I'm having trouble building opencolorio in this manner on Windows. Needs some minor fixes, but then I'll remove draft status. But I'm confident this is 95% in final form, so by all means start taking a look if you're curious about the approach I'm trying.

Is it mandatory from now on to build everything as static libs, or OIIO, and required libs as before can be built as dynamic libs?

I like the idea of making the build easier -- at the same time, it feels to me like this is kind of reinventing the wheel. I worry that this setup will be brittle and need constant tweaking (though maybe that is par the course no matter what we do).
For someone new to the project, I think it would be nicer to see calls to the ordinary cmake find_package than discover we've rolled our own flavor that they need to study. This would likely be easier for package maintainers as well.
As an alternative -- would it be worth seeing how many custom "find*.cmake" we can actually remove if we rely on new enough versions of the target libraries (and cmake itself)? How close to a fully "modern cmake" setup could we get?

I've only tested on linux so far, but it works like a dream. I can't tell you how much easier this makes things for us...!

I did a bit of reading and some people suggest using the FetchContent family of functions in cmake.
Did you investigate those? Is there a reason why you rolled version?
I'm curious what the pros and cons are. From a cursory glance, it seems to be designed for this exact problem.

Another cmake feature that came up when reading up a bit on this was ExternalProject. I'm not sure I fully grok the differences between that and FetchContent but it seems like another option that might be relevant here.
Likewise there is also ExternalData which could be handy to use for some of the testsuite data (which is a bit clunky to download and setup manually).

@ssh4net:

Is it mandatory from now on to build everything as static libs, or OIIO, and required libs as before can be built as dynamic libs?

None of this is mandatory. It only kicks in if important dependencies are not found, or are not adequate versions. I prefer static libs for this particular use because I don't want OIIO to need to also install dynamic libs of the dependencies, which might interfere with system libraries.
@zachlewis:

I've only tested on linux so far, but it works like a dream. I can't tell you how much easier this makes things for us...!

Thanks! I'm still working out some issues for the Windows CI, but that's less that it's difficult and more than I haven't had the time to chase it down in the last several days.
@fpsunflower:
This is my 4th or 5th rewrite of this, including doing full implementations of both the ExternalProject and FetchContent families of functions (and the CPM project as well). Every one had its own set of awkward tradeoffs, and I didn't find any of them as simple and clean as what I've done here. You can see those other implemented variously in OpenEXR (which uses FetchContent, I think, to get Imath) and OpenColorIO (which uses ExternalProject for all its dependencies). Both seem to require considerable setup before the ExternalProject/FetchContent, and considerable extra work after, to fix up everything just right. Whereas I feel like my stab at it is a really minimal way to get EXACTLY what you would get if it found the project externally -- in fact, after doing a build, it just does another find_project so it really does read the exported cmake files of a clean build of the dependency (none of the others work that way).
Here is OpenColorIO's code to build OpenEXR when not found: https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/share/cmake/modules/install/InstallOpenEXR.cmake
It's based on ExternalProject_Add and you can see how much ridiculous cruft must surround it. Every one of their dependencies needs a similarly impenetrable file. Compare that to my build_OpenEXR.cmake in this PR, and you can perhaps understand how I arrived at this solution after trying the others.
Note that the general setup I have where it looks externally, then if not found, runs whatever is in the build_blah.cmake, can do anything in that build file. Nothing stops one of the build_blah files from doing ExternalProject or FetchContent or CPM or anything else if it wants. So it's trivial to switch the methodology of that part if we decide down the road that I'm just totally misunderstanding those and they are easy after all. I allow for the possibility that I (and maybe OpenColorIO's authors and those of every other project I looked at) have misunderstood ExternalProject/FetchContent and made it overly complicated. I could be wrong.

One issue with FetchContent/ExternalProject is that it's very awkward if the dependency is cmake based, and moreover must have its cmake build system carefully written to be safely included as a subproject. My scheme makes no such assumptions.

I see. That's disappointing to hear. From the advertising it sounded like those commands were solving the exact same problem in a built-in way that would (hopefully) be more familiar to anyone doing the build and more likely to work across platforms out of the box.
From what I was reading -- the whole point of ExternalProject is that you get to invoke cmake again and control its environment exactly. I'm not sure why it would require anything special from the target project (in fact it claims to work with any build system, not just cmake). Once the recursive cmake configure,build,install succeeds, it should be in the build folder as if it had been installed on the system and should be able to be picked up as such. The only catch is that you are getting a completely independent cmake session, so any arguments you want to forward (like compiler, build type, etc...) you have to pass in manually. That could definitely get verbose, although I guess some of that could be automated.
FetchContent on the other hand, definitely seems a bit more fragile because if I understood it correctly, all it does is it adds the fetched projects' targets to yours. So I could definitely see that a not-so well behaved project could make a mess. But for well-behaved project with modern cmake throughout, you get (in theory) a clean dependency graph of all the targets and they all execute within the same cmake session (for better or worse).
In any case, didn't mean to derail the conversation -- it could be that over time the official cmake way of doing things will mature and will be able to be swapped in as you said.

So here is my understanding:
FetchContent just gets stuff and puts it in your tree. It doesn't invoke any build as far as I know, you'd need to add all that logic. But it does it immediately at configure time, so may be ok for a header-only library. I believe that the integration between FetchContent and find_package is fairly new, and we can't count on a cmake that recent unless we make our cmake minimum much higher than any of the other related projects.
ExternalProject gives you the works, including build steps, etc., but the problem is that the download doesn't happen until the build step itself, which is problematic for two reasons -- first, many distros and build setups have firm rules against needing internet access beyond the configure step, and second, it means that you can't use the targets or anything else you would've learned from the config files for the rest of your build step.
I also tried CPM which at first appeared to be exactly the wrapping and simplification I wanted, but I found that is really only works for very well structured cmake projects and I had trouble getting it all quite right with the interdependencies of OpenEXR, Imath, and OpenColorIO.
What I found trying to explore these in detail is that they are pretty good under certain conditions: (1) well structured dependencies that have already made themselves subproject-friendly, (2) independent dependencies, so you don't need to worry much about a package that is both a direct dependency of you and also of other dependencies, (3) your aim is unconditional building of dependencies rather than a somewhat complex set of rules we have about preferring system installs. I just didn't find the level of control I preferred, with all the little features I wanted, in a way that it could be expressed compactly for each dependency and didn't require me to have to fight to find exactly the right secret incantation to make it work. So I wrote my one from scratch that covers exactly what we need, with a very simple use-site notation.
I dunno, I could be wrong. But I couldn't make them work without feeling like I was jumping through some ugly hoops. What I would like to do is get this scheme integrated, and then it is easy for us to experimentally swap out any individual dependency's build_dependency_with_cmake call with a FetchContent or ExternalProject to see if that works better.

Just wondering what are the reasons that Conan or Vcpkg got dismissed as a solution to manage dependencies?

Externally built dependencies, or automatic locally built dependencies?
For external, we don't dismiss either.  The "local build" facilities are for when they aren't found externally using whatever dependency management the user or their system has set up.
I have to admit that I'm not crazy about vcpkg in practice for the CI because, as far as I know, there are no cached binaries, no easy way to have it build only the mode you care about (e.g. for our CI, I want to build only release mode, but I seem to have no choice but to pay to burn GHA minutes for vcpkg building debug even though I'm not going to use it), and there's no fine control over which version of each dependency I get or what other build-time controls are used. I'm not sure how (or if) those can be overridden when invoking vcpkg, without doctoring the individual recipe files of ever dependency.
But if you're happy with whatever version of the dependencies vcpkg is pegged to, and the build options it uses, and don't mind that it'll build both debug and optimized (which is fine if you're going to do that build once and then use it for weeks or months), it's totally fine.
Conan -- Again, nothing wrong with it. I'm not experienced enough with it to know if it's any better in terms of easy command-based overriding of version or build options of the dependencies without doctoring recipe files or whatnot. I did look at it potentially as the basis of this PR, and to be honest, I don't remember the specific reason I chose to mostly roll my own. I think maybe it just didn't give me all the controls I needed, or maybe it was my fault and I didn't investigate deeply enough, or perhaps I thought I could cobble something together faster than it would take me to deeply learn the Conan way.
I wish I had a more principled answer to explain. But the long and short of it was that I looked at several solutions: cmake ExternalProject_Add, CPM, Conan, and some others. I found strengths and weaknesses to them all, hard to decide among them, and in the end I broke the paralysis by taking a shot at writing the dead simplest solution I could think of to exactly solve our use case with no additional complexity or cognitive load.

Thanks for your answer! I think the complexity and cognitive are very valid reasons. My intention is not to change your mind, but I was curious on the thoughts behind the choices. I think that needing finer control with vcpkg or Conan is a common issue.

I have to admit that I'm not crazy about vcpkg in practice for the CI because, as far as I know, there are no cached binaries, no easy way to have it build only the mode you care about (e.g. for our CI, I want to build only release mode, but I seem to have no choice but to pay to burn GHA minutes for vcpkg building debug even though I'm not going to use it), and there's no fine control over which version of each dependency I get or what other build-time controls are used. I'm not sure how (or if) those can be overridden when invoking vcpkg, without doctoring the individual recipe files of ever dependency.

You can use the default triplets (or the community triplets) to build in Release or Debug only. That would definitely save you those GHA minutes.
I don't recall if it is enabled by default, but vcpkg do have a local binary cache that can save you a lot of build time.

But if you're happy with whatever version of the dependencies vcpkg is pegged to, and the build options it uses, and don't mind that it'll build both debug and optimized (which is fine if you're going to do that build once and then use it for weeks or months), it's totally fine.

I had similar issues regarding transient dependencies. For example, if you have multiple dependencies that uses zlib, I don't recall a way to control the version of zlib for all your dependencies - But you can control the version of your direct dependencies using manifest mode (within the versions that are made available by the package).

Conan -- Again, nothing wrong with it. I'm not experienced enough with it to know if it's any better in terms of easy command-based overriding of version or build options of the dependencies without doctoring recipe files or whatnot. I did look at it potentially as the basis of this PR, and to be honest, I don't remember the specific reason I chose to mostly roll my own. I think maybe it just didn't give me all the controls I needed, or maybe it was my fault and I didn't investigate deeply enough, or perhaps I thought I could cobble something together faster than it would take me to deeply learn the Conan way.

I've worked with Conan for awhile and while I like the concept of it, it can feel like you don't have all the low-level control that you would like sometimes (e.g. the way the Cmake generators are implemented)
With Conan, you can control the version of your direct and transient dependencies - which is a big plus over Vcpkg, but it does have a bigger cognitive load.

You can use the default triplets (or the community triplets) to build in Release or Debug only. That would definitely save you those GHA minutes.

@cedrik-fuoco Could you elaborate? What do I need to do in particular to a line like
vcpkg install tiff:x64-windows

to make it only build the release version?

You can use the default triplets (or the community triplets) to build in Release or Debug only. That would definitely save you those GHA minutes.

@cedrik-fuoco Could you elaborate? What do I need to do in particular to a line like
vcpkg install tiff:x64-windows

to make it only build the release version?

vcpkg install tiff:x64-windows-release or vcpkg install tiff --triplet x64-windows-release (same behavior, different syntax)
It uses the Community triplets, but they come with Vcpkg: https://github.com/microsoft/vcpkg/tree/master/triplets/community

@cedrik-fuoco Thanks, that's very helpful!

So, here is where we are, I think. This PR basically consists of two parts, both conceptually simple:

When we search for a dependency PKG and it's not found, now it knows to check for src/build-scripts/build_PKG.cmake, and if that exists, it will include that file and run the code therein.
This is fully general, the file can do literally anything, though the baseline assumption is that it either (a) does something to directly add the targets for the dependency to the local build of OIIO, or (b) does something that will allow a second attempt at find_package to succeed and we can then go on our way exactly as if it had been found "externally" the first time.
There are many possible approaches one could take in those files: ExternalProject_Add, FetchContent, CPM, Conan, many flavors of roll your own. It literally doesn't care, as long as whatever it does permits either option (a) or (b) above.

I've taken a stab at making such "build" files for OpenEXR, Imath, and OpenColorIO, which in my current implementation are the simplest "roll your own" variety I could get away with, utilizing some utility functions I wrote that make it super easy to download a GitHub-based project that uses CMake, run the configure and build steps, and end up with a private install in OIIO's own build directory, which is then used to continue our build.

That's really it. Note that item 2 is not set in stone. At any point, we could improve the methodology, switch to one of the other methods, or mix and match with each additional dependency choosing the best/simplest approach to do a local build of itself.
Also note that by default, "external" (on the system already) installations of the dependencies will always be used if found (and in the acceptable range of versions), so none of this local build stuff kicks in at all except for dependencies that appear to be missing at build time.
I don't think it's possible for this to break or change anybody's setup who already has the right dependencies installed in their build environment.
I'd love to get approvals for this PR and do an initial merge, and then we can continue to refine and add more dependencies over time. My goal is that by the time we release OIIO 3.0, we'll have worked out how to make these builders for most or all of the major dependencies, so that more of them can be effectively treated as required/assumed dependencies, while decreasing the burden on downstream users/builders to have to worry about pre-building dependencies.

We discussed this at yesterday's TSC meeting, and the consensus seemed to be that maybe the right default should be NOT to automatically build the missing dependencies, for fear that some downstream users may require specific dependency versions (or maybe customized builds of those dependencies), think they have those pre-installed, but if our build system doesn't find them and the automatic builds kick in, they may inadvertently get versions different than their requirement. Lee advocated for the initial OIIO build to fail if dependencies were missing, but to give a clear message saying how to turn on the option to do the automatic dependency building.
So I've amended the PR again: Make the default be to NOT build any local packages unless explicitly instructed. (Except for robinmap and fmt, which we had always automatically downloaded if missing; we continue to do that.)
But we also add a nice report after config that details which missing optinal dependencies we could have built and how to arrange it.
Here's an example of what gets printed at the very end of our build, let me know what you think @lkerley:

Will merge this by end of day tomorrow if nobody has further comments or objections.

I think the OCIO-1.1 minimum thing may have broken the build system's ability to "refind" the just-automatically-built OpenColorIO-2.3.2 (i.e., with -DOpenImageIO_BUILD_MISSING_DEPS=all):
...
[18/19] Install the project...
-- Install configuration: "Release"
-- Refinding OpenColorIO
CMake Warning at src/cmake/modules/FindOpenColorIO.cmake:35 (find_package):
  Could not find a configuration file for package "OpenColorIO" that is
  compatible with requested version range "1.1...<2.9".

  The following configuration files were considered but not accepted:

    /var/folders/w7/h_1h043d5jlbq4gz7rzxdwdm0000gn/T/tmp8q4w10fu/build/deps/dist/lib/cmake/OpenColorIO/OpenColorIOConfig.cmake, version: **2.3.2**

Call Stack (most recent call first):
  src/cmake/dependency_utils.cmake:335 (find_package)
  src/cmake/externalpackages.cmake:126 (checked_find_package)
  CMakeLists.txt:176 (include)

CMake Warning (dev) at /Users/zach/.rye/tools/cmake/lib/python3.12/site-packages/cmake/data/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:447 (message):
  `find_package()` specify a version range but the module OpenColorIO does
  not support this capability.  Only the lower endpoint of the range will be
  used.
Call Stack (most recent call first):
  src/cmake/modules/FindOpenColorIO.cmake:87 (find_package_handle_standard_args)
  src/cmake/dependency_utils.cmake:335 (find_package)
  src/cmake/externalpackages.cmake:126 (checked_find_package)
  CMakeLists.txt:176 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- OpenColorIO library not found
--     OpenColorIO_ROOT was: /var/folders/w7/h_1h043d5jlbq4gz7rzxdwdm0000gn/T/tmp8q4w10fu/build/deps/dist
--     Maybe this will help:  src/build-scripts/build_OpenColorIO.bash
...

No problems building or refinding Imath-3.1.10 and OpenEXR-3.2.4...!
- All build dependencies: BZip2 1.0.8;DCMTK NONE;FFmpeg NONE;fmt 10.2.1;Freetype 2.13.2;GIF NONE;Imath 3.1.10;JXL NONE;Libheif NONE;libjpeg-turbo 3.0.0;LibRaw NONE;OpenColorIO NONE;OpenCV NONE;OpenEXR 3.2.4;OpenGL;OpenJPEG 2.5;PNG 1.6.40;Ptex NONE;Ptex NONE;pybind11 2.12.0;Python 3.9.16;Qt5 NONE;Qt6 NONE;Robinmap;TBB NONE;TIFF 4.5.1;WebP NONE;ZLIB 1.2.12

however, the report seems to think that all of the dependencies are missing:
-- =========================================================================
--
-- The following dependencies were not found:
--     Imath
--     OpenEXR
--     JXL
--     OpenColorIO
--     OpenCV
--     TBB
--     DCMTK
--     FFmpeg
--     GIF
--     Libheif
--     LibRaw
--     Ptex
--     Ptex
--     WebP
--     Nuke
--     Qt6
--     Qt5
--     Robinmap
--     fmt
--
-- For some of these, we can build them locally:
--     Imath
--     OpenEXR
--     OpenColorIO
--     Robinmap
--     fmt
-- To build them automatically if not found, build again with option:
--     -DOpenImageIO_BUILD_MISSING_DEPS=all
--
-- =========================================================================

(the report is lovely, btw, even if is filled with lies and deceit)

Ok, I think maybe I know what's wrong. Will update.

I was unable to reproduce any problematic behavior, and the thing I suspected turned out not to be broken. I pushed an update that improves the output somewhat (based on ideas I had for making it clearer while trying unsuccessfully to reproduce), but that doesn't address the problem that you describe, @zachlewis.
I don't see why putting the OpenColorIO minimum back to 1.1 should matter. (Aside: Do you by any chance have an OCIO < 2.1 installed somewhere that might be getting found and interfering with things?)
Can you try checking out a new version of this patch and trying a clean build with it? And if something goes wrong, can you please send me the FULL verbose cmake output of the whole configure and build process, maybe I can spot some clue.

Thanks, Larry --
I can pretty reliably reproduce on my end -- if I adjust src/cmake/externalpackages.cmake so VERSION_MIN and VERSION_MAX for OpenColorIO are 2.1 and 3.0 respectively, everything works as expected -- the build process either uses whatever OpenColorIO it can find, or builds its own locally.
If I don't do anything, and leave externalpackages.cmake alone, whether or not the build process first finds an existing OpenColorIO-2, the build process build its own OpenColorIO; but ultimately decides not to use it, and continues building OIIO without OCIO support.
I've created a gist here that includes the logs of three different builds, as well as the rez package.py I'm using to test building OIIO under different conditions / constellations of requirements.

zachlewis_oiio_build_24060620.log: The build process finds the provided OpenColorIO-2.4, doesn't like it, builds its own OCIO locally, doesn't like it either, and builds without OCIO support.
zachlewis_oiio_build_24060621.log: If I patch src/cmake/externalpackages.cmake and provide an existing OpenColorIO-2 package the build process links the found libraries
zachlewis_oiio_build_24060622.log: If I patch  src/cmake/externalpackages.cmake and do not provide an existing OpenColorIO package, the build process builds it own OCIO locally, and continues building with OCIO support.

Thanks! Is that OCIO package you have installed a top-of-tree OCIO rather than any actual release? Maybe that's the key.

Thanks! Is that OCIO package you have installed a top-of-tree OCIO rather than any actual release? Maybe that's the key.

Hmm, good thought. I'd been testing with top-of-tree packages; but I just tried with an OCIO package built from the released  OCIO v2.3.2.tar.gz, and the behavior is consistent with what I've been experiencing with the top-of-tree OCIO packages.

I don't quite have a full reproduction as you described it originally, but I am (with OCIO TOT) able to have it not find an external OCIO, build it locally, and then not find the local one it just built! So I think I might be on the trail.

I found some real problem with the way I was doing version checking. Revising and testing now. Stay tuned...

OK, @zachlewis, give a try? I think I might have it.
The Windows 2022 CI failure appears to be unrelated to this PR -- it's having the same errors on the nightly test against master, and just started yesterday, so I think it's one of those occasional breakages of the github runner setups that they usually fix within a few days.

OK, @zachlewis, give a try? I think I might have it.

You did it!!! Well done, man. I appreciate the effort you've been putting in to this.

Whew! OK, then, I'm going to take the W and merge this so we snapshot where we are. I'm sure there will be continued refinement.


Getting resolve: Host not found (authoritative) from a valid address.

I'm trying to convert my discord library, Discord++, from Websocket++ to Beast, as Webscoket++ was (I think) causing random disconnects, and I'm getting a resolve: Host not found (authoritative) at the boost::asio::connect in
std::string const host = fetchGateway(token);
    boost::asio::ip::tcp::resolver r{asio_ios_};
    boost::asio::ip::tcp::socket sock{asio_ios_};
    boost::asio::connect(sock,
                         r.resolve(boost::asio::ip::tcp::resolver::query{host, "80"}));

as well as the SSL example. fetchGateway(token) is calling this Discord API endpoint to get the URL wss://gateway.discord.gg with CurlPP. It worked with Websocket++, I'm probably doing something very wrong here. Does anyone know what?

Hmm....your code looks right. I'm not sure what the problem is, or even if there is a problem. It looks like your program (or computer) is not connected to the Internet, or DNS services are not configured correctly. This StackOverflow question seems to address your use case, maybe it can help?
http://stackoverflow.com/questions/5971242/how-does-boost-asios-hostname-resolution-work-on-linux-is-it-possible-to-use-n

I'll give to SO question you linked a read. The part that's really confusing me is that the old Websocket++ version is still making the connection, but this can't.

If possible, try to step through websocket++ and see what the API calls are returning, and compare that with what you're getting from your own code.

You have to remove the protocol in the gateway URL and use https instead of the port. You can take a look at how I did this here.
I also get regular disconnects from the Discord gateway, and I suspect Discord being at fault here rather than the client library.

What is the value of host in your example? You seem to suggest that it is: wss://gateway.discord.gg. If that's true, then this will never work. Can you manually specify gateway.discord.gg instead, and see if that works?

Thank you everyone! New error, so that's progress, I guess. I now have:
// Normal boost::asio setup
    std::string host = fetchGateway(token);
    std::string::size_type protocolPos = host.find("wss://");
    if (protocolPos != std::string::npos) {
        host.erase(protocolPos, 6);
    }
    boost::asio::ip::tcp::resolver r{asio_ios_};
    boost::asio::ip::tcp::socket sock{asio_ios_};
    boost::asio::connect(sock,
                         r.resolve(boost::asio::ip::tcp::resolver::query{host, "https"}));

Which results in
terminate called after throwing an instance of 'boost::system::system_error'
  what():  upgrade request failed

Anyone know what this means?

upgrade request failed is a Beast error. It looks like you're connecting to their https protocol. Try using query{host, "wss")
Also, where's the rest of your code? The part that sets up the beast::websocket::stream? You're trying to do OpenSSL are you handshaking correctly? Where's the code?

I added some debug prints, it's actually failing a few lines later, at the handshake. Give me a sec to try some stuff.

I tried "80" "http" and "wss", none of them seemed to work.
Here's the code in question

If you want to connect to Secure WebSockets ("wss") you need to use OpenSSL. See:
https://github.com/vinniefalco/Beast/blob/master/examples/ssl/websocket_ssl_example.cpp

You seem to be using HTTP but trying to talk to an HTTPS server. From everything I can see, discord doesn't allow HTTP. You need to use the SSL-aware Boost ASIO sockets.

Ok, I switched back to the SSL code I'd been trying to use with the wss::// clipped off, and it gets through the connections. Now I'm getting Process finished with exit code 139 (interrupted by signal 11: SIGSEGV) which I think is coming from sometime after I tell asio_ios_ to run. Did I mess up something with my async?

Sounds like you have a lot going on there. Consider taking the Beast websocket SSL example as a starting point, change the code to connect to the Discord server, and then slowly adapt the code to suit your needs - this way, you start from something that works.

Ok

Closing this, since the issue it's about was solved.