bug: ion-datetime appears below modal when using Javascript only.

Bug Report
Ionic version:

[x] 4.x
Current behavior:

In the Javascript platform when using ionic 4 (no Angular, React or Vue) when I call an ion-modal I cannot use an ion-datetime inside that modal because the modal will be front of the screen and the ion-datetime below. WHen you try the modal you will see nothing but when closing the modal you will see the modal there.
Expected behavior:

I should see the datetime on top of the modal (it does on Angular. I am trying to not use frameworks and I am remaking my app on Stencil)
Steps to reproduce:

Related code:

//This is how I open the modal
function openEventCreateModal(): void {
const modalElement = document.createElement('ion-modal');
modalElement.component = 'app-event-create';
modalElement.componentProps = {
header: 'Create Event'
};
document.body.appendChild(modalElement);
modalElement.present();
}
//This snippet is on the modal. I think the z-index of the ion-datetime is the same one as the modal when I press the ion-datetime on the browser.
<ion-item>
    <ion-label position="fixed">{this.htmlControls.date}:</ion-label>
    <ion-datetime display-format="MM/DD/YYYY" value={this.date.toString()} onIonChange={ev => this.date = new Date(ev.detail.value)}></ion-datetime>
    </ion-item>

insert short code snippets here

Other information:

Ionic info:

insert the output from ionic info here

The overlay element is appended inside ion-app instead of the document body, while modals are appended directly inside the document body. Since modals have higher z-index than ion-app, many components, including alerts, pickers, actionsheets, etc, will be hidden by the modal.

I see, thanks.
Yesterday I was updating to ionic 5 and this issue was fixed.
Marking it as complete.


enable clippy in font/copypasta crates

turned out regular "cargo clippy" would ignore these previously.

Hey, thanks for staying on top of clippy with these PRs! Looks great to me, I'll give this a spin later.
It might also make sense to pin nightlies for clippy, to make sure that cargo can always install it, however that would probably introduce some maintenance work of having to increase the pinned nightly whenever possible.
Alternatively just keeping it the way it is right now until clippy will fail nightlies again is an option. From what I've heard that should be a thing in the not too distant future.


[Plan] Think about having new Pronoun & Timezone pages scroll to selected items on render

Idea from @thesahindia here: https://github.com/Expensify/App/pull/12301#issuecomment-1315758878
Holding on implementation of new timezone pages: https://github.com/Expensify/App/pull/12201

Possibly useful SO for scrolling: https://stackoverflow.com/questions/43452859/react-native-sectionlist-scroll-to-section

Wait, Melvin! Start counting a month from now.

I'll get back to this soon, most probably I'll offload this to Callstack

This is already implemented.


Managing Dialogs - discussion

How should dialogs (not only modal) be handled?
The current spec follows other libraries, where dialogs are managed by parent components using the isOpen (or similar) prop/state.
For example:
<ConfirmFileRemoval isOpen={this.isCfrDialogOpen} onCloseRequest={() => this.isCfrDialogOpen = false} />

There's couple of problems with this approach:

Such dialog is tied to another component. But dialogs are usually tied to a process/flow, not component.
The dialog is always rendered, at least as "closed", regardless of whether is visible or not. So "closing a dialog" is more like "hiding a dialog"
This approach doesn't scale well. All possible dialogs of some component must be part of its render function.
The more potential dialogs, the slower parent render is

The alternative is having a central dialog manager. Opening a dialog is then a command/message sent to the manager, rather than changing its state.
this.dialogManager.openModal(<ConfirmFileRemoval onCloseRequest={dialog => this.dialogManager.close(dialog) } />

This approach solves all the above problems.

what is considered as this in this.dialogManager, user application, parent, root, router?

what if each time you render the <Dialog ... />  it does smth like
render() {
  Dialog.manager.whatEver()
}

I think declarative dialogs are better. It looks like any other component vdom. And The owner component shouldn't really care how / where / when the internal component is rendered.
Even in normal containment, there is no guarantee that the children you pass are going to render when you are. Their render might be prevented or delayed by some parent component or by React (>16).
In the future, I like to have the option when building a dialog to indicate that its a layer, which means that any other portals rendering from the same application context will not render when a layer is rendered, and any other layer from that context will queue up and wait for the layer to close. Layer opening from the layer context should open above it and cause the same behavior for any other portals in the layer.


Drop incremental compilation state for Mill modules when version changes

Mill used various tricks to map build scripts written by users to generated enhanced versions, including package objects and other stuff.
Since some of these techniques may result in Zinc undercompilation, we want avoid downstream issues,
especally in the methodCodeHashSignatures task, which is sensitive to inconsistent bytecode.
We trait potentially longer compilation against incorrect or too coarse code change detection, which may invalidate a lot more downstream tasks than needed due to invalid data.
Fix https://github.com/com-lihaoyi/mill/issues/3874

Since we don't have a reproducer, this PR comes without a test.


ci: update releases-json to 7f83a5a

follow-up:

https://github.com/crazy-max/.github/pull/25
https://github.com/crazy-max/.github/pull/26

Handles edge releases so RCs can be tested without updating the tag.
Last commit pin latest of Buildx to v0.18.0 https://github.com/docker/actions-toolkit/actions/runs/12049171429/job/33595366377?pr=510#step:4:6 related to regressions encountered in v0.19.0, see https://github.com/docker/actions-toolkit/pull/508

Test failure unrelated but looks flaky:
Removing Docker context
      console.error
        Error: The process '/usr/local/bin/limactl' failed with exit code 1
  /var/folders/9x/gv0lxxcx5mj3ys0lwjy2hw1h0000gn/T/docker-actions-toolkit-mGecuC/runner-tool-cache/docker-image/master/x64/docker context rm -f foo
            at ExecState._setResult (/Users/runner/work/actions-toolkit/actions-toolkit/node_modules/@actions/exec/src/toolrunner.ts:668:17)
            at ExecState.CheckComplete (/Users/runner/work/actions-toolkit/actions-toolkit/node_modules/@actions/exec/src/toolrunner.ts:649:12)
            at ChildProcess.<anonymous> (/Users/runner/work/actions-toolkit/actions-toolkit/node_modules/@actions/exec/src/toolrunner.ts:522:15)
            at ChildProcess.emit (node:events:518:28)
            at ChildProcess.emit (node:domain:489:12)
            at maybeClose (node:internal/child_process:1104:16)
            at Socket.<anonymous> (node:internal/child_process:456:11)
            at Socket.emit (node:events:518:28)
            at Socket.emit (node:domain:489:12)
            at Pipe.<anonymous> (node:net:343:12)


[Fonts] Icon request: edit_calendar

io.material

Hi @Pooja289318, Thanks for filing the issue. The requested icon is already present in the latest stable release of flutter.

Flutter 2.10.3 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 7e9793dee1 (3 weeks ago) • 2022-03-02 11:23:12 -0600
Engine • revision bd539267b4
Tools • Dart 2.16.1 • DevTools 2.9.2

Closing, as the icon is already present. In case you disagree feel free to write in the comments and we will reopen it.
Thank you.


Is there a way to reverse the default assumption about nullability?

Couldn't find this anywhere in the doco, so I'm assuming no... but thought I'd ask the question. I have a couple of quite large code bases that pretty much assume all fields and parameters are nullable. Eg they have null checks already for everything. There have lots of hibernate and json model objects while have to have empty constructors and null initialised fields.
For these existing code bases, it seems it would be a lot less annotation effort to reverse the assumption and assume @Nullable by default. Then the checker would pick up non checked uses straight away, and we could gradually add @NonNull annotations.
As it is, its going to be too big a task (currently 5k+ combined NullAway and ErrorProne warnings on one of the code bases) to get this happening.

I don't think it's supported yet, but you can annotate packages with Checker Framework's @DefaultQualifier annotation to make the default nullable.

Hi @jonnermut!  We don't support this reversal at the moment, though with some work we could probably do it in the future.  For the fields, are they in fact nullable and your code needs to have defensive null checks everywhere?  Or is it that they are not null after initialization, but NullAway doesn't understand the initialization pattern?  If it's the latter, and if there is some annotation on the fields or classes to indicate they are getting initialized in a special way, we could probably add support for that pretty easily.  Parameters are a different story, and probably require something like flipping the default.
For adopting Error Prone gradually, you can try to use the new -XepExcludedPaths option in EP 2.1.3 to exclude large chunks of your code base from all Error Prone checks, and then gradually allow checks on more code as it is ready.  It'll still be painful, but less painful then trying to get all code passing the checks at once 😄

Thanks @JakeWharton , I don't thinks its supported yet.
Thanks @msridhar .
It's a real mix, as you'd expect in a large code base. I have a ton of Spring beans it's tripping on that are annotated with @Autowired and @PostContruct and I need to add those annotations to the config and see how much that pairs things down.
Most of really nullable fields are in model objects which model JSON (where they are almost all nullable), or Hibernate database entities (where they are a mix). In both of these cases every field is private with a public getter/setter pair which would also need annotation. In both cases the fields have to start null and have empty constructors, and they may or may not be initialised inside the frameworks (Hibernate & Jackson).
Parameters are also a mix. But the vast majority of our methods are written defensively with null guards (due to bitter experience of NPEs!), so it would be useful to set the reverse default there for sure.
Lately the team has been writing a lot of Swift, Kotlin & (recent versions of) Typescript, and the non null enforcing in those languages really shows up how primitive the null checking is in Java (and our C++ code for that matter...). So I'm keen to make this happen.
Do you think that the code is encapsulated enough that changing the logic in nullnessFromAnnotations in Nullness.java would be enough? If so I might have a go at a fork to see if it works:
  private static Nullness nullnessFromAnnotations(Element element) {
    for (AnnotationMirror anno : NullabilityUtil.getAllAnnotations(element)) {
      String annotStr = anno.getAnnotationType().toString();
      if (isNullableAnnotation(annotStr)) {
        return Nullness.NULLABLE;
      }
    }
    return Nullness.NONNULL;
  }

  public static boolean hasNullableAnnotation(Element element) {
    return nullnessFromAnnotations(element) == Nullness.NULLABLE;
  }

@jonnermut feel free to give it a shot!  I think the key issue is how NullAway should figure out whether a class has opted in to the default nullable treatment.  I think we'll need to add support for something like @DefaultQualifier, both at the class and package level.  And also this should work whether a class is present as source code or in a jar file.  Depending on how expensive the @DefaultQualifier search is, we may need some caching as well.  And we'll also have to figure out which non-null annotations to support 😄
FYI, I probably won't be able to look too much at this until after the holidays.

Could this be solved by passing a custom annotation to the -XepOpt:NullAway:ExcludedFieldAnnotations complication flag to not check certain fields?
To extend upon this, I was hoping to find a way to completely exclude a field marked with this custom annotation from any NullAway analysis, and not just initialization. I have a field that is both late initialized, and is nulled out after being used in many different functions. I would ideally like for it to not be nullable, but in the meantime it would be nice to not have to add a @SupressWarning("NullAway") annotation to the method that nulls out this object (since it might have other fields I do want NullAway to run on).

After discussing the extended use case above with a co-worker, we decided that wrapping the value in Optional can handle the extended case.

To help solve the original problem in this thread, and to even match Kotlin, a pre-baked @LateInitVar annotation could be added to NullAway as an ExcludedFieldAnnotation.

Hi @caseykulm, I won't be able to look more until next week, but could you open a separate issue in the @LateInitVar support?  That sounds like a good idea, but I think it's separate from this issue.


gui: change path signature details

Thanks. It's much nicer now.
From my suggestion i see you dropped the "or" at the beginning of each line. Didn't it render nicely?
What about dropping the green color for signers that signed? It was useful when it wasn't explicited they signed but now it's literally written next to it so it seems unnecessarily heavy?
Maybe we should also qualify the aliases. Something like "2 more signatures from signers Specter and Edouard Ledger" rather than "2 more signatures from Specter Edouard Ledger". This is kinda getting in nit territory but my concern is that we shouldn't assume these labels are meaningful aliases set by the user, if you replace Specter by 326475a9 and Edouard Ledger by 09cc411a does the sentence still hold?

2 more signatures from 326475a9 09cc411a

With my suggestion it'd become

2 more signatures from signers 326475a9 and 09cc411a

Yeah i don't know it's not a bunch clearer either. It looks like nothing will make fingerprints clear in the UI (apart maybe a whole and heavy "signer with id 326475a9" instead of just showing the fingerprint.
I have more suggestions that we won't be able to do before the next release. Let's discuss only the pressing fixes here.

maybe key:326475a9

I'd rather use "signer" thank "key" because the fingerprint does identifiy a single key.
------- Original Message -------
Le samedi 4 février 2023 à 12:16 PM, Édouard @.***> a écrit :

maybe key:326475a9
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

So we are grouping keys by signers, but not signatures. So it can lead to confusing displays like "need 5 signatures from Alice, Bob and Carol" if a device is used multiple times in the same spending path. For instance here (ignore my retarded third alias):

So maybe we could instead display something like "Need X more signers to participate in the transaction" instead of "Need Y signatures".
On the other hand it would be an invasive change at this point and for a simple multisig it's probably useless in the first place to have one device several times on a single spending path.

Ok there is a lot to cover here. I'll try to go chronologically from previous comments, then add my own.
From my suggestion i see you dropped the "or" at the beginning of each line. Didn't it render nicely?
I personally don't care, either works too. We can put that in later UX improvements.
Something like "2 more signatures from signers
I'd rather use "signer" thank "key" because the fingerprint does identifiy a single key.
Something i repeatedly said at the last retreat, we have a big wording issue with the Fingerprint identifiers. I absolutely think we are doing the right thing by using Fingerprint labels, but indeed the words "keys", "signers", "device" aren't good for describing it.
I absolutely NACK the change for "Signer", as a single HW can have multiple fingerprints, typically for any password protected mnemonic. Some other HW can have multiple mnemonics loaded to them, even outside of the realm of password derivation.
If you need a word, we first need to find one. "Fingerprint", "mnemonic", "seed" are all correct but at the same time bad/confusing. Signer, Key, Account etc are just not describing the actual thing.
maybe key:326475a9 or key#326475a9
NACK for the same reason.
So we are grouping keys by signers, but not signatures. So it can lead to confusing displays like "need 5 signatures from Alice, Bob and Carol" if a device is used multiple times in the same spending path.
I cannot see any reason why a single mnemonic should be reused in a single path. This should actually be prevented IMHO.
(again, Fingerprint is mnemonic, not device. I could imagine using the same device, requiring multiple keys that you load separately (ledger with passphrase, Specter with different mnemonics, etc etc)
For my own comments:

if it's ready, the tx doesn't need anything more. So I'd just display: "Ready, signed by bob carol
Nit: i'd replace Ed Ledger Specter already signed by "already signed by Ed Ledger Specter . We might even find better wording, i just don't have it now.
i'm getting very triggered by the lack of consistency between buttons. Ignore this comment for now but please take this into account in the future, i keep saying it.
We can keep the "1 signature(s) from ed ledger " for the single case, we can change that later.
We can keep the "2 signature(s) from ed ledger potato chips for the multi case, might change that later.
I would change the "finalizing this transaction needs either" by "finalizing this transaction requires". Not I don't mind about keeping the Either there or using Or later.

Thanks for the hard work, we are getting there. It's hard to design something like that!

Kevin, i agree with regard to the words "device" or "key" not being representative of a fingerprint. But "signer" is. It is a common abstract role in Bitcoin terminology. For instance, see the signer role in BIP174 (PSBTs). The word "mnemonic" (contrary to "seed", which do keep in mind is not the same thing) you then bring up does not always represent a signer since you may derive multiple signers by using no, or different, passwords. I also don't understand why you then throw vaguely described unsupported signing devices ("Some other HWs") into the mix.
Anyways, i agree with you "signer" is not perfect and maybe not the right word to use in a user interface. But to be frank we are fighting a time-wasting useless battle here. It was just an off-hand note on displaying the fingerprint being confusing. We are not going to change that in this PR, one day from the release.

I cannot see any reason why a single mnemonic should be reused in a single path. This should actually be prevented IMHO.

Me neither. But again as a general rule of thumb i don't think we should just forbid every single thing we can't come up with a use for. For the simple reason that we are not omniscient, but also because it can come back to bite us in the future.

if it's ready, the tx doesn't need anything more. So I'd just display: "Ready, signed by bob carol

I agree (as i posted on Mattermost). We shouldn't display the details if the transaction is fully signed. At least for now it saves us some things to figure out. Are you fine with that @edouardparis?

Nit: i'd replace Ed Ledger Specter already signed by "already signed by Ed Ledger Specter . We might even find better wording, i just don't have it now.

+1 for this and the rest of your comment basically.

Screenshots look good to me!

In order to not slow down the release process, a first state of the work is merged.
People are invited to give feedback and continue discussions at #327
Self-ACK 56d3522f8c74ff774cb3ecdbf76b48dd216497f9


JPype crashes when JIT compilation is enabled

Hi,
I'm running into an issue where JPype crashes when JIT compilation is enabled, I am forced to use -Xint when starting the JVM to prevent the failure, which can happen in arbitrary places.
It is hard for me to tell which environment crashes first: the JVM or the Python process, see error message below. I've tried on different JREs (Oracle 1.8.0_151 & 1.8.0_172, OpenJDK 11.0.1) and the problem remains. I am on MacOSX 10.14.6 and uses Jpype 1.1.2 on Python 3.8.6.
I don't know if and why that could be the issue but the Java code I'm running is written originally in Kotlin. Is there anything I can try to reenable JIT compilation, since without it performances are extremely poor?
Thank you,
Karl
Error message:
Fatal Python error: Bus error
Thread 0x000070000261d000 (most recent call first):
<no Python frame>
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (sharedRuntime.cpp:549), pid=9833, tid=0x0000000000000307
#  guarantee(cb != NULL && cb->is_nmethod()) failed: safepoint polling: pc must refer to an nmethod
#
Fatal Python error: Aborted

Hello fellow Karl.  This one is a little beyond my knowledge unfortunately.   There is nothing in JPype that should require the interpreter.   As far as I am aware we can run with full JNI checking which should catch any mishandling of the JNI calls.   The only exception to this is there is currently a call to request a virtual on an interface method which appears to mess up android based virtual machines.

Hi @Thrameos , I can believe this is a tough one! I'm quite a new user to JPype though so I'm not sure to understand all particularities of this project yet, when you say : "we can run with full JNI checking", do you mean you want me to enable some sort of debugging session to see if the issue occurs in JPype JNI code?
I've just did the same test on Linux and I still have the same problem: my process crashes unless I enable -Xint in my JVM command. Also executing the same piece of Java code in a Java stand-alone app, without -Xint, works without problem. So it has to have something to do with the Python bridge somehow. Any traces you would like to see in particular?

JPype is just steering around the JVM using JNI calls.   Fundamentally it should be no different than Java calling natively.   The common problems that we can have is either we mess up a referencing count and call a resource which is not currently alive in terms of a reference, leak a reference by failing to close, or call a method using the wrong access pattern (attempt to use the wrong class for the method or force a non-virtual call on a method without an implementation.)
The JVM has an option to try to catch as many of these as possible by forcing them to be be segfaults.  This prevents them from running silent.  The option is -Xcheck:jni.
Beyond that I can only point you to the two debugging chapters in user and development guide.  Those recommend "trace" and "gdb" based debugging.   If you can post some code as to which call you issued at the time of the fault (which method and it signature) I can see if it matches the pattern seen on the dex bug.  I can also give a patch fix for that so you can try it, but as it is a fairly complex problem it may be a week of so to get you a working patch.
Last you can use javac to look at the byte code of the failed method.   If it really is a bug in the JVM it likely will be below the level where JPype interacts.   Though we can make mistakes in the JNI access, I am not aware of anything that would be fixed by turning off JIT.   I run with JIT all the time without issue.

Ok I'll try first with the -Xcheck:jni, thanks
For the example code, I can send you something but the issue does not occur only in a single method, it especially happens inside loops of thousands of iterations. FWIW, adding some System.out.println inside the loop with JIT enabled seems to postpone a bit the problem (one loop can succeed, then a different loop in another method will fail), if that can help...

As this is a JIT issue, we need to consider the method after JIT runs.   That is it calls the method 100 times, then decides to compile it, then on the 101th time we called X.Y(Z) and it crashed with AAA.
I would need to see the method signature of the call and its relationship to the objects.   For example we are calling method Y which was defined in object X as an abstract method which was implemented as Z.   The class structure is important here because method X.Y and Z.Y are two different memory addresses.   It is possible that JIT is changing the address of a method and somehow we have a stale method handle.
Also important if there is some threading involved.  We can get old addresses if there is recursion and we unwind onto a stale address.
Unfortunately, as I haven't seen anything like this it is going to be hard to track down with out a lot of information.
Just for clarity you are not perhaps using the non-virtual calling method deliberately.   For example....

a.method(b)
A.method(self, b)

mean different things to JPype.   The first is getting the method for the type of "a" then calling a virtual method with argument b.  The second is looking up A.method and calling it non-virtually such that it always gets A.method even if C.method should hide A.method.   This can potentially foul things up if C.method does not actually call A.method.

I verified that the virtual bug is not happening on Oracle based JVMs.  It must be particular to dex so it can't be affecting you.
So I guess the next steps are on you.  Please post

the call in Python that is crashing
The method signature which is being called in Java
The class structure (abstract, inherited from etc) so that I can see how JNI likely called the method.

Hi @Thrameos ,
I've narrowed down my code until I hit the breaking point and I've found out the issue. I'm running some machine-learning code with TensorFlow in my Python script and I was using tf.compat.v1.app.run to start it, which happens to not be required anymore in my case.
So by simply replacing this:
def main(args):
    # Call Java code here

tf.compat.v1.app.run()

by this:
def main():
    # Call Java code here

if __name__ == '__main__':
    main()

JIT compiler can now run without any issue. I don't know why tf.compat.v1.app.run() is in conflict with JPype, I didn't try to find out neither, I'm just happy that now it runs smoothly. Unless you have more questions and want us to investigate further, I'm fine closing this issue. Thanks a lot for your help.

Actually, the same problem occurs if I'm using app.run() from the absl package instead of tf.compat.v1.app.run.

Ok... I couldn't refrain myself to continue digging further into this :) See the following code, which is quite self-explanatory:
Java:
package mypackage;

import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class MyClass {

  public static void tokenize(String filename) throws Exception {
    Files.readAllLines(Paths.get(filename)).forEach(line -> line.split(" "));
  }
}

Python:
from absl import app
import jpype.imports
from jpype.types import *

jpype.startJVM(classpath=['target/jpype-test-0.1-jar-with-dependencies.jar'])

from mypackage import MyClass

def main(args):
    MyClass.tokenize("test.txt") # test.txt is a file with 400K identical lines: "This is a test"

if __name__ == '__main__':
    #app.run(main) # Using this, the JVM crashes if -Xint is not specified
    main(None) # This works all the time

Does it work without the import to absl?    I ran it without the absl import and it completed without issue.
This is sounding vaguely like another bug that we don't understand.  On some versions of numpy the blas library was compiled against a different version of pthreads library than the JVM.  This resulted in a very odd crash when numpy.linalg.inv was called.   The basic problem appears to be that depending on the order that calls are issued some of the threading code used by both blas and JVM are conflicting in memory layout resulting in a crash.   The fix for numpy was to call inv prior to starting the JVM, but I could see the bug working in the opposite direction as well in which some library is loaded before the JVM is started which is interfering with the operation of the JVM resulting in a threading lock (such as the one called by JIT) to fail in some dastardly fashion.
Assuming that is the case I would look to see what dynamic libraries are being loading by the absl call and see if any have a conflict with the copies loaded by the JVM.

I can confirm there is some type of crash.
Fatal Python error: Segmentation fault

Current thread 0x00007fffff7c0740 (most recent call first):
  File "testCrash.py", line 12 in main
  File "/home/nelson85/env/python3.6-unix/lib/python3.6/site-packages/absl/app.py", line 251 in _run_main
  File "/home/nelson85/env/python3.6-unix/lib/python3.6/site-packages/absl/app.py", line 303 in run
  File "testCrash.py", line 15 in <module>
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fffff03ef47 (sent by kill), pid=7835, tid=7835
#
# JRE version: OpenJDK Runtime Environment (11.0.8+10) (build 11.0.8+10-post-Ubuntu-0ubuntu118.04.1)
# Java VM: OpenJDK 64-Bit Server VM (11.0.8+10-post-Ubuntu-0ubuntu118.04.1, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libc.so.6+0x3ef47]  gsignal+0xc7
#
# Core dump will be written. Default location: core.7835 (may not exist)
#
# An error report file with more information is saved as:
# /mnt/c/Users/nelson85/Documents/devel/open/jpype/hs_err_pid7835.log
#
# If you would like to submit a bug report, please visit:
#   https://bugs.launchpad.net/ubuntu/+source/openjdk-lts
#

Thread 1 "testCrash.py" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Second guess.  Another rare possibility is that absl could have install a signal handler.   Python and JVM don't play particularly nice on this front because JVM uses certain signal handlers as part of its normal operation.  In some cases the Python signal handlers intercept or prevent the JVM from receiving these normal operation exceptions resulting in anomalous behaviors.   I tried the usual pattern to disable the fault handlers but it had no effect.

Disabling the fault handler fixed the error for me.
def main(args):
    import faulthandler
    faulthandler.disable()
    MyClass.tokenize("test.txt") # test.txt is a file with 400K identical lines: "This is a test"

Unfortunately, disabling the faulthandler didn't worked for me in my real app. I'm not able though to reproduce anymore the error in the sample app I gave you so it seems to me that the issue cannot be reproduced deterministically. Maybe that is your case as well?

Note that your error seemed a bit different than mine, you had a SegFault while in my case, it is always a BusError with this message: guarantee(cb != NULL && cb->is_nmethod()) failed: safepoint polling: pc must refer to an nmethod

Yeah yours reads more like the pthread bug than the faulthandler bug.    Safepoint is a checked in a Pthread section of the code.   I found the source and it seems likely that there is something wrong in the threading support.  Unfortunately, that does not rule out the faulthandler as both can participate.
I am not sure why the faulthandler causes issues beyond there is a technical problem with Python chaining.  But it is really outside of JPype domain.   It is possible that the disabling of the handler also failed to restore the Java entry points.  I would recommend altering the absl module to disable installing the fault handler in the first place and trying again.   That was how I isolated the issue on my end (just disabled pieces until it ran).   It is possible that your app has some other places that deal with the fault handlers.   There was one attempt to install the handlers in app.main but unfortunately that is not the only way that handlers can get installed especially if there is C code involved.
I have not been able to reproduce the bug on my machine with the faulthandlers disabled.  Perhaps I need to try on a OSX machine.  Unfortunately it will be a while as I have to work with a coworker as I only have windows and Linux available.

OK, mea culpa, I've just noticed you were disabling faulthandler in the main method, I was doing it before calling app.run(main), which was useless since absl was enabling it right after.
So I confirm that disabling faulthandler in the main method resolves the issue on my side as well 👍

Okay.  Thank you for the contribution.  Now that I have a method to replicate the bug in the fault handler interaction I can potentially fix it, though I suspect that given the Python fault handler module is written entirely in C there is not much that I can do from my end.   I don't think I can even monkey patch to place a warning so that next poor guy doesn't run face first into it.

If absl can fail to load faulthandler somehow, it would work as it uses a fail-safe approach in case it is missing. A super ugly fix could be something like sys.modules['faulthandler']=None before absl is imported. But that will only work in that very specific case, I'm sure you'll find out better ideas ;)
Thanks a lot for your support and for finding a viable solution to this!


windows 10 service disabler not most up to date version

this is not the the most up to date version of  windows 10 service disabler and the newset version of this script  disables hyper srvices and hp bloat

this is the latest version of this script

this is not the latest version of this script
lates version newer version:
previous version older version:
previosu version here
ps: when I got confidence creating a pull request i relised i diden't put .ps1 extention at the end

this is not the latest version of this script and was deleted
lates version newer version:
previous version older version:
previosu version here
ps: when I got confidence creating a pull request i relised i diden't put .ps1 extention at the end

this is not the latest version of this script
lates version newer newer version:
previous version older version: older version
ps: when I got confidence creating a pull request i relised i diden't put .ps1 extention at the end

this is not the latest version of this script
newer version: newer version:
previous version : older version
ps: when I got confidence creating a pull request i relised i diden't put .ps1 extention at the end

this is not the latest version of this script
newer version: newer version
previous version : older version
ps: when I got confidence creating a pull request i relised i diden't put .ps1 extention at the end


Experimental Implementation: Sisimai::RFC1894

Coverage increased (+0.02%) to 95.842% when pulling e6d8eaf66f67a7ec42eb3211d2f5e57dc585de9f on sisimai-rfc1894 into 254fabf3af331d1ac5676783bf6c06ad42233c53 on master.

Coverage increased (+0.02%) to 95.842% when pulling e6d8eaf66f67a7ec42eb3211d2f5e57dc585de9f on sisimai-rfc1894 into 254fabf3af331d1ac5676783bf6c06ad42233c53 on master.

Coverage increased (+0.02%) to 95.842% when pulling e6d8eaf66f67a7ec42eb3211d2f5e57dc585de9f on sisimai-rfc1894 into 254fabf3af331d1ac5676783bf6c06ad42233c53 on master.


Removed logic to list requests by approver via query parameter

Remove approver filtering parameter in endpoint /requests in favor of the new endpoint /requester/requests that was added recently.
https://projects.engineering.redhat.com/browse/SSP-475

@bzwei @hsong-rh
Can an approver log into the system as a regular user to order items? When he does that he doesn't need to see things that he needs to approve.

@mkanoor Yes, approver can login as regular user to create request. But in this case, he has dual roles, means he is able to see those requests waiting for him to process. The request list is provided by different endpoints: approver/requests for approver role, and requester/requests for regular user.


slow and the result is not that good

test  description
find the minimum value of (x1-1)**2 + (x2-2)**2
x1 is a float in [-10 ,10]
x2 is a float in [-10 ,10]
test 100 studies  and  each study has 100 trials
test code
optuna
import optuna
import time
import numpy as np
optuna.logging.set_verbosity(optuna.logging.ERROR)
start = time.time()
def objective(trial):
    x1 = trial.suggest_uniform('x1', -10, 10)
    x2 = trial.suggest_uniform('x2', -10, 10)
    return  (x1 - 1) ** 2 + (x2 - 2) ** 2

best_score=[]
for i in range(100):
    study = optuna.create_study()
    study.optimize(objective, n_trials=100)
    best_score.append(study.best_value)

end = time.time()
print(np.mean(best_score))
print(end-start)

time
647s
average of 100 results
0.27
btb
from btb import HyperParameter, ParamTypes
from btb.tuning import GP
import time
import numpy as np
import warnings
warnings.filterwarnings('ignore')

best_score = []

start = time.time()

for i in range(100):
    tunables = [
        ('x1', HyperParameter(ParamTypes.FLOAT,
                                        [-10, 10])),
        ('x2', HyperParameter(ParamTypes.FLOAT,
                                        [-10, 10]))
    ]
    tuner = GP(tunables)

    for i in range(100):
        params = tuner.propose()
        #  print('params',params)
        score = -(params['x1'] - 1) ** 2 -  (params['x2'] - 2) ** 2
        tuner.add(params, score)
    best_score.append(tuner._best_score)

end = time.time()
print(np.mean(best_score))
print(end-start)

time
264s
average of 100 results
0.002

First, It's better to separate the problem of speed and the problem of optimization's result.
In general, the time consumed by the optimization library is significantly less than the time taken to evaluate the ML model in the object function. Optuna seems to be slower than btb, but spending about 6 seconds for 100 trials won't be a problem in almost situations. At least, I think keeping a clean design is more important than this problem.
In the viewpoint of performance, Optuna use TPE (The example of btb you pasted uses GP based bayesian optimization). Optuna will support GP based bayesian optimization at #380 and #399.

I am a newcomer to this aspect. Thank you for your patient.  You are right, I realized that the time is indeed not a problem.
I also made a test on SMAC, this is just one study. You can see that it's much slower than optuna and btb. 10 trials cost about 55s. But the result is pretty good.

After all these tests, I found that optuna is much easier for beginners to use. And it also supports saving/resuming studies.  I hope optuna can support more algorithms. Thank you.

Regarding the difference between the results of Optuna and btb, as mentioned above, I think that it is due to the difference of surrogate models (Optuna uses TPE and btb uses Gaussian Process).
Eggensperger confirmed that Gaussian Process based Bayesian optimization performs better than TPE and SMAC for low-dimensional functions [Eggensperger 13].
And for the results of SMAC, it looks like the initial value of SMAC is given a very good value (the initial value of SMAC is (0, 0) that is near the optimal value (1, 2)).
If you experiment with the different setting, the result may change.
[Eggensperger 13] Eggensperger, K., Feurer, M., Hutter, F., Bergstra, J., Snoek, J., Hoos, H., and Leyton-Brown, K.: Towards an Empirical Foundation for Assessing Bayesian Optimization of Hyperparameters, in NeurIPS workshop on Bayesian Optimization in Theory and Practice (2013).

Thank you. It helps me a lot. Let me paste the result of the paper  here.

It looks this issue is resolved, right?

@c-bata Yes, please close the issue. Thank you

@c-bata @nmasahiro Thank you for your perfect answers!
I will close this issue.
FYI about execution time
In consideration of safety, Optuna applies copy.deepcopy() when trial objects are retrieved from storage.
Besides, gc.collect() is called each time a trial is finihsed (https://github.com/pfnet/optuna/pull/377).
In the above test, the overhead of these processing takes most of the execution time (see below):
$ vim optuna-test.py  # Write the above test code

# Execute
$ python optuna-test.py
0.34231789837718446
524.1540217399597    # 524 seconds

# Apply a patch to remove memory copies and GCs
$ patch -p1 <<EOS
> diff --git a/optuna/storages/in_memory.py b/optuna/storages/in_memory.py
> index 7cd63cc..bc5591f 100644
> --- a/optuna/storages/in_memory.py
> +++ b/optuna/storages/in_memory.py
> @@ -253,7 +253,7 @@ class InMemoryStorage(base.BaseStorage):
>
>          self._check_study_id(study_id)
>          with self._lock:
> -            return copy.deepcopy(self.trials)
> +            return self.trials # return copy.deepcopy(self.trials)
>
>      def get_n_trials(self, study_id, state=None):
>          # type: (int, Optional[structs.TrialState]) -> int
> diff --git a/optuna/study.py b/optuna/study.py
> index da99fce..21554ec 100644
> --- a/optuna/study.py
> +++ b/optuna/study.py
> @@ -416,7 +416,7 @@ class Study(object):
>              # environments (e.g., services that use computing containers such as CircleCI).
>              # Please refer to the following PR for further details:
>              # https://github.com/pfnet/optuna/pull/325.
> -            gc.collect()
> +            pass # gc.collect()
>
>          try:
>              result = float(result)
> EOS
patching file optuna/storages/in_memory.py
patching file optuna/study.py

# Re-execute
$ python optuna-test.py
0.3058921208529839
15.914953231811523  # 15 seconds


feat: add JAX as Computation Backend

Integrating JAX as a computation backend in Docarray similar to Pytorch, Tensorflow, and Numpy

[x] JaxArray typing implementation
[x] JaxArray typing unit tests
[x] JaxCompBackend methods implementation
[x] JaxCompBackend basic tests
[x] DocVec working
[x] Integration tests
[x] function annotations and commenting
[x] docs updations

from docarray import BaseDoc
from docarray.typing import JaxArray
import jax.numpy as jnp

class MyDoc(BaseDoc):
    arr: JaxArray
    image_arr: JaxArray[3, 224, 224]
    square_crop: JaxArray[3, 'x', 'x']
    random_image: JaxArray[3, ...]  # first dimension is fixed, can have arbitrary shape

# create a document with tensors
doc = MyDoc(
    arr=jnp.zeros((128,)),
    image_arr=jnp.zeros((3, 224, 224)),
    square_crop=jnp.zeros((3, 64, 64)),
    random_image=jnp.zeros((3, 128, 256)),
)
assert doc.image_arr.shape == (3, 224, 224)

# automatic shape conversion
doc = MyDoc(
    arr=np.zeros((128,)),
    image_arr=np.zeros((224, 224, 3)),  # will reshape to (3, 224, 224)
    square_crop=np.zeros((3, 128, 128)),
    random_image=np.zeros((3, 64, 128)),
)
assert doc.image_arr.shape == (3, 224, 224)

btw looking at the CI it seems that you still have place where you load jax without using the helper import and therefore it throw an error

Hey @agaraman0 ,
would it be possible for you to add a code snippet as an example of the usage of this feature in the PR description. Like this we can add it in future release notes to highlight this awesome feature.

Hey @agaraman0 ,
would it be possible for you to add a code snippet as an example of the usage of this feature in the PR description. Like this we can add it in future release notes to highlight this awesome feature.

Sure will do that, I am just looking for some existing example if I can replicate one.

@agaraman0 can you add an equivalent test to the one added for Pytorch and TF in this PR #1696

Hey @samsja @JoanFM  PR is ready to be merged, addressing all concerns and review comments.


ntr: CMG & MCM complex processes

id: GO:new1
name: CMG complex assembly
def: The aggregation, arrangement and bonding together of a set of components to form the CMG complex, a protein complex that contains the GINS complex, Cdc45p, and the heterohexameric MCM complex, and that is involved in unwinding DNA during replication. The process begins when additional proteins (e.g. Cdc45 and Sld3) join the loaded, inactive double MCM hexamer at replication origins, and ends when Mcm10 triggers the separation of the Mcm2-7 double hexamers, forming two active CMG complexes. [PMID:28501329, PMID:22718908]
is_a: GO:0022402 ! cell cycle process
is_a: GO:0065004 ! protein-DNA complex assembly
GO:1902315 ! nuclear cell cycle DNA replication initiation
id: GO:new2
name: MCM complex loading
def: The protein localization process in which two MCM complexes become associated with chromatin at replication origins. MCM loading begins when origin-bound ORC and Cdc6 (Cdc18 in fission yeast) recruit one MCM2-7/Cdt1 complex to the origin, includes formation of a succession of intermediate complexes and ATP hydrolysis-dependent Mcm2-7 ring closure, and ends when two MCM hexamers fully encircle DNA, and are oriented head-to-head. The double hexamer is inactive for DNA unwinding. MCM loading takes place during G1 phase, and precedes CMG complex assembly."
[MPDI:23603117, PMID:28191893, PMID:28191894, PMID:28501329]
synonym: "MCM complex loading at replication origin" EXACT [GOC:mah]
synonym: "MCM double hexamer formation at replication origin" EXACT [GOC:mah]
is_a: GO:0022402 ! cell cycle process
is_a: GO:0065004 ! protein-DNA complex assembly
GO:1902315 ! nuclear cell cycle DNA replication initiation
I don't know whether it's worth also adding terms for the various complexes formed as precursors or intermediates in either of these processes (e.g. OCCM, pre-LC; see figs 1 & 2 of PMID:28191893). It might spawn a mini-project that I don't have time to tackle!

any word on this?

at @pgaudet's invitation in the GO meeting, pinging my open tickets

Hi @mah11 Thanks for the reminder.
CMG complex assembly -> sound like DNA is not an integral part of the complex ? I would rather have it simply under 'protein-containing complex' and the assembly term under 'protein-containing complex assembly'. Or the definitions should be changed. What do you think ?

Also for ' MCM complex loading' ->  according to your definition, would it not fir better under 'GO:0070727 cellular macromolecule localization' rather than 'protein-DNA complex assembly'?
Thanks, Pascale

CMG complex assembly -> sound like DNA is not an integral part of the complex

This is not correct; CMG is a complex of proteins on DNA (some bind directly, and others indirectly by binding DNA-bound proteins), and never exists without the DNA. The portion of the definition that says "additional proteins ... join the loaded, inactive double MCM hexamer at replication origins" indicates this -- "loaded ... MCM" refers to an MCM double hexamer that has bound to DNA, and of course "replication origins" are DNA sequences.
I don't object if you want to change the def wording somehow, but I don't know exactly what to suggest.

Also for ' MCM complex loading' -> according to your definition, would it not fir better under 'GO:0070727 cellular macromolecule localization' rather than 'protein-DNA complex assembly'?

Well, the definition explicitly states that the outcome of the loading process is that "two MCM hexamers fully encircle DNA". I can see how MCM loading could also fit "macromolecule localization", but I'm not convinced that localization fits better thas assembly. If MCM loading isn't protein-DNA complex assembly it's a challenge to think of anything that is.
I'm trying, but failing, to remember why I put "protein localization process" in the text for one def but not the other ... in both processes some proteins get localized to where some others are already on DNA at origins, forming new protein-DNA complexes, so to me both processes would actually fit under both protein localization and complex assembly.

p.s. both should be part_of GO:1902315 ! nuclear cell cycle DNA replication initiation ... I just spotted that the part_of relation is missing from the stanzas

Here you go
+[Term]
+id: GO:0140529
+name: CMG complex assembly
+namespace: biological_process
+def: "The aggregation, arrangement and bonding together of a set of components to form the CMG complex, a protein complex that contains the GINS complex, Cdc45p, and the heterohexameric MCM complex, and that is involved in unwinding DNA during replication. The process begins when additional proteins (e.g. Cdc45 and Sld3) join the loaded, inactive double MCM hexamer at replication origins, and ends when Mcm10 triggers the separation of the Mcm2-7 double hexamers, forming two active CMG complexes." [PMID:22718908, PMID:28501329]
+is_a: GO:0022402 ! cell cycle process
+is_a: GO:0065004 ! protein-DNA complex assembly
+intersection_of: GO:0065004 ! protein-DNA complex assembly
+intersection_of: results_in_assembly_of GO:0071162 ! CMG complex
+relationship: part_of GO:1902315 ! nuclear cell cycle DNA replication initiation
+property_value: term_tracker_item https://github.com/geneontology/go-ontology/issues/16570 xsd:anyURI
+created_by: pg
+creation_date: 2020-10-12T16:42:17Z
+
+[Term]
+id: GO:0140530
+name: MCM complex loading
+namespace: biological_process
+def: "The protein localization process in which two MCM complexes become associated with chromatin at replication origins. MCM loading begins when origin-bound ORC and Cdc6 (Cdc18 in fission yeast) recruit one MCM2-7/Cdt1 complex to the origin, includes formation of a succession of intermediate complexes and ATP hydrolysis-dependent Mcm2-7 ring closure, and ends when two MCM hexamers fully encircle DNA, and are oriented head-to-head. The double hexamer is inactive for DNA unwinding. MCM loading takes place during G1 phase, and precedes CMG complex assembly." [] {comment="PMID:28501329", comment="PMID:28191894", comment="PMID:23603117", comment="PMID:28191893"}
+synonym: "MCM complex loading at replication origin" EXACT []
+synonym: "MCM double hexamer formation at replication origin" EXACT []
+is_a: GO:0022402 ! cell cycle process
+is_a: GO:0065004 ! protein-DNA complex assembly
+relationship: part_of GO:1902315 ! nuclear cell cycle DNA replication initiation
+property_value: term_tracker_item https://github.com/geneontology/go-ontology/issues/16570 xsd:anyURI
+created_by: pg
+creation_date: 2020-10-12T16:46:23Z
I'm not sure we need the intermediate complexes ?
Thanks, Pascale

brilliant; thanks!
I have no immediate need for the intermediate complexes, and I really don't want to get sidetracked into trying to craft definitions for them!


(BKR-372) add support for ubuntu 15.04, Vivid, amd64 & i386

not quite sure what is going on here, but removing the timeout and
using the Net::SSH default allows ubuntu15.04 to reboot successfully
(was stuck on a blocking call to Net::SSH.start)

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1250/
Test PASSed.


add Shutdown method on the Chi Server

The Server does not provide a method for shutting down, making graceful shutdown impossible.

My suggestion is to modify the Server struct to keep the httpServer reference and add the Shutdown method that will call the httpServer Shutdown.
type Server struct {
	mux        *chi.Mux
	opts       *server.Options
	httpServer *http.Server
}

...

func (s *Server) Shutdown(ctx context.Context) {
	logger := log.FromContext(ctx)

	if err := s.httpServer.Shutdown(ctx); err != nil {
		logger.Fatalf("chi http server shutdown failed:%+v", err)
	}

	logger.Info("shutdown chi http Server")
}


Update references to Triton to version 22.02

@viclafargue There's a reference in the README that also needs to be updated


Improvement suggestion: mark active buttons in toolbar

It would be great if the toolbar buttons have a class to indicate if they are active (on/off).

+1


access log: log TLS related errors for HTTP

Description:
While upstream TLS is configured, HTTP access log is not aware of any of them. Access log response code UF, UR, UC are potential code for TLS errors such as peer certificate expired, not trusted, protocol or cipher mismatch handshake timeout etc. It would be nice if we could do for downstream too but we don't have enough request information, though for upstream the log should be aware.

not stale


Gate count jumps after finalization

While creating instance during IVC, if we compare the number of gates before and after finalization, we'll get the following:

So there's obviously some bug

Ended up tracking this back to a discrepancy in the non-native-field gate count produced by get_num_gates() and the actual number of nnf gates that are produced in finalize_circuit() and added to the num_gates total. Note that get_num_gates does not account for "de-duplications" in nnf gates, whereas finalize_circuit() does. So before finalization, get_num_gates() overestimates how many nnf gates we'll need. During finalization we actually add fewer than expected due to duplicates. When we call get_num_gates a second time, it doesn't compute it, it just returns num_gates directly, and thus the total is lower.

Perhaps this is resolved by https://github.com/AztecProtocol/aztec-packages/pull/5211

@codygunton I don't think so but I'd have to dig in to be sure. The Pr you linked was an ECCVM optimization but the num_gates issue is purely an Ultra issue.


chore: add additional logging for efm

Summary

Description

Additional Reviewers

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Do we have an issue to refer to that prompted this change ?

Do we have an issue to refer to that prompted this change ?

Yes, #675. I've updated the PR description.


whatshap error: Read name occurs more than twice in the input file

Description of the bug
Whenever I try to run the pipeline using a reduced revio fastq file as a test, I run into this error: Read name occurs more than twice in the input file. Up to that point I have not experienced any problems. Do you have idea what is going on, is there a way to get around this error?
Command used and terminal output
ERROR ~ Error executing process > 'FELLEN31_SKIERFE:SKIERFE:PHASING:WHATSHAP_PHASE (pr_001_001)'

Caused by:
  Process `FELLEN31_SKIERFE:SKIERFE:PHASING:WHATSHAP_PHASE (pr_001_001)` terminated with an error exit status (1)

Command executed:

  whatshap phase \
      --ignore-read-groups --indels --distrust-genotypes \
      -o pr_001_001.sorted.vcf.gz.phased.vcf \
      --reference GCA_000001405.15_GRCh38_no_alt_analysis_set_nochr.fna \
      pr_001_001.sorted.vcf.gz \
      pr_001_001.bam

  bgzip \
      -@ 2 \
      pr_001_001.sorted.vcf.gz.phased.vcf

  tabix \
      -p vcf \
      pr_001_001.sorted.vcf.gz.phased.vcf.gz

  cat <<-END_VERSIONS > versions.yml
  "FELLEN31_SKIERFE:SKIERFE:PHASING:WHATSHAP_PHASE":
      whatshap: $( whatshap --version )
      bgzip: $( bgzip --version | head -n 1 | sed 's/bgzip (htslib) //g')
      tabix: $( tabix --version | head -n 1 | sed 's/tabix (htslib) //g')
  END_VERSIONS

Command exit status:
  1

Command output:
  (empty)

Command error:
  WARNING: Ignoring --row-limit as heuristic is not used as algorithm.
  WARNING: Ignoring --indels as indel phasing is default in WhatsHap 2.0+
  This is WhatsHap 2.2 running under Python 3.9.18
  [E::idx_find_and_load] Could not retrieve index file for 'pr_001_001.sorted.vcf.gz'
  [E::idx_find_and_load] Could not retrieve index file for 'pr_001_001.sorted.vcf.gz'
  [E::idx_find_and_load] Could not retrieve index file for 'pr_001_001.sorted.vcf.gz'
  Working on 1 sample from 1 family

  # Working on contig 1 in individual pr_001_001
  Found 6443 usable heterozygous variants (3298 skipped due to missing genotypes)
  ERROR: whatshap error: Read name 'm84045_230420_150058_s1/198967705/ccs' occurs more than twice in the input file

Relevant files
No response
System information
Nextflow v.23.04.2,
HPC,
slurm,
Singularity,
CentOS Linux,
fellen31/skierfe v1.0dev

Hi,
Could you double check if you have multiple copies of this read in your input file? For example with:
zgrep -c "m84045_230420_150058_s1/198967705/ccs" REVIO_TEST_DATA.fastq.gz

Ah, it sure was one to many copies in the fastq file! It has been rectified and now it runs through the whatshap process as it should, thanks!
Regards,
Paul


No such module 'NSEntityDescription_SYNCPrimaryKey'

I'm installing Sync with that pod (for Swift 2.3):
	pod 'Sync', '~> 1'
I receive an error when trying to build:
/Pods/Sync/Source/NSManagedObject+Sync.swift:2:8: No such module 'NSEntityDescription_SYNCPrimaryKey'
import CoreData
import NSEntityDescription_SYNCPrimaryKey // error here
import DATAStack
import NSString_HYPNetworking
import DATAFilter

I had exactly the same problem:
Pods combination:
pod 'Alamofire', '3.5.0'
pod 'Sync', '1.14.3'
pod 'NSManagedObject-HYPPropertyMapper', '4.1.1'
pod 'DateParser', '0.1.0'
works for me as a temporary fix :)
Hope it helps.

Can you try again? The latest release should fix this problem.
https://github.com/SyncDB/Sync/releases/tag/1.15.0

Let me know if I should re-open this issue. Thanks for reporting it!


Rewarders

This PR adjusts the initial mapping environment to allow for a rewarder that takes into account the fidelity of edges in the connection_graph. This rewarder is implemented as the FidelityEpisodeRewarder.

@S-Linde I didn't manage to fix all typing and linting issues. Could you have a look into those aspects? I marked two places in code with a TODO fix mypy.

@S-Linde I didn't manage to fix all typing and linting issues. Could you have a look into those aspects? I marked two places in code with a TODO fix mypy.

Sure, I'll take a look.


Conversation Sidebar tweaks

💬 Description
A couple of tweaks for use in the conversation sidebar:

Spreading rest onto Layout.Body
adding onTransitionEnd to sidebar.

✅ Checklist

[ ] Tests written
[ ] Browser tested
[ ] Added to documentation
[ ] Added to storybook

 Fade out the blank slate after clicking 'Leave a comment' over 300ms


https request very slowly

I am using hey/Jmeter to perform load testing on HTTPS site. HTTP request very fast but when I play script HTTPS Request is working very slow. It take long time to initiate and complete each request as shown below in image.
Hoverfly is running simulate mode.
hey -n 50  -c 50 -x http://localhost:8500 https://api.restful-api.dev/objects

hey -n 50  -c 50 -x http://localhost:8500 http://api.restful-api.dev/objects

It's likely that the goproxy library is not caching the TLS connection... You can try using  hoverfly as a webserver to help you with simulating loads for the time being.


Redirected input should terminate on first uncaught exception.

In production (if not testing), multi-line scripts should not be run in interactive mode (i.e., be passed as the user input device).

I disagree.

In interactive mode, when an error occurs, the Forth system eventually discards the parse area (the remaining part of the input buffer) and reads the new line from the input stream (that is the user input device).
So if a script file is used as the user input device (by redirection), and an error occurs in the middle of the script (for example, a word is not found, or r/o open-file throw and the file is absent),  then interpreting of the remaining part of the script will probably produce more errors.  This does not make any sense in production.
Just an illustration of what I mean:
post4 <<EOF
: foo
  -#123 .
;
foo
EOF

There is no point in continuing to interpret the input file after the first error.  Therefore, you probably will not pass a script to the Forth system stdin in a production environment.
This also means that from the user's perspective it is better if post4 script.p4 is equivalent to post4 -i script.p4 rather than post4 < script.p4.
Originally posted by @ruv in https://github.com/ForthHub/discussion/discussions/185#discussioncomment-11169487

Using this input:
132 dup . cr quit cr 456 . cr
.( say something clever here )

So something like this for the four cases:
elf$ ./post4 ../test/data/quit0.p4 ; echo $?
132
ok
3
elf$ ./post4 <../test/data/quit0.p4 ; echo $?
132
3
elf$ ./post4 -i ../test/data/quit0.p4 ; echo $?
132
ok
3
elf$ ./post4 ; echo $?
ok include ../test/data/quit0.p4
132
ok
3
elf$

Should not it output "say something clever here" in the second case (when the input is redirected)?

What is your rationale to provide a nonzero exit status when the system terminates due to the end of the input?
If the end of input is unexpected, the error -39 "unexpected end of file" can be thrown.

Why are the following cases produce different exit status?

echo "1" | post4  ; echo $?
echo "1 quit" | post4  ; echo $?

Should not it output "say something clever here" in the second case (when the input is redirected)?

No, based on other other this portion of discussion and the following 3 comments.   Because redirected input is not interactive (isatty(STDIN_FILENO) is false), so it terminates on the first uncaught exception.

2. What is your rationale to provide a nonzero exit status when the system terminates due to the end of the input?
   If the end of input is unexpected, the error -39 "unexpected end of file" can be thrown.

As I've mentioned before (somewhere, I'm losing track where all the conversation threads), if the batch job or session generates one or more uncaught exception anytime during the job/session, then on EOF the exit status would be 3.  Otherwise a BYE or BYE-STATUS could exit with an explicit status.
I would not consider this to be a case of unexpected EOF.  Unexpected EOF in my mind would be when you only read part of a UTF8 encoding or part of a BASE64 quantum or similar case were you expect more input to complete some sequence.  Maybe EOF in an unfinished word definition would count too.

3. Why are the following cases produce different exit status?

echo "1" | post4  ; echo $?
echo "1 quit" | post4  ; echo $?\

QUIT is considered an exception even though it can never be caught; it terminates processing unexpectedly (?).  And follows much of the same code path as ABORT et al.  However I did pose a question of you a few days back as to whether it should be treated this way with no answer.
Interactive users are less interested in the exit status; but redirected / scripted QUIT, ABORT, and THROW are exceptional and IMO should be treated all the same.

if the batch job or session generates one or more uncaught exception anytime during the job/session, then on EOF the exit status would be 3.

Ah, I see. I didn't think QUIT was an exception, so I thought it was because of EOF.

However I did pose a question of you a few days back as to whether it should be treated this way with no answer.

Do you mean this one?

Interactive users are less interested in the exit status;

Agreed.   Then, it is not necessary to count uncaught exceptions in interactive mode.

but redirected / scripted QUIT, ABORT, and THROW are exceptional and IMO should be treated all the same.

Well, I still think that redirected stdin can be treated as interactive, at least in some cases (it is useful for testing).
I agree that QUIT and ABORT can be considered to have the same level of severity. But other uncaught exceptions have a higher severity level, for my taste 🙃

if the batch job or session generates one or more uncaught exception anytime during the job/session, then on EOF the exit status would be 3.

Ah, I see. I didn't think QUIT was an exception, so I thought it was because of EOF.

How would you describe it?  It has an Exception Code, its part of ABORT which also has an exception code, disrupts normal control flow.

However I did pose a question of you a few days back as to whether it should be treated this way with no answer.

Do you mean this one?

Yes.  Though the answer felt underwhelming.

Interactive users are less interested in the exit status;

Agreed. Then, it is not necessary to count uncaught exceptions in interactive mode.

Well the code paths are pretty much 99.9% the same for interactive / redirected or scripted. The only behaviour differences are no prompt, no command line editing when redirected/scripted.

but redirected / scripted QUIT, ABORT, and THROW are exceptional and IMO should be treated all the same.

Well, I still think that redirected stdin can be treated as interactive, at least in some cases (it is useful for testing).

Redirected stdin is not interactive, since input is not from a terminal, but a stream.

I agree that QUIT and ABORT can be considered to have the same level of severity. But other uncaught exceptions have a higher severity level, for my taste 🙃

Like hot spices, strong mustards, chillies, something with kick?  Mmm.
While other exceptions may be viewed or treated with greater importance, technically they behave the same as ABORT, just the exception code changes (and text description).  Other than QUIT, I don't see any difference with exceptions.  If there are differences, they're not clearly documented or explained.  There are a who list of exceptions that seem redundant or unused (at least in Post4), but they all behave like ABORT internally.

Redirected stdin is not interactive, since input is not from a terminal, but a stream.

By "interactive mode" I only mean a reaction on an uncaught exception. Maybe this term is not quite appropriate.
Anyway, the word ACCEPT, which reads characters from the user input device, usually works when stdin is redirected.
For example:
echo "foobar" | gforth -e 'pad dup 80 accept swap type cr bye'

Output:
foobar

Should not it output "say something clever here" in the second case (when the input is redirected)?

No, based on other other this portion of discussion and the following 3 comments. Because redirected input is not interactive (isatty(STDIN_FILENO) is false), so it terminates on the first uncaught exception.

The following two commands shall produce the same output:
post4 <<EOF
pad dup 80 accept
foobar
type cr
EOF

post4 <<EOF
quit
pad dup 80 accept
foobar
type cr
EOF

If accept reads the redirected stdin, than quit shall read it too, regardless the mode.

If accept reads the redirected stdin, than quit shall read it too, regardless the mode.

I'm confused.  Is that a good thing or a bad thing?

OK.  I think I've come see how QUIT is not an exception.  As you've explained before QUIT is the historical REPL.  It cannot be caught since it resets the exception stack (at least it should).  As such QUIT on its own should not cause exit 3 at the end of session.  However other exceptions might occur along with QUIT during a session and at exit they (the other exceptions) result in exit 3.
Does that make sense?  (Probably as much sense as my puppy stealing my socks.)

If accept reads the redirected stdin, than quit shall read it too, regardless the mode.

I'm confused. Is that a good thing or a bad thing?

That is a good thing.  Otherwise, that would be inconsistent.

It cannot be caught since it resets the exception stack (at least it should).

Not only for that.  Even if the exception stack is not touched, nothing can be caught because it never throws an exception.

However other exceptions might occur along with QUIT during a session and at exit they (the other exceptions) result in exit 3.
Does that make sense?

Yes, a nonzero exit status makes sense in these conditions. At least, it can be noticed by the caller script/program when stdin is redirected.

(Probably as much sense as my puppy stealing my socks.)

😄

Because redirected input is not interactive (isatty(STDIN_FILENO) is false), so it terminates on the first uncaught exception.

Redirected input can be interactive (i.e., under user's interactive control). For example, the Forth system process runs under ncat, and the user is on the other side of the pipe or socket. So I dislike the idea of determining interactive mode with isatty.
Perhaps isatty can be used to determine available capabilities, but not the mode.
As an example, in mysql client a similar problem exists (i.e., whether to terminate after the first error on stdin or continue), and it provides a command line argument to enable batch mode.
One more argument: it's formally unclear why throw does not call quit when there no exception frame and the stdin is redirected.

Because redirected input is not interactive (isatty(STDIN_FILENO) is false), so it terminates on the first uncaught exception.

Redirected input can be interactive (i.e., under user's interactive control). For example, the Forth system process runs under ncat, and the user is on the other side of the pipe or socket. So I dislike the idea of determining interactive mode with isatty.

Ah. Finally get what you mean by "Redirected input can be interactive", like telnet to a sock-et (beware of puppy) talking to Forth.

Perhaps isatty can be used to determine available capabilities, but not the mode.

Well isatty means terminal, which means I can enable line editing & history, though I suppose that could allowed to pass through a socket.

As an example, in mysql client a similar problem exists (i.e., whether to terminate after the first error on stdin or continue), and it provides a command line argument to enable batch mode.

I'll have to think about this, whether to add a new option.  Normally if I'm redirecting input I want it scripted or piped etc. by default because i'm writing some filter / command line script (like sed or awk) to process input.

One more argument: it's formally unclear why throw does not call quit when there no exception frame and the stdin is redirected.

Huh?  I assume you are talking about the standard or you making a comment on Post4?

One more argument: it's formally unclear why throw does not call quit when there no exception frame and the stdin is redirected.

Huh? I assume you are talking about the standard or you making a comment on Post4?

When post4 terminates on the first uncaught exception if the input is redirected, it violates the behavior specified by the standard.  But it's unclear what the formal difference is between "redirected input" and "not-redirected input".
An argument in the command line (that enables terminating on the first uncaught exception) is a clear and obvious thing, at least. And it can be considered as a system-dependent program.

When post4 terminates on the first uncaught exception if the input is redirected, it violates
behavior specified by the standard. But it's unclear what the formal difference is between "redirected input" and "not-redirected input".

Well originally I didn't terminate on first uncaught exception.  But then you gave me feed back about how continuing to process would yield useless knock-on exceptions when input is redirected.
Now you don't like this idea of terminating on first uncaught exception for redirected input.
Which is it?  I can remove the is_tty check I added and restore the old behaviour, which wouldn't be bad IMO (the is_tty check feels like a hack).  The user just has to understand the first error is the only one that matters.  Its much like early C compilers would generate a cascade of knock-on errors; fix the first and a whole bunch of errors go away.
In many ways I prefer this old behaviour, because the program behaves consistently for interactive  and redirected input.

But then you gave me feed back about how continuing to process would yield useless knock-on exceptions when input is redirected.

Yes, but that was an argument for adding a command line option that enables batch mode 🙃
is_tty can be useful to enable line editing (if not in batch mode).

The user just has to understand the first error is the only one that matters.

If the user redirects a file to stdin, he should probably enable batch mode (to terminate on the first error). If the user redirects user input from another program/pipe to stdin, they will not enable batch mode.


Spotify Ads

Ads definitely still come up in Spotify. Even after removing & reinstalling, respringing/rebooting, and running iCleaner. I am on the latest version of Spotify. My device is a 6+ on 9.3.3. I am also using BdaySpotify2, Anywhere!, and a flex tweak that could be modifying the app, but I feel like hosts blocking should precede all of that.

Thanks for opening an issue here. I will push a little experimental build to the latest pull request later tonight with experimental Spotify blocking. In the first version I had blocking for Spotify ads but it was breaking Spotify for some people so I removed it.


Add higher-level of testing for "queue-name" handling in pod-based workloads

What would you like to be cleaned:
Add integration-level testing for pod-based integrations (Pod themselves, STS, Deployment).
In particular cover scenarios related to the recent changes around namespace filtering and LQ defautling.
We may also consider adding a suite for e2e tests with manageJobsWithoutQueueName: true.
Why is this needed:
The logic around "queue-name" handling is getting complex, but the tests for Jobs aren't enough, because the handling is mostly separate for pod-based serving workloads.

cc @mbobrovskyi @dgrove-oss @yaroslava-serdiuk @tenzen-y

Actually, I think with https://github.com/kubernetes-sigs/kueue/issues/3804 it should be relatively simple to start a new e2e suite within the same CI job with that configuration. So, I would suggest starting with that. The Pod-based integration is easier to test e2e than integration, because pods are actually created by kube-controller-manager's controllers (Deployment or StatefulSets). cc @dgrove-oss @tenzen-y @mbobrovskyi

/assign

/unassign
Sorry, I don't have capacity to work on it for now.


Invite your POSTER for our pre-heat for the CVPR offline conference in Seattle

We sincerely look forward to your poster and will arrange a collection (will show on bilibili)for all authors as a pre-heat for the offline conference. It is  convenient for everyone to discuss the posters in advance and this will be a period of significant memory for everyone. You can also send us the exhibition information with poster.
Our email<EMAIL_ADDRESS>WeChat：AIDriver002

Thank you for your interest in our paper. We have mailed it.

Oh~Get it！Next week we will email you our pre-heat video !
At 2024-06-11 14:29:47, "zoomin-lee" @.***> wrote:
Thank you for your interest in our paper. We have mailed it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Question: how to use switchDatabase?

Hi, I am working with multiple dbs on the same mysql server/instance, and I need to switch db when migrate.
Is there any examples about how to use switchDatabase?

Hey @WClouds ,
This actually depends on the database. this works for mysql though:
https://github.com/db-migrate/mysql/blob/master/index.js#L183
Using it in your migrations might only work within a single migration and you would need to switch back as the migration table would be missing. This is currently not yet completely available on that level. However, there is support at scoping level to switch databases. Please refer to the scoping config example over here:
https://db-migrate.readthedocs.io/en/latest/Getting Started/the commands/#scope-configuration
Also notice this only works for some databases. There are dbs where there are known issues. Talking especially about postgres here, which has no support for switching the db on the same connection. There are a couple of things that will change in the near future concerning this. I will keep you updated as soon as I have news for you on that topic here. Don't hesitate to bug me again shouldn't you hear from me again though :)


Cortex-R5 and Cortex-R5F

What about the core Cortex-R5F ? Are they planned to be included in the CMSIS-6 and CMSIS-DSP ?

Hi @edbek, please check pull-request #45 which adds initial support for Cortex-R. Please consider collaborating on this.

Closing due to inactivity. Please reopen if you think this should be discussed further.


Tallow Bomb doesn't display damage button.

An attack with a Tallow Bomb just results in a hit/miss post, with no way to display the persistent damage or splash.

Based on a discord conversation, it sounds like the issue is the bomb having zero base damage.

I'm able to replicate the behavior on other bombs by setting the base damage to zero

Testing Environment:

I believe this is fixed by recent changes.


[Brave] Searching within Brave's History doesn't work

Extension
https://www.raycast.com/ron-myers/brave
Raycast Version
1.77.1
macOS Version
14.5
Description
Searching within History doesn't work. It shows Brave's history, it's just search that doesn't work.
Searching Bookmarks and Tabs seems fine.
Steps To Reproduce
Activate "Search Brave History".
Type in the name of one of the history items

It doesn't filter any items
Current Behaviour
Enter a search within "Search Brave History"
It doesn't filter any items
Expected Behaviour
"Search Brave History"
It should filter items based on the search term

…actually, I'm now encountering a problem when I run "Search Brave Tabs".
This must be a very recent problem, I haven't seen this before (but have seen problems searching history for a while).


Uncaught TypeError: storage.getItem is not a function with create-react-app and polyfills

I'm trying out connect-wallet with vanilla setup and am receiving Uncaught TypeError: storage.getItem is not a function from redux-persist using create-react-app and polyfills for Buffer and process.
I'm using https://github.com/niksy/node-stdlib-browser for the polyfills.
Is this error related to a missing polyfill?
Do you have an example of connect-wallet in create-react-app?

 My assumption might be similar to yours in that it is possibly a missing polyfill.
Would you be able to provide a sample app / repo that we can use for testing? If you could use a service like CodeSandbox that would be great :)
Not to dismiss the usage of Create React App, I do want to help resolve the issue, but I might recommend that if you're not set on using Create React App, it might be worthwhile to consider using more modern tooling such as Vite.
Here is a CodeSandbox that uses Vite if you're interested in what that might look like.

Hey 👋 . I think you're right that I'd benefit from switching to something like Vite. I've been meaning to make the switch.
My create-react-app is fairly ordinary, except that I'm using a fork of create-react-app for polyfills and tailwind support
  "react-scripts": "https://gitpkg.now.sh/ryanberckmans/create-react-app/packages/react-scripts?08746634d19a73958ba9b764b3cda418e1fce151",

I'll switch to Vite asap, and then try connect-wallet again. I'm looking forward to it, the library looks quite competitive, thanks for making it.


Demonstrate usage with protocol buffers and grpc

Show https://rules-proto-grpc.com/en/latest/lang/js.html and/or https://github.com/stackb/rules_proto/tree/master/rules/nodejs examples in this repo.

This would be great. I'm having some trouble getting this to work, where it did before.
With the old rules_js repo, I defined a custom plugin:
tools/bazel/ts_proto_compile/BUILD.bazel:
load("@rules_proto_grpc//:defs.bzl", "proto_plugin")

proto_plugin(
    name = "ts_proto_compile",
    outputs = ["{protopath}.ts"],
    protoc_plugin_name = "ts_proto",
    tool = "@npm//ts-proto/bin:protoc-gen-ts_proto",
    visibility = ["//visibility:public"],
)

tools/bazel/ts_proto_compile/def.bzl:

load(
    "@rules_proto_grpc//:defs.bzl",
    "ProtoPluginInfo",
    "proto_compile_attrs",
    "proto_compile_impl",
)

ts_proto_compile = rule(
    implementation = proto_compile_impl,
    attrs = dict(
        proto_compile_attrs,
        _plugins = attr.label_list(
            providers = [ProtoPluginInfo],
            default = [
                Label("//tools/bazel/ts_proto_compile"),
            ],
            doc = "List of protoc plugins to apply",
        ),
    ),
    toolchains = [
        str(Label("@rules_proto_grpc//protobuf:toolchain_type")),
    ],
)

Then using it like:
load("//tools/bazel/ts_proto_compile:defs.bzl", "ts_proto_compile")

ts_proto_compile(
    name = "google_ts",
    protos = [
        "@com_google_protobuf//:any_proto",
        "@com_google_protobuf//:duration_proto",
        "@com_google_protobuf//:struct_proto",
        "@com_google_protobuf//:timestamp_proto",
        "@com_google_protobuf//:wrappers_proto",
        "@go_googleapis//google/rpc:status_proto",
        "@go_googleapis//google/rpc:code_proto",
        "@go_googleapis//google/type:money_proto",
    ],
)

However, changing to the new tool path:
   tool = "//:node_modules/ts-proto/protoc-gen-ts_proto",

gives the error:
INFO: Invocation ID: 7955c9de-0498-43e7-868f-7b323d996ac2
INFO: Analyzed target //common/proto/google:google_lib (25 packages loaded, 186 targets configured).
INFO: Found 1 target...
ERROR: /home/sasha/paypa-stack/common/proto/google/BUILD.bazel:8:17: Compiling protoc outputs for ts_proto_compile plugin on target //common/proto/google:google_lib failed: (Exit 1): bash failed: error executing command /bin/bash -c 'mkdir -p '\''bazel-out/k8-fastbuild/bin/common/proto/google/_rpg_premerge_google_lib'\'' && external/com_google_protobuf_protoc_linux_x86_64/bin/protoc $@' '' ... (remaining 11 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
/usr/bin/env: 'node': No such file or directory
--ts_proto_out: protoc-gen-ts_proto: Plugin failed with status code 127.
Target //common/proto/google:google_lib failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.447s, Critical Path: 0.98s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully

So, it seems node is no longer available to the toolchain, despite it being the same binary?

Ahh okay, I think I see the issue - the file is actually a shell script to run node. Setting the tool to the new form of js_binary should fix it:
directory_path(
    name = "ts-proto_entry_point",
    directory = "//:node_modules/ts-proto/dir",
    path = "protoc-gen-ts_proto",
)

js_binary(
    name = "protoc-gen-ts_proto",
    data = ["//:node_modules/ts-proto"],
    entry_point = ":require_ts_proto.js",
)

proto_plugin(
    ...
    tool = ":protoc-gen-ts_proto",
)

except, this gives:
FATAL: aspect_rules_js[js_binary]: BAZEL_BINDIR must be set in environment to the makevar $(BINDIR) in js_binary build actions (which run in the execroot) so that build actions can change directories to always run out of the root of the Bazel output tree. See https://docs.bazel.build/versions/main/be/make-variables.html#predefined_variables. This is automatically set by 'js_run_binary' (https://github.com/aspect-build/rules_js/blob/main/docs/js_run_binary.md) which is the recommended rule to use for using a js_binary as the tool of a build action. If this is not a build action you can set the BAZEL_BINDIR to '.' instead to supress this error. For more context on this design decision, please read the aspect_rules_js README https://github.com/aspect-build/rules_js/tree/dbb5af0d2a9a2bb50e4cf4a96dbc582b27567155#running-nodejs-programs.
--ts_proto_out: protoc-gen-ts_proto: Plugin failed with status code 1.

Here's what I'm currently trying:
WORKSPACE.bazel:
git_repository(
    name = "rules_proto_grpc",
    commit = "b9e6b2922d8b6177d0747f30b738ea467161fc33",
    remote = "https://github.com/gonzojive/rules_proto_grpc.git",
)

bazel/web/ts_proto_library.bzl:
load(
    "@rules_proto_grpc//:defs.bzl",
    "ProtoPluginInfo",
    "proto_compile_attrs",
    "proto_compile_impl",
)

def _ts_proto_compile_impl(ctx):
    """
    Implementation function for ts_proto_compile.

    Args:
        ctx: The Bazel rule execution context object.

    Returns:
        Providers:
            - ProtoCompileInfo
            - DefaultInfo

    """
    base_env = {
        # Make up for https://github.com/bazelbuild/bazel/issues/15470.
        "BAZEL_BINDIR": ctx.bin_dir.path,
    }
    return proto_compile_impl(ctx, base_env = base_env)

# based on https://github.com/aspect-build/rules_js/issues/397
ts_proto_compile = rule(
    implementation = _ts_proto_compile_impl,
    attrs = dict(
        proto_compile_attrs,
        _plugins = attr.label_list(
            providers = [ProtoPluginInfo],
            default = [
                Label("//bazel/web/targets:ts_proto_compile"),
            ],
            doc = "List of protoc plugins to apply",
        ),
    ),
    toolchains = [
        str(Label("@rules_proto_grpc//protobuf:toolchain_type")),
    ],
)

bazel/web/targets/BUILD.bazel:
load("@npm//:ts-proto/package_json.bzl", _ts_proto_bin_factories = "bin")
load("@rules_proto_grpc//:defs.bzl", "proto_plugin")

_ts_proto_bin_factories.protoc_gen_ts_proto_binary(
    name = "protoc-gen-ts-proto",
)

proto_plugin(
    name = "ts_proto_compile",
    outputs = ["{protopath}.ts"],
    protoc_plugin_name = "ts_proto",
    tool = "//bazel/web/targets:protoc-gen-ts-proto",
    use_built_in_shell_environment = False,
    visibility = ["//visibility:public"],
)

Usage:
load("@rules_proto//proto:defs.bzl", "proto_library")
load("//bazel/web:ts_proto_library.bzl", "ts_proto_compile")

proto_library(
    name = "geompb_proto",
    srcs = ["geom.proto"],
    import_prefix = "blah.xyz",
    visibility = ["//visibility:public"],
    deps = [
        "@go_googleapis//google/type:latlng_proto",
    ],
)

ts_proto_compile(
    name = "geom_ts",
    protos = [
        ":geompb_proto",
    ],
    verbose = 4,
    visibility = ["//visibility:public"],
)

I've been trying to get this to work with stackb/rules_proto, but I can't figure out how to refer to the plugin binary.
I have the following in the WORKSPACE file:
npm_translate_lock(
    name = "npm_ts_proto",
    # we have to manually wire-up the bin, unfortunately
    bins = {
        "ts-proto": {
            "protoc-gen-ts_proto": "./protoc-gen-ts_proto",
        },
    },
    pnpm_lock = "//plugin/stephenh/ts-proto:pnpm-lock.yaml",
    verify_node_modules_ignored = "//:.bazelignore",
)

load("@npm_ts_proto//:repositories.bzl", npm_ts_proto_repositories= "npm_repositories")

npm_ts_proto_repositories()

Using the old rules_js v5 (note that the main repo is still on v4), the plugin is defined as so:
proto_plugin(
    name = "protoc-gen-ts-proto",
    data = [
        "@nodejs_host//:npm",
        "@npm_ts_proto//:node_modules",
    ],
    tool = "@npm_ts_proto//ts-proto/bin:protoc-gen-ts_proto",
    visibility = ["//visibility:public"],
)

I haven't been able to figure out how to refer to the binary when using the new rules_js. Trying the same trick as worked for the other proto ruleset didn't work: cannot load '@npm_ts_proto//:ts-proto/package_json.bzl': no such file

I realised I was forgetting how labels work and it should be ":node_modules/.bin/protoc-gen-ts_proto" once you link the packages. However, while that's a good label, I'm still failing to compile the protos: Compiling protoc outputs for ["routeguide.proto"] failed: missing input file '//plugin/stephenh/ts-proto:node_modules/.bin/protoc-gen-ts_proto'

Maybe you need something like the following?
load("@npm//:ts-proto/package_json.bzl", _ts_proto_bin_factories = "bin")

_ts_proto_bin_factories.protoc_gen_ts_proto_binary(
    name = "protoc-gen-ts-proto",
)

# label :protoc-gen-ts-proto is now the "tool" binary you can execute

That did end up being the trick--I'd messed up setting up the node modules, clearing out everything and starting over got it working. Now I'm stuck on the proto_ts_library macro. (I'm taking that question to the Slack, though, as it's clearly beyond this issue. I'll return with a link to a PR or something if I get this working.)

FYI it seems likely that we have some funding lined up to create a proper ts_proto_library rule this quarter.

Ooh, that is good news. The attraction of stackb/rules_proto for me are the gazelle rules, but it's proving to be an uphill battle. But then I'm left figuring out how to publish less granular packages, so I may end up globbing for protos anyway.

``·=

Maybe you need something like the following?
load("@npm//:ts-proto/package_json.bzl", _ts_proto_bin_factories = "bin")

_ts_proto_bin_factories.protoc_gen_ts_proto_binary(
    name = "protoc-gen-ts-proto",
)

# label :protoc-gen-ts-proto is now the "tool" binary you can execute

seems this will cause the follow issue,  maybe this only works in one
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
FATAL: aspect_rules_js[js_binary]: BAZEL_BINDIR must be set in environment to the makevar $(BINDIR) in js_binary build actions (which run in the execroot) so that build actions can change directories to always run out of the root of the Bazel output tree. See https://docs.bazel.build/versions/main/be/make-variables.html#predefined_variables. This is automatically set by 'js_run_binary' (https://github.com/aspect-build/rules_js/blob/main/docs/js_run_binary.md) which is the recommended rule to use for using a js_binary as the tool of a build action. If this is not a build action you can set the BAZEL_BINDIR to '.' instead to supress this error. For more context on this design decision, please read the aspect_rules_js README https://github.com/aspect-build/rules_js/tree/dbb5af0d2a9a2bb50e4cf4a96dbc582b27567155#running-nodejs-programs.
--ts-proto-plugin_out: protoc-gen-ts-proto-plugin: Plugin failed with status code 1.

my full code is here:
in bazel/build.bazel
load("@npm//:ts-proto/package_json.bzl", "bin")

bin.protoc_gen_ts_proto_binary(
    name = "ts_proto_bin",
    visibility = ["//visibility:public"],
)

proto_plugin(
    name = "ts-proto-plugin",
    outputs = ["{protopath}.ts"],
    tool = ":ts_proto_bin",
    visibility = ["//visibility:public"],
)

in bazel/ts-rule.bzl
load("@rules_proto//proto:defs.bzl", "ProtoInfo")
load(
    "@rules_proto_grpc//:defs.bzl",
    "ProtoPluginInfo",
    "proto_compile_attrs",
    "proto_compile_impl",
)
load(
    "@rules_proto_grpc//internal:compile.bzl",
    "proto_compile",
)

BASE_OPTIONS = [
    "forceLong=bigint",
    "exportCommonSymbols=false",
    "esModuleInterop=true",
    "outputServices=generic-definitions",
    "useExactTypes=false",
]

GRPC_OPTIONS = [
    "outputServices=nice-grpc",
]

ESM_OPTIONS = ["importSuffix=.js"]

def ts_proto_compile_impl(ctx):
    options = [] + BASE_OPTIONS
    if ctx.attr.esm:
        options += ESM_OPTIONS
    if ctx.attr.grpc:
        options += GRPC_OPTIONS
    else:
        options += ["outputServices=generic-definitions"]
    if ctx.attr.remove_deprecated:
        options += ["removeDeprecated=true"]
    options += ctx.attr.options

    extra_protoc_args = getattr(ctx.attr, "extra_protoc_args", [])
    extra_protoc_files = ctx.files.extra_protoc_files

    pluginOptions = {
        "*": options,
    }

    #    print("pluginOptions: " + str(pluginOptions))
    return proto_compile(ctx, pluginOptions, extra_protoc_args, extra_protoc_files)

ts_proto = rule(
    implementation = ts_proto_compile_impl,
    attrs = dict(
        proto_compile_attrs,
        esm = attr.bool(
            default = False,
            doc = "Whether to generate ESM modules",
        ),
        grpc = attr.bool(
            default = False,
            doc = "Whether to generate gRPC services stub",
        ),
        options = attr.string_list(
            default = [],
            doc = "Additional options to pass to protoc",
        ),
        remove_deprecated = attr.bool(
            default = False,
            doc = "Whether to remove deprecated fields",
        ),
        _plugins = attr.label_list(
            providers = [ProtoPluginInfo],
            default = [
                Label("//bazel:ts-proto-plugin"),
            ],
            doc = "List of protoc plugins to apply",
        ),
    ),
    toolchains = [str(Label("@rules_proto_grpc//protobuf:toolchain_type"))],
)

see

I've been trying to get this to work with stackb/rules_proto, but I can't figure out how to refer to the plugin binary.
I have the following in the WORKSPACE file:
npm_translate_lock(
    name = "npm_ts_proto",
    # we have to manually wire-up the bin, unfortunately
    bins = {
        "ts-proto": {
            "protoc-gen-ts_proto": "./protoc-gen-ts_proto",
        },
    },
    pnpm_lock = "//plugin/stephenh/ts-proto:pnpm-lock.yaml",
    verify_node_modules_ignored = "//:.bazelignore",
)

load("@npm_ts_proto//:repositories.bzl", npm_ts_proto_repositories= "npm_repositories")

npm_ts_proto_repositories()

Using the old rules_js v5 (note that the main repo is still on v4), the plugin is defined as so:
proto_plugin(
    name = "protoc-gen-ts-proto",
    data = [
        "@nodejs_host//:npm",
        "@npm_ts_proto//:node_modules",
    ],
    tool = "@npm_ts_proto//ts-proto/bin:protoc-gen-ts_proto",
    visibility = ["//visibility:public"],
)

I haven't been able to figure out how to refer to the binary when using the new rules_js. Trying the same trick as worked for the other proto ruleset didn't work: cannot load '@npm_ts_proto//:ts-proto/package_json.bzl': no such file (Note: This is fundamentally the same question as being asked in the discussion of #630.)

seems we also need in proto_plugin rule for this
    env = {
        "BAZEL_BINDIR": "{bindir}",
    },

I think we want to show an example with protobuf-es: https://github.com/bufbuild/protobuf-es

Okay finally getting some progress... https://github.com/aspect-build/rules_ts/issues/415

ts_proto_library is introduced in rules_ts v2.0.0-beta1

Marking this closed since rules_ts shows what to do.


fix: wds fine tunes

Description

Icon tokens now respond to changes to density and sizing in the theme. Added the appropriate settings to the config as well
Fixed the documentation and rendering of some stories in storybook.
Fixed icon rendering

PR fixes following issue(s)
Fixes #30955
Media
https://github.com/appsmithorg/appsmith/assets/11555074/e0cd818f-9716-4887-9f5e-aaa3c3ab9e30
Type of change

Bug fix (non-breaking change which fixes an issue)
Chore (housekeeping or task changes that don't impact user perception)

Testing

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Also list any relevant details for your test configuration.
Delete anything that is not relevant

[x] Manual
[ ] JUnit
[x] Jest
[x] Cypress

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

Summary by CodeRabbit

New Features

Introduced custom React hooks for dynamic icon sizing (useIconSizing) and stroke width adjustments (useIconDensity).
Revised Dimension component functionality with new token calculation and user adjustments.

Refactor

Updated various type imports to improve consistency across theming hooks.
Simplified logic in detached widget hooks and removed unnecessary styling logic in resizer components.

Style

Adjusted shadow colors and properties in CSS modules.
Updated icon and button styling for better size and stroke width management.

Documentation

Removed sections focusing on deprecated hooks and components in storybook stories.

Chores

Changed favicon path in Storybook manager.

/build-deploy-preview skip-tests=true

/ok-to-test<EMAIL_ADDRESS>


Adding CinéCréatis, Lyon

@adraug I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host lyn.ecolescreatives not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for understanding!

Sorry, but in your error message, the ending .com is not present. I don't know if you made a mistake, but the file that @adraug is located in the com folder.


Merge recent changes from upstream

No, this really shouldn't go into the mathoid-0-2-8 branch. Instead, mathoid's deps should be updated to use this new branch, test it, and if all goes well, then we merge it into master and create an annotated tag.

@d00rman: All right... I intended to make a pull request against master


Corrected multiplied chat text widths

Ensures that text items displayed on the same line of the chatbox use the correct width value to determine where to start the display of text.
An example of the fault is shown in this image:

The text starts at the same place regardless of the multiplication of the text size, because it uses the same width value to determine its starting position regardless. The width value used is only correct when no text scaling is applied. This PR makes sure that the starting position of subsequent texts bases itself off of the actual width of the previous text, rather than the assumed width. As such, with this applied, chat text follows directly after the timestamp, with no overlap or gap.

I've amended my change: rather than getting the final width and simply changing the x-offset based on that, I have updated the WrappedText method to take multiplication into account when storing width and height values.
This means that scaling doesn't have to be taken into account by each system which uses the stored width and height values, but rather it is automatically accounted for.

The latest re-push was just to fix a typo in the commit title.


Improve flow in menucontroler

Currently, each time the page is loaded, the system will connect to the DB and try to insert each DayRecipe, this is unneeded overhead and could be done in a smarter way

Closing with update