(Live-preview) Tabs are not traversed for relationships

Link to reproduction
No response
Describe the Bug
When logging here, the type is named tab
console.log(fieldSchema.type)

https://github.com/payloadcms/payload/blob/4cfe4736273551e5c51431598054c09bd0e903f8/packages/live-preview/src/traverseFields.ts#L24-L27
Only the switch case handels the name tabs
https://github.com/payloadcms/payload/blob/4cfe4736273551e5c51431598054c09bd0e903f8/packages/live-preview/src/traverseFields.ts#L105-L110
Seems to me like a typo.
For now I fixed it by editing the switch case but I think that the live preview does not give the correct type name.
To Reproduce

Create a collection with a field and set the type to tab
Create new tabs in the field
Set in one of the tab a relation to media
Open de live preview and the relation ship is not fetched

Payload Version
2.2.2
Adapters and Plugins
"@payloadcms/live-preview": "^0.1.6"

Heyyy @matthijs166 thank you as always for the details

When logging here, the type is named tab...seems to me like a typo.

Hmmm tabs appears to be using the correct the value in the switch, which is derived from here:
https://github.com/payloadcms/payload/blob/main/packages/payload/src/admin/components/forms/field-types/index.tsx#L46-L47 via https://github.com/payloadcms/payload/blob/main/packages/payload/src/utilities/fieldSchemaToJSON.ts#L11-L12.
The issue seems to come from here: https://github.com/payloadcms/payload/blob/main/packages/payload/src/utilities/fieldSchemaToJSON.ts#L77 where we (incorrectly) set the type to tab instead of tabs. This would also explain why your temporary patch works. You're forcing the switch case to hit the incorrectly set key.
Thank you for point this out 👍 I will push a fix for this shortly along with a test to prevent regression.

Also how did you get those multi-code code references?! I tried but failed. Yours look so good.


Instead of escaping i18n strings provide ability to map html entities if needed

See -> https://github.com/Manvel/cmints/issues/99

Change is reverted here -> https://github.com/Manvel/cmints/commit/8ab64d3255957589c53f1502cafeb6fbbefb5fbb

Disbling entities mapping will not solve the problem as & in the entities will always be escaped.

markdown.disable("entity");

Will disable entities(source), but the entities are still being escaped here.
So in order to prevent the entities escape, smth like this can be a solution:
markdown.renderer.rules.text = function (tokens, idx, options, env, self) {
  const text = defaultRender(tokens, idx, options, env, self).replace(/&#125;/g, "}").replace(/&#123;/g, "{");
  return text;
};


Use seconds for updateInterval in the config

Actually, there is no reason for the update interval to be 2 seconds. The data won't change that often. I think the 2 minutes will do

Actually, there is no reason for the update interval to be 2 seconds.

That's not what the patch was doing. It was allowing the user to enter/use seconds instead of milliseconds in their config. ;)


Improved content for Tutorial 8 (QAMP fall'22)

Summary
Enhancing the documentation of Tutorial "08_quantum_kernel_trainer" as a mentee for QAMP 2022.
Mentor: @ElePT
Mentee: @SanyaNanda
Details and comments

Restructured the notebook (Overview, Introduction, Objective, Tutorial, accuracy table and what was learned)
Imports placed where required
Added more explanations and inline comments for better understanding of the code
Hyperlinks to API references wherever required

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 88.934%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3544

Relevant Lines:
3985

💛  - Coveralls

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

Closing this PR whilst working on updating tutorials. For more info - see [here].(https://github.com/qiskit-community/qiskit-machine-learning/pull/491#issuecomment-1979205893)


Callbacks are never called

Hello Maxime.
Using your example code 04-Dump-Messages.ino with an ESP32 az-delivery-devkit-v4 board I found the following:
1: Callbacks for connect and disconnect were never called.
2: The board freezes on disconnect, ie it refuses to establish another connection.
I have fixed my problem by defining the callbacks before calling .begin()
I also added a restart command to the disconnect callback. At least it can be used as a temporary solution.
I hope you find this useful. Thanks for sharing your code.
Example shown below.
Best regards
Kim
void setup() {
Serial.begin(115200);
BLEMidiServer.setOnConnectCallback( {
Serial.println("Connected");
});
BLEMidiServer.setOnDisconnectCallback( {
Serial.println("Disconnected");
ESP.restart();
});
BLEMidiServer.begin("MIDI device");
BLEMidiServer.setNoteOnCallback(onNoteOn);
........

Hi Kim,
thank you very much for spotting these bugs, and the information you provided !
I have corrected them, and published the code on the arduino library manager and platformio.
Now the example works without needing to modify it, and we can connect and disconnect as much as we want.
Can you tell me if it works also for you ?
Best regards,
Maxime

Hi Maxime
I tested your solution 0.2.2 with the ESP32 az-delivery-devkit-v4 on PlatformIO, and I can confirm that It now functions as expected:
1: Callbacks for connect and disconnect are called even when defined later than the .begin() call
2: A disconnect do no longer freeze the board.
Many thanks!!
Cheers
Kim

Ok cool !
cheers,
Maxime


ENH: Restructure libcpp.vector and cover API with tests

In particular, add C++11 declarations, more const-correctness.
I have added a new file for testing C++11 methods, I think this can be later used to add more tests for container methods and algorithms, which have been added with C++11 and were not tested before, because otherwise these tests will fail on compilers where the default mode is still not C++11.

Will rework as requested in #488.

Any update on this?


Fixes typos.

Thank you, can you point us to where the typos are ?

The diff for the pull request should show them? The word ‘encapsulation’ was spelled incorrectly, as was the name of the Bulma CSS framework. Both in the readme file.

Spencer

On Apr 14, 2019, at 4:51 PM, Amine Belgacem<EMAIL_ADDRESS>wrote:
Thank you, can you point us to where the typos are ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

The diff for the pull request should show them? The word ‘encapsulation’ was spelled incorrectly, as was the name of the Bulma CSS framework. Both in the readme file. - Spencer
…
On Apr 14, 2019, at 4:51 PM, Amine Belgacem @.***> wrote: Thank you, can you point us to where the typos are ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

There was no "you should" instead "can you". Thank you for correcting us.


Pick routes using more realistic ratios

The current seed generators picks routes randomly. Whilst this gives us a spread of routes, it means the niche routes are way over represented.
This adds some approximate weighting to the routes, split by SCITT and HEI - so we should see more realistic numbers.

 Prototype: adjust weighting of routes to be more realistic


Dump at ZCL_ABAPGIT_FILE_DESERIALIZE=>FILTER_FILES_TO_DESERIALIZE (abap 731)

https://github.com/abapGit/abapGit/pull/6328 ?

Yes, probably, looks like the same code. Closing for now.


Fixed small typos in README.md

Fixing small readability issues in the README.md file

Thank you.


Company firewall blocking multipart/form-data requests

When I try running an example I get this. Any chance of not using "multipart/form-data" to POST data? I had a quick look at the source and "multipart/form-data" comes from the use of XMLHttpRequest/FormData combination. Would it be technically possible to use "application/x-www-form-urlencoded" media type instead?
Ta,
Glaukon
POST https://code.world/compile 403 (MediaTypeBlocked)
codeworld_shared.js:39
  | sendHttp | @ | codeworld_shared.js:39
  | compile | @ | codeworld.js:750
  | onclick | @ | (index):102

File Blocked
McAfee Web Gateway has blocked the file, because the detected media type (see below) is not allowed.
URL:
Filename:
Media Type (detected): multipart/form-data
Media Type (from file name):

Company Acceptable Use Policy
For assistance, please contact Helpdesk.

generated 2018-01-23 10:43:01 by McAfee Web Gateway
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36

I'm going to close this.  It's unfortunate, but it seems to be an overly restrictive corporate network policy, and working around it on the CodeWorld side is probably the wrong answer.


won't work with "padrino start"

... because padrino start doesn't load config.ru.
if works well if I do rackup config.ru -p 3000 but it doesn't when I do padrino start

This is a dupe of #1. I hope to fix this soon


Adjust abnormal flag mapping

BACKEND PULL REQUEST
Related Issue

Part 1 for #7897
This should at least fix the issue CA was experiencing.

Changes Proposed

Set the Abnormal and Normal coding only when they match a defined list of SNOMED codes that we support
If the SNOMED code that is provided does not match, we will log it and return null instead of setting the code to Normal

Additional Information

Will create an alert in a separate PR when we log an unsupported SNOMED code
⚠ As part of #7898 we should make sure that any results being sent to the CSV pipeline should also map to values here: https://github.com/CDCgov/prime-reportstream/blob/1ffae4ca0b04cd0aa9f169e26813ecd86df71bb5/prime-router/src/main/kotlin/metadata/Mappers.kt#L768 otherwise you get the following error from ReportStream that is not obvious to users uploading their results:
RS CSV API Error 400 Response:

{
  "id" : null,
  "submissionId" : 4261955,
  "overallStatus" : "Error",
  "timestamp" : "2024-07-11T20:43:28.954Z",
  "plannedCompletionAt" : null,
  "actualCompletionAt" : null,
  "sender" : "",
  "reportItemCount" : null,
  "errorCount" : 1,
  "warningCount" : 0,
  "httpStatus" : 400,
  "destinations" : [ ],
  "actionName" : "receive",
  "externalName" : "",
  "reportId" : null,
  "topic" : null,
  "bodyFormat" : "",
  "errors" : [ {
    "scope" : "item",
    "indices" : [ 1 ],
    "trackingIds" : [ "42daf9c8-9deb-4636-a040-380bde2b44cd+1+20240711" ],
    "field" : "test_result (test_result)",
    "message" : "The code '' for field test_result (test_result) is invalid. Reformat to HL7 specification.",
    "errorCode" : "INVALID_MSG_PARSE_CODE"
  } ],
  "warnings" : [ ],
  "destinationCount" : 0,
  "fileName" : ""
}

Testing

deployed to dev3
upload a bulk result with various SNOMED combinations
example with new SNOMEDs
DEV3_EX.csv

@fzhao99 @DanielSass @mpbrown Ready for re-review!

⚠ As part of https://github.com/CDCgov/prime-simplereport/issues/7898 we should make sure that any results being sent to the CSV pipeline should also map to values here: https://github.com/CDCgov/prime-reportstream/blob/1ffae4ca0b04cd0aa9f169e26813ecd86df71bb5/prime-router/src/main/kotlin/metadata/Mappers.kt#L768 otherwise you get the following error from ReportStream that is not obvious to users uploading their results:

about this bit - is this an issue with how we are handling the response (in other words, do we need to do work to convey info we're getting from RS back to the user)?
Definitely out of scope for this PR, just something to think about as we look at the next story for updating the bulk upload file validation

This is an example of a FHIR bundle with a nonsensical SNOMED (search "111") -- no abnormal/normal flag is added
hiv_bundle_with_nonsense_snomed.json


Examples 6 and 7 not working in RPI4B

Hey. Firs of all, thanks for this great tutorial. Is really fun & interesting!!
As for the problems I'm experiencing:
Example 6

Ran BSP=rpi4 make and copied kernel8.img together with fixup4.dat,  start4.elf (renamed to start.elf as per README comment) and bcm2711-rpi-4-b.dtb and config.txt with the specified contents to the SD.
Ran sudo screen /dev/ttyUSB0 230400. Black screen appears and then after pressing Enter nothing happens.

I tried with start4.elf and doesn't work. Also tried to download the latest firmware and same outcome..
Example 7

Ran BSP=rpi4 make and copied the kernel8.img to the SD.
 I checked whether I had everything correct with the toolchains and targets and the rest of the config. But since I've seen new commits have been done since this issue was close, maybe one of them broke this.
If you need any kind of extra info, just ping me. Sorry that I cannot provide more, but I don't really know how to debug it.

Hi @CPerezz,
that's strange. I just re-tested it on my Pi4. I loaded the newest versions of start4.elf, fixup4 and the dtb.
It works for me, and it doesn't make a difference if the start is named start.elf or start4.elf.

Do you have any other files on SD card?

Are you ejecting the SD card properly after writing to it from the host? This can often cause issues because the contents are not flushed onto the SD but reside in the OS cache when you don't eject/flush properly.

Hi @andre-richter , thanks for answering.
No other files are there:
> ls -la /run/media/boot/$USER
Permissions Size User Date Modified Name
.rw-r--r--   47k kr0   7 Nov 21:22  bcm2711-rpi-4-b.dtb
.rw-r--r--    56 kr0   8 Nov  0:26  config.txt
.rw-r--r--  5.4k kr0   7 Nov 21:22  fixup4.dat
.rw-r--r--  8.2k kr0   8 Nov  0:20  kernel8.img
.rw-r--r--  2.2M kr0   7 Nov 21:22  start.elf

Also. After writing/copying files to the SD I just do sudo umount /dev/sdYX and eject the USB adapter that has the SD card in it.
Will try to re-do completely from scratch example 6 and 7 later today to see what happens. But at this point. I tried everything. So if I can provide any other info that might help the debugging. Just tell me. Since it's weird, and also difficult to check since qemu doesn't support rpi4 on the -M option.

kk after doing everything from scratch again:
Example 6
I probably did something wrong since now I'm capable of booting the RPI4B and the Enter triggers the execution as expected breaking the infinite loop. Although the prints are indented and so the output looks like:
Output 1
               Output 2
                               Output 3
                                               Output 4

But it's fine. I played a bit with the println! macro to try to see why this happens but haven't been able to catch it yet.
Example 7
The kernel boots correctly if I load it in the SD and use screen as in example 6.
 A while ago, I changed all the kernel sources to conclude a line only with \n, and not print an explicit carriage return. The terminal part of minipush accounted for it, but I never realized that it breaks screen.
I carved out the terminal part of minipush for tutorial 6, so connection to the RPi now happens through an in-house tool as well. Please check out if the changes introduced in https://github.com/rust-embedded/rust-raspberrypi-OS-tutorials/commit/e1473099ff0b4ffc4c07fa24985bb55d8ef28f07 work for you.
Regarding tutorial 7, hard to say why this still fails. Even more so because tutorial 6 seems to work...

@andre-richter thanks again for doing these tutorials. Maybe this is related to my issue #81 ?

@CPerezz,
can you check if something changes when you use this kernel8.img as the chainloader on your Pi4 SD card?
It has the changes @abdes reported in #81.

Closing this for now since no feedback received.
We can reopen anytime if needed.

Hi @andre-richter I've been extremely busy. That's why I haven't been able to test your changes. I'll do ASAP. Sorry for the delay.


feat: Allow empty selectors in bindings values

This commit let's custom binding values omit the selector part of binding values selector->identifier#method.
If it is omitted then the controller will use the HTML element to which the stimulus controller is bound.

Hi Paul, thanks for the PR. It's been an age since I've looked at this code, but I don't see any obvious reason not to move forward with it. That said, we do need to make some changes:
      let [selector, target] = value.split('->')
      if (!target) {
        [target, selector] = [selector, this.element]
      }

First, please keep the order of the array on line 47 intact, or else it becomes extremely difficult to read. It's [selector, target] - you'll need to reverse the order of the elements on the right side of the equation eg. [this.element, selector].
Next, I'm pretty sure that we don't need the braces on 46 and 48 for a one-line statement. if (!target) [selector, target] = [this.element, selector].
Finally, we should add a note to the README that explains the shorthand.

Seems to have been handled in https://github.com/leastbad/stimulus-hotkeys/commit/4a676139c935661d3a9de9de1575eec652af885a thanks a lot @leastbad :pray:


Substitute DNS Resolver

This relates to #1174.
It would be great if we could substitute a resolver instead of using to_socket_addrs and getaddrinfo. It seems there was already a good amount of discussion around this in #1174, but I'm not sure what the conclusion was.
It seems like there are three options:

Implement custom connector with Connect instead of HttpConnector
Add resolver type to HttpConnector (#1174)
Modifying tokio's ClientProto(?). I admit I'm not sure what this actually means for end-users.

Honestly I think 2) makes a lot of sense because we get to avoid any duplication and maintenance efforts to keep a custom connector up-to-date / bug-free with HttpConnector. But again, I'm not sure if 3) is better?
Context for this is: we're trying to update from an old fork of hyper and had previously swapped out the resolver in the fork :).
@seanmonstar thoughts?

The ClientProto stuff is long gone, nothing to worry about there :)
I've seen others ask to replace the resolve in HttpConnector also, and it would be nice to be do so. The only thing that has held me back is that it would be another trait to need to stabilize. I don't have a good design for one, and haven't spent time trying to solve this, since so far I've figured that just copying the TCP connecting bits from the HttpConnector is pretty simple.
I'd be open to working this out, though!

I'd follow this issue and maybe even help:
https://github.com/tokio-rs/tokio/issues/363
Would be pretty nice to just use Tokio's DNS resolver in Hyper when it's ready. There are some unofficial crates to use in your custom connector that should not be that hard to add to your stack, e.g:
https://github.com/sbstp/tokio-dns

Ah okay great, forget about the ClientProto stuff then.
I think thinking about a stable trait design is a fair point and might be more involved than I expected given the wide range of use-cases hyper needs to support.
However, if a trait-bound on HttpConnector is the goal, then the only logic we can replace is here, right?
                        let work = dns::Work::new(host, port);
                        state = State::Resolving(oneshot::spawn(work, executor));

The input on some hypothetical resolve function would be: fn resolve(host: String, port: u16) as per dns::Work::new() and it would return a Future<Item=Iterator<Item=SocketAddr>, Error=io::Error> (This is the same trait structure as #1174).
Okay, but maybe that's not the end goal, what other possible use cases might be brought up?

Return results synchronously instead of a Future

This would be a strange use-case for hyper as "async I/O" is a point in the main page, is it fair to call this one a "write a custom HttpConnector"?

Take in more context than host: String and port: u16

Looking at several different DNS crates (trust-dns, abstract-ns) as well as the standard ToSocketAddrs trait, this set of arguments seems reasonable and standard. Maybe instead of String it could take an IpAddr?

Using a trait provided by another crate (like abstract-ns as discussed in #1174)

This would be a good point, I could see some sort of ToSocketAddrsFuture trait that's implemented and shared amongst crates so there's no need for new types to bridge implementations.

Let me know if I'm missing anything, or if you're worried about any other use-cases! The only thing I can see is possibly supporting a generic ToSocketAddrsFuture (or something) trait with other crates, which would include research into what crates are used, what should be on a generic trait, etc. It expands the scope from a trait for HttpConnector to a trait of any DNS resolver to plug into, which is quite a leap.
Anyways I think an initial step is for me to duplicate the HttpConnector and add in DNS substitution. That way I can continue without being blocked and if supporting a larger scope is required it can be prototyped outside of Hyper without requiring releases for the crate as a whole. If no larger scope is required though, it would be good to get the trait bound merged in!

Maybe instead of String it could take an IpAddr?

If we already had an IpAddr, we wouldn't need to do resolution, right? :D In fact, hyper does skip resolution if the hostname parses as an IpAddr.
I think it'd be reasonable to try to include a Resolve trait specifically for HttpConnector. What does it look like? Should it only be allowed to return io::Error, or should it allow any error, like Connect does?
trait Resolve {
    type Future: Future<Item=Self::Addrs, Error=io::Error>;
    type Addrs: Iterator<Item=SocketAddr>;
    fn resolve(&self, host: &str, port: u16) -> Self::Future;
}

Does it make sense to include a port as input? Or should the HttpConnect just override the any port when it receives the SocketAddr?

Didn't see your reply @pimeys, thanks for the links! I'll definitely keep an eye on tokio-dns, and would be happy to wait for it if that's the right solution.
@seanmonstar: Ah, yeah oops, that would not be necessary :P.
Does Connect allow users to define any error? From the code it looks to have some sort of bound on io:Error like the proposed trait, although you could just create io::Error from your Error.
Ah, okay, I'm looking at the 0.11 branch, on master branch it does allow any error. Given that HttpConnector is an implementation of Connect and defines its error type as io::Error it would make sense to me to have the Resolve trait (bounded on HttpConnector) as io::Error as well.
Good point with the port:

Looking at trust-dns, the implementation for lookup_ip does not take in a port and returns IpAddrs
tokio-dns::Resolveronly operates on the host and returns IpAddrs as well.
abstract_ns::Resolve operates on only a string as well, it returns SocketAddrs though.

Given the API for these crates, I would lean towards avoiding passing in the port and have the future return Iterator<Item=IpAddr> and constructing the SocketAddrs from the IpAddrs and port.
trait Resolve {
    type Future: Future<Item=Self::Addrs, Error=io::Error>;
    type Addrs: Iterator<Item=IpAddr>;
    fn resolve(&self, host: &str) -> Self::Future;
}

Let me know what you think!

Great! How does the generic on HttpConnector play out in practice? Annoying? Ignorable?
I've wanted to be able to change out the default resolver for trust-dns for a while, and besides wanting to wait for it to be as reliable as getaddrinfo, the other problem is some of the constructors for HttpConnector would break. This change could actually make the switch compatible.
Basically, it could be similar to HashMap that has a default hasher that doesn't otherwise expose what it is, which allowed switching from SipHash-2-4 to 1-3. There could be a DefaultResolver newtype that hides its details, besides a GAI resolver type.
I'll be of limited availability for the next week, but I'd welcome this change for the 0.12 release if someone would like to make a PR!

This may slip out of 0.12, as it isn't high on my priorities, and I'd like to release this week.

Oh, sorry for ignoring this thread!
Happy to contribute a PR once we're satisfied with the code, we're still on 0.11 so it would require some changes to work with 0.12.

I got around to fleshing this out in #1674.


Create Windows shortcuts using menuinst2

notebook 7.0.8
Destination channel: defaults
Links

Upstream repository

Explanation of changes:
This PR improves how shortcuts are handled. Previously, shortcuts were created using menuinst v1, which will no longer be maintained and does not support MacOS and Linux. Miniconda was installed into Miniconda (64-bit) and Anaconda Distribution into Anaconda (64-bit). Other apps (like this package) were always installed into Anaconda (64-bit). Multiple installations of Miniconda/Anaconda Distribution were installed into the same directory.
This PR alleviates these issues.

Convert Windows shortcuts to menuinst v2
Use installation directory for Start Menu folder name
Add code to handle the transition into menuinst v2. Since the menuinst version that installs the shortcut is in the base environment, run_constrained is not sufficient here.

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_65okf7xvdi/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_a3cetvp6sm/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_b0i0djb9m_/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_7c0x4s9hj5/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_5fwxucuc8h/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_f8tj0d23tv/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_e2lbfwwoua/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_9c75i5riab/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_desxqswpa0/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_4fx2apo97q/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_5356ftmmou/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_c8w6fhzias/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_a115xpemlq/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_f9dv80xn71/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found


Minor correction

Hi!
On the line 14, it has to be .\handle.exe instead of handle
Before correction (line 14)
handle -c $eventHandle -p $d2pid -y -nobanner
After correction (line 14)
.\handle.exe -c $eventHandle -p $d2pid -y -nobanner
Have a good one! Thanks for the tool, really useful!

Ahh ya, left overs from when I was adding the local script path to the system path and just calling handle.
I guess the PowerShell instance I was running still had that path change, so both calls were working.
the fix is pushed.


fix: added target type input property for alb ingress module

what
added configuration for target type, to support instance type for EC2
why
Seems like awsvpc network doesn't work properly with ec2 (at least I didn't manage to get it work for few hours)

any concerns with this one?

/terratest

Thanks for your contribution @vsamofal


Glove word embeddings assignment

If Glove word embeddings is assigned before tf.global_variables_initializer(). The embedding will be randomly initialized. It will not use Glove word embeddings.

Thanks for pointing that out. I will change the order.


add a hidden, experimental config option --Xdiscv5-enabled default false

experimental option for discv5 support

this CLI option name should match what geth uses

since we haven't done the implementation yet, if this flag is specified, just log a warning but don't abort startup.


Compile Error - prestashop <IP_ADDRESS>

Expected behavior
For the module to work normally
Actual behavior
Error message after upgrade to Prestashop 17.7.0 from <IP_ADDRESS>
Re-install produces the same message
Steps to reproduce the behavior
Error message on install (alongside HTTP error 500):

Compile Error: Declaration of Mollie::getContainer($id = false) must be compatible with ModuleCore::getContainer(): Symfony\Component\DependencyInjection\ContainerInterface

[Symfony\Component\Debug\Exception\FatalErrorException 0]

Perhaps it's not compatible with <IP_ADDRESS> yet?
Environment

PrestaShop version: <IP_ADDRESS>
Mollie module version: 4.1.1
PHP version: 7.3.24

Just noticed there's already an outstanding issue addressing this.


feat(Dockerfile): add health check to Dockerfile

This commit adds a health check to the Dockerfile. The health check is set to run every 30 seconds with a timeout of 30 seconds. If the health check fails 3 times, it will mark the container as unhealthy.

The healthcheck should be much quicker after the passthrough feature has been implemented: https://github.com/elifesciences/enhanced-preprints-biorxiv-xslt/pull/72


Issues trying to take advantage of ability to move hassos-data filesystem to separate device

Seems that booting HassOS Dev 3.0 with a relocated hassos-data doesn't always work -- at least on my ODroid HC1, even after PR#318  Mentioning @berg since he is author of PR#318.
I wasn't sure if it warranted a new issue, so I commented on the PR, but that was not the correct process, so I created this issue.
For kernel logs and work so far see:

https://github.com/home-assistant/hassos/pull/318#issuecomment-460028839
https://github.com/home-assistant/hassos/pull/318#issuecomment-460029474

Gotcha, thanks. I think that the errors you saw from attempts one and two were related to not swapping around the partitions properly; let's focus on the partially successful attempts three and four.
The flakiness you're seeing isn't too far from what I'd originally seen—which was the original motivation for this patch—so this is a bit concerning. It does look like you've successfully managed to pull in the PR, so that's good.
Any chance that—when it fails—you can provide a complete boot log? I think there's something failing earlier in the boot when you get to

[DEPEND] Dependency failed for HassOS data partition.

... but it's not included in the logs, so being able to see all the way back to the first line the kernel prints would be helpful.

Full logs are uploaded here, note that I copy/pasted from the serial console so it is possible there are some transcription errors:

Boot failure, when this happens I can still ping the device but can't get a shell or any other response.
Boot success, no system changes, just powercycled after the above failure and it worked.

Wild speculation: It seems if I wait a while ~10 minutes??? the next boot works usually but if I reboot quickly after the hang then it does not.  Wondering if there is an fsck or resize operation still doing something in the background and waiting for that to complete even though there are no logs allows the next boot to work???

failed:
[ 16.942218] usb 4-1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=31.01
versus good:
[ 5.614275] usb 4-1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=31.01
Apparently your usb-disk takes  a nap sometimes. So the reason it sometimes works is related to your hardware. We could wait longer for the mount to become available. Also some services do startup after the mount is available, like NetworkManager and other do not, like getty and ssh.

I am playing around with naive sleeps and polling loops in the hassos-expand script but it takes 20-30 minutes per test cycle with my current workflow so progress is slow.
Did some googling and ran across this problem report which got me thinking that maybe I do have a power problem -- especially since a couple times on boot it didn't recognize the network adapter, which I had been thinking was unrelated.
I have the ODroid 4A supply, but maybe I should've bought the 6A.

  Once I figure out logging I will try again to debug.
I ordered a higher power supply and a much newer model SATA SSD (Patriot Burst 240GB, only $30), so I will have some extra hardware to play with in case that is a better solution.  The SSD will be here Friday but the power supply will be a week or so.

It should wait 90s before giving up on your disk—I'm more worried I've got the dependencies for the hassos-expand target set incorrectly or there's a bad interaction here.
@TonyApuzzo would you mind building this branch:
https://github.com/berg/hassos/tree/berg-test-expand
And capturing some logs if it fails/works? It is just adding extra logging, so I do not expect a behavior change (but it is build off current HEAD, so there may be other changes).

Thanks for the update, I will try it as soon as I can, might be a day or two.

Curiouser and curiouser... it seems the behavior has changed with the latest pull.
I can't get the resize to work at all anymore.  It is corrupting the data partition on SSD.  I tried several times and it failed with the same error each time failure gist.
However, if I manually resize the target partition to be full, then I get a good boot success gist
Basic process as a recap:

recompile hassos from branch (berg-test-expand) via make odroid_xu4 in my docker environment on windows
burn img to sdcard on build machine (windows)
mount ssd in odroid hc1
mount hassos sdcard in usb card reader on hc1
boot odroid hc1 using armbian sdcard
create empty large partition on ssd /dev/sdc1
dd if=/dev/sda4 of=/dev/sdc1 bs=4M
e2label /dev/sda4 hassos-data-orig
e2label /dev/sdc1 hassos-data
OPTIONAL MANUAL RESIZE: e2fsck -f /dev/sdc1 resize2fs /dev/sdc1
shutdown armbian
remove armbian boot sd card from internal reader
remove usb card reader with hassos sd card
mount hassos sdcard in hc1 internal card reader
boot hc1
fail or good depending on whether or not I manually resized the partition

Note: The above logs are with a new SSD, I did attempt the same with my old SSD and I got roughly the same bad behavior with a simple dd copied (undersized) fs in a big partition.  The filesystem ended up corrupt although the specific error messages were different.  I will attempt to capture a trace of that as well but am running into some different problems duplicating the error now.

And a couple more logs.  I think that I figured out why the old SSD is not recognized on boot, it does seem to be a power related issue.  If I mount the old SSD (m4) with a powered USB hub, then it is recognized always.  However, there is still some sort of race condition with the partition resizing and mounting.
WIth the external hub, the first time I boot up with the hassos-data partition copied, I get a straightforward failure 5
If I reboot with the exact setup after the previous fails, then it boots to completion but I end up with a non-resized filesystem (1GB) and then hassio fails to provision itself since the FS is too small failure 6
I'm done for now but hopefully these logs shed some light on what is happening.

With the change that @berg made and with my new SSD, I have not had any mount failures, so I think the problems that caused me to create this issue have been addressed.


Implement tutorial page

UI: https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=2011%3A0
Spec: https://g0v.hackmd.io/sB_zayWjTo-W0R7xe_U34w#分項解說

I am seeing that some image files are > 50KB. I suggest using ImageOptim or pngquant (uses the same core as TinyPNG, but is easier to use since they run on local machine) and perform lossy compression on big image files first.

Thanks for the update! I have resolved comments that have been implemented. What's left are:

tutorial.js image tab (tabContainer) should use <a>; consider using semantic tag nav for tabContainer
use fileMock and remove styleMock


yarn: no option: --colors

Describe the bug
I have a Ubuntu 18.04 Server and wanted to install koel, after when runing php artisan koel:init, after i set the database i get the yarn no option --colors error.
To reproduce
Steps to reproduce the behavior:

clone koel
run composer install
run php artisan koel:init
See error

Expected behavior
I am not really sure what more information i can provide
Screenshots

Environment

Koel version v4.1.0
OS: Ubuntu 18.04
PHP version v7.2
Node version v12.13

Additional context
This is my first issue on github i apologize if its not supposed to be posted here

What's your yarn version?

apparently I was running an old version, I updated yarn to 1.19. but no i get an error while building

Where do I start on reading this error?

Can you try this? https://github.com/phanan/koel/issues/1093#issuecomment-549186081.

Released v4.2.0 which should work with Node 12.x. Feel free to open another issue if it's not the case.

yea downgrading to NOde 10.x fixed it. but weirdly enough going to the home page on my server doesn't show a login in button or anything except the logo, mail and pw

I'm on Firefox 70.0

Hi @toter200  Any update here? If you're still having trouble can you check for errors in the browser console?

I checked it and nothing was there, i have since moved to another service so i cant tell anything more

I ran into this error, and it was caused by a outdated version of yarn. I fixed it by installing hte latest version via this method:
curl --compressed -o- -L https://yarnpkg.com/install.sh | bash

Thanks for the details on how you fixed it @DDriggs00. Since this looks to be resolved by an update of Yarn and not an issue with Koel directly I'm going to close this. If anyone runs into this in the future and a Yarn update doesn't resolve it please create a new ticket and refer back to this one.


NIFI-6455 - Fix issue preventing scrolling all the way to the bottom …

…of certain tables.
The issue was related to the version of slickgrid. Upgrading that to a newer version solves this problem. It is not the latest version of slickgrid, but the latest at the same minor version (from 2.3.3 to 2.3.23). slickgrid 2.4.x presents other challenges and would require a larger effort.
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
Enables X functionality; fixes bug NIFI-YYYY.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[X] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[X] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[X] Has your PR been rebased against the latest commit within the target branch (typically master)?

[X] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

+1 LGTM


Edit Add Command to handle remind

Closes Issue #3

Codecov Report

Merging #74 into master will increase coverage by 0.21%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master      #74      +/-   ##
============================================
+ Coverage     70.70%   70.91%   +0.21%
- Complexity      402      407       +5
============================================
  Files            75       75
  Lines          1246     1255       +9
  Branches        122      125       +3
============================================
+ Hits            881      890       +9
  Misses          329      329
  Partials         36       36

Impacted Files
Coverage Δ
Complexity Δ

...ava/seedu/address/model/assignment/Assignment.java
96.42% <ø> (ø)
16.00 <0.00> (ø)

.../java/seedu/address/logic/commands/AddCommand.java
100.00% <100.00%> (ø)
8.00 <1.00> (ø)

...a/seedu/address/logic/parser/AddCommandParser.java
100.00% <100.00%> (ø)
10.00 <8.00> (+5.00)

Continue to review full report at Codecov.

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


Initial 503 status at startup

As described at http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html under the section Why is it so Slow to Register a Service?, it is possible, although not recommended, to configure eureka.instance.leaseRenewalIntervalInSeconds when using Eureka.
Is there a similar configuration for Consul?  After our services start, we consistently receive a 503 for a varying period of time before the services start processing requests.  I assume this is because of the same reason described in the URL above (i.e., A service is not available for discovery by clients until the instance, the server and the client all have the same metadata in their local cache [so it could take 3 hearbeats]).

So the eureka client sends heartbeats to the eureka server. Consul pings your app (a http health check). So it's a different model. You can configure how often consul performs the healthcheck with spring.cloud.consul.discovery.healthCheckInterval. The default is 10s (10 seconds). If you're using ribbon, you can tweak that as well.

Thanks, Spencer. We are using Ribbon. What is the configuration property for configuring Ribbon's health check interval?  I haven't found it online or in the source code yet.
Also, is there, or do you plan to document, a site where all of the possible Spring Cloud project configuration properties are listed?

By the way, we are using Feign with Ribbon.

OK, after digging some more into the source code, I found spring.cloud.consul.discovery.heartbeat. I see that it's set by default to 30 seconds. Is this the property I need to change?

@kabennett you only need to set the heartbeat if it's enabled, which it isn't by default.

The ribbon property is ribbon.ServerListRefreshInterval=10000 (Case is important).

Thank you for your response, Spencer.  I will tweak these settings to reduce the period of time that we receive the 503 statuses.


State Functions - stuck after 3 events?

Describe the bug
We are currently experiencing something which I would consider as a bug. If we deploy a function which affects the state, it stops working at one point, to be exact -> after consuming / processing 3 events.
At the same time, it seems that the bookkeeper API is being affected by it - a request to the state of the function will time out.
To Reproduce
Steps to reproduce the behavior:

Spawn a standalone pulsar
deploy the attached function
produce 10 (3+) messages
See error

Expected behavior
In case the function is okay - it should consume all events and produce the outputs. In case it is a real error, it should stop the function from running, then either restart or error out (whatever the designed solution is)
Screenshots
You can see me reproducing this in the following screencast - https://asciinema.org/a/TqyVCb5lTvO6Y6l0yKKRuPr8g
Desktop (please complete the following information):

OS: Foundation - MacOS using Docker with the latest pulsar docker image
function: using python

Additional context
Using "querystate" by the cli will return the following error - Reason: javax.ws.rs.ProcessingException
statefunction.txt

Additional information - I was able to make it up to a 1000 processed messages, by manually adding messages 1 by 1 ... slowly ramping up to 150 messages every 3 seconds, where it broke with the same result -> being stuck at 3 messages. Will try to find and attach a log of the state table service if I understand where to find it.

thanks @Pixelartist for the reporting. It would be great if the log of function worker could be provided.

Hello,
I reproduced the problem once more - with the following output within the log files:
logs/pulsar-standalone.log - empty
tmp/functions/public/default/StateMe/StateMe-0.log - StateMe-0.log
Please see below - input has more messages than output where java shows a lot of io-errors during restart.
running: bin/pulsar-admin functions status   --tenant public   --namespace default   --name StateMe
{
  "numInstances" : 1,
  "numRunning" : 1,
  "instances" : [ {
    "instanceId" : 0,
    "status" : {
      "running" : true,
      "error" : "",
      "numRestarts" : 0,
      "numReceived" : 360,
      "numSuccessfullyProcessed" : 357,
      "numUserExceptions" : 0,
      "latestUserExceptions" : [ ],
      "numSystemExceptions" : 0,
      "latestSystemExceptions" : [ ],
      "averageLatency" : 44.71126457556289,
      "lastInvocationTime" :<PHONE_NUMBER>896,
      "workerId" : "c-standalone-fw-localhost-8080"
    }
  } ]
}

running: ```
bin/pulsar-admin functions querystate
--tenant public
--namespace default
--name StateMe
--key pulsar

null
Reason: javax.ws.rs.ProcessingException

running:
`bin/pulsar-admin topics stats-internal public/default/state-input`

{
"entriesAddedCounter" : 412,
"numberOfEntries" : 412,
"totalSize" : 25976,
"currentLedgerEntries" : 412,
"currentLedgerSize" : 25976,
"lastLedgerCreatedTimestamp" : "2020-03-02T08:24:19.889Z",
"waitingCursorsCount" : 1,
"pendingAddEntriesCount" : 0,
"lastConfirmedEntry" : "12:411",
"state" : "LedgerOpened",
"ledgers" : [ {
"ledgerId" : 12,
"entries" : 0,
"size" : 0,
"offloaded" : false
} ],
"cursors" : {
"public%2Fdefault%2FStateMe" : {
"markDeletePosition" : "12:356",
"readPosition" : "12:412",
"waitingReadOp" : true,
"pendingReadOps" : 0,
"messagesConsumedCounter" : 357,
"cursorLedger" : 13,
"cursorLedgerLastEntry" : 4,
"individuallyDeletedMessages" : "[]",
"lastLedgerSwitchTimestamp" : "2020-03-02T08:24:19.916Z",
"state" : "Open",
"numberOfEntriesSinceFirstNotAckedMessage" : 56,
"totalNonContiguousDeletedMessagesRange" : 0,
"properties" : { }
}
}
}

running:
` bin/pulsar-admin topics stats-internal public/default/state-output`

{
"entriesAddedCounter" : 326,
"numberOfEntries" : 326,
"totalSize" : 58601,
"currentLedgerEntries" : 326,
"currentLedgerSize" : 58601,
"lastLedgerCreatedTimestamp" : "2020-03-02T08:24:36.057Z",
"waitingCursorsCount" : 1,
"pendingAddEntriesCount" : 0,
"lastConfirmedEntry" : "14:325",
"state" : "LedgerOpened",
"ledgers" : [ {
"ledgerId" : 14,
"entries" : 0,
"size" : 0,
"offloaded" : false
} ],
"cursors" : {
"my-subscription" : {
"markDeletePosition" : "14:325",
"readPosition" : "14:326",
"waitingReadOp" : true,
"pendingReadOps" : 0,
"messagesConsumedCounter" : 326,
"cursorLedger" : 15,
"cursorLedgerLastEntry" : 4,
"individuallyDeletedMessages" : "[]",
"lastLedgerSwitchTimestamp" : "2020-03-02T08:24:36.107Z",
"state" : "Open",
"numberOfEntriesSinceFirstNotAckedMessage" : 1,
"totalNonContiguousDeletedMessagesRange" : 0,
"properties" : { }
}
}
}

Restart:

bin/pulsar-admin functions restart   --tenant public   --namespace default   --name S
tateMe
Restarted successfully

after restart:
`bin/pulsar-admin functions status   --tenant public   --namespace default   --name StateMe`

{
"numInstances" : 1,
"numRunning" : 0,
"instances" : [ {
"instanceId" : 0,
"status" : {
"running" : false,
"error" : "UNAVAILABLE: io exception",
"numRestarts" : 0,
"numReceived" : 0,
"numSuccessfullyProcessed" : 0,
"numUserExceptions" : 0,
"latestUserExceptions" : [ ],
"numSystemExceptions" : 0,
"latestSystemExceptions" : [ ],
"averageLatency" : 0.0,
"lastInvocationTime" : 0,
"workerId" : "c-standalone-fw-localhost-8080"
}
} ]
}

-> [StateMe-0_after_restart.log](https://github.com/apache/pulsar/files/4274328/StateMe-0_after_restart.log)

[display_log.log](https://github.com/apache/pulsar/files/4274460/display_log.log)

display_log.log

I'm getting the same error with my java source connector that uses state. I thought it might be because I'm doing too many concurrent state operations, but your StateMe function doesn't seem to use state concurrently...
My source connector seems to get this error quite randomly. Sometimes it happens after ~1k state operators and sometimes more than 100k, but I think that it usually happens sooner with increased throughput.
I'm getting this error with both standalone deployment and three bookie deployment.

Closed as stale. Please create a new issue if it's still relevant to the maintained versions.


Trace output unhelpful

Bug Report
Steps to Reproduce:
run generation with
--violate
--trace-constraints
Expected Result:
trace file produced that is helpful?
trace file tells which constraints have been violated.
Actual Result:
Lots of information about default values is produced (length < 1001)
no constraint is shown to be violated

Additional Context:
i do not know what trace should be doing instead.

See https://github.com/ScottLogic/datahelix/blob/master/generator/docs/TracingOutput.md for details on expected behaviour


feat(#140): embeddings.py, vector.py

closes #140

PR-Codex overview
This PR introduces new dependencies, refactors model testing, adds licensing information, and implements vectorization and embedding functionalities.
Detailed summary

Added transformers and torch dependencies
Refactored model tests for test_pre_name.py, test_embeddings.py, test_vector.py
Added licensing information to test files
Implemented vectorization in Vector class
Implemented token embedding in Embeddings class

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor merge

@rultor merge

@h1alexbel OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@h1alexbel Done! FYI, the full log is here (took me 12min)


Add slice-timing correction experiment

Getting a handle on this structure.
It was a little bit counter-intuitive that we use attrs['meta'] instead of attrs. This resulted in a new image containing a shallow copy of the old image's metadata, so popping invalidated metadata removed it from the old image as well as the new.
The clean interactions with scipy are very nice.

Yes, we should probably move the metadata to attrs - I was just reflecting on what to about mergeing the BIDS data with stuff that we need.   I'll add an issue.


deleteMessage throws an uncaught error (grammy  v1.16.0)

./node_modules/grammy/out/core/error.js:35
    return new GrammyError(`Call to '${method}' failed!`, err, method, payload);
           ^
GrammyError: Call to 'deleteMessage' failed! (400: Bad Request: message to delete not found)
    at toGrammyError (./node_modules/grammy/out/core/error.js:35:12)
    at ApiClient.callApi (./node_modules/grammy/out/core/client.js:86:48)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  method: 'deleteMessage',
  payload: { chat_id: -[ID], message_id: 1745798 },
  ok: false,
  error_code: 400,
  description: 'Bad Request: message to delete not found',
  parameters: {}
}

This happens because you try to delete a message that does not exist. Telegram returns an error, and grammY throws it. You need to await all promises in your code and install an error handler on your bot: https://grammy.dev/guide/errors.html

This happens because you try to delete a message that does not exist. Telegram returns an error, and grammY throws it. You need to await all promises in your code and install an error handler on your bot: https://grammy.dev/guide/errors.html

Well, that's the thing - I do have an error handler and it does indeed catch other (internal grammy) errors successfully, but this one gets thrown

Do you ever call next without await?

Do you ever call next without await?

nope, I don't use next at all

You are not using await at all. If you start using async/await correctly, error handling will work as expected.

await ctx.api.deleteMessage(ctx.message.chat.id, 1000) in case it wasn't clear what I meant

await ctx.api.deleteMessage(ctx.message.chat.id, 1000) in case it wasn't clear what I meant

`const { Bot, Context } = require("grammy")
, bot = new Bot(process.env.TOKEN)
async function del(ctx) {
await ctx.api.deleteMessage(ctx.message.chat.id, 1000)
}
bot.on("message", ctx => {
console.log("got context",ctx.message.chat.id,ctx.message.message_id)
del(ctx)
})
bot.catch( err => console.log("caught error:", err.error) )
bot.start()`
produces exact same error.
node v16.15.0

This isn't a platform-specific issue. You still just doesn't await all calls.

async function del(ctx) {
await ctx.api.deleteMessage(ctx.message.chat.id, 1000)
}
bot.on("message", ctx => {
console.log("got context",ctx.message.chat.id,ctx.message.message_id)
del(ctx)
})

Here, you are wrapping the await-ed deleteMessage call in an async function, del. That's unnecessary, but that's not the issue. But in the message handler, you are not await-ing that del function. It is an async function, so, it must be await-ed if you don't want this error to occur.
If you are trouble with making the handler async, just take a look at literally every single code snippet in the documentation at https://grammy.dev. It's like this in-case if you still can't find out how:
bot.on("message", async (ctx) => {
  // ...
  await del(ctx); // or,
  await ctx.api.deleteMessage(/* ... */);
});

Thank you that resolves the issue.
Sure enough I didn't check all the snippets as not all apply in my use case, I was going off bot.on("message" snippets, where .on() is not qualified as async


Responsive Layout

At the moment, the website works just fine on desktop-wide screens, although on mobile it looks very squished. I think it'd be good to have breadcrumbs / moving menus to optimize everything for mobile and otherwise narrow screens.

Done


Public Site: Home page: tags - clicking tags is wrong

On the public (publish) site, on the home page, in the tags list, clicking on a tag with a zero count causes the display of an empty, meaningless, page; whereas when clicking on a tag with a non-zero count nothing happens!

This was a problem with the server-side query, fixed with https://github.com/materials-commons/materialscommons.org/commit/b0bf84d9f4c87f7122e497f281d246dd30d1854e


rollup 0.61.0 with rollup-plugin-node-resolve 3.3.0 leads to messed up undefined values

Reduction:
// hello.js (content unimportant)
const hi = 'hello';
export default hi;

// index.js
import hi from './hello.js'; // without this nothing bad happens
var a;
console.log(a === undefined);

Compile these with from the same directory:
require('rollup').rollup({ input: './index.js', plugins: [require('rollup-plugin-node-resolve')()] })
  .then(b => b.generate({ format: 'cjs' }))
  .then(c => console.log(c.code));

And it logs:
'use strict';

var a;
console.log(a === undefined$1);

The oddness here is undefined$1. Commenting out the import seems to fix the issue.

Probably related to https://github.com/rollup/rollup/issues/2290

Yes, it is definitely rollup/rollup#2290. Sorry for this.

No problem, 💩 happens!


Hermes always uses max_gas for transactions

Crate
Hermes ibc_relayer v0.7.1
Summary of Bug
Hermes transaction always use max_gas amount.
https://www.mintscan.io/osmosis/txs/E742F9EFE2E97A5FCD71FDB3CCDF2FF02BEE47DE5B2D0A51110805736F67C0E4
Version
v0.7.1
Acceptance Criteria
Hermes use automatic gas adjustment and gas_adjustment from config

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Can you explain in a bit more detail the problem?
Was Hermes configured with max_gas 60,000,000 (or thereabout)? It would be good if you can share the gas-related configuration details from config.toml for chain Osmosis.
Note that Hermes will by default try to simulate each tx, thus obtaining an approximate amount of gas it should use, and thenit will subsequently submit the transaction with that approximated amount (the amount is adjusted up using gas_adjustment). If the tx simulation fails, then Hermes will simply use the configured max_gas.
https://github.com/informalsystems/ibc-rs/blob/5d38857ac41affd93573c100fedf333b979dfcf3/relayer/src/chain/cosmos.rs#L335-L343

Hi,
my config is the same as issue 1342
https://github.com/informalsystems/ibc-rs/issues/1342#issuecomment-918590572
for Osmosis, Crypto.org and Cosmos, the max_gas value is used for every transaction.
the transaction shared is an example.

Hi @Galadrin! It appears that you have configured gas_adjustment=5 for the osmosis-1 chain in your config.toml. And that probably caused hermes to use the max_gas based on this calculation ->
https://github.com/informalsystems/ibc-rs/blob/5d38857ac41affd93573c100fedf333b979dfcf3/relayer/src/chain/cosmos.rs#L405-L410
Can you try a gas_adjustment < 1 i.e. 0.5?

I have the same symptom on Crypto.org and Cosmos chain.
and the issue is not present using v0.7.0

here is 2 transaction on Cosmos and Crypto.org
I've limited the max_gas on cosmos to not drain the wallet by $200 per days.
https://www.mintscan.io/cosmos/txs/D5C5701811BD5639E892FDE9AA382762B66BC6AA3D149AD621D14EBAF8B9E8E4
https://www.mintscan.io/crypto-org/txs/32C43358FAF5A36F1748F4114CDF105544958EBA5D72163FA07F500400E0906F

Are you still seeing this problem? And did you get a chance to try my previous suggestion for gas_adjustment?

Are you still seeing this problem? And did you get a chance to try my previous suggestion for gas_adjustment?

Hi,
Yes, still have the issue.
I tested with 0.5 then 0.1 for gas_adjustment with same result.
then remove the parameter, always with same result.

@Galadrin Do you have any Hermes logs (preferably with log_level = "trace") that you could share with us?

@romac please find attached the hermes logs after restart with log_level = "trace".
I've check and some TX have been made.
hermes.log

Here's an example I would like to understand.
The hermes config for this chain is:
gas_price = { price = 0.001, denom = 'uosmo' }
max_gas=1000000

The resulting transaction:
Gas (used / wanted)
453,860 / 1,000,000

If I undestand this correctly, the fee paid should be 0.00045OSMO
Instead, the actual fee is Fee 0.001000OSMO
https://www.mintscan.io/osmosis/txs/85C390DDE1A501A4512BF7F62C0CE2113C9ED0C0A480124183AA7FCA28DB784E

Hi @mircea-c, I'm not totally agree :
on Osmosis chain, my gas fee settings are :
gas_price = { price = 0.000, denom = 'uosmo' }
max_gas = 60000000

on Cosmos chain :
gas_price = { price = 0.001, denom = 'uatom' }
max_gas = 1000000

https://www.mintscan.io/cosmos/txs/E7BAAC35019236CF1D52276C40EAF36326A07C587EBF7719A2FE7BF9762B6672
on Crypto.org chain :
gas_price = { price = 0.025, denom = 'basecro' }
max_gas = 8000000

https://www.mintscan.io/crypto-org/txs/F1C70D57A9FF5028DDBF6E39789AD3206DE14B9F4A29E82E6A047521BFC3D83A

Here's an example I would like to understand.
The hermes config for this chain is:
gas_price = { price = 0.001, denom = 'uosmo' }
max_gas=1000000

The resulting transaction:
Gas (used / wanted)
453,860 / 1,000,000

I think Hermes submitted this transaction specifying that it allocates 1,000,000 gas, so that's how much was spent from the relayer wallet. The chain/execution module only required 453,860 only in fact. In this example, Hermes submitted the tx specifying 1,000,000 gas because of one of two reasons:

Hermes did a /simulate and found out that the chain estimates it will take 1 million gas for that specific tx, so Hermes will use that exact amount (adjusted with gas_adjustment) or
Hermes was unsuccessful in doing the /simulate for that tx, and so it used the predefined max_gas from config.toml for that chain.

The first option is unlikely. The second one is more likely. Searching the Hermes logs for tx hash 85C390DDE1A501A4512BF7F62C0CE2113C9ED0C0A480124183AA7FCA28DB784E could probably reveal what is the cause for unsuccesful tx /simulate.

@romac please find attached the hermes logs after restart with log_level = "trace".
I've check and some TX have been made.
hermes.log

This is a good first step, thank you @Galadrin ! The relevant lines of log are as follows:
$ cat hermes.log | grep 'estimated'
Sep 22 20:07:02 Beast hermes[28217]: Sep 22 20:07:02.542 TRACE [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" }
Sep 22 20:07:21 Beast hermes[28217]: Sep 22 20:07:21.557 TRACE [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" }
Sep 22 20:07:42 Beast hermes[28217]: Sep 22 20:07:42.523 TRACE [cosmoshub-4] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uatom", amount: "1000" }], gas_limit: 1000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uatom", amount: "1000" }], gas_limit: 1000000, payer: "", granter: "" }
Sep 22 20:08:02 Beast hermes[28217]: Sep 22 20:08:02.466 TRACE [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" }
Sep 22 20:08:56 Beast hermes[28217]: Sep 22 20:08:56.123 TRACE [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" }
Sep 22 20:09:15 Beast hermes[28217]: Sep 22 20:09:15.281 TRACE [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" }
Sep 22 20:09:48 Beast hermes[28217]: Sep 22 20:09:48.881 TRACE [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 60000000, payer: "", granter: "" }

Normally, the fee should be adjusted down, to smaller amounts. But it seems to remain unchanged. Most likely the /simulate fails. We will do some debugging locally and come back to you. Would you be open to running Hermes build from a master or a developer branch?

There is also this case as described in the code comments.
        // Try to simulate the Tx.
        // It is possible that a batch of messages are fragmented by the caller (`send_msgs`) such that
        // they do not individually verify. For example for the following batch
        // [`MsgUpdateClient`, `MsgRecvPacket`, ..., `MsgRecvPacket`]
        // if the batch is split in two TX-es, the second one will fail the simulation in `deliverTx` check
        // In this case we just leave the gas un-adjusted, i.e. use `self.max_gas()`

Would you be open to running Hermes build from a master or a developer branch?

Yes, we can run engineering build if needed. it can't be worst than today ;)

Hi,

Would you be open to running Hermes build from a master or a developer branch?

Yes, we can run custom build if needed for test.

@Galadrin @mdyring So that's indeed a regression introduced in Hermes v0.7.0 which only occurs with chains based on Cosmos SDK 0.42. Indeed, when doing the compatibility upgrade for SDK 0.43, we introduced a backward-incompatible change which broke the tx simulation on 0.42.
We have a fix for this in #1405 if you want to run a custom build of Hermes and see if it does indeed fix the problem for you. If you enable log_level = "debug" you should see the fee being adjusted properly, eg.
Sep 30 18:37:58.791 DEBUG ThreadId(29) [ibc-1] send_tx: sending 2 messages using account sequence 5
Sep 30 18:37:58.811 DEBUG ThreadId(29) [ibc-1] default fee: Fee { amount: "900000stake", gas_limit: 900000000 }
Sep 30 18:37:58.836 DEBUG ThreadId(29) [ibc-1] simulated gas: Ok(Some(GasInfo { gas_wanted: 0, gas_used: 117532 }))
Sep 30 18:37:58.836 TRACE ThreadId(29) [ibc-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: "900000stake", gas_limit: 900000000 } to Fee { amount: "130stake", gas_limit: 129286 }

Hi @romac
here is the steps I follow :
$ cd hermes-sources/
$ git fetch --all
$ git checkout origin/romac/fee-simulate-0.42
$ cargo install ibc-relayer-cli --bin hermes --locked --force
then restart with TRACE log level
I don't find the log about default fee and simulate gas
Sep 30 21:42:36.688 DEBUG ThreadId(50) [osmosis-1] send_tx: sending 2 messages using nonce 72346
Sep 30 21:42:36.689 TRACE ThreadId(50) [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 2000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uosmo", amount: "0" }], gas_limit: 2000000, payer: "", granter: "" }
Sep 30 21:42:36.696 DEBUG ThreadId(50) [osmosis-1] send_tx: broadcast_tx_sync: Response { code: Ok, data: Data([]), log: Log("[]"), hash: transaction::Hash(86C593B187E78F8574F65C52E4F902CC7B30E68457CFA18402C67A924B52B658) }
Sep 30 21:42:36.696  INFO ThreadId(16487) [Async~>osmosis-1] response(s): 1; Ok:86C593B187E78F8574F65C52E4F902CC7B30E68457CFA18402C67A924B52B658
Sep 30 21:42:36.696  INFO ThreadId(16487) [cosmoshub-4:transfer/channel-141 -> osmosis-1] success

Sep 30 21:43:05.418 DEBUG ThreadId(52) send_messages_and_wait_check_tx with 2 messages
Sep 30 21:43:05.418 DEBUG ThreadId(52) [cosmoshub-4] send_tx: sending 2 messages using nonce 54019
Sep 30 21:43:05.422 TRACE ThreadId(52) [cosmoshub-4] send_tx: based on the estimated gas, adjusting fee from Fee { amount: [Coin { denom: "uatom", amount: "100" }], gas_limit: 1000000, payer: "", granter: "" } to Fee { amount: [Coin { denom: "uatom", amount: "100" }], gas_limit: 1000000, payer: "", granter: "" }
Sep 30 21:43:05.425 DEBUG ThreadId(52) [cosmoshub-4] send_tx: broadcast_tx_sync: Response { code: Ok, data: Data([]), log: Log("[]"), hash: transaction::Hash(914A80786F2D90F6CE018898D376BF2C25985AB7BC4FA677B4B924B661AA7329) }
Sep 30 21:43:05.425  INFO ThreadId(15710) [Async~>cosmoshub-4] response(s): 1; Ok:914A80786F2D90F6CE018898D376BF2C25985AB7BC4FA677B4B924B661AA7329
Sep 30 21:43:05.425  INFO ThreadId(15710) [osmosis-1:transfer/channel-0 -> cosmoshub-4] success

That's really weird. Can you please check that the code in cosmos.rs that you checked out matches the code in the PR? Can you also please post the output of hermes version? Assuming that's the executable you are running.
Or otherwise run it with cargo run -- start?
I just double checked the code in the PR and it should match the output I just posted above. If that doesn't work maybe we can have a synchronous debug session together sometime next week if that works for you? cc @adizere

Nevermind, try installing Hermes with
cargo install --path relayer-cli

The command you used above installed the version that's on crates.io, not the one from the branch.
Alternatively, just do a cargo build and then invoke Hermes with ./target/debug/hermes

That's really weird. Can you please check that the code in cosmos.rs that you checked out matches the code in the PR?
Yes the code match

Can you also please post the output of hermes version? Assuming that's the executable you are running.

Sep 30 22:04:45.600  INFO ThreadId(01) using default configuration from '/srv/hermes/.hermes/config.toml'
hermes 0.7.2

The command you used above installed the version that's on crates.io, not the one from the branch.

OK :) sorry
this time hermes version return hermes 0.7.2+11bea3da
Look like the modification works :
https://www.mintscan.io/cosmos/txs/06DD939153010C79FCE1C395A222F5A8DCF58150DD5AB867C74EFF05AC59E32C
https://www.mintscan.io/osmosis/txs/65E1A765970312E10A35F3DAE69A26B9F7BE8BB60455BA5A479D5510CE5F1344
Sep 30 22:22:34.468 DEBUG ThreadId(50) [osmosis-1] send_tx: sending 2 messages using account sequence 72390
Sep 30 22:22:34.468 DEBUG ThreadId(50) [osmosis-1] default fee: Fee { amount: "0uosmo", gas_limit: 2000000 }
Sep 30 22:22:34.484 DEBUG ThreadId(50) [osmosis-1] simulated gas: Ok(Some(GasInfo { gas_wanted: 0, gas_used: 413782 }))
Sep 30 22:22:34.484 TRACE ThreadId(50) [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: "0uosmo", gas_limit: 2000000 } to Fee { amount: "0uosmo", gas_limit: 455161 }
Sep 30 22:22:34.489 DEBUG ThreadId(50) [osmosis-1] send_tx: broadcast_tx_sync: Response { code: Ok, data: Data([]), log: Log("[]"), hash: transaction::Hash(A2CB73AD59723BF0A3CC63E15B4953983647C915120C8908BC07294E6A95BED6) }
Sep 30 22:22:34.489  INFO ThreadId(7414) [Async~>osmosis-1] response(s): 1; Ok:A2CB73AD59723BF0A3CC63E15B4953983647C915120C8908BC07294E6A95BED6

this time hermes version return hermes 0.7.2+11bea3da
Look like the modification works :
https://www.mintscan.io/cosmos/txs/06DD939153010C79FCE1C395A222F5A8DCF58150DD5AB867C74EFF05AC59E32C https://www.mintscan.io/osmosis/txs/65E1A765970312E10A35F3DAE69A26B9F7BE8BB60455BA5A479D5510CE5F1344
Sep 30 22:22:34.468 DEBUG ThreadId(50) [osmosis-1] send_tx: sending 2 messages using account sequence 72390
Sep 30 22:22:34.468 DEBUG ThreadId(50) [osmosis-1] default fee: Fee { amount: "0uosmo", gas_limit: 2000000 }
Sep 30 22:22:34.484 DEBUG ThreadId(50) [osmosis-1] simulated gas: Ok(Some(GasInfo { gas_wanted: 0, gas_used: 413782 }))
Sep 30 22:22:34.484 TRACE ThreadId(50) [osmosis-1] send_tx: based on the estimated gas, adjusting fee from Fee { amount: "0uosmo", gas_limit: 2000000 } to Fee { amount: "0uosmo", gas_limit: 455161 }
Sep 30 22:22:34.489 DEBUG ThreadId(50) [osmosis-1] send_tx: broadcast_tx_sync: Response { code: Ok, data: Data([]), log: Log("[]"), hash: transaction::Hash(A2CB73AD59723BF0A3CC63E15B4953983647C915120C8908BC07294E6A95BED6) }
Sep 30 22:22:34.489  INFO ThreadId(7414) [Async~>osmosis-1] response(s): 1; Ok:A2CB73AD59723BF0A3CC63E15B4953983647C915120C8908BC07294E6A95BED6

Many thanks @Galadrin for reporting the problem, and your patience with helping debug this, it was a tricky one having to do with SDK version compatibilities!
We aim to cut a new release today (Oct 1) with the fix.


Possible issue with UUID Deserializer

Wanted to bring up a possible problem with the uuid deserializer in up-java, according to a up-tck test. Attaching the results of both python and java's results for this uuid_deserializer test, and up-java is failing. Something is happening with the deserializer where the msb of the uuid is being set differently in java than in python. Can someone with more knowledge of this method in java take a look and see if it's an issue?

It looks like the printed number for lsb is greater than 2^63-1 so it cannot fit in a long that has a range of -2^63 to 2^63-1 and that is why you get the negative number from up-java that uses a long.

Looks like root cause was discovered, closing for now


Add contributors to README

Show a list of contributors on the main README

@all-contributors please add @jevakallio for doc

@all-contributors please add @jevakallio for doc

@all-contributors please add @StefanOpariuc for doc


qiskit.providers.aer is qiskit_aer in Aer 0.11

In the qiskit-aer most recent release 0.11, the import path is changing from qiskit.providers.aer is qiskit_aer. This is a silent change right now, but it will turn into a warning with qiskit-terra 0.22 (planned for Oct 11th, 2022)
This PR change all the import paths.

This will cause Terra to stop being able to load Aer 0.10 completely - it's possible we don't actually want to do this for another couple of versions, or at least do dynamic switching on our imports.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

11 of 12 (91.67%)  changed or added relevant lines in 5 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.007%) to 84.393%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/test/decorators.py
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

qiskit/extensions/quantum_initializer/squ.py
2
79.78%

qiskit/pulse/library/waveform.py
3
91.49%

Totals

Change from base Build<PHONE_NUMBER>:
-0.007%

Covered Lines:
59210

Relevant Lines:
70160

💛  - Coveralls

Are you suggestion something like this?
    try:
        from qiskit_aer import ...
    except ImportError as ex:
        try:
            from qiskit.providers.aer import ...
        except ImportError as ex:
            raise MissingOptionalLibraryError(

I've integrated this into #8657 as it was needed to enable that to merge. Per earlier offline discussions that PR updates doc references and tests to the new imports and filters the warnings inside qiskit code (to maintain compatibility with aer < 0.11 during the transition period). I'm going to close this accordingly, but if I'm missing something please feel free to reopen this


v<IP_ADDRESS> Breaks Pycharm Debugger Console

It appears the v<IP_ADDRESS> introduces an issue with Pycharm Debugging console.  Normally one can put a breakpoint and the debug will stop there and you are able to interact in a console e.g. ask shape information, print values, etc. Using <IP_ADDRESS> (I have tested downgrading to <IP_ADDRESS> and everything works fine), if you set a breakpoint inside a JIT'ed function inside an equinox Module, when it hits it, if you type anything in the console you now get the following error.
PyDev console: starting.
Traceback (most recent call last):
  File "_pydevd_bundle/pydevd_cython.pyx", line 928, in _pydevd_bundle.pydevd_cython.PyDBFrame.trace_dispatch
  File "_pydevd_bundle/pydevd_cython.pyx", line 585, in _pydevd_bundle.pydevd_cython.PyDBFrame.do_wait_suspend
  File "/home/adam/.local/share/JetBrains/Toolbox/apps/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd.py", line 1207, in do_wait_suspend
    self._do_wait_suspend(thread, frame, event, arg, suspend_type, from_this_thread)
  File "/home/adam/.local/share/JetBrains/Toolbox/apps/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd.py", line 1221, in _do_wait_suspend
    self.process_internal_commands()
  File "/home/adam/.local/share/JetBrains/Toolbox/apps/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd.py", line 906, in process_internal_commands
    int_cmd.do_it(self)
  File "/home/adam/.local/share/JetBrains/Toolbox/apps/pycharm-professional/plugins/python-ce/helpers/pydev/_pydevd_bundle/pydevd_comm.py", line 1865, in do_it
    sys.stderr.flush()
AttributeError: '_FilteredStderr' object has no attribute 'flush'
Traceback (most recent call last):
  File "_pydevd_bundle/pydevd_cython.pyx", line 1597, in _pydevd_bundle.pydevd_cython.ThreadTracer.__call__
  File "_pydevd_bundle/pydevd_cython.pyx", line 940, in _pydevd_bundle.pydevd_cython.PyDBFrame.trace_dispatch
  File "_pydevd_bundle/pydevd_cython.pyx", line 928, in _pydevd_bundle.pydevd_cython.PyDBFrame.trace_dispatch
  File "_pydevd_bundle/pydevd_cython.pyx", line 585, in _pydevd_bundle.pydevd_cython.PyDBFrame.do_wait_suspend
  File "/home/adam/.local/share/JetBrains/Toolbox/apps/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd.py", line 1207, in do_wait_suspend
    self._do_wait_suspend(thread, frame, event, arg, suspend_type, from_this_thread)
  File "/home/adam/.local/share/JetBrains/Toolbox/apps/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd.py", line 1221, in _do_wait_suspend
    self.process_internal_commands()
  File "/home/adam/.local/share/JetBrains/Toolbox/apps/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd.py", line 906, in process_internal_commands
    int_cmd.do_it(self)
  File "/home/adam/.local/share/JetBrains/Toolbox/apps/pycharm-professional/plugins/python-ce/helpers/pydev/_pydevd_bundle/pydevd_comm.py", line 1865, in do_it
    sys.stderr.flush()
AttributeError: '_FilteredStderr' object has no attribute 'flush'

I believe the issue might well be related to the introduction of the _FilteredStderr class in latest version that might be clashing with Pycharm Debugger.

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

Ah, probably we just need to add that method and forward the method call on. I'll write a quick PR for that.
Thanks for the report!

Alright, I've opened #828 that should fix this.
Can you confirm that installing Equinox from that branch resolves things? If so I'll merge it.

This seems to fix the problem.
However, I now get warnings, "UserWarning: A JAX array is being set as static! This can result in unexpected behavior and is usually a mistake to do.". In the case it is warning about, it isn't "wrong". I presume you have added this with the latest update.

Yup! We've added a warning for this -- not yet released.
If you have a use-case for static arrays I'd be curious? Also tagging @lockwo on this.

One example is that I am using torch2jax (https://github.com/rdyro/torch2jax) to call a complex pytorch function via torch2jax_with_vjp. I wrap the function inside an equinox module, as some of inputs do not change each time the function is called (and its buried deep inside the code tree, so passing them each time would be a pain). Thus its easier to create the module and pass the jax arrays in the init method and store them as static jax arrays.

I haven't used torch2jax before, so I can't comment on the specifics (I have used the new keras 3 interface and gotten old PyTorch code to interface with equinox, idk how similar that is). But what is unclear to me is what marking them as static here is doing?

wrap the function inside an equinox module, as some of inputs do not change each time the function is called

I interpret this as meaning the inputs do not change as user parameters, but does this also mean they do not change as a result of optimization (i.e. they are not part of the gradient tree)? If they are not part of the gradient flow, then you could just not mark them as static and they shouldn't be differentiated. If that isn't a concern, and they are just "static" in the sense that they are user inputs that are unchanging, then it doesn't seem essential to mark them as actual static fields (unless I am missing some pytree manipulation or something else is going on).

It is true I could pass the parameters in as a static, but it is quite annoying to then have to pass them down through a hierarchy of classes. I find it easier and neater just to initial the class and store them as a static parameter. Maybe this is bad programming practice, it is just in some of my models i can have a significant number of such things (and because I do research these can be in flux), and that need to go to different parts of the model / losses functions and so it quickly becomes quite messy to keep passing them about.

I find it easier and neater just to initial the class and store them as a static parameter.

I think I get the motivation for having a class, but my question was like why is it necessary to make the array's static fields (as opposed to just member variables)? Is it for gradient reasons? Pytree manipulation reasons?

There is no gradient or pytree manipulation required, but if I don't set them to static they will be deemed as a parameter that should be optimised.

There is no gradient or pytree manipulation required, but if I don't set them to static they will be deemed as a parameter that should be optimised.

In general, if they shouldn't be optimized there's often two cases. 1) they don't actually have a gradient, in which case they won't be optimized even if you "let" them (since the gradients will always be 0/None). 2) they do have a gradient, but you don't want to propagate it, in which case stop_gradient is usually the fix. But in your case, since you have a somewhat bespoke system w/ respect to torch and jax, its possible static arrays are fine (can't say for sure in abstract discussions) .

My particular setup is tricky. I might be able to use stop gradient if I am careful.


[bug] Fix Error Message on K8s Manifest Upload

Notes for Reviewers
This PR fixes the incorrect error message when Meshery fails to convert K8s Manifest to Design.
This PR fixes https://github.com/meshery/meshery/issues/9936
Signed commits

[ ] Yes, I signed my commits.

The design used to upload in the test had syntax errors..
Here is the corrected K8s Manifest.

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: elasticsearch
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/app-root: "/"
    # "413 Request Entity Too Large" uploading plugins, increase client_max_body_size
    nginx.ingress.kubernetes.io/proxy-body-size: 50m
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600s"
    nginx.ingress.kubernetes.io/proxy-request-buffering: "off"

    nginx.ingress.kubernetes.io/proxy-send-timeout: "180s"
    nginx.org/proxy-connect-timeout: "3m"
    # "413 Request Entity Too Large" uploading plugins, increase client_max_body_size
    ingress.kubernetes.io/proxy-body-size: 100m
    ingress.kubernetes.io/proxy-request-buffering: "off"
spec:
  # To enable SSL offloading at ingress level, uncomment the following 5 lines
  #tls:
  #- hosts:
  #  - elasticsearch.cje.example.com
  #  # Name of the secret containing the certificate to be used
  #  secretName: cje-example-com-tls
  rules:
  - host: elastic.example.com
    http:
      paths:
      - path: /elasticsearch
        backend:
          serviceName: elasticsearch
          servicePort: 9200
---
apiVersion: v1
kind: Namespace
metadata:
  name: elastic
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: elasticsearch
  namespace: elastic
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: elasticsearch
  namespace: elastic
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get","list","watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["create","delete","get","list","patch","update","watch"]
# - apiGroups: [""]
#   resources: ["namespaces"]
#   verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["services"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["persistentvolumeclaims"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: ["extensions"]
  resources: ["ingresses"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["list"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["get","list","watch"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: elasticsearch
  namespace: elastic
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: elasticsearch
subjects:
- kind: ServiceAccount
  name: elasticsearch
---
apiVersion: v1
kind: ReplicationController
metadata:
  name: es
  namespace: elastic
  labels:
    component: elasticsearch
spec:
  replicas: 1
  template:
    metadata:
      labels:
        component: elasticsearch
    spec:
      serviceAccount: elasticsearch
      initContainers:
      - name: init-sysctl
        image: busybox
        imagePullPolicy: IfNotPresent
        command: ["sysctl", "-w", "vm.max_map_count=262144"]
        securityContext:
          privileged: true
      containers:
      - name: es
        securityContext:
          capabilities:
            add:
              - IPC_LOCK
        image: quay.io/pires/docker-elasticsearch-kubernetes:5.6.2
        env:
        - name: "CLUSTER_NAME"
          value: "estest"
        - name: "DISCOVERY_SERVICE"
          value: "elasticsearch"
        - name: NODE_MASTER
          value: "true"
        - name: NODE_DATA
          value: "true"
        - name: HTTP_ENABLE
          value: "true"
        - name: NETWORK_HOST
          value: _eth0_
        - name: ES_JAVA_OPTS
          value: -Xms9192m -Xmx9192m
        ports:
        - containerPort: 9200
          name: http
          protocol: TCP
        - containerPort: 9300
          name: transport
          protocol: TCP
        resources:
          limits:
            cpu: "1"
            memory: "16G"
        volumeMounts:
        - mountPath: /data
          name: es-storage
      volumes:
      - name: es-storage
        emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: elasticsearch
  namespace: elastic
  labels:
    component: elasticsearch
spec:
  type: ClusterIP
  selector:
    component: elasticsearch
  ports:
  - name: http
    port: 9200
    targetPort: 9200
    protocol: TCP
  - name: transport
    port: 9300
    targetPort: 9300
    protocol: TCP