Linsen test

@FreeTymeKiyan @lvyb @hustldw @kuangami

looks good

Looks pretty good. Is that possible to increase the efficiency?

nice!

A suggestion though, can we add the problem description in the committed file so we don't need to go back and look up the problem. Easier for reviewing.

Agree～
On Wednesday, March 2, 2016, Yanbin Lu<EMAIL_ADDRESS>wrote:

A suggestion though, can we add the problem description in the committed
file so we don't need to go back and look up the problem. Easier for
reviewing.
—
Reply to this email directly or view it on GitHub
https://github.com/FreeTymeKiyan/LeetCode-Sol-Res/pull/2#issuecomment-191597450
.

@forest5013 thanks for the example!
@lvyb great suggestion!
Please refer to my previous Java code for better format WordLadder2

The very basic way for Two Sum is to do two nested for-loops, one to iterate through the given array, one to search for the other number. The first loop is necessary, nothing can be improved on that. The only improvement possible is the second loop, to reduce the O(n) iteration to lower complexity, O(logn), or even O(1). That's where map comes in. Hope this can answer your question @hustldw .
So try to come with the intuitive, basic solution first, although it might not be perfect. Then find where it can be improved, including efficiency, logic, variable usage and even format. I believe this kind of thinking will help you guys greatly in an interview.

LGTM


Image snapshot testing with Puppeteer

Snapshot (approval) testing is useful for easy refactoring, and well supported by Jest. It's not quite trivial to set up for us because the map view renders asynchronously, and so waiting on "Nothing to show" doesn't seem to be enough for deterministic behaviour. The following diff illustrates different states that both satisfy expect(..).toContain("Nothing to show"):

Maybe we can find a UI element to wait on that only appears when the map is fully loaded.

[x] install jest-image-snapshot
[x] import toMatchImageSnapshot from jest-image-snapshot and extend Jest’s expect API
[ ] condition that over-approximates map being fully loaded
[ ] revisit snapshot tests in tgvejs (maybe no longer needed)

See:

Snapshot testing with Puppeteer
Puppeteer options for detecting navigation complete
Puppeteer wait until page is completely loaded
Puppeteer to listen for map.on('load') from within Node

Shall we try waitUntil: 'networkidle2'?

OK having played with many options on puppeteer, a solution which also contributes to overall tgvejs functionality is to generate the image snapshots without "basemap"s. This can be achieved by exporting another API called mapStyle and setting it to "No map". The results would be like. Please let me know @rolyp if you like me to send the commit (small one) to tgve/tgvejs.

Leave it here, got enough about puppeteer and how we are trying to use it. Great work btw.


How to deal with cookie bombing

@sirdarckcat pointed out the following attack:
An attacker that can execute scripts on an origin (XSS) could add large cookies meaning the ServiceWorker fails to update, as the response would be 500 or similar.
We should try and work around this by doing something like this as part of the update:

Let response be the result of fetching the SW with credentials
If fetch fails & cookies header length is greater than some extreme number of bytes,
Let response by the result of fetching the SW without credentials + Service-Worker: script no-credential-fallback header
(continue update)

+@slightlyoff

Made a small demo https://sirdarckcat.github.io/manifest/index.html

There should be a platform-wide solution to cookie bombing.
Even if we fix this for ServiceWorker fetches, it'll fail install if any request carries credentials. Also, the ServiceWorker has no access to document therefore no access to document.cookies.

If you can XSS you can also do a number of other attacks, such as poisoning storage or confused deputy attacks, no?

Yeah, but in those cases a new SW can come in and attempt cleanup. Cookie bombing prevents that happening.
I'm not sure we should do something specific in service worker for cookie bombing, but browsers should do something to combat it.
I suggested this to our security team:

If the browser makes a GET request that fails, and the cookies look "well dodgy", could try a request to the same url without credentials, and if it 200s (or 300s?) could we suggest to the user that their local state may be broken, & do they want to clear it?

This should be solved by http://w3c.github.io/webappsec-clear-site-data/ - servers should return this on too much cookies.


modifyVars appears to be changing in the less-loader

And seem to be throwing errors...
The proposed adjustments seem to be discussed here: https://github.com/webpack-contrib/less-loader/issues/303

Seeing the same thing - tried a number of things to get around it but no luck so far.

@gidich @Steven-Lilley-Imprivata  This addon does not rely on less loader. You can remove the use of modifyVars in the project build configuration. If you need to use it, please ensure that the use method is consistent with the less loader version. Please refer to https://ant.design/docs/react/customize-theme

And seem to be throwing errors... The proposed adjustments seem to be discussed here: webpack-contrib/less-loader#303

Errors in addon will not appear in canvas. In addition, storybook-addon-customise-antd-theme does not use less-loader. It seems that modifyVars is used in your stories file. Can you let me see where you use modifyVars? What is your storybook version？

No further feedback, I'll close first


Add ISSI IS6xWVS2M8ALL psram size

The size table for this SPIRAM (IS6xWVS2M8ALL) is wrong. This PR adds the manufacturer identification and, based on that, chooses the right table size. For IS6xWVS2M8ALL, the size table starts at 8 Mib (1MB).

@matheuswhite Thanks! I haven't checked whether esp-idf support this SPIRAM model. If not, would be good to submit the same patch in there.

@matheuswhite jut a heads up.. we will handle this after v4.0.0 is released.


[Request] Hold Shift to draw anchor perpendicularly

Holding shift key to draw new anchor point only in n*45 degrees ( also perpendicularly ) according to the last one, would be a big adventage. So as snaping not only to grid but also ie. to other anchor points.

Note, it can use angle snapping from snapping options, not 45°.

+1

As there was no answer to the above request, we're closing this issue as inactive.
If you can still reproduce it, please open a new issue against a currently supported release of Godot.


more control over std.ignore inputs in dl_read_gcp

Hello,
thank you for the recent changes to dl_read_gcp()! I tested the updates locally and found they worked nicely. There is one thing remaining that I think only impacts Windows users. This PR attempts to fix that and also should not impact the way dl_read_gcp() works for non-Windows users.
tldr: system() can throw an error in local R sessions for Windows users when both ignore.stderr and ignore.stdout are TRUE. I made modifications so that users can set one of those inputs to FALSE if they want to, and added documentation explaining the fix.

Great! Thank you 🎉 😄


NOW() isn't recognized as a Postgresql function

Dialect
PostgreSQL
Failing SQL
SELECT NOW();

Description
"Unknown function NOW()"

https://www.postgresql.org/docs/current/functions-datetime.html
now ( ) → timestamp with time zone
Current date and time (start of current transaction); see [Section 9.9.5](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT)
now() → 2019-12-23 14:39:53.662522-05


Update test_compile.cpp

Prevent the error:
"variable 'temp' is uninitialized when used here"
Since one of the generated kernels starts with:
__kernel void sample_test(__global float *src, __global int *dst) {
float temp;
int  tid = get_global_id(0);
dst[tid] = dst[tid] + temp;

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Waiting one more week for additional review.

Thank you, Lakshmi. @bashbaug, can you please merge this?

Merging as discussed in the October 10th teleconference.


Audio mounted slightly wrong causes volume to get increasingly louder

Reproduced it with this code, which forgot a yield:
import {Audio, makeScene2D} from '@revideo/2d';
import {waitFor} from '@revideo/core';

export default makeScene2D(function* (view) {
  for (let i = 0; i < 100; i++) {
    const x = <Audio src="/sounds/iphone.wav" play={true} />;
    view.add(x); // forgot the yield here
    yield* waitFor(1);
  }
});

This creates this warning actually:
Worker 0: JSHandle:warning from browser process:
Worker 0: JSHandle:Tried to access an asynchronous property before the node was ready. Make sure to yield the node before accessing the property.

This causes the audio to get increasingly louder

You might say user error, and feel free to just close this. Just thought it's worth documenting as I spent some time debugging this and might not be the only one to run into this issue.
Btw, the audio will play if you just construct an  object. You don't even need to add it to the view. You can skip that line altogether.

this is definitely interesting, thanks for the pointer. Audio nodes should indeed be yielded - any in which we await promises has to, e.g. also Txt nodes because we need to await fonts to load here. I'll take a look

This one was also fixed by my fix


Include Comments to the Download Package

Add comments from pages in to one document and upload to application package

Added comments to the download package.


dx serve should open simulator for mobile

Feature Request
Right now our CLI tooling has no special casing for mobile. In our future efforts to inline mobile support #2091 , we should implement the ability to pop open simulators when using the cli to build apps.
This + hotreloading will make mobile development extremely smooth and within reach for most rust newbies.

This is supported now, for iOS at least, and we're planning on being released for android in 0.6


[Feature] Support TRI-ML/prismatic-vlms

Checklist

[X] 1. If the issue you raised is not a feature but a question, please raise a discussion at https://github.com/sgl-project/sglang/discussions/new/choose Otherwise, it will be closed.
[X] 2. Please use English, otherwise it will be closed.

Motivation
I'm trying to speed up inference for new VLM models on huggingface: https://huggingface.co/TRI-ML/prismatic-vlms/tree/main. I'm wondering if there are additional documentation on how to adapt new models?
Related resources
The model I'm trying to adapt is detailed here: https://arxiv.org/pdf/2402.07865.

Contributions are welcome! Please refer to  https://github.com/sgl-project/sglang/blob/main/docs/en/model_support.md and the existing llava implementation


!voice random picker assigns members without Yes Theory role

The random assignment might assign someone who doesn't have the Yes Theory role so they cannot manipulate the room.
There are two ways of approaching this:

Narrowing down the list of members who may randomly be picked to only those with the role
Assigning the role to the randomly picked member

Each comes with its pros and cons; narrowing down the list might leave us with noone which would mean that room must be closed but would avoid more complex logic to cover that edge case; assigning the role poses the same questions as #200.

Why not use both ideas? If it comes to None then we could assign the role?

Check if the person picked for the random assignment has the role, if not, just give it to them, because they were already in a call hence yes theory role condition is satisfied.

however this may be exploited as a loophole and people would start joining 2 person calls and leave from one to get the role, so ethical hotfix can be checking if the random person has the yes theory role, if not, shuffle again.
the problem with the above fix would be is the call might have to get dropped if no one with the yes theory role is found.

Yeah, currently the room is just dropped. From what I know, this hasn't happened in the two years since I wrote the OP (at least nobody complained) so don't fix what nobody knows is broken 😄


Simplify assembly code bases

Pulled from #8349
Removal of upper bound will remove most of the maintenance burden.
Shrinking to a single line makes it must easier to identify which assemblies are missing in future.

Test results on this PR seem to be flaky. Not sure if its related to this PR though, will need to see how other future PRs go I think.


fix: increase parser lookahead

Fixes #1507. I'm really surprised we haven't hit this previously.

Moo.

Moar


How to get high res

I've succesfully created a 700px image using cpu and 8gb ram (uses about 6gb with l-bfgs).  Plus the fact that 2000px on cpu takes like 10+ hours to finish (not 100% sure cause I didn't wait till the end).
I tried splitting my style and content images and batch process the tiles but this doesn't work.
Is there anyway to get high res results without $6k in graphics cards? I'd really love to be able to print a 36" picture at 300dpi, so >10kpx

@alrpal, maybe this "neural-style" Wiki page could be helpful: https://github.com/jcjohnson/neural-style/wiki/Techniques-For-Increasing-Image-Quality-Without-Buying-a-Better-GPU


Consider utilising the standby replicas fully

Since the streaming interface was unified with http interface in front of the akka layer this opens a possibility to remove the notion of master-standby and treat all replicas as active writers and readers.

This would improve the performance and hardware utilisation characteristics as the standbys would become true replicas fully sharing the load
It would also somewhat simplify the architecture, although that is questionable since every partition, including the former master would have to continue consuming the state changelog
The biggest con is that instead of full consistency of master-standby model degrades into  eventual consistency
Maybe offering this trade-off via configuration per service type could be the way

Closing as won't do - keeping the exclusive Master, i.e. master handles all reads and writes leads to a simpler architecture with full consistency not being compromised


[core] GESTURE_DRAG and GESTURE_SWIPE_* issues (mostly) for web.

[x] I tested it on latest raylib version from master branch
[x] I checked there is no similar issue already reported
[x] I checked the documentation on the wiki
[x] My code has no errors or misuse of raylib

Part 1
Issue description
After becoming aware that Mouse Position was zero for mouse movement on Touch for web (https://github.com/raysan5/raylib/issues/3174), I suspected that it could be the cause of some problems on GESTURE_DRAG (and, to an extent, to GESTURE_SWIPE_*).
After a closer look, GESTURE_DRAG detection (rgestures.h#L350-L355) on ProcessGestureEvent() (rgestures.h#L265) calculates the distance between GESTURES.Touch.downPositionA and GESTURES.Touch.moveDownPositionA to compare it with the MINIMUM_DRAG distance.
However, GESTURES.Touch.moveDownPositionA is always zero. So when it calculates the distance, it's calculating the distance from the GESTURES.Touch.downPositionA (which is wherever the touch was pressed down) to the 0,0 (top left) point on the screen.
This wasn't easily noticeable because MINIMUM_DRAG value was really small (0.015f) (rgestures.h#L182). But once that was changed to a higher value, it becomes very apparent. A GESTURE_DRAG that started near 0,0 would start on the correct distance from MINIMUM_DRAG, but a GESTURE_DRAG that started on the other corner (bottom right) would trigger instantly.
Proposed solution
Since GESTURES.Touch.downPositionA is not available, it's not possible to reliably calculate the distance and an alternative check to detect GESTURE_DRAG is necessary. The best option I could find was using using time (subtracting the GESTURES.Touch.eventTime from rgGetCurrentTime() and comparing it to a new minimal DRAG_TIMEOUT define).
Part 2
Issue description
Albeit that solved the GESTURE_DRAG, it broke GESTURE_SWIPE_* for web.
Following the execution sequence of ProcessGestureEvent() I found that GESTURE_SWIPE_* usually happen after a GESTURE_DRAG. However, it can also happen after a GESTURE_HOLD. That's a rare occurance on PLATFORM_DESKTOP, but far more frequent on PLATFORM_WEB due to Emscripten's callbacks running independently.
Proposed solution
To fix that, it's necessary to add GESTURE_HOLD to also update the GESTURES.Touch.upPosition at rgestures.h#L300.
Part 3
Issue description
Finally, the last issue was that on Chrome for Android the sensitivity of a touch is very high internally on the web browser. High enough that a single physical touch could actually trigger multiple singular touches due to the curvature of the fingertip. Which, on its turn, would end up triggering multiple touch gestures that the user didn't actually intend to.
ProcessGestureEvent() was robust enough handle that, except for GESTURE_SWIPE_* because FORCE_TO_SWIPE value was way too small 0.0005f (rgestures.h#L181), so any tap would end up triggering a GESTURE_SWIPE_*.
Proposed solution
Increasing FORCE_TO_SWIPE to a higher value gave GESTURE_SWIPE_* a higher tolerance without losing functionality.
Tested these solutions successfully on Firefox (115.0.1) and Chrome (95.0.4638.74) for Android; Firefox (102.11.0esr 64-bit) and Chrome (114.0.5735.106 64-bit) with Touch Emulation enabled and disabled for Linux; and native on Linux.
I'll send a PR with the proposed changes (for the 3 parts, since they are somewhat interconnected) shortly.
I believe these were the last fixes necessary to fully reestablished functionality of touch for web.
Environment
Platform: Desktop
Operating System: Linux Mint 21.1 (x86_64)
OpenGL version: 3.1 Mesa 22.0.5
GPU: Intel HD Graphics 3000
Platform: Mobile
Operating System: Android 5.1.1
OpenGL version: OpenGL ES 1.1/2.0
GPU: Mali-400
Issue Screenshot

Code Example
Minimal reproduction code to test the issue: examples/core/core_input_gestures_web.c

@ubkp Thank you very much again for the improvement and the super-detailed and professional issue description.
As commented in the PR, trying the example on Windows (with mouse), I notice that HOLD is always issued after just a TAP, shouldn't it take some time to be detected?

@ubkp thanks for the detailed explanation. About the proposed changes on the drag/hold mechanism, it sounds good to me.

Can I make the "time" method (L355) the standard way to detect the "drag" gesture?

@ubkp Yes, I think it's the best option.


update the links in the readme modules

https://github.com/zsh-users/prezto/blob/master/modules/README.md is outdated.

As I said in #33 this issue is about bringing https://github.com/zsh-users/prezto/blob/master/modules/README.md up to date with a current list of modules.
In the medium term this content is better presented on a website as @facastagnini suggested in #3. It'll be more browsable, searchable, and accessible that way.
In the short term perhaps we can write a script to update this page from the individual module readmes.


Added AXES_ONLY_USER_FAILURES to support only looking at the user ID …

…and not the IP address.  I needed to add this for offices that use the same IP.  One user was locking the whole office out of my application.  Tests updated as well.
I just branch off of latest so this should be able to be merged.
All the tests including my new added tests ran without issue.

Thank you


"helm template" doesn't set $.Release.Name?

When using helm template with various parameters including --name-template, apparently it's not setting $.Release.Name. I get this error:

Error: template: mychart/templates/istio/cert-manager-certificate.yaml:19:6: executing "mychart/templates/istio/cert-manager-certificate.yaml" at <include "ingress.hostname.allurls" .Values.istio.foo>: error calling include: template: mychart/templates/istio/_ingress.tpl:18:5: executing "ingress.hostname.allurls" at <include "ingress.hostname" .>: error calling include: template: mychart/templates/istio/_ingress.tpl:2:4: executing "ingress.hostname" at <$.Release.Name>: nil pointer evaluating interface {}.Name

Output of helm version:

version.BuildInfo{Version:"v3.9.3", GitCommit:"414ff28d4029ae8c8b05d62aa06c7fe3dee2bc58", GitTreeState:"clean", GoVersion:"go1.17.13"}

Output of kubectl version: N/A
Cloud Provider/Platform (AKS, GKE, Minikube etc.): N/A

I suspect that the behavior of $ might be different from what the documentation suggests...
https://helm.sh/docs/chart_template_guide/variables/ says this:

However, there is one variable that is always global - $ - this variable will always point to the root context. This can be very useful when you are looping in a range and you need to know the chart’s release name.

Also, https://helm.sh/docs/chart_template_guide/control_structures/#modifying-scope-using-with says this:

we can use $ for accessing the object Release.Name from the parent scope. $ is mapped to the root scope when template execution begins and it does not change during template execution.

I do not see any explanation of what the "root context" or the "root scope" is? Seems like that should be explained somewhere in the docs? Is it really true that "root context" or "root scope" or "top-level scope" is a global value that doesn't change? To me it is looking like $ is not a global value which never changes, but is instead local to a specific invocation of a named template (via include or template)...
Also, that's the only place I see the words "root" and "context" being used. Everywhere else in the doc it's referred to as "scope". Also, the docs use both "top-level scope" and "root scope". It would be nice to make the terminology consistent.

Aha... it looks like I am not the only one who has been confused about this: https://github.com/helm/helm/issues/7915
Also, it sounds like Helm is relying on gomplate's "Context" functionality? https://docs.gomplate.ca/syntax/#the-context So it seems like it would be better to call it "context" not "scope".
I guess the documentation does need to be updated. I will see if I can take some time to contribute improvements to it...

This is how go templates work. I agree with @rehevkor5 that this would be better handled through a documentation improvement. Please open an issue in helm-www.


Combining VarStores

I have a language model I pretrained on some data. I want to then use part of this model (the transformer) as part of another model. I'm having trouble figuring out the proper way to do this, as I end up having two varstores, one for loading the transformer model's weights, and one for the rest of the final model.
The problem with this is that now this can't be saved as one model, nor can it be optimized with a single optimizer. Is there a way to combine varstores together?

Maybe it could be possible to use a single varstore for your whole model? This would make it easier to save and run an optimizer on the whole thing. One tricky bit would be to load the pre-trained weights for the transformer part but for this you can probably use load_partial, this function does not fail if some variables in the varstore are not available in the weights file.

Yes I tried to use load_partial, but the issue is that the paths don't match up. Is it possible to get a varstore of only certian paths in the varstore? Because if I add a path to a varstore, I get an nn::Path, which does not have a copy function.
Is it possible to store the variables in each module, rather than have a single large varstore for the entire model? This seems to be how the pytorth python API does it, though I don't know how they do it in libtorch.

I am kind of getting around the solution by loading my pretrained model seperately and copying the appropriate tensors over to the main model by doing:
dest = source.detach().copy();

Does this mean that the dest will continue to be tracked? Is there a better way to copy a tensor over to a tensor being tracked?

I'm not sure to understand what you mean by "tracked" here. You can still backpropagate on dest after this block if that's what you're asking, the no_grad block only prevents gradients from being retained for the closure's duration.

Ok that's what I'm asking. It doesn't seem like the most optimal way, but currently just loading each model separately and copying the variables from the pretrained to the new one seems to work for me. It also seems the most intuitively straightforward.

@LaurentMazare , one side question. Does the below 2 equivalent:
let train_images = tch::no_grad(|| dataset.train_images.apply_t(&net, false));
let train_images = tch::no_grad(|| dataset.train_images.apply(&net));


[feature request] async es module loader

async module loader is useful for loading code from network, or requiring execute external process like esbuild/swc
since this fork is already support top level await, it can be (partially) implemented in pure js (aka add an fake source for async module which will await an unresolved promise) but I think it would be better if add an the module loader interface which can do this without the workaround

It's easier to discuss details if you can give a quick sketch of what you think the C API should look like and how it would be used.

IIRC the main problem is the module loader must populate a JSModuleDef as it's called, you can't perform an async operation and call some API to complete it later.

quick sketch

ref
https://html.spec.whatwg.org/#hostloadimportedmodule
https://tc39.es/ecma262/#sec-HostLoadImportedModule
https://tc39.es/proposal-import-attributes/#importattribute-record
HostLoadImportedModule(referrer, moduleRequest, loadState, payload)
typedef enum JSModuleLoadingResultEnum {
    JS_ASYNC_MODULE_SYNC,
    JS_ASYNC_MODULE_ASYNC,
    JS_ASYNC_MODULE_FAILED,
} JSModuleLoadingResultEnum;

// also reserve the import attribute struct for future extend
// to support something like `import { main } from './foo.wasm' with { type: "webassembly" }`
// or `import { xyz } 'xyz.ts' with { type: "typescript", compiler: "tsc" }`
typedef struct JSImportAttribute {
    char *key; /* 0 if end */
    JSValue value;
} JSImportAttribute;

typedef struct JSModuleRequest {
    char *specifier;
    JSImportAttribute *attributes;
} JSModuleRequest;

typedef JSModuleLoadingResultEnum JSModuleLoaderFunc2(
    JSContext *ctx,
    const char *module_name,
    /* only be used in sync mode */ JSModuleDef** out_sync_module_def,
    void *opaque);

// Changed the normalize function to allow serialize import attribute array into string
typedef char *JSModuleNormalizeFunc2(JSContext *ctx,
    const char *referrer,
    const JSModuleRequest* request,
    void *opaque);

void JS_SetModuleLoaderFunc2(JSRuntime *rt,
  JSModuleNormalizeFunc2 *module_normalize,
  JSModuleLoaderFunc2 *module_loader, void *opaque);

// used when JSModuleLoaderFunc2 returns JS_ASYNC_MODULE_ASYNC
void JS_FinishLoadingModule(JSRuntime *rt,
    const char *module_name,
    // null if failed
    JSModuleDef *module_def);

So the ask is to make the module loader interruptible? More specifically, that the JSModuleLoaderfunc callback can somehow signal that it will complete at a later time?
I'm not saying 'no' outright but I expect it will be a big effort, with lots of edge cases that need dealing with, like should JS_Eval(JS_EVAL_TYPE_MODULE) return some kind of sentinel when it can't continue?

Maybe an easier way forward is to have a special parse mode for modules that doesn't evaluate the module but returns its imports (and maybe exports?)
Then you fetch and parse its imports in the same way (and those imports' imports, etc.) until you're done and evaluate everything.

btw, I found current implementation is actually cannot handle top-level-await in module... so no js workaround at first place....

Maybe an easier way forward is to have a special parse mode for modules that doesn't evaluate the module but returns its imports (and maybe exports?)

it sounds good, and I think it should be able to handle dynamic import too

Maybe an easier way forward is to have a special parse mode for modules that doesn't evaluate the module but returns its imports (and maybe exports?)

ref: https://tc39.es/ecma262/#sec-source-text-module-records
actually I think it is how most of existing js engine works, two pass for esm, resolve module is first pass (InitializeEnvironment() ^1), eval is second part (ExecuteModule() ^2)

but I suggest to create a new api for module loading and eval. not just reuse JS_Eval, so we can avoid parse code twice...
maybe a dedicated JS_LoadModuleRecord which only return module records (contains import and export information, and set unresolved module as null, let caller to filling the gap), and JS_EvalModuleRecord to execute the resolved module (I known the old JS_Eval has module mode, but the api is only accept js source code)

Only dynamic imports where the path is a static string. That's so restricting it probably isn't worth bothering with though

but dynamic import is already return a promise, I mean it is possible to change the behavior for dynamic import...
static JSValue js_dynamic_import_job(JSContext *ctx,
                                     int argc, JSValueConst *argv)
{
    JSValueConst *resolving_funcs = argv;
    JSValueConst basename_val = argv[2];
    JSValueConst specifier = argv[3];
    JSModuleDef *m;
    const char *basename = NULL, *filename;
    JSValue ret, err, ns;

    if (!JS_IsString(basename_val)) {
        JS_ThrowTypeError(ctx, "no function filename for import()");
        goto exception;
    }
    basename = JS_ToCString(ctx, basename_val);
    if (!basename)
        goto exception;

    filename = JS_ToCString(ctx, specifier);
    if (!filename)
        goto exception;

    m = JS_RunModule(ctx, basename, filename); // change that to be allow async
    JS_FreeCString(ctx, filename);
    if (!m)
        goto exception;

    /* return the module namespace */
    ns = js_get_module_ns(ctx, m);
    if (JS_IsException(ns))
        goto exception;

    if (!JS_IsUndefined(m->promise)) {
        JSValueConst args[] = {argv[0], argv[1], ns};
        JSValueConst funcs[2];
        funcs[0] = JS_NewCFunctionData(ctx, js_dynamic_import_resolve, 0, 0, 3, args);
        funcs[1] = JS_NewCFunctionData(ctx, js_dynamic_import_reject, 0, 0, 3, args);
        JS_FreeValue(ctx, js_promise_then(ctx, m->promise, 2, funcs));

        JS_FreeValue(ctx, (JSValue)funcs[0]);
        JS_FreeValue(ctx, (JSValue)funcs[1]);
        JS_FreeValue(ctx, ns);
        JS_FreeCString(ctx, basename);

        return JS_UNDEFINED;
    }

    ret = JS_Call(ctx, resolving_funcs[0], JS_UNDEFINED,
                   1, (JSValueConst *)&ns);
    JS_FreeValue(ctx, ret); /* XXX: what to do if exception ? */
    JS_FreeValue(ctx, ns);
    JS_FreeCString(ctx, basename);
    return JS_UNDEFINED;
 exception:

    err = JS_GetException(ctx);
    ret = JS_Call(ctx, resolving_funcs[1], JS_UNDEFINED,
                   1, (JSValueConst *)&err);
    JS_FreeValue(ctx, ret); /* XXX: what to do if exception ? */
    JS_FreeValue(ctx, err);
    JS_FreeCString(ctx, basename);
    return JS_UNDEFINED;
}

I think you're confusing parsing and execution:

dynamic imports are done when bytecode is executed (and they have in fact their own opcode, OP_import)

my suggestion for non-dynamic imports is a static analysis pass; no bytecode executes

my suggestion for non-dynamic imports is a static analysis pass; no bytecode executes

ok, thats make sense (for static analysis pass), but my suggestion is also change the js_dynamic_import_job to allow async import too
aka allow customize how js_dynamic_import is execute, current implementation is just call JS_RunModule(ctx, basename, filename); in js_dynamic_import_job, which will only works with sync module loading mode

Okay, but that's something of an orthogonal issue. It'd be best to open a new issue so it can be tracked separately.


6355 don't lose authority portion of inputDirURI

Description
Fix for issue #6355.
Support for inputDirURI in job file that uses authority (HDFS namenode, for example).
Tried it out with my use case and it fixed the problem I encountered, as per #6355.
I had done a complete build (including top-level mvn eclipse:eclipse) prior to this patch, and wound up with two artifacts (.externalToolBuilders/ and maven-eclipse.xml) that were being treated as new files, so I excluded them via a change to .gitignore, don't know if that should have a separate PR.
Also the Pinot Batch Ingestion Standalone sub-project didn't have any unit tests previously, not sure if I configured things properly (I use JUnit 4 not testng), so looking for input, thanks!

Codecov Report

Merging #6359 (05704be) into master (1beaab5) will decrease coverage by 1.11%.
The diff coverage is 45.12%.

@@            Coverage Diff             @@
##           master    #6359      +/-   ##
==========================================
- Coverage   66.44%   65.33%   -1.12%
==========================================
  Files        1075     1291     +216
  Lines       54773    62158    +7385
  Branches     8168     9014     +846
==========================================
+ Hits        36396    40608    +4212
- Misses      15700    18650    +2950
- Partials     2677     2900     +223

Flag
Coverage Δ

unittests
65.33% <45.12%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...e/pinot/broker/api/resources/PinotBrokerDebug.java
0.00% <0.00%> (-79.32%)
:arrow_down:

...ot/broker/broker/AllowAllAccessControlFactory.java
71.42% <ø> (-28.58%)
:arrow_down:

.../helix/BrokerUserDefinedMessageHandlerFactory.java
33.96% <0.00%> (-32.71%)
:arrow_down:

...ker/routing/instanceselector/InstanceSelector.java
100.00% <ø> (ø)

...ava/org/apache/pinot/client/AbstractResultSet.java
66.66% <0.00%> (+9.52%)
:arrow_up:

.../main/java/org/apache/pinot/client/Connection.java
35.55% <0.00%> (-13.29%)
:arrow_down:

...inot/client/JsonAsyncHttpPinotClientTransport.java
10.90% <0.00%> (-51.10%)
:arrow_down:

...not/common/assignment/InstancePartitionsUtils.java
73.80% <ø> (+0.63%)
:arrow_up:

.../apache/pinot/common/exception/QueryException.java
90.27% <ø> (+5.55%)
:arrow_up:

...pinot/common/function/AggregationFunctionType.java
100.00% <ø> (ø)

... and 1141 more

Continue to review full report at Codecov.

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

Thanks!
Can you also add a test for SegmentGenerationUtils.getRelativeOutputPath(...) with the example you have. So we can ensure this works for your use case.

Hi @fx19880617 - OK, test added.

Hi @fx19880617 - I looked at the failing unit test report. It seems to be in a test that I didn't change (testNonMatchingRequestId(org.apache.pinot.core.transport.QueryRoutingTest) plus other tests in QueryRoutingTest. Do these sometimes randomly fail? Or should I dig deeper?

Hi @fx19880617 - I looked at the failing unit test report. It seems to be in a test that I didn't change (testNonMatchingRequestId(org.apache.pinot.core.transport.QueryRoutingTest) plus other tests in QueryRoutingTest. Do these sometimes randomly fail? Or should I dig deeper?

I don't think it's relevant. Let me dig more.

Thanks for fixing this!


environment values file matching does not exist

helmfile version v0.144.0
When i refer values file release.yaml from environments.yaml file i get error that file could not be found: err: failed to read helmfile\bases\environments.yaml: environment values file matching "../../environments/ocp3/dev/release.yaml" does not exist in "."
No matter where i place the file, even if that is next to environments.yaml i get the same error.
My goal is to read the versions of all charts from external file that can be modified later by PRs.

Any idea what do i do wrong that i get the error or any suggestion on how to achieve the goal?
Could the release.yaml be iterated by range in combination with template to populate labels and potential values enabling additional subcharts to be installed?

i have following structure:
C:.
│   helmfile.yaml
│
└───helmfile
    ├───bases
    │       environments.yaml
    │       helmDefaults.yaml
    │
    ├───environments
    │   └───ocp3
    │       └───dev
    │               release.yaml
    │
    └───releases
        └───services
                helmfile.yaml
                issues.values.yaml.gotmpl
                jira-metrics.values.yaml.gotmpl

root helmfile.yaml:
bases:
  - "helmfile/bases/helmDefaults.yaml"
  - "helmfile/bases/environments.yaml"

helmfiles:
  - "helmfile/releases/services/helmfile.yaml"

missingFileHandler: Error

helmfile in services dir:
---
bases:
  - "../../bases/helmDefaults.yaml"
  - "../../bases/environments.yaml"

---
repositories:
  - name: foo
    url: {{ .Values | getOrNil "bitnami_helm_repo_url" }}

templates:
  common: &common
    namespace: {{ required "Namespace is required" .Values | getOrNil "namespace" }}
    chart: foo/{{`{{ .Release.Name }}`}}
    values:
      - "{{`{{ .Release.Name }}`}}.values.yaml.gotmpl"

releases:
  - name: jira-metrics
    <<: *common
    version: {{ .Environment.Values | get "jira-metrics.version" }}
    labels:
      tier: app
      domain: services

  - name: issues
    <<: *common
    version: {{ .Environment.Values | get "issues.version" }}
    labels:
      tier: app
      domain: services
    values:
      - something.enabled: true

environments.yaml:
---
# !!IMPORTANT!!
# All false boolean values should be quoted due to https://github.com/helm/helm/issues/3308
# Because of YAML merging, all true boolean values should be quoted as well
environments:

  default:
    values:
      - strimzi:
          installed: "false"
        microcks:
          installed: "false"
        bitnami_helm_repo_url: https://charts.bitnami.com/bitnami

  # This is a dummy environment used for base values that can
  # be merged into other environments.
  __base:
    values:
      # These services are only installed in the
      # regional cluster, so we disable them for
      # all zonal clusters, regardless of the environment.
      - &artifactory_helm_repos
        bitnami_helm_repo_url: https://artifactory.net/artifactory/foo-helm-release-virtual
      - &aks_helm_repos
        bitnami_helm_repo_url: https://artifactory.net/artifactory/foo-helm-release-virtual

  #### Begin environments #####
  ocp4:
    values:
      - <<: *artifactory_helm_repos
      - microcks:
          installed: "true"
  ocp3-dev:
    values:
      - ../../environments/ocp3/dev/release.yaml
      - namespace: foo-dev
      - <<: *artifactory_helm_repos
      - microcks:
          installed: "false"
  ocp3-int:
    values:
      - namespace: foo-int
      - <<: *artifactory_helm_repos
      - microcks:
          installed: "false"

content of release.yaml:
jira-metrics:
  version: 0.1.0

issues:
  version: 0.1.0

@tomassatka Hey. Are you're on Windows? We don't have CI for Windows so not sure how it behaves there.
At glance, the problem seems like coming from the fact that you're using / as the path separator whereas in Windows you should use \

Hi @mumoshu
I found the rootcause of the issue. It is not related to OS.
Providing git repo to showcase the issue: https://github.com/tomassatka/helmfile-2135
In repo is non-working and working dir where i applied ugly fix.
Would like to describe the nature of the problem.
In the project i defined root helmfile that uses bases pointing to environments.yaml and pointing to nested helmfile:
bases:
  - "helmfile/bases/helmDefaults.yaml"
  - "helmfile/bases/environments.yaml"

helmfiles:
  - "helmfile/releases/services/helmfile.yaml"

missingFileHandler: Error

now the nested helmfile.yaml also uses bases:
---
bases:
  - "../../bases/helmDefaults.yaml"
  - "../../bases/environments.yaml"

Thats intentional that the environment is defined only in 1 file and all files refer to it. The problem is then when helmfile goes over rendering different helmfiles.. the path is relative to helmfile not to environments therefore the path for release.yaml is relative to 2 different helmfile in 2 different directories hence for one of them it wont be able to find the release and prints the error.
Now the ugly solution is to write environemnts section into each helmfile but that causes a duplication and potential issues.
Do you have any other suggestion? :)
thx

@tomassatka Hey. Ah, that makes sense. Each helmfile and sub-helmfile evaluates relative paths based on the paths of helmfile.yaml files, whereas paths in a base file is evaluated based on the path of the helmfile loading it. I thought I made that design choice to make base.yaml useful for sharing the structure of the helmfile.yaml.
In your case, why do you need to define the whole environments in the top-level helmfile.yaml? To me, the only thing you need in the top-level helmfile.yaml is a list of environments names without their values, and the helmfiles section to call individual sub-helmfiles with their own environments sections.
Can't you make the root helmfile.yaml look like the below? So that the only thing you need to repeat is the names of environments. Every service helmfile.yaml can share the same base file that is specifically tailored for service helmfiles.
environments:
  default:
  dev:
  int:

helmfiles:
  - "helmfile/releases/services/helmfile.yaml"

hi @mumoshu
Thanks for proposal. Yes that is an acceptable solution. I was not aware that the path is always relative to helmfile that is being executed. This gives me a thought if in future will be useful to have variable like maven has ${basedir}.

hi @mumoshu
Thanks for proposal. Yes that is an acceptable solution. I was not aware that the path is always relative to helmfile that is being executed. This gives me a thought if in future will be useful to have variable like maven has ${basedir}.


Changed Dropdown Button Color to White

Old dropdown buttons were light blue, which blended too well with the header color. Changing them to white makes them more visible.

Not sure yet if I like it. When you click on filtering, it gets a grey border which sticks around even after closing / unfocusing:

We have the same effect already:

Happens in Chrome but not in Firefox. It just more visible in the white version. Apart from that I personally like the white version. Looks much fresher.


fix: bump ms-rest-js for axios version bump

Fixes #3181

Pull Request Test Coverage Report for Build 480860031

0 of 0   changed or added relevant lines in 0 files are covered.
9 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.05%) to 84.344%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

libraries/adaptive-expressions/src/triggerTrees/node.ts
8
91.7%

Totals

Change from base Build 479513690:
-0.05%

Covered Lines:
17738

Relevant Lines:
20090

💛  - Coveralls

Pull Request Test Coverage Report for Build 480860031

0 of 0   changed or added relevant lines in 0 files are covered.
9 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.05%) to 84.344%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

libraries/adaptive-expressions/src/triggerTrees/node.ts
8
91.7%

Totals

Change from base Build 479513690:
-0.05%

Covered Lines:
17738

Relevant Lines:
20090

💛  - Coveralls


test: use malloc install of new in common/crypto/utility_test.cc

Signed-off-by: Xin Zhuang<EMAIL_ADDRESS>Description: use malloc+free in crypto/crypto_impl{.cc,_test.cc}
The new + free composition is could lead to undefined behavior.
Had the impulse to switch the free in verifySignature() to delete, or we probably should not "delete/free" a reference parameter at all, but better leave it to the openssl expert.
Risk Level: LOW (test only)
Testing: Unit test
Docs Changes: N/A
Release Notes: N/A
Fixes: #8286

/assign mattklein123


Straight-up fails to change region

Yeah. You heard. It straight up fails to change the region. This may, however, have to do with the fact I downloaded it from TitleDB. It does work in changing the game's language to one supported by the default region, but it cannot change it to out-of-region languages or actually change regions. So, yeah. Running Luma 8.1.1.

Can you comment on which game(s) it is having problems with?
Since the application is just a frontend to Luma's built-in region spoofing feature, it only changes what region and language the 3DS appears to the game. In other words, the game has to support it. It won't make, e.g., a USA region game become a EUR one, but instead it'll make the cart think it's running on a EUR system instead of a USA one. This has been useful for non-region locked games (such as Pokémon, in order to get region specific events) and is necessary for some games where Luma's region patching isn't enough (Bravely Default JPN version for instance).

Oh. I see. I was testing it on MK7. You see, I region-changed my EmuNand to Europe so I could run my 3DS in German, and wanted to run MK7 in German too. My Gamecart-dumped copy was USA, so I ended up downloading a European version from FreeShop (it's not piracy if you own the game). I figured it would actually change the region of the game, and actually change it to out-of-region languages. I suppose I'll have to stick with German or English. I wanted to run it in Japanese. What would be cool is if you got a copy of each region of the game, and merged the language files so you can change it to any language. Well, I see now. Thanks.


Astro LSP completions sometimes write over incorrect ranges

FAQ

[X] I have checked the FAQ and it didn't resolve my problem.

Announcement

[X] I have checked Breaking change announcement.

Minimal reproducible full config
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  -- bootstrap lazy.nvim
  -- stylua: ignore
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", "--branch=stable", lazypath })
end
vim.opt.rtp:prepend(vim.env.LAZY or lazypath)

require("lazy").setup({
	spec = {
		{
			"williamboman/mason.nvim",
			cmd = "Mason",
			keys = { { "<leader>cm", "<cmd>Mason<cr>", desc = "Mason" } },
			build = ":MasonUpdate",
			opts = {
				ensure_installed = {
					"astro-language-server",
				},
			},
			---@param opts MasonSettings | {ensure_installed: string[]}
			config = function(_, opts)
				require("mason").setup(opts)
				local mr = require("mason-registry")
				local function ensure_installed()
					for _, tool in ipairs(opts.ensure_installed) do
						local p = mr.get_package(tool)
						if not p:is_installed() then
							p:install()
						end
					end
				end
				if mr.refresh then
					mr.refresh(ensure_installed)
				else
					ensure_installed()
				end
			end,
		},
		"hrsh7th/cmp-nvim-lsp",
		{
			"hrsh7th/nvim-cmp",
			version = false, -- last release is way too old
			event = "InsertEnter",
			dependencies = {
				"hrsh7th/cmp-nvim-lsp",
			},
			opts = function()
				vim.api.nvim_set_hl(0, "CmpGhostText", { link = "Comment", default = true })
				local cmp = require("cmp")
				local defaults = require("cmp.config.default")()
				return {
					completion = {
						completeopt = "menu,menuone,noinsert",
					},
					mapping = cmp.mapping.preset.insert({
						["<C-n>"] = cmp.mapping.select_next_item({ behavior = cmp.SelectBehavior.Insert }),
						["<C-p>"] = cmp.mapping.select_prev_item({ behavior = cmp.SelectBehavior.Insert }),
						["<C-b>"] = cmp.mapping.scroll_docs(-4),
						["<C-f>"] = cmp.mapping.scroll_docs(4),
						["<C-l>"] = cmp.mapping.complete(),
						["<C-e>"] = cmp.mapping.abort(),
						["<CR>"] = cmp.mapping.confirm({ select = true }), -- Accept currently selected item. Set `select` to `false` to only confirm explicitly selected items.
						["<S-CR>"] = cmp.mapping.confirm({
							behavior = cmp.ConfirmBehavior.Replace,
							select = true,
						}), -- Accept currently selected item. Set `select` to `false` to only confirm explicitly selected items.
					}),
					sources = cmp.config.sources({
						{ name = "nvim_lsp" },
					}),
					experimental = {
						ghost_text = {
							hl_group = "CmpGhostText",
						},
					},
					sorting = defaults.sorting,
				}
			end,
		},
		"williamboman/mason-lspconfig.nvim",
		{
			"neovim/nvim-lspconfig",
			event = { "BufReadPre", "BufNewFile" },
			dependencies = {
				"mason.nvim",
				"williamboman/mason-lspconfig.nvim",
				"hrsh7th/cmp-nvim-lsp",
			},
			---@class PluginLspOpts
			opts = {
				-- LSP Server Settings
				---@type lspconfig.options
				servers = {
					astro = {},
				},
				setup = {},
			},
			---@param opts PluginLspOpts
			config = function(_, opts)
				local servers = opts.servers
				local has_cmp, cmp_nvim_lsp = pcall(require, "cmp_nvim_lsp")
				local capabilities = vim.tbl_deep_extend(
					"force",
					{},
					vim.lsp.protocol.make_client_capabilities(),
					has_cmp and cmp_nvim_lsp.default_capabilities() or {}
				)

				local function setup(server)
					local server_opts = vim.tbl_deep_extend("force", {
						capabilities = vim.deepcopy(capabilities),
					}, servers[server] or {})

					if opts.setup[server] then
						if opts.setup[server](server, server_opts) then
							return
						end
					elseif opts.setup["*"] then
						if opts.setup["*"](server, server_opts) then
							return
						end
					end
					require("lspconfig")[server].setup(server_opts)
				end

				-- get all the servers that are available through mason-lspconfig
				local have_mason, mlsp = pcall(require, "mason-lspconfig")
				local all_mslp_servers = {}
				if have_mason then
					all_mslp_servers = vim.tbl_keys(require("mason-lspconfig.mappings.server").lspconfig_to_package)
				end

				local ensure_installed = {} ---@type string[]
				for server, server_opts in pairs(servers) do
					if server_opts then
						server_opts = server_opts == true and {} or server_opts
						-- run manual setup if mason=false or if this is a server that cannot be installed with mason-lspconfig
						if server_opts.mason == false or not vim.tbl_contains(all_mslp_servers, server) then
							setup(server)
						else
							ensure_installed[#ensure_installed + 1] = server
						end
					end
				end

				if have_mason then
					mlsp.setup({ ensure_installed = ensure_installed, handlers = { setup } })
				end
			end,
		},
	},
	defaults = {
		-- By default, only LazyVim plugins will be lazy-loaded. Your custom plugins will load during startup.
		-- If you know what you're doing, you can set this to `true` to have all your custom plugins lazy-loaded by default.
		lazy = false,
		-- It's recommended to leave version=false for now, since a lot the plugin that support versioning,
		-- have outdated releases, which may break your Neovim install.
		version = false, -- always use the latest git commit
		-- version = "*", -- try installing the latest stable version for plugins that support semver
	},
	performance = {
		rtp = {
			-- disable some rtp plugins
			disabled_plugins = {
				"gzip",
				-- "matchit",
				-- "matchparen",
				-- "netrwPlugin",
				"tarPlugin",
				"tohtml",
				"tutor",
				"zipPlugin",
			},
		},
	},
})

Description
Under some circumstances, inserting completions from the Astro LSP inside interpolations in the HTML template result in what looks like the completions being written over incorrect ranges in the buffer.
Steps to reproduce
Initialize an Astro project with npm create astro@latest or equivalent. Then try to ciw the test inside the {test} interpolations in a file like the below, type t, and insert a completion for the test variable.
---
const test = "TEST";
---

{

}

Expected behavior
The completion gets inserted and the file is as given in the reproduction example.
Actual behavior
Individually, the cases will become as below. Note that doing the replacement and completions sequentially within the same file may not produce this due to the missing brackets changing the syntax.
---
const test = "TEST";
---

{<div id={ttest

Additional context
Another user in the discussion linked below found no issue when using Neovim omnifunc to insert completions in similar circumstances.
Astro framework: https://astro.build/
Some prior discussion of this issue can be found here: https://github.com/LazyVim/LazyVim/discussions/1455

Hi, @Trildar
I think this problem is a bug on the language server side. it does not cause problems with VSCode, but seems to cause problems with LSP clients of other editors. The start and end ranges for the selected completion items returned by the language server are probably incorrect. (completionItem/resolve)
You might want to report the issue to the language server side.

Hi, @Trildar
I think this problem is a bug on the language server side. it does not cause problems with VSCode, but seems to cause problems with LSP clients of other editors. The start and end ranges for the selected completion items returned by the language server are probably incorrect. (completionItem/resolve)
You might want to report the issue to the language server side.

Yeah, looking at the language server responses, there does seem to be an issue with the ranges returned for completionItem/resolve, so I filed an issue here: https://github.com/withastro/language-tools/issues/664
But seeing as how Neovim omnifunc apparently also works fine (mentioned in the discussion on LazyVim repo), I have to wonder if it's just a matter of that and VS Code not using ranges from completionItem/resolve or some bigger issue with how nvim-cmp interacts with the language server.

This issue already solved in latest @astrojs/language-server


SILGen: Emit the base of a read coroutine as a borrow in a yield/borrow/noncopyable context.

@swift-ci Please test


wildfly-swarm-bootstrap not in internal repo of swarm fat jar

Hi,
is there a reason why wildfly-swarm-bootstrap is not added to the m2repo folder in the swarm fat jar when building with the wildfly-swarm-plugin plugin?
The reason I am asking is that when I run a swarm jar in an environment that has no maven installed (e.g. a docker container) my jar fails to start. From debugging it seems the bootstrap process tries to resolve the wildfly-swarm-bootstrap from the maven repo in the swarm jar. It doesn't find it there, so it tries to resolve from the local maven repo, and as it is not found there, from public maven repos (maven central, jboss public repo), where it can't find it neither. The end result is that my jar fails to start.
When I manually add the wildfly-swarm-bootstrap jar in the m2repo folder of my fat jar, everything works fine.
Thx
Bernard

Forgot to add I am using 1.0.0.Alpha6-SNAPSHOT.

Hrm, that's intentional since the contents are exploded into the -swarm.jar
itself. Apparently I've done something wrong though. Can you attach or gist
the error you see?
--
Sent from my iPhone
On Nov 17, 2015, at 5:42 AM, Bernard Tison<EMAIL_ADDRESS>wrote:
Forgot to add I am using 1.0.0.Alpha6-SNAPSHOT.
—
Reply to this email directly or view it on GitHub
https://github.com/wildfly-swarm/wildfly-swarm/issues/162#issuecomment-157332883
.

The error says the moduleloader cannot find the modules:
Exception in thread "main" org.jboss.modules.ModuleNotFoundException: org.wildfly.swarm.logging:main
at org.jboss.modules.Module.addPaths(Module.java:1042)
at org.jboss.modules.Module.link(Module.java:1398)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1426)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238)
at org.wildfly.swarm.bootstrap.Main.getMainClass(Main.java:73)
at org.wildfly.swarm.bootstrap.Main.run(Main.java:50)
at org.wildfly.swarm.bootstrap.Main.main(Main.java:39)
However I think the real error is already happening before that, in org.wildfly.swarm.bootstrap.util.Layout.determineBootstrapClassLoader(). That method tries to load the org.wildfly.swarm.bootstrap module. It finds the module through the BootstrapModuleFinder, which then tries to build the module (org.wildfly.swarm.bootstrap.modules.AbstractSingleModuleFinder.buildModule(Builder, ModuleLoader). The implementation reads the META-INF/wildfly-swarm-bootstrap.conf file, and tries to load all artifacts in this file through maven.
The contents of my META-INF/wildfly-swarm-bootstrap.conf is:
org.wildfly.swarm:wildfly-swarm-security-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-webservices-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-undertow-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-container-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-logging-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-io-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-bootstrap:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-naming-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-ee-modules:1.0.0.Alpha6-SNAPSHOT
The  META-INF/wildfly-swarm-bootstrap.conf contains 'org.wildfly.swarm:wildfly-swarm-bootstrap:1.0.0.Alpha6-SNAPSHOT', so the implementation tries to load it through maven, and fails. The BootstrapModuleFinder throws a ModuleNotFoundException which is catched by Layout.determineBootstrapClassLoader(), which sets the bootstrap classloader to the classloader of the LayoutClass (an instance of sun.misc.Launcher$AppClassLoader) instead of an instance of ModuleClassLoader.
So it looks like META-INF/wildfly-swarm-bootstrap.conf should not contain org.wildfly.swarm:wildfly-swarm-bootstrap.
Bernard

Thank you for the fantastic report.  I’m investigating now.
On Tue, Nov 17, 2015 at 11:46 AM, Bernard Tison<EMAIL_ADDRESS>wrote:

The error says the moduleloader cannot find the modules:
Exception in thread "main" org.jboss.modules.ModuleNotFoundException:
org.wildfly.swarm.logging:main
at org.jboss.modules.Module.addPaths(Module.java:1042)
at org.jboss.modules.Module.link(Module.java:1398)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1426)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238)
at org.wildfly.swarm.bootstrap.Main.getMainClass(Main.java:73)
at org.wildfly.swarm.bootstrap.Main.run(Main.java:50)
at org.wildfly.swarm.bootstrap.Main.main(Main.java:39)
However I think the real error is already happening before that, in
org.wildfly.swarm.bootstrap.util.Layout.determineBootstrapClassLoader().
That method tries to load the org.wildfly.swarm.bootstrap module. It finds
the module through the BootstrapModuleFinder, which then tries to build the
module
(org.wildfly.swarm.bootstrap.modules.AbstractSingleModuleFinder.buildModule(Builder,
ModuleLoader). The implementation reads the
META-INF/wildfly-swarm-bootstrap.conf file, and tries to load all artifacts
in this file through maven.
The contents of my META-INF/wildfly-swarm-bootstrap.conf is:
org.wildfly.swarm:wildfly-swarm-security-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-webservices-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-undertow-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-container-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-logging-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-io-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-bootstrap:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-naming-modules:1.0.0.Alpha6-SNAPSHOT
org.wildfly.swarm:wildfly-swarm-ee-modules:1.0.0.Alpha6-SNAPSHOT
The META-INF/wildfly-swarm-bootstrap.conf contains
'org.wildfly.swarm:wildfly-swarm-bootstrap:1.0.0.Alpha6-SNAPSHOT', so the
implementation tries to load it through maven, and fails. The
BootstrapModuleFinder throws a ModuleNotFoundException which is catched by
Layout.determineBootstrapClassLoader(), which sets the bootstrap
classloader to the classloader of the LayoutClass (an instance of
sun.misc.Launcher$AppClassLoader) instead of an instance of
ModuleClassLoader.
So it looks like META-INF/wildfly-swarm-bootstrap.conf should not contain
org.wildfly.swarm:wildfly-swarm-bootstrap.
Bernard
—
Reply to this email directly or view it on GitHub
https://github.com/wildfly-swarm/wildfly-swarm/issues/162#issuecomment-157427523
.

I've tried this against an -example as usual and with -Dmaven.repo.local=./tmp to point to an empty maven repo, and both work, along with mvn wildfly-swarm:run.
Give it a whirl and let me know if this solves your problem
Once again, this bug report was terrific and helped very much in tracking this down.  Keep up the good work!

Yes, problem solved.
Thx
Bernard


build: change directory to the project directory when running the hooks

Signed-off-by: Filipe Laíns<EMAIL_ADDRESS>

@uranusjr does this fix #68 for you?

Uh, @gaborbernat can you look at this?

Looks ok, but fix the CI.

Do you know what is wrong? I don't use macos.

Nevermind, looks like /private/var is a symlink to /var.


Clean up old celery producer connections

Without this, each taskqueue server just increases the number of open rabbitmq connections each time it handles reloadworker calls.

https://ocd.appscale.com:8080/job/Daily Build/3486/


⚠ Processors has degraded performance

In e1e5277, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 68 ms

Resolved: Processors performance has improved in fdbb7b8.


lightning-cli plugin stop /path/to/watchtower.py kills lightningd

It seems when plugin stop is called on the watchtower right after Sending appointment, before Appointment accepted and signed, it crashes lightningd
022-02-09T19:15:37.554Z INFO    plugin-watchtower.py: Remaining slots: 159981005
2022-02-09T19:15:37.554Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:37.607Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=$id)
2022-02-09T19:15:37.616Z INFO    plugin-watchtower.py: Sending appointment 531c53e4279195a08711033ed88aef73 to $id
2022-02-09T19:15:37.998Z INFO    plugin-watchtower.py: Killing plugin: stopped by lightningd via RPC
2022-02-09T19:15:37.999Z **BROKEN** lightningd: Already in transaction from lightningd/jsonrpc.c:948
2022-02-09T19:15:38.049Z **BROKEN** lightningd: FATAL SIGNAL 6 (version v0.10.2)
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: common/daemon.c:38 (send_backtrace) 0x556f12436da1
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: common/daemon.c:46 (crashdump) 0x556f12436df0
--
2022-02-09T21:24:59.406Z INFO    plugin-watchtower.py: Appointment accepted and signed by $id
2022-02-09T21:24:59.407Z INFO    plugin-watchtower.py: Remaining slots: 159979073
2022-02-09T21:24:59.407Z INFO    plugin-watchtower.py: Start block: 722533
2022-02-09T21:24:59.438Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=$id)
2022-02-09T21:24:59.584Z INFO    plugin-watchtower.py: Killing plugin: stopped by lightningd via RPC
2022-02-09T21:25:05.432Z INFO    plugin-watchtower.py: A key file for the watchtower client already exists. Loading it
2022-02-09T21:25:05.433Z INFO    plugin-watchtower.py: Plugin watchtower client initialized. User id = $uid
2022-02-09T21:25:08.916Z INFO    plugin-watchtower.py: Sending appointment 07dffc4311d765151942e619bee13e80 to $id
2022-02-09T21:25:09.689Z INFO    plugin-watchtower.py: Appointment accepted and signed by $id
--
2022-02-09T21:25:12.496Z INFO    plugin-watchtower.py: Appointment accepted and signed by $id
2022-02-09T21:25:12.496Z INFO    plugin-watchtower.py: Remaining slots: 159979069
2022-02-09T21:25:12.496Z INFO    plugin-watchtower.py: Start block: 722533
2022-02-09T21:25:12.522Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=$id)
2022-02-09T21:25:58.038Z INFO    plugin-watchtower.py: Killing plugin: stopped by lightningd via RPC
2022-02-09T21:26:02.717Z INFO    plugin-watchtower.py: A key file for the watchtower client already exists. Loading it
2022-02-09T21:26:02.718Z INFO    plugin-watchtower.py: Plugin watchtower client initialized. User id = $uid
2022-02-09T21:26:07.638Z INFO    plugin-watchtower.py: Killing plugin: stopped by lightningd via RPC
2022-02-09T21:26:10.497Z INFO    plugin-watchtower.py: A key file for the watchtower client already exists. Loading it
2022-02-09T21:26:10.498Z INFO    plugin-watchtower.py: Plugin watchtower client initialized. User id = $uid
2022-02-09T21:26:12.463Z INFO    plugin-watchtower.py: Killing plugin: stopped by lightningd via RPC
2022-02-09T21:26:14.627Z INFO    plugin-watchtower.py: A key file for the watchtower client already exists. Loading it
2022-02-09T21:26:14.627Z INFO    plugin-watchtower.py: Plugin watchtower client initialized. User id = $uid

I'm kinda lost with this one. Looks like the plugin is indeed killing the daemon, but there is no backtrace from the plugin.
According to c-lightning docs on plugins, once stop is been called the plugin has up to 30 secs to exit or it'll be killed. But I'm unsure if the timeout is the reason of the issue or what.

022-02-09T19:15:37.554Z INFO    plugin-watchtower.py: Remaining slots: 159981005
2022-02-09T19:15:37.554Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:37.607Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=$id)
2022-02-09T19:15:37.616Z INFO    plugin-watchtower.py: Sending appointment 531c53e4279195a08711033ed88aef73 to $id
2022-02-09T19:15:37.998Z INFO    plugin-watchtower.py: Killing plugin: stopped by lightningd via RPC
2022-02-09T19:15:37.999Z BROKEN lightningd: Already in transaction from lightningd/jsonrpc.c:948
2022-02-09T19:15:38.049Z BROKEN lightningd: FATAL SIGNAL 6 (version v0.10.2)
2022-02-09T19:15:38.049Z BROKEN lightningd: backtrace: common/daemon.c:38 (send_backtrace) 0x556f12436da1
2022-02-09T19:15:38.049Z BROKEN lightningd: backtrace: common/daemon.c:46 (crashdump) 0x556f12436df0
--

Is this the end of the execution (i.e. the plugin kills the daemon right after it is called?

2022-02-09T21:24:59.406Z INFO    plugin-watchtower.py: Appointment accepted and signed by $id
2022-02-09T21:24:59.407Z INFO    plugin-watchtower.py: Remaining slots: 159979073
2022-02-09T21:24:59.407Z INFO    plugin-watchtower.py: Start block: 722533
2022-02-09T21:24:59.438Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=$id)
2022-02-09T21:24:59.584Z INFO    plugin-watchtower.py: Killing plugin: stopped by lightningd via RPC
2022-02-09T21:25:05.432Z INFO    plugin-watchtower.py: A key file for the watchtower client already exists. Loading it
2022-02-09T21:25:05.433Z INFO    plugin-watchtower.py: Plugin watchtower client initialized. User id = $uid
2022-02-09T21:25:08.916Z INFO    plugin-watchtower.py: Sending appointment 07dffc4311d765151942e619bee13e80 to $id
2022-02-09T21:25:09.689Z INFO    plugin-watchtower.py: Appointment accepted and signed by $id

Is this happening right after the daemon is restarted, are there any longs in the middle? Just trying to make sense of this.
I'll chat with the c-lightning folks anyway to see if there's something expected to be done when handling a stop signal. Anyway it does not feel right that a plugin can kill the daemon when the daemon is killing it.

the log is complete, so nothing cut out but only on level INFO. Here is the log from the starting of lightningd on, first line is interesting, so I guess I started watchtower later manually.
2022-02-09T18:52:13.031Z INFO    plugin-watchtower.py: Killing plugin: exited before replying to getmanifest
2022-02-09T18:52:13.063Z INFO    plugin-backup.py: root        : Comparing backup version 1692532 versus first write version 1692533
2022-02-09T18:52:13.063Z INFO    plugin-backup.py: Comparing backup version 1692532 versus first write version 1692533
2022-02-09T18:52:13.063Z INFO    plugin-backup.py: root        : Versions match up
2022-02-09T18:52:13.063Z INFO    plugin-backup.py: Versions match up
2022-02-09T18:52:22.759Z INFO    plugin-bcli: bitcoin-cli initialized and connected to bitcoind.
2022-02-09T18:52:27.353Z INFO    plugin-autoclean: autocleaning every 600 seconds
2022-02-09T18:52:27.354Z INFO    lightningd: Restarting onchaind for channel 21995
2022-02-09T18:52:27.356Z UNUSUAL xxx-chan#xxx: Peer permanent failure in ONCHAIN: Funding transaction spent
2022-02-09T18:52:27.356Z INFO    xxx-chan#xxx: State changed from ONCHAIN to FUNDING_SPEND_SEEN
2022-02-09T18:52:27.379Z INFO    lightningd: --------------------------------------------------
2022-02-09T18:52:27.379Z INFO    lightningd: Server started with public key xxx, alias xxx (color #xxx) and lightningd v0.10.2
2022-02-09T18:52:27.385Z INFO    xxx-chan#xxx: State changed from FUNDING_SPEND_SEEN to ONCHAIN
[some channeld and feeadjuster stuff...]
2022-02-09T19:14:37.724Z INFO    plugin-watchtower.py: A key file for the watchtower client already exists. Loading it
2022-02-09T19:14:37.725Z INFO    plugin-watchtower.py: Plugin watchtower client initialized. User id = UID
2022-02-09T19:14:37.901Z INFO    plugin-watchtower.py: Sending appointment e71eaa9ed8aafbffb460d9e17a4ae493 to ID
2022-02-09T19:14:38.308Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:38.308Z INFO    plugin-watchtower.py: Remaining slots: 159981026
2022-02-09T19:14:38.308Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:38.336Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:38.372Z INFO    plugin-watchtower.py: Sending appointment ca62a33c46ba57d25c5f8a18a080fd7f to ID
2022-02-09T19:14:38.763Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:38.763Z INFO    plugin-watchtower.py: Remaining slots: 159981025
2022-02-09T19:14:38.763Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:38.794Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:38.804Z INFO    plugin-watchtower.py: Sending appointment 9fe3a076ce28ddcad31b595f90d1cd21 to ID
2022-02-09T19:14:39.174Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:39.174Z INFO    plugin-watchtower.py: Remaining slots: 159981024
2022-02-09T19:14:39.174Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:39.199Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:45.144Z INFO    plugin-watchtower.py: Sending appointment ba890ec58de109b01c93fb3dc9fc8984 to ID
2022-02-09T19:14:45.623Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:45.623Z INFO    plugin-watchtower.py: Remaining slots: 159981023
2022-02-09T19:14:45.623Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:45.648Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:45.656Z INFO    plugin-watchtower.py: Sending appointment e33f44c156c1a02dfb851a37826e08c1 to ID
2022-02-09T19:14:46.210Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:46.211Z INFO    plugin-watchtower.py: Remaining slots: 159981022
2022-02-09T19:14:46.211Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:46.236Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:46.248Z INFO    plugin-watchtower.py: Sending appointment 525f50ec5ea519284c0a6b8ecf7b9376 to ID
2022-02-09T19:14:46.906Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:46.906Z INFO    plugin-watchtower.py: Remaining slots: 159981021
2022-02-09T19:14:46.906Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:46.930Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:46.944Z INFO    plugin-watchtower.py: Sending appointment e9a8e41446e8a630f26dae483190d9c0 to ID
2022-02-09T19:14:47.445Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:47.446Z INFO    plugin-watchtower.py: Remaining slots: 159981020
2022-02-09T19:14:47.446Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:47.471Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:47.501Z INFO    plugin-watchtower.py: Sending appointment 0fa44ef68702e489bec0a48ab8a5d09e to ID
2022-02-09T19:14:47.940Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:47.941Z INFO    plugin-watchtower.py: Remaining slots: 159981019
2022-02-09T19:14:47.941Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:47.968Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:47.980Z INFO    plugin-watchtower.py: Sending appointment f1e71bbb8f941e81422f68b78d21b8f2 to ID
2022-02-09T19:14:48.390Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:48.390Z INFO    plugin-watchtower.py: Remaining slots: 159981018
2022-02-09T19:14:48.391Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:48.414Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:51.856Z INFO    plugin-watchtower.py: Sending appointment 907473c96b961514edc21efecbe05084 to ID
2022-02-09T19:14:52.286Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:52.286Z INFO    plugin-watchtower.py: Remaining slots: 159981017
2022-02-09T19:14:52.286Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:52.309Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:14:52.634Z INFO    plugin-watchtower.py: Sending appointment 5d7a19e1f875c6e312b356ea1691ce0f to ID
2022-02-09T19:14:53.311Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:14:53.311Z INFO    plugin-watchtower.py: Remaining slots: 159981016
2022-02-09T19:14:53.311Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:14:53.335Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:05.888Z INFO    plugin-watchtower.py: Sending appointment c49d05b68c5ffb05eb6fc7c47b956b34 to ID
2022-02-09T19:15:06.430Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:06.431Z INFO    plugin-watchtower.py: Remaining slots: 159981015
2022-02-09T19:15:06.431Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:06.453Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:06.696Z INFO    plugin-watchtower.py: Sending appointment 917a5a1c7446da382a67ed47213c23f2 to ID
2022-02-09T19:15:07.233Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:07.233Z INFO    plugin-watchtower.py: Remaining slots: 159981014
2022-02-09T19:15:07.233Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:07.263Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:16.156Z INFO    plugin-watchtower.py: Sending appointment 14abc1ee66f20ce20cbb818d6b96a186 to ID
2022-02-09T19:15:16.611Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:16.611Z INFO    plugin-watchtower.py: Remaining slots: 159981013
2022-02-09T19:15:16.611Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:16.634Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:16.952Z INFO    plugin-watchtower.py: Sending appointment 1e039ad43e8863a99d8608bb7146f604 to ID
2022-02-09T19:15:17.280Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:17.281Z INFO    plugin-watchtower.py: Remaining slots: 159981012
2022-02-09T19:15:17.281Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:17.304Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:20.442Z INFO    plugin-watchtower.py: Sending appointment fb89bbb0e574f89609e94901ade1eb20 to ID
2022-02-09T19:15:21.046Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:21.046Z INFO    plugin-watchtower.py: Remaining slots: 159981011
2022-02-09T19:15:21.046Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:21.070Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:21.223Z INFO    plugin-watchtower.py: Sending appointment<PHONE_NUMBER>5c71ae3d71adc34daf4c68 to ID
2022-02-09T19:15:21.921Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:21.922Z INFO    plugin-watchtower.py: Remaining slots: 159981010
2022-02-09T19:15:21.922Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:21.948Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:33.586Z INFO    plugin-watchtower.py: Sending appointment 66b439d24cd2647a1eff547cbff97ca0 to ID
2022-02-09T19:15:34.192Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:34.192Z INFO    plugin-watchtower.py: Remaining slots: 159981009
2022-02-09T19:15:34.192Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:34.215Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:34.228Z INFO    plugin-watchtower.py: Sending appointment 67ecc7b5208d47b0622c418663a2013f to ID
2022-02-09T19:15:34.824Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:34.824Z INFO    plugin-watchtower.py: Remaining slots: 159981008
2022-02-09T19:15:34.824Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:34.854Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:35.433Z INFO    plugin-watchtower.py: Sending appointment 5cfecaf7f16acf080fa5790eaa04dc13 to ID
2022-02-09T19:15:35.839Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:35.839Z INFO    plugin-watchtower.py: Remaining slots: 159981007
2022-02-09T19:15:35.839Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:35.862Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:35.946Z INFO    plugin-watchtower.py: Sending appointment 25c19243e57fcb853ef50e5353549cbb to ID
2022-02-09T19:15:36.300Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:36.300Z INFO    plugin-watchtower.py: Remaining slots: 159981006
2022-02-09T19:15:36.300Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:36.324Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:37.035Z INFO    plugin-watchtower.py: Sending appointment 93bea258b8a65922f2b2a67fe32f6fd2 to ID
2022-02-09T19:15:37.553Z INFO    plugin-watchtower.py: Appointment accepted and signed by ID
2022-02-09T19:15:37.554Z INFO    plugin-watchtower.py: Remaining slots: 159981005
2022-02-09T19:15:37.554Z INFO    plugin-watchtower.py: Start block: 722518
2022-02-09T19:15:37.607Z INFO    plugin-watchtower.py: Adding tower to Tower's db (id=ID)
2022-02-09T19:15:37.616Z INFO    plugin-watchtower.py: Sending appointment 531c53e4279195a08711033ed88aef73 to ID
2022-02-09T19:15:37.998Z INFO    plugin-watchtower.py: Killing plugin: stopped by lightningd via RPC
2022-02-09T19:15:37.999Z **BROKEN** lightningd: Already in transaction from lightningd/jsonrpc.c:948
2022-02-09T19:15:38.049Z **BROKEN** lightningd: FATAL SIGNAL 6 (version v0.10.2)
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: common/daemon.c:38 (send_backtrace) 0x556f12436da1
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: common/daemon.c:46 (crashdump) 0x556f12436df0
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x7f2497a1dd5f
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x7f2497a1dce1
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x7f2497a07536
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: lightningd/log.c:804 (fatal) 0x556f123da547
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: wallet/db.c:1060 (db_begin_transaction_) 0x556f1240f85a
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:205 (plugin_hook_callback) 0x556f124058c7
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:131 (plugin_hook_killed) 0x556f124055ec
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: ccan/ccan/tal/tal.c:240 (notify) 0x556f124ac61d
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: ccan/ccan/tal/tal.c:402 (del_tree) 0x556f124acb0c
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: ccan/ccan/tal/tal.c:412 (del_tree) 0x556f124acb5e
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: ccan/ccan/tal/tal.c:486 (tal_free) 0x556f124ace98
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: lightningd/plugin.c:345 (plugin_kill) 0x556f123ff302
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: lightningd/plugin_control.c:116 (plugin_stop) 0x556f12404830
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: lightningd/plugin_control.c:171 (plugin_dynamic_stop) 0x556f12404aaa
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: lightningd/plugin_control.c:229 (json_plugin_control) 0x556f12404ce3
2022-02-09T19:15:38.049Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:627 (command_exec) 0x556f123d3792
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:762 (rpc_command_hook_final) 0x556f123d3d97
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:275 (plugin_hook_call_) 0x556f12405c63
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:850 (plugin_hook_call_rpc_command) 0x556f123d4188
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:949 (parse_request) 0x556f123d4656
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:1040 (read_json) 0x556f123d49db
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:59 (next_plan) 0x556f1249b90d
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:407 (do_plan) 0x556f1249c4b7
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:417 (io_ready) 0x556f1249c4f5
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:453 (io_loop) 0x556f1249e6cb
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:21 (io_loop_with_timers) 0x556f123d19df
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: lightningd/lightningd.c:1163 (main) 0x556f123d78d7
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x7f2497a08d09
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x556f123ad399
2022-02-09T19:15:38.050Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff


Violation of license of scriban

Hi,
You are currently using the entire codebase of the scriban project https://github.com/lunet-io/scriban without retaining the original license which is violating its usage.
So please, I'm asking you to fix your license.
For guidance for your users, I would also appreciate that you specify that you are actually forking the original project scriban. Using a project like this (including the documentation) without properly giving back credits is really not the way to play respectfully in OSS world.

Nevermind, I found the license in https://github.com/lizoc/textscript/blob/master/THIRD-PARTY-LICENSE.txt

Reopening because you have been removing the license headers in the source files, while they should not be removed:
// Copyright (c) Alexandre Mutel. All rights reserved.
// Licensed under the BSD-Clause 2 license.
// See license.txt file in the project root for full license information.

Please update your code base to reflect that this header should not be removed.

Hi there. Sorry if you feel violated, that was certainly not the intention. I've added your copyright header to all files that contained your code. Let me know if you are satisfied.
If you would like more credit exposure beyond that and the third party license doc, I can also add something at the top of the readme, along the lines of "this project is adopted from scriban etc..". If you have wording in mind just let me know too.
FYI, numerous breaking changes are made and will be made here for my specific needs, things you probably would not care to consider in your project. That's why this is a hard fork that's expected to diverge from your code base in time. However, I have a fork on your repo too, and I do hope you are still cool if I make any PRs to your scriban project in the future based on that?

If you would like more credit exposure beyond that and the third party license doc, I can also add something at the top of the readme, along the lines of "this project is adopted from scriban etc..". If you have wording in mind just let me know too.

I  would prefer that instead of listing scriban as part of the "We take inspirations from the following repos"  you should separate it from the rest of this list (frankly, this is not just "inspiration" in the case of scriban) and explicit that TextScript is a fork of scriban, and explaining why. It will provide better guidance and avoid confusion.

As I said

I can also add something at the top of the readme, along the lines
of "this project is adopted from scriban etc.."

I have decided to add a big banner at the top of the readme that says this is a fork from your repo. I'll let you know once that's done, probably after new year.

Honestly, it was a oversight on my part to remove the header copyright notice, but that has since been fixed in the previous commit. I hope that means it's all good legally.
Coupled with the fork clarification I just said, I trust you have nothing to add?

Coupled with the fork clarification I just said, I trust you have nothing to add?

No that should be fine, thanks.

closing for now. feel free to open again if you are still having issues.


Minor style improvements

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

Project coverage is 96.80%. Comparing base (c2f86c5) to head (34ed76a).
Report is 1 commits behind head on trunk.

Additional details and impacted files
@@           Coverage Diff           @@
##            trunk      #57   +/-   ##
=======================================
  Coverage   96.80%   96.80%
=======================================
  Files          30       30
  Lines        1220     1220
=======================================
  Hits         1181     1181
  Misses         39       39

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


⚠ Avatar API Endpoint has degraded performance

In 95b2471, Avatar API Endpoint (https://avatar.roblox.com/v1/avatar-rules) experienced degraded performance:

HTTP code: 200
Response time: 4896 ms

Resolved: Avatar API Endpoint performance has improved in 5674678 after 9 minutes.


Use booleans instead of strings in the documentation

Booleans should be passed as true instead of "true".
Example: https://github.com/zitadel/terraform-provider-zitadel/blob/97b2d6c6cf46906ae4a15542bdf1b77bfba129f7/docs/resources/project.md?plain=1#L20
Docs: https://www.terraform.io/language/expressions/types#bools

Correct, I will have a look at it.

corrected examples in 1.0.0-alpha.8


Error on warnings when testing

Before https://github.com/zarr-developers/numcodecs/pull/619, it would be good to convert test warnings to errors, so we can make sure there aren't any warnings being raised that we're not expecting.

pre-commit.ci autofix


Problem: "nodes" subtree in "hctl status --json" is broken

Process type is a typing.NamedTuple which is converted to JSON with json
library incorrectly. This makes the part of "hctl status --json" payload already unparseable.
Here is how this subtree looks now:
  "nodes": [
    [
      "localhost",
      [
        [
          "hax",
          "0x7200000000000001:0x6",
          "<IP_ADDRESS>@tcp:12345:1:1",
          "started"
        ],
        [
          "confd",
          "0x7200000000000001:0x9",
          "<IP_ADDRESS>@tcp:12345:2:1",
          "started"
        ],
        [
          "ioservice",
          "0x7200000000000001:0xc",
          "<IP_ADDRESS>@tcp:12345:2:2",
          "started"
        ],
        [
          "m0_client",
          "0x7200000000000001:0x28",
          "<IP_ADDRESS>@tcp:12345:4:1",
          "unknown"
        ],
        [
          "m0_client",
          "0x7200000000000001:0x2b",
          "<IP_ADDRESS>@tcp:12345:4:2",
          "unknown"
        ]
      ]
    ]
  ]

So under "nodes" there is a list which messes up node name (string) with Process details (erroneously shown as sub-lists).
Solution: use simplejson instead for handling --json option.
Fixed output looks as follows:
  "nodes": [
    {
      "name": "localhost",
      "svcs": [
        {
          "name": "hax",
          "fid": "0x7200000000000001:0x6",
          "ep": "<IP_ADDRESS>@tcp:12345:1:1",
          "status": "started"
        },
        {
          "name": "confd",
          "fid": "0x7200000000000001:0x9",
          "ep": "<IP_ADDRESS>@tcp:12345:2:1",
          "status": "started"
        },
        {
          "name": "ioservice",
          "fid": "0x7200000000000001:0xc",
          "ep": "<IP_ADDRESS>@tcp:12345:2:2",
          "status": "started"
        },
        {
          "name": "m0_client",
          "fid": "0x7200000000000001:0x28",
          "ep": "<IP_ADDRESS>@tcp:12345:4:1",
          "status": "unknown"
        },
        {
          "name": "m0_client",
          "fid": "0x7200000000000001:0x2b",
          "ep": "<IP_ADDRESS>@tcp:12345:4:2",
          "status": "unknown"
        }
      ]
    }
  ]

@mssawant can we merge this patch?

@mssawant can we merge this patch?


Define Format

Need to finalize the format.

[x] Draft a document with the format (already in the repository)
[x] Decide on denormalized or normalized format: is ICES mixed record txt file
[x] Approve the format
[ ] Approve and insert the vocabularies
[x] Insert the format in ICES system
[ ] Add QC Rules based on the present schema
[ ] Test the files

ESAS-ICES format draft.xlsx

@Osanna123 I wasn't able to download the latest file from the Team chat. Can you drop it here again?

latest version ESAS-ICES_format_draft_v1.xlsx
also shared in Office.com for joint editing/commenting

Format approved at May 3, 2021 meeting. https://ices-tools-dev.github.io/esas/tables/ has been updated to reflect the adopted model.

Can we close this one?

Note that there still needed to be some changes to field characterics as well as to field descriptions, but this might be included in another issue?

It that to change the descriptions of the vocabularies?
Can that be address in the vocab items?

@cmspinto it is an update of the field descriptions (column Description) at http://datsu.ices.dk/web/selRep.aspx?Dataset=148 (to make it consistent regarding phrasing, punctuation, etc.). I haven't gotten around to do this yet.

@Osanna123 could you have a look at this one?


stickyModal not working for $state.go

I follow "Minimal Modal Sticky States demo"  to create this codepen: http://codepen.io/lbngoc/pen/zoVMEE
Currently, the modal is showing when use "ui-sref",
but when I go to state from $state.go, nothing is happened...
Please help to take a look and give me some advices..

It works with a few tweaks to your code! ;-)
http://codepen.io/anon/pen/egBgJp ;-)

@bigb6611 so we need stop the event to keep the code working, right ?

@lbngoc, that's right!
One other thing I noticed in your pen is the scope function name referenced on the ng-click event does not match the one defined on the root scope: openLoginModal vs openModalLogin
With this typo fixed, it all seems to work fine!


tpm2-tss-engine

OpenSSL cryptographic engine package for TPM 2.0
Uses the tpm2-tss package to provide an interface for OpenSSL to utilize TPM 2.0 for cryptographic purposes.
Metadata

homepage URL: https://tpm2-software.github.io/
source URL: https://github.com/tpm2-software/tpm2-tss-engine
license: bsd
platforms: linux

If someone needs a starting point: https://git.beyermatthi.as/nixpkgs/log/?h=init-tpm2-tss-engine
I started it but I do not have enough time right now. It fails during compilation because it tries to create symbolic links in the openssl installation (probably submit this as bug report to upstream).

@matthiasbeyer @Binary-Eater
I got it to build like this:
{ stdenv, lib, fetchFromGitHub, autoreconfHook, autoconf-archive, pkg-config
, pandoc, doxygen
# Runtime
, openssl, tpm2-tss
# Check
, cmocka, expect, tpm2-tools, ibm-sw-tpm2, coreutils, iproute }:

let
  pname = "tpm2-tss-engine";
  version = "1.1.0";
in stdenv.mkDerivation {
  inherit pname version;

  src = fetchFromGitHub {
    owner = "tpm2-software";
    repo = pname;
    rev = "v${version}";
    sha256 = "1pwc38izkk50s73xzcca1l5h265lmh4hcgpfq8lmbv5grq2qdal8";
  };

  nativeBuildInputs =
    [ autoreconfHook autoconf-archive pkg-config doxygen pandoc ];
  buildInputs = [ openssl tpm2-tss ];
  checkInputs = [ cmocka expect tpm2-tools ibm-sw-tpm2 coreutils iproute ];

  postPatch = ''
    patchShebangs bootstrap
    patchShebangs test
  '';

  preAutoreconf = "./bootstrap";

  enableParallelBuilding = true;

  configureFlags = [
    "--with-enginesdir=${placeholder "out"}/lib/engines"
    "--enable-unit"
    # Integration tests disabled, as they rely on TPM2 support
    # "--enable-integration"
  ];

  doCheck = true;

  meta = {
    homepage = "https://github.com/tpm2-software/tpm2-tss-engine";
    description = "OpenSSL Engine for TPM2 devices";
    license = lib.licenses.bsd3;
    platforms = lib.platforms.linux;
    maintainers = lib.maintainers.terlar ];
  };
}

Unfortunately I didn't have a TPM2 device when I packaged it (January last year). So could perhaps have saved you some time. I remember it failed the integration tests, but I just re-ran them now on a device that has TPM2 and then the integration tests passed as well. After the build I can execute the binary. Not sure what more I need to verify.

@terlar I finally got a chance to test your packaging.
You have a syntax error in your posting.
    maintainers = lib.maintainers.terlar ];

should be
    maintainers = [ lib.maintainers.terlar ];

I noticed this error when testing ./result/bin/tpm2tss-genkey.
./result/bin/tpm2tss-genkey key.priv
Could not load tpm2tss engine

This appears to be an issue with loading the shared object needed.
openat(AT_FDCWD, "/nix/store/dk9xkkxabg6mpcb3nahjg0pla75m69vq-openssl-1.1.1q/lib/engines-1.1/tpm2tss.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/nix/store/dk9xkkxabg6mpcb3nahjg0pla75m69vq-openssl-1.1.1q/lib/engines-1.1/libtpm2tss.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "Could not load tpm2tss engine\n", 30Could not load tpm2tss engine

The required shared objects are under result/lib/engines and not result/lib/engines-1.1.

This error makes sense to me.  Uses openssl library functionality for invoking the engine. Openssl does not know where the tpm2-tss-engine is located.
https://github.com/tpm2-software/tpm2-tss-engine/blob/0745b9df717a6613f1415173861df46ec660b425/src/tpm2tss-genkey.c#L38-L40
Integration tests pass for me as well with my tpn2 device. I think this could be upstreamed and then the next step is adding an option for openssl 1.1.1 to have this engine installed with it.
Openssl 3 will require tpm2-openssl.

Just fyi, I've created a PR to add tpm2-openssl: https://github.com/NixOS/nixpkgs/pull/299626


feat: introduce pg_shadow to support pg_bouncer

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
As title, resolve #10789
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[x] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[x] My PR contains user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

SQL commands, functions, and operators

Release note

Add system table pg_shadow: https://www.postgresql.org/docs/current/view-pg-shadow.html

userconfig seems to be an array, but as we return a NULL right now, wonder if it is accepted on the client side?
rest LGTM

Good catch, we'd better to make it consistent. I will fix it.


Support to show both of td-agent version and fluentd version at the same time

Problem
td-agent shows fluentd version, it doesn't match td-agent itself.
(In issue tracker, most of the reporters doesn't write both of them.)
Actual
td-agent shows only fluentd version
Expected
td-agent shows td-agent version and fluentd version at the same time.

related files:
./td-agent/msi/assets/td-agent.bat
./opt/td-agent/share/config.rb
fluent/version.rb

Expected result:
 /usr/sbin/td-agent --version
td-agent 4.0.1 fluentd 1.11.2 (2f80f6cf0a4aa44b9795cd6a66894a6b8fa70d06)

https://github.com/fluent-plugins-nursery/td-agent-builder/pull/226 should fix this.
Closing.


[GH-147] Trying to Fix the deploy workflow action

Change Description:
This may not have always been the case, but the last few times we've tried to used this workflow, it doesn't work.
I discovered a few things, one being (I think) it was always deploying to dev, no matter what.
Closes Jira(s):
GH-147
UW-Directory Pull Request checklist

[x] I have run poetry run tox
[x] I have selected a semver-guidance: label for this pull request (under labels,
to the right of the screen)

I have no concerns but someone closer to software development should do an approve here.

All the pieces look fine to me and the workflows are nicely documented.
I'm quite novice at writing github workflows so I'm unable to comment on better ways to do things or possible syntactic issues,

All the pieces look fine to me and the workflows are nicely documented.
I'm quite novice at writing github workflows so I'm unable to comment on better ways to do things or possible syntactic issues,

Cool, then I'm in good company ;) This is a port from another workflow in our identity.uw code base. I understand it somewhat better now. Thanks for the input.