Update website to look of mbon.ioos.us

See #1, especially ...

On 11/30/20 3:47 PM, Andy Nguy wrote:
We can update the menubar styling on the current sanctsound to look like the IOOS menubar. From a glance, it looks like we can achieve this with some CSS since sanctsound and IOOS have similar menu structures (single level dropdowns). Here’s a quick visual I slapped together.

From: Micah Wengren<EMAIL_ADDRESS>Date: Wed, Dec 2, 2020 at 10:18 AM
And a couple small updates to what I said before is that I confirmed on our end the IOOS logo links in the header area should all point to ioos.us, and the sanctsound.ioos.us splash page should include a footer that matches or at least has the same content as the main ioos.us site.

Problem: the libs/styles.css styling from _site.yml:
output:
  html_document:
    theme: yeti
    css: libs/styles.css

is not getting knitted from input Rmd to output html (eg index.Rmd to index.html). Seems to be a problem of not extracting from _site.yml, since should be handled by default.html here:
$for(css)$
<link rel="stylesheet" href="$css$" $if(html5)$$else$type="text/css" $endif$/>
$endfor$

but is not being parameterized in pandoc command, eg knitting index.Rmd. Note that the CSS does work if explicitly listing on every page, but that defeats purpose of _site.yml and is super redundant.
https://github.com/marinebon/sanctsound/blob/dff5fff290018acc8c5b162e52f24ee795207556/index.Rmd#L5-L8
/Applications/RStudio.app/Contents/MacOS/pandoc/pandoc +RTS -K512m -RTS index.utf8.md --to html4 --from markdown+autolink_bare_uris+tex_math_single_backslash --output index.html --lua-filter /Library/Frameworks/R.framework/Versions/4.0/Resources/library/rmarkdown/rmarkdown/lua/pagebreak.lua --lua-filter /Library/Frameworks/R.framework/Versions/4.0/Resources/library/rmarkdown/rmarkdown/lua/latex-div.lua --email-obfuscation none --standalone --section-divs --template /Library/Frameworks/R.framework/Versions/4.0/Resources/library/rmarkdown/rmd/h/default.html --no-highlight --variable highlightjs=1 --css libs/tiles.css --include-before-body /var/folders/2r/grqvdjfn04361tzk8mh60st40000gn/T//RtmpJdvQoy/rmarkdown-str775434e528cb.html --variable navbar=1 --variable body_padding=45 --variable header_padding=50 --variable 'theme:yeti' --include-in-header /var/folders/2r/grqvdjfn04361tzk8mh60st40000gn/T//RtmpJdvQoy/rmarkdown-str775430d9428e.html

Problem: the libs/styles.css styling from _site.yml:
output:
  html_document:
    theme: yeti
    css: libs/styles.css

is not getting knitted from input Rmd to output html (eg index.Rmd to index.html). Seems to be a problem of not extracting from _site.yml, since should be handled by default.html here:
$for(css)$
<link rel="stylesheet" href="$css$" $if(html5)$$else$type="text/css" $endif$/>
$endfor$

but is not being parameterized in pandoc command, eg knitting index.Rmd. Note that the CSS does work if explicitly listing on every page, but that defeats purpose of _site.yml and is super redundant.
https://github.com/marinebon/sanctsound/blob/dff5fff290018acc8c5b162e52f24ee795207556/index.Rmd#L5-L8
/Applications/RStudio.app/Contents/MacOS/pandoc/pandoc +RTS -K512m -RTS index.utf8.md --to html4 --from markdown+autolink_bare_uris+tex_math_single_backslash --output index.html --lua-filter /Library/Frameworks/R.framework/Versions/4.0/Resources/library/rmarkdown/rmarkdown/lua/pagebreak.lua --lua-filter /Library/Frameworks/R.framework/Versions/4.0/Resources/library/rmarkdown/rmarkdown/lua/latex-div.lua --email-obfuscation none --standalone --section-divs --template /Library/Frameworks/R.framework/Versions/4.0/Resources/library/rmarkdown/rmd/h/default.html --no-highlight --variable highlightjs=1 --css libs/tiles.css --include-before-body /var/folders/2r/grqvdjfn04361tzk8mh60st40000gn/T//RtmpJdvQoy/rmarkdown-str775434e528cb.html --variable navbar=1 --variable body_padding=45 --variable header_padding=50 --variable 'theme:yeti' --include-in-header /var/folders/2r/grqvdjfn04361tzk8mh60st40000gn/T//RtmpJdvQoy/rmarkdown-str775430d9428e.html

Sorted. Now it looks like this:


python38Packages.google-cloud-resource-manager: 1.1.1 -> 1.1.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.google-cloud-resource-manager is: "Google Cloud Resource Manager API client library"
meta.homepage for python38Packages.google-cloud-resource-manager is: "https://github.com/googleapis/python-resource-manager"
meta.changelog for python38Packages.google-cloud-resource-manager is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.1.2 with grep in /nix/store/9zy43g3kx25l6i0i3wmq9706a6wnh5sc-python3.8-google-cloud-resource-manager-1.1.2

found 1.1.2 in filename of file in /nix/store/9zy43g3kx25l6i0i3wmq9706a6wnh5sc-python3.8-google-cloud-resource-manager-1.1.2

directory tree listing: https://gist.github.com/db4b5e19f0180d8bf65298867eab00c5

du listing: https://gist.github.com/0ad5912809cec53a85d0e842ff5b574c

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
python38Packages.google-cloud-resource-manager
python39Packages.google-cloud-resource-manager

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/9zy43g3kx25l6i0i3wmq9706a6wnh5sc-python3.8-google-cloud-resource-manager-1.1.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.google-cloud-resource-manager https://github.com/r-ryantm/nixpkgs/archive/452fc587f79cf28038cd7f0b6f8ae676c10f2f04.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/9zy43g3kx25l6i0i3wmq9706a6wnh5sc-python3.8-google-cloud-resource-manager-1.1.2
ls -la /nix/store/9zy43g3kx25l6i0i3wmq9706a6wnh5sc-python3.8-google-cloud-resource-manager-1.1.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python38Packages.google-cloud-resource-manager
python39Packages.google-cloud-resource-manager

Maintainer pings
cc @SuperSandro2000 for testing.

closing in favor of #140959


upcloud: encrypted at rest volumes

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:
/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:
Im creating tihs PR for reviews and then I will create a PR upstream.

Adds support for encrypted bootdisks for vms
Bump the upcloud csi driver and added more default storage classes.

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Make sure to update the branch before merging. @davidumea has done some changes there, so they don't dissapear

@Elias-elastisys I updated how snapshot classes are added/created. So please take another look :slightly_smiling_face:

What about the removed Velero label? The docs seemed to indicate it was required, but never tested without it. Or do we plan to add it back somewhere else?

As velero is not a kubespray component it is strange to have it here. As it should be possible to chnage it to what ever. So it is possible to add the label via group_vars instead. Where I think it should live.
Example would be:
snapshot_classes:
  - name: upcloud-csi-snapshotclass
    is_default: true
    labels:
      velero.io/csi-volumesnapshot-class: "true"


TF_BUILD environment variable missing from container job

Agent Version and Platform
Version of your agent? 2.144.0
OS of the machine running the agent? Linux; Ubuntu 16.04 with Docker
VSTS Type and Version
Azure Pipelines
What's not working?
Following up from https://github.com/cake-build/cake/issues/2432, the container job in Cake.Dungeon/azure-pipelines.yml#L6-L17 uses cake-build/cake and is not working as expected because the TF_BUILD environment variable has not been passed to the Docker container.
See Cake.Dungeon/#20190107.3/Docker job for all the build step environment variables, which have been logged as seen from inside the container. Note that the TF_BUILD environment variable is missing.
For comparison, Cake.Dungeon/#20190107.3/Linux job and Cake.Dungeon/#20190107.3/Windows job, are both run directly on the agent and see the TF_BUILD environment variable.
The TF_BUILD environment variable is required for Cake build to correctly detect if it is running on Azure Pipelines and affects subsequent build behavior such as only publishing artifacts when detected.

FTR, workaround removed as fixed in azure pipelines agent 2.146.0 deployed ~Feb 6. Thanks again!


bump up psutil version from 5.2.2 to 5.6.6

bump up psutil version in one commit instead of separate commits created by dependabot

I've change the commit message


Flatpak support

With most free applications moving towards Flatpak, please provide such an image, too!

I've heard this request many times from Linux users

I don’t know if Electron can be used in conjunction with Flatpak. But getting rid of Electron would be beneficial for performance, so this would be pretty good. 😎

We've also discussed appimage packaging in the past as well. Not sure how that compares to flatpak.
Getting rid if electron means developing native solutions on each OS, which is not something we want to do at this time.

AppImage is deprecated – Flatpak can do everything what AppImage does and much more!

Good to know, thanks! I'll update that original app image issue and link these.

Most programs of the Gnome desktop get ported to Flatpak until 3.28. At the moment a lot is ported already, so this is the way to go. It also is already integrated into the Gnome Appstore. ;)
For more information, see:
www.flatpak.org and www.flathub.org

Endless people are tackling this issue (flatpaking electron apps):
https://github.com/endlessm/electron-flatpak-base-app
http://blog.manuq.com.ar/posts/building-electron-apps-offline-for-flathub/

Per discussion still happening on #332, it doesn't seem like there is a consensus that Flatpak > AppImage.
I'm open to changing this, but it's unlikely we're adding 2 new ways to package an app on our least popular OS.

Flatpak neither needs root, nor involves complicated commands. It is directly integrated into the Gnome appstore and non-gnome distros will support it too, soon – if they don’t yet provide it already, as e.g. KDE does. With Gnome and KDE you reach >98% of all Linux desktop users – the rest seems to be able installing it via flatpak install --bundle LibreOffice.flatpak, or double-clicking the file. And if Flatpak isn’t shipped with the system already, dnf/apt install flatpak really doesn’t seem to be that hard.
Check out the most used Linux applications and you’ll see that a lot of them are available as flatpak images already (Firefox, Steam, LibreOffice, Slack, Spotify, VLC, Inkscape, Blender, Transmission, Gnome-MPV, Audacity, Corebird, Darktable, FileZilla, FeedReader, Lollypop, Gedit, GnuCash, Builder, Peek and nearly all Gnome core applications). There are many reasons why all their developers have chosen Flatpak over AppImage or Snap. And by the way: There is even EndlessOS, where EVERY single program is flatpaked.
AppImage seems to be a one-way street, because nearly everything at the moment is under way providing Flatpak images. I don’t know a single feature, what is supported via AppImage and not available as Flatpak. I don’t think that custom themes are usable via AppImage, and sandboxing isn’t available at all. See Android – every single user-installed application is sandboxed, what is especially important for applications that have a connection to the internet. You’ll want that on desktop Linux, too!
Snap isn’t decentralized what is the mayor drawback, and many distros and applications don’t support it because of this. Plus, providing a decentralized YouTube alternative via a centralized appstore isn’t reasonable at all.
Here you’ll find more information:
Flatpak presentation
Flatpaking KDE

@HoboPrimate @fbruetting would either of you be interested to add support for flatpak yourselves? We'd be happy to offer commensurate LBC bounty.

@kauffj I commented on the thread with the info on current efforts for flatpaking electron apps, but I don't have the skills myself unfortunately. Am just a linux user who came across this application (by mention in one of bryan lunduke's videos) who doesn't run debian/ubuntu.

So yeah, Snap only does work for Ubuntu…

Hello,
I just submitted a Flatpak version of the LBRY app on Flathub: https://github.com/flathub/flathub/pull/175
I'm sure the Flathub team can add some else to the repo once it's created that represents the release team on LBRY. I'll try to keep it updated but I don't use LBRY much. I'm on Fedora and wanted to try it but only saw the deb. I figured I might as well package it for Flatpak so I didn't need to build from source.
It's currently being built with the stable deb file. It'll be changed over to being built from source once the Flatpak/Flathub team can find a better way to ship Electron apps.

Just to confirm, Flathub's policy is that the upstream team can absolutely control the app on Flathub, it's there as a service to make things easier for developers - but we allow other people to set up the flatpak and maintain it if there isn't a lot of upstream interest.
As for electron apps, they're absolutely supported! The 'electron native' way to make a flatpak isn't very 'flatpak native', which is a bit annoying, and that's the barrier that we're trying to overcome right now.
Please see https://lbry.io/faq/tips
@nedrichards thanks for coming by to provide the additional information.  I'll look into the process needed to maintain it, but I feel like we would be able to handle it.  Not sure what the initial demand will be - at this point a majority of our users are Windows based.  I would assume there is a cost to the service you provide.

@tzarebczan Nope, no cost. The costs of Flathub are covered by donations from people and organisations keen to see a better app developer experience on Linux. (e.g. my employer Endless helps out because it gets better, more quickly updated apps to our users). We understand that for almost every project there are more users on Windows, Mac OS, Android, anything else - so we want to make stuff as easy as possible!
Let me know github usernames and I'll add you to the repo - the maintenance guidelines are here. But if you've got any questions or need help, just ask.

Sweet, flathub.org has the install file up at https://flathub.org/repo/appstream/io.lbry.lbry-app.flatpakref
Installed successfully on Fedora :)
when I installed it with the built in app manager - it did say "something went wrong" but the app worked. No errors when installing from flatpak command line.

hey @nedrichards, are you a crypto fan? Can we get some LBC (LBRY Credits) over to you for your contributions?

@tzarebczan is this working?

@liamcardenas Yes, install flatpak via your distro's package manager then add the Flathub repo & install io.lbry.lbry-app by:
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak --user install flathub io.lbry.lbry-app

By adding the Flathub repo you can try out other Flatpak apps on Flathub ;)
This issue could probably be closed now.

Yes, worked on my fedora vm. The working directories are a bit different, so we may want to document that somewhere.
We should definitely add the link to the flathub site in our install / Readme doc.
I think @IGassmann still wanted to check our appimage because of native electron support, but Jeremy said we should go with the one or other.
This definitely fills the gap for non Debian systems, and since Linux accounts for a smaller portion of installs, we shouldn't spend too much time on it.

@julianrichen Thanks for what have you done. We appreciate your help.
Concerning app updates. If we release a new version of our app, should we update manually the related flathub repository or is there any way to do it automatically?

@IGassmann At the moment you have to manually update the json manifest in the flatpak repo with the new URL, size and sha256 hash. It's not terribly difficult but it is an extra manual step.
fwiw on 'native electron support' that's something that flatpak also has, there just isn't a plugin to electron builder yet (there's tools for electron installer and another way that I can't quite remember off the top of my head). Also, once you create a file that way you still have to run your own repository for updates etc. which is a bit of a hassle and something flathub does for you. But it's totally possible (at Endless we've shipped some apps using this).
The flatpak community is also working on making it easier to build electron apps natively on Flathub or elsewhere (with the advantages of reproducible builds, not needting network connectivity during the build etc.) with tools like flatpak-npm-generator that takes package-lock files and turns that into a flatpak manifest (I'm hoping it'll be extended to yarn.lock files soon as well).

@tzarebczan well, I've certainly been testing the app, so always happy to have anything that makes it easier! ;-)

@nedrichards Send me an email at<EMAIL_ADDRESS>with your LBC address (receive tab of the wallet) and I'll get some over to you :)
Thanks again for the support and trying out the app!

@nedrichards if it's possible that we (or you ;) can create a script that our build service (Team City) can run, we can explore automating this and remove that manual step.

@kauffj that's a really interesting question and one that I love to hear. I'll file a ticket on Flathub and we'll have a chat. Remote building, or remote triggering has been seen as being a little way away - but if people are asking for it then we can certainly talk! I'll start the discussion and hook you in so you can see and maybe share some of your requirements.

Due to these reasons: https://github.com/lbryio/lbry-app/issues/332#issuecomment-359021161 AppImage has been chosen as our Linux target package instead of Flatpak.

For the record, appimages do not tend to support accessibility features, cannot be "installed", require a roll-your-own upgrade solution which introduces privacy and security concerns, will not integrate into desktop environments, and dramatically increase the resource usage required for even hello world in electron from 350 MB of RAM to 500 MB of RAM on my system. As I am legally blind and must have accessibility features, that alone pretty much ensures I won't be using an appimage.

For the record, appimages do not tend to support accessibility features, cannot be "installed", require a roll-your-own upgrade solution which introduces privacy and security concerns, will not integrate into desktop environments, and dramatically increase the resource usage required for even hello world in electron from 350 MB of RAM to 500 MB of RAM on my system. As I am legally blind and must have accessibility features, that alone pretty much ensures I won't be using an appimage.


Deprecate run_ica()

What does this implement/fix?
Removes the mne.preprocessing.ica.run_ica() function. All it does it instantiate an ICA object and then run an artifact detection. However, the same can be achieved by using ICA.detect_artifacts().
Deprecates mne.preprocessing.ica.run_ica() in favor of ICA.detect_artifacts()

git grep run_ica tells me that examples/preprocessing/plot_ica_comparison.py should be updated, too

git grep run_ica tells me that examples/preprocessing/plot_ica_comparison.py should be updated, too

No, it defines its own run_ica function which it then calls with different parameter values to create different plots

Hah! fair enough

@larsoner @drammock I believe I've addressed all of your comments.

Good call! run_ica has been some historical leftover for years ...

On 19 Feb 2020, at 21:23, Eric Larson<EMAIL_ADDRESS>wrote:

@larsoner approved this pull request.
LGTM +1 for merge once CIs come back happy
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

The Travis failure is a general timeout error at the CodeCov step, seems unrelated to this PR (@larsoner have you seen that before? Seems odd). Azure is "Windows fatal exception: caccess violation" which is also unrelated (though is happening a lot lately, should be investigated).

@drammock the Travis timeouts at various stages are just https://github.com/numpy/numpy/issues/15580
The Azure failures I was hoping to fix with https://github.com/mne-tools/mne-python/pull/7295 but hasn't quite done the trick


Question about support for already running applications

Can jqf be used on already running applications using javaagents?
Let's take minecraft as an example.
Server starts with javaagent
java  -javaagent:JQFagent.jar server.jar
server load plugin from ./plugins dir (plugin contains @RunWith(JQF.class) @Fuzz code)
maven plugin starts fuzzy instructions
hooks in agent catch exceptions
java agent send exceptions to maven plugin

Hmm... I've never really tried it but it is worth attempting. JQF can indeed be used with a JavaAgent instead of a Maven plugin. There is a script called bin/jqf-zest which allows invoking JQF on the command-line (sample usage shown in the 101 tutorial). If you follow what the script does, you will reach scripts/jqf-driver.sh, which actually does use the jqf-instrument JAR as a javaagent, where the premain method is in SnoopInstructionTransformer. So, the javaagent itself does the instrumentation and you don't really need the Maven plugin at all.
If you start the JVM with this JavaAgent, then you get instrumentation for free. You can then invoke a fuzz test (i.e., a method annotated with @Fuzz) programmatically by calling GuidedFuzzing.run() with the system classloader (you don't need an instrumenting classloader like the Maven plugin because the javaagent is already instrumenting classes for you).
Now, all of this will only work in your example if the application code to fuzz is in server.jar. If you are connecting remotely over a network, then I am not sure how much coverage feedback you will get even if you can actually invoke the application via RPCs.


Fix to define the runtime version as dependency management

@jonasrutishauser Thank you for the contribution. I just have a couple of questions, and also wanted to point out a change we made recently around the liberty.runtime.version property via this issue. We added the ability to specify the groupId and artifactId as properties, as well as the ability to specify an empty string for the version from the command line in order to default back to what is specified in the runtimeArtifact.
Can you explain in a sentence or two the use case that your are addressing with this PR? Can you show a before/after of the pom configuration for the scenario that you are addressing?

With this PR the following would work as documented (currently it always uses the latest version):
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>io.openliberty</groupId>
        <artifactId>openliberty-runtime</artifactId>
        <version><IP_ADDRESS></version>
        <type>zip</type>
      </dependency>
    </dependencies>
  </dependencyManagement>
     <!-- ... -->
            <plugin>
                <groupId>io.openliberty.tools</groupId>
                <artifactId>liberty-maven-plugin</artifactId>
                <version>3.5.1</version>
                <configuration>
                    <runtimeArtifact> <!-- documentation: Maven coordinates of a server assembly. This is best listed as a dependency, in which case the version can be omitted. -->
                        <groupId>io.openliberty</groupId>
                        <artifactId>openliberty-runtime</artifactId>
                        <type>zip</type>
                    </runtimeArtifact>
                  </configuration>
            </plugin>

At the moment we use a workaround to generated a property with the maven-dependency-plugin:properties goal and use this to define the runtime archive but this only works good if maven is called with a lifecycle target.

@jonasrutishauser Interesting, thank you for the explanation. Looks like the setting of the default version accidentally overrode the behavior of resolving the artifact version from dependency management. Line 177 of AbstractLibertySupport used to resolve the artifact from the dependency management section, and then its version was used. I will want to add a test for this specific scenario so that we do not regress this in the future. I'll open a separate issue for that and try to get this reviewed and merged later this week. Thanks again for the contribution.

@jonasrutishauser - reacting to your snippet comment:
<!-- documentation: Maven coordinates of a server assembly. This is best listed as a dependency, in which case the version can be omitted. -->

I'm curious what value you get out of specifying the runtimeArtifact as a dependency, as opposed to relying on the liberty-maven-plugin configuration including its more recent support for properties:

liberty.runtime.version
liberty.runtime.groupId
liberty.runtime.artifactId

Is it because you're doing some of your own custom packaging with some other downstream plugin?  I can't think of how it'd be more convenient just within the goals of the liberty-maven-plugin.
Appreciate your input, thanks.

Sorry for the late answers.

@jonasrutishauser Can you follow the CLA process here and sign the PR? Alternatively, I can open a separate PR where I would implement the fix based off your PR, add a test case and update the appropriate documentation. Then I would close this PR. Whichever you prefer is fine.

The alternative with a separate PR would be good.

I'm curious what value you get out of specifying the runtimeArtifact as a dependency, as opposed to relying on the liberty-maven-plugin configuration including its more recent support for properties:

liberty.runtime.version
liberty.runtime.groupId
liberty.runtime.artifactId

Is it because you're doing some of your own custom packaging with some other downstream plugin? I can't think of how it'd be more convenient when executing the goals of the liberty-maven-plugin.

We have our own openliberty docker image (built with maven) which has a dependency management for the liberty runtime. We then have a BOM-Import of this docker image which ensures that in local tests we use the same version as in the built docker image.
Therefore it would help us a lot if specifying the version via dependency management (other things can't be imported) is possible without running an additional goal.

Closing this PR since it was implemented in #1464. The fix will be part of the next release (3.6) which is currently targeted for the first week of April.

We have our own openliberty docker image (built with maven) which has a dependency management for the liberty runtime. We then have a BOM-Import of this docker image which ensures that in local tests we use the same version as in the built docker image. Therefore it would help us a lot if specifying the version via dependency management (other things can't be imported) is possible without running an additional goal.

You can do this via a parent.  I assume the value of using a BOM then is that you're not limited to a single parent, i.e. you can work around the lack of "multiple inheritance".


Modal gets closed as you click on it when it's rendered from a popup

Bug Report
Steps
I have a link inside a popup to open a modal with form but as I click on modal form to fill out the input the modal gets closed. No matter where I click on the modal it gets closed
Expected Result
The result that you expected.
Actual Result
The actual result that happened 💣
Version
"semantic-ui-css": "2.4.1",
"semantic-ui-react": "2.0.3",
Testcase

@hashmatmuqbil please complete the entire bug report. We need a minimal working code example to see what is happening.
Closing but will reopen if a code example is provided.


Stop using old-style simd_shuffle

fix #541

After upgrading to 0.5.3, I encountered a compile error, can you help me out?
error[E0432]: unresolved import `std::intrinsics::simd`
  --> C:\Users\runneradmin/.cargo\registry\src\index.crates.io-6f17d22bba15001f\pathfinder_simd-0.5.3\src\arm\mod.rs:13:22
   |
13 | use std::intrinsics::simd::*;
   |                      ^^^^ could not find `simd` in `intrinsics`

Please open a new issue about that error!


Add rake task to create User, Schedules, and Shifts, and run it from seeds file.

Ths will close issue #37. It also fixes the association between Users, Schedules, and Shifts - you can now do User.find(1).shifts or Schedule.find(1).users and so on.

Yeah that works for me.
On Wed, Nov 8, 2017 at 8:55 PM Lakshya Kapoor<EMAIL_ADDRESS>wrote:

@kapoorlakshya commented on this pull request.
In db/seeds.rb
https://github.com/zeiter-io/zeiter/pull/57#discussion_r149866861:

-enrollments = Enrollment.create([
@maxdobeck https://github.com/maxdobeck Are you okay with me deleting
the commented code and only keeping the rake tasks here?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zeiter-io/zeiter/pull/57#pullrequestreview-75329796,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALidQki1XAJtuAfopczw7nJ98YeCFjR0ks5s0oXZgaJpZM4QV42l
.

FYI - You can log in to any generated fake user account with their email in the Users index and password as "password".


235 keep track of minted uuids within the same run and warn for duplicates

Codecov Report

Merging #460 (91a2426) into main (14875c7) will increase coverage by 0.02%.
The diff coverage is 66.66%.

:exclamation: Current head 91a2426 differs from pull request most recent head b277c8e. Consider uploading reports for the commit b277c8e to get more accurate results

@@            Coverage Diff             @@
##             main     #460      +/-   ##
==========================================
+ Coverage   52.11%   52.13%   +0.02%
==========================================
  Files          51       51
  Lines        6179     6184       +5
  Branches     1039     1040       +1
==========================================
+ Hits         3220     3224       +4
  Misses       2731     2731
- Partials      228      229       +1

Flag
Coverage Δ

unittests
52.13% <66.66%> (+0.02%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/folio_migration_tools/custom_exceptions.py
74.19% <ø> (+2.31%)
:arrow_up:

...ng_file_transformation/mapping_file_mapper_base.py
81.10% <66.66%> (-0.26%)
:arrow_down:

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

@bltravis I have considered it, but it seems that as long as these lists/dictionaries are not dicts of dicts, we are safe.


feat(docs):  Add aligned-cli readme

Aligned CLI readme
Description
Adds an readme for the aligned CLI that displays and describes all its flags and parameters. This is intended to be used in alongside the other examples within the documentation for usage.
A separate PR should be done to make the naming conventions throughout the repo consistent. ref: https://github.com/yetanotherco/aligned_layer/issues/1589 . It would be recommended to do this in parts as it may introduce breaking changes.
Type of change
Please delete options that are not relevant.

[x] New feature

Checklist

[ ] “Hotfix” to testnet, everything else to staging
[ ] Linked to Github Issue
[ ] This change depends on code or research by an external entity

[ ] Acknowledgements were updated to give credit

[ ] Unit tests added
[ ] This change requires new documentation.

[ ] Documentation has been added/updated.

[ ] This change is an Optimization

[ ] Benchmarks added/run

[ ] Has a known issue

Link to the open issue addressing it

[ ] If your PR changes the Operator compatibility (Ex: Upgrade prover versions)

[ ] This PR adds compatibility for operator for both versions and do not change batcher/docs/examples
[ ] This PR updates batcher and docs/examples to the newer version. This requires the operator are already updated to be compatible

There is missing to update the summary.MD

Cambio! @JuArce I also added a missing link for Submitting Batch without Batcher


[AMBARI-23556] Fix constraint issue during logfeeder log entry testing.

What changes were proposed in this pull request?
NotBlank annotation cannot be used for Map types, NotEmpty can be used for constraint validation, so use that
How was this patch tested?
FT: manually
please review @adoroszlai @zeroflag @kasakrisz

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/1805/
Test FAILed.
Test FAILured.


added Farmer's Delight 1.2.4 from modrinth. PR 2, Electric Boogaloo

(and this time I made absolutely sure I refreshed the index...
Multiple times, since you keep committing concurrently. Maybe there should be a hook or something to handle the merge automatically? It's basically "ignore the conflicts and refresh the index" right?)

merged manually


read_gds read slowly

Hi heitzmann:
Using  read_gds functions to read large files is extremely slow. Do you have a solution?
klayout read file speed is relatively fast

There are many reasons why gdspy is slower, but mainly it's because it is written in python... it's hard to overcome that. Maybe there is a specific bottleneck we can improve. Could you send some profiling information for me to check which functions are the slowest?

read BOX 0x2D....in a multi-process fashion, which I suspect will make it faster?

Is your layout made only of boxes? Python doesn't multiprocess well, and even if that wasn't the case, most time would be spent in function calling, so it wouldn't matter.

I've been working on a C++ library to use as a backend for gdspy 2.0, so I'll close this issue as unsolvable in the current versions.


Implements the feature to open from command line on darwin platform

I guess this PR can be closed, right? Just want to make sure that updates are now made on #88 instead.
Please reopen it if I'm wrong!


add bpftrace for CI debugging

I like to run a bpftrace based program in CI to collect better logs for specific processes not observed in the normal testing such as the podman container cleanup command.
Given you need to have full privs to run ebpf and the package pulls in an entire toolchain which is almost 500MB in install size we do not add it the the container images to not bloat them without reason.
https://github.com/containers/podman/pull/23487

LGTM but you need to make IMG_SFX

Right which greets me with
base_images/debian_base-setup.sh:52:timebomb 20240801 "prevent us from getting broken tar-1.35+dfsg-3"
cache_images/fedora_packaging.sh:220:    timebomb 20240710 "Temporary workaround for signed rpms (ima) in rawhide"

and I didn't really wanted to look at this right now. I guess I can just bump the time?

Yes, just bump it.
Note that there WILL be problems. It's been a month since my last make here, and it will probably take 3-6 iterations before this is ready. I will try my best to help.

Note that there WILL be problems

Yes I know that part... but I guess someone has to suffer through that no what what. Might as well be me.

20240805t173227z-f40f39d13
20240708t152000z-f40f39d13 ⇑ (built in #357)

debian
prior-fedora
fedora
fedora-aws
rawhide

base
13.5
39-1.5
Generic
?
41-0

13.3 ⇑

kernel
6.9.12-1
6.9.12-100
6.9.12-200
6.9.12-200
6.8.5-301

6.9.8-1 ⇑
6.9.7-100 ⇑
6.9.8-200 ⇑
6.9.7-200 ⇑

grub2-common
2.12-5
2.06-121
2.06-123
2.06-123
2.06-124

2.12-2 ⇑

aardvark-dns
1.6.0-3
1.11.0-1
1.12.1-1
1.11.0-3
1.12.1-1

1.4.0-6 ⇑

1.11.0-1 ⇑
1.11.0-1 ⇑
1.11.0-1 ⇑

netavark
1.6.0-2.1
1.11.0-1
1.12.1-1
1.11.0-3
1.11.0-3

1.4.0-4.1 ⇑

1.11.0-1 ⇑
1.11.0-1 ⇑
1.11.0-1 ⇑

buildah
1.35.3+ds1-3
1.36.0-1
1.37.0-1
1.36.0-1
1.37.0-1

1.33.7+ds1-1 ⇑

1.36.0-1 ⇑

1.36.0-1 ⇑

conmon
2.1.10+ds1-1+b1
2.1.12-1
2.1.12-1
2.1.10-1
2.1.12-2

2.1.10-1 ⇑

container-selinux
?
2.232.1-1
2.232.1-1
2.232.1-1
2.232.1-2

2.232.1-1 ⇑

containers-common
?
1-99
0.60.0-1
0.60.0-1
0.60.0-1

0.59.1-2 ⇑
0.59.1-2 ⇑
0.59.1-1 ⇑

criu
3.17.1-3
3.19-2
3.19-6
3.19-4
3.19-7

3.19-4 ⇑

3.19-5 ⇑

crun
1.15-1
1.15-1
1.15-1
1.15-1
1.15-2

1.15-1 ⇑

docker-ce
5:27.1.1-1~debian.12~bookworm
?
?
?
?

5:27.0.3-1~debian.12~bookworm ⇑

golang
2:1.22~3
1.21.12-1
1.22.5-1
1.22.5-1
1.23~rc2-1

1.21.11-1 ⇑
1.22.4-1 ⇑
1.22.4-1 ⇑
1.23~rc1-2 ⇑

nmap-ncat
7.94+git20230807.3be01efb1+dfsg-4
7.92-2
7.92-2
7.92-2
7.92-3

7.95-1 ⇑
7.95-1 ⇑
7.95-1 ⇑
7.95-1 ⇑

passt
2024-07-26
2024-06-24
2024-07-26
2024-06-24
2024-07-26

2024-06-24 ⇑
2024-06-07 ⇑
2024-06-24 ⇑

2024-06-24 ⇑

podman
5.0.3+ds1-5
4.9.4-1
5.2.0-1
5.1.2-1
5.2.0~rc2-1

4.9.5+ds1-1 ⇑

5.1.1-1 ⇑
5.1.1-1 ⇑
5.0.3-1 ⇑

runc
1.1.12+ds1-2
1.1.12-1
1.1.12-3
1.1.12-3
1.1.12-4

1.1.12-3 ⇑

skopeo
1.13.3+ds1-2+b1
1.15.2-1
1.16.0-1
1.15.2-1
1.16.0-1

1.15.1-1 ⇑
1.15.1-1 ⇑
1.15.1-1 ⇑
1.15.1-1 ⇑

slirp4netns
1.2.1-1+b1
1.2.2-1
1.2.2-2
1.2.2-2
1.2.2-3

1.2.2-2 ⇑

systemd
256.4-2
254.16-1
255.10-1
255.10-1
256.4-1

256.2-1 ⇑
254.14-1 ⇑
255.8-1 ⇑
255.8-1 ⇑
256.1-8 ⇑

tar
1.34+dfsg-1.2+deb12u1
1.35-2
1.35-3
1.35-3
1.35-4

1.35-3 ⇑

@Luap99 care to repush, to pick up new pasta? (https://github.com/containers/podman/issues/23478#issuecomment-2271646047)

Shouldn't we merge this first as the images are now used in podman?

Also do we actually get the packages from the testing repos here? I would assume we need to wait for it to hit stable, no?

Eek I missed that. Okay, merged. @baude your turn, please rebase and rerun make IMG_SFX and let's see how that goes.


Fixed Some typos

Just fixes some small Typos
Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

Hi, I recently started my coding journey. This was my first pull requests and ive sadly overlocked the first part in the pull request guide that says "Do not edit files directly through GitHub".
I promise this mistake is not gonna happen any time in the future.
Sry :(

Can you update the title to follow the PR naming convection https://contribute.freecodecamp.org/#/how-to-open-a-pull-request


Private registry support for helm chart

I was hoping to generally use this scheme to support private registry so the user can change the value of sourceRegistry to use a private registry rather than change any number of values

/lgtm


set unique flags in .env

and as vars in yml

https://github.com/threefoldtech/grid_deployment/commit/f00df459cd521b65da05a4d549b7411830bba480


Fix example

Solves https://github.com/docker/libcompose/issues/399

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:kszarek/libcompose.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:kszarek/libcompose.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

LGTM. Thanks @kszarek!


fix: cd command doesn't work

Hi, cool project!
I thought of a hacky way to get the cd command to work.

Thanks for the effort in contributing! I actually had this workaround thought long back but didn't implement because it has lot of issues.

Only cd works, environment var and similar things don't and if implemented same way would be too janky.
Commands which take input from stdin behave abnormal.
Commands which print to stderr won't work.
Small amount of performance overhead.

Overall, its better to wait for the bun team to allow executing commands in same context then all these won't be an issue anymore.


⚠ Topfarmacia has degraded performance

In 5fba2a3, Topfarmacia (https://www.topfarmacia.it) experienced degraded performance:

HTTP code: 200
Response time: 13723 ms

Resolved: Topfarmacia performance has improved in 1f33f58.


Apache fails to load php5_module

Installed Apache 2.4 and PHP 5.6 without any options.
I get the error message below in attempting to start Apache.
httpd: Syntax error on line 172 of /usr/local/etc/apache2/2.4/httpd.conf: Cannot load /usr/local/opt/php56/libexec/apache2/libphp5.so into server: dlopen(/usr/local/opt/php56/libexec/apache2/libphp5.so, 10): Symbol not found: _unixd_config\n  Referenced from: /usr/local/opt/php56/libexec/apache2/libphp5.so\n  Expected in: /usr/local/bin/httpd\n in /usr/local/opt/php56/libexec/apache2/libphp5.so

Can you put in some more information about your system ?

I am getting a similar problem apart from for me it's with apache 2.2 and php 5.3. The libexec directory is not being created. apachectl configtest returns OK if I remove the following line.
LoadModule php5_module        libexec/libphp5.so
Previously the php module was created and located in the following location /usr/local/opt/php53/libexec/apache2/libphp5.so.
I tried reinstalling php53 with the --with-apache22 flag but it still didn't create the apache module.

Just note that the php5.3 and apache 2.2 bottles have not been merged yet which might be related.

maybe you can just the --with-apache option when installing php

Bumped into the same issue. As described in the homebrew-php repo, the next steps fixed my issues.
I ran:
brew uninstall --force httpd24
and
brew uninstall --force php56
to remove all versions of Apache 2.4 and PHP 5.6.
Then:
brew install php56 --with-apache
And after installation:
brew services restart httpd24
Hope it helps.

@javian @timsnadden @tangerine62 @lekkerduidelijk
Hello, everyone.
Got this working by including thr --with-apache option as some of you have mentioned. Thanks for the help!

Not working for me. MacOS X 10.11.6. Have tried with PHP 5.6, 7.0 & 7.1.0RC3:
brew install php71 --with-apache
==> Installing php71 from homebrew/php
==> Downloading https://downloads.php.net/~davey/php-7.1.0RC3.tar.bz2
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/php71/7.1.0-rc.3_8 --localstatedir=/usr/local/var --sysconfdir=/usr/local/etc/php/7.1 --with-config-file-path=/usr/local/etc
Last 15 lines from /Users/jlbrown/Library/Logs/Homebrew/php71/01.configure:
--enable-dtrace
--disable-phpdbg
--enable-zend-signals

configure: WARNING: unrecognized options: --with-mysql
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for a sed that does not truncate output... (cached) sed
checking build system type... x86_64-apple-darwin15.6.0
checking host system type... x86_64-apple-darwin15.6.0
checking target system type... x86_64-apple-darwin15.6.0
checking whether the C compiler works... no
configure: error: in `/private/tmp/php71-20161026-40548-x4gvnk/php-7.1.0RC3':
configure: error: C compiler cannot create executables
See `config.log' for more details

For php53 and httpd22, this is still not working.
I force remove httpd22 and php53.
I also removed the /usr/local/etc/php/5.3 and /usr/local/etc/apache2/2.2 directories.
Then
brew install php53 --with-apache22
The installation completes successfully, but /usr/local/Cellar/php53/5.3.29_7/libexec/apache2/libphp5.so does not exist.
Although, I need apache22, I also tried
brew install php53 --with-apache
The installation completes successfully, and the apache module is created, but the apache module does not load when going to php enabled pages.
I don't understand brew well enough to know what is going on. Any suggestions are appreciated.

Thanks for the help, folks. Just one note that Homebrew has deprecated the --with-apache modifier:
$ brew install php56 --with-apache ==> Installing php56 from homebrew/php Warning: homebrew/php/php56: --with-apache was deprecated; using --with-httpd24 instead!


Fix script color count.

The script keeps identifying 2 color counts in a given image regardless of the actual number.

Hi @MarvinKweyu, can I try this?

Sure thing @Ian-Yy .


[All] Update CPO docker image tag to v1.22.0

What this PR does / why we need it:
Update docker image tag in the manifest files for release v1.22.0
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

/override openlab/cloud-provider-openstack-e2e-test-csi-cinder

/lgtm

@lingxiankong for lint charts ,dont we need to update the chart version?

/override openlab/cloud-provider-openstack-e2e-test-csi-cinder

/test all

/test all

/test all

/test all

@lingxiankong for lint charts ,dont we need to update the chart version?

This PR is for release-1.22 branch, the chart version is bumped here https://github.com/kubernetes/cloud-provider-openstack/pull/1627

/test all

@lingxiankong for lint charts ,dont we need to update the chart version?

This PR is for release-1.22 branch, the chart version is bumped here #1627

@lingxiankong Need version bump on this branch as well , because of change in charts.yaml. Its complaining https://github.com/kubernetes/cloud-provider-openstack/pull/1626/checks?check_run_id=3354825504#step:7:33

/lgtm
/approve

/override openlab/cloud-provider-openstack-e2e-test-csi-cinder

/override openlab/cloud-provider-openstack-multinode-csi-migration-test


Module not found: Error: Can't resolve 'handsontable'

Description
I use VUE-CLI and i tried to test HOT for a new project.
I tried to create a sample test table in the about view that the vue cli generates for me.
Though I refer to the example that i found on the official documentation see below :

but when webpack do the compilation it displays the message below :

Failed to compile.
<EMAIL_ADDRESS>Module not found: Error: Can't resolve 'handsontable' in 'C:\laragon\www\table_spreadsheet\node_modules@handsontable\vue\es'

Maybe i did something wrong and i dont know what...
Steps to reproduce

Use VUE-CLI
Install the depedency HANDSONTABLE latest version 4.1.1
launch the SERVE function

Your environment

Vue wrapper version: 4.1.1
Handsontable version: 7.3.0
Browser Name and version: Chrome Version 79.0.3945.130 (Build officiel) (64 bits)
Operating System: Windows 10

hey @codingstuff91
would you be able to send the project .zip to<EMAIL_ADDRESS>

Hi,
Sorry to answer so late.
I found myself my problem.
It was because i didnt import the Handsontable plugin before using it with the vue specific one.

Hi @codingstuff91
Thanks for the information.
So I close the issue.


Serve API using Compojure-API, thus enabling Swagger docs

This LGTM! I'm really excited about this.


Update the tags in specific branch

Update the image tags in the 1.2.x branch
Signed-off-by: Khushboo<EMAIL_ADDRESS>

cc: @innobead


Investigate TRS OpenAPI V3 backwards compatibility

Feature Request
Desired behaviour
Investigate upgrading all of Dockstore or just the TRS implementation to OpenAPI v3.
Open questions:

Does this break swagger-codegen instantly since it does not claim OpenAPI V3 compatibility or does this just mean that swagger codegen will not take advantage of new OpenAPI V3 features?
Do we need to upgrade TRS as well?
How does this affect existing CLI clients?
How does this affect the GUI?
Is it possible for the swagger annotations we are using currently to output both a V2 and V3 OpenApi?

Last I heard about v3 codegen: https://github.com/swagger-api/swagger-codegen/issues/6598#issuecomment-352205669

One option to consider, serving up an automatically converted description?
https://github.com/ga4gh/data-object-service-schemas/pull/40/files

Ran an openapi 3.0 swagger.yaml with the swagger codegen both 2.3.1 and 3.0.0 snapshot and it encounters errors.
Might as well
Not sure, will need to use new annotations and core
Would completely break trying to swagger codegen an openapi 3.0 spec unless we keep the old one.
Doesn't look like it https://github.com/swagger-api/swagger-core/wiki/Annotations-2.X vs https://github.com/swagger-api/swagger-core/wiki/Annotations-1.5.X

Notes:

Our TRS swagger 2.0 yaml can be easily converted to openapi 3.0 using swagger2openapi.  That can probably be placed on smart api without issues.

I think I'd like to see a deeper, more granular look at our options here.
Use the oicr wiki for this report, thanks!

Investigation done.  Remaining tasks:

Auto-generate TRS openapi.yaml via npm openapi2swagger within Travis
Auto-generate Dockstore openapi.yaml using maven

Could you also link the document you presented in the demo here?

https://docs.google.com/document/d/1V1Y7aSa1D_e5l7ON4AFR4Y7AdOWuJClNmpVwYafaa8A/edit?usp=sharing

Thanks for this @denis-yuen! I think switching the v3 might be premature, the tooling is still catching up. That being said, the v2 -> v3 conversion is painless and automatable as you've shown. As a developer, I would prefer to have swagger v2 available based on current tooling. What are the benefits of going v3 versus v2 at this point?

@david4096 we were mostly investigating from a "how difficult would it be to upgrade to OpenAPI 3" to directly support SmartAPI POV. It looks like it would be pretty difficult and breaks a lot of tooling, so we're going with the "provide a swagger v2 directly and a converted v3 description" strategy
We didn't actually investigate whether there are new exciting features of OpenAPI v3 that would make the conversion more compelling (but we probably should have, given more time)

Automated conversion from swagger.yaml to openapi.yaml now exists for Dockstore as part of the maven build
Working with a deploy key running in Travis TRS in that repo


prometheus-frr-exporter: init prometheus exporter module

Description of changes
Prometheus exporter module for frr-exporter (see #309442)

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I'm not quiet sure how to test this properly. I tried to rename the prometheus/exporters.nix, but I can't get it working.

I tested the module by cherry picking it onto my local nixos-24.11 branch and it works as I expected.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 313651

x86_64-linux

:fast_forward: 1 package blacklisted:

nixos-install-tools

@ofborg test prometheus-exporters

https://github.com/ofborg test prometheus-exporters


Append part of device MAC ID to the hotspot AP name to make them unique

To avoid problems connecting to devices when multiple of them have hotspots enabled nearby we need to use unique AP names.
One solution is to append the last two bytes of the device MAC to the AP name such as GaisaSargs03AB or GaisaSargs-03AB here:
https://github.com/open-lv/air-guard/blob/bd06151d986bbe80923d18c140d2af601c506134/firmware/micropython/sargs.py#L291

Can be done here https://github.com/open-lv/micropython/blob/39bf805c69e84e9c77e767989de3cdb7921e35e2/ports/esp32/boards/AIRGUARD/modules/network_manager.py or directly in sargs.py.

Fixed in https://github.com/open-lv/air-guard/commit/995cdb4d79f742ae6de5641e2b2abca483565a75


Android ExoPlayer video/poster display issue

Current behavior
I don't know why my video play wrong position. Video is playing at the top and poster or something display at bottom like picture below.
Expected behavior
Video play fullscreen.
Platform
Which player are you experiencing the problem on:

Android ExoPlayer
"react-native-video": "^3.2.0",
"react-native": "^0.47.2",

Image

@pqminh Were you able to fix this issue? I'm having the same problem,


WebUI generated the audio,but can not play it.

Self Checks

[X] This template is only for bug reports. For questions, please visit Discussions.
[X] I have thoroughly reviewed the project documentation (installation, training, inference) but couldn't find information to solve my problem. English 中文 日本語 Portuguese (Brazil)
[X] I have searched for existing issues, including closed ones. Search issues
[X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
[X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
[X] Please do not modify this template and fill in all required fields.

Cloud or Self Hosted
Self Hosted (Source)
Environment Details
CentOS7, python=3.11, torch==2.4.1+cu124 torchvision==0.19.1+cu124 torchaudio==2.4.1+cu124,gradio=5.7.0
Steps to Reproduce
1.Run the WebUI
python tools/webui.py \
 --llama-checkpoint-path checkpoints/fish-speech-1.4 \
   --decoder-checkpoint-path checkpoints/fish-speech-1.4/firefly-gan-vq-fsq-8x1024-21hz-generator.pth

2.Synthesize audio based on TEXT and Reference Audio on webUI
Prepare and configure the “Input Text”、“Reference Audio”, then click the “Generate”.
✔ Expected Behavior
WebUI I can synthesize the audio and can play on this webpage.
❌ Actual Behavior
While in the WebUI I can synthesize the audio,but can not play, except I download the audio file to localhost.
I have read the 《 webui is failed to generate audio, no error reports on the backend log #610 》，but there is no answer.

GPU type: NVIDIA A10

The WebUI log：
2024-11-28 01:44:26.544 | INFO     | tools.api:encode_reference:167 - Loaded audio with 5.42 seconds /myplc/.aigc/miniconda3/envs/fish-speech/lib/python3.11/site-packages/vector_quantize_pytorch/residual_fsq.py:170: FutureWarning: torch.cuda.amp.autocast(args...)is deprecated. Please usetorch.amp.autocast('cuda', args...)instead.   with autocast(enabled = False): 2024-11-28 01:44:26.802 | INFO     | tools.api:encode_reference:175 - Encoded prompt: torch.Size([8, 117]) 2024-11-28 01:44:26.805 | INFO     | tools.llama.generate:generate_long:759 - Encoded text: 这学校真不是一般的寒酸，统共只有一幢楼房，两层高，楼下是教室，楼上是办公室。 2024-11-28 01:44:26.806 | INFO     | tools.llama.generate:generate_long:759 - Encoded text: 六间教室，一年级和二年级八个班的学生只能轮番上课，读到三年级就直接送到工厂里去实习，找不到实习单位就在家睡觉，搞得像山区小学一样。 2024-11-28 01:44:26.807 | INFO     | tools.llama.generate:generate_long:759 - Encoded text: 该校没有操场，体育老师倒有三个。 2024-11-28 01:44:26.807 | INFO     | tools.llama.generate:generate_long:777 - Generating sentence 1/3 of sample 1/1   0%|                                                                                | 0/3914 [00:00<?, ?it/s]/myplc/.aigc/miniconda3/envs/fish-speech/lib/python3.11/contextlib.py:105: FutureWarning:torch.backends.cuda.sdp_kernel()is deprecated. In the future, this context manager will be removed. Please seetorch.nn.attention.sdpa_kernel()` for the new context manager, with updated signature.
self.gen = func(*args, **kwds)
5%|██████▎                                                                                | 177/3914 [00:08<03:05, 20.16it/s]
2024-11-28 01:44:35.657 | INFO     | tools.llama.generate:generate_long:832 - Generated 179 tokens in 8.85 seconds, 20.23 tokens/sec
2024-11-28 01:44:35.658 | INFO     | tools.llama.generate:generate_long:835 - Bandwidth achieved: 10.00 GB/s
2024-11-28 01:44:35.658 | INFO     | tools.llama.generate:generate_long:840 - GPU Memory used: 1.38 GB
2024-11-28 01:44:35.658 | INFO     | tools.llama.generate:generate_long:777 - Generating sentence 2/3 of sample 1/1
2024-11-28 01:44:35.661 | INFO     | tools.api:decode_vq_tokens:189 - VQ features: torch.Size([8, 178])
8%|██████████▉                                                                                | 287/3685 [00:14<02:53, 19.59it/s]
2024-11-28 01:44:50.460 | INFO     | tools.llama.generate:generate_long:832 - Generated 289 tokens in 14.80 seconds, 19.53 tokens/sec
2024-11-28 01:44:50.460 | INFO     | tools.llama.generate:generate_long:835 - Bandwidth achieved: 9.66 GB/s
2024-11-28 01:44:50.461 | INFO     | tools.llama.generate:generate_long:840 - GPU Memory used: 1.54 GB
2024-11-28 01:44:50.461 | INFO     | tools.llama.generate:generate_long:777 - Generating sentence 3/3 of sample 1/1
2024-11-28 01:44:50.464 | INFO     | tools.api:decode_vq_tokens:189 - VQ features: torch.Size([8, 288])
2%|██▊                                                                                | 68/3375 [00:03<02:48, 19.60it/s]
2024-11-28 01:44:54.086 | INFO     | tools.llama.generate:generate_long:832 - Generated 70 tokens in 3.62 seconds, 19.32 tokens/sec
2024-11-28 01:44:54.086 | INFO     | tools.llama.generate:generate_long:835 - Bandwidth achieved: 9.55 GB/s
2024-11-28 01:44:54.087 | INFO     | tools.llama.generate:generate_long:840 - GPU Memory used: 1.64 GB
2024-11-28 01:44:54.088 | INFO     | tools.api:decode_vq_tokens:189 - VQ features: torch.Size([8, 69])
/myplc/.aigc/miniconda3/envs/fish-speech/lib/python3.11/site-packages/gradio/processing_utils.py:738: UserWarning: Trying to convert audio automatically from float32 to 16-bit int format.

warnings.warn(warning.format(data.dtype))`


Static transformations missing when running the multiple camera example

System Configuration

Version
Your Configuration

Operating System
Ubuntu 16.04.1 LTS

Kernel
4.4.0-45-generic #66-Ubuntu SMP

Backend
v4l

ROS
kinetic

ROS RealSense
1.5.0

librealsense
1.11.0

Camera Type-Firmware
r200-<IP_ADDRESS>

Expected Behavior
The static transformations for both cameras should be found in the tf tree.
Actual Behavior
When running the r200_nodelet_multiple_cameras.launch only one of the cameras is able to publish it's static transforms. This probably happens because the nodelet manager will have to latched publishers to tf_static, one per camera, and that does not work correctly, as explained here:
http://wiki.ros.org/tf2/Migration#Addition_of_.2BAC8-tf_static_topic
Steps to Reproduce
Start the r200_nodelet_multiple_cameras.launch and check the tf tree. This can be done doing:
$ rosrun tf tf_echo camera2_link camera2_depth_optical_frame
$ rosrun tf tf_echo camera1_link camera1_depth_optical_frame

You will see the camera2 frames being correctly resolved but the camera1 frame missing.

This is related (or even a duplicate of) https://github.com/intel-ros/realsense/issues/120

@tulku As you figured out, since this is a duplicate of #120, I am closing this one. Please look out for updates on the other thread.


Tree traversal implementation scala

Sorry, it's been a while since the PR started. It kind of fell off my radar for a bit. Hope you can look at it again.
Thanks


Add type hint stub

Fixes #779
Changes

Add py.typed file stub
Include the file into package data

This breaks torchvision pretty hard: https://app.circleci.com/pipelines/github/pytorch/vision/20354/workflows/861e7e2c-4e0b-4594-9d81-33f0b2d27f43/jobs/1655543
Found 299 errors in 26 files (checked 219 source files)

I haven't looked in detail, but some of the errors don't seem to be a usage error. I'll keep you posted.

An example where I don't think we are responsible
from typing import BinaryIO, Tuple
import pathlib

from torchdata.datapipes.iter import FileLister, FileOpener, IterDataPipe, IterableWrapper

def load(path: pathlib.Path) -> IterDataPipe[Tuple[str, BinaryIO]]:
    if path.is_dir():
        dp = FileLister(str(path), recursive=True)
    else:
        dp = IterableWrapper([str(path)])
    return FileOpener(dp, mode="rb")

Running mypy on this yields
main.py:11: error: Incompatible types in assignment (expression has type "IterableWrapperIterDataPipe",
variable has type "FileListerIterDataPipe")  [assignment]
            dp = IterableWrapper([str(path)])
                 ^
main.py:12: error: Incompatible return value type (got "FileOpenerIterDataPipe", expected
"IterDataPipe[Tuple[str, BinaryIO]]")  [return-value]

The actual function is a little more complicated and we can't use FileOpener as return type, whereas IterDataPipe[Tuple[str, BinaryIO]] is true for all cases.
Could you advise how you want us to annotate? Can we maybe revert this PR and resolve all issues that this brings to torchvision before we merge a second time?

@pmeier
At list for the first Error, the proper typing should be:
def load(path: pathlib.Path) -> IterDataPipe[Tuple[str, BinaryIO]]:
    if path.is_dir():
        dp: IterDataPipe = FileLister(str(path), recursive=True)
    else:
        dp = IterableWrapper([str(path)])
    return FileOpener(dp, mode="rb")

However, even with the proper typing shown above, the Error is changed to Incompatible types in assignment (expression has type "FileListerIterDataPipe", variable has type "IterDataPipe[Any]"). And, it doesn't explain what causes the second Error.
So, I spent a few hours figuring out what is the root cause of the mypy Error. In the generated datapipe.pyi file, a new IterDataPipe class is defined, which overrides the original IterDataPipe from the inheritance graph for all other DataPipe.
All Errors are eliminated when I remove new IterDataPipe definition from datapipe.pyi  and import IterDataPipe directly from torch.utils.data.datapipe. And, the reason we define new IterDataPipe in pyi file is attaching all functional APIs to it. We need to do it in a different way by keeping the original IterDataPipe and extending the class with all functional APIs.
cc: @NivekT for python interface file
For this PR, I will revert it because our typing system needs to be fixed generally.


pin nightly to 2022-11-28 to fix miri

Objective

pin nightly to 2022-11-28 to fix miri

I bumped the version of concurrent queue to clear the cache. Let me know if there's a better change I can make to have the same effect.

bors r+


[BUG]Jumanji RWARE reward shape mismatch

We found that in the 4ag RWARE task, env.reward_spec().generate_value() gives something of shape (), but the reward that environment outputs is actually of shape (num_agents).
This is curious because I believe the scenario should output a reward of shape ().
Maybe it's a wrapper thing?

Thanks Louise looks like this is a bug, we duplicated the reward and discount but never update the specs, my vote is to just not duplicate it and add a dummy agent dim so everything behaves the same.


Marlowe Suite - Fix loan contract

This PR fixes the loan contract, the amount and interested were mixed up, and you ended up borrowing the interest and paying the amount + interest
Pre-submit checklist:

Branch

[ ] Tests are provided (if possible)
[X] Commit sequence broadly makes sense
[X] Key commits have useful messages
[ ] Relevant tickets are mentioned in commit messages
[X] Formatting, materialized Nix files, PNG optimization, etc. are updated

PR

[X] Self-reviewed the diff
[X] Useful pull request description
[X] Reviewer requested

Another PR fixed this issue


[WIP] Make MVar consistent with Cats-Effect impl

See discussion at #710
Quick sketch showing how using cats-effect implementation could look like.
Note that we lose withPadding constructors.
It is easy to do it also for AsyncVar but it will be essentially using MVar and running it every operation.
I'd rather stay with AsyncVar as is because if someone needs it with Future he can't use MVar anyway (needs to be Async / Concurrent). And if someone needs those semantics before we update implementation he can wrap it quite easily.

BTW I'm trying to add atomic reads to AsyncVar but I don't make any promises. x)

@alexandru @oleg-py
I managed to do it, the only difference between Cats-Effect is that it doesn't support nulls because it uses them (I guess for performance reasons?) internally instead of Option.
I don't know if there are any benefits over Cats-Effect version apart from padding constructor. Let's decide what we do with MVar and I can either remove it or finish implementation (scaladocs and review)


Custom event > releases payload does not contain secret

Gitea version (or commit ref): 1.5.2
Git version: 2.9.3
Operating system: CentOS
Database:

[x] SQLite

Can you reproduce the bug at https://try.gitea.io:

[x] Not relevant

Description
When setting up a gitea webhook, one can provide a secret that is supposed to be included in the delivered POST application/json payload. This works fine for "Push Events", however when choosing "Custom Events..." and selecting "Releases", this secret is not included in the payload anymore.

I just tested the latest version 1.6.0-rc2 and it seems like this issue is still not resolved. Now, if I trigger a test delivery for a custom event of the type release, no request is queued whatsoever.

Could you explain "trigger a test delivery"? I tried to retrace your steps but couldn't find the same error

I simply press the "Test Delivery" button :)

Okey, but it looks to me as if the TestDelivery is always executing a push event. If your webhook only acts on releases it will not be triggered. routers/repo/webhook.go:677

My intuition was that the button tests whatever hook is specified at the top?!
Anyways, I had to put a new request bin, here the link to inspect it http://requestbin.net/r/wy4b3rwy?inspect
I pushed a tag (release) to the repository under https://try.gitea.io/test1337/Hooktest and it did not trigger a request to the request bin. So something seems to be broken, no?

@AuspeXeu tag without release in release list page is displayed differently

release will be triggered when you create release (either by UI or API) either on new tag or existing. Pushing tag from git command will not create release, this is by design so

Okay, I guess it's all working correctly then in that case.

Closeable?

I guess so :) - thanks for your efforts!

Test delivery will always issue push event

Why? :D

Because it is just for testing if target can be reached not to test actual functionaliity

Well, but exactly this is not happening. If you set the hook to custom event as I showed above, and then press "test delivery" nothing happens. It claims that a fake event has been generated but no request ever reaches the specified endpoint.

Ok, now I understand the problem. It is tested if event type is enabled before sending. This would require option to choose what kind of event to send then and implement each event type webhook content generation. I don't think that is worth time needed to develop this the gains.

Well, if we could at least have a delivery test that would be great :) One option could be, as you said, to always send a push event type. That way one could at least verify that the endpoint is reachable, no?

If you enable push events and then try test delivery than it will work and do request. Later you can disable it again

Basically my point is, if someone is new to gitea and sets up a custom event webhook, they will wonder why the test delivery does not work unless the read this particular issue with our comments.

We could probably add warning if push event is not enabled

Whats the state of this issue?

Secret inside the payload has been deprecated, and the hmac header of webhook should now be used. Closing this issue.


Change how FIR filters detect the end condition

This PR is a follow-on to #33 (and this contains the same commits as that PR, because I couldn't figure out how to make a PR to merge this into that). But, it's conceptually different so I probably not worth combining the PRs.
So I think we can move the finish condition into the FIR filters by calculating how many more samples we could have produced. If the input is finished, and the core could not have produced more samples (even if it had room), then I think we can finish the block?
If so, this'll make resampling filters work a bit easier, eventually.

Thanks, I was also thinking about this issue recently. I think giving back concrete numbers might not always be straightforward and is also not really needed. How about returning an enum with BlockedIn, BlockedOut, and Done to indicate that the input/output was the limitation or if everything could be processed?
Since this includes the other PR, I'd wait for this discussion and merge this PR, if that's fine for you.

How about returning an enum with BlockedIn, BlockedOut, and Done to indicate that the input/output was the limitation or if everything could be processed?

Okay, yeah that makes sense. I'm not entirely sure though what the right enum names are - Done in particular doesn't always apply, since it could happen even if the block isn't finished. What about InsufficientInput, InsufficientOutput, and BothSufficient?

Thanks, I don't have better suggestions for the names. I'd say, we just go for it.


Support multiple schemas with a single vttablet

Highlights from a conversation today with @sougou and @bbeaudreault

It would be really nice if a single vttablet could work with a database with multiple schemas. We have ~40 that fit into that and will need to do manual migrations to work towards vitess. vttablet is a mysql sidecar not a db sidecar.  things like reparenting don't make sense on just a single db of a mysql. @bbeaudreault

Thoughts from @sougou

the part i know will work is query serving (edited)
but cluster management will have pitfalls, and will have to be tested and iterated upon
the _vt name is mostly parameterized
but we'll have to see how things like backup/restore, reparent, etc. are modeled
query serving is mostly isolated. You can run multiple query services within one process. That's how vtcombo works.
Some things will still have to be done, especially on exported URLs, which may not be hard. For example /debug/vars

My use case is to have a unified MySQL cluster on the backend. Each set of shared microservices would only have access to their own schema using Vitess ACL, so they are logically separated. Behind the scenes, we could still enforce referential integrity across schemas for tenant, user or other shared ids.

@alainjobart and I had a little brainstorm about this:
We agree that this is a legitimate use case, and think that it should be addressed by Vitess.
The best approach is along the lines of what @bbeaudreault suggested: a single vttablet serves all the schemas of a give mysql. In this respect, this was the essence of our discussion:

The concept of a keyspace changes: Instead of being a group of tables that share the same sharding scheme, it becomes a group of databases that share the same sharding properties.
Applications are agnostic of keyspaces. They connect to a database. This database is then routed based on the keyspace it belongs to.
As before, the name of the mysql database is configurable in the topo.
When vtgate sends queries to vttablet, it rewrites them with table names qualified by the corresponding mysql database name. The queries will become less recognizable. We can look at tweaks to preserve this in the future.
The keyspace is something only an operator has to deal with when performing maintenance work.

This concept is backward compatible with the current design:

Every keyspace has only one database.
A keyspace is also used as a database name.

However, work must be done to push the new concepts down into the code. Places that assume only one database have to be changed to handle multiple. Once all the code is in place to handle the new design, we can open up configs to support multiple databases per mysql.
Since this is substantial work that involves touching of multiple components, volunteers are welcome, especially in the area of cluster management and resharding.


nixos/collectd: Fix syntax error on some hostnames.

Motivation for this change
I wanted to monitor a host with the hostname "helper-us-west1". This hostname causes syntax errors if unquoted.
Things done

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

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Tested on live machines.
Without this, hostnames that e.g. end in digits will cause syntax errors for
collectd.

Thanks! :beers!


Event not bubbling through Sprite

Hey guys, I'm not sure if this is a bug or an intended functionality change. In 4.4.1, my use case flow is as follows.

Make sprite graphics cover entire screen
Draw hole in graphics
Perform hit test if input is in hole (do nothing, allow event to bubble)
If outside of hole, use 'event.stopPropagation()'

This works fine, if the click is inside the hole, then anything inside that hole, (underneath in the display list) then it also captures gets triggered.
However after upgrading to 4.5.0, the event does not bubble through the sprite, and it's input handler is eating the object. When inspecting, the event, it looks like the current target is null, which is not what I would normally expect?

Between 4.4.1 and 4.5.0, we made a few patches that fixed situations where mouse ups and clicks were improperly happening when they should not. Is it possible that your use case was dependent on that bug?

Haha, quite possible! In that case, if you had two sprites, of the same size (eg 100x100) directly stacked on top of each other, and both had interactivity.. If you clicked on the top one, would you expect the one underneath to catch the click?

The answer to that question is indeed no.
It sounds like a solution could be a new hit testing method that gets all interactive children under a single point, without firing events (to be performed by the dev on the InteractionManager's click event).
Another solution could be to manually hit test against specific things upon click events on a given sprite on top.

Okay, I understand. I didn't realise that the event won't bubble to those children not in the display order tree. You can go ahead and close this! Sorry for the false alarm.


Flashing issue - SPI flash detection

Hi,
A friend & I are turning made trying to fash an ESP-32S module. We managed only once and now can't get anything working.
We do force GPIO0 to low, and manually toggle the EN line.
ESPTool correctly detects the bootloader, gets in download mode and is able to 'discuss' with the bootloader to for example, get the chip_id, mac & sta addresses, ...fuse etc.
But when it tries to detect the SPI flash, it fails, and consequently isn't able to download any firmware.
In normal user mode, on a terminal, the ESP32 keeps rebooting with

flash read err, 1000
Falling back to built-in command interpreter.
OK
ets Jun  8 2016 00:22:57
...
...

We have tried the ESP GUI Flash tool as well - same thing, com with ESP32 is fine, but it is as if the SPI Fash would be dead.
We have tried the MTDI pin forcing too. Using FTDI, CP2102 cables...
We have this on 2 branch new modules (1 of which we managed to flash once only)...
Any idea on what we can do as we are stuck ...
We are almost at a point, we are thinking of decapsulating the module and swap the flash to see...
Thanks for your help !
PyB

Hi PyB,
The "flash read err, 1000" error means the first stage ROM bootloader failed to read a valid image header for the second stage software bootloader (at offset 0x1000)
The usual reasons for this are:

Flash encryption was enabled in config and the the first flash succeeded, but now the bootloader expects to see an encrypted header (re-flashing writes a plaintext header.)
Nothing has been flashed to offset 0x1000 (either because secure boot is mistakenly enabled. which disables flashing of the bootloader by "make flash", or because of a mistake in the esptool command line.)
The thing flashed to 0x1000 was not bootloader.bin.
There are power stability problems causing the flash to brown out at that moment. This can be an issue with programming bare modules without a supporting PCB, especially if the 3.3V supply is inadequate (the built-in 3.3V regulator of a USB to Serial chip is not adequate) or if there isn't enough capacitance on the module.
The MTDI pin is driven high on reset which has caused to go into 1.8V mode, and it's browning out.

Finally, under some circumstances it seems like there are SPI flash chips which are slow to come out of reset and therefore mis-read when the ESP32 ROM first reads them. However I wouldn't expect this problem with ESP32S modules, even though they're a third party module I have a few and they all work fine.

Hi PyBerger, is this problem still unsolved?


Project status

Sorry I create an issue for this but I don't see any recent activity with a bunch of good PRs done.
Is this project maintained or not? If not, would you add somebody as contributor or pass membership?

Anybody???

@ryanwinchester  and anyone I would recommend to move to https://github.com/KamilLelonek/exnumerator
At the end of the day, there is only one reason to use this package (when you want to use enum at the database layer), that is a good and bad thing depending of many factors.
But I would argue that for 98% of time you don't need this and it's just fine to use something like exnumator

Thanks @yordis I'm just using my fork for now :)

I reached out to the maintainer (email in in git log) about a month ago and did not get an answer...
I don't have high hopes for this project to continue.

😥 yeah

It's not that hard to use postgres enum types without this library, actually. Here's an example https://github.com/idi-ot/ecto_enum_postgres

@yordis @ryanwinchester @leifg I've just published latest Ecto 1.1 which only loosens dep requirements which was one of the main issues. Was on sabbatical from software development and back now.
@yordis what good PRs are you referring to btw?

@idi-ot the point of this library is that you no longer have to manually set that up for your project. It does some metaprogramming underneath to generate similar code as above.

@gjaldon I know (actually, I think the code I posted here is a bit more clean than that in the library, would you accept a PR?). I just want people to know that there is a simple way to use eum types with ecto without any additional libraries.

@idi-ot the library does metaprogramming so it won't be as clean as code without metaprogramming. Another advantage of this lib is that you may define multiple custom Enums in just a few lines of code. The library is small and focused and does what it needs to do without much fuss.

I meant that it's both cleaner and more efficient to define a lookup table out of multiple function heads, than to use a literal map, which is the current approach.

@idi-ot ahh did not realize that's what you meant! Don't know about the efficiency. Haven't really looked into refactoring it. It does seem cleaner. PR is welcome and would be happy to merge if it ends up cleaner 👍

Feel free to reopen if this needs to be revisited

@gjaldon on efficiency: https://github.com/idi-ot/ecto_enum_bench
Finished in 49.56 seconds

## EnumBench
benchmark name  iterations   average time
load custom       10000000   0.20 µs/op
load ecto_enum    10000000   0.25 µs/op
dump custom       10000000   0.31 µs/op
cast custom       10000000   0.32 µs/op
cast ecto_enum    10000000   0.60 µs/op
dump ecto_enum    10000000   0.79 µs/op
## IntBench
benchmark name  iterations   average time
load custom      100000000   0.04 µs/op
load ecto_enum    10000000   0.11 µs/op
dump custom       10000000   0.34 µs/op
cast custom       10000000   0.34 µs/op
cast ecto_enum    10000000   0.81 µs/op

In absolute terms, the difference is almost non-existent, but in relative -- lookup table out of functions is twice as fast as literal map.

dump ecto_enum didn't finish since it raised (should've returned :error instead according to ecto type spec):
** (exit) an exception was raised:
    ** (Ecto.ChangeError) `"akjsdfgh"` is not a valid enum value for `EctoEnumIntStatus`. Valid enum values are `[1, 2, 3, 4, :registered, :active, :inactive, :archived, "active", "archived", "inactive", "registered"]`
        lib/ecto_enum_int_status.ex:2: EctoEnumIntStatus.dump/1
        bench/int_bench.exs:97: IntBench."bench: dump ecto_enum"/3
        (stdlib) timer.erl:197: :timer.tc/3
        lib/benchfella.ex:313: anonymous fn/7 in Benchfella.measure_n/6


Install doctrine/doctrine-bundle to use the ORMAdapter

Hi guy,
Thank you for your great work on this bundle, it's looking awesome.
Actually i'm trying this just for me and i have the errror "Install doctrine/doctrine-bundle to use the ORMAdapter". And i don't understand why.
doctrine/doctrine-bundle is already in my appkernel.php, so i don't understand why it's not working.
You can show my code below.
AppKernel.php
$bundles = [             new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),             new Symfony\Bundle\SecurityBundle\SecurityBundle(),             new Symfony\Bundle\TwigBundle\TwigBundle(),             new \Omines\DataTablesBundle\DataTablesBundle(),             new Symfony\Bundle\MonologBundle\MonologBundle(),             new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),             new Doctrine\Bundle\DoctrineBundle\DoctrineBundle(),             new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),             new AppBundle\AppBundle(),         ];
and here my controller where i try to create a dataTable
`public function indexAction(Request $request)
{
$table = new DataTable();
$table
->add('firstname', TextColumn::class)
->add('lastname', TextColumn::class)
->add('email', TextColumn::class)
->add('phone', TextColumn::class)
->add('age', TextColumn::class)
->createAdapter(ORMAdapter::class, [
'entity' => User::class]
);
    $table->handleRequest($request);

    if ($table->isCallback()) {
        return $table->getResponse();
    }

    return $this->render('dataTableIndex.html.twig', ['dataTable'=>$table]);
}`

Best regards

Hi, can you provide more details?
Symfony version, datatables-bundle version, etc.
Thanks!
Giovanni Albero
+393661860916
<EMAIL_ADDRESS>full-stack developer
Skype: giovanni.albero
Linkedin: https://it.linkedin.com/pub/giovanni-albero/64/465/bba
Twitter: @albero92

As noted in the docs:

After installation, if not using Flex, you should register the bundle to your kernel, commonly AppKernel.php, before your own bundles but after the required external bundles, such as FrameworkBundle and TwigBundle.

You are currently loading DoctrineBundle after ours, and as it registers the doctrine service alias during compilation that we depend on to inject into the adapter this makes it sensitive to order of loading.
I believe this was fixed in Symfony 4 due to how Flex works.

Do you have doctrine service in your container (you can do a check in a controller)? Try to add to your service.yaml
doctrine:
    alias: 'doctrine.orm.default_entity_manager'

ok , i don't know what happen, i just test an array Adapter this morning and when i came back on ORMAdapter the error has disapear.
And i also disable all datatable config in my config.yml.
Now i try to display my table but i don't now if i need to make a template or if the bundle construct the table :)
Sorry for my beginner questions :)
best regards

i think i need to sleep, i just forgot to load JQUERY in my project...
Thank's a lot for your help, all is fine now.
Best regards

Lol ok, good to hear it's fixed 🎉


disable amp for pytorch_fx, pytorch quantization, whose quantization …

…module does not support bf16 input
Signed-off-by: Wang, Yi A<EMAIL_ADDRESS>What does this PR do?

Fixes # (issue)
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

@echarlaix @PenghuiCheng please have a review of it

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Idea: args shortening

Can we do shortening like --playbook = --playbooks, --script = --scripts etc. then?

tmt plan --hel
Usage: tmt plan [OPTIONS] COMMAND [ARGS]...
Try "tmt plan --help" for help.

Error: no such option: --hel  Did you mean --help?

For command shortening I needed to do this.
Originally posted by @psss in https://github.com/psss/tmt/timeline

Yeah, definitely +1. We already have a story for this. Just to implemet it ;-)


Move to rust 2021

WIP cargo fix --edition gives:
    Checking finality-grandpa v0.14.4 (finality-grandpa)
   Migrating src/lib.rs from 2018 edition to 2021
error: internal compiler error: compiler/rustc_middle/src/ty/subst.rs:534:17: type parameter `N/#2` (N/2) out of range when substituting, substs=[SignedMessage<H, N, Signature, Id>, std::alloc::Global]

thread 'rustc' panicked at 'Box<dyn Any>', /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/compiler/rustc_errors/src/lib.rs:1093:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.56.1 (59eed8a2a 2021-11-01) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [adt_significant_drop_tys] computing when `round::Round` has a significant destructor
#1 [has_significant_drop_raw] computing whether `round::Round<<E as voter::Environment<H, N>>::Id, H, N, <E as voter::Environment<H, N>>::Signature>` has a significant drop
end of query stack
error: could not compile `finality-grandpa`
warning: build failed, waiting for other jobs to finish...
thread 'rustc' panicked at 'Box<dyn Any>', /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/compiler/rustc_errors/src/lib.rs:1093:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.56.1 (59eed8a2a 2021-11-01) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [adt_significant_drop_tys] computing when `round::Round` has a significant destructor
#1 [has_significant_drop_raw] computing whether `round::Round<<E as voter::Environment<H, N>>::Id, H, N, <E as voter::Environment<H, N>>::Signature>` has a significant drop
end of query stack
error: build failed

That was probably caused by some compiler bug. I tested now and didn't have any issues, only needed to make a small change in a test.