Add support for serializing to JSON

Due to the time it takes to read a model into MontePy, it is helpful for users to be able to serialize the model and write it to file to make loading in the future easier. Pickling is possible, but does come with a huge security vulnerability when sharing files. Instead a way to support serialization that does not allow code execution is needed. So JSON should be supported.
Some thoughts:

Most objects are not immediately writeable to JSON.
The "correct" way to implement this is by implementing a default function that is passed to the load/dump function. This doesn't seem the cleanest as it would be nice for JSON to call a dunder function that an object implements so json.dump can just be called on an object.
The defacto standard is to implement a to_json method, and sometimes a from_json.
The syntax tree for each object is it's most important information to keep.
There are two ways to save to JSON.

An internal representation of the state for the MontePy object e.g., {"cell": {"number": {"value": 120, "token": "0120"} ...}
A JSON version of an MCNP input file. The goal with this would be to push MCNP in this direction: e.g., {"cell": {"number": 120, "mass_density": 10.0, importance: {"n": 1.0...}}}

How to implement:

Implement MCNP_Problem.export_to_json() for creating a JSON formatted Input File
Implement MCNP_Problem.to_json() for serializing the object state to json.
Maybe we will want to create a generic MCNP_Problem.serialize that will just generate a dictionary that can then be saved however the user wants.
Need to implement montepy.from_json.

One question I have @tjlaboss: how much schema enforcement should be done for de-serialization? My understanding is that this shouldn't pose a security risk, but could lead to some weird errors. I'm thinking we shouldn't guard against this as the use case of manually editing the serialized form would not be supported by us.


Feature/add tab mapping

Taking a stab add adding the Visual Mode mapping and adding support for tab and shift tab to indent and outdent when in the visual mode.

Also, you need to run esy format to appease the CI.

@glennsl  I don't know why the check failed, but it generated the artifacts. I tested them and they appear to be working correctly.

The Windows CI tasks seems to be flaky. I had a similar issue last night for my PR, but it worked fine this morning. You just need @glennsl or @bryphe to re-run the CI pipeline.

/azp run


Mouseout event triggered on removed L.Path throws TypeError

Description:
If a Path is removed from the map while in 'mouseover state' (the mouse is still over the element - the mouseover event has been triggered but the mouseout event not yet), then the next mousemove event will trigger a mouseout event on the Path. As the path has been removed from the map when this event is triggered, the this._map property has already been nulled and the event throws an uncaught TypeError in _fireMouseEvent.
Stack trace:
Uncaught TypeError: Cannot read property 'mouseEventToContainerPoint' of null
o.Path.o.Path.extend._fireMouseEvent @ leaflet.js:7
o.DomEvent.addListener.t.(anonymous function).s @ leaflet.js:8
Test case:
Minimal jsFiddle test case can be found here:
http://jsfiddle.net/Ldp25Lf4/
Affected Versions:
Note that this happens on 0.75 / stable only, but not on 1.0.0-beta.1 / master (due to major refactorings in that part of the code).
Browser:
Tested on Firefox 40.x and Chrome 45.x

Duplicate of #3829


TypeError when using MinViewMode

Hi, when I try to use MinViewMode so the user can only select Year and Month, I get this error on the browser console: TypeError: o.find is not a function.

Give development branch a try. Try with the unminified version. That should be fixed there

In development branch is fixed.


Fix make ci-clean and runlocal-rp

Which issue this PR addresses:

Fixes local make errors
What this PR does / why we need it:

Problem 1: make runlocal-rp
Typo in image tag.
Problem 2: make ci-clean
Fix an error for orphaned running work containers by buildah that prevents prune from working. This can occasionally happen when you kill a build with ctrl-c (which can lead to some really wonky build states, like RUN commands missing the cache randomly/etc - make ci-clean needs to be capable of fixing these states):
$ make ci-clean
podman image prune --all --filter="label=aro-*=true"
WARNING! This command removes all images without at least one container associated with them.
Are you sure you want to continue? [y/N] y
Error: image used by fe1476ec4e2c451b5cdf0788df13f9006a64b4c7efa8cde43b72aec1f673c261: image is in use by a container: consider listing external containers and force-removing image
make: *** [Makefile:222: ci-clean] Error 125

Listing external containers, you can see the buildah working container artifacts that prevent image deletion:
$ podman ps --external
CONTAINER ID  IMAGE                                                                                COMMAND     CREATED     STATUS      PORTS       NAMES
81b98b6b041d  registry.access.redhat.com/ubi8/nodejs-16:latest                                               buildah     4 days ago  Storage                 nodejs-16-working-container
3c1b2bf5c347  docker.io/library/46d89be108e7fa5cac82f7e68c543539b7c13e558ed1cdf78498b51916586f80-tmp:latest  buildah     4 days ago  Storage                 3d52b3bb3d8a-working-container
3efa745fabf8  docker.io/library/2aa66078bf34e95141549305672566212ddb4f66ba2fcce4a856e2bc1e199c4a-tmp:latest  buildah     4 days ago  Storage                 327bc823b740-working-container
3610dc395a7a  docker.io/library/cea1b1cccd979795295a974097fa8db114ac9ec5f125eafe5252865bf87ea16a-tmp:latest  buildah     4 days ago  Storage                 7b178c9a4c1f-working-container
eed2a06abda2  docker.io/library/11672cccafff0e2355b71f5458990cda5ad64035201a45e3923a3ae0ca924f6c-tmp:latest  buildah     4 days ago  Storage                 8a45bc60bb06-working-container
7fa4dba5db49  registry.access.redhat.com/ubi8/nodejs-16:latest                                               buildah     4 days ago  Storage                 nodejs-16-working-container-1

Unfortunately, I couldn't take "standard" routes:

podman system prune --external does not fix the issue
buildah rm -a would be nice, but buildah is strictly Linux and will not port to MacOs as part of make - so I had to build my own version of this command.

Test plan for issue:

Run make ci-clean locally, validate buildah containers are also removed with podman ps --external.
Is there any documentation that needs to be updated for this PR?

N/A
How do you know this will function as expected in production?

Does not affect production, only local image cache and containers created by buildah.

/azp run ci

I was not able to reproduce the issue with the orphaned running work containers at my side. But the make ci-clean works correctly.
MacOS.
LGTM.


⚠ Bofrost.de has degraded performance

In 83b8d77, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1058 ms

Resolved: Bofrost.de performance has improved in 02765a9.


Coroutines functionalities in the context of Minecraft

Soon we would have Dispatchers.Main been implemented as a supplement to other dispatchers. A few questions I'd like to ask before diving into it.

Q1: We need to specify how the dispatcher runs actually, because unlike the official implementations, there's no ready-to-use event loop, but only tick, render forming some kind of "event loop". Maybe QSL lifecycle events could be used.

So I'm looking into kotlinx.coroutine for reference. However only UI related implementations (Android Event Loop, JavaFX, Swing) are found.

Q2: Do we really need main dispatcher on the server side? Usually it is for UI and is confined to only one thread. What is the usage?

Q3: Usually main dispatcher implements Delay for time related tasks. While real time is used among other main dispatcher implementations, Minecraft has a special time unit which is tick. Should we consider a tick based Delay implementation?

Q1 and Q2 are an interesting consideration. Android, JavaFX, and Swing are all GUI frameworks. In their contexts, thread safety is only needed when drawing onto the view. Minecraft, however, has both rendering and worlds requiring synchronization, with worlds having a server and client running in parallel. Any of them can pass for a Main context, though my expectation would probably be to find server being referred to as such.
Perhaps it'd be a better idea to add Server, Client, and Render as Dispatchers extensions instead.
As for delays, the question here is behavior on dispatchers that don't implement Delay: the docs don't seem to state it explicitly, but the delay handler in this case is the DefaultDelay. I could only track down the execution so far after that. However, it'll eventually have to come back to the dispatcher and dispatch anyway, so the behavior will likely end up being rounding up to the nearest tick.
I say implementing Delay, warning that it shouldn't be used in logs (can't do deprecation as we don't control the delay(Duration) and delay(Int) functions themselves, and pointing towards a separate method that takes ticks would be the cleaner option that tells the users their delays are being rounded to ticks and to specify that upfront.

Perhaps it'd be a better idea to add Server, Client, and Render as Dispatchers extensions instead.
Is there a meaningful difference between server and client?

The both only have a single thread for computation afaik, with client just running an integrated server

Is there a meaningful difference between server and client?
The both only have a single thread for computation afaik, with client just running an integrated server

In this case, one difference is how the dispatcher functions. I'm considering the following implementation: maintain an internal task queue for each main dispatcher, and when certain event happens like XxxTickEvents.START/END, these scheduled tasks get executed. So the difference here is where the tasks run.

Perhaps it'd be a better idea to add Server, Client, and Render as Dispatchers extensions instead.

This is what I mean to do at first place. (Can you explain the reason to seperate Render and Client? I didn't find minecraft seperating these two contexts)

I say implementing Delay, warning that it shouldn't be used in logs (can't do deprecation as we don't control the delay(Duration) and delay(Int) functions themselves, and pointing towards a separate method that takes ticks would be the cleaner option that tells the users their delays are being rounded to ticks and to specify that upfront.

I agree. A seperate function is needed so users don't get confused by the behavior. Normal delay would most likely round up to the nearest tick if going for my suppose specified in the previous comment.

Can you explain the reason to seperate Render and Client? I didn't find minecraft seperating these two contexts)

My impression was client-side rendering and world ticks still run on separate threads, so they are separate contexts. I might be wrong on that, but if so, running rendering code on a world thread would slow the ticks down, while vice versa would result in concurrent modification.

Bringing this up again, for Q1 something that would make sense would be the ability attach jobs to specific objects with their own lifecycles
so, i.e, you could attach a job to a player, delay for "ticks" (running the job as part of the player tick?) and if the player disconnects from a server, close their CoroutineScope so that anything attached gets the ability to clean up automatically when it makes  sense
Ive had a few cases now where my Jobs are doing something in relation to a world, and I need to spend a bunch of time hooking it up to the start and stop events

Generalize this topic in order to welcome other coroutine related ideas.

Bringing this up again, for Q1 something that would make sense would be the ability attach jobs to specific objects with their own lifecycles
so, i.e, you could attach a ...

A CoroutineScope could be created for an object with the corresponding lifecycle based CoroutineContext.
I'm thinking of having a (or to say one for eash logic side) global CoroutineDispatcher which maintains all continuations in the order of that in the original Minecraft, and this priority is done by LifecycleObjectType which is this CoroutineContext and specifies when this LifecycleObject (pseudo concept) runs its continuations on the game loop timeline.

Something that occurred to me, is there any we can write this where it wont explode with those various "Minecraft but with more threads" projects?
They are, unfortunately, somewhat popular and I suspect we'll run into issues at some point with them.


Few incorrect hashes

2.3.6
mmc-export -i "c:/Users/Madis/Desktop/Fabulously Optimized 3.9.0.zip" -f Modrinth --modrinth-search loose -o "c:/Users/Madis/Desktop/" -c "C:/Users/Madis/Documents/GitHub/fabulously-optimized/Modrinth/mmc-export.toml" -v 3.9.0

modrinth.index.json.txt
same happens when importing FO 3.9.1 btw

Can you send intermediate output?

intermediate_output.json.txt

Actually, reading the error it just seems the script doesn't like (anymore?) when a version has two files - a jar for users and a sources jar.

Yeah, I think that's the problem. It never liked when a version have multiple files

Fixed with latest?

Fixed with latest.


Expose flow types & add detailed usage docs

This commit introduces a few flow-related things (and also some misc
stuff):

Fix some typing errors with glamor / nameGenerator
Move adapted flow-typed/npm libdefs to flow-typed
Add some flow related ignore rules for eslintrc / flowconfig etc.
Add a build:flow script and add it to the build step
Add docs for making styled-components and flow work for the consumer

MISC:

Add test for generateAlphabeticName

As soon as this feature is merged, there will be flow.js files
vendored along with transpiled lib files on every build.
Related issues: #177 and #151

The flow files generated by build:flow contains regular javascript, but as far as I understand from the flowtype docs it should contain declarations similar to the libdefs in the flow-typed folder?

@relekang Shadow files can also contain implementing code... that's the whole point why they wanted to introduce the flow gen-flow-files command... to strip out the implementation code and make the delivery size much more efficient... you can imagine it like this... code located in lib is transpiled source without any annotations... if flow sees a [file].js.flow, it will parse this code instead... this has nothing to do with libdef syntax

@mxstbr @geelen @relekang ... Everything done on my side... I even made it Windows compatible ... time to >ship it< 🚀

Shadow files can also contain implementing code... that's the whole point why they wanted to introduce the flow gen-flow-files command... to strip out the implementation code and make the delivery size much more efficient... you can imagine it like this... code located in lib is transpiled source without any annotations... if flow sees a [file].js.flow, it will parse this code instead... this has nothing to do with libdef syntax

Ah, okay 😊
Great job :v:

This looks good to me. Tested it on a few projects of mine it works great except there seems to be some problems with the ThemeProvider typings, but I guess it would be better to fix that outside this PR as it is not related to the bundling of flow types. 🙂

@relekang That's most likely because you use a different flow version... I am 80% sure :-) ... yep we can do that

That's most likely because you use a different flow version

Yeah, it was 0.33.0. Sorry about that.


BIP 32 binary encoding functions are extracted from base58

Binary (non-base58) encoding for public and private keys are required for storing PSBT PSBT_GLOBAL_XPUB according to BIP 174. This PR extracts binary encoding from inside Display and FromStr functions and put this as a standalone methods.
This PR is dependent on #469; to see only changes specific to the current PR pls check commit https://github.com/rust-bitcoin/rust-bitcoin/commit/94c2ddaeffd4277aed50bc88e0684e4d311faeea

Could this perhaps be rebased just on master? I think this can be merged faster than the ypub stuff as it's way less opinionated on.

@stevenroose done

Rebased onto fixed master (requires #512 to be merged first) and addressed @stevenroose comments

Found another incorrect error conversion which fixed with https://github.com/rust-bitcoin/rust-bitcoin/pull/470/commits/97e7d0da8a04a2c79319c755735f24a812915958

@apoelstra your comments are addressed. Rebased onto master with the merged fix and kept two commits in the history: one for moving logic from old functions to a new once w/o code modification inside those functions; and the other on top with all improvements and addressing review suggestions.

Updated according to @stevenroose review; all the changes are in https://github.com/rust-bitcoin/rust-bitcoin/pull/470/commits/fa4ecb4a6a8cab36bef92a0e792cdddd5b395c1a


optional: disabling scan to access directly on upload phase

Hello,
I add two options:

scan files only
upload without scan
For massive upload, I schedule scan files only every week but I upload photos after opening session (I'm windows user).

Python2 walk files have poor performance. In ths way, I save time.
I'm not python developer but to my mind, for the next version, I think that it will be a good idea to remove all tables except allMedia  and add it attributes like 'bad' ...
Thank you for your help.

@malys checkout version 2.6.7 which is much faster for runs after the 1st one. Calls to md5Checksum (time consuming) are now much more limited while keeping the "scan files". I think it will end up addressing your question.


Fix for Issue #66 | Docker run fails due to "Cannot find module '/home/myuser/dist/main.js'" | Error in Docker container

Fix for Issue #66 - Docker Run Failure Due to Missing 'main.js' - Overview
This pull request addresses the critical bug described in Issue #66, where the Docker container for 'gpt-crawler' fails to start due to a missing /home/myuser/dist/main.js module. The root cause was identified as an incorrect file path reference in the package.json and a missing TypeScript (tsc) setup in the Docker environment.
Changes Made
Modified Files:

package.json:

Updated the start:prod script from "node dist/main.js" to "node dist/src/main.js". This change corrects the path to the main JavaScript file generated after TypeScript compilation.

.dockerignore:

Added ignore line for the base image's default main.js in '/home/myuser/'.

Testing and Verification

After implementing the changes, the Docker image was rebuilt.
Ran the updated Docker container and confirmed that the 'gpt-crawler' started successfully without encountering the previous error.
Conducted functional tests to ensure that the crawler operates as expected in the Docker environment.

Conclusion
These changes rectified the issue of the Docker container failing to run on my machine where Node is not installed, thereby improving the usability and reliability of the 'gpt-crawler' in Dockerized environments.

Link to related issue: Issue #66
My Fork

thanks @Daethyra !


initial implementation of Scan, with only MIT license

This is the implementation side of Scan.
Many more licenses will follow, but this PR has just the code and one license to exercise it.
(The MIT license is very old and has undergone significant mutation over the years, so it's a significant test case all by itself.)
As far as reviewing, it may be more manageable to look at the individual commits, although most files are only changed in one commit, so the file view is not too much different.

I have addressed all the comments in the dict commit.
Still working through some of jba's later comments in the later commits.


SARAALERT-1145: SymptomsAssessment input validation & IntegerSymptom support

Description
Jira Ticket: SARAALERT-1145
Certain browsers allowed users to input non-numerical values into FloatSymptom input fields which caused errors at times. This PR addresses that issue as well as two other issues that were identified while testing the original reported bug:

IntegerSymptoms did not render in the SymptomsAssessment component when present
Inputs over a certain value would cause errors.

Screenshot
IntegerSymptoms now display properly in the SymptomsAssessment component:

Bugfix - How to Replicate
Bug 1: FloatSymptom inputs accepted non-numerical inputs (all browsers except Chrome) and at times caused errors (specifically for Internet Explorer).

While in Internet Explorer, navigate to a monitoree's profile that has a SymptomAssessment with a FloatSymptom.
Click on "+ Add New Report" to open up a new assessment.
Input an invalid entry such as "6%" and submit the Symptom Assessment.
Observe that an error occurs after a short time.

Bug 2: IntegerSymptoms (when present) do not render in the SymptomsAssessment

(Ensure you have an IntegerSymptom configured for at least one of your available jurisdictions - see instructions in Testing section on how to configure if needed)
Navigate to a monitoree's profile that has a SymptomAssessment that should have a IntegerSymptom.
Click on "+ Add New Report" to open up a new assessment.
Observe that the IntegerSymtom is not displayed.
(To confirm that the IntegerSymptom should be in that assessment, submit that assessment and observe in the Reports table that a column should be displayed for the IntegerSymptom that wasn't displayed in the assessment.

Bug 3: Providing a FloatSymptom input over a certain value causes an error (any browser)

Navigate to a monitoree's profile that has a SymptomAssessment with a FloatSymptom.
Click on "+ Add New Report" to open up a new assessment.
Input the following value into the FloatSymptom input:<PHONE_NUMBER>999999999999999999999999999999
Observe that an error occurs after a short time.

Bugfix - Solution
Bug 1: FloatSymptom inputs accepted non-numerical inputs (all browsers except Chrome) and at times caused errors (specifically for Internet Explorer).
The various browsers handle type='number' in different ways and the handleChange() method was not robust enough to prevent the user from inputting non-numerical values. Various handle change methods were created for float, integer & boolean symptoms to ensure more robust validation was in place to prevent the user from inputting erroneous inputs. And due to issues with how Firefox passed the inputted value to the handleChange() method, the type='number' property was removed. To handle the special cases of ., -, & -. characters being inputted, on submission, validation is done to null the values out if such inputs are detected so as not to trigger an error.
Bug 2: IntegerSymptoms (when present) do not render in the SymptomsAssessment
The SymptomsAssessment component did not support the rendering of IntergerSymptoms. The component was updated to check and properly render IntergerSymptoms when any were present in the list of symptoms to display. Validation was also included similar to the validation for FloatSymptoms.
Bug 3: Providing a FloatSymptom input over a certain value causes an error (any browser)
Providing an input over a certain value would cause an error to occur on the backend. So the user/monitoree will now be limited in the value they can input through an enforced maxLength property on the input (set to 35 for FloatSymptoms and 9 for IntergerSymptoms).
Important Changes
app/javascript/components/assessment/steps/SymptomsAssessment.js

Each different symptom type now has their own change method for validating user input
Formatting is done on the submitted FloatSymptoms and IntegerSymptoms to ensure an invalid input does not cause an error.
Logic included to handle the rendering of IntegerSymptoms
The type='number' property was removed due an issue in Firefox (if a user inputted an invalid entry such as "6tk", Firefox would pass in an empty string to the change method)

app/javascript/tests/assessment/steps/SymptomsAssessment.test.js

Tests were updated to address the new IntegerSymptom that was included in the mock files.

app/javascript/tests/mocks/mockAssessments.js
app/javascript/tests/mocks/mockSymptoms.js
app/javascript/tests/mocks/mockTranslations.js

Mocks for an IntergerSymptom were included for testing purposes

Testing
This fix was tested on the following browsers (submitter must check all those that apply):

[x] Chrome
[x] Firefox
[x] Safari
[x] IE11
[x] Edge

Note - Please perform these tests in all the browsers listed above.
FloatSymptom Tests:

[x] Attempt to type in any non-floating point input. Observe the input field prevents the user from providing such input. The only allowed inputs are any valid positive or negative floating point number, ., -, and -.
[x] Type in each of the following inputs into the FloatSymptom field and submit the assessment:  ., -, and -.. Observe that the new assessment displayed in the Reports table displayes the FloatSymptom value for that symptom as blank.
[x] Type in any valid floating point value into the FloatSymptom field and submit (such as 0.22, .12, 1.23, -0.1, -1, -1., -.12). Observe that the new assessment displayed in the Reports table displayes the FloatSymptom value for that symptom as expected.
[x] Attempt to input<PHONE_NUMBER>999999999999999999999999999999 (which is 40 characters long) into the FloatSymptom field. Observe that the input only accepts up to 35 characters. Click submit and observe that no error occurs and the new assessment displayed in the Reports table displayes the FloatSymptom value for that symptom as expected.

IntegerSymptom Tests:
**See section at bottom for configuring an IntegerSymptom

[x] Attempt to type in any non-integer input. Observe the input field prevents the user from providing such input. The only allowed inputs are any valid positive or negative integers and  -.
[x] Type in the following input into the IntegerSymptom field and submit the assessment:  -. Observe that the new assessment displayed in the Reports table displayes the IntegerSymptom value for that symptom as blank.
[x] Type in any valid floating point value into the IntegerSymptom field and submit (such as 12 & -12). Observe that the new assessment displayed in the Reports table displayes the IntegerSymptom value for that symptom as expected.
[x] Attempt to input<PHONE_NUMBER> (which is 10 characters long) into the IntegerSymptom field. Observe that the input only accepts up to 9 characters. Click submit and observe that no error occurs and the new assessment displayed in the Reports table displayes the IntegerSymptom value for that symptom as expected.

Adding a IntegerSymptom to your local Sara Alert instance:

(optional) Save a copy of your current database elsewhere if you would like to use it again.
Go to this line of your local jurisdiction.yml file and input the following right under that FloatSymptom:

'Integer Symp':
                    value: 10
                    threshold_operator: 'Less Than'
                    type: 'IntegerSymptom'
                    required: true

Go to this line of your local en.yml file and input the following right under that FloatSymptom:

integer-symp:
        name: 'Integer Symp'
        notes: ''

Run the following on your command line: bundle exec rake admin:import_or_update_jurisdictions
Now all monitorees in State 1 would be expected to have the "Integer Symp" display in their symptom assessments.

When you are done testing and would like to remove the Integer Symp, you can do one of the 3 following options:

If you saved a copy of your database before adding the Integer Symp, drop your current database and use your previous one.
Revert the changes you made to your local jurisdiction.ymland en.yml files.

OR

Drop your current database.
Revert the changes you made to your local jurisdiction.ymland en.yml files and run the following commands to re-initiatize your database (based on the Sara Alert README):

rails db:create
rails db:schema:load
bundle exec rake admin:import_or_update_jurisdictions
bundle exec rake demo:setup demo:populate (optional)

OR

**Revert the changes you made to your local jurisdiction.ymland en.yml files and run the following commands to remove the Integer Symp from State 1 assessments: bundle exec rake admin:import_or_update_jurisdictions

**If you decide to do this method, please note that all assessments that were previously submitted with Integer Symp will still be displayed in a monitoree's Reports table and if you attempt to edit any of those prior assessments, the Reports table will crash.

I'm not sure if this is an issue or not but if you type an invalid key it moves the cursor to the end of the line. So for example if you went to enter 3.14 and realized you typed 2.14 and go to the beginning, delete the 2, and  press e instead of 3 your cursor will be at the end of .14

I'm not sure if this is an issue or not but if you type an invalid key it moves the cursor to the end of the line. So for example if you went to enter 3.14 and realized you typed 2.14 and go to the beginning, delete the 2, and press e instead of 3 your cursor will be at the end of .14

Thanks for asking, this is expected behavior. Unless another reviewer thinks otherwise, I can't think of a strong reason to change this behavior so I'll leave it as is for the time being.

There is some wonky display stuff happening on IE (see below).  Not specific to your branch but might be worth adding a ticket.  Didn't happen on any other browsers.

This also needs a rebase because it has conflicts.  Looking good so far though!

There is some wonky display stuff happening on IE (see below). Not specific to your branch but might be worth adding a ticket. Didn't happen on any other browsers.

Thanks for pointing that out @sgober, I have created this ticket to address that issue in a different PR.

@hackrm It looks like after the most recent rebase the React component tests are failing. Looks like some of the wrong changes may have been accepted in that rebase as it relates to the new ApplyToHousehold component.

@hackrm After the most recent rebase the React component tests are failing. Looks like some wrong changes may have been accepted in that rebase as it relates to the new ApplyToHousehold component. Might be worth grabbing your commits and starting fresh - the rebase had a lot of conflicts and we want too make sure all the changes currently on 1.25.0 were accepted (that weren't actual conflicts with your work).

@kylietmo - Thanks for the tip, my branch should be good now!


Actually vendor go-jsonnet 0.15.0

Oops
Add a test case to check that actually we run jsonnet 0.15.0

TBR


use same income variables for evaluation

generate_income_baseline.py uses file "INPA2011TABV2.sav", and the variable "INPBELI".
baseline_model_income_jan_2024.R uses the incomeAge30 variable from the income.saved dataframe

how do we make sure we use the same variable for both scripts?

the problem is that Lucas takes the income of people at age 30; while Dakota uses people's income (that has an income at age 30) for all/multiple years available.

we postponed this issue because we will use a different income measure as target for prediction

closing as outdated


RTCP Receiver Report Extensions being sent from Edge without any corresponding extmap entries in the SDP

Browsers and versions affected
Edge Shim
Description
RTCP Receiver Reports being generated by Edge contain the following extension, but there is no corresponding extmap in the SDP to indicate this extension will be present.
Edge Extension Spec: https://msdn.microsoft.com/en-us/library/dd950523(v=office.12).aspx
(For a little more background, see this issue report on Microsoft's site:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12054804/)
Steps to reproduce
Set-up a PeerConnection between 2 Peers and inspect both the SDPs and the RTCP Receiver Reports that come out of Edge.
Neither CreateOffer nor CreateAnswer contain any extmap's indicating the extension in the Receiver Reports.
Expected results
I expect the SDPs to contain an extmap that corresponds to the extension in the Receiver Reports
Actual results
No such extmap's exist

that sounds familiar... can you provide an unencrypted RR as a pcap?

Unfortunately, I am unable to successfully create an unencrypted Peer Connection with my current setup, but you can find a binary RR packet in the MS issue that I referenced above (https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12054804/)

ah... I had encountered this before:  rr.pcap.zip and had to fix my rtcp parser to ignore it.
This probably comes from the fast_bandwidth_feedback extension that Edge announces in RTCRtpReceiver.getCapabilities().headerExtensions. I'll need to check if .send and .receive are called without this when an answer from Chrome or Firefox comes that does not contain this.

IIRC that was in a situation where that extmap was not used in the SDP. So this doesn't seem like something that goes wrong in adapter but a native layer issue.


Enhancers extending state will not work for all reducers

Prior Issues
https://github.com/reduxjs/redux/issues/1648
What is the current behavior?
The type for enhancers imply that enhancers should be allowed to extend the state. This is problematic for simple states that are just a number or a string because there is no way to extend them while still maintaining the original string or number. If you spread a string or a number, you'll get an empty object back, so if an enhancer tries to extend state, they'll likely end up erasing the user's state.
Steps to Reproduce
function counter(state = 0, action: AnyAction) {
  switch (action.type) {
    case "INCREMENT":
      return state + 1;
    case "DECREMENT":
      return state - 1;
    default:
      return state;
  }
}

interface MyStateExt {
  bar: string;
}

function makeEnhancer(): StoreEnhancer<{}, MyStateExt> {
  return (createStore: StoreEnhancerStoreCreator) => <S, A extends Action>(
    reducer: Reducer<S, A>,
    preloadedState?: PreloadedState<S>
  ): Store<S & MyStateExt, A> => {
    const store = createStore(reducer, preloadedState);

    return {
      ...store,
      getState: () => ({ ...store.getState(), bar: "test2" }),
      replaceReducer: (reducer: Reducer<S & MyStateExt, A>) => {
        throw new Error("Not implemented.");
      }
    };
  };
}

const store = createStore(counter, makeEnhancer());
// User expected store.getState() to return their counter number,
// but instead it returns { bar: "test2" } from the enhancer
const state = store.getState();

https://codesandbox.io/s/unruffled-faraday-u502r?fontsize=14&hidenavigation=1&theme=dark
What is the expected behavior?
The types should not allow you to create an enhancer that tries to extend the state because it's not possible to do so if the state is a string or number.
Environment Details
N/A

@timdorr Any insights into https://github.com/reduxjs/redux/issues/1648 or why we would want to let enhancers extend state?

As a store enhancer, they have quite a bit of control over the behavior and shape of the resulting store. They may want to add things to state related to the things they are enhancing. I could see a WebSocket enhancer that exposes the global connection instance via getState(). The main reason for doing that would be to allow access during connect() or useSelector(). So, I think it should stay.

But how would the WebSocket enhancer add to the state if the state is just a number or a string?

It seems to me like the preferable way for a library to extend state would be to expose a reducer and an enhancer and have the user provide the reducer in combineReducers themselves. I've seen quite a few libraries export a reducer that is expected to get mixed in (e.g., https://github.com/supasate/connected-react-router#step-1).

Also worth noting that this is really a conversation about types. If an enhancer really wants to extend state, they can write the JavaScript to do so. However, providing a StateExt type provides the illusion that it's safe to extend the state for any generic state. In the example I gave above, everything compiles, but the result is not safe. This is because TypeScript allows you to spread an unrestrained generic (still looking into this).
Removing the StateExt generic wouldn't make it impossible to extend the state from a JavaScript perspective, but from a TypeScript perspective it will prevent cases that we normally expect TypeScript to catch.

But how would the WebSocket enhancer add to the state if the state is just a number or a string?

They would need to handle it in the setup function, I would imagine. Simple state values aren't typically used with enhancers like that. I would say that's an extreme edge case.

Still seems like it wouldn't be too hard for an enhancer to just have the user add the reducer themselves. It will also prevent the enhancer from having to deal with the edge cases where the state isn't an object or the key already exists in the reducer.
It could be implemented like this:
// Enhancer code
interface WebSocketConnection {}
declare function makeConnection(): WebSocketConnection;

interface WebSocketElements {
  webSocketReducer: Reducer<{ connection: WebSocketConnection }, AnyAction>;
  webSocketEnhancer: StoreEnhancer<{ extendStoreProperty: {} }>
}

function connectToWebSocket(): WebSocketElements {
  const connection = makeConnection();

  return {
    webSocketReducer: (state, action) => ({ connection }),
    webSocketEnhancer: (createStore) => (reducer, preloadedState) => ({
      ...createStore(reducer, preloadedState),
      extendStoreProperty: {
        // do some fancy stuff in here
      }
      }),
  }
}

// User code
const { webSocketReducer, webSocketEnhancer } = connectToWebSocket();

const reducer = combineReducers({
  webSocket: webSocketReducer,
  // rest of your reducers
});

const store = createStore(reducer, webSocketEnhancer);

In summary:

As far as I can tell, enhancers extending state is not very common (I don't know of any real-life examples).
There's already precedent for having users add parts of state to combineReducers themselves (e.g., https://github.com/supasate/connected-react-router#step-1).
It simplifies the types for enhancers in Redux.
It makes the types for enhances in Redux more type-safe.
It provides better safety for the enhancer and allows them to not have to deal with the cases where the state isn't an object or the key already exists in the reducer.

Since it doesn't seem very common, it simplifies the Redux types, and there's better type-safety all around, I still think it's a net positive to remove the StateExt generic.

A number or a string can be assigned additional prperties, which converts them to Number or String objects.
So in JavaScript, this is possible.
const numberWithProps = Object.assign(5, {foo: "bar"})

and results in a Number & { foo: "bar" } that behaves just like 5 with an additional property.
But really, this is more of a typing issue. It doesn't sound reasonable to me to remove a feature that might or might not be used by who-knows-how-many of the 13k redux-related packages currently on npm.
Instead, the type could be modified to simply only accept object-like types to extend?

Nice, didn't realize you could do that.
As you said, this is a typing issue. In reality, an enhancer can do whatever it wants to a store. It could change the state of shape completely (not just extend the state), which is something our types don't support.
With any other type in Redux, I know of an package that uses that type. However, I have not seen a real-life usage of StateExt, which is why I call it into question. Even less likely is that this enhancer uses TypeScript. If TypeScript supported deprecating, then we could deprecate the type to see how many people are actually using it and then just un-deprecate it if it's being used, but I don't think TypeScript currently supports deprecation (see https://github.com/microsoft/TypeScript/issues/390).
It seems odd to support a feature that considerably complicates our types that "who-knows-how-many packages" are relying on if that number could reasonably be 0.
I'm not too worried about constraining the type to be just object-like, my main push for this change would be to simplify the types.

My original concern of enhancers extending state not working for all reducers has been addressed. Thanks!


[refactor] some code cleanup for min/max function.

Proposed changes
Issue Number: close #xxx
Problem Summary:
Describe the overview of changes.
Checklist(Required)

Does it affect the original behavior: (Yes/No/I Don't know)
Has unit tests been added: (Yes/No/No Need)
Has document been added or modified: (Yes/No/No Need)
Does it need to update dependencies: (Yes/No)
Are there any changes that cannot be rolled back: (Yes/No)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

@yiguolei @morningman
Do you have time to help to review this PR?


Make multiple WSO2 crypto service providers configurable within a product.

Is your suggestion related to an experience ? Please describe.
In current WSO2 products, you can configure only one WSO2 internal crypto service provider (SymmetricKeyInternalProvider/KeyStorebasedInternalProvider). But, there may be situations where we would want to use symmetric key encryption in some components and keystorebased encryption in some
components.
We need to provide support for a configuration that would allow such capability
Describe the improvement

Additional context

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Add show camera and snooze notification actions in crying notification

Task

JIRA

Description

Add snoozeTimestamp to child table to handle notification snoozing
Fix for starting stream with not open webSocket connection

          22 Warnings

:warning:
app/src/main/AndroidManifest.xml#L0 - The project references RTL attributes, but does not explicitly enable or disable RTL support with android:supportsRtl in the manifest

:warning:
app/src/main/AndroidManifest.xml#L20 - On SDK version 23 and up, your app data will be automatically backed up, and restored on app install. Your GCM regid will not work across restores, so you must ensure that it is excluded from the back-up set. Use the attribute android:fullBackupContent to specify an @xml resource which configures which files to backup. More info: https://developer.android.com/training/backup/autosyncapi.html

:warning:
app/src/main/kotlin/co/netguru/baby/monitor/client/feature/babycrynotification/BabyMonitorMessagingService.kt#L3 - Imports must be ordered in lexicographic order without any empty lines in-between

:warning:
app/src/main/kotlin/co/netguru/baby/monitor/client/feature/communication/webrtc/client/RtcClient.kt#L3 - Imports must be ordered in lexicographic order without any empty lines in-between

:warning:
app/src/main/kotlin/co/netguru/baby/monitor/client/feature/communication/webrtc/client/RtcClient.kt#L18 - org.webrtc.* is a wildcard import. Replace it with fully qualified imports.

:warning:
app/src/main/kotlin/co/netguru/baby/monitor/client/feature/communication/webrtc/client/RtcClient.kt#L35 - Expression with labels increase complexity and affect maintainability.

:warning:
app/src/main/kotlin/co/netguru/baby/monitor/client/feature/communication/websocket/RxWebSocketClient.kt#L3 - Imports must be ordered in lexicographic order without any empty lines in-between

:warning:
app/src/main/kotlin/co/netguru/baby/monitor/client/feature/firebasenotification/FirebaseNotificationSender.kt#L3 - Imports must be ordered in lexicographic order without any empty lines in-between

:warning:
app/src/main/res/values/strings.xml#L31 - The resource R.string.feature_maybe_later_btn appears to be unused

:warning:
app/src/main/res/values/strings.xml#L34 - The resource R.string.back appears to be unused

:warning:
app/src/main/res/values/strings.xml#L53 - The resource R.string.isntall_app_title appears to be unused

:warning:
app/src/main/res/values/strings.xml#L54 - The resource R.string.install_app_description appears to be unused

:warning:
app/src/main/res/values/strings.xml#L55 - The resource R.string.done appears to be unused

:warning:
app/src/main/res/values/strings.xml#L56 - The resource R.string.back_underlined appears to be unused

:warning:
app/src/main/res/values/strings.xml#L59 - The resource R.string.done_exclamation appears to be unused

:warning:
app/src/main/res/values/strings.xml#L60 - The resource R.string.continue_text appears to be unused

:warning:
app/src/main/res/values/strings.xml#L69 - The resource R.string.notification_title_sound_processing appears to be unused

:warning:
app/src/main/res/values/strings.xml#L74 - The resource R.string.notification_low_battery_channel_id appears to be unused

:warning:
app/src/main/res/values/strings.xml#L75 - The resource R.string.notification_low_battery_channel_description appears to be unused

:warning:
app/src/main/res/values/strings.xml#L79 - The resource R.string.child_monitoring appears to be unused

:warning:
app/src/main/res/values/strings.xml#L103 - Formatting %d followed by words (“minutes”): This should probably be a plural rather than a string

:warning:
app/src/main/res/values/strings.xml#L115 - The resource R.string.camera_error appears to be unused

          1 Message

:book:
:link: BM-529

JaCoCO Code Coverage 1.24% :white_check_mark:

Class
Covered
Meta
Status

co/netguru/baby/monitor/client/feature/babycrynotification/BabyMonitorMessagingService
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/feature/babycrynotification/CryingActionIntentService
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/feature/babycrynotification/NotifyBabyCryingUseCase
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/common/NotificationHandler
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/data/AppDatabase
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/data/DataRepository
18%
0%
:white_check_mark:

co/netguru/baby/monitor/client/feature/communication/websocket/RxWebSocketClient
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/application/ApplicationModule
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/application/ServiceBindingsModule
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/feature/communication/webrtc/client/RtcClient
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/data/client/ChildDataEntity
0%
0%
:white_check_mark:

co/netguru/baby/monitor/client/feature/firebasenotification/FirebaseNotificationSender
0%
0%
:white_check_mark:

APK file size

size

42.3MB

Number of method references

Dex file
count

classes.dex
36753

  Generated by :no_entry_sign: Danger


feat(add ajv-errors support): add foundation

Information

Type
Breaking change

Feature
No

resolves #1235

Usage example
Customise error messages for decorators:
import {Required} from "@tsed/schema";

class Model {
      @Required().Error("custom message")
      num: number;
}

Add a default ajv message:
@DefaultMsg("foo should be a string")
    class Model {
      property: number;
    }

Add a more global ErrorMsg decorator (not recommended)
class Model {
      @ErrorMsg({type: "foo should be a string"})
      property: number;
    }

Add a TypeError message
@TypeError("foo should be a string")
    class Model {
      property: number;
    }

Todos

[x] Tests
[x] e2e Tests
[x] Coverage
[x] Example
[x] Documentation

@Crunchyman-ralph  Perfect ;)

[x]  Decorators works on class and properties

[ ]  Decorators are correctly exported:

[x]  ErrorMsg
[ ]  TypeError
[x]  RequiredError
[x]  DefaultError

[x]  Ajv is correctly configured with ajv-errors (Edit https://github.com/TypedProject/tsed/blob/production/packages/ajv/src/services/Ajv.ts#L48)

[ ]  Documentation is up-to-date (model.md and ajv.md)

[ ]  Unit test cover correctly the decorators.

[ ]  Integration test cover the success and error cases.

I still have a question about what a typeError represents, is it related to decorators like @Integer() ?
I will do the documentation once we have finished everything to not have to modify it everytime we change something during the review.
Unit tests could have better coverage.

@Crunchyman-ralph TypeError is a simple shortcut decorator which can be used on class, to customize the error message related to type field on json schema ;)
@TypeError("should be an object") // shortcut to ErrorMsg({type: 'msg'})
class MyClass {}

See you :)

[ ]   Documentation is up-to-date (model.md and ajv.md)
[ ]   Integration test cover the success and error cases.

Thanks for the support on this PR romain, I have added the TypeError decorator and noticed how you could using @ErrorMsg with this format (@ErrorMsg({foo:bar}) instead of @ErrorMsg("foo", bar))
So I just decided to change the way the function works, also did a few more fixes.
All that I have left is the documentation and the integration tests.
For the documentation:

where would you put this part of the documentation in the model.md file and the ajv.md file (since we noticed that these changes were specific to spec and not necessarily to ajv, I thought maybe it should only go in model.md ?

For the integration tests:

Where would they go ? Do you have any good examples of any other integration tests by any chance ?

For the documentation:
where would you put this part of the documentation in the model.md file and the ajv.md file (since we noticed that these changes were specific to spec and not necessarily to ajv, I thought maybe it should only go in model.md ?

We can update the model.md b adding a new section :) (ajv is always included in a Ts.ED app)

For the integration tests:
Where would they go ? Do you have any good examples of any other integration tests by any chance ?
Yes, you have two places for that.

If you want to run integration over all platform (Express, Koa), this is the good place:
https://github.com/tsedio/tsed/tree/production/packages/platform/platform-test-utils/src/tests

You have to run yarn test:integration - (run it directly from IDE isn't possible).

If you code isn't really related to a specific platform, you can add the integration test here:

@Romakita I have finally gotten around to getting the end to end tests as well as the documentation down.
It's a shame the documentation doesn't have a search feature, would make things much easier.
Other than that the PR is ready for review and eventually a merge.
It has been a pleasure contributing to this project, I learned a lot (especially with unit tests and e2e tests)

Hello @Crunchyman-ralph

The documentation have search feature on the website:

it use algolia :D
Thanks again for the PR! awesome!

OK just a minor change around the package.json
We will merge the PR. The next step (next PR) will be to wrap all decorators that produce an error message (like Required decorator).
We can wrap the following decorators:

[ ] MinLength/MaxLength
[ ] Min/Max/ExclusiveMin/ExclusiveMax
[ ] MinItems/MaxItems
[ ] MinProperties/MaxProperties
[ ] UniqItems
[ ] Format
[ ] Integer
[ ] MultipleOf
[ ] Pattern
[ ] Enum ?

It should be easy, now that the mechanism is implemented :D

/rebase

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

v7.11.0
GitHub release

Your semantic-release bot :package::rocket:


Always complete the promise

Promise is used only in ZkRepositoryList
A constant field is created in zookeeper class for the duration of wait.
Helper method throws or returns the completed promise.

This the process I followed to test this :

Spun up a local zookeeper on 2181 port. When cosmos boots up, it connects to this zookeeper.
Spun up a cluster in ccm.
Run cosmos in debug mode locally with above dcos cluster.
use dcos cli locally to search for a package

Dcos cli gets response for the search result.
Shutdown zookeeper and after one minute (when the cache invalidates itself) the search result is an error describing the timeout.

@jsancio Updated. is this what you had in mind?


revamp: profile flow; be: integrate profile

Description

[x] Resolves #116

Checklist

[x] I have followed the repository's contribution guidelines.
[x] I have added necessary documentation or updated existing documentation.
[x] My code follows the established code style and formatting of the project.
[x] I have tested my changes and they function as expected.
[x] I have added suitable unit tests (if applicable).

To be reviewed by: @Nasfame @techyNonso

@techyNonso review the UI and if its good, approve it


document dependencies.json format

Add example and explanation of dependencies.json file to README.md.

Added this to README.md in 4963233b31da5141a3bc3fd6ce4b5ada641d7f40


Is the T5 indices to compute dr_in dr_out correct?

https://github.com/SegmentLinking/TrackLooper/blob/master/code/core/write_sdl_ntuple.cc#L1217-L1224
is this correct?
Take a T5:
MD 1
MD 2
MD 3
MD 4
MD 5
I think dr_in = MD1 - 3 (correct)
and dr_out = MD2 - 5 (incorrect)
Am I reading this wrong?

This will be fixed with PR212


Updated LoKr implementation with lycoris support

For context refer this #1935
@BenjaminBossan Here is an early draft PR. Is this how you have envisioned when you meant by a separate implementation of Lokr.

Thanks a lot for this PR. I haven't done an in-depth review yet, but from a first skim, this looks good already. A few points:

Let's ensure that we don't add any new dependencies. The dependency should be optional but it can be added as a dev dependency.
About the name, I wonder if we should go with LycorisLoKr rather than LoKrv2. It's more typing, true, but "v2" is just not very informative. If we stick with "v2", I'd go with LoKrV2Config rather than LoKrConfigv2, etc. I'm also open to other suggestions. WDYT?
Did you already have time to test how the two implementations compare to one another?

About the name, I wonder if we should go with LycorisLoKr rather than LoKrv2. It's more typing, true, but "v2" is just not very informative. If we stick with "v2", I'd go with LoKrV2Config rather than LoKrConfigv2, etc. I'm also open to other suggestions. WDYT?

@BenjaminBossan I feel we should go with LoKrV2 as this is the latest version and we providing support to use lycoris. If we rename it LycorisLoKr it kind of means we are implementing a API for lycoris even though it is a major functionality.

Did you already have time to test how the two implementations compare to one another?

I am confused on how to test it as the problem is lycoris version has too many flag for weights initialization, and I tried but couldn't find the combination for similar initialization of weight for both PEFT LoKr and lycoris Lokr. So tried training it on MNIST with a simple MLP but then the weights  are differing as we are getting difference peformance .
Since I haven't  implemented all the features in Lokrv2 so right now I haven't performed the sanity check of comparing results between upstream and LoKrV2.

I feel we should go with LoKrV2 as this is the latest version and we providing support to use lycoris. If we rename it LycorisLoKr it kind of means we are implementing a API for lycoris even though it is a major functionality.

Well, we can decide later on the naming, but I think LycorisLokr would still be a more descriptive name.

I am confused on how to test it as the problem is lycoris version has too many flag for weights initialization, and I tried but couldn't find the combination for similar initialization of weight for both PEFT LoKr and lycoris Lokr. So tried training it on MNIST with a simple MLP but then the weights are differing as we are getting difference peformance .

Okay, probably we won't manage to get 100% of the same results. It would probably still be worth it to have a script that compares the performance between the two and checks if they roughly match. It could be one of the existing examples in PEFT or the example you came up with.

@BenjaminBossan Please do a first review of this PR. I have trained a simple MLP on MNIST dataset under same config and attached the loss curve plots below to compare different implementations.

Few things from my side:

I haven't implemented the weight decompose and can be done in a separate PR if majority of community want it.
Things done in this PR from the list (Issue 1935)  - fixed rank dropout implementation ,full matrix tuning and  fixed maths (not multiplying against the vector, but only the scalar) is WiP.
Training loss curve is a bit concerning and I need to investigate it.
Added LycorisLokr to existing testcases and will be writing some new test cases too.

I have trained a simple MLP on MNIST dataset under same config

Training loss curve is a bit concerning and I need to investigate it.

Let's try to figure this out first. Did you make some progress on investigating this? If you could share your script, I can also take a look.

Let's try to figure this out first. Did you make some progress on investigating this? If you could share your script, I can also take a look.

This is the notebook I am using for testing: https://colab.research.google.com/drive/12T9CZvSAPcVPi5usXtkbY5G1pvNgDjH7?usp=sharing

Could you extend a little bit, just so I'm clear what is changed where?

In LoKr we were directly dividing the dropout and now I have added the rank_dropout_scale flag
https://github.com/yaswanth19/peft/blob/25f00554bfb259a9e9afbc0c1d8d5ff14203070e/src/peft/tuners/lokrv2/layer.py#L435

Using full matrix now to determine whether to use w1 and w2 https://github.com/yaswanth19/peft/blob/25f00554bfb259a9e9afbc0c1d8d5ff14203070e/src/peft/tuners/lokrv2/layer.py#L137

Mostly scale related corrections; In LoKr we are not calculating scale correctly and not using it in make_kron.

In LoKr we were directly dividing the dropout and now I have added the rank_dropout_scale flag
https://github.com/yaswanth19/peft/blob/25f00554bfb259a9e9afbc0c1d8d5ff14203070e/src/peft/tuners/lokrv2/layer.py#L435
Using full matrix now to determine whether to use w1 and w2 https://github.com/yaswanth19/peft/blob/25f00554bfb259a9e9afbc0c1d8d5ff14203070e/src/peft/tuners/lokrv2/layer.py#L137
Mostly scale related corrections; In LoKr we are not calculating scale correctly and not using it in make_kron.

Thanks for explaining. So this is really in the PEFT code and not so much resolved because we're using lycoris, right? So we could make the same fixes to the existing LoKr implementation too (of course in a separate PR).
Did you check my notebook about reproducibility? I think we should adjust the initialization of parameters to be in line with lycoris and then hopefully see the same results.

So this is really in the PEFT code and not so much resolved because we're using lycoris, right? So we could make the same fixes to the existing LoKr implementation too (of course in a separate PR).

Yes, This could be done. But now I am a bit hesitant on a separate implementation; We mainly have three functional APIs 'weight_genwhich would be used to initialize weights which can be optimized inlycoris,make_kronanddiff_weight` which will not be changed mostly as they are doing fundamental things.
Most of the optimizations/changes are done at module level like weight_decompose, rs_lora, unbalanced_factorization. Even though some are of these are minor ones we can utilize them using the current approach of funcitonal API.
In this case wouldn't it be better to rewrite the original LoKr and periodically(year or two) update the component. In case to effectively use use_upstream feature; author needs to have full feature parity between Functional and Module which is not the case currently.

Did you check my notebook about reproducibility? I think we should adjust the initialization of parameters to be in line with lycoris and then hopefully see the same results.

Yes, I have made the required changes and now we have similar initilalization to lycoris but not same random weights :crying_cat_face: and I am having hard time reproducing same weights both locally and on colab even after setting seed extensicely.
Colab link: https://colab.research.google.com/drive/1YxlaT9G_jotkoTrEMQIQwNX87lehcMHu?usp=sharing

Thanks a lot @yaswanth19 for sharing your thoughts on this. When reviewing the PR, I was a bit astonished how little of the lycoris package we're actually using.
As to the question of whether it's worth it to have this separate LoKr implementation or if we should rather fix the existing one: Depending on lycoris has the advantage that each time there is a fix or improvement there, we automatically benefit from it, which is nice. However, checking the lycoris/functional/lokr.py file, there was no change in the past 4 months (besides the docs), so I'm not sure how it plays out in practice. And as mentioned, we're not using a lot of it in the first place.
The disadvantage in my eyes is that we create more confusion for users, have a higher complexity in our code base, and to avoid breaking backwards compatibility, we would need to maintain the existing LoKr implementation anyway.
If your work on this PR has helped you identify the issues with the existing LoKr implementation, I would be super happy if you could work on fixing those. If you do that, there is even less necessity for the alternative implementation. But it could be that I'm missing some arguments, so if @bghira or @sayakpaul have different opinions, please let me know.
In case we decide to go with fixing the existing implementation instead of adding the new one, I would propose that we elaborate the test notebook, e.g. to be a standalone script. Then we can use it to compare the results from the lycoris implementation to PEFT and ensure that they're close. This could be run daily or weekly on CI. Of course, we would need to extend the script to cover a few more cases, like conv layers and some of the edge cases discussed in the initial issue.

Yes, I have made the required changes and now we have similar initilalization to lycoris but not same random weights 😿 and I am having hard time reproducing same weights both locally and on colab even after setting seed extensicely.

Don't worry too much about that. It would be exceedingly hard to get the exact same outcome using PEFT and lycoris, because we would need to ensure that each call involving randomness is executed exactly the same and in the same order.

@bghira @sayakpaul A gentle ping for your thoughts on the above discussion.

If your work on this PR has helped you identify the issues with the existing LoKr implementation, I would be super happy if you could work on fixing those. If you do that, there is even less necessity for the alternative implementation.

I am not opposed to the idea, but I guess it depends on the amount of work and the effectiveness of the implementation. From what I understand we're already having to touch many lines of code in the existing implementation, so might as well just fix them at this level instead of a separate implementation?

Not stale

Gently pinging @yaswanth19 @BenjaminBossan

Now that #2180 is merged, I'm not sure if this PR is still needed.

i haven't really checked it but i'm not sure that it helps with loading models created by the lycoris library, that probably needs additional state dict key mangling
i think it fixed some bugs in the current LoKr implementation but did not align the two and still leaves the lycoris library as a better candidate for finetuning lycoris models..


To do: work on editSessionActive function in utilityFunctions

The current method of editSessionActive looks to see if a runtime error is generated by trying to open two concurrent update cursors on the same table. It tries to do this on either the GeoMaterialDict or MapUnitPolys table. A simpler and more schema-agnostic way would be to look for the presence of .ed.lock files in the geodatabase.
def editSessionActive(gdb_path):
    if glob.glob(os.path.join(gdb_path, '*.ed.lock')):
        edit_session = True
    else:
        edit_session = False

    return edit_session

At this time, geopackages cannot be edited with the interactive tools in ArcMap or Pro (https://www.esri.com/arcgis-blog/products/product/data-management/how-to-use-ogc-geopackages-in-arcgis-pro/) so I believe there could never be an active edit session on a geopackage. The function could return False if the gdb_path ends in .gpkg.
The python toolbox version of the tools uses this method.

Can't delete this issue, but I no longer want to log issues here. Started a page in the Wiki called 'Known Issues' where I will try to collect them all in one place. Just closing this for now so it doesn't show up every time for everyone visiting the page.


Payments over 300k doesn't go through

Hey Mutiny,
Payments with an amount over 300k doesn't work.
I tried different Wallets (Wos, Phoenix, Own node)
I funded the wallet with 1M SATs via Lightning.
Maybe you can have a look
Greetings Nico

Sometimes that happens.


"Error parsing spec file: unknown field lightSyncState at line 256 column 1"

update tools, fixed it


Add some tests for the tran package

Codecov Report

Merging #54 (c77a16f) into main (a57676b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #54   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           41        41
  Lines         1306      1306
=========================================
  Hits          1306      1306

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Lights turn on after log "set homekit last boot from[DATE]"

Issue

Hey Folks,
I'm new to Git.
My Problem is, that sometimes Lamps in my Environment turn on "by themselves" as it seems.
I was away for one week and came home to a stagelike bright livingroom.
I could find following in my Log:
Log Messages

[25.12.2020, 02:40:00] [Hue] LED Strip Sofa: set homekit last boot from Thu Dec 24 2020 03:19:56 to Fri Dec 25 2020 02:40:00
[25.12.2020, 02:40:00] [Hue] LED Strip Sofa: set homekit on from 0 to 1
[25.12.2020, 10:40:37] [Hue] LED Strip Fernseher: set homekit last boot from n/a to Fri Dec 25 2020 10:40:37
[25.12.2020, 10:40:37] [Hue] LED Strip Fernseher: set homekit on from 0 to 1

so yep, my lamps had been on since then...
Debug Files

homebridge-hue.json.gz

Best Regards and a good start in a better year 2021,
Welli

The message means that the light firmware booted (powered on).  Could be because the light was temporarily disconnected from power, could be a bug in the firmware (not likely if this happens to multiple lights at the same time).  Apparently these lights turn on when powered.  Some lights support configuring the power-on behaviour, but not all.  For lights that don’t support power-on configuration, you would need to setup some automation to turn them off after they power on.  That’s where Last Boot comes in handy.  Of course, if you’re (living with) one of those heretics that insist on using 20th century wall switches, you want the light to turn on when powered on.

wow thanks for that quick reply!
ok, I tried setting the deconz "PowerOn" Tag but I failed... I edited the lines as in this #1055 case but I couldn't get it to work.

Those are needed only if you want to set a power-on colour.  You need to set the PowerOn OnOff attribute 0x4003 in the On/Off cluster 0x0006 in the GUI.  If you read that attribute and it greys out, the light doesn't support it.

In my Environment only one Ikea E14 lamp does the same. Again and again:
Can anyone help me?
[05/01/2021, 19:42:57] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:42:39 to Tue Jan 05 2021 19:42:57 [05/01/2021, 19:42:58] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:42:57 to Tue Jan 05 2021 19:42:58 [05/01/2021, 19:42:59] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:42:58 to Tue Jan 05 2021 19:42:59 [05/01/2021, 19:43:02] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:42:59 to Tue Jan 05 2021 19:43:02 [05/01/2021, 19:43:19] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:02 to Tue Jan 05 2021 19:43:19 [05/01/2021, 19:43:21] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:19 to Tue Jan 05 2021 19:43:21 [05/01/2021, 19:43:23] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:21 to Tue Jan 05 2021 19:43:23 [05/01/2021, 19:43:40] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:23 to Tue Jan 05 2021 19:43:40 [05/01/2021, 19:43:43] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:40 to Tue Jan 05 2021 19:43:43 [05/01/2021, 19:43:45] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:43 to Tue Jan 05 2021 19:43:45 [05/01/2021, 19:44:02] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:45 to Tue Jan 05 2021 19:44:02 [05/01/2021, 19:44:03] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:02 to Tue Jan 05 2021 19:44:03 [05/01/2021, 19:44:04] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:03 to Tue Jan 05 2021 19:44:04 [05/01/2021, 19:44:07] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:04 to Tue Jan 05 2021 19:44:07 [05/01/2021, 19:44:24] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:07 to Tue Jan 05 2021 19:44:24 [05/01/2021, 19:44:26] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:24 to Tue Jan 05 2021 19:44:26 [05/01/2021, 19:44:29] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:26 to Tue Jan 05 2021 19:44:29 [05/01/2021, 19:44:46] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:29 to Tue Jan 05 2021 19:44:46 [05/01/2021, 19:44:47] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:46 to Tue Jan 05 2021 19:44:47 [05/01/2021, 19:44:48] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:47 to Tue Jan 05 2021 19:44:48 [05/01/2021, 19:44:50] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:48 to Tue Jan 05 2021 19:44:50

In my Environment only one Ikea E14 lamp does the same. Again and again:
Can anyone help me?
[05/01/2021, 19:42:57] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:42:39 to Tue Jan 05 2021 19:42:57 [05/01/2021, 19:42:58] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:42:57 to Tue Jan 05 2021 19:42:58 [05/01/2021, 19:42:59] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:42:58 to Tue Jan 05 2021 19:42:59 [05/01/2021, 19:43:02] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:42:59 to Tue Jan 05 2021 19:43:02 [05/01/2021, 19:43:19] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:02 to Tue Jan 05 2021 19:43:19 [05/01/2021, 19:43:21] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:19 to Tue Jan 05 2021 19:43:21 [05/01/2021, 19:43:23] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:21 to Tue Jan 05 2021 19:43:23 [05/01/2021, 19:43:40] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:23 to Tue Jan 05 2021 19:43:40 [05/01/2021, 19:43:43] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:40 to Tue Jan 05 2021 19:43:43 [05/01/2021, 19:43:45] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:43 to Tue Jan 05 2021 19:43:45 [05/01/2021, 19:44:02] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:43:45 to Tue Jan 05 2021 19:44:02 [05/01/2021, 19:44:03] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:02 to Tue Jan 05 2021 19:44:03 [05/01/2021, 19:44:04] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:03 to Tue Jan 05 2021 19:44:04 [05/01/2021, 19:44:07] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:04 to Tue Jan 05 2021 19:44:07 [05/01/2021, 19:44:24] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:07 to Tue Jan 05 2021 19:44:24 [05/01/2021, 19:44:26] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:24 to Tue Jan 05 2021 19:44:26 [05/01/2021, 19:44:29] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:26 to Tue Jan 05 2021 19:44:29 [05/01/2021, 19:44:46] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:29 to Tue Jan 05 2021 19:44:46 [05/01/2021, 19:44:47] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:46 to Tue Jan 05 2021 19:44:47 [05/01/2021, 19:44:48] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:47 to Tue Jan 05 2021 19:44:48 [05/01/2021, 19:44:50] [Hue] Licht TV: set homekit last boot from Tue Jan 05 2021 19:44:48 to Tue Jan 05 2021 19:44:50

one Ikea E14 lamp does the same

Do you mean: turn on spontaneously?  Does the bulb remain on or does it turn off and back on?

one Ikea E14 lamp does the same

Do you mean: turn on spontaneously?  Does the bulb remain on or does it turn off and back on?

@Welli1994 @riconr1  did you find a solution to this? I'm having the same issue but my light is turning on around the same time every night in the middle of the night. Unfortunately it is my nightstand light so it wakes me up at ~2:30am :(
I noticed that it happens shortly after homebridge UI does its scheduled update, so I've just disabled that. I've also updated the firmware on my bulb using the Philips hue bluetooth app. We'll see how it goes tonight...
[3/21/2021, 2:32:12 AM] [Homebridge UI] Creating temporary backup archive at /tmp/homebridge-backup-mDHkAd/homebridge-backup-CB223DE2CE31.tar.gz
[3/21/2021, 2:34:45 AM] [Hue] Lamp: set homekit transition control to ""
[3/21/2021, 2:36:01 AM] [Hue] Deans nightstand: set homekit last boot from Sat Mar 20 2021 06:08:51 to Sun Mar 21 2021 02:36:01
[3/21/2021, 2:36:07 AM] [Hue] Deans nightstand: set homekit last boot from Sun Mar 21 2021 02:36:01 to Sun Mar 21 2021 02:36:07
[3/21/2021, 2:36:09 AM] [Hue] Deans nightstand: set homekit on from false to true
[3/21/2021, 2:36:13 AM] [Hue] Deans nightstand: set homekit last boot from Sun Mar 21 2021 02:36:07 to Sun Mar 21 2021 02:36:13

I'm experiencing the same. I have an Ikea lightbulb "TRÅDFRI bulb E27 opal 1000lm" controlled by ConBee 2. Each time message "set homekit last boot" appears in logs the bulb changes state for a moment (from off to on or from on to off).
@dalovering did the problem disappear for you or are you still experiencing it?

@blazejpawlak it never went away 😔 I reset the bulb, updated its firmware, and no changes. I started powering it off at night from the physical switch so it wouldn’t turn on and wake me up, but when I powered it back on in the morning it would flash randomly for a few minutes. I determined it was a faulty bulb so I put in a warranty request with philips and they are sending a replacement.
FYI the “set HomeKit last boot” comes on when a bulb is powered on or when it reboots.

@dalovering thanks for sharing that info. Perhaps mine is about to die soon. I'll get a replacement at Ikea then.


Checkout with digital product and removed physical product

What I'm trying to achieve
Create checkout.
Checkout lines add/update/delete can change selected shipping method in checkout. We should synchronise shipping method with backend.
Steps to reproduce the problem

Add shippable product
Add non-shippable product
Add shipping method
Remove all shippable product, left an only non-shippable product
Shipping method doesn't exist on backend side but storefront doesn't refresh checkout.

This issue is blocked by #400


Set the value of BlockTimestamp when consuming V2 messages

Sarama is not setting the value of BlockTimestamp when consuming V2 messages, but it is when consuming V1 messages.
Other kafka clients only expose 1 timestamp, so recommendations are:
1. set BlockTimestamp for consistency between V1 and V2
2. remove BlockTimestamp,

@bai what do you think about this. Let's find a common ground and then I can work on it?


pubspec.yaml is not getting updated with flutter packages upgrade

Steps to Reproduce

I had an existing project running on Flutter version 1.5.4+hotfix.2
I used the flutter upgrade command to upgrade to the latest version i.e 1.9.1. This should upgrade flutter as well as all the packages being used.
After flutter upgrade, I can see some of the package version upgrades in pubspec.lock but none in pubspec.yaml.
I tried manually running flutter packages upgrade but that didn't serve any purpose.
All the dependencies are still using their previous version in pubspec.yaml and not being updated to their latest versions.

Output of flutter doctor -v:
[✓] Flutter (Channel stable, v1.9.1+hotfix.2, on Mac OS X 10.14.4 18E226, locale
    en-IN)
    • Flutter version 1.9.1+hotfix.2 at /Users/shivam/sdks/flutter
    • Framework revision 2d2a1ffec9 (10 days ago), 2019-09-06 18:39:49 -0700
    • Engine revision b863200c37
    • Dart version 2.5.0

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /Users/shivam/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.3, Build version 10G8
    • CocoaPods version 1.6.1

[✓] Android Studio (version 3.5)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 39.0.3
    • Dart plugin version 191.8423
    • Java version OpenJDK Runtime Environment (build
      1.8.0_202-release-1483-b49-5587405)

[!] IntelliJ IDEA Community Edition (version 2019.1.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    • Dart plugin version 191.7019
    • For information about installing plugins, see
      https://flutter.dev/intellij-setup/#installing-the-plugins

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

[✓] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 9 (API
      28) (emulator)

! Doctor found issues in 1 category.

This is by design. flutter packages upgrade never touches your pubspec.yaml maybe vote for this issue https://github.com/flutter/flutter/issues/12627 which would make it easier to update your pubspec.yaml manually after an upgrade.
I recommend using any if you don't have to use a specific version.

@escamoteur What's the point of upgrading the package versions in pubspec.lock then? I believe when we run the app, it uses the versions specified in pubspec.lock and not from pubspec.yaml.
Am I right?

Yes indeed it will use that in pubspec lock. The poitn is that you can have in your pubspec: some_package: '^1.0.1' which means you allow package upgrade to use any package >1.0.1 but smaller '2.0.0'  see https://dart.dev/tools/pub/versioning#semantic-versions
But somewhere the actually selected versions have to be stored. This is done in pubspec.lock. Thats also why you should include that file in source control so that everyone checking out the project gets the same versions

After running pub upgrade and re-testing my app:
Is there any way to port the higher dependency numbers in pubspec.lock to pubspec.yaml?
(Apart from the obvious way of copying by hand, of course...)

This is by design. flutter packages upgrade never touches your pubspec.yaml maybe vote for this issue #12627 which would make it easier to update your pubspec.yaml manually after an upgrade.
I recommend using any if you don't have to use a specific version.

i remember when i started with flutter that it highlights libs that can be upgraded to a higher version.
then im not sure when at some point it does not work anymore.
i like it better that pubspec.yaml is affected instead of .lock

Opening 'widget_test.dart' and running it solved my issue


Revert "Only show Management Dashboard button for user datasets"

Reverts VEuPathDB/web-monorepo#1003
This logic is not correct. If anything, we only want to show the button if a study has any access restrictions.

Force-merging so this can get to qa asap

frankly i would just  fix the bug for now.. so it only shows when needed..
danica describes a situation when it will be needed in public studies (in qa sites providers wont be able to see other providers studies even if public)
but that might not be the case for a while and i rather eliminate clutter..  and will be clue on how things are working.

in qa sites providers wont be able to see other providers studies even if public

I don't really understand this. Who exactly would it be "public" for?
Anyhow, I will work on a fix for not showing the button for public studies soon.


Set operators (eg (+), (-)) throw an exception

The generic solution is to have the macro for the F# +, - and other operators translate to a trait calls on op_Addition, op_Substraction and so on. This needs support for multiple-type trait calls to do properly.


Discussion: Extend GlobalConsensus junction to include a Bridge ID

The GlobalConsensus junction signifies that a network is capable of externalizing its consensus system to other global consensus systems. However, I believe there is a piece of information missing. This externalization is always mediated via a bridge between the two consensus systems. Without a bridge, the externalization could not occur.
I propose for XCMv4 that we extend the GlobalConsensus junction to include the ID of the bridge:
GlobalConsensus(NetworkId, BridgeId)

I believe this change improves the semantics of XCM MultiLocations when it comes to identifying bridged assets on Polkadot.
Consider the following scenario with the existing XCMv3 language. We can represent the location of the ERC20 DAI token relative to Polkadot using the following notation:
/GlobalConsensus(Ethereum)/AccountKey20(DAI)

Suppose two different bridges want to transfer DAI to Statemint. There will be a clash, as they would both like to use /GlobalConsensus(Ethereum)/AccountKey20(DAI) identify their assets within the Polkadot.
To work around this, they could add an extra "dummy" junction like GeneralIndex or AccountKey20 to disambiguate:
/GlobalConsensus(Ethereum)/AccountKey20(SomeBridgeSpecificContract)/AccountKey20(DAI)
However, this does not really reflect Ethereum's consensus hierarchy all that well, as Ethereum doesn't have nested contracts. DAI is not really contained within SomeBridgeSpecificContract. So I feel it would be better to include the bridge id within the GlobalConsensus junction.

Could you explain what problems there are for clashing? I actually don't believe that there is a clash; in fact, it's working as intended when 2 MultiLocations are pointing to the same location -- it just means that they're representing the same asset, which is exactly the case here.
What you seem to be indicating is that the assets on the 2 different bridge contracts are not the same, which is a completely separate problem.

What you seem to be indicating is that the reserve assets on the 2 different bridge contracts are not the same, which is a completely separate problem, and can be solved by simply using separate MultiLocations for each of them, as they are in fact not the same asset.

This makes good sense, come to think of it We shouldn't be using /GlobalConsensus(Ethereum)/AccountKey20(DAI) to represent bridged DAI on Statemine, because bridged DAI is really a derivative asset, backed by real DAI locked up in a vault in ethereum.

What you seem to be indicating is that the reserve assets on the 2 different bridge contracts are not the same, which is a completely separate problem, and can be solved by simply using separate MultiLocations for each of them, as they are in fact not the same asset.

I've changed my mind on this.
Actually the two different bridge contracts on Ethereum both hold the same DAI token in reserve. They are the same asset. In fact the way its implemented in Ethereum is that the DAI contract itself is actually the consensus system that holds the reserves. It has an internal ledger that says an account for Bridge X has so many tokens in reserve, and and and account for Bridge Y has so many tokens in reserve.
However synthetic assets on AssetHub derived from these foreign reserves are not fungible with each other. That said, its still convenient and useful to be able to identify the synthetic assets using the contract address of the foreign token.
The alternative is to just identify the synthetic asset using a location of the form /Para(AssetHub)/PalletIndex(X)/GeneralIndex(Y), where Y is some randomly allocated asset ID. But then we've lost the discoverability aspect, compared to /GlobalConsensus(Ethereum)/AccountKey20(DAI)
Adding a BridgeID allows to discriminate between synthetic assets derived from the same foreign token, while maintaining the discoverability aspect.


from_str doesn't work for wildcards/Star

Didn't see an issue tracked for this. Was going to try and fix this this weekend.

Related to iron/iron#385.

I'm not sure what you mean. Have a test case that fails? It certainly looks like it should work.

I was running it on nightly and from_str("/") didn't work for me. I'll investigate more.

Oh you're right, it doesn't work. The current code follows this spec's ABNF, which doesn't allow a * character. I suppose some checks before entering that parsing would need to be done to check for things like */*, anything/*, etc...

It's also documented in hyper here.

This was fixed in  0.2.3


Address issue with SiteGOF

per @doug-friedman : "The original SiteGoF function was returning NAs for the monthly goodness-of-fit statistics calculated for the January to September (e.g. the documented example should return all 0s and 1s)."

@doug-friedman addressed this issue  here 03cafaad26205a0957e18f43365c11ff3ad4699e , but code needs to avoid dplyr piping before being merged. I will address this and remove dplyr::arrange until package is transitioned to dplyr

Started working on this.
First thing that becomes apparent is that the data.frame input is not defined in the help. Additionally, the testthat test does not have the proper inputs, on has class date other has class posix


rbd: modify ensureImageCleanup() to be best effort

The function ensureImageCleanup(), called when images to be deleted are not found, ensures that these images if in trash have a task on them to be removed from trash.
This scenario is an extreme edge case and it is an expensive operation to list images in trash depending on the number of images in trash and , therefore this commit modifies code to only log the errors rather than returning it which causes a retry of the whole request.
Closes: #3593
Signed-off-by: Rakshith R<EMAIL_ADDRESS>

The function ensureImageCleanup(), called when images to be deleted are not found, ensures that these images if in trash have a task on them to be removed from trash.
This scenario is an extreme edge case and it is an expensive operation to list images in trash depending on the number of images in trash and , therefore this commit modifies code to only log the errors rather than returning it which causes a retry of the whole request.
Closes: #3593
Signed-off-by: Rakshith R<EMAIL_ADDRESS>
@Rakshith-R I agree this is a best effort, but this can leave the stale resources in the cluster what is the measure to remove the stale resources?
There was a bug in the go-ceph code which was using less value for the list operation, it's been a workaround with the larger value. IMO the actual fix should come from the go-ceph, not at the cephcsi level.

@Rakshith-R I agree this is a best effort, but this can leave the stale resources in the cluster what is the measure to remove the stale resources? There was a bug in the go-ceph code which was using less value for the list operation, it's been a workaround with the larger value. IMO the actual fix should come from the go-ceph, not at the cephcsi level.

IMO, I see a better trade off in  very rarely (this is an extreme edge case) leaving behind a stale resource in trash rather than blocking all delete requests &/ repeating such expensive operation (listing large number of images in trash) which also ends up slowing down other operations too(create,clone,snapshot, etc.,).
let me know what you think,

:+1:
We'll have to find another way then, closing this pr


Update Providers docs with YAML explicit provider config

Hello!

Vote on this issue by adding a 👍 reaction
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details
Update Providers docs with YAML example to instantiate an explicit provider, i.ee pulumi:provider:Foo
Affected area/feature

Please take a look at https://github.com/pulumi/pulumi-hugo/pull/1767

Please take a look at pulumi/pulumi-hugo#1767

That is very good timing


sensors: Implement MPU9250 driver

MPU9250 driver for 9-axis
gyroscope, accelerometer, magnetometer
Signed-off-by: Dominik Chat<EMAIL_ADDRESS>

@MaureenHelm @gmarull could you please take another look?


Email is green if no firing alerts

@stuartnelson3
Emails that contain no firing alerts should not be red. This makes them green.
#859 was a past (never merged) attempt to do something similar, but this is simpler

Thanks!


update scala

minor bump in logging jars too

Agree with @He-Pin lets do our best to not do multiple things in same PR. Its nice to maintain a clean git log especially when we need to cherry pick (i.e. we typically backport Scala upgrades but not general dependency updates).

Agree with @He-Pin lets do our best to not do multiple things in same PR. Its nice to maintain a clean git log especially when we need to cherry pick (i.e. we typically backport Scala upgrades but not general dependency updates).

there is no branch to backport to - main is the only branch


x/pkgsite: ./prog.go:33:2: invalid character U+200B in identifier
./prog.go:33:5: invalid character U+0023 '#'
./prog.go:33:6: invalid character U+200B in identifier
./prog.go:33:6: syntax error: unexpected  This workflow will run tests using node and then publish a package to GitHub Packages when a release is created at end of statement
./prog.go:33:9: invalid character U+00A0 in identifier
./prog.go:34:2: invalid character U+200B in identifier
./prog.go:34:5: invalid character U+0023 '#'
./prog.go:34:6: invalid character U+200B in identifier
./prog.go:34:6: syntax error: unexpected  For more information see at end of statement
./prog.go:34:9: invalid character U+00A0 in identifier
./prog.go:34:6: too many errors
Go build failed.

What is the URL of the page with the issue?
What is your user agent?

Screenshot

What did you do?

What did you expect to see?
Output:
./prog.go:33:2: invalid character U+200B in identifier
./prog.go:33:5: invalid character U+0023 '#'
./prog.go:33:6: invalid character U+200B in identifier
./prog.go:33:6: syntax error: unexpected  This workflow will run tests using node and then publish a package to GitHub Packages when a release is created at end of statement
./prog.go:33:9: invalid character U+00A0 in identifier
./prog.go:34:2: invalid character U+200B in identifier
./prog.go:34:5: invalid character U+0023 '#'
./prog.go:34:6: invalid character U+200B in identifier
./prog.go:34:6: syntax error: unexpected  For more information see at end of statement
./prog.go:34:9: invalid character U+00A0 in identifier
./prog.go:34:6: too many errorsWhat did you see instead?

Thank you for raising this issue. The contents of ./prog.go appear to be a shell script, not a Go file. Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.
For asking questions, see:

Stack Overflow with questions tagged "go"

Gophers Slack, use the invite app for access. The #general channel is a good starting point.

The golang-nuts mailing list


Add support for named argument functions

This commit support functions with argument names.
the format is : "Select * from ( a => exp, b=> exp2 .. )
see:
https://jakewheat.github.io/sql-overview/sql-2016-foundation-grammar.html#named-argument-assignment-token
or example in snwflake db :
https://docs.snowflake.com/en/sql-reference/functions/flatten.html

Sorry about some style changes that made by cargo fmt

Pull Request Test Coverage Report for Build 187373027

38 of 41 (92.68%)  changed or added relevant lines in 4 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.006%) to 91.75%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/parser.rs
6
7
85.71%

src/tokenizer.rs
16
18
88.89%

Files with Coverage Reduction
New Missed Lines
%

src/tokenizer.rs
1
91.57%

Totals

Change from base Build 186377189:
0.006%

Covered Lines:
4426

Relevant Lines:
4824

💛  - Coveralls

I find it weird that you added NamedArgument as a new variant of Expr. This makes the parser accept many weird constructs, which shouldn't be accepted. I expected this to be a new SelectItem-like enum. You can use peek_nth_token(1) == RArrow to determine if it's a named argument.
The argument name is a simple identifier, not an ObjectName.
Please check the PR for typos (FUCNTION, rigth, agument, // vs /// (which led to rustfmt reformatting the whole enum))

the format is : "Select * from ( a => exp, b=> exp2 .. )

Surely you meant SELECT myfunc(args) rather than FROM (args)

Sorry for all the typos , I fixed them (Hope that all of them..)
I also changed the the object name to ident - and fixed the commit message with the correct query .
But i don't sure what you means when you say that the named-argument should be SelectItem
It's a comma-separated argument list that passed to function, In the struct Function the args is comma-separated Vec<Expr> , And because that my thought was that creating new Expr type will be the best suit .

I said a new enum, a little like SelectItem (currently with two variants: unnamed argument, named argument).

I done the changes according to comments .

Thanks!


[Improve] Localization streampark-usercase-haibo

cc: @saLeox

https://github.com/apache/incubator-streampark/issues/3218

apache/incubator-streampark#3218apache/孵化器-streampark#3218

Thank U

@saLeox Thx,I modified them.

LGTM