Port to rbczmq

I keep getting segfaults from "assertion failed" error messages from programs involving ZMQ. Even just running rake spec in this project brings those errors. I tried on OSX 10.10 and 10.11, same result. I tried with and without lib sodium, same result. Then I noticed that maybe it's because https://github.com/chuckremes/ffi-rzmq has been put into maintenance mode. Apparently https://github.com/methodmissing/rbczmq is the way to go. So I'm thinking about porting celluloid-zmq to that library. Is that a good idea? Or is the low-level approach of ffi-rzmq actually needed by celluloid-zmq?

@chuckremes would know best here. I've been contemplating a port since higher versions of ZMQ don't work with ffi-rzmq. Would be glad for help, if a port is the best idea.

The main downside I can think of is this would break JRuby support

@tarcieri From my point of view, it's already broken. ffi-rzmq says it supports ZMQ 4.x, and I have 4.1.3 installed, but it doesn't work at all.

It's known that 4.x doesn't work. But 3.x works completely under jRuby.

Sorry, I didn't know that. Where does it say that?

This is known:
https://github.com/chuckremes/ffi-rzmq/issues/121

@digitalextremist Oh, I see. Thanks for pointing that out.

I saw that there are also https://github.com/zeromq/czmq, https://github.com/Asmod4n/ruby-ffi-czmq, and https://github.com/mtortonesi/ruby-czmq, all of which are based on FFI, which, AFAIK, would guarantee JRuby support. I just have no idea about the differences between them. But the first seems like it's the "official" Ruby binding for CZMQ. Why not use that one?

The official bindings are just thin wrappers around the c code and don't expose any high level ruby functionality, they are the basis for someone who wants to write high level bindings.
The wrapper i wrote is pretty outdated now and is build around assumptions which might no longer be true, it's high level code could be adopted to use the official bindings instead of the abomination i came up with in https://github.com/Asmod4n/ruby-ffi-czmq/blob/master/lib/czmq/libczmq.rb.
Last time i checked https://github.com/mtortonesi/ruby-czmq was broken and doesn't work and it doesn't look like the errors where fixed.

(i also pretty much gave up on ruby as a standalone interpreter and focus much more on mruby now, which has solved the packaging hassle ruby is)

I noticed that second part @asmod4n. Do you mind if we talk separately about that?

Just curious, what benefits are brought by 4.x that are lacking in 3.x? I'm extremely committed to continued feature support on core dependencies, but having done triage a long time by now, I'm prone to prioritize based on gains. What do we gain here, I really want to know. I'm heavily invested in 0MQ.

Mainly security, but also a new wire protocol, the next release will bring thread safe server and client sockets with automatic timeout handling.

I see. Thanks for the explanation.
I don't know how outdated your your wrapper is, or how much work it'd take to adapt it. I am using ZMQ already but not in any sophisticated way (just bi-directional communication between one "broker" and many "clients" (both sides use a ROUTER socket), done with CURVE authentication). Is there much more to know to be able to come up with a nice, Ruby-esque interface and integrate it in your library? :)
What I noticed about your and also @mtortonesi's wrappers is that they don't have any tests. I guess that'd be a good starting point on the road to a stable wrapper?

What is missing is some kind of error handling in the generated wrappers build via zproject (https://github.com/zeromq/zproject/blob/master/zproject_bindings_ruby.gsl) from xml files (https://github.com/zeromq/czmq/tree/master/api).
zproject is the way how the zmq folks tamed automake/cmake et all to build robust APIs around C libraries, which as a byproduct also create wrappers for ruby/python/qt etc.

With zproject for example you can define a class/actor and it automatically generates C skeletons you fill out and get wrappers around them.

Seams like the main culprit has been resolved in https://github.com/chuckremes/ffi-rzmq-core, but looks like the library does stuff the zeromq API doesn't allow: http://api.zeromq.org/4-0:zmq-msg-init.
The API docs explicitly say not to use the zmsg struct, but ffi-rzmq-core does it.

@paddor @digitalextremist looks like its fixed in ffi-zmq-core, see my last post.

@Asmod4n Please provide more information on what you think ffi-rzmq-core or ffi-rzmq are doing wrong. I don't see any problems with my handling of zmq_msg_t structs.

zmq_msg_t was always exported in a opaque way e.g. its fields have never been part of the official api, it was at first a pointer, then a struct and now a union, its size changed too.
So in essence, ffi-rzmq-core wasn't compatible with libzmq since January.
That also happened because libzmq doesn't define a function to return the size of a zmq_msg_t, opened a issue for that on the issue tracker: https://github.com/zeromq/libzmq/issues/1599

I'm working on a (hopefully nice) CZMQ binding over at paddor/cztop. Any input or help is welcome.

@paddor that gem looks well conceived and exciting. I will watch with interest and help wherever I can. I am highly dependent on Celluloid::ZMQ and maintain most of the code impacted by your topic here.

@digitalextremist Thanks! That's great to hear. I'll add you as collaborator.

@digitalextremist Providing a way to wait for read/write events from sockets to be able to port Celluloid::ZMQ::Reactor to CZMQ turns out difficult, because waiting for write events isn't straight forward without falling back to using zmq_poll_items. Plus, when using zloop, one would have to add and, as soon as the event has been received, immediately remove sockets from the loop, and also keep starting and stopping the zloop, because Celluloid::ZMQ::Reactor apparently uses #run_once (as opposed to #run).
Do you know if it's possible to adapt Celluloid::ZMQ::Reactor to support the more low-level kind of loop, where one would call #run just once?

I had a similar issue with my czmq binding for mruby and wrote my own reactor https://github.com/Asmod4n/mruby-czmq/blob/master/mrblib/reactor.rb https://github.com/Asmod4n/mruby-czmq/blob/master/mrblib/poller.rb

@paddor I believe this is an area where we'd want to be careful to preserve "evented" behavior versus having an infinite loop or similar. See the Celluloid::IO reactor itself, which behaves the same:

https://github.com/celluloid/celluloid-io/blob/master/lib/celluloid/io/reactor.rb#L57

/cc: @tarcieri

@Asmod4n Thanks for the help. Very interesting solution.
@digitalextremist I think I have a solution. I'll extend zpoller with the method zpoller_add_writer and then implement Celluloid::ZMQ::Reactor#run_once using a loop that calls zpoller_wait until it doesn't return any more sockets.

@digitalextremist I'm wondering, how do you manage RSpec's lack of support for Rubinius? I'm running into trouble with it in my CZMQ binding when I run it on Rubinius (and JRuby), but only since I implemented zpoller (yesterday). The issue seems to be related to RSpec, though. How does Celluloid manage this? Thanks for any input.

@paddor we've never had problems using RSpec on Rubininus other than the inability to pinpoint the specific Rubinius version we want to test on Travis CI ... what specific problem are you having?

@digitalextremist Thanks. I was having trouble with CZTop. The zpoller specs failed mainly on Rubinius and JRuby, but then even on MRI. Then I learned that RSpec doesn't officially support Rubinius. I filed zeromq/czmq#1299 and it's fixed now. It wasn't RSpec's fault after all. :-) All CZTop specs run very smoothly on MRI, Rubinius, and JRuby now.
By the way: CZTop::Poller (zpoller) was the last class. CZTop is pretty much complete now. Maybe you wanna give it a look. I know we still need a #run_once loop/poller thing for Celluloid::ZMQ (can't use CZTop::Poller, as it's only for reading). I've been thinking about creating a gem cztop-manual_loop. Or maybe build it directly into Celluloid::ZMQ. What's your opinion on it?

@digitalextremist I've started porting Celluloid::ZMQ to CZTop.
Do you know if its internal API is used outside of the project? Like, I assume and understand that methods like Celluloid::ZMQ::Socket#read and #write are expected to only raise IOError, so Celluloid knows the actor should just crash. But do you know if any other projects depend on methods like Socket#get/#set to access a socket's options by passing in integers such as ::ZMQ::RCVTIMEO?

I've finished porting the library code and the specs (WIP, I guess). When I run the specs, I get a wall of backtraces complaining about loose threads.
Celluloid::ZMQ::Socket
Runaway thread: ================ #<Celluloid::Thread:0x007f828b1e88f8@/Users/paddor/src/ruby/celluloid.git/lib/celluloid/group/spawner.rb:47 sleep>
Backtrace:
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `sleep'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `wait'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `block in check'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/timers-41145ed260e4/lib/timers/wait.rb:14:in `for'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:58:in `check'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:155:in `block in run'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/timers-41145ed260e4/lib/timers/group.rb:66:in `wait'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:152:in `run'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:131:in `block in start'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/celluloid-essentials-f0545ce47ed9/lib/celluloid/internals/thread_handle.rb:14:in `block in initialize'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor/system.rb:78:in `block in get_thread'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/group/spawner.rb:50:in `block in instantiate'
Runaway thread: ================ #<Celluloid::Thread:0x007f828b1da140@/Users/paddor/src/ruby/celluloid.git/lib/celluloid/group/spawner.rb:47 sleep>
Backtrace:
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `sleep'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `wait'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `block in check'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/timers-41145ed260e4/lib/timers/wait.rb:14:in `for'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:58:in `check'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:155:in `block in run'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/timers-41145ed260e4/lib/timers/group.rb:66:in `wait'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:152:in `run'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:131:in `block in start'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/celluloid-essentials-f0545ce47ed9/lib/celluloid/internals/thread_handle.rb:14:in `block in initialize'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor/system.rb:78:in `block in get_thread'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/group/spawner.rb:50:in `block in instantiate'
Runaway thread: ================ #<Celluloid::Thread:0x007f828b1c9110@/Users/paddor/src/ruby/celluloid.git/lib/celluloid/group/spawner.rb:47 sleep>
Backtrace:
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `sleep'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `wait'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `block in check'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/timers-41145ed260e4/lib/timers/wait.rb:14:in `for'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:58:in `check'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:155:in `block in run'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/timers-41145ed260e4/lib/timers/group.rb:66:in `wait'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:152:in `run'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:131:in `block in start'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/celluloid-essentials-f0545ce47ed9/lib/celluloid/internals/thread_handle.rb:14:in `block in initialize'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor/system.rb:78:in `block in get_thread'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/group/spawner.rb:50:in `block in instantiate'
Runaway thread: ================ #<Celluloid::Thread:0x007f828b1a3c58@/Users/paddor/src/ruby/celluloid.git/lib/celluloid/group/spawner.rb:47 sleep>
Backtrace:
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `sleep'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `wait'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:63:in `block in check'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/timers-41145ed260e4/lib/timers/wait.rb:14:in `for'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/mailbox.rb:58:in `check'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:155:in `block in run'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/timers-41145ed260e4/lib/timers/group.rb:66:in `wait'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:152:in `run'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor.rb:131:in `block in start'
 ** /Users/paddor/.gem/ruby/2.3.0/bundler/gems/celluloid-essentials-f0545ce47ed9/lib/celluloid/internals/thread_handle.rb:14:in `block in initialize'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/actor/system.rb:78:in `block in get_thread'
 ** /Users/paddor/src/ruby/celluloid.git/lib/celluloid/group/spawner.rb:50:in `block in instantiate'

I don't know what that means. Can anybody help me?

This is a known problem. For your purposes right now, circumvent that test if you need immediate feedback; otherwise, this is another thing on my immediate to-do list

@paddor more background: This is caused outside Celluloid::ZMQ in Celluloid itself; more precisely, in its addons to the test suite, brought in basically everywhere in the celluvoid.
I'm trying to recall which issue this problem is being address on, but can't at the moment. But like I said, it's known

It's basically all of them :laughing: I had to change a spec file in celluloid to make it stop after the first, otherwise my scrollback buffer of 10000 lines wasn't enough to see the first one.

Okay, thanks for the info. Btw, how are we standing on breaking the API within Celluloid::ZMQ? Now or never? Not at all?
And does it really always have to be IOError if something goes wrong? CZTop raises appropriate exceptions, like ArgumentError for EINVAL, Interrupt for EINTR, SocketError for EHOSTUNREACH, or subclasses of SystemCallError for other errnos from ZMQ.

Problem has been solved here http://daniel.haxx.se/docs/poll-vs-select.html, but only for celluloid-io. Try to see whether replacing boot with init in ZMQ group solves it.

Thank you @TiagoCardoso1983

Any updates on this?

I'd be interested in an update as well. I've tried a few times over the past year to use (C)ZMQ with Celluloid, and had a mixed bag of results. Generally stopped a while back because ZMQ 4.0 was installed on my OS by other dependencies, but none of the existing gems supported it. CZTop is the only one so far that seems to work out of the box (based on very limited testing, but that is light years ahead of other that complain about stack smashing or fail assertions all the time).

CZTop::Poller is now implemented based on the zmq_poller_*() functions and thus also works with thread-safe sockets such as SERVER/CLIENT/RADIO/DISH. Furthermore, CZTop::Poller::Aggregated is the one that can be used in Celluloid::ZMQ, as it provides #readables and #writables (arrays of sockets) after just one call to #wait.
Has that Runaway thread issue been fixed?

I noticed there is a cztop 0.3.0, but it doesn't appear to work with the version of czmq I have access to via AUR on my Manjaro (Arch derivative) system - 3.0.2-1. What version of czmq is necessary to use the latest cztop?
I also checked out your fork of celluloid-zmq a while back, and it doesn't look like it has been updated. I assume the reactor should use CZTop::Poller::Aggregated instead if CZTop::Poller? Or does that not matter?
As far as I can tell, it looks like the Runaway thread issue issue is still happening when I run the specs.

What version of czmq is necessary to use the latest cztop?

@rfestag Because CZTop is pretty new, and supporting older versions, I decided to drop support for ZMQ < 4.2 (soon to be released) and CZMQ 3.0.2 (current stable release, next release coming soon too, I guess). If you're on OSX and use Homebrew, you can install both using brew install zmq --with-libsodium --HEAD && brew install czmq --HEAD.

I assume the reactor should use CZTop::Poller::Aggregated instead if CZTop::Poller?

Thanks for the heads up on celluloid-zmq. You are completely right. I just released CZTop 0.4.0, which adds some more compatibility on CZTop::Poller::Aggregated, and changed my branch to use that one (see here). I haven't tested this change though, since you said the Runaway thread issue is still present. 😞

Yes, let's use this issue to collaborate with @paddor and @digitalextremist on replacing ffi-rzmq with cztop in celluloid-zmq.

@chuckremes I don't know if you noticed, but I tried to port this repo to cztop before, back in April. I stopped because of the issue mentioned above. Maybe you can build on top of my work: https://github.com/celluloid/celluloid-zmq/compare/master...paddor:cztop

@paddor does this issue actually persist? The original SIGSEGV? I'm sure between those of us on the thread, we can squish that in relatively short order. If it was the loose-threads piece, that ought to be resolved, as of the multiplex branch on Celluloid I'm still on.

@digitalextremist No idea about the SIGSEV, since it's been ages. Actually couldn't remember it.
As for the loose threads, I'll try to rerun the test suite then. :)

Great -- but remember, when in doubt, use the multiplex branch for the time being. Also, I invited you to our Slack lair just now.

@paddor with jruby-1.7.25 and mri-2.3.1 ( with rbx-3.* currently having its own unrelated problems for now ) all the tests pass with `libzmq3, after #58 was fixed.

@digitalextremist Thank you so much!

No problem @paddor -- thanks for your patience!

So the whole test suite passes, even with the changes on my cztop branch. I guess I can create a pull request now. :)

Solved via #60.


CLIP: preprocess

Hi 👋🏽 I wanted to replicate the Linear-probe evaluation script from the official CLIP repository. However, I can't figure out how to properly pre-process the images. I've attached my script and the corresponding error trace.

Evaluation script
import numpy as np
import mlx.core as mx
from mlx.data.datasets import load_cifar10

from model import CLIPModel
from image_processor import CLIPImageProcessor

def get_cifar10(batch_size, root=None):
    mean = np.array([0.485, 0.456, 0.406]).reshape((1, 1, 3))
    std = np.array([0.229, 0.224, 0.225]).reshape((1, 1, 3))

    def normalize(x):
        x = x.astype(np.float32) / 255.0
        return (x - mean) / std

    tr = load_cifar10(root=root)
    tr_iter = tr.to_stream().key_transform("image", normalize).batch(batch_size)

    test = load_cifar10(root=root, train=False)
    test_iter = test.to_stream().key_transform("image", normalize).batch(batch_size)

    return tr_iter, test_iter

def get_features(model, iter):
    all_features = []
    all_labels = []
    image_proc = CLIPImageProcessor.from_pretrained("mlx_model")

    for _, batch in enumerate(iter):
        image, label = batch["image"], batch["label"]
        x = image_proc([mx.array(image)])
        y = mx.array(label)

        image_embeds = model.get_image_features(x)
        all_features.append(image_embeds)
        all_labels.append(y)

    return mx.concatenate(all_features), mx.concatenate(all_labels)

if __name__ == "__main__":
    model = CLIPModel.from_pretrained("mlx_model")

    train_iter, test_iter = get_cifar10(batch_size=256)
    train_features, train_labels = get_features(model, train_iter)
    test_features, test_labels = get_features(model, test_iter)

Error
Traceback (most recent call last):
  File "/Users/saurav/dev/SauravMaheshkar/mlx-examples/clip/eval.py", line 47, in <module>
    train_features, train_labels = get_features(model, train_iter)
  File "/Users/saurav/dev/SauravMaheshkar/mlx-examples/clip/eval.py", line 33, in get_features
    x = image_proc([mx.array(image)])
  File "/Users/saurav/dev/SauravMaheshkar/mlx-examples/clip/image_processor.py", line 39, in __call__
    [self._preprocess(image)[None] for image in images], axis=0
  File "/Users/saurav/dev/SauravMaheshkar/mlx-examples/clip/image_processor.py", line 39, in <listcomp>
    [self._preprocess(image)[None] for image in images], axis=0
  File "/Users/saurav/dev/SauravMaheshkar/mlx-examples/clip/image_processor.py", line 44, in _preprocess
    image = resize(image, self.size)
  File "/Users/saurav/dev/SauravMaheshkar/mlx-examples/clip/image_processor.py", line 65, in resize
    width, height = image.size
TypeError: cannot unpack non-iterable int object

The resize function in our Clip example takes a PIL Image not an mx.array.
I would remove the CIFAR-10 preprocessing and just load the byte arrays directly into a PIL.Image using Image.fromarray. From there you should be able to use the image preprocessing for the CLIP model.
So concretely change the dataset loading to:
def get_cifar10(batch_size, root=None):
    tr = load_cifar10(root=root)
    tr_iter = tr.to_stream().batch(batch_size)

    test = load_cifar10(root=root, train=False)
    test_iter = test.to_stream().batch(batch_size)

    return tr_iter, test_iter

And modify the loop like so:
        x = image_proc([Image.fromarray(im) for im in image])

Make sure to add from PIL import Image.


updated _userbar.scss #10036

updated userbar.scss for fixing Wagtail 4.2 userbar is now sensitive to change in font size in parent DOM #10036 #10038

Please check the following:

[ ] Do the tests still pass?[^1]
[ ] Does the code comply with the style guide?

[ ] Run make lint from the Wagtail root.

[ ] For Python changes: Have you added tests to cover the new/fixed behaviour?
[ ] For front-end changes: Did you test on all of Wagtail’s supported environments?[^2]

[ ] Please list the exact browser and operating system versions you tested:
[ ] Please list which assistive technologies [^3] you tested:

[ ] For new features: Has the documentation been updated accordingly?

Please describe additional details for testing this change.
[^1]: Development Testing
[^2]: Browser and device support
[^3]: Accessibility Target

@saevarom ya i tried it it works

@Aadijindal07 in the future please fill in the details of our pull request template and keep it to one pull request per change.  We receive lots of pull requests so it makes a big difference when people make an effort to make them simple to review.


bump go to 1.21.6

Routine bump in the minimum Go version.
[#186765938]

Similar error message as https://github.com/golang/go/issues/61888

see https://github.com/cloudfoundry/uaa/pull/2677

This has been in fixed here: https://github.com/cloudfoundry/uaa/pull/2677


A way to set default start time

It would be awesome if we could set the default time and maybe even the increment time. This could simply be done through a config file somewhere on the filesystem so no UI has to be made for it.

Hi @MichelJonkman, unfortunately this would mean adding permissions to read the file system, handle reading files, exposing new APIs, documentation, etc. and this is not the goal of this project.
Furthermore, users that would create such configuration file and copy it to the appropriate location probably can simply re-compile this project with the values they want 😄
https://github.com/SimonMarquis/SleepTimer/blob/e88f7463cb6b4622ec44baa6dcb27f2bb9aa9ad4/app/src/main/java/fr/smarquis/sleeptimer/SleepNotification.kt#L26-L28

@SimonMarquis I'd love to recompile it myself but I have no knowledge of compiling Android apps, is this easy to do?

Thank you for the explanation, I will do this when I hopefully don't forget about it 😛


Controller Middleware

Hi,
Can you helpe me please to specify middleware within in controller's ?

@devlamine could you explain with more details what you want?


fix(analytics): remove tailorbird, consider Stork

it is https://github.com/Thinkful/ui/blob/435aaff45961500329acdd68b3a5439b8dc2e8db/src/analytics/actions.es6#L42


Internal error when doing production build

I am using latest app-scripts (@beta). Doing ionic serve, ionic-app-scripts build --dev works fine. Trying to do ionic-app-scripts build fails with below error. How can I debug this?
[00:11:39]  ionic-app-scripts 0.0.37
[00:11:39]  build prod started ...
[00:11:39]  clean started ...
[00:11:39]  clean finished in 6 ms
[00:11:39]  copy started ...
[00:11:39]  ngc started ...
[00:11:40]  lint started ...
[00:11:40]  copy finished in 386 ms
[00:11:49]  Error: Internal error: unknown identifier [object Object]
[00:11:49]  ngc failed
[00:11:49]  ionic-app-script task: "build"
[00:11:49]  Error: Error
Your system information:

Cordova CLI: 6.3.1
Gulp version:  CLI version 3.9.1
Gulp local:
Ionic Framework Version: 2.0.0-rc.1
Ionic CLI Version: 2.1.1
Ionic App Lib Version: 2.1.1
Ionic App Scripts Version: 0.0.37
ios-deploy version: 1.9.0
ios-sim version: 5.0.8
OS: Mac OS X Sierra
Node Version: v6.9.1
Xcode version: Xcode 8.0 Build version 8A218a

Hello, thanks for using Ionic! Unfortunately I am not able to reproduce this issue, would you mind posting a repo we can use to reproduce it?

Unfortunately this is on a private repo. Any way I can have a more verbose error output?

@masimakopoulos You are correct, this is an internal NGC error and not an error coming from our app-scripts. Could you try deleting your node_modules and reinstalling? Thanks!

Could I also use the latest version of angular-compiler as the ones used in the sample ionic2 package.json seem a bit outdated
    "@angular/compiler": "2.0.0",
    "@angular/compiler-cli": "0.6.2",

vs
    "@angular/compiler": "2.1.1",
    "@angular/compiler-cli": "2.1.1",

maybe I get lucky and there is more info or bug fix on the newer versions. Will that cause trouble with app-scripts?

Just referencing the ngc related issue https://github.com/angular/angular/issues/11034

Hey @masimakopoulos , so i actually opened this pr to update us to the latest NGC and Angular. For now if you try to update your app to the latest NGC its gonna break stuff, but that PR will fix this. I am going to mark this one as blocked for now because of this.

@masimakopoulos,
Angular had a change in ngc that is breaking semver and compatibility with Ionic. Can you update your package.json to 2.0.0 and get rid of the ^, then do a fresh npm install. This should fix the issue I think.
I'll re-open if needed. I think this will fix it. We're working on supporting the most recent version of Angular ASAP.
Thanks,
Dan

Hi people. I have a simillar issue:
Error: Internal error: unknown identifier {}
    at _TsEmitterVisitor._resolveStaticSymbol (/path/node_modules/@angular/compiler/bundles/compiler.umd.js:18517:19)
    at _TsEmitterVisitor._visitIdentifier (/path/node_modules/@angular/compiler/bundles/compiler.umd.js:18535:23)
    at _TsEmitterVisitor.visitExternalExpr (/path/node_modules/@angular/compiler/bundles/compiler.umd.js:18197:14)
    at ExternalExpr.visitExpression (/path/node_modules/@angular/compiler/bundles/compiler.umd.js:15390:24)
    at _TsEmitterVisitor.AbstractEmitterVisitor.visitBinaryOperatorExpr (/path/node_modules/@angular/compiler/bundles/compiler.umd.js:17888:17)
    at BinaryOperatorExpr.visitExpression (/path/node_modules/@angular/compiler/bundles/compiler.umd.js:15534:24)
    at _TsEmitterVisitor.AbstractEmitterVisitor.visitIfStmt (/path/node_modules/@angular/compiler/bundles/compiler.umd.js:17575:24)
    at IfStmt.visitStatement (/path/node_modules/@angular/compiler/bundles/compiler.umd.js:15957:24)
    at /path/node_modules/@angular/compiler/bundles/compiler.umd.js:17998:58
    at Array.forEach (native)
Compilation failed

Ionic info:

global packages:

    @ionic/cli-utils : 1.5.0
    Cordova CLI      : 7.0.1
    Ionic CLI        : 3.5.0

local packages:

    @ionic/app-scripts              : 1.3.6
    @ionic/cli-plugin-cordova       : 1.4.1
    @ionic/cli-plugin-ionic-angular : 1.3.2
    Cordova Platforms               : android 6.1.2
    Ionic Framework                 : ionic-angular 3.1.1

System:

    Node       : v6.10.3
    OS         : Linux 4.4
    Xcode      : not installed
    ios-deploy : not installed
    ios-sim    : not installed
    npm        : 5.0.4

I already delete my node_modules folder and re install all, but the problem persists. Can anyone help me please?

Sorry people. Commenting this line in my app.module.ts the problem has gone:
{provide: Window, useValue: window},
Sorry again.


PIZ-5 Report View

Description
The report view was added
Related Tickets
PIZ-5
Manual Testing

Checklist
The expectation with this checklist is to ensure that the Pull Request follows all requirements before review.

[x] I have added reviewers for this Pull Request.
[x] Assign a descriptive label to the PR.

 PIZ-5 Create a Report Endpoint


Feeder unit tests

Description
Add unit tests to the feeder package.

Done at https://github.com/awfm9/flow-dps/tree/unit-test-feeder
Waiting for #24 before opening a PR

Fixed by #33

Reopening since tests are now broken on master. I'm looking into it.

Solved on master by putting back the original code for the feeder.


[nrf noup] ci: python requirement updates

Install ci-tools requirementx.txt before check_compliance.py
-- missing python-magic

lock python requirement versions
-- setting sphinx==2.3.0
-- (sphinx:2.4.0 released yesterday with a bug that breaks the build)

Signed-off-by: Thomas Stilwell<EMAIL_ADDRESS>

tested here: https://github.com/NordicPlayground/fw-nrfconnect-nrf/pull/1874


Rename mir-run... to mir-bin-run... also in CMakeLists.txt

Fixes #395

Oops.  I've just fixed it by myself.  Sorry.

Does not cover the addition of mir-bin-run-test in 9b7aa03, but that would require me reading up on CMake testing best practices...

I practically do not know cmake too.  So I can not help in this.

No worries, thanks for fixing :-)


Reorder output in ods file

need to move the  email field up the list of fields in the ODS.

👍 good when tests


Implement an exporter for Ableton .ascl

ref #601

How does it look?

Self-reviewing: Good enough.


Implement DXGI guidance for variable refresh displays

Summary of the Pull Request
Implements guidance examples from https://docs.microsoft.com/en-us/windows/desktop/direct3ddxgi/variable-refresh-rate-displays to hopefully resolve variable refresh rate display issues.

References

PR Checklist

[x] Closes #1413
[x] CLA signed. If not, go over here and sign the CLA
[x] Tests added/passed (n/a, visual)
[x] Requires documentation to be updated (no)
[x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: I am a core contributor.

Detailed Description of the Pull Request / Additional comments

Adds check during DXGI creation for tearing support
Uses tearing check status to apply appropriate flags to swap chain creation, swap chain buffer resize, and presentation calls.
Sets presentation sync to 0 to present immediately (per variable refresh doc). I don't remember why I had this as 1. It might become a problem. If it does, we'll conditionally change it back and forth. But reading the docs now, I think 0 is OK.

Validation Steps Performed

All manual since we don't have automated visual tests:

I checked that everything was looking fine on a standard 1080p 60hz monitor still
I changed my second monitor to 150% scaling and dragged the window back and forth with a full line of text at the pwsh prompt to ensure that everything fit correctly as the display size updated and caused refreshes of buffer and scaling sizes

I checked adding the dxgi1_4.h and dxgi1_5.h headers into the Windows code build and it does NOT make the build angry for layering issues. So this should be good... if it works.

Also, I have no idea why this says "out-of-date with the base branch" because I pulled and synced master and tried to merge it into here and it says we're up to date...

Should we close this since it didn't end up fixing the issue in question?

Should we close this since it didn't end up fixing the issue in question?

Yes.


Add click commands

Add click commands

[ ] Start listening with params:

interface
port
processes

[ ] Add click tests

Hi. I am new and would like to contribute to this issue @jaumef

To be honest I don't even know if this repo is still used or anyone from GISCE is maintaining this repo (seeing the last commit was 7 years ago... ) maybe @ecarreras can lend a hand.
IIRC this issue was to add some click command parsing so that we could start it without configs which is easier when trying things out.


This fixes #316. SmallTagMap#equals was not thread safe

NetflixOSS » servo » servo-pull-requests #17 SUCCESS
This pull request looks good

NetflixOSS » servo » servo-pull-requests #18 SUCCESS
This pull request looks good

NetflixOSS » servo » servo-pull-requests #19 SUCCESS
This pull request looks good


Added B.E and B.TECH name suffixes

These suffixes are commonly used in India for engineering graduates

FYI the only reason I didn't merge this earlier is that I was trying to keep most internationalization out of the library until I figure out #52 but since I haven't taken the time yet to crack that nut and this change is rather minor I'm merging it.
Sorry it took so long!


Tests: ranger: replace=TRUE is invalid

We need to adjust the param.set such that logicals are valid there

Evtl replace=TRUE interpreted as string?

You were right, replace=TRUE is interpreted as string. If any parameter is TRUE or FALSE, i will now convert it to logical.


index/pilosa: speedup index iterator

Each next call to index iterator was searching for the bucket and creating a new transaction. Now the bucket and transaction is created only once and reused during all its life.
Previously:
index.Next() 5.445086ms
index.Next() 4.958599ms
index.Next() 4.597905ms
index.Next() 5.394169ms
index.Next() 5.161109ms

Now:
index.Next() 3.711µs
index.Next() 24.377µs
index.Next() 11.213µs
index.Next() 9.873µs
index.Next() 7.679µs
index.Next() 5.182µs
index.Next() 3.655µs
index.Next() 6.272µs
index.Next() 3.734µs

Some tests with queries:

create index path on files using pilosa (file_path); (2620377 rows)

rows returned
before
after

160
1.34s
0.10s

1342
18s
6.34s

create index author on commits using pilosa (commit_author_name); (1933 rows)

rows returned
before
after

419
3.05s
0.51s

142
1.86s
0.84s

Perfecto!
Do we rollback transaction in some cases?

Actually, do we need transactions at all? If any error occurs the index is marked as corrupted and can't be used so it does not really matter which state the index is in

I believe we need to do transactions always in boltdb. Also in read only transactions Rollback must be called.
https://godoc.org/github.com/boltdb/bolt#Tx.Rollback
I'll make the transaction read only and use Rollback always.

Transactions are now read only and Rollback is used to close them.


Keysend doesn't appear to be working

Trying to keysend the LSP node. Getting incorrect_or_unknown_payment_details

I did this last night on mainnet to the TBC node. I think it was just our CLN node that can't accept keysend. Maybe it has it disabled.


ULID type

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
Would V2 welcome a ULID type? This seems like a good implementation. ULIDs are becoming more popular because as it's a timestamp and a globally unique ID all in one, and is time sortable. I don't mind working on a PR.
Affected Components

[ ] Compatibility between releases
[ ] Data validation/parsing
[X] Data serialization - .model_dump() and .model_dump_json()
[ ] JSON Schema
[ ] Dataclasses
[ ] Model Config
[X] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

Hello,
Concerning this feature, I think we should use this pip https://github.com/mdomke/python-ulid
WDYT?

Hello,
Concerning this feature, I think we should use this pip https://github.com/mdomke/python-ulid
WDYT?

Sounds great! we can depend on this package for this integration!


IUrlHelper Link - Ignore Properties

Hi!
I'm using IUrlHelper to create paging links.
Like:
urlHelper.Link(RouteName, ObjectWithPagingData)
That works and it generates the URL.
However that same object has some public properties I'd like to ignore and not include.
But even decorating the property like so, it ends up in the URL:
 [IgnoreDataMember]
        [JsonIgnore]
        [XmlIgnore]
        public Int32? ServerPageNumber

Is there a different attribute/way of doing this I need to use, or is this some kind of bug?
Thanks for the help!

Hi @OpenSpacesAndPlaces , there is currently no way to do this directly.
There are two alternatives:

Create a new type that has only the properties you want to be included in the route
Use a dictionary type instead, and include only the keys/values you want to be included in the route


Run-time check for type mismatch, could not be compile-time?

import gara
type Rectangle = object
      a, b: int
let a = @[Rectangle(a: 1, b: 2), Rectangle(a: 3, b: 4), Rectangle(a: 5, b: 6), Rectangle(a: 7, b: 8)]
match(a):
of @[int @first, _, *(a: @list)]: # mismatching `int` added to make it fail
  echo first, list

Nim's seq cannot have different types values, at least with int and an object/tuple it's always wrong,
so principally can be caught at compile-time. Not to compile for patterns which can never match. ?

Detecting that this is in fact impossible to be true in cases like that means gara does additional typechecking and I really want to go down that road only if really needed.
Also writing a pattern like that is like writing
if a[0] is int:

You wouldn't expect Nim to fail to compile this, right?

Well
of @[0, Rectangle(a: 5, b: 7)]

should already fail on compile time, just without a good enough error message. However that's a different case


Upload countdown.js to a CDN

Issue migrated from Bitbucket...
Looks like cdnjs have a pretty straightforward procedure for this:
https://github.com/cdnjs/cdnjs

@ohadschn - looks like cdnjs is no longer a "straightforward" process!
https://github.com/cdnjs/cdnjs/issues/3638
The old way (manual pull request) is deprecated and the new way (npm / git auto-update) isn't actually working yet.
When it does work, I want to use countdownjs as the lib slug so that it matches bower:
ajax/libs/countdownjs/2.5.2/countdown.min.js

Man, that sucks...
Congrats on the move to GitHub though!

This was satisfied almost a year ago: https://cdnjs.com/libraries/countdown


Calculate n_buffers in FFI_ArrowArray by data layout

Which issue does this PR close?

Closes #1959.
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

Codecov Report

Merging #1960 (0148c41) into master (55d6073) will increase coverage by 0.01%.
The diff coverage is 92.85%.

@@            Coverage Diff             @@
##           master    #1960      +/-   ##
==========================================
+ Coverage   83.47%   83.48%   +0.01%
==========================================
  Files         221      221
  Lines       57054    57113      +59
==========================================
+ Hits        47626    47682      +56
- Misses       9428     9431       +3

Impacted Files
Coverage Δ

arrow/src/array/mod.rs
100.00% <ø> (ø)

arrow/src/ffi.rs
87.07% <92.30%> (+0.10%)
:arrow_up:

arrow/src/array/data.rs
84.40% <100.00%> (+0.24%)
:arrow_up:

arrow/src/compute/kernels/arithmetic.rs
90.61% <0.00%> (-0.26%)
:arrow_down:

parquet/src/file/writer.rs
92.90% <0.00%> (-0.02%)
:arrow_down:

arrow/src/compute/kernels/cast.rs
95.79% <0.00%> (-0.02%)
:arrow_down:

parquet/src/file/metadata.rs
95.15% <0.00%> (+0.02%)
:arrow_up:

parquet/src/encodings/encoding.rs
93.62% <0.00%> (+0.19%)
:arrow_up:

Continue to review full report at Codecov.

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

cc @sunchao

Seems unrelated test failure.
FAILED TEST: datetime Java producing,  C# consuming

Thanks @sunchao


Use NS_ENUM for PTKCardType.

This makes it usable as a Swift enum.

Hey @SlaunchaMan, thanks for the PR. We're actually in the process of deprecating this codebase in favor of https://github.com/stripe/stripe-ios, although I've merged your PR as it's reasonable and backwards-compatible, etc.
stripe-ios now contains a class called STPPaymentCardTextField that duplicates (and improves on) most of the functionality here. I'd strongly encourage you to migrate to that! There's a migration guide in the README here, but feel free to comment here if you have any problems and I'll help you out. Cheers!


Rtp mpeg4

Added support for RTP Mpeg4Reader in Exoplayer

@ManishaJajoo  We can only accept PRs if you sign the CLA. Could you please do that so we can take a look? Thanks!
@claincly  Assigning to you to further handle the PR once the CLA is signed.

Please also add test to RtspMediaTrackTest, targeting processing of the codec specific parsing logic, like the ones added in

CodecSpecificDataUtil
RtspMediaTrack, especially for MPEG4_CODECS, because there was a comment about the missing period.

Also please consider adding the test for RtpMPEG4Reader, for the logics like getBufferFlagsFromVop

Mostly nits

resolved the changes requested

As mentioned in https://github.com/androidx/media/pull/35#issuecomment-1047150026, please add a simple test.

Sure, we will submit the test as a separate PR.


Bump up devfile library on dependent registry test modules

What does this PR do?:
This PR simply bumps up the devfile/library version inside the odov3 and validate_devfile_schemas tests of the devfile/registry to the v2.2.2 version.
It also removes a temporary fix made in the past for 2.2.1 and 2.2.2 schema versions, which is no longer needed as the odo3 check has been fixed.
Which issue(s) this PR fixes:
Fixes https://github.com/devfile/api/issues/1479
It also closes the following EPICs:

https://github.com/devfile/api/issues/1494
https://github.com/devfile/api/issues/1476

PR acceptance criteria:

[ ] Contributing guide
Have you read the devfile registry contributing guide and followed its instructions?
[ ] Test automation
Does this repository's tests pass with your changes?
[ ] Documentation
Does any documentation need to be updated with your changes?
[ ] Check Tools Provider
Have you tested the changes with existing tools, i.e. Odo, Che, Console? (See devfile registry contributing guide on how to test changes)

How to test changes / Special notes to the reviewer:

FYI I've not updated anything on the konflux test as we are under discussions about the future of this check


Station summary fails if date time has no milliseconds

This was an issue that was addressed for the channel_summary but was not addressed for the station_summary.  This has to do with pandas datetime, if a previous input has milliseconds then it expects milliseconds and if there are none it fails, need to add a key word mixed as we have in the channel_summary.

I recall that when the mixed fix was originally implemented for channel summary it solved a specific problem case, but other cases broke and the patch needed an additional update.  The solution on channel summary was to use a try/except strategy where the mixed keyword was one option and the previous syntax was the other.


About Library version

Hello
Can I ask you about your library version such as pytorch or kornia?

Hi,
for PyTorch I used v 1.8.1.
For kornia, I used v 0.5.


nodejs: remove references to build dependencies

Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

@marsam can you take a look please?

@marsam @SuperSandro2000 doesn’t nuke-refs also remove dynamic loader reference? 😬
file /nix/store/ip600n5nk8k1j8kkjwbh35qqg4frkwri-nodejs-20.11.1/bin/node
/nix/store/ip600n5nk8k1j8kkjwbh35qqg4frkwri-nodejs-20.11.1/bin/node: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /nix/store/eeeee
eeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.38-44/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, not stripped

🤔 that's a problem. Let me turn that into removeReferencesTo

This is trickier than I thought. You can follow my progress at #292098. If I can't fix it today, we revert it.


HowTo exclude specificly a file type by negation

Hi,
As far as I've seen you can whitelist file-extensions with ngf-patterns and accept. Is there a possibility to blacklist file-extens or exclude them?
I'm looking for something like: ngf-pattern="'image/*,!.jpg'"
So PNGs or any image can be uploaded, but no JPGs.
Not sure if this is a bug or if I just missed it.
JsFiddle: http://jsfiddle.net/sufius/k6ahsu1n/4/

Added feature to version 7.3.9. Same syntax you mentioned here should work.

thank you very much :+1:

Is the fiddle outdated, I can drop zip and .mov files into the dropzone? I think I'm having this issue, which is how I found this issue.

This seems to fix the error I was experiencing: https://github.com/danialfarid/ng-file-upload/pull/1386. You can test if you use ngf-pattern="'image/*,!.psd'" for example.

@danialfarid, can you reopen this issue as the fiddle above is still not working as expected. Also tested on demo site with same incorrect behavior:


Update network.md

id parameter in file have to be the same as name of file

Hi @piowit,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!


How do I get the response headers?

I'm using this awesome library to work with the Shopify REST API and everything was like a dream, until Shopify threw a wrench and decided to deprecate its limit and page querystring parameters, and phase-in "cursor-based navigation", where they put links to the next page in the response headers.
I can't seem to find anything about response headers... am I missing something, or RestEase needs a new feature for this?
Thanks!

Looks like a case for passing my own httpclient singleton to one of the .For<T>() overloads.

You can use Response<T>?
On 13 September 2019 20:55:33 BST, Mathieu Guindon<EMAIL_ADDRESS>wrote:

Looks like a case for passing my own httpclient singleton to one of the
.For<T>() overloads.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/canton7/RestEase/issues/136#issuecomment-531370487

@Canton7 hm, sounds promising, how would I access it?

Response Message, then get the headers from that.

Ah, looks like I had missed the Response<T> bullet here -- all dots connected, thanks again!

I'll add words like "response headers" to that bit of the README for people searching for that in future.

Turns out I already did this...


Data not found exception

Handle exceptional cases when getting the data counts from Regulations.gov.
DataCounts class raises a DataNotFoundException when Regulations.gov does not return the expected data.
The work generator catches this exception and prints out a message.

This Looks good!


Fix duplicate peers

Noticed after we added discv5, libp2p  emits peer:connected for peer found as bootnodes as well as peer found using some discovery method. I've switched this to listen on peers added to peerStore which filters duplicates.

So whats strange to me is that the other libp2p discovery modules don't check for duplicates either.
It also looks like the libp2p core logic is supposed to handle duplicate connections from discovered peers (when autodial is on):
https://github.com/libp2p/js-libp2p/blob/master/src/index.js#L451

Yeah, I saw that also, it might be that discovery emits before we mannually dial


verify & improve platform specific functions

Verify if use of NSRecursiveLock is OK
Use a proper logger (now it's just println)
write proper unit tests for platform specific functions

I'll close this for now. NSRecursiveLock is OK I think, logger is fixed, I can live without unit tests in this particular case.


PermissionSet#serialize breaks with rdflib.js 0.13.0

copy from gitter: https://gitter.im/solid/chat?at=587168559e6f00e74a0b219f
I don't understand this, solid-permissions in serialize https://github.com/solid/solid-permissions/blame/c60141eaed6d168cf52b13f55fab0afcf5a28fec/src/permission-set.js#L755-L773
does
    let target = null
    let base = null
    return new Promise((resolve, reject) => {
rdf.serialize(target, graph, base, contentType, (err, result) => { //...

and rdflib.js in serialize https://github.com/linkeddata/rdflib.js/blame/master/src/serialize.js#L12
does
base = base || target.uri

which results in "Cannot read property 'uri' of null"
https://github.com/solid/solid-permissions/blob/c60141eaed6d168cf52b13f55fab0afcf5a28fec/package.json#L50
"rdflib": "^0.12.1"
since solid-client depends on "rdflib": "^0.13.0" solid-permissions it uses can't serialize permission set
it looks like @timbl made 17 days ago change to rdflib which made latest rdflib.js incompatible with current implementation of solid-permissions PermissionsSet#serialize
TODO

[ ] update rdflib dev dependency to "0.13.0"
[ ] fix PermissionSet#serialize

merging #15 should solve it!

Could you please check that it is working, @elf-pavlik ?

It seems to me that this issue is solved, since the branch has been merged and we have the same rdflib dep.


Drop usage of internal API when conditionally including assets

Fixes #197 by reversing the logic of how JS/CSS assets are added to pages.
Rather than adding assets to the app and using undocumented API to remove them when not needed, do the exact opposite and only add them to the local html-page-context when building a page that uses the directive.

just realized I forgot to update pytests - should be green now

@foster999 codecov/codecov-action@v1 is probably due for an update since v4.5.0 is the current version. Maybe this will help handline rate limit automagically?

Thanks for this @kartben 😄

@foster999 codecov/codecov-action@v1 is probably due for an update since v4.5.0 is the current version. Maybe this will help handle rate limit and perform retries automagically?

Yes please, might as well sort this at the same time! Failing that, I'd be happy to drop the codecov step in the Actions config for now.
Could you also drop the lines in the change for backwards compatibility with old sphinx (and if needed update the setup.py) please? I've tried to move towards only officially supporting the latest major version of dependencies, as older versions of sphinx-tabs can be used with older dependencies
This part of the code has been rewritten to and from this approach a few times, so I'd also like to understand why it was changed from the approach you've written here last time. I'll try and look back when I get chance, but it would be great if you could review older revisions/PRs to this part of the code to try to understand this also please

Thanks for adding those bits and taking a look back. I think you're right - the old method just added them regardless of use, so the method being replaced here was likely a solution to that
As others have confirmed the issue is resolved, I'll get it merged and released once everything is passing

@foster999 I think we should be back on track.
Updated pre-commit.ci to fetch more recent versions of black, pylint, etc. since one of the errors was actually a hard crash due to a too old pylint version being pulled in and not being compatible with Python 3.12
Also dropped bad-continuation as per the warning that was showing up before the crash.
pre-commit run -a now passes locally
$ pre-commit  run -a
check json...............................................................Passed
check yaml...............................................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
check-manifest...........................................................Passed
black....................................................................Passed
pylint...................................................................Passed

@foster999 if/when you get a chance to take another look that'd be great as the warning is polluting our build logs making it harder to spot any real issue. Thanks!

Sorry for the huge delay getting round to this! Now included in version 3.4.6

Sorry for the huge delay getting round to this! Now included in version 3.4.6

Awesome, thanks! Do you have a sense of when this will be available through pypi? Thanks!

Deployment failed for that one, but it's now up on PyPI as 3.4.7 ☺

Sorry for the huge delay getting round to this! Now included in version 3.4.6

@foster999, no worries at all, thanks for your work as maintainer and also thanks again @kartben for the PR!


Github release?

I see actions are already set up and artifacts are uploaded – https://github.com/lazamar/haskell-docs-cli/actions/runs/11043126886 worked on my machine. It would be nice if they ended up in Releases so people can see how easy it is to use :-)
(Last time I set releases up with Actions it looked like https://github.com/unhammer/bin-your-stars/blob/master/.github/workflows/release.yml but I'm no expert)

The current hackage doesn't build for me:
src/Main.hs:73:42: error: [GHC-76037]
    Not in scope: ‘OP.linebreak’
    NB: the module ‘Options.Applicative.Help.Pretty’ does not export ‘linebreak’.
   |
73 |   , O.footerDoc $ Just $ moreInfoText <> OP.linebreak
   |                                          ^^^^^^^^^^^^

but this problem is fixed in git

Good idea. I finally got around to it. First release is out.
https://github.com/lazamar/haskell-docs-cli/releases/tag/v<IP_ADDRESS>


Copying buffers is slow

Copying buffers is slow in node (and maybe everywhere else), so I suggest using bl which does almost the same thing of CircularBuffer but instead maintains the original Buffer objects without copying them.
cc @teomurgi

Yeah, when I first took a dependency on CircularBuffer I assumed they were using a buffer list internally (because that makes sense, right?).  Only later did I dig in and find out the awful truth.  It's been on my list to think about replacing it, so thanks for the recommendation, I'll check into it.


Update Button Not Working Properly

Getting Message Internal Server Error on Save Changes Button

assigned to @samjain233

In index.ejs file
changedmethod: "POST", to method: "PUT",
and added the header for json file format headers: { "Content-Type": "application/json" },
In index.js file
added fetchuser middleware in the put route
BEFORE UPDATE :

AFTER UPDATE

@samjain233, I guess you're too late! 😂

assigned to @Ayush-kumar0


Defender 1.4 & Check for Sensitive Users, Groups, and Domains

🗣 Description
Check Users, groups, & domains for Strict EOP against Config file.
💭 Motivation and context

Confirms Strict EOP exists
User can indicate Users, groups, & domains that must be protected
Still passes if there are more users, groups, & domains protected than indicated in the config file.
closing #486

🧪 Testing

Unit Tests
Cisanet

✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] All future TODOs are captured in issues, which are referenced
in code comments.
[x] All relevant type-of-change labels have been added.
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[x] All relevant repo and/or project documentation has been updated
to reflect the changes in this PR.
[x] Tests have been added and/or modified to cover the changes in this PR.
[x] All new and existing tests pass.

✅ Pre-merge checklist

[ ] Revert dependencies to default branches.
[ ] Finalize version.

✅ Post-merge checklist

[ ] Create a release.

@Sloane4 I just saw that you marked this as a draft. Should I hold off on reviewing?

@adhilto, yeah I made an incorrect assumption & the fix causes a big change so I have it in draft until the change is finished.

@adhilto & @schrolla ready for review

@nanda-katikaneni ready for merge


Can I use it with 1.3.0 Angular ?

How can I make it working for 1.3.0?

Thanks all -- this should definitely be working, please feel free to re-open if you can recreate with a basic plunker


fixing route for tutorial after renaming

@onbjerg hey sry missed the renaming of the path :)

You should also rename the file itself :smile:

think i did that. this one you mean? https://github.com/onbjerg/foundry-book/blob/master/src/tutorials/solmate-nft.md

Ahh, my bad!


feat: GardenMetadata objects have modal function metadata (like entrypoints)

Note: as of #143, the DB entities for modal functions and apps are defined, but none of the /gardens routes or schemas are modal-aware yet.
Acceptance

payload returned by GET /gardens should have metadata for ModalFunctions, like it does for Entrypoints
general "entrypoint parity" for our /gardens routes. if e.g. PATCH /gardens doesn't know about entrypoints it doesn't need to think about modal functions either

duplicate of #148


Show how to access data passed into the modal

This addition shows how to access the data that is passed into the modal through the Modal.Create() method.

thanks!


Beta Support

Hi, really love your work!!!!
the best CR downloader i had to use!
I want to suggest some thing:

Beta Support
Funimation Support

Thank you for your Hard Work!

Thanks for your compliments, the world just needed another (good xD) crunchy downloader & go api :)
Beta support is already implemented in the api but not in the command line interface. I look forward to add it within the next few days.
Funimation support won't be implemented since this is only a crunchy downloader. Besides this, in my country I have no access to funimation nor I know in another person in a (funimation supported) country with a funimation account who could help me

Beta url support is now available in version v1.2.3

I can give account for funi, if you can make that it will be really great. And idk how, another downloaders downloading the video at 1.5mb/s if you have luck.
And yours just fast as f!!!
Really ty!

Where r u from btw?

Germany

I can give account for funi, if you can make that it will be really great. And idk how, another downloaders downloading the video at 1.5mb/s if you have luck. And yours just fast as f!!! Really ty!

I'm currently working on another project, so maybe after this i'll come back to your offer :)
And i don't know how the other downloaders are working but crunchyroll-go uses 4 goroutines by default to download which means that the anime (which is splitted into 715 - 720 tiny video files, or called segments) download performs 4 parallel segment downloads at the same time. It may be so fast because of this ¯_(ツ)_/¯


module: LVGL: Improve support for hardware display rotation

Originally brought up within #73474 this PR tries to improve the support for hardware based display rotation during runtime.
Since in the past few weeks quite a few bugfixes in regards to pointer input device handling were merged it would be useful to have them properly unit tested.
Test output:
===================================================================
START - test_no_rotation
        Expected: x:20 y:150
        Press:    x:20 y:150
        Release:  x:20 y:150
 PASS - test_no_rotation in 0.001 seconds
===================================================================
START - test_rotation_180
        Expected: x:300 y:90
        Press:    x:300 y:90
        Release:  x:300 y:90
 PASS - test_rotation_180 in 0.001 seconds
===================================================================
START - test_rotation_270
        Expected: x:150 y:300
        Press:    x:150 y:300
        Release:  x:150 y:300
 PASS - test_rotation_270 in 0.001 seconds
===================================================================
START - test_rotation_90
        Expected: x:90 y:20
        Press:    x:90 y:20
        Release:  x:90 y:20
 PASS - test_rotation_90 in 0.001 seconds
===================================================================

Perhaps the test can be expanded to take into account correct rotation initialisation based on the various rotation dts values as well? Like: looping through all dts values and then checking if the input values match. That way the updated LVGL init code is also tested.

@Snevzor neat idea but I fear that this would mean that I'd have to add an overlay on for each rotation and do some messy things with skipping tests I pressume. Could be wrong though :^).
Btw I added a DNM label for now since I want  to clarify the discussion around #73360 first.

@faxe1008 apologies for the necromancy here- It seems like this PR is the start of what we would need to standardize how rotation works within Zephyr (IE if the display driver should be swapping x/y parameters when rotated, or if the consumer of the display API should be handling this)
Do you still want to move this forwards? It seems like we'd need this, as well as changes to the gc9x01x and ili9xxx drivers to align them with the remainder of the codebase

@faxe1008 please let me know if you need some assistance, I definitely want to help where possible.

Heyhey @danieldegrasse and @Snevzor yes eventually I want to continue working on that issue, either by contributing or reviewing, if someone feels inspired to take this up in the meantime. I want to first finish up the update of the module its self since this has been sitting on my plate quite some time now before moving on to other issues. Can you maybe spare some time to look at https://github.com/zephyrproject-rtos/zephyr/pull/81263?


how can i improve the accuracy for this model and could anyone help me to increase the loss percentage

how can i improve the accuracy for this model and could anyone help me to increase the loss percentage.
Thanking you !

[session 1][epoch 25][iter  100/ 107] loss: 0.3858, lr: 1.00e-07
fg/bg=(4/1020), time cost: 2159.435124
rpn_cls: 0.0213, rpn_box: 0.1552, rcnn_cls: 0.0151, rcnn_box 0.0000
save model: models/vgg16/pascal_voc/faster_rcnn_1_25_106.pth
please tell any suggestion for decrease the accuracy

It's too late. Reduce your learning rate!!
lr=0.002 epoch 3 times
I got a loss of 0.55 !!


Refactor actors to use new client

Description
Refactors actors to use the new dapr client
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to
implementation.
Please reference the issue this PR: #36
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[ ] Tests pass
[ ] Created/updated tests
[ ] Extended the documentation

Codecov Report

Merging #104 (aa4f348) into main (e7968b9) will decrease coverage by 1.59%.
The diff coverage is 77.66%.

:exclamation: Current head aa4f348 differs from pull request most recent head 31dcdc7. Consider uploading reports for the commit 31dcdc7 to get more accurate results

@@             Coverage Diff              @@
##               main     #104      +/-   ##
============================================
- Coverage     78.20%   76.61%   -1.60%
- Complexity      499      530      +31
============================================
  Files            63       64       +1
  Lines          1606     1732     +126
============================================
+ Hits           1256     1327      +71
- Misses          350      405      +55

Impacted Files
Coverage Δ

src/lib/Client/DaprClient.php
53.84% <ø> (ø)

src/lib/Client/DaprHttpClient.php
53.84% <0.00%> (-4.49%)
:arrow_down:

src/lib/Client/HttpBindingTrait.php
0.00% <ø> (ø)

src/lib/Client/HttpInvokeTrait.php
0.00% <ø> (ø)

src/lib/Client/HttpPubSubTrait.php
100.00% <ø> (ø)

src/lib/Client/HttpSecretsTrait.php
100.00% <ø> (ø)

src/lib/Client/HttpStateTrait.php
81.03% <ø> (ø)

src/lib/Actors/ActorTrait.php
23.07% <60.00%> (-31.47%)
:arrow_down:

src/lib/Client/HttpActorTrait.php
72.97% <72.97%> (ø)

src/lib/Actors/Reminder.php
85.18% <81.25%> (-7.13%)
:arrow_down:

... and 8 more

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 e7968b9...31dcdc7. Read the comment docs.

Codecov Report

Merging #104 (0c6981b) into main (e7968b9) will decrease coverage by 1.71%.
The diff coverage is 79.04%.

@@             Coverage Diff              @@
##               main     #104      +/-   ##
============================================
- Coverage     78.20%   76.48%   -1.72%
- Complexity      499      530      +31
============================================
  Files            63       64       +1
  Lines          1606     1731     +125
============================================
+ Hits           1256     1324      +68
- Misses          350      407      +57

Impacted Files
Coverage Δ

src/lib/Actors/Generators/GenerateProxy.php
100.00% <ø> (ø)

src/lib/Client/DaprClient.php
53.84% <ø> (ø)

src/lib/Client/DaprHttpClient.php
53.84% <0.00%> (-4.49%)
:arrow_down:

src/lib/Client/HttpBindingTrait.php
0.00% <ø> (ø)

src/lib/Client/HttpInvokeTrait.php
0.00% <ø> (ø)

src/lib/Client/HttpPubSubTrait.php
100.00% <ø> (ø)

src/lib/Client/HttpSecretsTrait.php
100.00% <ø> (ø)

src/lib/Client/HttpStateTrait.php
81.03% <ø> (ø)

src/lib/Actors/ActorTrait.php
23.07% <60.00%> (-31.47%)
:arrow_down:

src/lib/Client/HttpActorTrait.php
72.97% <72.97%> (ø)

... and 13 more

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 e7968b9...0c6981b. Read the comment docs.

Codecov Report

Merging #104 (412c771) into main (e7968b9) will decrease coverage by 1.15%.
The diff coverage is 88.59%.

:exclamation: Current head 412c771 differs from pull request most recent head 80744c5. Consider uploading reports for the commit 80744c5 to get more accurate results

@@             Coverage Diff              @@
##               main     #104      +/-   ##
============================================
- Coverage     78.20%   77.05%   -1.16%
- Complexity      499      535      +36
============================================
  Files            63       64       +1
  Lines          1606     1739     +133
============================================
+ Hits           1256     1340      +84
- Misses          350      399      +49

Impacted Files
Coverage Δ

src/lib/Actors/Generators/GenerateProxy.php
100.00% <ø> (ø)

src/lib/Client/DaprClient.php
53.84% <ø> (ø)

src/lib/Client/DaprHttpClient.php
53.84% <0.00%> (-4.49%)
:arrow_down:

src/lib/Client/HttpBindingTrait.php
0.00% <ø> (ø)

src/lib/Client/HttpInvokeTrait.php
0.00% <ø> (ø)

src/lib/Client/HttpPubSubTrait.php
100.00% <ø> (ø)

src/lib/Client/HttpSecretsTrait.php
100.00% <ø> (ø)

src/lib/Client/HttpStateTrait.php
81.03% <ø> (ø)

src/lib/Actors/ActorTrait.php
23.07% <60.00%> (-31.47%)
:arrow_down:

src/lib/Deserialization/Deserializer.php
91.78% <60.00%> (-6.66%)
:arrow_down:

... and 26 more

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 e7968b9...80744c5. Read the comment docs.


Coloring for directories

This makes the distinction between files and directories much clearer.  Why didn't I think of this?


build: Update Vulkan-Headers and VUL to 1.3.280

CI Vulkan-ExtensionLayer build queued with queue ID 147430.

CI Vulkan-ExtensionLayer build # 862 running.

CI Vulkan-ExtensionLayer build # 862 passed.


All exec's after were privileged by default. That is NOT okay IMO. Until we can find a way to reset the container to its original state after a privileged exec, I say we revert this.
ping @ewindisch @diogomonica @crosbymichael @tiborvass

Hmm, this is not my experience.
$ docker run -d --name test busybox top
8b307baeb3e4bd300a3ecb7a427afec22387a15e4f170781dcca39411c911463
$ docker exec --privileged -it test sh
# mkdir /test
# mount --bind /tmp /test
# exit
$ docker exec test umount /test
umount: can't umount /test: Operation not permitted
$ docker exec --privileged test umount /test
$

I can do it numerous times on mine just by editinng that test and trying
again unpriviledged
On Tue, May 26, 2015 at 2:13 PM, Brian Goff<EMAIL_ADDRESS>wrote:

Hmm, this is not my experience.
$ docker run -d --name test busybox top
8b307baeb3e4bd300a3ecb7a427afec22387a15e4f170781dcca39411c911463
$ docker exec --privileged -it test sh
mkdir /test
mount --bind /tmp /test
exit
$ docker exec test umount /test
umount: can't umount /test: Operation not permitted
$ docker exec --privileged test umount /test
$
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/13491#issuecomment-105666235.

literally just add the check back to make sure mknod doesnt work
unnpriviledged in the test thaat was added and you will see
On Tue, May 26, 2015 at 2:20 PM, Jessie Frazelle<EMAIL_ADDRESS>wrote:

I can do it numerous times on mine just by editinng that test and trying
again unpriviledged
On Tue, May 26, 2015 at 2:13 PM, Brian Goff<EMAIL_ADDRESS>wrote:

Hmm, this is not my experience.
$ docker run -d --name test busybox top
8b307baeb3e4bd300a3ecb7a427afec22387a15e4f170781dcca39411c911463
$ docker exec --privileged -it test sh
mkdir /test
mount --bind /tmp /test
exit
$ docker exec test umount /test
umount: can't umount /test: Operation not permitted
$ docker exec --privileged test umount /test
$
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/13491#issuecomment-105666235.

btw, your examplle i can umount... maybe it is my kernel... but this patch makes me kinda naeusous

LGTM, let's add this back once we feel more comfortable

Just want to make sure you are ok with --user which was also added by the same pr?

I'm fine with --user, but --privileged is a bit scary. LGTM.

ya i kept that I think its fine
On Tue, May 26, 2015 at 3:00 PM, Brian Goff<EMAIL_ADDRESS>wrote:

Just want to make sure you are ok with --user which was also added by the
same pr?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/13491#issuecomment-105679287.

LGTM

LGTM

@jfrazelle I'm trying to find the bug that prompted this PR so the functionality can be remerged. I missed that this PR had partially undone #12025, so I was patiently waiting for the functionality in the 1.7.0 release.
I've modified the test based on your description above, but it passes:
func (s *DockerSuite) TestExecWithPrivileged(c *check.C) {

	runCmd := exec.Command(dockerBinary, "run", "-d", "--name", "parent", "--cap-drop=ALL", "busybox", "top")
	if out, _, err := runCommandWithOutput(runCmd); err != nil {
		c.Fatal(out, err)
	}

	cmd := exec.Command(dockerBinary, "exec", "parent", "sh", "-c", "mknod /tmp/sda b 8 0")
	out, _, err := runCommandWithOutput(cmd)
	if err == nil || !strings.Contains(out, "Operation not permitted") {
		c.Fatalf("exec mknod in --cap-drop=ALL container without --privileged should fail")
	}

	cmd = exec.Command(dockerBinary, "exec", "--privileged", "parent", "sh", "-c", "mknod /tmp/sda b 8 0 && echo ok")
	out, _, err = runCommandWithOutput(cmd)
	if err != nil {
		c.Fatal(err, out)
	}

	if actual := strings.TrimSpace(out); actual != "ok" {
		c.Fatalf("exec mknod in --cap-drop=ALL container with --privileged failed: %v, output: %q", err, out)
	}

	cmd = exec.Command(dockerBinary, "exec", "parent", "sh", "-c", "mknod /tmp/sdb b 8 16")
	out, _, err = runCommandWithOutput(cmd)
	if err == nil || !strings.Contains(out, "Operation not permitted") {
		c.Fatalf("repeating exec mknod in --cap-drop=ALL container after --privileged without --privileged should fail")
	}

}

Can you provide any more information so I can produce a failing test and fix it?

This made the entire container privileged. Which is NOT ok so test for that
On Friday, June 19, 2015, Tim Dettrick<EMAIL_ADDRESS>wrote:

@jfrazelle https://github.com/jfrazelle I'm trying to find the bug that
prompted this PR so the functionality can be remerged. I missed that this
PR had partially undone #12025
https://github.com/docker/docker/pull/12025, so I was patiently waiting
for the functionality in the 1.7.0 release.
I've modified the test based on your description above, but it passes:
func (s *DockerSuite) TestExecWithPrivileged(c *check.C) {
runCmd := exec.Command(dockerBinary, "run", "-d", "--name", "parent", "--cap-drop=ALL", "busybox", "top")
if out, _, err := runCommandWithOutput(runCmd); err != nil {
    c.Fatal(out, err)
}

cmd := exec.Command(dockerBinary, "exec", "parent", "sh", "-c", "mknod /tmp/sda b 8 0")
out, _, err := runCommandWithOutput(cmd)
if err == nil || !strings.Contains(out, "Operation not permitted") {
    c.Fatalf("exec mknod in --cap-drop=ALL container without --privileged should fail")
}

cmd = exec.Command(dockerBinary, "exec", "--privileged", "parent", "sh", "-c", "mknod /tmp/sda b 8 0 && echo ok")
out, _, err = runCommandWithOutput(cmd)
if err != nil {
    c.Fatal(err, out)
}

if actual := strings.TrimSpace(out); actual != "ok" {
    c.Fatalf("exec mknod in --cap-drop=ALL container with --privileged failed: %v, output: %q", err, out)
}

cmd = exec.Command(dockerBinary, "exec", "parent", "sh", "-c", "mknod /tmp/sdb b 8 16")
out, _, err = runCommandWithOutput(cmd)
if err == nil || !strings.Contains(out, "Operation not permitted") {
    c.Fatalf("repeating exec mknod in --cap-drop=ALL container after --privileged without --privileged should fail")
}

}
Can you provide any more information so I can produce a failing test and
fix it?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/13491#issuecomment-113405771.

The test is somewhat more complicated now, but it checks that the main run doesn't acquire privileged access while docker exec --privileged is running, or after.
func (s *DockerSuite) TestExecWithPrivileged(c *check.C) {

	// Start main loop which attempts mknod repeatedly
	runCmd := exec.Command(dockerBinary, "run", "-d", "--name", "parent", "--cap-drop=ALL", "busybox", "sh", "-c", "while (true); do if [ -e /exec_priv ]; then cat /exec_priv && mknod /tmp/sda b 8 0 && echo \"Success\"; else echo \"Privileged exec has not run yet\"; fi; usleep 10000; done")
	if out, _, err := runCommandWithOutput(runCmd); err != nil {
		c.Fatal(out, err)
	}

	// Check exec mknod doesn't work
	cmd := exec.Command(dockerBinary, "exec", "parent", "sh", "-c", "mknod /tmp/sdb b 8 16")
	out, _, err := runCommandWithOutput(cmd)
	if err == nil || !strings.Contains(out, "Operation not permitted") {
		c.Fatalf("exec mknod in --cap-drop=ALL container without --privileged should fail")
	}

	// Check exec mknod does work with --privileged
	cmd = exec.Command(dockerBinary, "exec", "--privileged", "parent", "sh", "-c", "echo \"Running exec --privileged\" > /exec_priv && mknod /tmp/sdb b 8 16 && usleep 50000 && echo \"Finished exec --privileged\" > /exec_priv && echo ok")
	out, _, err = runCommandWithOutput(cmd)
	if err != nil {
		c.Fatal(err, out)
	}

	if actual := strings.TrimSpace(out); actual != "ok" {
		c.Fatalf("exec mknod in --cap-drop=ALL container with --privileged failed: %v, output: %q", err, out)
	}

	// Check subsequent unprivileged exec cannot mknod
	cmd = exec.Command(dockerBinary, "exec", "parent", "sh", "-c", "mknod /tmp/sdc b 8 32")
	out, _, err = runCommandWithOutput(cmd)
	if err == nil || !strings.Contains(out, "Operation not permitted") {
		c.Fatalf("repeating exec mknod in --cap-drop=ALL container after --privileged without --privileged should fail")
	}

	// Confirm at no point was mknod allowed
	logCmd := exec.Command(dockerBinary, "logs", "parent")
	if out, _, err := runCommandWithOutput(logCmd); err != nil || strings.Contains(out, "Success")  {
		c.Fatal(out, err)
	}

}

It also passes. Branch incorporating it:
https://github.com/dit4c/docker/tree/exec-privileged
@jfrazelle Can you recommend anything else to detect the erroneous behaviour you've described?


Update Asynchronic Link changes

Coverage decreased (-0.6%) to 99.308% when pulling a728788cde1172447ab459b3e342c972f5f91c0d on issue_51 into c590305dfa0a3fefe0bdc65d722a44fca78df34f on supplier-declaration.


Skip deploy for testing kjar

there is no need to deploy
the kjar as it's just used for
testing

This should fix the deploy we are seeing. However, it's just quick&dirty fix. We need to come with a better solution.
cc @mariofusco, @baldimir

+1 for merge. Agree on that we need to find a better solution. Ideally the kjar shouldn't be part of the Maven reactor build and should be built and handled by the test that uses it.


feat: ADR-004 tips contract

This PR implements the tips contract as described in the ADR-004

I would also like @RiccardoM to give a look at it if he has some time

I add Riccardo as reviewer.
@bragaz I have also made some minor changes to make the ServiceFee Optional to allow the contract to not take any fees from the tipped amount in a more clear way insted of using a 0 ServiceFee:.Percentage or an empty ServiceFee::Fixed

The contract has changed a little bit after talking with @bragaz regarding how the tip history should be kept.
Before the contract was using the threshold value to limit the total number of tips memorized in the contract state, now that value is used to limit the history of tips sent and received from a user.
Please @bragaz take another look at it.
Also since now i keep the block height to sort the tips from the oldest to the latest we can return that information when querying the tips what do you think guys?

There are typos that found should be fund.

After having a call with @bragaz we need to change some behaviour of this contract and the ADR-004. I close this PR for now


Weird conflict with "femmployee" mod, maybe not only

Hello!
After your last rewrite of the mod we caught a bug, where GUI of that mod, where you can customise the model of that mod, isnt opening, and throw NullReferenceException in console every time that suit is worn/unworn. And that seems to happen only if you load into ship first time since launch, by accident i noticed that if you return in main menu and then load into ship again problem disappears.
By trying to track last changes in our modpack i clued it causes by this mod after last update, if rollback your mod to previous version this bug disappears. Maybe something also might be broken after rewrite but we dont tested game further with it, so cant say :D

Idk still why that issue was triggered only after rewrite but turned out conflict of these 2 modes was driven by Hayrizan's XUnity AutoTranslator(which was only one mod besides those 2 which was left turned on when was testing conflict), and maybe a dozen or two another semi-hidden issues in our modpack. -_-

Idk still why that issue was triggered only after rewrite but turned out conflict of these 2 modes was driven by Hayrizan's XUnity AutoTranslator(which was only one mod besides those 2 which was left turned on when was testing conflict), and maybe a dozen or two another semi-hidden issues in our modpack. -_-


suit_create_es256_public_key should include key length

Currently, the suit_create_es256_public_key() function assumes ECC keys based on NIST P256r1. We should make this function more generic to also use other key sizes.
The function can be found in https://github.com/yuichitk/libcsuit/blob/master/src/suit_cose.c

I created 1 commit to solve this issue.
In addition to this, I realized we need another commits like in PR #12 to solve compile errors raised by my definition changes.


[Retro] [API] Endpoints for CRUD of collections

https://en.numista.com/forum/topic118560.html

Implemented by Numista On March 29th


Adding a fix for #267.

In #267 I described the incorrect behaviour, when generating DDLs with characters in name that are used for escaping on different plattforms. This is an attempt to fix it.
I tested the behaviour and it corrects the script generation with the base (PostgreSQL, SQLite) and MySQL escaping behaviour.
MSSQL seems to behave like standard despite having separate escaping, so I didn't touch it. I was able to test with driver Pdo_SqlServer, perhaps it uses the escaping with brackets, if Sqlsrv driver is used, but I couldn't test it, because I don't have the corresponding extension installed. I get the RuntimeException with message The Sqlsrv extension is required for this adapter but the extension is not loaded. @alextech Can you test the example in #267 and add the [] brackets to every named element? If it uses the brackets for escaping and is wrong, is it fixed, if you change in Zend\Db\Adapter\Platform\SqlSserver $quoteIdentifierTo to
    protected $quoteIdentifierTo = '[]';

At least from my tests SQL Management Studio escapes the opening bracket in names by adding the closing bracket to it, when I generate a CREATE TABLE script.

I'll work on unit test next week. Thx for the first review!

@mwillbanks I finally found time to add the unit tests. Are they ok in that form?

This repository has been moved to laminas/laminas-db. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

Squash all commits in your branch (git rebase -i origin/{branch})
Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
Run the laminas/laminas-migration tool on the code.
Clone laminas/laminas-db to another directory.
Copy the files from the second bullet point to the clone of laminas/laminas-db.
In your clone of laminas/laminas-db, commit the files, push to your fork, and open the new PR.
We will be providing tooling via laminas/laminas-migration soon to help  automate the process.


Crash in destroy for AsyncChain2Sequence?

Using 0.1.0 of the library I sometimes get a crash (EXC_BAD_ACCESS (code=1, address=0xf2575c505790)) in iterator next(), see example of call stack below (caught from Xcode while debugging). Any ideas what might cause this? In the call stack below I was using a type erasers from: https://github.com/pointfreeco/swift-concurrency-extras, such as:
extension AsyncThrowingStream where Failure == Error {
  /// Produces an `AsyncThrowingStream` from an `AsyncSequence` by consuming the sequence till it
  /// terminates, rethrowing any failure.
  ///
  /// - Parameter sequence: An async sequence.
  public init<S: AsyncSequence>(_ sequence: S) where S.Element == Element {
    var iterator: S.AsyncIterator?
    self.init {
      if iterator == nil {
        iterator = sequence.makeAsyncIterator()
      }
      return try await iterator?.next()
    }
  }

#0	0x000000019035520c in _swift_release_dealloc ()
apple/swift-async-algorithms#1	0x0000000190355f00 in bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) ()
apple/swift-async-algorithms#2	0x00000001020a1eb4 in destroy for AsyncChain2Sequence ()
apple/swift-async-algorithms#3	0x00000001020de454 in destroy for AsyncRemoveDuplicatesSequence ()
apple/swift-async-algorithms#4	0x00000001020590c8 in ___lldb_unnamed_symbol212959 ()
apple/swift-async-algorithms#5	0x0000000190355224 in _swift_release_dealloc ()
apple/swift-async-algorithms#6	0x0000000190355f00 in bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) ()
apple/swift-async-algorithms#7	0x000000021f85c23c in closure apple/swift-async-algorithms#1 in closure apple/swift-async-algorithms#1 in AsyncStream.init(unfolding:onCancel:) ()
apple/swift-async-algorithms#8	0x000000021f873df0 in partial apply for closure apple/swift-async-algorithms#1 in closure apple/swift-async-algorithms#1 in AsyncStream.init(unfolding:onCancel:) ()
apple/swift-async-algorithms#9	0x000000021f851b20 in withTaskCancellationHandler<τ_0_0>(operation:onCancel:) ()
apple/swift-async-algorithms#10	0x000000021f84ffa0 in withTaskCancellationHandler<τ_0_0>(operation:onCancel:) ()
apple/swift-async-algorithms#11	0x000000021f85bd74 in closure apple/swift-async-algorithms#1 in AsyncStream.init(unfolding:onCancel:) ()
apple/swift-async-algorithms#12	0x000000021f873db0 in partial apply for closure apple/swift-async-algorithms#1 in AsyncStream.init(unfolding:onCancel:) ()
apple/swift-async-algorithms#13	0x000000021f85c4c8 in AsyncStream.Iterator.next() ()
apple/swift-async-algorithms#14	0x000000021f873da4 in protocol witness for AsyncIteratorProtocol.next() in conformance AsyncStream<τ_0_0>.Iterator ()
apple/swift-async-algorithms#15	0x000000021f83a954 in AsyncCompactMapSequence.Iterator.next() ()
apple/swift-async-algorithms#16	0x000000021f873e00 in protocol witness for AsyncIteratorProtocol.next() in conformance AsyncCompactMapSequence<τ_0_0, τ_0_1>.Iterator ()
apple/swift-async-algorithms#17	0x000000021f865734 in dispatch thunk of AsyncIteratorProtocol.next() ()
apple/swift-async-algorithms#18	0x0000000102058e14 in closure apple/swift-async-algorithms#1 in AsyncStream.init<τ_0_0>(_:) at /Users/mansbernhardt/Library/Developer/Xcode/DerivedData/Gigset-gkrmpjneavqivdheptpucovbtxjv/SourcePackages/checkouts/swift-concurrency-extras/Sources/ConcurrencyExtras/AsyncStream.swift:59
apple/swift-async-algorithms#19	0x00000001020591b0 in partial apply for closure apple/swift-async-algorithms#1 in AsyncStream.init<τ_0_0>(_:) ()
apple/swift-async-algorithms#20	0x000000021f85c144 in closure apple/swift-async-algorithms#1 in closure apple/swift-async-algorithms#1 in AsyncStream.init(unfolding:onCancel:) ()
apple/swift-async-algorithms#21	0x000000021f873df0 in partial apply for closure apple/swift-async-algorithms#1 in closure apple/swift-async-algorithms#1 in AsyncStream.init(unfolding:onCancel:) ()
apple/swift-async-algorithms#22	0x000000021f851b20 in withTaskCancellationHandler<τ_0_0>(operation:onCancel:) ()
apple/swift-async-algorithms#23	0x000000021f84ffa0 in withTaskCancellationHandler<τ_0_0>(operation:onCancel:) ()
apple/swift-async-algorithms#24	0x000000021f85bd74 in closure apple/swift-async-algorithms#1 in AsyncStream.init(unfolding:onCancel:) ()
apple/swift-async-algorithms#25	0x000000021f873db0 in partial apply for closure apple/swift-async-algorithms#1 in AsyncStream.init(unfolding:onCancel:) ()
apple/swift-async-algorithms#26	0x000000021f85c4c8 in AsyncStream.Iterator.next() ()
apple/swift-async-algorithms#27	0x000000021f873da4 in protocol witness for AsyncIteratorProtocol.next() in conformance AsyncStream<τ_0_0>.Iterator ()
apple/swift-async-algorithms#28	0x000000021f865734 in dispatch thunk of AsyncIteratorProtocol.next() ()
apple/swift-async-algorithms#29	0x0000000102059fd8 in closure apple/swift-async-algorithms#1 in AsyncThrowingStream<>.init<τ_0_0>(_:) at /Users/mansbernhardt/Library/Developer/Xcode/DerivedData/Gigset-gkrmpjneavqivdheptpucovbtxjv/SourcePackages/checkouts/swift-concurrency-extras/Sources/ConcurrencyExtras/AsyncThrowingStream.swift:12
apple/swift-async-algorithms#30	0x000000010205a340 in partial apply for closure apple/swift-async-algorithms#1 in AsyncThrowingStream<>.init<τ_0_0>(_:) ()
apple/swift-async-algorithms#31	0x000000021f85d5ec in closure apple/swift-async-algorithms#1 in closure apple/swift-async-algorithms#1 in AsyncThrowingStream.init<>(unfolding:) ()
apple/swift-async-algorithms#32	0x000000021f873de4 in partial apply for closure apple/swift-async-algorithms#1 in closure apple/swift-async-algorithms#1 in AsyncThrowingStream.init<>(unfolding:) ()
apple/swift-async-algorithms#33	0x000000021f851b20 in withTaskCancellationHandler<τ_0_0>(operation:onCancel:) ()
apple/swift-async-algorithms#34	0x000000021f84ffa0 in withTaskCancellationHandler<τ_0_0>(operation:onCancel:) ()
apple/swift-async-algorithms#35	0x000000021f85d19c in closure apple/swift-async-algorithms#1 in AsyncThrowingStream.init<>(unfolding:) ()
apple/swift-async-algorithms#36	0x000000021f873dd4 in partial apply for closure apple/swift-async-algorithms#1 in AsyncThrowingStream.init<>(unfolding:) ()
apple/swift-async-algorithms#37	0x000000021f85d9b0 in AsyncThrowingStream.Iterator.next() ()
apple/swift-async-algorithms#38	0x00000001023d54a0 in closure apple/swift-async-algorithms#3 in AsyncView.body.getter at /Users/mansbernhardt/dev/gigset-apple4/gigset/Sources/ViewUtilities/AsyncView.swift:30
apple/swift-async-algorithms#39	0x00000001023d68d8 in partial apply for closure apple/swift-async-algorithms#3 in AsyncView.body.getter ()

We are also seeing Intel Macs running 12.x with this crash logs (release builds), not sure if they might be related:
Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace SIGNAL, Code 4 Illegal instruction: 4

Thread 4 Crashed:
0   libswiftCore.dylib            	0x00007ff828033245 _assertionFailure(_:_:file:line:flags:) + 421 (AssertCommon.swift:132)
1   libswift_Concurrency.dylib    	0x00007ffb34060b64 AsyncStream._Storage.next(_:) + 532 (AsyncStreamBuffer.swift:253)
2   libswift_Concurrency.dylib    	0x00007ffb340735ec partial apply for closure apple/swift-async-algorithms#2 in AsyncStream._Storage.next() + 188 (<compiler-generated>:0)
3   libswift_Concurrency.dylib    	0x00007ffb340742e1 thunk for @callee_guaranteed @async () -> (@out A?) + 1

@phausler could you take a look at this

AsyncStream._Storage.next(_:) no longer has an assert in it. Previously this was asserting that the consumption did not happen on more than one task. However that assertion could not be truly held in all cases (why it was removed).

The root cause of the reported crash seems as if it is the destruction from the unfolding; my guess is that the iterator being sent is not actually Sendable and w/o the Sendable enforcements in place it is hitting a non-thread-safe usage of the capture of var iterator: S.AsyncIterator?.
Erasing to an AnyAsyncSequence using AsyncStream as a vehicle via that type of pattern can easily lead to missteps as such. The Sendable nature of the iterator in this case is non-trivial and should be held in a critical region (for example OSAllocatedUnfairLock) if you really need this type of behavior.

here is the "corrected" code... however it would be considerably better to wait for the some AsyncSequence<Element, Never> etc when it is available.
  public init<S: AsyncSequence>(_ sequence: S) where S.Element == Element, S: Sendable {
    let iterator = OSAllocatedUnfairLock<S.AsyncIterator?>(uncheckedState: nil)
    self.init {
      // NOTE: this has a time of check/time of use bug lurking
      // if two tasks call next concurrently the iterator will
      // be in the wrong state
      var iter = iterator.withLock { $0 }
      if iter == nil {
        iter = sequence.makeAsyncIterator()
      }
      defer { iterator.withLockUnchecked { $0 = iter } }
      return try await iter?.next()
    }
  }

@phausler

AsyncStream.Storage.next(:) no longer has an assert in it. Previously this was asserting that the consumption did not happen on more than one task. However that assertion could not be truly held in all cases (why it was removed). So no; that is not related.

In what OS version of macOS, iOS, tvOS was this assert removed?
This happens consistently on a Mac Intel machine on Mac OS 12.x, but as we can't catch this in a debugger as there does not seem to be an easy way to debug an older Mac OS machine, and Xcode with latest Swift does not even install on that system. I have tried to reproduce this on older iOS devices as well in the iOS simulator running iOS 15.x, but there the crash does not happen.


METAL-834: Add --metrics-addr argument to controller

We want to be able to override the bind address of the metrics server. Omitting the argument preserves the original behaviour for backwards compatibility.

I think it works as a standalone change --- the testing is more about the actual problem I'm trying to solve: running this on the bootstrap node in k8s mode.

/unhold

Please open a ticket for this. This is not a valid use of NO-ISSUE.

/retitle METAL-834: Add --metrics-addr argument to controller

/retest

/retest

/retest

/unhold