Node client connections refused?

I've tried a few different websocket client libraries and all of them successfully connect to Beast and my own websocket server but I am presented with the 1006 error code which is unfortunately not very informative. :[
Has anyone been able to successfully connect to uWebSockets server using a node client?
I'm sorry if this is not the place to post this. I just don't know where else to ask for help.
var WebSocket = require('ws');
var ws = new WebSocket("ws://localhost:3000");

ws.on('message', function(message) {
  console.log('Received: ' + message);
});

ws.on('close', function(code) {
  console.log('Disconnected: ' + code);
});

ws.on('error', function(error) {
  console.log('Error: ' + error.code);
});

Error: ECONNREFUSED
Disconnected: 1006

I was getting the same error with my own websocket client implementation connecting to UWS server, in C++. Problem solved by just changing the client-sided encryption key. I don't know how its possible on node tho :/

ws can of course connect to and send / receive messages to uws, just like any other client


Change Security Association

I've got some devices that are included without any kind of security , and some other (same brand / model / firmware) that are included using S0 (with is better that nothing)
Is there a way to (let me say) double check again the device security feature , in order to force them communicate with the highest security possibile, without exclude and include it again ?

Try re-interviewing the device checking "reset security classes"

Unfortunately ..... already tried this multiple times with different
devices..... but it does not work.
Just to undesrstand better : are you telling me that "reset security
classes" is provided for this exact reason ?
Il Sab 28 Gen 2023, 17:38 webmogul1 @.***> ha scritto:

Try re-interviewing the device checking "reset security classes"
—
Reply to this email directly, view it on GitHub
https://github.com/zwave-js/zwave-js-ui/issues/2918#issuecomment-1407434835,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGGSROKEBHF7HF5Z4PTHFILWUVDPBANCNFSM6AAAAAAUJVCL3I
.
You are receiving this because you authored the thread.Message ID:
@.***>

If you want to change the security class, but don't want to lose the node ID, then you can: ..... omississ.....

Ok, that's exactly what I'm doing.
Thank you all for giving all the details!!!


[BUG] Root domain details page is not loading

Describe the bug
Root domain details page is not loading
Screenshots

Working as expected:


[qt] Set defaultStyles to const

This sets the method to const as it is expected to be. Please review

Thanks for spotting this!


Flag to disable helpers during compilation (#1494)

As discussed at #1494, this pull request allows you to tell CoffeeScript.compile that you don't want helpers/utilities like __hasProp to show up in the compiled output. That way, if you have a large number of modules that you're compiling for front-end deployment, you can just put the helpers in one file and eliminate them in the other. This was discussed briefly on Twitter today:
http://twitter.com/#!/ryanflorence/status/132122428913614849
http://twitter.com/#!/CoffeeScript/status/132156500364894208
http://twitter.com/#!/jashkenas/status/132161592451268608
Example:
coffee> CoffeeScript.compile 'x in arr', bare: true
'var __indexOf = Array.prototype.indexOf || function(item) {\n  for (var i = 0, l = this.length; i < l; i++) {\n    if (this[i] === item) return i;\n  }\n  return -1;\n};\n__indexOf.call(arr, x) >= 0;'
coffee> CoffeeScript.compile 'x in arr', bare: true, utilities: false
'__indexOf.call(arr, x) >= 0;'

This does not affect the coffee command. It's purely to give other compilation tools more flexibility.

I fail to see the necessity of this flag. Only the necessary helpers are included. If you're compiling multiple files, combine them first, right?

As helpers are not visible between different wrapped closures, this will simply cause all of the code within your disabled-heleprs file to break ... unless compiling all files --bare, correct?

If you're compiling multiple files, combine them first, right?

That's what I thought at first, but let's say that you're using something like Sprockets. You want to compile and concatenate a.coffee, b.js, and c.coffee in that order, with only one copy of the utility functions that a.coffee and c.coffee both require. That's a very hard thing to do at present. This flag would make it much, much easier.
Indeed, the Rails folks will probably want to make "insert global CoffeeScript utility functions if any .coffee files are in the pipeline" a default, since having several declarations of __extends and such in the application JS has become the norm.

@TrevorBurnham: How do they know

Which helpers are needed by the code
The current source of the particular helper

This feels like a half-assed approach. Either we make that information available for compilation tools like sprockets or this flag is unnecessary.

As helpers are not visible between different wrapped closures, this will simply cause all of the code within your disabled-helpers file to break ... unless compiling all files --bare, correct?

Or declare the helpers in global scope yourself. I'd suggest making a utilities.js file part of the repo, under extras. In fact, adding that to the pull request now...

Which helpers are needed by the code

Just throw them all in. You might wind up with one or two things you don't need, but that's an O(1) efficiency loss rather than O(n) with respect to the number of .coffee files. This is exactly what was requested at #1494. As @lucaswoj said when opening the issue:

I'd love to just have a single file of all CoffeeScript helpers and include that instead.

And as @rpflorence said just today,

I'd be ecstatic with nothing more than an exclude helpers flag. I can put them on the page myself.

@michaelficarra Right, that was for debugging. Removed.

I'm surprised more people don't find this needless code disturbing :\  As I mentioned before in #1494, it's impractical to expect your entire app to be transpiled at once.  All of our JS uglified and gzipped is over 1 megabyte (!), it'd be a crime to expect our users to download and execute that much JS.
Consequently, we have a script that compiles a single file from cs to js, and also watches the file system as we develop to do it seamlessly.  We then use the RequireJS optimizer to build layers of our application that are loaded when they are needed.  In a large AMD application, if you do it right, you have a lot of individual coffeescript files.
My hand-written JS is smaller than what coffeescript kicks out.  Add in the helpers (which show up in nearly every module) and now that 1 megabyte is creeping up on 1.5.  We don't need hundreds of __bind, __extend, __hasProp, etc.
Anyway, anybody using this option should have a clue, and the tool can provide feedback saying "make sure you include the helpers some how!"  I know it sounds gross, but is there really an alternative w/o making the coffeescript command-line tool a robust application packager / optimizer?

:+1: I may or may not have been begging for something like this, but I sure as hell want it. I think it would be cleaner to namespace the helpers, though, if they are going to be in the local scope. CoffeeScript.__indexOf, anyone?

@TrevorBurnham You make a good argument, although I might humbly suggest a prefix of cs$ or similar.
IIRC, the ECMAScript standard suggests that $ should be reserved for compiler-generated identifiers, so this is a reasonable application. I know jQuery breaks the rules by using $ on its own, but I haven't seen anybody using cs$ either and it would be a little more obvious that it's "ours". C:

Awesome. This would definitely help with stuff like this https://gist.github.com/1099767
Would also make it easier to leverage existing libraries, such as $.proxy instead of __bind, as all helpers would be in one place.

This is going a strange direction.  Let's keep it simple.  Add the flag, provide a file of all helpers.
On Nov 5, 2011, at 12:06 PM, Tasveer<EMAIL_ADDRESS>wrote:

Awesome. This would definitely help with stuff like this https://gist.github.com/1099767
Would also make it easier to leverage existing libraries, such as $.proxy instead of __bind, as all helpers would be in one place.

Reply to this email directly or view it on GitHub:
https://github.com/jashkenas/coffee-script/pull/1820#issuecomment-2641610

@rpflorence Duh. Maybe I wasn't clear enough.
I was commenting on the added benefit of being able to modify that single file of all helpers to further benefit my app's requirements.
Instead of this in all of my files, for example:
some_func = $.proxy(->
  # ...
, @)

I can use:
some_func = =>
  # ...

And overwrite my utilities.js to do the $.proxy behind the scenes. If you look at my gist, it would be useful to overwrite __extends as well to use Underscore's extend, and so on. Once again, all for my single application in just my utilities.js file that is provided by CoffeeScript.
Anywho, that's my 2 cents. Keep up the good work guys.

I believe @rpflorence was referring to the namespacing suggestion.
On Nov 5, 2011, at 3:13 PM, Tasveer<EMAIL_ADDRESS>wrote:

@rpflorence Duh. Maybe I wasn't clear enough.
I was commenting on the added benefit of being able to modify that single file of all helpers to further benefit my app's requirements.
Instead of this in all of my files, for example:
some_func = $.proxy(->
# ...
, @)
I can use:
some_func = =>
# ...
And overwrite my utilities.js to do the $.proxy behind the scenes. If you look at my gist, it would be useful to overwrite __extends as well to use Underscore's extend, and so on. Once again, all for my single application in just my utilities.js file that is provided by CoffeeScript.
Anywho, that's my 2 cents. Keep up the good work guys.

Reply to this email directly or view it on GitHub:
https://github.com/jashkenas/coffee-script/pull/1820#issuecomment-2641920

@TrevorBurnham @rpflorence Ah. Seems we could've all been a bit clearer :P I was referring to $ as jQuery. I've had no conflicts with __ thus far, and would prefer to keep it simple and leave it the way it is.

+1 this pull request as is. I can't believe how fast the second half of this discussion went completely off course.

Yeah, :+1: as is. I think derailing the discussion was my fault. C:

:+1: to this!

:+1:

This would be a great option : )

I'm afraid that I'm not entirely comfortable with this -- but we can continue to discuss it.
Helpers are the exception to our "no special functions" rule in CoffeeScript. If we're at a point where we need to have a flag to suppress and re-add them separately, perhaps it means that we've gone too far with them in the first place and that they need to be scaled back.

There are only 4 helpers right now: __extends, __bind (still used for class prototype methods), __indexOf, and __hasProp, and __slice. Those last two are the obvious candidates for scaling back, since
obj.hasOwnProperty(prop)

is a fine alternative to
__hasProp.call(obj, prop)

and likewise with __slice (though I'm not even sure if __slice is being used; arr[x..y] compiles to arr.slice(x, y)...).
__indexOf is a harder case because it makes val in arr IE6/7-compatible without requiring an additional shim. But most people deploying to IE6/7 are probably using a shim anyway; as long as we documented this requirement, it probably wouldn't be a problem.
Here's the problem: The only reason #1494 and this pull request exist is because of concerns over minified code size. And removing __hasProp and __indexOf would probably hurt that cause more than it would help—after minification, any file that uses those helpers a couple of times will actually be better off. Inlining the big __extends and __bind helpers would hurt even more. If you have several files with code in the style of
class A extends B
  method: =>

that are being served together, the only way to avoid code duplication is to define the __extends and __bind helpers in just one place.
Which is why I think this pull request is the right approach. We're not in the production build tool business; we're in the compiler business. This option lets build tools use the compiler in the manner that's most appropriate for them.

__slice

To clarify: __slice is used in argument splices (fn = (a, b...) ->).

@trevorburnham:
$ grep "utility 'slice'" -r src
src/nodes.coffee:        val = "#{olen} <= #{vvar}.length ? #{ utility 'slice' }.call(#{vvar}, #{i}"
src/nodes.coffee:      return "#{ utility 'slice' }.call(#{code})"
src/nodes.coffee:      then "#{ utility 'slice' }.call(#{code})"

__slice isn't used in slices (I know, right?) because the target may be either a string or an array, and __slice is Array::slice.

We're not in the production build tool business; we're in the compiler business. This option lets build tools use the compiler in the manner that's most appropriate for them.

Yep. +1 again.

@TrevorBurnham …and pretty much every single other useful array method.
@jashkenas If you don't like the idea of a flag to exclude the helpers, would you consider some way of separating "boilerplate" code from code that corresponds directly to CoffeeScript source? There doesn't seem to be a good way of identifying and removing the CoffeeScript helpers otherwise.

I'm a little disappointed that the discussion here has stagnated. Can we get a conversation going again? This issue has raised its head again in a situation where I'd like to combine the compiled javascript output in a way that isn't possible with --join.
My use case right now is similar to the Compiled Modules example on the CommonJS wiki. I'd like to distribute my source code without depending on (or worse, bundling) a custom build of CoffeeScript.

I think its stagnated because gzip, for the most part, makes the duplicated boilerplate's impact negligible.

That's unfortunate, especially since the fix has already been implemented. And it makes the output uglier than it really needs to be. :poop:
There was also the earlier suggestion that, with the option to provide our own utility functions, we could make CoffeeScript use those provided by another library. Not that it's massively important, but it's a nice bonus for no extra work.

A big +1 for this. I think @TrevorBurnham has the right idea, this change would appear to make it possible (easy, even?) for require-cs to add support for this when run under the RequireJS optimizer.

@lydell the size isn't necessarily the issue. With code coverage reporters, for example, you end up with branches that are marked as uncovered despite the Coffeescript not showing any branches. You can see the hack I have in place to solve this here https://github.com/Constellation/ibrik/pull/36
This isn't only about splitting hairs about file size.

@lydell  I'm having the same problem has @samuelhorwitz , the inclusion of these extra methods (like the check for indexOf) it creating code paths that my code coverage checks cant reach

@samuelhorwitz @DinisCruz The use case of this PR (as well as in a few other issues) is to reduce repetition of helper declarations, in order to save bytes when sending compiled JS from server to client. However, my tests have proven that this is unnecessary thanks to gzip.
Thanks for bringing up the issue with code coverage tools, though, because I've not heard and thought about such issues before.
I don't see how this PR would help in the code coverage case, though. Even if the helpers are not duplicated, there can still be unused branches is them. Removing all helpers won't cut it either, since then your program won't run at all -- unless you were planning to inject custom versions of them on your own? Feels pretty hacky.
It sounds like you'd rather be looking for some way to extend or override the helpers, more like what is done in the PR @samuelhorwitz linked to. Perhaps we could add an option to pass in a function that would pre-process the helper strings (that'd be done on this line). Then you could do regex hacks on it, or parse it using one of the many JavaScript parsers, modify the AST and return in a string using one of the many AST-to-string modules.

I'd tend to think that points to a fault in the capability of the code coverage tool — better to fix it at the source, instead of contorting your code, no?

Yeah, that's what this beautiful PR I submitted to the Ibrik team does :P https://github.com/Constellation/ibrik/pull/36/files
I'm not familiar enough with Coffeescript compiler to know what the best way to go about doing what I'm trying to do is, but I'm pretty sure my solution isn't it, though it works


Federated Schema Hash Race Condition

I ran into a race condition with the schema Hash() function during building a prototype.  Specifically the issue is around this line:
https://github.com/wundergraph/graphql-go-tools/blob/be7d24d1b89d4cf46802f7cedb8422052f449f32/pkg/graphql/schema.go#L53
Below is a snippet of code showing how I'm creating the most recent engine from a collection of subgraphs:
				cfg := m.List()
				fecf := graphql.NewFederationEngineConfigFactory(cfg,
					gqlds.NewBatchFactory(),
					graphql.WithFederationHttpClient(gw.client))
				_, err := fecf.MergedSchema()
				if err != nil {
					gw.log.Error("get schema error", zap.Error(err))
					continue
				}

				dscfg, err := fecf.EngineV2Configuration()
				if err != nil {
					gw.log.Error("get engine config error", zap.Error(err))
					continue
				}
				dscfg.EnableDataLoader(true)

				engine, err := graphql.NewExecutionEngineV2(ctx, nil, dscfg)
				if err != nil {
					gw.log.Error("create engine error", zap.Error(err))
					continue
				}

				gw.mutex.Lock()
				gw.log.Info("engine updated")
				gw.engine = engine
				gw.mutex.Unlock()

But the problem is the hash is calculated at usage time.  So the question I have is how to solve this best.
A few ideas I have are:

Add an API to the engine that can be called to calculate the hash while it's mutex protected.
Change the hash to be a sync.Atomic type.
Wrap the Hash calculation with a mutex.

Any suggestions on something I missed or how we should fix?  I'm happy to create a PR once I know the direction.

I'd suggest that we build the hash at configuration time. I don't see why we need to compute this while handing a request. @pvormste What's your take on this?

Thanks - I crated a proposal PR for review.


Infinite Bundling causes simulator keeps refreshing screen

Description
My react native app started bundle Infinitely on "react-native run-android". "react-native run-ios" working just fine. I didn't do any configuration change. I don't know how it started.

What I tried:
--- watchman watch-del-all && rm -rf $TMPDIR/react-native-packager-cache-* &&
rm -rf $TMPDIR/metro-bundler-cache-* && rm -rf node_modules/ && npm cache clean --force &&
npm install && npm start -- --reset-cache
--- ./gradlew clean
--- deleting simulator and re-install
React Native version:
System:
OS: macOS 10.15.7
CPU: (8) x64 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
Memory: 521.71 MB / 16.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 12.15.0 - ~/.nvm/versions/node/v12.15.0/bin/node
Yarn: 1.21.1 - /usr/local/bin/yarn
npm: 6.13.4 - ~/.nvm/versions/node/v12.15.0/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
Android SDK:
API Levels: 28, 29
Build Tools: 28.0.3, 29.0.3
System Images: android-28 | Intel x86 Atom, android-28 | Google Play Intel x86 Atom, android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom
IDEs:
Android Studio: 3.6 AI-192.7<IP_ADDRESS>41897
Xcode: 11.3.1/11C504 - /usr/bin/xcodebuild
npmPackages:
react: ~16.9.0 => 16.9.0
react-native: ~0.61.4 => 0.61.5
Steps To Reproduce
1."react-native run-android"
Expected Results
Just run app debug mode in simulator.

fixed:
in App.js file
I disabled
// if (DEV) {
//   NativeModules.DevSettings.setIsDebuggingRemotely(true);
// }


Fixed sizeAverage for NCECriterion

NCECriterion returns table as gradInput, so you can't just use :div(nStep) for size averaging

All tests pass. Thanks @danpol


Feature/example

Add example, see issue https://github.com/expo/react-native-tab-navigator/issues/99.

Thanks @gengjiawen will take a look on this next week.

@gengjiawen would you care to upgrade this to 0.46 so we can merge it? Would be a great addition!

Have got any thought on https://github.com/react-community/create-react-native-app ?

Perfect! Will try it out during the day and merge ASAP! Great work @gengjiawen


WHAT ARE STEPS TO INSTALL YOUR BOT CODES ?

You can set up the bot by following the instructions here: https://github.com/trizin/Telegram-Airdrop-Bot#installation-with-docker

Any app to run script

Any app to run script

Only Docker is required.


Log a thrown error's status when available

From the koa docs, when an error is thrown using ctx.throw it may contain an status code. It would be nice to have that in the logs

Nice!
I saw the errors (with and without status) got formatted differently, I'd like to look into why that happened.


ORC-854: Optimize ReadFully for Full Reads

What changes were proposed in this pull request?
Optimize ORC's readFully method for a condition where the buffer is always fully read.
Why are the changes needed?
Better performance reading Float/Long/Double values.
How was this patch tested?
No change in functionality. Use existing unit tests.

Are we sure that the buffers / InputStreams passed to readFully do not contain data after their usage?

In this context, the "readFully" refers to the the buffer that is passed in, not that the InputStream itself is read fully.  That is, the buffer is fully populated (unless EOF is seen first).  The typical read function of InputStream can return any number of bytes, so you have to be able to handle that, and continuously loop to extract enough data to fully fill the buffer.

Also, since we've been adding a lot of smaller optimizations recently (which can indeed have a big effect in some cases), would it be a good idea to establish something like JMH benchmarks or something to ensure that the optimizations make sense? I know JMH isn't perfect, and many of the optimization PRs have been visually apparent to be optimizing, but throwing that out there to see what others think.

I think something like ORC should definitely have that, and looking at the code, there might even be some JMH tests in there, but we would need additional documentation on how to do that.
For now, I am using the performance benchmarks currently available, using simple timers and/or examining under a profiler.  I've come up with quite a few ideas for PRs, but not all of them have shown much perf improvement and I don't bother submitting them. :)

Are we sure that the buffers / InputStreams passed to readFully do not contain data after their usage?

In this context, the "readFully" refers to the the buffer that is passed in, not that the InputStream itself is read fully. That is, the buffer is fully populated (unless EOF is seen first). The typical read function of InputStream can return any number of bytes, so you have to be able to handle that, and continuously loop to extract enough data to fully fill the buffer.

Ah I misspoke. I was indeed referring to the passed in buffers. That's what I get for reviewing code really late at night.
Looking at it with fresher eyes, it does in fact look like there is no behavioral change between the two. My actual concern was that the buffers passed in were not necessarily intended to be read from the beggining / their current location / mark (and hence the offset parameter). That was my actual concern. But seeing where the code had to be changed, it doesn't appear as though anywhere it's used the offset is anything but zero, so this is functionally the same.
Thanks @belugabehr!

@kbendick @pgaref Good to merge? :)

@kbendick @pgaref Good to merge? :)

I have merged it. Thanks @belugabehr for contribution and @kbendick @pgaref for review!


Add a Testnet faucet command

As a curious end user, I think it would be very convenient if there was functionality to request testnet credits every 24 hours. I think a gentle reminder after a week to send back the credits would be a engaging and fun way to encourage more lbrycrdd users.

@binaryflesh, thanks for opening this. We have a developer program at LBRY.tech which offers free LBC to active GitHub members.
We also have a way to setup your own local LBRY network to control/spend/reset as you like in regnet mode - https://lbry.tech/resources/regtest-setup (needs updating though!!)
I think either of those are better than the testnet scenario. @nikooo777 thoughts?

I opened lbry.tech#268 and lbrycrd#261. I was unaware of how -Regtest was supposed to be used with lbrycrdd and how it compared to using testnet. Closing this one out


Prompt for password length

Prompt user for password length between 8 - 128 characters
Apply password length preference to presented password

This feature was integrated under: commit 81331f23b133b16a69192249e739567cfef68ddc .


cannot stop loadbalancer from binding to my public IP

Environmental Info:
K3s Version:
k3s version v1.31.3+k3s1 (6e6af988)
go version go1.22.8
Node(s) CPU architecture, OS, and Version:
Linux trajan 6.12.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 19 Dec 2024 21:29:01 +0000 x86_64 GNU/Linux
Cluster Configuration:
single server single node on a hetzner VPS
Describe the bug:
I want k3s and the load balancer to only bind on an internal interface but it always binds to the public one as well. I cannot get it to stop binding to <IP_ADDRESS>
Steps To Reproduce:

Installed K3s:
edited the systemd unit with the following flags: --node-external-ip <IP_ADDRESS> --node-ip <IP_ADDRESS> --bind-address <IP_ADDRESS>
I then try with the public ip of the server to do a curl, this always gives a response from traefik

Expected behavior:
curl localhost or curl  should give an error that it cannot connect
Actual behavior:
a http response is given from traefik
Additional context / logs:
load balancing rules:
get svc --all-namespaces
kube-system   traefik                     LoadBalancer   <IP_ADDRESS>    <IP_ADDRESS>     80:30497/TCP             2d10h

https://docs.k3s.io/networking/networking-services#how-servicelb-works

When the ServiceLB Pod runs on a node that has an external IP configured, the node's external IP is populated into the Service's status.loadBalancer.ingress address list with ipMode: VIP. Otherwise, the node's internal IP is used.

Note that the --bind-address only affects the apiserver. It does not affect the loadbalancer, as the loadbalancer uses iptables and does not actually 'bind' to anything.

I have spend hours reading all kinds of docs, including your link. It does not specify how do I change this behaviour. Can you explain to me how I get the setup that I want? I do not want the cluster to be open on my public IP.
On 27 Dec 2024, 00:31, at 00:31, Brad Davidson @.***> wrote:

Note that the --bind-address only affects the apiserver. It does not
affect the loadbalancer, as the loadbalancer uses iptables and does not
actually 'bind' to anything.
--
Reply to this email directly or view it on GitHub:
https://github.com/k3s-io/k3s/issues/11504#issuecomment-2563168743
You are receiving this because you authored the thread.
Message ID: @.***>

Set the node IP to the private IP, and don't set an external IP.

Ah okay! How do I unset the external ip then?
Get BlueMail for Android
On 27 Dec 2024, 01:01, at 01:01, Brad Davidson @.***> wrote:

Set the node IP to the private IP, and don't set an external IP.
--
Reply to this email directly or view it on GitHub:
https://github.com/k3s-io/k3s/issues/11504#issuecomment-2563179754
You are receiving this because you authored the thread.
Message ID: @.***>

After changing the CLI args, you'd probably need to kubectl delete node the existing node, then restart k3s.


(php) Fix php projectSourceUrl

Description
This PR fixes the projectSourceUrl in php package.
Motivation and Context
PHP now uses the GitHub repository php/php-src, and the use of git.php.net has been discontinued.
This should fix the package validation error here - https://community.chocolatey.org/packages/php/8.1.0
How Has this Been Tested?
The updated URL in this PR is valid and is the location of PHP source.
Screenshot (if appropriate, usually isn't needed):
Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[X] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[ ] All files are up to date with the latest Contributing Guidelines
[ ] The added/modified package passed install/uninstall in the chocolatey test environment.
[X] The changes only affect a single package (not including meta package).

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

@shivammathur your changes have been merged, thanks for your contribution 👍
Before we can push out a fixed package, there is still some additional work we need to do since the uninstaller is failing that we/I need to look into.


manage.py migrate not working with external database

I have deployed defectdojo using godojo on EC2 and hooked up to external RDS. While doing version upgrade when I run manage.py migrate it shows no changes to apply. It doesn't look like its comparing the schema with RDS database

Did you activate the virtual environment that godojo creates before you ran that command? An example of making that a 'one-liner' is at https://github.com/DefectDojo/godojo/blob/master/docs-and-scripts/dojo-start#L26 or
source /opt/dojo/bin/activate && python manage.py [manage.py sub-command here]

If you did activate the virtual environment, it's still not migrating maybe try these commands:
source ../bin/activate && python3 manage.py makemigrations dojo
source ../bin/activate && python3 manage.py migrate

This is one of the many reasons why the docker-compose install is significantly better that a godojo install - the initializer container handles upgrades for you. You might get some clues from looking at it's entrypoint script as well - https://github.com/DefectDojo/django-DefectDojo/blob/master/docker/entrypoint-initializer.sh
godojo was really written to replace an old 1200+ line Bash script called setup.bash and will be deprecated for DefectDojo v3 or sooner. It assume a high level of familiarity with how DefectDojo and Django works that ends up causing users problems that could easily be avoided by using the docker-compose install path.
HTH

Can we close this issue @mtesauro ?


Integrate with the Banzai Cloud Kafka operator

Is your feature request related to a problem? Please describe.
Add support/integration with the Banzai Cloud Kafka Operator. The Kafka Operator already orchestrates an Envoy proxy in order to route external broker access towards the broker pod - instead of relying on the load balancer's e.g. round-robin feature. While brokers come and go (autoscaling, failovers, etc) the Kafka operator already generates complex Envoy configs - adding mTLS, etc complicates things even more.
Describe the solution you'd like to see
Add support for Kafka, by wiring brokers into the mesh. Also, add support for the Envoy Kafka protocol filter once is pushed upstream.

Banzai Cloud's Supertubes comes with a full mesh support. If you are interested please check https://banzaicloud.com/docs/backyards/overview/. If you want to read more about the key benefits of integrating Kafka with the mesh please read our blog post


services(tracer,logger,sentry): Includes job labels in context

@aviau @infherny
Turns out we didn't include labels under tags.
I also refactored a little to remove the need to propagate the label in the message now that we have a hold of the message pipeline everywhere and normalize the tags name under logger, tracer and sentry.

look good


Right arrow key jumps to end of line in contentEditable on WebKit browsers

There seems to be some odd behavior when using the arrow keys to navigate around inserted span elements on WebKit browsers. When using the arrow keys, the expected behavior would be that the cursor would jump to the beginning and end of the inserted element instead of to the beginning of the element and to the end of the line. To reproduce on the demo:

insert an emoji/mention
add some text after the emoji/mention
navigate to before the emoji/mention on the same line
use the right arrow key to navigate along the line and over the inserted emoji/mention

From what I can tell the &nbsp after the span element is used as a marker for the end of the inserted element but the &nbsp is replaced if the user enters any text after the element.

Thanks for the wonderful library!

Having the same problem here. Any updates on this?


Bug involving seeking multi-channel flac files.

It appears the way SFML is seeking in flac files is not taking into account the number of channels of the flac file when seeking to a specific sample position.
For instance, seeking to 100 seconds of a 200 second 2-channel flac file will bring you to the very end of the audio.
http://en.sfml-dev.org/forums/index.php?topic=18995.msg141271#msg141271

I implemented a fix for this here #1041. It would be nice if you could test it, to verify that it fixes your problem.

@Foaly Yep, appears to be working as intended.

Fixed in c78c8106dad49dd458aa3624df06d2a989f3d0ed


A request with any enum having rawValue = null hangs forever

Version
4.0.0-beta.6
Summary
Enums defined in the provided graphQL schema are defined as pseudo-enums, actually classes wrapping a String member called rawValue. While it's possible to use the provided enum constants from the class, you can also create your own, possibly passing in null.
Example enum in the graphql schema:
enum StatusEnum {
    GOOD
    BAD
}

Generated StatusEnum class:
public class StatusEnum {
  public static EnumType type = new EnumType("StatusEnum", Arrays.asList("GOOD", "BAD"));
  public static StatusEnum GOOD = new StatusEnum("GOOD");
  public static StatusEnum BAD = new StatusEnum("BAD");

  public String rawValue;

  public StatusEnum(String rawValue) {
    this.rawValue = rawValue;
  }

  public static StatusEnum safeValueOf(String rawValue) {
    switch(rawValue) {
      case "GOOD": return StatusEnum.GOOD;
      case "BAD": return StatusEnum.BAD;
      default: return new StatusEnum.UNKNOWN__(rawValue);
    }
  }
// ... lots of other stuff
}

A good usage of StatusEnum would be to use the constants such as StatusEnum.GOOD, or StatusEnum.BAD. Another valid use of StatusEnum would be to parse the string "GOOD" into StatusEnum.GOOD using StatusEnum.safeValueOf("GOOD") or even new StatusEnum("GOOD").
An invalid, yet allowed, usage of StatusEnum is to pass in null to the constructor: new StatusEnum(null). This isn't checked for invalidity at any point, even up through making the GraphQL call:
var query = GetThingQuery.builder()
            // !!! Set the input enum to null !!!
            .something(new StatusEnum(null))
            .build()

// hangs forever!!
var result = Rx3Apollo.single(apolloClient.query(query), BackpressureStrategy.BUFFER).blockingGet();

When used in conjunction with Rx3Apollo.single(...).blockingGet(), a NullPointerException is thrown in another thread when attempting to serialize this value:
Exception in thread "Apollo Dispatcher" java.lang.NullPointerException: Parameter specified as non-null is null: method com.apollographql.apollo3.api.json.internal.FileUploadAwareJsonWriter.value, parameter value
	at com.apollographql.apollo3.api.json.internal.FileUploadAwareJsonWriter.value(FileUploadAwareJsonWriter.kt)
	at com.apollographql.apollo3.api.json.internal.FileUploadAwareJsonWriter.value(FileUploadAwareJsonWriter.kt:11)
	at org.example.type.adapter.StatusEnum_ResponseAdapter.toJson(StatusEnum_ResponseAdapter.java:29)
	at org.example.type.adapter.StatusEnum_ResponseAdapter.toJson(StatusEnum_ResponseAdapter.java:16)
	at com.apollographql.apollo3.api.NullableAdapter.toJson(Adapters.kt:66)
	at com.apollographql.apollo3.api.ApolloOptionalAdapter.toJson(Adapters.kt:114)
	at org.example.adapter.GetThingQuery_VariablesAdapter.serializeVariables(GetThingQuery_VariablesAdapter.java:27)
	at org.example.GetThingQuery.serializeVariables(GetThingQuery.java:110)
	at com.apollographql.apollo3.api.http.DefaultHttpRequestComposer$Companion.composePostParams(DefaultHttpRequestComposer.kt:126)
	at com.apollographql.apollo3.api.http.DefaultHttpRequestComposer$Companion.access$composePostParams(DefaultHttpRequestComposer.kt:77)
	at com.apollographql.apollo3.api.http.DefaultHttpRequestComposer$Companion.buildPostBody(DefaultHttpRequestComposer.kt:225)
	at com.apollographql.apollo3.api.http.DefaultHttpRequestComposer.compose(DefaultHttpRequestComposer.kt:71)
	at com.apollographql.apollo3.runtime.java.network.http.HttpNetworkTransport.execute(HttpNetworkTransport.java:49)
	at com.apollographql.apollo3.runtime.java.ApolloClient$NetworkInterceptor.intercept(ApolloClient.java:147)
	at com.apollographql.apollo3.runtime.java.interceptor.internal.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:35)
	at com.apollographql.apollo3.runtime.java.ApolloClient.lambda$execute$0(ApolloClient.java:131)

Because the serialization exception happens in a different thread, but we're using Rx3Apollo.single(...).blockingGet() to block until the request finishes, the result is that the current thread hangs forever.
Obviously, this is an invalid use of the generated enum -- or maybe it's valid and null should be the resulting serialized value. In any case, it would be much more useful to have the library do something (either use null or surface the exception to the calling thread) rather than just hang forever.
Possible Solutions

Don't allow construction of generated enums with null values - this would be nice since it would catch this particular issue at the earliest possible spot. Just a simple if (rawValue == null) throw new NullPointerException() in the constructor would suffice.
Check during serialization whether rawValue is null, and if so, serialize to JSON as null -- this is in case rawValue=null is a valid state and should be allowed.
Surface the NullPointerException up to the calling thread like any other exception might be discovered -- this is slightly less preferred, but maybe this should be happening anyway for serialization failures?

Just some ideas. I have never contributed to this library and TBH I'm still figuring out how best to use it. Please let me know the desired path forward.
Steps to reproduce the behavior
I've created a repo to reproduce this behavior in the simplest possible way: https://github.com/japhib/apollo-null-enum-test
To reproduce the bug, simply run ./gradlew test and observe that the test TestMain.testNullEnumHangs() times out after the configured 30 second timeout.
Key parts:

A GraphQL schema, with both an enum and a query that takes that enum as an input variable:

# schema.graphqls
type Query {
    everything(something: StatusEnum): TypeA
}

type TypeA {
    status: String
}

enum StatusEnum {
    GOOD
    BAD
}

# GetThing.graphql
query GetThing($something: StatusEnum) {
    everything(something: $something) {
        status
        __typename
    }
}

The plugin to generate Java code based on that schema

# build.gradle
plugins {
    id("com.apollographql.apollo3") version "4.0.0-beta.6"
}

Create the query with an instance of the enum, but passing in null as the rawValue for the enum constructor:

var query = GetThingQuery.builder()
            // !!! Set the rawValue of the enum to null !!!
            .something(new StatusEnum(null))
            .build()

Use Rx3Apollo to make the call using the specified query:

// hangs forever!!
var result = Rx3Apollo.single(apolloClient.query(query), BackpressureStrategy.BUFFER).blockingGet();

Logs
See above.
thanks!
Just wanted to say, thanks for this library! For the most part it has been great to use and has solved the problem of using GraphQL from Java in a rather elegant way. The code generation is nice to work with and the IntelliJ plugin (maybe maintained by this org?) is also very convenient to work with.

Hi 👋 Many thanks for the detailed issue and the kind words ❤ .

The code generation is nice to work with and the IntelliJ plugin (maybe maintained by this org?) is also very convenient to work with.

Apollo's own @BoD built most of the Apollo IJ plugin, which depends on the IntelliJ GraphQL plugin for shared functionality.

While it's possible to use the provided enum constants from the class, you can also create your own, possibly passing in null.

Looks like you're using Java codegen? (generateKotlinModels.set(false)?). If yes, can you try with the Kotlin codegen?
apollo {
  service("service") {
    generateKotlinModels.set(true)
    sealedClassesForEnumsMatching.set(listOf(".*"))
  }
}

Also the latest SNAPSHOTs use an @ApolloEnumMarker OptIn annotation on the constructor to make it clear that the constructor is not supposed to be called directly (even if it's still possible): See https://github.com/apollographql/apollo-kotlin/pull/5813.

Using the Kotlin generated code does indeed make it impossible to pass null to the enum constructors. But then I lose access to other things that are nice for Java, such as the builder interface for queries.
I'm using the latest version but the generated enum class doesn't appear to have the @ApolloEnumMarker annotation ... does that only happen for Kotlin?
Is there a problem preventing the generated enum class from making the constructor private?

I'm also curious how @ApolloEnumMarker is supposed to work. Seems like it creates a compiler warning unless you "opt-in" by adding a different annotation. Is that correct?

Using the Kotlin generated code does indeed make it impossible to pass null to the enum constructors. But then I lose access to other things that are nice for Java, such as the builder interface for queries.

Rigth 👍

I'm using the latest version but the generated enum class doesn't appear to have the @ApolloEnumMarker annotation ... does that only happen for Kotlin?

Indeed, this is only for Kotlin, and only for the SNAPSHOTs versions

Is there a problem preventing the generated enum class from making the constructor private?

Excellent question. IIRC there was some concern that some advanced use cases could still want to send unknown (to the client) enums (that would be known by the server). This could happen for an an example if the enum is passed "out of band" to an older app. You can read https://slack-chats.kotlinlang.org/t/16930109/apollo-kotlin-generates-an-unknown-entry-in-all-enums-to-be- for some background although I'm not sure what the ultimate decision was.

I'm also curious how @ApolloEnumMarker is supposed to work. Seems like it creates a compiler warning unless you "opt-in" by adding a different annotation. Is that correct?

Correct 👍
All in all, we should add a non-null assertion for Java codegen. Whether we can do better while still keeping the constructor accessible is not clear to me in Java. Java doesn't have @OptIn annotations.

Thanks for the answers.

All in all, we should add a non-null assertion for Java codegen.

I support this. Seems like the simplest solution going forward.

What do you think of:

add a non-null assertion in safeValueOf
making the class constructor private
also making the UNKNOWN__ constructor private

2 and 3 are breaking changes but it's probably for the better

Wouldn't that prevent users to use a custom rawValue if they really want to? cf "there was some concern that some advanced use cases could still want to send unknown (to the client) enums (that would be known by the server)"

Wouldn't that prevent users to use a custom rawValue if they really want to?

safeValueOf("foo") does it

Gotcha 👍 Perfect plan ✅

Made the change in #5904 which will be included in the next beta release of v4. The related change has also be made in the generated Kotlin enums when using sealed classes: now safeValueOf must be used.

Fix is released in 4.0.0-beta.7


Default token rbac permissions

Hi, I've been reviewing the besu-kubernetes automated ibft setup and noticed that you're currently allowing secret and configmap permissions to everything that runs in the same namespace: https://github.com/PegaSysEng/besu-kubernetes/blob/master/helmfile/private-network-ibft-automated/besu-genesis/templates/role-binding.yaml#L49
Wouldn't it make more sense to use a dedicated service account that you specify in the designated jobs and/or statefulsets that actually need the access instead of granting a complete namespace the access?

Thanks for that, I'll look at adding a service account in or updating the Readme to be explicit about this. This example is intended for users to get familiar with how things work and then design a system to suit their needs for a production use where network topology, data volumes, security etc has been taken into account

I can make a PR if you want to!

By all means :)

Closing for lack of activity. Readme has notes now to deploy using namespaces and nothing should go in the default namespace


Race condition when testing

I tried following your guide on testing and am seeing a race condition between the assertion happening and the store receiving an action type that updates it.
My test looks like:
actions.toggleShowMorePresets();
expect(reactor.evaluate(getters.showMorePresets)).to.eql(true);

Here's the debugging output where I've put some logs to show the order of things:

Is there a way to resolve this? Somehow make nucler trigger things synchronous in test?
More info:
action:
toggleShowMorePresets: function() {
    reactor.dispatch(TOGGLE_SHOW_MORE_PRESETS);
}

store:
  initialize() {
    this.on(TOGGLE_SHOW_MORE_PRESETS, state => {
      return state.updateIn(['sections', 0, 'showMorePresets'], showMore => {
        return !showMore;
      });
    });
  }

Interesting.
Nuclear should be doing everything synchronously.
Where does store registration happen.
Would you mind posting the full function block in your test code?

@jordangarcia Sure
Store registration in module index
import reactor from 'reactor';
import actions from './actions';
import getters from './getters';
import ResizePanelStore from './stores/ResizePanelStore';

reactor.registerStores({
  ResizePanel: ResizePanelStore
});

export default {
  actions: actions,
  getters: getters
};

Test looks like:
import reactor from 'reactor';
import {actions, getters} from 'modules/ResizePanel';

describe('ResizePanel', () => {
  describe('actions', () => {
    describe('#toggleShowMorePresets', () => {
      it('should toggle from false to true and back', () => {
        expect(reactor.evaluate(getters.showMorePresets)).to.eql(false);
        actions.toggleShowMorePresets();
        expect(reactor.evaluate(getters.showMorePresets)).to.eql(true);
      });
    });
  });
});

It's running in Chrome with Karma + Mocha + Chai

For more info, I've created a function using observers to verify it is a race condition and it does pass.
helper fn:
reactor.nextValue = function(keyPath) {
  return new Promise((resolve, _reject) => {
    var unwatch;
    unwatch = reactor.observe(keyPath, (...args) => {
      unwatch();
      resolve(...args);
    });
  });
};

Test:
      it('should toggle from false to true and back', () => {
        expect(reactor.evaluate(getters.showMorePresets)).to.eql(false);

        actions.toggleShowMorePresets();

        return reactor.nextValue(getters.showMorePresets).then(newValue => {
          expect(newValue).to.eql(true);

          actions.toggleShowMorePresets();
          return reactor.nextValue(getters.showMorePresets);
        }).then(newValue => {
          expect(newValue).to.eql(false);
        });
      });

Oh man, that's pretty gnarly.
Your test code looks fine to me.
Mind posting what your store looks like.
There is an issue with the evaluator and occasional collisions that cause stale evaluate values.  See #140.
I am in the process of refactoring the evaluator to fix this, not 100% sure that your issue is related to this but seems like the mostly likely case.

@jordangarcia Sure, like so:
import { Store, toImmutable } from 'nuclear-js';
import reactor from 'reactor';
import getters from '../getters';
import { TOGGLE_SHOW_MORE_PRESETS } from '../actionTypes';

function toggleShowMorePresets(state) {
  return state.updateIn(['sections', 0, 'showMorePresets'], showMore => {
    return !showMore;
  });
}

export default Store({
  getInitialState() {
    return toImmutable(require('json!yaml!../state.yml'));
  },

  initialize() {
    this.on(TOGGLE_SHOW_MORE_PRESETS, toggleShowMorePresets);
  }
});

hmmmm.
Can you try something crazy.
can you make the toggleShowMorePresets function return a string like 'foobar' and see if the race condition still exists.
If it doesn't then this is indeed related to a stale cached value like in #140.  If not then it may be something deeper.

When changing it to something like:
  return state.updateIn(['sections', 'index', 'showMorePresets'], showMore => {
    return showMore === "true" ? "false" : "true";
  });

I see the same behavior :/ Is that what you had in mind?

@jordangarcia Crap, I figured it out. We had a custom Reactor class that dispatched changes on requestAnimationFrame and that was causing them to be triggered async.
Apologies for having you look into a non-problem.


environment is broken in a block in an ensure clause

loop do
  a = {}
  begin
  ensure
    p a
    [1].each { p a }
  end
  break
end

The variable a defined at the top of the "loop" block is an empty Hash.  But it tunes into main object in a iterator block in an ensure clause.
% ruby a.rb
{}
{}

% bin/mruby a.rb
{}
main

By bisecting, I found e26e11860466676e5713fa0d9ab268ea8dbdcef9 is NG and the preceding commit 5513fcee22ceab9293bff7815f961616c1fa3e83 is OK.

it can be be simpler:
begin
ensure
  a = 1
  [1].each {
    p a
  }
end


Expire non-current versions in our permanent storage buckets

Although we have versioning enabled, we never actually delete the old versions once they're gone!
I've applied this in staging and it looks fine (although we don't actually enable versioning on the staging buckets); I'll apply in prod once this has been reviewed.

Just to have context as to why we might chose these times what would we use previous versions for?

There is some reasoning behind this, but it belongs in the code rather than a PR discussion. I'll push another commit in a bit.


Local Ollama URL incorrect and no adjustment.

When attempting to use a local instance of olamma, I get this error:
Failed to generate step after 3 attempts. **Error: 404 Client Error: Not Found** for url: http://<IP_ADDRESS>:11434/api/chat

However manually verifying that the service is up and running works:
curl http://<IP_ADDRESS>:11434/api/generate -d '{
  "model": "llama3.1:latest",
  "prompt": "Why is the sky blue?"
}'
{"model":"llama3.1:latest","created_at":"2024-12-07T22:59:12.977900524Z","response":"The","done":false}
{"model":"llama3.1:latest","created_at":"2024-12-07T22:59:12.988189036Z","response":" sky","done":false}
{"model":"llama3.1:latest","created_at":"2024-12-07T22:59:12.998730522Z","response":" appears","done":false}
{"model":"llama3.1:latest","created_at":"2024-12-07T22:59:13.009296528Z","response":" blue","done":false}
{"model":"llama3.1:latest","created_at":"2024-12-07T22:59:13.019687252Z","response":" to","done":false}

It APPEARS that "/api/chat" is not the correct URL and without digging into the source, there doesn't appear to be a way to change it.
I have a fairly generic ollama install, only oddity is the use of ROCM as I have an AMD GPU:
version: '3.8'

services:
  ollama:
    image: ollama/ollama:rocm
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ./Ollama/data:/root/.ollama
    devices:
      - /dev/kfd
      - /dev/dri
    shm_size: '16gb'
    group_add:
      - video
    cap_add:
      - SYS_PTRACE
    security_opt:
      - seccomp=unconfined
    restart: always

  ollama-webui:
    build:
      context: .
      args:
        OLLAMA_API_BASE_URL: '/ollama/api'
      dockerfile: Dockerfile
    image: ghcr.io/ollama-webui/ollama-webui:main
    container_name: ollama-webui
    volumes:
      - ./Ollama/webui:/app/backend/data
    depends_on:
      - ollama
    ports:
      - 8081:8080
    environment:
      - 'OLLAMA_API_BASE_URL=http://ollama:11434/api'
      - 'WEBUI_SECRET_KEY='
    extra_hosts:
      - host.docker.internal:host-gateway
    restart: always

EDIT:  Updated test to actually use IP rather than localhost just to confirm.  No change.

More from the Ollama logs:
Working request from the Ollama UI:
llm_load_print_meta: EOG token        = 128008 '<|eom_id|>'
llm_load_print_meta: EOG token        = 128009 '<|eot_id|>'
llm_load_print_meta: max token length = 256
llama_model_load: vocab only - skipping tensors
[GIN] 2024/12/08 - 21:08:16 | 200 | 13.403022737s |      <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/12/08 - 21:08:55 | 200 |  6.479498014s |      <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/12/08 - 21:08:55 | 200 |  138.817915ms |      <IP_ADDRESS> | POST     "/api/generate"

Logs from Streamlit UI:
[GIN] 2024/12/08 - 21:14:17 | 404 |     182.912µs |   <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/12/08 - 21:14:18 | 404 |     162.111µs |   <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/12/08 - 21:14:19 | 404 |     121.001µs |   <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/12/08 - 21:14:19 | 404 |     268.412µs |   <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/12/08 - 21:14:20 | 404 |     122.731µs |   <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/12/08 - 21:14:21 | 404 |     127.201µs |   <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/12/08 - 21:14:21 | 404 |     385.263µs |   <IP_ADDRESS> | POST     "/api/chat"

This issue was caused by not having the model already downloaded in ollamma.
This should probably have a check if possible, or maybe include some extra detail in the error?   Maybe  "check your selected model is available"?


Add dispatch to the effects arguments

Forked from: https://twitter.com/meijer_s/status/1252252222500622336?s=20
I think it makes sense to pass dispatch to the effect's arguments as well, so that we don't need to declare our effects, or "api" within the scope of the component.
I believe this would also benefit the test-ability of the effects. As I could now just test api and stub dispatch with jest.fn.
const api = {
  fetchDog: async (state, effect, dispatch) => {
    try {
      const data = await fetchRandomDog();
      dispatch({ type: 'RESOLVE', data });
    } catch (error) {
      dispatch({ type: 'REJECT', error });
    }
  },
};

function dogReducer(state, event, exec) {}
const initialState = {};

function DogFetcher() {
  const [state, dispatch] = useEffectReducer(dogReducer, initialState, api);

  // ...
}

Yeah, this will be great!


adding messaging plugin container with the various messaging plugins

@Hermann-Core @Christiantyemele @IngridPuppet please review this PR

@Hermann-Core, please review this pull request

Suggestion Enhance the plugin with logging to improve observability during initialization and operation. You can use the tracing crate for structured logging as indicated in the review.

These are unnecessary and redundant because all the errors and required informations will already be traced. Take a look at the plugin manager implementation.


boost 1.81.0 upgrade

Description
The CRAN package BH is about to go to 1.81.0, see https://github.com/eddelbuettel/bh/issues/88
Example
Expected Output
We should bump to 1.81.0 once the CRAN BH package is released in January according to the current plan.
Current Version:
v4.5.0

since yesterday boost is bumped to 1.81.0 on CRAN... so bump boost in Stan-math would make a lot of sense now (ok, not that things are perfectly aligned wrt to Stan-math and rstan... still it would be nice)


[Bug-fix] Made truncated_normal_ completely in-place

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue

The current implementation of mbrl.util.math.truncated_normal_() is not (entirely) in-place. This problem can be seen with the following code snippet.
import torch

import mbrl.util.math

t_original = torch.empty(1000)
t_new = mbrl.util.math.truncated_normal_(t_original)

print((t_original == t_new).all().item())
print(((t_original <= 2.0).all() and (t_original >= -2.0).all()).item())

With the current implementation, both outputs are False. If the implementation was in-place, both outputs should be True. The problem is that torch.where(), used in truncated_normal_(), is not an in-place operation. As a result, t_original contains values sampled from a regular Gaussian, while t_new contains values sampled from the truncated Gaussian.
How Has This Been Tested (if it applies)

import torch
import matplotlib.pyplot as plt

import mbrl.util.math

t_original = torch.empty(5000000)
t_new = mbrl.util.math.truncated_normal_(t_original)
assert (t_original == t_new).all().item()

plt.hist(t_original.cpu().numpy(), 100)
plt.show()

After the changes, the code snippet above results in the following histogram, which shows that the values are sampled from a Gaussian truncated to [-2, 2].

Checklist

[x] The documentation is up-to-date with the changes I made.
[x] I have read the CONTRIBUTING document and completed the CLA (see CONTRIBUTING).
[x] All tests passed, and additional code has been covered with new tests.

Hi @JanS97, this is great, good catch! Thanks a lot for the fix. Do you mind adding a unit test along the lines of the first code snippet? (and probably best to use torch.allclose instead of == for the first check)

Yes, sure I can add a unit test. Actually, I think we should just check t_original is t_new since both variables should refer to the same object.

Sounds good. Thanks!

I added the test. It checks both conditions from the first code snippet.

LGTM. Merging now. Thanks @JanS97 !


No longer trimming configuredStatusText since it corresponds directly to what is in the DB

Description
It makes sense to trim the text from user-provided status texts and emails. However, the configuredStatusText field used to identify the original status when editing / deleting is essentially a key into what is in the DB directly. Additionally, it's populated based on the DB value. Performing a trim here will cause issues if a status makes it's way into a program that hasn't been trimmed.
Release notes:
N/A
Checklist

[X] Added the correct label: < feature | bug | dependencies | infrastructure | ignore-for-release >
[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Issue(s)
#2752

Do we trim the original status value input?

Yes, here: https://github.com/civiform/civiform/blob/99e4c9f70f4a27aad9bf18b2f62c5358f7e25b3f/server/app/forms/admin/ProgramStatusesForm.java#L64

Codecov Report

Merging #3152 (99e4c9f) into main (2b108d9) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 99e4c9f differs from pull request most recent head b4cebff. Consider uploading reports for the commit b4cebff to get more accurate results

@@            Coverage Diff            @@
##               main    #3152   +/-   ##
=========================================
  Coverage     77.92%   77.92%
  Complexity     2185     2185
=========================================
  Files           277      277
  Lines          8721     8721
  Branches        591      591
=========================================
  Hits           6796     6796
  Misses         1701     1701
  Partials        224      224

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


Discord embed black color only problem

I am not sure I understand your hexadecimal format, because I search up for the format and plug them in, but all it returns to me in black. Do you have any ideas that can help me? Please answer as soon as possible!

Hello, the format for picking a color looks like {FF0000 for red, {00FF00 for green. That sort of thing. I assume the confusion is because you probably expected to input #FF0000 or maybe {#FF0000. Let me know if this helps/works.

Hello, the format for picking a color looks like {FF0000 for red, {00FF00 for green. That sort of thing. I assume the confusion is because you probably expected to input #FF0000 or maybe {#FF0000. Let me know if this helps/works.

Maybe my generator is broken? It still not working for me. It returns back black again. Would you like me to share a google doc of it, maybe that can help?

If you would like to add me to the server for a moment we can take a look. As you mentioned it's also possible that the generator is no longer working due to updates to the Discord.js module.

Sure!

My username is InStock#9416

https://discord.gg/PzK276jT


Timer Clock on KeyGen

User should feel progress on keygen

Clock ARC, which "winds" towards 12-oclock

prepare: 10 seconds
ECDSA: 10 seconds
EdDSA: 10 seconds
DONE: 1 second animation

Clock ARC should slow down in the last ¼ arc, gradually "inching" towards 12-oclock until the step is complete, but not finishing until step complete

Clock ARC should instantly speed up and fill when progressing to next STEP

words while waiting

"Generating ECDSA Key"
line underneath scrolls all ECDSA chains (while waiting)
<<<<<< Bitcoin, Ethereum, Litecoin, Dogecoin..... <<<<
"Generating EdDSA Key"
line underneath scrolls all EdDSA chains:
<<<<<< Solana, Polkadot, Aptos..... <<<<

DONE

User should be presented with a DONE animation

clock arc morphs into giant TICK ✅
animation!
maybe logo pulses

max 2 seconds

Discuss the design with Mia when you start it @Rockindash


Update 430 - Creator of Wordle.md

thanks nthan

Nthaan is my fav spellchecker. :) Thanks for catching that!


Mission Log

This adds a new log file to the SD card configurable via SDLOG_MISSION parameter.
Use-cases
It's also a ULog file, but only contains minimal information for the following use-cases:

geotagging/survey (more generally: extract data collected by the pixhawk during a mission and needed for post-processing)
cloud upload & statistics: keeping track of where and how long a vehicle has flown, and if there were problems.
regulation: keeping a small log to show where a drone was flown, what failures happened etc.

It is stored in another directory (mission_log) to keep the logs separate from the normal flight logs.
@dogmaphobic This will need an interface update on the QGC side, and maybe changes/extensions to the log download. I have not looked into that yet.
Implementation

the general structure of the logger is the same, but the mission logs use a separate independent write buffer.
optimization to reduce the header size: now only the message formats are written for messages that are actually logged. Reduces the header size by about 13KB for a normal log.
due to other optimizations, RAM usage does not increase if the mission log is disabled.
If enabled, only the additional buffer of 300 bytes is required.

Testing
I ran a stress-test on a low-quality SD card for 1h:30min with 90KB/s normal logging rate and enabled mission log with 5Hz camera capture publication. There were no drops for the mission log, and the maximum used buffer was 200 bytes, so 300 bytes buffer size will be enough.
CPU load minimally increased from 5.6% + 1.7% to 5.7% + 1.8% for the main and writer threads.
Fixes https://github.com/PX4/Firmware/issues/10189.
I enabled the mission log by default so that we get it field-tested. But it does not have to be enabled later on.

Looks cool. I commented on the parameter doc.
Can we also update the user guide with this and also cover the other SDLOG_ params? Proposal is that this should be added in user guide https://docs.px4.io/en/getting_started/flight_reporting.html

Add a section on "Configuring logging" covering all the params
Explain which logs can be used for what - for example, is Mission Log useful in Flight Reporting?

I thought it would be good to add a link to the geotagging log in geotagging docs, but we don't have any. Do we need a page that covers what we offer in this area? If so, what would such a page offer?
Last of all, I looked at the devguide logging topic https://dev.px4.io/en/log/logging.html
My guess is that the logger is set up with all the rates information etc when the board is set up - and the user guide people don't need to know about this?
Should we perhaps just add a note in that logging topic about the SDLOG parameters.

Can we also update the user guide with this and also cover the other SDLOG_ params? Proposal is that this should be added in user guide https://docs.px4.io/en/getting_started/flight_reporting.html

Ok.

Explain which logs can be used for what - for example, is Mission Log useful in Flight Reporting?

No.

I thought it would be good to add a link to the geotagging log in geotagging docs, but we don't have any. Do we need a page that covers what we offer in this area? If so, what would such a page offer?

Yes we should have that. But I don't know of anything that exists already either.

My guess is that the logger is set up with all the rates information etc when the board is set up - and the user guide people don't need to know about this?

You generally don't have to change anything, since the defaults are good for general log analysis. Special use-cases that differ from that include:

ekf2 replay
enabling the high-rate logging profile for PID & filter tuning
if you want your own set of logged topics.
thermal temperature calibration

Thanks @bkueng . I'll look into updates to those docs once this is merged.

CI fails:

remote file operation failed: /tmp/jenkins/workspace/irmware-compile_mission_log-VMOKXZB2XWPNUMKC2VMXOFD4RIUCZ46BF3YVCQJRPP6QGICMO3JA@tmp/durable-cb023d6c at hudson.remoting.Channel@61b65624:ec2_docker_slave (i-0001bbab6136cffbf): java.nio.file.FileSystemException: /tmp/jenkins/workspace/irmware-compile_mission_log-VMOKXZB2XWPNUMKC2VMXOFD4RIUCZ46BF3YVCQJRPP6QGICMO3JA@tmp/durable-cb023d6c: No space left on device

@dagar can you look into it?

@bkueng we had a zombie ec2 slave. I'll restart these jobs now.

Some may want vehicle_attitude as well. Pix4d can optionally use roll, pitch, yaw.

I tested in pixhawk 4 and pixhawk 4 mini in both created a folder with the name of mission_log.
pixhawk 4 log
https://review.px4.io/plot_app?log=eaed8008-87c9-40a3-b209-d23c50208f5f
pixhawk 4 mini log
https://review.px4.io/plot_app?log=f074290a-4f59-4cff-9a05-23adf99b21ef

@bkueng OK, docs for this waiting in https://github.com/PX4/px4_user_guide/pull/372 . Note that they are only peripherally about the mission log - without a topic about something that uses it (e.g. geofencing) there isn't much to say about it yet. So consider this "a start".


Merge of 8722 from 1.0

This is a manual merge, the trees have diverged too much.
I did not merge the 'legacy' code or the variables to control fallback, not needed in master.
From original PR:

added a mechanism for service discovery to update 'shards' of endpoints
new data structures optimized for endpoint update ( IstioEndpoint has minimum info needed and allows caching the proto )
optimized the update path - only affected shard will be changed without triggering a full cache invalidation
rewrote the EDS tests - which were testing the 0.7 method, no longer used
added a ADS client mirroring envoy behavior, to simplify testing (the load tester using this will be in separate PR)
optimized the incremental push update path.
fixed label update to cause a push.

@costinm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-unit-tests

prow/istio-pilot-multicluster-e2e.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-unit-tests

prow/istio-pilot-multicluster-e2e.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-multicluster-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-e2e-envoyv2-v1alpha3-mcp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-unit-tests

prow/istio-pilot-multicluster-e2e.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-multicluster-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-e2e-envoyv2-v1alpha3-mcp

prow/e2e-bookInfoTests-v1alpha3.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-unit-tests

prow/istio-pilot-multicluster-e2e.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-multicluster-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-e2e-envoyv2-v1alpha3-mcp

prow/e2e-bookInfoTests-v1alpha3.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-mixer-no_auth-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-mixer-no_auth-mcp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-multicluster-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-e2e-envoyv2-v1alpha3-mcp

prow/e2e-bookInfoTests-v1alpha3.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-mixer-no_auth-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-mixer-no_auth-mcp

prow/istio-unit-tests.sh
889bc72a2d4cff193817dc7db1e685fb6fde94bf
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-multicluster-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-e2e-envoyv2-v1alpha3-mcp

prow/e2e-bookInfoTests-v1alpha3.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-mixer-no_auth-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-mixer-no_auth-mcp

prow/istio-unit-tests.sh
889bc72a2d4cff193817dc7db1e685fb6fde94bf
link
/test istio-unit-tests

prow/istio-presubmit.sh
889bc72a2d4cff193817dc7db1e685fb6fde94bf
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

galley/OWNERS
istioctl/OWNERS
mixer/OWNERS
pilot/OWNERS
pkg/OWNERS
security/OWNERS
tests/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-multicluster-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test istio-pilot-e2e-envoyv2-v1alpha3-mcp

prow/e2e-bookInfoTests-v1alpha3.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-mixer-no_auth-mcp.sh
e6edd520864c84f35c2dd66ae9ffc310e448bb94
link
/test e2e-mixer-no_auth-mcp

prow/istio-presubmit.sh
889bc72a2d4cff193817dc7db1e685fb6fde94bf
link
/test istio-presubmit

prow/istio-unit-tests.sh
252e550d9f72f1ec9d9000c512d944ef8ab190ef
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
e2268d9c70804878e34ca359d48087fd02a65bf0
link
/test istio-unit-tests

prow/e2e-mixer-no_auth-mcp.sh
e2268d9c70804878e34ca359d48087fd02a65bf0
link
/test e2e-mixer-no_auth-mcp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS
pkg/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: ZackButcher
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [ZackButcher]
pkg/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

pkg/adsc is covered by the tests in pilot/proxy/envoy/v2 - yes, we'll probably move some of the tests to the adsc package. It used to be part of the tests - but now we use it in the load tester.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ozevren, ZackButcher
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [ZackButcher]
pkg/OWNERS [ozevren]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

@costinm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
498b801d4e231025d239d7779fdbe2cfaf284afe
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
498b801d4e231025d239d7779fdbe2cfaf284afe
link
/test istio-unit-tests

prow/istio-presubmit.sh
498b801d4e231025d239d7779fdbe2cfaf284afe
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@costinm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
b1bca8cae793d4b99b1b1dd9b3501a4d474c7b03
link
/test istio-unit-tests

prow/e2e-mixer-no_auth.sh
b1bca8cae793d4b99b1b1dd9b3501a4d474c7b03
link
/test e2e-mixer-no_auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-unit-tests
/test e2e-mixer-no_auth


Added functions to set colors using RGB values

In addition to adding the  functions based on the requirements of issue #46 , I made some updates to the previous code base based on a syntax error in the main branch.
I also updated the circle.ml file to use the Joy library in order to test the changes made.
For some reason, after every change, I still get only the black circle displayed and not the colored circle.
Please review these changes. Would love to get your feedback

Okay, I'll make the changes. Thank you @nikochiko

I've updated the code:|

To make fill and stroke non optional and the default for fill is transparent while for stroke is black. The shapes can now use the default values
I have created a new type for color. It looks like Transparent | Fill of int * int * int | Stroke of int * int * int as @Sudha247 proposed which can store this information in the same field in a shape.
This shape.mli file has been updated accordignly.
I created a new file called colored_circle to test the changes and the circle displays perfectly fine with the colors that I defined.
I've updated the rest of the code accordingly.

I've updated this PR based on the requested changes by @nikochiko .
Please review


expande getIssuesForBoard + useQuerystring for fixing oauth get request

Added "jql" and "fields" options for "getIssuesForBoard" method. Since this method using GET request, for Oauth signature we need to use "useQuerystring" option of request package to stringify fields list correctly.

BTW, currently any GET request with oauth and get arguments will not work, because of useQuerystring option.

Published 2.8.0


Fix: Fixed SelectWidget: when there was a selected value, the selecti…

…on was lost when the tab was changed
Fixes: https://github.com/plone/volto/issues/2742

It seems to me that we need a ton of Cypress tests around the Selects/Array/Token widgets :/
For the Fanzone list for sure.
btw, @giuliaghisini did you check if this flaw is also present in Array/Token?

no Victor, i didn't check Array and Token widgets. We can't at the moment. If someone else would like to check it will be very apprecieted.


[do-not-merge] Revert sdk version

Still discussing with the SDK team how to proceed. Our main branch needs to be unblocked soon. #1470

This is not needed anymore


chore: Merges main-overview module with control-planes module

We've been chatting for a while about moving main-overview to be called control-planes, and now felt like the first good opportunity to do it.
This PR merges main-overview module with control-planes module, so a main-overview module no longer exists.
Notes:

The control-planes module is already being added in main.ts
I moved the MainOverview component (now ControlPlaneStatus) to no longer be injected via the @/components/index file. Eventually this file will cease to exist.
I didn't rename the i18n keys prefixed with main-overview as yet, I'll do that in a follow up.

There were a couple of "while I was here" things, that I'll note inline.

Just to link to a previous conversation in a feature PR where this came up, it also came up offline previous to that (which is also mentioned in that PR)
https://github.com/kumahq/kuma-gui/pull/1682#pullrequestreview-1706267264
Just to note this is a refactoring PR, specifically about renaming things to our newer style, although granted not specifically about the names of .vue files.
#1682 decided not to follow the naming convention of the zones, zone-insights and zone-egresses modules. That being - not repeating the namespace of the file in the name of the file. I didn't see a technical reason why there was a problem with not repeating the namespace of the file in the name of the file and I don't think you've given on as yet, but I decided to approve the PR in order to get the feature into the software and then circle back.

Here is a screengrab of my editor now:

Note from #1682 I've no idea what the extension is on the ZoneIngressSummar name when looking at that. I don't really know whether the name ends in Summary. Is this a .spec file? Is it a ZoneIngressSummaryAbstractView, I've no idea. I've also noticed that this kinda problem is also beginning to happen in the GH web UI in the file explorer during code reviews.
Here's a screengrab of the the zones module in my text editor previous to me removing the namespace from the name of the file for the zones related modules.

I still find it really hard to look at that screengrab, so I'm really glad I changed it. Both of the above screengrabs show how redundant it is to prefix every file within a folder with the same name of the folder.
Could I widen the sidebar in my editor? Of course I can, but its an extra thing to keep having to do, but I could. Pretty sure I can't on GH though. Would widening my editor sidebar it make that last screengrab any easier to parse quickly, I'd say no.

On the other hand, in our past conversations you've pointed out that you have found it hard to find the files in your fuzzy finder with these shortened file names, although I did point out that as the fuzzy finder will also use the name of the folder in its search, there should be no real difference and I didn't get any response back from you on that, so I kinda assumed that was problem solved.

Does ZoneListView technically contain more characters than IndexView? Yes. Does that make ZoneListView a worse name? No. Doesn’t make it any harder for you to find it and does make it easier for me to find it.

The technical fact there is that is that IndexView has less characters than ZoneListView and therefore is easier to read in a sidebar. The personal opinions are that ZoneListView isn't a 'worse name' or that it makes it harder or easier for someone to find. And those points are all omitting that fact that its redundant to include the namespace of a thing in the name of the thing that has already been namespaced. Or that with IndexView as opposed to TabView (the UI might change), or AbstractView (abstract generally means its not directly used) is maybe a safer more descriptive choice.

Please stick to the pretty well-established pattern to include the module name in one form or another (e.g. ControlPlaneDetailView.vue).

I wouldn't call ControlPlaneDetailView exactly well established, I could probably point to a few repos where they don't repeat the namespace in the name of the file (e.g. https://github.com/Kong/kong-manager/tree/main/src/pages/certificates). In this repository specifically I'd say the split is probably 60/40 amongst our modules, Its mostly only 60/40 due to the fact that we've spent quite a long time organising this repository a little better that it was previously and we are now nearing the end of that, and naming things a little better was one of the last things on my list.

After all that being said I'd be fine to change this to use ControlPlaneDetailView for the moment if you still have an issue with any of the above, but if so, I think another MADR would then be a good idea instead of flip-flopping backwards and forwards with this. This would give another opportunity to provide some technical reasoning around this rather than just "I prefer it"
Let me know either way and we can either move on here, or I can change the name, move this to a MADR around the value of namespaces and then either change it back or leave as is depending on the outcome of that.

Your arguments for why you prefer the index-style file names seem to be:

preference to defer to the containing directory as the sole name-giving element

editor configuration not allowing you to see moderately long file names

short file names being more readable than long ones

Point 1 is something that’s not impacted by different file names so it doesn’t matter if the file is called IndexView or ZoneListView
Point 2 is something that you control. You can configure your editor to show file names longer than X characters adequately. In the GitHub UI for diffs, there are always multiple places to see the file name, so should it be cut-off in some cases, it won’t prevent you from identifying what the file is about.
Point 3 is only really true in the most literal sense of being able to read and parse fewer characters more quickly. But really, a name IndexView that appears perhaps dozens of times in a code base is so much less clear than a name ZoneListView that appears once. Plus ZoneListView has the advantage that you don’t need to look at anything else to know what this file is.
Also, I very much understand that it’s possible to identify an IndexView file in purpose by looking at its containing directory and path. My point is that I shouldn’t need to look at both. Identifying files by name is easy and I don’t want to change this habit unnecessarily. File names are commonly emphasized in UIs like project-wide full-text search and command palettes. File names should be the primary identifier of the file. That also makes it much easier to move it around because moving it around shouldn’t change the meaning of its contents.
I’m going to write an MADR for this.
For now, there is no action needed here.

I’m going to write an MADR for this.

Sounds good!
Do you want me to change the name so we can merge in the meantime, or shall we wait for the MADR?
I'd prefer to change the name to here ControlPlaneDetailView at least temporarily (or maybe not) so I can merge this. I've been waiting for a good time to do this PR and its been kinda hard to find a time when its not gonna clash with other PRs, and i would want it to get in the way of anything else.
Let me know, Im good either way. Separately, ping me when that MADR is there 👍

We should generally not wait for an MADR in already on-going work so we can take our time with it.

Ok lemme change the name here so we can merge. Just in case apart from that it sounded like the rest was good to go? Shout me if there was anything else here, otherwise I'll ping you when I've changed up the name.


SLAM code cleanup and documentation clarification

README.md with working instructions for installing SLAM as a UWSGI application
slam directory renamed src
Import of uncommited changes at LAL
Add conf directory, at the same level as src, as the first location looked for configure.py
Deployment script refactoring and cleanup
Django 1.11 support (and requirement)

Ready for merging...

Really ready to merge!

Every pending issue has been fixed and the code cleanup planned is complete.

Issue found with object modification... Fix coming soon!

Issue related to an attribute name change has been fixed. The current version of this PR is now in prod at LAL.


Add ability to specify tiller namespace

I want to be able to use helmfile to talk to different instances of tillers in different namespace.  I would like to add a global flag  --tiller-namespace , to specify the namespace where tiller is located. Also if possible to have a tillerNamespace section in helmfile. That way can specify either via flag or helmfile what tiller to talk .

@rmartinez3 Hi! Thanks for the feature request 👍
Probably, adding --tiller-namespace to sync, diff, delete makes sense to me.
But FYI, I guess you can do that today with e.g. helmfile sync --args "--tiller-namespace=yourns".
I'd rather want to avoid enchancing helmfile.yml here.
The context is that, I basically like to include only declarative parts of helm releases in helmfile.yml.
--tiller-namespace seems like a part of operational knowledge - on developer's minikube you'd just want to omit tiller-namespace but in staging and prod clusters you'd want to specify the tiller-ns.
WDYT?

Hello thanks for  responding and thanks for the workaround.
Yes it  makes sense to have it added to sync , diff and delete.
As for tiller-namespace being set via helmfile. The reason I would like to have it set. Its to minimize mistakes , currently we have our own maintained helmfile repo  and will like to move back to main stream helmfile. We set the kube-context and tiller-namespace in helmfile.yaml, so that a install or upgrade via helmfile will be just referencing helmfile and values.  That way the person using helmfile wouldn't have to worry about setting tiller-namespace flag. We currently have tiller instances deployed for different teams in each cluster and helmfile helps us distinguish what to deploy to. That with rbac, having teams with their own namespaces. Setting tiller-namespace via helmfile helps out.
I did see now that labels have been added via helmfile. So something i would look into as well.

@rmartinez3 Hi. Thank you so much for the detailed explanation!
I have not yet encountered advanced use-cases like yours myself, but I believe your points are valid and very important.
Looking back, we already have an operational knowledge of "which kube-context to be used by helmin ourhelmfile.yaml. It is named context:`, which you can see from the README of this project.
That being said, how about enhancing helmfile.yaml to add more operational context to helmfile?
Currently we have:
context: kubectl-context-name

How about enhancing it so that we can pack all the operational knowledge into it:
context:
  # What exists today
  kubeContext: default
  # Your requested feature
  tillerNamespace: yourns
  # Or even more flexible one...
  args: |
    {{ if (and (eq (env "HELMEFILE_ENV") "prod") (eq (env "HELMFILE_CMD") "sync") }}--wait{{ end }}

Alternative:
How about naming context to helmOptions or even helm so that we can be explicit about what resides under the key
helm:
  args:
  - --kube-context=default
  # Your requested feature
  - --tiller-namespace=yourns
{{ if (and (eq (env "HELMEFILE_ENV") "prod") (eq (env "HELMFILE_CMD") "sync") }}  - --wait{{ end }}

Pros are that this will become completely backward-compatible change with trivial code change. It will also address issues #64 and #84 cc/ @cmeury @sstarcher

I tend to lean toward typed values instead of a generic args as that allows us to validate syntax and structure, but of course is more work for us.
Either way with that information it likely makes sense to call the key something else.

I tend to lean toward typed values instead of a generic args as that allows us to validate syntax and structure, but of course is more work for us.

Good point. It would be definitely be a good thing for users!
How about start with args and accept contribution for dedicated keys?

I like the idea of starting of with args as it will also address issues you mentioned. Accepting contributed dedicated keys will be great. Thanks again. I'll see if i get a chance to help out in this since I'm sure you guys are busy with other requests.

Hello its been a while but have time again. I would like to add dedicated keys to the helmdefault section specifically tiller-namespace. Should I add kube-context as well? I was also considering adding arg merging on helmdefault.args and --args and given dedicated keys in helm default. In which --args will take precedence as well.
Also should I update docs to include helm default and functionality?
Thanks again

If adding arg merging --args should take precedence.

Noted. Will work on this and make a pull request .

Put up pull request #186 . Let me know if there are any changes/suggestions needed to merge this .
Thanks


Add scalar functions snippets

I hope it's ok.
I have an issue with choices and placeholders in snippets coding.
for Example I Don't know how to implement correctly scalar functions like TIMESTAMP
regards
yvon

@novy400 This is awesome. Thanks a bunch for your hard work.


TextField: White background deleted from label

Description
Issue related #3486.
After researching this issue, I found two great posts to read. I feel like they are related to this issue.
1
2
I've decided to delete the white background from the input label(placeholder) box to make it looks a bit more polished for now, and also, I have a question: Is that issue can be a bug in Chromium?
"When Chrome autofills the values in the fields in the form the oninput and onfocus events are not fired. This means that the browser does not notify the fields that their values have changed and thus the floating label remains inside."
How Has This Been Tested?
none
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[x] I've added relevant tests.

@JonBunator right. The background color is needed to not see outlined like over the label. Need to think also this.

@mckaragoz this is actually solvable. The mui.com has figured it out.

The fieldset element with legend inside provides a clean solution for all backgrounds.

Heres the link: link


haskellPackages.kmonad: mark as broken on darwin

Description of changes
Related: https://github.com/NixOS/nixpkgs/pull/304640
I don't have access to MacOS, so I don't know how to actually test this (help? :)), but the error seemed obvious enough.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Darwin specific overrides should go to configuration-darwin.nix which is unconditionally applied there.

This change does appear to result in a linker failure on darwin.

Well that's very confusing… I suppose wrt https://github.com/NixOS/nixpkgs/pull/304640 we can just mark this package as broken on darwin for the time being.

@sternenseemann since I don't really have a way to test this, the sanest solution seems to be to just mark the package as broken on darwin for now.

wfm

Technically, it supports darwin… we just haven't set it up right.

Yeah, the old semantic struggle that we can’t trivially mark packages broken based on platform …