Query Performance Statistics

Will post information about Github GraphQL Query performance. All of these are done on 10 successive runs. All of these were run on this repo: https://github.com/metrumresearchgroup/rbabylon. Each sets of query tests were run with the same data to retrieve. No pagination was used so the default root node return size was capped at 100.

Query
Performance

get all issues + filter
~446ms

get issues by specific milestone
~165ms

Query
Performance

get first 50 comments of all issues
~666ms

get first 1 and last 3 comments of all issues
~990ms

get all comments of single issue (issue 71 was used which has 8 comments)
~78.57ms

@dpastoor with almost a 3rd of the performance increase between just getting the first 50 and getting the first 1 and last 3. It might be worth just scrapping the bookend comments query and switching to first 50 comments.


chore(side-navigation): rename subnav -> subNav and sidenav -> side-nav

Description
rename subnav -> subNav and sidenav -> side-nav for consistency
Scope

[ ] Patch: Bug Fix
[ ] Minor: New Feature
[x] Major: Breaking Change

thanks @leyanlo. going to keep this pr open until the next major

Thanks for the PR, @leyanlo! Could you add a migration guide for the change? You can find an example of it here

Updated with migration guide. Let me know if it looks ok!

Looks great! Can you open this PR against the v7 branch please?

Updated PR against v7 branch


CSS changes

Since the Drawing Canvas was a critical issue, I tried to reproduce the changes made by Beefjerkie and found out that the Drawing canvas hence is not calibrated.
Also fixed the issue of Controls being unrepsonsive.
Reduced the padding of menu navbar-toggle to improve the UI
Improved the markup for Contributors

@charmaine Can you check this and respond ASAP :) Thanks

Hey @kira0204! Thanks for carefully identifying what needed to be done and for contributing to the repo!
Feel free to continue working on anything else in the repo! :tada:


Fix export (increasing font sizes)

Issue number: resolves #267

Checklist

[ ] Code Formatter (run prettier/spotlessApply)
[ ] Code has unit tests? (If no explain in other_information)
[x] Builds on localhost
[x] Builds/Runs in docker compose

What is the current behavior?

When exporting, the H3 tags aren't properly closed so they're automatically changed, creating nested h3 tags. Because of this, the font size gets increasingly bigger on the page.
What is the new behavior?

Displays the font sizes as intended.
Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

@joelramilison Thanks! glad you caught that missing closing tag!


Clarify tutorial name

Change the title to "Setting up your routes for LiveView" instead of just "Setting up your routes", since the guide is specifically about LiveView.

🚀 Thank you for your contribution! 🚀


Using lazypipe at the end of a stream hangs the Gulp task

If you use lazypipe at the end of a Gulp stream, the task will be properly executed, but it never finishes. If you run this task standalone this is not problematic; you will just not get the message on the comand line that the task finished. However if the task is used in a series it will cause depending tasks to wait forever.
Example code:
var lazy = lazypipe()
    .pipe(uglify)
    .pipe(gulp.dest(destination));

function task() {
    return gulp
        .src(glob)
        .pip(lazy());
}

At first sight it seems related to #7, but there's actually something different going on.
I tracked the problem down to stream-combiner not firing a finish event and it seems that Gulp relies on that event.
I opened an issue on the stream-combiner GitHub page:
https://github.com/dominictarr/stream-combiner/issues/13
I guess you shouldn't have to change anything to your code, but you might want to follow up on that issue, so that you can update your dependencies when the issue gets fixed.

If your code above is correct, the issue is that you have set your gulp.dest up incorrectly.  You cannot pass initialized pipe functions into a lazypipe, because it instantiates them when you call it.
Your sample code, instead, should be:
var lazy = lazypipe()
    .pipe(uglify)
    .pipe(gulp.dest, destination);

If that's not the issue, then it still doesn't make much sense, because events such as finish are passed through from the originating stream.  I'm using lazypipe throughout a massive gulp build system, and if there were any issue with finish events, I would have come across it at some point.
You need to make an absolute minimal case example (I recommend a very simple gulp plugin, such as gulp-debug) to test this issue.

Sorry about the botched sample code; wrote that of the top of my head as a minimal version of the actual code, hence the mistake.
Here's a fully working sample that reproduces the behaviour:
var gulp = require('gulp'),
    debug = require('gulp-debug'),
    lazypipe = require('lazypipe');

var lazydest = lazypipe()
    .pipe(debug)
    .pipe(gulp.dest, './build');

gulp.task('test', function () {
    return gulp
        .src('./src/app/**/*.*')
        .pipe(lazydest());
});

The files from ./src/app/ are copied as expected, but the test task never finishes.
Remove the .pipe(debug) line and the task finishes as expected.
As I said: the problem actually lies with stream-combiner not firing a finish event. I posted a minimal example over there as well, but using just stream-combiner itself. If anything that sample is even more minimal since it uses only through2. The owner of the repo told me to use bun instead of stream-combiner. Still need to look into that.
I should also mention that I'm running this with Gulp 4 instead of Gulp 3, but I don't see how that would change anything.

Hmm, Gulp 4 might break something, I haven't even begun looking at it (since they took so long getting there).
I'm sorry it's giving you trouble, if I get time, I'll look into bun, but I've had trouble with other stream-combiner replacements in the past, and I'm really busy with work right now.

Did some testing and it seems that there is indeed a difference between Gulp 3 and Gulp 4 and - more importantly - that it might not be related to the finish event after all.
Running the two minimal examples with Gulp 3 I get the following results:

stream-combiner-only case: same as with Gulp 4, meaning the combined stream doesn't fire a finish event
lazypipe case: works as expected

This must mean that the cause for the Gulp task not finishing is not the lack of a finish event. Back to square one :(
For reference, here's the complete stream-combiner-only case in a Gulp pipeline:
var combiner = require('stream-combiner'),
    through = require('through2');

var stream = combiner(
    through.obj(pass).on('finish', log('inner stream 1')),
    through.obj(pass).on('finish', log('inner stream 2'))
).on('finish', log('combined stream'));

function pass(file, enc, cb) {
    cb(null, file);
}

function log(id) {
    return function() {
        console.log('FINISH: ' + id);
    }
}

gulp.task('test', function () {
    return gulp
        .src('./src/app/**/*.*')
        .pipe(stream);
});

Note that I used through2 for the test because that's what gulp.dest uses too, both in Gulp 3 and Gulp 4.
Dominic suggested that stream-combiner is not really compatible with stream2, but nevertheless that doesn't seem to be the cause.

I switched to stream-combiner2 in the example @RIAstar posted and it seemed to properly finish the task.  Based on that fact I went ahead and created a PR updated lazypipe to use stream-combiner2 and it seemed to have fixed my problem with streams composed of lazypipes in gulp not emitting finish events.

I can confirm same problem using gulp#4.0, fixed using stream-combiner2.

I'm encountering the same problem. gulp.dest() doesn't work when inside of lazypipe.
Using gulp 3.9.0
example
function writeToDevDir() {
  return lazypipe()
    .pipe(gulp.dest, './dev')();
}

gulp.task('write', function() {
  gulp.src('**/*.js')
    .pipe(writeToDevDir()); //nothing gets written
}).

So i understand that for this moment gulp 4 and lazypipe are incompatible?

As of now, I have no intention of making lazypipe work on Gulp 4.

For anyone looking, there are some simple workarounds listed here.

Is there any fixes for this issue?

No, sorry, Gulp 4 isn't even on my radar. I have no plans on supporting it, probably ever.
I get the feeling they don't care too much, either, as it's still not officially released, and it's been over four years since I first heard about the new-and-improved Gulp 4 which would include support for various features I've worked around in Gulp 3 (i.e., run-sequence).
I'd be willing to look into a PR if someone else wants to tackle it, but only one that doesn't break existing Gulp 3 functionality, or require major changes to how the code works. I've had trouble in the past with people replacing stream-combiner with another stream combining tool, that broke things in subtle ways.
Alternatively, there's nothing wrong with forking this project, or looking into one of the alternative forks. This one looks like a good option.

@OverZealous: Hm, lazypipe2 seems to be already removed from GitHub.
The whole nodejs build stuff changes far too fast and is very brittle.

@strarsis That's too bad. It wasn't my project, so there's nothing I can do. Looks like they removed it from npm, but you can still find it if you look directly, maybe you can use that as a starting point for a fork.


feature request - Support YouTube Music

This tweak doesn't seem to support the YouTube Music app (https://play.google.com/store/apps/details?id=com.google.android.apps.youtube.music). It would be great if it did. The YouTube Music app is pretty similar to the regular YouTube app functionality-wise, but I'd prefer to use it since the interface is better for listening to music.

The app is only displaying an information that the YouTube Music service is not available in my country atm.
So, I have no easy possibility to test it .


Closes #32

There's things that prolly could be improved but I'm dumb
Basically this renders the text :D

Requesting review because I am stinky


Object spreading a Record<string, any> gives wrong type

TypeScript Version:  3.4.0-dev.20190322
Search Terms:
object spread, Record, index signature
Code
const fn = (a: Record<string, any>) => {
  const obj = { p: 1, ...a };

  obj.foo; // ts-error: Property 'foo' does not exist on type '{ p: number; }'
};

const fn2 = (a: { [_: string]: any }) => {
  const obj = { p: 1, ...a };

  obj.foo; // ts-error: Property 'foo' does not exist on type '{ p: number; }'
};

Expected behavior:
obj has type {p: number} & Record<string, any>.
This matches how typescript handles Object.assign.
Actual behavior:
Type of object-spreaded thing is ignored.
Playground Link:
link
Related Issues:

This is a duplicate of #27273


Add OASA Telematics greek public transport sensor component

Description:
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#8978
Example entry for configuration.yaml (if applicable):
sensor:
  - platform: oasa_telematics
    route_id: '090006'
    stop_id: '1965'

Checklist:

[X] The code change is tested and works locally.
[X] Local tests pass with tox. Your PR cannot be merged unless tests pass
[X] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[X] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[X] New dependencies have been added to the REQUIREMENTS variable (example).
[X] New dependencies are only imported inside functions that use them (example).
[X] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[X] New files were added to .coveragerc.

Reopened because I messed up the previous PR. Apologies for that

Hi!
If you want take a look of my implementation of this because it seems simpler using coordinates:
https://gist.github.com/bkbilly/ee250990228f1acb3673b1b1d06574bb

Hi @bkbilly, thanks that's interesting! However, I use a different approach. I find it simpler (and more useful) to get the upcoming arrivals for a given bus stop, mimicking the way the real bus stop displays work. Nonetheless we could definitely add the actual bus coordinates as a different mode.

@MartinHjelmare This sensor fetches the next bus arrival (in minutes) of a given bus line to a given bus stop.
The estimated arrival time is what we poll the api for, but I agree that next_departure should be added. If we are only interested in next_departure, that's a different implementation.
due_in is the estimated arrival time (in minutes) of the bus to the stop, and next_arrival is the second next estimated arrival time (of the next bus in line heading to the stop). I will rename these for clarification.

Isn't departure more interesting than arrival, if this will be used to know what bus to catch? I'm thinking we could replace arrival with departure. But I'll leave this up to you. Thanks for clarifying the context.

Can be merged when the merge conflict is solved and the build passes.

Thanks for the feedback @MartinHjelmare


Userinfo encryption also with EC

bandit fails but it's not caused by your commit by this
https://github.com/italia/spid-cie-oidc-django/actions/runs/4491139564/jobs/7899177102?pr=255#step:11:27
httpc_params contains the timeout, but the static check of bandit doesn't get it. I'll patch it asap


WIP [DEVOPS-13]  launcher:  generalised substitution of env vars

This fixes the ad-hoc, custom variable substitution during cardano-launcher's parsing of launcher-config.yaml.

Closed in favor of a better-named branch: https://github.com/input-output-hk/cardano-sl/pull/2738


Support separate test/train data layers

Created by: brollb
Models should support different training/testing data transformations

Created by: brollb
We actually may not need to support this (at least not the same way). Rather than supporting separate phases in the single network prototxt file, we could simply add the architecture to the created models and then allow the user to change some layers (such as loss functions)


.NET MAUI

Type of issue
Typo
Description
[Enter feedback here]
Page URL
https://learn.microsoft.com/en-us/dotnet/communitytoolkit/maui/
Content source URL
https://github.com/MicrosoftDocs/CommunityToolkit/blob/main/docs/maui/index.md
Document Version Independent Id
f2fb5332-4c1b-fc63-1be9-9032440ff424
Article author
@bijington
Metadata

ID: f2fb5332-4c1b-fc63-1be9-9032440ff424
Service: dotnet-communitytoolkit
Sub-service: dotnet-maui-community-toolkit

@Vmostr what exactly is the issue?

No response for a long time so assuming this issue has been resolved, thank you!


Run the Employee Onboarding Sample Scenario

Tutorial URL: https://developers.sap.com/tutorials/cp-starter-ibpm-employeeonboarding-5-run.html
Please specify the step you are referring to: Step 6: Continue with the workflow execution
Change of screenshot
Expected: Reserved status is Medium

Actual: Reserved status is Ready

Regards,
Nidhi
--

Hello Nidhi, noted. this is very minor. will update this up in next major update.
@thecodester - close the issue.

Screenshot changed!


Edit Endpoint form loads too slow with many findings

Problem description
The Edit Endpoint form includes the Findings field that increases in size unlimitedly with increasing the number of findings in the related project.
Steps to reproduce

Create a project.
Create 100500 findings.
Create an endpoint.
Click Edit Endpoint.

Actual result
The page takes a very long time to load. The form includes the Findings field that is a drop-down list with 100500 items.
Expected result
The page loads fast. There is no such big and useless field.
Root cause
https://github.com/DefectDojo/django-DefectDojo/blob/2234848f02f243b5250894fccb6fc05ccaa1bc0d/dojo/forms.py#L1587-L1588
Possible solution 1
Just remove the Findings field from the form. A user can go to a finding and set an endpoint there instead.
diff --git a/dojo/forms.py b/dojo/forms.py
--- a/dojo/forms.py	(revision 52d3a67ad4fca76f299395bfc76371d2ee2d136f)
+++ b/dojo/forms.py	(revision a3a2d4da73c10bed56ddde439a5278e97acc12b1)
@@ -1578,7 +1578,7 @@
 class EditEndpointForm(forms.ModelForm):
     class Meta:
         model = Endpoint
-        exclude = ['product', 'inherited_tags']
+        exclude = ['product', 'inherited_tags', 'findings']

     def __init__(self, *args, **kwargs):
         self.product = None
@@ -1588,8 +1588,6 @@
             self.endpoint_instance = kwargs.pop('instance')
             self.product = self.endpoint_instance.product
             product_id = self.endpoint_instance.product.pk
-            findings = Finding.objects.filter(test__engagement__product__id=product_id)
-            self.fields["findings"].queryset = findings

     def clean(self):

Possible solution 2
Do not preload the full list of findings. Instead, use AJAX queries that fetch limited number of findings. On the form use a drop-down list with search box that fetches limited number of matching items after inputting several characters.

@AndreyMZ TBH, your "Solution 1" makes sense to me - are you willing to create a PR to get that done?
Info on creating PRs here is at https://github.com/DefectDojo/django-DefectDojo/blob/master/readme-docs/CONTRIBUTING.md


Automatic lookup of R executable should prepend instead of append the path of the which result

The function looking up the R executable to use at the moment may lead to unexpected selection of the appropriate executable to use. I think that a better lookup is required.

I am going to replace the whole logic with a different lookup strategy that uses the install paths. Now, the problem is that, while it seems to me that multiple R version can coexist and run on windows and linux, and can be invoked in an isolated fashion, on macos the change is global and affects everything. This is because there can only be one version active and linked with the Current entry in R.framework.
For now, I am going to attack the problem in a pragmatic way. Environments will still be associated with a given executable (and we can't do otherwise, or we start mixing libraries compiled with different executables) and the discovery when we init an environment will still attempt to find the R executable path, and then eventually fall back to whatever "which R" returns. however:

I added a check to ensure that, at startup, the environment will be checked to match against the invoking R.
I rewrote the lookup search to use the highest available version of R. We'll have to add a selector in environment init to be able to specify which R we want to use, but that will be part of a subsequent PR. At the moment, environment init still accepts the raw R path if all else fails (e.g. we have R in non-standard paths)


Paste handler classifies font-weight 500 as bold, though it should be normal

Do you want to request a feature or report a bug?
I want to report a bug
What is the current behavior?
When you copy text with font-weight: 500, the draftJS paste handler applies a bold tag to the pasted text.
This is the result of the following lines in this file:
// https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight
const boldValues = ['bold', 'bolder', '500', '600', '700', '800', '900'];
const notBoldValues = ['light', 'lighter', '100', '200', '300', '400'];

What is the expected behavior?
But the mozilla documentation says the following:

This means that for fonts that provide only normal and bold, 100-500 are normal, and 600-900 are bold.

Which puts font-weight 500 in the normal category, not the bold category.

According to those mozilla docs, what you're quoting is just the fallback behavior for fonts that do not support more than "normal" and "bold" (and from what I understand this is specific to Firefox).
Other browsers / fonts that support more weights correctly render 500 as something heavier/thicker than normal text ("medium"), so it seems sensible to put it in the bold category. It would be strange to treat 500 values as not-bold just because some browsers/fonts do not support that granularity.

Hmm, there are definitely quite a few sites (including the one I run) that use 500 as their normal body font, and additionally have a bold tag that uses 700 or higher. Copying from these sites results in everything being bolded.
I don't know of any sites that use 500 as their bold font-weight, which would strike me as a pretty weird decision. And given the fallback behavior, it seems that firefox also thinks that if you try to translate a font with font-weight 500 to something that doesn't have that level of granularity, which is the problem we are facing here, then 500 should be interpreted as normal font-weight, not bold.

Another datapoint might be that Firefox uses font-weight 500 as a fallback for normal fonts, if the font doesn't have a font-weight of 400. This also suggests that font-weight 500 is more naturally interpreted as normal text.

For another data point, in our fork we made this change because we found 500 to be common and the transition to bold on paste pretty jarring.

Hi @Discordius, thanks for raising this issue. It sounds reasonable what are your thoughts @flarnie  ?

Same as in our app as well - I need to handle this using handlePastedText and actually replace 500 with 400 to avoid having it bold.

I put up a PR with this change:
https://github.com/facebook/draft-js/pull/3068


Error message when renaming unauthorized Tessels is confusing

will create a pull request fixes this next minutes.

Fixed with https://github.com/tessel/t2-cli/pull/367.


Frame locators that contain { visible: true } blow up

When using the in_frame(visible: true) &block style approach, Page Object is incorrectly converting true into 'true'  This is resulting Watir blowing up saying it expects TrueClass or FalseClass.
The code causing the issue is located in PageObject::Platforms::Watir::PageObject#nested_frames:1077
module PageObject
module Platforms
module Watir
class PageObject
def nested_frames(frame_identifiers)
The solution that seems to work is add checks for TrueClass and FalseClass, similar to the line that checks for Integer.

I have a fix, but cannot push a branch.  How do we get access to push a branch and issue a pull request?

I have a fix, but cannot push a branch.  How do we get access to push a branch and issue a pull request?

You need to fork the project, push the change to a new branch on your fork, then make a PR from that.

You need to fork the project, push the change to a new branch on your fork, then make a PR from that.

Issued PR#499.  I attempted to create some tests, but I'm not sure how to mock frames to do so.  The code change itself is straight forward.  If I can get some guidance on how to create iframe tests, I'm happy to add some for this.  I did not see any iframe tests in the repo.

Issued PR#499.  I attempted to create some tests, but I'm not sure how to mock frames to do so.  The code change itself is straight forward.  If I can get some guidance on how to create iframe tests, I'm happy to add some for this.  I did not see any iframe tests in the repo.

PR merged


Unable to sign in

Storage Explorer Version: 1.8.1
Build Number: 20190510.6
Platform/OS:  Windows 10
Architecture: ia32
Regression From:  never tried
Bug Description
Unable to connect to storage account
Steps to Reproduce

Add account and select Azure environment
Click Sign in and enter credentials
Error message stating:   "message": ""ERR_NETWORK_ACCESS_DENIED""

Expected Experience
Successful login
Actual Experience
{
"message": ""ERR_NETWORK_ACCESS_DENIED""
}
Additional Context
same thing I am able to sign and access using my v- id. This issue I am seeing while using ALT account

Hi, sorry that you're having sign in issues. There's some fairly involved steps I'd like you to take to help us diagnose what's going wrong. I know it's a lot, but this is what will help us figure out how to help you. If you have any problems with the below steps let us know and we'll do our best to help you. If you don't have time to do all of these steps, then you can probably ignore the proxy and Fiddler stuff for now, but it's usually easiest to get all of this collected in one go.
Note: these steps are for Windows, let me know if you need them for another OS.
Part 1: Reset Auth/Sign Out of Everything

Open Storage Explorer
Go to "Help" -> "Reset", make sure "Authentication" is selected (you can deselect "Quick Access" if you'd like), click "Reset"
After the reset dialog closes, go to "Edit" -> "Configure Proxy". Enable proxy, set the URL to 'http://localhost' and the port to '8888' (if you already have a proxy, skip this step and ignore all steps related to Fiddler), click "OK"
Close Storage Explorer

Part 2: Setup Fiddler

Install Fiddler from https://www.telerik.com/fiddler (Note: you can put in a fake email when they ask you for one 😋)
Start Fiddler
Go to Tools -> Options
Click on the HTTPS tab
Make sure Capture HTTPS CONNECTs and Decrypt HTTPS traffic are checked
Click on the Actions button
Choose "Trust Root Certificate" and then "Yes" in the next dialog
Click on the Actions button again
Choose “Export Root Certificate to Desktop”
Go to your desktop
Find the FiddlerRootCer file
Double click to open
Go to the "Details" tab
Click "Copy to File…"
In the export wizard choose the following options

Base-64 encoded X.509
For file name, Browse… to C:\Users\<your username\AppData\Roaming\StorageExplorer\certs, and then you can save it as any file name

Close the certificate window

Part 3: Clear Auth Logs

Go to C:\Users<your username>\AppData\Local\Temp\servicehub\logs
Delete Everything

Part 4: Try Signing In!

Open PowerShell
Goto where Storage Explorer is installed, if you installed at the default location you can just do cd 'C:\Program Files (x86)\Microsoft Azure Storage Explorer\'
Execute $env:SERVICEHUBTRACELEVEL="all"
Close as many other running programs as possible (excluding Fiddler and PowerShell)
Start Storage Explorer from PowerShell: .\StorageExplorer.exe
Try signing in, after your issue happens, close Storage Explorer
In Fiddle, in the bottom left where it says "Capturing", click that, and then "File" -> "Save All Sessions", and save the file wherever you'd like

Part 5: Share results with us

Go back to Go to C:\Users\<your username>\AppData\Local\Temp\servicehub\logs
Zip up all of the log files and attach them to a comment on this issue
Do not attach us the file you saved in Part 4!!! If we need that, we'll give you an email to send it to. That type of file can contain some super sensitive information so we do not want you putting it in a public place.

PS: sounds like you work at Microsoft. Feel free to look me up on teams for add'l help as well.

Closing due to lack of response.


Only cleanup ocp/tf-master if its there

This failed if the directory didn't exist

Build FAILURE, see build http://<IP_ADDRESS>:8080/job/dev-tools/234/


Provide a way to get notified if entries are not found when watching

Motivation:
Related #532
Currently, when we try to watch a file that doesn't exist,
the watch API waits until the file is added or timeout happens.
It sometimes makes user difficult to debug because the client cannot distinguish such cases.
Modifications:

Add notify-entry-not-found preference to the watch Prefer header.

https://datatracker.ietf.org/doc/html/rfc7240#section-4

Result:

You can now get notified if the entry doesn't exist when watching.

To-do:

Add the option to client-side

Thanks for reviewing. 😉


[5.5] Safe Bootable Testing Traits ( Non-breaking )

This is an alternate pull request to https://github.com/laravel/framework/pull/18407. This is simply an addition of functionality without breaking the current implementation, but is less clean.
Uses the same principle that Eloquent Models use to boot traits. This allows user defined traits to hook into both the setUp and tearDown methods by defining methods prefixed with setUp and tearDown respectively.

No plans to add this right now.


update most jetbrains casks to include build number

Recently we had to update the casks intellij-idea (https://github.com/caskroom/homebrew-cask/pull/31190) and intellij-idea-ce (https://github.com/caskroom/homebrew-cask/pull/31209), because jetbrains swapped out the 2017.1 with another build.
This commit adds the build number to the version string. The build number is publicly announced at the app casts, for example here for clion: https://data.services.jetbrains.com/products/releases?code=CL&latest=true&type=release

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[ ] The commit message includes the cask’s name and version.

If every one of these Casks uses #{version.before_comma} only in the interpolation, then what is the purpose of the version after the comma?

The purpose of it is being a bit more verbose if a background swap of binaries by jetbrains happens (See linked merge requests in initial comment).
The  #{version.after_comma} could actually be used in the appcast url for example:
https://data.services.jetbrains.com/products/releases?code=AC&build=163.13906.24
instead of
https://data.services.jetbrains.com/products/releases?code=AC&latest=true&type=release
I do not know if the appcast url should contain a version number or not

@leipert are you able to fix the merge conflicts?

done 👍
Do you think, we should update the app cask urls to contain the build number?

Do you think, we should update the app cask urls to contain the build number?

Does the appcast change if the build number is given as a parameter, or does it just show this build number's release notes? It should always change if there is a new version.

It should always change if there is a new version.

Then the cast url should remain as they are

So what do the maintainers think? Do we want do this change or not?

👍
Updated @jcbot to 1.1.0 for automatic updates including build number:
https://github.com/leipert/jetbrains-cask-bot/releases/tag/v1.1.0


Added Garuda Linux to install script

Bug Fixes

[x] Added Garuda to install script, as it is also arch-based

Thank you

Thanks!! @Nereuxofficial


Box height jumping around

I am able to reproduce this right in the examples shown on https://docs.nativebase.io/box.
Height set to 20:

Height set to 19, much smaller!

Height set to 40, okay looks twice that of 20 about

Height set to 30. Huh?? Shorter than 20.

Am I missing something about this property? Shouldn't it be treated as a pixel value?

@stacey-gammon Hey, please have a look at https://docs.nativebase.io/design-tokens this is not a bug it's an intended behaviour. I'm closing this issue feel free to reopen if required.


App crashes if DVC run name not changed after run fails

I tried to set up a run but my input was wrong. Changed my input and it had a command line error that the run name already existed and now the app is crashing

did you click run?

I guess, clicking RUN should disable the run button which will be re-enabled by setting a new name.

the user might not realise that's why its disabled, I would prefer an error message

After (not so) thorough investigation @lauramurgatroyd and I didn't manage to reproduce the error.

This morning I have reproduced this error many times. Here's an example of how you can reproduce it:

Make a small pointcloud with subvolume size 5:

Apply these settings:

You'll get an error message:

Apply these settings and keep run name the same:

Everything crashes!

Note: the reason I get the "Failed to create pointcloud" error is because I am running on a cropped dataset with only 6 slices and the size of my pointcloud is bigger than the size in the slicing direction (i.e. 6)

I did the same and got the same error without the cropped dataset. As you point out in a small mask there may not be any point in the pointcloud. That's what trips the process.


Remove absolute URLs, fix various bugs, add info to PSC usage post

Remove absolute URLs by using post_url + relative URLs
Fix bug that doesn't show year on publication
Remove absolute link attached to main page's image
Add helper python function example for PSC usage

LGTM! thanks for your help~


update to new msprod and mstechnlogy values.

We updated our allow list for ms.prod and ms.technology.
This PR updates the values used in the file metadata section of the docfx.json file.

This fixes almost all the warnings introduced by the new metadata value edits.
The four that remain are for values that were on the list to be requested but weren't added. (Vague language because don't know if I edited the spreadsheet wrong, or if the values were missed by mistake). Either way, the fix for these is the same: I'll file a new request for those values.


Lock contentions in ssleay_rand_bytes() causing severe performance degradation

Hi team,
I want to report a performance issue due to lock contentions in ssleay_rand_bytes() and check if this is a known issue.
Our environment:

32 cpu cores, 128 GB machine
MySQL-5.7.21 with openssl 1.0.2n
512 concurrent mysql client connections
in-memory, cpu-bound workload

Test results:
without openssl: query throughput is ~220K
with openssl (TLSv1.1): query throughput is ~100K
Observations:

With SSL enabled in MySQL, the connection between the mysql client & server is encrypted and every data exchange goes through code like this:

gdb) bt
#0  0x00000000013b8000 in RAND_bytes ()
#1  0x00000000013150d2 in tls1_enc ()
#2  0x000000000131255a in do_ssl3_write ()
#3  0x0000000001312af2 in ssl3_write_bytes ()
#4  0x00000000013219d0 in SSL_write ()
#5  0x00000000012b88a6 in vio_ssl_write (vio=0x7f28b106cca0, buf=0x7f28b10a8ca0 "\001", size=<optimized out>)
    at /mnt/ssd1/mysql-master/vio/viossl.c:225
#6  0x0000000000c179d2 in net_write_raw_loop (count=193, buf=0x7f28b10a8ca0 "\001", net=0x7f28b1029fb8)
    at /mnt/ssd1/mysql-master/sql/net_serv.cc:500
#7  net_write_packet (net=net@entry=0x7f28b1029fb8, packet=0x7f28b10a8ca0 "\001", length=193)
    at /mnt/ssd1/mysql-master/sql/net_serv.cc:639
#8  0x0000000000c17bc3 in net_flush (net=0x7f28b1029fb8) at /mnt/ssd1/mysql-master/sql/net_serv.cc:222
#9  0x0000000000c25838 in net_send_ok (thd=0x7f28b1028800, server_status=server_status@entry=3,
    statement_warn_count=statement_warn_count@entry=0, affected_rows=affected_rows@entry=0, id=id@entry=0, message=message@entry=0x0,
    eof_identifier=eof_identifier@entry=true) at /mnt/ssd1/mysql-master/sql/protocol_classic.cc:369
#10 0x0000000000c259f6 in Protocol_classic::send_eof (this=0x7f28b1029860, server_status=3, statement_warn_count=0)
    at /mnt/ssd1/mysql-master/sql/protocol_classic.cc:668
#11 0x0000000000c7b8bf in THD::send_statement_status (this=this@entry=0x7f28b1028800)
...

perf profiling shows a lot of time is spent in pthread_rwlock and _raw_spin_lock stemming from ssleay_rand_bytes().  [over 50% of sampled perf events].
Looking at the code in ssleay_rand_bytes(), I suppose CRYPTO_w_lock(CRYPTO_LOCK_RAND) and/or CRYPTO_w_lock(CRYPTO_LOCK_RAND2) could be the source of contentions. I believe the lock  variable is always passed in true to the function in our case.
Also looking at the code in tls1_enc(), it appears RAND_bytes(...) is only called for TLSv1.1 and later with explicit IV (and for ciphers with CBC mode). So to further test/confirm the performance degradation is related to the random number functions we re-ran the same test with TLSv1:
Test results:
without openssl: query throughput is ~220K
with openssl (TLSv1.1): query throughput is ~100K
with openssl (TLSv1): query throughput is ~210K
So it does seem the performance degradation is due to severe lock contentions inside ssleay_rand_bytes().
Is the team aware of this or similar performance issue in ssleay_rand_bytes()? If not, can someone have a look at this?
Thanks in advance!
Jack Ng

The random stuff was completely replaced in the upcoming release. Among other things, there is almost zero locking contention.  Closing this issue.

Thanks for the quick response.
Would the redesigned random stuff be in the 1.0.2 release too, or only in 1.1?

It's a new feature, only in new release.

This lock contention isknown about.  CRYPTO_LOCK_RAND is the problem.  As @richsalz wrote, there is a completely new RNG framework in 1.1.1 and special consideration was given to minimising locking.


added µ in plots disappear

imagesc(peaks); axis off equal; colormap hot; colorbar; hold on
sizex=90000; sizey=90000; nx=49; ny=49; pixelx=sizex/nx; pixely=sizey/ny;
if sizex> 30000
  scalebar=10000;
  SBname='10 µm';
elseif sizex> 15000
  scalebar=5000;
  SBname='5 µm';
elseif sizex> 3000
  scalebar=1000;
  SBname='1 µm';
elseif sizex<3000
  scalebar=500;
  SBname='500 nm';
end
SBx = [ nx-(nx*0.1)-(scalebar/pixelx) nx-(nx*0.1)-(scalebar/pixelx) nx-(nx*0.1);
            nx-(nx*0.1) nx-(nx*0.1)-(scalebar/pixelx) nx-(nx*0.1)];
SBy = [ ny-(ny*0.1) ny-(ny*0.1)-(scalebar/pixelx*0.1) ny-(ny*0.1)+(scalebar/pixelx*0.1)
            ny-(ny*0.1) ny-(ny*0.1)+(scalebar/pixelx*0.1) ny-(ny*0.1)-(scalebar/pixelx*0.1)];
plot(SBx,SBy,'LineWidth',3,'Color','w')
text((SBx(1,1)+SBx(2,1))/2,SBy(1,1)+(scalebar/pixelx*0.4),SBname,'Color','w','FontSize',24,'HorizontalAlignment','center')
plot2svg

By adding the µ in the scale the matlab figure looks as it is supposed to be but the exported figure has a large space between the 10 and the m instead of the µ
test2.zip

Thanks for reporting a new issue. Original discussion appeared here: #8

I can confirm this is an issue with the file encoding

the easiest you can do is to replace µ by \mu, using tex format

By the way, when I use your file, the matlab figure that is generated doesn't show µ either, hence it's not a problem of plot2svg but a problem of matlab. I wanted to confirm if this is the same for you, and if so, I will close the issue as it's not plot2svg's fault, but matlab's.
The workaround I mentioned above should fix it anyway

haha right, that works, I could have guessed that.
Only in the matlab figure it has a different font but in the SVG it looks as it should!
Great


about parallel arb

Watching 2 relationship(s) is not sufficient to engage in triangle arbitrage
    "INVESTMENT": {
        "BASE": "BTC",
        "MIN": 0.005,
        "MAX": 0.013,
        "STEP": 0.005
    },

    "TRADING": {
        "ENABLED": true,
        "EXECUTION_STRATEGY": "parallel",
        "EXECUTION_CAP": 3,
        "PROFIT_THRESHOLD": 0.3,
        "AGE_THRESHOLD": 300,
        "WHITELIST": ["BTC", "ETH", "BNB"]
    },

whats wrong with me

This appears to be a bug!
I'll have a fix out soon with some improved logging to help clarify when a config check fails

Please confirm if this issue is resolved

will try :( but loss big, I'm scared

You can run with the same setup with TRADING.ENABLED set to false to simulate a run, but without actually making any trades.

That isss, thank you bmino


Move interpreter info to the right

Move the interpreter selector to the right and remove the A/B experiment

Closing in favor of https://github.com/microsoft/vscode-python/issues/18710


Add request/response example

The current samples use the event driven model which is generally preferred, but it would be great to have an example of how to use the request/response model as well. This could also be combined with webhooks for receiving events.

I would like to work with this please 👍


refactor: use arrow function for short functions

👨💻 Changes proposed

Convert regular functions that could be converted to one line code using arrow functions

✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Thanks for proposing to make changes to this project, your code will be reviewed soon and don't forget to join the community - [Automated]

Thanks for proposing to make changes to this project, your code will be reviewed soon and don't forget to join the community - [Automated]

:tada: This PR is included in version 1.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[protobuf] Build with -fPIC on Linux

Is your feature request related to a problem? Please describe.
I get the follow error when linking static protobuf into a shared library:

/usr/bin/ld: /home/user/vcpkg/installed/x64-linux/lib/libprotobuf.a(arena.cc.o): relocation R_X86_64_TPOFF32 against symbol `_ZN6google8protobuf8internal15ThreadSafeArena13thread_cache_E' can not be used when making a shared object; recompile with -fPIC

It looks like protobuf wasn't built as position independent code. Or am I missing some linker flags required to make it work?
Proposed solution
protobuf should be built as PIC on Linux, so it can be used in shared libraries.
Adding -DCMAKE_POSITION_INDEPENDENT_CODE=ON to protobuf/portfile.cmake seems to work for me. But I'm not sure if this is the right way of doing things.
Describe alternatives you've considered
No response
Additional context
My vcpkg ports version is tag 2023.12.12

Default vcpkg toolchain already adds -fPIC.
https://github.com/microsoft/vcpkg/blob/261dd6831673d3b07e5118261f7e161a21d1a759/scripts/toolchains/linux.cmake#L55

Default vcpkg toolchain already adds -fPIC.
https://github.com/microsoft/vcpkg/blob/261dd6831673d3b07e5118261f7e161a21d1a759/scripts/toolchains/linux.cmake#L55

I just rebuilt protobuf in vcpkg with default options, and it linked without errors. I might have mixed libraries that were compiled earlier... 🥲
Closing this for now, until I find another cause of the issue.
Thank you for answering!


Rocm 1.9: OpenCL 2.0 device side enqueue not working properly

Hi,
I have an up to date ubuntu 16.04.5 LTS running running Rocm 1.9.
Hardware: Supermicro X10SRA-F, Xeon E5-2680V3, Radeon Pro Duo (polaris, gfx803). The GPU (both ASICs) is recognized by clinfo. clinfo shows two GPUs and reports that device side enqueue is supported.
I am developing a multi GPU program that uses OpenCL 2.0 features like device side enqueue. The program runs fine when using the first GPU. If I start the program on the second GPU, clBuildProgram does not return. Instead, the following output is shown:
"Memory access fault by GPU node-1 (Agent handle: 0x1a25cc90) on address 0xa14dfc000. Reason: Page not present or supervisor privilege.
Aborted"
dmesg shows:
[ 1028.966950] Evicting PASID 32768 queues
[ 1028.966974] Evicting PASID 32768 queues
[ 1029.023599] kfd2kgd: update_invalid_user_pages: Failed to get user pages: -14
[ 1029.023622] kfd2kgd: update_invalid_user_pages: Failed to get user pages: -14
[ 1029.023627] kfd2kgd: update_invalid_user_pages: Failed to get user pages: -14
[ 1029.023632] kfd2kgd: update_invalid_user_pages: Failed to get user pages: -14
[ 1029.023636] kfd2kgd: update_invalid_user_pages: Failed to get user pages: -14
[ 1029.023641] kfd2kgd: update_invalid_user_pages: Failed to get user pages: -14
[ 1029.023646] kfd2kgd: update_invalid_user_pages: Failed to get user pages: -14
[ 1029.023783] Restoring PASID 32768 queues
[ 1029.023788] Restoring PASID 32768 queues
[ 1029.449905] Evicting PASID 32768 queues
[ 1029.449922] Evicting PASID 32768 queues
[ 1029.456686] Restoring PASID 32768 queues
[ 1029.456692] Restoring PASID 32768 queues
[ 1094.640268] amdgpu 0000:05:00.0: GPU fault detected: 147 0x0fe24802
[ 1094.640337] amdgpu 0000:05:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00A161FC
[ 1094.640426] amdgpu 0000:05:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x11048002
[ 1094.640539] amdgpu 0000:05:00.0: VM fault (0x02, vmid 8, pasid 32768) at page 10576380, write from 'TC4' (0x54433400) (72)
[ 1094.640684] Evicting PASID 32768 queues
I tried to write a small program to reproduce the problem. That little program works fine on my develop machine which runs OpenSuse and fglrx. It turns out that the test program does not run on Rocm at all.
Could anyone have a look at this?
Greetings!
bug.tar.gz

Please note that OpenCL 2.0 device side enqueue is not yet officially supported in ROCm 1.9.

@b-sumner
OK, I hope this repoducer helps to fix the broken parts. Can you tell me when device side enqueue will work? I need to give advice on which hardware to buy.
I have seen other posts where users asked for dates when certain things will work. It is very hard to convince anybody in a professional environment if there is no time line. I have been telling people that things will work in a few week with the next Rocm release but I was proven wrong repeatedly.

It will be part of the Offical OpenCL 2.0 support,  yes this will help.  We were still finalizing this feature.   The goal is ROCm 2.0. for OpenCL 2.0 support.

@Moading I personally think it would also be interesting to get your feedback on the feature in the single-GPU case while it is in this unofficial/preview state. That might not fit into all of your application use-cases, but I know you've been waiting on this feature for a while.

Hi, I was just wondering if ROCm 2.0 will be the next release? I'm not even asking for a release date...

ROCm 2.0 is our next major release. I believe we will have a 1.9.2 point release before then, but 2.0 is our next major milestone. There won't be a 1.10.

Hi everybody,
I have installed Rocm 2.0 and as far as I can tell, OpenCl 2.0 device side enqueue is still not working. Could someone please try to reproduce the problem with the latest version of Rocm?

I am closing this issue because there is a new ROCm release now. For me this issue is not fixed yet.


[FS] Lock FederationWalletManager during CCTS operations

Prevents wallet updates from happening while the CrossChainTransferStore is using it:

Encapsulates all public wallet manager methods in lock(this.lockObject) { ... }
Adds lock (((FederationWalletManager)this.federationWalletManager).lockObject) { ... } around the CCTS's Synchronize method calls and subsequent code to guarantee that the wallet remains in sync for the duration of the containing method's execution.
To make this all possible the federation wallet manager's lockObject is made internal and made visible to the FederatedPeg feature only:
[assembly: InternalsVisibleTo("Stratis.Bitcoin.Features.FederatedPeg")]

Includes an optimization to avoid locking when receiving block batches devoid of deposits. Also added Guard.Assert to all Synchronize calls to be consistent and not to assume success as we were doing.

I think the idea is sound, ideally it would have been built a bit closer to this.
But there's potential for unnecessary performance hits, so I would see if we can progress without this. If we find any more "concurrency" errors that are ridiculous to debug, lets put it in.
What do you reckon @quantumagi ?
Also the performance hits might be reduced a ton once I start including withdrawals natively (with depositId)

If there are any more concurrency issues then I suggest the only way to know is to give this a spin. It should not be too difficult to judge if things slow down unacceptably. As you said, a lot of optimization is possible - here we are just adding some locks though.

@fassadlr , I would rather have too many locks than too few and as Jordan reported there is no noticeable performance hit following our tests.


Revocation status not displayed correctly in SSLlabs client

Status 3 is not an error, but means both CRL and OSCP is available.

Classic mistake, used = for comparison, but it actually means assingment which always returns true.


Eliminate the compiler warning from PrognosticData_test.

I made a mess of the original PR #309. So, I've closed that, cherry-picked the relevant commit and created this PR instead. The original text of PR #309 follows.

Eliminate the compiler warnings.
Will close https://github.com/nextsimdg/nextsimdg/issues/217

Also, not 100% sure about review a change I wrote the code for….

Also, not 100% sure about review a change I wrote the code for….

Yes, that's strange. But I reviewed the other pull request and wanted to approve it. Only, it didn't actually compile on my machine anymore, as it was asking for Catch2. Hence the rabbit hole of git rebase, and git merge which ended with the original PR consisting of 90 commits instead of one :(
So I think we're fine.


Discontinuities in scipy.special.mathieu_a

Hi, this is to report an issue with scipy.special.mathieu_a, which is likely related to the issue previously reported in #4479. While #4479 reported discontinuities when varying the order n at fixed q, this reports discontinuities when varying the value of q for fixed n.
The following code,
import numpy as np
import matplotlib.pyplot as plt
from scipy.special import mathieu_a, mathieu_b

fig, ax = plt.subplots()
n = 4
qs = qs = np.linspace(600, 1500, 100)
ax.plot(qs, -2*qs+2*(2*n+1)*np.sqrt(qs)-((2*n+1)**2+1)/8, '-c', label = 'Analytical')
ax.plot(qs, mathieu_a(n, qs), '--r', label = 'SciPy')
plt.title('mathieu_a for n=4 over range of q\'s')
plt.legend()
plt.show()

results in the plot

which possesses discontinuities that I think is not expected analytically. For reference, the "large q limit" analytical expression was obtained from DLMF.
(I'm using Python 3.7.7, numpy-1.21.1 and scipy-1.7.1)

I am able to reproduce the bug in master using your code. Can I work on it?

I am able to reproduce the bug in master using your code. Can I work on it?

That would be great! I'm quite new to this (reporting issues on GitHub) but looking at another problem related to the Mathieu functions (https://github.com/scipy/scipy/issues/12267#issuecomment-636347980), I'm thinking that it has something to do with the implementation in Fortran, though I'm not sure.
The wrapper   mathieu_a can be found in
https://github.com/scipy/scipy/blob/f57e5bf577c0d2ac6c611047961269348fd49315/scipy/special/functions.json#L933
which leads to the source .c file:
https://github.com/scipy/scipy/blob/f57e5bf577c0d2ac6c611047961269348fd49315/scipy/special/specfun_wrappers.c#L407
and eventually calls
https://github.com/scipy/scipy/blob/f57e5bf577c0d2ac6c611047961269348fd49315/scipy/special/specfun_wrappers.c#L427
The Fortran source starts here:
https://github.com/scipy/scipy/blob/42e50b42e3bccabf4e8ba9c409ea3a12dfe4a0ac/scipy/special/specfun/specfun.f#L1402
The code in this comment (https://github.com/scipy/scipy/issues/4479#issuecomment-72968958) also seems like a useful reference for this problem.

Yeah. The bug is in Fortran code. I am looking into it.

The problem is with REFINE function called in IF part of CVA2. REFINE starts off with 1.002*A (A is the value computed by CV0) and uses an iterative method. Most probably seems like a numerical issue.

@czgdp1807 Thank you for the fix, I really appreciate it! I'm not too familiar with how REFINE works and how necessary it is to have it, so I don't think I'd be able to give a good assessment of which solution is better, but from the sound of it, it seems like with your second approach, the benefits of REFINE are maintained and the bumps caused by it are avoided, which sounds better than just not using REFINE, assuming that the error reduction due to REFINE is somewhat crucial for most applications.
However, one thing I'd comment on is that the "analytical expression" I used to compare the SciPy result against is just the first few terms of the "large q limit" expression from DLMF, so I'm not sure how reliable it is as a benchmark. I truncated the asymptotic expression at the first term that was a reciprocal in q, i.e. the term with 1/h or 1/sqrt(q) in DLMF expression (this term and following ones were not included). Just doing a quick calculation with my calculator for the 4th order mathieu_a with q = 1000, that term would be about 0.187 (3sf) if I'm not mistaken, which could be numerically significant if it is comparable to the magnitude of the changes you get when you imposed the fix.
In case you're still using the "analytical expression" in my code as a benchmark, I think maybe including one or two more terms in the asymptotic expansion would be safer if you're assessing the quality of the fix based on how much the numerical result deviates from the "analytical" values.

After adding those terms, the bumps are still there in master branch. However, in my diff, those are removed. The secant method is a bit unstable (the one used by REFINE). Combining it with BISECTION_REFINE, removes the discontinuities wherever they are present and if REFINE works correctly for an input then it will keep doing so, since, bisection method just brings A closer to the root which is anyways good for secant method.


ipc_service: open-amp backend may never leave

Describe the bug
In this commit: https://github.com/zephyrproject-rtos/zephyr/commit/7f51907fda2dd30f18d01262f06c175714a9be3f the default priority level of the was set to K_PRIO_COOP(0) instead of K_PRIO_PREEMPT(0).
There are 2 issues with this:

K_PRIO_COOP(0) is the highest available priority in the system. It should rather be K_PRIO_COOP(CONFIG_NUM_COOP_PRIORITIES - 1) by default.
The function rpmsg_virtio_rx_callback that is used from open-amp never leaves the loop as long as it has data to process. So even if the thread level is low enough to allow other threads to run, if it is fed fast enough it would starve the rest of the system as long as it is cooperative thread. We need a k_yield here in the right place when it runs on cooperative level.

To Reproduce
It is enough to continuously send a lot of messages using IPC.
Expected behavior
CPU needs to have a time to process the messages. It is better to postpone the transmission than allow whole program to fail because it cannot process messages and some internal buffers overflows.
Impact
As long as open-amp works on any level of cooperative mode we cannot trust it in current state.

tagging a few people here @arnopo @hubertmis @ahasztag
I think the real problem here is that using the highest cooperative priority here is a mistake. That was introduced back in the days by https://github.com/zephyrproject-rtos/zephyr/commit/001894a1c0f1c0a8d90857134a7627644bdc670c to solve some internal performance issues.

K_PRIO_COOP(0) is the highest available priority in the system. It should rather be K_PRIO_COOP(CONFIG_NUM_COOP_PRIORITIES - 1) by default.

I would really much prefer to have something like K_PRIO_PREEMPT(0) as default value and leave to the user the possibility to move to a cooperative priority if needed using the zephyr,priority DT property.

The function rpmsg_virtio_rx_callback that is used from open-amp never leaves the loop as long as it has data to process. So even if the thread level is low enough to allow other threads to run, if it is fed fast enough it would starve the rest of the system as long as it is cooperative thread. We need a k_yield here in the right place when it runs on cooperative level.

Yes, but this is indeed a consequence of having an higher-than-everything-else thread running, by lowering its priority this problem should disappear, so I don't think that having a k_yield() is needed at all. Also, if the user really needs that, that can be added in the endpoint received callback in the user code.

Yes, but this is indeed a consequence of having an higher-than-everything-else thread running, by lowering its priority this problem should disappear

As long as it is preemptive priority it is ok. As long as it is cooperative priority level it starts to be an issue.

Right. Then it just cannot be cooperative by default. I think that default should be the safe option and then the user may tune it for his application.

tagging a few people here @arnopo @hubertmis @ahasztag
I think the real problem here is that using the highest cooperative priority here is a mistake. That was introduced back in the days by 001894a to solve some internal performance issues.

K_PRIO_COOP(0) is the highest available priority in the system. It should rather be K_PRIO_COOP(CONFIG_NUM_COOP_PRIORITIES - 1) by default.

I would really much prefer to have something like K_PRIO_PREEMPT(0) as default value and leave to the user the possibility to move to a cooperative priority if needed using the zephyr,priority DT property.

The function rpmsg_virtio_rx_callback that is used from open-amp never leaves the loop as long as it has data to process. So even if the thread level is low enough to allow other threads to run, if it is fed fast enough it would starve the rest of the system as long as it is cooperative thread. We need a k_yield here in the right place when it runs on cooperative level.

Yes, but this is indeed a consequence of having an higher-than-everything-else thread running, by lowering its priority this problem should disappear, so I don't think that having a k_yield() is needed at all. Also, if the user really needs that, that can be added in the endpoint received callback in the user code.

Great that the priority was reconsidered. I still recommend to add explicit yield if we expect code might enter a processing loop (which I believe is the case here).

I still recommend to add explicit yield if we expect code might enter a processing loop (which I believe is the case here).

I agree with @carlocaione . I think it's user of this API who should decide if callback should yield or not. Someone could have high priority IPC which should not yield to other tasks.

@pdunaj

Check it quickly - there should be yield as workq uses default config so no_yield is disabled. Lowering the prio should be fine there.

Open-AMP uses modules/lib/open-amp/lib/rpmsg/rpmsg_virtio.c. There is processing function that handles the data in rpmsg_virtio_rx_callback. It is called via the workqueue in our backend. But this function would not leave as long as there is any data to process:
static void rpmsg_virtio_rx_callback(struct virtqueue *vq)
{
	(...)
	rp_hdr = rpmsg_virtio_get_rx_buffer(rvdev, &len, &idx);

	(...)

	while (rp_hdr) {
		(...)
		rp_hdr = rpmsg_virtio_get_rx_buffer(rvdev, &len, &idx);
		(...)
	}

So as long as it is cooperative thread it can starve the system if overloaded with transfer.
Just for testing purposes I was trying to set a k_yield in ept_cb inside ipc_rpmsg_static_varings.c (just not to touch the sources in external modules). Exactly in this point:
static int ept_cb(struct rpmsg_endpoint *ep, void *data, size_t len, uint32_t src, void *priv)
{
	(...)
	if (ept->cb->received) {
		ept->cb->received(data, len, ept->priv);
		k_yield();
	}
	(...)
}

And it worked, but I am not really sure if it is really smart as being inside rpmsg_virtio_rx_callback main loop we keep the mutex locked there.


Cannot import XGboost after compiling xgboost.dll and installing python packages

For bugs or installation issues, please provide the following information.
The more information you provide, the more easily we will be able to offer
help and advice.
Environment info
Operating System: Windows10 64-bit OS
Compiler: TDM-GCC-64
Package used (python/R/jvm/C++): Python
xgboost version used: 0.4
If installing from source, please provide: github
The python version and distribution: Anaconda3
Steps to reproduce
I was following the steps from BowieHsu (https://github.com/dmlc/xgboost/issues/1316) to install xgboost on my laptop. I walked through all the steps in the instruction and it looked all good. I double checked the ~/xgboost/lib/ directory to make sure xgboost.dll was there. Also I saw xgboost-0.4-py3.5.egg-info folder in ~/Anaconda3/Lib/site-packages/ directory. It seems that I have successfully install xgboost. However, when I was trying to import xgboost in Anaconda prompt, I got an error saying "A dynamic link library (DLL) initialization routine failed":
[Anaconda3] C:\Users\sxl>python
Python 3.5.1 |Anaconda 2.5.0 (64-bit)| (default, Jan 29 2016, 15:01:46) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

import xgboost as xgb
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\sxl\Anaconda3\lib\site-packages\xgboost-0.4-py3.5.egg\xgboost__init__.py", line 11, in
from .core import DMatrix, Booster
File "C:\Users\sxl\Anaconda3\lib\site-packages\xgboost-0.4-py3.5.egg\xgboost\core.py", line 112, in
LIB = load_lib()
File "C:\Users\sxl\Anaconda3\lib\site-packages\xgboost-0.4-py3.5.egg\xgboost\core.py", line 106, in load_lib
lib = ctypes.cdll.LoadLibrary(lib_path[0])
File "C:\Users\sxl\Anaconda3\lib\ctypes__init.py", line 425, in LoadLibrary
return self.dlltype(name)
File "C:\Users\sxl\Anaconda3\lib\ctypes__init.py", line 347, in init
self._handle = _dlopen(self._name, mode)
OSError: [WinError 1114] A dynamic link library (DLL) initialization routine failed

Any idea to solve this? Thanks!

Same issue here !

I have the same issue, same versions of everything also. I tried installing an earlier version of TDM-GCC MinGW Compiler (4.8.1) because I read that it was an issue with the recent version. However, it still doesn't work.

Also same issue here, followed the steps by BowieHsu, and also tried https://www.ibm.com/developerworks/community/blogs/jfp/entry/Installing_XGBoost_For_Anaconda_on_Windows?lang=en
with no luck.
Any help would be greatly appreciated!


Status not complete

Seems that the status only post a complete check mark if there is a rule match. Check if that is the case.

This is possibly caused by posting a start_time in the check_run request for completion. Try if that fixes the problem.

 Investigate further to see what happened.


Chrome issue

Not working on Google Chrome.

Not working on Google Chrome.

On other browsers based on Chromium as well.

I will fix it this week

@GiuseppeEliano It's fixed,the demo already updated, but I haven't tested it carefully.

@GiuseppeEliano It's fixed, the demo already updated, but I haven't tested it carefully (only test Windows Chrome 93.0.4577.63)

It's working now for me. Thank you!

@GiuseppeEliano It's fixed, the demo already updated, but I haven't tested it carefully (only test Windows Chrome 93.0.4577.63)

It's working now for me. Thank you!

Update: I found a wrong detection on Chrome for iOS devices, it works just fine on Safari.

@GiuseppeEliano It's fixed, the demo already updated, but I haven't tested it carefully (only test Windows Chrome 93.0.4577.63)

It's working now for me. Thank you!

Update: I found a wrong detection on Chrome for iOS devices, it works just fine on Safari.

Ok, I will fix it later

I will fix it within this week

fixed, please try again

Have you applied the fix on Demo? it does not work on Chrome for iOS


Changed an entry

Changed an entry from "New features" to "Fixed issues".
Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://670f772a5c232c06a2ee60e8--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://670f78adfd38be10f4b4eb2a--harness-developer.netlify.app


[WIP] Refactor pytest fixtures into plugins directory

Note:
The easiest way to look through this PR is to start with the changes to imap_processing/tests/conftest.py then look at new files in the imap_processing/tests/plugins directory. Other changes are changes to Hi tests to use the new fixtures.
Change Summary
Move common and hi fixtures into plugins directory
Add pytest_plugins definition to root conftest.py
Refactor hi test_data structure
Add fixtures for hi test data
Overview
This is a proposal for a refactor of how we organize pytest fixtures. The proposal is that we move away from distributed conftest.py files which I find to be challenging to understand as more and more fixtures are added. This centralizes all fixtures that are not specific to a single test file and organizes them by instrument. Pleas let me know what you think about these changes.
For this WIP PR, I moved common and hi fixtures only to demonstrate what the refactor would look like.
New Dependencies
Non
New Files

imap_processing/tests/plugins/init.py

description of new file 1's purpose

imap_processing/tests/plugins/common_fixtures.py
imap_processing/tests/plugins/hi_fixtures.py

Deleted Files
None, some files were moved
Updated Files

imap_processing/tests/conftest.py

Added definition of pytest_plugins pointing to common tests/plugins files

imap_processing/tests/hi/test_decom.py

Use new fixtures for test data location

imap_processing/tests/hi/test_hi_l1b.py

Use new fixtures for test data location

imap_processing/tests/hi/test_l1a.py

Use new fixtures for test data location

Testing
Many changes to the structure of fixtures

Is there a reason to use plugins specifically? I thought plugins were generally for sharing across packages so other external projects could make use of the fixtures.
I've generally seen this written more as nested conftest.pys, and I think that would also prevent the hi_test_data_path from being available to all tests, and only within hi tests instead. Right now, the plugins are imported in the root conftest.py meaning they will be available to all tests and then the import order likely matters if multiple people define ccsds_header_data differently and want it available to their module tests.

I personally dislike the organization of fixtures into 10 or more different conftest.py files. I find it hard to find fixtures and determine what fixtures are affecting a test, especially for autouse=True fixtures. I also think that it discourages reuse of fixtures because everyone writes their own fixture in their own conftest.py. I do see your point about fixture scope and possible collision of names.
On EMUS, we had some troubles with having different levels of conflicting fixtures which was solved by centralizing all shared fixtures into one main location. Perhaps this is less of a concern for imap_processing because we don't need fixtures to deal with DB connections or AWS resources.

This could just be my personal preference and experience working with nested conftest.py so I prefer that style. It would be good to get others' preferences/opinions too though as I may be skewed.
Here is a good thread explaining some of the nested conftest uses: https://stackoverflow.com/questions/34466027/what-is-conftest-py-for-in-pytest

I personally dislike the organization of fixtures into 10 or more different conftest.py files. I find it hard to find fixtures and determine what fixtures are affecting a test

Using plugins would lead to the same thing though I think, it's just the files are called hi_fixtures in a single root folder rather than conftest.py located in the hi/ directory. I still wouldn't know which plugin file my fixture came from, I could take a guess, but I don't know for sure. This is sort of an unfortunate limitation of using fixtures, that I can't click into them with my IDE to see where the implementation is coming from (or at least I haven't been able to and this seems like it would be tricky to implement).

especially for autouse=True fixtures

I actually think that we should rarely be using autouse=True because I agree with you that it is hard to see what was happening with the action-at-a-distance stuff when this is the case. The exception is with our current autouse fixtures to muck with temporary directories and environment variables where we want those to isolate everyone without needing to think about it.

On EMUS, we had some troubles with having different levels of conflicting fixtures which was solved by centralizing all shared fixtures into one main location. Perhaps this is less of a concern for imap_processing because we don't need fixtures to deal with DB connections or AWS resources.

In our AWS CDK repo, we do split the DB tests into a separate folder from the AWS resources tests, so they have different conftest.py files with different fixtures associated with those.

No, we did something similar to what I did in this PR organizing fixtures by aws, data path, database, and spice fixtures. I grok the organization and scope of conftest.py files but dislike the strict naming requirement and inability to organize fixtures in the case where you have lots of fixtures that need to be at the same level.

Using plugins would lead to the same thing though I think, it's just the files are called hi_fixtures in a single root folder rather than conftest.py located in the hi/ directory. I still wouldn't know which plugin file my fixture came from, I could take a guess, but I don't know for sure.

Being able to determine a unique name for the file that the fixture is in would allow us to follow a convention such as: Each fixture name should start with the name of the file it is located in.

I actually think that we should rarely be using autouse=True because I agree with you that it is hard to see what was happening with the action-at-a-distance stuff when this is the case.

Totally agree with this. There may eventually be a need for one additional autouse=True fixture that handles setting up SPICE depending on all the decisions that we make on how to use SPICE.

Did anyone else review this or give you feedback/preferences? I'd leave this open if you're still looking for other comments.

@greglucas

Did anyone else review this or give you feedback/preferences? I'd leave this open if you're still looking for other comments.

No other feedback was given. I'm going to cherry pick some of the Hi specific changes but keep with the standard use of conftest.py files. If we find a need for clearer fixture organization as our test suite grows, it is an easy change to implement.


Randomly throwing: Error: Forbidden

Some servers can randomly throw "Error: Forbidden" error
root@2361489-cu36924:/home/commune# c block
Connecting to ws://<IP_ADDRESS>:50053
174051
root@2361489-cu36924:/home/commune# c block

<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>403 Forbidden</title>

Error: Forbidden

Your client does not have permission to get URL / from this server.

Connecting to ws://<IP_ADDRESS>:50055
174053

This is only happening on servers based on "RU" location (?). Issue above on same server. I don't have issue on other server locations

Seems a lot of troubles come from ipv6 global ip. Removing ipv6 - solved all 403 Forbidden issues.
Please confirm on your side


Varint support for code and length

Fixes #12
This PR requires multiformats/clj-varint 0.1.1 to be released. Current release (0.1.0) does not include the VarInt class.

closing due to inactivity, archiving repo


Refreshing tests

Coverage decreased (-0.09%) to 99.145% when pulling 76fb74153c2864909da4491841acfd15e1ceb935 on qfox.up-testing into a1412e24e299e061f3870ada5cfd0b2c819b34de on master.


Saved dataURI displays in web, but not in Cordova app (Android)

Tested it as such:
Generate dataUri on website, save to fs. Gets successful url like =
http://localhost:3000/cfs/files/images/xBK5oDtSaDxrz5Dni

And file displays in browser, but when I try to view it in Cordova with
meteor run android-device --verbose --production

I get a broken image every time on the same page as browser which is showing full image.
Tested on Xperia Z3 running Android 5.1.1 (Haven't tried iOS yet)

Sorry, should have been in gridfs :(


Use Envelope in PublishRequest

Writing some publish tests I noticed that I need to transform Envelope into PublishRequest, which seems kinda pointless and arguably inconsistent with the rest of the API which returns Envelopes. We are also losing Envelope.Id which is probably not good either. So I'm proposing to just wrap the Envelope in the PublishRequest instead (do we want to allow collection of them maybe?).

I wouldn't be against taking a collection of Envelopes. Seems like there are plenty of valid cases for publishing multiple messages at once that we shouldn't be blocking at the API level.

This is entirely my fault, since I haven't yet written a README for the proto package, or setup the commitlint. But you'll want to use the same "semantic-release" format for commit messages to trigger new releases for the JS SDK.
I'll fix those issues today.

For publishing, we would expect Envelope.id to be blank, right? Those get generated server side right now, and I'd rather not reproduce the logic in case we get inconsistencies.

This is entirely my fault, since I haven't yet written a README for the proto package, or setup the commitlint. But you'll want to use the same "semantic-release" format for commit messages to trigger new releases for the JS SDK.

I'll squash-rebase to clean up the commit, what should the commit message be in this case? This is a breaking change so should we roll the major number?

Given that the library isn't being used in main of the SDK yet, I think the number doesn't matter much as long as it's incremented at all. But in theory it should be a breaking change.

For publishing, we would expect Envelope.id to be blank, right? Those get generated server side right now, and I'd rather not reproduce the logic in case we get inconsistencies.

Hm, good point. Is this an argument against this change then?

Clients do care about the ID for read APIs (for example, to dedupe messages). Proto fields are optional, so we could just not use it on Publish. If we were to ship this change, I would just make the API we expose to users exclude the field and leave it blank in the API calls.

Hm, looking at the node side it seems the ID is mixed up with the pagingInfo.Cursor.Digest. Isn't that field sufficient for the querying side of things? You wouldn't get it when you stream messages via Subscribe, but you arguably shouldn't need to dedupe in that case, no?

We also want ID on the messages themselves. For example, in the example chat app we dedupe messages between streaming and list API calls using the ID. It's also very helpful in a React context for the key field.

I'm missing parts of the puzzle here, I don't see a way to actually get the stored Id. Relayed messages don't have it at all and HistoryResponse also just has []*WakuMessages and those don't have Id either. So how are we getting it at all?

Maybe it's actually being generated on the client right now via js-waku (which we no longer have)

Looks like it's just generated on the client side https://github.com/xmtp/xmtp-js/blob/main/src/Message.ts#L70-L71. So we should be able to just drop it here right?

In any case, it's going to be challenging to generate consistent IDs on the client now, given that we serialize things so differently.

In any case, it's going to be challenging to generate consistent IDs on the client now, given that we serialize things so differently.

It seems it's generated just from our proto payload so that should remain consistent.

OK, rebased, cleaned up, commit message fixed, GTG?

I guess that means our IDs have always been different from server IDs

I guess that means our IDs have always been different from server IDs

I'm not sure we really have server IDs, they seem to only exist in store.Envelope and get throw away immediately after retrieval from DB. So they don't seem to exist outside of the store subsystem.

LibP2P gossipsub definitely cares about IDs as well. It just calls it Hash in that context.


⚠ GitHub has degraded performance

In c7e2015, GitHub (https://www.githubstatus.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 218 ms

Resolved: GitHub performance has improved in dd8a32a.


Reset search to searchname

the command is still "search".

Seems like check style violation caused the failed checks, may you look into that？Thank you

LGTM

Seems like check style violation caused the failed checks, may you look into that？Thank you

corrected, thx.


Reading parquet files that contain pyarrow extension dtypes

Describe the bug
Calling wr.s3.read_parquet parses the dtype of a column incorrectly when the column data type is a pyarrow extension dtype (or so it seems to me). Note this behavior only happens when calling wr.s3.read_parquet in a new python session (see below for more details).
To Reproduce
python version: 3.8.7
awswrangler version: 2.7.0
We construct a data frame, write it and read it - so far so good
In [1]: import pandas as pd
In [2]: import awswrangler as wr
In [3]: df = pd.DataFrame({"col": ["2010-01"]})
   ...: df["col"] = pd.to_datetime(df["col"]).dt.to_period("M")
In [4]: df.head()
Out[4]:
       col
0  2010-01
In [5]: df.dtypes
Out[5]:
col    period[M]
dtype: object
In [6]: wr.s3.to_parquet(df, "s3://my-s3-bucket/wrangler-test/period.parquet")
{'paths': ['s3://my-s3-bucket/wrangler-test/period.parquet'],
 'partitions_values': {}}
In [7]: wr.s3.read_parquet("s3://my-s3-bucket/wrangler-test/period.parquet")
Out[7]:
       col
0  2010-01

We attempt to read the data frame from a different python session - the same call returns a different output when called again:

In [1]: import awswrangler as wr

In [2]: wr.s3.read_parquet("s3://my-s3-bucket/wrangler-test/period.parquet")
Out[2]:
   col
0  480

In [3]: wr.s3.read_parquet("s3://my-s3-bucket/wrangler-test/period.parquet")
Out[3]:
       col
0  2010-01

I checked version history.  This example works in 2.1.0 and none of the versions since.

Pandas categoricals work.  It's the Pandas Period (and maybe other extension types) that don't.
df["col"] = df["col"].astype("category")

I ran the same tests but with pandas and the pandas Period works fine.
In [1]: import pandas as pd
   ...:
   ...:
   ...: df = pd.DataFrame({"col": ["2010-01"]})
   ...: df["col"] = pd.to_datetime(df["col"]).dt.to_period("M")
   ...: print(df)
   ...: print(df.dtypes)
   ...:
   ...: print(df.to_parquet(f"s3://infima-sandbox/wrangler-test/pandas/period.parquet"))
   ...: print(pd.read_parquet(f"s3://infima-sandbox/wrangler-test/pandas/period.parquet"))
       col
0  2010-01
col    period[M]
dtype: object
None
exit       col
0  2010-01

In [1]: import pandas as pd
   ...: first = pd.read_parquet(f"s3://infima-sandbox/wrangler-test/pandas/period.parquet")
   ...: print(first)
   ...: print(first.dtypes)
   ...: print(pd.read_parquet(f"s3://infima-sandbox/wrangler-test/pandas/period.parquet"))
   ...:
       col
0  2010-01
col    period[M]
dtype: object
       col
0  2010-01

Part of the problem seems to be originated in pyarrow. When trying to read the same file directly via pyarrow int normally reads the datatype as int64. However after doing a to_pandas call once the datatype is ArrowPeriodType(DataType(int64)):
import pyarrow
import pyarrow.parquet

pq_table = pyarrow.parquet.read_table("s3://infima-sandbox/wrangler-test/pandas/period.parquet")
pq_table.schema.types
# Out[6]: [DataType(int64)]

pq_table.to_pandas()
# Out[7]:
#        col
# 0  2010-01

pq_table = pyarrow.parquet.read_table("s3://infima-sandbox/wrangler-test/pandas/period.parquet")
pq_table.schema.types
# Out[9]: [ArrowPeriodType(DataType(int64))]

The reason why awswrangler diverts from the output of pyarrow in the first call is that it uses ignore_metadata=True (https://github.com/awslabs/aws-data-wrangler/blob/main/awswrangler/s3/_read_parquet.py#L264). But maybe we could exhibit this parameter as a kwarg for read_parquet. What do you think about it?

I can confirm that this seems to be a pyarrow issue, specifically with the to_pandas method. I will have to raise it directly with the arrow team.
@maxispeicher Setting ignore_metadata=False was not enough for me to avoid the behaviour though, I also had to set types_mapper=None  to get it to work.
The obscure part for me is why is the pyarrow read parquet file operation not idempotent? I don't see what is causing that operation to interpret the type as int64 the first time, but then suddenly consider it a period on the second call?

@jaidisido Yeah you're right I've also changed types_mappers to None for getting it to work.
But pyarrow's behavior is really strange. I also don't quite understand what's going on 🤷.


Loco gets launched when power is applied!

Ok, I know this is pretty vague. I'm by no means a novice when it comes to wiremod or trainbuild, but this one has me stumped. Since the latest build of OC with default chip settings, this is exactly what happens. I know I have everything wired properly; it's pretty self-explanatory and inputs and outputs match. I have edited nothing. I have not parented the DE processor chip. I have an older build of OC that works fine with the loco i have placed it on, but the newer build has been giving me trouble.
I noticed that the direction the loco is being forced in seems to be to the side rather than forward or backwards, so i thought maybe it had to do with the model and the way the model's directional facing was. So, I tried another model I knew faced a different direction by default. Nothing changed.
As I said, this one has me stumped. Would really appreciate any help or feedback on this issue.

This is due to a NaN value bug, usually happens when dividing a valve by 0 (eg, 0 divided by 0 is Not a number).
OpenControl is now Deprecated.
Not further action will be taken, closing.

This is due to a NaN value bug, usually happens when dividing a valve by 0 (eg, 0 divided by 0 is Not a number).
OpenControl is now Deprecated.
Not further action will be taken, closing.

Thank you for your response. I'm sorry to hear there will be no further
development, but I wish you well and look forward to your future projects.
Keep up the great work you do!
On Fri, Dec 31, 2021 at 8:40 PM TitusDoggo @.***> wrote:

This is due to a NaN value bug, usually happens when dividing a valve by 0
(eg, 0 divided by 0 is Not a number).
OpenControl is now Deprecated.
Not further action will be taken, closing.
—
Reply to this email directly, view it on GitHub
https://github.com/TitusStudiosMediaGroup/OpenControl/issues/1#issuecomment-1003482035,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI7WMYUSV5MYPFFVOUEEMTUTZLQDANCNFSM5K7S5QVA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Regards,
Bryson Grondin

Thank you for your response. I'm sorry to hear there will be no further
development, but I wish you well and look forward to your future projects.
Keep up the great work you do!
On Fri, Dec 31, 2021 at 8:40 PM TitusDoggo @.***> wrote:

This is due to a NaN value bug, usually happens when dividing a valve by 0
(eg, 0 divided by 0 is Not a number).
OpenControl is now Deprecated.
Not further action will be taken, closing.
—
Reply to this email directly, view it on GitHub
https://github.com/TitusStudiosMediaGroup/OpenControl/issues/1#issuecomment-1003482035,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI7WMYUSV5MYPFFVOUEEMTUTZLQDANCNFSM5K7S5QVA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Regards,
Bryson Grondin


Unified Ui

Jira issue:
https://glia.atlassian.net/browse/MOB-1547

@dukhovnyi All commits to this branch were reviewed before merging, so this PR is ready to merge.

@dukhovnyi it seems your force push has broken the unified_ui branch, and a lot of changed files disappeared.

As this branch is broken, moved everything to PR #413


Improve launch.json examples

Previously, a project created by "dotnet new" and opened in VS Code was unable to debug.  Specifically, when the debugger was started, a new browser window would open "about:blank, wait for 30 seconds, and then close.  The issue was that:

The launchSettings.json generated by the "dotnet new" command uses a random port number.
The launch.json file generated by VS Code omits the "url" parameter (the default value is "https://localhost:5001").
The fix is to add the "url" parameter to launch.json.

Also, I merged the "Example launch configurations" section with the relevant steps above.  This makes it easier for users to find the appropriate config, as well as simplifying long-term maintenance of the documentation.

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

Moved to https://github.com/dotnet/AspNetCore.Docs/issues/24479.

Thanks @knumat ... Let's take this up on an issue at #24479 first. Updates introduced directly by a PR are only a regular approach when the change is a patch update. I'll (and possibly the product unit engineers) need to take a closer look at the proposed changes. We'll need up to a week to dig out ⛏⛰ ... I'll ping u on the issue ASAP. Thanks again!

@knumat ... Thanks for sending the updates. This will go live within 24 hour or so.


Skeleton KwikModel

Model class to access, write, open, save and store in-memory structures using the Kwik format.
Closes #59.

Coverage decreased (-0.45%) to 94.61% when pulling 24c99eba85b9b7762310f8611b12dc764e946244 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.45%) to 94.61% when pulling 24c99eba85b9b7762310f8611b12dc764e946244 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.44%) to 94.61% when pulling 98225f1971c75a4cd73764a963b5abfc15236bab on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.42%) to 94.63% when pulling 515de87b185f66c3f8d09e1829bd32983f1e80af on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.42%) to 94.64% when pulling a2643672475f85da76e7e2818ef0c374028e5838 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.42%) to 94.64% when pulling a2643672475f85da76e7e2818ef0c374028e5838 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.84%) to 94.22% when pulling 3d1c80dd235f1cdadd92e8286fe91bec979effd2 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.53%) to 94.52% when pulling c44a9095500dad5348010181ca1969d58e574426 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.53%) to 94.52% when pulling c44a9095500dad5348010181ca1969d58e574426 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.47%) to 94.59% when pulling 225e42bc5bec78d1e63e27c4786617a8eb63e88b on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.54%) to 94.52% when pulling 029979bf68d11eb2153ce82763ecc9919f7265fa on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.66%) to 94.4% when pulling d0b87735cf90a5c840430f4eb2759630d73f883a on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.82%) to 94.24% when pulling 3e9f60e75005f98e5e11c5550d6204de8fc345c0 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.68%) to 94.38% when pulling ef42ebc859d23372cb252fd78e8ce17d90655dbb on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.72%) to 94.34% when pulling 82fbf40bd5070e4d003772fd0e96aeef8c9a1bdc on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage decreased (-0.72%) to 94.34% when pulling 74b5cd92d122e9a6d2026c8e7227b1aa4acc6707 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

TODO:

float32/int16 waveforms
fix spiketimes[0] edge effects

Coverage increased (+0.17%) to 95.22% when pulling 5a62101f4df85cdff6edd0f3045eb8a10cc9e24e on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage increased (+0.17%) to 95.22% when pulling 5a62101f4df85cdff6edd0f3045eb8a10cc9e24e on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

Coverage increased (+0.39%) to 95.45% when pulling 0425cf89bfd31f086a52debfd8502970cac0ec50 on nippoo:max_kwikmodel into 6ad001722757d9d23f3a79a679a396717443b174 on kwikteam:master.

@nippoo this is ready for review and merge. This PR implements a first working KwikModel that supports features + masks from KWX and waveforms from KWD.


ReferenceMany with repositoryMethod and eagerCursor causes fatal error

When using referenceMany in combination with repositoryMethod, returning an eagerCursor instead of a regular cursor results in a fatal error in Doctrine\ODM\MongoDB\Persisters \DocumentPersister::createReferenceManyWithRepositoryMethodCursor. This is because the eagerCursor does not support sort(), limit() or skip(). As such, repositoryMethods may not return eager cursors. There are two possibilities:

have the DocumentPersister unwrap the original cursor from the EagerCursor object and apply sort, limit and skip to that.
Have Doctrine\ODM\MongoDB\EagerCursor support sorting out of the box by wrapping the original methods from Doctrine\ODM\MongoDB\Cursor. Note: this may depend on doctrine/mongodb#208.

I can provide a PR for both - just need to know what the better course of action is.

Option number 1 seems to be good quickfix for the case.
As for 2nd option I'd additionally consider some common interface for these two to have something to rely on :)

Sounds good. I have a working draft prepared, I'll clean it up, add tests and push it in the coming days.

:+1:

#1049 has been merged


Fix renaming in MANIFEST.in

Installing it now actually works

Ah thanks! I was working on it in preparation for something but haven't yet used it, might be the reason i haven't run into this issue (yet). I'm sorry it didn't work.
I've made plans to improve this module and integrate it into a Django app starting next month, if there's something you'd like to see please tell me so i can see whether it fits in the planning :)

No problem, I just wanted to upgrade my website to Python 3 and I couldn't get your fork to actually install the needed files. So I tried to figure out what was wrong and found this. I don't need anything added, the old mollie one worked fine on Python 2.


Can't reproduce the training log of Resnet18 for CIFAR10[Bug]

Describe the bug
As this log shows,  after 20 epochs, the loss should be reduced to 0.2.
And I tried to train ResNet18 with below cmd:
python .\tools\train.py .\configs\resnet\resnet18_8xb16_cifar10.py
Here is my training log:
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] 10000/10000, 2227.6 task/s, elapsed: 4s, ETA:     0s2022-09-05 18:26:37,203 - mmcls - INFO - Epoch(val) [68][625] accuracy_top-1: 83.7200, accuracy_top-5: 99.1100
2022-09-05 18:26:41,316 - mmcls - INFO - Epoch [69][100/3125]   lr: 1.000e-01, eta: 2:25:58, time: 0.041, data_time: 0.020, memory: 252, loss: 0.4175
2022-09-05 18:26:43,407 - mmcls - INFO - Epoch [69][200/3125]   lr: 1.000e-01, eta: 2:25:56, time: 0.021, data_time: 0.000, memory: 252, loss: 0.4350
2022-09-05 18:26:45,536 - mmcls - INFO - Epoch [69][300/3125]   lr: 1.000e-01, eta: 2:25:54, time: 0.021, data_time: 0.000, memory: 252, loss: 0.4165
That's way far from the 0.2 loss.
To Reproduce
The command you executed.
python .\tools\train.py .\configs\resnet\resnet18_8xb16_cifar10.py

this log is trained by using 8 GPUS, If you train in a single GPU, the log should be different.

I don't get it. Will 8 GPUs backward 7 more times than a single GPU?

No! But you can try to scale your batch_size

Ok, I will try bs128.

bs=128 1GPU produced a similar result. Thanks!


[BUG] Bot should be keeping a 0.91 iv Magikarp, but transfers it instead with the correct rules.

Expected Behavior
Keep the magikarp
Actual Behavior
Trashing the Magikarp
Steps to Reproduce
use the latest commit as of posting this.
Other Information
[x] Captured Magikarp! [CP 26] [IV 0.91] - Checking Release Config
[x] Release config for Magikarp: CP 800 or IV 0.8
[#] Magikarp has been exchanged for candy!
{
"any": {
"min_cp": 800,
"min_iv": 0.8,
"cp_iv_logic": "or"
},

If you want to keep a high IV pokemon with low CP you have to use cp_iv_logic = and.
For your config the magickarp would have been kept if it also had >800 cp.
With cp_iv_logic = or the pokemon is released if one of the conditions is met, so in your case the magikarps cp was below 800.

Hmm,
from looking at it I thought "cp_iv_logic": "or" would mean either of them.
So it would keep the pokemon if it was either higher then 800 cp OR higher then 0.8 iv, 1 of the 2.

Nope, it's a release logic, not keeping logic. @DanielHeckrath is right.

Alright, Thanks for the clarity, will change it. Close the Issue if you want. :)

So if I write -
"release_under_cp": 2500,
"release_under_iv": 0.95,
"cp_iv_logic": "and"
It will keep only high IV Pokémon and release all others no matter their CP right?
(unless I manage to find a Pokémon with 2500+ CP yes :P)


Context handling improvement

Fixes #75
Fixes #74

Yeah, I did try to implement something smart but was unsure as it leave some unknowns.
I've fixed your findings, please have a look


Cannot install from git but can install with pip install -e .

If I clone and do pip install -e . from the sheetload folder then call sheetload --version all seems good.
If I install from git
pip install git+ssh://git<EMAIL_ADDRESS>I run into this error:
Traceback (most recent call last):
  File<EMAIL_ADDRESS>line 11, in <module>
    load_entry_point('sheetload==1.0.0rc3', 'console_scripts', 'sheetload')()
  File<EMAIL_ADDRESS>line 480, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File<EMAIL_ADDRESS>line 2693, in load_entry_point
    return ep.load()
  File<EMAIL_ADDRESS>line 2324, in load
    return self.resolve()
  File<EMAIL_ADDRESS>line 2330, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
ModuleNotFoundError: No module named 'sheetload'

No goddamn idea what the issue is...

Maybe add py_modules=['sheetload'] to your setup.py?


Allow choosing the address of the "server"

Defaults to localhost; I added a button to switch to Thing3.
I don't know what port Thing3 will use, or what IP address/hostname it has. (@rye?)
Closes #17

@hawkrives thing3 has 80 open to use currently, I'd be fine with deploying just there for now.

@rye I have changed to port 80


Update scalafmt-core to 3.5.3

Updates org.scalameta:scalafmt-core from 3.5.2 to 3.5.3.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (3.5.2).
You might want to review and update them manually.
docs/src/adr/006rfc-unit-testing.md

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequest = { frequency = "@monthly" },
  dependency = { groupId = "org.scalameta", artifactId = "scalafmt-core" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Codecov Report

Merging #1754 (1c1bd9b) into unstable (b3656d0) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           unstable    #1754   +/-   ##
=========================================
  Coverage     76.68%   76.68%
=========================================
  Files           376      376
  Lines         11763    11763
  Branches        525      544   +19
=========================================
  Hits           9020     9020
  Misses         2743     2743

Continue to review full report at Codecov.

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


Finish adding network pages to Remix app

@aureentuluvacal Is this still in progress? Hit "ready for review" if not.


Dev Build: Empty/Unkown Pokestops Spin

Expected Behavior
Collect from pokestop and continue to walk.
Actual Behavior
Goes to few pokestops, works fine, after a while shows this and continues doing that until I restart.
Steps to Reproduce
One way to fix is to keep restarting the bot every five minutes  which can be super annoying or just wait for a fix.
Other Information
OS: Windows 10 B4-bit
Git Commit: 8462fb2a699b1c46e166d7917b0d59cc244264ec

The login token has expired, in newer commits this should be addressed, try git pull or redownload from github.

Please upgrade to the latest dev branch by running this command:
git reset --hard
git pull -f

Then run this command:
pip install --upgrade -r requirements.txt
If issue persists, open a new issue.
/closed