Docker build/push performance is inexplicably slow

Description
I am evaluating whether I could use docker as a reproducible build and runtime environment for a local cluster application. I've got it mostly working, except I've run into the unexpected issue that the build time became excruciatingly slow due to docker image build/push. I've isolated the problem to be related to sheer data volume.
Steps to reproduce the issue:

Create test folder
$ mkdir testimage
Generate 1GB incompressible file
$ openssl enc -aes128 -in /dev/zero -out >(dd bs=64K count=16384 iflag=fullblock of=testimage/data.img) -e -k $RANDOM -bufsize 134217728
Generate test Dockerfile
$ echo "FROM scratch" > testimage/Dockerfile
$ echo "ADD data.img /data.img" >> testimage/Dockerfile
Build the docker image
$ /usr/bin/time docker build -t testimage testimage
Tag the image
$ docker tag testimage localhost:5000/testimage
Push the image to the local registry
$ /usr/bin/time docker push localhost:5000/testimage

Describe the results you received:
Step (4) output above looks like this:
Sending build context to Docker daemon 1.074 GB
Step 1 : FROM scratch
 --->
Step 2 : ADD data.img /data.img
 ---> 9cacb55ce73d
Removing intermediate container 225630bb7d2e
Successfully built 9cacb55ce73d
1.61user 1.85system 0:39.16elapsed 8%CPU (0avgtext+0avgdata 20728maxresident)k
0inputs+0outputs (0major+1658minor)pagefaults 0swaps

Which works out to be about 25MB/s
Step (6) output above looks like this:
The push refers to a repository [localhost:5000/testimage]
fa2f5c3d71b4: Pushed
latest: digest: sha256:775f2fdf508b162f5ef26ee96292a9b8c1bbbabe4675e071ce02c1a815cb5845 size: 531
0.31user 0.14system 1:40.09elapsed 0%CPU (0avgtext+0avgdata 20172maxresident)k
0inputs+0outputs (0major+1663minor)pagefaults 0swaps

Which works out to be about 10MB/s
Describe the results you expected:
Well it's basically a local copy + hash. There's 64 cores with 2 threads each, 1.5TB of free RAM and nobody else on the system. I expected... a lot faster? Even if it's single-threaded, I would expect maybe >300MB/s for build and >1GB/s for localhost push?
As a point of comparison:
$ sha1sum data.img
Takes 2.5 seconds
and
$ sha256sum data.img
Takes 5 seconds
Is this because of loop devices?
Additional information you deem important (e.g. issue happens only occasionally):
Just for a point of comparison, I decided to try something really not designed for handling binaries and do a similar experiment. I copied the data.img to an empty git repo, with a corresponding bare remote on a different computer on the local network.
$ git add data.img
Took 36s for a pitiful ~27MB/s
$ git commit -m "Test"
Took less than a second
$ git push srvr4 master
Took 33.8s for a ~29.5MB/s
So git add/commit/push over the local network is still faster than docker build/docker push locally, even though docker is a tool nominally designed for blobs of incompressible binary data and shoving those into git is probably the worst thing you can do to it.
Output of docker version:
$ docker --version
Docker version 1.12.3, build 6b644ec

Output of docker info:
$ docker info
Containers: 6
 Running: 1
 Paused: 0
 Stopped: 5
Images: 3
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-8:2-3671813-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 11.92 GB
 Data Space Total: 107.4 GB
 Data Space Available: 95.46 GB
 Metadata Space Used: 7.684 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.14 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.110 (2015-10-30)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.4.0-47-lowlatency
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 128
Total Memory: 1.476 TiB
Name: lfvs1
ID: PPFZ:4NG7:WN7F:HTAI:GH3M:UOYE:DFV4:THVD:LRKW:2W4Z:NSPU:TNSP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Physical box with plenty of ram and CPU, and reasonably fast disks:
$ head -n1 /etc/issue
Ubuntu 16.04.1 LTS \n \l
$ uname -a
Linux lfvs1 4.4.0-47-lowlatency #68-Ubuntu SMP PREEMPT Wed Oct 26 21:00:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/cpuinfo | grep "model name" | cut -d ':' -f 2 | sort | uniq -c
    128  Intel(R) Xeon(R) CPU E7-8867 v3 @ 2.50GHz
$ free -h
              total        used        free      shared  buff/cache   available
Mem:           1.5T        5.5G        1.0T         19M        459G        1.5T
Swap:            0B          0B          0B

I would definitely not run on devicemapper with loop devices, but not sure that explains everything. w.r.t 64 cores; I wonder if that's actually related to https://github.com/golang/go/issues/15395, but difficult to tell without more metrics
/cc @unclejack @stevvooe

Switched docker to using an LVM thinpool on the local RAID
# docker info | grep -i "pool\|metadata\|thin"
WARNING: No swap limit support
 Pool Name: docker-thinpool
 Pool Blocksize: 524.3 kB
 Metadata file:
 Metadata Space Used: 454.7 kB
 Metadata Space Total: 2.986 GB
 Metadata Space Available: 2.986 GB
 Thin Pool Minimum Free Space: 28.37 GB

Build performance got worse:
 /usr/bin/time docker build -t testimage testimage
Sending build context to Docker daemon 1.074 GB
Step 1 : FROM scratch
 --->
Step 2 : ADD data.img /data.img
 ---> d5d415f8f7b7
Removing intermediate container 97b326f08ba7
Successfully built d5d415f8f7b7
1.66user 1.83system 0:48.24elapsed 7%CPU (0avgtext+0avgdata 20460maxresident)k
0inputs+0outputs (0major+1665minor)pagefaults 0swaps

A whopping 20.7MB/s
And local push performance stayed about the same:
$ /usr/bin/time docker push localhost:5000/testimage
The push refers to a repository [localhost:5000/testimage]
789e203de5cd: Pushed
latest: digest: sha256:25909798fce96da752bcdd6bcffc4891c0583264c36ad144b9263c27819274c3 size: 531
0.30user 0.15system 1:41.19elapsed 0%CPU (0avgtext+0avgdata 22184maxresident)k
0inputs+0outputs (0major+1688minor)pagefaults 0swaps

~9.9MB/s

@groman2 There are a few things going on here. To understand push performance, you really need to understand what is happening. We'll dive into that then we can look into what is going on with this machine, because it is very slow.
Pushing an image isn't exactly straightforward but we can break down the process into pushing metadata and pushing layers.  Roughly, a layer push consists of the following steps:

Tar up the contents of the layer.
Compress the resulting tar file.
Take the sha256 of the result.
Send it up to a registry.

For the most part, this is all done as a "cut-through" operation, meaning we tar directly into the compressor and directly hash the output, sending the hashed data to the registry. This gives the property that the bandwidth of the push is dominated by the slowest component. If everything is working correctly, disks, taring and hashing operate at roughly the same bandwidth, making the push process network limited. The tradeoff is that throughput in one pipeline stage can starve or back off other stages, resulting in slower performance.
For reference, we can measure a few of these steps to get a ballpark estimate of what we should be seeing (none of this is science). On my local machine (macbook pro w/SSD), I got the following as bandwidth numbers for various steps:

Scenario
Command
Bandwidth

Tar up 2GB of files
`tar cf - -C ~/go/src/github.com/docker/docker .
pv > /dev/null`

Registry push
time curl -vv -H'Content-Type: application/octet-stream' --data-binary @<(tar cf - -C ~/go/src/github.com/docker/docker .) -XPUT $UPLOAD_URL
~300 MB/s

Note, that rather than using random data, I used real data from a 2GB checkout of docker to make the tar process even slower that what it would be in the example provided here. It includes a generated data.img, similar in size the file used in the original examples.
While I agree that push should be faster, expecting >300 MB/s is very optimistic. With unloaded and unlimited network and disk, 100 MB/s is more realistic (and very close to the original numbers I got when do V2 protocol tests), depending on the machine.
Let's also get more realistic push numbers with docker on my local box (docker for mac, with 1.12.3, notoriously slow fs performance). I have a local image of the docker-dev build, clocking in ~3GB that took roughly 6:36 to push to a registry running in docker for mac. We get about 8 MB/s. The same push to hub took about the same amount of time. With a different machine, also SSD, however, I get ~18 MB/s, when pushing from local docker to local registry. Clearly, the disk has an effect, but we also have unexplained performance degradation.
Given the above, we can start to really see the pipeline affecting actual bandwidth but we can also see where the bottleneck lies. For the most part, compression and hashing are fixed on an unloaded machine. This leaves the problem at the disk or on the network. Since your push test is going to a local registry instance, we can assume the network is around 125MB/s or more, so it is likely that the disks speed is what is affecting the performance. The test data from my local machine confirms this, but also casts doubts about the theoretical limits of push performance.
TL; DR We can make a few conclusions from the data the analysis above:

The disks on @groman2's test machine are very slow. While I estimated at least 200 MB/s using your sha256 example (clearly hash limited), it would be good to get some baseline numbers reading from /var/lib/docker, reading directly from the same filesystem as docker. Having this data point will tell us if adjusting your disk setup can help with performance.
In theory, we should be getting closer to 100 MB/s of push bandwidth. On the "ideal box" (my second laptop with SSD and native docker), we are only 17 MB/s.

Either way, this warrants more investigation. We'll have to instrument each pipeline stage to see where the actual bottleneck is.

I did some speed testing on the machine:

Scenario
Command
Bandwidth

Tar up 2GB of files and transfer over TCP to localhost
`$ nc -l 5001 > /dev/null & tar cf - -C testimage .
pv

RAW TCP Localhost Speed
$ iperf -s 2>&1 >/dev/null & iperf -c localhost
5.4GiB/s

Read 64GB file
`$ dd if=largefile64GB bs=1M
pv >/dev/null`

tar up /var/lib/docker
`# tar cf - -C /var/lib/docker .
pv > /dev/null`

Write big file to /var/lib/docker
`# cat largefile64GB
pv > /var/lib/docker/largefile`

Tar up 2GB file
`$ tar cf - -C testimage .
pv > /dev/null`

Tar and sha256 2GB file
`$ tar cf - -C testimage .
pv

So nothing was really jumping out at me. The tar + sha256 speed is not super impressive. I saw you mentioned compression but your speed tests used uncompressed tar. So I threw in gzip:

Scenario
Command
Bandwidth

Tar + gzip 2GB file
`$ tar cf - -C testimage .
gzip

I think we found our culprit. gzip is slow.... sloooow. Using gzip --fast helps only marginally.
Trying the same experiment with pigz instead of gzip produces some promising results:

Scenario
Command
Bandwidth

Tar + pigz 2GB file
`$ tar cf - -C testimage .
pigz

So it would be nice to have:

Faster/parallel compression algorithm
A no-compress option
A faster hash algorithm

I guess the sha would have to move prior to compression, because otherwise --no-compress would change the sha

@groman2 Perfect! This data helps out a lot with the analysis. I think we can eliminate the hypothesis that your "disks are slow".
Throwing out gzip in the analysis above was a HUGE omission. Apologies for the oversight. I've confirmed the bandwidth numbers of gzip, getting anywhere from 10-40 MB/s, even with pigz, on my local machine (I only have a few cores, so this makes sense).
For docker, parallel gzip presents some serious performance issues. Most benchmarks assume that the process will have the whole machine at their disposal. However, with applications running and other layers being push/pulled concurrently, many of these parallel gains will be diminished. We really need to optimize for single threaded performance and gzip seems to be a massive bottleneck.
Looking back, gzip compression has always been a controversial topic. Checkout https://github.com/docker/docker/issues/10181 and https://github.com/docker/docker/pull/17674. The approach previously has always been about optimizing gzip, usually at the cost of more resources. Unfortunately, none of these analysis approached the problem from a theoretical pipeline perspective.
The main reason we cannot just turn gzip on and off is that the compression is part of the content addressable artifact. If you disable compression, it will change the content addresses of existing content.
We'll have to make a decision to as a whole and have a plan for phasing out compressed layers. This will get rid of a major bottleneck and allow operators to choose a fitting transport compression that works well in their infrastructure.
Another option is to compress each layer once, rather than on every single push and pull.

w.r.t. making compression optional, there's also a discussion here; https://github.com/docker/docker/issues/1266

I'm not familiar with the Docker codebase, but I have some familiarity with content addressable systems in general. In my experience, generating a hash of compressed data for content addressability can result in an eventual mess that is not related to performance. You are effectively locking yourself to a particular compression library version/compression settings/etc.
while we have a guarantee that
$ cat data.img | gzip | gunzip | shasum

and
$ shasum data.img

will give the same result on any system, we don't have a guarantee that the compressed version will have the same SHA everywhere and every time (as long as it decompresses into the same thing, it's all fine). Obviously it's likely that it IS the same, given that gzip is pretty stable.
Using the sha of the uncompressed data for content addressability is a much better long term approach, IMO, even if compressed layers are supported.

@groman2 I see you are very familiar with this trade off. The actual goal with this design was to make the storage layers agnostic to what content is being stored. When we introduced content addressability, the decision had already been made that layers are compressed artifacts, which was affirmed in the presence of possible, though improbable attacks, involving the processing of unverified content.
The root issue here is the expectation that a round trip of content through serialization layers provides a stable hash calculation. In your example, only data.img is considered. However, that may include json generation, consistent tar creation (see tar-split) and consistent compression. Whether you have choice of compression or not isn't particularly important when the round tripping of artifacts can introduce hash instability. In particular, bugs within any of these components can create problems with the round trip. Generating the artifact once usually assuages these problems and is very much a viable solution in this case.
Put in your terms, I expand the warning of "generating a hash of compressed data for content addressability can result in an eventual mess" to the stronger "generating hash stable round trip serialization for content addressability will result in an eventual mess". 😉
The implication here is that compression is actually a transport concern. Especially since we do it on every push and pull. Going back to our bandwidth pipeline analysis, if the compression bandwidth is higher than the connection bandwidth, we have the property that the transfer time (there is a relationship that can be worked out mathematically). For most internet connections and CPU sizes, gzip is adequate because it can keep the pipe full. When the CPU size (lower compression bandwidth) is too small or the connection is too fast (like in this case), the low compression bandwidth starves the network connection, resulting in a slow push. Because the performance of compression is variant on environmental conditions, it should probably be separated from content identity.
I hope my statements above give you the feeling not that I disagree with you, but rather that I am affirming your intuition with experience we've had in the deployment of content addressability in Docker.
Given the above, there are too paths:

Separate compression from content identity. We still have the "danger" of hash instability, since we are round tripping the other components, but we have much better control over their stability. This comes with the expense of a migration, but the cost isn't too bad, since daemons have always had content compression detection in layer processing.
Don't round trip artifacts. This ensures stability for all serialization methods in the generation of an image. At the cost of disk space and a compression step during commit, it will store content, as received. If content is to be pushed again, the untouched data will be sent directly without interference from the docker daemon.

Both can be done, but we can favor 2 before 1, since there will be less impact. The takeaway is that I am going to pursue these much less casually than before, since we actually have some theory backing it up.

Is this being worked on? Pushing 16GB of layers on beefy server takes very, very long time.

Very interested in seeing this improved. It takes a long time to push to local registries on a lan that can easily handle full GiB throughput.

@D0han @Tomasu I am generally addressing this problem with the approach taken in containerd but I am not sure how quickly we can realize those gains in docker.
The quickest fix would be to allow one to completely disable layer compression.

Thanks @stevvooe !
Is disabling doable by options, or not implemented yet?

Is disabling doable by options, or not implemented yet?

It is not implemented.

@stevvooe I see. I really don't mind that too much. disk space is cheap on the registry for what I use it for.

@Tomasu I am currently working on the option to enable saving of artifacts. Give containerd a try on a pull-push round trip and see if that impacts the push time and we can adjust. It is not quite production ready yet, but it will be a good data point to ensure the approach is right.

any updates?

any updates?

@thaJeztah @stevvooe
Is there a way to calculate total time spent compressing / decompressing images during push/pull operations (by inserting logs in moby source) , rather than relying on "time docker push" as this includes network time also ?
I am trying to analyze how much more time does the gzip/unpigz spend on comp/decomp when used from within docker , and when we compress the same thing using docker save  | gzip | ... (basically want to measure overhead due to stream compress/decompress operations in docker )

If you have debug enabled, the daemon will show the logs for each step;
DEBU[2019-08-07T19:30:12.680669875Z] Calling HEAD /_ping
DEBU[2019-08-07T19:30:12.694678713Z] Calling GET /v1.40/info
DEBU[2019-08-07T19:30:12.810109275Z] Calling POST /v1.40/images/create?fromImage=ubuntu&tag=latest
DEBU[2019-08-07T19:30:12.817316208Z] Trying to pull ubuntu from https://registry-1.docker.io v2
DEBU[2019-08-07T19:30:14.662277902Z] Pulling ref from V2 registry: ubuntu:latest
DEBU[2019-08-07T19:30:14.662347404Z] docker.io/library/ubuntu:latest resolved to a manifestList object with 6 entries; looking for a unknown/amd64 match
DEBU[2019-08-07T19:30:14.662364930Z] found match for linux/amd64 with media type application/vnd.docker.distribution.manifest.v2+json, digest sha256:d91842ef309155b85a9e5c59566719308fab816b40d376809c39cf1cf4de3c6a
DEBU[2019-08-07T19:30:15.134344421Z] pulling blob "sha256:1d425c98234572d4221a1ac173162c4279f9fdde4726ec22ad3c399f59bb7503"
DEBU[2019-08-07T19:30:15.134372035Z] pulling blob "sha256:7413c47ba209e555018c4be91101d017737f24b0c9d1f65339b97a4da98acb2a"
DEBU[2019-08-07T19:30:15.134405110Z] pulling blob "sha256:0fe7e7cbb2e88617d969efeeb3bd3125f7d309335c736a0525233ec2dc06aee1"
DEBU[2019-08-07T19:30:15.656331038Z] Downloaded 1d425c982345 to tempfile /var/lib/docker/tmp/GetImageBlob813512277
DEBU[2019-08-07T19:30:15.656536674Z] pulling blob "sha256:344da5c95cecd0f55238ce59b8469ee301056001ece2b769e9691b80f94f9f37"
DEBU[2019-08-07T19:30:15.680269873Z] Downloaded 0fe7e7cbb2e8 to tempfile /var/lib/docker/tmp/GetImageBlob175359311
DEBU[2019-08-07T19:30:16.285710722Z] Downloaded 344da5c95cec to tempfile /var/lib/docker/tmp/GetImageBlob741678178
DEBU[2019-08-07T19:30:19.963628678Z] Downloaded 7413c47ba209 to tempfile /var/lib/docker/tmp/GetImageBlob377162672
DEBU[2019-08-07T19:30:19.968940733Z] Applying tar in /var/lib/docker/overlay2/e627c5b69cb82a1d0f77357522926a0ef1351be2b20d17d3937b4ad9a6e901ad/diff  storage-driver=overlay2
DEBU[2019-08-07T19:30:21.400568017Z] Applied tar sha256:543791078bdb84740cb5457abbea10d96dac3dea8c07d6dc173f734c20c144fe to e627c5b69cb82a1d0f77357522926a0ef1351be2b20d17d3937b4ad9a6e901ad, size: 63197287
DEBU[2019-08-07T19:30:21.461786503Z] Applying tar in /var/lib/docker/overlay2/dd94d8f18f96e8264f9898cd63e6037e880f1ebf32baff212e11350bdba8d4a2/diff  storage-driver=overlay2
DEBU[2019-08-07T19:30:21.586150772Z] Applied tar sha256:c56e09e1bd18e5e41afb1fd16f5a211f533277bdae6d5d8ae96a248214d66baf to dd94d8f18f96e8264f9898cd63e6037e880f1ebf32baff212e11350bdba8d4a2, size: 987475
DEBU[2019-08-07T19:30:21.601487548Z] Applying tar in /var/lib/docker/overlay2/a7123da831bb70cab3492f7f44eb31086becde37500001d4b03553d14e354638/diff  storage-driver=overlay2
DEBU[2019-08-07T19:30:21.737944764Z] Applied tar sha256:a31dbd3063d77def5b2562dc8e14ed3f578f1f90a89670ae620fd62ae7cd6ee7 to a7123da831bb70cab3492f7f44eb31086becde37500001d4b03553d14e354638, size: 745
DEBU[2019-08-07T19:30:21.755832870Z] Applying tar in /var/lib/docker/overlay2/c82433d5d0c2fce81e72606e5f2d8a5bea72fcd7667aa7220e09211d6fcc8e76/diff  storage-driver=overlay2
DEBU[2019-08-07T19:30:21.908411096Z] Applied tar sha256:b079b3fa8d1b4b30a71a6e81763ed3da1327abaf0680ed3ed9f00ad1d5de5e7c to c82433d5d0c2fce81e72606e5f2d8a5bea72fcd7667aa7220e09211d6fcc8e76, size: 7

Thank you for the reply.
I am currently using debug mode, and it has timestamps for "Applying tar" and "Applied tar" for pull (decompression).  But I was unsure if this is accurate, as the debug logging code is spread across 2 files :
daemon/graphdriver/overlay2/overlay.go ---- line 712 logger.Debugf("Applying tar in %s", applyDir)
layer/layer_store.go line 277----- logrus.Debugf("Applied tar %s to %s, size: %d", layer.diffID, layer.cacheID, applySize)
But there is no end point specified for push-compression finish of a layer.
You have "Assembling tar data" & then a "uploaded layer " , which has a timestamp for after upload finishes, rather than after compression finishes.
I tried to add debug logs before and after this switch for compression times in push_v2.go, but the logs show almost same timestamps.
I am trying to find between which 2 points does compression and decompression part happen in moby code. Appreciate your time and help, thank you

I'm not super-familiar with that part of the code, but happy to help where I can

Will it be possible to point me to someone who is familiar with it?

@dmcgowan @stevvooe and @tonistiigi have dealt more with that code

still having the issue from time to time 🥴

Also here, a 3 min (almost fully cached) build that takes up to 30 min for being pushed. It's weird.

I would definitely not run on devicemapper with loop devices, but not sure that explains everything. w.r.t 64 cores; I wonder if that's actually related to golang/go#15395, but difficult to tell without more metrics
/cc @unclejack @stevvooe

Hi, could you explain why running on devicemapper with loop devices is a bad idea? Thanks.

@da2018 various reasons can be found in the docs here; https://docs.docker.com/storage/storagedriver/device-mapper-driver/#device-mapper-and-docker-performance
Unless you have a very specific reason, I'd recommend using the default (overlay2) storage driver. The device mapper storage driver was created when RHEL/CentOS kernels did not yet support overlayfs or other alternatives, but now that they do, overlay2 is used on those platforms as well. For those reasons, the device mapper storage driver is marked deprecated; there's no immediate plans to remove it, but other than some maintenance if needed, no further development is planned.

ry specific reason, I'd recommend using the default (overlay2) storage driver. The device mapper storage driver was created when RHEL/CentOS kernels did not yet support overlayfs or other alternatives, but now that they do, overlay2

Many thanks.

Deleting LOCAL docker images helped in my case!!
Maybe unrelated, but my cca. 300MB push suffered the same terrible slowdown. Used to be seconds, but became long minutes (after few weeks of work).
So I tried a few things (like disabling antivirus for Docker), but what seems to have helped was removing all images from my local docker. It freed up some 7GB and the push is suddenty super fast again.

buildah pushing is much faster than docker-cli because it uses "github.com/klauspost/pgzip" instead of "compress/gzip".
According to the pgzip benchmark, pgzip is 123x faster than gzip.
Is there anyone interested to send a pr for mody?

Still a problem, very frequently

Still an issue with Docker 24.0.5. I second @umialpha.

We have the same problems.

We have the same problems. Is there any way to speed this up?

@Benjamin-Tan yes, like @umialpha said: using github.com/klauspost/pgzip instead of compress/gzip. I guess the Moby team hasn't heard us yet.

@thetredev How would one go about to use pgzip instead of gzip? while waiting for the Moby team to recognize this.

@Benjamin-Tan I would imagine: figuring out how to build moby, the Docker engine, and the CLI. Not sure if the Docker engine is open source (it's free though), so you might be able to replace the Moby binaries from the engine with those you built yourself.
I guess I'm not the right person to ask though. It could very likely be the case that you have to build containerd instead of Moby, with the gzip patch applied to either Moby or containerd (don't know how they work together, if at all). But if it's only containerd then it's easier because at least on Linux, the Docker CLI uses containerd AFAIK. Again, not sure what role Moby plays in all of this. It might be best to read through the containerd project first and go from there.

@benatkin my 2 cents: the actual performance gain depends on how the resulting image is structured before compression. Layering also seems to be very important. There's only so much parallelism can do. Figuring out the perfect layering for speeding up compression is up to you. So 123% performance increase is mist likely achievable, but it could go down quickly if image layering is not in favor of compression.

We're working on completing the containerd image-store integration, which switches the image store to use the image-store and snapshotters provided by containerd.
With the containerd store integration, compressed (tar.gz) layers are persisted on disk (instead of constructed when pushing); this allows pushes to be reproducible (compression is not 100% reproducible), but at the cost of additional storage space required. If you have a system to test on, you can enable it in current versions of docker; see https://docs.docker.com/storage/containerd/#containerd-image-store-with-docker-engine

@thaJeztah thank you! I had a try and it is a lot faster. I did not even notice that it has been pushed successfully. When do you think this feature would become General Availability, away from Beta stage?
The solution might benefit #26959

Unless I'm mistaken, I don't think docker engine is used at all when using the buildx Kubernetes driver; in that case, you're running a standalone BuildKit builder (which doesn't store images, only build-cache).

Ahh thank makes sense. Thank you for clearing it up.

@thaJeztah for your information, with this experimental feature enabled, the user permission of folders does not persist in the running container. Also, the docker image size increase drastically (from 2.78 GB to 9 GB) just for a few line in the dockerfile to add new user,group via useradd. Not sure where would be a good place to file this, but feel free to move this information elsewhere if that helps!
A simple Dockerfile can be found as follows:
FROM ubuntu:jammy as base

RUN groupadd -g 1000 docker_group &&\
    useradd -l -m -d /home/docker_user -u 1000 -g docker_group docker_user -s /bin/bash -G sudo -p "" &&\
    install -d -m 0755 -o docker_user -g docker_group /home/docker_user

RUN install -o docker_user -g docker_group -d /folderD/ && \
    install -o docker_user -g docker_group -d /home/docker_user/folderA && \
    install -o docker_user -g docker_group -d /home/docker_user/.folderB

RUN chown -R docker_user:docker_group /home/docker_user/
RUN ls -la /home/docker_user
USER docker_user:docker_group

WORKDIR /home/docker_user/folderA

We're working on completing the containerd image-store integration, which switches the image store to use the image-store and snapshotters provided by containerd.
With the containerd store integration, compressed (tar.gz) layers are persisted on disk (instead of constructed when pushing); this allows pushes to be reproducible (compression is not 100% reproducible), but at the cost of additional storage space required. If you have a system to test on, you can enable it in current versions of docker; see https://docs.docker.com/storage/containerd/#containerd-image-store-with-docker-engine

@Benjamin-Tan I just built an image with the Dockerfile you gave and:
REPOSITORY                                                                   TAG       IMAGE ID       CREATED             SIZE
huge                                                                         latest    50f780ba3a48   5 seconds ago       117MB

How did you get a 9GB image?
If you have a reproducer feel free to open a new issue

@Benjamin-Tan I just built an image with the Dockerfile you gave and:
REPOSITORY                                                                   TAG       IMAGE ID       CREATED             SIZE
huge                                                                         latest    50f780ba3a48   5 seconds ago       117MB

How did you get a 9GB image?
Also, I see that the permissions are right it would seem
docker_user@a6a81fba0b78:~$ pwd
/home/docker_user
docker_user@a6a81fba0b78:~$ ls -la
total 28
drwxr-xr-x 1 docker_user docker_group 4096 Jan  4 10:31 .
drwxr-xr-x 1 root        root         4096 Jan  4 10:31 ..
-rw-r--r-- 1 docker_user docker_group  220 Jan  6  2022 .bash_logout
-rw-r--r-- 1 docker_user docker_group 3771 Jan  6  2022 .bashrc
drwxr-xr-x 2 docker_user docker_group 4096 Jan  4 10:31 .folderB
-rw-r--r-- 1 docker_user docker_group  807 Jan  6  2022 .profile
drwxr-xr-x 2 docker_user docker_group 4096 Jan  4 10:31 folderA

If you have a reproducer feel free to open a new issue

I was extracting this out of another Dockerfile with multi-stage build. I will get a reproducible example and open the new issue instead. Thanks @rumpl


check defaultPrevented when intercepting link clicks

fixes #7

Can you write a test that fails on the incorrect behavior?

Everything passes except sauce not wanting to connect right now.


Support transformer loggers in pub build/serve

Right now pub build and pub serve don't support TransformerLogger. This should be fixed.

This issue has been moved to dart-lang/pub#676.


make software.amazon.opentelemetry:aws-opentelemetry-agent default option available as jar instead of pom in mavencentral

Describe the bug
for the aws opentelemetry javaagent, artifacts available in maven central repository
software.amazon.opentelemetry:aws-opentelemetry-agent, it's by default available as pom artifact, instead of jar artifact.
https://mvnrepository.com/artifact/software.amazon.opentelemetry/aws-opentelemetry-agent/1.13.1
if you observe gradle representation, by default pom extension is there
// https://mvnrepository.com/artifact/software.amazon.opentelemetry/aws-opentelemetry-agent
implementation group: 'software.amazon.opentelemetry', name: 'aws-opentelemetry-agent', version: '1.13.1', ext: 'pom'

When compared with io.opentelemetry.javagent, it's available as jar in mavencentral.
https://mvnrepository.com/artifact/io.opentelemetry.javaagent/opentelemetry-javaagent/1.9.0
if you observe gradle representation, by default jar extension is there
// https://mvnrepository.com/artifact/io.opentelemetry.javaagent/opentelemetry-javaagent
runtimeOnly group: 'io.opentelemetry.javaagent', name: 'opentelemetry-javaagent', version: '1.9.0'

Steps to reproduce

if we don't give extension as jar, it won't download the jar for aws otel java agent

below is working one
   implementation group: 'software.amazon.opentelemetry', name: 'aws-opentelemetry-agent', version: '1.9.0', ext: 'jar'
below get's pom by default
   implementation group: 'software.amazon.opentelemetry', name: 'aws-opentelemetry-agent', version: '1.9.0'
What did you expect to see?

would like to have jar as the default option for aws opentelemetry agent
What did you see instead?
seeing pom as the default option

Additional context

We're running into this issue as well.  If possible please fix.

The fix for this issue will be available in v1.19.0.

Closing issue as this will be available in v1.19.0


[Bug] Eleventy plugin doesn't generate any images

Describe the bug
Eleventy plugin doesn't generate any images
To Reproduce
Steps to reproduce the behavior:

Remove all manually generated pictures, leave only source
Open last tutorial step (06), run yarn start
Install node_modules
Run yarn start
There is no images generated based on presets in assets folder

Expected behavior
Plugin generate all images from the preset and put it in assets folder

This definitely doesn't generate images for me… but should it? Is this only for generating markup for images that I need to generate by some other method? It's not clear if this is a bug or the intended behavior.

@Defite @freshyill really sorry for the laaate answer.
Indeed, this plugin doesn't generate any image.
It is meant to be used with another solution for image resizing and optimization, like an image CDN. I'm currently using Cloudinary for example, but it works well with others.
I think it should be possible to use it with the official Eleventy Image plugin, if you don't want to rely on a third party service, but I didn't check.
I'll add a warning to the README and docs.


msql2 0.5.6

Bumps mysql2 version
I needed this because I could not install 0.5.5.
I got:
bundle install
...
Installing mysql2 0.5.5 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

coverage: 94.536%. remained the same
when pulling e5f6efb0cb75d1f08e3936ec932edafc1e4fa9b8 on jdc-mysql2_0_5_6
into d61c187f2a39a8f46d304ce8595b36aff831246e on main.


R arrow package can't see arrow-cpp installation

Hi there,
this is more a question than a bug request.
I am using NixOS 20.03 and couldn't get the arrow library in R to see the arrow C++ library.
Even when I install the library from R itself, it can't find the C++ library after restarting.
The following is the installation log in R. This problem might be specific to NixOS. But if anyone can point to the source code that checks for the C++ library, I might be able to help to fix this for NixOS.
Thanks in advance!
> arrow::install_arrow()
Installing package into ‘/home/zhen/R/x86_64-pc-linux-gnu-library/3.6’
(as ‘lib’ is unspecified)
trying URL 'https://cran.rstudio.com/src/contrib/arrow_0.17.0.tar.gz'
Content type 'application/x-gzip' length 242534 bytes (236 KB)
==================================================
downloaded 236 KB

* installing *source* package ‘arrow’ ...
** package ‘arrow’ successfully unpacked and MD5 sums checked
** using staged installation
*** No C++ binaries found for nixos-20
*** Successfully retrieved C++ source
*** Building C++ libraries
**** cmake
**** arrow
./configure: line 132: cd: libarrow/arrow-0.17.0/lib: No such file or directory
------------------------- NOTE ---------------------------
After installation, please run arrow::install_arrow()
for help installing required runtime libraries
---------------------------------------------------------
** libs
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c array.cpp -o array.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c array_from_vector.cpp -o array_from_vector.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c array_to_vector.cpp -o array_to_vector.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c arraydata.cpp -o arraydata.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c arrowExports.cpp -o arrowExports.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c buffer.cpp -o buffer.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c chunkedarray.cpp -o chunkedarray.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c compression.cpp -o compression.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c compute.cpp -o compute.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c csv.cpp -o csv.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c dataset.cpp -o dataset.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c datatype.cpp -o datatype.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c expression.cpp -o expression.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c feather.cpp -o feather.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c field.cpp -o field.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c filesystem.cpp -o filesystem.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c io.cpp -o io.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c json.cpp -o json.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c memorypool.cpp -o memorypool.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c message.cpp -o message.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c parquet.cpp -o parquet.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c py-to-r.cpp -o py-to-r.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c recordbatch.cpp -o recordbatch.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c recordbatchreader.cpp -o recordbatchreader.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c recordbatchwriter.cpp -o recordbatchwriter.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c schema.cpp -o schema.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c symbols.cpp -o symbols.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c table.cpp -o table.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -I"/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/include" -DNDEBUG  -I"/nix/store/58d1yk61akanrlq3pwnbhbb62vrwk6a6-r-Rcpp-1.0.4/library/Rcpp/include"   -fpic  -g -O2  -c threadpool.cpp -o threadpool.o
/nix/store/x9vxn05bn19wn2mzn6d4h56glbd02pyr-gcc-wrapper-9.3.0/bin/c++ -std=gnu++11 -shared -L/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/lib -o arrow.so array.o array_from_vector.o array_to_vector.o arraydata.o arrowExports.o buffer.o chunkedarray.o compression.o compute.o csv.o dataset.o datatype.o expression.o feather.o field.o filesystem.o io.o json.o memorypool.o message.o parquet.o py-to-r.o recordbatch.o recordbatchreader.o recordbatchwriter.o schema.o symbols.o table.o threadpool.o -L/nix/store/jk3gaiy3g3fs2866r194yxy0mppyix8n-R-3.6.3/lib/R/lib -lR
installing to /home/zhen/R/x86_64-pc-linux-gnu-library/3.6/00LOCK-arrow/00new/arrow/libs
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (arrow)

The downloaded source packages are in
	‘/run/user/1000/RtmpliJLh9/downloaded_packages’

We don't do any testing on NixOS, so it's not surprising that it doesn't just work.
http://arrow.apache.org/docs/r/articles/install.html describes how dependencies are resolved and notes the relevant files inside the r directory of apache/arrow. It sounds like http://arrow.apache.org/docs/r/articles/install.html#using-system-libraries is most relevant since you say you already have Arrow C++ installed, so maybe you can set one of those environment variables to help it find them.
If you have any fixes to enable it to work on your OS, please open a JIRA ticket and I'll be happy to review your PR.


add hotkeys

add hotkeys for different jobs for example CTRL+H to open "add hardcoded sub" window ..etc

I added it but it has to be reset manually to appear, meanwhile you can config it manually.


Build times should be cumulative

Sometimes files show up multiple times with different build times. I suppose this is because of target dependencies. It would be nice if identical lines would be grouped and their cumulative build time displayed.

Sometimes files show up multiple times with different build times. I suppose this is because of target dependencies.

The plugin displays build times for functions rather than files (see the Function column). That would be why you see the same file show up multiple times.

No. It's the same function AND same file.

Ah, that would be a bug. I haven't actually seen this for any of my projects. Let me see if I am able to reproduce this when I have a moment.
If you have then time and able to build the plugin yourself, it would be interesting to see if that goes away if:
return time.hashValue ^ text.hashValue
is swapped to:
return text.hashValue
in CMRawMeasure.swift.

Example screenshot

Let me check

By the way. Is there a reason the results are capped at 20?

I added it for performance reasons but never benchmarked it. It could likely be increased.

Thanks for this find and your commits. Have merged the branch to master...


Loading Tensorflow model with h5py > 2.1.0

An update in the h5py package causes errors in model loading for Tensorflow architectures (Link)
To successfully load our tensrflow model we need h5py version 2.10.0

Fixed by adding "h5py==2.10.0" to install requirements on setup.py


FEAT-#7249: Add reload_modin feature

What do these changes do?

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[x] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] signed commit with git commit -s
[x] Resolves #7249
[x] tests passing
[x] module layout described at docs/development/architecture.rst is up-to-date

This seams to break methods that use the @multimethod decorator which chooses the method based on dataframe type.
ultimethod.DispatchError: ('update_columns: 0 methods found', (<class 'ModinRayPointqloud'>, <class 'modin.pandas.dataframe.DataFrame'>), set())


chore(main): release 0.6.0

:robot: I have created a release beep boop
0.6.0 (2024-09-13)
Features

add multi visualization (#20) (e34ecb8)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.6.0
:sunflower:


[flash_ctrl] Wrong page size in flash_ctrl C test

The chip's test chip_sw_flash_access is running the method test_basic_io in the file sw/device/tests/flash_ctrl_test.c https://github.com/lowRISC/opentitan/blob/b1e181b4ff83e60f4ee3a567bf358721d5336ad8/sw/device/tests/flash_ctrl_test.c#L37
In this test, the input page and output page variables declared as arrays that should be in the size of 1 full page of the flash.
The flash pages actual size is 256 64bits words, however this arrays defined as arrays of 32bits integers which means their size should be 512, while in fact is defined as FLASH_WORDS_PER_PAGE which is 256.
This in turn causes the flash to only do the programs and reads in this test on the 1st half of the pages.
The definition of the array as arrays in the size of FLASH_WORDS_PER_PAGE of 32bits integers:
https://github.com/lowRISC/opentitan/blob/b1e181b4ff83e60f4ee3a567bf358721d5336ad8/sw/device/tests/flash_ctrl_test.c#L81-L82
The definition of the FLASH_WORDS_PER_PAGE parameter in the test:
https://github.com/lowRISC/opentitan/blob/b1e181b4ff83e60f4ee3a567bf358721d5336ad8/sw/device/tests/flash_ctrl_test.c#L27
The definition of the flash_get_words_per_page method in the file sw/device/lib/flash_ctrl.c
https://github.com/lowRISC/opentitan/blob/b1e181b4ff83e60f4ee3a567bf358721d5336ad8/sw/device/lib/flash_ctrl.c#L270-L272
The definition of the FLASH_CTRL_PARAM_WORDS_PER_PAGE parameter to be 256 in the flash_ctrl_regs.h
(I'm not sure where this file is actually defined in the environment)

Taking a look at this now.


integrations: Add SonarQube webhook integration.

Fixes #13395

Testing plan:
tested manually as well as using ./tools/test-backend zerver/webhooks/sonarqube

@timabbott I have made the changes.

@timabbott @eeshangarg I have made the changes.

I'll wait for @eeshangarg to comment before reviewing again.

@eeshangarg Sorry for the delay on this. I have made the following changes based on your suggestions

Capitalized constants.
Added templates for different messages.
Added branch to topic if present.
Split the render_body function into 2 according to branch present.

@eeshangarg would you mind to merge it. I have a use for this integration 😉

Sorry we lost track of this, and thanks for the bump @jwillmer!  Merged, thanks @tushar912 for writing this!

@jwillmer since this is a new integration, please be especially encouraged to open issues or start a thread in #integrations if you have any feedback on how we might improve the formatting.
(If you're self-hosting, it should be easy to cherry-pick; it should be on Zulip Cloud in a few days).


Adding ReadMe

Fixes #1
As the extension is still in WIP, I have left the instructions for now.

Good job @aryanbaburajan. Can you add instructions for reloading the extension as well?
In chrome:

Firefox:


🎛 Migrate initDismissibles to a Stimulus controller w-dismissible

ℹ Part of the Stimulus  🎛 RFC 78

Is your proposal related to a problem?
We have a TypeScript implementation that when a button is clicked, it removes the parent element from the page, i.e dismiss it.
Describe the solution you'd like

Create a stimulus controller w-dismissible that will replace the TypeScript implementation
The behaviour should be exactly the same as current state but using Stimulus data attributes for the behaviour & classes declaration
The Controller should be written in TypeScript
Ensure that the existing unit tests are created to reflect this new behaviour
We will need to document an upgrade consideration that the previous data-attribute approach will no longer work

Additional context
Current implementation

client/src/includes/initDismissibles.ts
client/src/includes/initDismissibles.test.js
wagtail/admin/templates/wagtailadmin/home/whats_new_in_wagtail_version.html
wagtail/admin/menu.py

Current usage in What's new in wagtail.

    <button
      class="w-whats-new__dismiss"
      type="button"
      data-wagtail-dismissible-toggle
    >
      {% icon name="circle-xmark" %}
      {% trans "Close" %}
    </button>

Potential usage

    <button
      class="w-whats-new__dismiss"
      type="button"
      data-action="w-dismiss#dismissible"
    >
      {% icon name="circle-xmark" %}
      {% trans "Close" %}
    </button>

Current usage in `help menu in sidebar widget
class DismissibleMenuItemMixin:
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.attrs["data-wagtail-dismissible-id"] = self.name

    def render_component(self, request):
        profile = getattr(request.user, "wagtail_userprofile", None)

        # Menu item instances are cached, so make sure the existence of the
        # data-wagtail-dismissed attribute is correct for the user
       if profile and profile.dismissibles.get(self.name):
            self.attrs["data-wagtail-dismissed"] = ""
        else:
           self.attrs.pop("data-wagtail-dismissed", None)

        return super().render_component(request)

Resulting html
<button
  data-wagtail-dismissible-id="help"
  class="sidebar-menu-item__link"
  aria-haspopup="menu"
  aria-expanded="false"
  type="button"
>
  <svg class="icon icon-help icon--menuitem" aria-hidden="true">
    <use href="#icon-help"></use>
  </svg>
  Help
  <svg
    class="icon icon-arrow-right sidebar-sub-menu-trigger-icon"
    aria-hidden="true"
  >
    <use href="#icon-arrow-right"></use>
  </svg>
</button>

Potential html

<button
  class="sidebar-menu-item__link "
  aria-haspopup="menu"
  data-controller="w-dismissible"
  data-action="w-dismissible#dismissible"
  data-w-dismissible-dismissed-class="w-dismissible--dismissed"
  data-w-dismissible-id-value="help"
>
  <svg class="icon icon-help icon--menuitem" aria-hidden="true">
    <use href="#icon-help"></use>
  </svg>
  Help
  <svg
    class="icon icon-arrow-right sidebar-sub-menu-trigger-icon"
    aria-hidden="true"
  >
    <use href="#icon-arrow-right"></use>
  </svg>
</button>

Usage in Wagtail admin

Usage in help menu in sidebar

Additional helpful content

https://github.com/wagtail/wagtail/pull/9344

Thanks @Lovelyfin00  I have reformatted this a bit as it looked like everything was indented, really appreciate you raising this.

Thanks @Lovelyfin00 I have reformatted this a bit as it looked like everything was indented, really appreciate you raising this.

Great thanks!!

Thanks for writing this up!
I'm in favour of refactoring the dismissibles that are rendered with Django templates to use Stimulus. However, I would be a bit wary about the changes to the menu item. That component is rendered using React, and as such, the local dismissible state is handled separately using the state management that applies for that component (in this case a Redux state). This means that the data-controller attribute should likely not be applied to dismissible menu items.
That said, I assume data-wagtail-dismissible-id will be renamed to something else that's more in-line with our Stimulus conventions. When that happens, we should also update the attribute name for the dismissible menu items and update the React component's code accordingly, while still keeping the state management in React.
I'd like to note that we need to keep the name consistent and clear across the attributes, though. In the "Potential HTML" I see:

data-controller="w-dismiss"
data-action="w-dismiss#dismissible"
data-w-dismiss-dismissed-class
data-w-dismissible-id-value

Instead of w-dismiss, I'd suggest naming it w-dismissible. The reason is that "dismiss" is the action, while "dismissible" is the element, as outlined in:

#9351

And to be more concise, can the data-w-dismissible-id-value be just data-w-dismissible-id?
With those changes, the potential HTML attributes would be:

data-controller="w-dismissible"
data-action="w-dismissible#dismiss"
data-w-dismissible-dismissed-class
data-w-dismissible-id

which I think look great 🙂

@laymonage  great feedback, thanks for this. I have been digging into the nuance of the sidebar menu/sub-menu dismissible behaviour and agree that this does not really make sense in the Stimulus controller only as it has to 'update' when the parent menu item is clicked and also manage things like counts.
However, I would like to suggest we avoid exporting updateDismissibles from the controller and instead approach this a bit differently, here are some ideas;

Util file - create a 'util' that just has this updateDismissibles code in a different file, both the controller and the React code import this util and use to update in their isolated behaviours. In this case, the two implementations are quite disconnected and as noted, we would not make the link items a controlled element at all. React dismissibles would not be controlled elements, i.e. not have the data-controller.
DOM Events - The Stimulus controller is attached to any dismissible items, even those in React, and exposes an event listener for doing the updates (either just 'one' added in afterLoad) or per instance. Then the React code will dispatch a DOM event when any updates need to occur. The benefit here is the code and behaviour is all attached in one file and we are using DOM events to drive behaviour. React dismissibles would be controlled elements, i.e. have the data-controller. Downside is that we would have no way to to a then on the promise.
Static property - Make the updateDismissibles available as a static method on the controller, this is kind of a middle ground, where the connected code is all in one file but if other code needs to 'reach in' and grab the function, they can do that easily. React dismissibles would not be controlled elements, i.e. not have the data-controller.
Leverage data attributes. The constraint I see here is the desire to present a 'count' (state) on the parent menu items, this is not really something that we want to pull out of React as noted. If we did not have this we could actually just have React update the data attribute to in turn tell the Stimulus controller to update its state which is pretty epic. I think that may come in handy in the future but will not help us here. We could also make the 'parent' element controlled element, then when React determines the update needs to happen, it simply toggles a data attribute, this would happen in ActionMenuItem.tsx, it's probably a larger change though and pushes more knowledge of the data attributes further down the React tree, I think this would be good to consider but probably too much effort than it's worth.

As for naming, that 100% makes sense, I suggested the shorter name mostly as a convenience, but agree we should align with the original naming justification.
However, the attribute for the id would instead be data-w-dismissible-id-value='whats-new-in-wagtail-5.0' (with the value at the end), same for whether the item is dismissed data-w-dismissible-dismissed-value (note: does not need to be ='true' as per current state, just needs the word value at the end.
Let me know if this all makes sense and if there is any preference on the way we keep the updateDismissibles, I guess option 3 above is the simplest way to preserve current behaviour but also keep code together. It just means that React code is importing a Stimulus controller file.
I will then update this issue accordingly.

One thing I'd love to see if we can avoid is putting the admin API path for the dismiss update url into a global constant.
Instead with option 2 above, this url can exist on the Dom element as a data attribute.
We would still keep the csrf token in the window global but it gives us a path forward for avoiding adding more and more URL paths globally. However, I understand that may not be something that we think matters.
See. https://github.com/wagtail/wagtail/issues/9771

Idea. We go with putting the URL on the element, but keep the updateDismissibles function importable. Then the React code can call it with the provided URL as it's already reading the data attributes as is to determine if it's been dismissed.
It would be pretty close to current state and gives us a lot more flexibility for future usage of the dismissible items.

Hi @lb-
I'm going to start working on this today.
Currently, is there a way I can get back the what's new in wagtail banner if I mistakenly click on the dismissible button?

Hey @Lovelyfin00, I usually change this method:
https://github.com/wagtail/wagtail/blob/e219968e60723815746ca2c6983b8a4152e13a7e/wagtail/admin/views/dismissibles.py#L10-L14
to something like
    def get(self, request, *args, **kwargs):
        # The UserProfile may not exist for the user, in which case return an empty object
        profile = getattr(request.user, "wagtail_userprofile", None)
        dismissibles = profile.dismissibles if profile else {}
        # Empty dismissibles state for testing purposes
        # Note that the response will show the state before it's cleared
        profile.dismissibles = {}
        profile.save(update_fields=["dismissibles"])
        return JsonResponse(dismissibles)

Then access /admin/dismissibles/ from the browser. It'll show you the current state before it's cleared. To verify, if you load it again, it should show an empty JSON object, and the admin will show all the dismissibles as if they haven't been dismissed.

Hey @Lovelyfin00, I usually change this method:
https://github.com/wagtail/wagtail/blob/e219968e60723815746ca2c6983b8a4152e13a7e/wagtail/admin/views/dismissibles.py#L10-L14
to something like
    def get(self, request, *args, **kwargs):
        # The UserProfile may not exist for the user, in which case return an empty object
        profile = getattr(request.user, "wagtail_userprofile", None)
        dismissibles = profile.dismissibles if profile else {}
        # Empty dismissibles state for testing purposes
        # Note that the response will show the state before it's cleared
        profile.dismissibles = {}
        profile.save(update_fields=["dismissibles"])
        return JsonResponse(dismissibles)

Then access /admin/dismissibles/ from the browser. It'll show you the current state before it's cleared. To verify, if you load it again, it should show an empty JSON object, and the admin will show all the dismissibles as if they haven't been dismissed.

Nice
This makes sense
So you're overriding and updating the current dismissible attribute in the user profile
Thanks, Sage!

Awesome. This is way better than the approach I took - resetting the user each time I tested the feature. Thanks Sage.

3. Static property - Make the updateDismissibles available as a static method on the controller, this is kind of a middle ground, where the connected code is all in one file but if other code needs to 'reach in' and grab the function, they can do that easily. React dismissibles would not be controlled elements, i.e. not have the data-controller.

Hey @lb-
I'm confused on this
I know that I can't access the updateDismissible method in the component using this.getControllerForElementAndIdentifier or this.controllerForElement(). How then can i acess the method?


Make small adjustements to the developer docs

Summary of the changes / Why this improves CrateDB

Remove the runDebug part since we don't explain how a debugger would
be attached. People familiar with gradle and remote debugging will know
that it exists anyway.

Re-order distTar & installDist, given that distTar is a subset of
installDist it makes sense to explain it first.

Checklist

[x] User relevant changes are recorded in CHANGES.txt
[x] Touched code is covered by tests
[x] Documentation has been updated if necessary
[x] CLA is signed

@seut sorry, I pushed another commit to this PR

retest this please


java.lang.UnsatisfiedLinkError

I have added implementation 'com.madhavanmalolan.android:ffmpegandroidlibrary:0.0.4' in my dependencies and jcenter under repositories.
I tried to do a simple test as below:
try {
                Controller.getInstance().run(new String[]{
                            "-y",
                            "-i",
                            mp4_location,
                            "-vcodec",
                            "copy",
                            "-an",
                            mux_location
                });
            } catch (Exception er) {
                System.out.println("failed: "+er);

And got the below error:
 java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.tabaud.musik-K25pRG8-9drkRBScyQosFw==/base.apk", zip file "/data/app/com.tabaud.musik-K25pRG8-9drkRBScyQosFw==/split_lib_directories_apk.apk", zip file "/data/app/com.tabaud.musik-K25pRG8-9drkRBScyQosFw==/split_lib_resources_apk.apk"],nativeLibraryDirectories=[/data/app/com.tabaud.musik-K25pRG8-9drkRBScyQosFw==/lib/x86, /data/app/com.tabaud.musik-K25pRG8-9drkRBScyQosFw==/base.apk!/lib/x86, /data/app/com.tabaud.musik-K25pRG8-9drkRBScyQosFw==/split_lib_directories_apk.apk!/lib/x86, /data/app/com.tabaud.musik-K25pRG8-9drkRBScyQosFw==/split_lib_resources_apk.apk!/lib/x86, /system/lib, /system/vendor/lib]]] couldn't find "libffmpeg.so"
Am i missing any additional configuration here?  please suggest.

this lib is compiled for arm but i can see your phone architecture as x86, meaning you will have to compile ffmpeg to support x86...

hello
i build .so file for all architecture. now i can not get how to build libffmpeg.so  for run ffmpeg command


Provide default progress loggers and use new ProgressLogging API

This PR fixes https://github.com/JuliaDiffEq/DiffEqFlux.jl/issues/158 and adds support for the new (unreleased) support of default progress loggers in DiffEqBase to DiffEqFlux. In my local tests, progress bars were displayed in the terminal successfully (but maybe you want to disable the progress bars in the CI tests since it seems to fill up the logs IIRC).
As mentioned by @tkf in https://github.com/JuliaDiffEq/DiffEqFlux.jl/issues/158#issuecomment-586768555, the problem with the current approach of setting up the progress logs (and also in https://github.com/JuliaDiffEq/DiffEqFlux.jl/pull/183) is that the progress bar can't distinguish between a crashed and a slow progress. To get this right, the PR makes use of ProgressLogging.@withprogress and the new ProgressLogging API. In this way also a UUID is used as id automatically. However, since ProgressLogging.@withprogress automatically initializes the progress bar before the first manual progress update (in https://github.com/JunoLab/ProgressLogging.jl/blob/b64333df0f4d2e780387af01867cccb7460da33d/src/ProgressLogging.jl#L326), a macro helps to use it only if progress output is desired. Otherwise, a progress bar might be initialized and finalized after the computations even though the user specified progress = false.

It seems Travis tests fail due to the same error as on master.

Should the progress bars be disabled in the tests?

The error on master: @pkofod did you forget to tag Optim?


feat: add protobuf 3.22.1 release

update protobuf with release 3.22.1

:tada: This PR is included in version 1.86.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Fastavro iter_avro

Im trying to use the bag.read_avro() functionality, but I get the following error:
AttributeError: module 'fastavro' has no attribute 'iter_avro'

Here is the code to reproduce the case:
import dask.bag as db
path_input = './data/*.avro'
df = db.read_avro(path_input).compute()

From the fastavro (1.0.0.post1) doc, I get it should be calling fastavro.reader instead of fastavro.iter_avro:
https://github.com/fastavro/fastavro/blob/3474b6c8a2a38c7d39ca955a5e3d0261d6f3659f/fastavro/read.py
Environment:

Dask version: 2.11.0
Fastavro version: 1.0.0.post1
Python version: 3.7
Operating System: Linux
Install method (conda, pip, source): pip

Thanks for the report. IIUC, fastavro has changed their API? Do you want to update https://github.com/dask/dask/blob/7f5f7fe49298c2353977b99a081be47dc28bc358/dask/bag/avro.py to be compatible with it (and the old version too, ideally).

Ref: https://github.com/dask/dask/pull/6740

@lqrz you gave a thumbsup to https://github.com/dask/dask/issues/6744#issuecomment-712036919. Does that mean you're looking into updating the code in dask.bag.avro?

@TomAugspurger Hi, Tom! nono, I just intended to support your good interpretation of my original report 😄 ; but im not looking into it!


ImportError: No module named _moments

When i try compute moments by:
cube.moment0()
i get the following error:
ImportError                               Traceback (most recent call last)
 in ()
----> 1 cube.moment0()
/usr/local/lib/python2.7/dist-packages/spectral_cube/spectral_cube.pyc in moment0(self, axis, how)
/usr/local/lib/python2.7/dist-packages/spectral_cube/spectral_cube.pyc in moment(self, order, axis, how)
ImportError: No module named _moments

This looks like an installation failure, and it's a weird one.  Could you try re-installing, and also report what version of spectral-cube you're using?

As this was with an old spectral-cube version and we no longer support python 2, I'm going to close this.
Re-open if the issue shows up elsewhere with the current version.


Factorize methods addMarkerToMap and addMarkersToMap

The code of these two methods is very similar.
It looks like addMarkersToMap could be a loop calling addMarkerToMap.
In NearbyParentFragment.java

Hi I would like to work on this issue. Can you please assign it to me ?

@ujjwal2900 It is yours, thanks! :-)

Hi @nicolas-raoul, I have changed the code for addMarkersToMap method and raised a PR. Can u please review it.

Thanks @ujjwal2900 for fixing this! :-)


Google search fails

When I tried to do Google search specific to the domain pastebin.com as described in: https://mig5.net/content/monitoring-pastebincom-scumblr
I'm getting the following error:
Unable to run task Pastebin Crawler. Error: undefined method []' for nil:NilClass ["/home/b05/Scumblr/lib/search_providers/provider.rb:113:in create_event'", "/home/b05/Scumblr/lib/search_providers/provider.rb:92:in create_error'", "/home/b05/Scumblr/lib/search_providers/provider.rb:33:in block in initialize'", "/home/b05/Scumblr/lib/search_providers/provider.rb:30:in each'", "/home/b05/Scumblr/lib/search_providers/provider.rb:30:in initialize'", "/home/b05/Scumblr/lib/search_providers/google.rb:73:in initialize'", "/home/b05/Scumblr/app/models/task.rb:137:in new'", "/home/b05/Scumblr/app/models/task.rb:137:in perform_task'", "/home/b05/Scumblr/app/workers/task_worker.rb:30:in perform'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/processor.rb:155:in execute_job'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/processor.rb:136:in block (3 levels) in process'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/chain.rb:128:in block in invoke'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-status-0.6.0/lib/sidekiq-status/server_middleware.rb:37:in call'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/chain.rb:130:in block in invoke'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/server/active_record.rb:6:in call'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/chain.rb:130:in block in invoke'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/server/retry_jobs.rb:74:in call'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/chain.rb:130:in block in invoke'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/server/logging.rb:11:in block in call'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/logging.rb:32:in with_context'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/server/logging.rb:7:in call'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/chain.rb:130:in block in invoke'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/middleware/chain.rb:133:in invoke'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/processor.rb:131:in block (2 levels) in process'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/processor.rb:171:in stats'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/processor.rb:130:in block in process'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq.rb:35:in block in module:Sidekiq'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/processor.rb:122:in process'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/processor.rb:81:in process_one'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/processor.rb:69:in run'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/util.rb:17:in watchdog'", "/home/b05/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/sidekiq-4.2.3/lib/sidekiq/util.rb:25:in `block in safe_thread'"]
I'm a first time user. Your help is very much appreciated.

Hi @bofinbabu,
Are you using the latest version of Scumblr?  That error was resolved a number of months ago.

Hi @bofinbabu,
I am closing this issue since I didn't hear back from you.  Please reopen if upgrading to the latest Scumblr didn't resolve the issue.


Publishing package on conda-forge

Hi @iwpnd, this is a great package! Unfortunately, it is not available on conda-forge while flashtext can be found.
I'm building a library around it and I can only fetch packages from conda-forge so I'm wondering if you might accept PR to publish on conda-forge eventually.
For now the workaround is to embed all flashgeotext as a module statically but I would love to declare it in the dependencies.

Hi @francbartoli, I'd be happy to accept your PR on this. I'd learn a thing or do I believe. :)

Hi @iwpnd, sorry for the late follow up on this. I'm now ready to perform it so I'm going to start the procedure.
By the way, I've just published pyflashtext to conda-forge, which is a fork of the original flashtext. I had to take this decision because the codebase contained the fuzzy search but the maintainer wasn't able to publish a new version of the package for a long time (see this issue).
I'd like to integrate the fuzzy search functionality as optional to flashgeotext, what do you think?

I've started the pull request for conda-forge https://github.com/conda-forge/staged-recipes/pull/14513.
@iwpnd can you please post a comment there to just say you are willing to be listed as maintainer?

I followed the discussion around the fuzzy search. Sounds like a good addition but would decrease performance depending on the edit distance? Would've to be an option in this case.

@francbartoli done

Our feedstock repo has been created on the conda-forge organization and the package is available to install in conda.
@iwpnd you can review the pr at your earliest convenience and then close this once that is merged.


set builtin for handling heketi-cli failures

Using the setbuiltin to handle command line execution errors and also handle the unset variables in the  deploy script
Pair Programmed with @raghavendra-talur

This change is

@obnoxxx @humblec  I have made the requested changes. Could you review.

LGTM

I'm not sure I entirely like this change. Why do we need this instead of just checking the return code of the heketi-cli commands? This post makes a pretty convincing argument as to why we would want to be very cautious of or avoid set -e and use our own explicit error checking mechanisms.
I also don't see a need for -u, unless you're thinking of making it a rule that all variables need to at least be initialized to "", in which case I would want to see that the script throws out an appropriate error message when expanding an unset variable.
-o pipefail seems fine to me.

After a good face-to-face with @raghavendra-talur, I now have a bette runderstanding of the set options and their intended use. We will keep an eye out for any complications brought about by -eu, but thus far developer testing proves them to be safe.
LGTM :)


Package netcoredbg

Project description
netcoredbg is an open-source debugger for .NET Core applications. The most popular one, vsdbg, is a binary blob distributed with the Visual Studio Code C# extension. However, vsdbg's license is incredibly restrictive. netcoredbg is a drop-in replacement, and is also compatible with other editors.
Metadata

homepage URL: https://github.com/Samsung/netcoredbg
source URL: https://github.com/Samsung/netcoredbg
license: MIT
platforms: Linux, macOS, Windows (possibly others?)

I was having some issues with .NET 5, going to try again.


Styling the header component to be consistent and professional

User Story:
As a user of Feedr, I want to see a consistent and crisp looking website so that I am more attracted towards using it.
Acceptance Criteria:

Consistent Styling of Buttons
Good spacing and layout of components

Why is the feature required?
For Feedr to look consistent
Describe the solution you'd like
Consistent Styling of Buttons and good spacing and layout of components to name a few
Additional Context:

I'm sorry, accidentally created this and #242 here instead of the other repo


proper placement of the Testimonial section in the center

The placement of the Testimonial section will be made such that the site remains responsive.
@Anupkjha2601

I want to work on this issue under GSSoC'23. Please assign me this issue.

Hey! Anyone still working on this issue?

@duragpal I am working on it because there is problem in site only if you want to try it I can assign you. I think @shramanpaul has taken their time so if you want I can assign you.


Added the new SPWebAppSuiteBar resource to edit Web App Suite Bar branding

✔ Change details added to Unreleased section of changelog.md?
✔ Added/updated documentation and descriptions in .schema.mof files where appropriate?
✔ Examples updated for both the single server and small farm templates in the examples folder?
✔ New/changed code adheres to Style Guidelines?
✔ Unit and Integration tests created/updated where possible?

This change is

Codecov Report

Merging #662 into dev will decrease coverage by <1%.
The diff coverage is 1%.

@@         Coverage Diff         @@
##            dev   #662   +/-   ##
===================================
- Coverage    90%    89%   -1%
===================================
  Files        90     91    +1
  Lines      8605   8688   +83
  Branches      3      3
===================================
+ Hits       7771   7772    +1
- Misses      831    913   +82
  Partials      3      3

Pop open the Champagne! It worked!

You're missing the resource-specific example for this one (under Modules\SharePointDsc\Examples\Resources\SPWebAppSuiteBar). I've got some feedback on the main work done, I'll review the tests once the other changes are made. Thanks mate

Reviewed 1 of 4 files at r1, 5 of 6 files at r2.
Review status: 6 of 7 files reviewed at latest revision, 10 unresolved discussions.

CHANGELOG.md, line 7 at r2 (raw file):

* Added resource: SPMinRoleCompliance

## 2.0

Can you put this under "unreleased" like we normally do?

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 38 at r2 (raw file):

    Write-Verbose -Message "Getting web app suite bar properties for $WebAppUrl"

    $installedVersion = Get-SPDSCInstalledProductVersion

I don't think you are using this line here at all since you grab the version inside the invoke block below, so you should be able to remove this line

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 50 at r2 (raw file):

        if ($null -eq $wa)
        {
            return $null

We shouldn't be returning null from "get" methods. I would return the initial $returnVal value you have below with all the nulls on it rather than a flat-out null

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 140 at r2 (raw file):

        }
    }
    elseif($installedVersion.FileMajorPart -ge 16)

Rather than elseif can you put this in to a switch statement, then use a default block that throws an error about using an unsupported version of SP. There are examples of this elsewhere in the module

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 164 at r2 (raw file):

    $CurrentValues = Get-TargetResource @PSBoundParameters

    if ($null -eq $CurrentValues)

Expect this to not be a $null based on the previous item, so you'll need to change your approach here as well

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 189 at r2 (raw file):

        {
            $wa.SuiteBarBrandingElementHtml = $params.SuiteBarBrandingElementHtml
            $wa.Update()

You can put this update line after the if statement seeing as it's in both code blocks

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 241 at r2 (raw file):

    $CurrentValues = Get-TargetResource @PSBoundParameters

    if ($null -eq $CurrentValues)

Again don't expect a null here

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 247 at r2 (raw file):

    # Determine the default identity type to use for entries that do not have it specified
    $returnValue = Invoke-SPDSCCommand -Credential $InstallAccount `

I don't think you need all of this logic here, you should just be able to use the Test-SPDscParameterState to compare the values. They will either match the desired state or they won't, and if the user provides invalid parameters then this will get caught in the set method. This means we can simplify this test method down a whole lot.

Modules/SharePointDsc/Examples/Single Server/SharePoint.ps1, line 142 at r2 ([raw file](https://github.com/powershell/sharepointdsc/blob/5026a4a78823a7f0bb37fcc1b3b403383c259c77/Modules/SharePointDsc/Examples/Single Server/SharePoint.ps1#L142)):

        }

        SPWebAppSuiteBar SuiteBarBranding

We tend to keep the examples here to just basic resources so it doesn't need to go in here, can you please remove this one

Modules/SharePointDsc/Examples/Small Farm/SharePoint.ps1, line 155 at r2 ([raw file](https://github.com/powershell/sharepointdsc/blob/5026a4a78823a7f0bb37fcc1b3b403383c259c77/Modules/SharePointDsc/Examples/Small Farm/SharePoint.ps1#L155)):

        }

        SPWebAppSuiteBar SuiteBarBranding

We tend to keep the examples here to just basic resources so it doesn't need to go in here, can you please remove this one

Comments from Reviewable

Review status: 6 of 7 files reviewed at latest revision, 10 unresolved discussions.

CHANGELOG.md, line 7 at r2 (raw file):
Previously, BrianFarnhill (Brian Farnhill) wrote…
Can you put this under "unreleased" like we normally do?

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 38 at r2 (raw file):
Previously, BrianFarnhill (Brian Farnhill) wrote…
I don't think you are using this line here at all since you grab the version inside the invoke block below, so you should be able to remove this line

You are right. I removed the line

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 50 at r2 (raw file):
Previously, BrianFarnhill (Brian Farnhill) wrote…
We shouldn't be returning null from "get" methods. I would return the initial $returnVal value you have below with all the nulls on it rather than a flat-out null

I copied this line from the SPWebAppPolicy Resource. It also returns a direct $null, but I have changed mine to follow your recommendations.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 140 at r2 (raw file):
Previously, BrianFarnhill (Brian Farnhill) wrote…
Rather than elseif can you put this in to a switch statement, then use a default block that throws an error about using an unsupported version of SP. There are examples of this elsewhere in the module

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 164 at r2 (raw file):
Previously, BrianFarnhill (Brian Farnhill) wrote…
Expect this to not be a $null based on the previous item, so you'll need to change your approach here as well

Good call. Logic changed to check for WebAppUrl key to be null instead

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 189 at r2 (raw file):
Previously, BrianFarnhill (Brian Farnhill) wrote…
You can put this update line after the if statement seeing as it's in both code blocks

Done deal. One less line of code.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 241 at r2 (raw file):
Previously, BrianFarnhill (Brian Farnhill) wrote…
Again don't expect a null here

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 247 at r2 (raw file):
Previously, BrianFarnhill (Brian Farnhill) wrote…
I don't think you need all of this logic here, you should just be able to use the Test-SPDscParameterState to compare the values. They will either match the desired state or they won't, and if the user provides invalid parameters then this will get caught in the set method. This means we can simplify this test method down a whole lot.

Yeah, you are right. I overdid the Test method a bit. It is simplified now.

Modules/SharePointDsc/Examples/Single Server/SharePoint.ps1, line 142 at r2 ([raw file](https://github.com/powershell/sharepointdsc/blob/5026a4a78823a7f0bb37fcc1b3b403383c259c77/Modules/SharePointDsc/Examples/Single Server/SharePoint.ps1#L142)):
Previously, BrianFarnhill (Brian Farnhill) wrote…
We tend to keep the examples here to just basic resources so it doesn't need to go in here, can you please remove this one

Done

Modules/SharePointDsc/Examples/Small Farm/SharePoint.ps1, line 155 at r2 ([raw file](https://github.com/powershell/sharepointdsc/blob/5026a4a78823a7f0bb37fcc1b3b403383c259c77/Modules/SharePointDsc/Examples/Small Farm/SharePoint.ps1#L155)):
Previously, BrianFarnhill (Brian Farnhill) wrote…
We tend to keep the examples here to just basic resources so it doesn't need to go in here, can you please remove this one

Done

Comments from Reviewable

@NikCharlebois Mate, your last commit broke some of the tests. Can you fix this, so we can merge this PR?

It's fixed now.

Review status: 2 of 8 files reviewed at latest revision, 10 unresolved discussions.

CHANGELOG.md, line 7 at r2 (raw file):
Previously, NikCharlebois (Nik Charlebois) wrote…
Done.

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 38 at r2 (raw file):
Previously, NikCharlebois (Nik Charlebois) wrote…
You are right. I removed the line

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 50 at r2 (raw file):
Previously, NikCharlebois (Nik Charlebois) wrote…
I copied this line from the SPWebAppPolicy Resource. It also returns a direct $null, but I have changed mine to follow your recommendations.

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 140 at r2 (raw file):
Previously, NikCharlebois (Nik Charlebois) wrote…
Done.

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 164 at r2 (raw file):
Previously, NikCharlebois (Nik Charlebois) wrote…
Good call. Logic changed to check for WebAppUrl key to be null instead

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 189 at r2 (raw file):
Previously, NikCharlebois (Nik Charlebois) wrote…
Done deal. One less line of code.

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 241 at r2 (raw file):
Previously, NikCharlebois (Nik Charlebois) wrote…
Done.

Done.

Modules/SharePointDsc/DSCResources/MSFT_SPWebAppSuiteBar/MSFT_SPWebAppSuiteBar.psm1, line 247 at r2 (raw file):
Previously, NikCharlebois (Nik Charlebois) wrote…
Yeah, you are right. I overdid the Test method a bit. It is simplified now.

Done.

Modules/SharePointDsc/Examples/Single Server/SharePoint.ps1, line 142 at r2 ([raw file](https://github.com/powershell/sharepointdsc/blob/5026a4a78823a7f0bb37fcc1b3b403383c259c77/Modules/SharePointDsc/Examples/Single Server/SharePoint.ps1#L142)):
Previously, NikCharlebois (Nik Charlebois) wrote…
Done

Done.

Modules/SharePointDsc/Examples/Small Farm/SharePoint.ps1, line 155 at r2 ([raw file](https://github.com/powershell/sharepointdsc/blob/5026a4a78823a7f0bb37fcc1b3b403383c259c77/Modules/SharePointDsc/Examples/Small Farm/SharePoint.ps1#L155)):
Previously, NikCharlebois (Nik Charlebois) wrote…
Done

Done.

Comments from Reviewable

Reviewed 5 of 6 files at r3, 2 of 2 files at r4.
Review status: all files reviewed at latest revision, 10 unresolved discussions.

Comments from Reviewable

 Just needs a pull from dev to resolve conflicts in the changelog and it's good to go.

Reviewed 5 of 6 files at r3, 2 of 2 files at r4.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

Reviewed 1 of 1 files at r5.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Unablt to connect, stuck on "Transitioning from START to IN_SASL due to connected"

I can't get to any of the callbacks on the connection, neither with correct/invalid authentication credentials. It gets stuck on the state "Transitioning from START to IN_SASL due to connected". I have auto reconnect setup so the same message is printed over and over. Why are the this.client.connect call neither resolving as success nor failure? Is there some event somewhere that I should be listening to instead?
(Trying to connect to an instance of ActiveMQ version 5.13.2)
DEBUG=amqp* AMQP_PORT=61613 AMQP_USER=consumer AMQP_PASSWORD=password node .
  amqp10:client connecting to: amqp://consumer:password@localhost:61613 +0ms
  amqp10:transport:net Connecting to localhost:61613 via straight-up sockets +6ms
  amqp10:connection Transitioning from DISCONNECTED to START due to connect +3ms
Connecting using amqp://consumer:password@localhost:61613
  amqp10:connection Sending Header 414d515003010000 +2ms
  amqp10:connection Transitioning from START to IN_SASL due to connected +0ms

const AMQP = require('amqp10');

const AMQP_HOST = process.env.AMQP_HOST || 'localhost';
const AMQP_PORT = process.env.AMQP_PORT || 5672;
const AMQP_USER = process.env.AMQP_USER;
const AMQP_PASSWORD = process.env.AMQP_PASSWORD;

let uri = '';
if (AMQP_USER) {
  uri = `amqp://${AMQP_USER}:${AMQP_PASSWORD}@${AMQP_HOST}:${AMQP_PORT}`;
} else {
  uri = `amqp://${AMQP_HOST}:${AMQP_PORT}`;
}

this.client = new AMQP.Client(AMQP.Policy.ActiveMQ);
this.client.connect(uri).then(() => {
  console.log('connected', `amqp://${AMQP_HOST}`);
  this.client.createReciever('log').then((reciever) => {
    console.log('reciever created');
    reciever.on('message', (message) => {
      const level = message.level === 'warning' ? 'warn' : message.level;

      if (console[level] instanceof Function) {
        if (message.package) {
          console[level](
            (new Date(message.date).toISOString()),
            message.package.name,
            message.package.version,
            message.level,
            message.data
          );
        } else {
          console[level](
            (new Date(message.date).toISOString()),
            message.level,
            message.data
          );
        }
      }
    });
  }, (error) => {
    // Is this useful or are ErrorRecieved event listner enough??
    console.error(error);
    throw new Error('Unable to create a reciever for the amqp service, exiting');
  });
}, (error) => {
  // Is this useful or are ErrorRecieved event listner enough??
  console.error(error);
  throw new Error('Unable to connect to the amqp service, exiting');
});

this.client.on(AMQP.Client.ErrorReceived, error => console.error(error));

console.log(`Connecting using ${uri}`);

@tirithen do the logs stop there? There's no further data sent?

Yes, they stop there

That looks like the amqp server isn't responding to anything on that port, are you sure you have an AMQP 1.0 listener on that port? (I noticed in the log you are connecting to port 61613 but default to the expected 5672 in your code snippet)

Oh. Port 61613 is for the STOMP protocol, we do not support that with this library.

I thought so, using docker image from https://hub.docker.com/r/webcenter/activemq/

Ah, guess I need to find out more about that docker image as well. Would still be great with a failed to connect callback somewhere even in that case though. :)

Well that's exactly it, from our perspective we did not fail. This is like sending ssh commands to a telnet server, at what point do you say this failed to a user? We could theoretically time out on the connection attempt I guess

Okay, yes maybe that makes sense. But what if you have configured the ports in a bad way for example. If nothing is listening I do get an error.

Anyway, it's probably mostly me that is new to this and need to find a docker image with ActiveMQ that works.

@tirithen let's look at it another way. When you screw up the ports, and we connect and give you an error that's like making a telephone call and getting an "out of service" error from the telephone company - you're right, we propagate that error from the operating system in that case. In your case here, it's like you are a person who speaks english calling what they think is another person who speaks english, but instead getting someone who speaks Mongolian. The connection succeeded, and you say "hello" and then get nothing in return because the Mongolian has no idea what you said. There is no error to be propagated here, you simply have made a mistake from your side. The only thing that could be done is to modify the connect code such that if in  the connection does not succeed, then we could throw a "timeout error".

WRT your docker image, iirc ActiveMQ comes with support for AMQP 1.0 and STOMP out of the box. You simply need to make sure you enable the AMQP 1.0 backend, and connect on the default port of 5672

:) Okay, it's okay
Yes, realized that now, so enabled port 5672 but instead got some protocol version problem
Server AMQP Version: 6976654d51000000 vs 414d515000010000

Nevermind now everything works! :D


New release

Hey @jeroenvisser101 can you create a new release? Thanks.

@lukasoppermann since you're a contributor, you should be able to do this yourself now, if I'm correct. :)

Yes, true, I just was not sure if this is fine by you. :)

Sure, just stick by semver :)


Non-fatal error: exports is not defined

My dev tools console gives the following error:
Uncaught ReferenceError: exports is not defined(…) Line 2659
The error is not fatal; your boilerplate script works as expected. Please let me know if you need further details.

I probably added the Node-patch which introduced this. I'll get it fixed.
Thanks for reporting!


bug fix HTTP mixed-content warning by editing HTML

This site is live on mirai.audio but is throwing a HTTP mixed-content warning because the <img> tags on the page refer to non-HTTPS URLs.
These errors appear in the console as:
Loading mixed (insecure) display content “http://placekitten.com/420/420” on a secure page

They appear in the browser as follow:

[ ] replace hard coded links to http:// with https://
[ ] verify mixed-content warnings are gone

@0xadada I would like to work on this.

@rajkharvar yes, please do go ahead! 👍

fixed by https://github.com/mirai-audio/html5-kitchen-sink-test/pull/3/commits/ae99697dbd55fd0048691203568a667b94fbfe4c


Allow options to be passed to model

This lets you pass things like Person.search(includes: :name, unscoped: nil).

Merging!