Vim9: no error when assigning list of funcrefs with variable number of arguments to variable declared with fixed number of arguments

Describe the bug
In Vim9 script, no error is given when we assign a list/dict of funcrefs with different number of arguments, to a variable declared with a fixed number of arguments.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def OneArg(x: bool)
    enddef
    def TwoArgs(x: bool, y: bool)
    enddef
    var l: list<func(bool, bool, bool)> = [OneArg, TwoArgs]
EOF
)

No error is given.
Expected behavior
A type mismatch error is given; such as this one:
E1012: Type mismatch; expected list<func(bool, bool, bool)> but got list<func(...)>

And to fix this error, we should be required to write func (without parens):
var l: list<func> = [OneArg, TwoArgs]
            ^--^

Because there is currently no specification which can match funcrefs with different numbers of arguments.
IOW, the only acceptable solution is to not specify anything with regards to the funcref arguments.  Besides, in its current form, the previous code is misleading:
var l: list<func(bool, bool, bool)> = [OneArg, TwoArgs]
            ^-------------------^

When we read it, we might wrongly think that all the funcrefs respect the specification.  We currently have no such guarantee, because Vim doesn't give any error when the funcrefs have different numbers of arguments.
Environment

Vim version: 8.2 Included patches: 1-3081
OS: Ubuntu 20.04.2 LTS
Terminal: XTerm(353)

Additional context
In the future, if this syntax gets implemented:

These types can be used in declarations, but no value will have this type:
{type}|{type}  {not implemented yet}

Then, we could also write:
var l: list<func(bool)|func(bool, bool)> = [OneArg, TwoArgs]

Although, it could quickly get too cumbersome to read/write.

Note that currently, during a simple funcref assignment, Vim does check that the number of arguments matches:
vim9script
def Func(b: bool, _)
enddef
var Ref: func(bool) = Func

E1012: Type mismatch; expected func(bool) but got func(bool, unknown)

vim9script
var Ref: func(bool): number = (_, _) => 0

E1012: Type mismatch; expected func(bool): number but got func(any, any): number

In both cases, Vim complains because the funcref expects 2 arguments, while we declared only one (in the variable type).
IMO, this is good, but it's also inconsistent with what happens in a list/dict of funcrefs assignment.

When we read it, we might wrongly think that all the funcrefs respect the specification. We currently have no such guarantee, because Vim doesn't give any error when the funcrefs have different numbers of arguments.

And by "Vim doesn't give any error", I mean not even the types are checked:
vim9script
def OneArg(x: bool)
enddef
def TwoArgs(x: bool, y: bool)
enddef
var l: list<func(job, job, job)> = [OneArg, TwoArgs]

no error

I guess it makes sense.  Since there is no third argument in the functions, the third job can't be checked; so Vim drops type checking for the previous 2 job.  But Vim should still warn us about the number of arguments which don't match.

Because there is currently no specification which can match funcrefs with different numbers of arguments.

We could also introduce the (...) specification.  It would be consistent with what Vim already writes in an error message, and with the output of typename().
So, we could write this:
var l: list<func(...)> = [OneArg, TwoArgs]
                ^---^

Right now, this specification gives an error:
E1010: Type not recognized: )>

The benefit over a simple func is that it gives more meaning to the code:
# this is a list of funcrefs; I have no idea what kind
var l: list<func>

# this is a list of funcrefs; I know that they expect arguments, but their number don't match
var l: list<func(...)>

Because there is currently no specification which can match funcrefs with different numbers of arguments.

We could also introduce the (...) specification.  It would be
consistent with what Vim already writes in an error message, and with
the output of typename().
So, we could write this:
var l: list<func(...)> = [OneArg, TwoArgs]
                ^---^

Right now, this specification gives an error:
E1010: Type not recognized: )>

The benefit over a simple func is that it gives more meaning to the code:
# this is a list of funcrefs; I have no idea what kind
var l: list<func>

# this is a list of funcrefs; I know that they expect arguments, but their number don't match
var l: list<func(...)>

Just leaving out the (...) will have that effect.  It looks a bit
strange, since with the () missing it does not look like a function
call.
We could add "(...)" to mean "any number of arguments", but then we
should probably require it.  That makes it asymmetric to "unknown return
type" though.
func		any arguments, unknown return type
func: void	any arguments, no return
func: type	any arguments, with return type
func()		no arguments, no return
func(): void	no arguments, no return
func(): type	no arguments, with return type

So what's not possible is to specify arguments but unknown return type
(including none).  Perhaps this could work:
func(): ...	no arguments, unknown return type
But it doesn't make much sense to specify arguments and not have an
unknown return type.
--
From "know your smileys":
!-|	I-am-a-Cylon-Centurian-with-one-red-eye-bouncing-back-and-forth
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I think the patch 8.2.3100 has broken something; or it has revealed an inconsistency:
vim9script
def Foo(b: bool)
enddef
var Partial: func(bool) = function(Foo, [true])

no error

vim9script
def Foo(b: bool)
enddef
def Func()
    var Partial: func(bool) = function(Foo, [true])
enddef
Func()

E1012: Type mismatch; expected func(bool) but got func(...): unknown

I would expect both snippets to give the same result; either they both work, or they both fail.

Before the patch, the second snippet worked.  Reading the help, it seems as if it's working as intended:

When using function() the resulting type is "func", a function with any
number of arguments and any return type.

However, it seems to contradict this simple test:
vim9script
def Foo(b: bool): number
    return 0
enddef
echo Foo->function()->typename()

func(bool): number

vim9script
def Foo(b: bool): number
    return 0
enddef
def Func()
    var Ref = function(Foo)
    echo typename(Ref)
enddef
Func()

func(bool): number

The result is not a function with any number of arguments and any return type.  It's a function expecting exactly 1 argument, and a number return type.
And I don't understand why Vim should forget everything it knows about a function as soon as we use function().  If Vim knows the signature of Foo, then I would expect the latter to be used when type inferrence kicks in, whether we use function() or not.  Although, maybe the quotes should be dropped around the function name as a requirement; not sure.

I think the patch 8.2.3100 has broken something; or it has revealed an inconsistency:
vim9script
def Foo(b: bool)
enddef
var Partial: func(bool) = function(Foo, [true])

no error

vim9script
def Foo(b: bool)
enddef
def Func()
    var Partial: func(bool) = function(Foo, [true])
enddef
Func()

E1012: Type mismatch; expected func(bool) but got func(...): unknown

I would expect both snippets to give the same result; either they both
work, or they both fail.

Yeah, this happens because the type returned by function() is
incomplete, and now we check the type.
I think it's best worked around by having function() return a slightly
different type, which indicates to not check the type at all.
Not sure if this really works, let's give it a try.
There is an error though:
var Partial: func(bool) = function(Foo, [true])
Since the argument is provided by the partial, the declaration should
be:
var Partial: func() = function(Foo, [true])

And I don't understand why Vim should forget everything it knows about
a function as soon as we use function().  If Vim knows the signature
of Foo, then I would expect the latter to be used when type
inferrence kicks in, whether we use function() or not.  Although,
maybe the quotes should be dropped around the function name as a
requirement; not sure.

This works at runtime, but at compile type the type returned by
function() is used, which is incomplete.  The function used can be
defined later.
--
From "know your smileys":
:-)-O	Smiling doctor with stethoscope
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

There is an error though:

Ah right, but Vim doesn't complain:
vim9script
def Foo(b: bool)
enddef
var Partial: func(bool) = function(Foo, [true])

no error

vim9script
def Foo(b: bool)
enddef
def Func()
    var Partial: func(bool) = function(Foo, [true])
enddef
Func()

no error

Since the argument is provided by the partial, the declaration should be:
var Partial: func() = function(Foo, [true])

This works in compiled code:
vim9script
def Foo(b: bool)
enddef
def Func()
    var Partial: func() = function(Foo, [true])
enddef
Func()

no error

But not at the script level:
vim9script
def Foo(b: bool)
enddef
var Partial: func() = function(Foo, [true])

E1012: Type mismatch; expected func() but got func(bool)

There is an error though:

Ah right, but Vim doesn't complain:
vim9script
def Foo(b: bool)
enddef
var Partial: func(bool) = function(Foo, [true])

no error

vim9script
def Foo(b: bool)
enddef
def Func()
    var Partial: func(bool) = function(Foo, [true])
enddef
Func()

no error

As mentioned, function() does not return the actual type.  It has to be
figured out at runtime.

Since the argument is provided by the partial, the declaration should be:
var Partial: func() = function(Foo, [true])

This works in compiled code:
vim9script
def Foo(b: bool)
enddef
def Func()
    var Partial: func() = function(Foo, [true])
enddef
Func()

no error

But not at the script level:
vim9script
def Foo(b: bool)
enddef
var Partial: func() = function(Foo, [true])

E1012: Type mismatch; expected func() but got func(bool)

That is a bug.
--
You are only young once, but you can stay immature indefinitely.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Not sure whether this is a bug:
vim9script
def Func(b: bool)
enddef
var Ref: func() = function(Func, [true])
echo typename(Ref)
Ref()

func()
no error

vim9script
def Func(b: bool)
enddef
var Ref: func = function(Func, [true])
echo typename(Ref)
Ref()

func()
E118: Too many arguments for function: <80><fd>R1_Func

I would expect the second snippet to not raise any error; considering that both snippets are almost identical (the only difference is func in the first snippet compared to func() in the second one), and typename() reports the exact same type in both.

I mean, the error message seems confusing:
E118: Too many arguments for function: <80><fd>R1_Func

If it has to be raised, it should be by the first snippet (the one using func()), not the second one (which uses func).  Because func() is more specific than func; it asserts no arguments.  But in practice, it's the opposite.

Assigning a partial with a wrong signature correctly gives an error at the script level:
vim9script
def Func(b: bool)
enddef
var Partial: func(string)
Partial = function(Func, [true])

E1012: Type mismatch; expected func(string) but got func()

But not in compiled code; not even at runtime:
vim9script
def Func(b: bool)
enddef
var Partial: func(string)
def Foo()
    Partial = function(Func, [true])
enddef
Foo()

no error

Ah, I guess the error is meant to be raised only when the partial is used; not assigned.  If so, there are still what seems to be 2 issues.  First, why giving an error at the script level, on the assignment?  Why not delay the error until the partial is used (just like in compiled code)?
Second, once we try to use the wrong partial, the error message seem confusing:
vim9script
def Func(b: bool)
enddef
var Partial: func(string)
def Foo()
    Partial = function(Func, [true])
    Partial()
enddef
Foo()

E119: Not enough arguments for function: Partial

First reaction: OK, not enough arguments, so let's try to pass an argument:
vim9script
def Func(b: bool)
enddef
var Partial: func(string)
def Foo()
    Partial = function(Func, [true])
    Partial('')
enddef
Foo()

E118: Too many arguments for function: <80><fd>R1_Func

Now, there are too many arguments.  I don't know which error should be raised, nor at which moment.  On assignment?  When the function in which the partial is assigned is compiled?  When the partial is invoked?

Now, there are too many arguments.

Ah, but that's not for the same function.  "Not enough" is for the partial; "too many" is for the final function.  It's still a bit confusing.

This is not different from the first version:
def Func()
    var Partial: func(bool) = function(Foo, [true])
    Partial()   # error for missing argument to Partial, since it was declared to take a bool argument
    Partial(true)  # error for too many arguments for Foo, since it gets two but expects one
enddef

Ideally there would be an error when Partial is assigned to, but as mentioned that is difficult.

This is not different from the first version:
def Func()
var Partial: func(bool) = function(Foo, [true])
Partial()   # error for missing argument to Partial, since it was declared to take a bool argument
Partial(true)  # error for too many arguments for Foo, since it gets two but expects one
enddef

This example only handles the case of compiled code.  I was talking about an inconsistency between compiled code and script level.
I still think there is an inconsistency, and that this snippet should not give an error:
vim9script
def Func(n: number)
enddef
var Ref: func(string) = function(Func)

E1012: Type mismatch; expected func(string) but got func(number)

Because the same assignment doesn't give any error in compiled code:
vim9script
def Func(n: number)
enddef
def Foo()
    var Ref: func(string) = function(Func)
enddef
Foo()

no error

These snippets gave consistent results until 8.2.3100.  The latter patch introduced a regression which was fixed in 8.2.3104.  From there, the snippets gave consistent results.  Then, another issue was reported which was fixed in the next patch 8.2.3105.  Since then, both snippets give inconsistent results.
Considering that the behavior between script level and compiled code has changed several times, I'm really not sure that the current one is correct.
Besides, I think 8.2.3105 introduced a regression, because its purpose was to fix a different issue.  It was about a wrong type for a partial with argument.  There is no partial in the 2 snippets I've just posted.  There is no reason for 8.2.3105 to have such an effect.

Also, usually, when there is an inconsistency between script level and :def function, it's because of an error at compile time when Vim has less information with regards to the types, than at runtime when Vim has full knowledge of all the types.
Which means that usually, when there is an inconsistency, it's the compiled code which gives an error, while there is no error at the script level.  But here, it's the opposite.  The compiled code doesn't give any error – even when the function is called – while there is an error at the script level.  That doesn't make sense.

Something else looks weird:
vim9script
def Func(n: number)
enddef
def Compiled()
    var Ref: func(string) = function(Func)
enddef
Compiled()

no error

Why isn't there any error?
If we quote the function name, an error is given:
vim9script
def Func(n: number)
enddef
def Compiled()
    var Ref: func(string) = function('Func')
enddef
Compiled()

E1012: Type mismatch; expected func(string) but got func(...): any

Where is it documented that quotes can have such an effect?
There are 4 occurrences for the pattern quote at :help vim9; not one of them explains this effect.

Also, at the script level, the quotes no longer matter.  An error is always given:
vim9script
def Func(n: number)
enddef
var Ref: func(string) = function(Func)

E1012: Type mismatch; expected func(string) but got func(number)

vim9script
def Func(n: number)
enddef
var Ref: func(string) = function('Func')

E1012: Type mismatch; expected func(string) but got func(number)

Why do the quotes matter in compiled code, but not at the script level?

The main problem appears to be that at compile time the type is checked, but this only returns OK or FAIL.  There should be a third value for when assigning "any" to a specific type, which requires a runtime type check.  This doesn't currently happen for a function reference, where the arguments and return type may need to be checked.
I'll make a patch, but it's likely not going to cover all corner cases.  if you find other things that don't work properly yet, please give examples.

I think the patch 8.2.3844 makes the snippets much more consistent.  But there is still something weird:
vim9script
def Func(b: bool)
enddef
def Compiled()
    var Ref: func(number) = function('Func')
enddef
defcompile

E1012: Type mismatch; expected func(number) but got func(...): any

vim9script
def Func(b: bool)
enddef
def Compiled()
    var Ref: func(number) = function(Func)
enddef
defcompile

no error

Both snippets are nearly identical.  The only difference is in the Ref assignment.  In the first snippet, Func is quoted:
var Ref: func(number) = function('Func')
                                 ^    ^

but not in the second one:
var Ref: func(number) = function(Func)

Why does that matter with regards to type checking at compile time?  Is it documented somewhere that omitting quotes can suppress type checking at compile time?
The closest excerpt I can think of is:

Omitting function() ~
A user defined function can be used as a function reference in an expression
without function(). The argument types and return type will then be checked.
The function must already have been defined. >
    var Funcref = MyFunction

When using function() the resulting type is "func", a function with any
number of arguments and any return type (including void).  The function can be
defined later.

But this deals with the possible omission of function().  The previous snippets are about the possible omissions of quotes.

I think the patch 8.2.3844 makes the snippets much more consistent.  But there is still something weird:
vim9script
def Func(b: bool)
enddef
def Compiled()
    var Ref: func(number) = function('Func')
enddef
defcompile

E1012: Type mismatch; expected func(number) but got func(...): any

vim9script
def Func(b: bool)
enddef
def Compiled()
    var Ref: func(number) = function(Func)
enddef
defcompile

no error

Both snippets are nearly identical.  The only difference is in the
Ref assignment.  In the first snippet, Func is quoted:
var Ref: func(number) = function('Func')
                                 ^    ^

but not in the second one:
var Ref: func(number) = function(Func)

Why does that matter with regards to type checking at compile time?
Is it documented somewhere that omitting quotes can suppress type
checking at compile time?

It should not matter.  Also, using funcref() does not make this
difference, while it should be the same.
I think we should allow the assignment and use a runtime type check,
since when using function() or funcref() the returned value cannot be
set by the user, thus we have to allow the "any" type.
--
If your nose runs, and your feet smell, you might be upside down.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

It should not matter.

Here is another example where the quotes matter:
vim9script
def Compiled()
    var Ref = function(Func)
enddef
defcompile
def Func()
enddef

E1001: Variable not found: Func

vim9script
def Compiled()
    var Ref = function('Func')
enddef
defcompile
def Func()
enddef

no error

In both snippets, the same code is run.  The only difference is the Ref assignment:
# snippet 1
var Ref = function(Func)

# snippet 2
var Ref = function('Func')
                   ^    ^

The first snippet uses quotes, but not the second one.  If this is working as intended, maybe we should add something about this pitfall in the Omitting function() section.  The latter says:

When using function() the resulting type is "func", a function with any
number of arguments and any return type.  The function can be defined later.

That's true in the second snippet, but not in the first one.  So, maybe we should say that the function name must be quoted.

I'll add a note that when using function() quotes need to be used if the function doesn't exist yet.


Unicode normalization of content

What are the results of this discussion?
The character position within a Unicode string depends on whether the string is normalized and which Unicode normalization form is used. atjson should specify to normalize content strings to avoid character position mismatch and to ensure same content results in same character sequence.

When are two content strings assumed to be equivalent? Does atjson recommend or require Unicode normalization form and which?
I recommend NFC (Normalization Form Canonical Composition).

atjson currently uses UTF-16 code points per the ecmascript String type, so unicode-equivalent texts that use different unicode normalization (or unnormalized texts) are treated as entirely separate documents.
There are a couple of different possible ways to address this, but in practice, as long as text editors or tools using atjson do not normalize the content (or do so only using the insertText and deleteText methods), the system is internally consistent and specifying behaviour for this is unnecessary.
For an interchange format where the underlying text might be subject to modification independently from the annotations, or environments where it's necessary or desirable to normalize the unicode content string without using the atjson interface (I'm not sure I can think of a realistic example, but happy for suggestions!), one possible approach would be to add a new contentMimeType document attribute (or similar). This could be used to specify the mime-type of the content (and give a path to automatic handling of normalization, string offset behaviours, etc). One challenge with this approach is that while it's possible to specify a charset in addition to text/plain (e.g. "text/plain; charset=UTF-16") per RFC2231, I'm not aware of any standardized way to specify unicode normalization in a content type (my understanding is that charset in mime types must be one of the IANA registered types, none of which include normalization approaches)
That all said, so long as software that modifies an atjson document ensures that (1) the offsets align to UTF-16 code points per the ecmascript definition of strings and (2) any changes, e.g. unicode normalization, correctly update the offsets to account for any added or removed code points, then any other software operating on an atjson document would be able to correctly interpret and modify that document itself.
In practical terms, the insertion or removal of a single code point via a normalization process would simply increase or reduce by one all annotation offsets greater than the insertion offset.
The more complex case of normalization of a document with annotations that refer to code points within a composed character (i.e., grapheme) that is modified by normalization is an edge case that might warrant consideration, though we haven't yet encountered that use-case. My hunch is that any annotations that have start/end offsets within a unicode grapheme (i.e., not aligned to the start or end of the grapheme) would be unicode-specific annotations and as such could use the custom text insertion/deletion behaviours in order to implement the correct behaviour.


Add DCGAN example

This PR will close issue #1776, as it adds an example on how to train a DCGAN that generates MNIST digits.
The generator will be able to generate good-looking images after around 20'000 training iterations.
I've also tried it with the Fashion MNIST dataset, and it converges much faster (only 3'000 iterations) and it can be run with no code changes.

I have noticed a "small" issue. The generator sometimes does not converge, so I fixed the pseudo-random generator seed. Then I got convergence after 5'000 steps instead of 20'000+.
However I did:
touch dnn_dcgan_train_ex.cpp

and then rebuild the program and then it didn't converge.
I repeated the processes about 4 or 5 times until I got convergence again. Is there any way to make the whole program deterministic?.

I've noticed that randomize_parameters in the network initialization makes a call to std::rand, so I've set a seed to std::srand. But it does not make a big difference. I might be missing some random thing elsewhere.

This is super cool.
There isn't a reliable way to make things deterministic as what happens is dependent on build settings and the particular order that CUDA atomic adds happen (since floating point addition is non-commutative).
In general I don't think this kind of non-determinism is a big deal.  Like you don't want it in unit tests, since it makes automated testing frustrating in some cases.  But the underlying issue is that training is unstable, and finding the magic setting/seed/what-have-you that makes it work in that one case just hides it, which is not great.  The non-determinism exposes this, which adds a silver lining to the non-determinism.
Anyway, you might be able to make it more stable by not using assign_image_scaled().  Even if it's still unstable this is still super cool.  DNN training and GANs in particular are known to be hard to train, so sometimes it just is what it is.

Thank you so much for your kind words and advice! I really want to be like you when I grow up :P
Aside from the assign_image_scaled, which seemed to help a little, I've also made sure all floating point values have an explicit type, so that the compiler does not implicitly cast between float and double.
After this change, I've compiled and run the example many times, and it converged every time after a few thousand iterations.

I don't know why this is failing on Windows, now. Among others, it doesn't recognize the operator not, which is built into the language. It was working on the previous commit, and the only thing I changed was the leaky_relu documentation (inside of a comment).

I don't know why this is failing on Windows, now. Among others, it doesn't recognize the operator not, which is built into the language. It was working on the previous commit, and the only thing I changed was the leaky_relu documentation (inside of a comment).

Yeah, visual studio has never been a bastion of standards compliance.  I'm kinda surprised it doesn't know what not is though.  But even so, no one uses not, the idiomatic thing to do in C++ is to use !.

Thanks for spending time giving me quality feedback! I really appreciate it.
In case somebody is wondering why I don't use the built-in sync mechanism of the dnn_trainer: when the loss increases, it will try to reload from a previous state.
I have a couple of questions:

since training is much more stable, maybe we can reduce the number of steps to 30000? I don't know of a good way to stop the training: it's hard to tell from the loss values (which look way nicer after the removal of the htan), since both networks are improving and the same loss value at different training steps has different meanings.
I have noticed that the GPU memory usage varies between 496 and 582 MiB. Is there something we can do about it?

No problem.
I think it's fine to keep it at 50000, but whatever you want to set it to is fine.  The point of the example is to educate, it doesn't have to be a perfect tool for making a dcgan.  The main thing it does is display the images and losses when it's running.  If the main loop was a while(true) loop it would still serve its purpose of being educational and showing this all working.
That memory fluctuation is happening because there are some resizable_tensor variables inside the main loop that get created and destroyed over and over.  There are also two cases where you do const resizable_tensor& thing = ... which also make a copy, since those expressions are binding to a tensor, not a resizable_tensor. So a copy is created.  Finally, there is this device_global_buffer() idiom inside the conv layers.  Those layers need to allocate scratch buffers, and to not waste memory all instances of conv in a thread share the same global scratch buffer.  Normally this is fine, but what happens is the trainer runs the network in thread A, you then in main() run the network in thread B (the main thread), the conv layers see this happen, and they discard their handles to the device global scratch buffer for thread A.  Importantly, they all discard their handles, causing thread A's global scratch buffer to be deallocated.  But then the trainer runs it all again in thread A and it's reallocated again.
I don't think this reallocation is a huge deal.  But you could just not use the trainer.  Maybe the example would end up being simpler since you wouldn't have to reason about the whole "trainer.get_net() to pause the threads" thing.  Anyway, whatever you think makes the example easiest to read and understand is best here, since this reallocation is really inconsequential.

Again, thank you very much for your explanation. I've decided to leave the number of iterations as it is.
I think also showing how to train both networks manually can be useful, since no other example does it. The training code is much more consistent between the discriminator and the generator: we can see exactly where they differ: compute_loss(fake_samples_tensor, real_labels.begin()).
Also, after this change, the memory usage does not fluctuate any more: it stays constant at 486 MiB and the GPU usage has also increased a little bit (from 96% to 97-98%).
Thank you so much for adding this deep learning API to dlib, it is really a joy to use!
As a side note, now that this example is complete, here's a comparison between this implementation and the PyTorch one, which was used as a guide.

Toolkit
GPU
VRAM
CPU
RAM

dlib
98%
486 MiB
100%
838 MiB

PyTorch
92%
721 MiB
100%
1767 MiB

No problem, and thanks for another cool PR :)

All the .subnet() calls were bothering me so I just pushed some of these methods into the loss layer as well and updated the example.  This way user interactions with the network are a little more straightforward.

Oh, perfect!

I was thinking about using 2 running_stats objects to track the losses of the discriminator and the generator:
running_stats<double> g_loss, d_loss;

And then compute the losses as:
d_loss.add(discriminator.compute_loss(real_samples_tensor, real_labels.begin());
// ...
d_loss.add(discriminator.compute_loss(fake_samples_tensor, fake_labels.begin());
// ...
g_loss.add(discriminator.compute_loss(fake_samples_tensor, real_labels.begin());

Then, display d_loss.mean() (or d_loss.mean() * 2) and g_loss.mean(), and clear the stats after each check point. I think it's more representative of what's happening than displaying the raw loss at a particular point. What do you think?


/bl and /m causes build to hang on complex project

Steps to reproduce
Repro project: (MS Internal, do not share externally) \wolfgang\public\msbuild\repro
Command line
build.cmd

Only occurs when running with both /bl and /m (enabled inside build.cmd). Removing /bl or setting /m:1 allows the build to succeed as expected.
A heap dump of the stuck build process is available here: (MS Internal) \wolfgang\public\msbuild\dotnet.dmp
Expected  behavior
Build completes successfully
Actual behavior
Build hangs at random points, seems to be stuck in https://github.com/Microsoft/msbuild/blob/d83a9eda20970d2bfa3ad96d47cbecf93343256b/src/Build/BackEnd/Components/Logging/LoggingService.cs#L1073 waiting on a full queue.
Environment data
msbuild /version output:
Microsoft (R) Build Engine version <IP_ADDRESS>627 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
<IP_ADDRESS>627
OS info:
Windows 10 1709
If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc):
Dotnet SDK 2.1.0-preview1-007063

The hang also reproduces if you use a diag text logger:

set environment variable MSBUILDTARGETOUTPUTLOGGING=1
set environment variable MSBUILDLOGIMPORTS=1
/m /flp:v=diag

Is there any additional information on this issue?
e.g. what triggers the "complex" project?


add a new line symbol and tab symbol (\n, \t)

Can the package work with those symbols?

Currently, new line (\n) causes the input to be accepted and tab (\t) causes focus to move to other elements on the page (the default behavior for HTML inputs). If we add support for new line and tab, we'd have to change this current behavior. What is your use case for \n and \t?

Thank you for the quick response @jonmbake
The main idea is that we get from API a response that is usually viewed on a terminal.
the text contain \n and \t to make it look more readable. When I asked about the symbols, it is more like if it can work as an output like that {text:"hello world\r\n this is a test \t\t"} and the terminal shows tabs and new line and such

From my testing, \n and \t is supported. Here's the test lineData:
const [lineData, setLineData] = useState([
    {type: LineType.Output, value: 'Welcome to the React Terminal UI Demo!'},
    {type: LineType.Output, value: "hello world\r\n this is a test \t\ttext after tab."},
  ]);

, which renders:

In https://github.com/jonmbake/react-terminal-ui/issues/23, we'll add support for rendering arbitrary HTML, which will add more flexibility in what can get rendered. E.g. you could render multiple paragraph (p) elements instead of \n.

Sounds great!
Looking forward to it!
and thank you for the help.


Read search items from cache if possible

If possible, use the cached information on pages and posts instead of reading the file again
Solution:

Use the caching classes

Implemented.
If the content is in cache, the cache is used.  But the search itself will not make the content cache itself.


Please invite me to the community

Name
Shubham mourya
Additional Context
I contribute to open-source projects, and I would like to join.

Invitation sent to join the GitHub Organization. Welcome to Infraform 🎉Please check your mail to accept the invitation sent by GitHub! 🤖About usInfraform is a remarkable open-source solution tailored for serverless platforms, aimed at empowering creators to craft their infrastructure solutions. 💻 We're thrilled to welcome you into our vibrant community! ✨ We eagerly anticipate your valuable contributions! 🤓 Don't forget to explore our community on Github and connect with us on LinkedIn 💜 Feel free to spread the word about our community to like-minded individuals interested in development, DevOps, technology, and collaborative contributions. 👉💜👈


Provide a preview of last aquired capture direct via zmq stream

Current solution relies be based on writing of a temporary file on a disk. The better one should read the data direct from RAM via zmq. Await further instructions in the github repo issue https://github.com/slsdetectorgroup/slsDetectorPackage/issues/337#issue-1077805722

does the zmq approach allow for easliy generating an average image?
I mean, in Tango we cannot handle all image files generated, there must be at least a sub-layer generating an average/sum image

Are there any bad consequences to do something like that:
@command
def get_last_aquired():
    data = np.array(zmq_stream)
    return np.sum(data)

I suppose that such a krasser powerfull PC with a big amount of RAM won't stuck or crash on invoke of this operation.

there is an additional information provided in a personal email as a response to my previously opened issue in github:
Here is a short example that we can use as a basis for discussion and further development.
https://gist.github.com/erikfrojdh/d96b8400eddbc483292de22a4c93587d
It uses the slsdet python package and pyzmq to connect to the receiver zmq stream and read one frame.


MM-44334: export styled components

Summary
Plugins shouldn't have to import a duplicate copy of the styled components library. This will help avoid this warning:

Ticket Link
Fixes: https://mattermost.atlassian.net/browse/MM-44334
Release Note
NONE

@hmhealey Would this maybe be a good opportunity to try out Module Federation?

Yeah, I'd say that's probably fine. I want to hold off on sharing most new dependencies with plugins until we have module federation in place, but since multiple instances of styled-components sound like they'll cause problems, I think we can continue going forward with this one as long as this isn't going to cause issues with @crspeller's common components stuff.

Have we hit a real problem here or is it just the warning?

Only a warning at this point. This is part of a campaign of mine to make it possible to read the console without spam :p


@internal on constructor does not work

Inspired by https://stackoverflow.com/q/52570628 .

TypeScript Version:  master (e1a4c2779f93c8389d1589e543920a61771e97ec)

Search Terms: internal constructor stripInternal
Code: Compile with --declaration --stripInternal.
class Foo {
  /** @internal */
  constructor() {}
}

Expected behavior: Compile error that this isn't supported, or the generated declaration file has a private constructor.
Actual behavior: No compile errors and the generated declaration file has no explicit constructor, which leaves an implicit public constructor, which is clearly contrary to the user's intent.
Playground Link: N/A, declaration file generation
Related Issues: none found

A private constructor would be wrong because we'd then generate an incorrect file when there's a derived class:
declare class A {
    private constructor();
}

// Error
declare class B extends A {

}

internal is really use-at-your-own-risk and we should undocument it

Hello! I created PR to fix this in documentation: https://github.com/Microsoft/TypeScript-Handbook/pull/856

Is there no chance for you to support this?

@RyanCavanaugh Are there any plans to remove stripInternal or document it differently? Wondering if we can rely on it in the future.


Not able to build the plugin in Unreal 5.3.2 in Visual Studio 2022

Severity	Code	Description	Project	File	Line	Suppression State Error	C2614	'RenderBufferRHIImpl': illegal member initialization: 'lite_rtti_override' is not a base or member	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	289	 Error	C3861	'flags': identifier not found	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	310	 Error	C2660	'FRHICommandList::DrawIndexedPrimitive': function does not take 6 arguments	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	1651	 Error	C2065	'GRHISupportsRasterOrderViews': undeclared identifier	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	187	 Error	C2504	'LITE_RTTI_OVERRIDE': base class undefined	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.hpp	114	 Error	C2039	'LITE_RTTI_OVERRIDE': is not a member of 'rive'	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.hpp	114	 Error	C3668	'RenderBufferRHIImpl::onMap': method with override specifier 'override' did not override any base class methods	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.hpp	124	 Error	C3668	'RenderBufferRHIImpl::onUnmap': method with override specifier 'override' did not override any base class methods	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.hpp	125	 Error	C2440	'return': cannot convert from 'rive::rcp<RenderBufferRHIImpl>' to 'rive::rcp<rive::RenderBuffer>'	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	941	 Error	C3861	'sizeInBytes': identifier not found	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	315	 Error	C2039	'sizeInBytes': is not a member of 'RenderBufferRHIImpl'	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	1654	 Error	C3861	'SwizzleRiveColorToRGBAPremul': identifier not found	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	1288	 Error	C2039	'SwizzleRiveColorToRGBAPremul': is not a member of 'rive::gpu'	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.cpp	1288	 Error	C2143	syntax error: missing ',' before '('	RiveTest	D:\Unreal Projects2\RiveTest\Plugins\rive-unreal-main\Source\RiveRenderer\Private\Platform\RenderContextRHIImpl.hpp	114	 Error	MSB3073	The command ""C:\Program Files\Epic Games\UE_5.3\Engine\Build\BatchFiles\Rebuild.bat" RiveTestEditor Win64 Development -Project="D:\Unreal Projects2\RiveTest\RiveTest.uproject" -WaitMutex -FromMsBuild" exited with code -1.	RiveTest	C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.MakeFile.Targets	50

What version of the Rive plugin are you using?
This looks like a potential version mismatch in the files. Are you trying to upgrade an older version of the plugin? Or is this a new install? If you're upgrading, be sure to completely delete the older plugin before copying in the newer.

I am trying to 0.2.2 version and this is my new install

The plugin should be automatically when you run the Unreal Editor. Where are you getting the output you've pasted?

I am getting this  in Visual studio 2022  when I tried to build a C++ project that I created using Unreal Engine 5.4

Did you see the plugin build when you started unreal?

Ok, we're working on a new release that, if you can, would probably make sense for you to wait for. Let me know if this is more time critical and we can continue working through the issue you're seeing.

We've released 0.2.3. Please try that release.

Hello Tod, Thank you for you help. I tried the latest version and now I am able to enable the plugin and open the project

Glad it worked! Sorry for the trouble.


TRT-1827: Revert "Synchronize From Upstream Repositories"

Reverts  #65, #63; tracked by TRT-1827
Per OpenShift policy, we are reverting this breaking change to get CI and/or nightly payloads flowing again.
#65 broke techpreview installs (this did show up in presubmits, and was overridden).  #63 is reverted to resolve conflicts when trying to revert #65.
To unrevert this, revert this PR, and layer an additional separate commit on top that addresses the problem. Before merging the unrevert, please run these jobs on the PR and check the result of these jobs to confirm the fix has corrected the problem:
Ensure techpreview installs succeed
CC: @tmshort, @joelanford

Techpreview install succeeded here: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/openshift-operator-framework-catalogd-67-ci-4.18-e2e-aws-ovn-techpreview/1838175085748293632
INFO[2024-09-23T12:03:25Z] Step e2e-aws-ovn-techpreview-ipi-install-install succeeded after 40m44s.

/label approved

/override ci/prow/openshift-e2e-aws-techpreview
Expediting revert, we already got signal on the payload job installs are working


Expand the size in the tombstone correction.

Motivation
The tombstone mechanism in ScyllaDb is limited to 10000 tombstones by default.
This PR extends it to 200000.
Proposal
The following was done:

Add to the store_test.rs a test that triggers the error with the default settings of ScyllaDB.
Add the creation of a modified ScyllaDB image (which is very fast).
Modify the CI accordingly.

Test Plan
The CI should do it.
Release Plan
More work is needed for the Kubernetes.
Links

reviewer checklist

One idea: The Kubernetes tests are run with ScyllaDB, and are closer to a production environment. Do the e2e tests have the same coverage as the ScyllaDB tests? I'm guessing they don't, but wanted to check.
If they do, we could just add modif_scylla.yaml to the Helm deployment, and the kubernetes test would cover things. Then we wouldn't need this new Dockerfile or the CI changes

One idea: The Kubernetes tests are run with ScyllaDB, and are closer to a production environment. Do the e2e tests have the same coverage as the ScyllaDB tests? I'm guessing they don't, but wanted to check. If they do, we could just add modif_scylla.yaml to the Helm deployment, and the kubernetes test would cover things. Then we wouldn't need this new Dockerfile or the CI changes

If you have a way to enable the scylla.yaml with that corrected file I would be happy to use it.
However, the tombstone problem is not triggered by the e2e test, it is triggered by the scylla_db_tombstone_triggering_test which as far as I know is not part of the e2e tests.


Plugin should use local mvnw

Actual behavior (Required!)
maven.vim checking executable('mvn') and use 'mvn' command.
Expected behavior (Required!)
maven.vim should use local mvnw file because not everyone can install maven globally.
$project_dir . './mvnw' should be used instead of 'mvn' everywhere.
The steps to reproduce actual behavior (Required!)

... I started spring with https://start.spring.io/ and i did not install maven globally
... imports did not resolve.
... I started reviewing the code :)

Environment (Required!)

OS: Arch Linux
Vim version: 8.2

Good point. If you can PR welcome. Or I will do it a bit later.

i can PR, but i'am new vim script and i don't know your code structure exactly. It's better if you do.

Ok, but you need to wait some time. I'm not able to do it right now.
On 02-25 (02:08), murat akbulut wrote:

i can PR, but i'am new vim script and i don't know your code structure
exactly. It's better if you do.
—
You are receiving this because you commented.
Reply to this email directly, [1]view it on GitHub, or [2]unsubscribe.
References
Visible links

https://github.com/artur-shaik/vim-javacomplete2/issues/434?email_source=notifications&email_token=ABFDHO6SBWBAETE4BO62AH3RETU2BA5CNFSM4KZ5VS52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM3LGQY#issuecomment-590787395
https://github.com/notifications/unsubscribe-auth/ABFDHO6VKVF5AYBUAOT334DRETU2BANCNFSM4KZ5VS5Q

--
Best regards,
Artur Shaikhullin

@MrAkblt This has been done in #464, can you test it?

@wsdjeg Hi, I don't have the necessary development tools as I haven't used java and javacomplete for a long time. Sorry for not being able to help.

Consider switch to jc.nvim


Add cpu argument to Dataset API

Addresses the first two items in #534
This PR introduces the cpu argument to the Dataset API (and to the DatasetEngine backends).  It also introduces the to_cpu and to_gpu methods.  Note that none of the operators (nor Dataset.to_parquet) support a pandas-backed partition at the moment, so any use of cpu=True or to_cpu() will result in a user warning.  Overall, this is just the first step towards a "CPU version" of NVTabular.

rerun tests


BTCPay: Worth It?

Seen here https://docs.btcpayserver.org/Deployment/ManualDeploymentExtended
it's inherently risky to setup Btcpay manually, especially for newbies. It's also an extremely long winded process to install.
Deploying with docker (especially for personal use) is a huge anti-pattern and also not consistent with other tutorials.
However, I think there's a high demand for business-oriented payment processing using crypto. Btcpay can allow a small business to get paid and not have to deal with customer's credit card / debit card / bank account / personal info, while also not submitting to custodial exchanges nor fiat payment processor policies. Plus it has a Monero integration.
Does anyone think Btcpay would be a good tutorial to be considered? Would including docker be an acceptable exception?

I think I had written somewhere that I would be okay with a BTC tutorial using Docker (thus making an exception), but honestly, I'm not sure at this point. I'd like a guide for it, but it should be the non-Docker deployment.
I had run a BTCPay instance with Docker, and I will flatly say it was sheer frustration because the extra layer of Docker made what would otherwise be simple fixes extremely painful to put in order.
Honestly, yeah they say you should run it via Docker for "ease" and "security", but you have to remember they're talking to a different audience than this site is. They are talking about Windows-normies who think BTC is cool, whereas the audience of this site is more sysadmins or wannabe-sysadmins who already have Linux experience.
I wouldn't worry too much about the "length" of installation either. There are a lot of these guides where steps can easily be combined or summed up in one pastable line.


Documentation for System.Reflection.Metadata (package version 1.5.0) has gone missing

There appears to be a XML doc problem with System.Reflection.Metadata, version 1.5.0. Despite being quite thoroughly documented in the original source code, most or all of that documentation appears to get lost on its way to VS IntelliSense and the online .NET API Browser.
I checked some of the XML documentation files in the NuGet package that sits in my local NuGet package cache at C:\Users\stakx\.nuget\packages\system.reflection.metadata\1.5.0\lib\netstandard2.0\System.Reflection.Metadata.xml—it contains the markup skeleton but no actual documentation text.

Thanks @stakx! What happens is that the IntelliSense is generated from what is in the https://github.com/dotnet/dotnet-api-docs repo, not the source code. In the future, we'll be able to do a one-time import for new classes of the /// comments. So, right now, we'll have to manually import the content from the source into our docs.

@mairaw: What is the status on importing missing reference docs? Is there anything that the community (e.g., me) can do to help? I'd like to see this one resolved.


apps: charts to ghcr

[!warning]
This is public repository, ensure not to disclose:

[x] personal data beyond what is necessary for interacting with this pull request
[x] business confidential information, such as customer names

What kind of PR is this?
Required: Mark one of the following that is applicable:

[x] kind/feature
[ ] kind/improvement
[ ] kind/deprecation
[ ] kind/documentation
[ ] kind/clean-up
[ ] kind/bug
[ ] kind/other

Optional: Mark one or more of the following that are applicable:

[!important]
Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

[ ] kind/admin-change
[ ] kind/dev-change
[ ] kind/security
[ ] kind/adr

What does this PR do / why do we need this PR?

...

Fixes #1805

Additional information to reviewers
Screenshots
Checklist

[x] Proper commit message prefix on all commits

Change checks:

[x] The change is transparent
[ ] The change is disruptive
[ ] The change requires no migration steps
[ ] The change requires migration steps

Metrics checks:

[x] The metrics are still exposed and present in Grafana after the change
[ ] The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
[ ] The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)

Logs checks:

[x] The logs do not show any errors after the change

Network Policy checks:

[x] Any changed pod is covered by Network Policies
[ ] The change does not cause any dropped packages in the NetworkPolicy Dashboard

Pod Security Policy checks:

[x] Any changed pod is covered by Pod Security Admission
[ ] Any changed pod is covered by Gatekeeper Pod Security Policies
[ ] The change does not cause any pods to be blocked by Pod Security Admission or Policies

Falco checks:

[x] The change does not cause any alerts to be generated by Falco

Audit checks:

[x] The change does not cause any unnecessary Kubernetes audit events
[ ] The change requires changes to Kubernetes audit policy

Bug checks:

[x] The bug fix is covered by regression tests

I even get chart signing? 😄
We should document this, how to consume the charts, and how to verify the charts.
Additionally we should enforce a versioning policy of the charts.
But maybe I should work on that policy in a separate PR, as we also need to do that in some clever way for images as well.

Yep! Signing it is!


Update FEniCS training notebook

closes #93

@chaozg , I appreciate it if you can review this PR. Many thanks!

Hi @amal-ghamdi, this notebook looks excellent. I've only left some minor comments with some additional ones, again very minor:

Maybe we can give the full name of pCN or a link to CUQIpy's api page on pCN, just after section 2.8, in case people don't know what it is?
Regarding boundary conditions, u(0,ξ2)=0onξ1=0 seems redundant, I mean u(0,ξ2)=0 already implies ξ1=0. What do you think? Maybe u(ξ)=0onξ1=0 is enough?

Very good point about the BC.
Thank you very much @chaozg for your helpful comments to improve the consistency and conciseness of the notebook. I incoropareted your suggestions :).


using Capital N

this doesn't work for me with minkube when using namespace with lower "n"
minikube version: v0.27.0
kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-05-12T04:12:12Z", GoVersion:"go1.9.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

This should be merged.  Capitalizing Namespace fixes this error:
Error from server (BadRequest): error when creating "myns.yaml": namespace in version "v1" cannot be handled as a Namespace: no kind "namespace" is registered for version "v1" in scheme "k8s.io/kubernetes/pkg/api/legacyscheme/scheme.go:29"

Thanks a lot and terrible sorry for the delay here, not sure why this one fell between the cracks!

Thank you.
:relaxed:


Build CoreRT binaries within Visual Studio 17/19

When I want to compile my project to CoreRT native binaries I have to use the command line:
dotnet publish -c Release -r win-x64
How can I compile native builds when using "Build" operation in Visual Studio?
I tried this StackOverflow answer (https://stackoverflow.com/questions/54542158/c-sharp-compile-net-core-3-0-to-native-code-through-visual-studio-2019#comment95894438_54542158) but I end up in an endless loop of builds (one build finishes and the next one starts).

This is duplicate of bug https://github.com/dotnet/corert/issues/6773. The problem is that the CoreRT build task does not work  with .NET Framework msbuild currently.

@jkotas
I ended up with following post-build event:
if not exist building (
  type nul > building
  dotnet publish -c Release -r win-x64
  del building
)

After a "normal" build it creates the empty file "building" and compiles to native code.
By checking for existence of this file it will not enter the endless building loop.
After successfull native compiling it deletes file "building".
Is there an ETA when the CoreRT build task will work with msbuild?

I expect that it will take a while (months) before somebody gets to it.
The problem with the CoreRT build task is that it is not packaged correctly. We are overdue for updating the CoreRT build infrastructure to be in sync with other .NET Core projects that comes with different packaging system. We will want to do the build infrastructure update first.


proc_stat_test.go: architecture dependent MinInt and MaxInt constants

to avoid math.MinInt64 and math.MaxInt64 overflowing int type
when running TestProcStatLimits on 32bit architectures:
./proc_stat_test.go:97:49: cannot use math.MinInt64 (untyped int constant -9223372036854775808) as int value in struct literal (overflows)
./proc_stat_test.go:98:51: cannot use math.MaxInt64 (untyped int constant<PHONE_NUMBER>854775807) as int value in struct literal (overflows)

Fixes: #432
Signed-off-by: Tim Rots<EMAIL_ADDRESS>

Hrmm how is this working with the fixture having the same values on all archs?

I clearly didn't understand the issue. Sorry for this


"Could not wire ResourceServerTokenServices" error

We have been using 2.0.4.SNAPSHOT version, but since we upgraded to 2.0.5-RELEASE we are receiving this error:
Could not wire ResourceServerTokenServices: please create a bean definition and mark it as @Primary.

Debugging, I found that the exception was caused by:
org.springframework.beans.factory.NoUniqueBeanDefinitionException:
No qualifying bean of type [org.springframework.security.oauth2.provider.token.ResourceServerTokenServices] is defined:
expected single matching bean but found 2:
consumerTokenServices,
defaultAuthorizationServerTokenServices

(code added on commit 45505c6ab815a8c282d6f566eb65a9b5da676f26)

I agree it is not ideal yet, but the various token services might not always be the same instance of DefaultTokenServices. You can easily get the one you need by using a @Qualilfier (that's what I have been doing while I think about a better way of exposing them in the framework).

Hello,
I am also facing the same issue here.
The problem is that when I use spring OAuth 2.0.5.Release along with spring-orm. And have @EnableGlobalMethodSecurity(prePostEnabled = true, proxyTargetClass = true) as a configuration.
The test to load the application context fails. The application works fine when I Run it. Only the tests fail.
After Debugging I figured out the problem was with this part of the code
private ResourceServerTokenServices resolveTokenServices() {
		if (tokenServices == null || tokenServices.length == 0) {
			return null;
		}
		if (tokenServices.length == 1) {
			return tokenServices[0];
		}
		if (tokenServices.length == 2 && tokenServices[0] == tokenServices[1]) {
			return tokenServices[0];
		}
		try {
			TokenServicesConfiguration bean = context.getAutowireCapableBeanFactory().createBean(
					TokenServicesConfiguration.class);
			return bean.services;
		}
		catch (BeanCreationException e) {
			throw new IllegalStateException(
					"Could not wire ResourceServerTokenServices: please create a bean definition and mark it as @Primary.");
		}
	}

the condition
if (tokenServices.length == 2 && tokenServices[0] == tokenServices[1]) {
fails because the tokenservices array contains two beans which are proxied by Cglib and do not equate.
I have created a test project on which the tests fail. It is a fork of the sparklr-boot project.
https://github.com/gauravlanjekar/sparklr-boot
@dsyer  I would really appreciate any help on this. Or a even a work around :)
Thanks in advance

@gauravlanjekar that last change fixes your app, but possibly not the original problem (if not please open another ticket).

I've had the exact same issue with @EnableTransactionManagement. I end up with [1]	DefaultTokenServices  (id=97) and [0]	DefaultTokenServices$$EnhancerBySpringCGLIB$$765d443b  (id=161). When removing the annotation, I end up with two beans but that are indeed equal. I have not found a solution to that problem yet. The two following lines create the two beans:
@Bean
	public ConsumerTokenServices consumerTokenServices() throws Exception {
		return getEndpointsConfigurer().getConsumerTokenServices();
	}

	/**
	 * This needs to be a @Bean so that it can be @Transactional (in case the token store
	 * supports them). If you are overriding the token services in an {@link AuthorizationServerConfigurer} consider
	 * making it a @Bean for the same reason (assuming you need transactions, e.g. for a JDBC token store).
	 *
	 * @return an AuthorizationServerTokenServices
	 */
	@Bean
	public AuthorizationServerTokenServices defaultAuthorizationServerTokenServices() {
		return endpoints.getDefaultAuthorizationServerTokenServices();
	}

It's strange because I'm not overriding the tokenservices so only one is created through the createDefaultTokenServices() method and I verified that the consumerTokenServices() and getDefaultAuthorizationServerTokenServices() return the same object but then only one of the bean is proxied, how is that?
I'm using 2.0.6.

same problem, though we have 3... (2.0.15), because we're defining our own. fixed it by overriding the bean name of one that it was looking for.
private static final String TOKEN_SERVICES = "defaultAuthorizationServerTokenServices";

@Bean(TOKEN_SERVICES)
DefaultTokenServices tokenServices( final DataSource dataSource ) {
    DefaultTokenServices tokenServices = new DefaultTokenServices();
    tokenServices.setTokenStore( tokenStore( dataSource ) );
    tokenServices.setTokenEnhancer( tokenEnhancer() );
    tokenServices.setClientDetailsService( clientDetails( dataSource ) );
    tokenServices.setSupportRefreshToken( true );
    return tokenServices;
}


Add Prophet algorithm in augurs-prophet crate

This PR adds an implementation of the Prophet forecasting model. It handles:

definitions of types for input and output data
transformation of data into something suitable for an optimizer
generation of predictions using optimized model parameters obtained from an optimizer
calculation of uncertainty intervals by sampling using those parameters

The Optimizer trait (for which there are no implementations, yet) allows the model to work without any a dependency on any specific optimizer. The Python and R libraries have (in the past) offered bindings using Stan libraries and the cmdstan interface; the cmdstan is the only one now supported. A similar interface could be added here with relative ease.

Summary by CodeRabbit

New Features

Introduced a new bacon.toml configuration file for enhanced task management in Rust projects.
Added multiple new dependencies to the project, including augurs-prophet, chrono, num-traits, rand, and pretty_assertions.
Implemented the Prophet forecasting model with various configuration options and prediction capabilities.
Introduced functionality for loading and processing time series data from CSV files.
Added a new section in the README.md detailing the augurs-prophet package and its development requirements.
Included Apache and MIT license files to the project.
Added a new FeatureMode, Holiday, and Seasonality structures for enhanced model configuration.

Bug Fixes

Updated dependency management for rand to use workspace specifications.

Documentation

Added a detailed README.md for the augurs-prophet package explaining its functionality and usage.
Included documentation for new features and options in the Prophet model.

Tests

Included unit tests for various functionalities within the Prophet model and its components.

Chores

Updated .gitignore to exclude .bacon-locations.
Added a watch target in the justfile for monitoring project changes.

@coderabbitai resolve

@coderabbit full review

@coderabbitai full review


Incorrect behavior of the application on Raspberry pi 4

Software Versions

Python: 3.9.0
OS: Raspbian GNU/Linux 10 (on rpi 11 all fine)
Kivy: 2.1.0
Kivy installation method: pip

There is a problem with kivy under raspberry pi 4, if I start scrolling with the mouse wheel outside the window with the application, then the scrolling still works, as well as clicking, the clicks themselves can occur in different places.
from kivy.app import App
from kivy.uix.button import Button
from kivy.lang import Builder

KV = '''
<CustomBtn>
    size_hint_y: None
    height: dp(50)

Screen:
    ScrollView:
        BoxLayout:
            id: container
            orientation: 'vertical'
            size_hint_y: None
            height: self.minimum_height
'''

class CustomBtn(Button):
    pass

class TestApp(App):
    def build(self):
        return Builder.load_string(KV)

    def on_start(self):
        for i in range(50):
            self.root.ids.container.add_widget(CustomBtn(text=str(i)))

TestApp().run()

(venv) pi@raspberrypi4:~/Desktop/Python $ ~/env/bin/python kivy_test.py
[INFO   ] [Logger      ] Record log in /home/pi/.kivy/logs/kivy_22-09-14_12.txt
[INFO   ] [Kivy        ] v2.1.0
[INFO   ] [Kivy        ] Installed at "/home/pi/env/lib/python3.9/site-packages/kivy/__init__.py"
[INFO   ] [Python      ] v3.9.0 (default, Sep 11 2022, 23:59:19)
[GCC 8.3.0]
[INFO   ] [Python      ] Interpreter at "/home/pi/env/bin/python"
[INFO   ] [Logger      ] Purge log fired. Processing...
[INFO   ] [Logger      ] Purge finished!
[INFO   ] [Factory     ] 189 symbols loaded
[INFO   ] [Image       ] Providers: img_tex, img_dds, img_sdl2, img_pil (img_ffpyplayer ignored)
[INFO   ] [Text        ] Provider: sdl2(['text_pango'] ignored)
[INFO   ] [Window      ] Provider: sdl2
[INFO   ] [GL          ] Using the "OpenGL" graphics system
[INFO   ] [GL          ] Backend used <sdl2>
[INFO   ] [GL          ] OpenGL version <b'2.1 Mesa 19.3.2'>
[INFO   ] [GL          ] OpenGL vendor <b'Broadcom'>
[INFO   ] [GL          ] OpenGL renderer <b'V3D 4.2'>
[INFO   ] [GL          ] OpenGL parsed version: 2, 1
[INFO   ] [GL          ] Shading version <b'1.20'>
[INFO   ] [GL          ] Texture max size <4096>
[INFO   ] [GL          ] Texture max units <16>
[INFO   ] [Window      ] auto add sdl2 input provider
[INFO   ] [Window      ] virtual keyboard not allowed, single mode, not docked
[INFO   ] [ProbeSysfs  ] device match: /dev/input/event3
[INFO   ] [HIDInput    ] Read event from </dev/input/event3>
[INFO   ] [ProbeSysfs  ] device match: /dev/input/event1
[INFO   ] [HIDInput    ] Read event from </dev/input/event1>
[INFO   ] [ProbeSysfs  ] device match: /dev/input/event2
[INFO   ] [HIDInput    ] Read event from </dev/input/event2>
[INFO   ] [ProbeSysfs  ] device match: /dev/input/event0
[INFO   ] [HIDInput    ] Read event from </dev/input/event0>
[INFO   ] [Base        ] Start application main loop
[INFO   ] [HIDMotionEvent] using <SIGMACHIP USB Keyboard System Control>
[INFO   ] [HIDMotionEvent] using <SIGMACHIP USB Keyboard>
[INFO   ] [HIDMotionEvent] using <SIGMACHIP USB Keyboard Consumer Control>
[INFO   ] [HIDMotionEvent] using <PixArt USB Optical Mouse>
[INFO   ] [GL          ] NPOT texture support is available
[INFO   ] [Base        ] Leaving application in progress...
(venv) pi@raspberrypi4:~/Desktop/Python $

https://user-images.githubusercontent.com/40869738/190177838-31d7bceb-2619-4350-b5a4-b88fbd1b05ff.mp4
https://user-images.githubusercontent.com/40869738/190177819-f80cd968-5d00-475f-9062-82d47e77eacf.mp4

I have seen the same thing.
On Raspberry mouse events are reported in Screen coordinates not in Window coordinates.
This is incorrect behavior if the machine is running a windowed OS such as X.

Hi @Neizvestnyj !
Can you please check if you're able to reproduce this issue with latest Kivy version? (we now provide cross-compiled wheels to piwheels)


🪸 Remove feature flag for connector overview and edit

prep branch: 1597-remove-feature-flag-for-connector-overview

Wait for #1756


Accounts instantly get banned

I created an alt, verified the phone number and email, and left all the settings that weren't required on their default values, and ran the dm spam bot. It dmed two people, then the account got banned. Is this because I had the account open in a chrome tab while it was running or is this a known issue that there is an easy fix to?

Getting banned is usually due to sending the same message over again.

also using proxies

Getting banned is usually due to sending the same message over again.

I got banned after only sending one message

Any way to provide a video example?
Has this happened more than once


Backport 2.1: Correctly handle handshake messages in ssl_read if renegotiation is disabled

Summary: This is the backport of #1141 to Mbed TLS 2.1, obtained manually.
Internal Reference: IOTSSL-1707.

CI only failed due to timing tests (known issue), ok to merge pending my review


Allow multiple users to have a pregnancy on their call list #228

I rule and have completed some work on Case Manager that's ready for review!
This pull request makes the following changes:

many to many -ifies user and pregnancy
fix controller test
makes pledge factory valid

It relates to the following issue #s:

Fixes #228

Confirming that this resolves the bug described in #228, where a patient could only be on one person's call list at a time. Thanks much @Kevin-Wei !
I had a few questions / suggestions about a couple of things in the PR (a reload in a view and a change to the pledge factory), but on the whole, looks good to me.
Thanks a ton for taking care of this!

I just run the linter before PR's so as not to submit invalid ones.
as for partial reload. Charles solution looks better. Without the user reload the partial table doesn't toggle the "add" "remove" correctly. since mongo nonsense is hardcore and the block can't detect the changes in the array until the DB is called again. There is probably a much better solution out there somewhere.

Thanks for fixing up the pledge factory, appreciate it.
And thanks for your thoughts on the partial reload. What are yr thoughts about removing the reload from the view and holding out for @charleshuang80 's PR to get merged?

Come to think of it, that's a minor enough change that I think we can just merge and I'll fix manually. Merging now.


Fix keybindings

The keybinding in the source was .atom-text-editor which isn't valid. The valid version of this would be atom-text-editor, since it is an element, not a class (looks like this issue was created by @brunosabot).
However, surely this package's keybinding should apply anywhere in Atom, since gulp watch is not dependent on the current file. The context is the whole project, therefore this PR amends the selector to be global.
Apologies for including the original gulp process path fix PR's commit in this PR - I shouldn't have put that original commit in my master branch! Hopefully that won't be an issue.

How about this one @kenwheeler and publishing to apm?

done, thanks


IntentService -- OutOfMemoryError

Hi,
I'm seeing this error, happening only on Android 8 (Oreo) devices.
Fatal Exception: java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again
       at java.lang.Thread.nativeCreate(Thread.java)
       at java.lang.Thread.start(Thread.java:733)
       at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:970)
       at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1038)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1180)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
       at java.lang.Thread.run(Thread.java:764)

The crash console is showing there are 1177 threads created (doubt this is intentional!). And most of the threads look like this:
IntentService[EventHandlerService]
       at android.os.MessageQueue.nativePollOnce(MessageQueue.java)
       at android.os.MessageQueue.next(MessageQueue.java:325)
       at android.os.Looper.loop(Looper.java:142)
       at android.os.HandlerThread.run(HandlerThread.java:65)

I'm not entirely sure this is an error from the optimizely SDK, but I saw you have this file, so it might be related.
https://github.com/optimizely/android-sdk/blob/992acca918557031e4b1289277cc54976d5f945b/event-handler/src/main/java/com/optimizely/ab/android/event_handler/EventIntentService.java#L53

We are also seeing similar crashes with a slightly different stack trace.
Fatal Exception: java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Out of memory
       at java.lang.Thread.nativeCreate(Thread.java)
       at java.lang.Thread.start(Thread.java:733)
       at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:970)
       at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1377)
       at android.os.AsyncTask.executeOnExecutor(AsyncTask.java:651)
       at com.optimizely.ab.android.shared.ScheduledJobService.onStartJob(ScheduledJobService.java:145)
       at android.app.job.JobService$1.onStartJob(JobService.java:71)
       at android.app.job.JobServiceEngine$JobHandler.handleMessage(JobServiceEngine.java:108)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loop(Looper.java:164)
       at android.app.ActivityThread.main(ActivityThread.java:6494)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)

Thanks for the info.  We hope to have a fix out this week.

@jia-tse-zocdoc when you say Oreo 8, you mean Oreo 8 and above?  correct?

@thomaszurkan-optimizely -- the particular out of memory error I was seeing is only on 8. All 120 users are on Android 8.
However, there is another issue affecting 8 & above: https://github.com/optimizely/android-sdk/issues/269.  I'm not quite sure if it's the same as the issues reported 2 years ago

I have done a couple of things to make sure we don't start multiple event handlers for the same event.  Do you know if you are generating a lot of events? Thousands?  This should be fixed in 3.0.1.  Patch 2.1.5 coming soon.

we have about 15-20 experiments, 15-20 metrics/events all sprinkled throughout the app. I can imagine 100s, but not 1000s. Are you able to look into your server backend and confirm that you're receiving thousands of events from us per user?

@jia-tse-zocdoc I will look into it.  But, that was the feedback I needed.

We're hitting the same issue. We're seeing both ANRs and OOM crashes, where the logs show hundreds of threads called IntentService[EventIntentService]. I'm trying 2.1.4 right now but it looks like the issue is not fixed.
The JobWorkService class seems to recycle an EventIntentService instance. It calls onCreate (https://github.com/optimizely/android-sdk/blob/25757892d0d405d03201d09cc8a7cfd46c67c7be/shared/src/main/java/com/optimizely/ab/android/shared/JobWorkService.java#L106) but never calls onDestroy. Could this be where threads are being leaked?

Seeing this mostly on Android 8 and 9.

@iain-merrick-fanduel thanks for the feedback.  Can you use 3.0.1?  We didn't patch 2.1.4.

I have stopped seeing these errors in the 3.x versions...., 🤞

I believe that this issue is fixed with the latest sdk being 3.2.1


[MRG] JOSS Paper

Branch for submitting HNN-core paper to JOSS.

@jasmainak @rythorpe @stephanie-r-jones here is the branch with the JOSS paper. Still formatting things but let's move any lingering discussion on the text to comments on paper.md

Codecov Report

Merging #653 (0de406f) into master (07374a3) will increase coverage by 0.05%.
The diff coverage is n/a.

:exclamation: Current head 0de406f differs from pull request most recent head fb703df. Consider uploading reports for the commit fb703df to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##           master     #653      +/-   ##
==========================================
+ Coverage   91.88%   91.94%   +0.05%
==========================================
  Files          22       22
  Lines        4375     4370       -5
==========================================
- Hits         4020     4018       -2
+ Misses        355      352       -3

see 4 files with indirect coverage changes

Is there a way to view the compiled PDF?

Okay, I did a fine comb-through and it's looking really good. I found a few very minor typos that need fixing, but besides those, updating the figure, and getting the remaining affiliations, we're ready to go!

@raj1701 any thoughts on why this test is failing?


Qwik 0.0.36 E2E, now uses build/serve

Using the updated Qwik allows the E2E to use the Qwik library output, a closer match to intended downstream use.

I'm pretty sure the fiddle error is unrelated to this pr... hmmm.


[DRAFT] Whole new cfg editor UI

This draft is for whole new cfg editor UI.
ONE-vscode-DCO-1.0-Signed-off-by: Seok NamKoong<EMAIL_ADDRESS>
Related Issues

#698

Before & After

Type
Item
Before
After

UI
Progress bar

UI
Summary

:factory_worker: WIP

UI
Import Step

UI
Optimize Step
:x: NYI

UI
Quantize Step
:x: NYI
:factory_worker: WIP

UI
Codegen Step

UI
Profile Step

New Feature
Sync Changes (Editor -> .cfg)
:x: NYI
:heavy_plus_sign: Changes from editor are applied to cfg file

Bugfix
Sync Changes (.cfg -> Editor)
:lady_beetle: onecc section was not supported
:hammer_and_wrench: onecc section is now supported

This draft is now tool old to apply current main branch.
So let's close this PR and then create new one if needed! :D


fix byte issues

this is similar to the fix we did for ember-eslint-parser
fixes #191
closes #220

Thank you!


New: changes makefile parsing to include commands without a description comment and adds optional alphabetical command list sorting

Description
Changes the parsing of makefiles to include commands without a description comment, allows for optional rendering of command comments as descriptions in the panel (now also shown as hover text), and a new option to sort the command list in the panel alphabetically.  Panel also auto-updates when extension options are changed.  Updated .gitignore to ignore the .vscode-test folder that was generated when I ran npm run test.
I didn't see the contribution guidelines before making the first commit in my fork, but I can use the tag format you described at merge time if we squash the commits I hope?
Example of the panel being sorted and showing the description comments:

Options in vscode:

Related Issue

https://github.com/Akecel/makefiles-runner/issues/1
https://github.com/Akecel/makefiles-runner/issues/17

Motivation and Context
I've wanted these features for a while, and after rediscovering why some of the commands in our makefile weren't showing up in the panel I decided to make the changes and spin up an PR.
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[X] My code follows the code style of this project.
-- I believe it does but if you spot anywhere that doesn't please let me know and I will update.
[X] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.

Tagging you @Akecel so I can get your thoughts on this PR.  Thanks!

Hi @JeremyCaron !
Thanks a lot for all this, I still have to take the time to look and test on my side, but I see that you stayed with what we initially said so really a big thank you.
I'll take a look at it all in January, and keep you posted.

Hi @JeremyCaron ! Thanks a lot for all this, I still have to take the time to look and test on my side, but I see that you stayed with what we initially said so really a big thank you. I'll take a look at it all in January, and keep you posted.

Sounds good, there's one more feature I really need so I'll use the extra time to add it to the MR (an option to always run selected make commands in a new terminal, thus skipping the terminal selection dropdown).  Enjoy the holidays!


INET_ATON and INET_NTOA

I could not find these conversion functions. They take a address and convert it to a integer.
May be handy for storing many ips in a efficient format with ordering or using addresses as a key inside maps.
More infos: http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_inet-aton
May i implement that feature? :)

Hi, yeah for sure!
This isn't a format I'm familiar with, hence the only reason I've not implemented it.
Thanks!

I am working on it.
@bordeltabernacle Is there a preferred form for ip addresses? Like is the string "<IP_ADDRESS>" preferred over the octed {192, 168, 1, 2}.
The address_to_number function i am working can accept both, but what should number_to_address return? I would favor to return a string for number_to_address and add another function like number_to_octet returning a octet.

@bordeltabernacle Have a look at what i did please.

I read that PostgreSQL does not have UnsignedInteger Column Types. There are also some implementations, that use signed integer implementations for this feature: http://php.net/manual/en/function.ip2long.php
The current implementation is returning unsigned integer. I will try to find out how to convert unsigned ints to signed ints in elixir.

This is great, thankyou. A couple of things;
So, as it is at the moment I've tried to have it so that each conversion function doesn't mind in what form it takes the ip address/subnet mask and will take dotted decimal, hexadecimal, binary, dotted binary, tuple and cidr and convert it as necessary.
Ideally this would be the case for to_number as well, it should be able to take all form's of ip address, and subnet mask, and convert it to a valid number.  And all the other to_* functions should then be able to take a number and convert it too.  The biggest problem I can see here is in the pre_transformation_validations function where any integer over 32 is just assumed to be invalid as this is as high as a cidr mask will go.  I'm thinking I might have to break the functions up, either into separate Address & Subnet modules or into address_to_* and mask_to_* functions.  I wasn't overly happy with the pre_transformation_validations anyway.
The to_* functions also have built in validation, and privately transform from, and to, a common data structure to enable simpler transformation across the functions. Each function follows a similar path: performs any pre-transformation-validations, converts the argument to a 4 element list, validates that list, then if valid converts the list to the required form.  This path gives us a couple of benefits; apart from the pre-transformation-validations, we only have to validate one data structure, the 4 element list, rather than having to validate hex & binary etc.  It also means we only have to write one function to convert a 4 element list to a number, and another to convert a number to a 4 element list, we can then utilise the already existing functions to transform a number to the other forms, and the other form into a number, via the 4 element list. Does that make sense? I realise I'm rambling!
Yeah, unsigned is fine for our needs as we don't need to represent negative numbers, but if it's a case of making return values work for other services such as Postgres than that could be useful.
Thanks @h4cc !

Looks like development has halted here, because some preconditions to my PR might not be met.
@bordeltabernacle A idea how this could proceed?

Hi @h4cc
Yeah, I admit I've not paid much attention to this lib for a while, my involvement with Elixir has diminished somewhat recently due to work stuff.  But, anyway, I'm not abandoning this just yet.  I'm starting a develop branch where I'm going to start breaking the API into Address, Mask, & Network modules, as I think this will be the best thing moving forward, hopefully at this point we can get these functions in.
I welcome any feedback you have on this as I'm learning as I go and may not be sure of the most practical way forward from an Elixir point of view.
How does this sound to you?

Sounds good. Ping me when your branch is ready :)

sorry @h4cc I've deprecated this project as I'm not spending any time with Elixir anymore, feel free to fork it


Update docs

Updated docs

Added more comments in codes
Merged #35 and enabled docs
Added some MarkDown docs

/merge


glew: default enableEGL to true

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux (cross from x86_64-linux)
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Ugh, still had the HEAD~1 in my push URL. will open a new PR.


update jackson-databind version

Proposed changes

Describe your changes to communicate to the maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to that issue.

Types of changes
Please put an x in the boxes related to your change.

[O] Bugfix
[ ] New feature or enhancement
[ ] Others

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] I have read the CONTRIBUTING doc
[ ] I have signed the CLA
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Adding an API to validate a schema

This api will convert the given schema to the same format
that we see from GET /schemas/{schemaName}. Similar to #1856.

Codecov Report

Merging #2009 into master will decrease coverage by 0.1%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #2009      +/-   ##
==========================================
- Coverage   69.76%   69.66%   -0.11%
==========================================
  Files         826      826
  Lines       39991    39997       +6
  Branches     5381     5382       +1
==========================================
- Hits        27900    27863      -37
- Misses      10243    10283      +40
- Partials     1848     1851       +3

Impacted Files
Coverage Δ

...ller/api/resources/PinotSchemaRestletResource.java
39.13% <0%> (-3.73%)
:arrow_down:

...t/common/exception/PermanentDownloadException.java
0% <0%> (-100%)
:arrow_down:

...not/common/segment/fetcher/HttpSegmentFetcher.java
68.42% <0%> (-15.79%)
:arrow_down:

...e/operator/dociditerators/MVScanDocIdIterator.java
52.23% <0%> (-11.95%)
:arrow_down:

...kedin/pinot/core/query/reduce/EqualComparison.java
55.55% <0%> (-11.12%)
:arrow_down:

...m/linkedin/pinot/common/utils/FileUploadUtils.java
43.97% <0%> (-7.81%)
:arrow_down:

...impl/dictionary/DoubleOnHeapMutableDictionary.java
68.88% <0%> (-6.67%)
:arrow_down:

...e/impl/dictionary/LongOnHeapMutableDictionary.java
88.88% <0%> (-6.67%)
:arrow_down:

...not/core/query/pruner/DataSchemaSegmentPruner.java
53.65% <0%> (-4.88%)
:arrow_down:

...mon/utils/retry/ExponentialBackoffRetryPolicy.java
81.81% <0%> (-4.55%)
:arrow_down:

... and 22 more

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 014c16e...608aac8. Read the comment docs.


Feature request: Add in .versionize "firstParentOnlyCommit" (or similar) to have only the first parent of each commit in branch

Hi,
Thanks for this library. It's pretty nice to have a automatic resume all the work that we've done on version.
I have a project where I regularly perform commits and pull requests on a local azure devops.
However, when I try to generate the changelog, it outputs all the commits I've made on the branches used in the pull requests.
I'd like to know if we can add an option to include only parent commits in the changelog.
I've seen that in the library libgit2sharp, you can add a filter to display only the parent commits of a branch.
See : https://github.com/libgit2/libgit2sharp/blob/5085a0c6173cdb2a3fde205330b327a8eb0a26c4/LibGit2Sharp/CommitFilter.cs#L65
Note: I saw that there was a similar topic already open ( #118 )

Would you mind adding an example scenario so I can better visualize the desired input/output? So multiple branches are involved in a single pull request?

Here's an example
Before (FirstParentOnly = false) :

After (FirstParentOnly = true) :

Sure, that works.

Ready for Versionize v2 #135


Tray rsp v3

Description
Syncing up with React Spectrum V3 work on Dialog, Modal, and Tray.
It requires https://github.com/adobe/spectrum-css/pull/710
To-do list

[ ] If my change impacts other components, I have tested to make sure they don't break.
[x] If my change impacts documentation, I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.

[x] This pull request is ready to merge.

@GarthDB Looks like some token are missing which caused gulp build failed.

@jianliao that's really odd, it was working before, and it looks like the variables are there, I'll dig into it.

Maybe consider some of the RTL support like changing things back to to inline-size.

@jianliao can we please add a VRT for this PR?

@bernhard-adobe I switch things to inline for rtl. Could you give me a review?


Bump GitHub actions/checkout from 3 to 4

Main change is an update of the default runtime to Node 20 inside the action.
Note: actions/checkout@v4, needs to be added to https://github.com/openbgpd-portable/openbgpd-portable/settings/actions to make this pull request passing.

Merged with 272fa867691053049e0a6932ea364f554a935ea7


Ignoring articles not working as expected

I have a rule like the following in my config:
ignore-article "https://example.com/*" "title !~ \"interesting thing\""
I'd expect this to ignore any articles from any feed from https://example.com/ that does not have the string "interesting thing"  in the title. But I see articles slip past this rule anyway :(
I think there could be 3 causes for this:

I'm an idiot and this rule does not do what I expect it to do.
* doesn't work as a wildcard in feed URLs, but only as a standalone wildcard for all feeds.
There's an actual bug!

Is anyone able to tell me what's going on? :)
Edit: I just realised that there's a #newsboat channel on Freenode, which might have been a better place for something questionish like this, but I'll leave it here, to avoid causing too much commotion.

Looks like your second assumption is correct, only wildcard for all feeds is recognized and it isn't doing any actual parsing on the url.
The relevant codebit is the following:
https://github.com/newsboat/newsboat/blob/6f3c0ccc037576bf069206f6628925ea5174b375/src/rss.cpp#L408-L419

Thanks, both of you!
@Minoru, I did read the docs, and did understand what it said. I guess I was just hoping for a little bit of additional magic :)

can we make the documentation better?

That would be to explicitly say that * only works to match all feeds, not as a wildcard in feed URLs.

Second, maybe this should lead to a feature request for globs or regexes

Oh yes, that would be sweet! Would you prefer to open a new issue for this yourself or do you want me to do it?

Both will conflict with URL's use of question mark, though

Yeah. Let's save that discussion for the issue for the actual feature request.
I'll close this one, as I consider my question answered. Thansk again.

@decibyte, turns out we already have an issue for that over at Newsbeuter tracker: akrennmair/newsbeuter#500. But if you have more thoughts on the matter, please do open an issue here, and we'll discuss it further.
(My stance regarding Newsbeuter issues and how they apply to Newsboat is outlined in #31.)

a patch 1b7b48adf69c9d0e0fa251ceb252671daf429c3f which does regex matches with the feed url. I don't like c++ codebases so I just took the quick route and used the built-in regex match, which uses ECMAScript style I think.
and I'm using this
ignore-article "https://nitter.net/.*" "title =~ \"RT by\" or title =~ \"R to\""