Unexpected behavior when UNCHANGED is applied to indirect nested tuples

Description
UNCHANGED does not get transformed correctly, when applied to tuples with more than 1 level of operator indirection:
In the attached module, xyz is a tuple, containing as one of its elements a tuple of global variables. Semantically,
UNCHANGED xyz is equivalent to x' = x /\ y' = y /\ z' = z, which is the expected result of the transformations applied by Apalache to UNCHANGED xyz. However, the actual result is different. The transformations relevant to this discussion are done in the following passes:
PASS #3: DesugarerPass ~> ... ~> PASS #5: InlinePass ~> ... ~> PASS #8: PreprocessingPass

Desugarer transforms all instances of UNCHANGED xy into xy' = xy and UNCHANGED xyz into xyz' = xyz
Inliner transforms the above into <<x, y>>' = <<x, y>> and <<<<x, y>>, z>>' = <<<<x, y>>, z>>
PreprocessingPass transforms the above into x' = x /\ y' = y and <<x', y'>> = <<x, y>> /\ z' = z, where the latter notably does not contain any assignments and causes Assignment error: test.tla:12:9-12:9: x' is used before it is assigned. Even though the former passes assignment solving, it is notable that the resulting forms are x' = x, and not x' := x, which is how UNCHANGED x would have been translated on its own.

Input specification
--------------------------- MODULE test -------------------------------------

VARIABLE
  \* @type: Int;
  x,
  \* @type: Int;
  y,
  \* @type: Int;
  z

\* @type: <<Int,Int>>;
xy == <<x,y>>
\* @type: <<<<Int,Int>>,Int>>;
xyz == <<xy, z>>

Init == x = 0 /\ y = 0 /\ z = 0
NextOK == UNCHANGED xy /\ UNCHANGED z
NextBad == UNCHANGED xyz

Next ==
  \/ NextOK
  \/ NextBad

=============================================================================

From 08_OutPrepro.tla:
Next == ((x' = x /\ y' = y) /\ z' := z) \/ (<<x', y'>> = <<x, y>> /\ z' = z)

Suggestion
As Desugarer already knows how to translate the case of UNCHANGED <<<<a,b>>, c>> (just not if indirect via operators), the easiest solution is to extract this UNCHANGED rewriting from Desugarer into a standalone utility, and call it in PreprocessingPass, or to omit the 1st Desugarer pass entirely, since Desugarer is called inside PreprocessingPass already (though this might have unintended ripple effects, so I'd be cautious about this).

As we discussed several times, e.g., in #480, it would be good to have a transformation framework that calls individual transformations, when an expression has been updated. There is no perfect order on transformations.


auth.isLoggedIn: Treat BalenaExpiredToken errors as logged out indicator

Change-type: patch
Signed-off-by: Thodoris Greasidis<EMAIL_ADDRESS>
Resolves: #
HQ:
See:
Depends-on:
Change-type: major|minor|patch

Contributor checklist

[ ] Includes tests
[ ] Includes typings
[ ] Includes updated documentation
[ ] Includes updated build output

@balena-ci I self-certify!

@balena-ci I self-certify!


Manual

It would be very helpful if we have a manual with instructions about how to compile and run the project.

@gabimjesus nothing special is needed. Just open this project from Android studio and run.

Does it work only using Android studio? How about an IDE like Netbeans?

It works only with Android studio. There is plenty of built in stuff that had to be used for project to be compiled and run. (like resources class automatic generation, gradle support, xmls parsing and bunch of other must stuff).


libu2f-server: 1.0.1 -> 1.1.0

Motivation for this change
Simple upgrade, also the previous version is broken at least with pam_u2f (see issues 1 and 2)
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

cc @philandstuff

@GrahamcOfBorg  eval

@grahamcofborg build libu2f-server pam_u2f

Success on x86_64-linux (full log)
Attempted: libu2f-server, pam_u2f
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6
shrinking /nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6/bin/pamu2fcfg
shrinking /nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6/lib/security/pam_u2f.so
gzipping man pages under /nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6/share/man/
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6/lib  /nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6/bin
patching script interpreter paths in /nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6
checking for references to /build in /nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6...
/nix/store/06nc07vdvq1s2rmvd3lcffw09v391i4v-libu2f-server-1.1.0
/nix/store/060b4y11qfvx26lxnzll5yj8ifcvkkwz-pam_u2f-1.0.6

Success on aarch64-linux (full log)
Attempted: libu2f-server, pam_u2f
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6
shrinking /nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6/bin/pamu2fcfg
shrinking /nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6/lib/security/pam_u2f.so
gzipping man pages under /nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6/share/man/
strip is /nix/store/gp7fylxwn18b7pl2c18ks89hsiaxyfvf-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6/lib  /nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6/bin
patching script interpreter paths in /nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6
checking for references to /build in /nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6...
/nix/store/q9cb83c73c30bsg2ajnxxhy872h84zjl-libu2f-server-1.1.0
/nix/store/0ayrrr8fmqmvzcbvy1qqlrxqj541fsrr-pam_u2f-1.0.6

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: libu2f-server, pam_u2f
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.


Status pages for object deliveries

We handle some processing and object deliveries async, eg inbound webmentions. Lots of background on the tradeoffs on https://fed.brid.gy/docs#error-handling . We don't currently have status pages for those async deliveries. It'd be nice if we did! (And returned those status page URLs in the Location response header.)

This would be prohibitively expensive. We're actually going the opposite direction, eg #1501


fix(cli): add missing shared package for lint command and remove useless path

…ess path
Checklist
List of tasks you have already done and plan to do.

[ ] Fix linting errors
[ ] Tests have been added / updated (or snapshots)

Change information
Describe your modifications here.
Issues
The issues you want to close, formatted as close #1.
Related Links
Links related to this pr.

LGTM


Use github actions to build and test project on every commit/pull request

Maybe I should also add an auto release to GitHub and PyPI or not?

By the way, tests for Windows fail due to LF/CRLF and I don't know how to fix it 🤔

Yes, that would be great. Should have added CI/CD a long time ago.
A couple of comments so far:

Preferred python version for now is 3.11.
I'm not sure if compiling on every push/pr is necessary. Auto-tests on every push/pr would be nice.
It might be better to update single pre-release automatically for the dev branch instead? Not sure.

By the way, tests for Windows fail due to LF/CRLF and I don't know how to fix it 🤔

Weird, I thought that fixed before. Will look again. Maybe .gitattributes required.

Preferred python version for now is 3.11

Fixed

I'm not sure if compiling on every push/pr is necessary. Auto-tests on every push/pr would be nice.
It might be better to update single pre-release automatically for the dev branch instead? Not sure.

Well it's a CI not a CD, because there are no automatic releases. It just saves builds as github actions artifacts. I also didn't see any binaries for Linux.


Implement implicit DSDL compilation via import hooks

Instead of this:
import pyuavcan
compiled_dsdl_dir = pathlib.Path(__file__).resolve().parent / ".demo_dsdl_compiled"
sys.path.insert(0, str(compiled_dsdl_dir))
try:
    import sirius_cyber_corp
    import pyuavcan.application
except (ImportError, AttributeError):
    src_dir = pathlib.Path(__file__).resolve().parent
    pyuavcan.dsdl.compile_all(
        [
            src_dir / "custom_data_types/sirius_cyber_corp",
            src_dir / "public_regulated_data_types/uavcan/",
        ],
        output_directory=compiled_dsdl_dir,
    )
    importlib.invalidate_caches()
    import sirius_cyber_corp
    import pyuavcan.application

We could just do this:
import pyuavcan
import sirius_cyber_corp
import pyuavcan.application

Such that if the DSDL namespaces are not compiled, PyUAVCAN would invoke the compiler transparently for the user. This is implementable with the help of Python import hooks. The Cap'n'Proto Python client implements it this way.
We could define an environment variable named simply CYPHALPATH listing a set of paths where DSDL namespaces are to be searched for. When an import hook is triggered, PyUAVCAN would scan the paths looking for the matching namespace. If found, it would invoke the DSDL compiler, providing all other directories reachable via the path variable as the look-up paths. The output should be cached somewhere secure to avoid recompilation at every launch (/tmp is probably not an option for security reasons, but the home directory might work).

@chemicstry continuing the conversation here. So the way I see it is that we set up a hook for ImportError and check there if there is a directory anywhere under CYPHALPATH whose name matches the name of the missing import. If there is, we collect all of the namespace directories from every location listed in CYPHALPATH, and pass them all to pycyphal.dsdl.compile_all. We can't compile namespaces one by one because they may be interdependent. I am not yet sure where to save the output, any ideas here?

Looks good, however, I think there are some tricky edge cases.
If CYPHALPATH has a default value, when not defined, then there is issue with adding additional paths. For example, user just installed pycyphal, added public_regulated_data_types to ~/.cyphal and everything works fine. However, then he decides to add custom DSDL, sets CYPHALPATH=/home/user/my_company_dsdl and suddenly regulated types are missing. I see a couple  options here:

Always add default paths to CYPHALPATH
Have a separate CYPHAL_ADDITIONAL_PATHS variable for any customs DSDL
On first launch set CYPHALPATH to default location if it is not defined. On windows this might work, but on linux permanently setting env variables is a bit tricky.
Do not use list in CYPHALPATH, limit to a single path only
I think limiting CYPHALPATH to single path is the best option here and maybe consider adding CYPHAL_ADDITIONAL_PATHS if neccessary.

The compilation output directory. I think it should be separate from CYPHALPATH, because CYPHALPATH might be used by other implementations (C, Rust, etc) and it should only contain DSDLs. Maybe an additional PYCYPHAL_PATH variable, which defaults to ~/.pycyphal? Another option is to put everything under subfolders in CYPHALPATH, like: ~/.cyphal/dsdl and ~/.cyphal/pycyphal_compiled. I would probably prefer the PYCYPHAL_PATH variable.
And finally I think it is worth thinking how we handle DSDL updates so that they are recompiled when files are changed. Compiling on each startup would probably be too much overhead? I'm not sure how reliable it is to use FS modification dates, but we could generate a hash of all DSDL files and store it in the output directory. If hashes do no match - recompile.

Always add default paths to CYPHALPATH

This doesn't sound too bad but I imagine it might become troublesome if one desires to purposefully isolate the current environment from the system-wide default configuration. Say, if I have a special one-off script that needs to use some modified DSDL namespaces, I would want to temporarily set CYPHALPATH to include only my special paths. With a permanent default that would be impossible.

Have a separate CYPHAL_ADDITIONAL_PATHS variable for any custom DSDL

I don't like this because it promotes the default to a special status, which risks creating wrong ideas about the public regulated data types namespace (which is likely to be found in the default location). Also, and perhaps most importantly, this approach differs from commonly acceptable practices (see PATH, PYTHONPATH, etc).

On first launch set CYPHALPATH to default location if it is not defined. On windows this might work, but on linux permanently setting env variables is a bit tricky.

Reconfiguring the environment like that is out of the scope of PyCyphal (remember we're not talking about Yakut here) but it shouldn't be an issue for the user to do it manually if needed. Higher-level tools like Yakut could still check if CYPHALPATH is configured, and if not, do it automatically for the user. Configuring this manually is not too taxing for the user anyway so we could start small and then add automation later. I think of the presented options this is the best solution.

Do not use list in CYPHALPATH, limit to a single path only
I think limiting CYPHALPATH to single path is the best option here and maybe consider adding CYPHAL_ADDITIONAL_PATHS if neccessary.

I don't think these are good ideas because they introduce more entities (= higher complexity) and differ significantly from common practices.
Let us proceed with a multi-entry PYCYPHAL with no default value other than, perhaps, the current working directory, similar to PYTHONPATH, and let us adjust UX later by building on top of this (perhaps by adding UX tweaks to Yakut like appending ~/.bashrc automatically).

The compilation output directory. I think it should be separate from CYPHALPATH, because CYPHALPATH might be used by other implementations (C, Rust, etc) and it should only contain DSDLs.

Agreed.

Maybe an additional PYCYPHAL_PATH variable, which defaults to ~/.pycyphal? Another option is to put everything under subfolders in CYPHALPATH, like: ~/.cyphal/dsdl and ~/.cyphal/pycyphal_compiled. I would probably prefer the PYCYPHAL_PATH variable.

Let's go with PYCYPHAL_PATH (or PYCYPHALPATH?) at least for now because it seems to be the most obvious approach with no clear contenders. Although piggybacking on CYPHALPATH is also possible without even the need to put DSDL namespaces into subdirectories because we could always store our PyCyphal-specific outputs into some cleverly named subdirectory whose name is not a valid DSDL namespace name, like .pycyphal.

And finally I think it is worth thinking how we handle DSDL updates so that they are recompiled when files are changed. Compiling on each startup would probably be too much overhead? I'm not sure how reliable it is to use FS modification dates, but we could generate a hash of all DSDL files and store it in the output directory. If hashes do no match - recompile.

Reliance on FS modification timestamps seems to be working for build systems so why not also use it here. The main problem I see is that we will need to traverse all DSDL files to see if they need to be recompiled, which may be slow in certain cases (esp. with HDD), but then hashing would be even worse in this regard. I suggest we start without recompilation (which would necessitate doing rm -rf $PYCYPHAL_PATH to force updates) and revisit this later.

Hey @chemicstry, no pressure but are you still interested/able to help us with this?

Hey, yes, but I can't give an ETA when. Maybe a month. Feel free to assign it to anyone else if it can be done sooner.

Hey @chemicstry how's it looking now? :D


JavaScript

As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first

Committed code for javascript

Committed code for javascript


proposal: Go 2: universal WrapError type

go2 proprosal: universal WrapError type
See filled questionare https://github.com/golang/go/issues/36994#issuecomment-581419256
This is a go2 proposal in the context of error wrapping. It is a concrete follow up to the more open ended #35929 (errors: how should formatting be handled?).
It requires changes to the errors package but no language change. All code is in this repo.
Context
Error wrapping support was added in go 1.13. It did not introduce some advanced features like error formatting and stack traces, not because these were not desirable  (Error Values — Problem Overview, Error Printing — Draft Design) but because no good implementation was found that delivered them.  This puts forward an implementation that delivers on the above, and which can easily introduce new feautures going forward.
Abstract
Currently, to be a wrapping error means implementing interface {Unwrap() error}.
Under this proposal, it means beaing an instance of the new WrapError struct, which itself contains plain, non-wrapping errors. The key advantage is new features can be added accross all wrapped error uses by adding functionality to WrapError, as opposed to introducing additional interfaces that have to be inplemented by every individual error type.
Details
Immediate Changes
The following are to be added to errors package (implementations in werrors.go):

type WrapError struct: effectively a linked list of errors, this is set to become the universal type for all wrapped errors. It supports Is, As and Unwrap as expected.
func Wrap(error, error) error: used to produce the WrapError error chain. All error wrapping is set to be produced through this method.

This is the extent of the 'immediate' changes put forward by this proposal.
Follow ups
The more advanced features can be built on top of these changes as demonstrated in the following orthogonal extensions. This are in place to demostrate the ease with which such features can be delivered, but are not complete implementations of such features.

error formatting.
stack frames.
error filtering.
efficient serialisation.

Note that the above can be introduced without requiring changes on any other error type other than WrapError. More generally, in a WrapError compliant world adding functionality to all wrapped errors requires updating WrapError only.
Limitations and Breaking Changes
Note the migration to WrapError is needed before the follow ups above (and theremore, the primary gains) can be delivered, but WrapError and Wrap can be introduced (with no additional functionality) without any breaking change. This allows for a gradual migration before the ultimate breaking changes.
The primary backwards-incompatible changes are:

Removal of interface {Unwrap() error}:
it was added with go1.13 to the errors package as the fundamental method that defines wrapped errors. Errors implementing this need to be changed to no longer have this method nor contain other errors in their fields, and the wrapping be provided by the new Wrap method. This represents the largest breaking change in the proposal. A significant error in this category is os.PathError.
Limited fmt.Errorf support:
While %w-suffixed strings can be supported, having it elsewhere can't. This makes fmt.Errorf("foo, err=%w, bar", err) unsupportable, but fmt.Errorf("foo, bar, err: %w", err) is. Even in the suffix scenario, the requiremenet for formatting imposes for a uniform suffix syntax, presumably the ": %w" that was part of an earlier errors draft. A new fmt.WErrorf(error, string, ...interface{}) without %w may be altogether more suitable. Note that, more than an implementation detail, such standarisation is required if an error is to support formatting.
Phasing out type assertions:
While the preferred error type checking is via errors.Is and errors.As, type assertions are still used widely. These will not work as expected under WrapError,
since the type of the error is always WrapError even if the last wrapped error is of the type being asserted.

Though not a language change, following the new questionaire for language changes in the hope of making this easier to review.

Would you consider yourself a novice, intermediate, or experienced Go programmer?

Expert, ~6y using it.

What other languages do you have experience with?

C++ and Java, though neither at the level of Go.

Would this change make Go easier or harder to learn, and why?

No meaningful change.

Has this idea, or one like it, been proposed before?

If so, how does this proposal differ?

Go team proposals:
Error Values - Problem Overview and Error Printing — Draft Design: same objective (error formatting), but different implementation.
My own proposals:

errors: how should formatting be handled?: vague issue trying to get the level of priority towards error formatting.
counter proposal to error values (v2): currently 'under investiagtion', very similar to this one but very poorly communicated on my part.

Who does this proposal help, and why?

Anyone embracing wrapped errors trying to do anything but the bare minimum with them. For example doing not standard error printing (previously, I myself had to do JSON error encoding of wrapped errors) or wanting stack frames on their errors.

What is the proposed change?

Please describe as precisely as possible the change to the language.
What would change in the [https://golang.org/ref/spec](language spec)?
Please also describe the change informally, as in a class teaching Go.

No language change.
At first 1 additional type and 1 additional function in the errors package. Follow up changes will require further functions in the errors package.

Is this change backward compatible?

The follow up changes would have breaking changes, primarily the removal of interface {Unwrap() error} and allowed formatting in fmt.Errorf. Described in detail in the main post.

Show example code before and after the change.

Very little change for the average user of wrapped erorrs. Primarily from:
if err := nil {
  return myError{myData: ..., e: err}
}

to
if err := nil {
  return errors.Wrap(err, myError{myData: ...})
}

Richer examples in this repo and the various variants in the extensions directory within it.

What is the cost of this proposal? (Every language change has a cost).

No language change.

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?

Primarily vet, to highlight error types with an Unwrap() error method, errors containing other errors or unsupported formatting in fmt.Errorf.

What is the compile time cost?

None expected.

What is the run time cost?

The optimize extension actually shows it can be made to be more efficient than the current implementation, particularly for longer chains of wrapped errors. Adding stack frames would have a cost, though.

Can you describe a possible implementation?

Do you have a prototype? (This is not required.)

See this repo and the various extensions. The implementation is actually very small.

How would the language spec change?

It doesn't.

Orthogonality: how does this change interact or overlap with existing features?

N/A

Is the goal of this change a performance improvement?

If so, what quantifiable improvement should we expect?
How would we measure it?

Performance is not a goal.

Does this affect error handling?

If so, how does this differ from previous error handling proposals?

Yes, it targets error handling directly. It changes the definition of a wrapped error.

Is this about generics?

If so, how does this differ from the the current design
draft
and the previous generics proposals?

No

It changes the definition of a wrapped error.

We want a wrapped error to be defined by an interface so existing errors can conform. By requiring errors to be instances of WrapError, you would be breaking not only many things in the standard library, but also many error types across the Go ecosystem. I don't see how such a change could be smoothly introduced.

But by having wrapped errors defined by an interface the other advanced features can't be delivered. The cost of not doing anything is not negligible by any means.

I don't see how such a change could be smoothly introduced.

Best we can do is mitigate the damage. For that, the most urgent thing is to introduce the Wrap method and encourage it (via documentation, blog posts, vet, etc). At the very least, it won't make the problem larger by adding new instances of the interface one, and hopefully the errors than can be migrated without breaking their exported API will be. Hopefully most breaking errors can be dealt with through rewrite rules. Worst case scenario, it becomes a long process of many individual incompatibility breaks.

I have released a library, zerrors that implements the ideas exposed above, namely:

frame info: simply include in your main package import _ "github.com/JavierZunzunegui/zerrors/zmain" for wrapped error with Error() as "{err1}:{err2}: ... : {errN}" to transparently become "{err1} ({file1}:{line1}): {err2} ({file2}:{line2}): ... : {errN} ({fileN}:{lineN})".
error formatting: does the default error format (characterised by ": ") not work for you, or do you want the frames formatted differently? It is supported, i.e. the above could also be made to produce "{err1} - {err2} - ... - {errN}" , or indeed any other format.

The library is performant, in fact the frameless form is more so that fmt.Errorf or errors.New. Frames do come at a cost. Details in benchmark results.
The library uses the idea of a universal wrap error type outlines in this proposal.

Any project can start using their own new error type.
It's clear that different Go programs have different needs for error types.  The idea of adding new features to a standard error type runs directly counter to that.  We want the error type to provide the minimum required for all Go programs.  We don't want to slowly add features to it.
As @jba notes, the transition from error to some new type would be difficult, slow, and would never complete.
It seems better to provide this in a separate package, as you've already done.

Any project can start using their own new error type.

Of course - while the universal wrapper type holds the wrapping functionality, it may carry any custom error. That is already in zerrors: func Wrap(inErr, outErr error) error.

It's clear that different Go programs have different needs for error types. The idea of adding new features to a standard error type runs directly counter to that. We want the error type to provide the minimum required for all Go programs. We don't want to slowly add features to it.
As @jba notes, the transition from error to some new type would be difficult, slow, and would never complete.

To clarify it is not error that I propose to change in any way, but its wrapper form, interface {Unwrap() error}. The reason being the interface is not enough to do anything but the most basic wrapping, and building it up as an interface to have multiple methods (such as Format or similar) with an expected (non-trivial) standard implementation is probably more unrealistic still.

It seems better to provide this in a separate package, as you've already done.

I understand this has to start like this, as a separate library, and prove itself first. But while it remains outside the standard library and interface {Unwrap() error} exists, it is not universal, and the existance of such errors means it can't fully and safely implement all the things it could otherwise (including features that were once part of the official errors proposal). But I think it can show it could if it were to replace interface {Unwrap() error}, and I will try to ilustrate that (I am improving zerrors in that direction).

I have released<EMAIL_ADDRESS>WRT error formatting & stack traces: a single error produced by zerrors can be serialised in arbitrary ways, with or without stack frames. This is best shown in the benchmarks: the zerrors there (wErr and swErr) can produce both their own encoding as well as the %+v format of the popular golang.org/x/xerrors and github.com/pkg/errors(*). In other words, zerrors support error formatting without imposing any requirements on custom errors.
v0.2.0 also includes support for modifying the default encoding of zerrors, i.e. if you are migrating from say golang.org/x/xerrors, you can have all zerror's Error() and %+v format string forms remain unchanged.

(*): github.com/pkg/errors does  full stack capture vs zerrors single frame capture, which means it can't 100% replicate the format since the last few frames are not captured by zerrors.  Because golang.org/x/xerrors does single frame capturing too, zerrors does reproduce it exactly.

This has been released as a third party package (thanks!).  Let's see how that goes before considering adopting this into the standard library in some future release.  For now, this is a likely decline.  Leaving open for four weeks for final comments.

@ianlancetaylor I will be trying to spread awareness. Any visibility boost would be very welcome, I not active nor experienced in sharing to the community.

No change in consensus.


Feature: Force Feedback / Vibration

Adds Force Feedback support when player is harmed;

Hey @FusionLord, I am currently in the process of relicensing Controllable to a more suitable license. I would like your permission to relicense your contributions (all, not just this pull request) to Controllable under MIT.


Autocomplete don`t work in some specific cases (self and direct class hierarchy)

Tested versions

reproducible in 4.2.1

System information
Godot v4.2.1.stable unknown - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Fri Mar  1 18:16:16 UTC 2024 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 Ti SUPER (nvidia; 550.54.14) - Intel(R) Core(TM) i7-14700KF (28 Threads)
Issue description
It is quite often practice to use self. for recognition class defined
variables  usage from local variables usage which are without self prefix.
In current moment in situation like in screenshot autocomplete fail to work .
Working autocomplete (no self ):

Not Working autocomplete (using self ):

Also persist situations in case of usage Enums autocomplete working only for Global scope enums usage
Like in screenshot :
Working enum autocomplete using global enum scope:

But in case if used direct class member Enum define in parameters which is quite logical and predictable . Autocomplete fail to work.

Steps to reproduce
steps to reproduce so simple and do not require anything special
Minimal reproduction project (MRP)
it is not required any project and reproducible even with one node and default binded script.

The part about self is solved, see:

https://github.com/godotengine/godot/issues/85833

Please try 4.2.2.rc2

The second part I'm unsure about, that's an unusual way to access an enum

As mentioned before, the self problem is already fixed on master. Your enum problem is a duplicate of #88858 and would likely be fixed by #89382. So I'd suggest closing this issue as duplicate.

Hi . Sorry for dupe.
Yes we  can close


acceptTap but only for closing?

I am using a left drawer with a right offset, and want to allow tapping on the right side to close the drawer. However, I don't want to allow tapping on the left side of the screen (when the drawer isn't open) to open the drawer. Is there a way to use acceptTap but only for closing the drawer?
On a related note, when someone taps on the right side of the screen, buttons that are partially visible can still be pressed. Is there a way to make it so tapping on the non-drawer side will just close the drawer, but won't actually use the buttons that may have been tapped?

Tap close not open: At present the method to achieve this is to set onTap={this.state.open}.
this of course means you need to track the open state on your parent component using onOpen & onClose. I would accept a PR that adds a tapToClose prop which works as described.
Gesture negotiation: this problem is generally solved by setting captureGesture={true}. Let me know if that works for you.

I would also like to see a tapToClose because otherwise acceptTap={true} and dragging produces this:

I don't know if I have time to submit a PR, but I'll add it to my list.

Ah, now I understand the conflict. Just pushed a fix to master, will cut a release soon.

https://github.com/rt2zz/react-native-drawer/releases/tag/1.8.0
tapToClose prop
fixed tap/pan conflict

thanks! Works great :)

I tested it out and I think there is a bug. When I use acceptTap={true}, and the drawer is closed, my app isn't registering taps normally any longer if I tap on the left side. I am guessing there is an invisible mask that is where the offset should be, that is blocking what would otherwise work as a tap on my app's buttons.


IE8 compatibility

There might be some issues, the use of map here for example:
https://github.com/bitovi/system-npm/blob/master/npm-crawl.js#L31

Fixed by #17


Crash on Startup: 1.19.3

Unable to start minecraft 1.19.3 client via fabric loader 0.14.12 with radon 0.3.3 installed.  Only mods installed are Fabric API version 0.72.0 for 1.19.3 and Radon

Version 0.4.0 updates to MC 1.19.3


Update slug for Democratic Republic of the Congo in marriage-abroad

Trello card

Marriage abroad

Description
The slug for Democratic Republic of the Congo changed from democratic-republic-of-congo to democratic-republic-of-the-congo has changed in whitehall admin.
We need to change every occurrence of democratic-republic-of-congo in smartanswers to democratic-republic-of-the-congo in marriage-abroad.
Factcheck

Expected changes

URL on GOV.UK

Before

https://www.gov.uk/marriage-abroad/y/democratic-republic-of-the-congo/ceremony_country/partner_local/opposite_sex

After

https://smart-answers-pr-2791.herokuapp.com/marriage-abroad/y/democratic-republic-of-the-congo/ceremony_country/partner_local/opposite_sex

Thank you for your commit @leenagupte
Good to merge then 👍


Reflect all states from UWW score sheet

Adapt Bout Results to:
https://github.com/Oberhauser-Dev/wrestling_scoreboard/blob/5f6112fac18d931c4ecfeca6da67ea381aa1be6a/wrestling_scoreboard_client/docs/score_sheets/uww-score-sheet-competition-2023.pdf

Partially done in 6abdbdb1c0f76dde56c566430f2fcc12aca8ab52


Image Selection

As a User, I want to be able to select an image on the canvas so that I can perform various operations (like scaling, moving, rotating) on it.
Acceptance Criteria:

A user should be able to select an image by clicking on it. The selected image should be visibly highlighted or outlined.
A user should be able to deselect an image by clicking outside the image or on another element.
Scaling, moving, rotating is out of scope.

TBD:

Design of the selection.

Let's use selection approach similar to what we apply to monomers selection, just make the selection rectangular.

We are missing "Copy to clipboard". Can be added to the scope of this ticket.

Missed AC:

Image can be selected using selection tools: rectangle, lasso, fragment:

Image can be deleted using "Erase", "Clear Canvas" (Ctrl + Del) tools and buttons - Delete and Backspace.


fix: make sure setQueryData is not considered as initial data

:tada: This PR is included in version 2.15.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

This fixed: https://github.com/tannerlinsley/react-query/discussions/962


[NSE-913] Add support for Hadoop 3.3.1 when packaging

What changes were proposed in this pull request?
Fix #913
How was this patch tested?

We notice upstream Spark-3.2.0 and Spark-3.2.1 both choose Hadoop-3.3.1. To add support to Hadoop-3.3.1 for OAP 1.4 package, wonder whether we can change the default Hadoop version or add a Hadoop-3.3 profile. @weiting-chen Please help review this PR, thanks.


First request always takes at least 200 milliseconds

Expected Behavior
The first request should match the latency of the subsequent requests. The subsequent requests are in the impressive 0.7 - 1.0 ms range, which is faster than Postman. By quickly clicking "Send" over and over, the subsequent requests get this time.
Actual Behavior
The first request is actually 200+ ms. Postman is not inconsistent like this.
Reproduction Steps
The "first" request happens if it's the first request after opening Insomnia, or by waiting 5 seconds before sending it.
Sample code:
const http = require('http');
const PORT = 3000;

http.createServer(function (req, res) {
	res.writeHead(200, {'Content-Type': 'text/plain'});
	res.end('Hello World!');
}).listen(PORT);

Prerequisite for my sample code:

Install node.js
Pick an available port for the script.
Start with node sampleScriptName.js
Open Insomnia and add a GET request http://localhost:3000

Method 1:

Open Insomnia
Send the request
It takes 200+ ms

Method 2:

Insomnia is already open
Wait at least 5 seconds after the previous request
Send the request
It takes 200+ ms

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
I have also reproduced the error in Insomnia 2022.5.0-beta.5
Insomnia Version
2022.4.2
What operating system are you using?
Windows
Operating System Version
Windows 10 Version 21H2 19044.1826
Installation method
download from insomnia.rest
Last Known Working Insomnia version
N/A

Hi @RobbyCBennett, thank you for reporting this. I might be mistaken but this is a bit of a know issue, someone else from the team can correct me here.
I was able to in part reproduce this issue at least in Windows, with the first request seemingly taking 20ms and the remaining ones around 1 to 3 ms:

This needs a bit deeper investigation, though I believe I've seen this a couple of times, and more folks have also mentioned this issue ( #4612 ) and other similar issues like #3786.
We'll update you here as soon as possible.

I just tested it in another shell. It's more noticeable if node is running in WSL, which was my first test. My second test was with node running in CMD, and it's normally 0.5 ms and 1.5 ms during the first slow request.


Merge controllers of frontend with existing CRUD endpoints.

Just remove the controllers/frontend/ folder and put everything in controllers.

I think it makes sense, as the frontend controllers can also be reached under api/v0/fe and not the normal route api/v0/


Concurrent invocations of puts seem to interfere with each other

Since I am not sure if this is a Crystal issue or Kemal issue, I have reported this to the Kemal team as well (kemalcr/kemal#543).
Description
A simple server responds to get requests with random numbers in JSON format.  When the server is running on a Raspberry Pi and ab tool is used to issue sequential requests to the server in quick succession, the output of the server on standard output is garbled.
I am reporting the issue here as I am not sure if this is a crystal issue or a kemal issue.
Steps to Reproduce

Execute the server following the instructions in README.md
Execute ab -n 10 -c 1 http://<IP_ADDRESS>:1234/random?num=30

Expected behavior: The following or something similar should be seen in the terminal executing the server.
8.108ms
8.051ms
8.403ms
8.242ms
8.209ms
8.437ms
8.095ms
7.988ms
8.126ms
8.087ms

Actual behavior: The following is seen in the terminal executing the server.
-159659774543452127413503ApacheBench/2.3<IP_ADDRESS>:1234/random?num=30��<�pyR�p��%�h2.3
                                                                                /get/random34
                                                                                /get/rams
-1358916334152017894057263��7R뱵��Al`|��34
                                          /get/random096<IP_ADDRESS>:41128	<IP_ADDRESS>
                                                                                /get/random2.3ms
321435393.761ms
-0.000ms
-0.000ms
4076574188583769414937274��&��5���Qg����2.3
                                           /get/random34
                                                        /get/random30
                                                                     /get/random<IP_ADDRESS>:41152	127.0ms
-902563470739474328704365�^��b�Z'�v�;�ق2ms
-108291519172398526629057��1m�EU]�K�����9�2.3
                                             /get/random34
                                                          /get/randomms
0.000ms
-0.000ms

Reproduces how often: Always
Versions
Crystal 0.29.0 (2019-07-20)
Kemal 0.25.2
LLVM: 6.0.1
Default target: arm-unknown-linux-gnueabihf
Linux master10 4.14.34-hypriotos-v7+ #1 SMP Sun Apr 22 14:57:31 UTC 2018 armv7l GNU/Linux
Additional Information
The object file of the crystal compiler was compiled on Ubuntu/Laptop and then linked to create the executable on Hypriot/RaspberryPi.

I observed similar garbled output even after isolating puts into a dedicated fiber.

Totally offtopic, but there's no need to do Random.new every time. You can just use the top-level rand method.

I can't reproduce this on Mac OSX.
I don't think Crystal works fine on a Raspberry Pi. At least it's not something we officially support it so it'll be very hard for us to give help on this.

I haven't observed this issue on Linux.  Just on Raspberry Pi 3.  Since Crystal works on Linux and RaspPi runs Linux, I figured Crystal would work on RaspPi if Crystal could be cross compiled to run on RaspPi (even if this configuration is not supported).  Clearly, that is not the case :)

i feel like this is a unique and specific use-case. it also can't be reproduced on WSL or Debian

I am not sure if this an issue with cross compilation (that is causing the compiled program to output garbage) or the Crystal compiler on Raspberry Pi.  Any suggestions to verify this is welcome.
So far, I have tried building Crystal on Raspberry Pi 3B by 1) using the cross-compiled compiler and 2) bootstrapping the compiler (crystal-lang/boostrap-script).  First approach failed due to insufficient memory while the second failed due to failure in building ruby in the first stage of bootstrapping.
That said, I am looking for a way to compile Crystal programs to run on Raspberry Pi 3B.  Doing so on Raspberry Pi would be ideal.

@rvprasad Do yo know what architecture is Raspberry Pi running on? Or check if this gives true?
{{ puts flag?(:aarch64) }}

If so, #7983 might fix this issue.

Rasp Pi 3B uses Armv7 (v7l) processor.  So, the above test fails.

I did some digging with gdb.  For this, I changed
puts "%.3fms" % (elapsed_time.total_nanoseconds / 1e6)

to
tmp1 = "%.3fms" % (elapsed_time.total_nanoseconds / 1e6)
puts tmp1

When a single request was submitted to the server, I found all of the strings and puts output were well-formed.
(gdb) info locals
ret = 0x245be8
elapsed_time = {seconds = 0, nanoseconds = 190677}
tmp1 = 0x260e60
(gdb) print &(tmp1->c)
$5 = (UInt8 *) 0x260e6c "-0.000ms"
(gdb) print &(ret->c)
$9 = (UInt8 *) 0x245bf4 "[680012]"

However, while elapsed_time.total_nanoseconds was 190677, the second string was "-0.000ms".  This is wrong.
When two concurrent requests were submitted to the server, ret was well-formed but tmp1 was not.
(gdb) info locals
ret = 0x245990
elapsed_time = {seconds = 0, nanoseconds = 191874}
tmp1 = 0x23de10
(gdb) print &(tmp1->c)
$10 = (UInt8 *) 0x23de1c "-501870678723681322067296"
(gdb) print &(ret->c)
$11 = (UInt8 *) 0x24599c "[926334]"

Changing puts "%.3fms" % (elapsed_time.total_nanoseconds / 1e6) to puts "#{elapsed_time.total_nanoseconds / 1e6}ms" reduces the frequency of garbled output and the amount of garbled output in each instance.

There is an issue with hard/soft floats on ARM 32 targets. Specifying the target CPU while compiling may help LLVM backend to generate proper code (or not).

@ysbaddaden if you are suggesting floating point calculations (not operations involving floating point values) pose issues on ARM 32 targets, then I doubt that is the case as I was able to generate garbled output with the below minimal program.
require "kemal"

get "/random" do |env|
  tmp1 = "%fms" % 3.333
  puts tmp1
  tmp2 = "%dms" % 3.333
  puts tmp2
  ""
end

Kemal.config.logging = false
Kemal.config.port = 1234
puts "Serving at <IP_ADDRESS>:1234"
Kemal.run

Submitting a single request to the above server produces the following output:
$ ./server
Serving at <IP_ADDRESS>:1234
-158972576233719173059H�/getget

get/random/getget

/ws/randomms
3ms

To cross-compile the compiler,

Ran ./bin/crystal build src/compiler/crystal.cr --warnings all --cross-compile --target "armv6-unknown-linux-gnueabihf" -s -D without_openssl -D without_zlib on a Ubuntu box.
Copied crystal.o onto a Raspberry Pi 3B running Raspbian 9.9 (from Hypriot).
Ran sudo cc 'crystal.o' -o '/usr/lib/crystal/bin/crystal' -rdynamic /usr/share/crystal/src/llvm/ext/llvm_ext.o `/usr/bin/llvm-config-6.0 --libs --system-libs --ldflags 2> /dev/null` -lstdc++ -lpcre -lm -lgc /usr/share/crystal/src/ext/libcrystal.a -levent -lrt -ldl -lpthread -L/usr/lib -L/usr/local/lib after copying crystal/src into /usr/share/crystal/src (following the instructions here].

It seems the format specifier for float (%f) is broken.

Well, the stringifier for floats uses float arithmetic and that might be broken as @ysbaddaden mentioned. Why do you doubt that this could be the issue?

For %f we call sprintf, there might be an issue there. But it's hard if we can't reproduce it on Mac and Linux.

@straight-shoota TIL stringifying float values involves floating point calculations/arithmetic operations :)  That said, it seems the floating point operations (e.g., the division operation worked fine) in the application code seems to work fine while the ones used to stringifying floats seem to be broken.  Nevertheless, I will check this.

Don't use floats, at all. Use integers instead —and don't round a float!
The problem with hard/soft floats is that the caller/called ABI doesn't expect the value in the same registers (cpu integers vs fpu registers), which results in garbage.

The format_buf and float args to the invocation of LibC.snprintfat src/string/formatter.cr:265 are valid but the value filled into temp_buf is invalid.  This is in line with @asterite's comment.

@asterite I was able to reproduce the issue in a Raspbian container running on a Linux host.  The instructions to use the Docker image to create a compiler is available in docker-files repo.  Once you have built the compiler and shards in the container, the issue can be repro-ed by building and executing the example.  You will need to install curl in the container (via apt install curl) to repro the issue.

Is the linux host running on armv6 as well or is it an x86 architecture? Raspbian has an x86 variant, so I'm not sure.

The Linux host is a x86 machine while the Raspbian is running on armv7l emulator.

Please read the following:

https://github.com/crystal-lang/crystal/pull/3424#issuecomment-255971241
https://github.com/crystal-lang/crystal/pull/3424#issuecomment-255977488
https://github.com/crystal-lang/crystal/pull/5862#issuecomment-468187793

Likely a duplicate of #6954
All ARM isues are related to a hard/soft float issue. Specifying a CPU when compiling may fix the issue (it did for my qemu raspbian image) or not (fails on scaleway armv7 server, and reportedly rpi3).
Reproducing isn't an issue. It's quite easy to. The problem is understanding why LLVM won't enable hard floats when compiling. Maybe we miss some LLVM attributes on functions? I recently noticed that clang sets a bunch of them, related to FP and soft-float.

Maybe I'm saying something stupid, but for hard float you should specify cpu, fpu and float abi: -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16

@konovod I tried doing this today but I gave up as I could not figure out how to pass these flags to LLVM compiler from the command line interface of crystal compiler.

@ysbaddaden Thanks for the pointer.  I read thru some of these while digging around.  BTW, what is the best way to pass the compiler options mentioned by @konovod to LLVM via crystals CLI?  That would allow more experimentation.

The format_buf and float args to the invocation of LibC.snprintfat src/string/formatter.cr:265 are valid but the value filled into temp_buf is invalid.

What do you mean?

Maybe we just miss the "use-soft-float"="false" attribute on every functions? It should always be false, unless the target's arch is arm and the ABI is *eabi.

@asterite I wasn't sure at which program point were the memory addresses getting messed up.  So, I dug around and found that format_buf (the format string) and float (the value to be printed) arguments passed to LibC.snprintf at src/string/formatter.cr:265 were indeed the values they should have been.  Assuming the other input argument len was valid, the fault resulting in the garbled output is encountered sometime after the LibC.snprintf is invoked at src/string/formatter.cr:265.  This kinda aligns with @ysbaddaden suggestion -- ABI mismatch between the app and libc.

The failure occurs only when the foo() is invoked within the context of a Kemal Handler (at call2 and not at call1).  This seems to suggest the issue may be specific to Kemal and not related to ABI or hard/soft floats.  [I have mentioned this in kemalcr/kemal/issues/543.]
require "kemal"

def foo()
  tp1 = "%fms" % 3.333
  puts tp1
  tp2 = "%dms" % 3.333
  puts tp2
end

foo()   # call1

get "/random" do |env|
  foo() # call2
  ""
end

Kemal.config.logging = false
Kemal.config.port = 1234
puts "Serving at <IP_ADDRESS>:1234"
Kemal.run

What happens if you just use http server from the standard library? I don't think kemal is involved here.

The below snippet fails as well.
require "http/server"

def foo()
  tp1 = "%fms" % 3.333
  puts tp1
  tp2 = "%dms" % 3.333
  puts tp2
end

foo()   # call1

server = HTTP::Server.new do |ctxt|
  foo() # call2
  ctxt.response.print "Boo"
end

address = server.bind_tcp 1234
puts "Serving at #{address}"
server.listen

Output
3.333000ms
3ms
Serving at <IP_ADDRESS>:1234
-158972575660657402946.

keep-alive

Keep-Alive

ConnectionHoidentity*/*ms
3ms

Cool! Now you could try reducing it to using spawn and Fiber.yield in between calls, and spawning a lot of fibers and see if it still reproduces.
The less code we have that reproduces the problem, the easier to find the cause.

(I'll send such code later today)

@rvprasad Try this:
chan = Channel(Nil).new

1000.times do |i|
  spawn do
    tp1 = "%fms" % 3.333
    puts tp1
    Fiber.yield
    tp2 = "%dms" % 3.333
    puts tp2
    chan.send(nil)
  end
end

1000.times do
  chan.receive
end

@asterite Thanks.  I was able to repro the issue in the Docker container.
spawn do
  tp1 = "%fms" % 3.333
  puts tp1
end

sleep(10)

What output you get with that program?

It produces the following output in a container.
root@4b026a742082:/t/t# crystal run -d s.cr
Using compiled compiler at `.build/crystal'
-158972575643887689414`?� I�l@Z~?6�~΄/t/t//t/t@@ms

But it works fine if you don't do it inside spawn?

Yes.
Also, output is fine when spawn is replaced with 1.times.

@ysbaddaden In the below snippet, foo prints 1.000000 2.000000 when invoked in mydo but it prints 0.000000 0.000000 when invoked in the fiber.  Since the same code fragment provides both "correct" and "incorrect" outcomes, I doubt if this is an ABI related issue but...
The float argument to corresponding calls to LibC.snprintf in string/formatter.c in the above invocations are identical, i.e., 1.0 and 2.0.  So, it seems the context swapping is interfering with the call to an external library function.
def foo
  i = {1.0, 2.0}
  printf("%f %f\n", *i)
end

def mydo(&x)
  x.call()
end

mydo(&->foo)
spawn foo

sleep(2)

Any ideas on what/where might be the issue?

We save/restore FPU registers on ARM when switching fibers, and it leads to the same hard/soft float codegen bug.

I assume this is not multi threaded?

I want to experiment with different LLVM compiler flags during code generation, e.g., related to FPU and NEON.  Any ideas where and how these flags can be added/modified/specified?

I know this issue has been dormant for a couple of years, but I wanted to bring up that I have also experienced this, although it was much earlier this year.


TS/SassPlugin and SCSS imports have different paths in SourceMaps file

Steps to reproduce:

in app/index.ts => import('index.scss');
in app/index.scss => @import 'sub';
use following setup:

const {
  FuseBox,
  SassPlugin,
  CSSPlugin,
} = require('fuse-box');

const path = require('path');

const basePath = 'app';
const distPath = 'dist';

const fuse = FuseBox.init({
  homeDir: basePath,
  output: `${distPath}/$name.js`,
  tsConfig: 'tsconfig.json',
  log: true,
  debug: true,
  cache: false,
  sourceMaps: {
    inline: false,
    sourceRoot: `/${basePath}`
  }
});

fuse.bundle(basePath)
  .plugin([
    SassPlugin({
      sourceMap: true,
      outputStyle: 'compressed'
    }),
    CSSPlugin({
      inject: file => `/${file}`,
      outFile: file => `${distPath}/${file}`
    })
  ])
  .target('browser')
  .instructions(`> index.ts`);

fuse.run();

Demo:
https://github.com/rs3d/fuse-box-sass-issue
Results in dist/index.scss.map
{"version":3,"file":"index.scss","sources":["/app/index.scss","/app/app/_sub.scss"],"names":[],"mappings":"ACAA,AAAA,IAAI,AAAC,CACD,UAAU,CAAE,GAAG,CAClB,ADAD,AAAA,IAAI,AAAC,CACD,KAAK,CAAE,IAAI,CACd"}

==> wrong path here /app/app/_sub.scss

Forgot to mention that i used FuseBox with this PR https://github.com/fuse-box/fuse-box/pull/773/files
Without this change _sub.scss is not included as source.

@rs3d - if you move _sub one level down e.g. styles/_sub.scss helps right? This is what I was thinking of as I created the PR. I tried to avoid any breaking changes of this line  - ofc I don't know if its a breaking change.
I think the best way to tackle this is to change the node-sass options here and add file property to something like this
const options = Object.assign({
    data: file.contents,
    sourceMap: true,
    file: file.info.absDir+"/"+file.info.fuseBoxPath,
    outFile: file.info.fuseBoxPath,
    sourceMapContents: true
}, this.options);

this will also remove stdin from the sources and provide the correct path. file.info.absDir also helps to have the right path hierarchy (with subforlder e.g. /src/index.scss or /app/index.scss). Currently you get somethink like index.scss (with this.info.fuseBoxPath) for the root file but src/sub.scss for all related. So its not following the same schema or I'm wrong?
and change it here to:
jsonSourceMaps.sources = jsonSourceMaps.sources.map((source : string) => {
    return this.context.sourceMapsRoot + "/" + source;
});

And for `sourceRoute:''`` this line need to be adjust to:
if (params.sourceRoot || params.sourceRoot === '') { }

so the result for the repo with  sourceRoot :'' would be:
{"version":3,"file":"index.scss","sources":["/app/index.scss","/app/_sub.scss"],"names":[],"mappings":"ACAA,AAAA,IAAI,CAAC;EACD,UAAU,EAAE,GAAG;CAClB;;ADAD,AAAA,IAAI,CAAC;EACD,KAAK,EAAE,IAAI;CACd"}

and with not providing sourceRoot (be default its ./src:
{"version":3,"file":"index.scss","sources":["/src/app/index.scss","/src/app/_sub.scss"],"names":[],"mappings":"ACAA,AAAA,IAAI,CAAC;EACD,UAAU,EAAE,GAAG;CAClB;;ADAD,AAAA,IAAI,CAAC;EACD,KAAK,EAAE,IAAI;CACd"}

I can craft a small PR if its ok to solve it this way. @rs3d @nchanged What do you think?

@zigmo sounds good to me ;-) thanks for you help!

@nchanged sure? I think e.g. examples will not work anymore by default, because /src will be added by default but sourceMaps now respect the hierachy. So I have to set ``sourceRoot:''to make it work by default. Don't you think that a lot of people have their source in/srcand this worked before out of the box and now this will be/src/src/....` - or I'm wrong?

@zigmo I haven't gotten into it yet.  I think we can default it to sourceRoot:''

@nchanged I'm just concern about the side effect on this line for typescript
with respecting of sourceRoot:'':
{"version":3,"sources":["/index.ts","packages/fuse-box-css@0.0.1"],"names":[],"mappings":";;;;;;AAAA,wBAAsB;

and keep it like it is:
{"version":3,"sources":["/src/index.ts","packages/fuse-box-css@0.0.1"],"names":[],"mappings":"

but my homeDir is /app
with sourceRoot :'/app':
{"version":3,"sources":["/app/index.ts","packages/fuse-box-css@0.0.1"],"names":[],"mappings":";;;;;;AAA

but than sass sourceMaps are broken because its already repects the hierachy:
{"version":3,"file":"index.scss","sources":["/app/app/index.scss","/app/app/_sub.scss"],"names":[],"mappings":"ACAA,AAAA,

and now I'm thinking that this should be related to my homeDir, too... mhhh

that should be related to your homeDir, In fact, if you have an idea how to remove node_modules sourcemaps - even better, they are there cuz of some nasty bug.  They should be there only when requested

Well i see it as a bugfix/clean up if we set sourceRoot:'' as default.
If this breaks some sourceMaps in dev environments it's not that breaking change while bundling is still working and people have to update fuse-box to experience this.
Proper sourceMaps with nested scss sources is outweighing this minor change imo.
@zigmo Your change is working for me, ty!

<EMAIL_ADDRESS>please test ;-)

For the log<EMAIL_ADDRESS>is solving my issue!


"There have been too many unsuccessful login attempts. Try again later." after my first login attempt.

Describe the bug
"There have been too many unsuccessful login attempts. Try again later." after my first login attempt.
I'm as sure as I can be that my password is correct, as I use a password manager.

Expected behavior
Let me log in.
To Reproduce
Log in, I guess?
My Platform

macOS, both Safari and Chrome
Additional context
My spouse was logging in on her account as well, from the same IP, at around the same time; I tried this after she was getting the error.

It worked on my second attempt so the issue is intermittent

Anecdotally, I think I vaguely recall seeing this before as a user, but I don't recall any additional context that'd help track down why it happened.

Thanks for the issue!

My spouse was logging in on her account as well, from the same IP, at around the same time; I tried this after she was getting the error.

We currently have a fairly aggressive ratelimit on failed logins, keyed by IP address. It seems likely that your spouse tripped this ratelimit for your shared IP, which then caused your login attempt to fail. If you can provide your spouse's PyPI username, I can confirm this.
We have this in place to reduce the effectiveness of credential stuffing attacks across multiple accounts from a single IP. The ratelimit is easy to trip, but has reset windows that are intended to not be too inconvenient to a regular user, but severely reduce the speed at which an attacker can test authentication credentials.
As such, I think this is generally working as intended (most legitimate users don't experience this ratelimit, and ones that do have behavior that appears suspicious to us, but can wait a few minutes and be able to log in) but if you have any ideas on how this could be improved that wouldn't impair our ability to slow down attackers, feel free to let us know.


Bug: On Window Resize Egui looses the position

When we change the value from
false to true inside glfw.window_hint(glfw::WindowHint::Resizable(true)) of the demo, the ui doesn't fit the total area. It seems the pivot is beeing set to the bottom left. The widgets become irresponsive, because the location where the interaction occurs doesn't change to the new location where the widgets are beeing draw.
https://user-images.githubusercontent.com/2336812/233203846-7aa91ee6-a783-423a-b8c5-4624742a611c.mp4
Thanks!

I will take a look at it later today


Add predefined preprocessor: scenarioNumbering

Create a predefined preprocessor, which would add the index of all scenario/scenario outline to their name, to make their name unique.
It should receive a configuration:

{string} format - the format how the index should be added, default: "${i}. ${name}", where

${i} is the placeholder for the actual index
${name} is the placeholder for the original title of the scenario/scenario outline

@judit-nahaj what do you think, would this preprocessor be useful?


Versions after <IP_ADDRESS>1 do not display some SVGs properly (image seems to be cropped)

🔙 Regression

Old (and correct) behavior
Attached test.svg is properly displayed on iOS and Android

Current behavior
Image seems to be cut off or cropped

Reproduction steps
Load attached test.svg in the mobile app
Configuration
Version: <IP_ADDRESS>1 - works
Version: <IP_ADDRESS>2 and next - does not work
Xamarin version: <IP_ADDRESS>1477
Platform:

[x] :iphone: iOS
[x] :robot: Android
[ ] :checkered_flag: WPF
[ ] :earth_americas: UWP
[ ] :apple: MacOS
[ ] :tv: tvOS
[x] :monkey: Xamarin.Forms

(See svg in archive)
test.zip
Thanks

can you try the version <IP_ADDRESS>9?  for me this is the best working version till today


grammar - it is

Problem Statement
Documentation grammar
Proposed Changes
added "'s"
Checklist

[x ] I have read the contribution guidelines
[ x] All commits are signed with git commit --signoff
[x ] My changes have reasonable test coverage
[x ] All tests pass with make test
[x ] I ensured my PR is ready for review with make reviewable

Hello @aviadkray 👋
Would you please sign your commit as instructed here? https://github.com/external-secrets/external-secrets/pull/2991/checks?check_run_id=20084531794
Then we can merge this. :) Thanks! :)


Experiment with extra check for an uploaded file

This double checks an uploaded file's existence in the pre-finish hook, which is called after a file is uploaded but before a response to a client.

quick benchmark shows no meaningful change in performance with or without validation.


Typescript migration

Base tasks:

[ ] Install and configure TS
[ ] Migrate:

[ ] utils
[ ] routes
[ ] tests

/cib


Create RTL view

Pull Request Template
Issue
Addresses #248

[ ] This change addresses the issue in full
[x] This change addresses only certain aspects of the issue
[ ] This change is a dependency for another issue
[ ] This change has a dependency from another issue

Description
Sets site text direction to RTL.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Prototype/POC (not to merge)
[ ] This change is a refactor/address technical debt
[ ] This change requires a documentation update
[ ] This change requires a SQL Script

How Can This Be Tested/Reviewed?
Please describe the tests that you ran to verify your changes. Provide instructions so we can review. Please also list any relevant details for your test configuration

[ ] Desktop View
[ ] Mobile View
[ ] Test A
[ ] Test B

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have reviewed the changes in a desktop view
[ ] I have reviewed the changes in a mobile view
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have assigned reviewers
[ ] I have updated the changelog to include a description of my changes

@willrlin I tried this but got stuck after the NPM install.  Wouldn't mind some time pair programming if you are free today/tomorrow.

Sure, feel free to schedule some time tomorrow!

Closing as this was previous RTL view attempt.  New solution implemented.


Doesn't scale with many shops

As much as I like this plugin, having lots of shops causes excessive use of simultanious java threads both in paperspigot and spigot. These threads causes some kind of starvation, high load average, and in the end starvation on the java process causing lag and users to disconnect.
Neither paperspigot timins/tps nor the operating systems ps/top caught any cpu intensive tasks, though load average spikes extremely high at most peaking at 1900 load average, but every thing except this worlds java process was still responsive. Counting ps output of running threads regularely counts > 1000  with > 700 shops.
Using jvisualvm, it becomes clear that ShopChest is the one creating the threads and removing the plugin gets the server back to normal without the thread numbers going wild.
I guess the plugin is working as intended with seperate threads doing it's work to reduce in-game lag but it doesn't scale to a large number of shops.

Been having increasing lag on the server, and recently the plugin crashed the server completely and it could not restart until I removed the plugin. Once I removed it, it seems as if the lag was gone until I re-added it (It is still installed at the moment). It would be nice to see a fix, since this is a good plugin.

@EpicEricEE please, this is an important issue for large servers.

I am aware of that, but I'm not exactly sure what to do about it.

try handling some stuff with async tasks, if possible

if the problem is threads you have to check again how you are using async tasks, probably your design is wrong.


NotebookCellOutput.metadata returned by content provider does not end up in Notebook document

VS Code Version:
OS Version:

Steps to Reproduce:

Create a Notebook content provider and return cells with output and the output containing metadata
The Notebook document generated by VS Code will not contain the metadata in the outputs
@jrieken @rebornix /cc

Tests can be found here https://github.com/microsoft/vscode/pull/116968/files

Does this issue occur when all extensions are disabled?: Yes/No

Actually fixed via #116968


Crash during shutdown (documentation bug)

The documentation over at discord does not mention that you have to call Discord_Shutdown even though it is vital for a clean shutdown.
If you don't call Discord_Shutdown then the application does not shut down properly. You have a static variable of type std::thread which will run its destructor during termination of the application. Running a destructor on a running thread is not allowed and will crash the program (calls std::terminate)
This prevents a clean exit because other destructors and onexit handlers are not executed.
You apparently have Discord_Shutdown which properly terminates the thread, allowing clean shutdown of the game, but you haven't mentioned this anywhere in your documentation.

Will get it added—thank you very much!

This has been added here: https://github.com/discordapp/discord-api-docs/commit/5be941b5230524e0db6b49e26af6357d514303ec
Thank you very much for this important info.


something wrong with hmr2_data.tar.gz

I can not tar it correctly on several OS, leading the lose of "model_config.yaml"!
How can i get this?
Thanks for ur attention!

Oh ! It has nothing to do with the tar and my operation, i can not download the complete zip from "https://people.eecs.berkeley.edu/~jathushan/projects/4dhumans/hmr2a_model.tar.gz"
Would u test the file server plz?

oh,i have fixed the problem, and i am very helpless about China’s National Firewall

Please check this issue: https://github.com/shubham-goel/4D-Humans/issues/127#issuecomment-2170618221

I am wondering how do you solve this problem @SuSuYMH with the China’s National Firewall. Thanks!

It's indeed the problem of China’s National Firewall. And I have fixed it, thanks!


Revert "Add input for setting detect-secrets version"

Reverts reviewdog/action-detect-secrets#58

It's breaking change to be precise, but I think it's fine to bump just minor version considering it's was released recently and it actually didn't work.

@haya14busa yes, thank you. I wasn't sure what process you had here around issues like this. I think this is fine as a minor release.


Akka-HTTP

Hi there,
Spray is moving into maintenance mode. Will spray-swagger support Akka-HTTP going forward?
Kind regards,
Jacobus

It looks like the community has forked this project and is experimenting with akka-http and swagger, see #60. I don't think spray-swagger itself will move to akka-http; rather, a new project would probably be better supporting akka-http and swagger2. I also don't think the annotations-based approach required by swagger-core is that great with spray (nor akka-http). The dream would be parsing the raw-swagger json file at compile time (maybe with macros/quasi quotes) and using that as a stream producer of messages for your app and models.

:+1:


make error w/icc

With 1.1.1 I am now able to get to the final step. But at around 2% I get an error while building "ospray/embree-v2.7.1/common/sys_xeonphi/CMakeFiles/sys_xeonphi.dir/sysinfo.cpp.o"
The error is "icc: warning #10274: cannot find configuration for platform /intel/compilers_and_libraries_2017.0.098/linux/bin/intel64/x86_64-linux.env
icc: warning #10379: Problem with offload compilation environment. Offload target compiler or the supporting libraries not found"
This looks like a problem with icc not being setup properly from what I can tell. I am using Intel Parallel Sudio 2017 and do not know it well. Is there something I need to do in order to generate the .env file?

Hmmm, I must admit I haven't tried the latest icc w/ our KNC build (all testing there done with 2015.3), but I haven't seen this issue before with any version of icc. Are you able to build without KNC enabled?

KNC disabled = MIC support OFF in ccmake, correct?
With this disabled the following error appears intermittently throughout the process after starting 'make'
"icc: warning #10237: -lcilkrts linked in dynamically, static library not available."
But it will still finish to 100% rather than aborting.
One thing I did leave out last post by accident, I am using a trial version of Parallel Studio.

Correct, and the warning message #10237 is known and will be fixed. FYI, the trial version of Parallel Studio is the same a the full version, it just expires after 30 days.
My next question is: is the original icc warning causing any problems? I originally thought you were blocked by an error, but it appears to only be a warning. If it's an offload warning, it may be only a warning for icc features we are not using in OSPRay, such as the #pragma based offloading stuff. COI is a library based approach we used for offloading, which icc doesn't know about besides the library we build against.
I'll try to get the latest icc on a machine with MIC cards in it to replicate the problem soon, but it may be a week or two before I can get to it. The only suggestion I would have in the mean time would be to try using the version I've been using to check our KNC features, which is Parallel Studio 2015.3. That one worked with COI+MIC.

The original icc warning resulted in a stop of the make process, It never got past 2%. But with MIC support off it was able to finish. The #10237 was seen with MIC support OFF and still finished. While the #10274/10379 were during MIC support ON and the make process aborted there.
Would you happen to know if 2015 would still be available as a trial? I am only using it to compile for a demo so purchasing it to compile one thing is a bit much.
Thank you for your help so far btw.


Helm 3 Beta 5 SecurityContext DaemonSet fails

Describe Issue
When using Helm-3-beta5 and installing a chart that has a DaemonSet that has a pod Security Context and an Update Strategy, the following error gets printed:
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(DaemonSet.spec.template.spec.containers[0].securityContext): unknown field "fsGroup" in io.k8s.api.core.v1.SecurityContext, ValidationError(DaemonSet.spec.template.spec.containers[1].securityContext): unknown field "fsGroup" in io.k8s.api.core.v1.SecurityContext, ValidationError(DaemonSet.spec.template.spec.securityContext): unknown field "privileged" in io.k8s.api.core.v1.PodSecurityContext, ValidationError(DaemonSet.spec.template.spec): unknown field "updateStrategy" in io.k8s.api.core.v1.PodSpec]

The Security Context values are:
securityContext:
  privileged: true
  runAsUser: 0
  fsGroup: 0

And the UpdateStrategy is:
updateStrategy:
  rollingUpdate:
    maxUnavailable: 1
  type: RollingUpdate

This worked with Helm-3-beta4
$ h3 version
version.BuildInfo{Version:"v3.0.0-beta.4", GitCommit:"7ffc879f137bd3a69eea53349b01f05e3d1d2385", GitTreeState:"dirty", GoVersion:"go1.13.1"}

Output of helm version:
$ helm version
version.BuildInfo{Version:"v3.0.0-beta.5", GitCommit:"509a8819b7e8dba86b7982c006fce22628aeea28", GitTreeState:"clean", GoVersion:"go1.13.3"}

Output of kubectl version:
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"d647ddbd755faf07169599a625faf302ffc34458", GitTreeState:"clean", BuildDate:"2019-10-02T17:01:15Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-07-08T19:16:39Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):  Local bare metal OKD v3.11
$ oc version
oc v3.11.0+0cbc58b
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://okd.example.net:443
openshift v3.11.0+01dd962-225
kubernetes v1.11.0+d4cacc0

3.0.0-beta.5 added OpenAPI validation for resources (see #6599). It's likely that the DaemonSet resource you are trying to install fails validation, which means it does not match the schema provided by Kubernetes.
Looking at the SecurityContext API schema, fsGroup does not exist as part of that field. It is part of the Pod Security Policy spec.
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#securitycontext-v1-core
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#podsecuritypolicyspec-v1beta1-extensions
Please check and ensure that the DaemonSet complies with the OpenAPI schema for your version of Kubernetes.
For reference: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11
Closing as resolved.


Ignore inverse dependencies when building graph

Summary
It turns out that when we iterate over the incompatibilities of a package, PubGrub will also show us the inverse dependencies. I suspect this was rare, because we have a version check at the bottom... So, this specifically required that you had some dependency that didn't end up appearing in the output resolution, but that matched the version constraints of the package you care about.
In this case, langchain-community depends on langchain-core. So we were seeing an incompatibility like:
FromDependencyOf(Package(PackageName("langchain-community"), None, None), Range { segments: [(Included("0.0.10"), Included("0.0.10")), (Included("0.0.11"), Included("0.0.11"))] }, Package(PackageName("langchain-core"), None, None), Range { segments: [(Included("0.1.8"), Excluded("0.2"))] })

Where we were iterating over langchain-core, and looking for version 0.0.11... which happens to match langchain-community. (`langchain-community was omitted from the resolution; hence, it didn't exist in the map.)
Closes https://github.com/astral-sh/uv/issues/2358.

This is pretty hard to reproduce.

I can reproduce with just:
b2sdk==1.32.0
llama-index==0.4.40

But it's an expensive test.


Support TSP App 2121

Is the objective to support TSP 2121-1 or (proposed) TSP 2121-4?

TSP 2121-1, but soon TSP 2121-4 when it will be ready.

Do we know when this is going to be merged into the master branch and a new version released?

Soon as Netflix guys will review it.
I hope before NAB :-)

@cconcolato is it possible to have a feedback on it ?
Thanks

I've merged #239. Can you update your PR to reflect that?

Is this PR still active? Can you update it?

Yes I'll check with first IMF Package from Plugfest before push the update.


After Dark Theme Migration

After Dark is saying goodbye to GitHub and moving to: https://git.habd.as/comfusion/after-dark/
I've already made all the necessary preparations. Note I had to rewrite the entire commit history to update author email after GitHub retroactively Unverified my all of my commits (true story).
Given my server is running on a VPS it may occasionally go down while I'm performing routine maintenance. If this could potentially break the update script my suggestion is for Hugo to consider starting an organization on GitLab (hosted) and begin mirroring theme site repositories there.
Once the update is complete I will reach out to GitHub support and ask if they'll be so kind as to set-up some redirects to help prevent linkrot after I close my GitHub account.

Well that was easy. 🥇

Hi Josh,

I've already made all the necessary preparations. Note I had to rewrite the entire commit history to update author email after GitHub retroactively Unverified my all of my commits (true story).

This shouldn't affect the theme website per se.

Given my server is running on a VPS it may occasionally go down while I'm performing routine maintenance. If this could potentially break the update script

The update script is me typing git submodule update --remote into the console. So nothing will break here :wink:
I've updated the remote url of your theme and cleared the cache for the Hugo theme site. Once the rebuild finished I'll check if everything looks fine.

 Please lmk if I can help clear any of your workload on here. Sorry for my quasi-trolling. Guilty.

It was later decided by @bep self-hosted themes will not be allowed on the theme site. I was not given a heads up prior to the removal, which honestly felt like a slap in the face after investing 2 years into my Hugo theme.

Related: https://github.com/gohugoio/hugoThemes/issues/371


Force CMake targets in top-level Makefile to run

This is a bug I introduced in https://github.com/apache/tvm/pull/8809, because the built binary is now named build/cpptest when make checks that artifact it finds it exists already and skips running make -C build cpptest. This ensures all nested make calls are forced to run from the top-level Makefile.

@Lunderberg could you take a look at this please? :smile_cat:

Looks good to me, and thank you for the fix!  Looks like I accidentally left that trap in #8317, since at the time none of the cmake rules produced a file with the same name as the rule.


HL-450: add duration_in_months_rounded to the application API

Description :sparkles:
The field is needed for display in the UI
Issues :bug: HL-450
Testing :alembic:
backend/benefit/applications/tests/test_applications_api.py:test_application_single_read_as_applicant
Screenshots :camera_flash:
Additional notes :spiral_notepad:

Codecov Report

Merging #752 (1581c16) into develop (f8981ab) will increase coverage by 29.71%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##           develop     #752       +/-   ##
============================================
+ Coverage    65.17%   94.88%   +29.71%
============================================
  Files          777      168      -609
  Lines        18186     6984    -11202
  Branches      1002        0     -1002
============================================
- Hits         11852     6627     -5225
+ Misses        5397      357     -5040
+ Partials       937        0      -937

Impacted Files
Coverage Δ

backend/benefit/applications/api/v1/serializers.py
94.03% <ø> (ø)

...enefit/applications/tests/test_applications_api.py
99.20% <100.00%> (+<0.01%)
:arrow_up:

backend/benefit/common/utils.py
90.29% <100.00%> (+0.39%)
:arrow_up:

backend/shared/shared/audit_log/viewsets.py
46.96% <0.00%> (-43.94%)
:arrow_down:

backend/shared/shared/azure_adfs/views.py
41.17% <0.00%> (-41.18%)
:arrow_down:

backend/shared/shared/audit_log/audit_logging.py
76.59% <0.00%> (-21.28%)
:arrow_down:

backend/shared/shared/common/tests/conftest.py
87.87% <0.00%> (-12.13%)
:arrow_down:

backend/shared/shared/oidc/auth.py
81.48% <0.00%> (-1.86%)
:arrow_down:

...rc/utils/get-activation-link-expiration-seconds.ts

...rontend/shared/src/components/drawer/Drawer.sc.tsx

... and 607 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f8981ab...1581c16. Read the comment docs.

good point, added tests


[SPARK-13194][BUILD] Update release audit tools to use Scala 2.11

Can one of the admins verify this patch?

Jenkins, this is ok to test.

Test build #50752 has started for PR 11077 at commit 72e9df7.

Test build #50752 has finished for PR 11077 at commit 72e9df7.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50752/
Test PASSed.

@lresende thanks for doing this. Please merge the relevant pull requests into a single one.

@lresende why are there 5 JIRAs now... This is definitely not needed. As Reynold says you should have made one PR

@rxin this is now merged into #11092


Sphinx custom theme support sporadically doesn't work

Details

Read the Docs project URL: http://xrt.readthedocs.io/
Build URL (if applicable): https://github.com/kklmn/xrt
Read the Docs username (if applicable): konstantin.klementiev

Expected Result
In my theme template I have default.css_t stylesheet that imports basic.css. I expect my default.css (not a generic one) in the _static directory, with all the imports properly done.
Actual Result
The actual default.css is not mine, it doesn't have style elements I've tuned myself. Ok, I've simply given it another name, now I got it. The import of basic.css has also become wrong (since yesterday, probably): the builder reports on ThemeError, complaining about a missing theme variable that actually does exist and is supported in the "basic" theme::
sphinx.errors.ThemeError: unsupported theme option 'body_min_width' given

Now, instead of importing I've simply copied basic.css into mydefault.css_t. But all these "solutions" are just ugly. Please make the templating mechanism properly work, as it used to. Thanks!

I'm not quite sure why RTD is using 1.6 for your build.
I don't think it is. If instead of importing basic.css into my "mydefault.css_t" I copy-paste it, it still uses body_min_width but now without errors. So it looks like a problem of importing (templating).

In this build, it did.

Yes, I see it now, you're right.

My current best guess is that there was some sort of deployment error and one of the builders didn't deploy correctly. The failures appear to be on build01. Successes are elsewhere.

Ok, I see that this problem with ThemeError was temporary. The issue with not copying default.css is really minor, I will just keep it renamed.
Thanks!

Thanks for pointing to the Sphinx version used in the failed build. Closed


Add make cover command

closes https://github.com/appcelerator/amp/issues/371
added make cover command
to test:
make test (to verify no regression)
make cover (to run tests with coverage)

I didn't actually have a successful outcome running this, but it has to do with tests failing, not the PR itself:
amp (unit-coverage)$ make cover
echo "mode: count" > coverage-all.out
go test -coverprofile=coverage.out -covermode=count github.com/appcelerator/amp/api/rpc/service; tail -n +2 coverage.out >> coverage-all.out;  go test -coverprofile=coverage.out -covermode=count github.com/appcelerator/amp/data/storage/etcd; tail -n +2 coverage.out >> coverage-all.out;  go test -coverprofile=coverage.out -covermode=count github.com/appcelerator/amp/api/rpc/stack; tail -n +2 coverage.out >> coverage-all.out;  go test -coverprofile=coverage.out -covermode=count github.com/appcelerator/amp/data/influx; tail -n +2 coverage.out >> coverage-all.out;  go test -coverprofile=coverage.out -covermode=count github.com/appcelerator/amp/api/rpc/stats; tail -n +2 coverage.out >> coverage-all.out;  go test -coverprofile=coverage.out -covermode=count github.com/appcelerator/amp/api/rpc/topic; tail -n +2 coverage.out >> coverage-all.out;  go test -coverprofile=coverage.out -covermode=count github.com/appcelerator/amp/api/rpc/logs; tail -n +2 coverage.out >> coverage-all.out;
ok      github.com/appcelerator/amp/api/rpc/service     2.105s  coverage: 53.2% of statements
ok      github.com/appcelerator/amp/data/storage/etcd   2.567s  coverage: 72.0% of statements
ok      github.com/appcelerator/amp/api/rpc/stack       13.142s coverage: 53.5% of statements
ok      github.com/appcelerator/amp/data/influx 0.022s  coverage: 52.6% of statements
ok      github.com/appcelerator/amp/api/rpc/stats       1.096s  coverage: 73.8% of statements
ok      github.com/appcelerator/amp/api/rpc/topic       67.157s coverage: 55.6% of statements
2016/11/03 10:53:55 Waiting for swarm to be ready
2016/11/03 10:53:55 connecting to etcd at http://<IP_ADDRESS>:2379
2016/11/03 10:53:55 connecting to etcd at http://<IP_ADDRESS>:2379
2016/11/03 10:53:55 connected to etcd at http://<IP_ADDRESS>:2379
2016/11/03 10:53:55 connecting to elasticsearch at http://<IP_ADDRESS>:9200
2016/11/03 10:53:55 connected to etcd at http://<IP_ADDRESS>:2379
2016/11/03 10:53:55 connecting to elasticsearch at http://<IP_ADDRESS>:9200
2016/11/03 10:53:55 connected to elasticsearch at http://<IP_ADDRESS>:9200
2016/11/03 10:53:55 Connecting to NATS-Streaming at nats://<IP_ADDRESS>:4222
2016/11/03 10:53:55 connected to elasticsearch at http://<IP_ADDRESS>:9200
2016/11/03 10:53:55 Connecting to NATS-Streaming at nats://<IP_ADDRESS>:4222
2016/11/03 10:53:55 Connected to NATS-Streaming at nats://<IP_ADDRESS>:4222
2016/11/03 10:53:55 connecting to InfluxDB at http://<IP_ADDRESS>:8086
2016/11/03 10:53:55 connected to influxDB at http://<IP_ADDRESS>:8086
2016/11/03 10:53:55 connecting to Docker API at unix:///var/run/docker.sock version API: 1.24
2016/11/03 10:53:55 connected to Docker at unix:///var/run/docker.sock
2016/11/03 10:53:55 Connecting to amplifier
2016/11/03 10:53:55 Connected to NATS-Streaming at nats://<IP_ADDRESS>:4222
2016/11/03 10:53:55 connecting to InfluxDB at http://<IP_ADDRESS>:8086
2016/11/03 10:53:55 connected to influxDB at http://<IP_ADDRESS>:8086
2016/11/03 10:53:55 connecting to Docker API at unix:///var/run/docker.sock version API: 1.24
2016/11/03 10:53:55 connected to Docker at unix:///var/run/docker.sock
2016/11/03 10:53:55 amplifier is listening on port 50101
2016/11/03 10:53:56 Connected to amplifier
2016/11/03 10:53:57 log requested: [service:"c8f84c9baa823e7d5938c41537d49917c03372e8e835c023bfd2507e27fc055c" ]
2016/11/03 10:53:58 log requested: [service:"c8f84c9baa823e7d5938c41537d49917c03372e8e835c023bfd2507e27fc055c" ]
2016/11/03 10:53:59 log requested: [service:"c8f84c9baa823e7d5938c41537d49917c03372e8e835c023bfd2507e27fc055c" ]
2016/11/03 10:54:00 log requested: [service:"c8f84c9baa823e7d5938c41537d49917c03372e8e835c023bfd2507e27fc055c" ]
2016/11/03 10:54:01 log requested: [service:"c8f84c9baa823e7d5938c41537d49917c03372e8e835c023bfd2507e27fc055c" ]
.... hundreds of lines ....
2016/11/03 10:55:20 log requested: [service:"c8f84c9baa823e7d5938c41537d49917c03372e8e835c023bfd2507e27fc055c" ]
2016/11/03 10:55:20 log requested: []
2016/11/03 10:55:20 log requested: []
2016/11/03 10:55:20 log requested: [container:"4b9b6f98c1ff1412da25a7ff8e969b21ef4e4d5ae07fd84133625775ee53f15e" ]
2016/11/03 10:55:20 log requested: []
2016/11/03 10:55:20 log requested: [node:"82b1b21e48bd1a02a4a934a71427a9151cf335d1b1c08734c73e7af82f29675c" ]
2016/11/03 10:55:20 log requested: [service:"c8f84c9baa823e7d5938c41537d49917c03372e8e835c023bfd2507e27fc055c" ]
2016/11/03 10:55:20 log requested: [service:"testServiceName" ]
--- FAIL: TestShouldFilterByService (0.03s)
        Error Trace:    logs_test.go:145
        Error:          Should NOT be empty, but was []
        Messages:       We should have at least one entry

2016/11/03 10:55:20 log requested: [message:"test" ]
2016/11/03 10:55:20 log requested: [stack:"196aeef6ee66f6510d5f3b872ee401090d6e55ff4ce082426911d769c6375d16" ]
2016/11/03 10:55:20 log requested: [stack:"testStackName" ]
--- FAIL: TestShouldFilterByStack (0.03s)
        Error Trace:    logs_test.go:176
        Error:          Should NOT be empty, but was []
        Messages:       We should have at least one entry

2016/11/03 10:55:20 log requested: [size:1 ]
2016/11/03 10:55:20 log requested: [size:11 ]
2016/11/03 10:55:20 log requested: [size:21 ]
2016/11/03 10:55:20 log requested: [size:31 ]
2016/11/03 10:55:20 log requested: [size:41 ]
2016/11/03 10:55:20 log requested: [size:51 ]
2016/11/03 10:55:20 log requested: [size:61 ]
2016/11/03 10:55:20 log requested: [size:71 ]
2016/11/03 10:55:20 log requested: [size:81 ]
2016/11/03 10:55:20 log requested: [size:91 ]
2016/11/03 10:55:20 log stream requested: []
2016/11/03 10:55:20 log stream requested: [container:"4b9b6f98c1ff1412da25a7ff8e969b21ef4e4d5ae07fd84133625775ee53f15e" ]
2016/11/03 10:55:21 log stream requested: [node:"82b1b21e48bd1a02a4a934a71427a9151cf335d1b1c08734c73e7af82f29675c" ]
2016/11/03 10:55:21 log stream requested: [service:"testService" ]
2016/11/03 10:55:21 log stream requested: [message:"test message " ]
2016/11/03 10:55:21 log stream requested: [message:"TEST MESSAGE " ]
2016/11/03 10:55:21 log stream requested: [stack:"testStack" ]
FAIL
coverage: 78.2% of statements
FAIL    github.com/appcelerator/amp/api/rpc/logs        86.272s
go tool cover -html=coverage-all.out

It would be good if we could filter out autogenerated files (ie, *.pb.go), but in any case the make cover command works well. 👍


Make structures mutable

I am looking for a PromQL parser in Python, and this project looks like the only reasonable option. However, I would like to be able to manipulate the AST, e.g., to rewrite parts of a query. It looks like all objects are immutable.
For example, I would need to work with matchers, and be able to modify matchers (the list is currently immutable) and create new instances of that class.

+1 to this. I'm looking to munge labels. Any updates or tips appreciated


feat: add error types for better validation

Description:
This PR improves error handling by adding specific error types and ensuring compatibility with errors.Is for better validation. The changes include:

Introduced custom error types:

ErrInvalidUUIDFormat
ErrInvalidURNPrefix
ErrInvalidBracketedFormat
ErrInvalidLength

Refactored error handling to use the new error types.
Updated the Parse, ParseBytes, and Validate functions to wrap errors with additional context using fmt.Errorf and %w.
Ensured backward compatibility by maintaining the IsInvalidLengthError function.

@bormanp I really appreciate your review and valid suggestions. I've removed some changes that were added unintentionally by my code formatter in my code editor. Additionally I've sightly modified the approach with ErrInvalidLength and ErrInvalidURNPrefix error types to keep more backward compatibility.


Add destination chain to confirmed packet metrics

Closes: #3297
Description

PR author checklist:

[x] Added changelog entry, using unclog.
[ ] ~Added tests: integration (for Hermes) or unit/mock tests (for modules).~
[x] Linked to GitHub issue.
[x] Updated code comments and documentation (e.g., docs/).
[x] Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

[ ] Reviewed Files changed in the GitHub PR explorer.
[ ] Manually tested (in case integration/unit/mock tests are absent).

I'll check this and update if possible

Do we have easy access to the dst channel and port ids? If so let's add them to the labels as well

I was able to add them in this commit https://github.com/informalsystems/hermes/pull/3302/commits/3b3213e78c6f4b2412e45744e3343608f8557467. What do you think about this ?


Frontend to query the encrypted data

I just installed today on multiple servers and already liking it. I am using existing Postgresql as the backend and wondering if there can be a frontend like a simple UI where we can search the history.

Thanks for the issue! Can you explain more in terms of what type of frontend you're envisioning here? Are you picturing a web frontend? Generally, I see the hishtory CLI as the frontend for the encrypted data, though I can see the potential utility of supporting some sort of web frontend for viewing/querying your history.

I'm closing this out since there's no reply, but if you do see this, please re-open this so I can take another look!

Yes a web frontend with simple search would work, may be in the future can support APIs as well.


[prim_xilinx] Update pad wrapper and delete unused ram_2p

This introduces the following changes:

prim_xilinx_ram_2p is removed since the implementation always used the generic implementation (which is inferrable). Hence this prim is redundant.
an IOBUF cell is instantiated in the prim_xilinx_pad_wrapper in preparation for #2114.

Signed-off-by: Michael Schaffner<EMAIL_ADDRESS>

I have tested the FPGA build with the hello world example, and that works.

Thanks @msfschaffner. The change LGTM overall.
In a perfect world, this would be two commits, since the changes aren't related at all.
Did the IOBUF not get inferred before, or do you only want to be explicit? It would be great if you can add this piece of information to the commit message.

yeah, the pad_wrapper has not been instantiated until now, and I wanted to be more explicit to make sure this gets correctly placed. sure, I  I'll update the commits.


Ord wallet balance

I am doing the following:
Running bitcoind with commands -txindex -prune=0
I run ord and restore my wallet with 12 secret phrases.
i run this command on ord:
ord wallet receive and it gives me my address.
Everything is going good until I enter the command:
ord wallet balance.
Today I'm running the 0.5.0 version, which gives me a  _ as my result and stays frozen on that.
Yesterday i was running the 0.4.2 version and it would give me a response of 0 balance. Even though I had funds verified through mempool by copying the first address it would give me.
Both versions 0.4.2 and 0.5.0 gave me the same initial address after restoring my wallet each time.

You may be running into this bug https://github.com/casey/ord/issues/1589
You need to manually trigger a rescan of the wallet to pickup all the historical transactions
Someone wrote this guide which has some details
https://gist.github.com/windsok/5b53a1ced6ef3eddbde260337de28980#importing-into-ord-wallet


Formatting XAML

Removed trailing spaces.
Moved attributes onto their own line.

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@skalpin : Thanks for your contribution to the Azure documentation! The author, @v-royhar, has been notified to review your proposed change.

@skalpin : Thanks for your contribution to the Azure documentation! The author, @v-royhar, has been notified to review your proposed change.

The xaml was updated


Vimeo Thumbnail in Schema Preview / Prepare

Hi there,
Thank you for making this simple to install and easy to use plugin!
I'm able to add the Vimeo Title / Name to my schema preview like so:
preview: {
    select: {
      title: 'vimeo'
    },
    prepare: ({ title }) => {
      return {
        title: title.name
      }
    }
  }

I'm newer to Sanity, can't understand the preview / prepare for the media...
Is there any way to pass the Vimeo Thumbnail into the preview / prepare media to go with the title name?

Hi,
the store puts a bunch of data from vimeo to your document, you can inspect the data with the sanity inspector, see below.
.
Thumbnails are stored in vimeo.pictures. Since the thumbnails are just external image urls, you need to wrap them around an img tag (this would not be necessary for sanity assets). Here's a working example:
preview: {
  select: {
    title: 'vimeo.name',
    picture: 'vimeo.pictures.sizes.[1].link',
  },
  prepare(selection) {
    const {title, picture} = selection
    return {
      title: title,
      media: <img src={picture} alt={title} />,
    }
  },
},

Please make sure to change your document to a jsx / tsx (and import react).
Preview should like this:

You can read more about this in the sanity docs
I hope this helps!

Sweet!! Thank you so much for this quick reply and perfect little demo. I saw the pictures data and all coming through, just wasn't clear about the react import and needing to turn my .js file into .jsx for the img tag.
Thanks again, this is great!

That thumbnail preview totally works now, thanks again!
Last question, hah, is there any way to hide the "Files" and "Play" fields, like with hidden: true? Since those are readonly, I was just thinking of not showing them so the client had less fields to look at, haha. No big deal if this isn't possible.

Glad it works for you!

Last question, hah, is there any way to hide the "Files" and "Play" fields, like with hidden: true? Since those are readonly, I was just thinking of not showing them so the client had less fields to look at. No big deal if this isn't possible.

At the moment this is not an option, but I might remove that in the next release and just display title + thumbnail.

Sounds good, thanks again!