add tests

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@e9cb438). Click here to learn what that means.
The diff coverage is 20%.

@@            Coverage Diff            @@
##             master       #7   +/-   ##
=========================================
  Coverage          ?   21.62%
=========================================
  Files             ?        3
  Lines             ?       74
  Branches          ?        0
=========================================
  Hits              ?       16
  Misses            ?       53
  Partials          ?        5

Impacted Files
Coverage Δ

pkg/server/udp.go
59.25% <20%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e9cb438...cbc76b6. Read the comment docs.


Validation loss always 0.

I am training my network with mixed input data (numeric and images). However, during traing the validation loss remains always 0. I tried different loss functions but have the same problem.
I tried to use the solution from https://github.com/tensorflow/tensorflow/issues/42053 , but it does not work and also i am using stand alone keras not tf.keras.
Can someone provide with some suggestions?
tf-version = 2.1.0
keras version = 2.3.1

@ArpithaFAU It is strange.  Are you using funtional model with two input branches? Can you share a standalone code to reproduce the issue? Thanks!

This is a stale issue. I am assuming this was got resolved already. If not, please reopen with a standalone code. Thanks!

I get the similar error, any update on this?

i have the same problem

Try changing the loss in your model.fit from loss="categorical_crossentropy" to loss="binary_crossentropy"
I Had the SAME problem, but this worked for me. The thing is that I have a binary classification model, with only 1 output node, not a multi-classification model with multiple output node, so loss="binary_crossentropy" is the appropriate loss function in this case.
😊


Keeping only the needed Image edit options after cropping the image.

Is there any way we can give only few image edit options after cropping the image to the user.
For example :

User clicks the image.
Then crop the image options appear (edge detection)
Next screen there are edit options such as Rotate left,rotate right,B&W,MAGIC,etc

is there any way we can provide only few edit options out of all this for ex we provide only Magic and rotate options.
I tried to look for any parameters to pass with the options object in the scanDoc()
scan.scanDoc(successCallback, errorCallback,opts);
but i cant find any. Please help.

Hey @shreyask12
Currently this isn't possible with the plugin.
But it is an interesting feature and I'll add it to our enhancement backlog.
For your immediate use, you could fork the scanlibrary repo in this github account and remove those buttons in the android code manually. If you would like to contribute to this plugin, I will gladly guide  / work with you in making the appropriate changes.
Cheers,
Chris
Neutrinos

Thanks for your reply i would like to contribute to the plugin but for immediate use could you please guide me how to remove those buttons from the android code manually through the scanlibrary.

Hey @shreyask12
If you understand android native code it is pretty straight forward. You can fork the library then just disable the buttons in the xml layout using the android:visibility = "gone" xml property. Then change the build.gradle file in this plugin to point to your fork of the scanlibrary.
Locking the conversation on this issue as it seems like it is going off topic. Won't close it though since it is an enhancement we might take up in the next release.
Cheers,
Chris
Neutrinos

hey Chris, I did as you pointed out in the xml library and disabled the buttons but i am not able to point out to the forked @scanlibrary to the build.gradle. I am still getting the buttons visible even after changing the build.gradle to my forked scanlibrary.
this is my build.gradle after changing
allprojects {
repositories {
maven {
url 'https://jitpack.io'
}
}
}
dependencies {
implementation 'com.github.shreyask12:scanlibrary:2.3'
}
earlier it was
dependencies {
implementation 'com.github.NeutrinosPlatform:scanlibrary:2.3'
}

The 2.3 here represents the release version. You have to create a release on github to get that version's build, if not you have to use master-snapshot. Refer to this to get the latest snapshot builds.
Also your current build is failing.
I am assuming you are changing the build.gradle from android studio. Instead you can just change it within your fork of the plugin. Then install that plugin using cordova plugin add https://github.com/shreyask12/cordova-plugin-document-scanner
Cheers,
Chris
Neutrinos

Thanks @ChrisTomAlx for your help, i achieved what i was looking for with your instructions. But there is still one issue i.e the size of the app increases drastically from 10mb to 45 mb on installing the plugin.
i tried the solution provided by you in earlier issue from https://github.com/NeutrinosPlatform/cordova-plugin-document-scanner/issues/45
it reduces the apk size from 45 to 35 mb but my original apk size before installing the plugin was 10mb.

Yea that is expected behavior since we are adding the opencv library to perform image manipulations. opencv is a huge library and this can't be helped. The only advice I can give is to remove some of the other architectures (maybe the 32 bit architectures, although this might cause the app not to work in older phones).
Closing this issue now.
Cheers,
Chris
Neutrinos


Update pimd to RFC4601

Currently pimd implements RFC2362, which is a previous PIM-SM experimental RFC, plus some changes from early drafts of RFC4601.
All new implementations following RFC4601 should be backwards compatible.  This issue has been filed as a reminder to start working out differences and iron out TODOs to reach full RFC4601 compliance.
For details See http://datatracker.ietf.org/doc/rfc4601/ and complementary RFC5059 and RFC5796.

With the recent merge of the pull request for PIM-SSM and IGMPv3 support, and the fix for #5,
this issue is nearing completion.
Anyone interested may want to test the upcoming pimd v2.3.0 and see if it holds up to RFC4601.


Add UbiRider to Mobility section

Hello,
This merge request adds UbiRider, a digital platform for urban mobility for providers and end users, to the Mobility section.

Thank you @leandromuto!


BLEU of LeakGAN is much lower than in the original paper

BLEU-2 of LeakGAN in WMT is 0.956 in the original paper, whereas it's 0.835 here. Notably, BLEU score of LeakGAN and that of other models for COCO diminished in your benchmark. Do you know what caused the difference? In order to compare my model with the ones in your benchmark, am I supposed to make every words in lower case by using .lower() as suggested in text_process.py? Lower-case-only generation wasn't done in LeakGAN, which regarded 'A' and 'a' to be different, so that may be one factor for the aforementioned difference.

Hi, why is this issue closed?  Could you please explain the reason of lower performance? I'm confused about this issue, thanks a lot!


Peek Definition is not working with SQL 2017 created databases\tables. RTM CU5

SQL Operations Studio Version: 27.3

Steps to Reproduce: SQL 2017 RTM CU5.

Create a new database
2 Create a table and columns
Try and use the Peek Definition in a new query window

I wonder if there's a way we can be smarter about how we cache Intellisense results when doing things like creating databases.
As a workaround you can refresh the cache yourself by opening the command palette (ctrl+p) and running the "Refresh IntelliSense Cache" command

I couldn't repro this on the July release.  I think one key step in the repro is when doing Try and use the Peek Definition in a new query window you need to make sure that the new query window is open with a connection to the database created in step 1.
Please reactive with additional repro steps if the problem persists.


inconsistent camelcase

multi word functions like setAngle use camelcasing, but goto does not. should be goTo?

Yes, it should be good to have uniform camel casing everywhere.

It's funny because it's actually switched back and forth. Alright let's go with goTo.
We'll have to update the gallery and workshops

hello! i can take care of this issue

Hmm. Could it be made to be backwards compatible?
I have some code that uses goto,.....

now that I think of it… what if blot functions weren’t case-sensitive?
On Mon, Sep 25, 2023 at 16:45 V205 @.***> wrote:

Hmm. Could it be made to be backwards compatible?
I have some code that uses goto,.....
—
Reply to this email directly, view it on GitHub
https://github.com/hackclub/blot/issues/131#issuecomment-1734438324, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AUCK4MDUDHKY2QLIHVNLKI3X4HUPRANCNFSM6AAAAAA5F7G7HU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Should be following camel case.
What does sprig use?

Just update your code @V205Arduino


index error with a spikeglx neuropixels files

When I try to open a set of imec.ap.bin/imec.ap.meta files I get this error (when I pass the folder in which only these two files are present):
>>> from neo import SpikeGLXIO
>>> sg = SpikeGLXIO('/mnt/scrap/catalyst_neuro/sakshamsharda/shenoy/PrimateNeuropixel/P20180323')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sakshamsharda/miniconda3/envs/giocomo_lab_nwb/lib/python3.7/site-packages/neo/io/spikeglxio.py", line 11, in __init__
    BaseFromRaw.__init__(self, dirname)
  File "/home/sakshamsharda/miniconda3/envs/giocomo_lab_nwb/lib/python3.7/site-packages/neo/io/basefromrawio.py", line 74, in __init__
    self.parse_header()
  File "/home/sakshamsharda/miniconda3/envs/giocomo_lab_nwb/lib/python3.7/site-packages/neo/rawio/baserawio.py", line 185, in parse_header
    self._parse_header()
  File "/home/sakshamsharda/miniconda3/envs/giocomo_lab_nwb/lib/python3.7/site-packages/neo/rawio/spikeglxrawio.py", line 67, in _parse_header
    self.signals_info_list = scan_files(self.dirname)
  File "/home/sakshamsharda/miniconda3/envs/giocomo_lab_nwb/lib/python3.7/site-packages/neo/rawio/spikeglxrawio.py", line 221, in scan_files
    seg_index = int(r[0][0])

The folder contains the files named:
P20180613/P20180613.imec.ap.bin
P20180613/P20180613.imec.ap.meta
Are the files expected to be in a specific naming format?

if a folder only contains 1 of .ap.bin and .meta file without the tags of '*.g0_t0.imec0*ap.in' in the file name, then would it make sense to assume only 1 segment and stream?
Currently the header pulls the segment and stream from the file name like here .I'm not sure if the above mentioned file naming scheme is an edge case or something that can be incorporated into the api?

Yes of course.
We have to change this and add any pattern which is possible.
Can you make a PR ?

@Saksham20 Any news on this?

Same issue as https://github.com/NeuralEnsemble/python-neo/issues/1337 conceptually. Can be fixed together.

I think with our newest version of spikeglx we cover many more regex possibilities. Feel free to reopen if the latest version doesn't cover your issue.


Setup New Merkle Trees for DIDs

Sets up new merkle trees for DIDs.
Adds new key signing claims to the existing and new trees.
Allows adding multiple key signing claims to trees.
Adds check for existing tree for a DID.

This tries to create a new tree on did save and checks tree existence on claim save.  Let know if this is a sound strategy and if this code make sense at all.  Seems like we could get rid of the tree existence check and just re-use CreateNewTreeForDID in all places.
cc/ @walfly

going to make some updates to use createtreefordid before merging.

@walfly let me know what you think of the last commit I made here.  did a little renaming so it makes a little more sense.


[SPARK-29010][SQL] Cast decimal to float type may lost precision when don't allow loss

What changes were proposed in this pull request?

Why are the changes needed?
Decimal may lost precision when user don't allow decimal precision loss

Does this PR introduce any user-facing change?
No

How was this patch tested?
Added Unit test.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@mgaido91  Hi, I saw you worked on this file. Can you help to review?

I don't agree with this. It avoids loss in favor of overflow...other DBs do the same as Spark was doing before this patch...I don't agree with this change honestly...
The flag spark.sql.decimalOperations.allowPrecisionLoss means that operations between decimals should or not allow precision loss... it shouldn't control how we choose casting rules...

get. thanks for your suggestion.


Use https instead of http

Thx for your PR. This changes look good, but doesnt merge cleanly right now.
I will take care of it when back on a real computer.

@staabm
are you able to update/merge this? If not, I can make the changes and merge it myself, but want to give you a chance to carry it through.

Please merge it yourself.

Fixed the merge conflict locally and squashed the commits into one 3c03198
Thanks @vanillajonathan for your contribution :)

Thanks for fixing the merge conflict and merging it. :)


Bank account is test account (GitHub Sponsors)

The documentation currently still lists these:

Routing number: 123205054
Account Number:<PHONE_NUMBER>

However according to Stripe this is a test account that can not be used in live mode:

So you might want to check your bank account / account number and I'll probably also have to contact Stripe, because due to that error message I won't also be able to change it to the correct number.
Too bad already 40 USD went there on Jul 22 :S
Edit: (And they didn't arrive in our https://opencollective.com/advancedfx yet, so they might be lost.)

@alanna we need to update this with the new OSC bank account - can you please coordinate with github?

I will get this updated in the docs ASAP. Sorry @dtugend - we changed our bank account and forgot to update it here. I'm just confirming the details.

@dtugend - I have updated the documentation. The routing number is the same but the account number should be<PHONE_NUMBER>.
I will also contact Github about your past transaction. We should be able to find the funds and get them to the right place.

Thank you very much.
I was able to change the account number to the new one this time (don't know why it worked this time).
Would be awesome if the founds are not lost, but we'll survive if they are as well.
I am personally wondering if this problem might affect others and how to inform them, but I don't know.

@dtugend - I'm glad you were able to update it.
I am in touch with Github and I've asked them if all the Collectives need to do anything about the new bank account number (and about your $40). We didn't think about this soon enough but we'll find a solution! Thanks for bringing it up.
I will close this issue now.


Handle weird Linux edge cases.

the title.
pug.

#JustLinuxThings

Please remove everything that is not a relevant change e.g. gumshoe.yyp

Done.

Looks good! Couple requests aimed at cleaning up global namespace:

Please make global.gumshoe_force_lower_case an optional argument. I don't mind breaking compatibility and making this a GMS2.3.7+ library so feel free to rewrite the parameters using the newer syntax
Please make global.__gumshoe_* "private" globals into statics inside the function itself

I really like the comments you've put in, those are very helpful for developers to understand the differences. Thank you for putting those in.

Updated. (also I do care about 2.3.6 a bit ;-;)

Perfect! Thank you Nik


Cesium for Unity And ParticleSystem

The development environment is Unity2021.3.27. When CesiumForUnity is used, ParticleSystem component is added to a Cube to simulate the wake effect, adjust the position of the camera, and the particles also move with the camera. How can I solve the problem to change the position of the camera, the ParticleSystem remains stationary relative to the ground.
What happens now is that when the camera changes position, the particle system follows the Cube through height and position movements, which looks strange.

If you're using the default Cesium for Unity camera, you'll notice there's a CesiumOriginShift component on it. That means that the origin of the Unity world will move as the camera moves. In order to keep an object anchored to the globe when the origin shifts, you need to add a CesiumGlobeAnchor component to that object. This is covered in this tutorial:
https://cesium.com/learn/unity/unity-placing-objects/
Hopefully this is possible (and works) with particles. If not, the next option is to remove the CesiumOriginShift component. That will be fine if your camera will stay contained to a relatively small area, but you'll see precision problems as the camera ventures far from the origin.
Please post further questions to the community forum. We use github issues only for bug reports and feature requests.


API introspection for API tab doesn't understand @property

I tried to annotate the fields of os.uname's return type with @property but that meant they didn't appear in the API tab.
The analysis we do inside of Pyright should be amended to cope with @property so we have this option going forward.

I'm not sure we're ever going to prioritise this. It'd only be if we bumped up against it in a more critical/visible API area. Closing for now.


Critical error. Can't open file at all

I can't open this templ file at all. It just won't open and just show the go file that it belongs to instead of opening the file in a tab:
package components

// Global name variable for example
var GlobalName string = ""

// Similar to YourNameIs, but uses the server's global name variable.
templ YourNameIsGlobal() {
	if GlobalName == "" {

Global name is empty

	} else {

Global name is { GlobalName }

	}
}

I don't think you've provided enough information to troubleshoot this, or to help others understand what the issue is.
I'd consider taking an MP4 screen capture of what you're talking about, along with an explanation and posting it.

Closing this as insufficient information.


Bug: Background color only applied to the first cell after dragging table cells

Lexical version: v0.12.4
Steps To Reproduce

Visit Lexical Playground: https://playground.lexical.dev/
Create a table.
Drag the table cells as needed.
Change the background color.
Note that the background color is applied only to the first cell, not the entire selection.

The current behavior
After dragging table cells, the background color is only applied to the first cell.
https://github.com/facebook/lexical/assets/70982342/9b3446d7-1202-43fa-8686-281619cffce5
The expected behavior
When multiple cells are selected, the background color should be applied to each cell.
https://github.com/facebook/lexical/assets/70982342/2789479f-e30b-4c3c-a719-86a957cf463e

This has been fixed


Feat/stable funcs

makes the functions returned from useActiveToasts more stable to prevent infinite/unnecessary renders
moves some tests into their parent describe blocks
fixed a bug when maxToasts <= 0
updated tests to condense some act blocks
updated tests to use inlineSnapshot to make some of the checks a bit simpler

best viewed without whitespace

Thank you! @TomPridham

Thank you!


Various optimizations

Hi, basically I was just messing around and did some benchmarking, found some interesting things, so I made some changes. Mostly to do with removing some of the branches and created a SIMD version of finding CRLF that doesn't need to walk the whole payload twice(worst case)
Below are the benchmark results
OSX (el capitan, mbp 13" early 2015, 3.1 GHz Intel Core i7)
Clang

time(master)
req/s(master)
time(new)
req/s(new)
percent

5.761632
867809.687500
5.104409
979545.312500
11.4069

5.769115
866684.062500
5.104001
979623.625000
11.5289

5.803461
861554.875000
5.086198
983052.625000
12.3592

5.779534
865121.687500
5.082990
983672.937500
12.0519

5.762670
867653.375000
5.092542
981827.875000
11.6288

GCC 4.9

time(master)
req/s(master)
time(new)
req/s(new)
percent

4.297466
1163476.375000
3.787979
1319965.000000
11.8555

4.159397
1202097.250000
3.774015
1324849.000000
9.26533

4.230322
1181943.125000
3.788900
1319644.250000
10.4347

4.214539
1186369.375000
3.772407
1325413.750000
10.4906

4.162938
1201074.750000
3.763118
1328685.375000
9.6042

ubuntu 14.04 ( Intel Core i7-6700 @ 3.40GHz )

time(master)
req/s(master)
time(new)
req/s(new)
percent

3.186016
1569358.000000
2.815905
1775628.000000
11.6167

3.186449
1569144.875000
2.846761
1756382.125000
10.6604

3.190864
1566973.625000
2.877822
1737425.125000
9.81057

3.183230
1570731.625000
2.813425
1777193.250000
11.6173

3.190520
1567142.625000
2.849443
1754728.875000
10.6903

I am not sure how to ignore whitespace when you view the diff, the changes are actually very minimal

@shekhei you can use https://github.com/nodejs/http-parser/pull/342/files?w=1 to see the diff without whitespace changes.
BTW it looks like the style in this file is to use lower-case for labels, not upper-case as you have for HEADER_FIELD_BEGIN

@shekhei thank you for doing this! I've experimented with vector intrinsics some time before, but for whatever reason I had at the moment decided to not proceed further.
Is the most of the speedup achieved by using vector intrinsics? How much do other changes contribute?

It seems like they each contribute to approximately half of the speed up. The fallthroughs about 10%, the h_general jmp was about another 20%, the vector speedups is slightly more interesting, it really depends on the size of the header values :)
I was really surprised about the gcc and clang difference though, if i use gcc 6 to compile it, my god its almost twice as fast as the clang one on osx.

@craig65535 you are right, let me modify them to lower case, and using snake for function names.

hmm.. any news on this pr?

hmm... :P

hmm... any news?

Eager to see this landed. I get about a 21% speedup on an i7-7700HQ on Windows.
Just tested a wider version (256 bits, requiring AVX2) and get another 8% on top of that. This SSE2-only version needs no dispatching though, which makes it easy. Happy to help with an AVX2 implementation (using either preprocessor directives or dispatching) if there's interest, though.

Ok, it seems like my whole branch has gone cranky after not updating for so long, let me clean it up

Ok, latest changes made

@indutny What do you think of landing this awesome PR? Will be nice to have this core part of node.js sped up!

This PR is awesome indeed!
I'll try to find time to review it this week. Sorry for not doing it sooner?
@bnoordhuis @mscdex your help would be very appreciated.

It would be interesting to see how much of a difference there would be in using NEON on ARM for the parts using intrinsics. I might try that this weekend.

Clang doesn’t define __GNUC__, yet it does support emmintrin.h, please we need to remove the __GNUC__ checks and just leave __SSE2__ to make this code efficient also with clang.

Clang does define __GNUC__ actually. (Have you found some version that doesn't?)

Well, here it wasn’t compiling that part and it was because of that __GNUC__ check. I'll dig deeper.

Did you have -march=[something with at least SSE2 or -msse2?

Ok I just added a NEON-based implementation and I see ~13% improvement when testing on an Odroid C2:
Before:
Benchmark result:
Took 29.264072 seconds to run
170857.968750 req/sec

After:
Benchmark result:
Took 25.583895 seconds to run
195435.453125 req/sec

FWIW here is my patch on top of this PR as it currently stands:
--- http_parser.c	2017-09-23 16:50:15.330221304 -0400
+++ http_parser-neon.c	2017-09-23 16:52:40.372395441 -0400
@@ -443,7 +443,7 @@
     }                                                         \
     ch = *++p;                                                \
     ++parser->nread;                                          \
-  } else                                                      \
+  }

 /**
@@ -485,19 +485,17 @@

 const char* find_crlf(const char* p, const char* data, size_t len);

+#ifndef USE_INTRISICS_CRLF
+# define USE_INTRISICS_CRLF 1
+#endif
+
+#if USE_INTRISICS_CRLF && (defined(_MSC_VER) || (defined(__SSE2__) && defined(__GNUC__)))
 #if defined(_MSC_VER) // SSE2 is baseline
 #include <intrin.h>
 #define __builtin_ctz _tzcnt_u32
 #elif defined(__SSE2__) && defined(__GNUC__)
 #include <emmintrin.h>
 #endif
-
-#ifndef USE_INTRISICS_CRLF
-# define USE_INTRISICS_CRLF defined(_MSC_VER) || (defined(__SSE2__) && defined(__GNUC__))
-#endif
-
-#if USE_INTRISICS_CRLF
-
 int32_t get_crlf_mask(const char* p) {
   /* [ c, 0, 0, 0, 0, 0 .. 0 ] */
   const __m128i vCR = _mm_set1_epi8(0x0a);
@@ -539,9 +537,63 @@
   }
   return p;
 }
+#elif USE_INTRISICS_CRLF && defined(__ARM_NEON)
+#include <arm_neon.h>
+const uint8_t __attribute__ ((aligned (16))) _powers_array[16] =
+  { 1, 2, 4, 8, 16, 32, 64, 128, 1, 2, 4, 8, 16, 32, 64, 128 };
+uint8x16_t _powers;
+uint8_t _powers_init = 0;
+uint16_t get_crlf_mask(const char* p) {
+  /* [ c, 0, 0, 0, 0, 0 .. 0 ] */
+  const uint8x16_t vCR = vdupq_n_u8(0x0d);

-#else
+  /* [ c, 0, 0, 0, 0, 0 .. 0 ] */
+  const uint8x16_t vLF = vdupq_n_u8(0x0a);
+
+  uint8x16_t v1, v2;
+  v1 = *(uint8x16_t*)p;
+  v2 = vceqq_u8(vCR, v1);
+  v1 = vceqq_u8(vLF, v1);
+  v2 = vorrq_u8(v1, v2);
+
+  // Compute the mask from the input
+  uint64x2_t mask = vpaddlq_u32(vpaddlq_u16(vpaddlq_u8(vandq_u8(v2, _powers))));
+
+  // Get the resulting bytes
+  uint16_t output;
+  vst1q_lane_u8((uint8_t*)&output + 0, (uint8x16_t)mask, 0);
+  vst1q_lane_u8((uint8_t*)&output + 1, (uint8x16_t)mask, 8);
+
+  return output;
+}
+
+const char* find_crlf(const char* p, const char* data, size_t len) {
+  const char* lastp = MIN(data + len, HTTP_MAX_HEADER_SIZE + p);
+
+  int32_t result = 0;
+
+  size_t alignment = (long) p & 15;
+  p -= alignment;
+
+  result = get_crlf_mask(p + 16) << 16 | get_crlf_mask(p);
+  result = (result >> alignment) << alignment;

+  if (!result) {
+    while (!result && lastp >= p + 32) {
+      p += 32;
+      result = get_crlf_mask(p + 16) << 16 | get_crlf_mask(p);
+    }
+    if (!result) {
+      return data + len;
+    }
+  }
+  p += __builtin_ctz(result);
+  if (p >= lastp) {
+    return data + len;
+  }
+  return p;
+}
+#else
 const char* find_crlf(const char* p, const char* data, size_t len) {
   const char* p_cr;
   const char* p_lf;
@@ -563,7 +615,6 @@
   }
   return p;
 }
-
 #endif

 /* Our URL parser.
@@ -2181,6 +2232,13 @@
   parser->type = t;
   parser->state = (t == HTTP_REQUEST ? s_start_req : (t == HTTP_RESPONSE ? s_start_res : s_start_req_or_res));
   parser->http_errno = HPE_OK;
+#if USE_INTRISICS_CRLF && defined(__ARM_NEON)
+  // Only create the powers list once
+  if (_powers_init == 0) {
+    _powers = vld1q_u8(_powers_array);
+    _powers_init = 1;
+  }
+#endif
 }

 void

@Kronuz actually I have tested it on clang too, it works, maybe you can share which version you are using?

I've updated my patch a bit.
I'm also wondering if the fallback code might benefit from a SWAR implementation over the current dual memchr() solution?

@mscdex I did try optimizing with packing into some 64bit and then comparing them, I don't think the improvements were significant, also given that memchr is always optimized for a specific platform, if my memory serves me right, it started losing out rather quickly.
I might be wrong though.

made some changes to ensure not going before or after requested bounds within findcrlf, did a bench, almost no drop in performance

hmm... I have added some tests a while ago, any comments? or anything else that I should change?

@shekhei It looks like there was a build error during the last CI run.

Ah, it seems like it is stricter with gcc, i have modified, lets see how's the build

Ok made some changes according to comments

Still green. LGTM if the suggestion made by @bnoordhuis about HTTP_MAX_HEADER_SIZE + p is not a blocker.


CASSANDRA-14888 Several mbeans are not unregistered when dropping a keyspace and table

@maedhroz updated the PR based on your suggestions, let me know if you want to dig deeper into the MV tests, or if this is sufficient.

@maedhroz very good suggestion! I changed the tests to include the metrics in the error message.

@stillalex I think we're probably good to commit this, although squashing first might make it easier for the committer ;)


Implement 'write-zip-archive' command

In leoFileCommands.ts, implement @tbpassin 's 'write-zip-archive' with the JSZip library now available as g.JSZip

I remember posting that we need something like this, but I didn't write it.  I didn't even realize that the command had been written (!).


Helm hooks delete capsule-tls and capsule-ca secrets

Helm hook resources are removed after installs and upgrades. The following lines cause the tls and ca secrets to be deleted, preventing the deployments from scaling up successfully:
https://github.com/clastix/capsule/blob/16906db309ab5d8a952bb818e600601dd990d31c/charts/capsule/templates/certs.yaml#L5
https://github.com/clastix/capsule/blob/16906db309ab5d8a952bb818e600601dd990d31c/charts/capsule/templates/ca.yaml#L5
This is visible in the debug output:
$ helm upgrade capsule clastix/capsule -n capsule-system --debug
upgrade.go:121: [debug] preparing upgrade for capsule
upgrade.go:449: [debug] copying values from capsule (v15) to new release.
upgrade.go:129: [debug] performing update for capsule
upgrade.go:301: [debug] creating upgraded release for capsule
client.go:187: [debug] checking 13 resources for changes
client.go:236: [debug] Deleting "capsule-ca" in capsule-system...
client.go:236: [debug] Deleting "capsule-tls" in capsule-system...
upgrade.go:136: [debug] updating status for upgraded release for capsule
Release "capsule" has been upgraded. Happy Helming!

The events for the pod show:
Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Normal   Scheduled    4m18s                default-scheduler  Successfully assigned capsule-system/capsule-controller-manager-5859f98bcf-9sbfm to ip-X-X-X-X.ec2.internal
  Warning  FailedMount  8s (x10 over 4m17s)  kubelet            MountVolume.SetUp failed for volume "cert" : secret "capsule-tls" not found
  Warning  FailedMount  0s (x2 over 2m15s)   kubelet            Unable to attach or mount volumes: unmounted volumes=[cert], unattached volumes=[cert capsule-token-l6hgq]: timed out waiting for the condition

Thanks for reporting this, really appreciated
I'm having some issues trying to replicate this:

helm upgrade --install capsule clastix/capsule -n capsule-system --create-namespace
helm upgrade capsule clastix/capsule -n capsule-system

Checked the secrets but these are not deleted.
Which version of the Chart are you using?
NAME      NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
capsule capsule-system  8               2021-01-21 19:56:46.178567454 +0100 CET deployed        capsule-0.0.8   0.0.4

Thanks for reporting this, really appreciated
I'm having some issues trying to replicate this:

helm upgrade --install capsule clastix/capsule -n capsule-system --create-namespace
helm upgrade capsule clastix/capsule -n capsule-system

Checked the secrets but these are not deleted.
Which version of the Chart are you using?
NAME      NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
capsule capsule-system  8               2021-01-21 19:56:46.178567454 +0100 CET deployed        capsule-0.0.8   0.0.4

I was attempting to install chart version 0.0.10.

I was attempting to install chart version 0.0.10.

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "clastix" chart repository
Update Complete. ⎈Happy Helming!⎈

$ helm upgrade capsule clastix/capsule -n capsule-system --debug
NOTES:
- Capsule Operator Helm Chart deployed:

   # Check the capsule logs
   $ kubectl logs -f deployment/capsule-controller-manager -c manager -n capsule-system

   # Check the capsule logs
   $ kubectl logs -f deployment/capsule-controller-manager -c manager -ncapsule-system

- Manage this chart:

   # Upgrade Capsule
   $ helm upgrade capsule -f <values.yaml> capsule -n capsule-system

   # Show this status again
   $ helm status capsule -n capsule-system

   # Uninstall Capsule
   $ helm uninstall capsule -n capsule-system

$ helm list
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
capsule capsule-system  9               2021-01-21 20:35:19.849222304 +0100 CET deployed        capsule-0.0.10  0.0.4

It's really weird, I have no idea how to reproduce it.

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "clastix" chart repository
Update Complete. ⎈Happy Helming!⎈

$ helm upgrade capsule clastix/capsule -n capsule-system --debug
NOTES:
- Capsule Operator Helm Chart deployed:

   # Check the capsule logs
   $ kubectl logs -f deployment/capsule-controller-manager -c manager -n capsule-system

   # Check the capsule logs
   $ kubectl logs -f deployment/capsule-controller-manager -c manager -ncapsule-system

- Manage this chart:

   # Upgrade Capsule
   $ helm upgrade capsule -f <values.yaml> capsule -n capsule-system

   # Show this status again
   $ helm status capsule -n capsule-system

   # Uninstall Capsule
   $ helm uninstall capsule -n capsule-system

$ helm list
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
capsule capsule-system  9               2021-01-21 20:35:19.849222304 +0100 CET deployed        capsule-0.0.10  0.0.4

It's really weird, I have no idea how to reproduce it.

Ok, finally I was able to replicate the issue: thanks for reporting this, I'll try to find a viable solution!

Ok, finally I was able to replicate the issue: thanks for reporting this, I'll try to find a viable solution!


Rename variables

Closes #354
Phew, I honestly can't believe I managed to complete it - it's fully working transformer that renames variables (and somehow doesn't trip on various Robot Framework syntax). There could be some edge cases still missing but I can cover them in the upcoming releases.
This PR is last in current release - I will relase 4.0 after it.

Codecov Report
Patch coverage: 97.80% and project coverage change: -0.02 :warning:

Comparison is base (e2d1e56) 97.15% compared to head (5670090) 97.14%.

:exclamation: Current head 5670090 differs from pull request most recent head 42db026. Consider uploading reports for the commit 42db026 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #502      +/-   ##
==========================================
- Coverage   97.15%   97.14%   -0.02%
==========================================
  Files          48       49       +1
  Lines        4360     4588     +228
==========================================
+ Hits         4236     4457     +221
- Misses        124      131       +7

Impacted Files
Coverage Δ

robotidy/transformers/__init__.py
95.72% <ø> (ø)

robotidy/transformers/RenameVariables.py
97.80% <97.80%> (ø)

... and 5 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


md_file_with_firststeps_for_installing

Describes the 0-th steps necessary to run the application, describing the venv environment, poppler download and placement and the OPENAI_API_KEY (rudimentary).

Well, sorry about it, but as I shifted towards docker, I guess we can come back to this branch and update the readme so one can run the docker instead

Readme has been updated. Will close this PR


error

i got an error when i click on button
-------Tejas Lamba#1924-------
C:\Users\Dima Ursachi\Desktop\Discord-Button-Tickets-Bot-main\index.js:309
id: button.clicker.user.id,
^
TypeError: Cannot read property 'id' of null
at Client. (C:\Users\Dima Ursachi\Desktop\Discord-Button-Tickets-Bot-main\index.js:309:35)
at processTicksAndRejections (node:internal/process/task_queues:96:5)

pls join https://discord.gg/FYhRKv3D
to reeive support


The strange behavior exhibited by RigidBody2D when calling the move_and_collide() method.

Tested versions
Reproducible in: 4.0.3.stable, 4.1.stable, 4.2.1.stable, 4.3.dev2
System information
Windows 10 Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz   1.50 GHz
Issue description
https://github.com/godotengine/godot/assets/127111270/1258218c-5c2e-4a08-aa80-ae0093bf16c1
Steps to reproduce
Running and moving the window may potentially reproduce the bug.
However, sometimes I can reproduce this bug just by doing nothing, simply by running it.
Minimal reproduction project (MRP)
MRP.zip

I retested it again and found that there is still an issue.
This time, I just call the method, move_and_collide(), in the _process().
func _process(delta: float) -> void:
	rigid_body.move_and_collide(Vector2.LEFT * 200 * delta)

https://github.com/godotengine/godot/assets/127111270/a0f94ee0-13d6-44e2-96de-056918c85069

Does it work if you call it in _pysics_process?

I tested it, and it works fine in the _physics_process function.

Then that's the problem, you should always do physics in the right method I'd say, see here

Oh, I get it now!


[3.6] avoid modifying  vector without acquiring its write-lock

Scope & Purpose
Backport of https://github.com/arangodb/arangodb/pull/10621
Jenkins: http://jenkins01.arangodb.biz:8080/job/arangodb-matrix-pr/7636/

Tests blue


Gitignore

the pr is great but just btw this isn't the real code for wasteof-client it's like a version behind since I was too lazy to push so I'll have to push the real one or else I'll have a massive conflict

wasteof-client 3.0.0 is coming very soon, it has gitignore already so Ima close this


Extreme slow down of GET requests

Hi,
I added rack-timeout (v. 0.2.1) and saw extreme slowdown (ie 2s to almsost 20s) of requests on development.
Some notable gems I am using: Rails 4, Unicorn, Pry.
Here is my complete Gemfile.lock
https://gist.github.com/hakunin/aa57c0576f6489ff0a90
Removing rack-timeout solves the issue.
I should also mention that the page is computation intensive, is there anything listening on ruby stack?

My bad, I had some tracing in the branch I just checked into.


Gradle unable to resolve dependency for Materialviewpager library

I've been unable to compile Materialviewpager as a gradle dependency. I've included it exactly as specified in the documentation. I've been able to compile other third-party libraries via gradle with no problem. Please see the screenshot of the exact error below.  Thanks for your help!
dependencies {     compile ('com.github.florent37:materialviewpager:<IP_ADDRESS>@aar'){         transitive = true     } }

I tried it in a new empty project
compile ('com.github.florent37:materialviewpager:<IP_ADDRESS>@aar'){ transitive = true }
and it works,
can you send me your full build.gradle please ?

Okay - here's a gist for the full file: https://gist.github.com/eatyoveshtables/caa2b8defb4da8a3eff6

same here. @florent37  did you solve your issue @eatyoveshtables ?

can you try with 1.0.4 ?
@DevendraSingh91 can you make a pull request with this please ?

that was done @florent37  Thanks.

Hi sorry, what was the conclusion here @florent37? I just tried with version 1.0.4 and I'm getting the same error. The minSdkVersion of my project is 10 and that seems to work fine when compiling Materialviewpager as a separate library.


Block domain uniquestellar.com

Domain: uniquestellar.com
Requested by @usser0134

,

Still working on these


[helpers] check for valid ips before executing in_network

to: @ryandeivert
cc:  @airbnb/streamalert-maintainers
size: small
Background
Force the ip check in_network prior to execution
Changes

Use the valid_ip helper before running in_network

Testing
Unit testing

Coverage remained the same at 95.652% when pulling f8289e005eb54feb60511197562320aaea98c8eb on jacknaglieri-helpers-fix into 99e599b268bb5d61cc142b53d571fc7d10e87ffb on master.


Dynamic fields for hasMany with embeds

Is there a way to implement hasMany relationship which contain embeds fields. And, dynamic fields for embeds based on a key/column in hasMany relationship.
Idea is similar to this
$form->hasMany('paintings', function (Form\NestedForm $form) {
    // paintings has a field to store json
    $form->embeds('extra', function ($form) {
        // these fields can be dynamic
        // eg:
        //  id=1, we have fields: extra1 and extra2
        //  id=2 we have fields: extra1 , extra2 and extra3
        //  .....
        $form->text('extra1')->rules('required');
        $form->email('extra2')->rules('required');
        $form->mobile('extra3');
        $form->datetime('extra4');
        $form->dateRange('extra5', 'extra6', 'Date range')->rules('required');

    });
});

Do you mean this https://laravel-admin.org/docs/#/en/model-form-fields?id=hasmany ?

updated the first comment with an example

updated the first comment with an example

How did you resolve? I have a custom multipleSelect in a nestedform and i can't access index nor model :(


Update registry.yaml to add Weights & Biases examples

Summary
Update registry.yaml to add Weights & Biases examples for the cookbook website.
Changes
Update registry.yaml

Major Changes

Update registry.yaml to add Weights & Biases examples

Motivation
Discoverability on the more popularly rendered website
Self Review Checklist

[ ] Is the writing easily skimmable?

Sections have informative titles.
Key takeaways are upfront.
Short paragraphs and topic sentences are used.

[ ] Is the writing quality high?

Sentences are simple and unambiguous.
Demonstrative pronouns are avoided or clearly referenced.
No left-branching sentences.

[ ] Is the content universally helpful?

Terminology is specific and avoids jargon.
Provides solutions to common problems.
Code examples are general and exportable.

[ ] Is the content consistent?

Styling and formatting align with existing documentation.
Consistent use of punctuation and case.

When contributing a new example, make sure to add a new entry for it in registry.yaml to render it on the cookbook website.
Note: For additional guidelines on writing good documentation, check out What Makes Documentation Good.

@simonpfish I forgot to update the registry.yaml. Would appreciate a stamp

@simonpfish Added the suggestions you made. One nit, I called the Finetuning example: Fine-tuning GPT with Weights & Biases

Perfect! Merging.


Arp entries become invalid after 2s and the entry timeout callback makes the entry invalid regardless of traffic

The arp entry timeout callback ofp_arp_entry_usetime_tmo makes the entry invalid even if packets were received for that entry,

It's about:
/* Timer interval for entry use time update. */
#define ARP_ENTRY_UPD_TIMEOUT 2
In previous versions of file OFP_ARP_ENTRY_TIMEOUT was used which was 1200.
There is still a comment about OFP_ARP_ENTRY_TIMEOUT.


Feature request: WebUI and override options for Show IP address on connect

Is your feature request related to a problem? Please describe.
Commit https://github.com/HASwitchPlate/openHASP/commit/57569e7b06676dc175d2875ff8578e4e0075dfde is excellent, thank you!
To make deployments easier, please consider these:

add an option in web ui configuration to disable Show IP address on connect (could be a checkbox which is enabled by default)
add an option to user_config_override to disable auto_close of the messagebox.

Describe the solution you'd like
The reason for the first: the IP address may be unimportant for the end-user after deployment is finished (wife acceptance factor).
The reason for the second: when multiple devices are deployed, with wifi credentials burned-in with user_config_override it takes time to walk by in each room and note the IP addresses gathered, by that time the messageboxes closed. For such cases keep that info on the screen until dismissed, and when configuration is done, first option can be used to disable popup of the address on the next boot.
Describe alternatives you've considered
N/A
Additional context
N/A

In v0.6.1 the popup screen with the IP address has been removed.
The /online.cmd script will run after the wifi connects.
The idea is that you can implement a message box to show the IP.

In the next version we need to pre-create the /online.cmd with the msgbox for fresh flashes and factory resets.

#https://github.com/HASwitchPlate/openHASP/commit/d3da4957bb37e408bca1eb842e697614bbd8a522


Update Popper.js to 1.12.5

@skmedix https://www.srihash.org/ give me the same hash for 1.12.5 with this url : https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.5/umd/popper.min.js :worried:

@Johann-S Because there is no difference between these two versions. Compare them on https://diffnow.com

That's strange according to the release note here : https://github.com/FezVrasta/popper.js/releases/tag/v1.12.5

What I understand from the release notes is that we basically don't need this update since it's the same as 1.12.3.

So true @XhmikosR

I'm kind of new to this, so my apologies if this is already covered (maybe in upcoming beta 2?) or posted in the wrong place;
When using Popper v1.11.0, as suggested by the docs (in Boostrap v4 beta), I have a very hard time getting tooltips to position correctly when using 100% body height. This seems to be the issue described here:
https://github.com/FezVrasta/popper.js/issues/302
See demo: https://codepen.io/skunkbad/pen/prrOWR
Upgrading to Popper v1.12.5 solves the issue for me.

That's right @anve but Popper.js 1.12.3 and 1.12.5 are the same 😉


Initialize EventChannel state

OnCancel was fired randomly on EventChannel registering, because of uninitialized is_listening_ variable.

I think this change should be made in the upstream engine. Please consider filing an issue (or PR) in flutter/flutter (flutter/engine).

I think you are right. I will make create PR with this change to flutter/engine as soon as I get approval to the Open Source Contribution process for that repo.

I am closing it as I opened issue in the upstream: https://github.com/flutter/engine/pull/26761.

As the commit in the upstream has been merged, you can back port the change to the Tizen engine (2.2.1) before the next flutter stable version release if you want. Thank you for the work!


Add PAC cel filtering propal

Signed-off-by: Chmouel Boudjnah<EMAIL_ADDRESS>

Here is a proof of concept. The change in the annotation matcher :
https://github.com/chmouel/pipelines-as-code/commit/66b2438786dfe2e45f414b4142ab9d3af830dbcc#diff-7e21d71dc0c56798fde36ab4207d45899ac473d6287b63a93a7cbd5c0d92e484R104
The new pipelinerun that only match on a  pull_request event, target_branch main and source_branch cel_event
https://github.com/chmouel/scratchmyback/blob/9caea22/.tekton/run.yaml#L6-L7
and pipeline matches it :

I think that looks pretty nice,

Thanks for the reviews and from @siamaksade thumb up as well it seems this can get implemented.
this will open a world of possibilities for flexible pipeline and advanced matching with pac


fix(select): compare SelectOptionType by text rather than object

Please read and mark the following check list before creating a pull request:

[x] I read and followed the CONTRIBUTING.md guide.
[x] I read and followed the New Feature Checklist guide.

Short description of what this resolves:
When utilizing the multiSelect Select component, it is not possible to default a value, because the comparison is attempting to use an Object Equality.
For example within the documentation,
state = {
    selectedOption: [],
  };

change to:
state = {
    selectedOption: [{ text: 'Option 1' }],
  };

will put 'Option 1' in the input field, but when opening the selector, the value is not checked. If pressed again, it will duplicate the option.

Thanks for PR! We'll review it soon

Hi @mattlisiv! Thanks for your contribution. Unfortunately, this is not the right way to handle such issue. Anyway, thank you for finding this bug. We will fix it in the next release and describe it in the documentation.


Docs absent about using Transaction in sqlite with this package

I need to use transaction with my sqlite code in react-native. I was not able to find any documentation or post about that so I am unsure how to proceed with it. I have seen code in package addTransaction. It would be great if you can provide a code snippet or how addTransaction or startNextTransaction works and how to use them. It would be great help.
If from your guidance I would be able to do that.

Look at the demo code in test directory or check cordova-sqlite-storage repo.


New icon: ING

[x] I have carefully read and followed CONTRIBUTING document.

URL of the site: https://developer.ing.com/

Proof of the Aegis-compatible 2FA: https://developer.ing.com/openbanking/contact/support (FAQ has a "Second Factor Authentication" section)

Logo / icon info: Extracted logo with SVG Gobbler from https://developer.ing.com/

Background color info: It's from the logo (#FF6200 or #FFFFFF).

Rejected, doesn't follow CONTRIBUTING document.

Hi @krisu5, sorry for the bad PR; my bad!
I'm now working on a compliant icon version but have trouble creating something that looks good especially when scaling down (see icon versions in the bottom rows). Quick question: would it be acceptable to go beyond the template outer-guidelines as shown in the screenshot below?

Quick question: would it be acceptable to go beyond the template outer-guidelines

No, it's prohibited on the CONTRIBUTING guidelines and icon grid.
The icon on last row & center column is acceptable. Use icon grid to properly size and center the logo to the icon.


Bump up the versions and pick accelerate from branch

What's the reason for removing the package's version?
If you want to upgrade some packages, you should specific another version instead of removing it.


OK to add to Hackster article?

As title, are you happy if I mention this work on https://www.hackster.io/97766/announce-who-is-home-using-facial-recognition-dcc389 ?
Cheers

Hi Rob, that would be great. Please keep in mind that I will be on vacation the next 2 weeks, so minimal time to support/help people. (as the family deserves my time) Better to mention around the time I will be back to normal ritm (end of the month)


Remove whitelist class

The following address list lookup should be part of the core protocol.

https://github.com/yzernik/squeaknode/pull/801


Adding custom pagination total

Putting back the ability to override the default pagination totals (like paginationShowsTotal in the original react-bootstrap-table).

@sean-ww thanks, I will review it in this weekend 👍

@sean-ww,  thanks your contribution, will be released soon

Released on<EMAIL_ADDRESS>


Corrupted .ipynb file

Azure Data Studio Version:  1.12.0-insider (1-Oct daily build)

Steps to Reproduce:

I had a SQL Notebook open in ADS with unsaved changes.
I installed the 1-Oct 2019 Insiders Build, without saving changes.

I have not been able to reproduce the issue, and it just happened the one time, but I am pretty confident that this is not the result of me accidentally "keyboard tapping" (ex, if ADS froze & I was trying to wake it up). If that were the case, I'd expect to see a zillion spaces or carriage returns, but not the gibberish in this file.
Attached is a zip file containing the corrupt & repaired .ipynb files. I can't be 100% positive that the "repaired" one is exactly what the file looked like pre-corruption, but it should be very close. Note that the corrupted lines in ReplicationLatency-20191001-corrupt.ipynb are 23-43. Line 255 is also "wrong" though that could have been a typo on my part.
ReplicationLatency.zip

@vickyharp ☝ This is the issue I was talking to you about. Possibly something wonky about my own machine, since I have tried & failed to reproduce this several times in the last week with other Insiders builds. But wanted to log the issue here while details are fresh on my mind.

Potentially fixed by https://github.com/microsoft/azuredatastudio/pull/7497

If it's not clear to others reading this, the corruption follows the pattern of:

Reverse the string
Repeat each character 3 times
Append to the original line

So "ABCDE" becomes "ABCDEEEEDDDCCCBBBAAA"
But as you can see it's not done on every line and in some cases it looks like the original line is missing and only the reversed corrupt string remains.

@amtwo Is what platform are you on? Windows?

@chlafreniere Yes, Windows 10, specifically.


Disable auto tagging

Brilliant work on the project guys! However, the lack of ability to disable applying tag suggestions makes me unable to use this project :(
Generating titles works well, but suggested tags mess up my already properly set tags.
IMO, there should be an option to just not apply them, either by setting it by ENV, or somewhere on the UI.
Also, for a few larger docs, it generated a title of 1500+ characters :D Maybe some double checking if the model didn't go too far with it, and invalidating those results?
I made it analyze 50 docs at once, and with these issues, it could also be helpful being able to pick ones you want to apply, or just remove the ones you don't like :)
What do you guys think about all this? I could open some PRs with changes, but I'd like to know first if you agree with these points :)

Thanks for this suggestion! Yes, I was thinking of something like this already.
I like the idea. Originally, paperless-gpt was titles only. A few commits back is only titles 😁
If you want to try a PR, I'm more than happy to support. 😊

Hey @dawidkulpa, I tried to incorporate your idea into a redesign I wanted to do: https://github.com/icereed/paperless-gpt/pull/11
Can you give that a try?
Do you need a docker tag for that?

Oh, cool! No need for docker tag just yet, I have the repo checked out anyways, so I'll just pull the changes. and run a dev build.
I'll let you know soon :)

This feature is implemented and merged on the main branch.
Until the new release is published, this feature can be used with icereed/paperless-gpt:unreleased.


How do I access Flask current_app?

server.py

#!/usr/bin/env python3

from connexion.resolver import RestyResolver
import connexion

def create_app():
    app = connexion.FlaskApp(__name__, specification_dir='swagger/')
    app.add_api('mapmybook.yaml',validate_responses=True, strict_validation=True, resolver=RestyResolver('api'))

    return app

if __name__ == '__main__':
    create_app().run(port=9090)

api/routes.py

from flask import current_app
def get() -> list:
    print(current_app)
    return items

results in RuntimeError: Working outside of application context.
I'm using Flask 1.0 with connexion 1.4.2, creating the app as seen above. Is there a way to access Flask's current_app from other modules?
I keep getting RuntimeError: Working outside of application context. when calling current_app in API modules.

Got it, app context is only available under certain conditions.

@zimmicz I still get these errors. Can you let me know how you solved your issue? I've tried so many things but I always get this error...

Same issue here...

Can we re-open this?

I found a way: https://stackoverflow.com/questions/53941243/how-to-pass-a-variable-into-connexion-flask-app-context

What about connexion 3.0.0+
How we can access context?


Suggestion: restrict email sign-up to certain domains + allow admins to verify

e.g., only allow "*.cam.ac.uk" addresses. This should be implemented in #484.
Should also have an option to allow admins to reject account creation.

Partially closed by #484; email sign-up now restricted by config. Second part will have to wait for an admin dashboard to materialize.


chore: bump time crate

Resolves https://github.com/huggingface/llm-ls/issues/101
Version is based on this comment in upstream time repo issue https://github.com/time-rs/time/issues/681#issuecomment-2128002434

duplicate https://github.com/huggingface/llm-ls/pull/102


Merge from my fork

I forgor i was a collaborator. Here's everything I've been doing so far. Lmk how it looks 👍

you forgor :skull:

i forgor 💀


Fixing compilation problems on 32 Linux systems

Fixes #6361

New build using the patch on Fedora 39
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409303

New build using the patch on Fedora 39
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409303

@diehlpk please try again: https://github.com/STEllAR-GROUP/hpx/pull/6362/commits/af3761f791ef4cf430ab4fe7dcdd316cdf1463a7.diff

@hkaiser and a different bug

[ 34%] Building CXX object libs/full/agas/CMakeFiles/hpx_agas.dir/src/state.cpp.o
cd /builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/agas && /usr/bin/g++ -DHPX_FULL_EXPORTS -DNDEBUG -D_GNU_SOURCE -I/builddir/build/BUILD/hpx-1.9.1/libs/full/agas/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/agas/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/agas/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1 -I/builddir/build/BUILD/hpx-1.9.1/libs/full/actions_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/actions_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/actions_base/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/components_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/components_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/components_base/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/naming_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/naming_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/naming_base/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/affinity/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/affinity/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/affinity/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/assertion/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/assertion/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/assertion/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/config/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/config/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/preprocessor/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/preprocessor/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/preprocessor/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/config_registry/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/config_registry/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/format/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/format/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/format/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/datastructures/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/datastructures/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/datastructures/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/concepts/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/concepts/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/concepts/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/errors/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/errors/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/errors/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/filesystem/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/filesystem/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/filesystem/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/logging/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/logging/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/logging/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/timing/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/timing/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/timing/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/hardware/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/hardware/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/hardware/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/type_support/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/type_support/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/type_support/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/thread_support/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/thread_support/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/thread_support/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/serialization/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/serialization/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/serialization/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/debugging/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/debugging/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/debugging/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/topology/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/topology/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/topology/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/async_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/async_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/async_base/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/allocator_support/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/allocator_support/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/allocator_support/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/coroutines/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/coroutines/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/coroutines/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/functional/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/functional/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/functional/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/itt_notify/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/itt_notify/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/itt_notify/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/tag_invoke/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/tag_invoke/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/tag_invoke/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/memory/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/memory/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/memory/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/util/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/util/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/util/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/iterator_support/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/iterator_support/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/iterator_support/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/version/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/version/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/prefix/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/prefix/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/prefix/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/plugin/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/plugin/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/plugin/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/string_util/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/string_util/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/concurrency/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/concurrency/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/concurrency/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/execution_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/execution_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/execution_base/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/lock_registration/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/lock_registration/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/hashing/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/hashing/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/hashing/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/algorithms/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/algorithms/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/algorithms/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/async_combinators/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/async_combinators/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/async_combinators/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/futures/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/futures/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/futures/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/synchronization/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/synchronization/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/synchronization/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/threading_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/threading_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/threading_base/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/pack_traversal/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/pack_traversal/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/pack_traversal/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/async_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/async_local/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/execution/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/execution/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/execution/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/threading/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/threading/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/threading/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/executors/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/executors/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/executors/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/io_service/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/io_service/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/io_service/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/properties/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/properties/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/resource_partitioner/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/resource_partitioner/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/resource_partitioner/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/runtime_configuration/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/runtime_configuration/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/runtime_configuration/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/program_options/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/program_options/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/ini/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/ini/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/thread_pools/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/thread_pools/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/thread_pools/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/schedulers/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/schedulers/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/schedulers/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/lcos_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/lcos_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/lcos_local/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/asio/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/asio/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/asio/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/batch_environments/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/batch_environments/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/batch_environments/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/cache/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/cache/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/cache/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/command_line_handling_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/command_line_handling_local/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/compute_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/compute_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/compute_local/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/runtime_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/runtime_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/runtime_local/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/static_reinit/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/static_reinit/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/static_reinit/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/threadmanager/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/threadmanager/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/threadmanager/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/thread_pool_util/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/thread_pool_util/include -I/builddir/build/BUILD/hpx-1.9.1/libs/core/include_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/include_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/include_local/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/timed_execution/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/timed_execution/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/timed_execution/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/init_runtime_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/init_runtime_local/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/init_runtime_local/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/testing/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/testing/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/testing/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/core/resiliency/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/core/resiliency/include -I/builddir/build/BUILD/hpx-1.9.1/libs/full/parcelset_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/parcelset_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/parcelset_base/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/agas_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/agas_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/agas_base/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/actions/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/actions/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/actions/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/async_distributed/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/async_distributed/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/async_distributed/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/components/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/components/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/components/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/naming/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/naming/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/naming/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/checkpoint_base/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/checkpoint_base/include -I/builddir/build/BUILD/hpx-1.9.1/libs/full/parcelset/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/parcelset/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/parcelset/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/plugin_factories/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/plugin_factories/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/plugin_factories/include_compatibility -I/builddir/build/BUILD/hpx-1.9.1/libs/full/command_line_handling/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/command_line_handling/include -I/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial/libs/full/command_line_handling/include_compatibility -O2  -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -DNDEBUG -std=c++17 -fPIC -pthread -Wall -Wno-strict-aliasing -Wno-sign-promo -Wno-attributes -Wno-cast-align -Wno-use-after-free -Wno-interference-size -Wextra -Wpedantic -Wno-self-move -Wno-noexcept-type -Wformat=2 -Wno-format-nonliteral -Winit-self -Wdouble-promotion -Wcast-qual -Wcast-align -Werror=trampolines -Werror=parentheses -Werror=reorder -Werror=return-type -Werror=sequence-point -Werror=uninitialized -Werror=format -Werror=missing-braces -Werror=sign-compare -fdiagnostics-show-option -Werror=vla -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-sync-nand -Wno-delete-non-virtual-dtor -fvisibility=hidden -MD -MT libs/full/agas/CMakeFiles/hpx_agas.dir/src/state.cpp.o -MF CMakeFiles/hpx_agas.dir/src/state.cpp.o.d -o CMakeFiles/hpx_agas.dir/src/state.cpp.o -c /builddir/build/BUILD/hpx-1.9.1/libs/full/agas/src/state.cpp
/builddir/build/BUILD/hpx-1.9.1/libs/full/async_colocated/src/server/destroy_component.cpp: In function ‘void hpx::components::server::destroy_component(const hpx::naming::gid_type&, const hpx::naming::address&)’:
/builddir/build/BUILD/hpx-1.9.1/libs/full/async_colocated/src/server/destroy_component.cpp:47:58: error: no matching function for call to ‘bit_cast<uint8_t*>(uint64_t)’
   47 |                     delete[] hpx::bit_cast<std::uint8_t*>(gid.get_lsb());
      |                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
In file included from /builddir/build/BUILD/hpx-1.9.1/libs/core/concurrency/include/hpx/concurrency/cache_line_data.hpp:11,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/core/concurrency/include/hpx/concurrency/spinlock_pool.hpp:16,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/core/threading_base/include/hpx/threading_base/thread_data.hpp:12,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/core/threading_base/include/hpx/threading_base/register_thread.hpp:16,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/core/threading_base/include/hpx/threading_base/thread_helpers.hpp:16,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/full/actions_base/include/hpx/actions_base/actions_base_support.hpp:19,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/full/actions_base/include/hpx/actions_base/basic_action.hpp:15,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/full/actions_base/include/hpx/actions_base/plain_action.hpp:13,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/full/async_colocated/src/server/destroy_component.cpp:8:
/builddir/build/BUILD/hpx-1.9.1/libs/core/type_support/include/hpx/type_support/bit_cast.hpp:34:23: note: candidate: ‘template<class To, class From> constexpr std::enable_if_t<(((sizeof (To) == sizeof (From)) && is_trivially_copyable_v<From>) && is_trivially_copyable_v<To>), To> hpx::bit_cast(const From&)’
   34 |         To> constexpr bit_cast(From const& src) noexcept
      |                       ^~~~~~~~
/builddir/build/BUILD/hpx-1.9.1/libs/core/type_support/include/hpx/type_support/bit_cast.hpp:34:23: note:   template argument deduction/substitution failed:
In file included from /builddir/build/BUILD/hpx-1.9.1/libs/core/config/include/hpx/config/move.hpp:17,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/core/config/include/hpx/config.hpp:29,
                 from /builddir/build/BUILD/hpx-1.9.1/libs/full/async_colocated/src/server/destroy_component.cpp:7:
/usr/include/c++/13/type_traits: In substitution of ‘template<bool _Cond, class _Tp> using std::enable_if_t = typename std::enable_if::type [with bool _Cond = false; _Tp = unsigned char*]’:
/builddir/build/BUILD/hpx-1.9.1/libs/core/type_support/include/hpx/type_support/bit_cast.hpp:34:23:   required by substitution of ‘template<class To, class From> constexpr std::enable_if_t<(((sizeof (To) == sizeof (From)) && is_trivially_copyable_v<From>) && is_trivially_copyable_v<To>), To> hpx::bit_cast(const From&) [with To = unsigned char*; From = long long unsigned int]’
/builddir/build/BUILD/hpx-1.9.1/libs/full/async_colocated/src/server/destroy_component.cpp:47:58:   required from here
/usr/include/c++/13/type_traits:2610:11: error: no type named ‘type’ in ‘struct std::enable_if<false, unsigned char*>’
 2610 |     using enable_if_t = typename enable_if<_Cond, _Tp>::type;
      |           ^~~~~~~~~~~
gmake[2]: Leaving directory '/builddir/build/BUILD/hpx-1.9.1/i686-redhat-linux-gnu-serial'
gmake[2]: *** [libs/full/async_colocated/CMakeFiles/hpx_async_colocated.dir/build.make:79: libs/full/async_colocated/CMakeFiles/hpx_async_colocated.dir/src/server/destroy_component.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:144574: libs/full/async_colocated/CMakeFiles/hpx_async_colocated.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....

https://koji.fedoraproject.org/koji/watchlogs?taskID=107416567

New attempt:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107418272

New attempt:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107418272

It seems to be ok now. Thanks!

Bors merge

bors merge


fix(build): Built library

:tada: This PR is included in version 1.3.1 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Missing column in docs for cellxgene_census schema

Hi, I was trying to download cell-level metadata usingcellxgene_census.get_obs. I usually refer to this for column names.
I tried filtering by tissue_type and got a missing column error.
cell_metadata = census["census_data"]["homo_sapiens"].obs.read(
    value_filter = "tissue_type == 'tissue'",
    column_names = ["assay", "tissue", "tissue_general", "suspension_type", "disease", 'dataset_id', 'is_primary_data',
                    'donor_id', 'development_stage_ontology_term_id',
                   'cell_type_ontology_term_id','cell_type', 'raw_sum', 'nnz']
)

---------------------------------------------------------------------------
SOMAError                                 Traceback (most recent call last)
Cell In [15], line 1
----> 1 cell_metadata = census["census_data"]["homo_sapiens"].obs.read(
      2     value_filter = "tissue_type == 'tissue'",
      3     column_names = ["assay", "tissue", "tissue_general", "suspension_type", "disease", 'dataset_id', 'is_primary_data',
      4                     'donor_id', 'development_stage_ontology_term_id',
      5                    'cell_type_ontology_term_id','cell_type', 'raw_sum', 'nnz']
      6 )

File ~/my-conda-envs/patho-signatures-2/lib/python3.9/site-packages/tiledbsoma/_dataframe.py:409, in DataFrame.read(***failed resolving arguments***)
    399 sr = clib.SOMADataFrame.open(
    400     uri=handle.uri,
    401     mode=clib.OpenMode.read,
   (...)
    405     timestamp=handle.timestamp and (0, handle.timestamp),
    406 )
    408 if value_filter is not None:
--> 409     sr.set_condition(QueryCondition(value_filter), handle.schema)
    411 self._set_reader_coords(sr, coords)
    413 # # TODO: batch_size

SOMAError: SOMAError: 'Column tissue_type does not exist in schema'

I just upgraded to v1.14.1
Am I using the wrong docs/schema?

@emdann thanks for reaching out.
tissue_type was added relatively recent to Census, and after our latest LTS data release. If you are opening the Census with the defaults then you are opening the LTS version of Census which does not have tissue_type.
If you open the latest non-LTS version of Census you will be able to see the field. However only  cells with tissue_type of values "tissue" are included in Census, so at the moment the information is not very useful.
See this reproducible example
import cellxgene_census
census = cellxgene_census.open_soma(census_version="latest")
obs = cellxgene_census.get_obs(census, "homo_sapiens", column_names=["tissue_type"])


⚠ PrivateHD has degraded performance

In b53fc22, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 2024 ms

Resolved: PrivateHD performance has improved in dcc4f8e.


docker-compose converts templates configuration files into directories

Bug Report
Steps to Reproduce:

Move to directory: /legend/installers/legend-studio-dev/
Run docker-compose command docker-compose ... in the README.md

Expected Result:
Should put right configuration files in the $BUILD_DIR as mentioned in the ./config.properties
Actual Result:
configuration files picked from /legend/installers/docker-compose/shared/templates/ are all converted to directories instead of files
eventually docker-compose runs but the container doesn't start as the configuration is missing, in fact it is a directory instead.
Environment:
OS: Windows 10 Version	10.0.19041 Build 19041
Additional Context:
This is an intermittent issue. Solved by pulling the project again and running the scripts.

@epsstan related to https://github.com/moby/moby/issues/30555 (as mentioned here)

@epsstan related to moby/moby#30555 (as mentioned here)

So we have two issues. 1/ Bind mounting files is not portable and 2/ Bind mounts should use absolute and not relative paths.
Think we should sweep all the files into a single directory and mount that directory.


Android build failed

Hi,
I used v1.0.1 in project now. But the build is failed with this log:
Error:Execution failed for task ':transformNativeLibsWithMergeJniLibsForLocalDebug'.

com.android.build.api.transform.TransformException: com.android.builder.packaging.DuplicateFileException: Duplicate files copied in APK lib/armeabi-v7a/libc++_shared.so
File1: C:\Users\yuesu.android\build-cache\865ea54445ecac9832b751ddaeb8fd05938fe7e5\output\jni
File2: C:\Users\yuesu.android\build-cache\281e71cedee43876919d0950d3dd9035c83af4df\output\jni

Please help to take a look.
Thanks,
Yue

The reason for this is that you have another module that has libc++_shared.so included and out project includes it as well. You can fix this simply by adding the following to your apps build.gradle file:
android {   packagingOptions {     pickFirst 'lib/armeabi-v7a/libassmidi.so'   } }

Please let us know if this doesn't solve it.

It works. Thank you!


Extract recid/v + 27

Closes #1369
Simple change. But have to be careful during review @James-Sangalli

@James-Sangalli we aren't. And actually there might be a few more possibilities. The ideal way is to refactor so that the +=27 is applied when we sign, but the existing code needs some refactoring [1] to do that safely and to add some tests for it. So this PR is really only extract the magic number 27 and be able to discover them to refactor or fix bugs.

guard against that scenario before adding it?

We should set up another issue to refactor if we want. This PR doesn't change the logic.
[1] Because there is at least 1 spot where we also apply the += 27 as a fix to a signature we get from MagicLink, as a patch.


Change TMaster to watch the packing plan for changes

Fixes #1932.
During a scaling event, instead of the scheduler deleting the packing plan and the executor restarting the tmaster with new stream manager ids, the TMaster will fetch the packing plan from the state manager and watch it. The packing plan is first fetched during initialization. Later if it updates, the TMaster updates it's state to reflect the new packing plan and stream manager list.
The main classes to review are tmaster.cpp, UpdateTopologyMaster.java and heron_executor.py. The rest of the classes are just incorporate the new tmaster changes.

Ping. Any comments?
This approach still has some shortcomings which I suggest we iterate upon in follow-ups, but in it's current form it's is a big improvement over what we have now.

Please look at my prev comment about the zk node hierarchy.

@srkukarni I see two previous comments of you, both of which I've addressed. What's the ZK node hierarchy comment?

Sorry, looks like i hadn't submitted my comments(damn github).
Anyways, I really want the invariant to be maintained by the logic of the code rather than the is_master_ thing. I just checked the code, and it looks like we do not start serving until much later. Thus, I believe the following approach is better

Upon start, make sure you are the master(just like the current logic).(Btw this avoids the is_master_ thingie).
Upon becoming master, check for packing plan and make sure that it exists.
Then continue with checking for physical plan and becoming master.
This way I believe you also reduce the size of this commit substantially

Why is it a bad thing to fetch the packing plan at initialization before being master? This is the safe thing to do. If we become master and start taking requests without initializing the TMaster we're going to have lots of failed RPCs from the stream managers since absent_stmgrs_ won't be initialized. I'm not seeing the reasoning for why we'd want to do that.
Note that this is a totally different concern than deleting the physical plan upon update, for which we should assure we're the master somehow.

There are two steps here

Becoming the master(when we write the /tmasters zk node).
Serving as master(when we start the TMasterServer.
IMO, 1 should be the first step in the logic of tmaster. 2 can follow anytime. So as soon as you become tmaster, you can start the fetching packing plan and only after that you can start serving requests.
Right now we do not do 2 until much later(after physical plan fetch). So we will not get any requests from stmgrs.

So, what's the issue with stmgrs trying to connect and retrying?

@srkukarni and I discussed on slack and have a plan, which I'll refactor to:

we can address both of our concerns by fetching the initial packing plan before registering (when we start and it’s null), but then registering the packing plan watcher only once we’re tmaster. That way we can still front-load initialization, while guaranteeing that the packing plan watcher (which takes mutating actions on the topology as master during update) would only happen when it’s master.


[search] Elastic search tests should not be using real indices

Ideally all the tests would be hitting a 'test' index, so that at the end of the tests you can just delete that index and not have to rebuild the search index from scratch. Because Node and User save methods will end up calling search, this will probably necessitate patching website/search.py:search so that its default index argument is 'test' instead of 'website' when you are running the tests.

If this is still needed I can do it.

That would be awesome

Closed by #3132


LinearNDInterpolator not thread safe

LinearNDInterpolator is crashing with a segfault when an instance is being called concurrently.
Steps to reproduce:

create a LinearNDInterpolator instance
run the call method of the instance concurrently

I looked at the source code, but can't see anything at the python level that could cause it to not be thread safe. Can it be deeper down in the fortran routines it's calling ? Could it be related to #4763 and #4770 ?
Reproducing code example:
import threading
import numpy as np
from scipy.interpolate.interpnd import LinearNDInterpolator

r_ticks = np.arange(0, 5000, 10)
phi_ticks = np.arange(0, 5000, 10)
r_grid, phi_grid = np.meshgrid(r_ticks, phi_ticks)

def do_interp(interpolator, slice_rows, slice_cols):
    print('interpolation started')
    grid_x, grid_y = np.mgrid[slice_rows, slice_cols]
    res = interpolator((grid_x, grid_y))
    print('interpolation complete')
    return res

points = np.vstack((r_grid.ravel(), phi_grid.ravel())).T
values = (r_grid * phi_grid).ravel()
interpolator = LinearNDInterpolator(points, values)

worker_thread_1 = threading.Thread(target=do_interp,
                                   args=(interpolator, slice(0, 2500), slice(0, 2500)))
worker_thread_2 = threading.Thread(target=do_interp,
                                   args=(interpolator, slice(2500, 5000), slice(0, 2500)))
worker_thread_3 = threading.Thread(target=do_interp,
                                   args=(interpolator, slice(0, 2500), slice(2500, 5000)))
worker_thread_4 = threading.Thread(target=do_interp,
                                   args=(interpolator, slice(2500, 5000), slice(2500, 5000)))

worker_thread_1.start()
worker_thread_2.start()
worker_thread_3.start()
worker_thread_4.start()

worker_thread_1.join()
worker_thread_2.join()
worker_thread_3.join()
worker_thread_4.join()

Error message:
[2]    536 segmentation fault  python test_ts_interp.py

Scipy/Numpy/Python version information:
Tested on both python 2.7.5 and python 3.6.3
('1.1.0', '1.14.3', sys.version_info(major=2, minor=7, micro=5, releaselevel='final', serial=0))
(1.1.0 1.14.3 sys.version_info(major=3, minor=6, micro=3, releaselevel='final', serial=0)

On first use, the interpolator computes some additional data
structures, which are cached on the interpolator object. This step is
not threadsafe (it should be, need to add locks around this). The crash
goes away if you add interpolator((0, 0)) before the threaded calls.

@pv thanks for the workaround!

Having looked at this issue for a while, I still fail to see what is being cached on the first call and where. One way to make the OP crash go away is to hold the GIL in the loop over the data points, https://github.com/scipy/scipy/blob/main/scipy/interpolate/interpnd.pyx#L314
Inside that loop, the main suspect is a call to qhull._find_simplex, the rest looks benign.
So if indeed the culprit is somwhere in Qhull, I actually wonder if it is really correct to call from with nogil or without specialized locks, since the Qhull website has the note (http://qhull.org/html/qh-code.htm#reentrant):

Note: Reentrant Qhull is not thread safe. Do not invoke Qhull routines with the same qhT* pointer from multiple threads.

Concluding, ISTM locks need to be added somewhere in Qhull itself or our Cython wrappers. To properly fix this issue, it needs a look from spatial/qhull expert. @tylerjereddy if memory serves, you worked on scipy.spatial, any chance you have a pointer off the top of your head?

On first use, the interpolator computes some additional data structures, which are cached on the interpolator object. This step is not threadsafe (it should be, need to add locks around this). The crash goes away if you add interpolator((0, 0)) before the threaded calls.

This is actually very crucial information if you want to use this interpolator in any form of parallel computing. For example, if you don't "initialize" it this way when using imap from the multiprocessing library , each new iteration will suffer from the significantly increased computation time on the first call. I suppose, since this cached is saved on the object, you have to esnure that it already exists before shipping the object to any subprocesses.
This should probably be mentioned in the docs.


Redis Stream XTRIM with MINID strategy is not fully supported: incompatible parameter type

Is your feature request related to a problem? Please describe.
The API to trim a redis stream (see the correspoding XTRIM command) supports different strategies via the org.redisson.api.stream.TrimStrategy type.
Yet the additional command parameters in the overloaded methods (e.g. trim, trimAsync, trimNonStrictAsync) will allow only ints.
Specifically you can now only pass a

int threshold (to say how many messages you want to keep)
int limit (to remove up to a given number of messages)

Those are inconsistent with the TrimStrategy.MINID which expects a message Id as input.
Since the message Ids are composed of a timestamp in millis from epoch and a number, the current int param won't be able to technically be used for such a job, even ignoring the semantics of the param.
An int is not enough to encode a valid millis timestamp which is part of the message Id.
Describe the solution you'd like
It would be nice to provide overloaded methods taking an instance of org.redisson.api.StreamMessageId, and - most importantly- a simple String, to allow partial matches.
Describe alternatives you've considered
I will probably use a work-around by calling the low-level redis client, but the issue is mostly about the current API which is a bit misleading in what it provides.

I'm locally testing my fix, but I can't seem to properly run the overall tests as per instructions.
Essentially it looks like my mvn installation can't properly pick up the argLine property to feed to the tests, as the default redis binary path is not properly overridden.
This is the starting log when I try to run the mvn tests as per contribution's instructions
Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
Maven home: /usr/local/Cellar/maven/3.8.2/libexec
Java version: 11.0.11, vendor: AdoptOpenJDK, runtime: /Users/ivanopagano/.sdkman/candidates/java/11.0.11.hs-adpt
Default locale: en_IT, platform encoding: UTF-8
OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"

Done. Thanks for report!