[QUESTION] Keep the changed value in a variable

When you change the value in a variable, it resets into InitialValue after scene stop. How to keep the changed value after exiting play mode?

why would you want that?
if you seek for persistence, you need some kind of serialization system. when building the game, the serializable objects won't keep the state persistant accross playthroughs, so they shouldn't do it in the editor. it's to prevent errors.

why would you want that?
if you seek for persistence, you need some kind of serialization system. when building the game, the serializable objects won't keep the state persistant accross playthroughs, so they shouldn't do it in the editor. it's to prevent errors.

We have an online game and game client receives remote configuration from online server. We are looking to add option to keep the values that server sent for offline development in Unity Editor.
With that our designers will connect to server only once, after that, they are able to work offline without connecting to server again because values are there.

either:

generate a config file from the values sent by the server and use that to fill the atoms on the first frame.
store those settings in a custom ScriptableObject instead of an Atom, they keep their values in the editor.
Add a custom menu item to download the config from a server into the atoms while in edito mode

I'm sorry, but changing Atoms such that they don't go back to the initial value would be very counter intuitive in many/all other places.

either:

generate a config file from the values sent by the server and use that to fill the atoms on the first frame.
store those settings in a custom ScriptableObject instead of an Atom, they keep their values in the editor.
Add a custom menu item to download the config from a server into the atoms while in edito mode

I'm sorry, but changing Atoms such that they don't go back to the initial value would be very counter intuitive in many/all other places.

Why not have it as an opt-in feature?

Why not have it as an opt-in feature?

to prevent missuse? The whole point behind scriptable variables is that they feel like real variables, but can easily be shared.
if you want a plain "unity scriptable object" you can easily create one, if you want to use an atom you can use an atom, the library suggests an architecture/a workflow.

If you look at the Original Talk that all of this is based on, you can see that another Variable Scriptable Object is used for resetting the values.

that is the case for the simple Health example. I've used Atoms within game jams with multiple people and you can trust me: resetting to the initial value is a huge benefit when you run your build and bugs start to appear you can't wrap your head around.
it also saves a monobehavior that resets all your variables. it also fixes the problem of handling which monobehavior should handle the reset.
I said it multiple times in discord, but I think it cannot be said enough: UnityAtoms is a tool, use it where it is applicable. you wouldn't use a hammer where you want a saw. Why do you want to cram unity atoms in a place where a simple ScriptableObject would be your best option?

Why do you want to cram unity atoms in a place where a simple ScriptableObject would be your best option?
Simple ScriptableObject is not my best option. Scriptable** Object Architecture that was presented in the talk is there to provide an easy way for designers to tweak game variables and sharing game state. My use case is the designer-friendly use case, but somehow you insist that this tool should not support it.

I do not suggest, not using Atoms at all, but just for this single use case.
Just create a scriptable object, with all variables for your server config. Create an asset from it. success.
it has all properties you want: it keeps the values when leaving play mode. Its references can be shared. I mean ... IT IS a ScriptableObject
what you don't have in a simple SO: change events.
I'm sorry, but I cannot see the greater benefit in making reseting the value optional.
I'd suggest to make the OnEnable method protected virtual, so you can override them in when you need it.

@soraphis I think it is a good idea to make more methods overridable, like OnEnable.
My first reaction to making the reset optional for Variables is that it's not something we would like to do. I agree with @soraphis here that it makes Atoms too cluttered (I believe that it might already be too cluttered) and hard to understand. With that said, I would like to understand your project setup a little bit better. So you have a server where you in editor mode wants to grab values from and then work with those values when working offline. Why can't you set initial value of the Atoms with the values from the server? Could you please describe your setup a little bit more in detail so we can understand your use case better?

With that said, I would like to understand your project setup a little bit better. So you have a server where you in editor mode wants to grab values from and then work with those values when working offline. Why can't you set initial value of the Atoms with the values from the server? Could you please describe your setup a little bit more in detail so we can understand your use case better?

Our game is an always online game. So users need to be always online in order to enter the game.
So here is the flow of data in a normal environment (when unity editor is online or game is in production (on device)):
[Database] -> [Server] -> [Scriptable Objects that hold single values] -> [Game components that need single values (ex. movement speed)]
Here Unity Atoms are perfectly OK and cover the use case. And variable resetting does not cause
any problems. (Game can be in runtime so scriptable objects would lose their values anyway).
The use case that Unity Atoms does not support is designer-friendly use-case. Being always online is  a bad requirement for development and testing. Since it slows people down.
So what we decided was that game should be able to work without server connection.
Now the data flow is like this:
[Scriptable Objects that hold single values] -> [Game components that need single values (ex. movement speed)]
So now our designers are able to tweak values in variables and see the results right away.
But when they stop the game all the tweaks will be gone and will reset to original values from server. (right?)
Our target workflow that we looking to achieve is that every designer should be able to connect to server once, fetch all the required values to run the game.
Then every designer can get offline, work on their specific area and tweak variable values, and then when they are happy with what they have in their editor, they can write variables on DB so others can get the updated values when they get online.
P.S: You guys have used Unity Atoms in a couple of games, How did you fine tune the variables?

But when they stop the game all the tweaks will be gone and will reset to original values from server. (right?)

this is also the case for any other component or object in the scene. unity atoms is even better as InScene objects as it has still stored the latest "Value" in the Value field, just copy the Value to the InitialValue after leaving play mode.
I see how it is a problem for your specific use case, but Atoms behave in a consistent manner to Unity and between release builds and in-editor play mode

this is also the case for any other component or object in the scene. unity atoms is even better as InScene objects as it has still stored the latest "Value" in the Value field, just copy the Value to the InitialValue after leaving play mode.
Except that Scriptable Objects are not In Scene game objects. And "just copy the Value to the InitialValue after leaving play mode." is not acceptable at all. I don't know why you even mentioned it.

summing it up:

removing the initialValue reset, does (imho) not fit into the unity and UnityAtoms workflow.
making the reset optional is for me a no-go not every feature should be opt-in. especially if the default fits 99% of all use cases (if it would be a 50/50 thing or a 60/40 -> okay make it optional, but like this)
we should allow more inheritance, to allow users to redefine certain behaviors if they insist to.

@mnarimani alternatives I've presented to you in this thread, from best to worst:

use a single ScriptableObject for all your server configurational values. tweak those.

you may use this SO in a script to fill the values into Atoms

Create an custom Atom Type where you implement the OnEnable method that it does not reset to initialValue (this works, even if the OnEnable in the parent is not virtual, due to how unity calls those methods)
copy the Value to InitialValue after leaving play mode...

or create a custom editor script, that handles this for you

But, can you answer this question? You have used this plugin in a couple of games. How do you fine your game variables?
Because what I see, Your plugin design and mindset is completely ignoring this vital feature.

First of all, please keep the conversation civil. No need to be rude to each other (not pointing any fingers, just pointing it out).
@mnarimani I believe that using Constants instead of Variables would be preferable in your case. Constants are meant to be used for configuration values (eg. walk speed, run speed, initial attack rate, etc). You can set its value in runtime using the BaseValue property. There might be a case here for making it ok to set the value via the Value property (that is atm throwing if used). Would using Constants suffice for your case?

But, can you answer this question? You have used this plugin in a couple of games. How do you fine your game variables?
Because what I see, Your plugin design and mindset is completely ignoring this vital feature.

I use Atoms mostly for the easy cross-scene/cross-gameobject references.
Having health for the player and as UI element, but UI is in another scene? no problem its a FloatVariable now. e.g.
I've had hooked AtomEvents and AtomActions in my own Dialog system (btw. I'm working on an AtomBased Dialog system as package) to trigger state changes and stuff.
I don't use Atoms for GameConfig and Database. In the last project where I used atoms, I used the Unity GameFoundation package for inventory stuff, so fine tuning Item-stats was in there.
As Adam said: When I need a specific start value or stuff like this, I usualy have a AtomConstant with that value. And a script that uses this constant to fill the variable on game start.
@AdamRamberg we could add ImmutableVariableReference deriving from VariableReference, where you can choose between a value and a AtomConstant but not from AtomVariables.
And use for InitialValue a ImmutableVariableReference.

@AdamRamberg we could add ImmutableVariableReference deriving from VariableReference, where you can choose between a value and a AtomConstant but not from AtomVariables.
And use for InitialValue a ImmutableVariableReference.

@soraphis I think this is a good idea for the library, but I don't think however that it will solve the use case for @mnarimani, since it will be hard to reliably call the API to get the values + adding to the Constant / Immutable Ref before OnEnable is called for each Variable.

I think it's better to just have this "value persistence" behavior in my own fork.
Can you guide me to points in the code that resets happen/I need to change?

@mnarimani The reason why O'm not 100% convinced to make it possible to opt-out resetting the Variable when entering editor play mode is that Variables are designed for holding a runtime value  that could be shared and observed by other scripts in a modular fashion. For example Variables are designed to hold units' health / mana, user's volume settings or the state of an enemy (eg. attacking, chasing, idle). These are values that you want to reset before each time you enter play mode.
Constants on the other hand are designed for holding configuration and balance values. These are values that do not change at runtime. Constants could for example hold values like default / initial player health, default / initial unit speed or default / initial attack speed of a unit.
From my understanding, you want to load values referring to configuration and balance values from the server. Like I mentioned above, even though Constants are not designed to be changed at runtime, it's possible using the BaseValue property. If I were you, I would use Constants and then create an editor script that fetches values from the server and then update the local Constants to align with what's on the server side. Let me know if that guides you in the right direction or if there is something that I've missed.

I think it's better to just have this "value persistence" behavior in my own fork.
Can you guide me to points in the code that resets happen/I need to change?

First of all, I would suggest going with the approach above. If you really want to change the behavior of Variables in your fork you would need to change the first couple of rows in OnEnable in AtomVariable.cs.

Will close this issue for now since I do not believe we will address by doing any code changes to Atoms.


Improve third_party readme

Establish some ground rules on adding new depedencies (to make hidden costs of adding a depdendency more obvious).

CC @srini100

@guantaol  @donnadionne   adding both of you as you're currently going through the process of adding a new dependency.


Working with Queries

When creating a binding with vue-firestore, is there a way to incorporate a query? Basically, I want to know if the below code should work:
firestore () {
  return {
    collection: firebase.firestore().collection('groups').collection('my_collection').orderBy('my_attr')
  }
}

You can't query a collection within a collection like you do in your first comment.
See: https://firebase.google.com/docs/firestore/data-model#subcollections


How to define res_required

Hello, I'm wondering if I can specify the res_required and ack_required parameters on certain calls? Namely light filters and power off commands.

For now, this module sets the res_required to 1 (except some methods related to the Tile) and the ack_required to 0. This module does not allow to change the parameters.
Why do you need to change the parameters? The power-off command works well without changing them.

I was having issues with the on/off broadcasts, but by adding stronger validation to the requests I was able to solve the problem.
Thanks for your hard work.


BUG - Plate creation error displays wrong information

Describe the bug
In /plates/new when scanning a group of plates and creating new plates from them, if one of the plates in the group fails on the creation (for example, if it doesn't exist), then all plates created are rolled back. However, the view displays the barcodes of the created plates before the roll back, which is incorrect.
RT Ticket Number
689589
To Reproduce
Steps to reproduce the behaviour:

Go to page /plates/new
Scan 2 plate barcodes, but one of them does not exist
Create plates from them
The screen will show the creation of 1 plate and and error from the other plate
Search for the barcode created, and it doesn't exist.

Expected behaviour
When trying to create the plate, it should not display any created barcodes, but fail all the group.
Screenshots
Desktop (please complete the following information):

All
Additional context

This issue was duplicated. It will be tracked in https://github.com/sanger/sequencescape/issues/2655


Missing parent: GO:0001576 globoside biosynthetic process

GO term ID and label for which you request a new superclass

GO:0001576  globoside biosynthetic process
The chemical reactions and pathways resulting in the formation of a ceramide with a core structure of GalNAc-beta-(1->3)-Gal-alpha-(1->4)-Glc(I).

New superclass (parent) suggested

If this is a valid classification it should have is_a ceramide biosynthetic process, since it is defined as a ceramide

Reference(s), if appropriate
PMID:nnnnnnn

may be a definition proble.
Glycosphingolipids are derived from ceramides

This is a ChEBI issue. Please open a ticket there.

Is globoside definitely a ceramine, though?

A quick Google search shows that:

Globosides are a type of glycosphingolipid (GSL) made up of a ceramide backbone, and a terminal oligosaccharide.
A ceramide is composed of sphingosine and a fatty acid joined by an amide bond.
Sphingosine (2-amino-4-trans-octadecene-1,3-diol) is an 18-carbon amino alcohol with an unsaturated hydrocarbon chain.

So a ceramide is a part of a globoside in the same way that adenine is a part of NAD.

OK, I will alter the definiton.

The chemical reactions and pathways resulting in the formation of a ceramide with a core structure of GalNAc-beta-(1->3)-Gal-alpha-(1->4)-Glc(I).
->
The chemical reactions and pathways resulting in the formation of a glycosphingolipid with a core structure of GalNAc-beta-(1->3)-Gal-alpha-(1->4)-Glc(I).


Unable to test latest master

neikos ~/p/r/ncollide (master)> cargo clean
neikos ~/p/r/ncollide (master)> git rev-parse HEAD
d97238c2b577a64b84776106a05adb5c4cf5bddb
neikos ~/p/r/ncollide (master)> git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
neikos ~/p/r/ncollide (master)> cargo build
   Compiling rustc-serialize v0.3.19
   Compiling libc v0.2.11
   Compiling num-traits v0.1.32
   Compiling rand v0.3.14
   Compiling num-integer v0.1.32
   Compiling num-iter v0.1.32
   Compiling num-complex v0.1.32
   Compiling num-bigint v0.1.32
   Compiling num-rational v0.1.32
   Compiling num v0.1.32
   Compiling nalgebra v0.8.2
   Compiling ncollide_math v0.4.0 (file:///home/neikos/projects/rust/ncollide/ncollide_math)
   Compiling ncollide_utils v0.4.0 (file:///home/neikos/projects/rust/ncollide/ncollide_utils)
   Compiling ncollide_geometry v0.1.1 (file:///home/neikos/projects/rust/ncollide/ncollide_geometry)
   Compiling ncollide_procedural v0.4.0 (file:///home/neikos/projects/rust/ncollide/ncollide_procedural)
   Compiling ncollide_pipeline v0.8.1 (file:///home/neikos/projects/rust/ncollide/ncollide_pipeline)
   Compiling ncollide_transformation v0.4.0 (file:///home/neikos/projects/rust/ncollide/ncollide_transformation)
   Compiling ncollide v0.9.1 (file:///home/neikos/projects/rust/ncollide)
neikos ~/p/r/ncollide (master)> cargo test
   Compiling nom v1.2.2
   Compiling pkg-config v0.3.8
   Compiling lzw v0.9.0
   Compiling glfw-sys v3.1.3
   Compiling bitflags v0.3.3
   Compiling csfml-graphics-sys v0.1.0
   Compiling winapi-build v0.1.1
   Compiling khronos_api v1.0.0
   Compiling csfml-audio-sys v0.1.0
   Compiling byteorder v0.4.2
   Compiling csfml-network-sys v0.1.0
   Compiling kernel32-sys v0.2.2
   Compiling color_quant v1.0.0
   Compiling inflate v0.1.1
   Compiling bitflags v0.5.0
   Compiling winapi v0.2.6
   Compiling sfml-types v0.1.0
   Compiling csfml-window-sys v0.1.1
   Compiling glob v0.2.11
   Compiling gif v0.7.0
   Compiling csfml-system-sys v0.1.0
   Compiling freetype-sys v0.3.1
   Compiling time v0.1.35
   Compiling log v0.3.6
   Compiling semver v0.2.3
   Compiling enum_primitive v0.1.0
   Compiling ncollide_math v0.4.0
   Compiling xml-rs v0.2.2
   Compiling sfml v0.11.2
   Compiling ncollide_utils v0.4.0
   Compiling gcc v0.3.28
   Compiling miniz-sys v0.1.7
   Compiling libz-sys v1.0.3
   Compiling glfw v0.2.0
   Compiling flate2 v0.2.14
   Compiling freetype-rs v0.5.0
/home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs:302:9: 302:27 warning: lint raw_pointer_derive has been removed: using derive with raw pointers is ok
/home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs:302 #[allow(raw_pointer_derive)]
                                                                                ^~~~~~~~~~~~~~~~~~
/home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs:302:9: 302:27 warning: lint raw_pointer_derive has been removed: using derive with raw pointers is ok
/home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs:302 #[allow(raw_pointer_derive)]
                                                                                ^~~~~~~~~~~~~~~~~~
/home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs:301:16: 301:21 note: in this expansion of #[derive_Clone] (defined in /home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs)
/home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs:302:9: 302:27 warning: lint raw_pointer_derive has been removed: using derive with raw pointers is ok
/home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs:302 #[allow(raw_pointer_derive)]
                                                                                ^~~~~~~~~~~~~~~~~~
/home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs:301:10: 301:14 note: in this expansion of #[derive_Copy] (defined in /home/neikos/.cargo/registry/src/github.com-88ac128001ac3a9a/glfw-0.2.0/src/ffi/mod.rs)
   Compiling ncollide_procedural v0.4.0
   Compiling gl_generator v0.4.2
   Compiling ncollide_testbed2d v0.1.1 (file:///home/neikos/projects/rust/ncollide/ncollide_testbed2d)
   Compiling png v0.4.3
   Compiling gl v0.5.2
   Compiling image v0.6.1
   Compiling kiss3d v0.4.2
   Compiling ncollide_testbed3d v0.1.0 (file:///home/neikos/projects/rust/ncollide/ncollide_testbed3d)
ncollide_testbed3d/src/objects/convex.rs:27:44: 27:58 error: mismatched types:
 expected `ncollide_procedural::trimesh::TriMesh<na::structs::point::Point3<f32>>`,
    found `ncollide_procedural::trimesh::TriMesh<na::structs::point::Point3<f32>>`
(expected struct `ncollide_procedural::trimesh::TriMesh`,
    found a different struct `ncollide_procedural::trimesh::TriMesh`) [E0308]
ncollide_testbed3d/src/objects/convex.rs:27             gfx:        window.add_trimesh(convex.clone(), na::one())
                                                                                ^~~~~~~~~~~~~~
ncollide_testbed3d/src/objects/convex.rs:27:44: 27:58 help: run `rustc --explain E0308` to see a detailed explanation
ncollide_testbed3d/src/objects/convex.rs:27:44: 27:58 note: Perhaps two different versions of crate `ncollide_procedural` are being used?
ncollide_testbed3d/src/objects/convex.rs:27             gfx:        window.add_trimesh(convex.clone(), na::one())
                                                                                ^~~~~~~~~~~~~~
error: aborting due to previous error
Could not compile `ncollide_testbed3d`.

To learn more, run the command again with --verbose.
neikos ~/p/r/ncollide (master) [101]>

If you check the compile output you will find that it compiles ncollide_procedural twice, once the local build, once one that it fetches from crates.io.
eikos ~/p/r/ncollide (master) [101]> cargo -V
cargo 0.10.0-nightly (d6e148d 2016-03-09)
neikos ~/p/r/ncollide (master)> rustc -V
rustc 1.9.0-nightly (c9629d61c 2016-03-10)

Same issue here.

It looks like the example depends on the local ncollide while the testbed's renderer depends on the one from crates.io.
The only way I see to fix this is to move the ncollide examples using the testbeds into the testbeds' example folders (which seems more logical anyway).

By the way @TheNeikos , if you attempt to compile the tests or examples from ncollide with the current nightly (or beta) version of rustc, you will end up with internal compiler errors. This will be fixed when rust-lang/rust#33478 lands. In the mean time you may use the stable channel.


Data logging fixes

The original commits in this PR have been pushed here from @gerargz branch (thanks!): https://github.com/microbit-foundation/DAPLink/commit/a7b614ed46ca2329fc0e3be6c589d96365c777de

As indicated in the PR timeline, I've rebased the latest upstream master and forced pushed (head before was a7b614e, and now is 096519d)
This was so that any testing builds from this branch can have all the latest changes from main, as this would include the last commits added to microbit_features upstream PR before it was merged, as they were added before this branch was originally created.

Build using Keil with armcc, git hash 096519dbccc60d6ca86c60dd8dede8cda195b18d:

kl27z_microbit_if.hex.zip

b7e6a0eb44896c211d44cdbcf89135e4be21ffe8 build from Gerardo: kl27z_microbit_if_b7e6a0e.zip


node-red deploy issue

I have had this problem for about a week now but didn't say anything because I hoped the resolution of #16 may have also resolved this problem but it doesn't...and I am not even sure its a node-red-contib-blynk issue, just wondering if you have any idea what's going on..?
The problem .. I have 4 blynk server connections, when I fully re-deploy node-red, 3 of the servers from connecting to connect take about 2 seconds but the 4th always takes ages like 3-4 minutes, its always the same server connection that has this problem and its every time I deploy nr here's the log:
1 Dec 10:43:16 - [info] Starting flows
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
1 Dec 10:43:46 - [info] Started flows
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
1 Dec 10:43:46 - [info] [mqtt-broker:8084e98a.7f7b18] Connected to broker: mqtt://<IP_ADDRESS>:1883
Connected
Authorized
1 Dec 10:43:47 - [info] [blynk-server:c1c8f31f.3e371] key: 0cc7 bla bla connected
Authorized
1 Dec 10:43:47 - [info] [blynk-server:39b0b4e1.c64f4c] key: 2972 bla bla  connected
Connecting to SSL: cloud.blynk.cc 8441
Connected
Authorized
1 Dec 10:43:49 - [info] [blynk-server:c3307c50.3ccf8] key: f165 bla bla connected
Connecting to SSL: cloud.blynk.cc 8441
Connected
Connecting to SSL: cloud.blynk.cc 8441
Connected
same same repeated for in this case nearly 3 minutes until
Connecting to SSL: cloud.blynk.cc 8441
Connected
Authorized
1 Dec 10:46:11 - [info] [blynk-server:7f2dce8b.80d23] key: adf0 bla bla connected
As you can appreciate its very frustrating having to wait 3-4 minutes for node-red to be working when you are developing a flow,
To ensure its not a problem with my code, I deleted the flow and pasted it into another instance of node-red on a pizero in this case the 3 remaining flows still load within seconds and the flow on the pizero also loads within seconds ...
Its almost like Blynk gets confused/overloaded when connecting to multiple server instances.

i winder if this could be in some way linked to blynk server connection rate limiting...
i need to test it myself
in the mean time, if you can in a new flow, does having just one connection cause any issues?

Not sure I get your meaning, like I said I removed the flow that takes ages to load and pasted it into a different instance of node-red on a different pi,
Result was it loads within seconds and so does the 3 remaining flows on my original pi.

Or do you

Whoops that went wrong - Or do you mean, " just one connection " .. just one node?

sorry, i meant just one token/server combo
i think there is some rate limiting on blynk.cc, but i do not know if it would affect the connecting part as well
it kind of seems it does. if you add 3 server connections on the pi0 , does it behave the same?

Over the last 2 days here is what I have been testing:-

This is a pi2 running wheezy node-red v0.12.2  node.js v0.12.6  blynk v0.0.24  contrib-blynk v0.0.17
I loaded a node-red blank canvas and made 4 sheets with 1 inject node and 1 blynk write node on each sheet, each write node connects to an existing watch-dog led on 4 separate blynk servers, when I deploy node-red each node connects to its respective server immediately, so it appears the issue has nothing to do with "blynk server connection rate limiting" . deploying original flows still results in 3-4 minute load issue
I also had to reboot node-red on 1 occasion due to issue #16 / #19

This is a pizero running noobs jessie with node-red pre installed v0.12.2  node.js v0.10.29  blynk v0.0.24  contrib-blynk v0.0.17
Then I exported all my original flows and imported them into the node-red instance on my pizero expecting the same issue but that's not what happened, all of the flows load within 10 seconds no sign of the 3 to 4 minute delay issue.

This is a pi b+ running wheezy node-red v0.12.2  node.js v0.12.6  blynk v0.0.24  contrib-blynk v0.0.17
importing & deploying original flows results in 3-4 minute load issue
Downgrade node.js to v0.10.36 (because I couldn't find v0.10.29)  flows load within 10 seconds no sign of the 3 to 4 minute delay issue.

So now I have 3 pi's with the original flows imported and I can switch between them recreating the issue and resolving it depending which one I use, so it appears to me the issue is related to the node.js version.
I also notice that during the last 36 hrs test period pi b+ with node.js v0.10.29  I had no issues due to #16 / #19

So the question: is there a preferred node.js version associated with blynk / contrib-blynk.
Of coarse I can down grade node.js on my pi2 to try it but didn't want to do that to soon as you may want some more info, so I propose to leave pi b+ running for a few days to see if it solves #16 / #19 as well.
Toshi

wooow, nice going.
for reference i've got Node.js  version: v0.12.7 and am not seeing this, but i only use it to test stuff, it s not a complicated deployment like yours.
looking forward to what results you get.
if it disconnects, please find the node-red log pertinent to the moment it disconnects and what happened right above that.
cheers

btw, by "4 separate blynk servers" upi mean 4 blynk.cc project keys, right?

Yes 4 separate servers/project keys, in fact there the same 4 servers as original, each of the servers has a watch-dog led already so I just made the new write nodes switch just the existing watch-dog leds on each server page in the app.
Here's the log for the disconnect detailed in para 2 of my post.
Authorized
3 Dec 08:48:27 - [info] [blynk-server:c1c8f31f.3e371] key: bla bla connected
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
Connecting to SSL: cloud.blynk.cc 8441
3 Dec 09:17:42 - [red] Uncaught Exception:
3 Dec 09:17:43 - Error: write EIO
at exports._errnoException (util.js:746:11)
at WriteWrap.afterWrite (net.js:775:14)


Bad link to RATProfilesList_Empty.png in DE Screenshots 2.22

Where to find the issue
https://www.coronawarn.app/de/screenshots/#android_rat_profiles
Describe the issue
The Screenshot section https://www.coronawarn.app/de/screenshots/#android_rat_profiles links to the file https://www.coronawarn.app/assets/screenshots/2-22/de/android/RATProfilesList_Empty.png however this file does not exist.
Instead there is a file https://www.coronawarn.app/assets/screenshots/2-22/de/android/RatProfilesList_Empty.png which has the same name, but different upper / lower case characters.
Steps to reproduce
On Ubuntu execute
npm run test:open
select check_links.js
produces log:
==================== Broken links ====================

[RESPONSE 404] http://localhost:8000/assets/screenshots/2-22/de/android/RATProfilesList_Empty.png on '/de/screenshots/'

OR
Open https://www.coronawarn.app/de/screenshots/#android_rat_profiles
Note "Schnelltest-Profile Bild 4 von 6" with link to https://www.coronawarn.app/assets/screenshots/2-22/de/android/RATProfilesList_Empty.png does not display any graphic.
For comparison, the EN file https://www.coronawarn.app/assets/screenshots/2-22/en/android/RATProfilesList_Empty.png does exist.
Suggested change
In the source directory /src/assets/screenshots/2-22/de/android/ rename the file RatProfilesList_Empty.png to
RATProfilesList_Empty.png.

PR #2833 submitted


Z2M crash after i made restart

Description of the issue
With version: 1.37.0-1,if i hit restart zigbee2mqtt bridge button,or if I restart zigbee2MQTT,all mqtt devices became unavailable.The only solution to return to normal is to shut down HA(not restart,but shutdown).After downgrade to 1.36.1 version.the problem disapear.I also downgraded to HA core, to 2024.4.4, believing that the problem is from HA, but the problem persists. So the problem is with the add-on, at version 1.37.0.
Addon version
v1.37.0
Platform
Core 2024.5.0
Supervisor 2024.5.0
Operating System 12.2
Frontend 20240404.2
Logs of the issue (if applicable)
No response

With 1.37.1 version,my problem is solved.Now everything is ok.

With 1.37.1 version,my problem is solved.Now everything is ok


Implement gobuffalo-pop Eager Creation & Loading

Implement features described here as a trial run for setting up the much more complex sets of relational associations in the clin-phen-service.

Pop documentation has since moved off the README to offer more detailed tutorials on Associations here.

Completed.


FeatureRequest: CollaSet supports operationDelaySeconds

Is your feature request related to a problem? Please describe:
After preparing finished in PodOpsLifecycle, we still want to hold CollaSet process for a while before it delete or update Pods, in order to provide a grace period.
Describe the feature you'd like:
When preparing finished in PodOpsLifecycle, it is supposed to hold for a while before CollaSet does operation on Pods. Take traffic for example, after traffic turned off, CollaSet need to wait for seconds before delete Pods to allow the traffic on the fly to be processed.
Describe alternatives you've considered
Option 1 is to use Pod terminationGracePeriod, but it ask for users to handle TERM signal in application codes.
Option 2 is to ask users to consider the graceful process in preparing phase. For example, remove the PodOpsLifecycle protection finalizer only if all the traffic is processed completely.
All of above options ask users for extra effort. We still need to provide a way to make it easier.
Teachability, Documentation, Adoption, Migration Strategy
No response

lifecycle.allowOps already support operationDelaySeconds

lifecycle.allowOps already support operationDelaySeconds


Use is_staff rather than membership of group to define staff status

I think it'd be cleaner to check if a user is a staff user account (staff is not the same as administrator / superuser) rather than check for the membership of the group "Komiteer".
Since all committee members are synced to this group, we could make sure any persons synced to the "Komiteer" group has the is_staff flag.

Sure, should have been done in that sort of way in the first place. But that's on me :)

is_staff should be set based on if a user is in a group of type COMMITTEE or NODE_COMMITTEE


[Bug]: Using docker network not possible due to URL resolve

What happened?
The current implementation of client creation makes it very cumbersome to work with docker networks. This is because chromadb.HttpClient checks settings against args:
https://github.com/chroma-core/chroma/blob/8f0ab7902680b743e795f5e214fb15b07835ebff/chromadb/__init__.py#L191-L195
And the BasHTTPClient assumes a full URL if the host starts with http:
https://github.com/chroma-core/chroma/blob/8f0ab7902680b743e795f5e214fb15b07835ebff/chromadb/api/base_http_client.py#L41-L45
As a result, I can't use docker networks unless I bypass this effect by passing the settings object and the ports/complete URL.
import os
import logging

logging.basicConfig(level=logging)

CHROMA_SERVER_HOST = os.environ.get("CHROMA_SERVER_HOST", "localhost")
CHROMA_SERVER_PORT = os.environ.get("CHROMA_SERVER_PORT", 8000)
CHROMA_URL = f"{CHROMA_SERVER_HOST}:{CHROMA_SERVER_PORT}/"

import chromadb
from chromadb import Settings

settings = Settings(
    chroma_server_host=CHROMA_URL,
    chroma_server_http_port=CHROMA_SERVER_PORT,
)

client = chromadb.HttpClient(
    host=settings.chroma_server_host,
    port=settings.chroma_server_http_port,
    settings=settings,
)

Versions
Python 3.12.7
chromadb 0.5.20
ghcr.io/chroma-core/chroma:0.5.20
Relevant log output
**[2024-12-03 09:34:12,322] INFO Connecting to ChromaDB server at http://chromadb:8000**
[2024-12-03 09:34:12,608] INFO Anonymized telemetry enabled. See https://docs.trychroma.com/telemetry for more information.
**[2024-12-03 09:34:12,652] DEBUG Skipping port as the user is passing a full URL**
[2024-12-03 09:34:12,653] DEBUG load_ssl_context verify=True cert=None trust_env=True http2=False
[2024-12-03 09:34:12,653] DEBUG load_verify_locations cafile='/usr/local/lib/python3.12/site-packages/certifi/cacert.pem'
[2024-12-03 09:34:12,702] DEBUG Starting component System
[2024-12-03 09:34:12,702] DEBUG Starting component Posthog
[2024-12-03 09:34:12,702] DEBUG Starting component OpenTelemetryClient
[2024-12-03 09:34:12,703] DEBUG Starting component FastAPI
**[2024-12-03 09:34:12,703] DEBUG connect_tcp.started host='chromadb' port=80 local_address=None timeout=None socket_options=None
[2024-12-03 09:34:12,704] DEBUG connect_tcp.failed exception=ConnectError(ConnectionRefusedError(111, 'Connection refused'))**

@thesethtruth, I admit that the current client interface that supports both endpoints and host+port separately is confusing. But if you threat them as the original intent was as separate concepts - you can either connect to an endpoint or to a host+port. In the former you must provide the full URL info including scheme, host/ip, port and path, in the latter you specify host + port and you let the client construct the URL for you.
In the code snippet above what is stopping you from doing:
CHROMA_SERVER_HOST = os.environ.get("CHROMA_SERVER_HOST", "localhost")
CHROMA_SERVER_PORT = os.environ.get("CHROMA_SERVER_PORT", 8000)
CHROMA_URL = f"http://{CHROMA_SERVER_HOST}:{CHROMA_SERVER_PORT}/" # or https if you have configured a cert.

import chromadb
from chromadb import Settings

settings = Settings(
    chroma_server_host=CHROMA_URL,
)

@tazarov, thanks for the very swift response! Your suggestion is valid, except for the 'validation' parsing in the first snippet I linked in the ticket. Your suggestion yields:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.12/site-packages/chromadb/__init__.py", line 192, in HttpClient
    raise ValueError(
ValueError: Chroma server host provided in settings[http://chromadb:8000/] is different to the one provided in HttpClient: [localhost]

@thesethtruth, you have a point but then the solution for this would be to just be mindful of the env vars. The issue, as you describe lies not so much with the HttpClient config itself but in general with how pydantic Settings class works. Specifically how it interacts with env vars. I think this is what introduces the confusion and we have fair share of these popping up - https://discord.com/channels/1073293645303795742/1298075062854881291/1298263590985531415.
Is there anything that dictates you must use CHROMA_SERVER_HOST env var? If you are creating your client programmatically, I think, it makes sense to use custom env vars that you can then plug into your CHROMA_URL. The env vars thing makes sense if you do something like:
client = chromadb.HttpClient()

Then pydantic takes care of wiring your env vars into your Chroma client.
In short, pick either programatic or auto-wired with env vars client in your code and stick with that while making sure to not add env vars that might be picked up by the client automatically thus causing the confusion.

@tazarov Right! I second the confusion about env vars. I was not aware of the fact that my definition of chroma env vars was actually the same as chroma uses internally. I can change my env var definitions, no problem; I just did not know/realize that these were actually picked up at client creation. It seems kind of implicit to me.
You want me to keep this issue open for reference or to close it, as it is not necessarily a bug but QoL kind of thing?

@thesethtruth, I think we can close it. It will still be searchable for anyone that faces similar problem.


224 | Vaccination status styling on patient list

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #224
Type
Choose one: (Feature)
Checklist

[x] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[ ] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[x] I have built and run the fhircore app to verify my change fixes the issue and/or does not break the app

Marking this with a DNM for now. Borrows a lot from the covaxx-demo code we need to refactor.

after rebase is this mergeable now?

@maimoonak not high priority, but worth seeing if this can go in now after a rebase before it gets farther away from main

the rebasing or merging over main seems to be almost impossible on this branch. Since now required changes are small and include styling only hence closing this PR in favor of https://github.com/opensrp/fhircore/pull/413.


Problem running gulp marbles_tls

Hi there,
I kept getting the following error when running "gulp marbles_tls" command. Do you know what step I have missed? I have ran npm install gulp -g and npm install commands and also modified the connection_profile_tls.json file with the connection profile copied.
fs.js:904
  return binding.readdir(pathModule._makeLong(path), options.encoding);
                 ^

Error: ENOENT: no such file or directory, scandir '/Users/etan128/Projects/ibm_cloud_platform/marbles/node_modules/node-sass/vendor'
    at Object.fs.readdirSync (fs.js:904:18)
    at Object.getInstalledBinaries (/Users/etan128/Projects/ibm_cloud_platform/marbles/node_modules/node-sass/lib/extensions.js:129:13)
    at foundBinariesList (/Users/etan128/Projects/ibm_cloud_platform/marbles/node_modules/node-sass/lib/errors.js:20:15)
    at foundBinaries (/Users/etan128/Projects/ibm_cloud_platform/marbles/node_modules/node-sass/lib/errors.js:15:5)
    at Object.module.exports.missingBinary (/Users/etan128/Projects/ibm_cloud_platform/marbles/node_modules/node-sass/lib/errors.js:45:5)
    at module.exports (/Users/etan128/Projects/ibm_cloud_platform/marbles/node_modules/node-sass/lib/binding.js:15:30)
    at Object.<anonymous> (/Users/etan128/Projects/ibm_cloud_platform/marbles/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)

cheers
Estee

node-sass did not install correctly,  try again with the command npm install or maybe sudo npm install.
ideally you don't see any read text.

Yes, got it working. Thanks

closing, inactivity


Update README.md

Homebrew can automatically add tap before installing the formula. Create and Maintain a Tap

@dkoper you can accept this without a CLA

Thanks Artem!


Error in Dialog/visualize_result.py

When I try to  visualize the result of Dialog dataset after training I get the following error.
Traceback (most recent call last):
File "/home/prayalankar/anaconda3/envs/tyu/lib/python3.5/runpy.py", line 184, in _run_module_as_main
"main", mod_spec)
File "/home/prayalankar/anaconda3/envs/tyu/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/prayalankar/qrn/dialog/visualize_result.py", line 174, in
list_results(ARGS)
File "/home/prayalankar/qrn/dialog/visualize_result.py", line 88, in list_results
X, Q, Y, Y1, Y2, Y3, Y4, Y5, Y6, Y7 = data[:10]
ValueError: not enough values to unpack (expected 10, got 4)

@prayalankar2
Sorry for the inconvenience.
There was a bug in the code and it is fixed now.
Thanks!


Support MPEG2 Layer2

Hi,
I've been working with your awesome package, and it works well for most of audio/video codecs. However, I've encountered a challenge as I'm currently looking to decode MPEG2 Layer2, which unfortunately the package doesn't support. I'm curious if there's a specific reason for not supporting MPEG2 Layer2 and if there are any plans to include support for it in the future.
Thank you!

Hello, there is no particular reason for not supporting MPEG-2 layer 2 (by the way, this limitation lies in mediacommon and not in gortsplib, which is already fit for handling any MPEG combination), other than the fact that this feature wasn't requested until now. Just provide a sample MPEG-2 layer 2 file or a FFmpeg / GStreamer command that allows to generate it and i'll add support for it.

Hello, there is no particular reason for not supporting MPEG-2 layer 2 (by the way, this limitation lies in mediacommon and not in gortsplib, which is already fit for handling any MPEG combination), other than the fact that this feature wasn't requested until now. Just provide a sample MPEG-2 layer 2 file or a FFmpeg / GStreamer command that allows to generate it and i'll add support for it.

Okay, I'll provide the 'command' or a sample 'MPEG-2 layer2' file and come back to you.

@aler9
you can use below command to simulate MPEG2-Layer2.
ffmpeg -i noise.wav -c:a mp2 -b:a 192k output.mp2

fixed in mediacommon v1.9.0


Django 3+ not support staticfiles pls support this feature

Django 3+ not support staticfiles pls support this feature.

To get around this:

navigate to your installation path of rest_framework_swagger, for me it's env\Lib\site-packages\rest_framework_swagger
goto templates/rest_framework_swagger folder and change staticfile to static in your index.html
enjoy

I think it is best to update master to have {% load static %} in the index.html file than simply directing people to hack site-distribution of their install of django-rest-swagger. Updating site-distribution file(s) is a bad idea - in my opinion.

@marcgibbons Any news on this?


Support for clipboardy

from my experience copy-paste has several issues - which clipboardy does not.  Would it be possible to add in support? https://github.com/sindresorhus/clipboardy

Have you tried using clipboardy within an app packaged with pkg and it failed? It seems to work fine for me.

@gabemarshall that's great to hear. I have come into problems with the app packaged from pkg not being able to find the copy or paste executables on windows - i have not attempted on other OS's.

I can confirm that both modules fail when called from inside a binary built with pkg on Windows.  Here is clipboardy:
Error: spawn C:\\snapshot\\vagrant\\node_modules\\clipboardy\\fallbacks\\windows\\paste.exe

And node-copy-paste:
Error: Command failed: cscript /Nologo C:\snapshot\Users\IEUser\myapp\node_modules\copy-paste\platform\fallbacks\paste.vbs

yeah the issue is clipboardy provides its own exes for utilizing the clipboard. Not much pkg can do to fix that.

Ahh yes sorry about that, wasn't thinking of Windows support when I first read the issue. I'll look into it this weekend (I have a project that needs copy/paste support as well).

Any updates regarding this? I have a project that requires copy/paste support and pkg and clipboardy still do not work together.

I am also looking for support for clipboardy within pkg or a workaround to use it as an uncompiled external module. Any updates?

Apologies for committing over a year ago to look into this and letting it fall by the wayside. I'm taking another look now based on the idea I had and will hopefully come back with some good news shortly.

For now I ended up writing a simple patch script that searches the lib directory for all the occurrences of the fallback executables and rewrites the matched files with paths to the current working directory. Then it copies the executables to the working dir.

@LinkTree3 @JoeNimble I have a modified fork of node-copy-paste that seems to work fine, but it could use some additional testing if you have a chance. I'm sure something similar could be implemented into clipboardy if necesary.
https://github.com/gabemarshall/node-copy-paste
https://github.com/gabemarshall/node-copy-paste/blob/master/platform/win32.js

@gabemarshall I haven't tested it yet but I did go over your code and it looks wonderful. That ps script to create a new htmlfile object and get the clipboard data from it is really cool.


State transitions for CIS v2 scans are confusing

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):

Repo: https://github.com/prachidamle/charts.git branch: civ-v2-chart

Run a scan by creating a cluster Scan CR.

The scan's state changes from Active --> Running --> Active

For example, in a scenario when 2 ClusterScan CRs are created in parallel - scan-1 and scan-2

Scan-1 is seen in Running state and Scan -2 is seen in Active state.

When Scan-1 has finished, the state of Scan-1 is now Active

Scan-2 now changes to Running --> Active state

Expected Result:
Transition state of the clusterScan can be made better
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master-head - commit id: 8d9cedd
Installation option (single install/HA): HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): custom cluster - 8 nodes - 3 etcd, 2 control and 3 worker nodes.
Kubernetes version (use kubectl version):

1.18

Docker version (use docker version):

(paste the output here)

This issue has been fixed and available to test via the new tag:

repository: rancher/cis-operator
tag: v0.0.4
The rancher-cis-benchmark chart has been updated to use this tag. https://github.com/rancher/charts/pull/586

Fix provided:

A new status.display.state field has been added to the ClusterScan CRD and this will contain the state of the ClusterScan: pass/fail/error/reporting.
This state will be displayed under STATUS column of the ClusterScan list on Dashboard.

Example: Here is how the clusterscan fields will be displayed that shows the the STATUS field to reflect the state of the scan as (pass/fail/error/reporting)
$ kubectl --kubeconfig ~/.kube/test_config_master  get clusterscans

NAME           STATUS   CLUSTERSCANPROFILE       TOTAL   PASS   FAIL   SKIP   NOT APPLICABLE   LASTRUNTIMESTAMP
rke-cis        fail     rke-profile-hardened     92      59     13     0      20               2020-09-05T01:18:28Z
rke-cis-perm   pass     rke-profile-permissive   92      58     0      0      34               2020-09-05T01:19:36Z
run-eks-1.0    error

The STATE field on Dashboard may not yet reflect this status.display.state value(possibly needs a UI update?), but the STATUS field will demo the state transitions.

On master-head - commit id: 3ca11da829

Deploy cis-operator from repo - https://github.com/prachidamle/charts.git branch: cis-v2-chart. chart Images:

  cisoperator:
    repository: rancher/cis-operator
    tag: v0.0.4
  securityScan:
    repository: prachidamle/security-scan
    tag: v0.1.20

Run a scan by creating a cluster Scan CR.
The scan's state changes from Active --> Running --> Pass/Fail/Error
when 2 ClusterScan CRs are created in parallel - scan-1 and scan-2
Scan-1 is seen in Running state and Scan -2 is seen in Active state.
When Scan-1 has finished, the state of Scan-1 is now Pass
Scan-2 now changes to Running --> Pass state

Expected:
Can we have the initial state of the scan as Created/Pending instead of Active ?

We will be having following states:
"Active"  - this is the default state set by steve/wrangler api for a new object
"Pending" - clusterscan pending to be run
"Running" - scan running
"Reporting" - report generation in process
"Pass" / "Fail" / "Error" - scan complete

On master-head - commit id: e919796c - issue is not seen fixed.

As a standard user Deployed CIS benchmark chart on a user cluster. images:

image:
  cisoperator:
    repository: rancher/cis-operator
    tag: v0.0.5
  securityScan:
    repository: rancher/security-scan
    tag: v0.2.0
  sonobuoy:
    repository: rancher/sonobuoy-sonobuoy
    tag: v0.16.3

Run a scan by creating a cluster Scan CR.
The scan's state changes from Active --> Running --> Pass/Fail/Error
when 2 ClusterScan CRs are created in parallel - scan-1 and scan-2
Scan-1 is seen in Running state and Scan -2 is seen in Pending state.
When Scan-1 has finished, the state of Scan-1 is now Pass
Scan-2 now changes to Running --> Pass state


Publish snapshot on merge to main branch

sbt-ci-release makes this super easy. I assume mill-ci-release does the same?
This is great for those of us interested in trying out features not yet releases without resorting to a local publish (can't be shared).

We can trigger the release action on push to the main branch but I think it would spam too much. A better alternative is eventually nightly publishing aka publishing once a day (at night) only if the main branch (here dev/2.0) changed.

I do it on Redis4Cats and it's refreshing. You can forget about it once the tooling does it for you, in my case it's sbt-ci-release. The aim of the plugin is pretty clear:
This is an sbt plugin to help automate releases to Sonatype and Maven Central from GitHub Actions.

    - git tag pushes are published as regular releases to Maven Central
    - merge into main commits are published as -SNAPSHOT with a unique version number for every commit

AFAICS mill-ci-release has similar goals.
This is a [Mill](https://com-lihaoyi.github.io/mill/mill/Intro_to_Mill.html) plugin modeled after the fantastic [sbt-ci-release](https://github.com/sbt/sbt-ci-release) plugin which helps automate publishing to [Sonatype](https://www.sonatype.com/) from GitHub Actions with as little friction as possible. These are the key features of using the plugin.

    - A new git tag is published as a regular release
    - A merge is published as a SNAPSHOT release
    - Auto versioning based on git by [mill-vcs-version](https://github.com/lefou/mill-vcs-version)
    - A simple one-liner in CI to publish

What do you mean with spam too much?

What do you mean with spam too much?

I mean publish too much artifacts if a day is particularly active (multiple merges, multiple push etc...)

That's the idea of snapshots :)

I mean, even in other projects like Dotty, Scalameta (granted they are way more active than Iron), they only publish nightlies IIRC


How does permission work for other menu?

for example users or applications, is the access control automatically set?, I have tried but it doesn't have any effect, and I'm still confused about how to use these permissions and how to set access control for each user

See: https://casdoor.org/docs/permission/overview


Tabs SSR not working

[ ] I have searched the Issues to see if this bug has already been reported
[ ] I have tested the latest version

Steps to reproduce
just create a nextjs +14 pro version and you'll see that it's not compatible yet...
Current behavior
Describe what is currently happening and why it's a problem.
Expected behavior
must work perfectly
Context

Compound components are not supported in RSC.
Please read:
https://flowbite-react.com/docs/getting-started/server-components#compound-components
To solve ur issue, just add "use client" directive at the top of ur file.

Compound components are not supported in RSC.
Please read: https://flowbite-react.com/docs/getting-started/server-components#compound-components
To solve ur issue, just add "use client" directive at the top of ur file.

hi yes i solved by using "use client",  and move it in another component.
basically my page structure is:
page.tsx to get data (ssr)
then i should split it into client mini-components to render flowbite??
is that a good approach?
thanks.


carousel-item-dark

I like the new carousel-dark class, but I think it would also be useful to have darker or lighter controls, etc. on a slide-by-slide basis.
I would recommend something like a carousel-item-dark and carousel-item-light class available on each carousel-item.
This would allow slides to override the carousel setting, if necessary.

Controls and indicators are outside each slide, so it'd be difficult to style those based on the slides. One method could be sibling selectors, however the HTML order is never guaranteed. Blend modes or something might be useful depending on the context?

I was just concentrating on the captions, but you're right. the controls and indicators wouldn't work. Might need a class change on the carousel element itself.
If I get something working, I'll submit a solution.

Might be able to do something with mix-blend-mode? https://codepen.io/emdeoh/pen/YzNRYKW

I can't wait til :has comes out...

Not sure if this can be achieved with CSS only. 🙁
I had a try on mix-blend-mode and with simple backgrounds it works more or less fine. Figured one problem is gray tho, e.g. setting the background to #808080.
With pictures it's a whole different story. The more details and contrast changes they contain the harder it is to see the navigation. Colors in general have an impact on the outcome of difference too. Black and white images share issues with the gray backgrounds.
For the details and color problem I tried to add some backdrop-filter with blur() and grayscale() which solved that to some extent.
But there are pictures that still don't work. I played around by adding backdrop-filters like invert(), brightness(), contrast() and saturate() with mixed results. For some pictures it works for some it doesn't.
My CSS magic is just not stronk enough to solve this 🧙♂✨💩.
If you want to do it with JS tho maybe I can help 😁.

How about adding background-color to controls on carousel hover? It would make controls fully visible.
.carousel:hover .carousel-control-prev,
.carousel:hover .carousel-control-next{}

I think we close this as a can't/won't fix.


Fix first login failing session evaluation

Fixes #182

Also bundled a readme update to add unical to the customized versions
Closes #187

Merged. Thanks!


[CI][C++] Nightly test-conda-cpp-valgrind is flaky due to arrow-compute-vector-test taking closer to 500 seconds

Describe the bug, including details regarding any error messages, version, and platform.
Sometimes the test-conda-cpp-valgrind nightly test fails due to a timeout on arrow-compute-vector-test. Examples:

test-conda-cpp-valgrind-8th-May --> 8th May
test-conda-cpp-valgrind-17th-May --> 17th May

with the failure:
The following tests FAILED:
	 25 - arrow-compute-vector-test (Timeout)

When it succeeds it is close to the 500 seconds, example:

test-conda-cpp-valgrind-11th-May --> 11th May, 405 seconds
test-conda-cpp-valgrind-13th-May--> 13th May, 468 seconds

I am not sure whether we should reduce the tests time or split the test so we stop getting those timeouts.
Component(s)
C++, Continuous Integration

I think we could probably be more selective about which types we test (e.g. testing one or two of the 8 integer types is often sufficient) if we really wanted to trim down the runtimes.

@westonpace @pitrou should we do something about this flaky one?

@raulcd Someone should ideally take a look into it and try to reduce the runtime under Valgrind.
For example, it's not obvious that testing all datatypes exhaustively with random input is useful (why all integers, both signed and unsigned, for example?). Test sizes could also be reduced a bit.
@felipecrv Since you've been working quite a bit on kernels, would you like to take a look at this?
Note that you can use Archery to run the Valgrind CI job, for example archery docker run conda-cpp-valgrind.
I would recommended shelling in the Docker image, though (archery docker run conda-cpp-valgrind bash), allowing you to build and test more selectively.

An orthogonal solution is to split arrow-compute-vector-test into two or three independent test executables (for example: 1) sort+rank+top/bottomK 2) select+filter 3) all the rest). But, while that would workaround the timeout problem, it wouldn't reduce the total CI runtime.

An orthogonal solution is to split arrow-compute-vector-test into two or three independent test executables (for example: 1) sort+rank+top/bottomK 2) select+filter 3) all the rest). But, while that would workaround the timeout problem, it wouldn't reduce the total CI runtime.

I will try to reduce number of allocations in tests (I hope it's possible to do so), but will split these tests as I don't feel safe selecting which tests to disable. When developing kernels, exhaustive tests were very helpful in catching unexpected UB and mistakes in the type dispatching logic.

I generate a bunch of test cases for run-end encoding, but it's really fast compared to other kernels. Number of variations is a bad predictor of test cost.
[----------] Global test environment tear-down
[==========] 423 tests from 1 test suite ran. (326 ms total)
[  PASSED  ] 423 tests.
debug/arrow-compute-vector-test --gtest_filter="EncodeArrayTest*"  0.44s user 0.06s system 96% cpu 0.511 total

I tried looking for inefficiencies in test code, but none of the changes I tried made a difference. So I went for a split of the tests.


Error: Minified React error

Hello Can you help me for this case ? when i scroll down into ignition page it giving this error.
My browser console is :

Hey, can you please try upgrading to the latest version of Ignition by running composer update? This will improve the outputted error. Alternatively you can try opening the page in an incognito window or with extensions disabled (e.g. TronLink is known to cause issues). Please let us know if any of these possible fixes work in #107.
Finally, feel free to open a new issue if you're still experiencing this issue!


Bug - Renewal of user certificate causes connection issue

By using this guide and the example config - evantually when the user certificate on the computer renews , further vpn connections will fail.
The user will get an error message saying: "There are no more files"
To fix the issue the user has to open properties of the vpn connection and press "Clear signin info". Then he can successfully connect again.
The error message is easy to reproduce - just manually renew the user certificate from mmc.exe - certificates.
After some investegation found this line in profile xml - as default in this guide:
<RememberCredentials>true</RememberCredentials>
If i change this line in the profile to:
<RememberCredentials>false</RememberCredentials>
The error won't reproduce, and connecting vpn works seamless after certificate renewal, as we would expect :)

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

ID: 77e14da1-102d-3ddf-e2a1-a20ce533b95a
Version Independent ID: 374edc4c-f527-b7b7-c291-353928b97d8d
Content: Configure Windows 10 Client Always On VPN Connections
Content Source: WindowsServerDocs/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections.md
Product: windows-server
Technology: networking-ras
GitHub Login: @Teresa-Motiv
Microsoft Alias: v-tea

#assign:HeidiLohr

#please-close Fixed in: https://github.com/MicrosoftDocs/windowsserverdocs-pr/pull/3398


Use a task dependency to trigger construction of artifacts in an included build

See gradle/composite-builds#103

Thanks for the feedback @big-guy. I've rebased on master and addressed the majority of your comments. Please take another look.


BUG: SetScale() and SetSkew() did not recompute offset: ScaleSkewVersorT

The ScaleSkewVersorTransform did not call ComputeOffset() when
its scale or skew variables were updated - only called ComputeMatrix().
Additionally, the composition of a transform matrix from the scale
and skew variables was non-standard (i.e., wrong).   Now the transform
matrix is correctly composed from scale and skew matrix.
Additionally, a function to compute Scale, Skew, and Rotation values
from a given matrix (i.e., the ComputeMatrixParameters()) was not
defined and threw an exception.   A correct decomposition is now
computed.
Corresponding tests have also been added.

You didn't add any files, but you deleted two files. In particular, missing itkScaleSkewVersor3DTransformTest.cxx is causing configure errors.

Obscure and unintuitive  merge tool failure.
Will fix.

Sent via phone.
On Mon, Dec 30, 2019, 11:23 AM Dženan Zukić<EMAIL_ADDRESS>wrote:

You didn't add any files, but you deleted two files. In particular,
missing itkScaleSkewVersor3DTransformTest.cxx is causing configure errors.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/InsightSoftwareConsortium/ITK/pull/1523?email_source=notifications&email_token=AACEJLZZKASAYK7CNRCJXD3Q3IN6LA5CNFSM4KBN5QN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH2UZSY#issuecomment-569724107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACEJLYXAI33HK73PGDHH2LQ3IN6LANCNFSM4KBN5QNQ
.

Hello @dzenanz @aylward,
I am just encountering this change due to test failures in SimpleITK.
I have a couple issue with this patch:

The number of parameters has changed. This means that previously written transforms are now broken, and unusable.
The latex definition of the transforms and their compositions were not updated: https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Transform/include/itkScaleVersor3DTransform.h#L31
The JacobianWithRespectToParameters was not updated. When I discovered this class used the odd "+" for the composition instead of matrix multiplication I thought it was a bug and considered a similar fix. I recall using symbolic differential tools to compute the Jacobian with respect to parameters and it was impossibly complicated due to parameter interaction, where as if the the addition matrix composition was with the scale and skew matrixes, the values were trivial as previously defined.

I suggest the the old transform remain as it was for compatibility and a new "ComposedScaleSkewVersor3DTransform" be created. Perhaps the new transform could be implemented with out a Jacobian method? I'd expect this to limit its use in registration to derivative free optimizers.

Hi,
You bring up a really good point that I also struggled with.
There are a few things that make this backward compatibility issue a bit
complex.

This patch addressed a bug - which was clearly a bug: SetScale and
SetSkew were not calling ComputeOffset.  So, the previous implementation
never really worked.

The way the ScaleSkewVersor transform was previously implemented was
also misleading at best (and arguable simply wrong).  The "scale"
parameters didn't control scale (they were added to the matrix diagonal -
which would effect a rotation and scaling if no other values are changed)
and the "skew" parameters didn't control skew (they were added to the
offdiagonal and had 6 values when only 3 are needed for skew - using 6
produces a non-symmetric skew matrix and I don't know what the heck kind of
transform that is, but it isn't just skew).

So, I agree with you that the documentation needs update and this needs to
be added to the migration guide, but I wonder if we need to preserve the
original misleading and broken implementation for the sake of backward
compatibility.  I would call having 6 parameters for skew "wrong", just as
not calling ComputeOffset was wrong.
If you do want to preserve the "wrong" implementation, then I agree with
renaming the one that I created to something new, but I think that keeping
the old implementation around is a disservice to the community.
Thanks,
Stephen
PS> I will look at the Jacobean.  I completely forgot to update it - thanks
for catching it!   I think it could be removed for now, and an issue
assigned to me.   That is the only change I recommend for now.
On Mon, Jan 6, 2020 at 2:42 PM Bradley Lowekamp<EMAIL_ADDRESS>wrote:

Hello @dzenanz https://github.com/dzenanz @aylward
https://github.com/aylward,
I am just encountering this change due to test failures in SimpleITK.
I have a couple issue with this patch:

The number of parameters has changed. This means that previously
written transforms are now broken, and unusable.
The latex definition of the transforms and their compositions were
not updated:
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Transform/include/itkScaleVersor3DTransform.h#L31
The JacobianWithRespectToParameters was not updated. When I
discovered this class used the odd "+" for the composition instead of
matrix multiplication I thought it was a bug and considered a similar fix.
I recall using symbolic differential tools to compute the Jacobian with
respect to parameters and it was impossibly complicated due to parameter
interaction, where as if the the addition matrix composition was with the
scale and skew matrixes, the values were trivial as previously defined.

I suggest the the old transform remain as it was for compatibility and a
new "ComposedScaleSkewVersor3DTransform" be created. Perhaps the new
transform could be implemented with out a Jacobian method? I'd expect this
to limit its use in registration to derivative free optimizers.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/InsightSoftwareConsortium/ITK/pull/1523?email_source=notifications&email_token=AACEJLY54KJI75G62RHE6R3Q4OCSBA5CNFSM4KBN5QN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIGRO7I#issuecomment-571283325,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACEJLZLSJWPBV3B3MZEFX3Q4OCSBANCNFSM4KBN5QNQ
.

--
Stephen R. Aylward, Ph.D.
Senior Director of Strategic Initiatives

@aylward I agree that the old implementation was wrong.  I remember having long discussions about this at a NAMIC meeting.  At that time, the argument was that backward compatibility for files written to disk should be maintained because those sets of parameters may define a transform that is useful even if it is mathematically nonsensical.   There may be 1000's of these transforms stored on disk that could still be applied, even if this configuration of parameters should never be allowed for future transform optimizations.
I would recommend making a new class with a new name, and then deprecating the old broken version.

@aylward @hjmjohnson
I mistakenly linked to the "ScaleVersor3DTransform", which also has the same additional type of matrix.
I just check 3D Slicer the "General Registration (BRAINS)" has both the "Rigid+Scale(7 DOF)" and "Rigid+Scale+Skew(10 DOF)". So these transform are being  use for registration.

This patch addressed a bug - which was clearly a bug: SetScale and
SetSkew were not calling ComputeOffset.  So, the previous implementation
never really worked.

That is a bug to me too. However, the transforms were functioned correctly for registration and IO, but not are broken.

The way the ScaleSkewVersor transform was previously implemented was also misleading at best (and arguable simply wrong).

Yes, I agree again. That is why we clearly documented that addition was occurring.

the "skew" parameters didn't control skew (they were added to the offdiagonal and had 6 values when only 3 are needed for skew - using 6 produces a non-symmetric skew matrix and I don't know what the heck kind of transform that is, but it isn't just skew).

The new skew matrix for composition look like is just the upper triangle, and still non-symmetric. Did you intend to add a symmetric  skew?

If you do want to preserve the "wrong" implementation, then I agree with
renaming the one that I created to something new, but I think that keeping
the old implementation around is a disservice to the community.

The motivation is to preserve results in transforms that already exit and more forward to a sensible transform that both has meaning for names and correctly works with registration.

Ok - good points regarding existing files and such.
We can make what I submitted to be a "new" transform - I like the name
suggested by Brad.
Yes, with the decomposition I did for scale and skew, the skew becomes an
upper triangle matrix.  I believe it is correct as-is.  It isn't limited to
symmetric in this decomposition.  However, I'm guessing many of y'all know
these things better than me, so...
Since I caused this mess, I can fix it.   What git pattern do you want to
use? (perhaps just create a new branch and pull request instead of
reverting?)
s
On Mon, Jan 6, 2020 at 3:22 PM Bradley Lowekamp<EMAIL_ADDRESS>wrote:

@aylward https://github.com/aylward @hjmjohnson
https://github.com/hjmjohnson
I mistakenly linked to the "ScaleVersor3DTransform", which also has the
same additional type of matrix.
I just check 3D Slicer the "General Registration (BRAINS)" has both the
"Rigid+Scale(7 DOF)" and "Rigid+Scale+Skew(10 DOF)". So these transform are
being use for registration.

This patch addressed a bug - which was clearly a bug: SetScale and
SetSkew were not calling ComputeOffset. So, the previous implementation
never really worked.

That is a bug to me too. However, the transforms were functioned correctly
for registration and IO, but not are broken.

The way the ScaleSkewVersor transform was previously implemented
was also misleading at best (and arguable simply wrong).

Yes, I agree again. That is why we clearly documented that addition was
occurring.
the "skew" parameters didn't control skew (they were added to the
offdiagonal and had 6 values when only 3 are needed for skew - using 6
produces a non-symmetric skew matrix and I don't know what the heck kind of
transform that is, but it isn't just skew).
The new skew matrix for composition look like is just the upper triangle,
and still non-symmetric. Did you intend to add a symmetric
https://en.wikipedia.org/wiki/Skew-symmetric_matrix skew?
If you do want to preserve the "wrong" implementation, then I agree with
renaming the one that I created to something new, but I think that keeping
the old implementation around is a disservice to the community.
The motivation is to preserve results in transforms that already exit and
more forward to a sensible transform that both has meaning for names and
correctly works with registration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/InsightSoftwareConsortium/ITK/pull/1523?email_source=notifications&email_token=AACEJLYCRDICMIBDERG5VBDQ4OHGZA5CNFSM4KBN5QN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIGVGNA#issuecomment-571298612,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACEJL3GEVRYZGWSO7BSEMTQ4OHGZANCNFSM4KBN5QNQ
.

--
Stephen R. Aylward, Ph.D.
Senior Director of Strategic Initiatives

a new branch and pull request

It does not have to be " instead of reverting". Revert can be the first commit in that branch.

@aylward The easiest thing to do to revert these changes it to click on the "Revert" button above next to the "merge commit". I tried it and it looks correct. This can be merged before the new class is created.
But, before you update your local master branch, just mv these two files to the new "itkComposedSkewScaleVersor3DTransfrom" file names. Then you should be able to create a new branch and work locally as normal.


Reduce repo size by removing accumulative commits in CI job

Closes #5908
The arrow-rs repo size grows very huge due to this CI job:
https://github.com/apache/arrow-rs/blob/master/.github/workflows/docs.yml#L72-L97
Basically, whenever a PR is merged into master, this job will be triggered and will publish a new commit to the branch asf-site. Each commit contains files extracted from the tarball file (which contains the rust doc). This gradually grows the repo size since commit is accumulative on previous one and thus the repo overall gets larger.
This PR proposes to use the option force_orphan available here which allows us to publish our commit with only the latest commit.

I added a comment with the rationale for this setting (so a future reader might understand). I plan to merge this PR when the CI jobs complete (I think the only way to really test it is "in producton") 🚀

🚀

https://github.com/apache/arrow-rs/actions/runs/9748618390/job/26904074621
Seems to have worked
/usr/bin/git commit -m deploy: 8284e5f4ff507bb664dc47a3a96ff51433f99dc7
  Auto packing the repository in background for optimum performance.
  See "git help gc" for manual housekeeping.
  [asf-site (root-commit) 94d5b74] deploy: 8284e5f4ff507bb[66](https://github.com/apache/arrow-rs/actions/runs/9748618390/job/26904074621#step:5:71)4dc47a3a96ff51433f99dc7
   5312 files changed, 574765 insertions(+)
   create mode 100644 .asf.yaml
   create mode 100644 .lock
...

And asf-site shows only a single commit: https://github.com/apache/arrow-rs/commits/asf-site/

Thanks again @Owen-CH-Leung


Issues #SB-11768 fix: adding some delay in user search

Codecov Report

Merging #469 into release-1.15 will decrease coverage by <.01%.
The diff coverage is 0%.

@@                Coverage Diff                 @@
##             release-1.15     #469      +/-   ##
==================================================
- Coverage           40.72%   40.72%   -0.01%
  Complexity            775      775
==================================================
  Files                 110      110
  Lines                7636     7637       +1
  Branches              859      859
==================================================
  Hits                 3110     3110
- Misses               4186     4187       +1
  Partials              340      340

Impacted Files
Coverage Δ
Complexity Δ

...n/java/org/sunbird/common/models/util/JsonKey.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...rd/common/util/KeycloakRequiredActionLinkUtil.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3306bdd...30ed669. Read the comment docs.


test: add 100 internal transfers case

I believe this was not merged due to the tests becoming prohibitively slow.


[web]: Support crossorigin network images

A widget like Image.network(/* url */) does not show when url comes from a different origin. The image bytes are downloaded from the network.

Does the image come from the same origin? CORS disallows XHR requests across origins.

@yjbanov in my case the images do not come from the same origin. Any quick tips on how to make this work? Can we add crossorigin="anonymous" somehow?

@yjbanov yes from a different origin.

We should be able to support crossorigin="anonymous" in the HTML backend. We'd need to audit our codebase for things that could break due to tainting the canvas, or avoid tainting altogether (e.g. by falling back to SVG or HTML).
Supporting this in WebGL without a proper CORS handshake is trickier. We will likely need to compose the scene graph together with <img> tags, but doing this efficiently in the presence of multiple crossorigin images can be tricky.

This only seems to be an issue with the CanvasKit backend. When using the html backend the same images work.
My images are in a gcs bucket where I am able to set the CORS configuration (https://cloud.google.com/storage/docs/configuring-cors).

When using the html backend the same images work.

Yes, we recently switched to using the <img> tag, which supports this out-of-the-box. Heads up though, there are some known issues with this approach, and so it's not yet super-clear if we can keep it as is.

@CaseyHillers is this what's keeping the commit author avatar images from showing in https://flutter-dashboard.appspot.com/#/build?

@tvolkert yes. For the flutter-dashboard app's use case, the DOM implementation works.
Do you know if this would impact http.get for the author image bytes from GitHub? If we can get the image bytes, we could use Image.fromBytes to show the author image.

I imagine it would also affect http.get, since it would be subject to the same CORS policy.

@tvolkert  I was able to get this to work in the build dashboard, so i'm not sure this was a CORS issue. I was able to do an http.get from the build dashboard to GitHub to get the avatar bytes, then I was able to use Image.memory to show it. I haven't tracked down yet why the engine isn't doing this.

I have the same issue , is there any workarround ?

I have the same issue , is there any workarround ?

Workaround for those still looking:
Append "https://cors-anywhere.herokuapp.com/" to the src of your network image
String src = "https://sourceofimage.com/image.png"
Image.network("https://cors-anywhere.herokuapp.com/"+ src)

Workaround for those still looking:
Append "https://cors-anywhere.herokuapp.com/" to the src of your network image
String src = "https://sourceofimage.com/image.png"
Image.network("https://cors-anywhere.herokuapp.com/"+ src)

We have documented various options available for CORS images at https://flutter.dev/docs/development/platform-integration/web-images. There's a push to require CORS on the plain <img> tags as well because of Spectre, so <img> will stop being an effective escape hatch.

Workaround for those still looking:
Append "https://cors-anywhere.herokuapp.com/" to the src of your network image
String src = "https://sourceofimage.com/image.png"
Image.network("https://cors-anywhere.herokuapp.com/"+ src)

You can use https://cors.bridged.cc/ aswell

A workaround for those who have enabled CORS but still cannot render images ->
https://flutter.dev/docs/development/tools/web-renderers

Workaround for those still looking:
Append "https://cors-anywhere.herokuapp.com/" to the src of your network image
String src = "https://sourceofimage.com/image.png"
Image.network("https://cors-anywhere.herokuapp.com/"+ src)

You can use https://cors.bridged.cc/ aswell

https://cors.bridged.cc/ it worked for me !

Workaround for those still looking:
Append "https://cors-anywhere.herokuapp.com/" to the src of your network image
String src = "https://sourceofimage.com/image.png"
Image.network("https://cors-anywhere.herokuapp.com/"+ src)

You can use https://cors.bridged.cc/ aswell

it works Done and you can use http.get()

for build: flutter build web --release --web-renderer html
for local: flutter run --web-renderer html


propagating clicks through Overlay

I'm not sure this is even possible without ugly hacks, so just throwing this out there.
Currently, when you have one select open and you try to open another (or focus any input), it will simply close the first select and do nothing. It's gotta be said that this is actually the native behaviour as well (on mac anyway), but I think it would be pretty nice if Overlay would be able to determine that there's a focusable material component underneath the coordinates it was closed from by clicking and trigger focus/open whatever.
https://gist.run/?id=546a55a20f515cc2cb551f891d426c43

We actually do this on purpose in order to mimic the native behavior (and same in AngularJS Material). The idea is that end-users are accustomed to this behavior and changing it would be surprising.


Terminal and Debug button both open the Debug Shell

Describe the bug
Using OrbStack 1.5.1 on Mac. When clicking on "Terminal" in the right UI pane the Orb Stack Debug Shell opens.
To Reproduce

Start a Container
Click on the Container in the UI
Click on "Terminal" in the right pane

Expected behavior
A "normal" shell opens, not the debug shell.
Diagnostic report (REQUIRED)
n/a
Screenshots and additional context (optional)
No response

Intended behavior. They're only different for non-Pro users. What use case do you have that actually requires a non-Debug Shell terminal?

The problem we had is the confusion about file/directory ownership (I wrote this in an email to you yesterday): The debug shell does not show the correct file owners for volumes bind mounted by MacOS.
Since – as you wrote – this is expected behaviour I thought it might be helpful to have one button for the Standard-Terminal and one button for the Debug shell.

I replied to your email and explained that the file owner behavior you saw is not related to Debug Shell.

Yes, I understood. For us it would've been helpful to have a Terminal button which opens bash in the container. But not a big deal, thanks for the quick reply.


fix(notifications): export notificationSeverities for reuse

The ordered array of constants is exported by the notifications-common for reusability by other plugins.
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

not stale
Cc @Rugvip


[GH-993]: added support for subtasks in subscriptions

Summary
Added functionality to support subtasks Jira subscription.
Screenshots
Old

New

Issues
Fixes https://github.com/mattermost/mattermost-server/issues/993

@mickmister Added the first part of the changes as per our discussion on https://github.com/mattermost/mattermost-plugin-jira/issues/993. Please have a look

@AayushChaudhary0001 You have to enable the below setting in system console to see that:


Linking with filament: -fPIE/-fPIC issue

I've just downloaded the prebuilt libraries for linux and tried to link them in my project which gave me this error:
/usr/bin/ld: filament-prefix/src/filament/lib/x86_64//libimage.a(KtxBundle.cpp.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object;
recompile with -fPIE

If I understand that error correctly, it's telling me to recompile libimage.a with -fPIE. I had a discussion with someone who explained me -fPIE is an alias for -fPIC. After some reading up I found a StackOverflow post with a command that allows you to check if an object/library was compiled with -fPIC. It seems libimage.a was compiled with -fPIC which makes me wonder why I get that error (especially if -fPIE is an alias for -fPIC).
I did a couple of tests, enabling/disabling POSITION_INDEPENDENT_CODE in my CMakelists.txt but nothing solved the issue.
I was able to compile and link filament by using the filament repository as an external project and building it from source:
ExternalProject_Add(
    filament
    GIT_REPOSITORY https://github.com/google/filament.git
    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
)

I'm trying to figure out why I can't use the prebuilt libraries? Any thoughts? Maybe it's because of compiler defaults? (Using clang 9)

Looks like the CMakeLists for libs/image is missing the following line:
target_compile_options(${TARGET} PRIVATE  $<$<PLATFORM_ID:Linux>:-fPIC>)

I think this will help you out in our future releases.  Sorry for trouble.

Can this be added please so we don't have to do it by hand at every new release? Or is there a problem doing this in general?

We should already be using -fPIC everywhere.

1.8.0 doesn't. Adding that line in 1.8.0 fixes the problem.

That's an oversight we need to fix then.

For the record: I encountered this with filament built from source myself; no idea if you do something different for the binary releases, but in any case, would be nice to have fixed. Thanks.

According to find libs/ -name "CMakeLists.txt" | xargs grep -l install, these are our installable libraries:
libs/filaflat/CMakeLists.txt
libs/bluegl/CMakeLists.txt
libs/utils/CMakeLists.txt
libs/math/CMakeLists.txt
libs/bluevk/CMakeLists.txt
libs/gltfio/CMakeLists.txt
libs/image/CMakeLists.txt
libs/filabridge/CMakeLists.txt
libs/ibl/CMakeLists.txt
libs/matdbg/CMakeLists.txt
libs/camutils/CMakeLists.txt
libs/geometry/CMakeLists.txt
libs/filameshio/CMakeLists.txt
libs/mathio/CMakeLists.txt
libs/filamat/CMakeLists.txt

We should make it so that they all have:
if (MSVC)
    target_compile_options(${TARGET} PRIVATE $<$<CONFIG:Release>:/fp:fast>)
else()
    target_compile_options(${TARGET} PRIVATE $<$<CONFIG:Release>:-ffast-math>)
    target_compile_options(${TARGET} PRIVATE -Wno-deprecated-register)
endif()

target_compile_options(${TARGET} PRIVATE $<$<PLATFORM_ID:Linux>:-fPIC>)

I might fix this by creating a macro in our root-level CMake file for the above snippet.

On second thought, maybe the root-level CMake file should simply set up CMAKE_CXX_FLAGS and CMAKE_CXX_FLAGS_RELEASE (which it already does for some flags, but not for these).  This would guarantee consistency across all our subprojects.
I'll give it a try.

Similarly, CMAKE_POSITION_INDEPENDENT_CODE=1 sets the default POSITION_INDEPENDENT_CODE property.


Weird attribute assignment syntax

In Ruby, the following code is invalid:
a = [:foo] * 3
a[0] = :bar
a.[](1) = :baz # syntax error

However, this works fine (by accident?) in Crystal, where a.[](1) = :baz is the same as a.[]=(1, :baz) (or a[1] = :baz)
Parser#can_be_assigned? probably should check if Call#has_parentheses is false when Call#name is "[]"
Here's my crystal -v:

Crystal 1.6.2 (2022-11-03)
LLVM: 14.0.6
Default target: x86_64-apple-macosx

a.[](1) = :baz and a.[] 1 = :baz should be invalid. The combination of standard call syntax with an operator method name and assignment is confusing.
Note that a.[]=(1, :baz) should continue to work, though.

#14527 seems to have made a.[](1) = :baz into a syntax error.
All that's left now before this issue can be closed is a.[] 1 = :baz


Don't show "tip not sent with comment" warning, when it's sent with a tip

OLD:

NEW (removes the warning from comment tips):

oh wow, how'd we miss that haha


Data Validation

Add input validation of the data received while creating a new account to ensure only properly formed data is entering the workflow.
Entries to be verified:

Name should not be of length less than 3.
Should be a valid email address.

Working on this

File in /src/TopMenu.js
`	const handleRegister = e => {
e.preventDefault();
if(name.length <= 3){
setAlert('Name should not be of length less than 3.', 'danger');
}
const re = /^(([^<>()[]\.,;:\s@"]+(.[^<>()[]\.,;:\s@"]+)*)|(".+"))@(([[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}])|(([a-zA-Z-0-9]+.)+[a-zA-Z]{2,}))$/;
re.test(String(email).toLocaleLowerCase);
if(re.test(email) == false){
setAlert('Not valid email address!', 'danger');
}
	if (name === '' || email === '' || password === '') {
		setAlert('Please fill in all fields', 'danger');
	} else {
		console.log('register called');
		showLoading({ data: true });
		register({
			name,
			email,
			password
		});
	}
};`

Can it be considered as fix for this issue?

I'll be happy to contribute.

Can it be considered as fix for this issue?

Yes, it's working fine!
Thanks


Wrong pose got when using TF

Hi, I use:
ROS2 version: humble (I also use the "humble" branch)
ROBOT: UR10e
First, I run ros2 launch ur_robot_driver ur_control.launch.py ur_type:=ur10e robot_ip:=<IP_ADDRESS> launch_rviz:=false
then, I want to echo the pose information about the flange, so I run ros2 run tf2_ros tf2_echo base flange
then I got this:
At time<PHONE_NUMBER>.12247712
- Translation: [0.246, -0.249, 0.619]
- Rotation: in Quaternion [0.170, 0.472, -0.074, 0.862]
- Rotation: in RPY (radian) [0.421, 0.994, 0.059]
- Rotation: in RPY (degree) [24.108, 56.975, 3.383]
- Matrix:
  0.544  0.288  0.788  0.246
  0.032  0.931 -0.363 -0.249
 -0.838  0.223  0.497  0.619
  0.000  0.000  0.000  1.000

while, the pose information on the teaching pendant was like:
TCP
x: 243.69mm
y: -249.04mm
z: 618.32mm

Rx: 149.49 degree
Ry: -12.78 degree
Rz: 72.64 degree

Apparently, the position coordinate was almost right, but the rotation in RPY I got from ros2 was wrong.
what should I do to get the right pose from tf?
thank you for your answer~

@WundtAsim I'll close this as duplicate of #788, but thanks for bringing my attention to this once more.

Since #788 was resolved to be not an issue with the driver, I'll reopen this.
@WundtAsim In order to get the same values, please make sure you

Use a calibrated URDF.
Make sure that on the TP you select "Base" as reference and not "View" or "Tool".
Make sure to check tool0, not flange. Flange and tool0 use different orientation standards.
Make sure to look at the same rotation convention. The TP by default shows the Rotation vector notation. For example, on the shell I get- Translation: [-0.144, -0.436, 0.202]
- Rotation: in Quaternion [-0.000, 1.000, 0.012, 0.013]
- Rotation: in RPY (radian) [3.117, 0.025, -3.141]
- Rotation: in RPY (degree) [178.570, 1.437, -179.973]
- Matrix:
 -1.000 -0.001  0.025 -0.144
 -0.000  1.000  0.025 -0.436
 -0.025  0.025 -0.999  0.202
  0.000  0.000  0.000  1.000

In the default view I see this:

However, when you click on the rotation fields, you'll get to another view where you can select "RPY (rad)" This will show the same values as ROS:

I hope this explanation helps.

Thanks！

I just tried 'tool0' and realized my error, Now I can get the right RPY degree which carries an error of 0.003 [rad] level.
I have extracted the calibration information file to my home path, but the position in ros2 still has an error of 2mm. I have tried the way #711 showed, but the error still be there. how can I confirm the calibration file is working?@fmauch
(Btw, I didn't modify any code in this repository)

I've explained here how to verify that the correct calibration is actually being used.

Thank you all for your support in addressing this issue. It has been determined that the problem I encountered was related to the calibration process on my end.
Appreciate to @fmauch and @cpsiff  for providing assistance in troubleshooting the issue.

@WundtAsim Any hints what we could improve in the documentation to avoid things like this in future?


Seemingly incorrect test equivalency between FCS_TLSC_EXT.1.1 test 3 and FCS_TLSC_EXT.1.5

Provide the location of the issue
In FCS_TLSC_EXT.1.1 test 3
What is the correction request for the cPP? Please describe.
In FCS_TLSC_EXT.1.1 test 3, the test case says the following: "Perform this test only if support of TLS 1.2 is claimed (corresponding testing for TLS 1.3 is covered by the tests for FCS_TLSC_EXT.1.5)"
This appears to incorrectly imply that FCS_TLSC_EXT.1.5 test cases cover the same result, but for TLS 1.3.  That is incorrect since FCS_TLSC_EXT.1.5 has no negative testing and FCS_TLSC_EXT.1.1 test 3 is only a negative test case.
Describe the solution you'd like
Remove the following in FCS_TLSC_EXT.1.1 test 3: "(corresponding testing for TLS 1.3 is covered by the tests for FCS_TLSC_EXT.1.5)"
The same solution should be applied to FCS_DTLSC_EXT.1 as well.
Describe alternatives you've considered
N/A
Additional context
N/A

TLSWG agreed to Greg's suggested change on today's call.