RDMA failures on multicore/SMP builds

Original issue: https://charm.cs.illinois.edu/redmine/issues/1561

multicore builds for linux, darwin, and win all failed in tests/ampi/megampi/ with +p2 +vp2

Original date: 2017-05-15 23:28:37

One potential source of this issue is the RDMA stuff that was recently merged in AMPI. You can build AMPI with '-DAMPI_RDMA_IMPL=0' to test that.

Original date: 2017-05-16 15:15:40

On Darwin, compiling with -DAMPI_RDMA_IMPL=0 does not fix the crash. (Full build command: ./build AMPI multicore-darwin-x86_64   -j8  --with-production -g -DAMPI_RDMA_IMPL=0). Any parallel execution of Cjacobi3d crashes with a segfault at the end of startup (e.g., ./jacobi 1 2 1 +p2).

Original date: 2017-05-16 15:19:49

GDB output:
Starting program: /Users/mdiener/Work/charmrdma.off/examples/ampi/Cjacobi3D/jacobi 1 2 1 40 +p2
[New Thread 0x1403 of process 39896]
warning: unhandled dyld version (15)
Charm++: standalone mode (not using charmrun)
Charm++> Running in Multicore mode:  2 threads
Converse/Charm++ Commit ID: v6.8.0-beta1-156-gfff8f258e
CharmLB> Load balancer assumes all CPUs are same.
Charm++> Running on 1 unique compute nodes (8-way SMP).
Charm++> cpu topology info is gathered in 0.000 seconds.
[New Thread 0x1207 of process 39896]

Thread 3 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x1207 of process 39896]
0x00007fffccf4bec9 in ?? ()
(gdb) bt
#0  0x00007fffccf4bec9 in ?? ()
#1  0x000070000db17ab0 in ?? ()
#2  0x000000010009308f in serializeContig (userdata=<optimized out>, buffer=0x1007072e8 "",
    size=<optimized out>, dir=<optimized out>) at ddt.C:17
#3  CkDDT_DataType::serialize (this=0x100702a60, userdata=0x1040c8768 "", buffer=0x1007072e8 "",
    num=80000, dir=-1) at ddt.C:549
Backtrace stopped: frame did not save the PC
(gdb)

Original date: 2017-05-16 15:25:07

Weird, but megampi may be simpler to debug and is the first issue here.
That stack trace is the same one we saw before the following was merged, are you using current charm master? ~~https://charm.cs.illinois.edu/gerrit/#/c/2520/~~ https://github.com/UIUC-PPL/charm/commit/ce06655175706886a8945ba137cdce7c20957973

Original date: 2017-05-16 15:28:39

Full stack frame just before the crash (this is with RDMA off, supposedly):
#0  CkDDT_DataType::serialize (this=0x100610810, userdata=0x1051cc768 "",
    buffer=0x20204a920 <error: Cannot access memory at address 0x20204a920>, num=10000, dir=-1)
    at ddt.C:549
#1  0x00000001000593c0 in ampi::processRdmaMsg (this=<optimized out>, sbuf=0x20204a920,
    slength=<optimized out>, ssendReq=0, srank=<optimized out>, rbuf=<optimized out>, rcount=10000,
    rtype=<optimized out>, comm=<optimized out>) at ampi.C:2863
#2  0x0000000100059213 in IReq::receiveRdma (this=0x100615290, ptr=0x8, sbuf=0x1051cc768 "",
    slength=80000, ssendReq=10000, srcRank=-1, scomm=9000000) at ampi.C:5420
#3  0x000000010004c876 in ampi::genericRdma (this=0x100614b90, buf=<optimized out>, size=80000, seq=0,
    tag=<optimized out>, srcRank=<optimized out>, destcomm=<optimized out>, ssendReq=<optimized out>)
    at ampi.C:2555
#4  0x000000010007623a in CkIndex_ampi::_call_genericRdma_marshall8 (impl_msg=<optimized out>,
    impl_obj_void=0x100614b90) at ./ampi.def.h:3285
#5  0x00000001000a49b7 in CkDeliverMessageFree (epIdx=<optimized out>, msg=0x101025460, obj=0x1051cc768)
    at ck.C:593
#6  0x00000001000b785f in CkLocRec::invokeEntry (this=0x10060f8d0, obj=0x100614b90, msg=0x101025460,
    epIdx=146,
    doFree=<error reading variable: access outside bounds of object referenced via synthetic pointer>)
    at cklocation.C:2026
#7  0x00000001000babba in CkLocMgr::deliverMsg (this=0x10060ebd0, msg=0x13880, mgr=...,
    id=<optimized out>, idx=<optimized out>, type=<optimized out>, opts=<optimized out>)
    at cklocation.C:2711
#8  0x00000001000a6033 in CkArray::deliver (m=<optimized out>, type=CkDeliver_inline,
    this=<optimized out>) at ./ckarray.h:493
#9  _processArrayEltMsg (ck=<optimized out>, env=<optimized out>) at ck.C:1168
#10 _processHandler (converseMsg=<optimized out>, ck=<optimized out>) at ck.C:1263
#11 0x00000001001a5225 in CmiHandleMessage (msg=<optimized out>) at convcore.c:1672
#12 CsdScheduleForever () at convcore.c:1909
#13 0x00000001001a4f35 in CsdScheduler (maxmsgs=8) at convcore.c:1845
#14 0x000000010019fc64 in ConverseRunPE (everReturn=0) at ./machine-common-core.c:1297
#15 0x00000001001a30f6 in call_startfn (vindex=0x1) at ./machine-smp.c:408
#16 0x00007fffccf5293b in ?? ()
#17 0x0000000000000d00 in ?? ()
#18 0x00007000014c2000 in ?? ()
#19 0x00007000014c1f50 in ?? ()
#20 0x00007fffccf52887 in ?? ()
#21 0x0000000000000000 in ?? ()

As RDMA is apparently still in use, could you check if my build command above is correct?
I'm using current charm master.

Original date: 2017-05-16 15:34:03

We still use the RDMA path for sends that are local (the sender and the recver are on the same PE), so that's one possible explanation, but based on the full stack trace it looks like that is really an RDMA entry method invocation. Your build command looks good, so I'm not sure why that would be happening?
Also, I would build with -g -O0 and not production to see if it reproduces there...

Original date: 2017-05-16 15:47:35

Full stack trace with -g -O0, RDMA is enabled:
#0  serializeContig (userdata=0x1040c8768 "",
    buffer=0x20602c920 <error: Cannot access memory at address 0x20602c920>, size=80000, dir=-1)
    at ddt.C:14
#1  0x00000001000e18e1 in CkDDT_DataType::serialize (this=0x100d06140, userdata=0x1040c8768 "",
    buffer=0x20602c920 <error: Cannot access memory at address 0x20602c920>, num=10000, dir=-1)
    at ddt.C:549
#2  0x000000010007d30c in ampi::processRdmaMsg (this=0x100d0a4d0, sbuf=0x20602c920, slength=80000,
    ssendReq=0, srank=0, rbuf=0x1040c8768, rcount=10000, rtype=0, comm=9000000) at ampi.C:2863
#3  0x000000010007d113 in IReq::receiveRdma (this=0x100a100d0, ptr=0x100d0a4d0,
    sbuf=0x20602c920 <error: Cannot access memory at address 0x20602c920>, slength=80000, ssendReq=0,
    srcRank=0, scomm=9000000) at ampi.C:5420
#4  0x000000010006cec9 in ampi::inorderRdma(char*, int, int, int, int, int, int) () at ./sdag.h:206
#5  0x000000010006cbd5 in SDAG::MsgClosure::MsgClosure (this=0x100d0a4d0) at ./sdag.h:90
#6  0x00000001000a4604 in CkIndex_ampi::_call_genericRdma_marshall8 (impl_msg=0x103016460,
    impl_obj_void=0x100d0a4d0) at ./ampi.def.h:3285
#7  0x00000001001053e1 in CkSetRefNum (msg=0x9600406730, ref=0) at ck.C:497
#8  0x000000010012bed6 in std::__1::unordered_map<CkArrayID, CkArray*, ArrayIDHasher, std::__1::equal_to<CkArrayID>, std::__1::allocator<std::__1::pair<CkArrayID const, CkArray*> > >::end (this=0x103016470)
    at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/unordered_map:902
#9  0x00000001001349d6 in std::__1::vector<CkArrayMessage*, std::__1::allocator<CkArrayMessage*> >::swap
    (this=0x895200, __x=...)
    at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:2031
#10 0x000000010010c21d in CkVec<void*>::reserve (this=0x103016460, newcapacity=4294967308)
    at ../bin/../include/cklists.h:233
#11 0x000000010010778d in _processArrayEltMsg(CkCoreState*, envelope*) () at ck.C:1255
#12 0x000000010010725e in _processHandler(void*, CkCoreState*) () at ck.C:859
#13 0x000000010027b1a2 in CmiHandleMessage (msg=0x100d0ac10) at convcore.c:1672
#14 0x000000010027b60d in CsdScheduleForever () at convcore.c:1909
#15 0x000000010027b1fa in CsdScheduler (maxmsgs=-1) at convcore.c:1845
#16 0x0000000100272972 in ConverseRunPE (everReturn=0) at ./machine-common-core.c:1297
#17 0x0000000100277fe4 in call_startfn (vindex=0x1) at ./machine-smp.c:408

Note that the invalid pointer is already received as an argument in IReq::receiveRdma.

Original date: 2017-05-16 15:52:01

Whoa, what is SDAG doing in there?!
Can you try reverting this recently merged series of 3 commits (in which Eric made changes to SDAG closures):
~~https://charm.cs.illinois.edu/gerrit/#/c/2484/~~ https://github.com/UIUC-PPL/charm/commit/d26a94e01e0bff1c46f60d7fa8d7c0895b1bca16
~~https://charm.cs.illinois.edu/gerrit/#/c/2497/~~ https://github.com/UIUC-PPL/charm/commit/40b16eb44c063ef776a6db33f210fb483e733b6f
~~https://charm.cs.illinois.edu/gerrit/#/c/2501/~~ https://github.com/UIUC-PPL/charm/commit/8e85dc62a6ca4dfebcad1f6caf203bd81f80b221
The last one was merged a day or two before this issue started cropping up...
I'm still concerned about why RDMA is even showing up when building with -DAMPI_RDMA_IMPL=0 too

Original date: 2017-05-16 18:12:21

(Note that the stack trace in message #8 was with RDMA enabled).
I think I did not run make clean in the first test, so rerunning the tests resulted in the following (current charm master):
./build AMPI multicore-darwin-x86_64   -j8  -g -O0 -DAMPI_RDMA_IMPL=0: All AMPI tests pass.
./build AMPI multicore-darwin-x86_64   -j8  -g -O0: Crashes, as in message #8.
./build AMPI multicore-darwin-x86_64 -j8 --with-production -g -DAMPI_RDMA_IMPL=0: All AMPI tests pass.
./build AMPI multicore-darwin-x86_64 -j8 --with-production -g: Crashes, similar as in message #8.

Original date: 2017-05-16 18:17:06

K, doing a git bisect on './build AMPI multicore-darwin-x86_64 -j8 -g -O0' to find what commit broke this would be good. It could be any of the SDAG changes that Eric M recently made, or the change that Vipul made to pack/unpack RDMA parameters, or a change in AMPI itself...

Original date: 2017-05-16 18:56:51

git bisect shows that this commit causes the error:
~~https://charm.cs.illinois.edu/gerrit/#/c/2520/~~ https://github.com/UIUC-PPL/charm/commit/ce06655175706886a8945ba137cdce7c20957973

Original date: 2017-05-16 21:03:44

The same failure should happen in SMP mode when running with ppn > 1.

Original date: 2017-05-17 14:17:50

Indeed it does:
http://localhost:8080/job/Nightly-Build/label=linux,platform=mpi-linux-x86_64-smp/
(correct for port forwarding to Jenkins as appropriate)

Original date: 2017-05-17 14:18:17

That started failing exactly the same as the multicore builds:
http://localhost:8080/job/Nightly-Build/label=linux,platform=multicore-linux64/

Original date: 2017-05-17 14:19:25

I suspect that the issue is that the RDMA code is doing packing/unpacking in something of the wrong place - when the message is prepared, rather than when it crosses in/out of the process. Non-RDMA messages only get packed when they're coming or going to/from a process.

Original date: 2017-05-17 14:21:18

Yes, we talked to Vipul after group meeting, and he is taking this issue over. For RDMA sends within a process, the machine layer RDMA code isn't used, and that's where he added the pack/unpack stuff.

Original date: 2017-05-17 15:20:20

At least on netlrts-darwin-x86_64-smp, this does not crash for me when specifying ppn (current charm master, examples/ampi/Cjacobi3D): ./charmrun +p4 ++ppn 2 ./jacobi 1 2 2 5

Original date: 2017-05-19 14:44:53

The issue manifests in AMPI tests, but is not an AMPI issue as such. So, recategorizing and tagging

Original author: Vipul Harsh
Original date: 2017-05-19 18:30:01

Patch: ~~https://charm.cs.illinois.edu/gerrit/#/c/2543/~~ https://github.com/UIUC-PPL/charm/commit/ab2eb371fbb0f847634fc2749cd54a585688f349


compile-time-rng on a platform with getrandom

As a feature request, it would be quite nice to be able to use compile-time-rng (or, better, some dummy-unsafe-no-rng cfg) when building binaries with hashbrown maps while fuzzing.
The https://github.com/rust-fuzz crates seem to mostly always set --cfg=fuzzing, so its possible to also check #[cfg(fuzzing)] without ever actually exposing a potentially-unsafe feature. Happy to work to implement if this would be acceptable.

the build.rs can easily detect a fuzzing flag. (As can the code.)
What do you want the behavior to be when fuzzing?
Should the code be fully deterministic so that every hashmap uses the same keys and hashes the same way?
(IE: Just turning off the random seeding, or should the pointer math, and counters be disabled also?)

A straight constant hash value would likely be ideal.
The goal here ultimately is full determinism in the sense that if you run the same code in the same order the keys should be identical (even if you run the same code twice in a row in the same process/static context). Pointer math likely wouldn't work as, while fuzzers should be turning off ASLR/etc, you may run multiple test cases in the same memory space and get different pointers. Just using compile time RNG values would work fairly well, but would result in fuzzers finding duplicate test cases across runs where you may re-build and get different hash values. Ultimately a straight constant is probably the easiest to implement and the best for fuzzing.

Ok. So even counters should be disabled. Because while it would be identical if the process is re-run, if the same code is called twice in a row in a loop it will produce different results.
I can add a flag to do this, but it still won't make the process fully deterministic if there is a non-ahash hashmap used anywhere. Additionally, there is the possibility it introduces quadratic runtime into functions that otherwise take linear time.
What sort of variable/flag is best to avoid this being 'on' when not intended?

I can add a flag to do this, but it still won't make the process fully deterministic if there is a non-ahash hashmap used anywhere.

Sure, for my use-case I can just swap everything out for hashbrown so in my case it's easy :)

Additionally, there is the possibility it introduces quadratic runtime into functions that otherwise take linear time.

Right, maybe a reason to not always enable it when fuzzing? I assume in most fuzzing cases there aren't enough hash map entries for it to be a concern, however.

What sort of variable/flag is best to avoid this being 'on' when not intended?

The canonical one in Rust is #[cfg(fuzzing)], which is enabled by default by the rust-fuzz projects when building. Given it's not a feature and only an explicit --cfg it's somewhat hard to accidentally turn on (ie has to be a compile flag, cannot be set via Cargo.toml). I'd generally leave it at that, but if there's concern about the behavior being surprising we could swap for some other cfg like ahash-not-random.

Yes, #[cfg(fuzzing)] is definitely better than a feature flag, because it can't creep in accidently. IE: Some random dependency specifies it, therefor it gets set on the whole binary accidently.
The only thing I don't like about fuzzing is the connection is not clear. Nothing is being specified on this package so it might be surprising that its behavior changed. The second thing that is a minor negative, is the fuzzer won't actually be able to affect the iteration order of maps. (And some bugs could depend on this).
If you are in-control of the main I could add a setter method for a supplier for the random sequence used by the RandomStates. Effectively refactor the current implementation to be defined via a trait, and allow alternative impls to be supplied via a static setter. (impls would need to be send + sync) Then you could build a tool where these random values are supplied by the fuzzer (possibly indirectly).

Oops, I'm sorry this somehow fell off my stack.

The only thing I don't like about fuzzing is the connection is not clear. Nothing is being specified on this package so it might be surprising that its behavior changed because fuzing is enabled.

Yea, its true that its a bit strange, but aside from your next point it seems like what a fuzz user would almost certainly want, so its a little less annoying. Specifically, the fact that fuzz output will randomly change and fail any time you use a hashmap in rust is actually quite annoying, and requires a rather significant amount of manual effort to resolve.

The second thing that is a minor negative, is the fuzzer won't actually be able to affect the iteration order of maps. (And some bugs could depend on this).

Indeed, I'm not entirely sure what to do about that. I suppose hashbrown could also detect fuzzing and perturb the iteration order itself, but that seems excessive.

If you are in-control of the main() I could add a setter method for a supplier for the random sequence used by the RandomStates. Effectively refactor the current implementation to be defined via a trait, and allow alternative impls to be supplied via a static setter. (impls would need to be send + sync) Then you could build a tool where these random values are supplied by the fuzzer (possibly indirectly).

At least for my use-case that's more than fine, because I'm aware of the issue and work with fuzzers in Rust regularly. For those who are less accustomed to fuzzing, non-deterministic behavior can be somewhat surprising, and some fuzz tools light up large warnings about non-determinism which isn't clear the source of. I suppose could always do both - default to deterministic behavior with cfg(fuzzing) and also provide a static setter which can use fuzz input as random source, or at least allow allow for compile-time randomness.

I have sortof a prototype of this. (Though annoyingly it does not work on ARM)
The basic idea is that we could have a feature/flag to check which disables runtime randomess, and a main can call this function to supply randomness (presumably from the fuzzer).
There is still a bunch of work to do. In terms of interface I don't really like the fact that the fixed and dynamic randomness are on the same trait, but I am not really sure what would be best for an application.

I have sortof a prototype of this. (Though annoyingly it does not work on ARM)

Cool! Thanks.

The basic idea is that we could have a feature/flag to check which disables runtime randomess, and a main can call this function to supply randomness (presumably from the fuzzer).

Right, makes sense. I'm not sure what the right answer is, but, on balance, an inconsistent fuzzer is probably better than a fuzzer that will miss a bug that depends on hashmap iteration order, so probably best to use something like cfg(ahash_no_random) or whatever. Of course useful to document in README as some things (I believe driller is one) will give you completely inscrutable errors as a result of randomness being loaded at runtime.

There is still a bunch of work to do. In terms of interface I don't really like the fact that the fixed and dynamic randomness are on the same trait, but I am not really sure what would be best for an application.

Hmm, right, I assume they're hashed together in one way or another? I guess there's not a ton of reason to a fuzzer should care about both, as long as it can get hashes to output anything from just the dynamic part maybe fixed can stay fixed and dynamic entropy can come from the interface that fuzz main's can override? This would also make it a tiny bit harder to foot-gun with the API.

This is now available in v0.8.0


Median-averaging of complex CSDs

signal.csd does not median-average complex CSDs correctly because of unexpected behavior of np.median for complex-valued arrays (see the numpy issue). Line 589 of signal/spectral.py could be modified so that if the CSD is complex, its real and imaginary parts are separately median-averaged.
Reproducing code example:

import numpy as np
from scipy import signal

s = 0.3 * np.random.uniform(size=100000) # white noise
n1 = np.random.uniform(size=100000)
n2 = np.random.uniform(size=100000)
d1 = s + n1
d2 = s + n2
freq, Pss = signal.csd(s, s, nperseg=100) # mean average PSD of s
_, Pssmed = signal.csd(s, s, nperseg=100, average='median') # median average PSD of s
_, P12 = signal.csd(d1, d2, nperseg=100) # mean average CSD of d1 and d2
_, P12med = signal.csd(d1, d2, nperseg=100, average='median') # median average CSD of d1 and d2

The real and imaginary parts of P12 should have similar variances, but in the median-averaged case the variance of the imaginary portion is much too high.

Scipy/Numpy/Python version information:

import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info)
1.4.1 1.16.2 sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0)

@hadrev agreed they should be processed separately (not 100% sure it's correct but seems reasonable to me), would you be up for making a PR for this?

Good catch @hadrev! It definitely looks like that the current behavior of np.median on complex arrays isn't what we want. There isn't a unique notion of a multivariate median, though, which is effectively what we're looking for in this case (See this wikipedia page).
I haven't looked at this carefully yet, but I think that for cross-spectra, we may in fact want something more like a geometric median rather than the medians of the real and imaginary parts of the array, as this may throw away correlations between the two.

No consensus on this so I'm removing the 1.6.0 milestone


Cloning TLS connection random values

Many attacks on various TLS modes (e.g. https://eprint.iacr.org/2019/421.pdf) require the attacker's capability to act as MITM proxy sending ClientRandom to the server and ServerRandom to the client.
Currently, there is no way to specify exact random values to clone handshake parameters for such a proxy. It may be useful to implement such API for research purposes, though it MUST NOT be used in the production environment.

I think there are dedicated software projects for such things, I don't see a need to add any support for that in OpenSSL.

I'm not sure because OpenSSL pretends to be universal. But I can't imagine an API to use it for this purpose that will never be used by benign users accidentally. Maybe smth disabled by default?..

This seems like something a systemtap script would be perfect for
Marking as inactive, to be closed at the end of 3.4 dev barring further input


certificate

Icon Request

Icon name:
Use case:
Screenshots of similar icons:

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

Please complete the form above. Thanks!

Closing due to missing info.


Acorn config update

Summary
This PR adds gcc 10.2.0 to the intel compiler build environment on Acorn (as we do for other systems), and also pins several packages versions for intel 19 on Acorn to avoid C++-related build failures. I have created separate intel 19 and 2022 environment on Acorn under spack-stack-1.6.0 (due to an unrelated issue having to do with py-contourpy), and those directories are now reflected in the documentation.
Testing
Tested on Acorn; these modifications are reflected in the directories shown in the updated documentation.
Applications affected
all
Systems affected
Acorn only
Dependencies
none
Issue(s) addressed
--
Checklist

[x] This PR addresses one issue/problem/enhancement, or has a very good reason for not doing so.
[x] These changes have been tested on the affected systems and applications.
[x] All dependency PRs/issues have been resolved and this PR can be merged.

@Hang-Lei-NOAA Can you take a look at this PR please? Thanks!

@Alexander Richert - NOAA Affiliate @.***> I
remembered that the gcc/11.2.0 is on acorn, why not pin gcc/11.2.0?
This commit itself should be fine to add gcc in the environment.
On Thu, Jan 18, 2024 at 1:03 PM Dom Heinzeller @.***>
wrote:

@Hang-Lei-NOAA https://github.com/Hang-Lei-NOAA Can you take a look at
this PR please? Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/JCSDA/spack-stack/pull/958#issuecomment-1898966265,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKWSMFBNGEWOP7ZMWCENQQDYPFPWVAVCNFSM6AAAAABB7NQXEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJYHE3DMMRWGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

For some reason not all of the GCC installations work in this context, 10.2.0 is the only one for each where I was able to get it to build the whole stack.


Main Java Usage Wiki Page has not been updated for the latest Beta release

The PathPlannerLib Java Usage page still references the PathPlanner class, which does not seem to exist in the latest version of the 2024 beta. Please let me know if there is another page I should use as a starting point for learning the new library. Thanks.
JD Lewis
FRC 6377 - Howdy Bots

2024 examples are in the sidebar. I also added their links to the main page.


Support publisher common id opt_out cookie

Add a section for the publisher common id that describe the usage of individual user opt-out.

confirmed went out with 1.25


Azure API throttling (get VMs) and x-ms-ratelimit-remaining-subscription-reads

Rest call to get VMs  frequently returns 429 status code ( for example,  every hour for entire day) with error pointed to calls limit reached:

Azure Resource Manager read/write per hour limit reached. Will retry in: 1200 seconds

header value x-ms-ratelimit-remaining-subscription-reads of azure responses always contains big values 13000 - 14000, all other header values related to calls rate ( x-ms-ratelimit-remaining-subscription-writes, x-ms-ratelimit-remaining-tenant-reads., etc.)  are null.
For example we observed that the previous get call to azure that passed (was made less  than 1 sec before) exposed in the response  x-ms-ratelimit-remaining-subscription-reads > 13000.

The header values doesn't provide any real number about reaching the limit as it's supposed to be per https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-request-limits#retrieving-the-header-values

Cleaning up old issues from 2016 - 2018. Please reopen this issue if it is still a concern.


No JSON object could be decoded?

https://github.com/PokemonGoF/PokemonGo-Bot/wiki/No-JSON-object-could-be-decoded-or-decoder.py-error

im getting this...

Yes, you seem to be getting the double quotes wrong. Probably something your text editor does. Try copying the example file, and editing only the text inside the quotes

@mrthrowaway whats the next step? :-D

python pokecli.py

@mrthrowaway but what does this mean?

Where is your config.json file? If its in a different location other than the default or if you've renamed it
do python pokecli.py -cf path/to/config.json

@mrthrowaway getting this now :-) whats next?
(PokemonGo-Bot) Kenneths-MacBook-Pro:PokemonGo-Bot kennethbolo$ python pokecli.py
[2016-07-30 21:04:11] [x] PokemonGO Bot v1.0
[2016-07-30 21:04:11] [x] Configuration initialized
[2016-07-30 21:04:11] [#] IMPORTANT: Rename and configure release_config.json.example for your Pokemon release logic first!

IMPORTANT: Rename and configure release_config.json.example for your Pokemon release logic first!
That :P

change it back to config.json.example?

nope. you'll find a file named release_config.json.example, change it to release_config.json

I'm getting this now.
[2016-07-30 22:33:51] [x] PokemonGO Bot v1.0
[2016-07-30 22:33:51] [x] Configuration initialized
[2016-07-30 22:33:51] [x] The location given using -l could not be parsed. Checking for a cached location.
[2016-07-30 22:33:53] Login Error, server busy

Login error happens when the pokemon go servers are busy. If you location isn't recognized, you could try entering the latitude and longitude manually

@mrthrowaway I managed to run it. By cloning and adding the Google generated password. But how do i set it up with the web ui?

git submodule init
git submodule update
cd web
<edit userdata.js or config/userdata.js depending on what version you're on>
python -m SimpleHTTPServer

And browse to http://localhost:8000

should i run it in a new terminal window? or in the same terminal as pokecli.py?

run it separately

do i need to download openpogoweb-master first?

git submodule command should be run inside PokemonGo-Bot

@mrthrowaway
So what order should i put git submodule in?
cd pokemongo-bot
virtualenv .
source bin/activate

git submodule?
pip install -r requirements.txt
python pokecli.py

cd path/to/PokemonGo-Bot
git submodule init
git submodule update
cd web
<edit userdata.js or config/userdata.js depending on what version you're on>
The above bit only needs to be done the first time
To start the web interface,
cd path/to/PokemonGo-Bot/web
python -m SimpleHTTPServer

This is run separately from your bot, presumably in another terminal window/tab

is this correct? i'm getting a blank screen on my localhost.

you need to run the server from inside the web directory

@mrthrowaway  u mean the OpenPoGoWeb-master

If you followed the installation instructions, you end up with the PokemonGo-Bot/ directory with the web/ directory inside it.
If your OpenPoGoWeb directory is named something other than web or located elsewhere, you'll have to rename it to web and move it inside the bot directory

@mrthrowaway now its running a blank screen

Umm. Did you install the bot using git like the installation instructions said or did you download a zip file?

@mrthrowaway now i am getting this?

At this point, I'd just start over and go through the installation instructions step by step
https://github.com/PokemonGoF/PokemonGo-Bot/wiki/Installation
At the end, you will have the directory named PokemonGo-Bot from where you run the bot, and a web directory inside that from where you run the web interface.
If you still have issues, join the Slack chanel at https://pokemongo-bot.herokuapp.com/
Someone with more experience with MacOS may be able to help you there

Regarding the error you last posted https://github.com/PokemonGoF/PokemonGo-Bot/issues/2082

thank you very much 👍


Can't get the pre-trained model

It seems that both the Google Drive and Baidu Disk are down. Also the official pre-trained model in openMMLab can't be reached. Can you update the model link? Many thanks！

Hi, I can download normally. Can you provide a screenshot or information of the error you encountered?

I think it's a vpn problem and it can be downloaded normally after switching a node. Thank you for your reply anyway.


git-node: detect CI status also from the GitHub API

Currently it only parses the thread and looks for CI links pasted manually, but it can also just query the GitHub API for the status of the last commit in the PR in case someone forgets to paste the link.
We cannot replace the link parsing entirely with this though because the github bot does not always update the CI status reliably. If the node-test-commit status of the last commit is not green we could also print a warning (again we cannot just error because the bot or Jenkins is not always reliable)

I think @richardlau made a good point in https://github.com/nodejs/node/pull/25861#issuecomment-461256551 that having ci:  is good for after the fact observation.
The suggestion I would make for git node land is that when it says no CI detected, it mention specifically that it is looking for a ci: comment. You could print a message saying "ci passed, but not comment, please add ci: ... as a comment.... but honestly, just clarity about what the tool is looking for would be enough, IMO.

@sam-github That's a good point. Although it would still be useful to query the CI status and display a hint if it's not green or yellow, so that the user is aware that they are pushing a commit to master that did not fully pass the CI (even when it's just flaked).


putting cmds into different files results in command not getting declared

I have diffrent commands in different files stored.. say, in my main gm I include commands/main, in which I  then include "commands/supporter", "commands/admin", "commands/highadmin"... .pwn files
after I included all files, I put the two callbacks at the end of commands/main.pwn - but calling my cmd results in invalid command message (flags always 0, seems the command isn't really declared.
#include "/../../gamemodes/commands/debug.pwn"
//#include "/../../gamemodes/commands/player.pwn"
//#include "/../../gamemodes/commands/supporter.pwn"
//#include "/../../gamemodes/commands/admin.pwn"
#include "/../../gamemodes/commands/head-admin.pwn"
//#include "/../../gamemodes/commands/projektleiter.pwn"*/

`public OnPlayerCommandReceived(playerid, cmd[], params[], flags)
{
	if(!pInfo[playerid][loggedin])return 0;
	DebugPrint("if([%d]%d < %d", playerid, pPermissions[playerid], flags);
    if (pPermissions[playerid]<flags)
    {
    	SendClientMessage(playerid, GREY, "* Du hast keinen Zugriff auf diesen Befehl.");
        return 0;
    }

    return 1;
}

public OnPlayerCommandPerformed(playerid, cmd[], params[], result, flags)
{
	if(result == -1)
    {
        SendClientMessage(playerid, 0xFFFFFFFF, "SERVER: Unbekannter Befehl. ("HTML_RED"/help"#HTML_WHITE")");
        return 0;
    }
	return 1;
}

@michael-fa If you solved your issue you should explain how so other users who come across this will know what to do.

@Crayder Wow, no, I really could not get behind the weirdness the plugin reached by just putting a command in to a different file, which I then just include.
For everyone: I did not solve the problem, sadly I had to use something else (for now.)


Error in executing the binary executable

Godot version: Current master branch
Commit Hash :- 133942cfeb0279ca03ab9943459c5140ab1f1725
OS/device including version:  Windows 10 (OS Build 16299.248)
GPU Model :  GeForce 940MX/PCIe/SSE2
Issue description:
I followed each and every step in the documentation for "Compiling in Windows."
I compiled the source code on windows 10 using Scons.
The executable was successfully created inside the bin directory as directed in the documentation.
But when I ran the executable nothing shows up apart from a white screen

Error generated : OpenGL ES 3.0 Renderer: GeForce 940MX/PCIe/SSE2 WARNING: StreamPeerMbedTLS::_load_certs: Error parsing some certificates: 1      At: modules\mbedtls\stream_peer_mbed_tls.cpp:281
Steps to reproduce:
I cloned the source code using GIT.
Then I compiled using scons -j3 platform=windows given I have 4 cores of processor.
Then I executed the .exe file give generated the error specified above.

I get the same error
Master Kubuntu

@AlexHolly This bug report is about Godot not displaying anything. The error you're mentioning is most likely unrelated, so please report it in its own issue.

I found it strange, I have exact same GPU Model, and it is indeed shows blank white screen on Windows (I have yet to test it on Ubuntu in same machine) to all version of Godot including 2.x too. I tried this on many machines, Godot runs in all of them except mine. Is this more hardware/driver specific problem?

So is this fixed?

Since no other Windows users could confirm it, I'm pretty confident that it's a Windows drivers bug and might have been fixed by now by drivers updates.


Add square option to AggregrateError for derefinement

When accumulating local indicators, some marking algorithms require accumulating the squared value before taking the final square root, as this better reflects the underlying norm structure of the estimate. This tiny PR adds this as an option for aggregation during a derefinement.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#3932
@hughcars
@tzanio
@tarikdzanic + @termi-official
10/19/23
⌛due 11/2/23
⌛due 11/9/23

PR Checklist

[ ] Code builds.
[ ] Code passes make style.
[ ] Update CHANGELOG:

[ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
[ ] Does it make sense to create a new section in the CHANGELOG to group with other related features?

[ ] Update INSTALL:

[ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
[ ] Have the version ranges for any required or optional libraries changed?
[ ] Does make or cmake have a new target?
[ ] Did the requirements or the installation process change? (rare)

[ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)

[ ] .github
[ ] .appveyor.yml

[ ] Update .gitignore:

[ ] Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
[ ] Add new patterns (just for the new files above) and re-run the above test.

[ ] New examples:

[ ] All sample runs at the top of the example source file work.
[ ] Update examples/makefile:

[ ] Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
[ ] Add any files generated by it to the clean target.
[ ] Add the example binary and any files generated by it to the top-level .gitignore file.

[ ] Update examples/CMakeLists.txt:

[ ] Add the example code to the ALL_EXE_SRCS variable.
[ ] Make sure THIS_TEST_OPTIONS is set correctly for the new example.

[ ] List the new example in doc/CodeDocumentation.dox.
[ ] If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add example-specific documentation, see e.g. the src/examples.md.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] In examples.md, list the example under the appropriate categories, add new categories if necessary.
[ ] Add a short description of the example in the "Extensive Examples" section of features.md.

[ ] New miniapps:

[ ] All sample runs at the top of the miniapp source file work.
[ ] Update top-level makefile and makefile in corresponding miniapp directory.
[ ] Add the miniapp binary and any files generated by it to the top-level .gitignore file.
[ ] Update CMake build system:

[ ] Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
[ ] Add/update the CMakeLists.txt file in the new miniapp directory.
[ ] Consider adding a new test for the new miniapp.

[ ] List the new miniapp in doc/CodeDocumentation.dox
[ ] If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
[ ] If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
[ ] Add a short description of the miniapp in the "Extensive Examples" section of features.md.

[ ] New capability:

[ ] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
[ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
[ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
[ ] Consider adding new sample runs in existing examples to highlight the new capability.
[ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
[ ] If this is a major new feature, consider mentioning it in the short summary inside README (rare).
[ ] List major new classes in doc/CodeDocumentation.dox (rare).

[ ] Update this checklist, if the new pull request affects it.
[ ] Run make unittest to make sure all unit tests pass.
[ ] Run the tests in tests/scripts.
[ ] (LLNL only) After merging:

[ ] Update internal tests to include the new features.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

Maybe I am misunderstanding your description, but I think there are 2 errors in the implementation. Can you take a look at my comment @hughcars ?

You were totally correct. Fixed just now.

LGTM


feat: Rename plugins option to parser-plugins.

The original option name created confusion about what was expected.
This helps identify that babel parser plugins are expected, not babel
transform plugins.
BREAKING CHANGE: The plugins option has been renamed to
parser-plugins.
Fixes #986

Coverage remained the same at 96.296% when pulling 9ff5d66b731e8acca2aa26c8d44e5a030b3902c9 on coreyfarrell:parser-plugins into 364eb330cd16331f62f9aa967598ef4a08e07d28 on istanbuljs:master.

@coreyfarrell do we have an nyc@14 branch to merge breaking changes to and rebase eventually?

@JaKXz master already has one breaking change merged and #1026 is being labeled as breaking to be on the safe side.  The plan is that the next release will be 14.0.0.


Default icon id should be 32512

Track issue https://github.com/mxre/winres/issues/28 which was closed without action (so it's still open, technically).

Fixed in winresource = "0.1.16"


Orchestration flags could be just an arrays instead of a map

The OrchestrationFlags field in the serviceRequestForm is currently a map of key with flags' names, and values TRUE or FALSE. Since flags can only be true or false, this field could just be an array of the flags. THe flags sent are true, and the ones not sent are false by default.
I know this is a big change in one of the main interfaces, but I put it here to open the discussion

yes, indeed
need to think about it

There also seem to be some differences between the consumer skeleton and the orchestration system implementation. Not sure if this is actually correct, but it looks off at first glance.
ConsumerMain.java, line 97-106:
    //Some of the orchestrationFlags the consumer can use, to influence the orchestration process
    Map<String, Boolean> orchestrationFlags = new HashMap<>();
    //When true, the orchestration store will not be queried for "hard coded" consumer-provider connections
    orchestrationFlags.put("overrideStore", true);
    //When true, the Service Registry will ping every potential provider, to see if they are alive/available on the network
    orchestrationFlags.put("pingProviders", false);
    //When true, the Service Registry will only providers with the same exact metadata map as the consumer
    orchestrationFlags.put("metadataSearch", true);
    //When true, the Orchestrator can turn to the Gatekeeper to initiate interCloud orchestration, if the Local Cloud had no adequate provider
    orchestrationFlags.put("enableInterCloud", true);

OrchestratorResource.java, line 52-69:
  @POST
  public Response orchestrationProcess(@Valid ServiceRequestForm srf) {
    srf.validateCrossParameterConstraints();

    OrchestrationResponse orchResponse;
    if (srf.getOrchestrationFlags().get("externalServiceRequest")) {
      log.info("Received an externalServiceRequest.");
      orchResponse = OrchestratorService.externalServiceRequest(srf);
    } else if (srf.getOrchestrationFlags().get("triggerInterCloud")) {
      log.info("Received a triggerInterCloud request.");
      orchResponse = OrchestratorService.triggerInterCloud(srf);
    } else if (!srf.getOrchestrationFlags().get("overrideStore")) { //overrideStore == false
      log.info("Received an orchestrationFromStore request.");
      orchResponse = OrchestratorService.orchestrationFromStore(srf);
    } else {
      log.info("Received a dynamicOrchestration request.");
      orchResponse = OrchestratorService.dynamicOrchestration(srf);
    }

I notice that:

The same flags are not mentioned in both places
In consumer it is enableInterCloud and in orch. it is triggerInterCloud
The code in orchestrationProcess() indicates that a SRF can be of one of four types (external, interCloud, override, or dynamic), where the rest of the implementation states it as four boolean flags that can be turned on and off in any combination...

The orchestrator here only mentions the flags that are needed to decide which orchestration mode should be started. The consumer skeleton only mentions flags that I chosen to be potentially interesting to change for the example. This is on purpose.
enableInterCloud and triggerInterCloud are 2 different flags, which can have a similar effect.

the rest of the implementation states it as four boolean flags that can be turned on and off in any combination...
Where does is state this? Do you mean the ServiceRequestForm? Technicially it is true, but not all the combinations would make sense (both trigger and externalSR being true), and I think only the local Gatekeeper is allowed to send an SRF with externalServiceRequest true (see Orch access control filter).
Handling the flags on the Orch side in this particular order might not be the best solution, maybe the Orchestrator should look at these flags all at once, and decide from there what to do.

1/2. Okay, the first time around I was really looking for something else and just wanted to record what I noticed so we had a change to come back to it. Now, I had looked a little more into it (and found the state chart in the documentation). Seems you're right that it works as intended. Then, it's only a minor issue, that influences code readability and how the application systems developers experiences it.

Well, the code states it. Give developers four boolean properties and they will expect that at least some combinations will work - give them a state, enum or set of subtypes and they will know that a SRF can be of four types. The code in OrchestratorResource is really just a switch on four types, thus I feel this should somehow be reflected in the SRF.

Maybe this is better modelled by having multiple services? One for the gatekeeper, one for store, and one for dynamic. The triggerInterCloud could be handled by the opposite enableIntraCloud, making the implementation something like:
if (enableIntraCloud) results.append(doIntraCloud());
if (enableInterCloud) results.append(doInterCloud());

Would also move the access control to service level, rather than having to inspect what's in the payload itself.
Anyway, was just my 5 cents...


Rewrite the DSA-lobby backend in Rust

To have a consistent code-base in the long run, it has been decided on our last sync a few weeks ago that the game-lobby API (currently written in C# and available in the old DiscoBot repo) should be ported to Rust as well.
With this change, we'll have even less components cluttered across several repos and can build (almost) the entire project in one run.

The API itself should be fairly trivial to implement. I suggest to use some framework like rocket for the api.
We have to build a new database structure as well to migrate away from firebase. I'd suggest to just use a postgres db.
On that note, should we provide a docker compose solution for easy deployment? (web api, database, rask-server)
And should we merge the web api and the game-server?

Should we provide a cli interface for the server?
this could be inspired by rask-server to save us some work


Consolidate codecs for both client and server in one place

Handle all import logic and encoder/decode function construction in the tuber.codecs namespace, rather than distributed between the server and client namespaces.
Create a Codecs dictionary for keeping track of encoder/decoder functions on the server.

There are merge conflicts between this and #22, so if both are approved, I'd want pause to fix the conflicts after one of them is merged.

I've merged this one - please go ahead and rebase the other one and I'll review it in parallel.


Roleplaying is Magic 4E sheet

Sheet looks good, should make it out on with the next character sheet push either today or tomorrow.


see whatwg for their copyright

point to WHATWG for their copyright rather than duplicating it

Nit: there's a space between the ( and the link now


Call LoseContext to prevent WARNING: Too many active WebGL contexts. Oldest context will be lost.

Similar to #1271, I've ran into WARNING: Too many active WebGL contexts. Oldest context will be lost. because the context is not properly cleaned up even after calling .clear() and .kill.
What I've tried is the following (inside ngOnDestroy):
this._chartRenderer.clear();
this._chartRenderer.kill();
this._chartRenderer = null;

However, this did not solve the issue and I've come up with the following solution. However, the "type cheating" is quite hacky and I feel like this should be the default behaviour of a .kill() function (to properly clean up the WebGL contexts), shouldn't it?
this._chartRenderer.clear();
this._chartRenderer.kill();
Object.values((this._chartRenderer as any).webGLContexts as WebGLRenderingContext[]).forEach(
  context: WebGLRenderingContext) => {
    // Free up all the context
    context.getExtension("WEBGL_lose_context")?.loseContext();
  }
}
this._chartRenderer = null;

Interesting, thanks for this feedback. I'm a bit afraid of just pushing a fix, because of this comment from @Yomguithereal:
https://github.com/jacomyal/sigma.js/issues/1271#issuecomment-1278876667
Just so that I know what to target: Which version of sigma are you using?

Yea,h I've also read through this post. And tbh, I have no idea whether this has any implications or stuff. I can only say that it works for me and I have (a) no warnings in the console and (b) I guess it also frees up the resources (at least, the warnings with "too many WebGL Contexts disappeared).
But sure, this could have bad side-effects :D
I'm using the newest version 3.0.0-alpha3

OK, good to know, I don't have to push any hot-fix to the v2.4 version, at least :)
@Yomguithereal Any take on that?

Thanks for the explanation! I'm not entirely sure whether this is related to angular or not. I already use the DestroyRef by putting it inside ngOnDestroy that gets automatically called when the component gets destroyed. And as expected, I also see the "DESTROY"-message every time I expect something to be destroyed. Nonetheless, it still doesn't work without the loseContext - with it, it works flawlessly :D
public ngOnDestroy(): void {
    this.graph?.clear();

    console.log("DESTROY!");
    // Proper cleanup to properly delete WebGL context.
    if (this.renderer) {
      this.renderer.clear();
      this.renderer.kill();
      // Free up all the context (see https://github.com/jacomyal/sigma.js/issues/1386)
      // Object.values((this.renderer as any).webGLContexts as WebGLRenderingContext[]).forEach(
      //   (context: WebGLRenderingContext) => {
      //     context.getExtension("WEBGL_lose_context")?.loseContext();
      //   }
      // );
      this._renderer = null;
    }
}


Could we add the SIG hosts as moderators to this repo?

Damian Glover and Lubna Dajani.

Damian has (we have a Team for maintainer rights) - I don't have a Github handle for Lubna as yet ?

hello thank you for pinging me on this Phil hello Paul

I am totally new to using Github and need to find my way around. thank you for any and all help

Damian and Lubna seem to be moderators now. Thanks!


feat(linter/eslint/no-cond-assign): span points to the operator

close: #1726

Current dependencies on/for this PR:

main

PR #1739   👈

This stack of pull requests is managed by Graphite.


Build Instructions are poor

Some OS'es still ship zig-0.9.1 including mine, which is not working on my OS.
I was not able to find the specified, tested zig version here https://ziglang.org/download/.
zig-0.11.0-dev.3786+8dcb4a3dc (for linux_x86_64 in my case) is working. I couldn't find a different 0.11 version for direct download.
Build instructions can be found here https://ziglang.org/learn/getting-started/#direct-download, and it is a little awkward to find them, to be honest. On the other hand, one only needs to extract it with xz --decompress and add the extracted directory to your path. I suggest to mention this.
Users of poop that aren't zig devs, likely do not want to set up a nighty build / nighlty download of a prebuild binary, and the version for download likely keeps changing. That is a tough situation, and should be at least mentioned.
I did not check whether some zig-0.10 is working, but using a more stable version might be more convenient for users of poop that aren't zig-devs.

https://github.com/andrewrk/poop/pull/35#issuecomment-1605791460


[do not merge] Standalone modifiers with paren hack

This is a hardcoded, no-config hack to add the shift-to-parens trick that was made popular by this article. Build as you would with @wwwjfy's build, but this is only if you want the last piece of the Space Cadet puzzle: better shifting!
Details of the functionality: When shift is pressed by itself, it does ( (or ) for right shift). When it's pressed in conjunction with something else, it provides the expected behavior.
Required config snippet:
            ...
            "standalone_keys": {
                "left_shift": "left_shift",
                "right_shift": "right_shift"
            },
            ...

Hmm…I was unable to get this to work after building and setting the config as shown above. Any suggestions?

hmm... hard to say without any other informations.
did you read this? https://github.com/tekezo/Karabiner-Elements/pull/247#issuecomment-276043287
Things you may have wrong:

location of configuration. check if you config is at ~/.config/karabiner/karabiner.json (was ~/.karabiner.d/configuration/ before)
configuration itself. try to use my config from the comment linked above.
try to do a clean reinstall. remove karabiner and all of the config-files. reboot. reinstall and set config again.

Hi,
I have wired Apple Keyboard with Numeric Keypad.
I would like to remap:
CMD+C to right_CTRL+Fn (copy)
CMD+V to right_SHIFT+Fn (paste)
using Karabiner-Elements.
Can someone help me?

Hey @jasonmay, I've made a general patch for shift-to-parens like mappings. Take a look at #2.
Build is here https://github.com/IvanRublev/Karabiner-Elements/releases/tag/0.90.90_shift_to_parens.

@IvanRublev awesome! this seems to have gotten fairly out of date anyway (and even stopped working for me at this point). I'll try out yours and if you're works I'll point people to yours!

I had great success with @IvanRublev 's build, thanks Ivan!


ci: add checks for code style

Adds checks for formatting and linting, using the configurations that should be used.
As of writing, both checks should fail until:

#289 is merged, fixing formatting errors
Linting errors are fixed

Seems there is still some issue?

@magnus-madsen
Yes, linting has been configured wrong for a while, so there are a lot of small errors here and there. I'll make another PR to fix them.

Or wait - There seems to be an issue with the formatting as well.

Linter errors fixed in #291

@sockmaster27 Not sure why it is still not passing? I tried to re-run the tests?

End-of-line... 😐

Ok. I'm not home now, but will merge later.

Do we remove the .eslint* files?

@magnus-madsen
No, we're still using it for linting


Use AT_MOST measurespec when onyl max dimension is defined

Make use of max dimension styles to allow root to be measured with AT_MOST measurespec

I think this pr only support for the top-most node, it's not enough.
https://github.com/facebook/css-layout/issues/201

@molon I'll follow up with another PR. thanks for pointing this out.
@rigdern This was an oversight, i'll follow up

@rigdern #203


How can i get the props after Actions.popTo in the previous scene?

Version
Tell us which versions you are using:

react-native-router-flux v4.0.1
react-native v0.55.4

Expected behaviour
Actions.push
SceneA ==> SceneB
Actions.popTo
SceneB ==> SceneA
How can i get the  props in SceneA?

According to the API documentation, there is a second parameter on popTo that is an object for your props.

Property
Type
Parameters
Description

[key]
Function
Object
The Actions object "automagically" uses the Scene's key prop in the Router to navigate. To navigate to a scene, call Actions.key() or Actions[key].call().

currentScene
String

Returns the current scene that is active

jump
Function
(sceneKey: String, props: Object)
used to switch to a new tab. For Tabs only.

pop
Function

Go back to the previous scene by "popping" the current scene off the nav stack

popTo
Function
(sceneKey: String, props: Object)
Pops the navigation stack until the Scene with the specified key is reached.

push
Function
(sceneKey: String, props: Object)
Pushes the scene to the stack, performing a transition to the new scene.

refresh
Function
(props: Object)
Reloads the current scene by loading new props into the Scene

replace
Function
(sceneKey: String, props: Object)
Pops the current scene from the stack and pushes the new scene to the navigation stack. *No transition will occur.

reset
Function
(sceneKey: String, props: Object)
Clears the routing stack and pushes the scene into the first index. No transition will occur.

drawerOpen
Function

Opens the Drawer if applicable

drawerClose
Function

Closes the Drawer if applicable

create
React.Element
pass Scene to create your app navigator. It is alternative router creation method mostly used for Redux integration

@dextermb I have seen that API documentation, but it doesn't seem to work.

@arfaWong Probably in relation to #3206.
cc @daviscabral @aksonov

Yes, thank @dextermb, we can continue this over there. But before doing that it's important to notice that things changed from 1.x to 2.x on react-navigation, making a lot of RNRF API to also change (that's the main reason why this went from v3 to v4.
Please read #3206 and see if you think you can contribute there with more information about your problem or that you can help with a PR.


Fix left-hand-panel resize issue

Fixes drawer resize bug, fix minimum width at 512px.
Removes shadow from left hand panel:

fixed missing shadow:

fixes #277


Run test_tracetools tests against rmw_fastrtps_dynamic_cpp too

This is sort of a follow-up to #116, see https://github.com/ros2/ros2_tracing/pull/116#discussion_r1645042581
Requires https://github.com/ros2/rmw_fastrtps/pull/772 for the rmw_fastrtps_dynamic_cpp tracing instrumentation
action-ros-ci-repos-override: https://gist.githubusercontent.com/christophebedard/c07fa52c22a5d4af1c0b88755409344b/raw/a0d726f66dcca91cb26b77ef5ef3e35a135ed9e2/ros2.repos

CI is over at https://github.com/ros2/rmw_fastrtps/pull/772#issuecomment-2211227412


Add piles to table for Cities cards

The pink cards shall be present.  The pink cards can also be put in hands, scores, and achievements.

I imagine the ability to draw the Cities cards will be done here as well since their layout is very different than other cards.

Can you file a separate issue to track rendering the cards? That's a separate piece of work from rendering the piles.

done -> #375


Change protractor.conf as default

Is this a convention that I don't know about?  The protractor examples use conf.js.  Would it be alright to make the default something a little more standard (mostly for syntax highlighting).

Hi @buob . Back when I wrote this plugin, if I remember correctly, the default was protractor.conf.js. It seems that's changed now which is fine. I'm worried about the potential of breaking other people's test, but I'll definitely keep an eye on it if more people request it. Hope this helps.


Remove Dead and Deprecated Web Services

repoman 404's so remove the svn redirect
remove the long-commented svn subservice
stop serving the wiki, remove related redirects, and remove related pgsql config

I don't mean this to be a forever thing, I think having the wiki in a middle phase between "is old and out of date and not fixable" and "we're wanting to fix it soon(?)" is the worst option. Nobody sees the "being shut down" message.
cc @copumpkin

Rather than take down the wiki webserver entirely, can you just replace it with a landing page saying something like:

The NixOS wiki is currently down. Please check  <@domenkozar's cookbooks> for documentation in the meantime, and follow https://github.com/NixOS/nixpkgs/issues/22599 for updates on the wiki itself.

It seems friendlier than just making it disappear when it's by far the greatest target of Google links for most Nix searches.

I didn't expect you to have such a positive response! I thought for sure you'd just ask for another week or something :)

I agree with you that we're in the worst possible situation right now, and I have very little time for anything much, so I don't want to leave things shitty due to my lack of time.

@edolstra can you just keep a backup of the wiki data lying around for a while? Not saying it needs to be publicly accessible, but I'd hate to lose the info forever.

I'm looking in to making an export, there is https://nixos.org/wiki/Special:Export but it is a bit annoying since it is per-category.

Ok, I copied all the pages from https://nixos.org/wiki/Special:AllPages and pasted them in to https://nixos.org/wiki/Special:Export and made an export of all pages with all versions, available for a limited time here: http://next.gsc.io/Nix+Wiki-20170503130016.xml
@edolstra can you mirror this export to somewhere on nixos.org, so it can be linked to from the "down" page?

This PR now has a redirect and a second PR adds the landing page: https://github.com/NixOS/nixos-homepage/pull/138
I think this and the other are ready.

Rebased on master after the other PR merged. Ready to be merged.


Support CIPM proceedings

Procès-Verbaux of the Comité international des poids et mesures, CIPM
https://www.bipm.org/en/committees/cipm/publications-cipm.html
(Decisions and Reports)

Procès-Verbaux des Séances du Comité International des Poids et Mesures (PV).
These are cited like this:

"PV, 20, 119-122"

https://www.bipm.org/en/committees/cipm/publications-cipm.html

@ronaldtse this link doesn't work

We can use these:

https://www.bipm.org/en/committees/ci/cipm/publications
https://github.com/metanorma/cipm-resolutions

"PV, 20, 119-122"

@ronaldtse which document should fe fetched from the repo https://github.com/metanorma/cipm-resolutions by the reference?

@andrew2net this is going to sound strange, but that particular resolution is this:
https://github.com/metanorma/cipm-resolutions/blob/master/meetings-en/meeting-1946.yml
https://github.com/metanorma/cipm-resolutions/blob/de6d8786a71fe02ee620f7fb1d63c35c042ed0b3/meetings-en/meeting-1946.yml#L7-L38
I think "20" means "meeting 20", "119-112" means pages 119-122, and it happens that those two are these.
I think we need a better identification system to resolve what "20" and "119-122" means.
Let me clarify with BIPM.

@andrew2net so we have to manually fix the data.
For example, "PV, 20, 119-122" refers to Tome 20, which is available here:
https://www.bipm.org/documents/20126/57335245/CIPM1945-1946.pdf/ebdf0f08-482a-19fc-9e6d-0aced9de2c36
The pages are these:

So we have to manually supplement the "tome 20" information to our cipm-resolutions repository.

https://github.com/metanorma/bipm-data-outcomes/tree/main/cipm

We need only involve BIPM PV 20, we don't need to retrieve anything for BIPM PV 20, 119-122 if page-granularity information is not available.

@opoudjis For CGMP and CIPM fetching by pages hasn't been implemented.
Each source file can have multiple resolutions. For example, https://github.com/metanorma/bipm-data-outcomes/blob/main/cgpm/meetings-en/meeting-20.yml has 11 resolutions. Each resolution is treated as a document. So in the https://github.com/relaton/relaton-data-bipm/tree/master/data we have CGPM20-1.yaml, CGPM20-2.yaml, ... CGPM20-11.yaml. The relaton-bipm accepted references like BIPM CGPM20 1.
As I understand for PV references relaton-bipm should return CGMP documents, and for CR references CIPM documents, right?
How should we treat resolutions? Should we put them into relations?

Yes:

CR is CGPM Resolutions
PV is CIPM Decisions

Also, we do not need the "Tomb" number anymore, as per BIPM.

The relaton/relaton-data-bipm is updated. See examples https://github.com/relaton/relaton-bipm#search-for-a-standard-using-keywords

<organization>
      <name>Bureau Intrnational des Poids et Mesures</name>

Misspelled International :-)

@opoudjis done but there are duplicates of PV 102 and PV 104 documents.
The document
https://github.com/metanorma/bipm-data-outcomes/blob/main/cipm/meetings-en/meeting-2013.yml
has the same (102) number as
https://github.com/metanorma/bipm-data-outcomes/blob/main/cipm/decisions-en/meeting-102(I).yml
The https://github.com/metanorma/bipm-data-outcomes/blob/main/cipm/meetings-en/meeting-2015.yml
has the same (104) number as
https://github.com/metanorma/bipm-data-outcomes/blob/main/cipm/decisions-en/meeting-104(I).yml

There is some misunderstanding here.
"PV 102" does not refer to two things. It refers to one book that contains two types of objects that are mentioned in the same meeting:

decisions (this content comes from the meeting)
resolutions (this content is "input" to the meeting, i.e. it is not from the meeting)

The reason why I told @opoudjis that we will no longer use page numbers and tome numbers, is exactly because of this.
The new format provided by BIPM provides "unique identifiers" to every Decision and Resolution.
For example, a citation "PV, 20, 119-122" in the old form is now "Resolution 1, CIPM 41st meeting":
https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/meetings-en/meeting-1946.yml#L11
There is no "PV" anymore.

...
... I... see
So, Relaton needs to respond to requests to these new identifiers, and the editors will need to insert references to these new identifiers, even though the rendered text will presumably still be "PV 20, 119-222".
And the identifier is what? "CIPM 31,1"?

So, Relaton needs to respond to requests to these new identifiers, and the editors will need to insert references to these new identifiers

Yes.

even though the rendered text will presumably still be "PV 20, 119-222".

Maybe, maybe not.
Locating BIPM meeting-related identifiers
There are these types of identifiers:

CIPM meetings
CIPM meeting resolutions
CIPM decisions
CGPM meetings
CGPM meeting resolutions
CCTF meeting
CCTF meeting resolutions

How about we do this:

CIPM meetings:

"CIPM meeting {number}" e.g. "CIPM meeting 41" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/meetings-en/meeting-1946.yml#L3)
"CIPM meeting {year}" e.g. "CIPM meeting 1946"
"CIPM meeting {id}" e.g. "CIPM meeting 41-1946"

CIPM meeting resolutions

"CIPM {meeting-locator} resolution {resolution id}" e.g. "CIPM meeting 41 resolution 1"
"CIPM resolution {meeting id}-{resolution id}" e.g. "CIPM resolution 41-1" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/meetings-en/meeting-1946.yml#L11)

CIPM decisions

"CIPM decision {number}" e.g. "CIPM decision 101-1" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/decisions-en/meeting-101(I).yml#L11)

CGPM meetings

"CGPM meeting {number}" e.g. "CGPM meeting 1" (https://github.com/metanorma/bipm-data-outcomes/blob/main/cgpm/meetings-en/meeting-01.yml#L3)
"CGPM meeting {year}" e.g. "CGPM meeting 1889"

CGPM meeting resolutions

"CGPM {meeting-locator} resolution {resolution id}" e.g. "CGPM meeting 3 resolution 1" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cgpm/meetings-en/meeting-03.yml#L12)

CCTF meeting

"CCTF meeting {number}" e.g. "CCTF meeting 5" (https://github.com/metanorma/bipm-data-outcomes/blob/main/cgpm/meetings-en/meeting-01.yml#L3)
"CGPM meeting {year}" e.g. "CGPM meeting 1889"

CCTF meeting resolutions

"CCTF {meeting-locator} resolution {resolution id}" e.g. "CCTF meeting 5 resolution 2" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cctf/meetings-en/meeting-5.yml#L11)

CIPM decisions

"CIPM decision {number}" e.g. "CIPM decision 101-1" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/decisions-en/meeting-101(I).yml#L11)

@ronaldtse does it mean for decisions we need to cite only resolutions elements? We don't need to cite metadata https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/decisions-en/meeting-101(I).yml#L3
Right?

does it mean for decisions we need to cite only resolutions elements? We don't need to cite metadata

When I cite a decision, I need:

metadata of the decision of the meeting
data of the decision

i.e.
https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/decisions-en/meeting-101(I).yml#L2-L22

You do not want CIPM id = 41-1946 for meetings, and = 41 for resolutions, that's nuts. The ID should be a number with no hyphens and years in it, especially if you're then going to use hyphens to indicate resolutions. And I think this amount of flexibility in identification is unsustainable and unnecessary. Your proposals are also not orthogonal: you have meeting x resolution y and resolution x-y, but you avoid the latter in favour of the wordier (and more error-prone) former.
I would instead recomment we implement only the identifiers below that I put a [NN] next to, with a consistent structure of BODY (meeting/resolution/decision) {meeting-id}(-{resolution/decisionid})?:

CIPM meetings:

"CIPM meeting {number}" e.g. "CIPM meeting 41" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/meetings-en/meeting-1946.yml#L3) [NN]
"CIPM meeting {year}" e.g. "CIPM meeting 1946"
"CIPM meeting {id}" e.g. "CIPM meeting 41-1946"

CIPM meeting resolutions

"CIPM {meeting-locator} resolution {resolution id}" e.g. "CIPM meeting 41 resolution 1"
"CIPM resolution {meeting id}-{resolution id}" e.g. "CIPM resolution 41-1" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/meetings-en/meeting-1946.yml#L11) [NN]

CIPM decisions

"CIPM decision {number}" e.g. "CIPM decision 101-1" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cipm/decisions-en/meeting-101(I).yml#L11) [NN]

CGPM meetings

"CGPM meeting {number}" e.g. "CGPM meeting 1" (https://github.com/metanorma/bipm-data-outcomes/blob/main/cgpm/meetings-en/meeting-01.yml#L3) [NN]
"CGPM meeting {year}" e.g. "CGPM meeting 1889"

CGPM meeting resolutions

"CGPM {meeting-locator} resolution {resolution id}" e.g. "CGPM meeting 3 resolution 1" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cgpm/meetings-en/meeting-03.yml#L12)
"CGPM resolution {meeting-id}-{resolution id}" e.g. "CGPM resolution 3-1" [added] [NN]

CCTF meeting

"CCTF meeting {number}" e.g. "CCTF meeting 5" (https://github.com/metanorma/bipm-data-outcomes/blob/main/cgpm/meetings-en/meeting-01.yml#L3) [NN]
"CGPM meeting {year}" e.g. "CGPM meeting 1889"

CCTF meeting resolutions

"CCTF {meeting-locator} resolution {resolution id}" e.g. "CCTF meeting 5 resolution 2" (https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cctf/meetings-en/meeting-5.yml#L11)

"CCTF resolution {meeting-id}-{resolution id}" e.g. "CGPM resolution 3-1" [added] [NN]

@opoudjis I'm happy with your proposal.
I just want to add that there are meetings with only a single resolution, hence the resolution identifier is just "0".
e.g. https://www.bipm.org/en/committees/cg/cgpm/1-1889/resolution-

Data: https://github.com/metanorma/bipm-data-outcomes/blob/d625c7216260970de3904e4979c12f0b34679e3c/cgpm/meetings-en/meeting-01.yml#L12

Citation format for CR
There are multiple citation formats in the original SI brochure:

Resolution of the 1st CGPM (1889)
(1954, Resolution 3; CR 79)
(18th CGPM (1987), Resolution 6, CR 100)
(CR, 94)

Which ones do we want to keep? e.g. long form, short form, abbreviated form?
What is the proper way to display a citation of the CGPM (assume we dropped the tome)?

short: “(CR, 34)” ?
longer: "(CGPM, 1889, p34)”?
full: “ Resolution of the 1st CGPM (1889)”?

Or can we only stick to 1 short representation and 1 full representation?
Citation format for PV
In the original SI brochure multiple citation formats are used:

(PV, 20, 119-122)
(CI-1989, PV, 57, 115)
(PV, 1879, 41)
CIPM, 1948 (PV, 21, 88)
Recommendation 5 (CI-1989) of the CIPM

Which ones do we want to keep? e.g. long form, short form, abbreviated form?
What is the proper way to display a citation of the CGPM (assume we dropped the tome)?

short: “(PV, 1879, 41)”?
longer: "(CIPM, 1948, p88)”?
full: “Recommendation 5 (CI-1989) of the CIPM”?

Or can we only stick to 1 short representation and 1 full representation?
Citation format for CCTF (or other committees)
There is only one CCTF Recommendation in the SI Brochure: "CCTF in its Recommendation CCTF 1 (2004)”.
What is the correct way of citing? Are there also short and full citations, in case this is used in other occasions?
e.g.

Recommendation 1 (CCTF, 2004)?
(Rec 1, CCTF, 2004)?
(CCTF, 2004-1)?

Differentiation between English and French citations of page numbers
The page numbers for English and French entries are sometimes identical but sometimes different.
e.g. CIPM 1989 Recommendation 5

French: Comptes rendus du 78e CIPM (1989), 1990, p26
English: Proceedings of the 78th CIPM (1989), 1990, p115

e.g. Resolution of the 1st CGPM (1889)

Comptes rendus de la 1e CGPM (1889), 1890, p34
Proceedings of the 1st CGPM (1889), 1890, p34

In the SI Brochure, we have to use the correct page when cited in English or French. This means we need to also provide the language for a citation entry.

@opoudjis I also want to add that there are two issues we need to be aware of.
The "year" of a meeting/recommendation does not necessarily point to a single year
This is from Janet Miles of BIPM:

The example you give (from p.159), "PV, 20, 119-122" for a CIPM Resolution from 1946, is the only one that is slightly more complicated - as the sessions held in 1945 and 1946 were considered part of the same meeting and the file on the "Older meeting reports" page is therefore labelled "1945, 1946" instead of just 1946.

The "year" of a resolution is often not the same "year" that the proceedings were published
https://www.bipm.org/en/committees/ci/cipm/41-1946

The year of the resolution is 1946, but the proceedings were published in 1947.

This is related to https://github.com/metanorma/metanorma-bipm/issues/164.

@andrew2net I discussed with @opoudjis and this task is for Relaton-BIPM:

From Janet Miles of the BIPM:
For the Resolutions/Recommendations/Decisions I think the following simple rule works without any ambiguity:
English:
[BODY] [Type] {number} (YEAR)

(where the number can be omitted if necessary, and the Type will be Resolution/Recommendation/Declaration as appropriate).
French (in French an additional dash is required as follows):
[BODY] - [Type] {number} (YEAR)

(and of course the Type has to be specified in French : Résolution,  Recommandation, Déclaration…)
Examples:
CGPM Resolution 6 (1987)
CIPM Resolution (1948)
CCDS Recommendation 2 (1970)

We can omit the official citation (CR, PV etc.) since the Brochure will provide links to the relevant pages on the BIPM website, and these contain the citation details.
Within the notes to the Resolutions there is no need to make any changes. For example in the link you provide (for CGPM Resolution (1889)) we can leave the phrasing in the note as is
“as abrogated in 1960 by the 11th CGPM (Resolution 6)”.

Can you please help make these items available via Relaton-BIPM?

From Janet Miles of the BIPM:
For the Resolutions/Recommendations/Decisions I think the following simple rule works without any ambiguity:

@ronaldtse I don't see a "Recommendation" attribute in the source files.
As I understand the source has following cases:

CIPM decision 101 (2012)
CIPM decision 101 (2012) resolution 1
CIPM meeting 41 (1946)
CIPM meeting 41 (1946) resolution 1
CGMP meeting 1 (1889)
CGMP meeting 1 (1889) resolution 0
CCTF meeting 5 (1970)
CCTF meeting 5 (1970) resolution 2

What is "Recommendation" type mean?
Should we create separated documents for each resolution or create relation for them? What type of relation should it be?

CIPM decision 101 (2012)

This is "CIPM Meeting 101".

CIPM decision 101 (2012) resolution 1

This is "CIPM Meeting 101 Decision 1", shortened as "CIPM Decision 1 (2012). The given label is "Decision CIPM/101-1 (2012)"

CIPM meeting 41 (1946)

This is "CIPM Meeting 41".

CIPM meeting 41 (1946) resolution 1

This is "CIPM Resolution 1 (1946)".

CGMP meeting 1 (1889)

"CPGM" instead of "CGMP". This is "CGPM Meeting 1".

CGMP meeting 1 (1889) resolution 0

This is "CGPM Resolution (1889)" as there is no number to the single resolution.

CCTF meeting 5 (1970)

This is "CCDS Meeting 5". As shown on the page, CCTF used to be CCDS.

CCTF meeting 5 (1970) resolution 2

This is "CCDS Recommendation 2 (1970)". All CCTF outcomes are called "Recommendations".

What is "Recommendation" type mean?

BIPM has clarified that "CCTF meeting 5 (1970) resolution 2" is to be called "CCDS Recommendation 2 (1970)".

Should we create separated documents for each resolution or create relation for them? What type of relation should it be?

I think we should create the following objects for citation:

Meeting
Resolution/Decision/Recommendation

For relationships, a meeting contains resolutions/decisions/recommendations.

@ronaldtse for documents like the CIPM Meeting 101 (2012) there are two sessions. Do we need to have two documents like "CIPM Meeting 101-1 (2012)" and "CIPM Meeting 101-2 (2012)", or one "CIPM Meeting 101 (2012)" with two "hasPart" relations?
In the previous discussion, Nick asked me to create one document with relation.

@ronaldtse for documents like the CIPM Meeting 101 (2012) there are two sessions. Do we need to have two documents like "CIPM Meeting 101-1 (2012)" and "CIPM Meeting 101-2 (2012)", or one "CIPM Meeting 101 (2012)" with two "partOf" relations?

The proper way to reference should be "partOf", and we should have separate instances of Meeting 101-1 and 101-2:
meeting-101
  contains: meeting-101-1
  contains: meeting-101-2

In addition, I think we should rename the files:

https://github.com/relaton/relaton-data-bipm/blob/master/data/CIPM-DECISION-35-2012.yaml
https://github.com/relaton/relaton-data-bipm/blob/master/data/CGPM-RESOLUTION-11-2007.yaml

It is strange to see:
CIPM-DECISION-35-2012
CIPM-RESOLUTION-7-2012

I'd rather see:
cipm/decision/35-2012.yaml
cipm/resolution/07-2012.yaml

And the IDs, like: BIPMCGPMResolution11(2007) are very strange... can we use a better format?
https://github.com/relaton/relaton-data-bipm/blob/4d3b678695f9075ce451d6a8145071cd0897d6d5/data/CGPM-RESOLUTION-11-2007.yaml#L2

@ronaldtse there are documents with identical url
cipm/decisions-en/meeting-102(I) has identical url and title to cipm/meetings-en/meeting-2013
and
cipm/decisions-en/meeting-104(I) has url and title identical to cipm/meetings-en/meeting-2015
How should we handle them?

@andrew2net from the filenames, you can see that they are different types of content:

Decisions made in the meeting
Resolutions of the meeting

Should we make decision a specific type of a resolution?
e.g. from:
- dates:
  - '2013-06-21'
  title: Decision CIPM/102-1 (2013)

To this
- dates:
  - '2013-06-21'
  type: decision
  title: Decision CIPM/102-1 (2013)

Oh, and we also have this https://github.com/metanorma/bipm-data-outcomes/issues/6 to mark a resolution of type: recommendation. So yes we should do this.

Should we make decision a specific type of a resolution?

@ronaldtse the types allowed by the grammar are:
DocumentType =
"brochure" |
"mise-en-pratique" |
"rapport" |
"monographie" |
"guide" |
"meeting-report" |
"technical-report" |
"working-party-note" |
"strategy" |
"cipm-mra" |
"resolution"

There is only resolution type in this list. We need decision and recommendation. Should we update the grammar? Or can we map the existed gramma types to decision and recommendation?
I've pushed updated dataset, review it please.
We also have data/SI-BROCHURE.yaml and data/GUIDE-CCL-GD-MEP-1.yaml in this repo. Should we update them?

We need decision and recommendation. Should we update the grammar?

Yes we need to update the grammar. Could you help do that? Thanks!

We also have data/SI-BROCHURE.yaml and data/GUIDE-CCL-GD-MEP-1.yaml in this repo. Should we update them?

What do we need to do with them? The SI Brochure is a brochure, the GUIDE-CCL... is a guide?

@andrew2net personally I prefer lowercase names than uppercase names. However, I believe an indexed search is required for locating items in GitHub datasets.


Update to latest Rosetta specification

The most recent specification has some useful updates that previously required fiddling with metadata. I guess we need to preserve backwards compatibility now and still keep the old approach for a while though.

Done in #261.


Use C++11 ranged for-loops where possible

This uses C++11 ranged for-loops when possible to simply the code and make it clearer when iterators are needed and not.
I wasn't sure how to build the code, so I couldn't directly test this.

I wasn't sure how to build the code, so I couldn't directly test this.

Purely out of interest, what motivated you to do this if you aren't using this code?

My apologies. Vulkan is used within PyTorch, where I've been working on increasing code safety via this loop transformation. I'll close this.

@expipiplus1 : Vulkan is used in PyTorch. I've been trying to improve code safety/modernity there and like to upstream that.
When following the build directions for this repo I see the following when running cmake:
CMake Error at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find Vulkan (missing: Vulkan_LIBRARY Vulkan_INCLUDE_DIR)

which currently prevents me from checking compilation on this code.

I introduced usage for range-based for loops wherever I could. Thank you for this suggestion and sorry it took so long.
Not every place could use this form as sometimes direct access to the iterator is needed.


Set toxenvs in tox_configure instead of during parsing

@ryanhiebert - I'll add comments later, just wanted to submit this. I tried to break the changes into discrete commits so that it's a little easier to review.
Note that this PR hinges on being able to change default_toxenv to be called from tox_configure instead of tox_addoption. The tests largely seem to work, minus a few issues (also see the last commit).

Also, not sure why travis isn't picking up the PR (maybe it only checks master?)

That's right, it only checks master, to avoid duplicate builds for pull requests opened from branches on this repository. Mind opening another PR to master? I've reviewed this already, but I'll hold off on commenting until we've got the right PR open.

Hilariously enough, the new PR has the same commit hashes, so the checks are also applied to this PR.

haha.


Added The Landing Pages Folder

An updated live URL for the landing pages https://smartlearn.netlify.app

Oh, it's approved already. Thanks.


Implement bitwise SSE ops & _mm_cmp*_ss

Implement SSE bitwise AND, OR, AND-NOT, and XOR.
Implement all variants of _mm_cmp*_ss.

Thanks! Mind rebasing now as well?

👍


[App Config] Run Publish Samples Command

Packages impacted by this PR
app-configuration
Issues associated with this PR
Publish latest samples for release
Describe the problem that is addressed by this PR
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


XGBOOST Custom Splitting Criterion

Dear Authors,
Is there a way to custom the split criterion of trees? IF not, where should we start digging down after forking XGBOOST please? Is it Python based ? or Cython based?
Cheers,

It's c++/cuda based. https://github.com/dmlc/xgboost/blob/master/src/tree/split_evaluator.h

Superb! Cheers for the promptness, will update later if ever we do struggle with something but after a skim-read it looks very-doable!
Have a great day, thanks again!


DDL: support other union types

Aka product types aka JSON Schema enums. Follow on from #136

Migrated to https://github.com/snowplow/iglu/issues/246


Prior sub-spaces

API-chaning prior subspaces to allow general prior distributions, e.g. that have no quantile.

done


[Config option to turn off "Team home"]

Is your feature request related to a problem? Please describe.
I've been looking for a teams plugin that doesn't feature any teleportation commands.
Describe the solution you'd like
Addition of a config option to turn off teleportation via the team home command, or a permissions node for it

/team home and /team sethome can already be disabled.
To do so, all you need to do is remove the permission node from the default group. (they have the permission node by default)
If you are using luckperms, add the permission node and set it to false (i'm not too familiar with other permission plugins, so I don't think I can be of much help.
To save typing out the permission nodes again check the wiki permissions page to find the permission nodes you are looking for.


Failed to retrieve conntrack stats on an armv5 based Synology NAS

Host operating system: output of uname -a
Linux DS <IP_ADDRESS> #25556 Thu Jul 1 14:25:48 CST 2021 armv5tel GNU/Linux synology_88f6282_411
node_exporter version: output of node_exporter --version
node_exporter, version 1.5.0 (branch: HEAD, revision: https://github.com/prometheus/node_exporter/commit/1b48970ffcf5630534fb00bb0687d73c66d1c959)
build user: root@6e7732a7b81b
build date: 20221129-19:00:13
go version: go1.19.3
platform: linux/arm
As originally reported in this ticket, the conntrack collector on the node_exporter seems to have an issue because of some expected fields beeing missing.
The error meassage with node_exporter v 1.2.2 looks as following (node_exporter log output):
ts=2023-03-13T19:04:46.789Z caller=collector.go:169 level=error msg="collector failed" name=conntrack duration_seconds=0.000592692 err="failed to retrieve conntrack stats: failed to read conntrack stats from \"/proc/net/stat/nf_conntrack\": invalid conntrackstat entry, missing fields"
With version 1.5.0 it seems to be even worse:
ts=2023-03-13T21:26:20.985Z caller=collector.go:169 level=error msg="collector failed" name=conntrack duration_seconds=0.000755877 err="failed to retrieve conntrack stats: failed to read conntrack stats from \"/proc/net/stat/nf_conntrack\": invalid conntrackstat entry, missing fields"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x66de9c]

goroutine 59 [running]:
github.com/prometheus/node_exporter/collector.parseNetlinkStats({0x1209ec0, 0x3, 0x3}, 0x105dda8, {0x8be790, 0x105dd70})
        /home/dietpi/node_exporter/node_exporter-1.5.0/collector/netdev_linux.go:69 +0x1dc
github.com/prometheus/node_exporter/collector.netlinkStats(0x105dda8, {0x8be790, 0x105dd70})
        /home/dietpi/node_exporter/node_exporter-1.5.0/collector/netdev_linux.go:52 +0x114
github.com/prometheus/node_exporter/collector.getNetDevStats(0x105dda8, {0x8be790, 0x105dd70})
        /home/dietpi/node_exporter/node_exporter-1.5.0/collector/netdev_linux.go:35 +0x40
github.com/prometheus/node_exporter/collector.(*netDevCollector).Update(0x105dda0, 0x11b6a80)
        /home/dietpi/node_exporter/node_exporter-1.5.0/collector/netdev_common.go:113 +0x34
github.com/prometheus/node_exporter/collector.execute({0x7be599, 0x6}, {0x8bebf0, 0x105dda0}, 0x11b6a80, {0x8be7f4, 0x11144a0})
        /home/dietpi/node_exporter/node_exporter-1.5.0/collector/collector.go:161 +0x40
github.com/prometheus/node_exporter/collector.NodeCollector.Collect.func1({0x7be599, 0x6}, {0x8bebf0, 0x105dda0})
        /home/dietpi/node_exporter/node_exporter-1.5.0/collector/collector.go:152 +0x54
created by github.com/prometheus/node_exporter/collector.NodeCollector.Collect
        /home/dietpi/node_exporter/node_exporter-1.5.0/collector/collector.go:151 +0x7c

Content of  /proc/net/stat/nf_conntrack:
cat /proc/net/stat/nf_conntrack

entries  searched found new invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error  expect_new expect_create expect_delete
0000002b  0003159f 02e6786a 00142562 0001bf93 00e1a051 00142537 000b8fe0 000b900b 00000000 00000000 00000000 0001b46a  00000000 00000000 00000000

You're actually seeing two separate errors in v1.5.0.
The original "invalid conntrackstat entry, missing fields" error is present in both v1.2.2 and v1.5.0, since procfs expects /proc/net/stat/nf_conntrack to contain 17 fields, which apparently it doesn't on 2.6 kernels.
The panic that you see in v1.5.0 is due to node_exporter v1.4.0 and later using kernel netlink to get netdev stats (https://github.com/prometheus/node_exporter/pull/2074). You could try reverting to the previous method of parsing /proc/net/dev by specifying --collector.netdev.netlink=false.

Your /proc/net/stat/nf_conntrack appears to be missing one field at the end (search_restart), based on the test fixtures used to test net_conntrackstat.go:
entries  searched found new invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error  expect_new expect_create expect_delete search_restart
00000021  00000000 00000000 00000000 00000003 0000588a 00000000 00000000 00000000 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000

According to iproute manpages:

search_restart Number of conntrack table lookups which had to be restarted due to hashtable resizes.

This field first appeared in kernel 2.6.35.


Mailhog not working with Traefik

Hi, I have some Drupal sites (local sites) working with the previous version of Docker4Drupal, but I started using Traefik and all the containers work just fine, but not Mailhog.
Browser says ERR_CONNECTION_REFUSED
Has anyone experienced something like this?
Thanks!

There was a bug in initial 2.0.0 version with incorrect port specified for mailhog service. Make sure you have traefik.port=8025 under mailhog labels.

I have it like that, but it's not running (at least I cannot access it via Browser)

How are you trying to access it? As mailhog.drupal.docker.localhost?
Few suggestions:

Make sure traefik container is up and running
Go to traefik admin UI (port 8080) and look up mailhog status
Add public port to mailhog (8025:8025) and check if it works when you access it directly (localhost:8025) without traefik

Hi @csandanov, thanks for your help.

Yes, Traefik is up and running (all the other services work as expected)
Mailhog status is fine in the Traefik admin UI (just like the others)
I added the port and yes, I can access it directly without Traefik.

I'm using Docker CE Version 17.03.0-ce-mac2 (for MAC)
Best,

I have the same version and I can't reproduce it. Paste here your compose file and output of curl -I mailhog.domain

This is working, I wasn't using it the right way (maybe a better documentation would be fine).
The Mailhog should be accessed using the port 8000
http://mailhog.drupal.docker.localhost:8000
Thanks

I am still having this problem. I do not understand why. I am have docker version 18.09.7 build CE for Linux and followed the checks mentioned above, except for the port=8000. I did not understand that part.
Your assistance is greatly appreciated. Thank you.