fixed failure for OML test

Signed-off-by: Pushpa Bhallamudi<EMAIL_ADDRESS>

@hajiratasneem  I have updated your OML message YAML and modified to make it work with HAPI parser non-greedy mode.
Here are details about that:
https://hapifhir.github.io/hapi-hl7v2/base/apidocs/index.html?ca/uhn/hl7v2/parser/ParserConfiguration.html
public void setNonGreedyMode(boolean theNonGreedyMode)
If set to true (default is false), pipe parser will be put in non-greedy mode. This setting applies only to Pipe Parsers and will have no effect on XML Parsers.
In non-greedy mode, if the message structure being parsed has an ambiguous choice of where to put a segment because there is a segment matching the current segment name in both a later position in the message, and in an earlier position as a part of a repeating group, the earlier position will be chosen.
This is perhaps best explained with an example. Consider the following structure:
MSH
GROUP_1 (start)
{
AAA
BBB
GROUP_2 (start)
{
AAA
}
GROUP_2 (end)
}
GROUP_1 (end)
For the above example, consider a message containing the following segments:
MSH
AAA
BBB
AAA
In this example, when the second AAA segment is encountered, there are two possible choices. It would be placed in GROUP_2, or it could be placed in a second repetition of GROUP_1. By default it will be placed in GROUP_2, but in non-greedy mode it will be put in a new repetition of GROUP_1.
This mode is useful for example when parsing OML^O21 messages containing multiple orders.

@LisaWellman  ^^ fyi

Closing this as this has been resolved in the following PRs:
https://github.com/LinuxForHealth/hl7v2-fhir-converter/pull/257
https://github.com/LinuxForHealth/hl7v2-fhir-converter/pull/413


Create snapshot of collection after querying db

Atomic collections and these nested inside were still considered dirty even after update query was issued and they were scheduled for update again if UoW::recomputeSingleDocumentChangeSet was called for instance by postUpdate.
@blockjon's test from #1126 is incorporated in this PR

@jmikola actually I think we should change whole flow of updating/removing Collections. To recap current commit flow is as follows:

Upserts
Inserts
Updates
Collection deletions
Collection updates
Deletions
Collection snapshots

Separating collection updates from parent document so far lead us to #1126, #1145 and #1046 (from top of my head). Now that we have introduced atomic strategies DocumentPersister will also take care of them and unschedule so CollectionPersister won't pick them up but I believe your suspection in https://github.com/malarzm/mongodb-odm/pull/4#issuecomment-111592953 is correct and altering child of atomic collection in postUpdate will schedule collection for update again and throw exception in CollectionPersister as atomic collections can't be handled by it.
The change I want to propose is to move all collection updates/deletions into DocumentPersister (it can call internally CollectionPersister) and take care of these collections just after parent document is resolved (before we return to UnitOfWork to dispatch events). This leads to several enhancements:

Document A's collections will be updated just after A which logically makes sense (a lot of :) )
We will be able to easily fix Version check of document while saving its collections since DocumentPersister has already calculated that and can simply pass information to CollectionPersister
All collections will be snapshotted just after saving so there will be no place for desynchronization of snapshot and db state (now it can happen if DocumentPersister::remove would throw LockException)
If update of document B will throw exception it will not affect A's collections
postUpdate will be correctly triggered after database query(ies) as it is expected to be
updating document's collection in postPersist/postUpdate will no longer trigger saving them (which might be a BC break but again, both events where meant to be fired after the database operations, so this change is totally sane)
Collections are handled in one place, not in two as currently is needed
Right now if parent document is to be deleted, we will issue additional query to its collections anyway (if these collections are scheduled for some reason) - it will no longer be an issue

What do you think? cc @jwage @alcaeus

altering child of atomic collection in postUpdate will schedule collection for update again and throw exception in CollectionPersister as atomic collections can't be handled by it.

Reading that lead me to consider another point. We currently have logic to check if a scheduled collection is contained within some top-level atomic collection. In a more general sense, should we be doing the same for collections with addToSet or pushAll strategies that are contained in a parent with a set* strategy? AFAIK, we don't currently do this, although ODM likely issues the higher-level collection's write before the child. If a parent uses set*, though, I think the benefit of an addToSet or pushAll is lost, so we might as well coalesce the writes.

updating document's collection in postPersist/postUpdate will no longer trigger saving them (which might be a BC break but again, both events where meant to be fired after the database operations, so this change is totally sane)

This behavioral change will be due to the collection modification happening between the document's write and any event dispatching, correct?
That said, I'm inclined to agree with your proposal :)

Reading that lead me to consider another point. We currently have logic to check if a scheduled collection is contained within some top-level atomic collection. In a more general sense, should we be doing the same for collections with addToSet or pushAll strategies that are contained in a parent with a set* strategy? AFAIK, we don't currently do this, although ODM likely issues the higher-level collection's write before the child. If a parent uses set*, though, I think the benefit of an addToSet or pushAll is lost, so we might as well coalesce the writes.

Awesome, probably it will fix #1104 :)

This behavioral change will be due to the collection modification happening between the document's write and any event dispatching, correct?

Exactly

Superseded by #1155


Add install instructions for normal releases and for pre-releases

Fixes #1098

Thanks for the pull request @kring!

:heavy_check_mark: Signed CLA found.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.


Fix readme3

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:
/kind bug
/kind task
/kind feature

What does this PR do / why do we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewers:

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

/ok-to-test

/sync

Is this a personal test pr? Please close this pr.


Refactor timer to run in the app instead of the widget

closes #26

This branch was only to separate refactoring in case it doesn't work out. Remaining work can be done it current WIP branch (#28)


[FEATURE REQUEST] Custom date format

Is your feature request related to a problem? Please describe.
It's a problem that documents are named in a MM/dd/yyyy hh:mm am/pm format by default.
Describe the solution you'd like
I'd prefer the ISO 8641 date format by default, which is more readable and universal when working with files. But a setting to pick from most popular formats would be a better solution.

Just saw this one, dont know if its since last update?

Will test with 'iso' but maybe documentation about Y M D etc will follow?

Ah I see now, even picking 'iso' doesnt do anything (yet).

@joeldebruijn it should! And the doc for other should be shown when you click the "here" text.
Will check all.that Monday when i am back to work

Ah thanks, at the moment I have renaming scripts for the exported pdfs but eager to strip them away and have right at the source.
Not in a hurry tho, thanks.

@joeldebruijn it should! And the doc for other should be shown when you click the "here" text.
Will check all.that Monday when i am back to work

@joeldebruijn so i have tested the custom date format and all is working as expected. Dont forget to un check "use document name when possible". By default document name is set to the date with a custom format (we see it in your screenshot).
So if you dont uncheck your custom format will never be applied. It is needed that way because you can change the document name, and i have to expect you want to use it if it is set.

Sorry, just one more thing ...
The ISO date/time takes the moment of export as a source, not the moment of scan?
Meaning: if I scan something on the day it came in, but export once a week or so, the dates are not the date the document is received ....

@farfromrefug, you can see in the screenshot above that the file at the top is still named with a MM/dd/yyyy date format, so the issue should not be considered completed.

it is not the name of the file. It is the name of the document which is auto generated on document creation. But you are right i misread the issue as wanting custom name for file exporting, not document naming. Should i use the same setting for both?

@nvllz does not seem like a bad idea. Will do that and if i get requests for separated setting i ll do that then

@nvllz thanks will.look at that the here should be clickable! Must a locale issue. What s your phone language ?

@nvllz should fixed in latesr


Design Matrix Class

We should add new design matrix class to nltools
Data Fields
.data - we get this from data.values cause of subclassing pandas
.sampling_frequency
Methods

vif
plot
convolve - look up temporal derivatives

hrf should take list of functions then loop over to apply convolution and change column names accordingly
inplace = true
column_list
variable name

add_filter - check out luke matlab toolbox, maybe nilearn, direct cosine transform
import_onset
concat

add intercept
deal with run wise codes
-zscore - steal from utils
-downsample - steal from utils
-upsample - copy from downsample add to utils too

Make new function to read csvs and yield design matrix class as a utility function instead of putting it in design matrix init
function should take flag about whether to add an intercept
then append method on design matrix should handle 4 cases:
handle 2 scenario: both have intercepts, or both dont otherwise raise error

if they both dont, either make a single intercept, or runwise dummies
if they both do, decide whether to stack them or separate them

make sure even run dummies are called intercept, i.e. intercept_1, intercept_2... then can search within column names for intercept

added with #116


Impossible to override methods with different function signature in typed GDScript

Godot version:
525384d master
OS/device including version:
Windows 10 1803 build 17134.165
Issue description:
For instance, the parser doesn't allow me to override set/get methods of a class that inherits Object:
extends Node

var property

# It was possible to override `set` method before typed GDScript
func set(p_property, p_value, some_other_value = null):
	property = p_property

# Same with `get`
func get(p_property, some_other_value = null):
	return property

SCRIPT ERROR: GDScript::reload: Parse Error: Function signature doesn't match the parent.
          At: res://Node.gd:7

Minimal reproduction project:
typed-gdscript-set-get.zip

CC @vnen - I don't know if it's a bug or a feature, overriding Object set and get sounds like asking for trouble.

It's not about set and get specifically, the issue is changing the method signature (adding more arguments) when doing so. This is one of the things that GDScript used to allow that is not safe when considering OOP concepts (inheritance and polymorphism).
Say you have a variable of type Object, you can put an instance of this script there. But if the signature of the get() method can be different, there's no way to type-check this in the parser (or rather, the parse would say it's okay, looking at Object, but when you run it breaks), and it's very easy to make a mistake, breaking the game in runtime with a hard to track bug.
I know you added only optional arguments, so in theory it would still work, but it would require ignoring all the extra arguments when checking, allowing for some potential mistakes.
While this is technically breaking compatibility, I prefer not allowing changing the method signature when overriding.

While this is technically breaking compatibility, I prefer not allowing changing the method signature when overriding.

This is the reason why I created the issue because you stated in your merged PR that it shouldn't break anything. But I've got to agree that it's logical not to break OOP concepts...
I'll try to refactor my code base with that in mind and see if I get any more errors (it spits plenty of errors now, and I'm not sure whether they're related to method signature alone). I don't really need to be able to override set/get methods specifically, I can rename them as setup  and retrieve.

This is the reason why I created the issue because you stated in your merged PR that it shouldn't break anything.

It's okay to open the issue. There's a lot of things I didn't anticipate because GDScript is very lenient in many aspects. But in this particular case I think it was a flaw in the old GDScript.
I'll leave this up for discussion.

I also ran into this today, but not by adding more arguments to my function.
If I make a scene called Enemy.gd, and that scene has a script:
extends Node2D

func hit(dmg, stun = true):
   pass

And I instance this as a New Inherited Scene, say Orc.gd, and give it the following script:
extends "res://Enemy.gd"

func hit(dmg, stun = true):
   .hit(dmg, stun)

It fails with: " Parse Error: Function signature doesn't match the parent."

Here's another error while we are at it,

I don't think that is expected.
And sorry about the absurd naming, was just testing things.

@swarnimarun This is unrelated to the issue since default arguments were allowed only at the end even before the typed gdscript PR.

I´m having similar issue trying to make FSM works in Godot 0e8f2c8 master
FSMState.gd

foo.gd

any idea how I can make this plugin works again in the new typed gdscript?

Also having weird errors like this, with the base class having the method like this.

And another class inheriting the class with an override like this.

Seems like typed GDScript deems using default parameters as some kind of an evil thing to do when overriding, so most likely it's a bug related to using default parameters, isn't it? The number of arguments doesn't change according to reports by @K3nIchi and @ArcOfDream.

The problem lies somewhere in ~this map~~ this piece of code:
https://github.com/godotengine/godot/blob/f778bd8e694cb9c93cc0e021418f2be362dcdd3c/modules/gdscript/gdscript_parser.cpp#L7171-L7185

I guess we could allow adding arguments as long as they are optional.
The other reports (when the signature really didn't change) are effectively a bug.

@bojidar-bg it turns out that GDScript's get_default_argument_count() method is return the wrong number (off-by-one).


hs:id tag is not applied to some custom components as an implied tag

I had some custom components in my module where I expected the hs:id tag to be applied.  However, when inspecting the implied tags on the component, and this was verified once the tags were shipped out of Niagara, the 'hs:id' tag wasn't there.  Looking at the rules in the tag dictionary it seems that the 'hs:id' tag should be applied to every baja:component.
This needs to be looked into because the 'hs:id' tag is vital to a number of operations.
@esanderson you might need to check this out in the Tridium tag dictionaries.

The smart hs:id tag in the NHaystack module (BNIdTag) does an addition "visible" check (see SpaceManager#isVisibleComponent(BComponent)) in addition to the the tag rule conditions when determining whether or not to imply the tag.  This "visible" check includes the components that:

The query user has read-access to
Are instance of BHTagged (BHEquip and BHSite)
Are instance of BControlPoint, BDevice, or BWeeklySchedule
Have a slot named "haystack" whose type is instance of BHDict
Have an "hs:site" or "hs:equip" tag (this check was added in more recent NHaystack versions)

If I recall correctly, this "visible" check was added to the smart tag to replicate how the NHaystackService formerly implied the ID tag.  The same "visible" check has always been used elsewhere in the NHaystack module.  In previous NHaystack versions, if a query was made for all components with the ID tag, it would only return components that met the "visible" conditions.
We could remove the extra "visible" check from the smart tag.  Then, the smart tag would be implied on all components for all NHaystack users.  If we want to allow users to choose whether the smart tag is implied on all components or only on "visible" ones, we could create a new smart tag type ("BNIdTag2") that removes the extra "visible" check.  Including this new type in the dictionary can be specified through a tag import file.  The Haystack tag dictionary is frozen to prevent changing the dictionary at runtime so a configuration property on the smart tag would not work.  The Haystack tag dictionary import does not support custom tag rule conditions, which might be another way to customize the smart tag's behavior.

@esanderson I've reviewed the code at SpaceManager#isVisible and I can see what you're referring to.  It all makes sense.  Rather than make too many changes would it simpler at here:
https://github.com/ci-richard-mcelhinney/nhaystack/blob/n4/nhaystack-rt/src/nhaystack/server/SpaceManager.java#L94
to just add an additional condition that includes any component that has the 'hs:point' tag applied to it.  This way we would capture the Site - Equip - Point hierarchy properly and the changes would be minimal.
So that line would turn into:
if (tags.contains(NHaystackConst.ID_SITE) || tags.contains(NHaystackConst.ID_EQUIP) || tags.contains(NHaystackConstI.ID_POINT))


[dashboard] Add support for the new API

This PR adds support for the new Dashboard API in the library.

The code is clean, I see no issues. LGTM 👍

Could this be merged in?


Attempting to preview parquet on 1.30

Preflight Checklist

[X] I have installed the latest version of Storage Explorer.
[X] I have checked existing resources, including the troubleshooting guide and the release notes.
[X] I have searched for similar issues.

Storage Explorer Version
1.30.0
Regression From
No response
Architecture
x64
Storage Explorer Build Number
No response
Platform
All
OS Version
No response
Bug Description
Trying to view parquet files and get the following error:
{
"name": "TypeError",
"message": "o.buffer.readUInt32LE is not a function",
"stack": "TypeError: o.buffer.readUInt32LE is not a function\n    at ZR (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:736826)\n    at Object.QR (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:736928)\n    at Tn (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:764741)\n    at rD (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:766114)\n    at async sb (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:765449)\n    at async fb (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:767625)\n    at async Mu.readRowGroup (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:763489)\n    at async Object.next (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:756357)\n    at async ParquetParser.getRecords (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:5046)\n    at async getParquetData (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:6298)"
}
Steps to Reproduce
1 Launch Storage Explorer
2 Browse to Parquet file
3 Attempt to preview
Actual Experience
Error message:
{
"name": "TypeError",
"message": "o.buffer.readUInt32LE is not a function",
"stack": "TypeError: o.buffer.readUInt32LE is not a function\n    at ZR (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:736826)\n    at Object.QR (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:736928)\n    at Tn (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:764741)\n    at rD (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:766114)\n    at async sb (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:765449)\n    at async fb (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:767625)\n    at async Mu.readRowGroup (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:763489)\n    at async Object.next (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:756357)\n    at async ParquetParser.getRecords (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:5046)\n    at async getParquetData (file:///C:/Program%20Files/Microsoft%20Azure%20Storage%20Explorer/resources/app/node_modules/@storage-explorer/file-preview/dist/src/Panels/ParquetPreviewPanel/index.js:2:6298)"
}
Expected Experience
No response
Additional Context
No response

I experienced same issue

I aloo experience same

I am going to close this issue and track in #6990 instead. This is very likely due to your data being compressed. The library we use for parsing data is not converting decompressed data back to buffer correctly which may lead to this problem. Please let us know if your data is not compressed.


Optional dependency properties fail to resolve if type with property is registered as container controlled

The following test fails when using Unity Container 5.8.12. It succeeds with 5.8.11.
It is only when WithOptionalDependency is registered as container controlled that it fails. With the other lifetime managers it works.
[TestMethod]
public void ResolveOptionalDependency()
{
	var container = new UnityContainer();
	container.RegisterType<IWithOptionalDependency, WithOptionalDependency>(new ContainerControlledLifetimeManager());
	container.RegisterType<IOptionalDependency, OptionalDependency>();

	var foo = container.Resolve<IWithOptionalDependency>();
	Assert.NotNull(foo.Dependency);
}

public interface IWithOptionalDependency
{
	IOptionalDependency Dependency { get;set; }
}

public class WithOptionalDependency : IWithOptionalDependency
{
	[OptionalDependency]
	public IOptionalDependency Dependency { get;set; }
}

public interface IOptionalDependency
{
}

public class OptionalDependency : IOptionalDependency
{
}

Fixed in 5.8.13


Flag unnecessary @Suppress annotations

Expected Behavior
When a @Suppress annotation is not suppressing any issue we should flag it.
Current Behavior
We don't do that.
Context
As the code evolves there are @Suppress that are obsolete. But you don't remember to remove it so there is a change to add the same problem again. It would be great to have a rule/report (I'm not sure which one would fit better here) to remove those.
There are some "caveats" here:

How do we know if a suppress is related with detekt or not?
If a rule is disabled (active = false) and we have a @Suppress should we mark that @Suppress as unnecessary?
What about other @Suppress related with the compiler? For example @Suppress("DEPRECATION")

I think this is a hard problem in many ways. You would need to get the suppressed scope right and rerun the suppressed rule based on that to make sure the violation isn't present anymore.

How do we know if a suppress is related with detekt or not?

You would need to query detekt's list of rules. However, you can't be 100 % sure that a detekt rule is suppressed. There might be rules in other projects with the same name.

If a rule is disabled (active = false) and we have a @Suppress should we mark that @Suppress as unnecessary?

This would make sense.

What about other @Suppress related with the compiler? For example @Suppress("DEPRECATION")

These elements shouldn't be touched IMHO.

We have been discussing this a LOT on our team, because it's often ignored. People are afraid or forget to remove Suppression annotations, especially at the Class/file level. My thoughts are:

Could be a separate task so that you could essentially set a flag that doesn't acknowledge suppressions
Suggest removal of any suppressions that are off at the top-level
Determine if a suppression's scope is too wide (Suppress at class/file level that should be more specific

I also think it would be best as a report, because then it can be tracked over time. (For our team we would always want it empty.)

I was looking at this the other day, and had a thought about how to generate this:

Add ability to turn off ALL Suppressions
Run detekt twice under the hood, just compare.

That would likely require a LOT less work than some of the other discussed paths.

I was thinking about a different approach, but I'm unsure if is feasible:

Run Detekt once without Suppression. Save to a file similar to the baseline fine.
Have a custom rule that checks for all the Suppress annotation and checks if the item they're annotating contains one of the reported

When a @Suppress annotation is suppressing anything we should flag it.

I guess this should say "is not suppressing anything", @BraisGabin?

When a @Suppress annotation is suppressing anything we should flag it.

I guess this should say "is not suppressing anything", @BraisGabin?

Edited. Thanks to point it out.

Android Studio flags this as a soft warning now, saying that it's a Redundant suppression. Is there any way for detekt to do something similar?

It is possible. But I think this is a difficult one. We need a rule that flags all the @Suppress and then something else to filter the ones that really suppress something. But right now our core doesn't give us that type of information.


[DatePicker] [a11y] [VoiceOver] Date Range Calendar doesn't select when using arrows with VoiceOver (Sequoia and Sonoma MacOS)

Steps to reproduce
Steps:

Open this link to live example: MUI Date Range Calendar

Use Mac with Sonoma/Sequoia OS
Use Safari/Chrome/Edge/Firefox browsers
Navigate to a desired calendar to test (I tested single box calendar from section "Customization")
TAB into calendar box (observe that first date is on focus)
Then use either arrow down/up/left/right or control+option+arrow down/up/left/right
Observe how arrows work (pay attention where they land and how focus works)
Press ENTER/SPACE
Observe how selection doesn't work

Current behavior
We noticed that on our proprietary apps datepickers no longer properly work with VO but only on Sonoma and Seqouia MacOS (works fine on Ventura OS). The worst is on Firefox - arrows don't work at all. On Chrome/Edge the arrows work on the left/right but causing issues when using arrow up/down. On Safari arrows work all directions. But on all browsers ENTER/SPACE doesn't select the correct date - selection is always on what TAB landed on.
I additionally tested this datepicker with NVDA/JAWS 2024/JAWS 2025 on Windows 10 on Edge/Chrome/Firefox and there were no issues with those combinations.
Videos:
Safari test
Firefox test
Chrome test
Edge test
Expected behavior
VoiceOver user should be able to change dates on the datepicker box using arrows and select chosen day with ENTER/SPACE.
Context
It is hard to say if it's Apple issue or MUI issue, but it's a 50/50 possibility. However, this violates WCAG 2.0/2.1/2.2 Level A SC 4.1.2 (Compatibility) and puts this library users (companies) at risk of lawsuits.
Your environment
Computer:
MacBook Pro, Apple M1 Max, 15.1 (24B83)
Browsers:
Safari Version 18.1 (206<IP_ADDRESS>.10)
Chrome Version 130.0.6723.117 (Official Build) (arm64)
Edge Version 130.0.2849.80 (Official build) (arm64)
Firefox Version 132.0.2 (aarch64)
Search keywords: accessibility

Hey @iseatz-zgoodwin, thanks for the report. I'll transfer this issue to the MUI X repo so the team can triage it.


Total refcount issue in pypocketfft

scipy.fft.fft appears to increase total reference count, probably that of some global singleton.
It's not a memory leak, so low priority issue.
Steps to reproduce
Requirements: Python debug build, pybind11 (with this patch https://github.com/pybind/pybind11/pull/1860 to fix a different refcount issue):
>>> import sys, numpy as np, scipy.fft; x = np.array([1,2,3,4+1j,1,2,3,4+2j], dtype=complex)
>>> before = sys.gettotalrefcount(); y=scipy.fft.fft(x); after = sys.gettotalrefcount(); print(after-before)
8
>>> before = sys.gettotalrefcount(); y=scipy.fft.fft(x); after = sys.gettotalrefcount(); print(after-before)
3
>>> before = sys.gettotalrefcount(); y=scipy.fft.fft(x); after = sys.gettotalrefcount(); print(after-before)
3

However, what is strange is that if I move the pocketfft_hdronly.h include before pybind11 here https://github.com/scipy/scipy/blob/310f562e58ca4bba72ed6068d7c12bd865d33607/scipy/fft/_pocketfft/pypocketfft.cxx#L15-L19 and recompile, I see
>>> import sys, numpy as np, scipy.fft; x = np.array([1,2,3,4+1j,1,2,3,4+2j], dtype=complex)
>>> before = sys.gettotalrefcount(); y=scipy.fft.fft(x); after = sys.gettotalrefcount(); print(after-before)
5
>>> before = sys.gettotalrefcount(); y=scipy.fft.fft(x); after = sys.gettotalrefcount(); print(after-before)
0
>>> before = sys.gettotalrefcount(); y=scipy.fft.fft(x); after = sys.gettotalrefcount(); print(after-before)
0

I don't understand at the moment why the refcount leak stops when changing the order of headers.
It also goes away if I comment out the py::gil_scoped_release release in c2c_internal. pybind11 bugs are possible, so not clear it's any issue here.

I don't understand at the moment why the refcount leak stops when changing the order of headers. It also goes away if I comment out the py::gil_scoped_release release in c2c_internal. pybind11 bugs are possible, so not clear it's any issue here.

It sounds like this is definitely a pybind11 issue. The include order dependency suggests that macros are probably involved. Looking at py::gil_scoped_release, I think that pybind11::detail::get_internals is probably a good place to start looking. Perhaps they leak a reference to their "internals" which appears to be a PyCapsule object.

Never mind, the issue went away with ccache --clear, so probably some problem in it picking up the pybind11 headers were changed. Closing.


docs: script tag

Description
Should not use self-closing script tags
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] Any dependent changes have been merged and published in downstream modules

Codecov Report

Merging #44 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #44   +/-   ##
=======================================
  Coverage   52.98%   52.98%
=======================================
  Files         123      123
  Lines        1659     1659
=======================================
  Hits          879      879
  Misses        780      780

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 c7a7b2a...25c1298. Read the comment docs.


Update method names to support intx and floatx changes

Updated the following
from_float -> from_hp_to_intx
from_float_static -> from_hp_to_intx_static
from_float_to_floatx -> from_hp_to_floatx
to_affine_quantized -> to_affine_quantized_intx
to_affine_quantized_static -> to_affine_quantized_intx_static

need to resolve some CI errors


Natural sorting

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

16 of 16 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.192%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2349

Relevant Lines:
2442

💛  - Coveralls


feat: adapt to 0.9.x branch of witnet-requests package

All the existing npm tasks have been kept in place as aliases of the new tasks, for the sake of backwards compatibility.

After this update, I'm happy to confirm to @guidiaz that this short syntax is working again:
npx rad2sol --write-json

Once conflicts are solved, I'm ok w/ this PR.

Once conflicts are solved, I'm ok w/ this PR.

Thanks! Merged!


Code Generation in Quick SQL Creates Randomly Ordered Tables, Leading to Script Execution Failures

When generating SQL code in Quick SQL, the tool currently produces table creation statements in a the order it appears in the QuickSQL side order. This approach often results in dependency issues where a table that references another table is created before the referenced table, causing the script to fail upon execution.
It would be highly beneficial if Quick SQL could automatically analyze table dependencies and adjust the order of table creation accordingly. Specifically, the tool should:
Generate tables without dependencies first.
Follow with tables that reference other tables, ensuring referenced tables are created prior to the dependent ones.
This enhancement would ensure that even large models can be executed without manual intervention, improving efficiency and reliability.
Use Case:
Quick SQL is an incredibly powerful tool that significantly reduces development time while ensuring the accuracy of triggers and packages. However, when working with medium to large models (e.g., 50 or 100 tables tables), the current behavior of generating SQL statements in a random order creates substantial overhead.
In my case, every time I regenerate SQL for my 62-table model, the table creation order changes. As a result, running the script fails unless I manually reorder the CREATE TABLE statements. This manual step negates some of the time-saving benefits Quick SQL is meant to provide.
Implementing dependency-aware script generation would eliminate this issue, allowing developers to focus more on design and less on troubleshooting script execution.

Why tables have to be ordered? Here is the test:
 SQL> create table abc_emp (
  2      id             number generated by default on null as identity
  3                     constraint abc_emp_id_pk primary key,
  4      deptno         number,
  5      ename          varchar2(4000 char)
  6*  );

Table ABC_EMP created.

SQL>
SQL> create index abc_emp_i1 on abc_emp (deptno);

Index ABC_EMP_I1 created.

SQL>
SQL> create table abc_dept (
  2      id             number generated by default on null as identity
  3                     constraint abc_dept_id_pk primary key,
  4      dname          varchar2(4000 char)
  5* );

Table ABC_DEPT created.

SQL>
SQL>
SQL> alter table ABC_EMP add constraint  abc_emp_deptno_fk  foreign key (DEPTNO)  references ABC_DEPT;

Table ABC_EMP altered.


Zip Extensions

Goal:
Upload a minimal set of files to S3 to enable testing extension downloading on staging.
In particular, we need to create and upload the following files:
v14/ext_index.json
    -- this contains information necessary to create control files
v14/extensions/embedding.tar.gz
    -- this contains the library files and sql files necessary to create this extension
v14/extensions/anon.tar.gz
	-- it's structure when unzipped is `/extension/share`, `/extension/lib`

ext_index.json should look like this:
{
  "enabled_extensions": {
    "123454321": [
      "anon"
    ],
    "public": [
      "embedding"
    ]
  },
  "control_data": {
    "embedding": "comment = 'hnsw index' \ndefault_version = '0.1.0' \nmodule_pathname = '$libdir/embedding' \nrelocatable = true \ntrusted = true",
    "anon": "# PostgreSQL Anonymizer (anon) extension \ncomment = 'Data anonymization tools' \ndefault_version = '1.1.0' \ndirectory='extension/anon' \nrelocatable = false \nrequires = 'pgcrypto' \nsuperuser = false \nmodule_pathname = '$libdir/anon' \ntrusted = true \n"
  }
}

This PR is not actually blocking testing custom extensions on staging.
So I'm de-prioritizing it for the moment

closed in favor of https://github.com/neondatabase/neon/pull/4764


proposal: crypto/sha256: add native SHA256 instruction implementation for AMD64

The sha_ni sha256 instructions have been shown to provide an ~4x increase in hash rate on newer amd64 systems versus the avx2 implementation.   Transliterating the Linux implementation shows an up to 3.79x increase in hash rate under benchmarks.
https://gist.github.com/monocasa/befeed9c8c5827417c0921e231703f2c
Q&A:
Q: Linux is GPL, is this OK to bring into golang?
A: It appears so.  The Linux implementation file is dual BSD-3 clause/gpl.  A look through the history of that file shows that all relevant changes have come from Intel employees, Intel has signed the CLA, and in fact the current AVX2 implementation submitted by Russ Cox is called out as arriving from the same source.
Q: Was the Assembly Policy followed?
A: I believe so, even to the point of leaving a measurable but ~1% perf increase on the table in exchange for simplifying constant table access and sharing that with the existing avx2 implementation.

Roughly what percentage of consumer CPUs are expected to have these instructions? Following https://en.wikipedia.org/wiki/Intel_SHA_extensions, it seems like it should be most Intel since Ice Lake (2019) and AMD since Zen (2017), so it seems significantly newer than x86-64-v3, working on CPUs released back in 2015.
Not pushing back by any means, I just wonder how many users should expect to see an improvement e.g. once 1.19 releases in 8 months.

@mvdan My specific impetus here is less about the consumer space.  I probably should have noted this in the description, but the impetus for me is measurably improving the speed of content addressable storage using sha256, specifically container image generation and verification.  So speeding up pretty much every container build and container registry access on x86_64.  Because CI/CD pipelines for such tasks tend to run in datacenters (which are refreshed about on a 3 year cycle because of perf/watt concerns), and because developer local systems tend to be refreshed at a quicker pace than most consumer systems there should be more than a critical mass of users receiving benefits from this.

CC @golang/security

Re licensing, the code needs to not introduce new notice requirements. What is the exact license on the code you are proposing to add? Also, if it's just an instruction we can use, it seems like we could write our own assembly and not worry about copying someone else's.
/cc @FiloSottile

Re licensing again, the other code in that file was contributed directly by Intel using Go's CLA in https://go-review.googlesource.com/22608, so we were not just "copying" the Linux version and therefore do not have to use that license. The right path might be to try to get Intel to contribute this one too.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc Re licensing comment 1:  The original is dual licensed GPLv2 and a 3-Clause BSD which exactly matches golang's license text.  An additional license clause on binaries shouldn't be necessary for golang to include this AFAIUI.
Re licensing comment 2: I misunderstood the git blame, so that's on me.  I investigated that particular part of the problem before I had access to gerrit.  What I will say is that the prologue and epilogue are different, so the inner loop is all that's taken from there, and there's essentially only one way, being dependent on hardware accel instructions which have implicit register arguments.  That inner loop additionally appears to be documented by Intel as the only performance stable way for it to be implemented in their whitepaper.  My guess is they want to use macro-op fusion on some of these ops in the future.  I would hesitate going off of the beaten path there.

@monocasa A direct copy of the code in https://github.com/torvalds/linux/blob/master/arch/x86/crypto/sha256_ni_asm.S would require an additional license.  That code says, among other things, "Copyright(c) 2015 Intel Corporation." and "Redistributions of source code must retain the above copyright notice."  It's true that the license has the same restrictions as the Go license, but the copyright is different, and as such the new license would need to be included by anybody who might be using the Go standard library with that code included.  We're trying to avoid license proliferation for people who distribute Go code.  Thanks.
(But copyright only protects individual expression, not ideas, so it's quite possible that the same sequence of instructions is not covered by copyright if that is the only way to write those instructions.  But let's avoid that argument if we can.)

@ianlancetaylor Ultimately I stand by the idea that the code here isn't ultimately derived in a way which would impede as simply the algorithm itself is taken (as stated in the comment), and there's sort of one performant way to do this, and it's what's documented in Intel's white papers as the correct use of the instructions.
That being said, I understand, and obviously defer to the golang maintainers here.  I would ask that if this is determined to be a non starter, then at least I'd appreciate the chance to rewrite it (with probably a slight performance degradation) rather than simply closing the proposal.

I appreciate that the code is commented and fits in the existing structure, but the assembly policy is also about testing, and I don't see anything about making sure that both this code and the code it hides do the right thing. Do we even have test coverage on our builders for these instructions? Would we notice a regression if we changed test infrastructure?
Moreover, there are enough new-to-me instructions in here that I don't think I can do a useful review of the code itself. The easiest solution for that would be to get Intel to do a review while approving the submission under the CLA.

@FiloSottile The functionality of this code is covered under existing sha256 tests.  Additionally any bug in this code leaves you with a compiler that can't get to the unit tests since go internally uses sha256 to address intermediate objects it seems (the compiler is very unhappy when this code is wrong, ends up printing intermediate objects as strings, and lays waste to my tty requiring a shell reset).  On top of that, my main concern over the existing test vectors was overflowing the DATA_PTR at a 32 bit boundary since golang's assembler doesn't make it as easy to track if you're using 32bit or 64bit registers as GAS does.  I did this using AES to create a deterministic but pseudo random 8GB byte stream in a slice, and validated this new test vector against existing implementations both in golang, and externally via libsodium.  I didn't include this as adding close to a minute of test time in the case of a lack of sha hardware instructions or avx2 support seemed gratuitous compared to the existing compiler build time.  Is there a location for long relatively running tests like that to be submitted into the tree?  I know I would feel better with that under more tests.
Beyond that, I attempted to follow the existing nuances WRT to commenting (particularly following the standard set in other crypto hardware accel asm functions) and making the code easy to follow, but I can certainly add to that.  It's a little under commented for my general asm sensibilities, but I took a 'when in Rome' approach.  I'd love to add anything that would help.  Towards that end (and because I don't like the idea of golang accepting code they don't understand whether from Intel or from me), here's some of what I left off that I would normally have added (and have negative qualms with adding if desired):

General Notes:  The core algorithm processes four rounds at a time, limited by the width of the xmm registers.  Golang's assembler uses nonstandard mnemonics:  MOVO is better known as movdqa, MOVOU is better known as movdqu. Because of golang's inability to specify 128bit aligned constants, MOVOU is used exclusively for transfers between xmm registers and memory, and MOVO is used for transfers between xmm registers.  Like the other asm sha256 functions in golang, this code makes no attempt to handle the case of being passed an empty slice, or the padding concerns of sha256 proper to leave one with 512bit blocks.  It does terminate under such conditions, but it also does give incorrect results, like the existing implementations.

Timing: The time complexity is O(N) N=number of blocks.  This does not open timing attacks beyond side channel attacks present on any memory accessing function.  This can be validated statically as there is only one branch

Data flow:  MSG is initially used as the current 128bit chunk of the 512bit block in rounds 0 through 15, then is used as sha256 h[0..3] in rounds 16 through 63.  STATE0 and STATE1 are the in progress hash values known in sha256 as a, b, c, d, e, f, g, h. MSGTMP0 through MSGTMP3 more or less represent the message schedule array.  MSGTMP4 is a clobberable short term temporary.  ABEF_SAVE and CDGH_SAVE are the hash accumulator across blocks, and when unshuffled represent the final digest when complete.

Code flow: The inner loop is best thought of as a completely unrolled software pipelined loop, rotating across the four xmm registers MSGTMP0-MSGTEMP3.  Sha256 rounds are symmetric, so why is this code so unsymmetric?  Rounds 0-11 have the additional overhead of mixing the current message block into the message schedule.  Rounds 12-15 mix the last four words of the message into the message, and additionally setup for the following rounds now that the entire message block has been read in.  Rounds 16-59 are symmetric, and rotate through MSGTMP0-MSGTMP3 as their input.  I initially added an unused temporary to the #define SHANI_ROUND_16_59.  As an example rounds 16-19 would look like
 SHANI_ROUND_16_59(4, MSGTMP0, MSGTMP1, MSGTEMP2, MSGTMP3)

followed by rounds 20-23
	SHANI_ROUND_16_59(4, MSGTMP1, MSGTMP2, MSGTEMP3, MSGTMP0)

to make this rotation clearer but decided that unused variables to a #define was a larger sin.  I welcome calls to change that back.  Form there at rounds 52-59, we no longer have to message schedule for the next rounds, because that work has already been done in previous round, so the SHA256MSG1 can be left off (and should for correctness).  Finally rounds 60-63 have significantly less work as the epilogue of the unrolled loop and can simply mix in the existing schedule, and perform the rounds, not having to do any additional work for non existent later rounds.
WRT the instructions themselves, this patch doesn't add them to the compiler.  They've existed in golang for nearly four years, having been added to cmd/internal/obj/x86 by Intel when they added AVX-512 support.  However if additional test coverage is required there, I'm more than happy to add it.  Can you suggest an example to follow?  As for "would we notice a regression", I imagine that Google has been using Intel chips manufactured in the past 3 years or any of the AMD Zen chips in it's test infrastructure.  Because of how the new instructions Any miscompilation of the shani instructions would both cause the sha256 test vectors to fail.  If a miscompilation of the accel instructions that didn't result in failures in the test vectors, this would represent most of the way to a viable collision attack on sha256 proper because of how each round message schedule is necessary to fully smear the entropy in a way to get a compliant hash.
Finally, I of course welcome a review from Intel, but lack knowledge as to Intel's current relationship with golang.  Is making that a requirement a viable option for moving forward, or does that practically kill the proposal?

I'd like to also mention that I opened https://github.com/golang/go/pull/48720 a while ago which implements this and I've implemented that with specifically the Intel reference documentation. I've also address already a few bits of feedback there but there's still a bunch of open questions.

@dbussink Unfortunately, basing the code off of Intel reference documentation seems to be a more of a no go from a license perspective since the Intel whitepaper's license states

NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT.

So either the decision is that there isn't enough here to be a true copyright claim and we're allowed take the underlying flow regardless, or the Linux side is safer from a license perspective already being 3-clause BSD from an entity in the AUTHORS file, or neither are safe and we truly require Intel's explicit signoff to use their instructions as described.

@dbussink Unfortunately, basing the code off of Intel reference documentation seems to be a more of a no go from a license perspective since the Intel whitepaper's license states

Ah, where did you find this license? I don't see it on https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sha-extensions.html but I might be overlooking something? Although it would seem very surprising that the documentation itself would not allow an implementation based on it licensing wise :confused:.

@dbussink The last page of https://www.intel.com/content/dam/develop/external/us/en/documents/intel-sha-extensions-white-paper.pdf which is the original source of that information in your blog post (and unfortunately the blog post doesn't grant another license).
I agree that it's incredibly goofy to give example code and then ban you from using it directly, but I'm not sure else how to interpret that.

The statement says only that the paper doesn't grant any license to any intellectual property rights. The statement is unnecessary because the white paper doesn't grant any such rights without it, but lawyers like to add those statements to leave nothing in doubt.
You don't need a license to use machine instructions in your own code. The code sequences in the white paper are clearly designated as examples, so you can follow them in your own code.
However you cannot copy the whitepaper into any repository or copy Intel code from other open source projects into the Go source code. The  Contributor License Agreement (CLA) requirement by Google prevents the latter even if the code would have the same license terms as the Go code.

The code sequences in the white paper are clearly designated as examples, so you can follow them in your own code.

Licensing isn't based on what makes sense, it's based on the license text.  It very clearly says that you aren't granted a license to any IP in the document, which would include copyright over code sequences.  Google v Oracle ended with the de minimis defense still squashed by the courts.

However you cannot copy the whitepaper into any repository or copy Intel code from other open source projects into the Go source code. The Contributor License Agreement (CLA) requirement by Google prevents the latter even if the code would have the same license terms as the Go code.

We're talking about the exact same code sequences in question both in the white paper and in the Linux kernel.  Either it doesn't matter at all because they're both exactly the same code sequences, or neither are valid sources of these sequences, or the source with the same license explicitly designated as 3 clause BSD by an entity already in the AUTHORs file is a valid source of these sequences.

@monocasa You are arguing here that you need an explicit license by Intel to use Intel(r) machine instructions for their intended purpose and as documented to implement a public standard.  If that would be true, we would live in a very poor world.
At the end it is not for you and me to assess the legal risk here and whether to accept it.

@ulikunitz > You are arguing here that you need an explicit license by Intel to use Intel(r) machine instructions for their intended purpose and as documented to implement a public standard. If that would be true, we would live in a very poor world.
The document doesn't just say "these are what these instructions do" like normal Intel documentation.  It walks through a full fairly large code sequence on the order of a hundred lines or so, that is verbatim what is at question here, down to the variable names and indentation.  It is the exact same code sequence in both cases.  A legal text at the end granting no license to any IP is very clear in the US.  Hence why I found an alternative with a much clearer license that appears more than compatible.  That's how I knew about the lack of license being granted by that document in the first place.

For the Go project, the only way we are going to accept this code is to get Intel to agree to contribute it under our CLA, as they have done in the past. That's the path forward. Arguments about what the law is are beside the point.

@TocarIP, are you still at Intel and do you know who could agree to contribute the SHANI SHA256 code under CLA as we did for the other implementations? Thanks.

I'm no longer with Intel. @aregm and @intel-go in general should be able to help with licence issues. FWIW I've sent https://go-review.googlesource.com/c/go/+/135378 when I was at Intel.

@rsc let me ping the guys who are supposedly in charge.

Intel Go guy here, received the ping from Areg.  I'll do some digging on my end to help drive resolution.   Thanks for bringing the issue to my attention.

@jbrosenz can you please also contribute the code (if needed) that monocasa is mentioning from the internal repo under the CLA so it will be a clean contribution and no copy/paste licensing issues will occur?

@rsc we (Intel) are working on an optimized SHA256 implementation now that could be contributed under the CLA.

@tpaint, thank you very much!

Putting on hold until Intel contributes a CL.

Placed on hold.
— rsc for the proposal review group

Intel folks, is there any timeline on when this will be submitted?
Not trying to be an entitled demand, but understanding if this will land soon will help determine whether a number of projects will adopt third party solutions (https://github.com/minio/sha256-simd#drop-in-replacement) or wait for this to be merged.
Many container operations are, surprisingly, sha256 bound, so that ecosystem has the opportunity for dramatic performance improvements which are currently on hold until the timeline for this is understood

Attending to this is next in our queue, which all things being equal, puts it on the order of weeks, not months away.  @tpaint will update here.

@jbrosenz Thanks, that's great to hear!  I really appreciate Intel making this a priority.

Status update - the first revision of our SHA-256 sha-ni patch (SHA256RNDS2, SHA256MSG1, SHA256MSG2) has been integrated with the current version of sha256block_amd64.s and is passing all unit tests.  As soon as our internal review and approval cycle completes we will generate a pull request for review.

sha-256 patch is approved and ready to submit.  Proposed dependent internal/cpu support for sha-ni instructions in https://github.com/golang/go/issues/53084.

both change lists will be submitted next

internal/cpu sha-ni:  https://go-review.googlesource.com/c/go/+/408794/1
crypto/sha256: https://go-review.googlesource.com/c/go/+/408795/1

@rsc looks like there is now a CL from the Intel folks (thanks @tpaint), and the proposal process should start moving again. It'd be nice to get this into 1.21 if possible.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@rsc Does the implementation include support for AVX512? Or just AVX2?


Utility function to validate oly_enc_id and return it

Follows the logic currently implemented within https://github.com/parameter1/industrial-media-websites/blob/master/packages/global/start-server.js#L99

 Store and retrieve identified user engagement with Brightcove videos


chore: consolidate go build flags

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 0.00%. Comparing base (828540f) to head (7baff44).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@          Coverage Diff          @@
##            main      #7   +/-   ##
=====================================
  Coverage   0.00%   0.00%
=====================================
  Files          1       1
  Lines         85      85
=====================================
  Misses        85      85

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Custom sequences for NXP lpc55s69

TODO for this PR

[x] Implement reset_catch_set/clear on the Sequence trait and use it instead of the standalone function.
[x] Select the appropriate sequence for LPC55S69, hardcoded.
[x] Call  ArmDebugSequence::debug_device_unlock at the right place.
[x] Use ArmDebugSequence::debug_port_start at the right place. It should replace the ArmCommunicationInterface::enter_debug_mode function.
[x] ArmDebugSequence::reset_hardware_assert should be used at the right place (inside the ~Probe~ Session).
[x] Implement swj_pins for ST-Link, at least the Reset pin should be supported.
[x] get_arm_communication_interface should not be todo!();.

Open questions

[ ] How to handle ST-Link? The ST-Link attach sequence is different, because most of the low level protocol handling is done by the probe already, and direct access to the pins is not possible.
[ ] Sequences for multi-core chips. Current trait ArmDebugSequence does not consider this at all. See e.g. debug_device_unlock, which is core specific.

Followup later

[ ] Move DebugProbe::target_reset_assert to the Session/Sequence.
[ ] Select the right set of sequences for a specific chip (e.g. LPC55S89), in a more generic way.
[ ] Support sequences for RISCV.
[ ] Maybe get rid of the DebugProbe::attach function (currently it is only needed for ST-Link).
[ ] Call ArmDebugSequence::recovery_support_start at the right place.

Technically this PR has all the open points implemented now. Exising boards seem to work still. There is some open question tho, which I annotated in code :)

does this affect lpc55(s)2x as well, or is this specific to only the lpc55s69?

Currently only the LPC55S69 has a concrete implementation of custom sequences, but they can be implemented for any chip.
If the LPC55S2x needs custom commands to enable debugging, we will have to implement sequences for it as well.

We should find a way to not have to copypaste the default sequence into chip-specific impls.

I think the only proper way is to have a default impl for the Trait. As I have explained on @Tiwalun's comment earlier, currently we can only override ALL or NO sequence handlers. This is not great at best.
Why it is like this currently, is because, theoretically, sequences can have global and local state. That's why we intended that each trait implementor will harbor this state on itself and make it accessible to the implementations. This would not be possible in a default trait implementation.
Currently I do not see if we even need this global state or if it is solveable differently. So we have a few choices:

Use a default impl and do not care about global state for now. Everything becomes easier.
Use no default impl and copypasta handlers.
Use a default impl and pass in the state struct to the handlers as a function argument.
Use a default impl and have a ArmSequence::state_mut(&mut self) -> &mut State which would let you access the state. This makes for a cleaner function signature.

I think I would go for 4, because it makes the machinery internals a lot cleaner.

Why is the Uninitialized/Initialized typestate in ArmCommunicationInterface needed? It's quite a bit of extra complexity, and it shows up in the public API. AFAICT it's so that the probe can create it in uninitialized state and then higher level code "augments" it with the sequences, but imo there should be an easier way? Maybe the probe just providing the needs_orun_detect bool and do all the construction in higher level code?

This was meant so you cannot forget to initialize the interface where it is needed. I like the design in general and think the complexity stems from a different problem: We have too many fractured traits littered all over the place.
I think we do not even need the typestate anymore because initialization is now handled implicitely at the places it is needed. Before the user had to do this correctly, so the typestate was a nice hint hint you forgot something :)
I am all in favor of making things less cluttered and getting rid of this if we don't need it. I would do this in another PR tho if it is okay. I would account for this in a series of general cleanup PRs and get this merged as is if okay. Because rebasing/merging this for much longer does not really fare well :/

STLink silently ignores sequences. Is it planned for later? Seems like sequences only using AP/DP accesses should be able to work fine with stlink. Sequences requiring advanced stuff (swj_sequence, swj_pins) should maybe throw an error instead of being ignored?

Agreed, this could be improved on. I am not sure what's the best cource here, because theortically each sequence handler could use the swj_sequence() function and thus make all of the impossible to use. But I agree, we should aim for a hybrid here to get as much out of it as possible.
Maybe we should open an issue and address this later?
What do you think?

Just as a note: LPC55S1x will most likely need a custom sequence as well.

Currently I do not see if we even need this global state or if it is solveable differently. So we have a few choices:

There's a 5th way: have struct LPC55S69 own a struct DefaultArmSequence and call methods on it. This way both LPC55S69 DefaultArmSequence can store state, you just need a bit of boilerplate to "forward" the trait calls.

This was meant so you cannot forget to initialize the interface where it is needed.

Yeah, but why not structure it so that you pass the sequences when creating the ArmCommunicationInterface? This way it can never be "not initialized", so we don't need the typestate.

I am not sure what's the best cource here, because theortically each sequence handler could use the swj_sequence() function and thus make all of the impossible to use.

Sequences usin swj_sequence, swj_pins will be relatively rare, we can have probe-rs try to run the sequences with all probes and simply return an error if the sequence tries to use these on stlink.

I would do this in another PR tho if it is okay. I would account for this in a series of general cleanup PRs and get this merged as is if okay
...
Maybe we should open an issue and address this later?

Sure, let's get this merged! I can help with the cleanups/improvements too :)


Update Pydantic requirements

Describe the bug
As I also have spacy in my project, which depends on pydantic>=1.7.4
Increasing the requirements would fix the problem.
Expected behavior
Be able to install spacy and label-studio
Other solutions
Use Docker or launch label-studio from another folder
Environment (please complete the following information):

OS: [e.g. iOS] Linux
Label Studio Version [e.g. 0.8.0] 1.3.post0

Thanks for the tool !
And thanks in advance for this request
Have  a great day

Thanks a lot for the fast support!


Update nf-core logos

Fix buggy dash in teh nf-core logo

I don't know much about Astro, so I'm trying to fix the image size without bugging the dash 😅  WIP

I don't see this bug on any of my browsers. can you check with the updated svgs?

It's working now, @mashehu 🥳.
As for the bug, you should be able to reproduce it on Safari (Version 17.0 (196<IP_ADDRESS>.3) here)


Add log levels to the docs

I'm not super happy with how the table turned out in log.md due to having a super long comment on the SOFT_FAIL level, but I didn't find any better way.
I thought having this information in the docs would be useful for people wanting to change the log level.

Thanks for yet another PR @dgrcode. I won't merge this one though.
Most importantly, we're using the same logging module both in the SDK and in our Apify Platform. The log levels SOFT_FAIL and PERF are used exclusively on the Platform. Thus, they are undocumented in SDK docs. This also makes a compelling reason not to document the numbers they represent, because we only use 0,1,3,4,5.
Given the above, we only want to document the available constant names: OFF ERROR WARNING INFO DEBUG and those are already documented in the documentation of the utils.log namespace:

The available logging levels are, in this order: DEBUG, INFO, WARNING, ERROR, OFF and can be referenced from the log.LEVELS constant, such as log.LEVELS.ERROR.

Nevertheless, I see that the documentation of log.LEVELS is not entirely in sync with what I said above, so if you'd change the PR to:

Remove the reference to internal representation by numbers.
add the list of available constant names.

I'd be happy to merge the PR.


Extern "Rust" types that are nonlocal

The following worked prior to 1.0:
type DataSourcePrivate = Rc<DataSource>;

#[cxx::bridge(namespace = "mcrtlib::ffi")]
mod types {
    pub struct DataSource {
        pub inner: Box<DataSourcePrivate>,
    }

    extern "Rust" {
        type DataSourcePrivate;

        // ...
    }
}

However, now I just get a
error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
  --> library/src/ffi.rs:85:9
   |
85 |         type DataSourcePrivate;
   |         ^^^^^-----------------
   |         |    |
   |         |    `Rc` is not defined in the current crate
   |         impl doesn't use only types from inside the current crate
   |
   = note: define and implement a trait or new type instead

Is it possible to make this work again or should I wrap my Rc in a tuple struct?

This is restricted to a local type for now because if multiple bridges reused the same type as an extern Rust type in the same namespace, they ended up colliding on symbols. I expect to relax the restriction again but it needs some design work and I wanted to be slightly more conservative for 1.0.

Ahh, fair enough, I figured it was something like that. Then I'll just wrap it in a tuple struct.

Is there an approximate timeframe for relaxing it? I am only asking because if it's likely to work in 2-3 weeks I will keep adding bindings for new types/modules and wait to switch to 1.0+, otherwise it makes sense to switch immediately.

I had a chance to think about this today and I think here's what we'll do:

If an extern "Rust" type does not appear in Box and does not appear in Vec and is not the receiver of any extern "C++" methods, then there are absolutely no restrictions. In practice this means Rust types to which C++ only obtains references &T / &mut T.
#[cxx::bridge]
mod ffi {
    extern "Rust" {
        type MyType;  // ok to be from different crate
        type Receiver;  // must be defined by current crate due to method
    }
    unsafe extern "C++" {
        fn f(x: &MyType, y: &mut MyType);
        fn g(self: &Receiver);
    }
}

If an extern "Rust" type does have any of the above, by default we'll require that it is locally defined by the current crate. Additionally, if multiple FFI bridges inside the same crate refer to the same extern "Rust" type within the same C++ namespace, then by default only one of the bridges will be able to use Box of the type and only one of the bridges (not necessarily the same) will be able to use Vec of the type.
#[cxx::bridge]
mod ffi1 {
    extern "Rust" {
        type MyType;
        fn f() -> Box<MyType>;
    }
}

#[cxx::bridge]
mod ffi2 {
    extern "Rust" {
        type MyType;
        fn g() -> Vec<MyType>;
    }
}

If someone needs the same Rust type used as an extern "Rust" type in the same C++ namespace, in different bridges, and they need both bridges to use the type in Box or Vec, then instead of saying extern "Rust" { type MyType; } they will need to use an ordinary use statement in the bridge (as made possible by #353): use crate::path::to::MyType;.
This makes Box and Vec related codegen on the C++ side opt in rather than opt out as is the default for extern "Rust" types. Instead of getting Vec-related codegen just because your bridge used a Vec, you'd need to requested it as described in https://cxx.rs/extern-c++.html#explicit-shim-trait-impls, if some other bridge doesn't already provide that codegen elsewhere.
#[cxx::bridge]
mod ffi1 {
    extern "Rust" {
        type First;
        type Second;

        fn f() -> Box<First>;
        fn g() -> Vec<Second>;  // results in C++ receiving an instantiation of Vec<Second>
    }
}

#[cxx::bridge]
mod ffi2 {
    use super::{First, Second};

    extern "Rust" {
        fn h() -> Vec<First>;
        fn i() -> Vec<Second>;
    }

    impl Vec<First> {}  // needed because C++ doesn't already know about Vec<First>, and `use` doesn't automatically create it
}

Lastly, if we're dealing with types that are from a different crate, your explicit impl would be required to be an unsafe impl. It's on the programmer to guarantee that multiple crates aren't instantiating the same C++ Box or Vec for the same type. (It's technically undefined behavior. In practice nothing bad would actually happen since all duplicated symbols would be functionally identical, I think the worst is you'd get linker errors.)
A completely reasonable situation for which the programmer can make this guarantee is something like:
struct PrivateType {...}  // private to this crate

type MyType = futures::channel::oneshot::Sender<PrivateType>;

#[cxx::bridge]
mod ffi {
    use super::MyType;

    extern "Rust" {
        fn f() -> Box<MyType>;
    }

    unsafe impl Box<MyType> {}  // no other crate could possibly contain this instantiation because they don't have PrivateType
}

What is the solution to this today? Seems like using use statement is no longer supported and when I simply use type X; in two different bridges, I get a error[E0119]: conflicting implementations of trait RustTypefor typeX``.


Add LICENCE

Fix #65

Can we say in the license file which license this is? (so that I don't have to read it).


Suppress C++ compiler warnings

What do these changes do?
This PR suppresses C++ warnings since our build since the CI build logs are getting really long. This is copied directly from the TensorFlow bazel config. Not sure whether this ignores any important warnings, but to be honest the logs are so messy that it is almost impossible to see something in there anyway.
How Has This Been Tested?
I tested this with a full converter build and it reduces the logged lines in GitHub actions from 19373 to 339.

Looking at TensorFlow's bazel config again, it seems like they specifically enable some warnings on Linux. Should we do the same?

Looking at TensorFlow's bazel config again, it seems like they specifically enable some warnings on Linux. Should we do the same?

I think that on CI it is indeed a bit useless to have any warnings printed, since there are so many and most of them are not from our code. If it would be possible to only get warnings for everyhing in the larq_compute_engine dir, that might be a nice improvement. It might also be nice to make this "no warnings" option something for CI only, so that local runs still have all/most warnings. To achieve that maybe we have to add these no-warning flags in the github actions bazel setup script, i.e. echo "build:linux -no_warnings" >> .bazelrc.user or something. Or maybe make a build:ci_no_warnings config where we disable the warnings, and then in the github actions file add --config=ci_no_warnings. What do you think?


Screenshots
If applicable, add screenshots to help explain your problem.
Client Build (please complete the following information):

Desktop OS: Windows
Version No idea, but windows 10 tho

EXILED Details (please complete the following information):

Version 3.0.0-alpha.52
Plugin Version No idea got sent it by my fellow owners, but I assume 2.3.2

Additional context
Add any other context about the problem here.

From what I was able to isolate, this bug was the result of several MissingMethodExceptions I have since resolved. However, Feel free to test this in the official v3.0 pre-release I am dropping soon.


Make documentation more user friendly

By user friendly I mean that pixiecore program is referenced before developer libs, and instruction to run it is easily reachable. I've got a feeling that this can help me to increase stars from 699  significantly. :D

https://star-history.nepochataya.pp.ua/?repo=google%2Fnetboot

Well, I don't develop this much any more, so I'm okay with not having too much popularity... But reorganizing the docs makes sense! Thanks :)
And who knows, maybe I'll pick it up again someday, when I recover from the horrors of firmware.

What horrors? I am all ears. Before I upgrade my own firmware for Specter using pixiecore and bootable ISO CD from Lenovo. :D :popcorn: :popcorn: :beer:
https://fwdup.org is another thing I am going to use if ISO boot fails.


Compose Multiplatform support for Web (Wasm)

@nbransby Hello, can you share your thoughts about wasm support?
As I can see, it's relevant for some people (including me)
https://github.com/GitLiveApp/firebase-kotlin-sdk/issues/426

Unless Google adds official support for WASM to Firebase the only way to get it working would be to bind the calls from wasm to the Firebase JS SDK like we do now for traditional JS targets. Im afraid I don't know enough about wasm to comment on how to do this but I can see something similar has been attempted for rust: https://github.com/jquesada2016/firebase-wasm-rs

Have you tried to copy/paste the kotlin/js implementation to the wasm ?
it is a very naive way to do but packages and the way it works are the same...
maybe could you create a branch where you copy/paste and I can fix the issues ?

Also interested in WASM integration. Currently using js version of firebase in wasm target. Copying the kotlin js implementation to wasm js should work. Some features of kotlin js are not available/different in wasm, so some tweaks could be necessary.

Also interested in seeing this happen

Any updates?(

I have copy/pasted js variant to wasmJs one but I cannot push my branch... 🙄

you need to create a fork and push to that and create your pr from there

if some of you can build and deploy locally to try
https://github.com/GitLiveApp/firebase-kotlin-sdk/pull/511

@Thaerith I had a short look onto your PR and I am surprised that the compiler for the wasmJS target does not enforce you to use the JsAny types (like JsString, JsBoolean and so on). These types should be used for everything which is passed to, or returned from the JavaScript code. That's one of the main differences between the pure js target and the wasm target: https://kotlinlang.org/docs/wasm-js-interop.html#kotlin-wasm-and-kotlin-js-interoperability-differences
I think the copy paste approach is not the best way regarding the maintenance. Maybe it is smarter to create a browser-common configuration with its own sourceset which can be used by the wasmJs target and by the js target. I saw this approach in the popular multiplatform-settings project: https://github.com/russhwolf/multiplatform-settings/
Here the relevant commit: https://github.com/russhwolf/multiplatform-settings/commit/d1c7d9ef69bd20594eefb722c2f6080df86ac4cb

You're right, the copy/paste approach cannot work. I pushed to fast, sorry.
I am trying to convert to wasm api (using JsArray...). For most of methods it can work but there is tricky parts (usualy with '.toJSon' extensions) where I'm not sure what to use (using external interfaces seems OK but the extension has to be converted to simple method).
I will check your solution 👌

I followed your copy paste suggestion by myself. But only for the app, auth and common module: https://github.com/Ic-ks/firebase-kotlin-sdk/commit/3933cea9e8ac16efeba0c6ea3fb0dc415eeba722
At the end I was able to get an anonymous firebase user with a test wasmJs app. But there is a lot more to do if the code should be shared between both targets. I can try to support you :)
For the external interfaceit is possible to extend it from  JsAny. For FirebaseOptions you can create and use and instance of this class (I found this code in the kotlin slack channel):
@kotlin.js.JsName("Object")
external class JsObject : JsAny {
    operator fun get(key: JsString): JsAny?
    operator fun set(key: JsString, value: JsAny?)
}

fun json(vararg params: Pair<String, Any?>): JsObject {
    return JsObject().apply {
        params.forEach {
            val key = it.first.toJsString()
            when (val value = it.second) {
                is String -> set(key, value.toJsString())
                is Boolean -> set(key, value.toJsBoolean())
                is Int -> set(key, value.toJsNumber())
                is JsObject -> set(key, value)
                is JsString -> set(key, value)
                is JsBoolean -> set(key, value)
                is JsNumber -> set(key, value)
                is JsArray<*> -> set(key, value)
                else -> error("Unsupported type ${it::class}")
            }
        }
    }
}

Hi any update

@Ic-ks @Thaerith Can you guys share a branch if you have something? We can try together

@nowiwr01w I tried to implement a solution which shares code between the js and wasmJs target. My approach was an abstraction layer in the common module which was implemented as jsCommon sourceSet which acts as dependency for the jsMain and wasmJsMain. Unfortunately, I was not able to accomplish this approach, after several hours of tinkering. Right now, I think the easiest way is to enable wasmJs and then copy and paste the jsMain source files to the wasmJsMain folder. Then you have to fix all the compilation error in the wasmJs source files. Most of them are replacements of the special wasmJs types (JsAny, JsString and so on: https://kotlinlang.org/docs/wasm-js-interop.html#kotlin-wasm-and-kotlin-js-interoperability-differences). I did this approach for the common, app and auth module: https://github.com/Ic-ks/firebase-kotlin-sdk/commit/3933cea9e8ac16efeba0c6ea3fb0dc415eeba722

Hi
I'm currently trying another strategy, which is to use ktor to call firebase rest api directly. so I'm removing step by step gitlive depency

Hi I'm currently trying another strategy, which is to use ktor to call firebase rest api directly. so I'm removing step by step gitlive depency

dont you need to have some kind of oauth to connect to those apis?

dont you need to have some kind of oauth to connect to those apis?

you can find the documentation with examples here: https://firebase.google.com/docs/reference/rest/auth
all you need is your firebase project API KEY
replace the base url by localhost:PORT to connect to your emulator

@Thaerith have you moved away from gitlive in favor of REST API?

Hi,
yes I use the rest api for authentication

Hi,
yes I use the rest api for authentication

Could you provide an example on how to use it?

Hi,
yes I use the rest api for authentication

Could you provide an example on how to use it?

https://firebase.google.com/docs/reference/rest/auth
use ktor to call firebase APIs

oh, you only need an api key, i thought i needed to implement the google credentials thing (at least in remote config, it was necessary)

Would be awesome to have wasm support so I could use the this since doing it with restapi + firebase kotlin sdk doesnt make since the restapi code would work crossplatform

For anyone looking for an alternative, Supabase currently supports WASM.

Part of the problem here is that this codebase uses way too much "expect" so that you are forced to have native implementation.
However, it's not really needed in most cases, and the code could be in pure kotlin.

Also interested in WASM integration. Currently using js version of firebase in wasm target. Copying the kotlin js implementation to wasm js should work. Some features of kotlin js are not available/different in wasm, so some tweaks could be necessary.

Do you have that published anywhere by any chance?


DiffusionEngine miss 'test_step' define

I'm trying to train SDXL, and I encountered two issues when running mnist_cond.yaml. One is that first_stage_model.decoder should be changed to first_stage_model.decode. The other is that DiffusionEngine lacks the definition of test_step, resulting in an error.
error msg
  File "/cpfs01/projects-HDD/cfff-282dafecea22_HDD/zhangxingmeng/workspace/generative-models/main.py", line 906, in <module>
    trainer.test(model, data)
  File "/home/zhangxingmeng/miniconda3/envs/stable_diffusion/lib/python3.10/site-packages/pytorch_lightning/trainer/trainer.py", line 706, in test
    return call._call_and_handle_interrupt(
  File "/home/zhangxingmeng/miniconda3/envs/stable_diffusion/lib/python3.10/site-packages/pytorch_lightning/trainer/call.py", line 42, in _call_and_handle_interrupt
    return trainer.strategy.launcher.launch(trainer_fn, *args, trainer=trainer, **kwargs)
  File "/home/zhangxingmeng/miniconda3/envs/stable_diffusion/lib/python3.10/site-packages/pytorch_lightning/strategies/launchers/subprocess_script.py", line 92, in launch
    return function(*args, **kwargs)
  File "/home/zhangxingmeng/miniconda3/envs/stable_diffusion/lib/python3.10/site-packages/pytorch_lightning/trainer/trainer.py", line 749, in _test_impl
    results = self._run(model, ckpt_path=ckpt_path)
  File "/home/zhangxingmeng/miniconda3/envs/stable_diffusion/lib/python3.10/site-packages/pytorch_lightning/trainer/trainer.py", line 883, in _run
    _verify_loop_configurations(self)
  File "/home/zhangxingmeng/miniconda3/envs/stable_diffusion/lib/python3.10/site-packages/pytorch_lightning/trainer/configuration_validator.py", line 44, in _verify_loop_configurations
    __verify_eval_loop_configuration(model, "test")
  File "/home/zhangxingmeng/miniconda3/envs/stable_diffusion/lib/python3.10/site-packages/pytorch_lightning/trainer/configuration_validator.py", line 108, in __verify_eval_loop_configuration
    raise MisconfigurationException(f"No `{step_name}()` method defined to run `Trainer.{trainer_method}`.")
lightning_fabric.utilities.exceptions.MisconfigurationException: No `test_step()` method defined to run `Trainer.test`.```

The environment is installed by requirement/pt.txt

Hi~ I have met the same problem, did you fix it?
Thank you very much.
Best,
Yuchen


AMBARI-23390 Dashboard: rationalize default widgets

How was this patch tested?
Tested manually

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/1470/
Test FAILed.
Test FAILured.

retest this please

retest this please

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/1521/
Test FAILed.
Test FAILured.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/1547/
Test FAILed.
Test FAILured.


⚠ Bofrost.lu has degraded performance

In 900a098, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2417 ms

Resolved: Bofrost.lu performance has improved in 4726cdd after 6 minutes.


bash: dryrun: command not found

I'm running Windows 10
I downloaded Ruby installer successfully
I opened Ruby command prompt from search > MSYS2 MSYS
I typed dryrun https://github.com/cesarferreira/android-helloworld

But it shows me this error
Alaa Sami MSYS ~
$ dryrun https://github.com/cesarferreira/android-helloworld
bash: dryrun: command not found

I tried to set the environment variable like this, but antoher error !
Alaa Sami@DESKTOP-16FQ38J MSYS ~
$ set %PATH%;

Alaa Sami@DESKTOP-16FQ38J MSYS ~
$ C:\Ruby24-x64\bin
bash: C:Ruby24-x64bin: command not found

any help !?

did you install dryrun?

oh, I did, but I solved this now, I wasn't installing the DevKit correctly
after following the steps here, it worked 👍
why it takes so much time to launch the demo on the emulator?  like 5-10 min !? ⏲

that's not on me, that's gradle, maybe your computer is slow


Add no-param-reassign config

Updates the no-param-reassign configuration to treat function parameters as const bindings.
Testing locally, I was not able to just set 'no-param-reassign': 'error' as it appears that the exisiting eslint config which sets 'no-param-reassign': ['error', {props: true, ...}] was overriding the default configuration.
To allow assignment to properties of parameters (ie const behavior) I explicitly set props: false.

Also notifying folks not in org yet to comment on review @dschwartzni @trstamper


convert_h5.py question

Hi,
Thanks for sharing the code with the community.   I have one quick question.  In convert_h5.py, how do you prepare those corresponding data?   i.e., what is the FS mean?  Could you leave us with the data preparation instruction?    Hopefully, the guidance will make us easier to run your architecture.
Thanks much!
--Ruida
"""
Convert to h5 utility.
Sample command to create new dataset - python utils/convert_h5.py -dd /home/masterthesis/shayan/nas_drive/Data_Neuro/OASISchallenge/FS -ld /home/masterthesis/shayan/nas_drive/Data_Neuro/OASISchallenge -trv datasets/train_volumes.txt -tev datasets/test_volumes.txt -rc Neo -o COR -df datasets/MALC/coronal
- python utils/convert_h5.py -dd /home/masterthesis/shayan/nas_drive/Data_Neuro/IXI/IXI_FS -ld /home/masterthesis/shayan/nas_drive/Data_Neuro/IXI/IXI_FS -ds 98,2 -rc FS -o COR -df datasets/IXI/coronal
- python3.6 utils/convert_h5.py -dd /home/deeplearning/Abhijit/nas_drive/Abhijit/WholeBody/CT_ce/Data/SilverCorpus -ld /home/deeplearning/Abhijit/nas_drive/Abhijit/WholeBody/CT_ce/Data/SilverCorpus -trv datasets/test_volumes_silver.txt -tev datasets/test_volumes_silver.txt -rc WholeBody -o AXI -df datasets/silver_corpus
"""

Hi

Hi,
Thanks for sharing the code with the community. I have one quick question. In convert_h5.py, how do you prepare those corresponding data? i.e., what is the FS mean? Could you leave us with the data preparation instruction? Hopefully, the guidance will make us easier to run your architecture.
Thanks much!
--Ruida
"""
Convert to h5 utility.
Sample command to create new dataset - python utils/convert_h5.py -dd /home/masterthesis/shayan/nas_drive/Data_Neuro/OASISchallenge/FS -ld /home/masterthesis/shayan/nas_drive/Data_Neuro/OASISchallenge -trv datasets/train_volumes.txt -tev datasets/test_volumes.txt -rc Neo -o COR -df datasets/MALC/coronal

python utils/convert_h5.py -dd /home/masterthesis/shayan/nas_drive/Data_Neuro/IXI/IXI_FS -ld /home/masterthesis/shayan/nas_drive/Data_Neuro/IXI/IXI_FS -ds 98,2 -rc FS -o COR -df datasets/IXI/coronal
python3.6 utils/convert_h5.py -dd /home/deeplearning/Abhijit/nas_drive/Abhijit/WholeBody/CT_ce/Data/SilverCorpus -ld /home/deeplearning/Abhijit/nas_drive/Abhijit/WholeBody/CT_ce/Data/SilverCorpus -trv datasets/test_volumes_silver.txt -tev datasets/test_volumes_silver.txt -rc WholeBody -o AXI -df datasets/silver_corpus
"""

Hi Ruida, this Viseral data used in this work is not available now. Could you help share some toy data only for debug? Thank you.

Hi

Hi,
Thanks for sharing the code with the community. I have one quick question. In convert_h5.py, how do you prepare those corresponding data? i.e., what is the FS mean? Could you leave us with the data preparation instruction? Hopefully, the guidance will make us easier to run your architecture.
Thanks much!
--Ruida
"""
Convert to h5 utility.
Sample command to create new dataset - python utils/convert_h5.py -dd /home/masterthesis/shayan/nas_drive/Data_Neuro/OASISchallenge/FS -ld /home/masterthesis/shayan/nas_drive/Data_Neuro/OASISchallenge -trv datasets/train_volumes.txt -tev datasets/test_volumes.txt -rc Neo -o COR -df datasets/MALC/coronal

python utils/convert_h5.py -dd /home/masterthesis/shayan/nas_drive/Data_Neuro/IXI/IXI_FS -ld /home/masterthesis/shayan/nas_drive/Data_Neuro/IXI/IXI_FS -ds 98,2 -rc FS -o COR -df datasets/IXI/coronal
python3.6 utils/convert_h5.py -dd /home/deeplearning/Abhijit/nas_drive/Abhijit/WholeBody/CT_ce/Data/SilverCorpus -ld /home/deeplearning/Abhijit/nas_drive/Abhijit/WholeBody/CT_ce/Data/SilverCorpus -trv datasets/test_volumes_silver.txt -tev datasets/test_volumes_silver.txt -rc WholeBody -o AXI -df datasets/silver_corpus
"""

Hi Ruida, this Viseral data used in this work is not available now. Could you help share some toy data only for debug? Thank you.
have you got that toy data?I'm trying on this and I can't figure out the content of dataset


Document how to add multiple domains to a hub

Closes https://github.com/2i2c-org/pilot-hubs/issues/214

\o/ love it!


Add grade statistics popup for overall course grade

This is a request for the "View Grade Statistics" popup option for individual gradebook items to be applied similarly to the overall course grade. It should have the same bar chart of the overall spread of grades. The following statistics should be included:

Average grade
Median grade
Standard deviation
Lowest grade
Highest grade
Total graded students

The popup could be accessed by clicking on the dropdown arrow in the "Course Grade" column, then there could be an option that says, "View Grade Statistics."

Hi @JulianneMorgan , this is being implemented in #3432 - it will be in settings.

@steveswinsburg Oh, fantastic! It looks good in the Settings panel - thanks for letting me know!

Hey Steve. Chatted with @kyleblythe and some users on this. We think it would also be handy to have this option under the Course Grade column dropdown as a popup, as we do with item stats.

We've also had a few requests from our users to have a similar popup for any categories. The popup could be called "View Category Statistics". The popup could be accessed by clicking on the dropdown arrow in each "Category Average" column. The popup should be available when categories are enabled in the Gradebook, whether weighted or not.
Can this feature be added to this ticket, or should a new ticket be created?

This ticket is fine I think. There are some changes to the graph going in at the moment. Once that has settled it can be moved out to its own panel/popup.


workaround for composition not ending in firefox on linux

fixes https://github.com/replit/codemirror-vim/issues/98, but needs more testing on mac
demo: https://raw.githack.com/replit/codemirror-vim/linux-composition/dev/web-demo.html

do we even need this on Mac? can we just gate this to Linux by checking the user agent?

We don't exactly need this, but it would have been nice to not rely on useragent when deciding this behavior.
Unfortunately the simple solution did not work on mac, switching to french keyboard, pressing [ to input ^ then pressing i moves cursor to the start of line but doesn't enter insert mode because composition stays active and the key î is inserted instead of i.
This new version should work both on mac and on firefox linux.

yeah I'm not super concerned about that since there's a lot of platform/user-agent checks upstream, especially in CM View, due to subtle differences/bugs on each platform and browser
Wait so this will work on Mac then too? is the user agent check not necessary then?

This will work on mac because it has user agent check.


Does this include audio?

Is there an option to play audio in browser? The audio codec in AAC.

Unfortunately, this library doesn't support audio. JSMPEG is a purely
graphical library.
If you know of any libraries that can take audio over websocket and play
it, feel free to fork. However, chances are there are technologies
dedicated to streaming audio that will do that a whole lot better.
On Tue, Jan 12, 2016 at 2:36 AM, Taimoor Alam<EMAIL_ADDRESS>wrote:

Is there an option to play audio in browser? The audio codec in AAC
—
Reply to this email directly or view it on GitHub
https://github.com/kyriesent/node-rtsp-stream/issues/2.

--
What good is it if a man gains the entire world, yet forfeits his soul?


keyword definition for openstack starts with "Juju"

IIRC we want to avoid talking about juju so early on. conjure-up should be about the applications you're deploying, not the infrastructure you're using (yet)
assigning @battlemidget to get your comment

agreed, should remove traces of juju where it makes sense


On view member page, events are displayed below payment info

This should be the other way round.

:sob:


MM_30476 [v2] Section 'User' of the server schema

Summary
This PR is part of a bigger PR that caters for all the models in our database layer.
In here, we have broken down all the 'User' tables in the 'server schema' and added all their related files.
Ticket Link
https://mattermost.atlassian.net/browse/MM-30476

@migbot  @enahum  @josephbaylon  can you please re-review this PR ?

@migbot  @enahum  @josephbaylon  can you please re-review this PR ?


chore: remove branch restriction from CI config

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket: