OpenCover doesn't reliably work with nunit with (current) default parameters

I have investigated an odd functionality, in which, some assemblies tested by nunit via opencover got and other didn't get their coverage computed.
The ones for which coverage wasn't computed, it seems that it is due to "MissingPdb". At the end of the OpenCover run phase, it was printing:
Committing...
No results - no assemblies that matched the supplied filter were instrumented
    this could be due to missing PDBs for the assemblies that match the filter
    please review the output file and refer to the Usage guide (Usage.rtf)

Now, it seems there were other people that encountered this situation [0], [1], [2], [3](some issues opened on OpenCover's side).
I've tested with multiple options and we need to do the following:

Add the -oldstyle flag for OpenCover - this affects only the way the analysis is done (this flag doesn't support Silverlight apps, but I think we don't care for that. Anyway, we can put that as a configuration on the opencover plugin to allow opt-in for it)
One of the two:

Provide the /noshadow argument to NUnit (this is a bit more cumbersome to do I think)
Properly set the /targetdir parameter for OpenCover to point to the build directories of the test assemblies, not the build directory for the gradle project (e.g: instead of root/build use root/test/bin/Release

I will do the fix, after we agree which way we should take :)
[0] - http://w3facility.org/question/nunit-tests-failing-within-opencover/
[1] - https://github.com/OpenCover/opencover/issues/119
[2] - https://github.com/OpenCover/opencover/issues/88
[3] - https://github.com/OpenCover/opencover/issues/259

Given this the dll folder is (logically if you ask me) the first place opencover looks for the pdb file.
Now as far as I understood, NUnit (when using shadow mode) does copy the PDB there, albeit not reliably enough that OpenCover can grab it (to be confirmed ?).
IMO the fix should be that NUnit starts getting reliable about its PDB file copying.
Though this asks the question of why do we copy those files around at all, and is it the right thing to do ?

Hello,
I have the same issue but only after the project is compiled in framework 4.0, perhaps the issues are related and the message perhaps missleading....
I've attempted to make nunit use framework 4.0 with:
    targetExecArgs='framework:net-4.0'
}```

but then I got into another situation:

What went wrong:
Execution failed for task ':opencover'.

No signature of method: java.lang.String.join() is applicable for argument types: (java.lang.String) values: [ ]
Possible solutions: find(java.lang.String), count(java.lang.String), wait(), trim(), find(), wait(long)

Hello,
The same issue adrianrus mentioned, only when compiled in fmk 4.0

For me no longer reproduces with latest version, could be fixed.

closing as obsolete


Implementation of InstanceIdClient (FCM topic management) is missing

The title should be quite self-explanatory. I'm looking at java SDK, where FCM topic management functionality is available under InstanceIdClient, methods subscribeToTopic and unsubscribeFromTopic. Can this feature be expected anytime soon by the Firebase team?

Not unless somebody in the community contributes the code. The Firebase team will eventually get to it, but it won't be anytime soon.


Ignore mouse devices

I use keyd to remap some keys on my keyboard, and it seems like it's blocking the smooth scrolling of my mouse (MX3)... When I turn off the keyd service, the smooth scrolling works just fine
It would be nice if in the settings of keyd, there was a way to say "ignore all mouse devices and don't create a virtual pointer"

By default keyd will not try an remap your mouse, however some devices (e.g laptops) will assign the trackpad and keyboard to the same vendor/product id. The latest version of keyd accounts for this by using internal ids that can distinguish between the devices and explictly whitelisted/blacklisted in your config.
You can see these ids using keyd monitor.


Bump matrix synapse

Motivation for this change

https://github.com/matrix-org/matrix-synapse-ldap3/releases/tag/v0.1.4
https://github.com/matrix-org/synapse/releases/tag/v1.7.0

Things done

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

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

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

Notify maintainers
cc @WilliButz @mguentner @pacien @Ekleog

@GrahamcOfBorg test matrix-synapse


Blog: Getting started in DevOps, CI pipelines, and GitHub Actions (video)

https://app.clubhouse.io/featurepeek/story/5722/embed-youtube-video-in-featurepeek-blog-post


extractCss for ng serve

Hi there,
Is there a way to extract css to separate css files when running ng serve ?
I tried ng serve --extractCss but with no luck.
Is there a page or a file with all available commands and options for serve or build ?
Thank a lot for all the help.

Heya @mkoczorowski, you can find all the flags in our wiki: https://github.com/angular/angular-cli/wiki/serve
The one you wanted is --extract-css.


Allow px units when specified

I find it difficult to achieve the look I desire when the only unit available is spaces.
For example:
label-unfocused-padding = 0
label-unfocused-padding = 1
0 is much too small. 1, while tolerable, is just a little too big.
In addition, this spacing will change in size with the font size. Sometimes this is great - other times I would rather it not.
Ideally, adding the px extension to a number would cause that number to be treated as pixels instead of spaces.

This allows greater control for those that want it
This does not break existing configs, like #204

I am currently using formatting tags in labels to work around this.

+1
I currently use label-separator = &nsbp; (replacing &nsbp; with an actual non-breaking space) to get separation between labels, since I can't have half-padding values (or change the padding character/size)
If px is not a preferred method, perhaps we can change the font-size or character of the padding character?
https://github.com/jaagr/polybar/blob/a0b888b5e6fa81422d05ff7c571e3b0c3871e901/src/components/builder.cpp#L299-L308
https://github.com/jaagr/polybar/blob/ea5fc22c7d43d7f4d25855124b275159f43c3371/src/modules/bspwm.cpp#L409-L411

At first sight this doesn't seem too difficult. We could directly also support other types like points (1/72 inch). This would help address #951.
I'll list the things that I think would need to be done.

We need to be able to parse these values and represent them. Parsing should be easy, I think it could be done inside config.hpp and the representation could be:

enum size_type { SPACE, POINT, PIXEL };

struct size {
  enum size_type type;
  size_t value;
}

We need to use this representation throughout polybar when it comes to spacing. @MyNameIsCosmo already mentioned some code locations for this. For one builder::space should now accept struct size.

Wherever spaces are produced now the %{O} formatting tag should be emitted for spacing based on pixels and spaces should still be used if size_type::SPACE is used. I think we would only need to change builder::space here but there could be other places that produce spaces for spacing.

One issue here is about where we want to translate points to pixels with the dpi set in the bar config. I'm not sure the config should actually know about dpi and just do the parsing (separation of responsibility). If builder::space is truly the only place that handles spacing, we could just do the translation there.

Set the dpi inside bar_settings. This just involves moving the relevant code from renderer.cpp to bar.cpp and accessing dpi_x and dpi_y through m_bar inside renderer.cpp. This is needed so that wherever we do the translation from points to pixels, we have access to the dpi settings.

This has turned more into a breakdown of what needs to be done to support a DPI-dependent unit like pt instead of px, but I think we can implement both at the same time.
Ideally we can find a way that can help solve this as well as the issue in #951 at the same time without too much code duplication. The main challenge is that for width and height a unit like spacing does not make sense while a percentage does. Also we don't use builder::space for width and height.
If anyone wants to take a crack at this, I think we could start with just implementing the functionality for pixels, for this we would only need points 1-3 and could drop POINT from 1.

I would like to help on this feature, however I don't see exactly how do you want to print the space.
Do you want to convert pixel to space or do you want to change the way the "space type" are managed into the builder::space?
I already started to adapt the code and the config class to use the struct rather than an int.


Add score for test execution only; Add to run for a specific TestScript file

Added minor features:

Added new score for test only. It is calculated inside the method but won't be included in TestReport. Need to discuss how we will set "options" in the engine along with the score types.

Added an argument to point a specific TestScript file to execute. Without argument it runs all TestScripts in the folder.

Flushed TestReports.

Great changes! I'll approve that last fix ^ gets addressed.


Allow for customization of included components

Description
Registries in the components/* packages and runtime.Run were refactored to allow for a customized set of components to be compiled and initialized.  This makes extensibility much easier and clear.  See #929 for more details.
Issue reference
Closes #929
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Unit tests passing
[x] End-to-end tests passing
[ ] Extended the documentation
[ ] Specification has been updated
[ ] Provided sample for the feature

 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: pkedy sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @pkedy, this is an important change that'll allow organizations with private components to build a customized Dapr better, thanks for this.
For visibility to all: as we discussed, let's try and find a way of keeping main.go small and focused, while providing the same benefits of this PR.

/ok-to-test

@pkedy, run the e2e manually to see why it fails.

/ok-to-test

/ok-to-test

/ok-to-test

Congrats indeed @pkedy

/cc @amanbha and @shalabhms, please review.

@pkedy can you resolve the conflicts?


Clean Up handling of raw tags

Until now the builder parsed any raw tags that users provided (like ones coming from script modules) and used it to track how many tags were open, to be able to close it when flushing the builder.
This method didn't support multiple formatting tags in a single block (e.g. %{F#ff0000 B-}) and thus created some issues (see #1555). Instead of fixing this, I just completely removed the tracking of raw tags. Because we would then have basically replicated parser.cpp in the builder.
Because we don't track raw tags anymore they could leak out and affect the modules appearing to the right of it. For that I introduced a new formatting tag P, which is used for polybar control commands, %{PR} is the only available tag right now, and it resets all colors, activations of underline and overline and the font in the renderer (it's basically equivalent to %{F- B- T- -u -o u- o-} but less verbose).
This will probably change the behavior of some configs that use raw tags outside of the script module.
This PR only causes raw tags to be reset later and never earlier. So colors leaking out could happen more, but tags won't be reset earlier than they currently are.
Some drawtypes would call flush at (for the user) arbitrary places, users could have relied on those flushes to reset their raw tags they used inside the labels and because now this doesn't happen anymore those raw tags could leak over the subsequent labels in the module. I don't think this is a big deal as we never gave any guarantees when polybar would reset tags within a module (except that labels won't reset tags that they didn't set at the beginning).
Fixes #1555

Maybe we should add something into the parser to forbid the usage of the %{PX} tags to the users?

The point of this PR kind of is that we don't have to do tag parsing before sending the entire string to parser.cpp. I think if we don't add user documentation for it, it should be fine.


[BotFramework-Connector] Fix webpack breaking issue with polyfill

Description
After removing the request dependency from the botframework-connector library the bundling of the app using WebPack would throw a missing dependencies error and fail (see issue 818).

Specific Changes
We removed the conditional imports in botframework-connector and replaced a variable (env) that was being initialized to global or window depending on the bot running locally or on a browser, and directly replaced its instances by a call to this which holds that value. This is because the function, being called through its constructor, will execute in the global scope (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function)
Code before this modification was:
(new Function('require', 'const env = (global || window); if (!env.hasOwnProperty("FormData")) { env.FormData = require("form-data"); }; if (!env.hasOwnProperty("fetch")) { env.fetch = require("node-fetch"); }'))(require);

Was changed to:
(new Function('require', 'if (!this.hasOwnProperty("FormData")) { this.FormData = require("form-data"); }; if (!this.hasOwnProperty("fetch")) { this.fetch = require("node-fetch"); }'))(require);

Line changed
Testing
We ran the unit tests after this change and they all passed successfully

Promoted to MS # 890


ref(*): remove chart

remove charts/
update docs

Depends on https://github.com/Azure/brigade-charts/pull/1
Ref https://github.com/Azure/brigade/issues/718

CI failing due to unrelated issue(s): https://github.com/Azure/kashti/issues/237


Cromwell Launch Exit Code

Bug Report
Expected behaviour
Dockstore CLI launch should return the same exit code as its Cromwell execution
Actual behaviour
Exit code 0 is always returned no matter what
Steps to reproduce the behaviour
Launch a WDL workflow that is known to fail.

dockstore now returns a non-zero exit code when cromwell returns a non-zero exit code.  However, cromwell exit code was 1, but dockstore returned 3.  Not sure if that's what's intended.

Probably our mappings don't match their's. A 1 for us would be a generic error. IO error probably isn't better, we probably need a code for workflow failure


HTML is being altered

If I pass in


Add disclaimer regarding removal of :champagne: comment

Closes #881
Signed-off-by: Matej Focko<EMAIL_ADDRESS>

Nice, what about linking this or the other issue?

I thought about this, but since we "smack" the comment on every PR, I can see the issue being spammed just by use referencing it. If it's not a big problem, could be added. :)

I thought about this, but since we "smack" the comment on every PR, I can see the issue being spammed just by use referencing it. If it's not a big problem, could be added. :)

Good point. Let's go without that.

I thought about this, but since we "smack" the comment on every PR, I can see the issue being spammed just by use referencing it. If it's not a big problem, could be added. :)

Good point. Let's go without that.

We could probably pin the issue for removal of it?


Quote linked messages

For example:
srid: @solvann: example here: https://actualfreedom.slack.com/archives/general/p1470071346001458

In Slack, that embeds the linked message. But in the digest no such thing happens. Would be nice to do it though.

Hmm will have to see about this one, may be slightly tricky. But still do-able I'm sure

Ah this ended up being solved when I added attachments in general.


Windows 10 debug assertion failed error

Required Info

Camera Model
D435i

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win 10

Platform
PC

SDK Version
2.50.0

Language
C/C++

Issue Description
While testing librealsense2 SDK release v.2.50.0 I've encountered the "Debug assertion failed error".

The error only occurs in examples and tools that use openGL library (realsense-viewer, rs-gl) and that are built with Debug configuration and in which GLSL for processing is used.
When built with Release configuration no error is reported, however a memory leak seems to occur when GLSL for processing is used.
Debug assertion error has not occured when running realsense-viever or rs-gl example from librealsense2 SDK v2.49.0. The possible memory leak is still present on v2.49.0.
A similar error does not occur for debug configurations  on Ubuntu 18.04.
Ways to reproduce:
• Download librealsense2 v2.50.0 source from github
• Checkout to tag v2.50.0
• Use Cmake to configure project
• Open project in Visual Studio
• Build project
• Run realsense-viewer in debug mode
○ Go to settings: check Use GLSL for rendering
○ Start depth stream
○ No error
○ Go to settings. Check use GLSL for processing
○ Start depth stream
○ Debug assertion error occurs
I am aware that the GLSL memory leak has been reported before https://github.com/IntelRealSense/librealsense/issues/8110
The debug assertion error could be related to the memory leak since both occur when GLSL is used for processing.
I've also tried the latest commit on the development branch and the assertion debug error occurs there also.

Hi @MartyG-RealSense thank you for your reply.
I was aware of the memory leak, but the debug assertion error is new.

As GLSL support has to be programmed into an application deliberately and is not enabled by default (GLSL is optional support for acceleration of certain SDK functions) you should be able to use Debug mode with 2.50.0 if you do not use rs-gl or you disable it in the Viewer.

Hi @mkelrajt  Do you require further assistance with this case, please?  Thanks!

I have no further questions, if new issues arise I will open a new ticket. Thank you for your reply.

Thanks very much @mkelrajt for the update.  As you do not require further assistance with this case, I will close it.  Thanks again!


Suggestion Update faq.md

@JV0812 - Sharing this suggestion as a generic reference for any administrators interested in understanding how the system optimizes the query.
Could you please improve the experience of the same and add it to the help documentation.
Purpose of this pull request
This pull request...
Select the type of change

[ ] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions, updating sections
[ ] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - .clabot, version updates, maintenance, dependencies, new packages for the site (Docusaurus, Gatsby, React, etc.)

Ticket (if applicable)

@kimsauce, your comments have been addressed. Could you approve?


asips-test: SSL wildcard Certificate Creation

Issued. Manifest updated and SSM Parameters created.
Note: this is done in 'Unity-SBG-dev' environment as that is being repurposed for ASIPS work.


Add the ability to reimport a List CSV export into the App

Add the ability to reimport a List CSV export into the App
Loop for the barcode column, and re-add the items to a list.
A simple way to exchange a list between 2 people (for shopping)

I would like to work on this

i would also like to work on this


Add fuzzy matching support to the vimgrep command

Hi,
The Github actions for this PR didn't run because it says
"This workflow is awaiting approval from a maintainer".
I haven't seen this message before.
Regards,
Yegappan
On Sun, Apr 25, 2021 at 1:26 PM Yegappan Lakshmanan <
@.***> wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/8152
Commit Summary

Add fuzzy matching strings support to vimgrep command

File Changes

M runtime/doc/quickfix.txt
https://github.com/vim/vim/pull/8152/files#diff-b8a62bd8b4df13e572b6ca24cd855b598e8d69055cf742fb2b23bcd7cdf296e2
(13)
M src/ex_cmds.c
https://github.com/vim/vim/pull/8152/files#diff-036240e2e564f661297b3e05cd955286c36bc8adebfa35bc6e0acaac3b354e80
(6)
M src/proto/search.pro
https://github.com/vim/vim/pull/8152/files#diff-8a6ecb5f2e0ed9d6374b2abd8210fa52f4cc45d61fe4b7aead6bac550d4890a2
(1)
M src/quickfix.c
https://github.com/vim/vim/pull/8152/files#diff-044c1fb49b65ed4f32c8f526333ceba6e2aa59b618e0b18b1b97c87975636a9a
(113)
M src/search.c
https://github.com/vim/vim/pull/8152/files#diff-d5920a54fc6fff9b49052b09ca50c0608cf55cc93b5a46713bf8a4de1132eed0
(34)
M src/testdir/test_quickfix.vim
https://github.com/vim/vim/pull/8152/files#diff-70ab6853309b5a0f83ba72df3c82c30f9f373e01a5b3335cfc8a2c25e66e1704
(50)
M src/vim.h
https://github.com/vim/vim/pull/8152/files#diff-0f9fae9859e0cdbca395251787c939a8bf5ba976ffa1f87615936adc193f1be4
(4)

Patch Links:

https://github.com/vim/vim/pull/8152.patch
https://github.com/vim/vim/pull/8152.diff

not sure why this is needed now. I approved the GH workflow

Hi Christian,
On Sun, Apr 25, 2021 at 11:21 PM Christian Brabandt <
@.***> wrote:

not sure why this is needed now. I approved the GH workflow
It looks like Github changed the policies:

https://github.blog/changelog/2021-04-22-github-actions-maintainers-must-approve-first-time-contributer-workflow-runs/
https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/
When I updated the PR, the Github actions now requires maintainer
approval to run again.

Yegappan

not sure why this is needed now

some hacker using pr action to dig coin, i guess that's the why, and so check pr (specially for ci 'action') carefully as well.

seems just added [f] into quickfix.txt, but did not mentioned what's that use for..
// supposed would update at next runtime update?

seems just added [f] into quickfix.txt, but did not mentioned what's that use for..
// supposed would update at next runtime update?

https://github.blog/changelog/2021-04-22-github-actions-maintainers-must-approve-first-time-contributer-workflow-runs/
https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/
When I updated the PR, the Github actions now requires maintainer
approval to run again.

Thanks, this is unfortunately a bit annoying. I will check the PR page then more actively and see if I need to approve anything.

github network for page and feed recently is abnormal too (or just in some country).
// above 2 links cannot be opened, but I Guess pr action was limited due to that..

Hi,
On Mon, Apr 26, 2021 at 11:01 PM Shane-XB-Qian @.***>
wrote:

seems just added [f] into quickfix.txt, but did not mentioned what's that
use for..
// supposed would update at next runtime update?

My pull request includes the updates to the help files. I guess it will
show up when Bram pushes the next runtime file updates.

Yegappan


Feature/Audit [Update/Simpler version]

This is not finished, i am sure there is bugs in it.
Before I continue I want to check that we are roughly agree on the api interface.

I am no sure if the PATCH /1/products/:id solutions is what you want
And not sure if I need to adjust the handling of the POST /1/products/search

Also note that I picked the products endpoint as an example I don't plan to add the audit logic to any endpoint out of the box.

I have updated the PR, renamed a few things.
The modal fields has changed a bit, besides from changing the interface + moving it to be just methods on db model.
Add routePrefix (namespace)
This is gonna require a wide change e.g. that relies on the router.opts.prefix see https://github.com/koajs/router/blob/master/API.md#router- from what i can tell we doing our routes wrong ... but that is a separate discussion. This field is only set if you set via the new Route({ prefix: "/1/products" }) I think thats most bullet proof solution to find a "namespace".
Remove type
I have removed type, I don't think we need it, its an http based audit trail.
Added an objectType
To capture the what type of the object are we dealing with e.g. is it a user or product or shop ?
Missing things
I need endpoints to expose the audit logs for reading
And possible would also be useful to hook it up something like users / auth endpoints ?

I am leaving the AuditEntries hook in the routes to make it more clear how it works.
I think it make sense to have hooked up for the users / auth endpoints, but happy to remove it.

lgtm


Migrating Code Gallery examples to the Samples Browser

Migrating Code Galley examples to the Samples Browser
At some future point, Code Gallery will be retired. Samples that I worth preserving should be migrated to the new Samples Browser. This issue outlines the steps in the migration.
All samples should be migrated as .NET Core applications rather than .NET Framework libraries or desktop applications. In addition, many examples combine C# and Visual Basic source code. The two languages should be separated so that they are independently downloadable.
Migrating from Code Gallery to the Samples Browser
Migration involves the following steps:

Select a sample to be migrated from the existing open issues in the Code Gallery Migration project and indicate in the issue that you are working on the migration.
Some of the samples are actually large collections of samples, with parallel samples in Visual Basic and C#. If you are interested in working on only one or more of these in a single language or in both languages, open an issue indicating that you are working on that individual sample's migration and refer to the parent issue in your issue.
If there is a Code Gallery sample that is not listed in the project, you can create an issue to migrate it. We will add it to the Under consideration column of the project.

Some of the existing issues represent samples that consist of large numbers of samples. In most cases, these should be broken down into a smaller subset of examples. If you're migrating only a single example or subset of examples from a multi-example project, clearly indicate in the issue which examples you're migrating.

Once you've selected the examples you'd like to migrate, use the .NET Portability Analyzer to identify issues that you'll have to address when converting a .NET Framework project to a .NET Core project.

Select where in the dotnet/samples repo the sample should go. The top-level directory should represent the general technology area of the sample, with any additional subdirectories serving to further identify it. For example, the HttpClient sample could be placed in /samples/networking/httpclient.

If the sample has multiple versions, they should be placed in separate subdirectories (such as cs and vb) of this directory.

For information on porting individual project types from .NET Framework to .NET Core, see Port your code from .NET Framework to .NET Core.

Some of the code is quite old and doesn't follow current best practices. Where possible, modernize the code and, for C# code, take advantage of the latest language features if they are useful. For example, objects that implement IDisposable should be wrapped in a using statement. Interpolated strings should be used instead of composite format strings.

//cc @KathleenDollard

Looking for VB Samples to port and having trouble finding them, the link above takes you back to this page.

The To migrate column of the Code Gallery Migration project contains samples that we'd like to see migrated to the dotnet/samples repo, @paul1956.


[FILTERS] The total number of filter values should appear in title bar

Also: Number of selected filter values should appear next to filter total count in title bar
Also: remove "clear selection" (it's redundant :) )

See PR #151
Changes
Selection filter should have filter count and selection count next to title

closing --> PR was merged + no activity since august


Move to using two sets of KTS script templates for IDE support

Reverting existing templates to legacy kotlin scripting configuration that works in the IDE
Adding new templates using new kotlin scripting configuration for future IDE support
This is a follow up to

https://github.com/gradle/gradle/pull/23575

#23575 broke IDE support because IntelliJ only looks up scriptFilePattern from the old configuration, this PR restores this.
The new script templates for IDE support are using the new configuration model for kotlin scripting and leverage implicit receivers.

@bot-gradle test RFN

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFN

I've triggered the following builds for you:

ReadyForNightly build

@bot-gradle test and merge

I've triggered a build for you.

Thanks for the review Ilya. Let's talk about it next week


pipenv --clear is not working

Issue description
pipenv --clear is not working.
Actual result
➜  Untitled Folder pipenv --clear
Clearing caches...

Do we have any update on this issue ?
I confronted it today, had to clear caches manually.

https://github.com/pypa/pipenv/pull/3354 should sovles this, I will try to add tests to that PR this weekend. Sorry for the delay.


Github CI: run also on repository pushes

This is useful to have a history of builds to track regressions.

This pull request is ready to merge

Merged to master and 1.1.1.


GatewayAnalyzer should parse namespace from the gw info in VS first

If the gateway link in the VirtualService has namespace information, use that to the find the correct resource instead of always trying the same namespace.
Fixes #18366
[x ] User Experience

Hi @burmanm. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@burmanm I did not mean to duplicate your work.  If you want to pick up an Issue, and don't have permission to self-assign, leave a comment and someone will set the assignment or hold the issue for you.

@esnible It's fine, this one didn't take too long. I assumed (incorrectly) that the linking to the issue from the PR would notify.

@burmanm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-istioio-k8s-tests_istio
3542abd4c1c07a5224a37e3e3261ea8aa6efd7ba
link
/test integ-istioio-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@burmanm I am happy to see you contributing to Istio.  How about you take anything good from https://github.com/istio/istio/pull/18393 and add it to your PR, following @sushicw 's suggestions.
I will approve yours and close mine.

@burmanm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-istioio-k8s-tests_istio
7b75d3824b4e0a0c73b88377776aac28843d7f22
link
/test integ-istioio-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-istioio-k8s-tests_istio

@burmanm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-istioio-k8s-tests_istio
7b75d3824b4e0a0c73b88377776aac28843d7f22
link
/test integ-istioio-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/cherrypick release-1.4

@sushicw: new pull request created: #18518

In response to this:

/cherrypick release-1.4

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


[bug] tsx.findInFiles may include ts in the target files

⏯ Playground Link
N/A

💻 Code

Code:
Repository to be reproduced is available here.
https://github.com/makotot/ast-grep-napi-find-in-files-tsx-issue
$ npm run exec
import { tsx } from '@ast-grep/napi'
;(() => {
  tsx.findInFiles(
    {
      paths: ['./example'],
      matcher: {
        rule: {
          any: [
            {
              kind: 'import_statement',
            },
            {
              kind: 'export_statement',
            },
          ],
        },
      },
    },
    (err, resultNodes) => {
      if (err) {
        console.log(err)
      }

      const results = resultNodes.map((node) => {
        return {
          statement: node.text(),
          path: node.getRoot().filename(),
        }
      })

      console.log(results)
      // [ { statement: '{}', path: './example/foo.ts' } ]
      // Is it expected that files with the extension ts?
    }
  )
})()

🙁 Actual behavior
My assumption is that tsx.findInFiles in @ast-grep/napi works only for tsx files, but as far as I can figure out, it only seems to include ts files if they contain export clause.
🙂 Expected behavior
I'm thinking that files with the extension ts should be exempt with tsx.findInFiles 🤔.

Thanks for the report!
I need to thinking about the behavior. Most users will use ts along with tsx in their setup, is it desirable to parse tsx only?
The desired behavior may be discovering all TS + TSX files and parsing them based on extension.
What's your opinion?

The desired behavior may be discovering all TS + TSX files and parsing them based on extension.

If the behavior consistently included ts files, I would think it would be as described above, but it did not appear to be the case.
The breaking point appears to be whether or not the export clause is included.
For example, I added this file to the repository I reported, but it is not recognized as a target. Maybe I am not understanding something 🤔 .
Here are the execution results.
$ npm run exec

<EMAIL_ADDRESS>exec
 ts-node ./src/index.ts

[
  {
    statement: "import { FindConfig } from '@ast-grep/napi'",
    kind: 'import_statement',
    path: './example/bar.tsx'
  },
  {
    statement: 'export { Bar }',
    kind: 'export_statement',
    path: './example/bar.tsx'
  },
  {
    statement: 'export default Bar',
    kind: 'export_statement',
    path: './example/bar.tsx'
  }
]
[
  {
    statement: '{ Foo }',
    kind: 'export_clause',
    path: './example/foo.ts'
  }
]

I too think the use case would be to treat both ts and tsx as targets.

I see.
If you question is "why .ts file is matched if they contain export clause."
This is because findInFiles accepts "FindConfig" where you can specify the matcher.
Only file with nodes matching with matcher  will be reported in the callback.
In this case, the findInFile with called with matcher like below
        rule: {
          any: [
            {
              kind: 'import_statement',
            },
            {
              kind: 'export_statement',
            },
          ],
        },

So only import/export file is reported by ast-grep

At least findInFiles' doc is not clear to you. Thanks for reporting the confusion! I will update the doc.
https://github.com/ast-grep/ast-grep.github.io/issues/188

Thank you for your detailed explanation and thanks again for the documentation improvements.

So only import/export file is reported by ast-grep. It is not because they are tsx or ts.

I am sorry, but I have one more question.
I thought it would match if it was a ts file that had an import statement, but am I understanding that incorrectly as well?

This is indeed a valid bug!
console.log(ts.kind('import_statement'), tsx.kind('import_statement'))
// 168, 170

Gave me two different kind.
The problem is that though  both ts and TSX are discovered by ast-grep. The kind import_statement is different in two languages.
Our config is specified as tsx so the import_statement kind is not equal to ts

napi 0.9.0 now strictly uses file extension to discover files!
So that tsx.findInFiles will always report *.tsx file.

My change


Full Armour No Damage

Server version:  1.13.2 Paperspigot
OldCombatMechanics version:  The latest from Jenkins
Server log file: No errors during charging
OldCombatMechanics config file: https://pastebin.com/8sPDcr18

When a player has full body armor he does not receive any damage.

Any enchantments? What type of armour? What weapon?

Diamond armor: Unbreaking 3 protection 4,
Diamond sword damage 5/10/50/100 The level of the spell does not affect the damage.

Armour enchantments damage calculations are a bit wonky at the moment. Do you still get issues without it?

I have great problems, it looks like turning off pvp.

Without any armour enchantments, does combat still behave as expected for 1.8?

Without armor, from what I remember, the fights are okay.

I am having this issue too. Running on 1.12.2 Paperspigot, using latest OCM build from Jenkins.

Having this issue too. It comes from the Old Armour Strength module, which is simply broken at the moment, you have to turn it of completely (you can't fix the issue by modifying values).

Yes I realized. I remember one year ago there was a similar issue to this. It happened when someone got killed but relogged, that player would simply just have 9999 toughness and couldn't get any damage.

Having 9999 toughness shouldn't be an issue though, it's the case on every armour on my server, it just changes the damage reduction of damaged armor.

Hope this is getting fixed very soon

The issue was that the old armour strength module wasn't actually working as intended because armour toughness is hard-capped in the server code. Thus I had to make the plugin recalculate the damage as if it were 1.8. This is working fine even with armour, except for enchantments, which I haven't gotten round to fixing yet as they seem significantly more complex than the rest of the code.

Any update on this?

@iBrady we are currently working on a rewrite of the damage calculations as a whole so that we can provide more compatibility with 1.9-1.13.

Alright thank you for the update!

@gvlfm78 @Rayzr522 With latest version, things have indeed improved. However armors are very far from offering the protection they should : try hitting a full Protection 4 armored player with a Sharpness 5 diamond sword with the effect Strength 2. You almost die in one hit, while you should only lose about one or one and a half heart.

@Ferocimo Maybe I got the order of some calculations wrong, but if you enable debug mode, do the OldArmourStrength module debug messages (in the console) report a reasonable damage reduction?

@gvlfm78 @Rayzr522 It now works fine with latest build (Version 1.7.0 Build 40), thank you very much !
A note though, for your information : without your plugin, before and after 1.9 damages are a little bit randomized when hitting someone with Protection enchantments. Sometimes you would take one heart of damage, sometimes one and half or two, some time a half heart only. It seems that your plugin makes players deal a set amount of damages that doesn't vary : this is not a big concern for us as we see the randomized damage quite annoying, but just so you know, it's different than Minecraft vanilla.

Damage is a double value, meaning it is a decimal. Those "randomized damages" are probably just decimal attack damages, and depending on when
For example, if a hit does 1.75 damage (1 heart + additional decimal):
If the player has full 20 hearts: 20-1.75 = 19.25 = 9 1/2 hearts displayed, -1/2 display heart
If the player has 19.25 hearts: 19.25-1.75 = 17.50 = 8 1/2 hearts displayed, -1 display heart

No, it's actually randomized damage. I simplified by talking about hearts but we use tools to measure what damages are dealt exactly.

@Ferocimo The amount of protection armour enchantments provide is still meant to be randomised, within 50% and 100% of the full protection amount, as was in 1.8. I saw this being the case in the console debug messages. Is it not so?

@Scremonetu @iBrady @Ferocimo Please try the latest test version of the plugin. If the issue is no longer present I will be closing this ticket.

@gvlfm78 Okay I tested it, it works fine indeed, I thought it was bugged because of an error from our measurement plugin.


[id] Add translation to Bahasa Indonesia for chapter0 & chapter1/1

Related to translating the course to Bahasa Indonesia https://github.com/huggingface/course/issues/345.
Covers chapter0 and chapter1/1

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

Thanks for kick-starting the Indonesian translation @gstdl and welcome to the 🤗 community!!
This looks great and we just need to remove some commented out bits of the _toctree.yml file before we merge :)

Hi @lewtun, I've already removed the commented out bits in _toctree.yml as requested


SuperCam view looks incorrect

The checkerboard rendering pattern maybe looks suspicious:

Yeah I saw that, as well. I'll have to take a closer look when I get the chance. It's possible the camera parameters have some kind of quirk to them.


Are TCP OOB packets used in toxcore? If yes, for [...]

https://github.com/Tox-Docs/Text/blob/master/src_text/net_crypto.txt#L12
Comment on
TCP OOB packet

found at column 233.
Are TCP OOB packets used in toxcore? If yes, for what?

Ok, I found it in the TCP_server docs.


add job scheduler page

docs project
this pr adds a new 'job scheduler' page to the dbt cloud jobs subsection.
the content includes info about the job scheduler, familiar terms, queue time, memory, and cancellation info.
source for content:

https://www.notion.so/dbtlabs/Issue-3144-Job-queue-content-ac97f41f0633409ba920c709ccd764ef#21e940dd3cbc430983c68122a700b891
https://dbtcloud.zendesk.com/agent/tickets/32268
https://dbt-labs.slack.com/archives/C02556Q6NEN/p1681840787758139

What are you changing in this pull request and why?

Checklist

[ ] Review the Content style guide and About versioning so my content adheres to these guidelines.
[ ] Add a checklist item for anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch."

Adding new pages (delete if not applicable):

[ ] Add page to website/sidebars.js
[ ] Provide a unique filename for the new page

Removing or renaming existing pages (delete if not applicable):

[ ] Remove page from website/sidebars.js
[ ] Add an entry _redirects
[ ] Ran link testing to update the links that point to the deleted page

Thanks @schottj ! Hey @jeremyyeo would love your review on this pr - particularly the memory section context (which used one of your tickets as context bc it was so good)?


Fix broken sdist/wheel

This will fix the sdist and wheel, which depending on how they are build, will omit all the source code, causing ModuleNotFoundError: No module named 'pytest_markdoctest' when you run pytest.
If anyone else finds this, this is the work around I'm using in the meanwhile
python -m pip install 'pytest-markdoctest @ git+https://github.com/matthewdeanmartin/pytest-markdoctest@50d08c3c8ec30bc4c7dc56201bba26f5e8dacf2d'
You will want to run python setup.py bdist_wheel sdist and pay close attention to the logging to see if the __init__.py and unparse.py were included.
For issue https://github.com/liqimai/pytest-markdoctest/issues/1

@matthewdeanmartin did you end up finding an alternative package? if not, any interest in maintaining a friendly fork and uploading to PyPI under a different package name?

@matthewdeanmartin cheers! Thank you + looking forward to it.
Just a heads up it might turn into a slightly larger time+effort sync than just packaging. Once I got it installed I saw AttributeError: 'DoctestMarkdown' object has no attribute 'getini' as soon as I tried running it. If I find the time to look into it, I'll do a PR on your repo for it.

For anyone else wanting to run doctests in Markdown and waiting on this to be fixed, I figured out that we can:

add --doctest-glob='*.md' to the pytest command, and

put a blank line at the end of any doctest in backtick code blocks, so that the closing ``` fence doesn't get interpreted as an expected output. (This extra line doesn't end up displayed on GitHub.)

This approach could get confused if you have >>>  at the start of a line outside of any code block, and I haven't checked how it handles indented code blocks, but it seems to at least work well enough for common cases.

@liqimai Thank you for coming back and merging this! Nice to see you're still maintaining it!


Rename the async keyword argument to async_req

The Python Kubernetes client recently changed the name of the async keyword parameter in its API to async_req.
This change makes the corresponding change to our calls to that API, which is necessary for the tf-operator code to work against the latest version of the Kubernetes client code.

This change is

/assign @gaocegege

Coverage decreased (-0.07%) to 57.957% when pulling 5decb57cec51c6b7ed28fdb1c696cde971442633 on ojarjur:patch-2 into b5809d5bbb4dd90bba8708dffc305973c164e1c9 on kubeflow:master.

/retest

/retest

/retest

@jlewi
I think why it failed the presubmit is because our testing still use kubernetes 4.0.0
so I try to update it to 7.0.0 in kubeflow/testing https://github.com/kubeflow/testing/pull/194
Would you help to have a look, Thanks!

/retest

/retest

3 tests failed: /py/prow_test.py, /py/release_test.py, /py/util_test.py.
INFO|2018-08-23T05:00:28|test_py_checks.py:23| Running py_test
INFO|2018-08-23T05:00:28|util.py:41| Running: python /mnt/test-data-volume/kubeflow-tf-operator-presubmit-v1-790-74639c0-968-cda2/src/kubeflow/tf-operator/py/prow_test.py
cwd=/mnt/test-data-volume/kubeflow-tf-operator-presubmit-v1-790-74639c0-968-cda2/src/kubeflow/tf-operator
INFO|2018-08-23T05:00:28|util.py:56| Subprocess output:

INFO|2018-08-23T05:00:29|util.py:62| Traceback (most recent call last):
INFO|2018-08-23T05:00:29|util.py:62| File "/mnt/test-data-volume/kubeflow-tf-operator-presubmit-v1-790-74639c0-968-cda2/src/kubeflow/tf-operator/py/prow_test.py", line 4, in <module>
INFO|2018-08-23T05:00:29|util.py:62| import mock
INFO|2018-08-23T05:00:29|util.py:62| File "/usr/local/lib/python2.7/dist-packages/mock/__init__.py", line 2, in <module>
INFO|2018-08-23T05:00:29|util.py:62| import mock.mock as _mock
INFO|2018-08-23T05:00:29|util.py:62| File "/usr/local/lib/python2.7/dist-packages/mock/mock.py", line 80, in <module>
INFO|2018-08-23T05:00:29|util.py:62| import funcsigs
INFO|2018-08-23T05:00:29|util.py:62| ImportError: No module named funcsigs

@jlewi
Do we also have to add funcsigs into kubeflow/testing images/Pipfile ?
It seems it has dependency on mock in python2

Yes. I have a fix in kubeflow/testing#195 and a new image should be pushed.
/test all

/retest

/lgtm

@ojarjur
Thanks for your contribution!
@jlewi
We successfully pass all the tests.
I think we can merge this PR and other PR can then move forward.
Thanks

/approve


Build failure: pipewire with gstreamerSupport = false;

Steps To Reproduce
Steps to reproduce the behavior:

Set gstreamerSupport = false; for the pipewire package, e.g.:

(self: super: {
  pipewire = (super.pipewire.override {
    gstreamerSupport = false;
  });
})

Try building it

Build log
Full build log here
error: builder for '/nix/store/wgrafxy52bl43wh76bl4cgxn3x1v2psk-pipewire-1.0.7.drv' failed with exit code 1;
       last 10 log lines:
       > Run-time dependency libcanberra found: YES 0.30
       > Run-time dependency libusb-1.0 found: YES 1.0.27
       > Run-time dependency libcap found: YES 2.69
       > Run-time dependency glib-2.0 found: YES 2.80.2
       > Run-time dependency gio-2.0 found: YES 2.80.2
       > Dependency glib-2.0 skipped: feature gstreamer disabled
       >
       > meson.build:371:6: ERROR: Problem encountered: `gstreamer-device-provider` is enabled but `glib-2.0` was not found.
       >
       > A full log can be found at /build/source/build/meson-logs/meson-log.txt
       For full logs, run 'nix log /nix/store/wgrafxy52bl43wh76bl4cgxn3x1v2psk-pipewire-1.0.7.drv'.
error: 1 dependencies of derivation '/nix/store/q08x7jj3gqjafvcd79zgai1qzm7qsxpm-SDL2-2.30.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/js3n9p4ilnrlkxkjb2mlqr1wz2faygbr-gnome-remote-desktop-46.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/7ldsfimg20ddd57979czfc78ad6qhib8-gnome-shell-46.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/b8gh76bwmnf1dsi856maj8mlfddibdkb-google-chrome-126.0.6478.182.drv' failed to build
error: 1 dependencies of derivation '/nix/store/8sr5k8bxxaqcr2bsn8c1vqj57gfgrpdh-hwdb.bin.drv' failed to build
error: 1 dependencies of derivation '/nix/store/gvwfailabl0izry6823md1pc6ip58z5f-mutter-46.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/gfksa8xyg319qrdbd3s550nj93j0z3h9-openal-soft-1.23.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/wcc3y9cwc1wyz51lafj19a07ifl2yxxd-system-path.drv' failed to build
error: 1 dependencies of derivation '/nix/store/gxslyy7g1di8jazfffl9krm6py82p9jp-nixos-system-heliodor-24.05.20240719.0c53b6b.drv' failed to build

Additional context
This can be fixed by either making sure that gstreamerSupport flag controls the gstreamer-device-provider Meson option in addtion to the gstreamer, or by exposing a new option to control the gstreamer-device-provider directly.
Notify maintainers
ping @kranzes @k900 👋🏻 let me know which of the options above you guys prefer and I can open up a PR to fix as well.

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.41, NixOS, 24.05 (Uakari), 24.05.20240719.0c53b6b`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - channels(root): `""`
 - nixpkgs: `/nix/store/qszplw617r895nbcprgyj139c9a3r0xs-source`

Add a :+1: reaction to issues you find important.

Can we just remove that option instead?

Sorry do you mean set the gstreamer-device-provider to always be false or completely remove the gstreamerSupport as an option? Because I prefer the abilitiy to turn as many unnecessary dependencies as practically possible on my system (better stability and security).

Remove the gstreamerSupport option, yes, because we can't realistically maintain the exponential explosion of possible flag combinations.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/a-sad-state-of-nixpkgs/49397/1

I made two PRs: https://github.com/NixOS/nixpkgs/pull/328996 and https://github.com/NixOS/nixpkgs/pull/328999
Feel free to pick whichever PR looks better to you

arg removed in #328999

because we can't realistically maintain the exponential explosion of possible flag combinations.

How much maintenance burden does this actually cause? IMO the package options are one of Nixpkgs strengths (one of the things that attracted me, after I stopped working on Homebrew because package options started to be removed entirely), and they're critical for people working on systems where size matters.

To expand a bit, I don't think that package maintainers should generally be expected to support all combinations of options, but I also don't think they should block people who want to from doing so.  Just having the flags there shouldn't cause any problems for package maintainers that don't want to maintain the flags, and it's fine IMO to respond to issues about flags not working by asking people to adopt the flag and send a patch.

No one's blocking people from overriding.
It's just a bad idea to have some flags we haven't even looked at in months and pretend we support them by including them in the expression. Or in other words, keeping the flags is shipping broken code if people don't maintain them.

The enableSystemd flag had clearly been looked at recently, because there was a commit from me fixing it, and yet it was removed anyway.


Secrets in repositories and exporting secrets in modules

@rahalan and @MrMCake I agree with @christiankuhtz this repository is a example for others to use and putting secret in code is a no no private and also in public repositories.
The same as exporting secrets in a module.
Originally posted by @aavdberg in https://github.com/Azure/ResourceModules/issues/1157#issuecomment-1220639778

Hey @aavdberg, I will close this issue as we almost concluded the rework to the new dependency approach (#1791) which also means we don't need the Public SSH Key for our Linux deployments anymore in code - instead the key is generated during a pipeline's run, used, and deleted without ever exposing the value in the code.


Feature/creating a data model

In this pull request I did the following:

[ ] Created User, Post, Like, and Comment models.
[ ] Created User, Post, Like, and Comment tables.

Thank you @Gambit142, I updated the default branch to be dev branch.


Improve the presentation of drift summaries

Problem
When Migrate detects drift, it will warn that the database drifted and print a summary that can look like this:
[*] Changed the `Color` enum
  [+] Added variant `TRANSPARENT`
  [-] Removed variant `RED`
[*] Changed the `Cat` table
  [-] Removed column `color`
  [+] Added column `vaccinated`

Suggested solution
Change the phrasing to something like this:
[*] `Color` enum drift
  [+] Unexpected variant `TRANSPARENT`
  [-] Expected variant `RED` missing
[*] `Cat` table drift
  [-] Expected column `color` missing
  [+] Unexpected column `vaccinated`

Alternatives
Keep the current phrasing, but introduce it better.
Additional context

Explain what drift means. Introduce the summary better.

Feedback on https://github.com/prisma/prisma-engines/pull/2045
alberto:knife_fork_plate:  20 minutes ago
I think thinking of changes or additions or deletions can be challenging to reason about because of the direction. You are presenting the changes that likely happened, but the person could be thinking of it as the changes that Migrate would perform to bring everything in sync.I was thinking this could be made more explicit by using language about what was found vs what was expected.Some ideas:
Unexpected tables: Cat
Missing tables: Dog, Horse
Column differences: Bird.id expected to be String but is of type Id.
I don’t know how verbose vs summarized we want to be but I find such language more intuitive.

We'll probably revisit this later then.

Other comment written on slack, copy-pasted for the rationale for the current format: It's a larger effort than it seems because you need to translate every type of change a migration can do into that language, and you have to take into account large drifts. People are probably not going to read all of it if it's more than ~15 lines, that's why I went for the most compact format I could with the current summaries.

https://github.com/prisma/prisma-engines/pull/2045 is merged. Let's see if we need to make further changes later.

Keeping it in the backlog as it's not fully aligned with the current goal (stabilize preview features for next major)

For the record, I personally think we should keep the current phrasing (although we could probably introduce it better), so I'm changing the tag from improvement to discussion. I am happy to write up rationales if we want to engage in the discussion. The main one being that the current phrasing reflects the changeset as actually implemented, so it gives users a better mental model of what is happening if introduced properly.


Update sbt-scalajs, scalajs-compiler to 0.6.31

Updates

org.scala-js:sbt-scalajs
org.scala-js:scalajs-compiler

from 0.6.29 to 0.6.31.
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.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-js" } ]

labels: semver-patch

Codecov Report

Merging #1320 into master will decrease coverage by 0.39%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #1320     +/-   ##
=========================================
- Coverage   86.04%   85.65%   -0.4%
=========================================
  Files          74       74
  Lines        2537     2537
  Branches      108      108
=========================================
- Hits         2183     2173     -10
- Misses        354      364     +10

Impacted Files
Coverage Δ

...re/shared/src/main/scala/io/circe/JsonNumber.scala
91.56% <0%> (-7.23%)
:arrow_down:

...les/core/shared/src/main/scala/io/circe/Json.scala
76.96% <0%> (-1.82%)
:arrow_down:

...rc/main/scala/io/circe/numbers/BiggerDecimal.scala
84.79% <0%> (-0.59%)
:arrow_down:

.../core/shared/src/main/scala/io/circe/Decoder.scala
84.98% <0%> (-0.27%)
:arrow_down:

...re/shared/src/main/scala/io/circe/KeyDecoder.scala
97.29% <0%> (+2.7%)
:arrow_up:

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 6d2e2dd...072d444. Read the comment docs.


Editor/Console object inspecting behavior inconsistency

From<EMAIL_ADDRESS>on 2012-03-14T19:57:17Z
Is there a way to do a help lookup on a term (like Go to Definition) except that instead the current term is supplied to pydoc search and displayed in the Help window?
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=972

From pierre.raybaut on 2012-03-18T09:04:12Z
It is possible to show help (in the object inspector) on the word under cursor by pressing Ctrl+I.
I think that it's answering your question, so I'm closing the issue. Please do not hesitate to comment.
Status: Done

From<EMAIL_ADDRESS>on 2012-03-18T10:15:43Z
I didn't specify that I meant when the cursor is in the Editor window. To get the pydoc help on whatever is under the cursor. Thanks.

From<EMAIL_ADDRESS>on 2012-03-18T16:44:23Z
I tried that, but nothing happens. It does work if the cursor is in the console. I'm running 2.1.7. Is this a 2.1.8 feature?

From pierre.raybaut on 2012-03-18T14:29:24Z
Well, then let me rephrase my answer :)
"It is possible to show help (in the object inspector) on the word under cursor by pressing Ctrl+I directly from the editor window."

From pierre.raybaut on 2012-03-31T06:01:02Z
I changed the title to reflect the fact that we need to fix the behavior inconsistency between the Editor and the Console in the matter of getting help on an object through the Object Inspector.
Currently, the "Ctrl+I" shortcut in the Editor does not inspect any selected object: it only shows the calltip and associated docstring of a function.
Summary: Editor/Console object inspecting behavior inconsistency

From pierre.raybaut on 2012-03-19T14:17:09Z
The behavior seems to be slightly different from the console indeed, you're right.
If I'm pressing Ctrl+I on a function (with a docstring) in the editor, it works as expected. But if the cursor is on a module name for example (after an import statement), nothing happens... and the same operation works in the console.
Status: Accepted
Labels: Cat-Editor MS-v2.1

From pierre.raybaut on 2012-03-31T06:01:34Z
Labels: -Cat-Editor Cat-ObjectInspector

From pierre.raybaut on 2013-01-27T01:43:55Z
Labels: -MS-v2.1 MS-v2.2

From ccordoba12 on 2013-02-13T09:19:10Z
Status: Duplicate
Mergedinto: 1191


chore(git): adjust .gitattributes

Coverage remained the same at 100.0% when pulling 56d7b4459bdaedda594df9dc10ae57c2f02f8fa4 on adjust-gitattributes into 3b2887d69bd85bd614e365f8cdf34be812a1b2a3 on main.

:tada: This PR is included in version 1.1.4 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Investigate faster CI builds

As of today, testing out a change on CI approximately takes 50-60 minutes. Not only this introduces major friction in the feedback loop of the development process, but it is also source of slowdowns when a new version of Atom needs to be published. This is made worse by some flaky tests, which e.g. may cause us to wait multiple hours before publishing an important hotfix.
Caching
Related: #19326
After transitioning to Azure Pipelines as our CI provider, we lost an essential functionality for a project like Atom: caching. Our dependencies don't change that often, and when they do, only a small part of them gets updated/removed. On any given build, we have to wait approximately 15-20 minutes (~ 30-50% of our build times) to setup dependencies and generate a snapshot script.

Even though it seems like official support for caching hasn't yet been added to Azure Pipelines (apparently, it is slated for 2019 Q2), I discovered an extension (developed by Microsoft) that, if installed, claims to enable caching for arbitrary artifacts.
While it may not be fully baked yet, I would be inclined to try it out and see whether it makes a difference on this repository.
Testing
Atom's test suite is quite thorough, and we even run tests against the latest bundled version of core packages to catch unwanted API changes. Having an extensive set of test is valuable, but every test contributes to a slower build.

The above screenshot captures how long it takes to run main-process, renderer-process and package tests on macOS. On platforms like Windows x64, this time drops to 15 minutes because we simply don't run package tests there.
A simple solution to this could be to take advantage of the pipeline infrastructure offered by Azure. We could build Atom once on macOS and, in parallel, run two sub-jobs, each taking care of running main/renderer-process tests and package tests, respectively. This would dramatically decrease variance within an individual build, as macOS and Windows would roughly take the same amount of time to bootstrap and run tests.
Moreover, if we're willing to increase the granularity of our build, we could split package/renderer tests into further sub-jobs and increase parallelism even more. This would require a few minor changes to script/test but, alongside caching, could lead to builds that take ~5 minutes.
Final Remarks
I believe this work would be worth doing for a number of reasons:

Reduced friction while we're trying to publish a new Atom version.
Decreased time between opening a pull request and merging it.
Flaky tests would become easier to fix. We could test "fix hypotheses" much more quickly.
Addressing caching and parallelism shouldn't require a lot of engineering effort.

/cc: @atom/maintainers for 👀 and 💭

Thanks for writing this up! Both ideas are great!
This initiative is one of the things that will allow people to do these small improvements that get killed by the friction.
Regarding parallelisation of tasks, we'll need to increase our current number of maximum parallel jobs that can be run by Azure: it's currently set to 10 and that's going to quickly become a bottleneck (it already is during peak hours where several PRs/commits need to be built).

This would require a few minor changes to script/test but, alongside caching, could lead to builds that take ~5 minutes.
This would be truly incredible and would definitely lead to more developer productivity for us and our volunteer maintainer/contributors.

I saw a few different options for going about this in the testing section. Because this extension isn't fully baked, do you have a sense of what sort of level of effort is needed to try this out for either option? And at what points (either by amount of time or work completed) will be good places to pause and determine "move forward" vs. "wait for this to ship in Q2"?

With respect to the caching extension, based on their README, it seems like enabling it on our repository shouldn't take more than 4-5 days. I expect to be able to validate whether this approach would work at all or not in 1 or 2 days. Ideally, it would take even less than that but I am expecting slow feedback loops, as it always is when experimenting with CI.
As for the testing optimization, I think we should start out by running core and package tests simultaneously on macOS. I don't expect major problems with this optimization, so I am hoping it will take 3-4 days (this may depend on what @rafeca pointed out in https://github.com/atom/atom/issues/19366#issuecomment-493967810, as we need to contact Microsoft to increase our limits). If we can do that and the caching extension works, I would expect our builds to take ~15 minutes (27% of what they take today).
Based on everything we'll learn as part of those two steps, we could then take a step back and decide whether we want to invest some extra engineering time to cut the build time down even further.

@as-cii the builds have got much faster now thanks to the caching of node_modules and the parallelization of builds, can we close this one?

I think so, thanks for the heads-up.


ScrollDirection and BlockDirection confusion

Right now scrollables use ScrollDirection and they're backed by render objects that use BlockDirection. However, that means ScrollDirection.both has no good mapping.
We should clean this up. I think we should probably still have two enums, one with "horizontal" and "vertical" and one with "horizontal", "vertical", and "both", but we should not split it across Block vs Scroll, instead of should split it according to who supports "both" and who doesn't.

Briefly looked at this with @collinjackson. Scrollable right now asserts that you don't use "both". RenderViewport supports "both", nobody else seems to. We probably want a Widget to wrap RenderViewport with fling gesture support that does both, but other than that we should probably not have any use of the enum with "both".


solve the issue with minicity router 9 ( deleted it), Added new nodes…

solve the issue with minicity router 9 ( deleted it), Added new node and edges in minicity scenario

@lucfisc Lucas, The files you modified are the old examples/sumo/minicity.py and the Minicity scenario file. We actually weren't using Minicity Router 9 anymore anyways, we're using examples/sumo/minicity_subroutes2.py  instead with our own custom router included in this subroutes2 file.

I'm merging this PR since you say Xiao @yunerzxy is no longer working on Minicity, but as she was the one who created Minicity she's the best authority as to whether the new nodes and edges might break anything or not.


Write more performance tests and optimize runtime performance

Formatting UTF8 strings does not have performance tests
Number formatter is calling ToUpper on the format character. This regressed perf a bit in the past.
Math.DivRem (used in hot formatting loop) generates two idiv instructions. it should be just one.
It would be worth to again profile the perf tests. There were significant changes since last time.
Composite formatting does not have perf or memory tests.

@KrzysztofCwalina What remains to be done here? The formatters / parsers are now productized and the RTM code appears to have addressed much of these concerns.


Fetchart: check that the art found is a file

Code + test. Fixes issue #1177

Awesome; this looks like just what we need. :tophat:

Tiny GitHub protip: if you use the string "fix #someissue" or even "fixes #something", I think, it will automatically close the ticket when the PR is merged. I don't think it quite recognizes "fixes issue #something".

https://help.github.com/articles/closing-issues-via-commit-messages/ has the full list of usable closing keywords.


Combobox

Acceptance criteria:

If there are characters input or a selection is made there will be an “x” present next to the chevron to clear the selection
Text input matching will have “bold” treatment

Allow matches in the middle of a result, but prioritize matches at the start of a result.

Clear an input when focus is lost if no match is selected.
When no match is found, state “No matches found” in pop-up, not selectable
Should use the popover component
Implemented in accordance with design docs
Component API

Accessibility

Consider applying a role of “combobox”
Consider the following attributes:

aria-expanded
aria-haspopup
aria-controls
aria-activedescendant
aria-autocomplete

If initial state of the combo box is collapsed aria-expanded=false
When the combo box is expanded aria-expanded=true
If the menu is a listbox then the aria-haspopup value does not need to be set
When the menu is displayed ensure that aria-controls attribute is set to the id of the menu listbox
Chevron icon that shows menu should  button with a tabindex of -1.

It also must not be a descendent of the element with a role of combobox

Code must be written to enable the user to move focus between the combobox input field and the elements in the listbox.

down arrow should move the focus from the input to the elements in the listbox.

Keyboard interactions

Down Arrow

Moves focus to the next option, or to the first option if none was selected.

Alt + Down Arrow (Optional)
*If the popup is available but not displayed, displays the popup without moving focus.
Up Arrow

Moves focus to the previous option. Moving focus to the first option if focus was originally on the last option.

Alt + Up Arrow (Optional)

If the popup has focus, returns focus to the combobox, otherwise it closes the popup.

Enter

If the combobox is editable and an autocomplete suggestion is selected in the popup, accepts the suggestion either by placing the input cursor at the end of the accepted value in the combobox or by performing a default action on the value. For example, in a messaging application, the default action may be to add the accepted value to a list of message recipients and then clear the combobox so the user can add another recipient.

Additional Notes:

Look into using the native Autocomplete feature

see how that behaves with respect to location on the screen (including popover positioning behaviour)
Question - Can scroll be disabled on open with the native dropdown?
Question - Can the list be styled?
Question - can a “Clear selection” control be added in the input?

Implement for use with a list of data, and a callback function that updates the list.

Properties

Name
Type
Required
Default
Description

name
string
No

Must be unique in the rendered view and must match the children's name

value
string
No

Stores the value of the item selected from the dropdown

maxHeight
string
No
276px
Maximum height of the dropdown menu items popover.

placeholder
string
No

The text displayed for the dropdown before a selection is made.

default-value
string
No

The combo box will set this value as the default selection if it is found within the select options.

width
string
No

Override the autosized menu width

disabled
boolean
No
false
Disable this control

error
boolean
No
false
Show an error state

ariaLabel
string
No

Defines how the selected value will be translated for the screen reader. If not specified it will fall back to the name

Design
Figma

:tada: This issue has been resolved in version 2.5.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 4.14.0-alpha.2 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.14.0-alpha.2 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 2.5.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 4.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


High multiplicity event: in which order are they written?

If I have an event with a lot of detector hits (let's say several GRIFFIN hits in coincidence), in which order are they written into the AnalysisTree? Is it time based (clock, cfd)? Or is it channel or address based?

They are LED timestamp based. They may not be truly time ordered after the cfd is applied.

Ok, thank you.

one small bit of confusion here.  (maybe just for me)
If you have many gammas rays built into a single event (i.e - more than
one crystal in coincidence or already grouped by a time window), I believe
they are still written in order of there energy into the built event
(TGriffin).  What this means, if you loop over the TGriffinHits in a
TGriffin event the highest energy gamma should be first, followed by the
second, etc...
This is done to make it easier to construct addback events later.  The
actual led time of an individual gamma-ray can fluctuate by ~100 ns (to
clock ticks) easily due to walk effects which are common to all large
volume coaxial ge detectors.
Just out of my own curiosity;  is there some effect you are trying to
account for?
On Tue, Feb 14, 2017 at 2:57 PM, bolaizol<EMAIL_ADDRESS>wrote:

Ok, thank you.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-279817955,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAacI8-WIhvBVx8W2AMF-Wh5-yr1hwxOks5rcgc-gaJpZM4MA6gr
.

Was this changed to be like this at some point?

I was loooking on optimized ways to correlate TAC and LaBr (or any other detector) events. If they were ordered by addresses it would be much better for this case.
If there is such a large fluctuation (~100 ns), I don't really see the point of ordering them based on timeclock or cfd. But I see the point of ordering the hits by energy if it is useful for the addback.

I don't think we sort the hits by energy. That wouldn't help much in the addback either since you would now shuffle gamma-rays out of their time-order and the time is something we consider for the addback.
As far as I can see in the code, we just use AddFragment to add the current hit (which was sorted by LED timestamp) to the vectors of hits. That is why we check the energy of the (second) hit in the TGriffinHit::Add routine to decide whether we use the position of the first or the second hit as position of the addback. If the hits were sorted by energy we wouldn't need this check.

The only energy sorting that is happening is actually due to the walk. Gamma rays that are hitting the detectors at practically the same time will have a later timestamp if their energy is lower.

I really think LED is the way to do this, at least with GRIFFIN. Breaking up the ordering will make it a pain to deal with pileups in the future.

I haven't looked at the latest incarnation of the griffin addback - however
at one point I wrote a compare function (and < operator overload) which
allowed us to use std::sort on the vector of hits before writing to the
tree, this is still being done in tigress.  I thought was still being done
in griffin as well.
It is true the fragments going into the hit building are sorted, as they
should be, however once the event is built - I think there is a lot more
information to be gain from the energy of a gamma hit than its time -
especially if the time is an led value.  This stems from the idea that the
energy defines a main interaction point in addback event or from which hit
an addback hit will inherit its timing and position properties from when it
is constructed from a sum of two or more hits.  Knowing who gets copied
where just makes the coding a bit cleaner.
On that same note, I am not sure what is gained from keeping the order of
the led time in the hits.  Based on the pileup argument - this hits should
either be removed completely from the event or become there own event as
they are not time ordered, right?
Also; "The only energy sorting that is happening is actually due to the
walk. Gamma rays that are hitting the detectors at practically the same
time will have a later timestamp if their energy is lower."    and
interaction location within the crystal (just for completeness sake and
future readers).
On Wed, Feb 15, 2017 at 11:53 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

I really think LED is the way to do this, at least with GRIFFIN. Breaking
up the ordering will make it a pain to deal with pileups in the future.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280068181,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAacI9uSjnRtoTxlDAlaz0XdHRs6YKKmks5rcy2XgaJpZM4MA6gr
.

In the end, it is the ordering based on CFD timing in GRIFFIN that will be best if you are looking for efficiency. I’m not sure why energy ordering makes add back better. That just means you have to loop over every single hit to find out what to add back, which you would have to do anyway if they weren’t ordered. Ordering on a time parameter allows for the quick knowledge of which hit came first. It also allows one to be more efficiency if they desire by cutting off the looping over hits when a tight time difference is exceeded. This will be very important for high rate experiments where everything is in coincidence with everything.

We do use that compare in Griffin as well, but only to determine which hits time and position we use for the addback. I agree with Ryan in that I don't see the advantage of energy-ordered hits for building addback (you need to loop over all hits anyways) compared to time-ordered hits (where you might stop after a hit is outside the addback time window).
And I think we need to change the whole time sorting as some point to use the cfd corrected time anyways (if we didn't already do that?), to correctly build events using pile-up.

Can I have some clarification of what the current ordering is.
I can see Ryan's logic of time sorting allowing speed by continuing the loop and avoiding unneeded comparisons for addback.
But this isn't done in TIGRESS. TIGRESS addback logic is heavily based on energy arguments the Peter explained, (I recently added a whole load of comments to the code)  and assumes energy of hits and segments have been pre-sorted.

Simply put - if two gammas are really in coincidence with each other and
not a special case (i.e. isomer, which is never the case for two individual
hits which need to be added together), than there energy is deposited in
the detectors with a time difference we can not measure.
Currently, we do a single pass through of the hits to decide which hits to
add together. What this implies is we are slightly  weighting the
probability of which hits get added based on their order in the list.  Now
the time measurements we actually measure for gammas, especially the ones
that should be added back, are there due to detector effects where as the
charge deposited in the detector more closely related to information
carried by the actual gamma.  Thus the energy making slight weighting in
terms of the energy should give better results. This is a very hand wavy
argument of one reason, as my time is ridiculously short right now, of why
the energy is a better ordering then the time.    Next week I can look at
getting my hands on a large 60Co data set and see if I can make some
definite plots.
Also I should mention, the addback requirements for tigress and griffin are
slightly different.  Tigress is a single trigger low rate counter, it is
not currently used in a gamma singles mode - and like all in-beam
facilities, it is not clear it can be effectively used with out an external
tag to look at the event.  Such an external tag already greatly cleans up a
gamma-gamma spectrum.    For griffin, there is a worry about high rates.
However my gut feeling tells me this doesn't become a really concern until
the expected rate in a single element plus neighbors approaches our addback
time window, for 200ns window, that is 500,000 Hz over 5 crystals.  That is
still 100,000Hz in our detector which is a factor of two higher than the
desired goal of 50,000 Hz, right?
I am not sure I buy the argument about after a certain time cut off, we can
never have more than 64 gamma hits in a single event, and even at extremely
high rate - we should still have far fewer than that.
On Wed, Feb 15, 2017 at 5:17 PM, jsmallcombe<EMAIL_ADDRESS>wrote:

Can I have some clarification of what the current ordering is.
I can see Ryan's logic of time sorting allowing speed by continuing the
loop and avoiding unneeded comparisons for addback.
But this isn't done in TIGRESS. TIGRESS addback logic is heavily based on
energy arguments the Peter explained, (I recently added a whole load of
comments to the code) and assumes energy of hits and segments have been
pre-sorted.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280158324,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAacI70iTqDoE5JF6rQGXDjByCDKT_kkks5rc3mKgaJpZM4MA6gr
.

We also have descant, and sceptar, and LaBr, etc…. The ordering method I am talking about makes looping through all events more efficient. I can still find the highest energy hits and use them appropriately for addback. My thinking goes beyond addback into correlating events across detection systems and between clovers. In the GRIFFIN 2 us event window, you can easily have 3 distinct events based on CFD, but as soon as you sort by energy you mix them all up. If the first 3 of 10 hits should be added back because the other 7 are distinct, why should I have to loop through the highest energy hits of the other 7 as well? If it works for TIGRESS I think that’s fine, but I would strongly recommend against doing this in GRIFFIN.

The time sorting vs energy sorting i was referring to is only relevant
internally to the hpge detector.  When trying to compare different
subsystems, of course we must compare by time.
As far as addback goes, this may just be getting down to preference.  But
the logic to me goes position, energy, time in terms of importance to
check.  I have no proof one is faster or one gives a better sum peak to
addback ratio.  For tigress, we clearly do not have a rate issue and any
hence no effect of sorting by time.  For griffin, I am interested as to
what if any effect this actually has - but we need data and plots to take
this much further :)
On Wed, Feb 15, 2017 at 7:38 PM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

We also have descant, and sceptar, and LaBr, etc…. The ordering method I
am talking about makes looping through all events more efficient. I can
still find the highest energy hits and use them appropriately for addback.
My thinking goes beyond addback into correlating events across detection
systems and between clovers. In the GRIFFIN 2 us event window, you can
easily have 3 distinct events based on CFD, but as soon as you sort by
energy you mix them all up. If the first 3 of 10 hits should be added back
because the other 7 are distinct, why should I have to loop through the
highest energy hits of the other 7 as well? If it works for TIGRESS I think
that’s fine, but I would strongly recommend against doing this in GRIFFIN.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280190591,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAacI2s-qrrxT2nSV1hXseFFi6squHlNks5rc5pogaJpZM4MA6gr
.

I just think someone has been working with GRETINA too much… :P

I won't lie. Tracking everything makes me think about addback waaay too
much.
On Feb 15, 2017 7:59 PM, "Ryan Dunlop"<EMAIL_ADDRESS>wrote:

I just think someone has been working with GRETINA too much… :P
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280194769,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAacI-ZxIl9U4cJpSZINuXlg4ZHYN6Tbks5rc59ogaJpZM4MA6gr
.

I agree with Peter advocating energy ordered for the physics motivation.
Currently within the TTigress class there is an assumption of energy ordered hits.
The potential time saving you are advocating Ryan (by skipping ahead when coincidence searching) is a matter for a subsequent stage of sorting and the benefit of doing so is only gained if the end user doesn't use their own sorting scripts or knows this particular trick of the frag->analysis tree sorting.
Two things:

Currently how are we ordered, does tigress now need to energy sort before doing addback?
Producing the best physics results to ignorant end users should the priority over high end computing.

Tigress  hits are order by energy before they are saved to the analysis
tree, thus when they are read back, they are still ordered.
This provides the default addback scheme to work as intended for an user
with out having to know to much of the underlying details.
On Feb 15, 2017 10:23 PM, "jsmallcombe"<EMAIL_ADDRESS>wrote:
I agree with Peter advocating energy ordered for the physics motivation.
Currently within the TTigress class there is an assumption of energy
ordered hits.
The potential time saving you are advocating Ryan (by skipping ahead when
coincidence searching) is a matter for a subsequent stage of sorting and
the benefit of doing so is only gained if the end user doesn't use their
own sorting scripts or knows this particular trick of the frag->analysis
tree sorting.
Two things:

Currently how are we ordered, does tigress now need to energy sort
before doing addback?
Producing the best physics results to ignorant end users should the
priority over high end computing.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280220168,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAacI1fvgF-aJ_jex4GrwCmOIZ8aAtlTks5rc8FAgaJpZM4MA6gr
.


Can I train in local?

Hello, I have got the IAM MARG and RIMES dataset。How to deal with them to train？

Hello, I have got the IAM MARG and RIMES dataset。How to deal with them to train？

Hi, where can we found the dataset. thank you


Swagger-UI error when not using localhost

Everything works great when viewing with http://localhost/docs.
If I change to host ip, <IP_ADDRESS>, or server.info.host I get an Error {...} button on the /docs/index.html' page after the routes.  When I click on it get something like[{"level":"error","message":"Can't read from file http://<IP_ADDRESS>:8000/swagger/swagger"}]` however if I set the page directly to that url it resolves fine.
Is there something wrong with my initial config?

I will have a look into... but i guess it's a CORS issue so may just try to add cors: true to the plugin options for now.

Setting cors:true doesn't to seem to have an effect in my environment.

ahhh sorry - i didn't get the point ;-) You are referring to this:

This is the swagger schema validator which is automatically disabled for "localhost" because it uses a remote service for validation and your swagger schema (hosted on localhost) cannot be fetched from remote. I thought setting swaggerOptions.validationUrl to null should disable it completely but unfortunately it does not. "false" actually does the job but is not accepted by the validation schema. I will fix it with the next release of hapi-swaggered-ui.
Follow up here: z0mt3c/hapi-swaggered-ui#8

Great thank you for the quick response!

Where does one set swaggerOptions.validationUrl  ? I can't find it mentioned in any source files or on https://github.com/swagger-api/swagger-ui README

I found this https://github.com/swagger-api/swagger-ui/issues/630
which says where to set it but unfortunately points to a source location
https://github.com/swagger-api/swagger-ui/blob/master/dist/index.html#L33
that is not tied to a commit, so the line has moved/changed
using query parameter as per
https://github.com/swagger-api/swagger-ui#parameters
is also a poor solution (and also does not seem to work)

Using validatorUrl instead of validationUrl solved this problem for me.  I'm on tag 2.1.3.
  window.swaggerUi = new SwaggerUi({
    url: url,
    validatorUrl: undefined,

Aah!!! I was using <IP_ADDRESS> and had to modify the condition in swagger-ui.js as:
if ('validatorUrl' in opts.swaggerOptions) {
// Validator URL specified explicitly
this.model.validatorUrl = opts.swaggerOptions.validatorUrl;
} else if (this.model.url.indexOf('localhost') > 0 || this.model.url.indexOf('<IP_ADDRESS>')>0) {
// Localhost override
this.model.validatorUrl = null;
} else {
// Default validator
if(window.location.protocol === 'https') {
this.model.validatorUrl = 'https://online.swagger.io/validator';
}
else {
this.model.validatorUrl = 'http://online.swagger.io/validator';
}
}

Hi boloindia,
may I know what exactly you changed in swagger-ui.js?
thanks

@jsandeepm Since I was using <IP_ADDRESS> only so I modified the else if condition the bold part
else if (this.model.url.indexOf('localhost') > 0 || **this.model.url.indexOf('<IP_ADDRESS>')>0) **

I followed codestellar , added the else part which was not in my swagger-ui.js. It was able to read Json file in Chrome but not in IE. Any suggestions?

I was able to disable the validation by adding &validatorUrl= in the url. I give an empty url and NO http call is made. I'm using swagger-ui version 3.0.19.
Working for me : http://localhost:9000/assets/lib/swagger-ui/index.html?url=/assets/swagger/v1.yaml&validatorUrl=
Not that this way no http call is made to try the validation.
I previously tried things like &validatorUrl=null or &validatorUrl=undefined but an http call was made failing of course (note that with current version of swagger-ui parse query strings as string and a work in progress is looking to parse as json).

@laguiz you can disable validator like below (thought to share, may be it can help any one)
.EnableSwaggerUi(c => {
c.DisableValidator();
}

Setting validatorUrl to false or null solved this problem for me:
    const ui = SwaggerUIBundle({
    url: "/api/v1/doc/swagger",
    validatorUrl: false,
    // other code here...
    })


Save record to database

For posterity, here's the code I shared with @winkerVSbecks & @meodai over Discord.
Adding Color API records to Supabase
This version has a debounce function, something we might want to revisit in the future, as a a global flag for the node server, to prevent the database to hit at a dramatic rate, in case of automated attacks.
Additionally, I'd explore the impact of adding a rate-limiter middleware to socket.io with something like node-rate-limiter. It may or may not have a performance impact on the server but it's a good practice to keep some piece of mind with this stuff.