'force' parameter not working in 'add' and addMany' actions

Plop v2.3.0 - Win10
Using this action in my plop generator:
    {
      type: 'add',
      path: '{{projectLocation}}',
      templateFile: './templates/microservice-dotnet-servicefabric/MyCompany.{{name}}.sln',
      force: true
    }

Results in this error:
×  ++ Cannot delete files/folders outside the current working directory. Can be overridden with the `force` option.

A few things:

Is {{projectLocation}} available within the handlebars data or is it a local variable? If it's a local variable, handlebars won't know about it.
You're using a handlebars template value in your templateFile path, make sure that it is correctly resolving to a file that exists.
All paths are (by default) relative to the plopfile path. So, if your plopfile is in your project root, you may not need to specify "projectLocation".

1. Project Location is supplied as a prompt. It's available and working in other actions.
2. The filename is named ./templates/microservice-dotnet-servicefabric/MyCompany.{{name}}.sln
Maybe this is the problem? This format works with the addMany action, since it matches a glob pattern and when the file is moved, it is also named. Perhaps it doesn't work the same way in add
3. Path is presently being used to specify the destination location.

Ah, I see. So, it looks like this is probably an issue with your path pointing to a directory instead of a file path. The add action expects path to be the exact path (including filename) that the file should be generated as.
So if you change path to include "/Carvana.{{name}}.sln" at the end, it should work.

That still doesn't seem to work.

looks to me like this is a constraint with the del package not wanting to remove things (overwrite) outside of the cwd. We likely need to pass the plop force value into del in order to make this work.


Enable BO3 trees to be generated at different heights

This enable to generate trees at different heights when SpawnHeightOffset and SpawnHeightVariance in BO3.

Nice idea, but I think the implementation could be better. You now have lots of blocks like this:
                 if(tree instanceof BO3)
                 {
                    if(((BO3) tree).spawn(world, random, spawnX, spawnZ))
                    {
                        // Success!
                        return true;
                    }
                 }
                else
                {
                    if (tree.spawnForced(world, random, rotation, spawnX, y, spawnZ))
                    {
                        // Success!
                        return true;
                    }
                }

How about adding spawn(world, random, spawnX, spawnZ) to the CustomObject interface instead? Then you don't need to cast to a BO3 first. (A better name for this method would probably be spawnInColumn.)

Hi @hexosse can you compile the plugin for me with this feature? i have TerrainControl 2.7.2

@rutgerkok : I didn't want to change the CustomObject interface in a first place. This would have an impact on all generated structures? I'll try and propose a new commit to this PR.
@agusztin : which version of bukkit is 2.7.2

It will not affect other structures if the code in the new spawn method is equivalent to the old code that was outside the method. It requires some care, but it results in much cleaner code.
If you're having trouble, just leave a message here, and I'll see what I can do.

@hexosse Server version: This server is running CraftBukkit version git-Spigot-21fe707-e1ebe52 (MC: 1.8.8) (Implementing API version 1.8.8-R0.1-SNAPSHOT)
TerrainControl Version: 2.7.2

I don't find a good way to do it.
In fact, I don't understand few parts of the code yet.
The process function could be used for it, but it use frequency and rarity which should be ignored for Tree(..), Sapling(..) and CustomStructure(..)
I don't think that adding a new function is a good point as there is already many spawn functions (spawn, spawnInChunk, process)


Generate module builders

Usage:

run from the root directory go generate modules/modules.go before building the app
or just make modules

This approach looks good to me.

New PR: #21
This one was closed accidentally due to removed base branch.


System.OutOfMemoryException while executing RetrieveEntityChanges request

I am trying to retrieve Email records using RetrieveEntityChanges request and getting about 5000 records each time and getting System.OutOfMemoryException
Message: Failed to allocate a managed memory buffer of 134217728 bytes. The amount of available memory may be low. Exception of type 'System.OutOfMemoryException' was thrown.
I can say large amount data is due the description column of Email record.
Note: I am using P3v2 configuration for Azure Functions hosted inside Azure app service.
If I reduce the page count to less, it works.
But I would like to understand is there a way if I can change the code so it can retrieve large amounts of data in each request?
Error message:
System.InsufficientMemoryException:
at Microsoft.PowerPlatform.Dataverse.Client.ServiceClient.Execute (Microsoft.PowerPlatform.Dataverse.Client, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at DES.FunctionApp.Helpers.EntityChangesHelper.RetrieveEntityChanges
Inner exception System.OutOfMemoryException handled at Microsoft.PowerPlatform.Dataverse.Client.ServiceClient.Execute:
at System.Runtime.Fx.AllocateByteArray (System.Private.ServiceModel, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)

The limitation you're running into there is the Host process, not the client.
In this case your Azure function host is limiting you.  You can scale it up if you want more memory for your process.
That said, retrieving large volumes of data in one shot is not efficient nor effective.  You're going to face limitations on your process and on the request response time to process that much data.   We generally guide folks to use smaller result sets (under 500-1K rows depending on width) and paging to get better performance. it also aids in processing as you can yield the results of your retriever to a separate thread doing processing while the retriever is still running if you want to invest that level of effort into your program.
Though without knowing what you trying to achieve here its hard to guide you .

Hi Mat,
Thanks for the reply.
I am trying to sync Email data from CRM into another external storage such as Azure SQL.
If I want to quickly finish the sync process, then I need to increase the record count per page.
Can you please suggest some options on how to increase Azure function host memory?
Currently I am using P3V2 app service plan which is max. available for an Azure app service.
Thanks
Anil
Sent from Samsung Galaxy smartphone.
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: MattB @.>
Sent: Saturday, July 22, 2023 9:25:56 AM
To: microsoft/PowerPlatform-DataverseServiceClient @.>
Cc: Anil Kumar MSFT @.>; Author @.>
Subject: Re: [microsoft/PowerPlatform-DataverseServiceClient] System.OutOfMemoryException while executing RetrieveEntityChanges request (Issue #390)
The limitation you're running into there is the Host process, not the client.
In this case your Azure function host is limiting you. You can scale it up if you want more memory for your process.
That said, retrieving large volumes of data in one shot is not efficient nor effective. You're going to face limitations on your process and on the request response time to process that much data. We generally guide folks to use smaller result sets (under 500-1K rows depending on width) and paging to get better performance. it also aids in processing as you can yield the results of your retriever to a separate thread doing processing while the retriever is still running if you want to invest that level of effort into your program.
Though without knowing what you trying to achieve here its hard to guide you .
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerPlatform-DataverseServiceClient/issues/390#issuecomment-1646623614, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACKHCCTCWL2WWBWGOFJ6LGDXRP5JBANCNFSM6AAAAAA2TP63ZU.
You are receiving this because you authored the thread.Message ID: @.***>

That your running out of memory likely indicates your trying to read too much into memory at once,
Again without understanding what your doing, I would look at batching operations with smaller record-set lbs and threading

Going to close this at this time, due to no activity.
thanks


replace  {field} also on errorField

It does'nt work as intended. The translation should be as in english, with not field name from The {field}... to This field....


New features regarding premium user

Premium feature needs to be implemented. User database should be reconstructed to add role (premium vs free user). Premium has the power to change the posters of movies. Following that, they should have a credit amount. Each change they make is credit deducted from their account. Admin role should be added to regulate the buying and selling of credits. A page for selling credit bundles should be created, with that the check out page, with payment methods, security,.....

Would be cool if there are more features for people who pay, maybe trailer access or something like that

done


One line install script doesnt seem to work anymore

During the installation with the "one line install command" there are several "Fehlschlag beim holen von xxx" notices (see CLI output in the attachment).
Setup raspian OS buster on SD card. Put SD card in an Raspberry Pi 3 Model B. Connected via PuttY-->SSH2 to Pi3. Updated and Upgraded raspian. Copy and pasted the "one line install command" into the CLI. Started the installation of Phoniebox.
Sevreal "Fehlschlag beim holen von xxx" notices during the installation, eventhough internet connection is workking. Have tried the installation 10 times, always with the same result.

Please execute sudo apt update before starting the install script. I assume the apt mirrors are not up to date.

That was the solution. It's weird, I could have sworn that I did sudo apt update as well as sudo apt upgrade when I first set up the pi two days ago. However, thank you for the quick response.


independent axis range control btw x and y, no origin for auto-zoom

This will address two enhancements described in the ticket, https://github.com/VEuPathDB/web-eda/issues/1408
a) behavior of axis range controls between x and y are independent each other
b) for Auto-zoom option, origin (e.g., 0) is not included
As for b), below is the example case that Bob raised (https://github.com/VEuPathDB/web-eda/issues/1097#issuecomment-1265744498, https://github.com/VEuPathDB/web-eda/issues/1097#issuecomment-1273655548)

X-axis Full

X-axis Auto-zoom: now the X-axis range is based on data, not including 0.

Thank you for your review and tests, @bobular 👍


Support firebase-admin 11.x

Currently, this library only supports firebase-admin 9.x and 10.x. We should add support for 11.x.
There have been some typing changes in 11.x so this is a bit more involved than just updating the dependencies to 11.x as there are some compilation issues, mainly around the introduction of making firestore.UpdateData generic.

This is done in #48 and #49. Merged and released v2.


Update sbt-buildinfo to 0.13.0

About this PR
📦 Updates com.eed3si9n:sbt-buildinfo from 0.12.0 to 0.13.0
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (0.12.0).
You might want to review and update them manually.
bin/deltag.sh

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.eed3si9n", artifactId = "sbt-buildinfo" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.eed3si9n", artifactId = "sbt-buildinfo" }
}]

labels: sbt-plugin-update, early-semver-major, semver-spec-minor, old-version-remains, commit-count:1

A bunch of tests failing with java.lang.ClassNotFoundException: xsbt.CompilerInterface:
[info] ClassNameSpecification:
[info] ClassName
[info] - should create correct binary names for top level object *** FAILED ***
[info]   java.lang.ClassNotFoundException: xsbt.CompilerInterface
[info]   at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
[info]   at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
[info]   at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
[info]   at java.lang.Class.forName0(Native Method)
[info]   at java.lang.Class.forName(Class.java:348)
[info]   at sbt.internal.inc.AnalyzingCompiler.getBridgeClass(AnalyzingCompiler.scala:372)
[info]   at sbt.internal.inc.AnalyzingCompiler.bridgeInstance(AnalyzingCompiler.scala:321)
[info]   at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:95)
[info]   at sbt.internal.inc.CompilingSpecification.$anonfun$compileSrcs$3(CompilingSpecification.scala:239)
[info]   at scala.collection.Iterator$$anon$9.next(Iterator.scala:584)
[info]   ...

something regressed on sbt-buildinfo?

https://github.com/sbt/sbt-buildinfo/issues/211


influx to bigQuery

in the example i don't see a migration from other DB
I would like to migrate time series collections from influxdb to bigquery

Thank you for the report. You're correct, we don't have a specific guide for migrating from InfluxDB to BigQuery (or another database). But, we do have a few guides for how to represent, import, and analyze time series data with GCP:

This article references financial data, but might be helpful in general: https://cloud.google.com/solutions/time-series/bigquery-financial-forex.
This article describes BigTable time series schema design: https://cloud.google.com/bigtable/docs/schema-design-time-series.

If you do end up finding a good solution, it might be a good candidate for a community tutorial (where you can also find a link to request a tutorial).


Tests not working on linux locally

I was here and got an error: https://github.com/techygrrrl/timerrr/blob/main/CONTRIBUTING.md#-testing
It looks like the tests were made for running inside of the CI runner with hardcoded runner paths. I'm unsure if it would be better to make them work for local setups or use something like https://github.com/nektos/act to test locally instead.

https://github.com/techygrrrl/timerrr/pull/11
There is a quick fix for supporting both my local linux setup and the runner(supposedly).

Closed by #11 #14 – thank you @AdjectiveAllison


homepage

This is a college assignment which I extended for my own personal interest inorder to closely look at javascript/html/css which I have combined here. Hope to get your reviews here

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Please do not open pull requests to random repositories for unrelated code.
Aside from that, don't push zip files to Git as they are impossible to diff and cannot be viewed in GitHub UI.


Dockerfile build failing trying to use --use-feature=in-tree-build

I have mailrise setup as a CI/CD pipeline to rebuild daily and push an image to my local repo.  It started failing 4 days ago with the error in the logs below.  Looks like --use-feature=in-tree-build may have been deprecated from pip and now the options are 2020-resolver, fast-deps, or truststore???
CI/CD Pipeline Logs
Step 2/16 : WORKDIR /code
 ---> Running in 732845b7294f
Removing intermediate container 732845b7294f
 ---> 5d17f01b648c
Step 3/16 : COPY . .
 ---> c8d28783d2f6
Step 4/16 : RUN pip install --user --no-cache-dir --use-feature=in-tree-build --no-warn-script-location .
 ---> Running in fb5517e5cf76

Usage:
  pip install [options] <requirement specifier> [package-index-options] ...
  pip install [options] -r <requirements file> [package-index-options] ...
  pip install [options] [-e] <vcs project url> ...
  pip install [options] [-e] <local project path> ...
  pip install [options] <archive url/path> ...

option --use-feature: invalid choice: 'in-tree-build' (choose from '2020-resolver', 'fast-deps', 'truststore')
The command '/bin/sh -c pip install --user --no-cache-dir --use-feature=in-tree-build --no-warn-script-location .' returned a non-zero code: 2
exit status 2

In tree builds are the default in contemporary Python versions, so we can just remove the flag now. Cheers!

In tree builds are the default in contemporary Python versions, so we can just remove the flag now. Cheers!

How should I remove the flag?


Pin version cairo1 on docs

Pin version cairo1 on docs

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (c7ac1bf) 94.55% compared to head (e6e1f0a) 94.55%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #809   +/-   ##
=======================================
  Coverage   94.55%   94.55%
=======================================
  Files         154      154
  Lines       34587    34587
=======================================
  Hits        32705    32705
  Misses       1882     1882

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Introduce Redux to app

First version was quick developed app. As this app grows it is best to introduce redux.

Successfully migrated app to Redux. Now need to auto persist state in AsyncStorage


[Feature]: extend options of cookie set to the browser

How the project can be improved?
Currently we are setting a cookie with session expiry date. As Vendure is not returning any data other that the token value we should set this expiry date by ourselves. I would recommend to set it to 2 days as we do not have a refresh token functionality.
What are the acceptance criteria?

[ ]

Additional information
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Does this mean that a customer would need to log in again after 2 days of their last visit?

Does this mean that a customer would need to log in again after 2 days of their last visit?

This is for the guest session cookie. We can set it to any other value. I have seen that other devs sometimes us a value of a week. Could you recommend any approach here?

From a UX perspective I think a longer time is better IMO. Putting a bunch of stuff in a guest cart and then returning a few days or a week later to an empty cart would be frustrating.
From a little googling I see that Magento allow "persistent carts" up to 1 year, and I saw a forum thread saying Shopify guest carts persist for 2 weeks.
So I'd say 2 weeks is a reasonable default.


CVP-9999 D01 Code Improvments

Change description
Terraform refactoring
Does this PR introduce a breaking change? (check one with "x")
[X] Yes
[] No

Can you create a ticket and update the title please


feat(Iconic): add provider to make 'assetPath' configurable

We are using the paid version of the awesome Iconic icons. Thus the default assetPath in the iconic service doesn't necessarily fit.
So I changed the service to a provider that can be configured via IconicProvider.setAssetPath(path). If no path is configured, the default value assets/img/iconic/ is used.

And as JSHint made some complaints I added minor stylistic changes.

Nice, thanks for the work!

@gjungb Can you help out here? http://foundation.zurb.com/forum/posts/26117-how-to-use-of-iconicprovider  Thanks!


Non-parenthesized function call with | operator isn't parsed properly

Non-parenthesized function call with | operator isn't parsed properly.  For example:
chmod $perm | oct '700', $root

Fixed in v0.969


Node segfault (error 139) in container release v11.x.x

Bug description
I can neither migrate old data nor can I start a new world.  I always get the same error:
{"code":"ECOMPROMISED","errno":-2,"level":"error","message":"ENOENT: no such file or directory, stat '/data/Config/options.json.lock'","path":"/data/Config/options.json.lock","stack":"Error: ENOENT: no such file or directory, stat '/data/Config/options.json.lock'","syscall":"stat","timestamp":"2023-05-26 17:39:43"}
{"level":"error","message":"A fatal error occurred while trying to start the Foundry Virtual Tabletop server: Foundry VTT cannot start in this directory which is already locked by another process.","stack":"Error: A fatal error occurred while trying to start the Foundry Virtual Tabletop server: Foundry VTT cannot start in this directory which is already locked by another process.\n    at _acquireLockFile (file:///home/foundry/resources/app/dist/init.mjs:1:4799)\n    at async _initializeCriticalFunctions (file:///home/foundry/resources/app/dist/init.mjs:1:2593)\n    at async Module.initialize (file:///home/foundry/resources/app/dist/init.mjs:1:1564)","timestamp":"2023-05-26 17:41:11"}
{"level":"error","message":"A fatal error occurred while trying to start the Foundry Virtual Tabletop server: Foundry VTT cannot start in this directory which is already locked by another process.","stack":"Error: A fatal error occurred while trying to start the Foundry Virtual Tabletop server: Foundry VTT cannot start in this directory which is already locked by another process.\n    at _acquireLockFile (file:///home/foundry/resources/app/dist/init.mjs:1:4799)\n    at async _initializeCriticalFunctions (file:///home/foundry/resources/app/dist/init.mjs:1:2593)\n    at async Module.initialize (file:///home/foundry/resources/app/dist/init.mjs:1:1564)","timestamp":"2023-05-26 17:44:36"}

The data is stored on the host system as a bind volume under a directory.  All was well with V10.
I attempted to 'reset' all the data as well, by stopping the container, moving the data to a new folder, re-creating the old folder completely empty, and creating a brand new world.  The error logs above are from that last attempt.
I have tried removing the options.json.lock directory (isn't this supposed to be a file, not a directory, btw?), recycling the container, to no avail.   I suspect this may be a bug in foundry itself, but I'm not certain, and figured anyone else running into this issue from this container may find their way here...
Steps to reproduce

Start a new container instance with a bind volume to hold the container data
Create a new world
Attempt to launch the world

Expected behavior
I expect the world to launch without error.
Container metadata
com.foundryvtt.version = "11.299"
org.opencontainers.image.authors =<EMAIL_ADDRESS>org.opencontainers.image.created = "2023-05-26T01:33:20.124Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "349bc278fa92049dd2b480b322fc30a0842221fb"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "11.299.0"

Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Please provide the logs from the container with verbose logging enabled.  If you have a docker-compose file that would be helpful as well.

_foundryvtt_logs.txt

Did you report this yesterday by any chance on the FoundryVTT discord?  I'm seeing someone with the same error here:
https://discord.com/channels/170995199584108546/486930822465716249/1111373639321911427
The issue most likely not a container bug, as Foundry was installed and successfully launched.
Are you sure there are no other processes / containers running with that same Config directory?

Negative, I'm not on the FoundryVTT server - I'd be uberDoward on there as well, though...

Ok then if that's not you... good news then if you believe that miserly loves company.
CaydenSworn#3518 is reporting the same issue in the #troubleshooting forum.  I'd keep an eye any resolutions they report.
I saw your issue that you opened to the foundryvtt project.  Just be aware that there is a very strong container phobia with the support team.  To the point that they will refuse to support any containerized foundry debugging.  🤷
I can't think of any solutions or tests that you haven't already run.  Can you think of anything novel about your setup or configuration?

Nothing novel, beyond the basic binding of the volume for the host storage.   I'll see if they reply, and I'll go ahead and see if I can re-create it outside the containerization just to quell that discussion ahead of time...   Appreciate the heads up!

Ok, so noticed something potentially of interest.  Node's dying with exit code 139 (SIGSEGV) - and when I went to launch using the same data config from the straight node FoundryVTT install, all worked fine.  As part of trying to get it to run, though, I had to get GCC 3.4.29 - and since I'm running on Bullseye (Raspian) I had to upgrade to unstable (Bookworm) - then I could run FoundryVTT from node non-containerized perfectly fine.   What GLIBCXX is available within the container?   I'm trying to hit it with /bin/sh so I can check, but now that I migrated the default world, I'm just spinning and crashing the container lol.    I'll keep digging...

Attach latest log - created a completely fresh image.  Running on a raspberry pi4, btw - so this is ARM, rather than x86 based.   Completely new container won't launch any world when running in a container, but works fine running directly from my RPi4 host.   I'm really leaning towards a container issue
_foundryvtt-test_logs.txt
:(

do you have any issues installing/updating modules too?
i always get a timeout if i try to do that.

BTW, can I get an invite to the discord channel?

Click New Issue button on this repo above and it will take you to a page with the Discord invite link.

FWIW Here is the info for the two machines I normally run Foundry on:
➤ uname -a
Linux 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux

➤ cat /etc/issue.net
Debian GNU/Linux 11

➤ grep Model /proc/cpuinfo
Model		: Raspberry Pi 4 Model B Rev 1.4

➤ uname -a
Darwin 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 20:52:24 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6000 arm64

➤ sw_vers
ProductName:		macOS
ProductVersion:		13.4
BuildVersion:		22F66

➤ sysctl -n machdep.cpu.brand_string
Apple M1 Ultra

And all continuous integration tests are run on amd64 Ubuntu 22.04.2:

https://github.com/felddy/foundryvtt-docker/actions/runs/5154302282/jobs/9282675181#step:1:4

I haven't been able to reproduce this yet.  I do have a few ideas that could help diagnose the cause.

Can you try pulling a :nightly build of the container to see if the issue still persists.  I'm trying to rule out it being an issue in specific base node image that was used for the release.  To do this, set the tag you are pulling to :nightly .  https://github.com/felddy/foundryvtt-docker/pkgs/container/foundryvtt/98592774?tag=nightly

Release v11.299.0 is based off of the official node container 18-alpine3.17.  Can you try starting that base container and seeing if it is possible to generate a segfault by creating some disk and memory access in node?

Something like this:
docker run --rm -it node:18-alpine3.18 /bin/sh

cd /tmp

npm install diskdb

cat <<EOF > test.js
const db = require('diskdb');
db.connect('/tmp', ['test']);

const data = [];
for(let i = 0; i < 1000000; i++) {
    data.push({ number: i });
}

db.test.save(data);

console.log(db.test.find());
EOF

node test.js

cat <<EOF > test-memory.js
let array = [];

setInterval(() => {
  for(let i = 0; i < 1000000; i++) {
    array.push("This is some text.");
  }

  const memoryUsage = process.memoryUsage();
  console.log("Memory usage: " + JSON.stringify(memoryUsage, null, 2) + " bytes");
}, 1000);
EOF

node test-memory.js

I just published the 11.300.0 release.  Usually these aren't significant except the version bump for FoundryVTT, but this release also includes a new version of the base node image.  Alpine was bumped from 3.17 to 3.18.
In addition to the previous tests I suggested above, please try pulling 11.300.0 to see if it behaves differently.
See:

https://github.com/felddy/foundryvtt-docker/releases/tag/v11.300.0
https://github.com/felddy/foundryvtt-docker/commit/4feac207c86c80205505f64886ca431a6017e051

I regret to inform you, that the error persist, in my instance at least the errorcode 139 persists. even with the newest 11.300.0 release

Just as in Version 11.299.0 The error appears when launching a world, or trying to migrate one to the newest Version.
The error also persists on a complete clean install of the container via docker-compose.

I wanted to chime in that I'm having the exact same issue as @DasOcko on my Raspberry Pi 4, with a completely fresh install using 11.300.0. The container crashes with a segmentation fault and exit code 139 when trying to load a just created world.

@mxvs That is the "good" outcome of the memory test.  It ran out of memory and got a SIGTRAP and not a SIGSEGV.  Thanks for running it.   This is helpful.

I just build a version of the image using Node 16 instead of 18.
When you get a chance please pull felddy/foundryvtt:testing-issue-697 and test.
See:

https://github.com/felddy/foundryvtt-docker/pkgs/container/foundryvtt/99984846?tag=testing-issue-697

I just build a version of the image using Node 16 instead of 18.
When you get a chance please pull felddy/foundryvtt:testing-issue-697 and test.
See:

https://github.com/felddy/foundryvtt-docker/pkgs/container/foundryvtt/99984846?tag=testing-issue-697

I just ran the modified container and it unfortunately still segfaults as soon as I try to load the world :-(

Ok.  That gives us more data. Thank you for helping run this down.  I wish I could reproduce it myself.
I"ve got another idea.  Let's start up the last version of the image that was working, but request Foundry version 11.300 be installed.
So that would mean starting felddy/foundryvtt:10.291.1 and setting the environment variable FOUNDRY_VERSION to 11.300.
Normally this would work fine.  You'd just have a mismatch between the container and Foundry which means you might not have access to specifying some options via environment variables.  There should be a warning in the container logs to this effect.
If we still see the segfault then we know it's something specific to Foundry v11.  Then the debugging fun really begins. ;)

Ok. That gives us more data. Thank you for helping run this down. I wish I could reproduce it myself.
I"ve got another idea. Let's start up the last version of the image that was working, but request Foundry version 11.300 be installed.
So that would mean starting felddy/foundryvtt:10.291.1 and setting the environment variable FOUNDRY_VERSION to 11.300.
Normally this would work fine. You'd just have a mismatch between the container and Foundry which means you might not have access to specifying some options via environment variables. You will see a warning like this in the logs:
foundryvtt-mine-foundry-1  | Entrypoint | 2023-06-08 21:21:10 | [warn] FOUNDRY_VERSION has been manually set and does not match the container's version.
foundryvtt-mine-foundry-1  | Entrypoint | 2023-06-08 21:21:10 | [warn] Expected 10.291 but found 11.300
foundryvtt-mine-foundry-1  | Entrypoint | 2023-06-08 21:21:10 | [warn] The container may not function properly with this version mismatch.

I can confirm that this test works on my side.
If you still see the segfault then we know it's something specific to Foundry v11. Then the debugging fun really begins. ;)

Alright, I just tried the above both with 11.300 in the 10.291.1 container and the just released 11.301 and in both instances the segfault is still thrown when trying to open the world. So its something specific to v11 and not the container..

Thanks for testing.  I think this is the most telling test results so far.
I've got a couple problems to overcome now:

I need to do some thinking about how to run this down further despite not being able to reproduce it yet.
The FoundryVTT developers are anti-container and do not support containerized installs, or bug reports related to them.

I'll keep working on this.  Thank you again for the test help.

Thanks for testing. I think this is the most telling test results so far. I've got a couple problems to overcome now:

I need to do some thinking about how to run this down further despite not being able to reproduce it yet.
The FoundryVTT developers are anti-container and do not support containerized installs, or bug reports related to them.

I'll keep working on this. Thank you again for the test help.

So, to be absolutely certain, I wanted to try running things in a barebones container, install Foundry V11 manually and  see if it would still segfault. The short version is that it works just fine in barebones container. This seems to indicate it might not be a Foundry bug after all, or at least there is some weird interaction going on with the way the container is set-up as I got it to work in another container configuration on the same hardware.
So here is what I did:

I pulled the latest official Ubuntu docker image (since I know how to work with that)
Ran the image with docker run with just port 30000 mapped and dropping straight into a bash shell, no other options
Installed only the following tools: sudo, wget, curl, libssl-dev and installed nodejs 18 using the official install script
I then followed the install instructions here https://foundryvtt.com/article/installation/ to the letter and ran Foundry
Installed dnd5e system, created a test world and launched it
No segfault!

So its definitely possible to run Foundry V11 in a container on a Raspberry PI 4.. not sure if this makes it easier or harder now, but I feel this takes us a step closer to a solution..

Great find!  Don't stop trying things.  You're reading my mind on these tests.
I'm hesitant to switch the project off of Alpine (yet) since I really appreciate the size to the resulting image.  That said, this isn't the first time Alpine has either been the cause of an issue or exasperated something else.  So I don't want to point any fingers about which component, Alpine, Node.js, or FoundryVTT is doing the Wrong Thing™ (yet).
I would like to try to run this to ground for a couple of reasons:

I like to understand why things break so I can avoid it in the future.
We might find a bug in Alpine, Node, or FoundryVTT that we can report back to those projects.

As a temporary work-around I can revive a Debian version of the image that I have sitting in a stale branch.
I'd like to get my hands on a core dump from this segfault.  I don't have any experience debugging node dumps, especially when I don't have access to the symbols, but I'd like to attempt it and see if I can identify the call that kills the process.   If anyone wants to attache a core dump I'd appreciate it.
Thanks again for all the help.  I truly appreciate it.
See:

https://github.com/felddy/foundryvtt-docker/commit/ed1718d7b34ea887df7de13d70537a5f540dc053
https://github.com/felddy/foundryvtt-docker/tree/improvement/debian

A Debian version of the container is now building:

https://github.com/felddy/foundryvtt-docker/actions/runs/5251473586

When/If it completes successfully it can be pulled with felddy/foundryvtt:testing-issue-697.
Noe: I had to drop arm/v6 support for now as the Debian base image did not exist for that platform.
Please test an let me know if this temporary work-around works.

A Debian version of the container is now building:

https://github.com/felddy/foundryvtt-docker/actions/runs/5251473586

When/If it completes successfully it can be pulled with felddy/foundryvtt:testing-issue-697.
Noe: I had to drop arm/v6 support for now as the Debian base image did not exist for that platform.
Please test an let me know if this temporary work-around works.

@felddy This container unfortunately doesn't start, here's the error:
v11-foundry-1  | Entrypoint | 2023-06-13 17:07:17 | [info] Starting felddy/foundryvtt container v11.301.0
v11-foundry-1  | Entrypoint | 2023-06-13 17:07:17 | [info] No Foundry Virtual Tabletop installation detected.
v11-foundry-1  | Entrypoint | 2023-06-13 17:07:17 | [info] Using CONTAINER_CACHE: /data/container-cache
v11-foundry-1  | Entrypoint | 2023-06-13 17:07:17 | [info] Installing Foundry Virtual Tabletop 11.301
v11-foundry-1  | Entrypoint | 2023-06-13 17:07:24 | [info] Preserving release archive file in cache.
v11-foundry-1  | Entrypoint | 2023-06-13 17:07:24 | [info] Not modifying existing installation license key.
v11-foundry-1  | Entrypoint | 2023-06-13 17:07:24 | [info] Setting data directory permissions.
v11-foundry-1  | Entrypoint | 2023-06-13 17:07:24 | [info] Starting launcher with uid:gid as foundry:foundry.
v11-foundry-1  | Launcher | 2023-06-13 17:07:24 | [info] Generating options.json file.
v11-foundry-1  | Launcher | 2023-06-13 17:07:24 | [info] Setting 'Admin Access Key'.
v11-foundry-1  | Launcher | 2023-06-13 17:07:25 | [info] Starting Foundry Virtual Tabletop.
v11-foundry-1  | node:internal/modules/cjs/loader:1338
v11-foundry-1  |   return process.dlopen(module, path.toNamespacedPath(filename));
v11-foundry-1  |                  ^
v11-foundry-1  |
v11-foundry-1  | Error: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /home/foundr                                                                y/resources/app/node_modules/classic-level/prebuilds/linux-arm/node.napi.armv7.node)
v11-foundry-1  |     at Module._extensions..node (node:internal/modules/cjs/loader:1338:18)
v11-foundry-1  |     at Module.load (node:internal/modules/cjs/loader:1117:32)
v11-foundry-1  |     at Module._load (node:internal/modules/cjs/loader:958:12)
v11-foundry-1  |     at Module.require (node:internal/modules/cjs/loader:1141:19)
v11-foundry-1  |     at require (node:internal/modules/cjs/helpers:110:18)
v11-foundry-1  |     at load (/home/foundry/resources/app/node_modules/node-gyp-build/node-gyp-build.js:22:10)
v11-foundry-1  |     at Object.<anonymous> (/home/foundry/resources/app/node_modules/classic-level/binding.js:1:43)
v11-foundry-1  |     at Module._compile (node:internal/modules/cjs/loader:1254:14)
v11-foundry-1  |     at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
v11-foundry-1  |     at Module.load (node:internal/modules/cjs/loader:1117:32) {
v11-foundry-1  |   code: 'ERR_DLOPEN_FAILED'
v11-foundry-1  | }
v11-foundry-1  |
v11-foundry-1  | Node.js v18.16.0
v11-foundry-1  | Launcher | 2023-06-13 17:07:27 | [error] Node process exited with code 1
v11-foundry-1 exited with code 0

So again for posterity,  tihis Debian-based image works in continuous integration amd64, on my development machine M1 arm64, and also my server (Raspberry Pi 4 Model B Rev 1.4) also arm64.
Here is the output of docker info and docker version:
M1 Mac (Colima)
➤ docker info
Client: Docker Engine - Community
 Version:    24.0.2
 Context:    colima
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.10.5
    Path:     /Users/xxx/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.18.1
    Path:     /Users/xxx/.docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 2
 Server Version: 23.0.6
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1fbd70374134b891f97ce19c70b6e50c7b9f4e0d
 runc version: 860f061b76bb4fc671f0f9e900f7d80ff93d4eb7
 init version:
 Security Options:
  seccomp
   Profile: builtin
 Kernel Version: 6.1.29-0-virt
 Operating System: Alpine Linux v3.18
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 15.6GiB
 Name: colima
 ID: 5f37d5cf-a1cc-4c73-ae4b-88f10df32a72
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

➤ docker version
Client: Docker Engine - Community
Version:           24.0.2
API version:       1.42 (downgraded from 1.43)
Go version:        go1.20.4
Git commit:        cb74dfcd85
Built:             Thu May 25 20:26:27 2023
OS/Arch:           darwin/arm64
Context:           colima

Server:
Engine:
 Version:          23.0.6
 API version:      1.42 (minimum version 1.12)
 Go version:       go1.20.4
 Git commit:       9dbdbd4b6d7681bd18c897a6ba0376073c2a72ff
 Built:            Fri May 12 13:54:36 2023
 OS/Arch:          linux/arm64
 Experimental:     false
containerd:
 Version:          v1.7.0
 GitCommit:        1fbd70374134b891f97ce19c70b6e50c7b9f4e0d
runc:
 Version:          1.1.7
 GitCommit:        860f061b76bb4fc671f0f9e900f7d80ff93d4eb7
docker-init:
 Version:          0.19.0
 GitCommit:

Raspberry Pi 4 Model B Rev 1.4
➤ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.9.1)

Server:
 Containers: 13
  Running: 13
  Paused: 0
  Stopped: 0
 Images: 14
 Server Version: 20.10.5+dfsg1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1.4.13~ds1-1~deb11u3
 runc version: 1.0.0~rc93+ds1-5+deb11u2
 init version:
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.84-v8+
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 7.629GiB
 Name: xxx
 ID: RKF3:S7B4:UJOO:EBUY:V6SP:C7BN:XY4O:WUXQ:KPPN:ZEI3:XPOY:FN2S
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

WARNING: No memory limit support
WARNING: No swap limit support
WARNING: Support for cgroup v2 is experimental

➤ docker version
Client:
 Version:           20.10.5+dfsg1
 API version:       1.41
 Go version:        go1.15.15
 Git commit:        55c4c88
 Built:             Mon May 30 18:34:49 2022
 OS/Arch:           linux/arm64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.5+dfsg1
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.15.15
  Git commit:       363e9a8
  Built:            Mon May 30 18:34:49 2022
  OS/Arch:          linux/arm64
  Experimental:     true
 containerd:
  Version:          1.4.13~ds1
  GitCommit:        1.4.13~ds1-1~deb11u3
 runc:
  Version:          1.0.0~rc93+ds1
  GitCommit:        1.0.0~rc93+ds1-5+deb11u2
 docker-init:
  Version:          0.19.0
  GitCommit:

But I think it is very telling that it is in the classic-level prebuilt module.   I need to do some more research.
See:

https://github.com/Level/classic-level

For your info, here is what I'm running it on:

Raspberrry Pi 4 Model B Rev 1.4
```
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.10.0-docker)
  compose: Docker Compose (Docker Inc., v2.18.1)
Server:
Containers: 9
Running: 0
Paused: 0
Stopped: 9
Images: 41
Server Version: 24.0.2
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
runc version: v1.1.7-0-g860f061
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.1.21-v8+
Operating System: Raspbian GNU/Linux 11 (bullseye)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 3.704GiB
Name: pifoundry
ID: FQMZ:FQR2:NHSC:45P7:KZ6L:PYR4:WBRS:YKRZ:FL5X:KHIW:WB2R:J5RL
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false

</details>

This is what I see in the Debian image as far as GLIBCXX versions:
docker run -it --rm --entrypoint /bin/bash felddy/foundryvtt:testing-issue-697 -c "apt-get update && apt-get install -y binutils && strings /usr/lib/aarch64-linux-gnu/libstdc++.so.6 | grep GLIBCXX"
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_3.4.30
GLIBCXX_DEBUG_MESSAGE_LENGTH

This is what I see in the Debian image as far as GLIBCXX versions:
docker run -it --rm --entrypoint /bin/bash felddy/foundryvtt:testing-issue-697 -c "apt-get update && apt-get install -y binutils && strings /usr/lib/aarch64-linux-gnu/libstdc++.so.6 | grep GLIBCXX"

Running this exact command starts the apt-get install process and then halts with this message:
Processing triggers for libc-bin (2.31-13+deb11u6) ...
strings: '/usr/lib/aarch64-linux-gnu/libstdc++.so.6': No such file`

No GLIBCXX versions are printed.

Follow up:
I dropped into a shell in the container and tried to find where libstdc++ was located because according to apt-get it is installed and I got the following:
root@28d99cd0f12c:/home/foundry# find / -name "libstdc*"
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.28
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6
/usr/share/gcc/python/libstdcxx
/usr/share/gdb/auto-load/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.28-gdb.py
/usr/share/doc/libstdc++6
/var/lib/dpkg/info/libstdc++6:armhf.triggers
/var/lib/dpkg/info/libstdc++6:armhf.md5sums
/var/lib/dpkg/info/libstdc++6:armhf.list
/var/lib/dpkg/info/libstdc++6:armhf.prerm
/var/lib/dpkg/info/libstdc++6:armhf.symbols
/var/lib/dpkg/info/libstdc++6:armhf.shlibs

Follow up:
I dropped into a shell in the container and tried to find where libstdc++ was located because according to apt-get it is installed and I got the following:
root@28d99cd0f12c:/home/foundry# find / -name "libstdc*"
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.28
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6
/usr/share/gcc/python/libstdcxx
/usr/share/gdb/auto-load/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.28-gdb.py
/usr/share/doc/libstdc++6
/var/lib/dpkg/info/libstdc++6:armhf.triggers
/var/lib/dpkg/info/libstdc++6:armhf.md5sums
/var/lib/dpkg/info/libstdc++6:armhf.list
/var/lib/dpkg/info/libstdc++6:armhf.prerm
/var/lib/dpkg/info/libstdc++6:armhf.symbols
/var/lib/dpkg/info/libstdc++6:armhf.shlibs

Do you have a 32-bit version of Raspbian installed on your 64-bit Raspberry Pi?

Hey that's a great point @mcdonnnj - My setup was running 64bit raspbian on 64bit raspberry pi 4 and refused to work.

Hey that's a great point @mcdonnnj - My setup was running 64bit raspbian on 64bit raspberry pi 4 and refused to work.

@uberDoward Have you tried the image tag that @felddy created for working on this issue (felddy/foundryvtt:testing-issue-697)?

@mcdonnnj - not yet.  Work has been killing me, and I had a bit of a rough zfs pool migration that JUST finished on the home lab.  I've been utterly exhausted and why I haven't participated after I booted FoundryVTT-docker from the ARM64 RPi4 over to the x86 server LOL - I will try to try it tonight, but not making promised, my wife just went back into the hospital this morning and I'm running the house as well...

I gotta cook dinner BUT I am fundamentally incapable of leaving a problem alone.  It's a weakness.   Here's what I got:
Actions

Entrypoint | 2023-06-13 22:49:49 | [info] Starting felddy/foundryvtt container v11.301.0
Entrypoint | 2023-06-13 22:49:49 | [info] No Foundry Virtual Tabletop installation detected.
Entrypoint | 2023-06-13 22:49:49 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
Authenticate | 2023-06-13 22:49:50 | [info] Requesting CSRF tokens from https://foundryvtt.com
Authenticate | 2023-06-13 22:49:51 | [info] Logging in as: uberdoward
Authenticate | 2023-06-13 22:49:52 | [info] Successfully logged in as: uberdoward
Entrypoint | 2023-06-13 22:49:52 | [info] Using authenticated credentials to download release.
ReleaseURL | 2023-06-13 22:49:53 | [info] Fetching S3 pre-signed release URL for build 301...
Entrypoint | 2023-06-13 22:49:54 | [info] Using CONTAINER_CACHE: /data/container_cache
Entrypoint | 2023-06-13 22:49:54 | [info] Downloading Foundry Virtual Tabletop release.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  2  207M    2 6338k    0     0  4868k      0  0:00:43  0:00:01  0:00:42 4864k
 11  207M   11 24.5M    0     0  10.8M      0  0:00:19  0:00:02  0:00:17 10.8M
 21  207M   21 44.6M    0     0  13.6M      0  0:00:15  0:00:03  0:00:12 13.6M
 30  207M   30 63.9M    0     0  15.0M      0  0:00:13  0:00:04  0:00:09 15.0M
 38  207M   38 79.8M    0     0  15.1M      0  0:00:13  0:00:05  0:00:08 15.9M
 46  207M   46 96.4M    0     0  15.3M      0  0:00:13  0:00:06  0:00:07 18.1M
 53  207M   53  110M    0     0  15.2M      0  0:00:13  0:00:07  0:00:06 17.2M
 59  207M   59  123M    0     0  14.9M      0  0:00:13  0:00:08  0:00:05 15.7M
 65  207M   65  135M    0     0  14.6M      0  0:00:14  0:00:09  0:00:05 14.3M
 68  207M   68  142M    0     0  13.9M      0  0:00:14  0:00:10  0:00:04 12.6M
 72  207M   72  150M    0     0  13.3M      0  0:00:15  0:00:11  0:00:04 10.7M
 76  207M   76  157M    0     0  12.8M      0  0:00:16  0:00:12  0:00:04 9683k
 80  207M   80  165M    0     0  12.4M      0  0:00:16  0:00:13  0:00:03 8646k
 83  207M   83  172M    0     0  12.0M      0  0:00:17  0:00:14  0:00:03 7508k
 86  207M   86  178M    0     0  11.7M      0  0:00:17  0:00:15  0:00:02 7330k
 88  207M   88  183M    0     0  11.2M      0  0:00:18  0:00:16  0:00:02 6706k
 91  207M   91  189M    0     0  11.0M      0  0:00:18  0:00:17  0:00:01 6557k
 94  207M   94  196M    0     0  10.7M      0  0:00:19  0:00:18  0:00:01 6347k
 98  207M   98  203M    0     0  10.5M      0  0:00:19  0:00:19 --:--:-- 6412k
100  207M  100  207M    0     0  10.4M      0  0:00:19  0:00:19 --:--:-- 6502k
Entrypoint | 2023-06-13 22:50:14 | [info] Installing Foundry Virtual Tabletop 11.301
Entrypoint | 2023-06-13 22:50:22 | [info] Preserving release archive file in cache.
Entrypoint | 2023-06-13 22:50:22 | [info] Not modifying existing installation license key.
Entrypoint | 2023-06-13 22:50:22 | [info] Setting data directory permissions.
Entrypoint | 2023-06-13 22:50:22 | [info] Starting launcher with uid:gid as foundry:foundry.
Launcher | 2023-06-13 22:50:22 | [info] Generating options.json file.
Launcher | 2023-06-13 22:50:23 | [warn] No 'Admin Access Key' has been configured.
Launcher | 2023-06-13 22:50:23 | [info] Starting Foundry Virtual Tabletop.
node:internal/modules/cjs/loader:1338
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^
Error: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /home/foundry/resources/app/node_modules/classic-level/prebuilds/linux-arm/node.napi.armv7.node)
    at Module._extensions..node (node:internal/modules/cjs/loader:1338:18)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Module._load (node:internal/modules/cjs/loader:958:12)
    at Module.require (node:internal/modules/cjs/loader:1141:19)
    at require (node:internal/modules/cjs/helpers:110:18)
    at load (/home/foundry/resources/app/node_modules/node-gyp-build/node-gyp-build.js:22:10)
    at Object.<anonymous> (/home/foundry/resources/app/node_modules/classic-level/binding.js:1:43)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Module.load (node:internal/modules/cjs/loader:1117:32) {
  code: 'ERR_DLOPEN_FAILED'
}
Node.js v18.16.0
Launcher | 2023-06-13 22:50:26 | [error] Node process exited with code 1

Using

Image
felddy/foundryvtt:release@sha256:f1c70bca8f80967077a2c0cc8b35e3fd6a05aa0bb9508f6b7474242ea47265a7

I think we've found the culprit:

https://github.com/foundryvtt/foundryvtt/issues/8847

That jives with my gut instinct of this being a GLIBC issue.  If I get any free time (HAHAHA), I'll try rebuilding the dependencies from source.  My home lab is Gentoo, and my day job is a senior software engineer.  I'm familiar with building code, lol

Follow up:
I dropped into a shell in the container and tried to find where libstdc++ was located because according to apt-get it is installed and I got the following:
root@28d99cd0f12c:/home/foundry# find / -name "libstdc*"
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.28
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6
/usr/share/gcc/python/libstdcxx
/usr/share/gdb/auto-load/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.28-gdb.py
/usr/share/doc/libstdc++6
/var/lib/dpkg/info/libstdc++6:armhf.triggers
/var/lib/dpkg/info/libstdc++6:armhf.md5sums
/var/lib/dpkg/info/libstdc++6:armhf.list
/var/lib/dpkg/info/libstdc++6:armhf.prerm
/var/lib/dpkg/info/libstdc++6:armhf.symbols
/var/lib/dpkg/info/libstdc++6:armhf.shlibs

Do you have a 32-bit version of Raspbian installed on your 64-bit Raspberry Pi? I'm trying to think of why you would be pulling an armhf image instead of an arm64 image.

Yes, I'm running the 32 bit OS, when I first set-up the PI4, the 64 bit version was still in beta and even today on their website the 32 bit version is mentioned as "Our recommended operating system for most users."

As a workaround  for this issue you can try the following:

Create a container_patches directory in your data mount.  e.g., data/container_patches.

In this directory create a file called: patch-issue-697.sh with the following contents:
#!/bin/ash

# Issue 697 Fix
# =====================

PATCH_DOC_URL="https://github.com/felddy/foundryvtt-docker/issues/697"
PATCH_NAME="Fix for issue #697"

log "Applying \"${PATCH_NAME}\""
log "See: ${PATCH_DOC_URL}"

apk add g++ make python3
cd resources/app
npm install classic-level --build-from-source
cd -

Set the environment variable: CONTAINER_PATCHES=/data/container_patches  in your container's configuration.

Start the container.

In your container logs you will see lines similar to this after Foundry is installed but before it starts:
...
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] Using CONTAINER_PATCHES: /data/container_patches
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] Container patches directory detected.  Starting patch application...
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] Sourcing patch from file: /data/container_patches/issue-697.sh
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] Applying "Fix for issue #697"
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] See: https://github.com/felddy/foundryvtt-docker/issues/697
foundryvtt-foundry-1  | fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/aarch64/APKINDEX.tar.gz
foundryvtt-foundry-1  | fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/aarch64/APKINDEX.tar.gz
foundryvtt-foundry-1  | (1/29) Installing libstdc++-dev (12.2.1_git20220924-r10)
foundryvtt-foundry-1  | (2/29) Installing zstd-libs (1.5.5-r4)
foundryvtt-foundry-1  | (3/29) Installing binutils (2.40-r7)
foundryvtt-foundry-1  | (4/29) Installing libgomp (12.2.1_git20220924-r10)
foundryvtt-foundry-1  | (5/29) Installing libatomic (12.2.1_git20220924-r10)
...
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:52:11 | [info] Completed file patching.
...

This should apply the steps as documented in the associated issue here:

https://github.com/foundryvtt/foundryvtt/issues/8847#issuecomment-1476744934

Please let me know how this works.  If it succeeds I can add this file to the repo's patch library for others to use.

As a workaround for this issue you can try the following:

Create a container_patches directory in your data mount.  e.g., data/container_patches.
In this directory create a file called: patch-issue-697.sh with the following contents:#!/bin/ash

# Issue 697 Fix
# =====================

PATCH_DOC_URL="https://github.com/felddy/foundryvtt-docker/issues/697"
PATCH_NAME="Fix for issue #697"

log "Applying \"${PATCH_NAME}\""
log "See: ${PATCH_DOC_URL}"

apk add g++ make python3
cd resources/app
npm install classic-level --build-from-source
cd -

Set the environment variable: CONTAINER_PATCHES=/data/container_patches  in your container's configuration.
Start the container.

In your container logs you will see lines similar to this after Foundry is installed but before it starts:
...
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] Using CONTAINER_PATCHES: /data/container_patches
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] Container patches directory detected.  Starting patch application...
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] Sourcing patch from file: /data/container_patches/issue-697.sh
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] Applying "Fix for issue #697"
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:51:50 | [info] See: https://github.com/felddy/foundryvtt-docker/issues/697
foundryvtt-foundry-1  | fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/aarch64/APKINDEX.tar.gz
foundryvtt-foundry-1  | fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/aarch64/APKINDEX.tar.gz
foundryvtt-foundry-1  | (1/29) Installing libstdc++-dev (12.2.1_git20220924-r10)
foundryvtt-foundry-1  | (2/29) Installing zstd-libs (1.5.5-r4)
foundryvtt-foundry-1  | (3/29) Installing binutils (2.40-r7)
foundryvtt-foundry-1  | (4/29) Installing libgomp (12.2.1_git20220924-r10)
foundryvtt-foundry-1  | (5/29) Installing libatomic (12.2.1_git20220924-r10)
...
foundryvtt-foundry-1  | Entrypoint | 2023-06-19 17:52:11 | [info] Completed file patching.
...

This should apply the steps as documented in the associated issue here:

Build the precompiled binaries for LevelDB and classic level using a lesser version of the GLIBC library to support a wider range of environments. foundryvtt/foundryvtt#8847 (comment)

Please let me know how this works. If it succeeds I can add this file to the repo's patch library for others to use.

It doesn't run, you get:
 /data/container_patches/patch-issue-697.sh: line 12: apk: command not found
I think its because the container behind felddy/foundryvtt:testing-issue-697 is now the debain based build you prepared in this comment (https://github.com/felddy/foundryvtt-docker/issues/697#issuecomment-1588553610) and no longer the alpine version that has apk as the package manager?

It doesn't run, you get:
 /data/container_patches/patch-issue-697.sh: line 12: apk: command not found
I think its because the container behind felddy/foundryvtt:testing-issue-697 is now the debain based build you prepared in this comment (#697 (comment)) and no longer the alpine version that has apk as the package manager?

Sorry I wasn't clear.  You should use the standard releases. e.g., felddy/foundryvtt:release

Please let me know how this works. If it succeeds I can add this file to the repo's patch library for others to use.

This fixed the segfault I was getting on a pi4, thank you!

Please let me know how this works. If it succeeds I can add this file to the repo's patch library for others to use.

I too can confirm that this works on my Raspberry Pi 4  🥳  I will note that this increases the startup time of the container to a little over two minutes on the Pi 4 hardware due to the compilation step, perhaps a useful disclaimer to mention when publishing the patch.
Thanks for all the efforts to resolve this issue!

Apologies for the delayed response - I'll test as well this weekend on my rpi4

I was having this problem and your solution worked for my system.
Problem
When upgrading or launching a world, foundry crashed with the follow logs:
Segmentation fault (core dumped)
Launcher | 2023-05-27 02:44:37 | [error] Node process exited with code 139

Solution
Exactly as described here: https://github.com/felddy/foundryvtt-docker/issues/697#issuecomment-1599192517
My system
$ uname -a
Linux raspberrypi 5.15.84-v7l+ #1613 SMP Thu Jan 5 12:01:26 GMT 2023 armv7l GNU/Linux
$ cat /etc/issue.net
Raspbian GNU/Linux 11
$ grep Model /proc/cpuinfo
Model           : Raspberry Pi 4 Model B Rev 1.5

I was having this problem and your solution worked for my system.
Problem
When upgrading or launching a world, foundry crashed with the follow logs:
Segmentation fault (core dumped)
Launcher | 2023-05-27 02:44:37 | [error] Node process exited with code 139

Solution
Exactly as described here: #697 (comment)
My system
$ uname -a
Linux raspberrypi 5.15.84-v7l+ #1613 SMP Thu Jan 5 12:01:26 GMT 2023 armv7l GNU/Linux
$ cat /etc/issue.net
Raspbian GNU/Linux 11
$ grep Model /proc/cpuinfo
Model           : Raspberry Pi 4 Model B Rev 1.5

Exact same issue for me, except here was my  System:
$ uname -a
Linux DietPi 6.1.21-v7+ #1642 SMP Mon Apr  3 17:20:52 BST 2023 armv7l GNU/Linux
$ cat /etc/issue.net
Debian GNU/Linux 12
$ grep Model /proc/cpuinfo
Model           : Raspberry Pi 2 Model B Rev 1.1

Thank you @felddy!

I currently have the same issue.
However, when I create the patch file in my /data directory, docker doesn't seem to be able to find it.
The log:
Entrypoint | 2023-08-31 14:36:34 | [info] Using CONTAINER_PATCHES: /Data/container_patches
Entrypoint | 2023-08-31 14:36:34 | [warn] Container patches directory not found.
The important parts of the docker-compose.yml look like this:
volumes:
- type: bind
source: /home/pi/Foundryv10
target: /data
environment:
- FOUNDRY_PASSWORD=XXX
- FOUNDRY_USERNAME=XXX
- FOUNDRY_ADMIN_KEY=XXX
- FOUNDRY_PROXY_PORT=XXX
- FOUNDRY_PROXY_SSL=true
- CONTAINER_PATCHES=/data/container_patches
I created the file in Foundryv10/data/container_patches.
Was this the wrong path?

Hi,
Solution don't work on my system.
Raspberry Pi 4 Model B Rev 1.2


Implementation detail: Why does FastList extend ArrayList?

At first glance, it seems like a waste of space that com.zaxxer.hikari.util.FastList extends java.util.ArrayList, as you don't reuse any fields or methods from ArrayList.
The implementation of an empty ArrayList by Oracle may not use a lot of space, but this is implementation dependant and the fields are using heap space nonetheless.  Why not just extending AbstractList or implementing List directly? Seems like a low hanging fruit to save a few Bytes.
Also, having an instance of ArrayList that is actually a FastList may lead to surprising behaviour, as FastList does not support many operations that are supported by ArrayList.

Pull request welcomed. 😀


Image upload

Could we have images uploading feature?
Thanks in advance.

+1!
Love this tool but it would definitely be amazing to give users the ability to upload screenshots attached to the issue.

related to https://github.com/schneidmaster/gitreports.com/issues/114

As a workaround, in the prompt, I mentioned the following
Use https://ufile.io/ to share files, images, videos of the report and paste the share link(s) here
It would be nice to have some sort of integration though (whether own web server or some service such as this)

Would it be possible to upload an image to https://user-images.githubusercontent.com?


Using chai libraries to save work

Hey! I’m the current lead maintainer of chai, a friend linked me this project, looks cool!
We’ve been slowly extracting useful parts of chai out into separate modules which we hope will help other libraries (like this one) and also help to make chai better.
I noticed you have a couple of open issues around things like a plugin system, and better error messaging, I also notice you’re missing some assertions like deepEqual.
The libraries we’ve extracted so far:

deep-equal (https://github.com/chaijs/deep-eql) - used for .deep.equal()

type-detect (https://github.com/chaijs/type-detect) - used for chais .to.be.a() style assertions

loupe (https://github.com/chaijs/loupe) like nodes util.inspect, used for error messages

pathval (https://github.com/chaijs/pathval) which converts strings to property lookups, used in the .to.have.nested.property style assertions

plugin-use (https://github.com/chaijs/plugin-use) which we just released today aims to provide a plugin system which will be the basis of chai 5 which is undergoing a ground up rewrite to use ES modules and typescript.

There’s a few more which have even more specific requirements, but I think some of these might be very beneficial to you.
As an aside, if you feel like you want to contribute to chai, feel free to get in touch. It’s an old project and lots of people use it, so we can’t move as quickly as a new library without annoying/losing lots of existing users, but contributing back to chai means you can impact millions of users!

Hey!
Thanks so much for getting in touch! I will for sure take a closer look at extracted chai's libs.
But I need to state that one of the goals of the project is to rethink decisions that were taken in Chai (and similiar libs) and see if we can come up with something better (lets hope at least!). That's why for example earl is deepEq by default, also we have custom approach to to.be.a style checks. And finally, everything is written in TS and we are 100% committed to type-safety which forces some design decisions.
That being said, thanks again for creating these packages. If we're not gonna use them, in the worst case we will get inspired by your code and test cases ;)
Best,
Kris


installation on Mac

I had to slightly change the Cmake command from:
CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=../install ../src/fringe
To the following to install the package on my Mac:
CXX=clang++ cmake -DCMAKE_FIND_FRAMEWORK=NEVER -DCMAKE_INSTALL_PREFIX=../install ../src/fringe
Before issuing a PR I wanted to make sure if others have experienced this?
@piyushrpt @yunjunz @yjzhenglamarmota

Just my 2¢ but, I always use this option on macOS so my cmake PR recommends it in the isce2 readme. https://github.com/isce-framework/isce2/pull/136/files#diff-04c6e90faac2675aa89e2176d2eec7d8R324-R329

Yep. Need it to circumvent the default framework.

I got the cmake -DCMAKE_FIND_FRAMEWORK=NEVER -DCMAKE_INSTALL_PREFIX=../install ../src/fringe to work on my Mac, but I am having trouble with it not finding the mpi.h file on build.
make all
[ 10%] Built target calamplib
[ 21%] Built target ampdispersionlib
[ 25%] Building CXX object src/nmap/CMakeFiles/nmaplib.dir/nmaplib.cxx.o
In file included from /Users/fielding/tools/Fringe/build/src/nmap/nmaplib.cxx:629:
In file included from /Users/fielding/tools/Fringe/src/fringe/src/nmap/./nmap.cpp:9:
In file included from /opt/local/include/armadillo:75:
In file included from /opt/local/include/armadillo_bits/include_hdf5.hpp:30:
In file included from /opt/local/include/hdf5.h:22:
/opt/local/include/H5public.h:63:13: fatal error: 'mpi.h' file not found
#   include <mpi.h>
            ^~~~~~~
1 error generated.
make[2]: *** [src/nmap/CMakeFiles/nmaplib.dir/nmaplib.cxx.o] Error 1
make[1]: *** [src/nmap/CMakeFiles/nmaplib.dir/all] Error 2
make: *** [all] Error 2


Azure DevEx Architecture Board: Review of Content Moderator vNext

New SDK Review meeting has been requested.
Service Name: Content Moderator vNext
Review Created By: Jinrui Shao
Review Date: March 21, 2023 4:05 PM PT
Hero Scenarios Link: here
Architecture Diagram Link: Not Provided
Core Concepts Doc Link: Not Provided
APIView Links: .NET, Python, Java,
Description:
Detailed meeting information and documents provided can be accessed here

@jinruishao,
Wanted to ask if you could also add an API View for JavaScript.

Meeting updated by Jinrui Shao
Service Name: Content Moderator vNext
Review Created By: Jinrui Shao
Review Date: 3/21/2023 4:05 PM PT
Hero Scenarios Link: here
Architecture Diagram Link: Not Provided
Core Concepts Doc Link: Not Provided
APIView Links: Python, .NET,
Description:
Detailed meeting information and documents provided can be accessed here

Hi @jinruishao,
I wanted to ping here again. It looks like we're still missing a JavaScript API View and the Java API View link was removed. Please add API Views for these two languages at least 48 hours before the meeting so the architects have time to review the materials.

Hi @jinruishao,
Wanted to ping again on my question above.

@ronniegeraghty As Jinrui replied in email thread, we will generate SDK and APIView for .NET and Python currently. And note that there is rebranding recently and we will use "ContentSafety" as the service name.
Here are the APIView and SDK Links:
APIViews:
TypeSpec: https://apiview.dev/Assemblies/Review/3aeb9b2a675b4c42bbaabeb24fe8169e
Python: https://apiview.dev/Assemblies/Review/f2c6e64aeb4f47ae892d2778a7ffc5af
.NET: https://apiview.dev/Assemblies/Review/d1fee5210fa34184bca6003f087171e3
PRs:
TypeSpec Original Approved PR: https://github.com/Azure/azure-rest-api-specs-pr/pull/9275
TypeSpec Renamed: https://github.com/mengaims/azure-rest-api-specs-pr/tree/temp-renamed/specification/cognitiveservices/ContentSafety
Python: https://github.com/Azure/azure-sdk-for-python/pull/29390
.NET: https://github.com/Azure/azure-sdk-for-net/pull/34933

For JavaScript RLC the package name would be @azure-rest/ai-content-safety

For Java, the package name would be azure-ai-contentsafety.


Add MailController

Project URL
https://github.com/Kulich-ua/MailController
Category
Networking
Description
Add MailController to the Email subcategory of the Networking category.
Why it should be included to awesome-ios (mandatory)
MailController is a lightweight Swift wrapper around MFMailComposeViewController, which provides you with a convenient interface. It eliminates the use of delegation pattern and instead provides a block-based API if necessary.
Checklist

[x] Only one project/change is in this pull request
[x] Has unit tests, integration tests or UI tests
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 4 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Warning

:warning:
Found 11 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

206
403
https://www.udemy.com/arkit-beginner-to-professional/?couponCode=CREATORS

547
301
https://developer.couchbase.com/mobile/ redirects tohttps://www.couchbase.com/products/mobile/

930
301
https://github.com/schibsted/layout redirects tohttps://github.com/nicklockwood/layout

1003
301
https://github.com/caffe2/caffe2 redirects tohttps://github.com/facebookarchive/caffe2

1174
301
https://github.com/bakkenbaeck/Viewer redirects tohttps://github.com/3lvis/Viewer

1683
301
https://github.com/VirgilSecurity/sdk-x redirects tohttps://github.com/VirgilSecurity/virgil-sdk-x

1706
301
https://github.com/VirgilSecurity/crypto-x redirects tohttps://github.com/VirgilSecurity/virgil-crypto-x

2450
301
https://github.com/hyperoslo/Dropdowns redirects tohttps://github.com/onmyway133/Dropdowns

2706
301
https://github.com/bakkenbaeck/SectionScrubber redirects tohttps://github.com/3lvis/SectionScrubber

3097
301
https://developer.apple.com/app-store/review/rejections/ redirects tohttps://developer.apple.com/app-store/review/#common-app-rejections

3152
301
https://github.com/hyperoslo/SwiftSnippets redirects tohttps://github.com/onmyway133/SwiftSnippets

  Generated by :no_entry_sign: Danger

Hi @kulich-ua . Thanks for contributing.
Seems like a project with few functionalities. According our Contribution Guidelines we cannot merge. Sorry.

Hi @vsouza, thank you for the feedback, I understand.


waifu2x not recognizing CUDA driver :(

NVIDIA CUDA

???

Shit, i just realized I downloaded the wrong file. What the hell did i just install lol
https://developer.nvidia.com/cudnn

Okay, so I downloaded cuDNN and dropped it in the waifu2x directory...

...but I'm still getting this error :(

what am i doing wrong this time???

cuDNN needs a CUDA GPU that has Compute Capability of at least 3.0. GeForce G105M's Compute Capability is only 1.1.

すいません、要求環境には書かれていませんでしたがCUDAで計算するにはCompute Capability 2.0以上のGPUが必要です。
@HolyWu さんが書かれている通りGeForce G105MのCompute Capabilityは1.1なので、CUDAで計算することは出来ません。

Aww man, you guys know how to ruin someone's day. The cpu takes about four minutes to convert a single image, was hoping to speed that up somehow :(

You can try another waifu2x converter that supports OpenCL and SIMD optimization.

I will give that one a try, thank you for all your help :]

EM... So, that program doesn't work on AMD?
I tried to run it with CPU, but... Nothing happens, estimated time is endless... I don't know what to do.


Image URL error

"message": "Trying to get property 'url' of non-object",
"exception": "ErrorException",
"file": "/demo/vendor/tipoff/escape-room/src/Models/EscaperoomTheme.php",
"line": 126,
EscaperoomTheme.php:
public function getIconUrlAttribute()
{
return $this->icon->url;
}
images dont have a url attribute?

I think in escaperoom_themes table 'icon_id' should be a required attribute i.e. 'NOT NULL'


u-boot:sf:get the permission before operating the device

When flash protect is enable,write or erase the flash would not reminder any error.
It would show "erase Ok",but actually erasing the flash is not success
Check the write protection status before operating the device
Signed-off-by: Chao Zeng<EMAIL_ADDRESS>

no respond from u-boot.
this feature I think could keep at local firstly.

Keep it locally at this moment, due to need delivery to testing.

This has style issues (checkpatch is your friend).
What's the link to the upstream discussion?


Add polyfill for Game Boy Advance

At present the system assumes that all Thumb targets other than thumbv6m-none-eabi have full support for atomics up to 32-bit, which isn't correct since prior to ARMv6 there was no hardware support for atomics at all. In Rust this primarily affects the bare-metal target thumbv4t-none-eabi (which was added for the Game Boy Advance - since we now have armv6k-nintendo-3ds it might be due for a rename to something like armv4t-nintendo-gba, but according to Lokathor the generic name was actually requested by the rustc developers so who knows) since Linux provides its own userspace support.

GBA, exciting! :)
Does the GBA hardware guarantee 32bit loads/stores (non-CAS) are atomic? it seems to me it should. Does Rust core::sync::atomic allow that? If it does, the level should be CAS, not Full. If it doesn't maybe it suffers from the same issue as riscv32imc, where we set it to Full but to workaround lacking support in Rust, not in hardware.
Also, could you update the table in the README?

Does the GBA hardware guarantee 32bit loads/stores (non-CAS) are atomic? it seems to me it should.

I believe so.

Does Rust core::sync::atomic allow that? If it does, the level should be CAS, not Full. If it doesn't maybe it suffers from the same issue as riscv32imc, where we set it to Full but to workaround lacking support in Rust, not in hardware.

I confess I don't fully understand how Rust goes from what a target specification says about a target's atomics support to the target_has_atomic feature which is used to enable/disable stuff in core::sync::atomic, but from a cursory glance it appears that the latter is the case.

Are you using this with a custom critical-section impl? The default tries to use cortex-m which is wrong. Do you have the code for it somewhere?

There's also the I bit in CPSR, which is standard in all ARMv4/ARMv5 cores, so maybe we could add that to critical-section


Updating button selectors for hotkey mapping

Update button selectors for hotkey mapping
Updating the selectors for media keys and thumbs up/down to match with the new version of Google Play Music.

Author: Marcos Mellado<EMAIL_ADDRESS>

Hello. Thanks for your pull request. Could you reformat its description according to a draft of Contributor guidelines (section Pull Requests)? Thanks :-)

Sorry about that! I'll update my pull request over the weekend. This is actually my very first time contributing to anything through github so I'm very new to this process. To fix this I just need to do a git commit --amend right?

To fix this I just need to do a git commit --amend right?

You don't have to amend the commit message. Just change text of the description of this pull request at GitHub website (the first comment) so I can copy-and-paste it without modifications and save some time.

Updated comment :)

Merged. I've changed the summary to "Update selectors of media actions and rating" as there is no hotkey mapping in the scripts actually (the hotkey mapping occurs elsewhere). Thanks for your pull request :+1:


attach displayName to forwardRef function as described in React docs

This addresses #2507

ok, I guess it wasn't that easy ;)

This needs some more testing I think.

@probablyup Any chance of getting this published? I think it might fix an issue I am running into.

I’ve been in the hospital so I really can’t. But if one of the other core
collaborators wants to they can.
On Wed, May 15, 2019 at 2:35 PM Chase McCoy<EMAIL_ADDRESS>wrote:

@probablyup https://github.com/probablyup Any chance of getting this
published? I think it might fix an issue I am running into.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/pull/2508?email_source=notifications&email_token=AAELFVVSYY7UKOTN3IG3SDTPVRQYTA5CNFSM4HGYPYWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVPXB7A#issuecomment-492794108,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAELFVSL57KJSEC7NHZVHH3PVRQYTANCNFSM4HGYPYWA
.

So sorry to hear that. All the best to you, focus on getting well and thank you so much for your contributions here.

@probablyup Oh no! Hope everything is well, and thank you for all your hard work on styled-components!


Withdraw: fee in dollar (2)

see #3791 (some additions have been added)
Checklist

[x] I have read the CONTRIBUTING guide
[x] Good naming, keep simple
[x] Tested desktop/mobile
[x] Tested bright/dark
[x] Tested en/ru
[ ] Affects money; I checked the functionality once again
[x] I checked the PR once again

Original issue
#3788

проверил биток и usdt вроде все верно посчитало и отправило


[HELP] Unable to get TextView wrapping to have the wanted behaviour.

I have a TextView widget inside a ScrolledWindow. I wanted to wrap word inside the text view so I set the wrap mode to "word-char" which works as expected except one thing. The text view does not recognise tabs and extends until I enter a word. The word then wraps around but the tab remains the same. As such when I move the cursor back, the end of next line is far along the right side where I had tabs. How do I get the TextView to wrap around tabs as well?

Please use the discussions for "questions", https://github.com/gtk-rs/gtk4-rs/discussions

Otherwise this sounds like an issue/intended behaviour that comes from the library itself, so I would suggest opening an issue at https://gitlab.gnome.org/GNOME/gtk/


RSS 피드

As mentioned above the html field was removed from the GraphQL node. We know that some of you used this for e.g. gatsby-plugin-feed. Unfortunately, for compatibility and performance reasons we had to remove it. We recommend using the excerpt field in the meantime until we find a feasible solution to provide MDX rendered as HTML. If you have any suggestions, please comment on the GitHub Discussion.

https://www.gatsbyjs.com/plugins/gatsby-plugin-mdx/#v3-to-v4-breaking-changes


chore(doc): fix example

What does this PR do?
fix example code error.

Related issues
Does this PR introduce any user-facing change?

[ ] Does this PR introduce any public API change?
[ ] Does this PR introduce any binary protocol compatibility change?

Benchmark

@chaokunyang hi, can you help review this?


[Scenario] Horror Haunts Merinda

What kind of mission do you want to add (mark with an X, e.g. [X] Descent)?

[x] Mansions of Madness
[ ] Descent

Please enter the GitHub Url to your scenario here
https://github.com/Drake3/MOM/tree/master/Horror_Haunts_Merinda
Thanks for uploading.

Added should be listed within the hour


[CLOUDSTACK-10128] Simplify the search for host to execute command

@mike-tutkowski found a problem in #2315 when converting a snapshot to a template from a storage pool that has been deleted. Following his feedback in #2298 I am creating this PR to address the issue.

reviewers (@DaanHoogland, @mike-tutkowski, @rhtyd ) what is your positions here? It seems that the tests passed and we have a consensus. If you are ok with this one, I would like to proceed and merge this to 4.11 and then forward to 4.12 (master branch)

Yes, per my prior comments, the code LGTM and the two tests that previously failed now pass.

@mike-tutkowski thanks!
I am getting used to look directly to the "reviweres" section on Github and checking the approved ones. I did not seen any for this PR, that is why I asked again.

Sounds good - we should all get used to marking that field.
On Feb 19, 2018, at 12:46 PM, Rafael Weingärtner <notifications<EMAIL_ADDRESS>wrote:
@mike-tutkowskihttps://github.com/mike-tutkowski thanks!
I am getting used to look directly to the "reviweres" section on Github and checking the approved ones. I did not seen any for this PR, that is why I asked again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/apache/cloudstack/pull/2402#issuecomment-366798899, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AC4SHxDTguzYeKeTROs1yhRE0tmZFpSMks5tWd2pgaJpZM4RasNN.

Since everything is ok, I will merge this one.
Let's see if I still know how to do it :)


Amit/roger 989 Added authorize logic for allowed users and actions

@vmahedia , @ankanm and @04msambit Please review:

LGTM

LG apart from comment above.


Reproduction of results on Table4

How the w/o fine-tuning results in Table 4 are derived?
I tried to use -mode ori to generate a pre-trained model of stgcn on PEMS07M, but the pretrain mode in the code only yields results after enhancement with FlashST.

Hello. You can use the same pre-training data as FlashST to pre-train on different baselines, and then proceed to testing.
If you use the "ori" mode, you can assess the original performance of the baseline models, rather than the performance enhanced by FlashST.


Please invite me to the GitHub Community Organization

Name
Ritwik Sinha
Discord Username (if applicable)
No response
Additional Context
I am contributing more and more in open source projects and I think this org can give me more I want.

Welcome to the EddieHub community, @Ritwik880, where we believe Collaboration 1st, Code 2nd! 😄👋🎉


bug(anvil): debug_traceTransaction does not work for local txs (after fork)

Component
Anvil
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (588a1d7 2024-06-19T00:23:02.274658000Z)
What command(s) is the bug in?
anvil
Operating System
macOS (Apple Silicon)
Describe the bug
Trying the callTracer tracer with debug_traceTransaction
It works for transactions that have been mined previous to the fork. But transactions added to the chain after the fork locally do not return the call trace.
Example
{"jsonrpc": "2.0","id": "123","method": "debug_traceTransaction","params": ["0x2d70cab1a3481c03fecf2909192cfa6601fb60b3239d982694cfa787e44f2d1e", {"tracer": "callTracer"}]}

{
    "jsonrpc": "2.0",
    "id": "123",
    "result": {
        "failed": false,
        "gas": 119470,
        "returnValue": "",
        "structLogs": []
    }
}

All trace types in fact return this same response.
Works completely fine for transactions that are mined before the fork. I suppose as they result in a direct call to the node.

@monokh I'm unable to repro this result. debug_trace_transaction is working correctly for txs sent locally after forking.


Investigate Waffle vs Truffle

Personally I'd love to have truffle on waffle~
Background
It seems like py-solc is not really updating to support latest solidity. We can update that but whether we want to maintain that ourselves is a question. It seems like a good timing to move away.
Also, related to previous audit recommendation: https://www.pivotaltracker.com/story/show/161138286
So one obvious option is truffle. However, Pepesza points out there's another framework called Waffle might be an alternative.
Some links for Waffle:
https://github.com/EthWorks/Waffle
https://medium.com/ethworks/meet-waffle-8e630e5e9e91
What to do here
Let's put some reasoning, pros and cons on the two choices. Ideally make decision.

@jbunce – relevant to your interests.
(Jake would buy you a 🍩 if you decoupled contract deployment from elixir-omg.)

Truffle provides tooling for compiling, deploying and testing smart contracts. Its deployment toolset allows you to deploy to any Ethereum network (local, Rinkeby, mainnet, etc.). One nice feature about it is that tests can be written in Solidity as well as Javascript.
Waffle's focus is on testing. It can compile smart contracts but not deploy them. All tests are run against a bundled Ganache. It provides some Chai extensions to make tests easier to write e.g. expect(contract.method).to.emit(contract.Event)
eth-tester is the Python testing framework that we currently use. It does not provide tooling for either compiling or deploying smart contracts. Currently we use py-solc for compiling, but development on it appears to have halted and it's not compatible with Solidity 0.5
Any of the three tools can handle testing. However if we want to continue writing tests in Python, then eth-tester will probably need to be combined with one of the other two to compile Solidity 0.5 contracts.
I think it's a separate issue - but the possibility of using Truffle instead of dev_helpers to deploy the RootChain contracts has been raised. If that goes ahead, then it seems sensible to use Truffle here as well (instead of Waffle), at least for compiling the smart contracts.
I don't have a string opinion about writing tests in Javascript or Python. On one hand javascript is better integrated with Truffle and would be easier to setup and maintain. On the other hand there are already a lot of tests written in Python as well as experienced Python (and javascript averse) devs on the team…
TLDR: I think it makes more sense to go with Truffle rather than Waffle for compilation and deployment.
What the tests are written in depends on whether the Pythonistas want to learn Javascript or not 😬

I think it's a separate issue - but the possibility of using Truffle instead of dev_helpers to deploy the RootChain contracts has been raised

@jbunce @kasima I don't think a separate issue has been created for this yet, but I do think it belongs in elixir-omg rather than here, as it deals with replacing the current dev_helpers stuff with truffle. I'm open to being convinced otherwise though...

Some comments:

a note on Python and testing: AFAIK, Python + testing on ganache (getting rid of eth-tester itself) is an option too, and has been considered and postponed. It is however then reliant on web3.py whose status/future I'm not up-to-date about.
I'd favor getting rid of eth-tester in tests but remaining in Python-world, in general. But if the js-tooling is orders of magnitude better than Python's then, sigh, ok :).
Notwithstanding, there's a lot of tests there...
"the possibility of using Truffle instead of dev_helpers" - a reminder - truffle or not, dev_helpers shouldn't be used for anything production-like in the long run. State we're in now has always been an interim workaround to get ramped up with deployments. It is intended to be used by elixir-omg-specific integration tests.
Having said that, there still is an option of leveraging Truffle in dev_helpers somehow, but let's treat it separately from what Jake needs to roll his deployments conveniently. I think the technical requirements for those two tools diverge substantially.

@kevsul I've opened https://github.com/omisego/elixir-omg/issues/734 for discussion

Note from abstract layer migration plan meeting:

Waffle is basically out.
Let's separate the concern/issue of deployment and testing
Main concern on moving tests to truffle is on team's knowledge. Before the team is familiar with this new testing framework/language, the migration of the test suite might mean people not familiar on the assumption of them. And this might decrease the security in this sense.
Let's have a small call compare js testing POC and python to decide
in-house solution vs more standard solution

My personal 2 yen on testing in general:
Python + Web3.py + Ganache:

Python is a small plus (personally prefer python, but js with async/await + class, fairly speaking, is not that much different in coding experience)
Web3.py is a minus (it is in jsCodeStyle instead of python_code_style + from experience usually not as updated as web3.js)
Ganache setup is a small minus, slightly more complex to setup. (Need to run a process in beneath on the starting of test and pipe out the std output to remove noise messages, and, kill the process afterward)

JS + Truffle:

Easier setup, fairly straight forward to write and run
I think Mocha is slightly better than pytest in test description (customized sentence vs function name)

If people are curious how js test code looks like: JS example test code by @pgebal
re: Security-wise concern:

Short term, yes, if our team is not familiar with these new tools. However, long term speaking, consider the (sad) fact there is just more tooling in js rather than python in blockchain world, when we get any new hirings, the benefit of this just keep decreases. Also, this means we get less support community-wise.
I am pretty confident we can provide as good quality tests in js than in python. It is more about a matter of time and effort.

Again, I like python more than js. However, I am bringing this out because I think testing with truffle is a more widely used practice and the js toolings would bring us long term value (and sadly web3.py is just....a really badly written lib IMO). Also, I see this as probably our last chance to make this switch. With the huge change of abstract layer, the extra effort to switch might be justify-able at this moment. As more and more tests are added, the switch would just become a less feasible choice in the future.

I totally agree with @boolafish
I also prefer Python, but modern javascript has copied so much from Python that it's almost pleasant to use nowadays...
Truffle is very actively maintained and keeps improving. I know that there's an initial cost to learning it, but using it saves us from spending resources on our homegrown test framework.

What was the reason for throwing out waffle? Deployment tooling?

@kasima yeah, it does not help deploy, and we probably don't want to have two new tools (like deploy in truffle and test in waffle).

Is the jury still out? The latest is a fight (what I gather from @boolafish )
Python + Web3.py + Ganache  or  JS + Truffle?
I think that with a bit of help we could do the deployment part because we need it most. But we definitely need a decision asap.
cc @jbunce

Hi I'd like to give my 2 cents as well. I've had a lot of discussions with the ODP people. A lot of dApp + tooling level developers seems to have preferences for truffle.js and have even asked a few times for a way to deploy the plasma contract in either a container or a deployment tool that is decoupled from the codebase. In both of these instances- their stack is JavaScript.
I would argue that 90% of smart contracts deployment process is done with Truffle.

Note for Action item in the meeting:

[ ] Collect how much time needed to migrate the tests to js.

[Notes of the meeting]

Port existing python with py-solcx that supports existing tests
Write tests in each PR with JS. Implementer and code reviewer should double check with existing python test case. We would try to port existing code to js in this flavor on the way of building it.


From 1.37, GLTF shader paths are relative, even when starting with a slash

Hi,
I used to specify custom shaders in my GLTF files in this manner:
"uri": "/shaders/mappedReflectiveFS.glsl"
This should load the file from the root of the web host (http://domain.com/shaders/mappedReflectiveFS.glsl)
Instead, and starting with Cesium 1.37, the shaders are loaded relative to the GLTF's directory even if the uri starts with a slash.
Regards,
Xavier.

Thanks for the report @xtassin, this definitely sounds like a clear cut bug.  @lilleyse or @emackey any ideas?

Definitely sounds like a bug.  There's been some discussion of root-relative paths on the official glTF repo lately, but nothing that should prevent this from working.

Sorry to bump this but can we expect a fix in upcoming releases or is this something I should be looking into myself?
Thanks.

@xtassin we would love to get this fix in, but no one has had a chance to look at it yet.  It should be pretty straight forward so I think it would make a great first pull request if you have the time or desire to tackle it yourself.
If not, thanks for bringing it to our attention anyway and I marked this a priority so we don't forget about it.

Actually I recently opened a PR to add file support to joinUrls in #5989, and while I was in there I noticed that joinUrls always concats them, taking care to get the slashes right, but not cancelling out any base path if the 2nd URL is a root-relative URL.  It looked like intended behavior, as .. is not supported there, and the unit tests very specifically test for that behavior.  Maybe it used to be different?  Or maybe glTF in Cesium didn't used to depend on this?
If someone has time to run git bisect on this, to nail down exactly what changed to cause the break, that would be a great for understanding this.  I'm a little swamped with non-glTF stuff at the moment sadly.

All usage of uri.resolve have been replaced by joinUrls in model.js (and possibly in other places) during "Misc changes and helpers from 3d-tiles #5249"
The fix could be to handle root relative url in joinUrls but I am not sure of your view on that.

I checked that this has since been fixed after the resource loading overhaul. Paths starting with a slash should now point to the server root directory.


Cloud Box Folder continuously refreshes

Description
With a synced Box cloud folder the folder refreshes every 2 seconds. No files can be viewed only folders. Tab refreshes continuously not allowing interactions with folders and files within the box folder.
Steps To Reproduce

Click on Cloud Drives
Select "Box" folder
Watch box folder continiously refresh

Expected behavior
Expect box folder to load once and only refresh on open.
Files Version
Version: <IP_ADDRESS> OS Version: 10.0.22000.493
Windows Version
Windows 11 21H2
Relevant Assets/Logs

#7428