Fix name mangling and typevar errors (dev branch)

Issue: https://github.com/capitalone/DataProfiler/issues/722
Inside the BaseDataProcessor class definition, all references to __subclasses are automatically replaced with
_BaseDataProcessor__subclasses. This remains the case even in static methods _register_subclass() and get_class(). Same with BaseModel and its __subclasses field. So we do not have to write out the full name mangled identifiers inside the class definitions.
Also, mypy doesn't seem to be able to handle the return type of BaseDataProcessor.get_class() being a typevar, so that was changed to type[BaseDataProcessor]. This does not affect the functionality of get_class() since it always returns a subclass of BaseDataProcessor.
This PR is a duplicate of https://github.com/capitalone/DataProfiler/pull/895, except it is based on the dev branch instead of main

license/cla is stuck in "expected" status, so I'll push an empty commit

Need to revert to ensure dev is updated to main before we continue additional PRs to dev or feature/* branching off dev. @junholee6a -- not your fault. If you can, just rebase / cherry pick your commits here on dev once I update things. I'll pop another comment here once its ready to go

The idea here is that we will take current dev and rename it to something like dev/release/0.10.0. But since we are going to re-create dev from main we would loose your changes in the "new" dev branch. Hopefully that is helpful in adding a bit more clarity. Thanks!

Okay -- good to go on a re-open @junholee6a into dev. Thanks again!

Okay -- good to go on a re-open @junholee6a into dev. Thanks again!

Thanks for the heads up, I just re-made the branch and PR


fix streaming callback repartition null reference bug

Current coverage is 76.46%

Merging #290 into master will increase coverage by +1.27% as of 35808d7

@@            master    #290   diff @@
======================================
  Files           40      40
  Stmts         3930    3930
  Branches       342     340     -2
  Methods
======================================
+ Hit           2955    3005    +50
+ Partial        143     142     -1
+ Missed         832     783    -49

Review entire Coverage Diff as of 35808d7

Powered by Codecov. Updated on successful CI builds.


Deprecate use of unexposed field from opt-einsum=2.1.3

It seems like einsum_symbols_base has been made private in the latest einsum release. This is breaking the doctest in #1345.

Codecov Report

Merging #1346 into dev will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##              dev    #1346   +/-   ##
=======================================
  Coverage   95.88%   95.88%
=======================================
  Files         122      122
  Lines        6415     6415
=======================================
  Hits         6151     6151
  Misses        264      264

Impacted Files
Coverage Δ

pyro/ops/einsum/torch_log.py
94.44% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Set up CI with Azure Pipelines for branch build-pipeline

[skip ci]

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: swiftMaster2017 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Support for Docker Desktop on Apple Silicon

Tell us about your request
Provide support for Docker Desktop for Apple computers running on Apple custom silicon.
Which service(s) is this request for?
Docker Desktop for Mac
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Mac will be moving to a new CPU architecture where Docker Desktop will no longer run, this ticket is to release Docker Desktop on the new architecture
Are you currently working around the issue?
Using a self hosted VMs on new Macs to run Docker
Additional context
https://www.apple.com/uk/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/

If I'm clear, you work around isn't working at least for m1, because m1 doesn't support virtualization. So no VM on the host?

.

Work on docker-compose can be tracked here: https://github.com/docker/roadmap/issues/142

Progress on getting Docker Desktop running on Apple Silicon (M1). Lots (lots!) of duct-tape still, but this screenshot should make many people happy: (I can't take any credits for this, so give Dave's tweet a like ❤  https://twitter.com/mugofsoup/status/1332382741892124675?s=20)

@thaJeztah is there a download of that version to download and test?

@rene-mueller no, much too early for that. This is a local build on a developer's machine. Still needs lots of hand-holding to run it, and we have a very limited number of machines to work with (remote-desktop across continents), waiting for more machines to arrive (also for our release and CI pipelines).
We definitely want to get test builds out as soon as possible, when they're more usable, but that will still take some time.

@thaJeztah what a pity, is there any way to help you and speed up the process?

Not at this moment. Team is working on the low-level stuff to get all components running. Debugging some crashes (which could be bugs in Golang (or the way it's used in our code), and bugs in macOS).

@thaJeztah It certainly looks like you and the team are making good progress.  Would it be possible for you to give us a realistic ETA on getting an alpha or beta that runs on the M1 in our hands?  I will not hold you to it but it would help with planning.  Thanks so much!

@EDemerzel Not part of the team so I couldn't tell you, but I find your question/demand really super inappropriate. It's done when it's done. If you want to plan (for what?), assume early June and be happily surprised if it's finished early. Otherwise lay off on the pressure and be grateful that you will receive the fruits of their labor for free - whenever that might be. I don't think it's ok to add pressure by asking "when is it done?"

@infostreams Relax, okay? He asked politely and just wanted to know where things are at. He didn't pressure anyone, it was just a question to get a better understanding of what's currently going on. And, believe it or not, some people actually do need to do some planning, especially in an enterprise world. This isn't all fun and games, some people need to work, and some people need docker for this. And yes, docker is free, and he or anyone else using it for free can't demand anything to be done, but it's another thing to just ask a simple question.

@KarimGeiger No. He is putting pressure and he is making demands, however politely phrased, and no - that's not ok. I will stop replying to this thread now, but this needed to be said. I don't mind being the scapegoat for that.

@KarimGeiger No. He is putting pressure and he is making demands, however politely phrased, and no - that's not ok. I will stop replying to this thread now, but this needed to be said. I don't mind being the scapegoat for that.

Just for the record I wasn't attempting to place pressure or demands.  I wasn't even asking about a RC or a Release.  On most of my machines I run "edge" and enjoy testing and giving feedback when I can.  I'm someone that is excited about the M1 and helping products move from Intel to Apple Silicon.  Also, while I do not personally pay for Docker services the people I work for do so I'm not a freeloader.  Lastly, I do apologize if my question rubbed you the wrong way.

Please guys, this is an issue related to a bug in the software. Please refrain from leaving a comment unless it contributes to the conversation at hand.

Assuming we have Docker Desktop for Apple Silicon Macs, how much of a performance hit approximately we’ll have for running x86 images through Docker QEMU?

It certainly looks like you and the team are making good progress. Would it be possible for you to give us a realistic ETA on getting an alpha or beta that runs on the M1 in our hands? I will not hold you to it but it would help with planning. Thanks so much!

At this moment, any estimation would be only "guessing" and very likely to be completely off. The honest answer is "we don't know, until we reached that point". To illustrate that; while we did have parts of Desktop running before, the screenshot was posted just minutes after an engineer was able to spin up Desktop (including the UI). There's still many parts that are currently running with duct-tape solutions (e.g. networking with hard-coded IP addresses etc). These builds are also built with unreleased versions of (build-time) dependencies, such as Golang (and I think with some temporary patches on top of that); while that works to get a test-build, that's not something we can use for an actual (regular) release.
This is pretty much "uncharted territory", and given that Docker tends to use parts of operating systems (including macOS) and kernels in very specific ways that other software may not be using, we may be (and often do) running into bugs in macOS that would need to be fixed before we're able to do a somewhat stable release.

I find your question/demand really super inappropriate
..
He asked politely and just wanted to know where things are at.

@infostreams @KarimGeiger thank you for stepping in; no worries: we're good at "reading between the lines", and I assume @EDemerzel's question was all in good faith.
We are all super-excited to see things progress (I for sure am eyeing the new M1 machines to give them a spin), and with engineers in both San Francisco and Europe working on this, we're literally working around the clock to get things working, and try to make that a reality.

And, believe it or not, some people actually do need to do some planning, especially in an enterprise world.

(Personal opinion); while it's definitely good to start testing with these machines in (enterprise) environments, I would not make a major switch to an entirely new hardware for business-critical situations on "day 1". These machines are the first generation of the Apple Silicon platform; while they should be good for may use-cases, there might still be things that need to be addressed. I very much expect that Apple started with the "lower range" models for this reason: allowing them (and users) to "test the waters" before proceeding with the higher-spec models.

Assuming we have Docker Desktop for Apple Silicon Macs, how much of a performance hit we’re talking about when running x86 images through Docker QEMU?

I'm not sure if we have good benchmarks yet. That said; these machines are FAST, and even with some overhead, performance may be comparable with native intel. Again; we don't have benchmarks yet (but we'll keep you posted once we have).
With all of the above said, I should add some big warnings :warning: to set expectations right;

While we do want to get things into your hands as soon as realistically possible, releasing it "to the world" also brings "support" and "bug-reports" with it. With millions of Docker Desktop users, we wouldn't be able to deal with the "firehose" or reports. For that reason, it's possible we will send out test-builds to a limited group of users before making them generally available. (Nothing decided yet on that, and this will depend on how things progress, etc, etc). Also read the related blog-post which has a sign-up link for a Docker ID (and the newsletter).
As mentioned; currently, we depend on either unreleased, or patched versions of (build-time) dependencies. Those are not suitable for regular releases, so while we may be releasing test-builds at some point (see above), "regular" releases may still be some time out.
Since we started the work on Apple Silicon, we uncovered some bugs in macOS and the macOS kernel on these machines. Some may have been patched since, but others may either have to be worked around, or we have to wait for those to be fixed by Apple.
Additional changes may still be needed in other components, which may include changes to "how" architectures are selected from multi-arch images for these systems.

@thaJeztah This is wonderful information and certainly more than I had ever hoped!  I really appreciate you taking the time to interact with the community like you do.

Thanks for giving us these informations. I'm part of thoses which received a M1 while having ordered an Intel one in early November, prior M1 unveiling. I hope all bugs will soon be fixed by cupertino.
Does anyone know if we can do something to run Docker on M1 inside some kind of VM ?

Thanks for giving us these informations. I'm part of thoses which received a M1 while having ordered an Intel one in early November, prior M1 unveiling.

You ordered a new Intel based Mac in November and instead received an ARM one???

Does anyone know if we can do something to run Docker on M1 inside some kind of VM ?

Yes: https://finestructure.co/blog/2020/11/27/running-docker-on-apple-silicon-m1

Thanks for giving us these informations. I'm part of thoses which received a M1 while having ordered an Intel one in early November, prior M1 unveiling.

You ordered a new Intel based Mac in November and instead received an ARM one???

Yes, we (the company I work for) ordered a MBP 13" in November 4th, and the day after M1 reveal the ordered model was switched from Intel to M1.
@finestructure Thanks, I was reading it when your message came up, nice work. 😉 I'll get a VM from Scaleway to host my developments during the meantime of the M1-compatibility development.

Love you all for working so hard on this.  Thank you!

Amazing work being done here! 👏🏻 👏🏻 👏🏻

Yet another comment to notify every subscriber. Thank you!

It might be a good idea to lock this discussion and allow only comments from the team. Otherwise, the topic's subscription does not make any sense.
/cc @nebuk89

Yet another comment to notify every subscriber. Thank you!

You think you're helping the problem? (I know I'm not)

We switched our entire development team to Ubuntu hosts in order to get around the non-viability (speed) of Docker on Mac. I would love to switch back to Mac, but for our installation, we see page load times of 1 minute or more for our web applications on Mac OS, and 600ms on Ubuntu, for the same exact setup. I tried NFS, Rsync and Mutagen and they all have different challenges that forced us to simply stop using Mac.

Apple M1 Chip – EC2 Mac instances with the Apple M1 chip are already in the works, and planned for 2021
New – Use Amazon EC2 Mac Instances to Build & Test macOS, iOS, iPadOS, tvOS, and watchOS Apps
hope this brings god speed to development !!!

Hi Everyone!
I promised to keep you up to date on progress; If you were at today's community all-hands you may already know (for those that weren't; here's the recording: https://goto.docker.com/on-demand-event-community-all-hands-201210.html)
❗Spoiler alert ❗
Good news! The team has made significant progress, and we will be sending out preview builds of Docker Desktop for Apple Silicon very soon 🎉. We will be using the Developer Preview Program to send out preview builds. If you are interested in giving these builds a spin, you can learn more about the Developer Preview Program (and find a link to register) in this blog post: https://www.docker.com/blog/expanding-dockers-developer-preview-program/
Take in mind; these are still preview builds (some parts are not yet working, and we're working with 🍎 to get some bugs fixed (we discovered some bugs resulting in a kernel panic), os (to quote my college Dave); "Expect it to be a bit rough around the edges, after all it’s a dev preview!"
(more details about what works, doesn't work, and "rough edges" will be provided when we send out the previews 😅 )

Hi Everyone!
I promised to keep you up to date on progress; If you were at today's community all-hands you may already know (for those that weren't; here's the recording: https://goto.docker.com/on-demand-event-community-all-hands-201210.html)
❗Spoiler alert ❗
Good news! The team has made significant progress, and we will be sending out preview builds of Docker Desktop for Apple Silicon very soon 🎉. We will be using the Developer Preview Program to send out preview builds. If you are interested in giving these builds a spin, you can learn more about the Developer Preview Program (and find a link to register) in this blog post: https://www.docker.com/blog/expanding-dockers-developer-preview-program/
Take in mind; these are still preview builds (some parts are not yet working, and we're working with 🍎 to get some bugs fixed (we discovered some bugs resulting in a kernel panic), os (to quote my college Dave); "Expect it to be a bit rough around the edges, after all it’s a dev preview!"
(more details about what works, doesn't work, and "rough edges" will be provided when we send out the previews 😅 )

Hi, @thaJeztah does this version support x86 image build? (in Rosseta2?) 🥺 It's really important for me to build x86 image. I had tried using qemu + arm processor to build x86 image but not worked for me.
Thanks in advance!

@michael34435 Yes, you can build x86 images using qemu in this release.

The Docker Desktop Preview5 runs perfect on my Apple Mac Mini M1!
It runs just fine with both x86 images (tried php-apache)

as well arm64v8 images (used mariadb)

Got error with MySql but that is because then don't have published arm64/v8 image.
So well done team!

Seems the docker.for.mac.host.internal is not working, cannot connect to the MySQL on the host machine.

The preview build doesn't yet have complete functionality. Release notes with known issues for the current build are at https://docs.docker.com/docker-for-mac/apple-m1/

thank you for this build, mac on m1

hi @stephen-turner
if we try with the build in above link , would we need to re-install manually on next release or it will give an option for update.?
Thanks

@sharadjain21 ,
The tech preview build does not update automatically. You must manually install any future versions of Docker Desktop. For more detail please read at https://docs.docker.com/docker-for-mac/apple-m1/#known-issues

Are there any plans to release the Tech Preview on Intel as well? It would be useful to be able to test a version of Docker that uses the new Virtualization.framework on Intel architecture as well if the change to the new framework will eventually make it into all Big Sur builds?
I'm noticing changes in functionality when testing on M1. Specifically, https://github.com/docker/for-mac/issues/155 is no longer an issue because now we do have a bridge interface, so tuntap now works. I'd be interested in testing this on Intel as well.

Are there any plans to release the Tech Preview on Intel as well? It would be useful to be able to test a version of Docker that uses the new Virtualization.framework on Intel architecture as well if the change to the new framework will eventually make it into all Big Sur builds?
I'm noticing changes in functionality when testing on M1. Specifically, https://github.com/docker/for-mac/issues/155 is no longer an issue because now we do have a bridge interface, so tuntap now works. I'd be interested in testing this on Intel as well.

Yes, we will do a preview on Intel, probably in a couple of weeks.

Yes, we will do a preview on Intel, probably in a couple of weeks.

Now that Docker Desktop is using Virtualization.framework, can we expect Docker to continue to contribute to HyperKit?

Now that Docker Desktop is using Virtualization.framework, can we expect Docker to continue to contribute to HyperKit?

thank you for this build, mac on m1. Php and Nginx containers working as well, thanks, guys!

Do you know if it is working PHP8 and Nginx in Alpine images? I wanna know this so I can buy a m1 mac.

thank you for this build, mac on m1. Php and Nginx containers working as well, thanks, guys!

Do you know if it is working PHP8 and Nginx in Alpine images? I wanna know this so I can buy a m1 mac.

Docker on M1 can run any linux/arm64 image out of the box, and any Intel image with emulation if you add --platform linux/amd64 to the command line.

Docker on M1 can run any linux/arm64 image out of the box, and any Intel image with emulation if you add --platform linux/amd64 to the command line.

Docker on M1 can run any linux/arm64 image out of the box, and any Intel image with emulation if you add --platform linux/amd64 to the command line.
EDIT: if someone can tell me how to specify that flag from a docker-compose.yml file, I'd be very grateful.

Build the Docker image manually yourself from the command line:
docker build --platform linux/amd64 -t name-of-image .

If you're dependent on another image in the docker-compose file like mysql just swap it out with mariadb:latest the binaries should be the same and there's no need to reconfigure your settings.py.  The build runs pretty slow, but that's to be expected when building and running through an emulator.  At least it's working

Docker on M1 can run any linux/arm64 image out of the box, and any Intel image with emulation if you add --platform linux/amd64 to the command line.
EDIT: if someone can tell me how to specify that flag from a docker-compose.yml file, I'd be very grateful.

Build the Docker image manually yourself from the command line:
docker build --platform linux/amd64 -t name-of-image .

If you're dependent on another image in the docker-compose file like mysql just swap it out with mariadb:latest the binaries should be the same and there's no need to reconfigure your settings.py.  The build runs pretty slow, but that's to be expected when building and running through an emulator.  At least it's working

If you use the version 2 compose file format, there is a per-service platform flag you can use https://docs.docker.com/compose/compose-file/compose-file-v2/#platform.
That doesn't seem to be the case for version 3 though.
Another option is to set DOCKER_DEFAULT_PLATFORM as an environment variable in the respective directory https://docs.docker.com/engine/reference/commandline/cli/#environment-variables

If you use the version 2 compose file format, there is a per-service platform flag you can use https://docs.docker.com/compose/compose-file/compose-file-v2/#platform.
That doesn't seem to be the case for version 3 though.
Another option is to set DOCKER_DEFAULT_PLATFORM as an environment variable in the respective directory https://docs.docker.com/engine/reference/commandline/cli/#environment-variables

Circling back after using --platform linux/amd64 tag for a couple of weeks...
The builds are almost unbearably slow, even slower than the early days of using Docker with WSL 😞

This is probably because Docker is defaulting to 4 CPU cores.
Virtualization.framework seems to be dropping interrupts not directed at VCPU0. Not sure if this is by design, but definitely appears to be the way it is for now.
Looking at my machine currently with the resources defaulted to 4 cores, It appears that my Docker VM has an SMP affinity list set to 0-3. This will result in dropped interrupts.
Try running this from within the Docker VM:
for f in /proc/irq/*/smp_affinity_list;do echo 0 > $f;done
See if you get significant speedup.
Unless Apple has indicated they will change this behavior, the Docker team should look at ensuring irqbalanced (or equivalent) is not installed in the VM or possibly starting the VM with the kernel parameter:
irqaffinity=0

Virtualization.framework seems to be dropping interrupts not directed at VCPU0. Not sure if this is by design, but definitely appears to be the way it is for now.

Sent this as feedback to Apple (via the Feedback Assistant). Feedback ID: FB8989471

We've also reported the IRQ thing to Apple, by the way.

Docker on M1 can run any linux/arm64 image out of the box, and any Intel image with emulation if you add --platform linux/amd64 to the command line.
EDIT: if someone can tell me how to specify that flag from a docker-compose.yml file, I'd be very grateful.

putting platform: linux/x86_64 in the docker-compose.yml did the trick for me.

Docker on M1 can run any linux/arm64 image out of the box, and any Intel image with emulation if you add --platform linux/amd64 to the command line.
EDIT: if someone can tell me how to specify that flag from a docker-compose.yml file, I'd be very grateful.

putting platform: linux/x86_64 in the docker-compose.yml did the trick for me.

  I can run the docker build command with the platform flag to first build my web app image under the spec that it should be linux/amd64, and then when I run docker-compose build it will inherit that same flag and build the web app 'service' with the same virtualization.  The only thing that differs are the other services you're composing together.  In my instance, I had to switch my db service in the docker-compose to use postgresql or mariadb because there isn't an ARM based image for mysql.

Docker on M1 can run any linux/arm64 image out of the box, and any Intel image with emulation if you add --platform linux/amd64 to the command line.
EDIT: if someone can tell me how to specify that flag from a docker-compose.yml file, I'd be very grateful.

putting platform: linux/x86_64 in the docker-compose.yml did the trick for me.

 You can read more about it in our docs at https://docs.docker.com/docker-for-mac/apple-m1/

Kubernetes now works (although you might need to reset the cluster in our Troubleshoot menu one time to regenerate the certificates).
osxfs file sharing works.
The host.docker.internal and vm.docker.internal DNS entries now resolve.
Removed hard-coded IP addresses: Docker Desktop now dynamically discovers the IP allocated by macOS.
The updated version includes a change that should improve disk performance.
The Restart option in the Docker menu works.
We no longer call it preview 7, ... because now these builds are created by our CI pipeline and we're much closer to our Intel code base now.
The new preview has the version 3.1.0 (60984) that also can be found in the about window. This helps us to reference which version you're using when you report or discuss a problem.
Come and grab the new preview build, the download link is also in that docs page.  :tada:

Hey Apple M1 users,
we have a new preview ready for you.

Thanks for the update! As the preview builds don't auto-update, can we rely on comments here when new releases are available?

The updated version includes a change that should improve disk performance.

The biggest problem I've had with preview 7 was the disk performance was poor, especially for MariaDB, which caused tests for my codebase to take three times as long as with a non-ARM64 Mac. With preview 7, I resorted to storing the database files on a tmpfs volume which helped massively. I hoped this update would help with this, but I do not see any noticeable difference with version 3.1.0 (60984).
To quantify this better, I tried to run some benchmarking with fio using the configuration from this Percona blog post since that seemed relevant for MySQL/MariaDB. The tests were run with size=100m to keep the time necessary to do this down. All tests were run inside an ubuntu:latest container with fio installed via apt-get.

Test scenario
ibd_sync_read
ibd_async_write
ib_log_sync_write

No volume
90 IOPS / 1.41MiB/s
90 IOPS / 1.41MiB/s
178 IOPS / 1.39MiB/s

Volume
87 IOPS / 1.41MiB/s
84 IOPS / 1.33MiB/s
167 IOPS / 1.31MiB/s

Bind mount
1188 IOPS / 18.6MiB/s
1778 IOPS / 27.8MiB/s
1947 IOPS / 15.2MiB/s

The bind mount testing was done using gRPC FUSE. I tried with osxfs, which showed roughly double the throughput for the ib_log_sync_write test, while the other tests failed with osxfs.
I also tried to use the :delegated option, but it didn't make any noticeable difference.
Running the tests directly in macOS and on a tmpfs volume were both much, much quicker but I left them out since it's not too relevant here.
I was surprised to see the bind mount's performance being so much better than the other options, as I expected that to be slowest.
Do you have any indication for where the bottleneck would be for disk IO? It would be interesting to try and run similar tests inside the VM that Docker daemon is running on to see if the problem is with Hypervisor.framework or higher up the stack.

@Tenzer I do agree with you, in fact, its much faster but i think that was also expected but since Hypervisor framework got some adjustments for ARM now it will probably slow docker team due to the fact they have to support also this new arch

We have seen some situations in which disk performance is worse on the virtualization framework than on the old hypervisor framework, and we are talking to Apple about it.

@StefanScherer That is perfectly normal to happen, they are probably still adapting the kit to most of the apps that were relying on intel based. Is there anything new from Apple regarding hypervisor or it's still under prep talk?

Nothing concrete yet.

@Tenzer I had the same issue. My container response felt so slow on my M1.
I'll try with tmpfs. Also I'll try the new preview And I'll comment the results here.

Docker on M1 can run any linux/arm64 image out of the box, and any Intel image with emulation if you add --platform linux/amd64 to the command line.
EDIT: if someone can tell me how to specify that flag from a docker-compose.yml file, I'd be very grateful.

putting platform: linux/x86_64 in the docker-compose.yml did the trick for me.

can you try to start bitnami/apache on apple silicon?
`
version: "3.8"
services:
apache:
image: bitnami/apache
platform: linux/x86_64`

Hi @jan-runkel-zeitgleich ,
thanks for your input, but the platform flag is not in the 3.8 docker compose specification.
This is why we have to pass it through the command line.

Hi @jan-runkel-zeitgleich ,
thanks for your input, but the platform flag is not in the 3.8 docker compose specification.
This is why we have to pass it through the command line.

Is this the correct way to start a x86 image on Apple Silicon?
docker run --platform linux/x86_64 bitnami/apache:latest

or this?
docker run --platform linux/amd64 bitnami/apache:latest

Or is there another Way to start this image?

try with linux/arm64 as it's the way it works for me

try with linux/arm64 as it's the way it works for me
EDIT:
I mean this:
docker run --platform linux/arm64 bitnami/apache:latest

thanks for the fast response. I think I forgot something
I now get the following message with your docker run command:
docker: Error response from daemon: image with reference bitnami/apache:latest was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64.

I install today the Apple Silicon preview 7
i also install rosetta2.
Is there another Step required to use the x86 emulation?
softwareupdate --install-rosetta

@jan-runkel-zeitgleich  @DavidGarciaCat  please don't use this ticket to report bugs or support questions; use github.com/docker/for-mac/issues for that (or the "dev-preview-program" slack channel if you're on that list)

You're right.
Unfortunately I don't have access to the Slack channel yet.
This ticket describes that with the flag "platform: linux / x86_64" Intel images should run. But that doesn't seem to work.

This ticket describes that with the flag "platform: linux / x86_64" Intel images should run. But that doesn't seem to work.

The --platform flag works if the image is a multi-arch image (which is the case for all official images, but may not be the case for other images). The bitnami/apache image is not a multi-arch image, and only supports linux/amd64 (x86); https://hub.docker.com/r/bitnami/apache/tags?page=1&ordering=last_updated

When you specify --platform, docker will only pull the image if it finds a match (which, in this case, it doesn't).
As a workaround you can try pulling it without --platform, which (in case of a non-multi-arch image) will make docker "ignore" the platform, and just pull "whatever it found".
But, it would still be an x86 image that you run on an arm platform, which means it will try to run it using qemu emulation, which should be considered a "best effort" and may work (but no guarantee, as there's still many bugs/known issues in qemu).
We will continue looking to improve the emulation, and are also in talk with 🍏, but it will remain a "best effort", and mostly to help the transition to ARM becoming more mainstream (both on hosting platforms, and in images).
Because of the above, the recommendation is to run images that match the architecture.
I see you opened https://github.com/bitnami/bitnami-docker-apache/issues/104, which is probably best for that

Hello,
Just aiming to report a potential bug:
When I download and install the Docker Preview on my M1, it seems to run. If I open the Docker Desktop Preferences window and set Docker not to start when booting up my laptop, then I am unable to use it again, and I need to remove it and install it again.
The error message I get is that my M1 is not compatible to use Intel software, even when I already used it and Rosetta is installed.
Maybe this is something to be reviewed and addressed in an upcoming update?
Cheers,

hi everybody, anybody has a solution to inotify issue, I have RC3 Docker Desktop but I don't have some fix o a temporary fix, can you help me, anybody?

When I download and install the Docker Preview on my M1, it seems to run. If I open the Docker Desktop Preferences window and set Docker not to start when booting up my laptop, then I am unable to use it again, and I need to remove it and install it again.

It does seem that if I shut down Docker Desktop, it won't start again unless I reboot.

I frequently see the same issue, especially after wake from sleep. Going into Activity Monitor and quitting the Docker process(es) lets me restart. Should save you the reboot.

As this is now shipped 🎉 https://www.docker.com/blog/released-docker-desktop-for-mac-apple-silicon/
I am closing this item. If you have issues please raise them on https://github.com/docker/for-mac/issues

@nebuk89 Congratulations on the release! Is there any place where we can track the status of getting rid of the Rosetta dependency? I searched the issue tracker where you linked but couldn't find anything. I've also only ever seen references to "some upstream binaries" that are still x86, but never been able to find any more information on which upstream binaries, or if anyone is actively working on it...
Thanks!

@LinusU I don't think we have a public ticket to track, but it's definitely on our list of internal tracked items.
You can read about changes for every Docker Desktop release in the release notes https://docs.docker.com/docker-for-mac/release-notes/ . When we finally get rid of requiring Rosetta it will be shown there, and also the system requirements in our docs https://docs.docker.com/docker-for-mac/install/#system-requirements will be updated.
So, just keep your Docker Desktop installation up to date and follow announcements.
Technically our list is down to a few components, and we're aware of version bumps in several components we use that now have native Apple silicon support like Kubernetes, Docker Engine, Node.js, ...
And before you ask, I don't have an ETA to share 😅

@StefanScherer thanks for the quick reply, I'll keep watching the release notes then 👍

So, just keep your Docker Desktop installation up to date

(my Docker crashes on startup because of missing Rosetta, so I can't run the updater 😄)
b.t.w. the "Known issues" section doesn't mention that it requires Rosetta anymore (I think it did during the technical preview), which initially led me to believe that the non-preview release didn't require it anymore. I managed to install it, but then Docker crashes on startup.
No big deal though, since I guess that I will just be able to download and run the latest installer as soon as the dependency on Rosetta is dropped 🚀

b.t.w. the "Known issues" section doesn't mention that it requires Rosetta anymore (I think it did during the technical preview), which initially led me to believe that the non-preview release didn't require it anymore. I managed to install it, but then Docker crashes on startup.

https://docs.docker.com/docker-for-mac/apple-silicon/ it is listed as a system requirement in the installation docs.


Add ability to skip the same version downloading with php rr binary downloader

Problem:
I want to get full control of the version of rr with composer.json package manager.
But it has one little problem when i add it to post install/update composer scripts
    "scripts": {
        "update-scripts": [
            "./vendor/bin/rr get -l ./bin",
            "@auto-scripts"
        ],
        "auto-scripts": {
            "cache:clear": "symfony-cmd"
        },
        "post-install-cmd": [
            "@update-scripts"
        ],
        "post-update-cmd": [
            "@update-scripts"
        ]
    },

Proposal:
it's re-download the same version of the go binary each time I do composer install/update.
I want to install rr binary deps with modern way as composer like deps with cache and hash checking. But it least we can do an ability to skip the same version downloading to don't do complex solution to download single bin deps file :). I did it with pull request #178
I add php logic to skip the same version downloading and remove shell colorize to make version parse simpler and reliable.
FIO: also I tried to add version command but stack with cobra.OnInitialize(... logic that init all container service bus services and gets an error:
Error: [http]: key file 'server.key' does not exists

and stop this solution direction.

I remembered about windows compatibility :) and moved solution from shell awk to Perl based regex.

Thank you, the proposal looks good!

Are you OK to wait till we will get more features for the next release or this is something which is currently pressing?

It's ok to wait. Thanks you for the merging it to the master.


Add template to test sampling sentences script

Script that generates sample sentences currently accepts intent. Since intents can have lot's of variations specifying template to generate sentences could be more appropriate, for example
python3 -m script.intentfest sample --language en --template "turn [on] [the] light[s] [on]"

I don't quite understand what you mean, but the purpose of the tests is to test the sentences, which contain flexible templates.
Please clarify if this is not what you meant :)

Is this what you mean?
python3 -m script.intentfest sample_template "turn [on] [the] light[s] [on]"

That can't generate sentences with expansion rules. For example this sentence template:
"  {cover_classes:device_class}"

You can add lists, ranges, and expansion rules as well:
python3 -m script.intentfest sample_template 'set color to <color> and brightness to {brightness}' --values color red green --range brightness 1 2 --rule color '[the] {color}'

From here


CLI: Handle dependent options in yargs handler

Is your feature request related to a problem? Please describe.
Right now, we are using a confusing solution to propagate default values for dependent Options, involving parsing yargs args in a non-standard way.
See https://github.com/ChainSafe/lodestar/blob/master/packages/lodestar-cli/src/util/parseArgs.ts
See https://github.com/ChainSafe/lodestar/blob/master/packages/lodestar-cli/src/util/mergeOptions.ts
https://github.com/ChainSafe/lodestar/blob/master/packages/lodestar-cli/src/cmds/beacon/options/index.ts#L19
Describe the solution you'd like
Instead of continuously re-parsing args in the "build" stage, parse at the "handler" stage.
Remove the "default" from the options that are dependent on other options, so that arg values can be null-checked to determine if they've been set or not.
"Downstream" nullish args can be set based on "upstream" args in a utility function that resolves the arg heirarchy.
The one wrinkle to this is https://github.com/ChainSafe/lodestar/blob/master/packages/lodestar-cli/src/cmds/beacon/cmds/run/index.ts#L19
in beacon run, we're currently using the args.config value in the builder, before the handler runs. So in that case, we will likely still need to pre-parse the args to determine the correct args.config.
Describe alternatives you've considered
Keep the solution we have now, more documentation on the nonstandard method we're using
Additional context
See https://github.com/ChainSafe/lodestar/pull/1097 implementing the described solution for the validator CLI

Resolved in #1210


Improve round-trip

Fixes #2. Fixes #3.

Test more scenarios with generative tests via test.check.
Fixes diff and patch when maps have nil or false as keys.
Fixes support for sequences that change from one data structure to another.
Fixes support for sequences which become empty.
Add deps.edn for tools.deps git coordinates.
Update dependencies and build targets.
Proposes changing library to version 0.4.0.
Support replacing a record with another record.

My company has stored many months of diffs (version 0.3.3).  I ran millions of them through to make sure the new 0.4.0 patch function could process the 0.3.3 diffs without exception.


Change log level for add/removal of hosts

Fixes https://github.com/dapr/dapr/issues/1391
These log messages should have been Debug level from the start.

Thanks for the removal delay suggestion @LMWF


made the guitars be able to be worn on suitstorage

About the PR

made the guitars be able to be worn on suitstorage
Why / Balance

i wanna carry a guitar and a backpack
Technical details

Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

:cl: Boaz1111

add: Guitars can now be worn in the suit storage slot

can you send a picture with how it looks

can you send a picture with how it looks

it's exactly the same sprite you goober just for suit storage, not just backpack

Where banjo

Banjo can't be worn on the backpack slot


Release 2.1.0

Questions
Answers

Description?
Release 2.1.0

Type?
improvement

Hello @PierreRambaud ,
I tested the release with develop and <IP_ADDRESS> and I didn't detect any regression related => PR is QA approved.
I detected the following bugs (with and without PR):
https://github.com/PrestaShop/PrestaShop/issues/27155
https://github.com/PrestaShop/PrestaShop/issues/27154
https://github.com/PrestaShop/PrestaShop/issues/27153
Thanks !

Thank you @marwachelly


config: only set tls_prefer_server_cipher_suites for Vault < 1.9.0

see: https://www.vaultproject.io/docs/v1.9.x/upgrading/upgrade-to-1.9.x#tls-cipher-suites-changes

@bbaassssiiee WDYT?

@bbaassssiiee Any chance of getting this merged or is https://github.com/ansible-community/ansible-vault/pull/311/files better? I kind of prefer the other PR as 1.9.0 is old.


[ERROR] VSCode Extension Creation showing vscode.Uri.joinPath error

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.71.2
OS Version: Windows 10 Home latest build

Steps to Reproduce:

Follow the official guide on Extension Creation
Getting error with vscode.Uri.joinPath

Tried to solve it by creating an interface for vscode.Uri and adding the joinPath method, but then I get more errors.
Searched the issues, and didn't find any solution, before someone chimes in with the mandatory "It's a dup!".
Thank you in advance to the kind souls who bring me some light on the matter.

Solved?
(vscode.Uri as any).joinPath()


w2grid online editing in 1.5rc1

Not working insert (ctrl + v) the cell in firefox with online editing, Chrome work fine.
At the beginning of the editing "Save" button is inactive in all browser.

Can you create jsFiddle with the problem. I did not understand the issue with "Save" button

For example: http://jsfiddle.net/yuy2bh5b/
At the beginning of the editing "Save" button is disabled, even when I changed the text. To button becomes active, I need to go to the next line, or click on the "Save" button twice (first click makes it active). I would like to see this button active at the beginning of the editing.

I think this issue consists of actually 2 issues:

BUG: CTRL+V not working in editable cell in Firefox

Feature Request: Enable the "Save" already during editing, not when edting is finished.

Though I guess (2) could be done during http://w2ui.com/web/docs/1.5/w2grid.onEditField - personally, I do not see the need to change the default behavior or make this an option.


Fix voice connect

Code
fut = asyncio.Future()
async def client_connected(reader, writer):
    fut.set_result(reader)
    await evnt.send('made reader')
a = await asyncio.start_server(client_connected, '<IP_ADDRESS>', 8080)
_, writer = await asyncio.open_connection('<IP_ADDRESS>', 8080)
asyncio.get_event_loop().create_task(a.serve_forever())
voice_connection = await client.channels.get(772872533732753443).connect()
voice_connection.player = AudioPlayer(voice_connection, get_packets_encoded(await fut, voice_connection.loop))
voice_connection.receiver = AudioReceiver(voice_connection)
await asyncio.sleep(1)
await voice_connection.ws.send_speaking()
async def received(data):
    await writer.write(data)
voice_connection.receiver.voice_packet_received = received
await voice_connection.player.start(wait=False)

Error
Traceback (most recent call last):
  File "C:\Users\name\snakecord\snakecord_test_bot\bot.py", line 65, in listen
    voice_connection = await client.channels.get(772872533732753443).connect()
  File "C:\Users\name\snakecord\snakecord\snakecord\channel.py", line 92, in connect
    await shard.update_voice_state(self.guild.id, self.id)
AttributeError: 'Shard' object has no attribute 'update_voice_state'

from snakecord.audio.receive import AudioReceiver
from snakecord.audio.play import AudioPlayer
from snakecord.audio.packets import get_packets_encoded
fut = asyncio.Future()
async def client_connected(reader, writer):
    fut.set_result(reader)
    await message.channel.send('made reader')
a = await asyncio.start_server(client_connected, '<IP_ADDRESS>', 8080)
_, writer = await asyncio.open_connection('<IP_ADDRESS>', 8080)
asyncio.get_event_loop().create_task(a.serve_forever())
voice_connection = await client.channels.get(755487055794012236).connect()
voice_connection.player = AudioPlayer(voice_connection, get_packets_encoded(await fut, voice_connection.loop))
voice_connection.receiver = AudioReceiver(voice_connection)
await asyncio.sleep(1)
voice_connection.ws.set_speaking_state()
async def received(data):
    await writer.write(data)
voice_connection.receiver.voice_packet_received = received
await voice_connection.player.start(wait=False)

Thank you.


Unhelpful error messages with env-vars that don't set all fields of a config struct

Problem
I have been using the gitoxide integration for a while, via setting env-vars so it doesn't impact running the stable compiler:
CARGO_UNSTABLE_GITOXIDE_CHECKOUT=true
CARGO_UNSTABLE_GITOXIDE_FETCH=true
CARGO_UNSTABLE_GITOXIDE_INTERNAL_USE_GIT2=false
CARGO_UNSTABLE_GITOXIDE_SHALLOW_DEPS=true
CARGO_UNSTABLE_GITOXIDE_SHALLOW_INDEX=true

After updating to a version that includes https://github.com/rust-lang/cargo/pull/13592 any usage of cargo starts failing with
> cargo test -- --ignored zero_byte
error: missing field `list_files`

which makes no mention of where this field is missing
Steps
> CARGO_UNSTABLE_GITOXIDE_FETCH=true cargo build
error: missing field `list_files`

Possible Solution(s)
No response
Notes
https://github.com/rust-lang/cargo/pull/13687 will likely fix this specific issue by making the fields of this struct default, but the general issue of the error message not having enough context will remain.
Version
cargo 1.79.0-nightly (a59aba136 2024-03-28)
release: 1.79.0-nightly
commit-hash: a59aba136aab5510c16b0750a36cbd9916f91796
commit-date: 2024-03-28
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: NixOS 23.11.0 [64-bit]

Thanks for the report. I guess this is not a general issue but -Zgit/-Zgitoxide specific one?

Those do appear to be the only structs in the unstable config. I'm not sure where the general config-env-var parsing happens so I'm not certain if they're the only ones that are affected.

Found a way to trigger it with a stable config too:
> CARGO_TERM_PROGRESS_WIDTH=2 cargo check
error: missing field `when`

FYI,  I have searched the code base, and have not found the place that triggers missing field, guess that this is related to the parsing process of the third-party library serde?

Yeah, the env-vars are read as part of a deserializer that merges the config files, env-vars and cli flags into one, then the error is produced by the Deserialize impl from ProgressConfig, you also get the same unhelpful error using the cli flag or config file:
> cargo check --config 'term.progress.width=2'
error: missing field `when`
> mkdir -p .cargo && echo 'term.progress.width=2' > .cargo/config.toml
> cargo check
error: missing field `when`

What would be most useful is more context on the error: what's the full config key that's being parsed and failed, and where are the other fields coming from (they can even come from multiple locations:
> CARGO_TERM_PROGRESS_WIDTH=2 cargo check --config 'term.progress.when="always"'
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s

Whats interesting about the config case is that its term.progress.when.  Serde only reports when.  We only know that the caller looked up term.  I'm unsure if we can connect the dots to report term.progress.when without specializing the error reporting to each individual struct which is just playing whack-a-mole (like in #13687).

See #13694 to see what that looks like

I'm unsure if we can connect the dots to report term.progress.when

It looks like this is being tracked in the Deserializer as it enters into parsing each field of the structs:
https://github.com/rust-lang/cargo/blob/18181c69c4bb569811bcc01ef7b71fceeebfbec3/src/cargo/util/context/de.rs#L315
it feels like it should be possible to attach this context somewhere at this level when the error first passes back to the deserializer.

Good point.  I do something similar in toml_edit, see https://github.com/toml-rs/toml/blob/48f968b449d64a3b7bcefab37c3f08438ba857ec/crates/toml_edit/src/de/table.rs#L171
However, I hit my time box I set aside for this as I need to be wrapping up some existing tasks and putting most of my focus to my 2024 Edition work.


Ability to install Slidev globally

First of all, great project. For further, I hope it can be used like this:
npm i -g @slidev/cli
vim index.md
slidev index.md
# Then, start to performance.

Didn't know if this was already done, but currently, if I use @slidev/cli like this, it will report lack of dependencies.
In this way, it can make user more focus on the content (only a single markdown file) than now (vscode, node_modules, package.json, etc).
Thanks.

I also want to second this: a way to use Slidev without needing a 500MB standalone project for each presentation.
I am a teacher, currently using Marp, and I have hundreds of presentations. While it's possible to have all the presentations for a course as one single slide, it's not practical (~200-400 slides per presentation), and even that would still require dozens of very heavy projects containing redundant slidev dependencies.
Having a way to generate a slides.md presentation without needing to add anyother file or node_modules next to it would be great!

This was tough 😅

But hey! We get it supported in v0.14.0 🎉


Merge Online Application Development and Developer Portal documentation

Audience: tech, dev
Area: Online application development
Title: Merge Online Application Development and Developer Portal documentation
Description: Merge the online application documentation with the developer portal documentation.
https://docs.superoffice.com/apps/index.html
https://docs.superoffice.com/developer-portal/index.html
Organize these in such a way that consumers/readers easily/organically understand how to create/work with online applications, tenants, validations, certifications, etc.
For App Store, installed apps - add info about this page and "Report a problem"

Links between the two sections
developer-portal links to apps 76 times in 21 files
apps links to developer-portal 27 times in 16 files
Incoming links
Other pages links to DP 13 times in 9 files and to apps 67 times in 41 files
Many of these are in index pages and go to terminology, tutorial, or getting access to SOD/DP.

New top folder name
While there are more links to apps, I think developer-portal is a more descriptive name. After introducing DP, we've gradually moved or deleted content from apps. DP has currently the most attention. Since we have many api folders, you have to spell out apps completely for it to be unique - small productivity gain from using DP instead.
Subfolders

Move the requirements and tutorial folders "as is" and keep their naming in the new location.
Move in getting-started and add apps/activate/helper-application.md to it.
Create a new folder called overview or terminology in DP and place all concepts from both sources there.
Move checklists and apps/tenant-status/status-page.md to reference.
Move the 3 Watchcom pages + get/revoke consent to security.
Move under but not including apps/publish to app-store.
Move remaining how-tos scattered in apps to howto.
Merge the index.yml and toc.yml and place apps/best-practices.md at top level
Images and includes follow their parent Markdown files.

Skeleton

developer-portal

app-store
create-app
getting-started
howto
reference
requirements
security
terminology (or overview)
tutorials

toc-idea.md
Also discussed this today's meeting.


Enhancement in texts and buttons

On the homepage, lots of text and buttons are not correctly colored when hovering on them in both dark mode and light mode.
If you want to make it correct assign me this task.
buttons and texts are -
search button
sign up button
scroll up button
navbar texts
these are some elements that I noticed

@devjain2309 already given to someone


Incorrect parcing is happening for my m3u.

Please first read the documentation. Problems affecting the client, e.g. Plex or Emby should be reported there in the forum.
Describe the bug

All channel names appear as AAA
My CUID is ignored and the channel starts from 1000

Server (please complete the following information):

OS [Linux - Unraid - docker]
Arch [Intel 64 Bit]
xTeVe Version and Build [2.1.1 Build: 0112]

To Reproduce
Steps to reproduce the behavior:

Go to 'XMLTV - NEW - TXMLTV File - Save'
This is my m3u file

#EXTM3U
#EXTINF:-1 CUID="13.1" tvg-id="" tvg-name="AAA" tvg-logo="http://mylocalhost/logo/13.1.png"
http://mylocalhost:5004/auto/ch789000000-1
#EXTINF:-1 CUID="13.2" tvg-id="" tvg-name="BBB" tvg-logo="http://mylocalhost/logo/13.2.png"
http://mylocalhost:5004/auto/ch789000000-2
#EXTINF:-1 CUID="7.1" tvg-id="" tvg-name="CCC" tvg-logo="http://mylocalhost/logo/7.1.png"
http://mylocalhost:5004/auto/ch783000000-2

Expected behavior
My CUID is displayed as channel, and tvg-name is displayed as channel name.
Screenshots

Desktop (please complete the following information):

OS: [Windows]
Browser [chrome]
Version [78.0.3904.108]

Additional context
I tried https://github.com/xteve-project/xTeVe/blob/master/src/internal/m3u-parser/test_list_1.m3u but it didn't help.

Your M3U playlist is incorrectly formatted.
It should look like this:

#EXTM3U
#EXTINF:-1 CUID="13.1" tvg-id="" tvg-name="AAA" tvg-logo="http://mylocalhost/logo/13.1.png", AAA
http://mylocalhost:5004/auto/ch789000000-1

#EXTINF:-1 CUID="13.2" tvg-id="" tvg-name="BBB" tvg-logo="http://mylocalhost/logo/13.2.png", BBB
http://mylocalhost:5004/auto/ch789000000-2

Every new channel got the first free channel number from 1000. CUID is used as unique stream ID, not as the channel number.
Channel numbers are ignored because they can appear twice when using multiple playlists.

Your M3U playlist is incorrectly formatted.
It should look like this:

#EXTM3U
#EXTINF:-1 CUID="13.1" tvg-id="" tvg-name="AAA" tvg-logo="http://mylocalhost/logo/13.1.png", AAA
http://mylocalhost:5004/auto/ch789000000-1

#EXTINF:-1 CUID="13.2" tvg-id="" tvg-name="BBB" tvg-logo="http://mylocalhost/logo/13.2.png", BBB
http://mylocalhost:5004/auto/ch789000000-2

Every new channel got the first free channel number from 1000. CUID is used as unique stream ID, not as the channel number.
Channel numbers are ignored because they can appear twice when using multiple playlists.

Oh, I see. Thank you for Xteve and you.


Variable IOS_USE_PRECOMPILED_FIRESTORE_POD does not work on 14.2.1-cli

Bug report

CHECKLIST

[x] I have read the issue reporting guidelines
[x] I confirm this is a suspected bug or issue that will affect other users
[x] I have reproduced the issue using the example project or provided the necessary information to reproduce the issue.
[x] I have read the documentation thoroughly and it does not help solve my issue.
[x] I have checked that no similar issues (open or closed) already exist.

Current behavior:
Using the 14.2.1-cli build, the pre-compiled Firestore pod is always used regardless of the variable IOS_USE_PRECOMPILED_FIRESTORE_POD.
The non-cli 14.2.1 version works fine.
Comparing plugin.xml between 14.2.1-cli and 14.2.1 reveals a number of differences including:
14.2.1-cli:
<pod name="FirebaseFirestore" git="https://github.com/invertase/firestore-ios-sdk-frameworks.git" tag="9.1.0"/>
14.2.1
<pod name="Firebase/Firestore" spec="9.1.0"/>
Expected behavior:
The variable IOS_USE_PRECOMPILED_FIRESTORE_POD should control whether the pre-compiled Firestore pod is used.
Steps to reproduce:
Add 14.2.1-cli into a project without specifying the variable (defaults to false).
Check the PodFile - it states:
pod 'FirebaseFirestore', :tag => '9.1.0', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git'
Environment information

Cordova CLI version

11.0.0

Cordova platform version

ios 6.2.0

Dev machine OS and version, e.g.

OSX

Monterey 12.5.1

Node JS version

16.17.0

Hi @dpa99c, it seems the merge on plugin.xml fails.
The following line must be updated to point directly to the official pod version 9.1.0 .
Thanks !

@TiBz0u Due to this issue with the cli version, we're using the non-cli version with the official pod (i.e. not pre-compiled). Consequently, we haven't experienced an issue with instant crashing on devices.

Can confirm it doesn't work. Tried it as a fix for the error of #735. I wrote a cordova hook, to overwrite the Podfile. Similar to this one. Now it works.
However, would be great to see it fixed :)

I wrote a cordova hook to overwrite the Podfile. Similar to https://github.com/dpa99c/cordova-plugin-firebasex/issues/735#issuecomment-1180019463. Now it works.

@RobYed can you share what you added in that after_prepare hook?

@rex-iotum sure! It's very basic with a hard-coded version number, but might help:
module.exports = (context) => {
  // Make sure ios platform is part of build
  if (!context.opts.platforms.includes('ios')) {
    return;
  }

  const iosPlatformRoot = path.join(context.opts.projectRoot, 'platforms/ios');
  const podfilePath = path.join(iosPlatformRoot, 'Podfile');

  if (!fs.existsSync(podfilePath)) {
    console.log(
        `'${podfilePath}' does not exist. FirebaseFirestore fix skipped.`
    );
    return;
  }

  const preCompiledVersionString =
      "pod 'FirebaseFirestore', :tag => '9.1.0', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git'";

  let podfileContent = fs.readFileSync(podfilePath, 'utf-8');

  if (podfileContent.includes(preCompiledVersionString)) {
    podfileContent = podfileContent.replace(
        preCompiledVersionString,
        "pod 'FirebaseFirestore', '9.1.0'"
    );

    fs.writeFileSync(podfilePath, podfileContent, 'utf-8');

    console.log('Installing non pre-compiled FirebaseFirestore...');

    return execa('pod', ['install', '--verbose'], {
      cwd: iosPlatformRoot,
    });
  } else {
    console.log('Could not set non pre-compiled FirebaseFirestore');
  }
};

Hi @RobYed.
Since release 14.2.0, the pre-compiled version is not the default anymore. As explained upper, there is a merge issue.
If you want the same behavior on the cli, instead of hook, juste adapt the plugin.xml to the right pod (as here)...
In all case, you'll need a fork before the fixing release. Or use the current_cli branch with has already the PR you asked
https://github.com/dpa99c/cordova-plugin-firebasex/pull/757

Should be fixed in<EMAIL_ADDRESS>which has just been released to npm


Getting Secrets securely into Kubernetes

As a Customers
I'd like to have secret management
Which I can use for my own apps provided centrally by Giant Swarm.
We need to invest time with customers to get a better general understanding of what our customers need and want to build this capability.

https://github.com/giantswarm/roadmap/issues/1431

cc @piontec as the use case towards which the ESO issue #1431 be a solution to

team did a spike and defined an ESO implementation plan (public roadmap ticket here)

closed in favor of https://github.com/giantswarm/roadmap/issues/1749


Fix typo in readme

Fix some word typos and symbol typos.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks!


Proof of concept that uses x-forwarded headers

Please check the following:

Make sure you are targeting the main branch, pull requests on release branches are only allowed for backports.
Make sure you have read contributing guidelines: https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md .
Describe what your pull request does and which issue you're targeting (if any).
It is recommended to enable "Allow edits by maintainers", so maintainers can help more easily.
Your input here will be included in the commit message when this PR has been merged. If you don't want some content to be included, please separate them with a line like ---.
Delete all these tips before posting.

See Issue https://github.com/go-gitea/gitea/issues/29591


[Bug candidate] pip sometimes includes debug messages on stdout

This is an abbreviated copy of #115 and #116, since those have been filled up with additional debugging.
Summary: In rare cases (currently N=1), we fail to collect environmental dependencies from PipSource. PipSource uses pip-api internally, which boils down to pip list --format=json.
What seems to happen is that the pip list --format=json command doesn't emit just JSON. Instead, it also emits a trailing log message that looks like this:
Given no hashes to check 181 links for project 'pip': discarding no candidates

According to pip's source code, that message is produced by a call to log.debug, which should be going to stderr instead of stdout. pip-api only uses stdout from pip subprocesses, so this is a strong indicator that the two streams are being mixed and/or confused somewhere, potentially with a logging override. The original reporter also traced the process and confirmed that the log was produced on stdout.
The original reporter found this on Python 3.9, pip version 20.3.3. I was unable to reproduce it locally, and they were also unable to reliably reproduce it locally.

You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command.
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/pip_audit/_dependency_source/pip.py", line 72, in collect
    for (_, dist) in pip_api.installed_distributions(
  File "/usr/local/lib/python3.8/site-packages/pip_api/_installed_distributions.py", line 94, in installed_distributions
    return _new_installed_distributions(local, paths)
  File "/usr/local/lib/python3.8/site-packages/pip_api/_installed_distributions.py", line 75, in _new_installed_distributions
    for raw_dist in json.loads(result):
  File "/usr/local/lib/python3.8/json/__init__.py", line 357, in loads
    return _default_decoder.decode(s)
  File "/usr/local/lib/python3.8/json/decoder.py", line 340, in decode
    raise JSONDecodeError("Extra data", s, end)
json.decoder.JSONDecodeError: Extra data: line 2 column 1 (char 3190)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/bin/pip-audit", line 8, in <module>
    sys.exit(audit())
  File "/usr/local/lib/python3.8/site-packages/pip_audit/_cli.py", line 263, in audit
    for (spec, vulns) in auditor.audit(source):
  File "/usr/local/lib/python3.8/site-packages/pip_audit/_audit.py", line 60, in audit
    yield from self._service.query_all(specs)
  File "/usr/local/lib/python3.8/site-packages/pip_audit/_service/interface.py", line 115, in query_all
    for spec in specs:
  File "/usr/local/lib/python3.8/site-packages/pip_audit/_dependency_source/pip.py", line 91, in collect
    raise PipSourceError("failed to list installed distributions") from e
pip_audit._dependency_source.pip.PipSourceError: failed to list installed distributions

and
docker run --rm -it <test-image-name> pip list --format=json

Produces:
[{"name": "CacheControl", "version": "0.12.10"}, {"name": "certifi", "version": "2021.10.8"}, {"name": "charset-normalizer", "version": "2.0.9"}, {"name": "cyclonedx-python-lib", "version": "0.11.1"}, {"name": "html5lib", "version": "1.1"}, {"name": "idna", "version": "3.3"}, {"name": "lockfile", "version": "0.12.2"}, {"name": "msgpack", "version": "1.0.3"}, {"name": "packageurl-python", "version": "0.9.6"}, {"name": "packaging", "version": "21.3"}, {"name": "pip", "version": "21.1.1"}, {"name": "pip-api", "version": "0.0.25"}, {"name": "pip-audit", "version": "1.1.0"}, {"name": "progress", "version": "1.6"}, {"name": "pyparsing", "version": "3.0.6"}, {"name": "rapid-client", "version": "0.0.0"}, {"name": "requests", "version": "2.26.0"}, {"name": "requirements-parser", "version": "0.2.0"}, {"name": "resolvelib", "version": "0.8.1"}, {"name": "setuptools", "version": "50.3.2"}, {"name": "six", "version": "1.16.0"}, {"name": "toml", "version": "0.10.2"}, {"name": "types-setuptools", "version": "57.4.4"}, {"name": "types-toml", "version": "0.10.1"}, {"name": "urllib3", "version": "1.26.7"}, {"name": "webencodings", "version": "0.5.1"}, {"name": "wheel", "version": "0.37.0"}]
WARNING: You are using pip version 21.1.1; however, version 21.3.1 is available.
You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command.

I have observed that doing pip install without specifying --disable-pip-version-check corrects the problem

Perhaps you could make use of --disable-pip-version-check within the pip list call in pip-api to get around it?

@westonsteimel thanks a ton for the in-depth debugging! I'll look into that workaround.

Yeah, so here's the message in question:
https://github.com/pypa/pip/blob/bbc7021cde307676a71e7a89e88a6fc20b8e2c26/src/pip/_internal/self_outdated_check.py#L170-L177
It's using logger.warning, so the underlying question of "why is it on stdout?" still isn't resolved. But I'll use your repro setup and, if it clears the problem for me too, we'll go ahead and fix it blindly 🙂

Okay, I'm also able to reliably reproduce the bug. If I do this:
docker run --rm -it pip-audit-bug pip list --format=json 2>/dev/null | less

I can see both the errant log and some terminal escapes are present on stdout:

I haven't fully dug through pip's logging code yet, but this looks like a bug. But even so we'll need a fix on our side for older pips. Working on one now.

Upstream fix: https://github.com/di/pip-api/pull/114

Will cut a release for this once there's a new pip-api release 🙂

Done: https://pypi.org/project/pip-api/0.0.26/

Fixed with #196!

I can confirm that this fixes the problem for me. Thank you!

Fantastic, thanks for confirming!


Add cancelRoll attribute for the camera lookAt method

The cancelRoll attribute wasn't taken in account into the Camera.lookAt method when a tween was used.

 All committers have signed the CLA.


Initial scaffolding for multiple language support

Need to add + verify Python import support, just build new machinery for this or is the C++-based import lookup usable?

Need to test enum scenario that doesn't depend on auto, need to start generating struct scaffolding and figuring out imports

Next: https://github.com/vkottler/runtimepy/pull/261#issuecomment-2295123593 (prepare for struct generation, we need to provide some endianness when creating the underlying array)


Create wiki for how to get Eagle Pro

Now that I have the info on how to download professional eagle, I need to create a wiki page for that club members now and it in future can get a free professional version of Eagle Cad

Created and placed on the wiki. Sorry for all the spam!

You do realise anyone on the internet can download your eagle license right?

Thanks for letting us know @thinkl33t , I changed the privacy settings back to group only.


where clause requiring an operand

I wouldn't exactly define this as an issue with doctrine, but it's giving me some problems in my project.
I can't find a way to force the querybuilder to accept a where clause as simply being true, without having to set it to '= true'.
In SQL you can simply make a statement that goes like:
SELECT * FROM users WHERE email_validated;

Is there any way that this is possible to achieve with the querybuilder? It'd look something like:
$this->createQueryBuilder('users')->where('users.email_validated');

Since it expects an operand, it throws the following exception:
[Syntax Error] line 0, col -1: Error: Expected =, <, <=, <>, >, >=, !=, got end of string.

I hope I'm making myself clear, otherwise I'd be happy to explain further, thanks in advance.

I can't find a way to force the querybuilder to accept a where clause as simply being true, without having to set it to '= true'.

It's not possible, but why do you want to do that?
This is how DQL grammar looks like (look at SimpleConditionalExpression).
QueryBuilder does not know about field types (because it's not its responsibility) to magically add conditional, so I see no possibilites of allowing that.
Even if somebody have an idea how to introduce that - for me it brings additional code to maintain for no real gain.

Thanks for the reply @kejwmen!
It was a quite unique case, but I was using a doctrine extension introducing MBRContains to calculate distances between two points.
I therefore had a spatial index on the point column, which is kinda critical if I want a response lower than 3 seconds. MBRContains doesn't use the index if you set it to '= true'. And that's not just in doctrine, it doesn't use the index unless I avoid the '= true' in a native SQL either.
But since this wasn't a common issue, I figured that a CustomSQLWalker  was my best option and it's working just as intended :-)


fix: deprecate pygments related variable to correct typos

Fix #1594
As mentioned in the issue, the code highlighting lib name is "pygments" and not "pygment". I tracked down all occurences of the word "pygment" without "S" and updated it. Deprecation cycle is due to v1.0.
changes:

create a pygments_light_style/pygments_dark_style parameter
make a sanity check at theme option init
change pygments filename

Thanks for rebasing this @Carreau.  Assuming I didn't break anything by editing through GH web UI, this can be merged when CIs are green.


fix remaining references to half_basal_target

fix for https://github.com/openaps/oref0/pull/684#issuecomment-336717935

Thank you, exercise mode now again works as expected. I think this is good to merge.


GD-115: Fix Debug tests gets stuck when using --verbose

What
see https://github.com/MikeSchulze/gdUnit4Net/issues/115 The debugger was on hold because of printing system outs and the process has not start reading stdout and stderr
What

Moved the attach debugger after begin reading stdout and stderr
fixed local nuget config to build against local nuget packages

@van800 can you please check the debug works on rider?
The version is not released yet, you need to check out the master and run the example project and edit the nuget.config inside the project to load the latest package versions.

@MikeSchulze I have tried that, I have double-checked to use locally compiled nugets. However, it doesn't work. I believe it is still a problem on our side.
Last runner error: TestRunner: JetBrains.ReSharper.TestRunner.Adapters.VsTest.Executor Could not attach debugger System.AggregateException: One or more errors occurred. (Specified method is not supported., reason: System.NotSupportedException: Specified method is not supported.
   at JetBrains.Rider.Backend.Features.UnitTesting.RiderUnitTestDebugHost.AttachToProcess(IUnitTestRun run, String remoteMachine, Int32 processId)
   at JetBrains.ReSharper.UnitTestFramework.Execution.Hosting.DebugHostController.AttachToProcess(Int32 processId, IUnitTestRun run, ILogger logger)
   at JetBrains.ReSharper.UnitTestFramework.Execution.Launch.UnitTestLaunch.HostControllerWithLogging.AttachToProcess(Int32 processId, IUnitTestRun run, ILogger logger)
   at JetBrains.ReSharper.UnitTestFramework.Execution.Launch.UnitTestLaunch.HostControllerWithExtensions.AttachToProcess(Int32 processId, IUnitTestRun run, ILogger logger)
   at JetBrains.ReSharper.UnitTestFramework.Execution.TestRunner.DefaultTestRunnerHost.TestExecutionMessageHandler.Execute(AttachToProcessRequest message)
   at JetBrains.ReSharper.UnitTestFramework.Execution.TestRunner.Activation.ServerEndpoint.<>c__DisplayClass7_1.<<TryRegisterAsyncHandler>b__0>d.MoveNext()

@MikeSchulze I have tried that, I have double-checked to use locally compiled nugets. However, it doesn't work. I believe it is still a problem on our side.
Last runner error: TestRunner: JetBrains.ReSharper.TestRunner.Adapters.VsTest.Executor Could not attach debugger System.AggregateException: One or more errors occurred. (Specified method is not supported., reason: System.NotSupportedException: Specified method is not supported.
   at JetBrains.Rider.Backend.Features.UnitTesting.RiderUnitTestDebugHost.AttachToProcess(IUnitTestRun run, String remoteMachine, Int32 processId)
   at JetBrains.ReSharper.UnitTestFramework.Execution.Hosting.DebugHostController.AttachToProcess(Int32 processId, IUnitTestRun run, ILogger logger)
   at JetBrains.ReSharper.UnitTestFramework.Execution.Launch.UnitTestLaunch.HostControllerWithLogging.AttachToProcess(Int32 processId, IUnitTestRun run, ILogger logger)
   at JetBrains.ReSharper.UnitTestFramework.Execution.Launch.UnitTestLaunch.HostControllerWithExtensions.AttachToProcess(Int32 processId, IUnitTestRun run, ILogger logger)
   at JetBrains.ReSharper.UnitTestFramework.Execution.TestRunner.DefaultTestRunnerHost.TestExecutionMessageHandler.Execute(AttachToProcessRequest message)
   at JetBrains.ReSharper.UnitTestFramework.Execution.TestRunner.Activation.ServerEndpoint.<>c__DisplayClass7_1.<<TryRegisterAsyncHandler>b__0>d.MoveNext()

I know the issue of AttachDebuggerToProcess not implemented, that's a JetBrains problem.
For me, it is from interesting that the workaround you proposed is working as before.
Unfortunately, I can't test this myself because I don't have a Rider license.

Ah, I forgot that workaround. I will test tomorrow.

The workaround with while (!Debugger.IsAttached) still works as before.

The workaround with while (!Debugger.IsAttached) still works as before.

thanks for your feedback 👍

@MikeSchulze Regarding a Rider license, we'd be happy to provide one for you. I have wrote to your email stated in the github profile, from my jetbrains address.

@MikeSchulze Regarding a Rider license, we'd be happy to provide one for you. I have wrote to your email stated in the github profile, from my jetbrains address.

Thank you for this message, I have an answer and yes, I am very interested in the license ;)


circleProgress is not a fuction

Hi!
I get this error using WebPack: "circleProgress is not a fuction".
My script.js:
require('jquery-circle-progress/dist/circle-progress');

$("#dial-1").circleProgress({
    value: 23,
    size: 60,
    lineCap: 'round',
    fill: {
      gradient: ["#005bff", "#005bff"]
    },
    thickness: 33
})

jquery loads by webpack.ProvidePlugin:
new webpack.ProvidePlugin({
    $: 'jquery',
    jquery: 'jquery',
    jQuery: 'jquery',
    Mustache: 'mustache',
})

@devope If you can come up with a minimal repo on GitHub which reproduces that error I might be able to help you.

@devope - I'll try to help you.
First of all - use require('jquery-circle-progress') instead of require('jquery-circle-progress/dist/circle-progress'). It's the same right now, but shorter. And someday I may rename dist to lib (e.g.) but require('jquery-circle-progress') will still work correctly.

Another question - could you try to use it without webpack.ProvidePlugin, just with the regular WebPack module loader?

This took me a bit... here's what I had to do to get circleProgress to be recognized in the context of webpacker in a new rails app where I already had jquery loaded via the asset pipeline.
From: app/javascript/packs/application.js
/* eslint no-console:0 */
// This file is automatically compiled by Webpack, along with any other files
// present in this directory. You're encouraged to place your actual application logic in
// a relevant structure within app/javascript and only use these pack files to reference
// that code so it'll be compiled.
//
// To reference this file, add <%= javascript_pack_tag 'application' %> to the appropriate
// layout file, like app/views/layouts/application.html.erb

console.log('Hello World from Webpacker');

import $ from 'jquery';
import 'jquery-circle-progress';

$(document).on('turbolinks:load', function() {
  $('#circle').circleProgress({
    value: 0.75,
    size: 80,
    fill: {
      gradient: ["red", "orange"]
    }
  });
});

You can move this out to a different folder structure as it suits you, but they key is allowing circleProgress to find and have jQuery loaded for it in the right order.

Yes, in my library, there's UMD which does (for NPM environment):
var jQuery = require('jquery');

Probably webpack.ProvidePlugin was conflicting with this mechanism in some way.
@jondkinney - thanks for the investigation. Are you OK now? May I close this ticket? Or is there something that I should do?

I hope I've helped you. I'm closing this ticket, but feel free to reopen.


Occasional test failures at Travis CI

Occasionally there are test failures on travis ci builds. Random builds fail at the ctest -D ExperimentalMemCheck step – with compiler varying from build to build.
After one or two re-runs, the build is ok. No failure locally.
Output on failure:
$ ctest -D ExperimentalMemCheck
   Site: testing-gce-8767ab6f-b1a6-4f55-81d6-fa8f865a2e58
   Build name: Linux-g++-4.7
Memory check project /home/travis/build/offa/seasocks/build
    Start 1: AllTests
1/1 MemCheck #1: AllTests .........................***Failed   21.70 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =  21.70 sec

The following tests FAILED:
	  1 - AllTests (Failed)
-- Processing memory checking output:
Memory checking results:
Errors while running CTest

Examples

https://travis-ci.org/offa/seasocks/jobs/178529492
https://travis-ci.org/offa/seasocks/jobs/188547286
https://travis-ci.org/offa/seasocks/jobs/188547297

As there are no failures at the mainline so far, maybe it's just an issue on my fork? Even though it's exact the same content; even master had failures.

Super weird. I'll take a look; will run under valgrind and the address
sanitiser
On Wed, Jan 4, 2017 at 6:22 AM, offa<EMAIL_ADDRESS>wrote:

As there are no failures at the mainline so far, maybe it's just an issue
on my fork? Even though it's exact the same content; even master had
failures.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mattgodbolt/seasocks/issues/44#issuecomment-270359187,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmsdcDj42axnCP1TmydfkwXvTLpspE8ks5rO48igaJpZM4Lakdy
.

Running locally yields the logfile of:
==13905== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==13905==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13905==    by 0x50E0EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==13905==    by 0x40104E9: call_init.part.0 (dl-init.c:72)
==13905==    by 0x40105FA: call_init (dl-init.c:30)
==13905==    by 0x40105FA: _dl_init (dl-init.c:120)
==13905==    by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==13905==

So I suspect there's something missing from the valgrind suppressions file for the compilers. I'll check in an appropriate file.

I found a specific entry for the leak: https://gcc.gnu.org/ml/gcc-bugs/2015-12/msg00796.html

I have a suppression file for this: https://github.com/offa/stm32-eth/blob/master/script/memcheck.suppression

Yes, it is strange: why it happens only on yours and not my builds and so on...perhaps it's the version of valgrind available on the nodes it builds on...
Anyway, I'll use your suppression file once I've found out how to get CMake to pass it to valgrind. Thanks!

Four hours later...I think I have worked it how to do it...

Thank you @mattgodbolt !


Handshake interface

What was wrong?
Identity scheme class only worked with ENR, but it's also responsible for the handshake.
How was it fixed?
Implement the basic interface and add a placeholder so that we don't have to implement the cryptography as long as it isn't properly specified.
Also some minor stuff:

rename node address to node id (both are used interchangeably in the spec, but address may collide with endpoint address)
add method to access public key (we'll need that for the handshake)
make node id and public key accessible on the ENR via properties

Cute Animal Picture

Sorry for the delay. Changes since last review:

Ellipsis instead of "pass" in abstract method bodies
Renamed "KeyAgreementResult" to "SessionKeys" and "perform_key_agreement" to "compute_session_keys"
In V4IdentityScheme.extract_public_key(enr), I don't assume anymore that the ENR has been validated before (a proper exception is raised). Instead, this assumption is only made in ENR.public_key. It's still not ideal, but better than before, as now this issue is only present in one, not two classes. Also, I've added an Exception("Invariant: ...") in the property to document this slightly awkward coupling.
Added id nonce signing and signature verification methods to the identity scheme which are also required for the handshake.
I got rid of the get_random_bytes interface. The only reason why I thought it would be useful is for testing (so that we can replace the non-deterministic os.urandom we should use in production with a pseudo random alternative). But now I don't like it anymore as it increases the complexity of the interface for no good reason. Instead, I just mock out os.urandom in tests via a fixture.

What I have not done (yet):

Use factories for creating ENRs. The problem here is that for most of the tests we actually test stuff in the ENRs __init__ function, so what I'd actually have to do is use some kind of ENRKwargFactory which doesn't feel very useful for future tests. So since the existing tests already work fine I'd rather not spend more time on it at the moment to get it right, but revisit this for the next time I need an ENR for tests.
 Will do so before I merge

Other than that, if I haven't missed anything, this is ready from my side.


Avoid rendering "None" as S3 Prefix value

This is a small change to avoid rendering "None" as the value for Prefix in S3 response templates.
Currently, we're sometimes receiving <Prefix>None</Prefix> in S3 responses, which leads to issues with paginated requests, e.g., when using listNextBatchOfObjects(..) from the Java SDK.
Cheers

Coverage increased (+0.006%) to 94.03% when pulling 4ad111830b79ed6bbfd8462cf0a5d9c3a4ccc2d7 on whummer:fix-s3-prefix into b8a1f85285fe28039da64005255e2c4488bc8764 on spulec:master.


Streaming error mishandled in http.rb

Line 154 in http.rb on env is nil on valid requests. This causes merge to error on line 157
 return unless env&.status != 200

Example:
          response = anthropic_client.messages(
            parameters: {
              temperature: 0.7,
              model: model,
              messages: message_data
              max_tokens: 100,
              preprocess_stream: :text,
              stream: proc do |incremental_response, delta|
                next if delta.blank?
                Rails.logger.info "Incremental response: #{incremental_response}"
                Rails.logger.info "Delta: #{delta}"
              end
            })

Thanks, @strukturedkaos. Have you seen this occur @swombat ?

Any chance of this being fixed in the next few days? We can't use the streaming api right now.

Also getting this error

@redders123 will see if I can fix this

@alexrudall Anything I can help with? Are you able to reproduce the issue?
In case it helps:
ruby 3.2.2
Rails <IP_ADDRESS>

Hey @strukturedkaos -- struggling to find the time to look at this - but I'm very open to a PR if you're able to figure out a fix! If not I will get to it when I can.

I ran into this as well, it's because the streaming proc method signature changed in Faraday 2.5.0, and any older version only provides the first two arguments to the proc (see 6799f58).
So you could update the gemspec to require ~> 2.5.0 of Faraday, although that wouldn't work for me as I have other gems that require < 2.0 of Faraday that I'm not able to easily upgrade.
The other option is to update Anthropic::HTTP#handle_faraday_error to accomodate the case where env isn't provided as a third argument. At first glance I don't see any way to get the http request status in order to check if there is an error with an older version of Faraday, so you might just have to assume the streaming request is successful on older versions of Faraday? @alexrudall if you have any suggestions about how you'd like to handle older versions of Faraday and I can put together a PR.

@geeosh your fix worked for me. Thank you. Hopefully we can get the PR merged soon.

Thanks for your patience @geeosh & @strukturedkaos, @leo-quimbee, @redders123, now released in v0.3.2


[top] Integrate ast into FPGA

Integrate AST into fpga (cw305/cw310/nexysvideo)

I need to clean-up the commits a bit, but can you guys have a look at the final result and let me know what you think?
I had to add ast into englishbreakfast...which was a bit awkward..but i think that's slightly better than the alternative of having a different clocking structure.

The related issue is here: https://github.com/lowRISC/opentitan/issues/295. @tjaychen do you mind ticking off some of the FPGA / Verilator tasks on that issue once this has been merged?

i've addressed the comments, merging.


Problem when instantiating Tasks in the tableauserver when they have no Schedule assigned

Describe the bug
In our Tableau Site we don't use schedules for tasks, and when trying to fetch the issues from the endpoint, it fails.
Versions
Details of your environment, including:

Tableau Server Online
Python 3.9
TSC library version v0.28

To Reproduce
In a server without Schedules, try to get tasks with, for example:
req_option = tsc.RequestOptions(pagesize=1000) all_extracts, pagination_item = server.tasks.get(req_option)
Results
It fails because there is no name for schedules.
NOTE: Be careful not to post user names, passwords, auth tokens or any other private or sensitive information.
The solution is to make the schedule optional for the tasks, as those can be created without schedules.

The solution is pretty easy. In task_item:

and


[enhancement] Add meaningful logging

Logging would be useful for tracking/tracing and debugging

Added to 0.28.0


Implemented RFC0004

Things got a little bit more complex because of Resource Model :(

@pksunkara I would at least expect the link to the RFC in the description. Making it easier for person who reviews it might actually helps to get the review faster. Also this should have do not merge label until it is implemented

@pksunkara please keep in mind providing context and clarity is what we all should aim for, looking at the first 20 lines of diffs I do not recall what RFC0004 was about.

Remember to do the following:

[ ] Update the parent sections for URI Parameters section: https://github.com/apiaryio/api-blueprint/blob/master/API Blueprint Specification.md#def-uriparameters-section

@zdne We use "PR: Passed review" label to denote this PR as reviewed and should be merged only after implementation. Not the "PR: Do not merge" label.

@pksunkara why are you mentioning it https://github.com/apiaryio/api-blueprint/pull/293#issuecomment-167579599 ? (besides it should be "Do not merge" + "Passed review" – one is given by the author other by the reviewer)

@zdne I was replying to this line from you.

Also this should have do not merge label until it is implemented

I wanted to point out that we do not use "PR: do not merge" labels in this case because we generally use it to denote that a PR is not ready according to the author. Guess, we need more labels :smile:

I have removed the URI parameters from Resource Model since it is soon to be deprecated anyway. This PR is ready for review now.

Addressed.

This looks good to me :+1:

@w-vi Fixed.


add: protonvpn-gui

[x] Edit packagelist
[x] Add initial pacscript
[ ] ~Contact devs (via email)~
[x] Add maintainer to pacscript

The error seems to be CI specific, everything works fine on a normal machine
https://packages.debian.org/buster/gir1.2-appindicator3-0.1

Because: https://www.debian.org/releases/bullseye/armhf/release-notes.en.pdf se section 5.3.1 Noteworthy obsolete packages

The deprecated libappindicator libraries are no longer provided. As a result, the related pack-
ages libappindicator1, libappindicator3-1 and libappindicator-dev are no longer
available. This is expected to cause dependency errors for third-party software that still depends
on libappindicator to provide system tray and indicator support.
the same issue with discord package.


internal server error after login

Describe the bug

After login into either the web browser at https://bsky.app/ or in the android app an internal server error is shown.
On Thursday November 9th the login was still working fine and I did posts with that login. Yesterday Friday November 10th the error did occur the first time and today the error still remains.
Another private login of myself is still working fine.
(both accounts are domain accounts, just with different domain names)
Has the problems eventually something to do with these migrations?
https://github.com/bluesky-social/atproto/discussions/1832
Expected behavior

no more internal error anymore like it has been until Thursday November 9th 14.27 (UTC +1) when I did the last posts with that account.
Screenshots

Details

Platform:
Platform version:
App version:

Additional context

I have the same issue.

The only feedback that I have gotten so far from the Bluesky support is the following.
But the steps did not solve the problem so far as I wrote back to them.
The account cannot be used anymore since November 10th ...

I have not gotten any information so far from the Bluesky support that the problem was solved.
But I just noticed that the login is now working again, so it looks like  the Bluesky support has solved the problem.

It’s working for me as well now!


Import disqus xml file failed

I installed isso by setup virtual environment using pipenv, following this guide.
When I'm trying to import my disqus xml file, I got this error:
Traceback (most recent call last):
  File "/home/tareef/isso/.venv/bin/isso", line 11, in <module>
    sys.exit(main())
  File "/home/tareef/isso/.venv/lib/python3.6/site-packages/isso/__init__.py", line 238, in main
    migrate.dispatch(args.type, mydb, args.dump, args.empty_id)
  File "/home/tareef/isso/.venv/lib/python3.6/site-packages/isso/migrate.py", line 279, in dispatch
    cls(db, dump).migrate()
  File "/home/tareef/isso/.venv/lib/python3.6/site-packages/isso/migrate.py", line 107, in migrate
    'email': post.find('{0}author/{0}email'.format(Disqus.ns)).text,
AttributeError: 'NoneType' object has no attribute 'text'

Do you have an example discus file with this problem (perhaps from a site without privacy-sensitive comments)?

I sent you an email with my XML file. Thanks for your interest.

It looks like the issue is that the  elements in your disqus XML file don't have an email set.

We could consider multiple solutions:

Setting a default email if none present → I don't know the implications it will have on the result isso DB, will it work?
Not importing comments without email → seems like not the feature users would want
Importing comments anyway by setting a<EMAIL_ADDRESS>

Importing comments by setting a default email sounds good.

Do we need a default email? It's possible to comment without setting a proper email address.


Highlight selected tool

You got it.  Hit me up if you need someone to pick up any more issues.

Feel free to take any that you think would be fun, or even suggest some improvements yourself if you see something you think would be cool! I might not be around the next few days to review but I will defiantly get to them next week


Readxl add a date for a time format

With the file times_1904.xls, read_excel add a date 1904-01-01
> read_excel("times_1904.xls")
Source: local data frame [11 x 1]

                  Time
1  1904-01-01 01:02:03
2  1904-01-01 02:45:56
3  1904-01-01 04:29:49
4  1904-01-01 06:13:42
5  1904-01-01 07:57:35
6  1904-01-01 09:41:28
7  1904-01-01 11:25:21
8  1904-01-01 13:09:14
9  1904-01-01 14:53:07
10 1904-01-01 16:37:00
11 1904-01-01 18:20:53
```

When it should behave like Excel.

Pandas does it right (it is their test files ;) )

```
In [5]: pd.read_excel("times_1904.xls")
Out[5]:
               Time
0          01:02:03
1   02:45:56.100000
2   04:29:49.200000
3   06:13:42.300000
4   07:57:35.400000
5   09:41:28.500000
6   11:25:21.600000
7   13:09:14.700000
8   14:53:07.800000
9   16:37:00.900000
10         18:20:54
```

Same issue with [times_1900.xls](https://github.com/pydata/pandas/blob/master/pandas/io/tests/data/times_1900.xls)

Given that R doesn't have a time type, I think people are going to have to struggle with this issue at some point.


Admin User - Data Expiry

As an Admin user in Doorway,
I want applicant and lottery data to be removed for download 90 days after a listing closes,
So that I do not have access to sensitive information longer than I need to.
Notes:

This should just be an empty state on the FE, not actual deletion.

AC:

As an Admin, 90 days after a listing closes, I should no longer be able to download applicant or lottery data.
As an Admin, 90 days after a listing closes, I should see an empty state notifying me that my data is going to download.

This is not a bug - backlog item for the future if BAHFA chooses to prioritize it


Mentorship: Swap routes

Have /mentorship and /mentor routes point to new semester.
TEST=manual
Checked all four routes.
Change-Id: I26d647e976b1578befde2677f4c27f5bd55fccd4

Code Review comments can be found at https://gerrithub.io/q/I26d647e976b1578befde2677f4c27f5bd55fccd4


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_00pez00ixo/clone/recipe/meta.yaml:14: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_00pez00ixo/clone/recipe/meta.yaml:20: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_00pez00ixo/clone/recipe/meta.yaml:42: missing_documentation: The recipe is missing a doc_url or doc_source_url
ERROR: /tmp/abs_00pez00ixo/clone/recipe/meta.yaml:42: missing_license_family: The recipe is missing the about/license_family key.
ERROR: /tmp/abs_00pez00ixo/clone/recipe/meta.yaml:42: missing_dev_url: The recipe is missing a dev_url
WARNING: /tmp/abs_00pez00ixo/clone/recipe/meta.yaml:42: missing_description: The recipe is missing a description
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_45yvumyr7z/clone/recipe/meta.yaml:14: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_45yvumyr7z/clone/recipe/meta.yaml:20: missing_wheel: For pypi packages, wheel should be present in the host section
WARNING: /tmp/abs_45yvumyr7z/clone/recipe/meta.yaml:42: missing_description: The recipe is missing a description
ERROR: /tmp/abs_45yvumyr7z/clone/recipe/meta.yaml:42: missing_documentation: The recipe is missing a doc_url or doc_source_url
ERROR: /tmp/abs_45yvumyr7z/clone/recipe/meta.yaml:42: missing_license_family: The recipe is missing the about/license_family key.
ERROR: /tmp/abs_45yvumyr7z/clone/recipe/meta.yaml:42: missing_dev_url: The recipe is missing a dev_url
Errors were found


M3-4020 Follow-up

Description
Assorted feedback items from the original PR and sprint review:

disable addDevice form button if no Linodes have been selected
Show slightly more helpful message if all Linodes are already attached
use e.preventDefault() to prevent page from reloading when pressing Enter inside the
Use key prop to reset LinodeMultiSelect form state

When the Add Device form is submitted, and an error occurs,
the previously selected Linodes remained selected in the LinodeMultiSelect
field. They remained unchanged regardless of whether the Linode in question
was successfully added to the firewall.
This could cause problems, e.g.:

Select one invalid Linode and two valid Linodes
Submit the form
Observe: all 3 are still selected and an error is displayed for the "bad" Linode
Submit the form again
Observe: you can now get an error for the valid Linodes, since it's not
possible to re-add something that's already attached to the Firewall.

To fix this, I used React's key prop. By resetting the key on submit, the
LinodeMultiSelect is re-created, with new filteredLinodes props. The result
is that the select is cleared, and the user is unable to re-select any Linodes
that were successfully added.

These changes LGTM