Optional expression does not follow property assignment rule

The syntax for property assignment is:

property_name [= expression];

The spec Section <IP_ADDRESS> says the value is presumed true when the expression is not specified .

When expression is not specified, it is presumed the property_name is of type boolean and the default value is set to true.

The example in #45 demonstrates the issue:

property bool_prop {type = boolean; component=field; default=false;};
addrmap test {
    reg {
        field {
            bool_prop;
        } FIELD[4] = 0;
    } TEST @ 0x0;
};

would return 0 when doing a print(node.get_property("bool_prop")) on the Python side (and 1 when the default is set to true.

These should always be equivalent irrespective of the property declaration.
bool_prop;
bool_prop=true;

The behavior of a user defined property's default setting is often misinterpreted and this is actually the intended behavior. See my reply in #30 for a detailed explanation.

Isn't the example in 15.2.2 just another bug in a comment like these?
https://systemrdl-compiler.readthedocs.io/en/latest/dev_notes/rdl_spec_errata.html
This comment in #30 is not backed up anywhere other than the 15.2.2 example.

For normal built-in properties, a no-value assignment implies the property was assigned true. For UDPs, it implies the assignment of its default.

The spec that says the opposite in 15.2.  User Defined Properties (UDP) have the same assignment rules as built in properties.

User-defined properties may be assigned like general properties (see 5.1.3).

What's the point of specifying a default value?

15.2.1-c) User-defined properties can be bound to a component without setting a value.
15.2) A user-defined property is bound when it is instantiated within a component definition or assigned a value.

This property does not have a value and must be instantiated within a component in order to be bound.
property some_bool_p { type = boolean; component = field; };
You can bind this UDP to all field components by assigning a value.
default some_bool_p; // implies some_bool_p=true;
This property has an assignment and is bound to all field components with the value of false.
property some_bool_p { type = boolean; component = field; default = false; };
We can also use 15.1.1-d to clarify the intended behavior.

A default of true creates an inconsistency with respect to SystemRDL property assignments.

This property binds some_bool_p=true to all field components in the current scope (since it has been assigned a value).
property some_bool_p { type = boolean; component = field; default = true; };
When we instantiate the property within a component, it does not change the value.  The default assignment was true and the implied assignment is also true.
field { some_bool_p; } field1; // Attach some_bool_p to the field with a value of true;
This is inconsistent with a built-in property because the statement above would have changed the value from false to true.
In systemrdl-compiler we have an inconsistency inconsistency when the default value is false.
property some_bool_p { type = boolean; component = field; default = false; };
field { some_bool_p; } field1; // Attach some_bool_p to the field with a value of false;
A built-in property would have assigned the value of true.
I think the systemrdl-compiler implementation is based on a bug in a comment and does not reflect the actual rules in the spec.

@j-klier Re-opening this, since I missed your detailed reply after I initially had closed this.
In principle, I totally agree with you on what the default keyword ought to do. I just want to be extra sure I'm not missing something in the spec's interpretation before I proceed to change the compiler's behavior.
You have a good point regarding your comment on clause 15.1.1-d. That pretty clearly confirms the intended behavior. Worth copying the full text of that clause for posterity:

The default attribute can result in some inconsistencies relative to the behavior of built-in properties
to the language, especially relating to boolean properties. Built-in booleans in SystemRDL are
inherently defaulted to false. With user-defined boolean properties, the default can be specified to
be true or false. A default of true creates an inconsistency with respect to SystemRDL property
assignments.

One last thing that's nagging me, is the text in the opening paragraph of Section 15:

Unlike built-in properties, user-defined properties are not automatically bound to every instance of the specified
component’s type; instead they need to be bound per instance and/or component definition.

The above statement is what originally led me to my first interpretation, which I agree, is probably incorrect. That said, what on earth could that mean - that UDPs need to be "bound"? Any ideas on how to interpret that?

Aagh! Now I'm not totally convinced. Looking at the full 15.2.2-Example1 again, there is another snippet that is interesting:
property some_num_p { type = number; default = 0x10; component = field | reg | regfile };
// ...
field { some_bool_p = true; some_num_p; } field2;

This raises several questions:

What is the value of some_num_p in this case? Surely it cannot be True since that's not an integer. (casting it to 1 could be the case ... I guess?).
Or does it get "bound" the default value of 0x10? This is consistent with my original interpretation and current implementation. It also aligns with the rest of the comments in that example.
What was the author's intent of showing this example in the first place? Given the full context, it appears to be demonstrating the behavior of assignments w.r.t. defaults.

I disagree that this example is a mere typo. It feels a bit too ... intentional. However I do agree that the wording of clause 15.1.1-d subtly contradicts with 15.2.2-Example1.
It seems there are two concepts at play here:
The value assigned if an expression was not given when specifying a property

Built-in properties:

Very clearly states in <IP_ADDRESS> that the value is true
Also the phrasing uses the word "default" to imply it is referring to this concept specifically:

When expression is not specified, it is presumed the property_name is of type boolean and the default value
is set to true.

UDPs:

15.2.2-Example1 as a whole seems to only make sense if the value assigned is the default from the UDP's declaration.

The "assumed" value of a property if not assigned at all

Built-in properties:

Boolean built-ins are always assumed false if unassigned
Other built-in properties vary wildly and often depend on context

UDPs:

Ambiguous!
Does this also assume the UDP's default value? This would be consistent with 15.1.1-d.
Or does it remain "undefined" since it was not "bound" as the intro paragraph in Section 15 states?

Thanks for highlighting the wording in <IP_ADDRESS>.

When expression is not specified, it is presumed the property_name is of type boolean and the default value
is set to true.

I agree that 15.2.2-Example1 is too intentional to be a mistake and the correct interpretation is that the implied expression assigns the default value from the UDP declaration (if available).  When the default value is not present, the value should come from the data type according to <IP_ADDRESS>.d.  The difference between UDP and pre-defined properties is that pre-defined properties are presumed to have the default = true whereas UDP use the value from the declaration (if any).
Implied expressions
I've added a_map_p to your example to show the difference between a UDP with and without a default value.
property a_map_p { type = string; component = addrmap | regfile | field; };
property some_num_p { type = number; default = 0x10; component = field | reg | regfile };
property some_bool_p { type = boolean; component = field; default = false; };

field {
    ispresent; // = presumed true
    rclr; // = presumed true
    a_map_p; // = "" implied from default value for string type
    some_num_p; // = 0x10 implied from default value
    some_bool_p; // = false implied from default value
}a;

When is a UDP bound to an object?
A UDP requires an instance or assignment to bind it to the component.

15.2) A user-defined property is bound when it is instantiated within a component definition or assigned a value.

Assignments are outlined in <IP_ADDRESS>. and specifically:

<IP_ADDRESS>.c) default property assignment (see <IP_ADDRESS>)
<IP_ADDRESS>.d) SystemRDL default value for property type (see Table 7)

Where the type refers to the data type, not the the default value from the property declaration.
The default value from the declaration is not the same as a default property assignment statement.  This was covered in https://github.com/SystemRDL/systemrdl-compiler/issues/30, but I think the default property assignment statement is a valid way to bind a property to a component.
property a_map_p { type = string; component = addrmap | regfile | field; };
property some_num_p { type = number; default = 0x10; component = field | reg | regfile };
property some_bool_p { type = boolean; component = field; default = false; };

default some_num_p = 0x20;
field {
    // ispresent = true assumed due to 5.3.1-b
    // rclr = false assumed
    // a_map_p = has not been bound
    // some_num_p = 0x20 from default property assignment
    // some_bool_p = has not been bound
}a;

Summary
My original assumptions were incorrect

default value during UDP declaration is different than default property assignment.
SystemRDL treats pre-defined properties differently from UDP during implied expressions because it "presumes" pre-defined properties were declared boolean and true.
The user must know how the UDP was declared when using implied expressions.

2 new questions/issues were raised:

A UDP without a default value should be derived from the data type (see <IP_ADDRESS>.d and Table 7)
A UDP default property assignment should bind the property to all matching components in the same scope.

Is this issue also related to the default value of the UDP never gets assigned to the instances? In this example, I would expect the "mymap" version property to be "1.0" but I get None.
property version {
    type = string;
    component = addrmap;
    default = "1.0";
};

addrmap mymap {
    reg {
        field {} a1;
    } a;
};

You have given the property a default value, but no default assignment.  I believe you need an assignment statement like this:
property version {
    type = string;
    component = addrmap;
    default = "1.0";
};
default version; // = "1.0" is implied from default value
addrmap mymap {
    reg {
        field {} a1;
    } a;
};

Can you confirm if adding the default assignment statement fixes the issue?


📈 SSW Rules - Logging Fakes

https://github.com/SSWConsulting/SSW.Rules.Content/pull/9565

PR Merged


Initial documentation for the version catalog

Context
This commit introduces documentation for the whole "version catalog" feature, which includes
declaring a version catalog in settings, in an external TOML file, and via the version catalog
plugin.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

Sorry some internal error occurs, please contact the administrator @blindpirate

@bot-gradle test this

OK, I've already cancelled the old build and triggered a new ReadyForMerge build for you.

Rendered version: https://builds.gradle.org/repository/download/Gradle_Check_BuildDistributions/39394797:id/distributions/gradle-6.8-docs.zip!/gradle-6.8-20201112195045%2B0000/docs/userguide/platforms.html

@jjohannes : > I am wondering why you can't define plugin versions in the settings file? Or can you? It was just weird that this topic is only introduced when the TOML file is described.
Yes you can. The settings DSL already exists, so we just delegate to this DSL. It's:
pluginManagement {
    plugins {
        id 'foo' version '1.0'
    }
}

Thanks a lot for the review Jendrik, I'll fix the remaining issues asap.

Thanks. I did not make this connection. Maybe the documentation for pluginManagement { plugins {}} can be linked in the section about plugin versions in the toml file. Or there could be a note with a link in the section about declaring dependency versions in settings.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.


Bump guava 271jre

In order to bump gson to 2.8.9 per https://github.com/apache/brooklyn-server/pull/1270, it is necessary also to bump jclouds to 2.4.0 which bumps guava to 27.1j.  As jclouds-karaf is not maintained, the definition of the jclouds feature is incorporated here.  This gives us more flexibiilty about start order so we've taken the opportunity to tidy up the feature definitions and optimize startup.
It now starts in 10 seconds with no refreshes!
However for sshj to work, due to an implicit reference to Curve in eddsa.math (which is neither exported from eddsa nor imported to sshj) we need to wrap those to bundles and redeclare the exports/imports.  Not sure how jclouds-karaf managed to do this in a cleaner way, but without this ssh wouldn't connect; now however confirmed that jclouds+ssh is working as part of this.
Note several more downstream PRs which will reference this.

This closes #1270.


DataSources- Vulnerability fixes

Fixed latest CG vulnerabilities for DataSources.
To-do : need to test changes.

Datasoucre PR closed


Starship Security System BP Cost Modifier

Each starship security computer countermeasure costs a number of Build Points equal to the starship’s computer’s tier (half the starship’s tier, rounded down, minimum of 1). Can the [Starship Security System] > [Details] > [Common Component Properties] get updated with a new checkbox for "BP Cost Equals Starship's Computer Tier"?
Ideally, this would automatically populate the [Buildpoint Cost] field with a dynamic value.

The more open, and thus ideal solution; would be to allow @ references in that field. Ship computers are usually half the tier of the ship, So the formula for them would be<EMAIL_ADDRESS>/ 2)".
Similar formulas would exist for other items. Such as ones that refer to the size category. (I don't know if that currently has a value attached to it in system)
But another thing worth adding, is a text field under the BP field, for items that reference something that can't be reached by an @ reference. Such as Antipersonal Weapons, which is based on the level of the weapon you attach.


use lightweight GeometryBasics

Compile Times benchmark
Note, that these numbers may fluctuate on the CI servers, so take them with a grain of salt. All benchmark results are based on the mean time and negative percent mean faster than master. Note, that GLMakie + WGLMakie run on an emulated GPU, so the runtime benchmark is much slower. Results are from running:
using_time = @ctime using Backend
# Compile time
create_time = @ctime fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @ctime Makie.colorbuffer(display(fig))
# Runtime
create_time = @benchmark fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @benchmark Makie.colorbuffer(display(fig))

using
create
display
create
display

GLMakie
–
–
–
–
–

master
–
–
–
–
–

evaluation
–
–
–
–
–

CairoMakie
8.77s (8.70, 8.84) 0.04+-
20.39s (20.33, 20.54) 0.09+-
3.32s (3.31, 3.33) 0.01+-
19.84ms (19.68, 19.96) 0.10+-
24.18ms (24.05, 24.33) 0.08+-

master
9.03s (8.98, 9.09) 0.04+-
21.26s (21.12, 21.38) 0.10+-
3.40s (3.38, 3.42) 0.02+-
17.11ms (17.00, 17.22) 0.08+-
24.04ms (23.94, 24.16) 0.08+-

evaluation
-2.93%, -0.26s invariant (-5.97d, 0.00p, 0.04std)
-4.26%, -0.87s invariant (-8.78d, 0.00p, 0.10std)
-2.39%, -0.08s invariant (-6.16d, 0.00p, 0.01std)
+13.73%, 2.72ms worse❌ (29.01d, 0.00p, 0.09std)
+0.57%, 0.14ms invariant (1.62d, 0.01p, 0.08std)

WGLMakie
–
–
–
–
–

master
–
–
–
–
–

evaluation
–
–
–
–
–

Compile Times benchmark
Note, that these numbers may fluctuate on the CI servers, so take them with a grain of salt. All benchmark results are based on the mean time and negative percent mean faster than the base branch. Note, that GLMakie + WGLMakie run on an emulated GPU, so the runtime benchmark is much slower. Results are from running:
using_time = @ctime using Backend
# Compile time
create_time = @ctime fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @ctime Makie.colorbuffer(display(fig))
# Runtime
create_time = @benchmark fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @benchmark Makie.colorbuffer(display(fig))

using
create
display
create
display

GLMakie
–
–
–
–
–

breaking-release
–
–
–
–
–

evaluation
–
–
–
–
–

CairoMakie
12.66s (12.40, 12.89) 0.20+-
24.27s (23.70, 24.79) 0.43+-
4.02s (3.88, 4.17) 0.10+-
25.52ms (25.15, 26.31) 0.39+-
28.66ms (27.95, 29.38) 0.53+-

breaking-release
12.62s (12.35, 12.85) 0.22+-
24.98s (24.10, 25.45) 0.47+-
4.19s (4.13, 4.28) 0.05+-
25.23ms (24.73, 25.83) 0.41+-
28.89ms (27.61, 29.82) 0.73+-

evaluation
+0.28%, 0.04s invariant (0.17d, 0.76p, 0.21std)
-2.95%, -0.72s faster ✓ (-1.59d, 0.01p, 0.45std)
-4.35%, -0.17s faster ✓ (-2.32d, 0.00p, 0.07std)
+1.16%, 0.3ms invariant (0.74d, 0.19p, 0.40std)
-0.80%, -0.23ms invariant (-0.36d, 0.51p, 0.63std)

WGLMakie
–
–
–
–
–

breaking-release
–
–
–
–
–

evaluation
–
–
–
–
–

closing in favor of https://github.com/JuliaPlots/Makie.jl/pull/2220


vim always resets alternate screen

Steps to reproduce

echo main
tput smcup; vim --clean; cat
tput rmcup; vim --clean; cat
See that we are back at the main screen regardless of whether we start in main screen or alternate screen, that is after both steps 2 and 3 we are in the main screen.

Expected behaviour
I expect to return to the screen I started in. At least that's what Bram says should be vim's behavior. Personally, I think that is not possible to do robustly and efficiently, but what do I know.
Reference: https://github.com/vim/vim/issues/11705#issuecomment-1354730945
Version of Vim
9.0.1046
Environment
Operating system: Arch Linux
Terminal: xterm 377 with TERM=xterm
Shell: zsh 5.9
Logs and stack traces
This presumably happens because vim uses the smcup and rmcup capabilities from terminfo to populate t_TI and t_TE. Most (all?) terminals that support smcup and rmcup define them to toggle alternate screen.

I cannot reproduce.  Well, the reproduction steps are unclear, "cat" is not a Vim command.
So what exactly happens after "vim --clean"?
And what is "cat" supposed to do?  Without interaction it just hangs.
If after "vim --clean" I exit Vim I'm back where I started.

On Sat, Dec 17, 2022 at 04:15:54AM -0800, Bram Moolenaar wrote:

I cannot reproduce.  Well, the reproduction steps are unclear, "cat" is not a Vim command.
So what exactly happens after "vim --clean"?
And what is "cat" supposed to do?  Without interaction it just hangs.

vim --clean; then exit vim. cat will prevent the shell from running and
interfering with anything.
tput smcup
puts the terminal in alternate screen. Then vim --clean is started. Then vim is
quit and cat is run. At this point you see that you are in main screen,
not alternate screen, as evidenced by the fact that you can see the
commands you typed on the main screen. But when vim was started the
terminal was in alternate screen.
And anyway you dont need a reproducer, inside vim do
:set t_te?
you will see that it contains ^[[1049l now go lookup this escape code in
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
You will see that it unconditionally changes from alternate screen back
to main screen. Thus on exit vim will always reset the terminal to main
screen regardless of what screen the terminal started at in xterm (and
every other terminal, but lets use xterm here since you like it).

On Sat, Dec 17, 2022 at 04:15:54AM -0800, Bram Moolenaar wrote:

I cannot reproduce.  Well, the reproduction steps are unclear, "cat" is not a Vim command.
So what exactly happens after "vim --clean"?
And what is "cat" supposed to do?  Without interaction it just hangs.

vim --clean; then exit vim. cat will prevent the shell from running and
interfering with anything.
tput smcup
puts the terminal in alternate screen. Then vim --clean is started.
Then vim is quit and cat is run. At this point you see that you are in
main screen, not alternate screen, as evidenced by the fact that you
can see the commands you typed on the main screen. But when vim was
started the terminal was in alternate screen.

I still don't see what "cat" is needed for.  Assuming starting in the
main screen, that shows the "tput smcup" command, the alternate screen
doesn't.

And anyway you dont need a reproducer, inside vim do
:set t_te?
you will see that it contains ^[[1049l now go lookup this escape code in
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

No, it doesn't contain this code.  For me the value is:
t_te=^[[2J^[[?47l^[8

Now you might think this is the value from the builtin xterm termcap,
but it isn't, because FEAT_XTERM_SAVE is not defined.  You can check
that with the version output, which contains "+xterm_save" if it would
be defined, but for me it is "-xterm_save".  And unless you build Vim
yourself and explicitly enabled this feature, you should have
"-xterm_save".
I'm not quite sure where this t_te value comes from...  The value of
$TERM is "xterm-color".  Ah, it's just the terminfo entry "rmcup" for
this terminal.

You will see that it unconditionally changes from alternate screen back
to main screen. Thus on exit vim will always reset the terminal to main
screen regardless of what screen the terminal started at in xterm (and
every other terminal, but lets use xterm here since you like it).

Well, Vim just does what it has been told to.  The t_te termcap entry is
exactly to allow for the user to control this behavior.  In my .vimrc I
make t_te empty, what other users do is up to them.
--
Nothing is impossible for the man who doesn't have to do it.
/// 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    ///

On Sat, Dec 17, 2022 at 08:17:28AM -0800, Bram Moolenaar wrote:

On Sat, Dec 17, 2022 at 04:15:54AM -0800, Bram Moolenaar wrote:

I cannot reproduce.  Well, the reproduction steps are unclear, "cat" is not a Vim command.
So what exactly happens after "vim --clean"?
And what is "cat" supposed to do?  Without interaction it just hangs.

vim --clean; then exit vim. cat will prevent the shell from running and
interfering with anything.
tput smcup
puts the terminal in alternate screen. Then vim --clean is started.
Then vim is quit and cat is run. At this point you see that you are in
main screen, not alternate screen, as evidenced by the fact that you
can see the commands you typed on the main screen. But when vim was
started the terminal was in alternate screen.

I still don't see what "cat" is needed for.  Assuming starting in the
main screen, that shows the "tput smcup" command, the alternate screen
doesn't.

The shell could potentially reset the screen. Running cat after vim
ensures that cannot happen thereby making the reproducer robust.

And anyway you dont need a reproducer, inside vim do
:set t_te?
you will see that it contains ^[[1049l now go lookup this escape code in
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

No, it doesn't contain this code.  For me the value is:
t_te=^[[2J^[[?47l^[8

And go to https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
and you will see the ^[[47l also uncoditionally transitions to the main
screen just like ^[[1049l

Now you might think this is the value from the builtin xterm termcap,
but it isn't, because FEAT_XTERM_SAVE is not defined.  You can check
that with the version output, which contains "+xterm_save" if it would
be defined, but for me it is "-xterm_save".  And unless you build Vim
yourself and explicitly enabled this feature, you should have
"-xterm_save".
I'm not quite sure where this t_te value comes from...  The value of
$TERM is "xterm-color".  Ah, it's just the terminfo entry "rmcup" for
this terminal.

And this terminfo causes a transition to the main screen.

You will see that it unconditionally changes from alternate screen back
to main screen. Thus on exit vim will always reset the terminal to main
screen regardless of what screen the terminal started at in xterm (and
every other terminal, but lets use xterm here since you like it).

Well, Vim just does what it has been told to.  The t_te termcap entry is
exactly to allow for the user to control this behavior.  In my .vimrc I
make t_te empty, what other users do is up to them.

No one is telling vim what to do. vim is reading t_te from terminfo
rmcup capability. All terminfo's that have this capability reset the
alternate screen in it. Therefore, vim always resets to the main screen
on exit, unless a user goes out of his way to configure it not to, in
contravention of your statement that vim always runs in whatever screen
it was started in. I am simply pointing out that vim is not behaving how
you say it should. What you want to do about it is up to you.

I don't think there is any way for Vim to query which screen buffer it was started in, it may be either the main screen buffer or an alternate screen buffer.  Vim typically returns to the 'main' screen buffer on exit, even if it was started in an alternate screen buffer.
Whatever!  I don't see anyway around this being the default behavior, and users can configure this differently if they wish.
@kovidgoyal   This really feels like a petty point scoring exercise on your part.  What are you actually expecting Vim to do here?  Why does this matter to the keyboard issue?

There is a way to query it, use the DECRQM escape code to query to query the 47 and 1049 modes.
printf '\x1b[?1049$p\x1b[?47$p'; cat -v;

I am expecting vim to do what Bram says it should do, aka respect the screen it was started in. It's technically possible to do that via DECRQM. I dont think its a good idea to do it, but, again, what do I know.
Or Bram needs to retract that statement, which will allow him to realize that vim always resets the screen mode. Therefore there is no problem in also resetting the keyboard mode before resetting the screen mode. Which in turn makes the fix for the keyboard issue trivial.

Maybe not trivial, because Vim doesn't always return to the main screen mode on exit for all configurations.  Consider when Vim is nesting a terminal session, hosting another instance of vim running inside that.   It gets complicated.

On Sat, Dec 17, 2022 at 05:53:40PM -0800, Christopher Plewright wrote:

Maybe not trivial, because Vim doesn't always return to the main screen mode on exit for all configurations.  Consider when Vim is nesting a terminal session, hosting another instance of vim running inside that.   It gets complicated.

I dont follow the complication there. If vim is nesting a terminal it
presumably is using a dedicated PTY device to do so, what does that have
to do with the issue? The state of that PTY device has to be managed
completely independently.

Or Bram needs to retract that statement, which will allow him to realize that vim always resets the screen mode.

Yeah, well, it looks like a petty way to go about it.  Expecting someone to retract a statement feels like an ego thing.   Anyway, I find rudeness unhelpful in most situations.  Maybe it's a cultural thing.  I hope it works out the way you want it to in the end.
Keep in mind, @brammool  wrote what he did shortly after you were rudely condescending toward him.
  You gotta love internet etiquette.
Oh, you are right, PTY provides another layer.  I just did some testing, the nested Vim didn't affect the host Vim.
My example was unhelpful.   But, there are situations where users have set up different configurations where Vim does not return to the main screen buffer.
Thanks for the reference to DECRQM.   My intro to the screen restore issues was on the Windows Terminal side - only about a month ago.    And that does not have any way to query which buffer it started from, at least not that I can find as of yet.   Although, I do see that someone has submitted a PR to Windows Terminal to utilize DECRQM, so that might be doable too sometime in the future.    Anyway, unrelated to the keyboard issue.
Sorry if this is a naive question, but why is the keyboard protocol data tied to which screen-buffer is in use?

On Sat, Dec 17, 2022 at 06:25:22PM -0800, Christopher Plewright wrote:

Or Bram needs to retract that statement, which will allow him to realize that vim always resets the screen mode.

Yeah, well, it looks like a petty way to go about it.  Expecting someone to retract a statement feels like an ego thing.   Anyway, I find rudeness unhelpful in most situations.  Maybe it's a cultural thing.  I hope it works out the way you want it to in the end.

So I should just let incorrect reasons to not do something stand? If that's
the way this repo is run that's fine by me. I will simply bow out at
this point. Good luck.

Keep in mind, @brammool  wrote what he did shortly after you were rudely condescending toward him.

What?? Point out what I said before the reply I quoted was rudely
condescending?
Here is what I wrote:
Dont randomnly transition screens. There is no usecase for that. At startup always switch to alternate screen. Then enable the keyboard protocol. Whenever vim relinquishes control of the tty, whether that is to run a shell command, suspend itself, or quit, it is incumbent on it to restore the tty to the state it found it in, or if it is not capable of doing that, then to a known good state. Which means you turn off the keyboard protocol and preferably transition back to the main screen before relinquishing control of the tty.
Oh and as far as I can tell for this particular issue, all you need to do is emit the restore keyboard protocol bytes before you emit the switch to main screen bytes when doing :!

  You gotta love internet etiquette.

Its the internet what do you expect :)

My example was unhelpful.   But, there are situations where users have set up different configurations where Vim does not return to the main screen buffer.

So in that case emitting the bytes to reset the keyboard protocol
before the rest of t_te wont affect anything. And if a user completely
changes t_ti and t_te then the keyboar dprotcol will not have been
enabled at all in the first place.

Sorry if this is a naive question, but why is the keyboard protocol data tied to which screen-buffer is in use?

Because the keyboard protocol is mostly going to be used by full screen
apps which use the alternate screen. So the alternate screen becomes a
shorthand for setting up various properties. You dont need to reset
individual things every time you transition, unless you want to.
Regardless, that is how the
spec is designed, and by now implemented in multiple places.
vim should support it correctly.

No, I enjoy reading your thoughts.   Please don't bow out because of me!   I'm relatively new to this open development stuff, only been involved in this Vim community a couple of months.   It's none of my business how you discuss the issue.   Just adding my 2c for a different perspective.    I hope you feel free to disagree or disregard anything I say, and please don't feel that I am in anyway representative of the tone of this community.  That would be me doing an injustice to this community.  I'm just a noob trying to get involved and contribute.
The thing that I found condescending;
https://github.com/vim/vim/issues/11705#issuecomment-1354978853

If you insist on using termcap/terminfo in vim maybe you should
educate yourself about them a little.

But, touchet.   Another mistake of mine.   @brammool  did write his comment before yours.   Don't know why I tried to defend what he said that way.  I guess I was reacting to the tone of your comment.
Also, I appreciate your answer to my question about keyboard state;

You dont need to reset individual things every time you transition, unless you want to.

To the actual issue, users can configure some screen restore behavior;
			 *'restorescreen'* *'rs'* *'norestorescreen'* *'nors'*
'restorescreen' 'rs'	boolean	(default on)
			global
			{only in MS-Windows console version}
	When set, the screen contents is restored when exiting Vim.  This also
	happens when executing external commands.

	For non-Windows Vim: You can set or reset the 't_ti' and 't_te'
	options in your .vimrc.  To disable restoring:
		set t_ti= t_te=
	To enable restoring (for an xterm):
		set t_ti=^[7^[[r^[[?47h t_te=^[[?47l^[8
	(Where ^[ is an <Esc>, type CTRL-V <Esc> to insert it)

You suggest the meat of the issue is in here;

So in that case emitting the bytes to reset the keyboard protocol
before the rest of t_te wont affect anything. And if a user completely
changes t_ti and t_te then the keyboar dprotcol will not have been
enabled at all in the first place.

I wonder if you can really assume that is safe, without knowing what users enter into t_ti and t_te.  Are there zero scenarios where it could be a problem to emit the bytes to reset the keyboard protocol before emitting t_te?   Again, I'm just asking as an interested noob.   I'm not suggesting anything is right or wrong here.

On Sat, Dec 17, 2022 at 07:27:51PM -0800, Christopher Plewright wrote:

No, I enjoy reading your thoughts.   Please don't bow out because of me!   I'm relatively new to this open development stuff, only been involved in this Vim community a couple of months.   It's none of my business how you discuss the issue.   Just adding my 2c for a different perspective.    I hope you feel free to disagree or disregard anything I say, and please don't feel that I am in anyway representative of the tone of this community.  That would be me doing an injustice to this community.  I'm just a noob trying to get involved and contribute.

No worries, it's up to Bram, it's his project. If he doesn't want my
input I am happy to leave. I got involved because Bram asked me to help
test his implementation and I am a vim user myself.

The thing that I found condescending;
https://github.com/vim/vim/issues/11705#issuecomment-1354978853

If you insist on using termcap/terminfo in vim maybe you should
educate yourself about them a little.

But, touchet.   Another mistake of mine.   @brammool  did write his comment before yours.   Don't know why I tried to defend what he said that way.  I guess I was reacting to the tone of your comment.

My comment was a direct response to this from Bram:
"
You do know about the relation between terminfo and termcap names,
right?  They are 1:1, so either can be used to identify an entry.
"

To the actual issue, users can configure some screen restore behavior;
			 *'restorescreen'* *'rs'* *'norestorescreen'* *'nors'*
'restorescreen' 'rs'	boolean	(default on)
			global
			{only in MS-Windows console version}
	When set, the screen contents is restored when exiting Vim.  This also
	happens when executing external commands.

	For non-Windows Vim: You can set or reset the 't_ti' and 't_te'
	options in your .vimrc.  To disable restoring:
		set t_ti= t_te=
	To enable restoring (for an xterm):
		set t_ti=^[7^[[r^[[?47h t_te=^[[?47l^[8
	(Where ^[ is an <Esc>, type CTRL-V <Esc> to insert it)

You suggest the meat of the issue is in here;

So in that case emitting the bytes to reset the keyboard protocol
before the rest of t_te wont affect anything. And if a user completely
changes t_ti and t_te then the keyboar dprotcol will not have been
enabled at all in the first place.

I wonder if you can really assume that is safe, without knowing what users enter into t_ti and t_te.  Are there zero scenarios where it could be a problem to emit the bytes to reset the keyboard protocol before emitting t_te?   Again, I'm just asking as an interested noob.   I'm not suggesting anything is right or wrong here.

I cant think of a scenario where it is an issue. If you can I am all
ears.
Also, beyond a certain point if a user changes low level things like this,
they need to take responsibility for not breaking things. Personally, if
I was designing this, I would remove t_ti and t_te and restorescreen.
There is no use case I know of where it ever makes sense for a full
screen application like vim to not use the alternate screen. At best you
can have an option to dump the contents of the alternate screen to the
main screen on exit. But that's Bram's choice and I dont want to dictate
his design.
I will however insist that emitting the keyboard state escape codes in
the correct order is both possible, desirable and safe.
What vim is doing here is setting up terminal emulator state by means of
escape codes. The t_ti sequence is
switch to alt screen -> change keyboard mode
the corresponding unwind t_te sequence should be
change keyboard mode -> switch to main screen
In general when doing state transitions A->B->C
the correct way to unwind it is C->B->A. That is because subsequent
states can depend on previous ones.

me too, i am just the another noob. :laughing:
i may think the problem is just the different angle or level or scope, for example @kovidgoyal mentioned BSU and ESU #11718 such tech actually was a common and used way to reduce flick, but just terminal raw esc level i donot know how it play, and there some exceptions like the case here https://github.com/yegappan/lsp/issues/66#issuecomment-1288450404  such flick looks cannot be solved by such tech.
again, i think there should be some historical reason we cannot change it totally as/per the modern spec, wish to be fixed but not sure which is right or wrong not sure...
// at least this (vim) and that (kitty) is keeping update freq and fast, vs (i would say or blame? :rofl:) gnu-screen 2 years would update a release...

@kovidgoyal   thanks for taking the time to explain it for me.
I'm also following along because I am also trying to deal with issues of Vim working with Windows Terminal using "\033[?1049h"  and  "\033[?1049l".  When using these, it solves a number of issues related to restoring the windows buffer properly when Vim exits.   BUT, these consistently cause some other existing CI Test scripts to fail in the CI test environment.    As of yet, I am still unable to reproduce those failures in any version of Windows,    8, 10, 11 & Server 22.    So, I'm still trying to solve that properly.
Anyway, I know these details are irrelevant for Kitty, but whatever Bram decides is the correct behavior, I want to make sure we follow that on Windows if we can too.
@Shane-XB-Qian   Thanks :)

This discussion is drifting off in various directions, therefore I'm going to close it.
For the original problem: If you don't want switching between the alternate and main screen you have to make sure that the t_te and t_ti termcap entries are empty.
Any change in Vim to try and make this work better will cause havoc among users who rely on the current behavior.  And I don't see a real problem with the current behavior anyway.  It may go against what some people expect, sure, but sticking with how it has worked for 20 years is more important.


Added sample code for D3Js library.

I've appended the code for a simple html file which renders text using D3JS library.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@devanshhu Awesome! Thanks! Congrats on your first open source contribution to this repository!


Make the kick knock harder

The BD barely even slaps. ;) I assume there are some additional concerns here but if you could somehow channel a slightly more authentic kick/sub sound this thing would be out of this world. Great work, awesome project.

I completely agree 😄
The design of the BD is based off of a SOS article talking about Kick synthesis and how you would recreate something like the 808s bass drum with a standard analog modular. Following this alone resulted in some fairly weak sounding kicks so I found a soft-clipping waveshaper curve to give it a little more umph. Unfortunately the waveshaper is rather sensitive and I really had to dial back the gain to make sure it didn't sound like a big-room distorted kick.
But back to the issue at hand. The TR-808 BassDrum was made using a Bridged-T Oscillator which was essentially a digital pulse trigger (actually the same signals used to trigger all of the other drum's envelope generators) being run through a specifically calibrated self-oscillating filter (here's a discussion on the topic).
As far as I know the BiquadFilterNode in the web-audio-api is not capable of self-oscillation so I'll need some help in what direction to go in.

I'll suggest an easier way to get the true 808 kick.  Why not just use a high quality sample with the longest decay setting and use the decay knob to roll it off?  I know that might not be the goal of this project, however, without the bomb 808 kick, you might as well not call it an 808 at all.  In the hip hop world, "paducas" don't even know that an "808" is anything beside that famous low kick sound. LOL.

I've been thinking about doing that for a while now. If I were to go down that route I think it would be best for the app to have two 'modes' (synthesis/sample). When the user would load the page, it would start in synth mode but then they could choose to switch to the sample mode which would trigger the downloading of the samples.
My biggest concern would be the legality of using the samples. Doing a quick google search there are various options for 'free' 808 sample packs but the majority of them do not detail a license for redistribution. On top of that a lot of these (free) sites seem (at first glance) not completely legitimate and it's hard to guarantee they aren't distributing someone else's work.
What we would need to find is a 'clean' 808 sample pack with an FOSS license in order to keep this project as FOSS as possible 😉

@vincentriemer The part about redistribution of sounds from an analog drum computer... here's an interesting thread on the topic.  I'm no expert at copyright law, but I'm pretty sure that once the sounds are recorded through other hardware (i.e. DAW, CDR, DAT etc.) they are the copyright of the owner who sampled them.  If they give away the license for free commercial use, I'm pretty sure you're in the clear.  Since the sound was generated by the hardware originally through analog synthesis, the sounds are not originally a sample.  The patents which Roland owns on the TR-808 is on the actual hardware design and not the sound it produces.
https://www.kvraudio.com/forum/viewtopic.php?t=255116
Here's a pretty good source for samples.  http://smd-records.com/tr808/?page_id=14  and are sounds that were used in this project which I forked and modified to add Swing and Instrument Mutes here!  https://codepen.io/lacostenycoder/full/bgbQzX/
Unless you plan on selling these "samples" commercially, I don't think there's much to worry about in the way of legal issues.  Consider the fact that your software version uses the same look, feel, color scheme, functionality and design as the original TR-808.  I'm gonna guess you didn't get permission from Roland to utilize that much of their design concepts right?  You could probably also add a disclaimer somewhere.  When it comes to intellectual property, the further you drill into the topic, the more blurry it becomes.


Galarian Farfetch'd can't evolve into Sirfetch'd

So, I tried doing the 3 crits in a single battle method to evolve my Galarian Farfetch'd and it didn't work. It may still be bugged. However, maybe for an easier way of evolving it, maybe have it hold a Black Belt and faint another pokemon, or an item along those lines. Just a suggestion though, to make it easier :)

Hello! This is fixed pending restart. Thanks for the ticket!


Bake direct eoc exercises

In pl-psychology EOC exercises sections are direct children of chapter. (They're not inside composite chapter like in u-physics or calculus).
I created two erb files: one for direct exercises section (direct_review_exercises.xhtml.erb) and one for exercises section from composite chapter (child_review_exercises.xhtml.erb). They differ only in two places, title tag and title from metadata:

Let me know what do you think about this solution and name convention of files.

@kswanson33 @LostMojo Thank you for all your comments :relaxed: I applied solution suggested by you. It's ready for rereview.

@LostMojo @kswanson33 I added specs for both versions. PR is ready for review. I'm new to creating rspecs, so I'm not sure if this is how it suppose to look :grin: Let me know if I did something wrong.


[BUG] sendMessage not sending image attached

Describe the bug
When passing a buffer from a base64 image string, the image does not go with the message
To Reproduce
Steps to reproduce the behavior:

Create a buffer from a base64 string
Send it with image property

Expected behavior
The image is sent within the message
Code:
public async sendMessage(number: string, message: string, base64: string) {
    const a = await<EMAIL_ADDRESS>{
        text: message,
        image: Buffer.from(base64, "base64"),
    });
}

Describe the bug When passing a buffer from a base64 image string, the image does not go with the message
To Reproduce Steps to reproduce the behavior:

Create a buffer from a base64 string
Send it with image property

Expected behavior The image is sent within the message
Code:
public async sendMessage(number: string, message: string, base64: string) {
    const a = await<EMAIL_ADDRESS>{
        text: message,
        image: Buffer.from(base64, "base64"),
    });
}

For media messages use caption instead of text
const a = await<EMAIL_ADDRESS>{
    image: Buffer.from(base64, "base64"),
    caption: "your caption"
});


When making an absurdly large number of an item, autocrafting stops working for that recipe and other recipes (not all). Also my materials needed for that got wiped out of existence.

Issue description:
Friend went on my system and ordered 23512 crafters (e2e recipe). It wouldn't go onto the pre craft screen and just stay there.  Clicked cancel and tried again to craft 1. it wouldnt go onto the pre craft screen again, and i logged on and checked that all of my redstone, iron and glass just disappeared.
What happens:
Friend went on my system and ordered 23512 crafters (e2e recipe). It wouldn't go onto the pre craft screen and just stay there.  Clicked cancel and tried again to craft 1. it wouldnt go onto the pre craft screen again, and i logged on and checked that all of my redstone, iron and glass just disappeared.
What you expected to happen:
To go to the precraft screen and be able to cancel it and be able to autocraft it again, and not have my items disappear.
Steps to reproduce:

Craft a crafter (e2e recipe) fully automated recipe. Ask for an absurdly large number.
To be honest I don't even know if this is reproduceable, if you want I can send you the server IP so you can test it out and the co ordinates of my house.
...

Version (make sure you are on the latest version before reporting):

Minecraft: 1.12.2
Forge: 2847
Refined Storage: 2.2.9

Does this issue occur on a server? [yes/no]
Yes
If a (crash)log is relevant for this issue, link it here:
[pastebin/gist/etc link here]

Also what is the payload too large error? Try making a crafting table recipe and it just crashes or the greenhouse glass from actually additions

Also what is the payload too large error? Try making a crafting table recipe and it just crashes or the greenhouse glass from actually additions

That happens because the maximum size for a packet payload in minecraft is 32767 bytes. The amount of different saplings that are a available for the recipe all have to be sent to the client thus exceeding this limit.  This could probably be caught to not kick you but it would still not work. I am currently thinking of including this into a core-mod I am working on to make this limit customizable.

Sounds like an error happened while it was calculating. Anything in the log or debug log?
I should probably handle errors better so you don't loose all items

Sounds like an error happened while it was calculating. Anything in the log or debug log?
I should probably handle errors better so you don't loose all items

I'll be honest, I have no idea how to read the debug log, I can send it if you like, and yeah every single thing that that recipe used is gone.

Thanks for the log. There was indeed an error during calculation.

Does it break in the same way if you only request a single crafter? I don't think it depends on the requested amount
I've made a new build with improved error messages. Could you try running that and send me the logs again?
Could you post all pattern that are involved in making a crafter in your setup if that aren't too many. Or even better would be if you could build a setup in single player with the minimal amount of blocks and patterns required to make it crash.

Yes, breaks the exact same way. I can send the logs as well,
here is what i saw on the terminal after clicking the craft button
[20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.Task.<init>(Task.java:239) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.ProcessingTask.<init>(ProcessingTask.java:62) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.Task.calculate(Task.java:536) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.Task.calculate(Task.java:544) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.Task.calculate(Task.java:544) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.Task.calculate(Task.java:544) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.Task.calculate(Task.java:544) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.Task.calculate(Task.java:544) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.Task.calculate(Task.java:544) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.autocrafting.engine.task.MasterCraftingTask.calculate(MasterCraftingTask.java:350) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at com.raoulvdberge.refinedstorage.apiimpl.network.grid.handler.ItemGridHandler.lambda$onCraftingPreviewRequested$1(ItemGridHandler.java:220) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1604) [20:08:57] [ForkJoinPool.commonPool-worker-2/INFO] [STDERR]: [java.lang.Throwable:printStackTrace:635]: 	... 5 more [20:08:58] [Thread-142/INFO] [THAUMCRAFT]: Stopping aura thread for dim 144 [20:09:12] [Server thread/DEBUG] [FML]: Gathering id map for writing to world save world
latest.log

sorry i couldnt do the single player world thing my internet is awful especially my upload speed (talking about 0.5mbps upload, living rurally isnt very good for this sort of thing lol)

I can send you the server IP with the additional mods for E2e 1.82a and the co ordinates for my base if you'd like.

I can send you the server IP with the additional mods for E2e 1.82a and the co ordinates for my base if you'd like.

Joining your server won't help me. Have you tried point number 2 from my comment?

I can send you the server IP with the additional mods for E2e 1.82a and the co ordinates for my base if you'd like.

Joining your server won't help me. Have you tried point number 2 from my comment?

Yeah I downloaded the new update and it would still do the same thing, i sent the log in my reply with the images, i can send it again here because I recognise that it's hard to see.
latest (1).log

Yes, that log helps. The problematic pattern seems to be the one that makes stone. Is the input for that flint?
You could probably avoid the error by turning off oredict.

Right okay I’ll try the stone pattern and turn ore dict off for that one because I redid all the patterns apart from stone with ore dict off.
I’m presuming that ore dict is completely broken or something? One of the other issues is about ore dictionary which I’ll be honest about I have no clue what it means but if it means I have to turn it off, so be it.

What does the stone pattern look like? It seems like you put something there which also oredict to stone, meaning 1 stone = 1 stone which kinda breaks stuff

Well, that fixed it. The pattern was just cobblestone in a furnace.
So I'm assuming now that ore dict is broken and I should not use it at all? Because turning ore dict off on that fixed it all lol.
Also, did my items get deleted because of the error?

Also, did my items get deleted because of the error?
Yeah, how I handle that isn't the greatest right now.

So I'm assuming now that ore dict is broken and I should not use it at all? Because turning ore dict off on that fixed it all lol.
I think I can circumvent the crash, although your oredict there seems just weird I guess. I recommend always turning off oredict anyway and only turning it on when you might need the functionality.

Alright thanks, now that the issue is resolved I guess we can close this now. Thanks!


Error in running runspatialdecon

When running runspatialdecon, I got the following error:
Error in [<-(*tmp*, colnames(result$beta), , value = t(result$beta)) :
subscript out of bounds
Here is my code:
target_MRD_Data_filter2$istumor = target_MRD_Data_filter2$SegmentLabel == "Tumor"
restils = runspatialdecon(object = target_MRD_Data_filter2,
norm_elt = "q_norm",
raw_elt = "exprs",
X = safeTME,
cellmerges = safeTME.matches,
cell_counts = target_MRD_Data_filter2$AOINucleiCount,
is_pure_tumor = target_MRD_Data_filter2$istumor,
n_tumor_clusters = 10)
Hope to get your help about the reasons. Thank you so much!

Hi @ydai3,
Our customer support team will be able to help you with this. Please email<EMAIL_ADDRESS>with your issue.
Thanks,
Maddy


music.yandex.ru bug

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like that [x])
Use Preview tab to see how your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2016.07.30. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

[x] I've verified and I assure that I'm running youtube-dl 2016.07.30

Before submitting an issue make sure you have:

[x] At least skimmed through README and most notably FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

d:\1\3>youtube-dl -v https://music.yandex.ru/album/1980067
[debug] System config: []
[debug] User config: ['--no-mtime', '--no-check-certificate', '-o', '%(title)s.%
(ext)s']
[debug] Command-line args: ['-v', 'https://music.yandex.ru/album/1980067']
[debug] Encodings: locale cp1251, fs mbcs, out cp866, pref cp1251
[debug] youtube-dl version 2016.07.30
[debug] Python version 3.4.4 - Windows-8.1-6.3.9600
[debug] exe versions: ffmpeg N-50515-g28adecf
[debug] Proxy map: {'http': 'http://someserver:80', 'no': 'localhost,12
<IP_ADDRESS>', 'https': 'http://someserver:80'}
[yandexmusic:album] 1980067: Downloading album JSON
[download] Downloading playlist: Nirvana - With The Lights Out - Box Set (2011)
[yandexmusic:album] playlist Nirvana - With The Lights Out - Box Set (2011): Col
lected 23 video ids (downloading 23 of them)
[download] Downloading video 1 of 23
[yandexmusic:track] 555386: Downloading track JSON
[yandexmusic:track] 555386: Downloading track location JSON
Traceback (most recent call last):
File "main.py", line 19, in
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl_init_.py", line 422, in main
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl_init_.py", line 412, in _real_main
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\YoutubeDL.py", line 1775, in download
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\YoutubeDL.py", line 693, in extract_info
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\YoutubeDL.py", line 854, in process_ie_result
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\YoutubeDL.py", line 746, in process_ie_result
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\YoutubeDL.py", line 682, in extract_info
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\extractor\common.py", line 347, in extract
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\extractor\yandexmusic.py", line 138, in _real_extract
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\extractor\yandexmusic.py", line 96, in _get_track_info
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpiptyv43b\bu
ild\youtube_dl\extractor\yandexmusic.py", line 78, in _get_track_url
TypeError: Can't convert 'list' object to str implicitly

Duplicate of #10193.


1.6. Broadcast token invalidation Information

With the Admin API as mentioned in section 1.1.2, the auth admin will specify the token to be invalidated. This information will be stored in the database which shall be used as the source of truth. The same shall be published (broadcasted) to parties who are interested in it using the internal RabbitMQ server.

closes #142


[calendar] add config option "showEndsOnlyWithDuration"

redo and rebase changes made in PR https://github.com/MagicMirrorOrg/MagicMirror/pull/2968 by https://github.com/kleinmantara

want to add tests for that too?

no, I will try to check if I can update other dangling PR's before release, so feel free to write tests for this ...


feat(assembly): Add line number while token parsing

Closing since parsing will be affected by issue #298.


postgres timestamp precision vs javascript timestamp precision

node.js Date() -> precision of milliseconds
postgres timestamps -> precision of microseconds
and when we're saying "record.created_at <= ${record.createdAt.toISOString()}" we are loosing the extra precision

so assume:

record.created_at = 12:30:21.123456

then

record.createdAt => 12:30:21.123
=> record.created_at <= record.createdAt => 12:30:21.123456 <= 12:30:21.123000 => false

this is a non intuitive bug that will crop up over and over due to the difference in precision.
our options are to:

store data in the rounded precision [loss-of-information]
round the precision when reading [poor-performance]
remember this bug each time we want to compare timestamps from js to sql [not-maintainable]

we can not use the "loss-of-information" option because for high speed writes we do need the created_at to maintain a microsecond precision in order for version information not to be lost
so that option is out, leaving us with only:

round the precision when reading [poor-performance]
remember this bug each time we want to compare timestamps from js to sql [not-maintainable]

i guess the other option is to require usage of a more precise date class:

e.g., PreciseDate or Timestamp

maybe domain-objects can come with that one
it has defaults in which:

it is always a string
it can be parsed as iso
it has default precision of 6 (microseconds)

and then the sql-dao-generator can just ban using Date as the constructor, because it causes this bug

would date-fns work with that option though? ^

looks like it would not: https://www.reddit.com/r/javascript/comments/ff76xr/askjs_are_there_any_js_datetime_formatting/
may need to create a library that lets javascript work with microsecond precision timestamps :thinking:
maybe we can extend the normal Date fn w/ an added field of microseconds :thinking:
or maybe we can wrap that rust package like that thread recommended

:tada: - instead of making our own - we should be able to use Temporal when it comes out: https://tc39.es/proposal-temporal/docs/index.html


Added AWS Marketplace option in pricing page.

Added AWS Marketplace option in pricing page.
Added a custom TextBlock for new design.
This is for stage deployment only.

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] 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] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

👍


[Bug]: Menu button widget - when many menu options are added, no scroll, & the dropdown UI inconvenient to use

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When I add many menu options for a menu button widget, the UI of the dropdown is not convenient for the user, it extends and flows below the visual area.
Also, on Deploy, when we click the Menu button, after the menu items are displayed, when we click the menu button again, the UI moves down, and focus goes to the menu items, instead of the menu getting closed.
Steps To Reproduce

Drag and drop a menu button widget.
Add say 15 - 20 menu options and check the dropdown
It extends and flows below the visual area.
Also, on deploy, the menu dropdown functionality is improper on click to close-  focus goes to the menu items, instead of the menu getting closed.
https://www.loom.com/share/40d22812c22b4532af0c60730308f84d

Public Sample App
No response
Version
Production

@btsgh closing this in favor of #12286, also adding the comments from you on the deploy mode there for tracking.

@dilippitchika  - noted. Thanks


createBlankDynamicLayer defaults for tileWidth and tileHeight are incorrect when tileset argument is an array

Version

Phaser Version: v3.15.1-FB
Operating system: N/A
Browser: N/A

Description
When an array of strings or Tilesets are passed to the tileset argument and either tileWidth or tileHeight are unspecified, they default to 0 instead of the associated map's tileWidth or tileHeight, respectively.
On the one hand, this makes sense - the specified Tilesets may disagree on which tileWidth/tileHeight to use, so of course one would want that explicitly specified.  On the other, since there's no warning message and nothing in the documentation about this case, it can be a pain to debug and figure out what's happening.
Looking at https://github.com/photonstorm/phaser/blob/master/src/tilemaps/Tilemap.js#L466 makes the cause of the behavior apparent.
Example Test Code
function preload() {
  this.load.image('image_a');
  this.load.image('image_b');
}

function create() {
  const tilemap = this.make.tilemap({
    width: 3,
    height: 3,
    tileWidth: 32,
    tileHeight: 32
  });

  const tileset = tilemap.addTilesetImage('image_a', undefined, undefined, undefined, undefined, undefined, 0);
  const tileset2 = tilemap.addTilesetImage('image_b', undefined, undefined, undefined, undefined, undefined, 1);
  const layer = tilemap.createBlankDynamicLayer('background', ['image_a', 'image_b']);
  layer.putTileAt(0, 1, 1);
  layer.putTileAt(1, 2, 2);
}

Additional Information
It'd probably be best to include a warning in createBlankDynamicLayer() for this case, like:
createBlankDynamicLayer: function (name, tileset, x, y, width, height, tileWidth, tileHeight)
{
    if (Array.isArray(tileset) && (tileWidth === undefined || tileHeight === undefined) {
        console.warn('When specifying multiple tilesets, the tileWidth and tileHeight should be explicitly defined.');
    }
    //...
}

Alternately (or additionally), the documentation for createBlankDynamicLayer should be updated to include a note about what happens to tileWidth/tileHeight defaults when the tileset argument is an array.

I've confirmed that this issue appears to be corrected.


[WIP] Topics APIs

This pull request addresses #722 by implementing protocol support for the create/delete topics APIs. It also adds an interface to the cli module that uses these APIs.

Codecov Report

Merging #750 into master will decrease coverage by 0.71%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #750      +/-   ##
==========================================
- Coverage   85.46%   84.74%   -0.72%
==========================================
  Files          27       27
  Lines        3220     3232      +12
  Branches      502      502
==========================================
- Hits         2752     2739      -13
- Misses        343      365      +22
- Partials      125      128       +3

Impacted Files
Coverage Δ

pykafka/protocol.py
95.27% <66.66%> (-0.89%)
:arrow_down:

pykafka/managedbalancedconsumer.py
77.02% <0%> (-7.44%)
:arrow_down:

pykafka/simpleconsumer.py
83.77% <0%> (-2.43%)
:arrow_down:

pykafka/broker.py
92.85% <0%> (-1.3%)
:arrow_down:

pykafka/balancedconsumer.py
93.95% <0%> (-0.31%)
:arrow_down:

pykafka/connection.py
89.36% <0%> (+1.06%)
:arrow_up:

pykafka/cluster.py
72.6% <0%> (+1.3%)
:arrow_up:

pykafka/topic.py
86.17% <0%> (+2.12%)
:arrow_up:

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 fb5bb06...7725edc. Read the comment docs.

It looks like these are the first API requests pykafka is implementing that need to talk to the "controller broker". The controller broker is assigned at the cluster level, and is distinct from the "group coordinator broker", which differs per consumer group. Pykafka currently doesn't include a way to discover the controller broker, so it will need to be added. The ID of the controller broker is returned by v1-5 of the MetadataResponse (at the time of this writing, pykafka only supports v0.

Another option for handling lack of knowledge about the controller broker is to simply send the request to all brokers in the cluster sequentially and handle any error code 41's that occur (error 41 indicates that a request requiring communication with the controller was sent to a non-controller broker).


PP-5256 Added TransactionViewDao

WHAT

Added TransactionViewDao (searchTransactionView()) to support searching for DB transactions

with @SandorArpa

Maybe a bit more detail on what you've done and why? - one line of comment for 850 lines of code seems a bit on the low side 😃

@mrlumbu Was updating comment and is done now

I do think we need to think more about the TransactionView thing, but I'm happy for that to be done in a follow up PR. Let's discuss if it's not clear what I'm on about


Using multi threaded GTK app with Nim and Gintro

I am having an application that have different buttons, each button does 1 job. So with normal way of coding, my code hangs until the callback completes running. I checked on google and i saw something about multi threaded gtk app:

Tutorial (very old tutorial that used gtk 2. Please check sample 3 and 4): http://blog.borovsak.si/2009/06/multi-threaded-gtk-applications.html
Glib g_thread_create (which was used in tutorial): https://developer.gnome.org/glib/stable/glib-Deprecated-Thread-APIs.html#g-thread-create
So i'm having 2 solutions:

Simulate the tutorial but i can't find anything like g-thread-create. this procedure is not found in glib.nim as i used grep (I found threadsInit() and threadsEnter()
Create thread object but it makes problems

Everybody want the code is easy and safe and i afraid this way can't be like that
Each button do 1 different job so i have to create multiple thread object and check instead of using GTK API (like wait for event or something?)

So by creating this issue i want to ask does gintro support multi threaded by GTK and is there any example because i can't find any IP by grepping proc's names

Does gintro 0.7.8 released yesterday work fine for you? Well I got no new issues yet, so maybe there are not too obvious issues?
Multi threaded GTK is difficult indeed. Multi threaded Nim too. I am interested myself in this topic, for my chess game I would like to have a non blocking GUI. And for cairo drawing multiple threads would be nice too. But unfortunately cairo is from design single threaded.
I have not really investigated this topic myself. Well I did some google search of course, there are simple solutions like the gtk idle function. The Nim cairo_anim is a very basic non blocking solution. Investigating this topic would be fun, but my time is too restricted for the next years, the GTK4 and the Nim book have priority, and there are many other tasks for me...
I would propose that you ask on the Nim forum. Or maybe you ask on the GTK forum for C solutions, we should be able to convert it to Nim  then. If you ask on Nim forum, you may ask for the other Nim GUI toolkits for threading as well, maybe some of the other GUIs has a good solution already. I think Nim has more than a dozen GUI toolkits now, I have listed some of them in the GTK4 book already.

Does gintro 0.7.8 released yesterday work fine for you? Well I got no new issues yet, so maybe there are not too obvious issues?

I used gintro 0.7.7. I've upgraded to 0.7.8 and everything is good. It is just this threading issue and it is not very nice.

Multi threaded GTK is difficult indeed. Multi threaded Nim too
Super agree with you. Well my plan is making an application firewall on Linux like opensnitch so a gui is needed and as you see, non-blocking GUI is something I have to think about (for further development). For now the hang is acceptable but i feel it is not good for user's experience.

there are simple solutions like the gtk idle function
So i guess gintro is not supported this by now?

there are simple solutions like the gtk idle function
I asked on telegram channel and there is a solution that i use threading, and timeout_add to check if is running. I think it is acceptable but for more complex software can it be good? If it can, we can write prebuilt function for gintro?

https://developer.gnome.org/gtkmm-tutorial/unstable/sec-multithread-example.html.en
Other example of multi threaded gtk app. Hopefully we can do it with nim

So there is 1 way to do threading but for calling system command only:
https://developer.gnome.org/glib/2.64/glib-Spawning-Processes.html#g-spawn-command-line-async
StackOverflow answer: https://stackoverflow.com/a/7048806
I think it is a good way to start. I'm searching more about this topic.

My test code. It worked perfectly:
import gintro / [gtk, gobject, glib]
import osproc

let command = "ping <IP_ADDRESS> -c 6"

proc onClickIsRun(b: Button) =
  echo "Clicked on test"

proc onClickPingThread(b: Button) =
  if spawnCommandLineAsync(command):
    echo "Done"
    # Must use ChildWatch to get output
  else:
    echo "Failed"

proc onClickPing(b: Button) =
  echo execCmd(command)

proc createArea(boxMainWindow: Box) =
  let
    btnPing = newButton("Ping")
    btnPingThread = newButton("Ping Threads")
    btnIsRunning = newButton("Click to test it is running")
    boxTest = newBox(Orientation.horizontal, 3)

  btnPing.connect("clicked", onClickPing)
  btnPingThread.connect("clicked", onClickPingthread)
  btnIsRunning.connect("clicked", onClickIsRun)
  boxTest.add(btnPing)
  boxTest.add(btnPingThread)
  boxTest.add(btnIsRunning)
  boxMainWindow.add(boxTest)

proc onClickStop(w: Window) =
  #[
    Close program by click on title bar
  ]#
  mainQuit()

proc main =
  #[
    Create new window
    http://blog.borovsak.si/2009/06/multi-threaded-gtk-applications.html
  ]#
  gtk.init()

  let
    mainBoard = newWindow()
    boxMainWindow = newBox(Orientation.vertical, 3)

  mainBoard.title = "Test Threading"

  createArea(boxMainWindow)

  mainBoard.add(boxMainWindow)
  mainBoard.setBorderWidth(3)

  mainBoard.showAll()
  mainBoard.connect("destroy", onClickStop)
  gtk.main()

main()

here is an example to use multi threads in gtk with glib.g_idle_add. I hope you can help me try it on gintro @StefanSalewski
https://stackoverflow.com/a/37009232
binding source of Nim proc idleAdd(priority: int; function: SourceFunc; data: pointer; notify: DestroyNotify): int

here is an example to use multi threads in gtk with glib.g_idle_add. I hope you can help me try it on gintro @StefanSalewski
https://stackoverflow.com/a/37009232
binding source of Nim proc idleAdd(priority: int; function: SourceFunc; data: pointer; notify: DestroyNotify): int

It ran after i added doCheckIP(userData: pointer): gboolean {.cdecl.} to call function. The code is still single thread. The code:
proc doCheckIP(userData: pointer): gboolean {.cdecl.} =
  let ipInfo = checkIPwTorServer()
  var iconName: string

  # If program has error while getting IP address
  if ipInfo[0].startsWith("Error"):
    iconName = "error"
  # If program runs but user didn't connect to tor
  elif ipInfo[0].startsWith("Sorry"):
    iconName = "security-medium"
  # Connected to tor
  else:
    iconName = "security-high"

  sendNotify(ipInfo[0], ipInfo[1], iconName)

proc onClickCheckIP*(b: Button) =
  #[
    Display IP when user click on CheckIP button
    Show the information in system's notification
  ]#

  # doCheckIP()
  # idleAdd ( priority: 0 = default, function?, pointer, notify: DestroyNotify)
  discard glib.idleAdd(0, doCheckIP, nil, nil)

Great that you continued your investigations. I did a short google search myself about that topic, but was not too satisfied with the results yet. I consider the use of the GTK idle functions a bit ugly, it seems to be some sort of polling for results, but maybe that is the only solution that works with GTK. Have still to consider the message passing between thread in Nim, using Channels? I heard ARC would support better ways for thread communication, but I have still to investigate that. But maybe it is enough when we get an ugly but working solution for the start, we can improve it later.

I consider the use of the GTK idle functions a bit ugly

Yes i agree and it didn't work for me.

Have still to consider the message passing between thread in Nim, using Channels?

I tried it before with help from members in Telegram channel. It works. Well the problem is multiple channel and multiple threads. I tried that for creating GUI for ClamAV. The requirement was more complex than the basic syntax of GTK can do.
So my idea is, if we can, we create a pre-built nim lang modules for threading in gtk with some basic check. But idk if it is good and further problems we can have.

Have not yet read all your post carefully sorry, here is a fast hack using GTK3 timeoutAdd() and Nim channels. Nim thread does a countdown, we display that number as label on a button, we can click the button to invert the numbers. Well maybe not really nice, but it is a start, and was really easy. Works with arc, have not jet tested with GTK4.
# nim c --threads:on --gc:arc -r t.nim
# https://nim-lang.org/docs/channels.html

import gintro/[gtk, glib, gobject, gio]
from  os import sleep

var chan: Channel[int]
var worker: system.Thread[void]

proc work() =
  var countdown {.global.} = 25
  while countdown > 0:
    sleep(1000)
    dec(countdown)
    chan.send(countdown)

proc invalidateCb(b: Button): bool =
  let tried = chan.tryRecv()
  if tried.dataAvailable:
    #echo tried.msg
    b.label = $tried.msg
    if tried.msg == 0:
      worker.joinThread
      chan.close
      return SOURCE_REMOVE
  return SOURCE_CONTINUE

proc buttonClicked (button: Button) =
  button.label = utf8Strreverse(button.label, -1)

proc appActivate (app: Application) =
  let window = newApplicationWindow(app)
  window.title = "Countdown"
  window.defaultSize = (250, 50)
  let button = newButton("Click Me")
  window.add(button)
  button.connect("clicked",  buttonClicked)
  window.showAll
  chan.open
  createThread(worker, work)
  discard timeoutAdd(1000 div 60, invalidateCb, button)

proc main =
  let app = newApplication("org.gtk.example")
  connect(app, "activate", appActivate)
  discard app.run

main()

The gtkmm example from
https://developer.gnome.org/gtkmm-tutorial/unstable/sec-multithread-example.html.en
is indeed interesting, it seems to not need something like timeout_add().
But I think you can do all what you need following my example. The same principle should work with multiple threads and multiple channels. The idea is to pass data between treads over Nim channels and to use the iddleAdd() function to receive the data and to display them. You should be able to add buttons for starting or terminating threads. Maybe the most difficult part is to terminate a background process before it is finished, i.e. to terminate a chess engine when time limit is reached. We may need something like semaphores and global variables for that, you may ask in IRC or Nim forum.

And here is a solution with g_idle_add():
# nim c --threads:on --gc:arc -r t.nim
import gintro/[gtk, glib, gobject, gio]
from  os import sleep

var worker: system.Thread[void]
var button: Button

proc idleFunc(i: int): bool =
  button.label = $i
  return SOURCE_REMOVE

proc work() =
  var countdown {.global.} = 25
  while countdown > 0:
    sleep(1000)
    dec(countdown)
    idleAdd(idleFunc, countdown)

proc buttonClicked (button: Button) =
  button.label = utf8Strreverse(button.label, -1)

proc appActivate (app: Application) =
  let window = newApplicationWindow(app)
  window.title = "Countdown"
  window.defaultSize = (250, 50)
  button = newButton("Click Me")
  window.add(button)
  button.connect("clicked",  buttonClicked)
  window.showAll
  createThread(worker, work)

proc main =
  let app = newApplication("org.gtk.example")
  connect(app, "activate", appActivate)
  discard app.run

main()

E. Bassi recommends use of GTask but we have to investigate how it can be used with Nim, see
https://discourse.gnome.org/t/gtk-background-threads/3817/6

And here is a solution with g_idle_add():
# nim c --threads:on --gc:arc -r t.nim
import gintro/[gtk, glib, gobject, gio]
from  os import sleep

var worker: system.Thread[void]
var button: Button

proc idleFunc(i: int): bool =
  button.label = $i
  return SOURCE_REMOVE

proc work() =
  var countdown {.global.} = 25
  while countdown > 0:
    sleep(1000)
    dec(countdown)
    idleAdd(idleFunc, countdown)

proc buttonClicked (button: Button) =
  button.label = utf8Strreverse(button.label, -1)

proc appActivate (app: Application) =
  let window = newApplicationWindow(app)
  window.title = "Countdown"
  window.defaultSize = (250, 50)
  button = newButton("Click Me")
  window.add(button)
  button.connect("clicked",  buttonClicked)
  window.showAll
  createThread(worker, work)

proc main =
  let app = newApplication("org.gtk.example")
  connect(app, "activate", appActivate)
  discard app.run

main()

E. Bassi recommends use of GTask but we have to investigate how it can be used with Nim, see
https://discourse.gnome.org/t/gtk-background-threads/3817/6

Thank you. I'm trying to understand it then trigger the worker (or idleAdd) after button is clicked.

Well i still don't know how to use it on my code right now but as far as i'm understand:

createThread make a background thread
idleAdd is a method to "communicate" between the worker thread and main thread.
I have some idea but i have to test it.

Yes, threading is never easy. I have still no idea how to do it for my chess game, I would use some bidirectional message passing and a way to stop the engine when it is deep in the tree of possible moves. I may try it in winter.
The key concept of idleAdd() or timeoutAdd() is that the GTK GUI is not directly updated from the second thread, but by a function that is executed in the main thread. You can investigate the Nim Channel module for threading and message passing. I have also added a section to the README:
http://ssalewski.de/gintroreadme.html#_threading_examples

@StefanSalewski i'm having this error
/home/dmknght/ParrotProjects/anonsurf/src/gui/actions/toolbar.nim(32, 10) template/generic instantiation of `idleAdd` from here
/usr/lib/nim/core/macros.nim(579, 69) Error: expression cannot be cast to pointer```
Is your idleAdd from glib or other module? i'm using gintro#head

Nevermind. I completed the code without using idleAdd. The code works fine.

idleAdd() and timoutAdd() are macros in gintro, the macro then calls the glib g_idle_add(). Macro is needed because of the different calling conventions, g_idle_add() wants to call a function with cdecl calling convention, but our Nim functions generally use nimcall, and we do not want to force the user to mark his user function with cdecl pragma. So we use some sort of trampoline function, that trampoline function is generated by the macro.
grep -A40 idleAdd ~/.nimble/pkgs/gintro-#head/gintro/gimpl.nim
macro idleAdd*(p: untyped; arg: typed): untyped =
  var IdleID {.compileTime, global.}: int
  inc(IdleID)
  let ats = $getTypeInst(arg).toStrLit
  let procName = "idlefunc_" & $IdleID
  let procNameCdecl = "idlefunc_cdecl_" & $IdleID
  var r1s = """
proc $1(p: pointer): gboolean {.cdecl.} =
  let a = cast[$3](p)
  result = $2(a).gboolean
  #when (a is ref object) or (a is seq):
  #GC_unref(a)
""" % [$procNameCdecl, $p, ats]

  let r2s ="""
proc $1(a: $2): culong {.discardable.} =
  when (a is ref object) or (a is seq):
    GC_ref(a)
    return g_idle_add_full(PRIORITY_DEFAULT_IDLE, $3, cast[pointer](a), nil)
  else:
    var ar: ref $2
    new(ar)
    #deepCopy(ar[], a)
    ar[] = a
    GC_ref(ar)
    return g_idle_add_full(PRIORITY_DEFAULT_IDLE, $3, cast[pointer](ar[]), nil)
$1($4)
""" % [$procName, ats, $procNameCdecl, $arg]
  result = parseStmt(r1s & r2s)

I use the same syntax for idleAdd from your code and it give me error so i give up and use threading without idleAdd. Can example of mine using spawnCommandLineAsync be added in gintro examples? I think it is useful for everybody want to check syntax.

proc doCheckIP(ipInfo: array[2, string]): bool =

Maybe your problem with idleAdd() is that your doCheckIP() function has an array as parameter. I think I never tested with arrays. Maybe it would work when you use an object with two string fields?

Can example of mine using spawnCommandLineAsync be added in gintro examples?

This one?
https://github.com/StefanSalewski/gintro/issues/81#issuecomment-658307309
Yes I can add it to the example directory, but it is not very interesting as you do no communication with the background thread, you only call blocking execCmd() and non blocking spawnCommandLineAsync(). Unfortunately your onClickIsRun() proc is a plain echo, it does not really test if the background process is running.
But well maybe for a plain command launcher tool your example is useful, so I will add it to examples. But I think I will not add  it to the README, as it is not too interesting.

Indeed I wonder if it is a good idea to use spawnCommandLineAsync() from glib at all. Does Nim not provide similar functions? Like startProcess() from osproc module? Well I never have used that one, but generally we use what is provided by Nim std lib and only fall back to external libs when necessary. (Similar for string processing, we generally use Nim strutils and not what is provided by glib.)
Maybe you can check osproc.startprocess() and tell us why it is inferior to glib.spawnCommandLineAsync.

Maybe your problem with idleAdd() is that your doCheckIP() function has an array as parameter. I think I never tested with arrays. Maybe it would work when you use an object with two string fields?

Well i think that is problem of extracting arguments maybe. It is like the connect button (i think i opened an issue about it and the solution is use an object). But i decided using Thread without idleAdd(). The code structure is similar and it works fine.

it does not really test if the background process is running.
Well it only shows output in terminal. Maybe i can do more complex example but idk if it worthy

Does Nim not provide similar functions?
Nim has functions but the spawnCommandLineAsync() spawns a background process without hanging the GUI just like threading and from the result you don't have to care about creating thread object managing it and join it. You also don't have to provide --threads flag when you compile it. It is a native gtk thing as i call.

My new problem: Turned out the worker.join is not a good idea because it crashes application after function works.
I changed array[2, string] to an object and i still have template/generic instantiation of idleAdd from here error

More information: The location from gobject that output error pointed
proc toggleNotify*(data: pointer; obj: ptr Object00; isLastRef: gboolean) {.cdecl.} =
  if isLastRef.int == 0:
    GC_ref(cast[RootRef](data)) # --> This line caused crash. L123
  else:
    GC_unref(cast[RootRef](data))

My new problem: Turned out the worker.join is not a good idea because it crashes application after function works.

I think the reason is i call gtk notification inside threading. Well, the logic of how it work is good but do the actual code with threading is crazy

You told us that spawnCommandLineAsync() was working fine for you, so I have not further investigated idleAdd() macro. That macro is simple, so expanding it for other data types should be not that hard.
Have just tested with an ref object, that compiles, but seems to work only with ARC without crash. I am not really surprised, the default GC has problems with data shared between threads.
# nim c --threads:on --gc:arc -r thread2.nim

import gintro/[gtk, glib, gobject, gio]
from  os import sleep

type
  TwoStr = ref object
    s1, s2: string

var workThread: system.Thread[void]
var button: Button

proc idleFunc(x: TwoStr): bool =
  button.label = x.s1 & x.s2
  return SOURCE_REMOVE

proc workProc =
  var countdown {.global.} = 25
  var x {.threadvar.}: TwoStr
  if x == nil:
    x = TwoStr(s1: "Nim", s2: "Rust")
  while countdown > 0:
    sleep(1000)
    dec(countdown)
    idleAdd(idleFunc, x)

proc buttonClicked(button: Button) =
  button.label = utf8Strreverse(button.label, -1)

proc activate(app: Application) =
  let window = newApplicationWindow(app)
  window.title = "Countdown"
  window.defaultSize = (250, 50)
  button = newButton("Click Me")
  window.add(button)
  button.connect("clicked",  buttonClicked)
  window.showAll
  createThread(workThread, workProc)

proc main =
  let app = newApplication("org.gtk.example")
  connect(app, "activate", activate)
  discard app.run

main()

Compile with
nim c --threads:on --gc:arc thread2.nim

I am not sure if passing strings between threads works at all with the default GC.
Unfortunately I do not know much about threading in Nim. And I have still to investigate the GTask suggestion of Mr Bassi, I am not sure if GTask will work at all for Nim code that contains GC instructions.
Generally you should try to always compile with gc:arc as that is deterministic, you get a crash earlier if something is wrong. The default GC may take long to crash, which is bad for testing.
About all your other problems, it is hard to guess without having the full code.
Maybe you should ask on the forum, there are some people with some GTK and good threading knowledge.

the default GC has problems with data shared between threads.

I solved this by using Channel. The idea is using gtk notification to pop information up so it has to be run after thread is completed. So i have to show notification in timeoutAdd()
My code
var
  worker*: system.Thread[void]
  channel*: Channel[MyIP]

channel.open()

proc doCheckIP() =
  var finalResult: MyIP
  let ipInfo = checkIPFromTorServer()
  # If program has error while getting IP address
  if ipInfo[0].startsWith("Error"):
    finalResult.iconName = "error"
  # If program runs but user didn't connect to tor
  elif ipInfo[0].startsWith("Sorry"):
    finalResult.iconName = "security-medium"
  # Connected to tor
  else:
    finalResult.iconName = "security-high"

  finalResult.isUnderTor = ipInfo[0]
  finalResult.thisAddr = ipInfo[1]
  channel.send(finalResult) # Crash second time

proc onClickCheckIP*(b: Button) =
  #[
    Display IP when user click on CheckIP button
    Show the information in system's notification
  ]#
  sendNotify("My IP", "Getting data from server", "dialog-information")
  createThread(worker, doCheckIP)

And then in the function that is called by timeoutAdd() i do something like this:
If channel.dataAvailable`:
  showPopup()

The key here is not closing the channel so program won't crash if user click on button 2nd time.


Set correct shebangs

@charlierudolph @allewun
Fixes the last remaining incorrect shebangs

Is there a reason why the shell overrides are kept as #!/bin/bash ?

Ha, no, I just forgot them. Fixed

:ship:

:ship:


Wrap SendQueued in WebGL ifdef

This resolves the final missing definition (https://github.com/Unity-Technologies/com.unity.multiplayer.mlapi/pull/724#issuecomment-816990650).

 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.

@yeOldeNoob Just needs CLA signage!

@yeOldeNoob any chance this can be merged soon? Looks like you need to accept the CLA.


Support pixi search "numpy>2.0" i.e. package names with version requirements

Problem description
micromamba search already supports this but currently pixi does not:
$ pixi search "numpy>=2.2"
Using channels: conda-forge
  × 'numpy>=2.2' is not a valid package name. Package names can only contain 0-9, a-z, A-Z, -, _, or .

Yes @deephbz, we'd are interested in that feature as well!
@wolfv had a draft PR for this at some point, but we didn't finish it up: https://github.com/prefix-dev/pixi/pull/2390


test(e2e): introduce cypress e2e testing

Related Ticket(s)
No related issue
Description
After our website outage, this will hopefully introduce better checks to ensure that we are notified of any rendering issues on the website. This will run e2e tests (homepage for now) on PRs, and also will run on a cron ever 2 hours on the prod environment.
Changelog
New

Cypress test harness
Workflow to run Cypress e2e tests on pull requests
Workflow to run e2e tests on the prod environment every 2 hours

it looks like there are some lockfile conflicts

Yup I noticed that, I'm going a reset locally and will push up the changes!


Support for CacheCluster resource

Issue #, if available: https://github.com/aws-controllers-k8s/community/issues/2079
Description of changes:
This changelist adds support for the ElastiCache CacheCluster resource. The generated code did not account for many fields in the call to ModifyCacheCluster, and the DescribeCacheClusters API does not return all fields in the spec and values for some fields are reported in the PendingModifiedValues field instead. To handle this, the last requested configuration for Spec.PreferredAvailabilityZones is stored as annotations and used to compute NewAvailabilityZones. Moreover, CacheNodeIdsToRemove is computed using Spec.NumCacheNodes and PendingModifiedValues.NumCacheNodes. Support for Spec.LogDeliveryConfigurations is explicitly removed and parked for later because the Describe API does not return all fields for this struct. There were many changes to other ElastiCache resources introduced in the newer SDK, so they have been removed for now and not ignored. As a result, a subsequent make build-controller will result in new changes.
The logic for syncing tags and comparing engine versions has been refactored to promote reusability.
Closes https://github.com/aws-controllers-k8s/community/issues/2079.
Signed-off-by: cPu1<EMAIL_ADDRESS>By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/ok-to-test

/test all


Parameter sweep with Quandary

There is a sample Slurm script here: https://github.com/LLNL/quandary/blob/master/util/slurm_script.
How should it be modified to do parameter sweep over configuration options?
SLURM_PROCID can be useful as a variable for the sweep. How should it be used in .cfg files?
Let’s say we have a list of “transfreq” to be used in each .cfg file:
transfreq_1 = 4416.66, 6840.815
transfreq_2 = 4500.66, 6900.815
transfreq_3 = 4700.66, 7000.81

There are 3 in this example but many will be needed. We can combine them into a single array (format may vary), such as
transfreq_array = [[4416.66, 6840.815], [4500.66, 6900.815], [4700.66, 7000.815]],
and use SLURM_PROCID for each instance.
What is the correct format for such arrays to be used in .cfg files of Quandary jobs?
Is it possible/recommended to use a single .cfg file for the parameter sweep? Or should we use a separate .cfg file for each set of configuration parameters?

When Quandary parses the .cfg file, it looks for "transfeq" and expects a list of transition frequencies per oscillator. It throws an error if the list is not in this format (list with Q elements, Q being the number of oscillators).
When sweeping over parameters, you could modify the python script https://github.com/LLNL/quandary/blob/master/util/submit_scalingstudy.py for your needs (I've tried it with Python2 only). You can choose the parameters to sweep over, and it will generate separate .cfg files for each case in separate folders, as well as a slurm script to submit a job for it.

I saw the python script. Thanks for updating it.


TypeError: cannot concatenate 'str' and 'NoneType' objects

I'm a Chinese, and my system language is ZH_cn. So microblog went wrong to get best matched language. Full Traceback is behind:
TypeError: cannot concatenate 'str' and 'NoneType' objects
<IP_ADDRESS> - - [28/Jan/2014 17:34:20] "GET /login?__debugger__=yes&cmd=resource&f=style.css HTTP/1.1" 200 -
<IP_ADDRESS> - - [28/Jan/2014 17:34:20] "GET /login?__debugger__=yes&cmd=resource&f=jquery.js HTTP/1.1" 200 -
<IP_ADDRESS> - - [28/Jan/2014 17:34:20] "GET /login?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 200 -
<IP_ADDRESS> - - [28/Jan/2014 17:34:20] "GET /login?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
<IP_ADDRESS> - - [28/Jan/2014 17:34:20] "GET /login?__debugger__=yes&cmd=resource&f=source.png HTTP/1.1" 200 -
<IP_ADDRESS> - - [28/Jan/2014 17:34:20] "GET /login?__debugger__=yes&cmd=resource&f=ubuntu.ttf HTTP/1.1" 200 -

I found this works:
view.py:
@babel.localeselector
def get_locale():
    return request.accept_languages.best_match(LANGUAGES.keys())

change to >>
    return request.accept_languages.best_match(LANGUAGES.keys()) or 'en'

But I don't know is it a good way or not.

Closing this issue, as it does not apply anymore.


A Calculator Feature

This calculator cog converts a infix(Normal) math expression to a postfix math expression. Then the postfix expression is parsed and the result is returned.

python conventions state that module names (the file name) need to be snake case, so in this case it should calculator.py

also resolves #65


Add react/no-redundant-should-component-update

This will check for shouldComponentUpdate defined in a class that extends React.PureComponent.
In regards to the name: I went with what is in the proposal, but perhaps something more informative can be found. Also, I realized that the functions dealing with component properties are duplicated in a few spots, but since there were some differences, I figured they could be refactored out at some other point. That's ultimately up to the reviewers, though.
This PR implements the rule proposed in #985.

I think "redundant" might be more specific than "useless". What do folks think?
Also, I'm not sure if we should abbreviate shouldComponentUpdate as scu. I think it might be best if the rule was named react/no-redundant-should-component-update.

I agree with @lencioni's naming comments.

I've updated the code based on the feedback given. I'll squash at the end after everything checks out.

@jomasti what do you think about my v14/v13/v15.0/v15.1 question?

@ljharb It makes sense. Would you expect a test with settings for a lower version? All I can think of would be using the syntax with a lower version and having it not catch the error. It doesn't seem useful, though.

@jomasti hm, that's a fair point - considering it'd just "do nothing" in a React where PureComponent also does nothing, it's probably not worth doing.

I'll merge this tomorrow if there's no objections.


Exclude Normals from Training

Hello,
thank you for your nice work! I am using your Model for a Training with my own Dataset. But i dont have any Informationen in my dataset about the normals.
How can i exclude the normals in the training.
When i set read_file = ReadFile(has_normal=False, has_color=True, has_label=True) in scannet.py line 222 to False i receive a key Error saying KeyError: 'normals'
Thank your for your help
Best
Moritz

I suspect that the error Key Error: 'normals' comes from the following line of code.  You should modify source codes that use normals accordingly, if the normals are not read from data.
https://github.com/octree-nn/octformer/blob/41957017fb04977dcca4b6b2fa5a936b0781c0b6/datasets/scannet.py#L148