Initial spike for duktape debugger support. Currently a work in

progress.
@nick-thompson, this is still in progress but thought I'd open up the PR so we can begin to discuss. I'll follow up with a comment on the PR explaining the current setup/workflow with the vscode extension using source maps.
Without source-maps it should still be possible to debug the main.js/bundle file in the duktape browser debugger I believe. Would need to switch off minification in webpack when building bundles to make this usable. I will test this shortly.
I've only been testing on Linux in the context of my app thus far so I'm about the pull this branch down on the mac and test with the example GainPlugin.
I need to make a PR to the vscode extension as I have had to fix/hack one thing to get this all working. I'll fork the extension and drop you a link over so you can play with it.
Note that I've had to edit duk_config.h as the debug defines need to be toggled at that level rather than in blueprint.cpp. This may prompt discussions about the build system and custom duktape headers but perhaps we can get away with this change to the default config for now?

@nick-thompson, could do with a quick opinon on a thing.
Should we include a default launch.json file for the duktape debugger setup? For example, if I load the jsui folder in GainPlugin/Source/jsui as the workspace root the launch.json for a duktape debug task looks as follows:
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach (duk)",
            "type": "duk",
            "request": "attach",
            "address": "localhost",
            "port": 9091,
            "localRoot": "${workspaceFolder}",
            "sourceMaps": true,
            "outDir": "${workspaceFolder}/build/js",
            "stopOnEntry": false,
            "debugLog": false
        }
    ]
}

Some users may wish to load the workspaceFolder as the root GainPlugin directory, i.e. if they wish to edit C++ in VsCode and stay in one editor session for everything. What do you think we should provide as the example for this?

Good question. I lean towards leaving editor config files out of the repository because it's such a personalized thing, but we should definitely have a clear guide in the docs for this. I think Create React App's "Setting up your editor" is a good example: https://create-react-app.dev/docs/setting-up-your-editor/

@nick-thompson. Quick question about how you think hot-reload and debug should behave together. Because we reset the EcmascriptEngine object during a bundle reload the debugging session is terminated. Should we concern ourselves with this? Is there any need to attempt persisting debug sessions whilst making changes with a watch running? I'm not sure how this would work right now.
Perhaps we could get away with only resetting the EcmascriptEngine instance in the event of an evaluation error?

Yea, another good question, and that makes me realize– if we require CMD+D/CTRL+D to attach the debugger, then how would you catch a debugger statement or an uncaught error that comes up in the initial bundle evaluation? I suppose you'd have to CMD/CTRL+D to attach the debugger, then maybe CMD/CTRL+R to reload/re-evaluate the bundle?
This actually makes me think I was wrong earlier– perhaps carrying a member flag enableDebugging on ReactApplicationRoot is a good idea (toggled true/false by CMD/CTRL+D), and at the time that we reset the EcmascriptEngine (basically right before beforeBundleEval) we can also say if (enableDebugging) { engine->attach(); } to debug the bundle eval step.
That would also satisfy your question: if you've enabled debugging with CMD/CTRL+D, we can do the hot reload like normal and attach the debugger again before the bundle eval.
What do you think?

Yea, another good question, and that makes me realize– if we require CMD+D/CTRL+D to attach the debugger, then how would you catch a debugger statement or an uncaught error that comes up in the initial bundle evaluation? I suppose you'd have to CMD/CTRL+D to attach the debugger, then maybe CMD/CTRL+R to reload/re-evaluate the bundle?
This actually makes me think I was wrong earlier– perhaps carrying a member flag enableDebugging on ReactApplicationRoot is a good idea (toggled true/false by CMD/CTRL+D), and at the time that we reset the EcmascriptEngine (basically right before beforeBundleEval) we can also say if (enableDebugging) { engine->attach(); } to debug the bundle eval step.
That would also satisfy your question: if you've enabled debugging with CMD/CTRL+D, we can do the hot reload like normal and attach the debugger again before the bundle eval.
What do you think?

Yeah this is basically the sort of scheme I had in mind initially but I thought I'd maybe over-thought/over-engineered it a bit. OK. I'll have an experiment with this. If fixed everything else otherwise and then I can add a simple addition to the README with VSCode editor setup and debug instructions.
I want to give this a good test on Linux, Mac and Windows to sanity check before merging.

@nick-thompson, the CMD-R reload idea might still be nice regardless actually.

@nick-thompson, I'm finishing this off at the moment.
One question,
As a user of a debug client, I probably expect detaching (i.e. hitting stop in vscode) to switch off the enableDebugging flag. i.e. I don't want blueprint to continue calling duk_debugger_attach (blocking the UI) each time there is a hot-reload once I have deliberately disconnected from the debug client.
However, there is no simple mechanism in duktape to determine from where a duk_debug_detached_function callback has originated. i.e. it may have been triggered from the debug client (stop in vscode) or it may have been triggered by some socket connection error, or a hot-reload etc. So there is no straight forward way to reset enableDebugging when a detach is triggered from a debug-client vs leaving enableDebugging set when detach is triggered from a hot-reload.
There is probably a long winded way to make this work using the user data pointer supplied by duktape to the duk_debug_detached_function callback and passing some flag/callback from ReactApplicationRoot into EcmascriptEngine::debuggerDetach(). However, this feels a bit overkill and potentially error-prone for this edge case? It could be a "debug support 2.0".
To allow the user to terminate the re-attach behaviour but keep the app running, do we want to offer some sort of CTRL-C/CTRL-E command which forcibly detaches the debugger and resets to enableDebugging flag? This behaviour would need to be added to the docs as a "thing to know".
i.e. once you hit CTRL-D/CMD-D blueprint with alway await a debug client connection on a hot-reload until you forcibly reset this behaviour with CTRL-C/CTRL-E.
What do you think?

@nick-thompson, thinking about this more. Is it actually necessary for us to be resetting the EcmascriptEngine object in ReactApplicationRoot::handleBundleChanged and ReactApplicationRoot::handleBundleError ? The errors we receive in handleBundleError look like they should all be recoverable as opposed to the fatal errors handled by fatalErrorHandler in blueprint_EcmascriptEngine.cpp.
If we didn't reset engine in these calls that would simplify things greatly. provide we always use the safe variants of the duktape functions like duk_pcall, duk_peval I can't see from the API docs that we are then unable to reuse the context/engine. We always evaluate the bundle as a function and then pop said bundle off of the duk stack. So can we not simply evaluate the changed bundle again in a reload and do away with the engine/context reset?

However, there is no simple mechanism in duktape to determine from where a duk_debug_detached_function callback has originated. i.e. it may have been triggered from the debug client (stop in vscode) or it may have been triggered by some socket connection error, or a hot-reload etc. So there is no straight forward way to reset enableDebugging when a detach is triggered from a debug-client vs leaving enableDebugging set when detach is triggered from a hot-reload.
There is probably a long winded way to make this work using the user data pointer supplied by duktape to the duk_debug_detached_function callback and passing some flag/callback from ReactApplicationRoot into EcmascriptEngine::debuggerDetach(). However, this feels a bit overkill and potentially error-prone for this edge case? It could be a "debug support 2.0".

Interestinggg, thanks for digging into that. I see what you mean, there might be a way to thread some void* udata through there but I agree that it seems error-prone and tricky. I like your suggestion, let's call that "debugging 2.0," come back to it later, and for now implement the "manually detach" hotkey. So we'll have CTRL+D = attach, CTRL+E = detach, CTRL+R = re-evaluate the loaded bundle?

@nick-thompson, thinking about this more. Is it actually necessary for us to be resetting the EcmascriptEngine object in ReactApplicationRoot::handleBundleChanged and ReactApplicationRoot::handleBundleError ? The errors we receive in handleBundleError look like they should all be recoverable as opposed to the fatal errors handled by fatalErrorHandler in blueprint_EcmascriptEngine.cpp? https://duktape.org/guide.html#normal-and-fatal-errors
If we didn't reset engine in these calls that would simplify things greatly. Provided we always use the safe variants of the duktape functions like duk_pcall, duk_peval I can't see from the API docs that we are then unable to reuse the context/engine. Am I right in saying we always evaluate the bundle as a function and then pop said function off of the duk stack after calling it? So can we not simply evaluate the changed bundle again in a reload and do away with the engine/context reset?

Right, this is a great question and I think worth a careful discussion. If we can get away without resetting the engine and that simplifies things like debugging for us, it's obviously a win. I spent a min with the docs again and I think you're right, but I see two "gotchas" here that I think we should figure out: the first is what happens if the user doesn't supply the handleError callback? For the engine that ReactApplicationRoot owns, we can easily guarantee that this callback is provided, but what does that look like? In debug mode it's great to pop up that red screen unless the user has overriden the error handler callback, but what is sensible behavior for release mode? Is it fair to pop up that red screen in debug and release and enforce that the user, if they want different behavior, must override? Maybe it is... Then the second one is that the user always has access this global state in the ecmascript engine via the global keyword (this is common in js engines, it's window in browsers and global in node), and there's nothing to prevent the user from writing state to global. When we reset the engine, we guarantee that the next bundle eval will start from a clean slate. When we don't, the user kind of has this opportunity to shoot themselves in the foot. I can make arguments for either case, but I think it's something we should at least be aware of and careful of as we make this decision

"what happens if the user doesn't supply the handleError callback"

Yeah I thought about this. So, we could make this a requirement, i.e. a constructor dependency on EcmascriptEngine. Failing that, from a personal point of view I'd have no objection to the red error screen being displayed in production as my bundles are minified and stack traces/errors are obfuscated. Obviously that doesn't speak for all the other users out there! Clearly stating in the docs that users must override this if they wish different behaviour seems fair to me though?
I also think we might want to provide callbacks for both "normal" and "fatal" errors. This is particularly useful in embedded environments. Then perhaps clearly state the engine/context CANNOT be reused in the event of a fatal error etc. We could link to the duktape docs there?

"user always has access to global state in the ecmascript engine via the global keyword"

The idea being that a user could modify the global object/state and this may have side effects on bundle eval because the expect global to be untouched at evaluation? Yeah you would know far more about the pitfalls here than I. I think you'd be best to make the call whether we can state "Avoid this as best practice and if you modify global be aware you do so at your own risk. Generally speaking this should only be an issue in debug builds when hot-reload is enabled (at least for the moment).

"Then they think they've made their app robust, never see the red screen anymore and forget to write a release-mode override, suddenly they're shipping an app that red-screens on their users in random edge cases"
Yeah I totally get the concern. The main dev process is probably going to come through ReactApplicationRoot which will have the default error handler switched on in debug builds. It might not be a major issue to throw an unhandled exception if no error handler is supplied to be fair?. After all the user can't expect their component to render after an eval error and if they do want to handle production evaluation error in any specific way they override the handler. This could be clearly documented.
"Anyway I'm generally in favor of finding the right way to not reset the engine because I do see that it would simplify our code"
I think the good thing about it is it delivers a pretty familiar development experience to people used to working with hot-reload and debug in a browser. Definitely needs careful code/consideration though. I've got the basics running fine but need to stamp out all the little gotchas.

@nick-thompson, the other thing I think we might need to do is to copy out our own version of duk_trans_socket_unix.c from the duktape examples to make a couple modifications. In some cases disconnecting the vscode debugger and interacting with the UI soon after can cause a SIGPIPE to be triggered when attempting to write debug infomation to the socket associated with the debug tcp connection.
The duk_cmdline.c app actually swallows SIGPIPE to stop it from terminating:
static void set_sigint_handler(void) {
	(void) signal(SIGINT, my_sighandler);
	(void) signal(SIGPIPE, SIG_IGN);  /* avoid SIGPIPE killing process */
}

I suspect we may want a similar handler somewhere or a more refined version of duk_trans_socket_unix.c which handles SIGPIPE signals.

Hmm how about this:

For the ecmascript engine reset, let's ignore the case where the user can shoot themselves in the foot by writing to global. It's generally just a bad practice and I don't think we should go out of our way to support a bad practice
For the error screen, I'm cool with the idea of showing the red screen in both debug and release and making it clear in the docs that they should override that for release builds
I'm not sure I follow the "normal"/"fatal" error distinction– isn't a fatal error just a normal error that was never caught in javascript land? I think we only need the one "fatal" error handler, and if the user wants to get more fine-grained error handling they can always try/catch in javascript and call their own native metods if they need to handle that back in C++
Re: sockets, interesting, this is definitely not in my wheelhouse either :) I'm happy with whatever we need to do to get it working, and we can always revisit later to improve

Awesome, thanks Nick. Nice clear concise set of behaviour/requirements as always.
Cool. I agree with all of the above. I will sanity check on the distinction between "fatal"/"normal" errors in the docs when I'm back at my desk. I was under the impression that normal errors meant you could carry on using the duktape context (i.e. if we do not dispose engine in "normal" errors) whilst "fatal" errors are basically "something has gone terribly wrong, abort abort!". I probably need another read through the guide though.
The sockets thing probably makes sense to hack inline as we've done with duk comment and just leave a sensible comment and open issue to do better.

@nick-thompson, So I'm pretty sure there is a distinction between normal and fatal errors that we should be aware of but we don't need to do anything about it for the moment other than to clearly document it I think. EcmascriptEngine provides the onUncaughtError override already, allowing users to handle "normal" errors, it also registers a fatal error handler EcmascriptEngine.cpp:133.
Normal errors are those returned by the duktape protected calls (i.e. duk_pcall etc.). Those errors can be handled either in C/C++ by examining the protected call's return code or they can be handled prior by js code by catching.
A fatal error is an error that either is not handled or is unrecoverable.
From the duktape docs:
"An ordinary error is caused by a throw statement, a duk_throw() API call (or similar), or by an internal, recoverable Duktape error. Ordinary errors can be caught with a try-catch in ECMAScript code or e.g. duk_pcall() (see API calls tagged protected) in C code.
A fatal error is caused by an uncaught error, an assertion failure (if enabled), an explicit call to duk_fatal(), or an unrecoverable error inside Duktape."
So for the normal error case, the default onUncaughtError handler provided by ReactApplicationRoot shouldn't reset the EcmascriptEngine instance as the duk context can still be used to evaluate code etc. This makes the debug/hot-reload workflow perform as expected.
i.e. I can attach a debugger and start my webpack watcher, if I make an edit that causes an eval/webpack-compile error then the ReactApplicationRoot error handler is called (red screen of death) but my debug session is not terminated. I can then read the error, correct my mistake and webpack/blueprint reloads the bundle with my debug session still running.
In the case of the fatal handler we currently crash out (throwing from EcmascriptEngine). I think at some point we may want to provide an error handler for both cases of a flag to the onUnhandledError callback identifying whether the error is normal or fatal. For now maybe it makes sense to just clarify the doc/comment around EcmascriptEngine::onUncaughtError to clarify and we could open a "Comprehensive error handling" issue?

@nick-thompson, related question. I'm seeing the error messages/traces printed to the red error screen as a jumbled mess at the moment. I feel like I've hit this before and you showed me how to correct it. Does this ring any bells? Want to ensure this is working for the new development workflow.

@nick-thompson, FYI I started a basic first draft for WIKI instructions to set this all up here: https://github.com/JoshMarler/blueprint-wiki/commit/3648d0cf44c0ef6292cf788252f8dab07fc8e824

@JoshMarler this looks excellent, thanks so much for your work. I'll wait for your update on how the testing goes but otherwise I'm happy to merge! Also I read through the wiki edits and I love it, happy to merge that ASAP as well.
Re: the jumbled error screen text, can you send a screenshot? I suspect this is the result of the minifier in webpack but hard to say without seeing it.
Re: errors, ahh ok, thanks for the clarification. So that makes me think that in almost all cases we'll be dealing with recoverable errors (because we do everything in a duk_pcall and pop up the red screen when we catch something). Even if it's an uncaught user exception, we'll still catch it at the pcall boundary. It sounds like we'll hit the fatal error handler largely in 2 cases: explicit calls to duk_fatal and duktape internal errors. So as it concerns the recoverable errors, I think that gives us plenty of reason to go ahead with not resetting the EcmascriptEngine in the error handler, which helps keep the debugging simple and sensible. Then for the fatal errors, I anticipate it being a very low percentage of errors, so I think it would be fair to not let this case impact the design decisions around how ReactAppRoot consumes EcmascriptEngine, so long as we provide the user a way to deal with fatal crashes in production (mostly I mean that we should not concern this case too much in our decisions around hot reloading and debugging)

Yeah awesome. Maybe we can provide a separate handler override for fatal errors or give the existing one some sort of flag. Probably worth raising an issue. I'm just giving mac a bit of a test. I have to confess I rarely test Windows so I will need to get my Windows machine setup for blueprint now to check everything.

Yeah awesome. Maybe we can provide a separate handler override for fatal errors or give the existing one some sort of flag. Probably worth raising an issue. I'm just giving mac a bit of a test. I have to confess I rarely test Windows so I will need to get my Windows machine setup for blueprint now to check everything.

Sounds great. Yea, separate handler or flag for fatals sounds good, I'll open an issue there to
And yea, I'll go ahead and fetch/merge the wiki when I can!

@nick-thompson, here is a screenshot of the mangled error. I'll dig into it but thought I would post here incase you've seen similar. Using webpace --mode=development

Oh yup, that's webpack trying to add terminal colors to the output. I forget exactly what you need to do but basically need to configure webpack to not use colors

Oh yup, that's webpack trying to add terminal colors to the output. I forget exactly what you need to do but basically need to configure webpack to not use colors

Awesome. Cheers, I'll do a bit of Googling.

@nick-thompson, just testing on mac. I hadn't tested mac since the duk_config change. Looks like JUCE_DEBUG isn't defined at the point of processing duk_config.h on mac ... Need to check why. Just in case you do to experiment.

@nick-thompson, mac all good. Just testing Windows but build is failing at the moment so will drop you a separate PR shortly fixing some compiler errors. My fault, I've not been testing Windows enough. Will be great when Blueprint has some sort of CI pipeline so save us from fools like myself :-)

Agreed! There's an issue open for that... I'll try to tackle it one of these days :D

@nick-thompson, FYI I have found why debugging isn't working on Windows using the extension. I've raised an issue here: https://github.com/harold-b/vscode-duktape-debug/issues/63
I'm going to test hacking this out locally. We could potentially offer a modified version of the extension bundle/dist folder Blueprint users can copy until this is resolved. I'm not sure how actively  supported the extension is. I could fork it and we could reference the fork in the docs etc.

@nick-thompson, I've found one additional issue whilst I've been back and forth between hot-reloading and debugging on windows.
When running the GainPlugin example we hit exceptions in EcmascriptEngine::invoke when calling duk_require_function. This is because the BlueprintGenericPluginEditor triggers parameterValueChanged in it's afterBundleEval callback which dispatches an event via the engine.
The mistake here is that afterBundleEval is called and BlueprintGenericPluginEditor has no knowledge of the fact that there was an evaluation error. We got away with this before because ReactApplicationRoot checks for if (engine) before calling engine->invoke. The engine instance would have been nullptr in the old approach where we reset the engine in the event of an error.
So, we need to give afterBundleEval callbacks someway to determine whether bundle evaluation passed or failed. I suspect the thing that makes the most sense here is to return a result from EcmascriptEngine::evaluate which clearly signals that an eval error has occured:
 if (onUncaughtError != nullptr)
                {
                    const juce::String trace = duk_safe_to_stacktrace(ctx, -1);
                    const juce::String msg = duk_safe_to_string(ctx, -1);

                    // Call the user provided error handler
                    std::invoke(onUncaughtError, msg, trace);

                    return juce::var::undefined();
                }

Right now we simply return juce::var::undefined. Perhaps we could return/define some constant wrapped in a  juce::var which signals that an error has occured and pass this to the afterBundleEval callback. i.e. juce::var result = juce::String("Evaluation_Error") etc.
The afterBundleEval callback type would become something like:
using BundleEvalCallback = std::function<void(std::optional<juce::File> bundle, juce::var result)>;
What do you think?

Cannot work this out. There should be no race condition with the flag stored in afterBundleEval on BlueprintGenericEditor but I'm still seeing occasional throws from duk_require_function when dispatching the parameterValueChange event.
        appRoot.afterBundleEval = [=] (std::optional<juce::File> bundle, juce::var result)
        {
            if (bundle && bundle->getFullPathName() == bundleFile.getFullPathName())
            {
                if (result != EcmascriptEngine::EvaluationError)
                {
                    bundleValid = true;
                    afterBundleEvaluated();
                }
                else
                {
                    bundleValid = false;
                }
            }
        };
    }

      throttleMap.throttle(parameterIndex, 1000.0 / 30.0, [=]() mutable {
            juce::MessageManager::callAsync([=]() mutable {
                if (bundleValid)
                {
                    appRoot.dispatchEvent(
                        "parameterValueChange",
                        parameterIndex,
                        id,
                        defaultValue,
                        newValue,
                        stringValue
                    );
                }
            });
        });

@nick-thompson, aaahhhh OK. I think I have fixed the issue. I was filling up the duk value stack by repeatedly calling EcmascriptEngine::registerNativeRenderingHooks in response to a bundle change. Effectively registering duplicates. I've removed this and now only registerNativeRenderingHooks in the EcmascriptEngine constructor and it's all working as expected. This works as we no longer dispose the duktape ctx in response to an error.
Would still be good to get your thoughts on where the responsibility for avoiding calls to dispatchEvent should live when we are in the middle of a bundle eval error. i.e. do we pass it to afterBundleEval or do we set some state on EcmascriptEngine to signal that we have a bundle eval error until the next successful call to evaluate (could get more complex with multiple bundles but I think that whole story is a thing for later)

@nick-thompson, Now that I'm looking at the lambda release pool stuff along with this I'm starting to wonder if changing the reset of EcmascriptEngine might be a rather larger task than I had initially realised right now ... It may be that we keep the reset and users just have to be aware they will need to reconnect the debugger manually if they are hot-reloading at the same time etc.
I'm reading through the code now to inform the decision ....

Hey @JoshMarler this is awesome, sorry I didn't get back to you sooner!
Ok, got you, great catch on the duplicte native hooks, that makes sense. Sounds like a triiiicky bug lol
Re: the callbacks, yea, I haven't thought about this case but you're totally right. My gut is that it would feel nicer, from the user's perspective, for afterBundleEval to only be invoked in the case of a successful evaluation. I hear you though, it could get tricky to implement that. After a brief minute with it, I think my proposal would be this: change the return types of our invoke/evaluate methods from juce::var to std::optional<juce::var>. The optional will be empty if we hit an error along the way (and if you've defined the onUncaughtError callback you will have received your call to it), and otherwise will contain the result of the evaluation (which might be undefined, but that would be different from an empty optional). Then in ReactAppRoot we would do something like:
if (auto result = engine.evaluate(bundle) && afterBundleEval) {
    afterBundleEval();
}

How does that sound?
Also, love this trick!
duk_push_context_dump(ctx);
DBG(duk_to_string(ctx, -1));
duk_pop(ctx);

I didn't know about it but I can tell immediately how useful that will be

Oh, just saw the comment on the release pool– yea, I would say don't worry about tackling that yet. I think it's fair to try to limit the scope of this PR and come back in a second PR to try to address that, whether that involvese keeping the Engine reset in place for now or allowing the release pool to grow. Either way we can come back and fix those, but I definitely understand the feeling when a PR feels like it's growing!

@nick-thompson, Yeah OK  interesting. I basically just had the following at the moment.
EcmascriptEngine held a static member type to denote an error:
 static constexpr auto EvaluationError = "EcmascriptEngineEvalError";

evaluate then returned said code in the event of an error:
    juce::var EcmascriptEngine::evaluate (const juce::File& code)
    {
        juce::var result = juce::var::undefined();

        if (!detail::safeCompileFile(ctx, code, onUncaughtError))
            return juce::var(EvaluationError);

        // Call compiled function
        if (duk_pcall(ctx, 0) != DUK_EXEC_SUCCESS)
        {
            if (onUncaughtError != nullptr)
            {
                const juce::String trace = duk_safe_to_stacktrace(ctx, -1);
                const juce::String msg = duk_safe_to_string(ctx, -1);

                // Call the user provided error handler
                std::invoke(onUncaughtError, msg, trace);

                duk_pop(ctx);
                return juce::var(EvaluationError);
            }

            duk_throw_raw(ctx);
        }

        // Collect the return value
        result = readVarFromDukStack(ctx, -1);
        duk_pop(ctx);

        return result;
    }

However if we do this or return std::optional it's arguable that things like EcmascriptEngine::invoke might want to follow suit rather than returning juce::var::undefined.
The beforeBundleEval callback disappears if we do away with the engine reset and I had a single onBundleEval/afterBundleEval callback which was of the following type to include error code:
        using BundleEvalCallback  = std::function<void(std::optional<juce::File> bundle, juce::var result)>;

User's have the onUncaughtError callback so I couldn't decide whether returning the error code in the bundle eval callback is of worth or not. onUncaughtError may be raised from multiple locations whilst passing the error result to onBundleEval makes it clear where the error came from and allows for special case handling in hot reload etc. etc.

Oh, just saw the comment on the release pool– yea, I would say don't worry about tackling that yet. I think it's fair to try to limit the scope of this PR and come back in a second PR to try to address that, whether that involvese keeping the Engine reset in place for now or allowing the release pool to grow. Either way we can come back and fix those, but I definitely understand the feeling when a PR feels like it's growing!

Yeah ... It would be really nice to keep the debug/reload behaviour we get by not resetting the EcmascriptEngine by it's starting to look like that might require some significant changes. I'm gonna spend the next few hours going over it all and workout exactly what needs to be done to make it work safely and then decide whether to bail out.

@nick-thompson, hmmm. You know what. It might not need to be as complicated as I thought to sort this out.
My worry was that I would go and clear out the LambdaReleasePool which would break the native methods and props that are no longer registered via a beforeBundleEval callback, because those registrations are now effectively a "one time" initialisation. Actually, we just need an equivalent callback clients use to register those same things. That way clearing the LambdaReleasePool should be safe. This could even still be the beforeBundleEval callback.
I'll have an experiment and push up a change for you to peruse. Can always be rolled back if this ends up unravelling.

@nick-thompson, yeah I think keeping the EcmascriptEngine reset is the only sensible way to go at the moment with this. I've tried numerous approaches but there are just way too many subtle problems. For starters, for every bundle eval/re-eval we end up duplicating the value stack if we don't reset the duktape heap. I can see after 2 bundle reloads I have 3 copies of core.js's code in the value stack.
There's also a tonne of subtle issues around clearing out the LambdaRelease pool etc. Given this experiment was only to support a particular development workflow I don't think it's worth going through all the pain, this code isn't required in release outside of a development workflow. At least we can attach a debugger and get stuff done.
I'm going to have one more last run through to see if anything nice can be done in regards to debugger reconnects should people edit and reload at the same time. Might be that the the original scheme where we check a flag after bundle evaluation to see if we should re-attach the debugger works best. A better route might even be for a debug client to repeatedly attempt reconnects when it has been forcefully killed or something.
Eesh, that was a rabbit hole to climb down .... Oh well, I actually understand how the guts of EcmascriptEngine/Blueprint work now so it was a valuable experiment. Thanks for all the back and forth on this one, I went too deep!

@nick-thompson, I can't quite believe it but even with the reset of EcmascriptEngine back in I'm still seeing the intermittent crash from duk_require_function in EcmascriptEngine invoke when reloading.
I'm dumping the context at various points.
In most casse after the call to duk_pcall in EcmascriptEngine::evaluate the context shows all content, i.e. it has the corejs stuff in there etc.
In the case where we crash I can clearly see that after duk_pcal (without pcall returning an error) the context/stack is missing the corejs stuff and looks exactly as it did prior to duk_pcall, that is the stack contains no content from the bundle, it only contains native C functions/props registered in beforeBundleEval and then an undefined object.
You know what ... I wonder if the timer checking the bundle state briefly see's the main.js file as empty or something when webpack rebuilds it ... maybe the rebuild of the bundle file isn't atomic and in some cases the BundleWatcher see's an empty/partially written file, thus duk_pcall doesn't fail and instead parses the bundle as undefined.
Hmmmm .... Bit of a theory but plausible. I can't see any other cause for this intermittent issue at the moment other than something is corrupting the value stack. Possible it's my implementation of the stuff around duk_pcompile etc.

@nick-thompson, I managed to get things working without the reset of EcmascriptEngine with some changes. The management of the duk stack and lambda release pool all works, I've done a bunch of dumping of the duktape context to check things are behaving. The below commit has a basic shape for this.
It's a somewhat chunky/nuanced change so I'd totally understand if you felt this was too risky just to allow hot-reload support under a debugger. I'm happy to back out back to resetting the EcmascriptEngine if that is the way we decide to go. It does allow users to attach a debugger, set breakpoints and edit/hot-reload, all without having to CTRL-D and manually reconnect the debug client every-time an edit is made.
https://github.com/JoshMarler/blueprint/commit/686179aa6619e0f72adefd8e83412947fb146ae6

Sorry I didn't get back to you sooner @JoshMarler! Busy weekend. Just left you some comments and I'm looking over the code again now

Sorry I didn't get back to you sooner @JoshMarler! Busy weekend. Just left you some comments and I'm looking over the code again now

No worries at all. Please take as much time as you need when I'm spamming you and feel free to ignore me or ask if I can slow down for a bit! I can keep some PR's on ice and drop them over as and when you have the time.

uld we try to sort that and tackle it here? Or

It suits me to do this hear if you're OK sweating through this PR Nick. Gotten to be a bit of a beast but I think it makes sense to get this all sorted here now.

@nick-thompson, You know what. I've started working on the error handling refactor and it's a reasonable chunk so if you're happy with merging the debugger changes in as is now I'll open up a separate PR for the error handling stuff. I've got a decent chunk of it implemented now but it might be nice to get this stuff in.

Thanks @JoshMarler, you're a champion. Sorry for my slow replies, crazy week over here.
Yea, I'm with you, let's merge here and revisit the error handling refactor in a separate PR. I'll take one last pass here and pull it in if all good!

Thanks @JoshMarler, you're a champion. Sorry for my slow replies, crazy week over here.
Yea, I'm with you, let's merge here and revisit the error handling refactor in a separate PR. I'll take one last pass here and pull it in if all good!

Not a problem! I've been hammering you with notifications I expect. Just happy to be on full steam with Blueprint at the moment.

Ok, yea, this is great! There's a couple conversations inline about the error handling, we'll just loop back on those in the followup. Happy to go ahead and merge here, mind if I rebase + squash on the way in?

Nah go ahead and rebase as you like. Wasn't too sure whether squash this all up into one or not.

Done 🎉 🙌 🍻

@nick-thompson, you the man.


Line 14: [Warning] Invalid file link:(~/notifications/objectivec-api/userdata/index.md).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Error in markdown renderer: -> becomes an arrow

In a code example, the -> is rendered as an arrow. So when copy/pasting such a code example, it will not work.
Eg. on https://www.jfx-central.com/learn-javafx/checkbox

Are you sure? When I copy it out, I still get.->
Maybe it's browser-dependent? But really strange that it is rendered this way.


Ensure all Syscalls have regression tests

The current regression test files Exception.cc and Syscall.cc for both AArch64 and RISCV seem to be missing many tests. These should be completed to ensure proper functionality of all system calls and exceptions that could be generated

Fixed with PR #379 merged into dev


wallpaper keeps resetting

when I refresh the page it resets the wallpaper
Desktop

OS: ChromeOS

https://user-images.githubusercontent.com/98791937/152002215-71351ce9-0aba-4c02-8810-d81059ffe40e.mp4

Browser: chrome
Version: 97.0

@ranvirsi this is not a bug ,its just not implemented to save the wallpaper's state :)

It's a feature, not a bug!

I remember

Oh sorry nevermind

Oh, who are you @ghost?

Why is your name in grey color?

@yashash1511 can you handle this? In the changeTheme function, change the wallpaper from default/img0.jpg to dark/img0.jpg and vice-versa. If the wallpaper is something else, don't change the wallpaper.

Sorry, I am bit busy these days & focusing on school-studies have pre-boards starting next week then Board-practicals then 2nd pre-boards then boards so I won't be able to contribute to the project for few months now :(

@yashash1511 no problem

If the wallpaper is something else, don't change the wallpaper.

I was trying it but

this won't work in a action


YouTube RSS video feeds show videos from years ago

Describe the bug
Since the new web ui version of commafeed, old YouTube videos appear in the feed, even they are from many years ago.
for example, today I got the following video in my feed:
https://www.youtube.com/watch?v=c5dGlgdHlaY
Because I’m following the rss feed of https://www.youtube.com/@ThisOldTony/videos.
in commafeed.com, the feed url in this example is https://www.youtube.com/feeds/videos.xml?channel_id=UC5NO8MgTQKHAWXp6z8Xl7yQ
Environment (please complete the following information):

CommaFeed version (or "commafeed.com"): commafeed.com
Browser [e.g. chrome, firefox]: any
Device [e.g. desktop, mobile]: any

Additional context
this used to work just fine.
This happens for so many YouTube feeds now. The date displayed in commafeed.com seems wrong: when clicking the video and going to YouTube, it shows xx years ago (I’ve had between 1 and 12 years ago)

I think you're right. Since January there's a new setting maxEntriesAgeDays that deletes entries older than a year from the database to keep the size of the database in check.
I think what's happening is:

The video was detected by CommaFeed when it was published
When the video was a year old, it was deleted from the database
Someone recently edited the description of the video:

CommaFeed incorrectly reads the updated instead of the published field and considers it's a new video

I will try to fix this ASAP.

I just deployed a fix on commafeed.com that should fix this. Let me know here if it happens again!

@Athou thanks a lot for such a quick and efficient response!
I’ll monitor it.
You’re outstanding :)


SerialBLE.begin(9600) not declare???

why my coding cannot compile because of [ SerialBLE.begin(9600) ] not declare???
i use this coding, but cannot compile:
#define BLYNK_PRINT Serial
#include <SoftwareSerial.h>
SoftwareSerial SwSerial(10, 11); // RX, TX
#include <BlynkSimpleSerialBLE.h>
// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "G7_TJoL9xY2yPkyYEbUVqAqHRvVfYZ34";
int fsrPin = 2;     // the FSR and cap are connected to pin2
int fsrReading;     // the digital reading
// Attach virtual serial terminal to Virtual Pin V1
WidgetTerminal terminal(V1);
// You can send commands from Terminal to your hardware. Just use
// the same Virtual Pin as your Terminal Widget
BLYNK_WRITE(V1)
{
// if you type "Marco" into Terminal Widget - it will respond: "Polo:"
if (String("Marco") == param.asStr()) {
terminal.println("You said: 'Marco'") ;
terminal.println("I said: 'Polo'") ;
} else {
// Send it back
terminal.print("You said:");
terminal.write(param.getBuffer(), param.getLength());
terminal.println();

}
// Ensure everything is sent
terminal.flush();
}
void setup()
{
// Debug console
Serial.begin(9600);
SerialBLE.begin(9600);
Blynk.begin(SerialBLE, auth);
Serial.println("Waiting for connections...");
// Clear the terminal content
terminal.clear();
// This will print Blynk Software version to the Terminal Widget when
// your hardware gets connected to Blynk Server
terminal.println(F("Blynk v" BLYNK_VERSION ": Device started"));
terminal.println(F("-------------"));
terminal.println(F("Type 'Marco' and get a reply, or type"));
terminal.println(F("anything else and get it printed back."));
terminal.flush();
}
void loop()
{  fsrReading = RCtime(fsrPin);
if (fsrReading == 30000) {
// if we got 30000 that means we 'timed out'
Serial.println("Nothing connected!");
} else {
Serial.print("RCtime reading = ");
Serial.println(fsrReading);     // the raw analog reading
// Do a little processing to keep the LED blinking
fsrReading /= 10;
// The more you press, the faster it blinks!
digitalWrite(ledPin, HIGH);
delay(fsrReading);
digitalWrite(ledPin, LOW);
delay(fsrReading);

}
delay(100);
}
// Uses a digital pin to measure a resistor (like an FSR or photocell!)
// We do this by having the resistor feed current into a capacitor and
// counting how long it takes to get to Vcc/2 (for most arduinos, thats 2.5V)
int RCtime(int RCpin) {
int reading = 0;  // start with 0
// set the pin to an output and pull to LOW (ground)
pinMode(RCpin, OUTPUT);
digitalWrite(RCpin, LOW);
// Now set the pin to an input and...
pinMode(RCpin, INPUT);
while (digitalRead(RCpin) == LOW) { // count how long it takes to rise up to HIGH
reading++;      // increment to keep track of time
if (reading == 30000) {
  // if we got this far, the resistance is so high
  // its likely that nothing is connected!
  break;           // leave the loop
}

}
// OK either we maxed out at 30000 or hopefully got a reading, return the count
return reading;
Blynk.run();
}

I have same problem

#define BLYNK_PRINT Serial
#include <SoftwareSerial.h>
SoftwareSerial SwSerial(10, 11); // RX, TX
#include <BlynkSimpleSerialBLE.h>
// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "YourAuthToken";
BlynkTimer timer;
void sendSeconds() {
Blynk.virtualWrite(V0, millis() / 1000);
}
void sendMillis() {
Blynk.virtualWrite(V1, millis());
}
void setup()
{
// Debug console
Serial.begin(9600);
SerialBLE.begin(9600);
Blynk.begin(SerialBLE, auth);
Serial.println("Waiting for connections...");
// Setup a function to be called every second
timer.setInterval(1000L, sendSeconds);
// Setup a function to be called every second
timer.setInterval(1000L, sendMillis);
}
void loop()
{
Blynk.run();
timer.run();
}

SoftwareSerial SerialBLE(10, 11); // RX, TX
This is the solution for serialBLE not declared, its from another reported issue here https://github.com/blynkkk/blynk-sketch-generator/issues/95#issuecomment-648577276

BLE is currently not supported in Blynk 2.0


vulkan-headers, vulkan-tools: fix version

Motivation for this change
This fixes an assertion error in vulkan-loader on version == vulkan-headers.version:
assertion failed at /nix/store/ca66sbxzxlxlfpb579nxxnw97z2ql1gv-source/pkgs/development/libraries/vulkan-loader/default.nix:8:1

The sha256 for vulkan-headers and vulkan-tools are unchanged because they were already set to the newer version. The correct version was lost in the staging-next merge.
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @FRidh @Ralith

@GrahamcOfBorg build vulkan-headers
@GrahamcOfBorg build vulkan-loader
@GrahamcOfBorg build vulkan-tools
@GrahamcOfBorg build vulkan-validation-layers

Thanks!


gulp does not finish the task

Hello There,
Why does not Gulp v4 finishes the task... for example the following task
gulp.task('test', function () {
    console.log('Hello World!');
  return "This is test message";
});

Using gulpfile ~/PhpStromProjects/AppCLI/gulpfile.js
Starting 'test'...
Hello World!

And then the process is idle and does nothing..
Iam using Gulp 4.0.0

I think you need to the entire Getting Started guide, as gulp 4 doesn't work the same as gulp 3 in regards to sync tasks (hint: they are completely unsupported).


1:N logic for the action nodes (and some other stuff)

This PR includes the contributions listed below, in order of importance (I would say).

Instead of replicating an action node for every pair of previous/next state (N:N logic), now we use only one dashed arrow from the previous state to the action, and many solid arrows from the action to the next state (1:N logic). This makes the resulting image more clean.
Create a text file from which a conda environment can be run, and update README.md accordingly with the necessary instructions to do it. This should facilitate contribution from others.
Modify the layout engine and add a background color to the state nodes (trying to slightly beautify the resulting image).
Stop tracking temporary files from the /img folder.

I just noticed that maybe I should have opened multiple PRs instead of a single one... sorry for that.

Thanks, Pedro. The feature contribution of 1:N logic for the action nodes makes the FMDP graph more organized. I'll merge this commit and the others to the master branch.


Update the image tags on v1.1.x branch

Update the images tag with v1.1.x-head
Signed-off-by: Khushboo<EMAIL_ADDRESS>

I can't put the reviewers
cc: @innobead


Can the readproxy be upgraded to support readcloser?

I am trying to work with a request body and the progress bar is wrapping the body as a reader.
Can the readproxy be upgraded to support readcloser? or can a readcloserproxy be added?

I'd like this too. I submitted a pull request for this a while back but it didn't go anywhere, I currently use a fork that has the functionality.

Now you can create pb.Reader with io.Reader or io.ReadCloser

@cheggaaa Thanks, tested to work as expected for http response body.
I think it can be closed.


[Question] Showing Chart in Angular 2+ (preferably Angular 9)

Hi Team,
I am trying to add/use charts in our form.
I noticed that there's already a solution to achieve this but the implementation uses Angular 1.x.
Reference :: https://github.com/formio/formio/issues/198
I just wanted to request if any such implementation can be provided for Angular 2+ (preferably Angular 9)
Use case ::
I need to implement a Risko meter which will get calculated based on some responses and gets changed accordingly just like the below image.

Thanks

That would be a cool component. Unfortunately I cannot think of anyone implementing a component that does such a thing, so you will need to implement this one on your own.

We're currently addressing a backlog of GitHub issues, and as part of this effort, some inactive issues may be marked as closed. This isn't a dismissal, but a step toward more efficient tracking.
If you feel the issue is still relevant, please re-open and we'll ensure it gets the attention it deserves. Your understanding is appreciated as we work to enhance our open-source responsiveness.


Should be "$sudo chgrp -RL" per comment on preceding lines. The -H parameter isn't very help or expected.

https://github.com/deployphp/deployer/blob/35027de18ba2eadd6205336961910f0f400e557c/recipe/deploy/writable.php#L56

Why -RL? Not -RH?


Plugin seems to be broken on latest version of Piwigo

Hi Jasper. Are you still maintaining this plugin? We have tested it on the latest Piwigo with the latest Keycloak, both running on FreeBSD 14 but are getting error messages. I can't seen any updates to this repo in last couple years so want to check you're still working on this before providing more information. I'm happy to pay for your assistance with this as we are using it at our small media publication. Thanks.

Works for me on FreeBSD with latest Piwigo and keycloak. What are the error messages?


where mod

no dsyons phere

please update your ticket with current status and expected story points @cmpashak

EXPECTED STORY POINTS: 4

List of stuff needed for MVP

[block/generator] Solar panel block: generates FE
[basic item] Orbital Collector: Use solar panels to craft orbital collector
[block/machine] Warp Dislocator: consumes orbital collector and FE
[block/generator] Ground station: generates FE proportional to number of orbital collectors consumed


Acess Denied for S3 buckets is not reporting

Environment info

NooBaa Version: noobaa-core-5.15.4-20240704.el9.x86_64
Platform: RHEL9

Actual behavior
see the below o/p specially the bold one, dir permission for user  s3user-1-dir is 770 and there is bucket associated to it  bucket-new-1 for which I set the chmod to 000, no permission at all, then why there is no invalid bucket[ACCESS_DENIED] in health command output of /usr/local/noobaa-core/bin/node /usr/local/noobaa-core/src/cmd/health --all_bucket_details | jq | less
If i did same  for s3user-1-dir then am getting the ACCESS_DENIED but for bucket there is no error for same scenario
[root@cluster4-41 ~]# ll /mnt/cesSharedRoot/
...
drwxrwx---. 3       10 wheel  4096 Jul 26 19:03 s3user-10-dir
drwxrwx---. 3 bin      bin    4096 Jul 26 19:02 s3user-1-dir
drwxrwx---. 3 daemon   daemon 4096 Jul 26 19:03 s3user-2-dir
drwxrwx---. 3 adm      sys    4096 Jul 26 19:03 s3user-3-dir
...
[root@cluster4-41 ~]# ll /mnt/cesSharedRoot/s3user-1-dir
total 1
d---------. 2 bin bin 4096 Jul 26 19:02 bucket-new-1
[root@cluster4-41 ~]#  /usr/local/noobaa-core/bin/node /usr/local/noobaa-core/src/cmd/health --all_bucket_details | jq | less
{
"service_name": "noobaa",
"status": "OK",
"memory": "267.6M",
"checks": {
"services": [
{
"name": "noobaa",
"service_status": "active",
"pid": "71215",
"error_type": "PERSISTENT"
}
],
"endpoint": {
"endpoint_state": {
"response": {
"response_code": "RUNNING",
"response_message": "Endpoint running successfuly."
},
"total_fork_count": 2,
"running_workers": [
2,
1
]
},
"error_type": "TEMPORARY"
},
"buckets_status": {
"invalid_buckets": [], <-- no invalid bucket
"valid_buckets": [
{
"name": "bucket-1",
"storage_path": "/mnt/cesSharedRoot/s3user-1-dir/bucket-new-1"
},
{
"name": "bucket-6",
"storage_path": "/mnt/cesSharedRoot/s3user-6-dir/bucket-new-6"
},
{
"name": "bucket-9",
"storage_path": "/mnt/cesSharedRoot/s3user-9-dir/bucket-new-9"
},
Expected behavior

bucket having no access should be reported in invalid buckets in health CLI

Steps to reproduce

manually changed the permission of the bucket folder to 000

More information - Screenshots / Logs / Other output

thank you  @Roushan45
we can definitely add a check for that, initially, we did only existence check, and I added also permissions check for account's new_buckets_path, so we need to add permissions check for that bucket's path.

Hey @Roushan45, we merged a fix for this issue, available on master, hence closing the bug, can you please validate?


Organize tests and start Hyprland testing

Sorry if this is too all over the place for a single PR... just kinda throwing various things together as I came across them and just wanted to fix them...

Organized the test folder a bit so that its easier to see which test suites are failing and manage them as they scale in size.
Start hyprland tests, just testing the getSocketFolder change recently.

This test suite caught a possible crash if someone unsets the XDG_RUNTIME_DIR before launching. Now, we continue to fallback to /tmp/hypr without seg fault.

Minor clang-format cleanup that was failing CI
Change linux builders to not cancel each other if one fails
Add python3-packaging dependency for opensuse image

Tested building docker image locally and then building in the opensuse container, fixed build.
NOTE: CI will still fail until an image is pushed with the fix.

Bump spdlog to next minor version

Fixes alpine build and still works with others.
https://repology.org/project/spdlog/versions shows its very well distributed amongst the distributions we test against.

@Alexays Did you need me to break this up or will this PR be fine in this state?

LGTM, thx!


Iteration over tuples does not show type

t = ((1,), (2,), (3,))
for x in t:
    x

t is shown as tuple[tuple[int], tuple[int], tuple[int]] which is correct, but x has no type. You can switch it to a list and it will work, like:
l = [(1,), (2,), (3,)]
for x in l:
    x

And now x is of type tuple[int].
Found in #334.

Fixed via #526.


Start game automatically when spacebar is pressed

On the countdown page for Quick Play, if you press spacebar the game will automatically begin

Uploading Screen Recording 2023-11-18 at 10.13.58 PM.mov…

https://github.com/wikispeedruns/wikipedia-speedruns/assets/64957454/bb850f56-b4fb-4011-9496-d48a2ca7e845

A general note on deleting things:
Having a more systematic way to delete user data would be really nice, not just for this particular issue. We've also had people ask about deleting personal data, which we would have to do manually (and tbh I'm not sure if we've kept up with that). Going through and refactoring the SQL schema with CASCADE rules would help this along. This is a great first step though!

Wrong PR? lol

Edited the message. Thanks!


Handle block reordering attacks

(Related to issue #345 - Handle transaction reordering attacks. See the mitigation ideas suggested there.)
There are a couple of ways that blocks could be re-ordered:

Each block is built by only one node. A node could hold on to some of its already-built blocks and reorder them before writing them to the bigchain table. (It could hold off on inserting the block timestamp and block id/hash until the last moment, so the timestamps are all in order.)
In each shard, there's a primary/leader node (for the bigchain table) which determines the block order. It could reorder some blocks. (Note: It may be that there isn't one true block order, thanks to physics, but there are false block orders.)

There are clues that block reordering has happened:

One can look inside the transactions in the blocks to spot clues. For example, does a block contain a large number of transfer transactions to transfer non-existent assets? Also, if we add sequence numbers to transactions (per client), then are the transaction sequence numbers badly out of order?
Look for anomalies in timestamps. (A smart malicious block-builder can write plausible timestamps, so this is just to catch the sloppy ones.)

Another thing that could be looked for (suggested by @libscott in conversation):
If a block wrote blocks A, B, C, in that order, to the bigchain table, then it should check that the final ordering (determined by the shard primary/leader) has those three blocks in the same order (maybe with some other blocks in between).

Not the concern of BigchainDB any more (as of version 2.0, coming out soon). Therefore closed.


add link to /transactions in an empty collective

If a host wants to manually add funds and there are no transactions in the collective, there is no direct link to do it. host must type the opencollective.com/:slug/transactions URL
example from https://opencollective.com/suffolkfosterparents#budget

https://github.com/opencollective/opencollective-website/pull/740


remove libprotoc.la from Makefile.am

Remove libprotoc.la from the build list. Otherwise, in the absence of instructions autotools will assume you wanted to build a file called libprotoc.c, then helpfully break when it can't find it.

Thanks for your contribution!


Stale/wrong values for (at least) mongodb_network_bytes_total

Hi,
I'm trying to use the mongodb_exporter but realize some odd issues. It's somehow not exposing the actual numbers for the mongodb_network_bytes_total sometimes. This is the output of curling the exporter every second:
mongodb_network_bytes_total{state="in_bytes"} 1.8038162909e+10
mongodb_network_bytes_total{state="in_bytes"} 1.8038213018e+10
mongodb_network_bytes_total{state="in_bytes"} 1.8038257311e+10
mongodb_network_bytes_total{state="in_bytes"} 1.8038289814e+10
mongodb_network_bytes_total{state="in_bytes"} 1.8038336711e+10
mongodb_network_bytes_total{state="in_bytes"} 1.22594549377e+11
mongodb_network_bytes_total{state="in_bytes"} 1.803846286e+10
mongodb_network_bytes_total{state="in_bytes"} 1.8038546902e+10
mongodb_network_bytes_total{state="in_bytes"} 1.8038588227e+10
mongodb_network_bytes_total{state="in_bytes"} 1.8038659031e+10
mongodb_network_bytes_total{state="in_bytes"} 4.974604715e+09
mongodb_network_bytes_total{state="in_bytes"} 5.00446282153e+11
mongodb_network_bytes_total{state="in_bytes"} 5.00446395761e+11
mongodb_network_bytes_total{state="in_bytes"} 4.974617148e+09
mongodb_network_bytes_total{state="in_bytes"} 5.00446665747e+11
mongodb_network_bytes_total{state="in_bytes"} 1.8039037928e+10
mongodb_network_bytes_total{state="in_bytes"} 5.00446920076e+11
mongodb_network_bytes_total{state="in_bytes"} 1.22597290424e+11

I've checked mongodb and those aren't counter resets or something. I suspect there is some issues with the shared/, maybe it creates two counters with the same name or something.
Will investigate this more next week.

weird, it's working fine on my side. did you restart the mongodb server?
Please let me know if you find what's causing the issue

@dcu No it didn't restart. And I also saw the issue with other metrics. In general lot of numbers seems to be off. I've checked the stats in mongodb via the mongo shell and they look correct, so it really seems like an issue with the exporter.

How's your setup? Replica set? Sharded? MongoDB version?
Also can you post an example of the exporter data vs db status data?
Thanks
On Tue, Dec 8, 2015, 11:27 AM discordianfish<EMAIL_ADDRESS>wrote:

@dcu https://github.com/dcu No it didn't restart. And I also saw the
issue with other metrics. In general lot of numbers seems to be off. I've
checked the stats in mongodb via the mongo shell and they look correct, so
it really seems like an issue with the exporter.
—
Reply to this email directly or view it on GitHub
https://github.com/dcu/mongodb_exporter/issues/7#issuecomment-162935776.

It's mongodb 2.6.9, 5 shards with 4 replicas each running on AWS. Here is the exporter and mongo cli output from the same time (<1s between):

https://gist.github.com/discordianfish/38c80b18364bc52b83df All good here
https://gist.github.com/discordianfish/a04db20657e8bda951d0 Differences of bytesIn vs in_bytes

When run in a loop and watching for the in_bytes counter this gets more apparent:
while true; do echo 'db.runCommand({ serverStatus: 1 })' | mongo <IP_ADDRESS>:27018 | grep bytesIn; curl -s localhost:9101/metrics|grep in_bytes; sleep 1; done
		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 5.177120978e+10
		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 1.0905279525e+11
		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 1.09052946269e+11
		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 1.0905312077e+11
		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 1.09053300953e+11

		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 1.09053478539e+11
		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 7.839116978e+09
		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 1.09053974839e+11
		"bytesIn" :<PHONE_NUMBER>,
mongodb_network_bytes_total{state="in_bytes"} 1.0905413353e+11

The exporter also isn't logging anything.

@dcu General question: Are you still using this exporter and plan to maintain it in the future? It looks like it's not working with mongodb 3.2 and the code isn't very go idiomatic so I would rather refactor it first before adding support for mongodb 3.2 and fixing this issue here.

@discordianfish I added you as collaborator to the repo, feel free to refactor it

@discordianfish  We should sync up I was going to start adding more metrics for replSet's and Sharding/mongos. Would like to work with you on your refactors so I take those into account before I do a pull request :)

@discordianfish We should sync up I was going to start adding more metrics for replSet's and Sharding/mongos. Would like to work with you on your refactors so I take those into account before I do a pull request :)

I just looked into refactoring it but I tend to rewrite it in a simpler way. I get that the dynamic configuration of 'interesting' values via the groups.yaml and things like that are nice but also make everything quite complex.

I think the yaml way while complex lends more toward Ansible integration wouldn't you say?  If you can think of another methodology I am curious. But I do see your point simple and clean interfaces are nice. I think there are two phases here  1) Refactor to be cleaner ( not me im not that good at go yet)  2) Expand the tool to support the entire mongo system not just stand alone nodes.  When do you think you might get to 1, so I know when I can get my team helping on 2? No rush just trying to plan resources.

Looks like @dcu started refactoring the code. That's great! Then I'll hold off with that for now and see if I can contribute to this code base after the refactoring is done.
@dcu If you have prometheus related questions, I'm happy to help!

Just FYI: I built a new sharded cluster, this time with mongo 3.2 and there metrics look much more reasonable.
I also confirmed that with current master, I still have the same problem on our old cluster.

@discordianfish are you passing more than one host in the URI parameter?

I think this was resolved with the commit from March 7. Please reopen if it is not.


https://issues.apache.org/jira/browse/FINERACT-1415 fix

Description
As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.
The fix is for using the java.security.SecureRandom class instead of java.util.Random & java.lang.Math.random() .
As per SonarQube Analisys this is a Weak Cryptography Category & Medium
https://sonarcloud.io/project/security_hotspots?id=apache_fineract#
Jira Ticket was opened https://issues.apache.org/jira/browse/FINERACT-1415
Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!

[X] Write the commit message as per https://github.com/apache/fineract/#pull-requests

[X] Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.

[X] Create/update unit or integration tests for verifying the changes made.

[X] Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.

[X] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/api-docs/apiLive.htm with details of any API changes

[X] Submission is not a "code dump".  (Large changes can be made "in repository" via a branch.  Ask on the developer mailing list for guidance, if required.)

FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.

When I looked at this, Travis had not completed the integration tests so did not know if they'd pass.
They did, so that's ok. Now just if @IOhacker you can squash the commits please?


ClippingPlaneCollection error

ClippingPlaneCollection destroy error
call tileset.clippingPlanes.destroy

tileset.clippingPlanes = undefined;

Browser:
Chrome 109.0.5414.74
Operating System:
windows 10

Hi there @lewhonly. Would you be able to include a Sandcastle example that replicates the issue? That would help us give us more context to determine the issue. Thanks!

Thanks for the report @lewhonly, but I'm closing this issue due to inactivity. If you believe this is still an issue, please feel free to re-open. Thanks!


Surface model permits correlated attributes

This adds some extra fields to the surface model file.  It facilitates a new technique that I've been working on for a while with Niklas Bohn (GFZ) in which we estimate surface properties via joint correlation with surface reflectance parameters.  In the past, we have added these properties as "unobserved reflectance channels."  But this is a bit awkward.  Here, I add this information to the surface model, so that the parameter inference can be performed as a postprocessing step conditioned on the reflectance solution.  This would allow the ISOFIT reflectance model to use the same wavelength grid as the instrument, simplifying the rest of the code.

Looks good, thanks!


Re-validate data pre-processing

We need to re-validate whether the current pre-processing is OK. There were some changes to predicu.data in https://github.com/icubam/icubam/pull/309 and also some other versions of this module by @fplandes .
We need to make sure the preprocessing we currently have in,
https://github.com/icubam/icubam/blob/16fb298269d0edd045a03bdcc002e77ba8c90662/icubam/predicu/data.py#L215-L218
is OK that nothing is missing.

The modeling team re-generated the plots and exported the data today. Everything looks OK.

Great, thanks for the confirmation!


[BUG] Exception during process_requests

I'm running the motion capture example without changing anything and it does capture the motion. However, after the 2nd motion capture, it just dies with an error.

Copy paste the code AS-IS to main.py
Run it as python main.py

Ideally, it should continue recording motion videos and continue to write it as output without dying.
[5:24:09.901470365] [975]  INFO Camera camera_manager.cpp:293 libcamera v0.0.1+54-d528119f
[5:24:10.049589460] [976]  INFO RPI raspberrypi.cpp:1414 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media3 and ISP device /dev/media0
[5:24:10.093262193] [975]  INFO Camera camera.cpp:1026 configuring streams: (0) 1280x720-RGB888 (1) 320x240-YUV420
[5:24:10.095656178] [976]  INFO RPI raspberrypi.cpp:800 Sensor: /base/soc/i2c0mux/i2c@1/ov5647@36 - Selected sensor format: 1920x1080-SGBRG10_1X10 - Selected unicam format: 1920x1080-pGAA
New Motion 7.809947916666666
New Motion 7.044270833333333
New Motion 7.252734375
Exception during process_requests()
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/picamera2/previews/null_preview.py", line 82, in handle_request
    completed_request = picam2.process_requests()
  File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 1135, in process_requests
    self._encoder.encode(stream, display_request)
  File "/usr/lib/python3/dist-packages/picamera2/encoders/v4l2_encoder.py", line 243, in encode
    fcntl.ioctl(self.vd, VIDIOC_QBUF, buf)
OSError: [Errno 22] Invalid argument
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/picamera2/previews/null_preview.py", line 30, in thread_func
    callback(picam2)
  File "/usr/lib/python3/dist-packages/picamera2/previews/null_preview.py", line 82, in handle_request
    completed_request = picam2.process_requests()
  File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 1135, in process_requests
    self._encoder.encode(stream, display_request)
  File "/usr/lib/python3/dist-packages/picamera2/encoders/v4l2_encoder.py", line 243, in encode
    fcntl.ioctl(self.vd, VIDIOC_QBUF, buf)
OSError: [Errno 22] Invalid argument
^CTraceback (most recent call last):
  File "/home/mohsin/cat-detector/main.py", line 27, in <module>
    cur = picam2.capture_buffer("lores")
  File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 1308, in capture_buffer
    return self._execute_or_dispatch(partial(self.capture_buffer_, name), wait, signal_function)
  File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 1212, in _execute_or_dispatch
    return self.wait()
  File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 1156, in wait
    result = self._future.result()
  File "/usr/lib/python3.9/concurrent/futures/_base.py", line 435, in result
    self._condition.wait(timeout)
  File "/usr/lib/python3.9/threading.py", line 312, in wait
    waiter.acquire()
KeyboardInterrupt

Hardware :

Raspberry Pi Zero W.
5MP Raspberry Pi Zero W Camera Module W/ HBV FFC Cable

Software :
Raspian Pi Lite OS (Bullseye)

Thanks for reporting this.  I've just been testing it, but on a pi4, and it seems to work ok here, so I'll see if I can find a pi zero w.
New Motion 21.4624609375
New Motion 92.37063802083334
New Motion 31.690390625
New Motion 77.86139322916667
New Motion 15.963138020833334
New Motion 16.356484375
New Motion 17.4552734375
New Motion 20.747747395833333
New Motion 15.736731770833334
New Motion 15.1761328125
New Motion 56.698919270833336
New Motion 95.7665625
New Motion<PHONE_NUMBER>7916666
New Motion 15.048619791666667
New Motion 69.22579427083333

Sorry for the delay, I've found a Pi Zero, just waiting for the camera cable adapter now.  Will hopefully have something to report early next week.

Sure, thanks. Appreciate it!

Just tested this using v 0.3.6 which I can replicate this issue in.  (I also used a pizero)
If you upgrade your picamera version, to get v 0.3.7, which was released today, I believe this should be fixed.

Great. Thank you!


Change the type of error value

Codecov Report

Merging #79 (314a2c6) into master (1304484) will decrease coverage by 0.71%.
The diff coverage is 56.06%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##           master      #79      +/-   ##
==========================================
- Coverage   76.43%   75.73%   -0.71%
==========================================
  Files          12       12
  Lines        1061     1059       -2
==========================================
- Hits          811      802       -9
- Misses        250      257       +7

Flag
Coverage Δ

unittests
75.73% <56.06%> (-0.71%)
:arrow_down:

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

Files
Coverage Δ

lib/exec.lua
94.11% <83.33%> (+0.56%)
:arrow_up:

lib/renderer.lua
97.22% <92.30%> (-1.20%)
:arrow_down:

lib/request.lua
64.70% <33.33%> (+2.44%)
:arrow_up:

lib/session.lua
96.91% <87.50%> (-0.13%)
:arrow_down:

lib/readcfg.lua
71.17% <57.14%> (-1.25%)
:arrow_down:

lib/response.lua
62.37% <4.76%> (-1.82%)
:arrow_down:

... and 2 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


blank() does not return errors for non-null components as suggested

I was struggling to get blank() to fail when a component had content. I eventually copied the exact code from the example but had it return content rather than null:
class NullFixture extends React.Component {
  render () {
    return (
hi
)
  }
}

The example tests do not fail (they pass):
const nullWrapper = mount(<NullFixture />) // mount/render/shallow when applicable

expect(nullWrapper).to.be.blank()
expect(nullWrapper).to.be.empty

Looks like this is a bug when the component is mounted (not when using shallow or render):
class NullFixture extends React.Component {
  render () {
    return (
hi
)
  }
}

const it = createTest(<NullFixture />)

describe('#blank', () => {
  describe('()', () => {
    it('passes negated when the actual does not match the expected', (wrapper) => {
      expect(wrapper).to.not.be.blank()
    })
  })
})

Results:
$ NODE_ENV=test npme mocha test/blank.test.js

  #blank
    ()
      ✓ (shallow): passes negated when the actual does not match the expected
      1) (mount): passes negated when the actual does not match the expected
      ✓ (render): passes negated when the actual does not match the expected

  2 passing (161ms)
  1 failing

  1) #blank () (mount): passes negated when the actual does not match the expected:
     AssertionError: expected <NullFixture /> not to be empty

     HTML:

hi

      at blank.test.js:12:33
      at Context.<anonymous> (createTest.js:20:7)
      at callFn (/Users/adc/Developer/producthunt/chai-enzyme/node_modules/mocha/lib/runnable.js:334:21)
      at Test.Runnable.run (/Users/adc/Developer/producthunt/chai-enzyme/node_modules/mocha/lib/runnable.js:327:7)
      at Runner.runTest (/Users/adc/Developer/producthunt/chai-enzyme/node_modules/mocha/lib/runner.js:428:10)
      at /Users/adc/Developer/producthunt/chai-enzyme/node_modules/mocha/lib/runner.js:534:12
      at next (/Users/adc/Developer/producthunt/chai-enzyme/node_modules/mocha/lib/runner.js:348:14)
      at /Users/adc/Developer/producthunt/chai-enzyme/node_modules/mocha/lib/runner.js:358:7
      at next (/Users/adc/Developer/producthunt/chai-enzyme/node_modules/mocha/lib/runner.js:284:14)
      at Immediate.<anonymous> (/Users/adc/Developer/producthunt/chai-enzyme/node_modules/mocha/lib/runner.js:326:5)
      at runCallback (timers.js:574:20)
      at tryOnImmediate (timers.js:554:5)
      at processImmediate [as _immediateCallback] (timers.js:533:5)

The problem still exists, now in shallow and render, in case of non-empty component:
class NullFixture extends React.Component {
  render () {
    return (<AnotherNullFixture/>)
  }
}

class AnotherNullFixture extends React.Component {
  render () {
    return (
text
)
  }
}

it = createTest(<NullFixture />)

describe.only('#blank', () => {
  describe('(non-empty component)', () => {
    it('passes when the actual matches the expected', (wrapper) => {
      expect(wrapper).to.not.be.blank()
    })

    // it('fails when the actual does not match the expected', (wrapper) => {
    //   expect(() => {
    //     expect(wrapper).to.be.blank()
    //   }).to.throw()
    // })
  })
})

Results:
NODE_ENV=test npx mocha test/blank.test.js

  #blank
    (non-empty component)
      1) (shallow): passes when the actual matches the expected
      ✓ (mount): passes when the actual matches the expected
      2) (render): passes when the actual matches the expected

  1 passing (365ms)
  2 failing

  1) #blank (non-empty component) (shallow): passes when the actual matches the expected:
     AssertionError: expected <NullFixture /> not to be empty

     HTML:

text

      at /Users/user/Documents/_prj/chai-enzyme/test/blank.test.js:60:33
      at Context.<anonymous> (/Users/user/Documents/_prj/chai-enzyme/test/support/createTest.js:14:7)
      at callFn (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runnable.js:348:21)
      at Test.Runnable.run (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runnable.js:340:7)
      at Runner.runTest (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:443:10)
      at /Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:549:12
      at next (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:361:14)
      at /Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:371:7
      at next (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:295:14)
      at Immediate.<anonymous> (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:339:5)
      at runCallback (timers.js:789:20)
      at tryOnImmediate (timers.js:751:5)
      at processImmediate [as _immediateCallback] (timers.js:722:5)

  2) #blank (non-empty component) (render): passes when the actual matches the expected:
     AssertionError: expected the node in <??? /> not to be empty

     HTML:

text

      at /Users/user/Documents/_prj/chai-enzyme/test/blank.test.js:60:33
      at Context.<anonymous> (/Users/user/Documents/_prj/chai-enzyme/test/support/createTest.js:26:7)
      at callFn (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runnable.js:348:21)
      at Test.Runnable.run (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runnable.js:340:7)
      at Runner.runTest (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:443:10)
      at /Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:549:12
      at next (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:361:14)
      at /Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:371:7
      at next (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:295:14)
      at Immediate.<anonymous> (/Users/user/Documents/_prj/chai-enzyme/node_modules/mocha/lib/runner.js:339:5)
      at runCallback (timers.js:789:20)
      at tryOnImmediate (timers.js:751:5)
      at processImmediate [as _immediateCallback] (timers.js:722:5)

It seems not correct to check children in these cases in isEmpty, why not use exists from enzyme, which is the replacement for the deprecated method isEmpty?


Add Texas cities to defund12

Please add Austin, Dallas/Ft Worth, San Antonio, Houston, and El Paso

Thank you for opening this request!

San Antonia template proposed in #226

DUE TO HIGH VOLUME EMPTY ISSUES, OR ISSUES MISSING THE FOLLOWING INFORMATION WILL BE IMMEDIATELY CLOSED. THANK YOU!

A subject message for the email
A list of emails (at least one) for the government officials you’d like to receive the message
A detailed message concerning the budgeting decisions that are at stake in your community
Please read more about our email style guidelines here.

If this information is copied from an external source please provide a link to the original source.
See our current links for examples at https://defund12.org.
Thank you!!


Update Gerty extension to 0.1.3

Will create branch for the typo commit to avoid merging onto main


404 Error after ILMerge

Hello,
I have a strange behaviour after merged the Nancy DLLs to my .exe file. The Nancy instance is self-hosting and the sshtml are embedded to the .exe file.
Nancy is working like a charm before I ILMerge the DLLs to .exe - After merging I get a 404 error.
My CustomBootstrapper:
        protected override NancyInternalConfiguration InternalConfiguration
        {
            get
            {
                return NancyInternalConfiguration.WithOverrides(OnConfigurationBuilder);
            }
        }

        void OnConfigurationBuilder(NancyInternalConfiguration x)
        {
            x.ViewLocationProvider = typeof(ResourceViewLocationProvider);
        }

        protected override void ConfigureApplicationContainer(TinyIoCContainer container)
        {
            Assembly assembly = Assembly.GetExecutingAssembly();
            string[] assemblyNames = assembly.GetManifestResourceNames();

            base.ConfigureApplicationContainer(container);
            ResourceViewLocationProvider.RootNamespaces.Add(
              Assembly.GetAssembly(typeof(MainModule)), "FrontEnd.Webinterface.Views");
        }

Any ideas for this problem or any approach how to troubleshoot it? Thanks!

We have never really made any conscious design decisions to ensure that Nancy functions well after having being subjected to ILMerged (or other similar tools). The fact that you get a 404 seems to indicate that Nancy is, at least, being hit but that the route resolution fails. My guess is that it is the default module scanning strategy that is causing the problem. You do not say what version of Nancy you are using, so I am going to assume that you are on the 1.x-releases, not that it matters that much since the concept is the same in 2.0-alpha
If you have a look at NancyBootstrapperBase.Modules you can see that Nancy scans for all INancyModule with ScanMode.ExcludeNancy. When using ExcludeNancy all types that are in the Nancy assembly are going to be ignored. The way it does that is by excluding all types that are in the assembly that is identified by typeof(INancyEngine).Assembly.  Normally when you run Nancy independently this is not a problem, however when you have merged it into anothe assembly, it will end up being the same assembly as the rest of your code.
I'm guessing you could override the Modules property and provider your own filter, or just explicitly list the names of your modules in there and it should be able to work
Hope this helps!

Thanks for your support! I did it like this:
        protected override IEnumerable<ModuleRegistration> Modules
        {
            get
            {
                return

                    AppDomainAssemblyTypeScanner
                        .TypesOf<INancyModule>(ScanMode.ExcludeNancy)
                        .NotOfType<DiagnosticModule>()
                        .Select(t => new ModuleRegistration(t))
                        .ToArray();
            }
        }


Rerender with latest conda smithy and conda-forge-pinning

I'm having some issues with this package on Windows for the GMT builds conda-forge/gmt-feedstock#71 and thought it might be related to outdated builds of FFTW. I thought it wouldn't hurt to have a newer build with a rerendered feedstock.

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

LGTM. Thanks @leouieda!

Unfortunately I don't think this will help you with the issues you encountered in conda-forge/gmt-feedstock#71 because it seems to be looking for an MPI-based build on Windows. The fairly recent PR #52 added MPI support, but this was for OS X and Linux only.
The builds for Windows are a lot different (they are CMAKE-based, which is less well supported by FFTW) and I'm not sure how much work would be involved to get MPI working there.

Yeah, I thought so. The problem is that we're not asking for MPI and it wasn't failing a couple of weeks ago.


Always wait for dotfile stream before renaming

Should fix the infamous Error: EPERM, rename error. If this works, I'll add another commit writing the temporary dotfile in the tmp directory instead of in the output file's directory. I'm not doing that now because I want to isolate the true fix of the EPERM error.

UGH failed tests... old steams -_-

@zertosh I tested this PR, and it works great!
Except for one little thing. After an error logs, it also logs out an incorrect number of bytes written to the file. (In verbose mode, -v.)
C:\Users\Michael\Github\javascript\state-router-example>watchify implementations\virtualdom\index.js -d -v -o implementations\virtualdom\bundle.js
473839 bytes written to implementations\virtualdom\bundle.js (2.04 seconds)
473839 bytes written to implementations\virtualdom\bundle.js (0.45 seconds)
Error: Parsing file C:\Users\Michael\Github\javascript\state-router-example\implementations\virtualdom\index.js: Unexpected token (8:33)
473839 bytes written to implementations\virtualdom\bundle.js (0.45 seconds)

At this point, bundle.js is:
console.error("Error: Parsing file C:\\Users\\Michael\\Github\\javascript\\state-router-example\\implementations\\virtualdom\\index.js: Unexpected token (8:33)");

@ArtskydJ Oh yeah it's using the old values of bytes and time - I'll fix that. I'm stuck trying to figure out how old node 0.8.x streams work since that's causing the tests to fail.

Not "old" - more like the last "success" values

It used to only log the error. Perhaps this could be implemented by doing: bytes = 0; here, and doing: if (verbose && bytes) { here.
Unfortunately it's slightly hacky.

A lot of people support the current and the previous stable version of node. Right now, that's 0.12 and 0.10, so maybe 0.8 could be dropped? This is a matter of opinion. (I have no idea how many people still use 0.8.)

@ArtskydJ I have no idea either - but I figured the problem so I'll just let it be. For the bytes count I was thinking of:
        var body = 'console.error('+JSON.stringify(String(err))+');';
        bytes = body.length;
        time = 0;
        dotStream.end(body);

but that's so ugly :cry:

Green build :smile:

If a build errors, I don't really care how long it took, or how many bytes were written, but maybe that's just me. :smiley:

lol fair enough - but you gotta keep it consistent. I just ran a quick test in node 0.12.1, and the tests hang randomly - but when I bump chokidar to 1.0.0-rc4, they run just fine. I'll add that version and maybe iojs to the travis.yml in 3.0.0.

@ArtskydJ once I get a few more confirmations that this fix works I'll do a release - so hopefully tmw

@zertosh I don't know if it matters, but the log output changes with this PR.
It used to log either an error, or this message: "x bytes written to y.js (z seconds)"
Now if there is an error, it still logs the message.
What I get:
watchify files\main.js -v -o bundle.js
788 bytes written to bundle.js (0.10 seconds)
Error: Parsing file C:\Users\Michael\Github\javascript\watchify\example\files\main.js: Unexpected token (2:18)
136 bytes written to bundle.js (0.00 seconds)

What I expect:
watchify files\main.js -v -o bundle.js
788 bytes written to bundle.js (0.10 seconds)
Error: Parsing file C:\Users\Michael\Github\javascript\watchify\example\files\main.js: Unexpected token (2:18)

Other than that, everything works great! Again, I don't know if it matters. I just thought I'd let you know.
Thanks for figuring this out!

@ArtskydJ You're right, the message and the error were mutually exclusive. I'll fix that and do the release.

@zertosh Awesome!

Published as<EMAIL_ADDRESS>

Seems to be working fine here.


Add primitive classification and browsing

The primitives should be able to define a type and a subtype, and a tool should exist that allows the user to get the list of available primitives filtering by these values.

This has already been covered in HDI-Project/MLBlocks/issues/90


Fix bug in link container logic

While i tried to link container to another running container i got the exception:
Aborting attempt to link to container  as it is not running.
The  provided in the exception was a different name than the real container name.
When i debugged this, i saw that for decide if the container is running (so it can be linked),
You used in GenericContainer.java:
boolean linkableContainerIsRunning = dockerClient.listContainersCmd().exec().stream()
.filter(container -> container.getNames()[0].endsWith(linkableContainer.getContainerName()))
container.getNames()[0] returned different name than the real container name. this is the bug, and due to that the exception was thrown.
in order to fix this bug i used:
dockerClient.inspectContainerCmd(container.getId()).exec().getName() in order to retrieve the real container name instead of using the container.getNames()[0].

@bsideup Can we continue the discussion?

@asafm yes :) I think we also need @rnorth here :)

Sorry for not commenting sooner :(
I think I'd like to avoid the performance overhead of the current implementation; it does feel as though invoking inspect on every container (even when linking is not required) will be a performance issue for somebody (e.g. with a remote docker daemon, which can be done).
Are we sure we know why container.getNames()[0] is giving the wrong value yet? Could it be something as simple as the container having multiple names, and the selection of the first entry being too naive? Sorry for this inconclusive suggestion, but if you could show how container.getNames() is differing from the names returned by inspect, there might be something else we could do.
Also, looking through the API documentation and docker-java source, it actually looks like the API inspect endpoint accepts id or name as its parameter, since at least API v1.18. This was surprising to me, but naming ugliness aside it looks like using the container name as the ID for the docker-java inspect command might work - if we can give an exact name.

@eranshahar @asafm How do you want to proceed with this?

Eran is researching Docker to figure out why the name of a linked container
changes in flight, and also why inspect returns an array of names instead
of a single String.
On Sun, 9 Apr 2017 at 9:10 Richard North<EMAIL_ADDRESS>wrote:

@eranshahar https://github.com/eranshahar @asafm
https://github.com/asafm How do you want to proceed with this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/testcontainers/testcontainers-java/pull/314#issuecomment-292766583,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA8Y8T7U8ZAN5gHNI0iA-mWk0SY1ejUDks5ruHY8gaJpZM4MdxVf
.

@bsideup @rnorth - It was quite hard for us to reconstruct the bug. I ended up ditching using Linked Containers all together for using Network and Network alias (using the hooks we have for modifying the CreateContainerCmd). The latter reaches the same effect: the /etc/hosts file ends up containing a line per each container with the network alias you give and its internal IP.

Using Docker networks seems to be the more correct way to do this after all. Maybe you can share an example and we can add it to documentation?


Custom TestMethodAttribute breaks TestInitialize

Looks like when I use a custom TestMethodAttribute that the original TestInitializeAttribute no longer functions. Even if all my custom one does is call base.Execute. Is this intended? If so, how do I ... not do that?

@wasabii
Can you elaborate the issue? In addition, can you share a sample repro project with us?

@wasabii Any updates here?

Can't seem to reproduce it. Will open if I can.


Add escape sequences for special characters in docstrings

Cargo will fail to generate documentation if [ and [ are not
escaped in docstrings. Therefore an additional transformation
for escape sequences is done before the docstring is written to file.

Hi @all,
I started to write a patch for the Issue I have reported. Would be great if somebody could provide feedback in general and also about:

Are all spots where this should be applied (fixed) identified? see ticket
Would the approach which I used for the single location valid to use for the other spots
-> or do you have a better idea on how to fix it in general?
Is the issue and the fix legit? -> Please let me know then I will proceed fixing the other locations

Meh, I just noticed that I accidentally re-created a solution for this, although in a slightly different way. 😞

@therealprof no worries, feel free to discard/reject/close this PR then.

this is already fixed by https://github.com/rust-embedded/svd2rust/pull/240


trailing-comma option for object literal with one key, but written over multiple lines

The option singleline: always/never seems to treat these two both as singleline:
let foo = {foo: 'bar'}

let foo = {
  foo: 'bar',
}

As I love this rule for keeping my code properly formatted for (irrelevant) conflict free merges I would really appreciate if I can distinguish between the two.
As the first one doesn't need a trailing comma, but the second one does.
(or am I missing something? :) )

I updated your comment to what I believe was your intended formatting. Let me know if this was wrong.
Looks like a duplicate of #856

Indeed! You we're right with the formatting, and right about this issue being a duplicate. Sorry I didn't find that one my self :)


21.1.0: Trim RT and Trial Number Updates

Updates include:
Load ace bulk now creates trial_number column if it does not exist (primarily classroom data) and orders trial according to trial_number
Trim_rt function split into two separate functions and allow modules to be excluded
Post clean chance updated to include app argument to account for change in TaskSwitch design between classroom and explorer builds

Updated PR title to include version number for easier reference. should be good to go bc this has been tested!


K3s infra tests

Hi @vandot , could you please add the PR description?

Hi @vandot , could you please add the PR description?


Migrate doppio version information into doppio.js

Currently, tools\render.coffee will dynamically invoke git to determine the revision responsible for the given demo page, and will paste it directly into the mustache template.
Instead, it would be better to include this on the public-facing doppio API so that templates can retrieve it from that at runtime. This would also further decouple demo building from building doppio.js.

No longer required. We'll transition to proper versioning with the next release, like BrowserFS and our JCL repository.