.dylib, not .so files are produced on Mac, which makes installation fail

When I tried to R CMD INSTALL . the hello example on Mac, it fails because:
cp: ../target/release/libhello.so: No such file or directory

and I fount that libhello.dylib was produced instead

A workaround could be changing
cp ../target/release/libhello.so .

to
cp ../target/release/libhello.dylib ./libhello.so

in extendr-api/examples/R/hello/src/Makefile
although I'm not sure if this is the correct way to do this.

macOS should produce .dylib.
.so is for Linux.

Give @dasmoth a ping on this. He is the master of Mac builds.

I actually mostly work on Linux too nowadays, but in the past I've done:
cp ../target/release/libhello.* .

...which seemed to work.

谢谢 @TianyiShi2001
I'll amend this in the package.skeleton generator in the upcoming R package.
If you could let us know if the @dasmoth solution works...
Look out for our Oxford Rust meetup on Thursday.

By only changing that line to cp ../target/release/libhello.* . I got the following error when R CMD INSTALL .:
Error: package or namespace load failed for ‘hello’ in library.dynam(lib, package, package.lib):
 shared object ‘libhello.so’ not found
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/Users/tianyishi/Library/R/3.6/library/hello’
* restoring previous ‘/Users/tianyishi/Library/R/3.6/library/hello’

libhello.d and libhello.dylib have been copied to the current directory, but only libhello.so was searched for.
Changing it to:
cp ../target/release/libhello.dylib ./libhello.so

made it work in this case. However, it seems that a .dylib file isn't always equivalent to a .so file (I'm not sure, I have no experience in C/C++) so this is unlikely to be the correct way to do this.

as I commented before, .dylib is what you should expect to generate on macOS. they're not exactly the same. and simply renaming it won't work

What you need is something like this:
https://github.com/r-rust/hellorust/blob/master/src/Makevars
Also notice that "Makefile" is not a proper name used by R. By convention it should be "Makevars"

For the moment I do not have a mac environment to build this on and so
cannot give you a solution.
The Mac edition of Rust should produce a compatible shared object with the
Mac shared object
both compilers use LLVM under the hood. Chris was recruited by Apple to run
the Xcode team.
Apple objects are "Mach-O" instead of "ELF", but the differences are
minimal.
The Makevars file is used for C/C++ builds. Jeoren had to do a two stage
build -
linking a static library (hence STATLIB) into a shared object which is
unnecessary.
Rust can build shared object libraries directly although the exact runes
for the
Mac build elude us.
Once we get access to a Mac platform or a skilled Mac developer armed with
such,
we can specialise the Makefile accordingly.
On Mon, Oct 5, 2020 at 8:12 PM Lucius Hu<EMAIL_ADDRESS>wrote:

What you need is something like this:
https://github.com/r-rust/hellorust/blob/master/src/Makevars
Also notice that "Makefile" is not a proper name used by R. By convention
it should be "Makevars"
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/extendr/extendr/issues/19#issuecomment-703832704, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAL36XHG7K6W4R6LX2VSDITSJILA3ANCNFSM4R6QYBPQ
.

But R seems to work only with .so. All R packages I installed have the .so file in their lib directory:
$ pwd && ls */libs
/Library/Frameworks/R.framework/Resources/library

Biobase/libs:
Biobase.so

BiocParallel/libs:
BiocParallel.so

Biostrings/libs:
Biostrings.so

DelayedArray/libs:
DelayedArray.so

...

I tried the r-rust/hellorust example noted by @lebensterben , and it outputted hellorust.so, not .dylib.

@andy-thomason
You could be right. But I think we still need a standard "Makevars". Note that R is using a dialect of standard "make".
Specifically, in 1.2.1 of Writing R Extensions

A Makevars file is a makefile and is used as one of several makefiles by R CMD SHLIB (which is called by R CMD INSTALL to compile code in the src directory)

The manpage of ?SHLIB shows that,

dllname: the full name of the shared object/DLL to be built, including
the extension (typically ‘.so’ on Unix systems, and ‘.dll’ on
Windows).  If not given, the basename of the object/DLL is
taken from the basename of the first file.

So I guess, it will correctly generate .so for both macOS and Linux.
Therefore, I suggest to use Makevars as other R packages are using.

Also froo Writing R Extensions, in section 5.5

If the src subdirectory of package contains a file Makefile, this is used by R CMD INSTALL in place of the R CMD SHLIB mechanism. make is called with makefiles R_HOME/etcR_ARCH/Makeconf, src/Makefile and any personal Makevars files (in that order). The first target found in src/Makefile is used.
It is better to make use of a Makevars file rather than a Makefile: the latter should be needed only exceptionally.

So using Makefile actually bypassed the R CMD SHLIB.

I could have sworn that I had seen the .dylib version working previously, but it's not now.  However, renaming to .so does indeed seem to work fine...

I could have sworn that I had seen the .dylib version working previously, but it's not now.  However, renaming to .so does indeed seem to work fine...

@dasmoth My proposal is to use R's native mechanism to deal with these stuff.
So let "R CMD SHLIB" do its job so we don't need to worry about ".dynlib" at all.

I've merged a PR that may make the hello example build on windows and mac. Please can you test it.

I've tried today's version on a Mac.  R CMD install . in the hello directory works fine.  However,
> library(hello)
> hello()
Error in .Call("wrap__hello") :
  "wrap__hello" not resolved from current namespace (hello)

...and...
macbook:hello thomas$ nm -g src/hello.so
                 U dyld_stub_binder

So it does look as though the Rust function isn't getting built into the .so file.
This could be down to MacOS linker behaviour.  Investigating...

It's linking hello.so with the following command.  Some of the paths will be fairly specific to how my machine is set up, but I would expect the gist of it to remain constant:
     clang -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/Cellar/r/3.5.1/lib/R/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/readline/lib -L/usr/local/lib -o hello.so empty.o -L../target/release -lhello -L/usr/local/Cellar/r/3.5.1/lib/R/lib -lR -lintl -Wl,-framework -Wl,CoreFoundation

Nothing from libhello.a is making it into the finished .so file.
If I add the (Mac-specific):
  -Wl,-force_load ../target/release/libhello.a

...I get a slew of warnings about hiding symbols, but do get a working hello.so which can be loading into R and call wrap__hello.  I'm not convinced this is the right way to do things, though, but maybe a starting point for someone who has a better rapport with the MacOS linker...

It seems that lld is being a bit too clever and not linking the static
library
because it is not referenced by empty.c.
The empty c file is needed for the semantics of R CMD SHLIB as this is set
up
for compiling C/C++ code.
Ultimately, we should want to just write lib.rs without any extra
attribution, but the
very manual process that R forces on us is hard to fight.
I would also like to be able to wrap Rust crates with the minimum of
attributes.
For example, we should be able to take a simple crate like md5 or crc
and
wrap it without modifying the source code. This means using syn to parse
the corresponding source tree, looking for exports.
For strongly templated libraries, we would have to pick particular impls to
wrap
Andy.
On Tue, Nov 10, 2020 at 8:15 PM Thomas Down<EMAIL_ADDRESS>wrote:

It's linking hello.so with the following command. Some of the paths will
be fairly specific to how my machine is set up, but I would expect the gist
of it to remain constant:
 clang -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/Cellar/r/3.5.1/lib/R/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/readline/lib -L/usr/local/lib -o hello.so empty.o -L../target/release -lhello -L/usr/local/Cellar/r/3.5.1/lib/R/lib -lR -lintl -Wl,-framework -Wl,CoreFoundation

Nothing from libhello.a is making it into the finished .so file.
If I add the (Mac-specific):
-Wl,-force_load ../target/release/libhello.a
...I get a slew of warnings about hiding symbols, but do get a working
hello.so which can be loading into R and call wrap__hello. I'm not
convinced this is the right way to do things, though, but maybe a
starting point for someone who has a better rapport with the MacOS linker...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/extendr/extendr/issues/19#issuecomment-724941664, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAL36XG7HD7PO2LT6BQ7VR3SPGNPTANCNFSM4R6QYBPQ
.

@andy-thomason: In case you haven't already spotted this: I'm actually getting exactly the same behaviour under Linux (i.e. .so is generated fine but doesn't contain anything from the cargo-generated .a file).  So not a Mac-specific issue.
Not entirely sure where to go from here.  Ideal might be to have the rust code compiled into .o files instead, so we can all the linking in a single step.  But it doesn't look like cargo supports compiling to .o files, and using rustc without cargo doesn't seem like my idea of fun.
One thing I assume would work (and be portable): rather than using "empty.c", generate a minimal C wrapper function for each exposed Rust function.  Ought to be possible to provide some build.rs boilerplate to scan the Rust code and generate matching .c.  But seems like a lot of overhead...

This is partly why I was avoiding the C file approach.
We will need a function to be called from the R code to init the .Call
interface anyway,
so a stock .c file might be all we need. Shame, though, it is a bit of a
mess.
R compiles to multiple .o files in an "ar" archive AKA a static library.
This is designed so that the linker can trace the exports through to
functions which are actually
used and eliminate (dead strip) unused functions.
The gnu linker was always terrible at doing this, which is why we had our
own linker
on the Playstation (the SN linker). lld, the LLVM equivalent has
inherited much of this
bad behaviour!
You could try, for example, an exported C function with:
extern void wrap__hello();

void *my_c_func() {
  return &wrap_hello;
}

Which may have the desired effect.
My current default Eoan llvm seems to work ok.
Andy.
On Wed, Nov 11, 2020 at 5:01 PM Thomas Down<EMAIL_ADDRESS>wrote:

@andy-thomason https://github.com/andy-thomason: In case you haven't
already spotted this: I'm actually getting exactly the same behaviour under
Linux (i.e. .so is generated fine but doesn't contain anything from the
cargo-generated .a file). So not a Mac-specific issue.
Not entirely sure where to go from here. Ideal might be to have the rust
code compiled into .o files instead, so we can all the linking in a single
step. But it doesn't look like cargo supports compiling to .o files, and
using rustc without cargo doesn't seem like my idea of fun.
One thing I assume would work (and be portable): rather than using
"empty.c", generate a minimal C wrapper function for each exposed Rust
function. Ought to be possible to provide some build.rs boilerplate to
scan the Rust code and generate matching .c. But seems like a lot of
overhead...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/extendr/extendr/issues/19#issuecomment-725540563, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAL36XDPA5OSVPOLH3LYTADSPK7QFANCNFSM4R6QYBPQ
.

C code along the lines of Andy's suggestion does indeed work (on both Fedora Linux and MacOS).
...and avoids the extra layer of function calls that the version I was thinking of would have added.

I'm going to close this. I think this is fixed in the extendr repo, but more importantly we now have a minimal working example here: https://github.com/extendr/helloextendr
It compiles on Linux and macOS and passes R CMD check on those platforms. Windows remains to be seen.


android: example app doesn't show remote participants video track

when running the example app in android, the remote participants can be heard but not seen.
the remote video track appears as if it was muted.
even if the remote participant mutes/unmutes his video or switches camera, it's never seen on the android app.
btw, the chrome version of the app can see the android video stream without problem.
this was tested on
client-sdk-flutter commit 28e7091325f6a692948037940065d02187a1dbb1
livekit-server commit c00d799ac6ebcfbdf32b48c886801f968a4e62c6

I found why this is happening, thinking what's the best solution now.


exclude /examples/.../node_modules/* directories from published module

From 1.2.1 to 1.3.1 the module size went from 9 KB to > 4,000 KB.
Presumably the huge bump in size of 1.3.1 is due to bunch of node_modules directories embedded into examples:
/examples/basic/node_modules/*
/examples/basic-handlebars/node_modules/*
/examples/basic-pug/node_modules/*
I only noticed because I ran into issues with filepath limits since the node_modules got nested so deep.

<EMAIL_ADDRESS>should fix this. Thank you for reporting.


Should SBE also generate a Car?

Regarding your example: https://github.com/real-logic/simple-binary-encoding/blob/master/sbe-samples/src/main/java/uk/co/real_logic/sbe/examples/ExampleUsingGeneratedStub.java
SBE generates CarEncoder and CarDecoder but no Car. I'm sure this is intentional and well thought through -- it follows your streaming access design principal.
But what about users who wish to pass around a Car once it's been decoded, are they meant to write a Car pojo and an adapter class which reads from CarDecoder and writes to Car? That code could be generated by SbeTool. Or perhaps even generate a Car which wraps an agrona buffer and accesses fields via offsets. Car could also be a flyweight, to avoid allocations.
Thanks in advance for clarifying your vision. Perhaps the strategy for a Car object is outside the scope of SBE, in which case I'd be interested in hearing your suggestion on what a typical, nice integration is between codecs and domain objects.

We used to generate a single object, eg: Car,  that did both encoding and decoding. Over time we decided that we would encourage better design (separating read-only view from mutation) by splitting out the encoder and decoder.
I suspect that Martin and Todd have well formed opinions on this, but from my perspective I would say that SBE should not be used for things like aggregate roots or entities in DDD terminology, but for things like domain events. In this case you're unlikely to do something like create a Car object and stash it in a map, so I'm not 100% sure this ability is needed.

@brianfromoregon  POJOs are a bit of an anti-pattern that have infected the Java world :-)
I like to map messages to method calls on an aggregate root in DDD, like @RichardWarburton has pointed out. The interface and mapping of parameters can be generated easily.
If you create POJOs then you are allocating which will greatly impact the throughput and response time of your application. SBE was designed for low latency financial trading where many applications are GC event free.

Totally agree with @mjpt777 and @RichardWarburton . Often it is a very bad idea to conflate the concern of parsing/filling with object lifetime. This is the real issue that I have with POJOs. So, doing something outside of SBE would be a great benefit. But within SBE wouldn't be the best way to do it.

It might be handy to collect some best practice examples of passing the SBE event/message/data through the app a bit in a GC-friendly way.
I think you're sort of doing this over in Amaethon project. For example amaethon.Auction looks like a flyweight-ish POJO which gets injected with SBE data pulled from Aeron. This is the sort of thing I'd like to do. Seems like the template class for amaethon.Auction could be generated by SbeTool as a starting point which can be extended by user. It may be handy if SbeTool generated it vs a different tool because SbeTool already knows how to use AuctionDecoder properly to hyrdate/reset/fill an Auction.

@brianfromoregon It would be good to write a sample service that uses SBE, Aeron, and good reactive style programming as an example to copy. Some day I hope to get the time to do that :-)

Checking in to see if any of you are aware of examples created in the past year, which show how to replace use of POJOs in an app as you describe.

Checking in to see if any of you are aware of examples created in the past year, which show how to replace use of POJOs in an app as you describe.

interested in examples too


"jsonc/no-comments" rule - [bug] some comments are ignored

It is possible to simulate the error with the code:
{
  /* hi */
  // test
  "name": "John"
}

or
{
  // test
  "name": "John"
}

or
{
  "name": "John",
  "test": "test",
  // test
  "test2": "test"
}

WebStorm has its own JSON validator, which means that WebStorm identifies the error because there should not be comments in a JSON file. However, the warning from eslint-plugin-jsonc does not appear. If you look at the terminal in the image, you will see the command to run eslint on the same file, and nothing happens because the error is not detected. Initially, I thought it was an error only with comments made at the beginning of the block, but that's not the case. I have managed to enforce the rule "jsonc/no-comments," but generally, it doesn't work.

Do you have {"rules":{"jsonc/no-comments":"error"}} in your configuration? If not, please add it.
If so, please share your repository.

Thank you for the response. Setting the rule directly worked... After some testing, I understood the problem. In the documentation example, 'plugin:jsonc/recommended-with-jsonc' is used. Since the library is called jsonc, I thought it would be the most obvious option to use to cover everything. However, further down it is mentioned that there are 3 recommended optional configurations, one for each type of JSON.
In other words, I misunderstood the documentation. So, to cover all 3 JSON formats, I need to do something like this:
module.exports = {
  overrides: [
    {
      files: ['**/*.json'],

      extends: [
        'plugin:jsonc/recommended-with-json',
        'plugin:jsonc/prettier',
        'plugin:prettier/recommended',
      ],

      rules: {
        'prettier/prettier': [
          'error',
          {
            files: ['**/*.json'],
            parser: 'json',
          },
        ],
      },
    },
    {
      files: ['**/*.json5'],

      extends: [
        'plugin:jsonc/recommended-with-json5',
        'plugin:jsonc/prettier',
        'plugin:prettier/recommended',
      ],

      rules: {
        'prettier/prettier': [
          'error',
          {
            files: ['**/*.json5'],
            parser: 'json',
          },
        ],
      },
    },
    {
      files: ['**/*.jsonc'],

      extends: [
        'plugin:jsonc/recommended-with-jsonc',
        'plugin:jsonc/prettier',
        'plugin:prettier/recommended',
      ],

      rules: {
        'prettier/prettier': [
          'error',
          {
            files: ['**/*.jsonc'],
            parser: 'json',
          },
        ],
      },
    },
  ],
};


Why is this still stuck on 1.0.0-SNAPSHOT

I don't want to be using the snapshot version of this lib, however the non-snapshot (1.0.0) stable version does not have the content_available flag.
Can the snapshot version be released if it's ready please

Ideally it should be 1.1.0-SNAPSHOT but nevertheless, looks to be this project is not actively maintained.


SNP-JSON format

From what I can see in the demo genomes, all vendors provide as chromosomal location, is there any reason why this isn't included a a property in the SNP-JSON.

@axdg File size mostly - some of the information isn't really that important to have in the file. AFAIK the chromosomal location can be looked up in the reference genome.

included now afaik


could you update for react-apollo 2?

^^

Hello Falison,
I've tried to upgrade react-apollo 2.1 (as a beta version).
Just implemented only Query part.
But I'm not familiar a bit with render-props code styles. This is not a good example enough. 😅
https://github.com/Cerberus/note/tree/react-apollo-2
PR is welcome 😄


ARROW-15414: [java] RangeEqualsVisitor does not work for BitVector

Please see: https://issues.apache.org/jira/browse/ARROW-15414

@liyafan82 Could you please review it? Really thanks! This problem is very similar to ARROW-13981


Branches Aren't Just For Birds

While running "Branches Aren't Just For Birds" I ran into a syntax bug;
I am using Git-it on Manjaro linux (installed from AUR, doesn't appear to be latest bits - but I also don't see that this particular issue has been addressed.) I created the appropriate branch, "add-SBS-MBUEL", added and committed the file to CONTRIBUTORS and the result from Verify is as follows:
Found branch as expected!
Changes have been pushed!
Error: ENOENT: no such file or directory, scandir '/home/mbuel/Documents/work/Projects/patchwork/contributors/'
This is appears to be failing because of case sensitive nature of *nix environments.
remote branch
https://github.com/SBS-MBUEL/patchwork/tree/add-SBS-MBUEL
local directory capture:
/home/mbuel/Documents/work/Projects/patchwork
ls
contributing.md  CONTRIBUTORS/  favicon.png  index.html  issue_template.md  LICENSE.md  patchwork-ss.png  readme.md  style.css  template.hbs
git status
On branch add-SBS-MBUEL
nothing to commit, working tree clean
AUR
Git-IT <IP_ADDRESS>-1 - I did look through the release history, and it doesn't appear this particular issue was fixed in later versions.

I am having this same issue.
I would only like to add that the patchwork repo I forked contained both 'CONTRIBUTORS/' and 'Contributors/' folders.

Same problem here. Seems to be a problem in branches_arent_just_for_birds.js:findFile.

@pintman - Looked at the suggested location, instead of fixing anything there, I think a better solution is to fix the instructions to be consistent, which is a clear source of confusion.

@pintman - Looked at the suggested location, instead of fixing anything there, I think a better solution is to fix the instructions to be consistent, which is a clear source of confusion.


Enable the wast::Cranelift::spec::simd::simd_align test for AArch64

wast::Cranelift::spec::simd::simd_address also passes, even though there aren't any changes specifically for it.
Note that this PR makes the assumption that execution happens in a little endian environment; currently the AArch64 backend doesn't seem ready to deal with big endian anyway.

Hmm, the CI seems to be hitting a test timeout (or just a really slow test -- our aarch64 tests run under qemu on the x86 CI hosts):
test wast::Cranelift::spec::start ... test wast::Cranelift::spec::start has been running for over 60 seconds
error: test failed, to rerun pass '-p wasmtime-cli --test all'

Not sure what's going on -- did tests pass for you locally?

I usually test with cargo test --all --exclude lightbeam. However, I run everything in an actual AArch64 environment - no emulation.

I re-kicked the tests; likely just a spurious issue then. If still not green then I can look into the timeout settings.

It appears there's a merge conflict now since we merged Joey's PR (#1801) -- sorry about that!

Now the build fails for reasons that are completely unrelated to my changes:
   --> crates/runtime/src/mmap.rs:185:55
    |
185 |         unsafe { region::protect(ptr.add(start), len, region::Protection::ReadWrite) }
    |                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `-D deprecated` implied by `-D warnings`

error: aborting due to previous error

error: could not compile `wasmtime-runtime`.

@akirilov-arm we've fixed the CI issue on master, so if you rebase, the tests should pass now. Sorry about all the trouble!

It's still not clear to me why there are failures - this is the only information that I find in the log:
2020-06-03T22:34:04.7756111Z error: test failed, to rerun pass '-p wasmtime-cli --test all'
2020-06-03T22:34:04.8390830Z
2020-06-03T22:34:04.8395010Z Caused by:
2020-06-03T22:34:04.8429995Z   process didn't exit successfully: `/home/runner/qemu/bin/qemu-aarch64 -L /usr/aarch64-linux-gnu /home/runner/work/wasmtime/wasmtime/target/aarch64-unknown-linux-gnu/release/deps/all-1543c4079f5cddb8` (signal: 9, SIGKILL: kill)
2020-06-03T22:34:04.9333419Z ##[error]Process completed with exit code 101.

In particular, the tests that my changes are supposed to enable pass.

@cfallin I'll give it another try after the recently merged test fixes.

I am unable to get any useful log output from the latest CI failure - it looks like a timeout?
I have also tried running the tests locally on a x86 machine with QEMU 5.0.0. I used the following command line (based on what CI is doing):
QEMU_LD_PREFIX=/usr/aarch64-linux-gnu cargo test --features test-programs/test_programs --release --all --exclude lightbeam --exclude peepmatic --exclude peepmatic-automata --exclude peepmatic-fuzzing --exclude peepmatic-macro --exclude peepmatic-runtime --exclude peepmatic-test --exclude wasmtime-fuzz --target aarch64-unknown-linux-gnu

Everything completes successfully.
@cfallin I am at a loss about how to proceed. It looks like everything is correct on my end and I am just blocked by CI issues.

Sorry the CI is being so temperamental... I kicked the jobs again; let's see what happens. If still an issue, I can ping some others who know more about our CI setup.

Job failed again with a segfault in qemu. Perhaps it's an issue with the qemu setup we have? We appear to be using version 4.2.0, according to the custom qemu build commands in our GitHub CI config. @alexcrichton , is there a way we could use a newer qemu? @akirilov-arm, is there a way you could try to replicate with 4.2.0 (to see if this is a qemu bug)?

FWIW segfaults in qemu I've found are typically bugs in qemu (and are somewhat common, especially with things like fanciful instructions). It should be easy enough to update the copy in CI by updating this URL, and if it's working locally with 5.0.0 updating CI should do the trick! If you've got trouble doing that though I'd be happy to help

@akirilov-arm I just rebased your commit on top of our qemu update -- let's see if this works.

FYI QEMU 4.2.0 works for me too. However, I have one remark - I didn't notice any segmentation faults in the old log, rather SIGKILL (it was the same error message as the one I posted above). Now, I am not familiar with the CI setup, but if I have to make a wild guess, I'd say we are running out of memory (and the OOM killer springs into action). Of course, I have no idea why any of the other PRs don't fail, including the ones that touch the AArch64 backend. As I said, that's just a wild guess.

Yeah it actually sort of looks like OOM of some form since I can't see logs from the builders. One possibility is to turn down the concurrency to just one on aarch64 tests, but otherwise it's probably ok to not enable the tests here just yet and we can figure out how to do that in CI later.

@akirilov-arm if you want to simply re-disable the test, I'm OK with merging this now; maybe open an issue for the SIGKILL-afflicted test and add a FIXME on the line that disables it?

OK, I will rework the patch, so that the vector element extensions go in (we need them for some upcoming changes; for example, I have already implemented what's necessary for simd_load_extend, but I have been waiting for this PR to get merged), but I won't enable any tests. Let's revisit them later.

Thanks!


[9.x] Test any() method on MessageBag

There was no test for any() method on MessageBag.

Please follow code formatting used by the rest of the framework.


Journey Maps

What is a journey map?
A journey map is an exercise you can do after you created your personas to walk them through a task they need to complete that may involve your application.   The reason we do this is because it exposes what is very necessary to make your app useable for people. Just saying something as simple as "Oh I made this thing, how do I show it to my team?" reveals that sharing should be a core component of your app and might need to get bumped up priority-wise.
Here are the Journey Maps for The Task Oriented and The Tinkerer personas. These are screenshots from trello. I will work ok a template for markdown.

Here's a Contributor & Maintainer Journey. We need to make sure there's project maintainer interaction in certain parts to make a successful experience.

@deathbearbrown, when you get a chance, could you publish these to the gh-pages branch like you did with the personas?

Done with 7b55501. Thanks @deathbearbrown!


App Service on Linux free tier

This page needs to be updated with information about App Service on Linux Free Tier and whether the free tier supports Web App for Containers or not.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ef9002ed-c817-c615-fe32-05ad4cc78b61
Version Independent ID: 72295255-8d90-a2c6-0995-0e1208fcdcab
Content: Introduction to App Service on Linux - Azure
Content Source: articles/app-service/containers/app-service-linux-intro.md
Service: app-service
GitHub Login: @msangapu
Microsoft Alias: msangapu;yili

@prajaybasu Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.
@msangapu-msft Hi Mangesh, could you please check this issue and update the document as necessary? Thank you.

This PR will address this issue: https://github.com/MicrosoftDocs/azure-docs/pull/31032

#31032 has been merged.
#please-close

@prajaybasu We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Fixes #34 - improved ecbuild consistency.

Note that packages that use this macro will get warning messages until
they update.   But should be strictly backward compatible with zero-diff in
all fixtures.
Note that this change also expands the esma_add_library() macro a bit.  E.g. one can now pass compiler definitions (e.g., -DMAPL_MODE) on the macro via PUBLIC_DEFINITIONS option.

oops - will fix ...

Query for @tclune: Should we see more warnings in GEOS at all with this? Or is the fact I don't see anything mean our CMake was well-written in re ecbuild

I have no suppressed all of the new warnings (by default).   To test for deprecated, use
cmake ... -DESMA_ALLOW_DEPRECATED=OFF

Probably not the best name for the flag.  And note, that I forgot to test the non-default before pushing, but no harm in the worst case.

Oh wow. Yeah -DESMA_ALLOW_DEPRECATED=OFF does indeed spit out a lot of warnings!
I'll do a quick test to make sure everything builds and runs and if so, I'll approve.

Okay. Something has gone wrong. If I try and build with make install:
[  3%] Building Fortran object<EMAIL_ADDRESS>[  3%] Building Fortran object<EMAIL_ADDRESS>[  3%] Linking Fortran static library ../../../../lib/libGMAO_pFIO.a
[  3%] Built target GMAO_pFIO
Scanning dependencies of target pfio_server_demo.x
[  3%] Building Fortran object<EMAIL_ADDRESS>[  3%] Linking Fortran executable ../../../../bin/pfio_server_demo.x
[  3%] Built target pfio_server_demo.x
Scanning dependencies of target pfio_collective_demo.x
[  3%] Building Fortran object<EMAIL_ADDRESS>[  3%] Linking Fortran executable ../../../../bin/pfio_collective_demo.x
[  3%] Built target pfio_collective_demo.x
Scanning dependencies of target MAPL_Base
[  3%] Building Fortran object<EMAIL_ADDRESS>[  3%] Building Fortran object<EMAIL_ADDRESS>[  3%] Building Fortran object<EMAIL_ADDRESS>MAPL_StringVector.F90(2): #error: can't find include file: types/deferredLengthString.inc
MAPL_StringVector.F90(6): #error: can't find include file: templates/vector.inc
make[2]: ***<EMAIL_ADDRESS>Error 2
make[1]: ***<EMAIL_ADDRESS>Error 2
make: *** [all] Error 2

What a weird issue to be associated with this change.   I built ADAS with all of the warnings, and the only change since then was this suppression.
Hmmm.    But I can at least see how it is relevant.


[Epic] Refactor generate_data.py to make it functional and simpler

[ ] Num_instructions/sdg_scale_factor currently is setup only for the freeform skills - we need some logic to split that value between contexts and grounded questions for grounded skills. https://github.com/instructlab/sdg/blob/main/src/instructlab/sdg/generate_data.py#L189
[x] The current state of this code doesn't generate grounded data - it treates them as freeform (#99, #98, #97)
[ ] We should move the sys_prompt and system roles and delineate that to data mixing step #95
[ ] Let go of legacy keys used for self instruct https://github.com/instructlab/sdg/issues/102

I'm not sure this epic captures anything that's still actionable. If there is something actionable not captured in an individual issue, please file an issue for that. Thanks :+1:


enhanced timing in emergency processing...

Currently, emergencies are checked only in the timer loop (default 50ms). One emergency can be sent immediately by using emcy callback, but from the second onwards this will not work because of emcy inhibit time. This patch adds emergency message processing to the timerNext_ms functionallity, respecting inhibit time and emergency queue.

emergency processing now affects CO_process() timerNext_ms
timerNext_ms is gets set when either a message is ready to send, but inhibit time is not elapsed or when a message was sent to re-check the queue
be aware that timer resolution is 1ms, whereas emergency inhibit time resolution is 100us. We round this up to the next ms.

superseded by "Merged Pull Requests"


⚠ Bofrost.de has degraded performance

In 7a9548a, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1066 ms

Resolved: Bofrost.de performance has improved in 134126c after 9 minutes.


download and save with a correct name

This config tiddler lets to download and save the projectify wiki (not plugin) with a pre specified name. At the moment it is downloaded with tiddlywiki.html name.
Ref: https://tiddlywiki.com/#Hidden Setting%3A Filename for Save Wiki Button

Awesome, thanks!

Awesome, thanks!


Webpack issues on node 4.0.0

Hi,
I recently upgraded to node version 4.0.0. and I am unable to run webpack.
I did a nom install -g webpack and installed it locally on my project. however when I run webpack command, it says command not found.

When you install with -g it actually shouldn't install it into your project's local node_modules folder.
So doing npm -g webpack should link the webpack binary into the same folder npm is linked to.
What OS are you using?

@joshikeerti, yes @despairblue is correct the -g flag means install this package globally on my machine. In the case where webpack is installed globally the binary must still be in your PATH on OSX, Linux or other Unix-like systems for you to have access to it.
If you run type webpack in your terminal I would imagine there are no entries of webpack in your PATH.

@joshikeerti Any luck with this? Please note that you can hit node_modules/.bin/webpack to trigger webpack installed locally to a project.

I have a similar problem.
If I run webpack in my terminal, return error zsh: command not found: webpack
but if I run node_modules/.bin/webpack it's work and build my app.
How can I fix that? Why webpack are not found?

@MacgyverMartins Do other globally installed packages work for you? Could this be a path issue? Have you set NODE_PATH at your zsh config?

@bebraw I think the problem happened because I was using nvm, and somehow, It doesn't work. Today I uninstall nvm node versions and install again using npm n. And the  webpack work great.
Sorry my bad english

Helpful npm package for this issue. Solved it for me using zsh.
https://www.npmjs.com/package/add-local-binaries-to-path


[meta] maintenance question

According to https://github.com/prettier/prettier-eslint/issues/949#issuecomment-1863321941, I'd like to take over to maintain this repo actively, questions:

Can you give me the owner role of this repository?
Can you give me the npm owner permission? My npm account is jounqin
I'd like to migrate the deveop and release workflow to changesets if I have the correct permission, will you reject such changes?
I'll add the funding section mentioned as the above issue, do you reject such changes?

I don’t seem to have permission to do so.
You have now been invited.
and 4. Feel free to make whatever changes you feel are improving the way maintainers work on the package, and how users are using the package. (For example, the testing setup is overdue some simplification.)

@fisker @sosukesuzuki Would you like to help us? See also https://github.com/prettier/eslint-plugin-prettier/pull/624#issuecomment-1868064833

I'm on vacation. I'll find time to make the change.

Added @lydell and @JounQin  as "Admin" of this repo.  Anything else to do?

Thanks @fisker!


add metric: "require approval from someone other than the last pusher"

https://github.blog/changelog/2022-10-20-new-branch-protections-last-pusher-and-locked-branch/
This would be part of a general feature for reporting on branch protections on the default branch.

This needs research to see if it's in the API.

Looking into this


Add a note about the need to set BuildKit to false when building myMicroservice Docker image

Problem encountered on https://dotnet.microsoft.com/learn/aspnet/microservice-tutorial/docker-image
Operating System: Windows 10
When running:
docker build -t mymicroservice .
I got the error message:
failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount138889191/Dockerfile: no such file or directory

This StackOverflow answer solved the problem, instructing to set BuildKit to false.
Please add a note about this requirement in the tutorial.

Thanks @OfirD1. Let me investigate if this has changed on the last few days since I've tested the tutorial almost two weeks ago.


Image classification errors when testing against training dataset

I have trained an image classifier on a dataset of images, but when I test out the mlmodel file on an iOS app using the same images that the image classifier was trained on, several images have incorrect classifications. What's the problem here? I was expecting that it would have a 100% accuracy against images that it was trained on.
My initial thought is that it has something to do with if the images were perhaps compressed as they were sent to the iOS device, but I'm not sure.

Hi @varunlakshmanan -
This is expected behavior. The image classifier is not expected to get 100% accuracy on the train set.
To learn more about the image classifier, see the How it works page in our User Guide.
I'm going to close this issue, but let me know if you have more questions.

Thanks for the link. If the classifier isn't expected to display 100% accuracy on the training set, I'm just curious why after training the classifier, the results matrix displayed an accuracy of 97% against the train set. In real use, it seems like the accuracy rate is closer to 80%.

On average the model will always preform worse on examples that it was not trained with. I assume that's what you mean by "real use". That is also expected.

Sorry, I think I wasn't clear. By "real use", I meant uploading the same training images from an iOS device (not using completely new images). I was just interested in why there's a discrepancy between the accuracy rate output and the actual accuracy rate when testing on the training set.

There shouldn't be a discrepancy. Can you paste the entire output of your call to image_classifier.create(...).

This is the output:

@TobyRoseman This is the output:

@varunlakshmanan - it's still not clear to what the problem is here.
You're training a Turi Create image classifier. Then exporting that model to Core ML. Then checking the accuracy on the training dataset with the Core ML model. There is a big discrepancy between that accuracy and the accuracy reported during training. Is that a correct summary of the problem?
I'm not seeing any Core ML output in your screenshots.

I'm going to close this issue due to inactivity. Feel free to reopen with the requested information.


Reading 0 points

Describe the bug
Hello,
I tried to convert a small OBJ file as a test (see attached) which comes from a large dataset for the city of Helsinki.
The Helsinki data can be found here:
https://bit.ly/2kzHjrh
After hitting the convert button the conversion process doesn’t even start and sits at “reading … 0 points”:
Expected behavior
Conversion process should have read the file and eventually produced the UDS file.
Desktop (please complete the following information):

Platform:  Windows 10 Home
Version: EuclideonVaultClient_Windows_<IP_ADDRESS>800

Additional context
Add any other context about the problem here.

This dataset is working as expected in the RC for 0.4.0 (expect the geozone isn't supported currently)


fixed language and simplified thank you notification

@SudharakaP what's blocking this one?

@SudharakaP what's blocking this one?

@alanna : Ah, I think this missed my attention, I normally get a code review approval before merging; it's review is assigned to @znarf and I'll make sure we merge this on Monday. 😄

@alanna OSC and OCF have dedicated templates we should make sure to update that one too.
There is also multiple other custom "Thank You" emails, if they're not maintained by their collective/host/community I think they should be deprecated. https://github.com/opencollective/opencollective-api/blob/main/templates/emails/

Let's rollback the changes about attached receipts. I personally think this section is making a good job at the moment and the proposed version doesn't improve experience for the user.

@znarf : I've reverted that section back to it's original state. 👍🏽

Cool, let's follow up on opensource and foundation as soon as possible.

@alanna @znarf : Done at https://github.com/opencollective/opencollective-api/pull/6150.

OK sure I agree about @znarf's comments, let's go with that.
We should make a clear decision about custom email templates - if we support them, we should build a way for the host admins to customise them directly. If we don't, we should deprecate them. Users really want these kinds of custom emails so I would advocate for properly supporting them if at all possible. It's hard to improve email templates if we're constantly trying to sync them up with the custom ones (maybe this is fine for you guys but I find it's confusing to keep track of).

@znarf : Noticed that we need to slightly change a test as well for this on front-end; https://github.com/opencollective/opencollective-frontend/pull/6491


Start reimplementing geometry in Cython

Classes which are computation-intensive, like Polygon and Point should be rewritten to Cython:
https://cython.readthedocs.io/en/latest/src/tutorial/cdef_classes.html

Or Taichi Lang: https://docs.taichi-lang.org/

Other alternatives:

numba
C, ctypes, CUnit
C++, pybind11

Hi @krzysztofarendt
Did you consider Mojo?
https://www.modular.com/mojo

Hi @Tokarzewski, yes, but it has some limitations which I don't like for this particular project: https://docs.modular.com/mojo/manual/python/
I want to:

keep as much code as possible in Python, to make it more accessible to other developers and easier to maintain
compile to machine code only modules which are critical for the performance (solvers, geometry)
be able to use these compiled modules from other Python modules (I don't want to rewrite everything)

Currently, you cannot call Mojo from Python, while calling Python from Mojo is possible but limited.
As for the other options:

numba is the easiest and it is very fast, but it only accepts a subset of Python, so I would have to rewrite a lot of code. I have been using it only with functions. I know it has some support for classes, but I have not tested it yet.
Cython is very mature and can compile most of regular Python code, so I could make changes incrementally. It is easier to learn by Python developers than C/C++.
C/C++ - if I have to rewrite parts of code to numba-compatible or to Cython, why not rewrite to C/C++ anyway? Easy integration with Python via ctypes, pybind11. On the other hand, it is further away from my goal of having as much as possible of the code in Python. It would also take me more time than both numba and Cython.

Another factor to take into account (Mojo not included, because it is not open source anyway):

@krzysztofarendt thanks for that awesome explanation. It seems to be too early for Mojo.

I could also recommend topologicpy.
It is a py library built on top of the OpenCASCADE C++ core that has
geometry, topology, graph functionalities and integrations with many other libraries and engines.

Very interesting project which would be potentially useful in my case, but it is licensed under AGPL3, which as far as I understand would force me to license my project also under AGPL3. I prefer to stay with the MIT license.

I decided to go with numba: https://github.com/krzysztofarendt/building3d/tree/numba

Merged.


[TS migration] Migrate 'AttachmentModal.js' component to TypeScript

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/25130
Tests

Start a chat

Click + icon

Add Attachment

Attachment should be sent

Open RHN

Go to your profile

Click on Avatar

Select new photo

Avatar should be changed

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Start a chat

Click + icon

Add Attachment

Attachment should be sent

Open RHN

Go to your profile

Click on Avatar

Select new photo

Avatar should be changed

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x ] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/25230417/fdc73736-3296-4153-a3df-72dd4011f35c

Android: mWeb Chrome
https://github.com/Expensify/App/assets/25230417/5ed5f17f-1830-4a5a-b4ac-7691b38060f4

iOS: Native
https://github.com/Expensify/App/assets/25230417/e64c7cd3-8c1b-4c59-b0a2-1220f7768559

iOS: mWeb Safari
https://github.com/Expensify/App/assets/25230417/834b39cf-d8d7-4779-bfa9-075091c62350

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/25230417/23b86cf6-b2fd-4f53-ae01-4a03734b72dc

MacOS: Desktop
https://github.com/Expensify/App/assets/25230417/8100c7ab-388d-41ea-aa82-886aa4e12540

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@c3024 comments resolved 😄

I am not able to add a jpeg attachment from composer. It works fine on main. Are you able to add attachment from composer?
https://github.com/Expensify/App/assets/102477862/2995106f-8d16-4aaf-93f3-301e8e5a945e

@c3024 all resolved, please recheck 😄

@blimpich its fixed, thanks !

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Cherry-picked to staging by https://github.com/francoisl in version: 1.4.33-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to staging by https://github.com/blimpich in version: 1.4.34-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
cancelled 🔪

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/blimpich in version: 1.4.34-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/francoisl in version: 1.4.34-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


systemctl start wazuh-indexer not working

I ve installed Wazuh on my virtuell Debian environment but when i give the last command systemctl start wazuh-indexer, i take the error in picture which i added.
Does anyone has any idea?
thanks

Have you checked the logs as suggested?

Yes but was not able to identify the error

[

]

@AlexRuiz7  Can you help

Check the service logs with on journald
journalctl --no-pager --since yesterday -xeu wazuh-indexer

Also, check the logs at /var/log/wazuh-indexer/wazuh-cluster.log
grep -iE "error" /var/log/wazuh-indexer/wazuh-cluster.log

Closed due to inactivity.


Publish New Listing is not working

| Support request? | yes
Dear Team,
i have installed the project in my local in that functionalities like PUBLISH NEW LISTING is not working
Giving error something went wrong.
please help me
thank you in advance
shivukumar

Here the answer of @atranaz for the same question you asked in an unrelated issue :
@mmshivukumar there is two type of listing publish producer 1st you set auto approved from param in this case every submitted listing automatically publish. 2nd is needed approval permission from an administrator. In this case when someone submits a list and waiting for administrator approve its list.

@mmshivukumar  I suggest you to describe precisely your problem.

i have the same problem. it show invalid address every time i click "publish your listing" button.
i haven't set up my google API key, does it really need google API to publish a listing. is there any way i can disable google API. Please help @cocolabssas .


The application in production mode does not find some plugins

Short description of the problem:
Compiled applications in production mode gives an error:

Storage: SQLite plugin not installed, falling back to WebSQL Make sure to install cordova-sqlite-storage in production.!

Install the t plugin: 'ionic plugin add cordova-plugin-calendar'

although these plug-ins are available at window.plugins.calendar and window.sqlitePlugin. If you build your application in development mode by putting the flag ionic-app-scripts build --dev, then the plug-ins found.
What behavior are you expecting?
Compiled applications in production mode should work with all the plug-ins included.
@ionic/app-scripts 0.0.36
Cordova CLI: 6.3.1
Ionic Framework Version: 2.0.0-rc.1
Ionic CLI Version: 2.1.1
Ionic App Lib Version: 2.1.1
Ionic App Scripts Version: 0.0.36
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Mac OS X Sierra
Node Version: v6.7.0
Xcode version: Xcode 8.0 Build version 8A219b

Thanks, we're tracking this over at ionic-native. If you're able to, I'd love to see your project. If you could zip up your app directory or put it on github for me, my email is<EMAIL_ADDRESS>I've had trouble reproducing this locally so a real live project would be immensely helpful (in that case, the .zip method would be preferable so I can get a snapshot of the app). Thanks!

Can you check this comment and see if this fixes it for you? https://github.com/driftyco/ionic-native/issues/602#issuecomment-254024940

Guys - this is my big mistake! I found that I start to work with plug-ins to confirm the readiness of the platform. Yet, why is this code was working in design mode!


feat(dapp-console-api): add support for contracts deployed by CREATE2

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#287  👈
#284
main

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

Join @tremarkley and the rest of your teammates on  Graphite


Hi, does anymore ahave expirience in creating custom tools for draw figures?

Hi, does anymore ahave expirience in creating custom tools for draw figures? I have some problems, i think i do how talks in documentation, but event's does'nt works. Please, help me.

Put your code in a gist and post it to the mailing list for discussion.


Refactor: improve the project readability

please merge to dev, and test in production. If it goes well, and then merge to main


Is Location extraction on the cards?

Amazing work with the update!
Any plans to extend it to support location extraction ? Would love to contribute!

Thanks @akki2825!
There are no immediate plans to support locations. Although geolocations are doable, postal addresses require another set of techniques (e.g. dictionary lookup), and the world of named places is pretty wild.


feat: Support Additional Metadata + CVSS Score Logic Update

Description
This PR introduces two changes:

Support for SeveritySource and DataSource as optional fields in the report data.
Updated logic for determining the "score" value.

The previous GetScoreFromCVSS logic consisted of:
•	check if “nvd” exists in the CVSS map and returns its score if found.
•	If “nvd” is not found, it returns the first vendor score found in the map.
Returning the first vendor score in the map could lead to discrepancies between the severity and the CVSS score value.
The updated GetScoreFromCVSS logic includes:
•	Takes severitySource and preferredSources as additional parameters.
•	Returns the CVSS score from severitySource (vendor) if it exists.
•	If severitySource (vendor) does not exist in the map, it looks for scores in the order of preferredSources. The order of preferredSources is derived from https://github.com/aquasecurity/trivy-db/blob/d23a6ca8ba04f8acaeac9b1d2e1c52c5242b2814/pkg/vulnsrc/vulnerability/vulnerability.go#L17
Before:
{
"fixedVersion": "1.33.0",
"installedVersion": "v1.31.0",
"lastModifiedDate": "2024-06-10T18:15:26Z",
"links": [],
"primaryLink": "https://avd.aquasec.com/nvd/cve-2024-24786",
"publishedDate": "2024-03-05T23:15:07Z",
"resource": "google.golang.org/protobuf",
"score": 5.9,
"severity": "MEDIUM",
"target": "",
"title": "golang-protobuf: encoding/protojson, internal/encoding/json: infinite loop in protojson.Unmarshal when unmarshaling certain forms of invalid JSON",
"vulnerabilityID": "CVE-2024-24786"
},
After:
{
"dataSource": {
"id": "ghsa",
"name": "GitHub Security Advisory Go",
"url": "https://github.com/advisories?query=type%3Areviewed+ecosystem%3Ago"
},
"fixedVersion": "1.33.0",
"installedVersion": "v1.31.0",
"lastModifiedDate": "2024-06-10T18:15:26Z",
"links": [],
"primaryLink": "https://avd.aquasec.com/nvd/cve-2024-24786",
"publishedDate": "2024-03-05T23:15:07Z",
"resource": "google.golang.org/protobuf",
"score": 5.9,
"severity": "MEDIUM",
"severitySource": "ghsa",
"target": "",
"title": "golang-protobuf: encoding/protojson, internal/encoding/json: infinite loop in protojson.Unmarshal when unmarshaling certain forms of invalid JSON",
"vulnerabilityID": "CVE-2024-24786"
},
Related issues

N/A

Checklist

[X] I've read the guidelines for contributing to this repository.
[X] I've added tests that prove my fix is effective or that my feature works.
[X] I've updated the documentation with the relevant information (if needed).
[X] I've added usage information (if the PR introduces new options)
[X] I've included a "before" and "after" example to the description (if the PR is a user interface change).

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Mark Dalton Gray seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@Hacks4Snacks Seems to look like it will this solve my irritation about score and severity which I questioned here 👍🏻  https://aquasecurity.slack.com/archives/C02KVB6AED9/p1717779723156139

@Hacks4Snacks Seems to look like it will this solve my irritation about score and severity which I questioned here 👍🏻 https://aquasecurity.slack.com/archives/C02KVB6AED9/p1717779723156139

Awesome! Just took a look at the linked thread and that is exactly what I'm targeting with this fix.

@Hacks4Snacks why did you close this?

Hey @kersten I appreciate the ping, this was inadvertent. I will be raising again.


bad memory leak

Hello, I'm having a bad memory leak in production after implementing nsfwjs. I'm talking gigs of memory.
const axios = require('axios')
const tf = require('@tensorflow/tfjs-node');
tf.enableProdMode();
const nsfw = require('nsfwjs');
const modelFunc = async () => await nsfw.load();
let model;

setInterval(() => {
    tf.disposeVariables()
console.log(tf.memory()) // { unreliable: true,  numTensors: 49, numDataBuffers: 49, numBytes: 532830292 } and keeps increasing
}, 5000)

async function scan(url) {
    if (!model) {
        console.log('no model, loading.....')
        model = await modelFunc();
    }
    const pic = await axios.get(url, {
        responseType: 'arraybuffer',
    });
    tf.engine().startScope();
    const image = await tf.node.decodeImage(pic.data, 3)
    const predictions = await model.classify(image)
    image.dispose()
    tf.engine().endScope();
    return predictions;
}

for (const nsfwURL of [...(alex000kim / nsfw_data_scraper_chunk_ofurls)]) { //a chunk of nsfw image urls
    scan(nsfwURL).then(e => console.log(e))
}

I sometimes get TypeError: Cannot read property 'backend' of undefined; (@tensorflow/tfjs-core/dist/tf-core.node.js:3280:31)
Either way, the memory is never free'd.
What am i doing wrong?

It's a bit confusing the way this is constructed, but I see you're doing a lot of good things.
The thing I'm confused by, is why are you tf.disposeVariables() on an interval?   Does that cause the model to have to reload?
I'm not familiar with startScope/endScope.  Are you sure you should be managing the global engine like that?
Do you have an open source GitHub repo you can link me to, so I can pull down the code and run it and see if I can fix it?

@GantMan It's actually a worker that exposes the "scan" function, the loop part is just to show how I'm supplying the urls.
I used tf.disposeVariables() in an interval just to see the effect it would have on memory and also the results of tf.memory();
I had tf.memory() return a VERY high numTensors number (over 500). tf.disposeVariables() reduced it and only few are returned now (around 50); The memory leak however wasn't fixed.
<image>.dispose() ( or tf.dispose(image) ) had absolutely no effect sadly.
As for tf.engine().startScope() and tf.engine().endScope(), I noticed online:

The way to clean any unused tensors in async code is to wrap the code that creates them between a startScope() and an endScope() call.

I do admit, the two might be the cause of the error I had mentioned above
Either way, the memory leak was never resolved.
The code shown above is enough to actually reproduce this behavior on node

Hrmmm, TBH, I'm not seeing the source.  Perhaps the model is getting created over and over?   You could try model.model.dispose().  But I'll have to create a downloadable runnable debuggable demo to find it.   I don't think it's the library, but I could be wrong, of course!  Strange stuff indeed.
If you have a small, open source, ready to run demo I'll pull it down and throw an hour at it.
If I were you, I'd comment out line by line and watch tensor memory with a log.

Was this resolved?

Was this resolved?

I have same problem with this too. The `image.dispose()` seems doesn't work.

Can I see some code?  Are you using ts-node?

disposeVariables

i am having this issue, any solution ?


Platform specific email subject format for feedback

Email subject format is e.g. Feedback for iOS Vocable 1.2.0-503

Updated.


Getting started guide

Add something similar to https://github.com/extism/go-sdk#readme

Done in #13


UI will get busy with so many vendors and osps

The web user interface is going to get very busy as we can see hints of from the cw49 build deployments containing 6 new vendors and osps. We need to allow for rapid access and filtering but enable user (including myself) to see the full range of resources and dynamically handle rapid index additions.

single view web launcher has been scoped out as one option even in absence of user profile
user profile has been modelled in sql and in prototype spring data project but not integrated here yet
rapid scrolling, mobile-view handling, medium-based ui options need to be explored. This is NOT my strength so I will ask some UI friends for help on ways to make navigation easier and less clunky
the current ui uses bootstrap and resizes on mobile hardware we tested on, but even the new additions will start cluttering things up especially in the search-and-store build with the CRUD options

from an engineering perspective, we can look at JSON-generated view, to allow dynamic generation of view based on json-list of vendors/osps (same as we dynamically generate UI labels from google cse json api)

closing for now as this will not get looked at. Based on own workflow demands, vendelligence will be customized to tackle a subset of vendors and osps based on my daily needs. I personally do not need a fancy ui for the task; this one works fine for me for now. I will look at a json-generated view as that is something I can fairly easily construct.


Options Dialog Box Sizing and Size Persistence Issues; Resetting of Settings Files

XmlNotepad ver. <IP_ADDRESS> / Windows 10 Pro ver. 22H2, build 19045.3930
Chris:
Options Dialog Box Sizing and Size Persistence Issues;
The Options dialog box (View > Options) has the following issues:

While the Options dialog box can be resized and relocated once opened, its size does not persist, even within the same XmlNotepad session (the next opening of the dialog box will have its upper left corner at the location of the upper left corner of the last closed dialog box, but its size will revert to the default size).

While the Options dialog box can be made wider (by grabbing a vertical border), taller (by grabbing a horizontal border--note that there is no visible bottom border), but the invisible bottom border can be grabbed), or both (by grabbing the lower right hand corner resizing marker), this is a one-way operation: once made taller or wider, the dialog box cannot be made less tall or less wide (of course, given that this resizing will not stick at this point beyond the current display of the dialog box, this is not really an issue, but if no. 1 above is fixed, it may be, and worse so).

Resetting of Settings Files:
Also, I am finding that both my Roaming AppData XmlNotepad.settings file and %StartupPath%Resources  XmlNotepad.Template.settings file get reset to default (the former occurring more frequently than the latter) under circumstances of which I am not yet sure. I will try to determine what those circumstances are and report what I find. At this time, however, I know that this happens. My only non-default settings (other than Options dialog box size and location) are the editor and the font and font size).
General Thanks:
Finally, as a longtime user of the 2007 XML Notepad application, thank you, Chris, for the work you have done to reinvigorate it!

Good bug about the options dialog, thanks.  I pushed a fix that makes the option dialog remember your size (but only if it is larger than the default size because that ensures something is visible and window is not super tiny).  Then it lets you resize as much as you want.  I also fixed the preservation of the window location so it is relative to the location of the Main Window.
I also decided to remove preservation of the find dialog size because there are actually 4 different sizes to remember depending on whether you are doing find, replace, and with XPath setting checked or unchecked.  Preserving one size can make these other versions of the find dialog really ugly and or dysfunctional (info clipped).

Ok I published new version, so this is fixed in <IP_ADDRESS>
The Resetting of Settings Files I have not been able to reproduce, perhaps a bug in windows roaming feature, to moving to local only?


MINOR: Reduce (hopefully) flakiness of testRackAwareRangeAssignor

I have looked at the recent failures of this test and they are always at the same place (L252 before this change). Therefore, I suspect that the partition assignment may be the cause. This patch add logic to wait until it completes before proceeding. Let's see if it helps.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

The test still fails. There is likely something else going on... I will keep investigating.


add link to community blog post

Description (required)
This adds a link to a community blog post for building a single page app (SPA) in Astro with React router.
I think the best place for this (for now?) is on the Create React App page.

!coauthor


Is this library maintained?

A lot of open PR and issues havent had any comment or reaction. Is this library maintained or should we move on from it?

It looks like this isn't being maintained anymore. 2 years since last commit sadly.


No module named 'rasa_core'

Rasa Core version:0.11.12
Python version: 3.6.3
Operating system (windows, osx, ...):MacOS
Issue:
I'm trying to run python train_online.py. And I get the following Error :
"  File "train_online.py", line 8, in
from rasa_core.agent import Agent
ModuleNotFoundError: No module named 'rasa_core'"
Installation from rasa_core was successfully. When I type in "show rasa_core" I get the response:
"Name: rasa-core
Version: 0.11.12
Summary: Machine learning based dialogue engine for conversational software.
Home-page: https://rasa.com
Author: Rasa Technologies GmbH
Author-email<EMAIL_ADDRESS>License: Apache 2.0
Location: /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages
Requires: slackclient, numpy, scikit-learn, flask-cors, redis, rasa-core-sdk, pytz, python-socketio, terminaltables, six, gevent, pykwalify, apscheduler, mattermostwrapper, rasa-nlu, tqdm, pymongo, twilio, python-telegram-bot, fbmessenger, jsonschema, coloredlogs, pyyaml, flask-jwt-simple, h5py, graphviz, colorclass, keras, pika, ConfigArgParse, python-dateutil, flask, packaging, jsonpickle, requests, rocketchat-API, typing, colorhash, ruamel.yaml, tensorflow, PyInquirer, networkx, future, fakeredis
"
Content of domain file (if used & relevant):

### while installing rasa_core using pip install rasa_core getting the error.
ERROR: tensorflow-cpu 1.15.0 has requirement tensorboard<1.16.0,>=1.15.0, but you'll have tensorboard 1.13.1 which is incompatible.
ERROR: rasa 1.7.4 has requirement cloudpickle~=1.2.0, but you'll have cloudpickle 0.6.1 which is incompatible.
ERROR: rasa 1.7.4 has requirement fbmessenger~=6.0, but you'll have fbmessenger 5.6.0 which is incompatible.
ERROR: rasa 1.7.4 has requirement jsonschema~=3.0, but you'll have jsonschema 2.6.0 which is incompatible.
ERROR: rasa 1.7.4 has requirement matplotlib~=3.0, but you'll have matplotlib 2.2.5 which is incompatible.
ERROR: rasa 1.7.4 has requirement packaging~=19.0, but you'll have packaging 18.0 which is incompatible.
ERROR: rasa 1.7.4 has requirement pika~=1.0.0, but you'll have pika 0.12.0 which is incompatible.
ERROR: rasa 1.7.4 has requirement python-socketio>=4.3.1, but you'll have python-socketio 3.1.2 which is incompatible.
ERROR: rasa 1.7.4 has requirement pytz~=2019.1, but you'll have pytz 2018.9 which is incompatible.
ERROR: rasa 1.7.4 has requirement redis~=3.3.5, but you'll have redis 2.10.6 which is incompatible.
ERROR: rasa-sdk 1.7.0 has requirement ConfigArgParse>=0.14, but you'll have configargparse 0.13.0 which is incompatible.

@guneet999 i think pip installs the correct requirements after showing these errors itself


Order of some yarn command args

I've noticed that in many locations you guys use yarn add global *package-x*. This will install the package global and the package package-x. As pointed in the yarn docs. I suppose this is not the intended behavior.

Expected Behavior
Globally install a package

Current Behavior
Install two packages:

Package named global
Package specified

Possible Solution
Change the order of the arguments. Like this:
$ yarn global add package-x

You are right, this should be fixed in the docs. I need to so some checks as well if it's still necessary to install gulp 4 globally as the preferred way would be to just have it as a local dependency.

Well... Since you have everything on your scripts node in the package.json, you could avoid installing a global package and the package.json would point to the local gulp version (if it is indeed necessary to have it).

I initially had some issues with the local gulp setup but at this point I can't exactly remember what it was. However, a few simple tests will shed some light on this.

Was fixed in #353


As a team, we need to create a relayer task to call the processFromRoot function

From epic #1808

Should use the send() transaction hash (hash that generated the L2 → L1 message) to grab the message associated with an outboundRoot from subgraph
Should use optimism sdk to generate proof
Should call processFromRoot via Gelato

P0


Expr#show: Don't crash when the expression contains an unsupported type (like a SkolemType)

When the SkolemType appears as the prefix of a TypeRef, we avoid it by using qualifier which is defined in QuotesImpl to widen skolems, but skolems can appear in any position, and so before this change we would get a compiler crash in the added test case where the skolem appears as the prefix of a TermRef.
We fix this by adding fallback cases in the quotes pretty-printer, now for the test case we get:
Test.f.ho(((arg: <<SkolemType(693709097) does not have a corresponding extractor> does not have a source representation>.x.type) => arg))

Which isn't great, but better than a crash.
Maybe we should run Type#deskolemized on a type before trying to print it in SourceCode/Extractors, but currently these files are intentionally defined to not depend on compiler internals and do not have a Context so we cannot even call deskolemized on them.
Alternatively, maybe SkolemType should be a tasty-reflect constructor but that would also be a pretty big change.

This code was intentionally made to crash to ensure that users would report these issues. If we print them as a string, there is the danger that bugs will go unreported.

Maybe we should run Type#deskolemized on a type before trying to print it in SourceCode/Extractors

A more complete way to deal with these would be to descolemize all the types before they are given to the user as a Type or TypeRepr. This might be computationally expensive and fragile.

The problem with a crash is that it makes it hard to diagnose unrelated issues. It even breaks using -Xcheck-macros when it tries to print something

Maybe reporting a warning with explicit instructions to report the issue in the fallback print case would be enough? Outside of this issue with printing/reporting, I'll try to figure something out for SkolemTypes specifically, maybe deskolemizing only if we need to will not be that bad

maybe deskolemizing only if we need to will not be that bad

The problem with deskolemizing in the error is that it can be actively misleading: it's possible my macro doesn't work just when skolems are involved, so if I try to print types for debugging and the compiler hides the skolem from me, then I'm going to be very confused and won't be able to find the root cause of my macro issues.
I think that fundamentally, trying to hide some types from the user just does not work: the abstraction is leaky, and it leads to unsolvable issues when the user cannot match what the compiler expects.


Add LLVM libc sample

This will be built into the LLVM libc overlay package. Sample installs to samples/src/llvmlibc/baremetal-semihosting.

Add llvmlibc-samples directory to contain LLVM libc specific samples.
Add single baremetal-semihosting sample using LLVM libc.

Sample contains a number of calls to LLVM libc functionality:

heap.
printf.
string library.
math library.

A special linker script is used to set the bounds of the heap. This uses different linker defined symbols to picolibc.
The crt0.S from the existing llvmlibc-support can't be used directly as the RW and ZI from the linker script need initializing.

What's the motivation for using a separate directory structure instead of placing the new samples inside the existing samples directory?

What's the motivation for using a separate directory structure instead of placing the new samples inside the existing samples directory?

A couple of reasons, neither particularly strong:

Easier to avoid name clashing with the existing picolibc samples as the overlay package is developed separately. This could be resolved by explicitly adding llvmlibc to each sample name, for example baremetal-semihosting-llvmlibc.
It made it easier for me to remove the llvm-libc samples when repeatedly testing the package, but I think that's resolvable.

I'm open to opinions on what's best?

For consistency I'd suggest keeping everything under samples. It also helps to keep the directory structure simple and clear.
Could we maybe have separate sub-sirectories inside samples for each library package we provide? E.g.:
LLVM-embedded-toolchain-for-Arm/
├─ samples/
│  ├─ picolibc/
│  ├─ newlib/
│  ├─ llvmlibc/
├─ ...

Are you OK with me doing that in a follow up change as this one currently only affects the overlay package?


vs code prevents the parent shell from exiting

VSCode Version: Code 1.12.2 (19222cdc84ce72202478ba1cec5cb557b71163de, 2017-05-10T13:20:36.315Z)
OS Version: Windows_NT ia32 10.0.14393
Extensions:

Extension
Author
Version

Bookmarks
alefragnani
0.15.1

python
donjayamanne
0.6.4

xml
DotJoshJohnson
1.8.0

cpptools
ms-vscode
0.11.4

csharp
ms-vscode
1.10.0

Steps to Reproduce:

start from a shell window (ex: code .)
type "exit" in the shell
the console window will not close

What type of shell? (Powershell, CMD, bash....)

I noticed the issue with cmd first, but it reproduces with powershell as well (so it seems related to conhost, not the shell itself)
Another thing I noticed after trying it on a few different configurations: at some point I wasn't able to reproduce it a few times, then it started reproducing after opening the lower pane in VS Code.

after opening the lower pane in VS Code.

What do you mean?

Ctrl-J in the default keyboard mapping.
On Jun 14, 2017 1:40 AM, "João Moreno"<EMAIL_ADDRESS>wrote:

after opening the lower pane in VS Code.
What do you mean?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/28159#issuecomment-308363637,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANLyKYBworT4zntCnLSTzOauH51vIUuDks5sD5xtgaJpZM4NyJ_S
.

@tlemo can you post a screenshot after you types exit and it didn't exit?

nothing spectacular:

I think this is more an issue with cmd.exe, not VS Code.

I'm pretty sure that cmd.exe exits just fine most of the time... unless an app does something funky like holding onto a handle perhaps... ? I hate to speculate and I don't have the time to investigate right now, but something is definitely not qute right.


Update support/example for ESP32-C3 to use latest versions of dependencies

This updates the rtic and rtic-macros packages to handle some changes which have been made since support for the ESP32-C3 has been updated last. It additionally updates the sw_and_hw example for this device, which I have tested and verified using a ESP32-C3-DevKit-RUST-1 v1.2a board.
If there are any questions or concerns please let me know, I'm happy to make any requested changes.
This supersedes #973 as well, so that can be closed when/if this is merged.

I'm not sure what you'd like me to do about the QEMU failure, I would not expect this output to stay consistent (as we're seeing with this failure).

I've fixed up the QEMU expected output, applied my suggestions and opened a PR on your fork.

i see my review is set as pending, so i'm not sure if you can see my comments. in any case, i see now what you were saying about QEMU, the output does not match what is expected, and what actually happens when running on a board

I agree, it's probably worth keeping the checks around, however perhaps being a bit less strict with regards to the bootloader output would be best.
Anyway, with your changes merged CI is green here now at least, so thanks for that!

i guess i just forgot to press submit, the comments are now outdated but i will leave them here for the record.

Great work, thank you!
I just merged some changes from @onsdagens , could you double check this PR is still OK?
E.g. I was there was a reference to esp32c3 v0.22 in rtic-montonics now as well.

Thanks for taking a look. I have rebased my branch locally but am running into some issues with the monotonic example; will investigate further.
Might take me a few days to get to this, lots going on right now for me :)

Thank you, no rush!

I've resolved the issues I had encountered with the monotonic example, seems to be working correctly now.
Unfortunately, again we are having issues with the checks on the QEMU output. Happy to make whatever changes here, but I am not very familiar with these checks so am not sure how best to resolve this long-term.

I agree z

I've resolved the issues I had encountered with the monotonic example, seems to be working correctly now.

Awesome! :rocket:

Unfortunately, again we are having issues with the checks on the QEMU output. Happy to make whatever changes here, but I am not very familiar with these checks so am not sure how best to resolve this long-term. I think that the bootloader output can probably be ignored entirely in the QEMU checks.

I agree, bootloader is not the main part. Do you want to attempt implement the ignoring of bootloader output, or should we join forces on that one?

Do you want to attempt implement the ignoring of bootloader output, or should we join forces on that one?

Would be great if I could get a hand with that, please. New project at work will be consuming a fair bit of my brainpower and time for at least the next couple weeks here.

Thank you for wrapping this up!


Content-Length is calculated incorrectly with UTF-8 2-byte characters

What version of Elysia is running?
1.2.1
What platform is your computer?
WSL Ubuntu
What steps can reproduce the bug?
import { Elysia } from "elysia";
import { node } from '@elysiajs/node'

const app = new Elysia({
    adapter: node(),
})
    .get('/api/v1/tasks', () => {
        return {
            "utf": "ú"
        }
    })
    .listen(3000);

Open http://localhost:3000/api/v1/tasks
What is the expected behavior?
Browser output:
{"utf":"ú"}

What do you see instead?
Browser output:
{"utf":"ú"

Additional information
reported on discord
Have you try removing the node_modules and bun.lockb and try again yet?
yes

Workaround:
import { Elysia } from "elysia";
import { node } from "@elysiajs/node";

const app = new Elysia({
  adapter: node(),
})

  .get(
    "/api/v1/tasks",
    () => {
      return {
        utf: "ú",
      };
    },
    {
      mapResponse(ctx) {
        const response = JSON.stringify(ctx.response);
        return new Response(response, {
          headers: {
            "Content-Type": "application/json;charset=utf8",
            "Content-Length": Buffer.byteLength(response, "utf8").toString(),
          },
        });
      },
    }
  )
  .listen(3000);


add count-empty-rows arg

fixed bug when only 65k rows are processed in .xlsx file created by open office etc.

added  --count-empty-rows to calculate or not empty rows inside the operation area

Thank you @Wampirusy
I added new tag 0.5.11 for this fix - in few minutes Composer will collect new version and you will be able to update your project


independent caddy-docker versioning

It would be great if this container was tagged in a way that updates to this repo didn't mutate tags on dockerhub.  We've been using the 0.9.1 tags of this repo for a while, and recently ran into a problem where one of our containers failed to restart.
It turned out the 0.9.1 tag was mutated when you switched from running as root to running as caddy, and the restart caused the latest version to be pulled, which was incompatible with our setup.

Hi, this was a big blunder from me and it is not gonna happen again. Even the breaking change has been reversed as many users had volume permission issues.
You can use 0.9.3 now and tags are henceforth immutable.
Really sorry about that.

You can check https://github.com/abiosoft/caddy-docker#saving-certificates for some tips.