Settle axes discussion for now

Polling does not seem to work in the PR... Maybe here we can vote on the proposal in https://github.com/bioimage-io/spec-bioimage-io/pull/69#issuecomment-822457618 and discuss any changes of this proposal specifically. Please open separate issues for completely different proposals.

Proposal:

We do add a few (pseudo) dimensions (i, f, d) to allow for straight forward description of almost all i/o data, which serves as a more detailed visualization hint (this list of c like axes may be extended in the future, but we will try to keep it short).
We agree not to duplicate any axis letter (chances are those dimensions can very well be flattened, which makes the model more accessible to a wider range of consumer software).
We emphasize the close relationship of channel like (pseudo) dimensions in the documentation to encourage model devs to limit their use to one of them, which allows to map those to the c dimension (e.g. in software that can 'only' handle 6d data) and 'keep it simple', while allowing higher dimensional models (max 9d)
As this turned out more complex than initially assumed, we add a key axes_description with a list of human readable short (single line + char limit) descriptions (maybe nested for 'columns'), that consumer software could potentially display. (alo: maybe fix description for b). Details are left for further discussion.
Left out for further discussion: Add keys like  axes_unit/axes_resolution to further clarify the nature of the i/o data.

edited: poll options were too long and cut off

I guess you don't want comments here again?

I guess you don't want comments here again?

no, of course comments are fine (I updated the poll, its options were cut off). Anything going beyond the scope of comments and minor changes should go to another dedicated issue, though.

I don't think we should allow for >6d (i.e. btczyx) data. Otherwise we need to start to reason about flattening on the spec level, which just introduces unnecessary complexity.
Further, if we introduce the additional axes_description I don't really see the need for anything but c. The difference between c, i, f would be purely semantic anyways, so one might as well check the axes description for it.

Thanks @FynnBe for the summary, I am fine with the proposal and I am thinking an alternative solution to add c, i, f is to make the axes key optional non-image tensor input or output.
It totally make sense for image tensor to stay with btczyx, but it becomes problematic if we force non-image tensor to use these 6 types of axes.
@constantinpape Let me give you some examples where c won't be enough. In a single molecule localization model which takes an image as input and produce a list of xyz coordinates (e.g. deeploco), in this case you can use c for the the three coordinate, but for along the location instances, we won't find a letter from btczyz that fit well. We will likely need something like i and define axes=bic. Or we rather not define the axes, but let the consumer software to handle it. @FynnBe 's argument for enforcing a common standard for axes to enable interoperability for consumer software, however, I think it won't work for all cases. At one point, we will have to accept that fact that some models will only work with a very specifically designed consumer software. In this case,  I think it won't make sense to force the developer to set, for example, axes=bxy so other software can also read it and use an image to represent the xyz coordinates.
There are other cases which c won't be enough, for example I am working on a model which takes an image and a protein sequence as input. For the protein sequence input, we use a 1-hot encoding to encode the 20 amino acid, so a sequence will be come a 2dimensional table. In that case, we will likely need to use c for the encoding and i for the instance of each amino acid letter.
More generally, for non-image data which has more than 3 channels, we will have the situation that b, c, i won't be enough and we cannot use t, x, y, z.

I don't think we should allow for >6d (i.e. btczyx) data. Otherwise we need to start to reason about flattening on the spec level, which just introduces unnecessary complexity.
Further, if we introduce the additional axes_description I don't really see the need for anything but c. The difference between c, i, f would be purely semantic anyways, so one might as well check the axes description for it.

some options following this only-c-idea for tabular data like the 'big bug table' from https://github.com/bioimage-io/spec-bioimage-io/pull/69#issuecomment-822457618 you would recommend to (ab)use t,z,y or x? I suppose axes_description would make it clear and for visualization we could:

agree to interpret a single spatial dimensions as specific visualization hints, e.g. lonely x: = i (index). 1d image -> table!

# example with big table
outputs:
 - name: bug_table    # table with individual bugs
   axes: bxc  # single `x` means index (-> table axes may not contain `y` or `z`)
   shape: [1, 100, 2]  # btw, we don't allow for an unknown size (yet), which would be important for tables, there are not 100 bugs on every page of code after all.
   axes_description: ["batch", "bug", ["size", "age"]]

make visualization hints more explicit and add axes_type or similar(, where only certain keys are allowed for certain axes keys, e.g. b in ["batch"], x in ["x-axis", "index"], c in ["rgb", "image channel", "feature"]).

 # example with big table
outputs:
  - name: bug_table    # table with individual bugs
    axes: bxc
    axes_type: ["batch", "index", "feature"]
    shape: [1, 100, 2]  # btw, we don't allow for an unknown size (yet), which would be important for tables, there are not 100 bugs on every page of code after all.
    axes_description: ["batch", "bug", ["size", "age"]]

channel_type instead of axes_type: like 2, but only c can have multiple meanings, but c may occur more than once.

not allow for wide tables and limit it to a fixed (small) number of columns, only using the # example with fixed columns/ small table from https://github.com/bioimage-io/spec-bioimage-io/pull/69#issuecomment-822457618:

outputs:
  # table with individual bugs
  - name: bug_size  # first column
    axes: bf
    shape: [1, 100]
    ...
  - name: bug_age  # second column
    axes: bf
    shape: [1, 100]
    ...

@constantinpape Let me give you some examples where c won't be enough. In a single molecule localization model which takes an image as input and produce a list of xyz coordinates (e.g. deeploco), in this case you can use c for the the three coordinate, but for along the location instances, we won't find a letter from btczyz that fit well. We will likely need something like i and define axes=bic. Or we rather not define the axes, but let the consumer software to handle it. @FynnBe 's argument for enforcing a common standard for axes to enable interoperability for consumer software, however, I think it won't work for all cases. At one point, we will have to accept that fact that some models will only work with a very specifically designed consumer software. In this case, I think it won't make sense to force the developer to set, for example, axes=bxy so other software can also read it and use an image to represent the xyz coordinates.
There are other cases which c won't be enough, for example I am working on a model which takes an image and a protein sequence as input. For the protein sequence input, we use a 1-hot encoding to encode the 20 amino acid, so a sequence will be come a 2dimensional table. In that case, we will likely need to use c for the encoding and i for the instance of each amino acid letter.

both of these cases boil down to a table. I see that for 20 columns the above option 4. is already too tedious and unintuitive, but options 1-3 could match your use cases here.

More generally, for non-image data which has more than 3 channels, we will have the situation that b, c, i won't be enough and we cannot use t, x, y, z.

I see that we need a bit more flexibility than the hard btczyx image tensor, but maybe it's best to restrict ourselves to the minimal extension that we really need right now and wait for a concrete use case to expand our definitions further. I am sure the ngff discussions will bring more insights over time, so let's aim at an intermediate solution that works for all models currently in and in-line for the model zoo.

@constantinpape Let me give you some examples where c won't be enough. In a single molecule localization model which takes an image as input and produce a list of xyz coordinates (e.g. deeploco), in this case you can use c for the the three coordinate, but for along the location instances, we won't find a letter from btczyz that fit well. We will likely need something like i and define axes=bic. Or we rather not define the axes, but let the consumer software to handle it. @FynnBe 's argument for enforcing a common standard for axes to enable interoperability for consumer software, however, I think it won't work for all cases. At one point, we will have to accept that fact that some models will only work with a very specifically designed consumer software. In this case, I think it won't make sense to force the developer to set, for example, axes=bxy so other software can also read it and use an image to represent the xyz coordinates.

Ok, I understand the use-case for i now. It basically means that you have a list index for a dimension where the size of this dimension might not be known a priori, e.g. because you can have different number of instances in an image.
I agree that it makes sense to introduce this as a different letter, because it is semantically very different from a channel (where you know exactly the size of the channel dimension).
However, note that this implies that b might not be naively applicable, because you might have different numbers of instances per sample, so you get a ragged array instead of a tensor. Could be solved by padding or restricting to b=1.

More generally, for non-image data which has more than 3 channels, we will have the situation that b, c, i won't be enough and we cannot use t, x, y, z.

I disagree here though: there is nothing fundamentally different of stacking 3 or 20 channels. For displaying purposes, channels would be treated as a stack by default (i.e. each channel is shown individually).
For other display modes, e.g. treating 3 channels as rgb, hints could be stored in the axes_descriptors. There are so many different use cases here that it doesn't make much sense to standardize it further; hence text in axes_descriptors are not restricted and a consumer can use it to store its custom visualisation syntax if necessary.
This can cover a wide variety of use-cases, e.g. also multi-dimensional axes can be flattened into c without the need to formalize all this in the spec.
Again, I see the need for i now, because it covers the use-case where data cannot be simply stacked.

I support @FynnBe's last comment. I think each of our software solutions can (and should) support the extra axes in the future for non-image data to visualize for the user. IF we encounter models that need even more dimensions, we can do one of these things:

Say that we only officially support 9D, but you can add more dimensions which may not be supported by all software solutions
Live with the fact that we will have models that work only in one (or none?) of our software because it was tailored for that.
Make it a hard constraint, declining all models >9D

But this is again a discussion we can do when we encounter such models. Now we have a clear example thanks to Wei's work.

Ok, there is some simultaneous posting going on :D.
To summarize my stance:
I would vote for option 1 in the comment from @FynnBe (https://github.com/bioimage-io/spec-bioimage-io/issues/70#issuecomment-823152000), but I do agree with @oeway that we should introduce a new axis letter i.
This is semantically different from c, because it describes "list-like" dimensions, for which the size of the dimension might not be known a priori.
Similar to @tomburke-rse, I think we should only introduce further letters if a use case that does not fit this spec at all (i.e. that is impossible or extremely inconvenient to express. It's totally fine if custom use cases need a bit of massaging to fit the spec, because otherwise we will need to change it for every new use-case.)

Hi @constantinpape and @FynnBe   I think we need to clarify the difference with different channels vs different axes a bit more. Considering the following example for the single molecule localisation or tracking model where it produce a list of xyz coordinates.

x
y
z

1.2
100
200

2.0
2.9
100

100
200
300

For horizontal dimension, we may use the letter c or f, but for the vertical dimension, we are likely need i instead of one of bctxyz because the semantical meaning is about each individual molecule (not because its size is undefined).
In this case, we will define the output tensor as a 3D axes as bic (deeploco for example allows predicting 256 molecules maximum )

I disagree here though: there is nothing fundamentally different of stacking 3 or 20 channels. For displaying purposes, channels would be treated as a stack by default (i.e. each channel is shown individually).

Well, I think it won't work unless we force everyone to flatten axes that does not fall into our defined axes. For example, in the above example, if we now say the model not only output a table of x, y, z coordinate, but it will output an additional table that contains the uncertainty scores for each predicted numbers in the first table. Together with the batch dimension, we will now have a 4 dimensional output bic plus another channel-like axis with length 2 (the first one is real coordinates, and the second one is error), the what letter should we use for the 4th dimension? We cannot use c again because we do not allow duplication @FynnBe @constantinpape

Similar to @tomburke-rse, I think we should only introduce further letters if a use case that does not fit this spec at all (i.e. that is impossible or extremely inconvenient to express. It's totally fine if custom use cases need a bit of massaging to fit the spec, because otherwise we will need to change it for every new use-case.)

I agree with introducing more letters later, but I am thinking that we should provide a more gentle way for those future letters to land. I mean if we do not allow custom axes letter or leave the axes key optional, models with those axes cannot enter the model zoo (because they won't pass the validator). I think we need a way to allow those models to enter the model zoo first, then offer the chance to discuss and absorb the new axis definition.

Also, I hope that in the long-term OME-NGFF will define a more general standard for image metadata that we will be able to use.

That's good! However, I think because OME-NGFF is a image format, there won't be much non-image axes involved, no?

In this case, we will define the output tensor as a 3D axes as bic (deeploco for example allows predicting 256 molecules maximum, so the i axes is padded to have length 256)

I think bic is a good solution here. If you can pad here because you know the maximal size of i in this case this is good;
but there might very well be cases for i were this is not possible. E.g. a model that can do differentiable instance segmentation and returns properties for each instance in an image. But we don't need to discuss that in too much detail now; I just wanted to mention that this is a potential concern for the i dimension.

Well, I think it won't work unless we force everyone to flatten axes that does not fall into our defined axes. For example, in the above example, if we now say the model not only output a table of x, y, z coordinate, but it will output an additional table that contains the uncertainty scores for each predicted numbers in the first table.

You can either flatten OR return a second tensor for the uncertainty scores. So I think this fits in the current proposal without big issues. I want to stress this again:
It's totally fine if custom use cases need a bit of massaging to fit the spec, because otherwise we will need to change it for every new use-case.

I agree with introducing more letters later, but I am thinking that we should provide a more gentle way for those future letters to land. I mean if we do not allow custom axes letter or leave the axes key optional, models with those axes cannot enter the model zoo (because they won't pass the validator). I think we need a way to allow those models to enter the model zoo first, then offer the chance to discuss and absorb the new axis definition.

I think we should avoid adding new letters as much as possible and only do this if there is really no other way.
Hence, I think it's a better strategy to discourage this and encourage developers to use the current specification.

That's good! However, I think because OME-NGFF is a image format, there won't be much non-image axes involved, no?

There are already several use-cases under discussion that are similar to the issues here.
But yes, it's primarily an image data format. But we are also called bioimage.io ;).
Sorry for being so strict here, but I think the whole discussion revolves around one of the core issues I have with the model zoo direction: we are still in an early beta stage and don't have any significant outside user adoption. That's fine, these things take time. But our priority should be making it work for the current scope of serving image data related models.
And I think if we start to introduce very significant changes to the spec now to accomodate more custom use-cases we will either be back to 2 months or more of spec discussions or introduce changes that we don't really understand and that are not described properly. I am not arguing for completely freezing the spec as is and not thinking about custom use-cases at all. But I think right now the focus should be much more on stability.

@FynnBe Thanks for listing the options for axis_description. I am thinking can we make it a list of dictionary to contain more information about the axis? Basically extend your option 1 with a time dimension:
# example with bug table
outputs:
 - name: bug_table    # table with individual bugs
   axes: btic
   shape: [1, null, 2] # use null if we don't know the length
   axes_description:
       - name: "batch"
         type: "ordinal"
       - name: "time"
         description: "frame number in the movie"
         type: "ordinal"
         step: 3   #  for ordinal axis, we can define the step/interval, for `x`, `y`, it can be pixel size
         unit: "second" # the unit of time, for `x`, `y`, it can be `pixels` or `um`
       - name: "index"
         description: "index of the bugs"
         type: "ordinal"
         step: 1
       - name: "features"
         description: "features for each detected bug, including size and age"
         type: "nominal"
         labels: ["size", "age"]
         units: ["meter", "year"] # we have really big and old bugs!

In the above example, here are the changes:

the x to i because  I think we should not change the meaning of x since they are completely different.
axes_description becomes a dictionary where we can add more meta data
each axis should have a type, either ordinal (e.g. btxyz) or nominal (e.g. c).
each ordinal axis can set step and unit
each nominal axis can set labels for its column name and units for the unit for each column

These are inspired by Vega which I recommend to take a look. It defines very thorough grammar for interactive data visualization. It is highly relevant for us especially for non-image data. We can even directly connect our tensor directly to vega and allow interactive visualisation of tensors. For axes, they have a table of properties which we can take inspirations from.
Another idea is that if we have the axes_description field, shouldn't we simply absorb the single letter axes, and spell out the letters and add them as a keyword under axes_description?

You can either flatten OR return a second tensor for the uncertainty scores. So I think this fits in the current proposal without big issues. I want to stress this again:
It's totally fine if custom use cases need a bit of massaging to fit the spec, because otherwise we will need to change it for every new use-case.

I think we all agree that we don't want a lot of changes, but an easier strategy is to propose a fallback plan for cases that does not fit to our current definition. I would simply add "if our current axes letters doesn't fit your case, you are free to use any non-standard axes letter".  Like that we don't have to exclude those non-standard models. And we provide a path to include new axis letters. Keep in mind that making changes to the model architecture is much more difficult, especially when the user already have a published model and they simply want to add an additional model.yaml to add to our model zoo. As a common strategy, we should avoid asking the developers to change their model in order to fit our spec, the spec should be more inclusive. We will suffer from spec stability issue only if we force an incomplete list and do not allow custom axes.

"if our current axes letters doesn't fit your case, you are free to use any non-standard axes letter"

But this is a free for all and can result in developers just using any letters they think fits because we effectively don't enforce anything. This is bad, e.g. for ilastik where the current axes letters more or less map to the axis tags that are used to label the axes.
Again, given that we don't have any real outside contributions yet, I don't think we should adjust the spec to match any anticipate non-custom model. If we see that this is a real problem at some point we can still change it but for now I think it's much better to be strict here.

I am thinking can we make it a list of dictionary to contain more information about the axis?

I really like that proposal. I would keep the axes and axes_description separate though, because otherwise we break compatibility with the current version of the spec.

"if our current axes letters doesn't fit your case, you are free to use any non-standard axes letter"

But this is a free for all and can result in developers just using any letters they think fits because we effectively don't enforce anything. This is bad, e.g. for ilastik where the current axes letters more or less map to the axis tags that are used to label the axes.
Again, given that we don't have any real outside contributions yet, I don't think we should adjust the spec to match any anticipate non-custom model. If we see that this is a real problem at some point we can still change it but for now I think it's much better to be strict here.

That's why we have to define very clearly what our axes are for and what it means if you use anything else. If we do that in the documentation and tutorials and someone still does only use optional stuff, then the model developer has to live with the consequences of not being consumable by use easily and not truly being on-spec.

I am thinking can we make it a list of dictionary to contain more information about the axis?

I really like that proposal. I would keep the axes and axes_description separate though, because otherwise we break compatibility with the current version of the spec.

Also like this one.

But this is a free for all ...

Totally agreed, let's avoid a free for all situation!

I really like that proposal. I would keep the axes and axes_description separate though, because otherwise we break compatibility with the current version of the spec.

I am actually in favor of keeping they axes, but treat it as axes description, e.g. 'extending' our axes key. For the standard cases we have now we can transform axes to axes description automatically when packaging. There is some converter logic already with the validator.

That's why we have to define very clearly what our axes are

Yes, I totally agree that we need to describe them better.

If we do that in the documentation and tutorials and someone still does only use optional stuff, then the model developer has to live with the consequences of not being consumable by use easily and not truly being on-spec.

I am still not convinced we should allow other letters. This would also mean that we can do much less static checks if axes are compliant with the spec.
We can discuss if we use something like SHOULD NOT contain any other letters instead (cf. https://tools.ietf.org/html/rfc2119). But then the wording should make clear that this is highly discouraged.

I am actually in favor of keeping they axes, but treat it as axes description, e.g. 'extending' our axes key. For the standard cases we have now we can transform axes to axes description automatically when packaging. There is some converter logic already with the validator.

@FynnBe sorry, I don't quite understand this comment.

@FynnBe sorry, I don't quite understand this comment.

I don't like the redundancy of having an axes field and a axes_description field. and the most straight forward field name is axes, but I, too, like the more extensive description of axes with a list of dicts. Right now the name field in Wei's poposed axes_description section not very meaningful and just a long version of the axes letter. If we could replace it with an enum like field (that should not be called name, as name is never an enum in our spec), e.g. axis, role or kind (kind is too similar to type though), then we can drop the axes letters and call the field that contains the axes description axes instead of axes_description
maybe something like:
# example with bug table
outputs:
 - name: bug_table    # table with individual bugs
   ## axes: btic # drop this
   shape: [1, null, 2] # use null if we don't know the length
   axes:  # now called 'axes'
       - axis/role: "batch"  # one of ["batch", "index", "time", "channel", "z", "y", "x"]
         type: "ordinal"  # would be default for "batch" and only valid type option
       - ...
       - axis/role: "channel"
         description: "features for each detected bug, including size and age"
         type: "nominal"
         labels: ["size", "age"]
         units: ["meter", "year"] # we have really big and old bugs!

of course we can have the same discussion again if we want to allow not only "channel", but also "feature" and "category", but with description, type, labels, and units describing the nature of the axis, the role of it might be considered a "channel".

But this is a free for all and can result in developers just using any letters they think fits because we effectively don't enforce anything. This is bad, e.g. for ilastik where the current axes letters more or less map to the axis tags that are used to label the axes.

I agree that "free for all" is not what we want, but I don't agree with your interpretation. We can work on the wording carefully and make it as a case that is not strictly prohibited, but highly discouraged.
My point is, having to changing the model architecture in order to fit our spec won't be an option. To move forward, I am totally fine with the strict definition if you can provide a solution for >3D non-image/non-spatial tensors. Since xyz and t are have very specific meaning, we will likely need b in all cases, the only left letter c won't work for any additional axes (e.g. the example I mentioned above that produce two tables in one tensor). This should be considered as a bug of the current design.
I proposed 3 solutions: 1) allow duplication so we can use several c 2) use a letter to represent undefined axis 3) make it optional 4) it's discouraged but allow custom axis and @constantinpape proposed 5) ask the user to change the network architecture. There seems also another proposal about 6) postpone it and add change the spec later
I think 5) is not an option because it's too much work for the user 6) means we will reject models that do not fit to our current definition. I suggest that we either come up with a 7th solution or choose one from 1-4.

I like @FynnBe 's proposal about renaming axes_description to axes and absorb it as a key, e.g. role. For providing backward compatibility, we can indeed automatically generate the old axes key, and print out a deprecation warning. Sometime later we can completely remove that.

If you want we can put it all into axes, but then we have to follow semantic versioning and bump the version to 0.4.0 (even if we provide some automatic conversion; but that is independent of the spec description itself).

I proposed 3 solutions: 1) allow duplication so we can use several c 2) use a letter to represent undefined axis 3) make it optional 4) it's discouraged but allow custom axis and @constantinpape proposed 5) ask the user to change the network architecture. There seems also another proposal about 6) postpone it and add change the spec later

how about
7) allow for duplicate i to represent a multiindex
rationale: If i is involved the tensor represents some tabular data that might as well be indexed with multiindex.
advantage over 1): in case of combination with zyx axes it's clear what to display (there is only a single c)
advantage over 2-4): everything is defined, no room for any degree of "free for all"

Hi there!

Sorry for being so strict here, but I think the whole discussion revolves around one of the core issues I have with the model zoo direction: we are still in an early beta stage and don't have any significant outside user adoption. That's fine, these things take time. But our priority should be making it work for the current scope of serving image data related models.
And I think if we start to introduce very significant changes to the spec now to accomodate more custom use-cases we will either be back to 2 months or more of spec discussions or introduce changes that we don't really understand and that are not described properly. I am not arguing for completely freezing the spec as is and not thinking about custom use-cases at all. But I think right now the focus should be much more on stability.

Totally agree with @constantinpape. Making very small changes sounds reasonable but updating the specs to version 0.4.0 seems for me starting again with the adaptation of our software to the new version of the model.yaml, which in our case I'm not sure we can really go for it.

use a letter to represent undefined axis 3) make it optional 4) it's discouraged but allow custom axis and @constantinpape proposed

I agree with this but the only problem is that the CI checker couldn't evaluate this field or output an error message as it happens now with this image classification model. On the other hand, any model uploaded to the BioImage Model Zoo should be compatible with at least one software. If this can be ensured, then I do not see further problems.

... e.g. the example I mentioned above that produce two tables in one tensor

Not sure about pytorch, but in tensorflow, wouldn't this be a multi-ouptut (list of tensors, or list of outputs)? if so, you could specify it as independent outputs.
Trying to see this from a high perspective, I think the main problem here is dealing with whatever that is not an image of btxyzc and being able to display all casuistics. So I'd try to make this simpler at least for now.
What I see:

Can you display anything that is not an image with more than 2 dimensions? If so, it would imply specific post-processing or some more code (a table is 2D so displaying larger dimensions seems not obvious to me) --> software specific model, and maybe here the config field should be used together with the run_mode.
If the tensor is an image, I see no differences between having i, f or c  or ccc (once x, y, z or t are specified) in terms of visualization unless you want to make very specific displays. This goes in hand with @oeway comments and could be a solution for >6D images ("I proposed 3 solutions: 1) allow duplication so we can use several c").
The only reason why it might be important to distinguish i, f or c  is to use the model afterward in a larger workflow which is more than just processing an image with a model --> Is this in the scope (for the moment)?

Maybe I'm wrong, but I really think it would be much simpler if we knew first whether the tensor is an image or not, and this is regardless of any axis name (same issue here https://github.com/bioimage-io/spec-bioimage-io/issues/12). Then:

If it is an image, more axis letters than btxyzc might not be necessary if we allow duplicate names. (We can of course limit this to 6D and if we do not, models with larger dimensions would just not be compatible with some software but this shouldn't be a problem at all).
If it is not an image, how many dimensions are we ready to support as software? If the tensor is non-image/non-spatial, does it really matter if you use xy as long as it is not an image? Semantically it's different because you already know that it is not an image and in that case, all these rows/y/i/, columns/x/channels/f/d/... seem to be equivalent. If we do not want to add specific tags about image/non-image, we can just use different letters for images and non-images.

If we take a step back, I think we have a lot we agree on now:
I think everyone is happy with a new form of the axes, similar to what @FynnBe wrote down in https://github.com/bioimage-io/spec-bioimage-io/issues/70#issuecomment-823465395.
As far as I can see, the only two unclear points are:

Is it allowed to repeat axes letters (or what we will call role or similar in the new layoy)? Is it allowed for just certain letters like i?
Is it allowed to add new letters that are not part of the spec? (If so this should be discouraged).

I would vote in favor implementing the new field and then discussing 1. and 2. separately.

Making very small changes sounds reasonable but updating the specs to version 0.4.0 seems for me starting again with the adaptation of our software to the new version of the model.yaml, which in our case I'm not sure we can really go for it.

I think if the change in axes description is the only (breaking) change we introduce the effort of updating to the new spec would be minimal and we could also still support 0.3 and just print a deprecation warning in the model checker.
I see this change as not being very large, but it is breaking with our current 0.3, so we need to increase the minor version; if we stop following semantic versioning rules the whole process will become very convoluted.

I agree with this but the only problem is that the CI checker couldn't evaluate this field or output an error message as it happens now with this image classification model. On the other hand, any model uploaded to the BioImage Model Zoo should be compatible with at least one software. If this can be ensured, then I do not see further problems.

I think with ic we can easily represent tables, which should fix the case you have linked to.

Not sure about pytorch, but in tensorflow, wouldn't this be a multi-ouptut (list of tensors, or list of outputs)? if so, you could specify it as independent outputs.

Yes, this would be the same in pytorch, so I agree that should just be independent outputs.

Maybe I'm wrong, but I really think it would be much simpler if we knew first whether the tensor is an image or not, and this is regardless of any axis name (same issue here #12). Then:
* If it is an image, more axis letters than `btxyzc` might not be necessary if we allow duplicate names. (We can of course limit this to 6D and if we do not, models with larger dimensions would just not be compatible with some software but this shouldn't be a problem at all).

* If it is not an image, how many dimensions are we ready to support as software? If the tensor is non-image/non-spatial, does it really matter if you use `xy` as long as it is not an image? Semantically it's different because you already know that it is not an image and in that case, all these `rows/y/i/`, `columns/x/channels/f/d/...` seem to be equivalent. If we do not want to add specific tags about image/non-image, we can just use different letters for images and non-images.

I personally like that we don't need to have different rules for different kind of tensors in the current proposal. This makes it easier to describe and verify the spec, because there are no conditionals we need to introduce.
From the software perspective, I would hope that the new axes are pretty easy to intepret:

xy, cxy, xyz, cxyz (and the same with a t): this is image data, should be straight forward to display. By default c would be treated as a "stack of channels". Other display modes (like rgb / argb) would need to be specified in some other field; following the suggestion by @oeway maybe we could look how vega does this.
ic: this is table data
anything else mixing i and x or y etc: this is weird, I can probably not display it.

Note that this is just my interpretation, any consumer can implement this as they see fit and there is no need to have this as an explicit requirement in the spec (might still be good to add some description that helps interpretation thoguh).

how about

allow for duplicate i to represent a multiindex

@FynnBe I am ok with your proposal 7) about allow duplicating i.

Not sure about pytorch, but in tensorflow, wouldn't this be a multi-ouptut (list of tensors, or list of outputs)? if so, you could specify it as independent outputs.

@esgomezm yes, you can do that as a workaround, but that does mean we are impose some limitation on the model design. I think we should avoid having this type of constrains, designing models and train them is already challenge enough, we shouldn't force them to change the model in order to be listed in our model zoo.

Maybe I'm wrong, but I really think it would be much simpler if we knew first whether the tensor is an image or not, and this is regardless of any axis name (same issue here #12).

I agree with @constantinpape that we should not have conditional definition of the axes. However, we can think about adding a new field in the new definition of axes to explicitly say if the axis is spatial. For now I propose we use ordinal and nominal for the axis type, but we can also add spatial for example, for x, y, z although that will be a bit redundant to the role key.

I think if the change in axes description is the only (breaking) change we introduce the effort of updating to the new spec would be minimal and we could also still support 0.3 and just print a deprecation warning in the model checker.

I am fine with both minor or major bump of the version number. I think if we bump to 0.4.0, that should be also fine, we can let 0.3.0 and 0.4.0 co-exists. I mean especially later we will have multiple version co-exists anyway, upgrading the spec does not mean everyone have to upgrade their models, a deprecation warning would be enough.

As far as I can see, the only two unclear points are:
Is it allowed to repeat axes letters (or what we will call role or similar in the new layoy)? Is it allowed for just certain letters like i?
Is it allowed to add new letters that are not part of the spec? (If so this should be discouraged).
I would vote in favor implementing the new field and then discussing 1. and 2. separately.

Sounds good to me.

Once the automatic packaging is up to speed, we can just "repackage" the current models and have the automatic conversion change the version number and in this case, axes content (minor or major, I don't mind either). So we wouldn't have to work with two versions (Lets avoid a python2 vs python3 type of situation at all cost^^). In the worst case someone would have to redownload the model to get the up to date version.

I would vote in favor implementing the new field and then discussing 1. and 2. separately.

I think this is a great idea. We already made a huge step forward on this axes discussion. A future change to duplicate an axis key or adding another one will be comparatively small change, so maybe we just move forward with what we definitely agree on for now...

Finalizing the 0.4.0:
# example with bug table
outputs:
 - name: bug_table
   shape: [1, 5, null, 2]
   # test_tensor: <uri>  # ida for next version: move this mandatory test field here (instead of `test_inputs/outputs`)!
   axes:  # now called 'axes'
       - role: batch  # one of ["batch", "index", "time", "channel", "z", "y", "x"]
         # all other fields are invalid for "batch"
       - role: time
         label: "space time" # but may not be a list!  (same for zyx and index)
         step: 10  # optional; default 1
         unit: ms  # optional; default: null; free text, but recommended standard from documented list, e.g. https://www.maplesoft.com/support/help/Maple/view.aspx?path=Units/SI
       - role: x
         step: 200  # default: 1
         unit: nm  #
       - role: index
         label: bug
         # step: <here invalid>  # forbidden for role "index"
         # unit: <here invalid>  # forbidden for role "index"
       - role: channel
         description: "features for each detected bug, including size and age"  # optional; char limit: 128
         # type: "nominal"  # mandatory non-default (guess for old models: "nominal")  => discuss addition of 'types' separately...
         label: ["size", "age"]  # optional; if list, then needs to match shape (and unit if specified);
         unit: ["meter", "year"]  # optional; if list, then needs to match shape (and label if specified); we have really big and old bugs!
         # step: <here invalid>  # must not be specified if label or unit is a list
 - name: bug_table2
      ...

Just to summarize the result on the meeting about this today:

we will first add i to our old-style axes and bump the PATCH, see #75.
then we will implement the non-controversial parts of the new axes, summarized in the comment above.
afterwards we can discuss the parts that are still controversial or unclear:

do we allow duplication of roles? Only for the channel role?
do we move test_input/output to the axes and call it test_tensor (or similar)
do we introduce the type with options nominal or ordinal (which would for example constraint the label and unit fields).

@FynnBe What's the status with the axes?

For now I'm working on finalizing the 0.3.2 as we decided to implement the axes changes in 0.4.0...

suggestions for preliminary decisions:

afterwards we can discuss the parts that are still controversial or unclear:

do we allow duplication of roles? Only for the channel role?
no. currently we don't have use-case for this and it is easy to add later (but not easy to remove again)

do we move test_input/output to the axes and call it test_tensor (or similar)
yes. this change is autoconvertible (can be undone in any future version) and just makes a lot of sense!

do we introduce the type with options nominal or ordinal (which would for example constraint the label and unit fields).
we add it as an optional field for now. this way we don't have more work converting models, but can play around with the idea more and specify it for new models which then don't need manual conversion if we make type mandatory in the future.

Seems to me that breaking shape down per axis would make sense as well.
We could move shape into axes as length (or size). default could be null. For the channel role it could be inferred if labels/units are given. for some roles we might allow the min/step combination...

Question:
We use the axes characters bcitxyz in many places (e.g. also in the pre-/postprocessing kargs). Should we generally accept b as an alias for batch, c for channel, etc..?
Or do we from now on require to specify the axes as a list of string with the full role name?

Question 2:
Are there any use-cases where step make sense for a channel axis?
I am confused about the label/unit of the actual values vs the label/unit of the channel itself.
All other axis exclusively describe the axis and do not inform about the values. This is different for the channel axis, like in the example above:
 label: ["size", "age"]  # optional; if list, then needs to match shape (and unit if specified);
 unit: ["meter", "year"]

here the recorded values are in meter and in years. a step from the 'size' channel to the 'age' channel does not make sense.
For the example of multi-channel microscopy I would expect something like this:
label: [500nm, 650nm]  # the wavelengths used for each channel
unit: lx*s  # unit of the recorded values (here: lux seconds to record exposure)

which would be equivalent to
label: [500nm, 650nm]  # the wavelengths used for each channel
unit: [lx*s, lx*s]  # unit of the recorded values (here: lux seconds to record exposure)

This is now mixing a label per channel with the unit of the recorded values.
Using the channel axis like any other axis would look like this for example:
label: wavelength
unit: nm
step: 100

this would mean each channel is 100nm apart from the next. This would further require an offset... This does not make sense! Another problem here is that we then do not have a field to describe the unit of the recorded values.
I think what we had in mind so far is this 'mixed' use above. labels refer to the channels like for any other axis role, but unit always refers to the recorded values. If there is a single label for multiple channels e.g. 'rgb', the channels are implicitly named with an index, e.g.  rgb[0], rgb[1], rgb[2]. (although the rgb example would be nicer as a list: ['r', 'g', 'b'])
Problem: for a single implicit channel there is no way of specifying the unit
-> solution: make an explicit singleton axis to describe the channel
If we always want this mixed use then step never makes sense for the 'channel' axis...

maybe for the 'channel' axis we should rename unit to value_unit to make the distinction clearer. (and then forbid a channel axis to have unit and step). And if we come up with use-cases that require 'channel' to have unit/step we can add it without clashing with the value unit...
(I'm assuming this is a reasonable solution for now...)

My 2cents:

do we want to do this now? I agree that it would be nice in principle, but we are back to having many moving parts if we do it together with the workflow spec.
In general: how about trying to re-use the axes metadata from ngff: https://ngff.openmicroscopy.org/latest/#axes-md


Issues installing and running

Trying to install and run for the first time.  Building from source, gradle fails with a series of access errors, unable to retrieve various components from repo1.maven.org and other sites, even though curl has no issue getting same objects.  I then copied the prebuilt version but it is probably not compatible with my RHEL7 installation on a VM - it complains about a version compatiblity issue -- Exception in thread "main" java.lang.UnsupportedClassVersionError: com/datastax/loader/CqlDelimLoad : Unsupported major.minor version 52.0.
Please advise, and thanks in advance.

The latter issue is usually an incompatibility with the version of Java that it was built with and the version of Java that you have installed.  I build with "1.8.0_66".  What version do you have installed?
As for the gradle/maven issues, it is a little hard to know without the actual settings, but I would do the following:

check that your settings in ~/.m2 are correct
check that the responses via curl are actually artifacts and not just error pages
wipe out your Maven cache and try again: rm -rf ~/.m2/repository/


parse not &  not-join (#389)

This deals with parsing and the pre-algebrizing validation.
I'm also looking at how Nicks changes to the parser affect this, and also at applying and algebrizing the clauses.

Closing in favor of #422.


[1.36.0] Error when renaming folders

I have checked the following:

[X] I use the newest version of bruno.
[X] I've searched existing issues and found nothing related to my issue.

Describe the bug
When renaming folders in Bruno (MacOS) you get the following error:
Error invoking remote method 'renderer:rename-item': TypeError [ERR_INVALID_ARG_TYPE]: The "cb" argument must be of type function. Received undefined
.bru file to reproduce the bug
NA
Screenshots/Live demo link

This will be fixed in the release v1.36.1 that will be shipped shortly


[Feature] _get_pixel_values needs to return tgt_sizes

Checklist

[X] 1. If the issue you raised is not a feature but a question, please raise a discussion at https://github.com/sgl-project/sglang/discussions/new/choose Otherwise, it will be closed.
[X] 2. Please use English, otherwise it will be closed.

Motivation
For some multi-modal models like minicpmv-2.6, it is necessary to obtain tgt_sizes when processing images, but the current _get_pixel_values only returns pixel_values and not tgt_sizes
Refer to https://huggingface.co/openbmb/MiniCPM-V-2_6/blob/4e4be000cd81feda8b96d14b53f1791b4010b038/image_processing_minicpmv.py#L415
Related resources
No response

Thanks for reporting this. Contributions are welcome!


Test SqlConnectOptions creation from URL

See JdbcUrlParserTest
We have a simple test for Postgres but the logic changes a lot based on the database selected.
We should make sure to test that we create the right SqlConnectOptions for each database.
This is the method that creates the SqlConnectOptions object: https://github.com/hibernate/hibernate-reactive/blob/cd8d50c851a2a3a528e77555c214fca20693a7a8/hibernate-reactive-core/src/main/java/org/hibernate/reactive/pool/impl/DefaultSqlClientPoolConfiguration.java#L92
Relates to #864

Logged vertx issue to allow additional URL properties to be captured during parsing. #1115

@gavinking @DavideD
So do we want HR users to be able to pass arbitrary properties on their URLs through the vertx sql clients?  Currently there's logic in vertx that is limiting the values being processed. (see #1115)
Currently the vertx SqlConnectOptions URL parsing implementations are creating a JsonObject map of specific or common parameters.
Couple examples

PgConnectionUriParser
DB2ConnectionUriParser

The parsing logic is customized to the DB-specific SqlConnectOptions implementations to match the getters/setters for some common and specific parameters.
It shouldn't take a lot of work to free things up on the vertx side, but want to know that we need these changes on our side.

So do we want HR users to be able to pass arbitrary properties on their URLs through the vertx sql clients?

Well, I mean naïvely I would say yes.
I don't see why we need to protect the database from receiving connection properties. That's it's responsibility to safely handle, I would have thought.


The v0.8.24 output "Could not find or load main class org.jruby.Main" error on Windows

embulk 0.8.24
OS: Windows (10,2012 Server R2)

Expect behavior
no error
D:\embulk-test>embulk
Embulk v0.8.24
Usage: embulk [-vm-options] <command> [--options]
Commands:

Actual behavior
D:\embulk-test>embulk
Error: Could not find or load main class org.jruby.Main
Embulk v0.8.24
Usage: embulk [-vm-options] <command> [--options]
Commands:

Note

embulk.bat: OK(No Error)
embulk: NG

Reference
https://gist.github.com/kazup0n/6d960a808f0fd3eb1848914893553824

#676 will fix this. :)

Released v0.8.25, and the issue should be fixed there. Please reopen this issue if the problem is still there.


[Android] Error after app dismiss and reopen with notification from service

HI,
(I'm pretty sure that the problem is mine and not from your component, but I cannot fix it in any way, I you test it, and works, but you havent time to help me just told me and I close the bug, no problem :) )
I have an app with service which has a notification, everything works perfect until I close the app, then I touch the notification to reopen the app the app works but when I try to show a ActionSheet I get this error:
"Unable to add window -- token android.os.BinderProxy@30881a8 is not valid; is your activity running?"
StackTrace:
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/data/lanes/2692/e98e9627/source/mono/external/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:143
at Android.Runtime.JNIEnv.CallVoidMethod (IntPtr jobject, IntPtr jmethod) [0x00062] in /Users/builder/data/lanes/2692/e98e9627/source/monodroid/src/Mono.Android/src/Runtime/JNIEnv.g.cs:554
at Android.App.Dialog.Show () [0x00043] in /Users/builder/data/lanes/2692/e98e9627/source/monodroid/src/Mono.Android/platforms/android-23/src/generated/Android.App.Dialog.cs:3022
at Acr.UserDialogs.Extensions.ShowExt (Android.App.Builder builder) [0x00012] in C:\dev\userdialogs\src\Acr.UserDialogs.Android\Extensions.cs:40
at Acr.UserDialogs.UserDialogsImpl+<>c__DisplayClass6_0.b__6 () [0x00000] in C:\dev\userdialogs\src\Acr.UserDialogs.Android\UserDialogsImpl.cs:84
at Acr.Support.Android.Extensions.RequestMainThread (System.Action action) [0x00019] in :0
at Acr.UserDialogs.UserDialogsImpl.ActionSheet (Acr.UserDialogs.ActionSheetConfig config) [0x0016d] in C:\dev\userdialogs\src\Acr.UserDialogs.Android\UserDialogsImpl.cs:84
at XXXXXXX.Core.ViewModels.XXXXXXXXXViewModel.ContextMenu (XXXXX.Core.Entities.XXXXXX XXXXXXXX) [0x00097] in C:\Users\X\X\X.Core\ViewModels\xxxxxxxViewModel.cs:402
--- End of managed exception stack trace ---
android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@30881a8 is not valid; is your activity running?
at android.view.ViewRootImpl.setView(ViewRootImpl.java:571)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:310)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:85)
at android.app.Dialog.show(Dialog.java:319)
at mono.android.view.View_OnClickListenerImplementor.n_onClick(Native Method)
at mono.android.view.View_OnClickListenerImplementor.onClick(View_OnClickListenerImplementor.java:29)
at android.view.View.performClick(View.java:5204)
at android.view.View$PerformClick.run(View.java:21155)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5422)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

Arf ... last test make this work...
I was doing some test this weekend and by mistake I installed from nuget an old version of userdialog... with that version I have to use this to initialize UserDialogs.Init(() => this);
Changing that for this: UserDialogs.Init(this); solve the problem... I need sleep more and code less hahaha

thanks for commenting you solution. i had the same problem and done the exact same thing...


[CP][beta channel] Cherry pick fix for migration tool crash when code is already migrated

commit(s) to merge: cf4d300c0bfd0eba3df5979f5c242d212b1f47a8
merge instructions: The commit does not cherry-pick cleanly.  I've resolved the merge conflicts and uploaded a CL based on the beta branch here: https://dart-review.googlesource.com/c/sdk/+/172064.
What is the issue: If the user runs dart migrate on an already-migrated package, they see a stacktrace.
What is the fix: Leverage logic for detecting already-migrated code that was developed for https://github.com/dart-lang/sdk/issues/44144; if code is already migrated, and there are no errors, output a friendly message indicating there is nothing to be done.
Why cherrypick: @mit-mit tagged the issue as a beta-blocker (https://github.com/dart-lang/sdk/issues/44193#issuecomment-726748091)
Risk: Some small risk due to merge conflicts in the cherry-pick, mitigated by manually running all nnbd_migration unit tests and manually testing the fixed behavior after resolving conflicts.
Link to original  issue(s): https://github.com/dart-lang/sdk/issues/44193
/cc @kevmoo @mit-mit @whesse @athomas @vsmenon @franklinyow

@leafpetersen @pcsosinski @mit-mit
I'm marking this as approved because the original was marked as beta blocker

When picking this, please include these two string changes:
https://github.com/dart-lang/sdk/commit/0258778e3b20d1f9b2c656b0793322d3c9fa8178
https://github.com/dart-lang/sdk/commit/e205acb506cca15228da56b26693e3339a22058a

Merged to beta in 09481aa6ca60a12a5885db108aa5152cecb73fb1 (2.12.0-29.10.beta).


User can download an existing document

@jiayingy can the user download the md file in both the file manager view and editor/viewer view?

05188181dd32b14f0833224ad4dbcb96799dc245


Forgotten password emails

This fleshes out the "forgotten password" route - it now sends emails and updates passwords for real. See this story: https://www.pivotaltracker.com/story/show/92213710
Also: https://www.pivotaltracker.com/story/show/92215856
Also: https://www.pivotaltracker.com/story/show/92216072
Also: https://www.pivotaltracker.com/story/show/92215834
Also: https://www.pivotaltracker.com/story/show/92213688
Also: https://www.pivotaltracker.com/story/show/92213724
You will need a Mandrill key if you want to see it send real emails (see me if you want it). The app fails quietly if you don't have a valid API key set (it logs a Mandrill error but doesn't break the app), and you can still test the whole flow without the risk of emailing people you didn't mean to as follows:

start up the data API locally (hopefully you have some users in your database already, otherwise run the import_users script)
start the app
visit http://localhost:5003/suppliers/login and hit "forgotten password"
type in an email address (preferably one that that exists in your local users table - you can try out different behaviour for supplier vs buyer accounts) and hit the button
check your app logging for a line that starts "Generated reset URL:" - here you can find the URL that would have been sent in an email if you had a valid Mandrill key set.
Paste the full URL into your browser (this is like clicking the link in the email that would have been sent)
Reset the password for the account
Log in to the app using the email address and new password. (Or not if you used a buyer account.)

Could we add the mandril key to the credentials repository?

I asked this in Slack the other day - I'm not sure if Credentials might be too public?

Latest version uses Flask template rendering and inserts user_id where it should have been before.

Pull-request in for adding the environment variables - this should merge before this one:
https://github.com/alphagov/digitalmarketplace-aws/pull/73

Fingers crossed for Travis... this should be good to go now.


BUG: unable to securely deploy app as scipy 1.14.0 requires write permission in docker container.

Describe your issue.
I am unable to securely deploy an app using scipy 1.14.0.
For security reasons, docker containers are run in read-only mode. Up to now I've been using scipy 1.11.4 and have experienced no issues. Upgrading to 1.14.0 causes my deployments to fail as scipy is trying to create a temporary folder but cannot.
This example repo shows how i am using scipy within my container: https://github.com/Cemlyn/scipy-example. Of course I build and run this simple app by running the following:
docker build . -t test
docker run -it --read-only test
Is it possible to revert to behaviour previously seen in version 1.11.4?
Reproducing Code Example
from scipy.stats import norm

means = [0,1,2,3]
stds = [1,1,2,2]

normal_dists = norm(means,stds)

print(normal_dists.mean)

Error message
(temp2) ccr@Cemlyns-MBP scipy-bug % docker run -it --read-only test
Traceback (most recent call last):
  File "messagestream.pyx", line 91, in scipy._lib.messagestream.MessageStream.close
TypeError: remove: path should be string, bytes or os.PathLike, not NoneType
Exception ignored in: 'scipy._lib.messagestream.MessageStream.__dealloc__'
Traceback (most recent call last):
  File "messagestream.pyx", line 91, in scipy._lib.messagestream.MessageStream.close
TypeError: remove: path should be string, bytes or os.PathLike, not NoneType
Traceback (most recent call last):
  File "/opt/pysetup/test_script.py", line 1, in <module>
    from scipy.stats import norm
  File "/opt/pysetup/.venv/lib/python3.11/site-packages/scipy/stats/__init__.py", line 628, in <module>
    from ._rvs_sampling import rvs_ratio_uniforms
  File "/opt/pysetup/.venv/lib/python3.11/site-packages/scipy/stats/_rvs_sampling.py", line 2, in <module>
    from scipy.stats.sampling import RatioUniforms
  File "/opt/pysetup/.venv/lib/python3.11/site-packages/scipy/stats/sampling.py", line 59, in <module>
    from ._sampling import FastGeneratorInversion, RatioUniforms  # noqa: F401
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/pysetup/.venv/lib/python3.11/site-packages/scipy/stats/_sampling.py", line 8, in <module>
    from ._unuran.unuran_wrapper import NumericalInversePolynomial
  File "unuran_wrapper.pyx", line 188, in init scipy.stats._unuran.unuran_wrapper
  File "unuran_wrapper.pyx", line 167, in scipy.stats._unuran.unuran_wrapper._setup_unuran
  File "messagestream.pyx", line 29, in scipy._lib.messagestream.MessageStream.__cinit__
  File "/usr/local/lib/python3.11/tempfile.py", line 351, in mkstemp
    prefix, suffix, dir, output_type = _sanitize_params(prefix, suffix, dir)
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/tempfile.py", line 129, in _sanitize_params
    dir = gettempdirb()
          ^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/tempfile.py", line 320, in gettempdirb
    return _os.fsencode(_gettempdir())
                        ^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/tempfile.py", line 309, in _gettempdir
    tempdir = _get_default_tempdir()
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/tempfile.py", line 224, in _get_default_tempdir
    raise FileNotFoundError(_errno.ENOENT,
FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/opt/pysetup']

SciPy/NumPy/Python version and system information
{
  "Compilers": {
    "c": {
      "name": "clang",
      "linker": "ld64",
      "version": "15.0.0",
      "commands": "cc"
    },
    "cython": {
      "name": "cython",
      "linker": "cython",
      "version": "3.0.10",
      "commands": "cython"
    },
    "c++": {
      "name": "clang",
      "linker": "ld64",
      "version": "15.0.0",
      "commands": "c++"
    },
    "fortran": {
      "name": "gcc",
      "linker": "ld64",
      "version": "13.3.0",
      "commands": "gfortran"
    },
    "pythran": {
      "version": "0.16.1",
      "include directory": "../../../../../../private/var/folders/b3/2xm02wpd21qgrpkck5q1c6k40000gn/T/pip-build-env-q_06ff8x/overlay/lib/python3.11/site-packages/pythran"
    }
  },
  "Machine Information": {
    "host": {
      "cpu": "aarch64",
      "family": "aarch64",
      "endian": "little",
      "system": "darwin"
    },
    "build": {
      "cpu": "aarch64",
      "family": "aarch64",
      "endian": "little",
      "system": "darwin"
    },
    "cross-compiled": false
  },
  "Build Dependencies": {
    "blas": {
      "name": "accelerate",
      "found": true,
      "version": "unknown",
      "detection method": "extraframeworks",
      "include directory": "unknown",
      "lib directory": "unknown",
      "openblas configuration": "unknown",
      "pc file directory": "unknown"
    },
    "lapack": {
      "name": "accelerate",
      "found": true,
      "version": "unknown",
      "detection method": "extraframeworks",
      "include directory": "unknown",
      "lib directory": "unknown",
      "openblas configuration": "unknown",
      "pc file directory": "unknown"
    },
    "pybind11": {
      "name": "pybind11",
      "version": "2.12.0",
      "detection method": "config-tool",
      "include directory": "unknown"
    }
  },
  "Python Information": {
    "path": "/private/var/folders/b3/2xm02wpd21qgrpkck5q1c6k40000gn/T/cibw-run-ut6da4bl/cp311-macosx_arm64/build/venv/bin/python",
    "version": "3.11"
  }
}

Here's what I've found from investigating this bug. I've not looked at this code before, so take this with a grain of salt.

SciPy stats loads a library called unuran for the purpose of generating random numbers.

It appears that unuran logs all of its errors to a FILE *.

That's not the interface we want to provide to users, so we capture that into either an open_memstream() (an in-memory FILE * object) or a tempfile, depending on what the operating system supports, so we can turn the error log stream into Exception objects.
This means that SciPy could accommodate your use case of running on a non-writable filesytem, as long as it can use open_memstream().

strace doesn't seem to provide any smoking guns for why open_memstream couldn't be used. I'm using Linux to test this, so there's definitely operating system support.

In my dev build, the define HAVE_OPEN_MEMSTREAM is set to 0, despite being on a platform which supports open_memstream(). To double-check that I have this support, I tried the open_memstream() example program on this page, and that programs works.

When I manually patch meson.build to set HAVE_OPEN_MEMSTREAM to 1, then it uses memstream, and this fixes the reproducer case.
diff --git a/scipy/_lib/meson.build b/scipy/_lib/meson.build
index fe1252bd3..1b0a7e473 100644
--- a/scipy/_lib/meson.build
+++ b/scipy/_lib/meson.build
@@ -85,13 +85,7 @@ py3.extension_module('_test_deprecation_def',
 #       compiler? Does it not exist, or is it hidden elsewhere?

 conf_memstream = configuration_data()
-
-if meson.get_compiler('c').has_function('open_memstream',
-                                        prefix: '#include <stdio.h>')
-  conf_memstream.set('has_openmemstream', '1')
-else
-  conf_memstream.set('has_openmemstream', '0')
-endif
+conf_memstream.set('has_openmemstream', '1')

 configure_file(
   input: 'src/messagestream_config.h.in',

It looks like something is wrong with this feature detection. But it seems fine according to the docs.
I ran the tests, and all of them pass with HAVE_OPEN_MEMSTREAM force-set to 1. (Of course, we can't do this for all platforms. Windows, for example, does not support open_memstream().)

To check my assumptions that glibc has this function, I tried writing a file called test.c with just the following:
#include <stdio.h>

I then ran gcc -E test.c to expand the #include. In the expanded output, there is a definition of open_memstream.

I also looked into whether this is something that only I am facing, or if this is also happening for published wheels. I wrote a script to download wheels from pypi from 1.11.0 through 1.14.0, (not including patch versions) and search it for messagestream_open_memstream, and disassemble that function. In every case, the code looks like this:
000000000000c920 <messagestream_open_memstream>:
    c920:	31 c0                	xor    %eax,%eax
    c922:	c3                   	ret

In other words, it returns NULL for this function. This indicates that in the following code, HAVE_OPEN_MEMSTREAM is set to 0 when building wheels.
https://github.com/scipy/scipy/blob/ab7d08c6148286059f6498ab5c3070268d13cbd9/scipy/_lib/src/messagestream.h#L8-L18

In order to try to find why meson thinks that I don't have open_memstream(), I looked at the meson logs, and found what options it is passing to the compiler. Removing the options one at a time, I found that passing the -std=c11 option causes glibc to hide the open_memstream, so meson thinks it is missing. See also here.

While searching through the project for uses of _GNU_SOURCE, I found that this has already been reported, but not fixed.  I really ought to have searched for previous reports sooner before spending eight hours debugging this, but you live and learn. https://github.com/scipy/scipy/issues/19911

I think I have a reasonably simple patch to fix this:
diff --git a/scipy/_lib/meson.build b/scipy/_lib/meson.build
index fe1252bd3..3ed2de0a6 100644
--- a/scipy/_lib/meson.build
+++ b/scipy/_lib/meson.build
@@ -87,7 +87,7 @@ py3.extension_module('_test_deprecation_def',
conf_memstream = configuration_data()

if meson.get_compiler('c').has_function('open_memstream',
-                                        prefix: '#include <stdio.h>')
+                                        prefix: '#define _POSIX_C_SOURCE 200809L\n#include <stdio.h>')
  conf_memstream.set('has_openmemstream', '1')
else
  conf_memstream.set('has_openmemstream', '0')

It doesn't appear to be necessary to add the same define to messagestream.h.
This seems to be enough to fix your repro case.

As previously mentioned, this is a duplicate of gh-19911

Hi Cemlyn, I wrote a PR to fix this issue, and it's been accepted. It's planned to be included in the SciPy 1.15.0 update. It may also be backported to version 1.14.1, as it's marked as a backport candidate.

Thanks for getting a fix in so quickly - much appreciated!


Document the process of submitting LaTeX templates to Open LaTeX Studio

#27 added the ability to use LaTeX templates in Open LaTeX Studio. The implemented solution made it easy to add more templates - all that must be done is putting the .tex template file in the correct directory and adding metadata about that template in the xml file. We should document that process on our wiki, so less technical contributors can submit their templates easily.

Hi sebbrudzinski,
I am new to open source and Git Hub and thought that updating the wiki would be a good place to start. I am confused as to whether I have to submit a pull request for the wiki update or if I just create a new page and save it.
Thanks,
Andy

Hello @andyzen619
Please go ahead and create a new page :)

Okay done. Let me know if there anything is wrong.  I look forward to contributing to this project in the future :)

@andyzen619 It looks good. I did some formatting improvements. Can you also add a note to always get author's permission first, before adding the template?

Okay done. I added the note on the bottom.

Fixed by @andyzen619  Thanks!


leezer3.OpenBVE version <IP_ADDRESS>

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

if one is already validated than why did you create another one


Edit resources with NULL values

I can't edit resources with NULL values that I desire to keep as NULL.
To begin with I receive this Warning in the browser. (From React I suppose)

Warning: value prop on input should not be null. Consider using an empty string to clear the component or undefined for uncontrolled components.

Then if I try to save after changing only one value it just clears the form. If I want to update I have to fill all the input fields, even the ones I desire to keep NULL.

can you paste a schema and please write which adapter you use (mongoose/typeorm/sequelize)?

This model for instance, using sequelize adapter. I am able to create a new Partner leaving website as an empty string and its converted to NULL after inserting in the database. But when I try to edit I am not able to do it at all. I tried forcing the allowNull property to true but I get the same error
'use strict';
module.exports = (sequelize, DataTypes) => {
	const Partner = sequelize.define('Partner', {
		name: {
			allowNull: false,
			type: DataTypes.STRING(50)
		},
		logo: {
			allowNull: false,
			type: DataTypes.STRING
		},
		website: {
			type: DataTypes.STRING
		}
	}, {});
	return Partner;
};

I've seen the #370 fix go in, but it changes all NULLs to be blank string.
I'm planning to have admin-bro working with an existing MSSQL DB via sequelize, and at the moment it will be changing pre-existing records replacing NULLs with ''. I can't afford to allow data changing unexpectedly. Is there a plan to have it handle NULLs or will it continue as its currently implemented? (I can't make any changes via the models I'm using sequelize-auto to generate them on the fly)

@mjlawrence83 wow - this is an actual very good solution. We will have to implement this in the core.

Just sharing the approach I took to resolve this issue.
/* jshint indent: 1 */

const NAME = 'Email'

module.exports = (sequelize, DataTypes) => {
    let schema = {
        templateData: {
            type: DataTypes.JSON,
            allowNull: true,
        },
        from: {
            type: DataTypes.STRING,
            allowNull: false,
            unique: false,
            validate: {
                isEmail: true
            }
        },
        sender: {
            type: DataTypes.STRING,
            allowNull: true,
            unique: false,
            validate: {
                isEmail: true
            }
        },
        replyTo: {
            type: DataTypes.STRING,
            allowNull: true,
            unique: false,
            validate: {
                isEmail: true
            }
        },
        priority: {
            type: DataTypes.ENUM('high', 'normal', 'low'),
            allowNull: false,
            unique: false,
            defaultValue: 'normal'
        },
        to: {
            type: DataTypes.TEXT,
            allowNull: false,
            unique: false
        },
        cc: {
            type: DataTypes.TEXT,
            allowNull: true,
            unique: false
        },
        bcc: {
            type: DataTypes.TEXT,
            allowNull: true,
            unique: false
        },
        subject: {
            type: DataTypes.TEXT,
            allowNull: false,
            unique: false
        },
        body: {
            type: DataTypes.TEXT,
            allowNull: false,
            unique: false
        },
        result: {
            type: DataTypes.JSON,
            allowNull: true,
            unique: false
        },
    }
    Object.keys(schema).forEach(key=>{
        if (schema[key].allowNull) {
            let _set = schema[key].set
            schema[key].set = function (val) {
                if (val === '') val = null
                if (_set && 'function' === typeof _set) _set(val)
                else this.setDataValue(key, val)
            }
        }
    })

    let model = sequelize.define(NAME, schema)
    model.associate = function (models) {
        models[NAME].hasOne(models.EmailTemplate)
    }
    model.adminBroConfig = {
        resource: model,
        // options: {
        //     editProperties: ['name'],
        //     listProperties: ['name'],
        //     properties: {
        //         name: {isTitle: true},
        //     }
        // },
    }
    return model
}

fixed in 3.1.0

Is there any documentation about this? I only now know to use __FORM_VALUE_NULL__ to set properties to null in the db because I stumbled upon this PR.


feat: update invokers to support swift 2

Reason for Change:
updating invokers to support swift 2 contract changes
Issue Fixed:

Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] relevant PR labels added

Notes:

/azp run


Expanding Copilot's Code Access: Enabling Cross-File Repository Context in Chat Assistance

When writing in the chat Copilot seems to have access only to the code of the current file, instead of the code of the entire repository. This is extremely limiting in that you cannot ask it to implement something specific by also looking at other files within the repository.

I want to add, that basing on my experience and the demos I have seen in github channel on youtube, Copilot chat should have access to the open files you have in your editor, but basing on its answers it has small context window which doesn't cover more then 100 lines of code in all open files cumulatively

Please see: https://code.visualstudio.com/docs/copilot/workspace-context


Utility classes with BEM

I just started reading about BEM and I quite like the idea. I do have a question though:
Where does BEM stand on utility classes?
At work we like to use classes like .margin-bottom and .margin-bottom-large but I can't find anything about this on the website.  The reason we use those kind of classes is because a lot of the margins (in this  case) will be the same for a lot of elements.
Thanks.

.margin__bottom
.margin__bottom--large

@EddyVinck you should use mixes with special blocks for that:

or even better use variables in styles instead of extra markup.


NRPE support

Not sure what all of this entails, leaving a ticket just to keep this in mind.
Would be nice if we were able to piggy back off of existing NRPE configs. Does this mean we implement a NRPE receiver? I don't recall how NRPE works exactly but I recall the protocol being pretty simple.

Options that I can think of here are:

Support existing NRPE daemons with Go implementation of the protocol
Support NRPE config translation but with a new implementation (e.g. GRPC or JSON/HTTPS)

I'll take a look at this one.

Nice! I know that the NRPE protocol is fairly simple, but I haven't done any sort of a deep-dive - glad to see exploratory surgery!

Schwing! MIT-licensed Go implementation: https://github.com/envimate/nrpe

Hmm, seems to use OpenSSL and CGO rather than native Go SSL. Might need some work.

NRPE uses ADH (anonymous Diffie Helman) cipher suites which are not supported by Go's TLS package: https://golang.org/src/crypto/tls/cipher_suites.go . Apparently it could be implemented in a fork of the Go TLS lib (e.g. https://groups.google.com/forum/#!topic/golang-nuts/URhpLNZWgL8/discussion) . I suggest that if we decide to support NRPE for legacy integration purposes, we do it in a separate service that can do the nasty CGO and integration with the threaded/heavily locking OpenSSL stuff. We could then call between 9volt and that service with GRPC.
Otherwise, we could:

Implement a server that pulls in the NRPE configs and replaces it with something more modern
Build a fork of NRPE that can be installed in place of an existing install, but which supports cert auth
Suggest that people run NRPE behind something like Stunnel, or a simple Go service
Potentially something else?

Thoughts?

Huge bummer about the copher suite not being supported.
Let me ponder about this a bit longer after work. Will update soon.

Optimally it should be the least difficult route for adoption. Requiring folks to update their existing NRPE setups across hosts would be a pain...
Maybe we can build two 9volt's -- 9volt and 9volt-nrpe? That way folks that don't need it can just pull 9corp/9volt and folks who need it, 9volt-nrpe? Utilize build tags as part of the compile/build chain.
The issue that I foresee with having a separate 9volt-nrpe service is that then we have to worry about that being H/A and/or distributed...

So I hacked up a little demo of my GRPC idea. https://github.com/relistan/nrpe-grpc
The idea is you just run this on the box that has 9volt and you don't do much bu have 9volt expect it to be there. It does nothing except isolate the OpenSSL libs and calls to NRPE to an external service.
You can build and run the demo and then pass the client the name of the NRPE check to run. It doesn't currently pass params but you get the gist.

To sketch that out a little better, the idea would be a check in 9volt that is described as a "nrpe" check but which just makes grpc calls to the NRPE bridge. The configuration is all in 9volt and each check runs just like any other check. But instead of calling out to the remote node, it connects to the local NRPE bridge which does the actual NRPE call and replies back to 9volt. No coordination or redundancy is required for the bridge service, it relies on 9volt for everything that matters. You run one bridge per node that runs 9volt. Options for keeping it running are:

People can manage it themselves
9volt could manage it

The second option wouldn't be that bad since the only thing that needs to happen is for it to actually stay running since it has no config.

Yep @relistan - makes complete sense. I'd like to think about how it'll look from docker-side of things - do we bundle both of the bins in the same image and 9volt execs the nrpe helper (and keeps it running)? Maybe 9volt determines if it should launch the nrpe helper if an env var is set?
Ie. NINEVOLT_ENABLE_NRPE by default is false; if someone wants nrpe, they have to ensure that env var (or flag is set).
Need to think about what it'll look like on bare-metal as well, turns out not everyone runs their infra on docker 😄

Looks like in mid-Summer 2016 NRPE got support for much better SSL. Not sure what 9volt should support but my guess is most people who would want to switch would be running old-school stuff.


can't add basic auth

How can I add basic authentication middleware to the route over which metrics are sent?
I tried to do the following and it didn't work:
package metrics

...

func New(app *fiber.App, config ...Config) fiber.Handler {
    cfg := configDefault(config...)

    prometheus := fiberprometheus.NewWith(
        cfg.ServiceName,
        cfg.NameSpace,
        cfg.SubSystem,
    )

    prometheus.RegisterAt(app, cfg.MetricsPath)

    return prometheus.Middleware
}

package routes

...
app := fiber.New(appConfig)

app.Get("/metrics", basicauth.New(BasicAuthConfig(t)), metrics.New(app, MetricsConfig(t)))

Hey, the way you described in the snippet above, it's not currently feasible. But the good thing is fiber supports mounting a new sub app.
package main

import (
	"github.com/ansrivas/fiberprometheus/v2"
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/basicauth"
)

func NewMetrics() *fiber.App {
	app := fiber.New()

	basicAuthMiddleware := basicauth.New(basicauth.Config{
		Users: map[string]string{
			"john": "doe",
		},
	})
        // Make sure to invoke this before calling prometheus.RegisterAt because it internally
        // mounts the prometheus handler at "/", thus we need to ensure that our auth-middleware
        // is available already
	app.Use(basicAuthMiddleware)

	prometheus := fiberprometheus.New("my-service-name")
	prometheus.RegisterAt(app, "/")
	app.Use(prometheus.Middleware)

	return app
}

func main() {
	app := fiber.New()

        // Mount a new sub app with auth-middleware at /metrics
	app.Mount("/metrics", NewMetrics())

	app.Get("/", func(c *fiber.Ctx) error {
		return c.SendString("Hello World")
	})

	app.Listen(":3000")
}


Where are the docs for this?

I'm trying to attempt to do basic things like find out how to add autolinks, but there are no docs for this, even for the different types of markdown flavors supported. Where are they?

I think simply there aren't

There is only commonmark, gfm, and "space-flavored markdown" where space = JetBrains space, and I think the latter is strictly weaker (though the lexical analysis is therefore faster).


FastReport in Linux environment, if the text is longer, it will wrap

FastReport in Linux environment, dot or space, if the text is longer, it will wrap. How to solve this problem?

Hi!
Do you have any screenshots of the problem? Thanks in advance!

Thank you very much.

Thanks for screenshots!
I think the problem is with the libgdiplus library.
Please read the article to solve this problem https://opensource.fast-report.com/2020/10/building-libgdiplus-library-from-source.html


Don't require outdated wasm-bindgen feature from uuid

The uuid package hasn't had the feature wasm-bindgen since https://github.com/uuid-rs/uuid/pull/536, in which it was renamed to js, but using it continues to work on wasm32-unknown-unknown because it accidentally activates the optional wasm-bindgen dependency that is only available on that platform.

it looks like this dep is only used in tests, could be moved to dev deps

Hello!  Any update on when this fix will be merged and released?  This is a blocking issue for a global upgrade we are working to move to uuid v1.9.1:
from our relevant Cargo.toml
[target.'cfg(target_arch = "wasm32")'.dependencies]
indexed_db_futures = { version = "0.4.1" }

build error:
    ... required by package `indexed_db_futures v0.4.1`
    ... which satisfies dependency `indexed_db_futures = "^0.4.1"` of package `securikey-lib v2.1.0 (/Users/ptdecker/PycharmProjects/vHSM/securikey-lib)`
versions that meet the requirements `^1.5.0` are: 1.9.1, 1.9.0, 1.8.0, 1.7.0, 1.6.1, 1.6.0, 1.5.0

the package `indexed_db_futures` depends on `uuid`, with features: `wasm-bindgen` but `uuid` does not have these features.
 It has an optional dependency with that name, but that dependency uses the "dep:" syntax in the features table, so it does not have an implicit feature with that name.

all possible versions conflict with previously selected packages.

  previously selected package `uuid v1.9.1`
    ... which satisfies dependency `uuid = "^1.9.1"` of package `securikey-lib v2.1.0 (/Users/ptdecker/PycharmProjects/vHSM/securikey-lib)`

failed to select a version for `uuid` which could resolve this conflict

Fixed with 0.4.2, thanks!