Allow for the ' character in names and descriptions

Summary
The following PR allows for the ' character in names and descriptions
Change Type
Mark the type of change your PR introduces:

[x] Bug fix (resolves an issue without affecting existing features)
[ ] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

Changes unknown
when pulling 046c5f7afa61b9eec4208da5753a51c398ea6d4b on fix-validation
into ** on main**.


Feature Request: Group Jobs

first off, awesome plugin.
I think it would be great if you could group jobs and have them be displayed under a banner with the group name.
Currently have a set up where there are 10 or so folders - each having about 3 jobs.
While I'm getting by through displaying jobs alphabetically and then having 3 columns, I see potentially problems in achieving the look and field desired if certain folders have different numbers of jobs.
If you have ever used Grafana, that's along the lines of what I'm thinking.
Let me know what you think!
Thanks,
Steven

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Thanks! I'm glad that you find it useful :-)
Sure, the capability to group jobs is something that's been requested on several occasions, but other things took priority I'm afraid - #130, #206, #246
It would be great to see this idea come to fruition though, so if you'd like to propose a PR I'd be more than happy to merge it in.
Looking forward to hearing your thoughts,
Jan


[Component] Badges

@gabrielduete @3rdepaula

@igorwessel @gabrielduete @3rdepaula is possible change the status to progress 😄

@felipefialho Okay! We are creating a task on the board for the next sprint. We will change the status as soon as we start! ❤

We started the development! :)
Task


Changed GPA alignement, such that it does not change the reference.

As discussed in Issue #175, the GPA alignment should not change the reference surface.
In this PR we fix this issue and provide an implementation which keeps the reference fixed.
Furthermore, we introduce two new convenient methods into the DataCollection class, to obtain the mean transformation and the mean surface represented by the DataCollection.
In case we find a valid use case that requires the change of reference to the mean, we could introduce a method DataCollection.changeReference(newReference : TriangleMesh), which makes this change simple but explicit.

Also agree on merging this.


Colocating form logic

tl;dr: With the major rewrite of the package (aka v6), is the opportunity to colocate most of the logic of each form together - which means they should all be in reduxForm and none in the reducer.

Normalization
The normalization, in v5, was in the reducer. Why not, for example, to enhance onChange so that each value was transformed before being dispatched?
Something like:
// generic onChange enhancer: the enhancer should receive a value and return a value
const enhanceOnChange = (enhancer) => (onChange) => (value) => (
  onChange(enhancer(value))
)

// have normalizeField that takes a value and returns it normalized
// new onChange, with normalizeField
onChange = enhanceOnChange(normalizeField)(onChange)

Sync validation
The decision for moving the sync validation to the reducer seems wrong to me. Even if the decision is to keep the error in the store - I would prefer to get the errors as a selector, since is derived data - is perfectly possible to enhanceOnChange a second time to dispatch the error after a possible normalization.
// normalizeField already have the signature correct, and don't need any help from redux-form
// for validateField is necessary an intermediate generic errorEnhancer,
// and a specify dispatchError provided by redux-form for this field

// dispatchError: provided by redux-form to dispatch the error for this specific fields
// validateField: is the validation provided by the user for this specific field

const errorEnhancerHelper = (dispatchError, validateField) => (value) => {
  dispatchError(validateField(value)) // compute and dispatch error
  return value
}

const errorEnhancer = errorEnhancerHelper(dispatchError, validateField)

const composedEnhancer = compose( // 'lodash/fp/compose'
  errorEnhancer,
  normalizeField
)

// enhanced onChange
onChange = enhanceOnChange(composedEnhancer)(onChange)

Also, if the decision is to not have the errors in redux store anymore, could have minor change in the api. Substitute the dispatchError for assignErrorToField.

ps: The important point is the colocation, the enhancer is implementation detail. But maybe could incorporate onChange enhancer for the library also so user could easily write our custom logic...
ps: I don't have deep knowledge of 'redux-form' v5, and almost none of v6. I am certainly overlooking/oversimplifying lots of things...

Yes, a lot of thought was put into the v6 rewrite.
I liked the idea of the normalization being in the reducer in v5 because it guaranteed that any dispatch(change(form, name, value)) from anywhere in the application would have normalization applied to it. However, that benefit was outweighed by exactly the argument you are proposing, and in v6, the normalization is pretty much just an enhanced onChange. See Value Lifecycle.
I tried really, really, really hard to keep the sync errors out of the Redux store, but when I finally succumbed, it made so many complex bugs disappear. It was really complicated to rerender only the field whose sync error had changed when the sync errors were coming down from the outer form component via context.

In v5, I had to implement normalizing the deep fields because IFAK redux-form didn't support it. And I almost switched to implementing all normalizing by myself, because I really value colocating the logic together - It was more maintainable to have complex code together than simple code spread apart.
Couldn't the errors be dispatched in the Value Lifecycle also? (just beside 'CHANGE action')
It will be a nightmare to have multiple forms across an app having this fundamental logic in the far away reducer, which I wouldn't like to touch.
ps: Since v6 have Field, maybe this is the proper place to declare the sync validation and the normalization. It would be further colocating the logic in the Field, instead of passing down from top-level reduxForm. But I don't wanna to push this idea now =).

Couldn't the errors be dispatched in the Value Lifecycle also? (just beside 'CHANGE action')

Yes, this has been considered. It is certainly another option.

It will be a nightmare to have multiple forms across an app having this fundamental logic in the far away reducer, which I wouldn't like to touch.

I'm not sure what "fundamental logic" you are referring to here.

Well, maybe "fundamental logic" should be refrased to "specific logic".  I was referring to the sync validation in v6 (but could be to normalization in v5 also).
IMHO it makes lot a difference to have the logic together - and not separate in component reduxForm and reducer.
Thanks for hearing my concerns and for this great package, and hope to have some way around the sync validation in the reducer - having it back in reduxForm or in the new Field would be great.

Thanks for hearing my concerns and for this great package

Thanks for voicing them. ❤

hope to have some way around the sync validation in the reducer

Sync validation isn't so much IN the reducer – It was once! 👻 – as it is "using the reducer to store sync validation errors as a way of communicating between the Form and the Field(s)".
I've enjoyed your respectful challenge to my decisions. All of OSS would be stronger if more people were like you. 👍

Looks like the sync validation in reduxForm is back! Great!


Updating astropy_helpers to 2.0.8

~Do not merge yet, it's opened for testing and needs to be updated to point to the actual release when it's released.~
This now points to the release, merge when passes.

I'm not exactly sure what goes on here. Now more test are failing than before, but it's almost certain to be unrelated to this PR.

@bsipocz I restarted the Travis jobs and they passed – can you do the same for AppVeyor?

Done. Please merge away once it passes, so I can start off the helpers update for the rest of the packages tonight (would avoid doing it while this is open as I was inconsistent with naming the branch, so it would open another update here...)

@bsipocz I don't understand why but it failed.

Yeah, weird.  Given it's windows python2, I don't really have the means to investigate.

Me neither, not sure what to do.

drop python2 :trollface:

How would you feel about merging and seeing if that build passes, and if it doesn't, then we drop Windows py2?

I always feel great when it's about withdrawing support for python2 :)

Ok, merging and hoping for the best.


Ordered nested list not numbering correctly

I have an issue with indentation of a numbered list...
I have this list
@ol[](false)
- Item1
  - subitem1
  - subitem2
-item2
@olend

This shows as
1. Item1
    2. subitem2
    3. subitem3
4. item2

Tried different numbers of indentations and empty lines, but still the numbering is wrong

Hi Henric, to clarify - can you please share an example of what it is you are expecting to see? Thanks.

Yes, sorry for not making it clearer!
The output for the above mentioned list I would expect to be ...
1. Item1
    1. subitem1   (or 1.1 subitem1)
    2. subitem2   (or 1.2 subitem2)
2. Item2

Is that possible?

Thanks for the clarification. I don't have a way for you to do what you want right now but I will try to take a look over the coming week to see if it might be done. I will update this thread with what I find.

Thanks for looking into it. Perhaps I bring it up but I would guess most people using indented ordered lists would expect that kind of output that I am describing.
I must say after trying different presentation software (Hieroglyph/Sphinx, Latex, etc...) Gitpitch is so far the best of the lot and I might have some further suggestion, which I think, could make it even better.

A quick update for this thread. I have looked into what would be involved to support the rendering of indented ordered lists as you described. And I agree, what you describe would indeed be an improvement if the GitPitch shortcut syntax for lists could support this type of rendering.
That said, this is not something that can be easily accomplished without introducing a risk to backward compatibility for existing presentations. So rather than committing to developing such a fix today I plan to leave this thread open to give the GitPitch community an opportunity to upvote the issue. If it attracts sufficient interest I will revisit the issue and consider moving it up the priority list.
In the meantime, given GitPitch already provides support for HTML snippets you can easily create the desired rendering effect using these snippets directly within your PITCHME.md.
For example, you could use the following:

One

Two

Two point One

Two point Two

Three

Four

And the output on your slide would look something like this:

Not identical to what you described, but certainly very much in the spirit of the desired outcome.

Hi André, thanks for this helpful tip. CSS counters will likely be part of the eventual solution.

This issue has been resolved. Using the following syntax for an ordered, nested list:
@ol[](false)
1. Item1
   1. subitem1
   1. subitem2
1. Item2
@olend

Renders as follows:

As noted in the Markdown List Widgets Guide you must indent nested list content using 4 spaces in your markdown file.


fix: Fix the link card width

:tada: This PR is included in version 2.0.0-next.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

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


Synchronous module installer in terminal

For #8952

Codecov Report

Merging #9032 into master will increase coverage by 0.08%.
The diff coverage is 76.31%.

@@            Coverage Diff             @@
##           master    #9032      +/-   ##
==========================================
+ Coverage   56.98%   57.06%   +0.08%
==========================================
  Files         550      551       +1
  Lines       28959    29116     +157
  Branches     4376     4415      +39
==========================================
+ Hits        16502    16615     +113
- Misses      11563    11592      +29
- Partials      894      909      +15

Impacted Files
Coverage Δ

src/client/common/terminal/types.ts
100% <ø> (ø)
:arrow_up:

src/client/common/installer/types.ts
100% <ø> (ø)
:arrow_up:

src/client/common/types.ts
100% <ø> (ø)
:arrow_up:

src/client/common/installer/pipEnvInstaller.ts
65.38% <100%> (ø)
:arrow_up:

src/client/common/terminal/service.ts
92.98% <100%> (ø)
:arrow_up:

src/client/common/installer/pipInstaller.ts
59.37% <100%> (ø)
:arrow_up:

src/client/common/installer/condaInstaller.ts
90.24% <100%> (ø)
:arrow_up:

src/client/common/installer/poetryInstaller.ts
83.33% <100%> (ø)
:arrow_up:

src/client/common/terminal/factory.ts
96.29% <100%> (+0.84%)
:arrow_up:

src/client/common/utils/localize.ts
94.63% <100%> (+0.03%)
:arrow_up:

... and 13 more

Continue to review full report at Codecov.

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


Reward Lens

add RewardLens contract where you can store borrow and supply joe/avax reward rates per market
add all related rewards to  jTokenMetadata struct in joeLens

nice, will defer to @cryptofish7 @LouisMeMyself for final stamp!
one last suggestion but def not a blocker is it would be great to have some basic tests for these methods 👍

Yes agree with nivek here. I'd add some quick tests here just to sanity check the values return what is expected.


Handling velocitiy discontinuities correctly in Dircon cost

Implementation of a more general version of #231.
Creates a Substitution member variable in Dircon that replaces the velocity variables with the correct post-impact velocity variables.

This change is

Oops this was branched off from the wrong branch.


How to run the application?

Hi,
I have both VS Code and VS 2017.
How to run the code and test the application? I put AngularClient and StsServerIdentity to run. But the Sts project defines the client with IP of the ASP.NET Core app and not the Angular app.
I am a bit confused on how to run the apps?

Hi @bhaidar
You need to build the angular app and and the APIs
Use npm to install the npm packages for the Angular client project. Then do an angular build, npm run build-dev, then build the .NET Core solution.
Start the 2 APIs, the STS server, and the Angular client. When you run it first, it should ask you the trust the iis express certs, and then it runs.
Greetings Damien

Hi @damienbod
Perfect!
Let me summarize the steps here in case someone else faced the problem.

Follow the instructions on the README.md file to restore .NET packages and do the migrations.
Build the entire solution in Visual Studio
From the command line, run npm run build-env to build the code and generate bundles
Then simple configure Visual Studio to run multiple projects including StsServerIdentity, AngularClient, ResourceFileServer, and ResourceServer.

That's all!
Two things I noticed though:

You make use of:
"ConnectionStrings": {
  "DefaultConnection": "__DefaultConnection__"
}

Is that an environment variable you set somewhere in production?

When the app first loads, the menu items are not showing (exception for languages). I look at the code, there is nothing hiding/showing them when the user is logged in or not. Why weren't visible at the beginning before signing in?

Thanks

@bhaidar thanks

@damienbod
Thanks. So basically I either make use of EV or provide a simple string for the ConnectionString for example. Correct?


Update list.json

Adding "vlutsas/DST" - SAP Data Scrambling Tool

thanks, note that it might take up to 24 hours for it to appear on the homepage


Very thin hollow/transparent gap/background between mini-map and scrollbar (on split editor)

On Zoom level = -1, there is a tiny gap between mini-map and scrollbar where underlying text is visible, causing distraction. An screenshot attached.

Does this issue occur when all extensions are disabled?: Yes/No
YES

VS Code Version: 1.89.1
OS Version: macOS Sonoma 14.5

Steps to Reproduce:

Set zoom level to -1
Open split editor

This is caused by using zoom level and the way it is implemented by Chromium and the way different rounding errors are handled. On a logical level, we position rectangles at pixel-perfect CSS coordinates. For pixel perfect screen rendering, please use zoom level 0 and adjust the font size.

Thanks for the note @alexdima. I am using 24" 4K display usually, problem seems bigger on it, then the 14" MacBook screen. On without zoom, everything becomes bigger, using unnecessarily more space. Anyway, I will try disabling mini-map.


Depend on a Conan ZLib package

Once the dust has settled after the Conan move to Bintray, it would be prudent to require a Conan package for ZLib instead of a system install.

Fixed in 7a04b8240346a9c5d8003063d14b42379a838dc2


versions: Update cri-o to fix race condition test.

Some test were CI test were failing due to a race condition.
Update cri-o repository to have a stable CI.
Fixes: #435
Signed-off-by: Jose Carlos Venegas Munoz<EMAIL_ADDRESS>

do not merge  - still see some fails - update to branch 1.11 to verify if is the branch 1.10

@jcvenegas we need the commit e0dd8a3d4c9e5ebc8b25299950bd5b222e3783d3, was it the one you were using ?

lgtm

Is this ready for merging? @jcvenegas
LGTM

I think it is, but needs to be merged along https://github.com/kata-containers/tests/pull/462

merging this one as https://github.com/kata-containers/tests/pull/462 is already merged.


Preview of marking orphaned models internal in all track 2 mgmt libraries

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API changes have been detected in Azure.ResourceManager.Resources. You can review API changes here

API changes have been detected in Azure.ResourceManager.AppConfiguration. You can review API changes here

API changes have been detected in Azure.ResourceManager.EventHubs. You can review API changes here

API changes have been detected in Azure.ResourceManager.CosmosDB. You can review API changes here

API changes have been detected in Azure.ResourceManager.KeyVault. You can review API changes here

API changes have been detected in Azure.ResourceManager.Compute. You can review API changes here

API changes have been detected in Azure.ResourceManager.Sql. You can review API changes here

API changes have been detected in Azure.ResourceManager.Network. You can review API changes here

API changes have been detected in Azure.ResourceManager. You can review API changes here

API changes have been detected in Azure.ResourceManager.ServiceBus. You can review API changes here

API changes have been detected in Azure.ResourceManager.Storage. You can review API changes here

API changes have been detected in Azure.ResourceManager.DeviceUpdate. You can review API changes here

API changes have been detected in Azure.ResourceManager.WebPubSub. You can review API changes here

API changes have been detected in Azure.ResourceManager.EdgeOrder. You can review API changes here

API changes have been detected in Azure.ResourceManager.ExtendedLocation. You can review API changes here

API changes have been detected in Azure.ResourceManager.StoragePool. You can review API changes here

API changes have been detected in Azure.ResourceManager.ConnectedVMwarevSphere. You can review API changes here

API changes have been detected in Azure.ResourceManager.Cdn. You can review API changes here

API changes have been detected in Azure.ResourceManager.AppService. You can review API changes here
API changes
-     public class PrivateLinkResourcesWrapper {
-         public IReadOnlyList<PrivateLinkResource> Value { get; }
-     }
-     }
-     public enum ManagedServiceIdentityType {
-         SystemAssigned = 0,
-         UserAssigned = 1,
-         SystemAssignedUserAssigned = 2,
-         None = 3,


Use executor name instead of id for metrics tests

(Missing JIRA in the title)
I think we should wait on merging this until the metrics endpoint is fixed so that we can enabled the previously disabled tests and make sure this is working as expected.

The 500 error fix is at https://github.com/mesosphere/dcos-enterprise/pull/3420. That PR is waiting for review, but we can test this one against it in the meantime.

ill go ahead and spin up a cluster against your PR and try the test @branden

@kvish there's a PR here: #2664 that adds a test similar to the ones for the other data services. This should allow us to use this as a smoke test for future metrics changes too.

@elezar @mpereira updated from the diff kevin posted in the ticket, and unsilenced your tests, once the data services tests are passing against this PR should be good to go


IndentationTypeFixer - Fix description and upgrade guide

for ref.: https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/2439

Thank you @SpacePossum.


Passwordbox can not show key

The password box has an option to show the key but this does not work. The issue is the custom style being used for some reason we Have to instead modify the existing passwordbox button style. This is an easy fix

hey @FireCubeStudios,  I would like to work on this

Please assign this to me

Hi  @FireCubeStudios I can  help you with this issue. Can you would assign it to me?

Hi i have already assigned two people to this issue. Would it be possible to do another one?


feat: add a script to help user generating a token and a new password

Small PR to improve user UX while handling password.

My idea is, it’s not a nice UX for user to start on our app to need to white python script directly.
So I wanted to make it improved at first.
Do you have a better idea? maybe a dedicated "webpage" just for that password?

As suggested by Tom, a notebook might be a better compromise

Aborted.


Create Centos 7 EOL blog post

Description of change

Checklist

[x] npm test passes
[ ] documentation is changed or added (if applicable)
[ ] permission has been obtained to add new logo (if applicable)
[x] contribution guidelines followed here

@gdams shellcheck doesn't like the date format

@gdams shellcheck doesn't like the date format

fixed, it was actually the regex in the command that we use to scrape the date that was incorrect


lodash cleanup and fix for no local timezones

Replaced _.where by _.filter and made sure that local and primary timezones are just added if there is at least one

I've merged this and released it as v1.6.0. For some reason there were conflicts so GitHub hasn't seen the changes from here as being merged, but they have been.

Also sorry for spelling your name wrong in the readme!


Add some sort of a badge to the package if it contains scripts

In the last meeting we make a suggestion to add a badge or some other indicator on the frontend to inform the user the package contains scripts
cc @phorcys420

@AucaCoyan  Hey, I would like to contribute on this issue


Mod conflict with Oh the Biomes You'll Go?

https://mclo.gs/XRyJqqB
I'm seeing a lot of errors like [14:06:27] [Render thread/ERROR]:  Parsing error loading recipe forgero:ebony-broadsword_blade com.google.gson.JsonSyntaxException: Unknown item 'byg:ebony' all through the logs, but the game gets to the main menu just fine. When trying to load into a world, however, it fails with [14:06:42] [Netty Local Client IO #0/ERROR]:  Exception occurred in netty pipeline java.lang.StringIndexOutOfBoundsException: offset 586, count 12827, length 5433
Removing Forgero fixes this.

First and foremost there are ALOT of errors in that log. Also alot not caused by forgero. The parsing errors and the type errors shouldnt make it crash. It just says it doesnt recognize the ID's we put in the files for some reason. Weird as some of them also reference normal minecraft ID's that should work.
The exit errors is related to emi_loot I have personally not used that so I wouldnt know if that works together.
The inbetween errors are more interesting as those literally show the recipe creator breaking for some reason.
I cant narrow this down, maybe sigmund could but its not a conflict with BYG. Its a mod conflict with something else probably.

On 1.20.1 BYG works for me, though I did compile BYG from source myself.

This looks a lot like the issue that was caused by emi loot + forgero. In that case it was due to the number of loot entries on some entities

This looks a lot like the issue that was caused by emi loot + forgero. In that case it was due to the number of loot entries on some entities

fzzyhmstrs.emi_loot.util.TextKey.fromBuf(TextKey.java:278) ~[emi_loot-0.6.1+1.19.jar:?]
Yes, I think this is the same issue again.

I would recommend upgrading the emi loot version and trying again. 0.6.1 was released in February.

Np, hope it works!

Updating EMI-Loot worked! I'm in and can see all the forgero recipes in EMI.


Fix typos (variable/translations), Fixed/Added some translations for .de, Switched event listener keypressed (deprecated) to keyup, Replaced static message

Some typo fix (also to have uniform variable naming, camel case)
Fix for the new/correct variable name in all translation files
Added/fixed .de (german) translation file
Switched event listener keypressed (deprecated) to keyup
Replaced static message with internationalized message
Off Topic: Wonderful work you have done, really - like it ;)

Many many thanks!

You're welcome
Try to support / "give back" where i can ;)

Thanks for your contribution!
Could you make this pull request into "develop" branch? You will see there will be conflicts because keypressed-issue is already addressed there ;)
There is a typo in translations ("miccophoneUnMute")

Sure, placed new pull request into develop branch.
So this one can be removed.
;)


Provide a mechanism for handling large content in TagHelper

In TagHelperOutput the mechanism to communicate the content is through a string. If the tag helper ever renders over 80K of data, it is going to end up in LOH, causing multi-second pauses. Further more, strings are constantly being generated by a StringBuilder  and through testing we did with MVC5 we realized that a large portion of the runtime (could be in the 20% range) is spent in garbage collection (see http://blogs.msdn.com/b/webdev/archive/2014/07/28/announcing-the-beta-release-of-web-pages-3-2-1.aspx)

Closing this since we've designed a replacement: https://github.com/aspnet/Razor/issues/296


[WIP] Add support for external load-balancer to access OpenStack APIs

On the high level, this allows to specify that a service/port should be
be exposed externally (to the cluster) on a specific host/port
(<service>.<external_domain>:<external_port>).
To do this, Ingress controllers are exposed through a service listening
on every nodes on <external_port> (NodePort). Any request to the
cluster's nodes on that port will be forwarded to one of the Ingress
controller with the help of the Kubernetes' service load balancing
mechanism. the controller will in turn forward the request to the proper
service backing the OpenStack APIs, based on the request' host.
Multiplexing is done based on host (<service>) instead of path (i.e. <external_domain>:<external_port>/<service>). Multiplexing on path is a bit more tricky and less maintainable in my opinion. While it still requires DNS resolution anyways (right, a single domain instead of a wildcard domain), we can't simply strip the prefix off before passing the requests to the OpenStack APIs because they love to return back to the clients absolute paths to follow to continue the interaction (i.e. KeyStone). We'd have to pass the requests with the prefix and configure apache wsgi / composite:rootapp accept/understand prefixed requests.
The potential extra roundtrip between the node (NodePort) and the
Ingress Controller allows us to deploy the controllers in a
high-availability and scalable way, on a specific set of nodes, while
still being able to access them via any nodes. It also provides us the
guarantee of always accessing a ready/working controller as their
health are monitored by Kubernetes and are behind a service. Oppositely,
if we would expose the controllers directly using a hostPort (which is
not currently supposed by the kubelet's CNI implementation) or using the
host network, an external regular DNS resolution may more likely lead us
to a dead/unavailable controller/node.
This PR includes traefik as the Ingress controller but virtually any other controllers could be used (nginx, vulcan, haproxy, ...).
Reviews are much appreciated - this isn't a small change.

Next step is to secure external endpoints using SSL/TLS.

Can we make this optional in Stackanetes ? Prepare an option in stackanetes.conf to deploy it or not ?

Yes, that makes a lot of sense, I am implementing it into the kpm repackage. I'll demonstrate it and provide instructions soon.

Side note:
We might replace Traefik with any Ingress controllers. Nginx, for example, has the advantage that it doesn't forward requests to services but to pods directly. However, due to way Django generates absolute URLs for redirections and refs in the OpenStack APIs, the configuration of the nginx controller and OpenStack would have to be tweaked slightly. By default, Django doesn't use X-Forwarded-For headers but the Host header or a combination or SERVER_NAME / SERVER_PORT [1]. Every OpenStack clients passes the Host header and Traefik forwards it without modification, while nginx doesn't - replacing it with $host, which doesn't contain the port [2]. The issue is that Django will then generate URLs using the standard HTTP port - while the service must be accessed through our Ingress controller, on a custom port (30000-32767). The solution would be to tweak nginx to pass proper X-Forwarded-For headers depending on our NodePort configuration and then enable support for X-Forwarded-For on every OpenStack API services. A workaround is to replace $host by $http_host. Now, from few tests that I ran, with the default settings, it seems that Nginx is way slower than Traefik - so I don't believe that the effort is worth it. A good reason to replace Traefik by Nginx would be for SSL support for every OpenStack endpoints, but again, the URL generation assumes that http is the scheme, except if SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') is configured - and while it has been added to some services in Mitaka, it appears that certain OpenStack services won't support it until Newton.

Closing in favor of #87.


no way to suppress gptj_model_load: output lines

How can I suppress these output lines?

I found someone with the same request at https://stackoverflow.com/questions/76161686/output-full-response-as-string-and-suppress-model-parameters, but no answer there.

@semorrison I think I answered that question in the discussions, check it here #98

Thanks --- unfortunately the gptj_model_load output is also on stdout, so your answer doesn't help.

Oddly enough, pygpt4all.models.gpt4all 's output are suppressed/non-existent via cpp_generate, but not pygpt4all's outputs for some reason from a similar cpp_generate function.
Tried to also modify the source code (%AppData% ...\Local\Programs\Python\Python39\Lib\site-packages\pygpt....\pygptj\model.py)
.... related to the unsuppressed output with no success to be similar to the other cpp_generate (%AppData% \Local\Programs\Python\Python39\Lib\site-packages\pyllamacpp...\pyllamacpp\model.py) that doesn't print output to cmd.

Using cpp_generate instead of generate seems to partially solve the issue:
from pygpt4all import GPT4All_J

AI_MODEL = GPT4All_J('data/models/ggml-gpt4all-j-v1.3-groovy.bin')

def TEXT_CALLBACK(text):
    print(text, end="")

AI_MODEL.cpp_generate(input_prompt, n_predict=128, new_text_callback=AI_NEURAL_AGENT.TEXT_CALLBACK)

Oddly enough, pygpt4all.models.gpt4all 's output are suppressed/non-existent via cpp_generate, but not pygpt4all's outputs for some reason from a similar cpp_generate function.
Tried to also modify the source code (%AppData% ...\Local\Programs\Python\Python39\Lib\site-packages\pygpt....\pygptj\model.py)
.... related to the unsuppressed output with no success to be similar to the other cpp_generate (%AppData% \Local\Programs\Python\Python39\Lib\site-packages\pyllamacpp...\pyllamacpp\model.py) that doesn't print output to cmd.

Using cpp_generate instead of generate seems to partially solve the issue:
from pygpt4all import GPT4All_J

AI_MODEL = GPT4All_J('data/models/ggml-gpt4all-j-v1.3-groovy.bin')

def TEXT_CALLBACK(text):
    print(text, end="")

AI_MODEL.cpp_generate(input_prompt, n_predict=128, new_text_callback=TEXT_CALLBACK)

Oddly enough, pygpt4all.models.gpt4all 's output are suppressed/non-existent via cpp_generate, but not pygpt4all's outputs for some reason from a similar cpp_generate function.
Tried to also modify the source code (%AppData% ...\Local\Programs\Python\Python39\Lib\site-packages\pygpt....\pygptj\model.py)
.... related to the unsuppressed output with no success to be similar to the other cpp_generate (%AppData% \Local\Programs\Python\Python39\Lib\site-packages\pyllamacpp...\pyllamacpp\model.py) that doesn't print output to cmd.

Looks like it boils down to "pp.gptj_generate" in "(%AppData% ...\Local\Programs\Python\Python39\Lib\site-packages\pygpt....\pygptj\model.py".

The above is derived from importing _pygptj as pp, and _pygptj seems to be related to "_pygptj.cp39-win_amd64.pyd", a DLL like object, which is reasonably closed off.

Since there's apparently no external "flag" that seems to suppress/desuppress cmd printouts of output tokens, it's left to modify the internal items which seem compressed into the .pyd object.


About using ddim50 on face dataset

I found an issue when I use ddim50 sampling aftrer training ddpm-ip on my own face dataset. The sampled images have much noise (however using ddpm50 is ok). I tried to use pre-trained celeba ckpt you provide and found the same problem.
mpiexec 4 python scripts/image_sample.py
--image_size 32 --timestep_respacing ddim50 --use_ddim True
--model_path DDPM_IP_celeba64.pt
--num_channels 192 --num_head_channels 64 --num_res_blocks 3 --attention_resolutions 32,16,8
--resblock_updown True --use_new_attention_order True --learn_sigma True --dropout 0.1
--diffusion_steps 1000 --noise_schedule cosine --use_scale_shift_norm True --batch_size 256 --num_samples 50000

@Suimingzhe Hi, for the DDIM sampling, I use the DDIM official code to do training and sampling. I remember that I also had some issues when using ADM code to do DDIM sampling.
Could you please check if the ADM-IP celeba checkpoint can do normal DDPM sampling?

@forever208 Thanks for your reply. I checked the sampled images again and here are the results.
For cifa10, using pre-trained ADM-IP，ddpm50 is normal, ddim50 seems normal.
For celeba, using pre-trained ADM-IP, ddpm50 is normal, ddim50 is unnormal(much noise).
For my own face dataset(similar to celeba), after training ADM-IP, ddpm50 is normal, ddim50 is unnormal(much noise).
The hyperparameters on my own dataset are the same as training celeba only except for '--img_size=256*256'.

@Suimingzhe hi, thanks for your info, I will check the DDIM sampling results today using pre-trained ADM-IP and let you know.
Currently, my only suggestion is that, if you wanna test the performance of DDIM-IP, you'd better use DDIM official code for training and inference. (but one major problem is that training on DDIM code is very slow)

@forever208 Thanks for your suggestion.

Hi @Suimingzhe, I confirmed your noisy DDIM samples using ADM-IP on the ADM code. So I suggest you train DDIM-IP on CelebA.

@john09282922
refer to the section  "Simple to implement Input Perturbation in diffusion models
" of the readme file

@john09282922 you should make the modification on their script 'ddim/functions
/losses.py'

@john09282922 e in DDIM is epsilon in DDPM. I am not clear about 'you are using x_start after the idea equation', what does it mean?

@john09282922 w is equal to th.rand_like(e)


Patch 3

Small section about profiling and debugging.

Work in Progrerr

Looks good, but before merging with the master, I think these should be first merged with the two existing branches: https://github.com/CSCfi/csc-user-guide/tree/debugging and https://github.com/CSCfi/csc-user-guide/tree/profiling.
I can do the merge, so we have a single WIP branch that we can iterate over.


prepare for installing from github

Whoops, I didn't mean to open this PR on editor-js. Maybe once I've tested it.

I tested this, and it works.
This allows installing from github directly with npm 5.
See also https://blog.jim-nielsen.com/2018/installing-and-building-an-npm-package-from-github/

Thanks for the PR


Remove duplicate pull of token/blockchain docker images

With the addition of Stack.VersionManifest, that manifest is now the de facto
source of all images for the stack. There is no need to iterate over the
plugins' Docker service definitions a second time (which are now also generated
from the same VersionManifest).
Fixes #119

There are images provided by the blockchain provider that are not in the manifest file though. For example, geth, besu, ethsigner, fabric-peer, fabric-orderer, fabric-ca.
The problem is that docker compose up does not retry on pull. So if pulling an image fails for any reason it will remove the docker compose stack and exit. This means that in our E2E tests, if an HTTP timeout is encountered pulling one of these images, the entire test run will fail, when a simple backoff and retry would have worked.
I agree that some work needs to be done here. It sounds like we just need to deduplicate the images in the list that get pulled. But I just wanted to provide a bit background info on why explicitly pulling with retry was important.

Fixed by #177


[CT-1454] [Bug] dbt-bigquery 1.3.0 compatibility issue with apache-airflow-providers-google

Is this a new bug in dbt-bigquery?

[X] I believe this is a new bug in dbt-bigquery
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
I want to use last version of dbt==1.3.0 with my Airflow, I have Airflow version 2.4.2, and dbt-core==1.3.0. I also need to install apache-airflow-providers-google to work with GCP.
Tried to install with docker container and locally, same behaviour.
Expected Behavior
There is no issue with previous version of dbt and airflow:
apache-airflow==2.2.2
apache-airflow-providers-google==8.4.0
dbt-core==1.2.0
dbt-bigquery==1.2.0
So I'm expecting to fix this dependencies with new one.
Steps To Reproduce
here it is list with my requirements:
apache-airflow==2.4.2
apache-airflow-providers-google==8.4.0
dbt-core==1.3.0
dbt-bigquery==1.3.0
Relevant log output
The conflict is caused by:
    apache-airflow-providers-google 8.4.0 depends on google-cloud-storage<2.0.0 and >=1.30
    dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0

Environment
- OS: macOS Monterey, Linux version 5.15.64-0-virt (buildozer@build-3-16-aarch64) (gcc (Alpine 11.2.1_git20220219) 11.2.1 20220219, GNU ld (GNU Binutils) 2.38) #1-Alpine SMP Mon, 05 Sep 2022 08:02:49 +0000
- Python: 3.9.6
- dbt: 1.3.0
- Airflow: 2.4.2
- dbt-bigquery: 1.3.0

Additional Context
No response

hi @driazanova, per this similar issue/discussion: https://github.com/dbt-labs/dbt-core/issues/6128#issuecomment-1295624967 I'm going to close this as won't fix -- the latest version of dbt does support the latest version of Airflow, and we feel that's the best we can guarantee at this point
I'd recommend for the apache-airflow-providers-google to similarly upgrade to the most recent version of airflow. we are looking to loosen our dependencies in general, but it's not something we'll want to track in individual tickets here

hi @lostmygithubaccount the problem here, I've tried with the latest version of Airflow (2.4.2) and dbt-core 1.3.0. works, but dbt-bigquery 1.3.0. is not compatible with any version with apache-airflow-providers-google. apache-airflow-providers-google 8.4.0 is the latest version for this package.
The problem here, if I have to work with bigquery I can't do this without apache-airflow-providers-google and it seams that I can't work with dbt-bigquery 1.3.0. in the same time.
The conflict is caused by:
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 8.4.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 8.3.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 8.2.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 8.1.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 8.0.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 7.0.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 6.8.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 6.7.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 6.6.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 6.5.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 6.4.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 6.3.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 6.2.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-dataproc>=4.0.3
apache-airflow-providers-google 6.1.0 depends on google-cloud-dataproc<4.0.0 and >=2.2.0
dbt-bigquery 1.3.0 depends on google-cloud-dataproc>=4.0.3
apache-airflow-providers-google 6.0.0 depends on google-cloud-dataproc<2.6.0 and >=2.2.0
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 5.1.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 5.0.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 4.0.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 3.0.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 2.2.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 2.1.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 2.0.0 depends on google-cloud-storage<2.0.0 and >=1.30
dbt-bigquery 1.3.0 depends on google-cloud-storage>=2.4.0
apache-airflow-providers-google 1.0.0 depends on google-cloud-storage<2.0.0 and >=1.16

@driazanova I believe this would then be a bug on apache-airflow-providers-google to update to the most recent version of google-cloud-storage -- I would suggest opening an issue here per the issue tracker link from their PyPi page: https://github.com/apache/airflow/issues
the airflow packages are not something we have control over, and we do want to keep our dependencies on the latest stable releases

Note that it's not currently possible to install the latest version of dbt-bigquery by itself either: https://github.com/dbt-labs/dbt-bigquery/discussions/361.


SDWebImage/SDWebImageManager.h not found

SDWebImage/SDWebImageManager.h not found in IDMPhoto.h

I have same issue in my swift static library project.
Following references are not found.
// IDMPhoto.h

#import <SDWebImage/SDWebImageManager.h>

// IDMZoomingScrollView.h

#import <DACircularProgress/DACircularProgressView.h>

+1

+1


Tidy up error page spacing/list

Only render the SpacingSection that wraps the Body if the Body has something in it.
Also, use lis inside the ul on the 404 page.

@davidpmccormick - flow is broken


Create new Property from OpenRefine

Is your feature request related to a problem or area of OpenRefine? Please describe.
This is a suggestion request to be added in OpenRefine. Currently OpenRefine supports creating new Items. It would be nice if an option is added to users to Create new Property similarly.
Describe the solution you'd like
Openrefine helps to create new Items (Special:NewItem) and update the existing Items in Wikidata. If there is an option to create new Property (Special:NewProperty) it can help Administrators and Property creators to do the creation easier.
Describe alternatives you've considered
Currently no tools are easily available for creating new Property. Administrators/Property creators needs to go to Special:NewProperty and Manually create a Property. And also needs to enter every statements and needs to save every statement separately.
Additional context
The Special:NewProperty option will work for only Administrators and Property creators. So no other edits will create the Property.

@jinoytommanjaly Where will you extract the data for the creation of the property from? And if you do have the data, why do you think the simplest way to import them into Wikidata is with OpenRefine. Maybe QuickStatements would work just fine? :)

@VojtechDostal The data for creating the Properties can taken the pages listed under the Category:Properties ready for creation in Wikidata. Always the QS is simplest way than OpenRefine. But in OpenRefine the Property creator can create a Scheme and Visualize how the edits going to be happen.

This should be quite a lot easier now, because we had to add support for editing multiple types of entities for the Wikimedia Commons integration project.
As things stand, this suggests the following steps:

write a reconciliation service for properties (externally to this repository)
implement the required backend classes (PropertyEdit similar to ItemEdit, a schema expression for property datatypes…)
update the schema editor and edit preview renderer to add support for those

Still a sizeable amount of work but following the existing infrastructure (with items and mediainfo entities) should get us a long way. (I am personally not planning to work on this though)

When building a reconciliation service for properties, it could be worth keeping in mind its use case for variable properties in schemas (when editing items, for instance): https://forum.openrefine.org/t/reconciling-properties/1744/3


GLTF2 Importer

I had a lot of luck reversing the polarity and doing this for the Godot importer to be an exporter.
What do you think about making this a gltf2 importer too?

That would be great, but I have way too much other work on my plate right now :(

Can you describe a rough sketch how to do this? Not sure but it seems possible.

I guess an importer would be easy, since Maya is so powerful, it can easily express the limited subset of features that GLTF exposes.
Of course ideally we would like a round trip importer: when exporting the imported GLTF again, you get the same file (modulus some ordering). But that's another step.

I might look into this on my breaks. I'll wait till 1.0 is out though.

Nice! I'm not planning any changes anymore to the 1.0 rc3, just bug fixes
that comes in. So this will become 1.0 in a week or so.
On Wed, Jul 22, 2020 at 5:24 PM K. S. Ernest (iFire) Lee <
<EMAIL_ADDRESS>wrote:

I might look into this on my breaks. I'll wait till 1.0 is out though.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/iimachines/Maya2glTF/issues/116#issuecomment-662518122,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AASHK36BNNK6SMUM43LX3EDR44ACDANCNFSM4JTZRVKQ
.


Use JSON.mapping for Generators

This is a start to #95, sorta side-glances at #100, and I believe it also fixes #103 (although "fix" is somewhat subjective, in this case, I suppose 😄).
Hoping for some feedback before I get too far along. The commits in this PR are mostly single purpose, and I've broken them out thusly ...

f1c9cfd - labeled this a refactor, but I ended up rewriting/duplicating a decent chunk of the generator logic. Sorry about that. I really didn't intend for it to happen that way, but I struggled quite a lot with the type system, JSON.mapping and ECR.def_to_s, and this is the result.

b57f8c6 - migrates the hello-world exercise.

16dd07b - migrates the flatten-array exercise. It also adds a macro for creating something like a finite "recursive type/alias" (since recursive types don't seem to work with JSON.mapping). This helps remove the  _i64 notation issue in the exercise. I'd be happy to hear I've just missed an obvious concept here. I would assume there's a better way to handle this type of issue in general.

1af210c - migrates the acronym exercise.

1052d1e - adds a new-style generator for the bob exercise. I also followed the instructions in #103 to remove .meta/description.md and regenerate the README.

The tests pass locally, but I'm relatively new to crystal and I've probably trampled over any sort of standards/best-practices and fallen into several traps. So, your guidance and feedback are greatly appreciated.
If there's any interest in this, in part or whole, I'll gladly update the top-level README to reflect what remains. Or if you think it would be better to resubmit as several smaller, incremental changes I am happy to do that too.
Thanks in advance!

@martinwalsh , not trying to leave you hanging, I just haven't gotten to looking at this.
I'm going to try to get to this tomorrow.
Just ahead of all the review... thanks for the effort into fixing our issues and giving this repo a refresh. It's greatly appreciated :)

Hi @mhelmetag, no worries! No rush, as far as I'm concerned. My main objective here is really just to learn crystal, anyway, and I feel that this particular exercise has been super helpful in that regard already. So if you're able to review and provide feedback, whenever that might be, it's icing on the cake for me and I am very grateful for your time and effort!
That said, I've had a bit of free time so I continued with generator migrations in another branch, finished up with the existing exercises, fixed a bug or two and started translating new exercises from the problem-specifications repo.
If you're able to review the generator changes here, and you have interest in moving forward, I will be very happy to cherry-pick those other commits and submit individual PRs.
Either way, thanks very much!

Hi @mhelmetag! I've been giving it some thought and I think this PR perhaps goes too far (includes too many changes). I'll trim down the initial contribution, and open a new PR soon that will hopefully allow for a more iterative approach with fewer and smaller incremental changes.


Extends specs of Exception#detailed_message

There are a few additional cases for empty messages

Thank you!
There logic related to highlighting seems not covered well enough.


[WIP] Automatically Find Inactive Reconciler Errors

Motivation
Fixes #24.
Solution

Open questions

Naive solution is working on https://github.com/coinbase/rosetta-cli/pull/26/commits/7f4df7c6b35cd942d5aa5a65671c293c9adeed1a but it is very ugly

Pull Request Test Coverage Report for Build 1103

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 75.299%

Totals

Change from base Build 1091:
0.0%

Covered Lines:
378

Relevant Lines:
502

💛  - Coveralls


feat: allow overriding subscription url

Optionally override subscription URL
It's a breaking change with the config.
From:
override_routing_url:
  subgraphs:
    subgraph-1: http://subgraph-1:80/graphql

To:
override_routing_url:
  subgraphs:
    subgraph-1:
      # required
      url: http://subgraph-1:80/graphql
      # optional, will default to url when not provided
      subscription_url: http://subgraph-1:80/graphql/ws

Motivation and Context

[ ] Tests or benchmark included
[ ] Documentation is changed or added on https://app.gitbook.com/
[ ] PR title must follow conventional-commit-standard

Hi @cs-clarence, good point. I'm curious, does it come from a requirement when running the router in production or is it nice to have?


Create Readme

Add node & npm version to the readme
Create an issue for updating the readme/wiki with instruction on setting up libnfc on the raspberry pi.

Wrote an initial readme and an extra issue.


added support for encrypted ssh-keys

Issue #241  solved
Modified function parsePrivateKey only in github.com/sosedoff/pgweb/blob/master/pkg/client/tunnel.go

@mdnight Do you have any additions to this PR? I dont see any changes to the UI where you're supposed to put your private key password.

it supposed to use a field 'ssh password'

@mdnight which might be misleading. the ssh password field is supposed to represent the password for the user account the end user is trying to login with.


fix: support different from addresses on amazon delivered emails

Proposed change

Allow more amazon delivered email from addresses.
Type of change

[ ] Dependency upgrade
[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (which adds functionality)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests
[ ] Documentation update
[ ] Adds a new shipper
[ ] Update existing shipper

Additional information

This PR is related to issue: #925

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.10%. Comparing base (8608d22) to head (55fa639).
Report is 17 commits behind head on dev.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #940      +/-   ##
==========================================
- Coverage   95.07%   93.10%   -1.97%
==========================================
  Files           8        8
  Lines        1482     1552      +70
==========================================
+ Hits         1409     1445      +36
- Misses         73      107      +34

Files
Coverage Δ

custom_components/mail_and_packages/const.py
100.00% <100.00%> (ø)

custom_components/mail_and_packages/helpers.py
92.51% <100.00%> (-2.21%)
:arrow_down:

... and 3 files with indirect coverage changes


Add link markdown style in bio

Fixes Issue
where the links in the bio were lacking the app's link styles (see screenshot) #7152
Closes #7152
Check List (Check all the applicable boxes)

[X] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[X] All new and existing tests passed.
[X] This PR does not contain plagiarized content.
[X] The title of my pull request is a short description of the requested changes.

Screenshots
fixed

Note to reviewers
@eddiejaoude @SaraJaoude
Please review and merge this pull request. It addresses the issue where the links in the bio were not displaying the app's link styles. To fix this problem, I have overridden the <a> tag in react-markdown to ensure that the links in the bio have the correct styling.
I have thoroughly tested the changes and verified that the links now appear with the desired app-specific styles. Additionally, I have ensured that the changes do not introduce any regressions and that all existing tests pass successfully.
Your feedback and review are greatly appreciated. Thank you for your time and assistance in merging these improvements!

Hi @eddiejaoude , thank you for your feedback. Just to confirm, regarding the changes you mentioned, do you want me to:
1)Apply my styles globally to the Link component, or
2)Remove my custom styles and revert to using the existing global styles for the Link component?
Could you please provide further guidance on how to proceed with this?

Thanks @harshpatel-r , we would like to keep the current link style consistent, so option 2 please

Closes #7152
hii @eddiejaoude ,
I have made updates to the code based on the feedback received. Please review the changes and provide your feedback on the following:
Changes Made:
Updated the bio links style with the Link component.
Screenshots


upload files

Coverage increased (+0.3%) to 96.398% when pulling ab343a2e844dd14047621a9c626a42594b272c7e on upload-files into 3a44612526aaac8bddb79c3c6b546bcda4ea4b9c on master.

Coverage increased (+0.3%) to 96.398% when pulling 2ac4d4026aeb3074f52d0f0a914c06750b896ebf on upload-files into 3a44612526aaac8bddb79c3c6b546bcda4ea4b9c on master.

Coverage increased (+0.3%) to 96.398% when pulling d6c6b4317caf10491d9f3395c0e2711c7d0974f1 on upload-files into 3a44612526aaac8bddb79c3c6b546bcda4ea4b9c on master.

Coverage increased (+0.3%) to 96.398% when pulling d6c6b4317caf10491d9f3395c0e2711c7d0974f1 on upload-files into 3a44612526aaac8bddb79c3c6b546bcda4ea4b9c on master.

Coverage increased (+0.3%) to 96.406% when pulling 50e33bf632fe718e705cd44da5ee29cdc79ee499 on upload-files into 3a44612526aaac8bddb79c3c6b546bcda4ea4b9c on master.


Non-file-based streams in Node.js do not receive progress events

Describe the bug
When passing a stream to tus-js-client that is not an fs.ReadStream, tus-js-client only emits progress events for the end and beginning of PATCH requests, but not during PATCH requests.
To Reproduce
/* eslint-disable no-console */

'use strict'

const fs = require('fs')
const tus = require('../..')
const { PassThrough } = require('stream')

const path = `${__dirname}/../../dist/tus.js`
const file = fs.createReadStream(path).pipe(new PassThrough())

const options = {
  endpoint: 'https://tusd.tusdemo.net/files/',
  chunkSize: 1024 ** 3,
  uploadLengthDeferred: true,
  metadata: {
    filename: 'README.md',
    filetype: 'text/plain',
  },
  onError(error) {
    console.error('An error occurred:')
    console.error(error)
    process.exitCode = 1
  },
  onProgress(bytesUploaded, bytesTotal) {
    const percentage = ((bytesUploaded / bytesTotal) * 100).toFixed(2)
    console.log(bytesUploaded, bytesTotal, `${percentage}%`)
  },
  onSuccess() {
    console.log('Upload finished:', upload.url)
  },
}

const upload = new tus.Upload(file, options)
upload.start()

Run it and the output is like this (no intermediate upload progress):
$ node demos/nodejs/index.js
0 201172 0.00%
201172 201172 100.00%

Expected behavior
It should be more like this (as with file-based streams):
$ node demos/nodejs/index.js
0 201172 0.00%
65536 201172 32.58%
201172 201172 100.00%

Details
This is a direct consequence of https://github.com/tus/tus-js-client/pull/385. Before this PR, tus-js-client split a stream into multiple sub-streams. After this PR, a stream is now split into buffers. However, our HTTP stack in Node.js only supports progress events when a stream is used a the request body, and not buffers:
https://github.com/tus/tus-js-client/blob/623ec813031eeb98fb94770072b63bc260bea7fa/lib/node/httpStack.js#L90-L94
We should find a different way to get progress events from requests in Node.js.

axios has an onUploadProgress event and seems to achieve this by a similar method of piping the upload body through a transform stream. Non-streams are simply converted into streams to conform here: https://github.com/axios/axios/blob/21a5ad34c4a5956d81d338059ac0dd34a19ed094/lib/adapters/http.js#L332-L347

I don't think that is a fitting solution because it would measure the progress from consuming the stream and not the actual network transmission. Since we are buffering internally, these two progress would be vastly different.

It tried something like this:
      if (body == null) {
        req.end()
      } else {
        if (!isStream.readable(body)) {
          body = Readable.from(body, { objectMode: false })
        }

        pipeline(body, new ProgressEmitter(this._progressHandler), req, (err) => {
          reject(err)
        })
      }

But it does not work. Progress events are emitted based on the read operations that fills the internal buffers and not based on the writes to the HTTP connection. Maybe we should use a more high-level HTTP client, like Axios (see https://github.com/tus/tus-js-client/issues/570).
How pressing is this issue for Uppy, @mifi?

I don't think it's very pressing. Just a minor UX inconvenience I would say, because users won't see any progress until one chunk has finished. But @arturi brought it up so maybe he can chime in

Agreed, not very, prio-2, but on slow connection this means you can sometimes wait a couple of minutes at 0% progress, so you'll think it's not doing anything and abandon the upload. I was convinced it's downloading the file before upload, not streaming it right away (which seems to not be the case, as tested by Mikael).

I played a bit around with this issue but didn't find any solution. I tested the latest version of Axios and progress-stream, but both approaches exhibit the same issue as described in https://github.com/tus/tus-js-client/issues/602#issuecomment-1624858651: The progress information is skewed because the entire upload data passed to the HTTP module in one go through the stream, without any consideration of how much data is written to the network socket in the end. The result is that we immediately get a 100% progress reporting because the entire upload data has been passed to the HTTP module. This does not reflect the actual upload progress though.
Reproducing this is possible without tus-js-client by sending a large buffer via a POST request:
'use strict'

const https = require('https');
const crypto = require('crypto');
const progress = require('progress-stream');

const dataSizeInBytes = 100 * 1024 * 1024;

// Generate a buffer with random data
const randomDataBuffer = crypto.randomBytes(dataSizeInBytes);

// Set the headers for the POST request
const headers = {
  'Content-Type': 'application/offset+octet-stream',
  'Tus-Resumable': '1.0.0',
  'Upload-Length': dataSizeInBytes.toString(),
};

const options = {
  method: 'POST',
  headers,
  hostname: 'tusd.tusdemo.net',
  path: '/files/',
  port: 443,
};

const req = https.request(options, (res) => {
  let data = '';

  res.on('data', (chunk) => {
    data += chunk;
  });

  res.on('end', () => {
    console.log('File uploaded successfully!');
    console.log('Response:', data);
  });
});

req.on('error', (error) => {
  console.error('Error uploading file:', error.message);
});

// Send the random data buffer in the request body
const progresStream = progress({
    length: dataSizeInBytes
}, (p) => console.log(p))

progresStream.pipe(req, { end: true })
progresStream.write(randomDataBuffer)

The only progress report I get is 100% immediately after the upload starts:
{
  percentage: 100,
  transferred: 104857600,
  length: 104857600,
  remaining: 0,
  eta: 0,
  runtime: 0,
  delta: 104857600,
  speed: 104857600
}

A search for alternative solutions to this problem did not show any helpful way for capturing upload progress in Node.js. Unless somebody else can help with this, we will likely not have progress information for Node.js unfortunately.


Errors when testing with psds_eval>=0.4.0

It worked well when training with psds_eval>=0.4.0,But an error occurs  in the final test.

When I downgraded PSD_eval to 0.3.0, it worked fine. However, the published baseline cannot be reproduced, and psDS1 is 0.3153 and PSDS2 is 0.5101 using PSDS_eval ==0.3.0

HI @1yunlong,
could you please point me to the validation.tsv file you are using?
Thanks.

I used the 1168 validation set, and the validation. tsv file is 217K in size.

same issue

ok,
as far as I understand, you validaton.tsv file has 4252 lines, right?

I followed your mentions, but didn't solve this error

@kimsojeong1225
could you please share the file with me, so I can check it out?
Maybe on slack?
Thanks you!

@RonFrancesca
I sent my file to slack!
Thanks

Thank you for all your assistance.


How to find root cause of incomplete stack trace?

It's not unique to see
══╡ EXCEPTION CAUGHT BY IMAGE RESOURCE SERVICE ╞════════════════════════════════════════════════════
The following _Exception was thrown resolving an image codec:
Exception: Invalid image data

When the exception was thrown, this was the stack:
#0      _futurize (dart:ui/painting.dart:5564:5)
#1      ImageDescriptor.encoded (dart:ui/painting.dart:5432:12)
#2      instantiateImageCodec (dart:ui/painting.dart:2052:60)
<asynchronous suspension>
════════════════════════════════════════════════════════════════════════════════════════════════════

the stack backtrace is not complete, How to find where or which image caused the issue?
If I need to give code example, I have to upload all my codes

@http600
Can you provide flutter doctor -v where it shows incomplete stacktrace ?
There was a similar issue which was resolved indicating it now shows complete verbose stacktrace on latest versions. https://github.com/flutter/flutter/issues/81464


Provide a set of standard icons

See https://openapplibrary.org/dev-tutorials/qt-icon-themes

Use whatever icon set you want.
Anyway, I am working on a full icon set that will fit well with my QStyle.

Release v1.0.0 of Qlementine Icons has been made.
Now it needs to be added as submodule.


Proposal for new neo.rawio API.

This PR is for discussion around a new neo.rawio API see issue #354.

Coverage decreased (-1.9%) to 48.057% when pulling ae9428a521111a90c6605325d480e4f08a024dba on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-2.0%) to 47.979% when pulling 92eb9ef269afa1a449797a1151e1920d7007ecea on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-2.0%) to 47.979% when pulling 92eb9ef269afa1a449797a1151e1920d7007ecea on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-1.8%) to 48.115% when pulling 0635348beb739b8e44d6bab59a37a452c56f064d on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-1.1%) to 48.806% when pulling 39e9008de6348eab7d63afc038baa2c6b9b653da on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-1.1%) to 48.812% when pulling 391ee30d665e5d389bbceba6d8e6f399e8d2bc69 on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-1.5%) to 48.419% when pulling 52d7ee85c4629537c75545b03360869961fe75d3 on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.7%) to 49.228% when pulling 659f9784920d10d340a073154ef548002fdd7843 on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.7%) to 49.228% when pulling 659f9784920d10d340a073154ef548002fdd7843 on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.7%) to 49.228% when pulling 5127425b991f76a6b788795560258c710b5bc396 on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.7%) to 49.184% when pulling 2b346e05dd5e8b210d57d6bf5553eddbcc93dae2 on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.8%) to 49.083% when pulling 8cd39ce48dcbcf0c94af003ccf445968bc2005be on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Note that all test are OK except for python2.6.

Coverage decreased (-0.8%) to 49.111% when pulling 51935d3070fc2365576873189fb743e7552bce75 on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.8%) to 49.136% when pulling 1523b52cf77b47121313ad1d664d6cab663de17c on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.8%) to 49.132% when pulling e23f7f7c1deda98dcb87ed469e4326b57eec89b5 on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.9%) to 49.039% when pulling 318c285092a9ceee97fc961f7e993bc6f3d48dcb on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

Coverage decreased (-0.8%) to 49.136% when pulling 58a70005995aaf2506a790eaf4496db4f1ba8d8b on samuelgarcia:raw_io_api into 8997ad2135dc0cb563e2e3742aa8ba751b861205 on NeuralEnsemble:master.

I compared the output of the NeuralynxIO with the new implementation and noticed a couple of differences when loading the Neuralynx test datasets used in the unittests. Some of the differences are improvements coming with the new implementation, but for some others the old implementation seems better. Here a summary of the latter ones:

all times should be rescaled by the time at which the recording started
the shapes of the extracted AnalogSignals are not the same
AnalogSignal objects are missing annotations
Event generation is different in terms of the number of event objects generated as well as their content and annotation
ChannelIndex.name could be more telling than just 'Channel group 0'
ChannelIndex.index can be negative (eg. [-2]) using the new implementation when no analogsignal is attached. Shouldn't it rather be []?
Spiketrain objects do have less annotations with the new IO
the number of waveforms read by the different versions can vary by 1.
the new IO uses the unit of mV to the waveforms. Where does this unit come from?
the left_sweep attribute should be None if it is not known and not set to 0.
the unit of the left_sweep attribute should be time and not 's/Hz'
the 'file_origin' attribute is not set for spiketrains, but should refer to the data file

The code used for comparison of the neo structures is available here: https://github.com/JuliaSprenger/python-neo/tree/fix/raw_io_api at  python-neo/neo/test/iotest/test_neuralynxio.py compare_neo_content(). I will extend the list above when starting to test the new IO also on different files.

Coverage decreased (-1.02%) to 48.602% when pulling c4d4dbe4b2937c2dde916709129b73c86eff93b7 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

@JuliaSprenger:
For NeuralynxIO, I have fix some problems of the list:

all times should be rescaled by the time at which the recording started

Done

the shapes of the extracted AnalogSignals are not the same

This need more investigation. My guess is that inthe very last data block the timestamp is the first sample of block and so this times is not the t_stop. The real t_start is last_time+nb_sample/sampling_rate. This could lead to t_stop difference between the two IOs. i need to check.

Event generation is different in terms of the number of event objects generated as well as their content and annotation

I have keep the same logic as before. One event channel=(event_id, ttl_input).
Except that a special channel was added for 'Starting Recording' and 'Stop Recording'.
This is not kept since they already have a specific channel.

the number of waveforms read by the different versions can vary by 1.

This must be also a limit problem link to t_stop see before.

the new IO uses the unit of mV to the waveforms. Where does this unit come from?

This wa s a mistake. It is in fact uV. For spiketrain.waveforms same logic than signals is applied with "bit_to_microVolt" from header.

the left_sweep attribute should be None if it is not known and not set to 0.

At RawIO level None is not possible because it is in a np.array. Maybe we can put -1 whch could be None at neo.io level.

the unit of the left_sweep attribute should be time and not 's/Hz'

Done.

Coverage decreased (-1.2%) to 48.4% when pulling fed74f5e930c2427f14ab513c2079294e1e5c1c4 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.2%) to 48.396% when pulling fed74f5e930c2427f14ab513c2079294e1e5c1c4 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.2%) to 48.458% when pulling 3ebbd90e5c50e060fb9ccd238e6762730ea710e2 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.2%) to 48.458% when pulling 3ebbd90e5c50e060fb9ccd238e6762730ea710e2 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.2%) to 48.458% when pulling 7e5d81b81bbe9a303da5fd702ace2c6e3017c721 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

I have added a small cache system.
Only NeuralynxRawIO is using it at the moment.
@JuliaSprenger  : could have an eye on it ?

Coverage decreased (-1.2%) to 48.403% when pulling 2fd83a0e0b64039b4a142bbcb6fda5116696251c on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.2%) to 48.403% when pulling 2fd83a0e0b64039b4a142bbcb6fda5116696251c on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.09%) to 48.531% when pulling 15a403737199c1cd30bfca14fa70548a4dae68a6 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.09%) to 48.531% when pulling 15a403737199c1cd30bfca14fa70548a4dae68a6 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.01%) to 48.609% when pulling 48ca97686b43d624ba15b5d42d8dabf08ac3fb06 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.2%) to 48.396% when pulling b138e1bceb619eb684487ad8053a1d9a00062524 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.3%) to 48.315% when pulling 5038b1385e0fcc62c4563ce277bac20ff04565e6 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

I'm playing with your raw_io_api branch now.
setup.py needs , 'rawio' added to the list of packages to install it properly.
I'll post more when I've had a chance to play with the other importers, but so far the BlackrockRawIO is much faster and requires less code on my application's end.

Coverage decreased (-1.2%) to 48.405% when pulling 507d517a872816888e602081a6d384cc6a91b712 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Thank you for feedback.
Have you seen the small doc in doc/source/rawio.rst ?
Maybe some methods name will change before the merge in the master. Do not code too much on top of this before the merge in master.

Coverage decreased (-1.3%) to 48.315% when pulling aa7653fe72b043784882a42fcf5dbe9d1ca7e047 on samuelgarcia:raw_io_api into 7b272cb469e8d6c2636f7a51157763c281dab03a on NeuralEnsemble:master.

Coverage decreased (-1.2%) to 48.526% when pulling f2b54b20ec4e0713837c6e763f53ed48eae5c529 on samuelgarcia:raw_io_api into cf18db0cec3fb49a71080c8da510610213a427ac on NeuralEnsemble:master.

Coverage decreased (-1.2%) to 48.603% when pulling cde007ee80d79dccc8bf0a2a020f123263db9ce6 on samuelgarcia:raw_io_api into bd36cf0118145e30a269ea8d037ee6da3387c427 on NeuralEnsemble:master.

neo 0.5.2 have been release to gather many PR and bug fixes.
Since this present PR is big change.
I propose to merge this soon in master before arrival of other PR.
The place for improvement will be directly in the master so.
Any remark before this ?

I tested the new BlackRockIOI and compared the output to the old implementation, based on how @JuliaSprenger tested the NeuraLynxIO. I used the test files that are used for the UnitTests. The following is a list of the differences I found, sorted by objects. The points marked by "!" are the ones I think are most important.

Parameters for calling the IO

units ('units') and channels to load ('channels') cannot be specified any more (old parameters not accepted any more)
In old IO all nsX were loaded by default, now it's just the highest. This might be a problem, because sometimes not all values are in the highest nsX but rather in lower nsX, so they should be loaded by default as well
parameter 'scaling' is now 'voltage' by default, was 'raw' before

General
!- Unit and SpikeTrains are not linked, i.e. for every Unit object, unit.spiketrains is empty and for every SpikeTrain object, spiketrain.unit is empty as well
!- Times are not saved in sampling resolution but in seconds (=> keeping the native sampling resolution prevents accumulating rounding errors early on)

file origin and description missing most of the time
inconsistent values of attribute name, in ChannelIndex name is 'Channel group X', in AnalogSignal name is 'chanX'

AnalogSignals

more AnalogSignals/channels loaded by default, in old IO only channels to 128 were loaded by default, if found
no nsX value in annotations, so that it's difficult to understand from which nsX file the data was loaded
in anasig.description signals are now numbered, maybe start index at 1, like numbering for channel_id and label. It looks like this: 'AnalogSignal X from channel_id: Y label: chanY, nsx: 5', but X is always one less than Y: X=Y-1

Block

missing annotations, earlier there was more meta-information

ChannelIndexes

In old IO Units were linked to the ChannelIndex that the AnalogSignal with the same number was linked to. Why do you create extra ChannelIndexes for the Units?
missing annotations, earlier there was more meta-information
index becomes array with number instead of 0 => numbers too large, every AnalogSignal only has 1 channel

Events

additional annotations (copy and id), what are they for?
one new Event that is not found by old IO, has empty times and labels (called 'serial_input_port' (0,))

SpikeTrains

names look differently: 'ch1#0' was 'Unit 1000'
There is an additional annotation 'id', that contains the same content as SpikeTrain.name in old IO (e.g 'Unit 1000')
description contained 'unit: unclassified', is now 'unit_id: 0'

Unit

Annotations Channel_ID and Unit_ID don't exist any more, instead the information is combined in annotation 'ID'. So there is no possibility to access them seperately any more

Some of those differences are quite similar to what @JuliaSprenger reported for the NeuraLynxIO.

Thank you for feed back.
The short answer is that the behavior of the old BlackrockIO will not be exactly similar that the new one. So choices we made specifically to the IO. In the new branch the same behavior should work for all IOs.

   units ('units') and channels to load ('channels') cannot be specified any more (old parameters not accepted any more)

This can be done at rawio API. For io API it is easy to add channel_indexes key. channel_ids is more ambiguous for some cases.

   In old IO all nsX were loaded by default, now it's just the highest. This might be a problem, because sometimes not all values are in the highest nsX but rather in lower nsX, so they should be loaded by default as well

You can do reader = BlackrockIO(filename='...',nsx_to_load=3) but it is not at instanciation not in read_block. This was too specific to blackrock. Specific kargs are now in init. This is easier and more consistent.

   parameter 'scaling' is now 'voltage' by default, was 'raw' before

At the moment reading raw data is only available at raw level but since the class is made by compisition. You can do  reader.get_signal_chunk(...) and you get directly numpyint16.

    Unit and SpikeTrains are not linked, i.e. for every Unit object, unit.spiketrains is empty and for every SpikeTrain object, spiketrain.unit is empty as well

Oups, this is a bug in BaseFromRaw.

Times are not saved in sampling resolution but in seconds (=> keeping the native sampling resolution prevents accumulating rounding errors early on)

At the io level, yes, but you can get timestamp (original format) at the rawio level with spike_timestamps(..)

file origin and description missing most of the time

Oups. I will fix.

inconsistent values of attribute name, in ChannelIndex name is 'Channel group X', in AnalogSignal name is 'chanX'

This is due to signal_group_mode="group-by-same-units" or "split-all". I guess we need some discussion here.

   more AnalogSignals/channels loaded by default, in old IO only channels to 128 were loaded by default, if found

OK. I was not aware of that. We can clip the channel exploration to 128. Is it the case for all blackrock system ?

   no nsX value in annotations, so that it's difficult to understand from which nsX file the data was loaded

I will add this.

   in anasig.description signals are now numbered, maybe start index at 1, like numbering for channel_id and label. It looks like this: 'AnalogSignal X from channel_id: Y label: chanY, nsx: 5', but X is always one less than Y: X=Y-1

I don't get this. X is the channel_index (0 based) can't be sparse. Y is the channel_id (1 base in the case of Blackrock) can be sparse. What is the expected descr ?

   missing annotations, earlier there was more meta-information

I need to check.

   In old IO Units were linked to the ChannelIndex that the AnalogSignal with the same number was linked to. Why do you create extra ChannelIndexes for the Units?

This cannot be done here at the moment because the BaseFromRaw is generic.
If someone have a solution for this. The IOs are able to do that. Some other not....

   missing annotations, earlier there was more meta-information

I need to check.

   index becomes array with number instead of 0 => numbers too large, every AnalogSignal only has 1 channel

This behavior can be fixed with signal_group_mode="group-by-same-units" or "split-all".

   additional annotations (copy and id), what are they for?

This is something general at rawio level. All channel have an id.

   one new Event that is not found by old IO, has empty times and labels (called 'serial_input_port' (0,))

I need to check. Is it a problem ?

   names look differently: 'ch1#0' was 'Unit 1000'

This is my choice. I thin this more explicit to have both channel and unit id. No ?

   There is an additional annotation 'id', that contains the same content as SpikeTrain.name in old IO (e.g 'Unit 1000')

Same answer.

   description contained 'unit: unclassified', is now 'unit_id: 0'

I can add this but not in name or id. Maybe another key ?

   Annotations Channel_ID and Unit_ID don't exist any more, instead the information is combined in annotation 'ID'. So there is no possibility to access them seperately any more

Yes but with other key.

Some of those differences are quite similar to what @JuliaSprenger reported for the NeuraLynxIO.

Yes they are!
I will fix most of theses soon when it is easy. Then I propose to merge this branch in the master.
It will easier for other developers related to previous IO implementation to propose a PR that could enhance everybody needs.
It is now more clear were to put changes : in the RawIO directly when it is specific or in BaseFromRaw when we want a global behavior for all IO.

@samuelgarcia thanks for the quick relpy. We are currently looking into your comments and will come back to you soon.  However, before merging this branch, we would like to test the new BlackrockIO not only on a single test data set (as done above) but also confirm that the new IO is working for real datasets containing more data and also recordings using different versions of Blackrock files. This might take a couple of days, but we will keep you informed.

@JuliaSprenger. Yes of course we can wait a before this merge. Merging soon is nevertheless important because any incoming PR could lead to conflict with rawio.
I propose:

keep explicitly OldBlackockIO and OldNeuralynxIO in the master for a long overlapping time to not break everyhting in existing pipeline you have.
add some commit in rawio branch this week.
merge rawio let's say next week. (but refusing any PR that concern theses IOs in old fashion)
discuss this new API and specific IO stuff directly in the master with PR and reviews.

In any case the release of 0.6.0 will be in a long time.
Is it OK for you ?

Unit and SpikeTrains are not linked, i.e. for every Unit object, unit.spiketrains is empty and for every  SpikeTrain object, spiketrain.unit is empty as well

This is strange, because the link is already done. Do you have my latest latest raw_io_api branch ?

missing annotations, earlier there was more meta-information

Could you be more specific ?

description contained 'unit: unclassified', is now 'unit_id: 0'

unit_id still is unit_id but I have added unit_tag for this  = 'unclassified', 'noise' or str(unit_id)

names look differently: 'ch1#0' was 'Unit 1000'
We now have at line 252

                    name = "ch{}#{}".format(channel_id, unit_id)
                    _id = "Unit {}".format(1000 * channel_id + unit_id)

if you prefer we can swap name<-> _id.

@samuelgarcia: I agree to your proposed plan. Keeping both versions of the IO would help a lot. Maybe we can do the same for the NeuralynxIO for some time?

OldNeuralynxIO is now in neo.io.neuralynxio_v1
The init look like this
from neo.io.neuralynxio import NeuralynxIO
from neo.io.neuralynxio_v1 import NeuralynxIO as OldNeuralynxIO
...
from neo.io.blackrockio import BlackrockIO
from neo.io.blackrockio_v4 import BlackrockIO as OldBlackrockIO

If there is another IO you want to keep in double version teel me.

Coverage decreased (-0.9%) to 49.035% when pulling e10fe7aa5d451481a471ba95efad7dd05755571a on samuelgarcia:raw_io_api into e43ed54d7d523f8723f975e47893e47a8c1270f6 on NeuralEnsemble:master.

I worked through your comments and will write a detailed answer to them soon. In addition, I just investigated whether it is possible to load different real Blackrock datasets. I noticed that it seems that some version checks are missing. blackrockrawio.py fails for file version 2.1 in _parse_header at line 244, because 'NEUEVFLT' cannot always be read as a key from the header (i.e., this Block is not existent in version 2.1). In the old IO 'NEUEVFLT' is only referenced in a function that would be run for file versions 2.2 and 2.3, whereas _parse_header in the new IO is called in any case.
As a somewhat related issue, could you please explain a bit more in detail how to load only specific channels in your new IO? I don't quite understand what you meant and don't want to crash everything by loading a complete ns5 dataset.

Coverage decreased (-0.9%) to 49.033% when pulling 34f6a60d9cef29ee67b720bed3016b6780245a5b on samuelgarcia:raw_io_api into e43ed54d7d523f8723f975e47893e47a8c1270f6 on NeuralEnsemble:master.

Thank you Björn for this investigation across the code.
I have done a fast patch for NEUEVFLT changed NEUEVWAV. Could you test it ?
For channel you have several possibilities for selecting (only at rawio level for the moment):
reader = BlackrockRawIO(filename='FileSpec2.3001')
reader.parse_hedaer()

#read all signals channels
raw_sigs = reader.get_analogsignal_chunk(channel_indexes=None)

#select by channel_indexes
raw_sigs = reader.get_analogsignal_chunk(channel_indexes=[0,  2, 4])

#select by channel_ids (note tha in Blackrock id is one based and this is specific to blackrock and some other
raw_sigs = reader.get_analogsignal_chunk(channel_ids=[1, 3, 5])

#select by channel_names
raw_sigs = reader.get_analogsignal_chunk(channel_names=['chan1', 'chan3', 'chan5'])

The file for testing is 2.3. If you have the small dataset <10Mo for 2.1 and 2.2, we could put them at gnode portal and use them in the test suite.
Since the neo.io Blackrock is done by inheritance with BlackrockRawIO get_analogsignal_chunk() is also available.
Have you seen the doc doc/source/rawio.rst ?
I will add in doc the channel selection stuff.

Coverage decreased (-0.9%) to 49.035% when pulling 15f26fdb850248871828092fab895bd02a9e80c9 on samuelgarcia:raw_io_api into e43ed54d7d523f8723f975e47893e47a8c1270f6 on NeuralEnsemble:master.

I guess it is time to merge this rawio.
Lets improve rawio directly in master.


eBPF, /proc/PID/mem, CRIU, and gdb/gcore for generic heap dumps?

Any interest in expanding to generic linux process heap dumps?
https://github.com/iovisor/bcc/blob/master/tools/profile.py is the most popular eBPF script for logging stack traces.
I was hoping of creating a tool that similarly did  /proc/PID/mem snapshots to visualize the heaps of arbitrary processes.
I know there is https://criu.org/Main_Page - like IBM/Intel MPI checkpoint it can write an entire cgroup stack and memory to file. This would certainly work. Might also have to log all the malloc() and free() calls.
GDB and gcore can also do it https://serverfault.com/questions/173999/dump-a-linux-processs-memory-to-file.
https://github.com/facebookexperimental/rbperf does the eBPF but doesn't seem to support more than logging libc memory calls - no heap visualization.

This project is mostly meant for research, not for serious usage. Building a more production-ready tool is out of scope of this project. Furthermore, I don't really have time right now for an effort to build a more production-ready tool.
Your references are very interesting however, so thank you for that!


Fixing "list index out of range" in secure_auth_with_db_example.py

As per http://tinydb.readthedocs.io/en/latest/usage.html#retrieving-data , db.get(...) will prevent TinyDB from throwing an "IndexError: list index out of range"
Calling with a non-existing username before:
Traceback (most recent call last):
  File "/usr/local/bin/hug", line 11, in <module>
    sys.exit(development_runner.hug.interface.cli())
  File "/usr/local/lib/python3.5/dist-packages/hug/interface.py", line 454, in __call__
    result = self.interface(**pass_to_function)
  File "/usr/local/lib/python3.5/dist-packages/hug/interface.py", line 99, in __call__
    return __hug_internal_self._function(*args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/hug/development_runner.py", line 71, in hug
    api.cli.commands[command]()
  File "/usr/local/lib/python3.5/dist-packages/hug/interface.py", line 454, in __call__
    result = self.interface(**pass_to_function)
  File "/usr/local/lib/python3.5/dist-packages/hug/interface.py", line 99, in __call__
    return __hug_internal_self._function(*args, **kwargs)
  File "secure_auth_with_db_example.py", line 48, in authenticate_user
    user = db.search(user_model.username == username)[0]
IndexError: list index out of range

After:
User myuser not found
False

Coverage remained the same at 100.0% when pulling d09a73316ad829f9030c3d08e2d3fdb593b29693 on cprior:develop into 78a6be2c2a8edfc7b0c4f6c259fe5e39ae9cfddb on timothycrosley:develop.

Looks good, thanks!


git repo improvements for helm operator

Here are some improvements to the git mirroring, so that it's usable for the Helm operator.

allow a git repo be read-only, so that you can give the helm-op a read-only SSH key (as we do in local env)
add a "files only" clone, git.Export, so the helm operator can get at a working tree without all the config baggage that fluxd uses in its working directories

The substance is in https://github.com/weaveworks/flux/pull/1238/files#diff-4e28ed4007c9ceb9cb3efd309643ca04, in which the state machine loop is factored out so it can be used synchronously (in repo.Ready(...) ) but also set running in repo.Start(...).

Thanks Aaron :spaghetti:


ConfigureServices Typo

In step 7 of Option #1, it says to update some code in the ConfigureServices method, but it should probably say Configure method.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7a0b8671-359e-6026-fd3a-39331cea73f3
Version Independent ID: 29bab4ad-243a-fb0a-99ed-d8336a92f648
Content: Develop DirectLine Speech Bot - Bot Service
Content Source: articles/directline-speech-bot.md
Service: bot-service
Sub-service: abs
GitHub Login: @ivorb
Microsoft Alias: v-ivorb

Thanks for your feedback.
This typo was fixed and the change will be visible the next time our document updates go live.


Soycode fixtests

This, combined with https://github.com/willscott/webrtc-adapter/pull/6 and https://github.com/freedomjs/freedom/pull/275, addresses many of the remaining concerns in https://github.com/freedomjs/freedom-for-firefox/issues/50.

N.B. - tests will continue failing on Shippable until we cut new releases of the dependency packages (webrtc-adapter and freedom). At least, I don't know a good way to otherwise update Shippable - they do pass locally for me though.

should this bump the dependency versions?

Probably a good idea, went ahead and updated all and it still seems to run/build as it was. One annoying thing is it seems like the getStats test is failing on OSX even with the new webrtc-adapter (it passed in Linux which is where I originally wrote it). I still think this is worth merging as hopefully it keeps passing on Linux and thus Shippable.

And checking the Shippable results, getStats does indeed pass in Linux land, so that's good. There's still some failing TCP tests, but hopefully they pass once we also cut a fresh release of freedom.

At this point the only failing test is:
>> integration: core.tcpsocket Pauses and resumes failed
>> Error: Timeout - Async callback was not invoked within timeout specified by
jasmine.DEFAULT_TIMEOUT_INTERVAL. in resource://jid1-mkagayemb0e5nq-at-
jetpack/freedom_for_firefox_tests/data/spec.jsm (line 11111)

And I think this will likely pass once we cut a new release of freedom. LMK what order you want to do things in (i.e. merging, releasing, etc.) - thanks!

:+1:


Polite Expressions and Greetings

Teaching children words like thank you, please, sorry and greetings, like good morning, good afternoon, good evening, good night etc.
(Suggestion of GSSoC '24 contributor)

Please assign this issue to me.

Hello Vaibhav ! I wanted to work on this issue. Can you please assign me ?

Hey, Khushi Soni this side, I'm a GSSoC contributor and would love to handle this issue

I have done a flutter internship and I would like to work on this issue. Kindly assign it to me

Hey @LEARNER-dakshesh  @khush1yaaar,  any update on this issue.

Changes will be pushed till tommorow afternoon.

I have made the changes regarding this issue. Please check it once.

@sapatevaibhav working on it

@sapatevaibhav  Bro i have made the changes you specidied . please recheck and merge it

Hello can you please assign me to this task?

please assign this issue to me


LoL Bot

is it still working? and how can i use it. Thanks.

Make sure to read the readme.
It's a beta, it works, there is no documentation.
You can read the code or wait a bit for the documentation!


Subscribers skip messages on module upgrade

Steps to repro:

Have a module with a subscriber with no retry policy that is trying to get through a backlog of messages
Deploy a newer version of the module

What goes wrong:

The context gets cancelled which fails any active calls
These failures are not detected any differently than other errors, and so we commit these messages as having been processed
Then sarama closes the consumer group, which includes sending all the commits to kafka

I think this is part of the more general problem of request draining.


Navbar

Changed the BackGround Color of navbar and changed the button styling as instructed

/reviewed

pull changes and try making a new PR


Add more primative gens

Closes #772

lgtm merge when you're happy @Kerooker

Thanks for the pr @magneticflux-

Could we add some tests for these new generators?

I added to some existing tests, but I didn't see any other tests for the original Int and Long gens to parallel for Short and Byte. If you want more tests, just link where I should put them and I'll add them!

I think we're ok for now.
I'll add some tests for all of these later.
Thanks for the PR, @magneticflux- !