Comparison of Versions also compares build metadata

Hi! This code:
use semver::Version;

fn main() {
    let a = Version::parse("0.0.0+a").unwrap();
    let b = Version::parse("0.0.0+b").unwrap();
    dbg!(a.cmp(&b));
}

currently prints
[src/main.rs:6] a.cmp(&b) = Less

According to SemVer 2.0.0 # 10, comparing versions should ignore build metadata. Including it in this comparison also create an inconsistency with VersionReq and makes cargo consider version change from 0.0.0+b to 0.0.0+a downgrading.
Crate documentation also suggests that implementation of Ord for BuildMetadata is only to allow comparing two BuildMetadata values and shouldn’t affect versions.

Ord worked the opposite way in versions 0.11 and older of this crate, and it was undesirable. See #108. Both behaviors are undesirable/confusing in different ways. I think my perspective agrees with https://github.com/dtolnay/semver/issues/108#issuecomment-521762577: the spec says 0.0.0+a and 0.0.0+b have the same precedence for the purpose of selecting which versions satisfies a particular version req during version selection, but precedence is not the operation that cmp implements.

Should it be considered a bug in cargo then? I’d say that calling version change “downgrading” assumes that the new version has lower precedence (it’s also just generally weird, given that build metadata is often stuff like git commit hashes, which are not comparable).

I created https://github.com/rust-lang/cargo/pull/12796 to change the message in Cargo.


Session Loss on Tab Switch in Langflow

Bug Description
I'm still losing sessions from time to time in langflow.
This is happening constantly when I switch tabs;
Reproduction
https://jam.dev/c/03826c9f-dde7-4c2d-a9b3-cefac0c396df
Using the default values for the token auth
Expected behavior
Keep in the session,
Who can help?
@Cristhianzl
Operating System
Ubuntu Linux 22.04
Langflow Version
1.0.14
Python Version
3.10
Screenshot
No response
Flow File
No response

Hi,
Please check if the error occurs after this PR: #3076


Drop Go <1.18

This is useful because we can use generics. For example, #252 is gonna be a bit tricky to integration test in part because it would require build tagging a bunch of things. And we can also use generics internally which will probably have at least a little value.
None of this is urgent if people are still using older Go though. @csilvers or @dnerdy, have y'all upgraded to 1.18 yet? Any other users who are still on 1.17 or below?

Another reason to get to 1.18 is so we can put our version in easily (i.e. finally do the thing that #127/#129 wanted to) via runtime.DebugInfo.

@benjaminjkraft We are in the process of upgrading to Go 1.19 from Go 1.16, but that has not been completed yet.

@benjaminjkraft We are in the process of upgrading to Go 1.19 from Go 1.16, but that has not been completed yet.

(I expect it will be completed in 1-2 weeks.)
That said, we have no plans to upgrade our genqlient before our go1.19 upgrade is complete, so I don't think landing this PR needs to block on us!


fix codacy on master

one could find all coding style problems here:   (GO TO MASTER BRANCH!!)
https://app.codacy.com/gh/marrlab/DomainLab/dashboard?branch=fbopt  (need login with github)

Click on code style: one get https://app.codacy.com/gh/marrlab/DomainLab/issues?categoryType=CodeStyle&bid=37559465
choose those one could fix and fix them

https://stackoverflow.com/questions/54586757/how-do-i-automatically-fix-lint-issues-reported-by-pylint


"Guide asking for help section needs to move to kivy's website from wiki"

Make asking-for-help guide (community guidelines) more visible on Kivy's main site and the in places where Kivy advertises its freenode chat-room and contact information, etc.

Also, "Community Guidelines" feels like a misleading name here.  I would not have necessarily guessed the sub-sections would be "Asking for Help" and "Conversation Guidelines."

The guidelines are linked from https://kivy.org/docs/contact.html.


Add config to disable dismissal of collapsed drawer

Hello!
Here's a PR to allow users disable dismissal of a drawer view and keep some height of it always on screen.
I think i can reference this issue here.

I really want this too!

I believe this is addressed now with #75 though without a configuration to not dismiss collapsed drawer

I'm going to close this PR since the changes haven't been addressed, there are conflicts, and - as @ilyapuchka has pointed out - this is fixed by another PR.


Version checking

Set up version checking in a similar manner to SMB Explorer

This also should probably involve adding a menu bar at the top of the screen. And let's fix it so that the app opens in full screen mode by default since it is designed for that


1.3.2 Changes

There's a couple of display: block; that were causing small images to break.
@M-Porter @rchen1992

looks good


Webpack support

It looks like the following lines doing dynamic requires is causing problems for webpack because it cannot be statically analyzed:
https://github.com/nodegit/promisify-node/blob/master/index.js#L156

I realize this module is called promisify-node not promisify-js, etc, but just wondering if this dynamic lookup is necessary.

That's sort of the entiregy of how just doing promisify('fs') instead of promisify(require('fs')) works. I'd presume it would pack fine if you used the latter, even with how the code already is, or is that incorrect?

@maxkorp unfortunately, I do not have control over the use of promisify-node because it is being used by a library that I am using, not directly in my code. More importantly, the problem is that webpack does static analysis at build time, not run time so it actually doesn't depend on what the caller actually uses, but what they may use.
The section of code starting at line that I referred to above causes the problem since webpack recognizes the unsupported, dynamic pattern and tries to deal with it by pulling in any possible files in the module including README, package.json, etc.
One could argue it is a webpack problem and on the other hand, it could be argued that dynamic requires are not future proof (I'm sure of the exact details why, but I believe ES6's import may not provide support for dynamic import either so the new import standard is less flexible than Node's require).
If this feature is not actually used in practice (I'm hoping it is just be syntactic sugar that can be easily changed using the solution you suggest), removing the string section lines would solve the problem. If this is a commonly used feature, I'll just continue using my fork where I comment out the lines.

@kmalakoff I think we can fix this by renaming require will you be around anytime soon so we can test this?

@tbranyen I'm here now and for the rest of the evening.

Sure, there is always a way around static analysis.

Understood. I'm going to close this since I have stopped using the library that depends on this one...I'll leave you to it to test if / when a need arises.


CookieSyncManager need to be initialized on API < 21

Unitialized CookieSyncManager causes crash on API < 21

Thanks @PaveLiArcH for the pull request!
Per the CONTRIBUTING.md file displayed when you created this pull request, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
This is a standard procedure for many open source projects. Your form should be processed within 24 hours and reviewers for your pull request will be able to proceed.
Please let us know if you have any questions.
We are very happy to have you join our growing community!

Looks like glitch - i've got no emails from github about any activity except closing PR
@coreyhulen, what can we do now?

@PaveLiArcH just resubmit the PR, i think

Sorry @PaveLiArcH, we typically close PR's if there has been no activity for a period of time. Please feel free to re-submit if you've completed the contributors agreement as above.


Upgrade to kotlin 1.5

Why isn't this being merged?

Because we're not ready to move to kotlin 1.5 yet. Our app uses coroutines a lot and we'll upgrade once the new memory model is ready (which should be soon).


Demo site redirect to spam sites

The Demo site provided in github is redirecting to spam websites. Looks to be compromised.

Hi @NookOps,
Thanks,
I forgot to renew the domain. So I've updated to techgoda.net


gg (move to start) is not working.

OS: Ubuntu 14.04LTS
Atom: 0.124.0
vim-mode: 0.14.0
I've built Atom from source onto Ubuntu 14.04LTS, installed vim-mode with apm, and tried using gg to go to the 1st line and # gg to go to a line # and neither worked.  shift+g, however, works for me.

I believe this currently works; I don't know when it was fixed though. Please let me know if there are still problems with it.

gg is working! I suspect there are some other issues in the key resolver, but I'll make a seperate ticket with more specific details :)


Add LZ4 python dependency

I think it might be better to pin specific dependency version during install

@jurgelenas lz4 should be quite unproblematic. What worries me more right now is that the new container breaks the 2nd step of builds, due to some enforcements of Git sec feature (repo owner user...). Probably because the new build uses a newer version of Git.


Tpi one

This is garbage

Got all backwards with this.  Changed to https://github.com/iterative/dvc.org/pull/3399


sendTToZ

How to fix a periodic error sendTToZ is waiting, too many z_sendmany operations already in progress. ?

Same thing here

Apparently no one knows how to fix this?

same


Reporting error causes no movement of data, Report pdfs  will need to be created

Current Cruise FKt241011 Dive 736, reports failed to build and so although all other exports ran successfully and were written to the local sealog /data/ folder, the code errors out before setting up the rsync to the cruise data since it exits at
https://github.com/schmidtocean/sealog-server/blob/c419f75751b8ab5b1386312f8948a9a5ba0ea158/misc/sealog_vehicle_data_export_Sub.py#L805
Note:
I temporarily forced sealog_vehicle_data_export_Sub.py to run and moved exports to the warehouse  but initially nothing was moved  after  dive tasks ran

Can we add a try to continue around this with a warning logged so that if everything else is created and only the reports error, the data still moves to the cruise data, thus making it available as soon as possible to scientists and allowing us to come back to deal with the missing reports?
Need to determine the issue that caused the report to fail, appears to not have been able to build the graph due to no nav data ...
a. can we fix this for this dive and re run?
b. can we add better handling?

RROR - index 0 is out of bounds for axis 0 with size 0
Traceback (most recent call last):
  File "/opt/sealog-server-Sub/./misc/sealog_vehicle_data_export_Sub.py", line 805, in <module>
    _build_lowering_reports(selected_cruise, selected_lowering)
  File "/opt/sealog-server-Sub/./misc/sealog_vehicle_data_export_Sub.py", line 542, in _build_lowering_reports
    raise(err)
  File "/opt/sealog-server-Sub/./misc/sealog_vehicle_data_export_Sub.py", line 537, in _build_lowering_reports
    file.write(lowering_summary_report.export_pdf())
  File "/opt/sealog-server-Sub/misc/reporting/sealog_build_lowering_summary_report.py", line 136, in export_pdf
    dive_track_filename = self._build_dive_track()
  File "/opt/sealog-server-Sub/misc/reporting/sealog_report_builder_Sub.py", line 1158, in _build_dive_track
    ax_dive_track.plot(lons[0], lats[0], linestyle='none', marker="o", markersize=12, alpha=0.6, c="green", markeredgecolor="black", markeredgewidth=1)
IndexError: index 0 is out of bounds for axis 0 with size 0

The exports script was pretty hard to troubleshoot with a lot of repetitive permanent errors leading techs to elevate most issues.

filecrop lastline hack - downgraded this to INFO level, there was typically >100 lines of this message and to my understanding there is no user-actionable solutions
everything in try blocks
rsync error handling
subprocess.run instead of subprocess.call - more modern and gives output by default
implemented slackbot integration via webhooks - these exports can take considerable time to run thus there is a risk the outcome is not always checked, also supervisorD default view is not ideal for long messages and requires entering custom URL to see full output. Messages are grouped by ERROR/WARNING, repetitive messages are counted and displayed as

• 20:26:06 - Could not process line: <ProductName>APG Atwood</ProductName>
(×54)WARNING -

Currently testing in production
Outstanding:

every dive claims NO WATCH CHANGE events but tables are built
discuss with team whether more messages should be downgraded to INFO
check/resolve when script does/should exit with success/error code

Current successful output:

All outstanding issues resolved, merged to main


Add GitHub Labels and Sync Workflow

Pull Request

Description
Write a short description of the changes made in this pull request.
What changed?
List important changes here. Changes within a file should be an indented bullet point.

#117  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @JackPlowman and the rest of your teammates on  Graphite

Merge activity

Oct 27, 7:20 AM EDT: A user merged this pull request with Graphite.


Multi-channel image registration with large number of channels

I'm having a strange issue when running registration on a multi-channel image. I use the suggested approach in the elastix manual such as:
elastix -f0 channel1_fixed.mhd -f1 channel2_fixed.mhd -m0 channel1_moving.mhd -m1 channel2_moving.mhd ...
where the multichannel image with N channels has been separated into N scalar images.
In SimpleElastix I implement this as:
elastix = sitk.SimpleElastix()
for idx in range(numberOfChannels):
  elastix.AddFixedImage( sitk.VectorIndexSelectionCast(fixedChannelImage, idx))
  elastix.AddMovingImage( sitk.VectorIndexSelectionCast(movingChannelImage, idx))

All works the same with both the SimpleElastix and command line elastix approaches for 6 or less channels.  Meaning, I obtain good registrations, and the metric and gradient are both decaying as expected.
However, when I try to use more than 6 channels, the command line approach still gives good results, but SimpleElastix gives very strange results.  The individual channel metrics and gradients do not decay as expected, and the combined metric is very noisy and does not change much with a large number of iterations. To see what I mean, here are plots of the metric and gradient.  Upper left of each plot is the overall Metric value vs. iteration. Lower left is the overall Gradient magnitude. Upper right shows the metric for each individual component / channel (Metric0, Metric1, etc. from IterationInfo.txt).  Lower right shows the individual gradient for each component / channel.
SimpleElastix, 6 channels:

elastix command line, 6 channels:

SimpleElastix, 7 channels:

elastix command line, 7 channels:

I've reviewed the SimpleElastix code, and can't find anything that might explain this issue.  I don't believe it is memory related, since I can easily run over 20 channels on the command line (these are small, 2D multichannel images in this test case), and can load just as many into memory in SimpleElastix without issue.
Any help on this issue would be much appreciated.  I can also package and send this test case, if that would help?
Thanks,
Geoff

Just a quick update:
I tried the same thing with very tiny images, to make sure it wasn't a memory or floating point issue.  I used the following very tiny images:
  numberOfAttributes = 7
  fixedAttributeImage = sitk.Image([32,32], sitk.sitkVectorUInt8, numberOfAttributes)
  movingAttributeImage = sitk.Image([32,32], sitk.sitkVectorUInt8, numberOfAttributes)
  val = range(numberOfAttributes)
  fixedPixel = [16, 16]
  movingPixel = [17, 17]
  fixedAttributeImage.SetPixel(fixedPixel[0], fixedPixel[1], val)
  movingAttributeImage.SetPixel(movingPixel[0], movingPixel[1], val)

and got similar results (command line elastix works fine, SimpleElastix gives noisy cost/gradient).

Are you using the exact same parameter settings? SimpleElastix is the Adaptive Stochastic Gradient Descent optimizer by default, are you also using this optimizer when running elastix via the command line?

I am not sure what is going on because SimpleElastix is not compiled for vector images. Or perhaps you customized SimpleElastix for that? In any case, yes, can you send a test data + script? That would be very helpful, thanks.

Thanks, Kasper.  To answer your questions:

Yes, I am using the exact same parameter files.  For components <= 6, I get exactly the same result and performance for command line and SimpleElastix (both with StochasticGradientDescent).

I am not using vector images.  Instead, I load in each component as a (scalar) image into the VectorOfImages.  Command line elastix also does not handle vector-valued images.  Instead, one registers a vector-valued image by extracting each component into a scalar image and running:

elastix -f0 channel1_fixed.mhd -f1 channel2_fixed.mhd -m0 channel1_moving.mhd -m1 channel2_moving.mhd ...

For a 2 channel image, for example.
I'll send a small test set through email.

How do you add multiple images in SimpleElastix? Are you using AddFixedImage() and AddMovingImage()? From your code snippet it looks like you create a vector image.

Sorry, I probably did not describe this thoroughly.  In the code, yes, I am using AddFixedImage() and AddMovingImage(). I loop through the component (channel) indices of multi-channeled (vector-valued) fixed and moving images, and use sitk.VectorIndexSelectionCast() to extract each channel, and add them subsequently using AddFixedImage() and AddMovingImage().  I'm preparing to email you the test case shortly.

Here is the test set.  You can run it using the python script test.py.  Make sure to change the two parameters in lines 11 and 12:
stem - point this to the disk location of the unzipped directory attributes_problem_smallimage.
numberOfAttributes - set to either 6 or 7 (the number of channels or attributes per pixel).  The script will only run with either 6 channels (this is the case that works fine) or 7 channels (this the case that fails relative to the command line).
At the bottom of the test.py script are two command line calls that can be used to try to run the same case with command line elastix.
attributes_problem_smallimage.zip

I have not forgotten you, I just haven't had the time to look at it. To be continued ...

One update:  Thanks to your help on the C++ project issue, I am able to confirm the problem here is not related to Python wrapping, as the same issue appears when I implemented in C++. I'm thinking about trying to implement using elxElastixFilter to see if this is truly a SimpleElastix issue or an issue with elastix itself. Will let you know when I have some results.

OK, I've done a bit more investigation on this and I can confirm the issue seems related to SimpleElastix, rather than elastix itself.  I've basically reproduced the internals of SimpleElastixImpl
::DualExecuteInternal by instantiating my own elxElastixFilter, passing the multi-channel SimpleITK image to elastix using AddFixedImage / AddMovingImage and GetITKBase() to get an ITK image.  Thus, I am not using any SimpleElastix to do any of the registration part.  When doing this, elastix runs without issue (as I describe above if calling from the command line).  So, my suspicions are the problem lies somewhere in SimpleElastix / SimpleITK.  However, I am stuck at this point.  Any suggestions on how to proceed to try to track down this issue would be welcome.

Can you check if the difference stems from SimpleITK image reader by trying out both ITKs image reader and SimpleITK's image reader in your C++ code?

Closing as we never found the underlying issue. Feel free to reopen if you want to discuss further. If you found a solution please let me know so I can fix it for everybody, or, even better, make a PR :D


Receive screen basics

home with balance!
receive

I like where this is going but I need to figure out how to have all the "wallet" routes under the nodemanagerprovider but none of the other routes... otherwise I'll be initializing a "node" for randoms just checking out the waitlist

Feels pretty smooth!
We also really gotta figure out how to make desktop not look like it's meant for blind grandma's, probably should have a good layout for that before we start building too many pages and stuff.


Function to reset the event specification in the Scaper object

It might be useful to have a way to reset the event specification in a Scaper object so that the same Scaper object can be used over and over to generate soundscapes, instead of making a Scaper object inside the loop for each soundscape like in the tutorial.
Current proposal is to add a function to the Scaper object called Scaper.reset_event_spec() which would accomplish this. Looking through Scaper._instantiate, the only objects that get touched that belong to self are self.bg_spec and self.fg_spec. As these are both lists, I think the body of reset_event_spec would look something like:
def reset_event_spec(self):
  self.fg_spec = []
  self.bg_spec = []

Which are their original settings in the init function.
We would need a corresponding test. Maybe generate something, then reset the object, then generate again? And make sure the generated soundscapes are different from one another?

Yes, let's add this! A few comments:

Scaper._instantiate() also touches self.duration. It also calls self._instantiate_event() which touches self.bg_path, self.fg_path, self.bg_labels, self.fg_labels, self.protected_labels and self.duration. Then there's _generate_audio() which touches pretty much all other parameters in self.*. All this to say, there's a big difference between the notion of resetting the Scaper object and just resetting the event specifications, and we should limit ourselves to the latter in this context.
It occurred to me that there's a valid (and common) use case for wanting to only reset either the foreground or background spec, for example when you want the same background but different foreground events, and vice versa (e.g. for model evaluation ablations). So how about we break this down into reset_fg_event_spec() and reset_bg_evet_spec()?
The implementation, as you've noted, is trivial. Where I think we need to spend time/effort is in documenting the behavior of these functions in docstrings, as well as explaining and demonstrating with examples in the documentation how to use them.
In terms of tests, the trivial ones to add are to check that the lists have been set to empty lists. Next, we can create a Scaper object and add events to it and then reset the specs, and compare it to another objects that hasn't had events added to it, and they should be identical. Finally, we could have a test that creates a Scaper object, adds events to it and instantiates a JAMS file. Then we reset the event specs, start it off with the same seed again, repeat the process and instantiate another JAMS. The two JAMS files should be identical.
This just made me thing: in additional to providing a random seed as part of the init function, do we also want to add a function Scaper.set_random_seed() in case someone wants to change the random seed of an already existing Scaper object?

How does this all sound?

All sounds good. I'll fold this into #54!

Added via #54


fix RunSafe with context

Codecov Report

Merging #3224 (e022924) into master (8762a3b) will decrease coverage by 0.06%.
The diff coverage is 46.15%.

Impacted Files	Coverage Δ
core/rescue/recover.go 50.00% <0.00%> (-50.00%)	⬇
core/threading/routines.go 100.00% <100.00%> (ø)
... and 1 file with indirect coverage changes

Please fix the code coverage problem. Thanks!


bond device with wlp3s0 and enp0s25 breaks networking when rfkill on wireless is active

Issue description
behaviour i see
when i reboot my laptop and rfkill (the little switch on my thinkpad) is off then my booting is slightly delayed and networking will not work until i restart it manually:
# manually turning rfkill to _on_
systemctl restart network-link-wlp3s0.service
systemctl restart bond0-netdev.service

behaviour i want instead

if the wireless interface is off (rfkill on) then just ignore that and add the wireless interface wlp3s0 to the bond0 anyways.
at least start the bond0 with the enp0s25 interface attached

instead i see two systemd units fail and networking is not working until i correct it manually each time i forget to disable rfkill (set wireless to on).
debugging information
with rfkill active, i see:
 journalctl -u network-link-wlp3s0.service

Aug 29 11:17:38 lenovo-t530 systemd[1]: Starting Link configuration of wlp3s0...
Aug 29 11:17:38 lenovo-t530 lk3pyq4ad5wc2bk78q57viybf3z3ppkp-unit-script-network-link-wlp3s0-start[829]: Configuring link...
Aug 29 11:17:38 lenovo-t530 lk3pyq4ad5wc2bk78q57viybf3z3ppkp-unit-script-network-link-wlp3s0-start[829]: bringing up interface... RTNETLINK answers: Operation not possible due to RF-kill
Aug 29 11:17:38 lenovo-t530 lk3pyq4ad5wc2bk78q57viybf3z3ppkp-unit-script-network-link-wlp3s0-start[829]: failed
Aug 29 11:17:48 lenovo-t530 systemd[1]: network-link-wlp3s0.service: Main process exited, code=exited, status=1/FAILURE
Aug 29 11:17:48 lenovo-t530 systemd[1]: network-link-wlp3s0.service: Failed with result 'exit-code'.
Aug 29 11:17:48 lenovo-t530 systemd[1]: Failed to start Link configuration of wlp3s0.

journalctl -u bond0-netdev.service

Aug 29 11:17:48 lenovo-t530 systemd[1]: Starting Bond Interface bond0...
Aug 29 11:17:48 lenovo-t530 mmf4njf69kbahwwdv7llqzyqc3nw5h8g-unit-script-bond0-netdev-start[956]: Destroying old bond bond0...
Aug 29 11:17:48 lenovo-t530 mmf4njf69kbahwwdv7llqzyqc3nw5h8g-unit-script-bond0-netdev-start[956]: Creating new bond bond0...
Aug 29 11:17:48 lenovo-t530 mmf4njf69kbahwwdv7llqzyqc3nw5h8g-unit-script-bond0-netdev-start[956]: RTNETLINK answers: Operation not possible due to RF-kill
Aug 29 11:17:48 lenovo-t530 systemd[1]: bond0-netdev.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Aug 29 11:17:48 lenovo-t530 systemd[1]: bond0-netdev.service: Failed with result 'exit-code'.
Aug 29 11:17:48 lenovo-t530 systemd[1]: Failed to start Bond Interface bond0.

my configuration:
    interfaces.enp0s25.useDHCP = false;
    interfaces.wlp3s0.useDHCP = false;
    interfaces.bond0.useDHCP = true;

    bonds = {
      bond0 = {
        interfaces = [ "wlp3s0" "enp0s25" ];
        driverOptions = {
          mode = "active-backup";
          miimon = "100";
        };
      };
    };

systemctl cat bond0-netdev.service
# /nix/store/y9yg3wn7dqifp0k45qxxf9cv3bp75r0w-unit-bond0-netdev.service/bond0-netdev.service
[Unit]
After=network-pre.target sys-subsystem-net-devices-wlp3s0.device sys-subsystem-net-devices-enp0s25.device network-addresses-wlp3s0.service network-link-wlp3s0.service network-addresses-enp0s25.ser>
Before=network-setup.service
BindsTo=sys-subsystem-net-devices-wlp3s0.device sys-subsystem-net-devices-enp0s25.device
Description=Bond Interface bond0
PartOf=network-setup.service

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/c228yaf0lpwz2b9w5cz6jqqf7wmn6lq3-glibc-locales-2.27/lib/locale/locale-archive"
Environment="PATH=/nix/store/ki6m84lssq5kzawabykg7p8qrk076m02-iproute2-4.17.0/bin:/nix/store/8q6dp79rygy5layib2k0l71n64jbmd78-gawk-4.2.1/bin:/nix/store/bgii6n1si6za1ry0vbwnmiapzagcyrjm-coreutils-8>
Environment="TZDIR=/nix/store/1739slb02r1mb60q4648ajbdms52yvnr-tzdata-2018e/share/zoneinfo"

ExecStart=/nix/store/mmf4njf69kbahwwdv7llqzyqc3nw5h8g-unit-script-bond0-netdev-start
ExecStopPost=/nix/store/jb6f5a843w3m9q7p0dp0dngbhr1fl9g4-unit-script-bond0-netdev-post-stop
RemainAfterExit=true
Type=oneshot

systemctl cat network-link-wlp3s0.service
# /nix/store/mm14sb4yn2p93b3fpz2n4mzzh6aimjvg-unit-network-link-wlp3s0.service/network-link-wlp3s0.service
[Unit]
After=network-pre.target sys-subsystem-net-devices-wlp3s0.device
Before=network-interfaces.target
BindsTo=sys-subsystem-net-devices-wlp3s0.device
Description=Link configuration of wlp3s0

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/c228yaf0lpwz2b9w5cz6jqqf7wmn6lq3-glibc-locales-2.27/lib/locale/locale-archive"
Environment="PATH=/nix/store/ki6m84lssq5kzawabykg7p8qrk076m02-iproute2-4.17.0/bin:/nix/store/bgii6n1si6za1ry0vbwnmiapzagcyrjm-coreutils-8.29/bin:/nix/store/hm91iaffdsq7gihqd75ax4wqqbk7mmzh-finduti>
Environment="TZDIR=/nix/store/1739slb02r1mb60q4648ajbdms52yvnr-tzdata-2018e/share/zoneinfo"

ExecStart=/nix/store/lk3pyq4ad5wc2bk78q57viybf3z3ppkp-unit-script-network-link-wlp3s0-start
RemainAfterExit=true
Type=oneshot

Technical details
nix-info -m
warning: Nix search path entry '$HOME/.nix-defexpr/channels' does not exist, ignoring
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.62, NixOS, 18.09.4af9ee4-nixcloud_c34f201 (Jellyfish)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.0.4`
 - channels(root): `"nixos-18.09pre148985.4af9ee49f1e"`
 - channels(joachim): `""`
warning: Nix search path entry '$HOME/.nix-defexpr/channels' does not exist, ignoring
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

For the moment networkd might not have this issue.

@Mic92 all those cases? you mean the 'rfkill'?


When viewing details of withdrawal i get the following error

http://peatio:8000/admin/withdraws/satoshis/2
undefined method `find_withdraw' for #Admin::Withdraws::SatoshisController:0x00007ff4a82e9088
@app.call(env)
Can be fixed by making mehtond find_wihdraw public (not sure if this proper fix thought)

@yivo this bug is confirmed

bittrex opensource: https://github.com/frezeq0/bittrex-opensource

bittrex opensource: https://github.com/pkdcryptos/frezeq0_bittrex-opensource

Bittrex sourcecode: https://github.com/stannak7/bittrex-source-code


[ldd-msss_cam_mh] Sampling to ref instead of name

In the main class we have in the xsd:
      <xs:element ref="img:Onboard_Compression" minOccurs="0" maxOccurs="unbounded"> </xs:element>
      <xs:element ref="img:Optical_Filter" minOccurs="0" maxOccurs="unbounded"> </xs:element>
      <xs:element name="Sampling" type="img:Sampling" minOccurs="0" maxOccurs="1"> </xs:element>
      <xs:element ref="img:Subframe" minOccurs="0" maxOccurs="1"> </xs:element>
      <xs:element ref="img:Instrument_State" minOccurs="0" maxOccurs="unbounded"> </xs:element>

Note that one if these is not like the others.  ;-)  Sampling should have the same ref= as the others so we can use img:Sampling ... the way it is now we have to say msss_cam_mh:Sampling, which defeats the point of reusability in the Velocity templates.

I think we are good here. This is what Jordan and I have been trying to figure out. The new version of MSSS_CAM_MH was pushed but it was pointing to a non-existing update for IMG. Chicken before the egg situation. So I have push a MSS_CAM_MH pointing to the latest IMG on github.
https://github.com/pds-data-dictionaries/ldd-msss_cam_mh/tree/v1010/build/release/1.E.0.0_<IP_ADDRESS>
But once we really push IMG, this line will need to update (for the line below).
https://github.com/pds-data-dictionaries/ldd-msss_cam_mh/blob/6917a8789549f10cf7d888a6ac8cd937c425b699/build/release/1.E.0.0_<IP_ADDRESS>/PDS4_MSSS_CAM_MH_1E00_1010.xsd#L23
Anyway, using this MSS_CAM_MH schema should work for testing. Once we feel IMG is solid, then PDS EN can post, but they don't want to post another version of IMG if it is going to change again.


Create bubble sort.md

This PR...

Fixes #
Changes

Checklist

[x] I have read CONTRIBUTING guidelines.
[ ] This is a typo fix.
[ ] I am not updating any todo.txt files.

new .md


Page 96 Sales Cr. Memo Subform - OnBeforeInsertExtendedText in InsertExtendedText procedure

page 96 Sales Cr. Memo Subform. OnBeforeInsertExtendedText event within InsertExtendedText procedure.  Could you please add xREC Parameter?  Thanks.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


[Bug] wasm-bindgen conflict with wasm32-unknown-unknown targets

Component
consensus, eips, genesis
What version of Alloy are you on?
v0.1.1
Operating System
Linux
Describe the bug
Hi! When the "consensus" feature is enabled, builds and deployments for wasm32-unknown-unknown targets fail due to the presence of the wasm-bindgen crate in the dependencies. What is the best path to avoid this? Could it be made optional similar to how this was dealt with for the contract feature? I can make a PR for it if you give me a hint :)

Thanks for opening the issue, it should be fixed with #974. For now you can pin to git main, or the workaround is to use the alloy-consensus crate directly.
I'd like to ask you what are you using the wasm32-unknown target without wasm-bindgen/js for? We would like to also support this usecase in CI.

Thanks for the quick response! I'm using it for writing smart contracts on the IC network.


Feature request: pass-through to XML RFC

This is a suggestion from @petithug (sorry for the late posting!):
The issue is that pass-through at the AsciiRFC level requires to use metanorma XML model, but it would be useful to be able to pass-through xml2rfc, for example to use some of the xml2rfc features that have no equivalent in AsciiRFC, at least until they are implemented.  Let's use <artset> as an example.  One cannot do that:
<artset>
 <artwork>
...
 </artwork>
</artset>

because metanorma XML (and AsciiRFC) does not know anything about <artset> yet.  So my suggestion is to add a new type of node in metanorma XML that can carry any value, something like this:
<pass-through>
<artset>
  <artwork>
    ...
  </artwork>
 </artset>
</pass-through>

Then the back-end for IETF (and probably others) can be modified to simply add the content of the <pass-through> element inside the xml2rfc document.

The pass-through feature has been requested multiple times. I don’t have a strong objection but there are some considerations:

What happens if the pass-through content breaks the output? e.g. broken tags/invalid chars in the rendered output. Will this confuse the user? Maybe a warning suffices (e.g. "Don't use this unless you know what you're doing")?

(pass-through content won't break MN XML, since the content will be embedded with escapes)

Will pass-through be an IETF-only feature? Does the pass-through only work with one output format (RFC XML)? In other flavors (such as ISO), what does pass-through mean? Or there a generic need to tailor the output.

e.g.
<!-- in ISO -->
<pass-through format="html">
  <annotation>...
</pass-through>

Would it be easier for AsciiRFC to play catch up with  and other features as they come along? I imagine that this may be limiting for your purposes. I can see pass-through being used for scripting too, but it may be dangerous for other users...


Sort link should not modify passed-in parameters

I'm sorry the ridiculous delay. I'm now using dup instead of clone. Could you please merge it in?

Looks like this pull request was from your master branch, instead of a 1-0-stable branch -- it's pulling the changes between 1-0-stable and master as well.


Functioning well after alteration to use yml configuration

check readme.md for more info

this change looks interesting - did you still want to merge?


Rocco ignores JS code/comments

Is Javascript not one of the languages Rocco will generate docs for? Test run with two trivial example files:
$ cat javascript.js
/* something */
function f() {
  // a comment
  alert( "hi" );
}

$ cat ruby.rb
module SpanishHarlem
  # purple drank
  def meth_od(code)
    puts "sup"
  end

  # stuff
  puts "yo"
end

$ bundle exec rocco ruby.rb javascript.js
WARNING: Pygments not found. Using webservice.
pygmentize not in PATH; using pygments.appspot.com instead
rocco: ruby.rb -> ruby.html
rocco: javascript.js -> javascript.html

$ open ruby.html javascript.html

RESULT: generated HTML for ruby file looks fine, generated HTML for js file = no code / comments

It should work with anything supported by pygments. Perhaps it's something with the webservice. Mind installing pygments locally and giving that shot?

@jm3 Rocco doesn't detect input file language without pygments installed locally:
  def detect_language
    @_language ||=
      if pygmentize?
        %x[pygmentize -N #{@file}].strip.split('+').first
      else
        "text"
      end
  end

I suggest (forgotten-labors/rocco@13b7975626dbc06e3d018e1535499b3a66566a08) a basic language detection, since some of defined code styles has keys similar to file extensions.

It did indeed work with a local pygments install [1]. If there's anything I can do here to help test / verify / document the above, please let me know!
[1] http://jm3.github.com/thunderous-configs/en.wikipedia.org.html

@jm3 You still can generate documentation without pygments installed locally. Just pass the --language option to rocco:
$ bundle exec rocco --language=js javascript.js

or
$ bundle exec rocco -l js javascript.js


Add an Authority API that can query the cert+effect for a list of transaction digests

For a fullnode following an authority, once it gets a list of tx digest through the follower API, it will want to know the exact certified transaction as well as the signed effects from the authority for each transaction. To make it more efficient (avoid querying tx by tx), we should provide an API that can query (cert+effect) tuple for a list of tx.
@gdanezis @laura-makdah What do you think?
@bmwill

One option is to have a batch request indeed. Another option is to have a streaming API to do all requests to authority with a set of streaming responses back. This is what we used to have.
The batch approach is a little more compact, but I do wonder if we need to special case or support a generic batch request containing a number of requests internally, and returning a vec of their responses.

I agree having a way to batch transactions or anything else for that matter would be handy.


Vertebrate-level brain atlas, questions about evolutionary distanct integration

Dear authors,
Thank you for giving us such a wonderful toolkit!
If I want to build an evolutionary distance atlas, should we use major cell type level as "cell_type" label?
Is there any other parameters you would recommend we could tune to make the atlas better since the default results doesn't integrated well.
Thank you for your help!
Best wishes,
Yuanzhen

The jupyter notebook is the version used in the paper (same hyperparameters, the random seed will be slightly different but this shouldn't make a hude difference), how were the results different?
How are you judging how well the species are integrated? You should try transferring labels between species and measuring accuracy.

Hi Yanay, thank you for your quick response!
Probably you are right, I just compared them with naked eye. so not that accurate but looks quite different from your paper.
I assume that the same major clusters (cell types) from different species should be close to each other rather than separate.
I also tested for human and mouse whole brain atlas, It also doesn't integrated well.

I checked about distance between your generated protein embeddings and mine, the corresponding genes had the lowest distance so no problem with the step of protein embedding.
The problem seems to be related to the scRNA and snRNA datasets, once I removed the snRNA human dataset and only integrated mouse and lizard (both are scRNA datasets), they integrated much better than before.  I was wondering do you have some recommendations to give more "force" on integration to make snRNA human better integrate with other scRNA datasets, for example, maybe increasing the pretrain numbers? Many thanks!

The UMAP for frog and zebrafish looks pretty similar. The actual UMAP will not be the exact same because of random seed and different hardware/versions. Another aspect that is different is that in the UMAP you generated, it looks like points are smaller/are in a random order, which causes the clusters to appear more mixed, which can be hard to see.


Drop support for Node.js 6.x

Just a top level tracking bug to drop support for Node.js 6, do a semver major bump, and cut a release. The list of tasks for each repo are:

BEFORE you start working on a library, add your handle next to the issue in this list, and call it out on the slack
Make sure the gts@1 PR is merged for TypeScript repos
Bump the supported version in engines of package.json to >=8
Use @bcoe's fancy release tool thing he's going to explain to us how to use to cut a semver major release
For any pre 1.x library - BUMP TO 1.X.  0.x releases are confusing everyone.

Wave 1

[x] googleapis/gaxios [@justinbeckwith]

[x] published to npm.

[x] googleapis/google-p12-pem @justinbeckwith

[x] published to npm.

[x] googleapis/nodejs-promisify @JustinBeckwith

[x] published to npm.

[x] googleapis/nodejs-paginator [@bcoe]

[x] published to npm.

[x] googleapis/nodejs-precise-date @bcoe

[x] published to npm.

[x] googleapis/nodejs-projectify @justinbeckwith

[x] published to npm.

[x] googleapis/release-please @bcoe

[x] published to npm.

[x] googleapis/github-repo-automation @alexander-fenster

[x] published to npm.

Wave 2

[x] googleapis/sloth bcoe

[x] published to npm.

[x] googleapis/node-gtoken bcoe

[x] published to npm.

[x] googleapis/gcp-metadata bcoe

[x] published to npm.

[x] googleapis/nodejs-proto-files bcoe

[x] published to npm.

Wave 3

[x] googleapis/google-auth-library-nodejs @alexander-fenster

[x] published to npm.

Wave 4

[x] googleapis/nodejs-googleapis-common @alexander-fenster

[x] published to npm.

[x] googleapis/gce-images [ben]

[x] published to npm.

[x] googleapis/gcs-resumable-upload [ben]

[x] published to npm.

[x] googleapis/gax-nodejs @alexander-fenster

[x] published to npm.

[x] googleapis/nodejs-common @JustinBeckwith

[x] published to npm.

Wave 5

[x] googleapis/nodejs-common-grpc

[x] published to npm.

Wave 6

[ ] googleapis/cloud-debug-nodejs

[ ] published to npm.

[ ] googleapis/cloud-profiler-nodejs

[ ] published to npm.

[ ] googleapis/cloud-trace-nodejs [@kjin]

[ ] published to npm.

[x] googleapis/google-api-nodejs-client

[x] published to npm.

[x] googleapis/nodejs-asset

[x] published to npm.

[x] googleapis/nodejs-automl

[x] published to npm.

[ ] googleapis/nodejs-bigquery

[ ] published to npm.

[ ] googleapis/nodejs-bigquery-data-transfer

[ ] published to npm.

[ ] googleapis/nodejs-bigtable

[ ] published to npm.

[x] googleapis/nodejs-cloud-container

[x] published to npm.

[ ] googleapis/nodejs-compute

[ ] published to npm.

[ ] googleapis/nodejs-containeranalysis

[ ] published to npm.

[ ] googleapis/nodejs-datalabeling

[ ] published to npm.

[ ] googleapis/nodejs-dataproc

[ ] published to npm.

[x] googleapis/nodejs-datastore

[x] published to npm.

[ ] googleapis/nodejs-dialogflow

[ ] published to npm.

[ ] googleapis/nodejs-dlp

[ ] published to npm.

[ ] googleapis/nodejs-dns

[ ] published to npm.

[ ] googleapis/nodejs-error-reporting

[ ] published to npm.

[x] googleapis/nodejs-firestore

[ ] published to npm.

[ ] googleapis/nodejs-iot

[ ] published to npm.

[ ] googleapis/nodejs-irm

[ ] published to npm.

[ ] googleapis/nodejs-kms

[ ] published to npm.

[ ] googleapis/nodejs-language

[ ] published to npm.

[ ] googleapis/nodejs-logging

[ ] published to npm.

[ ] googleapis/nodejs-monitoring

[ ] published to npm.

[ ] googleapis/nodejs-os-login

[ ] published to npm.

[ ] googleapis/nodejs-rcloadenv

[ ] published to npm.

[x] googleapis/nodejs-recaptcha-enterprise

[x] published to npm.

[ ] googleapis/nodejs-redis

[ ] published to npm.

[x] googleapis/nodejs-resource

[ ] published to npm.

[x] googleapis/nodejs-scheduler

[x] published to npm.

[ ] googleapis/nodejs-security-center

[ ] published to npm.

[ ] googleapis/nodejs-speech

[ ] published to npm.

[ ] googleapis/nodejs-storage

[ ] published to npm.

[x] googleapis/nodejs-talent

[x] published to npm.

[x] googleapis/nodejs-tasks

[x] published to npm.

[x] googleapis/nodejs-text-to-speech

[x] published to npm.

[x] googleapis/nodejs-translate

[x] published to npm.

[x] googleapis/nodejs-web-risk

[x] published to npm.

[x] googleapis/nodejs-video-intelligence

[x] published to npm.

[x] googleapis/nodejs-vision

[x] published to npm.

Wave 7

[ ] googleapis/google-cloud-kvstore

[ ] published to npm.

[ ] googleapis/nodejs-firestore-session

[ ] published to npm.

[ ] googleapis/nodejs-datastore-session

[ ] published to npm.

[ ] googleapis/nodejs-logging-bunyan

[ ] published to npm.

[ ] googleapis/nodejs-logging-winston

[ ] published to npm.

Wave 8

[ ] googleapis/nodejs-spanner - please hold this for now because of grpc-gcp. Need to update the code to use C-code grpc. / @alexander-fenster

[ ] published to npm.

[ ] googleapis/nodejs-pubsub

[ ] published to npm. / @alexander-fenster with the help of @callmehiphop

This is far enough along that I'm willing to call it :) Great job folks!


Revert "Added defaultIndex processing for userInput items parsing"

Reverts vespa-engine/vespa#23581
@bratseth PR

👍


Order ID = 0

<Bitstamp> Trying to send a "buy" limit order<EMAIL_ADDRESS><Bitstamp> Order ID = 0. Message: {"error": {"all": ["You need 29.08 USD to open that order. You have only 29.05 USD available. Check your account balance for details."]}}
<Bitstamp> Done (order ID: 0)

shouldn't order id "0" be marked as an "error" instead of a "done"?

that 3 cent miscalculation might also be an other issue.

Definitely needs to be fixed. Good catch.


Upgrade alpine to 3.7 and openjdk 8u151

Fixes #508
Unfortunately there must be some change in bash, the read call to split JAVA_OPTS just hangs
$ docker run --rm -ti -p 8080:8080 jenkins/jenkins:alpine
+ : /var/jenkins_home
+ touch /var/jenkins_home/copy_reference_file.log
++ date
+ echo '--- Copying files at Tue Dec  5 14:24:22 UTC 2017'
+ find /usr/share/jenkins/ref/ '(' -type f -o -type l ')' -exec bash -c '. /usr/local/bin/jenkins-support; for arg; do copy_reference_file "$arg"; done' _ '{}' +
+ [[ 0 -lt 1 ]]
+ java_opts_array=()
+ echo

+ IFS=++ [[ -n ''
 ]]
+ read -r -d '' item

Works for me. Looks like there was a problem with the upstream image which has now been fixed.

+1

Working now in a new build, must have been an issue in alpine base image


Grape 0.10.1 and 0.11.0

Will this be available for the newest versions of Grape?

The latest version works with Grape 0.10.1 and 0.11.0.

Sorry for bothering you it worked, just needed grape-swagger 0.9.0. One more question how to specify the version of the api. Let's say the api_url is http://localhost:3000/api/v1/users.json? It works without the version /api/users.json, but I can't figure out a way with the api version.

Describe "it doesn't work"? You should put up a demo project with the issue related to version and open an issue here.

I've figure this out as well, just used the "api_version" key of the the hash that is passed as an attribute to the add_swagger_documentation method. Example
add_swagger_documentation base_path: "/api", api_version: "v1"


Skip creating half edges when we don't have a second vertex

Running into problems with voronoi use from with the nvd3 library, and while debugging I noticed that cascading conditional starting on line 51 of cell.js can end up with a null value, which causes CreateBorderEdge to choke de-referencing for an x value.
Not really understanding this code, it seems that we would not want to create a border edge in that case.
Is there any harm it just skipping its creation?
FWIW, the nvd3 code was fixed to remove duplicate points (see https://github.com/novus/nvd3/pull/584).
Thanks for any insights you can offer.

Rrr

@mbostock, could you take a moment to consider this?  Thanks.

Looks like it chokes in d3_geom_voronoiHalfEdge, but yeah. Needs further investigation.


python3Packages.enturclient: relax aysnc_timeout constraint

Motivation for this change
Fix build (https://hydra.nixos.org/build/160346513)
Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

2 packages built:

python38Packages.enturclient
python39Packages.enturclient


Implemented NSData.description

I'm not particularly a fan of "0\(byteStr)", but I can't seem to find a way to pad Swift's hex strings.
Any better ideas?
String(format: "%02X", bytes[i]) ends up being "(\"%02X\", 4)", because of the whole arguments-as-tuples thing. I think String(format: String, ...) got removed?

So what should be the behavior for .description? Should we truncate or leave as-is?

Let's do what Philippe suggested and implement description to show everything and debugDescription to truncate.

So, in my Xcode 7.1, description and debugDescription are exactly the same until data.length is 65526, at which point it becomes <OS_dispatch_data: data[0x7fb97b737320] = { leaf, size = 65527, buf = 0x1127c5000 }>

That makes sense - at a certain size NSData changes the subclass it returns to you (the magic of class clusters). At 64k it effectively becomes a dispatch_data_t.
Is your question asking what the limit should be or if we should have a limit at all?

I guess this is a place where our implementation will diverge from Foundation?
If that's the case, what should the truncation limit be, and how much data should we put after the truncation point?
Is this a good truncation scheme?
<ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ... ffffffff>

There are case-by-case places where we can allow the implementation to differ. We should have a discussion like this about it for sure, so thanks for double-checking on the Darwin implementation.
In this case in particular, I'm ok with making changes to the debugDescription method which are incompatible with the wrong way of doing things on any platform. If we leave description with the full data then we are fairly compatible. If anyone is using debugDescription and expecting it not to truncate, then we may have to ask them to fix their code instead.
My opinion on debugDescription truncation length is that it should be manageable if you po in the debugger. Let's say 1k. Anything after that should show the first 512 bytes and last 512 bytes.

I agree with that. I'll implement that now! :+1:

Regarding building hex string out of NSData, this is how I did it some time ago, with String(format: String, ...).

below is sample of what I came up with some time ago to generate hex out of bytes:
   private func hex(limit limit: Int? = nil) -> String {
       var str = String()
       var totalCount = 0
       self.enumerateByteRangesUsingBlock { (bytes, byteRange, stop) -> Void in
           for var idx = 0; idx < min(byteRange.length, limit ?? byteRange.length); ++idx {
               str += String(format:"%02x", UnsafePointer<UInt8>(bytes + idx).memory)
           }
           totalCount += byteRange.length
           stop.memory = totalCount > limit ? true : false
       }
       return str
   }

My second thought here is about if buffer is contiguous. Presence of enumerateByteRangesUsingBlock() suggest it may be not if so I don't think we shoud have this assumption.

That's a great implementation, but the truncation logic relies on being able to skip potentially large amounts of data and print the last 512 bytes.

Any ideas here?

@harlanhaskins Yah, let's go ahead and close this one and merge a new PR.


TMM normalization

Here is the script I used for TMM normalization in this work.
multispecies_normalization.ipynb.zip
Could you integrate it in the curate step or as a new subcommand?

@fsaul will need across-species TMM normalization in her project. When is this feature expected to be integrated?

@Hego-CCTB bump.

I started looking into this. Expect a stable version by the end of next week!

I've got your script running on my own plant data as well. Now it's just a matter of integrating it into curate. I might change some of the output folder structure of quant/merge to make it an easier transition into curate.

I integrated cross species TMM normalisation into curate on my end (currently assumes very rigid folder structure and file names. Want to add options for that.).
It also currently lacks a link to subsequent SVA correction. Currently (with TPM), if you have 4 different species you want to do SVA correction on, you'd have to run curate 4 times. But with TMM normalisation I have the info for all species in place already and could run SVA for all of them (seperately, in a queue).
I'd add an option to stop after the TMM normalisation and one to automatically continue with the SVA for all species used in the TMM step.

Also, if I assume a similar folder structure for TPM into SVA, there's nothing stopping me from doing the same for that branch of the algorithm as well (processing multiple species in a queue, that is).
You think this is better or worse for the user?

It would be nice to have an option for sequential/parallel processing in both TPM and FPKM processings. And we clearly need a stop&resume for cross-species TMM and subsequent curations if parallel processing is desired... The stop&resume should be acceptable but wouldn't be a good design.
I'm wondering if it's possible to implement an optional subcommand like amalgkit tmm between quant and curate, so that we can use this command to apply a cross-species TMM normalization and get rid of the stop&resume in the curate step. To do so, we need to get "TMM-scaled counts" rather than "TMM-scaled FPKM/RPKM". I guess it's theoretically no problem to apply the TMM normalization factors to raw counts, but not entirely sure. Could you check if it's possible? If so, we should go with amalgkit tmm. If not, keep the stop&resume in the curate step.
You might want to check the original paper:
https://genomebiology.biomedcentral.com/articles/10.1186/gb-2010-11-3-r25

A quick test would be to compare if these two procedures return the same values:

raw count -> edgeR::calcNormFactors() -> manual tmm scaling -> edgeR::rpkm(foo, gene.length=bar, normalized.lib.sizes=FALSE)
raw count -> edgeR::calcNormFactors() -> edgeR::rpkm(foo, gene.length=bar, normalized.lib.sizes=TRUE)

A quick test would be to compare if these two procedures return the same values:

raw count -> edgeR::calcNormFactors() -> manual tmm scaling -> edgeR::rpkm(foo, gene.length=bar, normalized.lib.sizes=FALSE)
raw count -> edgeR::calcNormFactors() -> edgeR::rpkm(foo, gene.length=bar, normalized.lib.sizes=TRUE)

Had exactly the same idea! Will report back on my findings

Here's a scatterplot (FPKM vs FPKM) of the first 10000 genes in my test-dataset. Each dot represents a single gene, the x and y values being FPKM calculated in different order of operation.
x-Axis (tmm_scaled_counts):
Tmm scaling factor calculated based on raw counts -> scaling factor applied to the raw counts -> FPKM calculation based on scaled counts -> log2
y-Axis(tmm scaled fpkm):
Tmm scaling factor calculated based on raw counts ->FPKM calculation based on raw counts -> scaling factor applied to FPKM -> log2
This should be a straight line if both methods are identical.

Boxplot of the same data

10k genes from one SRA or multiple?

Wouldn't it be straight diagonal if you plot each SRA separately after 52-sample TMM normalization? If so, there would be something to do with the library size.
What we do currently with the default lib.size option is like: rpkm(lib.size=total_count_after_tmm_scaling)
So you can try rpkm(lib.size=total_count_before_tmm_scaling) and make the same plot again.

Here are the first 4 Bioprojects (all 52 was too busy, couldn't see anything on the plot), still the same data as above.

Completely proportional! This means that TMM normalization is applicable to the raw counts. Could you try this?

So you can try rpkm(lib.size=total_count_before_tmm_scaling) and make the same plot again.

Completely proportional! This means that TMM normalization is applicable to the raw counts. Could you try this?

So you can try rpkm(lib.size=total_count_before_tmm_scaling) and make the same plot again.

I've been trying to, but the function does not let me change the lib.size parameter. I get this error when I change the parameter in any way (even setting it to NULL, which is part of the usage examples):

Error in rpkm.default(y = y$counts, gene.length = gene.length, lib.size = lib.size,  :
  formal argument "lib.size" matched by multiple actual arguments

Currently trying to figure out, if it's on my side or if the function just doesn't permit changes to this parameter (it could be that a different function is called with the same parameter).

Ok, looks like the function takes the lib.size directly out of the DGElist object created by calcNormFactors() for TMM normalization. I suspect this is why it refuses to take any input to the lib.size as lib.size is already "matched by another actual argument".
Removing the lib.size data from the DGElist object leads the function to complain it can't find lib.size.
When I remove lib.size data from the DGElist object and supply the lib.size as an argument instead, I get both errors at the same time.

You can manually create a DGElist object with a manually given lib.size. I guess that a DGElist object is essentially a list with a simple structure (check by str(obj)) and a class name which you can give by class(obj) = 'DGElist'.

You can manually create a DGElist object with a manually given lib.size. I guess that a DGElist object is essentially a list with a simple structure (check by str(obj)) and a class name which you can give by class(obj) = 'DGElist'.

yup, I'm currently testing exactly that. The fpkm values I get now are much smaller, however. By "lib.size=total_count_before_tmm_scaling" I assume you mean the sum of all counts of a given SRR run, correct?

Yes, the sum of mapped reads. Could you share the script and input data? I'll take a look.

MSN_order_test.zip
That should be everything you need. Might have to adjust file paths slightly.

Why do some genes have non-integer counts?
Cla97C00G000550.1	45.1552	10.6436	19.697	55.1915	109.113	286.08	116.83	148.955	62.5674	147.764	19.6814	10.9908	15.1607	20.3287	11.1729	23.0078	31.6176	102.699	13.0827	18.8047	10.4348	31.6643	16.6954	44.0261	9.35973	6.50079	10.6587	25.9125	2.01264	75.5934	89.3125	18.6786	12.9305	5.7630300000000005	40.4928	168.958	18.2366	248.643	224.76	103.719	0.493075	14.0123	331.151	79.4392	6.63599	8.51185	151.76	86.8138	136.757	183.579	191.095

Ah, I just remembered that this is est_count from kallisto. No problem then.

which file is that?

The root of the problem wasn't lib.size but normalization factors. The count values should have been divided by, not multiplied by, the normalization factor.

ah, that would explain things! That's good news though, means order of operations are not relevant.

Wait, wouldn't that make TMM normalized TPM possible?

Yes, operationally possible and it's OK to provide an option for TMM-TPM. But please note that not everybody thinks that TMM and TPM are compatible. See here for a relevant discussion.
https://groups.google.com/g/rsem-users/c/GRyJfEOK1BQ

How is the progress?

cstmm is implemented and curate is now structured in a way that it takes in raw counts and effective length, so it can calculate FPKM or TPM by itself. So running cstmm first, then curate with the TMM-normalized counts is possible.
cstmm is running -as in not throwing errors- and the outputs look fine, but I have no idea how to verify the results.
Here's one of the plots for the cross species normalized counts:
Multisp.SVA.combined.pdf
Note, that "corrected" and "uncorrected" are almost identical.

Is it TMM-TPM? By definition, TMM doesn't change TPM if applied prior to TPM calculation, so if one really wants to combine, TPM should be applied prior to TMM. Please look into the above URL.

This should be FPKM. At least that's what I specified as input for the script. But I can't be 100% certain. I'll run it again.

I guess my point is:

TPM -> TMM: This isn't theoretically valid but some people do so operationally. This is difficult under the current workflow of amalgkit, and so we don't have to support it.
TMM-> TPM: This is meaningless as TMM normalization is completely canceled off by TPM transformation. Please return an error when curate is called with the TPM output and cstmm input. i.e., curate produces TPM output only when the input is merge files. This wouldn't be credibly detected if the users specify a custom input directory, but should've detectable if not (i.e., defaulted as inferred).

yeah, that's true. I will include a general warning statement when curate --norm = tpm, just to at least partially cover custom input directories.
I haven't done a Wiki entry on cstmm yet, but there should be a warning there as well.

Sounds good!

I have implemented a general warning when running curate with tpm, as well as an error (and program termination) when cstmm outputs are detected in the input file paths.
https://github.com/kfuku52/amalgkit/issues/49

This issue seems done for now, as both cstmm and the warning messages have been implemented.
Bugs and improvements can be done in new issues.

https://github.com/kfuku52/amalgkit/issues/11#issuecomment-1787489170
My correction above wasn't right. Division, rather than multiplication by a TMM normalization factor was a correct procedure indeed. I will revert the change in https://github.com/kfuku52/amalgkit/commit/22db4f582ff111232429b1ffa0157ee1d8edd51a.
Code for verification (works well after interactively running cstmm.r):
# EdgeR's TMM-CPM
head(edgeR::cpm(cnf_out2, normalized.lib.sizes=TRUE, log=FALSE, prior.count=0))

# Manually applied TMM transformation and subsequent CPM calculation. The values match with the above outputs.
df_nonzero_tmm = df_nonzero
for (col in colnames(df_nonzero_tmm)) {
    tmm_normalization_factor = cnf_out2[[2]][col,'norm.factors']
    df_nonzero_tmm[,col] = df_nonzero_tmm[,col] / tmm_normalization_factor # manually apply TMM normalization factors
}
tmp = cnf_out2
tmp[['counts']] = df_nonzero_tmm
head(edgeR::cpm(tmp, normalized.lib.sizes=FALSE, log=FALSE, prior.count=0))

With the correct "division" operation in a 114-species/3-tissue plant dataset:
Across-species among-sample variance of mean single-copy gene raw counts before and after TMM normalization: 351740.1 and 299518.9
Across-species among-sample variance of all-gene mean raw counts before and after TMM normalization: 258562.6 and 262748.6
cstmm_mean_expression_boxplot.pdf
cstmm_normalization_factor_scatter.pdf


[kueuectl] Include kubectl-kueue binary on release artifacts

What type of PR is this?
/kind feature

What this PR does / why we need it:
Include kueuectl binary on build artifacts.
Which issue(s) this PR fixes:

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

Include kubectl-kueue binary on release artifacts

/lgtm
/approve

/release-note-edit
CLI: kubectl-kueue is part of the release artifacts

Actually, github doesn't allow me to upload directories :(
We'll have to have to have the os and architecture in the filename, like:
kubectl-kueue.linux-amd64
And change the installation documentation to take that filename and remove the suffix.


Bump EKS-D to latest version

Description of changes:
Updating EKS-D versions to the latest.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm
/approve


[ArtStationBridge] Added new bridge

Adds a new bridge for the latest ten items of a search query on ArtStation. User profiles already have support for RSS, so there's no need to enhance this bridge.

Thanks for taking in account @LogMANOriginal 's comments and congrats for winning that battle against Travis :smile: !
Merged !

Haha, thank you! I'll give the battle against Travis another go soon I think with another bridge ;-)

Please do ! We are always welcoming new bridges ! And I am afraid that Travis is still hungry...


400 Bad Request while installing tfsec

Partial .github/workflows/tfsec.yaml file contents
name: tfsec

on: [push, pull_request]

jobs:
  tfsec:
    name: Terraform Security Scan and PR Commenter
    runs-on: ubuntu-latest

    steps:
      - name: Clone repo
        uses: actions/checkout@master

      - name: Pull Request Commenter
        uses: tfsec/tfsec-pr-commenter-action@main
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

The Github action fails intermittently with following log:
Build container for action use: '/home/runner/work/_actions/tfsec/tfsec-pr-commenter-action/main/Dockerfile'.
  /usr/bin/docker build -t 8a33c1:b550b8a0a509483d98f061f4371b7545 -f "/home/runner/work/_actions/tfsec/tfsec-pr-commenter-action/main/Dockerfile" "/home/runner/work/_actions/tfsec/tfsec-pr-commenter-action/main"
  Sending build context to Docker daemon  2.292MB

  Step 1/6 : FROM alpine:3.12
   ---> 13621d1b12d4
  Step 2/6 : RUN apk --no-cache --update add bash git     && rm -rf /var/cache/apk/*
   ---> Running in ad0873bae2ba
  fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
  fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
  (1/10) Installing ncurses-terminfo-base (6.2_p20200523-r0)
  (2/10) Installing ncurses-libs (6.2_p20200523-r0)
  (3/10) Installing readline (8.0.4-r0)
  (4/10) Installing bash (5.0.17-r0)
  Executing bash-5.0.17-r0.post-install
  (5/10) Installing ca-certificates (20191127-r4)
  (6/10) Installing nghttp2-libs (1.41.0-r0)
  (7/10) Installing libcurl (7.77.0-r0)
  (8/10) Installing expat (2.2.9-r1)
  (9/10) Installing pcre2 (10.35-r0)
  (10/10) Installing git (2.26.3-r0)
  Executing busybox-1.31.1-r20.trigger
  Executing ca-certificates-20191127-r4.trigger
  OK: 24 MiB in 24 packages
  Removing intermediate container ad0873bae2ba
   ---> 9c9a4e675717
  Step 3/6 : RUN wget -O - -q "$(wget -q https://api.github.com/repos/tfsec/tfsec/releases/latest -O - | grep -o -E "https://.+?tfsec-linux-amd64")" > tfsec     && install tfsec /usr/local/bin/
   ---> Running in 81c221f9a015
  wget: server returned error: HTTP/1.1 400 Bad Request
  The command '/bin/sh -c wget -O - -q "$(wget -q https://api.github.com/repos/tfsec/tfsec/releases/latest -O - | grep -o -E "https://.+?tfsec-linux-amd64")" > tfsec     && install tfsec /usr/local/bin/' returned a non-zero code: 1

  Warning: Docker build failed with exit code 1, back off 3.727 seconds before retry.

I am not sure how to debug the issue.

Did some more analysis. It seems it's probably because the release is returning now 2 rows.
$ wget -q https://api.github.com/repos/tfsec/tfsec/releases/latest -O - | grep -o -E "https://.+?tfsec-linux-amd64"
https://github.com/tfsec/tfsec/releases/download/v0.39.42/tfsec-linux-amd64
https://github.com/tfsec/tfsec/releases/download/v0.39.42/tfsec-linux-amd64

The tfsec file created by line in Dockerfile is now 0 bytes.
If I run the following command manually, the tfsec file is created properly.
wget -O - -q https://github.com/tfsec/tfsec/releases/download/v0.39.42/tfsec-linux-amd64 > tfsec
Did something change in the release process of tfsec?

Hi @shirishp  - yes, I broke this when I added signing and only thought to fix it in the sarif action. will fix now

Oh, thank you @owenrumney for quick reply.
We started using this action recently and loved it. Thank you so much for your work.
Thinking aloud, would it be better to use the tfsec:latest docker image as base image for this project instead of trying to install it manually by parsing API response?

This is fixed in release https://github.com/tfsec/tfsec-pr-commenter-action/releases/tag/v0.1.4  if you could update the version in your action.
Apologies for taking 3 days to respond, I'll be honest, I didn't think anyone was even using this (except me :-) )
WRT using tfsec as the base image, yes - you're probably right, I'll have a look at that

I just confirmed that the latest release fixed out builds. Thank you so much for quick fix.
I completely understand the time taken. I really appreciate you spending time on this. Thanks.


HELP! There is a memory leak in the code?!

Discussed in https://github.com/nlohmann/json/discussions/2836

Originally posted by HuberyQ June 23, 2021
Sorry to attract you with such a scary title. First of all, I would like to thank you for this work!
I found that after parsing the. MSG file, I got the JSON object successfully, but the CPU memory was not released until the end of the program! Is there a mistake in the way I use it? Can you manually free up the consumed memory?
The size of the. MSG file is about 24MB, but the memory consumption of the parsing process is about 0.4G! Here is the test source code:
void test_json(string path)
{
    std::ifstream ifs(path, std::ios::in | std::ios::binary);
    if (!ifs.is_open())
    {
        throw std::runtime_error("cannot load the file at " + path);
    }

    std::vector<uint8_t> msgpack;
    while (true)
    {
        uint8_t buffer;
        ifs.read(reinterpret_cast<char*>(&buffer), sizeof(uint8_t));
        if (ifs.eof())
        {
            break;
        }
        msgpack.push_back(buffer);
    }
    ifs.close();

    const auto json = nlohmann::json::from_msgpack(msgpack);
    cout << sizeof(json) / 1024.0 / 1024.0 << endl;
}

I have two questions: (1) How to release the memory consumption that has not been released? (2) Why is memory consumption so huge?
Hope to get help from you or other people, thank you!

This is the .msg file:https://raw.githubusercontent.com/HuberyQ/Learning-OpenCV-3_examples/master/1.msg

https://raw.githubusercontent.com/HuberyQ/Learning-OpenCV-3_examples/master/1.msg

I didn't test with Valgrind or ASAN...I just monitoring CPU through my terminal.
Ubuntu 20.04 / C++11

There is no memory leak in the library - you can compile your code with ASAN or run it with Valgrind. All memory acquired for json is release once it goes out of scope.

The memory consumption of the library is due to the overhead described in the README:

Each JSON object has an overhead of one pointer (the maximal size of a union) and one enumeration element (1 byte).

Your JSON value contains of a lot of numbers, and hence this overhead adds up.

Note the overhead is much smaller if you compile your binary in release mode.

* There is no memory leak in the library - you can compile your code with ASAN or run it with Valgrind. All memory acquired for `json` is release once it goes out of scope.

* The memory consumption of the library is due to the overhead described in the README:
  > Each JSON object has an overhead of one pointer (the maximal size of a union) and one enumeration element (1 byte).

  Your JSON value contains of a lot of numbers, and hence this overhead adds up.

Note the overhead is much smaller if you compile your binary in release mode.

Thank you for your reply! But when the test_json function exits, the CPU memory growth caused by it is not released! You can use the data and code above to reproduce it. We need your help!

I cannot reproduce this:

The library releases all memory, there are no memory leaks. Can you please try to run your code with Valgrind or ASAN?

For an explanation of why memory freed by the application isn't returned to the OS: https://stackoverflow.com/questions/45538993/why-dont-memory-allocators-actively-return-freed-memory-to-the-os

For an explanation of why memory freed by the application isn't returned to the OS: https://stackoverflow.com/questions/45538993/why-dont-memory-allocators-actively-return-freed-memory-to-the-os

Thanks! It really helps a lot!

I cannot reproduce this:

The library releases all memory, there are no memory leaks. Can you please try to run your code with Valgrind or ASAN?
I tested on different systems：
ubuntu16：It's normal and ok!
ubuntu18：The memory was not released!
Then I refered to #1924 , and it worked! I guess that different versions of the glibc lead to different memory recovery mechanisms.

Thanks a lot!
This library is really good to use!

I cannot reproduce this:

The library releases all memory, there are no memory leaks. Can you please try to run your code with Valgrind or ASAN?

I tested on different systems：
ubuntu16：It's normal and ok!
ubuntu18：The memory was not released!
Then I refered to #1924 , and it worked! I guess that different versions of the glibc lead to different memory recovery mechanisms.
Thanks a lot!
This library is really good to use!

Do you need further assistance with this issue?

Do you need further assistance with this issue?

Nope.Thanks!


MacOS: fails benchmarks

Apple Silicon M2 running MacOS Ventura 13.3.1, Xcode-14.3, Rust-1.69.0.
$ cargo bench --features "benchmarking kyber1024"
  Downloaded tinytemplate v1.2.1
  Downloaded ciborium-io v0.2.0
.  .  .
   Compiling pqc_kyber v0.6.0 (/Users/ur20980/src/kyber-pure)
   Compiling clap v3.2.24
   Compiling lazy_static v1.4.0
   Compiling ppv-lite86 v0.2.17
   Compiling crossbeam-deque v0.8.3
   Compiling rand_chacha v0.3.1
   Compiling rand v0.8.5
   Compiling rayon v1.7.0
   Compiling plotters v0.3.4
   Compiling ciborium v0.2.0
   Compiling tinytemplate v1.2.1
   Compiling criterion v0.4.0
    Finished bench [optimized] target(s) in 12.63s
     Running unittests src/lib.rs (target/release/deps/pqc_kyber-795659d6ce51cfa5)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/api.rs (target/release/deps/api-52af575b14e196b1)
Gnuplot not found, using plotters backend
Keypair Generation      time:   [30.546 µs 30.712 µs 30.904 µs]
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild

Benchmarking Encapsulate: Warming up for 3.0000 sthread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/reference/fips202.rs:27:11
stack backtrace:
   0: rust_begin_unwind
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
   1: core::panicking::panic_fmt
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
   2: core::panicking::panic_bounds_check
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:159:5
   3: pqc_kyber::reference::fips202::keccak_absorb_once
   4: pqc_kyber::reference::fips202::sha3_256
   5: pqc_kyber::kem::crypto_kem_enc
   6: criterion::bencher::Bencher<M>::iter
   7: <criterion::routine::Function<M,F,T> as criterion::routine::Routine<M,T>>::warm_up
   8: criterion::routine::Routine::sample
   9: criterion::analysis::common
  10: criterion::benchmark_group::BenchmarkGroup<M>::bench_function
  11: api::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: bench failed, to rerun pass `--bench api`

and
$ cargo bench --features "benchmarking kyber1024" --bench api
    Finished bench [optimized] target(s) in 0.04s
     Running benches/api.rs (target/release/deps/api-52af575b14e196b1)
Keypair Generation      time:   [31.035 µs 31.092 µs 31.146 µs]
                        change: [-0.9414% -0.3577% +0.2071%] (p = 0.23 > 0.05)
                        No change in performance detected.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

Benchmarking Encapsulate: Warming up for 3.0000 sthread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/reference/fips202.rs:27:11
stack backtrace:
   0: rust_begin_unwind
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
   1: core::panicking::panic_fmt
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
   2: core::panicking::panic_bounds_check
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:159:5
   3: pqc_kyber::reference::fips202::keccak_absorb_once
   4: pqc_kyber::reference::fips202::sha3_256
   5: pqc_kyber::kem::crypto_kem_enc
   6: criterion::bencher::Bencher<M>::iter
   7: <criterion::routine::Function<M,F,T> as criterion::routine::Routine<M,T>>::warm_up
   8: criterion::routine::Routine::sample
   9: criterion::analysis::common
  10: criterion::benchmark_group::BenchmarkGroup<M>::bench_function
  11: api::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: bench failed, to rerun pass `--bench api`

Have you resolved this?
Apple make it hard for anyone to troubleshoot issues such as this without their hardware. Have an MacOS emulation suite that can run these benchmarks, albeit very slowly, I can't replicate your issue emulated on x86.
Maybe someone else inside the walled garden can help you here. I'm open to donations of Apple Silicon VPS time for troubleshooting if you are willing.

Have you resolved this?

No, I cannot. I hope that you could resolve it, with me running tests for you.

Maybe someone else inside the walled garden can help you here.

Well, I'm mine and your best bet here. I am "inside the walled garden", but I don't have a clue about what your code is doing, and what's the reason for your code to panic - i.e., what conditions it expected, failed to get satisfied:
running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/api.rs (target/release/deps/api-b5c6e9d2b892f74a)
Keypair Generation      time:   [30.107 µs 30.175 µs 30.252 µs]
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

Benchmarking Encapsulate: Warming up for 3.0000 sthread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/reference/fips202.rs:27:11
stack backtrace:
   0: rust_begin_unwind
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5
   1: core::panicking::panic_fmt
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14
   2: core::panicking::panic_bounds_check
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:162:5
   3: pqc_kyber::reference::fips202::keccak_absorb_once
   4: pqc_kyber::reference::fips202::sha3_256
   5: pqc_kyber::kem::crypto_kem_enc
   6: criterion::bencher::Bencher<M>::iter
   7: <criterion::routine::Function<M,F,T> as criterion::routine::Routine<M,T>>::warm_up
   8: criterion::routine::Routine::sample
   9: criterion::analysis::common
  10: criterion::benchmark_group::BenchmarkGroup<M>::bench_function
  11: api::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: bench failed, to rerun pass `--bench api`

I'm open to donations of Apple Silicon VPS time for troubleshooting if you are willing

I'm afraid you're mistaking me for the IBM Research VP. Or do you want me to donate you my Apple Silicon laptop (I'd still have to respectfully decline)?
In short. If you're willing to offer suggestions and co-debug with me (you telling what to do, me running code and reporting back), I'm willing to try them out and (hopefully) together fix this issue. If not - well, just mark this code as buggy on Apple Silicon for reasons currently unknown.

Can you add the full backtrace and we'll go from there?
RUST_BACKTRACE=full cargo bench --features "benchmarking kyber1024"

Can you add the full backtrace and we'll go from there?
RUST_BACKTRACE=full cargo bench --features "benchmarking kyber1024"

I'm afraid, not a whole lot:
$ RUST_MACKTRACE=full cargo bench --features "benchmarking kyber1024"
   Compiling pqc_kyber v0.6.0 (/Users/ur20980/src/kyber-pure)
warning: unused import: `std::println`
 --> benches/api.rs:1:39
  |
1 | #![cfg(feature = "benchmarking")] use std::println;
  |                                       ^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `pqc_kyber` (bench "api") generated 1 warning (run `cargo fix --bench "api"` to apply 1 suggestion)
    Finished bench [optimized] target(s) in 1.44s
     Running unittests src/lib.rs (target/release/deps/pqc_kyber-9da025de157ed88e)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/api.rs (target/release/deps/api-b5c6e9d2b892f74a)
Keypair Generation      time:   [30.240 µs 30.325 µs 30.422 µs]
                        change: [+0.8577% +1.5078% +2.2168%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 11 outliers among 100 measurements (11.00%)
  5 (5.00%) high mild
  6 (6.00%) high severe

Benchmarking Encapsulate: Warming up for 3.0000 sthread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/reference/fips202.rs:27:11
stack backtrace:
   0: rust_begin_unwind
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5
   1: core::panicking::panic_fmt
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14
   2: core::panicking::panic_bounds_check
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:162:5
   3: pqc_kyber::reference::fips202::keccak_absorb_once
   4: pqc_kyber::reference::fips202::sha3_256
   5: pqc_kyber::kem::crypto_kem_enc
   6: criterion::bencher::Bencher<M>::iter
   7: <criterion::routine::Function<M,F,T> as criterion::routine::Routine<M,T>>::warm_up
   8: criterion::routine::Routine::sample
   9: criterion::analysis::common
  10: criterion::benchmark_group::BenchmarkGroup<M>::bench_function
  11: api::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: bench failed, to rerun pass `--bench api`
$

Hey so that's not the full backtrace, can you copy/paste the code in my comment and try again? There's a typo, you've got macktrace in there

RUST_BACKTRACE=full cargo bench --features "benchmarking kyber1024"

Darn... Silly me... Here it goes:
$ RUST_BACKTRACE=full cargo bench --features "benchmarking kyber1024"
warning: unused import: `std::println`
 --> benches/api.rs:1:39
  |
1 | #![cfg(feature = "benchmarking")] use std::println;
  |                                       ^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `pqc_kyber` (bench "api") generated 1 warning (run `cargo fix --bench "api"` to apply 1 suggestion)
    Finished bench [optimized] target(s) in 0.06s
     Running unittests src/lib.rs (target/release/deps/pqc_kyber-9da025de157ed88e)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/api.rs (target/release/deps/api-b5c6e9d2b892f74a)
Keypair Generation      time:   [30.108 µs 30.194 µs 30.296 µs]
                        change: [-2.3143% -1.6634% -1.0566%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  4 (4.00%) high mild
  4 (4.00%) high severe

Benchmarking Encapsulate: Warming up for 3.0000 sthread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/reference/fips202.rs:27:11
stack backtrace:
   0:        0x102dd8af0 - std::backtrace_rs::backtrace::libunwind::trace::h0a647ce7e8dc2fab
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:        0x102dd8af0 - std::backtrace_rs::backtrace::trace_unsynchronized::hea920694a2a8ac80
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x102dd8af0 - std::sys_common::backtrace::_print_fmt::h7b4e20c1da2ebb61
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:65:5
   3:        0x102dd8af0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h819e9cbdf1a9e730
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:44:22
   4:        0x102df500c - core::fmt::write::ha5e9bf3131ecb7c0
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/fmt/mod.rs:1254:17
   5:        0x102dd5238 - std::io::Write::write_fmt::h414ce9994bf17404
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/io/mod.rs:1698:15
   6:        0x102dd8904 - std::sys_common::backtrace::_print::h28d98f2094da6d1d
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:47:5
   7:        0x102dd8904 - std::sys_common::backtrace::print::h8072db0bbd5bcc3d
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:34:9
   8:        0x102dd9f34 - std::panicking::default_hook::{{closure}}::h2c85c5b0c2ede151
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:269:22
   9:        0x102dd9cf4 - std::panicking::default_hook::hcf2f70992d02f6fe
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:288:9
  10:        0x102dda40c - std::panicking::rust_panic_with_hook::h023af7f90b47eb8b
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:691:13
  11:        0x102dda340 - std::panicking::begin_panic_handler::{{closure}}::h14283519edc1d634
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:582:13
  12:        0x102dd8f10 - std::sys_common::backtrace::__rust_end_short_backtrace::hc366c0b0cef5b747
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:150:18
  13:        0x102dda0d4 - rust_begin_unwind
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5
  14:        0x102e0e2f4 - core::panicking::panic_fmt::h324f50b29db90195
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14
  15:        0x102e0e3f0 - core::panicking::panic_bounds_check::h44029950777bf20f
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:162:5
  16:        0x102c9f994 - pqc_kyber::reference::fips202::keccak_absorb_once::hfa9d2412d0d26918
  17:        0x102c9f09c - pqc_kyber::reference::fips202::sha3_256::h4800c0b5e166de04
  18:        0x102c83ffc - pqc_kyber::kem::crypto_kem_enc::h9105f52213e96543
  19:        0x102c80238 - criterion::bencher::Bencher<M>::iter::h9a21d2291970648c
  20:        0x102c76448 - <criterion::routine::Function<M,F,T> as criterion::routine::Routine<M,T>>::warm_up::h06ed0708b2add3df
  21:        0x102c78434 - criterion::routine::Routine::sample::hd0cc3a147cece1e2
  22:        0x102c7cd90 - criterion::analysis::common::hf8f90fd0142b16bc
  23:        0x102c9c464 - criterion::benchmark_group::BenchmarkGroup<M>::bench_function::h9c1ecdb2dd66f724
  24:        0x102c8e574 - api::main::h24ba327322e39238
  25:        0x102c8c27c - std::sys_common::backtrace::__rust_begin_short_backtrace::hb8f066ae8cca2bb1
  26:        0x102c8c424 - std::rt::lang_start::{{closure}}::hf60817bdacc7b46c
  27:        0x102dd1164 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h6f7eb9f266759f90
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/ops/function.rs:287:13
  28:        0x102dd1164 - std::panicking::try::do_call::h54b2febb9ea02379
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:485:40
  29:        0x102dd1164 - std::panicking::try::h95a2f9f45aeb75ea
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:449:19
  30:        0x102dd1164 - std::panic::catch_unwind::h9686256fa0fc97a1
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panic.rs:140:14
  31:        0x102dd1164 - std::rt::lang_start_internal::{{closure}}::h227e8b10bc4e486b
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:148:48
  32:        0x102dd1164 - std::panicking::try::do_call::h414d500a3ee5fa44
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:485:40
  33:        0x102dd1164 - std::panicking::try::h4f025820961f1c3f
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:449:19
  34:        0x102dd1164 - std::panic::catch_unwind::h0b71dfe3538d125d
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panic.rs:140:14
  35:        0x102dd1164 - std::rt::lang_start_internal::h8ee16b8f6c950a26
                               at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:148:20
  36:        0x102c8e8d8 - _main

error: bench failed, to rerun pass `--bench api`
$

Ping?

I'll put aside some time to work on it this weekend.

Resolved in #93

I confirm that this problem is fixed. Thanks!


[firebase_storage] Fix putFile method's Content-Type auto-detection for iOS

putFile should use putFile iOS SDK method correctly
putFile should auto-detect Content-Type automatically by file extension if not specified

I tested at this sample on iOS:
https://github.com/flutter/plugins/blob/master/packages/firebase_storage/example/lib/main.dart.
This uses putFile here:
https://github.com/flutter/plugins/blob/04d6f52e3b09193462a18a38a7249da92b901ba5/packages/firebase_storage/example/lib/main.dart#L66
Before this pull request
Uploaded file:
https://firebasestorage.googleapis.com/v0/b/flutter-firebase-plugins.appspot.com/o/text%2Ffoob3d87700-3260-11e9-d838-d7a1f7b2a3d4.txt
contentType is application/octet-stream, but this is unintended value because putFile should auto-detect contentType as written this document.

The putFile: method automatically infers the content type from the NSURL filename extension, but you can override the auto-detected type by specifying contentType in the metadata. If you do not provide a contentType and Cloud Storage cannot infer a default from the file extension, Cloud Storage uses application/octet-stream.
https://firebase.google.com/docs/storage/ios/upload-files#add_file_metadata

In this case, the file's extension is txt, so contentType should be plain/text.
After this pull request
Uploaded file:
https://firebasestorage.googleapis.com/v0/b/flutter-firebase-plugins.appspot.com/o/text%2Ffoo09aa2e30-3260-11e9-efe1-e3ed438ea03f.txt
contentType is plain/text, which is intended value.

This is Android's uploaded file URL:
https://firebasestorage.googleapis.com/v0/b/flutter-firebase-plugins.appspot.com/o/text%2Ffoo1c94d560-3260-11e9-8a4d-ff3d6d715989.txt
contentType is application/octet-stream, but I do not know why this happens.
putFile seems to use putFile correctly 🤔
https://github.com/flutter/plugins/blob/04d6f52e3b09193462a18a38a7249da92b901ba5/packages/firebase_storage/android/src/main/java/io/flutter/plugins/firebase/storage/FirebaseStoragePlugin.java#L258-L272

Sorry, I'll fix format.

@collinjackson
I've added commits:

Could you please write a CHANGELOG and update pubspec.yaml for release?

https://github.com/flutter/plugins/pull/1355/commits/1a1563b84856dab4435ad0b39a136e51e3172c05

It looks like it might be possible to update the integration test to include the test for the correct behavior here. Would you be willing to add that?

https://github.com/flutter/plugins/pull/1355/commits/778d6a605a8101270c6a908c9673d9fb1a997f15
Could you check that please?

Thanks for the contribution!


chore: bump github cla action version to<EMAIL_ADDRESS>

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[x] N
[ ] Y

chore: bump github cla action version to<EMAIL_ADDRESS>
2. What is the scope of this PR (e.g. component or file name):

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Other

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

[x] N
[ ] Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

[ ] Unit test
[ ] Integration test
[ ] Benchmark (add benchmark stats below)
[ ] Manual test (add detailed scripts or steps below)
[x] Other

6. Release note

Please refer to Release Notes Language Style Guide to write a quality release note.
None

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 87.988%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2300

Relevant Lines:
2614

💛  - Coveralls


Add Reflect derive to Events and contained types

Objective
The Events containerr should be reflectable, in order to make dev tools that examine its state more useful.
Fixes #13148.
Solution

Add a Reflect derive to Events, gated behind the bevy_reflect feature
Add Reflect to the contained types to make everything compile.

@alice-i-cecile thanks, its works!
use bevy::prelude::*;

#[derive(Component, Reflect, Default)]
struct Position;

#[derive(Event, Reflect, Default)]
struct MoveEvent;

#[derive(Resource, Reflect, Default)]
struct Houses;

fn main() {
    App::new()
        // Position
        .register_type::<Position>()
        // MoveEvent
        .add_event::<MoveEvent>()
        .register_type::<MoveEvent>()
        // Houses
        .init_resource::<Houses>()
        .register_type::<Houses>()
        // Systems
        .add_systems(Startup, startup)
        .run();
}

fn startup(registry: Res<AppTypeRegistry>) {
    let registry = registry.read();
    for i in registry.iter() {
        println!("{:?}", i);
    }
}

output:
TypeRegistration { type_info: Struct(StructInfo { type_path: TypePathVtable { type_path: "bevy::Houses", short_type_path: "Houses", type_ident: Some("Houses"), crate_name: Some("bevy"), module_path: Some("bevy") }, type_id: TypeId { t:<PHONE_NUMBER>19092159181105962761250037597 }, fields: [], field_names: [], field_indices: {} }) }
TypeRegistration { type_info: Struct(StructInfo { type_path: TypePathVtable { type_path: "bevy::Position", short_type_path: "Position", type_ident: Some("Position"), crate_name: Some("bevy"), module_path: Some("bevy") }, type_id: TypeId { t:<PHONE_NUMBER>4654762771215367196927044087 }, fields: [], field_names: [], field_indices: {} }) }
TypeRegistration { type_info: Struct(StructInfo { type_path: TypePathVtable { type_path: "bevy::MoveEvent", short_type_path: "MoveEvent", type_ident: Some("MoveEvent"), crate_name: Some("bevy"), module_path: Some("bevy") }, type_id: TypeId { t:<PHONE_NUMBER>46073673475871982974340081787 }, fields: [], field_names: [], field_indices: {} }) }

We need the ReflectEvent struct too, right? check

Looks good! I think the one thing we might want to consider adding is a method on App to more easily register these events and their resources into the type registry.

Agreed. Ideally we'd register the type during add_event, but without specialization that would require a Reflect (or equivalent) bound on Event. Ultimately this feels like a question for #13111.