Add environment Optional Setting

Sentry supports a custom option to set your environment but segment integration doesnt: https://docs.sentry.io/clients/javascript/config/#optional-settings
This particular custom option allows you to handle different environments without the need of creating different projects for each of them in Sentry.
Add another option called environment to the Sentry destination setup modal under the Optional Settings (string value - defaulting to null) to be sent to Sentry as follows:
environment
Track the environment name inside Sentry.

{
  environment: 'production'
}

Hey @diegoprd, thanks for creating this issue! I've added this in a report to our engineers as it's a better workflow to track user requests for integration changes. That being said I'll close out this issue and update you when our team has investigated the new Sentry library.
Please submit all future requests to us here: https://segment.com/contact
Thank you!

I was looking for the same option but eventually I created a small workaround. Load this after segment initialization:
window.analytics.ready(() => {      if (window.Raven) window.Raven.setTagsContext({ environment: 'production' }); });


Version 0.2.0 of QDax

Hi guys,
Time for us to move to version 0.2.0 :tada:
This release introduces:

fix a irrelevant 0.25 factor in td3 loss
fix a overflow issue in the replay buffer
clear the doc section about GPU usage with QDax
update jax, brax and flax versions
add a set of benchmarking functions from the QD community and clean the way we define our tasks
add a caveat section in the doc
add a QDax logo
scale the action space of pointmaze to match the action space of Brax tasks
add delay update in the PG emitter (PGAME)
fix reinitialisation of optimizer state in PG variations (PGAME)
introduce a wrapper to use fixed and known initial states for the Brax tasks
fix Brax version in colab
add the algorithm ME-ES
introduce a meta emitter to use multiple emitters in parallel, called MultiEmitter
add the algorithm CMA-ME with all its possible variants through the introduction of all three CMA emitters (improvement, random direction, optimization)
fix CMA ES optimizer
fix issue in CMA-MEGA
add the algorithm QDPG through the introduction of the Diversity PG emitter
refactor PGAME to use the multi emitter class
add template for pull requests
add DistributedMAPElites, an example of how to distribute a QDax algorithm on multiple devices
fix run-image stage in docker
avoid multiple jits of same method in for loops in our notebooks examples
add the extra_scores in the API of the repertoire addition in MAP-Elites

Codecov Report

Merging #126 (f84f887) into main (2fb5619) will increase coverage by 2.73%.
The diff coverage is 97.11%.

@@            Coverage Diff             @@
##             main     #126      +/-   ##
==========================================
+ Coverage   89.58%   92.31%   +2.73%
==========================================
  Files          67      103      +36
  Lines        3907     5816    +1909
==========================================
+ Hits         3500     5369    +1869
- Misses        407      447      +40

Impacted Files
Coverage Δ

qdax/core/mome.py
100.00% <ø> (ø)

tests/baselines_test/cmamega_test.py
98.36% <ø> (ø)

tests/baselines_test/dads_smerl_test.py
97.14% <ø> (ø)

tests/baselines_test/dads_test.py
96.92% <ø> (ø)

tests/baselines_test/diayn_smerl_test.py
96.96% <ø> (ø)

tests/baselines_test/diayn_test.py
96.72% <ø> (ø)

tests/baselines_test/ga_test.py
100.00% <ø> (ø)

tests/baselines_test/omgmega_test.py
98.36% <ø> (ø)

tests/baselines_test/td3_test.py
98.27% <ø> (ø)

qdax/tasks/qd_suite/qd_suite_task.py
79.31% <79.31%> (ø)

... and 61 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Default from/to get merged the wrong way

g = Opto::Group.new(defaults: { from: :env })
o = g.build_option(type: :string, name: 'foo', from: { prompt: "foo" })
o.from
=> { prompt: "foo", env: 'foo' }

Should probably be:
o.from
=> { env: 'foo', prompt: "foo" }

Actually it makes perfect sense for anything but prompt


VT1000 some alarts not functing

VT1000 device alarms not functioning well, I'm using port 5009 meiligao protocol (traccar 3.9 version). seems like they haven't decode. Like ignitionOn/Off harshbreak/acceleration, is there any specific reason for this or can this be done?
I can see SOS, power alarms are working fine. this device has inbuilt alarm functions as well as OBD reader connection port.
thanks.

I would need HEX messages where you expect to see missing alarms, and protocol documentation.

GPRS Communication Protocol 7.0 (new） VT1000 .pdf
Here i have attached the protocol document.
in the installation document, i can see we are connecting Ignition wire (ACC) to Input 4 (0x04 - ignitionOn, and  0x34 fot IgnitionOff),
as well as you can see some of the command we can send to the device. (for Engine Stop, Output 1)
Set authorization RFID,
Alarm code Definition
=0x01 SOS button is pressed / Input port 1 close
=0x02 2nd button (Call B) is pressed / Input port 2 close
=0x03 3rd button (Call C) is pressed / Input port 3 close
=0x04 Input port 4 close
=0x05 Input port 5 close
=0x11 Over speed alarm
=0x12 movement alarm
=0x13 Geo fence alarm
=0x31 SOS button is released/Input port 1 open
=0x32 Call B button is released/Input port 2 open
=0x33 Call C button is released/Input port 3 open
=0x34 Input port 4 open
=0x35 Input port 5 open
=0X50 external power cut
=0x72harsh braking
=0x73 harsh acceleration
=0x75 camera error
=0x74 lose oil
=0x76 add oil
=0x14 impact alert
Thanks.

I would need HEX as well.

Hi,
here some hex codes,
2424005a201708211fffff9934303030382c303030307c3131313132302e3030302c412c313534382e323436392c532c30333530332e363931332c452c302e30322c3330362e32332c3236303831372c2c2c412a373451c90d0a
2424005a201708211fffff9934303030302c303030307c3131313232302e3030302c412c313534382e323437312c532c30333530332e363930332c452c302e30352c3135342e34312c3236303831372c2c2c412a373964620d0a
Input 4 Open or Close
2424007b201708211fffff99553131313432302e3030302c412c313534382e323530372c532c30333530332e363837312c452c302e30312c3232312e33312c3236303831372c2c2c412a37397c302e39367c313136342e307c303030307c303030302c303030307c3030303030303239367c303030303088cf0d0a
2424005a201708211fffff9934303030302c303030657c3131313434392e3030302c412c313534382e323530302c532c30333530332e363836372c452c302e30322c3133362e39362c3236303831372c2c2c412a3744c75c0d0a

I have added some new alarms, but I don't see anything about ignition.

ignition should be input 4
thanks

Where does it say that?
Also, it seems like you didn't wait for the image to load.

installation diagram.

Where is diagram from? Can I see official documentation?

Here i have attached the User Manual.
User Manual of GPS Tracker VT1000 Topshine(V4.3).pdf

It seems like it's just one example. It's not guaranteed that input4 will be connected to ignition.

If we are not getting one of them as ignition, we are missing that important alert.
1-3 inputs are negative inputs, 4,5 are only positive inputs, so we must connect ignition to 4 or 5.
this is my propose as supplier guidance, (SOS button also connected to input 1)
thanks.

Does "open" in documentation mean that input is active?

Yes, open means vehicle is on state. (input percent ). sorry late reply.

I have added support for inputs.

Thank you,
Did you add to the V3.9, can i get the jar file if possible.

Not sure if you are familiar with software versioning, but nothing is ever added to existing versions. You need to wait for a next version of build from source yourself.


CLI: keybase saltpack encrypt now uses identify2

make an Identify2+Resolve all-in-one engine

rename identify2 test now that we have ResolveThenIdentify2 also covered

identify2 + salt pack encryption integration

Simplify exp encrypt options; don't need tracking integrated; use the same strategy we're going to use in KBFS

As a result, we got rid of one test case.
Make the device keyfinder therefore slightly simpler, but also add a filter for encryption of verification keys, while we are at it.

Temporary fix for a bug: which is that if we issue something like:
keybase exp encrypt t_tracy@rooter+keybase.io@web

We'll get an eager failure, the client will exit, but the service will still
make additional RPCs on a dead channel.
The problem is that due to bugs in the RPC library, this will hang indefinitely,
and the service will be deadlocked since it holds a singleflight lock for the
user as it's waiting for an RPC reply that will never come.

@akalin-keybase when you get a chance, can you take a look? Thanks!

It is with immense frustration that I report that the test TestSaltPackEncryptionLoggedOut deadlocks when run with the rest of the tests, but not individually

Sigh, it's obvious in retrospect.  RPC had nothing to do with it, since engine tests don't use the RPC channel for UI interaction.

Made a pass, although I'd like to take another look after this is rebased

Ok, rebased and stripped out that unneeded Index field.

lgtm


Dropdown menu button has the same tooltip as new tab button

The dropdown menu button (˅) shows the same tooltip as the new tab button (+).  That seems odd.
And (I've mentioned this before)  the "˅" on the dropdown menu button looks oddly puny compared to the "+" on the new tab button.
Microsoft Windows 10 Pro for Workstations
10.0.19044.1889 (2009, 21H2)
WindowsTerminalPreview 1.15.2208.16002

Thanks for the suggestion! This is actually already being tracked by another issue on our repo - please refer to #6078 for more discussion.
/dup #6078
/dup https://github.com/microsoft/microsoft-ui-xaml/issues/2064 (related)

Hmmm!  I did search but figuring it was an easy fix I didn't go back that far in time.  :-)


TreeSize v9.1.1

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hi @JAMSoftwareAutomatedTasks,

This PR's version number 9.1.1 has 3 parameters (sets of numbers between dots - major, minor, etc), which is greater than the current manifest's version 9.1, which has 2 parameters.

Is this intentional?
(Automated response - build 677)


Query: EntityTrackingInfo depends on QSRE which is not valid for owned entities

Owned entities may not always have QSRE referencing them since they cannot be query root. It is impossible to track them otherwise.

I assume this is not needed anymore


browse sort by size with files of same size

If browse is sorting by size and the files have the same size the order is not predictable.
I'd suggest that the fix should be if sorting by size (or modified) to secondarily sort by name.

This sounds complicated. Is the deterministic sorting of items with the same size/date/name/whatever really important? What situations are you finding that you need the exact same order of elements with the same value?

I spotted it during messing with the browse code. I created some more files in the test folder and the json test started failing. I doubt it's something that would ever bother me, and I solved it by making my test files have different sizes.

Although unlikely, the obvious next question is, what if the elements have the same first and second values (e.g. same size and modify timestamp -- not unheard of if files are generated programmatically)? I think for the sake of unit tests we'll just have to ensure the elements have different values (i.e. every file has a different timestamp or size, depending on what is being tested). If it ever comes up in practice, then perhaps we could revisit it if the situation was common enough and really merited the extra complexity.
Thanks for thinking about it and raising an issue!


Include PyPi and downloads badges in documentation

This PR includes the PyPi and number of downloads badges. Adding the badges helps with visibility of the package and therefore increase traffic.

Thanks


TypeError when plotting account performance using start-time parameter

When I plot the performance of my account using time_back as parameter I can see the chart successfully.
HOWEVER, when I use a specific date instead is gives me this type error...
TypeError: string indices must be integers
I use the following code:
from_date = datetime(2024, 8, 28, 0, 0, 0)
nl = account.get_net_liquidating_value_history(session, start_time=from_date )

Hey, thanks for opening this!
I did some digging and it looks like there's something wrong on with the Tastytrade API, so there's nothing the SDK can do to resolve this at this time, unfortunately! Maybe you could reach out to the support team and tell them that the endpoint is not working as expected.

Hey @Graeme22, I think this issue can be closed.
I reached out to the API team at Tasty and they didn't have any clear answers. I think there's something else not properly set on their end. Thanks

Thanks for looking into it!


Replace pg_listen with NOTIFY and add configuration variables

Closes #335

Replace pg_listen

@laurenceisla I think we should leave the pg_listen option, but at the bottom. The thing about db-channel is that it needs a postgres session, and when using postgrest behind a connection pooler(like pgbouncer) that is not always possible.

Replace pg_listen

@laurenceisla I think we should leave the pg_listen option, but at the bottom. The thing about db-channel is that it needs a postgres session, and when using postgrest behind a connection pooler(like pgbouncer) that is not always possible.

I've checked the pg_listen utility and it also uses the LISTEN command on a notification channel, so it wouldn't work with a connection pooler either. In this case I think pg_listen is entirely replaced by the NOTIFY command.

@laurenceisla Good catch!
You're right, pg_listen would have the same problem, mentioning it as an alternative would make no sense.
We should notify our users of this change though. How about adding the change in the Upcoming page?


Looking for Flux version compatibility information

What Flux version is required for Capacitor? It would be great to find this information in the README.
I tried adding the OCIRepository resource described in the README to a cluster and got as a result:

error: error validating "capacitor.yaml": error validating data: ValidationError(OCIRepository.spec.verify): unknown field "matchOIDCIdentity" in io.fluxcd.toolkit.source.v1beta2.OCIRepository.spec.verify

The according key matchOIDCIdentity has been introduced to the OCIRepository CRD in https://github.com/fluxcd/flux2/releases/tag/v2.2.0
Apart from that identity verification, it would be nice to know if Capacitor relied on any Flux version specific features.

Thanks for the report.
The field in question was introduced in Flux v2.2.0. (source-controller v1.2.0), but it is not a mandatory thing. Just if someone wants to enable cosign based signature verification.
In general Capacitor requires Flux v2.0.0.
Made https://github.com/gimlet-io/capacitor/pull/79 to:

display compatibility note
and making cosign optional

Hope this helps. Now I removed the cosign part from the yaml. You can retry.


Replace our iree/compiler/Dialect/VM/Analysis/ValueLiveness.h with upstream Liveness.h

This should do everything we need and is tested/improved upstream :)
https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir%2Finclude%2Fmlir%2FAnalysis%2FLiveness.h#L41

I'd like to work on this if this is still relevant

I'd like to work on this if this is still relevant

That'd be fantastic!

That'd be fantastic!

That'd be fantastic!

So just to clarify, we want to switch completely from ValueLiveness.h and ValueLiveness.cpp? Or am I getting something confused and it's more or less a simple switch?

That'd be fantastic!

So just to clarify, we want to switch completely from ValueLiveness.h and ValueLiveness.cpp? Or am I getting something confused and it's more or less a simple switch?

Ideally yes we can delete those files and where we were using it use the mlir::Liveness analysis - for example replacing calls to https://github.com/google/iree/blob/bb0f95eb8ab82054ff87469a29e8abe7d43149d7/iree/compiler/Dialect/VM/Analysis/ValueLiveness.h#L54 with calls to https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir/include/mlir/Analysis/Liveness.h#L72
(and so on)
There may be some gotchas that may require new features to the upstream liveness - though I suspect that reworking our code to better match what mlir::Liveness does is best. It's just 3 methods, though, so hopefully not too bad to make line up :)

Ideally yes we can delete those files and where we were using it use the mlir::Liveness analysis - for example replacing calls to https://github.com/google/iree/blob/bb0f95eb8ab82054ff87469a29e8abe7d43149d7/iree/compiler/Dialect/VM/Analysis/ValueLiveness.h#L54 with calls to https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir/include/mlir/Analysis/Liveness.h#L72
(and so on)
There may be some gotchas that may require new features to the upstream liveness - though I suspect that reworking our code to better match what mlir::Liveness does is best. It's just 3 methods, though, so hopefully not too bad to make line up :)

Ideally yes we can delete those files and where we were using it use the mlir::Liveness analysis - for example replacing calls to
https://github.com/google/iree/blob/bb0f95eb8ab82054ff87469a29e8abe7d43149d7/iree/compiler/Dialect/VM/Analysis/ValueLiveness.h#L54
with calls to https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir/include/mlir/Analysis/Liveness.h#L72
(and so on)
There may be some gotchas that may require new features to the upstream liveness - though I suspect that reworking our code to better match what mlir::Liveness does is best. It's just 3 methods, though, so hopefully not too bad to make line up :)

Ok think I'm managing to do that.
Sorry to be noobish, but I can't seem to see if there's a function in upstream that can replace liveness.recalculate?

Ideally yes we can delete those files and where we were using it use the mlir::Liveness analysis - for example replacing calls to
https://github.com/google/iree/blob/bb0f95eb8ab82054ff87469a29e8abe7d43149d7/iree/compiler/Dialect/VM/Analysis/ValueLiveness.h#L54
with calls to https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir/include/mlir/Analysis/Liveness.h#L72
(and so on)
There may be some gotchas that may require new features to the upstream liveness - though I suspect that reworking our code to better match what mlir::Liveness does is best. It's just 3 methods, though, so hopefully not too bad to make line up :)

Ok think I'm managing to do that.
Sorry to be noobish, but I can't seem to see if there's a function in upstream that can replace liveness.recalculate?

Also, just to make sure with my limited knowledge of c/cpp if I'm doing things right. From mlir I'm using it like Liveness liveness(Operation *op)
And then calling it like liveness(op).getLiveIn(block)
Is that the way to do it?

Also, just to make sure with my limited knowledge of c/cpp if I'm doing things right. From mlir I'm using it like Liveness liveness(Operation *op)
And then calling it like liveness(op).getLiveIn(block)
Is that the way to do it?

Creating the Liveness information performs a bunch of processing to build the liveness information:
https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir/lib/Analysis/Liveness.cpp#L161
You'll want to reuse it such that you never rebuild it for the same operation.
Liveness liveness(op);
...
liveness.getLiveIn(block);

Creating the Liveness information performs a bunch of processing to build the liveness information:
https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir/lib/Analysis/Liveness.cpp#L161
You'll want to reuse it such that you never rebuild it for the same operation.
Liveness liveness(op);
...
liveness.getLiveIn(block);

Creating the Liveness information performs a bunch of processing to build the liveness information:
https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir/lib/Analysis/Liveness.cpp#L161
You'll want to reuse it such that you never rebuild it for the same operation.
Liveness liveness(op);
...
liveness.getLiveIn(block);

As far as I can see the ValueLiveness functions are used in a couple of places like RegisterAllocation, BytecodeModuleTarget
And the usage described in the upstream is the following Liveness liveness(topLevelOp).
Where would you recommend to initialize it?

Creating the Liveness information performs a bunch of processing to build the liveness information:
https://github.com/llvm/llvm-project/blob/1664462d70cc399c6a95b88a9e8e73cb44d8a151/mlir/lib/Analysis/Liveness.cpp#L161
You'll want to reuse it such that you never rebuild it for the same operation.
Liveness liveness(op);
...
liveness.getLiveIn(block);

As far as I can see the ValueLiveness functions are used in a couple of places like RegisterAllocation, BytecodeModuleTarget
And the usage described in the upstream is the following Liveness liveness(topLevelOp).
Where would you recommend to initialize it?

I still would like to not own this; if the upstream liveness analysis is insufficient it'd be great to fix it and drop our own implementation.


compiling zig on windows without visual studio

I'd like to log progress on it somewhere. Can't wait to try out zig on windows.
Author intends to get zig working with visual studio first, and only then work on other compilers. But I can't get visual studio to work here, so I have to wait. But let's try working in parallel...
First, ci/appveyor/build_script.bat is pretty confusing. The most confusing part is getting three vars, which evaluate to this on my system:
ZIG_LIBC_LIB_DIR
C:/msys64/mingw32/i686-w64-mingw32/lib
ZIG_LIBC_INCLUDE_DIR
C:/msys64/mingw32/i686-w64-mingw32/include
ZIG_LIBC_STATIC_LIB_DIR
C:/msys64/mingw32/lib/gcc/i686-w64-mingw32/6.3.0
It looks like their purpose is locating crt1.o and crtbegin.o. Shouldn't it be possible to work without them? Support table says that compiling freestanding exe on windows already works.
Is it possible to make 4 build targets for windows instead of one?
32bit
32bit-freestanding
64bit
64bit-freestanding

I'd like to log progress on it somewhere. Can't wait to try out zig on windows.

Glad to hear that because I've been doing a lot of work on windows in the past couple weeks.

It looks like their purpose is locating crt1.o and crtbegin.o. Shouldn't it be possible to work without them? Support table says that compiling freestanding exe on windows already works.

It is possible to work without them. These are needed if you want to include libc .h files such as stdlib.h or if you want to link against libc (which you almost certainly will have to if you depend on any C libraries).
If you wanted to run the zig compiler tests you would need a working libc as well since some of the tests test libc integration.

Is it possible to make 4 build targets for windows instead of one?
32bit

--target-os windows --target-arch i386 --target-environ msvc

32bit-freestanding

--target-os freestanding --target-arch i386 --target-environ msvc

64bit

--target-os windows --target-arch x86_64 --target-environ msvc

64bit-freestanding

--target-os freestanding --target-arch x86_64 --target-environ msvc
If you want artifacts to have the mingw C ABI instead of msvc, change msvc to gnu.
I think we need to update the linker code in zig for --environ gnu to work on windows. We also might want to wait for llvm 6.0 which has a mingw environ target and LLD supports the mingw linker args.
However you can always use zig to create a mingw compatible .o file using --environ gnu and use the mingw linker (or just mingw clang) yourself.
We do have zig building successfully with mingw and it looks like most tests are passing, so you should be able to play with this.

--target-os freestanding --target-arch i386 --target-environ msvc

Are those cmake arguments? If those are zig arguments, I need to get zig itself first. I asked you to modify ci/appveyor/build_script.bat , so that it doesn't have that weird bash magic. and just compiles.
Can you at least upload compiled zig for windows somewhere?

These are needed if you want to include libc .h files such as stdlib.h or if you want to link against libc (which you almost certainly will have to if you depend on any C libraries).

I don't depend on any C libraries. That's the whole point of freestanding exe files: only system provided dll. I'm a fan of demoscene, you see. Size matters, and all. I'll probably actually rewrite most of the libraries in zig, or at least those that I need.

If you wanted to run the zig compiler tests you would need a working libc as well since some of the tests test libc integration.

Can't care less about those tests, don't want to wait for them to pass. These are probably not necessary for me.
When I say "freestanding", I mean exe file that doesn't depend on C runtime, and only interacts with system provided dll directly. Is that the right use of that word? Or "freestanding" actually means just some object code that can't be even run by itself?

Can you at least upload compiled zig for windows somewhere?

I'm working on it as we speak. Here's the checklist I'm going through: #302

I don't depend on any C libraries. That's the whole point of freestanding exe files: only system provided dll. I'm a fan of demoscene, you see. Size matters, and all. I'll probably actually rewrite most of the libraries in zig, or at least those that I need.

Right. This is one of the main use cases of zig, so I am excited for you to try it out. In this case you do not need the ZIG_LIBC* configure arguments.
Can you try building with mingw without those configure arguments? It should work fine and then panic if you try to do anything with libc.
"freestanding" in zig lingo means that you are either compiling your own OS or targeting an OS that zig doesn't know about. (See the list output by zig.exe targets).
You're targeting Windows so you'll want to either compile natively (no --target-* arguments) or use --target-os windows. This has some effects on the code generated by LLVM, for example it will generate __chkstk calls if a stack frame is larger than a page, and it will mangle DLL calls by prepending an underscore, and do the stdcall mangling convention.
If you're doing demoscene stuff I'm guessing you want to avoid __chkstk as well as write your own startup code instead of relying on zig's startup code: https://github.com/zig-lang/zig/blob/a4310cf8b4f104802360cb854e2dcc48802301a6/std/special/bootstrap.zig#L34-L44
(actually now that I think of it, we should figure out how to tell LLVM to turn off __chkstk in release-fast mode)
And probably your own compiler-rt and memcpy/memset implementations instead of zig's compiler-rt and zig's memcpy/memset.
In this case I think you're right that freestanding is what you want. I've used freestanding to build an OS but I haven't tried to run freestanding code on windows yet and I'd like to do that before recommending something to you.
Perhaps you could live with zig's startup code and target windows for a little bit, then when you want to really optimize the last 1% we can move forward on this? Or play around with freestanding, hack on zig, sounds like you know what you're doing. I'm on IRC if you want to chat.
Don't forget to build with --release-fast to omit all the safety checks. :zap:

Size matters, and all.

One more thing. We currently have these build modes:

Debug (safety on, fast compilation, slow runtime performance, big binary)
ReleaseSafe (safety on, slow compilation, medium runtime performance, big binary)
ReleaseFast (safety off, slow compilation, fast runtime performance, big binary)

I'm considering adding

ReleaseSmall (safety off, slow compilation, medium-fast runtime performance, small binary)

Is this something you would be interested in?

Ideally ReleaseFast and ReleaseSmall should be the same, don't see much reason in separating those. But until we get there, sure, why not.
I'll set CodeGen.libc_static_lib_dir to empty string and see if anything breaks. I'll also start rewriting build system in bash and makefiles, because I'm having troubles with understanding cmake.

Ideally ReleaseFast and ReleaseSmall should be the same, don't see much reason in separating those. But until we get there, sure, why not.

Here are a couple reasons:

SIMD instructions. Sometimes faster code using SIMD ends up being bigger.
Unrolling loops. Sometimes unrolling loops is faster and takes up more space in the binary.

I'll also start rewriting build system in bat and makefiles, because I'm having troubles with understanding cmake.

ok. feel free to post an error log, I can probably tell you how to fix whatever happened.

It sounds like it will also make simplier assembly. Then yes, it's a good idea, make ReleaseSmall.

Issue to track it: #531

How do you think, will zig build as a 32bit app? Or I must have it 64bit?

Currently the zig compiler only works as 64-bit. We'll make it work as a 32-bit application when we self-host (See #89)

Ok, zig got built, and it actually works. Except it deadlocks on exit. Really weird.
I create this _.zig file next to zig.exe, with this content:
use @import("std").os.windows;
export fn WinMainCRTStartup() -> INT {
    _ = MessageBoxA(null, c"hello", c"title", 0);
    return 0;
}

and type this to compile it:
zig build-exe _.zig --target-os windows --target-arch i386 --target-environ gnu --release-fast -mwindows

It works nicely, result works, but zig itself never exits.
I tried to get callstack with x64dbg, here it is. Ignore everything that's not "Comment", read from bottom to top:
Address           To                From              Size              Comment                                            Party
000000000022F848  000007FEFD8A1420<PHONE_NUMBER>63C3EA  100               ntdll.000000007763C3EA                             System
000000000022F948<PHONE_NUMBER>3E06D0  000007FEFD8A1420  90                kernelbase.000007FEFD8A1420                        System
000000000022F9D8<PHONE_NUMBER>941EAD<PHONE_NUMBER>3E06D0  60                kernel32.00000000773E06D0                          User
000000000022FA38<PHONE_NUMBER>9421A0<PHONE_NUMBER>941EAD  80                libwinpthread-1.0000000064941EAD                   User
000000000022FAB8<PHONE_NUMBER>942721<PHONE_NUMBER>9421A0  B0                libwinpthread-1.00000000649421A0                   User
000000000022FB68  000000006FCD8A7C<PHONE_NUMBER>942721  30                libwinpthread-1.0000000064942721                   User
000000000022FB98<PHONE_NUMBER>216BFB  000000006FCD8A7C  80                libstdc++-6.000000006FCD8A7C                       User
000000000022FC18<PHONE_NUMBER>1C11D7<PHONE_NUMBER>216BFB  60                llvm.0000000070216BFB                              User
000000000022FC78<PHONE_NUMBER>1C12D8<PHONE_NUMBER>1C11D7  50                llvm.00000000701C11D7                              User
000000000022FCC8<PHONE_NUMBER>612B31<PHONE_NUMBER>1C12D8  120               llvm.00000000701C12D8                              System
000000000022FDE8<PHONE_NUMBER>612940<PHONE_NUMBER>612B31  30                ntdll.0000000077612B31                             System
000000000022FE18  000007FEFDD499E2<PHONE_NUMBER>612940  40                ntdll.0000000077612940                             System
000000000022FE58<PHONE_NUMBER>4014D5  000007FEFDD499E2  D0                msvcrt.000007FEFDD499E2                            User
000000000022FF28<PHONE_NUMBER>40152B<PHONE_NUMBER>4014D5  30                zig.00000000004014D5                               User
000000000022FF58<PHONE_NUMBER>3E59DD<PHONE_NUMBER>40152B  30                zig.000000000040152B                               System
000000000022FF88<PHONE_NUMBER>61A631<PHONE_NUMBER>3E59DD  50                kernel32.00000000773E59DD                          System
000000000022FFD8<PHONE_NUMBER>000000<PHONE_NUMBER>61A631                    ntdll.000000007761A631                             User

ntdll kernel32 msvcrt ntdll kernelbase are system dlls, libstdc++-6 libwinpthread-1 are from mingw-w64 (for some reason they are added to every program compiled with mingw, unless they are linked statically), there is llvm, there is zig
What I understood from it, is that zig calls exit from msvcrt, then other system dlls, then for some reason control flow goes back into llvm, then libstdc++, it calls pthread_cond_wait from libwinpthread, then some other system dlls.
I guess pthread_cond_wait is the cause of this. I'm not sure why llvm code gets executed at closing program, that's some C++ magic right here.

I'm not sure why llvm code gets executed at closing program, that's some C++ magic right here.

It doesn't happen with the msvc build, so it seems like a bug in mingw. Can probably work around by patching zig to call _exit (skips atexit handlers) instead of exit when built with mingw. Do you want to try it?

Replaced return EXIT_SUCCESS with _exit(EXIT_SUCCESS) and ExitProcess(EXIT_SUCCESS), no effect.
I replaced this one: https://github.com/zig-lang/zig/blob/8cfb0cfbcee8161c52f71bccc3cf1b8d988f83b0/src/main.cpp#L793
Linking is so slow here.

Deadlock on application exit is often caused by invocation of user code in DllMain when a DLL is unloaded. Such code is subject of restrictions but few care.
This is the hammer to exit w/o notifying DLLs:
TerminateProcess(GetCurrentProcess(), EXIT_SUCCESS);
Alternatively, it may be possible to unload suspected DLL manually (by repeatedly calling FreeLibrary/FindLibrary) before termination.

I think we want to do this on Windows anyway. There is no point in calling a DLL unload code.

I'm new to git, how can I keep TerminateProcess in the code, but still get updates?
TerminateProcess worked nicely, now I don't have to open task manager every time.

@pluto439
When you want an update:
git stash
git pull
git stash pop

Can you send me the diff so that  I can merge it upstream? GitHub pull request is easiest for me but I don't mind if you just want to paste a diff.

It's a terrible thing to merge, it only works on windows, it only works for one combination of console commands. But it works for now.
Probably should recompile llvm instead, maybe they fixed it by now.
Also don't know how to make diff here.

Also don't know how to make diff here.

git diff

It's a terrible thing to merge, it only works on windows, it only works for one combination of console commands. But it works for now.

ok

It takes 6 minutes to link zig.exe together. I need to decrease that time somehow if I want to get anywhere.
I suspect that adding -Wa,-mbig-obj to compiler flags might help. Need to add them somewhere in deps/lld/CMakeLists.txt. Where exactly should I add them?
https://stackoverflow.com/questions/16596876/object-file-has-too-many-sections

deps/lld/CMakeLists.txt is ignored. All cmake stuff is in the root CMakeLists.txt. Search for LINK_FLAGS.

-Wa,-mbig-obj didn't work.
Built lld as dll, it worked, linking only takes 10 seconds. Object files were so odd, they had thousands of sections.
I replaced this:
    add_library(embedded_lld_lib ${EMBEDDED_LLD_LIB_SOURCES})
    add_library(embedded_lld_elf ${EMBEDDED_LLD_ELF_SOURCES})
    add_library(embedded_lld_coff ${EMBEDDED_LLD_COFF_SOURCES})

with this:
    add_library(embedded_lld_lib SHARED ${EMBEDDED_LLD_LIB_SOURCES})
    add_library(embedded_lld_elf SHARED ${EMBEDDED_LLD_ELF_SOURCES})
    add_library(embedded_lld_coff SHARED ${EMBEDDED_LLD_COFF_SOURCES})

    target_link_libraries(embedded_lld_coff ${LLVM_LIBRARIES} ${CLANG_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT} embedded_lld_lib)
    target_link_libraries(embedded_lld_elf ${LLVM_LIBRARIES} ${CLANG_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT} embedded_lld_lib)
    target_link_libraries(embedded_lld_lib ${LLVM_LIBRARIES} ${CLANG_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT})

And to free myself from ninja install every time, changed this:
install(TARGETS zig DESTINATION bin)

to this:
install(TARGETS zig DESTINATION .)

Ah if that improved link time, you night also improve link time by linking against libLLVM.so instead of individual libraries and the .so versions of clang libraries instead of .a

You would edit cmake/Findllvm.cmake and cmake/Find clang.cmake

Yeah, I'm already linking to LLVM.dll that came with msys2, I didn't compile it myself. It's probably the reason why it deadlocks. It worked like that out of the box, without me editing findcmake files.

Uploaded everything I said in this thread as a mingw.patch, since I now know how to do those. In a zip, github doesn't support .patch
mingw.zip
To create:
git diff > mingw.patch
To apply (made pa.bat for it):
git apply mingw.patch
To reverse (made pu.bat for it):
git apply -R mingw.patch
I guess I'll just keep unapplying and applying this patch every time I need to get newest version from git.
To actually compile, use this:
mkdir build
cd build
cmake -G"Ninja" .. -DCMAKE_INSTALL_PREFIX=.
ninja install

To get a short beep once it's done compiling, use this:
ninja && python -c "print '\7'"


No information regarding SpatialAwareness mesh retrieval

Issue Description
I want to retrieve the mesh generated by the Spatial Awareness System and do operations on it in other to generate more data (like getting floor, walls, etc) but I had no idea how to do that. I was only able to do this thanks to @wiwei , who showed me the method below to gain all observers (each observer having its meshes collection).
MixedRealityToolkit.SpatialAwarenessSystem.GetObservers<IMixedRealitySpatialAwarenessMeshObserver>()
It appears the base interface IMixedRealitySpatialAwarenessObserver does not provide access to the meshes.
Feature Area
It would be nice to access the whole mesh/all meshes used for the Spatial Mapping more easily, without having to go through multiple lists of lists. Even better if there were tools to easily process information out of these meshes.
Existing Doc Link
Missing documentation regarding this.

Here is more detail about the issue:
The only way to get the meshes is through the IMixedRealitySpatialAwarenessMeshObserver interface. Specifically the IMixedRealitySpatialAwarenessMeshObserver.Meshes property.
But the path customers will follow to access the service is MixedRealityToolkit.SpatialAwarenessSystem.GetObservers() and that method returns a list of objects of type IMixedRealitySpatialAwarenessObserver.
The IMixedRealitySpatialAwarenessObserver interface does not have a .Meshes property. Only IMixedRealitySpatialAwarenessMeshObserver does. It’s unclear to me why any spatial awareness observer would not provide meshes. Therefore it’s unclear to me why IMixedRealitySpatialAwarenessObserver does not have a .Meshes property. If this was accidentally omitted, it should be added. If there is a real reason for this omission then documentation should be updated to describe how to enumerate and query the meshes.
FYI, this does seem to be a common theme of confusion for developers. There are many service provider interfaces in the MRTK. We start with the most generic interfaces exposed at the MixedRealityToolkit object, then require developers to cast these basic interfaces in order to access commonly needed functionality. Unfortunately, because these casts are not documented, developers do not know how to access the information they need. This issue with accessing spatial observer meshes is another example of the problem I tried to call out here.

I own documenting this (ETA: week of 7/8).
The overall rationale behind this architecture is that there will be multiple types of spatial observers. Once MRTK support is expanded to phone AR, there will be observers that will natively deliver planes.
If the spatial awareness system directly exposed meshes today, it would need to directly expose planes "tomorrow". That would constitute a breaking change to the IMixedRealitySpatialAwarenessSystem interface.
The implementation of casting the interface to an instance of IMixedRealityDataProviderAccess provides a cross system pattern for accessing data providers (note: observers are data providers and the existing GetObservers methods have been deprecated).

I've added information about how to do this to the MRTK docs themselves:
https://microsoft.github.io/MixedRealityToolkit-Unity/Documentation/SpatialAwareness/UsageGuide.html


Basic tz::gl functionality

tz::gl is an upcoming graphics module in Topaz-2 which serves as a low-level wrapper for OpenGL functionality.
Implement modern-opengl features to be used in higher-level rendering modules. Example basic features expected of tz::gl:

TZGLP (tz::gl::ShaderPreprocessor)
tz::gl::Shader
tz::gl::Model & tz::gl::Mesh
tz::gl::RenderScene (?)

All of these modules should be Unit-Tested as extensively as reasonably possible. UB is to be avoided at all costs, especially on a module this low-level!

I think we're pretty much there now. I just finished the SSBO TZGLP Module and was able to make a new demo using it. We now have 2 tz::gl demos.
The only thing really missing now is matrix maths, but that's kind of out-of-scope here -- We can do basic graphics now.


Added animanted icons

add animated icons on home page

add animated icons on home page

looking nice, will be merged after some time

bro @creator79 , uhm i want to let you know that some of other updates are coming in this project and i found these animated icons not giving a perfect look for the website. So please choose any other issue


No "K:" drive when syncing files on Windows 10

Hi there,
I'm using keybase on Windows. I tried today to use the Keybase Filesystem, but while I can upload files by dropping them on the Keybase client, I cannot access the synced directory from Windows, because no K: drive exists.

The relevant part from the documentation:

@dgellow Install https://dokan-dev.github.io/ driver

@proukornew Thanks, that worked. The documentation should be updated.


Fix links in the Runtime Class.

This PR fixes some links and adds a link for the DNS label name in the Runtime Class docs.

Hi @rajeshdeshpande02 @dchen1107
Could you please take a look!

/kind cleanup

Page preview:
https://deploy-preview-28419--kubernetes-io-master-staging.netlify.app/docs/concepts/containers/runtime-class/

Thanks @Shubham82 .
/approve


Ordt errors on fields using keywords

Hi,
congratulations on the new role first and thanks for continued development of Ordt.
I'm not sure if this is a bug or you just don't accept the use of keywords in the RDL but I'm seeing the following issue.  I've been using the systemrdl-compiler and this seems happy with the naming.
I've noticed that both a field called 'enable' and one called 'threshold' cause Ordt to bomb out with the following error:
line 3:34 extraneous input 'enable' expecting ';'
*** ERROR ***: RDL parser errors detected.

An example follows:
regfile my_reg {
        reg {
            field { reset=1'd0; } enable ;
        } my_cfg ;
} ;

addrmap addresss_map {
        my_reg _reg @0x0;
};

Just prefix the keyword with backslash, eg:
        field { reset=1'd0; } \enable ;

Ok, nice.  Thanks.


Updated Spark 3.3 dependency

Description of changes:
This commit updates the Spark 3.3 dependency of Deequ. There are some breaking changes to the Scala APIs, from a Py4J perspective. In order to work around that, we use the Spark version to switch between the updated API and the old API. This is not sustainable and will be revisited in a future PR, or via a different release mechanism. The issue is that we have multiple branches for multiple Spark versions in Deequ, but only one branch in PyDeequ.
The changes were verified by running the tests in Docker against Spark version 3.3. The docker file was also updated so that it copies over the pyproject.toml file and installs dependencies in a separate layer, before the code is copied. This allows for fast iteration of the code, without the need to install dependencies every time the docker image is built.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Nice - this seems to be a short term solution for https://github.com/awslabs/python-deequ/issues/169.
Also would this address the issue we run into for 3.4+ https://github.com/awslabs/python-deequ/pull/168?

@chenliu0831 #168 will likely not be fixed by this. I'll address the upgrade of Spark 3.4 and the associated changes in a separate PR.

@rdsharma26 got it - I think the title of the PR might be more accurate if it's about "Deequ 2.0.4" parity


The original memory not removed  if I load a new dicom file.

I uploaded a dicom file and then show the canvas. Then I need to upload another dicom file and show the new one. But the old one still existed in the memory. One dicom file is about 200MB. If I open up the third one, then the memory is 600MB.

I suggest to ask this question here: http://stackoverflow.com/questions/tagged/ami.js
It seems that you already have or someone else had the same question:
https://stackoverflow.com/questions/51149960/memory-keep-growing-if-i-load-a-new-dicom-file


Mark epoll_{,p}wait as blocking regions if they have a timeout

CC: @sreecha @ghemawat

LGTM

Cc: @murgatroid99


Use ESLint with a config base of eslint-airbnb-config-base

This replaces JSHint with the newer, more powerful ESLint. Some discussion has been had about this already at https://github.com/nodegit/nodegit/pull/1016#issuecomment-215585622.

So I think it'll be a good idea to start babeling the test/utils/lifecycleScripts folders as well while I'm in here. This is inspired by the fact that https://github.com/nodegit/nodegit/pull/1023/commits/db56d3686e127a1b9d604ec968007cb56ebfa361 fixes the linter but is actually not fully supported as the 0oXXX octal syntax is new to ES6. Rather than use some weird parseInt magic, We can just go ahead with babeling the test folder so we don't have to worry about what syntax is supported yet. My thoughts for the new babel structure (with the help of @implausible) are as follows:

All un-transpiled javascript will move into a js folder at the root which will now contain lib, lifecycleScripts, test and utils. The generate folder could also be a candidate, though that will probably be a bit more complicated.
The js folder will be transpiled to the parent directory, putting the output folders exactly where they used to be. These folders will now be .gitignoreed and the new folders will be .npmignoreed.

The biggest problem I see here is that any outstanding js changes that will go in immediately after this are going to be a merge conflict nightmare. We'll have to work this in quickly after we agree on something to minimize immediate conflicts.
Thoughts?

Why js/lib/ -> lib/ and not lib/ -> dist/ like we do now?

Oh, ok I'm following you guys now. That looks good to me.

@tbranyen what do you think?

Changing the folder structure will be a rebase nightmare as previously outlined.  I don't see a huge rush to bring this in immediately, but I'll try and review this weekend! Thanks for humoring me with this exercise, I know it's not the fastest thing to land, but it affects a lot.

This is definitely not time critical :)

Awesome! Yeah, the rebase nightmare for any pending PRs is definitely the biggest concern here. Thanks for checking it out!

Well, this is conflicting with like 100 files so @cbargren are you able to rebase this and clean it up?

At this point, the actual file changes probably need to be reworked. FYI passing --fix to eslint helps with a LOOOOOT of the trivial stuff

I'll have to take a look at it again when I have some time. Yeah, a lot of these changes will probably have to be completely reworked, but it's really only worth doing if we're committed to getting it in immediately when it's ready, since the longer it waits, the more rebase nightmares it's going to create.

Should we just lint files that changed?

https://www.npmjs.com/package/polyjuice


OIDC Login

Fixes #59
Description (what might a PO or reviewer want to know?)

Log in using the OIDC Login button on the login page
You can keep your current account if the email address matches

PR checklist

[x] dev-branch has been merged into local branch to resolve conflicts
[x] tests and linter have passed AFTER local merge
[x] localization is supported (Guide)
[ ] another dev reviewed and approved
[ ] if feature-Branch: Teams PO has approved (show via e.g. screenshots/screencapture/live demo)

Peek 2023-01-05 16-21.webm
@benn02

@rgwohlbold When deploying OIDC, we need to add OIDC client credentials in the corresponding ENV variables. See here. Can you take care of this?

@rgwohlbold When deploying OIDC, we need to add OIDC client credentials in the corresponding ENV variables. See here. Can you take care of this?

I created two OIDC clients and added you as an owner @dasGoogle. I added the config variables to both deployments, we should check after the merge that it is configured correctly.

@rgwohlbold When deploying OIDC, we need to add OIDC client credentials in the corresponding ENV variables. See here. Can you take care of this?

I created two OIDC clients and added you as an owner @dasGoogle. I added the config variables to both deployments, we should check after the merge that it is configured correctly.

Thanks!

@rgwohlbold When deploying OIDC, we need to add OIDC client credentials in the corresponding ENV variables. See here. Can you take care of this?

I created two OIDC clients and added you as an owner @dasGoogle. I added the config variables to both deployments, we should check after the merge that it is configured correctly.

It seems that the base URL you configured in APP_BASE_URL is http rather than https which makes the authentication fail. Could you maybe fix this in the deployments, @rgwohlbold?

should
Sorry, should bei fixed now


check for conflicting revision and resolve with the most recent version

closes #43

@freefony I took the liberty of writing a (failing) integration test. Please could you check the assertion and confirm whether my understand aligns with yours.
Also note I fixed a bug in the locations service whereby you need to use the injected version of the utils service (4886f2d). If you agree with that change, you'll also need to apply it to the other services.

@freefony I've added restart replication support to locations service and made sure the local rev is at 2-. However, so far it doesn't even look like the onChange handler is called.

@freefony I fixed the change handler invocation in 3053a8f. Note angular-pouchdb's API is slightly different here.

The test still fails on Error: undefined is not a constructor (evaluating 'this.serialiseDocWithConfl ictsByProp(changedDoc, 'updatedAt')')

That's fixed, but this is still not working as we'd expect as the _conflicts property is indeed a list of revs, not a list of docs. Note we're using PouchDB 5.4.x, not 6.x which the PouchDB docs are based on (might've been a source of confusion).

Ok. i ll do db.get on each doc then

OK, NB, you don't need to fetch all rev docs, you can use open_revs: [<rev>] | 'all' instead, e.g.:
if (doc._conflicts.length) {
  db.get(doc._id, { open_revs: doc._conflicts })
  //=> [{}, {}, …]
}

@freefony I'm going to have look at this intermittent test.

@freefony this lgtm now. Please have a run through a feel free to merge if it lgty 👍


Investigate the usefulness of an async pipeline

Parsec currently works in an "old style" way with only the Unix domain socket listener having some degree of non-blocking'ness. The emerging trend (displayed by tokio, for example) is to make asynchronous calls truly async.
This could be a change mainly in the IO area, in dealing with the frontend of the service and how we communicate over IPC channels, but it could also look at the provider interface.
The task here is just to investigate what the changes and tradeoffs would be.

I think the important point is that the Listen trait must be async. It's currently the case for us as we set the socket non-blocking.
Maybe having slow methods be async would be good? For example fetching the mappings?


Solution Planning - Mapping

Mapping is almost complete.  Pending a few answers from Amanda at TCCH.

8/25/21 - Received the 1st TCCH de-identified production file.  Mapping started.

9/3/21 - Mapping completed and reviewed with Herman.


Interface for diagram shapes and limits

James and I had a quick chat and discussed a potential interface for the CategoricalAlgebra.ShapeDiagrams where we have the base shapes of Span, Cospan, Product, Coproduct, Equalizer, and Coequalizer defined in a way where the interface allows you to build arbitrary shape diagrams out of those building blocks.  For example if you do the colimit(s::Span), you would get the cospan that solves the pushout defined by s. You could also do something like limit(cs::Cospan) give you the span that solves the pullback defined by cs. Futhermore you would be able to use the interface like dual(colimit(s::Span)) == limit(cs::Span) given that s and cs form a valid pushout.

Yeah, I see the benefits:

Limits the number of shape types we need to define to O(1)
Special types for common shapes like product, equalizer, pullback and their duals
Function interface is just limit/colimit and dual so you don't have to have functions for lots of shapes. This should satisfy the axiom dual(limit(dual(s)))=colimit(s)
We can introduce pushout(f::Morhpsim, g::Morphism) = colimit(Span(f,g)) as aliases for special cases, but code that needs to be generic across shapes can use limit/colimit, and know that it will always work
If someone defines a shape that has a faster algorithm for computing limit/colimit, they can create a type for that shape and then use dispatch to give that faster algorithm.

Thanks for starting this discussion. Some thoughts:

Agreed that we should not have a proliferation of shape types. We want Span and Cospan. Equalizers and coequalizers are (co)limits of the same shape: parallel arrows, which we could represent by a single type Parallel or ParallelHom. Products and coproducts are also (co)limits of the same shape, but I'm not sure that we need a dedicated type for them, beyond the builtin types in Julia.

Agreed that we want a generic compositional implementation, but also the possibility to special case certain cases if needed for performance.

Although limits and colimits are dual (colimits in C are limits in C^op and vice versa), the existence of one does not imply the existence of the other (unless C is self-dual), and it is generally not possible to transform one into the other.  So, I don't think that the suggested interface for dual will work.

In addition to having dedicated types, I think we can also have a GAT-based interface that does not use these types.

Yeah that makes sense. For the GAT based interface are you thinking of a GAT like Shapes as a presentation of an AdhesiveCategory which has limits and colimits of shape diagrams and then the  Instances are the Subtypes of ShapeDiagrams.AbstractShape along with ShapeDiagrams.ShapeMorphisms?

When I wrote that, I wasn't sure. Later I wrote down some GATs in this branch. I think that a non-GAT-based interface will be more flexible and so generally preferable here, but it doesn't hurt to have the GATs too.

Hello all, I'm a new contributor, and I just got off the phone with James. He assigned me to work on this, so I'm going to take a stab. If someone else is in the middle of an implementation, please ping me so I don't step on any toes!

Yeah I think having the interface of taking a MetaDiGraph whose edges are labeled with FinOrd Morphisms and supporting limit(g::MetaDiGraph), colimit(g::MetaDiGraph) is a good way to achieve this. Then the return values would be n::Int, f::Vector{FinOrdFunction} where f[i]: vertices(g)[i] --> n you probably need to check that g is a DAG and that all the squares in g are labeled with morphisms commute before you go to compute the (co)limit.

Can you explain to me why we are restricting this to FinOrd? Is it because we are just doing proof of concept in FinOrd, or is FinOrd actually completely general and I'm not seeing it. Also, why do squares have to commute before i compute the colimit? If I'm taking the equalizer, then the diagram is not going to commute.

Oh, I'm looking at FinOrd right now and I see why; FinOrd is not the category with finite ordered sets as objects and order preserving maps as morphisms, it is the category with finite ordered sets as objects and anything as morphisms.

Yeah, this should actually work for all categories


Minor Setup Problem

Problem
I got a "Whoops, looks like something went wrong." error at the end of both graphical and command line setup but everything seems to set up normally.
Technical Details

Pagekit version: 0.11.3
Webserver: Apache/2.4.7 (Ubuntu)
Database: sqlite 3.8.2
PHP Version: 5.5.9-1ubuntu4.14

Troubleshooting

[X] I have enabled debug mode: https://pagekit.com/docs/troubleshooting/debug-mode
[X] I have verified the server requirements: https://pagekit.com/docs/getting-started/requirements
[X] I have tried disabling all installed extensions
[X] I have checked the browser developer console for JavaScript errors

Do you have other extensions than Blog and Theme-One located inside your packages folder?
For debugging it would be helpful if you could install Pagekit again from a fresh extracted zip archive with debug mode turned on (debug => true in app/installer/config.php) and past the contents of the last request made during installation.

WEB SETUP
Request:
{"config":{"database":{"default":"sqlite","connections":{"sqlite":{"prefix":"pk_"}}}},"option":{"system":{"admin":{"locale":"en_US"},"site":{"locale":"en_US"}},"system/site":{"title":"TEST"}},"user":{"username":"admin","password":"password","email":"ecmel@example.com"},"locale":"en_US"}
Response:
{"status":"success","message":""}

This one is difficult to reproduce. Is it possible for you to use a PHP debugger and find the exact position there the error occurs?

Please reopen if the issue still persists.


Message Archive

Hi
I can see that Kaiwa implements MAM which  will sync data from server. We are exploring storing data in localstorage so as to allow offline message read. We found an api  which does stringify and parsing very fast - http://rhaboo.org/
We can implement it but it will be great if you can share feedback.

App already using localstorage, what is the problem?


Issue with the compiler-wrapper and Clang

I am getting a core dump when trying to run Clang trunk. Other versions of Clang seem to be working.
https://godbolt.org/g/TRnJ9V
/compiler-explorer/c-preload/compiler-wrapper: line 21: 26388 Segmentation fault      (core dumped) "$@"
Compiler returned: 139

Investigating right now, thanks.

Something in llvm has changed and it doesn't like being upx packed any more. This affected both rust trunk and clang trunk.
I'm hastily rebuilding clang compilers without upx-ing them.

Building is taking an extraordinarily long time...well, it's stuck at Installing... - hopefully it'll finish up soon...

It was the xz to tar up the clangs that was taking so long... the .tar.xz is now 394 GB (!!!)

Slight improvement, now a glibc version issue. Continuing to work on this...

glibc woes fixed. Testing and works in beta, now restarting prod, ETA 10 minutes or so.
Thanks all for your patience...

And it should be fixed!

 Verified that it's working again for me as well.


(fix) Fixes the test MEXC test cases that attempt to contact the server.

Before submitting this PR, please make sure:

[X] Your code builds clean without any errors or warnings
[X] You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:
This PR simply fixes the REST mocking performed in the MEXC test cases. Nothing else has been changed in the tests themselves.
Tests performed by the developer:
I've monitored the network traffic of a test-case run with Little Snitch and nothing was detected where there used to be multiple connection attempts previously.
Tips for QA testing:
N/A

Closing because of initial open towards wrong repo


fix(material/card): use more specific selector for divider override

Fixes that the card targets all dividers which may include ones placed inside child components.
Fixes #23524.

Caretaker note: this has a chance of screenshot failures if people didn't compose their card correctly.

I am the one that created the original issue, I want to point out one concern i had.
The fix above might break this case

because the divider is not a direct child of the mat-card, it is actually a child of the mat-list.
So i dont know if there needs to be an or so we dont break some people existing layouts.

I think that in that case the list should be the one responsible for the divider position.

Please merge this! Nice fix 👍


[dist] Distribute test/helpers.js

So it can be used by other winston transports.

This bit me yesterday too. Will go out later today.


Added jsdoc comments.

Thanks for the feedback, have implemented suggested changes.
As an aside, I wonder if you can get the linter to also check jsdoc example sections?

As an aside, I wonder if you can get the linter to also check jsdoc example sections?

I would love to, but so far I haven't found anything.


Fix timeout for multi tab

https://github.com/WideChat/Rocket.Chat/issues/931

@Shailesh351 I'll also test this....  but can you review this PR please when you have a moment......  we're about to deploy new version to production....  maybe we can get this one in as well.  Thanks.

@ear-dev Will test 👍 Thanks


Added RemixIcon issue:#197

added RemixIcon tool
fix issue : #197

@ydv-ankit   you have deleted some data and the JSON data you added is not correct."


you-get: 0.4.1500 -> 0.4.1536

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for you-get is: "A tiny command line utility to download media contents from the web"
meta.homepage for you-get is: "https://you-get.org"
meta.changelog for you-get is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/n7w44m1n3m51wg124pibxywp5k6chkl8-you-get-0.4.1536/bin/you-get passed the binary check.

/nix/store/n7w44m1n3m51wg124pibxywp5k6chkl8-you-get-0.4.1536/bin/.you-get-wrapped passed the binary check.

2 of 2 passed binary check by having a zero exit code.

2 of 2 passed binary check by having the new version present in output.

found 0.4.1536 with grep in /nix/store/n7w44m1n3m51wg124pibxywp5k6chkl8-you-get-0.4.1536

found 0.4.1536 in filename of file in /nix/store/n7w44m1n3m51wg124pibxywp5k6chkl8-you-get-0.4.1536

directory tree listing: https://gist.github.com/1c2418fbe3f4c9c9ff6791c8f350de2c

du listing: https://gist.github.com/04974410d25656615831f38d0dcfdedb

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
you-get

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/n7w44m1n3m51wg124pibxywp5k6chkl8-you-get-0.4.1536 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A you-get https://github.com/r-ryantm/nixpkgs/archive/e8022e23670a4eae012a41b94c4f0c18eb392998.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/n7w44m1n3m51wg124pibxywp5k6chkl8-you-get-0.4.1536
ls -la /nix/store/n7w44m1n3m51wg124pibxywp5k6chkl8-you-get-0.4.1536/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

you-get

Maintainer pings
cc @ryneeverett for testing.

Result of nixpkgs-review pr 133883 run on x86_64-linux 1

1 package built:

you-get


[BUG] anaconda3/lib/python3.8/uuid.py", line 180, raise ValueError('bytes is not a 16-char string')

Code:
from mars.session import new_session
new_session().as_default()
Get error:
anaconda3/lib/python3.8/uuid.py", line 180, in init
raise ValueError('bytes is not a 16-char string')
ValueError: bytes is not a 16-char string
Error under Linux version 3.10.0-957.10.1.el7.x86_64.

Could you provide the full traceback details?

Traceback (most recent call last):
File "/mnt/nfs/yijing.zhou/venv_38/lib/python3.8/site-packages/mars/services/cluster/uploader.py", line 114, in upload_node_info
self._info.env = await asyncio.to_thread(gather_node_env)
File "/mnt/nfs/yijing.zhou/venv_38/lib/python3.8/site-packages/mars/lib/aio/_threads.py", line 36, in to_thread
return await loop.run_in_executor(None, func_call)
File "/mnt/nfs/zhihui/anaconda3/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/mnt/nfs/yijing.zhou/venv_38/lib/python3.8/site-packages/mars/services/cluster/gather.py", line 73, in gather_node_env
cuda_info = mars_resource.cuda_info()
File "/mnt/nfs/yijing.zhou/venv_38/lib/python3.8/site-packages/mars/resource.py", line 352, in cuda_info
products=[nvutils.get_device_info(idx).name for idx in range(gpu_count)],
File "/mnt/nfs/yijing.zhou/venv_38/lib/python3.8/site-packages/mars/resource.py", line 352, in
products=[nvutils.get_device_info(idx).name for idx in range(gpu_count)],
File "/mnt/nfs/yijing.zhou/venv_38/lib/python3.8/site-packages/mars/lib/nvutils.py", line 343, in get_device_info
uuid=uuid.UUID(bytes=uuid_t.bytes),
File "/mnt/nfs/zhihui/anaconda3/lib/python3.8/uuid.py", line 180, in init
raise ValueError('bytes is not a 16-char string')
ValueError: bytes is not a 16-char string
Failed to upload node info: bytes is not a 16-char string

Which Mars version did you use?

0.9.0a1

Can you try the latest version?

yes, actually the older version 0.6.1 was used, but have to upgrade to the newer version and encountered such errors...

Latest version v0.10.0 may address your issue, could you try it please?

I just tried, the latest version v0.10.0 doesn't work as well.

Looks like sth went wrong when getting info from cuda device, can you give more info about your cuda setting?

CUDA Version 9.0.176
CUDA Patch Version <IP_ADDRESS>
CUDA Patch Version <IP_ADDRESS>
CUDA Patch Version <IP_ADDRESS>
CUDA Patch Version <IP_ADDRESS>

I try to run the function on my computer with 2 GPU cards, but no error occurs.
>>> from mars.lib.nvutils import get_device_info
>>> get_device_info(0)
_cu_device_info(index=0, uuid=UUID('096adb53-fc18-1075-1097-5792e93051b7'), name='NVIDIA Graphics Device', multiprocessors=84, cuda_cores=16128, threads=129024)

Could you try this one?

from mars.lib.nvutils import get_device_info
get_device_info(0)
Traceback (most recent call last):
File "", line 1, in
File "//pkgs/mars-0.10.0/mars/lib/nvutils.py", line 343, in get_device_info
uuid=uuid.UUID(bytes=uuid_t.bytes),
File "/*/anaconda3/lib/python3.8/uuid.py", line 180, in init
raise ValueError('bytes is not a 16-char string')
ValueError: bytes is not a 16-char string


make use of has_virt()

I will also try to fix as many formatting issues in mill.py as possible

Please rebase 😉


Expose signals and callbacks as C# events

Godot version:
master / 2ac27608a6892d8d7e28d8afbbcc98505eb3e4b3
OS/device including version:
Manjaro Linux 17.1-rc2
Issue description: (This issue is a feature request)
Currently, in order to receive various callback events, like when a node is added to the tree or receives an input, one needs to override relevant methods (i.e. _EnterTree()).
However, in case of C# projects, some might prefer accessing them as events since it's more of an idiomatic way to implement an observer pattern. And the same can be said of signals like Button.pressed, for example.
Maybe we can add additional events along with existing callback methods and signals to provide an alternative method for those who prefer a more idiomatic approach. Or, we might let users to choose whether to enable such a feature by using a conditional compilation symbol.

@neikeq Isn't this done by now?

No, this is not done yet. I would really like it to happen, but there are still some problems to settle first.
Supposing we don't change the way signals and connections work
The situation would be like this. We have the following "signal" event:
delegate void NameChangedDelegate(string name);

[Signal]
event NameChangedDelegate NameChanged;

Raising this event should not only call its delegates, but also EmitSignal with the event name. This is so that the engine can also subscribe to events from this signal.
For this to happen, the engine would have to add a special delegate to the event after constructing the object. This raises a few problems like what if the user clears all delegates or sets the event to null.
We likely also want EmitSignal to raise the signal event, this way it can work like any other signal. This introduces the biggest. First the delegates will get called twice, and second:

raise event -> EmitSignal
EmitSignal -> raise event
raise event -> Emit Signal
...
Stack overflow at some point

This can probably be fixed by making EmitSignal aware it's being called from a raised signal event, so that it doesn't raise the signal event again.
We also want get_signal_connection_list to include the delegates added to the event.
The other option is to extend the way signals and connections.
Connecting a signal from the engine would actually add a delegate to the event. I think it would fix all the problems about without introducing new ones (except the get_signal_connection_list problem, for delegates added from C# with += instead of Connect), but I haven't thought much about this yet.

One thing we can definitely do in the meantime is add an overload of Connect that replaces the target object and method name with a delegate.

This seems to be now implemented judging from this progress report. Can you confirm this, @neikeq?

Yes, this is implemented for signals in 6a85cdf640d735b1ca8216b4c6e16fb949f4d183.
This is not going to happen for callbacks, as they don't necessarily to translate to events. In any case, I suggest requesting callbacks to be replaced (or complemented) with signals where it makes sense. The _EnterTree callback for example already has the equivalent TreeEntered signal as an event.
Note: The problem I described in my first comment was not resolved yet. Right now we still need EmitSignal calls.

Hey! Would be cool to have some option to pass Functions as parameters into argumetns of the Signals. For now it is Marshaling error

awesome. Is there any documentation on how to implement this? the official docs still show the SignalAttribute + delegate method.

@dimi3tron It's just an event with the Signal attribute, e.g.:
[Signal]
event Action Pressed;

Currently you need to use EmitSignal instead of raising/invoking the event, otherwise connections made via Connect won't be called. That may be solved in the future.
Keep in mind this is only available in 4.0 which is not released yet.

Thx. For some reason I was under the impression it was already in the current build. Great to see these kinds of improvements, really makes Godot feel more like home for long time c# developers like myself.
Excited for 4.0!


An ability to select multiple files using one key combination

Hey there,
I tried selecting multiple items from the file embed selector in the UI, but have not been able to do so. Usually, I would expect that something like clicking the first checkbox while holding shift and clicking the last desired checkbox would do the job, but since the UI is not using regular checkboxes, that doesn't work. When working with many documents, this is really important, esp. since PDFs are split page-by-page.
Thank you

Agree.
I think, that in the first place it would help, if all files get activated by default within in the workspace you uploaded them.
Now I am in a workspace and click "upload". After that I have to select those file in the workspace I am in all the time.

Closed in redesign, can select multiple files now!


Added new icon assets

I figured I'd add all the necessary assets based on the new logo so we could test them in a build. I'm back in a place where I'm not able to build the package at the moment to see how it looks in its various different places.
This pertains to issue #55.

:tada:


Proposal - Fictional type support

Abstract
I propose entt provides support for fictional types inside entt::registry, based on a discussion that was held a few weeks ago on discord.
Fictional types?
Also known as 'runtime' types, or 'virtual' types. They are types that have no C++ equivalent, they might exist as part of a different scripting language, or they might be loaded as an asset from a file.
Motivation
Currently, entt::registry can only store types that have a C++ equivalent. This makes it difficult to implement scripting support if your type has no C++ equivalent. This proposal offers a solution to improve scripting support in entt::registry.
There are runtime reflection systems that support fictional types. The data-layout of a fictional type is stored as an asset on file. This type can work very similarly to a C++ type, by mallocing the total size and accessing the fields based type and offset.
For example the default constructor could look like this:
// Iterate over fields of toType and default construct them based on their offset
for (const MetaField& field : fictionalType)
{
        const MetaType& memberType = field.GetType();

const uintptr memberOffset = field.GetOffset();
    void* memberAddress = reinterpret_cast<void*>(addrAsInt + memberOffset);
memberType.ConstructAt(memberAddress);
  }

You have a type that you can feed to your script interpreter, the size of this type is known at runtime, and there are functions available to construct, copy, move and destruct it. The only problem? You can't place it in an entt::registry.
Solution
The idea is to use the abstract interfaces currently in place, and create implementations that can work with full type erasure. There are abstract baseclasses such as entt::sparse_set, and derived classes that override the functions that require the full type, such as entt::storage. The storage knows how to construct, copy, move, and destruct the type. To support fictional types, you need to add another derived class, such as entt::fictional_storage that has the required function pointers for constructing, copying, moving and destructing. This is exactly what we did in Coral Engine
One way to add this functionality to entt is by exposing an overload for the add_fictional_storage function that requires the user to provide callbacks for constructing, copying, moving and destructing their type.
template<typename UserDataT>
entt::sparse_set* storage(
        id_type type_hash,
        std::string fictional_name,
        uint32 type_size,
        UserDataT&& user_data
        void(*default_constructor)(const UserDataT&, void* address),
        void(*move_constructor)(const UserDataT&, void* address, void* original),
        void(*move_assign)(const UserDataT&, void* src_address, void* dst_address),
        void(*destructor)(const UserDataT&, void* address, void* original));

UserData would contain the necessary type information, for example a runtime reflection representation of their fictional type. The userdata would be stored inside the storage, and passed along to the callbacks. This way it only needs to be stored once. I'd love to get feedback on the API for this function.
Entt could then be integrated with runtime reflection systems that support fictional types.
void construct(const Type& type, void* address) { type.ConstructAt(address); }
void move_construct(const Type& type, void* address, void* original) { type.MoveConstructAt(address, original); }
void move_assign(const Type& type, void* address, void* original) { type.MoveAssign(address, original); }
void destruct(const Type& type, void* address) { type.DestructAt(address); }

void load_script(std::string_view filename)
{
  Type type = load_type_from_file(filename);

  reg.add_fictional(type.get_hash(), type.get_name(), type.get_size_in_bytes(), type, &construct, &move_construct, &move_assign, &destruct);
}

What about entt::meta?
In the future I'd like to add support to entt::meta for fictional types as well, but the scope of that change is significantly larger. Better to start small!
Impact
The API would not grow significantly; only two more functions would be added. Internally, there would be another class added that derives from entt::sparse_set with similar functionality as is currently in entt::storage. Most of the 'common' functionality between storages has been moved to the baseclass entt::sparse_set, keeping code repetition at a minimum.
Having to register the types beforehand conflicts with entt's current design of not having to 'announce' component types beforehand. I don't see a way around it in this scenario, and seeing as this functionality is completely opt-in, for a relatively specific usecase, I think it's perfectly acceptable. The user can also use wrapper functions to recreate the 'lazy' initialization.
Implementation experience
I have implemented this exact proposal before for Coral Engine. I had modified entt::registry to expose a function that allowed me to add my custom storage class to the map of pools, and I had ofcourse implemented a custom storage class.
Conclusion
This relatively small change opens up a lot of possibilities, it is fully opt-in and proved incredibly helpful during the development of Coral Engine. It opens up future possibilities of expanding entt::meta for better scripting support. I'd love to hear your thoughts on this proposal, including anything I've missed and anything I could change to be more consistent with entt's design

I realized a few days after opening this issue that there is a 'simpler' solution.
You can use whichever type you use as an 'any', e.g., entt::any or std::any. If your runtime reflection library supports fictional types, entt::registry already supports fictional types!
for (const Script& script : GetAllAssets<Script>())
{
  MetaType type = ReflectTypeFromScript(script );
  registry.storage<MetaAny>(type.Hash());
}

With this approach each individual MetaAny stored inside the storage 'own' an instance of a fictional type that is stored on the heap. While my proposal would be a big optimization as you would have a lot fewer heap allocations, I personally don't consider the tradeoff of increasing entt's size worth it if there is an existing, simpler solution.
Instead. I will propose to add support for fictional types to entt::meta, I don't have much time today, but tomorrow I'll look into it and write a proposal for adding fictional type support to entt::meta. I'll either re-open this issue or open another one.

I've been looking at the fictional type for meta. I think a factory for the void type might be the right fit for that. It needs some fixes, but I'm more than willing to give it a try. Any other ideas in the meantime?

Hi! My apologies for the delay, I started working on the implementation and got side-tracked by life :)
I agree with the idea for using a void type, made a specialization for the factory for entt::fictional_t. I'm picturing the API to look something like this:
    entt::meta<entt::fictional_t>("myScript")
        .data<int>("Health"_hs)
        .data(entt::resolve<float>(), "Speed"_hs)
        .data(+[](entt::any member, const entt::data_context& context)
            {
                script_interpreter(context.data.prop("getter"_hs));
            })
        // Argument count and types can be deduced
        .func("PartiallyDynamicFunc", +[](int num, float otherNum, const entt::func_context& context)
            {
                return context.func.prop("script"_hs).value().cast<script>().invoke(num, otherNum);
            })
        // When we want to support fictional types as arguments, how do we specify that?
        // We could have a low-level way of registering functions?
        .func("MyDynamicFunc",
            3, // arity
            +[](std::size_t argNum, const entt::func_context& context) -> entt::meta_type // argument getter
            {
                return context.func.prop("script"_hs).value().cast<script>().arg(argNum);
            },
            +[](const entt::func_context& context) -> entt::meta_type // Return type getter
            {
                return context.func.prop("script"_hs).value().cast<script>().ret();
            }
            +[](entt::meta_handle instance, entt::meta_any* const args, const entt::func_context& context) -> entt::meta_any // Invoker
            {
                return context.func.prop("script"_hs).value().cast<script>().invoke(std::move(instance), args);
            })

The type 'alias' needs to be provided to the constructor, as the meta_type internally needs to be constructed with a unique type_id right of the bat. One potential problem related to the type_info is that type_info is usually stored as a pointer, and in it there is a type_alias that is a non-owning string_view. This data does need to be stored somewhere, but I'm not sure what the best place for this is. Maybe the type_info in meta_type_node could be stored by value, and the user themselves is responsible for managing the lifetime of their string? Not very good practice, but it is more in line with entt's pay-for-what-you-use vision. The type_info could also be stored as a property in the type_descriptor, this would come at no cost to users who do not use fictional types, but it's also unintuitive for the user if there are properties present they didn't register... Something to think about!
The .data function is pretty straight-forward, but internally I'm not sure yet how it will work. We could keep track of the current size of the type. If the user registers an 'int' we increment the size by sizeof(int) (or more if needed for alignment), and add a setter/getter pair for an integer at the offset of old-size of the type. Maybe we should also support a .padding function, that just increments the size? That way you can manually adjust the layout of the type if need be.
The user can also register custom functions, in order to avoid capturing any arguments there'd be an option to use entt::data_context or entt::func_context as a last argument.
One idea that I've been thinking about for a while is how to handle constructors. For Coral Engine we had a default constructor that would allocate enough size to construct all the data members, and then default construct the data members in place. This constructor would be registered after all the data members, since if some data members could not be default-constructed, you cannot have an implicitly generated default constructor. I think the same idea would work for entt::meta_factory; the user has to explicitly add default/copy/move constructors and a destructor.
        .ctor<>()
        .ctor( // Custom copy constructor
            1, // arity
            +[](std::size_t argNum, const entt::func_context& context) -> entt::meta_type // argument getter
            {
                return context.outer.type;
            },
            +[](entt::meta_handle instance, entt::meta_any* const args, const entt::func_context& context)
            {
                entt::fictional::copy_copyable_members(instance, args[0]);

                // Do some custom logic here
            })
        .dtor();

What do you think?

Sorry for the late reply. I decided to close a few things on the meta side so that I can work on this one now without unwanted stuff all around. 🙂
So, my first question is: why entt::fictional_t? I mean, why not entt::meta<void>? If we don't want a C++ type there, void looks much better and captures the intent.
Does it make sense? I think it's also easier to do like this. A bunch of std::is_void_v<Type> should get the job done for the large part.

No worries!
I don't feel too strongly when choosing between void or entt::fictional_t
I have a slight preference for entt::fictional. Using void is a bit less clear, as the same keyword then means different things in different contexts.; void is used frequently as part of a function signatures and void pointers, while entt::fictional_t would only be used for fictional types. It's also a bit easier to document by adding a comment above the struct, and easier to google. But again I don't feel strongly about the matter, entt::meta<void> is shorter, and void represents something 'typeless', and that's exactly what we're going for here.
I think it mostly comes down to preference and what is more in line with entt's design, for which I'll trust your expertise 🙂

I think the point is that the factory argument is also the meta function or meta data argument in general.
That is, the element on which data members are looked up and the this of the functions. Even when you bind a free function, the factory type is the first element in the list of arguments (if you like ofc).
Therefore, using an entt::whatever makes me feel like I can attach a void f(entt::whatever &ref, other_args...) function to it. However, this isn't the case. In this regard, I think void captures better what's going to happen. There is no type, that's it. 🤷♂
That said, yesterday I tried to implement it and figured out that some functions don't make much sense with this factory.
For example, conv is pointless as well as ctor or dtor because we're typeless here. At the end of the day, in this kind of scenario I see a purpose only for data and func. Does it make sense to you?

Ahh that's a very good point, void definitely works better than.
I'm not sure what you mean with ctor and dtor being pointless, could you elaborate? I don't think conv is very useful,  but I think having custom constructors & destructors are needed for hooking up entt::meta to whichever scripting tool you're using.
It'd for example be really useful to be able to specify the default value of data members, especially since not all data members are default constructible. The user could provide a callback using ``ctoranddtor, the callbacks take either an void*``` (or some form of meta_handle), and the user could use the data members offset to construct them in place with whatever value they like.
But more importantly, some scripting frameworks don't have a sequential C-like layout for the scripting types; they have different 'wrappers' around instances of the script types, such as sol::table for Lua. Instead of the user constructing the data members in the ctor/dtor, the user could construct/destruct a sol::table at the provided address.
I'm going away for a week today so it might take some time for me to respond, but let me know what you think or if I missed something

Looking into this one. To start with, I think we need to change the way the context works, because it stores meta types in a map where the index is the type id. This makes it impossible to construct multiple meta types for the same C++ type, even with void. 🤔


migrate some of eliteDangerous.js?

not sure if any of the modules related to ED are even enabled anymore

Only enabled things are !elite and channel description upates


[Bug]: Order issues with Leads

Steps to reproduce the bug
Continuing the discussion from https://github.com/SpeciesFileGroup/taxonworks/commit/22a5a6c78216996f03647f6a61cb3c2fe4171071, I'll add more below. This is with the latest adjustments.

Screenshot
No response
Expected behavior
No response
Additional Screenshots
No response
Environment
Development (docker)
Sandbox Used
No response
Version
5cff93d3929c16f2934db34d7e0
Browser Used
No response

It looks like there are still ordering issues with leads with the latest changes. STR for insert_couplet:

Create a new couplet (on left or right side doesn't matter) and save some distinguishing text for left and right. Note in the database that the left has position=1 and the right has position=2.
Go up a couplet and insert a new couplet for the couplet from step 1. Now note in the database that position for both nodes created in step 1 is equal to 1, and position of both nodes created during the insert is equal to 2. Sometimes (but not always?) the newly inserted node that carries the old children appears on the wrong side of the ui (it should appear on whatever side the insert occurred on).
Since position no longer distinguishes which lead of those pairs comes first, updates can now cause the ui/display order of those pairs to change. So, e.g. edit the left lead that you created in step 1 and click Update - now the "left" lead is on the right and the "right" is on the left in the ui. (It looks like the ui order switches only when you edit/update the left lead, presumably because since position no longer determines order now last_updated does, or something like that?) The same switching happens if you edit the inserted pair in the same way.

In my testing so far, the Delete both sides and reparent... button seems to be working fine.

I'm all for getting this to work without using numeric_order: true so we don't have issues with db:create, but just to clarify, when we were using has_closure_tree order: 'position', numeric_order: true, dont_order_roots: true and has_closure_tree was computing positions for us, positions were only ever computed on child pairs (root nodes didn't have a position set as I recall, at any rate it definitely didn't increase or change with the number of trees in the table) and the child pairs all had position values of 0 or 1, so to my mind it acted as though position was scoped to parent_id, as it is now with acts_as_list.

I probably won't have time to look at this tomorrow, but if nobody gets to it earlier I should be able to try some things this weekend.
I'll note that yesterday and in the past I've been unable to reproduce some of these issues in specs. And I'm not sure, but the specs may be passing now by chance: we do check that children[0] and children[1] are what we expect after insert_couplet (i.e. that left and right are the correct nodes), but it may be working just by chance that children[1] was last updated after children[0] or something like that, so more adjustments can be made there to try to draw that out.

@kleintom I'd like to poke at this.  Did the PR resolve this in your mind?

Yeah, I'm not a great fan of my initial reload-everything-and-set-positions-explicitly solution, but I think it does resolve the issue, and the last comment in the pr cleared up at least some of the confusion that had been in my mind concerning why things hadn't been working the way I had expected. I'd be grateful for more clarity though :-)

I've been poking at this code for a while just now.  Hope to get some comments shortly, but it's confusing me too.

@kleintom I don't have full satisfaction yet.  Pushed a new branch lead_debug.  Feel free to poke at it, I'll get back to it too.  If you flop the destroy/kids change I made back to what you had then you'll see 2 errors failing.  As is there are a number related to destroy.

@kleintom Spent (too much) more time on this.  I've merged some new code into development that resolves this and does a little more, see a644a205cb4261f71b9, however I feel I largely replicate your work and was infected with the same lack of full satisfication and clarity.  You'll see I reload, and actually re-save, the latter because I gave up.  I'm curious as to whether Rails 7 won't resolve some of this.
A couple of observations:

I saw differences b/w update(parent: obj) and (parent_id: obj.id), I don't think this is the root problem (consistent use throughout does not solve the issue in my testing, in fact it's the opposite).
When in mx I stacked a lot of expect() in one specify.  I've learned this is isn't the best pattern to follow, in fact ideally we'd have 1 expectation per specify.  This is a performance hit, but when specs have many complicated inter-relationships this can help tease out specific problems.  I'd encourage you (and us all) to ignore my mx patterns and make specs very lean/flat
I wrote Lead.draw to help visualize, this actually caught one reload requirement.  It might help you out in the future.
I'm wondering if there are conflicting callbacks in acts_as_list and closure_tree.

Once again, thanks again for the work, logically really solid, etc. etc. I'm treating this as code-review of sorts and I'm very happy with how you layed it out.  The spec work let me iterate much much faster had reviewed with out.

And a followup - I updated one controller method, but have not re-tested the UI.

Closing this as complete, for now.  Further introspection welcome.


Alert_trigger_bug_#78

*Issue #78
Description of changes:
To address this issue, i changed the logic in the runQueryLevelTrigger()  method so that it can  only return a trigger as "triggered" if it meets the specified condition and no previous triggers have already been triggered.
CheckList:
[X ] Commits are signed per the DCO using --signoff
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@dankyalo599 Want to finish this?
[Catch All Triage - 1, 2, 3]