Bug Report: New songs in Freeplay crash the game

Please check for duplicates, similar issues or closed issues with the same problem, as well performing simple troubleshooting steps (such as deleting the export folder if it's an issue with compiling, reinstalling Kade Engine) before submitting an issue.
If you are playing a downloaded version of the game, what operating system are you using?
Windows (x86), Windows (x86_64), Linux, or macOS? Specify below.
Windows x86_64
What version of the game are you using? Look in the bottom left corner of the main menu.
1.6 Kade Engine, Github releases version
Have you identified any steps to reproduce the bug? If so, please describe them below. Use images if possible.

Add a new song to the assets/songs folder, and the assets/data folder. Make sure the json's song value is the same as the folder names.
Add that song into the freeplaySonglist.txt file, then go into Freeplay and try to hover over the song.

Please describe your issue. Provide extensive detail and images if possible.
The game immediately crashes on hovering over the song, and the console log ends at this:
source/MainMenuState.hx:258: Freeplay Menu Selected source/Song.hx:87: loading tutorial/tutorial-easy source/Song.hx:87: loading tutorial/tutorial source/Song.hx:87: loading tutorial/tutorial-hard source/FreeplayState.hx:92: loaded diffs for Tutorial source/Song.hx:87: loading brine/brine-easy source/Song.hx:87: loading brine/brine source/Song.hx:87: loading brine/brine-hard source/FreeplayState.hx:92: loaded diffs for Brine source/Song.hx:87: loading spookeez/spookeez-easy source/Song.hx:87: loading spookeez/spookeez source/Song.hx:87: loading spookeez/spookeez-hard source/FreeplayState.hx:92: loaded diffs for Spookeez source/Song.hx:87: loading south/south-easy source/Song.hx:87: loading south/south source/Song.hx:87: loading south/south-hard source/FreeplayState.hx:92: loaded diffs for South source/Song.hx:87: loading fortune/fortune-easy source/Song.hx:87: loading fortune/fortune source/Song.hx:87: loading fortune/fortune-hard source/FreeplayState.hx:92: loaded diffs for Fortune source/Song.hx:87: loading pico/pico-easy source/Song.hx:87: loading pico/pico source/Song.hx:87: loading pico/pico-hard source/FreeplayState.hx:92: loaded diffs for Pico source/Song.hx:87: loading philly/philly-easy source/Song.hx:87: loading philly/philly source/Song.hx:87: loading philly/philly-hard source/FreeplayState.hx:92: loaded diffs for Philly Nice source/Song.hx:87: loading blammed/blammed-easy source/Song.hx:87: loading blammed/blammed source/Song.hx:87: loading blammed/blammed-hard source/FreeplayState.hx:92: loaded diffs for Blammed source/Song.hx:87: loading satin-panties/satin-panties-easy source/Song.hx:87: loading satin-panties/satin-panties source/Song.hx:87: loading satin-panties/satin-panties-hard source/FreeplayState.hx:92: loaded diffs for Satin Panties source/Song.hx:87: loading high/high-easy source/Song.hx:87: loading high/high source/Song.hx:87: loading high/high-hard source/FreeplayState.hx:92: loaded diffs for High source/Song.hx:87: loading milf/milf-easy source/Song.hx:87: loading milf/milf source/Song.hx:87: loading milf/milf-hard source/FreeplayState.hx:92: loaded diffs for Milf source/Song.hx:87: loading cocoa/cocoa-easy source/Song.hx:87: loading cocoa/cocoa source/Song.hx:87: loading cocoa/cocoa-hard source/FreeplayState.hx:92: loaded diffs for Cocoa source/Song.hx:87: loading eggnog/eggnog-easy source/Song.hx:87: loading eggnog/eggnog source/Song.hx:87: loading eggnog/eggnog-hard source/FreeplayState.hx:92: loaded diffs for Eggnog source/Song.hx:87: loading winter-horrorland/winter-horrorland-easy source/Song.hx:87: loading winter-horrorland/winter-horrorland source/Song.hx:87: loading winter-horrorland/winter-horrorland-hard source/FreeplayState.hx:92: loaded diffs for Winter Horrorland source/FreeplayState.hx:96: tryin to load sm files source/FreeplayState.hx:101: HOW TO ADD SM FILES.txt source/DiffCalc.hx:26: calcuilafjwaf source/DiffCalc.hx:48: 32 - playable notes source/DiffCalc.hx:26: calcuilafjwaf source/DiffCalc.hx:48: 32 - playable notes source/MusicBeatState.hx:31: reg (x: -200 | y: -200 | w: 1792 | h: 1008) source/DiffCalc.hx:26: calcuilafjwaf source/DiffCalc.hx:48: 176 - playable notes source/DiffCalc.hx:26: calcuilafjwaf source/DiffCalc.hx:48: 32 - playable notes source/DiffCalc.hx:26: calcuilafjwaf
If i need to clarify any more, let me know.

if its the precompiled version then its normal
if you are compiling it make sure the json file has the correct names for player1, player2, gfVersion and stage

this should have been fixed

im referring to precompiled and It Was Not, console when running from master source in debug mode says it can't find the assets under assets/songs/songname/Inst.ogg and assets/songs/songname/Voices.ogg

im referring to precompiled and It Was Not, console when running from master source in debug mode says it can't find the assets under assets/songs/songname/Inst.ogg and assets/songs/songname/Voices.ogg

i've been looking at the files and apparently the way the game looks for the correct files existing is having them inside a manifest-json file
if the file is not inside the manifest it gets ignored
and you can't add files to the manifest easily


upgrade() seems to not work as expected

Hi,
It's about custom built-in elements support in Safari.
I think the upgrade() in this polyfill is not working as expected, while your other specific polyfill ( https://github.com/ungap/custom-elements-builtin ) works correctly (by this I mean it gives the same result as browsers with native support).
I would be more than happy just using the other polyfill since I have to support only modern browsers and Safari is the only one not compliant with the standard, but that one is deprecated.
here is the code to reproduce the issue (I don't have a mac, so I'm testing everything through Browserstack)
class TestImg extends HTMLImageElement {}

const element = document.createElement('img', {is: 'test-img'});
console.log('before define', element instanceof TestImg); // false, as expected

customElements.define('test-img', TestImg, {extends: 'img'});
console.log('after define', element instanceof TestImg); // false, as expected

customElements.upgrade(element);
console.log('after ugprade', element instanceof TestImg);
// true on browsers with native support and using @ungap/custom-elements-builtin,
// but false when using @ungap/custom-elements

Cheers

Safari is the only one not compliant with the standard, but that one is deprecated.

nothing is deprecated. It's specs and stays in specs not deprecated.

// true on browsers with native support and using @ungap/custom-elements-builtin,
// but false when using @ungap/custom-elements

this is funny because this polyfill uses @ungap/custom-elements-builtin but I'll have a look.
Also please consider giving vanilla-elements a chance!
// optionally use import-map to differentiate Safari from others
import {define, HTML} from 'vanilla-elements/poly';

class TestImg extends HTML.Image {}
define('test-img', TestImg); // no need to use {extends}

This tiny helper uses @ungap/custom-elements-builtin only and it fixes a long standing bug with attributes in construction

nothing is deprecated. It's specs and stays in specs not deprecated.

Sorry, I meant your other polyfill is declared as deprecated, not the spec.

this is funny because this polyfill uses @ungap/custom-elements-builtin but I'll have a look.

Thanks a lot!

Also please consider giving vanilla-elements a chance!
Looks nice, I'll check it.

I see ... my misunderstanding then, as I've mentioned this one, not the old one. Then vanilla-elements won't fix it neither, I need to check @webreflection/custom-elements-builtin module instead. Will try when possible!

I tried now that one ( @webreflection/custom-elements-builtin ) and that is even more strange, since it is printing false also on Chrome (where it should not do anything, I would expect).
Anyway, thanks again for checking it, I will use @ungap/custom-elements-builtin in the meanwhile, no hurry.

Turns out ... there was no upgrade for builtin extends, as I've never needed that use case and completely forgot about it.
Now there is upgrade and tests are fine too and work as expected like native implementations.

Great, thanks again!


Wrong typings for 'observer' and 'inject'

Observed:
compiling next component
import * as React from 'react'
import { Component, PropTypes } from 'react'
import { observer, inject } from 'mobx-react'
import MyStore from './myStore'

@inject((allStores) => ({
    store: new MyStore(),
}))
@observer
class LoginContainer extends Component<any, void> {
    static contextTypes = {
        router: PropTypes.func.isRequired,
    }
    render() {
        return (
Hello!
)
    }
}
export default LoginContainer

gives an error:
error TS2345: Argument of type 'typeof MyComponent' is not assignable to parameter of type 'string[]'.  Property 'push' is missing in type 'typeof MyComponent'.

So, it means that none of the provided 'observer' functions signatures match a component type.
New signatures for functions observer and inject should be added. Not sure which exactly.
For now I added a quick fix:
export function observer
(clazz: any): any;
export function inject
(storesToProps: any): any

How to reproduce
This problem occurs when a static field contextTypes is added to the component class together with 'observer'

@mkozhukharenko I was able to reproduce this one, but actually TypeScript gave me a compile error on contextTypes itself first. It seems that the type of contextTypes is not inferred correctly by TypeScript, which can fixed by declaring context types as:
@inject((allStores) => ({
    store: {},
}))
@observer
class LoginContainer extends Component<any, void> {
    static contextTypes: React.ValidationMap<any> = {
        router: PropTypes.func.isRequired,
    }

    render() {
        return (
Hello!
)
    }
}

That being said, in your example propTypes should be used, as @inject will take stuff from the context and inject it as props to the component

@mweststrate thanks for the response with detailed explanation.

I landed here with similar errors; My component definition:
@observer
class Container extends React.Component<T, null> {

Seemed to be my declaring state as null (void has same result). This stackoverflow question led me there. Simply omitting the type for state resolved the error:
@observer
class Container extends React.Component<T> {

(Hadn't realized I could omit the State type altogether, maybe that's a later addition to @types/react).

Use {}
On wo 4 okt. 2017 16:19 chris<EMAIL_ADDRESS>wrote:

I landed here with similar errors; My component definition:
@observerclass Container extends React.Component<T, null> {
Seemed to be my declaring state as null (void has same result). This
stackoverflow question
https://stackoverflow.com/questions/45024559/jsx-element-type-app-is-not-a-constructor-function-for-jsx-elements-types-of
led me there. Simply omitting the type for state resolved the error:
@observerclass Container extends React.Component {
(Hadn't realized I could omit the State type altogether, maybe that's a
later addition to ).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-react/issues/129#issuecomment-334170753,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABvGhD3Bhr7fukPNJeDMZkW1kOiccY4pks5so5PlgaJpZM4KLi2l
.

The DefinitelyTyped react typings provide a default {} for state:
// Base component for plain JS classes
// tslint:disable-next-line:no-empty-interface
interface Component
 extends ComponentLifecycle
 { }
class Component
 {
  constructor(props?: P, context?: any);

Is there an impact when leaving it off / explicitly using {}?


Bug Fixed: Node rename dialog no longer pops up inside of the viewport

Could you be more explicit about what the bug is that you're fixing? I'm not familiar with it.

Could you be more explicit about what the bug is that you're fixing? I'm not familiar with it.

Alright, added a description. Is this enough information?

What about Batch renaming dialog ?
https://user-images.githubusercontent.com/13400398/107138169-639fa980-6945-11eb-9afe-6753ab01e572.mp4


Fetch only necessary commits for build

In https://github.com/docker-library/official-images/pull/15846 @LaurentGoderre asked me to move the Dockerfiles into an orphan branch because bashbrew spends a huge time to fetch the git references.
Here's the simplest change improves the fetch by an order of magnitude:
> time (rm -rf ~/.cache/bashbrew && ~/Space/go/bin/bashbrew --debug build library/clickhouse)
Using bashbrew/cache:e3168289a003ed8aa644f472b1d6a4521683d5c1a6a12765f9a0329d375dd4d1 (clickhouse:latest)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "clickhouse:latest" "--tag" "clickhouse:focal" "--tag" "clickhouse:24" "--tag" "clickhouse:24-focal" "--tag" "clickhouse:24.4" "--tag" "clickhouse:24.4-focal" "--tag" "clickhouse:24.4.1" "--tag" "clickhouse:24.4.1-focal" "--tag" "clickhouse:<IP_ADDRESS>8" "--tag" "clickhouse:<IP_ADDRESS>8-focal" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:e3168289a003ed8aa644f472b1d6a4521683d5c1a6a12765f9a0329d375dd4d1
 ---> e6a434d83fd8
Successfully built e6a434d83fd8
Successfully tagged clickhouse:latest
Successfully tagged clickhouse:focal
Successfully tagged clickhouse:24
Successfully tagged clickhouse:24-focal
Successfully tagged clickhouse:24.4
Successfully tagged clickhouse:24.4-focal
Successfully tagged clickhouse:24.4.1
Successfully tagged clickhouse:24.4.1-focal
Successfully tagged clickhouse:<IP_ADDRESS>8
Successfully tagged clickhouse:<IP_ADDRESS>8-focal
( rm -rf ~/.cache/bashbrew && ~/Space/go/bin/bashbrew --debug build ; )
 4,64s user 0,78s system 34% cpu 15,659 total

> time (rm -rf ~/.cache/bashbrew && bashbrew --debug build library/clickhouse)
Using bashbrew/cache:e3168289a003ed8aa644f472b1d6a4521683d5c1a6a12765f9a0329d375dd4d1 (clickhouse:latest)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "clickhouse:latest" "--tag" "clickhouse:focal" "--tag" "clickhouse:24" "--tag" "clickhouse:24-focal" "--tag" "clickhouse:24.4" "--tag" "clickhouse:24.4-focal" "--tag" "clickhouse:24.4.1" "--tag" "clickhouse:24.4.1-focal" "--tag" "clickhouse:<IP_ADDRESS>8" "--tag" "clickhouse:<IP_ADDRESS>8-focal" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:e3168289a003ed8aa644f472b1d6a4521683d5c1a6a12765f9a0329d375dd4d1
 ---> e6a434d83fd8
Successfully built e6a434d83fd8
Successfully tagged clickhouse:latest
Successfully tagged clickhouse:focal
Successfully tagged clickhouse:24
Successfully tagged clickhouse:24-focal
Successfully tagged clickhouse:24.4
Successfully tagged clickhouse:24.4-focal
Successfully tagged clickhouse:24.4.1
Successfully tagged clickhouse:24.4.1-focal
Successfully tagged clickhouse:<IP_ADDRESS>8
Successfully tagged clickhouse:<IP_ADDRESS>8-focal
( rm -rf ~/.cache/bashbrew && bashbrew --debug build library/clickhouse; )
 255,70s user 15,34s system 113% cpu 3:59,07 total

$ bashbrew --version
bashbrew version v0.1.13
$ ~/Space/go/bin/bashbrew --version
bashbrew version v0.1.13

Here's another test to see if it works with different refs
> time (rm -rf ~/.cache/bashbrew && ~/Space/go/bin/bashbrew --debug build library/alpine)
Using bashbrew/cache:a549aabbc73b701e3dff468635173f5a31fb8df23d45674d810037f188e4a74b (alpine:20230901)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:20230901" "--tag" "alpine:edge" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:a549aabbc73b701e3dff468635173f5a31fb8df23d45674d810037f188e4a74b
 ---> 8b96eaa5d551
Successfully built 8b96eaa5d551
Successfully tagged alpine:20230901
Successfully tagged alpine:edge
Using bashbrew/cache:54d04be340227935d149a64d37b5ada2234fac0cba400486f71e1af87fdf0bbd (alpine:3.18.5)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:3.18.5" "--tag" "alpine:3.18" "--tag" "alpine:3" "--tag" "alpine:latest" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:54d04be340227935d149a64d37b5ada2234fac0cba400486f71e1af87fdf0bbd
 ---> 0a39b18eeb74
Successfully built 0a39b18eeb74
Successfully tagged alpine:3.18.5
Successfully tagged alpine:3.18
Successfully tagged alpine:3
Successfully tagged alpine:latest
Using bashbrew/cache:bd8ebcaf28443dbdc6a23325432bc0fc7cda6cb0f11bc4c9e06ad35ab16c1d9e (alpine:3.17.6)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:3.17.6" "--tag" "alpine:3.17" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:bd8ebcaf28443dbdc6a23325432bc0fc7cda6cb0f11bc4c9e06ad35ab16c1d9e
 ---> 710cfc90b7ca
Successfully built 710cfc90b7ca
Successfully tagged alpine:3.17.6
Successfully tagged alpine:3.17
Using bashbrew/cache:799ae2e8a34101169cc25094ff566e0841a31c9ed7149348f6c8710324d8a72a (alpine:3.16.8)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:3.16.8" "--tag" "alpine:3.16" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:799ae2e8a34101169cc25094ff566e0841a31c9ed7149348f6c8710324d8a72a
 ---> 0f11e7a385b4
Successfully built 0f11e7a385b4
Successfully tagged alpine:3.16.8
Successfully tagged alpine:3.16
Using bashbrew/cache:f96d9751c747839ab074ce20fa5e24f69aba0e03402db471c4e74b34bbea41aa (alpine:3.15.11)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:3.15.11" "--tag" "alpine:3.15" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:f96d9751c747839ab074ce20fa5e24f69aba0e03402db471c4e74b34bbea41aa
 ---> 7620a8176e11
Successfully built 7620a8176e11
Successfully tagged alpine:3.15.11
Successfully tagged alpine:3.15
( rm -rf ~/.cache/bashbrew && ~/Space/go/bin/bashbrew --debug build ; )  1,88s user 0,74s system 24% cpu 10,485 total
> time (rm -rf ~/.cache/bashbrew && bashbrew --debug build library/alpine)
Using bashbrew/cache:a549aabbc73b701e3dff468635173f5a31fb8df23d45674d810037f188e4a74b (alpine:20230901)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:20230901" "--tag" "alpine:edge" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:a549aabbc73b701e3dff468635173f5a31fb8df23d45674d810037f188e4a74b
 ---> 8b96eaa5d551
Successfully built 8b96eaa5d551
Successfully tagged alpine:20230901
Successfully tagged alpine:edge
Using bashbrew/cache:54d04be340227935d149a64d37b5ada2234fac0cba400486f71e1af87fdf0bbd (alpine:3.18.5)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:3.18.5" "--tag" "alpine:3.18" "--tag" "alpine:3" "--tag" "alpine:latest" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:54d04be340227935d149a64d37b5ada2234fac0cba400486f71e1af87fdf0bbd
 ---> 0a39b18eeb74
Successfully built 0a39b18eeb74
Successfully tagged alpine:3.18.5
Successfully tagged alpine:3.18
Successfully tagged alpine:3
Successfully tagged alpine:latest
Using bashbrew/cache:bd8ebcaf28443dbdc6a23325432bc0fc7cda6cb0f11bc4c9e06ad35ab16c1d9e (alpine:3.17.6)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:3.17.6" "--tag" "alpine:3.17" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:bd8ebcaf28443dbdc6a23325432bc0fc7cda6cb0f11bc4c9e06ad35ab16c1d9e
 ---> 710cfc90b7ca
Successfully built 710cfc90b7ca
Successfully tagged alpine:3.17.6
Successfully tagged alpine:3.17
Using bashbrew/cache:799ae2e8a34101169cc25094ff566e0841a31c9ed7149348f6c8710324d8a72a (alpine:3.16.8)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:3.16.8" "--tag" "alpine:3.16" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:799ae2e8a34101169cc25094ff566e0841a31c9ed7149348f6c8710324d8a72a
 ---> 0f11e7a385b4
Successfully built 0f11e7a385b4
Successfully tagged alpine:3.16.8
Successfully tagged alpine:3.16
Using bashbrew/cache:f96d9751c747839ab074ce20fa5e24f69aba0e03402db471c4e74b34bbea41aa (alpine:3.15.11)
$ export DOCKER_BUILDKIT=0
$ docker ["build" "--tag" "alpine:3.15.11" "--tag" "alpine:3.15" "--rm" "--force-rm" "-"]
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM bashbrew/cache:f96d9751c747839ab074ce20fa5e24f69aba0e03402db471c4e74b34bbea41aa
 ---> 7620a8176e11
Successfully built 7620a8176e11
Successfully tagged alpine:3.15.11
Successfully tagged alpine:3.15
( rm -rf ~/.cache/bashbrew && bashbrew --debug build library/alpine; )  1,93s user 0,76s system 24% cpu 11,047 total

Here's an example of building an alpine image from different commits:

$ rm ~/.cache/bashbrew/ -rf
$ git checkout  master >/dev/null
Already on 'master'
$ time ~/Space/go/bin/bashbrew build library/alpine
Building bashbrew/cache:a549aabbc73b701e3dff468635173f5a31fb8df23d45674d810037f188e4a74b (alpine:20230901)
Building bashbrew/cache:54d04be340227935d149a64d37b5ada2234fac0cba400486f71e1af87fdf0bbd (alpine:3.18.5)
Building bashbrew/cache:bd8ebcaf28443dbdc6a23325432bc0fc7cda6cb0f11bc4c9e06ad35ab16c1d9e (alpine:3.17.6)
Building bashbrew/cache:799ae2e8a34101169cc25094ff566e0841a31c9ed7149348f6c8710324d8a72a (alpine:3.16.8)
Building bashbrew/cache:f96d9751c747839ab074ce20fa5e24f69aba0e03402db471c4e74b34bbea41aa (alpine:3.15.11)

real    0m16,301s
user    0m3,681s
sys     0m1,260s
$ git checkout $(git log -1 --format=%H library/alpine)~
Note: switching to '7e13453ce3b47c537e4ffe79127d4900825e9d03~'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at ca1ff8a21 Merge pull request #15797 from docker-library-bot/external-pins-tianon
$ time ~/Space/go/bin/bashbrew build library/alpine
Using bashbrew/cache:a549aabbc73b701e3dff468635173f5a31fb8df23d45674d810037f188e4a74b (alpine:20230901)
Building bashbrew/cache:9eb60d921d482965f048fe6217d50bb1a54c90efde85f6944716525287864f64 (alpine:3.18.4)
Building bashbrew/cache:43f876d1c162b59663bbefd823db152fe59d3960b863880c73a8ffd716af57c7 (alpine:3.17.5)
Building bashbrew/cache:9c9ead487f115deb249c82247e1373f3bab1aa5f31efe01ae44499d35c4d4bbe (alpine:3.16.7)
Building bashbrew/cache:a57aaa93382aa13b957f42b41cc78fb61f0496df2f52ac64759c1c20463f570e (alpine:3.15.10)

real    0m12,929s
user    0m2,813s
sys     0m1,027s
$ git checkout $(git log -1 --format=%H library/alpine)~
Previous HEAD position was ca1ff8a21 Merge pull request #15797 from docker-library-bot/external-pins-tianon
HEAD is now at ff00e9909 Merge pull request #15439 from docker-library-bot/wordpress
$ time ~/Space/go/bin/bashbrew build library/alpine
Using bashbrew/cache:a549aabbc73b701e3dff468635173f5a31fb8df23d45674d810037f188e4a74b (alpine:20230901)
Building bashbrew/cache:85083aa00523429a3d2708776410b89bb2ef26d79ed43b8a617b69d0a6a5592e (alpine:3.18.3)
Using bashbrew/cache:43f876d1c162b59663bbefd823db152fe59d3960b863880c73a8ffd716af57c7 (alpine:3.17.5)
Using bashbrew/cache:9c9ead487f115deb249c82247e1373f3bab1aa5f31efe01ae44499d35c4d4bbe (alpine:3.16.7)
Using bashbrew/cache:a57aaa93382aa13b957f42b41cc78fb61f0496df2f52ac64759c1c20463f570e (alpine:3.15.10)

real    0m4,049s
user    0m0,980s
sys     0m0,430s
$ git checkout $(git log -1 --format=%H library/alpine)~
Previous HEAD position was ff00e9909 Merge pull request #15439 from docker-library-bot/wordpress
HEAD is now at 6507e98e7 Merge pull request #15294 from docker-library-bot/openjdk
$ time ~/Space/go/bin/bashbrew build library/alpine
Building bashbrew/cache:2860aed394846a7f5b47777edd6f10f0c8433a8db6969fecc1038cada367f14e (alpine:20230329)
Using bashbrew/cache:85083aa00523429a3d2708776410b89bb2ef26d79ed43b8a617b69d0a6a5592e (alpine:3.18.3)
Using bashbrew/cache:43f876d1c162b59663bbefd823db152fe59d3960b863880c73a8ffd716af57c7 (alpine:3.17.5)
Using bashbrew/cache:9c9ead487f115deb249c82247e1373f3bab1aa5f31efe01ae44499d35c4d4bbe (alpine:3.16.7)
Using bashbrew/cache:a57aaa93382aa13b957f42b41cc78fb61f0496df2f52ac64759c1c20463f570e (alpine:3.15.10)

real    0m4,503s
user    0m1,027s
sys     0m0,545s
$ git checkout $(git log -1 --format=%H library/alpine)~
Previous HEAD position was 6507e98e7 Merge pull request #15294 from docker-library-bot/openjdk
HEAD is now at 5433844f5 Merge pull request #15150 from docker-library-bot/ghost
$ time ~/Space/go/bin/bashbrew build library/alpine
Using bashbrew/cache:2860aed394846a7f5b47777edd6f10f0c8433a8db6969fecc1038cada367f14e (alpine:20230329)
Building bashbrew/cache:c888cad40c964c0f6de9d7493ebdd83bff0ea773ad37e297a7e427893149ffd6 (alpine:3.18.2)
Building bashbrew/cache:f439ee9f147e9e793107ac3db503360ea5115ed542347aa011cf81fee04359c3 (alpine:3.17.4)
Building bashbrew/cache:785b7c78d4aa1a8595ebda7e50bd5105e3930032cf20fab7a4e450b02d3038d3 (alpine:3.16.6)
Building bashbrew/cache:6e6a5e0713a61f93b9f306af55fb688f795a1d168c1d6b1f620c9d64c02bfad9 (alpine:3.15.9)

real    0m12,934s
user    0m2,802s
sys     0m1,096s
$ git checkout $(git log -1 --format=%H library/alpine)~
Previous HEAD position was 5433844f5 Merge pull request #15150 from docker-library-bot/ghost
HEAD is now at 19f4f9c2d Merge pull request #14848 from amsteinb-orcl/update-oraclelinux
$ time ~/Space/go/bin/bashbrew build library/alpine
Using bashbrew/cache:2860aed394846a7f5b47777edd6f10f0c8433a8db6969fecc1038cada367f14e (alpine:20230329)
Building bashbrew/cache:73cf7ede3ed18aca96e7120a03dd7bb6c512d792dd928a1f9c72fbcab4786870 (alpine:3.18.0)
Building bashbrew/cache:addd6e6541e0f2bb34ae37a3ea1374e1f6db88808f7419a4dd7e6eaff906dcae (alpine:3.17.3)
Building bashbrew/cache:f6cbf1d672caaec6d46e037f93d7a79079ded11fb0fb0e7ab3897ef3adb95af2 (alpine:3.16.5)
Building bashbrew/cache:05fd9c1efca3611374c2e78bc4044648a0c9aad75be5a3892b88fe60de18e7f9 (alpine:3.15.8)

real    0m14,306s
user    0m2,878s
sys     0m1,100s
$ git checkout master
Previous HEAD position was 19f4f9c2d Merge pull request #14848 from amsteinb-orcl/update-oraclelinux
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
$ time ~/Space/go/bin/bashbrew build library/alpine
Using bashbrew/cache:a549aabbc73b701e3dff468635173f5a31fb8df23d45674d810037f188e4a74b (alpine:20230901)
Using bashbrew/cache:54d04be340227935d149a64d37b5ada2234fac0cba400486f71e1af87fdf0bbd (alpine:3.18.5)
Using bashbrew/cache:bd8ebcaf28443dbdc6a23325432bc0fc7cda6cb0f11bc4c9e06ad35ab16c1d9e (alpine:3.17.6)
Using bashbrew/cache:799ae2e8a34101169cc25094ff566e0841a31c9ed7149348f6c8710324d8a72a (alpine:3.16.8)
Using bashbrew/cache:f96d9751c747839ab074ce20fa5e24f69aba0e03402db471c4e74b34bbea41aa (alpine:3.15.11)

real    0m0,462s
user    0m0,181s
sys     0m0,182s
$ du -hscx ~/.cache/bashbrew/
373M    /home/felixoid/.cache/bashbrew/
373M    total

Compare the workflow running against master vs running against PR

Unfortunately, this would need to be more complicated -- effectively, if we're pulling from a Git platform which does not support direct fetch-by-commit, we rely on GitFetch to point us to a tree which contains GitCommit, and only fetching the top commit in those cases would not necessarily successfully fetch the commit.
Also, in our newer build system, we pass these Git URLs directly to docker buildx build (not using bashbrew build at all) and BuildKit becomes responsible for the git clone (so it can record accurate provenance data directly in the provenance objects it generates), and it doesn't currently even do direct fetch-by-commit (it fetches all refs hoping one of them contains the requested commit) :sob:

Oh my.. how would this build kit approach work with repositories as big as ClickHouse/ClickHouse or even bigger?
It's it just a blocker to use such big repos?
Aside from that, can you give an example of what should still work? Like, some library manifest to test?

Ok, I am pretty sure it's a bug in the go-git addressed somewhere between 5.5 and 5.12. Just updating this module fixes everything.

Here are the test results for the binary built from the latest state. The go-git is updated:
$ time ( : > /tmp/bashbrew.log; rm -rf ~/.cache/bashbrew; for lib in $(git grep -l GitFetch library/); do  ~/Space/go/bin/bashbrew --debug build --dry-run  "$lib" || echo "Failed '$lib'" >> /tmp/bashbrew.log ; [ -f /tmp/test-stop ] && break || :; done ; ) &> /tmp/bashbrew-first-run.log
( : > /tmp/bashbrew.log; rm -rf ~/.cache/bashbrew; for lib in ; do;  --debug   71,36s user 36,75s system 23% cpu 7:36,95 total

$ time ( : > /tmp/bashbrew.log; for lib in $(git grep -l GitFetch library/); do  ~/Space/go/bin/bashbrew --debug build --dry-run  "$lib" || echo "Failed '$lib'" >> /tmp/bashbrew.log ; [ -f /tmp/test-stop ] && break || :; done ; ) &> /tmp/bashbrew-second-run.log 2>&1
( : > /tmp/bashbrew.log; for lib in $(git grep -l GitFetch library/); do;      11,96s user 13,90s system 103% cpu 24,953 total

and BuildKit doesn't currently even do direct fetch-by-commit (it fetches all refs hoping one of them contains the requested commit) 😭

I think it should really fetch only the necessary commit. Otherwise, the amount of unnecessary network traffic and compute time is enormous.

To get rid of possible remaining questions, here's the run for all the official library manifests:
> time ( : > /tmp/bashbrew.log; for lib in $(ls library/*); do  ~/Space/go/bin/bashbrew --debug build --dry-run  "$lib" || echo "Failed '$lib'" >> /tmp/bashbrew.log ; [ -f /tmp/test-stop ] && break || :; done ; ) &> /tmp/bashbrew-full-run.log 2>&1
( : > /tmp/bashbrew.log; for lib in $(ls library/*); do;  --debug build   ||   33,57s user 40,60s system 106% cpu 1:09,48 total

> cat /tmp/bashbrew.log

> du -hs ~/.cache/bashbrew
3,8G    /home/felixoid/.cache/bashbrew

With the full output for bashbrew-full-run.log

Kindly hope for the next review round

Hello. Is something blocking it from the merge?


V8 -> V9 Breaking Change: setNativeProps

I recently upgraded from 8.0.11 to 9.4 and found there is a breaking change with how setNativeProps works.
You can no longer use a reference to update a path in 9.4 as the redraw will not occur.  Is there an issue tracking this?
Note, this is still working on 8.0.11
IE

class MyComponent extends Component {
    componentDidMount() {
        setTimeout(() => {
            const myPercent = formatPercentage(0.5);
            this._myPath.setNativeProps({
                d: generateSectionFromPercentage(myPercent, 80)
            });
        }, 2500);
    }
    render() {
        const myPercent = formatPercentage(0.1);
        const pathString = generateSectionFromPercentage(myPercent, 80);

        return (
            <Svg width={160} height={160} viewBox="0 0 80 80">
                <Defs>
                    <ClipPath id="successfulClippingPath">
                        <Path
                            ref={ref => {
                                this._myPath = ref;
                            }}
                            d={pathString}
                            fill={"#FFF"}
                        />
                    </ClipPath>
                </Defs>
                <Use
                    fillRule="evenodd"
                    fill={"none"}
                    href={"#hexagon"}
                    clipPath="url(#successfulClippingPath)"
                    stroke={"#06E6FA"}
                    strokeWidth="7"
                />
            </Svg>
        );
    }
}

At least this seems to work correctly in the latest version. So seems this has been fixed now.
App.js
import React, {Component} from 'react';
import {View, StyleSheet} from 'react-native';
import Svg, {Defs, ClipPath, Path, Polygon, Use} from 'react-native-svg';

const getPath = (a, b) => `M 0 0 L ${a} 0 ${a} ${b}`;

class Test extends Component {
  componentDidMount() {
    setTimeout(() => {
      this._myPath.setNativeProps({
        d: getPath(50, 80),
      });
    }, 2500);
  }
  render() {
    return (
      <Svg width={160} height={160} viewBox="0 0 80 80">
        <Defs>
          <ClipPath id="successfulClippingPath">
            <Path
              ref={ref => {
                this._myPath = ref;
              }}
              d={getPath(10, 80)}
              fill={'#FFF'}
            />
          </ClipPath>
          <Polygon
            id="hexagon"
            points="30,15 22.5,28 7.5,28 0,15 7.5,2 22.5,2"
            fill="lime"
            stroke="purple"
            strokeWidth="1"
          />
        </Defs>
        <Use
          fillRule="evenodd"
          fill={'none'}
          href={'#hexagon'}
          clipPath="url(#successfulClippingPath)"
          stroke={'#06E6FA'}
          strokeWidth="7"
        />
      </Svg>
    );
  }
}

export default () => (
  <View style={styles.container}>
    <Test />
  </View>
);

const styles = StyleSheet.create({
  container: {
    backgroundColor: 'black',
    justifyContent: 'center',
    alignItems: 'center',
    flex: 1,
  },
});

I don't see setNativeProps as a property on shapes such as Ellipse. I'm using react-native-web, so I can use event.target I guess. I just wanted to use RN APIs as much as possible.

I don't see setNativeProps as a property on shapes such as Ellipse. I'm using react-native-web, so I can use event.target I guess. I just wanted to use RN APIs as much as possible.

Did you fond a way to make it?
I'm using a dirty trick to do this:
this.mask.current._touchableNode.setAttribute('d', d)

See full example in this lib:

https://github.com/xcarpentier/rn-tourguide/blob/master/src/components/SvgMask.tsx#L63
https://github.com/xcarpentier/rn-tourguide/blob/master/src/components/SvgMask.tsx#L122
https://github.com/xcarpentier/rn-tourguide/blob/master/src/components/AnimatedPath.tsx#L9


Using github actions to run tests

Currently blocked by https://github.com/actions/setup-go/issues/16

Is this ready to go?


audio/video call

When can i expect audio/video call in this sample app

We will not add more features to this sample app. This app is just showing how to setup the SDK to login, view room list, view timeline and send message.
For a full app implementation, you can refer to https://github.com/vector-im/element-android

This version is too complicated. Can you make a simple audio and video call version?

我们不会向此示例应用程序添加更多功能。这个应用程序只是展示了如何设置 SDK 来登录、查看房间列表、查看时间线和发送消息。
完整的应用实现，可以参考https://github.com/vector-im/element-android

This version is too complicated. Can you make a simple audio and video call version?


webpack build warnings

Hi,
I use ngx-gallery 1.1.7 without problems. But for your information: a lot of warnings occure when building with webpack 3.3.0 and<EMAIL_ADDRESS>:
`WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery.component.ts
[32, 22]: Type number trivially inferred from a number literal, remove type annotation
[34, 20]: Type number trivially inferred from a number literal, remove type annotation
[52, 41]: Parentheses are required around the parameters of an arrow function definition
[156, 44]: Parentheses are required around the parameters of an arrow function definition
[157, 45]: Parentheses are required around the parameters of an arrow function definition
[158, 42]: Parentheses are required around the parameters of an arrow function definition
[159, 45]: Parentheses are required around the parameters of an arrow function definition
[166, 49]: Parentheses are required around the parameters of an arrow function definition
[167, 18]: Parentheses are required around the parameters of an arrow function definition
[178, 36]: Parentheses are required around the parameters of an arrow function definition
[180, 25]: Parentheses are required around the parameters of an arrow function definition
[189, 21]: Parentheses are required around the parameters of an arrow function definition
[190, 18]: Parentheses are required around the parameters of an arrow function definition
[197, 33]: Parentheses are required around the parameters of an arrow function definition
[138, 13]: Expected property shorthand in object literal ('{index}').
[13, 15]: The selector of the component "NgxGalleryComponent" should have prefix "jhi" (https://angular.io/styleguide#style-02-07)
@ ./node_modules/ngx-gallery/lib/index.js 1:0-40
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery.module.ts
[42, 1]: Consecutive blank lines are forbidden
@ ./node_modules/ngx-gallery/lib/index.js 2:0-37
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery-animation.model.ts
[2, 18]: Type string trivially inferred from a string literal, remove type annotation
[3, 19]: Type string trivially inferred from a string literal, remove type annotation
[4, 20]: Type string trivially inferred from a string literal, remove type annotation
[5, 18]: Type string trivially inferred from a string literal, remove type annotation
@ ./node_modules/ngx-gallery/lib/index.js 5:0-46
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery-image-size.model.ts
[2, 19]: Type string trivially inferred from a string literal, remove type annotation
[3, 21]: Type string trivially inferred from a string literal, remove type annotation
@ ./node_modules/ngx-gallery/lib/index.js 6:0-47
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery-layout.model.ts
[2, 27]: Type string trivially inferred from a string literal, remove type annotation
[3, 30]: Type string trivially inferred from a string literal, remove type annotation
@ ./node_modules/ngx-gallery/lib/index.js 7:0-43
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery-preview.component.ts
[16, 18]: Type boolean trivially inferred from a boolean literal, remove type annotation
[36, 20]: Type number trivially inferred from a number literal, remove type annotation
[38, 21]: Type boolean trivially inferred from a boolean literal, remove type annotation
[7, 15]: The selector of the component "NgxGalleryPreviewComponent" should have prefix "jhi" (https://angular.io/styleguide#style-02-07)
@ ./node_modules/ngx-gallery/lib/ngx-gallery.module.ts 25:38-80
@ ./node_modules/ngx-gallery/lib/index.js
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery-helper.service.ts
[22, 30]: Parentheses are required around the parameters of an arrow function definition
@ ./node_modules/ngx-gallery/lib/ngx-gallery.component.ts 14:35-74
@ ./node_modules/ngx-gallery/lib/index.js
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery-arrows.component.ts
[4, 15]: The selector of the component "NgxGalleryArrowsComponent" should have prefix "jhi" (https://angular.io/styleguide#style-02-07)
@ ./node_modules/ngx-gallery/lib/ngx-gallery.module.ts 22:37-78
@ ./node_modules/ngx-gallery/lib/index.js
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery-image.component.ts
[7, 15]: The selector of the component "NgxGalleryImageComponent" should have prefix "jhi" (https://angular.io/styleguide#style-02-07)
@ ./node_modules/ngx-gallery/lib/ngx-gallery.module.ts 23:36-76
@ ./node_modules/ngx-gallery/lib/index.js
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
WARNING in ./node_modules/ngx-gallery/lib/ngx-gallery-thumbnails.component.ts
[7, 15]: The selector of the component "NgxGalleryThumbnailsComponent" should have prefix "jhi" (https://angular.io/styleguide#style-02-07)
@ ./node_modules/ngx-gallery/lib/ngx-gallery.module.ts 24:41-86
@ ./node_modules/ngx-gallery/lib/index.js
@ ./src/main/webapp/app/images/images.module.ts
@ ./src/main/webapp/app/app.module.ts
@ ./src/main/webapp/app/app.main.ts
@ multi (webpack)-dev-server/client?http://localhost:9060 webpack/hot/dev-server ./src/main/webapp/app/app.main
`

Hi @gozeller thanks for info. I will try to eliminate them

I'm using the same versions and I'm experiencing these warnings as well. Thanks for taking a look at this @lukasz-galka ! Great component :)

Hi @gozeller @german-e-mas
In version 1.3.0 I have eliminated all warnings except
The selector of the component "..." should have prefix "jhi"
To fix this warning I have to change my build system (my components have ngx prefix). On the other hand you shouldn't lint external libraries. For angular-cli based apps you can disable this in config file, I described this here https://github.com/lukasz-galka/ngx-gallery/issues/14#issuecomment-309663783
Maybe you can also disable this in you generator? Are you using jhipster?

Hi @lukasz-galka, no warnings anymore.
(Yes, I'm using jhipster.)
Thanks for your work!


Added 'zora-mint-base'

I just fixed all other parts of code, just waiting for mintbuilder template to have creator field

Unfortunately in zora, its always returning null for creator @chrismaddern

@Nith567 yes indeed... because you're building the ingestor that will populate that data.
Likely it comes back from this call here: https://github.com/floornfts/mobile-minting/pull/18/files#diff-5466828e6def88e3cb17235dc6ee89722b3d02dc44c7297bdfdbad385ea0b29eR40
You'll then need to set it like in the FXHash example here:
https://github.com/floornfts/mobile-minting/blob/main/src/ingestors/fxhash/index.ts#L51

Interesting. As you know, we already support Zora in-house, and it appears that we're composing this response with this API to get this data:
https://zora.co/api/trpc/profile.getProfile?input=<address>
That might be the right approach here. Looking at their graph explorer → https://api.zora.co/graphql# it's not obvious to me where that data is available in the graph?

@chrismaddern  check this out : https://github.com/Nith567/mobile-minting/blob/main/src/ingestors/zora-mint/index.ts#L64

Amazing news, thank you for the update!
We've gotten a little behind on reviewing these, but will be spending some time over the next 48 hours, so look out for some feedback soon! Thank you! 🙏

Thanks @Nith567 I think this is almost ready to merge.
I made a few changes locally and couldn't push to the repo, but made you a patch to apply to update this PR.
It:

Moves this to be zora
Adds the required setAvailableForPurchaseEnd
Adds the output contract
Sets the marketing URL on the output payload

zora.patch

@chrismaddern   Successfully applied patch using git apply command

  const minterArguments = encodeAbiParameters(
    [
      { name: "mintTo", type: "address" },
      { name: "comment", type: "string" },
    ],
    ['mintToAddress', 'comment here ']
  );
``` actually minterarguemnts takes a comment and an address to mint

That's funny, we have an internal Zora ingestor and that does what I mentioned. Funny that it works 🤣 🤣 🤣

@Nith567 let me know when the simulation tests pass & we can get this in

Yeah i just fixed it, simulation tests passes successfully

Thanks @Nith567. I pulled this locally, and unfortunately they're not (your current tests don't include simulations since they weren't using the basicIngestorTests macro)
I added the following to your tests to have the simulation run:
basicIngestorTests(new ZoraIngestor(), mintIngestorResources(), {
    successUrls: ['https://zora.co/collect/base:0x1e1ad3d381bc0ccea5e44c29fb1f7a0981b97f37/1'],
    failureUrls: ['https://example.com'],
    successContracts: [{ chainId: 8453, contractAddress: '0x1e1ad3d381bc0ccea5e44c29fb1f7a0981b97f37', tokenId: '1' }],
    failureContracts: [{ chainId: 8453, contractAddress: '0x6140F00e4Ff3936702E68744f2b597885464cbB', tokenId: '1' }],
});

e.g. like this one
https://github.com/floornfts/mobile-minting/blob/main/test/ingestors/prohibition-daily.test.ts#L11
The same is true when running it with dry-run:
yarn dry-run zora url https://zora.co/collect/base:0x1e1ad3d381bc0ccea5e44c29fb1f7a0981b97f37/1

In this case the error seems to be that the value is being passed incorrectly as a decimal instead of a BigInt fractional unit (in this case 0.000777 vs.<PHONE_NUMBER>00000

Seems like the previous "https://zora.co/collect/base:0x1e1ad3d381bc0ccea5e44c29fb1f7a0981b97f37/1" has stopped minting NFT phase.
So try with other one it should look something like this :
` yarn dry-run zora url https://zora.co/collect/base:0x05ef5809568d428c5ea07513195d2cd8be75e2ac/1`

` export const mintArguements=(address:string,comment:string)=>{
return  encodeAbiParameters(
[
{ name: "mintTo", type: "address" },
{ name: "comment", type: "string" },
],
[address as Address, comment]
)
} `
instead of adding encodedAddress, its better to have an extra function so we can add a comment too instead of padding 64 hexadecimal zeros in simulation.ts file

@chrismaddern  any update ?

@Nith567 the tests fail for me locally and on CI.
The version of ethers included in this project does not have a util function (not sure why it didn't fail for you too!)
I think this will work:
ethers.parseEther(totalPriceWei).toString()

export const mintArguments = (address: string, comment: string) => {
  return encodeAbiParameters(
    [
      { name: "mintTo", type: "address" },
      { name: "comment", type: "string" },
    ],
    [address as Address, comment]
  );
};
 instead of adding encodedAddress, its better to have an extra function so we can add a comment too instead of padding 64 hexadecimal zeros in simulation.ts file

I actually like this idea a lot, but for now, I want to keep the mint arguments static except for some template vars (for security reasons)
We could add an optional comment replacement var, which would replace with an empty string if not present (like the current address replacement)

(We can also merge without that and then iterate too 🙂 to get the bounty unlocked 🙂 )

Instead of that confusing we can just use viem library
 import { parseEther } from 'viem';
 priceWei: parseEther(totalPriceWei).toString()

@Nith567 viem is not included in this project. this will also not compile off of your computer.
Can you use the parseEther method exposed by ethers which is included in the current repo? 🙏

I dont know why it just works for me :)
Yeah just switched to ethers library

gm @Nith567
This is great. I added two comments, both with the working code to replace them with.
One final note — when trying an unsupported mint, it appears that supportsUrl returns true, but then ingestUrl throws an "unsupported URL" error.
e.g. URL:
https://zora.co/collect/zora:0x23a036a7ffd4c3b7e70bba3dba48f49316d0970f/155
Ideally, supportsUrl should return false in this scenario.

Yessir!
I left a comment above showing how to lock the blockhash that simulation is occurring at:
Adding the blockhashes to the end of your basicIngestorTests call, like this:
  basicIngestorTests(
    new ZoraIngestor(),
    mintIngestorResources(),
    {
      successUrls: ['https://zora.co/collect/base:0x923b382f3205c26efe706c53d69f71f0817aa954/1'],
      failureUrls: ['https://example.com'],
      successContracts: [
        { chainId: 8453, contractAddress: '0x1e1ad3d381bc0ccea5e44c29fb1f7a0981b97f37', tokenId: '1' },
      ],
      failureContracts: [{ chainId: 8453, contractAddress: '0x6140F00e4Ff3936702E68744f2b597885464cbB', tokenId: '1' }],
    },
    {
      8453: '0x10B4CB9',
    },
  );

@chrismaddern  Finished it !

@chrismaddern any update ?

Seems like i need to make changes to new branch how about we close with pr and i will make a new pr with new branch of zora-mint ingestor how about this @chrismaddern


UnhandledPromiseRejectionWarning after upgrading to Node-Red 1.0.0

I'm submitting a ...  (check one with "x")
Problem

(x) bug report => no related issues found in github for modbus serial

Current behavior
I had a perfectly working flow implementing modbus communication to a Vallox ventilation system. After upgrading Node-Red to version 1.0.0, the flow stopped working. Modbus read does not succeed anymore, and for every attempted modbus read, an error message appears on the log:
(node:27964) UnhandledPromiseRejectionWarning: TypeError: a is not a function
at activateSending (/home/pi/.node-red/node_modules/node-red-contrib-modbus/modbus/maps/modbus-client.js:587:20)
(node:27964) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 719)
Expected behavior
The modbus communication is successful as before upgrading to node-red 1.0.0
Minimal reproduction of the problem with instructions
The problem can be reproduced by upgrading Node-Red to V1.0.0 and using the simplyfied flow:
[{"id":"fe9fab66.e14938","type":"tab","label":"Vallox","disabled":false,"info":""},{"id":"15dc5136.f68e2f","type":"modbus-getter","z":"fe9fab66.e14938","name":"STATE 4609","showStatusActivities":true,"showErrors":false,"logIOActivities":false,"unitid":"","dataType":"HoldingRegister","adr":"4609","quantity":"1","server":"2a7f376e.342c08","useIOFile":false,"ioFile":"","useIOForPayload":false,"x":290,"y":140,"wires":[[],["7222f114.6b0b4"]]},{"id":"409696e3.c0ce68","type":"inject","z":"fe9fab66.e14938","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":140,"y":140,"wires":[["15dc5136.f68e2f"]]},{"id":"7222f114.6b0b4","type":"modbus-response","z":"fe9fab66.e14938","name":"","registerShowMax":20,"x":489.5,"y":141,"wires":[]},{"id":"2a7f376e.342c08","type":"modbus-client","z":"","name":"Vallox","clienttype":"simpleser","bufferCommands":true,"stateLogEnabled":false,"tcpHost":"<IP_ADDRESS>","tcpPort":"502","tcpType":"DEFAULT","serialPort":"/dev/ttyUSB2","serialType":"RTU","serialBaudrate":"19200","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","unit_id":1,"commandDelay":1,"clientTimeout":1000,"reconnectTimeout":2000}]
to attemp a modbus read on one register.
Your Environment
Please tell us about your environment:

Raspberry pi 3 running Node-Red v1.0.0, connected to a Vallox Valloplus 350 MV Ventilation Unit (Modbus RTU) using a RS485 USB Dongle.

(x) I am using just the Node-RED package and got modbus-serial package installed with it
├─┬<EMAIL_ADDRESS>│...
│ ├─┬<EMAIL_ADDRESS>│ │ ├─┬<EMAIL_ADDRESS>│ │ │ └──<EMAIL_ADDRESS>│ │ └──<EMAIL_ADDRESS>deduped
│ ├─┬<EMAIL_ADDRESS>│...

Device :

(X ) Raspbian: v

Description of the connecting Modbus system:

Name   : Vallox ValloPlus
Version: 350 MV
Vendor : Vallox
Link   : https://oxomi.com/service/json/catalog/pdf?portal=3000306&user=&roles=&accessToken=&catalog=10136204
Modbus description: https://www.vallox.com/files/1092/Manual_Modbus_ENG_20190215_PRINT.pdf

node-red-contrib-modbus version: ``
4.1.3

Node: (min. 6.x)
node --version = v10.16.3

#144


attempts to fix scroll retain

alters view_history.js

Was the PR perhaps opened against this repository by mistake?
There's no explanation of what you're trying to do here, why the change should happen in the PDF.js library itself rather than in a custom fork, and finally what little code there is here is definitely not working.

Closing because of the reasons above.


Set last-modified time support?

Hi Martin
First of all sorry if this should not go under issues, as it may be more a question or feature request than a bug/issue.
One of our users tried out rsync -a localdir mntdir against an OSX Finder-mounted wsgidav volume and it actually mostly works, except the file time stamps are not transferred. Thus repeating the rsync call does not skip the already transferred files as intended. I repeated the test with fusedav from Linux and got similar results. Calling a simple touch on a file in the mount also gets rejected with "Operation not supported".
As far as I can tell from my tracing this is due to wsgidav refusing PROPPATCH calls with the {DAV:}getlastmodified argument. The relevant doc string in setPropertyValue of dav_provider correctly states that any {DAV:} property modification requests result in a HTTP_FORBIDDEN reply and that resource providers may override the method to "update supported custom live properties".
I did a quick test and added such set {DAV:}getlastmodified support directly in (fs_)dav_handler and then touch, rsync -t and rsync -a all work as expected. However, I'm not really sure if it belongs there or if it is even compliant with the WebDAV spec:
http://tools.ietf.org/html/rfc4918#section-15.7
It would be quite cool with rsync support for our purpose, but maybe I'm overlooking some problems it might introduce? Would it make sense to properly add such general set modification time support and maybe only enable it with a conf setting? I think I can give it a shot and send a pull request if so.
Or is that something you consider in the custom live properties category and better left for a derived fs resource provider?
Cheers, Jonas

Hi Jonas,
(found a related link here http://stackoverflow.com/a/12643147/19166)
Writing a property that is named 'getlastmodified' feels wrong.
But you observed that touch and rsync -t send a PROPPATCH {DAV:}getlastmodified?
In this case it would not help to support PROPPATCH {DAV:}lastmodified` (without 'get') or another custom approach.
I have seen objections that this may confuse clients that rely on If-Modified-Since headers, and the spec says it SHOULD be protected, but I am open to a configuration setting...

Thanks for the informative input and link, Martin.
Yes, I also initially went searching for a corresponding **set**lastmodified or just lastmodified in the RFC and code, but without any luck. In fact the commands both result in PROPPATCH **get**lastmodified requests.
I uploaded a trace of touch from the original at:
http://www.erda.dk/wsgidav-touch-trace.txt
and one from the version with my added support for changing it at:
http://www.erda.dk/wsgidav-touch-enabled-trace.txt
So apparently one must handle getlastmodified for it to work, but it could of course easily be extended to cover plain lastmodified requests as well.
Doing another touch after the first one resulted in first a HEAD request that received a matching
Last-Modified: 'Tue, 14 Jul 2015 06:15:02 GMT' reply, and then the actual next PROPPATCH request. I don't know if that would confuse other clients, but in our case I'd say it's the intended result.
I guess the same clients would then also be confused if a user would mimic a touch by moving the original file out of the way and then moving another copy with just a different time stamp there, because then that different time stamp is transferred.
I'm going to be mostly away for the next week or two, but will take a look at making a configurable implementation when time permits. I'm thinking something along the lines of adding support for a
mutableliveprops = ["{DAV:}getlastmodified"]
conf option and forwarding any matching live PROPPATCH requests in dav_provider.setPropertyValue if the actual provider has a corresponding setX method.
Comments and suggestions are welcome...

Hi Martin
Thanks for merging the patch!
I've switched our production to your updated version and verified that fusedav mounted touch and rsync -a works. Therefore closing the issue here.
Cheers, Jonas


Request: Add a repo.yaml to spack packages

I would like the ability to add this code repo's spack packages as a spack repo to environment files.  Currently, it looks like I have to copy these packages manually into a spack installation (or another spack repo) to use them.
I'll create a PR demonstrating what I'm looking for.
Related PR #1036

@white238 Can you eyeball this?  So, this requires adding patch files that are in spack github that are missing in this repo.  I'm assuming the package files in this repo were only those that are strictly different than spack github rather than the full set of files needed for each package to work.  (But it's really convenient to be able to pull this in as a spack repo instead of needing to copy files into a spack installation).  Thanks


Redact token value from hook logs

Coverage decreased (-0.02%) to 88.281% when pulling 1373ca5b51be98741f8f132f24a953ccecf63901 on redact-hook-token into d2448480339d0ab0700af09608e341ab7b4ce6d8 on master.

Even if I feel that's the cleanest solution:

I think doing a regex for every log will kill performance (complexity for regex is O(n), but can require up to O(2^m))

Also, we should always use re.compile when using regular expressions 😉


Time binning of the GeoVaLs read from files

Description
Time binning of the atmospheric geovals in GetValues is not implemented.
Solution/Optimization
Implement the binning for atmospheric geovals in GetValues.cc.
Reading of all the geovals should be done at the constructor level as suggested by @shlyaeva here
Alternatives
Do nothing.

I think this can be closed now that this functionality is removed from soca. (I'm going through all issues where I'm mentioned, and noticed this one).

taking advantage of @guillaumevernieres  being on vacation and closing this myself :-)


update to 14.0.6

as we spoke in review, I will release all versions but Windows.  Actually Windows could pass too, but sadly Prefect builder is cycling for ever, Concourse ran out of disk-space .... so I will build it separately.  This also unblocks tensorflow's libclang dependency


KAFKA-13173 Making the controller fence stale brokers one at a time if multiple stale brokers are discovered at the same time

This is necessary as the effect of each fencing is visible to the
controller one the corresponding record for it has been generated and
applied. Processing stale brokers one at a time ensures that subsequent
fencing records are generated correctly with the correct view of the system.

@showuon -- Thanks for looking at the PR. Will address the comments and publish an update.

@niket-goel I'm inclined to merge this as is so that we don't need to wait for another build. Perhaps you can submit a small follow-up to address @jsancio 's comments?

@hachikuji Will follow up with a follow-up. Thanks for merging this.


fix: use consistent oracles and market indexes when creating account subscriber in DriftClient constructor

When creating a polling subscriber the DriftClient constructor uses values provided by DriftClientConfig param first and otherwise falls back to value returned by getMarketsAndOraclesForSubscription(config.env). When creating a websocket subscriber however the constructor only uses the value provided by the config. It lead to some confusion on my part when trying to create a new DriftClient instance using a config that only specified the env property but not the oracleInfos etc. of the config object. It seems like this should be consistent unless there is some reason I am missing.

nice catch! lgtm


Lints not showing in pubspec files.

Possibly mis-filed on the IDEA issue tracker: https://youtrack.jetbrains.com/issue/WEB-35763, DAS appears to, in at least some cases, not be reporting analysis errors on pubspecs.
Here's a repro.

create a Dart project
create an analysis_options.yaml file w/ the package_names lint enabled:

linter:
  rules:
    - package_names

update the package name in the pubspec to something camelcase (e.g., FooBar) and save

What is the expected result?
Should see an error reported in the pubspec.
What happens instead?
No reported error.
/cc @bwilkerson @stereotype441
See also: #31890.

This is still a bug for me; lint does not show up in Problems panel of VS Code until I save the pubspec.yaml change.

Is server sent an overlay notification for pubspec.yaml files? If so, do the updated diagnostics get sent to the client? (Just trying to figure out where the bug is.)

Is server sent an overlay notification for pubspec.yaml files?

Maybe @jwren knows?

I don't think so, I was just questioning my assumptions. The reason we decided against that is because changes to either pubspec.yaml or analysis_options.yaml would necessitate re-analyzing the whole package, and that would be too expensive.
If we want to change that decision then we'll need to figure out the semantic of what it means for the content to be overlayed. Maybe it would be as simple as "re-analyze the YAML file, but don't reanalyze anything else". That could still result in some surprising behavior from a user's perspective, though so I'm not convinced it would be a good change. (For example, adding a lint rule wouldn't run the lint until the file was saved, even though it looks to the user like it's been enabled.)
In any case, it looks like it's currently working as intended.


robust spot detection is needed

Segmentation loses quite a few antigen spots and is not robust to smearing of antigen (see #7 for images and segmentations). We need robust method for detecting where antigens are in the array grid. This step is likely time consuming, so making it fast in the next iteration is also good idea.

@mattersoflight I'm trying out a few things right now starting with point cloud matching, which is fast if I can get it to work robustly on so few points. I'm on limited bandwidth with two kids at home and a bit rusty too, but hopefully I can get a prototype working soon.

One solution:

@smguo, just tried and your PR runs well (https://github.com/czbiohub/serology-COVID19/pull/16) and optical densities look usable too.

I am copying the results in googledrive and will be using this output to continue with interpretation notebook. It now uses nd-arrays. You and Janie should continue the analysis (https://github.com/czbiohub/serology-COVID19/blob/master/notebooks_interpretation/20200115_plate4_AEP_Feb3_6mousesera.ipynb).
@bryantChhun and @ieivanov, the interpolation aspect of this PR can help the spot detection methods you are working for octopi data.

@mattersoflight I have one solution now too. The code is still a bit messy, but you can see it in this notebook:
https://github.com/czbiohub/serology-COVID19/blob/jenny_tests/array_analyzer/extract/spot_detection_icp.ipynb
The spot detection is pretty slow, it takes about 0.6 seconds, but the registration part is faster, about 5 ms. I've only evaluated on the images_octopi/20200325AdamsPlate/Averaged/500us, so I'll have to check robustness on more images.

This is great @jennyfolkesson.
Here are @bryantChhun's notes:

wrote a new method “build_block_array” that takes “params” dict returned from “txt_parser.create_xml_dict” and the camera pixel size in mm
This method creates binary squares, each centered at expected spot position, in an array of row/col specified by the .xml file.
I have another method “build_and_place_block_array” that will interpolate the A1 position based on regionprops and place this block array there.  This works 100% on the flu data (including H8) if you tune the “select_props”.  Problem is that these hyperparameters don’t work for the octopi data.
The parameter tuning is getting heavy and may be problematic in the long run.  Some type of fitting would be great, but potentially hard too — Could easily be lots of local minima, so a good loss function should be designed

I am now doing a comparison and will note my observations here.

@jennyfolkesson's iterative closest point algorithm works very well for finding the location of fiducial markers only:
https://github.com/czbiohub/serology-COVID19/blob/find_fiduc_fromJenny/array_analyzer/extract/spot_detection_icp.ipynb
Once we have the location of fiducial markers we can easily interpolation the rest of the grid, as already implemented in @bryantChhun's branch. This reduces the requirements on the initial segmentation, making it potentially much faster, and is robust to plates with mostly blank spots (e.g. negative subjects).
Will implement in the repo

nice work @jennyfolkesson and @ieivanov! The approach works well and is a much more robust than segmentation. I have added some code to estimate hyper-parameters. If images are scaled to about 1800,  no hyper parameter tuning was required between scienion and octopi data.

Ok not sure which order we should merge.  I did try integrating jenny's notebook code into the main script but had some hiccups:

doing a conda install of the latest opencv showed that estimateRigidTransform is not available.  Documentation says it's deprecated and other methods should be used (affine2d), but the outputs are slightly different.  @jennyfolkesson can you check what version of openCV you're using? (mine is 4.2.0)  We can put your version in as a hard requirement.

there is some pixel scaling to consider.  It looks like Shalin was able to solve this.

When you resize image to 1800 and set min spot size set to 500, you do get consistent detection of fiducials. One parameter that is still finicky is spot_distance. It is estimated from histogram of manhattan distance now, but more robust to compute it from parameters of the array printer and of the imager.
Data from Octopi:

Data from scienion:

I'm on OpenCV version 3.4.2 - you can tell I've been away for a while. :-)
I will update my code to work with the version the rest of you are using
and move the code into the main repository. I'll send a PR to @Bryant Chhun
<EMAIL_ADDRESS>hopefully by tonight.
On Mon, Mar 30, 2020 at 8:43 AM Shalin Mehta<EMAIL_ADDRESS>wrote:

When you resize image to 1800 and set min spot size set to 500, you do get
consistent detection of fiducials. One parameter that is still finicky is
spot_distance. It is estimated from histogram of manhattan distance now,
but more robust to compute it from parameters of the array printer and of
the imager.
Data from Octopi:
[image: image]
https://user-images.githubusercontent.com/2934183/77931970-b9a1bc00-7261-11ea-9433-ca8d5b3afa9f.png
Data from scienion:
[image: image]
https://user-images.githubusercontent.com/2934183/77932471-7005a100-7262-11ea-9ffb-dc12457b9a63.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/czbiohub/serology-COVID19/issues/14#issuecomment-606078360,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABT3MZJJXCE2PJGAZEDCKO3RKC4ZBANCNFSM4LVKOZXQ
.

I'm on OpenCV version 3.4.2 - you can tell I've been away for a while. :-) I will update my code to work with the version the rest of you are using and move the code into the main repository. I'll send a PR to @bryant Chhun<EMAIL_ADDRESS>hopefully by tonight.
…
On Mon, Mar 30, 2020 at 8:43 AM Shalin Mehta @.***> wrote: When you resize image to 1800 and set min spot size set to 500, you do get consistent detection of fiducials. One parameter that is still finicky is spot_distance. It is estimated from histogram of manhattan distance now, but more robust to compute it from parameters of the array printer and of the imager. Data from Octopi: [image: image] https://user-images.githubusercontent.com/2934183/77931970-b9a1bc00-7261-11ea-9433-ca8d5b3afa9f.png Data from scienion: [image: image] https://user-images.githubusercontent.com/2934183/77932471-7005a100-7262-11ea-9ffb-dc12457b9a63.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABT3MZJJXCE2PJGAZEDCKO3RKC4ZBANCNFSM4LVKOZXQ .

Hi Jenny,
That's actually great.  According to this, OpenCV 3.3.1 is default on jetson nano:

Now, it seems if we want cuda acceleration, we may still need to recompile.  Let's hope we're fast enough without it.

@jennyfolkesson I already incorporated your iterative closest point search in the main repo on the branch find_spot_grid.
I did encounter an issue with this algorithm, however. Take a look at this notebook: https://github.com/czbiohub/serology-COVID19/blob/find_fiduc_fromJenny/array_analyzer/extract/spot_detection_icp.ipynb
When the grid is not initialized close to the target location (i.e. start_x and start_y are off), the algorithm doesn't find the correct target. I'll try a bit to fix that, but if you have time you're welcome to give it a shot as well.

I'll work on it. ICP is only guaranteed to converge if initialized close
enough to the true solution, so I was expecting that I would have to tune
the initial estimation once I encountered more heterogeneity in the data. @Ivan
Ivanov<EMAIL_ADDRESS>would you mind pointing me the data you
experienced issues with? And why are you using a cropped version of the
image? Thanks!
On Mon, Mar 30, 2020 at 2:42 PM ieivanov<EMAIL_ADDRESS>wrote:

@jennyfolkesson https://github.com/jennyfolkesson I already
incorporated your iterative closest point search in the main repo on the
branch find_spot_grid.
I did encounter an issue with this algorithm, however. Take a look at this
notebook:
https://github.com/czbiohub/serology-COVID19/blob/find_fiduc_fromJenny/array_analyzer/extract/spot_detection_icp.ipynb
When the grid is not initialized close to the target location (i.e.
start_x and start_y are off), the algorithm doesn't find the correct
target. I'll try a bit to fix that, but if you have time you're welcome to
give it a shot as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/czbiohub/serology-COVID19/issues/14#issuecomment-606266909,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABT3MZMPYFPA56C26L5ILFLRKEG33ANCNFSM4LVKOZXQ
.

Nevermind, I see it's a cropped version of the image in
2020-01-15_plate4_AEP_Feb3_6mousesera...
I will test that folder right now.
On Mon, Mar 30, 2020 at 2:54 PM Jenny Folkesson <
<EMAIL_ADDRESS>wrote:

I'll work on it. ICP is only guaranteed to converge if initialized close
enough to the true solution, so I was expecting that I would have to tune
the initial estimation once I encountered more heterogeneity in the data. @Ivan
Ivanov<EMAIL_ADDRESS>would you mind pointing me the data you
experienced issues with? And why are you using a cropped version of the
image? Thanks!
On Mon, Mar 30, 2020 at 2:42 PM ieivanov<EMAIL_ADDRESS>wrote:

@jennyfolkesson https://github.com/jennyfolkesson I already
incorporated your iterative closest point search in the main repo on the
branch find_spot_grid.
I did encounter an issue with this algorithm, however. Take a look at
this notebook:
https://github.com/czbiohub/serology-COVID19/blob/find_fiduc_fromJenny/array_analyzer/extract/spot_detection_icp.ipynb
When the grid is not initialized close to the target location (i.e.
start_x and start_y are off), the algorithm doesn't find the correct
target. I'll try a bit to fix that, but if you have time you're welcome to
give it a shot as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/czbiohub/serology-COVID19/issues/14#issuecomment-606266909,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABT3MZMPYFPA56C26L5ILFLRKEG33ANCNFSM4LVKOZXQ
.

Sure, here is the image. In our pipeline, we pre-crop the well first. This makes the spot segmentation easier, and it also runs much faster.

@ieivanov and @jennyfolkesson , we have occasionally found automatic pre-cropping to be difficult and I found cropping after locating fiducials to be more robust. You'll see the code in earlier commit improved parameter estimation.
@jennyfolkesson,  as you test, please pull files from two datasets (octopi, scienion). Paths are in above commit. I am inviting you to that google filestream.
Versioning is becoming important - please edit the code that Ivan added to main repo.
On the topic of speed, I was clocking 0.3s for 1800x1800 image for spot detection.

I'm testing the master branch with Jenny's approach incorporated but got this error:
A1.png Traceback (most recent call last):   File "/Applications/PyCharm.app/Contents/plugins/python/helpers/pydev/pydevd.py", line 1434, in _exec     pydev_imports.execfile(file, globals, locals)  # execute the script   File "/Applications/PyCharm.app/Contents/plugins/python/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile     exec(compile(contents+"\n", file, 'exec'), glob, loc)   File "/Users/syuan-mingguo/python/serology-COVID19/run_array_analyzer.py", line 289, in <module>     main(sys.argv[1:])   File "/Users/syuan-mingguo/python/serology-COVID19/run_array_analyzer.py", line 121, in main     workflow(inputfolder, outputfolder, debug=debug)   File "/Users/syuan-mingguo/python/serology-COVID19/run_array_analyzer.py", line 208, in workflow     props_array = assign_props_to_array_2(props_array, props_by_loc)   File "/Users/syuan-mingguo/python/serology-COVID19/array_analyzer/extract/image_parser.py", line 470, in assign_props_to_array_2     if arr[key[0], key[1]] and np.mean(value.intensity_image) > np.mean(arr[key[0], key[1]].intensity_image): IndexError: index 7 is out of bounds for axis 1 with size 6

I'm testing the master branch with Jenny's approach incorporated but got this error:
A1.png
Traceback (most recent call last):
File "/Applications/PyCharm.app/Contents/plugins/python/helpers/pydev/pydevd.py", line 1434, in _exec
pydev_imports.execfile(file, globals, locals) # execute the script
File "/Applications/PyCharm.app/Contents/plugins/python/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File "/Users/syuan-mingguo/python/serology-COVID19/run_array_analyzer.py", line 289, in
main(sys.argv[1:])
File "/Users/syuan-mingguo/python/serology-COVID19/run_array_analyzer.py", line 121, in main
workflow(inputfolder, outputfolder, debug=debug)
File "/Users/syuan-mingguo/python/serology-COVID19/run_array_analyzer.py", line 208, in workflow
props_array = assign_props_to_array_2(props_array, props_by_loc)
File "/Users/syuan-mingguo/python/serology-COVID19/array_analyzer/extract/image_parser.py", line 470, in assign_props_to_array_2
if arr[key[0], key[1]] and np.mean(value.intensity_image) > np.mean(arr[key[0], key[1]].intensity_image):
IndexError: index 7 is out of bounds for axis 1 with size 6

Can you make a new issue?

Sure... just wanted to check if I'm running it right. It errors out on the first image (A1.png)

I didn't get through all the testing today, toddler refused to nap then continued to have meltdowns the rest of the day... Hopefully the kids will cooperate tomorrow!
It does seem like the pre-cropping of the well is pretty slow, it took several seconds for me. So if I can get the spot detection robust that could speed things up.
Sorry for the newbie question: when you say find fiducials, is that the same as spot detection?

No worries Jenny, others are integrating this approach. By fiducials, we mean 5 specific spots that Ivan and I have been registering to the detected spots. These 5 spots are always present in all data. We should probably call them 'reference spots'. Other spots may or may not show up depending on experiment.

It took me a while but I was able to make the interpolation approach work for the new Scienion flu plate data:

It still fails occasionally on some challenging cases (2-3 wells out of 96 wells), but hopefully combined with the approach @jennyfolkesson @bryantChhun and @ieivanov are developing we can cover almost all the cases.
The full processed data can be found at
ELISAarrayReader/images_scienion/2020-03-30-15-08-05-COVD_March25_fluplatetest_AdamsPlate/test_output/3_31_18_7_10

I tested out one idea I had today to initialize the grid, which was to look at intensity profiles in x and y and determine spot locations from there. It worked pretty good, but it was thrown off when there were few spots and very dark dirt near the spots. You can see an example notebook here. http://localhost:8888/notebooks/array_analyzer/extract/icp_initialization.ipynb
It failed on 2 images in the 2020-01-15_plate4_AEP_Feb3_6mousesera dir and 8 (ugh) in the 2020-03-30-15-08-05-COVD_March25_fluplatetest_AdamsPlate dir.
My next plan is to try some type of particle filtering, which hopefully should be able to escape the local minima this first attempt got stuck in.
Sorry this is taking a while, Lex didn't nap again today so things are a bit chaotic...

Awesome work @jennyfolkesson, @bryantChhun , and @smguo . The recent tests from merged master look good. I am closing this issue and starting a new one. I think ICP will be very useful in handling edge cases that arise due to experimental factors.


webots_ros2: 2023.0.4-1 in 'iron/distribution.yaml' [bloom]

Increasing version of package(s) in repository webots_ros2 to 2023.0.4-1:

upstream repository: https://github.com/cyberbotics/webots_ros2.git
release repository: https://github.com/ros2-gbp/webots_ros2-release.git
distro file: iron/distribution.yaml
bloom version: 0.11.2
previous version for package: 2023.0.3-3

webots_ros2
* Drop support for Foxy.
* Fixed vertical field of view in static RangeFinder plugin.
* Added support for painted point clouds
* Fixed ability to launch RViz without other tools in e-puck example.
* Fixed command line arguments in importer tools.
* Added custom handler in driver interface to start nodes when Webots is ready.

webots_ros2_driver
* Fixed vertical field of view in static RangeFinder plugin.
* Added support for painted point clouds
* Added custom handler to start nodes when Webots is ready.

webots_ros2_epuck
* Fixed ability to launch RViz without other tools.
* Start ros control and navigation nodes when Webots is ready.

webots_ros2_importer
* Fixed argument parsing

webots_ros2_tests
* Added support for painted point clouds

webots_ros2_tiago
* Start ros control and navigation nodes when Webots is ready.

webots_ros2_turtlebot
* Start ros control and navigation nodes when Webots is ready.

webots_ros2_universal_robot
* Start ros control nodes when Webots is ready.

webots_ros2_control appears to be causing a regression as seen here but there is no changelog entry associated with the bump for this package in the PR desc.
Build error: https://build.ros2.org/job/Ibin_ujv8_uJv8__webots_ros2_control__ubuntu_jammy_arm64__binary/

The regression is coming from https://github.com/ros-controls/ros2_control/commit/cf4448d92d6644c04f060452e309d362ebbd118b#diff-2e7fae9591756afd4b8c6a1fc59b2c1f548d974c960f567f00f5546c746e2383 which broke the backwards compatibility on the Iron distribution.

@ygoumaz thanks for identifying the source of the problem. Are you able to accommodate the API changes and bloom a new release asap?

Thanks @ygoumaz for promptly supplying the fix! The regression has been resolved and I'll proceed with the sync.


Sliver in beacon style can't execute command

In the command Line ,it is normal

but in mythic ,it can not work

@wxi3 Are you able to give more information about the setup to reproduce this bug? What versions of Sliver/Mythic are being used? What type of implant was created and what type of host is it running on?

This is my version:

my mean,when i user sliver to generate a beacon style implant,i can execute command in sliver command line ,but i can't work in mythic when i use this command : use

Your screenshot shows commands being run in the “shell” context, which isn’t normally allowed for beaconing implants.

I installed a fresh kali, fresh sliver, fresh mythic, and was able to successful build a local http beaconer and task it. Let me know if it's failing for other tasks, or perhaps there is something more specific about your setup that can be shared to further replicate the issue. Again, 'shell' is only applicable for 'session' type implants, not beacons.
Furthermore, I saw that the beaconer wasn't automatically added like sessions would be, but that could likely be easily added by adding more events into this area of the code like I have for auto-adding sessions.
https://github.com/MythicAgents/sliver/blob/8675e0be9ad21e86772bf1e968b71da03006407b/Payload_Type/sliverapi/sliverapi/SliverRequests/SliverAPI.py#L67

sliverconfig_file_uuid is likely the uuid of the file you upload when connecting to sliver when creating the sliverapi callback. This can be found in Mythic in the files tab I believe. The reason this is needed, is potentially multiple sliver servers could exist, and I hadn't implemented an easy way to pick which one, and didn't want to assume only one was used, since Mythic supports multiple operations at the same time. In the future, perhaps this can be a dynamic drop down, but ideally you might just generate via the command line with the generate command, or with sliver directly instead of Mythic. I would need to test more to ensure that gui build functionality is working at 100%, it may be still buggy.

You might also notice that most of the generate options are not even available in that Mythic view, only because I did the bare minimum for that part of the proof of concept. All the other options could easily be added if this is the preferred method of building.

I think those implants are still 'generated', but just not uploaded into Mythic as well. That functionality wouldn't be too bad to handle, just api call to sliver to download after generating, then api call to Mythic to upload. That implant still exists on the Sliver server if you want to manually upload it in the meantime. Again, initial proof of concepts, but doable.

I'd have to look into adding it, but this would also be doable.
Here is actually the line in the sliver-py library I was using that could accomplish it. (referencing 1.6 sliver-py, but it's likely in the 1.5 version as well)
https://github.com/moloch--/sliver-py/blob/c9ca1dea1f92f6836eace21cf2f1592c36e5499c/src/sliver/client.py#L248

All in all, reasonable questions / bugs / things to implement. My motivation to work on it has stalled until Sliver officially releases version 1.6, since that simplifies some code.

Thank for you response.
Is this the uuid you are referring to:

But it still failed ,and here is the error message

`Build Message:
Sending Build command
StdErr:
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/mythic_container/agent_utils.py", line 70, in buildWrapper
build_resp = await agent_builder.build()
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Mythic/sliverimplant/agent_functions/builder.py", line 54, in build
config = SliverClientConfig.parse_config(filecontent.Content)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/sliver/config.py", line 86, in parse_config
return cls(**json.loads(data))
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/json/init.py", line 346, in loads
return _default_decoder.decode(s)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
Expecting value: line 1 column 1 (char 0)
StdOut:
`
Yes,i also noticed  that Mythic-Sliver still has many features that need improvement. It is a great tool.Thank for your reply,and i wish you a wonderful life.

I don’t think that’s it, I think it’s located in the “files” and the one you selected is the pseudo implant that is created for sliverapi, which is 0 bytes.
If you have a fresh install, and create the sliverapi, you’d see which file it was in the files tab I believe.

Is it this one?

No, see if there’s an area to view files in the navbar in mythic, and find a file that corresponds to that sliver .cfg