lib: add cbprintf capability

This PR adds a C99 stdio value formatter capability named cbprintf() (plus related variants) where generated text is emitted through a callback.  This allows generation of arbitrarily long output without a buffer, functionality that is core to printk, logging, and other system and application needs.
The formatter supports most C99 specifications, excluding:

%L[aefg] long double conversion
wide character output

The new solution is derived from z_prf(), which had the most complete functionality available.  Format parsing has been reimplemented, while floating point conversion has been retained and enhanced.
Kconfig options allow disabling features like floating-point conversion if they are not necessary.
Benefits include:

No more inconsistencies between printk, logging, and shell formatting capabilities.
Reduced inconsistencies due to toolchain libc capabilities.
Simplified (toolchain-independent) formatting feature selection via Kconfig.
Core infrastructure can avoid duplication with libc printf by using cbprintf variants.
Potentially a path to resolving #18351 and related issues, as the infrastructure can tell a caller the total size of arguments to the conversion string.
Fixed bugs with several specifications.

Costs include:

Applications that used only printk with no extra features consume more code space than the previous implementation.

Fixes #29202

this looks great.

Thanks!

I'm assuming stack usage for printk() is roughly like it was before?

I expect it's a little larger compared to z_vprintk, but smaller for z_prf(), depending on how much the compiler could overlay the local variables.  I don't know of any easy way to get real data.

+/* We can't determine at build-time whether int is 64-bit, so assume
+ * it is.  If not the values are truncated at build time, and the str
+ * pointers will be updated during test initialization.
+ */
+static const unsigned int pfx_val = (unsigned int)0x7b6b5b4b3b2b1b0b;

In the Zephyr environment, an int is always 32 bits. Only a long will
vary in width, and sizeof(long) is always equal to sizeof(void*). So the
constant above will always be truncated.

it increases the ROM footprint of samples/hello_world from 15760 to 16992 ... Is there something we can do about this?

Yeah, that's the fly in the ointment.  I've done a bunch of measurements, and tried different things, but have found nothing more that can be made optional without causing breakage (e.g. failing to correctly deduce the size of an argument that can't be converted, causing subsequent conversions to be corrupted).  Disabling 64-bit integer handling has no significant effect: the cost is all in handling C99 format specifications correctly.
Once you start adding logging and shell and other things that used to use two implementations the impact goes down.  At least one sensor sample I tried shrunk with this.  There's also some opportunity to eliminate existing dependencies on libc in Zephyr code, since this provides a replacement for snprintf.
The only candidate solution remaining is to have a Kconfig option that uses the old z_vprintk() implementation.  That's small, and would satisfy the needs of hello_world and anything that only uses printk, doesn't care about floating point, precision options, or decimal 64-bit values.
I'll take a look at what happens with that.

On Mon, 9 Nov 2020, Peter A. Bigot wrote:

Yeah, that's the fly in the ointment.  I've done a bunch of measurements, and tried different things, but have found nothing more that can be made optional without causing breakage (e.g. failing to correctly deduce the size of an argument that can't be converted, causing subsequent conversions to be corrupted).  Disabling 64-bit integer handling has no significant effect: the cost is all in handling C99 format specifications correctly.

Did you try removing the double and long double from argument_value
union in the case there is no float nor 64bit support? Some code might
need to be #ifdef'd out in that case of course which isn't as pretty,
but if the size reduction is significant then this might be worth it.

+#ifdef CONFIG_CBPRINTF_64BIT_SUPPORT
+/* The maximum defined standard integer type is 64 bits, so we assume
+ * that's the number of bits in uintmax_t.  Some toolchains might
+ * allow more, in which case the inconsistency needs to be
+ * resolved.
+ */
+typedef intmax_t sint_value_type;
+typedef uintmax_t uint_value_type;
+#define CONVERTED_INT_BUFLEN ((64U + 2U) / 3U)

If you're assuming a 64-bits width to size a buffer, then you should
really define sint_value_type as an int64_t. If intmax_t is larger then
it would only get truncated which is a benign "inconsistency". As it is,
such inconsistency could get you a buffer overflow instead.

@carlescufi There's now CONFIG_CBPRINTF_NANO which substitutes a nearly unmodified implementation of z_vprintk for the new one while retaining the new wrapper infrastructure (the old one didn't return the number of characters emitted, which is required).
This is opt-in, but if selected the size of hello_world is unchanged.
The unit test for cbprintf has, to the extent reasonable, been updated to verify existing behavior of the nano formatter.  It gets some things wrong, and there's a lot it doesn't handle.
Both the unit test and kernel/common pass locally with both full and nano formatters.  We'll see what CI thinks.  (I also have to fix some style issues that were grandfathered in with z_vprintk.
If this seems like the right way to move forward I'll squash nano support into the original commit.

@npitre Responding here in a batch since there's no context from email (could you submit further comments through the github review UI?):

In the Zephyr environment, an int is always 32 bits...

OK, but I want the test to be prepared for 64-bit integers.  It doesn't cost anything other than a compliance check failure (which  won't pass anyway).

Did you try removing the double and long double from argument_value
union in the case there is no float nor 64bit support?

No.  The fact that the formatter won't convert those types doesn't mean it won't have to pull them out of the argument list.  Removing them with ifdefs seems likely to create unmaintainable code and probably won't reduce code size since the code that would use them is already removed.

If you're assuming a 64-bits width to size a buffer, then you should really define sint_value_type as an int64_t.

I had thought about that, but research suggested that the wording in the C18 standard prevents using a size larger than 64 bits for intmax_t (toolchains are free to go further with non-standard types like __int128, etc., but not use intmax_t for them).  I didn't see a compelling counter-argument so I stayed with the existing implementation.

On Mon, 9 Nov 2020, Peter A. Bigot wrote:

@npitre Responding here in a batch since there's no context from email (could you submit further comments through the github review UI?):

Not really. I am blind and must rely on accessibility tools. The github
web interface is a complete nightmare wrt accessibility. Things as
simple as simply approving a RP is a real PITA. The review UI is just
unusable. Same for the CI reports.
I did provide the context manually though. Didn't it come through?

In the Zephyr environment, an int is always 32 bits...

OK, but I want the test to be prepared for 64-bit integers.  It doesn't cost anything other than a compliance check failure (which  won't pass anyway).

Just use a long then. Or better yet, int64_t.
You will never get a 64-bit integer to fit in an int.

Did you try removing the double and long double from argument_value
union in the case there is no float nor 64bit support?

No.  The fact that the formatter won't convert those types doesn't mean it won't have to pull them out of the argument list.  Removing them with ifdefs seems likely to create unmaintainable code and probably won't reduce code size since the code that would use them is already removed.

Yeah, you're right. I was under the impression that the union was passed
down to helpers, but it is not and its scope remains local. So the
compiler is free to optimize it.

If you're assuming a 64-bits width to size a buffer, then you should really define sint_value_type as an int64_t.

I had thought about that, but research suggested that the wording in the C18 standard prevents using a size larger than 64 bits for intmax_t (toolchains are free to go further with non-standard types like __int128, etc., but not use intmax_t for them).  I didn't see a compelling counter-argument so I stayed with the existing implementation.

The argument would be to avoid inconsistencies and confusion. If
intmax_t can't be bigger than int64_t then it is clearer to just use
that and dispense with the "some toolchains might allow more" comment.

I did provide the context manually though. Didn't it come through?

It did, yes.

In the Zephyr environment, an int is always 32 bits... OK, but I want the test to be prepared for 64-bit integers. It doesn't cost anything other than a compliance check failure (which won't pass anyway).
Just use a long then. Or better yet, int64_t. You will never get a 64-bit integer to fit in an int.

It can't be a long: the test relies on these values being int because they're paired with an unqualified %x specification.
The ILP64 model has 64-bit ints.  Given that some Zephyr applications seem to target odd architectures for video/sound processing I'd rather not make assumptions that this won't have to work on something unusual.

If you're assuming a 64-bits width to size a buffer, then you should really define sint_value_type as an int64_t. I had thought about that, but research suggested that the wording in the C18 standard prevents using a size larger than 64 bits for intmax_t (toolchains are free to go further with non-standard types like __int128, etc., but not use intmax_t for them). I didn't see a compelling counter-argument so I stayed with the existing implementation.
The argument would be to avoid inconsistencies and confusion. If intmax_t can't be bigger than int64_t then it is clearer to just use that and dispense with the "some toolchains might allow more" comment.

But the j conversion specifier is documented to operate on intmax_t types, not int64_t types.  I think it's more important to use the types that are identified in the standard.

The argument would be to avoid inconsistencies and confusion. If intmax_t can't be bigger than int64_t then it is clearer to just use that and dispense with the "some toolchains might allow more" comment.

But the j conversion specifier is documented to operate on intmax_t types, not int64_t types.  I think it's more important to use the types that are identified in the standard.

Well, in that case please add something like:
BUILD_ASSERT(sizeof(sint_value_type) == 8);
so that if the assumption in CONVERTED_INT_BUFLEN is no longer true then
there won't be unnoticed buffer overflows.

@carlescufi There's now CONFIG_CBPRINTF_NANO which substitutes a nearly unmodified implementation of z_vprintk for the new one while retaining the new wrapper infrastructure (the old one didn't return the number of characters emitted, which is required).
This is opt-in, but if selected the size of hello_world is unchanged.

This is good enough for me. I am now happy with this change.

In the latest push I've squashed the nano option into the commit that introduces cbprintf.
I've also changed the way support for reduced space for integer value conversion is selected and implemented so that it no longer depends on a 64-bit assumption (though if intmax_t is larger than 64 bits a Kconfig value must be changed).
@npitre does this work for you?

This adds cb[v]snprintf() as a substitute for [v]snprintf() to avoid pulling in libc formatting code when Zephyr modules need format-to-buffer capability.  With that name policy cb[v]printf should be substitutes for [v]printf, but those names are already used for the new API that takes the callback function and context.
I'm not a fan of trying to override standard library functions, so some options are:

do not provide something that can replace [v](sn)?printf() using the internal cbprintf infrastructure;
move the cb part of the substitute API to the end of the identifier, e.g. printfcb("fmt", ...) and snprintfcb(buf,sz,fmt,...)

I'm inclined to try the latter.

This is opt-in, but if selected the size of hello_world is unchanged.

While this was true when I wrote it, it's not exactly true now.  To use the former v_printk() to implement cbsnprintf it is necessary to adapt it to count the number of characters that would be emitted.  This increases the image size from 15738 to 15866.
If we make the [v](sn)?printf replacement functions optional most of that 128 bytes could probably be reclaimed.  I'll tackle that later.

DNM to give me a chance for final tuning and documentation updates before the approvals let this get merged.

I've also changed the way support for reduced space for integer value conversion is selected and implemented so that it no longer depends on a 64-bit assumption (though if intmax_t is larger than 64 bits a Kconfig value must be changed).

The CONFIG_CBPRINTF_UINTMAX_BITS doesn't bring anything right now. All
architectures currently supported by Zephyr must have 64 here. It can't
be smaller as it would trip the assertion to prevent buffer overflows,
and making it larger is just a waste of stack space. The day
sizeof(uintmax_t) is larger then something could be done about it. In
the mean time this is just loading the config space for no value.
I understand why you created CONFIG_CBPRINTF_FULL_WIDTH but this saves
only 15 bytes of stack. Is it worth it given that tight memory systems
are more likely to use the nano code anyway?
Otherwise there is also the issue of overflowing pad0_pre_dp or
pad0_post_dp. With any of the other width parameters, an overflow would
simply create a misaligned display. in the pad0_pre_dp/pad0_post_dp case
that would display the wrong numerical value. Unlikely of course but
still. Maybe reverting to a canned exponent form in that case should be
considered in that case.
In fact, can pad0_pre_dp and pad0_post_dp ever be non-zero at the same
time? I think you could combine them and use a pre/post flag instead.

The public libc-compatible functions have been renamed and made optional,
so NANO without them has no change in code size relative to pre-PR for
applications that use only printk.
A bug with z_vprintfk on LP64 has been fixed in NANO.

The CONFIG_CBPRINTF_UINTMAX_BITS doesn't bring anything right now. All
architectures currently supported by Zephyr must have 64 here. It can't
be smaller as it would trip the assertion to prevent buffer overflows,
and making it larger is just a waste of stack space. The day
sizeof(uintmax_t) is larger then something could be done about it. In
the mean time this is just loading the config space for no value.

I don't think it hurts anything and it does prepare for the day when
expectations turn out to be wrong.  Removing it would require a
constant 64 for a value that's dependent on intmax_t, which just
doesn't seem right.

I understand why you created CONFIG_CBPRINTF_FULL_WIDTH but this
saves only 15 bytes of stack. ... Otherwise there is also the issue
of overflowing pad0_pre_dp or pad0_post_dp.

Yes, good point:  I hadn't considered the FP padding could overflow too.
I've:

removed the FULL_WIDTH option;
combined the former pad0_prefix (integer-only) , pad0_pre_dp, and
pad0_post_dep values into one field pad0_value with a bit field to
distinguish which of the floating point positions would use it;
used unions because width and pad0_prefix have disjoint lifespans,
as do prec and pad0_pre_exp.

I also moved the conversion specifier out of the bitfield to a char,
because it turns out the compiler's wise enough to use the leftover
bitfield space to store it anyway.  So the conversion specification
structure is three words (12 bytes on a I32 host).
Both these changes reduced code size.

The day sizeof(uintmax_t) is larger then something could be done about it. In the mean time this is just loading the config space for no value.

I don't think it hurts anything and it does prepare for the day when expectations turn out to be wrong.

You added the assertion check to guard against false expectations and
that's perfect.
I think that over engineering something just in case some day things are
different does actually hurt. It would be simple enough to fix it if
ever that day comes. In the mean time this is just unneeded cruft that
will give unnecessary pause to everyone configuring their build as they
can't do anything with it anyway.

Removing it would require a constant 64 for a value that's dependent on intmax_t, which just doesn't seem right.

In practice it is right, and is likely to be right for quite a while.
The assertion is there for when it won't be, and a comment should say
so.  That's good enough for simplifying the config space which is a
worthy goal.
If you really want to make things fall out automatically, the
alternative could be:
#ifndef __INTMAX_WIDTH__
#define __INTMAX_WIDTH__ 64
#define __INTMAX_TYPE__ __INT64_TYPE__
#define __UINTMAX_TYPE__ __UINT64_TYPE__
#endif

[...]

typedef __INTMAX_TYPE__ intmax_t;

And then use __INTMAX_WIDTH__ directly for CONVERTED_INT_BUFLEN.
So far, all the compilers I've seen do define __INTMAX_TYPE__ and
__INTMAX_WIDTH__ already.

Also, if CONVERTED_INT_BUFLEN depends on some implicit and possibly
variable value, it would be safer to do this instead:
#if CONVERTED_FP_BUFLEN >= CONVERTED_INT_BUFLEN
#define CONVERTED_BUFLEN CONVERTED_FP_BUFLEN
#else
#define CONVERTED_BUFLEN CONVERTED_INT_BUFLEN
#endif

You may safely drop the U qualifiers if the preprocessor doesn't
like them as this is only used to size an array.

It can't be a long: the test relies on these values being int because they're paired with an unqualified %x specification.

OK. Similar to one of my previous comment, you may know at compile time
the width of an int at compile time. It is __INT_WIDTH__.

It is __INT_WIDTH__.

That's not in the standard.

It is __INT_WIDTH__.

That's not in the standard.

That's in the Zephyr build environment sstandard.
There is provision for providing it when the compiler doesn't. See
include/toolchain/xcc_missing_defs.h for example.

@npitre I understand you would do this a different way.  I haven't seen a compelling argument that there's something clearly wrong with the way it's being done.  I don't feel that what you propose is a significant improvement that warrants introducing non-standard technologies or making assumptions about what future toolchains may provide or targets might require.
At this point I do not intend to change the way the integer buffer length is determined.  If you feel strongly, block this PR, and we can see what the codeowners decide should be done.

At this point I do not intend to change the way the integer buffer length is determined.  If you feel strongly, block this PR, and we can see what the codeowners decide should be done.

Given that roughly 47% of the code in prf.c is actually mine, don't you
think that my opinion should count a little?
I do object to CONFIG_CBPRINTF_UINTMAX_BITS.
I've provided you with 2 alterntives to it. Please be free to do it some
other way if you don't like them.

@npitre I think we were both still getting hung up on 64-bit as a special case.
I changed it to use sizeof(value_type) to calculate the maximum buffer length in CBPRINTF_COMPLETE which has a well-defined map from size to number of characters in the converted representation.
For nano I added a BUILD_ASSERT, since it uses a different formula that might not be correct for values other than 4 and 8.
So the Kconfig is no longer needed, nor is reliance on toolchain-specific constants.
Is it OK now?

So the Kconfig is no longer needed, nor is reliance on toolchain-specific constants.

Is it OK now?

Yes, thanks.
One last thing(tm)
I'd suggest this change:
 #ifdef CONFIG_CBPRINTF_FP_SUPPORT
-#define CONVERTED_BUFLEN CONVERTED_FP_BUFLEN
+#define CONVERTED_BUFLEN MAX(CONVERTED_FP_BUFLEN, CONVERTED_INT_BUFLEN)
 #else
 #define CONVERTED_BUFLEN CONVERTED_INT_BUFLEN
 #endif

This way you don't have to presume FP is bigger.

Also, it is unfortunate that the printk code implicitly zero-padded %p.
That is causing some tests to fail as this isn't the behavior the C lib
is expecting.
I think we should drop the implicit precision to be standard conformant
and fix those %p instances where that matters instead.

I'd suggest this change:
+#define CONVERTED_BUFLEN MAX(CONVERTED_FP_BUFLEN, CONVERTED_INT_BUFLEN)

Good catch, done.

Also, it is unfortunate that the printk code implicitly zero-padded %p.
That is causing some tests to fail as this isn't the behavior the C lib
is expecting.

Which tests?  What C library depends on the format?
The standard specifies that %p format is implementation-defined.  z_prf and z_vprintk differed (the latter zero-padded, the former did not).  I picked printk as the standard to follow, but I'm not bound to that.
I did add a Kconfig option to do nil instead of 0x0...0 but I'm not sure it's worth it, so I'm tempted to removing the feature.  I personally find it more visible, but it could break automated processing.
I'd be fine with removing the zero padding, with or without making it optional.
So, I'm soliciting feedback:

Zero pad pointers to pointer width, strip leading zeros after 0x, or make this controllable?
Use nil for null pointers, or treat them as any other pointer value, or keep this controllable?

Absent strong contrary opinions I will:

Unconditionally remove the leading zeros from pointers
Remove the option to format null pointers as nil

Also, it is unfortunate that the printk code implicitly zero-padded %p. That is causing some tests to fail as this isn't the behavior the C lib is expecting.

Which tests?

tests/lib/sprintf/

What C library depends on the format?

It's rather that Newlib (used in some Zephyr configurations), glibc
(used with the native_posix targets) and the minimal C lib (where this
code comes from) all agreed on not having an implicit precision with %p.

I'd be fine with removing the zero padding, with or without making it optional.

I'd lean towards removing it and not making that optional.
You still can add it to the string format when needed.

I did add a Kconfig option to do nil instead of 0x0...0 but I'm not sure it's worth it, so I'm tempted to removing the feature.  I personally find it more visible, but it could break automated processing.

At least glibc does (nil).
I'd suggest doing 0x0 with `%#p". This way both are available.

Also, it is unfortunate that the printk code implicitly zero-padded %p. That is causing some tests to fail as this isn't the behavior the C lib is expecting. I think we should drop the implicit precision to be standard conformant and fix those %p instances where that matters instead.

%p seems to be an extension. The POSIX docs don't have anything to say about it that I can find:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05
If there's no actual standard for this perhaps we can leave this alone or update the test, I wouldn't treat current test behavior as necessarily binding without some concrete standard backing it. (which you should feel free to link if you have sources)
Absent a standard telling us otherwise, %p being zero padded is very handy for putting debug output in columns.

I'd suggest doing 0x0 with `%#p". This way both are available.

In fact, %#p could combine both: 0x0for NULL, and implicit precision
to the pointer width.

Absent a standard telling us otherwise, %p being zero padded is very handy for putting debug output in columns.

Would it make sense to mimick existing libs' behavior with %p and
having the automatic padding with %#p ?

%p seems to be an extension. The POSIX docs don't have anything to say about it that I can find:

Those links are for the command-line utility, which doesn't support it.  https://en.cppreference.com/w/c/io/fprintf has the summary content; or you can get to the final draft standard from wikipedia and look at section 7.21.6.

If there's no actual standard for this perhaps we can leave this alone or update the test, I wouldn't treat current test behavior as necessarily binding without some concrete standard backing it. (which you should feel free to link if you have sources)

I'll update the minimal libc tests to include behavior with the nano variant.

In fact, %#p could combine both: 0x0for NULL, and implicit precision to the pointer width.

I'd considered that, but a nit-picky problem is that while the representation of %p is implementation defined, use of %#p is undefined behavior, which MISRA disallows by Rule 1.3 (I can't correlate from MISRA to C99 to determine what's required for this specific violation because my C99 draft doesn't have the violations numbered; it may be ignorable).
We could do %p being zero padded hex value for all pointers including null, then %#p being no-zero-padding and nil for null pointers.  Or vice-versa.  Is conforming to existing minimal libc behavior, or existing printk behavior, more desirable?

%p seems to be an extension. The POSIX docs don't have anything to say about it that I can find:

Those links are for the command-line utility, which doesn't support it. en.cppreference.com/w/c/io/fprintf has the summary content; or you can get to the final draft standard from wikipedia and look at section 7.21.6.

Derp, thanks.

We could do %p being zero padded hex value for all pointers including null, then %#p being no-zero-padding and nil for null pointers. Or vice-versa. Is conforming to existing minimal libc behavior, or existing printk behavior, more desirable?

I'm thinking if we change this to be more standards compliant, or at least more in line with what Linux libc does, that if this diverges from exiting printk() or minimal libc behavior, we just make the change and deal with the fallout.
In other words: I'd say any precedent established by Zephyr-specific stuff like printk(), minimal libc, or their associated tests should not prevent us from doing the right thing and aligning the behavior with established precedent outside of Zephyr, if that makes sense.

Absent a standard telling us otherwise, %p being zero padded is very handy for putting debug output in columns.
Would it make sense to mimick existing libs' behavior with %p and having the automatic padding with %#p ?

This approach is agreeable to me.

Absent a standard telling us otherwise, %p being zero padded is very handy for putting debug output in columns.
Would it make sense to mimick existing libs' behavior with %p and having the automatic padding with %#p ?

This approach is agreeable to me.

Following gcc 9.3.0 on Ubuntu then %p will give ptr 0x1234 (nil)
Then as a Zephyr extension %#p will give 0x00001234 0x00000000, padded to the size of the pointer.
Of course %#p isn't undefined behavior because cbprintf isn't a standard library function, so this is fine.
I'll make it so in the next day or two.

This approach is agreeable to me.

Following gcc 9.3.0 on Ubuntu then %p will give ptr 0x1234 (nil)
Then as a Zephyr extension %#p will give 0x00001234 0x00000000, padded to the size of the pointer.
Of course %#p isn't undefined behavior because cbprintf isn't a standard library function, so this is fine.

To clarify: I'll implement the above behavior only for CBPRINTF_COMPLETE, leaving CBPRINTF_NANO to do what it does now.
This is the only way to avoid increasing the code size when selecting nano, and even if we make pointer support the same the two will still be different for other format operations, so it doesn't seem worth doing.

It's probably from just not having enough coffee that I didn't notice this earlier. I actually have some reservations about introducing format code extensions.

having the automatic padding with %#p

Are their alternatives to introducing non-standard format codes? For example this may result in warnings for APIs which use __printf_like
It might just be better to just do standard behavior, and if someone really wants their pointers printed in a special specific way for column formatting purposes they can do 0x%08lx or whatever and cast their pointer to uintptr_t.

having the automatic padding with %#p

Are their alternatives to introducing non-standard format codes? For example this may result in warnings for APIs which use __printf_like

You're right.

It might just be better to just do standard behavior, and if someone really wants their pointers printed in a special specific way for column formatting purposes they can do 0x%08lx or whatever and cast their pointer to uintptr_t.

Or just do "%.8p".
Well, although glibc does handle `"%.8p", gcc still warns about it.
So yeah... 0x%08lx or %#.8lx it shall be.

cbprintf now consistently formats non-null %p as 0x1234, no leading zeros.
Format of null pointers diverges: COMPLETE uses (nil) following Linux libc, while NANO uses 0x0 because detecting null and emitting (nil) increases memory significantly from the previous footprint.
CBPRINTF_NULL_AS_NIL has been removed.
When MINIMAL_LIBC is selected CBPRINTF_NANO selects LIBC_SUBSTS which causes a size increase, but this is required to correctly implement s[n]printf() (otherwise the number of characters that would have been written is not counted.)
A warning call-out has been added to the documentation to note the limitations of C library functions when MINIMAL_LIBC is combined width CBPRINTF_NANO.  tests/libc/sprintf should now pass with that combination but this is a non-default configuration that requires manual checking with an overlay, and when used some tests are skipped because they verify unsupported functionality.
Floating point formatting support is default-enabled with FPU is selected, as this seems to be the clue that floating point is desired by the application.

This looks fine to me.

Format of null pointers diverges: COMPLETE uses (nil) following Linux libc, while NANO uses 0x0 because detecting null and emitting (nil) increases memory significantly from the previous footprint.

That much? I would have expected 10-15 bytes of text.
I'll try to come up with a good comment to replace the /* Magically convert the base-2 exponent to a base-10exponent. */ eventually.
I can see potential for smallish code size reduction here and there but that'll be easier to test once this is merged.
@nashif you may turn that -1 on my behalf to +1.

This looks fine to me.
Format of null pointers diverges: COMPLETE uses (nil) following Linux libc, while NANO uses 0x0 because detecting null and emitting (nil) increases memory significantly from the previous footprint.
That much? I would have expected 10-15 bytes of text.

That motivated me to try harder, and by refactoring a little it's only 12 bytes more.

Format of null pointers diverges: COMPLETE uses (nil) following Linux libc, while NANO uses 0x0 because detecting null and emitting (nil) increases memory significantly from the previous footprint.
That much? I would have expected 10-15 bytes of text.

That motivated me to try harder, and by refactoring a little it's only 12 bytes more.  So that difference has been removed: both COMPLETE and NANO format null pointers as (nil).

If you prefer we can eliminate these complaints by (a) not being prepared to support ILP64, and/or (b) not testing handling of undefined format combinations.  But I'd rather just ignore checkpatch's whingeing.

ILP64 should probably be considered only the day they're needed.
There are many more code instances where such considerations would be
required. Better do that all at once in a unified way.
IMHO of course.

If you prefer we can eliminate these complaints by (a) not being prepared to support ILP64, and/or (b) not testing handling of undefined format combinations. But I'd rather just ignore checkpatch's whingeing.
ILP64 should probably be considered only the day they're needed. There are many more code instances where such considerations would be required. Better do that all at once in a unified way. IMHO of course.

I'm inclined to agree with @npitre here.
I also don't really care that much.

I also don't really care that much.

OK, since nobody objects strongly I'll leave it in.  The whole solution was designed to be ready for ILP64, and I'd rather not go through and take out everything that specifically supports it.
Compliance failures are known and explained; tests pass.  Anything else to do?


Workbook - WorkBook Usage Report missing fields for analytic rules due to using old preview API

Describe the bug
The workbook 'Workbook usage report' is using the 2202-06-01-preview api which does not include fields like Description, Severity for the display of analytic rules. The latest API version is 2023-11-01 which includes the fields.
https://learn.microsoft.com/en-us/rest/api/securityinsights/alert-rules/list?view=rest-securityinsights-2023-11-01&tabs=HTTP#code-try-0
Note - Workbook allows for the export of analytic rules.
To Reproduce
Steps to reproduce the behavior:

Go to Sentinel.
Install the workbook 'workbook usage report' from the content hub.
Navigate to workbooks, and open 'workbook usage report'.
Select Sentinel workspace.
Select Regular Checks (D/W/M).
Select Weekly for Group: Regular Checks.
Select Rules.
Scroll down to '3a. Active Rules via Rest API'.
See fields Description, Severity are not displayed.

Expected behavior
Display fields Description, Severity. Updating the API version to 2023-11-01 would allow the additional information to be displayed.
Screenshots

Hi  @MikeP1375 , Thanks for flagging this issue, we will investigate this issue and get back to you with some updates by 02/02/2024. Thanks!

Hi @MikeP1375 ,need some more time for applying those missing fields,working on it,will update you

Hi @MikeP1375 ,I have modified the api call and added the fields in KQL query,Please find below screen shot for reference,will be raising the PR for the same,

Hi @MikeP1375 ,I have modified the api call and added the fields in KQL query,Please find below screen shot for reference,will be raising the PR for the same,

Hi @MikeP1375 ,Apologies for delayed response, Raised the PR,once merged,will close the issue


Video Viewer Activity Fix

Here the issue #859 finds it's solution :)
ps:- fixed the branching errors in previous PR.  requested by @llaske , please review

Nice work. Thanks.


How I can run the example original strandtest.py with this version of lib

Hi, I am trying to execute the original example
https://github.com/jgarff/rpi_ws281x/blob/master/python/examples/strandtest.py
but i am obtain this error:
raceback (most recent call last):
File "test.py", line 83, in
strip.begin()
File "/home/pi/a/rpi-pcm-ws281x/neopixel_pcm.py", line 105, in begin
raise RuntimeError('ws2811_init failed with code {0}'.format(resp))
RuntimeError: ws2811_init failed with code -1
Exiting cleanly
How is the correct way?
Thank you :)

Since the master branch (which you seem to be using) is a copy from jgarff
version (https://github.com/jgarff/rpi_ws281x),
please use his version. Probably a mismatch between the installed C-code
and your python code.
On Wed, May 31, 2017 at 6:54 PM, logickphp<EMAIL_ADDRESS>wrote:

Hi, I am trying to execute the original example
https://github.com/jgarff/rpi_ws281x/blob/master/python/
examples/strandtest.py
but i am obtain this error:
raceback (most recent call last):
File "test.py", line 83, in
strip.begin()
File "/home/pi/a/rpi-pcm-ws281x/neopixel_pcm.py", line 105, in begin
raise RuntimeError('ws2811_init failed with code {0}'.format(resp))
RuntimeError: ws2811_init failed with code -1
Exiting cleanly
How is the correct way?
Thank you :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tvoverbeek/rpi-pcm-ws281x/issues/2, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABJE7tSn8zKc7MMZtOIaUy0wox6j2bmFks5r_ZtYgaJpZM4Nr6T3
.


Modify cudpp_rand so that random number generator also has CTA equivalent

Right now the only way to invoke the random number is through the API.
Provide a version which can use device level routines.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 19 Aug 2009 at 6:28

Original comment by<EMAIL_ADDRESS>on 20 Jan 2010 at 8:24

Added labels: Priority-Low, Milestone-Release2.0
Removed labels: Priority-High, Milestone-Release1.2

Stan, is this still something interesting to provide?  Do you have any plans to
implement it?  I'm going to move it back to release 2.1.

Original comment by<EMAIL_ADDRESS>on 6 Jul 2011 at 2:33

Added labels: Milestone-Release2.1
Removed labels: Milestone-Release2.0


Bad quoting

Module version: 5.4.3
Puppet version: 4.10
OS and version: Centos7

Bug description
Puppet Class
$cors_url="http://$ox_elasticsearch::params::ka_fronetend_hostname"
elasticsearch::instance { $ox_elasticsearch::params::es_instance_name:
config => {
'network.host' => '<IP_ADDRESS>',
'http.cors.allow-origin' => ""$cors_url"",
'http.cors.enabled' => true
}
}
Puppet agent generates this
MANAGED BY PUPPET

-http.cors.allow-origin: http://kibana.ofc.internal
+http.cors.allow-origin: '"http://kibana.ofc.internal"'
The line being removed is w/o the escaped quote which wouldnt work either.

Hi @hornetmadness,
So, just to be clear, which formatting are you intending to end up with and know to work correctly?

http.cors.allow-origin: "http://kibana.domain.com" is what I was expecting.
and currently have working.
-Erik-
On Thu, Oct 19, 2017 at 4:41 AM, Tyler Langlois<EMAIL_ADDRESS>wrote:

Hi @hornetmadness https://github.com/hornetmadness,
So, just to be clear, which formatting are you intending to end up with
and know to work correctly?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/elastic/puppet-elasticsearch/issues/886#issuecomment-337840275,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADCOoN3p9YknYsEWmt3vyzh20TFi6aPUks5stwtRgaJpZM4P7AwR
.

@hornetmadness in my testing, I can get elasticsearch running in the form without quotes, though I haven't tried connecting Kibana to it. Perhaps the config is reading it as a regular expression? Does specifying the trusted origin in regex form as mentioned in the documentation work?

Closing after inactivity.


Added support for team player roster and coach roster

This PR adds the following:
Two get functions within mlbapi.py that return a current team player roster and current team coach roster.
The Coach and Player classes are children of the Person class.
Also added doc strings for many get functions to get us started.
This PR requires this PR to be merged https://github.com/zero-sum-seattle/python-mlb-statsapi/pull/34

Let me know what you think. I want to get out handling dictionary transformation for Players and Coaches. A guy on Reddit gave me some good advice to get away from calling post_init at all.

Let me know what you think. I want to get out handling dictionary transformation for Players and Coaches. A guy on Reddit gave me some good advice to get away from calling post_init at all.

What is the downside to calling post_init ? Is there a reason we want to move away from it to something like this you mentioned?
@staticmethod     def from_response(response: dict) -> "Player":

Let me know what you think. I want to get out handling dictionary transformation for Players and Coaches. A guy on Reddit gave me some good advice to get away from calling post_init at all.

What is the downside to calling post_init ? Is there a reason we want to move away from it to something like this you mentioned?
@staticmethod
def from_response(response: dict) -> "Player":

This is all gravy for some of more basic base objects but im trying to wrap my head around on how this would be adapted and followed with Game. The amount of nested objects would make for a super messy call if it were to be following what you have wrote with get_team_coaches and get_team_roster coaches.append(Coach(**{**coach, **person}))

Post Init is nice, but it's not very flexible. We are bound by the rules of what is defined in the data class. We are a slave to the structure of the returned JSON, and after trying to do an inheritance and unpacking of all this nested data, I'm starting to see the limitations and frustrations as this project gets bigger.

with a @staticmethod for each data class, we would have more power over the data returned from the endpoints to create our data classes.


I built a site with Eleventy!

https://miriamsuzanne.com
personal site for everything Miriam creates as an author, web developer, musician, and playwright…

Hi Miriam,
would be great, if you could fix your Atom feed also :-)

@Ryuno-Ki Moved and fixed the feed, seems to be working now.

the file already exists

Thank you!


Khndrel Keght takes Normal Damage when Hit by Sword

The dirt slime only takes a half heart of damage which is the same as punching it.

Yes, it has damage reduction because being made from dirt gives it good armor. Try a better weapon; if I remember correctly a diamond sword should make 3 points of damage.


Add e2e tests

We currently lack e2e tests for the container-freezer, meaning we are not able to catch regressions / verify the end-to-end workflow / etc. Adding these would be beneficial.

in processing

/lifecycle frozen


fix(middleware): Catch errors when loading a module (#3572)

Fix karma-runner/karma#3572

:white_check_mark: Build karma 2778 completed (commit https://github.com/karma-runner/karma/commit/891635fc48 by @jehon)

:white_check_mark: Build karma 2780 completed (commit https://github.com/karma-runner/karma/commit/3054fc50b0 by @jehon)

:white_check_mark: Build karma 2781 completed (commit https://github.com/karma-runner/karma/commit/1c220fa432 by @jehon)

:white_check_mark: Build karma 2782 completed (commit https://github.com/karma-runner/karma/commit/5f389087bd by @jehon)

@johnjbarton Sorry to interrupt you, but could you have an (updated) opinion on this PR?
The basis is that, without this PR and actually, karma report success when there is a syntax error in a es6 test.

Could someone review this PR?
If some work need to be done, could it be said?
Thanks

Sorry for the long delay. I want to investigate the possibility of correcting any tests that fail with the error on both paths.

I did look into the failings tests, nothing important. It's just that it test the string, and that in need to be adapted. I can push it here if wanted.
But the problem is that the output would change for errors in normal scripts (here, I put a call to "nothing()":
Uncaught ReferenceError: nothing is not defined
ReferenceError: nothing is not defined
   at tests/failing-test.js:2:1

Instead of
ReferenceError: nothing is not defined
   at tests/failing-test.js:2:1

There is no difference with the "if".

Followup in https://github.com/karma-runner/karma/pull/3585

Followup in https://github.com/karma-runner/karma/pull/3605


fix(backport): checkout from staging branch and ask to update if needed

Fixes #731
this aligns with steps 1-3 in doc/contributing/backporting-to-release-lines.md - How to submit a backport pull request
https://github.com/nodejs/node/blob/c2cd74453e7d2794ad81cab63e68371e08bad04f/doc/contributing/backporting-to-release-lines.md?plain=1#L48-L62

I totally with you on adding test but there where no test to begin with
I will try to add one...

Please do not hard code 'upstream', and take the name of the upstream from the config instead.

@aduh95 fixed


Blazor plugins?

I would like to know if there will be portability to use the plugins with Blazor, in a similar way as it works with MVC.
I really like the library and I want to be able to use it in Blazor applications.

@pauloolileal Have you tried it?

@pauloolileal Have you tried it?

If you use Razor Pages with Blazor, it works. But not as a SPA. Besides, my tests were very simple.

I'm not planning to do anything special here to support Blazor.
Assuming you mean Blazor server-side rendering, I don't see any reason why you couldn't use this library as-is.
Blazor in the browser using WASM is definitely out of scope and will almost definitely never work with this library.

Hi great work here! It would be nice to have a sample using Blazor to load a plugin with a razor page with some content.


Not clear how to make composition of futures with CpuPool::execute

I use CpuPool to perform parallel computations in streams, here is my snippet of code:
let entires: Vec<DirEntry> = ...
let cpu_pool = CpuPool::new(num_cpus::get() as u32);
let stream = futures::stream::iter(entries.into_iter().map(|entry| Ok(entry)))
    .map(|entry| {
        cpu_pool.execute(move || {
            // - open file using `File::open` - returns `Result`
            // - read file using `futures_io::read_to_end` - returns `ReadToEnd` future
            // - parse content of a file using `ReadToEnd::and_then` (this is a heavy task)
        })
    })
    .buffered(num_cpus::get() * 2)
    .filter(...)
    .collect();

Using File::open is more appropriate because the execute returns a future to work that's running on the thread pool, and you can use try! if an error happens when using File::open or methods of Read, Write.

Thanks for the report @zummenix!
The CpuPool type is intended for blocking and/or intensive computations, so you probably won't want to execute more asynchronous/future-based work on it with the closures you're submitting. For that reason you'll probably not want to call read_to_end nor and_then in the closure passed to cpu_pool.execute, but rather you'll just do the normal blocking I/O the standard library provides with standard synchronous code.
I believe that'll give you the parallelization you want, does that make sense?

I can move File::open and read_to_end calls outside of execution block but I still need to run computation heavy tasks and handle Result's errors somehow. Current interface forces me to unwrap things (partially because I'm lazy, partially because I don't care for now).
In my opinion, better would be for CpuPool::execute to accept a Future or IntoFuture, but I don't know how effective/easy to implement it would be. Something like this:
let future = File::open(path).and_then(|mut file| {
    let mut buf = Vec::new();
    try!(file.read_to_end(&mut buf));
    Ok(buf)
}).into_future().and_then(|buf| {
    Ok(try!(parse(buf))
});
cpu_pool.execute(future)

Oh sorry, to clarify, the purpose of CpuPool::execute is not to run a future but rather run a computation on the thread pool itself. Futures are intended to model asynchronous computations or otherwise future events happening, but here we just need to do some synchronous work (reading a file) I believe, right?
As an example, I believe this may suffice for you? Or is this not what you're thinking?
extern crate futures;
extern crate futures_cpupool;

use std::io::{self, Read};
use std::fs::File;
use std::panic;
use std::path::Path;

use futures::{BoxFuture, Future};
use futures_cpupool::CpuPool;

struct Parsed;

fn parse(pool: &CpuPool, path: &Path) -> BoxFuture<Parsed, io::Error> {
    let path = path.to_path_buf();
    let res = pool.execute(|| {
        let mut f = try!(File::open(path));
        let mut contents = Vec::new();
        try!(f.read_to_end(&mut contents));
        try_parse(&contents)
    });
    res.map_err(|e| panic::resume_unwind(e))
       .and_then(|e| e)
       .boxed()
}

fn try_parse(data: &[u8]) -> io::Result<Parsed> {
    panic!()
}

@alexcrichton Thanks for clarification and example. I guess, you're right.


Fix the LED flickering

The lights are flickering a bit. This could be layer 1 or more likely, something with our code.

fixed now, was just some shitty demo code that is fixed by making it less shitty


face_recognition_modal-shared1 error on iis

i'm using iis as server when using the library, face_recognition_modal-shared1 not recognized by the server since it hasn't any extension
any solution how to fix it ?
thank you in advance

You could try to rename the files and give them a custom file extension. But then you also have to include the extensions in the shard list of the corresponding weight manifest json file.


Adding d3 through typings will break the ng-init or npm install

Hi All,
Thanks for looking into this. The issue happens on postinstall script:
Step to replicate:
add d3 library:

npm install d3 --save
typings uninstall d3 --save
run npm install at this point:

console result:
typings ERR! message Unknown dependency: registry:npm/d3#3.0.0+20160211003958
NPM log file:
69 info lifecycle<EMAIL_ADDRESS>Failed to exec postinstall script
70 verbose stack RangeError: Maximum call stack size exceeded
70 verbose stack     at Array.filter (native)
70 verbose stack     at /Users/nbirgani/.nvm/versions/node/v5.9.1/lib/node_modules/npm/lib/install/actions.js:55:37
70 verbose stack     at Array.forEach (native)
70 verbose stack     at markAsFailed (/Users/nbirgani/.nvm/versions/node/v5.9.1/lib/node_modules/npm/lib/install/actions.js:54:16)
70 verbose stack     at /Users/nbirgani/.nvm/versions/node/v5.9.1/lib/node_modules/npm/lib/install/actions.js:57:7
70 verbose stack     at Array.forEach (native)
70 verbose stack     at markAsFailed (/Users/nbirgani/.nvm/versions/node/v5.9.1/lib/node_modules/npm/lib/install/actions.js:54:16)
70 verbose stack     at /Users/nbirgani/.nvm/versions/node/v5.9.1/lib/node_modules/npm/lib/install/actions.js:57:7
70 verbose stack     at Array.forEach (native)
70 verbose stack     at markAsFailed (/Users/nbirgani/.nvm/versions/node/v5.9.1/lib/node_modules/npm/lib/install/actions.js:54:16)
71 verbose cwd /Users/nbirgani/Avetta
72 error Darwin 15.4.0
73 error argv "/Users/nbirgani/.nvm/versions/node/v5.9.1/bin/node" "/Users/nbirgani/.nvm/versions/node/v5.9.1/bin/npm" "install"
74 error node v5.9.1
75 error npm  v3.8.6
76 error Maximum call stack size exceeded
77 error If you need help, you may report this error at:
77 error     https://github.com/npm/npm/issues
78 verbose exit [ 1, true ]

That seems to be an issue with typings instead of whith angular-cli really. I don't think there's anything we can do about it, we just call it on the postinstall script as you mentioned.


Cyrillic git branch name causes UnicodeDecodeError

At this point:
~/.venvs/farfor/lib/python2.7/site-packages/raven/versioning.py", line 28, in fetch_git_sha
    head = text_type(fp.read()).strip()
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 27: ordinal not in range(128)

сука


OOM with visualize script

I get an OOM error with the visualize script:
RuntimeError: CUDA out of memory. Tried to allocate 22.00 MiB (GPU 0; 22.20 GiB total capacity; 19.53 GiB already allocated; 4.06 MiB free; 20.21 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF
Running via:
 python script/visualize.py -c config/fb15k237_visualize.yaml --checkpoint ~/scratch/experiments/LogicalQuery/FB15k237LogicalQuery/GNN-QE/2022-09-18-13-34-00/model_epoch_10.pth
I was able to run training ok after adjusting the batch_size in the config.
Any advice on adjusting config for the visualize script to avoid the OOM error?  I'm testing this in an AWS environment with 24G GPUs.

(I'll just run this on a machine with bigger GPUs, but am curious if anything can be tweaked in the config.)

FYI, this does work fine for me when i switched to a bigger GPU on google cloud.

Hi! The GPU memory consumption is generally proportional to the batch size. The default configuration file is tuned according to a 32GB GPU, but you may change it to fit into smaller GPUs.

Yes, I get OOM with batch size of 1 for the visualize script whereas the train script works in the same environment. (and they both work fine with larger GPUs).


:recycle: Create level objects as sub-documents

Create new levelSchema
Embed levelObjects in Game

Reverted the commit that includes the hiddenLevel in the backend, because this leads to unnecessary complexity for the calculation of the current and next level. Will do this in the frontend only in another PR.

Also adapted the Frontend to the new levelObjects. See comments in code for typescript assertion functions. Might be not the ideal way, but this way you can get to know a new technique.

Please squash and merge after approval.


Support more than 10 💎 at a time

Use Array#shift(10) to build batches and then sleep(1) to pause between them, since the rate limit is 10 requests per second.

Don’t output info about batches unless there is more than one.


Validation of Exported model (SavedModel format)

I created a very simple ImageProject with 3 classes and 10 images each, lefthand, righthand and no hand ( just background), using the images as trained as verification I get 100 % hit on model in website:  I export model in SavedModel format and convert to Onnx (tf2onnx) and import this.  I do not get 100% hitrate for same image.   In fact the results are highly unpredictable and of no use.
Thus I request a way to validate the export was ok and useful.
I tried to troubleshoot by using different op set and different image formats (jpg/png) etc but no luck so far.
What versions are compatible (if any) etc.

I used this python script on the onnx file additionally with no different outcome,
remove_initializer_from_input.py  (via onnxtools)

I convert from saved model as this:

python -m tf2onnx.convert --saved-model ./model.savedmodel/ --output model.onnx --opset 7 --verbose
python -m remove_initializer_from_input --input model.onnx --output model2.onnx  (to check if something missing).
Run this interference python script (class1.png from Class1 image set, change to class2.png from Class2 image set and there will show the difference, this is essential the same as shown in ML.net implementation so the problem is likely in the onnx model, or included already in the SavedModel exported (change input/output parameters according to model in use):

import onnxruntime as rt
import numpy as np
import os, sys
import cv2
from PIL import Image
Open the model:
sess = rt.InferenceSession("./model2.onnx")
Test all the empty images
Check image using the ONNX pipeline
img = cv2.imread('class1.png')
#img = np.dot(img[...,:3], [0.299, 0.587, 0.114])
img = cv2.resize(img, dsize=(224, 224), interpolation=cv2.INTER_AREA)
img.resize(1,3,224,224)
target=np.array(img,dtype=np.float32)
out = sess.run(["sequential_3"], {"sequential_1_input": target.astype(np.float32)})
print("Is classified as: {}.".format(out[0].flatten()))

Trying open the saved model in tensorflow gives strange error output:
Could not find matching concrete function to call loaded from the SavedModel.  Based on the input shape that is different in the SavedModel.
According to section Verifying a Converted Model:
https://onnxruntime.ai/docs/tutorials/tf-get-started.html
I tried to adapt this to the image sequence above to compare the onnx and savedmodel outputs.

This is the test with some modifications to match this above that is not successful:
img = cv2.imread('class1.png')
img.resize(1,224,224,3)
target=np.array(img,dtype=np.float32)
import tensorflow as tf
model = tf.saved_model.load("./model.savedmodel/")
out_tf = model({"sequential_1_input": target.astype(np.float32)})

The conclusion so far that the export model SavedModel from teachablemachine ImageProject is incorrect regarding the classification,  it might give correct prediction score number even if they diff.  I might also miss some pre/postprocessing in
the verification methods above?
Is there a even simpler example on two crosscheck and validate the SavedModel exported that works ok?


WWW-105 PatternLab video clean up

Jira
https://pegadigitalit.atlassian.net/browse/WWW-105
Summary
Updated the existing PatternLab instance with the new version of the Brightcove video
Details

Updated all the examples of videos being used within the PatternLab instance to the new Brigthcove video method
Added a "Deprecated" label on the Videos PL tab and added a deprecation message to the videos docs
Updated the build to output an isolated Brightcove CSS file for use within the Brigthcove Studio player

How to test
Check instances of videos in the PL instance and confirm they are still working as expected

Is the title and play time still supposed to show? If you go to accordion component variations and open the video tab on this branch and on master you can see what i mean.
There is no longer an example video in Figure Media Variations
I can see the title is missing in the Modal demo, as well as Tabs Content.
in the deprecated video warning, is it possible to link "Drupal integrated Brightcove video component" to the documentation?


Can this library runs on Node.js ?

Hi,
I have multiple times tried to make it work in a Node.js environnement but unsucessfully. There is a part in the readMe "Recommended Usage with Node + ESM", so is this possible?
If it's possible, can you provide a simple example?
Thanks in advance

Hi, apologize for the late response.
This lib is meant to be used as a polyfill of the Barcode Detection API, which is a Web API and requires other Web and DOM APIs like canvas, DOMRectReadOnly, etc. Unless they're also properly polyfilled (which may also introduce significant performance loss), this lib is not likely to be used in node.

There is a part in the readMe "Recommended Usage with Node + ESM", so is this possible?

This is for building not running.
If you want to run barcode detections in other JS runtimes, you can check out the lower-level zxing-wasm project this lib depends on, which also provides more control options.


Update read-the-docs to python3

Our read the docs builds produce the following warning:

DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.

We should also add the axom logo to our read-the-docs project at the same time.

I think this config file needs to be updated as part of this: https://github.com/LLNL/axom/blob/develop/.readthedocs.yml

Update merged to develop


Use S3 For Files

Story
As an admin I would like files to be stored and served from AWS S3 so that I don't have to use local storage on my server.
Notes
Mostly this https://github.com/gogits/gogs/issues/2904 .
Stop gap might simply be to create a cron that syncs the attachments to an S3 bucket on an interval.  This would give us a persistent backup of the attachments and might prepare for a switch to using S3 directly for attachments.

@jag3773 If the end goal is to have the content stored in S3, would https://github.com/s3fs-fuse/s3fs-fuse meet our needs? It would allow us to mount an S3 bucket as a virtual drive.

Yes, that would work but it's an extra dependency that I'd rather not have.  Would great if Gogs just interfaced directly with S3.  Seems like there is probably a Go S3 library out there somewhere...

Deprecated by #110


Can`t stream https

Configuration
System:
OS: Linux 4.15 Ubuntu 18.04.3 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i3 CPU       M 350  @ 2.27GHz
Memory: 128.01 MB / 3.65 GB
Shell: 4.4.20 - /bin/bash
Binaries:
Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
npm: 6.10.2 - ~/.nvm/versions/node/v10.16.0/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
npmPackages:
react: 16.9.0 => 16.9.0
react-native: 0.61.5 => 0.61.5
npmGlobalPackages:
create-react-native-app: 2.0.2
What react-native-track-player version are you using?
"react-native-track-player": "^1.2.2",
Issue
I have a problem to stream https url`s,  http is working fine. What can be the problem?
Code
index.js
AppRegistry.registerComponent(appName, () => Main)
TrackPlayer.registerPlaybackService(() => require('./service.js'));
service.js
import TrackPlayer from 'react-native-track-player';
module.exports = async function() {
TrackPlayer.addEventListener('remote-play', () => {
TrackPlayer.play()
})
TrackPlayer.addEventListener('remote-pause', () => {
TrackPlayer.pause()
});
TrackPlayer.addEventListener('remote-next', () => {
TrackPlayer.skipToNext()
});
TrackPlayer.addEventListener('remote-previous', () => {
TrackPlayer.skipToPrevious()
});
TrackPlayer.addEventListener('remote-stop', () => {
TrackPlayer.destroy()
});
};
home.js
class Home extends Component {
componentDidMount() {
this.props.getDatabase();
TrackPlayer.setupPlayer().then(async () => {
TrackPlayer.updateOptions({
stopWithApp: true,
capabilities: [
TrackPlayer.CAPABILITY_PLAY,
TrackPlayer.CAPABILITY_STOP
],
compactCapabilities: [
TrackPlayer.CAPABILITY_PLAY,
]
});
}).catch(error => {
console.log('SETUP PLAYERRR', error)
})
}
play = (item) =>	{
  return new Promise((resolve) => {
     this.setState({play: true, id: item.id})
     TrackPlayer.add({
         id: "1", //id ={item.id}
         url: item.url,
         title: "Track Title",
         artist: "Track Artist",
     }).then(res => {
        TrackPlayer.play();
        resolve()
     }).catch(error => {
       console.error('ERROR', error)
    })
 })
}

}

Some of our users are experiencing An SSL error has occurred and a secure connection to the server cannot be made. - are you experiencing the same error?  Maybe only on some OS 13.x devices, not sure yet.

I dont get any error thats a problem
if i put something like this
TrackPlayer.setupPlayer().then(async () => {
  TrackPlayer.add({
      id: "1",
      url: "https://www.soundeffectsplus.com/uploads/prod_audio/40052174_money-coins-in-hand-03.mp3",
      title: "Track Title",
      artist: "Track Artist",
    })
  TrackPlayer.updateOptions({
    stopWithApp: true,
    capabilities: [
      TrackPlayer.CAPABILITY_PLAY,
      TrackPlayer.CAPABILITY_STOP
    ],
    compactCapabilities: [
      TrackPlayer.CAPABILITY_PLAY,
    ]
  });
  TrackPlayer.play();

}).catch(error => {
console.log('SETUP PLAYERRR', error)
})
then https url will play but if i put https url of radio for example this one https://streaming.tdiradio.com/top40.mp3
then it wont play, notification appear in status bar and after one second dissapear

This is the error im getting
java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
is there any fix for react native?

Add this to MainApplication.java
//Create a trust manager that does not validate certificate chains
TrustManager[] trustAllCerts = new TrustManager[] {new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers()
{
return null;
}
public void checkClientTrusted(X509Certificate[] certs, String authType)
{
//
}
public void checkServerTrusted(X509Certificate[] certs, String authType)
{
//
}
}
//Install the all-trusting trust manager
try {
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (KeyManagementException|NoSuchAlgorithmException e) {
e.printStackTrace();
}

@markom983 did your last comment resolve this issue for you?

yes, this fix work for me


Add feature to filter submissions by team name in my submissions

Changes proposed in this pull request:

Added the input box to get the filter query as participant team name

Used the challenge submission API with filter query for filtering the submissions

Link to live demo: http://pr-166-evalai.surge.sh

@Sanji515 resolve the conflicts and pass the build.

@Sanji515 Please remove the conflicts here.

@RishabhJain2018 @lunayach @Shekharrajak Please review

Codecov Report

Merging #166 into master will decrease coverage by 0.08%.
The diff coverage is 33.33%.

@@            Coverage Diff            @@
##           master    #166      +/-   ##
=========================================
- Coverage   52.19%   52.1%   -0.09%
=========================================
  Files          60      60
  Lines        3148    3163      +15
  Branches      367     369       +2
=========================================
+ Hits         1643    1648       +5
- Misses       1421    1431      +10
  Partials       84      84

Impacted Files
Coverage Δ

...rc/app/components/utility/input/input.component.ts
57% <0%> (-1.77%)
:arrow_down:

...lengesubmissions/challengesubmissions.component.ts
34.83% <38.46%> (+0.3%)
:arrow_up:

src/app/services/endpoints.service.ts
70.27% <50%> (-0.57%)
:arrow_down:

Impacted Files
Coverage Δ

...rc/app/components/utility/input/input.component.ts
57% <0%> (-1.77%)
:arrow_down:

...lengesubmissions/challengesubmissions.component.ts
34.83% <38.46%> (+0.3%)
:arrow_up:

src/app/services/endpoints.service.ts
70.27% <50%> (-0.57%)
:arrow_down:

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 99dc91a...f391238. Read the comment docs.

A feature where it fetches all the Teams having their name starting (and/or some other criteria apart from the exact one) with what's already typed in the search input field might be more useful.
Yes, @Sanji515 Please open up an issue for this as well.

@RishabhJain2018 as it requires the backend change only so instead of issue how about if I open a PR in EvalAI for filtering even it matches the starting keywords of the query.

Please open it there and mention this PR as a reference.


generating empty config files

Hi,
thanks for the great script. i had used it one of my server and it was working great. i had initially added 3 users and they worked fine.
Now when i run the script it generates empty config file for openpn with no content for certificate or keys.
can you help with this.
thank you

Looks like you broke something and this isn't related to the script.


Add SubURL to redirect path for transferred/renamed repos

Fixes #8588

Codecov Report

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

@@            Coverage Diff            @@
##             master    #8632   +/-   ##
=========================================
  Coverage          ?   41.67%
=========================================
  Files             ?      529
  Lines             ?    68550
  Branches          ?        0
=========================================
  Hits              ?    28569
  Misses            ?    36325
  Partials          ?     3656

Impacted Files
Coverage Δ

modules/context/repo.go
55.7% <0%> (ø)

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 a41a965...0e80a05. Read the comment docs.

Please backport

This maybe backport to v1.9

@lunny sure, I'll make a backport in a bit here. Can you add the backport/v1.9 label?


time_limits not respected for object detection

Hello,
I set time_limits to 60*10 seconds (10 minutes) with 3 epoch.
The three epochs finished but the fit is still running more than one hour after end of last epoch training:
time_limits = 60*10  # 5 hours epochs = 3 detector = task.fit(dataset_train,                     epochs=epochs,                     net='resnet50_v1b',                     batch_size=4,                     meta_arch='faster_rcnn',                     ngpus_per_trial=2,                     SyncBN=True,                     lr=ag.Categorical(0.02, 0.01, 0.005, 0.002, 2e-4, 5e-4),                     time_limits=time_limits)
the dataset is the motorbike datasets provided.
I get quickly the following results for the last epoch:
[Epoch 2] Training cost: 139.507, RPN_Conf=0.002,RPN_SmoothL1=0.012,RCNN_CrossEntropy=0.035,RCNN_SmoothL1=0.092
[Epoch 2] Validation: motorbike=0.8803156791528884 mAP=0.8803156791528884
Thank you in advance

It is expected that this is now fixed in pre-release and upcoming v0.1 due to overhauls in the code.


Add Hspec discover support.

A work in progress. Closes #18.

Covered with https://github.com/lwm/tasty-discover/commit/7884c55b76ed388a02c137c8b9e269e725c867d1.


Fixed README example

fixes #61

this Pr should probably not get merged in favour of #65

Fixed in #73


[BUG] Azure ServiceBus memory leak

Describe the bug
The number of ServiceBusReactorAmqpConnection instances is rising until there is no more memory on the heap. When the app is started the number of instances is 44, because we use 44 queues, but with time it rises to above 500 and eventually we get OutOfMemoryError. The heap size is limited to around 500 MB.
When the OutOfMemoryError happens, all the ServiceBusReactorAmqpConnection have sessionMap set to 0. This lead us to conclusion that garbage collector is not cleaning these connections that are not being used.
We have never had similar problem before and it happens during normal load.
Exception or Stack Trace
The following exceptions might be relevant to the problem:
reactor.core.Exceptions$ErrorCallbackNotImplemented: java.lang.NullPointerException: Cannot invoke "java.util.List.add(Object)" because "this._sessions" is null
Caused by: java.lang.NullPointerException: Cannot invoke "java.util.List.add(Object)" because "this._sessions" is null
	at org.apache.qpid.proton.engine.impl.ConnectionImpl.session(ConnectionImpl.java:91)
	at org.apache.qpid.proton.engine.impl.ConnectionImpl.session(ConnectionImpl.java:39)

and
com.azure.core.amqp.exception.AmqpException: onSessionRemoteClose connectionId[MF_1e9f94_1730303967974], entityName[mdk-mnp-command-queue] condition[Error{condition=amqp:connection:forced, description='The connection was closed by container 'ce030eed2af746d4a84caa602d8b170a_G0' because it did not have any active links in the past 300000 milliseconds. TrackingId:ce030eed2af746d4a84caa602d8b170a_G0, SystemTracker:gateway5, Timestamp:2024-10-30T16:24:05', info=null}], errorContext[NAMESPACE: mdk-westeurope-eu-e-servicebus.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: some-queue]
	at com.azure.core.amqp.implementation.ExceptionUtil.toException(ExceptionUtil.java:90)
	at com.azure.core.amqp.implementation.handler.SessionHandler.onSessionRemoteClose(SessionHandler.java:139)

These exceptions started ocurring when we switched from 7.17.1 to 7.17.3.
To Reproduce
There are no special steps to reproduce.
Code Snippet
The following code is executed for every queue:
val processorClient: ServiceBusProcessorClient = ServiceBusClientBuilder()
            .credential(serviceBusFullyQualifiedName, DefaultAzureCredentialBuilder().build())
            .processor()
            .queueName(queueName)
            .processMessage(handler)
            .processError { context -> processError(context) }
            .maxConcurrentCalls(10)
            .disableAutoComplete()
            .maxAutoLockRenewDuration(Duration.ZERO)
            .prefetchCount(0)
            .buildProcessorClient()
processorClient.start()

Expected behavior
The memory consumption of the service bus library shouldn't raise to the point that cause OutOfMemoryError.
Setup (please complete the following information):
OS: Linux
Library/Libraries: com.azure:azure-messaging-servicebus:7.17.3
Java version: 21
App Server/Environment: AKS
Frameworks: Sprint Boot

Hello @gataricd, this is resolved recently, you can find more details here https://github.com/Azure/azure-sdk-for-java/issues/41865
Note that you will still see the session disconnect/reconnect logs (which is expected) but the new version should address the NullPointerException.
Update to 7.17.5 dependency
<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-messaging-servicebus</artifactId>
    <version>7.17.5</version>
</dependency>

Update the ServiceBusClientBuilder for "com.azure.core.amqp.cache"
When building any client (ServiceBusProcessorClient, ServiceBusReceiverClient, ServiceBusSenderClient etc..) use the configuration ("com.azure.core.amqp.cache"), as shown below. Make sure this configuration is selected for all the places where the application creates a new ServiceBusClientBuilder -

new ServiceBusClientBuilder()
            .connectionString(queueProperties.connectionString())
                     .configuration(new ConfigurationBuilder()
                         .putProperty("com.azure.core.amqp.cache", "true")
                         .build())
            .processor()
            .queueName(queueName)
            .processMessage(handler)
            .processError { context -> processError(context) }
            .maxConcurrentCalls(10)
            .disableAutoComplete()
            .maxAutoLockRenewDuration(Duration.ZERO)
            .prefetchCount(0)
            .buildProcessorClient()

Choosing this configuration is important to resolve the problem -  java.lang.NullPointerException: Cannot invoke "java.util.List.add(Object)" because "this._sessions" is null
Ensure right transitive dependencies
Make sure the transitive dependencies (azure-core-amqp, azure-core) are resolved to expected versions.
mvn dependency:tree

[INFO] ...
[INFO] +- com.azure:azure-messaging-servicebus:jar:7.17.5:compile
[INFO] |  +- com.azure:azure-core:jar:1.53.0:compile
[INFO] |  |  +- ..
[INFO] |  |  \- ...
[INFO] |  \- com.azure:azure-core-amqp:jar:2.9.10:compile
[INFO] |     +- com.microsoft.azure:qpid-proton-j-extensions:jar:1.2.5:compile
[INFO] |     \- org.apache.qpid:proton-j:jar:0.34.1:compile

Note: In the upcoming version the need for opt-in "com.azure.core.amqp.cache" will be removed

/unresolve
@anuchandy thanks for the answer, unfortunately the proposed changes didn't resolve the problem. We are still getting:
java.lang.NullPointerException: Cannot invoke "java.util.List.add(Object)" because "this._sessions" is null
after updating to 7.17.5 and setting com.azure.core.amqp.cache to true.

Hello @gataricd, thanks for trying it. Could you share -20/+20 minutes of DEBUG logs around this NullPointerException.

Hi, we are seeing the same issue with 7.17.5.
We can provide the requested logs, but not here. Should we create a support case and upload the logs through that?

Hi, we are seeing the same issue with 7.17.5.
We can provide the requested logs, but not here. Should we create a support case and upload the logs through that?

My apologies, we didn't read @anuchandy description thoroughly enough initially. After adding

Update the ServiceBusClientBuilder for "com.azure.core.amqp.cache"

as described, we are not longer seeing the issue.

Closing as there is support case for it. Currently, it appears that the opt-in may not be configured in some builders or is not recognized at runtime for the SDK to detect hence library continues to use deprecated AmqpChannelProcessor. If the case conclusion differs from this, I will update here.


Remove constraint(String, String, String) and named overloads

Pending discussion of #27647
Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@bot-gradle test and merge

The merge queue build has started. Click here to see all failures if any.


f-droid

request to make the Anddroid version available on f-droid

I'm not keen on f-droid because they started with a fork of the aptoide client (and I hate aptoide, they hosted many pirated copies of my apps over the years).

Leaving this open as there are occasional queries about an android version, and the Flutter code is now open source so anyone can update it to use the latest data and release on f-droid or whatever.


Remove componentWillMount for React >16 StrictMode compliance

Closes #120
I am currently unable to test this (as noted and asked about here), but this is such a seemingly simple change (famous last words?) that I'm putting this PR up anyway so that I can get some :eyes: on it.

Thank you! 🙏This looks great! 😀
Sorry about the dev environment not working! I'm going to update the build process and development docs right now.

No worries


Errors when attempting to run example run.sh or x.sh

I am attempting learn how to use you package.  I am excited at the prospect of a long overdue replacement for https://github.com/dart-archive/js_facade_gen
Any help you could provide would be greatly appreciated! :pray:
I am sure I am missing something - I included a flutter doctor at the end - I am up to date on master channel as of today.
My fork of the repo is https://github.com/timmaffett/typings - you can see how I tried to follow the directions to add monaco-editor.
(I am evaluating monaco as a replacement for the codemirror editor within future dartpad versions and was hoping to use your package to make the bindings.)
my  /src/typings/typings/lib/d/monaco_editor.dart file:
library typings.monacoeditor;

import 'package:typings/annotations.dart';

@Typings.npm(
    package: 'monaco-editor',
    version: '0.38.0',
    dirName: 'monaco_editor',
    contextCheck: 'monaco',
    uses: ['core'])
export 'monaco_editor/monaco_editor.dart';

dart run --enable-asserts --enable-experiment="inline-class" build_runner build --enable-experiment="inline-class"

[INFO] Generating build script completed, took 519ms
[WARNING] ../ts2dart/lib/src/project.dart:61:1: Error: The 'inline-class' language feature is disabled for this library.
Try removing the package language version or setting the language version to 3.1 or higher.
inline class ExternalInteropModule {
^^^^^^
../ts2dart/lib/src/project.dart:77:1: Error: The 'inline-class' language feature is disabled for this library.
Try removing the package language version or setting the language version to 3.1 or higher.
inline class ExternalInteropProject {
^^^^^^
../ts2dart/lib/src/metadata/struct.dart:4:1: Error: The 'inline-class' language feature is disabled for this library.
Try removing the package language version or setting the language version to 3.1 or higher.
inline class MetadataCtor {
^^^^^^
../ts2dart/lib/src/metadata/struct.dart:10:1: Error: The 'inline-class' language feature is disabled for this library.
Try removing the package language version or setting the language version to 3.1 or higher.
inline class MetadataIndex {
^^^^^^
../ts2dart/lib/src/metadata/struct.dart:22:1: Error: The 'inline-class' language feature is disabled for this library.
Try removing the package language version or setting the language version to 3.1 or higher.
inline class MetadataCall {
^^^^^^
../ts2dart/lib/src/metadata/struct.dart:28:1: Error: The 'inline-class' language feature is disabled for this library.
Try removing the package language version or setting the language version to 3.1 or higher.
inline class MetadataStruct {
^^^^^^
../ts2dart/lib/src/metadata/struct.dart:80:1: Error: The 'inline-class' language feature is disabled for this library.
Try removing the package language version or setting the language version to 3.1 or higher.
inline class MetadataTypeRef {
^^^^^^
../ts2dart/lib/src/metadata/struct.dart:88:1: Error: The 'inline-class' language feature is disabled for this library.
Try removing the package language version or setting the language version to 3.1 or higher.
inline class MetadataStructMember {
^^^^^^
[INFO] Precompiling build script... completed, took 1.4s
[SEVERE] Failed to precompile build script .dart_tool/build/entrypoint/build.dart.
This is likely caused by a misconfigured builder definition.

When trying to run x.sh I get the following error
webdev serve example --enable-experiment=inline-class

[SEVERE] Failed to precompile build script .dart_tool/build/entrypoint/build.dart.
[SEVERE] This is likely caused by a misconfigured builder definition.

[SEVERE] This is likely caused by a misconfigured builder definition.
[SEVERE]
Unhandled exception:
Bad state: Unable to start build daemon.
#0      _handleDaemonStartup.<anonymous closure> (package:build_daemon/client.dart:79:21)
#1      _runUserCode (dart:async/stream_pipe.dart:11:23)
#2      Stream.firstWhere.<anonymous closure> (dart:async/stream.dart:1698:9)
#3      _RootZone.runGuarded (dart:async/zone.dart:1582:10)
#4      _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:392:13)
#5      _BufferingStreamSubscription._sendDone (dart:async/stream_impl.dart:402:7)
#6      _BufferingStreamSubscription._close (dart:async/stream_impl.dart:291:7)
#7      _SyncBroadcastStreamController._sendDone.<anonymous closure> (dart:async/broadcast_stream_controller.dart:399:22)
#8      _BroadcastStreamController._forEachListener (dart:async/broadcast_stream_controller.dart:322:15)
#9      _SyncBroadcastStreamController._sendDone (dart:async/broadcast_stream_controller.dart:398:7)
#10     _BroadcastStreamController.close (dart:async/broadcast_stream_controller.dart:268:5)
#11     _AsBroadcastStreamController.close (dart:async/broadcast_stream_controller.dart:505:27)
#12     _RootZone.runGuarded (dart:async/zone.dart:1582:10)
#13     _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:392:13)
#14     _BufferingStreamSubscription._sendDone (dart:async/stream_impl.dart:402:7)
#15     _BufferingStreamSubscription._close (dart:async/stream_impl.dart:291:7)
#16     _SinkTransformerStreamSubscription._close (dart:async/stream_transformers.dart:87:11)
#17     _EventSinkWrapper.close (dart:async/stream_transformers.dart:21:11)
#18     _StringAdapterSink.close (dart:convert/string_conversion.dart:241:11)
#19     _LineSplitterSink.close (dart:convert/line_splitter.dart:141:11)
#20     _SinkTransformerStreamSubscription._handleDone (dart:async/stream_transformers.dart:132:24)
#21     _RootZone.runGuarded (dart:async/zone.dart:1582:10)
#22     _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:392:13)
#23     _BufferingStreamSubscription._sendDone (dart:async/stream_impl.dart:402:7)
#24     _BufferingStreamSubscription._close (dart:async/stream_impl.dart:291:7)
#25     _SinkTransformerStreamSubscription._close (dart:async/stream_transformers.dart:87:11)
#26     _EventSinkWrapper.close (dart:async/stream_transformers.dart:21:11)
#27     _StringAdapterSink.close (dart:convert/string_conversion.dart:241:11)
#28     _Utf8ConversionSink.close (dart:convert/string_conversion.dart:295:20)
#29     _ConverterStreamEventSink.close (dart:convert/chunked_conversion.dart:78:18)
#30     _SinkTransformerStreamSubscription._handleDone (dart:async/stream_transformers.dart:132:24)
#31     _RootZone.runGuarded (dart:async/zone.dart:1582:10)
#32     _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:392:13)
#33     _BufferingStreamSubscription._sendDone (dart:async/stream_impl.dart:402:7)
#34     _BufferingStreamSubscription._close (dart:async/stream_impl.dart:291:7)
#35     _SyncStreamControllerDispatch._sendDone (dart:async/stream_controller.dart:784:19)
#36     _StreamController._closeUnchecked (dart:async/stream_controller.dart:639:7)
#37     _StreamController.close (dart:async/stream_controller.dart:632:5)
#38     _Socket._onData (dart:io-patch/socket_patch.dart:2375:21)
#39     _RootZone.runUnaryGuarded (dart:async/zone.dart:1594:10)
#40     _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:339:11)
#41     _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#42     _SyncStreamControllerDispatch._sendData (dart:async/stream_controller.dart:776:19)
#43     _StreamController._add (dart:async/stream_controller.dart:650:7)
#44     _StreamController.add (dart:async/stream_controller.dart:598:5)
#45     new _RawSocket.<anonymous closure> (dart:io-patch/socket_patch.dart:1893:35)
#46     _NativeSocket.issueReadEvent.issue (dart:io-patch/socket_patch.dart:1336:18)
#47     _microtaskLoop (dart:async/schedule_microtask.dart:40:21)
#48     _startMicrotaskLoop (dart:async/schedule_microtask.dart:49:5)
#49     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:123:13)
#50     _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:190:5)

flutter doctor output:
flutter doctor -v
[✓] Flutter (Channel master, 3.10.0-19.0.pre.19, on Microsoft Windows [Version 10.0.25352.1], locale en-US)
    • Flutter version 3.10.0-19.0.pre.19 on channel master at C:\src\flutter
    • Upstream repository git@github.com:flutter/flutter.git
    • Framework revision 00cd3edae3 (10 hours ago), 2023-05-03 01:02:55 +0800
    • Engine revision 6fe3f50797
    • Dart version 3.1.0 (build 3.1.0-64.0.dev)
    • DevTools version 2.23.1

[✓] Windows Version (Installed version of Windows is version 10 or higher)

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    • Android SDK at C:\Users\Tim\AppData\Local\Android\sdk
    • Platform android-33, build-tools 33.0.0
    • Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[✓] Visual Studio - develop for Windows (Visual Studio Community 2022 17.5.4)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.5.33530.505
    • Windows 10 SDK version 10.0.22621.0

[✓] Android Studio (version 2022.2)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)

[✓] Android Studio (version 4.2)
    • Android Studio at C:\src\OLD_android_studios\android-studio-ide-202.7094744
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)

[✓] IntelliJ IDEA Community Edition (version 2020.1)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2020.1.1
    • Flutter plugin version 51.0.2
    • Dart plugin version 201.7223.99

[✓] VS Code (version 1.77.3)
    • VS Code at C:\Users\Tim\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.62.0

No problem. Enjoy your vacation!

It seems to be some change in the SDK 3.1.0 regarding the inline classes.
Can you try to bump up the dependency version in your pubspec.yaml?
environment:
  sdk: '>=3.0.0-277.0.dev <4.0.0'

to something like
environment:
  sdk: '>=3.1.0-64.0.dev <4.0.0'

Bumping it to 3.1.0-63.1.beta worked for me

I will close this issue. Feel free to open another one if you hit anything, thanks


Cluster marker disappear when close to window boundaries

White box is a cluster marker. If I will move map 5px left, marker will be removed from dom.
Is there a way to remove the marker after it goes behind the screen?

I have similar problem, but not only cluster will disappear, but also marker - if at least 1px touches borders, even coordinates are still on boundries (when you remove Cluster marker behavior is correct)
it is problematic for some UX, because it break you marker overview

I suppose I ran into another flavour of this issue in https://github.com/alex3165/react-mapbox-gl/issues/867


Unexpected token - You may need an appropriate loader to handle this file type

Hi everyone, I just try to run this example (react-transitions - codesandbox.io => https://codesandbox.io/embed/3r5o553y61 ) from my desktop.When I try to run it   with the npm run command,my terminal print this error:
Module parse failed: /Users/leonardoaranibar/Desktop/react-transitions/node_modules/react-icons/md/person.js Unexpected token (6:4)
You may need an appropriate loader to handle this file type.
|
| const MdPerson = props => (
|     <Icon viewBox="0 0 40 40" {...props}>
|         <g><path d="m20 23.4c4.5 0 13.4 2.1 13.4 6.6v3.4h-26.8v-3.4c0-4.5 8.9-6.6 13.4-6.6z m0-3.4c-3.7 0-6.6-3-6.6-6.6s2.9-6.8 6.6-6.8 6.6 3.1 6.6 6.8-2.9 6.6-6.6 6.6z"/></g>
|     </Icon>

My npm version is: 5.6.0 and my node Version is :    v8.9.1
I think that this issue is very easy to fix with babel and webpack but this example just use react-script
https://babeljs.io/docs/plugins/transform-react-jsx
https://github.com/boopathi/react-svg-loader/issues/152
So How I can Fixed?

Hi everyone :
Happy new year ,don't worry about this issue I make a simple solution into my repository , I will try to make pull request for this repository ,thanks any way  👍.
https://github.com/LeoCR/react-icons

@LeoCR any news on this create-react-app's side?


Add make clean

You should be able to do make clean.

as an alternative you can run ./rebar clean


ISPN-5710 Unknown entity name when indexing entities defined in inner…

… classes
https://issues.jboss.org/browse/ISPN-5710

Looking ..

Integrated, thanks Gustavo! And sorry for missing your comment, Adrian :)

I see another 3 places where getCanonicalName() should be replaced with getName()

New PR here https://github.com/infinispan/infinispan/pull/3681


TypeError: camelCase.camelCase  is not a function

Describe the bug
type error
To Reproduce
Steps to reproduce the behavior:
gql-gen --config codegen.yml

then this:
TypeError: camelCase.camelCase
is not a function
        at ReactApolloVisitor._buil
dHooksJSDoc (/home/capaj/work-repos
/looop/project-alpha3/node_modules/
@graphql-codegen/typescript-react-a
pollo/index.cjs.js:148:23)
        at ReactApolloVisitor._buil
dHooks (/home/capaj/work-repos/looo
p/project-alpha3/node_modules/@grap
hql-codegen/typescript-react-apollo
/index.cjs.js:176:34)
        at ReactApolloVisitor.build
Operation (/home/capaj/work-repos/l
ooop/project-alpha3/node_modules/@g
raphql-codegen/typescript-react-apo
llo/index.cjs.js:233:52)
        at ReactApolloVisitor.Opera
tionDefinition (/home/capaj/work-re
pos/looop/project-alpha3/node_modul
es/@graphql-codegen/visitor-plugin-
common/index.cjs.js:1768:33)
        at Object.visit
(/home/capaj/work-repos/looop/proje
ct-alpha3/node_modules/graphql/lang
uage/visitor.js:242:26)
        at Object.plugin
(/home/capaj/work-repos/looop/proje
ct-alpha3/node_modules/@graphql-cod
egen/typescript-react-apollo/index.
cjs.js:249:35)
        at executePlugin
(/home/capaj/work-repos/looop/proje
ct-alpha3/node_modules/@graphql-cod
egen/core/index.cjs.js:60:41)
        at process._tickCallback (i
nternal/process/next_tick.js:68:7)
    TypeError: camelCase.camelCase
is not a function
        at ReactApolloVisitor._buil
dHooksJSDoc (/home/capaj/work-repos
/looop/project-alpha3/node_modules/
@graphql-codegen/typescript-react-a
pollo/index.cjs.js:148:23)
        at ReactApolloVisitor._buil
dHooks (/home/capaj/work-repos/looo
p/project-alpha3/node_modules/@grap
hql-codegen/typescript-react-apollo
/index.cjs.js:176:34)
        at ReactApolloVisitor.build
Operation (/home/capaj/work-repos/l
ooop/project-alpha3/node_modules/@g
raphql-codegen/typescript-react-apo
llo/index.cjs.js:233:52)
        at ReactApolloVisitor.Opera
tionDefinition (/home/capaj/work-re
pos/looop/project-alpha3/node_modul
es/@graphql-codegen/visitor-plugin-
common/index.cjs.js:1768:33)
        at Object.visit
(/home/capaj/work-repos/looop/proje
ct-alpha3/node_modules/graphql/lang
uage/visitor.js:242:26)
        at Object.plugin
(/home/capaj/work-repos/looop/proje
ct-alpha3/node_modules/@graphql-cod
egen/typescript-react-apollo/index.
cjs.js:249:35)
        at executePlugin
(/home/capaj/work-repos/looop/proje
ct-alpha3/node_modules/@graphql-cod
egen/core/index.cjs.js:60:41)
        at process._tickCallback (i
nternal/process/next_tick.js:68:7)

My GraphQL schema:

I don't think it's needed, I can amend this if it is

My GraphQL operations:

I don't think it's needed, I can amend this if it is

My codegen.yml config file:

overwrite: true

generates:
  front-end/src/graphql/gqlPrivateSchema.tsx:
    schema: 'gqlSchemas/private.graphql'
    documents:
      - 'front-end/**/*.gql'
      - '!front-end/src/app-admin/**'
    plugins:
      - typescript
      - typescript-operations
      - typescript-react-apollo
      - add: '/* THIS IS A GENERATED FILE, DO NOT EDIT */'
  front-end/src/app-admin/graphql/gqlSuperuserSchema.tsx:
    schema: 'gqlSchemas/superuser.graphql'
    documents:
      - 'front-end/src/app-admin/**'
    plugins:
      - typescript
      - typescript-operations
      - typescript-react-apollo
      - add: '/* THIS IS A GENERATED FILE, DO NOT EDIT */'
  front-end/src/graphql/gqlPrivateSchemaFragments.tsx:
    schema: 'gqlSchemas/private.graphql'
    plugins:
      - fragment-matcher
      - add: '/* THIS IS A GENERATED FILE, DO NOT EDIT */'
config:
  withHooks: true
  withHOC: false
  withComponent: false
  apolloReactHooksImportFrom: '@apollo/react-hooks'
  reactApolloVersion: 3
  scalars:
    EmailAddressWithTLD: string
    NonNegativeFloat: number
    NonNegativeInt: number
    PositiveInt: number
    DateTime: string
  namingConvention:
    enumValues: keep
hooks:
  afterOneFileWrite:
    - prettier --write

Expected behavior
no type error
Environment:

OS:
@graphql-codegen/...: 1.10.1
NodeJS: 10.17.0

Additional context
On 1.9.1 it compiles without any issue

Also experiencing this after the latest version update

This was introduced in #3145

Could you try with the following version? If you still have any error, please share the stack trace.

Doesn't seem to fix the problem for me with version 1.10.1-alpha-c25db63c.4

I was able to get my setup working with this combination:
<EMAIL_ADDRESS><EMAIL_ADDRESS>

@coreylight Could you try 1.10.1-alpha-c25db63c.4 canary version for all packages (both ts-react-apollo and cli)?

Same problem. 1.10.1-alpha-c25db63c.4 does not solve it for me

I installed 1.8.3. Works fine for me.

https://codesandbox.io/s/friendly-glade-x1u9w
Could you help me reproduce it? You can see there is no errors in this sandbox.

I've tried reproduce it here.
https://codesandbox.io/s/gifted-golick-xjg0h?fontsize=14&hidenavigation=1&theme=dark
In sandbox I have         → Cannot find module 'change-case' : )
Hope it will help you

@kolengri Your case is a little bit different :) change-case has introduced some breaking changes recently. That package is independent from codegen. But we decided to add some workaround code while loading the function by usingnamingConventionoption.
1.10.1-alpha-3fc7bb8a.6 should work for all of you :)

Getting the camelCase error with 1.10.0 and 1.10.1-alpha-3fc7bb8a.6. 1.9.1 works.
overwrite: true
generates:
  src/__generated__/graphql.tsx:
    schema:
      - '../**/*.graphql'
    documents: './src/GraphQL/**/*.gql'
    plugins:
      - add: // tslint:disable
      - typescript
      - typescript-operations
      - typescript-react-apollo
      - typescript-compatibility
  # Introspection schema for mock server
  src/__generated__/schema.json:
    schema:
      - '../**/*.graphql'
    documents: './src/GraphQL/**/*.gql'
    plugins:
      - introspection

@PhishyFish Could you share a reproduction using codesandbox? Thanks!

I installed 1.10.1-alpha-d8c376b0.18 and it fixed the problem. @ardatan Thanks.

Fixed in 1.11.0


Add new location service and introduce into overall system

Introduce a new location service for managing locations for fights to occur. This service satisfies a few additional things:

Introduces some gRPC into the system (see #379 and #394).

The location service is a gRPC server, and additionally the rest-fights service will be reconfigured as a gRPC client to be able to talk to this new service

Introduce kotlin into the system (see #143)

Fixes #394
Fixes #143

Hey @cescoffier / @agoncal / @holly-cummins Would any of you mind taking a look at this?
This introduces a new location service, written in Kotlin, which uses gRPC as its communication mechanism. It uses MariaDB to store the locations. I figured something other than PostgreSQL would be nice :)
I've also retrofitted the UI, the fights service, and the narration service to use locations. For the narration service, location data (name, description) are added as variables that can be used by the AI in the narration.


Lock screen should have options for an interval or instant

Solved in https://github.com/CaliCastle/TooDoo/commit/8c7893d53875de35a6f2d7bbe1ea473c5b3ae5d9


disable TCP rendezvous

Fix #604

This change is

r? @canndrew
(maidsafe_highfive has picked a reviewer for you, use r? to override)

closing this as same was done as part of #608


Failed to withdraw from OP Sepolia

I attempted to withdraw from OP Sepolia at app.optimism.io/bridge. I initiated the first withdrawal transaction on Ethereum, and here is the transaction hash.
https://sepolia.etherscan.io/tx/0x1f26c1a91342a8e620c68f1bdc42cc08e7c8356ad0e5a75fdf7d3c02b3e7dd64
I then initiated the second withdrawal transaction on superbridge.app. However, the transaction failed, and I was unable to withdraw. Here is the transaction hash.
https://sepolia.etherscan.io/tx/0x0ee7b257191dde910cb719ca436cf546ed672e74351b17715ff95710d003ce34

We provide support via<EMAIL_ADDRESS>please reach out there with details of the problem

I sent you an email. Could you please check it? Thank you.


Stand up swarm0003

[x] managers 01-03
[x] workers 04-06
[x] Digital Ocean DNS zone with CAA records
[x] Namecheap NS records
[x] Load balancer on NS1
[x] Docker login and pull images
[x] GCP custom monitoring
[x] Shepherd
[x] doctl auth init
[x] Seccheck
[x] Cron jobs for cert renewal

@athandle @kumarnarendra701 over to you for shakedown

@cpswan - Verified all settings and creation of secondary.


WeakMap entries with tuple keys might get lost after GC

Run the code below with node --expose-gc. One might expect the output to be value, but it actually prints undefined.
import { Tuple } from "libtuple";
import { setTimeout } from "node:timers/promises";

const data = new WeakMap();
data.set(Tuple("key"), "value");
await setTimeout();
gc();
console.log(data.get(Tuple("key")));

I think this should be documented under the “Limitations” section of the readme, because I don't see a way to fix this without causing memory leaks.

hmmm, I'll need to really think about this one.

I wonder if a comparison to registered symbols would be helpful in deciding on the correct behavior would be helpful here.
If I recall correctly, registered symbols can't participate in WeakMaps or WeakSets, but I wonder how the memory is handled under the hood for those.
If you call Symbol.for('foo'), and then the resulting value is gc'ed, and then you call Symbol.for('foo') again, do you get back the "same" value, or is it just the "same" for "all" intents and purposes?