haskell: remove unused LDFLAGS in generic-builder

Once haskell has found a package.conf.d file, it no longer needs the
traditional -L flag. This commit removes the additional arguments from
NIX_LDFLAGS to prevent some systems from hitting the ARG_MAX limit.
This should accomplish the same thing as moving the $libdir somewhere
else without some of the breakages that would come with.
I don't have a macOS machine right now so cannot verify that this fixes the original issue. I can verify that it correctly removes the extra args from NIX_LDFLAGS though.
/cc @angerman @peti @Ericson2314 @domenkozar @nh2

@grahamcofborg build haskell.packages.ghc821Binary.aeson

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: haskell.packages.ghc821Binary.aeson
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Failure on x86_64-linux (full log)
Attempted: haskell.packages.ghc821Binary.aeson
Partial log (click to expand)
[14 of 24] Compiling Data.Aeson.Internal.Time ( Data/Aeson/Internal/Time.hs, dist/build/Data/Aeson/Internal/Time.o )
[15 of 24] Compiling Data.Aeson.Encoding.Builder ( Data/Aeson/Encoding/Builder.hs, dist/build/Data/Aeson/Encoding/Builder.o )
[16 of 24] Compiling Data.Aeson.Encoding.Internal ( Data/Aeson/Encoding/Internal.hs, dist/build/Data/Aeson/Encoding/Internal.o )
[17 of 24] Compiling Data.Aeson.Encoding ( Data/Aeson/Encoding.hs, dist/build/Data/Aeson/Encoding.o )
[18 of 24] Compiling Data.Aeson.Types.ToJSON ( Data/Aeson/Types/ToJSON.hs, dist/build/Data/Aeson/Types/ToJSON.o )

<no location info>: error:
    <command line>: can't load .so/.DLL for: libHSprimitive-<IP_ADDRESS>-9BHPmR1c3jBGsNX8V107zp.so (libHSprimitive-<IP_ADDRESS>-9BHPmR1c3jBGsNX8V107zp.so: cannot open shared object file: No such file or directory)
builder for '/nix/store/hzb8vsgif9znrbivk20layd442cffhqh-aeson-<IP_ADDRESS>.drv' failed with exit code 1
error: build of '/nix/store/hzb8vsgif9znrbivk20layd442cffhqh-aeson-<IP_ADDRESS>.drv' failed

Failure on x86_64-darwin (full log)
Attempted: haskell.packages.ghc821Binary.aeson
Partial log (click to expand)
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
[13 of 24] Compiling Data.Aeson.Internal ( Data/Aeson/Internal.hs, dist/build/Data/Aeson/Internal.o )
[14 of 24] Compiling Data.Aeson.Internal.Time ( Data/Aeson/Internal/Time.hs, dist/build/Data/Aeson/Internal/Time.o )
[15 of 24] Compiling Data.Aeson.Encoding.Builder ( Data/Aeson/Encoding/Builder.hs, dist/build/Data/Aeson/Encoding/Builder.o )
[16 of 24] Compiling Data.Aeson.Encoding.Internal ( Data/Aeson/Encoding/Internal.hs, dist/build/Data/Aeson/Encoding/Internal.o )
[17 of 24] Compiling Data.Aeson.Encoding ( Data/Aeson/Encoding.hs, dist/build/Data/Aeson/Encoding.o )
[18 of 24] Compiling Data.Aeson.Types.ToJSON ( Data/Aeson/Types/ToJSON.hs, dist/build/Data/Aeson/Types/ToJSON.o )
<command line>: can't load .so/.DLL for: libHSprimitive-<IP_ADDRESS>-9BHPmR1c3jBGsNX8V107zp.dylib (dlopen(libHSprimitive-<IP_ADDRESS>-9BHPmR1c3jBGsNX8V107zp.dylib, 5): image not found)
builder for '/nix/store/01glywapkq5205rql032zmbarwac7wzv-aeson-<IP_ADDRESS>.drv' failed with exit code 1
error: build of '/nix/store/01glywapkq5205rql032zmbarwac7wzv-aeson-<IP_ADDRESS>.drv' failed

@grahamcofborg build haskellPacakages.aeson

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: haskellPacakages.aeson
Partial log (click to expand)
Cannot nix-instantiate `haskellPacakages.aeson' because:
error: attribute 'haskellPacakages' in selection path 'haskellPacakages.aeson' not found

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: haskellPackages.aeson
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: haskellPacakages.aeson
Partial log (click to expand)
Cannot nix-instantiate `haskellPacakages.aeson' because:
error: attribute 'haskellPacakages' in selection path 'haskellPacakages.aeson' not found

No attempt on x86_64-linux (full log)
The following builds were skipped because they don't evaluate on x86_64-linux: haskellPacakages.aeson
Partial log (click to expand)
Cannot nix-instantiate `haskellPacakages.aeson' because:
error: attribute 'haskellPacakages' in selection path 'haskellPacakages.aeson' not found

@grahamcofborg build haskellPackages.aeson

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: haskellPackages.aeson
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

haskell.packages.ghc821Binary.aeson is broken in master apparently.

Failure on x86_64-darwin (full log)
Attempted: haskellPackages.aeson
Partial log (click to expand)
cannot build derivation '/nix/store/y1wkhgkgnssk5864fv7vvjwry6c29alc-tasty-quickcheck-0.10.drv': 9 dependencies couldn't be built
cannot build derivation '/nix/store/9fs67lhn1735an8w74x6b5y55m4gx70b-base-orphans-0.7.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/6zz43lqpng19qj1439izzd8sp30psabd-generic-deriving-1.12.2.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/cxkyag0sgv0qbbg2nkwpy2nl9nn8fb6w-uuid-types-1.0.3.drv': 10 dependencies couldn't be built
cannot build derivation '/nix/store/613g1y5wrl6341f46x0imljhvs4lsf7l-tasty-ant-xml-1.1.4.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/s7mmzgk24dpyb2ll7rbfpfqfvw8lhcza-scientific-<IP_ADDRESS>.drv': 12 dependencies couldn't be built
cannot build derivation '/nix/store/by703w7aqvx90n5g06cakcwj8qacj821-attoparsec-<IP_ADDRESS>.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/9hvjpzyi25i4zpizx0rfzrz528qliaia-quickcheck-instances-0.3.18.drv': 13 dependencies couldn't be built
cannot build derivation '/nix/store/q3m6rdqjjbbsxzsxb7vi9vqdk8k9a52z-aeson-<IP_ADDRESS>.drv': 25 dependencies couldn't be built
error: build of '/nix/store/q3m6rdqjjbbsxzsxb7vi9vqdk8k9a52z-aeson-<IP_ADDRESS>.drv' failed

Failure on x86_64-linux (full log)
Attempted: haskellPackages.aeson
Partial log (click to expand)
cannot build derivation '/nix/store/11c7ld4ky104pbic8cml42gzvnrmlws9-tasty-quickcheck-0.10.drv': 9 dependencies couldn't be built
cannot build derivation '/nix/store/yhqzyz5w2zymvh37yx3f1ms7ydqy17d8-base-orphans-0.7.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/r7dqa6kxv4gh9j9zgkazmd8z5ipj4awd-generic-deriving-1.12.2.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/ahpp96yyjdfxdz2qslq2czn9nwm67jag-uuid-types-1.0.3.drv': 10 dependencies couldn't be built
cannot build derivation '/nix/store/arzpmycwc4kba5idq880mfsnkrhlrry5-tasty-ant-xml-1.1.4.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/rv8xk8wl7vmx4c7y1mjypr7q3bawlhlc-scientific-<IP_ADDRESS>.drv': 12 dependencies couldn't be built
cannot build derivation '/nix/store/yj689hd526j91xaz1xgf9d0414ylgfv8-attoparsec-<IP_ADDRESS>.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/rmz0jrdi10aknmdxw70h9bh88rlli6hk-quickcheck-instances-0.3.18.drv': 13 dependencies couldn't be built
cannot build derivation '/nix/store/833as91vmwjv3gqya9invsvrni84ay2n-aeson-<IP_ADDRESS>.drv': 25 dependencies couldn't be built
error: build of '/nix/store/833as91vmwjv3gqya9invsvrni84ay2n-aeson-<IP_ADDRESS>.drv' failed

Failure on x86_64-darwin (full log)
Attempted: haskellPackages.aeson
Partial log (click to expand)
cannot build derivation '/nix/store/y1wkhgkgnssk5864fv7vvjwry6c29alc-tasty-quickcheck-0.10.drv': 9 dependencies couldn't be built
cannot build derivation '/nix/store/9fs67lhn1735an8w74x6b5y55m4gx70b-base-orphans-0.7.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/6zz43lqpng19qj1439izzd8sp30psabd-generic-deriving-1.12.2.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/cxkyag0sgv0qbbg2nkwpy2nl9nn8fb6w-uuid-types-1.0.3.drv': 10 dependencies couldn't be built
cannot build derivation '/nix/store/613g1y5wrl6341f46x0imljhvs4lsf7l-tasty-ant-xml-1.1.4.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/s7mmzgk24dpyb2ll7rbfpfqfvw8lhcza-scientific-<IP_ADDRESS>.drv': 12 dependencies couldn't be built
cannot build derivation '/nix/store/by703w7aqvx90n5g06cakcwj8qacj821-attoparsec-<IP_ADDRESS>.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/9hvjpzyi25i4zpizx0rfzrz528qliaia-quickcheck-instances-0.3.18.drv': 13 dependencies couldn't be built
cannot build derivation '/nix/store/q3m6rdqjjbbsxzsxb7vi9vqdk8k9a52z-aeson-<IP_ADDRESS>.drv': 25 dependencies couldn't be built
error: build of '/nix/store/q3m6rdqjjbbsxzsxb7vi9vqdk8k9a52z-aeson-<IP_ADDRESS>.drv' failed

Couldn't some build script in principle compile and run some C code that say, generates numeric tables that get embedded in the source code or whatever? Sounds like https://github.com/NixOS/nixpkgs/pull/43713 achieves the same thing as this PR except breaking such cases.

Couldn't some build script in principle compile and run some C code that say, generates numeric tables that get embedded in the source code or whatever? Sounds like #43713 achieves the same thing as this PR except breaking such cases.

I'm a little bit confused because I think the effect of these two PRs should be the same.
I think you're right that in theory a package could have something installed in $out/lib/lib* & want it. But GHC's package.conf.d stuff provides a way to configure the location of these libraries. They shouldn't be relying on LDFLAGS anyway (through library-dirs). I think we want GHC+Cabal to handle as much here as possible.

No, I mean that a Haskell package declares a dependency on some C library, then at build time compiles and runs some standalone C code that requires that library. With this solution the C program wouldn't link.

I don't like this approach as well, because it builds on hacks of hacks. I'd rather see stdenv rebuild where we make binutils setup-hook idempotent. I'm going to give that a go.

Yes I agree, but I think the idea was to have a temporary workaround that isn't a mass rebuild to have Haskell-on-Darwin working sooner. But if you can stand a mass rebuild, I think what I proposed here https://github.com/matthewbauer/nixpkgs/commit/110b5e0b6a8db0008c5698bf6aea986b0af0df6b#r29781349 could do. It's a legit optimization as well to avoid GCC from searching directories that can't possibly contain libraries but might fix Haskell for now.
Of course the duplicate LDFLAGS issue needs fixing regardless.

If I understand that commit correctly it goes into the right direction, but we want to set LDFLAGS once and then skip the rest of invocations. strictDeps fixes that in general case of setup-hooks, but we could only fix it for binutils setup-hook.

No, what I propose does nothing to the duplicate LDFLAGS problem, it's a totally orthogonal thing. Instead, it skips adding LDFLAGS for derivations that don't contain any 'real' libraries in $out/lib, which is the case for both Haskell and Python packages.

If you limit yourself to depth 1, lots of packages will break [...]

No, it won't break. If you have some package creating $foo/lib/foo/libfoo.so, then a linker flag -L $foo/libcannot possibly be used to reach that.sofile.gcc -lfoowon't work since that would look for$foo/lib/libfoo.so. And gcc -lfoo/foowon't work either since GCC will look for$foo/lib/libfoo/foo.so`.
Though now I realize that while this should always work for Linux, I have no idea about other platforms.

Linux/BSD/macOS will likely behave quite similar and I think they adhere to the lib... convention, except for frameworks on macOS, but that’s a whole different story with different linker flags and all.
Windows is a completely different beast though. And also often sticks the .dlls into bin.  I would just ignore windows for now until we have a unified approach for windows.

@dezgeg happy to throw 10 hetzner machines to the problem if you code that up :)

I looked around a bit:

Slashes in -l arguments (like -lfoo/bar) are already unportable; ld.gold does not support them. I'm not really sure how popular ld.gold actually is, however.
Apparently, it's possible to skip the lib prefix with a syntax like gcc -l:foo.a. I have never heard of that syntax, and it's not even documented on gcc manpage, you have to look in ld manpage. And this syntax isn't supported by lld.ld on Darwin.
However with ld.lld on Darwin, using an .o suffix like -lfoo.o will search for a file named foo.o. I can't make enough sense of the binutils code to see if it happens with ld.bfd or ld.gold on Darwin... Which one does macOS use nowadays anyway? And what does Nixpkgs use there?

So, I guess there still could be a theoretical problem with this, but it would have to be quite unconventional code. I guess it's worth giving a try. I pushed an attempt at: https://github.com/dezgeg/nixpkgs/tree/binutils-lflags

No, I mean that a Haskell package declares a dependency on some C library, then at build time compiles and runs some standalone C code that requires that library. With this solution the C program wouldn't link.

Well this only removes it if it has the package.conf.d directory. I guess it's possible for there to be a c library that also has a package.conf.d directory but it seems pretty unlikely.
I definitely agree that this is a hack but it seems much safer than moving from $out/lib to $out while accomplishing the same thing.

@dezgeg macOS has its own linker ld64.

@dezgeg great, 10 Hetzner servers are crunching. I'll also test macos a tiny bit, then we can push to staging.

@dezgeg seems to be all good, can you make a PR against staging-next?

I took the liberty and pushed the commit to staging, release-small.nix builds on linux.

Ok awesome! I will close this for now. Hopefully it is no longer needed!

Can somebody update me: Is a fix for this in master by now?

Yes it is definitely in master now.

I see, it's commit 24596d7a4a4b07bd9ce3ad748b8dabf5957003c5, pulled in with 099c13da1bd5335e7e33470e6c40772ee8a6a5b9.


Updates to SharedTable

This PR addresses:
#125 Storing result table values as Double rather than String
Using the rowHeader special column rather than a 'Label' column to store image titles
#117 Filling the table from the bottom when duplicate image titles are present in the rowHeaders
#124 No more alphabetical sorting

Excellent, thank you! When the time comes to switch to scijava.table, it'll be easier to start from this version of SharedTable.

Working on that shift now in a new branch as recommended: https://github.com/mdoube/BoneJ2/tree/result-table

No need to create a new PR from that branch, I merged PR #126 because it looked good after the fixes. But next time testing your code will be easier for reviewers if it's on a topic branch :)


1.1 Should be unpublished / Android Issue React Native Video

1.1 is completely unusable on Android. My assumption is that it has been tested on iOS and not on android

Buffering takes significantly longer than it should when loading local assets
Videos that are loaded async via prepareAsync (those that don't block the UI) and have sound, only play the sound, and not the video.

This is resolved when downgrading to 1.0.0 (change package.json version to 1.0.0 not ^1.0.0 and then run npm uninstall react-native-video, then run npm install react-native-video)
I also made this change to ReactVideoView.java (node_modules/react-native-video/android/src/main/java/com/brentvatne/react/ReactVideoView.java) to fix the race conditions on local assets yet load remote assets faster:
Replace the prepare(this) line with the following block of code:
                 if(isAsset) {
          		prepare(this);
     		 } else {
     		 	prepareAsync(this);
     		 }

@Having a similar problem on the emulator. IOS works but screen on Android remains black directly after starting.
This is the code Im using. Anything maybe wrong with it?
                    <Video
                        style={{flex: 1}}
                        resizeMode="cover"
                        paused={false}
                        onError={e => console.log(JSON.stringify(e))}
                        onProgress={e => console.log(JSON.stringify(e))}
                        source={{uri: "http://<IP_ADDRESS>:8080/test.mp4"}}
                    />

@mlukasch it looks like you are not setting the video height and width

@PimDeWitte doesnt change anything. still not working. Just hangs

@PimDeWitte you should send a PR for your prepare(this)-replacement.

@itinance once it passes our internal QA i will

Any update on this @PimDeWitte? Would love to see this in the next release. Thank you!

Both the Android and ExoPlayer versions are working well for me in 2.1.0.


support negative indexing in feed/item list

This PR adds support for negative indexing to the feed and item lists, allowing users to quickly access elements from the end of a list. For example, using -1 will retrieve the last item. This improves ease of use and aligns with common indexing practices, making list navigation more intuitive.

coverage: 60.671% (-0.01%) from 60.681%
when pulling 1da6cddd1e162b4f1b7bead3d7a6cfcd11bbcc15 on notdian:feature-negative-indexing
into 74f32a983b97049ac33b72404aee61f64c3a718f on newsboat:master.

I just tested this locally.
It seems to work fine if all feeds/items are shown, but it breaks down if the list is filtered (e.g. by pressing lowercase L to only show unread items, or when applying a filter/tag)
In those cases, most (or all?) negative numbers result in an error message: "Position not visible!"
The regular, non-negative number handling goes to items based on their number in the complete/unfiltered list.
Those numbers are shown on the left side of the screen and are stable (don't change) if the list is filtered.
You can start typing these numbers, even without pressing : (the first number will automatically open the "cmdline".
I'm wondering if there are any cases where the negative indexing would be faster.
Do you have any examples where it is?
Either way, sorry for the late review.
It is always nice to see new contributors but I'm not sure if we will take in this change.


How to extract 3D mesh from a .package file

Excellent project!
Does your library support the feature of the extraction of 3D mesh from a .package file?
or just extrect the metadata of mesh geometry?
Many thanks!

For future reference, GitHub issues is not the place to ask these kinds of questions. It is meant for bug reports, questions about odd behavior, etc. You can ask these questions in my Discord server instead.
But to answer your question, you can extract anything from any package with S4TK, assuming all you want is the raw data. All you need is the resource key (type, group, instance), and you can get the file's data as a buffer.
However, if you want to process the mesh at all, you'll have to look into other tools or 3rd party libraries - S4TK does not have a model for meshes or other file types related to CC (it is primarily intended for use with gameplay mods). You can also read the docs to see what kinds of files are supported.

Thank you Frank. Your answer helps a lot.


Reduce object layout size of producers

Some producers (implementing IObservable<T>) such as SelectMany have a ton of fields to accommodate for the different overloads of the operator. Upon subscribing, the sink gets a reference to the producer, thus keeping a big object alive. We should consider increasing the granularity of producers to reduce object layouts.

SelectMany appears to be split up nicely, Merge is okay, Window is okay. I'd think this happened not long after this issue.

Probably no longer relevant.


Fix: Add missing inline comments and doc-block

This PR

[x] adds missing inline comments and doc-block to Controller\ContributorsControllerFactory

Follows #447.

:+1:


Error add slim/twig-view (composer require slim/twig-view)

Hi,
I tried adding according to the documentation (eBook Vol. 1) slim/twig-view with the below result.
Problem 1
- Root composer.json requires slim/twig-view ^3.3 -> satisfiable by slim/twig-view[3.3.0].
- slim/twig-view 3.3.0 requires psr/http-message ^1.0 -> found psr/http-message[1.0, 1.0.1, 1.1] but the package is fixed to 2.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Using --with-all-dependencies where psr/http-message will be downgraded is probably not the right way? Thank you for the answer on how to proceed correctly
Thanks Jiri

Hi @matejik
It seems like there's a compatibility issue between the versions of slim/twig-view and the latest psr/http-message package.
The slim/twig-view declares v1.1 as dependency, which should be changed to ^1.1 || ^2.0 in this package, exactly here:
https://github.com/slimphp/Twig-View/blob/3.x/composer.json#L22
I will try to create a PR and hope that it's getting merged.

It should work now.


Update Clickhouse to <IP_ADDRESS>-stable

What's this PR about
I've updated ClickHouse to <IP_ADDRESS>-stable version due to an attempt to fix multiple issues and apply enhancements related to slow consuming data from Kafka brokers. I am still looking for an answer to the question, why it does not work. However, it seems there is no connection between changes in ClickHouse source code and particular issues with Kafka.
So, I ask you to build and publish an updated version of a stable version of ClickHouse.
Known build problems and traps
ClickHouse since 21.x requires modern set of C++ compilers to build itself (devtoolset-10). Unfortunately, there are no available packages devtoolset-* in Base or SCL repositories for unknown matters, so maintainers are supposed to use devtoolset-10 from Oracle Linux.
TODO's:

[x] Run perfecto check on your spec file
[ ] Write bibop tests
[x] Enable "Allow edits from maintainers" for this PR
[x] Update the messages below

Did you try to build the package with this spec?: Yes
Is this ready for review?: Yes

Looks good, merged. Thanks!


Error responses from API Builder are always stringified

I'm trying to send back detailed error responses as JSON from an API Builder method but it won't return JSON representation of my result. Here's a sample API project that demonstrates the problem:
"use strict";

var ApiBuilder = require("claudia-api-builder");
var AWS = require("aws-sdk");

var api = new ApiBuilder();
module.exports = api;

api.post("/dummy", function (request) {
  if (request.body.foo === "bar") {
    return {status: "OK"};
  } else {
    throw {error: "Invalid request"};
  }
});

If you then call that API like this:
POST /latest/dummy
Request Headers & Body
Accept: */*
Accept-Encoding: gzip, deflate
Content-Type: application/json
Accept-Language: en-us

{
  "foo": "baz"
}

You get the following response:
Response Headers
HTTP/1.1 500 Internal Server Error

Connection: keep-alive
Content-Type: application/json
X-Cache: Error from cloudfront
x-amzn-RequestId: 04957e7b-28d5-11e6-b1c5-991fd1d7258a
Via: 1.1 dc7c4fb5024ff022cad1642ec506a6e8.cloudfront.net (CloudFront)
Date: Thu, 02 Jun 2016 15:16:45 GMT
Access-Control-Allow-Headers: Content-Type,X-Amz-Date,Authorization,X-Api-Key
Content-Length: 34
X-Amz-Cf-Id: 1Y4Tb4lS7W6zDBoJkqOetlnPkKByi-R5WXeHC8fwxkbZKWGtTIGqXw==
Access-Control-Allow-Origin: *

Response Body Display Options
{
    "errorMessage": "[object Object]"
}

I would expect to see my error there instead of the "errorMessage": "[object Object]". I've tried explicitly setting the {error: {contentType: "application/json"}} when I define the method (although I think that should be the default), but I get the same result.
Do I need to build a specific error object or is this a problem in Claudia? I couldn't find anything in the docs or example projects that demonstrated returning a complete error object.

I just double-checked this (https://github.com/claudiajs/claudia-api-builder/blob/master/src/api-builder.js#L107) and this is a Lambda issue, not in Claudia. Whatever you throw as the error, the API Builder just passes on to Lambda. I think Lambda just expects a string or a JS exception object, you might try throwing an Error instead of a complex object.

Thanks for the quick response. Looking at the lambda docs, it appears that the only way to respond with complex body is to use a success response with a custom status code (e.g. 500). I'll see if I can figure out how to do that with api.ApiResponse. Thanks!

Never mind that attempt. This thread indicates it's probably not possible.

Lambda is very limited in error responses, it's best if you can pass a string there, so run JSON.Stringify on the object before sending it back


Debian repository problem?

I just added the Debian repository.
Not sure though, what does that message means (from "apt update"):
N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'http://www.mindforger.com/debian stretch InRelease' doesn't support architecture 'i386'

It seems to you use 32-bit Debian distribution, while I build only 64-bit packages. Perhaps you could try to build HSTR from source https://github.com/dvorka/hstr/blob/master/INSTALLATION.md#build-on-debian

I'm using an x64 distribution, Debian oldstable based (for the time being), thus the post.
Indeed building it locally is a better approach. :-)
I did it already.


feat: ASR and TTS integration

Please, consider  #1174 PR

The rest of PR content is correct as I can see.


Update placebo and apotheosis cause multiplayer nullpoint exception on my friend entering the world.

MCversion: 1.19.2
Apotheosis: 6.1.3
placebo: 7.1.6
Test with lanserverproperties 1.9.1, Apotheosis, placebo .
Single player OK, but my friends can't enter our save  on multiplayer after update the apotheosis, so I made another test with only these mod. And previous version of these two mods also no problem.
ps. lanserverproperties is a mod to chose the net port that my friend can access.
here the debug file.

waite a minute, I upload a wrong file.

debug.log


chore(main): release 0.41.0

:robot: I have created a release beep boop
0.41.0 (2024-06-21)
Features

Add a preview Storage Client (#354) (8aa9b7c)

Miscellaneous

remove legacy jwt token support (#366) (ba90ff0)
remove unused read concern mod (#363) (86f876b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/momentohq/client-sdk-rust/releases/tag/v0.41.0 :sunflower:


add doi support for validate command

todos:

[ ] add test

current problem: I don't have a working regex (in python)
Great, I found this doi regex: ^10.\d{4,9}\/[-._;()\/:A-Z0-9]+$ here (the first one for the "modern" dois)
Great it works with this example doi: 10.5072/zenodo.886788
This online regex tool tells me it matches:

BUT:
>>> import re
>>> print(re.fullmatch("^10.\d{4,9}\/[-._;()\/:A-Z0-9]+$", "10.5072/zenodo.886788"))
>>> None
>>> print(re.match("^10.\d{4,9}\/[-._;()\/:A-Z0-9]+$", "10.5072/zenodo.886788"))
>>> None

HELP!


The library does not support RTL!!!!

I tried to use all the props to swap the position of the icon with the text, and i can't.

duplicate of https://github.com/n4kz/react-native-material-dropdown/issues/124


Error in electron-vite: Unable to load preload script because of "missing file" in chunks folder.

Describe the bug
http://prntscr.com/WvyfJ-x97k4S
Any idea why this could be happening? The chunks folder is there and it contains the module but it says it's missing for some reason.
Electron-Vite Version
1.0.25
Electron Version
24.6.2
Vite Version
4.4.2
Validations

[X] Follow the Code of Conduct.
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

https://electron-vite.org/guide/dev.html#limitations-of-sandboxing for more details.
Because the require function is a polyfill with limited functionality, you will not be able to use CommonJS modules to separate your preload script into multiple files, unless sandbox: false is specified.

Is there a way I could fix this without disabling sandbox? Would it work if they were ES modules instead?

I am trying to build a project created accordingly with what is described in the docs but I am getting a white screen and these logs about some index.css and index.js files not found.
Do you have a solution to this ? I started getting these problems when using node 18.

Whether a router is used?  Maybe this problem: https://electron-vite.org/guide/troubleshooting.html#vue-router-or-react-router-dom-works-in-development-but-not-production

I'm actually having the same issue when using multiple windows with independent preload scripts that both depend on shared dependencies. In that case there's no way to configure electron.vite.config.ts in a way to not generate chunks (see the corresponding issue in rollup). I think it's worth re-opening this issue as I think electron-vite should make sure preload scripts get bundled as independent single files.


libc: add support for custom streams with fopencookie()

Summary
This commit adds support for custom stream via fopencookie function. The function allows the programmer the create his own custom stream for IO operations and hook his custom functions to it.
This is a non POSIX interface defined in Standard C library and implemented according to it. The only difference is in usage of off_t instead of off64_t. Programmer can use 64 bits offset if CONFIG_FS_LARGEFILE is enabled. In that case off_t is defined as int64_t (int32_t otherwise).
The interface will be useful for future fmemopen implementation.
Impact
New interface.
Testing
Tested with example application on man page on SAMv7 MCU.

I personally think you are going down the wrong path with this ad hoc logic.  This is very high risk because I don't think either of you are considering all of the issues and complexities.  You apparently seem focused on avoiding a clean context switch (which I believe is the correct, clean, flexible solution).
I believe we need to at least insist on a good test for this code to give people like me confidence.  A good test would include:

All build modes:  FLAT, PROTECTED, and KERNEL (we would need some testing help).
Assure that user code never executes in kernel mode in the PROTECTED build
Test with client and server in same task/process; Client and server in different tasks/processes and different address spaces (in KERNEL mde).

If it could pass a pretty rigorous test then I would become a believer.  That, I think is a requirement for merging.  I am not a believer now.

I once look at that to handle a fomempen and alike properly, it would require that struct FILE not to be a direct alias to internal FS struct, as indeed you need to have reference to callbacks and flags, so it would require an indirection where struct FILE holds a private pointer to internal.

You apparently seem focused on avoiding a clean context switch (which I believe is the correct, clean, flexible solution).

@patacongo  My main argument againts hooks you described above (various notifications, events, signal handlers etc.) is that it would lead to additional requirements for user application (different from how fopencookie is used in GNU/Linux). I havent had time to go through all code you suggested (graphics etc) so maybe I am missing something. But I think we should keep it in simple fseak, fputs etc operations.
@mu578 I like the structure you proposed, that would solve a lot of issues with current file_struct and as @xiaoxiang781216 mentioned it should not be that difficult (mostly renaming etc.). We could still keep pointers to read/write/seek at file in fs/vfs as it is now for drivers and just add the possibility for custom streams if required.
I would do this primarily for fopencookie and than build fmemopen and open_memstream on that if the community would agree as I think it is still beneficial to have fopencookie implemented (and its presence in Linux should justify that in my opinion).
I also think we should probably move this discussion to mailing list now.

I once had a look at that to handle a fomempen and alike properly, it would require that LIBC struct FILE not to be a direct alias to internal FS struct, as indeed you need to keep a reference to fs operation callbacks and permission flags, so it would require an indirection where struct FILE holds a private pointer to internal. Meanwhile, I think LIBC stdio would benefit at term that indirection to be made.
struct libc_stdio_file
{
  // ... stdio specifics;
  libc_stdio_fread_t  read;
  libc_stdio_fwrite_t write;
  libc_stdio_fseek_t  seek;
  libc_stdio_fclose_t close;
  libc_stdio_cookie_t cookie;

  file_struct *       internal;
}

typedef libc_stdio_file FILE;

we don't need add a new struct libc_stdio_file. Here is the current definition:
struct file_struct
{
  FAR struct file_struct *fs_next;      /* Pointer to next file stream */
  rmutex_t                fs_lock;      /* Recursive lock */
  int                     fs_fd;        /* File descriptor associated with stream */
#ifndef CONFIG_STDIO_DISABLE_BUFFERING
  FAR unsigned char      *fs_bufstart;  /* Pointer to start of buffer */
  FAR unsigned char      *fs_bufend;    /* Pointer to 1 past end of buffer */
  FAR unsigned char      *fs_bufpos;    /* Current position in buffer */
  FAR unsigned char      *fs_bufread;   /* Pointer to 1 past last buffered read char. */
#  if CONFIG_STDIO_BUFFER_SIZE > 0
  unsigned char           fs_buffer[CONFIG_STDIO_BUFFER_SIZE];
#  endif
#endif
  uint16_t                fs_oflags;    /* Open mode flags */
  uint8_t                 fs_flags;     /* Stream flags */
#if CONFIG_NUNGET_CHARS > 0
  uint8_t                 fs_nungotten; /* The number of characters buffered for ungetc */
  unsigned char           fs_ungotten[CONFIG_NUNGET_CHARS];
#endif
};

typedef struct file_struct FILE;

Here is the simple change to the struct:
struct file_struct
{
  ...
-  int                     fs_fd;        /* File descriptor associated with stream */
+  cookie_io_functions_t fs_iofunc;
+  FAR void *            fs_cookie;

};
and replace all read/write/seek/close with stream->iofunc.read/write/seek/close.
The remaining work is adding the simple wrapper for fopen:

static ssize_t read_fd(void *cookie, char *buf, size_t size)
{
int fd = (int)(intptr_t)cookie;
return read(fd, buf, size);
}
static ssize_t write(void *cookie, const char *buf, size_t size)
{
int fd = (int)(intptr_t)cookie;
return write(fd, buf, size);
}
static int seek(void *cookie, off_t *offset, int whence)
{
int fd = (int)(intptr_t)cookie;
off_t ret = seek(fd, *offset, whence);
if (ret >= 0)
{
*offset = ret;
ret = 0;
}
return ret;
}

You apparently seem focused on avoiding a clean context switch (which I believe is the correct, clean, flexible solution).

@patacongo My main argument againts hooks you described above (various notifications, events, signal handlers etc.) is that it would lead to additional requirements for user application (different from how fopencookie is used in GNU/Linux). I havent had time to go through all code you suggested (graphics etc) so maybe I am missing something. But I think we should keep it in simple fseak, fputs etc operations.

The marshaled data should be indisguishable from a direct function (provided an intermediate marshaling/de-marshaling,.
My main argument against this approach is that I have not heard any solution that will actually work in all conditions and build modes.

You apparently seem focused on avoiding a clean context switch (which I believe is the correct, clean, flexible solution).

@patacongo My main argument againts hooks you described above (various notifications, events, signal handlers etc.) is that it would lead to additional requirements for user application (different from how fopencookie is used in GNU/Linux). I havent had time to go through all code you suggested (graphics etc) so maybe I am missing something. But I think we should keep it in simple fseak, fputs etc operations.

The marshaled data should be indisguishable from a direct function (provided an intermediate marshaling/de-marshaling,.
My main argument against this approach is that I have not heard any solution that will actually work in all conditions and build modes.

@patacongo I think @michallenc initial design may confuse you. stdio is a pure userspace library, the implementation of fopencookie or fmemopen doesn't need involve any kernel stuff: it's enough to add the callback(read/write/seek/close) to struct file_struct(FILE).
So, I would suggest you read the manual from:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html
https://man7.org/linux/man-pages/man3/fopencookie.3.html

I once had a look at that to handle a fomempen and alike properly, it would require that LIBC struct FILE not to be a direct alias to internal FS struct, as indeed you need to keep a reference to fs operation callbacks and permission flags, so it would require an indirection where struct FILE holds a private pointer to internal. Meanwhile, I think LIBC stdio would benefit at term that indirection to be made.
struct libc_stdio_file
{
  // ... stdio specifics;
  libc_stdio_fread_t  read;
  libc_stdio_fwrite_t write;
  libc_stdio_fseek_t  seek;
  libc_stdio_fclose_t close;
  libc_stdio_cookie_t cookie;

  file_struct *       internal;
}

typedef libc_stdio_file FILE;

we don't need add a new struct libc_stdio_file. Here is the current definition:
struct file_struct
{
  FAR struct file_struct *fs_next;      /* Pointer to next file stream */
  rmutex_t                fs_lock;      /* Recursive lock */
  int                     fs_fd;        /* File descriptor associated with stream */
#ifndef CONFIG_STDIO_DISABLE_BUFFERING
  FAR unsigned char      *fs_bufstart;  /* Pointer to start of buffer */
  FAR unsigned char      *fs_bufend;    /* Pointer to 1 past end of buffer */
  FAR unsigned char      *fs_bufpos;    /* Current position in buffer */
  FAR unsigned char      *fs_bufread;   /* Pointer to 1 past last buffered read char. */
#  if CONFIG_STDIO_BUFFER_SIZE > 0
  unsigned char           fs_buffer[CONFIG_STDIO_BUFFER_SIZE];
#  endif
#endif
  uint16_t                fs_oflags;    /* Open mode flags */
  uint8_t                 fs_flags;     /* Stream flags */
#if CONFIG_NUNGET_CHARS > 0
  uint8_t                 fs_nungotten; /* The number of characters buffered for ungetc */
  unsigned char           fs_ungotten[CONFIG_NUNGET_CHARS];
#endif
};

typedef struct file_struct FILE;

Here is the simple change to the struct:
struct file_struct
{
  ...
-  int                     fs_fd;        /* File descriptor associated with stream */
+  cookie_io_functions_t fs_iofunc;
+  FAR void *            fs_cookie;
  ...
};

and replace all read/write/seek/close with stream->iofunc.read/write/seek/close. The remaining work is adding the simple wrapper for fopen:
static ssize_t read_fd(void *cookie, char *buf, size_t size)
{
  int fd = (int)(intptr_t)cookie;
  return read(fd, buf, size);
}

static ssize_t write_fd(void *cookie, const char *buf, size_t size)
{
  int fd = (int)(intptr_t)cookie;
  return write(fd, buf, size);
}

static int seek_fd(void *cookie, off_t *offset, int whence)
{
  int fd = (int)(intptr_t)cookie;
  off_t ret = seek(fd, *offset, whence);
  if (ret >= 0)
    {
      *offset = ret;
      ret = 0;
    }

  return ret;
}

you would if want to keep separated internal implementation to actual in-memory Os layout and a libc stdio frontend. Indeed nutxx/fs.h is one possible core-stream handling implementation, you don't want to mixup ; theoretically you could swap to any OS vfs implementation without changing any of your LIBC frontend.
fopencookie is a solution/vilain patch which only regards end-user and a LIBC frontend to address the implementation of open_memstream and fmemopen, nuttx_file_struct should remain agnostic to such concerns, now I don't say it could be smarter and hold default callback pointers, the problem: the ones defined by fopencookie do not match exactly.
But again do not hot patch such.

you would if you want to keep separated internal implementation to actual in-memory Os layout and a libc stdio frontend concern.
Indeed nutxx/fs.h is one possible core-stream handling implementation, you don't want to mixup ;

If you don't like file_struct is contained in nuttx/fs.h, the right fix is moving it to stdio.h, but don't create a new libc_stdio_file since libc_stdio_file lack many fields which is required to implement buffer I/O and fungetc etc.

theoretically, you could swap to any OS vfs implementation without changing any of your LIBC frontend.

struct file_struct is designed to work with stdio, struct file is designed to work with vfs. Please don't confuse them.

@patacongo I think @michallenc initial design may confuse you. stdio is a pure userspace library, the implementation of fopencookie or fmemopen doesn't need involve any kernel stuff: it's enough to add the callback(read/write/seek/close) to struct file_struct(FILE).
So, I would suggest you read the manual from:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html
https://man7.org/linux/man-pages/man3/fopencookie.3.html

AFAIK that is not true.  The user/supervisor mode is only one of several issues.  I have enumerated many others below that this design pure user-space design will not handle.  The bottom line:  You cannot call from one task/process address space into another.  In the FLAT build, that might work in some very, very simple cases.  But it will not work in general.  It will never work at all in the KERNEL build if the client and server lie in different process address spaces.  The virtual user address spaces overlap and it you try calling into it you will certainly crash.
In order to that successfully and reliably, a context switch is required.
I don't see any reason for me to participate in this any further.  I've tried to explain all of this as carefully as I can but I still see you guys marching ahead to fall off the cliff.

@patacongo I think @michallenc initial design may confuse you. stdio is a pure userspace library, the implementation of fopencookie or fmemopen doesn't need involve any kernel stuff: it's enough to add the callback(read/write/seek/close) to struct file_struct(FILE).
So, I would suggest you read the manual from:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html
https://man7.org/linux/man-pages/man3/fopencookie.3.html

AFAIK that is not true. The user/supervisor mode is only one of several issues. I have enumerated many others below that this design pure user-space design will not handle. The bottom line: You cannot call from one task/process address space into another.

This case isn't suitable for stdio functions. How can you pass FILE * from one task/process to other task/process in kernel mode? It's impossible to happen in the first place.

This case isn't suitable for stdio functions. How can you pass FILE * from one task/process to other task/process in kernel mode? So it's impossible to call the callback function cross the address space boundary since FILE* return from fopencookie can only be used by the caller's task/process and is always invalid and impossible to pass FILE* to another task/process at the first place.

I don't see the relevance of the FILE*.  I was more concerned at the io_funcs and cookie.  But looking at the prototype, it seems impossible that the io_funcs could like in a different address space. from the caller of fopencookie().

This case isn't suitable for stdio functions. How can you pass FILE * from one task/process to other task/process in kernel mode? So it's impossible to call the callback function cross the address space boundary since FILE* return from fopencookie can only be used by the caller's task/process and is always invalid and impossible to pass FILE* to another task/process at the first place.

I don't see the relevance of the FILE*. I was more concerned at the io_funcs and cookie. But looking at the prototype, it seems impossible that the io_funcs could like in a different address space. from the caller of fopencookie().

Aggreed, it would require to pound defined and only allowing such APIs in usermode. However, it could be doable by making a new vfs interface handling such but it would require a whole revamp and further thoughts to make it possible, as is : it is not hot patchable -> so my proposal to support indirection for user-mode build only, at least it can be undone and evolve without breaking.
That is impossible to callback from two distinct regions ; it would require some kind of trampoline jump with copies back and forth.

This case isn't suitable for stdio functions. How can you pass FILE * from one task/process to other task/process in kernel mode? So it's impossible to call the callback function cross the address space boundary since FILE* return from fopencookie can only be used by the caller's task/process and is always invalid and impossible to pass FILE* to another task/process at the first place.

I don't see the relevance of the FILE*. I was more concerned at the io_funcs and cookie. But looking at the prototype, it seems impossible that the io_funcs could like in a different address space. from the caller of fopencookie().

Yes, this is the key point: both io_funcs and cookie can only be used in the same proccess(address space), which simplify the thing a lot if the implementation can avoid the involve any kernel space stuff.

This case isn't suitable for stdio functions. How can you pass FILE * from one task/process to other task/process in kernel mode? So it's impossible to call the callback function cross the address space boundary since FILE* return from fopencookie can only be used by the caller's task/process and is always invalid and impossible to pass FILE* to another task/process at the first place.

I don't see the relevance of the FILE*. I was more concerned at the io_funcs and cookie. But looking at the prototype, it seems impossible that the io_funcs could like in a different address space. from the caller of fopencookie().

Aggreed, it would require to pound defined and only allowing such APIs in usermode.

Of course, all FILE functions can only be called inside the usermode, NuttX kernel forbid kernel code to use any FILE functions.

However, it could be doable by making a new vfs interface handling such but it would require a whole revamp and further thoughts to make it possible, as is : it is not hot patchable -> so my proposal to support indirection for user-mode build only, at least it can be undone and evolve without breaking.

@mu578 you may misunderstand NuttX file system:

nuttx/fs/vfs is the kernel VFS infrastructure, which is part of kernel, it's hard and bad to call the callback provided by userspace
nuttx/libc/stdio is userspace library, which is very simple and common to call the callback provided by userspace

That is impossible to callback from two distinct regions ; it would require some kind of trampoline jump with copies back and forth. E.g if function pointers were actually just address pointers pointing to an actual somewhere we would not have this conversation, but the reality is different.

Do you want to implement the userspace file system? NuttX already support it by message queue:
https://github.com/apache/nuttx/blob/master/include/nuttx/fs/userfs.h

Myself, I would go to support standard only: open_memstream and fmemopen ; there is no reason to expose a non standard fopencookie call ; the two requires some memory mapping that's it, no callback exposure. It is all about to be able to use FILE api on a user in-memory buffer instead of on a file descriptor/ino ; which in case of nuttx is kif-kif bourricot a mere detail.

If we want to support all open_memstream/open_wmemstream/fmemopen, it's important to setup a callback infrastructure otherwise fread/fwrite need add many:
if (file handle)
  {
    ...
  }
else if (mem handle)
  {
    ...
  }
else if (xxx handle)
  {
    ...
  }

To summarize the so far discussion a bit:
The problem discussed here is a that this implementation reuses file_operation_s infrastructure which is a part of a file system (thus kernel address space) which is my fault as I haven´t realize during the implementation that the reuse of current infrastructure would lead to this.
I quite like the proposition of reworked/new file system @mu578 suggested but as he mentioned, it is not a stuff for one patch and probably should be discussed on a mailing list first. I also do not agree with the statement

Myself, I would go to support standard only: open_memstream and fmemopen ; there is no reason to expose a non standard fopencookie call ; the two requires some memory mapping that's it, no callback exposure.

as fopencookie can be beneficial for programmers (maybe even more than fmemopen). And while not being POSIX, we should keep in mind the NuttX compatibility with Linux imho. Also if done correctly, fopencookie can be used both as libc call available for programmers and internal hook for fopencookie and open_memstream.
Regarding kernel protected builds, address space (and also priorities to keep strict scheduling), I think it should be sufficient to ensure user calls read/write/seek/close do not enter kernel space i.e. fs/vfs when used with fopencookie. In that case all code would remain in stdio libc library and would be purely user space therefore none of the mentioned issues should occur. I would go with @xiaoxiang781216 suggested implementation for that and we will see where it leads.

This case isn't suitable for stdio functions. How can you pass FILE * from one task/process to other task/process in kernel mode? So it's impossible to call the callback function cross the address space boundary since FILE* return from fopencookie can only be used by the caller's task/process and is always invalid and impossible to pass FILE* to another task/process at the first place.

I don't see the relevance of the FILE*. I was more concerned at the io_funcs and cookie. But looking at the prototype, it seems impossible that the io_funcs could like in a different address space. from the caller of fopencookie().

Aggreed, it would require to pound defined and only allowing such APIs in usermode.

Of course, all FILE functions can only be called inside the usermode, NuttX kernel forbid kernel code to use any FILE functions.

However, it could be doable by making a new vfs interface handling such but it would require a whole revamp and further thoughts to make it possible, as is : it is not hot patchable -> so my proposal to support indirection for user-mode build only, at least it can be undone and evolve without breaking.

@mu578 you may misunderstand NuttX file system:

nuttx/fs/vfs is the kernel VFS infrastructure, which is part of kernel, it's hard and bad to call the callback provided by userspace
nuttx/libc/stdio is userspace library, which is very simple and common to call the callback provided by userspace

That is impossible to callback from two distinct regions ; it would require some kind of trampoline jump with copies back and forth. E.g if function pointers were actually just address pointers pointing to an actual somewhere we would not have this conversation, but the reality is different.

Do you want to implement the userspace file system? NuttX already support it by socket: https://github.com/apache/nuttx/blob/master/include/nuttx/fs/userfs.h

Myself, I would go to support standard only: open_memstream and fmemopen ; there is no reason to expose a non standard fopencookie call ; the two requires some memory mapping that's it, no callback exposure. It is all about to be able to use FILE api on a user in-memory buffer instead of on a file descriptor/ino ; which in case of nuttx is kif-kif bourricot a mere detail.

If we want to support all open_memstream/open_wmemstream/fmemopen, it's important to setup a callback infrastructure otherwise fread/fwrite need to add many if/else:
if (file handle)
  {
    ...
  }
else if (mem handle)
  {
    ...
  }
else if (xxx handle)
  {
    ...
  }

If we need to add the callback to FILE, why not follow fopencookie which exist in most libc implementation(glibc, newlib, *BSD), but add a NuttX specific function instead? I don't see any benefit.

I fully understand vfs.

I fully understand vfs, no callback infrastructure is needed,

that's a glibc patch, who cares?

But I care where the implementation is elegance and extendable.  The code like spaghetti should avoid as mention in:
https://github.com/apache/nuttx/blob/master/INVIOLABLES.md?plain=1#L36-L41
https://github.com/apache/nuttx/blob/master/INVIOLABLES.md?plain=1#L90-L94

just deal with a flag about memory provider that's it.

even for memory stream, there are at least two cases:

fmemopen work on a fix size array(provided by caller, or allocated by self)
open_memstream work on an allocate/reallocate extendable memory

The detail is evil, you have to add more flags/fields and many if/else in many common places to handle the different behavior required by spec. The callback is better design here to encapsulate the difference behind the differerent callback(fd vs. mem, fixed vs. dynamically).

provided by caller, or allocated by self)
open_memstream work on an allocate/reallocate extendable memor

yes make a context buffer |internal|user_malloc|user_dont_touch|

_io_buffer_grow_if_needed(stream_flag, ** buffer)
{
  if this type -> do that or not do
}

_io_buffer_free_if_needed(stream_flag, ** buffer)
{
  if this type -> do that or not do
}

I have updated the implementation with internal callbacks so now the code should entirely avoid kernel address space. How are we going to design some tests that would ensure the correctness?

Some initial tests can be found here: https://github.com/michallenc/incubator-nuttx-apps/commit/1cd88d54c7119fad000866a3a62f8c5afad2ebc8 I have only tested it in FLAT mode so far as I have not been able to compile NuttX in protected mode (regardless of fopencookie, I tried upstream NuttX without changes as well) on both samv7 and imxrt MCUs. SAMv7 fails on NVIC_CFAULTS_MUNSTKERR (MemManage fault on unstacking) and I could not get any output from imxrt. I used @acassis video on https://www.youtube.com/watch?v=p2aXmPNUnCg for configuration, so that stepts should be alright. There might be something wrong with MPU for ARMv7-M...

@xiaoxiang781216 I have updated the implementation and implemented most of your suggestions (see separate comments). There is a new PR in nuttx-apps add fopecookie test and use fileno interface instead of accessing FILE that adds test application and also fix some FILE usage in system (this is should be merged before NuttX patch because of CI).

@xiaoxiang781216 I have updated the implementation and implemented most of your suggestions (see separate comments). There is a new PR in nuttx-apps add fopecookie test and use fileno interface instead of accessing FILE that adds test application and also fix some FILE usage in system (this is should be merged before NuttX patch because of CI).

@michallenc but, the ci still fail, could you take a look?

@michallenc but, the ci still fail, could you take a look?

Yes, I fixed some on Saturday but I suppose the rest is somehow related to change to fs_fdopen which should be (at least partially) fixed by the update from your patch a remove of fs_fdopen.

@michallenc but, the ci still fail, could you take a look?

Yes, I fixed some on Saturday but I suppose the rest is somehow related to change to fs_fdopen which should be (at least partially) fixed by the update from your patch a remove of fs_fdopen. I will update the patch once yours is merged.

@michallenc https://github.com/apache/nuttx/pull/10913 was merged, you can rebase your patch on top of it now.

@michallenc #10913 was merged, you can rebase your patch on top of it now.

@xiaoxiang781216 Updated. Local CI runs were successful, lets see what GitHub CI does.

Hmm, sim-01 fails without actually logging any error.

please fix:
81a82
> CONFIG_TESTING_FOPENCOOKIE_TEST=y
87d87
< CONFIG_TESTING_FOPENCOOKIE_TEST=y
Saving the new configuration file
HEAD detached at pull/10602/merge
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   boards/sim/sim/sim/configs/citest/defconfig


WFLY-4450 Added test coverage for datasource credentials in a security domain

Simple test that DataSource is able to use credentials coming from a security domain.

Linux with security manager Build 1069 is now running using a merge of 69a48a9c9fc3d024844d8813fc49968a2516ae6b

Linux Build 6092 is now running using a merge of 69a48a9c9fc3d024844d8813fc49968a2516ae6b

Windows Build 1205 is now running using a merge of 69a48a9c9fc3d024844d8813fc49968a2516ae6b

Linux with security manager Build 1069 outcome was SUCCESS using a merge of 69a48a9c9fc3d024844d8813fc49968a2516ae6b
Summary: Tests passed: 846, ignored: 319 Build time: 0:05:09

Linux Build 6092 outcome was SUCCESS using a merge of 69a48a9c9fc3d024844d8813fc49968a2516ae6b
Summary: Tests passed: 2931, ignored: 311 Build time: 0:49:07

Windows Build 1205 outcome was SUCCESS using a merge of 69a48a9c9fc3d024844d8813fc49968a2516ae6b
Summary: Tests passed: 2929, ignored: 311, muted: 2 Build time: 0:53:06


[Gally]: master <- dev

Automatically created by Git-Ally

:tada: This PR is included in version 2.7.16 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Use ontology term for gene symbol search

A few times in the Schemas, a gene is mentioned, and it is implied the HGNC name is used, however it is not explicitly stated. I, and I think others, are not especially confident in using HGNC names as the defacto standard. One immediate problem is that you now cannot query HGNC for genes on grch37, and only grch38 genes are returned. (I mean, a gene that is valid in 37 will redirect to a gene in 38, which is not in 37. Obviously a problem for those not using 38).
In the Matchmaker Exchange group, I have just brought this to our attention, and we've had some discussions on this. HGNC genes are updated with the "whenever" release cycle methodology. Ensembl has a regular 2-3 monthly release. There are problems with both data sources, but we're already in a non ideal situation. (It's difficult to get gene names for grch37 only genes from HGNC, as far as I am able to tell) _I elaborate on this more in the following issue in the MME repo:_
**_https://github.com/MatchmakerExchange/mme-apis/issues/113**_
There was a previous parrallel discussion regarding how to represent phenotypes. The main problem raised with HPO is the lack of stable releases. We couldn't agree on this being a problem or not, but personally I feel that expecting everyone to update reference data on a nightly cycle is unreasonable. /sidebar
I struggle to believe this is a problem that someone else hasn't thought about and at least attempted to solve. I'd like thoughts and comments on this, even if suggestions are not 100% solid, to generate discussion.
A polite reminder to please try to stay on topic with your replies, and not diverge from the issue at hand.

The genesymbol search in sequence annotations currently accepts a string. This should be upgraded to an ontology term so that a constrained vocabulary can be used.


Bug/jenkins 38023 expandable path

Description

See JENKINS-38023.
Since we need to use this treatment in Dashboard and Personalization and it's a simple component visual-only component I felt the JDL was the right place for it.

Submitter checklist

[x] Link to JIRA ticket in description, if appropriate.
[x] Change is code complete and matches issue description
[x] Appropriate unit or acceptance tests or explanation to why this change has no tests

Reviewer checklist

[ ] Run the changes and verified the change matches the issue description
[ ] Reviewed the code
[ ] Verified that the appropriate tests have been written or valid explanation given

@reviewbybees

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

 Could you try deleting shrinkwrap.json and building again? Builds on my Mac (El Capitan) so trying to pin down your issue.

@cliffmeyers right, yeah I must have upgraded to 6 at some point. I downgraded to node 5 and it is ok (node-sass is very brittle with node versions it seems, at least the postbuild stuff is).

functionality wise: :bee: from me

Builds and runs, stories work 🐝  all good


UploadHandler.php - fix processing of valid files with wrong extension

I noticed that of the 700+ correctly processed files, some were created but not properly resized.
The issue: people uploaded files with .PNG extension, but they're really JPG files, causing issues. The thumbnail version was created - but not resized.
This pull request offers a solution, although it may be worth considering passing $file to some functions instead of just the file name and the real image type?

Thanks for your contribution @jbostoen
The PHP upload handler already has a correct_image_extensions option (by default set to false):
https://github.com/blueimp/jQuery-File-Upload/blob/master/server/php/UploadHandler.php#L122
Is there anything that this option wouldn't already solve for your use case?

I noticed and tried it, but for some reason it didn't work out properly until I changed the few bits in the commit.

The fix_file_extension function is called when get_file_name is executed, which is done before any image processing:
https://github.com/blueimp/jQuery-File-Upload/blob/master/server/php/UploadHandler.php#L1123
Since the processing then uses the scaling function based on the new image name, fixing the image extension should also choose the correct scaling function.
I've also just tested this functionality again and could not reproduce any issues.
I'll close this pull request for now, feel free to reopen if you have a use case that the current functionality does not cover.


Error in running visualization validation

I've done the following steps:

Built the directory tree as you instructed
ran python torch2pytorch_data.py annd python torch2pytorch_pretrained_weight.py with their instructed parameters
But when i run 'python visual.py --flip --rotate 0.25 0.5 0.75 --img_glob "data/test/img/pano_aaccxxpwmsdgvj.png" --line_glob "data/test/line/pano_aaccxxpwmsdgvj.png" --output_dir assert/'
I get the following error

Traceback (most recent call last):
File ".../LayoutNet/visual.py", line 55, in
encoder.load_state_dict(torch.load('%s_encoder.pth' % args.path_prefix))
File ".../lib/python3.5/site-packages/torch/serialization.py", line 356, in load
f = open(f, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: 'ckpt/pre_encoder.pth'

Sorry for the late reply.
What is the arguments you given to the torch2pytorch_pretrained_weight.py?
The script should convert to pretrained model to the path you given to the --encoder...

I was able to solve this eventually.
The script says it is looking for 'ckpt/pre_encoder.pth' but I had 'ckpt/pre_full_encoder.pth' instead.
So I changed the prefix parameter and than it worked.
Due to the fact that following your instructions result in a 'pre_full_encoder.pth' file instead of a 'pre_encoder' file, I would suggest to edit your default behaviour of your code.
i.e edit the visual and visual_from_scratch files by changing the default value of the path-prefix parameter from 'ckpt/pre' to 'ckpt/pre_full


[BUG]: Attendee email and name are the same (both are email)

Not sure if this should be labelled a bug or a feature request. But in any case, the issue is that name and email are both the email of the attendee. This is a) redundant and b) a loss of information, since the actual name is not available. I'm trying to implement the workflow requested here (formatting the name as a link to the person folder), but without the name, it's not possible. Unless perhaps if you add the email as an alias to the note, but that's something you can only do after the note has been created, in this scenario.
So I'm wondering if this is intentional, which it seems to be based on this and this, and if so, why? Is it because the name of the attendee is simply not available? If so, bummer.

Hi @FeralFlora - I noticed the same and it may be worth adding a note or alternative handling to https://github.com/cloud-atlas-ai/obsidian-ics/blob/dad4fc23047faa095bf486ad13f2c7173188ac47/src/main.ts#L104-L120
I downloaded several ics files from different providers and CN (canonical name) is often the email address instead of the name. I don't know why this is the case. It is not always email, sometimes coming through as the attendee's name.
I'd rather not manipulate the data as it comes through, so could see adding another field or two with processed name & email if you think that is what most people expect.

For reference: https://www.kanzaki.com/docs/ical/attendee.html

For reference: https://www.kanzaki.com/docs/ical/attendee.html

Thanks for the link:

The property parameter CN is for the common or displayable name associated with the calendar address
Strange how your and my experience doesn't line up with this ☝

I'd rather not manipulate the data as it comes through, so could see adding another field or two with processed name & email if you think that is what most people expect.
I understand, that makes sense. If something like that is possible, it would be great, but what would you process, if CN is just the email?

I've shared my current attendee implementation here: https://github.com/cloud-atlas-ai/obsidian-ics/discussions/74#discussioncomment-8522435


Refactor runtime tutorials such that they start with non-MPI use cases and build up to full MPI use cases

estimate 1

Include non-MPI examples of how to leverage the runtime
Build up tutorial that leverages the report signals and trace signals
Shift the showcase agent from power balancer/governor to FrequencyMapAgent
Add placeholders for all other agents that don't have tutorials (will be addressed in a future task)

We have deleted the runtime tutorials and added documentation to the getting started guide


Segment split

Description:
We are adjusting the segment creation to accommodate local root spans.
If a span is a not a local root, then we keep existing behavior.
If it is a local root then:
If it is an Internal or Server span, then promote it to a segment.
Else we will split it into a segment and subsegment. The segment will represent the service operation and the subsegment will represent the dependency (service A calls service B).
Testing:
Unit Testing
Documentation:
None

"I am not sure this worked for me - I was getting the Service node named after the original SpanName when I was experimenting with this."
This works in the unit tests. segment_test.go line 1138.

Codecov Report

Merging #106 (1a7afd3) into main (7db0833) will decrease coverage by 0.04%.
Report is 33 commits behind head on main.
The diff coverage is 79.62%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##             main     #106      +/-   ##
==========================================
- Coverage   82.69%   82.65%   -0.04%
==========================================
  Files        1700     1708       +8
  Lines      158778   160183    +1405
==========================================
+ Hits       131304   132402    +1098
- Misses      23840    24084     +244
- Partials     3634     3697      +63

Files
Coverage Δ

exporter/awsxrayexporter/awsxray.go
84.88% <100.00%> (+0.54%)
:arrow_up:

...ter/awsxrayexporter/internal/translator/segment.go
90.34% <78.98%> (-5.44%)
:arrow_down:

... and 48 files with indirect coverage changes


feature/initial-dataset

Resolves #1
Resolves #2
I tried it with AwardFindR but the parameters are very limiting. But from looking at the AwardFindR source code and the NSF API docs it was easy enough to make it work in Python with custom parameters.
I added both the R and Python scripts to get the datasets so you can compare.
The filtered "software-like" / regex-matching dataset is filtered-nsf-awards.csv / filtered-nsf-awards.parquet.
There were 22 awards that met all of our parameters between 2019 and today.

I can remove the data files from git if you don't want them in the repo but they are so small it shouldn't matter.


Swift's memory bindings

So, I’ve been reading up on Swift’s memory model and the use of assumingMemoryBound(to:)and withMemoryRebound(to:capacity:). The current withUnsafePyramidOfDoom(_:) methods perform type punning using assumingMemoryBound(to:). As I understand it, this is safe when ANKFullWidth is unsigned, because it is a heterogeneous UInt collection falling under the category of related types. By contrast, from the view point of my limited understanding, it is unsafe when ANKFullWidth is signed, because it contains an Int - meaning that not every element is bound to UInt.
I believe the correct way, regardless, is to use withMemoryRebound(to:capacity:). Supposedly, this is one of those methods that should not affect run-time performance, but in reality it does. I can without problem update the read-only portion, but not the read-write portion. Maybe it's a compiler issue, or perhaps I'm doing some invalidating thing that causes  additional copies. I don't know, but I'm looking into it.

Why strict aliasing gotta make cool stuff so difficult…

Strict aliasing is the most anti-fun optimization rule…

Hm. The performance issue appears to be related to the optimizer’s [un]willingness to constant fold the capacity argument.

Self.count is bad.
MemoryLayout<Self>.size / MemoryLayout<UInt>.size is bad.
Self.bitWidth / UInt.bitWidth is OK for some reason?


Can't Query ProductItem use ForceClient

I'm attempting to query ProductItem objects from Salesforce field service. User has appropriate permissions. I am able to query ProductItems using the SalesForce REST API and the SalesForce SOAP API directly using Postman. When using the ForceClient from a C# application however, I receive the following error:
Salesforce.Common.ForceException: sObject type 'ProductItem' is not supported.
Can your explain why this wouldn't be supported in this scenario?

I have discovered its because by default SalesForce API version 36.0 is being used.


Merge beta into alpha

Description
Merge beta into alpha
Breaking Changes
NA
JIRA Link
NA
Checklist

[x] Updated the Readme.md (if required) ?

@VictorVicente  To resolve this message:

This branch is out-of-date with the base branch Merge the latest changes from beta into this branch.

We need to make a new branch from beta I call it beta-into-alpha, then merge alpha into that, and then open the PR. This happens when both branches have changes in them.
Since beta is a release branch we can't just update it with latest alpha changes in place.

:tada: This PR is included in version 19.0.0-beta.6 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 19.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Qasm3 Exporter needs to export arrays of qubtis for concatenation in alias of OpenQASM3.

What is the expected enhancement?
Currently Qasm3 Exporter generates qubit[2] _q; let q = _q[0] || _q[1]; to generate an array of qubits in OpenQASM 3.
https://github.com/Qiskit/qiskit-terra/blob/main/test/python/circuit/test_circuit_qasm3.py#L34-L35
However, I think that the spec allows concatenating of only two arrays.
https://qiskit.github.io/openqasm/language/types.html#register-concatenation-and-slicing
In the above case, the type of  _q[0] and  _q[1] is qubit and not qubit[1].
One of quick fixes may be generating let q = _q[0:0] || _q[1:1]; instead of let q = _q[0] || _q[1];.

This isn't 100% decided one way or the other (see also Qiskit/openqasm#218) but right now I'm pretty sure that our internal compiler supports the form the exporter outputs.  I'm not sure if it actually supports concatenating arrays, but likely it does (@taalexander?).

The internal compiler does not like the current form of exporter arrays very much. Rather, we always use the transpiled circuit which is laid out onto physical qubits. At this point, the exporter contains no reference to qubit arrays.

I can make the exporter turn this circuit:
qubits = [Qubit() for _ in [None] * 10]
first_four = QuantumRegister(name="first_four", bits=qubits[:4])
last_five = QuantumRegister(name="last_five", bits=qubits[5:])
alternate = QuantumRegister(name="alternate", bits=qubits[::2])
sporadic = QuantumRegister(name="sporadic", bits=[qubits[4], qubits[2], qubits[9]])

QuantumCircuit(qubits, first_four, last_five, alternate, sporadic)

into this OpenQASM 3:
OPENQASM 3;
include "stdgates.inc";
qubit[10] _q;
let first_four = _q[0:3];
let last_five = _q[5:9];
let alternate = _q[0:0] || _q[2:2] || _q[4:4] || _q[6:6] || _q[8:8];
let sporadic = _q[4:4] || _q[2:2] || _q[9:9];

Is that appropriate for everyone?  I haven't bothered to try and make the exporter cleverer about inserting steps (alternate in this example could be more efficiently written as _q[0:2:8]), but it's easy if people want it.


vagrant: Bump 4.9 Vagrant box (Linux 4.9.326, to fix a kernel bug)

We have been hitting a kernel bug on 4.9 for the verifier tests. An underflow on the memlock rlimit counter, caused by the reallocation of BPF programs not updating the charged values, makes the counter go under zero and convert into a huge value, blocking all further loads of BPF objects.
This has been fixed in kernel 4.10, and was backported at last in 4.9.326. We generated a new Ubuntu image based on that, let's update.

k8s-1.16-kernel-4.9 passed successfully


feat: Project selection prompt

This PR adds project selection prompt when opening a workspace
Type of Change

[x] New feature (non-breaking change which adds functionality)

Checklist

[x] I have performed a self-review of my own code

Related Issue(s)
This PR addresses issue #111
Screenshots

Notes
Please add any relevant notes if necessary.
/claim #111

@Tpuljak
Pushed changes and here's contributor.md PR

@Tpuljak
Was going to add the changes and I'm not sure why my instance broke all of a sudden, I get this message when I try to select the workspace.
FATA[0000] failed to get workspace info: exec: Stdout already set
Attached log file

log.txt

@Tpuljak Was going to add the changes and I'm not sure why my instance broke all of a sudden, I get this message when I try to select the workspace.
FATA[0000] failed to get workspace info: exec: Stdout already set

Attached log file server-log.txt

@neo773 it seems something is wrong with your docker provider. Please stop the server, run rm -rf ~/.config/daytona/providers/ and start the server again. Let me know if this does not resolve the issue.

@Tpuljak
Didn't work I can't even delete the workspace it throws the same error.
Where does daytona stores the data?

@Tpuljak Didn't work I can't even delete the workspace it throws the same error. Where does daytona stores the data?

Depends on if you're using Mac or Linux.
On Linux: ~/.config/daytona/db
On Mac: ~/Library/Application\ Support/daytona/db.
Also, if you're using Mac, the command from the reply above should be rm -rf ~/Library/Application\ Support/daytona/providers. Apologies for that, I just assumed you're using Linux.

@Tpuljak
Yeah, I'm a Mac, rm -rfing those worked.
Pushed a new commit that fixes the style.

@Tpuljak Yeah, I'm on a Mac, rm -rfing those worked. Pushed a new commit that fixes the style.

@neo773 My bad on the assumption. PR approved, I requested a review from one of our other contributors as well. Thanks for your patience with the provider error.


What is the proper way to programatically change an input?

Hi all,
I have a button in my Pane that opens a dialog to choose a folder in my filesystem. I want the folder path to be stored in a text input, so that when the user presses save, this value is included in pane.exportPreset()
This is the way I managed to do it, by rummaging through the source code:
    ...
    const folder_location = pane.addInput(PARAMS, 'folder_location');

    const btn = pane.addButton({
        title: 'Select Folder',
    });

    btn.on('click', () => {
        (<this handles the dialog>).then(result => {
            folder_location.controller_.binding.value.rawValue = result
        });
    });

It feels like there is probably a more direct way to change the input value than .controller_.binding... but I couldn't figure it out. the value setter didn't work for me (folder_location.value = ...)
Any thought would be greatly appreciated. Thank you

How about the code below:
btn.on('click', () => {
  (<this handles the dialog>).then(result => {
    PARAMS.folder_location = result;
    pane.refresh();
  });
});

Feel free to reopen the issue if you have any updates.


Add persistence to helm charts

Add persistence to VDC helm chart
(note - see https://github.com/odpi/egeria/issues/753#issuecomment-465102360 as a reminder on keeping the config file as well as the data store, to ensure metadatacollectionid is preserved and stable)

Transferring this, but will depend on where we see the vdc chart going
For base egeria work on persistance will start around the docker image and operator


Fixed freezing of thumb when touch ended outside of frame

If you move your finger outside of frame while touching, then thumb will freeze. I think expected behavior should be to select the nearest item.
Interaction now:

Interaction with changes from this pull request:

LGTM. Thanks for the PR.


PIN needed in HMAC?

okay, so 2 questions:

is it possible to drop PIN Requirement for HMAC or make it optional or whatever
could we add a way to insert the pin for the 2 hmac commands.

because for me they just die with "PIN required" which obviously sux.
as they obviously can be (and are) used for things where the response actually us used for something like crypto it might be an interesting Idea to use different secrets for acting with and without pin. that way if one wants pin it cannot just be skipped. and as these things may run local you might not want the response for something you want pin output without pin obviously, and no idea whether it could discern by credID whether PIN is wanted or not so a dual-secret approach may be fun

https://github.com/solokeys/solo-python/issues/20


Define evaluation history schemas

Fixes #3555
Implements the new datbase schema. Queries and logic to fill the tables will be implemented in the next PR.
Summary
Provide a brief overview of the changes and the issue being addressed.
Explain the rationale and any background necessary for understanding the changes.
List dependencies required by this change, if any.
Fixes #(related issue)
Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[x] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[x] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

Can you add some reasoning about the chosen schema to the PRs description? The design document is not something publicly accessible and transparency is key.

coverage: 53.147% (+0.01%) from 53.137%
when pulling df32c3ad2f60d210f4fb0c3ca910a881a73b75a9 on eval-history-schema
into f7fa49159a32418f05ce7a2cef23b6cf4075c5af on main.

coverage: 53.137%. remained the same
when pulling df32c3ad2f60d210f4fb0c3ca910a881a73b75a9 on eval-history-schema
into f7fa49159a32418f05ce7a2cef23b6cf4075c5af on main.


Lecture03. CustomLinkedList all test passed.

Щурбин Егор.

Coverage increased (+4.9%) to 65.066% when pulling 24adbdcd5ee0dff9dcef1275cc2f9a0209a2f021 on rentgen94:lecture03 into 354e59d14c8207f1a4977555c3526c00fb22514d on rybalkinsd:lecture03.


[CLOSED] Olwa/dev

 Issue by owalk
Sunday Feb 05, 2023 at 03:38 GMT
Originally opened as https://github.com/Sean-Nishi/M1Wengine/pull/17

None

owalk included the following code: https://github.com/Sean-Nishi/M1Wengine/pull/17/commits

 Comment by owalk
Sunday Feb 05, 2023 at 20:43 GMT

I've been out of the house since I woke up, there might be some time before I sleep tonight if your free. The PR isn't ready for review yet tho

 Comment by Sean-Nishi
Sunday Feb 05, 2023 at 16:10 GMT

Let me know if you have some time today and we can go over your changes from last night. I might have to leave before 3 today though

 Comment by owalk
Tuesday Feb 07, 2023 at 04:28 GMT

This is now ready for review. I've cut back, for now, to just black and flake8 to get us started. We can fix up the README for pulling in dependencies and using the tools next PR - documented here https://github.com/Sean-Nishi/Lunk-Game/issues/22


dwc_event_date not ISO 8601 compliant

https://github.com/SpeciesFileGroup/taxonworks/blob/86886f4939cbc3e94a2de2a8a083ac914b22b2e3/app/models/collection_object/dwc_extensions.rb#L115
That returns dates in the form YYYY/MM/DD-YYYY/MM/DD, should be YYYY-MM-DD/YYYY-MM-DD.
Do we have anything relying on current format that would block changing to ISO format?
Also, there is a potential semantic problem here (also affecting #1887) involving the meaning of the time interval.
https://dwc.tdwg.org/terms/#dwc:eventDate

Definition: The  date-time or interval during which an Event occurred. For occurrences,  this is the date-time when the event was recorded. Not suitable for a  time in a geological context.

Comments: Recommended best practice is to use a date that conforms to ISO 8601-1:2019.

Up to that point it seems to be used to indicate when the event started and when it finished, but then on examples:

Examples: 1963-03-08T14:07-0600 (8 Mar 1963 at 2:07pm in the time zone six hours earlier than UTC). 2009-02-20T08:40Z (20 February 2009 8:40am UTC). 2018-08-29T15:19 (3:19pm local time on 29 August 2018). 1809-02-12 (some time during 12 February 1809). 1906-06 (some time in June 1906). 1971 (some time in the year 1971). 2007-03-01T13:00:00Z/2008-05-11T15:30:00Z (some time during the interval between 1 March 2007 1pm UTC and 11 May 2008 3:30pm UTC). 1900/1909 (some time during the interval between the beginning of the year 1900 and the end of the year 1909). 2007-11-13/15 (some time in the interval between 13 November 2007 and 15 November 2007).

(Last example potentially not compliant actually, not parseable by iso8601 gem nor Ruby built-in parser)
So question here is what is the purpose of eventDate interval, is it to express uncertainty or to express a time span? And is it a 1:1 mapping to TW semantics for start_date_*/end_date_*?
PS: Not belonging to this issue tracker but after making a change all data will have to be re-indexed.

We not so long ago pushed hard to get everything unified to reference the dash version in TW:
https://github.com/SpeciesFileGroup/taxonworks/blob/development/lib/utilities/dates.rb#L6
Re certainty vs. time span.  I think they are the same thing.  I think of it as asserting knowns (certain of X).  If that happes to be certain it's uncertain that's fine.  From those examples I thnk the mapping is 1:1 semantically.
I'm anticipating significant health/re-indexing options for the DWC index, we'll be blowing it away with the merged of the export branch.

Not sure I follow all the nuances here. But historically note that DwC used to have dwc:earliestDateCollected and dwc:latestDateCollected, but these were deprecated.
So in this single term / concept you can provide a single date, or a date range.
I don't believe it's meant to represent uncertainty. If there was uncertainty (say a label that reads"June? 1896"), I might put dwc:verbatimEventDate = June? 1896, but in dwc:eventDate you could just put 1896. Does that help?

Is anything related to import here? Is it OK if I go ahead and change eventDate output format on development branch to produce valid ISO date?

Where is the output format?

2.7.2 :001 > Utilities::Dates.today
 => "2021-02-23"
2.7.2 :002 > Utilities::Dates.from_parts(2021,02,23)
 => "2021/02/23"
2.7.2 :003 > Utilities::Dates.today.inspect
 => "\"2021-02-23\""
2.7.2 :004 > Utilities::Dates.from_parts(2021,02,23).inspect
 => "\"2021/02/23\""

Perhaps as a first step add functions to this library that mention iso8601 explicitly in their names and refactor all code later when it is safe that it won't brake anything switching format? (The iso-variants would be used only for dwc_occurrence at this time.)

That's fine.  Reality is we should use an gem that is not ours to deal with these kind of issues.
We need to unify on '-' rather than / as well, at least internally.


fix: text input: removes unused interface omits a prop from text area and alphabetizes types

SUMMARY:
There was an unused interface, replaced with Label component quite a while ago. Also omitted the 'clearable' prop from TextArea as it's not needed.
JIRA TASK (Eightfold Employees Only):
ENG-29004
CHANGE TYPE:

[X] Bugfix Pull Request
[ ] Feature Pull Request

TEST COVERAGE:
N/A type cleanup
TEST PLAN:
Pull the pr branch and do yarn and yarn storybook. Verify the TextArea, TextInput stories behave as expected. You may also us Codesandbox CI to test.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@0bb0072). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #362   +/-   ##
=======================================
  Coverage        ?   89.43%
=======================================
  Files           ?      481
  Lines           ?    12992
  Branches        ?     4372
=======================================
  Hits            ?    11619
  Misses          ?     1348
  Partials        ?       25

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


feat: refactor drag/copy of tiles to support multiple tiles and shared models

#1601 implemented drag/copy of a single data card or table tile associated with a single SharedDataSet, but that implementation would not work for multiple tiles, multiple shared models, or even any other single tile. This PR represents a work-in-progress attempt to implement the general case of copying any selected tiles and any shared models to which any of those tiles are connected. The tricky part of the process is that shared models are linked to tiles by their tile ids, but tile ids are remapped during the copy process, so the tile id links from shared models to tiles must also be remapped during the copy process. The essence of the approach is to:

generate new ids for the tiles to be copied
update the shared models to make use of the new ids
copy the shared models into the document
copy the tiles (having modified the tile copying code to make use of the new ids we generated in step 1)

This implementation has not been tested end-to-end and so may not be complete, but most of the important parts should be in place. Some tests should also be written to test the new functionality.

I tested the basic case of dragging 2 tiles over that were linked together. This seemed to work. The one issue I saw is that the "link" icon does not show up when I do this. You can see that in the screenshot. If I reload CLUE and open the dropped tiles document again, then it does show up. To me it doesn't seem worth fixing that issue in this PR.

So @kswenson I think this is ready for review now. I don't think I can add you as an official reviewer since you opened the PR.
For the record I don't think the Jest tests for this are very good. They get the job done to make sure it is working as expected but I was trying to save time by using snapshots instead of writing the code to make it clear what the important part of the results is. I hope we can clean them up in the next PR which will move more of the drop code out of the document-content.

I'm going to merge 184812233-duplicate-tiles into this branch and resolve the merge conflicts. We are planning to merge #1672 into master first so I'm getting getting a head start.
Do not merge this PR into master yet. I'm taking it back to draft to help prevent that.


Remove !bang notification

@sreilly we can remove this notification that appears after tapping the !bang-icon:

all fixed.  testflight build coming soon!


⚠ Bofrost.de has degraded performance

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

HTTP code: 200
Response time: 1648 ms

Resolved: Bofrost.de performance has improved in 270ec4c after 37 minutes.


Hammer.JS versus HTML5 Drag and Drop

So, many modern browsers have native implementations of HTML5 Drag and Drop:

http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html
http://www.html5rocks.com/en/tutorials/dnd/basics/
http://html5demos.com/drag

The specification has the following events:

dragstart
drag
dragenter
dragleave
dragover
drop
dragend

The specification definitely has some problems, and I've recently spent some time working with it and can echo the sentiment found here: http://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.html
Is there room in Hammer.JS's scope to cover some of the features from the specification, but in a sane way? Specifically, the dragenter, dragleave and dragover events are not covered by Hammer currently, and might cover common use cases.
This may be partly related to #230.

Closing this hammer dropped all drag support in v2

Can you please clarify - what's the recommended way to implement Drag & Drop? Or hammer.js doesn't implement it at all and some other library supposed to be used?

@alexeypetrushin did you find any solution?


TypeError: Error.captureStackTrace is not a function

Hello, i'm having this exception whenever i try to render a slate document:
Uncaught TypeError: Error.captureStackTrace is not a function
c slate-to-react.mjs:1
d slate-to-react.mjs:1
U slate-to-react.mjs:1
W slate-to-react.mjs:1
X slate-to-react.mjs:1
X slate-to-react.mjs:1
Y slate-to-react.mjs:1
Z slate-to-react.mjs:1
React 3
Z slate-to-react.mjs:1
te slate-to-react.mjs:1
React 12
workLoop scheduler.development.js:266
flushWork scheduler.development.js:239
performWorkUntilDeadline scheduler.development.js:533
slate-to-react.mjs:1:262

Oh, right, I forgot this is V8 only method. Sorry about that, lemme just disable it :)

The fix available in https://github.com/octet-stream/slate-to-react/releases/tag/v0.7.2

I've forgotten I left another Error.captureStackTrace in another place. The issue is resolved in https://github.com/octet-stream/slate-to-react/releases/tag/v0.7.4
Tried out in Safari and Firefox.
See in codesandbox. Just uncomment 16-31 lines. Then save file and it will show you NoMatcherError instead of TypeError.

I'm gonna close this, your issue must be resolved.

@octet-stream thanks !


Review

Review app structure

I don't have much thing to comment on, just some spacing stuff, but that's not critical right now since I'm closing this in favor of our next workshop. nice job! 👍


[Question] Are there python functions to call cruft create, update, and check?

Is there a way to use cruft as a python library instead of cli?
Right now I call cookiecutter (v.1.7.3) as a python function
_ = cookiecutter(
        template=git_repo_url,
        no_input=True,
        extra_context={"project_name": project_name, **context},
        output_dir=tmpdir,
        directory="",
    )

where the template is a url to a git repository.
can i do the same with cruft? and by pointing to a github repository?
EDIT:
Create
I suppose for create, I can use this?
https://github.com/cruft/cruft/blob/3ec724634d8509d37164f2473ddf8674f072474c/cruft/_commands/create.py#L12

Yes, they are documented at https://cruft.github.io/cruft/reference/cruft/.


The YOLO PR

that looks nicer and should work faster!
Signed-off-by: Krasi Georgiev<EMAIL_ADDRESS>

Hello :)

/benchmark

/bencmark cancel

/benchmark cancel
:P

/benchmark cancel
:P


How to ensure that :resque is running?

Hi all, I tried to switch the trategy to :resque. Here is my code in chewy.rb:
Chewy::Config.instance.request_strategy = :resque

How can I ensure that the queue at: https://github.com/toptal/chewy/blob/master/lib/chewy/strategy/resque.rb
is working properly?

Better use Chewy.request_strategy = :resque
Well, the same way as you are doing for any other job. You can try to do a request and take a look on resque log, there should be a new job executed. Also maybe there will be chewy index entries in the log. After that you can try to search and make sure that changes are applied to the index.

Yes, i start the queue:
QUEUE=chewy bundle exec rake resque:work
and it works, thanks @pyromaniac

Awesome :)


npm version is behind github

Please push a new version on npm, as the function calls are different and you've added getDepartures.
Thanks for your work btw! :)

Hey! Am currently out backpacking in Southeast Asia and will be back in July, so might be a bit hard to push new versions :) will try to do it when I find a computer that works. Glad to hear you like it!

Actually managed to publish version 0.0.2 using SSH and my phone - latest commit in master is live in the npm registry now :)


Remove "Try Beta!"

We don't need the beta.
Remove the button and all functionality of the Beta https://cl.ly/0K1p2o0j0c3k

For now release let's hide the button


pd.read_sql get timestamp when the db time precision is ns

taos version: <IP_ADDRESS>
taospy version: 2.6.2
DB's time precision is ns which create db by:create database xx precision 'ns'. And use pd.read_sql to read data from this db's table.But the time column is int64 type not datetime type.

请参考：https://docs.taosdata.com/connector/python/#关于纳秒-nanosecond

谢谢！


Is it possible to use only the gpt4 model?

Just took a quick look at the backend code, but it seems like https://github.com/Azure-Samples/azure-search-openai-demo/blob/main/app/backend/app.py lines 21 and 22 describe the environment variables that needed to be changed pointing to GPT-4 instead.

@anderl80 check this PR #394

You can now use gpt-4 by changing a single line in the Bicep file, see the FAQ here:
https://github.com/Azure-Samples/azure-search-openai-demo#faq


Docker stops running after a period of time

1、
Error: read ECONNRESET
at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
Emitted 'error' event on ClientRequest instance at:
at TLSSocket.socketErrorListener (node:_http_client:502:9)
at TLSSocket.emit (node:events:513:28)
at emitErrorNT (node:internal/streams/destroy:151:8)
at emitErrorCloseNT (node:internal/streams/destroy:116:3)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
errno: -104,
code: 'ECONNRESET',
syscall: 'read'
}
2、
Node.js v18.15.0
info: Updating Game Files...
info: Logging in 011173388
debug: 011173388 About to connect
info: Logging in vyrun67834
debug: vyrun67834 About to connect
info: Listening for HTTP on port: 80
info: 011173388 Log on OK
info: 011173388 Initiating GC Connection
debug: Sending GC message ClientHello
debug: Sending hello, setting timer for next attempt to 2000 ms
debug: Got handled GC message ClientWelcome
debug: Unknown SO type 2 with 1 items
debug: Unknown SO type 7 with 1 items
debug: GC connection established
info: 011173388 CSGO Client Ready!
debug: Got handled GC message MatchmakingGC2ClientHello
debug: Got unhandled GC message ClientGCRankUpdate
debug: Got unhandled GC message GC2ClientGlobalStats
info: vyrun67834 Log on OK
info: vyrun67834 Initiating GC Connection
debug: Sending GC message ClientHello
debug: Sending hello, setting timer for next attempt to 2000 ms
debug: Got handled GC message ClientWelcome
debug: Unknown SO type 2 with 1 items
debug: Unknown SO type 7 with 1 items
debug: GC connection established
info: vyrun67834 CSGO Client Ready!
debug: Got handled GC message MatchmakingGC2ClientHello
debug: Got unhandled GC message GC2ClientGlobalStats
debug: Got unhandled GC message ClientGCRankUpdate
debug: Fetched schema.json
debug: Fetched items_game.txt
node:events:491
throw er; // Unhandled 'error' event
^
Error: read ETIMEDOUT
at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
Emitted 'error' event on ClientRequest instance at:
at TLSSocket.socketErrorListener (node:_http_client:502:9)
at TLSSocket.emit (node:events:513:28)
at emitErrorNT (node:internal/streams/destroy:151:8)
at emitErrorCloseNT (node:internal/streams/destroy:116:3)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
errno: -110,
code: 'ETIMEDOUT',
syscall: 'read'
}

Same for me.
I suggest that problem source is Steam User module by Alex Corn, probably in protobuf messages while processing inspections via proxy

Same problem...
"steam-user": "^5.0.9"
"globaloffensive": "^3.1.0"

This seems to have something to do with networking, so try adding a restart policy that restarts your program when an exception exits.The change I made to this is to modify the docker_start.sh file to add some listener exit code that will wait a few minutes to restart if the code is not equal to 0.The reason we wait a few minutes for the restart is because this can happen many times over a short period of time,so, try to run multiple docker containers at the same time so that if one of them exits, it won't affect the service
while true; do
    node index.js -c /config/config.js -s /config/steam_data
    exit_status=$?
  if [ $exit_status -ne 0 ]; then
    sleep 600
  else
    exit 0
  fi
done