Adding the deps/src directory to gitignore

Not including the /deps/src directory in gitignore makes the local copy dirty after the build process.  This causes problems with packaging systems e.g. DeclarativePackages.jl

Coverage remained the same at 82.927% when pulling c4d637d72cc5c3f3180eb12d7f602633e74ab0cf on FugroRoames:GitIgnoreUpdate into 7e8ffd284a3c5aced070c1c3b45a4a0be32dea2f on JuliaWeb:master.

Coverage remained the same at 82.927% when pulling c4d637d72cc5c3f3180eb12d7f602633e74ab0cf on FugroRoames:GitIgnoreUpdate into 7e8ffd284a3c5aced070c1c3b45a4a0be32dea2f on JuliaWeb:master.

I think the failures on Julia nightly builds is outside the scope of the PR

It's not exactly dirty since that directory isn't checked in, right? Just has untracked files.

Coverage remained the same at 82.927% when pulling 856fbffa47cf38b271c8cdd7ac5f56610c1824da on FugroRoames:GitIgnoreUpdate into 7e8ffd284a3c5aced070c1c3b45a4a0be32dea2f on JuliaWeb:master.

Coverage remained the same at 82.927% when pulling 856fbffa47cf38b271c8cdd7ac5f56610c1824da on FugroRoames:GitIgnoreUpdate into 7e8ffd284a3c5aced070c1c3b45a4a0be32dea2f on JuliaWeb:master.

@tkelman You're right - this isn't the issue so I'll kill this PR

This PR's still a good idea, whether or not it fixes whatever you're hitting

Well that's good then

Looking more into this,  the DeclarativePackages.jl I'm using doesn't distinguish between a dirty local repo and a local repo with untracked files.  I've editted the top comment to indicate this PR fixes untracked files instead.


Not recieving notifications

This is  a bug.

Prerequisites

[x] Are you running the latest version?
[ ] Are you reporting to the correct repository? I'm not sure about this one :frowning_face:
[x] Did you check the documentation?
[x] Did you perform a cursory search?

Description
I'm using laravel-websockets instead of pusher to broadcast notifications. Currently i'm only using the CommentTagNotification from the CommentsManager. The comments manager creates the notification with 'notifiable_type' field set to LaravelEnso\Core\Models\User. I assume this is because that is the actual user model it users to create the notification. But when i actually fetch the notifications(from a cloned Enso repository), I am using the Enso\App\User model so no notifications are received. I have been able to fix this by removing App\User and only using LaravelEnso\Core\Models\User in my app but this seem's substandard in case in the future i need to modify App\User.
Steps to Reproduce

Clone Enso repository
install laravel websockets following guide
Change the Laravel Echo code too point to websocket server instead of pusher
Do something that sends a notification. I am testing with the CommentTagNotification from LaravelEnso\CommentsManager

Expected behavior
This should just work like it does when using pusher
Actual behavior
No notifications are recieved upon checking the database i see that 'notifiable_type' is set to 'LaravelEnso\Core\Models\User'. Using laravel debugbar i notice that the query where using to get the notifications is:
select * from `notifications` where `notifications`.`notifiable_id` = 1 and `notifications`.`notifiable_id` is not null and `notifications`.`notifiable_type` = 'App\User' order by `created_at` desc limit 200 offset 0

If I use LaravelEnso\Core\Models\User in my app instead of App\User everything works as expected.
I'd like to submit a PR to help out with this but i'm fairly new to laravel and im not sure what the best way to fix it would be.

It has nothing to do with websockets.
You shouldn't have to use in your local app the core User. The tagging functionality is contained into the commentsManager package. The package only knows how to work with the core User, and that's ok. Whenever a notification is pushed for the core user the apps user will received it as well.
Could you provide the code and context that you are using for getting the comment tag notifications?

Sure thing upon looking though my git log it seems i made less changes then i though.
The only relevent change is in config/broadcasting.php i added the 'host', 'port' and 'schema' to the pusher config
    'connections' => [
        'pusher' => [
            'driver' => 'pusher',
            'key' => env('PUSHER_APP_KEY'),
            'secret' => env('PUSHER_APP_SECRET'),
            'app_id' => env('PUSHER_APP_ID'),
            'options' => [
              'cluster' => env('PUSHER_APP_CLUSTER'),
              'encrypted' => true,
              'host' => '<IP_ADDRESS>',
              'port' => 6001,
              'schema' => 'http'
            ],
        ],

I mispoke didn't actually have to change the laravel echo code. Both the 'initEcho' functions of resources/js/core/structure/navbar/IO.vue and resources/js/core/structure/navbar/IO.vue are unchanged. Here is there current form
        initEcho() {
            this.echo = new Echo({
                broadcaster: 'pusher',
                key: this.meta.pusher,
                cluster: this.meta.pusherCluster,
                namespace: 'App.Events',
            });
        },

After doing this i am unable to recieve notifications. They appear in the database but it always shows as no notifications in the navbar as well as in the Notifications index page.
I changed these files to use Core\Models\User instead of App\User.
config/auth.php
        'users' => [
            'driver' => 'eloquent',
            // TODO: change this back to App\User after speaking to the laravel enso people.
            'model' => LaravelEnso\Core\app\Models\User::class,
        ],

config/services.php
        // TODO: change this back to App\User after speaking with the laravel enso people.
        'model' => LaravelEnso\Core\Models\app\User::class,
        'key' => env('STRIPE_KEY'),
        'secret' => env('STRIPE_SECRET'),

app\Http\Controllers\Auth\RegisterController.php & app\Http\Controllors\Dashboard\UserStatController.php I simply imported LaravelEnso\Core\Models\User instead of App\User

After reading laravel documentation all morning i was able to find a better work around for this.
Reverting the changes above and adding this to AppServiceProvider is a much better solution.
        Relation::morphMap([
          'LaravelEnso\Core\app\Models\User' => 'App\User'
        ]);

But the problem still remains if i don't use morphMap. I do not recieve any notifications.

Great discovery @bytebuddha, that line might help with certain edge-cases I've been having to deal with :)
I'm using laravel-websockets myself but haven't had time to debug what you're experiencing (I don't use CommentTagNotification at this time).
@aocneanu Might be good to add that snippet to the introduction guide and/or default Enso bundle (this repo) to improve the onboarding experience.

I renamed this since aocneanu poointed out laravel-websocket is working as expected.

I’m sorry for causing a confusion :) I’m not 100% positive that websockets are working, because we’re using pusher and I don’t have the setup to test it. Ibelieve that @jlsjonas does.
I only wanted to point out that the relationship issue is not related to the websockets provider.

@aocneanu I can confirm websockets are working fine (for me atleast). I was confused thinking the notification's in the Header were being sent through them, but as you pointed out they are not.

The package only knows how to work with the core User, and that's ok. Whenever a notification is pushed for the core user the apps user will received it as well.

Can i ask how this is possible? When laravel-enso/Notification's sends a notifications it set 'notifiable_type' equal to 'LaravelEnso\Core\Models\User' and when laravel-enso\Enso searches for notifications with notifiable_type 'App\User'. How can this work? Maybe i'm missing something?

Wow @bytebuddha,
So sorry, I just got my head around what you were saying from the very beginning. I was really reading between the lines, but thank you for being persevering :)
It seems that 6 months ago when we entered the people structure I was careless on the refactor and instead of using config('auth.providers.users.model') I changed to the core's user.
Fixed now.

instead of using config('auth.providers.users.model') I changed to the core's user.
We should check the entire framework for this as I'm pretty sure this also occurs in other places,
a quick search gave me Avatar, Role & Login Models being directly tied to the core's user. Although they should have less of an impact in theory.


fix(login): improved validation ui and marked username/password fields as required

Fixes #2182 and #2183 .
Changes proposed in this pull request:

Marked username and password fields as required.
Shows banner with error message when username or password is not provided.
Shows banner with error message when wrong credentials are provided.

Thanks for the PR. I tried the enhancements that you reported, but only two work:

Marked username and password fields as required.
Shows banner with error message when username or password is not provided.

I can’t view any error with wrong credentials

Yes it doesn't seem to work in the live preview but it works locally (after setting everything up according to CONTRIBUTING.md). From what I can see in the network tab in chrome devtools the live preview doesn't connect to the CouchDB instance which, if it doesn't, is the reason why the last enhancement doesn't work in the live preview. When testing it locally I see a request to http://localhost:5984/_session (CouchDB instance) when signing in with both the username and password fields filled in. If the live preview actually is connected to a CouchDB instance I'll take a deeper look of what the problem could be.

Thanks for the feedback!

it appears that when I enter invalid credentials, I never see the invalid credential message. (chrome v83.0.4103.116).

Did you test it in the live preview when you weren't able to see the invalid credentials message? If so then the issue may be what I described above:

Yes it doesn't seem to work in the live preview but it works locally (after setting everything up according to CONTRIBUTING.md). From what I can see in the network tab in chrome devtools the live preview doesn't connect to the CouchDB instance which, if it doesn't, is the reason why the last enhancement doesn't work in the live preview. When testing it locally I see a request to http://localhost:5984/_session (CouchDB instance) when signing in with both the username and password fields filled in. If the live preview actually is connected to a CouchDB instance I'll take a deeper look of what the problem could be.


send the initial number of bins set in the viz.json

cc @abelvm

Some parameters need a fixed number of bins, set in config.
Typical: 24h in a day, 7 days in a week, 12 months in a year,...

see also: https://github.com/CartoDB/Windshaft/issues/414

This solves, partially, #71.

Solved in https://github.com/CartoDB/Windshaft/issues/414

Hey, @javisantana made me a proposal about changing the behaviour so we don't need to configure the number of bins but we can send a bins when doing the histogram request.
So if you don't send anything it will calculate bins and start+end, if you send bins it will calculate for you the start+end, and if you send bins and start+end will use all provided values.
What do you think @acanimal? Going with that approach means that we need to change deep-insights.

Sound good for me and think it will be transparent for DI.
As a summary, the current issue is because you can configure in dijson a widget with 10 bins. The initial request looks like server_address?bins=10 but the number is ignored and data with, for example, 48 bins is returned. Then that number of bins is set on the widget and all subsequent request passes that value.

@acanimal I did the required changes in https://github.com/CartoDB/Windshaft/pull/433, can you verify that deep-insights still has the expected behaviour with latest windshaft master branch.

Sorry, I can't verify with master, but they should be transparent for DI. DI simply stores the bucket number returned by the server. If now they are the same than the requested that would be fine.

Why you cannot verify it with master?

@acanimal could you test this locally please? we have a bunch of tickets related to bins we should close

As we talk the change is transparent for DI. Now the histogram is drawn with the specified number of bins in the diJSON:

Does it works with latest DI as is? Which params do I need to set up in the
json?
El 18 feb. 2016 10:26, "acanimal"<EMAIL_ADDRESS>escribió:

As we talk the change is transparent for DI. Now the histogram is drawn
with the specified number of bins in the diJSON:
[image: screen shot 2016-02-18 at 10 25 09]
https://cloud.githubusercontent.com/assets/732033/13138902/0001dfaa-d62a-11e5-8412-8dd3c2819b40.png
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/deep-insights.js/issues/164#issuecomment-185623785
.

@AbelVM You need to wait until a new windshaft deployment. For DI is transparent simply set the bins number on the diJSON.

No need for extra params as start, end...?
El 18 feb. 2016 10:29, "acanimal"<EMAIL_ADDRESS>escribió:

@AbelVM https://github.com/AbelVM You need to wait until a new
windshaft deployment. For DI is transparent simply set the bins number on
the diJSON.
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/deep-insights.js/issues/164#issuecomment-185625157
.

No for the moment, only bins are taking into account.
@rochoa are you workin on https://github.com/CartoDB/deep-insights.js/issues/164#issuecomment-184658816 ?

What is your question? I don't understand it. The changes proposed https://github.com/CartoDB/deep-insights.js/issues/164#issuecomment-184658816 were implemented as per https://github.com/CartoDB/deep-insights.js/issues/164#issuecomment-185141322. I just wanted to know if that was working with DI so we can release windshaft with those changes.
I think @AbelVM is asking if it's possible to fix the number of bins, start, and end at DI level. Windshaft supports all of them right now, but I don't know how they are exposed in DI, and if it's possible to use them right now.

I though you simply work to use bins in the first call, not on the rest of proposal.
As I said here (https://github.com/CartoDB/deep-insights.js/issues/164#issuecomment-185623785) that works fine and created a new issue to implement the new properties: https://github.com/CartoDB/deep-insights.js/issues/209. Now I now they are implemented on windshaft I start working allow use them on DI.


Release tagging

Tags should have vX.Y.Z format, not X.Y.Z (only 0.1.0 is this way - GitHub's own UI gives this recommendation), and a GitHub release should always be made when tagging, so it shows up in the UI. @mayou36, perhaps you can can fix?

Indeed, that was an oversight. I'll do a v0.1.1 release to have it proper, okay?

That's fine, though you could also tag v0.1.0 to match 0.1.0.

Doesn't that may interfere with PyPI? The upload should fail surely

Released, https://github.com/scikit-hep/formulate/releases/tag/v0.1.1, thanks for spotting this!


mac直接执行 python3 app.py -t index 出错

objc[3871]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
objc[3871]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

不是在docker中

Please refer to https://docs.jina.ai/chapters/troubleshooting.html#objc-15934-nsplaceholderdictionary-initialize-may-have-been-in-progress-in-another-thread-when-fork-was-called

This error is due to the limit of threads in OS X. Please find more details in the docs.

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES


Remove usages of .Tag on ComboBox theme

[ ] ComboBox theme (ComboBoxItem.Tag)
[ ] Also, TreeView theme, but lower priority as on more of a hidden element.

Should remove this as we are blocking people from using .Tag for their own purposes, and replace with an attached property.
Either:

Add

ComboBoxAssist.HideItem : bool
TreeViewAssist.HeightFactor : double

Or a single MaterialDesign.FrameworkTag : object

I think I prefer the former, more verbose option, even though it creates more classes...

But treeview is using of inner scrollviewer's tag, that is not a part of open properties.
I mean template doesn't use TreeViewItem.Tag.

Sorry, my mistake...
But did you see https://github.com/ButchersBoy/MaterialDesignInXamlToolkit/issues/159 ?

@ButchersBoy yes, i will fix it in a few days

Cool, thanks, I'll mark as in progress and leave to you.


UX weakness with "remember me" leading to unnecessary forgotten logins

There are a couple of issues with the "remember me" function that lead to it giving the appearance of being unreliable. This probably has flow-on issues such as resistance to rolling out MFA as it relies on this function for a good UX.
In my view, the first scenario has the higher impact, but that's a bit subjective.
Scenario 1
Steps:

Log in from Safari, tick remember me
Close and restart Safari, verify that login has been remembered
Log in from Chrome, do not tick remember me
Close and restart Safari

Expected:

Login has been remembered

Actual

Login on Safari has been forgotten

Explanation
I believe that when the "remember me" box is not checked, it is clearing out any ALC token from all devices. It would make sense to clear out the ALC from this device, but not other devices.
From my perspective, this is a bug, without any security implications.
Scenario 2
Steps:

Log in from Safari, tick remember me
Close and restart Safari, verify that login has been remembered
Log in from Chrome, tick remember me
Close and restart Safari, verify that login has been remembered
Explicitly log out from Chrome
Reload Safari, verify that it hasn't been logged out
Close and restart Safari

Expected:

Login has been remembered

Actual

Login on Safari has been forgotten

Explanation
The "log out" functionality is hard-coded to perform "log out from all devices". This has some security benefit but doesn't make a lot of sense as a default.
From my perspective, this is a bug, but it does have some security implications. Ideally, the log out action (at least in the CMS) would pop up a box with a "log out from all devices" checkbox, defaulting to unchecked.
ACs

[ ] A technical risk assessment is performed assuming the below is implemented
[ ] Neglecting to check the remember me checkbox in one browser does not remove settings for other browsers
[ ] By default, logging out of one browser session does not invalidate other browser sessions (currently managed in the true/false configuration value)
[ ] Review existing documentation and any changes required based on this fix
[ ] Changelog notes this as a bug, not a feature change

Notes

This fix should be tested with the silverstripe/session-manager module - we'll cover that in a separate issues

Regarding scenario 2, one of the options we are investigating is device management in the users profile. The "log out from all devices" is a good solution that I'll add to our list of possibilities, it doesn't let the user know which devices or how many devices have tokens.

Regarding scenario 2, one of the options we are investigating is device management in the users profile.

Yeah that would be a more complete solution, I agree.

Code which is probably leading to everyone getting logged out:

https://github.com/silverstripe/silverstripe-framework/blob/4/src/Security/MemberAuthenticator/CookieAuthenticationHandler.php#L251
https://github.com/silverstripe/silverstripe-framework/blob/4/src/Security/RememberLoginHash.php#L183
https://github.com/silverstripe/silverstripe-framework/blob/4/src/Security/RememberLoginHash.php#L55 << default value of true

Replicating
I tried replicating both scenario with Chromium and Edge:

Could NOT replicate scenario 1.
Replicated scenario 2

How the "Remember me" feature works
Key classes

CookieAuthenticationHandler handles the authentication of the Member and the creation of cookies on the user's device.
RememberLoginHash is a DataObject that link up the DeviceID, the Remember me Hash and the Member. When the user come back without a session, CookieAuthenticationHandler links back those 3 piece of data to let the user back in.

The "Remember me" workflows
New login
This behaviour is triggered when a user logins and checks the "remember me" option.

CookieAuthenticationHandler::logIn() is called
We check if there's any pre-existing device cookie for this request and clear any matching RememberLoginHash. *
If the user has requested a "persistent" session:

RememberLoginHash::generate() is called for the provided $member. This automatically generates a device ID (sha1 hash)   and a member token (sha1 hash, stored encrypted with the Member's Salt). An expiry date is also set. **

If RememberLoginHash::force_single_token' is set to true, any other RememberLoginHash` for this user well be deleted (default is false)

Two cookies are set: ***

The token cookie which contains the member ID and the RememberLoginHash token UNencryted (TTL defined by RememberLoginHash::$token_expiry_days, defaults to 90 days)
The device cookie which contains the RememberLoginHash device ID (TTL defined by RememberLoginHash::$device_expiry_days, defaults to 365 days)

* You can't have multiple "remember me" session on the same device
** Encrypting the member hash with the Member's Salt will invalidate the "remember me" hash when the user changes their password. Encryption is done via $member->encryptWithUserSettings().
*** These 2 cookies are unrelated to PHPSESSID which contains the ID for the current session and is only valid for the duration of the browser session.
Starting a new session
This workflow is triggered when a user returns to the site after having logged in with the "remember me" option, but having close their browser, therefore invalidating their session.

CookieAuthenticationHandler::authenticateRequest() is called with the HTTPRequest
We try reading a token cookie and a device cookie. If any of those check failed, we return null:

Both cookies are provided
We try fetching an existing user matching the member ID in the Token cookie.
We use the Member's Salt to hash the unencrypted token in the cookie.
We look for a RememberLoginHash matching the hash, the device id cookie and the member ID
We check that the RememberLoginHash is not expired.

We call the logIn function on the Identity store provided by CookieAuthenticationHandler::CascadeInTo
We call RememberLoginHash::renew()

This generates a new token for the member. Again, that token is hashed with the member's Salt.
The expiry date and device ID remain the same.
RememberLoginHash is written to the DB with the new token hash *

We set a new Token Cookie in the user's browser with the new unencrypted token. The TTL for this cookie is reset to RememberLoginHash::$token_expiry_days.

* The purpose of this step is to make sure you can't reuse the same token cookie multiple times
** The cookie time TTL seemed a bit weird here. The token cookie TTL gets extended after each new session, so it will live past the RememberLoginHash expiry date. The device ID cookie never gets extended, but its TTL is 365 days vs RememberLoginHash's 90 days, so this cookie will also outlive RememberLoginHash. The key thing, is that the expiry date on RememberLoginHash never changes. So no matter what, it will eventually expire even if the cookies are still in the user's browser.
Logout

CookieAuthenticationHandler::logIn() is called.
We try to find the current device ID cookie
We call RememberLoginHash::clear() with the current member and the device ID.

If RememberLoginHash::$logout_across_devices is false and a device ID was provided *

We delete all RememberLoginHash object for the provided member and device ID.

Otherwise,

We delete all RememberLoginHash object the current member

We clear any token cookieor device ID cookie in the user browser.

* I didn't try this, but I get the impression this logic is buggy. If logout_across_devices is false and you try to logout from a non-persistent device, you won't have any device ID cookie, which will cause all your RememberLoginHash to be deleted.

@clarkepaul Could use some feedback on this.
Possible approach to fix this
Minimal fix
We could:

Change the default value RememberLoginHash::$logout_across_devices to false
Fix that ambiguity in RememberLoginHash::clear() so that nothing happens if no device ID is provided.

In that scenario, there's no way to invalidate a "Remember me" cookie on a lost device, short of changing your password.
Minimal fix + add a UI switch to "log out across all devices"
Basically this would give the option to user to explicitly clear all their RememberLoginHash objects
Minimal fix + give users a Gridfield to manage their RememberLoginHash
That's probably a very bad idea. It would allow users to delete specific remembered device. However, the only identifier we have for those device is a very unfriendly sha1 hash.
Plus it would duplicate a the logic currently  being implemented in session manager.
Do mostly nothing
If we're serious about making session-manager a supported module and shipping it in our default recipe, then maybe doing nothing here is the best approach long term.
Session manager sounds like a better place to have a "logout everywhere" feature. It would also allow you to invalidate individual session directly.
So we could do this:

Fix that ambiguity in RememberLoginHash::clear()
Keep the current RememberLoginHash::$logout_across_devices default
Recommend that people who are unhappy with the current behaviour:

Set RememberLoginHash::$logout_across_devices to false OR
Install session manager

My feeling here is we're investing in improving the session-manager module with the goal of improving user and site security of the CMS. The best way to make that become a reality is to make that module as easy as possible to adopt.
We're still to confirm how the session-manager work will be released, but I'd like to see it go into the CMS core recipe so adoption is as pain-free as possible and requires one of:

composer update
read the CMS recipe changelogs and (if not using recipes) see the recommendations to install the module separately

Given the above, I think we should consider the investment already going into the session-manager module and take the "minimal fix" approach to resolve this issue.

In that scenario, there's no way to invalidate a "Remember me" cookie on a lost device, short of changing your password.

The best answer here is to use the session management feature that we've built exactly for that purpose.

If we weren't investing in the session manager already then I'd be all for the minimal fix. With the session manager module we have less need for the logout of all devices—not the most important addition unless its needed technically but adds a little value.
+1 for seeing this in core via the session manager module as it will provide the most benefit to the most people, makes it easier writing guides and better usability all round.
Do we have any idea how this might affect projects upgrading using the likes of SSO or identity managers? Is it worth checking in with a few projects to see howe this might affect them just so we have it in mind?

Do we have any idea how this might affect projects upgrading using the likes of SSO or identity managers?

No confident idea at this stage. We've got a dedicated issue to run through test scenarios with SSO in place: Compatibility with SSO modules.

With the session manager module we have less need for the logout of all devices—not the most important addition unless its needed technically but adds a little value.

Totally open to raising a separate issue to discuss including a 'sign out of all devices' feature if you like that idea @clarkepaul? I just think it should be handled as an additional and not be relied on to close this issue :P

@brynwhyman nope I don't think we need a "sign out of all" thing, as you were :)

It seems like the "Do mostly nothing" solution is the favourite. I'll confirm that setting RememberLoginHash::$logout_across_devices to false behave as expected and I'll review the existing doc.
My guess is this makes most of the ACs moot since we're going to keep the existing default.

Just clarifying that "Do mostly nothing" solution involves keeping the current default for RememberLoginHash::$logout_across_devices and the current behaviour.
The rational for this is mostly one around comms in the next release. If we change the default now, we'll have to explain to developers upgrading the ins and oust of the new behaviour. Then in the next release, we'll probably ship session-manager in core, which will again change the logout behaviour. I don't think there's much value in changing the default if that default is only going to matter for one release cycle.
Also the current default, is arguably more secure since it invalidates all your "remember me" tokens when you logout.
My thinking is this:

The vanilla install should keep the current default behaviour even if we don't think it's the best one in most cases. You need to set $logout_across_devices to false if you want the better log out behaviour.
Session manager should implicitly set $logout_across_devices to false. If you logout, only the "Remember Me" token for the current session will be invalidated.
Irrespective of what value is set for $logout_across_devices, when you use session manager to terminate a specific session, any "remember me" token associated to that session must be invalidated.

Sounds good

I've created a card to add unit test to the remember me feature: https://github.com/silverstripe/silverstripe-framework/issues/9896

Agree with Max and Bryn (and the "Do mostly nothing" option): We're fixing this properly with session-manager, and we don't have enough capacity to also fix anything in core without session-manager.
In terms of making this part of the core recipe, I think we need to have a broader discussion about what that means for support expectations from Silverstripe Ltd. That's already on Bryn's radar.

Linked PR has been merged


Firefox translations no longer [NIGHTLY]

Hello,
Pretty new to the project. I just wanted to point out that:

// PREF: Firefox Translations [NIGHTLY]
...
user_pref("browser.translations.enable", true);

Is no longer [NIGHTLY], it's in every Firefox build now I believe?
I noticed this because I find the translation feature highly obnoxious and annoying.

@yokoffing Thank you. I looked at the commit messages and then searched and didn't find anything. After looking into the code I see it's in the PR. 👍


Secured against brute force?

Thank you very much for developing this very useful extension and very easy to integrate.
I couldn't find in the readme if there is any feature that would prevent brute forcing the one time code?

Update:
Is it actually using the OTP policy we can see in the authentication settings ?

I did some more investigation and it seems after a few attempt keycloak forbids any new connection attempt for this user:
[keycloak-0 keycloak] 2024-07-17 13:33:34,242 WARN  [org.keycloak.events] (executor-thread-6263) type="LOGIN_ERROR",
[...]
 error="user_temporarily_disabled",
 auth_method="openid-connect",
 auth_type="code",
[...]


chore(main): release 2.29.0

:robot: I have created a release beep boop
2.29.0 (2024-08-01)
Features

EMS-3661: export contract - how was contract awarded - form validation (#2865) (c495363)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v2.29.0
:sunflower:


downloading PCD files

First, Thank you for this amazing work.
Please I didn't understand the leaf_size var in the rosservice command that download the pcd file,
If I want to save the dense map, what is the number of leaf_size to put in the command ? I tried 0.01 and the pcd file downloaded isn't like the dense map in rviz I don't know why.
Thank you again.

The dense map in rviz is purely for visualization and is just the deskewed scan but with a large decay time and an adjusted alpha value to give it that sharp look. The actual map used internally consists of the keyframes used for localization, and that is what is saved with the service command.

thanks, so what leaf_size would you recommend to use?


Modify the word error

What is the purpose of the change
update architecture.md、concept.md，modify incorrect word
Brief changelog
update architecture.md、concept.md
Verifying this change
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage increased (+0.02%) to 44.807% when pulling bab0f700f8debccb7710749fb3b4dc01456a4a67 on tiancang01:master into 8f37ff27db02177a1e336c8d5ee1a089a4a23939 on apache:master.

@tiancang01  please resolve your conflict code in you local enviroment and push commits into the develop branch rather then master branch.


Configure pitest

This PR adds a profile so pitest can be easily run against assertj core
mvn -Ppitest test-compile

The plugin has been bound to the test-compile (rather than test) as an easy way of preventing surefire from also running. As pitest runs the tests itself, additional running surefire just slows feedback.
A full analysis of the project takes around 45 minutes.
The PR also adds git integration, this allows just local changes to be analysed with
mvn -Ppitest -Dfeatures="+GIT" test-compile

Or for changes to be brought into scope from git history
mvn -Ppitest -Dfeatures="+GIT(from[HEAD~10])" test-compile

Once merged, this can be built on in a future PR to provide mutation testing feedback on all incoming PRs as described here -> https://blog.pitest.org/dont-let-your-code-dry/
The PR also modifies several tests to remove test order dependencies, and to exclude the pitest test runners from stack traces.

Thanks a lot @hcoles!


Provide sample for GATT Dynamic DB utilization for creation of GATT Services on runtime

Is your enhancement proposal related to a problem? Please describe.
Not exactly a problem but there is a lack of documentation on the utilization of available APIs to create resources for dynamic creation of GATT services on runtime.
Describe the solution you'd like
A working sample where a service is being created at runtime (triggered by some action, like when connection callback is called). Sample should include creation of all resources needed by the service to be created and registered at runtime. Attribute table for the service should also be created at runtime.
Describe alternatives you've considered
Been trying to do what I described above but unfortunately, I am not able to set the resources correctly for dynamic service creation.
Additional context
I think I have provided all the information above.

The tester application used for host qualification tests does this, see https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/bluetooth/tester/src/btp_gatt.c.
I would not recommend creating services this way, it is much simpler to just use the helper macros to define a static service.

Thanks for the quick response! I know creating services dynamically can create many issues. And as you mentioned, whenever GATT DB is changed, a rediscovery by client will also be needed. But I have a use-case that I wanted to validate with this approach.
What is the recommended way to at least modify the existing service (created statically) on runtime. For example, add a new characteristic to an existing service.

I also have a use-case for this:
I am making a simple multi-channel temperature sensor using ds18b20 devices. I would like to be able to:

plug in a previously-unused ds18b20 device to the bus (they have unique 64bit serial numbers in ROM)
initiate a search via a client command or button press to discover the device (this is working via button press)
create a new temperature sensor GATT service to display its UUID and sensor value
If possible, allow the user to set the device's name (and store the name in flash/eeprom, rather than on the client)

Currently I have one channel of data being returned by copying the peripheral_ht sample, but that seems to support only one sensor.
I was rather horrified by the complexity of the BT_GATT_SERVICE_DEFINE macro in the peripheral_esp sample.

I also have a use-case for this: I am making a simple multi-channel temperature sensor using ds18b20 devices. I would like to be able to:

plug in a previously-unused ds18b20 device to the bus (they have unique 64bit serial numbers in ROM)
initiate a search via a client command or button press to discover the device (this is working via button press)
create a new temperature sensor GATT service to display its UUID and sensor value
If possible, allow the user to set the device's name (and store the name in flash/eeprom, rather than on the client)

Currently I have one channel of data being returned by copying the peripheral_ht sample, but that seems to support only one sensor. I was rather horrified by the complexity of the BT_GATT_SERVICE_DEFINE macro in the peripheral_esp sample.

Does the client need to know/care about the serial number? Can multiple sensors be connected at the same time? You could potentially use a control point characteristic to select the sensor instead of adding a separate characteristic for each sensor.
Potential solution:

Have one characteristic to read the temperature
Have one characteristic to select which sensor to read from
Have a characteristic to read which sensors are available? Or the server can notify the client when a new one is connected.

My idea here is that when adding a new sensor you change the values in the database, not the layout.

Removed low priority bug label


npm-init.js installing szero 0.5.1

"szero": "^0.5.1",

we need at least 0.7.0, because is really a better version.

yea, i agree,  but should we wait until 0.8.0 is released, which i think i have scheduled for this friday, https://github.com/bucharest-gold/szero/milestone/6
it will fix that bug with the unused dependencies,  https://github.com/bucharest-gold/szero/issues/61

great !

actually lets use 0.7.1,  it has that bug fix,  i moved the 0.8.0 release to december since there is a bit more too it.  and i would like to take some time to figure it out.

landed here:  98a1351


Primitives should not be boxed just for "String" conversion

This pull request is focused on resolving occurrences of Sonar rule squid:S2131 - Primitives should not be boxed just for "String" conversion
You can find more information about the issue here:
https://dev.eclipse.org/sonar/coding_rules#q=squid:S2131
Please let me know if you have any questions.
Kirill Vlasov

Looks good to me, thanks @kirill-vlasov.

Thanks! Updated.


tools/syz-cover: no color on the c panel when it gets created from raw coverage

Describe the bug
A clear and concise description of what the bug is.
You can see the coverage from the right side of the panel like below. However, it will not show how many times it had been hit on the c panel.

To Reproduce
Steps to reproduce the behavior.
i was trying to follow the instruction from here coverage.md
however i get an error like below

when i add --kernel_src it works but c panel doesn't seem to color things (uncovered/covered)
syz-cover --kernel_src ./linux --kernel_obj ./linux rawcover
Expected behavior
I would assume it would look more something like this when its working. (this is from http::/url/cover).

Additional context
Add any other context about the problem here.

I accidentally reproduced it by passing relative kernel paths to syz-cover. But when I passed absolute paths, it worked fine (with colors).
Does it help if you pass absolute paths?
Probably tools/syz-cover should make them absolute before passing to the report generation.

I accidentally reproduced it by passing relative kernel paths to syz-cover. But when I passed absolute paths, it worked fine (with colors). Does it help if you pass absolute paths? Probably tools/syz-cover should make them absolute before passing to the report generation.

yes that seems to have fixed the issue :+1:
One other small problem I see is there seems to be no hitcounts next to the number of line.

but that might be how it suppose to be since rawcover all seems to be unique addresses? I just noticed there was no number and tested it by adding same address multiple time to see if it worked or not.
But thanks for quick response/fix and this amazing project!

but that might be how it suppose to be since rawcover all seems to be unique addresses?

Yes, this is WAI. /rawcover does not export programs nor hit counts.

But thanks for quick response/fix and this amazing project!

Thanks!


Remove unnecessary shebang

This file is not exectuable, and even if it were it doesn't do anything
useful when executed on its own.
This came up in the review to include pew in Fedora.

Hi there, anything I can do to move this forward? 😃

I totally don't know why I didn't merge this before, sorry :/


Break up and reorganise ci.yml

Closes #233
I’ve had a go at breaking up the ci workflow:

I’ve moved the vcpkg routine into an action which is called from the ci and release workflows
I’ve moved the release binary generation steps into the release.yml file. This will first call the ci.yml file to ensure the tests pass when a release is made

The ci.yml file is now much shorter and hopefully everything’s a bit clearer, take a look. One possible downside of this approach is that there’s some duplication between the ci and release files when it comes to defining os/compiler configurations and env variables. Also, when a release is made it will run the testing and binary release steps as separate jobs, meaning the vcpkg routine will be called twice, whereas previously this work was shared.
Also, I’m having a problem where it’s failing to compile with clang, see https://github.com/tsmbland/healthgps/actions/runs/6651996044/job/18075089562. This also fails on the main branch of the fork which I haven't changed from the original. Not sure what’s going on here, maybe you have some insights?
Could you please also explain the third task from the issue (unnecessary hash generation) a bit more as I’m not sure exactly what you’re referring to?

Hi @tsmbland . Many thanks for this! I will wait until it's all done, and review it all in one go, but looks good so far.
The clang issue is known to us -- see #237. Basically the clang-14 version that ships with Ubuntu 22.04 is quite dated, and does not correctly/fully implement all of the C++20 standard. Part of this is constexpr, hence the problems from <chrono>'s use of constexprs. No idea why it's complaining now of all times...
The third point is to remove the rule for generating the sha256 hash. It's in release.yml, and just needs removing. Cheers.

Ok - I've removed the sha256 hash routine

@tsmbland If this is ready for re-review, then click the icon by my name under reviewers

Seeing as this is now out of date, I think we might as well just close it.


Consider adding an example for onclick listener

Given the following Scatter example, it is unclear how to add an onclick listener to the chart.
let mut plot = Plot::new();
let trace = Scatter::new(vec![0, 1, 2], vec![2, 1, 0]);
plot.add_trace(trace);

let layout = plotly::Layout::new().title("Displaying a Chart in Yew");
plot.set_layout(layout);

plotly::bindings::new_plot(id, &plot).await;

In Plotly.js, this can be acheived by capturing the plotly_click event, i.e.
plot.on('plotly_click', function(data) {
  ..
});

Is it supported in plotly.rs?

Hi @chungwong. This is not supported. Would be nice if you could submit a PR with such a feature.

First of all thank you for the marvellous crate!
I would love to have a way to make the browser open a url on clicking on data points (a stacked bar in my case), and was thinking (hoping actually) that that functionality was provided by plotly::layout::ClickMode::Event, and then somehow give it a URL or javascript?


I edited the lightning_trainer after getting some errors

I edited the lightning_trainer because it did not work in slurm. It was using a list when it was a dictionary and for multi-nodes it was trying to open the log file many times

Thanks saw the issue, and merged it


cannot be recognized by aspx

I have no idea how this aspx was coded, but after saving the generated xlsx from xlsxio via MS-excel,
the new one is ok to be processed.
The error message was in Chinese, which means system resource is overloaded.

catch the exception and print its detail first. then analyzing...


Fixed parsing bug for USI continaining a colon in the interpretation

I changed the parsing to recognise the provinance identifiers to split the last remaining piece (interpretation+provinance) based on that. I first explored a stack based approach but that quickly grew in complexity. Additionally the specification is very unclear about provinances, but I think you know that as well, so I did not want to assume anything about the validity of using any kind of brackets in the provinance. If the specification was updated to disallow any kind of bracket (all of "()[]{}<>") the code could be changed to look for the last colon, but if it finds any bracket before it finds a colon it returns the full tail as the interpretation.

Thank you for adding this. I think the intent was that the string would be parsed from left to right with tokenization going the whole way, instead of hacky splitting on :, but provenance identifiers are a very specific use-case that I don't really understand yet.
Your solution looks good, but please see my note about rsplit_once vs split_once.

My main reason for giving up on parsing colons is that the specification for the provenance identifiers is fully unclear, so it is not specified if the provenance id can contain any kind of bracket. Additionally parsing the bracket structure of pro forma is doable but quite complicated, you need to support arbitrarily deep nesting but also ignore any bracket type that is not the outer bracket. For example [Info:<<{{(([[Have fun parsing!]]] is a valid text in proforma, but  [Info:<<{{(([[Have fun parsing!] is not. So the only solid structure I see is the guarantee that :XX- is the start of the provenance id. Yes a pro forma entry with this text  somewhere could be made, but that goes awry less often then the current implementation (which fails as soon as any colon comes on stage).

Okay, so that short-circuit option won't work, but shouldn't it still use rsplit_once regardless in order to avoid carving up the first CURIE tag in the interpretation?
Splitting mzspec:PXD000561:Adult_Frontalcortex_bRP_Elite_85_f09:scan:17555:VLHPLEGAVVIIFK/2:PR-G47 is fine, you get ("VLHPLEGAVVIIFK/2", "PR-G47")
Splitting mzspec:PXD000561:Adult_Frontalcortex_bRP_Elite_85_f09:scan:17555:VLH[UNIMOD:1]PLEGAVVIIFK/2:PR-G47 will split the sequence, not the identifier, ("VLH[UNIMOD", "1]PLEGAVVIIFK/2:PR-G47"). With rsplit_once you get ("VLH[UNIMOD:1]PLEGAVVIIFK/2", "PR-G47")

Yes indeed it should be. I will update it.

I realised I removed the repository code by splitting on it, so I took the liberty of making it into an enum and using that to better represent all possible repositories. With this I am ready for a merge.


Converting HTML to markdown doesn't appear to preserve HTML entities

Consider the following HTML example:

I think &

When I try converting this to Markdown using Turndown, I get the following output:
I think &

I guess I would expect Turndown to preserve HTML entities and to output something like this instead:
I think &

I couldn't see an option to turn this on, so unless I'm missing something, I assume I need to use something like https://www.npmjs.com/package/html-entities. But I just wanted to check I'm not missing anything obvious?
Here's the config I'm using:
const INITIAL_TURNDOWN_OPTIONS: Turndown.Options = {
  headingStyle: "atx",
  hr: "---",
  bulletListMarker: "-",
  codeBlockStyle: "fenced",
  fence: "```",
  emDelimiter: "_",
  strongDelimiter: "**",
  linkStyle: "inlined",
};

Any help much appreciated!

Using the CommonMark dingus, entering I think & or I think & renders to
I think &
. So, the HTML entity in the HTML source doesn't need to be preserved in the resulting Markdown to still render properly. Are you asking for a way to preserve HTML entities, even if they don't need to be preserved to render correctly?


New option to include/not include audience count estimates

Add new option to include/not include the audience count estimates, to avoid timeouts with large numbers of real-time segments

Thanks for the contribution! But sorry Dan, will reject this PR in favour of a solution where audience sizes are populated async.


Update stable version in repo from 1.4.0 to 1.5.0

Think about update stable version to 1.5.0
Version: stable=1.4.0 (67 days old) => latest=1.5.0 (15 days old)
Installs: stable=2110 (48.16%), latest=347 (7.92%), total=4381
Click to use developer portal
Click to edit
Do not close this issue manually as a new issue will be created if condition for update still exists.
Please drop a comment if any reason exists which blocks updating to version 1.5.0 at this time.
Note: This is an automatically generated message and not personally authored by bluefox!
@mcm1957 for evidence

This issue seems to be outdated.
This issue suggests to update the stable version of this adapter to 1.5.0 but the current stable version is already 1.5.0.
So this issue should be closed.
@mcm1957 for evidence


access dccm through dma port

When use external dma master to read/write data from/to DCCM through dma port, it's need more cycles (up to 20 cycles if config AHB-lite bus),  why need so many cycles to access?  if there are some ways to speed up this operation?
thanks!

DMA port arbitrates with CPU over DCCM. CPU has priority over DMA. MFDC register provides some control for DMA/Core priority settings.


Why does this appear?

Traceback (most recent call last):
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 151, in model_hash
OSError: [Errno 107] Transport endpoint is not connected
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/webui.py", line 337, in
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/webui.py", line 230, in webui
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/webui.py", line 111, in initialize
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 91, in setup_model
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 126, in list_models
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 46, in init
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 152, in model_hash
OSError: [Errno 107] Transport endpoint is not connected

an issue with google drive, I'm investigating

Trank You!!!

It seems to be an issue when you have way too many files , i'm testing it now to see if that's the problem because mine broke as soon as i dumped liek 100+ lora into a folder XD

It's now working?

I have same issue:
Is there any solution?
Traceback (most recent call last):
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 151, in model_hash
OSError: [Errno 107] Transport endpoint is not connected
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/webui.py", line 340, in
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/webui.py", line 233, in webui
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/webui.py", line 114, in initialize
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 91, in setup_model
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 126, in list_models
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 46, in init
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/sd_models.py", line 146, in model_hash
OSError: [Errno 107] Transport endpoint is not connected

if you have many lora models, put them in subfolders

yes, i found thi solution https://github.com/TheLastBen/fast-stable-diffusion/issues/1784, works now!


help: cannot change tthe color and style of MatchParen group

Neovim version (nvim -v)
v0.9.2
Operating system/version
Fedora Linux - 38
Describe the bug
I'm trying to change the MatchParen color for the carbonfox them but i'm not seeing any changes
return {
"EdenEast/nightfox.nvim",
lazy = false,
priority = 1000,
config = function()
require("nightfox").setup({
  options = {
    groups = {
      carbonfox = {
        MatchParen = { fg = "yellow" },
      },
    },
  },
})
vim.cmd("colorscheme carbonfox")
end,
}

Steps To Reproduce

copy the config
go over any parenthesis

Expected Behavior

what I want is for the opening and closing parenthesis to have the same block and color, in the above config I was trying with yellow but I don't see any changes
Repro
No response

thank you, it works but how do I make both the highlight be a block of same color i.e purple color of the carbonfox theme?

Not sure I understand the question. Which highlight groups are you referring to? Or do you mean inverting the highlight group so the background is magenta and the foreground is the background?

in the above screenshot only the opening parenthesis is highlighted with block, I want the same thing for the closing parenthesis as well, can this be done?

Your cursor is handed by your terminal and not neovim. I am guessing that you are using alacritty and have it set to reverse the current cell.
For example I am using wezterm and the cursor is static (always black foreground and white background).

no, what I mean is I want the opening and the closing parenthesis to be have cursor blocks

here, both the opening and closing parenthesis have cursor blocks

and here, both the parenthesis are highlighted but only the opening one has cursor block

the first screenshot is of the default theme and the second is of carbonfox

The 'cursor block' you are referring to it just setting the background color (the default is: MatchParen MatchParen    xxx ctermbg=6 guibg=DarkCyan).
Option 1
Set the foreground and background of the MatchParen highlight group.
require("nightfox").setup({
  groups = {
    all = {
      MatchParen = { bg = "palette.yellow", fg = "bg1" },
    },
  },
})

Option 2
Use the reverse style for MatchParen which reverses the foreground and background (see :h attr-list for list of styles)
require("nightfox").setup({
  groups = {
    all = {
      MatchParen = { fg = "palette.cyan", style = "reverse" },
    },
  },
})

Option 3
Use builtin shortcut in nightfox for reverse the match parens with options.inverse.match_paren = true.
require("nightfox").setup({
  options = {
    inverse = {
      match_paren = true,
    },
  },
  groups = {
    all = {
      MatchParen = { fg = "palette.cyan" },
    },
  },
})

Note
For the groups table it uses the spec table. If you want to refer to a palette color, prefix with palette..

Neovim can only set the highlight for the matched pairs. As pairs are highlighted based on your cursor's position it requires one of the pairs to be behind your cursor. Neovim does not control the cursor that is handled by your terminal. That is something you would have to consult your terminals cursor settings.

maybe I'm explaining something wrong, but this behavior works fine with default neovim theme along with the several other themes I have used in the past

Yes from the image that you provided your cursor is reversing the cell. I am guessing that you are using alacritty, (as that is the default behaviour). They both look like blocks because they are both different colors then the background color.
The default highlight only sets the background color and does not set a foreground color.
For example setting MatchParen to
MatchParen = { fg = "", bg = "palette.cyan" },

Would result in the following in alacritty:

And the same line with a different foreground color (commented)

And the same as the above but in wezterm

thanks a lot, this works and sorry for all the trouble :)


Just FYI this seems to be no longer working.

Getting provider not supported in console from firebase.js line 29.
Clean install simple
changed to our credentials
yarn: yarn run dev

Interesting the reduxSagas branch works.   More what i was looking for....


[JAWS V1] Cross-compiling native modules

http://iswwwup.com/t/5dc20214b79f/node.js-cross-compile-node-module-with-native-bindings-with-node-gyp.html
Contextify (and other native modules compiled with node-gyp) fail when deployed from a Mac. It looks like this:
START RequestId: 6b6c620b-4585-11e5-b7c3-f9f9cd8db2ee
module initialization error: Error at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Module.require (module.js:364:17) at require (module.js:380:17) at bindings (/var/task/node_modules/jsdom/node_modules/contextify/node_modules/bindings/bindings.js:76:44) at Object. (/var/task/node_modules/jsdom/node_modules/contextify/lib/contextify.js:1:96) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12)

Here's one solution:
jaws lambda-deploy

Check if you a JAWS builder is deployed in the AWS account.
If not, deploy it.
Send the function code to the JAWS builder lambda, and have it build and deploy it up there.

The only problem would be with things that take more than 60 seconds to build...

...and also custom npm repositories

:+1: This is an interesting and great idea.

And someone built it:
https://github.com/node-hocus-pocus/thaumaturgy

Also this: http://bitbucket.aerobatic.com/blog/lambda-continuous-deployment.html

Howdy - thaumaturgy is my project. Been watching JAWS for awhile and it was funny to see it pop up.  Let me know if I can help.

Hi @johntitus. I reckon there is a powerful synergy between JAWS and thaumaturgy. There has been discussion around it in the Gitter room [1] and also in the JAWS roadmap [2]. It would be great to have your input!
[1]  https://gitter.im/jaws-framework/JAWS
[2] https://docs.google.com/document/u/2/d/1SeTgtsQc620vcwgGMZ4F2yuWVf-A3JmpTn1VT8pKYsA/edit?usp=sharing

@johntitus I haven't had time yet to dig into your code, but from a high level we were going to start making something very similar to this.  @ac360 and I have been in talks with folks at AWS about this painpoint, so we should definitely touch base.  Give me a few days to look at what you got (I'm backed up on other stuff) and I'll reach out to you for next steps. Sound good?  Those 2 links @jwulf mention are good starting points.

This will be supported as a plugin

Any update on this? Is a plugin available or is there another recommended approach?


Substitution checking

Related code snippet:
https://github.com/Beluga-lang/McLTT/blob/89e791077a72a9a91083cfa312871ddce06ffdb1/theories/Extraction/TypeCheck.v#L147-L185
or more specifically,
https://github.com/Beluga-lang/McLTT/blob/89e791077a72a9a91083cfa312871ddce06ffdb1/theories/Extraction/TypeCheck.v#L180-L185
The problem here is in ci_extend case. We cannot infer the domain context of σ ,, M, but substitutions, in general, cannot have any "checking" mode (as there's nothing able to provide such domain context for checking).
We may need a judgment corresponding to the elaboration to rule out terms not directly written by users.
C.C. @HuStmpHrrr

We never have to check or inference a substitution. Substitutions never appear in a real program. They only occur in the intermediate process. In fact, I think they don't even occur during type checking, given conversion checking is done by NbE.
We should have a declarative judgment for type checking before going into the implementation. Otherwise, it's going to be difficult to prove completeness.

@HuStmpHrrr To rule out the case we need some judgement about elaboration as I said, or at least some type_checking_domain-likie. Otherwise I don't see how that can be done, especially for completeness.

Let's discuss some time. I don't get it then.

Sure. Oh, and as an extension note, once we have cocon substitution will appear in a real program, so we need to check a substitution later (but then we have a type that indeed provides the domain, so I hope that then it works without a problem)

This is solved by #163 with user_exp.


Register Meshery images as Official Docker images

Current Behavior
Docker images for Meshery are not listed as Official images.
Desired Behavior
Starting with layer5/meshery image, work through the process of having Meshery images listed as Official in Docker Hub. See https://github.com/docker-library/official-images#contributing-to-the-standard-library

May I take this issue? Looks like a good way to learn best practices in docker and about meshary at once :)

May I take this issue? Looks like a good way to learn best practices in docker and about meshary at once :)

@diru1100 sounds real good. @mkycia is a great individual to engage and collaborate with on this effort.

@diru1100 sounds real good. @mkycia is a great individual to engage and collaborate with on this effort.


Add a setting for the Y-axis of the area chart to connect empty values

i18n-check

The following components have not been translated
wizard (ru)wizard (en)

Wait for the reviewers to check your changes in Weblate and try running github action again.

i18n-check

The following components have not been translated
wizard (ru)wizard (en)

Wait for the reviewers to check your changes in Weblate and try running github action again.


Initial Terraform plan with no sponsored bucket]

Ignore -- testing some things for LINC -- was supposed to match PR against fork in LINC


Added interface for FITS files

WIP
Fixes #11.

Argh, something I was hoping we could avoid dealing with turns out we have to deal with it.
FITSIO.jl just takes over the memory read in by cfitsio. cfitsio reads the data in as row-major, but when Julia takes that memory it is assumed to be column-major. This means all of the data read in by read(::ImageHDU) is transposed. This will cause issues with any method that requires indexing (overscan, trimming, cropping). For example, I just tried subtracting overscan from a file using its fits header and I got an IndexError.
since we are handling opening the files internally, we're going to have to permute the dimensions appropriately. I wanted to avoid this because it is discrepant from FITSIO.jl (although the FITSIO.jl behavior isn't what I'd like it to be).
I suggest we add a function like this:
function getdata(hdu::ImageHDU)
	data = read(hdu)
	d = ndims(data)
	return permutedims(data, d:-1:1)
end

and the further calls within our methods should look like
subtract_overscan(hdu::ImageHDU, idxs; kwargs...) =
	subtract_overscan!(getdata(hdu), idxs; kwargs...)

Argh, something I was hoping we could avoid dealing with turns out we have to deal with it.
FITSIO.jl just takes over the memory read in by cfitsio. cfitsio reads the data in as row-major, but when Julia takes that memory it is assumed to be column-major. This means all of the data read in by read(::ImageHDU) is transposed. This will cause issues with any method that requires indexing (overscan, trimming, cropping). For example, I just tried subtracting overscan from a file using its fits header and I got an IndexError.
since we are handling opening the files internally, we're going to have to permute the dimensions appropriately. I wanted to avoid this because it is discrepant from FITSIO.jl (although the FITSIO.jl behavior isn't what I'd like it to be).
I suggest we add a function like this:
function getdata(hdu::ImageHDU)
	data = read(hdu)
	d = ndims(data)
	return permutedims(data, d:-1:1)
end

and the further calls within our methods should look like
subtract_overscan(hdu::ImageHDU, idxs; kwargs...) =
	subtract_overscan!(getdata(hdu), idxs; kwargs...)

Can't we just return the transposed version of data, something like:
function getdata(hdu::ImageHDU)
    data = read(hdu)
    return data'

LinearAlgebra.Adjoint{Int64,Array{Int64,2}}, whereas for the version you suggested the return type is Array{Int64,2}

Precisely, plus you can't use literal ' (or transpose) for anything more than 2 dimensions.


x64 build

Hi all,
May I please suggest a build for Windows 10 x64?
I tried doing it myself, and it appears to be that many dependencies are missing.
For example: \graphviz\windows\dependencies\libraries\x64\lib\xml2.lib.
Thanks. Refael.

Hey @refaelsh, welcome to GraPHP!
This project only uses Graphviz, so you're required to manually install it. Once you have a suitable version installed, this project will run the Graphviz executable (dot).
I'm not aware if any pre-built binary for 64 bit Windows exists, you may have to ask your favorite search engine (https://stackoverflow.com/questions/50644715/how-to-install-the-64-bit-version-for-windows-10-of-graphviz-2-38).
I hope this helps :+1:

Oops... Terribly sorry for the bother. My mistake.


kernel timeout_list NULL pointer access

I use MIMXRT1060_EVK board to run Zephyr. To avoid NULL pointer access, I use MPU to set ARM address 0x0 (located in ITCM which is not used in my program) as no-access attribute, so that NULL pointer access to 0 will cause MPU FAULT. A NULL pointer access occurs in remove_timeout() which is called by sys_clock_announce() in kernel/timeout.c.
E: ***** MPU FAULT *****
E:   Data Access Violation
E:   MMFAR Address: 0x4
E: r0/a1:  0x80198f18  r1/a2:  0x00017db0  r2/a3:  0x80002f60
E: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x6000dfc9
E:  xpsr:  0x2100020f
E: r4/v1:  0x00000000  r5/v2:  0x80006d80  r6/v3:  0x80094064
E: r7/v4:  0x00000000  r8/v5:  0x80002f60  r9/v6:  0x00000000
E: r10/v7: 0x60004bf1  r11/v8: 0x800ec57c    psp:  0x800ec4b0
E: EXC_RETURN: 0xfffffff1
E: Faulting instruction address (r15/pc): 0x6000ddee
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x800046b8 (tcpc_11)
E: Halting system

"Faulting instruction address (r15/pc): 0x6000ddee" is executing next->prev = prev; in sys_dlist_remove().
next pointer represented by r3 should not be NULL (0).
	next->prev = prev;
6000ddee:	605a      	str	r2, [r3, #4]

The following is the complete assembly code of remove_timeout() in which sys_dlist_remove() is called.
6000ddc8 <remove_timeout>:
	return (node == list->tail) ? NULL : node->next;
6000ddc8:	6803      	ldr	r3, [r0, #0]
{
6000ddca:	b530      	push	{r4, r5, lr}
	return (node != NULL) ? sys_dlist_peek_next_no_check(list, node) : NULL;
6000ddcc:	b168      	cbz	r0, 6000ddea <remove_timeout+0x22>
	return (node == list->tail) ? NULL : node->next;
6000ddce:	4a0a      	ldr	r2, [pc, #40]	; (6000ddf8 <remove_timeout+0x30>)
6000ddd0:	6852      	ldr	r2, [r2, #4]
6000ddd2:	4290      	cmp	r0, r2
6000ddd4:	d009      	beq.n	6000ddea <remove_timeout+0x22>
	if (next(t) != NULL) {
6000ddd6:	b143      	cbz	r3, 6000ddea <remove_timeout+0x22>
		next(t)->dticks += t->dticks;
6000ddd8:	e9d3 2104 	ldrd	r2, r1, [r3, #16]
6000dddc:	e9d0 4504 	ldrd	r4, r5, [r0, #16]
6000dde0:	1912      	adds	r2, r2, r4
6000dde2:	eb41 0105 	adc.w	r1, r1, r5
6000dde6:	e9c3 2104 	strd	r2, r1, [r3, #16]
 * @return N/A
 */

static inline void sys_dlist_remove(sys_dnode_t *node)
{
	sys_dnode_t *const prev = node->prev;
6000ddea:	6842      	ldr	r2, [r0, #4]
	sys_dnode_t *const next = node->next;

	prev->next = next;
6000ddec:	6013      	str	r3, [r2, #0]
	next->prev = prev;
6000ddee:	605a      	str	r2, [r3, #4]
	node->next = NULL;
6000ddf0:	2300      	movs	r3, #0
	node->prev = NULL;
6000ddf2:	e9c0 3300 	strd	r3, r3, [r0]
}
6000ddf6:	bd30      	pop	{r4, r5, pc}
6000ddf8:	80002f60 	.word	0x80002f60

6000ddfc <timeout_rem>:
	return ret;
}

To Reproduce
The following is main.c used to duplicate the phenomenon. 32 TCP server threads and 32 TCP client threads are created. TCP client thread tries to connect to local server. Zephyr does not support IP loopback interface, so TCP client connection fails and then continues to try connection. After few minutes, MPU fault occurs.
#include <zephyr.h>
#include <stdio.h>
#include <net/socket.h>

#define NUM_THREAD  32
#define THREAD_STACK_SIZE 8192
#define THREAD_PRIORITY K_PRIO_COOP(8)
K_THREAD_STACK_ARRAY_DEFINE(tcpserver_stack, NUM_THREAD,
			    THREAD_STACK_SIZE);
struct k_thread tcpserver_thread[NUM_THREAD];
K_THREAD_STACK_ARRAY_DEFINE(tcpclient_stack, NUM_THREAD,
			    THREAD_STACK_SIZE);
struct k_thread tcpclient_thread[NUM_THREAD];

void tcpserver(void *ptr1, void *ptr2, void *ptr3)
{
    int tcpport = (int)ptr1;
    int listen_fd, data_fd;
    struct sockaddr_in sin;
    int n;

    listen_fd = zsock_socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (listen_fd <= 0) {
        return;
    }
    sin.sin_family = AF_INET;
    sin.sin_port = htons(tcpport);
    sin.sin_addr.s_addr = INADDR_ANY;
    zsock_bind(listen_fd, (const struct sockaddr *)&sin, sizeof(sin));
    zsock_listen(listen_fd, 1);
    while (1) {
        n = sizeof(struct sockaddr_in);
        data_fd = zsock_accept(listen_fd, (struct sockaddr *)&sin, &n);
        zsock_close(data_fd);
    }
}

void tcpclient(void *ptr1, void *ptr2, void *ptr3)
{
    int tcpport = (int)ptr1;
    int fd;
    struct sockaddr_in sin;

    while (1) {
        fd = zsock_socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
        if (fd <= 0) {
            return;
        }
        sin.sin_family = AF_INET;
        sin.sin_port = htons(tcpport);
        sin.sin_addr.s_addr = 0x0100007F; /* <IP_ADDRESS> */
        zsock_connect(fd, (struct sockaddr *)&sin, sizeof(sin));
        zsock_close(fd);
    }
}

void main(void)
{
    int i;
    char name[64];

    for (i = 0; i < NUM_THREAD; i++) {
    	k_thread_create(&tcpserver_thread[i], tcpserver_stack[i],
    	    K_THREAD_STACK_SIZEOF(tcpserver_stack[i]), tcpserver,
    	    (void *)(4001 + i), NULL, NULL, THREAD_PRIORITY, 0, K_NO_WAIT);
        snprintf(name, sizeof(name), "tcps_%d", i);
    	k_thread_name_set(&tcpserver_thread[i], name);
    	k_thread_start(&tcpserver_thread[i]);

    	k_thread_create(&tcpclient_thread[i], tcpclient_stack[i],
    	    K_THREAD_STACK_SIZEOF(tcpclient_stack[i]), tcpclient,
    	    (void *)(4001 + i), NULL, NULL, THREAD_PRIORITY, 0, K_NO_WAIT);
        snprintf(name, sizeof(name), "tcpc_%d", i);
    	k_thread_name_set(&tcpclient_thread[i], name);
    	k_thread_start(&tcpclient_thread[i]);
    }
}

Impact
This is a test to cause potential problem. Multi-thread sockets program can cause system crash as in #32564
Environment

OS: Linux
Toolchain: Zephyr SDK
Commit 75a2ef8fc02a417f0d26307105f80b136a666dc8

Zephyr does not support IP loopback interface

Loopback is supported, just set CONFIG_NET_LOOPBACK to enable it.

Can be replicated with native_posix
*** Booting Zephyr OS build zephyr-v2.6.0-315-gde2e14177b37  ***
==20141== Thread 4:
==20141== Invalid write of size 4
==20141==    at 0x80693F2: sys_dlist_remove (dlist.h:514)
==20141==    by 0x80693F2: remove_timeout (timeout.c:59)
==20141==    by 0x8069719: sys_clock_announce (timeout.c:250)
==20141==    by 0x805260D: vector_to_irq (irq_handler.c:49)
==20141==    by 0x805260D: posix_irq_handler (irq_handler.c:93)
==20141==    by 0x805260D: posix_irq_handler (irq_handler.c:66)
==20141==    by 0x8067BA9: k_cpu_idle (kernel.h:5419)
==20141==    by 0x8067BA9: idle (idle.c:98)
==20141==    by 0x804A0FB: z_thread_entry (thread_entry.c:29)
==20141==    by 0x8051771: posix_thread_starter (posix_core.c:305)
==20141==    by 0x414467F: start_thread (in /usr/lib/libpthread-2.31.so)
==20141==    by 0x4254829: clone (in /usr/lib/libc-2.31.so)
==20141==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==20141==
==20141==
==20141== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==20141==  Access not within mapped region at address 0x4
==20141==    at 0x80693F2: sys_dlist_remove (dlist.h:514)
==20141==    by 0x80693F2: remove_timeout (timeout.c:59)
==20141==    by 0x8069719: sys_clock_announce (timeout.c:250)
==20141==    by 0x805260D: vector_to_irq (irq_handler.c:49)
==20141==    by 0x805260D: posix_irq_handler (irq_handler.c:93)
==20141==    by 0x805260D: posix_irq_handler (irq_handler.c:66)
==20141==    by 0x8067BA9: k_cpu_idle (kernel.h:5419)
==20141==    by 0x8067BA9: idle (idle.c:98)
==20141==    by 0x804A0FB: z_thread_entry (thread_entry.c:29)
==20141==    by 0x8051771: posix_thread_starter (posix_core.c:305)
==20141==    by 0x414467F: start_thread (in /usr/lib/libpthread-2.31.so)
==20141==    by 0x4254829: clone (in /usr/lib/libc-2.31.so)
==20141==  If you believe this happened as a result of a stack
==20141==  overflow in your program's main thread (unlikely but
==20141==  possible), you can try to increase the size of the
==20141==  main thread stack using the --main-stacksize= flag.
==20141==  The main thread stack size used in this run was 8388608.
==20141==

Note that because 0 is a valid fd, the check in tcpserver thread needs to look like this
    if (listen_fd < 0) {
        return;
    }

As almost every limit in Zephyr is determined at build time, some networking limits need to be increased because you are creating quite many sockets etc. in the application. So I compiled the application like this in order to increase the socket count etc.
cmake . -Bbuild -DBOARD=native_posix -DCONFIG_NATIVE_UART_AUTOATTACH_DEFAULT_CMD=\""gnome-terminal -- screen %s"\" -DCONFIG_NET_MAX_CONTEXTS=96  -DCONFIG_NET_PKT_RX_COUNT=96 -DCONFIG_NET_PKT_TX_COUNT=96 -DCONFIG_NET_MAX_CONN=96 -DCONFIG_NET_BUF_RX_COUNT=128 -DCONFIG_NET_BUF_TX_COUNT=128  -DCONFIG_NET_LOOPBACK=y -DCONFIG_NET_CONFIG_MY_IPV4_ADDR=\""<IP_ADDRESS>"\"

This helped a bit although I am still seeing error prints in console and eventually there is a crash like this.
*** Booting Zephyr OS build zephyr-v2.6.0-316-g8934cd6304da  ***
==49357== Thread 4:
==49357== Jump to the invalid address stated on the next line
==49357==    at 0x0: ???
==49357==    by 0x8052729: vector_to_irq (irq_handler.c:49)
==49357==    by 0x8052729: posix_irq_handler (irq_handler.c:93)
==49357==    by 0x8052729: posix_irq_handler (irq_handler.c:66)
==49357==    by 0x806647C: k_cpu_idle (kernel.h:5419)
==49357==    by 0x806647C: idle (idle.c:98)
==49357==    by 0x804A0DB: z_thread_entry (thread_entry.c:29)
==49357==    by 0x805188D: posix_thread_starter (posix_core.c:305)
==49357==    by 0x414467F: start_thread (in /usr/lib/libpthread-2.31.so)
==49357==    by 0x4254829: clone (in /usr/lib/libc-2.31.so)
==49357==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==49357==
==49357==
==49357== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==49357==  Bad permissions for mapped region at address 0x0
==49357==    at 0x0: ???
==49357==    by 0x8052729: vector_to_irq (irq_handler.c:49)
==49357==    by 0x8052729: posix_irq_handler (irq_handler.c:93)
==49357==    by 0x8052729: posix_irq_handler (irq_handler.c:66)
==49357==    by 0x806647C: k_cpu_idle (kernel.h:5419)
==49357==    by 0x806647C: idle (idle.c:98)
==49357==    by 0x804A0DB: z_thread_entry (thread_entry.c:29)
==49357==    by 0x805188D: posix_thread_starter (posix_core.c:305)
==49357==    by 0x414467F: start_thread (in /usr/lib/libpthread-2.31.so)
==49357==    by 0x4254829: clone (in /usr/lib/libc-2.31.so)
==49357==

I also needed to apply the fix at #36284.
Not sure where the issues are, the backtrace does not indicate a problem in networking side.

The client thread is flooding the system which is causing some issues in TCP because the CONFIG_NET_TCP_TIME_WAIT_DELAY is set to 250ms by default. Because of this, the TCP resources are kept still around after the socket is closed. Everything should be working smoothly even if the device is flooded, but there seems to be some place in the stack that does not handle resource exhaustion properly.
Everything starts to work much better if I add
k_msleep(250);

after the socket close in tcpclient thread.

Can be replicated with native_posix

The following is how it goes:

tcp_work thread: send_timer->tcp_send_process()->tcp_send_process_no_lock()->"peek head pkt in conn->send_queue"
context switch to tcp client thread: net_tcp_connect()->tcp_conn_unref()(for ETIMEDOUT)->tcp_send_queue_flush()
context switch back to tcp_work thread:  tcp_send_process_no_lock()->k_work_reschedule_for_queue()->z_add_timeout()->"append conn->send_timer->timeout to timeout_list"
context switch back to tcp client thread:  tcp_conn_unref()->memset(conn, 0, sizeof(*conn)), which clears conn->send_timer->timeout structure
irq: sys_clock_announce->remove_timeout(), the timeout structure is cleared in step 4, so null pointer access occurs

My understanding is if remote TCP server is unreachable (e.g. IP address is wrong) and TCP client in Zephyr is keeping retry to connect, then Zephyr will crash.
If this is true, it would be an serious issue in TCP2 stack especially we are working toward to v2.7 LTS release.

tcp_work thread: send_timer->tcp_send_process()->tcp_send_process_no_lock()->"peek head pkt in conn->send_queue"
context switch to tcp client thread: net_tcp_connect()->tcp_conn_unref()(for ETIMEDOUT)->tcp_send_queue_flush()
context switch back to tcp_work thread:  tcp_send_process_no_lock()->k_work_reschedule_for_queue()->z_add_timeout()->"append conn->send_timer->timeout to timeout_list"
context switch back to tcp client thread:  tcp_conn_unref()->memset(conn, 0, sizeof(*conn)), which clears conn->send_timer->timeout structure
irq: sys_clock_announce->remove_timeout(), the timeout structure is cleared in step 4, so null pointer access occurs

A race condition occurs when tcp_conn_unref() is executed by tcp client thread to release tcp connection while tcp_work thread is running tcp_send_process() in which tcp connection is being processed.
Locking tcp_lock in tcp_send_process() can avoid race condition described above.
static void tcp_send_process(struct k_work *work)
{
	struct tcp *conn = CONTAINER_OF(work, struct tcp, send_timer);
	bool unref;

	k_mutex_lock(&tcp_lock, K_FOREVER);

	k_mutex_lock(&conn->lock, K_FOREVER);

	unref = tcp_send_process_no_lock(conn);

	k_mutex_unlock(&conn->lock);

	k_mutex_unlock(&tcp_lock);

	if (unref) {
		tcp_conn_unref(conn);
	}
}

@tbursztyka do you think this issue is still applicable?


fixed replacing options.paged if it is true/false

In the previous code, line 188 would replace options.paged with {} if it is:

undefined
false
any other value that evaluates as false, like 0 or ''
or strictly equal to true

and then adds the properties pageSize and pagePause to it.
This makes it impossible to disable paging by options, because any value that evaluates to false and would be passed to the underlying ldapjs is replaced by a value, that effectively turns on paging.
I think this is not expected behavior and !options.paged was just intended to be a check if it is undefined or not.

Hey @wickning1, any interest in merging this PR? Or should something be adjusted there?

I agree that it should accept paged: false, but paged: true should be overwritten because pagePause: true isn't default but it should be.
I've fixed this in the major version I'm working on for upgrading to ldapjs 3.0.


adapt run-java-sh to adopt the auto-generation options for Java 11

@rhuss said in #160 that, quote:

major work will be to adapt https://github.com/fabric8io-images/run-java-sh to adopt the auto-generation options for the JDK. E.g. it would need a Java 8 / Java 11 dynamic detection (or taken from an env var) and use only the self-calculated cgroup based limits if not running on Java 11. Also, it would be awesome to update the fine-tuned options for Java 11 as well. A similar issue is open over there btw --> https://issues.jboss.org/browse/CLOUD-2839

But somewhat to my surprise, I seem to actually have been able to get a (basic) Java 11 working without touching run-java-sh ... I therefore propose that we work incrementally, and get #160 wrapped up and merged, and then iterate to improve things re. the point raised above under this issue.

@jerboaa thanks for the feedback. Actually, we should update run-java.sh either to detect also whether a Java 8 JDK supports the cgroup awareness automatically (and switch off the homegrown calculation in this case), or add an extra flag/env var to indicate that this is not needed anymore. The latter is probably is simpler (and then could be reused here when we are using the proper base image), but we might strive for the former, too.
Regardless what, works needs to be done over there in ghttps://github.com/fabric8io-images/run-java-sh


Python running selection within function causes indentation error

Environment data

VS Code version: 1.30.1
OS and version: Linux Ubuntu 18.04 bionic
Python version (& distribution if applicable, e.g. Anaconda): 2.7.15

Expected behaviour
After selecting indented lines (i.e.) inside a function/method/class and hitting Shift+Enter, code should execute in terminal without raising IndentationError.
Actual behaviour
For code:
def square(i):
    s = i*i
    s2 = s+1
    return s2

selecting two lines with variable manipulation causes error.

Steps to reproduce:

Create python source file.
Create function inside it
Select lines inside  the function
Press Shift+Enter to run the selection

Output
Python 2.7.15rc1 (default, Nov 12 2018, 14:31:15)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>     s = i*i
  File "<stdin>", line 1
    s = i*i
    ^
IndentationError: unexpected indent
>>>     s2 = s+1
  File "<stdin>", line 1
    s2 = s+1
    ^
IndentationError: unexpected indent
>>>

Thanks for bringing this up, @vicrac.  I've verified (on linux) with the latest release of the extension that this is failing as described.  We'll working on fixing it.

FWIW, this reminds me of something we fixed a while back.  @DonJayamanne, do you remember that?  I'm pretty sure you worked on it.

@vicrac - I believe this has been resolved as of today.
https://github.com/Microsoft/vscode-python/issues/2837
https://marketplace.visualstudio.com/items/ms-python.python/changelog


going to give it a try, noob coder will keep updated

hopefully we can get this untether working 👌

so whens the update

when upd?

this is literally a fake jb dudes its just fugu14 copy and pasted

RIP this guys phone


RenderDoc (nightly build) crashes when trying to create a vulkan swapchain

When I'm trying to debug my rendering engine by launching it from within RenderDoc, the window just closes. If I attach a debugger (after launching it from RenderDoc) it turns out that vk::createSwapchainKHR() call crashes in the driver (access violation). If, however, I launch my engine from explorer (or from Visual Studio) and then before creating a Vulkan instance I inject RenderDoc into it, it works fine and I can take captures. Which means that there's something about how RenderDoc launches an application that makes it crash for me. Any suggestions where to look?
My system: windows 10, RenderDoc_2019_10_07_3587ec2e_64 nightly, GTX1060.

It sounds like perhaps you haven't configured the right working directory in RenderDoc, by default if you don't choose one it will use the directory the executable is in.
I can't tell you why the crash is happening unless I have more information and ideally I can reproduce the problem. If you can share your program with me either here or privately please do so and I can look to see what the problem is.

I did specify the correct working directory (at least, it works fine when I'm using the exact same config in 1.4). I'm honestly not sure that the problem is in my program itself: it can be in my version of vulkan sdk(latest), nvidia driver or something else. I can make you a test executable if everything else fails, but maybe there is an easier option? Does renderdoc have any options for verbose logging?

RenderDoc doesn't have any verbose logging, and if it's crashing inside the driver in vkCreateSwapchainKHR then there's not really any logging that would help diagnose that. To isolate if it's something specific to your program you could try capturing a known-working program like vkcube from the SDK or one of Sascha Willems' samples, to see if they crash also. It is most likely that it's something related to your program, even if it's not necessarily an application fault, otherwise myself or someone else would have seen the problem too.
RenderDoc does very little in vkCreateSwapchainKHR aside from unwrap the surface and oldSwapchain handles and pass the call along to the driver, so I'm surprised it works in v1.4 and crashes in a recent build. If you wanted to you could try different nightly builds from the last few months to bisect and narrow down when the problem started happening, but the easiest way for me to investigate the problem is if you can share the executable that's crashing.
I'm assuming also that you don't have any validation warnings or errors with your program, as any of these could cause crashes.

I actually did end up creating a test binary for you, but then I noticed your message and tried running vkcube.exe
Lo and behold, same behaviour: it runs fine under 1.4 and crashes in nightly build. I'm not entirely amazed by the possibility of me bisecting the exact build that caused it, but if nothing else works, I can do it as I really appreciate your work.

What nvidia driver version are you running? That's more important than SDK version.

I'm running driver version 436.48 (downloaded from GeForce Experience thingie). Also running bisection now.

So I found that this build works fine:
v1.x branch @ 0d7c7eb2, 2019-08-27
And this build breaks on vkcube.exe for me:
v1.x branch @ 12f08aa4, 2019-08-28
Hope this helps.

That helps to narrow it down but I must admit I have no idea what in that range could be causing problems. Not even that there's some code that's innocuous, looking at the diff I don't see any code that will be running during capture of a vulkan program. The changes are all either in another API (GL or D3D11), another platform (Android), or only run at replay time.
Unfortunately that doesn't leave me with any more ideas of what the problem could be. Would you be able to compile those few revisions to bisect even further down than the nightly builds, to see the exact commit that causes problems? I'm not sure what will result from that but it's about the only thing I can think to try.
I did try reproducing the problem with that exact driver and SDK version but I've had no luck. It might be hardware specific (I don't have a 1060) but I doubt it.

There are two changes that seem remotely related: the one in vk_core.cpp and core.cpp but I have honestly no clue what I'm looking at. I have not tried building RenderDoc myself yet, but https://github.com/baldurk/renderdoc/blob/v1.x/docs/CONTRIBUTING/Compiling.md promises it's supposed to be simple so I can give it a shot.

The code in vk_core.cpp is disabled - SINGLE_FLUSH_VALIDATE is always defined off as it's a debugging macro that can be turned on during development to help debug driver/GPU crashes. The code in core.cpp only runs in the replay program, not in any captured programs. It might turn out to somehow be related but I can't see right now how it would be, so it doesn't give me any ideas for a potential fix or even a potential test.
The overnight builds are compiled on a VM which has not changed in build environment. The compiler is VS2015 and the only external dependency should be the windows SDK.
Some weird bug that has been revealed by different code generation or layout is certainly possible though as you say it's hard to do anything with that just yet. If you can compile those versions that should tell us more - indeed on windows it's as easy as downloading the source and compiling the .sln.

Yeah I found what it is. Indeed, it's this commit: https://github.com/baldurk/renderdoc/commit/422cd728adc031f76b9d53d43f98d6b105d42a37
What happens here is you initialize replay device driver for Vulkan driver (core.cpp):
      ReplayStatus status = m_ReplayDriverProviders[driverType](NULL, ReplayOptions(), &driver);

which is a pointer to this (vk_replay.cpp):
ReplayStatus Vulkan_CreateReplayDevice(RDCFile *rdc, const ReplayOptions &opts, IReplayDriver **driver)

and it calls this inside of it:
  // disable buggy and user-hostile NV optimus layer, which can completely delete physical devices
  // (not just rearrange them) and cause problems between capture and replay.
  Process::RegisterEnvironmentModification(
      EnvironmentModification(EnvMod::Set, EnvSep::NoSep, "DISABLE_LAYER_NV_OPTIMUS_1", ""));

You can't repro this problem because you're on a desktop, I presume. I'm on a laptop which uses shmoptimus. It does report me just one physical device normally in all my vulkan application (the one I allow it to run on) so it is indeed pretty wrong by design. However, commenting this call restores RenderDoc functionality for me. I know, this thing is very annoying to deal with. Keep in mind, however, that both my GTX1060 and integrated video (Intel HD 630) are capable of running Vulkan (and vkcube.exe that I'm testing with) and whichever RenderDoc chooses, both should work.
Here's what RenderDoc output looks like if I comment that environment modification line and run vkcube.exe (it runs):

And here's what it looks like if I uncommend the line (as in the latest revision, it crashes when I try to launch vkcube.exe):

Hope this helps.

Oh I see, so the DISABLE_LAYER_NV_OPTIMUS_1 env var is getting set earlier now and then inherited into the child process. In v1.4 it was only set later when the first replay happens and only inherited after that.
So in that case the question then is, if you remove RenderDoc from the equation completely and just run vkcube.exe or your own program with DISABLE_LAYER_NV_OPTIMUS_1=1 from the command line or visual studio, does vkcube.exe crash? What is the exact callstack - is it crashing in nvidia's driver or Intel's? Perhaps if the optimus layer is disabled the intel GPU is listed first, and it is intel's driver that is crashing.

Indeed it does crash the same way if I set the environment value DISABLE_LAYER_NV_OPTIMUS_1=1 from command line myself. It does, however, run correctly if I launch it on either GPU from context menu->"Run with graphics processor" and I can tell that it's actually running on a different gpu this way at least due to huge performance difference. I wonder how many other laptops will fail to run a vulkan application now with DISABLE_LAYER_NV_OPTIMUS_1=1 set.

What is the actual callstack of the crash? What version is your intel GPU's driver?

Here's the callstack:

My Intel driver:

That driver is quite old. I have no idea what device manager does to try and update, I wouldn't trust it since it probably only checks windows update. The Intel website has newer drivers and they may contain a fix for this crash, and if not I'd recommend reporting it to Intel themselves. Otherwise there's not much I can do for a driver bug like this, when it's not RenderDoc related (as you can repro it just by disabling the optimus layer directly).
Disabling the optimus layer is deliberate as otherwise it can cause significant problems between capture and replay. Leaving it enabled is not an option. I didn't actually realise it wasn't being disabled properly on the first run before, that could have caused other problems.

With vkcube.exe it will pick the first physical device available, which might be the Intel GPU. Each program will have its own logic for selecting physical devices from those available, disabling the optimus layer just means that they are all listed instead of having some removed - with recent loaders they will be listed in preferential order on Windows.
Disabling optimus is necessary to prevent potential incompatibility between capture and replay where the physical device used in one case isn't available in the other. If the intel driver crashes then that's a problem that needs to be solved within the driver itself - this could happen just as easily if a user disables the optimus layer and wants to use the Intel GPU.

Updating intel driver did fix the issue. Still unsure about disabling optimus for the child process though: if you want to make sure that the replay runs on the same GPU as a capture, then disable optimus for renderdoc process itself and make sure it has all physical devices listed to find the one capture was recorded with instead of disabling it for both renderdoc and the child. Otherwise it can mess up with how an app runs from within renderdoc and outside of it as it uses the same optimus setting as renderdoc itself.

Keeping the environment as close as possible between capture and replay is important to minimise the chance of incompatibilities either now or in future. Disabling the optimus layer should work fine, especially now that the loader orders physical devices by GPU preference. You ran into an Intel driver bug which could happen at any time - it just so happened to be hidden by the optimus layer in this case.


how to use ExtrudeGeometry to make a mesh?

like this?
const shapeGeometry = new THREE.ExtrudeGeometry(shape, {
depth: 3,
bevelThickness: 2,
bevelSegments: 10
});
const mesh = new THREE.Mesh(
shapeGeometry,
new THREE.MeshBasicMaterial({ color: 0xb8b730 * Math.random(), opacity: 1 })
);
I hope someone gives me a demo? 3Q.

This issue has been solved in the my Threebox fork. There's a specific example on creating extrusions from THREE.Vector2 arrays and from geoJson features.


codegen: fixing multidimensional array schema

when trying to introspect an openapi datasource,
with multi-dim array of numbers
getting the following error:
  4 | features: {
  5 | geometry: {
> 6 | coordinates: : : : number[],[],[],[],},
    |              ^
  7 | }[],},
  8 | }

Error:
coordinates: : : : number[],[],[],[]

expected to be
coordinates: number[][][][]

a repo to reproduce error:
https://github.com/abdelhameedhamdy/geojson-api
a small fix added should fix the issue.
re-run introspection, error disappeared, schema generated as expected
coordinates: [[[[Int]]]]

@jensneuse
sure, test has been added
commit 057de7425ddcb9d3e08bd443e75836c5f64bcd82

@jensneuse sure, test has been added commit 057de74

Thank you, amazing work!


fix unify metrics vs metric in schema and filter reg			42e856e

Coverage remained the same at 82.23% when pulling 42e856e70f0764ab504ec9fc95961f7fdea688a1 on kapilt:core-metrics-filter into e274cc4b5db55118f8c468e2a9b4824cb65f8fb9 on capitalone:master.


Failed to start Docusaurus server

🐛 Bug Report
Fail to start docusaurus-server
Have you read the Contributing Guidelines on issues?
(Write your answer here.)
To Reproduce
(Write your steps here:)

run npx docusaurus-init
yarn start
Step 3...

Expected behavior
Starts normally
(Write what you thought would happen.)
Actual Behavior
Actual is: Failed to start Docusaurus server: SyntaxError: Unexpected token (37:15)
(Write what happened. Add screenshots, if applicable.)
Your Environment

Docusaurus version used: 1.14.5
Environment name and version (e.g. Chrome 78.0.3904.108, Node.js 10.17.0): Node v12.15.0
Operating system and version (desktop or mobile): Fedora 31

Reproducible Demo
(Paste the link to an example repo, including a siteConfig.js, and exact instructions to reproduce the issue.)

Duplicate of https://github.com/facebook/docusaurus/issues/3199
Already fixed, going to release right now

Release 1.14.6, seems to work now


Demo's not working

Both demo links on the home page of the repo directly give runtime errors.

sorry, saw that was already mentioned by someone else in october


Docker instance is Of Node js Not Working how we install it

The Nodeos is Not running in docker I install docker in my linux machine and when i load Nodeos it give error Corrupted file

Seems to be a Docker problem, how are you using it?

@piranna  i clone the code and hit npm install i want to run this code in my ubntu it is possibel aur not so that i understand the code and give my own contribution to create a job pool in node os

@piranna when i run npm run build  it give error
prebuild-install info install Successfully installed prebuilt binary!
cp: cannot stat ‘/out/nocona-nodeos-boot-multiUser’: No such file or directory
Error building '/home/silver/NodeOS/NodeOS/out/x86_64/pc/qemu'
How i resolve this issue..

Have you followed the instruction to install all the dependencies? Seems like you are missing some step here...


[5.4] Allow using assertSessionHasErrors to look into different error bag

Solves the case in https://github.com/laravel/framework/issues/19134

5.4 or master? Title says one, PR to the other?

5.5 .. sorry :)