Fixed #28192 -- Prevented positional parameters for most form field t…

…ypes

Could (or should) the same be done for django.db.models.fields?

Maybe, but it's a little more tricky as verbose_name has traditionally been accepted as first positional parameter, and we should not break that (at least not without a deprecation cycle).

True. Also the model passed as the first parameter to ForeignKey, etc would need to be considered.

Thanks, feel free to commit!


“reaper_sws-arm64.dylib” can’t be opened because Apple cannot check it for malicious software.

When trying to install SWS on an M1 MacBook Air into Reaper, it throws up a nice ugly error in my face:
“reaper_sws-arm64.dylib” can’t be opened because Apple cannot check it for malicious software.
This software needs to be updated. Contact the developer for more information.
Safari downloaded this file today at 2:03 AM.
Reaper 6.68, Universal, and SWS latest, ARM64.
Any ideas?

Please see here to unquarantine it (you'd need to adjust the command for the ARM version).

@nofishonfriday that fixed it, thanks! For reference, in case anyone else ever comes across this, the exact command is:
xattr -d com.apple.quarantine ~/Library/Application\ Support/REAPER/UserPlugins/reaper_sws-arm64.dylib

@nofishonfriday It's also possible to authorize SWS to launch via the GUI: https://youtu.be/NDwmqJYJq9s?t=336.

I'll add that to the Wiki, thanks.


[CARBONDATA-3232] Add test framework and test case for alluxio UT

Add test case for alluxio UT

install alluxio UT environment, start alluxio minicluster before running test case.
This PR only add webapp into spark-common-test, it won't affect other module and non-test class
add CarbonSession test case for UT  => done
add external table test case for UT=>  done
add spark carbon file format test case for UT=>done
add SDK test case for UT=> done

Test case:

CarbonSession and external test:

all data type and Create/Load/Select/Insert/Update/Delete.
Create table and segment manage.
alter operation.

SDK and spark carbon file format:

write and read.
select

TODO after this PR:
TODO:  remove the webapp, but need Alluxio community support it in the future.
Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[ ] Any interfaces changed?
No
[ ] Any backward compatibility impacted?
No
[ ] Document update required?
No
[ ] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.
yes, add many test case for alluxio
[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.
No

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/35/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/34/

Build Failed  with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/38/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbonPRBuilder2.3/6022/


Docs / ReadMe needs updating to avoid downloading the wrong plugin

At the moment your docs say "Install with your favourite package manager (pnpm, npm, yarn)."
But because of many similar named packages it's easy to download the wrong one.
For example, these are all wrong, but have almost identical names. There are many more than these 3 examples:

https://www.npmjs.com/package/pinia-plugin-persistedstate-2
https://www.npmjs.com/package/pinia-plugin-persist
https://www.npmjs.com/package/pinia-persistedstate

To stop people downloading the wrong plugin I suggest you add links to the correct packages on your read me page instead of letting people search for the correct one.
For example: https://www.npmjs.com/package/pinia-plugin-persistedstate
Or just add the correct download command directly on the docs npm i pinia-plugin-persistedstate.
Thanks for such a great plugin. This is just my 2 cents to make things easier :)

That's actually true, I'll do this later today, thanks for the consideration! :)


fix(modal): fix modal event handling and add some tests

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Deploy to Production - 2024/10/03 (Equalize)

New CLI Major (2.0):
New deploy feature: Deploy now happens remotely;
E2E tests for the entire link/build/deploy sequence;
Unit tests for the new Deploy command;

Lgtm


Adds testing to abstract llm and simplifies fallback handling

remove fallback_not_found_relevant_contents?

@avelino IMO, it doesn't make sense to have this variable, it's only being used in the AbstractLLM (which is never used) and you could just use the standard fallback as the field, just overwritting the behavior of the DefaultLLM or adding a custom instance of your own.

@avelino IMO, it doesn't make sense to have this variable, it's only being used in the AbstractLLM (which is never used) and you could just use the standard fallback as the field, just overwriting the behavior of the DefaultLLM or adding a custom instance of your own.

In this issue we discussed some ideas for fallback, and @avelino proposed the idea of using two fallbacks in case no relevant documents were found from the retriever:

A fixed fallback text as an answer
Another prompt that is injected in prompt such as we delegate the answer to the llm (which, depending of prompt instructions, will answer accordingly)

The idea of his PR was that. Should we change this behavior?
obs: I think the terms were mixed in the code, because the fixed text here
https://github.com/talkdai/dialog/blob/4ca50e80ea3968e467c133df688bc62f5cd17aa1/src/dialog/llm/abstract_llm.py#L84
is using fallback_not_found_relevant_contents while this other part
https://github.com/talkdai/dialog/blob/4ca50e80ea3968e467c133df688bc62f5cd17aa1/src/dialog/llm/default.py#L53
uses prompt_config.get("fallback") or self.config.get("fallback").get("prompt").

@lgabs the thing is, abstractllm is never called since its an abstract class, so this fallback is never used, unless you've built a new LLM that relies on this fallback_not_found_relevant_contents. We can do a rollout with the variables still inside the settings, but there is no point of maintaining this variable inside the AbstractLLM.
This variable should be deprecated in the future when we get to a better understanding on how to process fallbacks on no retrievals.

In the issue, you made this comment @lgabs, which I agree, but my point here is to maintain a single variable that carries that data, my choice was to keep fallback since its shorter and simple.

Probably the default behavior should be the fixed fallback, and if the developer wants to delegate to GPT the answer using instructions from the prompt template, than he/she can make its own custom subclass of AbstractLLM dealing with desired behavior.

I'm going to fallback this PR to just add the test to the AbstractLLM, later we discuss the fallback variable

@vmesel

abstractllm is never called since its an abstract class, so this fallback is never used

this is not true, the default DialogLLM here is a subclass of the abstract one and it does not re-implement the abstrac's method process, and indeed it is called here (for any new subclass made):
https://github.com/talkdai/dialog/blob/4ca50e80ea3968e467c133df688bc62f5cd17aa1/src/main.py#L83
to avoid leaving this behavior in the abstract, the method would be re-implemented in default class, but this would be strange since the default class should probably work with minimal changes from the abstract.
We could reopen the issue to discuss that later.


[Admin] Cleanup

Docs Build status updates of commit bcd0a4c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/publish/publish-task-pane-and-content-add-ins-to-an-add-in-catalog.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


papplDevice Improvements for Default Schemes

Is your feature request related to a problem? Please describe.
The CUPS 2.x USB backend provides quirk support - quirks can help in some cases when the device has a known issue which we can workaround, or it can reject the device in case its USB support is utterly broken.
Describe the solution you'd like
Provide a quirk support where files can be read from /usr/share/pappl/quirks/* and from /etc/pappl/quirks/* with higher priority, where printer application maintainers and admins can put quirk files regarding their devices.
Describe alternatives you've considered
This might be solved on printer application level as well, but a generic support in PAPPL would be great.

OK, so I have reservations about this... By far the most common usage of quirks is to force unidirectional mode, which is unnecessary for a real printer application since the driver only reads when it needs to. I'm not sure "delay-close" matters, either. I'm not sure what to do for for "blacklist" and "no-reattach".
But the bigger issue is that I don't want PAPPL to have to track/support quirks forever like CUPS has, and in the age of snaps and flatpaks and other containers, even having a common PAPPL "repository" of quirks won't work because the instances are all isolated and might not even have access to a common /etc directory for configuration.

I think PAPPL's USB backend should support quirks, the same types as CUPS supports and ideally the same syntax of quirks files as CUPS uses. Due to the fact that we use sandboxed packaging (Snap or OCI containers, Flatpak does not work with daemons) more and more often we will not have a central quirk database, but the typical native Printer Application in the future will only support a handful of printers or the printers of one manufacturer. Here the developer of the Printer Application could easily set up a table of the few quirky printers which are supported by this Printer Application.
The big database of all known quirks is only needed for the big retro-fitting Printer Applications (like the Ghostscript Printer Application) which will use CUPS-2.x- and/or driver-supplied backends (contained and hidden in the Snap or OCI container) and so have all the quirks on board (pappl-retrofit supports using CUPS 2.x backends).

@tillkamppeter Looking at the current quirks file, there are 117 unique entries; here is the breakdown:

Quirk
Count

unidir
54

no-reattach
32

blacklist
27

delay-close
9

soft-reset
2

vendor-class
1

whitelist
1

usb-init
0

unidir is unnecessary because with PAPPL the driver only reads if it needs to (vs. the USB backend reading in a background thread).
no-reattach is unnecessary because PAPPL does not re-load the usblp kernel module.
blacklist currently only applies to a subset of Canon inkjet printers, all of which are in a specific range of product IDs (0x3NNN) so if I really needed to I could explicitly mask printers with the Canon vendor ID (0x04a9) and product IDs. Haven't had any bug reports on that...
'soft-reset' applies to the old Prolific USB to parallel converter and to certain Samsung printers (and it looks like at some point we gave up trying to isolate to specific models and always do a soft reset...) If this turns out to be an issue I guess I could add a soft reset on device close, but so far I've had 0 reports of this issue and doing a soft reset typically resets the printer as well which isn't what we want...
delay-close is spread around but is unlikely to apply since the issue had to do with reading back-channel data at the end of a job - again, the PAPPL architecture does things differently and won't have to worry about delaying things outside of the driver.
vendor-class applies to a single receipt printer from EPSON - you'd need to provide your own custom scheme to support this printer with PAPPL (it won't show up otherwise...)
whitelist is used by a single Samsung printer to turn off soft-reset behavior - not needed for PAPPL.
Short of blacklisting the subset of Canon inkjet printers that won't work with PAPPL anyways, I don't see a need to support USB quirks in PAPPL.

@michaelrsweet At the start I meant quirk support by providing PAPPL API, which would read files from specified directories and return a list of quirks defined in directories plus the quirk behavior implementation in pappl/printer-usb.c - the database itself would be in a specific printer application (it does not make sense to carry it with PAPPL). But I guess you would not like to have the quirky behavior in PAPPL USB implementation (which I understand), correct?
However that complicates backward support of old printers via retrofitting printer applications - we have the proper drivers, setup and IPP system via printer applications, but some older printers won't work properly as it does with CUPS 2.x.
Does PAPPL support a plug-in backends, so retrofitting printer apps could f.e. provide its own USB backend implementation and still use PAPPL, or is it like "Use PAPPL USB backend or implement the printer application without PAPPL at all"?

@zdohnal Correct, I would prefer to not encumber PAPPL with USB quirks if we can avoid it.
PAPPL does support adding custom schemes, which Till uses in the pappl-retrofit library to support/use the original CUPS backends. But there isn't a way to suppress the built-in "usb", "socket", and "file" schemes so that users of these applications are unable to specify them.
Conceptually I could update the papplDeviceAddScheme APIs to allow a program to replace the standard handers with its own - then Till could register each of the CUPS backends as their own scheme.

Thank you for looking into it!

@tillkamppeter Looking at the current quirks file, there are 117 unique entries; here is the breakdown:
Quirk 	Count
unidir 	54
no-reattach 	32
blacklist 	27
delay-close 	9
soft-reset 	2
vendor-class 	1
whitelist 	1
usb-init 	0
unidir is unnecessary because with PAPPL the driver only reads if it needs to (vs. the USB backend reading in a background thread).
no-reattach is unnecessary because PAPPL does not re-load the usblp kernel module.

Aha, we only detach it - hopefully nobody is using it till now.

blacklist currently only applies to a subset of Canon inkjet printers, all of which are in a specific range of product IDs (0x3NNN) so if I really needed to I could explicitly mask printers with the Canon vendor ID (0x04a9) and product IDs. Haven't had any bug reports on that...
'soft-reset' applies to the old Prolific USB to parallel converter and to certain Samsung printers (and it looks like at some point we gave up trying to isolate to specific models and always do a soft reset...) If this turns out to be an issue I guess I could add a soft reset on device close, but so far I've had 0 reports of this issue and doing a soft reset typically resets the printer as well which isn't what we want...
delay-close is spread around but is unlikely to apply since the issue had to do with reading back-channel data at the end of a job - again, the PAPPL architecture does things differently and won't have to worry about delaying things outside of the driver.
vendor-class applies to a single receipt printer from EPSON - you'd need to provide your own custom scheme to support this printer with PAPPL (it won't show up otherwise...)
whitelist is used by a single Samsung printer to turn off soft-reset behavior - not needed for PAPPL.
Short of blacklisting the subset of Canon inkjet printers that won't work with PAPPL anyways, I don't see a need to support USB quirks in PAPPL.

I'm planning to package all printer application into Fedora 39 since cups-filters 2.0b and friends are in Fedora 38 already and announce testing round for printer applications during Fedora 39, so hopefully we will get useful feedback on which quirks are still needed. CentOS Stream and RHEL are another stories - this I will handle later unfortunately.

But there isn't a way to suppress the built-in "usb", "socket", and "file" schemes so that users of these applications are unable to specify them.

@michaelrsweet For me this does not look correct. When I create a custom backend (scheme) without having touched (for example listed) the backends/devices before, the built-in schemes of PAPPL are not available. If I want both my own scheme and the built-in schemes I have to list the standard schemes via papplDeviceList(() before I add my own scheme:
https://github.com/OpenPrinting/pappl-retrofit/blob/master/pappl-retrofit/pappl-retrofit.c#L4354

This would mean the following:

If I have a native (not using pappl-retrofit) Printer Application, supporting only printers with Ethernet interface I suppress the USB backend via papplDeviceRemoveScheme("usb:");
If I have a native Printer Application, supporting only printers with USB interface I suppress all the network backends at once via papplDeviceRemoveType(NETWORK);
If I have a retro-fitting (using pappl-retrofit) Printer Application supporting printers with USB quirks I overwrite PAPPL's USB backend by creating my own USB backend with papplDeviceAddScheme(), giving it the scheme name usb:
In general, if I retro-fit CUPS (2.x) backends I create a custom scheme for each individual one, named with the backend's name, giving exactly the same URIs as we had with CUPS (2.x). I do not need to papplDeviceRemoveScheme() the original backend first.
If I only want retro-fitted CUPS backends and independent which ones are actually available, no original PAPPL backends dangling around, I can papplDeviceRemoveScheme() all the original backends, then papplDeviceAddScheme() my CUPS backend retro-fits, independent whether their names have existed as original PAPPL scheme or not.

Am I right with all this?

@tillkamppeter Yes, correct. You could also remove all schemes with papplDeviceRemoveTypes(PAPPL_DEVTYPE_ALL)...
I think most printer applications won't use these APIs, but clearly it would be helpful for the retrofitting applications...

[master 66e6871] Add new papplDeviceRemove APIs and support replacement of device URI schemes (Issue #259)


C++ program to find ones complement of a binary number

💥 Proposal
A C++  program to input binary number from user and find ones complement of binary number using loop.
Example
Input binary number: 01000011
Output Ones complement: 10111100
Have you read the Contributing Guidelines on Pull Requests?
I would like to add the code for one's complement of a binary number. Please /assign this issue to me[GSSOC'21]
(Write your answer here.)
Yes

/assign


There is a vulnerability in Spring Boot  1.5.4.RELEASE ,upgrade recommended

https://github.com/apache/iotdb/blob/64dc16bb7ef26b9acb021d0eca5e6c4ad246a437/grafana/pom.xml#L51-L58
CVE-2017-8046
CVE-2018-1196
CVE-2020-5421
Recommended upgrade version：1.5.15

Thanks, the issue has solved.


Option to disable drift touching certain elements

First of all, i love having the drift addon enabled. Being able to quickly move the char screen if its in front of something, or talents is very handy. The only downside I have found so far is that its not working well with my bags.
Having not Moved or dragged or scaled the bags using Drift, it seems Drift still tries to apply some changes to the bags.
I prefer Elvui/Moveanything to handle my bags, since they move All bags as a whole, instead of seperate bag movement (like drift does).
I would love the option to disable drift touching certain elements (Bags)
The reason why im requesting this Feature is because when Drift is loaded, my bags look different
Below is normal:

And this is what happens when the Drift addon is loaded

The issue doesnt Always appear consistently it feels like it depends on what Order wow loads the addons in (Drift/Elvui/Moveanything) A reload either fixes the issue, or forces it to appear again.
Just in case i might have moved the bags accidently with drift in the past, i have also tried resetting all Drift frames, but this didnt seem to influence the situation.

Hi Wybe, thanks for letting me know about the issue! Drift does have code that modifies bags. This is because WoW has code that constantly resets bag positions, so I had to overwrite that behavior in Drift. The code in Drift emulates the original bag placement but allows for moving and scaling individual bags too.
I haven't checked the ElvUI code, but it sounds like ElvUI also rewrote portions of the bag code. I think you're correct that the two addons are conflicting with each other.
I'm planning to add options to toggle whether Drift modifies particular UI elements. I'll probably add bags first.
-Jared

Thanks for the response! Looking forward to the feature being added :)
Much thanks for adding it to the roadmap, i can understand that as a addon creator you don't want to get caught up too much in modifying your addon because of other addons since that can a bit of an endless rabbit hole.
But thanks for looking into it anyways ! :D

Hi Wybe, I added the ability to disable Drift modifying Bags in the most recent version of the addon. Can you please download the latest version of the addon and then do the following:

Go to Game Menu -> Interface -> AddOns -> Drift -> Options
Uncheck "Bags Enabled"
Click "Okay"

This should remove all interactions Drift has with Bags and reload the interface. Once you've done this, can you let me know if it works for your use case?
Thanks!
-Jared

Hey there!
I have updated the addon, and indeed see that new option.
After unchecking it I indeed no longer have the option to move the bags with the Drift addon,
and it looks like now its using the Elvui bag location correctly!
Before when I opened the issue it was happening sporadically, basically whenever the Drift addon would load before Elvui,
and so far after the update things are looking good and if I run into any issues down the line I will let you know!


[text] Read URL of first texture page from JSON.

The JSON file in an MSDF font should contain the paths of any textures it relies on. Currently those are ignored (https://github.com/aframevr/aframe/pull/3643#discussion_r195370194) and we try to infer the path from the JSON file name. For fonts created with http://msdf-bmfont.donmccurdy.com/, the paths in the JSON are correct but inferred paths are not.
For some of the default fonts, it looks like the JSON contains absolute paths on disk, which clearly won't work — not sure what tool was used to create those, and whether it should be fixed? For now this PR looks for absolute non-HTTP(S) paths and ignores them.

Opened a PR to the wrong repo. 😅
https://github.com/aframevr/aframe/pull/3651


Support the WITH operator (Spdx) in package licenses

A license-exception combination has special semantics and thus should be treated as an atomic unit by the rules. Thus such license-exception tuples should be passed on to the rules engine in
case they are used in the input which is

declared
detected
concluded

...license of any package.

Implemented by #2565.


Add support for iPhone SE Gen 3 & iPad Air Gen 5

New iPhone SE is 14, 6
New iPad Air is 13, 17
per Xcode RC Version 13.3 (13E113)
Would be great to get these added, I think the ship 3/18...
:)
TY in advance!

There should be two different codes for the new 5th gen iPad Air, one for the WiFi model and one for the WiFi+cellular model.
For example, 4th gen iPad Air can be "iPad13,1" and "iPad13,2".

iPad13,17 is most likely Wifi; 13,18 most likely WiFi_Cellular.  Not 100% sure how to map those models in the simulator but that is the historical pattern...

According to several sources online, the new model codes should be:
"iPhone14,6" --> iPhone SE (3rd generation)
"iPad13,16" --> iPad Air (5th generation) Wi-Fi
"iPad13,17" --> iPad Air (5th generation) Wi-Fi + Cellular


Drop userID from isMutedChanged event

What

Breaking change to CallAdapter API
Drops the userId field from isMutedChanged event.

Why

Base Calling event doesn't include the user ID.
The event always triggers for the local user (that's why base SDK doesn't include user ID).
This was the only place where the user ID reported was the one stored in the stateful client context, the one provided by Contoso. In the case of CallComposite, this happens to be the same as the actual ACS ID because it's extracted from the token provided when creating the adapter. This is potentially very confusing because all other instances where a user ID is reported, the ID comes from the ACS services.
Dropping this allows us to stop using the getIdFromToken hack and stop storing the user ID entirely in the adapter state (it's not needed anywhere else).

Profit!
How Tested
rush build
rush test
Process & policy checklist

[x] I have updated the project documentation to reflect my changes if necessary.
[x] I have read the CONTRIBUTING documentation.

Is this a breaking change?

[x] This change causes current functionality to break.

There are 2 places triggers this event, one for local user one for remote user, please also check ParticipantSubcriber.ts to and check the one for remote user
UserID is necessary, because it is the one to distinguish different users including local and remote one

I had seen ParticipantSubscriber but missed that it was trigger the same event.
The string named event emit() calls means that IDEs can't easily help find all the places an event is triggered :( Nor does CI catch the problem in this PR. :'(
My original complaint still stands though. For all the remote participants, the user ID is the one reported from ACS backend. Only when it's the local user, the ID is the one we extracted (and saved in adapter context) from the token. This is confusing / not robust.
Do we really want to treat the two cases: local user was (un)muted and remote user was (un)muted in the same way like this?

I think we should treat local user specially. Contoso likely wants to have very different response to when the local user is muted vs remote is muted.
isLocalScreenSharingActiveChanged is only emitted for local user (and does not include userId). It would be consistent to similarly have isLocalMutedChanged and isMutedChanged (naming discussion below).

We're quite inconsistent in what events refer to local vs. remote vs. both users.

Applies to both local and remote: isMutedChanged.
Special case: videoStreamsUpdated applies only to remote, but there seems to be no way for Contoso to subscribe to this event.

I think we should keep local vs remote events separate:

Only applies to local: isLocalScreenSharingActiveChanged, isLocalMutedChanged.
Only applies to remote: isRemoteSpeakingChanged, remoteDisplayNameChanged, isRemoteMutedChanged, remoteVideoStreamsUpdated (also plumb this one through so Contoso can subscribe to it).

Would like to get some agreement on this before landing any API breaking changes.
@DominikMe @PorterNan

Moved discussion to team thread.
Will create new PR for a broader API change.


exporter CPU metrics f ext-servervice and CPU metrics of nodes that can be reused

exporter CPU metrics f ext-servervice and CPU metrics of nodes that can be reused
What this PR does / why we need it:
exporter CPU metrics f ext-servervice
exporter CPU metrics of nodes that can be reused

A question to discuss:
In the current design, the metric is calculated and exposed every time prometheus pulls. The advantage is the data is newest, the disadvantage is we want cpuStateProvider merge into collector, this method CollectCpuCoresCanBeReused may should be exposed, at the beginning, we just want to use data from collector. And this will increased agent's computational pressure.
If we use calculated data like other metrics, the point will not accurate. For example, prometheus pull period is 10s, the collector collect period is 25s, the point promethues will not be precise and may lost some data point from collector's data.

@shijieqin As much code is merged to the main branch in pr #165 and #196, please do a rebase of the main branch, we will continue the review of this pr after this.

https://github.com/gocrane/crane/pull/223


PDF only renders with the devtools open

Attach (recommended) or Link to PDF file here: https://samsara.ro/wp-content/uploads/2024/05/meniu-bauturi-QR-en-2024-v1-22-19.00.pdf
Configuration:

Web browser and its version: Firefox 126
Operating system and its version: MacOS and Android
PDF.js version: whatever is build-in in Firefox 126
Is a browser extension: No

Steps to reproduce the problem:

Open the PDF: it is blank
Open the devtools: the pdf gets rendered

What is the expected behavior? (add screenshot)
What went wrong? (add screenshot)
https://github.com/mozilla/pdf.js/assets/7000710/c6fe420f-24d0-4b0b-b02d-d42802d818d2
The console shows this error:
Message: CanvasRenderingContext2D.transform: Canvas is already in error state.
Stack: beginDrawing@resource://pdf.js/build/pdf.mjs:6301:16
initializeGraphics@resource://pdf.js/build/pdf.mjs:10837:14
render/<@resource://pdf.js/build/pdf.mjs:9698:26

I believe the devtools-part is a red herring, since just zooming out far enough seems to be enough to "fix" things.

After a certain zoom level (it depends of the screen resolution), the canvas height is too big and its creation just fails.
In all browsers, there are some limitations on the canvas dimensions/area.


Adding support for auto-adding remote related files to .gitignore

Tested with

no .gitignore file
.gitignore file with and without new line at end of file
.gitignore file with similar entries (like ".remotetralala*", ".remote*tralala" and ".remotetralala")

LGTM! Thank you 🥇


Kube-Scheduler Recovery cannot be loaded via tectonic-console

Issue Report Template
Tectonic Version
1.7.3.tectonic.3
Environment
What hardware/cloud provider/hypervisor is being used with Tectonic?
AWS
Expected Behavior
Pod scheduler recovery can only be done via the cli. I have a YAML configured to recover a scheduler, but the yaml throws an error when executing via console. Error states the nodename is declared twice, but when I remove the second occurrence, the recovery scheduler hangs indefinitely, and never creates the pod.
Actual Behavior
Should be runnable via GUI or CLI
Reproduction Steps

have cluster with failed schedulers
create scheduler-recovery
attempt to load yaml (after following CoreOS recovery steps) in tectonic-console

Other Information
`apiVersion: v1
items:

apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
name: kube-scheduler-rescue
namespace: kube-system
spec:
nodeName: ip-xx-x-xx-xxx.ec2.internal
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
pod-anti-affinity: kube-scheduler-1.7.3-tectonic.3
namespaces:
- kube-system
topologyKey: kubernetes.io/hostname
containers:

command:

./hyperkube
scheduler
--leader-elect=true
image: quay.io/coreos/hyperkube:v1.7.3_coreos.0
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10251
scheme: HTTP
initialDelaySeconds: 15
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 15
name: kube-scheduler-rescue
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
nodeName: ip-xx-x-xx-xx.ec2.internal
restartPolicy: Always
schedulerName: default-scheduler
securityContext:
runAsNonRoot: true
runAsUser: 65534
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations:

key: CriticalAddonsOnly
operator: Exists
effect: NoSchedule
key: node-role.kubernetes.io/master
operator: Exists
status: {}
kind: List
metadata: {}
`

Feature Request
Environment
What hardware/cloud provider/hypervisor is being used with Tectonic?
AWS
Desired Feature
Other Information

@zonepalms91 It is likely that this recovery process will remain something that needs to be done via kubectl. The kube-scheduler pods becoming unavailable was mostly due to a configuration that allowed schedulers to all be deployed to the same controller node. There have been measures taken to prevent this in recent releases of Tectonic.


[iOS] Not working when published on TestFlight

The package seems to be not working properly for my app ONLY when I am publishing it on TestFlight (didn't try to publish it to the AppStore).
I've tried to build it in debug and release mode using flutter run --release both on iOS simulator and on a physical iPhone 8 running iOS 14.7.1 and everything was working fine. I've also installed the application on iOS devices from BrowserStack (iPhone 12 with iOS 14 and iPhone 11 with iOS 13) by using the flutter generated .ipa file and it was still working properly but each time I am publishing this very same .ipa on TestFlight I am getting stuck when calling the read() method. To ensure this I've tried publishing an app with and without the secure storage operation and by removing it my loading page navigates to the next screen as intended.
Because it happens only on TestFlight I don't have any error logs, the app is not crashing so it feels like the Future is not completing properly. It does not seems like I got an exception as the dialog which should be displayed when I catch an error is not shown.
Dependency
flutter_secure_storage: ^4.2.1

Implementation
secure_storage_helper.dart
import 'package:flutter/foundation.dart';
import 'package:flutter_secure_storage/flutter_secure_storage.dart';
import 'package:strasApp/helper/shared_prefs_helper.dart';
import 'package:strasApp/util/index_keys.dart';

class SecureStorageHelper {
  static const _storage = FlutterSecureStorage();

  /// This variable is used only when on web mode to clean SharedPreferences
  /// managed by SecureStorageHelper.
  static const _managedKeys = [IndexKeys.tokens];

  static Future<String> getToken() {
    return kIsWeb
        ? SharedPrefsHelper.getString(IndexKeys.tokens, defaultValue: null)
        : _storage.read(key: IndexKeys.tokens);
  }

  static Future deleteToken() => kIsWeb
      ? SharedPrefsHelper.remove(IndexKeys.tokens)
      : _storage.delete(key: IndexKeys.tokens);

  static Future deleteAll() async {
    if (kIsWeb) {
      for (final e in _managedKeys) await SharedPrefsHelper.remove(e);
    } else {
      return _storage.deleteAll();
    }
  }

  static Future saveToken(String token) => kIsWeb
      ? SharedPrefsHelper.setString(IndexKeys.tokens, token)
      : _storage.write(key: IndexKeys.tokens, value: token);
}

The getToken() method is used in my AuthenticationBloc
authentication_bloc.dart
import 'package:rxdart/rxdart.dart';
import 'package:strasApp/bloc/bloc.dart';
import 'package:strasApp/helper/secure_storage_helper.dart';

class AuthenticationBloc implements BlocBase {
  // ...

  final _connectedController = BehaviorSubject<bool>.seeded(false);
  Stream<bool> get onConnectedStateChange => _connectedController.stream;
  bool get isUserConnected => _connectedController.value;

  // ...

  final _refreshTokenController = BehaviorSubject<String>.seeded(null);
  String get refreshToken => _refreshTokenController.value;

  // ...

  Future<bool> checkUserAlreadyConnected([BuildContext context]) async {
    final _token = await SecureStorageHelper.getToken();
    _refreshTokenController.sink.add(_token);

    _connectedController.sink.add(refreshToken != null);
    return isUserConnected;
  }

  // ...
}

This method checkUserAlreadyConnected() is called in my LoadingView to determine if I need to make some authenticated HTTP calls using the token fetched from the secure storage.
loading_view.dart
/// Loading view to call at the begining of the application to make all
/// database operations on first launch and fetch all data.
///
/// This widget should never be navigated to after the launch.
class LoadingView extends StatefulWidget {
  static const routeName = '/loading';

  @override
  State<StatefulWidget> createState() => _LoadingViewState();
}

class _LoadingViewState extends State<LoadingView>
    with SingleTickerProviderStateMixin {
  AuthenticationBloc _authenticationBloc;

  Future<void> _loadAll() async {
    try {
      // ...

      List<Future> _futures = [
        // Non authenticated HTTP calls
      ];

      // ...

      _futures.add(_authenticationBloc.checkUserAlreadyConnected(context));

      // Execute all asynchronous operations saved
      final results = await Future.wait(_futures);

      // ...

      final connected = results.last as bool;
      if (connected) {
        await _authenticationBloc.refreshAuthentication();
        await fetchAuthenticatedUserData(context);
      }

      // ...
    } catch (e) {
      print(e.toString());
      showDialog(
        context: context,
        builder: (_) => AlertDialog(
          title: Text('Error'),
          content: Text(e.toString()),
        ),
      );
    }
  }

  @override
  void initState() {
    super.initState();
    _authenticationBloc = BlocProvider.of<AuthenticationBloc>(context);

    final stopwatch = Stopwatch()..start();
    _loadAll().then((_) {
      stopwatch.stop();
      print('Operations executed in ${stopwatch.elapsed}');
      setState(() => _visible = !_visible);
      _controller.forward();
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Container(
        alignment: Alignment.center,
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.center,
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Container(
                child: const CustomProgressIndicator(),
                height: 76.0,
                width: 76.0,
             ),
          ],
        ),
      ),
    );
  }
}

Hi,
I discovered this bug yesterday, when publishing on TestFlight too, after multiple research, it doesn't work on profile mode too and I get this error:
WARNING: 'dart.core_ArgumentError_toString (kind RegularFunction)' is accessed through Dart C API without being marked as an entry point; its tree-shaken signature cannot be verified. WARNING: See https://github.com/dart-lang/sdk/blob/master/runtime/docs/compiler/aot/entry_point_pragma.md [tcp] tcp_input [C2.1:3] flags=[R] seq=207096974, ack=0, win=0 state=LAST_ACK rcv_nxt=207096974, snd_una=2751652398
The only way I got this error on the log was when using the profile mode on the VScode debugger

@ZacharieAzoulai which version are you using?
Can someone check if this issue is also present on 5.0.0-beta.3?
This almost seems as a Flutter error rather than a package issue.

@juliansteenbakker  I'm on 4.2.0

@juliansteenbakker I tried with another package Flutter_keychain and I still have this issue so it's more likely to be a flutter related issue...

Then which version of flutter did you use to build your application ?

I'm on flutter 2.2.3
After other hours of testing and fighting with my code, it turns out that -for me- it's not the flutter secure storage which gives me this error but the fast_rsa package,I don't know if you use it too
Sorry for my error, maybe it's the same error for you too ?

No unfortunately I'm not using this package. And I am using flutter 2.3 so if it is an issue with flutter it has not been fixed with the latest release.

Unfortunately I am not using this package, as I've said in my initial post I've confirmed by removing completely flutter_secure_storage that it was when I was calling the read method that my Future wasn't completing.
Here's  flutter doctor -v for further informations:
[✓] Flutter (Channel stable, 2.2.3, on macOS 11.5.1 20G80 darwin-x64, locale fr-FR)
    • Flutter version 2.2.3 at /usr/local/share/flutter
    • Framework revision f4abaa0735 (7 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /usr/local/share/android-sdk
    • Platform android-30, build-tools 29.0.2
    • ANDROID_HOME = /usr/local/share/android-sdk
    • ANDROID_SDK_ROOT = /usr/local/share/android-sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.4, Build version 12D4e
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)

[✓] IntelliJ IDEA Ultimate Edition (version 2018.3.5)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.59.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.18.1

[✓] Connected device (2 available)
    • IN2010 (mobile) • 52200b7c • android-arm64  • Android 11 (API 30)
    • Chrome (web)    • chrome   • web-javascript • Google Chrome 92.0.4515.159

• No issues found!

With version 5.0.0 improvements have been published. Please try again and comment if problem still exists


Hawk-Eye Innovations

Is there any plan to add Hawk-Eye Innovations tracking data?

I'm not aware of anyone planning to add support for Hawk-Eye but a deserializer for Hawk-Eye tracking data would certainly be welcome.

I have an implementation at https://github.com/probberechts/kloppy/tree/feat/hawkeye. I didn't create a PR yet because I only did some very limited testing on a single game, but it should be functional. Below is an example of how to use the API:
from pathlib import Path
from kloppy import hawkeye

hawkey_data_dir = Path(...)
season_id = 2024
league_id = 2
match_id = 1234
period_id = "*"
minute_id = "*"

# Load the 2D tracking data of the ball and the player centroids.
data_tracking = hawkeye.load(
    ball_feeds=sorted(hawkey_data_dir.glob(f'{season_id}_{league_id}_{match_id}_{period_id}_{minute_id}.football.samples.ball.gz')),
    player_centroid_feeds=sorted(hawkey_data_dir.glob(f'{season_id}_{league_id}_{match_id}_{period_id}_{minute_id}.football.samples.centroids.gz')),
    show_progress=True
)

# Loading the complete joint tracking data for a full game will probably require too much memory.
# There are two options.

# The first option is to load the data in batches.
# For example, to load all joint tracking data for the first minute of the game
data_joints = hawkeye.load(
    ball_feeds=[hawkey_data_dir / 'f'{season_id}_{league_id}_{match_id}_1_1.football.samples.ball.gz'],
    player_centroid_feeds=[hawkey_data_dir / f'{season_id}_{league_id}_{match_id}_1_1.football.samples.centroids.gz'],
    player_joint_feeds=[hawkey_data_dir / f'{season_id}_{league_id}_{match_id}_1_1.football.samples.joints.gz'],
    show_progress=False
)

# The second option is to load joint data only for a subset of tracking frames and or players.
# This can be configured by providing a function.

def load_joint_data(frame, player):
    # only load joint data for a specific player
    is_player = player.jersey_no == 20
    # only load joint data for frames where the ball is closer than 2m to this player
    ball_close = frame.players_data[player].coordinates.distance_to(frame.ball_coordinates) < 2
    return is_player and ball_close

data_joints = hawkeye.load(
    ball_feeds=sorted(hawkey_data_dir.glob('f'{season_id}_{league_id}_{match_id}_{period_id}_{minute_id}.football.samples.ball.gz')),
    player_centroid_feeds=sorted(hawkey_data_dir.glob(f'{season_id}_{league_id}_{match_id}_{period_id}_{minute_id}.football.samples.centroids.gz')),
    player_joint_feeds=sorted(hawkey_data_dir.glob(f'{season_id}_{league_id}_{match_id}_{period_id}_{minute_id}.football.samples.joints.gz')),
    load_joint_data=load_joint_data,
    show_progress=True
)

Sorry for asking such a basic question, but how do I access the reference ‘from kloppy import hawkeye’?
The link doesn't seem to work and in the version of kloppy I have installed, it's not possible to import ‘hawkeye’.

What do you mean by "The link doesn't seem to work"? Do you (1) get a 404 (try again, I guess; it might have been a server problem at GitHub), (2) do not have access permissions (that would be strange; I'm sure the fork is public) or (3) do not know how to install the library from a fork?
The most straightforward method to install it is through pip with:
pip install "git+https://github.com/probberechts/kloppy@feat/hawkeye"

or in editable mode (allows you to make changes to the code) with:
pip install -e "git+https://github.com/probberechts/kloppy@feat/hawkeye#egg=kloppy"


Annotation processing for generating entities parsers and serializers

Should be nice

Take a look at Square's JavaPoet http://corner.squareup.com/2015/01/javapoet.html

Decided to implement this as standalone library in possible future


Support job execution api part 2

Support the more advanced endpoints

[ ] Execution Output
[ ] Execution output with state

Is there any date when this will be implemented?


npm run build issue

I created a new library using this generator, and then after adding my code and running npm run build, an error occurred. To fix it, go to the gulpfile and then to the rollup:umd task and  change moduleName to name. That takes the error right away.
There's also a notice of deprecation for having "entry" in that same task instead of "input". But it'll still run with entry.
I would do this by myself, and submit the PR, but I don't know if others are running into the same issue.

@plambhsa Yes i'm running into the same issue.

@plambhsa Thank you, version 11.4.0 has been released with a fix (see #190) 👍


Feature: tame data consumption in a better way

If videos are not cached, this screensaver streams enormous files over network. Imagine you are traveling, getting your internet via tethering / personal hotspot and suddenly screen saver turned on your laptop - it can it up hundreds of megabytes/gigabytes of data before you realize it. That is dangerous.
There should be an option to disable streaming videos unless you are on wifi (non-hotspot one).
Yes you can cache videos, but - most people may not realize they have to.  It should be possible to only download select ones (just like you can select which ones you want to play).

Side note related to this issue, there is also an issue with cached videos still making network requests (as mentioned in this issue https://github.com/JohnCoates/Aerial/issues/512#issuecomment-426009013).
I do have a workaround for that one. Working on a "Never stream videos" options right now.

There are third-party utilities designed to trim data consumption. A temporary workaround might be to install something like TripMode which I use personally for this purpose.

Closing as fixed with v1.4, there are now options to block streaming and full offline mode


Adds exponential backoff to MQTT

@lesv Yes, in HTTP I was able to reuse the retry that is in Apiary, because this device example is using MQTT and a the PAHO client, it's a little more custom / verbose.


feat(core): add more variables

Signed-off-by: Felipe Zipitria<EMAIL_ADDRESS>Adds additional variables:

SecDefaultAction for phase 1 and phase 2.
SecAuditLogParts
SecTmpSaveUploadedFiles

Also, variables are sorted now.

@franbuehler Need your review here also.

Until when do we need an approval here?
I would like to test it with a local docker build.

For sure, let me know!


sent to unknown address that i never copied or pasted?

i copied an address i received through an sms on my iphone to copay to send a transaction, but for some reason that i can't quite fathom, it was sent to some other random address that i've never seen before. how could something like this possibly happen?

also of note: it says in the wallet "sent to bitcoin" instead of just "sent." what does this mean?


add < keycode

add missing keycode 60

👌 Thank you good sir!

That was awesome! Thanks for helping out :v:


Add wasm support

Currently this library (and async-executor) crashes on wasm due to missing std::time. This replaces it with cross-platform library instant.
Note that instant library could be used by default on all targets, but I added it for wasm32 only as it cuts dependency count on native targets.

Published v1.4.0.


Bug: input_shape error for advanced activations

I just updated Keras and my code stopped functioning due to the error:
Exception: Layer is not connected. Did you forget to set "input_shape"?
Note that my code was running minutes ago before updating Keras. After trying a lot, I found out that by replacing all LeakyReLU() by 'relu', the error gets resolved. So, I reproduced this issue on the mnist_cnn.py script in Keras Examples folder. Even more bizarre phenomena is that if you put some random input_shape values, you will be able to get the code compiled. If this was not the case, it would have been at least acceptable, since for each activation layer, user is forced to calculate the correct input shape. However, now this behavior is susceptible to user errors.
Script to reproduce the issue:
from __future__ import print_function
import numpy as np
np.random.seed(1337)  # for reproducibility

from keras.datasets import mnist
from keras.models import Sequential
from keras.layers.core import Dense, Dropout, Activation, Flatten
from keras.layers.convolutional import Convolution2D, MaxPooling2D
from keras.utils import np_utils

batch_size = 128
nb_classes = 10
nb_epoch = 12

# input image dimensions
img_rows, img_cols = 28, 28
# number of convolutional filters to use
nb_filters = 32
# size of pooling area for max pooling
nb_pool = 2
# convolution kernel size
nb_conv = 3

# the data, shuffled and split between train and test sets
(X_train, y_train), (X_test, y_test) = mnist.load_data()

X_train = X_train.reshape(X_train.shape[0], 1, img_rows, img_cols)
X_test = X_test.reshape(X_test.shape[0], 1, img_rows, img_cols)
X_train = X_train.astype('float32')
X_test = X_test.astype('float32')
X_train /= 255
X_test /= 255
print('X_train shape:', X_train.shape)
print(X_train.shape[0], 'train samples')
print(X_test.shape[0], 'test samples')

# convert class vectors to binary class matrices
Y_train = np_utils.to_categorical(y_train, nb_classes)
Y_test = np_utils.to_categorical(y_test, nb_classes)

model = Sequential()

model.add(Convolution2D(nb_filters, nb_conv, nb_conv,
                        border_mode='valid',
                        input_shape=(1, img_rows, img_cols)))
model.add(Activation(LeakyReLU()))
model.add(Convolution2D(nb_filters, nb_conv, nb_conv))
model.add(Activation(LeakyReLU()))
model.add(MaxPooling2D(pool_size=(nb_pool, nb_pool)))
model.add(Dropout(0.25))

model.add(Flatten())
model.add(Dense(128))
model.add(Activation(LeakyReLU()))
model.add(Dropout(0.5))
model.add(Dense(nb_classes))
model.add(Activation('softmax'))

model.compile(loss='categorical_crossentropy', optimizer='adadelta')

model.fit(X_train, Y_train, batch_size=batch_size, nb_epoch=nb_epoch,
          show_accuracy=True, verbose=1, validation_data=(X_test, Y_test))
score = model.evaluate(X_test, Y_test, show_accuracy=True, verbose=0)
print('Test score:', score[0])
print('Test accuracy:', score[1])

To make the above script work(?), replace LeakyReLU() by LeakyReLU(input_shape=(20,20,20)). Its quite obvious that these numbers (20, 20, 20) are random and code works as long as you put some value.
I think this is a serious bug and should be addressed as soon as possible. @fchollet

Ok. I just found a safer way (hack?). Just replace all LeakyReLU() by LeakyReLU(input_shape=()). It makes me think if this is an expected behavior, if so, I didn't see it anywhere mentioned in the documentation.


date_format validation rule behaving as if required

The date_format and after (probably before as well) validation rules are all behaving as if they are required.
If you pass in a null value, then all of these rules fail. In 5.2 they would pass.
They should pass in my opinion; if you want to disallow null values then you should also have the required rule.

null isn't an accepted value anymore, if you want a field to be nullable you need to pass the nullable rule.
['date' => 'nullable|after:2016-09-05']

Thanks, I missed that, my fault.

No worries :)


Add pyupgrade hook

As describe in #757, this hook will automatically upgrade syntax for newer versions of the language.
I also run pre-commit autoupdate to updates the hooks (maybe add pre-coomit ci to help on this?)

What do you think to add this to ensure these type annotations on all files?
hooks:
  - id: reorder-python-imports
    args: [--py38-plus, --add-import, 'from __future__ import annotations']


Attributes and dictionaries

Sorry, this is a bit of monster (especially as I had to change most of AST).
This is the controversial change I've been working towards:
After this:

Instances (including modules) use real dictionaries for their attributes.
Classes keep their attributes in a hidden PyAttributes.

We should create fewer dictionaries generally.

This work looks go to me, do you wish other reviewers to have a look at it?


Short $Plate from IS_NPL and IS_CPR packets is parsed incorrectly?

If I set my car's plate to "d" in LFS, and I leave the pits, in the NPL packet, the following is outputted:
"d  00000" - d + [space] + [space] + 0 + 0 + 0 + 0 (8 chars as supposed, but the spaces and zeros should be not parsed)
If I set my car's plate to "dd" in LFS, I get this:
"dd 00000" - d + d + [space] + 0 + 0 + 0 + 0 (also 8 chars as supposed, but spaces and zeros shouldn't be parsed)
But if I set my car's plate to "dddddddd" (full 8 chars used), I get:
"dddddddd" as I'm supposed to.
The same results happen in the IS_CPR and IS_NPL packet :(

I have a strange feeling that this bug has been reported before. It's probably just a miss typed null spaced string type that I used for the unpack function type. I don't call trim at any point, on any string that I parse, because I expect the packet to be well formed by the LFS engine. Either way, I'll get to the bottom of this.

Should be fixed by the following commit f5df1a9806.

Thanks for the fix! It was driving me crazy in my plugin when I compared the plate from the IS_NPL packet with my own stored plate in the database and they didn't match!


Breaks under large grid

Nodal linear solves tend to break (fail to converge) when the grid becomes large.

This is due to the use of tilebox while iterating outside of the box boundaries. Current fix is to replace tilebox with validbox - longterm fix is to replace with the ghost-cell-including validbox.

This issue has been fixed by enabling the multigrid solver.


Allow kicking player who is not connected to chat [moderation]

Currently as a moderator you can only kick players from the game/lobby who are connected to chat, ie. you need to be able to right click on their name.
We need a similar function as in the py client where you can either type the name of the player directly, or search for players connected to the actual lobby server and kick them that way.

Yes, please do: there is a large number of "game freezes" at the start where one player gets stuck at the "Waiting for Players to Connect" screen and the other is already in the game.
See replay: https://replay.faforever.com/16389827
This is what Cast_Away saw:

And this is what I saw:

Often the issue is recognized by the player who could not connect, they leave, but in this case a player refused to leave. The game counts as a loss for whoever leaves so it should likely get some attention from a moderator. I think the player who fails to connect should accept the loss here as it is not fair to the person who did not cause the issue.

Fixed in #2418


DWEB-10 update rollbar sdk

What does this PR do?
Updated rollbar sdk to 2.13.0
Are there breaking changes in this PR?
No.
Any background context you want to provide?
NA
Is there parity with the server-side/android/iOS integration components (if applicable)?
NA
Does this require a new integration setting? If so, please explain how the new setting works
No.
Links to helpful docs and other external resources
https://docs.rollbar.com/docs/rollbarjs-configuration-reference

I've already submitted the PR for this change. Thanks!

Thanks @CarlosMecha, Closing this PR


Combination of flattened internally-tagged enum and deny_unknown_fields results in unsatisfiable requirements

I think it is best explained by a bit of code:
#[macro_use]
extern crate serde_derive;
extern crate serde; // 1.0.70
extern crate serde_json; // 1.0.24

#[derive(Deserialize, Debug)]
#[serde(tag = "type")]
enum Y {
    A {
        x: i32,
    },
    B,
}

#[derive(Deserialize, Debug)]
#[serde(deny_unknown_fields)]
struct X {
    #[serde(flatten)]
    y: Y,
    z: Option<i32>,
}

fn main() {
    let x: X = serde_json::from_str(r#"{"type": "A", "x": 32 }"#).unwrap();
    println!("{:?}", x);
}

This panics with „unknown field type“. If the field type is removed, it complains that type is missing (that feels like it can't make its mind if it wants type or not).
If the deny_unknown_fields on the X struct is removed, it is willing to parse it.

I've also got this issue.
I don't know much about serde's implementation, but maybe it wouldn't be too difficult to implement it like this:
 #[derive(Deserialize, Debug)]
-#[serde(tag = "type")]
+#[serde(untagged)]
 enum Y {
     A {
         x: i32,
     },
     B,
 }

 #[derive(Deserialize, Debug)]
 #[serde(deny_unknown_fields)]
 struct X {
-    #[serde(flatten)]
+    #[serde(flatten_with_tag = "type")]
     y: Y,
     z: Option<i32>,
 }

Where the flatten_with_tag is a combination of flatten, and inserting a new discriminator field "type".

Is there any workaround to this or a way to implement Deserialize manually to work around it?
EG:
#[derive(Deserialize)]
struct EnumName {
    A,
    B,
}
#[derive(Deserialize)]
#[serde(untagged)]
struct EnumValue {
    A(AData),
    B(BData),
}
struct Enum {
    name: EnumName,
    #[serde(flatten)]
    value: EnumValue
}

impl Deserialie for Enum {
    // ...
}
struct MyOutermostStruct {
    other_field_1: &str,
    #[serde(flatten)]
    some_field: Enum,
    other_field_2: u64,
}

Been looking into this, but I don't understand implementing Deserialize well enough to know what the proper way to do this would be.
And yeah, in the case I'm dealing with the enum data fields are flattened into the outer structure, as well as it being internally tagged.

An update, you can do this with a lot of boilerplate using:
#[serde(try_from = "...", into = "...")]

Then having a wrapper which mirrors the struct, but also contains a field to discriminate the variant.
Like this:
#[derive(Serialize, Deserialize)]
#[serde(deny_unknown_fields)]
pub struct FooWrapper<'a> {
    #[serde(rename = "C")]
    example: i32,
    #[serde(rename = "A?")]
    enum_value_variant: &'a str,
    #[serde(flatten)]
    enum_value: FooEnum,
}
impl<'a> std::convert::TryFrom<FooWrapper<'a>> for Foo {
    type Error = String;
    fn try_from(that: FooWrapper<'a>) -> Result<Self, Self::Error> {
        let FooWrapper { example, enum_value, enum_value_variant } = that;
        if enum_value_variant != enum_value.variant() {
            return Err(format!("Mismatched variant, expecting '{}', got '{}'", enum_value_variant, enum_value.variant()));
        }
        Ok(Self { example, enum_value })
    }
}
impl<'a> From<Foo> for FooWrapper<'a> {
    fn from(that: Foo) -> Self {
        let Foo { example, enum_value } = that;
        let enum_value_variant = enum_value.variant();
        FooWrapper { example, enum_value, enum_value_variant }
    }
}

Where variant returns an identifier for each variant on the enum. The wrapper has a lifetime because I just used a &'a str.
I imagine this could all be done with derive macros, and more efficient reuse of the existing EnumAccess implementation rather than needing a separate variant method.
It fails appropriately when unknown fields are encountered, because the enum is externally tagged, which is unambiguous.

The problem is there that deserialization of internally tagged enums does not consume fields from intermediate storage to which they was collected (it uses ContentDeserializer which does not consume data), so mostly this is duplicate of #2200.


Duplicated key when groupby -> apply is used

Hello, I opened this thread in SO, but viewing other issues reported here ([1], [2]), I'm suspecting that this could also be a bug.
I'm not sure if I'm missing something about the groupby - apply when moving from pandas to koalas, but the only requirement that we have is that the function to be applied cannot be type annotated since it will be used in different contexts, with different dataframes, so we don't know all the columns in advance. We're aware that koalas must run the function to infer the schema before applying the function, and we're ok with that overhead

Hi again, I encountered this closed issue in pandas, it seems that the grouping column is kept when one performs apply, and it is explicitly tested for (so it's a feature of pandas)
The problem arises then koala's apply has to infer the schema, runs the pandas groupby - apply and then initiates a koalas.DataFrame with the result (that after groupby-apply has index and a column with the same name):
def apply(self, func):
    ...
    if should_infer_schema:
        # Here we execute with the first 1000 to get the return type.
        limit = get_option("compute.shortcut_limit")
        pdf = self._kdf.head(limit)._to_internal_pandas()
        pdf = pdf.groupby(input_groupnames).apply(func)  # <- pandas apply receive the key as column and index
        kdf = DataFrame(pdf) #  <- ValueError: cannot insert "key", already exists
        return_schema = kdf._sdf.drop(*HIDDEN_COLUMNS).schema

for now I can drop the key column inside func, I'm not sure if koalas should handle the logic for deduplicating index/column names before the initialization of ks.DataFrame

Thanks for reporting the issue & detailed investigation 👍
I think we should handle this logic and add the test explicitly like pandas.
@ueshin , @HyukjinKwon , WDYT about this?

@ueshin , @HyukjinKwon
For saving your time, the summary of this issue is like the below.

in pandas.

>>> df.groupby('d').sum()
        v
d
1.0   6.0
2.0  15.0

>>> df.groupby('d').apply(sum)
       d     v
d
1.0  3.0   6.0
2.0  6.0  15.0

but in koalas

>>> ks.from_pandas(df).groupby('d').sum()
        v
d
1.0   6.0
2.0  15.0

>>> ks.from_pandas(df).groupby('d').apply(sum)
...
ValueError: cannot insert d, already exists

Thanks, yeah. It would be great to fix to match at this moment.
In Spark, it supports the duplicated columns in some contexts. In some contexts, it doesn't.
So, we're thinking about disallowing duplicated column & index names in general as described in the best practice due to the limitation of Spark.

@itholic I would love to submit a PR for this, I'll give it a try during this weekend

@syonekura Sure, let's try :smile_cat:


Misleading doc string in JSON media handler

Looks like the JSON media handler's doc string ("""Handler built using Python's :py:mod:`json` module.""") is incorrect since falcon.util.json could be ujson.
Looks like it became incorrect in 24d51a4808e72d14108d61c2a089158cb6757435.

Good catch, we'll get that fixed!


actuate leverages set_current_values instead of set_target_values

Most probably copy paste error. Just to keep track of it

https://github.com/eclipse-kuksa/kuksa-databroker/pull/70


Allow global access to dashboard by default

When using interfaces like infiniband it's often the case that one can't get the dashboard to show up.  This is because the bokeh server is expecting to be called by its IP address on the infiniband network, not the normal network.
One solution to this  would be to provide services={('bokeh', ('', 8787)): BokehScheduler} to LocalCluster.

Interesting, I do seem to remember to have bumped into this problem ...

Hmmm I think I got something like you suggested working, but the _repr_html_ is not showing the right port for some reason ...

Just to put a bit more context, here is my diff (I hard-code the BokehScheduler port to 12345):
diff --git a/dask_jobqueue/core.py b/dask_jobqueue/core.py
index ab4b602..9bc467e 100644
--- a/dask_jobqueue/core.py
+++ b/dask_jobqueue/core.py
@@ -9,6 +9,7 @@ import warnings
 import dask
 import docrep
 from distributed import LocalCluster
+from distributed.bokeh.scheduler import BokehScheduler
 from distributed.deploy import Cluster
 from distributed.utils import (get_ip_interface, ignoring, parse_bytes, tmpfile,
                                format_bytes)
@@ -153,7 +154,8 @@ class JobQueueCluster(Cluster):
         else:
             host = socket.gethostname()

-        self.local_cluster = LocalCluster(n_workers=0, ip=host, **kwargs)
+        self.local_cluster = LocalCluster(n_workers=0, ip=host,
+                                          services={('bokeh', ('', 12345)): BokehScheduler}, *kwargs)

         # Keep information on process, cores, and memory, for use in subclasses
         self.worker_memory = parse_bytes(memory)

I run this ssh proxy (redirecting the 12345 port to 9898 locally):
ssh -N lesteve@sequoia -L 9898:sequoia:12345 # dashboard

and then I can access the dashboard at http://localhost:9898/status.
The widget for client.cluster shows the dashboard at 8787 though:
Dashboard: http://<IP_ADDRESS>:8787/status

I made sure I had the latest release of dask (0.18.1) and distributed (1.22).

Indeed.  It looks like this is broken in dask/distributed.  We just do a hard overwrite of the bokeh key:
https://github.com/dask/distributed/blob/fd8ca5ebc3a781d5f6625d3daa4d09ce806938a3/distributed/deploy/local.py#L119-L127

Don't you think this modification should be done upstream in distributed? Always bind bokeh UI to all network address by default?

That would make things simpler, yes, but I think that we don't want to do
it in the true LocalCluster case, where we expect to be on the localhost
and would be confused if someone else connected to our machine and wanted
to see our dashboard.
The fact that our cluster objects use LocalCluster is a bit of a historical
artifact.  Ideally they would create a scheduler manually with all of their
own options.
On Sun, Jul 15, 2018 at 6:32 AM, Guillaume EB<EMAIL_ADDRESS>wrote:

Don't you think this modification should be done upstream in distributed?
Always bind bokeh UI to all network address by default?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/90#issuecomment-405084967,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszEds3YlOsQf6q5kGiJzDYpij1qmfks5uGyg2gaJpZM4VLb_x
.

and would be confused if someone else connected to our machine and wanted to see our dashboard.

Would we? Would that be happening a lot?

The fact that our cluster objects use LocalCluster is a bit of a historical artifact. Ideally they would create a scheduler manually with all of their own options.

Should we do that? Or maybe implement some more generic superclass to LocalCluster upstream, that we can reuse here?

Perhaps.  I haven't investigated this enough to know what the right
approach is.  If someone wants to make progress on this they might look at
all of the modifications that LocalCluster does when starting up a
scheduler and write those up so that it can help inform discussion.  I
suspect that we might be able to put some of that logic into the Scheduler
constructor itself, or perhaps some other class as you suggest.  I suspect
that there will be some balance between making Scheduler construction fully
featured and keeping it lightweight.
On Wed, Aug 1, 2018 at 7:27 AM, Guillaume EB<EMAIL_ADDRESS>wrote:

and would be confused if someone else connected to our machine and wanted
to see our dashboard.
Would we? Would that be happening a lot?
The fact that our cluster objects use LocalCluster is a bit of a
historical artifact. Ideally they would create a scheduler manually with
all of their own options.
Should we do that? Or maybe implement some more generic superclass to
LocalCluster upstream, that we can reuse here?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/90#issuecomment-409543305,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszOdcw5okFAmShvm1bcS_tCNiurggks5uMZCkgaJpZM4VLb_x
.

This feature is important for being able to use Dask easily with infiniband, and to make sure it works with nbserverproxy.
I observed the same problem as @lesteve trying its diff, the other way around though (specifing 8787, having some random port displayed, but dashboard up on 8787), but I assume it is the same issue.
Current solution is not really elegant though, it is more of a hack. Ideally, I would prefer to have at least a kwargs in LocalCluster, so we can call something like:
self.local_cluster = LocalCluster(n_workers=0, ip=host, dashboard_bind_ip='<IP_ADDRESS>', **kwargs)

What do you think about that?

Another solution, that does not need modification to LocalCluster, is to just use ip='' parameter when launching LocalCluster. From what I understant looking at dask distributed sources, it will bind all services (scheduler too), to listen to all interfaces.
Do someone believe that this is a problem ?
With #107, we can easily do this:
cluster = PBSCluster( ... , interface='ib0', ip='')

But we could also make it by default directly in core.py:
        # Find the IP address and (if requested) set interface for workers
        localhost_kwargs = {}
        if interface:
            localhost_kwargs['ip'] = get_ip_interface(interface)
            extra += ' --interface  %s ' % interface
        else:
            localhost_kwargs['ip'] = ''

Or just drop #107, because binding on '' by default should solve it...
Any thoughts?

So @mrocklin, once #107 is in (I believe we should keep it, to give the choice to the user to not bind on all interfaces if he wants), is this okay for you if I propose another PR wich sets LocalCluster ip = '' by default ?
This will probably remove some lines from the one added in #107, as this default will get set no matter if interface is provided or not. I prefer to do this in another PR to keep things clear.

The common case use of LocalCluster is for local machines.  It should
continue to respond only to localhost or <IP_ADDRESS> by default for these
cases.  Otherwise we open up all dask users to having their machines stolen.
Recall that Dask opens up a connection that other people can connect to to
run arbitrary Python code.  Having the required address for the TCP server
remain localhost is a very useful way to provide some level of security.
This is the same as with other applications, like Jupyter.
On Tue, Aug 7, 2018 at 8:37 AM, Guillaume EB<EMAIL_ADDRESS>wrote:

So @mrocklin https://github.com/mrocklin, once #107
https://github.com/dask/dask-jobqueue/pull/107 is in (I believe we
should keep it, to give the choice to the user to not bind on all
interfaces if he wants), is this okay for you if I propose another PR wich
sets LocalCluster ip = '' by default ?
This will probably remove some lines from the one added in #107
https://github.com/dask/dask-jobqueue/pull/107, as this default will
get set no matter if interface is provided or not. I prefer to do this in
another PR to keep things clear.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/90#issuecomment-411041141,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszGgjnWh5xWhD_8gqvYELsKWHFbhpks5uOYoLgaJpZM4VLb_x
.

I agree with that, but I'm not sure that my proposal was clear enough. I just want to do the modifications in dask-jobqueue core.py file, when initializing LocalCluster here. Replace the defaults socket.gethostname() and get_ip_interface(interface) by ''.

Ah, sorry.  I thought that you were referring to the default in the
LocalCluster class itself
On Tue, Aug 7, 2018 at 8:46 AM, Guillaume EB<EMAIL_ADDRESS>wrote:

I agree with that, but I'm not sure that my proposal was clear enough. I
just want to do the modifications in dask-jobqueue core.py file, when
initializing LocalCluster here. Replace the defaults socket.gethostname()
and get_ip_interface(interface) by ''.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/90#issuecomment-411043632,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszBf0gjJsnxBcQAdEku3G5UEnb9p0ks5uOYw6gaJpZM4VLb_x
.


Add support for tokens retrieval from Transaction Service datasource

Closes #166
This PR adds support for tokens retrieval from Transaction Service datasource.
It implements both per-address and paginated retrieval. Depending on the outcome of #177 and related discussions regarding the tokens strategy, one of this functions could be deleted and the repository code will be written accordingly when implementing the route.

Coverage decreased (-1.06%) to 86.529% when pulling 7d55c3ad2f1237f73de637cf9f7562507f1704ac on 166-add-support-for-v1tokens into f46ee2afffe1b0a8f1414c7e8e0318c204cc0fc7 on main.

Coverage decreased (-1.06%) to 86.529% when pulling 7d55c3ad2f1237f73de637cf9f7562507f1704ac on 166-add-support-for-v1tokens into f46ee2afffe1b0a8f1414c7e8e0318c204cc0fc7 on main.


feature specification

This issue is for all of us. To specify features, I think we'll use a language called gherkin. That pages loads very slow but it provides a good introduction to gherkin. It's very precise and easy to use and worth the time learning it. Hope you'll enjoy it!

I started reading through the page you posted the link to, and then I stopped because it seems too complicated for what I want.  It's fine if you developers want to use it, but I just want to be able to write descriptions of what I want for the site in English and not have to use particular code words or whatever this gherkin thing is.

I updated one section of the roadmap wiki to give an example of what I want to have happen for the "rescue" portion of the site.  Also so you can see why I think using gherkin would not be good for me.

Sorry to hear that. In this case, I'll submit feature requests based on what I understand about your requirement. I think you'll get familiar with it very soon after seeing a few issues, which I'll submit soon. Actually Gherkin is very friendly and supposed to be bridge the gap between tech and non-technical world.


Examples

Hey the idea for the plugin looks really interesting, but I can't understand how to use :sweat_smile:. Could you add some very simple examples for each keyword (partial, pointer) to the README? The instanceOf explanation is good, just the partial and pointer examples could be simplified. Maybe a simple real world example would help?

I approved your plugin now so it should be available in the plugin marketplace :1st_place_medal:. I recommend joining the RemNote discord channel so you can announce your plugin: https://bit.ly/RemNoteDiscord

I have a better depiction(maybe) about the whole system

Thanks that's great!


add redirect codes to lb target group health check

Add commonly used redirect codes to health check

There are many circumstances that a healthcheck on / (root) would need redirect to be detected as a healthy state.

Hmm, I'm not too sure I agree with health checks including redirects, but I'm also not sure how much I care. I've done it out of laziness or to bandaid stuff before but I don't know if I want to encode it as a best practice. IMO if your / route is going to return a 3xx, you should create an explicit health check route that WILL return a 200. You can get 3xx responses from all sorts of stuff that's not actually a healthy app. You guys feel strongly about this one?

I'm fine with that. If we want our methodology to ONLY allow 200's in the future and just standardize a standard health check route into our apis that guarantees a 200 on healthy state then we'll do that.


Corrected some file paths and fixed some broken formatting in code blocks.

When we actually built the compile environment, we found the following problem.
These have been corrected.

There was a description error in the compiler and debugger file paths.
The include path required to build "HelloWorld" was missing.
Some parts were not recognized as code blocks and were formatted incorrectly.

Thanks for contributing!


Replace default waiting durations

Currently, we're waiting ~9 seconds for our new topic to be persisted to a mirror node, allowing us to successfully create a subscription to that topic. We should replace this with a try/catch block on an interval (2-3 seconds could make sense?), with a maximum # of retries.

Accidentally duplicated due to GitHub being down (?) or inconsistent. See #7


💥Feat: Debit Card Payment Method Integration

Related Issue
“None”
Fixes:  #4267
Description
This PR integrates Debit Card payment method to provide users with a seamless checkout experience.
Changes:

Added Debit Card payment form with card number, expiration date, CVV, and cardholder name fields
Integrated payment gateway (Stripe) for secure payment processing
Implemented error handling and validation for incorrect or expired card information

Related Issues:
Fixes #4267
Type of PR

[x] Feature enhancement

Screenshots / videos (if applicable)
https://github.com/user-attachments/assets/0c17433d-9248-43c8-80d3-95b37e2318f9
Checklist:

[x] I have made this change from my own.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

@anuragverma108 please review it and merge it under gssoc level 3 label. Would you like to proceed with the next payment method integration (e.g., UPI, COD, Credit Card)?

@abhi03ruchi thank you 😊 . Would you like to proceed with the next payment method integration (e.g., UPI, COD, Credit Card)?

@anuragverma108 please review it and merge it under gssoc level 3 label. Would you like to proceed with the next payment method integration (e.g., UPI, COD, Credit Card)?

along with these , u can also work on improving the UI of the payment.html page so that it aligns with the theme of the website . ( color combo )


Storagepreview

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it microsoft/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/williexu/azure-cli-extensions.git@storagepreview#subdirectory=src/$EXT&egg=$EXT"


Missing important values for MarkedLocationType enumeration

Issue name: “Missing important values for MarkedLocationType enumeration”
Summary
Location markers in a work zone (or road event) may not be exclusive to the start or end positions, or may be indeterminate in terms of order within a series of location markers. Currently the MarkedLocationType enumeration only supports "start" and "end" locations for road events or work zones. This precludes using marked location devices that are either intermediate to those positions or indeterminate of delineation. Within the WZDxFeed, the preferred method of delineating a work zone is via more than 2 points, which necessitates an intermediate to the start and end positions. Currently the SwzDeviceFeed will not support the inclusion of that 3rd, intermediate, marker device because the MarkedLocationType enumeration does not have an option for it.
Motivation
Adding this as an issue so it doesn't get lost as an existing PR
Proposed changes
Detailed in PR #227

Reference: MarkedLocationType
I agree with the suggestion of having a supplementary value for positions that are known as part of the work zone and not part of the listed supported device types. Personally I would call it waypoint or just other, but the suggested -intermediate value can work too.
I'm less confident in with the PR suggestion of differentiating between road-event-intermediate and work-zone-intermediate, since both are in the middle. It make sense to delimit the boundaries of the individual events in a bigger work zone, but not the middle points, since they are all middle to both the event AND the work zone.
As for the suggested -undetermined value, I understand they are to represent moving equipment that can be in or outside the work zone. I believe these should be completely absent if they are out of the bounding box or too far away from the events, but I don't see any harm at having the value available. We should make sure to have a clear description as to when this value to be used.
I would also suggest to add the value worker. Just like the flagger value, to pinpoint worker presence that are not necessarily waving a flag.
And I know it's important not to go outside of the scope of work zones, but I could also see value in added aluminum signs as new types. It could go as far as having the specific MUTCD code for temporary work zone signage.

The MarkedLocationType enumeration currently has:
road-event-start
road-event-end
work-zone-start
work-zone-end
The PR addition of
road-event-intermediate
work-zone-intermediate
is intended to correspond to the existing enumeration structure where road-events and work-zones are 2 different categories.
The -undertermined addition, as noted in the PR, is for allowing devices to be grouped with road-events / work-zones that are GPS marked but not for the purpose of describing the shape/path of the road event / work zone. The examples provided include moving devices and fixed position devices ahead of / behind the precise manifestation of the road event or work zone (such as PCMS to notify oncoming traffic to an approaching work zone). These types of devices are categorically a part of the road event / work zone, but are not descriptive of the bounds of the road event / work zone.

I want to expand this issue to discuss other options for things to add to the MarkedLocationType enumerated type, based on SWZ Subgroup discussions so far and desires from members and co-chairs:

delineator: a generic delineation point in a work zone. This could be used in place of all the intermediate options proposed above and is more general to be used for most types of marked locatins that don't fit into the other categories. However, it may be too general and thus not provide much value.
ramp-closure: the point where a ramp is closed due to the work zone. Potentially, the existing type lane-closure could be used for this. We need more information from consumers to know the critical distinction between a lane and a ramp;  as WZDx LaneType considers ramps to be types of lanes, there may be no difference and we should not add this value.

Expanding this issue to discuss all types of enhancements to the MarkedLocationType, after discussion between co-chairs of the WZDx Workers Presence and Smart Work Zones Subgroup, it was decided that we should propose adding functionality to use the LocationMarker to represent wearable devices, such as connected vests. Thus, proposed for inclusion is the following enumerated type value:

wearable: a connected device that is worn by a worker in a work zone.

I agree with @j-d-b in regards to the wearable value for the MarkedLocationType (link)
We already had flagger,   the new one will cover many others cases.

Updates:

"wearable" has been implemented in #293 as personal-device.
"delineator" covers all the "intermediate" options proposed in #227; #227 can be closed and a new PR adding delineator will be created.
"lane-closure" could be used for ramp closures, since ramps have lanes and can be represented in WZDx road events as lanes, but based as the LocationMarker covers various use-cases it is easier for current users to have ramp-closure as a separate MarkedLocationType. Similarly, road-closure can be added to allow using a LocationMarker to represent when an entire road is closed. As we are in the early stages of the DeviceFeed and especially LocationMarker, having explicit a MarkedLocationType for each common scenario we know that current feed users want to use a LocationMarker for is reasonable—we can simplify or refactor in the future based on experience.

Resolved in #293, #311, #312.