Building the theme started to fail with 6.11.5

Seems like the zipping portion broke.
🔏 Building the keycloak theme...⌚
🫶 Let keycloakify do its thang
node:events:491
      throw er; // Unhandled 'error' event
      ^

ReferenceError: Blob is not defined
    at utf8size (/workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:58:5)
    at localHeader (/workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:67:24)
    at /workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:183:20
    at step (/workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:33:23)
    at Object.next (/workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:14:53)
    at /workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:4:12)
    at writeDir (/workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:174:45)
    at /workspaces/center-web/node_modules/.pnpm/keycloakify@6.11.5_3stiutgnnbnfnf3uowm5cip22i/node_modules/keycloakify/bin/tools/zip.js:233:42
Emitted 'error' event on Transform instance at:
    at Transform.onerror (node:internal/streams/readable:773:14)
    at Transform.emit (node:events:513:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

Hello @juanpin-humane,
Sorry about this, we'll investigate.
In the meantime you can rollback to using maven with:
package.json
"keycloakify": {
    "bundler": "mvn"
}

https://docs.keycloakify.dev/build-options#keycloakify.bundler
Could you by any hance produce a reproduction path?
That would help a lot.
Hi, @lordvlad, any idea?

I'm going to try the latest versions to isolate exactly when did it broke and try your alternative. Thank you so much for the fast response @garronej !!!

You're welcome, It should be fixed in 6.11.7 :))

Hi, sorry, only now saw the message. @garronej I see that importing Blob resolved the issue? Looks like a nodejs version difference then? Something like in newer versions it is present in the global context, but not in an older version? @juanpin-humane can you tell which nodejs version you are using?

@lordvlad node 16

Just verified , it's fixed.

Thanks @juanpin-humane for taking the time to give feedback :)


TLS on MySQL crash

Error: [/Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/mysql_common-0.26.0/src/crypto/der.rs:35:18]
valid PEM is mandatory here

Command: prisma db pull
Version: 3.10.0
Binary Version: 73e60b76d394f8d37d8ebd1f8918c79029f0db86
Report: https://prisma-errors.netlify.app/report/13689
OS: x64 darwin 19.6.0
JS Stacktrace:
Error: [/Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/mysql_common-0.26.0/src/crypto/der.rs:35:18] valid PEM is mandatory here
    at ChildProcess.<anonymous> (/Users/mihee/.npm/_npx/2778af9cee32ff87/node_modules/prisma/build/index.js:46135:30)
    at ChildProcess.emit (node:events:527:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)

Rust Stacktrace:
   0: backtrace::backtrace::trace
   1: backtrace::capture::Backtrace::new
   2: user_facing_errors::Error::new_in_panic_hook
   3: user_facing_errors::panic_hook::set_panic_hook::{{closure}}
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_handler::{{closure}}
   6: std::sys_common::backtrace::__rust_end_short_backtrace
   7: _rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic_display
  10: core::option::expect_failed
  11: mysql_common::crypto::der::pem_to_der
  12: mysql_common::crypto::rsa::PublicKey::from_pem
  13: mysql_common::crypto::encrypt
  14: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  15: mysql_async::conn::Conn::new::{{closure}}
  16: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  17: mysql_async::conn::Conn::new::{{closure}}
  18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  19: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  20: introspection_engine::rpc::RpcImpl::load_connector::{{closure}}
  21: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  22: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  23: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
  24: <futures_util::future::future::Then<Fut1,Fut2,F> as core::future::future::Future>::poll
  25: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
  26: tokio::runtime::task::harness::poll_future
  27: tokio::runtime::task::raw::poll
  28: std::thread::local::LocalKey<T>::with
  29: tokio::runtime::thread_pool::worker::Context::run_task
  30: tokio::runtime::thread_pool::worker::Context::run
  31: tokio::macros::scoped_tls::ScopedKey<T>::set
  32: tokio::runtime::thread_pool::worker::run
  33: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
  34: tokio::runtime::task::harness::Harness<T,S>::poll
  35: tokio::runtime::blocking::pool::Inner::run
  36: std::sys_common::backtrace::__rust_begin_short_backtrace
  37: core::ops::function::FnOnce::call_once{{vtable.shim}}
  38: std::sys::unix::thread::Thread::new::thread_start
  39: __pthread_start

User also created a (minimal) bug report at: https://github.com/prisma/prisma/issues/12196 Asked for more details.

no solution so far??

I'm using the "mysql2" package and it is working normally, prisma isn't.
A tip that may help to find the solution to the problem, I'm using RDS from AWS.

@henriqueArrazao Have you looked at prisma.io/docs/concepts/database-connectors/mysql#configuring-an-ssl-connection and followed the steps there?

@henriqueArrazao Did https://www.prisma.io/docs/concepts/database-connectors/mysql#configuring-an-ssl-connection worked for you?

We haven't heard back about this issue, so we'll close it for now as we need a few more details to be able to dig into this problem. Don't hesitate to add more details in a new comment, and we'll be happy to reopen the issue. Thank you! :pray:


Please, translate code comments to english

I was investigating some issues with the library, and struggled to understand the intent behind the code. Yes, It's quite clear what code does, but intent of this code is far from clear w/o comments. Machine translators don't help. I'm not native english speaker, but still think that currently it's an universal language that almost every developer understands. Even GH issues here are in english.
Thank you!

@dcbrwn I need free time. Rewrite the code with TypeScript and use English comments.

This needs to wait for my free time, maybe soon.

The translation alone would be a great help for contributors. Thanks for your efforts!


tag a versioned release

hello!  i'd like to add this software to Homebrew, but in order to do so the maintainer must provide a way to automatically download a specific numbered release.  would you mind tagging a versioned release?

Sure, thank you! Here's a versioned release: v0.2.3.


feat: add feature flags e2e test

Issue being fixed or feature implemented

Need test feature flag functionality
What was done?

New feature flags e2e test was added
How Has This Been Tested?

Breaking Changes

Feature flag test requires latest versions
Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added or updated relevant unit/integration/functional/e2e tests
[x] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[x] I have assigned this pull request to a milestone

LGTM! 👍  Good job!


[TC-90] Recovered changes for @elsloo

Can one of the admins verify this patch?

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-traffic_ops-test-PR/17/

This is already merged from another PR. Closing.


Composition window in the edit_text example is mispositioned on macOS

We need to divide by DPI in the returned text bounding box

Is DPI being read correctly in Mac OS? In Druid, which this is forked from, I found that it just returned no scale factor on Mac OS.

:O that might explain it!


Don't allow this in decorator expressions

e.g. @this.method() is invalid

FYI @rbuckton

Woah, interesting.
class C {
    decorator(...args) {

    }

    foo() {
        @this.decorator
        class WAT {
        }
    }
}

is apparently not allowed


Implement Iterator#toSeq

fixes https://github.com/vavr-io/vavr/issues/2253

Codecov Report

Merging #2533 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #2533      +/-   ##
============================================
+ Coverage     93.04%   93.04%   +<.01%
- Complexity     5299     5300       +1
============================================
  Files            89       89
  Lines         12761    12762       +1
  Branches       1606     1606
============================================
+ Hits          11874    11875       +1
  Misses          702      702
  Partials        185      185

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/io/vavr/collection/Iterator.java
89.56% <100%> (+0.01%)
182 <1> (+1)
:arrow_up:

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 ddddc8b...9366e20. Read the comment docs.


No license listed

There isn't a license statement in the code. I recommend Apache 2 or GPL, but it would be nice to have the license spelled out either in the code or the readme or both.

Thank you
I will do that

Thanks. BTW, I added your theme to awesome-zsh-plugins

A LICENSE.md file is now present


Request: Clear Inventory

I have a request; a clear inventory command. I suppose it could look like this:
/ci
[clears everything]
/ci main
[clears top box]
/ci bar
[clears the main bar]

I chuckled when I saw this lazy idea.


Conflicting peer dependencies vue

Environment

Operating System: Windows_NT
Node Version:     v14.19.1
Nuxt Version:     2.16.0-27358576.777a4b7f
Package Manager<EMAIL_ADDRESS>Builder:          webpack
User Config:      ssr, head, css, loading, plugins, components, buildModules, modules, vuetify, build, bridge
Runtime Modules:  -
Build Modules<EMAIL_ADDRESS><EMAIL_ADDRESS>

Reproduction

Describe the bug
while install dependences with pnpm, got error above, after checking dependency in bridge/package.json#L30 and @vueuse/head#package.json#L83
bridge depent on @vue/hear which requires vue3 as a peerDependencies
but bridege is made for migrating a Nuxt 2 project. which means the project is still using vue2 for now.
Additional context
No response
Logs
No response

We've now removed @vueuse/head as a dependency of Bridge. (Users who wish to use the experimental meta integration can install it separately.)


Ensure division results in a double if original query is Spark

Fixes #72. This has been a cause of incorrect results when migrating (we've caught them, but needed to insert this manually).

@GeorgeSittas this probably doesn't make sense for you to do in SQLGlot but another interesting/annoying interaction between Spark and Trino

Division is tricky to do correctly and the SQL ecosystem is very fragmented around its semantics. Just fyi, 50% of the dialects we support implement integer division semantics and the rest implement float division semantics...
I actually tried to tackle this problem in the past but didn't take types into account so it ended up creating bugs and I had to revert: https://github.com/tobymao/sqlglot/pull/1277.

I guess in the direction you're trying to tackle it here it's solvable because casting to double doesn't truncate the result. The opposite direction is more risky because if you have x / y in Trino, you can't transpile it to CAST(x / y AS INT) for Spark to preserve the integer div semantics, since x or y could be floats and the result would be coerced to a float type.

Ha, I didn't know it was that divided! Somehow figured Spark was doing its own thing here.

I guess in the direction you're trying to tackle it here it's solvable because casting to double doesn't truncate the result. The opposite direction is more risky because if you have x / y in Trino, you can't transpile it to CAST(x / y AS INT) for Spark to preserve the integer div semantics, since x or y could be floats and the result would be coerced to a float type.

Definitely! This here is easy mode 😄


Initial orientation of S2 globe is too sensitive to changes in the boundingVolume value?

Recently we had a problem that two versions of our internal S2 globe was displayed with different initial orientation by Cesium. After investigating we realized that the boundingVolume of the two version had a small decimal difference (7th decimal of PI).
Cesium seems to be sensitive to the exact value of the boundingVolume when opening our internal globe and selecting what S2 face to display as initial orientation.
Cesium is zooming to different S2 faces when opening our internal globe depending on the root boundingVolume value defined in the tileset.json file .
If the root boundingVolume is as follows then Africa (face 0) shown:
"root": {
"boundingVolume": {
"region": [
-3.141592653589793,
-1.5707963267948966,
3.141592653589793,
1.5707963267948966,
-10881.995181892067,
8805.044281111099
]
},
here  -3.141592653589793 is identical to the definition of PI.
If the root boundingVolume is as follows then Antarctica (face 5) is shown:
"boundingVolume": {
"region": [
-3.141592618820418,
-1.5707962986969973,
3.14159264862274,
1.5707962837028416,
-10881.995181892067,
8805.044281111099
]
},
The difference of the bounding volume is:

-3.14159265358979 - -3.141592618820418
-3.47693718261155e-08

Is this as expected? Is it required that the boundingVolume must be identical to PI to orient the globe to display Africa (face 0) as its initial orientation?
We were suprised that our small difference in boundingVolume resulted in the dispaly of different initial S2 faces (Africa/Antarctica).

Hi @pmaxarr, thanks for the repot. Would you mind including a brief code snippet or sandcastle example that shows how you are constructing your scene?
By default, the home view is oriented relative your timezone.
If you are zooming to a bounding sphere, I would not expect such a small difference in the bounding region to cause a difference in orientation.

Attached is a file with two tilesets, tilesetA.json and tilesetB.json, which each just define the bounding volume as described in the first comment. It also contains a sandcastle for loading them and switching between them with a dropdown menu.
S2OrientationIssue.zip

From a quick debug pass, the root cause can (probably) be tracked to this check in the Transforms.js
The bounding spheres of the tilesets are computed as follows
tileset A:
center: Cartesian3 { x: 0, y: 0, z: 0 }
radius: 11050175.466421327
tileset B:
center: Cartesian3 {x: 1.862645149230957e-9, y: 2.7755575615628914e-17, z: -1.862645149230957e-9}
radius: 11050175.466421323
The center that is used as the origin there is obviously EPSILON14-equal to (0,0,0) in the first case, causing ~"some default orientation" (looking at Africa) to be used.
In the second case, the center is not EPSILON14-equal to (0,0,0). It will try to compute some orientation from that, in this line, ending up with east=(-2.7755575615628914e-17, 1.862645149230957e-9, 0) there. These numbers are small enough to consider the initial orientation as ~"random noise".

Focussing on the problem description:
Finding a solution that does not involve discontinuities (in a mathematical sense) could be difficult. When zooming to a sphere with its center at (0.0,,0,0), there is no sensible orientation - so some default has to be used. When the center is at (1.0, 0,0), then there is an orientation. That orientation may be completely different from the default.  What about (0.1...)? What about (0.01...)? What about (0.0000001...)? One could try to come up with something that interpolates between the "default" interpolation to the "computed" interpolation, based on the distance of the center to the origin (maybe "weighted" by the inverse radius of the sphere). But making sure that it is robust and always yields "nice" results could be tricky...

Thank you for the explanation @ggetx and @javagl, I believe I understand the problem now.
We will try avoid bounding spheres that triggers this behavior.

Trying to avoid that problem at the producing side could also be tricky. The fact that the values in the bounding region may be the result of some computation (possibly involving deg-to-rad conversions conversions between CRSes) might make certain rounding errors inevitable. The way how exactly the values are used for computing the initial oprientation is not specified (it might work as expected for a given set of values, because of the EPSILON14-range, but would not work if it was changed to EPSILON15).
One way to imagine the problem could be: Place the bounding shere at the origin, (x=0,y=0,z=0). Now pick it with the mouse, and drag it down the z-axis, slowly, always updating the camera so that it always matches the initial configuration that would be achieved with the zoomTo function. Right now, it would start with the view that looks at Africa. At a certain point (say (x=0,y=0, z=0.00....001)), it will "snap" to the view that looks at Antarctica. Some requirements for the fix would be:

At z=0.0, it should look at Africa (the default)
At z=earthRadius, it should definitely look at Antarctica.
There should be no "snapping" between these values,( i.e. no discontinuity for any z=0...earthRadius)

Maybe some maybe some solution can be derived from that...

For what users can observe here, the problem is that the viewer.zoomTo(tileset) call that is commonly used to center the camera on a tileset will eventually call camera.lookAt(target, offset), with the target being the center of the bounding sphere of the tileset. The implementation of lookAt tries to compute the "east north up (ENU)" matrix for that center/target, which leads into the special cases in the Transforms class that I pointed out earlier. Whether or not these "special cases" are triggered solely depends on some EPSILON14-thresholds. Now, the center of a tileset that describes the whole earth is ... at the center of the earth, i.e. at (0,0,0), and the differences in the tilesets in this issue have just been whether that EPSILON14-case was triggered or not.
So the issue is....

one cannot compute the ENU matrix from (0,0,0).
one can compute the ENU matrix from (1,1,1)
whether or not one can compute a sensible ENU matrix from (1e-10, 1e-10, 1e-10) is up for debate. I'd say "no", but one can just perform the computations and return the result nevertheless...

In terms of solving this, the question boils down to
What is the orientation that should be used when calling lookAt?
This unfolds into several considerations and follow-up questions. One high-level question (although only remotely related to this particular issue) is: Should this depend on whether the scene.globe is present (and whether it is shown) or not?
I could imagine that this should be taken into account. Imagine you have a glTF model that has a size of 10x10x10, load it with globe: false, and you want to lookAt(1,1,1). It will use some orientation that is computed from ENU at a random place on the surface of the earth. Pretty unexpected, I guess. However, one could just say: "You have to use lookAtTransform in this case, and pass in the matrix that you want". More generally, the camera orientation seems to depend on whether the globe is present or not (in subtle and hard to articulate ways), so maybe we don't want to go down that path for now.

I do have an approach, implemented locally, but just as an experiment. The outline is: When calling lookAt, then

compute the "default" orientation (that is used when looking at (0,0,0))
compute the ENU orientation for the actual target (which may or may not be correct)
interpolate between the two, with a weight that depends on the distance of the target to (0,0,0)

That "weight" is currently computed as max(1.0, distance/ellipsoidRadius). This means that

for targets very close to the center of the earth, the default orientation will be used
for targets near the surface of the earth, the computed orientation will be used

It seems to fix the issue for the given tilesets, but feels a bit shady: What does the ellipsoid have to do with all that? Imagine that the distance is 0.5*radius (i.e. somewhere inside the earth). Then it will use an orientation that is just in-between the "default" orientation and the orientation that it would have if it was at the surface of the earth for this location, which could be hard to justify. One could just set the weight to be  max(1.0, distance), and I actually played with that, via if (globe==false) ellipsoid=UNIT_SPHERE, but all this involves guesses about what users/callers might expect from this function...

The overarching question for fixing this issue is: Under which conditions should the zoomTo/lookAt/... and related family of functions even try to compute an "orientation" from a bounding sphere? And the details are subtle, and still have to be sorted out internally.
In the meantime, one way of just avoiding the issue could be to not use lookAt or zoomTo. Instead, one coud use the Camera#lookAtTransform function, which does not try to compute an orientation, but takes the orientation directly as a matrix instead.
Applied to a tileset, this could be
function zoomToTilesetFixed(targetTileset) {
  const boundingSphere = targetTileset.boundingSphere;
  const transform = Cesium.Matrix4.fromTranslation(boundingSphere.center);
  const offset = new Cesium.Cartesian3(boundingSphere.radius, 0, 0);
  viewer.camera.lookAtTransform(transform, offset);
}

Which means that instead of calling
viewer.zoomTo(currentTileset);
one could just call
zoomToTilesetFixed(currentTileset);

In addition to the workaround that was described above: Considering that it is known (at the source) that this tileset is supposed to represent the whole globe, one wokaround could also be to not compute the bounding region, but just insert the (known) fixed bounding region (without the epsilon-deviations) into the tileset JSON. Of course, this would be very specific and a bit quirky, and a more general solution has to be found on the CesiumJS side, but maybe the problem could be avoided for this specific case, at least.


Expose materialize functions in Chlo to Stablehlo lowering

We want to perform constant propogation through chlo.lgamma in Enzyme-JaX
Kevin mentioned he was open to exposing some materialize functions (which are currently static, and not callable from our pass atm)
@wsmoses @GleasonK

Two CI failures. The logs should have commands you can run to autofix

Seems like a formatting issue - let me check

@GleasonK they should all pass now


pull request for e2e test at 11/26/2016 13:26:04

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Add third party licenses

If you are distributing binaries, you also need to include the licenses of the linked libraries. Especially, with MIT license and Apache license, you need to display copyright information. I investigated the linked libraries and gathered each license in one file. Please include this file when distributing the build in the future.
Thank you.
Recipe
$ cd cmd/micro
$ godep save
$ find ./vendor -name 'LICENSE*'

and concat these LICENSE files

Thanks!

I've just added a commit that will include this file in all released tarballs and zip files as well.

That was good!


lag should support negative arguments

At the moment, if we call vector.lag -1 the vector returned has all nils. It would be better if lag supported positive as well as negative shifts.
[16] pry(main)> v = Daru::Vector.new(1..5)
=> #<Daru::Vector(5)>
   0   1
   1   2
   2   3
   3   4
   4   5
[18] pry(main)> v.lag 1
=> #<Daru::Vector(5)>
   0 nil
   1   1
   2   2
   3   3
   4   4
[19] pry(main)> v.lag -1
=> #<Daru::Vector(5)>
   0 nil
   1 nil
   2 nil
   3 nil
   4 nil
[20] pry(main)>

Behavior for pandas shift function for reference:
In [7]: s = pd.Series(range(5))

In [8]: s
Out[8]:
0    0
1    1
2    2
3    3
4    4
dtype: int32

In [9]: s.shift(1)
Out[9]:
0    NaN
1    0.0
2    1.0
3    2.0
4    3.0
dtype: float64

In [10]: s.shift(-1)
Out[10]:
0    1.0
1    2.0
2    3.0
3    4.0
4    NaN
dtype: float64

I suppose this can be marked as fixed as its closed in #355

:+1:


Problem on localhost

Hello,
when i use on localhost (http://localhost/captcha/examples/regular-form.php), i have a problem with playload parameter.
it works randomly.

Tx

Hi melt-cdk! I'm unable to reproduce the error you are reporting with the downloaded source and included examples. Did you make any modifications to the example code? If so, what steps did you take to produce the shown error?

Hi @fabianwennink , no i use your example. tx

I am having this same exact issue using the examples. Sometimes the captcha loads, and most of the times it doesn't.
I click "VERIFY THAT YOU ARE HUMAN" and the blue circle shows forever and I get that same error in console that they did.
I'm using shared hosting not localhost though. (Apache)

@dotworker This issue is related to https://github.com/fabianwennink/IconCaptcha-PHP/issues/26. Somehow, in very rare cases regardless of PHP version, rotating the image 180 degrees with imagerotate causes PHP to throw a 503. I've seen reports of this in other repositories as well, but there seems to not be a real answer or solution for it.
I'll see if I can implement some sort of workaround in a future version.


Remove stale docker restart

In caasp4 we no longer have docker running on the caasp workers,
remove the docker restart that will now fail.

Do we need that copy certificate part? Do we need whole 'build image' path now that the images should be built in OBS?
If yes, and this code is still needed, maybe we need to restart crio service instead of docker

There are two code paths that run these tasks. The build_images path may not be needed anymore (if it's not we should remove that playbook), but this also runs during setup_caasp_workers_for_openstack which looks like it may run on either the caasp workers or the deployer/registry.
I've expanded the change to check for either docker or cri-o and restart as needed.

The build images will hopefully go away once we start consuming images from I/OBS. However lets leave it until we have that workflow more well implemented.


Update OpenAI API call to add tracking user_id field

Backend changes look good. @anastasiya1155 can you push any necessary updates to the client to this branch?


Stop copying annotations from OnePasswordItem and Deployment to Secret

There is no reason for random annotations to be carried over from a Deploument or OnePasswordItem to a Secret. This can lead to weird problems like the kubectl.kubernetes.io/last-applied-configuration annotation ending up on a Secret as reported in #102.
The only annotation that needs to be copied is operator.1password.io/auto-restart, but that already happens explicitly.
Fixes #102.

Actually, there is a need, lot's of integration is based on annotations, not only labels. So user should be able to define annotations for the secret.


ValueError: invalid null reference in method 'BOARD_ITEM___eq__', argument 2 of type 'BOARD_ITEM const &'

Hi! I'm trying to run the KLE plugin, but whenever I do, I get this message:
Traceback (most recent call last):

File "/Users/svamp/Documents/KiCad/8.0/3rdparty/plugins/com_github_zykrah_kicad-kle-placer/kle_placer_action.py", line 514, in Run
placer.Run(dlg.get_key_annotation_format(), dlg.get_stabilizer_annotation_format(), dlg.get_diode_annotation_format(), dlg.get_move_diodes_bool(), dlg.get_relative_diode_bool(), dlg.get_specific_ref_mode_bool())

File "/Users/svamp/Documents/KiCad/8.0/3rdparty/plugins/com_github_zykrah_kicad-kle-placer/kle_placer_action.py", line 296, in Run
first_key = self.get_footprint(key_format.format(1))

File "/Users/svamp/Documents/KiCad/8.0/3rdparty/plugins/com_github_zykrah_kicad-kle-placer/kle_placer_action.py", line 136, in get_footprint
if footprint == None and required:

File "/Volumes/sol2/Apps/KiCad/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/pcbnew.py", line 9450, in __eq__
return _pcbnew.BOARD_ITEM___eq__(self, aItem)

ValueError: invalid null reference in method 'BOARD_ITEM___eq__', argument 2 of type 'BOARD_ITEM const &'

For reference, I'm using KiCad 8.0.3 on an M1 mac, running Sonoma 14.5, and I renamed the switches to MX instead of the default SW. I used marbastlib footprints for the hotswap switches and default library footprints for the rest. The layout is a custom version of a 40% keyboard where the bottom row isn't as wide as the rest of the keyboard.

I use manjaro (xfce) and used the plugin with kicad 7 earlier this year. kicad automatically updated to version 8 and now even after a clean and reinstall the plugin won't work (I tested the exact same situation as in kicad 7). I would assume that this is a version mismatch problem?
best regards, zegonix

Hey, I had the same issue placing footprints in the PCB editor.
https://github.com/zykrah/kicad-kle-placer/issues/11#issuecomment-1754116260
This basically fixed it for me.
Hope it helps.

To expand on @Tharun-jaji 's comment above:
The issue is indeed due to kicad 8. On line no. 136 in kle_placer_action.py, the == needs to be replaced with the is keyword. I manually made this change in the file and restarted kicad. To find where the file is located for your installation, you can look at the error message.
Alternatively, since this change has already been committed into the repository via pull request #14 , you can just download kle_place_action.py from the PR and replace the one for your install. Restart kicad.


My server is crashed and no voice is coming out

My server is crashed,
At 5 am, the server automatically restarts, but is crashanding for this reason.
And besides, no voice is coming out, I use the latest version of Sampvoice, and the latest Open.MP
"version": "openmp-dynssl"
[2024-03-07T05:22:54-0300] [Info] [debug] Native backtrace:
[2024-03-07T05:22:54-0300] [Info] [debug] #0 f0e73f7f in _Z13GetStackTraceRSt6vectorI10StackFrameSaIS0_EEPv () in plugins/crashdetect.so
[2024-03-07T05:22:54-0300] [Info] [debug] #1 f0e6c81d in _ZN11CrashDetect20PrintNativeBacktraceERSoRKN2os7ContextE () in plugins/crashdetect.so
[2024-03-07T05:22:54-0300] [Info] [debug] #2 f0e6ce48 in _ZN11CrashDetect20PrintNativeBacktraceERKN2os7ContextE () in plugins/crashdetect.so
[2024-03-07T05:22:54-0300] [Info] [debug] #3 f0e6e5dc in _ZN11CrashDetect7OnCrashERKN2os7ContextE () in plugins/crashdetect.so
[2024-03-07T05:22:54-0300] [Info] [debug] #4 f0e7379f in ?? () in plugins/crashdetect.so
[2024-03-07T05:22:54-0300] [Info] [debug] #5 f7ef8570 in __kernel_rt_sigreturn () in linux-gate.so.1
[2024-03-07T05:22:54-0300] [Info] [debug] #6 f50e0e3b in ?? () in components/Pawn.so
[2024-03-07T05:22:54-0300] [Info] [debug] #7 f50e122c in ?? () in components/Pawn.so
[2024-03-07T05:22:54-0300] [Info] [debug] #8 f50e10a9 in ?? () in components/Pawn.so
[2024-03-07T05:22:54-0300] [Info] [debug] #9 f50e16d8 in ?? () in components/Pawn.so
[2024-03-07T05:22:54-0300] [Info] [debug] #10 f04fa863 in ?? () in plugins/streamer.so
[2024-03-07T05:22:54-0300] [Info] [debug] #11 f470873c in _ZN4Pawn32OnPlayerActivationKeyPressForAllEth () in components/sampvoice.so
[2024-03-07T05:22:54-0300] [Info] [debug] #12 f4713310 in ?? () in components/sampvoice.so
[2024-03-07T05:22:54-0300] [Info] [debug] #13 08109d78 in ?? () in ./omp-server
[2024-03-07T05:22:54-0300] [Info] [debug] #14 0810419b in ?? () in ./omp-server
[2024-03-07T05:22:54-0300] [Info] [debug] #15 f7b9d519 in ?? () in /lib32/libc.so.6
[2024-03-07T05:22:54-0300] [Info] [debug] #16 f7b9d5f3 in __libc_start_main () in /lib32/libc.so.6
[2024-03-07T05:22:54-0300] [Info] [debug] #17 080f3c52 in ?? () in ./omp-server
[2024-03-07T05:22:54-0300] [Info] [debug] Registers:
[2024-03-07T05:22:54-0300] [Info] [debug] EAX: 0aba7d68 EBX: f533e000 ECX: ffac0ca8 EDX: c4cb5fd7
[2024-03-07T05:22:54-0300] [Info] [debug] ESI: 0000008d EDI: 0000000e EBP: 00000040 ESP: ffac0c78
[2024-03-07T05:22:54-0300] [Info] [debug] EIP: f50e0e3b EFLAGS: 00010296
[2024-03-07T05:22:54-0300] [Info] [debug] Stack:
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000000: 0000008d f50e122c 0aba7d68 ffac0ca8
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000020: 00000001 0ab9d700 0ab9d770 00000040
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000040: 0000000e 0ab9d770 ffac0d78 00000002
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000060: f04f95e9 0aba7d68 ffac0d74 09e31320
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000080: ffac0d74 f059f000 0aba7d68 ffac0d74
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000000a0: ffac0d74 ffac0d74 ffac0d84 0cfb92b4
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000000c0: ffac0d74 f470873c 0aba7d68 f47c796c
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000000e0: 00000000 0c95b64c 00000001 0ab9d968
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000100: 00000000 21c4a700 f4874dc0 00081a28
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000120: ffac0dd6 f4713310 00000002 00000042
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000140: f487cfe0 ffac0dc8 0d5c7fc8 0000018e
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000160: 0d45e680 21c4a700 f4711d67 f486e000
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000180: 09bcd370 08109d78 09b99e6c 0000137a
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000001a0: ffac0032 f7da27c0 0000137a 00000000
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000001c0: f76ff150 0f7f65d1 90e9fa95 0001e2ed
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000001e0: 90e9fa95 0001e2ed 00120031 f76ff14c
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000200: ffac1108 0810419b f75d0010 ffac0ee0
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000220: 00000001 00000000 ffac0ea8 00000004
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000240: 09b9fa30 00000034 00000034 74207470
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000260: 00000000 f7da2044 09b9f8ec 09b9f8e0
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000280: ffac0f10 00000001 00000000 00000000
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000002a0: 00000007 09ba3e90 00000006 3f800000
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000002c0: 00000000 00000000 09ba330c 09ba3300
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000002e0: 09ba2c7c 09ba2c70 09ba2c1c 09ba2c10
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000300: 00000000 080e5f33 ffac0fd4 ffac0fd0
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000320: 0000001f f7c90f53 ffac0fa8 00000000
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000340: ffac0fc0 00000000 f7da2700 09b9d470
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000360: 00000000 00002710 f7b81554 f7f31000
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+00000380: 09b9d490 00000015 ffac1008 00000000
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000003a0: ffac1020 00000000 f7da2700 00000000
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000003c0: 00039000 21c4a700 0808629f 000003e8
[2024-03-07T05:22:54-0300] [Info] [debug] ESP+000003e0: 00002d00 f7c12dff ffac1068 00000000
[2024-03-07T05:22:54-0300] [Info] [debug] Loaded modules:
[2024-03-07T05:22:54-0300] [Info] [debug] 00000000 - 004a9f9b omp-server
[2024-03-07T05:22:54-0300] [Info] [debug] f7ef8000 - f7ef93c2 linux-gate.so.1
[2024-03-07T05:22:54-0300] [Info] [debug] f7ee6000 - f7ee6ac8 /lib32/libdl.so.2
[2024-03-07T05:22:54-0300] [Info] [debug] f7ee1000 - f7ee2168 /lib32/libpthread.so.0
[2024-03-07T05:22:54-0300] [Info] [debug] f7edc000 - f7edd0bc /lib32/librt.so.1
[2024-03-07T05:22:54-0300] [Info] [debug] f7dd4000 - f7eda3fc /lib32/libm.so.6
[2024-03-07T05:22:54-0300] [Info] [debug] f7dad000 - f7dd0eb0 /lib32/libgcc_s.so.1
[2024-03-07T05:22:54-0300] [Info] [debug] f7b7c000 - f7db42b1 /lib32/libc.so.6
[2024-03-07T05:22:54-0300] [Info] [debug] f7efa000 - f7f31b09 /lib/ld-linux.so.2
[2024-03-07T05:22:54-0300] [Info] [debug] f757b000 - f75d4e98 components/GangZones.so
[2024-03-07T05:22:54-0300] [Info] [debug] f6ef8000 - f70653d1 components/LegacyConfig.so
[2024-03-07T05:22:54-0300] [Info] [debug] f6e70000 - f6f009a8 components/Unicode.so
[2024-03-07T05:22:54-0300] [Info] [debug] f6c3c000 - f6e7cc59 /lib32/libstdc++.so.6
[2024-03-07T05:22:54-0300] [Info] [debug] f6be7000 - f6c40e08 components/Pickups.so
[2024-03-07T05:22:54-0300] [Info] [debug] f577d000 - f57db138 components/TextLabels.so
[2024-03-07T05:22:54-0300] [Info] [debug] f56dd000 - f5737594 components/Menus.so
[2024-03-07T05:22:54-0300] [Info] [debug] f568e000 - f56e1bdc components/Checkpoints.so
[2024-03-07T05:22:54-0300] [Info] [debug] f54be000 - f569d3a5 components/CustomModels.so
[2024-03-07T05:22:54-0300] [Info] [debug] f534c000 - f54ce819 components/Console.so
[2024-03-07T05:22:54-0300] [Info] [debug] f4fcb000 - f53d8471 components/Pawn.so
[2024-03-07T05:22:54-0300] [Info] [debug] f4f5f000 - f4fd3f04 components/Objects.so
[2024-03-07T05:22:54-0300] [Info] [debug] f4d54000 - f4f80a74 components/pawnraknet.so
[2024-03-07T05:22:54-0300] [Info] [debug] f4cfc000 - f4d58904 components/Fixes.so
[2024-03-07T05:22:54-0300] [Info] [debug] f4caa000 - f4d00d50 components/Classes.so
[2024-03-07T05:22:54-0300] [Info] [debug] f4a01000 - f4cdd2ad components/LegacyNetwork.so
[2024-03-07T05:22:54-0300] [Info] [debug] f4997000 - f4a0939c components/Vehicles.so
[2024-03-07T05:22:54-0300] [Info] [debug] f45f1000 - f48d9bd4 components/sampvoice.so
[2024-03-07T05:22:54-0300] [Info] [debug] f455b000 - f45b65d0 components/Actors.so
[2024-03-07T05:22:54-0300] [Info] [debug] f44bb000 - f4509ebc components/Timers.so
[2024-03-07T05:22:54-0300] [Info] [debug] f4347000 - f44cca90 components/Databases.so
[2024-03-07T05:22:54-0300] [Info] [debug] f42f8000 - f434b408 components/Variables.so
[2024-03-07T05:22:54-0300] [Info] [debug] f42a8000 - f42fc77c components/Dialogs.so
[2024-03-07T05:22:54-0300] [Info] [debug] f3d37000 - f42d102c components/discord-connector.so
[2024-03-07T05:22:54-0300] [Info] [debug] f3b22000 - f3d42348 /home/samp01/components/../log-core2.so
[2024-03-07T05:22:54-0300] [Info] [debug] f39c8000 - f3b2df91 components/Recordings.so
[2024-03-07T05:22:54-0300] [Info] [debug] f396d000 - f39cc85c components/TextDraws.so
[2024-03-07T05:22:54-0300] [Info] [debug] f0e54000 - f0e9c3d4 /home/samp01/plugins/crashdetect.so
[2024-03-07T05:22:54-0300] [Info] [debug] f0e1d000 - f0e54844 /home/samp01/plugins/sscanf.so
[2024-03-07T05:22:54-0300] [Info] [debug] f05a1000 - f05ffaec /home/samp01/plugins/mysql.so
[2024-03-07T05:22:54-0300] [Info] [debug] f200e000 - f202f108 /home/samp01/plugins/../log-core.so
[2024-03-07T05:22:54-0300] [Info] [debug] eceea000 - ed2fde9f /home/samp01/plugins/../libmysqlclient.so.18
[2024-03-07T05:22:54-0300] [Info] [debug] f04ce000 - f05a2b05 /home/samp01/plugins/streamer.so
[2024-03-07T05:22:54-0300] [Info] [debug] f200a000 - f200d484 /home/samp01/plugins/mapandreas.so
[2024-03-07T05:22:54-0300] [Info] [debug] f0499000 - f04cbdc8 /home/samp01/plugins/chrono.so```

This happened to me too. Do you found any workaround?

Hi @MatheusAgL I fixed it (I think). https://github.com/Tiaansu/sampvoice/commit/9372a87946965b608e74f113e1640d8732fba048


SAK-29180 Remove the PDAHandler, refactor, and cleanup.

(1) Remove and unregister PDA handler, refactor into SiteHandler and cleanup SkinbleCharonPortal
(2) Further removal of PDA code and rename of the sakai.properties that controll inlining
(3) Cleanup the property naming - remove obsolete properties update documentation.
Removed:
portal.pda.autoredirect=false
portal.tablets.use.mobile=false
portal.frameset=
portal.frameset was obsolete long ago - I just took it out of the default properties
and updated the doc while I was in the files.

Nice. +1.  Let's wait for comments and then merge

Because of my lack of github knowledge - I cannot work on SAK-29181 until this one is merged.   So I will sit back and give it a while.

I am closing this and resubmitting with two new small cosmetic cleanup bits.


[help-wanted] How to change a select element

I want to be able to test my Single File Vue Component by selecting an option in a Vue Child component. I need to trigger the Vue watcher that watches selectedFooItem. I am using mocha-webpack and js-global according to the vue-test-utils docs.
This is related to this issue: #128 , and my SO ticket. I also tried going the chat route but Discord tells me I don't have permission to send messages in that channel in vue-land.js.org.
I'm testing a Vue 2 component that has an el-select child component from ElementIO . The main difference in my example is that there is a child Vue component as opposed to HTML elements (i.e. can't rely on .find("select"). It looks like this:
// Foo.vue
<template lang="pug">
  .foo-item(:class="className")
    el-select(v-model="selectedFooItem",
              value-key="name",
              @click="onClick",
              @visible-change="onVisibleChange")
      el-option(v-for="entity in unselectedFooItems",
                :label="foo.name",
                :value="foo",
                :key="foo.name")
</template>

What doesn't work:
1.
const selectBox = wrapper.find("el-select");
selectBox.trigger("click");
wrapper.find('el-option').trigger("click")

I see onClick being called twice (one from el-option). I think this refers to the event propagation behavior the issue I referenced was talking about. But, my watcher does not detect changes.

wrapper.find('el-option').trigger("change")

Still, watcher does not detect changes.

const selectBox = wrapper.find("el-select");
selectBox.trigger("change", { /* the value */ })

My work around
Right now I'm resorting to
wrapper.setData({ foo: 'bar' })

or
wrapper.vm.selectedFooItem = "bar"

If you call wrapper.update() after doing trigger does that make it work? It could be a sync/async issue.

Edit, had a shot at this. Used the element ui template on their website. I think you should be using the change event from element ui, not visible-change. Anyway... using the change event, I get the expected result in the browser - the new item. However, in vue-test-utils under Jest, I get an HTMLUnknownElement as the event.target. I guess some conflict between the library and the vue-test-utils?
The way I made it "work" in vue-test-utils is by adding click to the el-option - but this is not really doing what you want.
I think setting data directly is actually okay - you don't need to test that el-select works, they have their own internal tests. However, I too have found some paint points when it comes to testing components using external libraries... having said that, you should not be unit testing external components anyway, they should have their own tests. vue-test-utils is for testing your components. I think they (and what you see to be doing) should be an integration test. Of course I am also new to unit testing and programming in general, so I could be wrong.
Here is what I tried:
<template>

      <el-select @change="handleChange" v-model="value" placeholder="Select">
        <el-option
           v-for="item in options"
           :key="item.value"
           @click="handleClick(item.value)"
           :label="item.label"
           :value="item.value">
        </el-option>
      </el-select>

</template>

import { shallow, mount } from 'vue-test-utils'
import App from './App'

it('works?', () => {
  const wrapper = mount(App)

  // workaround...bad
  wrapper.findAll('el-option').at(0).trigger('click')

  // works in browser, but not in vue-test-utils.
  wrapper.findAll('el-select').at(0).trigger('change')
})

Can you explain a bit better what you want to test? If you are testing something like

user selects using el-select
vm.value is updated
watcher is called

I think the correct flow should be
setData({ value: 'something' })
expect( whatever the watcher should do?? )

We can assume el-select works, since the author of that lib already tested it.
I hope that helps, please let me know if you have more questions or anything else.
I think for the 1.0 release we should provide some good documentation on what to test, not just how.

To change the value of inputs and update data bound with v-model:
const input = wrapper.find('input[type="text"]')
input.element.value = 'some value' // input element value is changed, v-model is not
input.trigger('input') // v-model updated

const radioInput = wrapper.find('input[type="radio"]')
radioInput.element.checked = true // input element value is changed, v-model is not
radioInput.trigger('input') // v-model not updated
radioInput.trigger('change') // v-model updated

const radioInput = wrapper.find('input[type="radio"]')
radioInput.element.checked = true // input element value is changed, v-model is not
radioInput.trigger('change') // v-model updated

wrapper.findAll('option').at(1).element.selected = true
wrapper.find('select').trigger('change')

There is an open issue to add helper methods to make this easier: #530
I'm closing this issue in favor of that feature request.

It would be nice if all of these examples were in the documentation

Fine!
I also have one question

Okay. I also have one question. Is there a way to test that user can't change value in a disabled input?
For example
const wrapper = mount({
  data: () => ({ val: '' }),
  template: '<input v-model="val" disabled />'
});

wrapper.find('input').element.value = 'testing';
wrapper.find('input').trigger('input');

expect(wrapper.vm.val).toEqual('');
expect(wrapper.vm.val).not.toEqual('testing');

Or it's a browser's work - prevent input on a disabled input?

I believe JSDom supported disabled - does the above snippet not work?

Oh, I made a mistake. Snippet above  does work.
But if I change disabled to readonly it does not work. Maybe it is okay.

Readonly does not prevent events from triggering, or JavaScript from filling the value. You can research disabled and readonly elsewhere.


Hyprland breaks Waybar IPC(?)

Hyprland Version
 System/Version info
Hyprland, built from branch main at commit 56de72f357222beca94e3d4f8152e2523a22c0b3  (internal: store matched windowrules and emit event).
Date: Thu May 2 03:18:01 2024
Tag: v0.39.1-124-g56de72f3, commits: 4584

flags: (if any)

System Information:
System name: Linux
Node name: okinawa
Release: 6.8.8-zen1-1-zen
Version: #1 ZEN SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 15:59:30 +0000

GPU information:
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 XT] [1002:747e] (rev c8) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

plugins:

Bug or Regression?
Regression
Description
I have hyprland/workspaces and hyprland/window in my Waybar config.
With the AUR hyprland-git package version 0.39.1.r124.56de72f3-1, starting Waybar from a terminal running on Hyprland does not show the modules, and logs this into the terminal:
~ ❯ waybar
[2024-05-02 20:52:52.060] [info] Using configuration file /home/flippette/.config/waybar/config
[2024-05-02 20:52:52.061] [info] Discovered appearance 'dark'
[2024-05-02 20:52:52.061] [info] Using CSS file /home/flippette/.config/waybar/style.css
[2024-05-02 20:52:52.063] [info] Hyprland IPC starting
[2024-05-02 20:52:52.063] [error] Hyprland IPC: Unable to connect?
[2024-05-02 20:52:52.064] [error] Hyprland IPC: Couldn't connect to /tmp/hypr/56de72f357222beca94e3d4f8152e2523a22c0b3_1714657518_92406599/.socket.sock. (3)
[2024-05-02 20:52:52.064] [warning] module hyprland/workspaces: Disabling module "hyprland/workspaces", Error parsing JSON: * Line 1, Column 1
  Syntax error: value, object or array expected.

[2024-05-02 20:52:52.064] [error] Hyprland IPC: Couldn't connect to /tmp/hypr/56de72f357222beca94e3d4f8152e2523a22c0b3_1714657518_92406599/.socket.sock. (3)
[2024-05-02 20:52:52.064] [warning] module hyprland/window: Disabling module "hyprland/window", Error parsing JSON: * Line 1, Column 1
  Syntax error: value, object or array expected.

[2024-05-02 20:52:52.179] [info] Bar configured (width: 1920, height: 36) for output: DP-2

** (waybar:4606): WARNING **: 20:52:52.179: Status Notifier Item with bus name ':1.16' and object path '/org/ayatana/NotificationItem/udiskie' is already registered

** (waybar:4606): WARNING **: 20:52:52.179: Status Notifier Item with bus name ':1.14' and object path '/org/ayatana/NotificationItem/nm_applet' is already registered

** (waybar:4606): WARNING **: 20:52:52.458: Status Notifier Item with bus name ':1.16' and object path '/org/ayatana/NotificationItem/udiskie' is already registered

** (waybar:4606): WARNING **: 20:52:52.458: Status Notifier Item with bus name ':1.14' and object path '/org/ayatana/NotificationItem/nm_applet' is already registered
^C[2024-05-02 20:52:53.539] [info] Quitting.

Inspection of $XDG_RUNTIME_DIR/hypr/$HYPRLAND_INSTANCE_SIGNATURE/ shows that .socket.sock does not exist:
~ ❯ ll $XDG_RUNTIME_DIR/hypr/$HYPRLAND_INSTANCE_SIGNATURE
.rw-r--r--   15 flippette  2 May 20:45  hyprland.lock
.rw-r--r-- 3.0k flippette  2 May 20:45  hyprland.log

How to reproduce
This is the relevant section of my Waybar config:
{
  "modules-left": [
    "hyprland/workspaces",
    "hyprland/window"
  ]
}

Here are the package versions I'm using (pacman -Qi <pkg>):

waybar: 0.10.2-1
hyprland-git: 0.39.1.r124.56de72f3-1 (from Chaotic AUR)

Crash reports, logs, images, videos
No response

Duplicate of https://github.com/hyprwm/Hyprland/issues/5825. Use waybar-git until a new release is made.


New version: CavityTools v1.2.1

Registering package: CavityTools
Repository: https://github.com/abraunst/CavityTools.jl
Created by: @abraunst
Version: v1.2.1
Commit: 371eaffb8e7b2741045f7fd9026c02d66927aebc
Reviewed by: @abraunst
Reference: https://github.com/abraunst/CavityTools.jl/issues/1#issuecomment-2145031083
Release notes:

This release

- Makes the interface of `ExponentialQueue` match the one of `ExponentialQueueDict`
- Allow arbitrary collections and iterators as arguments to the ctors
- Match the API of `AbstractExponentialQueue{T}` math the one of `AbstractDict{T,Float64}`

stop, I'll include one more nonessential change


Ability to add listeners directly to objects like Modals/Collapse/etc

How about a public method to add listener(s) to an object, something like:
class Modal {
    //...

    on(event, callback) {
        this._element.addEventListener(`${event}${EVENT_KEY}`, callback);

        return this;
    }

    //...
}

This will allows us to do something like:
var myModal = new bootstrap.Modal(document.getElementById('myModal'));

myModal
    .on('shown', function (e) {
        // do something...
    })
    .on('hidden', function (e) {
        // do something...
    });

Instead of:
var myModal = new bootstrap.Modal(document.getElementById('myModal'));

myModal._element.addEventListener('shown.bs.modal', function (e) {
    // do something...
});
myModal._element.addEventListener('hidden.bs.modal', function (e) {
    // do something...
});

Hi @arcanedev-maroc,
Thanks I think it's a good idea, it'll be easier to listen to our events 👍
Any other thoughts @twbs/js-review ?

I think this would make a prudent addition.

PRs welcome, but the sooner the better before v5 hits stable :)

Hi @XhmikosR, i've created a PR: #32184

I would love if that supported chaining. E.g.
new Modal(element)
    .on('shown.bs.modal', e => {  })
    .show()

I would love if that supported chaining. E.g.
let modal = new Modal(element)
    .on('shown', e => {  })
    .show()

From looking at the unit tests it supports chaining.


EDU-1067 Improve resource selector

Closes https://educandu.atlassian.net/browse/EDU-1067

Works very nicely :+1:


feat(api-v2): Control JSON-LD nesting via an HTTP header (DSP-1084)

[x] Optionally build a flat JsonLDDocument when converting from an RdfModel.
[x] Optionally flatten an existing JsonLDDocument.
[x] Choose hierarchical or flat JSON-LD via an HTTP header.
[x] Add docs.

resolves DSP-1084.

Thanks for the review!


GROOVY-9373 (part 1): rework line numbers for statements

https://issues.apache.org/jira/browse/GROOVY-9373
https://issues.apache.org/jira/browse/GROOVY-9199
https://issues.apache.org/jira/browse/GROOVY-9126
https://issues.apache.org/jira/browse/GROOVY-7647
"do" and "try" should not generate line numbers
instructions after last source line are tied to closing brace
instructions before first source line are tied to opening brace
Writing two LINENUMBER instructions in a row is an issue.  Given this sequence from groovy.log.classgen system property:
L1
  LINENUMBER 7 L1
L2
  LINENUMBER 8 L2

If user sets breakpoint on line 8 of source, debugger will not stop because it associates line 7 with whatever instructions come next.  One example of this is try { on line 7 and some statement on line 8 (see GROOVY-9199).

Merged. Thanks!


remove leader election option for Lifecycle Manager

The kubebuilder default scaffold providing LeaderElection option as a feature flag which by default disabled.
However for our Lifecycle Manager project, we need to ensure that LeaderElection is always enabled. This is because our controller logic requires a single leader instance to manage the lifecycle of the resources and prevent conflicts or inconsistencies. Therefore, we need to modify the configuration yaml files to remove the --leader-elect flag and hardcode the LeaderElection option to true. This way, we can avoid potential side effects or errors caused by user misconfiguration or multiple leader instances.
AC:

[x] LeaderElection should by default enabled in Lifecycle Manager and not be configurable
[x] --leader-elect args should cleanup in config yaml

Upon starting with the issue the following problems were encountered:

Changed the leader election flag to true → led to name space error
Added namespace option and hardcoded it to kcp-system → the operator complains about namespace not found
➡ This is because of a potential race condition because during the initialisation of the LifecycleManager the kcp-system namespace does eventually get created, but only after the leader election takes place. Hence it never finds it in the first place.
Adding the code/command for the manual creation of this namespace → more problems as it is an anti-pattern and caused more cleanup issues.

After a detailed discussion with @ruanxin we came to the conclusion that this issue can be closed, as implementing it brings more overhead than benefits.


Should bitfields types be unsigned integers instead of signed integers?

Tested versions
Pop OS 22.04: Godot Engine v4.3.dev.mono.custom_build.bbb3531fa
Windows 10: Godot Engine v4.3.dev.mono.custom_build.bbb3531fa
System information
Pop OS 22.04, Windows 10
Issue description
We found that Windows was actually treating 0xffffffff bitflags as a signed integer with a value of -1 when compared to Linux where it was treated as unsigned and assigned a value of<PHONE_NUMBER>.
This resulted in Gdext panicing when generating Godot bindings as seen in this PR for the fix over here: https://github.com/godot-rust/gdext/pull/627
Godot currently uses signed integers when binding all of its constants including bitflags: https://github.com/godotengine/godot/blob/81f3d43cc1ba01136795fb2059bbaa55bc514a16/core/object/class_db.cpp#L949
So we are seeking further information and discussion around the data type that Godot should enforce for bitflags.  Should it stay with the currently signed value?  Are there instances where negative values make sense for bitflags?  Is there a reason Steam's sdk evaluates to this negative value on Windows and is this expected behavior?  If Godot changed to unsigned, would it still be compatible with Steam?
I don't expect all of these questions to necessarily be answered by the Godot team, but I wanted to get the discussion started while we also change the datatype on the gdext side to match Godot's datatype.
Here are the current issues / prs for reference:
godotsteam: https://github.com/CoaguCo-Industries/GodotSteam/issues/424
gdext: https://github.com/godot-rust/gdext/pull/627
Steps to reproduce
Build godotsteam from here: https://github.com/CoaguCo-Industries/GodotSteam/tree/godot4.
Evaluate the bitflags as describe here: https://github.com/CoaguCo-Industries/GodotSteam/issues/424
See that the constant on Linux is<PHONE_NUMBER>

And the constant on Windows is -1

Minimal reproduction project (MRP)
https://github.com/CoaguCo-Industries/GodotSteam/tree/godot4

It has come up before, see e.g. #61757 , https://github.com/godotengine/godot/pull/88424#discussion_r1493269773 .

Thanks for those!  So I guess the next discussion to be had is if we should extend that enforcement of unsigned integers to the class db level for bitflags: https://github.com/godotengine/godot/blob/81f3d43cc1ba01136795fb2059bbaa55bc514a16/core/object/class_db.cpp#L949
What impact that may have on sdks like Steam?  Will it be compatible still and / or is there an expected reason it is negative on Windows?

To bring this to a discussion about concrete actionables -- we currently have this in the GDExtension C header:
typedef int64_t GDExtensionInt;

typedef void (*GDExtensionInterfaceClassdbRegisterExtensionClassIntegerConstant)(
    GDExtensionClassLibraryPtr p_library,
    GDExtensionConstStringNamePtr p_class_name,
    GDExtensionConstStringNamePtr p_enum_name,
    GDExtensionConstStringNamePtr p_constant_name,
    GDExtensionInt p_constant_value,
    GDExtensionBool p_is_bitfield
);

The signed int64_t is causing some confusion. From the PRs linked by @lawnjelly, it seems like there's a tendency to move towards unsigned numbers for bitfields, at least in the implementation.

I see two options:
1. Add a new C function with the correct type
// only for bitfields, not enums
typedef void (*GDExtensionInterfaceClassdbRegisterExtensionClassBitfieldConstant)(
    GDExtensionClassLibraryPtr p_library,
    GDExtensionConstStringNamePtr p_class_name,
    GDExtensionConstStringNamePtr p_enum_name,
    GDExtensionConstStringNamePtr p_constant_name,
    uint64_t p_constant_value, // now unsigned
    // no p_is_bitfield value
);

We can either keep the old ClassdbRegisterExtensionClassIntegerConstant method.
Or deprecate it and add a ClassdbRegisterExtensionClassEnumConstant one without p_is_bitfield parameter.
2. Keep signature, improve docs
If you think moving away from the existing signature is too much of a change, we could go for this approach.
Clearly specify that p_constant_value, albeit signed, is interpreted as unsigned if p_is_bitfield is set to true.
Encourage bindings to use uint64_t to represent that type on their side.

Do you have any idea the extent of the impact a change like this could have, @Bromeon?
At least at my day job, we typically err on the side of a combination of both of these, starting with (2) and at some point introducing the new API in conjunction with the deprecation of the old toward the EoL of the current major just before moving to the next major when there is a large impact.

The existing API would keep working; GDExtension generally provides backwards compatibility down to Godot 4.1. So no one would be forced to update.
Migration would likely be quite straightforward, too: since the underlying value is only a bit pattern and has no numeric meaning, one can simply use uint64_t instead of int64_t when registering a constant (or cast when necessary, although I don't see why a bitfield should be signed in the first place).

I'm in favor the new API. I've seen a few libraries that use -1 as shorthand for "all flags on." It's very convenient, but you can run into trouble when casting from a smaller unsigned integer to a larger signed one because -1 is a different set of bits depending on your integer size. Enums that have bitfields (e.g., Steamworks API) are extra fun because the default type for enums can depend on the compiler (see #61757). Unsigned bitfields prevent this.
For the new API, I have a few questions:

Would the new C function be called via a new ClassDB method `bind_bitfield_constant``?
Binding unsigned integers are useful even outside of bitfields (e.g., IDs). Is there any chance this could be a generic bind_unsigned_integer_constant API? It out of the scope of this issue, but I wanted to bring it up now because I can see people misusing the new bitfield API for that purpose. I'd do that.

Discussed at the GDExtension, and we decided to:

Document that for bitfields, the constant value should be treated as a uint64_t, and recommend that GDExtension bindings attempt to warn developers who use a signed value as the source of a bitfield constant (which the GDExtension interface can't check, because it takes a int64_t anyway). @Bromeon is going to make a PR to add this note to the documentation for classdb_register_extension_class_integer_constant in gdextension_interface.h
Change the BIND_BITFIELD_FLAG() macro in godot-cpp to expect a uint64_t value so that developers get a compiler warning if they use an int64_t. @dsnopek can work on this change


Setting Target Heat, then drops back

Describe the bug
I have the S30 with the zoning panel which has 2 zones (Upstairs, and Downstairs).  During heating season, sometimes I noticed when I try to increase the target temperature, it doesn't set.  It looks like the temperature is changing and then it drops back.
I made a video showing the behavior (only happens on "Upstairs" zone).
https://github.com/PeteRager/lennoxs30/assets/375080/cf6c4f42-6c6a-4bc7-b931-b89744d45b6f
Same affect using the built in Thermostat card:
https://github.com/PeteRager/lennoxs30/assets/375080/568b1ca4-6150-44d7-9534-53ffcc736520
I do have a dual fuel setup.  Heat Pump and 2-Stage Furnace.  In this case its set to Heat Pump only.
If I go into the official Lennox App, and change the temperatures (say to 63f), then Home Assistant updates, and I cant go above that temperature:
https://github.com/PeteRager/lennoxs30/assets/375080/acb2f080-f85c-4719-9eff-57bd195eee5a
To Reproduce
Randomly this occurs.  Havent found any kind of pattern.  But only happens with HEAT.  Cant recall if "Downstairs" zone is ever affected.
Expected behavior
Changes target temp to whatever I set.
Screenshots/Logs
Here is my setup:

Version

Home Assistant: 2023.11.2 - But this has happened for a long time.
This Integration:  2023.10.1 - But this has happened for a long time.

**Integration Configuration **

Cloud or Local Connection:  Local
Inverter or Sensor Diagnostics Enabled:  Disable

Additional context

That doesn't look right and it's strange that it works sometimes and not others.
Any errors in the log file?
Let's enable message logging, reload the integration and run it until you get a setpoint sequence that doesn't take and let me know what the high number was.  Then we can look in the logs and verify if the message is being sent and see how the S30 responds.
Instructions are here in the second section.
https://github.com/PeteRager/lennoxs30#reporting-bugs

I believe what is happening is the error causes HASS to unload the integration.  However, the start_client task is still in the process of setting up and becomes disconnected which causes an unhandled exception to be thrown. So I believe we just need to catch that exception in the start_client task so the integration unloads successfully.
However, I don't think that completely solves the problem as the root cause are values that the integration believes to be invalid.

I'll get you a log dump tonight

Just tried and its working now unfortunately.  Next time it shows up I'll enable logging and reload the integration.

Since it does work, the issue is intermittent and likely caused by some other factor.

Communication Failure.  WIFI connection is going down and up. If this was happening, I'd expect to see errors in the log and error counts reported in the lennoxs30.state entity.
Speed of setpoints. Perhaps when rapidly changing setpoints some of them get dropped by the controller. This we could test by running a script that sets it quickly to different values - like 60,61,62,...70.  The script should be able to set it a lot faster than pushing the UI button
Schedule. If you are running a schedule, the process of doing the setpoint changes.  First, the integration needs to create a schedule override, then do the setpoint.  So it's possible there's a problem in this logic.
The setpoint is never getting sent.  Message log would show this, as would the send_count of the lennoxs30.state object.

Finally had this happen again.  This time it was the downstairs zone (between 450 PM and 500 PM).  Was trying to set the HVAC above 69 but it kept jumping down.
s30error.txt

According to the log the system mode for the zone is off.  Typically this is set to "Heat" or "Cool".   When it is off the integration cannot perform a setpoint because it does not know which limit is being set - the cool setpoint or the heat set point.
Looking at the code I would expect an error to be logged by the integration.  Is this happening?
Is your system in single setpoint mode - which means there is one setpoint that is used for both heat and cool?  If so, there I may need to trace this branch of the integration to verify it is generating an error.
I do believe the underlying cause is the zone is set to off.

So just to add on.  I have experienced this exact same bug.
I can change the temp on the thermostat itself, but if I adjust within HASS then it will jump back to the current set temp.

Sorry I forgot to reply.  No I only have my unit in either heat or cool mode.  I never have it in heat and cool mode.

@dresslerc the HVAC mode was set to off on all zones.  We can see that in the log file.
  "systemMode": "off"

There was no entry in the log that shows is was in "heat" mode or "cool" mode.

@chris-mosley
please enable message logging and then post a copy of the message log when the problem occurs as well as the time the problem occurs.  Please check the log also for warning messages.

When this happens also try to refresh the HA UI or reload the App.  I have seen the UI get in a funky state where commands and state updates become erratic.

Stale

I'm still experiencing this same issue about once a week and was subscribed to this issue in the hope of an eventual resolution.
Reloading the UI does not help and when it fails on one device it also fails the same on all devices (Android, MacOS, Web).
Sometimes it will let you reduce the temperature target but not increase it over a specific degree.
Sometimes it works in AC mode but not in heat mode.
Sometimes it unblocks after 5-10 minutes of fiddling back and forth.
Sometimes it just works the next day.
Lennox's iComfort continues to work fine when HA fails.
I'm enabling debug logging in my Lennox integration.
Is there anything I/we can do to help investigate this?

This only happens to me in Heat mode.  Never in Cool mode.
Didn't happen very often this winter.  Maybe 2-3 times.

We need to capture a message log when it happens.  This will show the messages getting sent (e.g. setpoints) and the responses coming back.

Sometimes it will let you reduce the temperature target but not increase it over a specific degree.

Not sure I understand this.  What would be an example?

Reloading the UI does not help and when it fails on one device it also fails the same on all devices (Android, MacOS, Web).

That's good to know

Sometimes it unblocks after 5-10 minutes of fiddling back and forth.
Sometimes it just works the next day.

By unblock, you mean eventually it will take the setpoint?

Sometimes it will let you reduce the temperature target but not increase it over a specific degree.

Not sure I understand this. What would be an example?

Let's say I'm in Heat mode at 19C. I try to increase so 19.5C but it snaps back to 19C within 5 seconds.
I can reduce the temperature to 18.5 or 18 and it will work, the desired target gets programmed properly and doesn't snap back.
I can go up again to 19C.
If I try again to go to 19.5C, no dice, it still snaps back.

Reloading the UI does not help and when it fails on one device it also fails the same on all devices (Android, MacOS, Web).

That's good to know

Yeah, it probably eliminates local UI issues.

Sometimes it unblocks after 5-10 minutes of fiddling back and forth.
Sometimes it just works the next day.

By unblock, you mean eventually it will take the setpoint?

Correct: Sometimes it accepts the setpoint after 5-10 minutes of fiddling back and forth.
Thanks for taking the time to look into this again!
Cheers.

This only happens to me in Heat mode. Never in Cool mode.
Didn't happen very often this winter. Maybe 2-3 times.

Too bad you're still seeing the issue. I'm confident we'll get to the bottom of this.
I'm not 100% sure I've seen it in Cool mode myself. I think I remember my wife saying so but we're not certain.
Last time it was definitely in Heat mode. I tried to switch to Cool mode and it was working fine, went back to Heat mode and the same issue could be experienced again.

Sorry I've been out of pocket here.  my area got warm and so i stopped seeing the issue as I wasn't in heating mode as often.  But the issue is very much still there.
One thing I'm not sure i mentioned or if anyone else did. Is that I do have mine set to diagnostic level 2 so that I can log all those stats.  I know the OP stated theirs was not but idk.  More info more better.

I reviewed the code this morning.  There are several different operating modes, and it would be good to understand what modes you are running in to see if it's a problem related to a specific mode.
a) Fahrenheit vs Celsius
b) Single Setpoint Mode (when in heat/cool there is only one setpoint)
c) Running using schedules on the panel
Also it'd be helpful to have at least "info" level debugging turned on, in addition to message logging.
logger:
  default: warning
  logs:
    custom_components.lennoxs30: info
    lennoxs30api: info

a) Fahrenheit vs Celsius

Celsius

b) Single Setpoint Mode (when in heat/cool there is only one setpoint)

Single Setpoint Mode

c) Running using schedules on the panel

No schedules configured.

Also it'd be helpful to have at least "info" level debugging turned on, in addition to message logging.

Yes. I turned on "debug" level, as per Reporting Bugs

One thing I'm not sure i mentioned or if anyone else did. Is that I do have mine set to diagnostic level 2 so that I can log all those stats. I know the OP stated theirs was not but idk. More info more better.

@chris-mosley, where is this "diagnostic level 2" configured?

@jstrot I don't think I've seen it in cooling mode.

OK, thanks for confirming.

Something else that might be relevant is I have a heatpump with dual fuel. So maybe there's some addtional complication there?

For comparison, my system has only a gas furnace + A/C. No heatpump.

@chris-mosley, where is this "diagnostic level 2" configured?

I found it: After enabling "Diagnostic sensors" in the HA integration configuration and reloading, I now see a new "System_diagnostic_level" sensor and set it to 2.
Thanks.

I reviewed the code this morning. There are several different operating modes, and it would be good to understand what modes you are running in to see if it's a problem related to a specific mode.
a) Fahrenheit vs Celsius b) Single Setpoint Mode (when in heat/cool there is only one setpoint) c) Running using schedules on the panel
Also it'd be helpful to have at least "info" level debugging turned on, in addition to message logging.
logger:
  default: warning
  logs:
    custom_components.lennoxs30: info
    lennoxs30api: info

Getting it to happen with the info and message logging turned on is what we need to diagnose.

a) Fehrenheit
b) Single setpoint
c) no schedules
additionally I do have one other modification I just remembered. I have it set to not do half degrees.
Before if I hit the up arrow on the app/webui it would go 70 -> 70.5 -> 71.
As far as I know it doesn't actually support half degrees in F.  So mine the step is set to a full degree per tap.

OK so while I was writing the last comment I decided to test it out.  And I remembered one more behavior I don't know if anyone else had mentioned.  It seems like its always when i go above some temperature.  It was 71, I could modify the set temp to my hearts content as long as it was under 71.  over 71 gets pulled back.  but then I restarted the container and the new number was 69.
I enabled debug logging but I don't see anything obvious in it.
2024-05-06 00:04:51.947 DEBUG (MainThread) [custom_components.lennoxs30] messagePump host [lennox-s30.th.local] running
2024-05-06 00:04:53.979 DEBUG (MainThread) [custom_components.lennoxs30] messagePump host [lennox-s30.th.local] running
2024-05-06 00:04:53.988 DEBUG (MainThread) [custom_components.lennoxs30] messagePump host [lennox-s30.th.local] running```

Is there a particular line I should be looking for?  I've got all the sensor data mixed in there too

The panel has a maximum heat setpoint that is configured for it, which should be captured in the max_temp attribute of the climate entity. If the setpoint gets sent to the integration there will be a message logged. Try with a lower setpoint like 65 and see if this message gets logged.  That way we will know the logger config is working properly.   If you see it for 65 and not for 71, that would indicate the setpoint is being filtered out / lost somewhere in HA.
        _LOGGER.info(
            "climate:async_set_temperature zone [%s] hvacMode [%s] temperature [%s] temp_high [%s] temp_low [%s]",
            self._myname,
            r_hvacMode,
            r_temperature,
            r_csp,
            r_hsp,
        )


Use OnceCell to cache decoded CID links

We're thinking of a data structure that may look like this:
enum Link<T> {
    Clean {
        cid: Cid,
        cache: OnceCell<Box<T>>,
    },
    Dirty(Box<T>),
}

There may be issues using a OnceCell, we need to figure it out!
Also, to Box or not to Box (or Rc?) TBD.

The current design of this is:
pub enum Link<T> {
    /// Invariant: the (optional) contents of the cache *must* encode the cid
    Encoded {
        cid: Cid,
        value_cache: OnceCell<T>,
    },
    /// Invariant: the (optional) cid of the cache *must* be the cid of the encoded value
    Decoded {
        value: T,
        cid_cache: OnceCell<Cid>,
    },
}


Multi select activities

Overview
This PR includes the following proposed change(s):

https://github.com/bcgov/invasivesbc/issues/317

I so far have not opted to follow the "Should always be able to see which records I've selected (i.e. should float to the top)" directive from the ticket - as that's a bit of a pain, and I'm not especially convinced it's a good user experience.  For now just including a count of the number selected in the button, and I'd suggest maybe putting that selected list on the bulk edits page itself in another PR if that's a big concern still.  Can add that in a follow-up PR though, whichever UX choice we make.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Refactoring / Documentation
[ ] Version change

if your change is a breaking change, please add breaking change label to this PR
How Has This Been Tested?
Locally
Screenshots

Unsupported records have no checkbox (disabled and hidden) while maintaining a margin:

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have made corresponding changes to the documentation
[X] New and existing unit tests pass locally with my changes

also I see these which should be fixed prior to merge: https://sonarcloud.io/project/issues?id=bcgov_invasivesbc&pullRequest=455&resolved=false&types=CODE_SMELL

also I see these which should be fixed prior to merge: https://sonarcloud.io/project/issues?id=bcgov_invasivesbc&pullRequest=455&resolved=false&types=CODE_SMELL

@dogcomplex what do you think of adding a column for the checkbox instead of adding it to the existing icon column?

@dogcomplex what do you think of adding a column for the checkbox instead of adding it to the existing icon column?

@dogcomplex what do you think of adding a column for the checkbox instead of adding it to the existing icon column?

Sure? whatever, really.  Could change the icon to have a little checkmark in the corner too.  I'm assuming the current look is likely to be scrapped in the longterm, so wouldn't spend too much time perfecting it right now.  If I'm going to that effort, I'd consolidate the whole thing with the IAPP tables and make a universal grid table component too.  So - not gonna bother stuffing it into this PR.

@dogcomplex what do you think of adding a column for the checkbox instead of adding it to the existing icon column?

Sure? whatever, really.  Could change the icon to have a little checkmark in the corner too.  I'm assuming the current look is likely to be scrapped in the longterm, so wouldn't spend too much time perfecting it right now.  If I'm going to that effort, I'd consolidate the whole thing with the IAPP tables and make a universal grid table component too.  So - not gonna bother stuffing it into this PR.


Is LTI necessary ?

Is setting up LTI mandatory to run the server on local or otherwise, if yes how can I set it up.

This is only required if you plan to integrate it with an LMS like Moodle.


PR: Add setuptools setup file, add command to compile CUDA/C libraries and general package file refactoring

Thanks for your great work and effort in porting Detectron to PyTorch!
This PR adds a compatible setuptools distributable setup file, this addition allows other reseachers/developers to embed Detectron in their applications without having to modify the PYTHON_PATH environment variable, instead, they just have to import the library using import detectron_pytorch.
It also adds a magic command to execute the make.sh script by invoking python setup.py build_static. Finally, it presents a new package structure.
I'm pending of any requests or additions this PR should have.

For instance, the main Detectron package has done the refactoring as well: https://github.com/facebookresearch/Detectron/issues/414


Don't rethrow exceptions in mapParUnordered

Changes the error handling in mapParUnordered so that errors from upstream channel or from the mapping function are not rethrown, but only signalled to the downstream channel and used to terminate further processing.
When the mapping function fails with an error, any already in-flight forks are allowed to complete, but their results are not sent downstream, since the downstream channel is closed immediately by the fork in error.
When the receive() from upstream fails, the downstream channel is closed and the internal loop terminates, so that no new forks are started.
Also adds Source.failed(Throwable) which was needed for one of the tests, so I decided not to put it in a separate PR.

Great, thanks! :)
As a follow-up, can we do two things:

review existing operators if they don't throw exceptions in case of errors, but instead propagate them
update the channel error handling section of the readme to accurately describe our approach?


The bot doesn't know that ProductCode changes in a new MSI.

It appears that the bot doesn't change the ProductCode when it automatically updates a MSI manifest. I've fixed two of these (#12159, #12164), but it'd be a real pain to do for every single one. Is there any way the bot can start to do it itself? The product code is available in the MSI's database (which I assume is where it grabs the new version number anyway).

This has been resolved.


add support for extra arguments to CF client

For example --skip-ssl-validation .

Hi Ricardo,
Thanks for the hi quality PR (tested etc.)! Do you not require additional args for all cf commands? Or just for the login command? At the moment it appears you're only adding them to the cf login.
Thanks,
Luke

Hi Luke,
For my current use case, I only want extra args on cf login, but I can add to other CF commands on separate PRs.
Thank you.
Ricardo

old PR, closing


Relative and absolute reference inconsistency inside the evaluate formula feature

Describe the bug
This may not necessarily be a bug, although, it is inconsistent, and that inconsistency is highly annoying and unintuitive.
When referring to an absolute value using the comments below the table for automatically determining a value of a given column, the absolute references ignores the second row (the one which does not contain any cells which actually shows up inside the reading render of the table). In contrast, the relative reference does not ignore the row which does not appear inside the rendering of the table.
For this table here are the absolute references listed:

@1$1
@1$2
@1$3

@2$1
@2$2
@2$2

@3$1
@3$2
@3$2

@4$1
@4$2
@4$2

| @1$1 | @1$2 | @1$3 |
| ---- | ---- | ---- |
| @2$1 | @2$2 | @2$2 |
| @3$1 | @3$2 | @3$2 |
| @4$1 | @4$2 | @4$2 |

In comparison, this is the relative references listed for the absolute cell: @3$2:

@-3$+1
@-3
@-3$+1

@-1$-1
@-1
@-1$+1

$-1
@3$2
$+1

@+1$-1
@+1
@+1$+1

| @-3$+1 | @-3  | @-3$+1 |
| ------ | ---- | ------ |
| @-1$-1 | @-1  | @-1$+1 |
| $-1    | @3$2 | $+1    |
| @+1$-1 | @+1  | @+1$+1 |

Again, this may not be a bug in itself, although, I feel like somebody got to report the inconsistency
To Reproduce
Here is a example of how to reproduce the issue:
Insert the following table into the text file:
| 1   | 2   | 3   |
| --- | --- | --- |
| 4   | 5   | 6   |
| 7   | 15  | 11  |
| 8   | 9   | 10  |
<!-- TBLFM: @3$2=@-2 -->

Evaluate the formula using Advanced tables Obsidian "evaluate formula" feature.
Expected behavior
What occurs is the "15" addressed as "@3$2" becomes a "---", what I would expect is for the cell "@3$2" to become a "2"; if you assume that the relative measurement should be adjusted after the absolute ones that is. Either way, to be clear:
The behavior
| 1   | 2   | 3   |
| --- | --- | --- |
| 4   | 5   | 6   |
| 7   | --- | 11  |
| 8   | 9   | 10  |
<!-- TBLFM: @3$2=@-2 -->

The desired behavior:
| 1   | 2   | 3   |
| --- | --- | --- |
| 4   | 5   | 6   |
| 7   | 2 | 11  |
| 8   | 9   | 10  |
<!-- TBLFM: @3$2=@-2 -->

Desktop:

Windows 10
Obsidian Version: v1.3.5
Advanced Tables Version: 0.18.1

Additional notes
I might have made some mistake inside the table example of all the absolute and relative references, since I just observed the pattern and filled in the rest, but the steps to reproduce the bug should be right.

Thanks for the bug report on this. I agree that this is inconsistent and definitely not desirable. Unfortunately at this point fixing it would be a major breaking change, so I think I had to leave it as is. Maybe (hopefully) some day if there is a need for other breaking changes this can be fixed.

Yeah, sounds highly reasonable, since changing what the references point to, might ruin some older uses of the references. Besides, it is easy to work with with the inconsistency anyways, once you get used to it. I would not expect any change anytime soon; instead, it was at the time of writing, mostly just done to bring awareness to the issue, and maybe something happens a few years later, maybe.


Rate Limit exceeded

Hello,
GitHub has a rate limit in place for API requests. When I do rpi-update it says I have hit this limit.
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7635  100  7635    0     0  20220      0 --:--:-- --:--:-- --:--:-- 26058
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** No hash received from github: https://api.github.com/repos/Hexxeh/rpi-firmware/git/refs/heads/master
{
  "message": "API rate limit exceeded for X.X.X.X. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
  "documentation_url": "https://developer.github.com/v3/#rate-limiting"
}

I'm getting slammed by this as well. I have 60+ RasPis here and trying to run rpi-update just exploded everything. I wish there was a way to pass in a user token as @Jamesking56 suggested.

Feel free to create a pull request to support a personal access token.

Why was this closed? I just ran into this issue.

@fenhl I think @Jamesking56 closed it with a #donthavetimebutknockyourselfout and that's completely within his right. Supporting a project like this is often thankless. Please do investigate, as they say!
What I ended up doing was a combination of hosting my own update blobs on Dropbox and reconsidering my approach to deploying a fix in general.
First, you probably don't randomly need to update your Pis unless you need a device that isn't currently supported by an older version of Linux. It's definitely not something to do without consideration.
However, the main change I made is that I adopted a process that is roughly:

Update a script that I verify can build a brand new Pi image from scratch
Run the script and put the image on a 4GB card
Use a duplicator to copy to 15 8GB cards

We used to use a nasty assortment of USB readers to do duplication. This is a reasonable strategy until it isn't. Yes, duplicators seem expensive but if your time is worth >$100/hour then they pay for themselves VERY quickly. YMMV.
Why do I copy to 8GB cards you must be wondering? Well, every batch of SD cards has a slightly different number of bytes available for writing - sometimes it's 10's of bytes, often it's 10-15MB. The price of a 8GB compared to a 4GB card is negligible so I'm fine with paying pennies extra for a 100% guarantee that the 8GB won't fill up before it's finished writing an image.

I'm not sure I understand what you're talking about. I was simply following a tutorial (for installing info-beamer-pi) which instructed me to run rpi-update.

Fair enough. Just recognize that you're also someone who hasn't contributed to the project showing up to a long-dead thread upset that GitHub is rate limiting you.
You really shouldn't be having this problem unless you're hammering GitHub. How many Pis are you trying to update at once?

I'm not upset, was just trying to figure out what's going on. And I'm just working with a single Pi.
Apparently the issue was caused by a BitBar plugin which pulls GitHub notifications every 30 seconds, which was running on a different computer in the same LAN. Even though this plugin was using an access token to authenticate to the GitHub API, temporarily disabling it and waiting until the rate limit state reset allowed me to run rpi-update without any issues.

I closed the issue because after waiting 24 hours it never came back for me. I am only using 1 pi so I rarely hit the rate limit.

I think this can be closed.
Github has API rate limits which are far higher than you would hit from normal use of rpi-update.
If you are making a large numbers of git API calls for other uses or and running rpi-update very frequently then you will have to slow down until github is happy with your usage.

@Jamesking56 can this issue be closed?

Ask @fenhl they wanted it to be reopened.

I don't think the issue is fixed until a personal access token can be provided.

I agree, it should be possible to provide an access token. The change required should be trivial. If no one else will do it, I can.

@darkwinternight Feel free to submit a pull request that allows an access token to be specified.

@popcornmix I created a pull request for this: https://github.com/Hexxeh/rpi-update/pull/237

Actually, just as a follow-up information, I hit the rate limit at work constantly since we work with GitHub a lot (web development).


Dual-licensed under MIT

Hi,
i would ask if it possible is to dual-licence the library under MIT and Apache license (or only MIT-License)?
The reason is the possibility to relicensing the code unter other free licenses. From the MIT licence you can relicensing the code to modified BSD, Apache, LGPL, GPL and AGPL. From the apache license you can relicensing the code only to LGPL 3, GPL3 and AGPL 3.
Sincery,
Florian

I'll look into this.

@seeseekey are you talking about using the Grapevine package (e.g. from NuGet) as a dependency for another project/product that would be licenced differently, or using the Grapevine source code to make a derivative work that would potentially have a different licence? I'm trying to figure out how the Apache license would inhibit either of these scenarios.


Causes of the error "RuntimeError: cannot call recv while another coroutine is already waiting for the next message"?

I know, it's in the message. Another coroutine is currently waiting for a message on the same websocket.
The thing is, I never do that. To init I recieve data, send data, then receive again. Then I go into a loop: Receive data, do stuff with it, maybe send data back. Other coroutines do send data down the wire, but they definitely don't do any receiving because there's only 3 instances of websocket.recv() in the entire program. What else could be causing this error? Is there a way to see what coroutine that is?
Edit:
So if I add a asyncio.sleep() to that main loop it stops with 2 clients (it always worked with 1), but going higher breaks it again.
Edit 2: This only seems to happen if I send a message after a receive.
 I still don't entirely understand what went wrong, but it was my fault, not yours. Sorry for wasting your time.

No worries - concurrent programming is hard. Guess how I know ;-)


Update files copied from eth-account to support nested array types

fixes: #6

@fabuloubu No worries :) Appreciate the review! I saw that linting and mypy were failing so have run black and rebased. Could you approve the workflows again? That should address the failing jobs.

@fabuloubu No worries :) Appreciate the review! I saw that linting and mypy were failing so have run black and rebased. Could you approve the workflows again? That should address the failing jobs.

For sure! This looks great, I'm going to try to look more into updating this package so I appreciate the updates
Was there anything else you wanted to do to take it out of Draft?

@cedric-cordenier also checking out the backlog of issues, do you think that this fix resolves https://github.com/ApeWorX/eip712/issues/6? It seems like it does to me, but was hoping to get another opinion.

@fubuloubu Nope, that should be all we need to take it out of draft, although isort was failing so I ran that too.
Yep, this should fix #6 while we're at it too.


config: document migration of config.toml file from v0.38.x to v1.x

As per title.
Definition of Done

[x] Find and enumerate all changes introduced in the configuration (config package)
[x] Check if running v1.x CometBFT with a standard v0.38.x configuration file works
[ ] Make sure that default (zero) values for introduced/changed configuration parameters are valid
[ ] Check whether the presence of parameters removed in v1.x in the configuration file cause problems
[ ] Document the findings of previous steps, as a guide for CometBFT operators
[ ] Stretch goal: produce a script to find inconsistencies in the configuration file

Changes in the configuration file:

db_backend: removed badgerdb (unclear, to be confirmed), added pebbledb
rpc.grpc_laddr and rpc.grpc_max_open_connections removed
New section grpc: grpc.laddr probably replaces rpc.grpc_laddr
mempool.max_batch_bytes removed, it was set to "Unused" in v0.38
consensus.peer_gossip_intraloop_sleep_duration added, although not documented in the config file
storage has new fields: experimental_db_key_layout, compact, and compaction_interval
Added subsection storage.pruning

rpc.grpc_laddr and rpc.grpc_max_open_connections removed

rpc.grpc_max_open_connections was ignored in v0.38.x. It couldn't be negative though. Running v1.x with this config entry has no effect.
rpc.grpc_laddr works in v0.38.x. Running v1.x with this config entry has no effect. But the only endpoint offered (broadcast tx commit) is not offered in v1.x.

New section grpc: grpc.laddr probably replaces rpc.grpc_laddr

When set in v1.x, grpcs.laddr indeed starts a GRPC server. But the only endpoint offered in v0.38.x (broadcast tx commit) is not offered (request is rejected with unknown service tendermint.rpc.grpc.BroadcastAPI).
rpc.grpc_max_open_connections has no replacement in v1.x.

mempool.max_batch_bytes removed, it was set to "Unused" in v0.38

This flag was already ignored in v0.38. If present in v1.x, it is ignored as well. No error is produced.

Side issue: genesis_hash is part of the storage.pruning.data_companion section in the configuration file.
But from config/config.go it is part of the StorageConfig, therefore it should be at storage section, not in a subsection.
In fact, setting this filed in the configuration file has no effect in v1.x.
This needs to be fixed.

Added subsection storage.pruning

storage.pruning.interval was introduced in v1.x. With a v0.38.x configuration file, the effect is the same as using the default value for this parameter, i.e., 10s:
I[2024-04-05|10:17:45.383] Started pruning blocks                       module=state interval=10s

storage.pruning.data_companion section was introduced in v1.x. The enabled flag has false as default. Running with a v0.38.x, which does not have this section, the effect is the same.
I suspect that the same would apply to the remaining config flags of this section.

db_backend: removed badgerdb (unclear, to be confirmed), added pebbledb

badgerdb backend is still supported in v1.x, although it was removed from the list (still present on the description).
pebbledb backend was introduced in v1.x, but it was already supported in v0.38.x, although not listed in the configuration file.
Running first a v0.38.x binary with one of these backends, then running v1.x binary using the same CometBFT home works for both DBs.

[ ]  Document the findings of previous steps, as a guide for CometBFT operators

#2723 adds to the CHANGELOG.md the missing entries for added, updated, or removed configuration parameters. This should be enough to close this issue.


Hypothes.is annotations: action menu (icon buttons) are enabled in TOC view!

Reproduce here:
https://readium.firebaseapp.com/?epub=epub_content%2Faccessible_epub_3&goto={"idref"%3A"id-id2611884"%2C"elementCfi"%3A"%2F4%2F2[introduction]%2F2%2F1%3A0"}
(open TOC, and see how it is possible to create annotations in the hierarchical list of headings)
So, is it possible to scope the annotator engine?

For some reason, annotations in Bootstrap popup modal dialogs are not enabled (e.g. the Readium "about box", or the settings dialog).
Can a similar implicit exclusion technique be used for the TOC panel?

The modal dialogs are actually affected as well: the Hypothesis callout menu (when selecting text) appears beneath the dialogs due to CSS z-index !

Related: https://github.com/readium/readium-js-viewer/issues/679


Changed incoming props not rerendering sortable list

Hello, I'm currently trying to add react-sortable-hoc to a list component and I'm running into a number of bugs when I change the incoming list of items via props. For example: if I add an item to the array, and I check the incoming props for the list, the props in the sortable component are changing (I see the new item in the list component props), but I can't get the component to re-render. I've tried shouldComponentUpdate, getDerivedStateFromProps, using PureComponent instead of Component, forceUpdate, hookifying the whole thing and setting up a useEffect for any change in props, nothing is causing a rerender and I know that the new list is getting to the component.
Is anyone else having this same problem or has anyone found a way around it?
here's how I'm setting props/state, and how I know the props are changing:
class MobileListItems extends Component {

  state = {
    items: this.props.listItems,
  }

.
.
.

  render() {

    console.log('this.props.listItems', this.props.listItems)
    console.log('this.state.items', this.state.items)

after I sort a few things, and try to add another item, this.props.listItems is incremented by 1, but no rerender no matter which method above I've tried.

Oopsie daisy! 😅  I was initializing my state wrong. Don't copy your props into state! Be better!


1.20.3a_01 not working

The process attaches and it gets the correct score count, but it doesn't notice when the crown is picked up.

(the hex of Spel2.exe got moved around a bit this update, I assume that's the cause)

True Crown Id was changed to 536 from 552
One or more of the offsets below have changed:
private const int OFFSET_NUM_ITEMS = 0X77E;        // the number of items picked up
private const int OFFSET_FIRST_ITEM_ID = 0x784;    // the first item ID in memory
private const int SIZE_ITEM_STRUCT = 0x14;         // the space between each item ID

Hi all,
Thanks for letting me know about this problem. Of course, the one time I'm confident enough to release without going through the hoops of getting the crown to test it is the time it breaks... ;)
I'll be able to have a look within the next few days, but in the meantime anyone else is welcome to submit a PR for reviewal.

Scratch that, I just released another version. Please give it a try and let me know whether it works for you.

It's working. Thanks for the fix

Awesome, glad to hear it! Good luck on your True Crown runs :)