[sdk] class called "Function" does not conform to the spec.

The Dart SDK introduces new syntax in its core library by shipping a class called "Function". "Function" is not a valid type identifier and so, according to the specification, a class can't be named "Function". The conformance section in the spec explicitly disallows new syntax.
Furthermore, the analyzer parses classes with a "Function" name without syntax errors, while the ANTLR-based spec, as expected, emits an error for the following program:
class Function {}

 === Analyzer ===
Scan errors: 0
Parse errors: 0
<CompilationUnitImpl> [0-17]
┗━ <ClassDeclarationImpl> [0-17]
  ┣━ 'class' [0-5]
  ┣━ 'Function' [6-14]
  ┣━ '{' [15-16]
  ┗━ '}' [16-17]
--------------------------------------------------------------------------------
 === ANTLR ===
Errors of type 1: [[@1,6:13='Function',<94>,1:6], [@1,6:13='Function',<94>,1:6], [@2,15:15='{',<139>,1:15], [@2,15:15='{',<139>,1:15]]
Errors of type 2: []
<startSymbol>
┗━ <libraryDefinition>
  ┣━ <metadata>
  ┣━ <topLevelDefinition>
  ┃  ┗━ <classDeclaration>
  ┣━ <metadata>
  ┣━ <topLevelDefinition>
  ┃  ┗━ <classDeclaration>
  ┃    ┗━ 'class'
  ┣━ <metadata>
  ┣━ <topLevelDefinition>
  ┣━ <metadata>
  ┣━ <topLevelDefinition>
  ┃  ┣━ 'Function'
  ┃  ┣━ '{'
  ┃  ┗━ '}'
  ┗━ '<EOF>'

It seems to me that this "hack" exists for UX-related reasons (to e.g. allow the "Go to implementation" feature in IDEs to resolve to an actual "thing" instead of making "Function" act like a keyword-like construct).
void main() {
//   ,--- "go to implementation" redirects to a real class with useful comments.
//   v
  Function fn;
}

I think that this is helpful, but I also think that conforming to the spec without such "hacks" would also be good.
(This "hack" seems intentional and there's probably nothing surprising here. I just couldn't find an issue that captures this exact observation.)
Cf. https://github.com/dart-lang/sdk/issues/45703 which seems to have dealt with disallowing users from defining custom classes called "Function" (but the SDK still ships new syntax that doesn't conform to the spec).

I'd say that this is all specified and working as intended.
Checking the programs in https://github.com/dart-lang/sdk/issues/45703, every attempt made in those programs to declare a type named Function is detected and rejected as a compile-time error, by the analyzer as well as the CFE. This is consistent with the fact that Function is specified to be a built-in identifier.
It is not a problem that there is a declaration in a platform library that introduces a type named Function. Platform libraries can break arbitrary rules, in the sense that (1) they are not the specification, they just need to implement it, and (2) tools can give any part of the code in such libraries a special treatment. For instance, they can choose to accept one specific class declaration named Function, because that's needed in order to be able to compile code like Function f = print; correctly in user-written code.
Platform libraries break rules in many other cases. For instance, the number classes num/int/double may have a variety of subtypes, depending on the platform, even though that is specifically an error according to the specification; int has an external const factory int.fromEnvironment constructor (external const factory is not a thing, otherwise); FutureOr has very, very special subtyping properties that you can't specify for any class written in Dart as specified; and so on and so on.

Furthermore, the analyzer parses classes with a "Function" name without syntax errors

This is also not a problem: Any tool can re-categorize a syntax error to be a compile-time error that isn't a syntax error, which might be done in practice because that turns out to be a useful implementation. This typically occurs because it is easier to get good error recovery from a parser which is broader than the specified grammar indicates (so we're reporting fewer things as syntax errors, thus accepting more programs), as long as the texts that are syntax errors according to the grammar will then be rejected with some other compile-time error.
So it's OK for the analyzer parser to parse class Function {} and report a (non-syntax) compile-time error stating that the name of the class cannot be Function.

Note: The issue description contains an incorrect link to the Function interface. The link refers to a Function "patch" the actual interface that users are exposed to is here function.dart.

For instance, the number classes num/int/double may have a variety of subtypes, depending on the platform, even though that is specifically an error according to the specification;

The SDK appears to try very hard to hide this fact from users via its "patch" mechanism. The Function declaration is not hidden from users in any way. If they "go to implementation" they are exposed to a declaration that is not valid Dart syntax and according to the spec, extending syntax is not allowed.
Do you consider the declarations (including any interfaces) in dart:core (before any patches have been applied) to be platform libraries and so they can deviate from the spec?

int has an external const factory int.fromEnvironment constructor (external const factory is not a thing

The grammar snippets in the spec contain the following productions:

⟨declaration⟩ ::= external ⟨factoryConstructorSignature⟩
⟨factoryConstructorSignature⟩ ::=
const? factory ⟨constructorName⟩ ⟨formalParameterList⟩

and they can be used to derive "external const factory ..."
Furthermore, the spec says:

An external function may be a top-level function (19), a method (10.2, 10.8), a getter (10.3), a setter (10.4), or a non-redirecting constructor (10.7.1, 10.7.2).

and external const factory int.fromEnvironment(String name, {int defaultValue = 0}); seems to be allowed because it is a non-redirecting constructor (10.7.2 Factories).
In what way is external const factory not a thing?

FutureOr has very, very special subtyping properties that you can't specify for any class written in Dart as specified;

FutureOr is mentioned explicitly by the deprecated subtyping specification (and the spec). It doesn't look like the specification says anything about FutureOr that the implementation disagrees with.

I've also noticed that Section 3, Normative References refers to the following link: https://api.dartlang.org/ which contains https://api.dart.dev/stable/3.0.3/dart-core/Function-class.html. So the spec depends on an API reference that contains a class that introduces new syntax due to implementation specific behavior? That doesn't seem to intentional.

This is also not a problem: Any tool can re-categorize a syntax error to be a compile-time error,

Thank you, I agree. It would be nice if the analyzer could report issues like that as syntax errors, but of course, it doesn't have to.

Do you consider the declarations (including any interfaces) in dart:core (before any patches have been applied) to be platform libraries and so they can deviate from the spec?

Certainly, yes. That's also consistent with the use of the term 'system library' that the language specification uses (we have used 'platform library' in many discussions, but the correct term according to the spec is 'system library', so I should have said 'system library' whenever I said 'platform library'). In any case, a system library does not exist in order to demonstrate spec compliant code, it exists in order to support the implementation of a set of Dart processing tools.
Dart the language has a number of atomic elements (entities that cannot be expressed in Dart and hence are pre-defined), and they need to be provided by an implementation of Dart. If that's convenient to do by having a declaration like class Function {...} in some system library that would have been rejected as a compile-time error, except that the analyzer/compiler/other_tools "know" this declaration and give it exceptional treatment, then so be it.
It is simply not useful to insist that system libraries cannot contain code which is given exceptional treatment by the tools (in particular, the code can be a compile-time error according to the specification, or the code could behave in a completely different way according to the specification). The reason why such code exists is exactly that some elements of Dart cannot be written in Dart (as is true for every language except the untyped lambda calculus).

[we can] derive "external const factory ..."

That is true, but you can also derive covariant int i as a <normalFormalParameter> of a top-level function, and that is still an error. This means that it doesn't say much that the syntax can be derived.
The external const factory is actually an interesting example, because the mechanism whereby an external declaration is bound to an actual foreign function is implementation specific. (Haha, caught myself on the wrong foot there! ;-)
However, the support for the fromEnvironment and hasEnvironment constructors exists on all configurations (as far as I know), which makes them similar to a mechanism which is part of the language itself.
That said, I doubt that any tool will support external const factory for anything other than those very special cases, because there's a semantic clash between binding a constructor to an unknown piece of foreign code, and at the same time promising that the returned result will be constant.

It doesn't look like the specification says anything about FutureOr that the implementation disagrees with.

The syntax that introduces the identifier FutureOr into the scope of 'dart:async' is a class declaration. The specification specifies all subtyping relationships of every possible class declaration in Dart that isn't an error. But the subtyping properties of FutureOr<T> for any given T are completely different than the subtyping properties of a FutureOr class that you create by copying the source code from 'dart:async', character for character.
This is so because the analyzer/compiler/... are treating the FutureOr declaration in 'dart:async' in a way which does not conform to the specification of that piece of syntax.
So we're violating the rules of Dart when compiling/analyzing 'dart:async' just because that declaration of FutureOr as a class, plus any number of special-casing parts of the tools, are a useful way to ensure that FutureOr is in scope in a Dart library that imports 'dart:async', and that it behaves as specified. In particular, anyone who uses FutureOr in their code does not need to know that this feature relies on having a class declaration which is "compiled and analyzed incorrectly".

So the spec depends on an API reference that contains a class that introduces new syntax due to implementation specific behavior?

The spec refers to the documentation of the 'built-in class Function'. An implementation is free to ignore the source code of 'dart:core' and implement all of Dart manually (more work, but possible). So in that sense there is no necessary connection between (1) the spec and this reference to the documentation of Function and (2) the actual source code that breaks the rules and declares a class named Function.
In short, you can read the actual source code in system libraries, but it doesn't tell you anything because any tool could presumably give any part of it an exceptional treatment, as long as they implement Dart in a conforming way.

Thank you for the clarification and taking the time to provide a detailed explanation.
I agree with your reasoning here and this seems to be working as intended, so I'm going to close this issue.

Another symptom of this hack can be found in the following program:
@Function.id()library;

Which is parsed by the analyzer without any errors, but rejected by DSP as a syntax error.
 === pkg:analyzer (https://pub.dev/packages/analyzer) ===
Parsing succeeded with no errors.
Scan errors: 0
Parse errors: 0
<CompilationUnitImpl> [0-22]
┗━ <LibraryDirectiveImpl> [0-22]
  ┣━ <AnnotationImpl> [0-14]
  ┃  ┣━ '@' [0-1]
  ┃  ┣━ <PrefixedIdentifierImpl> [1-12]
  ┃  ┃  ┣━ <SimpleIdentifierImpl> [1-9]
  ┃  ┃  ┃  ┗━ 'Function' [1-9]
  ┃  ┃  ┣━ '.' [9-10]
  ┃  ┃  ┗━ <SimpleIdentifierImpl> [10-12]
  ┃  ┃    ┗━ 'id' [10-12]
  ┃  ┗━ <ArgumentListImpl> [12-14]
  ┃    ┣━ '(' [12-13]
  ┃    ┗━ ')' [13-14]
  ┣━ 'library' [14-21]
  ┗━ ';' [21-22]
--------------------------------------------------------------------------------
 === DSP (https://github.com/dart-lang/sdk/blob/master/tools/spec_parser/dart_spec_parser/Dart.g4) dspVersion v0.41 ===
Parsing failed with some errors:
Errors of type 1: [[@2,9:9='.',<11>,1:9] Bad state: ]
Errors of type 2: []
<startSymbol>
┣━ '@'
┣━ 'Function'
┣━ '.'
┣━ 'id'
┣━ '('
┣━ ')'
┣━ 'library'
┗━ ';'

@Function.id()library; is a syntax error in the DSP, but not a syntax error in the analyzer as it rejects programs like that in a later phase.
I think it would be nice to try to keep the analyzer and DSP in-sync with respect to syntax errors to make it easier to maintain consistency across different artifacts.

@eernstg First of all, my goal is to prevent us from having to observe accidents like the following:

Perl Cannot Be Parsed: A Formal Proof
Parsing C++ is literally undecidable

I would like to see the language team be the ultimate authority on what is valid Dart syntax because they should know best how to prevent Dart from having undesirable properties.

I'm currently observing the following:

the system libraries are not specified by the spec, they are specified by the libraries that come with the SDK.

essentially, the SDK employs two different grammars: system-dart and user-dart.

Libraries that ship with the SDK are expected to adhere to system-dart (which has no specification).
User code is expected to adhere to user-dart (which is specified by the language team).
Erik, I want to be clear that I do not think that the spec should start dealing with error recovery. Consider the following example which is a program where no error recovery is needed, e.g.:
void main() {
  Function.apply(() => 0, []);
}

Any implementation (or IDE, or static analyzer, or any other tool that attempts to resolve Dart programs) needs to be able to parse system-dart and user-dart because they need the system libraries to know that Function has a static function called apply.
In practice, any desirable language properties that the language team is able to guarantee for user-dart are thrown out of the window (from the perspective of a tool author) if system-dart is able to do whatever it wants to.
So I guess what I'd like to see is have system-dart be == user-dart.
Are there perhaps any issues that I'm not anticipating with having system libraries be required not to extend the syntax specified by the spec?

I may have been a little ambiguous about the perspective that I am looking at this from. @eernstg You have rightfully assumed a broader view than I intended. My statements were only meant to comment on the fact that system libraries are free to make syntactic exceptions. I don't worry about any differences or exceptions related to, e.g., resolution, type inference or type checking.
It seems to me that what I'm proposing, a unified grammar for user libraries and system libraries, is not something that is incompatible with the constraints that you've provided, or any other constraint that I can think of.
I can't quite pinpoint the exact cause of our disagreement here, so how about a more concrete proposal for the changes that I would like to see:

To allow system libraries to ship classes named Function:

classDeclaration
    :    (classModifiers | mixinClassModifiers)
//                                   new:
//                                   vvvvvvvv
         CLASS (typeWithParameters | FUNCTION) superclass? interfaces?
         LBRACE (metadata classMemberDeclaration)* RBRACE
    |    classModifiers CLASS mixinApplicationClass
    ;

To prevent user libraries from declaring classes named Function.

It is a compile-time error for non system libraries to declare a classDeclaration named 'Function'.

Commentary:
The support for classes named 'Function' is there to allow implementations to deliver a class named 'Function' that can be used to, for example, support a go-to-declaration feature on Function types.

To ensure that no library is able to add custom syntax.

Dart libraries may not support syntax that is not specified by the specification.

Commentary:
This restriction is meant to prevent changes to Dart's syntax that could accidentally change the property-profile of Dart's syntactical language in detrimental ways.

Should the need for custom syntax in system libraries come up, then that syntax would have to become part of the spec, and be reviewed by the language team.
What do you think?

While we try to make platform libraries be written in Dart, nothing requires them to be.
It's just convenient, because we have way to execute Dart code already, and a way to gather documentation from Dart code, and most of the time the source code is a good representation of what the library feature actually does.
There are exceptions. Not many, but not zero.

The FutureOr class declaration. I was introduced originally just to make pre-Dart 2.0 code not crash when it saw a FutureOr type, and was considered a good place to hang documentation from. It has never been the source of truth for the FutureOr type which is exported by dart:async, it's just a placeholder that all compilers know to ignore.
The Function class. May actually be the real declaration of the Function type exported by dart:core, or it may not. You can't tell the difference because you can't use it as a class anyway (extend, implement, mix in, subtype at all, or instantiate). But it's a good place to hang the apply function, and documentation. so it stays. Even if it uses a name that nobody else may use.
The Null class in the dart:core source may or may not be the declaration of the Null type exported by dart:core. If it is, it's as special as class Object in that neither has a superclass, and the typing rules treat it very specially. In either case, user code can't tell the difference.
The Never name and type is from dart:core without any source declaration.
The dynamic name and type is exported from dart:core without any source declaration.

Those are the major places where source declaration does not (necessarily) match what is actually being exported.
The dynamic and Never types are so far from being class types that we never tried to have a placeholder declaration,
but we should find a way to export documentation for them anyway. They are names exported by dart:core.
FutureOr probably shouldn't be a class either.

About:

Dart libraries may not support syntax that is not specified by the specification.

Saying that is useless.
If a file contains something that is not allowed by the Dart specification, it is by definition not a Dart file.
So it's not a Dart library, so it's not bound by that restriction. Catch 22!
A language specification defines a set of valid Dart programs.
Any input which causes a parsing error or any static error specified by the language specification is not a valid Dart program.
(Or if it fails in an undescribed way, like a file just not existing, which I don't think we actually call out, because we don't say how to go from URI to source code),
Then the language specification defines a runtime semantics for valid Dart programs.
Anything outside of that is just not Dart, and therefore not something the Dart specification has any mandate over.

@lrhn, I think the topic here is slightly different: The question is whether or not it's OK to have a declaration like
class Function ... {...}

in the SDK, given that Function is a built-in identifier and hence it cannot be the name of a type declaration (such as a class declaration). In any user-written library this declaration would simply be a compile-time error, so why is it OK to have it in a system library? Similarly, how does the class Object manage to avoid having a superclass?
My response is that there is no obligation for a system library to satisfy all the rules of Dart. In fact, every tool in the tool chain associated with this SDK can give an exceptional (that is, rule breaking) treatment for any single declaration in the SDK, if needed. In fact, nobody promises us that there even is any Dart source code that is used to provide the services expected from the system by any Dart library. For example, nobody promises us that Function or Object even have a declaration, they might as well have been established outside the Dart language (just like the runtime is written in C++, but Dart programs interact with the runtime all the time).
The implication is that no tools can immediately be expected to work on Dart system libraries, just because they are working on all non-system Dart libraries: they may need to give a bunch of system library declarations special treatment. That special treatment isn't specified in any language specification documents, because they are concerned with the meaning of non-system libraries. However, the language specification documents do specify how entities like the classes Object and Function behave semantically, and how they can be used from non-system libraries, they just don't specify how the particular source code text that declares Object and Function manage to have that meaning.
@modulovalue, if you think I've misrepresented the discussion then please add in your perspective as needed!

I'll close this issue: We do not plan to require every library in the SDK to conform to the rules of the Dart language. Those libraries contain specific declarations whose semantics cannot be written in Dart, and hence they must at times violate the rules that every user-written library must satisfy.
The fact that the class Function is a supertype of all function types is an example, there is no syntax which will make this happen. So the analyzer and compiler just have to know that the declaration of the class Function is special, and give it special treatment.
Similarly, the declaration of the class Function can have the name Function even though that is a built-in identifier. The tools will simply give that declaration a special treatment, and that is not a problem.
This does not mean that the rules of the language are fuzzy in any user-written libraries, they must still follow all the rules.


Do not provide blob urls to json worker

It fails when there is multiple schemas for the same association, the worker merges them by creating a  allOf parent schema that fails with blob url because it tries to resolve them as paths
I got headaches on this one

How did you stumble upon the problem in the first place?

I've been using the vsix plugin to load some vscode extensions and multiple ones where registering json schemas for the package.json file. And as soon as there is more than 1, the json worker create a combined one and that's where it starts to fails with resolution failure and attempt to use fetch to get the underlying schema on a fake url with scheme schemaservice://


Option for Generating Config With Different Port

If networkqualityd is behind a reverse proxy (and it is the one generating its config file), then we need an option for the "announced port" in the config to be different than the one on which the server listens. I have a hack that works, but I will make a nice PR.

cc @randall


Ability to select and species in the Matrix tool

This would likely be easily implemented by exposing filter components from the new BS3 widget set and tying it to the manager (assuming we're not generating a new manager each time).

Should I see this here?
http://amigo2.berkeleybop.org/matrix

ignore found it


C#: Load assemblies as collectible only in the Godot editor

We use collectible AssemblyLoadContexts as that's the only way to allow reloading assemblies after building. However, collectible assemblies have some restrictions:

https://learn.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/collectible-assemblies#restrictions-on-collectible-assemblies

Those restrictions can cause issues with third-party code, such as some mocking libraries.
In order to work around this problem, we're going to load assemblies as collectible only in Godot editor, and not when running games. These issues will still exist in the editor, but this will be enough for some users.
Solves #66060

I can't merge this until a reviewer approves :stuck_out_tongue:

Is there an use case for reloading assemblies when running games? Or will we only ever care about reloading assemblies in the editor?

Is there an use case for reloading assemblies when running games? Or will we only ever care about reloading assemblies in the editor?

Yes, the use case is hot-reloading changes without restarting the game. I hope we can get .NET Hot Reload (VS and dotnet watch) working with Godot. That would be a better fit for running games. Godot's assembly reloading is a better fit for the editor.

Thanks!


edge yumrepos config.repo file content conflicting protocol with port

Describe the issue
Since yesterday around 1730 hours UTC, we have had failures installing edge via yum.  It appears the config.repo file (https://packages.microsoft.com/yumrepos/edge/config.repo) has conflicting protocol and port.  Possibly should be https
When did the issue occur?
September 12 around 1730 hours UTC
If applicable, what package did you attempt to install, and from which repo?
yum microsoft-edge-stable
Steps to Reproduce
rpm --import https://packages.microsoft.com/keys/microsoft.asc     && curl https://packages.microsoft.com/yumrepos/edge/config.repo > /etc/yum.repos.d/microsoft-edge-dev.repo     && yum --nogpgcheck install -y microsoft-edge-stable
Actual Result
http://packages.microsoft.com:443/yumrepos/edge/repodata/repomd.xml: [Errno 14] HTTP Error 400 - Bad Request
Trying other mirror.
Expected Result
Successful package install
Screenshots

Additional context
Our script has not changed and we noticed microsoft-edge-stable-116.0.1938.81-1.x86_64.rpm was uploaded at September 12 1722 hours UTC but the repodata directory was updated at 1858 hours UTC.  We had a successful install in between these times.

https://packages.microsoft.com/yumrepos/edge/config.repo should be fixed now. We're clearing other config.repo files from our cache as well.

All affected config.repo files / regions have been purged, this issue should be completely resolved.


When run "mvn clean install -DskipTests" in java8, got error for java…

…doc plugin.

See #8

Hi, thank you very much for your interest in contributing to the project!  Please read about submitting contributions here: http://www.quartz-scheduler.org/community/contribute.html  and confirm in a reply comment that you agree to the grant statement under the heading "Agreement and Grant of Copyright"

This is now fixed. See PR #50


[Bug] [client] A select sql cannot work with FlinkSqlEnv on yarn-per-job mode

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
I wrote a sql like 'select count(1) from table_a' and I submit it with FlinkSqlEnv, creating a Hive dialect and using it . The job I triggered got failure status by the end. I searched the log for the reason and I got 'Only insert statement is supported now'.
Here are the main Exceptions stack I found from the web:
2022-04-27T01:19:15.619: Exception in executing FlinkSQL:
select count(*) from test.omd
Error message:
org.apache.flink.table.api.TableException: Only insert statement is supported now.
at com.dlink.executor.CustomTableEnvironmentImpl.getStreamGraphFromInserts(CustomTableEnvironmentImpl.java:150)
at com.dlink.executor.CustomTableEnvironmentImpl.getJobGraphFromInserts(CustomTableEnvironmentImpl.java:167)
at com.dlink.executor.Executor.getJobGraphFromInserts(Executor.java:316)
at com.dlink.job.JobManager.submitByGateway(JobManager.java:397)
at com.dlink.job.JobManager.executeSql(JobManager.java:293)
at com.dlink.service.impl.TaskServiceImpl.submitTask(TaskServiceImpl.java:98)
at com.dlink.service.impl.TaskServiceImpl$$FastClassBySpringCGLIB$$168bea78.invoke()
WHY? It doesn't make any sense. I submit the same job on the version 0.6.1 without any failure.
What you expected to happen
Launching the job without any problem, you know.
How to reproduce
Just create a FlinkSqlEnv and then write a select statement , choose batch mode and submit your sql on version 0.6.2, you will find that.
Anything else
No response
Version
0.6.2
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Please close the statement set.


pool token in not being added

For some reason on swap events only pool token out is being added to tx.

Consider this query.
which produces this for a swap tx:
{
  "event": "swap",
  "poolAddress": {
    "datatokenAddress": "0x7bce67697ed2858d0683c631dde7af823b7eea38"
  },
  "timestamp":<PHONE_NUMBER>,
  "tokens": [
    {
      "poolToken": {
        "id": "0xaab9eaba1aa2653c1dda9846334700b9f5e14e44-0x7bce67697ed2858d0683c631dde7af823b7eea38",
        "symbol": "QUICRA-0"
      },
      "tokenAddress": "0x7bce67697ed2858d0683c631dde7af823b7eea38",
      "type": "out",
      "value": "-18.999999999825224137"
    }
  ],
  "tx": "0x2a64a94bba6b9542885fec11467a161bde3583eefcfecbf11e5add390b11a9bf"
},

Notice how tokens[] only holds 1 type: out token info, but for swap tx we need type: in & type: out


"com.fibaro.multilevelSwitch" incorrectly displays in HomeKit App

A device with the type of "com.fibaro.multilevelSwitch" incorrectly displays in HomeKit App. It should have a slicer control instead of binary "on" and "off".
Fibaro HC3. I can increase or decrease the fan by changing the brightness control.

iOS HomeKit App. Only on and off states are there.

@vkamenski can you show me the General and Advanced tab in home center for this device?

@vkamenski can you send me the json object of the device rest api?

Dimmer 2 (com.fibaro.FGD212) also is displayed as on/off. It should have a slicer control.

"type":"com.fibaro.FGD212",
"baseType":"com.fibaro.multilevelSwitch",

@mkz212 what's the value of deviceControlType ?

23

@mkz212 is it formatted as a string or as a number ?

String. "deviceControlType":"23"

ok, that's the problem. Will fix it.

@vkamenski @mkz212 can you test version 1.1.17 ?

Now kind of works. But I had to clean the cache.
The worst thing is that when I move the slider, the light blinks. For example, when I do from 2% to 100% it should only lighten up but it makes it brighter, darker, brighter.
And sometimes he doesn't listen. I change the value, the slider goes up and then goes back to the old position.

handling with scenes also has problems. I did two scenes. one set the light to 80%, the other set to 5% and the same flashes and jamming light as if it only reacted after a while.

@mkz212, please open different issues for those problems (it seems that they are related to a bug in Home Center on the refreshState, investigating). Closing this one.


calling grab_focus() during mouse_entered signal causes !is_inside_tree() error

Godot version:

3.1
Issue description:

All focus methods are affected in this example, grab, grab_click, and release_focus.
Steps to reproduce:
Run the provided project. Mouse over the panels.
Relevant code is on lines 140 and beyond.
The goal is to detect the mouse entering/existing, grab focus, then play an animation.
Minimal reproduction project:

buttonlist.zip

This looks like a problem with your scene. Not sure how you set object bindings via editor, but they don't seem to be working. The node you get as method's argument isn't the one you think. Try print(child.name) and you'll see its name is empty.

node.connect(signal, self, func, [node])
i dont see how node could not be correct in this case.

<.< Unless of course due to the fact that these connections are saved, it cant save the reference. Which is weird, that it would even be able to return a node in the first place.
I guess ill have to reconstruct the signals during _ready.

I mean, the nodes on scene are already connected and doesn't seem like the connecting code is being called. (that might be because add_child and add_child_below_node aren't virtual, so you can't override them)

The connections stem from those calls. Add a new node to the scene and see for yourself.

Right .-.
So in the end, assuming that you manage to save the node reference, isn't it basically the same as exporting a Node? AFAIK it's not possible. I guess you should pass a NodePath, not sure how to do this correctly though.
Anyways, the problem is not with the grab_focus in mouse_entered.

node.connect(signal, self, func, [node])
i dont see how node could not be correct in this case.

add_child(_t)
Tween is not a Control. Also, that seems to be the only place that code is being called, unless the example is incomplete. Inspecting the signals in the inspector, the extra call argument is empty.

It looks like an issue with serialization of the signals.
I'll close this issue, and make a new one. Signals that have bindings which can not be saved, should print a warning when you do so.


C++ Memory error on Linux/Docker

First off, thanks for your work on the implementation of the algorithm, it's excellent. I do most of my development on OSX and HDBSCAN has worked like a charm.
However, I've recently been trying to deploy some models requiring the package on some EC2 instances and keep getting segmentation faults associated with the munmap_chunk() method. As an example, I've included the output of a test script that I've run either on my development machine, or on the Linux box:
Test Script
import numpy as np
import cython as ct
import scipy as sp
import sklearn as sk

import subprocess

# get machine info
proc_cpu = subprocess.Popen(['/bin/bash'], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
cpu_info = proc_cpu.communicate('lscpu')[0]
proc_os = subprocess.Popen(['/bin/bash'], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
os_info = proc_os.communicate('uname -a')[0]

# custom logger
from crunch.logger import Logger
logger = Logger('test hdbscan')

# report info on current machine
logger.log.info('Current hardware configuration:\n%s' % cpu_info)
logger.log.info('Current os configuration:\n%s' % os_info)

# display requirements and current python distros
requirements = """
cython>=0.22
numpy>=1.9
scipy >= 0.9
scikit-learn>=0.16
"""
logger.log.info('Requirements for HDBSCAN:\n%s' % requirements)

current_config = """
cython: %s
numpy: %s
scipy: %s
scikit-learn: %s
""" % (ct.__version__, np.__version__, sp.__version__, sk.__version__)
logger.log.info('Current Python configuration:\n%s' % current_config)

# generate cluster data
np.random.seed(4711)  # for repeatability
sample_size = 50
a = np.random.multivariate_normal([10, 0], [[3, 1], [1, 4]], size=[sample_size,])
b = np.random.multivariate_normal([0, 20], [[3, 1], [1, 4]], size=[sample_size,])
c = np.random.multivariate_normal([40, 40], [[20, 1], [1, 30]], size=[sample_size,])
d = np.random.multivariate_normal([80, 80], [[30, 1], [1, 30]], size=[sample_size,])
e = np.random.multivariate_normal([0, 100], [[100, 1], [1, 100]], size=[sample_size,])
f = 300. * (np.random.rand(sample_size,2) - .5)

# cast data as different dtypes (doesn't matter)
X = np.asarray(np.concatenate((a, b, c, d, e, f),), dtype=np.float32)

# attempt to run clustering
logger.log.info('Running clustering...')
from hdbscan import HDBSCAN
cl = HDBSCAN(min_cluster_size=10)
classes = cl.fit_predict(X)
logger.log.info('Success!')

logger.log.info('Results:')
print classes

The output when run on OSX
/bin/bash: line 1: lscpu: command not found
INFO   | test hdbscan | Current hardware configuration:

INFO   | test hdbscan | Current os configuration:
Darwin crunch.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64

INFO   | test hdbscan | Requirements for HDBSCAN:
cython>=0.22
numpy>=1.9
scipy >= 0.9
scikit-learn>=0.16

INFO   | test hdbscan | Current Python configuration:
cython: 0.23.4
numpy: 1.10.1
scipy: 0.16.1
scikit-learn: 0.17.1

INFO   | test hdbscan | Running clustering...
INFO   | test hdbscan | Success!
INFO   | test hdbscan | Results:
[ 3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3
  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3
  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3
  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2
  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2  2
 -1 -1 -1 -1 -1  1  0 -1 -1 -1 -1  3 -1  1 -1  2 -1 -1 -1 -1 -1 -1 -1 -1  2

Great! Now let's try it on EC2...
The output when run on Linux
INFO   | test hdbscan | Current hardware configuration:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 62
Stepping:              4
CPU MHz:               2500.058
BogoMIPS:              5000.11
Hypervisor vendor:     Xen
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0-3

INFO   | test hdbscan | Current os configuration:
Linux 44f4d4de5575 3.13.0-71-generic #114-Ubuntu SMP Tue Dec 1 02:34:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

INFO   | test hdbscan | Requirements for HDBSCAN:
cython>=0.22
numpy>=1.9
scipy >= 0.9
scikit-learn>=0.16

INFO   | test hdbscan | Current Python configuration:
cython: 0.23.4
numpy: 1.10.1
scipy: 0.16.1
scikit-learn: 0.17

INFO   | test hdbscan | Running clustering...
*** Error in `python': munmap_chunk(): invalid pointer: 0x00000000030cef80 ***

This likely isn't a problem with the HDBSCAN package per se, but perhaps how Linux vs OSX allocates/deallocates memory. Unfortunately, I do not have direct access to the Linux box/Docker containers in order to run Valgrind or the like in order to track down the error (they're deployed by a 3rd party service, i.e. the *** Error in 'python':...***).
One possible solution is to add a  compilation flag that checks for memory size, though this may affect performance. Would love to hear your thoughts...

This looks like a nasty issue -- thanks for the detailed report, it will help me track it down much faster. I believe the problem to be in the UnionFind for the single linkage clustering, but I'm not actually sure what has caused the issue there (nothing obvious leaps out at least). I'll try and get some debugging done this evening when I can get access to a linux box.

I have the same problem. I changed to 0.6.4 version and now it works.

Thanks, that's actually helpful right now!
On Thu, Feb 25, 2016 at 8:43 PM, Felipe Moraes<EMAIL_ADDRESS>wrote:

I have the same problem. I changed to 0.6.4 version and now it works.
—
Reply to this email directly or view it on GitHub
https://github.com/lmcinnes/hdbscan/issues/25#issuecomment-189073964.

I believe this is working now; let me know if you still see any issues.

@felipemoraes, thanks for the pointer (pun intended) on version 0.6.4; that seemed to get things working for me on Linux. @lmcinnes, it seems the same munmap_chunk() issue persists in version 0.7.1

That's unfortunate; it seemed to fix the equivalent error I was managing to reproduce on the linux system I was using. I'll look into it further. It seems to involve the way Cython is handling pointers, and I may just have to accept I can't use the approach I was because it doesn't work well on linux.

@dustinstansbury If you get some time and can test the current head in the repository I would be keen to know if that resolves the problem for you. Thanks.

@lmcinnes, it seems that Cython continues to exhibit some problems with pointer handling; the issue persists, even when run from HEAD.

Alright; thanks for that. It seemed to be working for my linux install, but obviously that far from universal. 0.6.4 seems to be working for people so I will try and roll back changes to that for the relevant code and call it done.

Works for me! Thanks for taking the time to look into it.


DRILL-5375: Nested loop join: return correct result for left join

With this fix nested loop join will correctly process INNER and LEFT joins with non-equality conditions.

A general comment about filter evaluation: In HashJoin and MergeJoin we do implicit casting of one of the join columns to process the join condition (see invocations of JoinUtils.addLeastRestrictiveCasts()).  Since you are adding filter evaluation to NestedLoopJoin, I would think we need this there as well.  However, I am ok if you want to create a separate JIRA for doing that.

Thanks for bringing up this point. I have done some investigation and found out that implicit casts for nested loop join are already included during materialization.
Join condition is transformed into FunctionCall [1] which is later on materialized using ExpressionTreeMaterializer [2].
ExpressionTreeMaterializer.visitFunctionCall includes section which implicit casts [3].
Actually these casts are more enhanced that during hash and merge joins.
For example, during hash and merge joins only casts between numeric types, date and timestamp, varchar and varbinary are supported, i.e.
join by int and varchar columns won't be performed. The following error will be returned: Join only supports implicit casts between 1. Numeric data  2. Varchar, Varbinary data 3. Date, Timestamp data Left type: INT, Right type: VARCHAR. Add explicit casts to avoid this error.
In our case nested loop join will be able to perform join by int and varchar columns without adding explicit casts.
[1] https://github.com/arina-ielchiieva/drill/blob/71628e70a525d9bd27b4f5f56259dce84c75154d/exec/java-exec/src/main/java/org/apache/drill/exec/planner/physical/NestedLoopJoinPrel.java#L95
[2] https://github.com/arina-ielchiieva/drill/blob/71628e70a525d9bd27b4f5f56259dce84c75154d/exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/join/NestedLoopJoinBatch.java#L265
[3] https://github.com/apache/drill/blob/9411b26ece34ed8b2f498deea5e41f1901eb1013/exec/java-exec/src/main/java/org/apache/drill/exec/expr/ExpressionTreeMaterializer.java#L362

A few follow-up comments which are non-blockers.  Overall LGTM.  +1


Convert bdist_pex tests to explicit cmdclass.

Previously the test relied upon the tox venv interpreter (which
implicitly builds and installs the pex wheel) being the interpreter that
executed the python setup.py bdist_pex ... command. This assumption
could be violated when running under pyenv which OSX CI shards do.
Instead, explicitly add pex to the PYTHONPATH of the interpreter and
let distutils know about bdist_pex via --command-packages.
Fixes #896

I'm going to submit to unblock landing #894 and #895.


Example CSV import (labels.txt) does not render correctly

Preflight Checklist

[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug
Importing the label.txt example csv file does not render how it supposed to.
To Reproduce
Steps to reproduce the behavior:

Copy the contents of the label.txt example file
Insert into draw.io through Arrange -> Insert -> Advanced -> CSV
See error

Expected behavior
I expect to see the output included with the article (see screenshots). Instead I get a garbled string starting with hjavaZ1 on the browser.
Screenshots
This is what I expect to see, as given in the article:

This is what I see in the desktop install of draw.io:

This is what I see in firefox:

draw.io version (In the Help->About menu of the draw.io editor):

draw.io version: 20.3.0 (desktop)
draw.io version: 20.5.1 (web)

Desktop (please complete the following information):

OS: Windows
Browser: Firefox
Version: 106.0.1

Figured it out, there is a mistake in the label.txt file (space before labeltype and all entries). This is how it should look:
## **********************************************************
## Example description
## **********************************************************
## This example shows you how to use and style labels. By default, there is one label type for all cells. You can have a custom number of parameters, but in this example, for label1 we used 3: name, position and email. Here, in the "labels" array below, we defined three separate label types, which we apply to each shape. The label type is defined in the last column of the CSV data.
## **********************************************************
## Configuration
## **********************************************************
# labels: {"label1" : "%name%
%position%
Email", "label2" : "Type2
%name%", "label3" : "Type3"}
# labelname: labeltype
# style: whiteSpace=wrap;html=1;rounded=1;fillColor=#ffffff;strokeColor=#000000;
# namespace: csvimport-
# connect: {"from": "refs", "to": "id", "style": "curved=1;fontSize=11;"}
# width: auto
# height: auto
# padding: 5
# ignore: id,refs
# link: url
# nodespacing: 60
# levelspacing: 60
# edgespacing: 40
# layout: auto
## **********************************************************
## CSV Data
## **********************************************************
id,name,position,email,url,refs,labeltype
1,Evan Miller,CFO,me@example.com,https://www.draw.io,"2,3,4,5,6",label1
2,Edward Morrison,Brand Manager,me@example.com,https://www.draw.io,"",label1
3,Ron Donovan,System Admin,me@example.com,https://www.draw.io,"",label1
4,Tessa Valet,HR Director,me@example.com,https://www.draw.io,"",label1
5,Hanna Emerson,PR,me@example.com,https://www.draw.io,"",label2
6,Richard Newman,PR,me@example.com,https://www.draw.io,"",label3

That generates the expected chart:


Install fails on Ubuntu 14, GHC 7.6.3 (Haskell Platform)

I just tried to install IHaskell on both my work and personal computers, and each failed on the cabal install ihaskell --reorder-goals step with the message
cabal: The following packages are likely to be broken by the reinstalls:
HTTP-4000.2.18

I'm running Ubuntu 14.04, cabal <IP_ADDRESS>, and ghc 7.6.3 on both machines.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/10373296-install-fails-on-ubuntu-14-ghc-7-6-3-haskell-platform?utm_campaign=plugin&utm_content=tracker%2F332399&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F332399&utm_medium=issues&utm_source=github).

Could you include the full build log from cabal?
You could also pass it --force-reinstalls and let it break HTTP.
Also, you can install IHaskell in a cabal sandbox:
mkdir ihaskell-sandbox
cd ihaskell-sandbox
cabal sandbox init
cabal install ihaskell --reorder-goals

This doesn't look like a bug / error in IHaskell, just difficulty installing it with the packages you happen to have installed globally :( It can be solved by reinstalling some of the packages you have (that's the --force-installs option) or by using a sandbox.

Thanks for the quick reply! I did get it working with --force-reinstalls, but I figured it was worth posting a bug just because this will affect anyone who tries to install IHaskell using the most recent version of Ubuntu and the Haskell Platform.

Great; good to know.
Once 7.10 is out and IHaskell works with 7.10, I'll try to make sure it installs cleanly with the Haskell platform.


Remove misleading signature image

Leave prs snd authorship intact. You can apply additional work in follow-ups, or in unsquashed commits.


Added bloodhound to implementations list.

To install and verify:
npm i bloodhound-promises
npm run-script verify

Looks good, thanks!


Add "syncd init" command

Created a new syncd init command which creates a new syncd.conf file on current directory.
Please test if that works. I think it needs some more tweaks. I am using Ubuntu and could not test it anywhere else.
Thanks.

Great addition, thanks! However, this has conflicts now - can you reroll?


Feature request: Turborepo and Documentation

Add documentation template /[locale]/docs and also make turborepo for multiple apps
.
├── README.md                           # README file
├── .github                                    # GitHub folder
...
├──apps
│   ├── web                                   # App1 Nextjs
│   │   ├── src
│   │       ├── app                         # Next JS App (App Router)
│   │       ├── components           # React components
│   │       ├── ...
│   │       ├── utils                        # Utilities folder
│   │       ├── validations             # Validation schemas
│   │
│   ├── docs                                 # App2 Vite
│   │   ├── src
│   │       ├── app                        # Next JS App (App Router)
│   │       ├── components          # React components
│   │       ├── ...
│   │
│   ├── PWA                                # App3 Nextjs
│   │   ├── ...
│   │
│   ├── Blogs                               # App4 Nextjs
│   │   ├── ...
│
├── tests
│   ├── e2e                                 # E2E tests, also includes Monitoring as Code
│   └── integration                     # Integration tests
├── tailwind.config.js                 # Tailwind CSS configuration
└── tsconfig.json                       # TypeScript configuration
└── turbo.json                           # Turbo configuration

documentation examples:
nextjs: https://nextjs.org/docs
shacn: https://ui.shadcn.com/docs
clerk: https://clerk.com/docs
turborepo examples:
shadcn: https://github.com/shadcn-ui/ui
cal.com https://github.com/calcom/cal.com
supabase: https://github.com/supabase/supabase
Refrences:
docs: Nextra, Contentlayer.dev ⚠, Sandocs
turborepo: Turbo.build

I think these 2 features will make more sense in SaaS Boilerplate: https://github.com/ixartz/SaaS-Boilerplate, which is built on top of Next.js Boilerplate
In SaaS Boilerplate, it'll totally make sense to add a documentation template.

Yeah I agree with you and this template will booming soon but why you don't use Prisma instead of Drizzle and Prisma in this Saas Boilerplate even Prisma is now edge compatible and also supporting Turso
Read here: https://github.com/prisma/prisma/releases/tag/5.11.0
Blog: https://www.prisma.io/blog/prisma-orm-support-for-edge-functions-is-now-in-preview

It's a new project, just published today.
The Edge and Turso support is only available in 5.11, it was released 2 weeks ago. I didn't know it before your comment.
Here are the few reason I'm using Drizzle ORM instead of Prisma:
Schema in TypeScript
No DB client to generate
Programmatic migrate function: https://github.com/ixartz/Next-js-Boilerplate/blob/93ea223dfbf29d060b68b46431478169c9b3e291/scripts/dbMigrate.ts#L16, which not available in Prisma

I think these 2 features will make more sense in SaaS Boilerplate: https://github.com/ixartz/SaaS-Boilerplate, which is built on top of Next.js Boilerplate
In SaaS Boilerplate, it'll totally make sense to add a documentation template.

It's not added to the Saas boilerplate, and when I tried to make this one turborepo, it's throwing errors!

Could you share the error?
There isn't any specific changes to make incompatible with Turborepo

Since Turso by design supports large number of DBs, it is a great candidate for SaaS.

DB per Tenant
https://turso.tech/blog/creating-a-multitenant-saas-service-with-turso-remix-and-drizzle-6205cf47

Reduces security risks in B2B SaaS with each tenant getting their own DB.
Plus a monorepo is much more scalable pattern. This would be great.

Keystatic is a much better replacement for Contentlayer.


grpc: Received message larger than max

Important：Please file the issue follow the template, or we won't be able to help you to solve the problem.

0. Report Issue Guide

Please run the following command and check whether the problem has been fixed：
rm -rf package-lock.json
rm -rf node_modules
npm install

pretty sure that's not work

Please search in FAQ List first, and make sure your problem has not been solved before.

not work

Please search in the issue first, and make sure your problem had not been reported before

not work
1. Versions

What is your wechaty version?

Answer: bug at both<EMAIL_ADDRESS>and<EMAIL_ADDRESS>
Which puppet are you using for wechaty? (puppeteer/padlocal/service...)

Answer: wechaty-puppet-service

What is your wechaty-puppet-XXX（padchat/puppeteer/） version?

Answer:   "wechaty-puppet": "^1.2.11",

What is your node version? (run node --version)

Answer: v16.13.0

What os are you using

Answer: debian
2. Describe the bug

Give a clear and concise description of what the bug is.

3. To Reproduce

This part is very important: if you can not provide any reproduce steps, then the problem will be very hard to be recognized.

How to create a Minimal, Reproducible Example
Steps to reproduce the behavior:

run latest wechaty and puppet-service
send a big file to bot (like 10MB)
error

4. Expected behavior

Give a clear and concise description of what you expected to happen.

bot receive file.
it's ok in wechaty 0.x
5. Actual behavior

If applicable, add screenshots to help explain your problem. But do not paste log screenshots here.

error throw, no file to bot
6. Full Output Logs

Set env WECHATY_LOG=silly in order to set log level to silly, then we can get the full log (If you dosen't set log env, log level is info as default, we cannot get the full log)

We need full log instead of log screenshot or log fragments!
wechaty == 1.0.6
21:45:57 ERR Config ###########################
21:45:57 ERR Config Wechaty unhandledRejection: Error: 8 RESOURCE_EXHAUSTED: Received message larger than max (10963429 vs. 4194304)
    at Object.callErrorFromStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client.js:180:52)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:336:141)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:299:181)
    at /home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/call-stream.js:160:78
    at processTicksAndRejections (node:internal/process/task_queues:78:11) [object Promise]
21:45:57 ERR Config ###########################
21:45:57 ERR Config process.on(unhandledRejection) promise.catch(8 RESOURCE_EXHAUSTED: Received message larger than max (10963429 vs. 4194304))
Config Error: 8 RESOURCE_EXHAUSTED: Received message larger than max (10963429 vs. 4194304)
    at Object.callErrorFromStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client.js:180:52)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:336:141)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:299:181)
    at /home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/call-stream.js:160:78
    at processTicksAndRejections (node:internal/process/task_queues:78:11) {
  code: 8,
  details: 'Received message larger than max (10963429 vs. 4194304)',
  metadata: Metadata { internalRepr: Map(0) {}, options: {} }
}
(node:7486) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 3)
(Use `node --trace-warnings ...` to show where the warning was created)
21:45:58 VERB PuppetService recover$() heartbeatDing()
21:45:58 VERB PuppetService onStart() recover$().subscribe() next(0)
21:45:58 VERB PuppetService onGrpcStreamEvent({type:EVENT_TYPE_DONG(3), payload(len:28)})
21:45:58 VERB PuppetService recover$() heartbeat: {"data":"onGrpcStreamEvent(EVENT_TYPE_DONG)"}
21:45:58 VERB PuppetService recover$() heartbeat: {"data":"onGrpcStreamEvent(EVENT_TYPE_DONG)"}
21:46:04 VERB PuppetService onGrpcStreamEvent({type:EVENT_TYPE_HEARTBEAT(1), payload(len:43)})
21:46:04 VERB PuppetService recover$() heartbeat: {"data":"[object Object]","timeout":120000}
21:46:04 VERB PuppetService recover$() heartbeat: {"data":"[object Object]","timeout":120000}

wechaty==1.1.7
21:48:54 ERR Config ###########################
21:48:54 ERR Config Wechaty unhandledRejection: Error: 8 RESOURCE_EXHAUSTED: Received message larger than max (10963429 vs. 4194304)
    at Object.callErrorFromStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client.js:180:52)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:336:141)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:299:181)
    at /home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/call-stream.js:160:78
    at processTicksAndRejections (node:internal/process/task_queues:78:11) [object Promise]
21:48:54 ERR Config ###########################
21:48:54 ERR Config process.on(unhandledRejection) promise.catch(8 RESOURCE_EXHAUSTED: Received message larger than max (10963429 vs. 4194304))
Config Error: 8 RESOURCE_EXHAUSTED: Received message larger than max (10963429 vs. 4194304)
    at Object.callErrorFromStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client.js:180:52)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:336:141)
    at Object.onReceiveStatus (/home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:299:181)
    at /home/coder/project/JuziBot/src/node_modules/@grpc/grpc-js/build/src/call-stream.js:160:78
    at processTicksAndRejections (node:internal/process/task_queues:78:11) {
  code: 8,
  details: 'Received message larger than max (10963429 vs. 4194304)',
  metadata: Metadata { internalRepr: Map(0) {}, options: {} }
}
(node:7699) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 3)
(Use `node --trace-warnings ...` to show where the warning was created)
21:48:59 VERB PuppetService recover$() heartbeatDing()
21:48:59 VERB PuppetService onStart() recover$().subscribe() next(0)
21:48:59 VERB PuppetService onGrpcStreamEvent({type:EVENT_TYPE_DONG(3), payload(len:28)})
21:48:59 VERB PuppetService recover$() heartbeat: {"data":"onGrpcStreamEvent(EVENT_TYPE_DONG)"}

WECHATY_LOG=verbose \
TZ='Asia/Shanghai' \
WECHATY_PUPPET_SERVICE_NO_TLS_INSECURE_CLIENT=true \
WECHATY_PUPPET=wechaty-puppet-service \
WECHATY_PUPPET_SERVICE_TOKEN=xxxxxx \
node index.js

7. Additional context

Add any other context about the problem here.

Thanks for reporting this problem, I believe it's related to the below code:
https://github.com/wechaty/puppet-service/blob/13e753af916e4b9bdf3211c16a181d8c43443825/src/client/puppet-service.ts#L892-L905
It should be wrapped within a try {} catch () {} block, because the WXWork puppet service is not upgraded to the Wechaty v1.x, which means this block will exceed the maximum gRPC size limitation (default): 4MB.

Please try to npm install<EMAIL_ADDRESS>let me know if it can fix your problem.
Thank you very much!

I hope this issue has been resolved with the latest code fix.
Please feel free to reply under this issue if there are still any problems or create a new one for better visibility.


Add pmml-notebook and review README.md of the project

Create notebook to explain how to train and export a model as PMML

@danielezonca lgtm!
Just a few minor comments:

Perhaps it would be easier to provide all the dependencies in a requirements.txt and instruct the user to run pip install -r requirements.txt
If you don't want very high model score, introduce a small amount of randomness in disp_risk (for instance, return 2 if random()<0.9 else 1 instead of return 2).
Add a plt.show() and the end of the cell for the plot to remove the __repr__ echo.

@ruivieira
Thanks for the suggestions :)

Perhaps it would be easier to provide all the dependencies in a requirements.txt and instruct the user to run pip install -r requirements.txt

Done

If you don't want very high model score, introduce a small amount of randomness in disp_risk (for instance, return 2 if random()<0.9 else 1 instead of return 2).

Done

Add a plt.show() and the end of the cell for the plot to remove the __repr__ echo.

Done
@tarilabs
Thanks for the suggestion, I moved data generation to a separated script and committed the generated file so now the notebook will just load an existing CSV file as you proposed :+1:


flickers, cresoline

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 5
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[c,f]

/trunk merge


Few random issues

So I thought this was kind of cool so I cloned and tried to build it on
MacOS.  The build failed, and there were a few issues I’ll list here in
case you ever decide you want to support Apple:

dprintf() conflicts with the dprintf() in Apples <stdio.h>.  I would
imagine this shouldn’t matter since it’s a macro, but I do get the
following warning:
In file included from src/rayalloc.c:6:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:362:5: error: expected parameter declarator
int     dprintf(int, const char * __restrict, ...) __printflike(2, 3) __OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3);

C23 disallows the use of alignas() in type-definitions.  This renders
the following typedef invalid:
typedef struct alignas(16) array {
    u32 flags;
    u32 cap, len;
    u32 ref;
    char data[];
} ar_t;

The definitions for i8, i16, …, u64 should be using the fixed-width
integer types from <stdint.h>.  I’ve opened a PR for that.

mremap() doesn’t exist on MacOS

MAP_SHARED_VALIDATE doesn’t exist on MacOS

I replaced dprintf with a nicer, still macro-based debug printing system
Fixed that alignas
Merged that PR
that's annoying since it seems MAP_FIXED_NOREPLACE is also not available. I'm thinking of ways to handle that, but it's not high priority since the map resizing feature is not used at the moment anyway.
Should be fixable with a bit of macro trickery

All the changed outlined above are in the testing branch. Note that no executable binary compiles on that branch at the moment.


Frame Rate Issue with Flash Fallback

I discovered an issue with the flash fallback on media element.
I have a slideshow presentation and the framerate its frane rate is 1 frame per second.
When media element falls back to flash it begins to skip at increments of 10 to 12 seconds because the frame rate is not 30 frames a second.
Is there any support for other framerates besides 30 fps as file size is an issue.

@jay1990 Closing old issues. If you'd like to reopen this, let us know. Thanks!


Doc enhancement: max_frame_size is in unit of bytes.

Considering there's a lot of sizes not mentioning bytes it would be good to fix them all at once and not just this one.

Done locally. Thanks!


fix: test.c with main to compile

Appreciate there is a TODO but I was interested to see the current output, very cool project!
./tests.c:500:5: error: second parameter of 'main' (argument array) must be of type 'char **'
int main(int argc, char *argv) {
    ^
1 error generated.

Thanks for your contribution!


E2E tests have incorrect dependencies

Example:
https://github.com/apify/crawlee/blob/fbea90ec5e953bc2fb6b319b4d57d3c5736b43d2/test/e2e/cheerio-default-ts/actor/package.json#L5-L16
https://github.com/apify/crawlee/blob/fbea90ec5e953bc2fb6b319b4d57d3c5736b43d2/test/e2e/cheerio-default-ts/actor/main.ts#L1-L5

What does this mean? Lets not create issues without proper description, this is not actionable.

Those should be in overrides instead

Blocked by https://github.com/npm/cli/issues/5584

Closing as stale


Adding ASA and AireOS Support

I've raised this issue to discuss the tracking of the Cisco ASA and Cisco AireOS driver, so people can add/contribute to the discussion as needed.
Naming standard
In other networking projects, cisco_wlc is used as the naming standard. Technically speaking, the _wlc component is the device it runs on, rather than the operating system.
As such, I've gone with the name cisco_aireos, but I really don't care if we go cisco_wlc to keep it consistent.

I dig aireos since it is more technically correct -- the best type of correct 😁 ! Will check out the PR in a bit, thanks a bunch for opening this and the work on it!!

Convo moving over to PR, closing this!


generating examples files on group_vars; group_vars/*.yml will be ign…

…ored
The idea is that files edited by site admins don't get overwritten whenever they do a git pull.
All files .yml in group_vars will be ignored.

.gitignore: group_vars//.yml isn't working


issue running hinted compile on Raspberry Pi

I am trying to compile a Python program in Nuitka on my Raspberry Pi 4. I got this error...
pi@APFMRPi:~/TestCodes $ python3 get-hints.py APFM.py
... Various printout from my program ...
No result matches 5, , ['_OS_X_API']
No result matches 4, core, ['set_keyring', 'get_keyring', 'set_password', 'get_password', 'delete_password', 'get_credential']
No result matches 3, keyring, None
No result matches 2, yagmail.password, ['register']
No result matches 2, transforms, ['Bbox']
Call cleaning has removed 526 items.
pi@APFMRPi:~/TestCodes $ python3 nuitka-hints.py APFM.py
NUITKA v<IP_ADDRESS> on Python 3.7.3 (linux) is compiling 'APFM.py' with these options:
--standalone
--remove-output
--recurse-none
Error, cannot find 'hinted-mods.py=APFM-37-linux-32.json'.

Based on advice from  Nuitka-chat/Community, I tried installing Nuitka version 0.6.5, but the install says <IP_ADDRESS> is the latest. Presume that is the case for my platform.
I did try compiling the HelloWorld example after I first installed Nuitka and it worked fine. But when I try it again now, I get the same error as my APFM program. The directory lists afterwards shows tha the relevant files present in the folder.
pi@APFMRPi:../HelloWorld $ python -m nuitka --version
<IP_ADDRESS>
Python: 2.7.16 (default, Apr  6 2019, 01:42:57)
Executable: /usr/bin/python
OS: Linux
Arch: armv7l
pi@APFMRPi:../HelloWorld $ python3 get-hints.py HelloWorld.py
Talk Hello World
Call cleaning has removed 0 items.
pi@APFMRPi:~/HelloWorld $ python3 nuitka-hints.py HelloWorld.py
NUITKA v<IP_ADDRESS> on Python 3.7.3 (linux) is compiling 'HelloWorld.py' with these options:
--standalone
--remove-output
--recurse-none
Error, cannot find 'hinted-mods.py=HelloWorld-37-linux-32.json'.
pi@APFMRPi:~/HelloWorld $ ls
get-hints.py  HelloWorld-37-linux-32.json  HelloWorld.py hinted-mods.py nuitka-hints.py

Any advise on how to fix this would be greatly appreciated.

It was suggested that I uninstall Nuitka and reinstall. Now I am running in to trouble uninstalling. Using pip uninstall, I get permission errors. Using sudo pip uninstall, it cannot find the package. Here is the screen dump...
pi@APFMRPi:~ $ pip uninstall nuitka
Uninstalling Nuitka-<IP_ADDRESS>:
Would remove:
/usr/bin/nuitka3
/usr/bin/nuitka3-run
/usr/lib/python3/dist-packages/Nuitka-<IP_ADDRESS>.egg-info
/usr/lib/python3/dist-packages/nuitka
Proceed (y/n)? y
ERROR: Exception:
Traceback (most recent call last):
File "/usr/lib/python3.7/shutil.py", line 563, in move
os.rename(src, real_dst)
PermissionError: [Errno 13] Permission denied: '/usr/bin/nuitka3' -> '/tmp/pip-uninstall-prv9pwve/nuitka3'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/pi/.local/lib/python3.7/site-packages/pip/_internal/cli/base_command.py", line 153, in _main
status = self.run(options, args)
File "/home/pi/.local/lib/python3.7/site-packages/pip/_internal/commands/uninstall.py", line 79, in run
auto_confirm=options.yes, verbose=self.verbosity > 0,
File "/home/pi/.local/lib/python3.7/site-packages/pip/_internal/req/req_install.py", line 755, in uninstall
uninstalled_pathset.remove(auto_confirm, verbose)
File "/home/pi/.local/lib/python3.7/site-packages/pip/_internal/req/req_uninstall.py", line 394, in remove
moved.stash(path)
File "/home/pi/.local/lib/python3.7/site-packages/pip/_internal/req/req_uninstall.py", line 283, in stash
renames(path, new_path)
File "/home/pi/.local/lib/python3.7/site-packages/pip/_internal/utils/misc.py", line 338, in renames
shutil.move(old, new)
File "/usr/lib/python3.7/shutil.py", line 578, in move
os.unlink(src)
PermissionError: [Errno 13] Permission denied: '/usr/bin/nuitka3'
pi@APFMRPi:~ $ sudo pip uninstall nuitka
Not uninstalling nuitka at /usr/lib/python2.7/dist-packages, outside environment /usr
Can't uninstall 'Nuitka'. No files were found to uninstall.

This issue has been resolved by using the latest develop version 0.6.6 of Nuitka and python3.7.


ClassName Prop doesn't appear to be supported

Description
I'm using nativeWind and trying to pass classNames into components and it seems to be swallowing the className as styles aren't applied to components
CodeSandbox/Snack link
No response
Steps to reproduce
No response
gluestack-ui Version
1.011
Platform

[X] Expo
[ ] React Native CLI
[ ] Next
[ ] Web
[ ] Android
[ ] iOS

Other Platform
No response
Additional Information
No response

@dylel Thanks for reporting this. We'll update you on this.


miss cache if define and use structref in the same file

Hi, guys. I have an interesting issue when enabling cache and using structref, here is a minimum reproducer:
# %%
import numpy as np
from numba import types, njit
from numba.experimental import structref
import os

os.environ['NUMBA_DEBUG_CACHE'] = '1'

# define a structref
@structref.register
class StructType(types.StructRef):

    def preprocess_fields(self, fields):
        return tuple((nam, types.unliteral(typ)) for nam, typ in fields)

class Struct(structref.StructRefProxy):

    def __new__(cls, field):
        return structref.StructRefProxy.__new__(cls, field)

    @property
    def field(self):
        return Struct_get_field(self)

@njit(cache=True)
def Struct_get_field(self):
    # In jit-code, the StructRef's attribute is exposed via
    # structref.register
    return self.field

structref.define_proxy(Struct, StructType, [
    "field",
])

# define jit functions
@njit(cache=True)
def foo(struct):
    return struct.field

@njit(cache=True)
def goo(a):
    return a.shape

# call foo and goo
print("separate".center(20, '!'))

my_struct = Struct(0)
foo(my_struct)

my_a = np.zeros(10)
goo(my_a)

When executing this file, first time, everything is new, so need to save index and data:
!!!!!!separate!!!!!!
[cache] index saved to '.../define.foo-41.py38.nbi'
[cache] data saved to '.../define.foo-41.py38.1.nbc'
[cache] index saved to '.../define.goo-46.py38.nbi'
[cache] data saved to '.../define.goo-46.py38.1.nbc'

second time, rerun this python file and foo's cache misses! At the same time, goo's cache does hit:
!!!!!!separate!!!!!!
[cache] index loaded from '.../define.foo-41.py38.nbi'
[cache] index loaded from '.../define.foo-41.py38.nbi'
[cache] index saved to '.../define.foo-41.py38.nbi'
[cache] data saved to '.../define.foo-41.py38.2.nbc'
[cache] index loaded from '.../define.goo-46.py38.nbi'
[cache] data loaded from '.../define.goo-46.py38.1.nbc'

If moving these lines below to another file and importing Struct, foo, and goo, foo's cache will hit!
my_struct = Struct(0)
foo(my_struct)

my_a = np.zeros(10)
goo(my_a)

I haven't find the root cause, any pointer or insight will be helpful!
Tested with Numba 0.56.4

I can reproduce this with main. I suspect that the struct ref types are considered distinct across each run of the code.

@dlee992 Does undoing the changes from #7388 fix this issue for you?

Didn't try to revert. I mean #7388 mentioned similar issues as I met in this case, especially this comment  "Test cannot run as when module is __main__". I do remember my traceback prints __main__. Maybe it's a known limitation of cloudpickle.

I've taken a look into this. This is not specific to structref but instead a known pickle problem. Globals in the __main__ module is considered as not pickleable. That is why:

If moving these lines below to another file and importing Struct, foo, and goo, foo's cache will hit!
my_struct = Struct(0)
foo(my_struct)

my_a = np.zeros(10)
goo(my_a)

This behavior comes from: https://github.com/cloudpipe/cloudpickle/blame/master/cloudpickle/cloudpickle.py#L294.


Improve tree traversal of select_children

Resolves #10434
https://github.com/dbt-labs/dbt-core/issues/10434

Problem
DBT core performance was reported as degraded between 1.5 and 1.8 for some users with selectors of the style tag:mytag+. For selectors like this and for some large DAGs, the current implementation of getting descendants makes unnecessarily many calls to find children get the edge type, which I believe is a new check in finding children between 1.5 and 1.8. Many nodes may have the same descendents; this implementation takes care not to check the same edge twice.
Solution
This searches for descendents by stepping at a depth at 1 at a time, de-duplicating descendents by nature of Python sets, and removes nodes at each step that have already had their descendents searched.
I am looking for user testing to see if this improves performance and to apply this solution to parents as well if it is helpful.
I am seeing improved performance and will post my results in the issue thread.
Checklist

[X] I have read the contributing guide and understand what's expected of me.
[X] I have run this code in development, and it appears to resolve the stated issue.
[x] This PR includes tests, or tests are not required or relevant for this PR.
[x] This PR has no interface changes (e.g., macros, CLI, logs, JSON artifacts, config files, adapter interface, etc.) or this PR has already received feedback and approval from Product or DX.
[X] This PR includes type annotations for new and modified functions.

@ttusing Thank you so much for your continued interest in dbt performance issues!
I took your idea as a starting point, and did some simplification and testing. I found one small difference from the original function. Your implementation always included the 'selected' nodes, but the original did not.
I propose the following implementations for your branch. If they look good to you, let's use them and we should be able to merge your branch. I'll discuss a backport to earlier dbt versions with the rest of the team.
    def select_children(
        self, selected: Set[UniqueId], max_depth: Optional[int] = None
    ) -> Set[UniqueId]:
        """Returns all nodes which are descendants of the 'selected' set.
           Nodes in the 'selected' set are counted as children only if
           they are descendants of other nodes in the 'selected' set."""
        children: Set[UniqueId] = set()
        i = 0
        while len(selected) > 0 and (max_depth is None or i < max_depth):
            next_layer: Set[UniqueId] = set()
            for node in selected:
                next_layer.update(self.graph.successors(node))
            next_layer = next_layer - children  # Avoid re-searching
            children.update(next_layer)
            selected = next_layer
            i += 1

        return children

and also:
    def select_parents(
        self, selected: Set[UniqueId], max_depth: Optional[int] = None
    ) -> Set[UniqueId]:
        """Returns all nodes which are ancestors of the 'selected' set.
           Nodes in the 'selected' set are counted as parents only if
           they are ancestors of other nodes in the 'selected' set."""
        parents: Set[UniqueId] = set()
        i = 0
        while len(selected) > 0 and (max_depth is None or i < max_depth):
            next_layer: Set[UniqueId] = set()
            for node in selected:
                next_layer.update(self.graph.predecessors(node))
            next_layer = next_layer - parents  # Avoid re-searching
            parents.update(next_layer)
            selected = next_layer
            i += 1

        return parents

For reference, I used the following test function to verify they performed identically to the originals across a large number of test cases:
def test_select_children_and_parents_match_old_implementations():
    edges = [
        ("A", "B"),
        ("A", "C"),
        ("A", "D"),
        ("B", "E"),
        ("C", "E"),
        ("C", "F"),
        ("D", "G"),
        ("E", "H"),
        ("G", "I"),
        ("J", "K"),
    ]

    G = Graph(nx.DiGraph(edges))

    cases = []
    for i in range(len(G.nodes())):
        cases.extend(itertools.combinations(G.nodes(), i))

    for i in range(6):
        for case in cases:
            case = set(case)
            assert G.select_children_orig(case, max_depth=i) == G.select_children(case, max_depth=i)
            assert G.select_parents_orig(case, max_depth=i) == G.select_parents(case, max_depth=i)

Thanks - will update to this - also the docstring update is helpful; did not realize that behavior.

[success_kid.jpg]
Many thanks, @ttusing


simple syntax fix which allows logstash_formatter to not bomb under Py3

Python3 is grumpy with the current logstash-formatter and bombs-out.  The update fixes a simple
indentation issue and allows Python3 to run without issue.

This is fixed in a recent commit, thanks!


upgrade to lodash 4.x, split to separate imports

This will significantly reduce bundle size by not importing the entirety of the lodash package.

Coverage increased (+0.2%) to 95.161% when pulling 780bf2ed39435fa2f31ff5b72d232d37918270f3 on musicglue:master into b369eaa7f9e82544d40be19484b97f1e3d3a0220 on davidkalosi:master.

merged


Add error classes notice

Types of changes

[X] Enhancement (project structure, spelling, grammar, formatting)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

A description of the changes proposed in the Pull Request

Added errors usage notice

https://github.com/Green-Software-Foundation/if/issues/593


Redesign ongoing task type

Ongoing tasks are currently shown as a semi-transparent bar with small chunks filled in:

The idea was to demonstrate that there's some rough amount of work (the combined size of the solid chunks) but that it was spread throughout the remainder of the plan.
I don't think the visualization works that well though. For that matter, I don't think that using the input stop date to infer how big the chunks should be works that well either. Conceptually, an ongoing task might not run until the end of the plan.
I propose changing this type to remove the concept of "duration" (the solid chunks) and instead just render a striped line that respects the stop date. This can indicate an ongoing task that's a fuzzy level of effort. (If a more solid level of effort is required, arguably, the task should be defined as several regular tasks and slotted in somewhere.

Closed via b5add41


Provide error message when VIN doesn't have an update

Hi, the DEVICE_URL returns 404 if there's no updates for provided VIN, and 400 if it's invalid.
In case there's no updates, the program just closes without any feedback.

Hi,
Thanks for the feedback. I'm a bit surprised as the device API is meant to return information about the infotainment system in the car (NAC, RCC), whether there is an update or not.
I'll have to do some tests and try to understand what reason causes a 404...

For reference, it's Citroen C4 2016 VIN. Not sure if VIN is sensitive info so I'm not sharing that.
It's correctly formatted, as incorrect VIN returned 400.

I did some testing and investigated where the program would stop without any feedback but could not find anything so far.
Are you using latest version 1.0.4 (run psa-update --version)?
Are you executing the program from a terminal or just double clicking on it?
Are you running in interactive or silent mode?

Are you using latest version 1.0.4 (run psa-update --version)?
Are you executing the program from a terminal or just double clicking on it?
Are you running in interactive or silent mode?

Can't answer any of those questions. I reported this issue on behalf of my sisters husband during conversation.
Tried running it myself from the terminal now with the same VIN, and I get error:

Error: Device not found, make sure the VIN ***** is correct.

I took a closer look at the sources and the error gets correctly handled (for 404), so I'm closing this as "can't reproduce".


support idle handles for directory

Signed-off-by: xixi<EMAIL_ADDRESS>Close #2634

We need a simple test report to know how much this PR improves the situation.
Try ls a huge directory (e.g. 1m entries) in nfs client, and compare the time costs.

We should speedup Meta.Readdir, and cached the result (children) in meta.OpenFiles (same to chunks)

Codecov Report
Base: 58.34% // Head: 58.34% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (525671d) compared to base (ce69d4d).
Patch coverage: 83.33% of modified lines in pull request are covered.

:exclamation: Current head 525671d differs from pull request most recent head f31ad17. Consider uploading reports for the commit f31ad17 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3061   +/-   ##
=======================================
  Coverage   58.34%   58.34%
=======================================
  Files         141      141
  Lines       25066    25105   +39
=======================================
+ Hits        14625    14648   +23
- Misses       8500     8512   +12
- Partials     1941     1945    +4

Impacted Files
Coverage Δ

pkg/vfs/handle.go
83.70% <78.94%> (-1.87%)
:arrow_down:

pkg/vfs/vfs.go
76.80% <100.00%> (+0.03%)
:arrow_up:

pkg/vfs/reader.go
75.63% <0.00%> (-3.37%)
:arrow_down:

pkg/meta/sql.go
62.08% <0.00%> (+0.23%)
:arrow_up:

pkg/chunk/disk_cache.go
74.95% <0.00%> (+0.59%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


catch_pokemon: never_capture does not work

Expected Behavior
*A wild Pidgey appeared!* (CP: 235) (NCP: 0.35) (Potential 0.27) (A/D/S 6/1/5)
Great Curveball throw! Used Pokeball, with chance 38.66 (3 left)
Captured Pidgey! [CP 235] [NCP 0.35] [Potential 0.27] [6/1/5] (17/600) [+160 exp] [+100 stardust]
Actual Behavior
*A wild Pidgey appeared!* (CP: 235) (NCP: 0.35) (Potential 0.27) (A/D/S 6/1/5)
Skip ignored Pidgey! (CP: 235) (NCP: 0.35) (Potential 0.27) (A/D/S 6/1/5)
Steps to Reproduce
Update to the latest dev commit
And use
"catch": { "Pidgey": { "never_capture": true } }
docs/configuration_files.md
Additionally, you can specify always_capture and never_capture flags.
For example: "Pidgey": {"never_capture": true} will stop catching Pidgey entirely.

You inverted the Expeted Behaviour and the Actual behaviour.
With the rule "catch": { "Pidgey": { "never_capture": true } } the bot is supposed to skip all Pidgeys. But it doesn't.

replace "never_capture" in the config file with "never_catch".
from pokemon_catch_worker.py:
if pokemon_config.get('never_catch', False):
    return False

if pokemon_config.get('always_catch', False):
    return True

never_capture is incorrect. should be never_catch as stated. PR #5598 will fix this.


Version Issue Tensorflow and keras

Code is written in tensorflow and keras version 1 . can you change the code to tensorflow 2 and also keras,
Due to this issue we cannot run code as tensorflow 1 is unable to download and use right now.

please reply on this issue

nope
On Tue, 14 May 2024 at 19:07, shivakrishna karnati @.***>
wrote:

Hi @subhash137 https://github.com/subhash137 did you solve this issue?
—
Reply to this email directly, view it on GitHub
https://github.com/mdhmz1/Auto-Annotate/issues/30#issuecomment-2110268285,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AW6YNHLTNDU2R2527VOL73DZCIHRHAVCNFSM6AAAAABAXOVGW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQGI3DQMRYGU
.
You are receiving this because you were mentioned.Message ID:
@.***>


Disable audio testing

Pull Request instructions:

Please follow the update protocol
Answer the questions below in detail. Your responses will be emailed to experimenters.
If the experimenters must do anything new, provide detailed step by step instructions on the wiki
If computer maintainers need to manually update anything, provide detailed step by step instructions
Use markdown syntax in order for your comments to be rendered reliably in the email: "1." instead of "1)", use four spaces for indents.
If you use the keyword "skip email" in the title, it will skip the email updates
Merges from "develop" into "production_testing" should use the keyword "production merge" in the title for reliable indexing of updates
Merges from "production_testing" into "main" should use the keyword "update main"

Describe changes:
Disable audio play from the computer in bonsai. This function is only used by me, and it would cause an issue when that computer couldn't play the audio.
What issues or discussions does this update address?
resolved: https://github.com/AllenNeuralDynamics/aind-behavior-blog/issues/572
Describe the expected change in behavior from the perspective of the experimenter
No
Describe any manual update steps for task computers
No
Was this update tested in 446/447?
Yes, in 447

I will directly merge it into the production_testing without approving to make sure 6B is functional next week.

@XX-Yin Can you also merge it into develop to keep the branches synced?

@alexpiet I also merged into the develop


chore: Task Workers Revamp

Decoupled Worker Tasks
Worker tasks are now abstracted such that routes now send jobs via a JobClient decoupled from where the work is performed. A standalone noosphere_gateway::jobs::worker_queue module provides the work distribution logic, with each processor receiving a GatewayJobContext that provides access to sphere contexts, IPFS, and name resolvers when processing a job.

Worker jobs can now queue up additional tasks on success (IPFS Syndication -> Name Record Publish) (https://github.com/subconsciousnetwork/noosphere/issues/606).
Jobs can be retried upon failure.
Some timeout logic has been implemented, but not yet ready.
Republishing name records is now its own job type. Eliminates the need for the scheduler to resolve the latest name record.

Minimize external queries
GatewayManager and routes were updated to minimize GM queries (https://github.com/subconsciousnetwork/noosphere/issues/753).
In addition to a single, cacheable baseline query for scope, unauthenticated routes now has one less external query, and authenticated routes also has one less external query, with another query moved behind authorization.
Ultimately handler logic should not be changed, other than moving Push handler's queueing of name record publishing behind IPFS syndication.
Caveats/Concerns/Enhancements

We should do some profiling to measure lock contention across workers where appropriate amongst shared resources like KuboClient and the name resolver.
Job processors may need to be rethought in order to better take advantage of retries e.g. classifying a failure between retriables, invalid state/unretriable, and failed-but-ok-to-lazily-try-again-later.
Implement timeouts in worker queue. Timeouts now implemented
Ipfs syndication revision parameter now optional (unused? to confirm)
Ensure name record provided to PUSH is still valid after Ipfs syndication completes due to record expiry

Added explicit checks on existence of name records after syncing changes in tests, possibly clearing up a handful of intermittent failures.
Windows builds are having an unrelated issue: https://github.com/subconsciousnetwork/noosphere/pull/805

Updates (commit):

Changes/cleanups from feedback
Remove vestigial revision in IpfsSyndication job
Reduce indirection from cloning (e.g. use outer Arcs, not inner)
s/ContextResolver/SphereContextResolver
s/NameResolverExt/NameResolverPoller
s/WorkerQueueThread/WorkerQueueOrchestrator
More documentation for worker_queue


added typescript definition types

@hemerajs
May you check this?

@hemerajs
May you check this?

Thanks for the PR! Please add a test with https://github.com/SamVerschueren/tsd for the types. Here is an example https://github.com/StarpTech/next-localization/blob/master/types/index.test-d.ts

Thanks for the PR! Please add a test with https://github.com/SamVerschueren/tsd for the types. Here is an example https://github.com/StarpTech/next-localization/blob/master/types/index.test-d.ts

@StarpTech
I added a tsd test in #17

@StarpTech
I added a tsd test in #17

#18  looks good to me
@StarpTech  pls go ahead with #18

#18  looks good to me
@StarpTech  pls go ahead with #18

Released with 3.1.0.

Released with 3.1.0.


There is code only supported by Python 3.6+, while no Python version requirement is specified

There is line like https://github.com/dr-leo/pandaSDMX/blob/a31249da9a11e400a2b2f410d16e0010b4ff56af/pandasdmx/api.py#L145 which is using f-string and only supported by Python 3.6 and +.
However, there is no python_requires specified anywhere like setup.py.
So we need to either avoid using features like f-string which is only supported by the relatively new Python versions, or specify python_requires so users know they can only run the package using specific Python versions.

Another example is https://github.com/dr-leo/pandaSDMX/blob/a31249da9a11e400a2b2f410d16e0010b4ff56af/pandasdmx/api.py#L177

Thanks for spotting. I'll add this as suggested.
Leo
On 14/10/2019, Xiaodong<EMAIL_ADDRESS>wrote:

Another example is
https://github.com/dr-leo/pandaSDMX/blob/a31249da9a11e400a2b2f410d16e0010b4ff56af/pandasdmx/api.py#L177
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dr-leo/pandaSDMX/issues/110#issuecomment-541486721

Python 3.8 and 3.7.5 were recently released.
So, at the same time as we fix this, we can ensure Travis tests on the provided versions 3.6, 3.7 (latest, rather than the currently hardcoded 3.7.5), and 3.8.

To avoid potential misunderstanding, to me what's lacking here is something like this https://github.com/pandas-dev/pandas/blob/b0f33b3f40d5742531e31aef90573b9592489592/setup.py#L822

To avoid potential misunderstanding, to me what's lacking here is something like this https://github.com/pandas-dev/pandas/blob/b0f33b3f40d5742531e31aef90573b9592489592/setup.py#L822

Yes, thank you. I'll ask for your review on #114!


Enabling hotloading

Hi Tomer,
Quick question: Is there a way to setup hotloading in the app to avoid npm run build after every code modification?

hi @ssbozy
unfortunately no, BUT,
if the only thing you try to test is UI, then
you can just npm start and it will start the project in the browser
and then you will have updates everytime you make changes to the files,
you get it for free via webpack dev server.
I used this feature A LOT to setup my UI and iterate quickly
hope this helps

Hi @HendrixString Thansk for the quick tip. I am also trying to run some CSInterface commands along with the UI and testing both without having hotloading seems to be a pain.

I feel your pain in that matter


feat(NgbModalBackdrop): add NgbModalBackdrop needed for Modal support

This one should be fairly easy to review :-)

LGTM for an initial start - we'll probably want to implement backdrop clicking logic later for dismissing the modal, but that can come later.

Oh, I see the backdrop logic is in the modal window

Exactly - if I understand things correctly the HTML structure is different in B4.

Do we need a component for something without template?

Do we need a component for something without template?

We can't dynamically load directives, so pretty much yes.... I'm sure that there are alternative designs so I'm open to other suggestions.

Didn't know about that limitation. Good for me then.


build: return Makefile

Maintaining a Makefile isn’t that big of a deal, then why remove it? Can we just keep it alongside the new Task?

[x ] I have reviewed CONTRIBUTING.md.
[ x] My commits and title use the Conventional Commit format.
[x ] I have documented changes and additions in the CHANGELOG.md.

Can we just keep it alongside the new Task?

no, what is the point of having 2 task runners or build systems. i am also personally not interested in having to maintain both even if it is "no effort," see #171 for the entire reason that the move to task was done
if you have a real and compelling reason to switch back then you can comment and reopen


treewide: add mainProgram

Description of changes

Ref #269360, #269501, #270366
I've used a semiautomatic approach to add mainProgram attributes to several programs.
I used a verification script for the names of the binaries, so there shouldn't be any typos. I've tried my best to avoid programs where it's not obvious that the only binary in the package should not be considered a mainProgram, but I haven't dug deep into any of the packages so there might be some mistakes.
nixpkgs-review rev HEAD reports no changes
Covered directories:

pkgs/applications/audio
pkgs/applications/display-managers
pkgs/applications/emulators
pkgs/applications/file-managers
pkgs/applications/finance
pkgs/applications/graphics
pkgs/applications/logging
pkgs/applications/misc
pkgs/applications/office
pkgs/applications/radio
pkgs/applications/search
pkgs/applications/system
pkgs/tools/admin
pkgs/tools/bluetooth
pkgs/tools/games
pkgs/tools/networking

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Diff LGTM. The previous ones were backported, but that was likely due to being close to the 23.11 branchoff. I'll defer the backport decision to someone else.

My personal opinion is that it would be fine to backport this even if we're further away from the 23.11 branchoff now. I don't think any of changes here are breaking changes, right?


apibreak-compatible NeoHdf5IO

The current implementation of NeoHdf5IO (in the 0.4.x branch) is very dependent on the Neo object model.
This causes problems for reading files created with Neo 0.3/0.4 in Neo 0.5.
This pull request introduces a new, read-only implementation of NeoHdf5IO, which is capable of reading files created with Neo 0.3/0.4. (Because of the tight coupling between the current IO implementation and the object model, it seemed easier to reimplement from scratch rather than adapt the original code).
Write support could be added, but since other, more widely-supported HDF5-based formats (NIX, NWB) have IO classes under development for Neo 0.5, it would be better, in my opinion, to save data in one of these formats.
Note that the tests rely on a data file created with Neo 0.4.0, which needs to be uploaded to G-Node.

Coverage decreased (-0.02%) to 55.705% when pulling f5410946839f810ffb40de3d6fb4bbe6589d4189 on apdavison:new-hdf5io into fca866b330518273b6122a72d9c1aa0a7439ee8e on NeuralEnsemble:master.

This sounds good.
OK for me.