xarray mean generates unstable dask name (hash)

Code Sample
import dask.array as da
import xarray as xr
import numpy as np

# create dask array
x = da.ones((5, 5), chunks=(2, 2))

# create xarray array
x2 = xr.DataArray(x, dims=['d1', 'd2'])

# print dask name after taking mean
x = x.mean(axis=0)
print(x.name)

# print dask name after taking mean
x2 = x2.mean(dim='d1')
print(x2.data.name)

# confirm both functions do the same
print(np.allclose(x.compute(), x2.data.compute()))

Problem Description
Running the above sample three times outputs:
mean_agg-aggregate-9716da6e38d695dbff18f713d787e614
mean_agg-aggregate-02c33c19e6209edbe409749388d2f9f0
True

mean_agg-aggregate-9716da6e38d695dbff18f713d787e614
mean_agg-aggregate-2f59be8ef8c35336717fdcd7744bd167
True

mean_agg-aggregate-9716da6e38d695dbff18f713d787e614
mean_agg-aggregate-822994428d6b4cdea8e5c134711e5609
True

which shows the dask name (hash) generated using the xarray mean is unstable.
Expected Output
For processing large datasets, it's convenient to have a stable hash name in order to save intermediate results or compare them among developers.

Current workaround: unwrap dask array and recreate xarray array.

 That's the function we actually use under the covers in xarray.

Indeed, dask.array.nanmean() doesn't have a stable name. I will raise the issue in the dask rep.


Error when using custom network

When using a custom network the snap returns an error: Invalid configuration schema - Network name should be provided even though a network name was specified.
When connecting from a DApp the snap appears to still work anyway but the error still appears in the console.
E.g: https://pioneer-2-git-feature-metamask-snap-joystream.vercel.app
However when I run the snap locally or publish it myself this does not happen.
Is this the expected behavior for the published version of the snap ? If so could the error be more explicit ?

Hi @irubido,
Yes you're right the issue is fixed now.
Thank you :pray:

Hey @irubido, hope you are doing well! Just following up on that, it's been almost a month since the Github 0.9.0 release but the snap store is still at 0.8.2, is the audit expected to take that long?


callbacks from chained procedures should all run, not override each o…

…ther

Looks good! I have an open PR for some testing of zod safe function callbacks - thoughts on adding tests specifically for procedure callbacks?

Looks good! I have an open PR for some testing of zod safe function callbacks - thoughts on adding tests specifically for procedure callbacks?

Yeah good idea -- can you cherry pick this commit into your testing branch and add tests for chained procedure callbacks. We can then close this PR and merge them in your PR

moved to #92


Dropdown selected item text should be gray

Description
the selected text in a dropdown used to be blue, but recently changed to gray 800 (matches the other text in the list)

@labrowne , is this issue still relevant?

@labrowne looks like it's fixed, yes? https://opensource.adobe.com/spectrum-css/2.14.0/docs/menu.html#standard

i dont see blue text, which is good, but shouldnt there be a blue checkmark next to the selected item still?

Yup, that's what we've got:

See http://spectrum-css-archives.s3-website.us-east-2.amazonaws.com/2.14.0/docs/dropdown.html#standard
I'll go ahead and close this issue.


utdanning/elev/elev missing from api

https://play-with-fint.felleskomponent.no/administrasjon/personal/
does not contain utdanning/elev/elev as entry.
This should be included.

Closing issue as it has been resolved in Regenerate using fint-consumer 2.1.0 #6 21.11.2019
https://github.com/FINTLabs/fint-consumer-utdanning-elev/pull/6


Allow to create OrchestrationTemplate from old types

Temporarily maintain backward compatibility for API users. Should be removed later.
Due to our recent work to rename OrchestrationTemplate subclasses, existing customers that use API to create template may fail the creation. See comments on https://github.com/ManageIQ/manageiq-api/pull/63.
Our UI users should not have this concern.
@abellotti How do we let API users know that the old types are deprecated?

@miq-bot add_label refactoring
@miq-bot assign @gmcculloug

At least a mention in http://manageiq.org/docs/api. Thanks.

@abellotti added a test for key being a string.

@miq-bot add_label gaprindashvili/yes


Build Doesn't Have a "--Prefix-Path" Option?

using phaser v3.22 on macOs v10.15.3
I'm having issues deploying to gh-pages, and I'm pretty sure it had to do with phaser-scripts build not taking into account the "prefix path" that gets added when deploying to gh-pages.
For example, I made a build using phaser-scripts build which created an index file that looks like this:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1, user-scalable=no"
    />
    <title>Phaser Project</title>
    <link rel="shortcut icon" href="/static/favicon.png" />

    You need to enable JavaScript to run this app.

I then deploy it to the site here: https://everybodycodes.github.io/Phaser-Fish-Game/
And I get lots of errors for all the files because it is trying to look for them at a location that doesn't include Phaser-Fish-Game...
Sadly, I can't find any option to add the prefix-path to the phaser-scripts build command and don't get much help when running phaser-scripts --help or phaser-scripts build --help...  😢

This issue has been mentioned on Phaser. There might be relevant details there:
https://phaser.discourse.group/t/errors-when-trying-to-host-on-gh-pages/5832/3

Lol are you a bot @photonstorm ?
that is my post with no one else posting on it... 😁

Seems like someone got it working my manually going through the build folder and changing all the file paths... is this the only way? 😢
https://www.html5gamedevs.com/topic/36571-host-phaser-game-on-github/

Not sure which build script you're using, but it doesn't sound like one we created. Maybe some 3rd party template? Anyway, if it can't load assets, then just set the base URL / path in the calls to the Loader. It's the Loader code that's important here.

Hmm I use the phaser-cli's scripts to build my project. I didn't realize that was not part of phaser...
https://github.com/EverybodyCodes/Phaser-Fish-Game/blob/master/phaser-fish-single-player/package.json#L7
Also, I'm not sure what you mean by "calls to Loader". There is no reference to a Loader anywhere in my project. 🤔

Yeah, Phaser CLI isn't something we created, it's a pet project by a member of the community and I'm not familiar with how it handles bundling assets. It would be better to ask the maintainer, really.
re: Loader - Are you not loading any graphics in your game at all? No pngs, etc? The Phaser Loader is what, well, loads them. And you can control the base URL / path prefix directly from it.

Aha, I see what you mean now.
In my boot phase I'm now doing this:
this.load.setBaseURL('https://everybodycodes.github.io/Phaser-Fish-Game/')
But when I build and deploy it doesn't seem to be looking in a different place for the files...
I also tried :
this.load.setBaseURL('/Phaser-Fish-Game/')
and
this.load.setBaseURL('Phaser-Fish-Game')
Sadly, the documentation (https://photonstorm.github.io/phaser3-docs/Phaser.Loader.LoaderPlugin.html) for setBaseUrl doesn't really explain what is the correct string to pass to this function.

This issue has been mentioned on Phaser. There might be relevant details there:
https://phaser.discourse.group/t/how-to-use-setbaseurl/5836/1

@photonstorm can you please elaborate on how to use this setBaseUrl properly?
I asked  the question in that thread you mentioned, but the users responding don't seem to understand my question...

Someone helped me to get it working there, but I didn't set the baseUrl... 🤷♂


goog.i18n.DateTimeSymbolsType should declare the types of its properties

As discussed here, goog.i18n.DateTimeSymbolsType currently declares all of its types as unknown instead of
/**
 * @typedef {{
 *   ERAS: !Array<string>,
 *   ERANAMES: !Array<string>,
 *   NARROWMONTHS: !Array<string>,
 *   STANDALONENARROWMONTHS: !Array<string>,
 *   MONTHS: !Array<string>,
 *   STANDALONEMONTHS: !Array<string>,
 *   SHORTMONTHS: !Array<string>,
 *   STANDALONESHORTMONTHS: !Array<string>,
 *   WEEKDAYS: !Array<string>,
 *   STANDALONEWEEKDAYS: !Array<string>,
 *   SHORTWEEKDAYS: !Array<string>,
 *   STANDALONESHORTWEEKDAYS: !Array<string>,
 *   NARROWWEEKDAYS: !Array<string>,
 *   STANDALONENARROWWEEKDAYS: !Array<string>,
 *   SHORTQUARTERS: !Array<string>,
 *   QUARTERS: !Array<string>,
 *   AMPMS: !Array<string>,
 *   DATEFORMATS: !Array<string>,
 *   TIMEFORMATS: !Array<string>,
 *   DATETIMEFORMATS: !Array<string>,
 *   FIRSTDAYOFWEEK: number,
 *   WEEKENDRANGE: !Array<number>,
 *   FIRSTWEEKCUTOFFDAY: number
 * }}
 */

Apparently this file is generated by a Python script

As far as I can tell, that part of the file is actually maintained manually. In any case this should be filed under closure-library.

Could you file it against closure-library instead? Thanks.

Yep, it is manually generated. DateTimeSymbolsType used to be unspecified and I recently fixed it to at least provide the names of the properties at commit https://github.com/google/closure-library/commit/ea5a80b3b48b25f56ef7572894dd8e64a355bb3f. The reason I didn't provide the full types is that it required cleaning up projects that use Closure internally. I suspect it's not high priority either for the library team to clean those up.

I changes are pretty minor, I have a change pending but it needs to be farmed out, it will likely be a week or so


Simplification rule not applied before regular rules in a specific setting

Test excerpt from KEVM, file verif.k:
module VERIF
    imports DOMAINS

 // KEVM code
 // -----------------------------------------------------------

    syntax Set ::= "#precompiledAccounts" "(" ")" [function]
 // -----------------------------------------------------------
    rule #precompiledAccounts()           => SetItem(1) SetItem(2)

    syntax KItem ::= OpCode
    syntax OpCode ::= NullStackOp | InternalOp
    syntax NullStackOp   ::= PrecompiledOp
    syntax PrecompiledOp ::= #precompiled ( Int ) [function]
 // --------------------------------------------------------
    rule #precompiled(1) => ECREC
    rule #precompiled(2) => SHA256

    syntax PrecompiledOp ::= "ECREC" | "SHA256"

    syntax InternalOp ::= "#precompiled?" "(" Int ")"
 // --------------------------------------------------------------
    rule <k> #precompiled?(ACCTCODE) => #next [ #precompiled(ACCTCODE) ] ... </k>
      requires         ACCTCODE in #precompiledAccounts()
    rule <k> #precompiled?(ACCTCODE) => .                                ... </k>
      requires notBool ACCTCODE in #precompiledAccounts()

    syntax InternalOp ::= "#next" "[" OpCode "]"
 // --------------------------------------------------------
    rule <k> #next [ OP ] => OP ... </k>

    syntax Int ::= #newAddr ( Int , Int )         [function]
    rule #newAddr(ACCT, NONCE) => ACCT +Int NONCE [concrete]

 // ERC20 verifier code
 // -----------------------------------------------------------
    rule <k> #precompiled?(ACCTCODE) => #next [ #precompiled(ACCTCODE) ] ... </k>
      requires         #inPrecompiledAccounts(ACCTCODE)                            [priority(40)]
    rule <k> #precompiled?(ACCTCODE) => .                                ... </k>
      requires notBool #inPrecompiledAccounts(ACCTCODE)                            [priority(40)]

    syntax Bool ::= #inPrecompiledAccounts ( Int )                                 [function, functional]
    rule #inPrecompiledAccounts(ACCTCODE)  => ACCTCODE in #precompiledAccounts()
    rule #inPrecompiledAccounts(#newAddr(_,_)) => false                            [simplification]

endmodule

File precompiled-newaddr-spec.k:
module PRECOMPILED-NEWADDR-SPEC
    imports VERIF

    rule <k> #precompiled?(#newAddr(_, 1)) => . ... </k>
endmodule

Result:
  #Ceil ( #newAddr ( _0 , 1 ) )
#And
  #Ceil ( #precompiled ( #newAddr ( _0 , 1 ) ) )
#And
  <k>
    #precompiled ( #newAddr ( _0 , 1 ) ) ~> _DotVar1 ~> .
  </k>
#And
  {
    #newAddr ( _0 , 1 ) in SetItem ( 1 )
    SetItem ( 2 )
  #Equals
    true
  }

We expect [simplification] rule to apply for #inPrecompiledAccounts(#newAddr(_,_)), while it looks like regular rule applies.
https://github.com/kframework/k/tree/649744eb6291bf123c9d58670d8badbf329c2ec2/k-distribution/tests/regression-new/priority-simpl-combohttps://github.com/kframework/k/tree/649744eb6291bf123c9d58670d8badbf329c2ec2/k-distribution/tests/regression-new/priority-simpl-combo
In full ERC20 verifier a funnier thing happens. #precompiled ( #newAddr ( ... ) gets evaluated further on as if it's a non-function symbol, one branch apparently picks ECMUL, and K gets stuck with:
      <k>
        #ecmul ( ( #asWord ( b"70a08231" ++ ( #buf ( 32 , ?ACCT ) [ 0 .. 28 ] ) ) , #asWord ( #buf ( 32 , ?ACCT ) [ 28 .. 32 ] ) ) , 0 ) ~> #pc [ #precompiled ( #newAddr ( ?ACCT , 1 ) ) ] ~> #execute ~> #return 1728 32 ~> #pc [ STATICCALL ] ~> #execute ~> #successOrRevert ~> #setKAssertCount ~> .
      </k>

https://office.runtimeverification.com/jenkins/blue/organizations/jenkins/erc20-verification/detail/PR-150/11/pipeline/
Maybe it's a different bug.
This is required for ERC20 verifier.

Marking the last rule in definition with [priority(40)] doesn't change the result.
But defining last function like this leads to kompilation error:
    syntax Bool ::= #inPrecompiledAccounts ( Int )                                 [function]
    rule #inPrecompiledAccounts(ACCTCODE)  => ACCTCODE in #precompiledAccounts()   [concrete]
    rule #inPrecompiledAccounts(#newAddr(_,_)) => false                            [simplification]

Result:
[Error] Compiler: Found concrete attribute without simplification attribute on
function with one or more non-concrete rules.
        Source(/home/denis/erc20-verification/deps/evm-semantics/deps/k/k-distribution/tests/regression-new/priority-simpl-combo/./verif.k)
        Location(43,10,43,81)

Error points on rule with [concrete].
Looks like front-end has issues with last rule.

If priorities are not supposed to work with function rules, where should they be rejected?

What's your proposal for the separate bug on full KEVM? If this example couldn't reproduce it, then I don't know what triggers it. Should I open a separate issue and keep a special ERC20 branch for it? Seems rather serious.

If priorities are not supposed to work with function rules, where should they be rejected?

priority does work with function rules. You cannot nest functions on the left-hand side of a function rule, unless you use the simplification attribute. (This should be detected by the frontend, see kframework/k#1588.)

What's your proposal for the separate bug on full KEVM? If this example couldn't reproduce it, then I don't know what triggers it.

There is a guard in the backend that prevents narrowing when applying function rules. I think it's too liberal in the case where the rule binds no variables. I will try to make a minimal example.

In full ERC20 verifier a funnier thing happens. #precompiled ( #newAddr ( ... ) gets evaluated further on as if it's a non-function symbol, one branch apparently picks ECMUL...

I created a minimal example to investigate this, and I am convinced that the backend is doing the correct thing here. It's not evaluating #precompiled( #newAddr(_, _) ). You can see that this term remains unevaluated in the configuration. Actually, a rewrite rule has ECMUL on the left-hand side, and tries to unify with #precompiled( #newAddr(_, _) ), producing #precompiled( #newAddr(_, _) ) #Equals ECMUL. There is nothing in the definition to contradict this branch, so execution continues. Here is a small definition and spec which reproduces this behavior:
test-2.k:
module TEST-2
  import INT

  syntax Bool ::= fun ( Int ) [function]
  rule fun(1) => true
  rule fun(2) => false

  syntax Int ::= i ( Int ) [function]

  syntax KItem ::= "#true" | "#false" | "#assert" Bool

  rule <k> #assert true => #true </k>
  rule <k> #assert false => #false </k>
endmodule

test-2-spec.k:
module VERIFICATION
  import TEST-2
endmodule

module TEST-2-SPEC
  import VERIFICATION
  claim <k> #assert fun(i(X:Int)) => #true </k>
endmodule


proposal: allow implicit conversion of error to bool in if statements, fmt on one line

A couple weeks back during a proposal review, reviewing the fiftieth or so error handling proposal, I made a somewhat flippant remark that if we made if err != nil {\n return nil, err \n}\n shorter, most of the error handling proposals would go away. (At least the more incomplete ones)
I then mentioned two things we could do pretty easily:

allow just:

if err {

... instead of:
if err != nil {

That is, if the static type of a variable is exactly and only error, allow conversion to a boolean.
"But that's not orthogonal, why would you make error special?" Yes. But errors are already special. They're the only interface predefined in the language. And they're incredibly common.
Even if somebody is momentarily confused why it works, it's at least not ambiguous.
IIRC, we discussed a bit whether to allow it in all boolean contexts, just in boolean expressions inside an if condition (so if !err { would work), or only when it's the entire expression in an if (only if err {).

modify gofmt to format those on a single line (previously proposed and rejected in #27135):

if err { return err }

Later, if we do #21182, that extends to:
if err { return ..., err }

But if you have any non-return statement in the if body, then it formats as multiple lines.
Taken together, this makes error handling much lighter looking (the common motivation for new error handling proposals), while keeping flow control unchanged and explicit (a common argument against most error handling proposals).
I made these comments mostly as a joke at first, but the more we talked about, the more we didn't outright hate the idea. I reluctantly agreed to file an issue, so here it is.

allow just if err { instead of if err != nil {

Only after if and only if it's the whole expression? If so, sounds good.

modify gofmt to format those on a single line: if err { return err }

Would this also work with annotated (wrapped) errors, e.g. fmt.Errorf("annotation: %w", err)? If so, sounds good; if not, strong -1.

This actually makes a lot of sense to do in my opinion. Both saves time writing and makes error handling look a lot cleaner. Sounds good to me :+1:

Personally I don't see much difference between if err { over if err !=nil {, however your thoughts inspired an alternative idea.  Why not just introduce a new Keyword, like returnIfError?
If would be used to replace the cases of
if err != nil {
    return err
}

With
returnIfError err

Or if one wants to wrap the error;
returnIfError fmt.Errorf("annotation: %w", err)

Other more complicated cases would stick with the existing If statement
if err != nil {
  // do some other logic here
  // ...
  return err
}

Whether the Keyword returnIfError is a good selection or not could be debated and given some thought, something shorter to type is probably better, maybe and abbreviation reterr or what ever the community comes up with.

As a C programmer, I often miss if ptr constructs, but I recognize the confusion they can introduce.
Would you want this to work also for if a, err := foo(); err {?
I have actually been thinking about this same thing, because I frequently end up with, roughly:
a, err := f1(...)
if err != nil {
    return a, err
}
b, err := f2()
if err != nil {
    return b, err
}

and what I really want for a lot of these is basically "return these values if [this condition involving these values]". But in 99% of cases, the condition is "the last one, which is an error, is non-nil".
the ugly answer:
erreturn a, err

I like the idea of being able to test for errors this way, but I really feel like if you were going to make this change, that you would just make the bigger change for truthy testing any value. I get that error is a special case interface but I don't think users are likely to think of that when they find they can only truthy test an error interface and not any type. It will feel like a quirk where the language is unbalanced.
But I do remember the reasoning for not having it for all types being something like it leads to confusion or bugs when you mistake the type you are testing? I don't know about that. You still have static typing and no-implicit-conversion to protect you later when you use the value in other ways.
What is the downside of this example?
var s []string
if s {
  ...
}

It sound like a good compromise when we can still choose to keep if err != nil on 3 lines if we want.
It should be easy to test and revert if needed. That could be pretty fun at the moment !

@peterbourgon would be very strange that this
err := foo()
if err {}

is allowed but this
if err := foo(); err {}

is not.
@justinfx the problem is that empty slice and nil slice are both useful and practically identical in most of the cases (len, cap, append all treat them equally). But your example would probably handle them differently and cause mistakes and confusion.

@creker , honestly I would have just thought of an empty and nil slice to both be false, if I were to use truthy testing instead of explicitely checking a length or comparing to nil. The language lets you call len on a nil slice to get a length of 0 anyways, so one could say it already allows nil and empty slice to be treated the same.
If the truthy behaviour is defined then its just something to know about the language.

@swdee, there are plenty of proposals already open for new keywords like that. This is specifically what this issue is trying to avoid.

@peterbourgon, returning wrapped errors seems reasonable, yes.

@creker, writing:
if err := foo(); err {}

... separates the word "if" from the word "err" (error). Since it no longer reads "if error", I think it's totally reasonable to require that be written the normal err != nil way, with no fmt changes.

@justinfx, many downsides. Like others said: it's ambiguous whether that means len > 0 or != nil.

@bradfitz it's fine if gofmt doesn't format it as a one liner but it doesn't make sense disallowing
if err := foo(); err {
}

That just means language spec would have some strange rule about completely identical code (apart from err scope which is irrelevant here) being treated differently by the compiler. I would expect Go to be consistent in its syntax.

@creker

it doesn't make sense disallowing . . .

Yes, it does.

@peterbourgon what is the objective reasoning? I understand if you personally don't like how it looks but that shouldn't affect language spec if it introduces inconsistencies in it. Gofmt is where subjective reasoning should live and there formatting such cases as one line could be disallowed. There it actually makes sense because one liner could become too wide.

What is the downside of this example?
var s []string
if s {
  ...
}

That I don't know what it means. You might mean "if s is non-nil", you might mean "if s has a length other than zero". Heck, you might mean "if s contains at least one string which isn't an empty string".
I think it's pretty reasonable to only accept the exact form if err and not the longer form with the prior assignment. It's syntactic sugar, it can be narrowly-focused, and I'd definitely prefer the != nil to still be present in the longer lines so I have an easier time reading them.
if a, b, err := threeReturns(...); err
makes it a bit too easy for me to miss the nature of the condition.
if a, b, err := threeReturns(...); err != nil
is clearer.
The argument here is just that, for the very specific case of if err != nil, allowing the != nil to be omitted doesn't obscure things, because there's no other expressions nearby that can visually subsume the err.
I don't think this breaks the syntax much. The proposal here isn't to allow single error values to be truthy expressions; it's to allow the special case if errorValue as an alternative to requiring if statements to take truthy expressions.

The proposal here isn't to allow single error values to be truthy expressions;

That's not decided per the proposal

IIRC, we discussed a bit whether to allow it in all boolean contexts, just in boolean expressions inside an if condition (so if !err { would work), or only when it's the entire expression in an if (only if err {).

It does introduce inconsistencies in the language if we start disallowing syntactic constructs just because we don't like them. If we make if err a special case and not treat error types as false in all possible cases (at least inside an if statement but ideally it should include all types of expressions) it makes the proposal even worse. That would make whole thing confusing and unintuitive. Image someone just starting to learn the language. How would you justify it? Right now the reasoning is "some people didn't like how it looks". If that's the price to save a few strokes then I vote against such proposal. Either implement it properly or don't implement it at all.

@creker

It does introduce inconsistencies in the language if we start disallowing syntactic constructs just because we don't like them.

There's nothing wrong with this.

@peterbourgon there is and it's called bad language design. Language should be consistent and intuitive. If someone sees if err then the only logical conclusion is that error types can be implicitly converted to booleans (and the proposal clearly says "allow conversion to a boolean"). That means all the following cases should also work
func foo() error {
}

if err := foo(); err {
}

var result bool
result = err

The last one is unfortunate consequence of the proposal but it must work, otherwise the whole thing becomes a mess of special case syntactic sugar that doesn't mean anything (in other words, it no longer means implicit conversion to boolean. It now means "we like how this looks, let's allow it").

Overall, I like how refreshingly simple this proposal is, compared to most other error handling proposals. It deals with the verbosity without adding too much magic.

But if you have any non-return statement in the if body, then it formats as multiple lines.

I think this rule could be simplified to: this kind of if statement is allowed to fit in a single line if its body is exactly one statement, and its length is short enough.
This rule is already in place in gofmt, for single-line functions. The heuristic is just not explicitly defined, because it might change in the future. See it in practice - click "format" on https://play.golang.org/p/rEyBUh5rj7V

this makes error handling much lighter looking (the common motivation for new error handling proposals)

I think another point in favor of the handle proposal was to consistently wrap errors in a function:
// go2 draft
func process(...) error {
    handle err { return fmt.Errorf("process: %w", err) }
    check doFoo()
    check doBar()
}

// this proposal
func process(...) error {
    if err := doFoo(); err { return fmt.Errorf("process: %w", err) }
    if err := doBar(); err { return fmt.Errorf("process: %w", err) }
    return nil
}

Note how we repeat the error wrapping/decoration. This is good if we want the call site to decorate an error with the function that was called, but I thought the point of the go2 draft was also to encourage functions to decorate errors with their own information when returning.

I think it's good to be consistent and logical up to a point, but syntactic sugar is frequently special-case exceptions. We already have unusual rules on the behavior of if statements; the "if a := expr; a != 23" construct isn't a way you can spell an expression in any context other than an if statement, and it's not quite equivalent to having the first expression simply before the if statement, because it has different scoping.
I would prefer "an if statement can take an expression which is either any expression of type bool, or a single identifier referring to an object of type error" to "automatic conversion of some things to bool". I don't think the proposed change here would have much impact on my daily life, but I'd probably use it. A change allowing error in general to be used as a conditional expression, or pointers or interfaces in general, would be a major change, and I'd guess that I'd end up being hurt by it more than I'd be helped by it. (Although I'm not sure; I got very used to "if (p)" in C, and sort of miss it sometimes.)
I would be pretty strongly opposed to a general "implicit conversion to boolean". I would not object to conditional operations, like for or if loops, being able to take interfaces, or pointers, or possibly just error in particular.
As it gets more general, it gets more confusing. Consider:
for n, err := r.Read(buf); !err; n, err = r.Read(buf) { ... }

I would be thrown off by this even given the assumption that "err" could be used as a control expression for an if statement. It wouldn't confuse me in C, but in C, we're already used to pointers being usable as truth values.
That said... What about cases where we'd return early on success?
At the risk that it will make this proposal seem dangerous, consider:
err := happyPath()
if !err {
  return nil
}
// handle the complicated path

This, coupled with the above, makes me think that this absolutely should not imply a general conversion of error to bool, but rather, should be a special case of the if statement.

I'm fine with 2. I'd prefer if it's further limited only to if's that contain a return/break/continue statement. That's not especially important to me.
1 makes me uneasy.
If it's just limited to error, does it mean I can't use it with a value of net.Error? I can see why not, but overall the definition seems a little too special. I don't think it's going too far to just extend it to any interface value even if the target is specifically error.
Other boolean contexts seems like it could get convoluted. I could see if !err { as a single special case but I think disallowing it wouldn't provide any problems. Writing if err == nil happens but it's fairly rare, ime.
I don't have any problem with if x := f(); x {}. It looks exactly as clear to me. It can be avoided and linted against by parties that find it a concern.

Limiting the if to only contain a return/break/continue makes it not apply for testing, like
if err != nil { t.Fatal("unexpected error:", err) }
if a != b { t.Fatal(a, "does not equal", b) }

which that style I think would help remove the desire and proliferation of incompatible assertion style testing libraries.
For those situations, one could even consider going further and adding brace alignment to aid visual scanning:
if err != nil { t.Fatal("unexpected error:", err) }
if a != b     { t.Fatal(a, "does not equal", b) }

But, there's no existing precedent to do that alignment with function or struct literals like there is for allowing the whole thing to exist on a single line.

During the try proposal, I also brought the single line if statement idea up (https://github.com/golang/go/issues/32437#issuecomment-499161412) and many of the points I describe there also apply here:

It requires no language changes.
The formatting rule is simple, clear, and has precedent with function and struct literals.
It doesn't cause any existing code to need any changes, and it would all still be in canonical gofmt form.
It is hard to imagine that a formatting only change could cause any negative interactions with any future extensions to error handling that may be considered.
Applies to testing and not just error handling.

In my estimation, the amount of win you can get by allowing the discerning author to place if statements on a single line easily pays for the complexity and implementation cost. It has no negative interactions on existing or future code, greatly reducing the risk. And since there have already been changes to gofmt that changed existing code's formatting, the path to reverting it in the future is open and minimally expensive.
As far as worries about abuse, there are already a multitude of places where gofmt allows the author to choose between one line or multiple: functions (literals and declarations), struct/map/slice literals, type definitions, allowing semicolons on a single line (https://play.golang.org/p/Yr0bfdQPTrp), vertical spacing between imports, and I'm sure more. Yet we rarely see any of those absued.
I think it's a very nice gradual step forward to reducing the page weight of error handling, even if it doesn't reduce the amount of ink on the page.

I feel we really need a dedicate keyword to catch error type. There is no second guess.
catch err { return ... }

@zeebo that's a fair point about testing

What is it for?  Just to cut a couple of characters? It’s pointless.

@creker,

The last one is unfortunate consequence of the proposal but it must work, otherwise the whole thing becomes a mess of special case syntactic sugar that doesn't mean anything

We definitely would not want var _ bool = err to work. Only for if.
Yes, this proposal is just syntactic sugar. But that's kinda the point: it stemmed from a discussion of what the minimal sugar we could add to appease the largest number of people without much more intrusive (and probably controversial) language changes.

One clarification, should we leave for and switch/case without any modifications?
I suppose yes, due to overwhelming majority of if err != nil pattern.

@bradfitz in that case the proposal description is misleading. There's no "allow conversion to a boolean" going on any longer. The proposal now is about liking some piece of syntax that doesn't exist in the language. Meaning, before compilation if err { is implicitly unfolded into if err != nil { by the compiler. In that case I no longer like such a proposal. It's fine to explore this as a proper language construct but for me this is not worth polluting the language.

Instead of a language change, I'd prefer a (non-default) switch in go fmt that preserves certain single-line constructs, e.g.
case 1: stmt
for a := range s { x(a) }
if t { a() }
else { b() }
v := a; if t { v = b }

I'd be disappointed to see another error handling discussion engulf a lot of Go team time.
BTW, how's generics coming along? :-)

Imho introducing this feature specific for errors looks like workaround.
If this proposal will be considered, it makes sense to add this behavior to other nil-able items (and mb numbers).
But still not sure that this is a good way to solve the good-old if err != nil issue.

Implicit bool-ish-ness is one of programming's greatest mistakes, and that Go doesn't have it is one of its greatest strengths. This exception to that rule is specific, easy to explain/teach, and easy to understand. It would be the acme of foolishness to expand this exception into general bool-ish-ness for all types in the name of consistency.
That said, I don't really have any issue with error handling as-is, and I don't think the language needs this addition.

@creker,

@bradfitz in that case the proposal description is misleading. There's no "allow conversion to a boolean" going on any longer.

I guess I was more explicit if you read the title of the issue itself. The next words are "in if statements".

@peterbourgon

easy to explain/teach

That's exactly the problem, it's not. Like I already said, there's no objective reasoning here (you still didn't give any argument as to why it should work like that) and it goes against common sense. When you learn a new language feature you automatically try to apply it in a different context. This new sugar looks like implicit boolean conversion and works like that. The logical conclusion would be to try to use that conversion everywhere where you can already write "err != nil" or some other similar expression. That means, someone would definitely try to write all of these
if err := foo(); err {
}

if !err {
}

var _ bool = err

var ch chan bool
ch <- err

func test(arg bool){
}
test(err)

These examples are intuitive, logical, easy to explain and teach in one simple sentence - errors are implicitly convertible to boolean. That's it. What we have here would confuse people, would not give any explanation apart from "that's how it is, deal with it", require much more specification changes and just turn Go into something it is not. It's never been a language where you're not sure if something you write is a correct syntax.
But I agree that we don't want to allow all of those examples, so to quote you again

It would be the acme of foolishness to expand this exception into general bool-ish-ness for all types in the name of consistency.

I agree but it would be even more so to implement this just to introduce some cute syntactic sugar.

One thing to consider about allowing single line if statements is that
if cond { stmt }
else { stmt }

is not syntatically correct due to automatic semicolon insertion, so some sort of change or decision would have to be made there.

Would if f() { be legal with func f() error {?

Would if f() { be legal with func f() error {?

I wont able to guess it’s related to error.
catch err { ... } else ( ... }
catch err == Error.(type) { ... }
is widely understood in other languages.

@bradfitz what if you allowed Ruby-ish if statements following a return statement, coupled with implicit zero values for non-error types?
return err if err != nil

@jimmyfrasche, no.

Sorry for the "me too" but honestly @mvdan's proposal with handle (or check or whatever name) is still the cleanest and easiest to deal with.
Since it was rejected before, this seems like at least a step to make our lives easier.

I had actually explored this same idea myself, around the time when the other error proposal was being circulated. My conclusions/worries in respect to this specific proposal:

The special form of if err { might make other error handling constructs that do not fit the exact if err != nil { form seem out of place. This may lead programmers to refactor such code such that they can write if err { instead, which seems a counterproductive.

Having the error handling on one line isn't desirable IMO. Within the context of a function a return statement does something profound: it terminates execution. For that reason I think a return statement deserves its own line, with indentation if the return only executes on some condition, as it does today.

I think the consistency of having one way to check errors—arising naturally from the orthogonal concepts of expressions, if statements, blocks, and return statements—is a benefit higher than saving a few keystrokes and line breaks.

Although I promised myself that I wouldn't bother commenting on any more error handling proposals, this one may be unique in that (as I post this) it hasn't yet been heavily voted down! So here FWIW are my two cents.
Firstly, several people (including myself) have long advocated that go fmt should permit single statement blocks to be written on the same line as  the if  clause itself, where those statements are just return, break, continue or goto statements. It's always seemed anomalous to me that you can write a function block on the same line as the function declaration itself but are not allowed to do this. I therefore welcome the return part of the proposal even if it's not going as far as I would personally like.
I realize, of course, that there are many people who won't agree with this but as it would presumably be an optional part of the proposal, they could carry on writing the return statement on a different line as they do now.
As far as the if part is concerned, I would support it if and only if an expression of type error could be implicitly converted to bool. I think if you also support conversion of other nilable types and/or declaration of temporary variables within the if clause, then the essential simplicity of the proposal is lost and you may even find that the result is too long to write on a single line anyway :)

I'm not in favor of implicit error-to-bool, but if bool(err) isn't helpful. And the lion's share of this proposal can already be achieved by an alternative to go fmt.
I'd be disappointed to see another error handling discussion engulf a lot of Go team time. We were told the topic had been shelved after the community voted overwhelmingly against making any change. That was a well-considered decision.

or we have bool extension method on errors to return bools like
if err.IsTrue() {
//'. . .
}

or we can have bool extension method on errors to return bools like
if err.IsTrue() {
//'. . .
}

In such case:
if !err.IsNil() {
    // ...
}

would be more obvious

i believe your solution is more idiomatic as per language , and mine is more beginner friendly

@acnologia000

or we can have bool extension method on errors to return bools like
if err.IsTrue() {
//'. . .
}

In such case:
if !err.IsNil() {
    // ...
}

would be more obvious

i believe your solution is more idiomatic as per language , and mine is more beginner friendly

I think both of these look even worse than if err != nil.

I think both of these look even worse than if err != nil.

agree, also this has fewer characters :)

I think both of these look even worse than if err != nil.

I think both of these look even worse than if err != nil.

cannot disagree XD

C++ defines explicit conversions to bool as being special in the language, as they can occur implicitly in certain contexts. For example, if x is explicitly convertible to bool, then if x will call that conversion. However, trying to pass it into a function that accepts a bool won't work, because its not implicit.
I believe a similar approach would work in Go. Allow the error type to be explicitly converted to bool using the conversion operator as in bool(err), but also allow the conversion to occur implicitly in certain contexts, specifically inside an if statement condition. It would have to allow the ! operator to convert it to a bool for consistency.
This creates a small set of rules that to me seem very Go-like, as they are simple and can't be leveraged and overloaded by the user; it's just a special case.
On the other hand, if we were to simply allow the specific syntax if err, this will inevitably lead to confusion, as users will wonder why other constructs like if !err, if err := f(); err and if err1 && err2 don't seem to work. This kind of unexpected behavior is what I think a language feature should avoid.
It is similar to PHP's (int) and (float) constructs, designed to look like cast operators from C like languages to be familiar to users. However, they are misleading because there are no int or float types in PHP - the casts are just special syntactic features. It is very much like this, because a user will assume some conversion to bool is happening, where none is at all.

Based on the discussion above, this does not seem to be a clear win.  And the emoji voting is not strongly in favor.  Therefore, this is a likely decline.  Leaving open for four weeks for final comments.

Neat idea, but IMO it reduces clarity.  Something like ? to do the conversion would at least let the reader know what's happening.  if err? { return nil }  (Probably already several proposals involving a question mark floating around...)

I am new to the Golang party and aware that there is a ton of past proposals that I have not read, but might as well wade into the arena:
This proposal is nice in that it 1) accepts the reality that errors are special and unavoidable and 2) makes a minimal change for ergonomics that while are admittedly special-cased, are of such commonality as to fade into the background once adopted. I think of the semantics for how make operates on specific types. Why are slices and channels sufficiently special so as to demand language affordances that errors (which are far more common) do not?
I think when combined with an affordance that enables the low ceremony return of underlying errors, we can address 80% of the pain without introducing new keywords, flow control, etc.
To highlight what I mean, consider the introduction of a new error specific sentinel value (and maybe this should be a parallel proposal but this is where I am right now) of ^ that wires in the semantics of return error if not nil -- very similar to how _ throws away a value you don't care about.
Consider something like:
func readSomething() (string, error) {
        file, ^ := os.OpenFile("some_file", os.O_TRUNC|os.O_CREATE|os.O_WRONLY, 0666)
	defer file.Close()
        result, ^ := doSomethingWithFile(file)
        output, err := processResult(result)
        if err {
             // Try to recover from the error and return
        }
        return output, nil
}

IMO boilerplate check and return of errors and coercion to boolean is the essence of the error handling ergonomic issues

@blakewatters i like this idea for simple apps. But most of the time i prefer to wrap the error to add context. I think this idea was already discussed in the try proposal, but maybe you should still make a new proposal ?

Can someone teach me how to Hack bank account I don’t understand anything y’all saying but I wanna learn how to get to it 😁 I’m serious link me I’m all 👂

No change in consensus.

@blakewatters I really like your idea for its simplicity and resemblance to _. You could go fancy and even add error wrapping:
file, fmt.Errorf("..", ^) := os.OpenFile("some_file", os.O_TRUNC, 0666)

which is a bit hard to read with a later-called function on the left hand side.
We could also do something similar to extended if statement syntax:
file, ^ := os.OpenFile("some_file", os.O_TRUNC, 0666); fmt.Errorf("..", ^)

or, to make the return case explicit:
file, ^ := os.OpenFile("some_file", os.O_TRUNC, 0666); return fmt.Errorf("..", ^)

The last two variants could be combined with default  values to the non-error returns, too:
file, ^ := os.OpenFile("some_file", os.O_TRUNC, 0666); return "foo", fmt.Errorf("..", ^)

Different from this proposal this would allow to simplify a lot of error return statements to concise one-liners. Would it make sense to open yet another error proposal for this?

The guard statement in Swift assigns variables in the outer scope, as syntactic sugar for an if statement:
guard let foo = bar() else {
    return “error”
}

// Use foo here

If Go adopted it:
guard foo, err := bar() else {
    return err
}

// Use foo here

@andig @blakewatters.
+1 for a proposal to discuss your two proposals. But i'm pretty sure we already had this kind of proposal, if somebody remember ?

But i'm pretty sure we already had this kind of proposal, if somebody remember ?

Will wait some more to not raise this twice. A connection of @ydnar‘s suggestion of try/guard statement that is able to elevate variables out of block scope (which was my biggest pain) allows for using syntax similar to the if statement plus introduce a short form that entirely avoids the multi-line if err checking. I wouldn‘t want to raise it and waste everybody‘s time though if this has been seen before- I couldn‘t find it in the error handling-tagged proposals.

The main benefit of guard in Swift is not saving a few lines but optional binding. Other than that I always considered it as a pretty strange construct. It's an if statement and Go doesn't need two types of if statements. I'm sure the proposal would be quickly downvoted and declined.
As for extending an if statement, there were multiple such proposals and all of them were declined either because people don't want another special magic symbol to do all kinds of things (like ^ in the above example) or it doesn't address all the requirements (like allowing for errors to be augmented with some contextual information). The example above have the same problem many other such proposals had - it makes it difficult to see the error path. You have to scan whole line to get to it. It also makes lines much longer and will require you to split them in multiple lines possibly making code even harder to read. The benefit of current error handling is it's completely linear - you can scan the function from top to bottom only checking a few starting symbols on each line and get a glimpse on every return path.

I don't support special-casing the error type. I think it would be a wart in the language: something extra that people have to learn to read other people's code, but not a general-purpose feature you can apply to your own types.
However, if the proposal were to special-case all interface values in this way, then I think it's more acceptable.  That is: any interface variable can be used in a boolean context; a nil interface is treated as false, and any non-nil interface is treated as true (even if it contains a nil value, e.g. a nil pointer)
It could be used as a guard for a possibly-nil interface:
if v && v.Foo() { ... }

However, this may lead to requests for similar treatment of non-interface types.
Aside: I do sometimes miss Python's truthiness values, which each type can define using __bool__(): e.g. strings and lists implement them as len > 0.  The equivalent in Go would be a booler interface with Bool() method.  But it would still have to be defined in the language that a nil interface is false, since a nil interface has no concrete type to call a method on.  Therefore, the starting point would be "nil interfaces are false and non-nil interfaces are true".

As this proposal is declined, could folks pls continue the discussion re error handling in a new proposal, or golang-nuts? Thanks!


Send Properties

Currently the integration only sends the name of the track event. Should send properties as well.

Closed by #4


Separate container for web

Advice needed. I am trying to move web into a separate container and leave only fastAPI in api.

Do you mean you want to create an independent server that serves only html? If so, Ngnix can be used to serve static files. You can do this by creating a Ngnix container and setting the volume to ./app/web:/static in the volumes section. Of course, this also requires Traefik routing, and since Traefik's Host rule overlaps with the value used by the existing Fastapi server, you can move the hostrules to a different domain, so you can prevent access to FastAPI container.

The plan is to use a single shared instances of mysql, qdrant, redis and if possible fastAPI. then the frontend is independent per domain. I am also investigation simply symlinking the app/ folder. Avoiding duplicated code base for multiple domains on same server. using Nginx and traefik on same deployment can lead to nightmares. Lets take our time on this one. No rush

So you're saying that if you're running multiple domains, you want to set up the backend instance on a single server, and only assign the frontend to each domain.
I guess you want to replace the existing monolithic architecture with microservices.
Is this correct?

Yes and no. More like make fastAPI a headless backend by decoupling web. Here is a simplified version:
`services:
core:
image: fastapi_core_image
environment:
# Pool configurations for each domain
POOL_1: "mysql+mysqlconnector://user1:password1@db:3306/db1"
POOL_2: "mysql+mysqlconnector://user2:password2@db:3306/db2"
REDIS_1: "redis://:password1@cache:6379/0"
REDIS_2: "redis://:password2@cache:6379/1"
QDRANT_1: "qdrant_collection_1"
QDRANT_2: "qdrant_collection_2"
domain1:
image: flutter_app
environment:
DOMAIN_ID: "1"
BACKEND_URL: "http://core:8000"
domain2:
image: flutter_app
environment:
DOMAIN_ID: "2"
BACKEND_URL: "http://core:8000"
`
This allows customization of frontend. Also it is a lighter architecture, web containers are thin clients.
For more complex systems, FastApi can stored the connection pool in a db instead of environment variables. This may be easier to implement and my preferred option. The db can be prepopulated with 20 connections or so. And a bash script runs the docker-compose  instantiation.
Your thought?

Clients will send API requests to the real domain rather than hitting the BACKEND_URL set to http://core:8000. Because it is the client's browser, not flutter_app, that sends the actual API request. So while it is possible to mediate APIs using internal service names, it seems unlikely that you will be able to completely separate backend and frontend.

Okay for now I will symlink the code base among instances


WIP for now

Okay.
Not ready yet, I suppose I need about a few days more. Just want to make it right! )

@Piterden Hi! Can you, please, also add information about build to README to make sure that everyone will know how to build a package.

Yes, absolutely agree with you! It must to be done too.


fix pthread_create in uart_new

Thanks for the PR, but I'm curious what your OS is, it works fine on my computer (macOS 12.3 Intel). Also why remove the -Werror option?

Linux ubuntu 5.15.0-43-generic #46~20.04.1-Ubuntu SMP Thu Jul 14 15:20:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

if not removed, we will get another problems:  src/uart.c: In function ‘uart_thread’:
src/uart.c:8:9: error: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Werror=unused-result]
8 |         read(STDIN_FILENO, &c, 1);
|         ^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
and
src/cpu.c: In function ‘cpu_dump_csrs’:
src/cpu.c:148:29: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
148 |     printf("mstatus=0x%016llx mtvec=0x%016llx mepc=0x%016llx mcause=0x%016llx\n",
|                       ~~~~~~^
|                             |
|                             long long unsigned int
|                       %016lx
149 |         cpu_load_csr(cpu, MSTATUS),
|         ~~~~~~~~~~~~~~~~~~~~~~~~~~
|         |
|         uint64_t {aka long unsigned int}
src/cpu.c:148:45: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
148 |     printf("mstatus=0x%016llx mtvec=0x%016llx mepc=0x%016llx mcause=0x%016llx\n",
|                                       ~~~~~~^
|                                             |
|                                             long long unsigned int
|                                       %016lx
149 |         cpu_load_csr(cpu, MSTATUS),
150 |         cpu_load_csr(cpu, MTVEC),
|         ~~~~~~~~~~~~~~~~~~~~~~~~
|         |
|         uint64_t {aka long unsigned int}
src/cpu.c:148:60: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
148 |     printf("mstatus=0x%016llx mtvec=0x%016llx mepc=0x%016llx mcause=0x%016llx\n",
|                                                      ~~~~~~^
|                                                            |
|                                                            long long unsigned int
|                                                      %016lx
......
151 |         cpu_load_csr(cpu, MEPC),
|         ~~~~~~~~~~~~~~~~~~~~~~~
|         |
|         uint64_t {aka long unsigned int}
src/cpu.c:148:77: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 5 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
148 |     printf("mstatus=0x%016llx mtvec=0x%016llx mepc=0x%016llx mcause=0x%016llx\n",
|                                                                       ~~~~~~^
|                                                                             |
|                                                                             long long unsigned int
|                                                                       %016lx
......
152 |         cpu_load_csr(cpu, MCAUSE));
|         ~~~~~~~~~~~~~~~~~~~~~~~~~
|         |
|         uint64_t {aka long unsigned int}
src/cpu.c:153:29: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
153 |     printf("sstatus=0x%016llx stvec=0x%016llx sepc=0x%016llx scause=0x%016llx\n",
|                       ~~~~~~^
|                             |
|                             long long unsigned int
|                       %016lx
154 |         cpu_load_csr(cpu, SSTATUS),
|         ~~~~~~~~~~~~~~~~~~~~~~~~~~
|         |
|         uint64_t {aka long unsigned int}
src/cpu.c:153:45: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
153 |     printf("sstatus=0x%016llx stvec=0x%016llx sepc=0x%016llx scause=0x%016llx\n",
|                                       ~~~~~~^
|                                             |
|                                             long long unsigned int
|                                       %016lx
154 |         cpu_load_csr(cpu, SSTATUS),
155 |         cpu_load_csr(cpu, STVEC),
|         ~~~~~~~~~~~~~~~~~~~~~~~~
|         |
|         uint64_t {aka long unsigned int}
src/cpu.c:153:60: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
153 |     printf("sstatus=0x%016llx stvec=0x%016llx sepc=0x%016llx scause=0x%016llx\n",
|                                                      ~~~~~~^
|                                                            |
|                                                            long long unsigned int
|                                                      %016lx
......
156 |         cpu_load_csr(cpu, SEPC),
|         ~~~~~~~~~~~~~~~~~~~~~~~
|         |
|         uint64_t {aka long unsigned int}
src/cpu.c:153:77: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 5 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
153 |     printf("sstatus=0x%016llx stvec=0x%016llx sepc=0x%016llx scause=0x%016llx\n",
|                                                                       ~~~~~~^
|                                                                             |
|                                                                             long long unsigned int
|                                                                       %016lx
......
157 |         cpu_load_csr(cpu, SCAUSE));
|         ~~~~~~~~~~~~~~~~~~~~~~~~~
|         |
|         uint64_t {aka long unsigned int}
src/cpu.c: In function ‘cpu_dump_registers’:
src/cpu.c:606:36: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
606 |         printf("x%-2d(%4s)=0x%016llx  ", i + 0, abi[i + 0], cpu->regs[i + 0]);
|                              ~~~~~~^                        ~~~~~~~~~~~~~~~~
|                                    |                                 |
|                                    long long unsigned int            uint64_t {aka long unsigned int}
|                              %016lx
src/cpu.c:607:36: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
607 |         printf("x%-2d(%4s)=0x%016llx  ", i + 1, abi[i + 1], cpu->regs[i + 1]);
|                              ~~~~~~^                        ~~~~~~~~~~~~~~~~
|                                    |                                 |
|                                    long long unsigned int            uint64_t {aka long unsigned int}
|                              %016lx
src/cpu.c:608:36: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
608 |         printf("x%-2d(%4s)=0x%016llx  ", i + 2, abi[i + 2], cpu->regs[i + 2]);
|                              ~~~~~~^                        ~~~~~~~~~~~~~~~~
|                                    |                                 |
|                                    long long unsigned int            uint64_t {aka long unsigned int}
|                              %016lx
src/cpu.c:609:36: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
609 |         printf("x%-2d(%4s)=0x%016llx\n", i + 3, abi[i + 3], cpu->regs[i + 3]);
|                              ~~~~~~^                        ~~~~~~~~~~~~~~~~
|                                    |                                 |
|                                    long long unsigned int            uint64_t {aka long unsigned int}
|                              %016lx
cc1: all warnings being treated as errors

Okay, I'll set up a Ubuntu environment later this week to confirm this issue.

bugs:
first type in ls，then cat README or echo hi
$ cat README
cat README
panic: sched locks
$ cat README
ccat README
panic: release
$ ehco hi
ehco hi
exec ehco failed
if ls not completed and get uart input,  get above errors

The clint device is not fully implemented, nanoemu never generate timer interrupts. But xv6 requires timer interrupts for process switching. Therefore, only the boot process is expected to work. If you are interested, you are welcome to implement the clint device and submit a PR. 😄

Hi @dzwduan, sorry for the late response, I've confirmed the compilation issue in Ubuntu you mentioned. I've summited a commit https://github.com/ksco/nanoemu/commit/41f86115d to fix this. I've set you up as a co-author, thanks!


console spam under heavy load in linux server

when connecting 26 clients to a server with reX default / reference av app running, get this spammed to console:
441.808, 0x62fb6a0: EventArray::Wait: select() failed: Invalid argument(22)
using linux ubuntu 11.10 with a quite recent build (not current, though, will test with updated next). in a VM which may run the server quite slowly overall.
it doesn't crash and starts working ok again when the test clients log out

seems that that code is platform specific, let's make a similar test with windows next to compare. the part in UnixEventArray is:
int EventArray::Wait(int msecs)
Itv.tv_sec = msecs / 1000;
Itv.tv_usec = (msecs - tv.tv_sec * 1000) * 1000;
Iint ret = select(nfds, &readfds, &writefds, NULL, &tv); // http://linux.die.net/man/2/select
perhaps that can go to negative or something weird when server gets really slow? the windows code seems quite different

reproduced on 11.04 locally, without a vm - same test, same error, with current unmodified tundra2 & knet code

I can reproduce.

Fixed in https://github.com/juj/kNet/commit/ad354a6832e95657ab3bf83dd001f0bd3e3413bf . Linux builds directly clone the latest master branch of kNet (though btw this will perhaps change so that linux build scripts would pull a stable branch of kNet in the future), so re-running build-ubuntu-deps.bash should make this disappear.


feat: Update FAQ Illustration | Minor Style Fixes

Your checklist for this pull request
🚨Please review the guidelines for contributing to this repository.

[x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). Don't request your default branch!
[x] Make sure you are making a pull request against the default branch (left side). Also you should start your branch off default branch.
[x] Check the commit's or even all commits' message styles matches our requested structure.
[x] Check your code additions will fail neither code linting checks nor unit test.
[x] I have added necessary documentation (if appropriate)

Description
Please describe your pull request.
❤Thank you!
Post merge checklist

[ ] Follow steps from the guidelines for contributing to this repository.
[ ] If you are a new contributor, ping in the thread and one of the maintainers will add you to all-contributors list.

Okay a small fix. The logos are not aligned with the titles.

Either add the exact same margin to the title (make sure that it stays same for all views)
Or remove the left padding of the logo for all logos. Check the spacing once and adjust right padding accordingly.

Secondly, the image that has been added adjacent to FAQ, its background is overflowing. (very subtle thing, not visible straight away). Just to be consistent,  add an overflow of hidden to the parent div.


Supporting capistrano's clean task

In https://github.com/makandra/precompiled_assets/blob/d2a0fc50cfa9c290284901501590d7eb8dd4bc27/lib/precompiled_assets/tasks/assets.rake#L15 we are deleting all assets, that are not part of the manifest.js anymore.
IMHO we should support something like https://github.com/rails/propshaft/blob/e7cdbcd4aa9c9a390dade263bbd7c7cedc0c6442/lib/propshaft/railties/assets.rake#L17 && https://github.com/rails/propshaft/blob/e7cdbcd4aa9c9a390dade263bbd7c7cedc0c6442/lib/propshaft/processor.rb#L24 in propshaft.  Then set :keep_assets, 2 in capistrano would work as expected again, and rolling release will keep older assets available.
Wdyt?

Do you have any ideas on how to fix it? We currently don't have any information about previous assets in our manifests file, so we technically cannot keep X asset versions.
We could though warn if the user defines :keep_assets with any number except for 1 (which works as excpected)

(one attempt would be to use something like log-rotate.)

In case the digest format is unknown within the manifest.json, I agree it is difficult to solve. Otherwise something similar to https://github.com/rails/propshaft/blob/e7cdbcd4aa9c9a390dade263bbd7c7cedc0c6442/lib/propshaft/output_path.rb#L10-L23C6 might work:
Example (I will use the names logical_path for the left part without digest and digested_path for the right part with digest):
{
  "backend.js": "backend-5dd524a6b187583cacd52e36.js",
  "cover.jpg": "cover-2b884c2c70ef803b307518e5.jpg"
}

For each logical_path in the manifest find all digested_paths in the output e.g. public/assets

backend-1d69660cb9975aa76e6f4b0e.js
backend-042c8c36f345ffa238995e82.js
backend-cf4ff9f60349dfd08cb73c2b.js
...

Sort them by mtime
Keep the newest n assets according to keep_assets
(Optional) Drop all other assets that are not part of the manifest anymore and are older than the nth oldest known asset

This might not work good with chunked assets (the have the same logical path but different digests). But it seems it is not supported by precompiled_assets in the current version.

The whole idea behind precompiled_assets is to not make any assumptions about how assets are built.
As long as a manifest is included, it can be independent of the assets' build process.
Because of that, I believe we cannot follow the outlined approach:

We can not know if and how digests are injected into filenames. There are lots of different ways to do it.
Ordering assets by mtime might not always be correct. This gem has no knowledge about how and when assets were actually built.

Propshaft does not have these issues as it also controls asset generation.
The manifest is our only source of truth which is why our suggestion is to keep backups of previous manifests. (We would assume that at least manifest files can be sorted reliably by mtime.)

Then I'm fine with @makmic suggestion + short documentation.

We could though warn if the user defines :keep_assets with any number except for 1 (which works as excpected)

Agreed, :keep_assets > 1 should raise an error, possibly before any deployment starts.
I believe we could still implement some kind of manifest rotation to support values above 1 as a next step.


Add update.sh to generate AG xcframework

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (a5b0df5) 5.00% compared to head (b40663a) 0.00%.

Additional details and impacted files
@@           Coverage Diff            @@
##            main      #2      +/-   ##
========================================
- Coverage   5.00%   0.00%   -5.00%
========================================
  Files          5       5
  Lines         20      20
========================================
- Hits           1       0       -1
- Misses        19      20       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Memory Leak on macOS?

is it possible, that there is a memory leak on macOS? I'm running El Capitan and the example code on the front-page which just creates an empty (black) buffer seems to gain slowly but constantly memory.
Used code:
extern crate minifb;

use minifb::{Window, Key, Scale, WindowOptions};

const WIDTH: usize = 640;
const HEIGHT: usize = 360;

fn main() {
    let mut buffer: Vec<u32> = vec![0; WIDTH * HEIGHT];

    let mut window = Window::new("Test - ESC to exit",
                                 WIDTH,
                                 HEIGHT,
                                 WindowOptions::default()).unwrap_or_else(|e| {
        panic!("{}", e);
    });

    while window.is_open() && !window.is_key_down(Key::Escape) {
        for i in buffer.iter_mut() {
            *i = 0; // write something more funny here!
        }

        window.update_with_buffer(&buffer);
    }
}

after approx. 30 sec of running

Interesting. I will take a look at it. Thanks for the report!

With the upgrade to Metal this should be no issue anymore. Please re-open if you see this again.


add classes to sensors

Checklist

[X] I have filled out the template to the best of my ability.
[X] This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
[X] This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.
All sensor types are equal currently
Describe the solution you'd like
add a sensor class to created sensors
Describe alternatives you've considered
manually creating sensor templates
Additional context
none

resolved with release 0.3.0


fixes misinformation in "Rules" para. | readme.md

In readme.md there is a misinformation about rules receiving "slim app" as the argument, however, they actually receive a request.

Thanks!

well thank you for the nice middleware 🐙


Odd menu scrolling with dropdown

Dropdowns try to center their chosen value when the popup opens up. If the dropdown is placed on top of the screen (or the list of values is long enough), that's not possible. So you get a scrolling animation while the popup settles.
This is jarring at best and annoying at worst since it delays user action (can't tap on any value until the animation ends [typically a second]).
It would be great if Flutter can precompute whether the centering is possible and if not prevent the scrolling.

Duplicate of #8266
Sorry for dropping the ball on this issue.


panic: send on closed channel

Versions
<EMAIL_ADDRESS>Please specify real version numbers or git SHAs, not just "Latest" since that changes fairly regularly.

Sarama
Kafka
Go

v1.29
2.4.1
go1.17.6

Configuration
kafka.KafkaOptions{
		Enabled:             false,
		Name:                name,
		Topic:               "test",
		Brokers:             []string{},
		BufferMemory:<PHONE_NUMBER>,
		LingerInterval:      time.Millisecond * 10,
		BatchSize:           65536,
		CompressionType:     "none",
		ProducerLatencyTime: time.Millisecond * 60,
		SaslEnabled:         false,
		SaslMechanism:       "SASLTypePlaintext",
		SslEnabled:          false,
		SslCertificate:      "",
		SslCertificateKey:   "",
		SslCaCertificate:    "",
		MaxMessageBytes:     10485760,
		Version:             sarama.MaxVersion,
		SslSkipVerify:       false,
		MsgTimeoutWarn:      time.Millisecond * 10000,
		KeySerializer:       "org.apache.kafka.common.serialization.ByteArraySerializer",
		ValueSerializer:     "org.apache.kafka.common.serialization.ByteArraySerializer",
		Acks:                "local",
		Retry:               5,
		Workers:             1,
		SendBufferBytes:     10485760,
		ReceiveBufferBytes:  10485760,
		MaxRequestSize:      10485760,

panic: send on closed channel
goroutine 74 [running]:
github.com/Shopify/sarama.(*asyncProducer).shutdown(0xc0003080e0)
/Users/a/go/pkg/mod/github.com/!shopify/sarama@v1.29.2-0.20210920231520-94c8136ff710/async_producer.go:1057 +0xa8
github.com/Shopify/sarama.withRecover(0x0)
/Users/a/go/pkg/mod/github.com/!shopify/sarama@v1.29.2-0.20210920231520-94c8136ff710/utils.go:43 +0x3e
created by github.com/Shopify/sarama.(*asyncProducer).AsyncClose
/Users/a/go/pkg/mod/github.com/!shopify/sarama@v1.29.2-0.20210920231520-94c8136ff710/async_producer.go:322 +0x9d
exit status 2
Problem Description
When trying to shutdown Kafka producer using producer.Close() we are seeing this issue.

Closing as duplicate of #1441 — feel free to re-open if that's not the case


Set Hint for next track

The Next track does not start pre-loading if the app is in the background

DOUAudioStreamer does not provide out of the box handling of iOS background task, in the other words, you should do that yourself.


Can't login to Rdio via Facebook

System: Arch Linux, not reproducible in Debian Jessie
Persist with cleared cache/config.

It just gives a white loading window that goes on forever. When clicking connect with facebook a popup comes up asking for facebook login information, the popup is horribly styled and doesn't work either.
Using Arch Linux and the latest version from AUR.

Hello. Thanks for taking the time to report your issue. I need more information to investigate it further:

Version of Nuvola Player ("the latest version from AUR" is not specific enough)
Debugging output from terminal during the whole logging in sequence.
Screenshot of the horribly styled pop-up window.

See Bug Reporting Guidelines for details.

Nuvola Player Version
Nuvola Player 3 Beta 3.0.0
Revision fuzzy
rdio app version
nuvola-app-rdio-git  r8.52a785d-1
Screenshot

Debug output
[Master:WARNING    Gtk] Theme parsing error: gtk-contained-dark.css:3708:26: negative values are not allowed.
[Master:DEBUG      Gtk] Connecting to session manager
[Master:DEBUG    DioriteGtk] DesktopShell.vala:90: Shell: gnome shell 3.16.3, CSD on
[Master:DEBUG    Nuvola] config.vala:174: Json Error: Failed to open file '/home/nathan/.config/nuvolaplayer3/master/config.json': No such file or directory
[Master:DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Test at /usr/share/nuvolaplayer3/web_apps/test, version 1.0
[Master:WARNING  Nuvola] WebAppRegistry.vala:165: Unable to load web app from /usr/share/nuvolaplayer3/web_apps/template: /usr/share/nuvolaplayer3/web_apps/template/metadata.json is not a file
[Master:DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Google Calendar at /usr/share/nuvolaplayer3/web_apps/google_calendar, version 1.0
[Master:DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Rdio at /usr/share/nuvolaplayer3/web_apps/rdio, version 4.0
[Master:DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Spotify at /usr/share/nuvolaplayer3/web_apps/spotify, version 2.1
[Master:DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Deezer at /usr/share/nuvolaplayer3/web_apps/deezer, version 2.3
[Master:INFO     Nuvola] WebAppRegistry.vala:89: Using web app Rdio, version 4.0, data dir /usr/share/nuvolaplayer3/web_apps/rdio
[Master:DEBUG    Nuvola] MasterController.vala:380: Launch app runner for 'rdio': /usr/lib/nuvolaplayer3/apprunner -D -a /usr/share/nuvolaplayer3/web_apps/rdio
[Master:DEBUG    DioriteGtk] application.vala:219: XFCE session vanished: org.xfce.SessionManager
[Runner:WARNING    Gtk] Theme parsing error: gtk-contained-dark.css:3708:26: negative values are not allowed.
[Runner:DEBUG      Gtk] Connecting to session manager
[Runner:DEBUG    DioriteGtk] DesktopShell.vala:90: Shell: gnome shell 3.16.3, CSD on
[Runner:DEBUG    DioriteGtk] application.vala:219: XFCE session vanished: org.xfce.SessionManager
[Master:DEBUG    Nuvola] MasterController.vala:226: Connected to runner server for 'rdio'.
[Runner:WARNING    Gtk] Theme parsing error: gtk-contained-dark.css:3708:26: negative values are not allowed.
[Runner:DEBUG    Nuvola] WebEngine.vala:62: Nuvola WebKit Extension directory: /usr/lib/nuvolaplayer3
[Runner:DEBUG    Nuvola] WebEngine.vala:152: Network Proxy: system settings
[Runner:WARNING  GLib-GObject] g_object_set_property: construct property "local-storage-directory" for object 'WebKitWebContext' can't be set after construction
[Runner:DEBUG    Nuvola] Notifications.vala:175: Notifications: persistence true, actions true, icons false
[Master:DEBUG    Nuvola] MediaKeys.vala:99: GNOME settings daemon appeared: org.gnome.SettingsDaemon, :1.7
[Runner:DEBUG    Nuvola] MPRISProvider.vala:73: Bus acquired: org.mpris.MediaPlayer2.NuvolaPlayer3Rdio, registering objects
[Runner:DEBUG    Nuvola] MPRISProvider.vala:90: Bus name acquired: org.mpris.MediaPlayer2.NuvolaPlayer3Rdio

(WebKitWebProcess:16901): Gtk-WARNING **: Theme parsing error: gtk-contained-dark.css:3708:26: negative values are not allowed.
[Worker:DEBUG    Nuvola] main.vala:232: Page 1 created for (null)
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = http://www.rdio.com/home/en-us/, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
[Runner:DEBUG    Nuvola] FormatSupport.vala:88: Trying to play /usr/share/nuvolaplayer3/audio/audiotest.mp3.
[Runner:DEBUG    Nuvola] FormatSupport.vala:88: Pipeline state changed from NULL to READY.
[Runner:DEBUG    Nuvola] FormatSupport.vala:88: Pipeline state changed from READY to PAUSED.
[Runner:DEBUG    Nuvola] FormatSupport.vala:88: Pipeline state changed from PAUSED to PLAYING.
[Runner:DEBUG    Nuvola] FormatSupport.vala:88: End of stream for file /usr/share/nuvolaplayer3/audio/audiotest.mp3.
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Google Talk Plugin (enabled, not flash) at /usr/lib64/mozilla/plugins/libnpgoogletalk.so: Version: <IP_ADDRESS>
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Google Talk Plugin Video Renderer (enabled, not flash) at /usr/lib64/mozilla/plugins/libnpo1d.so: Version: <IP_ADDRESS>
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Gnome Shell Integration (enabled, not flash) at /usr/lib64/mozilla/plugins/libgnome-shell-browser-plugin.so: This plugin provides integration with Gnome Shell for live extension enabling and disabling. It can be used only by extensions.gnome.org
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Shockwave Flash (enabled, flash) at /usr/lib64/mozilla/plugins/libflashplayer.so: Shockwave Flash 11.2 r202
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Google Talk Plugin (enabled, not flash) at /usr/lib/mozilla/plugins/libnpgoogletalk.so: Version: <IP_ADDRESS>
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Google Talk Plugin Video Renderer (enabled, not flash) at /usr/lib/mozilla/plugins/libnpo1d.so: Version: <IP_ADDRESS>
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Gnome Shell Integration (enabled, not flash) at /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so: This plugin provides integration with Gnome Shell for live extension enabling and disabling. It can be used only by extensions.gnome.org
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Shockwave Flash (enabled, flash) at /usr/lib/mozilla/plugins/libflashplayer.so: Shockwave Flash 11.2 r202
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Google Talk Plugin (enabled, not flash) at /usr/lib/firefox/plugins/libnpgoogletalk.so: Version: <IP_ADDRESS>
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Google Talk Plugin Video Renderer (enabled, not flash) at /usr/lib/firefox/plugins/libnpo1d.so: Version: <IP_ADDRESS>
[Runner:DEBUG    Nuvola] FormatSupportCheck.vala:124: Nuvola.WebPlugin: Shockwave Flash (enabled, flash) at /home/nathan/.mozilla/plugins/libflashplayer.so: Shockwave Flash 11.2 r202
[Runner:WARNING  Nuvola] FormatSupportCheck.vala:137: Too many Flash plugins have been found: 3
http://www.rdio.com/home/en-us/:10:131: CONSOLE ERROR Viewport argument key "target-densitydpi" not recognized and ignored.
[Worker:DEBUG    Nuvola] main.vala:141: Window object cleared: http://www.rdio.com/home/en-us/, 0x2257670, 0x22ecc10, 0x7f246406f4b0
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] WebAppWindow.vala:165: Sidebar position: 837
http://dtp53wusksd88.cloudfront.net/home/static/js/site.min.js?rel=1438035278499559420:3:291: CONSOLE ERROR TypeError: null is not an object (evaluating 'ha')
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: can-go-next
[Runner:INFO     Nuvola] AppRunnerController.vala:235: Logged in as  ()
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: can-go-previous
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = http://static.ak.facebook.com/connect/xd_arbiter/PqAPbTuc2cR.js?version=41#channel=f14a39affc&origin=http%3A%2F%2Fwww.rdio.com, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = https://s-static.ak.facebook.com/connect/xd_arbiter/PqAPbTuc2cR.js?version=41#channel=f14a39affc&origin=http%3A%2F%2Fwww.rdio.com, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: can-play
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: can-pause
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = http://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/static/getItem.html?rl_eid=getItem-EQKjPPP&rl_ws=%5B%22rl_campaign%22%5D, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = http://rlets.com/static/getItem.html?rl_eid=getItem-5q1Xez3&rl_ws=%5B%22RlocalOptOut%22%5D, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = https://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/api/v1/insights, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_FORM_SUBMITTED
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = http://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/static/getItem.html?rl_eid=getItem-55su42D&rl_ws=%5B%22visitor_id%22%2C%22visit_id%22%2C%22referrer_type%22%2C%22bot_type%22%2C%22last_activity_at%22%2C%22referrer_url%22%2C%22history_campaign%22%5D, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = http://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/static/removeItem.html?rl_eid=removeItem-e6EggUv&rl_ws=%5B%22history_campaign%22%5D, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = https://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/api/v1/visits, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_FORM_SUBMITTED
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = http://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/static/setItem.html?rl_eid=setItem-3UUxY07&rl_ws=%5B%7B%22k%22%3A%22visitor_id%22%2C%22v%22%3A%228c1560e5-4946-4751-a4bf-25c2478ed8e2%22%2C%22e%22%3A%22%22%7D%2C%7B%22k%22%3A%22visit_id%22%2C%22v%22%3A%224d711744-2e16-441a-b75f-5135c4011cfd%22%2C%22e%22%3A%22%22%7D%2C%7B%22k%22%3A%22referrer_type%22%2C%22v%22%3A%22DIRECT%22%2C%22e%22%3A%22%22%7D%2C%7B%22k%22%3A%22bot_type%22%2C%22v%22%3A%22%22%2C%22e%22%3A%22%22%7D%2C%7B%22k%22%3A%22last_activity_at%22%2C%22v%22%3A%221439999495234%22%2C%22e%22%3A%22%22%7D%2C%7B%22k%22%3A%22history_campaign%22%2C%22v%22%3A%22%22%2C%22e%22%3A%22%22%7D%2C%7B%22k%22%3A%22referrer_url%22%2C%22v%22%3A%22http%3A%2F%2Fwww.rdio.com%2Fhome%2Fen-us%2F%22%7D%5D, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = https://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/api/v1/insights, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_FORM_SUBMITTED
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = https://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/api/v1/insights, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_FORM_SUBMITTED
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = https://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/api/v1/insights, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_FORM_SUBMITTED
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = https://910ec4e2-5138-41e9-9432-9f89d610cefb.rlets.com/api/v1/insights, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_FORM_SUBMITTED
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = http://www.rdio.com/account/signin/, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_LINK_CLICKED
[Runner:DEBUG    Nuvola] WebEngine.vala:507: Navigation, current window: uri = https://www.rdio.com/account/signin/, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_LINK_CLICKED
[Runner:INFO     Nuvola] config.vala:260: Config saved to /home/nathan/.config/nuvolaplayer3/apps_data/rdio/config.json
[Worker:DEBUG    Nuvola] main.vala:141: Window object cleared: http://www.rdio.com/home/en-us/, 0x2257670, 0x22ecc10, 0x7f246406dcb0
[Worker:DEBUG    Nuvola] jsenvironment.vala:65: ~JsEnvironment 0x22c01b0
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: can-go-next
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: can-go-previous
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: can-play
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: can-pause
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-location
[Runner:DEBUG    Nuvola] DeveloperSidebar.vala:120: Media player notify: artwork-file

Note that screenshot does not correlate to the debug log. For the debug log I launched nuvolaplayer with rdio and pressed the login button, then all I saw was a white window with a spinner animation. Doesn't seem worthy of a screenshot.

Thanks for your response. There is a JavaScript error in the Rdio code that might cause the loading failure. I will investigate it more in September 2015 as funds for August 2015 have been exhausted.
http://dtp53wusksd88.cloudfront.net/home/static/js/site.min.js?rel=1438035278499559420:3:291: CONSOLE ERROR TypeError: null is not an object (evaluating 'ha')

I'll start investigating sometime within the next few days. I will post updates here as I come across them.

Might be useful for understanding of the error: Deobfuscated site.min.js. I don't have time to identify the line 291 from original source though.

Hi @eurythmia, did you have a chance to investigate this issue further?

sorry, no. I've hardly had a chance to sit in front of my computer in the
past few weeks.
On Sun, Sep 13, 2015 at 11:59 AM, Jiří Janoušek<EMAIL_ADDRESS>wrote:

Hi @eurythmia https://github.com/eurythmia, did you have a chance to
investigate this issue further?
—
Reply to this email directly or view it on GitHub
https://github.com/tiliado/nuvola-app-rdio/issues/4#issuecomment-139881917
.

I'm assigning this issue to me and will take a look at it in October 2015.

Glad you're on top of it. Is there any workaround that I could try for the time being? Would love to be able to us this :)

I'm afraid I cannot reproduce the issue. Could you try to remove Rdio configuration and cache?
rm -rf ~/.config/nuvolaplayer3/apps_data/rdio
rm -rf ~/.cache/nuvolaplayer3/apps_data/rdio
rm -r ~/.local/share/nuvolaplayer3/apps_data/rdio

No dice. I am using gnome-shell, in case that matters ..

Does the issue occur also in GNOME Web/Epiphany browser?


Fix: Improve typeahead on /graph page

This PR is an attempt to improve the autocomplete behavior in the expression browser to support the query history feature.
The issues described in #3718 can be avoided by not automatically selecting the first item in the dropdown. With only one query in the dropdown, and a different query in the expression field, when you hit return it would take the first item in the dropdown and query for it since it was selected. With this change, you have to press the down arrow in order to have the query populate in the expression browser.

I'm just going to put this out there in case there's any interest. How about simply reverting to the 2.0 behaviour?
Is this worth forking a vendor library for? I don't think so but that's only my opinion.

@paddynewman I think it's worth it as a temporary solution before we get a UI rewrite. However, if there's pressure to release 2.1.1 and we can't get this fixed up before that (hopefully we can), then just rolling back for that release could be an option.

Yeah, that's definitively an option. I don't like forking vendor libraries either, but those dependencies hadn't been touched in 3 years, since they were added. The proposal to rewrite the UI has gained some momentum so hopefully that ball starts rolling in the next few weeks.
I am working on fixing all the things Julius pointed out above, this should be done in a few hours.

@lovisas Awesome, thanks. I'm currently flying to the other end of the globe, so it might be a day or two before I am able to get back to it.

No rush, safe travels! Thanks for all your feedback on this so far @juliusv.

Sooooo it turns out that we didn't need to fork the bootstrap-typeahead at all. Instead of modifying the version of the library that we were using, I took the latest version which introduced all of the bugs.
The current state of the PR:

the dependency isn't forked and we pass additional options to modify the behavior
items in the dropdown are not autoselected
historical queries are only shown when the dropdown is toggled on
small refactor to move shared behavior to a function

Apologize for all the back and forth that could have been avoided, next time I'll pay better attention to the versions... s/o to @csmarchbanks for getting me on the right track.

@lovisas That's excellent news! Taking another look...

@lovisas Works great now and obviously it's much nicer now :)

:+1: Awesome, with the last change to not auto submit, it looks good. Merging.


adding the example to nextjs

Hey!
is it possible to add this example in nextjs/examples
There seems to be no example for rescript.

I would keep a very minimal example there, so that ReScript gets regression test coverage, but keep housing the full project here.

Yep correct

FYI. I found there is an example of ReasonML & ReasonReact
https://github.com/vercel/next.js/tree/canary/examples/with-reasonml

It would be great if we have an example for ReScript (rescript-react)

Oh... IMO the ReasonML template should be removed completely, since starting a NextJS / ReScript project with Reason is like writing a legacy codebase from scratch.

Last one missing is reason-relay -> rescript-relay, but I have not used that one so far.

@zth - Maybe you can help with this?

@dan003400 Already talked with Gabriel about this.. there's currently no bandwidth on his side to update that one


[spec]: retransmit shutdown on reestablish

BOLT2 states that "upon reconnection, if [a node] has sent a previous shutdown, [it] MUST retransmit shutdown".
We currently do this if the channel has status ChanStatusCoopBroadcasted:
https://github.com/lightningnetwork/lnd/blob/ba4021cad98887b2a63be6b61bf0ad46b07c221a/peer/brontide.go#L905-L909
Prior to https://github.com/lightningnetwork/lnd/pull/8167 this means that if shutdown was sent, it will be re-transmitted since initChanShutdown calls MarkCoopBroadcasted:
https://github.com/lightningnetwork/lnd/blob/ba4021cad98887b2a63be6b61bf0ad46b07c221a/lnwallet/chancloser/chancloser.go#L342-L350
With #8167, the call to MarkCoopBroadcasted is delayed until we are ready to send closing_signed. This means that the logic in restartCoopClose won't be called before this point. Because of this, if LND has sent shutdown, but hasn't reached the point where it sends closing_signed, and then disconnects with its peer, LND won't retransmit shutdown. To fix this, some state needs to be persisted right before we send shutdown such that LND can restart the coop close process on reestablish. This is especially important in light of https://github.com/lightningnetwork/lnd/issues/8393 where LND <-> LND coop close may not happen on restart as neither side re-transmits shutdown.
Additional things to take note of:

the pkscript that is re-transmitted in shutdown must be identical to the prior shutdown's pkscript
if an update_* and commit_sig are owed as well as a shutdown, the original ordering must be maintained

Note that this new scenario is only applicable post #8167. So we'll need to drive that to final completion first, then take this on.


How to publish the lambda with different aws-lambda-tools-xxx.json for different environment (prod, staging, dev)?

We have three environments (prod, staging, dev), is there a feature for that we can use different aws-lambda-tools-xxx.json to publish to different environments in VS2020? If not, is there any other way we can achieve this goal? thank you.
One more question, we want to use the appsettings.json (appsettings.Staging.json, appsettings.Production.json) in SQS lambda template project, is there a way to DI the IConfiguration to the constructor? so I can read the configuration from appsettings.json easily, thank you so much.

Hi, does anyone knows this? thank you.

Hi @xiaohui-gsv , the Toolkit does not allow you to publish using an alternate configuration file. The AWS Toolkit's Lambda deployment features are intended to help the development and iteration loop. Once your system is ready to be deployed to another environment (like staging or prod), performing a deployment through more automated means is recommended. This reduces the likelihood of introducing unintended changes in those environments.
It's great that you have different json files configured for your different environments. You can use the AWS .NET CLI extensions to deploy your code to Lambda from the command line (and from CI systems). The AWS Lambda extension knows how to work with the aws-lambda-tools-xxx.json files, and performs the same deployment as the Toolkit. You will need to pass your specific json file in through a command line argument, and this should help you achieve your goal of deploying to different environments.

@awschristou thank you, I can use the dotnet lambda deploy-function --config-file xxxx.json to publish to the different environment.


Creating Rest api for blog section

Hello @anmode I want to create rest api for blog section

create blog
update blog
get all blog
get single blog

@Ja3mamtora You are working on it ?

Yes

Closing this issue as no update from contributor


vxfw fix mouse and root window

vxfw: improve mouse handling and hit testing
vxfw: use correct root window size

I would also suggest using the mouse_enter and mouse_leave events in the button widget to track the mouse pointer shape :)


onEnded、onSourceCompleted、onPause didn't work

i try it in my project, but  onEnded、onSourceCompleted、onPause didn't work, i don't know when video end?
我在我项目中使用，但是 视频结束、完成、或者 暂停，这些 回调函数没有执行？
beginPullVedio() {
      var that = this;
      var canvas = document.getElementById('video-canvas');
      var url = 'ws://meeting-front.hunterslab.cn/live/';
      var player = new JSMpeg.Player(url, {
        canvas: canvas,
        loop: true,
        autoplay: true,
        onPlay: function() {
            this.on_play = true;
            console.log('onPlay', new Date().getTime());
        },
        onPause: function() {
            console.log('onPause', new Date().getTime());
        },
        onEnded: function() {
            console.log('onEnded', new Date().getTime());
        },
        onStalled: function() {
            console.log('onStalled', new Date().getTime());
        },
        onSourceCompleted: function() {
            console.log('onSourceCompleted', new Date().getTime());
        }
      });
    }

loop: false， onEnded does work

loop: false， onEnded does work

loop: false， onEnded does work

loop: false， onEnded does work    again


Can we show the label on top of the bar instead of the y axis.. or show them in k like 10k instead of 10,000 if the numbers are that high?

Hey, did you find a solution to this? I also want the labels to be on the top of the graph rather than on y-axis.

Hi, is any updated abut this??


make PC police happy

@blowdart  can you verify my changes are OK?

Minor comment, but otherwise :shipit:

:ship:

merged