Update MSYS2 runtime to 2.6.1

This Pull Request brings the MSYS2 runtime up-to-date with Cygwin 2.6.1.
While at it, it also addresses two bugs in the POSIX->Windows conversion and backports a fix necessary to adjust for upcoming 64-bit Windows versions.

To make it easier to validate the changes in the patch sets, the first commit adds a script to generate the patch sets from the current HEAD in src/msys2-runtime.
The 2nd, 3rd and 5th commits used that script to re-generate the patch set from tags pr-786-step-1, pr-786-step-3 and pr-786-step-3 (that I pushed to https://github.com/dscho/msys2-runtime), respectively.
I realize that it is still pretty cumbersome to validate those changes, thanks to the way MSYS2 runtime's patch set is handled these days. If there is anything I can do on my side to make it less cumbersome, please let me know.

Seems AppVeyor is not able to build the MSYS2 runtime, even if the very same code works here. I cannot even figure out from AppVeyor's output what the problem is. Can anybody enlighten me?

Looks like the actual command that failed was at (https://ci.appveyor.com/project/Alexpux/msys2-packages/build/1.0.659#L2432)[line 2432]:
x86_64-w64-mingw32-gcc -s -g -O2 -pipe -ggdb -nostdlib -Wl,-shared -e DllMain -o cyglsa64.dll cyglsa64.o /c/projects/msys2-packages/msys2-runtime/src/msys2-runtime/winsup/lsaauth/cyglsa64.def -ladvapi32 -lkernel32 -lntdll
/opt/lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/bin/ld: /opt/lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libadvapi32.a(ADVAPI32.dll): string not null terminated in ILF object file.
/opt/lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/bin/ld: /opt/lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libadvapi32.a(ADVAPI32.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archive
/opt/lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libadvapi32.a: error adding symbols: File format not recognized
collect2: error: ld returned 1 exit status
[snip]
make[3]: *** [Makefile:75: cyglsa64.dll] Error 1
make[3]: Leaving directory '/c/projects/msys2-packages/msys2-runtime/src/build-x86_64-pc-msys/x86_64-pc-msys/winsup/lsaauth'
make[2]: *** [Makefile:81: lsaauth] Error 1
make[2]: *** Waiting for unfinished jobs....
[big snip]
make[1]: *** [Makefile:9464: all-target-winsup] Error 2
make[1]: Leaving directory '/c/projects/msys2-packages/msys2-runtime/src/build-x86_64-pc-msys'
make: *** [Makefile:883: all] Error 2

0002-Rename-DLL-from-cygwin-to-msys.zip
small help?

I don't understand, @PiotrVV. Are you asking for help, or trying to give help?

give help.

Yeah. :) I see some patches inside. Can you please explain what they do, or what you changed?

/opt/lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libadvapi32.a: error adding symbols: File format not recognized collect2: error: ld returned 1 exit status

@elieux thank you for digging that out (I was unable to find it in a browser). That error does not occur here, maybe there is something totally going wrong only in AppVeyor?

This is error in patch long time ago.

@dscho MSYS2 with AppVeyor isn't bug free. It could be random unreproducible error.

@PiotrVV Unfortunately, this is not helpful at all.
For the record, this is the diff relative to the tip of my PR (see below for my analysis):
diff --git a/msys2-runtime/0002-Rename-DLL-from-cygwin-to-msys.patch b/msys2-runtime/0002-Rename-DLL-from-cygwin-to-msys.patch
index bab2ffe2..6bd379c0 100644
--- a/msys2-runtime/0002-Rename-DLL-from-cygwin-to-msys.patch
+++ b/msys2-runtime/0002-Rename-DLL-from-cygwin-to-msys.patch
@@ -1,6 +1,6 @@
-From 5f1c5ffe5310a250b0552b392c3d9d01652a80a7 Mon Sep 17 00:00:00 2001
-From: Johannes Schindelin<EMAIL_ADDRESS>-Date: Fri, 13 Jan 2017 12:40:58 +0100
+From b6e6cb27503d4cae9e7346dc1bbed2e5e9972d35 Mon Sep 17 00:00:00 2001
+From: Alexpux<EMAIL_ADDRESS>+Date: Tue, 5 Apr 2016 10:15:20 +0300
 Subject: [PATCH 02/24] Rename DLL from cygwin to msys

 ---
@@ -495,23 +495,31 @@ index 3ec3249..3d2eaf3 100644
  %%
  #undef BRACK
 diff --git a/winsup/cygwin/dlfcn.cc b/winsup/cygwin/dlfcn.cc
-index 159d4fe..7280bab 100644
+index 255a6d5..4a90293 100644
 --- a/winsup/cygwin/dlfcn.cc
 +++ b/winsup/cygwin/dlfcn.cc
-@@ -147,8 +147,13 @@ collect_basenames (pathfinder::basenamelist & basenames,
-   /* If the basename starts with "lib", ... */
-   if (!strncmp (basename, "lib", 3))
-     {
+@@ -144,12 +144,20 @@ collect_basenames (pathfinder::basenamelist & basenames,
+       ext = ".dll";
+       extlen = 4;
+     }
 +#ifdef __MSYS__
+   /* If the basename starts with "lib", ... */
+-  if (!strncmp (basename, "lib", 3))
++  if (!strncmp (basename, "lib", 5))
++  {
 +      /* ... replace "lib" with "msys-", before ... */
-+      basenames.appendv ("msys-", 3, basename+3, baselen-3, ext, extlen, NULL);
++      basenames.appendv ("msys-", 5, basename+5, baselen-5, ext, extlen, NULL);
++  }
 +#else
++	if (!strncmp (basename, "lib", 3))
+     {
        /* ... replace "lib" with "cyg", before ... */
        basenames.appendv ("cyg", 3, basename+3, baselen-3, ext, extlen, NULL);
-+#endif
      }
++#endif
    /* ... using original basename with new suffix. */
    basenames.appendv (basename, baselen, ext, extlen, NULL);
+ }
 diff --git a/winsup/cygwin/dll_init.cc b/winsup/cygwin/dll_init.cc
 index 0fe5714..418e615 100644
 --- a/winsup/cygwin/dll_init.cc
@@ -560,7 +568,7 @@ index f464618..e6f560f 100644
  	  w32len = cygheap->installation_key.Length / sizeof (WCHAR);
  	  if (w32len
 diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
-index 743c732..2dd355a 100644
+index 0f5a890..2677ae7 100644
 --- a/winsup/cygwin/exceptions.cc
 +++ b/winsup/cygwin/exceptions.cc
 @@ -500,14 +500,14 @@ try_to_debug (bool waitloop)
@@ -581,7 +589,7 @@ index 743c732..2dd355a 100644
  	  break;
  	}
 diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
-index 1505b8c..96a3210 100644
+index aba469f..266927f 100644
 --- a/winsup/cygwin/fhandler_tty.cc
 +++ b/winsup/cygwin/fhandler_tty.cc
 @@ -464,7 +464,11 @@ fhandler_pty_slave::open (int flags, mode_t)
@@ -732,7 +740,7 @@ index 56b4363..6bc948a 100644

  #endif /* __CYGWIN_CYGWIN_DLL_H__ */
 diff --git a/winsup/cygwin/include/cygwin/version.h b/winsup/cygwin/include/cygwin/version.h
-index 6ba602e..2745496 100644
+index 820d28b..1bde8c7 100644
 --- a/winsup/cygwin/include/cygwin/version.h
 +++ b/winsup/cygwin/include/cygwin/version.h
 @@ -487,7 +487,11 @@ details. */
@@ -861,7 +869,7 @@ index 7e763e0..36b4d78 100755
    "END_CYGWIN_VERSION_INFO\n\0";
  cygwin_version_info cygwin_version =
 diff --git a/winsup/cygwin/pinfo.cc b/winsup/cygwin/pinfo.cc
-index 9b74442..3e73196 100644
+index 1ce6809..7dbd57e 100644
 --- a/winsup/cygwin/pinfo.cc
 +++ b/winsup/cygwin/pinfo.cc
 @@ -188,7 +188,7 @@ pinfo::maybe_set_exit_code_from_windows ()
@@ -912,7 +920,7 @@ index c250fdc..a230b35 100644
    va_list args;

 diff --git a/winsup/cygwin/sec_auth.cc b/winsup/cygwin/sec_auth.cc
-index 50823c6..acd9a95 100644
+index 468d048..e972e4a 100644
 --- a/winsup/cygwin/sec_auth.cc
 +++ b/winsup/cygwin/sec_auth.cc
 @@ -764,7 +764,7 @@ verify_token (HANDLE token, cygsid &usersid, user_groups &groups, bool *pintern)
@@ -956,7 +964,7 @@ index 50823c6..acd9a95 100644
    ts.SourceIdentifier.LowPart = 0x0103;

 diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
-index 13bb309..41c1a59 100644
+index ba7c743..0ff0b71 100644
 --- a/winsup/cygwin/syscalls.cc
 +++ b/winsup/cygwin/syscalls.cc
 @@ -365,7 +365,7 @@ try_to_bin (path_conv &pc, HANDLE &fh, ACCESS_MASK access, ULONG flags)
@@ -1225,7 +1233,7 @@ index 0ad73fb..63dd4ca 100644

  .PHONY: warn_dumper
 diff --git a/winsup/utils/cygcheck.cc b/winsup/utils/cygcheck.cc
-index d1e27b7..050a268 100644
+index f6adf51..50a68ec 100644
 --- a/winsup/utils/cygcheck.cc
 +++ b/winsup/utils/cygcheck.cc
 @@ -68,8 +68,7 @@ static const char *known_env_vars[] = {
@@ -1430,7 +1438,7 @@ index c83b764..42ffbfd 100644
    wcscpy (dllpath, sysdir);
    wcscpy (dllpath + sysdir_len, dll);
 diff --git a/winsup/utils/path.cc b/winsup/utils/path.cc
-index a76cf76..4da4288 100644
+index 4877f6a..dc71dae 100644
 --- a/winsup/utils/path.cc
 +++ b/winsup/utils/path.cc
 @@ -598,14 +598,14 @@ read_mounts ()
@@ -1495,7 +1503,7 @@ index 548b89a..09ee26d 100644
      "The \"-b\" means 'skip the help pages'.  You can omit this until you're\n"
      "familiar with the report layout.  The gprof documentation explains\n"
 diff --git a/winsup/utils/strace.cc b/winsup/utils/strace.cc
-index 4046cce..50ac4a7 100644
+index 5d4a23d..0c8d75e 100644
 --- a/winsup/utils/strace.cc
 +++ b/winsup/utils/strace.cc
 @@ -282,7 +282,7 @@ load_cygwin ()
diff --git a/msys2-runtime/0019-strace.cc-Don-t-set-MSYS-noglob.patch b/msys2-runtime/0019-strace.cc-Don-t-set-MSYS-noglob.patch
index 546d8851..2c8f1dd4 100644
--- a/msys2-runtime/0019-strace.cc-Don-t-set-MSYS-noglob.patch
+++ b/msys2-runtime/0019-strace.cc-Don-t-set-MSYS-noglob.patch
@@ -1,6 +1,6 @@
-From 070d0f27a59494acb4a8823d5e085c4f6d2285b5 Mon Sep 17 00:00:00 2001
-From: Johannes Schindelin<EMAIL_ADDRESS>-Date: Fri, 13 Jan 2017 12:41:51 +0100
+From 61c2a851d4472d1f251954bd8f077202147eccfe Mon Sep 17 00:00:00 2001
+From: Ray Donnelly<EMAIL_ADDRESS>+Date: Sun, 23 Aug 2015 20:47:30 +0100
 Subject: [PATCH 19/24] strace.cc: Don't set MSYS=noglob

 Commit message for this code was:
@@ -22,11 +22,11 @@ See quoted () comment:
 "This must have been run from a Windows shell, so preserve
  quotes for globify to play with later."
 ---
- winsup/utils/strace.cc | 20 +++++++++++++++++++-
- 1 file changed, 19 insertions(+), 1 deletion(-)
+ winsup/utils/strace.cc | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)

 diff --git a/winsup/utils/strace.cc b/winsup/utils/strace.cc
-index 50ac4a7..484eacb 100644
+index 0c8d75e..f7c98bd 100644
 --- a/winsup/utils/strace.cc
 +++ b/winsup/utils/strace.cc
 @@ -352,11 +352,28 @@ create_child (char **argv)
@@ -50,23 +50,10 @@ index 50ac4a7..484eacb 100644
 +  See quoted () comment:
 +  "This must have been run from a Windows shell, so preserve
 +     quotes for globify to play with later."
-
++*/
    const char *cygwin_env = getenv ("MSYS");
    const char *space;

--  if (cygwin_env && strlen (cygwin_env) <= 256) /* sanity check */
-+  if (cygwin_env && strlen (cygwin_env) <= 256) // sanity check
-     space = " ";
-   else
-     space = cygwin_env = "";
-@@ -364,6 +381,7 @@ create_child (char **argv)
- 				  + strlen (space) + strlen (cygwin_env));
-   sprintf (newenv, "MSYS=noglob%s%s", space, cygwin_env);
-   _putenv (newenv);
-+*/
-   ret = CreateProcess (0, one_line.buf,	/* command line */
- 		       NULL,	/* Security */
- 		       NULL,	/* thread */
 --
 2.9.0

So it seems that @PiotrVV tries to point out that there is an incorrect change in authorship (my rebases somehow changed authorship when I fixed the merge conflicts).
The changes in the file SHA-1s are completely bogus and incorrect.
There seem to be only two real, i.e. functional, changes in the diff:

 +#ifdef __MSYS__
+   /* If the basename starts with "lib", ... */
+-  if (!strncmp (basename, "lib", 3))
++  if (!strncmp (basename, "lib", 5))
++  {
 +      /* ... replace "lib" with "msys-", before ... */
-+      basenames.appendv ("msys-", 3, basename+3, baselen-3, ext, extlen, NULL);
++      basenames.appendv ("msys-", 5, basename+5, baselen-5, ext, extlen, NULL);
++  }
 +#else
++      if (!strncmp (basename, "lib", 3))
+     {

This change is incorrect. It would replace the condition that looks for the prefix "lib" to verify that the first five bytes are matching "lib", which is patently wrong. It is no surprise that the change to replace the first five characters by "msys-" is wrong, too.
What is correct is that my patch should have changed the first 3 in the appendv() call (and only the first one) to 5.
The second functional change is:
@@ -50,23 +50,10 @@ index 50ac4a7..484eacb 100644
 +  See quoted () comment:
 +  "This must have been run from a Windows shell, so preserve
 +     quotes for globify to play with later."
-
++*/
    const char *cygwin_env = getenv ("MSYS");
    const char *space;

--  if (cygwin_env && strlen (cygwin_env) <= 256) /* sanity check */
-+  if (cygwin_env && strlen (cygwin_env) <= 256) // sanity check
-     space = " ";
-   else
-     space = cygwin_env = "";
-@@ -364,6 +381,7 @@ create_child (char **argv)
-                                 + strlen (space) + strlen (cygwin_env));
-   sprintf (newenv, "MSYS=noglob%s%s", space, cygwin_env);
-   _putenv (newenv);
-+*/

In other words, it tries to not comment-out the entire noglob setting. However, this is what the original patch does: it comments out the entire block up to, and including, the _putenv() call.
I will fix the attributions as well as the replacement (after digging a bit deeper and verifying that the second parameter to appendv() specifies the length of the first parameter) and force-push.

This is error in patch long time ago.

@PiotrVV these non-explanations do not fail to frustrate everybody involved.

As promised, I amended the latest commit after fixing the authorship and the parameter to the appendv() call.

Looks like the actual command that failed was at line 2432:

@elieux I actually think that the real culprit comes much earlier:
      3 [main] pacman (2156) C:\msys64\usr\bin\pacman.exe: *** fatal error - cygheap base mismatch detected - 0x180339400/0x1802FE408.

In other words, Pacman fails to update, and therefore the files in question may not actually be correct (I am still puzzled that the linker complains about an invalid file format, obsolete file versions should still have the correct file format, after all...).

@elieux I actually think that the real culprit comes much earlier:

[snip]

In other words, Pacman fails to update, and therefore the files in question may not actually be correct (I am still puzzled that the linker complains about an invalid file format, obsolete file versions should still have the correct file format, after all...).

I would argue that this error is not significant. The failure occurs because bash&msys2-runtime are updated preceding the post-install script for filesystem. This script only displayed a few warnings AFAIK. The update process should be otherwise successful.
I agree with @mati865 that it could very well be a random bug. If there was a way to re-run the build on AppVeyor, I'd suggest that (maybe push to the PR branch?).

I agree that it is difficult to review diffs of diffs, and I really wish that msys2-runtime would not have moved to patches, but rather to merging rebases.

I really think that storing patches in the PKGBUILD repository is the better way (compared to just pointing to alexpux/cygwin#msys2-master), but maybe the process can be this: Send and accept (rebase) PRs to alexpux/cygwin and then internally regenerate patches in alexpux/msys2-packages.

I really think that storing patches in the PKGBUILD repository is the better way (compared to just pointing to alexpux/cygwin#msys2-master),

It may be seen as "more correct", but it sure makes it really hard to review, or for that matter, generate PRs.
To counter that "better way", I would like you to understand that Git was written to avoid "tarballs and patches", yet that is exactly what you described as better way...

but maybe the process can be this: Send and accept (rebase) PRs to alexpux/cygwin and then internally regenerate patches in alexpux/msys2-packages.

This makes it even harder, as you simply cannot open a non-conflicting PR after rebasing.
Unless, that is, you followed my link to the description of the "merging rebase", but from your post it does not look like it.

Yes, I didn't have much time to research but wanted to respond nevertheless :/. Let's take this off-topic discussion elsewhere (you choose the communication platform).
@alexpux, is the PR okay to merge?

Yes, I didn't have much time to research but wanted to respond nevertheless :/. Let's take this off-topic discussion elsewhere (you choose the communication platform).

@elieux assuming you were addressing me: I opened a private chat on Gitter.
But let me state for the public record, that I will use whatever scheme you choose to use, and I did not mean to prod you into changing it. I did have to point out the shortcomings of the chosen route, is all.

@Alexpux, is the PR okay to merge?

I would also like to know that. In the negative case, I would further like to know what needs to be fixed. I have more critical ("Bad address") bug fixes coming, so this here PR is a blocker.

I will look at it on next week. I see that cygwins 2.6.1 release is buggy for many users so maybe wait for 2.6.2 release.

@dscho , I'm rebasee my patches in Cygwin_Branches repository to 2.6.1. Lets close this pull request and I will add rebased patches from that repo. Then you will create new pull request with changes that not in my patches and clarify why we need it.

Then you will create new pull request with changes that not in my patches and clarify why we need it.

Sure. Just note that this is another downside of the patch-based workflow you chose: it cost me a substantial amount of time to get the PR this far, and now you just throw all the work away, asking me to spend even more time on the problem. It may be nice and convenient for you, but I have to admit that that does not match my experience.

For msys2-runtime I'm rebase patches directly in cygwin repo and then place patches to msys2-runtime PKGBUILD with git format-patch. This is how I'm do releases for msys2-runtime

So if you want apply any patches to it maybe need create PR on my Cygwin repo for msys2-master branch

So if you want apply any patches to it maybe need create PR on my Cygwin repo for msys2-master branch

That is unfortunately not good enough: I have done that in the past with patches that were clearly intended to be squashed into incorrect earlier patches, but now we have an ever-growing list of patches that introduce bugs only to fix them in a later patch.

So if you want apply any patches to it maybe need create PR on my Cygwin repo for msys2-master branch

That is unfortunately not good enough: I have done that in the past with patches that were clearly intended to be squashed into incorrect earlier patches, but now we have an ever-growing list of patches that introduce bugs only to fix them in a later patch.

I think this conversation demonstrates clearly that the direction I had in mind for the MSYS2 runtime to pick up Git for Windows' patches, and eventually for Git for Windows to replace MSYS2's mingw-w64-git, is not viable. The positive side of this is that it saves me tons of time :smile:

Ok, no problem.

In any case I don't understand what the problem cherry-picking patches from my Cygwin repo after rebasing.

In any case I don't understand what the problem cherry-picking patches from my Cygwin repo after rebasing.

The problem is that I cannot contribute changes that will result in a new msys2-runtime in a timely manner. Not a big problem, though: I'll just keep the fork of Git for Windows running indefinitely.

I mean that patches need to be rebased when we switch to new release, not between rebuilds of the same runtime


Handle project having experiments with no data

Fixes:
When I'm trying to show experiments/plots, that "You project contains no data".
But I have some... experiments and those plots
Any ideas why is VSCode behave like this?  Also, no clear what should I do here

From https://iterativeai.slack.com/archives/CB41NAL8H/p1701257451702629

This updates the experiments tree but the webview is still showing the "has no data" message:

@julieg18 what data/setup are you using?


Add the ability to register and receive webhooks

Provides comprehensive Webhook support for Solidus, with a simple and
powerful way to register them and route payloads to appropriate
actions, either synchronous or delayed.
See the README for more details on how it works.

I live this!!!!!


Timestamp.now() fails when using Firestore Emulator

When using the emulator gcloud beta emulators firestore start or firebase emulators:start --only firestore creating a record using the Timestamp value fails.
Environment details

OS: Testing on MacOS
Node.js version: v10.16.0
npm version:6.13.1
@google-cloud/firestore version: 2.6.0

Steps to reproduce
In my unit tests, I am setting up my database via:
import {initializeAdminApp} from '@firebase/testing';
const firebase = initializeAdminApp({ projectId: "my-project" });
 // @ts-ignore
 setDb(firebase.firestore());

Annoyingly, firebase testing doesn't match @google-cloud/firestore as if you don't use ts-ignore you get this error:

Type 'Firestore' is missing the following properties from type 'Firestore': getAll, listCollections

In my actual function:
import { Timestamp } from '@google-cloud/firestore';
const id="someTestId";
const docRef = db.collection(COLLECTION_NAME).doc(id);
const data = {
    id,
    name: "my name",
    created: Timestamp.now(),
    modified: Timestamp.now(),
};
await docRef.set(data);

This will result in the error:

FirebaseError: Function DocumentReference.set() called with invalid data. Unsupported field value: a custom object (found in field created)

This code works perfectly on the actual Cloud Firebase server.
Now, I am using @google-cloud/firestore in production. I suppose I could switch over to firebase-admin and try there, but I would prefer to keep this in Cloud Firestore over Firebase Firestore.
All I want to do is have rock solid unit testing. The mock libraries for Firestore are pretty poor and only maintained by the community. And this makes it impossible to use the emulator (if you need timestamps).
Maybe there is a different way to connect to the emulator that supports this properly?

I found some resolution that is not documented anywhere.
First, don't use @firebase/testing. That lib doesn't work with @google-cloud/firestore.  Where is the testing library for @google-cloud?
Connect to the local firestore by
import { Firestore } from '@google-cloud/firestore';
import { credentials } from '@grpc/grpc-js';
const db = new Firestore({
      projectId: 'some-project-id',
      port: 8080,
      servicePath: 'localhost',
      sslCreds: credentials.createInsecure(),
    }),

This seems to resolve the Timestamp.now(). You loose all the assertions from the testing library, but then again, you can always write your own.
The documentation should be changed to reflect this. Oh, DON'T use the grcp npm library. You have to use @grpc/grpc-js (which is what the Firestore library uses)

Brian is correct, the @firebase/testing library is intended to help test client applications. initializeAdminApp actually constructs a normal client application that happens to have admin access (to bypass security rules).
As you've noticed, this does not work the same as the server SDKs. The upside is that the server SDKs should work "out of the box" if you set the FIRESTORE_EMULATOR_HOST environment variable (the emulator should print out a helpful message when you start it up). With the environment variable set you should be able use
import { Firestore } from '@google-cloud/firestore';
const db = new Firestore({ projectId: "my-test-project" });

and immediately start talking to the emulator.


Make Block Lists be Generated

Feature branch: None
Since quite a few of the block groups have common patterns (e.g. colours), it would be more robust to have these lists generated rather then static.
Suggested implementation:
WOOL = ("minecraft:{colour}_wool" for colour in COLORS)

Moved to https://github.com/avdstaaij/gdpc/issues/40


Add license field in package.json

Installing local node modules raises the following warning : npm WARN<EMAIL_ADDRESS>No license field.
Adding a license field with a valid SPDX license expression fixes the warning.

Nice, thank you!


audacity: exclude from auto-updates, documenting decision

Motivation for this change
Uncertainty regarding privacy policy/tracking/fork situation.
Things done

[x] No code changes
[x] Fits CONTRIBUTING.md.

cc @ryantm is this an appropriate way to exclude it from nixpkgs-update? I interpret https://github.com/ryantm/nixpkgs-update/blob/0c36c9b59719e14c3ee02fa7019063425e422e70/src/Skiplist.hs#L119 this way but thought I'd check with you to make sure :)

cc @ryantm is this an appropriate way to exclude it from nixpkgs-update? I interpret<EMAIL_ADDRESS>this way but thought I'd check with you to make sure :)

As the author of that feature: yep, this is exactly how it's intended to be used.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/should-we-support-free-audacity-forks/13960/3


pip install does not seems to work behind a corporate proxy

Expected Behavior
pip install should be able to pull the dependencies from private artifactory
Current Behavior
pip install reported "SSL: CERTIFICATE_VERIFY_FAILED ... unable to get local issuer certificate"
Possible Solution

Tried adding -e PIP_TRUSTED_HOST but this did not work.
Adding ca-certificates binding only work for installing python and pip binary.

Motivations
We are working in an air-gapped environment and I wanted to use a tool to build production grade container.

It was my own bug.


Initial Release Roadmap

What needs to be done before a driver will have its first release?
My recent activity related to this driver:

added support to the PHPUnit-Mink project ( https://github.com/minkphp/phpunit-mink/pull/138 )
added an issue about documenting in Behat MinkExtension ( https://github.com/FriendsOfBehat/MinkExtension/issues/30 )

// cc: @uuf6429

Hi!
I would have made a "1.0" prerelease a long time ago, but wanted to avoid a lot of discussion on that and then somehow forgot about it.
We've been using this driver at work on a daily bases and so far it seems quite stable, with the exception of this issue which I think we should solve (the fix is simple, but I was hoping to get some agreement first).

I would have made a "1.0" prerelease a long time ago, but wanted to avoid a lot of discussion on that and then somehow forgot about it.

Please create a release so I can use this ^1.0 version constraint in composer.json instead of @dev-main.

We've been using this driver at work on a daily bases and so far it seems quite stable, with the exception of this issue which I think we should solve (the fix is simple, but I was hoping to get some agreement first).

I responded to the issue mentioned.
P.S.
Thanks to the code of this driver I was able to get MinkSelenium2Driver to work on Selenium 3 with the exception of right-clicking. This is as far as I could get considering https://github.com/instaclick/php-webdriver is in almost abandoned state (7 months without commits).

Done.


Losing Knowledge for Language Model in Fine-Tuning

Hello. I'm looking to Fine-Tune BERT MultiLingual on a specific closed-domain context in one of the languages that already exists in the multi-lingual-language set. (Romanian) My task will be to :

Fine-Tune Romanian Language Model (in order to include more words in the romanian vocab)
Fine-Tune the Resulting "Romanian++" Language-Model on an Intent-classification and NRE task.

OBS : the original vocab used by Google in training this specific language seems to be quite small (I've looked up specific words in the "vocab.txt" and they do not show up. Example : the equivalent of "bill" -> "factura" , a base word with no prefix or suffix ).
Also, I'm thinking that in order to leverage the knowledge of the pre-trained model (and the contextual embeddings down the road), I need to have the SAME input word embeddings for my vocabulary => a match of my word embeddings (the input) and the word embeddings used by Google to train (their input). Otherwise, I'm basically just adding new randomly innitialised embeddings to the system and I'm not actually fine-tuning anything!
Is my assumption correct? :dagger:
The resources found online, including the official resource page (https://github.com/google-research/bert#pre-training-with-bert) all refer to a "pre-training method" (my understanding is that this pre-training method will basically be a trained-from-scratch Language Model for a specific closed-domain corpus, using the masking technique).
But if that is true, why all the fuss about being able to FINE-TUNE BERT? (Is it really an ImageNet moment for NLP? From this point of view, not really.... It's like they used specific pixel embeddings and dont plan on releasing them for the public. So if u come with RGB input for pixels, you're not fine-tuning, you're re-training :)
It seems like without the original word-embeddings (word-pair/byte-pair or not), fine-tuning is actually just training from scratch :)
Guys, i'd appreciate any insight into this issue.
Here's a good article on the pitfalls of the MultiLingual Vocab and WordPiece Tokenization :
https://medium.com/omnius/hallo-multilingual-bert-cómo-funcionas-2b3406cc4dc2

Hey, let's distinguish between
a) adapting a model to a new national language (e.g. Romanian)
b) adapting to a certain domain (e.g. legal or healthcare)
For b): It might be enough to take a pretrained model (e.g. english or mulitilingual) and continue training on your domain corpus. We have implemented a function in the pytorch repository for this (https://github.com/huggingface/pytorch-pretrained-BERT/tree/master/examples/lm_finetuning). If vocab really doesn't fit your corpus, you can either replace the unused tokens in the current vocabulary (quick & easy!) or extend the vocab to a larger size (quite some effort in the model architecture!). In both cases you would need to learn the embeddings for these new tokens from zero in your Language Model adaptation phase. Don't expect crazy performance boosts by adjusting the vocab. We so far got 2-3 % out of it. However, the whole fine-tuning on domain corpus can have quite some good impact! Especially if your domain language is very different to wikipedia style.
For a): We had a similar problem for German language. We finally decided to train from scratch and open-source the model (see https://deepset.ai/german-bert). It works definitely better than the multilingual, but for some cases (e.g. NER) the multilingual seems to also benefit from learnings across languages. Pretraining from scratch only makes sense if you have +10GB training data in your language, but we are happy to share our learnings if you plan to train a Romanian model.


[Question]: Stateful services Graceful shutdown in dotnet core

Our stateful services run on windows VMSS in dotnet core. For gracefully shutdown them I would like my application to be notified on service shutdown.
In the past when we worked with dotnet framework we used AppDomain.CurrentDomain.ProcessExit trigger, but this is not relevant for dotnet core.
Is there any service fabric trigger that can notify my application that the service is about to shutdown? Alternatively, can you add a new hook for that (something like OnServiceCloseAsync)? Considering that OnCloseAsync is triggered for each repartitioning so we cannot tell this is a service shutdown.

For graceful shutdowns, the CancellationToken will be cancelled, so you could Register an Action on that.


Doubts about investment and O&M cost calculation in business case

Summary
I have some doubts about the business case of stakeholder customer AC1. The investment and O&M costs seem too low.
Details
This is the LES
The "huishoudens" node is assigned to "customer AC1".
The most costly technologies are:

Combined network gas, 1406 pieces.
The inital investment is  €1500 (over 15 years), O&M costs are  €156.2 per year
50 hybrid heat pumps investment (€1500+€3235), O&M costs are (€156.2+€97) per year
other technologies

In total I would expect minimally

1406*((1500/15)+156)= €359936, for combined network gas
50*(€1500+€3235)/15+(€156.2+€97)=€28433, for heat pumps

So, in my business case I would expect stakeholder Customer AC1 to pay at least €388,369 to itself.
However, this is just €31,703

Should now be fixed; good catch!


unable to send POST request to InfluxDB REST Api

i am trying to create a InfluxDB database by sending the POST request and url to which i am sending POST query is
http://localhost:8086/write?db=hamlet' --data-binary 'tobeornottobe booleanonly=true
iam getting reponse as

Any help in this regard is very much appreciated. Thank you

We try to reserve GitHub Issues for actionable bug reports or feature requests. Please send general questions to the<EMAIL_ADDRESS>mailing list


Export values_store types to help using flash messages with tsx

Package version
<EMAIL_ADDRESS>Describe the bug
Types (and class) from the file values_stores are not exported.
Reproduction repo
No response

I'm resolving my issue by using HttpContext['session']['flashMessages'] maybe it's a better solution?

Ohh yeah, we should export the ValuesStore from the main entrypoint. Can you send a PR that exports the following classes from the package entrypoint?

ReadOnlyValuesStore
ValuesStore
Session


NG Commands are slow in 25.5 (maybe before too)

Please provide us with the following information:

When running an ng command it is first thinking 30 seconds and after that it is running the command.
This is annoying, because it's not needed. My machine is a new MacBook Pro with everything to the max ;)
OS?

Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)
MacOS Siera

Versions.

Please run ng --version. If there's nothing outputted, please run in a Terminal: node --version and paste the result here:
25.5
6.9.1

Repro steps.

Was this an app that wasn't created using the CLI? What change did you do on your code? etc.
ng lint
ng serve

The log given by the failure.

Normally this include a stack trace and some more information.

Mention any other details that might be useful.

Thanks! We'll be in touch soon.

That's weird, startup time should have gone down this version. Did you follow https://github.com/angular/angular-cli#updating-angular-cli while upgrading?

@filipesilva yeah ruined exactly that steps. (copy based it from there in my terminal)

@masaanli maybe you can try and run one of this slow commands like this to see where it delays:
DEBUG=angular-cli*,ember-cli* ng serve

@beeman I tried it this morning what u said and everything seemed a lot faster, so not having it all the time it seems.
Btw. when running ng serve it takes now 5 seconds before doing anything.
and when doing it with the DEBUG=angular-cli*,ember-cli* ng serve it starts immediately.
Tried is 10x times :)


Transformation link in space

Pending at the moment. Should be part of the discussion for "coordinateSpace.schema.json" #40
Also, it was decided that "transformation" will be handled as an activity, meaning as a "protocol" / "protocolExecution" via openMINDS.

for now it was decided that this will be handle via the protocol / protocolExecution. I'll close this issue for now


Compilation error gcc 14.2.0

Hi guys, it seems that the installation of the ttable==0.6.4 pip package fails due to a compilation error when trying to build the picosatmodule.c.
The error message is realated to the -Wint-conversion check, where it detected a pointer trying to be stored in a char signed:
      building 'tt._clibs.picosat' extension
      creating build/temp.linux-x86_64-cpython-312
      creating build/temp.linux-x86_64-cpython-312/tmp
      creating build/temp.linux-x86_64-cpython-312/tmp/pip-install-hrud7wm5
      creating build/temp.linux-x86_64-cpython-312/tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907
      creating build/temp.linux-x86_64-cpython-312/tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt
      creating build/temp.linux-x86_64-cpython-312/tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs
      creating build/temp.linux-x86_64-cpython-312/tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosat
      x86_64-pc-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall -O2 -Wall -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -march=x86-64-v2 -mtune=broadwell -O2 -Wall -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -march=x86-64-v2 -mtune=broadwell -fPIC -DNDEBUG -I/tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosat -I/usr/include/python3.12 -c /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosat/picosat.c -o build/temp.linux-x86_64-cpython-312/tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosat/picosat.o
      x86_64-pc-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall -O2 -Wall -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -march=x86-64-v2 -mtune=broadwell -O2 -Wall -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -march=x86-64-v2 -mtune=broadwell -fPIC -DNDEBUG -I/tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosat -I/usr/include/python3.12 -c /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c -o build/temp.linux-x86_64-cpython-312/tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.o
      /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c: In function '_tt_soliter_next':
      /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c:403:50: error: passing argument 2 of '_tt_block_sol' makes pointer from integer without a cast [-Wint-conversion]
        403 |             if (_tt_block_sol(iter->picosat, iter->_temp_mem) < 0)
            |                                              ~~~~^~~~~~~~~~~
            |                                                  |
            |                                                  signed char
      /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c:356:48: note: expected 'signed char *' but argument is of type 'signed char'
        356 | _tt_block_sol(PicoSAT * picosat, signed char * mem)
            |                                  ~~~~~~~~~~~~~~^~~
      /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c: In function '_tt_soliter_dealloc':
      /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c:426:24: error: passing argument 1 of 'PyMem_Free' makes pointer from integer without a cast [-Wint-conversion]
        426 |         PyMem_Free(iter->_temp_mem);
            |                    ~~~~^~~~~~~~~~~
            |                        |
            |                        signed char
      In file included from /usr/include/python3.12/Python.h:41,
                       from /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c:12:
      /usr/include/python3.12/pymem.h:55:35: note: expected 'void *' but argument is of type 'signed char'
         55 | PyAPI_FUNC(void) PyMem_Free(void *ptr);
            |                             ~~~~~~^~~
      /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c: In function 'sat_all':
      /tmp/pip-install-hrud7wm5/ttable_b714877d13474619b5cf569f63972907/tt/_clibs/picosatmodule.c:548:21: error: assignment to 'signed char' from 'void *' makes integer from pointer without a cast [-Wint-conversion]
        548 |     iter->_temp_mem = NULL;
            |                     ^
      error: command '/usr/bin/x86_64-pc-linux-gnu-gcc' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for ttable
Failed to build ttable
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (ttable)

It seems to be a legitim warning that could generate a bug, which currently might be mittigated thanks to the implicit padding added at the end of the structure. I think we just need to change the _temp_mem type to signed char*: https://github.com/welchbj/tt/blob/develop/tt/_clibs/picosatmodule.c#L25.
I can do the Pull Request myself if needed

i confirm this issue. @TApplencourt, @welchbj, do you still maintain the project ?

I just did one commit 7 years ago :)
But potentially, picosat can be used as a dependency https://github.com/conda/pycosat (and not hard-coded as it's currently is)

Hello @TApplencourt @welchbj, I have done the fix in the PR.
Can you merge it ?

Thanks for the fix, merged. Apologies for the delay -- I wasn't aware anyone actually used this library. I've been thinking about some features I'd want to include in this library and may resume active development in the near future.


Menu bar word-wraps on narrow displays, covering map

The menu bar at the head of the Brave Intel Map has become so filled with menus and links that it no longer fits on any browser window with a canvas less than 1095px wide.  When viewed on a browser with an effective width narrower than that (a browser snapped to half-screen on a 1080p monitor, at least some Android tablets, any any iPad) the menu bar wraps to a second (or third) line, causing it to overlap the map and render the northern part of the region unviewable.
To reproduce:  Resize the browser so that the canvas has a width less than 1095px and more than 767px
Screenshots demonstrating problem:

Still an issue at 900x800 or so.
http://serinus.us/screenshots/20150127004121172.png


Bugfix - wrong class name

Coverage remained the same at 89.52% when pulling e99942682fd399600d40a999d674f05af4807b8c on savoirfairelinux:bugfix3 into d823a0c09d0a08ad907686fded8e44b1fc27c56f on digi604:master.

Coverage remained the same at 89.52% when pulling e99942682fd399600d40a999d674f05af4807b8c on savoirfairelinux:bugfix3 into d823a0c09d0a08ad907686fded8e44b1fc27c56f on digi604:master.

Coverage remained the same at 89.52% when pulling e99942682fd399600d40a999d674f05af4807b8c on savoirfairelinux:bugfix3 into d823a0c09d0a08ad907686fded8e44b1fc27c56f on digi604:master.

Coverage remained the same at 89.52% when pulling e99942682fd399600d40a999d674f05af4807b8c on savoirfairelinux:bugfix3 into d823a0c09d0a08ad907686fded8e44b1fc27c56f on digi604:master.

Coverage remained the same at 89.52% when pulling e99942682fd399600d40a999d674f05af4807b8c on savoirfairelinux:bugfix3 into d823a0c09d0a08ad907686fded8e44b1fc27c56f on digi604:master.

Done.


pod install --project-directory=ios报错了

第一步：yarn add react-native-navigation正常
第二步：pod install --project-directory=ios报错
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb:229: warning: Insecure world writable dir /usr/local/sbin in PATH, mode 040777
Auto-linking React Native module for target AwesomeProject: ReactNativeNavigation
Analyzing dependencies
[!] CocoaPods could not find compatible versions for pod "ReactNativeNavigation":
In Podfile:
ReactNativeNavigation (from ../node_modules/react-native-navigation)
Specs satisfying the ReactNativeNavigation (from ../node_modules/react-native-navigation) dependency were found, but they required a higher minimum deployment target.

index.js
import { Navigation } from "react-native-navigation";
import App from "./App";
Navigation.registerComponent('com.myApp.WelcomeScreen', () => App);
Navigation.events().registerAppLaunchedListener(() => {
Navigation.setRoot({
root: {
stack: {
children: [
{
component: {
name: 'com.myApp.WelcomeScreen'
}
}
]
}
}
});
});

我看了下react native navigation的文档，中间还有别的步骤你没做啊
---原始邮件---
发件人: @.>
发送时间: 2021年6月8日(周二) 晚上11:37
收件人: @.>;
抄送: @.***>;
主题: [reactnativecn/react-native-website] pod install --project-directory=ios报错了 (#448)
第一步：yarn add react-native-navigation正常
第二步：pod install --project-directory=ios报错
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb:229: warning: Insecure world writable dir /usr/local/sbin in PATH, mode 040777
Auto-linking React Native module for target AwesomeProject: ReactNativeNavigation
Analyzing dependencies
[!] CocoaPods could not find compatible versions for pod "ReactNativeNavigation":
In Podfile:
ReactNativeNavigation (from ../node_modules/react-native-navigation)
Specs satisfying the ReactNativeNavigation (from ../node_modules/react-native-navigation) dependency were found, but they required a higher minimum deployment target.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

import { Navigation } from "react-native-navigation";
import App from "./App";
Navigation.registerComponent('com.myApp.WelcomeScreen', () => App);
Navigation.events().registerAppLaunchedListener(() => {
Navigation.setRoot({
root: {
stack: {
children: [
{
component: {
name: 'com.myApp.WelcomeScreen'
}
}
]
}
}
});
});
index.js 文档里说改这个 我一开始就改过了啊

我不想重复，但你确实还有步骤没做。


fix: typo spelling grammar

hello , i fix some typo in documentation and replace to correct words with reference from Merriam webster, thanks

Many thanks for the PR!

thank you sir @MikeRalphson !!


Please select a issuer from the list (call from graphql) setPaymentMethodOnCart

Hi,
When using the mutation call setPaymentMethodOnCart. I receive an error : Please select a issuer from the list.
The current version of the module is 1.42.0
graphql call example :
mutation {
setPaymentMethodOnCart(input: {
cart_id: "${cartId}"
payment_method:
{
code: "buckaroo_magento2_ideal"
}
}) {
cart {
selected_payment_method {
code
title
}
}
}
}

Hello @raoulguillermo currently we don't provide graphQl in our main plugin(this), we have a new plugin in development that will provide you with graphQl functionality that you seek, it will be released in the coming months, thank you

Would it be an option if i use the normal magento 2 api?

@raoulguillermo We can also give you access to our private repo with our GraphQL module. It's a working module, already running in pilot at some merchants. Interested?

@Buckaroo-Rens yes! Would really appreciate that!

@raoulguillermo Added you. For now i will close this issue. And please, feel free to give us any feedback on the GraphQL module.

@Buckaroo-Rens thanks!


Some words are not loaded, but components work fine if loaded separately

Does anyone having problems in loading words like "便宜", when we try loading this using the CDN script, it throws error "Failed to load char data for".  If I try loading "便" or "宜" separately then it works fine. But when we combine it and try to load then it doesn't work.
Another problem we are facing is related to the strokes of the characters in some cases, some works fine in one browser but not in Safari and some works with safari but not with other browsers.
Desktop Browser:

Mobile browser:

Another character having strokes problem on browser:

I really appreciate your support and help here.

You can only load 1 character at a time in a single writer, so you can't load "便宜" in one go, for instance. You would need to have either 2 writer instances, and load "便" in one and "宜" in the other, or load them one at a time in the same writer instance.
The mobile browser stuff looks pretty bad - maybe the browser isn't supporting SVG fully? You can try switching the rendered to canvas and see if that helps. It doesn't handle overlapping strokes as nicely as the default SVG renderer, but it might work better in browsers that don't support SVG as well. You can do that by passing renderer: "canvas" when creating the writer

Thank you @chanind for your quick response. We were able to resolve the rendering strokes issue on browsers.
For the other point, "𠂇" we are not able to get this character loaded as well, I checked in the data sets of Henzi writer and this character is not in there.


Fix small typo of documentation

I fixed a small typo of documentation. Did I got your intend correctly?
@@ -51,7 +51,7 @@ will cause the compiler to look for **all** elm source files in the ...
 #### maxInstances (default 4)

-You can add `cache=true` to the loader:
+You can add `maxInstances=8` to the loader:

 ```js
   ...

Thanks.

@prikhi technically, I'm the one who is meant to merge PRs for this repo, since I'm the maintainer FWIW

@eeue56 Sorry figured it was a small enough change that you didn't need to be bothered with it. Wouldn't have done it for anything substantial.


Apple M1 support

My MacOS is Apple M1 chipset, with Sonoma 14.2
I installed protobuf using brew install protobuf and tried to compile to compile an empty hello, world! project with raft crate included. The compilation failed with
   Compiling raft-proto v0.7.0
error: failed to run custom build command for `raft-proto v0.7.0`

Caused by:
  process didn't exit successfully: `/Users/bayram/Projects/Rust/hello-raft/target/debug/build/raft-proto-c2bff7cf48736de7/build-script-build` (exit status: 101)
  --- stdout
  The system `protoc` version mismatch, require >= 3.1.0, got 25.1.x, fallback to the bundled `protoc`

  --- stderr
  thread 'main' panicked at /Users/bayram/.cargo/registry/src/index.crates.io-6f17d22bba15001f/protobuf-build-0.14.1/src/protobuf_impl.rs:35:14:
  No suitable `protoc` (>= 3.1.0) found in PATH
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I guess it is related to these lines inside protobuf_impl.rs
let protoc_bin_name = match (env::consts::OS, env::consts::ARCH) {
        ("linux", "x86") => "protoc-linux-x86_32",
        ("linux", "x86_64") => "protoc-linux-x86_64",
        ("linux", "aarch64") => "protoc-linux-aarch_64",
        ("linux", "powerpc64") => "protoc-linux-ppcle_64",
        ("macos", "x86_64") => "protoc-osx-x86_64",
        ("windows", _) => "protoc-win32.exe",
        _ => panic!("No suitable `protoc` (>= 3.1.0) found in PATH"),
    };

Or does it support M1 chipset and am I missing something?

It's just having problem recognizing version "25.1.x". As a workaround, you can put an outdated protoc in PATH.

@BusyJay Successfully built. Thank you.

@BusyJay I managed to compile and run  the example with a single node, however with 5 nodes it fails with:
Compiling hello-raft v0.1.0 (/Users/bayram/Projects/Rust/hello-raft)
error[E0599]: no method named `merge_from_bytes` found for struct `raft::prelude::ConfChange` in the current scope
   --> src/main.rs:291:24
    |
291 |                     cc.merge_from_bytes(&entry.data).unwrap();
    |                        ^^^^^^^^^^^^^^^^ method not found in `ConfChange`
    |
   ::: /Users/bayram/.cargo/registry/src/index.crates.io-6f17d22bba15001f/protobuf-2.28.0/src/message.rs:94:8
    |
94  |     fn merge_from_bytes(&mut self, bytes: &[u8]) -> ProtobufResult<()> {
    |        ---------------- the method is available for `raft::prelude::ConfChange` here
    |
    = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
7   + use protobuf::message::Message;
    |

warning: unused import: `protobuf::Message`
  --> src/main.rs:14:5
   |
14 | use protobuf::Message as PbMessage;
   |     ^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

For more information about this error, try `rustc --explain E0599`.
warning: `hello-raft` (bin "hello-raft") generated 1 warning
error: could not compile `hello-raft` (bin "hello-raft") due to previous error; 1 warning emitted

This is my Cargo.toml
[package]
name = "hello-raft"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
bytes = "1.5.0"
protobuf = "3.3.0"
raft = "0.7.0"
raft-proto = "0.7.0"
regex = "1.10.2"
slog = "2.7.0"
slog-async = "2.8.0"
slog-envlogger = "2.2.0"
slog-stdlog = "4.1.1"
slog-term = "2.9.0"

Any idea how to fix it?

Currently, raft-rs uses protobuf 2.x.

@BusyJay Thank you. Worked.

@BusyJay I want to play around with the crate. Do you have sort of community or a place to ask if I have questions regarding usage of the crate or internals of the crate?

Both issues or github discussions are OK.

Hi! I'm facing the same problem, I tried downgrading to version 3 but still it happens, is there any other solution?

This issue includes several problems, what's the exact error did you meet? Maybe we should create a new issue to discuss the problem more specifically.

@BusyJay
I'm getting the protobuf error:
Caused by:
  process didn't exit successfully: `/Users/davidviejo/poc/rust-raft-poc/target/debug/build/raft-proto-d85050faeb1cbc6b/build-script-build` (exit status: 101)
  --- stdout
  The system `protoc` version mismatch, require >= 3.1.0, got 27.3.x, fallback to the bundled `protoc`

  --- stderr
  thread 'main' panicked at /Users/davidviejo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/protobuf-build-0.14.1/src/protobuf_impl.rs:35:14:
  No suitable `protoc` (>= 3.1.0) found in PATH
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I think I see the issue, it's because of the --version command that is returning libprotoc 27.3

Now it's working, for anyone else facing this problem I had to:
Install protobuf 3.20:
brew install<EMAIL_ADDRESS>
Then copy protoc to the bin directory:
sudo cp<EMAIL_ADDRESS>/usr/local/bin/protoc

And verify the version of protoc
protoc --version

The major must be 3, otherwise it won't work on mac m1/m2/m3/m4


Update github actions to address warnings

This PR fixes the following warnings issued by the CI system:-

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: actions/checkout, actions/cache
The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
The ubuntu-18.04 environment is deprecated, consider switching to ubuntu-20.04(ubuntu-latest), or ubuntu-22.04 instead. For more details see https://github.com/actions/virtual-environments/issues/6002

For the last of these it is necessary to remove the -enable-fuse and --enable-fdkaac switches from the 32-bit compile, as the 32-bit packages to support these options are no longer available.

Further commit added so that when ubuntu-latest switches to 22.04, we get no errors from the C++ CI and the OpenSSL 3.x code.


universe: python: allow custom path to python

Closes #2114
Signed-off-by: Adam Smith<EMAIL_ADDRESS>

Not sure why the integration tests would fail. Is this something ephemeral? It seems to be complaining that the size of the alpine image isn't expected.

Not sure why the integration tests would fail. Is this something ephemeral? It seems to be complaining that the size of the alpine image isn't expected.

Everything looks good now :D


To Store Or Not To Store

Work with the refactor of the policy reasoner to extract the Brane stuff from it is progressing smoothly. Over at the reasoner, the lib-refactor-branch contains all the new work; and similarly, Brane has the lib-refactor branch as well to receive the new changes.
Currently, though, I'm at the point where I'm ready to re-introduce the policy store into the picture. I'm rather confident that I might as well use the opportunity and split it into a new service (will create a new policy-store repository soon).
However, I'm now facing two design decisions I'd like your input on @DanielVoogsgerd:

Should we structure the store repository the same as the reasoner repository (i.e., library-focused)? My argument for is that the projects are more homogeneous in structure and that we buy ourselves flexibility over at the store proejct; but the counter-point is that I think the store is actually quite agnostic to what it actually stores (some metadata + raw strings; should be sufficient). So we might just want to create a single binary out of it. But I'm not sure.
How do we want to combine the two services in Brane? Should I create a single brane-chk container that runs both binaries, to simulate the structure we had before? Or should we spawn another service on the worker that represents the policy store? I thought about using the brane-reg to also store policies, but I think that's unwise because we want none of the policy store API to be outward facing (only the domain itself should be able to check/change them, naturally).

Let me know what you think :)

If there is a clear boundary where you can split the project into a library and binary, I am generally in favour of doing so, as it allows for easy extension in case somebody else comes along with some new perspective. If there is one canonical way of implementing that library, I think we should use src/main.rs for that binary. If other fringe ways of using the library come to light, they can move to src/bin/
I think we should go with a single brane-chk container. From a Brane perspective, it functions as one service, so separating it into two just adds complexity. There is one main reason to separate them into two services from a practical standpoint, and that would be in order to allow load balancing the expensive checking, but I think it is unwise to worry about that for now.

Both points come with a big condition that it should not increase either your workload or the complexity too much. E.g. for point 1, if the boundary between what is library and what is binary becomes too vague, just implement it as a boundary and keep it simple. Having a useless library because everything of substance has to move to the binary because it is implementation dependent, it is not of any use to have it as a library.
Unfortunately, my domain knowledge of Brane is still only a fraction of yours, so take my opinion with a grain of salt.

You make good points! It's decided, then, I'll aim to implement the store akin to a library too with a binary wrapper (at least for now; if it turns out we need multiple, we can move them to Brane just like we did with the reasoner); and I'll create a single container for both the reasoner and the store.
Thanks :)


video.lengthSeconds returns 0 if the video is a Youtube short

when retrieving videos, if durationText is 'SHORTS', then lengthSeconds will return 0 instead of the actual video length in seconds.

actually, after looking into the data that YouTube gives that is used by this library, I can see that YouTube doesn't give this information, and I see that this library will default this to 0 when this happens.

Fixed in #75


Warning when compiling and ReferenceError

I've pieced together this gulp file:
var Gulp = require('gulp');
var Gutil = require('gulp-util');
var Webpack = require('webpack');

// var CommonsChunkPlugin = Webpack.optimize.CommonsChunkPlugin;
var UglifyJsPlugin = Webpack.optimize.UglifyJsPlugin;
var executionCount = 0;

Gulp.task('webpack', function (callback) {

    var config = {
        watch: global.isWatching,
        entry: {
            bingo: './client/pages/bingo/index',
            anotherpage: './client/pages/another-page/index'
        },
        output: {
            path: './public/pages',
            filename: '[name].min.js'
        },
        resolve: {
            extensions: ['', '.js', '.elm']
        },
        module: {
            loaders: [
                { test: /\.elm$/, exclude: /node_modules/, loader: 'elm-webpack-loader' }
            ]
        }
    };

    Webpack(config, function (err, stats) {

        if (err) {
            throw new Gutil.PluginError('webpack', err);
        }

        Gutil.log('[webpack]', stats.toString({
            colors: true,
            chunkModules: false
        }));

        if (executionCount === 0) {
            callback();
        }
        executionCount += 1;
    });
});

But I get these warnings:
WARNING in ./client/pages/bingo/index.elm
Critical dependencies:
10399:113-120 This seems to be a pre-built javascript file. Though this is possible, it's not recommended. Try to require the original source to get better results.
 @ ./client/pages/bingo/index.elm 10399:113-120

WARNING in ./client/pages/another-page/index.elm
Critical dependencies:
10399:113-120 This seems to be a pre-built javascript file. Though this is possible, it's not recommended. Try to require the original source to get better results.
 @ ./client/pages/another-page/index.elm 10399:113-120

It appears to compile fine, but then the app doesn't render and I get console log error:
ReferenceError: Elm is not defined

var app = Elm.fullscreen(Elm.Bingo);

Is this an issue with Webpack or is there something I am missing?

Very interesting. The full output of running bash gulp webpack  is:
$ gulp webpack
[22:32:45] Using gulpfile /Applications/MAMP/htdocs/Elm/bingo/gulpfile.js
[22:32:45] Starting 'webpack'...
Success! Compiled 0 modules.
Success! Compiled 0 modules.
Successfully generated /Applications/MAMP/htdocs/Elm/bingo/node_modules/elm-webpack-loader/index.js!/Applications/MAMP/htdocs/Elm/bingo/client/pages/another-page/index.elm
Successfully generated /Applications/MAMP/htdocs/Elm/bingo/node_modules/elm-webpack-loader/index.js!/Applications/MAMP/htdocs/Elm/bingo/client/pages/bingo/index.elm
[22:32:52] [webpack] Hash: 256272bebad409e68b2e
Version: webpack 1.12.2
Time: 7087ms
         Asset    Size  Chunks             Chunk Names
anotherpage.js  134 kB       0  [emitted]  anotherpage
      bingo.js  134 kB       1  [emitted]  bingo
chunk    {0} anotherpage.js (anotherpage) 326 kB [rendered]
chunk    {1} bingo.js (bingo) 326 kB [rendered]

WARNING in ./client/pages/another-page/index.elm
Critical dependencies:
10399:113-120 This seems to be a pre-built javascript file. Though this is possible, it's not recommended. Try to require the original source to get better results.
 @ ./client/pages/another-page/index.elm 10399:113-120

WARNING in ./client/pages/bingo/index.elm
Critical dependencies:
10399:113-120 This seems to be a pre-built javascript file. Though this is possible, it's not recommended. Try to require the original source to get better results.
 @ ./client/pages/bingo/index.elm 10399:113-120

inside the webpack folder inside node_modules a folder like this is being created: /index.js!/Applications/MAMP/htdocs/Elm/bingo/client/pages/bingo/index.elm
Also had to remove the node_modules/elm-webpack-loader/node_modules folder to get that far.

Ok I was able to achieve what was I looking for with gulp-elm. I made a gist of it in case it is useful for anybody else. https://gist.github.com/bigbassroller/edd8a30f237371b4be2b


Add requirements to build numpy/matplotlib

This change adds the requirements to build numpy/matplotlib to our cfgov-python-builder container.
How to test this PR
docker-compose build python should succeed.
Checklist

[x] PR has an informative and human-readable title
[x] Changes are limited to a single goal (no scope creep)

Could we consider upgrading this Docker build to a more modern Python, even given our current infrastructure status?

I don't think I'd want to do that — I think this image should reflect our current version of Python, and given that we're infrastructure-limited to 3.8, that's where we are for now.
Right now this image is only used for development purposes, so I think this is fine. I think it's up to the team who'll be making it into a deployable image as to what to do beyond that, including re-enabling the docker build action.


[BUG] - Outlier and Static slice view reset does not work in data browser

Describe the bug
When clearing the filter in the data browser on a static or outlier slice, the view does not reset properly and keeps showing the filtered data.
To Reproduce
Steps to reproduce the behavior:

Go to data browser
Click on outlier or static slice
Click "clear filter"
Observe that nothing happens

Expected behavior
When clearing the filter in the data browser on a static or outlier slice, the view should reset properly to show all records.
Screenshots

Desktop (please complete the following information):

OS: Win11
Browser edge
Version 1.7.1

Additional context

Steps to implement:

What is the core solution? --> reset results from outlier slice and show all records (1h)
What problems could be expected? --> there are many variables in the data browser, not sure what exactly needs to be reset (+1h)
UI changes and notifications? --> no additional min/hours
OPTIMISTIC: 1h
PESSIMISTIC: 2h
SUM: 1h - 2h

Steps for testing:

Testing dynamic, static and outlier slices with different filters (15 minutes)

Steps for review:

Review (part of the whole PR)
Fixing comments from PR (part of the whole PR)

ESTIMATION:

Implementation: 1h - 2h
Testing: 15minutes
Review: (part of the whole PR)

TOTAL ESTIMATION: 1h 15 min - 2h 15 min


duplicate rows/data showing up in aws_route53_record queries

Describe the bug
There seems to be a bug when doing lookup with an 'in' clause on the 'aws_route53_record' table.  Duplicate rows are shown when more than 1 qualifier is listed.
Steampipe version (steampipe -v)
v0.13.6
Plugin version (steampipe plugin list)
v0.57.0
To reproduce
> select name,type,ttl,failover from aws_prod.aws_route53_record where zone_id = 'SOMEZONEID' and name in ('back.example.com.','www.example.com.')
+--------------------+-------+-----+-----------+
| name               | type  | ttl | failover  |
+--------------------+-------+-----+-----------+
| www.example.com.  | CNAME | 5   | <null>    |
| www.example.com.  | CNAME | 5   | <null>    |
| back.example.com. | A     | 10  | PRIMARY   |
| back.example.com. | A     | 10  | SECONDARY |
| www.example.com.  | CNAME | 5   | <null>    |
| www.example.com.  | CNAME | 5   | <null>    |
+--------------------+-------+-----+-----------+
> select name,type,ttl,failover from aws_prod.aws_route53_record where zone_id = 'SOMEZONEID' and name in ('pr.example.com.','www.example.com.')
+-------------------+-------+-----+-----------+
| name              | type  | ttl | failover  |
+-------------------+-------+-----+-----------+
| www.example.com. | CNAME | 5   | <null>    |
| www.example.com. | CNAME | 5   | <null>    |
| pr.example.com.  | A     | 10  | PRIMARY   |
| pr.example.com.  | A     | 10  | SECONDARY |
| www.example.com. | CNAME | 5   | <null>    |
| www.example.com. | CNAME | 5   | <null>    |
+-------------------+-------+-----+-----------+
> select name,type,ttl,failover from aws_prod.aws_route53_record where zone_id = 'SOMEZONEID' and name in ('www.example.com.','back.example.com.')
+--------------------+-------+-----+-----------+
| name               | type  | ttl | failover  |
+--------------------+-------+-----+-----------+
| www.example.com.  | CNAME | 5   | <null>    |
| www.example.com.  | CNAME | 5   | <null>    |
| back.example.com. | A     | 10  | PRIMARY   |
| back.example.com. | A     | 10  | SECONDARY |
| www.example.com.  | CNAME | 5   | <null>    |
| www.example.com.  | CNAME | 5   | <null>    |
+--------------------+-------+-----+-----------+
> select name,type,ttl,failover from aws_prod.aws_route53_record where zone_id = 'SOMEZONEID' and name in ('www.example.com.','pr.example.com.')
+-------------------+-------+-----+-----------+
| name              | type  | ttl | failover  |
+-------------------+-------+-----+-----------+
| www.example.com. | CNAME | 5   | <null>    |
| www.example.com. | CNAME | 5   | <null>    |
| pr.example.com.  | A     | 10  | PRIMARY   |
| pr.example.com.  | A     | 10  | SECONDARY |
| www.example.com. | CNAME | 5   | <null>    |
| www.example.com. | CNAME | 5   | <null>    |
+-------------------+-------+-----+-----------+
> select name,type,ttl,failover from aws_prod.aws_route53_record where zone_id = 'SOMEZONEID' and name in ('back.example.com.','pr.example.com.')
+--------------------+------+-----+-----------+
| name               | type | ttl | failover  |
+--------------------+------+-----+-----------+
| back.example.com. | A    | 10  | PRIMARY   |
| back.example.com. | A    | 10  | SECONDARY |
| pr.example.com.   | A    | 10  | PRIMARY   |
| pr.example.com.   | A    | 10  | SECONDARY |
| back.example.com. | A    | 10  | PRIMARY   |
| back.example.com. | A    | 10  | SECONDARY |
+--------------------+------+-----+-----------+
> select name,type,ttl,failover from aws_prod.aws_route53_record where zone_id = 'SOMEZONEID' and name in ('back.example.com.','pr.example.com.','www.example.com.')
+--------------------+-------+-----+-----------+
| name               | type  | ttl | failover  |
+--------------------+-------+-----+-----------+
| www.example.com.  | CNAME | 5   | <null>    |
| back.example.com. | A     | 10  | PRIMARY   |
| back.example.com. | A     | 10  | SECONDARY |
| www.example.com.  | CNAME | 5   | <null>    |
| www.example.com.  | CNAME | 5   | <null>    |
| www.example.com.  | CNAME | 5   | <null>    |
| pr.example.com.   | A     | 10  | PRIMARY   |
| www.example.com.  | CNAME | 5   | <null>    |
| pr.example.com.   | A     | 10  | SECONDARY |
| www.example.com.  | CNAME | 5   | <null>    |
| back.example.com. | A     | 10  | PRIMARY   |
| back.example.com. | A     | 10  | SECONDARY |
+--------------------+-------+-----+-----------+
> select name,type,ttl,failover from aws_prod.aws_route53_record where zone_id = 'SOMEZONEID' and name in ('back.example.com.')
+--------------------+------+-----+-----------+
| name               | type | ttl | failover  |
+--------------------+------+-----+-----------+
| back.example.com. | A    | 10  | PRIMARY   |
| back.example.com. | A    | 10  | SECONDARY |
+--------------------+------+-----+-----------+
> select name,type,ttl,failover from aws_prod.aws_route53_record where zone_id = 'SOMEZONEID' and name = 'www.example.com.'
+-------------------+-------+-----+----------+
| name              | type  | ttl | failover |
+-------------------+-------+-----+----------+
| www.example.com. | CNAME | 5   | <null>   |
| www.example.com. | CNAME | 5   | <null>   |
+-------------------+-------+-----+----------+
>

Expected behavior
rows should not be duplicated

@tinder-tder Appreciate continuous feedback! Thank you
It is disappointing to see this happening; we could replicate the issue at our end, but we are looking into it.

Hey @tinder-tder, The API is not working properly due to which we are facing the duplicate values and optional column support issue, we have raised an issue in AWS GO SDK for that. We are also engaging AWS with a support request.
While we are waiting to get a response from the above support requests, after testing and working to provide an alternative solution, for the time being,  we have this draft [PR] (https://github.com/turbot/steampipe-plugin-aws/pull/972) fix. Could you please try it out and let us know your feedback.

@bigdatasourav I just tested the PR and it does look like its working as expected with no dupes, thanks!


Change background color to hex format

Hi @MikeRalphson
When we developed x-logo extension we had only hex format in mind.
But my friend made mistake referencing CSS spec for color definition.
Named colors are CSS specific and hard to support for anything other than CSS/HTML generation.
Official definition of x-logo already fixed:
https://github.com/Rebilly/ReDoc/blob/master/docs/redoc-vendor-extensions.md#logo-object

@IvanGoncharov the swagger file itself is regenerated from the header file plus the ibl.json schema, but in this case that's no problem. Many thanks for the PR.

Thank you, for maintaining this spec. I just try to minimize consequences of my mistake.


Adds hasRule utility function

It check if the rule exists for a set of validations.

Sure thing, let me check how to do it and I will write those, also with that in mind, should I also add this to fns to be used like it was described in #233?

I'm not sure I'd add it to context.fns since it would then be included in everyone's bundles. With beta.9 we'll be introducing @formkit/addons which will allow us to put nice utilities like this into plugins users can choose to install. So we could have one like addSchemaFns to add extra functions such as hasRule to the context.fns

Added the needed tests for it, let me know if there are missing cases that you see so I can create the missing tests.

I'm not sure if its useful enough as a convinent way of checking outside a node, or it should be changed to use a node instead of a an arbitrary array and use the parsed rules instead to make this check easier.

Closing in favor of node.props.parsedRules as it works the same way.


Remove priv and const declarations and modifiers

This PR simplifies the language by removing priv and const declarations. FieldElementType is also removed from the Type representation. To make up for the loss of constant field elements, a ConstantInt type has been added which is the new type of constant integers, implicitly castable to a Field type to match the previous behavior of Field(Constant) implicitly casting to Field(Private).
Additionally, this PR also removes modifiers entirely from types. That is, declarations like fn foo(x: priv i32, y: pub Field) no longer parses. There is a loss of functionality here currently from the inability to specify const or pub parameters. The current intent is to replace pub parameters with a return type on main. const parameters can possibly be replaced by exposing the ConstantInt type or having a dedicated const generics-like feature.
This PR is currently not close to being finished and so is given as a draft to provide a place for opinions on the change.

I think we should be able to specify pub or priv in the main arguments:  fn foo(x: priv i32, y: pub Field), in addition to having a return value.
In fact the main return value should also have the pub attribute (which should be mandatory for the return) so that it is explicit that it is public data.

My issue with allowing visibility in arguments in general is that pub is only allowed on main which feels quite special to me. We could of course parse (or just validate afterwards - as we currently do) fn main(...) differently from fn other(...) but this feels rather ad-hoc and non-intuitive to me if I were learning Noir.
That being said, I don't know of another more clear way either. I suppose if we consider pub parameters on main to be both given as an argument and returned in a sense, that somewhat lines up with out parameters (or just mutable parameters in general) in other languages. out makes more sense than mut to me but is still just a renaming of pub at the end of the day.
This is the area I'd imagine we'd have to spend the most time on in any future Noir tutorial like the one mentioned in standup today.


Problem with Google Play

When I start Google Play it says "Couldn't sign in There was a problem comunicating with Google services. Try again later."

Any fix?

In my case, I didn't even get this sign-in pop-up. Google Play Services won't open either.

In my case, I didn't even get this sign-in pop-up. Google Play Services won't open either.

Same is happening with my play store.

I get the same problem - I don't get the sign-in pop-up. I also tried to add a google account in contacts, same problem. I think the problem is because Windows Subsystem for Android isn't registered with play protect.

Same Problem, When I start Google Play it says "Couldn't sign in There was a problem communicating with Google services. Try again later."

Same Problem, When I start Google Play it says "Couldn't sign in There was a problem communicating with Google services. Try again later."  How do I fix This

whats the solution ?


hotfix(avoidance): avoidance safety check

Description

https://github.com/autowarefoundation/autoware.universe/pull/4864
https://github.com/autowarefoundation/autoware.universe/pull/4926
https://github.com/autowarefoundation/autoware.universe/pull/4798

Tests performed

Not applicable.
Effects on system behavior

Not applicable.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@mkuri 回避で最新の修正いくつかcherry-pickしたのでマージします、回避前に対向車いるかどうかのチェックなど


Where am I failing?

When i run my pygame using pygbag i get the following error:

my main.py is referring these local modules like this:

I can see all the script files for these modules are included in the apk-file in directory assets (same level as main.py)

So it seems to be looking for my own modules in the CDN.
Should I copy all modules into main.py, so I only have one file?

We cannot tell from just those screenshots, please provide a github project/page or a itch web.zip archive (--archive) of whole project you give to pygbag.

This repository: https://github.com/ThorvaldAagaard/bridge-with-ben
It is not a complete application, but running python main.py from the game directory gives:

Running pygbag game and then going to http://localhost:8000/?-i gives the CDN-error
web.zip attached it that is easier than cloning my repository
web.zip

you had some blocking while loops
https://github.com/ThorvaldAagaard/bridge-with-ben/pull/1/files

Thank you.
So on any drawing in a loop remember to sleep to avoid the blocking.
and this is just some information that can be ignored
1103: list_imports len(code)=7414 file=None hint=PosixPath('/data/data/game/assets/main.py')
1095: scan_imports hint=PosixPath('/data/data/game/assets/main.py') filename='<stdin>' len(code)=7414 ['table', 'drawing_func', 'player', 'buttons']
1132: repo['-CDN-']='http://localhost:8080/archives/repo/' does not provide want='table'
1132: repo['-CDN-']='http://localhost:8080/archives/repo/' does not provide want='drawing_func'
1132: repo['-CDN-']='http://localhost:8080/archives/repo/' does not provide want='player'
1132: repo['-CDN-']='http://localhost:8080/archives/repo/' does not provide want='buttons'
628: aio.pep0723.check_list env=PosixPath('/usr/lib/python3.11/site-packages')


[ENH] Enable HCP-style polarity-pair image averaging

The HCP pipelines run the same sampling scheme twice - once in each phase-encoding direction. Each phase-encoding direction version of the scheme is split into two files, resulting in 4 DWI scans. There are also a pair of EPI fieldmaps in the fmaps/ directory.
This PR adds the --distortion-group-merge option that can be 'none' (Default), 'average' (for HCP-style averaging) or 'concat' (produces a 4d series of the corrected input images).

Are the field maps required? The HCP Young Adult protocol has these, but the later protocols do not. The 2016 CCF protocol doesn't have any field maps before the dMRI
https://protocols.humanconnectome.org/CCF/
The HCP Aging and Development protocol acquires a SpinEchoFieldMap_[AP,PA] pair for topup, but I don't think they get gradient-echo field maps
https://www.humanconnectome.org/study/hcp-lifespan-aging/project-protocol/imaging-protocols-hcp-aging

If there are images in fmaps/ that have the dwi scans in their IntendedFor then the images from fmaps/ are used along with with b=0 images from the scans in dwi/ in TOPUP. The Lifespan sequences I've been testing have AP/PA Spin Echo fieldmaps (3 b=0 images in each direction). These get combined with 3 b=0 images from each of the dwi scans. This results in 18 total images (3 from fmaps + 3 from run 1  + 3 from run 2) x 2 PE Directions being used in TOPUP, which takes a long time to run and should probably be changed.
If there are no fieldmaps in fmaps/, then 3 b=0 images are taken from each dwi scan and used in TOPUP.
In all cases the b=0 images used are the first, middle and last b=0 images in the scan.


Uncaught SyntaxError: Identifier 'toString' has already been declared

Uncaught SyntaxError: Identifier 'toString' has already been declared
this is source code:
var Test = function (text) {

};

Test.prototype = {
    toString: function () {
        return JSON.stringify(this);
    }
};

module.exports = Test;

👍  thanks for your feedback, and I have fixed this.
It will release in next patch version


web: add test-utils tutorial

Please have a look at the tutorial for test-utils for compose-dom components.
These utils allow users to write unit-tests for their @Composable dom components.

Merging it now, but please let me know if anything needs to be improved


samples on hugging face got error?

The app you release on hugging face doesn't work, even a sample input got error.
Could you please fix this to verify the correctness of your work?
Thank you.

We haven't encountered such issues. Feel free to reopen this issue if they persist


Move info_to_provide copy beneath title

What is the context of this PR?
Moved copy for information_to_provide beneath the landing page title, inline with rest of copy. Reuse existing header html. Fixes #441.
How to review
Open the Star Wars survey, see if there is any duplication. See if it renders as per screenshot

Who worked on the PR
@iwootten

Current coverage is 78.45% (diff: 100%)

Merging #442 into master will not change coverage

@@             master       #442   diff @@
==========================================
  Files           131        131
  Lines          4854       4854
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           3808       3808
  Misses         1046       1046
  Partials          0          0

Powered by Codecov. Last update 2470c01...9197ea8

Current coverage is 78.45% (diff: 100%)

Merging #442 into master will not change coverage

@@             master       #442   diff @@
==========================================
  Files           131        131
  Lines          4854       4854
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           3808       3808
  Misses         1046       1046
  Partials          0          0

Powered by Codecov. Last update 2470c01...9197ea8

@iwootten Unrelated but the font isn't loading for some reason. Would be good to find out why in case it's a problem that happens in prod.

Current coverage is 78.45% (diff: 100%)

No coverage report found for master at d2c4fbd.

Powered by Codecov. Last update d2c4fbd...9197ea8

Current coverage is 78.45% (diff: 100%)

Merging #442 into master will decrease coverage by 0.36%

@@             master       #442   diff @@
==========================================
  Files           139        131     -8
  Lines          4951       4854    -97
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           3902       3808    -94
+ Misses         1049       1046     -3
  Partials          0          0

Powered by Codecov. Last update d2c4fbd...9197ea8

Current coverage is 78.81% (diff: 100%)

Merging #442 into master will not change coverage

@@             master       #442   diff @@
==========================================
  Files           139        139
  Lines          4951       4951
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           3902       3902
  Misses         1049       1049
  Partials          0          0

Powered by Codecov. Last update d2c4fbd...79959d1

Current coverage is 78.81% (diff: 100%)

Merging #442 into master will not change coverage

@@             master       #442   diff @@
==========================================
  Files           139        139
  Lines          4951       4951
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           3902       3902
  Misses         1049       1049
  Partials          0          0

Powered by Codecov. Last update d2c4fbd...79959d1

Current coverage is 78.81% (diff: 100%)

Merging #442 into master will not change coverage

@@             master       #442   diff @@
==========================================
  Files           139        139
  Lines          4951       4951
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           3902       3902
  Misses         1049       1049
  Partials          0          0

Powered by Codecov. Last update 2c7b9e2...79959d1

Current coverage is 78.81% (diff: 100%)

Merging #442 into master will not change coverage

@@             master       #442   diff @@
==========================================
  Files           139        139
  Lines          4951       4951
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           3902       3902
  Misses         1049       1049
  Partials          0          0

Powered by Codecov. Last update 2c7b9e2...6ce4a4f

Current coverage is 78.81% (diff: 100%)

Merging #442 into master will not change coverage

@@             master       #442   diff @@
==========================================
  Files           139        139
  Lines          4951       4951
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           3902       3902
  Misses         1049       1049
  Partials          0          0

Powered by Codecov. Last update 2c7b9e2...6ce4a4f

Current coverage is 78.81% (diff: 100%)

No coverage report found for master at 14622c6.

Powered by Codecov. Last update 14622c6...6ce4a4f

Current coverage is 78.81% (diff: 100%)

Merging #442 into master will not change coverage

@@             master       #442   diff @@
==========================================
  Files           139        139
  Lines          4951       4951
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           3902       3902
  Misses         1049       1049
  Partials          0          0

Powered by Codecov. Last update 14622c6...4c196c7


Error running hiccupsdiff

Hi, I successfully ran Juicer and got the .hic and merged_loops.bedpe for both control and experimental samples. Now I am trying to run hiccupsdiff but getting below error:
Data not available for chr1 at 5000 resolution
Data not available for chr2 at 5000 resolution
Data not available for chr3 at 5000 resolution
Data not available for chr4 at 5000 resolution
Data not available for chr5 at 5000 resolution
Data not available for chr6 at 5000 resolution
Data not available for chr7 at 5000 resolution
Data not available for chr8 at 5000 resolution
Data not available for chr9 at 5000 resolution
Data not available for chr10 at 5000 resolution and so on....
I am not able to understand what is wrong with the input files, can you please help, thank you in advance.

I have this same issue as well. Was able to run HiCCUPS, and Arrowhead on my .hic files just fine - but HiCCUPSDiff fails. Did you have any luck figuring this out? Looks like a few people have been having this issue recently (https://groups.google.com/g/3d-genomics/c/KhTpJJSNiyg/m/HubOa8dSAwAJ, https://groups.google.com/g/3d-genomics/c/eJywI41jwV0/m/-EeIW7w9BgAJ)

If anyone is still running into issues with this, I fixed my problems and got all of the Juicer tools steps to run by using an older version of juicer tools (version 1.19.02 specifically, downloaded from here: https://github.com/aidenlab/juicer/wiki/Download#version-11902).
Switching to this version of juicer tools also fixed issues I was running into when converting my output from HiC-Pro using the hicpro2juicebox.sh script.
Happy to share my syntax with anyone who needs it.

Thanks Erik, so you did all the steps with this version or just HiCCUPSDiff?
I ran HiCCUPSDiff with this version on .hic file created with another version and it failed.
Can you please share your scripts, thanks a lot!

Thanks Erik for the script, you're lucky that it worked for me.
For me v1.19.02 is unable to read my .hic files created by v.2.20.00
May be I need to run the whole pipeline with v1.19.02, but I doubt that too.
It is surprising that it didn't show any error on .hic file of HiCPro.

I can confirm that I also had to run through the whole pipeline using 1.19.02.  I also found that trying to use any juicer tools commands on the hic files I made with  2.20.00 didn’t work.
So I redid everything with 1.19.02 and it worked fine.

I successfully generated .hic file using 1.19.02 and then ran Arrowhead and hiccups on the same .hic file but didn't get loops/contacts and getting below error.
Data not available for 1 at 5000 resolution
Data not available for 10 at 5000 resolution
Data not available for 11 at 5000 resolution
Data not available for 11_KI270721V1_RANDOM at 5000 resolution
Data not available for 12 at 5000 resolution
Data not available for 13 at 5000 resolution
Data not available for 14 at 5000 resolution
........................
I got this error earlier also but it was resolved when I used v2.20.00 but couldn't run hiccupsdiff successfully this version, so I was looking for solutions.

Hmm, sorry it's not working for you!
The only other thing I can think of is that when you are running the hicpro2Juicebox.sh script you might need to specify the genome size, and restriction fragment files (using the -g and -r flags) that you used when you originally ran HiC-Pro.
Something like this:
hicpro2juicebox.sh -i CTRL_allValidPairs -g mm10_sorted_genome.fa.fai -t tmp-CTRL -o /hic2juicer -j juicer_tools_1.19.02.jar -r mm10_sorted_genome.fa.mm10_GATC_GANTC_no_chr_with_MT.bed

Erik Parker, PhD
Biostatistician I
Biostatistics Consulting Center
Department of Epidemiology and Biostatistics
School of Public Health-Bloomington
Indiana University
2719 E. 10th Street, 224
Bloomington, IN 47408
<EMAIL_ADDRESS>biostats.indiana.eduhttps://biostats.indiana.edu/

From: Rahul Kumar @.>
Sent: Wednesday, June 14, 2023 2:35 PM
To: aidenlab/juicer @.>
Cc: Parker, Erik @.>; Comment @.>
Subject: [External] Re: [aidenlab/juicer] Error running hiccupsdiff (Issue #312)
This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.
I successfully generated .hic file using 1.19.02 and then ran Arrowhead and hiccups on the same .hic file but didn't get loops/contacts and getting below error.
Data not available for 1 at 5000 resolution
Data not available for 10 at 5000 resolution
Data not available for 11 at 5000 resolution
Data not available for 11_KI270721V1_RANDOM at 5000 resolution
Data not available for 12 at 5000 resolution
Data not available for 13 at 5000 resolution
Data not available for 14 at 5000 resolution
........................
I got this error earlier also but it was resolved when I used v2.20.00 but couldn't run hiccupsdiff successfully this version, so I was looking for solutions.
—
Reply to this email directly, view it on GitHubhttps://github.com/aidenlab/juicer/issues/312#issuecomment-1591792829, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AF63RA3OTQFSNOBIMU75S7DXLH777ANCNFSM6AAAAAAXTK6R2Y.
You are receiving this because you commented.Message ID: @.***>

Hi,
so, I just ran into this issue (while running everything with juicertools 2.20.00). To reiterate, hiccups works and it generates the expected merged_loops.bedpe file. However, hiccupsdiff fails, with the following error:
$ java -jar juicer_tools.2.20.00.jar hiccupsdiff  DNMT3Amut55.allValidPairs.hic DNMT3Awtc13.allValidPairs.hic merged_loops.bedpe merged_loops.bedpe output/

....
Running HiCCUPS with alternate loop lists
Running HiCCUPS for resolution 10000
Data not available for chr1 at 10000 resolution
Data not available for chr2 at 10000 resolution
Data not available for chr3 at 10000 resolution
......
HiCCUPS complete
File output/file1/requested_list_10000.bedpe could not be parsed
File output/file2/requested_list_10000.bedpe could not be parsed

I will try the suggestion by @erikpark and update my findings. Thanks in the meanwhile.
Can the developers respond, please?

Dear @erikpark,
I am running into the same issue that @rahulk87 faced, I think. With juicertools 1.19.02, the hicpro2juicebox.sh generates a *.hic file. But hiccups does work on it. I am now trying regenerating the *.hic file using the -r (restriction fragment) argument in the hicpro2juicebox.sh script.
In comparison with juicertools 2.20.00, hiccups works, but hiccups diff does not work.
Thanks in advance for any suggestions.

A quick, happy update:
Turns out that all my issues were related to not using the right the right normalization string in the "-k" option. For example, using "-k SCALE" for *.hic files generated using juicertools.2.20.00 works all the way through to hiccupsdiff.


Settings from SDK-DIR/etc/tornado.properties are ignored for default platform/device

Settings specified in SDK-DIR/etc/tornado.properties file are ignored.
In particular, setting tornado.platform and tornado.device has no effect.
There is a method OpenCL.defaultDevice that uses these properties, but the method itself is not used anywhere.

Created a PR that overcome the limitation (inability to set VM-wide default driver/device).