Why does emscripten.Instantiate and InstantiateForModule differ drastically?

One imports all the host functions needed, and the other barely imports anything. The documentation point you towards Instantiate, which won't work for any C++ module requiring exception support, for example.
Why don't they both set the same emscription host functions?

Maybe @jerbob92 (the creator of wazero-emscripten-embind and our resident emscripten expert) can help?

That's because Emscripten dynamically registers host functions as needed, which are called invoke_xxx, where xxx is the function signature. Wazero needs to know the module so that it can generate the function as well (https://github.com/tetratelabs/wazero/blob/main/internal/emscripten/emscripten.go#L43). If Wazero wouldn't do this, it would need to register any combination possible, which is not feasible.
I suspect Instantiate is left in to not break external code, but it's probably not very usable in most cases, so I would always go withInstantiateForModule.
Please note that real C++ exceptions is not supported by Wazero yet, I have been building that here:
https://github.com/jerbob92/wazero/blob/feature/implement-emscripten-cpp-exceptions/internal/emscripten/exceptions.go
And it does work, but I don't like the implementation so I'm still waiting for a response on https://github.com/tetratelabs/wazero/issues/1654 to make a PR.

OK. Should I make a PR to change the documentation to use InstantiateForModule (since it sounds like Instantiate should be deprecated)?

Also as an aside, I'm interested in using wazero to run Tesseract, compiled to WASM via Emscripten.
The Tesseract WASM emscripten imports are minimal enough that I'd figure I could try to implement them myself.  (env._emscripten_fs_load_embedded_files and env.system)
Do you think this project is feasible with the current support of emscripten in wazero?

OK. Should I make a PR to change the documentation to use InstantiateForModule (since it sounds like Instantiate should be deprecated)?

Yeah, sounds good!

Also as an aside, I'm interested in using wazero to run Tesseract, compiled to WASM via Emscripten. The Tesseract WASM emscripten imports are minimal enough that I'd figure I could try to implement them myself. (env._emscripten_fs_load_embedded_files and env.system)
Do you think this project is feasible with the current support of emscripten in wazero?

I don't know what these imports are, but generally you would need to recompile for a standalone WASM file, then you will have way less emscripten specific imports. I use this branch to compile my stuff so that it uses WASI for things like filesystem operations: https://github.com/emscripten-core/emscripten/pull/18285
So it is feasible, but you might need to do some special steps to get there.


[SILENT ERROR] Tye run does not supports for CsProj containing "TargetFrameworkS"

Describe the bug
If you are trying to do tye run and one of the xxproj  is using TargetFrameworks it will silently crash on restore/build
And tye run output an error about a "Missing file"
Few issue here:

We might want to know the name of the file missing
We might want to know that the dotnet xxx /t:.... failed ==> Cannot find Target ResolveReferences
We might want to be able to do tye run --framework netcoreapp3.1 (see investigation)
We might want to be able to do in tye.yaml

name: THE_NAME
services:
- name: THE_SERVICE
  project: src/THE_SERVICE/THE_SERVICE.csproj
  framework: netcoreapp3.1

To Reproduce
DISCLAMER:
I did all the investigation on a CORP project, so i'm not entierlly sure this repro is enought
Naive repro:

dotnet new webapi
replace TargetFramework by TargetFrameworks
tye init
tye run

Further technical details

Include the output of tye --version

[12:24]❯ tye --version
0.3.0-alpha.20318.3+224101f108311b4d38b226eed75d0ec03fa14db1

The platform: Windows

If the repro is not enought, I believe that this one might be very similar to CORP repo:
mkdir repro
cd repro
git clone https://github.com/dotnet-experimentations/CentrallyManagingNuGetPackageVersions/
cd CentrallyManagingNuGetPackageVersions
cd WithMsBuild   # <==== THIS IS IMPORTANT :D
tye init
tye run

[12:23:23 INF] Executing application from C:\dev\xxxxxxx\tye.yaml
[12:23:23 INF] Dashboard running on http://<IP_ADDRESS>:8000
[12:23:23 INF] Building projects
[12:23:42 INF] Launching service XXXXXXXXXXXXXXXXXX-aspnetcore_f992c4c5-d:
[12:23:42 INF] Launching service YYYYYYYYYYYYYYYYY_5a5c648c-6:
[12:23:42 ERR] Failed to launch process for service XXXXXXXXXXXXXXXXXX-aspnetcore_f992c4c5-d
System.InvalidOperationException: Cannot start process because a file name has not been provided.  <============= This is very missleading
   at System.Diagnostics.Process.Start()
   at Microsoft.Tye.ProcessUtil.RunAsync(String filename, String arguments, String workingDirectory, Boolean throwOnError, IDictionary`2 environmentVariables, Action`1 outputDataReceived, Action`1 errorDataReceived, Action`1 onStart, CancellationToken cancellationToken) in /_/src/Microsoft.Tye.Core/ProcessUtil.cs:line 105
   at Microsoft.Tye.Hosting.ProcessRunner.<>c__DisplayClass8_0.<<LaunchService>g__RunApplicationAsync|0>d.MoveNext() in /_/src/Microsoft.Tye.Hosting/ProcessRunner.cs:line 319

I managed to get more info running tye run -v Debug
    Assets file has not changed. Skipping assets file writing. Path: C:\dev\XXXXXXXXXXXXX\obj\project.assets.json
    Writing packages lock file at disk. Path: C:\dev\XXXXXXXXXXXXX\packages.lock.json
    Restored C:\dev\XXXXXXXXXXXXX\XXXXXXXXXXXXX.csproj (in 5.12 sec).
    Restored C:\dev\XXXXXXXXXXXXX\XXXXXXXXXXXXX.csproj (in 4.28 sec).

    NuGet Config files used:
        C:\dev\XXXXXXXXXXXXX\Users\USER_NAME\AppData\Roaming\NuGet\NuGet.Config
        C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

    Feeds used:
        https://FEED_ONE/
        https://FEED_TWO/
        https://FEED_THREE/

    Installed:
        4 package(s) to C:\dev\path\to\each\file.csproj
        4 package(s) to C:\dev\path\to\each\file.csproj
        4 package(s) to C:\dev\path\to\each\file.csproj
        56 package(s) to C:\dev\path\to\each\file.csproj
        19 package(s) to C:\dev\path\to\each\file.csproj
        114 package(s) to C:\dev\path\to\each\file.csproj
        94 package(s) to C:\dev\path\to\each\file.csproj
        151 package(s) to C:\dev\path\to\each\file.csproj
        141 package(s) to C:\dev\path\to\each\file.csproj
        143 package(s) to C:\dev\path\to\each\file.csproj
        238 package(s) to C:\dev\path\to\each\file.csproj
        242 package(s) to C:\dev\path\to\each\file.csproj
        354 package(s) to C:\dev\path\to\each\file.csproj
        410 package(s) to C:\dev\path\to\each\file.csproj
        158 package(s) to C:\dev\path\to\each\file.csproj
        204 package(s) to C:\dev\path\to\each\file.csproj
    3 of 19 projects are up-to-date for restore.

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:02:05.62
Restored project 'C:\dev\XXXXXXXXXXXXX.HubApp\MY_PROJECT.csproj'.
Build started 6/26/2020 11:33:37.
__________________________________________________
Project "C:\dev\XXXXXXXXXXXXX.HubApp\MY_PROJECT.csproj" (ResolveReferences;ResolvePackageDependenciesDesignTime;PrepareResources;GetAssemblyAttributes target(s)):

C:\dev\XXXXXXXXXXXXX.HubApp\MY_PROJECT.csproj : error MSB4057: The target "ResolveReferences" does not exist in the project.

Done building project "MY_PROJECT.csproj" -- FAILED.

Build FAILED.

C:\dev\XXXXXXXXXXXXX.HubApp\MY_PROJECT.csproj : error MSB4057: The target "ResolveReferences" does not exist in the project.
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.00
Found application version: 1.0.0
RunCommand=
RunArguments=
TargetPath=
PublishDir=
AssemblyName=MY_PROJECT
IntermediateOutputPath=obj\Debug\
Found target framework:
Found shared frameworks:
IsAspNet=True
Evaluation Took:<PHONE_NUMBER>ms
Launching Tye Host...

[11:33:38 INF] Executing application from C:\dev\XXXXXXXXXXXXX:38 INF] Dashboard running on http://<IP_ADDRESS>:8000
[11:33:38 INF] Building projects
[11:33:54 INF] Launching service MY_PROJECT_c366d90a-f:
[11:33:54 ERR] Failed to launch process for service MY_PROJECT_c366d90a-f
System.InvalidOperationException: Cannot start process because a file name has not been provided.
   at System.Diagnostics.Process.Start()
   at Microsoft.Tye.ProcessUtil.RunAsync(String filename, String arguments, String workingDirectory, Boolean throwOnError, IDictionary`2 environmentVariables, Action`1 outputDataReceived, Action`1 errorDataReceived, Action`1 onStart, CancellationToken cancellationToken) in /_/src/Microsoft.Tye.Core/ProcessUtil.cs:line 105
   at Microsoft.Tye.Hosting.ProcessRunner.<>c__DisplayClass8_0.<<LaunchService>g__RunApplicationAsync|0>d.MoveNext() in /_/src/Microsoft.Tye.Hosting/ProcessRunner.cs:line 319

The interesting part is this one I think :
Project "C:\dev\XXXXXXXXXXXXX.HubApp\MY_PROJECT.csproj" (ResolveReferences;ResolvePackageDependenciesDesignTime;PrepareResources;GetAssemblyAttributes target(s)):

C:\dev\XXXXXXXXXXXXX.HubApp\MY_PROJECT.csproj : error MSB4057: The target "ResolveReferences" does not exist in the project.

so I found this in dotnet tye code :
https://github.com/dotnet/tye/blob/e368d04e914a3880a1a10e21cf5c271966241dbd/src/Microsoft.Tye.Core/ProjectReader.cs#L208-L218
I managed to reproduce a low level error by running:
dotnet msbuild "C:\dev\XXXXX\Y.csproj" /t:ResolveReferences /t:ResolvePackageDependenciesDesignTime /t:PrepareResources /t:GetAssemblyAttributes

I looked a bit around this error and this seems to be related sometimes to the error you have when running dotnet run on an sln rather than a csproj. In this case I did try both dotnet run and dotnet run --project path/to/csproj
Which did not worked for an obvious reason:

This works as expected:
dotnet run --framework netcoreapp3.1
As I could not find tye run --framework netcoreapp3.1 (maybe there's a flag in the YAML ?) I changed the csproj from :
<TargetFramworks>$(SrcTargetFrameworks)</TargetFramworks>

To:
<TargetFramwork>$(SrcTargetFrameworks)</TargetFramwork>

===> That finally works <=== even though it's not really a "goal" as a consumer :)
having a --framework from the CLI for tye run
then rolledback to TargetFramworks and I tried to edit the tye.yaml from
name: foobar
services:
- name: foo
  project: src/foo/foo.csproj

to
name: foobar
services:
- name: foo
  project: src/foo/foo.csproj
  framework: netcoreapp3.1

also see #608


remove extension delclaration for Page_Controller

delelted _config.php, updated ReadMe

closing in favor of an updated branch


playplaylist shows no result when there are too many matches

I have a lot (>30) of playlist that start with "Best-Of:".
When using playplaylist, no result is shown until I limit the matches, e.g "Best-Of: R". Following error is given while typing Best-Of:
[ERROR: alfred.workflow.input.scriptfilter] Code 1: 1660:1671: execution error: The variable resultLimit is not defined. (-2753)

The problem is probably here: https://github.com/caleb531/play-song/blob/master/filters/filter-playlists.applescript#L48
I think resultLimit should be replaced by (config's resultLimit).

Ah, you are indeed correct. I'll push out a fix for this and for the disableShuffle() handler later today.
Caleb

On Jan 27, 2015, at 8:43 AM, Asger Hautop Drewsen<EMAIL_ADDRESS>wrote:
The problem is probably here: https://github.com/caleb531/play-song/blob/master/filters/filter-playlists.applescript#L48
I think resultLimit should be replaced by (config's resultLimit).
—
Reply to this email directly or view it on GitHub.

Fixed in the latest commit. Will push a new release (v3.0.3) now.


Vite with Large Apps: Very slow initial request and slow subsequent requests

What version of Remix are you using?
2.2.0
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
Adding per a Discord discussion with @pcattori. Given a large app with many routes and components, the first page request after starting vite dev can result in hundreds of network requests. In my case most pages make around 250-300 requests, but another person in that same discussion had close to 600. In addition, every following request to any route (via navigation or actions/loaders) has a significant delay (2+ seconds per page for me). Including both of these issues together since they seem closely related in the way the plugin works.
Slow Initial Request
In my case, the first page request stalls for around 12 seconds while vite does its thing. After this, the app appears to load, but is not responsive for another 12 seconds while it runs 250 network requests for individual components and dependencies. This seems to be a common issue with Vite in dev mode due to the lack of bundling. But there may be some optimization opportunities on the remix plugin side.
I first ran vite dev and loaded a page, which let vite do it's initial new dependencies optimized... thing. I then restarted vite and ran vite dev --profile, made a browser request, then loaded the profile result into speedscope.app. Looking at it in Left Heavy mode, the time spent in resolveConfig and then flatRoutes is close to 9 seconds total. This is because resolveConfig is being called every time the plugin is loaded, which happens for each individual request. So even though it runs relatively quickly (around 30ms in my case), it's running hundreds of times and returning the same result every time. My initial thought was to cache the results of resolveConfig, but adding/renaming routes will break.
The next largest bottleneck in the remix plugin is at the transform function for remix-remix-react-proxy. For my initial page load, it's spending around 3-4 seconds here, most likely due to parsing the code of every single file in my project to see if it has "@remix-run/react" in it.

Slow Subsequent Requests
The transform bottleneck above is also causing subsequent requests to have a delay of 2+ seconds for me, which includes any navigation or calling any loaders/actions. This also slows down HMR -- even though vite almost instantly sends the updated component to the browser, rendering is paused while HDR re-runs the loader.
The plugin is set to invalidate the server build on every request, which causes all of the routes to be re-transformed. Since it's only re-transforming the routes and not every component, it is only taking 2 seconds instead of 3-4 like the initial page load, but it's enough to make the app feel very sluggish in development.
I tried commenting out the code that invalidates the server modules which makes the app very responsive after the initial load. But it has the same downside as caching resolveConfig: I now have to restart vite dev any time I add or rename routes. @pcattori mentioned figuring out a way to only invalidate when the changed files include routes or the config.
Expected Behavior
Reasonably quick development mode. Definitely not expecting the performance of a small 3-page app, but right now it's a significant slowdown from the old remix dev server (which took around 10 seconds for the initial build/page load).
Actual Behavior
25 second initial loads and sluggish navigation on following loads.

Spent some time this morning trying various caching ideas, but everything I tried broke something, usually related to adding/renaming routes. There are three key things that need to be cached or sped up in some way:

remix-react-refresh-babel: The call to resolvePluginConfig() here is running hundreds of times on startup causing the slow initial page load.
remix-remove-server-exports: Same, but to a lesser extent since it's not affecting the ssr build
The middleware in configureServer(vite). The resolvePluginConfig() here is fine, it only runs once per route request and doesn't seem to run for every individual component the page loads. However, it's invalidating all of the server modules on every request which is adding the 2 second delay.

Fixing 1 and 2 seemed a little easier, but the second I tried to add caching around the invalidating, everything broke -- it seems there are situations where even if the resolvePluginConfig() results haven't changed, the virtual modules still need to be invalidated. I'll explore some more when I have time.

@dmarkow - I am going to be curious to see if "remix-react-refresh-babel" is even needed.  Especially since Vite does not need Babel transforms.

@mikekidder Vite itself may not, but Remix does use a babel transform to 1) inject react-refresh code and 2) remove server exports (loader/action/headers) from route files.

@dmarkow Have you had success with vite.config.ts using optimizeDeps ?  Would this help the initial load to the server by eagerly optimizing the bundles?

@ZipBrandon I haven't explored that yet. On the old dev server my initial build time was 10-11 seconds, so Vite being at 12 for the initial build in my case is roughly the same. The caching I'm testing out right now should address the second 12 seconds where it loads in 250+ (or in your case almost 600) modules slowly.

I think I figured out my pain points above. I ended up adding two caches. The first one is for the middleware, which checks and refreshes the cache on each request, and only invalidates the virtual modules if the config changed. This makes site navigation a ton more responsive in dev, and speeds up HDR quite a bit. The other cache is initially set in the plugin config and used anywhere there are excessive calls to resolvePluginCache(). This cache gets refreshed in remix-hmr-updates, which should be the first part of the plugin to run anytime there is a file change as far as I can tell.
So far, this caching has drastically reduced that 8.5 seconds spent in resolveConfig down to 146ms. My next bottleneck on the profile graph is replaceImportSpecifier being called for a bunch of files in remix-remix-react-proxy (3+ seconds). The slowness here is Babel's parse/traverse/generate which I'm not sure how we speed up without moving away from Babel completely. Maybe switching to something faster like SWC?
I have a patch with the caching, I'd like to use it locally for a little bit before I create a PR around this. All Vite integration tests are still passing. The only jankiness I'm seeing is that adding a new route while the server is running and then trying to navigate to it sometimes causes an error, but if I hard-reload the browser it comes up fine without having to restart the dev server. And I'm getting the same issue without my patch which may warrant a separate issue.
Here's the patch if anyone wants to test -- you can use patch-package and drop it in your project's patches folder. @ZipBrandon I'd be curious to see what kind of speed increases you see on initial build.

// Don't transform files that don't need the proxy
if (
  !code.includes("@remix-run/react") &&
  !code.includes("LiveReload")
) {
  return;
}

// Rewrite imports to use the proxy
return replaceImportSpecifier({
  code,
  specifier: "@remix-run/react",
  replaceWith: remixReactProxyId,
});

@pcattori Is there a reason the RefreshRuntime is being injected into every file that imports from @remix-run/react? Shouldn't it just be the root file? Making it just inject into the root route will mostly eliminate the Babel slowdown. I'm wondering if this should actually be:
if (!(code.includes("@remix-run/react") && code.includes("LiveReload")) {
  return;
}

@dmarkow I'm currently trying the patch out and I'll profile on my end to see what it looks like around resolveConfig.  One thing that I'm hitting now is the first load gets a boatload of deps to optimize which impacts timing. I really want to resolve this. It doesn't seem that optimizeDeps is being honored -- or I am misconfiguring it out somehow.
 If you kill vite and start again, does it re-optimize those same dependencies again?

@dmarkow Improvement with your patch!
Unpatched

patched:

Yes, unfortunately if I kill vite and start again it re-optimizes it. Worse yet, if I navigate to a route that has some other dependencies that it discovers then it has to reoptimize those + all again.

@pcattori Is there a reason the RefreshRuntime is being injected into every file that imports from @remix-run/react? Shouldn't it just be the root file? Making it just inject into the root route will mostly eliminate the Babel slowdown. I'm wondering if this should actually be:
if (!(code.includes("@remix-run/react") && code.includes("LiveReload")) {
  return;
}

🤦 yep that looks like what we meant to write

An added bonus is that fixing these things drastically improves builds. Before any patches, vite build && vite build --ssr was taking my app 129 seconds. After patches (including a fix for the RefreshRuntime thing above), it's down to 24 seconds.

@dmarkow I was running at  ~5m 45s. Now 22s!

@dmarkow Thanks for picking that up! I've just opened a PR addressing this.

@markdalgleish I have successfully been using @dmarkow's patch for the last 3 days. I just tried to go to nightly-20231103 where I see your change in it.  My build times for prod are back to 5 minutes 45 seconds from ~22 seconds when I first patched it with @dmarkow . I didn't know if this was also due to the plugin cache that was incorporated in the patch. I carried over those changes by hand but no improvement to build times.  I have currently reverted to the patched version of 2.2.0 for these performance reason but hope it can be sussed out prior to 2.2.1.

@ZipBrandon Here is a patch file against 2.2.0 that includes the LiveReload fix. I made a PR yesterday for my other changes, so if they get accepted before 2.2.1 you won't need this patch anymore.

I think this can be closed now that both the LiveReload fix and my caching PR are merged.


swag rejects valid MIME Types for @Produce, panic

Describe the bug
Swag limits the MIME types allowed for APIs without good reason to do so.
Here are four MIME types which I want to use which swag disallows, panicing when I use them:

application/xhtml+xml
application/xml
application/health+json
image/svg+xml

To Reproduce
Steps to reproduce the behavior:

Create an endpoint that produces a valid MIME type not in the documentation of swag.
Run swag init

Expected behavior
All valid MIME types are accepted. There are no restrictions to what APIs can use. APIs are free to choose.
** Actual Behavior**
swag panics.
+ /home/christian.hujer/go/bin//swag init
2019/02/20 16:16:44 Generate swagger docs....
2019/02/20 16:16:44 Generate general API Info
2019/02/20 16:16:44 ParseComment panic in file health/health.go :application/health+json produce type can't accepted
panic: ParseComment panic in file health/health.go :application/health+json produce type can't accepted

goroutine 1 [running]:
log.Panicf(0x8f0078, 0x22, 0xc4201b3510, 0x2, 0x2)
        /usr/lib/go-1.10/src/log/log.go:333 +0xda
github.com/swaggo/swag.(*Parser).ParseRouterAPIInfo(0xc4204b7630, 0xc4203f7240, 0x10, 0xc420502b00)
        /home/christian.hujer/go/src/github.com/swaggo/swag/parser.go:347 +0x256
github.com/swaggo/swag.(*Parser).ParseAPI(0xc4204b7630, 0x8e2247, 0x2, 0x8e3479, 0x7, 0x8e7ed3, 0x13)
        /home/christian.hujer/go/src/github.com/swaggo/swag/parser.go:96 +0x242
github.com/swaggo/swag/gen.(*Gen).Build(0xc42048f988, 0x8e2247, 0x2, 0x8e3479, 0x7, 0x8e5a3e, 0xe, 0x8e3e9a, 0x9, 0x0, ...)
        /home/christian.hujer/go/src/github.com/swaggo/swag/gen/gen.go:30 +0x2c6
main.main.func1(0xc4200fe2c0, 0xc4202efb00, 0xc4200fe2c0)
        /home/christian.hujer/go/src/github.com/swaggo/swag/cmd/swag/main.go:34 +0x194
github.com/urfave/cli.HandleAction(0x843500, 0x8ffde0, 0xc4200fe2c0, 0x0, 0xc420143020)
        /home/christian.hujer/go/src/github.com/urfave/cli/app.go:502 +0xbe
github.com/urfave/cli.Command.Run(0x8e285f, 0x4, 0x0, 0x0, 0xc42040f210, 0x1, 0x1, 0x8e5ae6, 0xe, 0x0, ...)
        /home/christian.hujer/go/src/github.com/urfave/cli/command.go:165 +0x47d
github.com/urfave/cli.(*App).Run(0xc420074000, 0xc4200ba000, 0x2, 0x2, 0x0, 0x0)
        /home/christian.hujer/go/src/github.com/urfave/cli/app.go:259 +0x6e8
main.main()
        /home/christian.hujer/go/src/github.com/swaggo/swag/cmd/swag/main.go:61 +0x4e2

Your swag version
~/go/bin/swag --version
swag version v1.4.1

Desktop (please complete the following information):

OS: Kubuntu 18.04.2 LTS
Go version: go1.10.4 linux/amd64

Additional context
I've seen that swag has already been patched several times to accomodate more MIME Types.
It should not be necessary to patch swag for new MIME Types.
swag should not panic on MIME Types it does not know, it should simply pass them through.
If swag shall help with avoiding accidents with MIME Types, such as wrong MIME Types, it should issue a warning for unknown MIME types instead of panicing. Also, in that case, swag should not maintain authority over the list of known MIME types but accept IANA as authority, refering to the official list of registered MIME types at https://www.iana.org/assignments/media-types

fixed by #304


have you thought about supporting rotation?

Just a quick question/feature request.
As it currently stands, this is a great module for image creation or even basic photo manipulation, but having the ability to rotate images would be awesome.
Using android this can be done via matrix transforms, something like:
            var image = ImageSource.fromFile(path);
            var new_image = new ImageSource.ImageSource();
            var quality = 100;
            var rotate = 90; // Rotate 90 degrees
            var matrix = new android.graphics.Matrix();
            matrix.postRotate(rotate);

            // Create new rotated bitmap using source image
            new_image.android = android.graphics.Bitmap.createBitmap(
                image.android,
                0,
                0,
                width,
                height,
                matrix,
                true
            );

            // Save new image to disk
            new_image.saveToFile(
                new_path,
                Enums.ImageFormat.jpeg,
                quality
            );

Performing similar on iOS however has proven difficult.
Just an idea, but if implemented would be a great tool to link to custom GUI's to perform basic image manipulation :-)

Yes. Is available in version 1.6.1 now ;-)
let imgSrc = ImageSource.fromFile(path);
let originalBitmap = BitmapFactory.asBitmap(imgSrc);

// rotate +59.79 degrees
//
// is optional and +90 by default
let rotatedBitmap = originalBitmap.rotate(59.79);

Hmm, so I have tested this, but BitmapFactory.asBitmap(imgSrc) seems to return the good old "Immutable bitmap passed to Canvas constructor" exception.
I tested this using an instance of image source or as a native bitmap (generated using the makeMutable method) and got the same result. Any ideas?

Oh, the example is wrong.
You habe to use makeMutable() function.

Ok, it seems like my test phone was having some sort of moment earlier, I have tested rotation now and seems to work like a charm! :-)


[BUG] App hangs during loading of new chapter/volume

I am currently using the app to read volumes of One Piece and as per title the app hangs during loading of new chapter/volume When this happens I can click and see the animations for the clicks on the title bar still, however the body of the window is just a black screen. Clicking the X to close the app doesn't work and the only method to quit is via force killing of the process.
This is not a constant occurrence. In some cases I can load chapters in some cases it'll hang when attempting to load the next one directly after. (Never during loading of first chapter after opening app however)
I have tested with both loading from cbz and also loading directly from the extracted folder from the CBZ and in both cases it is occuring.
The volumes are around 180-200 pages in length, I haven't read anything that is a chapter length to be able to prove its happening on lower count items as well but if I do and it happens I will update.
Next time this occurs I will update the issue with a screenshot of how the UI looks.
I can provide any logs/dumps/screenshots etc that are required to help diagnose the issue so feel free to request them if it'll help

When this happens I can click and see the animations for the clicks on the title bar

From this you mean only the buttons in top right?

I can provide any logs/dumps/screenshots etc that are required to help diagnose the issue so feel free to request them if it'll help

Also, click ctrl+shift+i and send screenshot of any window that opens, if it still working. There might be some unhandled error I didn't account for.

Had a hang happen again - this time it was in fullscreen and couldn't exit full screen, nor open developer tools.
Going to keep the app running with verbose loggin enabled via and will upload log next time I get a hang
.\yomikiru.exe --enable-logging --v=1

Check the generated log file under "Settings->About->Last button" if you notice something.

main.log
yomikiru.log
Just got a hang with logging enabled
The last line in the log window was Renderer process oom - see https://www.electronjs.org/docs/tutorial/application-debugging for potential debugging information.
I've attached both the main.log and full verbose log above.

Can't be sure but I think its related to #141.
If not, then might be related to total ram usage. Can you tell me the resolution or size of an image? As it is a 32bit application it has limited RAM access.
Additionally, main.log is log of backend, and renderer.log is log frontend. This issue is probably on front side.

In some cases I can load chapters in some cases it'll hang when attempting to load the next one directly after

Can you elaborate further on that?

Can you elaborate further on that?

I'm using the app to read the One Piece volumes (1-99) currently
I originally had them in the CBZ archives in the location d:\XXXX\OnePiece\XXXX
The app was hanging at this point so I extracted them all out to folders in the same location to test if it was an issue with loading from the temp directory set in here

However it would still hang after that
To give you an idea each volume is around 200~ images large

When loading the app from fresh I can load and read as expected, most of the time I'm also to readall the way through a volume and then loading up the next from the end-page here

The hang itself happens when going over to the next volume at which point the app locks up and instead of showing the usual progress bar it'll hang at the black screen I mentioned previously. This isn't consistent though and sometimes I am able to transfer to the next volume 10+ times in a row.. sometimes it'll hang after just attempting to transfer after the first.
After force quitting the application I'm able to load the volume that it hung on previously and then continue as expected... until the next hang, whenever it decided to happen.
My laymens guess would be that garbage collection processes aren't running properly and clearing cache inbetween volumes causing it to run oom and post the "renderer oom" error, but I don't have enough experience to say anything more than best guesses.

My laymens guess would be that garbage collection processes aren't running properly and clearing cache inbetween volumes

Actually, I cant control the garbage collector, I just try to force it to clear cache when chapter changes. It caches all opened images and
From what I can see the issue is being caused by memory limit of 32bit app (4GB). Maybe I need to build for 64bit.

64bit version released. I will close this for now, please report if you encounter this issue again.


Allow custom enemies to differentiate between different gel types

Currently, enemies can only react to gel in general, and can't differentiate between the different gel types. Seeing as the different gels have vastly different properties, this would be a good feature to have for custom enemies in Portal mappacks

There's probably a better way to do this than to have it be specifically for gel. Just having a property filter for transforms would be much more versatile.


fix update clucene: fix CLStream memcpy read 1 extra byte (#240)

update clucene for https://github.com/apache/doris-thirdparty/pull/240

run buildall


Add AppiumLibrary driver instance

AppiumLibrary doesn't use _current_browser().
it uses  _current_application()

Fixed this in a separate PR


js_operation_serializer runtime crash

./js_operation_serializer
ChainTypes.operations=
    transfer: 0
    limit_order_create: 1
    ...
    assert: 35
    balance_claim: 36
    override_transfer: 37

2794874ms th_a       main.cpp:382                  main                 ] e.to_detail_string(): 10 assert_exception: Assert Exception
Internal error: static_variant tag is invalid.
    {}
    th_a  static_variant.hpp:117 con

Found and fixed the problem, patch coming shortly.

Closing this, feel free to re-open if the problem re-surfaces.

Another missing variant?  Anyway to show the stack so I can see and fix the actual line number causing the problem?
./js_operation_serializer
313108ms th_a       main.cpp:382                  main                 ] e.to_detail_string(): 10 assert_exception: Assert Exception
Internal error: static_variant tag is invalid.
    {}
    th_a  static_variant.hpp:117 con

It doesn't crash for me right now.   Does it still crash for you?

fixed ..


Unmoderated IoN Subs

I compiled a list of subreddits from the network that had no moderators other than the defaults.
I have reached out to all of the subreddits currently on this list and inviting the moderators of each subreddit to help with the subreddit related to their location. The form-letter templates used to contact the various subreddits have been moved here.
Now that all of them have been contacted, locations/places that we have found moderator(s) for will be checked off and formatted bold-strikethrough.

Unchecked items are subreddits without moderators (other than the defaults)

U.S. States

[ ] /r/ImagesOfArizona
[ ] /r/ImagesOfDelaware
[ ] /r/ImagesOfGeorgia
[ ] /r/ImagesOfHawaii
[ ] /r/ImagesOfIdaho
[ ] /r/ImagesOfIllinois
[ ] /r/ImagesOfIndiana
[ ] /r/ImagesOfKansas
[ ] /r/ImagesOfKentucky
[x] /r/ImagesOfLouisiana
[ ] /r/ImagesOfMinnesota
[ ] /r/ImagesOfMississippi
[ ] /r/ImagesOfMontana
[x] /r/ImagesOfMaine
[ ] /r/ImagesOfMaryland
[ ] /r/ImagesOfNebraska
[ ] /r/ImagesOfNevada
[ ] /r/ImagesOfNewHampshire
[ ] /r/ImagesOfNewJersey
[ ] /r/ImagesOfNorthCarolina
[x] /r/ImagesOfNorthDakota
[ ] /r/ImagesOfOhio
[x] /r/ImagesOfOklahoma
[ ] /r/ImagesOfOregon
[ ] /r/ImagesOfRhodeIsland
[ ] /r/ImagesOfSouthCarolina
[ ] /r/ImagesOfTennessee
[ ] /r/ImagesOfUtah
[ ] /r/ImagesOfVermont
[ ] /r/ImagesOfVirginia
[ ] /r/ImagesOfWestVirginia
[ ] /r/ImagesOfWyoming

Central & South America

[x] /r/ImagesOfBelize
[ ] /r/ImagesOfBrazil
[ ] /r/ImagesOfGuatemala
[x] /r/ImagesOfMexico
[ ] /r/ImagesOfPeru

Middle East & North Africa

[ ] /r/IMagesOfEgypt
[x] /r/ImagesOfIran
[ ] /r/ImagesOfLibya
[ ] /r/ImagesOfSyria
[ ] /r/ImagesOfYemen

"Dahn Undah"

[ ] /r/ImagesOfAustralia
[ ] /r/ImagesOfNewZealand

Europe

[ ] /r/ImagesOfBelgium
[ ] /r/ImagesOfIsleOfMan
[ ] /r/ImagesOfNetherlands
[x] /r/ImagesOfScotland
[x] /r/ImagesOfWales

state area
i also want to make a welcome mat for discord before you send this! i'll have one in the next hour.

@amici-ursi I originally had [state|area] in the form letter, but I ended up just changing it to state, for now, because I think we will probably want to adjust the form letter when reaching out to subreddits that are non-native english-speaking places, anyways.

As long as you're the one making sure the wording gets switched when sending the messages
Updated link for Discord: https://discord.gg/0tZsejLgM2wtu6DS. It goes directly to the #welcome channel.
Let's save the form-letter either to the project files or the wiki.

@amici-ursi I had already updated the link before you posted that :stuck_out_tongue_closed_eyes:

Fired the inactive mod in ImagesOfOhio and added it to the list.

Mail sent.


Added CodeCarbon-based kWh tracking for training, devtest and evaluation

as title implies.
Also made changes so the recipe for 2022 challenge is compatible with latest torch version (1.11.0) + fixed some installation issues.
Need to add to the README.md some instructions on how to interpret and where to find codecarbon kWh energy consumption.

Also updated README.md with instructions

I should ve addressed your comments


[feat]: request password Reset functionality

I would like to implement a password reset functionality that includes:
An endpoint to generate a password reset link.
A link where users can enter their new password and have it reset.
A comprehensive suite of tests to ensure the functionality works as expected, including:

test_reset_password_success: Verify successful password reset.
test_reset_password_invalid_token: Handle cases with an invalid reset token.
test_reset_password_user_not_found: Handle cases where the user is not found.
test_reset_password_passwords_do_not_match: Ensure passwords match during reset.
test_reset_password_database_error: Handle potential database errors.
test_create_valid_reset_link: Verify the creation of a valid reset link.
test_create_reset_link_invalid_email: Handle cases with an invalid email for reset link creation.

Additional context
The password reset functionality has been implemented and tested successfully using pytest. All test cases passed, ensuring robustness and reliability. This feature will greatly enhance user experience by allowing them to reset their passwords seamlessly.

Approved


Nopatch groff CVE-2000-0803

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[ ] Ready to merge

Summary
groff CVE-2000-0803 is unpatched. Centos & Fedora do not appear to address this CVE either.
Change Log

Nopatch groff CVE-2000-0803
Unify changelog format for groff.spec

Does this affect the toolchain?

NO
Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-2000-0803

Test Methodology

make 'input-srpms' to validate spec file format.

Very few people will use groff by itself these days, so the impact in Mariner, even if this is unpatched, is minimal.  (Groff is used by man pages, but that's fine as far as this vulnerability is concerned, because those are provided by the system.)


Pipeline editor: dark theme uses low contrast color scheme

Color scheme used by JupyterLab (relatively high contrast between font color and background):

Color scheme used by Elyra/pipeline editor (low contrast between font color and background):

This is blocked by our updating to a newer version of canvas. The version Elyra currently uses doesn't support svgs for the toolbar so we can't edit the color dynamically. This has been address in later versions of canvas and will be an easy fix once we update the canvas version (tracked in #645).

Icons passed to the current version of canvas being used displayed as img instead of svg and thus cannot be easily styled. An update has been added to the recent version of canvas which allows to passing of React components as icons which should allow for better and more easily styling the icons.
Per previous discussion (https://github.com/elyra-ai/elyra/pull/706#pullrequestreview-443437599), it was initially decided to leave the icons blue until the canvas version is upgraded. Upon further investigation, I was able to find workaround. Since image colors can't be changed via css I instead replace the images entirely when the theme is changed. This should suffice until canvas is upgraded.
See PR #743


Fix error due to missing 'priority' field default

Fix error due to missing 'priority' field default

I think I'd prefer to solve this in the code rather than the schema. 'blank' isn't exactly a default that seems like it should be explicitly set. The schema defaults would be more for a config editor, like what settings would already have values by default.

 I much rather set these values via a prepare config method.
However, I didn't make this plugin, just upgraded it a little. I do however plan to refactor it and add some more missing functionality.
In the mean time, I think it's worth pushing this as this addresses a crash that my previous pr caused.

I mean just change line 69 to priority = config.get("priority", "")

Yeah, obviously that's the best usage but I chose to remain consistent with the other parameters.
But whatever, if that's what you want I'll change it.

Ahh, I see. You mean the other params are also setting their defaults that way, didn't even look at that. Yeah, I don't care then, it can all be cleaned up later if you want.

Yeah, i rather keep consistency for now so the refactor will go smoother.


Add helm & kustomize licenses into images

Move creation of LICENSES.txt into the release build image. This allows inclusion of the binary dependency licenses, which are not vendored.

Blocked on https://github.com/GoogleContainerTools/kpt-config-sync/pull/516

/retest
Looks like the same old resource contention issue, but I'm not sure.
    testlogger.go:65: WatchObject(Deployment resource-group-system/resource-group-controller-manager) watched for 6m0.000664593s
    new.go:414: ERROR: waiting for ConfigSync Deployments to become available: WatchObject(Deployment resource-group-system/resource-group-controller-manager) timed out waiting for predicates: expected Deployment resource-group-system/resource-group-controller-manager to have status "Current", but got "InProgress"

/retest
Unrelated flake:
=== CONT  TestInvalidPolicyDir
    new.go:440: ERROR: timed out waiting for metrics predicate[0]: no results from prometheus query: config_sync_last_sync_timestamp{commit="4b93c260d938d4c7988b618cefe172d7b63809a7", component="otel-collector", k8s_pod_name="root-reconciler-5f845f8d8f-w9gf5", status="success"}


Document event schema and writing tests

I added a description of our event schema to the docs. We already have it in the comments from the generator and it is available on the Open Civic Data site, but I thought it made sense to have it in our docs for ease of access.
I also added some words about the dev process and opening a pull request. It's a start, and I imagine we'll continue to develop that content over time.

This should resolve #10 and #29.

Also addresses #31.

Excellent. I want to do some more editing and work on this, as well, so thanks for pushing it forward.


HA 0.92 N26 invalid config

There are not so many configurations required for N26 however it doesn't work for me
From documentation:
Example configuration.yaml entry
n26:
username: YOUR_EMAIL
password: YOUR_PASSWORD
My Config:
in configuration.yaml
n26:
  username<EMAIL_ADDRESS>  password: 12345ASDF

Is there any other silly thing I might did wrong?
Or there some typos in documentation and in fact config should look a bit different?

How "doesn't work". Any error log?

You may need quota your password, if there was special chars in it.

cc @markusressel

@awarecan No special characters in it, just letters and digits but even quoting didn't solve anything
regarding the error: nothing useful, just complaining about config validation in Notifications:
Invalid Config:
the following component or platform ...
n26
Please check your config

From the log:
File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='api.tech26.de', port=443): Max retries exceeded with url: /api/v2/cards (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f8bce0fd0>: Failed to establish a new connection: [Errno -3] Try again'))

I'll have a look, please be patient :)

From the log:
File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='api.tech26.de', port=443): Max retries exceeded with url: /api/v2/cards (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f8bce0fd0>: Failed to establish a new connection: [Errno -3] Try again'))

This doesn't look like an error because of an invalid config though.
How can you get an error in the log as well as an invalid config error? o.O
If the config is wrong (which it isn't if you quoted everything just to be safe) then the component shouldn't even initialize.
The second error looks like the the component was not able to make a connection to the n26 api.
Can the device you are running Home Assistant on reach the internet?

1)can the device you are running Home Assistant on reach the internet?
Yes - it's behind NAT but can access internet
2)How can you get an error in the log as well as an invalid config error? o.O
Simple :)
It did try to initialise component but failed and fired notification about bad config.
In fact - you are right, there is nothing wrong with config itself.
In dev-info section there were 4 main records about n26 platform:
Error during setup of component n26
8:19 PM components/n26/init.py (ERROR)
Setup of input_number is taking over 10 seconds.
8:19 PM main.py (WARNING)
Setup of input_boolean is taking over 10 seconds.
8:19 PM main.py (WARNING)
Setup of n26 is taking over 10 seconds.
8:19 PM main.py (WARNING)
The error log about no ability to create session was captured if to extend this record:
8:19 PM components/n26/init.py (ERROR)

If the password or the username (where the password doesn't matter) is wrong you should get an error similar to this:
2019-04-25 21:52:49 ERROR (SyncWorker_12) [homeassistant.components.n26] 400 Client Error: Bad Request for url: https://api.tech26.de/oauth/token

So I don't think it has to do with the component itself but some kind of networking problem.

Is that possible n26 has different URL for different region

Is that possible n26 has different URL for different region
Could be. What region are you from @Snakesms ?
The url should be accessible though as long as they don't completely block it.

@Snakesms Can you access the url mentioned in the error from your desktop PC? A login dialog should popup:

I'm in UK
I did try to open: https://api.tech26.de/oauth/token
and I can successfully open it from my PC and from HA host:
core-ssh:~# curl https://api.tech26.de/oauth2/token
{"timestamp":"2019-04-25T20:10:44.315+0000","status":401,"error":"Unauthorized","message":"Unauthorized","path":"/oauth2/token"}core-ssh:~#

However with my correct password I can authenticate to: https://app.n26.com (internet-banking)
but CAN'T authenticate to https://api.tech26.de/oauth2/token or https://api.tech26.de/oauth2/token
are you sure that no special permissions/credentials required for using api?

This is expected, the basic auth does not require your credentials as the API uses OAUTH json tokens to authenticate you after basic auth so it's not that simple to test it with only a browser.
The api implementation is quite simple. If you can read python I recommend looking into this file:
https://github.com/femueller/python-n26/blob/master/n26/api.py#L9
The line that is highlighted there has the basic header token that is needed.

Yeah I can read python but don't have time to do it today unfortunately.
Raised this topic as I thought I'm doing something silly but looks like not and its required deeper investigation...
Thanks for your help anyway

No problem, have a look at my edit above if you have the time.
I also found this:
https://community.home-assistant.io/t/telegram-bot-error/80543
This seems to be a pretty common issue...


Graphite Not showing data from all nodes

I am using graphite with a 5 node cluster and Replication factor 2. I am using grafana on top of it.
Below are my cluster settings.
REMOTE_EXCLUDE_LOCAL = True
CLUSTER_SERVERS = ['xxx.xx.xx.71:8081', 'xxx.xx.xx.61:8081', 'xxx.xx.xx.72:8081', 'xxx.xx.xx.73:8081', 'xxx.xx.xx75:8081']
REMOTE_RETRY_DELAY = 0
REMOTE_STORE_MERGE_RESULTS=True
While fetching data I am getting random data.. for the first time I am getting 8 data points and if I refresh it then I am getting only 2 data points. Again if I refresh the dashboard I am getting 8 data points and after that again 2 data points.
Is there any other setting I need to do for getting consistent data?

After refresh

Also, it is showing the below error in logs.
HTTPConnectionPool(host='<IP_ADDRESS>', port=8081): Max retries exceeded with url: /render/?format=pickle&local=1&noCache=1&from=1630305919&until=1630309519&target=

 (Caused by ProtocolError('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')))

Expected behavior
The data should be consistent and merge from all nodes
Environment

OS flavor: Ubuntu
Graphite-web version :  1.1.7
Python version 3.8

Hi @AshishVerma7690
What's installed on these hosts on port 8081? Graphite-web or something else?
How data is distributed, by carbon relay, carboc-c-relay? What's the config of carbon?

Hi @deniszh  8081 is used for graphite-web.  Data is distributed by carbon relay.
Below is my carbon conf.
[aggregator]
DESTINATIONS = <IP_ADDRESS>:2014,<IP_ADDRESS>:2014
FORWARD_ALL = False
LINE_RECEIVER_INTERFACE = <IP_ADDRESS>
LINE_RECEIVER_PORT = 2023
LOG_LISTENER_CONNECTIONS = False
MAX_AGGREGATION_INTERVALS = 5
MAX_DATAPOINTS_PER_MESSAGE = 500
MAX_QUEUE_SIZE = 10000
PICKLE_RECEIVER_INTERFACE = <IP_ADDRESS>
PICKLE_RECEIVER_PORT = 2024
REPLICATION_FACTOR = 1
USE_FLOW_CONTROL = True

[cache]
CACHE_QUERY_INTERFACE = <IP_ADDRESS>
CACHE_QUERY_PORT = 7002
CACHE_WRITE_STRATEGY = sorted
ENABLE_LOGROTATION = True
ENABLE_TAGS = False
ENABLE_UDP_LISTENER = True
LINE_RECEIVER_INTERFACE = <IP_ADDRESS>
LINE_RECEIVER_PORT = 2013
LOCAL_DATA_DIR = /bp2/data/graphite/storage/whisper/
LOG_CACHE_HITS = False
LOG_CACHE_QUEUE_SORTS = False
LOG_CREATES = False
LOG_DIR = /bp2/data/graphite/storage/log/
LOG_LISTENER_CONNECTIONS = False
LOG_UPDATES = False
MAX_CACHE_SIZE = inf
MAX_CREATES_PER_MINUTE = 1000
MAX_UPDATES_PER_SECOND = 1000
MAX_UPDATES_PER_SECOND_ON_SHUTDOWN = 1000
PICKLE_RECEIVER_INTERFACE = <IP_ADDRESS>
PICKLE_RECEIVER_PORT = 2014
PID_DIR = /dev/shm
STORAGE_DIR = /bp2/data/graphite/storage/
UDP_RECEIVER_INTERFACE = <IP_ADDRESS>
UDP_RECEIVER_PORT = 2013
USER =
USE_FLOW_CONTROL = True
USE_INSECURE_UNPICKLER = False
WHISPER_AUTOFLUSH = False
WHISPER_FALLOCATE_CREATE = True
WHITELISTS_DIR = /bp2/data/graphite/storage/lists/

[relay]
DESTINATIONS = <IP_ADDRESS>:2014,<IP_ADDRESS>:2014
ENABLE_UDP_LISTENER = True
LINE_RECEIVER_INTERFACE = <IP_ADDRESS>
LINE_RECEIVER_PORT = 2003
LOG_LISTENER_CONN_SUCCESS = False
MAX_DATAPOINTS_PER_MESSAGE = 500
MAX_QUEUE_SIZE = 30000
PICKLE_RECEIVER_INTERFACE = <IP_ADDRESS>
PICKLE_RECEIVER_PORT = 2004
QUEUE_LOW_WATERMARK_PCT = 0.8
RELAY_METHOD = consistent-hashing
REPLICATION_FACTOR = 2
UDP_RECEIVER_INTERFACE = <IP_ADDRESS>
UDP_RECEIVER_PORT = 2003
USE_FLOW_CONTROL = True
USE_WHITELIST = True

But why relay have only 2 destinations but you have 5 servers in Graphite cluster?

Ah. Sorry then, I have no ideas why data could be inconsistent, or why do you have errors in logs as above.

Some error logs:
2021-08-31,01:58:14.047 :: Exception during fetch for ['*.kafka.*.kafka.topicOffsets.{BPCORRELATOR,ConfigMgmt,Discovery,IFD,NSI,PINPOINT,RaProviderEventManager-0,RaProviderEventManager-1,RaProviderEventManager-2,TDC,aeprocessor,aeprocessor0,aeprocessor1,api-gw_0,api-gw_1,asset-area-ansible,asset-area-bpmn,asset-area-generic,asset-area-model-definitions,asset-area-terraform,bp_commissioning,chronos,com_cyaninc_bpocore_auth_troneventmonitor,crinoidapi_kompressor,equipmenttopologyplanning,fregraph,invhist_username_cache_0,invhist_username_cache_1,kompressor,mcpviewalarmcorrelator,perfg-monitor-servicetrail,perfg-monitor-viability,perfg-oms,perfg-plannedfiberloss,perfg-scheduler-ppg,perfg_equipment_v1,perfg_equipmentstaticspec_v1,perfg_fre_v1,perfg_nc_v1,perfg_tpe_v1,planningintent,pm-discovery,pm-ingestion,pm-metrics_34741333,pm-metrics_666918844,pm-nsi,pm-scheduler,pm-thresholds,pmp-derived,pmprocessor-0,pmprocessor-1,pmprocessor_derived_943239074,pmprocessor_derived_979700869,pmprocessor_threshold_43780691,pmprocessor_threshold_57930108,policy,projectmanagement,session-event-monitors,svchist_pipeline,tpegraph,viability,watcher}.{bp_aeprocessor_v1_alarmsforcorrelation,bp_aeprocessor_v1_filters_pool,bp_aeprocessor_v1_notifyhosts,bp_aeprocessor_v1_notifytapi,bp_aeprocessor_v1_operations,bp_aeprocessor_v2_0_alarms,bp_aeprocessor_v2_geo_sync,bp_bpoifd_v1_changes_services,bp_ciena_watcher_v2_geo,bp_ciena_watcher_v2_geo_in,bp_config_api_v1_backup,bp_config_api_v1_restore,bp_config_api_v1_upgrade,bp_correlation_v1_changes_alarms,bp_correlation_v1_changes_device,bp_correlation_v1_changes_inventoryRelationship,bp_crinoid_v1_kompressor,bp_crinoid_v1_kompressor_in,bp_discovery_v1_alarms,bp_discovery_v2_0_changes_discoverySyncRequest,bp_discovery_v2_0_changes_sync,bp_discovery_v2_geo,bp_discovery_v2_geo_in,bp_discovery_v3_changes_managementSession,bp_gcs_v2_kompressor,bp_hpmra_v2_pm,bp_ifd_v3_0_srlgJobs,bp_kafkacomet_v1_channel_administration,bp_licensing_v1_geo_sync,bp_nms_notreplicated_v1_alarms,bp_nms_replicated_v1_alarms,bp_nsi_v1_alarms,bp_nsi_v1_changes_equipmentStaticSpec,bp_nsi_v1_changes_sync,bp_nsi_v1_internal_changes_inventory,bp_nsi_v1_internal_group,bp_nsi_v1_internal_stitch,bp_nsi_v1_internal_utilization,bp_nsi_v2_0_changes_nc,bp_nsi_v2_0_validation,bp_nsi_v3_changes_equipment,bp_nsi_v3_changes_fre,bp_nsi_v3_changes_tpe,bp_nsi_v3_validation,bp_nsi_v5_changes_geo_in,bp_perfg_v1_scheduler_ppg,bp_perfg_v2_monitor_servicetrail,bp_perfg_v2_monitor_viability,bp_pinpoint_v1_otdr_state,bp_pm_v1_geo_sync,bp_pmp_v1_pm,bp_pmprocessor_v1_datastore,bp_projectmanagement_v2_cancelled,bp_projectmanagement_v2_commit,bp_projectmanagement_v2_deleted,bp_projectmanagement_v2_list_deleted,bp_projectmanagement_v2_list_projectadded,bp_projectmanagement_v2_list_statechange,bp_projectmanagement_v2_networkchanged,bp_projectmanagement_v2_projectvalidate,bp_projectmanagement_v2_statechange,bp_ra_v1_EroEvent,bp_ra_v1_SelectiveSync,bp_ra_v1_alarms,bp_ra_v1_diagnostics_loopback,bp_ra_v1_nodecommissioning,bp_ra_v1_pm,bp_ra_v1_pm_thresholds,bp_ra_v1_poke,bp_ra_v2_0_sync,bp_rasdk_v1_changes,bp_stitcher_v1_changes_iplinkfre,bp_stitcher_v2_changes_tpe,bp_stitcher_v2_patch_fre,bp_stitcher_v3_changes_fre,bp_tdc_v1_tests,bp_topologyplanning_v1_planneddata_fiberloss_changed,bp_topologyplanning_v1_planneddata_omssnr_changed,bp_tron_v1_changes,bp_tron_v1_kompressor,bp_view_alarmcorrelation_publish,chronos_dispatch_queue,chronos_scheduling_queue,chronos_sharding_queues_0,chronos_sharding_queues_1,com_cyaninc_bp_market,cr,freg2svchist,pm_scheduling}.committed'] after 0.801729s: Error requesting http://<IP_ADDRESS>:8081/render/?format=pickle&local=1&noCache=1&from=1630367893&until=1630389493&target=%2A.kafka.%2A.kafka.topicOffsets.%7BBPCORRELATOR%2CConfigMgmt%2CDiscovery%2CIFD%2CNSI%2CPINPOINT%2CRaProviderEventManager-0%2CRaProviderEventManager-1%2CRaProviderEventManager-2%2CTDC%2Caeprocessor%2Caeprocessor0%2Caeprocessor1%2Capi-gw_0%2Capi-gw_1%2Casset-area-ansible%2Casset-area-bpmn%2Casset-area-generic%2Casset-area-model-definitions%2Casset-area-terraform%2Cbp_commissioning%2Cchronos%2Ccom_cyaninc_bpocore_auth_troneventmonitor%2Ccrinoidapi_kompressor%2Cequipmenttopologyplanning%2Cfregraph%2Cinvhist_username_cache_0%2Cinvhist_username_cache_1%2Ckompressor%2Cmcpviewalarmcorrelator%2Cperfg-monitor-servicetrail%2Cperfg-monitor-viability%2Cperfg-oms%2Cperfg-plannedfiberloss%2Cperfg-scheduler-ppg%2Cperfg_equipment_v1%2Cperfg_equipmentstaticspec_v1%2Cperfg_fre_v1%2Cperfg_nc_v1%2Cperfg_tpe_v1%2Cplanningintent%2Cpm-discovery%2Cpm-ingestion%2Cpm-metrics_34741333%2Cpm-metrics_666918844%2Cpm-nsi%2Cpm-scheduler%2Cpm-thresholds%2Cpmp-derived%2Cpmprocessor-0%2Cpmprocessor-1%2Cpmprocessor_derived_943239074%2Cpmprocessor_derived_979700869%2Cpmprocessor_threshold_43780691%2Cpmprocessor_threshold_57930108%2Cpolicy%2Cprojectmanagement%2Csession-event-monitors%2Csvchist_pipeline%2Ctpegraph%2Cviability%2Cwatcher%7D.%7Bbp_aeprocessor_v1_alarmsforcorrelation%2Cbp_aeprocessor_v1_filters_pool%2Cbp_aeprocessor_v1_notifyhosts%2Cbp_aeprocessor_v1_notifytapi%2Cbp_aeprocessor_v1_operations%2Cbp_aeprocessor_v2_0_alarms%2Cbp_aeprocessor_v2_geo_sync%2Cbp_bpoifd_v1_changes_services%2Cbp_ciena_watcher_v2_geo%2Cbp_ciena_watcher_v2_geo_in%2Cbp_config_api_v1_backup%2Cbp_config_api_v1_restore%2Cbp_config_api_v1_upgrade%2Cbp_correlation_v1_changes_alarms%2Cbp_correlation_v1_changes_device%2Cbp_correlation_v1_changes_inventoryRelationship%2Cbp_crinoid_v1_kompressor%2Cbp_crinoid_v1_kompressor_in%2Cbp_discovery_v1_alarms%2Cbp_discovery_v2_0_changes_discoverySyncRequest%2Cbp_discovery_v2_0_changes_sync%2Cbp_discovery_v2_geo%2Cbp_discovery_v2_geo_in%2Cbp_discovery_v3_changes_managementSession%2Cbp_gcs_v2_kompressor%2Cbp_hpmra_v2_pm%2Cbp_ifd_v3_0_srlgJobs%2Cbp_kafkacomet_v1_channel_administration%2Cbp_licensing_v1_geo_sync%2Cbp_nms_notreplicated_v1_alarms%2Cbp_nms_replicated_v1_alarms%2Cbp_nsi_v1_alarms%2Cbp_nsi_v1_changes_equipmentStaticSpec%2Cbp_nsi_v1_changes_sync%2Cbp_nsi_v1_internal_changes_inventory%2Cbp_nsi_v1_internal_group%2Cbp_nsi_v1_internal_stitch%2Cbp_nsi_v1_internal_utilization%2Cbp_nsi_v2_0_changes_nc%2Cbp_nsi_v2_0_validation%2Cbp_nsi_v3_changes_equipment%2Cbp_nsi_v3_changes_fre%2Cbp_nsi_v3_changes_tpe%2Cbp_nsi_v3_validation%2Cbp_nsi_v5_changes_geo_in%2Cbp_perfg_v1_scheduler_ppg%2Cbp_perfg_v2_monitor_servicetrail%2Cbp_perfg_v2_monitor_viability%2Cbp_pinpoint_v1_otdr_state%2Cbp_pm_v1_geo_sync%2Cbp_pmp_v1_pm%2Cbp_pmprocessor_v1_datastore%2Cbp_projectmanagement_v2_cancelled%2Cbp_projectmanagement_v2_commit%2Cbp_projectmanagement_v2_deleted%2Cbp_projectmanagement_v2_list_deleted%2Cbp_projectmanagement_v2_list_projectadded%2Cbp_projectmanagement_v2_list_statechange%2Cbp_projectmanagement_v2_networkchanged%2Cbp_projectmanagement_v2_projectvalidate%2Cbp_projectmanagement_v2_statechange%2Cbp_ra_v1_EroEvent%2Cbp_ra_v1_SelectiveSync%2Cbp_ra_v1_alarms%2Cbp_ra_v1_diagnostics_loopback%2Cbp_ra_v1_nodecommissioning%2Cbp_ra_v1_pm%2Cbp_ra_v1_pm_thresholds%2Cbp_ra_v1_poke%2Cbp_ra_v2_0_sync%2Cbp_rasdk_v1_changes%2Cbp_stitcher_v1_changes_iplinkfre%2Cbp_stitcher_v2_changes_tpe%2Cbp_stitcher_v2_patch_fre%2Cbp_stitcher_v3_changes_fre%2Cbp_tdc_v1_tests%2Cbp_topologyplanning_v1_planneddata_fiberloss_changed%2Cbp_topologyplanning_v1_planneddata_omssnr_changed%2Cbp_tron_v1_changes%2Cbp_tron_v1_kompressor%2Cbp_view_alarmcorrelation_publish%2Cchronos_dispatch_queue%2Cchronos_scheduling_queue%2Cchronos_sharding_queues_0%2Cchronos_sharding_queues_1%2Ccom_cyaninc_bp_market%2Ccr%2Cfreg2svchist%2Cpm_scheduling%7D.committed&now=1630389493: HTTPConnectionPool(host='<IP_ADDRESS>', port=8081): Max retries exceeded with url: /render/?format=pickle&local=1&noCache=1&from=1630367893&until=1630389493&target=%2A.kafka.%2A.kafka.topicOffsets.%7BBPCORRELATOR%2CConfigMgmt%2CDiscovery%2CIFD%2CNSI%2CPINPOINT%2CRaProviderEventManager-0%2CRaProviderEventManager-1%2CRaProviderEventManager-2%2CTDC%2Caeprocessor%2Caeprocessor0%2Caeprocessor1%2Capi-gw_0%2Capi-gw_1%2Casset-area-ansible%2Casset-area-bpmn%2Casset-area-generic%2Casset-area-model-definitions%2Casset-area-terraform%2Cbp_commissioning%2Cchronos%2Ccom_cyaninc_bpocore_auth_troneventmonitor%2Ccrinoidapi_kompressor%2Cequipmenttopologyplanning%2Cfregraph%2Cinvhist_username_cache_0%2Cinvhist_username_cache_1%2Ckompressor%2Cmcpviewalarmcorrelator%2Cperfg-monitor-servicetrail%2Cperfg-monitor-viability%2Cperfg-oms%2Cperfg-plannedfiberloss%2Cperfg-scheduler-ppg%2Cperfg_equipment_v1%2Cperfg_equipmentstaticspec_v1%2Cperfg_fre_v1%2Cperfg_nc_v1%2Cperfg_tpe_v1%2Cplanningintent%2Cpm-discovery%2Cpm-ingestion%2Cpm-metrics_34741333%2Cpm-metrics_666918844%2Cpm-nsi%2Cpm-scheduler%2Cpm-thresholds%2Cpmp-derived%2Cpmprocessor-0%2Cpmprocessor-1%2Cpmprocessor_derived_943239074%2Cpmprocessor_derived_979700869%2Cpmprocessor_threshold_43780691%2Cpmprocessor_threshold_57930108%2Cpolicy%2Cprojectmanagement%2Csession-event-monitors%2Csvchist_pipeline%2Ctpegraph%2Cviability%2Cwatcher%7D.%7Bbp_aeprocessor_v1_alarmsforcorrelation%2Cbp_aeprocessor_v1_filters_pool%2Cbp_aeprocessor_v1_notifyhosts%2Cbp_aeprocessor_v1_notifytapi%2Cbp_aeprocessor_v1_operations%2Cbp_aeprocessor_v2_0_alarms%2Cbp_aeprocessor_v2_geo_sync%2Cbp_bpoifd_v1_changes_services%2Cbp_ciena_watcher_v2_geo%2Cbp_ciena_watcher_v2_geo_in%2Cbp_config_api_v1_backup%2Cbp_config_api_v1_restore%2Cbp_config_api_v1_upgrade%2Cbp_correlation_v1_changes_alarms%2Cbp_correlation_v1_changes_device%2Cbp_correlation_v1_changes_inventoryRelationship%2Cbp_crinoid_v1_kompressor%2Cbp_crinoid_v1_kompressor_in%2Cbp_discovery_v1_alarms%2Cbp_discovery_v2_0_changes_discoverySyncRequest%2Cbp_discovery_v2_0_changes_sync%2Cbp_discovery_v2_geo%2Cbp_discovery_v2_geo_in%2Cbp_discovery_v3_changes_managementSession%2Cbp_gcs_v2_kompressor%2Cbp_hpmra_v2_pm%2Cbp_ifd_v3_0_srlgJobs%2Cbp_kafkacomet_v1_channel_administration%2Cbp_licensing_v1_geo_sync%2Cbp_nms_notreplicated_v1_alarms%2Cbp_nms_replicated_v1_alarms%2Cbp_nsi_v1_alarms%2Cbp_nsi_v1_changes_equipmentStaticSpec%2Cbp_nsi_v1_changes_sync%2Cbp_nsi_v1_internal_changes_inventory%2Cbp_nsi_v1_internal_group%2Cbp_nsi_v1_internal_stitch%2Cbp_nsi_v1_internal_utilization%2Cbp_nsi_v2_0_changes_nc%2Cbp_nsi_v2_0_validation%2Cbp_nsi_v3_changes_equipment%2Cbp_nsi_v3_changes_fre%2Cbp_nsi_v3_changes_tpe%2Cbp_nsi_v3_validation%2Cbp_nsi_v5_changes_geo_in%2Cbp_perfg_v1_scheduler_ppg%2Cbp_perfg_v2_monitor_servicetrail%2Cbp_perfg_v2_monitor_viability%2Cbp_pinpoint_v1_otdr_state%2Cbp_pm_v1_geo_sync%2Cbp_pmp_v1_pm%2Cbp_pmprocessor_v1_datastore%2Cbp_projectmanagement_v2_cancelled%2Cbp_projectmanagement_v2_commit%2Cbp_projectmanagement_v2_deleted%2Cbp_projectmanagement_v2_list_deleted%2Cbp_projectmanagement_v2_list_projectadded%2Cbp_projectmanagement_v2_list_statechange%2Cbp_projectmanagement_v2_networkchanged%2Cbp_projectmanagement_v2_projectvalidate%2Cbp_projectmanagement_v2_statechange%2Cbp_ra_v1_EroEvent%2Cbp_ra_v1_SelectiveSync%2Cbp_ra_v1_alarms%2Cbp_ra_v1_diagnostics_loopback%2Cbp_ra_v1_nodecommissioning%2Cbp_ra_v1_pm%2Cbp_ra_v1_pm_thresholds%2Cbp_ra_v1_poke%2Cbp_ra_v2_0_sync%2Cbp_rasdk_v1_changes%2Cbp_stitcher_v1_changes_iplinkfre%2Cbp_stitcher_v2_changes_tpe%2Cbp_stitcher_v2_patch_fre%2Cbp_stitcher_v3_changes_fre%2Cbp_tdc_v1_tests%2Cbp_topologyplanning_v1_planneddata_fiberloss_changed%2Cbp_topologyplanning_v1_planneddata_omssnr_changed%2Cbp_tron_v1_changes%2Cbp_tron_v1_kompressor%2Cbp_view_alarmcorrelation_publish%2Cchronos_dispatch_queue%2Cchronos_scheduling_queue%2Cchronos_sharding_queues_0%2Cchronos_sharding_queues_1%2Ccom_cyaninc_bp_market%2Ccr%2Cfreg2svchist%2Cpm_scheduling%7D.committed&now=1630389493 (Caused by ProtocolError('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')))
2021-08-31,01:58:14.074 :: Exception during fetch for ['*.kafka.*.kafka.topicOffsets.{BPCORRELATOR,ConfigMgmt,Discovery,IFD,NSI,PINPOINT,RaProviderEventManager-0,RaProviderEventManager-1,RaProviderEventManager-2,TDC,aeprocessor,aeprocessor0,aeprocessor1,api-gw_0,api-gw_1,asset-area-ansible,asset-area-bpmn,asset-area-generic,asset-area-model-definitions,asset-area-terraform,bp_commissioning,chronos,com_cyaninc_bpocore_auth_troneventmonitor,crinoidapi_kompressor,equipmenttopologyplanning,fregraph,invhist_username_cache_0,invhist_username_cache_1,kompressor,mcpviewalarmcorrelator,perfg-monitor-servicetrail,perfg-monitor-viability,perfg-oms,perfg-plannedfiberloss,perfg-scheduler-ppg,perfg_equipment_v1,perfg_equipmentstaticspec_v1,perfg_fre_v1,perfg_nc_v1,perfg_tpe_v1,planningintent,pm-discovery,pm-ingestion,pm-metrics_34741333,pm-metrics_666918844,pm-nsi,pm-scheduler,pm-thresholds,pmp-derived,pmprocessor-0,pmprocessor-1,pmprocessor_derived_943239074,pmprocessor_derived_979700869,pmprocessor_threshold_43780691,pmprocessor_threshold_57930108,policy,projectmanagement,session-event-monitors,svchist_pipeline,tpegraph,viability,watcher}.{bp_aeprocessor_v1_alarmsforcorrelation,bp_aeprocessor_v1_filters_pool,bp_aeprocessor_v1_notifyhosts,bp_aeprocessor_v1_notifytapi,bp_aeprocessor_v1_operations,bp_aeprocessor_v2_0_alarms,bp_aeprocessor_v2_geo_sync,bp_bpoifd_v1_changes_services,bp_ciena_watcher_v2_geo,bp_ciena_watcher_v2_geo_in,bp_config_api_v1_backup,bp_config_api_v1_restore,bp_config_api_v1_upgrade,bp_correlation_v1_changes_alarms,bp_correlation_v1_changes_device,bp_correlation_v1_changes_inventoryRelationship,bp_crinoid_v1_kompressor,bp_crinoid_v1_kompressor_in,bp_discovery_v1_alarms,bp_discovery_v2_0_changes_discoverySyncRequest,bp_discovery_v2_0_changes_sync,bp_discovery_v2_geo,bp_discovery_v2_geo_in,bp_discovery_v3_changes_managementSession,bp_gcs_v2_kompressor,bp_hpmra_v2_pm,bp_ifd_v3_0_srlgJobs,bp_kafkacomet_v1_channel_administration,bp_licensing_v1_geo_sync,bp_nms_notreplicated_v1_alarms,bp_nms_replicated_v1_alarms,bp_nsi_v1_alarms,bp_nsi_v1_changes_equipmentStaticSpec,bp_nsi_v1_changes_sync,bp_nsi_v1_internal_changes_inventory,bp_nsi_v1_internal_group,bp_nsi_v1_internal_stitch,bp_nsi_v1_internal_utilization,bp_nsi_v2_0_changes_nc,bp_nsi_v2_0_validation,bp_nsi_v3_changes_equipment,bp_nsi_v3_changes_fre,bp_nsi_v3_changes_tpe,bp_nsi_v3_validation,bp_nsi_v5_changes_geo_in,bp_perfg_v1_scheduler_ppg,bp_perfg_v2_monitor_servicetrail,bp_perfg_v2_monitor_viability,bp_pinpoint_v1_otdr_state,bp_pm_v1_geo_sync,bp_pmp_v1_pm,bp_pmprocessor_v1_datastore,bp_projectmanagement_v2_cancelled,bp_projectmanagement_v2_commit,bp_projectmanagement_v2_deleted,bp_projectmanagement_v2_list_deleted,bp_projectmanagement_v2_list_projectadded,bp_projectmanagement_v2_list_statechange,bp_projectmanagement_v2_networkchanged,bp_projectmanagement_v2_projectvalidate,bp_projectmanagement_v2_statechange,bp_ra_v1_EroEvent,bp_ra_v1_SelectiveSync,bp_ra_v1_alarms,bp_ra_v1_diagnostics_loopback,bp_ra_v1_nodecommissioning,bp_ra_v1_pm,bp_ra_v1_pm_thresholds,bp_ra_v1_poke,bp_ra_v2_0_sync,bp_rasdk_v1_changes,bp_stitcher_v1_changes_iplinkfre,bp_stitcher_v2_changes_tpe,bp_stitcher_v2_patch_fre,bp_stitcher_v3_changes_fre,bp_tdc_v1_tests,bp_topologyplanning_v1_planneddata_fiberloss_changed,bp_topologyplanning_v1_planneddata_omssnr_changed,bp_tron_v1_changes,bp_tron_v1_kompressor,bp_view_alarmcorrelation_publish,chronos_dispatch_queue,chronos_scheduling_queue,chronos_sharding_queues_0,chronos_sharding_queues_1,com_cyaninc_bp_market,cr,freg2svchist,pm_scheduling}.committed'] after 0.828657s: Error requesting http://<IP_ADDRESS>:8081/render/?format=pickle&local=1&noCache=1&from=1630367893&until=1630389493&target=%2A.kafka.%2A.kafka.topicOffsets.%7BBPCORRELATOR%2CConfigMgmt%2CDiscovery%2CIFD%2CNSI%2CPINPOINT%2CRaProviderEventManager-0%2CRaProviderEventManager-1%2CRaProviderEventManager-2%2CTDC%2Caeprocessor%2Caeprocessor0%2Caeprocessor1%2Capi-gw_0%2Capi-gw_1%2Casset-area-ansible%2Casset-area-bpmn%2Casset-area-generic%2Casset-area-model-definitions%2Casset-area-terraform%2Cbp_commissioning%2Cchronos%2Ccom_cyaninc_bpocore_auth_troneventmonitor%2Ccrinoidapi_kompressor%2Cequipmenttopologyplanning%2Cfregraph%2Cinvhist_username_cache_0%2Cinvhist_username_cache_1%2Ckompressor%2Cmcpviewalarmcorrelator%2Cperfg-monitor-servicetrail%2Cperfg-monitor-viability%2Cperfg-oms%2Cperfg-plannedfiberloss%2Cperfg-scheduler-ppg%2Cperfg_equipment_v1%2Cperfg_equipmentstaticspec_v1%2Cperfg_fre_v1%2Cperfg_nc_v1%2Cperfg_tpe_v1%2Cplanningintent%2Cpm-discovery%2Cpm-ingestion%2Cpm-metrics_34741333%2Cpm-metrics_666918844%2Cpm-nsi%2Cpm-scheduler%2Cpm-thresholds%2Cpmp-derived%2Cpmprocessor-0%2Cpmprocessor-1%2Cpmprocessor_derived_943239074%2Cpmprocessor_derived_979700869%2Cpmprocessor_threshold_43780691%2Cpmprocessor_threshold_57930108%2Cpolicy%2Cprojectmanagement%2Csession-event-monitors%2Csvchist_pipeline%2Ctpegraph%2Cviability%2Cwatcher%7D.%7Bbp_aeprocessor_v1_alarmsforcorrelation%2Cbp_aeprocessor_v1_filters_pool%2Cbp_aeprocessor_v1_notifyhosts%2Cbp_aeprocessor_v1_notifytapi%2Cbp_aeprocessor_v1_operations%2Cbp_aeprocessor_v2_0_alarms%2Cbp_aeprocessor_v2_geo_sync%2Cbp_bpoifd_v1_changes_services%2Cbp_ciena_watcher_v2_geo%2Cbp_ciena_watcher_v2_geo_in%2Cbp_config_api_v1_backup%2Cbp_config_api_v1_restore%2Cbp_config_api_v1_upgrade%2Cbp_correlation_v1_changes_alarms%2Cbp_correlation_v1_changes_device%2Cbp_correlation_v1_changes_inventoryRelationship%2Cbp_crinoid_v1_kompressor%2Cbp_crinoid_v1_kompressor_in%2Cbp_discovery_v1_alarms%2Cbp_discovery_v2_0_changes_discoverySyncRequest%2Cbp_discovery_v2_0_changes_sync%2Cbp_discovery_v2_geo%2Cbp_discovery_v2_geo_in%2Cbp_discovery_v3_changes_managementSession%2Cbp_gcs_v2_kompressor%2Cbp_hpmra_v2_pm%2Cbp_ifd_v3_0_srlgJobs%2Cbp_kafkacomet_v1_channel_administration%2Cbp_licensing_v1_geo_sync%2Cbp_nms_notreplicated_v1_alarms%2Cbp_nms_replicated_v1_alarms%2Cbp_nsi_v1_alarms%2Cbp_nsi_v1_changes_equipmentStaticSpec%2Cbp_nsi_v1_changes_sync%2Cbp_nsi_v1_internal_changes_inventory%2Cbp_nsi_v1_internal_group%2Cbp_nsi_v1_internal_stitch%2Cbp_nsi_v1_internal_utilization%2Cbp_nsi_v2_0_changes_nc%2Cbp_nsi_v2_0_validation%2Cbp_nsi_v3_changes_equipment%2Cbp_nsi_v3_changes_fre%2Cbp_nsi_v3_changes_tpe%2Cbp_nsi_v3_validation%2Cbp_nsi_v5_changes_geo_in%2Cbp_perfg_v1_scheduler_ppg%2Cbp_perfg_v2_monitor_servicetrail%2Cbp_perfg_v2_monitor_viability%2Cbp_pinpoint_v1_otdr_state%2Cbp_pm_v1_geo_sync%2Cbp_pmp_v1_pm%2Cbp_pmprocessor_v1_datastore%2Cbp_projectmanagement_v2_cancelled%2Cbp_projectmanagement_v2_commit%2Cbp_projectmanagement_v2_deleted%2Cbp_projectmanagement_v2_list_deleted%2Cbp_projectmanagement_v2_list_projectadded%2Cbp_projectmanagement_v2_list_statechange%2Cbp_projectmanagement_v2_networkchanged%2Cbp_projectmanagement_v2_projectvalidate%2Cbp_projectmanagement_v2_statechange%2Cbp_ra_v1_EroEvent%2Cbp_ra_v1_SelectiveSync%2Cbp_ra_v1_alarms%2Cbp_ra_v1_diagnostics_loopback%2Cbp_ra_v1_nodecommissioning%2Cbp_ra_v1_pm%2Cbp_ra_v1_pm_thresholds%2Cbp_ra_v1_poke%2Cbp_ra_v2_0_sync%2Cbp_rasdk_v1_changes%2Cbp_stitcher_v1_changes_iplinkfre%2Cbp_stitcher_v2_changes_tpe%2Cbp_stitcher_v2_patch_fre%2Cbp_stitcher_v3_changes_fre%2Cbp_tdc_v1_tests%2Cbp_topologyplanning_v1_planneddata_fiberloss_changed%2Cbp_topologyplanning_v1_planneddata_omssnr_changed%2Cbp_tron_v1_changes%2Cbp_tron_v1_kompressor%2Cbp_view_alarmcorrelation_publish%2Cchronos_dispatch_queue%2Cchronos_scheduling_queue%2Cchronos_sharding_queues_0%2Cchronos_sharding_queues_1%2Ccom_cyaninc_bp_market%2Ccr%2Cfreg2svchist%2Cpm_scheduling%7D.committed&now=1630389493: HTTPConnectionPool(host='<IP_ADDRESS>', port=8081): Max retries exceeded with url: /render/?format=pickle&local=1&noCache=1&from=1630367893&until=1630389493&target=%2A.kafka.%2A.kafka.topicOffsets.%7BBPCORRELATOR%2CConfigMgmt%2CDiscovery%2CIFD%2CNSI%2CPINPOINT%2CRaProviderEventManager-0%2CRaProviderEventManager-1%2CRaProviderEventManager-2%2CTDC%2Caeprocessor%2Caeprocessor0%2Caeprocessor1%2Capi-gw_0%2Capi-gw_1%2Casset-area-ansible%2Casset-area-bpmn%2Casset-area-generic%2Casset-area-model-definitions%2Casset-area-terraform%2Cbp_commissioning%2Cchronos%2Ccom_cyaninc_bpocore_auth_troneventmonitor%2Ccrinoidapi_kompressor%2Cequipmenttopologyplanning%2Cfregraph%2Cinvhist_username_cache_0%2Cinvhist_username_cache_1%2Ckompressor%2Cmcpviewalarmcorrelator%2Cperfg-monitor-servicetrail%2Cperfg-monitor-viability%2Cperfg-oms%2Cperfg-plannedfiberloss%2Cperfg-scheduler-ppg%2Cperfg_equipment_v1%2Cperfg_equipmentstaticspec_v1%2Cperfg_fre_v1%2Cperfg_nc_v1%2Cperfg_tpe_v1%2Cplanningintent%2Cpm-discovery%2Cpm-ingestion%2Cpm-metrics_34741333%2Cpm-metrics_666918844%2Cpm-nsi%2Cpm-scheduler%2Cpm-thresholds%2Cpmp-derived%2Cpmprocessor-0%2Cpmprocessor-1%2Cpmprocessor_derived_943239074%2Cpmprocessor_derived_979700869%2Cpmprocessor_threshold_43780691%2Cpmprocessor_threshold_57930108%2Cpolicy%2Cprojectmanagement%2Csession-event-monitors%2Csvchist_pipeline%2Ctpegraph%2Cviability%2Cwatcher%7D.%7Bbp_aeprocessor_v1_alarmsforcorrelation%2Cbp_aeprocessor_v1_filters_pool%2Cbp_aeprocessor_v1_notifyhosts%2Cbp_aeprocessor_v1_notifytapi%2Cbp_aeprocessor_v1_operations%2Cbp_aeprocessor_v2_0_alarms%2Cbp_aeprocessor_v2_geo_sync%2Cbp_bpoifd_v1_changes_services%2Cbp_ciena_watcher_v2_geo%2Cbp_ciena_watcher_v2_geo_in%2Cbp_config_api_v1_backup%2Cbp_config_api_v1_restore%2Cbp_config_api_v1_upgrade%2Cbp_correlation_v1_changes_alarms%2Cbp_correlation_v1_changes_device%2Cbp_correlation_v1_changes_inventoryRelationship%2Cbp_crinoid_v1_kompressor%2Cbp_crinoid_v1_kompressor_in%2Cbp_discovery_v1_alarms%2Cbp_discovery_v2_0_changes_discoverySyncRequest%2Cbp_discovery_v2_0_changes_sync%2Cbp_discovery_v2_geo%2Cbp_discovery_v2_geo_in%2Cbp_discovery_v3_changes_managementSession%2Cbp_gcs_v2_kompressor%2Cbp_hpmra_v2_pm%2Cbp_ifd_v3_0_srlgJobs%2Cbp_kafkacomet_v1_channel_administration%2Cbp_licensing_v1_geo_sync%2Cbp_nms_notreplicated_v1_alarms%2Cbp_nms_replicated_v1_alarms%2Cbp_nsi_v1_alarms%2Cbp_nsi_v1_changes_equipmentStaticSpec%2Cbp_nsi_v1_changes_sync%2Cbp_nsi_v1_internal_changes_inventory%2Cbp_nsi_v1_internal_group%2Cbp_nsi_v1_internal_stitch%2Cbp_nsi_v1_internal_utilization%2Cbp_nsi_v2_0_changes_nc%2Cbp_nsi_v2_0_validation%2Cbp_nsi_v3_changes_equipment%2Cbp_nsi_v3_changes_fre%2Cbp_nsi_v3_changes_tpe%2Cbp_nsi_v3_validation%2Cbp_nsi_v5_changes_geo_in%2Cbp_perfg_v1_scheduler_ppg%2Cbp_perfg_v2_monitor_servicetrail%2Cbp_perfg_v2_monitor_viability%2Cbp_pinpoint_v1_otdr_state%2Cbp_pm_v1_geo_sync%2Cbp_pmp_v1_pm%2Cbp_pmprocessor_v1_datastore%2Cbp_projectmanagement_v2_cancelled%2Cbp_projectmanagement_v2_commit%2Cbp_projectmanagement_v2_deleted%2Cbp_projectmanagement_v2_list_deleted%2Cbp_projectmanagement_v2_list_projectadded%2Cbp_projectmanagement_v2_list_statechange%2Cbp_projectmanagement_v2_networkchanged%2Cbp_projectmanagement_v2_projectvalidate%2Cbp_projectmanagement_v2_statechange%2Cbp_ra_v1_EroEvent%2Cbp_ra_v1_SelectiveSync%2Cbp_ra_v1_alarms%2Cbp_ra_v1_diagnostics_loopback%2Cbp_ra_v1_nodecommissioning%2Cbp_ra_v1_pm%2Cbp_ra_v1_pm_thresholds%2Cbp_ra_v1_poke%2Cbp_ra_v2_0_sync%2Cbp_rasdk_v1_changes%2Cbp_stitcher_v1_changes_iplinkfre%2Cbp_stitcher_v2_changes_tpe%2Cbp_stitcher_v2_patch_fre%2Cbp_stitcher_v3_changes_fre%2Cbp_tdc_v1_tests%2Cbp_topologyplanning_v1_planneddata_fiberloss_changed%2Cbp_topologyplanning_v1_planneddata_omssnr_changed%2Cbp_tron_v1_changes%2Cbp_tron_v1_kompressor%2Cbp_view_alarmcorrelation_publish%2Cchronos_dispatch_queue%2Cchronos_scheduling_queue%2Cchronos_sharding_queues_0%2Cchronos_sharding_queues_1%2Ccom_cyaninc_bp_market%2Ccr%2Cfreg2svchist%2Cpm_scheduling%7D.committed&now=1630389493 (Caused by ProtocolError('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')))
2021-08-31,01:58:14.297 :: graphite.render.datalib.fetchData :: lookup and merge of "*.kafka.*.kafka.topicOffsets.{BPCORRELATOR,ConfigMgmt,Discovery,IFD,NSI,PINPOINT,RaProviderEventManager-0,RaProviderEventManager-1,RaProviderEventManager-2,TDC,aeprocessor,aeprocessor0,aeprocessor1,api-gw_0,api-gw_1,asset-area-ansible,asset-area-bpmn,asset-area-generic,asset-area-model-definitions,asset-area-terraform,bp_commissioning,chronos,com_cyaninc_bpocore_auth_troneventmonitor,crinoidapi_kompressor,equipmenttopologyplanning,fregraph,invhist_username_cache_0,invhist_username_cache_1,kompressor,mcpviewalarmcorrelator,perfg-monitor-servicetrail,perfg-monitor-viability,perfg-oms,perfg-plannedfiberloss,perfg-scheduler-ppg,perfg_equipment_v1,perfg_equipmentstaticspec_v1,perfg_fre_v1,perfg_nc_v1,perfg_tpe_v1,planningintent,pm-discovery,pm-ingestion,pm-metrics_34741333,pm-metrics_666918844,pm-nsi,pm-scheduler,pm-thresholds,pmp-derived,pmprocessor-0,pmprocessor-1,pmprocessor_derived_943239074,pmprocessor_derived_979700869,pmprocessor_threshold_43780691,pmprocessor_threshold_57930108,policy,projectmanagement,session-event-monitors,svchist_pipeline,tpegraph,viability,watcher}.{bp_aeprocessor_v1_alarmsforcorrelation,bp_aeprocessor_v1_filters_pool,bp_aeprocessor_v1_notifyhosts,bp_aeprocessor_v1_notifytapi,bp_aeprocessor_v1_operations,bp_aeprocessor_v2_0_alarms,bp_aeprocessor_v2_geo_sync,bp_bpoifd_v1_changes_services,bp_ciena_watcher_v2_geo,bp_ciena_watcher_v2_geo_in,bp_config_api_v1_backup,bp_config_api_v1_restore,bp_config_api_v1_upgrade,bp_correlation_v1_changes_alarms,bp_correlation_v1_changes_device,bp_correlation_v1_changes_inventoryRelationship,bp_crinoid_v1_kompressor,bp_crinoid_v1_kompressor_in,bp_discovery_v1_alarms,bp_discovery_v2_0_changes_discoverySyncRequest,bp_discovery_v2_0_changes_sync,bp_discovery_v2_geo,bp_discovery_v2_geo_in,bp_discovery_v3_changes_managementSession,bp_gcs_v2_kompressor,bp_hpmra_v2_pm,bp_ifd_v3_0_srlgJobs,bp_kafkacomet_v1_channel_administration,bp_licensing_v1_geo_sync,bp_nms_notreplicated_v1_alarms,bp_nms_replicated_v1_alarms,bp_nsi_v1_alarms,bp_nsi_v1_changes_equipmentStaticSpec,bp_nsi_v1_changes_sync,bp_nsi_v1_internal_changes_inventory,bp_nsi_v1_internal_group,bp_nsi_v1_internal_stitch,bp_nsi_v1_internal_utilization,bp_nsi_v2_0_changes_nc,bp_nsi_v2_0_validation,bp_nsi_v3_changes_equipment,bp_nsi_v3_changes_fre,bp_nsi_v3_changes_tpe,bp_nsi_v3_validation,bp_nsi_v5_changes_geo_in,bp_perfg_v1_scheduler_ppg,bp_perfg_v2_monitor_servicetrail,bp_perfg_v2_monitor_viability,bp_pinpoint_v1_otdr_state,bp_pm_v1_geo_sync,bp_pmp_v1_pm,bp_pmprocessor_v1_datastore,bp_projectmanagement_v2_cancelled,bp_projectmanagement_v2_commit,bp_projectmanagement_v2_deleted,bp_projectmanagement_v2_list_deleted,bp_projectmanagement_v2_list_projectadded,bp_projectmanagement_v2_list_statechange,bp_projectmanagement_v2_networkchanged,bp_projectmanagement_v2_projectvalidate,bp_projectmanagement_v2_statechange,bp_ra_v1_EroEvent,bp_ra_v1_SelectiveSync,bp_ra_v1_alarms,bp_ra_v1_diagnostics_loopback,bp_ra_v1_nodecommissioning,bp_ra_v1_pm,bp_ra_v1_pm_thresholds,bp_ra_v1_poke,bp_ra_v2_0_sync,bp_rasdk_v1_changes,bp_stitcher_v1_changes_iplinkfre,bp_stitcher_v2_changes_tpe,bp_stitcher_v2_patch_fre,bp_stitcher_v3_changes_fre,bp_tdc_v1_tests,bp_topologyplanning_v1_planneddata_fiberloss_changed,bp_topologyplanning_v1_planneddata_omssnr_changed,bp_tron_v1_changes,bp_tron_v1_kompressor,bp_view_alarmcorrelation_publish,chronos_dispatch_queue,chronos_scheduling_queue,chronos_sharding_queues_0,chronos_sharding_queues_1,com_cyaninc_bp_market,cr,freg2svchist,pm_scheduling}.committed" took 0.00185609s

as you can see remote graphite-web just closing connection and not responding with anything - but doing that after 0.001 s - so, it's not a timeout. Can be firewall or something like this, but looks like something beyond Graphite itself.

It is showing this issue for some of the dashboards. For the dashboard with less no. of endpoints, it is working fine and shows combined data on the dashboard.

So Tried multiple scenarios and found that after a number of data points the graphite web starts giving issues.


feat: Store metadata in db

Describe the changes you have made in this PR
feat: store metadata in DB
covered cases -

non-empty invoice valid  metadata
non-empty invoice invalid metadata
non-empty invoice no metadata
empty invoice valid metadata
empty invoice invalid metadata
empty invoice no metadata
validate metadata before making payment
allow payments to happen only when metadata is valid
no metadata passed is equivalent to valid metadata

Type of change (Remove other not matching type)

feat: New feature (non-breaking change which adds functionality)

Screenshots of the changes (If any)
Add screenshots to help explain your problem
How has this been tested?
using prototype and lightning regtest network

Existing functionality working fine

if metadata passed and if it's valid and stored in DB

if  no valid metadata is provided don't allow to proceed with payment

when no metadata is passed, the code works as before

when no metadata is passed but the invoice is valid, the code work as before and allows the user to make payment

Checklist

[X] My code follows the style guidelines of this project and performed a self-review of my own code
[X] New and existing tests pass locally with my changes
[X] I checked if I need to make corresponding changes to the documentation (and made those changes if needed)

@bumi

@bumi

@bumi can you merge this! so that I can build next improvement on top of this


Ollama reverts to CPU on a100 docker. "error looking up CUDA GPU memory: device memory info lookup failure 0: 4

What is the issue?
time=2024-04-15T09:17:48.609Z level=INFO source=gpu.go:82 msg="Nvidia GPU detected"
time=2024-04-15T09:17:48.609Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-04-15T09:17:48.617Z level=INFO source=gpu.go:109 msg="error looking up CUDA GPU memory: device memory info lookup failure 0: 4"
time=2024-04-15T09:17:48.617Z level=INFO source=routes.go:1133 msg="no GPU detected"
time=2024-04-15T09:17:49.031Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-04-15T09:17:49.031Z level=INFO source=gpu.go:109 msg="error looking up CUDA GPU memory: device memory info lookup failure 0: 4"
time=2024-04-15T09:17:49.031Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-04-15T09:17:49.031Z level=INFO source=gpu.go:109 msg="error looking up CUDA GPU memory: device memory info lookup failure 0: 4"
time=2024-04-15T09:17:49.031Z level=INFO source=llm.go:85 msg="GPU not available, falling back to CPU"
time=2024-04-15T09:17:49.034Z level=INFO source=dyn_ext_server.go:90 msg="Loading Dynamic llm server: /tmp/ollama3883625654/runners/cpu_avx2/libext_server.so"
time=2024-04-15T09:17:49.034Z level=INFO source=dyn_ext_server.go:150 msg="Initializing llama server"
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15              Driver Version: 550.54.15      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A100-PCIE-40GB          Off |   00000000:01:00.0 Off |                   On |
| N/A   38C    P0             32W /  250W |      90MiB /  40960MiB |     N/A      Default |
|                                         |                        |              Enabled |
+-----------------------------------------+------------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB          Off |   00000000:43:00.0 Off |                   On |
| N/A   32C    P0             35W /  250W |   17843MiB /  40960MiB |     N/A      Default |
|                                         |                        |              Enabled |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| MIG devices:                                                                            |
+------------------+----------------------------------+-----------+-----------------------+
| GPU  GI  CI  MIG |                     Memory-Usage |        Vol|      Shared           |
|      ID  ID  Dev |                       BAR1-Usage | SM     Unc| CE ENC DEC OFA JPG    |
|                  |                                  |        ECC|                       |
|==================+==================================+===========+=======================|
|  0    1   0   0  |              53MiB / 19968MiB    | 56      0 |  4   0    2    0    0 |
|                  |                 1MiB / 32767MiB  |           |                       |
+------------------+----------------------------------+-----------+-----------------------+
|  0    5   0   1  |              25MiB /  9856MiB    | 28      0 |  2   0    1    0    0 |
|                  |                 0MiB / 16383MiB  |           |                       |
+------------------+----------------------------------+-----------+-----------------------+
|  0   13   0   2  |              12MiB /  4864MiB    | 14      0 |  1   0    0    0    0 |
|                  |                 0MiB /  8191MiB  |           |                       |
+------------------+----------------------------------+-----------+-----------------------+
|  1    0   0   0  |           17843MiB / 40326MiB    | 98      0 |  7   0    5    1    1 |
|                  |                 7MiB / 65536MiB  |           |                       |
+------------------+----------------------------------+-----------+-----------------------+
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    1    0    0       4197      C   /opt/conda/bin/python                        5180MiB |
|    1    0    0       4201      C   /opt/conda/bin/python                       12644MiB |
+-----------------------------------------------------------------------------------------+
$
What did you expect to see?
No response
Steps to reproduce
No response
Are there any recent changes that introduced the issue?
No response
OS
Linux
Architecture
No response
Platform
No response
Ollama version
latest
GPU
Nvidia
GPU info
a100
CPU
No response
Other software
No response

If adjusting permissions doesn't resolve the problem, please let us know and I'll reopen the issue.

Hi, I am currently experiencing this issue on a prod openshift (k8s) environment, deployed via official dockerhub image.
We know that permissions to access gpu's ok by checking nvidia-smi command with same user.
Our Ollama version is 0.3.1.
Is there any output you want me to share, please let me know. Any help is appreciated. Cheers

@UmutAlihan your scenario looks different than this issue.  Please open a new issue and include a more complete server log.  The partial logs you included don't really make sense (if we didn't discover the GPU we shouldn't have loaded 33/33 layers on the GPU, so there's more going on here in other log lines that are important to understand.)


Invalid cubic bezier formula

Something I have noticed is that the formula you use for determining the Bezier easing percentage isn't valid.
The formula finds either the horizontal or vertical coordinate of a point on the Cubic Bezier curve. Although it is correct, you are mixing the coordinates, using both coordinates of the control points, instead of only one. This error results in an incorrect completion percentage of the animation.
I would suggest using a separate implementation of the Cubic Bezier easing curves if you wish to keep this feature or use only the timing functions for easing.

+++

will check on this, thanks!


Add automated tests

It would be very nice if we could run tests that enter a shell and compile an example program for each target using a single command.

https://github.com/mirrexagon/nixpkgs-esp-dev/tree/19-add-tests


Feature: support notify

#129

Codecov Report

Merging #130 (ca0f915) into main (c149c7a) will decrease coverage by 0.31%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #130      +/-   ##
==========================================
- Coverage   85.91%   85.59%   -0.32%
==========================================
  Files          51       52       +1
  Lines        5098     5117      +19
==========================================
  Hits         4380     4380
- Misses        718      737      +19

Impacted Files
Coverage Δ

src/dft_basic/src/canister_api/transfer_notify.rs
0.00% <0.00%> (ø)

src/dft_basic/src/lib.rs
100.00% <ø> (ø)

src/dft_token/src/basic.rs
0.00% <0.00%> (ø)

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 c149c7a...ca0f915. Read the comment docs.

waiting https://github.com/dfinity/cdk-rs/issues/265


Not able to detect audio Intent

Whenever I try to send audio to detect Intent by editing the detect.js code with nessecary values:
{ sample Rate = 16000, encoding: 'AUDIO_ENCODING_LINEAR16', file is PCM file. I always get INVALID_ARGUMENT: While calling Cloud Speech API: Invalid recognition 'config': bad encoding.. Can you please help on this. I tried with stackflow, no fruitful solutions. Please help me immediately on this. Thanks!

Same thing here. Seem like a the wrong write function is called..

The encoding name is AUDIO_ENCODING_LINEAR_16, not AUDIO_ENCODING_LINEAR16 (note the underscore between LINEAR and 16).

@lukaszbk  Thanks for the solution. It worked! Also, please change that in your code too. Might be helpful for others too....
@tefrati It works dude.... Follow the above mentioned solution.


Optimization Build Version

I'm using Nuxtjs and Exprressjs.
I'm looking for an optimization guideline that includes:

merge all js files (pages js files)
leverage browser caching
cash static contents
uglify CSS and JS file

There is a bunch of unreliable docs out there but I'm looking for the official package, Can you help me?

Merge all JS Files
With HTTP2, code-splitting and preload/prefetch, this shouldn't be done anymore. It's better to let the user load the most important content (the app-shell and the current page) first and let him load the other pages with subsequent requests afterwards (if preload/-fetch is enabled).
Browser Caching
This can be achieved either with Express.js (if you use nuxt only as "renderer") or in the nuxt config itself by changing the static value.
Example (nuxt.config.js):
render: {
  static: {
    setHeaders(res, path): {
      if (path.match(/.js$/)) {
        res.setHeader('Cache-Control', 'no-cache')
      }
    }
  }
}

Alternatively, you could go for the PWA approach and use service-workers for caching. You could use the pwa-module for it.
Uglify CSS and JS
Should be done automatically, but you can push webpack plugins or rules into the config through the build.extend function in your nuxt.config.js.
Example (adding ESLint rules):
build: {
    extend (config, ctx) {
      if (ctx.isClient) {
        if (ctx.isDev) {
          config.module.rules.push({
            enforce: 'pre',
            test: /\.(js|vue)$/,
            loader: 'eslint-loader',
            exclude: /(node_modules)/
          })
        }
      }
    }
  }
}


Modify assemblies to be variants instead of product with few minor fixes

This PR allows to add parts on variant level instead of just product level.
Please refer - #132

@Mafi88 - Closed the previous PR https://github.com/spree-contrib/spree-product-assembly/pull/135 and created this one.
Specs in this one are failing due to an issue in spree_cmd. Raised a PR to fix it on spree - https://github.com/spree-contrib/spree-product-assembly/pull/135

@Mafi88 @vinniefranco - The specs have been fixed now with all the changes specified in https://github.com/spree-contrib/spree-product-assembly/pull/135.
Please let me know if this PR seems fine to you or there is still something remaining that needs to be fixed. :)

@nishant-cyro :+1:

@nishant-cyro will be QA-ing this today

Thanks @damianlegawiec, please let me know if there is anything I have missed or can be improved :)


Remove deprecated Components/types

remove anything related to DeprecatedLiteralMapViewer

Added as part of https://github.com/flyteorg/flyteconsole/issues/393


Working with large graph for node prediction!

I have a single big graph on which I want to perform node prediction.
MyData(edge_attr=[25298524], edge_index=[2, 25298524], num_classes=608, test_mask=[3982], train_mask=[960], val_mask=[240], x=[5182, 875], y=[5182, 608])
When I try to run the model which is given by:
class GCN(torch.nn.Module):
    def __init__(self, num_features, num_classes, hidden_channels):
        super(GCN, self).__init__()
        torch.manual_seed(12345)
        self.conv1 = GCNConv(num_features, hidden_channels)
        self.conv2 = GCNConv(hidden_channels, num_classes)

    def forward(self, data):
        node_feature = data.x
        edge_index = data.edge_index
        x = self.conv1(node_feature, edge_index)
        x = x.relu()
        x = F.dropout(x, p=0.5, training=self.training)
        x = self.conv2(x, edge_index)
        return x

The training procedure on gpu is simple as follows:
def train():
    model.train()
    optimizer.zero_grad() #clear gradients
    out = model(data)
    loss = loss_fn(out[data.train_mask], data.y[train_mask])
    loss.backward() # Derive Gradients
    optimizer.step() # update parameters based on gradients
    return loss

def validate():
    model.eval()
    out = model(data.x, data.edge_index)
    loss = loss_fn(out[data.val_mask], data.y[data.val_mask])
    return loss

data = build_data()
data = data.to(device)
model = GCN(num_features = data.num_node_features,
                num_classes = data.num_classes,
                hidden_channels = node_hidden_channels).to(device)

optimizer = torch.optim.Adam(model.parameters(), lr = 0.0001)
for epoch in range(epochs):
      train_loss = train()
      val_loss = validate()
      print(f'Epoch: {epoch}/{epochs}\t train_loss: {train_loss:.5f}, val_loss: {val_loss:.5f}')

The following error occurs:
RuntimeError                              Traceback (most recent call last)
<ipython-input-6-4cf5583aaacb> in <module>()
     97     optimizer = torch.optim.Adam(model.parameters(), lr = 0.0001)
     98     for epoch in range(epochs):
---> 99         train_loss = train()
    100         val_loss = validate()
    101         print(f'Epoch: {epoch}/{epochs}\t train_loss: {train_loss:.5f}, val_loss: {val_loss:.5f}')

6 frames
/usr/local/lib/python3.6/dist-packages/torch_geometric/nn/conv/gcn_conv.py in message(self, x_j, edge_weight)
    175
    176     def message(self, x_j: Tensor, edge_weight: Tensor) -> Tensor:
--> 177         return edge_weight.view(-1, 1) * x_j
    178
    179     def message_and_aggregate(self, adj_t: SparseTensor, x: Tensor) -> Tensor:

RuntimeError: CUDA out of memory. Tried to allocate 12.07 GiB (GPU 0; 14.73 GiB total capacity; 13.04 GiB already allocated; 669.88 MiB free; 13.07 GiB reserved in total by PyTorch)

which obvious as the graph is large.
Is there any way possible to train using bactches of nodes? Or any other method in which I can perform node preditiction on the single graph?

Since your graphs are rather dense with a rather low number of nodes, I suggest you look into the newly introduced SparseTensor format, see here.
If you want to make use of mini-batch training, we provide several options:

NeighborSampler
ClusterLoader
GraphSAINTSampler


Support decimals for sending BRC-20 based on ticker

Tickers can support up to 18 places so we should use the API to detect how many are permitted for a given ticker as chosen by the user for sending and apply its decimal configuration to the form:
https://docs.bestinslot.xyz/reference/api-reference/brc-20#get-brc-20-ticker-info
Right now it appears we simply limit the field to 8 characters (including the decimal point):

@fbwoolf can perhaps take this on Monday as well so @alter-eggo you can focus on the previously assigned work


feat(cheatcodes): allow forge script to access wallet addresses with vm.getScriptWallets()

Component
Forge
Describe the feature you would like
To have a feature where we can access in our foundry scripts the private keys input from --interactives mode or the resolved public addresses of those private keys. This way, we don't have to repeat the sender address in the --sender because we can decide which private keys to use as the sender and pass the intended address as the sender in vm.startBroadcast(sender).
For example:
uint256[] privateKeys = vm.interactives();
// Or, an optional index parameter to get from the list of input private keys
// uint256 privateKey = vm.interactives(0);   // gets the first private key entered from interactive mode

address sender = vm.addr(privateKeys[0]);

vm.startBroadcast(sender);
// ...
vm.stopBroadcast();

Additional context
Currently, when forge is run with --interactives, it doesn't seem like there is a way to access the private keys or the public addresses of those private keys provided through the interactive input in the foundry scripts. The only way (as far as I have tried) to run the foundry scripts with --interactives is:

Provide the address of the private key through --sender on top of --interactives
AND only use vm.startBroadcast(). I cannot use vm.startBroadcast(sender) since I cannot access the private key supplied through the interactive input and so I won't know the sender address.

Supplying the public address through --sender feels repeated because the address should already be resolvable from the private key.
Moreover, the --interactives parameter can accept more than one private keys which seems to suggest a script should be able to select one of the keys supplied to be the actual sender.
If there is a feature where we can access the input private keys or their translated public addresses in our foundry scripts, we wouldn't have to repeat the address in the --sender because our foundry script can decide which private key to use as sender and pass the correct address as the sender in vm.startBroadcast(sender).

Can vm.getScriptWallets() could return an array of Wallet structs in scripts and tests? This way you can write tests for your scripts and do something like forge test script/MyScript.s.sol --private-key $DUMMY_PRIVATE_KEY to test your scripts

We can't always get a private/public key for script wallets as such info is not available for hw wallets

This should be solvable with pattern similar to the one discussed in https://github.com/foundry-rs/foundry/pull/7012#issuecomment-1927218283
That way, the script will look like
contract Script {
    function run() public {
        address[] memory wallets = vm.getScriptWallets();
        // logic to determine which wallets to use for broadcasting
        run(wallet1, wallet2);
    }

    function run(address broadcaster1, address broadcaster2) public {
        // actual logic
    }
}

do something like forge test script/MyScript.s.sol --private-key $DUMMY_PRIVATE_KEY to test your

this is similar to dry-running a script I believe
Probably more often it's useful do determine broadcaster at runtime when testing script, by calling .owner() on some contract for example

going to close in favor of https://github.com/foundry-rs/foundry/issues/8225 and track impl there