roc dev with hello world snippet from tutorial hangs indefinitely

Using nix shell github:roc-lang/roc on x86-64 linux
Using this code snippet from the tutorial:
app "hello"
    packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.5.0/Cufzl36_SnJ4QbOoEmiJ5dIpUxBvdB3NEySvuH82Wio.tar.br" }
    imports [pf.Stdout]
    provides [main] to pf

main =
    Stdout.line "I'm a Roc application!"

When I do roc dev, it gets stuck at
Downloading https://github.com/roc-lang/basic-cli/releases/download/0.5.0/Cufzl36_SnJ4QbOoEmiJ5dIpUxBvdB3NEySvuH82Wio.tar.br
    into /home/james/.cache/roc/packages

I don't think it's just a slow internet connection, since I can download that file from my browser fairly quickly.
Let me know any information I should provide to help debug.

I'm also affected by this. I'm using the same hello world snippet. roc dev hangs and roc run segfaults.
~/roc 15:43:15
WSL $ ./roc_nightly-linux_x86_64-2023-10-04-b00f25b/roc version
roc nightly pre-release, built from commit b00f25b on Mi 04 Okt 2023 09:08:06 UTC

~/roc 15:44:32
WSL $ ./roc_nightly-linux_x86_64-2023-10-04-b00f25b/roc dev
^C

~/roc took 23s 15:45:02
WSL $ ./roc_nightly-linux_x86_64-2023-10-04-b00f25b/roc run
Segmentation fault

The snippet can be built successfully, but the binary segfaults. And this seems to be an issue in the loader, according to the GBD warning.
~/roc took 11s 15:50:15
WSL $ ./roc_nightly-linux_x86_64-2023-10-04-b00f25b/roc build
0 errors and 0 warnings found in 253 ms while successfully building:

    hello

~/roc 15:50:19
WSL $ gdb -q hello
Reading symbols from hello...
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/user/roc/hello.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) r
Starting program: /home/user/roc/hello
During startup program terminated with signal SIGSEGV, Segmentation fault.

LD_DEBUG doesn't give any hits unfortunately.
~/roc 15:57:10
WSL $ LD_DEBUG=all ./hello
Segmentation fault

Didn't debug any further.

I cannot reproduce the hanging or the segfault on Ubuntu 22.04.
Can you share the used OS and upload the hello executable here @IsaacDynamo?

Can you also share your exact OS @sullyj3?

WSL $ uname -a
Linux PC 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
WSL $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal

Retested in WSL Ubuntu 22.04, and that has similar behavior: dev hangs, run segfaults.
user@PC:~$ uname -a
Linux PC 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
user@PC:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.2 LTS
Release:        22.04
Codename:       jammy

Running on an other machine with a newer kernel does work.  So it seem to be related to the kernel. 🤨
WSL $ uname -a
Linux LT <IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
WSL $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

Thanks, interesting...
Can you upload the segfaulting executable here?

The binaries from 4.19+20.04 and 4.19+22.04 run fine when copied to 5.10+22.04.
I would rather not upload them, because they will contain private data.
But let me known if you want me to run some other tests.

Ok, no problem, I'll try to set something up with on older kernel.

I was able to reproduce the hanging and the segfault with the 4.19 kernel on Ubuntu 20.04. I'm investigating now...

Using the legacy linker (./roc build --linker legacy main.roc) does work and based on the strange outputs I'm getting from ldd and strace I think the segfault is caused by a bug in the surgical linking process.

I've looked at the manual for execve and it should not even be capable of returning EEXIST here, so I assume this was a linux bug that has been fixed.
strace -f ./rocLovesZigSurgical
execve("./rocLovesZigSurgical", ["./rocLovesZigSurgical"], 0x7ffd1e583478 /* 33 vars */) = -1 EEXIST (File exists)
+++ killed by SIGSEGV +++
Segmentation fault (core dumped)

I'll still check out the hanging issue.

Have you seen the dmesg message?
WSL $ ./hello
Segmentation fault
WSL $ dmesg | tail -1
[ 5788.699342] 20029 (hello): Uhuuh, elf segment at 00007fb104ebf000 requested but the memory is mapped already

With that error message I found some posts that might be related:

https://stackoverflow.com/questions/51656713/cannot-load-custom-elf-executable-in-gdb
https://github.com/torvalds/linux/commit/a4ff8e8620d3f4f50ac4b41e8067b7d395056843

Oh good finds, I didn't think to check dmesg. I'll take a look

Can you also share your exact OS @sullyj3?

Sure:
⮞ uname -a
Linux dorian 6.5.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 23 Sep 2023 22:55:13 +0000 x86_64 GNU/Linux

⮞ lsb_release -a
LSB Version:	n/a
Distributor ID:	Arch
Description:	Arch Linux
Release:	rolling
Codename:	n/a

Hang on, nevermind, it seems to be working for me now.

@bhansconnect do you know what's going on here?
To summarize the issue;

(all?) roc executables (locally built) are segfaulting on operating systems with linux kernel 4.19
the same executable does not segfault on newer linux kernels
linking with legacy linker "fixes" the issue
This dmesg message appears to be the core of the problem:

$ dmesg | tail -1
4159 (rocLovesZigSurg): Uhuuh, elf segment at 000055e4f24ee000 requested but the memory is mapped already

(similar issue on stackoverflow)

These issues raised by eu-elflint may be relevant:

$ eu-elflint examples/platform-switching/rocLovesZigSurgical
GNU_RELRO segment not contained in a loaded segment
section [ 3] '.dynsym': symbol 3: st_value out of bounds
section [ 3] '.dynsym': symbol 200: st_value out of bounds
section [ 3] '.dynsym': symbol 307: st_value out of bounds
section [ 3] '.dynsym': symbol 468: st_value out of bounds
section [ 3] '.dynsym': symbol 644: st_value out of bounds
section [ 3] '.dynsym': symbol 773: st_value out of bounds
section [ 5] '.gnu.version_r': entry 2 has invalid offset to next entry
section [11] '.rodata': merge flag set but entry size is zero
section [17] '.tbss': thread-local data sections address not zero
section [34] '.symtab': _DYNAMIC symbol size 0 does not match dynamic segment size 432
section [34] '.symtab': symbol 2034: st_value out of bounds
loadable segment [12] is writable but contains no writable sections
section [ 4] '.gnu.version': symbol 1: invalid version index 2
section [ 4] '.gnu.version': symbol 4: invalid version index 2
section [ 4] '.gnu.version': symbol 5: invalid version index 3
section [ 4] '.gnu.version': symbol 6: invalid version index 2
section [ 4] '.gnu.version': symbol 7: invalid version index 2
section [ 4] '.gnu.version': symbol 8: invalid version index 2
section [ 4] '.gnu.version': symbol 9: invalid version index 2
section [ 4] '.gnu.version': symbol 10: invalid version index 2
section [ 4] '.gnu.version': symbol 11: invalid version index 2
section [ 4] '.gnu.version': symbol 12: invalid version index 4
section [ 4] '.gnu.version': symbol 13: invalid version index 5
section [ 4] '.gnu.version': symbol 14: invalid version index 2
section [ 4] '.gnu.version': symbol 16: invalid version index 7
section [ 4] '.gnu.version': symbol 17: invalid version index 7
section [ 4] '.gnu.version': symbol 18: invalid version index 2
section [ 4] '.gnu.version': symbol 23: invalid version index 2
section [ 4] '.gnu.version': symbol 24: invalid version index 2
section [ 4] '.gnu.version': symbol 26: invalid version index 2
section [ 4] '.gnu.version': symbol 27: invalid version index 2
section [ 4] '.gnu.version': symbol 28: invalid version index 2
section [ 4] '.gnu.version': symbol 29: invalid version index 3
section [ 4] '.gnu.version': symbol 30: invalid version index 2
section [ 4] '.gnu.version': symbol 32: invalid version index 2
symbol 3 referenced in old hash table in [ 7] '.hash' but not in new hash table in [ 6] '.gnu.hash'
$ eu-elflint examples/platform-switching/rocLovesZigLegacy
section [18] '.tbss': thread-local data sections address not zero
section [33] '.symtab': _DYNAMIC symbol size 0 does not match dynamic segment size 544
section [33] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not match .got.plt section size 264
section [33] '.symtab': symbol 2149: st_value out of bounds

rocLovesZigLegacyvsSurgical.tar.gz

I'm also seeing this issue under Ubuntu in WSL2 on Windows 10 Pro version 21H2.
```roc dev`` hangs and doesn't do anything.
I follow setup instructions here and used the code from the tutorial.
Ubuntu details:
$ uname -a
Linux ASHDESKTOP 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal

I'm running Roc version:
roc nightly pre-release, built from commit 49862da on Sa 16 Mär 2024 09:01:35 UTC

With basic-cli version:
https://github.com/roc-lang/basic-cli/releases/download/0.8.1/x8URkvfyi9I0QhmVG98roKBUs_AZRkLFwFJVJ3942YA.tar.br

I expect updating the linux kernel could be an easy workaround.


Trim spaces in search input

When you enter anything followed by a space in to the search it errors.

Fixed in d548a08ab8650669291f2d66d6e8311127e421b9


travis: Build docs

This commit adds functionality to Travis to build our docs, to make
sure to catch docs build failures.

I didn't test that it fails but I checked that Travis is compiling the docs as expected, and the Make command will exit with 1 when it fails.


Set percentages (Question)

Is there a way to make sure an enchant like headless works every time? Make it to where a head will drop if max level enchant is used rather than a lower level version of the same enchant. So far I couldn't find a way but may simply be an oversight

Chance control is based on the Enchantments.yml file. These were added in v1.8 Dev Build v8 so you have to be on at least that version to use this.
https://github.com/badbones69/Crazy-Enchantments/blob/8d585ca3711636ebdaa52f8c7e7d4cc770e20a54/plugin/src/main/resources/Enchantments.yml#L1189-L1191


add genai-microservices-connectors

Co-authored-by: KfreeZ
Co-authored-by: zhlsunshine
Description
add genai-microservice-connectors(GMC) which include a CRD and samples
Issues
n/a.
Type of change
List the type of change like below. Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would break existing design and interface)

Dependencies
golang, client-go
Tests
unit test

since the code is all under GenAIInfra, shall we simplify the folder to service-connector?

Thanks for the suggestion, to align with GMC, how about call it 'microservices-connector' ?

since the code is all under GenAIInfra, shall we simplify the folder to service-connector?

Agree - drop genAI, let us keep it as microservice-connector.

Hi @mkbhanda, @hshen14 and @chensuyue, please move to PR#29 for continuing the PR reviewing, thanks! ^_^

close this PR as   https://github.com/opea-project/GenAIInfra/pull/29


: 1. arrow not change on open/close; 2. when isOpen='false', it's still open.

Describe the bug

The arrow on SidebarDropdownWrapper doesn't change when open or close the drop-down list:

When set isOpen="false" on <SidebarDropdownWrapper>, it will still open; removing the isOpen property then it will close.

Reproduction

open / close a <SidebarDropdownWrapper>.
set isOpen="false" on <SidebarDropdownWrapper>

Flowbite version and System Info
System:
    OS: Linux 5.14 Linux Mint 20.1 (Ulyssa)
    CPU: (8) x64 Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
    Memory: 10.27 GB / 15.55 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm
  Browsers:
    Chrome: 104.0.5112.79
  npmPackages:
    @sveltejs/kit: next => 1.0.0-next.484
    flowbite-svelte: ^0.26.25 => 0.26.25
    svelte: ^3.50.1 => 3.50.1
    vite: ^3.1.2 => 3.1.2

Can you try isOpen={false}?

is fixed.
isOpen={false} works, but a string can be parsed as bool via JSON.parse("false"), frameworks may choose to support this.

Please read the examples in Svelte doc.
It is a convention to use {false}.


implicit 'any' return type in type definitions

tsc emits the following error when compiling a program that imports ssh-config:
node_modules/ssh-config/types/index.d.ts:34:3 - error TS7010: 'find', which lacks return-type annotation, implicitly has an 'any' return type.

34   find(predicate: (value: any, index: number, obj: any[]) => any);
     ~~~~

Found 1 error.

Thanks for reporting, fixed and released with v4.1.4


Random crashes + flickering even I updated to latest Hyprland version

Hyprland Version
Hyprland, built from branch main at commit 395ab3ba370f5e12fcba594232c338c16deef0ed dirty (xdg: use better min/max size checks for floating resizes). Tag: v0.33.1-43-g395ab3ba
Bug or Regression?
Bug
Description
Hmm, this bug happened about 3-4 months ago and it annoyed me a lot even when I updated Hyprland or Arch Linux
As you can see in the video, the screen suddenly flickers randomly for about 8-9 seconds and it automatically restarts after that
How to reproduce
I don't really know how to reproduce this because it almost random. But I noticed it crashes more frequently when I run some apps like VSCode, VMware
Crash reports, logs, images, videos
This is the recent crash report that I found in ~/.cache/hyprland. However, this file was created on 12/9/2023 while I still have problem on 12/21/2023:
hyprlandCrashReport980.txt
The video:
https://github.com/hyprwm/Hyprland/assets/96990857/76f852f0-1d9b-4c93-b7af-96d01e19a8b4

something is terribly wrong with your system

@vaxerski Is there any way to fix that?

no clue, call an exorcist or use a more user-friendly distro that maybe comes with hl preinstalled, like arco / garuda / etc

I'll reinstall to check if the bug still exist or not. Thanks for your response

Hi @vaxerski, after following "Fixing random flickering, (nuclear method)", I fixed this bug, thank you!


platform restrictions not documented

I couldn't see it noted anywhere that singularity is (currently?) x86_64-specific, as I realized when trying to build a range of Fedora packages.
Also it might be useful to have information on the versions of Linux that will/won't support it for common distributions.  Specifically RHEL5's isn't good enough -- we still have such a cluster... -- but I don't know about the oldest supported Debian and SuSE.

Hi Dave,
Very good points. I've been testing and developing on x86_64 only but I would assume that x86 should also work but you are right about other arches. I will document that and put the exclusive arches in the specfile.
Lastly, I believe it should work on most Linux distributions. I have a work around a in place that should make it work on older distributions (like RHEL5) but my testing ability here is somewhat limited, specifically for non RH distributions. But I do know that others have tested it on Mint, Ubuntu, Lubuntu, Debian proper, and even Slackware.
What have you found as far as build / runtime compatibility?
Thanks!
Sent from my iPhone

"Gregory M. Kurtzer"<EMAIL_ADDRESS>writes:

Hi Dave,
Very good points. I've been testing and developing on x86_64 only but
I would assume that x86 should also work

It fails on register names.  There's a build log from an older packaging:
https://copr-be.cloud.fedoraproject.org/results/loveshack/livhpc/epel-6-i386/00175787-singularity/build.log.gz

but you are right about other
arches. I will document that and put the exclusive arches in the
specfile.

For what it's worth, I have a modified spec that should pass review for
Fedora, which I could submit for review.

Lastly, I believe it should work on most Linux distributions. I have a
work around a in place that should make it work on older
distributions (like RHEL5) but my testing ability here is somewhat
limited, specifically for non RH distributions.

I can test on x86_64 RH5, if it helps, though it's not terribly
important.

But I do know that
others have tested it on Mint, Ubuntu, Lubuntu, Debian proper, and
even Slackware.
What have you found as far as build / runtime compatibility?

Someone with a brain would have suggested a configure change like this
to test the architecture and the failure he found on RH5...

Sent from my iPhone

On Apr 16, 2016, at 10:25 AM, Dave Love<EMAIL_ADDRESS>It fails on register names. There's a build log from an older packaging:
https://copr-be.cloud.fedoraproject.org/results/loveshack/livhpc/epel-6-i386/00175787-singularity/build.log.gz

Ohhhh, I know exactly what that is! Sheesh I coded up the Singularity ftrace a few months ago and I forgot that I did code it explicitly for x86_64. Ptrace is not the easiest to code against due to the sparse documentation especially for multiarch support.... But I'll get a fix in there for Singularity 1.1!

but you are right about other
arches. I will document that and put the exclusive arches in the
specfile.

For what it's worth, I have a modified spec that should pass review for
Fedora, which I could submit for review.

Yes please!

Lastly, I believe it should work on most Linux distributions. I have a
work around a in place that should make it work on older
distributions (like RHEL5) but my testing ability here is somewhat
limited, specifically for non RH distributions.

I can test on x86_64 RH5, if it helps, though it's not terribly
important.

I believe Tru (from the Centos team) ran it on x64 Centos 5 successfully. That was why I was confused in that it should work. So quickly I've forgotten about 32 bit. Lol

But I do know that
others have tested it on Mint, Ubuntu, Lubuntu, Debian proper, and
even Slackware.
What have you found as far as build / runtime compatibility?

Someone with a brain would have suggested a configure change like this
to test the architecture and the failure he found on RH5...

Haha, someone with a brain wouldn't have coded just for 64bit. Oops!!
I agree that a configure test and some defines would be best for fixing this. I'll get on that shortly (right after I build up a 32 bit VM lol).
Thanks again!

The rubbish tracker dropped the patch from the mail, grr.
index 58ea383..8c422ec 100644
--- a/configure.ac
+++ b/configure.ac
@@ -9,6 +9,12 @@ if test -z "$prefix" -o "$prefix" = "NONE" ; then
 fi
 AC_SUBST(PREFIX, $prefix)

+AC_CANONICAL_TARGET
+case $target_cpu in
+  x86_64) : ;;
+  *) AC_MSG_ERROR([Architecture $target_cpu not supported]) ;;
+esac
+
 AC_PROG_INSTALL
 AM_INIT_AUTOMAKE
 AC_PROG_LIBTOOL
@@ -96,6 +102,9 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#define _GNU_SOURCE
                       ]
                   )

+AC_CHECK_DECLS([MS_PRIVATE,MS_REC], [],
+               [AC_MSG_ERROR([Required mount(2) flags not available])],
+               [[#include <sys/mount.h>]])

 AC_SUBST(NAMESPACE_DEFINES)

(I'm surprised LD_PRELOAD isn't robust enough ; perhaps it's worth recording why it needs ptrace?)

This should work fine on 32 bit once I get the correct registers defined for ftrace. Can you do me a favor, I don't have a 32 bit system handy. Can you tell me what the value of $(target_cpu) and/or $(build_cpu) is in the produced Makefile? Hopefully it is something simple like i386 instead of i?x86! LOL
Thanks!

I didn't follow your comment about LD_PRELOAD... Are you suggesting to preload a library to monitor for calls to open() instead of using ptrace?
Hrmm... If so, that is an interesting idea. It would solve a few problems as I have them now with regards to applications forking and not knowing how to follow them easily with ptrace.

You wrote:

This should work fine on 32 bit once I get the correct registers
defined for ftrace.

Sure, and presumably ia32 would normally only be relevant to run old
stuff without 32-bit libraries installed.

Can you do me a favor, I don't have a 32 bit
system handy. Can you tell me what the value of $(target_cpu) and/or
$(build_cpu) is in the produced Makefile? Hopefully it is something
simple like i386 instead of i?x86! LOL

The glob-style match is "i?86":
$ linux32 ./config.guess
i686-pc-linux-gnu

You wrote:

I didn't follow your comment about LD_PRELOAD... Are you suggesting to
preload a library to monitor for calls to open() instead of using
ptrace?

Yes, as normal for i/o profiling or faking userland filesystems.  I
assumed ptrace was preferable somehow, like finessing scripts clobbering
LD_PRELOAD, which I've never got round to trying to subvert.

Hrmm... If so, that is an interesting idea. It would solve a few
problems as I have them now with regards to applications forking and
not knowing how to follow them easily with ptrace.

Is whatever "strace -f -e open" does not reliable?

Sent from my iPhone

On Apr 18, 2016, at 6:12 AM, Dave Love<EMAIL_ADDRESS>wrote:
You wrote:

I didn't follow your comment about LD_PRELOAD... Are you suggesting to
preload a library to monitor for calls to open() instead of using
ptrace?

Yes, as normal for i/o profiling or faking userland filesystems. I
assumed ptrace was preferable somehow, like finessing scripts clobbering
LD_PRELOAD, which I've never got round to trying to subvert.

Have you come across many run scripts that clobber LD_PRELOAD in practice?

Hrmm... If so, that is an interesting idea. It would solve a few
problems as I have them now with regards to applications forking and
not knowing how to follow them easily with ptrace.

Is whatever "strace -f -e open" does not reliable?

The first implementation I wrote used strace from the host system but it was almost impossible to parse from system to system. I had it working on a couple of different OSes and then would find a different version of Ubuntu or slack that my parser would not support.
This was actually why I ended up using ptrace instead of preloading a library as I was emulating strace.
The documentation is lacking for ptrace so the idea of using a straight forward LD_PRELOAD is an interesting one.  Also considering the limitations of what I'm doing now and balancing the pros and cons against preloading.
Thoughts?

Sent from my iPhone

On Apr 18, 2016, at 6:11 AM, Dave Love<EMAIL_ADDRESS>
Can you do me a favor, I don't have a 32 bit
system handy. Can you tell me what the value of $(target_cpu) and/or
$(build_cpu) is in the produced Makefile? Hopefully it is something
simple like i386 instead of i?x86! LOL

The glob-style match is "i?86":
$ linux32 ./config.guess
i686-pc-linux-gnu

Ahh ok. I'll glob it in the configure script and export a define down to the C code then.
Thanks!

So, I wrote a quick library that masks the open() and dlopen() system calls and prints the associated file names. It is working generally as expected except your surmise about programs interfering with the environment and disabling LD_PRELOAD was accurate and leading to reliability issues.
Ftrace should be fixed now to work on 32 bit and as long as we get it working for forks, it should be more reliable then the preload method. If you can test this from master, and confirm that 32 bit is working and close the ticket, that would be appreciated.
Thanks for the great idea, and pointing out the limitation on 32bit which I overlooked!
Greg

You wrote:

Ahh ok. I'll glob it in the configure script and export a define down
to the C code then.

Just use
#if x86_64
...
#elif i386
...
i386 is pre-defined for -m32 by any vaguely-recent gcc.

You wrote:

Is whatever "strace -f -e open" does not reliable?

The first implementation I wrote used strace from the host system but
it was almost impossible to parse from system to system. I had it
working on a couple of different OSes and then would find a different
version of Ubuntu or slack that my parser would not support.

I meant specifically the fork-following.  I'm surprised at the
variation, though.  On everything I have from RHEL5 through to Debian
testing/Fedora rawhide VMs, the only variation I see is whether or not
there's a prefix after a fork.  But I haven't slack-ed for a very long
time.

This was actually why I ended up using ptrace instead of preloading a
library as I was emulating strace.

I assumed there was a good reason.  You could always bundle a specific
(cut down?) strace if necessary, preferably making it easy to unbundle
in distribution packages.

The documentation is lacking for ptrace so the idea of using a
straight forward LD_PRELOAD is an interesting one.

I can't really say, as people here basically don't do things like
profiling.  However, clobbering LD_PRELOAD at least wouldn't be relevant
for tracing perl/python module loading, and if specgen doesn't work
properly, I guess it's not the end of the world.  It seems relatively
unlikely a script would trash the variable unless it was set up for a
filesystem like cruise or pvfs, in which case it won't be portable
anyway.  "Just don't do that"?

Also considering the limitations of what I'm doing now and
balancing the pros and cons against preloading.
Thoughts?

On Mon, Apr 18, 2016 at 11:00 AM, Dave Love<EMAIL_ADDRESS>wrote:

You wrote:

Ahh ok. I'll glob it in the configure script and export a define down
to the C code then.

Just use
#if x86_64
...
#elif i386
...
i386 is pre-defined for -m32 by any vaguely-recent gcc.
Ahhh, that would make it light years easier! But considering I just coded
it up in configure.ac and tossing those defines into ftrace.c, I wonder if
there is any advantage using the predefines?

(BTW, it seems that Github striped out the #if's)
--
Gregory M. Kurtzer
Technical Lead and HPC Systems Architect
High Performance Computing Services (HPCS)
University of California
Lawrence Berkeley National Laboratory
One Cyclotron Road, Berkeley, CA 94720

On Mon, Apr 18, 2016 at 11:02 AM, Dave Love<EMAIL_ADDRESS>wrote:

You wrote:

Is whatever "strace -f -e open" does not reliable?

The first implementation I wrote used strace from the host system but
it was almost impossible to parse from system to system. I had it
working on a couple of different OSes and then would find a different
version of Ubuntu or slack that my parser would not support.

I meant specifically the fork-following. I'm surprised at the
variation, though. On everything I have from RHEL5 through to Debian
testing/Fedora rawhide VMs, the only variation I see is whether or not
there's a prefix after a fork. But I haven't slack-ed for a very long
time.

I don't recall exactly what the differences were, but I ended up just
deciding to code exactly what I needed with ptrace. So far (with the
exception of my 32 bit blunder), it has worked very reliably and I have a
big TODO on figuring out how to track forks.

This was actually why I ended up using ptrace instead of preloading a
library as I was emulating strace.

I assumed there was a good reason. You could always bundle a specific
(cut down?) strace if necessary, preferably making it easy to unbundle
in distribution packages.

The documentation is lacking for ptrace so the idea of using a
straight forward LD_PRELOAD is an interesting one.

I can't really say, as people here basically don't do things like
profiling. However, clobbering LD_PRELOAD at least wouldn't be relevant
for tracing perl/python module loading, and if specgen doesn't work
properly, I guess it's not the end of the world. It seems relatively
unlikely a script would trash the variable unless it was set up for a
filesystem like cruise or pvfs, in which case it won't be portable
anyway. "Just don't do that"?

In just my 30 minutes of testing this, I found that there were several
use-cases that completely just didn't work. Also, it wouldn't catch
libraries that are dlopen'ed consistently. I'm not sure, and perhaps if I
spent more time with it I'll figure it out but... Considering the
environment is so easy to manipulate by a script or program I'm tempted not
to want to rely on LD_PRELOAD especially when ftrace seems to work so
reliably.
Again, great ideas! Thank you!
--
Gregory M. Kurtzer
Technical Lead and HPC Systems Architect
High Performance Computing Services (HPCS)
University of California
Lawrence Berkeley National Laboratory
One Cyclotron Road, Berkeley, CA 94720

You wrote:

I don't recall exactly what the differences were, but I ended up just
deciding to code exactly what I needed with ptrace. So far (with the
exception of my 32 bit blunder), it has worked very reliably and I have a
big TODO on figuring out how to track forks.

Apart from strace, fakeroot-ng is another program I know does that and
may be a simpler example, as well as for architecture support.

In just my 30 minutes of testing this, I found that there were several
use-cases that completely just didn't work.

I'd be interested to know which, as they'll break various things, but I
guess this isn't the place to discuss it...  I'd have expected not
following forks to be more of a problem.

Also, it wouldn't catch
libraries that are dlopen'ed consistently. I'm not sure, and perhaps if I
spent more time with it I'll figure it out but... Considering the
environment is so easy to manipulate by a script or program I'm tempted not
to want to rely on LD_PRELOAD especially when ftrace seems to work so
reliably.

Singularity ftrace now follows clones, forks, and threads. WAHOOOOOO!
The changes are not horribly bad, but without proper documentation for ptrace plus it being a somewhat moving target made it frustrating. But... it seems to be working properly now. Feel free to test on both 32 and 64 bit.
Closing ticket, but if you find any issues please don't hesitate to reopen.
Thanks!


Removed false information about current version

It was saying angular/cli is currently at version 1.0

Thanks for approving changes, who is now responsible of merging it to master?


Allow case insensitive comparison of paths for determining PSModulePath

PR Summary
When comparing paths on Windows for determining the PSModulePath, the comparison should be case insensitive.
PR Context

PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[ ] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[ ] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[ ] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[ ] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

@PoshChan please retry macos

@adityapatwardhan, successfully started retry of PowerShell-CI-macOS

@PoshChan Please remind me in one hour

@TravisEz13, I do not understand: Please remind me in one hour

Commands available in this repo for you:

retry <target> this will attempt to retry only the failed jobs for the target pipeline, restart can be used in place of retry

rebuild <target> this will perform a complete rebuild of the target pipeline, rerun can be used in place of rebuild Supported values for <target> which can be a comma separated list are: static,windows,macos,linux,all

get failures this will attempt to get the latest failures for all of the target pipelines

remind me in <value> <units> this will create a reminder that will be posted after the specified duration <value> is a number, and <units> can be minutes, hours, or days (singular or plural)


Allow to use npm instead of yarn

Hi guys, is there a way to use npm instead of yarn with this gem? I can't find any info about that in the README.

There is not at this time. But probably would be nice to at least catch if yarn isn't available on the system, then try npm. Do have a look at that, if there's a simple path to do so.

Node.js 16 became the current version in april 2021 and will become LTS on october 21st. Source : https://medium.com/the-node-js-collection/node-js-16-available-now-7f5099a97e70
As npm 7 is now as fast/clean/silent as yarn for install tasks, being able to switch to it would prevent installing one more package, which is always nice :-)

Hi,
Today yarn is still required. It feels like an excessive requirement. It would be nice to be able to use npm.


Editor override service always awaits whenInstalledExtensionsRegistered

It looks like we have a * override that always matches. As such we always await whenInstalledExtensionsRegistered on startup now.

Fixed https://github.com/microsoft/vscode/commit/3e1a7dc6551bb801b326fb3f8558f18b7a84389d. It was because the editorOverrideService knows the Text Editor exists on *, but we don't want to add that to the cache as the text editor isn't bound by the ext host.


Update the Twitter Logo

Observed behavior
The current Twitter logo is the old one. Now the Twitter logo has been updated to X.

Steps to reproduce

Go to https://www.ockam.io/blog
On the left sidebar you can see the old Twitter logo.

Expected behavior
New updated logo of Twitter should be displayed.

I would like to work on this issue. Please assign it to me.

Transferring this issue to the ockam-website repository and assigning you


Show correct error message when no constituency petitions found

Because we were using @petitions.present? as our guard and both [].present? and .present? on an AR relation with no results return false we ended up telling the user that we knew their MP but didn't know their constituency.  We switch to using @constituency.present? as the guard and this restores the correct behaviour.

LGTM


[Fix][Issue 107] RuntimeError: dictionary changed size during iteration

Fixes #107

Shallow copy shared iterables that are used on REST endpoints
Refactored previous shallow copies to use .copy() to make the intention and code clearear

Demonstrating the problem
The underlying issue, as explicit summarized in the exception, is related to a shared memory data struct being changed while it's being iterated (a best practice in kytos-ng docs to avoid this will be addressed on https://github.com/kytos-ng/kytos-ng.github.io/issues/33):

Here's a minimal example with two temporary functions that iterate on a shared iterable controller.switches (self.switches), and intentionally switches_iter_changing_size will insert into the collection to simulate the issue, whereas switches_iter_copy_changing_size will make a shallow copy and iterate on it, while inserting into the original collection:

diff --git a/kytos/core/controller.py b/kytos/core/controller.py
index ccb6c5a..1b42103 100644
--- a/kytos/core/controller.py
+++ b/kytos/core/controller.py
@@ -200,6 +200,18 @@ class Controller:
                 for name in logging.root.manager.loggerDict
                 if "kytos" in name]

+    def switches_iter_changing_size(self) -> None:
+        for idx, switch in enumerate(self.switches):
+            self.log.info(f"idx {idx}, it'll add switch {idx}")
+            switch = Switch(str(idx), connection=None)
+            self.add_new_switch(switch)
+
+    def switches_iter_copy_changing_size(self) -> None:
+        for idx, switch in enumerate(dict(self.switches)):
+            self.log.info(f"idx {idx}, it'll add switch {idx}")
+            switch = Switch(str(idx), connection=None)
+            self.add_new_switch(switch)
+
     def toggle_debug(self, name=None):
         """Enable/disable logging debug messages to a given logger name.

As you'd expect switches_iter_changing_size raises RuntimeError whereas switches_iter_changing_size doesnt:

kytos $> controller.switches_iter_copy_changing_size()
2022-08-09 12:39:08,073 - INFO [kytos.core.controller] (ThreadPoolExecutor-1_0) idx 0, it'll add switch 0
2022-08-09 12:39:08,075 - INFO [kytos.core.controller] (ThreadPoolExecutor-1_0) idx 1, it'll add switch 1
2022-08-09 12:39:08,076 - INFO [kytos.core.controller] (ThreadPoolExecutor-1_0) idx 2, it'll add switch 2

kytos $> controller.switches_iter_changing_size()
2022-08-09 12:39:14,582 - INFO [kytos.core.controller] (ThreadPoolExecutor-1_0) idx 0, it'll add switch 0
2022-08-09 12:39:14,584 - INFO [kytos.core.controller] (ThreadPoolExecutor-1_0) idx 1, it'll add switch 1
2022-08-09 12:39:14,586 - INFO [kytos.core.controller] (ThreadPoolExecutor-1_0) idx 2, it'll add switch 2
2022-08-09 12:39:14,587 - INFO [kytos.core.controller] (ThreadPoolExecutor-1_0) idx 3, it'll add switch 3
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
~/repos/kytos/kytos/core/kytosd.py in <module>
----> 1 controller.switches_iter_changing_size()

~/repos/kytos/kytos/core/controller.py in switches_iter_changing_size(self)
    204
    205     def switches_iter_changing_size(self) -> None:
--> 206         for idx, switch in enumerate(self.switches):
    207             self.log.info(f"idx {idx}, it'll add switch {idx}")
    208             switch = Switch(str(idx), connection=None)

RuntimeError: dictionary changed size during iteration

Performance

It'll depend on object size and the collection size, but since NApps are levering MongoDB as much as possible and avoiding to store large collections in memory, shallow copies isn't expected to introduce much latency, here's a benchmark with a collection with 10000 elements, it added roughly 100 us on mean and median results:

class Helper:
    @classmethod
    def gen_dict(cls, size: int) -> dict:
        return {i: i for i in range(size)}

    @classmethod
    def iter_dict(cls, size: int) -> None:
        """Perform an iteration simulating an conditional too"""
        for k, v in Helper.gen_dict(size).items():
            if k == "x":
                pass

    @classmethod
    def iter_dict_copy(cls, size: int) -> None:
        """Perform an iteration shallow copy simulating an conditional too"""
        for k, v in Helper.gen_dict(size).copy().items():
            if k == "x":
                pass

def test_dict_iter_10000(benchmark) -> None:
    benchmark(Helper.iter_dict, 10000)

def test_dict_iter_10000_copy(benchmark) -> None:
    benchmark(Helper.iter_dict_copy, 10000)

================================================================================== test session starts ===================================================================================
platform linux -- Python 3.10.5, pytest-7.1.2, pluggy-1.0.0
benchmark: 3.4.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
rootdir: /home/viniarck/repos/python
plugins: benchmark-3.4.1
collected 2 items

test_copy_bench.py ..                                                                                [100%]

------------------------------------------------------------------------------------------- benchmark: 2 tests ---------------------------------------------------------------------------
----------------
Name (time in us)                  Min                   Max                Mean             StdDev              Median                IQR            Outliers  OPS (Kops/s)            Ro
unds  Iterations
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------
test_dict_iter_10000          705.5320 (1.0)      1,479.0870 (1.28)     747.5517 (1.0)      51.5913 (1.37)     732.8570 (1.0)      34.6405 (1.58)        82;64        1.3377 (1.0)
1131           1
test_dict_iter_10000_copy     812.9850 (1.15)     1,152.3990 (1.0)      852.5019 (1.14)     37.5999 (1.0)      841.0625 (1.15)     21.9300 (1.0)       133;118        1.1730 (0.88)
1150           1
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------

Legend:
  Outliers: 1 Standard Deviation from Mean; 1.5 IQR (InterQuartile Range) from 1st Quartile and 3rd Quartile.
  OPS: Operations Per Second, computed as 1 / Mean
=================================================================================== 2 passed in 2.84s ====================================================================================

Thanks for reviewing, Antonio


Calling ray()->separator(); triggers an error 500

Hey,
Ray App: Version 1.18.3 (1.18.3)
Ray php: 1.31.0
Server: PHP 7.4.21 (cli) (built: Jul  8 2021 19:38:45) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.21, Copyright (c), by Zend Technologies
When calling : ray()->separator(); it creates an error 500 right at the point where the ray()->separator(); is called... i.e. Ray calls happening before the separator() are sent to the ray app... but as soon as ray()->separator(); is executed the server sends a 500 error.
Thanks,

Do you have more info on the error or exception being thrown?

Yes:
Fatal error: Uncaught BadMethodCallException: Method separator does not exist. in /home/nginx/domains/mydomain.com/public/apihook-PROD/vendor/spatie/macroable/src/Macroable.php:66 Stack trace: #0 /home/nginx/domains/mydomain.com/public/apihook-PROD/src/fb_cost_handler_adset_level.php(130): Spatie\Ray\Ray->__call() #1 {main} thrown in /home/nginx/domains/mydomain.com/public/apihook-PROD/vendor/spatie/macroable/src/Macroable.php on line 66

It seems like you are not using the latest version of the packe on the
server.
On Fri, 26 Nov 2021 at 07:34, benjamin74 @.***> wrote:

Yes:
Fatal error: Uncaught BadMethodCallException: Method separator does not
exist. in /home/nginx/domains/
mydomain.com/public/apihook-PROD/vendor/spatie/macroable/src/Macroable.php:66
Stack trace: #0 /home/nginx/domains/
mydomain.com/public/apihook-PROD/src/fb_cost_handler_adset_level.php(130):
Spatie\Ray\Ray->__call() #1 https://github.com/spatie/ray/issues/1
{main} thrown in /home/nginx/domains/
mydomain.com/public/apihook-PROD/vendor/spatie/macroable/src/Macroable.php
on line 66
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/spatie/ray/issues/601#issuecomment-979728665, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADWEDMP2V7BZBEZLJSEZOLUN4S7PANCNFSM5IZGYXQA
.

--
Freek Van der Herten https://spatie.be +32 495 84 27 91

I'm using 1.31.0 which is what github mentions as the latest (?)
composer.phar show
brick/math                    0.9.3   Arbitrary-precision arithmetic library
facebook/php-business-sdk     12.0.0  PHP SDK for Facebook Business
guzzlehttp/guzzle             7.4.0   Guzzle is a PHP HTTP client library
guzzlehttp/promises           1.5.1   Guzzle promises library
guzzlehttp/psr7               2.1.0   PSR-7 message implementation that also provides common utility...
psr/container                 1.1.2   Common Container Interface (PHP FIG PSR-11)
psr/http-client               1.0.1   Common interface for HTTP clients
psr/http-factory              1.0.1   Common interfaces for PSR-7 HTTP message factories
psr/http-message              1.0.1   Common interface for HTTP messages
ralouphie/getallheaders       3.0.3   A polyfill for getallheaders.
ramsey/collection             1.2.2   A PHP library for representing and manipulating collections.
ramsey/uuid                   4.2.3   A PHP library for generating and working with universally uniq...
spatie/backtrace              1.2.1   A better backtrace
spatie/macroable              1.0.1   A trait to dynamically add methods to a class
spatie/ray                    1.31.0  Debug with Ray to fix problems faster
symfony/deprecation-contracts v2.5.0  A generic function and convention to trigger deprecation notices
symfony/polyfill-ctype        v1.23.0 Symfony polyfill for ctype functions
symfony/polyfill-mbstring     v1.23.1 Symfony polyfill for the Mbstring extension
symfony/polyfill-php80        v1.23.1 Symfony polyfill backporting some PHP 8.0+ features to lower P...
symfony/polyfill-php81        v1.23.0 Symfony polyfill backporting some PHP 8.1+ features to lower P...
symfony/service-contracts     v2.5.0  Generic abstractions related to writing services
symfony/stopwatch             v5.3.4  Provides a way to profile code
symfony/var-dumper            v5.3.11 Provides mechanisms for walking through any arbitrary PHP vari.

It seems like we messed up the release. The function is available in the newly released  v1.32.0 of the package.
Thanks for bringing this issue to our attention.


BCLib + BetterEnd - Connection Lost

Describe the bug
Minecraft 1.20.1
Forge 47.2.1
trying to join my server with BCLib + BetterEnd results in the following
Connection Lost - Internal Exception: io.netty.handler.codec.DecoderException: java.lang.IndexOutOfBoundsException: ReaderIndex(13) + length(8) exceeds WriterIndex(14): PooledUnsafeDirectByteBuf(ridx: 13, widx 14, cap: 14)
Steps to reproduce
1.Start Client
2.Try to join my server
3.Connection lost
...
Logs
Error Log Modrith.txt
Additional context
This seems to only happen from the server side, and joing a single player world seems to be working perfectly fine, there did not seem to be much going on in the logs before, but just tried and i can see alot of "[worlds_together]" errors getting spammed this time.

I wonder if my server issue is because of this as well...
no logs or errors pointing to any mods but I get disconnected

Closing as stale / cannot reproduce.
If you can provide the necessary logs and information to reproduce the problem or identify the faulty mod, please open a new issue with all necessary details.


Create fibonnaci search.c

LGTM!
Two things

Rename the file to fibonacciSearch.c
Rename the function to fibonaccISearch()

GFG has fibMonacci, but here we want fibonacci 😄

i changed the function name and file name

final changes. i made the input dynamic and changes the file and function name also.
Please, review

LGTM! Thanks for your contribution! Merging into master


Add option to specify a location for atomic parsley: --atomic-location PATH

Checklist

[X] I'm reporting a feature request
[X] I've verified that I'm running youtube-dl version 2021.06.06
[X] I've searched the bug tracker for similar feature requests including closed ones

Description

Having to rely on atomic parsley being added to PATH is rather annoying when using the youtube-dl pip package in your own scripts, especially if you need to distribute your program to another computer and you want to bundle atomic parsley with it.
Because of this, I would like to request a feature allowing you to specify a location to either the atomic parsley binary or the folder containing it.
Suggestions for implementation are below:

This option could be implemented similarly to the --ffmpeg-location command option and the ffmpeg_location option for YoutubeDL in python. E.g.:

opts={
...
"atomic_location": "./AtomicParsley-win32-0.9.0/AtomicParsley.exe",
"ffmpeg_location: "./ffmpeg-20200115-0dc0837-win64-static/bin",
"postprocessors": [{'key': 'EmbedThumbnail', 'already_have_thumbnail': False}],
...
}

AND

youtube-dl.exe --ffmpeg-location "ffmpeg-20200115-0dc0837-win64-static/bin" https://www.youtube.com/watch?v=dQw4w9WgXcQ --atomic_location "AtomicParsley-win32-0.9.0/AtomicParsley.exe"

Alternatively, it could just be added as a parameter to the EmbedThumnailPP Postprocessor. E.g.:

opts = {
...
"postprocessors": [{'key': 'EmbedThumbnail', 'already_have_thumbnail': False, "atomic_location": "./AtomicParsley-win32-0.9.0/AtomicParsley.exe")}],
"ffmpeg_location: "./ffmpeg-20200115-0dc0837-win64-static/bin",
...
}

Please change the example URL.


Remove Gitter

:tada: This PR is included in version 2.3.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Migrate to Github Actions

Summary
Migration to github actions
Ticket Link

Updated Github actions to be on par with the recent refactor of the workflows in the provisioner.

Hey @phoinixgrr made some major changes addressing your comments.


fix: vite-playground Send

I am working on the KeepKey integration with @BitHighlander and noticed some funkiness when trying Send with multiple supported wallet types.
The problems were:

the controlled component wouldn't allow a user to freely type an input amount
the assetAmount that was ultimately passed to sdkClient.transfer always had a value of 1 decimal (this usually resulted in a value of 0 being passed to the wallet to sign)
the bootstrap script had an extra -

Broken:

Fixed: (https://etherscan.io/tx/0x6325245fada51110bb96f633da21d208e623b2a323901d90802bb02538785d59)

Hold on, need to fix a branching issue


SDK V3: Update to 5th testnet deployment of contracts

Overview
We need to update the contract addresses and ABIs to be the latest deployments.
Resources

Example PR  :point_right:  https://github.com/balancer/b-sdk/pull/319
Latest contract addresses from 5th testnet deployment
Verified contract info on Tenderly (grab ABIs here)
Mock Pool Deployments used for tests

  "B-50BAL-50WETH": "0x7CF221Fa36584f59A4F7FD7b946B8571c78E3692",
  "B-50DAI-50USDC": "0xf45f9638460e65173eAc117d9CE569cC0D561bF6",
  "B-50BAL-50DAI": "0xf6C927cAD5Fe9eB259e59ef604FC74532075dD97",
  "B-50WETH-50USD": "0xB1205100512690D5d51AddFf12AE0Ed99BCe80e8"

Blocker
A bunch of tests are failing because of ContractFunctionExecutionError

Here are results of verifying the same call from screenshot above but using foundry's cast call instead. Its interesting that it doesnt return 0x when the address is a valid pool but does with my phony 0x42069 comparison

Blocker
Creating weighted pools is failing because of missing "PoolCreated" event

Some how the tx is successful but the receipt contains no event logs :smiling_face_with_tear:

Blocker
A bunch of tests are failing because of ContractFunctionExecutionError
I have verified that the address is a contract, the params seem fine, and the pool contract almost certainly has the "allowance" function
Here are results of making the same call from screenshot above using foundry's cast call instead. Its interesting that it doesnt return no data ("0x") when the address is a valid pool but does with my intentional 0x42069... spoof

This phenomenon is also happening for all of the router queries 🤔

This is an annoying one that sometimes pops up, once you've experienced it once it'll probably stick in your head! If you check anvil-global-setup.ts you'll see the current forkBlockNumber is actually set for a block before the contract was deployed, I updated that to: forkBlockNumber: 6178545n, and it fixes the removeLiquidity tests at least. There still seems to be issues elsewhere though...

Blocker
Creating weighted pools is failing because of missing "PoolCreated" event
Some how the tx is successful but the receipt contains no event logs 🥲

Worth digging into this a bit more:

confirm in mono-repo that we still expect the event
try a tenderly simulation to see if it happens there
Let us know what you find!

About checking if a pool was properly created by parsing an event message.
I've always felt like this is a workaround that could be improved.
Can we influence this somehow?
Ask them to return the pool address (or any other info we might need)?

About checking if a pool was properly created by parsing an event message. I've always felt like this is a workaround that could be improved. Can we influence this somehow? Ask them to return the pool address (or any other info we might need)?

Not sure quite what you mean here but if there is a way to make things better (especially for builders) we should definitely raise it 👍

Not sure quite what you mean here but if there is a way to make things better (especially for builders) we should definitely raise it 👍

We're currently parsing poolAddress from the poolCreatedEvent message.
This seems a bit odd to me, as I'd expect the create method to already return poolAddress.
My suggestion was to ask the SC to add it to the output of the function, but as a matter of fact, I just looked at the ABI of the pool factory and create does return poolAddress, so I'm not really sure why we're not getting it directly from there.
I believe it's better to rely on the output of the function instead of relying on the event message.

I believe relying on the output of the function is better than relying on the event message
@brunoguerios Can you help me understand why?

The event is arguably more important since its what's actually used for indexing the data, but also i guess that testing prolly happens on monorepo huh

I'd say it's more like a general feeling. The question that triggered this was:

confirm in mono-repo that we still expect the event

Event message just seems more loosely coupled with the function itself than its own output.
Anyway - I don't think this is huge problem. Just something that bugged me for a while.
If you guys think the event message is reliable enough, I'd say it's ok to stick with it 👍

Blocker
The 'multi-hop swap' for the swapV3 Integration tests are all still failing. I copy/pasted the args from the failing test output to simulate with tenderly where the transaction is successful :thinking:
QuerySwapExactIn
:eyes: Tenderly Simulation of querySwapExactIn()

QuerySwapExactOut
:eyes: Tenderly Simulation of querySwapExactOut()

I realized its passing on Tenderly cus it uses latest block number by default. Sorry I still don't have a great handle on how the block numbers work. I get that it has to be a block number after deployment of the contract cus all tests execute at the given block number right?


Window close button is inactive

I would like it to be active and minimize the app. Since WindowEvent::CloseRequested is already intercepted, the close button should indeed minimize the window as intended, so there is no reason to disable it.

I did it on purpose. In our case, the close button closes the UI but the app still running and the windows can be opened again from the system tray:

I decided to hide this button because its behavior is different. Usually, the user expects to close the entire app using the close button, but in our case, it only closes the window but not the app.
What do you think? (I'm open for communication and changes, so if you resist, then we will enable it again 😃)


mailcatcher/Dockerfile build is failing on initial attempt

Describe the bug
Mailcatcher dockerfile build appears to fail due to a dependency error when running pnpm saas up on fresh project. See full logs below.
Steps to reproduce

pnpm create saas-boilerplate .
At prompt, enter project name and skip through other configuration.
pnpm saas up

System Info
System:
    OS: Windows 10 10.0.19045
    CPU: (24) x64 AMD Ryzen 9 3900X 12-Core Processor
    Memory: 9.76 GB / 31.95 GB
  Binaries:
    Node: 18.19.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD
    pnpm: 8.15.1 - ~\AppData\Local\pnpm\pnpm.EXE
  Browsers:
    Edge: Chromium (121.0.2277.98)
    Internet Explorer: 11.0.19041.3636
  npmPackages:
    @apollo/client: ^3.8.8 => 3.8.8
    @apollo/rover: ^0.19.1 => 0.19.1
    @aws-sdk/client-cloudformation: ^3.462.0 => 3.462.0
    @aws-sdk/client-codebuild: ^3.462.0 => 3.462.0
    @aws-sdk/client-ecr: ^3.462.0 => 3.462.0
    @aws-sdk/client-ecs: ^3.462.0 => 3.462.0
    @aws-sdk/client-iam: ^3.462.0 => 3.462.0
    @aws-sdk/client-lambda: ^3.462.0 => 3.462.0
    @aws-sdk/client-s3: ^3.462.0 => 3.462.0
    @aws-sdk/client-ses: ^3.462.0 => 3.462.0
    @aws-sdk/client-sfn: ^3.462.0 => 3.462.0
    @aws-sdk/client-sts: ^3.462.0 => 3.462.0
    @babel/preset-react: ^7.23.3 => 7.23.3
    @graphql-codegen/cli: ^5.0.0 => 5.0.0
    @graphql-typed-document-node/core: ^3.2.0 => 3.2.0
    @iconify-icons/ion: ^1.2.10 => 1.2.10
    @iconify/react: ^4.1.1 => 4.1.1
    @nx/devkit: 17.1.3 => 17.1.3
    @nx/eslint: 17.1.3 => 17.1.3
    @nx/eslint-plugin: 17.1.3 => 17.1.3
    @nx/jest: 17.1.3 => 17.1.3
    @nx/js: 17.1.3 => 17.1.3
    @nx/node: 17.1.3 => 17.1.3
    @nx/plugin: 17.1.3 => 17.1.3
    @nx/react: 17.1.3 => 17.1.3
    @nx/web: 17.1.3 => 17.1.3
    @nx/webpack: 17.1.3 => 17.1.3
    @sb/cli: * => 2.4.1
    @sb/core: * => 2.4.1
    @sentry/react: ^7.84.0 => 7.84.0
    @storybook/addon-actions: ^7.6.1 => 7.6.1
    @storybook/react: ^7.6.1 => 7.6.1
    @supercharge/strings: ^2.0.0 => 2.0.0
    @svgr/webpack: ^8.1.0 => 8.1.0
    @tailwindcss/typography: ^0.5.10 => 0.5.10
    @testing-library/dom: ^9.3.3 => 9.3.3
    @testing-library/jest-dom: ^6.1.4 => 6.1.4
    @testing-library/react: 14.0.0 => 14.0.0
    @testing-library/react-hooks: ^8.0.1 => 8.0.1
    @testing-library/user-event: ^14.5.1 => 14.5.1
    @trivago/prettier-plugin-sort-imports: ^4.3.0 => 4.3.0
    @types/gtag.js: ^0.0.14 => 0.0.14
    @types/jest: ^29.5.10 => 29.5.10
    @types/node: ^18.18.14 => 18.18.14
    @types/ramda: ^0.28.25 => 0.28.25
    @types/react: 18.2.24 => 18.2.24
    @types/react-dom: 18.2.9 => 18.2.9
    @types/react-router: ^5.1.20 => 5.1.20
    @types/react-router-dom: 5.3.3 => 5.3.3
    @types/react-test-renderer: ^18.0.7 => 18.0.7
    @typescript-eslint/eslint-plugin: 6.13.1 => 6.13.1
    @typescript-eslint/parser: 6.13.1 => 6.13.1
    @typescript-eslint/scope-manager: 5.62.0 => 5.62.0
    @vitejs/plugin-react: ^4.2.0 => 4.2.0
    aws-cdk: ^2.111.0 => 2.111.0
    aws-cdk-lib: ^2.111.0 => 2.111.0
    babel-jest: 29.7.0 => 29.7.0
    constructs: ^10.3.0 => 10.3.0
    esbuild: 0.19.8 => 0.19.8
    eslint: ^8.54.0 => 8.54.0
    eslint-config-prettier: 9.0.0 => 9.0.0
    eslint-import-resolver-typescript: ^3.6.1 => 3.6.1
    eslint-plugin-formatjs: ^4.11.3 => 4.11.3
    eslint-plugin-import: 2.28.1 => 2.28.1
    eslint-plugin-jsx-a11y: ^6.8.0 => 6.8.0
    eslint-plugin-react: 7.33.2 => 7.33.2
    eslint-plugin-react-hooks: 4.6.0 => 4.6.0
    eslint-plugin-testing-library: ^6.2.0 => 6.2.0
    graphql: ^16.8.1 => 16.8.1
    husky: ^8.0.3 => 8.0.3
    jest: 29.7.0 => 29.7.0
    jest-environment-jsdom: 29.7.0 => 29.7.0
    jest-matcher-utils: ^29.7.0 => 29.7.0
    jest-watch-typeahead: ^2.2.2 => 2.2.2
    lint-staged: ^14.0.1 => 14.0.1
    nx: 17.1.3 => 17.1.3
    nx-cloud: 16.5.2 => 16.5.2
    plop: ^4.0.0 => 4.0.0
    prettier: ^3.1.0 => 3.1.0
    prettier-plugin-tailwindcss: ^0.5.7 => 0.5.7
    ramda: ^0.28.0 => 0.28.0
    react: 18.2.0 => 18.2.0
    react-dom: 18.2.0 => 18.2.0
    react-helmet-async: ^1.3.0 => 1.3.0
    react-hook-form: ^7.48.2 => 7.48.2
    react-intl: ^6.5.5 => 6.5.5
    react-loading-skeleton: ^3.3.1 => 3.3.1
    react-markdown: ^8.0.7 => 8.0.7
    react-router: ^6.16.0 => 6.16.0
    react-router-dom: 6.16.0 => 6.16.0
    regenerator-runtime: ^0.14.0 => 0.14.0
    styled-components: 6.0.8 => 6.0.8
    tailwindcss: ^3.3.5 => 3.3.5
    tailwindcss-animate: ^1.0.7 => 1.0.7
    ts-jest: 29.1.1 => 29.1.1
    ts-node: 10.9.1 => 10.9.1
    tsconfig-paths: ^4.2.0 => 4.2.0
    tslib: ^2.6.2 => 2.6.2
    typescript: 5.2.2 => 5.2.2
    vite: ^4.5.0 => 4.5.0
    vite-plugin-eslint: ^1.8.1 => 1.8.1
    vite-plugin-svgr: ^3.3.0 => 3.3.0
    vite-tsconfig-paths: ^4.2.1 => 4.2.1

Logs

Click to expand!
#0 building with "default" instance using docker driver
#1 [mailcatcher internal] load build definition from Dockerfile
#1 transferring dockerfile:
#1 ...
#2 [mailcatcher internal] load .dockerignore
#2 transferring context: 2B 0.0s done
#2 DONE 0.4s
#3 [localwsserver internal] load build definition from Dockerfile
#3 transferring dockerfile: 172B 0.0s done
#3 DONE 0.5s
#1 [mailcatcher internal] load build definition from Dockerfile
#1 transferring dockerfile: 406B 0.2s done
#1 DONE 0.5s
#4 [localwsserver internal] load .dockerignore
#4 transferring context: 52B 0.0s done
#4 DONE 0.5s
#5 [mailcatcher internal] load metadata for docker.io/dockage/alpine:3.15.4
#5 ...
#6 [mailcatcher auth] dockage/alpine:pull token for registry-1.docker.io
#6 DONE 0.0s
#7 [localwsserver auth] library/node:pull token for registry-1.docker.io
#7 DONE 0.0s
#8 [localwsserver internal] load metadata for docker.io/library/node:20-alpine
#8 DONE 2.9s
#5 [mailcatcher internal] load metadata for docker.io/dockage/alpine:3.15.4
#5 ...
#9 [localwsserver 1/5] FROM docker.io/library/node:20-alpine@sha256:2f46fd49c767554c089a5eb219115313b72748d8f62f5eccb58ef52bc36db4ad
#9 DONE 0.0s
#10 [localwsserver internal] load build context
#10 transferring context: 301B 0.1s done
#10 DONE 0.7s
#5 [mailcatcher internal] load metadata for docker.io/dockage/alpine:3.15.4
#5 ...
#11 [localwsserver 2/5] WORKDIR /app
#11 CACHED
#12 [localwsserver 3/5] COPY package.json yarn.lock /app/
#12 CACHED
#13 [localwsserver 4/5] RUN yarn
#13 CACHED
#14 [localwsserver 5/5] COPY . /app/
#14 CACHED
#15 [localwsserver] exporting to image
#15 exporting layers done
#15 writing image sha256:1ebcc9a0c63156794e9058f1fd9f00a86d53eefbb89af0a178c857cf799d69b4 0.0s done
#15 naming to docker.io/library/saas-boilerplate-localwsserver 0.0s done
#15 DONE 0.0s
#5 [mailcatcher internal] load metadata for docker.io/dockage/alpine:3.15.4
#5 DONE 4.3s
#16 [mailcatcher 1/2] FROM docker.io/dockage/alpine:3.15.4@sha256:3d208f187240cb1f8cdfa4021dfc34b028ae79637194a316d34346d994420112
#16 CACHED
#17 [mailcatcher 2/2] RUN apk --no-cache --update add build-base ruby ruby-dev ruby-json ruby-etc sqlite-dev     && gem install mailcatcher:0.8.2 --no-document     && apk del --rdepends --purge build-base
#17 0.774 fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.tar.gz
#17 0.992 fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/community/x86_64/APKINDEX.tar.gz
#17 1.196 fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
#17 1.476 fetch http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
#17 1.769 fetch http://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
#17 2.217 ERROR: unable to select packages:
#17 2.221   musl-1.2.2-r7:
#17 2.221     breaks: musl-dev-1.2.2-r9[musl=1.2.2-r9]
#17 2.221     satisfies: apk-tools-2.12.7-r3[musl>=1.2]
#17 2.221                apk-tools-2.12.7-r3[so:libc.musl-x86_64.so.1]
#17 2.221                ruby-libs-3.0.6-r0[so:libc.musl-x86_64.so.1]
#17 2.221                pkgconf-1.8.1-r0[so:libc.musl-x86_64.so.1]
#17 2.221                gcc-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
#17 2.221                g++-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
#17 2.221                libffi-3.4.2-r1[so:libc.musl-x86_64.so.1]
#17 2.221                patch-2.7.6-r7[so:libc.musl-x86_64.so.1]
#17 2.221                libgmpxx-6.2.1-r1[so:libc.musl-x86_64.so.1]
#17 2.221                ca-certificates-20211220-r0[so:libc.musl-x86_64.so.1]
#17 2.221                binutils-2.37-r3[so:libc.musl-x86_64.so.1]
#17 2.221                busybox-1.34.1-r5[so:libc.musl-x86_64.so.1]
#17 2.221                ruby-3.0.6-r0[so:libc.musl-x86_64.so.1]
#17 2.221                sqlite-libs-3.36.0-r0[so:libc.musl-x86_64.so.1]
#17 2.221                libucontext-1.1-r0[so:libc.musl-x86_64.so.1]
#17 2.221                libretls-3.3.4-r3[so:libc.musl-x86_64.so.1]
#17 2.221                ncurses-libs-6.3_p20211120-r2[so:libc.musl-x86_64.so.1]
#17 2.221                musl-utils-1.2.2-r7[so:libc.musl-x86_64.so.1]
#17 2.221                libstdc++-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
#17 2.221                file-5.41-r0[so:libc.musl-x86_64.so.1]
#17 2.221                mpc1-1.2.1-r0[so:libc.musl-x86_64.so.1]
#17 2.221                libmagic-5.41-r0[so:libc.musl-x86_64.so.1]
#17 2.221                gdbm-1.22-r0[so:libc.musl-x86_64.so.1]
#17 2.221                libgphobos-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
#17 2.221                su-exec-0.2-r1[so:libc.musl-x86_64.so.1]
#17 2.221                mpfr4-4.1.0-r0[so:libc.musl-x86_64.so.1]
#17 2.221                zlib-1.2.12-r0[so:libc.musl-x86_64.so.1]
#17 2.221                libgomp-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
#17 2.221                readline-8.1.1-r0[so:libc.musl-x86_64.so.1]
#17 2.221                make-4.3-r0[so:libc.musl-x86_64.so.1]
#17 2.221                libgcc-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
#17 2.221                libssl1.1-1.1.1n-r0[so:libc.musl-x86_64.so.1]
#17 2.221                alpine-baselayout-3.2.0-r18[so:libc.musl-x86_64.so.1]
#17 2.314                libcrypto1.1-1.1.1n-r0[so:libc.musl-x86_64.so.1]
#17 2.314                libatomic-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
#17 2.314                yaml-0.2.5-r0[so:libc.musl-x86_64.so.1]
#17 2.314                scanelf-1.3.3-r0[so:libc.musl-x86_64.so.1]
#17 2.314                gmp-6.2.1-r1[so:libc.musl-x86_64.so.1]
#17 2.314                isl22-0.22-r0[so:libc.musl-x86_64.so.1]
#17 2.314                ssl_client-1.34.1-r5[so:libc.musl-x86_64.so.1]
#17 ERROR: process "/bin/sh -c apk --no-cache --update add build-base ruby ruby-dev ruby-json ruby-etc sqlite-dev     && gem install mailcatcher:${MAILCATCHER_VERSION} --no-document
     && apk del --rdepends --purge build-base" did not complete successfully: exit code: 4
------
 > [mailcatcher 2/2] RUN apk --no-cache --update add build-base ruby ruby-dev ruby-json ruby-etc sqlite-dev     && gem install mailcatcher:0.8.2 --no-document     && apk del --rdepends --purge build-base:
2.221                libgcc-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
2.221                libssl1.1-1.1.1n-r0[so:libc.musl-x86_64.so.1]
2.221                alpine-baselayout-3.2.0-r18[so:libc.musl-x86_64.so.1]
2.314                libcrypto1.1-1.1.1n-r0[so:libc.musl-x86_64.so.1]
2.314                libatomic-10.3.1_git20211027-r0[so:libc.musl-x86_64.so.1]
2.314                yaml-0.2.5-r0[so:libc.musl-x86_64.so.1]
2.314                scanelf-1.3.3-r0[so:libc.musl-x86_64.so.1]
2.314                gmp-6.2.1-r1[so:libc.musl-x86_64.so.1]
2.314                isl22-0.22-r0[so:libc.musl-x86_64.so.1]
2.314                ssl_client-1.34.1-r5[so:libc.musl-x86_64.so.1]
------
failed to solve: process "/bin/sh -c apk --no-cache --update add build-base ruby ruby-dev ruby-json ruby-etc sqlite-dev     && gem install mailcatcher:${MAILCATCHER_VERSION} --no-document     && apk del --rdepends --purge build-base" did not complete successfully: exit code: 4
Warning: run-commands command "docker-compose up --force-recreate -d backend workers" exited with non-zero status code

 ———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————

 >  NX   Ran target docker-compose:up for project core and 2 task(s) they depend on (4m)

    ×    1/3 failed
    √    2/3 succeeded [0 read from cache]

    Error: "pnpm nx run core:docker-compose:up" failed with code 1

Validations

[X] Follow our Code of Conduct.
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

You need to change /packages/internal/mailcatcher/Dockerfile
In the first line, bump the version of alpine from 3.15.4 to 3.19.0
Although that makes the build succeed, I have not tested the email functionality.

Thanks for the response.
Modifying the Mailcatacher Dockerfile to dockage/alpine:3.19.0 allows the build to successfully complete, but the container isn't able to start (there appears to then be an error with the sqlite dependency?):
2024-02-10 17:51:02 Starting MailCatcher v0.8.2
2024-02-10 17:51:02 <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- sqlite3/sqlite3_native (LoadError)
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/sqlite3-1.7.2-x86_64-linux/lib/sqlite3.rb:6:in `rescue in <top (required)>'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/sqlite3-1.7.2-x86_64-linux/lib/sqlite3.rb:2:in `<top (required)>'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher/mail.rb:6:in `<top (required)>'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher/smtp.rb:5:in `<top (required)>'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher.rb:183:in `block (2 levels) in run!'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher.rb:233:in `rescue_port'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher.rb:182:in `block in run!'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:193:in `run_machine'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:193:in `run'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher.rb:180:in `run!'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/bin/mailcatcher:6:in `<top (required)>'
2024-02-10 17:51:02     from /usr/bin/mailcatcher:25:in `load'
2024-02-10 17:51:02     from /usr/bin/mailcatcher:25:in `<main>'
2024-02-10 17:51:02 <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require': Error relocating /usr/lib/ruby/gems/3.2.0/gems/sqlite3-1.7.2-x86_64-linux/lib/sqlite3/3.2/sqlite3_native.so: posix_fallocate64: symbol not found - /usr/lib/ruby/gems/3.2.0/gems/sqlite3-1.7.2-x86_64-linux/lib/sqlite3/3.2/sqlite3_native.so (LoadError)
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/sqlite3-1.7.2-x86_64-linux/lib/sqlite3.rb:4:in `<top (required)>'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher/mail.rb:6:in `<top (required)>'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher/smtp.rb:5:in `<top (required)>'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from <internal:/usr/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher.rb:183:in `block (2 levels) in run!'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher.rb:233:in `rescue_port'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher.rb:182:in `block in run!'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:193:in `run_machine'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:193:in `run'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/lib/mail_catcher.rb:180:in `run!'
2024-02-10 17:51:02     from /usr/lib/ruby/gems/3.2.0/gems/mailcatcher-0.8.2/bin/mailcatcher:6:in `<top (required)>'
2024-02-10 17:51:02     from /usr/bin/mailcatcher:25:in `load'
2024-02-10 17:51:02     from /usr/bin/mailcatcher:25:in `<main>'

Thanks for the response @gabrii, some thoughts below:
Using Alpine 3.19
Alpine 3.19 isn't a viable option unfortunately, as it seems there's an issue with the sqlite native precompiled gem, introduced by a breaking change in Musl 1.2 (which I think this is actually a root cause of my original issue). This prevents the container from starting up properly, even though the build completes.
This issue on the sqlite3-ruby repository covers it:
https://github.com/sparklemotion/sqlite3-ruby/issues/434
More information on this from the Alpine repo:
https://github.com/alpinelinux/docker-alpine/issues/220
Using Alpine 3.18
Using dockage/alpine:3.18 allows the build to complete, but another incompatibility issue (this time with Ruby 3.x and Fixnum initialization) prevents the container from starting. Details for this issue can be found in https://github.com/sj26/mailcatcher/issues/545
Using Alpine 3.18 and Mailcatcher 0.9
My latest attempt, using Alpine 3.18 and Mailcatcher 0.9 allows the build to complete and the container to successfully start. However, when I attempt to send an email from the backend I'm seeing this error in the workers container:
2024-02-10 20:42:08 stdout:
2024-02-10 20:42:08 ><EMAIL_ADDRESS>sls /app/packages/workers
2024-02-10 20:42:08 > sls "invoke" "local" "-f" "SendEmail" "-d" "{\"source\":\"backend.email\",\"detail-type\":\"PASSWORD_RESET\",\"detail\":{\"id\":\"a862778ef5b54c4ca3eb15ede2a26768\",\"type\":\"PASSWORD_RESET\",\"to\":\"test@myaddress.com\",\"user_id\":\"OVwJAm8\",\"token\":\"c27m28-5da18398207311ea3a5f1d9bdd16fead\"}}"
2024-02-10 20:42:08 stderr: node:internal/modules/cjs/loader:1080
2024-02-10 20:42:08   throw err;
2024-02-10 20:42:08   ^
2024-02-10 20:42:08 Error: Cannot find module '/app/packages/workers/node_modules/serverless/bin/serverless.js'
2024-02-10 20:42:08     at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
2024-02-10 20:42:08     at Module._load (node:internal/modules/cjs/loader:922:27)
2024-02-10 20:42:08     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
2024-02-10 20:42:08     at node:internal/main/run_main_module:23:47 {
2024-02-10 20:42:08   code: 'MODULE_NOT_FOUND',
2024-02-10 20:42:08   requireStack: []
2024-02-10 20:42:08 }
2024-02-10 20:42:08 Node.js v18.17.1
2024-02-10 20:42:08 stdout:  ELIFECYCLE  Command failed with exit code 1.
2024-02-10 20:42:08 child process exited with code 1

No idea what's happening here, but it does seem like you've seen this same error in the past: https://github.com/apptension/saas-boilerplate/pull/426#discussion_r1395347273

Hi @andrewrice, you are right. I got it to start with:
FROM dockage/alpine:3.18
ENV MAILCATCHER_VERSION=0.9.0

I proceeded to try to send a recovery email, and just made it this far:

><EMAIL_ADDRESS>sls /app/packages/workers
> sls "invoke" "local" "-f" "SendEmail" "-d" "{\"source\":\"backend.email\",\"detail-type\":\"PASSWORD_RESET\",\"detail\":{\"id\":\"19b2108dc0ba43ebb19c1628c690947c\",\"type\":\"PASSWORD_RESET\",\"to\":\"admin@example.com\",\"user_id\":\"ajeypWr\",\"token\":\"c289p8-56adb95d4ca2224858352d0c5e37b4c9\"}}"
stderr: (node:146) NOTE: We are formalizing our plans to enter AWS SDK for JavaScript (v2) into maintenance mode in 2023.
Please migrate your code to use AWS SDK for JavaScript (v3).
For more information, check the migration guide at https://a.co/7PzMCcy
(Use `node --trace-warnings ...` to show where the warning was created)
stderr: Environment: linux, node 18.17.1, framework 3.35.2 (local), plugin 7.0.3, SDK 4.4.0
Docs:        docs.serverless.com
Support:     forum.serverless.com
Bugs:        github.com/serverless/serverless/issues
stderr:
stdout: Error:
Cannot resolve serverless.yml: Variables resolution errored with:
  - Cannot resolve variable at "custom.conf.eventBusArn": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.environment.SENTRY_DSN": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.SendEmail.environment.FROM_EMAIL": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.ExportUsers.environment.HASHID_SALT": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.SynchronizeContentfulContent.environment.CONTENTFUL_SPACE_ID": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.WebSocketsHandler.environment.HASHID_SALT": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.SendEmail.environment.WEB_APP_URL": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.SynchronizeContentfulContent.environment.CONTENTFUL_ACCESS_TOKEN": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.SynchronizeContentfulContent.environment.CONTENTFUL_ENVIRONMENT": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .,
  - Cannot resolve variable at "custom.conf.WebSocketsHandler.environment.JWT_SECRET": AWS provider credentials not found. Learn how to set up AWS provider credentials in our docs here: .
stdout:  ELIFECYCLE  Command failed with exit code 1.
child process exited with code 1

To get the workers to run (albeit with bad configuration) I had to do the exact change you reference in the comment, as it seems like node_modules are affected somehow otherwise:
diff --git a/packages/workers/Dockerfile b/packages/workers/Dockerfile
index b56b52a..2c7f573 100644
--- a/packages/workers/Dockerfile
+++ b/packages/workers/Dockerfile
@@ -39,12 +39,12 @@ COPY $SRC_CORE_PATH/package.json $DEST_CORE_PATH/
 COPY $SRC_WORKERS_PATH/package.json $DEST_WORKERS_PATH/
 COPY tsconfig* $APP_PATH/
 COPY $SRC_CLI_PATH $DEST_CLI_PATH/
-RUN pnpm install --include-workspace-root --frozen-lockfile --filter=workers... --filter=cli...

 COPY nx.json tsconfig* jest* babel* .eslintrc* .prettier* .eslintrc* $APP_PATH/
 COPY $SRC_CORE_PATH $DEST_CORE_PATH/
 COPY $SRC_WORKERS_PATH $DEST_WORKERS_PATH/
 RUN chmod +x $DEST_WORKERS_PATH/scripts/*.sh
+RUN pnpm install --include-workspace-root --frozen-lockfile --filter=workers... --filter=cli...

 ENV PYTHONPATH=/pkgs/__pypackages__/3.11/lib \
     PATH=$PATH:/pkgs/__pypackages__/3.11/bin

It seems like @pziemkowski gave some solutions in discord to fix the wrong configuration inside the workers: https://discord.com/channels/1122849885335597088/1125769784018087967/1156618189862608928
I'll leave this to the experts, right now deploying is not my priority. Apologies.

@andrewrice @gabrii Please check the PR with the fix. It will be included in the next release

@mkleszcz I've integrated the changes in your PR and it resolves the build/startup issues with the mailcatcher container (thank you!), but there it still seems to be an issue in the worker's container that @gabrii highlighted when attempting to send an email from the backend:
Here's an excerpt from workers-1 container log:
2024-02-12 13:02:58 > nx run workers:serve
2024-02-12 13:02:58
2024-02-12 13:02:59 Local trigger server listening at http://<IP_ADDRESS>:3005
2024-02-12 13:03:13 stdout:
2024-02-12 13:03:13 ><EMAIL_ADDRESS>sls /app/packages/workers
2024-02-12 13:03:13 > sls "invoke" "local" "-f" "SynchronizeContentfulContent" "-d" "{\"source\":\"backend.contentfulSync\",\"detail-type\":\"complete\",\"detail\":{\"id\":\"c6b09ef97bae46adb6a795ea3367924a\",\"type\":\"complete\"}}"
2024-02-12 13:03:13 stderr: node:internal/modules/cjs/loader:1080
2024-02-12 13:03:13   throw err;
2024-02-12 13:03:13   ^
2024-02-12 13:03:13 Error: Cannot find module '/app/packages/workers/node_modules/serverless/bin/serverless.js'
2024-02-12 13:03:13     at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
2024-02-12 13:03:13     at Module._load (node:internal/modules/cjs/loader:922:27)
2024-02-12 13:03:13     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
2024-02-12 13:03:13     at node:internal/main/run_main_module:23:47 {
2024-02-12 13:03:13   code: 'MODULE_NOT_FOUND',
2024-02-12 13:03:13   requireStack: []
2024-02-12 13:03:13 }
2024-02-12 13:03:13 Node.js v18.17.1
2024-02-12 13:03:13 stdout:  ELIFECYCLE  Command failed with exit code 1.
2024-02-12 13:03:13 child process exited with code 1
2024-02-12 13:30:05 stdout:
2024-02-12 13:30:05 ><EMAIL_ADDRESS>sls /app/packages/workers
2024-02-12 13:30:05 > sls "invoke" "local" "-f" "SendEmail" "-d" "{\"source\":\"backend.email\",\"detail-type\":\"ACCOUNT_ACTIVATION\",\"detail\":{\"id\":\"6c7f5d65bda0437da211dc4a348730b6\",\"type\":\"ACCOUNT_ACTIVATION\",\"to\":\"test@example.com\",\"user_id\":\"OVwJAm8\",\"token\":\"c2are4-5570785471b3b919ba9e6aa72d0ce915\"}}"
2024-02-12 13:30:05 stderr: node:internal/modules/cjs/loader:1080
2024-02-12 13:30:05   throw err;
2024-02-12 13:30:05   ^
2024-02-12 13:30:05 Error: Cannot find module '/app/packages/workers/node_modules/serverless/bin/serverless.js'
2024-02-12 13:30:05     at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
2024-02-12 13:30:05     at Module._load (node:internal/modules/cjs/loader:922:27)
2024-02-12 13:30:05     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
2024-02-12 13:30:05     at node:internal/main/run_main_module:23:47 {
2024-02-12 13:30:05   code: 'MODULE_NOT_FOUND',
2024-02-12 13:30:05   requireStack: []
2024-02-12 13:30:05 }
2024-02-12 13:30:05 Node.js v18.17.1
2024-02-12 13:30:05 stdout:  ELIFECYCLE  Command failed with exit code 1.
2024-02-12 13:30:05 child process exited with code 1
2024-02-12 13:30:30 stdout:
2024-02-12 13:30:30 ><EMAIL_ADDRESS>sls /app/packages/workers
2024-02-12 13:30:30 > sls "invoke" "local" "-f" "SendEmail" "-d" "{\"source\":\"backend.email\",\"detail-type\":\"PASSWORD_RESET\",\"detail\":{\"id\":\"2ca0c55002ac4c2aa6ca10b83174aff1\",\"type\":\"PASSWORD_RESET\",\"to\":\"test@example.com\",\"user_id\":\"OVwJAm8\",\"token\":\"c2areu-bead185dfdb85583ed35d171bd3bf2a3\"}}"

It seems like it's unable to locate the serverless module.
Not sure if this helpful, but this is what the worker-1 container file tree looks like at /app/packages/workers/node_modules:

It's almost like the symlink between .bin and bin isn't generated? Any thoughts?
Very much appreciate you!

@andrewrice please check #484 for the fixes for above issues ;)

@andrewrice please check #484 for the fixes for above issues ;)

Thanks @mkleszcz -- I'll give a shot tomorrow afternoon and will report back!


add upgrade instructions to changelog

Closed in favor of https://github.com/pipxproject/pipx/pull/312