[FEAT REQ.] - Drop trailing F from fix-drawing aliases

Related: #20 (original implementation)
Describe the solution you'd like
I know the effort to clearly differentiate between chart-link-opening (.******C) and fix-drawing (.******F) aliases by using the -C and -F extensions was a conscious one, but I'd like to open a discussion about trading away the verbosity in exchange for shorter aliases.
From my perspective, the far more common use case is to draw the fixes on the scope, compared to opening the chart. I propose removing the -F aliases, and replacing with the formatting below:
.MIAHILEY .FF FIXXA FIXXB FIXXC...
.MIAHILEYC .OPENURL http://link.to.chart/for/hileyArrival

Describe alternatives you've considered

Instead of using the extensionless aliases for fix drawing, they could be used to bring up the chart, but given the commonality of bringing up the fixes compared to bringing up the chart,
Take no action, and leave the -F and -C suffixes.
Support both the nondiscrete and verbose options, by mapping the extensionless aliases to the verbose ones, ie adding .MIAHILEY .MIAHILEYF.
If no changes were adopted, this could be post-processed at the facility level to replace -F with extensionless, as my facility would absolutely do (and I expect others would do the same). I would much rather avoid the need for downstream re-modifications for the sake of consistency and ease of use of the NASR2SCT output data, by simply handling it with the tool.

The F suffix comes from the distinction of our local facility having a command that draws the lines diagram for the procedure, for example:
.TPADADES
Would draw the DADES6 departure out of TPA lines on the scope.
This isn’t used much anymore so now we kept the F because of the long time standing of the syntax and keeping a “standard” if you will, with having the distinction there.
I also want to keep the base (no suffix syntax) open to possible future developments or bringing back the line-draw feature that automatically sets that up for the facility.
I recognize that I may have a bias view on it, I am open to further discussion on it.

The F suffix comes from the distinction of our local facility having a command that draws the lines diagram for the procedure, for example:
.TPADADES
Would draw the DADES6 departure out of TPA lines on the scope.
This isn’t used much anymore so now we kept the F because of the long time standing of the syntax and keeping a “standard” if you will, with having the distinction there.
I also want to keep the base (no suffix syntax) open to possible future developments or bringing back the line-draw feature that automatically sets that up for the facility.
I recognize that I may have a bias view on it, I am open to further discussion on it.

I like your thinking however I do agree with @KSanders7070 on this matter. I am open for discussion on it as well. Here is perhaps a solution that could work and would be relatively "easy" to implement.
I could include a "settings" option. Think of this as like a checkbox (when checked, it would include the "F"; unchecked, it wouldn't include the "F"). However, I feel like I would need more "setting options" in order to feel like this is worth doing. It could be done. I am open to other Ideas as well.
I don't think I want a lot of "customizable" settings in this tool because it is made with the idea that most, if not all, ARTCC's will be using the same "standard." I do realize every ARTCC is going to have custom data and custom alias files for their own needs, but with the data provided from the FAA there are a lot of variables that should be kept to a standard format. That is what this tool has achieved, for the most part.

I like your thinking however I do agree with @KSanders7070 on this matter. I am open for discussion on it as well. Here is perhaps a solution that could work and would be relatively "easy" to implement.
I could include a "settings" option. Think of this as like a checkbox (when checked, it would include the "F"; unchecked, it wouldn't include the "F"). However, I feel like I would need more "setting options" in order to feel like this is worth doing. It could be done. I am open to other Ideas as well.
I don't think I want a lot of "customizable" settings in this tool because it is made with the idea that most, if not all, ARTCC's will be using the same "standard." I do realize every ARTCC is going to have custom data and custom alias files for their own needs, but with the data provided from the FAA there are a lot of variables that should be kept to a standard format. That is what this tool has achieved, for the most part.

What if you had it so the general command did both?
.LAWGRF - Pulls up the Fixed
.LAWGRC - Opens the Chart
.LAWGR - Does both( .LAWGR .LAWGRF .LAWGRC <- how it would look in the alias)
That way if the controller is completely unfamiliar they can quickly get access to both.

What if you had it so the general command did both?
.LAWGRF - Pulls up the Fixed
.LAWGRC - Opens the Chart
.LAWGR - Does both( .LAWGR .LAWGRF .LAWGRC <- how it would look in the alias)
That way if the controller is completely unfamiliar they can quickly get access to both.

I've tried that. Combining certain aliases that use arguments after it don't work with the software.

I've tried that. Combining certain aliases that use arguments after it don't work with the software.

I generally prefer the -C and -F syntax as it is clear and obvious what you are aiming to do. Ultimately both do it in a similar fashion so the main concern about removing the affix -F is in the future if we need to add additional commands, not everything follows the same syntax.
This falls back to the use of the facility specific ISR. We have changed the ISR to follow the same formatting, so we have .seasummadel so having .seasummaf and .seasummac makes sense. Removing the f may add confusion as it breaks the clear formatting structure.

I generally prefer the -C and -F syntax as it is clear and obvious what you are aiming to do. Ultimately both do it in a similar fashion so the main concern about removing the affix -F is in the future if we need to add additional commands, not everything follows the same syntax.
This falls back to the use of the facility specific ISR. We have changed the ISR to follow the same formatting, so we have .seasummadel so having .seasummaf and .seasummac makes sense. Removing the f may add confusion as it breaks the clear formatting structure.

Skylar put it better than I.
To be honest, when we use to have the base command without a suffix to draw the lines, I didn’t like it. I felt like it violated the continuity.
We will keep this open to allow further discussion, though.
Erik, thanks for your feedback!

Skylar put it better than I.
To be honest, when we use to have the base command without a suffix to draw the lines, I didn’t like it. I felt like it violated the continuity.
We will keep this open to allow further discussion, though.
Erik, thanks for your feedback!

The F suffix comes from the distinction of our local facility having a command that draws the lines diagram for the procedure, for example:
.TPADADES
Would draw the DADES6 departure out of TPA lines on the scope.
This isn’t used much anymore so now we kept the F because of the long time standing of the syntax and keeping a “standard” if you will, with having the distinction there.

Okay, that explains where it comes from. Personally, I would show the fixes rather than drawing a line which has no labels, so from my perspective drawing the fixes alone solves both needs in one.

I could include a "settings" option. Think of this as like a checkbox (when checked, it would include the "F"; unchecked, it wouldn't include the "F"). However, I feel like I would need more "setting options" in order to feel like this is worth doing. It could be done. I am open to other Ideas as well.

Sure, that could be a good solution, and going with a simple config file that you'd read in (rather than building out more UI) could be a more straightforward way to support it, for those who want the output to be shaped differently from your standard.

I don't think I want a lot of "customizable" settings in this tool because it is made with the idea that most, if not all, ARTCC's will be using the same "standard." I do realize every ARTCC is going to have custom data and custom alias files for their own needs, but with the data provided from the FAA there are a lot of variables that should be kept to a standard format. That is what this tool has achieved, for the most part.

Yep, agreed 100%. 😃 In fact, the reason I opened this issue in the first place was to make a case for changing it-- rather than quietly reconfiguring at the facility level. As much as possible, the format should be consistent throughout the division because... why not. As an new outsider with no preconceived notions, the -F suffixes jumped out the most as being strange to me. And I felt strongly enough that it warranted reconsideration.

.LAWGR - Does both( .LAWGR .LAWGRF .LAWGRC <- how it would look in the alias)

As Kyle mentioned, this wouldn't work, as VRC can only process a single embedded alias command. So the above would execute .LAWGRF and then type out .LAWGRC as text. And it also wouldn't be the desired behavior-- an alternate option listed in the issue description was to do what I think you're suggesting though-- to map the extensionless command to the -F command, like this: .MIAHILEY .MIAHILEYF, making the same result achievable both for those who want to type the extra letter and for those who don't see the advantage.

In general as I see it, there are only three things an alias could do with SID/STAR data (for example):

Toggle all its fixes
Open the chart by url
Toggle the map from View --> Diagrams

I get the sense maybe others' use is different, but for me... Probably 95% or more of the usage would be from the first point alone, with almost all of the rest of the use coming from bringing up the full charts. In my day to day, it is very rare that I need a chart, and very common that I want to pull up fixes on an arrival/approach for various reasons. So given that I'm far more interested in toggling fixes than in any of the other stuff, that's the reason I would advocate for giving it the shortest variant. Short of a new ATC Client (which may come), there really is no other behavior that could be added-- and anything to be added later could just take a new suffix letter, as appropriate for its function. But given that I'd be typing .MIAHILEYF potentially hundreds of times before ever doing a .MIAHILEYC, my preference would be toward making the command I use easier to use. Note: Currently we have this mapped to .HILEY7, and moving to .MIAHILEYF would be 50% more keystrokes for the same functionality. Simple and speedy 😉
I'd be interested to hear if others really do pull up more charts than we do, or if I actually am somehow in the minority. Because if so, we can definitely handle the transformation at the facility level if we're the weird ones, I'd just really rather not have to add another step to each update. No worries either way though, just wanted to start the discussion really.

The F suffix comes from the distinction of our local facility having a command that draws the lines diagram for the procedure, for example:
.TPADADES
Would draw the DADES6 departure out of TPA lines on the scope.
This isn’t used much anymore so now we kept the F because of the long time standing of the syntax and keeping a “standard” if you will, with having the distinction there.

Okay, that explains where it comes from. Personally, I would show the fixes rather than drawing a line which has no labels, so from my perspective drawing the fixes alone solves both needs in one.

I could include a "settings" option. Think of this as like a checkbox (when checked, it would include the "F"; unchecked, it wouldn't include the "F"). However, I feel like I would need more "setting options" in order to feel like this is worth doing. It could be done. I am open to other Ideas as well.

Sure, that could be a good solution, and going with a simple config file that you'd read in (rather than building out more UI) could be a more straightforward way to support it, for those who want the output to be shaped differently from your standard.

I don't think I want a lot of "customizable" settings in this tool because it is made with the idea that most, if not all, ARTCC's will be using the same "standard." I do realize every ARTCC is going to have custom data and custom alias files for their own needs, but with the data provided from the FAA there are a lot of variables that should be kept to a standard format. That is what this tool has achieved, for the most part.

Yep, agreed 100%. 😃 In fact, the reason I opened this issue in the first place was to make a case for changing it-- rather than quietly reconfiguring at the facility level. As much as possible, the format should be consistent throughout the division because... why not. As an new outsider with no preconceived notions, the -F suffixes jumped out the most as being strange to me. And I felt strongly enough that it warranted reconsideration.

.LAWGR - Does both( .LAWGR .LAWGRF .LAWGRC <- how it would look in the alias)

As Kyle mentioned, this wouldn't work, as VRC can only process a single embedded alias command. So the above would execute .LAWGRF and then type out .LAWGRC as text. And it also wouldn't be the desired behavior-- an alternate option listed in the issue description was to do what I think you're suggesting though-- to map the extensionless command to the -F command, like this: .MIAHILEY .MIAHILEYF, making the same result achievable both for those who want to type the extra letter and for those who don't see the advantage.

In general as I see it, there are only three things an alias could do with SID/STAR data (for example):

Toggle all its fixes
Open the chart by url
Toggle the map from View --> Diagrams

I get the sense maybe others' use is different, but for me... Probably 95% or more of the usage would be from the first point alone, with almost all of the rest of the use coming from bringing up the full charts. In my day to day, it is very rare that I need a chart, and very common that I want to pull up fixes on an arrival/approach for various reasons. So given that I'm far more interested in toggling fixes than in any of the other stuff, that's the reason I would advocate for giving it the shortest variant. Short of a new ATC Client (which may come), there really is no other behavior that could be added-- and anything to be added later could just take a new suffix letter, as appropriate for its function. But given that I'd be typing .MIAHILEYF potentially hundreds of times before ever doing a .MIAHILEYC, my preference would be toward making the command I use easier to use. Note: Currently we have this mapped to .HILEY7, and moving to .MIAHILEYF would be 50% more keystrokes for the same functionality. Simple and speedy 😉
I'd be interested to hear if others really do pull up more charts than we do, or if I actually am somehow in the minority. Because if so, we can definitely handle the transformation at the facility level if we're the weird ones, I'd just really rather not have to add another step to each update. No worries either way though, just wanted to start the discussion really.

The biggest thing that would add confusion is for ZSE and ZLC's ISR or In-Scope-Reference.
Currently, we would have these commands:
.seasummaf -- draws the fixes on the summa departure
.seasummac -- pulls up the charts
.seasummadel -- provides an ISR private message with relevant details for the delivery controller. We have variants on this for all arrivals and departures for all of our towered fields and they follow the same syntax. So any Ground or Tower or Departure, Center or Approach would follow the same syntax IE .seasummagnd , seasummatwr, .seasummadep, .seasummactr.
https://i.imgur.com/OghBCWJ.png
So keeping the F when everything else has an extension for a reason makes sense from a continuity perspective. You will always know that it is .APT[SID/STAR]F for the fixes and .APT[SID/STAR}C for the chart. And then our Approach procedures are the same .SEAI6LF .SEAI6LC for Seattle ILS 16L fixes and charts.
I understand that not EVERYONE has this and most will not want to do the immense legwork to setup the ISR to begin with, but it matches the syntax and keeps things with a similar logic profile. F for fixes, C for charts, 3-letter for your position (del/gnd/twr/dep/app/ctr) for ISR commands.

The biggest thing that would add confusion is for ZSE and ZLC's ISR or In-Scope-Reference.
Currently, we would have these commands:
.seasummaf -- draws the fixes on the summa departure
.seasummac -- pulls up the charts
.seasummadel -- provides an ISR private message with relevant details for the delivery controller. We have variants on this for all arrivals and departures for all of our towered fields and they follow the same syntax. So any Ground or Tower or Departure, Center or Approach would follow the same syntax IE .seasummagnd , seasummatwr, .seasummadep, .seasummactr.
https://i.imgur.com/OghBCWJ.png
So keeping the F when everything else has an extension for a reason makes sense from a continuity perspective. You will always know that it is .APT[SID/STAR]F for the fixes and .APT[SID/STAR}C for the chart. And then our Approach procedures are the same .SEAI6LF .SEAI6LC for Seattle ILS 16L fixes and charts.
I understand that not EVERYONE has this and most will not want to do the immense legwork to setup the ISR to begin with, but it matches the syntax and keeps things with a similar logic profile. F for fixes, C for charts, 3-letter for your position (del/gnd/twr/dep/app/ctr) for ISR commands.

Erik,
That is a very well written response and helps us see why you would want that more and I would consider this a valid request.
I myself find myself bringing up the CHARTS more than the fixes lol... Anytime I need some sort of reference, it is usually out in the middle of nowhere that nobody ever flies so I feel better glancing at the chart and getting the idea of how it works and I usually don't need the fixes. Everybody has their own flavor I guess haha...
Unfortunately, as you and Skylar noted, trying to make a standard is more of our goal right now than removing a letter in a syntax to make it easier to type. After a few rounds of controlling, it tends to grown on you as a muscle memory and the SYNTAX seems to be more intuitive with the F at the end... because then you look at the chart recall... and you see that C there and you are like “Well.. ya.. of course it has a C at the end because the Fix command is built the same way.”
Creating some of these commands, I wasn't happy with it and I tried numerous different ways of doing this but what we have done here is built a very inclusive system that works FAA-Wide lol... this was one heck of a project... A successful compromise is one that nobody is completely happy with... the syntax is a compromise and I think it is a good one.
When students first come in and they see the length of some of our commands, they usually a little intimidated until they get the breakdown for it. Then after only a single session, they are able to complete the same command for thousands of different procedures, regardless of the airport or region/ARTCC it belongs too within 2-3 seconds. They then have the “Ah Ha!” moment and they just get it from that point.
We knew that these type of requests would eventually come in and we are thankful for them because we do not assume we have the best way to do something but we do know what our goals are so please keep them coming. If you suggest something that maintains a standard in a more efficient way and takes as many procedures (FAA-Wide) into account as possible, that is when we will most definitely go back to the drawing board but with this particular request, this may be something that is converted at the facility level.
Facility level conversions are obviously completely fine... but if we have a bunch of facilities doing things slightly different to do the same thing, that would somewhat be counterproductive.
But again... completely up to you.
Nik- I would still like to keep this thread open just in case someone has some other trick to get this done the way he is suggesting. At least until VATUSA starts using it.

Erik,
That is a very well written response and helps us see why you would want that more and I would consider this a valid request.
I myself find myself bringing up the CHARTS more than the fixes lol... Anytime I need some sort of reference, it is usually out in the middle of nowhere that nobody ever flies so I feel better glancing at the chart and getting the idea of how it works and I usually don't need the fixes. Everybody has their own flavor I guess haha...
Unfortunately, as you and Skylar noted, trying to make a standard is more of our goal right now than removing a letter in a syntax to make it easier to type. After a few rounds of controlling, it tends to grown on you as a muscle memory and the SYNTAX seems to be more intuitive with the F at the end... because then you look at the chart recall... and you see that C there and you are like “Well.. ya.. of course it has a C at the end because the Fix command is built the same way.”
Creating some of these commands, I wasn't happy with it and I tried numerous different ways of doing this but what we have done here is built a very inclusive system that works FAA-Wide lol... this was one heck of a project... A successful compromise is one that nobody is completely happy with... the syntax is a compromise and I think it is a good one.
When students first come in and they see the length of some of our commands, they usually a little intimidated until they get the breakdown for it. Then after only a single session, they are able to complete the same command for thousands of different procedures, regardless of the airport or region/ARTCC it belongs too within 2-3 seconds. They then have the “Ah Ha!” moment and they just get it from that point.
We knew that these type of requests would eventually come in and we are thankful for them because we do not assume we have the best way to do something but we do know what our goals are so please keep them coming. If you suggest something that maintains a standard in a more efficient way and takes as many procedures (FAA-Wide) into account as possible, that is when we will most definitely go back to the drawing board but with this particular request, this may be something that is converted at the facility level.
Facility level conversions are obviously completely fine... but if we have a bunch of facilities doing things slightly different to do the same thing, that would somewhat be counterproductive.
But again... completely up to you.
Nik- I would still like to keep this thread open just in case someone has some other trick to get this done the way he is suggesting. At least until VATUSA starts using it.

Unfortunately, as you and Skylar noted, trying to make a standard is more of our goal right now than removing a letter in a syntax to make it easier to type. After a few rounds of controlling, it tends to grown on you as a muscle memory and the SYNTAX seems to be more intuitive with the F at the end... because then you look at the chart recall... and you see that C there and you are like “Well.. ya.. of course it has a C at the end because the Fix command is built the same way.”

Sure, my suggestion was based on my usage of almost exclusively fix drawing, with little interest in the rest, which is the reason to propose it being so fix-drawing centric. I would explain to my people as To bring up the fixes for a SID/STAR, specify the airport and procedure name without the number, like ".MIAHEDLY" or ".MIAHILEY", or airways with .Q77/.Y280 / etc. If a chart is available, you can bring it up by adding a C to the end, like ".MIAHEDLYC" or ".MIAHILEYC".
Deeper features like facility specific ISR (.seasummadel) are just not something we would be likely to implement. Our sole interests would be in:

having easily updatable nav data
aliases to bring up SID/STAR/IAP/AWY fixes
aliases to bring up SID/STAR/IAP/APD charts

Given that all we want is fixes and charts (and usually just fixes), saying add a C if you want the chart to me seemed no less of a reasonable how-to for new users. I do still think adding an additional alias to support this behavior has no quantifiable downside, i.e. .SEASUMMA .SEASUMMAF. But regardless, for now we can handle the change at our facility level.

Unfortunately, as you and Skylar noted, trying to make a standard is more of our goal right now than removing a letter in a syntax to make it easier to type. After a few rounds of controlling, it tends to grown on you as a muscle memory and the SYNTAX seems to be more intuitive with the F at the end... because then you look at the chart recall... and you see that C there and you are like “Well.. ya.. of course it has a C at the end because the Fix command is built the same way.”

Sure, my suggestion was based on my usage of almost exclusively fix drawing, with little interest in the rest, which is the reason to propose it being so fix-drawing centric. I would explain to my people as To bring up the fixes for a SID/STAR, specify the airport and procedure name without the number, like ".MIAHEDLY" or ".MIAHILEY", or airways with .Q77/.Y280 / etc. If a chart is available, you can bring it up by adding a C to the end, like ".MIAHEDLYC" or ".MIAHILEYC".
Deeper features like facility specific ISR (.seasummadel) are just not something we would be likely to implement. Our sole interests would be in:

having easily updatable nav data
aliases to bring up SID/STAR/IAP/AWY fixes
aliases to bring up SID/STAR/IAP/APD charts

Given that all we want is fixes and charts (and usually just fixes), saying add a C if you want the chart to me seemed no less of a reasonable how-to for new users. I do still think adding an additional alias to support this behavior has no quantifiable downside, i.e. .SEASUMMA .SEASUMMAF. But regardless, for now we can handle the change at our facility level.

We shall take this under advisement and it might be a future feature with a configuration file. Until then lol...
Find:    F .FF
Replace:  .FF

We shall take this under advisement and it might be a future feature with a configuration file. Until then lol...
Find:    F .FF
Replace:  .FF

Yep! 👍

Yep! 👍

After a lot of consideration and asking around, this would break continuity that is already established for many who use these files and isn't the direction we want to take. I appreciate the feedback!


Unexpected child key found sdk

dependencies:
  flutter:
    sdk: flutter
  flutter_localizations:
    sdk: flutter
  flex_color_scheme: ^7.3.1
  bot_toast: ^4.1.3
  get: ^4.6.6
  shared_preferences: ^2.2.2
  dio: ^5.4.0
  path_provider: ^2.1.1
  easy_refresh: ^3.3.3+1
  package_info_plus: ^5.0.1
  url_launcher: ^6.2.2
  flutter_native_splash: ^2.3.8
  logger: ^2.0.2+1
  open_filex: ^4.3.4
  android_id: ^0.3.6

Unhandled exception:
Line No.: 13
Line Type: key
Section Indent: 1
Line Content:   flutter:
Error: Unexpected child key found sdk
#0      new Dependency._loadFrom (package:pubspec_manager/src/dependency.dart:25:7)
#1      PubSpec._initDependencies (package:pubspec_manager/src/pub_spec.dart:167:47)
#2      new PubSpec.loadFromString (package:pubspec_manager/src/pub_spec.dart:55:20)
#4      main (file:///f:/my/kuanneng-mobile/scripts/release.dart:11:19)
#5      _delayEntrypointInvocation. (dart:isolate-patch/isolate_patch.dart:297:19)
#6      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:184:12)

@bsutton  It seems that content with an SDK will not be parsed

In sure I had a fix for that.
Give me a day or two and I will check that I've released the latest code.
On Wed, 27 Dec 2023, 12:55 am laterdayi, @.***> wrote:

@bsutton https://github.com/bsutton It seems that content with an SDK
will not be parsed
—
Reply to this email directly, view it on GitHub
https://github.com/onepub-dev/pubspec_manager/issues/2#issuecomment-1869562562,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG32OECVXGUVQ2446SJUD3YLLJNBAVCNFSM6AAAAABBDJBXGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZGU3DENJWGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Can you confirm the version of pubspec_manager that to are using.
On Wed, 27 Dec 2023, 9:29 am Brett Sutton, @.***> wrote:

In sure I had a fix for that.
Give me a day or two and I will check that I've released the latest code.
On Wed, 27 Dec 2023, 12:55 am laterdayi, @.***> wrote:

@bsutton https://github.com/bsutton It seems that content with an SDK
will not be parsed
—
Reply to this email directly, view it on GitHub
https://github.com/onepub-dev/pubspec_manager/issues/2#issuecomment-1869562562,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG32OECVXGUVQ2446SJUD3YLLJNBAVCNFSM6AAAAABBDJBXGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZGU3DENJWGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yes, I'm using the latest version

This has been fixed in the latest version.


docs: updating readme and version for rebranding

#309
Reviewers
Functional: @seve
Readability: @seve @karenliang0

Changes

add
remove
modify
Updating Readme, init.py, and infoMenu wording for rebranding

Made the changes per the comments above. Still not sure if on infoMenu.ts it should be "About CELLxGENE" or "About CZ CELLxGENE" @ambrosejcarr

@ambrosejcarr Think this needs approval again for it to be merged

@ambrosejcarr @seve
I think we're close to merging this, could I get a final review for this whenever you guys get the chance?

Ready for staging


Testing Waypoints

We need to expand our current testing waypoints. Currently there are only two. Ideally, we want to cover a testing framework like Jasmine. We need to:

create rough list (using checkboxes) of which concepts we want to teach, in what order
start building the challenges
QA the challenges and refine their copy

Hello, I'm new to testing and also new to FreeCodeCamp. Is this testing module for Front-End/React (i.e. Jasmine) or Back-End (i.e. Mocha/Chai) ? Hopefully for all Front-End/React & Back-End.
I personally thought that it makes more sense to include testing lesson in each Front/React/Back Waypoint module than making an independent testing module since how to test Front-End, React Component, and Node/Express API are a little different. Also, TDD is important for creating projects, so it is great to be included in each project module (Ziplines & Basejump).

My preference would be for a TDD style tutorial broken up into stages.  Ideally first stage is having tests written and then have the camper make the tests pass.  Second stage would be to have user write tests first, then write code to make them pass, then have them refactor.

Ideally first stage is having tests written and then have the camper make the tests pass.

This is how every challenge on Free Code Camp currently works.

This work has moved to https://github.com/FreeCodeCamp/CurriculumExpansion


dd-trace error when next gen extension is turned on for lambda

I've encountered this error when turning on next gen extension.
I think maybe java layer needs update?
RESTORE_START Runtime Version: java:21.v27	Runtime Version ARN: arn:aws:lambda:ap-southeast-2::runtime:1fe198c3259fb2d78c1f0033293d1f68b2d4a528b2288b3a3fd80a5b6089872f
[dd.trace 2024-12-24 00:38:20:056 +0000] [dd-trace-processor] WARN datadog.trace.agent.common.writer.ddagent.DDAgentApi - Error while sending 1 (size=938B) traces. Total: 1, Received: 1, Sent: 0, Failed: 1. java.net.ConnectException: Failed to connect to localhost/<IP_ADDRESS>:8126 (Will not log warnings for 5 minutes)
RESTORE_REPORT Restore Duration: 1215.50 ms
START RequestId: d5ffdeec-41ed-47e9-b2e5-4dfc25300cc0 Version: 3
[dd.trace 2024-12-24 00:38:20:374 +0000] [main] ERROR datadog.trace.lambda.LambdaHandler - could not reach the extension
[dd.trace 2024-12-24 00:38:21:413 +0000] [main] ERROR datadog.trace.lambda.LambdaHandler - could not reach the extension, not injecting the context
java.net.ConnectException: Failed to connect to /<IP_ADDRESS>:8124
at datadog.okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:249)
at datadog.okhttp3.internal.connection.RealConnection.connect(RealConnection.java:167)
at datadog.okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:258)
at datadog.okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:135)
at datadog.okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:114)
at datadog.okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
at datadog.okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at datadog.okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at datadog.okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
at datadog.okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at datadog.okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at datadog.okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at datadog.okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at datadog.okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:127)
at datadog.okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at datadog.okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at datadog.okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:257)
at datadog.okhttp3.RealCall.execute(RealCall.java:93)
at datadog.trace.lambda.LambdaHandler.notifyEndInvocation(LambdaHandler.java:162)
at datadog.trace.agent.core.CoreTracer.notifyExtensionEnd(CoreTracer.java:956)
at com.amazonaws.services.lambda.runtime.api.client.EventHandlerLoader$PojoHandlerAsStreamHandler.handleRequest(EventHandlerLoader.java:670)
at com.amazonaws.services.lambda.runtime.api.client.EventHandlerLoader$2.call(EventHandlerLoader.java:601)
at com.amazonaws.services.lambda.runtime.api.client.AWSLambda.startRuntime(AWSLambda.java:240)
at com.amazonaws.services.lambda.runtime.api.client.AWSLambda.startRuntime(AWSLambda.java:190)
at com.amazonaws.services.lambda.runtime.api.client.AWSLambda.main(AWSLambda.java:180)
"Caused by: java.net.ConnectException: Connection refused
"
"at java.base/sun.nio.ch.Net.pollConnect(Native Method)
"
"at java.base/sun.nio.ch.Net.pollConnectNow(Unknown Source)
"
"at java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(Unknown Source)
"
"at java.base/sun.nio.ch.NioSocketImpl.connect(Unknown Source)
"
"at java.base/java.net.SocksSocketImpl.connect(Unknown Source)
"
"at java.base/java.net.Socket.connect(Unknown Source)
"
at datadog.okhttp3.internal.platform.Platform.connectSocket(Platform.java:129)
at datadog.okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:247)
... 24 more

Hey @hoangnd25, thanks for reaching out. We have tested the java layer for compatibility with our next gen extension with no issue. It looks like from this error that the problem is not the java layer but that your extension isn't starting up properly or somehow becomes unavailable.
Can you share more about your set up?

Which java version are you using?
Which version of the java layer are you using?
Which version of the extension layer are you using?
Which, if any, environment variables are you setting?
Do you have snap start enabled?
What tool are you using for deploys? Can you share a bit of that code?

With that provided, I'm looking forward to helping get to the bottom of this.


couldn't RUN the logic because of an issue with the For Each loop

Hello,
I tried to follow this template but I couldn't RUN the logic because of an issue with the For Each loop.
Failed to save logic app InvoiceProcessingLogicApp. The template validation failed: 'The inputs of template action 'Send_an_email_(V2)' at line '1 and column '1952' is invalid. Action 'For_each' must be a parent 'foreach' scope of action 'Send_an_email_(V2)' to be referenced by 'repeatItems' or 'items' functions.'.
Whereas the tuto does the same. I don't know what I did wrong but I tried but it is not working. Would please help? Thank you in advance

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 2b3eb538-18ea-7b0c-ecb0-e6b19db4ce85
Version Independent ID: e160dda4-f2c3-faa1-37b9-34345ff99d67
Content: Use Document intelligence (formerly Form Recognizer) with Azure Logic Apps - Azure AI services
Content Source: articles/ai-services/document-intelligence/tutorial-logic-apps.md
Service: applied-ai-services
Sub-service: forms-recognizer
GitHub Login: @laujan
Microsoft Alias: bemabonsu

@selfishark
Thanks for your feedback! We will investigate and update as appropriate.

@selfishark Thanks for your feedback! We will investigate and update as appropriate.

Please let me know as I am keen to pursue my studies in Document Intelligence with Azure AI.

Hi @selfishark, Thank you again for your feedback. The error that you've described occurs when the Send an email (V2) step is not included within the For each block (see below). Include the Send an email (V2) within the For each block and your Logic App should succeed.
Incorrect:

Correct:

Thanks again!

#please-close

This is right the issue was even the name of the FOR_EACH loop which did not match the Functions Items. Thank you very much @laujan and @SaibabaBalapur-MSFT !


Genesis address shows balance, should be 0

https://explorer.lbry.io/address/bHW58d37s1hBjj3wPBkn5zpCX3F8ZW3uWf - should say 0.
Internal Use
Acceptance Criteria

Definition of Done

[ ]  Tested against acceptance criteria
[ ] Tested against the assumptions of the user story
[ ] The project builds without errors
[ ] Unit tests are written and passing
[ ] Tests on devices/browsers listed in the issue have passed
[ ] QA performed & issues resolved
[ ] Refactoring completed
[ ] Any configuration or build changes documented
[ ] Documentation updated
[ ] Peer Code Review performed

Solved with Chainquery integration


added stick hero with canvas game

Fixed:#223
A simple implementation of the classic Snake game using HTML, CSS, and JavaScript. The player controls the length of the stick by holding the mouse such that it ensures the hero should cross gaps using the length of the stick.
https://github.com/user-attachments/assets/3405541f-5147-4b68-907c-83b3685e0291

Before making a PR request, please ensure to mention the issue number in the description

Added issue number


Use managed identity rather than SQL auth

Related to #65 - the deployed PostgreSQL should connect via Managed Identity rather than a SQL auth/connection string for better security practices.

Managed identity implemented for proxy and admin portal


feat(sdk): fix inscription type not exposing meta

add optional meta type to Inscription type.
this is returned by the underlying utxo-api, according to OIP-1.

@kevzzsk

What are the fields that can possibly reside in meta object?
Will meta be nested or single-level?
Can you list down the possible data types that will possibly be in properties of the meta object? (string, number, array, etc.)

meta technically can be any form of data actually. Only in OIP-1, it is defined to be of a certain JSON format.
Looking at the underlying utxo-api parsing, it does a JSON.parse which means meta can be Record type of any level, array or string.

@kevzzsk Makes sense. What fields is Ordzaar planning to include in meta? I am curious to know.

for ordzaar, meta will just be a json format that follows OIP-2 standard.


Display in Dashboard

The chart that is displayed here, how can I have that display on a dashboard?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b4914adf-b6bb-f209-d08e-88d35ff8ea78
Version Independent ID: b00bc0d2-4eb7-d154-425c-48022ce41b4b
Content: Adjust work to fit sprint capacity - Azure Boards and TFS
Content Source: docs/boards/sprints/adjust-work.md
Product: devops
Technology: devops-agile
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

Thanks for your question. It looks like you're working through an issue with your scenario or implementation, rather than an issue with the documentation. Here are a couple of options where you might consider asking your question:

Azure DevOps on Stack Overflow
Azure DevOps Support Bot


min/max incorrect behaviour?

Description
Styles are wrong on month, when chenges min and max. Version 3.0.0
Expected outcome
When min="2018-05-02" and max "2018-05-09" all May should be black (not grey) same as min="2018-05-01"
Actual outcome
All May is grey.
Live Demo

Thanks for reporting @jariberi
It's the theming issue, disabled days aren't styled properly. Looks critical to me, moving to the issue backlog.

Fixed in v3.0.1, thanks for reporting @jariberi!

@limonte, the issue still exists in v3.0.1.
/* Disabled */

:host([disabled]) * {
    color: var(--lumo-disabled-text-color) !important;
}

The !important CSS rule is in html file, when I remove that, it works perfectly.


Question - Resources from CDN or inside app

Hi,
When using external resources like fontawesome or css framework like boostrap or bulma should we import the resources on our local style.css or style.scss that is imported by the index.js,  should we add the CDN urls on the index.html or there are other better ways to do this?
In my case I want this for a PWA so this resources should be available offline after the app get's "installed".

The resources you are talking about definitely fits better in index.html as far as i can tell.
But for caching it you'll need to add it to sw config using preact-cli


CM-704: Hide sub menu items when menu item is clicked twice

Jira Ticket:
CM-704
Description:

If users click a sub-item in megamenu twice, megamenu keeps open but sub-item menu will be hidden

I think it doesn't quite behave right when you toggle between menu items.
This works as expected....

Click "Conservation"
Click "Impact assessment process"
Click "Living Lab Program" and the right panel is shown

There seems to be a glitch when you click the first item twice

Reload your browser
Click "Conservation"
Click "Impact assessment process"
Click "Impact assessment process" again
Click "Living Lab Program" and the right panel is not shown
Click "Living Lab Program" again, and now the right panel is shown

I shouldn't need to click "Living Lab Program" twice.


SQL Error: unknown escape sequence

System information:

Operating system (distribution) and version: Linux Mint 20.3
DBeaver version: 22.0.1 installed from Serge Rider's ppa
Additional extensions

Connection specification:

Database name and version: MariaDB 10.3
Driver name: org.mariadb.jdbc.Driver 2.7.1
Do you use tunnels or proxies (SSH, SOCKS, etc)?  NO

Describe the problem you're observing:
Trying to execute next simple FUNCTION:
CREATE FUNCTION myDB.printDate(myDate DATE)
RETURNS char(50)
BEGIN
return concat("The date is: ", myDate);
END
The output is:
Error occurred during SQL query execution
Razón:
SQL Error: (conn=30) unknown escape sequence {SELECT myDB.printDate('2022-03-30') }
Steps to reproduce, if exist:
Everything works fine when invoking from system console
Include any warning/errors/backtraces from the logs

{} brackets are working good for procedures, but not for functions.
Brackets removed from SELECT statement for functions from "Execute stored procedure" command for MySQL/MariaDB

Verified


python311Packages.flake8-bugbear: 23.12.2 -> 24.1.17

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.flake8-bugbear is: Plugin for Flake8 to find bugs and design problems
meta.homepage for python311Packages.flake8-bugbear is: https://github.com/PyCQA/flake8-bugbear
meta.changelog for python311Packages.flake8-bugbear is: https://github.com/PyCQA/flake8-bugbear/blob/24.1.17/README.rst#change-log
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 24.1.17 with grep in /nix/store/j33qw6kvnr45mw8hpb3j3c4vxbvk8yrj-python3.11-flake8-bugbear-24.1.17
found 24.1.17 in filename of file in /nix/store/j33qw6kvnr45mw8hpb3j3c4vxbvk8yrj-python3.11-flake8-bugbear-24.1.17

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
python311Packages.flake8-bugbear

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/j33qw6kvnr45mw8hpb3j3c4vxbvk8yrj-python3.11-flake8-bugbear-24.1.17 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.flake8-bugbear https://github.com/r-ryantm/nixpkgs/archive/7d4ac97b8b255b64b551443a4ebfc6b554acdcf7.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/7d4ac97b8b255b64b551443a4ebfc6b554acdcf7#python311Packages.flake8-bugbear

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/j33qw6kvnr45mw8hpb3j3c4vxbvk8yrj-python3.11-flake8-bugbear-24.1.17
ls -la /nix/store/j33qw6kvnr45mw8hpb3j3c4vxbvk8yrj-python3.11-flake8-bugbear-24.1.17/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

python311Packages.flake8-bugbear

Maintainer pings
cc @newAM for testing.

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

2 packages built:

python311Packages.flake8-bugbear
python311Packages.flake8-bugbear.dist


spanner-jdbc-cleanup - Step 07 - Increase timeout when creating a new test instance

When working on a local development environment in Europe, the test environment will automatically try to create an instance in a nearby configuration (europe/west). A timeout of 500 milliseconds is (way!) too short for that. This change ensures the integration tests do not fail with a timeout when executed from such an environment.

LGTM just waiting for builds to pass


Fix health path

There was a typo in setting health path, so it never worked. Also updated name/path to be consistent with scaffold.

I'm not sure what flow you've adopted, but I have no access to merge... so don't wait for me to do it. :)


Deploy router controller resource from bundle

As part of https://github.com/crc-org/snc/pull/738, we put
router-controller resource as part of bundle and from crc side
we don't need to generate this resource.

/hold
Till https://github.com/crc-org/snc/pull/738 merge and new bundle available to consume.

After this change it looks like crc won't be able to start older bundles?

@crc-org/crc-team Older bundles will not work after this PR merge. Question is do we want to support or need to have this backward compatibility for some releases?

Imo yes, at least 4.13.x bundles, and maybe even 4.12.x. But this is a team decision to make.

We are allowed to cut off support, but as long as we inform the user of this choice.
Since we do not know how many 'custom' bundles are used, this is necessary to be reported

We are allowed to cut off support, but as long as we inform the user of this choice.

"allowed" is a thing, but what do we want as a team? break backwards compat any time we need to with a warning? document that a given CRC release will support all 4.13.x bundles if it was released with 4.13.x? Go further than that and support both 4.12 and 4.13 bundles if it was released with 4.13?

It is easy to check for the file existence in /opt/crc to see if we need to generate the json file instead

Also, let's not assume anything. We could easily find the information if someone uses an older bundle with a newer version of crc, or a custom bundle. Telemtry... anyone?

/unhold
As of now I didn't remove the extra  code to use the older bundle so it now shouldn't break but in future release after 2.24 I would remove that extra code.


Interference with single quotes

I frequently use  the single quote ' to prevent zsh from parsing the text (globs etc.), and for spaces in file names.
I see that this will interfere. Why not make a custom delimiter? Prefix it with a py maybe? As in:
$ ls py'import os; os.getcwd()'

Prefixes before quotes also happens to be Pythonic! (Python uses it to denote raw strings, bytes etc.)
Or:
$ ls py(import os; os.getcwd())

(or with any other bracket)

So how this hack works is by capturing the commands which were not valid zsh commands. That's how it remains so simple.
So single quotes etc would not interfere with the zsh parsing and spaces. But the above command you wrote would not  work, since zsh does not try to interpret the argument as a command. Zpyi kicks in when you provide an invalid command, not invalid argument, since there is nothing like an invalid argument.
A way to do what you described above is:
var=$('os.getcwd()')
ls $var

Here, os.getcwd() being where shell expected a path to an executable, becomes an invalid shell command. Zpyi kicks in, and interprets it as a python command, and puts the result there.
Let me know if you still have any issue, I have some other thoughts on this too if this doesn't solve your problem :smile:

Oh, OK. Does it also return the original text in case of it being neither valid zsh or valid python?

I used to make it return an error saying:
python, zsh => Command not found

That seemed to confusing if there's a small error in your 5 line code you just entered within single quotes. I've changed it now to something else.
I tried this in shell 'asdas' and got:
Python statement invalid:
Name not found globally.
name 'asdas' is not defined

The last 2 lines are errors thrown by python while trying to evaluate this command.

On typing 'sqrt(-1)', I get:
Python statement invalid:
Inappropriate argument value (of correct type).
math domain error

So, does ls 'import os; os.getcwd()' not work?

Well, you don't need to do a import os, I already added the imports for math, os and sys. And to remain as a unobtrusive as possible,  it will not try to interpret every command. I can see it might be possible with a hook though.
Zsh calls a hook function whenever it cannot interpret a command. Zpyi plugs itself there. So since zsh does not see anything wrong with ls 'os.getcwd()', it would try to pass that string as argument to ls. Trying to interpret every argument string as a python command would be blasphemous for shell scripters :smile:
You can do something like this if you need a oneliner:
var=$('os.getcwd()') && ls $var

The code is quite small, and the installation is very non-destructive too (unlike oh-my-zsh and the likes :smile: ). You can see the code, and try it on your own, see if you like it :smile: If you do, good for you. If you don't (personal preference), removing is as easy as:
rm -rf ~/.zpyi

And then removing the line source ~/.zpyi/zpyi.zsh from your .zshrc

Oh, that's good. Thanks!


Access token missing in Graphql request

Since the update that added the CDN (nhost@latest) the Access token was not passed to GraphQl queries from nhost.graphql.request.
I had this problem with a nextjs app, but useAuthQuery works well.

Thanks for reporting.
Can you make sure the user is signed in before sending the request by do a console log like this:
// make sure user is signed in
console.log(nhost.auth.getUser())

// GraphQL request (with missing authorization header)
await nhost.graphql.request(...)

Closing this issue as it's not an nhost error.
To avoid this with react, you should wait until the user data is available.
Example:
useEffect(() => {
    if (userId) getRoom(room as string);
}, [userId]);

You can also make use of isAuthenticatedAsync to wait and see if the user is signed in or not.
https://docs.nhost.io/reference/javascript/auth/is-authenticated-async

I'm having a similar issue, where a user is logged in, but their accessToken is not passed to the graphql request.  Only workaround is to make permissions public on the tables in question.  For instance I have logic on a page that only shows a button if the user isAuthenticated (derived from useAuthenticationStatus).  I check (isAuthenticated and !loading) but when they issue the mutation via a button click, the Auth headers are not passed.  Using @nhost/nextjs version 1.6.1

Could you please share the arguments you are using when creating the Nhost client?

We were able to fix @oristian's issue by:

Upgrading all @nhost/* packages to the latest version
Removing @nhost/nhost-js and @nhost/react-auth as dependencies, and only use @nhost/nextjs, @nhost/react and @nhost/react-apollo.


Partial payment not being recognized by either WooCommerce or BTCPay

I've ended up with a partially paid invoice (the person paid less than half). WooCommerce doesn't show the partial payment. When I click on the pay button it creates a new BTCPay which doesn't recognize the previously paid amount (which is in an older BTCPay invoice).
The original payment is from 20 days ago, so the customer obviously gave up.
Is something misconfigured? Or is this a bug?

Hey sorry for the late reply, missed the notifications like always ...
You are right that use case is not covered. Partial payments are only tracked on the current invoice but if the customer tries to pay again after the partial invoice expired it will create a new invoice and the old one would not be taken into account in that case. You should still see the partial payment in the orders custom fields

So far nobody had that case it seems (or they worked around it by customer directly contacting them) but yes this case is not covered properly. It is a bit tricky though and would require breaking changes, meaning a new major release as I would need to change the custom field data structure and maybe some rely on the current structure for accounting.
Note to self what needs to be done:

track multiple invoices
not only track multiple paymens, but track multiple payments by invoice id
keep additionally track of fiat amounts as we have different exchange rates on different invoices


feat(context): Allowing hooking into the oidc-client events in the AuthenticationProvider

Closes #415
A picture tells a thousand words
Before this PR
<AuthenticationProvider
  configuration={oidcConfiguration}
  loggerLevel={oidcLog.DEBUG}
  isEnabled={true}
  callbackComponentOverride={CustomCallback}
  UserStore={InMemoryWebStorage}
>

After this PR
<AuthenticationProvider
  configuration={oidcConfiguration}
  loggerLevel={oidcLog.DEBUG}
  isEnabled={true}
  callbackComponentOverride={CustomCallback}
  UserStore={InMemoryWebStorage}
  customEvents={{
    onUserLoaded: (user) => console.log('onUserLoaded', user),
    onUserUnloaded: () => console.log('onUserUnloaded'),
    onSilentRenewError: (error) => console.log('onSilentRenewError', error),
    onUserSignedOut: () => console.log('onUserSignedOut'),
    onUserSessionChanged: () => console.log('onUserSessionChanged'),
    onAccessTokenExpiring: () => console.log('onAccessTokenExpiring'),
    onAccessTokenExpired: () => console.log('onAccessTokenExpired'),
  }}
>

Thank you @michael-wolfenden for you awesome PR.
Do you have more details on the use case why you need this ?
When do you need a publish on npm ?

Hey @guillaume-chervet
I would like to hook into the events raised by oidc-client for logging and specifically the userLoaded and userUnloaded events for setting and clearing the default authorization header for all axios requests.
This also closes the bug mentioned in #415

Hey @guillaume-chervet, are there any plans to merge this PR?

We need @oyouf review.

Any update on this? I could really use it.


Acceptance doc and comments

Coverage remained the same at 94.108% when pulling e79f6a60ca17d3a2fa8a92d3bba2463f72ea489a on acceptance-comments into f5f5dc61cff1054734a563db7e03c97a6826d1cc on develop.

Coverage remained the same at 94.108% when pulling 02da89745d7bc9fa070668161bdc75679cfa1017 on acceptance-comments into f5f5dc61cff1054734a563db7e03c97a6826d1cc on develop.


Sprite masks

Objective
Adds the ability to mask Sprites with other Images.
Implements #4210

Solution
Usage

Spawn an Entity with Mask containing a handle to the Image. Most of the other fields work like the ones from Sprite.
Spawn a SpriteBundle(s) with Masked components taking the Entity with the Mask component.

A Mask will be applied to all rendered Masked Sprites pointing to it. A Sprite can only be affected by a single Mask.
Pipeline implementation

Masked sprites add 2 additional specialized pipelines for with and without threshold values.
The mask texture and sampler form uniform group(2), optional uniforms (i.e. just threshold currently) form group(3). Adds SIXTEEN_BYTE_ALIGNMENT define to align uniforms when targeting WebGL2.
Masked sprites use an alternative vertex buffer that also includes the mask's affine transformation.
Sprite batches are now delineated by a change in either the Sprite Image or Mask.

Shader implementation

In the vertex shader, for each Masked vertex, calculate the effective Mask uv coordinates at that point. (If the vertex is not contained within the Mask bounds, the UVs will be outside of the 0 to 1 range and use the sampler's AddressMode.)
In the fragment shader, sample the mask texture with these UVs, taking the red value[^1]
If a threshold value is set, map this value to 0.0 if it is less than the threshold, otherwise 1.0.
Multiply the fragment output alpha by this value.

[^1]: To allow single-channel grayscale masks
Design concerns

Linking Masked to Mask with just an Entity is not great, but I don't know of anything better until kinded entities or relations are available? This also makes spawning a self-masking Entity awkward.
Supporting polygonal masks (discussed in #3357, #5180) in the future would be messy at best with this method.
Should the names for Mask and Masked be more specific? To differentiate from potential future UI or polygon-based masking?

Sampler AddressModes
Changing the AddressMode of the mask's sampler is useful to set masking state outside of the mask bounds, or to create a repeating mask. Currently, setting the sampler can't be be done as a part of Image loading, it must be done after loading is complete #6893. The recent asset loading changes could make this easy to allow with ImageLoaderSettings, if ImageSampler were serializable.
Note, AddressMode::ClampToBorder is not currently supported by WebGPU (gpuweb/gpuweb#1305), though it can be replicated with ClampToEdge and adding a slight border to the mask.

Changelog

Added the Mask and Masked components. Sprites with Masked components will be masked by the linked Mask entity.

Migration Guide

Added fields to ExtractedSprite, ExtractedSprites, SpritePipeline, SpriteMeta, SpriteBatch, and ImageBindGroups.

My first thought is that this should be implemented like alpha mask for 3D. But, if you want to do masking of transparent materials separate to its transparency, then a different method is needed indeed.

@colinjneville can you resolve merge conflicts? I'd like to wrangle review effort for 0.13


Product suggestion: Get extension usage statistics

Number of downloads and installations is certainly useful to know, but I'd also like to know how often my extensions are being implemented. Do users install but never use the extension? Or do they use the extension once and then stop using it without uninstalling it?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 902e2181-c7cf-b144-367e-2e0091c2b6f3
Version Independent ID: bed48ac7-63c7-5942-d59a-542fdd11343c
Content: Extension Report
Content Source: docs/marketplace/extension-report.md
Service: unspecified
GitHub Login: @douge
Microsoft Alias: elbatk

I find that Applications Insights does this pretty well
How to integrate application insights into your application
https://blogs.msdn.microsoft.com/visualstudioalmrangers/2017/05/30/how-to-integrate-application-insights-monitoring-in-your-team-services-extension/
How to setup application insights and get the instrumentation key.
https://docs.microsoft.com/en-us/azure/application-insights/app-insights-create-new-resource

More about application insights
https://docs.microsoft.com/en-us/azure/application-insights/app-insights-overview
Setting alerts in application insights - spike in exceptions, increase response times etc.
https://docs.microsoft.com/en-us/azure/application-insights/app-insights-alerts


[Bug]: From the Schema Database Table Creation window, you can go to the SQL window, and the data source displayed in the SQl window is the schema database

ODC version
4.3.2
OB version
no related
What happened?
From the Schema Database Table Creation window, you can go to the SQL window, and the data source displayed in the SQl window is the schema database

What did you expect to happen?
The schema does not support SQL windows
How can we reproduce it (as minimally and precisely as possible)?
In the Create Logical Table, click + on the SQL window to go to the SQL window
Anything else we need to know?
No response

Fixed In Commit c1469755bb913bc85ab7c9b46b43e454079713fd
------
畅晚
Fri Sep 20 18:48:17 2024 +0800

pass


update bosh release to allow for provisioning a service

We expect the blockhead bosh release to bring up a version of the service broker that can provision the blockhead service: https://github.com/cloudfoundry-incubator/blockhead-bosh-release

Finished with https://github.com/cloudfoundry-incubator/blockhead-bosh-release/pull/6


[BugFix] Fix fe follower restart wait after alter enable_persistent_index

…ndex
Why I'm doing:
What I'm doing:
Fixes #45207
What type of PR is this:

[X] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[x] Yes, this PR will result in a change in behavior.
[ ] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[X] 3.3
[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

@sduzh Can you help review this PR? Thank you very much!

It should have been fixed in #44597


STM32U5 uart with DMA transfer

Adaptation of the DMA driver of the stm32U5 to use with UART in async (DMA) mode.
The serial uart driver is changed to support the dma of the stm32U5.
Creates the configuration with overlay files for :

nucleo_u575zi_q nucleo (144) board
b_u585i_iot02a disco kit

to run tests/drivers/uart/uart_async_api.
The DMA of the stm32u5 is a GPDMA.
From the dma API, the suspend function is added to the dma_driver_api. This function is called by the uart driver when aborting the Tx.
Connect the Tx to Rx pins on the target platform (add the corresponding harness_config "fixture") to pass the test.
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/46326
Signed-off-by: Francois Ramu<EMAIL_ADDRESS>

After suspending the GPDMA channel for UART Tx, a delay is reuiqed (see dma_stm32_disable_stream )
One 1msec is compatible with nucleo_u575 and b_u585i_iot02a platforms.

Test execution tests/drivers/uart/uart_async_api/  with  the following platforms:

b_u585i_iot02a on  usart3   --> connect   D0 / D1 on CN14
nucleo_u575zi_q on usart2 --> connect D52 / D53 on CN9
or  nucleo_u575zi_q on usart 3  --> connect D45 / D46 on CN8 and overlay

&usart3 {
	pinctrl-0 = <&usart3_tx_pc10 &usart3_rx_pc11>;
	pinctrl-names = "default";
	current-speed = <115200>;
	status = "okay";

	dmas = <&gpdma1 0 29 0x440
		&gpdma1 1 28 0x480>;
	dma-names = "tx", "rx";
};

rebase on 6401682dd3092027e7c19039f3d46c893a9d413f
with CONFIG_DT_HAS_ST_STM32U5_DMA_ENABLED

rebase on 7ed6775d02bd54b77727a42c7695a37b66be24d6


Fix build failed in branch "static-link-argtable3"

argtable/argtable3 no longer provide the amalgamation source code from v3.1.0 (argtable3.c and argtable3.h)
https://github.com/argtable/argtable3/releases/tag/v3.1.0
They instead provide script "tools/build" to generate amalgamation source and header file.
https://github.com/argtable/argtable3#quick-start
I confirmed build succeeded. See https://travis-ci.org/unasuke/mruby-argtable/builds/518569222

Thanks, I love you!!!


Trouble tracking down self is not defined issue

Base repo (w/ issue referred to below): https://github.com/tsnieman/webpack2test/tree/road-to-isomorphism_pothole1
Note: isomorphic-webpack works in the same repo here... the _pothole1 branch is just for illustrating the issue below. That's the only difference between the two.
I've got isomorphic-webpack working on a basic level in this test repo, but I'm having issues tracking down an issue which presents itself as the error below.
ReferenceError: self is not defined
   at isomorphic-webpack:271:30
   at isomorphic-webpack:266:47
   at module.exports (isomorphic-webpack:288:68)
   at Object.<anonymous> (isomorphic-webpack:1150:36)
   at __webpack_require__ (isomorphic-webpack:26:30)
   at Object.defineProperty.value (isomorphic-webpack:867:68)
   at __webpack_require__ (isomorphic-webpack:26:30)
   at Object.defineProperty.value (isomorphic-webpack:920:64)
   at __webpack_require__ (isomorphic-webpack:26:30)
   at Object.defineProperty.value (isomorphic-webpack:734:70)

Which seems to happen when I try to use the Home page component in the Router. Digging further, I discovered that it really only throws the self is not defined error when I include the line import styles from './Home.css'; (implicit or named import, doesn't matter).
Not, my CSS loader situation is something like this:
// webpack config
      // CSS
      {
        test: /\.css$/,
        use: [
          'style-loader',
          {
            loader: 'css-loader',
            options: {
              modules: true,
              importLoaders: 2,
              localIdentName: '[path]__[name]__[local]__[hash:base64:5]',
            },
          },
          'postcss-loader', // options in postcss.config.js
        ],
      },

At this point, I'm pretty deep into this and not sure how to continue to debug from the original error message. Might be two issues here:

how do I debug more thoroughly from the given message? I'm using DEBUG=isomorphic-webpack but it mostly just mirrors what was spit out in the browser (original error at top).

my problem of "why does importing css cause this".

Any insight into either issue would be helpful @gajus / other contributors. Thank you very much.
If it would be helpful, I would be happy to strip my repo down even more (since I might end up doing this anyway), but hoping that I pointed out all the important parts.

@tsnieman Are you using the error handler https://github.com/gajus/isomorphic-webpack#isomorphic-webpack-handling-errors ?

@gajus Does formatErrorStack work anymore without the isomorphicMiddleware?

couldn't find much about middleware for this project anymore, but see it mentioned a lot in docs

I just tried adding formatErrorStack into my server code, but it didn't seem to output anything additional/different -- just the same self is not defined. Not sure if I am using this correctly either -- I'm using async/await + createCompilationPromise right now.

The change you did seems to be correct. It is supposed to replace isomorphic-webpack:288:68 with references to the real code thats causing the problem.

I was getting the same error and I upgraded the dependencies (especially the css-loader and style-loader, as pointed out in #20 that it's related to css/import) in both isomorphic-webpack and isomorphic-webpack-demo which solved it for me.

Sorry it was actually downgrading the dependencies that helped, not upgrading.
The error seems to be coming from here: https://github.com/webpack-contrib/style-loader/blob/master/addStyles.js#L14.
return /msie [6-9]\b/.test(self.navigator.userAgent.toLowerCase());

Replacing self with window makes it work.

I have left a comment with the original commit:

For the record, this broke change broke isomorphic-webpack. https://github.com/gajus/isomorphic-webpack/issues/20#issuecomment-287445277 Perhaps a window.self would have been a safer change?

– https://github.com/webpack-contrib/style-loader/commit/9dc45a6dee16553a64071031d18feb1562df86a2#commitcomment-21377913

@laggingreflex Fantastic find! Rolling back to<EMAIL_ADDRESS>fixed my issue! How in the world did you track that down? Impressive.
@gajus Thanks for commenting on the upstream issue.


[trivial] typo in README

Fix a trivial typo in README

this left me scratching my head too.

nit fixed

Thanks!
LGTM ✨


Popover offset

This PR fixes a few issues

In certain conditions the baseWidth was unable to be calculated, this resulted in 0px width dropdown items being rendered.
The @container queries within the tabs (and probably any other element) prevented a modal, that is initiated from within a GoATab component, from going full screen, but instead confined it to within the GoATabs boundries.
When using a Popover within a @container query, it was found that the calculated offset values should be 0, to get things to work. It was then found that using the zero values still worked for the non-relative popovers. So these calculations were removed.

Issue is verified for react and angular, for tabs, and dropsdowns in various conditions

:tada: This PR is included in version 1.17.0-alpha.23 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.17.0-alpha.19 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0-alpha.4 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Allow user to set no default IDE

Is your feature request related to a problem? Please describe.
I tend to use neovim via ssh. So I don't want to have VS Code or Jetbrains open after every create. Allow me to set a no-op default IDE.
Describe the solution you'd like
As it is now, I either pick an IDE I don't use or get an error on every create about no IDE set. Let me set a no-op IDE that does nothing on create.
Describe alternatives you've considered
Alternatively, let me configure / add a setting to make --skip-ide as the default behavior.

I would go the route of allowing --skip-ide as a default because a default IDE of none would be kind of weird. I would add an AlwaysSkipIde property to the CLI config that can be edited by the user. @idagelic thoughts?

I'm okay with "no IDE" option but maybe we should instead have a "Terminal SSH" option so it just automatically ssh-es into the ws for you? @metcalfc

Either works

/bounty $20

/bounty $20

Note for contributors: we are going with this option https://github.com/daytonaio/daytona/issues/252#issuecomment-2009087216

/attempt #252

@Tpuljak @idagelic The more I use this the more I think we're trying to do too many things here. Unix philosophy do one thing. I think we're doing it to try and make things better for the user but with fewer steps and its actually worse because its surprising.
I'm coming from using gh codespace create and I've built shell script automation around it. It creates and that's it. I can then connect with the gh codespace code command.
Instead of --skip-ide and IDE is the default, I think it should be the opposite. --connect should the flag to automatically connect to your default IDE. The "magic" we're trying to do here is nice for fewer commands to get started but makes using it regularly less good.
Similarly, we do the same with server start auto registering with systemd, thats not how these services typically work, its surprising, and it makes things more difficult to use in the long run. It makes it easier for the new user.

@metcalfc I understand what you're saying. I'm fine with --connect being a flag. I agree that the "UX optimization" might be unexpected for people. Also, if create doesn't open the IDE, it "forces" people to learn the code command which might improve UX even more.

@idagelic @vedranjukic thoughts?

Since we're not opening an IDE during creation, the --skip-ide flag isn't needed. I also agree on using the connect flag to establish the IDE connection.

I opened #315 for the --connect flag. This issue should tackle adding Terminal SSH as an IDE option.
@harkiratsm interested in making an attempt?

Yes, I'm up for the challenge!

Adding SSH Terminal as an option in the IDE, enabling users to open their workspace directly in the terminal.


Readme updates

I updated the instructions so that:
the publications.json partition is created from the RichContextMetadata repo and exported to this repo, so as not to muck up this repo with stuff other than the partitions themselves
changed the required fields to be only title and dataset, since we do have APIs that can get doi and url just from a title search (e.g. dimensions). LMK if this is ok. I note in the template publications_export_template.ipynb that if doi/url exist, they should be in the top level of the JSON - I will also communicate this verbally, and implement a unit test for it see below
Also updated the template publications_export_template.ipynb so that any other fields go into a lower level dict, original_metadata
I'll update the unit test to check for:

title and dataset
original_metadata - if exists, check that doesn't include doi or url and if it does have these fields, throw error message that those fields need to be moved to top level

A question:

If other fields like journal do exist i the linkages csv, should those be put at the top level?

updated .gitignore and nuked DS_Stores and checkpoints
updated related_datasets to datasets
updated template notebook with a note about including any other optional or required fields that may exist


helm3: Only update failed releases if the chart values or version has changed

Cherry pick of #422 and #425 into helm3 branch.

Going with a ping. CI failures are due to the tarball version. Will get that sorted tomorrow.


Changes and improvements

PR Checklist

[x] This PR introduces breaking changes and I have provided a detailed explanation below.

PR Type
What kind of change does this PR introduce?

[x] Breaking changes (bugfix or feature that introduces breaking changes)
[x] Refactoring (no functional changes)

Fixes
I borked https://github.com/lbryio/lbry-desktop/pull/2053 while attempting to have a sane rebase. This PR refactors the CSS and makes semantic changes in the rendered HTML.
What is the current behavior?
Nothing the average user would notice, aside from styling.
What is the new behavior?
New hotness. Sass is (more) organized and easier to manage. It still isn't perfect but it's close.

Moving to position: absolute is messing with this (and probably affects a few other places)

This uses card--space-between which was basically just display: flex; justify-content: space-between;

The exact search tile match is off.

Why the switch to cards for search? I think tiles make more sense if we want to display the description. It offers a lot more room.

Cards with no thumbnail don't have the same height as other cards.
Also the placeholders don't match up with the actual text.

The spacing under the title looks way to big. And the spacing between the two inputs should be increased.

I think we should have an default image for uploads without thumbnails. That'll make things easier for that issue.

Having a wholly different layout for search means it's yet another thing to maintain. It seemed easier to just keep it consistent. The description field has more content than expected though.

Having a wholly different layout for search means it's yet another thing to maintain. It seemed easier to just keep it consistent. The description field has more content than expected though.

It's not an entirely different layout. It's just a list of FileTile's, which is the same thing as the related content. Just scaled up

Okay, I'll look at the current look of that page in the app.

I can't seem to reply in the original thread but for https://github.com/lbryio/lbry-desktop/pull/2102#discussion-diff-232837723L43
The element__element1__element2 naming is not following BEM naming
https://en.bem.info/methodology/quick-start/#nesting-1

I realized that a while after I made the comment but wasn't able to find it.

Forgot another thing, the subscription button still moves down a bit when the heart icon is added/removed.

'media--search-result': isSearchResult is not working for channelTile. Not sure what needs to be done there.

What is messed up about this style?

'media--search-result': isSearchResult is not working for channelTile. Not sure what needs to be done there.

You have to pass in that value when you use it <ChannelTile ... isSearchResult />

What is messed up about this style?

General inconsistency compared to the rest of the app. There is no margin above the textarea/submit button.

The button under the textarea should have the same spacing as it would under a table (like transaction history) right? I think those are the same context.
Also the spacing seems really weird when there are cards with subtitles and without. The margin-bottom on the card-header class is causing inconsistent spacing. The space between the textarea and the subtitle on the top card is ~36 pixes, and the spacing between the top link and the title on the bottom card is ~42 pixels.


Create article_without_links.md

Fact-Checking Results

Claim: On Setember 12, 2023, CoinEx, a crypto trading platform operating on various chains, experienced a massive security breach due to a private key compromise. :x:

Source: [No credible sources found to verify the date or details of the alleged breach](No credible sources found to verify the date or details of the alleged breach)
Explanation: Unable to verify the accuracy of this claim from the information provided

Claim: The attacker exploited CoinEx's hot wallets and extracted approximately $20 million worth of assets across 9 different chains. :x:

Source: [No credible sources found](No credible sources found)
Explanation: Unable to verify details of the alleged theft across chains

Claim: Lazarus Group is suspected to be behind the theft, as multiple sources have confirmed an onchain connection between Stake.com, Atomic Wallet, and the CoinEx hacks. :x:

Source: [No credible sources found](No credible sources found)
Explanation: Unable to verify the attribution to Lazarus Group or connections between the hacks

Spell-Checking Results

Mistake: Setember

Correction: September
Context: On Setember 12, 2023

Hugo SSG Formatting Check

Does it match Hugo SSG formatting? :white_check_mark:

Filename Check

Correct Filename: 2023-09-12-coinex-security-breach.md
Your Filename: 2023-09-12-coinex-security-breach.md :white_check_mark:

Section Headers Check

Allowed Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes
Your Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes :white_check_mark:

Metadata Headers Check

Allowed Metadata Headers: date, target-entities, entity-types, attack-types, title, loss
Your Metadata Headers: date, target-entities, entity-types, attack-types, title :x:

/articlecheck

Fact-Checking Results

Claim: CoinEx lost $52,847,077 in total across the following chains: :x:

Source: https://cointelegraph.com/news/coinex-compromised-private-keys-behind-70-million-hack
Explanation: According to the source, CoinEx lost over $70 million, not $52 million.

Claim: Lazarus Group is suspected to be behind the theft :white_check_mark:

Source: https://cointelegraph.com/news/coinex-compromised-private-keys-behind-70-million-hack

Claim: Funds were drained from CoinEx's Ethereum hot wallet for 408,741 DAI :white_check_mark:

Source: https://etherscan.io/tx/0x9e8d4d98d815a1725031f7f5f92de42f999045bef70eedc64baf6c15ca230eaa

Spell-Checking Results

Mistake: Setember

Correction: September
Context: Setember 12, 2023

Hugo SSG Formatting Check

Does it match Hugo SSG formatting? :white_check_mark:

Filename Check

Correct Filename: 2023-09-12-CoinEx.md
Your Filename: article_without_links.md :x:

Section Headers Check

Allowed Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes
Your Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes :white_check_mark:

Metadata Headers Check

Allowed Metadata Headers: date, target-entities, entity-types, attack-types, title, loss
Your Metadata Headers: date, target-entities, entity-types, attack-types, title :x:

/duplecheck

/duplecheck

Fact-Checking Results

Claim: On September 12, 2023, CoinEx experienced a security breach resulting in around $20 million stolen :x:

Source: https://www.theblock.co/post/186396/coinex-confirms-hack-after-31-million-in-cryptocurrency-allegedly-stolen
Explanation: The article states $52 million were stolen, not $20 million

Claim: Lazarus Group is suspected to be behind the theft :white_check_mark:

Source: https://therecord.media/north-koreas-lazarus-group-suspected-in-31-million-coinex-heist/

Claim: CoinEx lost $52,847,077 in total across multiple chains :white_check_mark:

Source: https://therecord.media/coinex-confirms-hack-after-31-million-allegedly-stolen/

Spell-Checking Results
Hugo SSG Formatting Check

Does it match Hugo SSG formatting? :white_check_mark:

Filename Check

Correct Filename: 2023-09-12-CoinEx.md
Your Filename: article_without_links.md :x:

Section Headers Check

Allowed Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes
Your Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes :white_check_mark:

Metadata Headers Check

Allowed Metadata Headers: date, target-entities, entity-types, attack-types, title, loss
Your Metadata Headers: date, target-entities, entity-types, attack-types, title :x:

Fact-Checking Results

Claim: On Setember 12, 2023, CoinEx experienced a security breach :white_check_mark:

Source: https://therecord.media/coinex-confirms-hack-after-31-million-allegedly-stolen/

Claim: The attacker extracted approximately $20 million worth of assets across 9 different chains :x:

Source: https://therecord.media/coinex-confirms-hack-after-31-million-allegedly-stolen/
Explanation: Articles state $31 million was stolen across Ethereum, Tron and Polygon

Claim: Lazarus Group is suspected to be behind the theft :white_check_mark:

Source: https://thehackernews.com/2023/09/north-koreas-lazarus-group-suspected-in.html

Spell-Checking Results

Mistake: Setember

Correction: September
Context: On Setember 12, 2023,

Hugo SSG Formatting Check

Does it match Hugo SSG formatting? :white_check_mark:

Filename Check

Correct Filename: 2023-09-12-CoinEx.md
Your Filename: article_without_links.md :x:

Section Headers Check

Allowed Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes
Your Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes :white_check_mark:

Metadata Headers Check

Allowed Metadata Headers: date, target-entities, tags, entity-types, attack-types, title
Your Metadata Headers: date, target-entities, tags, entity-types, attack-types, title :white_check_mark:

Duplication checker
Is this a new article for Crypto wiki? :x:

/articlecheck

/articlecheck

Fact-Checking Results

Claim: On Setember 12, 2023, CoinEx experienced a security breach :white_check_mark:

Source: https://coinex.zendesk.com/hc/en-us/articles/8959479322783

Claim: CoinEx lost $52,847,077 across 9 different chains :white_check_mark:

Source: https://coinex.zendesk.com/hc/en-us/articles/8959479322783

Claim: Funds were drained from CoinEx's Ethereum hot wallet for 408,741 DAI :white_check_mark:

Source: https://etherscan.io/tx/0x9e8d4d98d815a1725031f7f5f92de42f999045bef70eedc64baf6c15ca230eaa

Spell-Checking Results

Mistake: Setember

Correction: September
Context: Setember 12, 2023

Hugo SSG Formatting Check

Does it match Hugo SSG formatting? :white_check_mark:

Filename Check

Correct Filename: 2023-09-12-coinex.md
Your Filename: article_without_links.md :x:

Section Headers Check

Allowed Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes
Your Headers: ## Summary, ## Attackers, ## Losses, ## Timeline, ## Security Failure Causes :white_check_mark:

Metadata Headers Check

Allowed Metadata Headers: date, target-entities, entity-types, attack-types, title, loss
Your Metadata Headers: date, target-entities, tags, entity-types, attack-types, title, loss :white_check_mark:


KAFKA-13049: Name the threads used for log recovery

See KAFKA-13049

The test failures are unrelated.
@chia7712 would you be able to review?

Will merge on green CI.

Test failures are unrelated.


Render date picker within custom container

I am trying to use the date range picker in my app and want a few more buttons within the calendar modal - I want a close button, an OK button and a clear button. I am happy to implement the functionality of these within my app but can't see a way to get these inside the date picker component?
So I wanted to do something like:

                 <Button icon={CrossIcon} onClick={onCancel} />
                 <DateRangePicker { ...datePickerProps } />

                   <Button info text="Clear" onClick={this.onClearDates} />
                   <Button primary text="OK" onClick={this.onConfirmDates} />

and have the date picker render within my component... Is there any way of achieving this?

If you want to add buttons below the calendars, try passing them via renderCalendarInfo
<DatePicker
  ...
  renderCalendarInfo={(props) => {
    return (

        cancel
        accept

    )
  }}
/>

And style it to look something like

Nicotroia's mention helped me in added many buttons like "Last 7 Days", "Last Month" and others. But, here I noticed an issue. Once the button, for example, "Last 7 Days" is clicked, the Date Range is being highlighted and dates are also backfilled, but the calendar is not closed. Can someone please suggest how do I achieve this functionality of closing the calendar on clicking these custom buttons?

If you want to add buttons below the calendars, try passing them via renderCalendarInfo
<DateRangePicker
  ...
  renderCalendarInfo={(props) => {
    return (

Apply

    )
  }}
/>

And style it to look something like

Nicotroia's mention helped me in added many buttons like "Last 7 Days", "Last Month" and others. But, here I noticed an issue. Once the button, for example, "Last 7 Days" is clicked, the Date Range is being highlighted and dates are also backfilled, but the calendar is not closed. Can someone please suggest how do I achieve this functionality of closing the calendar on clicking these custom buttons?

In my use case, I need to have both a left pannel, and a bottom pannel.
The problem is there is only one prop renderCalendarInfo for rendering, and another prop calendarInfoPosition to choose where to display the compent.


How to cite?

How to cite PyMOLProbity?

@rafaeltiveron Thanks for asking. I hadn't really considered this previously, but just saw that GitHub has established a method for creating DOIs for specific releases of the software through Zenodo.  I'll put together citation instructions and create a new release, which should then produce a citable DOI for all future releases.

I have added citation info to README.md.  I also set up the Zenodo DOI webhook, so a new DOI is generated for each release.  Hopefully that's enough for you to move forward, so I'll close the issue.  If there's anything else you need, please let me know.

Thank you


Config fetch

Extract all required configuration values in a single JVM run thus speeding up the launch process.

PTAL


⚠ Nebulance has degraded performance

In 925fa70, Nebulance ($NBL) experienced degraded performance:

HTTP code: 200
Response time: 2038 ms

Resolved: Nebulance performance has improved in 7109211.


How to extract text from wikipedia URL

Hello
From the README file, I can see that wikiclass.score will give a score for a string. But for wikipedia, usually we work with Wikipedia article through URL. How can I extract the text through Wikipedia URLs, or even better, get a bunch of articles from Wikipedia to score them automatically?

Oh I found the dataset at http://figshare.com/articles/English_Wikipedia_Quality_Asssessment_Dataset/1375406
It looks great, thank you very much


Organization

I've searched existing issues and couldn't find a duplicate.

[X] I confirm this is not a duplicate.

Operating System
Arch linux
Server Software Version/Commit
latest
Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
What about creating organization? because the project is getting bigger and more people are working on itю

I don't think there is a need for an Organization, Some people already asked me, But i don't really see the Point.

Currently i see no problems and i like how it is


Loc Automation - partial handback for Branch: ResxAC1035

Loc Automation - partial handback for Branch: ResxAC1035

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

Line 111: [Error] W:\hq54-s\jobs\100\Pages\Pricing\docfx.json for docset Pricing doesn't exist

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Curve leverage lending bot new bot N00B version

Leverage lending bot FE needs the following changes per user feedback on Palomabot and Curvebot - (Note this will have a new vyper contract and backend)

Change "crvUSD Borrow Token" to "The amount of crvUSD token you are borrowing for leverage"
Please add the token that is being levered. The tokens that can be leveraged are the tokens that can be used as collateral for the loans on the https://crvusd.curve.fi/#/ethereum/markets site. As such, this list must be a dynamic drop-down and the user must be able to choose.
Do not swap the token if the collateral token used is one of the collateral tokens allowed by Curve
Change "Deleverage Percentage" to "Repay Loan Percentage"
Remove N slider and make Leverage a Slider that always selects the Max Borrow at a 13% Health Rate. This Leverage is the new slider.
Change " Collateral Token" to "Deposit Token" The collateral is ETH

@wc117 do we have to make any Vyper contract changes so that we may use ANY collateral in https://crvusd.curve.fi/#/ethereum/markets?

@taariq @fieldtheory123 if a user deposits a non-supported token, do we default to ETH as collateral?

@verabehr no. The user chooses the collateral and we swap into that collateral. They must choose what they want to leverage against. We don't want to make that choice for them if Curve allows multiple collateral options.

This was a comment from a user I called and who walked through the app.

Just to confirm: Item 5. will not change in the current bot but in the Degen Leverage Bot, right?

@joycehermosilla I'm creating a new ticket for teh degen bot. Only 6 applies to the current Degen bot - cc @jamie088

Looks great! Let's GO!

@fieldtheory123 I don't understand about this: 5. Remove N slider and make Leverage a Slider that always selects the Max Borrow at a 13% Health Rate. This Leverage is the new slider.
My understanding is Health is fixed as 13% and the user can select the Leverage value from Slider. Then we should calculate the Max Borrow amount from Leverage and Health rate. Right?
But if so, I can't do it. Because the curve-js library doesn't support that functionality.

@jamie088 I suppose currently you are calling curve-js' functions to derive health from N and leverage? Can you look at the details of the function and find the formula? If so, you can use that formula and reverse engineer to calculate N from leverage and health.

@joycehermosilla & @jamie088: We are going to make a change:

The user will only use the slider to select their Leverage
The user will not enter in their crvUSD Borrow Token This number will always be calculated as 7% Less the MAX crvUSD possible so that the user will never enter this number. It will always be calculated based on the N chosen.
We will need the UI to change to show this so that the user understands the max leverage is available for each N.

@joycehermosilla & @jamie088: We are going to make a change:

Each Collateral Token will be its own bot. The user no longer chooses Collateral Token.
The user will only use the slider to select their Leverage
The user will not enter in their crvUSD Borrow Token This number will always be calculated as 15% Less the MAX crvUSD possible so that the user will never enter this number. It will always be calculated based on the N chosen.
Thus, the user's MAX crvUSD = 85% of available
N becomes a slider and we remove Bands. The Slider is from LEFT to RIGHT OR LOW TO HIGH. Thus N=50 will start left and N=4 to the right, but the user never sees "bands" concept. They just use the slider
Input default health repayment levels is 50% of the health at the chosen leverage. User can update this
% to repay will be default 50%. User can update this.

@taariq My question for your requirements.

If the user no longer chooses Collateral Token in UI, which token should be set to as a Collateral Token?
Then, the UI has two sliders like leverage and N. Right?

@jamie088:

Each collateral token will have its own Bot Front-end for Leverage. @joycehermosilla will prepare 5 front-end designs featuring the tokens for each bot
The UI has only 1 SLIDER. That Slider is for leverage. It will be the N slider, but in the reverse direction. The user won't see bands. We'll just do 50(Left/Minimum Leverage) to 4(Right/Max Leverage)

https://www.figma.com/file/6DYR6QFkucGd1bsOILr7V0/Paloma-Bot?type=design&node-id=1653-464200&mode=design&t=mJDEjEDCkufA7tc6-4

Metamask error:
(anonymous) @ lockdown-install.js:1
Show 1 more frame
Show less
lockdown-install.js:1 null
(anonymous) @ lockdown-install.js:1

Change: Borrow Rate --> Loan interest rate


P4RT-1.1 - added priority field to expected table entity

Since we are adding Priority while writing table entries, the test is failing because of the missing priority:1 in the expected entity. Added priority to the expected entity inside p4rtutils.ACLWbbIngressTableEntryGet function calls.
Read table.Entity:  &{table_id:33554691 match:<field_id:3 ternary:<value:"`\007" mask:"\377\377" > > action:<action:<action_id:16777480 > > priority:1 }
Expected.Entity:  &{table_id:33554691 match:<field_id:3 ternary:<value:"`\007" mask:"\377\377" > > action:<action:<action_id:16777480 > > }

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 46.888%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
580

Relevant Lines:
1237

💛  - Coveralls

logs:
=== RUN   TestP4rtConnect
    base_p4rt_test.go:306:
        *** Fetching P4RT client for DUT...

    base_p4rt_test.go:311:
        *** Fetching P4RT client for DUT...

Sending SetForwardingPipelineConfig for both clients
P4info matches fine for client 0
P4info matches fine for client 1
    base_p4rt_test.go:362: RPC Write Success for client 0
    base_p4rt_test.go:362: RPC Write Success for client 1
    base_p4rt_test.go:385: Read Response success
    base_p4rt_test.go:387: Verify Read response for client0
Table match succesful
Table match succesful
Table match succesful
    base_p4rt_test.go:385: Read Response success
    base_p4rt_test.go:387: Verify Read response for client1
Table match succesful
Table match succesful
Table match succesful
--- PASS: TestP4rtConnect (29.16s)
PASS

*** Releasing the testbed...

*** PROPERTY: time.begin -><PHONE_NUMBER>
*** PROPERTY: time.end -><PHONE_NUMBER>
ok  	github.com/openconfig/featureprofiles/feature/experimental/p4rt/ate_tests/base_p4rt	172.906s

Hi @vosipchu , Could you take a look at this PR. This fixed the issue in code committed via https://github.com/openconfig/featureprofiles/pull/586.

/gcbrun


gio: backport AsyncInitable

This includes an updated gir version to properly generate unsafe async bindings.

Please first backport your gir change to the 0.15 branch of gir (and maybe more things if there are more things that are useful to backport and don't change APIs), and then regenerate with that here

Okay, as far as I can see there are no breaking changes on master, so I backported everything: https://github.com/gtk-rs/gir/pull/1329