Identifying ARM platforms

There are a number of threads running on this - and after a very productive chat with a number of people at DockerCon last week and an internal review with the ARM Kernel/Distro and Toolchain team, I thought it would be useful to open the discussion here:
Firstly, the metadata in the image defines what the image contains, not what it will run on (as I have tried to express in #660).  with this in mind, the baseline metadata requirements for ARM would be:
{
  'arch': ['arm'|'arm64']  /* at some point in the future 'arm64ilp32' */
  'variant': ['6' | '7' | '8']
  'features': '...'
}

This means that for ARM, arch ~ ABI, variant ~ ISA.
We would ignore point releases of the architecture - 8.1, 8.2 etc as the extensions found can be expressed through HWCAPS and enabled in platform libraries.  Any features that are present in the binary that are not detectable through HWCAPS will need to be expressed in the platform.features field.  Neon for example is not assumed to be present in the platform, but should be runtime detectable.  If however this is not possible, the usage of Neon would have to be expressed in the platform.features field.
There would be some baseline assumptions for all platforms, as we don't believe there is a need to enable all existing ARM platforms though this mechanism.
Baseline assumptions would be:
arch = arm
arm means everything is built to run little-endian, using A32 instructions, for AArch32 execution mode, using the EABI spec, with 16 floating point registers used by the ABI, so VFP hardware must be present.
This is the same default used by debian/ubuntu 'armhf', fedora 'armv7hf', rasbian, suse and Linaro as the 32-bit ARM base ABI.  And is thus the default output of gcc targetting arm-linux-gnueabihf on those platforms [I hope - is this always true?]
It is expressed explicitly with -mfloat-abi=hard in gcc targeting arm-linux-gnueabihf (maybe some more options?)
Note that neon is not assumed to be present, and would need to be declared in features if used without runtime detection (it should always be used with runtime detection to make this moot).
https://wiki.debian.org/ArmHardFloatPort#Background_information is a useful page if you wish to understand the details of this.
Valid variants are currently '6' '7' '8'
arch = arm64
arm64 means everything is built to run little endian, using A64 instructions, for AArch64 execution mode, using the LP64 ABI.  Documentation on the ARM ABI's can be found here http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html
This is the default arm64 ABI with 64-bit longs and pointers.
Assume use of base v8 instructions only. v8.1, 8.2 etc extensions must be declared in features if not runtime detected (runtime detection should be used to avoid having to do this).
This is the same default used by debian/ubuntu 'arm64', fedora/centos/redhat 'aarch64', Suse.  And is thus the default output of gcc targetting aarch64-linux-gnu on these platforms.
Valid variants are currently '8'
arch = arm64ilp32
arm64ilp32 means everything is built to run little endian, using A64 instructions, for the AArch64 execution mode using the ilp32 ABI.
This is the rarely-used arm64 ABI using 32-bit ints, longs and pointers.
It is the default output of gcc targeting aarch64-linux-gnu_ilp32 or gcc targetting aarch64-linux-gnu with option -mabi=ilp32
Valid variants are currently '8'

Image-spec is currently punting to runtime-spec for architecture
information and punting to Go for variant information (with the
in-flight #650).  Runtime-spec is punting to Go for architecture
information.  Is there a reason for having this discussion in
image-spec instead of further upstream (e.g. in Go)?  Image-spec seems
like an odd choice for fixing “nobody identifies ARM appropriately”.
Maybe the ARM folks could publish a stand-alone ARM-identification
spec, and the OCI specs could punt to that instead of punting to Go?

The reason I bring it up here is that I spoke with a number of people at DockerCon who suggested that ARM get involved in helping to define the image-spec so that ARM platforms can be expressed properly.
I am probably missing a lot of context here, so please excuse me getting this completely wrong!
If the images are expressing what is contained within them, not the platform that they will run on, how can the runtime spec expect to explain what goes in the image metadata?  If this is the case, then an image could be marked {arch: arm, variant 8} and it could run on a platform {arch:arm64, variant: 8}.  If this is expected to be a strict pattern match, then this would not be possible?
And I am not sure I understand the logic of Go expressing the architecture information either?  Are all consumers of this spec going to build their platforms on Go?  And what if the go community decide to change the meaning of attributes.

On Fri, Apr 28, 2017 at 10:27:17AM -0700, mattspencer-arm wrote:

The reason I bring it up here is that I spoke with a number of
people at DockerCon who suggested that ARM get involved in helping
to define the image-spec so that ARM platforms can be expressed
properly.

I'm in favor of getting ARM expressed properly, both inside and
outside of image-spec.  If we have an external spec for expressing
ARM, both image-spec and other consumers (e.g. runtime-spec, Go,
package managers, …) can lean on that ARM-expression spec.  If, on the
other hand, the best ARM-expression spec was built into image-spec, I
think it's less likely that those other consumers would use it, and we
end up with https://xkcd.com/927/.

arch = arm64ilp32

This is not in the Go toolchain. They will likely add something to GOARM. It cannot appear in the GOARCH field if it is not supported by the Go toolchain.

Valid variants are currently '6' '7' '8'

The "variant" field was not at all meant to map to the GOARM field. This should contain values like "armhf" or "arm64ipl32" or whatever is required to resolve the ISA+ABI.
Rather than suggesting a mapping, it might be good for ARM to provide a topology of their requirements, describing both the ISA and ABI variation. This would allow us to design an appropriate methodology that maps to the existing fields or perhaps define new ones.

HI, I helped Matt write the doc at the top of this thread.
My understanding on this issue was that what is required is some way of expressing the contents of containers that makes long-term sense, so that builds can describe what they built, and such that clients can ask for something that will run on them. Bear in mind that whilst I have made years of messing with chroots and qemu, and architecture bootstraps in Debian, I know absolutely nothing about the world of docker, so could have erroneous assumptions.
The responses here so far talk about Go fields and toolchains. I understand that docker is written in Go, but I thought that we were talking about containers in a wider context here and thus the implementation language on one particular container image system is not the main consideration. Is there some reason why this spec will only ever be used for docker and that all possible relevant implementations will be in Go?

The "variant" field was not at all meant to map to the GOARM field.

I don't understand this comment. What 'GOARM field'?

This should contain values like "armhf" or "arm64ipl32" or whatever is required to resolve the ISA+ABI.

I understood that there are 3 fields we can use and that we need to try and fit a sensible description into those: ARCH, VARIANT, FEATURES. Is that wrong?
You suggest putting ISA+ABI into the 'variant' field, but in that case the 'arch' field is essentially wasted and you end up concatenating two things into the one VARIANT field, which makes a mess as there a lot of valid ABI+ISA variants. IMHO it makes a lot more sense to use the arch field for ARCH+ABI (as Debian does), and put the ISA level into the VARIANT field. You will have to explain to me why this is not appropriate here, and why concatenating both bits of info into one field is better.
The point being that saying that some binaries are 'x86_64' or 'i386' or 'arm' doesn't really tell you much useful unless you also take that to imply an ABI, which it is built to use.
Remember that the base ISA changes over time, unlike the ABI. An 'i386' image once used 386 instructions, but later on 486, 586, 686. All of these will run on a sufficiently-recent machine, and can interwork. This is one reason why it makes sense to specify the base ISA used in a separate field from the arch/ABI.

Rather than suggesting a mapping, it might be good for ARM to provide a topology of their requirements, describing both the ISA and ABI variation. This would allow us to design an appropriate methodology that maps to the existing fields or perhaps define new ones.

Well, I thought that's what we tried to do in the above doc, but sure, lets run at this again. We (ARM) don't have requirements as such - the requirements come from the ways people use containers and build images for them. My understanding is that clients want to be able to say 'I am a foo machine - send me an image that will run here'. People who build images want to be able to say 'this image contains stuff built like this'.
One question we had when trying to design the spec was 'do people expect to be able to download a container image and then run binaries built elsewhere on it?', to which we assumed the answer was 'no', or at least that they would use mechanisms inside the container (like distro package managers, or language ecosystem package managers) to get extra binaries, or that they would build them in-situ and thus automatically get stuff that matched.
There is lots of possible variation in ISA and ABI on ARM systems, especially older ones where all sorts of craziness went on because it was embedded-world. Fortunately if we can restrict the context to Linux images, on vaguely modern hardware (i.e. no older than the original RPi (arm v6 ISA)), then that cuts the space down to something sane, which is described at top of thread. 3 ABIs (only 2 currently in use anywhere real), and 3 base ISA levels. Not all combinations valid. Then there are various optional ISA extensions (like SSE, MMX, 386, 486, 686 in x86 world) which we assume a base level of in the default arch/ABI spec, and anything beyond that is either described in FEATURES or (much better) runtime-detected before use.
Does that all make sense?

On Wed, May 03, 2017 at 09:59:58AM -0700, Wookey wrote:

The responses here so far talk about Go fields and toolchains. I
understand that docker is written in Go, but I thought that we were
talking about containers in a wider context here and thus the
implementation language on one particular container image system is
not the main consideration. Is there some reason why this spec will
only ever be used for docker and that all possible relevant
implementations will be in Go?

The spec is intended for wider use than Go, but Go already has a way
to identify ARM platforms (using GOARCH and GOARM), and I don't see
the point of defining a new, image-spec-specific way to specify ARM
platforms.  If GOARCH and GOARM are insufficient, it would seem like
the Go folks would also be interested in adjusting their
characterization to allow more reliable compilation for ARM targets.
Instead of standardizing around Go's scheme, I'd bee fine
standardizing around Debian's scheme (or whatever).  But if every
toolset around ARM defines its own identification scheme, mapping
between the various identification schemes sounds like a lot of
trouble for no gain.

One question we had when trying to design the spec was 'do people
expect to be able to download a container image and then run
binaries built elsewhere on it?', to which we assumed the answer was
'no', or at least that they would use mechanisms inside the
container (like distro package managers, or language ecosystem
package managers) to get extra binaries, or that they would build
them in-situ and thus automatically get stuff that matched.

If the arch/variant/features tuple is sufficient to know that the
original image's binaries will run on a given host, won't it be
sufficient to specify a complication target for new binaries so a new
image (including the new binaries) will run on other hosts that
support that arch/variant/features tuple?

Fortunately if we can restrict the context to Linux images, on
vaguely modern hardware (i.e. no older than the original RPi (arm v6
ISA)), then that cuts the space down to something sane, which is
described at top of thread. 3 ABIs (only 2 currently in use anywhere
real), and 3 base ISA levels. Not all combinations valid. Then there
are various optional ISA extensions (like SSE, MMX, 386, 486, 686 in
x86 world) which we assume a base level of in the default arch/ABI
spec, and anything beyond that is either described in FEATURES or
(much better) runtime-detected before use.

Runtime-detected before use works when you have coded in a fallback
for a missing instruction.  That's great when you have one, and when
you don't you can use ‘features’.
And the ABI/ISA/extensions mapping to arch/variant/features sounds
good to me, but isn't that already what Go has 1?

GOARCH: arm, arm64, (presumably eventually arm64ilp32)
GOARM: 5, 6, 7 (they don't see a need for 8 2)

And then we punt to the Linux kernel for features like #631.  The only
difference to your proposal seems to be whether or not we need
GOARM/variant for 8.

I must reiterate again, the arch field MUST map to what is available in GOARCH. Please, please stop re-litigating this as it is not changing. It is making the conversation wildly confusing.
For the most part, we need to decide what goes in the variant field, as that is the place that is "controlled" by the platform. It should effectively encode the ABI and minimum ISA requirements. Other things, like "features", should be detected at runtime.
We can simplify this into a table. On the left, we have the name of the ABI+ISA and on the right, we have the contents of the platform fields:

ISA/ABI
Arch
Variant

Arm 32-bit, v6
arm
armv6

Arm 32-bit, v7+
arm
armhf

Arm 64-bit, v8
arm64
arm64v8

Arm 64-bit, v8, ilp32
arm64
arm64ilp32

What are we missing from the above?

I've put together a complete proposal here. Please feel free to comment.
We have the following table for the use of the variant field in ARM:

ISA/ABI
architecture
variant

Arm 32-bit, v6 (ie Raspberry Pi 1)
arm
v6

Arm 32-bit, v7
arm
v7

Arm 32-bit, v8
arm
v8

Arm 64-bit, v8
arm64
v8

PR ready: https://github.com/opencontainers/image-spec/pull/650

Should we update runtime-spec as well to remove support for pre-v6?

Should we update runtime-spec as well to remove support for pre-v6?

Where is that support specified in the runtime spec?

@stevvooe
Here: https://github.com/opencontainers/runtime-spec/blob/3908f2846586831a5b6eb38aaf6f9a4300230c71/config.md

Values for arch SHOULD use, and runtimes SHOULD understand, arch entries listed in the Go Language document for GOARCH.

But probably no need to remove pre-v6 explicitly, as you mentioned in https://github.com/opencontainers/image-spec/pull/650#discussion_r116582326

runtime-spec doesn't support such comprehensive platform yet, I've just created a PR https://github.com/opencontainers/runtime-spec/pull/830 to expand that, I think all these platform changes apply for both image-spec and runtime-spec.

@stevvooe Is v8ilp32 a valid variant?

The variant in this instance is expressing the ISA.
The architecture is the ABI.
So the correct place to express ILP32 would be as 'arch'='arm64ip32'

From: Qiang Huang<EMAIL_ADDRESS>Sent: 17 May 2017 07:43:09
To: opencontainers/image-spec
Cc: Matt Spencer; Author
Subject: Re: [opencontainers/image-spec] Identifying ARM platforms (#661)
@stevvooehttps://github.com/stevvooe Is v8ilp32 a valid variant?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/opencontainers/image-spec/issues/661#issuecomment-302000466, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Aayrr48JfbQDLRsM-OZ2T3UhrKqyJgc2ks5r6pb9gaJpZM4NLpju.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

@mattspencer-arm That's not what OCI specs defined for now, image-spec use the same semantics for arch as runtime-spec's, and we define arch should be listed in the Go language document for GOARCH in runtime-spec, which has no such arch as arm64ilp32.
If the current arch + variant is not sufficient for ARM, we probably should submit PR to Go definition or runtime-spec.

I would argue that goarch does not have an arm64ipl32 yet because ILP32 has not yet been upstreamed, and as a result there is no official support for it in go.  When ILP32 is available and go supports it, we will be pushing for it to be included as an 'arch' in go.

From: Qiang Huang<EMAIL_ADDRESS>Sent: 17 May 2017 09:17:49
To: opencontainers/image-spec
Cc: Matt Spencer; Mention
Subject: Re: [opencontainers/image-spec] Identifying ARM platforms (#661)
@mattspencer-armhttps://github.com/mattspencer-arm That's not what OCI specs defined for now, image-spec use the same semantics for arch as runtime-spec's, and we define arch should be listed in the Go language document for GOARCH in runtime-spechttps://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc5/config.md#platform, which has no such arch as arm64ilp32.
If the current arch + variant is not sufficient for ARM, we probably should submit PR to Go definition or runtime-spec.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/opencontainers/image-spec/issues/661#issuecomment-302019733, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Aayrr07aIwQYG2s2z6iTasPMasIzw2EVks5r6q0tgaJpZM4NLpju.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

@mattspencer-arm Fair, thanks for clarifying.

This can be closed now that https://github.com/opencontainers/image-spec/pull/650 has merged with @stevvooe's proposed table, right?

Is there an unambiguous way to identify a processor that runs both 32-bit and 64-bit ARM, and to distinguish it from a 64-bit only ARM system?

@AkihiroSuda I believe Resin io team make use of Docker on armv5 devices.

Is there an unambiguous way to identify a processor that runs both 32-bit and 64-bit ARM, and to distinguish it from a 64-bit only ARM system?

That isn't really the role of these fields. These are to declare minimum requirements for the image. The image may declare that it requires arm with v6 and the runtime can decide whether or not it supports that. It is implementation specific whether or not a runtime can support that or not and doesn't belong in the image format.
I am closing this since we have merged #650.


RuntimeError: mat1 and mat2 must have the same dtype

Thanks for your nice work! During running the training, I meet thre following error. Could you please help me figure it out? I have strictly follow the environment setup in the README.
Traceback (most recent call last):
  File "/home/zwang/server/Cones-V2/train_cones2.py", line 836, in <module>
    main(args)
  File "/home/zwang/server/Cones-V2/train_cones2.py", line 745, in main
    model_pred = unet(noisy_latents.float(), timesteps, encoder_hidden_states.float()).sample
  File "/home/zwang/anaconda3/envs/cones/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "/home/zwang/anaconda3/envs/cones/lib/python3.9/site-packages/diffusers/models/unet_2d_condition.py", line 574, in forward
    sample = self.conv_in(sample)
  File "/home/zwang/anaconda3/envs/cones/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "/home/zwang/anaconda3/envs/cones/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 463, in forward
    return self._conv_forward(input, self.weight, self.bias)
  File "/home/zwang/anaconda3/envs/cones/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 459, in _conv_forward
    return F.conv2d(input, weight, bias, self.stride,
RuntimeError: Input type (float) and bias type (c10::Half) should be the same

I haven't encountered a similar issue. Perhaps try resetting the accelerate config manually ?
"Do you wish to use FP16 or BF16 (mixed precision)? [NO/fp16/bf16]: No"

Thanks for response! So the training can only be run under fp32? If it is applicable for fp16 for saving memory and speedup?
As my GPU only has 24G memory, running under fp32 will cause OOM error


Error on healthCheck: x509: Can't parse "NaN" as a number

running
symbol-bootsrap healthCheck
The command output on the log is:
2022-03-13T08:35:42.590Z info User for docker resolved: 1000:1000
2022-03-13T08:35:42.591Z info Running image using Exec: symbolplatform/symbol-server:gcc-10-<IP_ADDRESS> openssl x509 -enddate -noout -in node.crt.pem -checkend NaN
2022-03-13T08:35:43.393Z info
2022-03-13T08:35:43.394Z error x509: Can't parse "NaN" as a number
x509: Invalid number "NaN" for -checkend
x509: Use -help for summary.
To Reproduce
mainnet node: conrad.symbolnode.ninja
testnet node: pequod.cola-potatochips.net
Desktop (please complete the following information):

OS: Debian 11
Tool Version: 1.1.5 linux-x64 node-v17.2.0
Docker Version: 20.10.13
Node Version: 17.2.0

same problem, running
symbol-bootstrap healthCheck
2022-04-04T19:31:52.363Z info     User for docker resolved: 1000:1000
2022-04-04T19:31:52.365Z info     Running image using Exec: symbolplatform/symbol-server:gcc-10-<IP_ADDRESS> openssl x509 -enddate -noout -in node.crt.pem -checkend NaN
2022-04-04T19:31:52.718Z info
2022-04-04T19:31:52.718Z error    x509: Can't parse "NaN" as a number
x509: Invalid number "NaN" for -checkend
x509: Use -help for summary.
Error: Cannot validate node.crt.pem certificate expiration. Expiration Date cannot be resolved. Check the logs!

after running
symbol-bootstrap renewCertificates
2022-04-04T19:31:13.693Z info     Generating config from preset 'mainnet'
2022-04-04T19:31:13.693Z info     Using assembly 'dual'
2022-04-04T19:31:13.707Z info     User for docker resolved: 1000:1000
2022-04-04T19:31:13.707Z info     Running image using Exec: symbolplatform/symbol-server:gcc-10-<IP_ADDRESS> openssl x509 -enddate -no                          out -in node.crt.pem -checkend 2592000
2022-04-04T19:31:32.936Z info     The node.crt.pem certificate for node node will expire on Nov 30 23:24:23 2022 GMT. No need to                           renew it yet.
2022-04-04T19:31:32.936Z info
2022-04-04T19:31:32.936Z info     The SSL certificates are up-to-date. There is nothing to upgrade.
2022-04-04T19:31:32.936Z info
OS: CentOS8
Version: symbol-bootstrap/1.1.6 linux-x64 node-v12.20.1

Have you done a
symbol-bootstrap config --upgrade -p mainnet -a dual -c customPreset.yml
Before running healthCheck?

Doing symbol-bootstrap config --upgrade solves the problem


Transaction demand

Hello Binance chain team.
Can you separate the build Transaction from the Tansaction signature? or export the Transaction class at /lib/index.js.
Thanks!
---From KOFO

The Transaction class is now being exported in v2.15.0, published to npm today.

The Transaction class is now being exported in v2.15.0, published to npm today.

Thanks. I have rewritten the binance SDK according to our business


File share file watcher

We have the feature for blobs to open a blob as a downloaded local file, watch changes on that file, and re-upload the updated data. We can implement its counter part for File share.

Storage explorer used to behave like this, with a dialog asking if you wanted to upload a file where it had detected a change. However this feature stopped working some time ago. When might a re-fix be released?

@stephenplant Could you please open a separate issue and provide the steps to reproduce the bug? Thanks.

Let's discuss if this can be done in v1.26.0

[ ] Create new queries after changing event names
[ ] Try to de-dupe the skip & save code
[ ] Clean up strings
[ ] Clean up blob transfer code


add packet-forward-middleware

Brief Changelog

add packet-forward-middleware
write upgrade handler for packet-forward-middleware module
write unit test for upgrade handler

Author's Checklist
run all tests passed
golangci-lint run --fix

@DongLieu can you write some tests + fill out a PR description?

I added some description
Where can I write tests, I didn't find a place to write tests for intechaintest

ok, I will edit again


content = open(filename)

when running:
hypergan train folder/hypergan/Pokemon/pokemon/main-sprites -s 32x32x3 -f png -c mymodel --resize
in ubuntu to train hypergan it starts of just fine but after a second  i givs me the error:
File "/usr/local/bin/hypergan", line 67, in
config = hc.Selector().load(config_filename)
File "/usr/local/lib/python3.5/dist-packages/hyperchamber/selector.py", line 112, in load
content = open(filename)
TypeError: invalid file: None
and just stops.
i followed the install guide.
i am new to hypergan an ubuntu in general but found hypergan so intresting that i relly wanted to use it so all help is aprechiated.
sry for bad spelling.

Oh i tried running it all as root to but it didnt make a difrence

This happens when the config file does not exist. Try a hypergan new first. Also we're close to releasing 1.0 which should give MUCH better results.


Maintain playbooks ordering and structure changes

Signed-off-by: Yussuf Shaikh<EMAIL_ADDRESS>

/cc @pravin-dsilva

/lgtm


Refused connection emits connected_to_server on client

Godot version:

3.1.1-mono
OS/device including version:

Issue description:

connected_to_server was triggered on client when server refused connection.
Steps to reproduce:
Start server with refuse_new_connections set to true.
Connect to connected_to_server on a client and let it connect.
Server ignores the connection but the client receives connected_to_server.
Minimal reproduction project:
CustomMultiplayer.zip

Btw "create_server" sets refuse_connections to false, when already done in the constructor. Would be nice to be able to set it before and keep its value.

Added minimal project

I think I understand what's happening.
In general, ENet always accepts new connections, and we emit the signal when ENet notifies that the client has connected to the server.
The server, when refusing connections, will then reset the peer, not notifying it of disconnection, and the client will simply timeout after a while (but not immediately call server_disconnected).
This will need some work to be properly addressed. Pushing to 4.0.

Can anyone still reproduce this bug in Godot 3.2.3 or any later release?

Yes, I can.

I still have this problem. Why did you push to 4.0? From my perspective this is a bug and could be solved in a minor version.

Also reported here
https://github.com/godotengine/godot/issues/48759
@Icaro-Lima bugs are listed for 4.x first and then backported to 3.x

@tavurth Thanks for the clarification!

Still encountering this problem in v4.1.2.stable.official [399c9dc39]
This gives connecting clients a false positive which makes the player wait for about 30 seconds until they can be served the DC error. Pretty bad UX.

Still encountering this problem in v4.1.2.stable.official [399c9dc]
This gives connecting clients a false positive which makes the player wait for about 30 seconds until they can be served the DC error. Pretty bad UX.
edit: can be mitigated by adjusting network/limits/tcp/connect_timeout_seconds in project settings.

I would actually suggest changing the timeout during the initial connect, and then increasing it if it does succeed so that later on you can withstand a temporary network issue instead of a single hiccup triggering a total disconnect/desync.
var peer = new ENetMultiplayerPeer();
var error = peer.CreateClient(ipAddress, port);
// making the timeout short lets us quickly detect if a connection doesn't work

 foreach (var p in peer.Host.GetPeers())
 {
     p.SetTimeout(500, 1000, 2000);
 }

then later raise it. I always suggest people have an rpc for the client to trigger connected to ConnectedToServer that acts as a little "hello I'm ready" call. This can include client data or auth information too, like the client's desired name/color, the password they entered etc. The server can then decide to let them proceed. If your server is refusing connections, the client's rpc call will fail and the client times out anyway.

Guys, will this issue get some love?
Still experiencing false positive in 4.3 beta2.
Like in situation when you create_server() then let clients join you, then when max player count is reach you set multiplayer.multiplayer_peer.refuse_new_connections=true on the game host. But if new player/peer tries to create_client() he will not error out and will just create his own game..
How do i limit player ability to join game when i reach max number of clients?
Also peer.create_server(port, max_clients) -> the max_clients cvar is not enforced, and i can join the game way past the max value :(..
Here in the example i have host + 1 + 1 = 3 players but i had created server with 2 as max player cvar.
The 4th player tried to create_client() but i guess he got refused (i dont know how to handle the refusion on client side, and if its even possible) so he just created his own server, but without the "1" peer.
In the player list tab you see player_name:peer_unique_id

How to enforce ability for players to not join a game if the host peer is set to refuse new conenctions, and why max player varriable is not enforced?


Globalizing organism traits prevents successful importing.

Organisms need to import one another to interact, but because the organisms' traits are global variables, when, for example an organism tries to make another move, it ends up moving itself, because the name and metabolism are pulled from the aggressor instead of the fleeing organism.
Functions should either pass variables explicitly, or the global creation function should be called on any interaction function call.

The solution: each file is also given a class, and the the variables are made class variables.


Add saved_games_folder param

This helps me whenever I have to re-run the auto-settings, since my default folder is different than the one that this bot uses:
C:\Users\cesar\Saved Games\Diablo II Resurrected -> my saved games folder
C:\\Users\\cesar-local\\Saved Games\\Diablo II Resurrected -> botty's default saved games folder
os.getlogin() differs from my user folder. I'm not sure why this happens, so I came up with this implementation under the [general] settings in params.ini.

Thx for the PR. Looks good. Only thing missing would be a short documentation in the readme.md.

Doing it right now!

done


python3Packages.twinkly-client: init at 0.0.2

Motivation for this change
Python module to communicate with Twinkly LED strings
https://github.com/dr1rrb/py-twinkly-client
This is a Home Assistant dependency.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 113785 run on x86_64-linux 1

3 packages built:

python37Packages.twinkly-client
python38Packages.twinkly-client
python39Packages.twinkly-client

Result of nixpkgs-review pr 113785 at 2d7784c9 run on aarch64-linux 1

3 packages built:

python37Packages.twinkly-client
python38Packages.twinkly-client
python39Packages.twinkly-client

@fabaff please resolve the merge conflict.

@fabaff please resolve the merge conflict.

@SuperSandro2000, done.


closes Iss 338 - removed "national/state" verbiage from search results

closes Iss 338 - removed "national/state" verbiage from search results

Alex approved. Merging.


turn off editing

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

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

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


DBus Issue

I get the following error when I run jrnl with Python 2.7.13 on my updated Fedora 25 machine. It only seems to happen when I am editing an encrypted journal, though I did notice that no editor is opened when I run jrnl by itself to edit the default journal, even though vim is set as my editor and it used to work normally.
$ jrnl --edit encrypted_journal.txt
Traceback (most recent call last):
  File "/usr/bin/jrnl", line 11, in <module>
    load_entry_point('jrnl==1.9.8', 'console_scripts', 'jrnl')()
  File "/usr/lib/python2.7/site-packages/jrnl/cli.py", line 194, in run
    journal = Journal.Journal(journal_name, **config)
  File "/usr/lib/python2.7/site-packages/jrnl/Journal.py", line 39, in __init__
    self.open()
  File "/usr/lib/python2.7/site-packages/jrnl/Journal.py", line 105, in open
    journal = util.get_password(keychain=self.name, validator=validate_password)
  File "/usr/lib/python2.7/site-packages/jrnl/util.py", line 37, in get_password
    pwd_from_keychain = keychain and get_keychain(keychain)
  File "/usr/lib/python2.7/site-packages/jrnl/util.py", line 56, in get_keychain
    return keyring.get_password('jrnl', journal_name)
  File "/usr/lib/python2.7/site-packages/keyring/core.py", line 42, in get_password
    return _keyring_backend.get_password(service_name, username)
  File "/usr/lib/python2.7/site-packages/keyring/backends/SecretService.py", line 58, in get_password
    collection = self.get_preferred_collection()
  File "/usr/lib/python2.7/site-packages/keyring/backends/SecretService.py", line 50, in get_preferred_collection
    collection.unlock()
  File "/usr/lib/python2.7/site-packages/secretstorage/collection.py", line 63, in unlock
    return unlock_objects(self.bus, [self.collection_path], callback)
  File "/usr/lib/python2.7/site-packages/secretstorage/util.py", line 168, in unlock_objects
    return exec_prompt_glib(bus, prompt)[0]
  File "/usr/lib/python2.7/site-packages/secretstorage/util.py", line 134, in exec_prompt_glib
    exec_prompt(bus, prompt, callback)
  File "/usr/lib/python2.7/site-packages/secretstorage/util.py", line 122, in exec_prompt
    prompt_iface.connect_to_signal('Completed', new_callback)
  File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 544, in connect_to_signal
    dbus_interface, **keywords)
  File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 369, in connect_to_signal
    **keywords)
  File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 148, in add_signal_receiver
    path, **keywords)
  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 400, in add_signal_receiver
    self._require_main_loop()
RuntimeError: To make asynchronous calls, receive signals or export objects, D-Bus connections must be attached to a main loop by passing mainloop=... to the constructor or calling dbus.set_default_main_loop(...)

This is what my .jrnl_config looks like.
  "default_hour": 9,
  "timeformat": "%Y-%m-%d %H:%M",
  "linewrap": 79,
  "encrypt": true,
  "editor": "vim",
  "default_minute": 0,
  "highlight": true,
  "journals": {
    "default": "/home/paul/writing/thoughts.text"
  },
  "tagsymbols": "@"
}

I completely reinstalled jrnl, but nothing was fixed:
$ pip2 install "jrnl[encrypted]" --ignore-installed --upgrade
Collecting jrnl[encrypted]
  Using cached jrnl-1.9.8.tar.gz
Collecting parsedatetime>=1.2 (from jrnl[encrypted])
  Using cached parsedatetime-2.3-py2-none-any.whl
Collecting pytz>=2013b (from jrnl[encrypted])
  Using cached pytz-2016.10-py2.py3-none-any.whl
Collecting six>=1.6.1 (from jrnl[encrypted])
  Downloading six-1.10.0-py2.py3-none-any.whl
Collecting tzlocal>=1.1 (from jrnl[encrypted])
  Using cached tzlocal-1.3.tar.gz
Collecting keyring>=3.3 (from jrnl[encrypted])
  Using cached keyring-10.3-py2.py3-none-any.whl
Collecting python-dateutil==1.5 (from jrnl[encrypted])
  Using cached python-dateutil-1.5.tar.gz
Collecting pycrypto>=2.6 (from jrnl[encrypted])
  Using cached pycrypto-2.6.1.tar.gz
Collecting future (from parsedatetime>=1.2->jrnl[encrypted])
  Using cached future-0.16.0.tar.gz
Collecting secretstorage; sys_platform == "linux2" or sys_platform == "linux" (from keyring>=3.3->jrnl[encrypted])
  Using cached SecretStorage-2.3.1.tar.gz
Collecting cryptography (from secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached cryptography-1.8.1.tar.gz
Collecting idna>=2.1 (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached idna-2.5-py2.py3-none-any.whl
Collecting asn1crypto>=0.21.0 (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached asn1crypto-0.21.1-py2.py3-none-any.whl
Collecting packaging (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached packaging-16.8-py2.py3-none-any.whl
Collecting setuptools>=11.3 (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached setuptools-34.3.2-py2.py3-none-any.whl
Collecting enum34 (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached enum34-1.1.6-py2-none-any.whl
Collecting ipaddress (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached ipaddress-1.0.18-py2-none-any.whl
Collecting cffi>=1.4.1 (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached cffi-1.9.1-cp27-cp27mu-manylinux1_x86_64.whl
Collecting pyparsing (from packaging->cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached pyparsing-2.2.0-py2.py3-none-any.whl
Collecting appdirs>=1.4.0 (from setuptools>=11.3->cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached appdirs-1.4.3-py2.py3-none-any.whl
Collecting pycparser (from cffi>=1.4.1->cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring>=3.3->jrnl[encrypted])
  Using cached pycparser-2.17.tar.gz
Installing collected packages: future, parsedatetime, pytz, six, tzlocal, idna, asn1crypto, pyparsing, packaging, appdirs, setuptools, enum34, ipaddress, pycparser, cffi, cryptography, secretstorage, keyring, python-dateutil, pycrypto, jrnl
  Running setup.py install for future ... done
  Running setup.py install for tzlocal ... done
  Running setup.py install for pycparser ... done
  Running setup.py install for cryptography ... done
  Running setup.py install for secretstorage ... done
  Running setup.py install for python-dateutil ... done
  Running setup.py install for pycrypto ... done
  Running setup.py install for jrnl ... done
Successfully installed appdirs-1.4.3 asn1crypto-0.21.1 cffi-1.9.1 cryptography-1.8.1 enum34-1.1.6 future-0.16.0 idna-2.5 ipaddress-1.0.18 jrnl-1.9.8 keyring-10.3 packaging-16.8 parsedatetime-2.3 pycparser-2.17 pycrypto-2.6.1 pyparsing-2.2.0 python-dateutil-1.5 pytz-2016.10 secretstorage-2.3.1 setuptools-34.3.2 six-1.10.0 tzlocal-1.3

Could you try and run pip install -U keyring and see if this changes anything?

Nothing changed.
$ pip install -U keyring
Requirement already up-to-date: keyring in /usr/lib/python3.5/site-packages
Requirement already up-to-date: secretstorage; sys_platform == "linux2" or sys_platform == "linux" in /usr/lib/python3.5/site-packages (from keyring)
Requirement already up-to-date: cryptography in /usr/lib64/python3.5/site-packages (from secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: idna>=2.1 in /usr/lib/python3.5/site-packages (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: asn1crypto>=0.21.0 in /usr/lib/python3.5/site-packages (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: packaging in /usr/lib/python3.5/site-packages (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: six>=1.4.1 in /usr/lib/python3.5/site-packages (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: setuptools>=11.3 in /usr/lib/python3.5/site-packages (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: cffi>=1.4.1 in /usr/lib64/python3.5/site-packages (from cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: pyparsing in /usr/lib/python3.5/site-packages (from packaging->cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: appdirs>=1.4.0 in /usr/lib/python3.5/site-packages (from setuptools>=11.3->cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)
Requirement already up-to-date: pycparser in /usr/lib/python3.5/site-packages (from cffi>=1.4.1->cryptography->secretstorage; sys_platform == "linux2" or sys_platform == "linux"->keyring)

Ah, looks like this is a known issue (see jaraco/keyring#223) in the secretstorage module, which keyring depends on (the module that manages storing your password in your key chain. Here's how to fix it:
pip install dbus-python

Does that work for you?

Installing dbus-python resulted in this:
Collecting dbus-python
  Using cached dbus-python-1.2.4.tar.gz
Installing collected packages: dbus-python
  Running setup.py install for dbus-python ... done
Successfully installed dbus-python-1.2.4

I noticed that running jrnl --edit on an encrypted journal no longer causes the error, but it also does not bring up my editor. jrnl -n # still causes the same error.

After doing all of the things listed here, I got different results. Running jrnl --edit resulted in a prompt asking me to create a password, and I'm now able to use jrnl fully as intended using that password. I'm surprised it doesn't work for @woo2, but...best of luck, I guess.

uninstalling and then reinstalling jrnl fixed this for me.
just run sudo pip uninstall jrnl
then run sudo pip install jrnl

Does this still happen with v2.0? We've dropped Python 2 support, so it would be helpful is someone can confirm if this still happens with Python 3 on Jrnl 2.0+

The computer I was experiencing this on is in storage for another month, I
can report back then.
On Sat, Jul 20, 2019 at 1:43 PM Jonathan Wren<EMAIL_ADDRESS>wrote:

Does this still happen with v2.0? We've dropped Python 2 support, so it
would be helpful is someone can confirm if this still happens with Python 3
on Jrnl 2.0+
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jrnl-org/jrnl/issues/478?email_source=notifications&email_token=AAGSXOY2UATTQXJPXK3H3YTQAN2HBA5CNFSM4DDPFUP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NVVQA#issuecomment-513497792,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGSXO6MKA55LJWXLG7AP7LQAN2HBANCNFSM4DDPFUPQ
.


'cassandra-cli.bat' is not recognized as an internal or external command

Running C* 2.1.9 cluster on windows. Doesn't cli work on windows? Or am I missing something?
$ ccm node1 cli
$ 'cassandra-cli.bat' is not recognized as an internal or external command,
operable program or batch file.

Thanks,
Dinesh

The cli doesn't work on windows.

Thanks @ptnapoleon for your quick response.


Add SDE_INSTALL_DIR check

Generate fatal error if SDE_INSTALL_DIR is not defined.

change LGTM, should we be checking other variables as well which are derived from env variables, say DEPEND_INSTALL?

Not necessarily. I just remembered why I didn't require that the various xxxx_INSTALL_DIR variables be defined.
The original premise was that all the packages would be installed to the same directories. I introduced support for separate directories, partly to make it easier to work on one package at a time during development, and partly to support Google's recommendation that gRPC and Protobuf not be installed to system directories.
There are also a couple of use cases that don't necessarily require the full build infrastructure. It is currently possible to build and run the kernel monitor unit tests with nothing but target-syslibs. (Once we add switchlink_db unit testing, we will also need tommyds, which is part of target-utils.)
If we're not careful, we'll end up burdening simple tasks with the weight of the entire build. I'm not convinced that requiring something we don't actually need is better than erroring out with an undefined library.

make-all.sh checks if _SDE_DIR is non-empty but doesn't check _DEPS_DIR even though the build depends on both. Thoughts?

Stratum is no longer an optional component. I think it's safe to say that P4 Control Plane is inherently dependent on the Stratum dependencies.
It costs us little at build time to be dependent on the SDE and Stratum dependencies. These dependencies are built and installed independently of the P4 Control Build.
The real build-time cost is in the number of source files (especially C++ and Protobuf) we have to compile. The optimizations in the kernel monitor testing path come from our target selection and the number of P4 Control Plane source files the targets require. The SDE and Stratum dependencies don't figure into this.
There is therefore no real risk in requiring that DEPEND_INSTALL be defined.
And in the event that the original scenario occurs (SDE and Stratum dependencies share an install tree), we should be able to finesse the check by setting SDE_INSTALL and DEPEND_INSTALL to the same file path.
I will amend the PR to perform a second check.

Well-spotted and well-argued, by the way.


Add possibility for resource-intensive tests to be skipped

Tests that compile a circuit and generate proofs are sometimes not feasible during development and on local machines.
Therefore we should add a option to execute only the tests, that do not compile/prove

Related to #25


Create prime_no_or_not.java

A code to check whether the input number is prime number or not with the help of java language.

github username- ADVOLT
DATE- 12/10/2024
AIM- to create a code in java to check whether the number is prime or not using java.


Add support for extra arguments for falcosidekick chart

What type of PR is this?
/kind feature
/kind chart-release
Any specific area of the project related to this PR?
/area falcosidekick-chart
What this PR does / why we need it:
This PR add support for extra args for falcosidekick chart. This allows specifying a config file for falcosidekick for situations when relying on environment variables is not possible (e.g. settings which contain confidential values which are injected into a file).
This is useful when secrets are loaded into pods with Hashicorp Vault's Agent sidecar injector.
A possible usage in falco's values.yaml file is:
falcosidekick:
  enabled: true
  config:
    extraArgs:
      - -c
      - /a/b/c/config.yaml

This loads the config.yaml file located at /a/b/c/config.yaml for falcosidekick.
Which issue(s) this PR fixes:
No issue is opened for this PR
Special notes for your reviewer:
I've bumped the falcosidekick chart version to 0.7.7 and the falco chart to 3.8.3 (to update the referenced falcosidekick version).
Checklist

[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] CHANGELOG.md updated

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

7a6efbb feat(falcosidekick): support extra args in the chart
1efa8eb chore(falco): Upgrade falcosidekick chart to v0.7.7

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.

Welcome @ogercyprien! It looks like this is your first PR to falcosecurity/charts 🎉

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: ogercyprien
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

You can't update all the charts in the same PR, can you scope to falcosidekick only please

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Issif, ogercyprien
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:

OWNERS [Issif]

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

LGTM label has been added.  Git tree hash: 1caeb378e7585c062b7a7f32f56d4e8b06c04cec


Use a single unique timestamp across scala versions per snapshot publish

As discussed in https://github.com/apache/incubator-pekko/issues/104#issuecomment-1384503408, due to a current limitation in sbt, when doing a cross publish amongst Scala versions using the + prefix it generates a separate timestamp for each Scala version where as ideally we should have a unique timestamp for an entire single publish operation.
A workaround as described in https://stackoverflow.com/a/21062454/1519631 is to pre-save the unique timestamp to a file and then read that timestamp along with a custom command alias.

So since this is blocking a few things from pekko-http's side I have labelled this as a bug

The timestamp shouldn't be part of the artifact version. It is only added when the workspace is not clean. Otherwise, it will only be the commit id.

@jrudolph This discussion is of relevance https://github.com/apache/incubator-pekko/pull/105#discussion_r1071912938 to your point. Currently @seglo set up nightlies which do contain a timestamp (which for a nightly makes sense) but I also want to setup snapshots which as you point out wouldn't need timestamp id's, but we need a strategy here because there is massive overlap between nightlies and snapshots (in my view nightlies are snapshots, just a specific way of handling them).

Indeed, I think the timestamp is currently included in the nightlies because the current main is not clean and while building the git workspace is changed, see
https://github.com/apache/incubator-pekko/actions/runs/3982251774/jobs/6826550691#step:4:173
and following.
Regarding, snapshots vs. nightlies, I agree. There's two potential solutions:

Either, push snapshots from nightlies, make sure to run only once per version on main
or, push snapshots for every commit and use nightlies only for more extensive testing than would be possible for each commit

I think we used the second option at least in akka-http.

because the current main is not clean

The reason is probably that PR validation is not run for every Scala version (or at least headerCheck / scalafmtCheckAll).

pekko > +headerCheck
[info] Setting Scala version to 2.12.16 on 40 projects.
[info] Excluded 2 projects, run ++ 2.12.16 -v for more details.
[info] Reapplying settings...
[...]
[error] There are files without headers!
[error]   /home/johannes/git/opensource/pekko/actor-typed/src/main/scala-2.12/org/apache/pekko/actor/typed/internal/receptionist/Platform.scala
[error] There are files without headers!
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ByteString.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ByteIterator.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/compat/Future.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ccompat/package.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/dispatch/internal/ScalaBatchable.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/dispatch/internal/SameThreadExecutionContext.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ccompat/CompatImpl.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/compat/PartialFunction.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ccompat/ccompatUsedUntil213.scala
[error] There are files without headers!
[error]   /home/johannes/git/opensource/pekko/cluster-typed/src/main/scala-2.12/org/apache/pekko/cluster/typed/internal/receptionist/ClusterReceptionistProtocol.scala
[error] (actor-typed / Compile / headerCheck) There are files without headers!
[error]   /home/johannes/git/opensource/pekko/actor-typed/src/main/scala-2.12/org/apache/pekko/actor/typed/internal/receptionist/Platform.scala
[error] (actor / Compile / headerCheck) There are files without headers!
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ByteString.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ByteIterator.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/compat/Future.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ccompat/package.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/dispatch/internal/ScalaBatchable.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/dispatch/internal/SameThreadExecutionContext.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ccompat/CompatImpl.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/compat/PartialFunction.scala
[error]   /home/johannes/git/opensource/pekko/actor/src/main/scala-2.12/org/apache/pekko/util/ccompat/ccompatUsedUntil213.scala
[error] (cluster-typed / Compile / headerCheck) There are files without headers!
[error]   /home/johannes/git/opensource/pekko/cluster-typed/src/main/scala-2.12/org/apache/pekko/cluster/typed/internal/receptionist/ClusterReceptionistProtocol.scala
[error] Total time: 0 s, completed Jan 23, 2023 1:44:47 PM
pekko >

Just to clarigy regarding scamafmtCheckAll, this has been removed because instead are using a github actions that runs a native GraalVM binary version of scalafmt, the reason to do this is because of developer ergonomics and speed (the idea with the github action is that it will be a mandated check before merging a PR).

the idea with the github action is that it will be a mandated check before merging a PR

Yes, it should be a mandatory check but it also needs to be able to pick up all the relevant paths from sbt and don't think that will work right now with a project as complex as pekko. If we really care for speed in that particular case, we can cache the sbt cache of scalafmt in the Action, so it does not rerun on file versions seen before.

Yes, it should be a mandatory check but it also needs to be able to pick up all the relevant paths from sbt and don't think that will work right now with a project as complex as pekko.

It does actually pick up everything relevance, I actually checked. The part of the code that checks which paths are being formatted are part of core scalafmt which is defined in .scalafmt.conf and is common between scalafmt, sbt-scalafmt and scalafmt-native (this in fact was a deliberate decision by the devs of the latest 3.x version of scalafmt)

If we really care for speed in that particular case, we can cache the sbt cache of scalafmt in the Action, so it does not rerun on file versions seen before.

At least for me, caching wouldn't solved the speed issue that I was experiencing the most. Its having to run scalafmt every time on small incremental changes. The current scalafmt github action typically takes 5-10 seconds to complete on the CI and also runs concurrently from the rest of the build.
I think this is going a bit offtopic though, feel free to make a thread on the dev mailing list where we can discuss this specifically

That is it doesn't matter how scalafmt is run, whether its via sbt or on the cli with the JVM scalafmt runner or a GraalVM scalafmt, the results will be deterministic (and this to me is a feature, not a bug).

:+1: I see, we are using --mode diff which should be good enough for PR validation (as long as you cannot slip files past the PR check). Sorry for the noise.
I created #125 to run headerCheck on all Scala versions.

an untidy but workable solution to unblock work on pekko-http, etc. - https://github.com/pjfanning/micrometer-akka/pull/3/files#diff-5634c415cd8c8504fdb973a3ed092300b43c4b8fc1e184f7249eb29a55511f91R34-R43

So the problem here is that pekk-http already happens to have a custom built code for handling snapshots and at least currently I am unsure if I want to rip it all out/modify it, you can see it at https://github.com/apache/incubator-pekko-http/blob/main/project/AkkaDependency.scala, I wanted to ask @jrudolph about this to get the context of whats going on.

The last nightly snapshot was now generated without the timestamp (after
fixing the headers).
Matthew de Detrich @.***> schrieb am Mo., 23. Jan.
2023, 17:27:

an untidy but workable solution to unblock work on pekko-http, etc. -
https://github.com/pjfanning/micrometer-akka/pull/3/files#diff-5634c415cd8c8504fdb973a3ed092300b43c4b8fc1e184f7249eb29a55511f91R34-R43
So the problem here is that pekk-http already happens to have a custom
built code for handling snapshots and at least currently I am unsure if I
want to rip it all out/modify it, you can see it at
https://github.com/apache/incubator-pekko-http/blob/main/project/AkkaDependency.scala,
I wanted to ask @jrudolph https://github.com/jrudolph about this to get
the context of whats going on.
—
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-pekko/issues/107#issuecomment-1400631012,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAACNDCMWPK2ETK2JHVXVFLWT2WPDANCNFSM6AAAAAAT5DWZUA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@pjfanning In practice I would say this isn't really a blocker for the v1.0.0-M0 release because this behaviour only occurs when a version is derived from a state when pullRequestValidation fails which has now been solved thanks to @jrudolph .
For this reason its not really blocking anything as of now, I would only see this as being useful when we end up implementing the functionality to create snapshots from an ongoing unmerged PR but I would consider this as a nice to have to implement sometime in the future.
Do you agree to remove this from the milestone?

@mdedetrich is this closeable?

Yes


Compare changes across branches, commits, tags, and more below. If you need to

Q
A

Fixed Issues
Fixes #1, Fixes #2

Patch: Bug Fix?

Major: Breaking Change?

Minor: New Feature?

Tests Added/Pass?

Spec Compliancy?

License
MIT

Doc PR

Any Dependency Changes?

Codecov Report

Merging #549 into master will decrease coverage by 0.00%.
The diff coverage is 25.00%.

@@            Coverage Diff             @@
##           master     #549      +/-   ##
==========================================
- Coverage   91.79%   91.78%   -0.01%
==========================================
  Files         435      435
  Lines       27376    27378       +2
  Branches     8245     8246       +1
==========================================
+ Hits        25129    25130       +1
- Misses       2217     2218       +1
  Partials       30       30

Impacted Files
Coverage Δ

...babel-plugin-syntax-module-attributes/src/index.js
0.00% <0.00%> (ø)

packages/babel-standalone/src/preset-stage-0.js
0.00% <0.00%> (ø)

...ckages/babel-standalone/src/transformScriptTags.js
0.00% <0.00%> (ø)

...ckages/babel-preset-env/src/plugins-compat-data.js
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


FIX: Remove Conda Store from default images

Fixes #1104

Hi @danlester
[terraform]: │ Error: Reference to undeclared input variable
[terraform]: │
[terraform]: │   on modules/kubernetes/services/conda-store/worker.tf line 101, in resource "kubernetes_deployment" "worker":
[terraform]: │  101:           image = "${var.conda-store-image.name}:${var.conda-store-image.tag}"
[terraform]: │
[terraform]: │ An input variable with the name "conda-store-image" has not been declared.
[terraform]: │ This variable can be declared with a variable "conda-store-image" {} block.
[terraform]: ╵

Problem encountered: Terraform error

It seems like we would have to anyway have a Terraform variable here and we cannot remove the duplication entirely. We can possibly revisit it at some other time.


libreoffice constant high cpu usage.

Issue description
libreoffices cpu usage is constantly on 100% (one core).
Steps to reproduce
$ libreoffice
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
look with a taskmanager at libreoffices cpu usage.
Technical details
libreoffice-<IP_ADDRESS>

system: "x86_64-linux"
host os: Linux 4.14.27, NixOS, 18.03pre131327.0e7c9b32817 (Impala)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 2.0
channels(mcd): ""
channels(root): "nixos-18.03pre131327.0e7c9b32817, nixos-1709-17.09.3194.edf1079d43f"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

Hm. Setting JAVA_HOME fixes the javaldx problem, but not the CPU consumption itself

Try executing with the environment
SAL_USE_VCLPLUGIN=gen

this avoids the issue on my system. From what I recall the issue is with the current version of glib.

@coreyoconnor yes, that fixes it.

Is it time to create a LibreOffice wrapper then? JAVA_HOME, SAL_USE_VCLPLUGIN, starting DBus if not already running…

I was unaware of "JAVA_HOME". Definitely for that one.
As for SAL_USE_VCLPLUGIN. That may indicate a bug in glib that effects other applications and should be patched in glib.  Pulling back up the history of why I did that:

https://bugs.archlinux.org/task/57036
notes the issue started with a recent glib release
https://bugzilla.gnome.org/show_bug.cgi?id=761102#c53
long discussion. big mess.
arch and fedora appear to be releasing patched glibs?
not resolved in upstream glib?

Not sure what glib is TBH. Is that "gnulib" in nixpkgs?

glib is the basic library for GTK that defines the GTK object system (GTK is written in C but it is very object-oriented), wrappers for things like input-output (I think GIO did not get separated from glib), timers, etc.
If it is unclear what breaks what, we can either take a patch from some distribution that does patch that, or start with a wrapper and then hope next GNOME release ships a better glib

Same issue here, the SAL_USE_VCLPLUGIN=gen workaround fixes it too.

IMO, given the stance of making it work "as expected" for end users: add to a wrapper now.

I have just pushed a wrapper into master. Any testers? (No LibreOffice rebuild needed, the wrapper is a separate derivation)

Can confirm on master there doesn't seem to be the 100% CPU usage issue any longer. Thanks! :grinning:

This is indeed fixed in master; could this fix be backported to 18.03 ?

OK, picked.

Ah, so a fake system bus is not needed when session bus exists, and is even actively harmful. I think I have pushed a fix to master (only the wrapper is rebuilt) to ignore the idea of system bus completely, could you try it? It works on my no-running-DBus system.

e471376982d5c404c0d5fb376f1e48fa4b7859ba didn't solved the font problem for me.

Can confirm, the font problem is the same as of master today @ a5ae3b57314. The DBus error messages are gone though. I looked into it a little more, SAL_USE_VCLPLUGIN is for setting the windowing toolkit to get the theme from. See here. So setting it to gen means no theme, and we shouldn't be surprised the fonts are wrong.
I'm not seeing high CPU usage when running LibreOffice, regardless of if I use the wrapper or not. GLib was upgraded from 2.54.3 to 2.56.0 in 0973618e4ec61578de2eaf5531d4be661e4fa20a, which wasn't in the version of nixpkgs @castilma was using when reporting this. So it's possible the original issue is fixed now and we can drop the wrapper. I never saw the problem in the first place though.

@castilma is the CPU problem still there without the wrapper?
@enolan I would keep the wrapper because of Java (and in rare circumstances DBus) but drop SAL_USE_VCLPLUGIN if it is not needed anymore.

how do I install the unwrapped version?
I have the wrapped /nix/store/gps4y0fnlsl8lshps3zpiy976147v4ph-libreoffice-<IP_ADDRESS>/bin/libreoffice in my profile. and this file calls  /nix/store/1nv742r3m75iljjpbd1mvrmzh6fj14mj-libreoffice-<IP_ADDRESS>/bin/libreoffice. invoking the second one directly still shows the problem.

Well, if this is a new enough version, that means that your system still
needs the wrapper.
You could install by using
nix-env -iA libreoffice.libreoffice
which should give you the same executable as you have launched after
inspecting the wrapper script.

It seems to me like it would be best to revert the wrapper; the cure for the high CPU usage issue seems far worse than the disease. The interface is quite unusable due to the theme issues introduced by the wrapper.

@bgamari if you use the unwrapped libreoffice.libreoffice version, does the original issue even happen for you?

@7c6f434c  I can't get Writer over 1% no matter what, in Calc I can go as "high" as 5% by dragging a semi-difficult formula to the thousands, but it sits at 1% at idle as well, so nothing I would even remotely call a bug.
I also think the wrapper should be reverted as soon as possible because without installing libreoffice.libreoffice this package is unusable and it's difficult to find this issue with keywords like "no theme libreoffice" to solve the problem.

… so that means that we have two types of setups, one where LibreOffice is unusable without wraper and one where it is unusable with wrapper? @castilma anything you can guess about your DE etc.?

Also, @castilma could you try running LibreOffice (unwrapped) in a more or less minimal environment, maybe nix-shell --pure? Is the problem still there?

guess about my DE? well, I guess it's xfce.
libreoffice after nix-shell --pure -p libreoffice.libreoffice still has the problem.
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.37, NixOS, 18.03.132192.ce0d9d638de (Impala)`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.0.1`
 - channels(mcd): `""`
 - channels(root): `"nixos-18.03.132192.ce0d9d638de"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs`

Heres my system configuration.
configuration.nix.gz

Well, I wondered if you could guess what else about your environment could be relevant.
Hopefully the wrapper can be adjusted to make sure it only sets the nuclear options in the case where it is needed.

Doesn't seem to happen in a VM built from that configuration…

I have also observed the high CPU usage. I've not looked into it as I generally avoid using Libreoffice when possible.
However, in general I would prefer a warm lap but usable Libreoffice than a cool lap but unreadable interface. :)

What separately annoys me is that the problem seems non-trivial to reproduce…

FWIW I also had the 100% CPU problem.  However now I can no longer reproduce it using either libreoffice.libreoffice or libreoffice-fresh.libreoffice.

(in the meantime, I commented out the toolkit override in the wrapper, but preserved the DBus fallback)

Is anybody still seeing this?

I'm still seeing this, on current 18.03. The SAL_USE_VCLPLUGIN workaround worked well.

I'm also still seeing this on current 18.03. However, the SAL_USE_VCLPLUGIN workaround doesn't work for me as it messes up the fonts.

Does setting SAL_USE_VCLPLUGIN to gtk or kde give you both fonts and normal CPU usage? If it doesn't help, could you try to set OOO_FORCE_DESKTOP to none but SAL_USE_VCLPLUGIN to gtk or something like that.

On my system, SAL_USE_VCLPLUGIN=kde seems to do nothing (it behaves the same as not setting SAL_USE_VCLPLUGIN).
SAL_USE_VCLPLUGIN=gtk changes to a different and usable theme, but the 100% CPU usage remains.
SAL_USE_VCLPLUGIN=gen changes to a different but unusable/ugly theme. The 100% CPU usage disappears.
OOO_FORCE_DESKTOP=none, with or without setting SAL_USE_VCLPLUGIN apparently has no effect either on the theme or on the CPU usage.
BTW, this issue is 100% reproducible for me. The 100% CPU usage begins immediately after starting libreoffice.

Hm. OK, thanks. Interesting. I still have no idea how to fix/work-around this issue…

Let's see if #68414 fixes it.

No activity in a while - please reopen if the problem persists.


🐛 BUG: Can't create project in Cloudflare pages.

Which Cloudflare product(s) does this pertain to?
Pages, Wrangler
What version of Wrangler are you using?
3.1.0
(and 3.0.1)
What operating system are you using?
Windows
Describe the Bug
Can't create new project in Cloudflare pages since few minutes.
It's happening both Wrangler and website.
If my account's limit to create project, please close this issue.
However, In the last few months I've only created one yesterday, I don't think that would.
It may be resolved if I wait for a while, but I contacted you for an early resolution.
Error message:
X [ERROR] Received a malformed response from the API

<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en-US"> <![endif]-->
<!--[if I... (length = 6533)
POST /accounts/***/pages/projects -> 504 Gateway Time-out

I just tried it, and I was able to create a new project!
Thank you, please close the issue.


Updating tutorial to match source

Most of the details are captured in this comment: https://github.com/kubernetes/examples/pull/410#issuecomment-862678482
A PR was opened to remove inappropriate terminology on k/website. Instead of being a text-only edit, the author chose to replace the tutorial with a new backend. At the time, we valued the contribution over bike shedding a backend. However, it recently came to my attention that SIG Docs is not the "true source" for the tutorial (details linked above). In addition, Google already modified the tutorials to remove inappropriate terminology.
The sample code ALSO exists in k/examples/guestbook and THAT needs to be updated to match or be removed.
This PR brings https://kubernetes.io/docs/tutorials/stateless-application/guestbook/ to parity with https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook as well as reference the "source of truth."
There is one minor issue, the GCP frontend image is broke due to a PR changing the Dockerfile. This PR is contingent on https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/pull/190 merging because that will cause a new working image to be published. I'm assuming this might have a unique tag too.
Next steps:

[ ] Merge revert https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/pull/190 in GCP org
[ ]  Build the new container image (confirmed the merge will auto-build and the tag will remain the same)
[ ] Merge this working PR into k/website
[ ] Update k/examples/guestbook to match or delete

Preview link: https://deploy-preview-28452--kubernetes-io-master-staging.netlify.app/docs/tutorials/stateless-application/guestbook/

Hello @jimangel !
It seems that Netlify build failed.
Netlify Deploy log:
https://app.netlify.com/sites/kubernetes-io-master-staging/deploys/60cad6b85692b30008a2af17

Error building site: "/opt/build/repo/content/en/docs/tutorials/stateless-application/guestbook.md:82:1": failed to render shortcode "codenew": failed to process shortcode: "/opt/build/repo/layouts/shortcodes/codenew.html:14:16": execute of template failed: template: shortcodes/codenew.html:14:16: executing "shortcodes/codenew.html" at <readFile $filename>: error calling readFile: stat /opt/build/repo/content/en/examples/application/guestbook/redis-service.yaml: no such file or directory

I think that including redis-service.yaml in this PR will solve the problem. 😊

Approach LGTM

@jihoon-seo thanks for the investigation! I just force pushed the change.
In this case, I missed renaming the redis-service.yaml to redis-leader-service.yaml (because now there's two services).

Direct links to the preview:

https://deploy-preview-28452--kubernetes-io-master-staging.netlify.app/docs/tutorials/
https://deploy-preview-28452--kubernetes-io-master-staging.netlify.app/docs/tutorials/stateless-application/guestbook/

/lgtm

/approve
Needs a follow up to make sure the examples test is updated.


Variable width feature

Hi mihnse,
Really a great light weight plugin for AngularJS 1. When will you release the next version which have variable width feature ?

@asishap007 thank you, I'm not sure about time for next version. We have a long list of feature to do :). For now, you should fork and create feature you want :)

Thanks for your quick response.. mihnsen :)

Hi @mihnsen , any update for this feature?


Text returned from method is not getting parsed

Hi,
In my case the text is returned from a function.
<ParsedText
parse={
[
{type: 'url', style: {color:"red"}, onPress: this.handleUrlPress},
]
}
>
{format(answers)}
in this case the parse is not happening
Help me on this
Thanks

how to handle this case.


@moduledoc false for generated modules

Anyway to do this?  Thanks.

I published a new release which sets moduledoc false for generated modules.

Thank you!


cleos get table "more" returns true if records match query

cleos get table account account table --limit 10 returns "more":true when there are just 10 records in the table, but with --limit 11 it returns "more": false. In other words, if --limit matches the query result rows count, it returns false positive for "more".

This is by design. "more" means whether or not there's more data than the returning result.

and this is exactly what I am reporting. It is reporting false positive extra data when there aren't any. If result exactly matches query, it reports that there is "more":true when it's not. Please reopen, reproduce, and fix.

@sergmetelin bump

Confirmed off-by-one error.

In order to focus our efforts on issues that are currently creating difficulty for the community we are closing tickets that were created prior to the EOSIO 2.0 release.  If you believe this issue is still relevant please feel free to reopen it or create a new one.  Thank you for your continued support of EOSIO!


Does the gridemissions pipeline support the european grid ?

We have been successfully using the gridemissions tool for north american balancing authorities and would like to know if it would be able to support data coming from the european grid as well. Specifically, we are looking at data coming from : https://transparency.entsoe.eu/content/static_content/Static content/web api/Guide.html

Sorry for the delay in my response. Yes we are interested in collaborating to enable support for the european grid. I can come back to you next week on a plan we are working with my colleagues. Do you think we can get support in terms of code reviews ?
Also happy to hear any suggestions about collaboration formats!

@jdechalendar We would like to have permission to start contributing to the repository. We started doing a python upgrade and are looking at how to create an equivalent for the parsing code under eia_api_v2.

@maoudia-via if you want to create a PR I'll happily review it.
If you are looking for more specific guidance on how to implement something, can you ask a few more specific questions? That would help me know what information you need. That file principally has code to 1) download data from the EIA API, 2) provide the conventions for column naming so that GraphData knows what to use.

Sounds good. I am sure there will be more questions soon once we start looking at how to map the European format to the parsing logic.
It looks like I do not have permission to push  to the repository though. I also have 2 other colleagues who will be contributing.


Feature Request: Make MonadError implicit param

It should be intuitive making a stub like this
val c: SttpBackend[Try, A] = SttpBackendStub[Try, A]

instead of currently
SttpBackendStub[Try, A](TryMonad)

Stubs can be now convientently created from the backend companion objects, and I think there hasn't been other demand for making the monad instances implicit. As we don't want to pollute the implicit scope without a good cause, closing.


metadata: improve deleting a non-empty namespace's error message

Deleting a non-empty namespace fails with

namespace must be empty: failed precondition

This change improves the error message by listing all objects in
the namespace that prevent deletion.
Signed-off-by: Kazuyoshi Kato<EMAIL_ADDRESS>

I'm not sure I understand the value of having all the types listed in the error message. It can have a potential costly memory usage to produce this message and produce a large error message. Would it help just having something on the client which could give some stats on the namespace? All the objects listed can easily be requested by the client already.

Yeah. I do agree that iterating over buckets x listBucket could be slow.
How about returning information about non-empty buckets (e.g. image and container), without mentioning specific objects? Then the worst case is only 4 buckets (image, blob, container and snapshot), and the operator can query specific types based on the error message.

@kzys that sounds reasonable to me

@cpuguy83 any reason the last merge to master is generating a comment in this PR about tests during that (merge, not PR) workflow run? 🤔 😂

@estesp I think it's because how workflow_run works:
The workflow runs on workflow_run event must exist on the master or default branch. And this workflow will only run on the master or default branch, regardless of whether it is triggered by a workflow run on other branches or not.

It is green now :)


null pointer error in the Agent model

This line doesn't account for the possibility of the ticket not existing causing something like this to be executed:
null->user->id

Since the isTicketOwner is called by routes implemented in this package, it is the responsibility of the package to guard against a potentially malformed request that match the routes.
A simple solution would be to replace the find() call with findOrFail(), this would make it so that a bad request will throw a ModelNotFound instead of the current ErrorException allowing it to be automatically handled by the application's normal 404 handler.

Additionally, it's possible that a ticket would not have a valid user associated with it because there's no foreign key constraint from ticketit.user_id to users table`.

Thanks for reporting this. Would you also create a pull request that fixes this?

Sure

Went on holiday and forgot all about this.
@thekordy has this been resolved or would a PR still be useful?

Not resolved yet, a PR would be very appreciated.


Integrate Ollama

Is your feature request related to a problem? Please describe.
Ollama provides fast local LLM inference and would be great to integrate with Guidance.

PS: I would love to contribute in this.

Ollama is already supported via LiteLLM, You can use it like so

from guidance import models, gen , select

llama2 = models.LiteLLMCompletion(
    model=f"ollama/llama2",
    api_base="http://localhost:11434"
)
# capture our selection under the name 'answer'
lm = llama2 + f"Do you want a joke or a poem? A {select(['joke', 'poem'], name='answer')}.\n"

# make a choice based on the model's previous selection
if lm["answer"] == "joke":
    lm += f"Here is a one-line joke about cats: " + gen('output', stop='\n')
else:
    lm += f"Here is a one-line poem about dogs: " + gen('output', stop='\n')

I got this error
TypeError: LiteLLM.__init__() got an unexpected keyword argument 'api_base'
Is there a specific version I should roll back to make that work?

May I ask if any updates. I would like to use ollama as a backend. Thanks.

I would also like to use ollama as a backend. Is there work to build native support for ollama/llama3?

OK, so how do we set api_base now?


Add Carthage/Build to generated list so it doesn't show in PR diffs

This is equivalent to #3865, but for Carthage.
What ?
This PR adds the Carthage/Build folder to generated.rb to blacklist it and its contents from PR diffs, etc.
Why ?
While many developers don't commit their Carthage/Build folder, there are many developers and companies who do, due to the following reasons:

Quicker build times in CI/CD (this is the top reason, usually)
Ability for new developers to build immediately after cloning
Many companies prefer keeping dependencies cloned to protect themselves from the day a project is "gone"

The problem for pushing PRs that contain changes to dependencies is that they create an impossible-to-follow PR, as well as the fact the actual files changed by the developer don't get diffs as there are too many files.
This is an example from my own repo:

The actual code changes there were less than 20 lines, while the diff was very hard to read due to the binary changes in Carthage/Build.
Note, I chose to not add Carthage/Checkout because the only time people will chose to commit that is if they're using submodules, in which case I believe it's useful to see hash changes in the diffs.

Thank you!


multi client and extended configs

support for multiple clients in middleware
extended configuration of middleware
added middleware tests

Solid work brother!  I have a project that needed this so I will give it a go and let you know.


draft: add TYPE command

How do you test a new command? I'm not sure if I'm already on the right direction, i.e., if I only need to figure out what to feed send_packed_command() with, and how to receive the connection's response.
#28

Does it work well with the python client?

Does it work well with the python client?

Should I test it thoroughly? If so, do I put them (SET and TYPE commands for every DataType) all in main.py? @clarity0

for the 1 TYPE command I tested in python client, yes it works well (the assertion doesn't fail)

Right now there is only support commands that add strings so you can't really test the other cases with a client but they should work fine.

@clarity0 @tbmreza good to be merged?

@tbmreza can you rebase?

@tbmreza can you rebase?

sure but I'm not a capable git user. could you tell me how to do it, step by step?

I'm closing this PR. Currently looking at other good first issues (#23 if it doesn't turn out to be too hard for me), will open new PR covering that and #28. Thanks for bearing with me!


Getting error when using After-effects Library

Hi All,
I am using after-effects library, with ae-to-json package but, I am getting issues as
	this.includes = [...codify_includes(this.options.includes, this.options.minify), babelIncludes];
	                 ^^^

SyntaxError: Unexpected token ...
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
Following is the code which I am using
var aeToJSON = require('ae-to-json/after-effects');
var ae = require('after-effects');
var fs = require('fs-extra');
ae.execute(aeToJSON)
.then(function(json) {
console.log(json);
})
.catch(function(e) {
throw e;
});
--Please correct me If I am missing some thing.

I wrote this package without a transpiler (which is actually pretty ironic, because it uses a transpiler)
Your current version of Node must not have support for the Spread/Rest operator, so it 's crashing.
Upgrading your Node will fix this problem.
Alternatively, an updated version is currently in development that will work on all node version. So, if you don't want to upgrade, sit tight! There will be a fix out in a couple of days.

Hi BenZed,
Thanks a lot for the input, this issue is solved. But now I am having a different issue :-
/Users/gurnaneymanish/Documents/node_modules/after-effects/index.js:79
throw new Error(Errors.BadExecuteArgument);
^
Error: execute expects a function or AfterEffectsCommand instance.
at prepare_command (/Users/gurnaneymanish/Documents/node_modules/after-effects/index.js:79:11)
at Function.execute (/Users/gurnaneymanish/Documents/node_modules/after-effects/index.js:144:19)
at Object. (/Users/gurnaneymanish/Documents/AERoJSon/aeToJSON.js:4:4)
I am using the above script in Mac, is this releated to Mac os.

Not sure, I'd say that's non the 'ae-to-json' package end.
According to it's readme, you're using the correct code, though. Anyway the error message just means that you need to supply a function or a Command object to ae for it to work.


request help: how to configure route without upstream (aws-lambda plugin)

Issue description
An upstream is not required when using aws-lambda plugin. See:

https://apisix.apache.org/docs/apisix/plugins/aws-lambda/#enable-plugin
https://docs.api7.ai/apisix/how-to-guide/ai-gateway/proxy-amazon-bedrock-requests#configure-apisix

With ingress controller, if you attempt to apply the following config:
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: aws-lambda-route
spec:
  http:
    - name: aws-lambda-route
      match:
        paths:
          - /something
      plugins:
      - name: aws-lambda
        enable: true
        config:
          function_uri: https://xxx.com
          authorization:
            iam:
              accesskey: xxx
              secretkey: xxx
              aws_region: us-east-2
              service: lambda
          timeout: 30000
          ssl_verify: false

You get the a schema check error:
The ApisixRoute "aws-lambda-route" is invalid:
* <nil>: Invalid value: "": "spec.http[0]" must validate at least one schema (anyOf)
* spec.http[0].backends: Required value

What I have also attempted is to set an upstreams:
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: aws-lambda-route
spec:
  http:
    - name: aws-lambda-route
      match:
        paths:
          - /something
      upstreams:
      - name: https-upstream
      plugins:
      - name: aws-lambda
        enable: true
        config:
          function_uri: https://xxx.com
          authorization:
            iam:
              accesskey: xxx
              secretkey: xxx
              aws_region: us-east-2
              service: lambda
          timeout: 30000
          ssl_verify: false
---
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: https-upstream
spec:
  scheme: https
  loadbalancer:
    type: roundrobin

With this you do get around the schema check but you would see an empty ExternalNodes or Discovery configuration error in the ingress controller log:
2024-08-01T17:39:26+08:00	error	translation/apisix_route.go:243	failed to translate ApisixUpstream at Upstream[0]	{"error": "default/https-upstream has empty ExternalNodes or Discovery configuration", "apisix_upstream": "default/amazon-bedrock-upstream"}

So what should be the right way to configure aws-lambda on a route that does not require an upstream? Or is this scenario something ingress controller schema should accommodate for?
Note: aws-lambda plugin does not have test coverage in this repo as of now.
Environment

your apisix-ingress-controller version (output of apisix-ingress-controller version --long): 1.8.0

https://github.com/apache/apisix-ingress-controller/blob/bbcd8d9e24ea40e168df416bd69cd0f4f9603cc5/test/e2e/suite-features/external-service.go#L258 Refer to this test case

I see this plugin terminates the original request. So doesn't matter what the upstream is. Creating ApisixRoute creates an upstream automatically so it still requires backend field to be configured.
As a workaroud, you can configure an externalservice as the same URL and use that as backend. Though that upstream won't be used. But currently ingress controller doesn't support creating ApisixRoute with upstream.


Fix microscope installation guide error

Fixes a small error @ieivanov and I spotted during a discussion of this work.
Currently, the next release is planned to include a single .dll USB device driver. We might consider distributing this device driver with MM if we get permission from Meadowlark, but this is currently a low priority.

From reading https://github.com/micro-manager/mmCoreAndDevices/pull/341 I see that the device adapter which ships with MM is built agains USB driver V108. That USB driver version do we distribute with the GitHub release? The device adapter instruction page says to use the .dll which Meadowlark distributes. Let's point our installation guide to the MM page so we can keep these instruction in one place. Here we could add instructions for legacy installations (if we are supporting those)?

I'm a bit confused about what we should do with the USB driver. Should we continue to distribute via recOrder (the plan that was in my head), or should we stop distributing and tell the user to use the version supplied by Meadowlark (the instructions on the device adapter page)? I'm not sure I know all of the history/permissions with distributing this file.

From reading https://github.com/micro-manager/mmCoreAndDevices/pull/341 I see that the device adapter which ships with MM is built against USB driver V108. What USB driver version do we distribute with the GitHub release?

For recOrder<=0.3.0 we distribute an older USB driver (that works with MM 20210920), and I was planning for the recOrder==0.4.0 release to be distributed with usbdrvd.dll built against V108. Happy to change this plan.

The device adapter instruction page says to use the .dll which Meadowlark distributes. Let's point our installation guide to the MM page so we can keep these instruction in one place.

My (minor?) concern with doing this is that that instruction page isn't pinned to a specific release, so the instructions may change. My intent with these instructions is to keep them specific to the version they're distributed with, so that we have a hope of installing/recreating old versions.

Here we could add instructions for legacy installations (if we are supporting those)?

I think we can support legacy version via their legacy documentation. I don't think we should have installation instructions for legacy versions on the main branch.

It is great to see the MeadowlarkLC device adapter in the main MM repo!
My vote is to support only the current version of the device adapter/USB driver (that works with the current version of recOrder) while we are figuring out a software architecture amenable to broader deployment. Do you see a reason to support legacy installations?

@talonchandler let's chat about this in person

@ieivanov and I just had a chat about how to handle this:
We decided that when we release recOrder-napari==0.4.0 we will distribute the usbdrvd.dll built against V108 via the recOrder GitHub release page.
We'll link to this driver and instruct the user to do drag-and-drop it into their MM installation. We'll put the instructions in the recOrder docs. It doesn't seem like we'll need to link to the micromanager device driver instruction page.
We decided to keep installation instructions with their versions---no need to maintain legacy documentation. For example, 0.3.0 documentation will live with the 0.3.0 branch/release and 0.4.0 documentation will live with the 0.4.0 branch/release.

@talonchandler are you still working on this PR or is it ready to merge? Are you planning to add the dependency table here?

Thanks. I'm finishing up a couple things on this branch right now. I'll request your review on this branch (updated docs in preparation for 0.4.0) and #394 at the same time because I want to keep a couple things synchronized.

This PR was against 0.4.0dev, and I couldn't easily wrangle it into a form that would easily merge into main. I cherry-picked the key commits and opened a clear PR for discussion on #395.
Closing this.


Missing .bundle file

After fork/clone repo, update _config.yml and try to execute bundle exec jekyll build a error occur
$ bundle exec jekyll build
Could not locate Gemfile or .bundle/ directory

in master brach

You can try jekyll server instead.

Works :+1:
maybe you can remove bundle exec jekyll build from docs

"jekyll server" works, and "bundle exec jekyll build" is still failing.  Please do update the docs on this.


C89 compatability

Hey, I'm interested in being able to use this library with older compilers. Do you want this patch or parts of it?

This looks promising. I will take an eye in detail soon.
Can you merge semver_unit.c into semver_test.c?

I reviewed the changes now and looks go to me. Thanks for the contributions.

That was fast! Thanks!
On Tue, 13 Dec 2016 at 01:15, Tomás Aparicio<EMAIL_ADDRESS>wrote:

I reviewed the changes now and looks go to me. Thanks for the
contributions.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/h2non/semver.c/pull/14#issuecomment-266595708, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAeE0QVXYl8ONLdXLqe4YCSN4plAyLbjks5rHeOvgaJpZM4LLCOK
.


[Suggestion]About Enchanter's voice.

This mod is recommended for use with EnchantWithMob, but in EnchantWithMob, the Enchanter's voice is replaced with the Illusioner's voice. How about making it possible to play the Enchanter's voice and the sound of magic effects by using this mod together?

Don't think that's happening. I'm pretty sure it violates Mojang EULA.


add jvm options to ScalaTestParams

Reasoning behind this is described in https://github.com/build-server-protocol/build-server-protocol/issues/143
I've taken changes from https://github.com/build-server-protocol/build-server-protocol/pull/96 and made them on latest master + made jvmOptions nullable.

Thanks! I'm not opposed to this change, but there's some question marks. Usually the jvmOptions for running tests are defined on the build tool side. Or it may run a test framework in-process. What are the intended semantics when passing jvmOptions from the client, when the server already has a set of options defined?

In tests I need to define which typesafe config file to load. The only way to do it is via JVM properties. Bloop, for example, already accepts jvm options to run tests with internally. My ultimate goal to be able to pass jvm options from vs code -> scala metals -> bloop

I would like to clarify another thing as well. DebugSessionParams can have "scala-test-suites". What is contents of the data field in that case? I initially thought it should be ScalaTestParams but metals and bloop encodes/decodes it at List[String].


Added failover callback for Oracle and PostgreSQL.

Hi all,
In this PR I would like to propose the failover capability, implemented for Oracle (where it is supported by the native OCI interface, especially in RAC configurations) and PostgreSQL (where it is emulated by the backend).
The idea is that when the database connection gets broken, the backend can notify the user about that fact and allow him to guide the automated reconnection process. It is possible to instruct the backend to retry to the same or to another destination, as well as replay necessary session configuration sequence.
The comments for functions in new file callbacks.h explain it all.
(no, don't ask for unit tests...)

Thanks, this looks like another useful addition!
No real comments, but it looks like the PostgreSQL implementation is almost completely generic, just PQstatus() == BAD_CONNECTION part is really backend-specific, so perhaps we could abstract just this check and make the rest generic and reusable from the other backends? I think it would be useful to have this functionality available for most of them (with the exception of SQLite).
And while I understand that unit testing this is difficult, it would be still great to have at least a small example (in the docs as we don't have any real examples?).

Vadz - I'm not sure if the whole concept of failover is generic enough for anything reusable. Oracle and PostgreSQL do it in completely different ways and for SQLite it does not make any sense at all - just these three examples show that a reusable component might not see any reuse in practice.
It would also make the library structure and dependencies more complex.


[AutoPR compute/resource-manager] Swagger change for getting all availability sets in a subscription and StandardSSD

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/3302

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/2487


feat: adds server redact

added exports to package.json +1 👍

How important would Request and Response be?  I think dropping node16 while we're already doing a semver major isn't gonna be a big deal.  It'd mean bumping the engines on npm-registry-fetch also.