bug(module:button): class ant-btn-icon-only is not applied to the icon-only-button

Reproduction link
https://stackblitz.com/edit/ng-zorro-antd-start-uaapgo
Steps to reproduce

I've tried to use the stackblitz to reproduce this bug, but seems like it's not yet supported<EMAIL_ADDRESS>(with Angular 9.1.1 & Ivy)

However, this bug is easy to reproduce as the sample code

<button nz-button nzType="danger"></button>
<button nz-button nzType="primary" class="ant-btn-icon-only"></button>

What is expected?
Buttons containing icon only should apply class ant-btn-icon-only as the blue button
What is actually happening?
Buttons containing icon only do NOT apply class ant-btn-icon-only as the red button

Environment
Info

ng-zorro-antd
9.0.0-beta.4

Browser
chrome:80

duplicated #4955


Clean up deployment process

Currently there are two deploy scripts deploy.sh and deploy-parallel.sh. deploy.sh is outdated - remove it and make sure it's not referenced in the workshop anywhere.
Currently there are two cleanup scripts cleanup.sh and cleanup-parallel.sh. There might be a justification for keeping the cleanup.sh for extreme circumstances using the EE deploy path and then trying to delete from cloudshell. In this situation the cleanup-parallel.sh runs out of disk space because of nodejs replication. Discuss and fix as appropriate.

For the EE, since I never had to deal with that before, can we use the CFN and delete stacks or run the offending stack cheanup.sh from inside that directory?


ContentPipeline

We could provide a GUI App which controls the ContentPipeline.exe so developers don't need to mess around with post build. This issue has very low priority because post build is not that hard to configure.

https://github.com/ThuCommix/Sharpex2D/commit/9f027615e1c40bed84b751ceb732869f09dcd3ca


API Conection Error (requestateam-kv)

Description
One of my API connections is showing an Error status.
The other 4 have the 'Authorize' button under 'Edit API connection' but requestateam-kv does not.
I tried using my service account credentials but did not work.
Steps to reproduce

Go into API Connections in Azure
Select 'requestateam-kv' and go to 'Edit API connection'
Error status is shown

Expected results
Show status of Connected
Actual Results
Status is shown as Error
Solution component
Deployment Script
Operating system (environment)
Windows
Additional Info

Solved by using correct package file script instead of one listed in deployment guide under step 1


Expose stop() as part of ExperimentClient protocol

Ehi,
Considering stop has been defined as public in DefaultExperimentClient, it should probably be exposed as part of the ExperimentClient protocol.

@peppesapienza Many thanks for raising this issue. stop() is now exposed in v1.13.6


Dice variables

dread it
run from it
dice variables are here
including a multitude of changes to the monad stack for dice rolling, parsing dice as a whole, if statements, and let statements (which allow storing of variables as well as lazy evaluation of variables to simulate functions)

This PR would end this issue finally: https://github.com/WarwickTabletop/tablebot/issues/66


feat: Exclude column checkbox

Description

This PR adds the feature to exclude columns on the tempålacolumn-review.html (both in 'grid-view' and 'table-view')

Grid overview
I HAVE BEEN PLAYING A BIT. IT COULD ALSO BE A CHECKBOX BELOW DESCRIPTION FIELD.
In the grid overview, it is displayed with a clickable bin-icon.

When excluded it will show like this (The action can be undone by clicking):

Table overview
In the table overview, I have just added a column to the table:

Related Issues
Closes #243
See also Issues #...
Testing

[X] Yes
[ ] No, not needed (give a reason below)
[ ] No, I need help writing them

Reviewer Focus

When excluding a column, the description field should not be required. This is handled with a bit of javascript and it is handled in the backend.
I add a overlay to a card when it is excluded. This also requires a bit of javascript.

Checklist

For all PRs that are not general documentation

[X] Tests accompany or reflect changes to the code
[X] Tests ran and passed locally
[X] Ran the linter and formatter
[X] Build has passed locally
[X] Relevant documentation has been updated

Maybe a warning on the one with the Bin, as once you click it is very much gone!

It is only gone, when you click the button "Update All". Until clicking "Update All", you can revert with the "undo"-button at the top.
But I can also add warning, if we want to be sure?

@philter87 I think the icon is enough, but we'll have to see during user testing (probably not achievable in this iteration)


Issue due date affected by time zone

Setting a issue due date send a full UTC date due_date: "2020-05-25T00:00:00.000Z" to the backend but depending on the user's time zone, the displayed date may not be 2020-05-25. We should probably convert the time to 00:00 in the user's current time zone and then send UTC for that.

I guess a better fix is to display the date as UTC (instead of local as right now) while continuing to store 00:00 UTC in the database.


feat: retry #900

disclaimer: did not test this, if anyone will to do

Thanks! Could you also add a change file and run pnpm build once (we need to commit the dist files)

@FabianLars good now?
keep wasting my time on these issue https://github.com/mediar-ai/screenpipe/actions/runs/12244105301/job/34155163076

@FabianLars done

Thanks! I'll merge this tomorrow morning.

i'm so close to rewriting the action in rust 🤣

please don't tell anyone i wasted hours on an attemps vs attempts typo 😂


Removes environment variables

It adds a safer way to run tests in Travis using an encrypted Sauce Labs access key. It was first requested in the Metal JS repository (https://github.com/metal/metal.js/issues/172).

LGTM


add README documentation

add yourself as an author please :smiley:

hahahah never considered myself one, but sure :+1:


Targets should have a field to indicate stable version of daplink

Targets should have a field to indicate stable version of daplink, for example daplink_version available here:
https://github.com/mbedmicro/mbed/blob/master/hal/targets.json
This would help mbedls tools to display a warning and ask the user to update the firmware (see request here https://github.com/ARMmbed/greentea/issues/148)

This should be managed by a database API where this information is stored, not the target description.


Home screen wallpaper doesn't change anymore

Describe the bug
Ever since updating to 5.0 and reconfiguring the home screen wallpaper doesn't change automatically anymore (or when triggered by the widget). Lockscreen works fine
To Reproduce
Use v5 and separate configurations for home and lock screen
Smartphone (please complete the following information):

Device: pixel 7a
OS: Android 15
Browser [e.g. stock browser, safari]
Version 5.0

@rigerc

I just checked, it's working fine.

I deleted storage & cache and set everything up again and it works now!


Add sample entity and samples.tsv file

Context and motivation
Hi BIDS community!
As part of the development of the Microscopy BEP (BEP031), we want to add a new sample entity to BIDS. This sample entity was introduced in order to distinguish different tissue samples from the same subject.
The sample entity may also be used by the Animal Ephys BEP (BEP032  @SylvainTakerkart) and could benefit other modalities as well.
This issue aims to start a discussion about the details of the sample entity between the 2 BEP groups and with the BIDS community. It will also facilitate the breaking down of BEPs in smaller modules by adding the sample entity as a separate PR.
Definition of the sample entity
To ensure compatibility with BIDS other modalities, the subject entity should correspond to the participant (e.g. a human, a mouse, etc). To identify multiple tissue samples from the same subject, we define the sample entity in BEP031 as:
A tissue sample, volume or slice pertaining to a subject.

It is positioned after the optional session entity in the filename:
sub-<label>[_ses-<label>]_sample-<label>_<modality_suffix>.<ext>

samples.tsv file
In BEP031, a samples.tsv file was added at the root of the dataset along with participants.tsv.
The samples.tsv file would have 2 required columns:

sample_id: corresponding to sample-<label> of the filename
participant_id: corresponding to sub-<label> of the filename

Another column sample_type was also suggested as required:

sample_type: kind of sample from ENCODE BiosampleType

We should also discuss if (and how) we want to encode an additional identifier when a sample is derived from another sample (e.g., a slice is derived from a block of tissue).
participants.tsv file
As part of the subject vs. sample definitions, we would also like to add 2 columns to the participants.tsv file:

species: string corresponding to the Binomial species name from NCBI Taxonomy, required when different from “Homo sapiens”
We think species should be in participants.tsv and not samples.tsv as it is an attribute of the subject and not the sample.

pathology: required when different from “Healthy”
In that case, pathology could be in either participants.tsv or samples.tsv as appropriate (e.g. healthy and non-healthy biopsy samples from the same subject).

Examples
File hierarchy and naming:
├── dataset_description.json
├── participants.json
├── participants.tsv
├── samples.json
├── samples.tsv
├── sub-rat1
│   └── microscopy
│       ├── sub-rat1_sample-data1_SEM.json
│       └── sub-rat1_sample-data1_SEM.png
├── sub-rat2
│   └── microscopy
│       ├── sub-rat2_sample-data5_SEM.json
│       └── sub-rat2_sample-data5_SEM.png
├── sub-rat3
│   └── microscopy
│       ├── sub-rat3_sample-data10_SEM.json
│       ├── sub-rat3_sample-data10_SEM.png
│       ├── sub-rat3_sample-data11_SEM.json
│       ├── sub-rat3_sample-data11_SEM.png
│       ├── sub-rat3_sample-data9_SEM.json
│       └── sub-rat3_sample-data9_SEM.png

participants.tsv:

participant_id
species

sub-rat1
Rattus norvegicus

sub-rat2
Rattus norvegicus

sub-rat3
Rattus norvegicus

samples.tsv:

sample_id
participant_id
sample_type

sample-data1
sub-rat1
tissue

sample-data5
sub-rat2
tissue

sample-data9
sub-rat3
tissue

sample-data10
sub-rat3
tissue

sample-data11
sub-rat3
tissue

thanks @mariehbourget for this ! we clearly need something of this type for BEP032 but havn't had a look at it precisely yet... we will take care of this in the next few weeks with @JuliaSprenger and others...

Species: :+1:
Pathology: This might not translate well to human subject populations, where I think "diagnosis" or similar would be considered more neutral. Is there a common term we can settle on that wouldn't be too awkward for either group, or will there need to be separate terms for animal tissues and human subjects?
Sample entity: As this is written, it seems to require that sample is unique throughout the dataset, so that if sample-1 exists in sub-01, there cannot be a sub-02_sample-1. This is an unusual requirement compared to existing entities. Could you elaborate on the motivation?

How does pathology/diagnosis overlap with phenotype?

regarding pathology, this should be annotated at the sample level in that one may have a tumor sample in one case versus on non-tumor location in the same participant. thus pathology goes with sample rather than participant. indeed for human and potentially other species there should be a Dx column for diagnosis. note that this could also vary by date and could therefore be in the sessions.tsv rather than participants.tsv. more generally there should be a conversation about inheritance of properties from participants to sample, when all samples share those properties.
also the same samples could be used in multiple sessions. hence having a mechanism to consolidate that would be necessary, and hence samples are similar to participants in that sense. in many cases, samples, rather than participants are often the primary entity in studies. and in keeping with bids it was discussed in the subgroups that a dataset should connect a sample to a participant even if the participant details are unknown.
btw, samples could also be used in human MR scans (e.g., left/right hemi ex vivo, brainstem, etc.,.), and hence samples should be considered at a generic concept in bids, rather than specialized just for microscopy/ephys.

Sample entity: As this is written, it seems to require that sample is unique throughout the dataset, so that if sample-1 exists in sub-01, there cannot be a sub-02_sample-1. This is an unusual requirement compared to existing entities. Could you elaborate on the motivation?

The intention is not to require "unique" sample_id across a dataset. We think people should be able to have the same sample_id for two different subjects as you are suggesting.  In samples.tsv, that would give something like this:

sample_id
participant_id
sample_type

sample-1
sub-1
tissue

sample-1
sub-2
tissue

sample-1
sub-3
tissue

sample-2
sub-3
tissue

sample-3
sub-3
tissue

So the "unique" identifier is the combination of sample_id and participant_id, and not sample_id alone.

So the "unique" identifier is the combination of sample_id and participant_id, and not sample_id alone.

this sounds ok to me! we should just give an example that is a bit more telling that just "sample-1", "sample-2" to be immediately understandable just by looking at it... question: what do experimenters use as user-friendly ids for their samples?

We should also discuss if (and how) we want to encode an additional identifier when a sample is derived from another sample (e.g., a slice is derived from a block of tissue).

we had discussion in our last BEP32 meeting about the possibility of adding several entities ('sample', but also 'slice' and 'tissue')... I don't want to deviate the goal of this thread, but maybe we should have this discussion globally here? I mean, asking ourselves how many entities should be added and which ones? or whether adding just the 'sample' entity and dealing with everything else through the 'sample_type' can cover all the targeted usecases? with this latter solution, indeed, the quoted question (i.e "how do we encode the fact that a slice is derived from a block of tissue") should be addressed!

small detail: although it is just an example / suggestion, the current specification mentions "group" as one of the column in participants.tsv, so if "pathology/diagnosis" finds its way in participants, this example might need to be amended or clarified otherwise this could lead to some confusion.

If sample labels can be reused across subjects, I think we can do the following:

Drop the participant_id column.
Follow the inheritance principle.

If the sample labels are the same across subjects, a global samples.tsv would provide the information needed. If they vary across subjects, then a set of sub-<label>/sub-<label>_samples.tsv files can be created.

regarding pathology, this should be annotated at the sample level in that one may have a tumor sample in one case versus on non-tumor location in the same participant.

I think @satra's suggestion here is good, and that making pathology a column in samples.tsv would make resolve the concerns I had above.

Indeed for human and potentially other species there should be a Dx column for diagnosis. note that this could also vary by date and could therefore be in the sessions.tsv rather than participants.tsv.

Yes, I think diagnosis as a session-level variable makes sense. As an aside, I don't think we have a principle that says how to do session-level variables for single-session studies that omit the ses-<label>/ directory, but that would be worth clarifying if we add variables that are useful in single-session contexts.

@SylvainTakerkart

we had discussion in our last BEP32 meeting about the possibility of adding several entities ('sample', but also 'slice' and 'tissue')...

We had similar discussions in BEP031 for other additional entities. The way we handled this so far is based on what entities are needed to distinguish between 2 different files of a same subject. For example, metadata like “sample_type” (primary cell, tissue, etc) is a unique attribute of the sample itself and would not change for a same subject_sample. In those cases, we think the information would be best encode in metadata and not in the filename.

how do we encode the fact that a slice is derived from a block of tissue

I would suggest adding a derived_from column in samples.tsv to cover this. Ex: sample-X from sub-1 is a block of tissue imaged. Then sample-X is sliced in slices named sample-x1, sample-x2, sample-x3 by the experimenter and imaged. The link between the samples could be in samples.tsv as:

sample_id
participant_id
sample_type
derived_from

sample-X
sub-1
tissue
n/a

sample-x1
sub-1
tissue
sample-X

sample-x2
sub-1
tissue
sample-X

sample-x3
sub-1
tissue
sample-X

@effigies

If sample labels can be reused across subjects, I think we can do the following:

Drop the participant_id column.
Follow the inheritance principle.

If the sample labels are the same across subjects, a global samples.tsv would provide the information needed.

I’m not sure to understand you on this.
Ex: 2 subjects (sub-1 and sub-2) have a sample named sample-1. However, the metadata of the sample-1 from sub-1 is not necessarily the same as for the sample-1 from sub-2. I don’t understand the utility of a global file without the participant_id column, as it would not make the distinction between the two.

@mariehbourget in the SPARC Dataset Structure we also include a "derived_from" (i.e. wasDerivedFromSample) in the samples metadata file: https://docs.google.com/presentation/d/1EQPn1FmANpPsFt3CguU-JOQVMMlJsNXluQAK_gb2qVg/edit#slide=id.p9

@mariehbourget

Ex: 2 subjects (sub-1 and sub-2) have a sample named sample-1. However, the metadata of the sample-1 from sub-1 is not necessarily the same as for the sample-1 from sub-2. I don’t understand the utility of a global file without the participant_id column, as it would not make the distinction between the two.

If the metadata for sample-1 is the same across subjects, it can be placed in a global file. If it differs, it can be placed in sub-1/sub-1_samples.tsv and sub-2/sub-02_samples.tsv.

I think it'd be great to hear from @tgbugs here... if we manage to handle all this consistently across BEP31, BEP32 and SPARC, that'd be fantastic to facilitate future inter-operability... (as was just said in the BEP31 meeting ;) )

From discussions at the meeting, I think the global samples.tsv might be compelling for this use case. My concerns are primarily aesthetic, preferring the file location to match the objects being described, but if doing it that way would require everybody to reconstruct the global table in software, it's not worth forcing.

Here is my write-up with an overview of the problem space, a potential model, and a review of the trade-offs that I see for BIDS based on my experience implementing and maintaining the SDS and its validation pipelines. I'm also dropping this in https://github.com/INCF/neuroscience-data-structure/issues/9.
https://github.com/SciCrunch/sparc-curation/blob/master/docs/participants.org
If you have targeted questions or comments you can leave them on this commit.
https://github.com/SciCrunch/sparc-curation/commit/c5968b94ca6de568f58acf146fce1f20140c7fcf

@effigies your concerns about forcing the reconstruction of the global table are well founded and I discuss the trade-offs in detail.

Thank you everyone for your comments, suggestions and feedback!
@tgbugs thank you very much for your insightful comment in https://github.com/SciCrunch/sparc-curation/blob/master/docs/participants.org. I am responding here so that the discussion stays centralized within a single issue thread (otherwise it is difficult to keep a clear track history of the discussion).
A few considerations following previous discussions and comments:

Regarding the subject entity: We are strongly in favor of keeping the current BIDS definition of subject i.e. a person or animal participating in the study. This is important to ensure compatibility between BIDS modalities (ex: a study with both microscopy and MRI where the subject must refer to the same organism)

Regarding “collective participants” such as “populations” or “pool”: This may go beyond the scope of this discussion. Moreover, based on our multiple meetings with the different groups who have given us feedback and exposed typical use case scenarios, this scenario currently falls in the 20% of the 80/20 BIDS principle. It seems reasonable to think that the label of the sub-<label> or sample-<label> could be used to describe this particular case (e.g. sub-pool01)

Regarding different “experimental group” (e.g. control and treatment): group is already mentioned as an example field for this purpose in participants.tsv in the current stable version of the BIDS standard (1.6.0).

Regarding the sample entity: Our proposition adds a single new entity sample to the file name to describe any sample_type (tissue, primary cell, etc). The sample_type is described in samples.tsv as it is an attribute of the sample and not necessary to distinguish between two files of the same sample. The advantage is to have a simple structure where each file has a unique identifier (e.g.: sub-1_sample-1). Because this prefix is in the file name, there would be no ambiguity between files if 2 subjects have the same sample numbers (e.g. sub-1_sample-1 and sub-2_sample-1).

Regarding file system: All files from the same subject remain in the sub-XX folder and not into additional nested folders. This structure avoids the added complexity and pitfalls of a nested folder structure mentioned by @tgbugs.

Regarding metadata files: The proposed solution with the sample entity requires only one additional file (samples.tsv) at the root of the dataset. The column participant_id is common to both participants.tsv and samples.tsv to join the tables. It seems reasonable to use two different files to distinguish between attributes of the subject and attributes of the sample.

In short, we suggest that:

Specific entity in filename should only be used when there is a need to distinguish two files from a same subject and sample (e.g. for microscopy: session, stain, chunk, run)
participants.tsv should be reserved for subjects’ attributes (e.g. age, sex, species, diagnosis)
samples.tsv should be reserved for samples attributes (e.g. sample_type, derived_from, pathology)

Hi @jcohenadad, thanks for taking a look. Here are my thoughts.

With respect to compatibility between modalities, the only thing
that matters in that case is the distinct identity of the participant,
not distinct identifier type.
The underlying conceptual types for the entities referred to by the
identifiers remains distinct (organismal subjects are not biological
samples). The type of the identifier in how it defines a namespace
for uniquely identifying distinct individuals is different from that
conceptual type. I am suggesting to extend the sub- identifier type
to be used to name anything in a BIDS dataset that has data about it.
This is consistent with how sub- is used in BIDS.
The underlying conceptual type of course must be retained, it couldn't
be otherwise, the key is to deconflate the conceptual type from the
identifier type. This means making the conceptual participant type
explicit in the schema rather than implicit in the identifier type.
As such, my suggestion does not prevent the ability to distinguish
metadata for participants subjected to different modalities, because
it is about the type of the identifier, not the identity of the
identifier. If I have sub-1 that was subjected to both microscopy and
MRI, then both have the same identifier because there was only one
participant that had measurements made on it. If there was a sample
derived from sub-1 that was subjected to microscopy then I would
simply call it sub-2. The identity of the organismal subject and the
sample subject are thus differentiated, without adding complexity to
the model by forcing them to have different identifier types.
I can understand the desire force the conceptual types (e.g. of
subject vs sample) onto the identifiers, but this doesn't actually buy
anything and only increases complexity, because sub- can already
distinguish sub-1 from sub-2 in the modality use case. Yes, we can
also distinguish sub-1 from sam-1, but why add that complexity?

The suggestion to use sub-pool01 will not work unless the meaning
of sub- is extended in the way I propose, because the metadata
requirements for pools cannot be enforced correctly unless there is a
way to distinguish between collective and atomic participants
independent of their identifier type prefix.
Even if this is a 20% use case, it is one that must be considered when
designing the 80% case because of the fundamental differences in what
can be required in the metadata of atomic vs collective entities.
If BIDS cannot distinguish between those cases, then it will become an
issue down the line, because there will be datasets e.g. in SPARC that
we will not be able to convert to BIDS in a way where we can correctly
enforce the structure of the metadata. For consortia looking to adopt
a standard that they can use across all datasets, this will cause BIDS
to continue to be unattractive.

Yep. That section was included for completeness and for other
audiences as BIDS already does this.

My suggestion is that rather than adding this complexity to only
samples, that it be added to all participants. Eventually it will be
needed for everything, and if it is only applied to samples then there
will be duplicated effort and duplicate schemas down the line.
Furthermore and more importantly, I strongly warn against allowing
sample identifiers to be reused across subjects. We just made a change
to prevent this in the SPARC data structure because of the numerous
implementation, usability, and ambiguity issues that it causes.
Sample IDs should at the very least be unique per dataset. Speaking
from experience, allowing non-unique sample ids that must be composed
with a subject identifier to for a primary key is a bad idea. I'm
happy to elaborate on the years of headaches that it has caused.

I should note that nesting files with sam-x in their name
encounters the exact same issue as nesting folders and thus the
problem remains.
In theory this could be mitigated to some extent by forcing users to
always include the subject id from which a sample was derived but as I
mention above, creating composite primary keys from subject sample
pairs is not a good idea. The problems that it causes down the line
are simply not worth the trade-off of being able to detect that a
sample file has been put in the wrong subject folder. Further, what
happens in cases with multiply derived samples? sub-1-sam-1-sam-1?
There are many other lurking issues here and I suggest avoiding them
entirely.

It is reasonable to use two different files to represent two
different schema. However, the problem is that there are going to be
more than two files in the future if the principle is "a new file for
every new schema and/or every new participant type."
Having a sparse tabular schema is also a reasonable way to solve this
problem, which is significantly more attractive because BIDS accepts
JSON as a metadata format, where the sparseness is not an issue. It
also has the benefit of only requiring the modification of the schema
to add a new set of fields for a new conceptual participant type,
rather than the addition of a whole new file. Some back of the napkin
math suggests that creating a new table per participant type will wind
up with BIDS eventually having well over a dozen different files one
for each of the participant types that I enumerate.
While adding additional files to avoid sparseness may seem reasonable
if there is only a single new table, it does not seem reasonable if
there will eventually be multiple new files and tables.
In a sense splitting samples.tsv into its own file is trying to solve
a user interface problem in the data model. I suggest that BIDS not
try to solve the user interface problem here and avoid multiplying
specialized metadata files.

With regard to the suggestions.

This is reasonable, with the note that I strongly discourage
allowing sample identifiers to be reused across subjects.
2 and 3 combined will lead to multiplication of specialized top
level metadata files over time. It would be better to have a sparse
schema that is only in participants.tsv.

Hi @tgbugs, thank you for the clarifications.
This discussion is touching on some of the core decisions made by the BIDS community. It would be great if some of the BIDS maintainers/steering could chip in as well @effigies @robertoostenveld.

I am suggesting to extend the sub- identifier type to be used to name anything in a BIDS dataset that has data about it. This is consistent with how sub- is used in BIDS.

If there was a sample derived from sub-1 that was subjected to microscopy then I would simply call it sub-2. The identity of the organismal subject and the sample subject are thus differentiated, without adding complexity to the model

We were advised by the BIDS steering group (@robertoostenveld) to not extend the definition of the subject entity. In that regard, the subject definition of "a person or animal participating in the study" seems important to the BIDS community to preserve consistency across modalities.
We’ve tried different configurations in the early development of the microscopy  BEP and we agree that adding many different entities to describe different use cases adds undue complexity to the model. Therefore, we proposed the sample entity which would be used for the different specimen types you mentioned. Our idea is not to add an entity to every possible case but to use sample as the entity for different sample_type such as “whole organ”, “tissue”, “cells”, etc.
The advantages are that it retains the definition of subject without adding multiple layers of complexity to the scheme, and covers all atomic participant types.

The suggestion to use sub-pool01 will not work unless the meaning of sub- is extended in the way I propose, because the metadata requirements for pools cannot be enforced correctly unless there is a way to distinguish between collective and atomic participants independent of their identifier type prefix. Even if this is a 20% use case, it is one that must be considered when designing the 80% case because of the fundamental differences in what can be required in the metadata of atomic vs collective entities.

As far as we know, the current BIDS specification does not cover explicitly “collective” participants, hence the suggestion to name the subject with the pool name in the absence of standardization. Again, it may be out of scope for the current issue. With that being said, I will let the BIDS community chip in if there are plans for that in the future.

I strongly warn against allowing sample identifiers to be reused across subjects. We just made a change to prevent this in the SPARC data structure because of the numerous implementation, usability, and ambiguity issues that it causes. Sample IDs should at the very least be unique per dataset.

I should note that nesting files with sam-x in their name encounters the exact same issue as nesting folders and thus the problem remains. In theory this could be mitigated to some extent by forcing users to always include the subject id from which a sample was derived but as I mention above, creating composite primary keys from subject sample pairs is not a good idea. The problems that it causes down the line are simply not worth the trade-off of being able to detect that a sample file has been put in the wrong subject folder.

We understand your concerns in cases where the subject from whom the sample is derived from would not be explicit. In this BEP, the derivation of a sample from a subject is enforced in the filename itself. An individual file will always have both the subject_id and the sample_id within its name. So the composite key of sub-sample is not only present in metadata but it corresponds directly to a unique filename (nested or not, misplaced or not).
From an experimental point of view, it also makes sense for people to name their samples the way they want for the same subject without having to take into account sample_id from previous acquisitions on other subjects. In addition, it is usual in BIDS to deal with the same key-value pair across a dataset with other entities such as session. Enforcing a unique sample_id would be an unusual requirement. Again, I would appreciate it if someone from the core BIDS could chip in (@effigies), as I am uncomfortable speaking as a porte parole for BIDS strategic decisions.

Further, what happens in cases with multiply derived samples? sub-1-sam-1-sam-1?

This was addressed earlier in the thread where we suggested to add a derived_from column in the samples.tsv file. There is always only one instance of sample-<label> in the filename.

It is reasonable to use two different files to represent two different schema. However, the problem is that there are going to be more than two files in the future if the principle is "a new file for every new schema and/or every new participant type." [...] Some back of the napkin math suggests that creating a new table per participant type will wind up with BIDS eventually having well over a dozen different files one for each of the participant types that I enumerate.

As mentioned earlier, the addition of the sample entity and samples.tsv file would already cover new participants type (at least “atomic”), so we are not worried about dozens of files being added in the future.

Hi @jcohenadad, I'll leave some thoughts while awaiting for responses from others. Since the discussion has strayed into cross BEP and core BIDS territory, this is understandable.

to not extend the definition of the subject entity

Absolutely. However, I wonder if that suggestion was made in a context where identifier type and conceptual type were conflated. Retaining the definition of subject while extending the scope of sub- should be possible by adding (initially) a separate definition for sample and a subject type or participant type column to participants.tsv. This is a unifying and regularizing generalization of the rather awkward sample type (I say this also having the same awkward sample type in the SDS schema that I maintain).

From an experimental point of view, it also makes sense for people to name their samples the way they want for the same subject without having to take into account sample_id from previous acquisitions on other subjects

However, from a data sharing point of view, they probably should be taken that into account. There are countless sample-1s in the world, and having to carry around a composite primary key of dataset-id, subject-id, and sample-id without any way to reduce them to a single unique identifier for the individual participant seems like it will induce complexity on any implementations of BIDS in the future. Furthermore it complications communication about samples because unique sample ids cannot be generated without the subject id to qualify them unless all communicating parties agree on the convention for converting composite primary keys into unique ids.
Relevant to a later point, the generalization of this reasoning is that participant-1-participant-1-participant-1-participant-1 should be allowed as an identifier because each prior participant is distinct and it should be up to the experimenter how to identify their participants. Part of the current BEP tries to deal with this by forcing sample ids to be unique if they were derived from another sample, however the isDerivedFrom relationship applies with domain and range subject and sample in addition to sample and sample, so the lack of enforcement of unique identifiers for samples derived from subjects is inconsistent with respect to the isDerivedFrom relationship.

Enforcing a unique sample_id would be an unusual requirement.

But according to the proposal this in fact already required for samples derived from other samples.

This was addressed earlier in the thread where we suggested to add a derived_from column in the samples.tsv file. There is always only one instance of sample-<label> in the filename.

There are many cases where samples and not subjects are shipped from one lab to another and then from the shipped samples further samples are derived. That is to say, there are labs for which someone else's sample is their subject.
If we were to apply the logic articulated above for subjects, the experimentalists should likewise not have to care about the fact they derived one sample from another, so long as they keep track of which sample they derived it from and thus that sub-1-sam-1-sam-1 should be allowed (re: infinitely nested participant-1).
Requiring different practices for identifier generation due to an arbitrary distinction between subject and sample (is a cadaver a sample?) seems like a design flaw. The restriction that only sample ids must be unique and enforcing that only on derived samples but not on samples derived directly from subjects* would significantly complicate the underlying data model and ontology.
* This isn't actually the requirement, it is more that all transitively derived samples from the same subject have to have unique identifiers. This gets extremely messy if you start deriving samples from populations of subjects because now the samples probably have to be uniquely identified up to the population not the subject, so the generalization of the uniqueness would require further specification (and thus complexity) in the future to correctly deal with such cases.

it might be worth splitting this issue into two (or three)

addition of _sample-<label> entity (IMHO quite straightforward)
ability to re-order levels of iteration (much larger issue, but could be made backward compatible so IMHO no need to wait for 2.x)
(providing the entity(ies) summary file(s) such as participants.tsv (aka subjects), scans.tsv, samples.tsv etc -- also could be backward compatible)

The last two relate also to "stimuli BEP" wannabe issue (see e.g. https://github.com/bids-standard/bids-specification/issues/751#issuecomment-820800800 I also generalize "similarly") and IMHO orthogonal issues to the first one ("samples" entity) and interrelated within since with reordering you would get top level ".tsv/.json".
As for the last one -- we could gain ".tsv/.json" even without any reordering: at large we already have it someone implied by inheritance principle and hence could have scans.json (#789) and even sessions.tsv/.json at top level could be useful (e.g. to provide characteristics for e.g. "preoperative", "postoperative" sessions etc) independent of top "iteration" level (currently fixed to sub).

@robertoostenveld thank you very much.
I think that BIDS 2.X is probably the right venue for my suggestions. Given the constraints on 1.X. In that context I only have one suggestion for this thread, which is to require that sample identifiers be unique per dataset not per subject.

why would you not extend the meaning of session, or scan, or run instead?

The only reason would be if there was a required metadata structure that was associated with some experimental process that could not be capture at one of those levels, or if there were more levels that were required. Otherwise the only reason would be because someone doesn't like the naming of the three levels.
In SPARC we have called the abstraction of those three into a single term performance or protocol execution variously. It corresponds to the performance of a protocol aka the carrying out of some experimental process. The distinction between session, scan, and run have to do with the particular nesting of repeated structure that is common to many MRI experiments, and which is shared with a variety of other modalities beyond MRI.
For the most part these don't need to be extended because they are distinct only in how they are named and in that they support 3 levels of repeated structure. There might be some experimental designs that need slightly more expressivity, or that might need/want to associate slightly different metadata with a particular repeated process, in which case the abstracted solution might help.
@yarikoptic I think the 3 can be broken up as you suggest, with a note that there is an interaction between _sample-<label> and participants.tsv depending on what uniqueness constraints are required.

I'm also in favor of addressing these issues step by step, this would fit the needs of development of BEP32 (which are strongly overlapping with the ones of BEP31, if not strictly identical)! and the first step (addition of the sample entity) will already allow us to move forward!
what's the next step?

I would think a PR for "addition of _sample- entity" with the opening of this PR.  Point to this issue for further info on discussion etc.
I would also file a separate issue (or better even a PR) suggesting additional (RECOMMEND) columns to participants.tsv/.json .

Thank you everyone for your feedback!
As suggested by @yarikoptic and as discussed in today’s BEP031 meeting, we will move forward with separate PRs, starting with the “Addition of sample entity”.

Hi everyone! The first PR (#812) for the addition of the sample entity is now open.

Closing this since #816 is now merged


Request for a Transaction example in the Cloud Firestore README

Hi! Can we add an example of transactions to https://pub.dartlang.org/packages/cloud_firestore ?
Here would be good: https://github.com/flutter/plugins/tree/master/packages/cloud_firestore
Thanks!

cc @collinjackson

@sethladd any luck on finding an example of how to perform a simple transaction?

can anyone tell me if this is the proper way to perform a transaction?  I'm getting this error "PlatformException(Error performing Transaction#get, Transaction has already completed., null)"
Firestore.instance.runTransaction((Transaction tran){         tran.get(postRef).then((DocumentSnapshot snap){           if(snap.exists)           tran.update(postRef, <String,dynamic>{"likesCount": snap.data['likesCount']+1});           else             print('nah son');         });       });

Hi @dac3971 you would need to pass in a TransactionHandler to runTransaction. Eg:
final TransactionHandler transactionHandler = (Transaction tran) {
  tran.get(postRef).then((DocumentSnapshot snap) {
    if (snap.exists) {
      tran.update(postRef, <String, dynamic>{'likesCount': snap.data['likesCount'] + 1});
    }
  });
};
Firestore.instance.runTransaction(transactionHandler);

@kroikie hmm ..wouldn't that essentially be the same thing?  i'm still getting a "task is already complete" error...

Ah you are right @dac3971 let me look deeper.

@dac3971 are you seeing this issue on Android/iOS or both?

@kroikie Android.

@kroikie is this working for you yet? i'm now getting a different error:
 E/AndroidRuntime(14446): Caused by: java.lang.IllegalArgumentException: Provided document reference is from a different Firestore instance.

See also the related SO question https://stackoverflow.com/questions/50280256/flutter-cloud-firestore-plugin-transactions-on-android

@dac3971 I'd suggest to create a new issue for this error message

any updates on this?

I am still confused about what's the best way to know if the transaction was successful?

The issue was closed by @collinjackson but I can't see any solution yet. Am I missing something?

So after banging my head on the wall, i decided to update my flutter and its fine now.

Future _updateFavorite() async {
Firestore.instance.runTransaction((Transaction transaction) async {
await messages.where("location", isEqualTo: _location).snapshots().listen(
(data) => data.documents.forEach((doc) async =>
await transaction.update(doc.reference, {"isFavorited": false})));
});
setState(() {
_isfavorite = !_isfavorite;
});
print("Updated fav => $_isfavorite");
}
Error:
Caused by: java.lang.IllegalArgumentException: Provided document reference is from a different Firestore instance.
E/AndroidRuntime(16311): 	at com.google.firebase.firestore.FirebaseFirestore.zza(com.google.firebase:firebase-firestore@@17.1.1:384)
E/AndroidRuntime(16311): 	at com.google.firebase.firestore.Transaction.zza(com.google.firebase:firebase-firestore@@17.1.1:203)
E/AndroidRuntime(16311): 	at com.google.firebase.firestore.Transaction.update(com.google.firebase:firebase-firestore@@17.1.1:145)
E/AndroidRuntime(16311): 	at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:360)
E/AndroidRuntime(16311): 	at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:354)
E/AndroidRuntime(16311): 	at android.os.AsyncTask$2.call(AsyncTask.java:333)
E/AndroidRuntime(16311): 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
E/AndroidRuntime(16311): 	... 4 more
I/Process (16311): Sending signal. PID: 16311 SIG: 9
Application finished.
Ok so the fix isnt available yet, and is anyone solved above exception??????

@DeepStyles  your error doesn't prove any bug, it is better suited to ask this question on Stackoverflow.

@DeepStyles Did you solve that problem?

Transaction has already completed.
Im also getting this issue. The firestore plugin is really buggy to be honest.

I was also getting the same issue. I changed document reference from
var chatRef = _firestore.collection(TABLE_SITES).document(siteId).collection(TABLE_CHATS).document(chatId); to var chatRef = _firestore.document('$TABLE_SITES/$siteId/$TABLE_CHATS/$chatId'); and the problem is fixed.
Dependencies versions:
firebase_core: ^0.4.0+6
firebase_auth: 0.11.1+7
cloud_firestore: 0.12.5+2
firebase_storage: ^3.0.2
firebase_messaging: ^5.0.4
firebase_crashlytics: ^0.0.4+8

Future _updateFavorite() async {
    Firestore.instance.runTransaction((Transaction transaction) async {
      await messages.where("location", isEqualTo: _location).snapshots().listen(
          (data) => data.documents.forEach((doc) async =>
              await transaction.update(doc.reference, {"isFavorited": false})));
    });
    setState(() {
      _isfavorite = !_isfavorite;
    });
    print("Updated fav => $_isfavorite");
  }

Error:
Caused by: java.lang.IllegalArgumentException: Provided document reference is from a different Firestore instance.
E/AndroidRuntime(16311): 	at com.google.firebase.firestore.FirebaseFirestore.zza(com.google.firebase:firebase-firestore@@17.1.1:384)
E/AndroidRuntime(16311): 	at com.google.firebase.firestore.Transaction.zza(com.google.firebase:firebase-firestore@@17.1.1:203)
E/AndroidRuntime(16311): 	at com.google.firebase.firestore.Transaction.update(com.google.firebase:firebase-firestore@@17.1.1:145)
E/AndroidRuntime(16311): 	at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:360)
E/AndroidRuntime(16311): 	at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:354)
E/AndroidRuntime(16311): 	at android.os.AsyncTask$2.call(AsyncTask.java:333)
E/AndroidRuntime(16311): 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
E/AndroidRuntime(16311): 	... 4 more
I/Process (16311): Sending signal. PID: 16311 SIG: 9
Application finished.

Ok so the fix isnt available yet, and is anyone solved above exception??????

I found the cause of this issue. My app is working fine and transaction is running successfully on fresh install. It is happening only when I hot reload/restart app.
Can you please check and confirm if same is happening with you?

@DeepStyles your error doesn't prove any bug, it is better suited to ask this question on Stackoverflow.

I'm sure this is a bug. This is only happening when we reload/restart app.

@sethladd
This issue has been moved to https://github.com/FirebaseExtended/flutterfire/issues/904. Any further collaboration will be done there.


Memes!!

Hey folks,
A lot of memes related to bhailang are being shared online. If you are creating one, please share in this issue.
Les.. go! BhaiLang to the moon 🚀

Credit: [@getumank](https://twitter.com/getumank)

Credit: @Naimish860

Credit: @Nikhil_Mahana

For errors

When you take bro code a tab bit seriously

printf -> screen pe likh bhai
fprintf -> file main likh bhai

function() : JS
kaam() : bhailang

Bhailang mein memory ki safai automatic hoti hai ki khud jaadu marrna padta hai?

Is the intellisense called "aaj gadi tera bhai chalega"?

Me after using bhailang

for error : YE TU KAUN SA KAND KAR KE AYA HAI
for exeption : KYU DIMAG KA DAHI KAR RAHA HAI

meanwhile girls :

while developing features for bhai-lang, even the copilot understands bhai-lang

Bhai logo does any one know how to ask a question from the user in bhailang

for debug logging "Bhai log ye" 😂

On login page for promising users with lot of free features:
https://pbs.twimg.com/media/Eb1023UUYAEAk-e?format=jpg&name=large

On login page for registration of new users for lots of free features :

World:
We have Python.
We have Anaconda.
We have Spider.
Meanwhile Indians:
Humare paass humara "Bhai" he.

I think soon we will have framework based on bhailang called MunnaBhai
Meanwhile error meme
For missing mandatory parameters

For storage/memory issue

O bete moj kardi meme

Meanwhile Microsoft compiling windows 11 with bhailang:
Aati Chota Mulayum Khidkiya Bhai!

When Server Crashes,
le  Server Written in Bhai Lang : Bhaiiiiiii Lo*e lag gye!!!

Syntax error : keha Kya chahte hai bhai


UnnamedParameterUse should not be reported for java functions

Expected Behavior
notifyItemRangeChanged(0, currentList.size) should not report any warning
Observed Behavior
notifyItemRangeChanged(0, currentList.size) is reporting warning
Though using the intention from idea Add names to call arguments is converting the fun to notifyItemRangeChanged(/* positionStart = */ 0, /* itemCount = */ currentList.size)
Steps to Reproduce
Happening in latest dev

There is already a TC for checking non Kotlin fun at https://github.com/detekt/detekt/blob/d4db424082b6b1b35ac6fb28990acfbf6616e602/detekt-rules-errorprone/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/bugs/UnnamedParameterUseSpec.kt#L208
not sure what is getting missed

Can you try with debug enabled to see if there are compiler errors?
Can you share a build scan?
Which Gradle task are you executing?

Can you try with debug enabled to see if there are compiler errors?

Ran ./gradlew :app:detektStageDebug --debug > logs.txt and attaching the logs.txt here(I don't think any error happened as suppressing is working fine)
logs.txt

Can you share a build scan?
https://scans.gradle.com/s/2p7w6aj6uvtca

Which Gradle task are you executing?
Detekt with TR /gradlew :app:detektStageDebug

Thanks for the build scan.
This indicates there are issues with the task setup: https://scans.gradle.com/s/2p7w6aj6uvtca/console-log/task/:app:detektStageDebug?page=1#L14-L85
Are you using latest snapshot of the detekt Gradle plugin? If yes, and the task was registered by detekt Gradle plugin and not configured manually by you, then it should autoconfigure correctly. I would need to see the build scripts to troubleshoot further.

My libs.version.toml is as follow
gradlePlugins-detekt = "main-SNAPSHOT"

[libraries]
detekt-ktlint = { module = "io.gitlab.arturbosch.detekt:detekt-formatting", version.ref = "gradlePlugins-detekt" }

[plugins]
# linter or formatter
detekt = { id = "io.gitlab.arturbosch.detekt", version.ref = "gradlePlugins-detekt" }

My app level build.gradle.kts is as follow
plugins {
    id("android-application")
    kotlin("kapt")
    id("org.jetbrains.kotlin.plugin.parcelize")
    id("com.google.gms.google-services")
    id("androidx.navigation.safeargs.kotlin")
    id("kotlinx-serialization")
    alias(libs.plugins.detekt)
}

detekt {
    // If set to `true` the build does not fail when the
    // maxIssues count was reached. Defaults to `false`.
    ignoreFailures = false
    // point to your custom config defining rules to run, overwriting default behavior
    config.setFrom(files("$rootDir/AceLibs/config/detekt/detekt.yml"))
    baseline =
        file("$projectDir/config/baseline.xml") // a way of suppressing issues before introducing detekt
    // Specify the base path for file paths in the formatted reports.
    // If not set, all file paths reported will be absolute file path.
    basePath.set(projectDir)
    // Adds debug output during task execution. `false` by default.
    debug = true
    parallel = true
    buildUponDefaultConfig = true
    autoCorrect = true
    enableCompilerPlugin = true
}

tasks {
    withType<io.gitlab.arturbosch.detekt.Detekt>().configureEach {
        jvmTarget = "1.8"
        reports {
            // observe findings in your browser with structure and code snippets
            html.required.set(true)
            // similar to the console output, contains issue signature to manually edit baseline files
            txt.required.set(false)
            sarif.required.set(false)
            xml.required.set(false)
        }
        exclude { it.file.path.contains("build") }
    }
}

I might need a complete reproducer to look into it further... nothing sticks out at the moment. You could try not excluding the build folder too - perhaps the source that's required for the rule to work properly is missing thanks to that exclusion?

@3flex do we have an issue to track that limitation? Maybe we should just remove the exclude from the client side and allow to define exclusions at the root of our config.yaml. This way we use all the information that we can get from the code but we don't raise any issue on those files.

It shouldn't affect analysis because all required compiled classes should be on the analysis classpath already even if some files are excluded from analysis. There's not enough information to know what exactly is going on.

You could try not excluding the build folder too - perhaps the source that's required for the rule to work properly is missing thanks to that exclusion?

Hi @3flex I tried removing the exclude { it.file.path.contains("build") } but the notifyItemRangeChanged(0, currentList.size) still present(since build is now not excluded all the errors in generated files in build also starts getting reported)
I will try to create the reproducer

This issue is waiting for authors feedback since 30 days. Please comment providing the requested feedback or this issue will be closed in 7 days.

This issue is waiting for authors feedback since 30 days. Please comment providing the requested feedback or this issue will be closed in 7 days.

This issue was closed because it has been stalled for 7 days with no activity.


Change positional args manifest and key to optional args

Signed-off-by: Sankaranarayanan Venkatasubramanian<EMAIL_ADDRESS>
Description of the changes
This PR changes the positional arguments manifest and key that gsc build and gsc sign-image commands take respectively to optional ones. This change is being done separately now to accommodate change for production signing #112 (to avoid introducing the breaking change for key as optional argument)

How to test this PR?
docker pull python
./gsc build -L --manifest test/generic.manifest python
./gsc sign-image -k enclave-key.pem python

and run the resulting gsc-python image.

This change is

@woju @mkow Could you review? This is a breaking change, but needed one - without which we aren't able to do production signing. So, we are making all arguments except IMAGE as optional.


Add testdata for differentialabundance pipeline

This PR adds some test files for the WIP differentialabundance pipeline

Hey @ggabernet , I understood that on the nf-core:differentialabundance branch I only need the testdata that are actually for the differentialabundance pipeline? The deleted data are files from some other project


Android ReferenceError: Property '__scanFaces' doesn't exist, js engine: hermes

Hi, trying out your lib. and getting the above error. __scanFaces is not found in global scope.
Several errors pop up:
ReferenceError: Property '__scanFaces' doesn't exist, js engine: hermes
Error: Requiring module "node_modules/vision-camera-face-detector/src/index.ts", which threw an exception: ReferenceError: Property '__scanFaces' doesn't exist, js engine: hermes
Env:
"react": "17.0.2",
"react-native": "0.66.0",
"react-native-vision-camera": "^2.9.3",
"vision-camera-face-detector": "^0.1.8",
"react-native-reanimated": "^2.3.0-beta.2",
// hermes: true

Tested on 2 real devices.

Did you set babel plugin correctly? see guide but you have to add __scanFaces.

closing due inactivity

@iAmGhost I tried the same guide but still getting "Property '_scanFaces' doesn't exist" issue. Can anyone please help me into this?

__scanFaces

Facing same issue

try using this in package.json
"vision-camera-face-detector": "rodgomesc/vision-camera-face-detector#master"

then run yarn install or npm install again
references BenHurMartins/react-native-face-detection/package.json

I am also facing the same issue
babel.config :

My import

error on metro

try using this in package.json
"vision-camera-face-detector": "rodgomesc/vision-camera-face-detector#master"

then run yarn install or npm install again
references BenHurMartins/react-native-face-detection/package.json

I tried like you have quoted :
package,json file:

I got this error :
none of the files were detected:

Same issue, any idea? Already added __scanFaces to babel file

I don't have time for investigating but here's some suggestions:

Check other Frame Processor Plugins are working, to see if it's plugin issue or react-native-vision camera itself.
There's an issue that reports app crashes in release mode, it can be problem is not related with babel.
https://github.com/mrousavy/react-native-vision-camera/issues/954
See Android native side log if plugin is registered.
(from issue above: Also, please share the initial logs that are logged by VisionCamera to Logcat on app-start, it says "Registering Plugins" or something like that.)
Reproduceable minimal repository will be helpful.

'import 'react-native-reanimated';'....on top of your index file.

try using this in package.json
"vision-camera-face-detector": "rodgomesc/vision-camera-face-detector#master"

then run yarn install or npm install again
references BenHurMartins/react-native-face-detection/package.json

this worked for me
I was try to add the reanimated import in my index.js file (didnt work), I could delete that line after installing from github repo


Publish 09/02/2022 3:30 PM PT

Docs Build status updates of commit 56b959c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Set-OwaMailboxPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Efficient computation of intersection and volume.

Once we have minus_Z and a parameterization that stores minuz_Z instead of Z directly, we can use z and minus_Z to compute intersection and volume.

class PureGumbelBox(Module):
    """
    Box embedding model optimized for performance.

    In this model, the self.boxes parameter is of shape (num_entity, 2, dim), where self.boxes[i,:,k] are location
    parameters for Gumbel distributions representing the corners of the ith box in the kth dimension.
        self.boxes[i,0,k] is the location parameter mu_z for a MaxGumbel distribution
        self.boxes[i,1,k] represents -mu_Z, i.e. negation of location parameter, for a MinGumbel distribution
    This rather odd convention is chosen to maximize performance.

    Note that with this parameterization, we allow the location parameter to "flip around", i.e. mu_z > mu_Z.
    This is completely reasonable, from the GumbelBox perspective.
    """

    def __init__(
        self,
        num_entity,
        dim,
        volume_temp=1.0,
        intersection_temp=1.0,
    ):
        super().__init__()
        self.boxes = Parameter(
            torch.sort(
                torch.randn((num_entity, 2, dim)), dim=-2, descending=True
            ).values
        )

        self.volume_temp = volume_temp
        self.intersection_temp = intersection_temp
        self.softplus = torch.nn.Softplus(beta=1 / self.volume_temp)
        self.softplus_const = 2 * self.intersection_temp * 0.57721566490153286060

    def forward(self, idxs: LongTensor) -> Tensor:
        """
        A version of the forward pass that is slightly more performant.
        :param idxs: Tensor of shape (..., 2) indicating edges, i.e. [...,0] -> [..., 1] is an edge
        :return:
        """
        boxes = self.boxes[idxs]
        # we now have boxes in a shape (..., nodeA/nodeB, min/max, embedding_dim)

        # calculate Gumbel intersection
        intersection = self.intersection_temp * torch.logsumexp(
            boxes / self.intersection_temp, dim=-3, keepdim=True
        )
        intersection = torch.max(
            torch.cat((intersection, boxes), dim=-3), dim=-3
        ).values
        # calculating log volumes
        # keep in mind that the [...,1,:] represents negative max, thus we negate it
        log_intersection_volume = torch.sum(
            torch.log(
                self.softplus(-intersection.sum(dim=-2) - self.softplus_const) + 1e-23
            ),
            dim=-1,
        )

        return log_intersection_volume

Setup two scripts, one which uses the above "efficient" computation and one which uses a similar computation but treats the parameters as mu_z and mu_Z, which will require negating and stacking the mu_Z parameter (like we currently do).
Profile these scripts (eg. using timeit)
If treating the parameters as though they are mu_z and -mu_Z is faster, we should consider making this the new base class.

class PureGumbelBoxNormal(Module):
    """
    Box embedding model.

    In this model, the self.boxes parameter is of shape (num_entity, 2, dim), where self.boxes[i,:,k] are location
    parameters for Gumbel distributions representing the corners of the ith box in the kth dimension.
        self.boxes[i,0,k] is the location parameter mu_z for a MaxGumbel distribution
        self.boxes[i,1,k] is the location parameter mu_z for a MaxGumbel distribution

    Note that with this parameterization, we allow the location parameter to "flip around", i.e. mu_z > mu_Z.
    This is completely reasonable, from the GumbelBox perspective.
    """

    def __init__(
        self,
        num_entity,
        dim,
        volume_temp=1.0,
        intersection_temp=1.0,
    ):
        super().__init__()
        self.boxes = Parameter(
            torch.sort(
                torch.randn((num_entity, 2, dim)), dim=-2, descending=True
            ).values
        )

        self.volume_temp = volume_temp
        self.intersection_temp = intersection_temp
        self.softplus = torch.nn.Softplus(beta=1 / self.volume_temp)
        self.softplus_const = 2 * self.intersection_temp * 0.57721566490153286060

    def forward(self, idxs: LongTensor) -> Tensor:
        """
        A version of the forward pass that is slightly more performant.
        :param idxs: Tensor of shape (..., 2) indicating edges, i.e. [...,0] -> [..., 1] is an edge
        :return:
        """
        boxes = self.boxes[idxs]
        # we now have boxes in a shape (..., nodeA/nodeB, min/max, embedding_dim)

        # calculate Gumbel intersection
        intersection_min = self.intersection_temp * torch.logsumexp(
            boxes[...,0,:] / self.intersection_temp, dim=-3, keepdim=True
        )
        intersection_min = torch.max(intersection_min, boxes[...,0,:])
        intersection_max = -self.intersection_temp * torch.logsumexp(
            -boxes[...,1,:] / self.intersection_temp, dim=-3, keepdim=True
        )
        intersection_max = torch.min(intersection_max, boxes[...,1,:])
        # calculating log volumes
        # keep in mind that the [...,1,:] represents negative max, thus we negate it
        log_intersection_volume = torch.sum(
            torch.log(
                self.softplus(intersection_max-intersection_min - self.softplus_const) + 1e-23
            ),
            dim=-1,
        )

        return log_intersection_volume

Suggested changes:

in the _compute functions, stack z and -Z, run a single logaddexp, and then (for the clipping functions) do torch.max, finally return lse[...,0,:] and -lse[...,1,:]
gumbel _intersection should be returning a base box
(optional) for the clipping with different forward / backward pass, we should probably implement this by subclassing Function as opposed to using the .detach trick.

PureGumbleBox (Stacking both z and Z in one tensor)
CPU:
54 s ± 467 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
	Line #    Mem usage    Increment  Occurences   Line Contents
	============================================================
	   123    125.8 MiB    125.8 MiB           1   @profile
	   124                                         def train(gumble, optimizer: optim.SGD, idx, n_epoch=10000):
	   125    140.1 MiB      0.0 MiB       10001       for epoch in range(n_epoch):
	   126    140.1 MiB      0.0 MiB       10000           optimizer.zero_grad()
	   127    140.1 MiB      6.0 MiB       10000           loss = -gumble(idx)
	   128    140.1 MiB      4.4 MiB       10000           loss.backward()
	   129    140.1 MiB      3.9 MiB       10000           optimizer.step()

GPU:
	23.8 s ± 1.14 s per loop (mean ± std. dev. of 7 runs, 1 loop each)

	Line #    Mem usage    Increment  Occurences   Line Contents
	============================================================
	   123   2002.2 MiB   2002.2 MiB           1   @profile
	   124                                         def train(gumble: PureGumbelBox, optimizer: optim.SGD, idx, n_epoch=10000):
	   125   2002.2 MiB      0.0 MiB       10001       for epoch in range(n_epoch):
	   126   2002.2 MiB      0.0 MiB       10000           optimizer.zero_grad()
	   127   2002.2 MiB      0.0 MiB       10000           loss = -gumble(idx)
	   128   2002.2 MiB      0.0 MiB       10000           loss.backward()
	   129   2002.2 MiB      0.0 MiB       10000           optimizer.step()

PureGumbelBoxNormal (not stacking):
CPU:
	52.6 s ± 521 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

	Line #    Mem usage    Increment  Occurences   Line Contents
	============================================================
	   123    118.3 MiB    118.3 MiB           1   @profile
	   124                                         def train(gumble, optimizer: optim.SGD, idx, n_epoch=10000):
	   125    137.6 MiB      0.0 MiB       10001       for epoch in range(n_epoch):
	   126    137.6 MiB      0.0 MiB       10000           optimizer.zero_grad()
	   127    137.6 MiB      3.3 MiB       10000           loss = -gumble(idx)
	   128    137.6 MiB      8.2 MiB       10000           loss.backward()
	   129    137.6 MiB      7.7 MiB       10000           optimizer.step()

GPU:
	28.1 s ± 1.38 s per loop (mean ± std. dev. of 7 runs, 1 loop each)

	Line #    Mem usage    Increment  Occurences   Line Contents
	============================================================
	   123   2002.2 MiB   2002.2 MiB           1   @profile
	   124                                         def train(gumble: PureGumbelBox, optimizer: optim.SGD, idx, n_epoch=10000):
	   125   2002.2 MiB      0.0 MiB       10001       for epoch in range(n_epoch):
	   126   2002.2 MiB      0.0 MiB       10000           optimizer.zero_grad()
	   127   2002.2 MiB      0.0 MiB       10000           loss = -gumble(idx)
	   128   2002.2 MiB      0.0 MiB       10000           loss.backward()
	   129   2002.2 MiB      0.0 MiB       10000           optimizer.step()


Add safety net when running sections with null inputs

Is your feature request related to a problem? Please describe.
When running a section, say, with 2 inputs and you provide a null input as the first one, an AIIOB will be thrown when it tries to set the (second?) variable.
Describe the solution you'd like
No exception should be thrown, the variable should stay unset.
Describe alternatives you've considered
This should be a simple check in Section#run()
Additional context
Provided stacktrace from user:
[19:42:44 WARN]: [skript-reflect] Plugin skript-reflect v2.4 generated an exception while executing task 32
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
        at ch.njol.skript.lang.Variable.change(Variable.java:550) ~[Skript.jar:?]
        at com.btk5h.skriptmirror.skript.reflect.sections.Section.run(Section.java:35) ~[skript-reflect.jar:?]
        at com.btk5h.skriptmirror.skript.reflect.sections.EffRunSection.lambda$walk$2(EffRunSection.java:95) ~[skript-reflect.jar:?]
        at org.bukkit.craftbukkit.v1_20_R3.scheduler.CraftTask.run(CraftTask.java:101) ~[purpur-1.20.4.jar:git-Purpur-2118]
        at org.bukkit.craftbukkit.v1_20_R3.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:57) ~[purpur-1.20.4.jar:git-Purpur-2118]
        at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22) ~[purpur-1.20.4.jar:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:840) ~[?:?]

when running
run section {ask_command_handler} async with player's uuid, arg-1

in a command as console, leading player's uuid to be unset.

Should be fixed by my pr


Unblock SwiftCC usage on Windows

We don't have a sensible way to mangle functions using the Swift calling convention on Windows currently. For now, as per discussions on swift-dev, don't do anything special and mangle it like the C calling convention.
Also in this patch, address feedback on usage of llvm_unreachable.

Submitted as a patch to Clang upstream at https://reviews.llvm.org/D40929.


docker-compose not called but docker compose which is not available

I am trying to implement https://github.com/WolfgangFahl/pymediawikidocker/issues/4
when calling:
  docker.compose.up(detach=True)

it works on MacOS with
docker --version
Docker version 20.10.6, build 370c289

docker-compose --version
docker-compose version 1.29.1, build c34c88b2

but not on Ubutu 20.04 LTS
with
docker --version
Docker version 20.10.7, build f0df350

The error is:
python_on_whales.utils.DockerException: The docker command executed was `/usr/bin/docker compose up --detach`.
It returned with code 125
The content of stdout can be found above the stacktrace (it wasn't captured).
The content of stderr is 'unknown flag: --detach
See 'docker --help'.

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Options:
      --config string      Location of client config files (default
                           "/home/wf/.docker")
  -c, --context string     Name of the context to use to connect to the
                           daemon (overrides DOCKER_HOST env var and
                           default context set with "docker context use")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket(s) to connect to
  -l, --log-level string   Set the logging level
                           ("debug"|"info"|"warn"|"error"|"fatal")
                           (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default
                           "/home/wf/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default
                           "/home/wf/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default
                           "/home/wf/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

Management Commands:
  app*        Docker App (Docker Inc., v0.9.1-beta3)
  builder     Manage builds
  buildx*     Build with BuildKit (Docker Inc., v0.5.1-docker)
  config      Manage Docker configs
  container   Manage containers
  context     Manage contexts
  image       Manage images
  manifest    Manage Docker image manifests and manifest lists
  network     Manage networks
  node        Manage Swarm nodes
  plugin      Manage plugins
  scan*       Docker Scan (Docker Inc., v0.8.0)
  secret      Manage Docker secrets
  service     Manage services
  stack       Manage Docker stacks
  swarm       Manage Swarm
  system      Manage Docker
  trust       Manage trust on Docker images
  volume      Manage volumes

Commands:
  attach      Attach local standard input, output, and error streams to a running container
  build       Build an image from a Dockerfile
  commit      Create a new image from a container's changes
  cp          Copy files/folders between a container and the local filesystem
  create      Create a new container
  diff        Inspect changes to files or directories on a container's filesystem
  events      Get real time events from the server
  exec        Run a command in a running container
  export      Export a container's filesystem as a tar archive
  history     Show the history of an image
  images      List images
  import      Import the contents from a tarball to create a filesystem image
  info        Display system-wide information
  inspect     Return low-level information on Docker objects
  kill        Kill one or more running containers
  load        Load an image from a tar archive or STDIN
  login       Log in to a Docker registry
  logout      Log out from a Docker registry
  logs        Fetch the logs of a container
  pause       Pause all processes within one or more containers
  port        List port mappings or a specific mapping for the container
  ps          List containers
  pull        Pull an image or a repository from a registry
  push        Push an image or a repository to a registry
  rename      Rename a container
  restart     Restart one or more containers
  rm          Remove one or more containers
  rmi         Remove one or more images
  run         Run a command in a new container
  save        Save one or more images to a tar archive (streamed to STDOUT by default)
  search      Search the Docker Hub for images
  start       Start one or more stopped containers
  stats       Display a live stream of container(s) resource usage statistics
  stop        Stop one or more running containers
  tag         Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
  top         Display the running processes of a container
  unpause     Unpause all processes within one or more containers
  update      Update configuration of one or more containers
  version     Show the Docker version information
  wait        Block until one or more containers stop, then print their exit codes

Run 'docker COMMAND --help' for more information on a command.

To get more help with docker, check out our guides at https://docs.docker.com/go/guides/

It looks like
docker-compose

should be called instead of
docker compose

I had a docker-compose in /usr/local/bin which i removed and then installed:
sudo apt-get install docker-compose

Python-on-whales uses docker compose and not docker-compose. docker compose is a complete rewrite in go of docker-compose (written in python). In docker desktop, docker compose is preinstalled. In linux, it's not preinstalled and you have to follow the install steps: https://github.com/docker/compose-cli#compose-v2-aka-local-docker-compose

@gabrieldemarmiesse  thanks for the hin. You might want to check the availability of
docker compose
``` and warn if it is not there instead.

It is a pitty that the docker-compose python code can not be used as a base for all the API functionality.

As it looks the docker reinstall is not the point.
bash
wget https://github.com/docker/compose-cli/releases/download/v2.0.0-beta.3/docker-compose-linux-amd64
ln -s docker-compose-linux-amd64 docker-compose
chmod +x docker-compose-linux-amd64

The idea of the docker team to have files with the same name with different behavior depending on where they are located and in which order they appear in the PATH seems very awkward  and absolutely annoying to me. It makes things difficult to explain and understand. It's like Johan Cruyff's "If I wanted you to understand i would have explained it better"

My Jenkins CI on Ubuntu now works since i could install things manually there. The github actions workflow still fails. Are you installing things in your github actions CI workflow? I'll have a look ...

There is even the code for checking the installation:
def is_installed(self) -> bool:
        """Returns `True` if docker compose (the one written in Go)
        is installed and working."""
        full_cmd = self.docker_cmd + ["compose", "--help"]
        help_output = run(full_cmd)
        return "compose" in help_output

I'd have a hard time calling this due to the inconsitent naming:
class ComposeCLI(DockerCLICaller):

while
docker = DockerClient()

and in its constructor:
self.compose = ComposeCLI(self.client_config)

so
docker.compose.is_installed()

would be the check.
I'll add it to my unit test cases.

def testComposePluginInstalled(self):
        '''
        make sure the docker compose command is available
        '''
        self.assertTrue(docker.compose.is_installed())

see https://github.com/WolfgangFahl/pymediawikidocker/runs/2868316276?check_suite_focus=true
======================================================================
FAIL: testComposePluginInstalled (tests.test_install.TestInstall)
make sure the docker compose command is available
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/pymediawikidocker/pymediawikidocker/tests/test_install.py", line 27, in testComposePluginInstalled
    self.assertTrue(docker.compose.is_installed())
AssertionError: False is not true

False is not true  ... indeed

https://github.com/WolfgangFahl/pymediawikidocker/runs/2869665577?check_suite_focus=true is the first working version it uses
#
# workaround https://github.com/gabrieldemarmiesse/python-on-whales/issues/188
#
installDockerComposeCLIPlugin() {
   docker --version
   # remember working directory
   wd=$(pwd)
   cliplugindir=$HOME/.docker/cli-plugins
   mkdir -p $cliplugindir
   cd $cliplugindir
   wget https://github.com/docker/compose-cli/releases/download/v2.0.0-beta.3/docker-compose-linux-amd64
   mv  docker-compose-linux-amd64 docker-compose
   # try out plugin
   chmod +x docker-compose
   pwd
   ls -l
   docker
   docker  2>&1 | grep compose
   cd $wd
}

and call it when in the public CI
case $os in
   Linux*)
   if [ "$USER" = "travis" ] || [ "$USER" = "runner" ]
   then
      echo "installing for user $USER with operating system $os ... in public CI Environment"
      installDockerComposeCLIPlugin
   fi
   ;;
esac


After the web page loads dilithium.js, an error occurs when executing DilithiumKeyPair.generate(2)

Hi,
I use  in my html code, and
Part of the js code in my frontend:
const level = DilithiumAlgorithm.DilithiumLevel.get(2);
const keyPair = DilithiumAlgorithm.DilithiumKeyPair.generate(level);
Post-processing when web page is reloaded
ReferenceError: Buffer is not defined
at s (dilithium.js:2:63339)
at l.generate (dilithium.js:2:42255)
Am I doing anything wrong?

Hello. Thanks for reporting this issue.
It seems Webpack does not include a Buffer polyfill into the javascript library bundle by default. I changed the webpack configuration to include it. Now it should be working without any extra dependencies in the browser (https://github.com/AgustinSRG/crystals-dilithium-js/releases/tag/v1.1.1).
I also added a basic test page (https://agustinsrg.github.io/crystals-dilithium-js/test.html) to test the browser bundle.
I'm marking the issue as completed. In case you find any other issues with this library, feel free to open more issues in the future.


ARROW-9192: [Rust] run clippy to lint arrow crate in CI

The goal of this PR is not to fix all the clippy errors/warnings in arrow crate, but to make sure no new linting errors are introduced in the future so we can slowly fix the remaining errors.

Hm I think this lint step should be merged into the main Lint workflow. @kszucs can you help?

@kszucs let me know if there is anything i can help to move it to the main lint workflow.

@kszucs  gentle ping, let me know what's the best way for me to help.

Hm I think this lint step should be merged into the main Lint workflow. @kszucs can you help?

It would be nice to have it integrated to archery, but since it's only triggered for the rust changes I think it's fine to defer it to a follow-up.
Created ARROW-9295: [Archery] Support rust clippy in the lint command.

@houqp sorry for the late response. I moved the lint job to the macos build to spare some CI resource and also changed to check all crates.

Created another follow-up to enable more clippy rules: ARROW-9296: [CI][Rust] Enable more clippy lint checks

Thanks @kszucs , at the mean time, I will try to fix more linting errors and see if we can just run clippy as is without the custom linting script before you start adding it to Archery.


Update snapshot isolation requirement

Clarify that snapshot isolation must be enabled on both hub and member DBs, based on user feedback

@MaraSteiu : Thanks for your contribution! The author(s) have been notified to review your proposed change.

The issue that's addressed in the PR appears to be addressed in master. We'll close the PR. If there are outstanding issues or questions, please add a comment or create a new pull request. Thanks.


Maybe add Parameters

Hey there, It would be cool if you can add also parameters tokens have to meet for example over 2000$ in Liquidity and mint revoked and LP burnt, because most of the time tokens are scam so that way it could be really effective.

thank you for the suggestion, I have added functionality, but it still needs to be improved


Files cannot be opened

Hello! I have problems with opening KiCad files. When I try to open any of them, I get an error like "Does not appear to be an eeschema file".
Which version of KiCad did you use to design it?

Hi! I used the development version (5.99). Try installing a relatively recent nightly build and give it a go then.

Okay, i will try later. May I ask you to plot schematic in pdf and send it to me?

Here you go

Thanks!


What does this code mean?

https://github.com/snipermonke01/gmx_python_sdk/blob/49dc0fd18b30d3646ad0828f2b1387951cab8e99/gmx_python_sdk/scripts/v2/get/get_open_interest.py#L77-L78
 oracle_factor = (30 - decimal_factor)
 precision = 10 ** (decimal_factor + oracle_factor)

 precision = 10 ** (decimal_factor + 30 - decimal_factor)

 precision = 10 ** 30

Isn't the value of precision always equal to 10 ** 30 ?

Yes, likely just a misnomer. You are correct, precision in the traditional sense ie conversion from a big int is always 10 ** 30


Revamped DSL & new Module API

Hello,
we have revamped our Koin DSL to make it clearer. We can now declare our module like follow:
val myModule = module {
  single { ComponentA() }

  module("view"){
     single { ComponentB()}
  }
}

A Koin module (declared now with module function) can have an inner module. This DSL is more neutral and better target the idea of declaring module and inner modules.
The following keywords has been deprecated in favor of new ones:

applicationContext -> module
context -> module
bean -> single

(factory has not been touched. You can still use bean keyword)
A module is declared in a path:

module { ... } -> definitions are in /
module("app") { ... } -> defintions are in /app
module("app.view") { ... } -> defintions are in /app/view

Visibility rule is child module can see parent module. This mean that for module:
val myModule = module("app") {
  single { Repository() }

  module("view"){
     single { Presenter(get())}
  }
}

-> Presenter can see Repository.
You can now request a component with the optional module parameter, which indicates the required module path to lookup: by inject(module="...") or get(module="...").
If you don't use the module parameter, you will lookup in all the modules as usual, else  you will lookup at given module path.
To request Presenter class, you can either write it get<Presenter>() or get<Presenter>(module="app.view")
The old releaseContext function has been renamed to release. If I want to release the Presenter instance, I can just use the module path: release("app.view")
This feature has been deployed in 1.0.0-alpha-3. You can already check it and give us some feedbacks 👍

Those keyword name changes are great and are now more natural with how other dependency injection libs name things.


1.18.2 Update

Any desire to update this to 1.18.2? A basic attempt at bumping the version gives me the following error, as well as 6 warnings.
/home/superloach/prgm/Custom-LAN/src/main/java/com/dimitrodam/customlan/mixin/PlayerManagerMixin.java:41: error: cannot find symbol
    private void init(MinecraftServer server, DynamicRegistryManager.Impl registryManager, WorldSaveHandler saveHandler,
                                                                    ^
  symbol:   class Impl
  location: interface DynamicRegistryManager

Swapped DynamicRegistryManager.Impl for the new DynamicRegistryManager.ImmutableImpl, since the previous Impl was an immutable one, and it built successfully. Haven't tested too extensively, but it does work!

How i get the jar for 1.18.2?

I tried superloach's brach but crash the game, the mod loads but the game chash when u try to join in a world

I tried superloach's brach but crash the game, the mod loads but the game chash when u try to join in a world

Try this fork.

Thank you, worked. Here is a link if someone want the mod jar file


Remove open Dialog flicker

🚀 Feature request
Motivation
body-scroll-lock has the option reserveScrollBarGap the preserve scrollbar-width.
If this gets enabled the dialog would not flicker when opening it.
https://github.com/willmcpo/body-scroll-lock#reservescrollbargap
Possible implementations
Could be enabled here:
https://github.com/reakit/reakit/blob/master/packages/reakit/src/Dialog/__utils/usePreventBodyScroll.ts#L16

Thank you! Would you like to send a PR for that?


AD9851::setRefClockHigh() doesn't work

To reproduce this bug:
ad9851.begin();
ad9851.powerUp();
ad9851.setAutoRefClock(false);
ad9851.setRefClockHigh();
ad9851.setFrequency(1000);

The output frequency is not 1kHz.

This can be fixed by #32

@wh201906
See comments in PR #32

@wh201906
if time permits, could you test the develop branch.
In my test it seems to work - tested the value of the mask depending on type - as I have no hardware setup nearby.
Will merge later today.

I only have an AD9851 so I can only test that

That would be sufficient as for the AD9850 there is nothing changed.
When I create 2 objects and print their mask I get the right mask.
So I'm confident it works, but as always proof with real hardware is proof.

@RobTillaart I‘ve tested the code in the develop branch. It's working on AD9851.
I tried AD9851::setRefClockLow(); and AD9851::setRefClockHigh();, both have the right output frequency.
Thanks!


chocolately points at version 1.1.0 instead of 1.3.1

[X] I have searched the issues of this repo and believe that this is not a duplicate

Issue
Chocolately points at 1.1.0 instead of 1.3.1. The readme/website could alternately point at the github releases instead of chocolately.
See also https://github.com/zeit/hyper/pull/1631

Looks like they're held up in the choco system? https://chocolatey.org/packages/hyper#versionhistory

Yeah, 1.3.1 awaits moderation. Clone + local build an option for you?

The direct download option linked on hyper.is is fine, no build needed.

This is resolved.  The current chocolatey package is version 1.3.1.

Thank you


Consider renaming the generated inc/ directory to include/.

My homebrew formula works around this non-standardism by explicitly renaming the directory; it's a small point of friction that I had to work around.

I need a little more context here.  Are you saying my installation creates a non-standard directory?

I mean that in most environments, headers are installed in a directory called include/ next to the directory called lib/ where library binaries are installed; that's sorta standard.  Your distribution calls the directory containing headers inc/, which is sorta non-standard.

Could you give an example of another distribution that uses ./include/ instead if ./inc/ ?

What distribution doesn't use ./include/?  https://github.com/gcc-mirror/gcc/tree/master/include, https://github.com/llvm/llvm-project/tree/main/llvm/include, https://github.com/postgres/postgres/tree/master/src/include, …

I did a census on my system and, according to that, "inc" is only used in the Perl world.  Since libmarpa is supposed to hide, as much as reasonable, its Perl origins, this means that my use of "inc" instead of "include" is a mistake, if not a severe one.
Is it worth fixing, giving all the downstream changes it would inflict?  Ordinarily no, but perhaps fortuitously, I need to refresh myself on the libmarpa and Marpa::R2 build procedures in order to test and evaluate other changes, and this is a nice "test" change, one which arguably is an actual improvement, for me to use to re-familiarize myself.

This change is incorporated into the master branch as of https://github.com/jeffreykegler/libmarpa/commit/11089b107d46acdf93a41baee37e530f2401a410.  Absent feedback to the contrary, I will close this issue in a couple of days.

Closed for the reason given in https://github.com/jeffreykegler/libmarpa/issues/77#issuecomment-1098258140.


Use JSON instead of .properties for config files

.properties files do not support UTF-8, array, hash data etc.
Xitrum includes Jerkson, use it!

See https://groups.google.com/group/xitrum-framework/msg/7d5d882fb9ce5f3a


remove job_management route

This was accidentally added with #240. Thanks for the fix, Joe!

Merged into master and digits-3.0.


When exporting an Array[Node], you can't assign any nodes in the UI.

Godot version
4.0-rc1
System information
Windows 10
Issue description
When exporting an Array of Node's, in the editor, it shows that it's an Array[Object], and doesn't let you assign any nodes to any of the elements.

In Player.gd, I have the line @export var nodes: Array[Node], yet it doesn't allow me to assign any Node's.
Steps to reproduce
Write a simple script attached to a node, with the line of code @export var nodes: Array[Node] on it, then try to assign a node to an element in the UI.
Minimal reproduction project
Not applicable.

Duplicate of https://github.com/godotengine/godot/issues/62916.
Please search before opening issues

@Zireael07 Sorry, I must've used a search term that was too generic, because it came up with 7 pages of issues, and I didn't see any in the first page, and assumed it must be a new issue with rc1. I'll try to be more thorough next time I open an issue.

No worry, the search functionality in GitHub is indeed pretty barebones and it can be pretty difficult to find duplicates.


Change min depth to 0 for ConvertTo-Json

PR Summary
Change min depth to 0 for ConvertTo-Json
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[ ] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[x] Issue filed: https://github.com/PowerShell/PowerShell/issues/13660

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[x] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[ ] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

I don't see any value in the change. If we plan to move new .Net Json API and follow the API behavior the change makes no sense at all.

@iSazonov  From what I understand you want to take away the ability to choose depth right? Why do you want to limit how people use PowerShell? Some choices may make no sense to you, but for other people, it makes a lot of sense.

What does depth 0 mean?

@TravisEz13 https://github.com/PowerShell/PowerShell/issues/13660 describes why I want Depth 0.

The short of it is the depth 0 is "flat" with no nesting at all.

$Object = [PSCustomObject] @{
    AnotherObject  = @{
        Test = 0
    }
    AnotherObject1 = @{
        LetsSett = 'dfdf'
        OhNo     = @{
            OrAnotherLevel = @{
                AndAnother = @{
                    Color = [System.Drawing.Color]::AliceBlue
                }
            }
        }
    }
}
$Object | ConvertTo-Json -Depth 1

Output:
{
    "AnotherObject":  {
                          "Test":  0
                      },
    "AnotherObject1":  {
                           "OhNo":  "System.Collections.Hashtable",
                           "LetsSett":  "dfdf"
                       }
}

What I'm after:
{
"AnotherObject":"System.Collections.Hashtable",
"AnotherObject1":"System.Collections.Hashtable"
}

Of course for nested hashtables the visual part will be bad. But what I'm after actually is same behavior:
$Object | ConvertTo-Html -Fragment

Output:

<colgroup><col/><col/></colgroup>

AnotherObject	AnotherObject1

System.Collections.Hashtable	System.Collections.Hashtable

Can you rebase to try to fix the errors?

@TravisEz13 fixed

@TravisEz13 are we doing this ?

I wrote a bunch of tests for my own ConvertTo-jsonLiteral which has a difference by default having Depth 0 and has additional settings such as BoolAsString, NumberAsString, DateTimeFormat where you can push how the date is formatted as a string, and NewLineFormatting. I do all that because I want it sometimes to behave like ConvertTo-HTML + usually JSON based queries for REST API don't like types or other stuff from native cmdlets.
Maybe it will help, as most of the tests should work on the original cmdlets as I try to validate it with PowerShell implementation with a difference of testing additional parameters in most cases. But I do tests arrays, strings, enums and so on.
https://github.com/EvotecIT/PSSharedGoods/blob/master/Tests/ConvertTo-JsonLiteral.Tests.ps1
Feel free to copy/adjust and enhance if you see any benefit.

Just a gentle reminder @TravisEz13 :-)

Just a gentle reminder @TravisEz13 :-)

Somebody please help to fix the build error.

@kvprasoon It seems unrelated to the PR, please rebase.

@kvprasoon I see unrelated commits. Please fix your rebase.

@iSazonov ohh yeah...donno how did this happen, was doing the changes from different laptops. Will fix it.

@iSazonov @TravisEz13 Closing and I've created a fresh one here https://github.com/PowerShell/PowerShell/pull/14830

PR Summary
Change min depth to 0 for ConvertTo-Json
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes

[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header

[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[ ] None

OR

[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable

OR

[ ] Documentation needed

[x] Issue filed: https://github.com/PowerShell/PowerShell/issues/13660

Testing - New and feature

[ ] N/A or can only be tested interactively

OR

[x] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[ ] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.

OR

[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).

Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.

Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).

Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).


call setupconnection() after displaying client version

closes #4398

tacking onto the 2.10 pile since this fixes a regression that was recently introduced.

thanks for checking that, michelle. There might be something prior to this code that requires a connection to tiller.

Found the issue; had to call ensureClient() after setting up the connection. I've manually tested both scenarios and it works as intended now. Thanks for catchingthat!

Awesome. Same. Works for me as well. Thanks!


tests: better test func names

Codecov Report

Merging #5 into master will increase coverage by 0.55%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master       #5      +/-   ##
==========================================
+ Coverage    97.5%   98.06%   +0.55%
==========================================
  Files           9        9
  Lines         361      361
==========================================
+ Hits          352      354       +2
+ Misses          6        5       -1
+ Partials        3        2       -1

Impacted Files
Coverage Δ

commandline.go
100% <0%> (+20%)
:arrow_up:

Continue to review full report at Codecov.

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