default runtime images can not be removed

Currently when you attempt to remove one of the default runtime images, say Pandas 1.1.1, you get the error:
Removal of instance 'pandas' from the runtime-images schemaspace is not permitted!

The JupyterLab logs show:
[E 2022-02-14 07:18:24.837 ElyraApp] Removal of instance 'pandas' from the runtime-images schemaspace is not permitted!  Resource conflict at '/opt/conda/share/jupyter/metadata/runtime-images/pandas.json'
[W 2022-02-14 07:18:24.837 ServerApp] 403 DELETE /notebook/kf-development/elyra-3-6-0/elyra/metadata/runtime-images/pandas?1644823104409 (<IP_ADDRESS>): Removal of instance 'pandas' from the runtime-images schemaspace is not permitted!
[W 2022-02-14 07:18:24.837 ServerApp] 403 DELETE /notebook/kf-development/elyra-3-6-0/elyra/metadata/runtime-images/pandas?1644823104409 (<IP_ADDRESS>) 2.38ms referer=https://xxxxxxx/lab/workspaces/auto-b

In a similar vein, are we considering adding a "runtime image catalog" feature as we have for pipeline components?

The images that come out of the box are considered system-owned and cannot be deleted.  They can be updated, in which a copy is made and persisted to the general user location.  Those updated copies can be deleted, but the originals can't.

In a similar vein, are we considering adding a "runtime image catalog" feature as we have for pipeline components?

No, but that's an interesting thought.   I'd love to figure out a way to NOT have "system-owned" behaviors.
Perhaps introducing the notion of "metadata packages" could be interesting, where a package includes pre-built instances.  I think we'd need something like - if the instance already exists, it is not installed.  This would allow for updates to override the packaged instance.  The problem would then be how to not re-install a deleted pre-packaged instance.  So you'd probably have to record installation at a package level, but then have a mechanism for introducing new instances when a new version is made, etc.
Hmm, we'd also have to figure out the expected behavior for when someone removes a metadata package.  Do the instances remain?  Or only those instances that have been updated (implying a checksumming/hash registry), etc.?

For reference: For source code Elyra builds its possible to customize which images are system-owned images by modifying the content of https://github.com/elyra-ai/elyra/tree/master/etc/config/metadata/runtime-images

Another possible alternative: Perhaps we could introduce a configuration setting that, if defined, causes the metadata service to ignore system-owned entries. This way these entries would not be listed in the UI or CLI. This would not change the default user experience and require an explicit action by the entity that installs Elyra, but does not require a custom-built Elyra.  wdyt @kevin-bates @kiersten-stokes?

This would be a matter of constraining the multiple paths to the preferred directory when gathering the paths to use.  That said, I'd love to find a different (and optional) way of exposing these system-owned instances, but prior to that, a configurable for this makes sense.
Things get a little trickier if this needed to be done at a schemaspace level, but that doesn't appear to be the case since runtime-images are the only schemaspace we provide instances for out of the box.

That said, I'd love to find a different (and optional) way of exposing these system-owned instances, but prior to that, a configurable for this makes sense.

An approach similar to the one we are currently using for connectors should be able to address not just the symptom (there are metadata instances the user has no need for - which my earlier alternative would do) but would also support customization:

create and publish a package, comprising primarily of the resources (system-owned metadata definitions => JSON code) and glue code that supports a new entrypoint
the Elyra-provided package is declared as an optional extra that is included during pip install elyra[all], mirroring the current out of the box behavior ("there are preconfigured instances")
at installation time one can decide wether or not to include the extra (by [not] installing the dependency)
the metadata behavior would not change - these instances would be treated the same way they are today (can't be removed via the GUI or CLI)
if desired, one could create a custom pip-installable package version

yeah, this is probably better, although, today, we can edit system-owned instances where the "edited instances" are stored in the user's location - rather than sys.prefix.  It's that behavior I'd really like to figure out how to address (i.e., remove).  If we say these are read-only, then I think adding a meta-behavior that indicates a given instance is system-owned might be an improvement as the instances can then live next to user instances.
Another thought might be to introduce Bring-Your-Own-Instances where the Schemaspace class loads entrypoints relative to itself and those entrypoints provide instances.  I think BYO instances would be used where common deployments are necessary.  The behavior could be that if the BYO instances are only created.  This would allow for modifications to the instance to survive server restarts.  The issue there is that any deleted instances would get revived, so it would be nice to figure out a way to address that.

Perhaps we should reevaluate whether this system-owned RTI metadata is even necessary. If I recall correctly, system RTIs were provided to provide a smother up-and-running experience. My thoughts:

For container based deployments, pre-seeded container images can be provided through other means:

publish -slim image (e.g. elyra-slim), which don't have any RTIs pre-defined. Users can extend this image FROM ..../elyra-slim and add elyra-metadata install runtime-images ..., specifying their own images.
publish elyra image, which extends above image using a small set of images (a subset of what we include today)

Pre-seeded RTI metadata is useful for getting started scenarios, but in many cases it'd be just one additional step to add it to an Elyra instance that doesn't have it defined. (Additional tutorial artifacts can be provided to create the metadata on as as needed basis. For example, https://github.com/elyra-ai/examples/tree/master/pipelines/dax_noaa_weather_data only requires one RTI instance to be fully functional.)
As  is, system-owned RTIs don't really solve many problems: (1) users can overwrite them and (2) users can add/use their own, hence the mechanism does nor enforce any restrictions that an admin might want to impose.

This would be great!  It does seem like most of this could be handled via documentation and within images we provide - as you mention.  System-owned metadata is also problematic for other storage solutions (which we don't have at the moment, but will be an immediate problem when that does occur).
We could also document how users could export/import the images they wish to retain.  (Of course, we'd need the necessary import functionality in place, but I'm assuming this (removal of system-owned RTIs) is something slated for 4.0.)

We could also document how users could export/import the images they wish to retain. (Of course, we'd need the necessary import functionality in place, but I'm assuming this (removal of system-owned RTIs) is something slated for 4.0.)

Yep. Metadata import should be available no later than 3.8. We could also add the current files to the examples repository or document the corresponding CLI commands, which are straightforward for RTIs.


Four-space tabs?

I'm loathe to suggest this, because I am a two-space tab jihadi, but I think we should switch to four-space tabs. When pairing with @neunenak, his editor defaulted to four space tabs, and we had to figure out how to switch to two space tabs, but I think we didn't figure out how to, and we just used rustfmt, which didn't work within macros. It's super minor, but we could make it marginally easier to contribute by just using four-space tabs.
@soenkehahn What do you think?

I don't actually think switching the convention is all that important to do - the things going with my editor were unrelated to the tab size specifically, and like I mentioned I deliberately set my editor's tab size to 4 spaces only because the last rust project I was working on used that convention, I was using 2 spaces before that. In general I don't expect to get every formatting detail correct if I'm working on a new project - that's what cargo fmt is for, and it's fine if people just run that before their final commit. I think either 2 or 4 spaces is a reasonable default and I'm indifferent to which one gets picked.

I don't have strong opinions. Four tabs is the rustfmt default, which is a (weak) advantage. :shrug:

I ran a poll on Reddit, which, since everyone likes to have opinion on indentation, attracted a lot of activity:
https://www.reddit.com/poll/r2kpdm
The final tally was 1.2k in favor of switching to 329 in favor of not switching. I don't think that it should be given a huge amount of weight, but it's at least some evidence in favor of switching.
Most arguments against switching were that it would create merge conflicts and that it would cause git blame to be less useful.
There aren't many inbound PRs, so I don't think merge conflicts will be that bad, and can be easily resolved by formatting with the new indentation width before merging.
Git blame not being useful, at least for a while, is unfortunate, but maybe not such a big deal.


manifests: updaters should NOT run in the control plane

tune the manifests to make sure RTE does NOT run in the control plane

the control plane has taints already to prevent daemonset in general to run on these nodes unless they have specific tolerations - which we don't, intentionally. So it seems we're good here? Let's reopen if new evidence, of bugs, arise.


chore(deps): allow new versions of react and react-dom

Similar to #8, this allows newer versions of react and react-dom in a slightly more confined way (and shouldn't require a major bump).
@jeremiahrhall #8 is pretty outdated at this point. I'd recommend merging this, which I don't think would require a major bump and closing out #8.
BTW I'm also not sure if you need the react-dom peer dep as it's only used in the example but no where within the actual codebase. Most other react packages I've seen don't specify both anymore unless they explicitly use react-dom. Happy to remove this as well if you're comfortable with it.

Hi @skipjack! You're likely right about react-dom being only necessary in devDependencies. If you increment the version in package.json, update the changelog, and move that to devDependencies I'll test, merge and publish these changes.

@jeremiahrhall all done, thanks for jumping on this! Btw I highly recommend the standard-version package and conventional commits convention to achieve automated version bumping and changelog management based on commit messages.


bugfix a compile error about struct initialization on Arduino IDE

Detail of error condition
Following error happens in case of compiling source code on Arduino IDE.
console.h:94:37: error: too many initializers for 'mrbc_printf_init(mrb_printf*, char*, int, const char*)::RPrintfFormat'
   pf->fmt = (struct RPrintfFormat){0};
                                     ^

Reason of the error
Arduino IDE use "g++" even if the source code is "*.c" file.
In that case, the inner struct which is defined in a top struct cannot be referred out of the top struct.
Detail of fix
Move the definition of the inner struct to out of the top struct.

Thank you for fixing it.


Licensing / monetization future decisions

have written up tentative plans here
Would love to hear ideas from @szepeviktor about how to manage keeping repos clean and including Freemius SDK & markup in the wp.org builds (or tell me it's all a terrible idea!)

Do I understand correctly?
Adding Freemius WP SDK to the plugin at release time?

Do I understand correctly?
Adding Freemius WP SDK to the plugin at release time?

Yes, that was the idea:

have my wp.org plugins contain freemius for payment
but keep repos free of the SDK code, allowing people to continue using freely from git/Packagist

I'm not great with money and struggle to ask people to pay for my stuff. Patreon is slowly building up, but not enough to cover minimal expenses. I figure if I can keep the projects free and open source, but ask for $ from those who want/need the convenience of wp.org listings and simple installation, it may be the right balance.
If only there were automated tests for life!

Yes, that was the idea:

have my wp.org plugins contain freemius for payment
but keep repos free of the SDK code, allowing people to continue using freely from git/Packagist

I'm not great with money and struggle to ask people to pay for my stuff. Patreon is slowly building up, but not enough to cover minimal expenses. I figure if I can keep the projects free and open source, but ask for $ from those who want/need the convenience of wp.org listings and simple installation, it may be the right balance.
If only there were automated tests for life!

@leonstafford that could be easier than you think.
Freemius is automatically parsing your code and provide a free version and pro version of your plugin.
There is also a composer package available: https://packagist.org/packages/freemius/wordpress-sdk
So you can still provide a development version on Github without having users to hassle around with licensing,
include the package only on builds for w.org and add a constant or another indicator for the prefix_fs() function to run.
That's pretty much the same way I will do it with Simply Static ;-)

@leonstafford that could be easier than you think.
Freemius is automatically parsing your code and provide a free version and pro version of your plugin.
There is also a composer package available: https://packagist.org/packages/freemius/wordpress-sdk
So you can still provide a development version on Github without having users to hassle around with licensing,
include the package only on builds for w.org and add a constant or another indicator for the prefix_fs() function to run.
That's pretty much the same way I will do it with Simply Static ;-)

@patrickdk77 that will be brilliant, thanks! I'll give it a try

@patrickdk77 that will be brilliant, thanks! I'll give it a try

I'd be happy to pay for a premium version tbh. I've paid for themes and a variety of other plugins here and there, so one that I can really leverage for a static site is worth the money. Always happy to pay for something that'll be refined and developed over time with more options and error handling/feedback :) I'd always pick that over something promising that gets abandoned because the author needs to eat!

I'd be happy to pay for a premium version tbh. I've paid for themes and a variety of other plugins here and there, so one that I can really leverage for a static site is worth the money. Always happy to pay for something that'll be refined and developed over time with more options and error handling/feedback :) I'd always pick that over something promising that gets abandoned because the author needs to eat!

Thanks @petewilcock! Eating less a concern for me, can probably survive on my body fat for a year :D Shelter is the kicker here in Australia. Still holding off on going Freemius route for now, but will definitely be submitting plugins to wp.org repo. I re-enabled other donation options besides Patreon, which has brought in a few more $ already this week. Also working on a job app for a WP engineer role nearby, which could definitely help take the pressure off.

Thanks @petewilcock! Eating less a concern for me, can probably survive on my body fat for a year :D Shelter is the kicker here in Australia. Still holding off on going Freemius route for now, but will definitely be submitting plugins to wp.org repo. I re-enabled other donation options besides Patreon, which has brought in a few more $ already this week. Also working on a job app for a WP engineer role nearby, which could definitely help take the pressure off.


iosched_2020 code

iosched_2020 code  pulled from https://github.com/google/iosched/compare/iosched_2020...main

Pulled code, from iosched_2020 branch to my repository
from https://github.com/google/iosched/compare/iosched_2020...main

testing after re-opening pull request


Subscriber context and Context range

How to give the context of the Subscriber?
var s = new Subscriber({
    callback: ...,
    context: o
});

var c = new Context({
    range: [
        {component: s, context: o}
    ]
});

If I give the context in the second one, it will be DRY, and it will be probably in conflict with the first one. Should Subscribers work without Context? What about wrappers?
var o  = {
    s: new Subscriber({
        callback: function (){}
    }).toFunction()
}

I don't think it is obligatory to have Subscriptions without Contexts. The single disadvantage of this choice that Subscriptions will be mapped to context objects. So they won't be reusable with wrappers.
What about wrapper Context? It can be delivered to the Subscriber.

The real problem that Subscriber.receive(Context context, args) does not hold the context object of the callback. So we cannot do a callback.apply(context.clone(contextObject), args).

I think we have to move the Subscriber context to Subscription.
new Subscription({
    publisher: o.p.component,
    subscriber: o.s.component,
    context: o
});

We have 2 options:
1.)
subscriber.receive(context, args, o);

2.)
subscriber.wrapper.apply(context.clone(o), args);

By the second one receive would be non-existent, or it would never called directly.

So what happens by publisher.publish? It calls subscription.notify which calls: subscriber.wrapper.apply(context.clone(o), args).
What is the case by calling the wrapper?
o.w(arg1, arg2, ...) -> subscriber.receive(var c = clone(Context), args, c.getClone(o)) or something like this. So instead of calling the wrapper, we can keep the receive methods with 3 params (which is not recommended, but who cares)
What if there is no context given? Should it relay publisher context or should it use null?
I think it should relay publisher context.

Added a basic context relaying code. Cloning with Context is not supported yet. I'll implement Subscriber wrapper now.

So from now it will be possible to: subscriber.receive(context, args, o). We have choices here as usual:

subscriber.receive(context, args, o) and o.wrapper(args) creates a new Context so the context.cloneContext(o) can be called in the receive
subscriber.receive(args, o) and o.wrapper(args) where the wrapper creates the new Context and the wrapper and Subscription call the context.cloneContext(o)

So where should I clone the Subscriber context? In the Subscription.receive or in the wrapper and the Subscription?
Cloning in the Subscriber.receive appears to be a better option.

Where should I clone the Subscription?

Should I clone it in Subscription.notify? subscription.notify(args, o, context) and if (this.context !== context) return context.cloneContext(this).notify(args, o, context)
Should I clone it in the Publisher? context.cloneContext(subscription).notify(args, o)

By both the second one seems to be better, so

Subscriber context should be cloned by its wrapper and by the Subscription
Subscription should be cloned by Publisher

I don't think it is possible to make this loosely coupled, so all 3 classes have to contain code related to Context instantiation and cloning by using the Context instance.

I'll use the Stack word instead of Context hereafter.
How to add the Subscriber and the context to the Stack range?
var subscriber = new Subscriber(...);
var subscription = new Subscription(publisher, subscriber, o1);
var stack = new Stack(range: [publisher, subscriber]); //???
publisher.toFunction().call(o2, 1, 2, 3);

// in Publisher
// var c = stack.clone();
// var s = c.getInstance(subscription);
// s.notify([1, 2, 3], o2);

// in Subscription:
// var o = c.getInstance(o1);
// subscriber.receive([1, 2, 3], o);

So the Stack range contains only the Components here and not the contexts. The Subscription is an interesting thing here... I think it should be cloned always by the Publisher. After that it can check the Subscribers whether they are in the same Stack. If they are then the context will be cloned by the same Stack if not, then another Stack must be selected by the StackSelector to do the job.

We can continue the #48, some of the questions are answered.


Linking against the dart-sdk shipped with Flutter

Flutter (Channel master, 1.25.0-5.0.pre.144, on Microsoft Windows [Version 10.0.19041.630], locale de-DE)
I'm currently developing a small Flutter plugin that requires acces to Dart_PostCObject_DL() to send a message from a different thread back to Flutter.
So I added the dart-sdk shipped with flutter to my CMakeLists.txt in my windows plugin folder:
get_filename_component(DART_SDK_PATH "cache/dart-sdk/"
                       REALPATH BASE_DIR "$ENV{DART_SDK}")

add_library(${PLUGIN_NAME} SHARED
  "${SRC_ROOT}/ffi.cpp"
  "${DART_SDK_PATH}/include/third_party/dart/dart_api_dl.c"
)

set_source_files_properties("${DART_SDK_PATH}/include/third_party/dart/dart_api_dl.c" PROPERTIES LANGUAGE CXX )

$ENV{DART_SDK} points to the bin folder in my flutter installation directory.
And this works, builds and I can post messages between dart isolates and threads back and forth all day long.
The issue is that I have to duplicate the folder "runtime" and rename it to "internal" because dart_api_dl.c looks for dart_api_dl_impl.h in internal.
Should we even use the included SDK or is it better to roll our own copy within the plugin?

dart_api_dl.c and dart_api_dl_impl.h are designed to be copyable.
In general when you publish a plugin, it might be linked against a different version of the DartVM. Whether you distribute a compiled shared object or push the copied sources to a repo, in both cases you can encounter another version of the DartVM than that you were developing the plugin for. dart_api_dl.c contains versioning internally to check whether the DartVM it is dynamically linked against is compatible with it.
Note that if you're writing the C code yourself and publishing a Flutter app directly, you wont encounter this version skew. In this case you could link against the files in the Dart SDK, but copying them is fine as well. The versioning will warn you if you ever need to update them.

Works for me. Thank you.


mod_ssl vs PHA - unable to consume non-appdata records

With older OpenSSL/TLS versions, mod_ssl was able to do:

        SSL_renegotiate(ssl);
        SSL_do_handshake(ssl);
        SSL_peek(ssl, buf, 0);

to trigger and complete a renegotiation to request a client cert.
There doesn't seem to be any way to do this with 1.1.1pre9 and PHA.  mod_ssl can now do:

        SSL_verify_client_post_handshake(ssl);
        SSL_do_handshake(ssl);

And the CertificateRequest gets sent to the client.  If the server does not call SSL_peek(), OpenSSL does not wait for a Certificate message.  If it does call SSL_peek(), it appears to wait to actually consume some app_data, when none is (necessarily) expected at this point in the HTTP connection.
As discussed in this thread https://marc.info/?l=openssl-dev&m=145546707418497&w=2 what mod_ssl really needs is an API to ask OpenSSL to read/consume/process non-appdata records which are available from the bio but then return control to the application.  Is something like this possible?

And I actually think that the SSL_peek() with zero length (possibly also ignoring the buffer argument) should semantically do exactly that. And if it does not with 1.1.1 I would consider this to be a bug.

Does calling SSL_clear_mode(ssl, SSL_MODE_AUTO_RETRY) before the peek help at all?

BTW, note that a client is not obligated to immediately respond with a response. It could come back with application data first, before the requested certificate.

Adding SSL_clear_mode(ssl, SSL_MODE_AUTO_RETRY) before the peek seems to work.  Testing further but this looks promising, thanks!
With HTTP/1.1 the problem of app data at this point in the protocol has always been there and never been possible to solve completely server-side without some protocol change, I don't know if was addressed in HTTP/2.

See:
https://github.com/openssl/openssl/blob/a4a90a8a3bdcb9336b5c9c15da419e99a87bc6ed/CHANGES#L121-L130
I'm wondering if this might give you an issue in your TLSv1.2 code.

It looks like mod_ssl can/should turn off AUTO_RETRY by default, it is designed to cope with SSL_read() returning SSL_ERROR_WANT_READ.  Can you expand on why this might matter for TLSv1.2?
Also, apologies for overloading this ticket with random questions, but the specific semantics of SSL_VERIFY_MODE_HANDSHAKE are not really clear from the man page.  If it is optional, what difference should it make and why/when should it be set?

It looks like mod_ssl can/should turn off AUTO_RETRY by default, it is designed to cope with SSL_read() returning SSL_ERROR_WANT_READ. Can you expand on why this might matter for TLSv1.2?

With AUTO_RETRY on, if you attempt to read application data but actually get handshake data then it will process the handshake data and then immediately try again to get application data. You saw this as a hang in the SSL_peek() call in TLSv1.3. But you also have an SSL_peek() call in TLSv1.2 so the same should occur there AFAICT.

Also, apologies for overloading this ticket with random questions, but the specific semantics of SSL_VERIFY_POST_HANDSHAKE [edit: fixed typo] are not really clear from the man page. If it is optional, what difference should it make and why/when should it be set?

Before the handshake starts if you set SSL_VERIFY_PEER then it will attempt to obtain a cert from the client during the handshake unless you also set SSL_VERIFY_POST_HANDSHAKE. By setting both you can set everything up before the handshake starts and forget about it. Alternatively you can set neither before the handshake starts, and just set SSL_VERIFY_PEER later on.

Thanks for your help @mattcaswell - I think we have ironed out all the 1.1.1 issues in mod_ssl other than the fact that PHA is broken by default as covered in the other ticket.  I'll close this.


Should class MatchKey method __getitem__ return value of _?

https://github.com/p4lang/p4runtime-shell/blob/main/p4runtime_sh/shell.py#L357-L359
    def __getitem__(self, name):
        _ = self._get_mf(name)
        print(self._mk.get(name, "Unset"))

I do not know if _ has a special meaning in Python, but is the intent here to do return _ at the end of this method?

The function self._get_mf is called for the single purpose of validating that name is a valid match field name for this table (i.e., that it is part of the match key). If it's not the case, it will raise a Python exception: https://github.com/p4lang/p4runtime-shell/blob/4bc4cd5c6b86a9669e5d6102da5c86ff0c0917ce/p4runtime_sh/shell.py#L348-L350.
(Technically some subset of suffixes is supported for each match field if you look at _get_mf in details)
The Python exception will then be translated into a user-facing error message.
The statement _ = self._get_mf(name) could be replaced by self._get_mf(name), but I think whoever wrote the code wanted to make it clear that there is a return value but that we are deliberately ignoring it. Some code linters which warn about unused function return values prefer _ = self._get_mf(name) to self._get_mf(name).

  This __getitem__ method always returns None, I believe, which is not useful.
After experimenting a bit more, it seems to me that changing the print(...) to return ... would be quite useful.  Even more useful if the name lookup used the abbreviations table if the name is not a full match field name.


Bug Report: OGL sync object memory leak

Describe the bug
Critical memory leak for OGL debug builds
Reproduction

Repros On: everything (e.g tz_terrain_demo)
Repro Type: unexpected behaviour: memory leak
Repro Rate: every time
Repro Severity (how badly does it affect your bottom line): high
Repro Steps
Steps to reproduce the bug:

Run any demo or game on OGL debug
View memory usage of application increase very quickly, especially with high fps (e.g task manager on windows)

Expected behavior
No memory leaks would be nice thanks
Screenshots
N/A
Conditions (please complete the following information):

OS: windows
Render API: opengl
Build Config: debug
Version: master
Compiler: gcc

Additional context
Connor: "shit was fucked"

https://github.com/Harrand/Topaz/blob/737ea1432b702f751ca6d3716b2571469c1dce77/src/tz/gl/impl/frontend/ogl2/renderer.cpp#L591
Didn't glDeleteSync aaaaaaa
https://registry.khronos.org/OpenGL-Refpages/gl4/html/glDeleteSync.xhtml

Fixed in 85308766c122e2e20410af7452a347e4e2a511c1


MLFlow Additional Config

PR for issue #1561
What is being addressed

Missing conda package to allow MLFLow to work with conda
Missing pip package azure-identity
Reformat MLFlow config scripts
Additional Documentation

How is this addressed

Nexus configured to proxy conda-forge.
Additional Nexus documentation to highlight all currently configured repos.
User resources altered to configure conda to use proxied conda-forge channel on deployment
MLFlow inline scripts moved to template files and rendered at runtime.
Additional pip package added to config script
Additional MLFlow documentation to highlight use case with conda-forge.

/test

/test-force-approve


getting warning from three.js on every tick that seems to crash page if console is up

My project seems to be working in quest, I essentially made the changes described in my 'documenting' issue, however, when I open my project on desktop now, I see this warning from THREE:
THREE.Quaternion: .inverse() has been renamed to invert().

on loop, infinite, seemingly at the pace of a requestAnimationFrame() call, and the first time I sat there watching it it eventually crashed my computer entirely which did a hard reset on its own suddenly.
I assume it's only a problem while the console is open, but not sure yet, haven't run oculus in adb bridge with console open since I've added this yet, but if I do and notice it there still, I'll update here... but given the message being logged, I imagine I would see it there if log was open too.

I just realized that it's from the physics repo, not here, so I'll open an issue there I guess.

nverse | @ | three.js:37223
-- | -- | --
  | Body.syncFromPhysics | @ | aframe-physics-system.js:17403
  | step | @ | aframe-physics-system.js:17280
  | tick | @ | aframe-physics-system.js:19025
  | tick | @ | a-scene.js:746
  | render | @ | a-scene.js:790
  | bound | @ | bind.js:12

I just realized that it's from the physics repo, not here, so I'll open an issue there I guess.

nverse | @ | three.js:37223
-- | -- | --
  | Body.syncFromPhysics | @ | aframe-physics-system.js:17403
  | step | @ | aframe-physics-system.js:17280
  | tick | @ | aframe-physics-system.js:19025
  | tick | @ | a-scene.js:746
  | render | @ | a-scene.js:790
  | bound | @ | bind.js:12

I followed this wormhole... it's really nothing the physics repo could do--I mean, yes, they can update to be compatible with latest version of A-Frame...
...but A-Frame should block the THREE logs...
...and THREE should make that easy and handle that itself...
...but I just read for hours arguments taking place over years on the THREE repo, and mrdoob basically refuses to do this. As I just posted there on the last one I saw, it's like reading a kafka novel.
Anyways, going to go add a console hack to block THREE messages and let the physics library maintainer know he needs to update so console.warn in tick() doesn't cause implosions, I guess. :/

I followed this wormhole... it's really nothing the physics repo could do--I mean, yes, they can update to be compatible with latest version of A-Frame...
...but A-Frame should block the THREE logs...
...and THREE should make that easy and handle that itself...
...but I just read for hours arguments taking place over years on the THREE repo, and mrdoob basically refuses to do this. As I just posted there on the last one I saw, it's like reading a kafka novel.
Anyways, going to go add a console hack to block THREE messages and let the physics library maintainer know he needs to update so console.warn in tick() doesn't cause implosions, I guess. :/


Store Pickup Notifications

A list of notifications that will move the Store Pickup workflow forward. Throughout the store pickup process, there will key points of contact between the store and the customer. The goal of this communication is to ensure a easy and timely pickup.
Customer Notifications (Managed in Order Settings)
Order Placed- This notification is triggered when the Order is created. This notification confirms that the order has been received. It will include the following:

Target Pickup Time: A date a time calculated from the Order Creation Date and the Expected Pickup Time for the Location
Pick Up Deadline: A date and time calculated from the Order Creation Date and the Pickup Deadline for that Location
Order Pickup Waiting Instructions - Includes information on what a customer should do while they wait for the order to become ready, including perhaps instructions on checking the order status
Ready for Pickup Instructions - Location and fulfillment method specific instructions on how the order is to be picked up when it is ready
Order Changes and Cancellation Instructions - Information on how a customer should go about cancelling or editing their order

Ready for Pickup- This notification is triggered when the Order Pick Status changes to Ready For Pickup

Pickup Deadline
Ready For Pickup Instructions
Order Changes and Cancellation Instructions

Pick Up Complete / Order Closed - This notification is triggered when the Order Pick Status changes to Pickup Complete

Receipt
Order Complete Information (may include info about returns etc)

Not sure whether we should have stories for these notifications in the Kinetic repo but wanted to capture the requirements around Notifications in an Epic for future reference


refactor: move consumer config to cronsumer struct

We don't need to given Kafka consumer config parameter multiple times on Consumer interface

Thanks 👏🏻


Lambda + SQS examples/best practices

Is there an existing issue for this?

[X] I have searched the existing issues and read the documentation

Question
Are there any examples or guides around best practices when using Lambdas and SQS queues?
In our case we need to access the related SQS queues both from localhost and from the Lambdas, but what we are doing seems rather complex. We are using LocalStack through TestContainers and we configure LocalStack as follows:
final Network network = Network.newNetwork();

final LocalStackContainer localStackContainer = new LocalStackContainer(DockerImageName.parse("localstack/localstack:0.14.3"))
    .withEnv("LAMBDA_EXECUTOR", "docker")
    // network name is generated as random uuid inside NetworkImpl
    // but the Network interface does not have a method to get name so we need to cast
    .withEnv("LAMBDA_DOCKER_NETWORK", ((Network.NetworkImpl) network).getName())
    .withEnv("HOSTNAME_EXTERNAL", "localhost")
    .withNetwork(network)
    .withNetworkAliases("localstack")
    .withServices(LAMBDA, SQS);

Then we create the necessary SQS queues through an AWS SQS client and retrieve their URL.
Then we pass the URLs to Lambdas through environment variables when creating them, but for the Lambdas to use the right URLs we need to do the following:
url
    .replaceAll("localhost:\\d+", "localstack:4566")
    .replaceAll("<IP_ADDRESS>:\\d+", "localstack:4566");

Is there a simpler way? Thanks.

with the new lambda provider of 2.0, SQS endpoint resolution now works out of the box when using SQS_ENDPOINT_STRATEGY=domain. This vastly simplifies the configuration, and have added a short section on this to the SQS docs: #731.


All API calls getting 401 error before successfully making an API call

All API calls get 401 error before returning successful call:

There is middleware in src/utils/httpClient.tsx that seems to be mishandling the token refresh. Ensure that calls to the API contain the correct access token and ensure the access token being stored in local storage is the correct token.

resolved with merge #6


Fixes#1594 Replace edittext by searchview for search feature.

Fixes#1594 Replace edit text by searchview for the search feature.
Description
Fixes#1594 Replace edit text by searchview for the search feature.

removed code for edittext
added code for searchview and modified it a little bit like hiding underline, searchicon.

Tests performed
Manually Tested on API25 with Moto G5S+, with ProdDebug variant.
Screenshots showing what changed

Codecov Report

Merging #1595 into browse-commons-via-app will decrease coverage by <.01%.
The diff coverage is 0%.

@@                    Coverage Diff                    @@
##           browse-commons-via-app   #1595      +/-   ##
=========================================================
- Coverage                    3.79%   3.79%   -0.01%
=========================================================
  Files                         154     154
  Lines                        7727    7730       +3
  Branches                      716     716
=========================================================
  Hits                          293     293
- Misses                       7417    7420       +3
  Partials                       17      17

Impacted Files
Coverage Δ

...va/fr/free/nrw/commons/explore/SearchActivity.java
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Fixes mobile Organization list and desktop list styling

Fixes and closes issue #865 .
If no organizations are present, the Organization menu item is removed.

Merged this, revisit if needed.


test(e2e): load test improvements

Context
Looking for a good test to stress the transaction submission, we found that the tx submissions load test could be a good candidate, but it needs some fixes/improvements.
Important Changes Introduced

removed the try/catch block around the body of the test which was hiding test failures
coins are now self sent to the same account to avoid the too many inputs error in subsequent test runs (with high TRANSACTIONS_NUMBER)

It would be good to add example .env file for this test


PRO-3118 Change timestamp format from milliseconds to seconds in veri…

…fier

@michelleinez LGTM, but given that we're now parsing data based on whether it's a date, it may be that there needs to be a test update


Firefox drag and drop redirect into nowhere

Hi
Our team faced with issue that when you try to connect one connector into nothing (to any place on the page where no other object or edges) it redirects you to about:blank url in Firefox.
Please could you provide us a way how to prevent it because as I know there is no way to add any logic to drag events callbacks.

Reproduces only in Firefox on any OS.
Thank you in advance.

Are you sure this relates to this library?
I've never seen this UI.

I'm so sorry, we have dependency ngFlowChart and I was pretty sure that this is just angular implementation of your library but it looks like not.
Sorry


Webhook error

Hello, I'm trying to hook a deploy but it's not working, here are the logs:
Access.log
<IP_ADDRESS> - - [16/Mar/2015:18:07:36 -0300] "POST /projects/1/build?token=37cOBFUSCATEDbca0 HTTP/1.1" 502 568 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36 FirePHP/4Chrome"

Error.log
2015/03/16 18:07:36 [error] 1795#0: *1626 upstream prematurely closed connection while reading response header from upstream, client: <IP_ADDRESS>, server: ci.renatomefi.com.br, request: "POST /projects/1/build?token=37cOBFUSCATEDbca0 HTTP/1.1", upstream: "http://unix:/var/opt/gitlab/gitlab-ci/sockets/gitlab.socket:/projects/1/build?token=37cOBFUSCATEDbca0", host: "ci.renatomefi.com.br"

How can I check the application log?
Thank you for any help!

I forgot to inform the version, it is Omnibus 7.8.1

I hope it will help you https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/logs/logs.md


Windows 10 Bluetooth LE support (No Dongle)

Hey, I started a rewrite of https://github.com/jasongin/noble-uwp using the C++/WinRT API in https://github.com/Timeular/noble-winrt
Any interested in merging this in?
Thanks to Timeular for sponsoring my work on this.

Hello i tried your module but seems does not work properly with some devices, if you want we can see what is the problem

@fedyfausto Please open an issue with the details at Timeular/noble-winrt. Thank you!


HADOOP-16376. ABFS: Override access() to no-op.

Contributed by Da Zhou.
Change-Id: Ia0024bba32250189a87eb6247808b2473c331ed0

@steveloughran
cherry picked from trunk
All tests passed for my west us account:
non-xns account
Tests run: 35, Failures: 0, Errors: 0, Skipped: 0
Tests run: 383, Failures: 0, Errors: 0, Skipped: 207
Tests run: 168, Failures: 0, Errors: 0, Skipped: 15
xns account
Tests run: 35, Failures: 0, Errors: 0, Skipped: 0
Tests run: 383, Failures: 0, Errors: 0, Skipped: 23
Tests run: 168, Failures: 0, Errors: 0, Skipped: 21

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
16
https://github.com/apache/hadoop/pull/988 does not apply to branch-3.2. Rebase required? Wrong Branch? See https://wiki.apache.org/hadoop/HowToContribute for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hadoop/pull/988

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-988/1/console

versions
git=2.17.1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

missed this
+1

@DadanielZ I'm happy with this PR if you can rebase it to trunk and reapply.

Actually this is no longer needed and has been updated already, I will close this comment.
@steveloughran Thanks anyway :)


fix link

Thanks for reporting, I caused the owner to reconsider his url and not applied the change in my own docu, shame on me.


Move CRA demo

is this going to be followed up by a removal of cra demo from FluidFramework?

is this going to be followed up by a removal of cra demo from FluidFramework?

Yep, we can remove it from FF once we have it checked in here to avoid having the same code in two places


[parser] Fix invalid tuple type round-tripping issue

public init(a: (b || c)) became public init(a: )(b || c) after round-tripping.
Resolves rdar://problem/55280477

@swift-ci please test


How to install in Directus CMS

I'm trying to install and use this hooks on a Directus (v9 - the node version) project.
Can't get it to load properly. I'm following the steps and import knex-hooks in the database file. When running it throws some errors:
npm run dev
[ERROR] 15:07:56 ⨯ Unable to compile TypeScript:

src/database/index.ts:53:10 - error TS2339: Property 'addHook' does not exist on type 'Knex<any, unknown[]>'.

53 database.addHook('before', '*', '*', (when, method, table, params) => {
            ~~~~~~~
src/database/index.ts:53:39 - error TS7006: Parameter 'when' implicitly has an 'any' type.

53 database.addHook('before', '*', '*', (when, method, table, params) => {
                                         ~~~~
src/database/index.ts:53:45 - error TS7006: Parameter 'method' implicitly has an 'any' type.

53 database.addHook('before', '*', '*', (when, method, table, params) => {
                                               ~~~~~~
src/database/index.ts:53:53 - error TS7006: Parameter 'table' implicitly has an 'any' type.

53 database.addHook('before', '*', '*', (when, method, table, params) => {
                                                       ~~~~~
src/database/index.ts:53:60 - error TS7006: Parameter 'params' implicitly has an 'any' type.

53 database.addHook('before', '*', '*', (when, method, table, params) => {

I guess Directus can't load the module. All the other node_modules have a different structure.
Anyone got this to work, in any project type?

Hey, knex-hooks is missing typescript declarations and this is why TS can't compile your code because it does not know that knex is pacthed and have new method "addHook".
For now you have to manually declare knex method addHook(...) in your code.

Hi!
Thanks for getting back to me in this issue. Sorry for my late response...
I'm not sure I understand. Could you please give me som more simple info/guides on how to setup these hooks (and helpers) in a Node (Express) project like Directus v9?
Big thanks!


Resteasy 1776: Sse feature should only be enabled when resource method only produces "text/event-stream" and is injected with @Context SseEventSink

This pull request introduce the concept of SSE resource method as described in the specification:

9.3 Server API
...
A resource method that injects an SseEventSink and produces the media type text/event-stream is an
SSE resource method.

It helps to fixe issues listed in https://issues.jboss.org/browse/RESTEASY-1776

Thanks to the tests failing I found out that there was a resteasy specific kind of SSE resource method like that:
   @GET
   @Path("sse")
   @Produces(MediaType.SERVER_SENT_EVENTS)
   public Publisher<String> sse() {
	   return Flowable.fromArray("one", "two");
   }

So I updated the ResourceMethodInvoker.isSseResourceMethod(ResourceMethod resourceMethod) to take it into account.
So now conditions to be a SSE method are :

Produce only text/event-stream

Be  injected with SseEventSink parameter or a having a return type for which a org.jboss.resteasy.spi.AsyncStreamProvider is regsitered in the given application and not being annotated with any org.jboss.resteasy.annotations.Stream.

@asoldano let me know if it is acceptable.


error StickerApplication

i can't generate apk

thanks for information sir, you can re-pull latest commit for fixing the problem


Upgrade Java to 21 and Support Jakarta Namespace

Use Jakarta instead of Javax
Update dependencies to latest

Hi @mhabib-workmotion,
Thanks for this PR
Upgrade work has been done in 2023 but I did not take the time to push yet
I just published v3.0.0
It upgrades to Java 11 (not 21) to remain compatible with most applications - including mine ;)
I cherry-picked your commit so you're now a contributor even if thir PR has been closed.
Regards,
Patrice


Pin smart table to exact version - newer one breaks things for us

Validated manually with a cf push

LGTM


Non blocking warmup

Motivation
blocks grpc server causing usabilty issues
Closes #

Changes
cache warm up runs async
Test Plan
same

bors merge


Use make for running CI

Adds a Makefile with targets for each language

Looks like this isn't going to work


I'm trying for post request but getting internal server error.

TypeError: Cannot read properties of undefined (reading 'id')

without seeing the http method and url you are using, its hard to ascertain what exactly you're doing.

My guess is you don't have an id field. If you could provide better context I'm sure someone can help.

actually I've got the issue, I was using "Id" instead of "id" so it was giving this error.

@zeeshan-naseem so you opened two issues for the same problem?  Please close both of them.


Feature/audioplayer seek fix

Improves AKAudioPlayers seeking abilities:

Player is now stopped before updating buffer to remove glitchy behaviour of sound playing for some seconds when seeking an already playing track.
Playhead no longer shifts by X amount of seconds when using play play() or play(from startTime: Double, to endTime: Double) methods
internalCompletionHandler handler is now actually only called when the track plays to end and not when seeking
Remove a check in startTime setter to allow a fairly normal use case of seeking from track -> replacing file -> seeking from same spot

Thanks!


[BUG] Replacement of Eventname in discordjs 13

Describe the bug
With the newest version of discordjs the message-event got replaced by messageCreate. This causes the bot to log a deprecation warning
Expected behavior
At some places like here the event needs to be updated when using the package in combination with discord.js v13

Hi! I am plan to use "interactionCreate" instead "messageCreate" in 2 version

awesome !

any updates on this? it's the only thing that is keeping me from using this package :D


How can i make image zoomable with FadeInImage.memoryNetwork

Are there how to make image zoomable with FadeInImage.memoryNetwork?

How-to questions are better asked on StackOverflow

What about using the zoomable_image plugin?


Update mit scheme

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
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)
[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/) (I don't have an ARM64 processor, so I would appreciate it if someone who does could try this PR)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 133017 at 36b1b165 run on x86_64-linux 1

2 packages built successfully:

mitscheme
mitschemeX11

1 suggestion:

warning: maintainers-missing
Package does not have a maintainer. Consider adding yourself?
Near pkgs/development/compilers/mit-scheme/default.nix:90:5:
   |
90 |     maintainers = [ ];
   |     ^


Remove Encoding::UndefinedConversionError rescue when stashing data

This was added in #134 / 3297e7a .
My motivation for removing this special rescue is that the lines being deleted are untested, and I think they might not be needed anymore (based on the fact that I don't think that any of these errors have been logged to Rollbar recently).

^ I got code coverage to appear by reverting 739fcdfb3881b9cbe23edc0c29623b8e64fb808e , which somehow seems to break the Codecov GitHub integration (and I guess Codecov reporting in general?).
I have since removed the reversion of that commit from this PR, so I expect Codecov to stop working again.
I will follow up with a separate PR to try to fix this issue.


[CLI]:  wandb: ERROR Failed to sample metric: psutil.NoSuchProcess process no longer exists (pid=564)

Describe the bug

Hi,
I'm training a yolov5 model in colab using weights and biases for the checkpoint feature. However, sometimes I'm getting the error pasted below. This can happen at the start of the training or in middle of the training. Last time my training got killed after 130 epochs due to this error.

!python train.py --img 1280 --rect --batch -1 --epochs 200 --data /content/drive-mnt/dataset --weights yolov5s.pt --save-period 5 --upload_dataset --cache

      0/199      7.41G     0.1254      0.101    0.03192         33       1280:   0% 0/106 [00:02<?, ?it/s]wandb: ERROR Failed to sample metric: psutil.NoSuchProcess process no longer exists (pid=564)

A second issue I notice is that for some reason I cannot use --resume with yolov5 and w&b path anymore
!python train.py --resume wandb-artifact://redacted/YOLOv5/3laxf9ci

gives me
AssertionError: File not found: wandb-artifact://redacted/YOLOv5/3laxf9ci

I double checked and the path does exist in my w&b account.
Furthermore, for both issues I'm logged in correctly.
The wandb version I'm using is wandb==0.13.6
Any idea what might be causing this?
Additional Files
No response
Environment
WandB version:0.13.6
OS:Google Colab (ubuntu?)
Python version:3.8.16
Versions of relevant libraries:
Additional Context
No response

Hi @wartek69,
Do you still have access to the Google Colab runtime you were running your code on? If so, it would be great if you could share the debug.log and debug-internal.log files associated with the run here. They should be present in the wandb folder in your working directory and they will help me get greater visibility into what happened here.
Thanks,
Ramit

Hey Ramit,
Thank you for getting back to me!
The Colab, unfortunately, timed out and hence I do not have access to those files anymore..
Can you reproduce this issue on your end using collab?
I'm not doing anything fancy, just using the default yolov5 example collab and training on my own data.
Br
Alex

Hey @wartek69, I can jump in here as Ramit is out! I haven't been able to reproduce this issue by running the colab example, it's working properly for me. Could you try to run it again and send me the debug files once the issue appears? Thanks!

Hi @luisbergua,
I've retried today, same problem persists.

debug-internal.log
2022-12-16 09:23:22,920 INFO    StreamThr :431 [internal.py:wandb_internal():87] W&B internal server running at pid: 431, started at: 2022-12-16 09:23:22.919916
2022-12-16 09:23:22,927 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: status
2022-12-16 09:23:22,928 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: status
2022-12-16 09:23:22,929 DEBUG   SenderThread:431 [sender.py:send():303] send: header
2022-12-16 09:23:22,929 INFO    WriterThread:431 [datastore.py:open_for_write():75] open: /content/yolov5/wandb/run-20221216_092322-i6enghic/run-i6enghic.wandb
2022-12-16 09:23:22,944 DEBUG   SenderThread:431 [sender.py:send():303] send: run
2022-12-16 09:23:22,953 INFO    SenderThread:431 [sender.py:_maybe_setup_resume():593] checking resume status for None/YOLOv5/i6enghic
2022-12-16 09:23:23,163 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: check_version
2022-12-16 09:23:23,166 INFO    SenderThread:431 [dir_watcher.py:__init__():216] watching files in: /content/yolov5/wandb/run-20221216_092322-i6enghic/files
2022-12-16 09:23:23,167 INFO    SenderThread:431 [sender.py:_start_run_threads():928] run started: i6enghic with start time<PHONE_NUMBER>.913588
2022-12-16 09:23:23,167 DEBUG   SenderThread:431 [sender.py:send():303] send: summary
2022-12-16 09:23:23,167 INFO    SenderThread:431 [sender.py:_save_file():1171] saving file wandb-summary.json with policy end
2022-12-16 09:23:23,167 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: check_version
2022-12-16 09:23:23,204 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: run_start
2022-12-16 09:23:23,207 DEBUG   HandlerThread:431 [system_info.py:__init__():31] System info init
2022-12-16 09:23:23,207 DEBUG   HandlerThread:431 [system_info.py:__init__():46] System info init done
2022-12-16 09:23:23,207 INFO    HandlerThread:431 [system_monitor.py:start():150] Starting system monitor
2022-12-16 09:23:23,207 INFO    SystemMonitor:431 [system_monitor.py:_start():116] Starting system asset monitoring threads
2022-12-16 09:23:23,207 INFO    HandlerThread:431 [system_monitor.py:probe():171] Collecting system info
2022-12-16 09:23:23,208 INFO    SystemMonitor:431 [interfaces.py:start():168] Started cpu
2022-12-16 09:23:23,208 INFO    SystemMonitor:431 [interfaces.py:start():168] Started disk
2022-12-16 09:23:23,210 INFO    SystemMonitor:431 [interfaces.py:start():168] Started gpu
2022-12-16 09:23:23,210 INFO    SystemMonitor:431 [interfaces.py:start():168] Started memory
2022-12-16 09:23:23,211 INFO    SystemMonitor:431 [interfaces.py:start():168] Started network
2022-12-16 09:23:23,217 DEBUG   HandlerThread:431 [system_info.py:probe():195] Probing system
2022-12-16 09:23:23,225 DEBUG   HandlerThread:431 [system_info.py:_probe_git():180] Probing git
2022-12-16 09:23:23,241 DEBUG   HandlerThread:431 [system_info.py:_probe_git():188] Probing git done
2022-12-16 09:23:23,242 DEBUG   HandlerThread:431 [system_info.py:probe():241] Probing system done
2022-12-16 09:23:23,242 DEBUG   HandlerThread:431 [system_monitor.py:probe():180] {'os': 'Linux-5.10.133+-x86_64-with-glibc2.27', 'python': '3.8.16', 'heartbeatAt': '2022-12-16T09:23:23.217373', 'startedAt': '2022-12-16T09:23:22.907600', 'docker': None, 'cuda': None, 'args': ('--img', '1280', '--rect', '--batch', '-1', '--epochs', '200', '--data', '/content/drive-mnt/boat_detector_va2/boat_detector_va2.yaml', '--weights', 'yolov5s.pt', '--save-period', '5', '--upload_dataset', '--cache'), 'state': 'running', 'program': 'train.py', 'codePath': 'train.py', 'git': {'remote': 'https://github.com/ultralytics/yolov5', 'commit': '1ae91940abe9ca3e064784bb18c12271ab3157b4'}, 'email': None, 'root': '/content/yolov5', 'host': '367216192b5d', 'username': 'root', 'executable': '/usr/bin/python3', 'cpu_count': 1, 'cpu_count_logical': 2, 'disk': {'total': 78.1898422241211, 'used': 22.990428924560547}, 'gpu': 'Tesla T4', 'gpu_count': 1, 'gpu_devices': [{'name': 'Tesla T4', 'memory_total':<PHONE_NUMBER>6}], 'memory': {'total': 12.681224822998047}}
2022-12-16 09:23:23,242 INFO    HandlerThread:431 [system_monitor.py:probe():181] Finished collecting system info
2022-12-16 09:23:23,242 INFO    HandlerThread:431 [system_monitor.py:probe():184] Publishing system info
2022-12-16 09:23:23,242 DEBUG   HandlerThread:431 [system_info.py:_save_pip():51] Saving list of pip packages installed into the current environment
2022-12-16 09:23:23,243 DEBUG   HandlerThread:431 [system_info.py:_save_pip():67] Saving pip packages done
2022-12-16 09:23:23,243 INFO    HandlerThread:431 [system_monitor.py:probe():186] Finished publishing system info
2022-12-16 09:23:23,333 DEBUG   SenderThread:431 [sender.py:send():303] send: files
2022-12-16 09:23:23,333 INFO    SenderThread:431 [sender.py:_save_file():1171] saving file wandb-metadata.json with policy now
2022-12-16 09:23:23,348 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:23:23,348 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:23:23,408 DEBUG   SenderThread:431 [sender.py:send():303] send: telemetry
2022-12-16 09:23:23,607 DEBUG   SenderThread:431 [sender.py:send():303] send: config
2022-12-16 09:23:23,710 INFO    Thread-16 :431 [upload_job.py:push():143] Uploaded file /tmp/tmp55bblt2cwandb/3vhj2l54-wandb-metadata.json
2022-12-16 09:23:24,168 INFO    Thread-13 :431 [dir_watcher.py:_on_file_created():275] file/dir created: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:24,169 INFO    Thread-13 :431 [dir_watcher.py:_on_file_created():275] file/dir created: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/wandb-summary.json
2022-12-16 09:23:24,169 INFO    Thread-13 :431 [dir_watcher.py:_on_file_created():275] file/dir created: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/requirements.txt
2022-12-16 09:23:24,169 INFO    Thread-13 :431 [dir_watcher.py:_on_file_created():275] file/dir created: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/wandb-metadata.json
2022-12-16 09:23:26,168 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:32,170 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:38,448 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:23:38,449 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:23:40,173 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:41,505 DEBUG   SenderThread:431 [sender.py:send():303] send: config
2022-12-16 09:23:42,100 DEBUG   SenderThread:431 [sender.py:send():303] send: telemetry
2022-12-16 09:23:42,125 DEBUG   SenderThread:431 [sender.py:send():303] send: telemetry
2022-12-16 09:23:42,173 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:42,631 DEBUG   SenderThread:431 [sender.py:send():303] send: telemetry
2022-12-16 09:23:42,877 DEBUG   SenderThread:431 [sender.py:send():303] send: telemetry
2022-12-16 09:23:44,175 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:46,176 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:48,177 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:50,177 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:52,178 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:23:53,508 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:23:53,508 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:23:54,180 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/config.yaml
2022-12-16 09:24:08,584 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:24:08,584 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:24:23,211 DEBUG   SystemMonitor:431 [system_monitor.py:_start():130] Starting system metrics aggregation loop
2022-12-16 09:24:23,216 DEBUG   SenderThread:431 [sender.py:send():303] send: stats
2022-12-16 09:24:23,643 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:24:23,643 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:24:38,701 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:24:38,702 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:24:44,202 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:24:46,203 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:24:48,203 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:24:53,217 DEBUG   SenderThread:431 [sender.py:send():303] send: stats
2022-12-16 09:24:54,200 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:24:54,201 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:24:58,208 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:00,209 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:02,211 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:04,212 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:06,213 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:08,217 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:09,258 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:25:09,260 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:25:10,214 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:12,215 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:14,216 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:16,217 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:18,217 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:20,218 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:22,219 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:23,218 DEBUG   SenderThread:431 [sender.py:send():303] send: stats
2022-12-16 09:25:24,220 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:24,327 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:25:24,327 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:25:26,221 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:28,222 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:30,223 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:32,223 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:34,224 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:36,225 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:38,226 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:39,389 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:25:39,390 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:25:40,227 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:42,227 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:44,228 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:46,229 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:48,230 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:50,234 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:52,236 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:53,219 DEBUG   SenderThread:431 [sender.py:send():303] send: stats
2022-12-16 09:25:54,237 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:54,465 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:25:54,465 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:25:56,238 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:25:58,238 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:00,240 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:02,241 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:04,241 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:06,242 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:08,243 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:09,533 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:26:09,535 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:26:10,244 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:12,245 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:14,245 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:22,256 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:23,219 DEBUG   SenderThread:431 [sender.py:send():303] send: stats
2022-12-16 09:26:24,257 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:24,594 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:26:24,594 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:26:26,258 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:28,258 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:30,259 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:32,260 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:34,261 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:36,263 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:38,268 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:39,697 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:26:39,698 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:26:40,270 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:42,270 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:44,271 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:48,273 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:51,466 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:53,229 DEBUG   SenderThread:431 [sender.py:send():303] send: stats
2022-12-16 09:26:54,810 DEBUG   HandlerThread:431 [handler.py:handle_request():139] handle_request: stop_status
2022-12-16 09:26:54,811 DEBUG   SenderThread:431 [sender.py:send_request():317] send_request: stop_status
2022-12-16 09:26:55,512 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:56,512 INFO    Thread-13 :431 [dir_watcher.py:_on_file_modified():292] file/dir modified: /content/yolov5/wandb/run-20221216_092322-i6enghic/files/output.log
2022-12-16 09:26:57,513 INFO    MainThread:431 [internal.py:handle_exit():77] Internal process exited
2022-12-16 09:26:57,514 WARNING MsgRouterThr:431 [router.py:message_loop():74] EOFError seen in message_loop

debug.log
2022-12-16 09:23:22,908 INFO    MainThread:419 [wandb_setup.py:_flush():68] Configure stats pid to 419
2022-12-16 09:23:22,908 INFO    MainThread:419 [wandb_setup.py:_flush():68] Loading settings from /root/.config/wandb/settings
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_setup.py:_flush():68] Loading settings from /content/yolov5/wandb/settings
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_setup.py:_flush():68] Loading settings from environment variables: {'_require_service': 'True'}
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_setup.py:_flush():68] Inferring run settings from compute environment: {'program_relpath': 'train.py', 'program': 'train.py'}
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_setup.py:_flush():68] Applying login settings: {'login_timeout': 30}
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_setup.py:_flush():68] Applying login settings: {'api_key': '***REDACTED***'}
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_init.py:_log_setup():476] Logging user logs to /content/yolov5/wandb/run-20221216_092322-i6enghic/logs/debug.log
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_init.py:_log_setup():477] Logging internal logs to /content/yolov5/wandb/run-20221216_092322-i6enghic/logs/debug-internal.log
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_init.py:init():516] calling init triggers
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_init.py:init():519] wandb.init called with sweep_config: {}
config: {'weights': 'yolov5s.pt', 'cfg': '', 'data': '/content/drive-mnt/boat_detector_va2/boat_detector_va2.yaml', 'hyp': {'lr0': 0.01, 'lrf': 0.01, 'momentum': 0.937, 'weight_decay': 0.0005, 'warmup_epochs': 3.0, 'warmup_momentum': 0.8, 'warmup_bias_lr': 0.1, 'box': 0.05, 'cls': 0.5, 'cls_pw': 1.0, 'obj': 1.0, 'obj_pw': 1.0, 'iou_t': 0.2, 'anchor_t': 4.0, 'fl_gamma': 0.0, 'hsv_h': 0.015, 'hsv_s': 0.7, 'hsv_v': 0.4, 'degrees': 0.0, 'translate': 0.1, 'scale': 0.5, 'shear': 0.0, 'perspective': 0.0, 'flipud': 0.0, 'fliplr': 0.5, 'mosaic': 1.0, 'mixup': 0.0, 'copy_paste': 0.0}, 'epochs': 200, 'batch_size': -1, 'imgsz': 1280, 'rect': True, 'resume': False, 'nosave': False, 'noval': False, 'noautoanchor': False, 'noplots': False, 'evolve': None, 'bucket': '', 'cache': 'ram', 'image_weights': False, 'device': '', 'multi_scale': False, 'single_cls': False, 'optimizer': 'SGD', 'sync_bn': False, 'workers': 8, 'project': 'runs/train', 'name': 'exp', 'exist_ok': False, 'quad': False, 'cos_lr': False, 'label_smoothing': 0.0, 'patience': 100, 'freeze': [0], 'save_period': 5, 'seed': 0, 'local_rank': -1, 'entity': None, 'upload_dataset': False, 'bbox_interval': -1, 'artifact_alias': 'latest', 'save_dir': 'runs/train/exp'}
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_init.py:init():569] starting backend
2022-12-16 09:23:22,909 INFO    MainThread:419 [wandb_init.py:init():573] setting up manager
2022-12-16 09:23:22,911 INFO    MainThread:419 [backend.py:_multiprocessing_setup():102] multiprocessing start_methods=fork,spawn,forkserver, using: spawn
2022-12-16 09:23:22,913 INFO    MainThread:419 [wandb_init.py:init():580] backend started and connected
2022-12-16 09:23:22,916 INFO    MainThread:419 [wandb_init.py:init():658] updated telemetry
2022-12-16 09:23:22,941 INFO    MainThread:419 [wandb_init.py:init():693] communicating run to backend with 60 second timeout
2022-12-16 09:23:23,162 INFO    MainThread:419 [wandb_run.py:_on_init():2006] communicating current version
2022-12-16 09:23:23,197 INFO    MainThread:419 [wandb_run.py:_on_init():2010] got version response
2022-12-16 09:23:23,197 INFO    MainThread:419 [wandb_init.py:init():728] starting run threads in backend
2022-12-16 09:23:23,340 INFO    MainThread:419 [wandb_run.py:_console_start():1986] atexit reg
2022-12-16 09:23:23,340 INFO    MainThread:419 [wandb_run.py:_redirect():1844] redirect: SettingsConsole.WRAP_RAW
2022-12-16 09:23:23,341 INFO    MainThread:419 [wandb_run.py:_redirect():1909] Wrapping output streams.
2022-12-16 09:23:23,341 INFO    MainThread:419 [wandb_run.py:_redirect():1931] Redirects installed.
2022-12-16 09:23:23,348 INFO    MainThread:419 [wandb_init.py:init():765] run started, returning control to user process
2022-12-16 09:23:23,606 INFO    MainThread:419 [wandb_run.py:_config_callback():1163] config_cb None None {'data_dict': {'path': '/content/drive-mnt/boat_detector_va2', 'train': '/content/drive/My Drive/ComputerVision/boat_detector_va2/images/train', 'val': '/content/drive/My Drive/ComputerVision/boat_detector_va2/images/val', 'nc': 2, 'names': {0: 'closeby_vessel,', 1: 'far_away_vessel'}}}
2022-12-16 09:23:41,504 INFO    MainThread:419 [wandb_run.py:_config_callback():1163] config_cb None None {'batch_size': 15}

Hi @wartek69, thanks for sharing these files! Could you send me a link to the run that is raising this error? I'd like to have a look at it in order to figure out why this error is raising as it's not clear to me from the files. Thanks!

Hi @wartek69, I wanted to follow up here! If you're still experiencing this issue, could you please send me a link to the failed runs? Thanks!

Hi Luis,
Do you mean this: https://wandb.ai/alex69/YOLOv5/runs/i6enghic/overview?workspace=user-alex69 ?
Br
Alex

I'm getting same issue with f1 metric

Hi @wartek69, thanks for sharing this! Is this error raising if you use the data proposed in the colab? Also @lyan62, could you explain me the steps you followed when raising this error? Thanks!

Hi @luisbergua
When using the default Yolo notebook without changing the data it seems to work just fine.
Br
Alex

Hi @wartek69, thanks for confirming this! Could you share with me an example of the training data you're using?

Hi @wartek69 @lyan62, if you're still experiencing this issue only when using your own data, could you please send me an example of it and so I can have a look? Thanks!

Hi @luisbergua
Sorry for the delay. Sharing the data would be quite difficult as it is proprietary.
The dataset we are using is quite simple. In the failed run there were around 1.2k images with a single class (We train on a single class). What exactly would you hope to see in the dataset? Maybe I can answer some more specific questions?
Br
Alex

I can confirm this bug, I get the same error message, typically happens after hours of training
Traceback (most recent call last):
  File "inpainting/train_autoregressive.py", line 337, in <module>
    load_ckpt=args.load_ckpt
  File "/home/lennartv/.conda/envs/neo38/lib/python3.8/site-packages/torch/multiprocessing/spawn.py", line 240, in spawn
    return start_processes(fn, args, nprocs, join, daemon, start_method='spawn')
  File "/home/lennartv/.conda/envs/neo38/lib/python3.8/site-packages/torch/multiprocessing/spawn.py", line 198, in start_processes
    while not context.join():
  File "/home/lennartv/.conda/envs/neo38/lib/python3.8/site-packages/torch/multiprocessing/spawn.py", line 140, in join
    raise ProcessExitedException(
torch.multiprocessing.spawn.ProcessExitedException: process 1 terminated with signal SIGKILL
wandb: ERROR Failed to sample metric: psutil.NoSuchProcess process no longer exists (pid=6029)

I had the same issue, in my case, the problem turned out to be small RAM. So, try increasing the RAM size.

I had the same issue, in my case, the problem turned out to be small RAM. So, try increasing the RAM size.

I think that is a valuable pointer. I see my memory usage increasing over time, it might be an OOM that is concealed by a cryptic error message.

Thanks for sharing this @sarvghotra! @wartek69 was the small RAM also the root cause of your issue?

I'm not 100% sure as I was not looking at the Ram when the issue happened. Initially, I had a timeout after some time like @LvanderGoten reported. Later I had the error whenever the first epoch was completed (even after a restart of the notebook, so RAM would have been cleared normally).
I didn't do any fancy stuff and afaik the Collab has 12Gb of RAM, which should be plenty for a simple use case of training a yolov5s model?

Hi @wartek69, thanks for confirming this! You mentioned your training dataset has 1.2k images, could you share with the the size of each image and so I can try to run a similar experiment and see if I get the same error?

@luisbergua
I have this error too. It happened immediately after instrumenting the code with torchmetrics and happens immediately in training.
I am not on a low memory machine. One strange consequence of this is that some of my metrics appear to be computed incorrectly, or don't appear at all in wandb.

If you reach out to me on email, lastname at gmail dot com, i can provide more info

My guess would be that this error is a catch-all for all OOM errors, the error message is not really helpful and should probably be refined.

Hi @wartek69, thanks for confirming this! You mentioned your training dataset has 1.2k images, could you share with the the size of each image and so I can try to run a similar experiment and see if I get the same error?

Hi, the image size for the conducted experiment was between 2Mb and 100kb for the training totaling a 1578 images of 2.2Gb size.
Validation is 396 items with a size of 500Mb in total.

I was able to resolve this issue by following the manual more closely.
https://torchmetrics.readthedocs.io/en/stable/pages/lightning.html
"Mixing the two logging methods by calling self.log("val", self.metric) in {training}/{val}/{test}_step method and then calling self.log("val", self.metric.compute()) in the corresponding {training}/{val}/{test}_epoch_end method. Because the object is logged in the first case, Lightning will reset the metric before calling the second line leading to errors or nonsense results."
Specifically, I was before logging both in _epoch_end AND in _step. I changed that and the error resolved.

Dear @turian, I'm also experiencing this issue. I've looked into the link you shared, but I'm still uncertain about how to apply it in my scenario. I didn't have any issues with using wandb, so I'm wondering if it's because the metrics can't be calculated twice. Or is it because the metrics shouldn't be calculated both in _step and _on {training}/{val}/{test}_epoch_end?
Any insights would be greatly appreciated.
Best regards


method does not override or implement a method from a supertype

Hi,
I have got the following error when I try to use @1.0.5 with RN 0.49.3 as well as 0.50.4.
Build @1.0.4 works correctly.
.../node_modules/react-native-contacts/android/src/main/java/com/rt2zz/reactnativecontacts/ReactNativeContacts.java:26: error: method does not override or implement a method from a supertype
    @Override
    ^
1 error
:react-native-contacts:compileReleaseJavaWithJavac FAILED

according to https://github.com/facebook/react-native-fbsdk/pull/345 we should remove the @Override syntax. Anyone wanna submit a PR?

Please test now. Followed suggestions at https://github.com/facebook/react-native-fbsdk/pull/345

I have tested. Current latest release will break upon the @Override. We need to remove this.

I already removed the line and released v2.0.0 of this project. See https://github.com/rt2zz/react-native-contacts/commit/95a5f87ff5904a24457b1b15abf9da3043b322e0

Thank you @morenoh149, now it works correctly (v2.0.0).


Adds support for case insensitive commands

Closes #74 .

I would rather have it so it is possible to add commands as either case sensitive or insensitive.
Maybe have the command set be something like:
pub enum CaseSentivity {
  Insensitive(Unicase<String>),
  Sensitive(String),
}

In that case, what would you like the Config::add_command function to look like?
I can think of three different ways:
1/ Ask for a CaseSensitivity enum instead of a String.
config.add_command(CaseSensitivity::sensitive("echo"));

2/ Take in an extra case_sensitivity boolean.
config.add_command("echo", true);

3/ Have the function return a mutable reference to the command.
config.add_command("echo").case_sensitive();

On a side note, would you rather the command be case sensitive or insensitive by default?

I think we should be case insensitive by default, maybe, I am not sure of the best way to make the api, we could add a function like add_case_insensitive_commad but that is a very long name. I have another more Involved idea which I will try and write up a bit later today.

That said you are free to change how it works, if you have a better idea for the api I would like to see it.

I gave it a try but unfortunately making a command case sensitive turned out to more verbose than making it insensitive. Also it seems that the third way I mentioned would not work as I forgot that HashSets are not able to produce mutable references of its items.
I'm pretty interested in seeing what you come up with.

So your idea 3 gave me a bit of an idea, so here is a short proof of concept for what I think would be a nice interface:
use std::collections::HashSet;

pub struct Parser {
    // Should be that enum posted above instead
    pub commands: HashSet<(String, bool)>
}

pub struct Command<'a> {
    name: String,
    case_insensitive: bool,
    parser: &'a mut Parser,
}

impl Parser {
    pub fn new() -> Self {
        Self {
            commands: HashSet::new(),
        }
    }

    pub fn command<'a>(&'a mut self, name: impl Into<String>) -> Command<'a> {
        Command {
            name: name.into(),
            case_insensitive: false,
            parser: self,
        }
    }

    // Not pub so we could change it as we want to.
    // Could also take some kind of builder struct instead of a lot of
    //  input arguments.
    /* not pub */ fn add_command(&mut self, name: String, case_insensitive: bool) {
        self.commands.insert((name, case_insensitive));
    }
}

impl<'a> Command<'a> {
    // Note: Not a mutable reference as that would move out of a mutable reference
    //       when used.
    pub fn case_insensitive(mut self) -> Self {
        self.case_insensitive = true;
        self
    }

    pub fn add(self) {
        self.parser.add_command(self.name, self.case_insensitive);
    }
}

fn main() {
    let mut parser = Parser::new();

    parser.command("foo".to_string()).add();
    parser.command("bar".to_string()).case_insensitive().add();

    println!("{:?}", parser.commands);
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=40fb1a05a4392406b74869d049569e0b
What do you think of it?

Yeah it should be Config I think, And yeah CommandBuilder is nice, I think the best place to do the transformation into the enum above will be in the private add_command method.


Unclear if the API allows workers to be generated from strings

TL;DR:
Using raw workers, I can generate a Blob from a string. Is there any affordance for this in operative's API? Can I alias the callback to a function that's called in the string?
The reason:
I'm writing a tool that needs to evaluate user-generated code. It's a programming challenge, so when a user thinks they've got the correct result they call verify(result) and see if it passes.
An example of a simple challenge:
Calculate 1+1, then pass the result into the verify function.
verify is defined by me behind the scenes as function (n) { return n == 2; }. After reading the challenge, the user might type something like this into a textarea and hit run.
var result = 1 + 1;
verify(result);

Thoughts so far:
It seems like this should work well with the operative API... I've got a chunk of code to run, and a single callback to send back to the main thread. I'm just not sure how to deal with stringified user input. One possible solution is:
var myOperative = operative(function (__code__, verify) {
  eval(__code__);
});

...but I was hoping to avoid using eval like that. Any thoughts on how best to handle this?
Thanks for all of your hard work on this library!!

Blobs give you a tad more debuggability, but beyond that, not much. Also, to get that debuggability, you'd have to form the worker from the blob itself ... so, a brand new operative for every piece of user code. Would that work for you? I'd like to experiment with this a bit, but was wondering if there's something specific about blobs that makes you want to use them here? Eval seems bad, but that's what's effectively going to be happening either way.

... so, a brand new operative for every piece of user code. Would that work for you?

It would certainly work, since there's no state held between tests (i.e. whenever run is hit, we're starting from scratch).

...wondering if there's something specific about blobs that makes you want to use them here? Eval seems bad, but that's what's effectively going to be happening either way.

You're right; the difference between Blobs and eval in this case is minimal. I was just wondering if Blob string support was baked-in, because if so I'd use it instead :)

Slight tangent: Is it possible for an operative's callback to accept function arguments? For example, if I have the following prompt:
Write a function that returns the number two and pass it into the verify function.
And the following verify method:
function verify (fn) { return fn() === 2; }

Running the following will return an error:
var worker = operative(function (__code__, verify) {
  eval(__code__);
});

worker('verify(function () { return 2; });', verify);
// Uncaught DataCloneError: Failed to execute 'postMessage' on 'WorkerGlobalScope': An object could not be cloned.

In this toy example, we could just run verify(fn())... but in more complex examples, passing a function back is very useful. Just wondering if you've dealt with this in the past.

There is no way to pass a function in either direction. If there was, operative would just be toString'ing it and then eval'ing it on the other side. This is generally a limitation of workers, and makes sense since a function is never a self-contained thing, but has ties to its execution context and scope, etc.

@padolsey  is it possible to pass Float32 array buffers between the web worker and the main thread. I want to run a merge buffer operation for Float32 arrays.

@dulichan Have a look at https://github.com/padolsey/operative/wiki/Transfers-API -- you should be able to pass through the buffer directly (though do note that you'll be transferring ownership of it). See https://developer.mozilla.org/en/docs/Web/API/Worker/postMessage (specifically the transferList argument), to see how it works.

@padolsey thank you for pointing me in that direction. What I want to do is to transfer an array of Float32Arrays. Does the spec support away to do this?

Basically I am trying to run the below function -
var mergeBuffer = operative(function(obj, callback) {
      const result = new Float64Array(obj.length);
      let offset = 0;
      var buffer = obj.buffer;
      for(let i = 0; i < buffer.length; i++) {
        const inner = buffer[i];
        result.set(inner, offset);
        offset += inner.length;
      }
      callback.transfer(result.buffer, [result.buffer]);
    });

What I have as inputs is an array of Float32 Arrays. If I try below invocation it fails with Failed to execute 'postMessage' on 'Worker': Value at index 0 does not have a transferable type.. This is mainly because buffers[0] is a plain old array. Any solution that you can think of to enable this transfer?
mergeBuffer.transfer(buffers[0], buffers[0], function(result) {
      console.log(result);
    });

Try:
mergeBuffer.transfer(buffers[0], [buffers[0]], ...);

(The second argument to transfer() must be an Array of Transferables.)
If this still doesn't work I suggest opening a separate issue as this is technically not related to the issue thread we've been speaking on.


OL5 beta.8 broke feature drawing "blue line"

The "blue line" style for interactive feature drawing is broken in OL5 beta.8. It's working well in beta.7.
If needed I can try to make a reproducible case.

If possible, please create a CodeSandbox that shows the issue.

OK, I'm creating one. I think the official example should reproduce it.

Even better, then we don't need a CodeSandbox. Which official example?

Yes, I can confirm, "draw-shapes" does it. No interactive part.

Looks like it works in master, unless I'm missing what the issue is. Can you confirm?

OK, I created CodeSandbox for it:
https://codesandbox.io/s/p3y4256q7x
No rectangle visible while drawing for beta.8.

Thanks @hyperknot. I ran git bisect, and 6d1e8cb38b988e0cc7bf7abcd5014297ff8e6bcf is the first bad commit.


Add FormulatePro 0.0.6

Aren’t there any alternate links? Google code will be gone soon, and if the author does not intend on moving it, no sense in adding a soon-to-be-dead cask.

FYI I've started an export of the repo into my personal GitHub account, to be moved under alehouse (haven't had to use that in awhile...). Just in case there isn't an alternate, we can still have this placed under homebrew-unofficial.

I see various forks outside of Google Code, but nothing that looks like an obvious transfer. In general, the project looks dormant for the last 2-3 years (but I still find the software useful, even on OS X 10.10.x). I've posted on the forums to see if it sparks any discussion about this.

but I still find the software useful, even on OS X 10.10.x

Doesn’t matter, if it dies soon with no way to officially get it. Let’s wait for the forum replies, then.

@von-forks Any news?