Convenience exec/query overloads that do parameterized SQL

...using prepared statements behind-the scenes.
Ie:
conn.query("SELECT * FROM mytable WHERE id=? AND name=?", 7, "Frank")

One other simple possibility is to expand the query and exec methods of PreparedImpl to allow one-line execution of sequences.
For example:
auto prep = conn.query("SELECT * FROM mytable WHERE id=? AND name=?");
foreach(r; prep.query(7, "Frank")) { ... }

If you do go for the one liner, one thing that the current implementation makes a bit cumbersome is that you have to store the Prepared somewhere while you iterate, or it will try to purge the result and release the prepared statement (this is how I came across #117). The way I solved it is to create a wrapper struct that holds both the Prepared struct and the ResultRange, and I alias this the range. Of course, if you mitigate that in ways that we discussed in that issue, it may make things much nicer.

Added in branch "v2.1.x" via 7a8fc46c37f54472d46872bab630ff256504fb62, e793af7aad87769e02d8a788a5e50b189192ec7c, and 35cddc8b46a46f202e89128240ef06ff0d7b161b

Nice. I may be able to just about eliminate my templates that do this :)

I have to come back here to say, was able to trim out ALL of my cruft in my DB wrapper. Things in mysql-native are looking awesome!

I no longer need Refcounted wrapper structs
I no longer need these convenience wrappers (I simply had to rename my fetch calls to query, and things worked seamlessly, and I had already named my non-data-returning function exec, so no changes needed there).
I no longer have extra scopes to ensure ref counting does the "right thing". Things just work.

I was able to delete probably about 130 lines of code from my project that just dealt with wrapping and lifetime. Kudos!


Module docs expect an @docs declaration to be last

From the mailing list, a bug involving parsing module documentation. If any text follows the last @docs line, the compiler rejects the documentation, claiming it does not document functions that are in fact documented.
Minimal example to reproduce:
module WebAudio where

{-|
@docs AudioContext
THIS LINE CAUSES THE PROBLEM - remove it to see for yourself.
-}

{-| Some docs here.
-}
type AudioContext = AudioContext | DefaultContext

This will compile fine, until you list "WebAudio" as an exposed module in elm-package.json. Then you get this error:
## ERRORS in webaudio.elm ######################################################

-- MISSING DOCUMENTATION ------------------------------------------ webaudio.elm

Your module exports `AudioContext` but it is not in the module documentation.

3|>{-|
4|>@docs AudioContext
5|>THIS LINE CAUSES THE PROBLEM - remove it to see for yourself.
6|>-}

It needs to be listed in the module documentation.
Learn how at <http://package.elm-lang.org/help/documentation-format>

As you can see on line 4, AudioContext is indeed documented. Removing line 5, as claimed, causes a correct compilation. This strongly appears to be undesired behavior.

Probably a bug in this code, seems like it could be a simple PR.

My Haskell isn't that great, but just from studying the code it appears to be correct. Someone else feel free to take it.

We should enumerate the issues @evancz identifies as low-hanging fruit within Elm Plans for would-be contributors? Even gamify it by mentioning their closed issue #s in the release notes.

I'd be up for that.

Rad. Piping in on the Roadmap is on my todo. I want to try re-export first.

Don't try re-export. Adding language features needs more review than fixing stuff like this.

try using union of unions to work around other Max's concern

I would love to have this fix cherry-picked for Elm 0.15.1, I think I might be running into this issue while trying to update Elm.Html.Shorthand at the moment

Can you work around it by moving things around a bit? Sounds like the docs can be shuffled to work?

Actually, I quickly did the compile via Elm 15.0 instead, so that's ok! I can continue publishing it via 15.0 for now.


Enhance ImageStacks module

Add progress reporting for long loads
Allow interrupt loading (the load button turns into a cancel button during loading)
Add support for .jp2 file format (do not search for number in file extension, load the image using ImageStacks by default)

Thanks Andras!


Add link for reserved namespace error during package upload

Summary of the changes (in less than 80 characters):
Add link to message when there is conflict of namespace during uploading package
After changes:

Addresses https://github.com/NuGet/NuGetGallery/issues/8397

I recommend including the link as part of the statement, something like:
... or re-upload the package with a different ID. Click here to learn more about the Package ID prefix reservation.

Here's an interesting perspective on using "here" for link text: https://www.smashingmagazine.com/2012/06/links-should-never-say-click-here/
I don't think it's a huge deal but perhaps we can consider a wording that avoids the focus on mouse mechanics. Users can navigate using keyboard -- no "click" per se or "tap" on their phone.

Can we say (with the full text as link):
"Learn more about Package Prefix Id reservation"


user edit panel in cross site scripting vulenrabiltiy

Hello Development Team,
When I was a security researcher and student, I wanted to discover and report "XSS" vulnerability.
Version : Pagekit 1.0.14
Vuln url address : https://demos5.softaculous.com/Pagekit/admin/user/edit?id=1
Screenshot :

Payload : "><img src=x onerror=alert('ismailtasdelen')>
Thanks

I would assume it's a dupe of #814
There it is also explained how security issues should be reported.

Thanks for the came back :+1:


added word of the day extension

whenever user clicks on this extension it gives a random word and its meaning

https://user-images.githubusercontent.com/75252077/152735363-9d5d21eb-bfff-4fc4-96f4-7ee9bfe7c9e2.mp4

Hey @mnnkhndlwl good job, can you increase the width of the extension. Also, add a background and a button which when clicked will generate a random word & meaning

@harshita214 done
https://user-images.githubusercontent.com/75252077/152746087-2dc44abe-ec3c-4277-8c09-12ab6506463a.mp4

Awesome work @mnnkhndlwl 👏
merging the PR 🚀
Thanks for contributing 💛

@harshita214  can you add JWOC and medium labels in it because our scores will be counted by the labels in pull requests

Done! Sorry for confusion


make predictors check actual contents of pMHCs and not just lengths

This change is

Coverage decreased (-0.4%) to 82.02% when pulling 7533b08c52d0e240b3af3e19d892e9f690a5794b on check-pMHCs-not-just-counts into 4b1e230d8a74308763f1570c199152690f0b0483 on master.

@ihodes FYI, I added some extra logic to check specific failure cases for peptide sequences

Coverage decreased (-0.6%) to 81.851% when pulling 1acf3c7317025a025ec7c94e7213a332990395eb on check-pMHCs-not-just-counts into 4b1e230d8a74308763f1570c199152690f0b0483 on master.


Edit machine-learning-r-csharp-forecasting-exponential-smoothing.md

Edit complete.
Line 89 includes a reference to the ARIMA forecasting model. Please confirm that this reference is accurate, even through the topic focuses on the Exponential Smoothing model.

Hi @ShawnJackson, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

I just checked the document and it looks likes it should be ETS model instead of ARIMA in this document.


Training with custom data

Hi, could I know if there is an instructions on training with in-house private data? Currently, my data is under structure:
dataset
-images
-volume1
...
-masks
-volume1
if there any easy way to get start? Also I noticed in the training command line, the data=[base/with-morse/mega], how to modify this if the data is from somewhere else? Thanks!

The data configuration files are here: https://github.com/hkchengrex/Cutie/blob/main/cutie/config/data/base.yaml and https://github.com/hkchengrex/Cutie/blob/main/cutie/config/data/datasets.yaml
The data loading part is set up here: https://github.com/hkchengrex/Cutie/blob/main/cutie/dataset/setup_training_data.py and https://github.com/hkchengrex/Cutie/blob/main/cutie/dataset/vos_dataset.py


[Gem] Fix making executables executable on 1.8

\c @indirect

lol I wrote this code on the plane at the same time

Since my commit uses the Pathname instance rather than to_sing it, I'll keep mine. Thanks for fixing this though!


User defined EKS security groups are configured as the only node group security groups, versus being appended to the cluster default security group

Rancher Server Setup

Rancher version: 2.6.5
Installation option (Docker install/Helm Chart):

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc):

Proxy/Cert Details:

Information about the Cluster

Kubernetes version:
Cluster Type (Local/Downstream): Downstream Cluster EKS v1.21.12-eks-a64ea69

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider):

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)

If custom, define the set of permissions:

Describe the bug

The change introduced to the EKS operator in Rancher v2.6.4 (https://github.com/rancher/eks-operator/commit/c91df2d6f32c8feb5661a45216a37904d6b8efa5) to resolve https://github.com/rancher/rancher/issues/34749 configures the security groups for the node group launch template (in the instance the user does not provide a custom launch template) to the user-defined set, versus appending them to the list of security groups alongside the cluster default security group. The UI describes the optional user-defined security groups as follows "EKS creates a security group for your cluster by default. You may choose additional security groups that will be applied to EKS instances alongside the default security group created by EKS".
Business impact:
Breaks EKS cluster communication where a user defines additional security groups to grant some additional inbound/outbound rules besides the cluster default.
To Reproduce

Provision a Rancher v2.6.5 instance (I used github.com/superseb/tf-do-rancher2)
Provision an EKS cluster, defining a custom security group for the cluster, and without specifying a custom launch template
Observe that only the custom security group is set on node group instances, which are missing the cluster default security group
Result
User-defined security groups are the only security groups for node groups (where user does not define custom launch template)
Expected Result

User-defined security groups appended to cluster default security group for node groups (where user does not define custom launch template)
SURE-4790

Testing template
Root cause
This issue is a regression when an EKS cluster is provisioned via the rancher UI, the default security group is not appended to the node group when a launch template is not specified.
What was fixed, or what changes have occurred
When an EKS cluster is provisioned through rancher, after the cluster is done creating the eks operator adds the default vpc security group generated by AWS here https://github.com/rancher/eks-operator/blob/012d292592a0141b21e9b0cffac1a46360eea5f8/controller/eks-cluster-config-handler.go#L1181, creates a new launch template version for each node group in the cluster, and applies the new launch templates(s). The config.Status is updated with the new list of security groups.
My solution here is to create a new launch template version and apply it to the EC2 nodes after the cluster is finished creating. EKS does not generate the default security group until after the cluster finishes creating. Specifically in eks operator, we now add a bool addDefaultSecurityGroup to mark that it needs to be added to the node group, update the config.Status with the vpc default security group included, create a new launch template version and apply it to the nodes.
Functionality notes
The security group update takes some time, so when you provision an EKS cluster with no launch template specified, the update will take an extra 5-10 mins on top of provisioning. I usually see 2 nodes clusters become fully active in Rancher after about 25 mins. That time bump is due to EKS creating a new launch template, deleting the old one, and recycling the nodes in the node group to use the new launch template.
Sometimes, the cloud provider is slow to update the cluster and config.Status.SecurityGroups doesn't get updated until after a few syncs of the operator. This results in 2-3 new launch template versions getting created before the update completes. The old ones are immediately cleaned up by rancher, so @rmweir have agreed this is fine as long as EKS is not getting overloaded with template objects.
Areas or cases that should be tested
What areas could experience regressions ?
Are the repro steps accurate/minimal ?

Ticket #38014 - Test Results
With Docker on a single-node instance:
Reproduced on rancher v2.6.6:

Fresh install of rancher v2.6.6
Provision a downstream EKS cluster via the rancher UI - [Specify 2 vpc subnets + custom security group; no launch template]
Reproduced - EKS Cluster instance shows default + custom sg; Node instances show custom sg only;

Screenshots:
Cluster Instance

Node 1

Node 2

Veri-FAILED on rancher v2.6-1134cad32243dc8c60812517d370690c754d05c9-head:

Fresh install of rancher v2.6-head
Provision a downstream EKS cluster via the rancher UI - [Specify 2 vpc subnets + custom security group; no launch template]
Verified - EKS Cluster instance and Node instances show default + custom sg;
Provision a downstream EKS cluster via the rancher UI - [Specify 2 vpc subnets + custom security group; with launch template]
Veri-FAILED - EKS Cluster instance and Node instances show default + custom sg;

Screenshots:
Step 3 - No template - Cluster Instance

Step 3 - No template - Node 1

Step 3 - No template - Node 2

Step 4 - Template

Step 5 - w/ template -Cluster Instance

Step 5 - w/ template - Node 1

Step 5 - w/ template - Node 2

@Josh-Diamond This test case can be disregarded
Provision a downstream EKS cluster via the rancher UI - [Specify 2 vpc subnets + custom security group; with launch template]

Team needs to discuss the expected behavior for that case. The default security group may not need to be added to the node instances in the case of a custom launch template being specified in rancher. Otherwise, the regression is fixed and this ticket can be closed

Reopened, @Josh-Diamond to provide additional information on why it's going to be reopened.
We want to roll back the changes and not have the current fix in 2.6.7 yet.

Re-opened due to fix being the root cause of unexpected behavior seen with EKS clusters.
Upon further testing, it was determined that this fix causes all provisioned EKS clusters to do a rolling update, which is not desired behavior.
When provisioning a 3-node EKS cluster from Rancher UI, the cluster takes just over 30m to come up active.
From AWS Console, you can observe 3 nodes come up active.  Then nodes are scaled to 6, then back down to 3.  Once nodes scale back down to 3 and are active, the cluster will come up active in Rancher UI

Can be validated on the latest v2.6-head

Ticket #38014 - Test Results [cont.]
With HA Helm:
Verified on rancher v2.6.6 => v2.6-c47178eb1457a7ff1aac135c86d3627dc971b704-head:

Fresh install of rancher v2.6.6
Provision a downstream EKS cluster w/ k8s v1.21
Once Active, upgrade rancher server from v2.6.6 => v2.6-head
Verified - Cluster does not go into Updating state; no rolling update triggered
Verified - Rancher eks operator version is rancher/eks-operator:v1.1.4-rc4
Provision a new downstream EKS cluster w/ k8s 1.22
Verified - Cluster provisions in roughly 13m; no rolling updates are triggered in AWS Console

Screenshot:
Step 5

@annablender to investigate if there is any other way to fix the issue that will not trigger much slower initial provisioning and ideally not trigger rolling updates on upgrade (not sure if it's possible).

I have an alternate solution for the fix that I discussed with @phillipsj that will fix the provisioning time bump on both creation and upgrade. Needs design discussion.

Design discussion complete.
Discussion summary
Fixing the issue of slower initial provisioning to add the EKS default security group to the launch template is moot, because that is not the expected behavior. The original PR https://github.com/rancher/eks-operator/pull/60 changed this behavior and will be reverted.
We want how rancher handles security groups in EKS to have parity with vanilla EKS. EKS will only add the default security group to node instances unless there are security group(s) on the launch template, in which case those security group(s) replace the default on the nodes. Rancher will not add custom security groups to the launch template; any security groups defined by the user in the rancher UI will only be added at cluster level.

Test Results
Results

[x] ablender-eks-sg-ltwithnosg (donnie-test-lt): default and user sg on cluster level, default sg on nodes
[x] ablender-eks-sg-nolt: default and user sg on cluster level, default sg on nodes
[x] ablender-eks-nosg-ltwithnosg: default sg on cluster level and nodes
[x] ablender-eks-nosg-nolt: default sg on cluster level and nodes
[ ] ablender-eks-nosg-ltwithsg (hgalal-mc-demo): (note: having a custom user sg doesn't matter here. We're testing that if an LT passed to EKS contains a sg, that sg will replace the default on the nodes. User sgs in rancher are not adding to the LT) - PENDING

I ran into several EKS errors while verifying sg behavior on v2.6.7. If QA runs into errors testing this, please reach out to me. I will know how to resolve/workaround it.

Test Plan:
Verify on v2.6-head:

Provision a downstream EKS cluster via the rancher UI - [use donnie-test-lt ]
Verify default + user sg on cluster level; default sg on nodes
Provision a downstream EKS cluster via the rancher UI - [sg w/ no launch template]
Verify default + user sg on cluster level; default sg on nodes
Provision a downstream EKS cluster via the rancher UI - [no sg w/ launch template w/ no sg]
Verify default sg on cluster level and nodes
Provision a downstream EKS cluster via the rancher UI - [no sg w/ no launch template]
Verify default sg on cluster level and nodes
Provision a downstream EKS cluster via the rancher UI - [use hgalal-mc-demo ]
Verify sg specified in template replace default sg on nodes; user sg's in rancher are not added to LT

Verify upgrade from v2.6.6 => v2.6-head:

Provision a downstream EKS cluster via the rancher UI - [use donnie-test-lt ]
Verify default + user sg on cluster level; default sg on nodes
Provision a downstream EKS cluster via the rancher UI - [sg w/ no launch template]
Verify default + user sg on cluster level; default sg on nodes
Provision a downstream EKS cluster via the rancher UI - [no sg w/ launch template w/ no sg]
Verify default sg on cluster level and nodes
Provision a downstream EKS cluster via the rancher UI - [no sg w/ no launch template]
Verify default sg on cluster level and nodes
Provision a downstream EKS cluster via the rancher UI - [use hgalal-mc-demo ]
Verify sg specified in template replace default sg on nodes; user sg's in rancher are not added to LT

Verify upgrade from v2.6.5 => v2.6-head:

Provision a downstream EKS cluster via the rancher UI - [use donnie-test-lt ]
Verify default + user sg on cluster level; default sg on nodes
Provision a downstream EKS cluster via the rancher UI - [sg w/ no launch template]
Verify default + user sg on cluster level; default sg on nodes
Provision a downstream EKS cluster via the rancher UI - [no sg w/ launch template w/ no sg]
Verify default sg on cluster level and nodes
Provision a downstream EKS cluster via the rancher UI - [no sg w/ no launch template]
Verify default sg on cluster level and nodes
Provision a downstream EKS cluster via the rancher UI - [use hgalal-mc-demo ]
Verify sg specified in template replace default sg on nodes; user sg's in rancher are not added to LT

Advising @Josh-Diamond on updating step 9-10

Updated Test plan around offline info provided by @annablender

Ticket #38014 - Test Results
With Docker on a single-node instance:
Verified on rancher v2.6-c54b655dfab4838063758278664f7437fa0a2dac-head:

Fresh install of rancher v2.6-head
As admin, create a standard user
As standard user, provision a downstream 2-node EKS cluster w/ sg defined + LT w/ no sgs used
Verified - SG description updated + accurate
Verified - Default sg + User sg on cluster level; Default sg on nodes
As standard user, provision a downstream 2-node EKS cluster w/ sg defined + no LT used
Verified - Default sg + User sg on cluster level; Default sg on nodes
As standard user, provision a downstream 2-node EKS cluster w/ no sg defined + LT w/ no sgs used
Verified - Default sg on cluster level; Default sg on nodes
As standard user, provision a downstream 2-node EKS cluster w/ no sg defined + LT w/ sgs used
Verified - sg from LT overwrites default sg on nodes

Screenshot:
Step 4

Upgrade verified on rancher v2.6.5 => v2.6-633f5aadaf0768f85f7ada74888f8392d374a394-head:

Fresh install of rancher v2.6.5
As admin, create a standard user
As standard user, provision a downstream 2-node EKS cluster w/ sg defined + LT w/ no sgs used
Verified - Default sg + User sg on cluster level; Default sg on nodes
Upgrade rancher to v2.6-head
Verified - No rolling update; expected behavior


feat(api-key-service): add update, delete, list, verify endpoints

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#256  👈
#255
#230
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @jakim929 and the rest of your teammates on  Graphite


Label By Lines, Default Phone Validations

Tweaked two things, label flavor text + phone number validations
I added a labelByLine for content nodes so you can do small descriptions under the input label. I did this because often there's places where you want to provide some extra flavor text, but you don't want to break out labels as their own content node, because that makes the required * UI less obvious. Anyways, so now we can do that.

Label By Line Example

Also tweaked some things w/ phone numbers because they were allowed to be a in a weird state where the UI input differed from the actual state machine value until they were considered valid (which wasn't obvious)

Passed through invalidation boolean, so we can style the inputs when failing like other inputs (https://github.com/xstate-wizards/xstate-wizards/pull/65)
Always passing up the phone number to the onChange handler, because invalidation wasn't causing the bad value to propagate up. So your input UI would differ from what was on the machine state.
The whole point of this phone number input is to do a good but still naive check that the phone number entered is valid. So instead of requiring someone to make a validation function, the component passes a validation message to the inputOnChange handler for content nodes.

Default Phone Validation
Passing Phone Validation
Failing Validation after Changing Country Code

I've also extend the recent change for allowCountryCode. I saw we didn't publish that yet, so I wanted to make the label more explicit since the input is always going to have a country code (so we're never allowing/disallowing really). So I renamed the prop to allowSelectingCountryCode. I've also added a defaultCountryCode property, so someone can set the default to other countries, whether its selectable or not.

Example w/ Selectable Country code, defaulted to UK
Example with validation failing, no selectable country code, using US as default

In doing this, I forgot I had to link example projects to yalc lol so I updated the package script so that happens after you link the packages.

Bumped the package for use while waitin for review. Can tweak/repush if needed

Probably should have done the cascading merges in reverse but alas


Highlighting of invalid branch names

Now while we edit machete file branches that are not present in repository are underlined

(changed the PR title to make it less ambigous - that the branch names are invalid and should be highlighted, not that highlighting itself was invalid/broken and needed a fix)


Publish on the asset library.

Publishing to the asset library?

I wanted to wait for the initial bugs, because I only tested the Linux Debug and this is my first addon. So tysm for testing right now :). I think I'll release it to the asset library at the end of the week.

I'll put this on hold after all. I won't have time/no access to my computer to continue working on this for a few weeks and I don't want to publish something that can crash so easily.

Ah, let me know when you’ll be back, in the meantime, I’ll try converting it back into a godot C++ module.

Ah, let me know when you’ll be back, in the meantime, I’ll try converting it back into a godot C++ module.

in ~2-3 weeks from now so not that long
Port to a module will be very useful for more access in debugging and a better importer, so good luck with that if you have the time. Never did more than look at modules so no idea how well GDExtensions transfers to modules, my guess is mostly include paths and some special virtual GDExtension stuff would need to be changed/removed.

I think we're ok for wider tests!

I think we're ok for wider tests!

🥳, thought so as well. I actually already opened a submission a few days ago but that one broke with beta 3. I'll create a new release 0.3.1 later after testing a bit more and update that submission then :)

Let me know if you submitted.

Let me know if you submitted.

Updated it!

🎉 Released to the asset lib https://godotengine.org/asset-library/asset/1488 🎉
I'll add a link to it on the info tab :)


Event handlers should receive two parameters

Event handlers should aways receive the sender of the event as an object and arguments of the event as a subclass of EventArgs. This is currently not the case.
Event handler registration:
var scanner = new ZXingScannerView();
scanner.OnScanResult += MyHandler;

The handler itself:
void MyHandler(object sender, ScanResultEventArgs eventArgs)
{

}

At the moment, the handler only receives a custom object with the result inside.

Samuel is correct:
https://msdn.microsoft.com/de-de/library/system.eventhandler(v=vs.110).aspx
According to MSDN

This method's first parameter is of type Object and refers to the instance that raises the event. Its second parameter is derived from type EventArgs and holds the event data.

While this is true, making this change right now will break API.   Moving this to a major release milestone for now.

Thanks for reporting this issue!  Unforunately it took me way too long to respond 😭.  Sorry, I apologize!  Recently the source code for this project was completely refactored to modernize it.  Many PR's were included in this effort, and many bugs were hopefully fixed.  Please try out the latest 3.x series of NuGet packages (currently in prerelease).  To try and make the project more maintainable in my spare time going forward, I've decided to close all existing issues to start with a clean slate.  If you're still experiencing this issue on the newest version, please open a new issue with as much detail as possible.  Thank you for your patience and understanding!  Happy scanning!


Roll 50 - keyCode not working in DDC

@terrylucas @vsmenon
The keyCode accessor is no longer working in DDC. It seems to work in Dart2js. The issue seems to be that keyCode (and charCode) were previously on UIEvent, and were removed in https://codereview.chromium.org/2888283003/
While dart2js doesn't seem to rely on this, DDC does. We get code like
 get [dartx.keyCode]() {
    return core.int._check(/* Unimplemented unknown name */_keyCode);
  }

I think the answer may be to just fix our templates to make these fields instead of getters on KeyboardElement, but that will need to be checked for Dartium and dart2js as well. For Dartium in particular, version 50 precedes the removal, so we might still need the template there.
The keyCode accessor also appears in the html_renamer.py, because it got changed to being a double. I think that's been reverted, so we might be able to just remove it from there.

The fix to the template to make them be fields rather than getters seems to work. That template is actually only for dart2js, so the change doesn't affect Dartium.
https://codereview.chromium.org/2896653003

https://codereview.chromium.org/2896653003


Vagrant Provider Choice and Documentation

Added the ability to specify which vagrant provider you use, also added some documentation with examples.

@chef/chef-provisioning-committers

Also paging @metadave and @randomcamel for review.  Do the current members of @chef/chef-provisioning-committers want to get replaced with the current people working on it?  I can update the group

@scotthain Nice! I can give it a try.. I wonder if we need to modify how we render the Vagrantfile ...  Also @tyler-ball I would love to a contributor (be a committer if possible) as you mentioned.. :smile: But we'll see.. Testing this at the moment..

@afiune There are ways to modify the Vagrantfile in certain circumstances, but it's limited. Check here for info: https://github.com/chef/chef-provisioning-vagrant/blob/master/lib/chef/provisioning/vagrant_driver/driver.rb#L224

@scotthain Sure my friend, I was exactly saying that that portion of the code (rendering that file) needs some love... Now that you introduced the providers as shown..
Look at this and see how we pass the provider in delivery-cluster.. (kinda ugly lol)
https://github.com/opscode-cookbooks/delivery-cluster/blob/master/libraries/vagrant.rb#L111-L118
I rather prefer pass some attributes and let the vagrant_driver to render the file.. But definitely that could be on next PRs..

Hey @scotthain - thanks for this PR!


[TACHYON-1468] Fix shell utils test on OSX

https://tachyon.atlassian.net/browse/TACHYON-1468

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Tachyon-Pull-Request-Builder/7453/
Test PASSed.

LGTM


/rules command needs updating

Rule 6 still mentions Terra, and alludes to other servers (i.e. Stratos) inside the oblique network, even though now it's just Oblique
No mention of AFK machines being prohibited
The lead listing at the end is a bit outdated, as Owski retired.

As a sidenote, the discord invite link on /rules doesn't immediately work because the link picks up the period at the end of the sentence, but that's minor.

Updated, AFK machines are not prohibited until we announce it so. I've passed the message to the rest of the mod team.


Test running a machine learning model on random input device data

Describe the aim of this enhancement
Establish backend steps & procedures for analyzing input device data
Describe the solution you'd like

[ ] Try running ml models on randomly generated input device data
[ ] Determine inputs, outputs, and how ml will be integrated to the application
[ ] Create branch to work on the integration with machine learning
[ ] Add backend method for exporting quiz actions from database, options might include

add csv to /data, which is ignored by git
method is called when submitting quiz (?)

Additional context

This is also to help the development of the export function at https://github.com/Iionsroar/inquizitor/issues/31

Yung processing na mangyayari ay mag tatake in ng raw data yung ml pipeline tapos mag output ng prediction. Yung raw data na igagrab ay from database mismo. I cocode nalang sa pipepline kung pano siya lilinisin.
Kaya for testing, pwede ka mag return nalang ng random predictions.
Question pala, ano purpose ng exporting ng quiz actions?

Question pala, ano purpose ng exporting ng quiz actions?
for testing & para maread ng ml, not necessarily exporting pala

Yung exporting siguro na hinahanap natin dito ay yung function na binibigay na yung row
Something like:

Again, for testing, pwede ka nalang mag return ng random predictions (cheating or not cheating per question)

noteds

for reference, eto yung query method
crud > action.py > CRUDQuizAction: get_per_question_summary_by_attempt(db, attempt_id)

mini test run 1 postgres dump(?) data (backup from heroku datastore):
https://xfrtu.s3.amazonaws.com/fb45aa39-d62b-41a4-ad56-7b7412de96ee/2022-09-13T14%3A28%3A35Z/e532e171-5537-404e-9795-140dfc36d4b9?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAQKF7VQWOPAHYMI77%2F20220913%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20220913T143326Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=556aa885e6891409061a34ff93895ecc9663140d2f52610f67c56c74fafb1d41

lmk if better as list instead of dict
function
crud > action.py > CRUDQuizAction: get_per_question_summary_by_attempt(db, attempt_id)
return
{6: {'blur': 0,
      'copy_': 2,
      'double_click': 4,
      'focus': 1,
      'left_click': 3,
      'paste': 1,
      'right_click': 3},
  7: {'blur': 3,
      'copy_': 0,
      'double_click': 1,
      'focus': 1,
      'left_click': 2,
      'paste': 0,
      'right_click': 0},
  8: {'blur': 1,
      'copy_': 1,
      'double_click': 1,
      'focus': 1,
      'left_click': 2,
      'paste': 0,
      'right_click': 0},
  9: {'blur': 0,
      'copy_': 1,
      'double_click': 0,
      'focus': 1,
      'left_click': 1,
      'paste': 0,
      'right_click': 0},
  10: {'blur': 1,
       'copy_': 2,
       'double_click': 1,
       'focus': 0,
       'left_click': 1,
       'paste': 0,
       'right_click': 0}}

Will do tnx


pythonPackages.fontparts: 0.9.2 → 0.9.6

Motivation for this change
https://github.com/robotools/fontParts/releases/tag/v0.9.6
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build nototools

@GrahamcOfBorg build python3Packages.nototools

Executed nix build .#python3Packages.fontparts with flake support enabled on this PR and the package built just fine.

meta.changelog = "https://github.com/robotools/fontParts/releases/tag/v${version}";

Added.

@GrahamcOfBorg build nototools

please add openssl to the inputs.

I don't understand. fontparts doesn't import openssl at all?

I'm trying to do reviews on my laptop, meant it for another PR

No problem, just was confused :)


Source file organization / hierarchy

Hi @xesscorp / @diorcety and the other of the group. Congratulations by the code organization and comments, easy to understand.
I have one propose of file (modules) organization / hierarchy that will make more easy to add other distributor (issue #76 ) and software  with XML BoM (as Eagle ...).
I think in the main code directory have to be two folders distributors (with local.py, farnel.py, rs.py, ...) and softwares ( with altium.py and kicad.py, yes, moving the get_part_groupsand other function related with KiCad's xml BoM inside).
In the module importdirective we may use:
import distributors
import softwares

To use was a generic name preceded with the module name:
kicad.get_part_groups(...)
altium.get_part_groups(...)

rs.get_price_tiers(...)
farnel.get_price_tiers(...)

See that this create more easy standard to create new module of sites and software and to people here contribute. And possible to create a external flag when kicost is called `kicost -i file.xml --distributors farnell rs" allowing create a personalized spread sheet with only the distributor that the user want.
I hope you understand. I did not do this in my pull request because is deep modification in the code structure (and all files to change the functions name) and I trying to solve the more important issues first, and this would make my code not merge with yours.

Hi @hildogjr,
I agree with your intent to modify the kicost organization in order to make it more easy to add new cad support or distributors. It would be great if the software re-organization will be made using a object-oriented approach (i.e. using python classes). For example, it might be useful to create a base-class  "Distributor" with common methods to all the distributors and another class named "EdaTool" (Electronic Design Automation) that contains the common methods for all the Cad softwares. In this way, adding the support for new distributors (e.g. TME) or softwares (e.g. Eagle) will consists in:

To inherit the base-class (e.g. Distributor);
Eventually overload some common methods (e.g. get_part_xx);
Implement cad-specific or distributor-specific methods;

I think that this approach will speed-up very much the process to add new distributors/softwares and results in an overall improvement of the code readability and understanding.
Thanks in advance,
glcerone

@glcerone , I like edaTool, "using the name now". I was using a provisional name and didn't remember of EDA abbreviation.
I am not expert in python class and overloading, I know the general methodology for class, hierarchy and so on.
I am working in this issue and you will live the most organized as possible to the community improve it.

I pushed a new branch called pickle_module to the repo. It reorganizes the distributors into a subdirectory. Each distributor is a module in a separate subdirectory. Each distributor module has to implement four subroutines: get_price_tiers, get_part_num, get_qty_avail and get_part_html_tree.
The current problems with this are:

It doesn't work with multiprocessing because of some problem with pickling a module.
The local distributor isn't working.
It doesn't yet scan the distributors directory to automatically import any distributor modules that are present.

You can take a look. It's one way of reorganizing. It gives you an object-oriented approach because each distributor module is an object with encapsulated data and a consistent interface.

The pickle_module branch is now working correctly. You can take a look at it and see how it compares to your ideas. You can add new distributors by adding a new subdirectory to the distributors directory and KiCost will access it automatically.

I will test soon this.
It did some improvements in the user experience, like warning (by coloring the cells) if the user to buy enough parts to the board quantity or not in stock of all distributor. I request a merge in the master branch, but before is good to try in different Excel versions (usually I just have LibreOffice avaliable).

I tried the `pickle_module` on python3.5 and got this error message:

     File "/home/h/.local/lib/python3.5/site-packages/kicost/kicost.py", line 109, in <module>

     distributors = distributor_imports.distributors

     AttributeError: module 'kicost.distributors' has no attribute 'distributors'

Yes, I'm getting the same error. For some reason, the setup.py is not installing the distributors directory. I'm working on it.

Is it necessary that the setup.py install the distributor folder. Is this folder be visible as a general module in python? (This appear a little strange, in a topological point of view).
Maybe, just add some __init.py__ file in the distributor folder to do this importer job.

The distributor folder should be installed by setup.py as a submodule inside the kicost folder. (This is similar to what used to be done for the rs, digikey, mouser... folders.) The distributors folder and its sub-folders all have the init.py files. The installation appears correct when I install from my local directory, but not when I install from Github.

I neglected to add the init.py file to the distributors directory. It should work now.

Hi,
I didn't tested the pickle_module yet but looking at the code organization, it seem a good step forward the objective to make the code more compact and re-usable (i.e. adding new distributors or EDA tools easier). I think that a further step will be the creation of standard Distributor and EDATools classes in order to not repeat several times code between the distributors. For example, the get_price_tiers() method is almost identical between the distributors except for the tags to find in the html tree. I think that a good way to avoid the repetition of code is to use an object oriented approach, inheriting and/or overloading these methods. I will work on it as soon as possible.

Actually, if you compare all the corresponding functions in the digikey.py and farnell.py (for example), they are significantly different. You may be able to forge some common functions that can be customized with a few tags, but I have doubts. And I'm not sure if the effort would deliver any noticeable value to the user.
Of more value to the users (I think) would be things like:

More distributor modules.
Internationalization so users can work with their native currency.
Webscraping from the correct distributor website based on a user's nationality.

I don't have any experience at items 2 & 3 so I don't know the level of effort required to do them.

Worked fine now, good job, just one correction that, in may opinion, is missing. This code:
        'digikey': workbook.add_format({
            'font_size': 14,
            'font_color': 'white',
            'bold': True,
            'align': 'center',
            'valign': 'vcenter',
            'bg_color': '#CC0000'  # Digi-Key red.
        }),
        'mouser': workbook.add_format({
            'font_size': 14,
            'font_color': 'white',
            'bold': True,
            'align': 'center',
            'valign': 'vcenter',
            'bg_color': '#004A85'  # Mouser blue.
        }),
        'newark': workbook.add_format({
            'font_size': 14,
            'font_color': 'white',
            'bold': True,
            'align': 'center',
            'valign': 'vcenter',
            'bg_color': '#A2AE06'  # Newark/E14 olive green.
        }),
        'rs': workbook.add_format({
            'font_size': 14,
            'font_color': 'white',
            'bold': True,
            'align': 'center',
            'valign': 'vcenter',
            'bg_color': '#FF0000'  # RS Components red.
        }),
        'farnell': workbook.add_format({
            'font_size': 14,
            'font_color': 'white',
            'bold': True,
            'align': 'center',
            'valign': 'vcenter',
            'bg_color': '#FF6600'  # Farnell/E14 orange.
        }),
        'local_lbl': [
            workbook.add_format({
                'font_size': 14,
                'font_color': 'black',
                'bold': True,
                'align': 'center',
                'valign': 'vcenter',
                'bg_color': '#909090'  # Darker grey.
            }),
            workbook.add_format({
                'font_size': 14,
                'font_color': 'black',
                'bold': True,
                'align': 'center',
                'valign': 'vcenter',
                'bg_color': '#c0c0c0'  # Lighter grey.
            }),
        ],

in the main kicost.py file have information about the color of the distributor logo (bold, align, ... that is common).
I think this have to go out of the main file and, in same way, be imported (bg_colorand font_color) of the each distributor module. (If don't, the module are not really easy integrate, jut putting the new folder in distributors).
About (2) and (3), would be new files in the distributors folder to deal if this issue. But let finish this and, after work the next issues. :-)
What you think about leave the altium folder as a edaTools module?

IMO, all that format information ought to be moved into each distributor and they can install it into the distributors data structure when the distributor module is imported. Then the function in KiCost can loop through the distributors data and apply the formatting to the spreadsheet.
Yes, moving Altium to an eda_tools directory sounds like a good idea. (Python naming conventions are that modules and packages have short, lower-case names with underscores.) I guess if we do that with Altium, we will eventually have to move KiCad-specific functions to a similar directory in eda_tools, but not now.

The pickle_module branch seems to be working as well as the master branch. I'll merge it into the master branch if that's OK with you. Then I'll move the format information into the distributor modules.

@xesscorp , I agree (I tested too).
I am already using this  pickle_module to deal with the other issues.

I merged pickle_module into master and pushed it to Github. pickle_module is still there, but I'll remove it, eventually.

Nice, @xesscorp.
But the HTML_RESPONSE_RETRIES and other global options do not make effect in each module. I now this because of my poor connection here, I need to change this configuration in each module.
Maybe is missing some import of this variable in the distributor modules.
Because this, I checked the SEPRTR option, and appear be not used in the distributors modules despise its declaration.

You're right. I've now moved the web-scraping imports and definitions into the distributor modules. SEPRTR and some other things have been removed from the distributor modules.

I could add HTML_RESPONSE_RETRIES option in the kicost call as kicost --retry [n].

New step in the hierarchy organization @diorcety, @xesscorp (to merge with the GUI). Now:

__main__.py and GUI deal with the input param format (call and configurations);
kicost.py deal with general program flux;
New layer (modules: distributors and EDA), deal with generic requirements of each class;
"sub-modules" (farnell, digikey, ..., csv, kicad, ...) deal with specific files and scrapes.

The 1 was modified moving the distributors_dict include and remove from kicost.py to __main__.py. And now GUI call kicost() (the messages still on terminal, but will be fixed).


clipboardjs not working modaal js

clipboardjs not working modaal js   http://www.humaan.com/modaal/

That may be caused by the focus trap that the modal component creates when opened. Have you tried using the container option, specifying the modal element?

Hey @rakibprog, I'm planning to contribute to some open issues. Can you confirm if your problem remains? If so, soon I will be triaging it.


Support custom styling

Please review my changes and if there are good we now support custom corner radius!

Great work on this pull request! I've refactored the code to make it cleaner and more readable, as well as adding a new SOCStyle struct that encapsulates a bunch of styling options (including custom corner radius, shape style, padding and more)

I have yet to finish writing the README file for these new options and maybe adding the possibility of having separate corner radii for each corner.


devicePixelRatio for FixedScrollMetrics class is not provided

since flutter PR in flutter/flutter#117503, FixedScrollMetrics is requiring a devicePixelRatio parameter, which is missing in the code
will make a PR to fix this issue.

related PR #11

Merged and released v1.0.3. Thanks for the PR.


Check if we can open multiple connection to the same Reachy.

We need to check if we can open multiple connection to the same Reachy in the same Python kernel.
Note that we would need to disable the singleton decorator on ReachySDK.
If we can do it, we will remove the singleton decorator.
If not, we should think about another way to prevent two connections on the same robot in the kernel so that we can still connect to two different Reachys in the same kernel.

Problem solved with #309


@kanaabe => Blank template optional scripts

Adds prevent default on venice videoGuide and onReadMore link (to prevent # in url)
Adds ability to include options when extending the blank template
Declare the following as false in an options object to omit:
modal, flash, stripe, sailthru, marketo, quantcast

@kanaabe just updated this so syntactically it is clearer -- a default options block is used

Nice! A lot cleaner, thanks. Just need to handle that last ❌ and this is good to go.

Looks like there's a merge conflict


Back button pop logic race condition

There is a very specific case that breaks the pop logic on web used for our custom BackButton behavior on the stack.
If you're on a screen, and hit back, it typically works. However, if the screen you're going back to satisfies the following condition, it breaks:
The screen you're going back to satisfies the linking path ''. That is, if you're going to myurl.com/, then this screen handles that route.
Issue
You can never click the back button and end up at the / route.
Example
Take this linking config:
 const linking = useLinkingConfig({
    prefixes: [Linking.makeUrl('/')],
    config: {
      screens: {
        artistsTab: {
          path: '',
          initialRouteName: 'artists',
          screens: {
            artist: 'artists/:slug',
          },
        },
      },
    },
  })

Explanation
In this case, we have 2 routes in play:

/ routes to the artists screen name (ArtistsListScreen component)
/artists/:slug routes to the artist screen name (ArtistDetailScreen component)

Expected behavior
If you're in the artistsTab, and an artist screen is open (artists/djkhaled), clicking back should go to /, opening the artists screen.
Actual behavior
Going "back" from our custom BackButton component while on artists/djkhaled instead sends you back to /artists. This is entirely incorrect. It seems like it's doing this:

If the path to go back to matches "", then instead it takes the screen name of that route (in this case artists) and uses that in the URL.

This is entirely undesired.

More bad behavior
Similarly, when clicking back to a screen that had a parameter (artists/djkhaled), I have also had it go back to artists?slug=djkhaled), which was breaking the app, since my next.js page at pages/artists didn't have access to the artist detail screen.
Workaround
A workaround I don't love is this: Add a getPathFromState to your linking config, which transforms your initialRouteName bug and re-routes it to the home screen.
import { getPathFromState } from '@react-navigation/native'

const rootScreenName = 'artists'

 const linking = useLinkingConfig({
    prefixes: [Linking.makeUrl('/')],
    getPathFromState(state, options) {
      const path = getPathFromState<ReactNavigation.RootParamList>(
        state,
        options
      )

      if (path == '/' + rootScreenName) {
        return '/'
      }

      if (path == '/' + rootScreenName + '?') {
        return '/' // TODO not sure what to do when this happens
      }
      return path
    },
    config: {
      screens: {
        artistsTab: {
          path: '',
          initialRouteName: rootScreenName,
          screens: {
            artist: 'artists/:slug',
          },
        },
      },
    },
  })

Reproduction
I only have this in my app right now, so I would need to build a repro here still.

I think the right solution will be to somehow use the first-class citizen getPathFromState inside of the back button: https://reactnavigation.org/docs/navigation-container#linkinggetpathfromstate
We just have to figure out how to get the state after popping that screen off. Is it as simple as making the index of the state one lower? The difficult part is recursively getting down to the current screen and knowing which one has to pop. After all, that is that the .pop() function is supposed to do for us...

Another solution is to not use the '' URL in a stack haha. Not ideal.

I'm also finding that adding an artists route helps. Currently, I only have '' and artists/:slug. Doing this helps:
 const linking = useLinkingConfig({
    prefixes: [Linking.makeUrl('/')],
    config: {
      screens: {
        artistsTab: {
          path: '',
          initialRouteName: 'artists',
          screens: {
            artist: 'artists/:slug',
            artists: 'artists'
          },
        },
      },
    },
  })

I'm also finding that adding an artists route helps. Currently, I only have '' and artists/:slug. Doing this helps:
 const linking = useLinkingConfig({
    prefixes: [Linking.makeUrl('/')],
    config: {
      screens: {
        artistsTab: {
          path: '',
          initialRouteName: 'artists',
          screens: {
            artist: 'artists/:slug',
            artists: 'artists'
          },
        },
      },
    },
  })

This is the best solution I have so far. As long as the home page is 1) a "list" screen that can also map to another URL, it's fine. My recommendation for generalized use would be to also have a route at home that catches the same screen. That way, if you go "back" it'll go to /home, and you'll have the same screen there as /. It requires making an extra screen for Next.js, but not that bad.

I made a redirect in my next config:
 * @type {import('next').NextConfig}
 */
const nextConfig = {
  experimental: {
    esmExternals: 'loose',
  },
  images: {
    disableStaticImages: true,
  },
  typescript: {
    ignoreBuildErrors: true,
  },
  async redirects() {
    return [
      {
        source: '/',
        destination: '/artists',
        permanent: false,
      },
    ]
  },
}

Still looking into better solutions, since we of course want to be able to use the root endpoint.

Okay, I have a better diagnosis of the problem:
When you go back from a given screen, it will always turn the URL into the name of that screen. It seems that this pop logic is just completely off.
If you're at /artists/:id with screen name artist, and go back, it will always go back to /artist.
If you're at /venues/:id with screen name venue, and go back, it will go back to /venue. This makes no sense for behavior, of course; it should go to the previous screen in the stack.

This makes no sense for behavior, of course; it should go to the previous screen in the stack.

Damn, this is weird! Can you share your current implementation for router.pop() please? Just want to make sure we have the same before digging into this. I don't think I have the same behaviour, a repro would be helpful.

Yeah! here's my back button:
import React from 'react'
import {
  HeaderBackButton as ReactNavigationHeaderBackButton,
  HeaderBackButtonProps,
} from '@react-navigation/elements'
import { useRouter } from '../use-router'

import { useRouter as useNextRouter } from 'next/router'
import { StackRouter } from '@react-navigation/routers'
import {
  StackActions,
  getPathFromState,
  CommonActions,
} from '@react-navigation/native'
import { NativeStackScreenProps } from '@react-navigation/native-stack'

// this is scary...
// @ts-expect-error but react navigation doesn't expose LinkingContext 😬
import LinkingContext from '@react-navigation/native/lib/module/LinkingContext'
import { LinkingOptions } from '@react-navigation/native'

import { useContext } from 'react'

// hack to access getStateForAction from react-navigation's stack
//
const stack = StackRouter({})

export function HeaderBackButton({
  navigation,
  ...props
}: HeaderBackButtonProps & {
  navigation: NativeStackScreenProps<any>['navigation']
}) {
  const linking = useContext(LinkingContext) as
    | {
        options?: LinkingOptions<ReactNavigation.RootParamList>
      }
    | undefined
  const nextRouter = useNextRouter()

  React.useEffect(() => {
    console.log('[before-remove] start')
    const stop = navigation.addListener('beforeRemove', (e) => {
      e.preventDefault()
      console.log('[before-remove]', {
        target: e.target,
      })
    })

    return stop
  }, [navigation])

  if (!props.canGoBack) {
    return null
  }
  const back = () => {
    if (nextRouter) {
      const nextState = stack.getStateForAction(
        navigation.getState(),
        StackActions.pop(),
        // @ts-expect-error pop and goBack don't need the dict here, it's okay
        // goBack: https://github.com/react-navigation/react-navigation/blob/main/packages/routers/src/CommonActions.tsx#L49
        // pop: https://github.com/react-navigation/react-navigation/blob/main/packages/routers/src/StackRouter.tsx#L317
        {}
      )
      console.log('[back]', {
        nextState,
        state: navigation.getState(),
      })
      if (nextState) {
        const getPath = linking?.options?.getPathFromState || getPathFromState
        const path = getPath(nextState, linking?.options?.config)

        if (path != undefined) {
          return nextRouter.replace(path)
        }
      }
    }

    navigation.goBack()
    // router.back()
  }

  return <ReactNavigationHeaderBackButton {...props} onPress={back} />
}

I just learned one added, interesting thing:
If you want one screen to be able to go back to another, they have to both be in the same stack. So make sure that the stack you make in /pages includes all the screens that should be possible to go back to inside of it.

Omg, that actually solved all of this. lol. wow. I should have thought this through more.
I'll need to document this really clearly.
Walkthrough
Imagine you have these routes
/artists
/artists/drake
/artists/albums/songs/take-care
In this case, if you open /artists/drake, then going back should always go back to /artists.
The structure for this library is like so: every single Next.js page is a React Navigation Stack.
So let's look at why this was breaking for me:
What I did incorrectly
For each page, I had a stack like this:
pages/artists/[slug].tsx
export function ArtistPage() {
  const screenOptions = useNativeStackNavigationOptions()
  return (
    <NativeStack.Navigator screenOptions={screenOptions}>
      <NativeStack.Screen
        name="artist"
        component={ArtistScreen}
        getId={({ params }) => params?.slug}
      />
    </NativeStack.Navigator>
  )
}

This seemed harmless. But when I click goBack, React Navigation is looking in this stack, and thinking, okay, I'll just send you back from here, which would just be the artist screen, without any params. So it goes to /artist.
In retrospect, this was a pretty dumb mistake from me.
The solution
For screens that should stack on top of others, it's important that their stack contains every screen involved. For example, if you want to open /artists/djkhaled, and have it be able to go back to /artists, it's important for the stack to have the artists screen. That way, React Navigation says, okay, that is the previous screen in this stack.
Recall that we defined artists as initialRouteName in linking config:
const linking = useLinkingConfig({
    prefixes: [Linking.makeUrl('/')],
    config: {
      screens: {
        artistsTab: {
          path: '',
          initialRouteName: 'artists',
          screens: {
            artist: 'artists/:slug',
            artists: 'artists'
          },
        },
      },
    },
  })

In order for this to work, you need to render artists in the initial stack, even if you're on the artists/:slug screen.
So here is what our pages/artists/[slug].tsx actually looks like:
// pages/artists/[slug]

export default function ArtistPage() {
  const screenOptions = useNativeStackNavigationOptions()
  return (
    <NativeStack.Navigator screenOptions={screenOptions}>
      <NativeStack.Screen
        name="artist"
        component={ArtistScreen}
        getId={({ params }) => params?.slug}
      />
      <NativeStack.Screen
        name="artists" // this is added
        component={ArtistsScreen}
      />
    </NativeStack.Navigator>
  )
}

Since this stack has both the /artists/[slug] and /artists screen, we can use the same stack for /pages/artists:
// pages/artist

export { default } from './[slug]
``

## Thinking out loud

> The remaining things I write are _unconfirmed thoughts that I still need to test_. I'm writing them so that I can try them out and see what works. The above is the right solution. The below might be wrong.

We now have a working `/artists` and `/artists/[slug]` screen.

But why should the `/artists` route load in the code for `/artists/[slug]`? This feels unnecessary, right?

After all, `/artists` never has to go back to any screen; **it is the root of its stack.**

What if `/pages/artists` only exported its own screen:

```tsx
// pages/artists

export function ArtistPage() {
  const screenOptions = useNativeStackNavigationOptions()
  return (
    <NativeStack.Navigator screenOptions={screenOptions}>
      <NativeStack.Screen
        name="artists"
        component={ArtistsScreen}
      />
    </NativeStack.Navigator>
  )
}

Since artists is the root screen of this stack, and will never go back anywhere, it's fine to only include artists in this stack.
One concern I have with this approach is, we will lose the scroll position of /artists when we open an artist, since it will unmount.
So a better solution is probably to still include the artist screen inside of /artists, loaded dynamically:
// pages/artists

const ArtistScreen = dynamic(() => import('screens/artist'))

export function ArtistPage() {
  const screenOptions = useNativeStackNavigationOptions()
  return (
    <NativeStack.Navigator screenOptions={screenOptions}>
      <NativeStack.Screen
        name="artist"
        component={ArtistScreen}
      />
      <NativeStack.Screen
        name="artists"
        component={ArtistsScreen}
      />
    </NativeStack.Navigator>
  )
}

Tree shaking /artists/[slug]
In the /artists page, we dynamically imported artist, the screen that goes to /artists/[slug].
In the /artists/[slug] page, we can do the same: dynamically import artists, the screen for /artists:
export function ArtistPage() {
  const screenOptions = useNativeStackNavigationOptions()
  return (
    <NativeStack.Navigator screenOptions={screenOptions}>
      <NativeStack.Screen
        name="artist"
        component={ArtistScreen}
        getId={({ params }) => params?.slug}
      />
    </NativeStack.Navigator>
  )
}

This seemed harmless. But when I click goBack, React Navigation is looking in this stack, and thinking, okay, I'll just send you back from here, which would just be the artist screen, without any params. So it goes to /artist.
In retrospect, this was a pretty dumb mistake from me.
The solution
For screens that should stack on top of others, it's important that their stack contains every screen involved. For example, if you want to open /artists/djkhaled, and have it be able to go back to /artists, it's important for the stack to have the artists screen. That way, React Navigation says, okay, that is the previous screen in this stack.
Recall that we defined artists as initialRouteName in linking config:
const linking = useLinkingConfig({
    prefixes: [Linking.makeUrl('/')],
    config: {
      screens: {
        artistsTab: {
          path: '',
          initialRouteName: 'artists',
          screens: {
            artist: 'artists/:slug',
            artists: 'artists'
          },
        },
      },
    },
  })

In order for this to work, you need to render artists in the initial stack, even if you're on the artists/:slug screen.
So here is what our pages/artists/[slug].tsx actually looks like:
// pages/artists/[slug]

const ArtistsScreen = dynamic(() => import('screens/artists'))

export default function ArtistPage() {
  const screenOptions = useNativeStackNavigationOptions()
  return (
    <NativeStack.Navigator screenOptions={screenOptions}>
      <NativeStack.Screen
        name="artist"
        component={ArtistScreen}
        getId={({ params }) => params?.slug}
      />
      <NativeStack.Screen
        name="artists"
        component={ArtistsScreen}
      />
    </NativeStack.Navigator>
  )
}

I'll be testing these things out.
Notice that we use the same screens everywhere, but the way they get imported/displayed in a given page differs. I'll keep testing these things, but overall, the race condition is solved by this comment.
Let me know if anything is unclear.

Also, looks like this logic works better for going back. Seems like getPathFromState is returning the incorrect path sometimes...so I'm checking the next state screen's path.
const back = () => {
    if (nextRouter) {
      const nextState = stack.getStateForAction(
        navigation.getState(),
        StackActions.pop(),
        // @ts-expect-error pop and goBack don't need the dict here, it's okay
        // goBack: https://github.com/react-navigation/react-navigation/blob/main/packages/routers/src/CommonActions.tsx#L49
        // pop: https://github.com/react-navigation/react-navigation/blob/main/packages/routers/src/StackRouter.tsx#L317
        {}
      )
      if (nextState) {
        let path =
          nextState.index != undefined
            ? nextState.routes[nextState.index]?.path
            : undefined

        if (!path) {
          const getPath = linking?.options?.getPathFromState || getPathFromState
          path = getPath(nextState, linking?.options?.config)
        }

        if (path != undefined) {
          return nextRouter.replace(path)
        }
      }
    }

    navigation.goBack()
  }

The structure for this library is like so: every single Next.js page is a React Navigation Stack.

Yeah that's what I do for my apps. We should really communicate about this and write a complete guide on the architecture.

Just tested using dynamic imports to improve tree shaking and it's working well! Good idea, thanks!

sweet. will def have this in the dedicated docs


Add and apply pre-commit poetry checks

Description
This adds a pre-commit check which automatically checks the Poetry-based pyproject.toml file for formatting and the poetry.lock file for related updates.
I noticed the check for the lockfile was failing due to SSH errors related to the git-based hash for Pycytominer. As a result, I opted to update pycytominer to use the latest PyPI release of 1.1.0. This will likely speed up installations more widely.
Closes #159
References #158 (CC @axiomcura)
What is the nature of your change?

[ ] Bug fix (fixes an issue).
[x] Enhancement (adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
[ ] This change requires a documentation update.

Checklist
Please ensure that all boxes are checked before indicating that a pull request is ready for review.

[x] I have read the CONTRIBUTING.md guidelines.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] New and existing unit tests pass locally with my changes.
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] I have deleted all non-relevant text in this pull request template.

This change will likely depend on #166 .

@d33bs Any insight into why this testing run failed, but  this re-run  succeeded?

Thanks @gwaybio and @kenibrewer ! I've moved to using poetry-check as suggested to avoid potential issues.

@d33bs Any insight into why this testing run failed, but this re-run succeeded?

I believe this is roughly the same issue as reported in #143 . I don't know for sure, but my hunch is that it has something to do with multiprocessing from Parsl used through the non-threaded tests in CytoTable alongside potential nondeterministic constraints by which MacOS environments are provisioned from GitHub for Actions workflows. I don't have any proof of this, but the fact that it only happens sporadically on MacOS virtual environments has me imagine as though they are (perhaps rarely, not guaranteed) shared resources across multiple workflows.

Thanks as well @kenibrewer ! Merging this in.


Changi Coffee Corner

Name of Student Organisation*
[Insert name of Student Organisation Here]
Cluster
Specialist
Classification
Interest Group
Description
Through building a vibrant coffee brewing culture in SUTD, Changi Coffee Corner hopes to connect people over coffee and build the community. With our goal of having a student-run espresso coffee cart, we are limited to conduct internal workshops and coffee appreciation sessions for our members. Do join us if you have a passion for coffee and would like to be a part of our community.
Training / Meeting Timings
TBC
Student Organisation Introduction Video
N.A
Name / Contact of President
Joseph Low
Telegram: @jolow
Other Relevant Links
Join our Telegram group at https://t.me/joinchat/Uxk-Q-j-MC71VPSd

This is good.


Use mean input in allocation

Fixes https://github.com/Deltares/Ribasim/issues/1121.
To do:

[x] Use average source flows
[ ] Use average vertical fluxes on basin for level demand
[ ] Use average (or simply average of now and last) basin level for level demand
[ ] Update documentation

The last commit also removes all variables and constraints from the allocation problems for basins that do not have a level demand.


feat: configurable ls path [ROAD-1082]

Description
This PR should enable a setting in the Snyk settings menu to provide a custom Language Server binary
Checklist

[x] Tests added and all succeed
[x] Linted
[x] CHANGELOG.md updated

Currently manual testing shows it working, but when changing the LS binary path, the old Language Server output window doesn't close, leading to a buildup of Language Server output windows:

Removed feature SCENARIO LS restart when changing custom LS.
There are snyc issues caused by the need to synchronise the LanguageClient in instantiation. A manual VSCode restart will be required when changing the LS binary path.


Instrument Gatsby application

Description
We have followed readme to instrument react application. However, we don't see anything in new relic
Steps to Reproduce

installed package with yarn add @newrelic/browser-agent
Created app in New Relic One
Instantiated the agent inside outernmost component (details removed)

const options: NrOptions = {
  applicationID: '',
  licenseKey: '',
  beacon: 'bam.nr-data.net',
  accountID: '',
  trustKey: '',
  distributed_tracing: {
    enabled: true
  },
  privacy: {
    cookies_enabled: true
  }
}

const nr = new NR()
nr.start(options).then(() => {
  console.log('Browser Agent Initialized!')
})

Launched the application with gatsby develop
interacted with the application causing calls to backend

Expected Behavior
That the traces of the navigation and the calls to backend would appear in New Relic
Relevant Logs / Console output
In console, I can see Browser Agent Initialized!
Your Environment
Browser: Chrome v111.0
OS: MacOs Ventura 13.2
Additional context
if instead of gatsby develop we do gatsby build, we receive this error instead
"window" is not available during Server-Side Rendering. Enable "DEV_SSR" to debug this during "gatsby develop".

See our docs page for more info on this error: https://gatsby.dev/debug-html

  3 |  * SPDX-License-Identifier: Apache-2.0
  4 |  */
> 5 | export const exists = typeof (window.performance) !== 'undefined' && window.performance.timing && typeof (window.performance.timing.navigationStart) !== 'undefined'
    |        ^
  6 | // export default {
  7 | //   exists
  8 | // }

  WebpackError: ReferenceError: window is not defined

That's what I call fast!!!. Thanks a lot

@TioLuiso we got the updated package published. Can you please try now. The version should be 0.1.229. Keep in mind, the NPM package is still a pre-release. We are still testing things out but I would love to hear any feedback you might have. Thanks.

Hello
Well, I'm trying to instantiate BrowserAgent, as it's said in the readme, but the path @newrelic/browser-agent/loaders/browser-agent it looks like it's incorrect. There's one at @newrelic/browser-agent/types, but it's an interface. I have seen a class at @newrelic/browser-agent/dist/esm/loaders/browser-agent, but when I try to import it, I get
<EMAIL_ADDRESS>10:21
Module parse failed: Unexpected token (10:21)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
| import { now } from '../../../common/timing/now';
| export class Instrument extends InstrumentBase {
>   static featureName = CONSTANTS.FEATURE_NAME;
|   constructor(agentIdentifier, aggregator) {
|     let auto = arguments.length > 2 && arguments[2] !== undefined ? arguments[2] : true;

Thanks for trying the npm package @TioLuiso . Any chance you could put together a small reproduction of the issue? The import path for the browser agent class is correct. What version of NodeJS are you using? When you say it is incorrect, what do you mean?

Ok

I created an empty react typescript app with yarn create react-app my-app --template typescript
I added the @newrelic/browser-agent package with yarn add @newrelic/browser-agent
I added imported BrowserAgent into App.tsx with import { BrowserAgent } from '@newrelic/browser-agent/loaders/browser-agent'

As you can see, if cannot find the module @newrelic/browser-agent/loaders/browser-agent

I have pushed this into a github repo: https://github.com/TioLuiso/react-newrelic

Thanks @TioLuiso that issue should be resolved with https://github.com/newrelic/newrelic-browser-agent/pull/456

@TioLuiso we have published a new release of the NPM package 0.230.0. Can you please give that a try?
I was able to get your reproduction working with the new version after adding a line to instantiate the BrowserAgent. Please look back over the README for info on what needs to be passed to the class.

I am still seeing the same issue on 0.1.230 I believe. I'm assuming this was the version that was supposed to be fixed?
I was able to produce a minimal reproduction here using Parcel: https://github.com/kylekarpack/nr-browser-test
Here's what I see in VSCode:

@kylekarpack I do not see that issue when I clone your reproduction repository. What version of Node are you running? What VSCode plugins do you have installed? Any global or IDE eslint or typescript settings that could cause this?

@patrickhousley, this occurs for me in a GitHub codespace running Node 19.7.0, but the issue is less about VSCode and more about the fact that the project won't build. When you run npm run build, does it actually build successfully for you?

Ah ok, yea the build does show the error but not my vscode. Weird.

Weirdly, what does work for the build is:
import { BrowserAgent } from '@newrelic/browser-agent';

But that causes VSCode's syntax highlighting to get unhappy:
Cannot find module '@newrelic/browser-agent' or its corresponding type declarations.ts(2307)

@kylekarpack That issue I linked above is the exact cause of your problems. The parcel bundler has a PR merged to support the exports package.json field but it has not been released yet. Until that is released, you can add the below to your project's package.json to make the build work.
  "alias": {
    "@newrelic/browser-agent/loaders/browser-agent": "@newrelic/browser-agent/dist/esm/loaders/browser-agent"
  }

@patrickhousley, thanks for digging that up. That does indeed solve the build issue with Parcel. Appreciate it!


Create a set of pre-defined Crawlers in CrawlerX

PR was added as GSoC 2020 task by Poornima Rangoda


Use [Flags] enum for FontStyle

TextMateSharp.Themes.FontStyle is currently a class with int fields representing a bitfield. This sort of bitfield is normally represented in c#/dotnet as an enum with the [Flags] attribute, so FontStyle should be updated to match.

Agree. The implementation is a port from tm4e so it matches that implementation. But there are some areas for improvement.
@Khitiara would you like to add a PR for this?

ill fork it and do it, this should be a relatively quick thing

Merged! Thanks for the contribution.


Fixes Using Chips in the "add Tags" section #9103

Fixes Issue
Fixes: #9103
Changes proposed
Added "enter" functionality to the "Tags" input, now we can add new tags by pressing "enter".
Screenshots
https://github.com/EddieHubCommunity/BioDrop/assets/86093112/2ad92497-1bc6-4f72-9021-1d1120db9321

PRs not related to profile, should not include any data file. Also, you're not allowed to remove someone else json file.
Please revert the changes from data/alevel7.json

I reverted that commit and pushed the new changes. Sorry for accidently deleting someone's json file.

Thank you for your contribution 👍 But this now breaks the events page, please search for where the component TagsInput is used

Thank you for your contribution 👍 But this now breaks the events page, please search for where the component TagsInput is used

can you specify steps to produce this error?

can you specify steps to produce this error?

I clicked on manage events, then went to edit an event.

can you specify steps to produce this error?

I clicked on manage events, then went to edit an event. You can search for where the TagsInput component is used, then you can test these pages also

I followed the steps and tried to edit an event, everything was working perfectly and I also searched for TagsInput but VS Code is showing that it is only used in profile.js file. Btw I have renamed the tagInputRef to inputRef so I guess this error will automatically get fixed.

can you specify steps to produce this error?

I clicked on manage events, then went to edit an event. You can search for where the TagsInput component is used, then you can test these pages also

in my local setup there is no option to add tags on events and VS Code is showing that TagsInput is only used in profile.js file. I also pulled changes but the tags options on event manage page is still not showing.

in my local setup there is no option to add tags on events and VS Code is showing that TagsInput is only used in profile.js file. I also pulled changes but the tags options on event manage page is still not showing.

see screen recording below to reproduce the error
https://github.com/EddieHubCommunity/BioDrop/assets/73095526/45735c6d-f17a-4a8c-8bc2-fdb622cc5422


Change incorrect OLD_ARCH header import

Overview
The import was set incorrectly for OLD_ARCH which leads to project's failing build.
Test Plan
Build an iOS project with OLD_ARCH.

@Naturalclar how soon is it possible with a new release including this? :)

@robertherber just released a new version! 🚀


Add option to specify envFrom for kustomize controller

Signed-off-by: MxNxPx<EMAIL_ADDRESS>
What this PR does / why we need it:

Allow for the ability to specify envFrom values for the kustomize controller
Required namely when using an Azure service principal to decrypt sops encrypted secrets

Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #
https://github.com/fluxcd-community/helm-charts/issues/35

Special notes for your reviewer:
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] helm-docs are updated
[x] Helm chart is tested

LGTM