Crash on Products item click

Problem Description
I am on 1.1.74 Factory planner on a seablock multiplayer map. This is the crash I get.
Let me know if you need more info, was in a bit of a rush.
93.392 Error MainLoop.cpp:1391: Exception at tick 31396557: The mod Factory Planner (1.1.74) caused a non-recoverable error.
Please report this error to the mod author.
Error while running event factoryplanner::on_gui_click (ID 1)
factoryplanner/ui/main/production_handler.lua:233: attempt to index field 'Product' (a nil value)
stack traceback:
factoryplanner/ui/main/production_handler.lua:233: in function 'handle_item_click'
factoryplanner/ui/main/production_handler.lua:394: in function 'handler'
factoryplanner/ui/event_handler.lua:157: in function <factoryplanner/ui/event_handler.lua:114>
93.392 Error ServerMultiplayerManager.cpp:92: MultiplayerManager failed: "The mod Factory Planner (1.1.74) caused a non-recoverable error.
Please report this error to the mod author.
Error while running event factoryplanner::on_gui_click (ID 1)
factoryplanner/ui/main/production_handler.lua:233: attempt to index field 'Product' (a nil value)
stack traceback:
factoryplanner/ui/main/production_handler.lua:233: in function 'handle_item_click'
factoryplanner/ui/main/production_handler.lua:394: in function 'handler'
factoryplanner/ui/event_handler.lua:157: in function <factoryplanner/ui/event_handler.lua:114>"
Reproduction
Create new subfactory in fp tab.
Added Product (titanium plate in this case)
Click on product to add it to the factory list.
Click on the product icon(titanium plate) under the Products column.

Server crashes at this point.

Thanks for the report! This is actually the same root cause as #167, which I just fixed for the next release :)


Documentation on client and EntityDecoder/Encoder

Still got a few TODOs to fix.

Current coverage is 62.54% (diff: 100%)

Merging #749 into master will not change coverage

@@             master       #749   diff @@
==========================================
  Files           208        208
  Lines          4416       4416
  Methods        3968       3968
  Messages          0          0
  Branches        442        442
==========================================
  Hits           2762       2762
  Misses         1654       1654
  Partials          0          0

Powered by Codecov. Last update f0eea87...c2e16c7

👍 on Travis


[FLINK-9355][checkpointing] Simplify configuration of local recovery …

…to a simple on/off switch
What is the purpose of the change
This PR makes the configuration of local recovery easier for the user and turns it into a simple on/off switch.
Brief change log

Config option for local recovery is just a boolean now.

Verifying this change
This change is already covered by existing tests, such as (please describe tests).
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency):  (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

CC @tillrohrmann

You have to regenerate the config docs, instructions can be found here.

@zentol thanks for pointing that out. Updated the PR.

Thanks for the reviews. Will merge this.


NaN values in the results

Hi Thomas,
Thanks for sharing this!
I am just wondering about the NaN values in the results, can you explain ?
We are currently in the process of gathering the results on these 128 datasets, using our own implementations in Keras and would like to compare the accuracy with yours.
Thanks again ;)

I will check this next week. If you look at the code I put a lazy try/except.

Ok, it is NonInvasiveFetalECGThorax1  not FATAL! that was one problem. I had some issues with batch_size=1 and BatchNorm (it is a pytorch issue), so it is fixed now.


not able to install

Hi, I want to try your model in our dataset, but I have not been able to install pointnet2_ops whatshoever. I was wondering if you had a docker image or a complete and functional conda environment that you could share in order to use your method.
Thanks a lot

I have encountered the same problem. Have you solved it

Please follow their repo to install it correctly.


Blog: Bridging OPC UA Data to MQTT with Node-RED

Description

Related Issue(s)

Checklist

[ ] I have read the contribution guidelines
[ ] I have considered the performance impact of these changes
[ ] Suitable unit/system level tests have been added and they pass
[ ] Documentation has been updated

@sumitshinde-84 I am working on this off an on.

@sumitshinde-84 Can you make MQTT In and MQTT Out consistent?  I asked for capitalization, then realized the Pallet on the left side is all lowercase.  Can you make them all lowercase instead and then can we make them bold?  We need to signify it as an action they should take.

We need to signify it as an action they should take.

Done !

Done! I also updated the OPC UA client to OpcUa-Client according to the sidebar palette.


Reframe warnings of diagram check to be constructive

What should we do?
Rephrase warnings to be constructive so that a person who checks a diagram does not just see what cannot be done but how a workaround could look like
Why should we do it?
The conversion tool would be much more helpful

Also in scope is to define a link for each message that points to a helpful information source

With refactoring, the base is laid to change each message individually.
Let's close this and open more specific issues for single messages.


Embeddable  with notify change tracking policy do not update

Changes to embedded objects are not detected when using notify change tracking policy.

That's because changes happen at entity level, not at embeddable level.

¿ Is it posible to use embedded objects and notify change tracking policy simultaneously?

@YaoOcelotl yes, by adding the policy to each entity that uses the embeddable object

¿ Then how do we register the the changes in the embedded object in the parent entity ?

You'd have to do that when calling the API on the entity, not on the embeddable. No way around it, or else just use the implicit tracking strategy.

The following calls do not work:
$listener->propertyChanged($entity, $embeddedPath, $oldEmbeddedClone, $newEmbeddedClone);
$listener->propertyChanged($entity, "{$embeddedPath}.{$property}", $oldValue, $newValue);

I am not sure change tracking policy makes sense, as its too fiddly and there aren't actually performance gains over using deferred explicit. As such I am closing the issue as further research is mood.


Update request: intel-media-driver 23.1.6 → 23.3.5

Package name: 23.1.6
Latest released version: 23.3.5

Current version on the unstable channel: 23.1.6
Current version on the stable/release channel: 23.1.6

[X] Checked the nixpkgs pull requests

I'm noticing a lot of outdated packages in dusty old corners... might be a good idea to make a goal for next year automatic notification of every single package once they are more than a month out of date.
Notify maintainers
@SuperSandro2000

PS: 01.org is gone because Intel, so all links going to there will have to be redirected to wherever intel hid them or swapped for archived versions.

Note for maintainers: Please tag this issue in your PR.

PS: 01.org is gone because Intel, so all links going to there will have to be redirected to wherever intel hid them or swapped for archived versions.

We should probably do a treewide change to fix this. Can you do this?

I mean, you probably know more about where the stuff is hiding now than me...

I mean, you probably know more about where the stuff is hiding now than me...

I actually don't. 😅 I would search like you.

I'm noticing a lot of outdated packages in dusty old corners... might be a good idea to make a goal for next year automatic notification of every single package once they are more than a month out of date.

intel-media-driver is actually quite up to date since I am maintaining it and there is already an auto update bot that I don't know why didn't trigger yet.

FYI #266294

intel-media-driver is actually quite up to date since I am maintaining it and there is already an auto update bot that I don't know why didn't trigger yet.

From https://r.ryantm.com/log/intel-media-driver/2023-11-05.log:

[updateScript] skipping because derivation has no updateScript

[version] generic version rewriter does not support multiple hashes

The actual issue seems to be this because fetchpatch is used and I didn't know this so far which is surprising to me and I think many do not know this.


Numerical robustness of balance_last

The following code fails for me:
let u = [|7.29051884672767705e-28; 7.40891406114041623e-19; 7.8974585653914162e-27;
    6.74931722499952811e-27; 1.96567242595806183e-18; 1.99759418829810833e-09;
    9.00957709439775126e-18; 7.69975469891059e-18; 5.44630568871032146e-27;
    5.53475162082589e-18; 7.14562067029471901e-27; 7.26166281614767e-18;
    3.40581066900184642e-26; 1.76422660684586938e-18; 1.79287696675020245e-09;
    8.08625861896575203e-18; 6.91066930614189608e-18; 9.84019855846523357e-10;
    0.999999958920365861; 4.51021371572784489e-09; 3.85451380633076905e-09;
    5.57697548253416743e-18; 5.6675434090004686e-09; 2.84750345476462241e-17;
    2.43353022074415654e-17; 6.00096499322304467e-18; 6.09841835106380515e-09;
    2.7505171256294709e-17; 2.35064387154075702e-17; 6.62930524914401317e-27;
    6.73696260890209106e-18; 3.03851424471216853e-26; 2.60227107878253518e-26;
    8.19698787626752916e-18; 8.33010379906068e-09; 3.75705500032367818e-17;
    3.21085014652355746e-17; 4.22071117495635736e-26; 4.28925389538807169e-17;
    1.04857628916290599e-25; 8.96133096150629102e-26; 3.89639425302617225e-26;
    3.95967019196240566e-17; 1.31783685040006345e-25; 1.12624825529808348e-25;
    1.2664323265349806e-28; 1.28699869924975191e-19; 5.80463937719803923e-28;
    4.96075441996169876e-28; 7.71899620480556344e-18; 7.84434972714204e-09;
    3.5379695143730131e-17; 3.02361555328812682e-17; 7.34588525560146473e-27;
    7.46517960274637435e-18; 1.49279215819264218e-25; 1.27576836720746576e-25;
    2.33797209106778106e-26; 2.37593985643049289e-17; 1.07159969713535906e-25;
    9.15809335252883654e-26|];;

Owl.Utils.Array.balance_last 1. u;;

with an assertion error on this code:
let balance_last mass x =
  let k = Array.length x - 1 in
  let q = ref mass in
  Array.mapi (fun i a ->
    assert (!q >= 0.);
    if i < k then (
      q := !q -. a;
      a
    )
    else !q
  ) x

Given the numbers, this is obviously due to numerical (im)precision, but I have no idea how one should (could?) fix this. I'm just reporting in case there is something that can be done. I was bitten by this while sampling categorical variables, in the mean time I've just set small values to actual zeros.

For the record, scipy works like the current implementation in owl, see this doc. The code corresponding to balance_last can be found here.
I don't really get why this is a good option, compared to R's implementation. One possibility would be that this is a way to catch numerical difficulties, while renormalizing to 1 would hide it (or add extra imprecision).

The GSL version is the same than R's, and is based on the so-called conditional distribution method in (Davis 1993)
[Davis 1993] The computer generation of multinomial random variates

scipy's interface was chosen to be similar to numpy: scipy/scipy#5410
See the discussion where various people say they're not happy with this convention of discarding the last probability.
The actual PR that introduced the current implementation mentions the above discussion, but keeping on the same track.

And finally, numpy implementation

As I see it, owl's current implementation is very close to the one in the GSL. It computes the sum of input probabilities (norm variable), and it seems to me that it doesn't matter that these sum to 1. Playing with gsl confirms it:
# let rng = Gsl.Rng.make (Gsl.Rng.default ());;
val rng : Gsl.Rng.t = <abstr>
# Gsl.Randist.multinomial rng ~n:100000 ~p:[|1. ; 2.|];;
- : int array = [|33251; 66749|]

This seems very natural to me, and much less confusing and error prone than ignoring the last element of the probability vector.
So in summary, it would be enough to remove the call to balance_last in multinomial_rvs:
let multinomial_rvs n ~p =
  let k = Array.length p in
  let _p = Genarray.create float64 c_layout [|k|] in
  let _s = Genarray.create int32 c_layout [|k|] in
  Owl_utils.Array.balance_last 1. p |>
  Array.iteri (fun i a -> Genarray.set _p [|i|] a);
  _multinomial_rvs ~k ~n ~p:_p _s;
  Array.init k (fun i -> Genarray.get _s [|i|] |> Int32.to_int)

The same is true IMO for the log pdf.


The subs on dubs feature is not working

I've been using your Crunchyroll with better seasons's extension for a long time, but today I noticed that it doesn't work anymore, particularly the subs on dubs feature. Do you know what's happening and how to fix it? The list of subs in dubbed anime is not appearing anymore. I tried it in Brave and Firefox.
The following image shows that the list is not appearing. Dub language: Spanish (Latinamerica),

Thank you for reporting this issue, a fix has been sent in the release v0.7.6


Deprecate py3.8 and deal with action warnings

Why deprecate 3.8? That is still a version in use by older Linux distros I think, let's not make things more complicated for potential users.

Okay, that is true, I was at this repo on other changes and find this from README https://github.com/aiidalab/aiidalab-launch#compatibility.

Interesting. TBH I don't really see a reason why this package should follow NEP 29. This package does not depend on the Python scientific ecosystem (numpy et al). On the contrary, since it is a CLI tool, it's likely to be installed system-wide using Linux distribution Python, that is often lagging behind. So I would simply vote for not following NEP 29.

Yes, agree. I close this PR.


Player favorite surface

In player profile and H2H, can be single surface or combination of surfaces (Fast/Slow/Hard/Soft)

Completed


lib_fdopendir.c:Fix crash in fdopendir caused by fdsan

Summary
Why is this change necessary?
When we enable fdsan and use the fdopendir interface, because we do not update the fdsan tag in the interface, this will cause a PANIC caused by fdsan
Changes
Update fdsan tag in lib_fdopendir.c
#ifdef CONFIG_FDSAN
  android_fdsan_exchange_owner_tag(fd, 0,
    android_fdsan_create_owner_tag(ANDROID_FDSAN_OWNER_TYPE_DIR,
                                   (uintptr_t)dir));
#endif

Impact
Is a new feature added?: NO
Impact on build: NO
Impact on hardware: NO, this change does not specifically target any particular hardware architectures or boards.
Impact on documentation: NO,This patch does not introduce any new features
Impact on compatibility: This implementation aims to be backward compatible. No existing functionality is expected to be broken.
Testing
Build Host(s): Linux x86
Target(s): sim/nsh
We can verify this by using a simple fdopendir demo. and open the CONFIG_FDSAN. After this PR, it will not crash.
#include <stdio.h>
#include <stdlib.h>
#include <dirent.h>
#include <fcntl.h>
#include <unistd.h>

int main() {
    const char *dirpath = "/tmp";

    int dir_fd = open(dirpath, O_RDONLY | O_DIRECTORY);
    if (dir_fd == -1) {
        perror("open");
        return EXIT_FAILURE;
    }

    DIR *dir = fdopendir(dir_fd);
    if (dir == NULL) {
        perror("fdopendir");
        close(dir_fd);
        return EXIT_FAILURE;
    }

    struct dirent *entry;
    while ((entry = readdir(dir)) != NULL) {
        printf("Found: %s\n", entry->d_name);
    }

    if (closedir(dir) == -1) {
        perror("closedir");
        return EXIT_FAILURE;
    }

    return EXIT_SUCCESS;
}

[Experimental Bot, please feedback here]
The PR fulfills the NuttX requirements.
Here's a breakdown:

Summary: The summary clearly explains the bug fix (fdsan PANIC with fdopendir), the code changes made, and its limited scope.
Impact:  Accurately describes the impact as minimal—no new features, hardware dependencies, or build changes. Backward compatibility is maintained. Documentation impact is not mentioned but likely unnecessary for such a focused bug fix.
Testing:  Provides sufficient details:

Host and target environments are specified.
A clear test case is provided, including code and the expected outcome (no crash).
While "before" logs aren't shown, the description implies they would demonstrate the PANIC, which is sufficient in this context.

Minor Suggestions:

Impact - Documentation: Even if no documentation update is needed, stating "NO" explicitly makes it clearer.
Testing - Logs: Consider briefly mentioning the nature of the PANIC observed in the "before" scenario for completeness.

Overall:  The PR is well-structured and provides all the necessary information. The reviewer can easily understand the change, its impact, and how it was validated.


Add source to metadata

Description
This PR makes napari store an image source in layer.metadata['source'] after napari opened the image. (Closes #2033 ). Furthermore, it adds a code eample and a test to show how/that works.
Type of change

[ ] Bug-fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update
I added a code example demonstrating how to access the meta data entry after opening an image.

References
How has this been tested?

[ ] I added a test. Unfortunately, it throws a "Widgets leaked error" on my system. I'm not sure what that means. Let me know how I can improve this or if the test should live in a different place.

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works

I think this is really great, definitely really useful! Is it worth having source as an optional keyword argument in the Viewer.add_* methods too?
I think this is important for those wanting to use napari on top of their projects which already presumably have data shuttling around under the hood which can't be directly opened by the viewer - if people agree I'm happy to add this in

Is it worth having source as an optional keyword argument in the Viewer.add_* methods too?

Great idea, indeed. I thought about that as well and decided against for now, because those methods do have a metadata dictionary parameter, where one could add a source entry.

I left a PR on your PR which would 'promote' source from simply a piece of metadata to a property of all layers settable upon construction, linking here for others to see haesleinhuepf/napari#1

I left a PR on your PR which would 'promote' source from simply a piece of metadata to a property of all layers settable upon construction, linking here for others to see haesleinhuepf#1

Also a good idea. I personally don't have a preference on that aspect. What do others think about this sub-PR? @tlambert03 @sofroniewn

commenting here to keep the discussion in one place...
I'm not sure I like https://github.com/haesleinhuepf/napari/pull/1 as is ... I don't love the v.add_image(skimage.data.astronaut(), source=skimage.data.astronaut) syntax, which requires a lot of duplication from the user.
The primary need for this PR as it currently stands is that it takes something that napari does internally (specifically, taking path in the add_path(path) method and turning it into an Image layer), and leaves a little breadcrumb of what napari did.  https://github.com/haesleinhuepf/napari/pull/1, on the other hand, is just making a place for an end-user to store something that they could very easily have stored elsewhere ("hang on to this function for me would you?" :wink:).  While I don't mind the concept of remembering which function was used to generate the data, I think it would only be appropriate if we actually accepted an image-generating function somewhere... which we don't (the user had to call the function before calling add_image()).  Since we do accept a string path and turn it into image data, that original string should be accessible somewhere.
Whether source is a first-class citizen or not... that feels like something easier to add than it is to remove.  So I'm in favor of the cautious metadata approach in the short term

I see your points and guess it's not really necessary!

Whether source is a first-class citizen or not... that feels like something easier to add than it is to remove. So I'm in favor of the cautious metadata approach in the short term

I'm just wondering before we merge this if we've thought through the consequences of auto-populating the metadata dict like this - which has previously just been for users - and if unexpected things might happen if people do or do not have source already in their metadata dict, or if one day plugins want to provide their own metadata dicts. It does feel like it's bridging two worlds to have napari place things in here automatically, on the other hand without this there is no way to capture the current information.
An alternative I see is that the layer gets a source attribute, but I'm not so sure about that either as most layers won't need this, but it could be None for those. A path attribute makes more sense to me then as we have the kwarg path. "source" is a word we've never used anywhere else in the codebase.

I'm just wondering before we merge this if we've thought through the consequences of auto-populating the metadata dict like this - which has previously just been for users - and if unexpected things might happen if people do or do not have source already in their metadata dict, or if one day plugins want to provide their own metadata dicts.

since @haesleinhuepf  used setdefault, it will only populate source if it doesn't already exist.  it will not overwrite user data.  and since we don't use it anywhere, it's hard to think of unexpected consequences.  It's basically there for a user if they want it (like @haesleinhuepf does), and ignorable/overwrite able if they don't.
The layer.source attribute idea is potentially good too (that's what @alisterburt started to do in https://github.com/haesleinhuepf/napari/pull/1) ... but my thought, mentioned above is that adding that is a bigger commitment that is harder to change in the future.  So we'd want to step back and think longer about that

it's hard to think of unexpected consequences. It's basically there for a user if they want it (like @haesleinhuepf does), and ignorable/overwrite able if they don't.

Say 6 months from now @haesleinhuepf has made a really cool plugin that autogenerates amazing things by looking for source in the metadata, someone else has written an awesome file IO plugin that preserves all the metadata from a file and dumps it into the metadata dict using the source kwarg but for something else that's not compatible with @haesleinhuepf plugin. A third person now wants to use both plugins together and things break :-(
Maybe that's ok or we tell that fileIO plugin developer "source" is a protected key and they should use something else, but I'd prefer to avoid this situation in the first place if possible, and as I see it as pretty likely to happen if we just start putting our own stuff in the metadata dict.
Also, if we do the metadata approach here, I wonder if are we going to add more things or if we're just making a special exception as this is information "lost" by napari? For example #1646 from @Czaki requests source and file path along with some other things like "origin", all of which seem reasonable, but I'm not sure if we should be adding them all too.
Using layer.source as a read only property that we set inside viewer.open and is None otherwise would avoid this. I have similar concerns about API expansion, and I don't love storing file path info on the layer, but I think a read only property might be a better place to start than populating the metadata dict.
We could also make layer.source a read-only dict, or small class/ namedtuple ;-)  with things like filename, plugin_name, that we populate and which could grow to include other stuff (like if a labels layer was created by clicking on a button) over time. This might be my favourite option as it containerizes everything nicely and guarantees we'll be meeting the needs of @haesleinhuepf and others for the long term.
I think the approach from @alisterburt in https://github.com/haesleinhuepf/napari/pull/1 is very exciting, but maybe hinting at a bigger picture vision around what it means for something to be a "computational source" that we're not quite ready to bite off yet.
Another approach would be to put source in metadata dict in our builtin plugin readers. This means that another fileIO plugin would still have complete control over the metadata dict, and the metadata would match exactly what that plugin provided, but I'm not sure if this would really meet the needs of @haesleinhuepf who wants to build something potentially on top of every fileIO plugin - but exactly the reason that makes me lean towards the layer.source approach.
Curious what others think here and if I'm being too pessimistic/ overly cautious!!

When using napari as n-dimensional viewer, then knowing the source of data is not important.
But there was already discussion about change napari in imaging data processing tools (which was already discussed at the European developer meeting) then knowing the source of data is really important. I really do not like the idea of depending on a scientist notebook (the physical one). The best thing will be the possibility to generate a whole calculation graph (like presented here https://napari.zulipchat.com/#narrow/stream/212875-general/topic/node.20editor). But I'm not sure if this should be done in Layer and its subclass. Maybe some additional small class could be used for such a description. Then will be simpler to keep the dependency graph in memory.

@sofroniewn, I agree with pretty much everything in https://github.com/napari/napari/pull/2053#issuecomment-752844879 ... I just saw this as a maybe-not-permanent thing that would help @haesleinhuepf now, and could easily be changed in the future.  I also think a first-class attribute like @alisterburt proposed is a more "stable" fix, but would require some more time to get right (maybe that time is now though?).  I'm pretty sure this "saving of the path" thing has come up before in the past, but I can't find the link at the moment.
I'm not sure I'm yet convinced that source should be an attribute in the Layer.__init__, but perhaps a quick solution here is to just make a layer.source attribute that is set to None, and then @haesleinhuepf can change layer.metadata.setdefault('source', filename) to layer.source = filename?

Just my 2 cents:

Say 6 months from now @haesleinhuepf has made a really cool plugin that autogenerates amazing things by looking for source in the metadata, someone else has written an awesome file IO plugin that preserves all the metadata from a file and dumps it into the metadata dict using the source kwarg but for something else that's not compatible with @haesleinhuepf plugin. A third person now wants to use both plugins together and things break :-(

That appears unfortunate, but reasonable. As we haven't specified a list of mandatory metadata entries (yet), breaking plugins in this context is ok.
Until further notice, plugin developers need to check if specific entries exist in this dictionary before using them.
Another and yet different example: voxel-size: It should exists in metadata (maybe that's the most important metadata anyway) and if it's not there, things may break. That's ok IMHO 🙂

Another and yet different example: voxel-size: It should exists in metadata (maybe that's the most important metadata anyway) and if it's not there, things may break. That's ok IMHO slightly_smiling_face

Why? I first time hear about the mandatory of voxel-size in metadata. Spacing specifies the voxel size. metadata could contain only units.

the mandatory of voxel-size in metadata.

Voxel size is not mandatory. I just used this example to explain what kind of metadata entries could be mandatory. Sorry if I wasn't clear.

the mandatory of voxel-size in metadata.

Voxel size is not mandatory. I just used this example to explain what kind of metadata entries could be mandatory. Sorry if I wasn't clear.

I do not think that any metadata should be mandatory without converting metadata to a custom class instance. Every mandatory thing in such a basic class like Layer should be named property, not an element of dict.

I do not think that any metadata should be mandatory without converting metadata to a custom class instance.

Alright. So what's your opinion, should "source" be a property of Layer?

source should be the property of Layer or of some additional class with a description of a layer.
There are three cases of source:

Data loaded from disc – it could be represented as a simple path (str or Path object).
Output of some method – then knowing method without parameters does not provide useful information for me. So it should contain all information about method parameters. But one of the argument could be a layer which could be later deleted by a user.
User modified layer (shapes, points) – which is a root, but also may bee need to know base on which layer it is created (for me it will be useful when saving a single layer to know which file is labeled)

I think that introducing some method of layer description serialization to really know the source of a layer.

I like the idea of some kind of source class (and agree with @tlambert03 that whatever is added now shouldn't necessarily immediately become a part of the constructor)
@Czaki for you the source seems to be the computational source of the specific data on the layer (with info to serialize it), I was also imagining the source might be useful for layer management. It could be cool if something like "show all layers which have the same dataset_identifier in their source" was possible in a standard way - I might be getting off track and confusing the purpose of source though...

Huh. I'm not sure how the layer properties you refer to differentiate from metadata. If I printed the metadata dictionary and it didn't contain the source of the data [and its voxel size] it would appear incomplete to me.

some additional class with a description of a layer.

This goes pretty much in line with "data that provides information about other data", which is the definition of metadata.

I'm not sure I'm yet convinced that source should be a parameter in the Layer.init signature, but perhaps a quick solution here is to just make a layer.source attribute that is set to None, and then @haesleinhuepf can change layer.metadata.setdefault('source', filename) to layer.source = filename?

@tlambert03 this would probably be my top vote too. An attribute that is set to None by default. We can then figure out longer term solution with time and easily add a deprecation warning if that changes etc. One option would be to make it a property with no setter and have a private _source that we set inside our _add_path_with_plugins method, so layer._source = filename. This would make layer.source "read only" from the user perspective, which I think is fine for now too.

Huh. I'm not sure how the layer properties you refer to differentiate from metadata. If I printed the metadata dictionary and it didn't contain the source of the data [and its voxel size] it would appear incomplete to me.

I think there might be some understandable confusion about how we've referred to layer.metadata vs other layer attributes or named properties. Things so fundamental that they are always needed for viewing the data, such as voxel size have been stored on the layer directly. You should be able to access that right now with layer.scale (though that is in someways overloaded as it could include both a voxel-size and an affine transform component so it's maybe not quite right, but curious if that meets your voxel size needs). (Similarly we have layer.colormap, layer.contrast_limits etc all as attributes directly on the layer).
Right now we have a private method layer._get_state() that will put all this stuff in a dictionary that might be more akin to the full "metadata" that you're imagining. layer.metadata has always just been free "user space" that is in addition to this other information, and so maybe isn't the best named. We'll be aiming to clean this up soon though so there is a public way to get this dictionary too, see #1636. Does this make it more clear @haesleinhuepf?

Alrigt. That interestingly also brings us back to where our discussion started.

Alrigt. That interestingly also brings us back to where our discussion started.

Lol, I think we're making progress!! I just left some additional comments :-)

Bumped milestone to 0.4.3 - we should be able to get this in for next release!

Maybe modify io plugin mechanism to check if source is set and if no then set to the path used to load data.

i think every array has some location -- an address in memory, a path on the local file system, a path on the cloud. are there any exceptions to this? if not, then i would consider using a URL-style for the source like file://foo/bar.tiff, memory://<memory_address>, s3://foo/bar etc

The memory address is a bad idea. It may be easily invalidated. It also does not contain metadata which is the most important part when we think about semantic meaning.

I just implemented @sofroniewn's suggestion with the private _source attribute and the public/read-only source property. I also agree with @tlambert03: Let's see how this works in practice, before we engineer it further towards practical use-cases.

The memory address is a bad idea. It may be easily invalidated.

Any path can be invalidated, even ones on the filesystem.

It also does not contain metadata which is the most important part when we think about semantic meaning.

Sure, the path to data is just one part of the set of metadata. My point is just that if napari keeps track of the path / location / origin for data loaded from disk, it should also keep track of the path / location / origin (or something sufficiently path-like) for all other sources of data.

My point is just that if napari keeps track of the path / location / origin for data loaded from disk, it should also keep track of the path / location / origin (or something sufficiently path-like) for all other sources of data.

We can grow this over time depending on what people request/ need. I think it's ok to get a first version of this in without, but I like the idea too!!

Sure, the path to data is just one part of the set of metadata. My point is just that if napari keeps track of the path / location / origin for data loaded from disk, it should also keep track of the path / location / origin (or something sufficiently path-like) for all other sources of data.

If you keep only memory address it is worthless. Data could be dask where you dynamically load and dump data on the drive. Could be NumPy array, which may not be continuous in memory. And we do not talk about data type (np.uint8, np.uint16, np.int16). Memory pointer without information on how to read it is worthless.  Encoding such data in the string is asking for a problem for me.

Disc or network location is much stable than in memory. Also often the path to file or file itself contains data that allows for semantic understanding of data.
Also much better is to have information that layer_c is calculated base on layer_a (which is loaded from file_a) and layer_b (loaded from file_b). than layer_c is calculate base on pointer_a and pointer_b.

so then maybe the conclusion is that for in-memory data napari should give up and put None for the source? That seems fine as long as consumers of the source field know what that means.

I'm not super-convinced about adding a new attribute to the layers to be honest... At least, it should be in experimental, or discussed in one or more group meetings, or both. I see your point @sofroniewn about conflicting metadata specs, but I also share @tlambert03's concern that fiddling with that dictionary is much less risky, from a user-space perspective, than fiddling with attributes in the base layer. (Sorry to have jumped in late after all this discussion has already happened.)
In short, if we're not ok with the dictionary approach (again, I see the issues), I'd like us to take some time to think about this and not include an API expansion in the next release. @haesleinhuepf I think for your immediate use case, you can use the dictionary in user-space as suggested by @sofroniewn?

I'm not super-convinced about adding a new attribute to the layers to be honest... At least, it should be in experimental, or discussed in one or more group meetings, or both. I see your point @sofroniewn about conflicting metadata specs, but I also share @tlambert03's concern that fiddling with that dictionary is much less risky, from a user-space perspective, than fiddling with attributes in the base layer. (Sorry to have jumped in late after all this discussion has already happened.)
In short, if we're not ok with the dictionary approach (again, I see the issues), I'd like us to take some time to think about this and not include an API expansion in the next release. @haesleinhuepf I think for your immediate use case, you can use the dictionary in user-space as suggested by @sofroniewn?

I vote only for parameters if it will be mandatory element. If all coda need to assume that this key may be missed I'm OK with putting it in dict.

I vote only for parameters if it will be mandatory element. If all coda need to assume that this key may be missed I'm OK with putting it in dict.

I think for your immediate use case, you can use the dictionary in user-space as suggested by @sofroniewn?

Yes. I am already using this. No hurry from my side.
I would also vote for keeping layer properties in a metadata dictionary if they are not necessary for core-functionality of napari.

I think for your immediate use case, you can use the dictionary in user-space as suggested by @sofroniewn?

Yes. I am already using this. No hurry from my side.
I would also vote for keeping layer properties in a metadata dictionary if they are not necessary for core-functionality of napari.

Ok, I've bumped this to 0.4.4 Let's discuss in a couple team upcoming meetings. Thanks all for their input and patience!

Ok, I've bumped this to 0.4.4 Let's discuss in a couple team upcoming meetings. Thanks all for their input and patience!

I'd like to pick this up again.  See long thread in zulip (but mostly this post).  Basically, the unfortunate situation at the moment is that, when someone (like a plugin) wants to evaluate a layer in the viewer, they basically have no idea about the layer provenance (they don't know the file name or extension, they don't know which plugin loaded it, etc... ).  Given that we also don't have a metadata model in napari, that pretty much leaves them in the dark.
From the looks of it, the reason this effort stalled is @jni's https://github.com/napari/napari/pull/2053#issuecomment-753242516 about the API.   So let's pick it up again and discuss the API.  I would propose that we add one new public read-only attribute to Layer called layer.source, or layer.provenance ...  It should minimally have the path (if relevant), but preferably be expandable, so perhaps a frozen dataclass?
@dataclass(frozen=True)
class Source:
    path: Optional[str]  # if `viewer.open` was used
    method: Optional[MethodType]  # could be a pointer to `viewer.open`, or `viewer.add_image`
    hookimpl: Optional[HookImplementation]  # all the necessary plugin info
    plugin_name: Optional[str]  # contained in hookimpl, but could add here too?

and then napari can internally populate layer._source depending on the load method.  I'm happy to push this through once we agree on an API.  @jni, @sofroniewn

I'm happy to pick up this thread again, that exchange in zulip was a good motivator.
I like the public readonly layer.source with source also a kwarg to the layer init. It would also be something that a reader plugin could provide. One thing to note with readonly is that we might run into this problem if we don't have a setter and a magicgui widget wants to update the source in place - see https://github.com/napari/napari/pull/2507#issuecomment-813676702. So maybe having a setter is ok and we eventually use our concept of locked/ frozen #1570 to prevent editing.

It should minimally have the path (if relevant), but preferably be expandable, so perhaps a frozen dataclass?

I like this! With those attributes as well. My comment from above might apply too though about allowing it to be editable in the case of a layer that updates in place. Maybe then the whole source object needs to be set new though?
Overall though I like this general direction and think it will add a lot of value

I like the public readonly layer.source with source also a kwarg to the layer init. It would also be something that a reader plugin could provide.

Actually... I was thinking this should start as something that doesn't have an __init__ kwarg, and couldn't be modified by plugins. part of the whole problem here started with the "unknown" that is plugins.  So this is something that we can, for now at least, strictly regulate to say something about the provenance of data.
and yeah, if layer._source needed to be changed, we internally would create a new Source() object and replace the old one

Actually... I was thinking this should start as something that doesn't have an init kwarg, and couldn't be modified by plugins. part of the whole problem here started with the "unknown" that is plugins. So this is something that we can, for now at least, strictly regulate to say something about the provenance of data.

lol! ok nice, I'm remembering this now - we would auto-populate this stuff based on where the data came from, like we currently do in this PR with layer._source = filename.
We could expand that to have those other attributes, but we as napari would set that, not a plugin/ or user. (Another one I thought of is a drag_and_drop bool, that we'd set to be True if the data came in via drag and drop).
I like this approach, much better than having kwargs/ or setter.
I guess from my perspective then the only remaining question is should source just be that path or the frozen dataclass, and if dataclass what are the attributes? I like the dataclass idea, and like the ones you listed!!

This has been superseded by #2518. Excited to see what comes next!!


Uncaught SyntaxError: Unexpected token <

If you are reporting a bug, please fill in below. Otherwise feel free to remove this template entirely.
### Can you reproduce the problem with latest npm?
Yes.
Can you still reproduce it?
Yes.
### Description
What are you reporting?
I am trying to render a create-react-app build folder using express. If I run it via localhost, it works fine, no problem. However, when I try to render it via my web server (Windows Server 2008, IIS, with iisNode), I get an error saying "Uncaught SyntaxError: Unexpected token <". This comes from the main.8b788f8.js file within the build/static/js folder.
Expected behavior
Tell us what you think should happen.
The express script should render the index.html page from the build folder with no issues.
Actual behavior
Tell us what actually happens.
Nothing is displayed at the web URL. There is one error within the console, stating the following:

main.8b78c8f8.js:1 Uncaught SyntaxError: Unexpected token <

Environment
Run these commands in the project folder and fill in their results:

npm ls react-scripts (if you haven’t ejected): react-scripts @0.9.3
node -v: v6.9.5
npm -v: 3.10.10

Then, specify:

Operating system: Windows Server 2008
Browser and version: Google Chrome, Version 57.0.2987.98 (64-bit)

Reproducible Demo
Please take the time to create a new app that reproduces the issue.
Alternatively, you could copy your app that experiences the problem and start removing things until you’re left with the minimal reproducible demo.
(Accidentally, you might get to the root of your problem during that process.)
Push to GitHub and paste the link here.
By doing this, you're helping the Create React App contributors a big time!
Demonstrable issues gets fixed faster.

Could you provide a demo reproducing this, please? I use CRA at work (with IIS) and don't run into this issue.

The error message says that instead of serving JS, you are serving the HTML file. You can look at build folder and verify that JS is really JS. Therefore, the problem is with how your web server is configured. You should make sure /static/js/main.8b78c8f8.js really serves the JS file, and not something else.

Hey, I added a demo that reproduces this issue.
https://github.com/AndehWong/counselling
But, I am going to try to serve it with pushstate-server and see if the problem is solved that way.

What are the steps to reproduce the problem?
Since you're using a different server, it’s probably a problem on that side rather than in that repo.

In which port that the production express app is running?
You are using homepage with a pathname, does the express server running on that url? Right now https://sscsecure.uwo.ca/counselling/triage/static/js/main.8b78c8f8.js is serving an html error.
If the express is running on different port than 80, the homepage field should also include the port in there.
I agree that we need more information about the setup. or a (non) working demo of the deployed app on that url.

I had my express running on port 3001, I switched it to port 80 and it still serves up the same issue.
I apologize if I can't provide a demo that has the same issue. As gaearon states, it is a server side issue, but I just don't know why express is deciding to serve up the HTML file rather than the static JS file.
I tried using pushstate-server, and it works fine from there. If I take the build folder, and copy all the build folder contents into the server directory, the application displays fine. It's only when I try to serve it up with express that it runs into issues.
I set up the "homepage" field to url/counselling/triage, as well as included iisnode into my web.config to ensure that iis knows that I am trying to run a node.js application.
If this is more of an IIS/Expressjs issue, then I understand it's outside of what you can help me with, but if it's something related to create-react-app, then any help would be great.

This is purely a configuration issue with your web server application.
Are you using WebAPI, MVC, or .NET Core?

Very sure that it is .NET Core.

What is your express code looking like?

https://github.com/AndehWong/counselling/blob/master/server.js
This is what I used for my expressjs server code as of yesterday. The only change I made was the port to 80, but that did not change anything.

Whoops, sorry. I didn't see that you said you were serving this with express.
I suspect this is causing it.
Here's a snippet from what I use which should be adaptable to your needs:
const path = require('path')
let root = path.join(__dirname, '..', 'build/')
app.use(express.static(root))
app.use(function(req, res, next) {
  if (req.method === 'GET' && req.accepts('html') && !req.is('json') && !req.path.includes('.')) {
    res.sendFile('index.html', { root })
  } else next()
})

OK, I just realized you had the server in there 😄
I can reproduce now.
The problem is that per your homepage setting, the project is built to be served from /counselling/triage/. However you’re serving it from /. So the paths to static files end up wrong.
This is noted in the build output:

It works if I apply this fix:
- app.use(express.static(path.join(__dirname, '/build')));
+ app.use('/counselling/triage/', express.static(path.join(__dirname, '/build')));

and then open http://localhost:3001/counselling/triage/.

Ahhh thank you gaearon! That as indeed the fix. Thank you everyone for having patience with me. I am very new to expressjs, this is my first time running a website using it.
I cannot express my gratitudes enough, thank you! :)

Glad it's working! Let us know if you need anything else.

I'm facing this exact same issue with pushstate-server.


Added prefix append

Prefixes will now append as well when you append your loaded models
Includes style changes (previously saved but uncommitted)

oh excuse me i will highlight the changes

Added fix that prevents preview from appearing in Firefox

no nothing else is changed, i found it strange it worked in chrome to

The last commit is too much of a diff-wall. Can't easily see the change.


TypeError: undefined is not an object (evaluating 'this._conversationsPromise.then')

We get a lot of errors that this._conversationsPromise is undefined when trying to call getSubscribedConversations on a channel. Let's take a look at getSubscribedConversations:
async getSubscribedConversations() {
    await this._ensureReady;
    return this._conversationsPromise.then((conversations) => conversations.getConversations());
}

Let's look how _ensureReady is defined in client.js of @twilio/conversations
this._ensureReady = new Promise((resolve, reject) => {
    this._resolveEnsureReady = resolve;
    this._rejectEnsureReady = reject;
 }).catch(() => void 0); // @todo How to process unhandled rejection here?

Well, it seems that there is a bug here and await this._ensureReady will never throw because you swallowed the error. Since you swallowed the error we get to the next line return this._conversationsPromise.... But we can't be sure that _conversationsPromise was set.
You should remove that catch on _ensureReady in Client constructor. At least users or your library would get the original error.

When you remove the catch, what is the error you get?

Also I think you should reset _ensureReady when disconnecting. I mean set _ensureReady to new Promise(... again

When you remove the catch, what is the error you get?

Didn't try yet but I suspect it is some connectivity error

Yep, ok, I will take a look at that part, thank you for reporting this!

Waiting for this fix


Error during training

I am working on a study of vertebral morphology and wanted to explore using this code to understand how osteophytes effect morphology metrics.
I go the code running - up to a point.
After the first block of iterations, it runs inference on the test set, and the inference runs on all 2077 images, but then crashes with the error messages below. Is there a fix for this? To get the code to work, detectron was cloned from facebookresearch and installed from the local clone.
Thanks
Traceback (most recent call last):
File "/SSD1/detectron2/detectron2/engine/train_loop.py", line 150, in train
self.after_step()
File "/SSD1/detectron2/detectron2/engine/train_loop.py", line 180, in after_step
h.after_step()
File "/SSD1/detectron2/detectron2/engine/hooks.py", line 555, in after_step
self._do_eval()
File "/SSD1/detectron2/detectron2/engine/hooks.py", line 528, in _do_eval
results = self._func()
File "/SSD1/detectron2/detectron2/engine/defaults.py", line 453, in test_and_save_results
self._last_eval_results = self.test(self.cfg, self.model)
File "/SSD1/detectron2/detectron2/engine/defaults.py", line 617, in test
results_i = inference_on_dataset(model, data_loader, evaluator)
File "/SSD1/detectron2/detectron2/evaluation/evaluator.py", line 204, in inference_on_dataset
results = evaluator.evaluate()
File "/SSD1/detectron2/detectron2/evaluation/coco_evaluation.py", line 206, in evaluate
self._eval_predictions(predictions, img_ids=img_ids)
TypeError: _eval_predictions() missing 1 required positional argument: 'predictions'

Sorry, I have encountered the same problem. Have you solved this problem?

I encountered the same too, has anyone figured out the solution?

This is because _eval_predictions in coco_evaluation.py has the same function name as coco_evaluator.py
Change the name of _eval_predictions in coco_evaluation and you will be fine.
Another thing, in sparsernn.yaml. You need to change the last 3 lines:
TEST:
EVAL_PERIOD: 500
VIS_PERIOD: 500
To 50000 Iterations or else it would finish at 500


Update json4s-core, json4s-native to 3.6.8

Updates

org.json4s:json4s-core
org.json4s:json4s-native

from 3.6.7 to 3.6.8.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

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

labels: library-update, semver-patch

Superseded by #155.


"Applies the latest Windows Server 2016 cumulative update to the new VHD ..."

Actually, it doesn't.  It applies the October 2017 cumulative update.  If you want the latest, you need to download it and use CUPath.  Shame.  I thought that I'd found a good way of getting the latest patches automatically, but this is not it.

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

ID: 2d5d4c0e-0054-452c-ac27-03e4c5731655
Version Independent ID: 974bb09d-9697-4e2b-e364-37c3bddb3a57
Content: Add the default VM image to the Azure Stack Marketplace | Microsoft Docs
Content Source: articles/azure-stack/azure-stack-add-default-image.md
Service: azure-stack
GitHub Login: @mattbriggs
Microsoft Alias: mabrigg

@jrp2014  - Thanks for the feedback. We are actively investigating and will get back to you.

@jrp2014 thanks for pointing this out. I have assigned the issue to the content author to review and update the doc as needed.
@mattbriggs can you please take a look and see if the instructions are still valid?

Thanks.  As a test, using only the instructions here, try walking through an ADFS deployment out of the box, run the CanaryValidation test (which will require you to remote powershell to a particular VM, to retrieve a piece of data) and spin up a VM (using the right one of AzureStackAdmin, CloudAdmin, TenantUserAdmin, Tenant, ..., in all the right places).  The AzureStack PowerShell tools themselves could do with a makeover: the cumulative updates for Windows Server are for October 2017, eg.  The whole setup for initialising your Powershell environment is a bit fragile (do we need the GraphAudience parameter or not: some of the documentation includes it, the Powershell tools documentation, not so much).  Why not write the settings into a config scripts (hash table) and get the scripts to initialise themselves?

@jrp2014 Thanks for your insight. I've passed your comment along to the technical owners of the Azure Stack PowerShell Tools. The tools are in the process of being updated, and I'm working on the PowerShell docs so your note that "the whole setup for initializing your Powershell environment is a bit fragile" is very helpful. Thanks! Matt #please-close


how to disable the swipe gesture?

is there a way to disable a gesture that detects the swipe? It just overlaps the tableview delete swipe.
Or is there a way so that both can persist together?

With new version you can simply delete panGesture. If you want the restore pan gesture, just call method setupPanGesture().

@vuevrn Were you able to solve your issue?

@alkhokhlov How can I delete the pan gesture?


Superscripts and the height of bullets in unordered lists in PDF output

Describe the issue
When the first line of an unordered list contains a superscript, the bullets are placed higher in the PDF output. For example, the bullets for the list in Section 3.1 of RFC 9616 are higher than the ones in Section 4 in the PDF. The bullet heights are fine in the HTML output.
https://www.rfc-editor.org/rfc/rfc9616.pdf
If the list has superscripts but they are not in the first bullet item, then the placement of the bullets is okay. For example, See Section 5.2.1 of RFC 9429.
https://www.rfc-editor.org/rfc/rfc9429.pdf
The RPC does not consider this a blocking issue.
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

This seems to be an WeasyPrint issue. See https://github.com/Kozea/WeasyPrint/issues/2253

List items with subscript in firs line in an ordered list will suffer from the same issue.

The proposed fix (#1165) generates the following output:
Note that this also fixes line height weirdness when the subscript is in one of the middle lines.
Section 3.1 of RFC 9616

Section 5.2.1 of RFC 9429

Maybe the line height should be set to 0 for the whole document not just li elements.
See Section Section 4.1 in RFC9591:

There is a line height issue when sup elements are present.

I'm good with proposed fix (https://github.com/ietf-tools/xml2rfc/pull/1165)


bugfix: fix mtype duplication in examples/synthesis_json.py

Current coverage is 100.00%

Merging #124 into master will not affect coverage as of 7641020

@@            master    #124   diff @@
======================================
  Files           30      30
  Stmts          988     988
  Branches         0       0
  Methods
======================================
  Hit            988     988
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of 7641020

Powered by Codecov. Updated on successful CI builds.


Moving to sonatype

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Coverage remained the same at 98.901% when pulling cb7edabfcfc88f684dcc3e7ded8310eed1f7fa47 on sonatype into db05a2606789ac20be0f7e6420e959247abb372e on master.


[Bug]: Task-Comprehensive Specimen Digitization: error messages at Attributes panel

Steps to reproduce the bug
1. CSD
2. added namespace, catalog number, repository, preparation
3. click "save" for rest of options
4. add anything into "Attributes" or "Custom Attributes" panel and got error message - see screenshot
...
@bpescador, @chrisgrinter, @rich-keller, @AntWeb-org

Screenshot

Expected behavior
No response
Additional Screenshots
No response
Environment
Sandbox
Sandbox Used
No response
Version
build 9d09fc80ad59 on 2023-03-01T03:51:11Z
Browser Used
chrome Version 110.0.5481.178

Thanks! Fixed.  Will be resolved next unified release


Optimize multiple crops

Update CroppedProjectiveTranform to optimize projective transforms followed by multiple crops, not just one crop. For instance:
Rotate(10) |> CenterCrop((100, 100)) |> RandomCrop((50, 50))

Is now optimized to warp only into the 50x50 region, instead of to the 100x100 region.
One caveat of this implementation is that crops that enlarge the region after a smaller crop will be different due to extrapolation of the smaller crop being skipped. ie this will give different results now:
Rotate(10) |> CenterCrop((50, 50)) |> RandomCrop((100, 100))

I wonder if enlarging crops should be disallowed anyways, since offsetcropbounds doesn't appear to be written with it in mind (ie sz>bounds), unless I am missing something. Thoughts?
PR Checklist

[x] Tests are added
[ ] Documentation, if applicable

I wonder if enlarging crops should be disallowed anyways, since offsetcropbounds doesn't appear to be written with it in mind (ie sz>bounds), unless I am missing something.

How do other frameworks like torchvision handle enlarging the crops?

Tochvision throws a ValueError if the crop is larger than the input image
In [1]: from torchvision.transforms import v2
   ...: from torchvision.io import read_image
   ...:
   ...: img = read_image( 'astronaut.jpg')
   ...: print(f"{img.shape = }")
img.shape = torch.Size([3, 512, 512])

In [2]: transform = v2.RandomCrop(size=(100, 100))
   ...: out = transform(img)

In [3]: print(f"{out.shape = }")
out.shape = torch.Size([3, 100, 100])

In [4]: transform = v2.RandomCrop(size=(1000, 1000))
   ...: out = transform(img)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[4], line 2
      1 transform = v2.RandomCrop(size=(1000, 1000))
----> 2 out = transform(img)

File /usr/local/lib/python3.11/dist-packages/torch/nn/modules/module.py:1553, in Module._wrapped_call_impl(self, *args, **kwargs)
   1551     return self._compiled_call_impl(*args, **kwargs)  # type: ignore[misc]
   1552 else:
-> 1553     return self._call_impl(*args, **kwargs)

File /usr/local/lib/python3.11/dist-packages/torch/nn/modules/module.py:1562, in Module._call_impl(self, *args, **kwargs)
   1557 # If we don't have any hooks, we want to skip the rest of the logic in
   1558 # this function, and just call forward.
   1559 if not (self._backward_hooks or self._backward_pre_hooks or self._forward_hooks or self._forward_pre_hooks
   1560         or _global_backward_pre_hooks or _global_backward_hooks
   1561         or _global_forward_hooks or _global_forward_pre_hooks):
-> 1562     return forward_call(*args, **kwargs)
   1564 try:
   1565     result = None

File /usr/local/lib/python3.11/dist-packages/torchvision/transforms/v2/_transform.py:46, in Transform.forward(self, *inputs)
     43 self._check_inputs(flat_inputs)
     45 needs_transform_list = self._needs_transform_list(flat_inputs)
---> 46 params = self._get_params(
     47     [inpt for (inpt, needs_transform) in zip(flat_inputs, needs_transform_list) if needs_transform]
     48 )
     50 flat_outputs = [
     51     self._transform(inpt, params) if needs_transform else inpt
     52     for (inpt, needs_transform) in zip(flat_inputs, needs_transform_list)
     53 ]
     55 return tree_unflatten(flat_outputs, spec)

File /usr/local/lib/python3.11/dist-packages/torchvision/transforms/v2/_geometry.py:870, in RandomCrop._get_params(self, flat_inputs)
    867         padded_width += 2 * diff
    869 if padded_height < cropped_height or padded_width < cropped_width:
--> 870     raise ValueError(
    871         f"Required crop size {(cropped_height, cropped_width)} is larger than "
    872         f"{'padded ' if self.padding is not None else ''}input image size {(padded_height, padded_width)}."
    873     )
    875 # We need a different order here than we have in self.padding since this padding will be parsed again in `F.pad`
    876 padding = [pad_left, pad_top, pad_right, pad_bottom]

ValueError: Required crop size (1000, 1000) is larger than input image size (512, 512).

You can pass pad_if_needed=True to the crop, but that isn't the default behavior

we could error as well, but I'll leave you the decision to choose the most sensible behavior

you can merge if you want. please tag a new release after

you can merge if you want. please tag a new release after

I am going to add an error when the crop size is larger than the input size. Should be a quick change.
Is there a release process to follow? From what I can tell, it is:

checkout master
update version in Project.toml
git commit ...
git tag ...
push commit and tag directly to master on Github

Anything else?

Ok, I'll merge this. Throwing an error is going to require additional changes that I'll put in a separate PR.


K3s fails to start with a flannel crash when using a ppp0 modem interface.

Environmental Info:
K3s Version: v1.20.2+k3s1 (1d4adb03)
Go version: go1.15.5

Node(s) CPU architecture, OS, and Version:
Linux ws-nxcore-000048B02D0766CD 4.9.140-tegra #1 SMP PREEMPT Thu Jun 17 21:46:37 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

Cluster Configuration: 1 server

Describe the bug:
I0624 23:06:59.293981   24938 flannel.go:92] Determining IP address of default interface
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1a31f90]

goroutine 20887 [running]:
github.com/rancher/k3s/vendor/github.com/vishvananda/netlink.parseAddr(0x400648bdec, 0x40, 0x40, 0x0, 0x400867a0a8, 0x4, 0x280, 0x0, 0x0, 0x400648be00, ...)
        /go/src/github.com/rancher/k3s/vendor/github.com/vishvananda/netlink/addr_linux.go:274 +0x170
github.com/rancher/k3s/vendor/github.com/vishvananda/netlink.(*Handle).AddrList(0x6721590, 0x43eff40, 0x400f0859e0, 0x2, 0x0, 0x4, 0x2bc, 0xfe, 0x1)
        /go/src/github.com/rancher/k3s/vendor/github.com/vishvananda/netlink/addr_linux.go:199 +0x180
github.com/rancher/k3s/vendor/github.com/vishvananda/netlink.AddrList(...)
        /go/src/github.com/rancher/k3s/vendor/github.com/vishvananda/netlink/addr_linux.go:174
github.com/rancher/k3s/vendor/github.com/coreos/flannel/pkg/ip.getIfaceAddrs(0x400e1e22c0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/rancher/k3s/vendor/github.com/coreos/flannel/pkg/ip/iface.go:36 +0x68
github.com/rancher/k3s/vendor/github.com/coreos/flannel/pkg/ip.GetIfaceIP4Addr(0x400e1e22c0, 0x0, 0x0, 0x400775ee08, 0x1, 0x1)
        /go/src/github.com/rancher/k3s/vendor/github.com/coreos/flannel/pkg/ip/iface.go:40 +0x30
github.com/rancher/k3s/pkg/agent/flannel.LookupExtIface(0x400e1e22c0, 0x75ff34, 0x400cd82f08, 0x75f90c)
        /go/src/github.com/rancher/k3s/pkg/agent/flannel/flannel.go:100 +0xa8
github.com/rancher/k3s/pkg/agent/flannel.flannel(0x444d740, 0x4000e58c00, 0x0, 0x4006a5dd40, 0x34, 0x400b2e43f0, 0x2d, 0x1, 0x0)
        /go/src/github.com/rancher/k3s/pkg/agent/flannel/flannel.go:43 +0x28
github.com/rancher/k3s/pkg/agent/flannel.Run.func1(0x444d740, 0x4000e58c00, 0x4005df4380)
        /go/src/github.com/rancher/k3s/pkg/agent/flannel/setup.go:98 +0x5c
created by github.com/rancher/k3s/pkg/agent/flannel.Run
        /go/src/github.com/rancher/k3s/pkg/agent/flannel/setup.go:97 +0x290

The above panic occurs when starting k3s with a ppp0 interface modem connected to the system.

Steps To Reproduce:

Installed K3s: curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.20.2+k3s1 INSTALL_K3S_SKIP_ENABLE=true K3S_CLUSTER_SECRET=<deprecated> sh -

Attach modem to USB port and wait for it to enumerate (have no other internet uplink interfaces)
start k3s: /usr/local/bin/k3s server --disable=traefik

Expected behavior:
It is expected that flannel not panic and k3s to start.

Actual behavior:
Flannel panics causing k3s server to fail to start.

Additional context / logs:
Looking at the code (https://github.com/k3s-io/k3s/blob/v1.20.2+k3s1/vendor/github.com/vishvananda/netlink/addr_linux.go#L274) it looks as if dst is null due to the  unix.IFA_ADDRESS case (https://github.com/k3s-io/k3s/blob/v1.20.2+k3s1/vendor/github.com/vishvananda/netlink/addr_linux.go#L237) not being reached.
IP routing table information
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<IP_ADDRESS>         <IP_ADDRESS>         <IP_ADDRESS>         U     700    0        0 ppp0
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     101    0        0 lan0
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>     U     0      0        0 docker0

ip a
...
9: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 70:88:6b:82:d1:53 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global noprefixroute lan0
       valid_lft forever preferred_lft forever
32: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 3
    link/ppp
    inet <IP_ADDRESS>/32 brd <IP_ADDRESS> scope global noprefixroute ppp0
       valid_lft forever preferred_lft foreve

^ filtered to only include the interfaces that matter
k3s log: k3s_flannel_crash_min.txt

It looks like this would require a fix upstream at https://github.com/vishvananda/netlink - are you able to open a PR?

Hey @brandond.  Yes I can open an issue against https://github.com/vishvananda/netlink but wasn't exactly sure what you meant by open a PR (pull request)?  I assume that once the fix is issued in https://github.com/vishvananda/netlink to open a PR here to update the netlink module.

The proposed solution https://github.com/vishvananda/netlink/pull/665 does address the immediate panic but it was later discovered that lacking an IFA_ADDRESS (which can be easily seen using https://github.com/Yourens/rtnetlinkexample/blob/master/if_show.c) results in other downstream problems.
Jun 29 21:16:36 ws-nxcore-000048B02D0766CD bash[4543]: E0629 21:16:36.736218    4543 remote_runtime.go:116] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed to setup network for sandbox "c246d0f2899b3a6c0e83c2e03fafcebbd5ada9eb54f349c970142127624fb83a": netplugin failed with no error message
Jun 29 21:16:36 ws-nxcore-000048B02D0766CD bash[4543]: E0629 21:16:36.739284    4543 kuberuntime_sandbox.go:70] CreatePodSandbox for pod "coredns-854c77959c-8p7nv_kube-system(0295c50f-8c65-42ef-964e-b97cee322658)" failed: rpc error: code = Unknown desc = failed to setup network for sandbox "c246d0f2899b3a6c0e83c2e03fafcebbd5ada9eb54f349c970142127624fb83a": netplugin failed with no error message
Jun 29 21:16:36 ws-nxcore-000048B02D0766CD bash[4543]: E0629 21:16:36.739356    4543 kuberuntime_manager.go:755] createPodSandbox for pod "coredns-854c77959c-8p7nv_kube-system(0295c50f-8c65-42ef-964e-b97cee322658)" failed: rpc error: code = Unknown desc = failed to setup network for sandbox "c246d0f2899b3a6c0e83c2e03fafcebbd5ada9eb54f349c970142127624fb83a": netplugin failed with no error message
Jun 29 21:16:36 ws-nxcore-000048B02D0766CD bash[4543]: E0629 21:16:36.739554    4543 pod_workers.go:191] Error syncing pod 0295c50f-8c65-42ef-964e-b97cee322658 ("coredns-854c77959c-8p7nv_kube-system(0295c50f-8c65-42ef-964e-b97cee322658)"), skipping: failed to "CreatePodSandbox" for "coredns-854c77959c-8p7nv_kube-system(0295c50f-8c65-42ef-964e-b97cee322658)" with CreatePodSandboxError: "CreatePodSandbox for pod \"coredns-854c77959c-8p7nv_kube-system(0295c50f-8c65-42ef-964e-b97cee322658)\" failed: rpc error: code = Unknown desc = failed to setup network for sandbox \"c246d0f2899b3a6c0e83c2e03fafcebbd5ada9eb54f349c970142127624fb83a\": netplugin failed with no error message"

Can you work around this by adding a dummy ethernet interface with a static IP?

If the ppp interface exists in the system at all the issue persists.  The only way I was able to work-around this issue was with the following:
/etc/ppp/ip-up.d/01ipfix
#!/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin
METRIC=700

ip addr del $4 dev $1
ip addr add $4 broadcast $4 dev $1
route add default gw $4 metric $METRIC

Closing due to age


Medplum ValueSets

We currently have a handful of current and proposed Medplum fields that would benefit from ValueSets.  ValueSets would help with user experience (for example, autocomplete values and validation).
Medplum fields that could use ValueSets

Project.features - bots, email
Bot.runtimeVersion - awslambda, vmcontext
Bot.category - ?
Bot.auditEventTrigger - always, never, error, output
Bot.auditEventTarget - log, resource, both
Login.authMethod - password, google, external
Login.codeChallengeMethod - plain,
AccessPolicy.ipAccessRule.action - block, allow
BulkDataExport.status - active, error, completed
AsyncJob.status - active, error, completed

We should create these in a new file "packages/definitions/dist/fhir/r4/valuesets-medplum.json", which sits next to the FHIR "valuesets.json".
We should update the createValueSets() method in "packages/server/src/seeds/valuesets.ts" to use this new file.
Example binding syntax (on the ElementDefinition):
          "binding" : {
            "strength" : "required",
            "description" : "The gender of a person used for administrative purposes.",
            "valueSet" : "http://hl7.org/fhir/ValueSet/administrative-gender|4.0.1"
          },

Example CodeSystem:
  {
    "fullUrl" : "http://hl7.org/fhir/CodeSystem/administrative-gender",
    "resource" : {
      "resourceType" : "CodeSystem",
      "id" : "administrative-gender",
      "url" : "http://hl7.org/fhir/administrative-gender",
      "version" : "4.0.1",
      "name" : "AdministrativeGender",
      "title" : "AdministrativeGender",
      "status" : "active",
      "experimental" : false,
      "date" : "2019-11-01T09:29:23+11:00",
      "description" : "The gender of a person used for administrative purposes.",
      "caseSensitive" : true,
      "valueSet" : "http://hl7.org/fhir/ValueSet/administrative-gender",
      "content" : "complete",
      "concept" : [{
        "code" : "male",
        "display" : "Male",
        "definition" : "Male."
      },
      {
        "code" : "female",
        "display" : "Female",
        "definition" : "Female."
      },
      {
        "code" : "other",
        "display" : "Other",
        "definition" : "Other."
      },
      {
        "code" : "unknown",
        "display" : "Unknown",
        "definition" : "Unknown."
      }]
    }
  },

Example ValueSet:
  {
    "fullUrl" : "http://hl7.org/fhir/ValueSet/administrative-gender",
    "resource" : {
      "resourceType" : "ValueSet",
      "id" : "administrative-gender",
      "url" : "http://hl7.org/fhir/ValueSet/administrative-gender",
      "version" : "4.0.1",
      "name" : "AdministrativeGender",
      "title" : "AdministrativeGender",
      "status" : "active",
      "experimental" : false,
      "date" : "2019-11-01T09:29:23+11:00",
      "publisher" : "HL7 (FHIR Project)",
      "description" : "The gender of a person used for administrative purposes.",
      "immutable" : true,
      "compose" : {
        "include" : [{
          "system" : "http://hl7.org/fhir/administrative-gender"
        }]
      }
    }
  },

Related: https://github.com/medplum/medplum/issues/2002

Fixed in https://github.com/medplum/medplum/pull/2527


Custom goal icon

Some goals can be difficult to convey with the current options, for example "Get 25 advancements" or "Never take fall damage". As a workaround, we found out that we can use custom player heads, but those are also limited and don't really look great.
It would be useful to be able to include a custom image in the datapack that is rendered in 2d.

Datapacks can't really include images. A server resourcepack should be used for that. I can add support for that though.


#778: add icd #779: use functions instead of alias #810: setup in current shell #782: fix IDE_ROOT on linux/mac

fixes #779 #810 #782

#778: add icd command but not yet with auto-completion.
#779: use functions instead of alias
#810: setup in current shell
#782: fix IDE_ROOT on linux/mac
#774: fix HTTP proxy support - see https://github.com/devonfw/IDEasy/blob/66b6d6bbdb5609995bda70133179e27cdd999099/documentation/proxy-support.adoc

Pull Request Test Coverage Report for Build<PHONE_NUMBER>8
Details

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

Totals

Change from base Build<PHONE_NUMBER>7:
0.0%

Covered Lines:
6478

Relevant Lines:
9274

💛  - Coveralls

I have meanwhile tested this on MacOS and it works.
@leonrohne27 testet this on Linux.
So as it works on all platforms with this new approach and both in bash and zsh, I will merge this.
For the record: This will also mean that CMD support will remain poor. We would have to reimplement everything redundantly in CMD as BAT files what is pure pain. There will be no support for icd in CMD (unless some external users contribute this as PR or our team run out of stories and gets bored what will not happen before 2027).


org.kohsuke/graphviz-api 1.0

Type: Incorrect
Summary:
org.kohsuke/graphviz-api 1.0
Details:
This was NONE but found a file that points to this website where you can see the license is CPL - https://www.graphviz.org/license/
Resolution:
CPL-1.0
Affected definitions:

graphviz-api 1.0

This package has a file that points to website where there is license info:


Cannot find module 'node:module'

I don't know why it can't be started. This error occurred.

{
  "name": "bbhxwl",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "dev": "nuxt",
    "build": "nuxt build",
    "start": "nuxt start",
    "generate": "nuxt generate"
  },
  "dependencies": {
    "@nuxtjs/axios": "^5.13.6",
    "@nuxtjs/proxy": "^2.1.0",
    "@syncfusion/ej2-vue-buttons": "^20.3.58",
    "@syncfusion/ej2-vue-navigations": "^20.3.60",
    "@syncfusion/ej2-vue-querybuilder": "^20.3.59",
    "core-js": "^3.19.3",
    "element-ui": "^2.15.11",
    "nuxt": "^2.15.8",
    "vue": "^2.6.14",
    "vue-server-renderer": "^2.6.14",
    "vue-template-compiler": "^2.6.14",
    "cookie-universal-nuxt": "^2.2.2",
    "webpack": "^4.46.0"
  },
  "devDependencies": {
    "@nuxt/types": "^2.15.8",
    "@nuxt/typescript-build": "^2.1.0"
  }
}

What version of node are you using?

What version of node are you using?

I have 2 projects, one of which cannot run, and the other is normal. This is strange.
nodejs v14.17.6
error log
0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/bin/node', '/usr/local/bin/npm', 'run', 'dev' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'predev', 'dev', 'postdev' ]
5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>7 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true
8 verbose lifecycle<EMAIL_ADDRESS>PATH: /usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/Users/xuzhibin/Project/gitea/bbhxwl/node_modules/.bin:/Users/xuzhibin/opt/anaconda3/bin:/Users/xuzhibin/opt/anaconda3/condabin:/usr/local/sbin:/usr/local/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Library/Frameworks/Python.framework/Versions/3.9/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/xuzhibin/Library/Application Support/JetBrains/Toolbox/scripts
9 verbose lifecycle<EMAIL_ADDRESS>CWD: /Users/xuzhibin/Project/gitea/bbhxwl
10 silly lifecycle<EMAIL_ADDRESS>Args: [ '-c', 'nuxt' ]
11 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null
12 info lifecycle<EMAIL_ADDRESS>Failed to exec dev script
13 verbose stack Error<EMAIL_ADDRESS>dev: `nuxt`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:400:28)
13 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:400:28)
13 verbose stack     at maybeClose (internal/child_process.js:1055:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)
14 verbose pkgid<EMAIL_ADDRESS>15 verbose cwd /Users/xuzhibin/Project/gitea/bbhxwl
16 verbose Darwin 22.2.0
17 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "dev"
18 verbose node v14.17.6
19 verbose npm  v6.14.15
20 error code ELIFECYCLE
21 error errno 1
22 error<EMAIL_ADDRESS>dev: `nuxt`
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>dev script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

You will probably be fine on v14.18.0+. Would you try that?

You will probably be fine on v14.18.0+. Would you try that?

I updated to nodejs 19, but there was still an error.
I ran the following code and also made an error. Mac computer. M1 chip.
export NODE_OPTIONS=--openssl-legacy-provider
node:internal/crypto/hash:71
  this[kHandle] = new _Hash(algorithm, xofLen);
                  ^

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:71:19)
    at Object.createHash (node:crypto:140:10)
    at module.exports (/Users/xuzhibin/Project/WebStorm/bbhxwl/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/Users/xuzhibin/Project/WebStorm/bbhxwl/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (/Users/xuzhibin/Project/WebStorm/bbhxwl/node_modules/webpack/lib/NormalModule.js:471:10)
    at /Users/xuzhibin/Project/WebStorm/bbhxwl/node_modules/webpack/lib/NormalModule.js:503:5
    at /Users/xuzhibin/Project/WebStorm/bbhxwl/node_modules/webpack/lib/NormalModule.js:358:12
    at /Users/xuzhibin/Project/WebStorm/bbhxwl/node_modules/webpack/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/Users/xuzhibin/Project/WebStorm/bbhxwl/node_modules/webpack/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at Array.<anonymous> (/Users/xuzhibin/Project/WebStorm/bbhxwl/node_modules/webpack/node_modules/loader-runner/lib/LoaderRunner.js:205:4) {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v19.4.0

Let's track in #10889


do you have maxDate .. can I set maxDate?

Can I allow selecting ranges in the future?

I don't have that as of yet. I am working on a rewrite of the API though and allowing more options. Will be fixed soon!

Hi! @amrbedair. The options object now accepts a maxDate and if not provided, it defaults to today. Hope this solves your problem :)

@praveenpuglia thank you .. I will try it


Fixed broken git branch icon

This will fix the git branch icon not showing in the Amuse theme.

This change looks like it switches from a standard Unicode "leftward-triangle" character (U+2B60) to the special private-use Powerline "branch" symbol. After it's applied, the theme will only work with special Powerline-patched fonts. Is that intentional?
(Not saying this is wrong; just trying to understand what's going on here. This sounds consistent with switching from the old Powerline code points to the new ones, as discussed in #4065.)

I would think so, because this theme seems to be designed for only Powerline fonts. But none of those fonts actually render correctly.
From https://github.com/robbyrussell/oh-my-zsh/wiki/Themes the description for this theme:
Shown in the screenshot with tmux and the powerline plugin (you might need to install one of the patched powerline fonts for it to look the same).

Ah, yep, that makes sense. Would you mind using this PR to add a comment to the theme definition indicating that it uses Powerline fonts, to make the situation clearer to future maintainers?

Where would I add that definition? To the wiki page?

To the amuze.zsh-theme file, as a comment near the top. (But not at the very top, so as not to interfere with that editor mode line.) That way people looking at that private-use \uE0A0 escape sequence will also be looking at the comment that explains how it should be interpreted.

Alright added comment above that line where \ uE0A0 is used

Looks good to me.
Tested on OS X with a current Powerline-patched font, and the new code point shows up as the branch icon.

:+1:
@mcornella or @ncanceill, can we get a code review and merge on this?

Clear as cristal. As is now, I also get the left-arrow sign when the original author intended a branch icon there.
:+1: /cc @robbyrussell

@mcornella Cool. That's consistent: the old Powerline glyph mappings were using some non-private-use code points, which eventually got implemented by Unicode and systems supporting it, which is the whole reason for the change in the first place. This PR should fix that.


EchoBot Instance VM, service FILES DELETE

name
about

Issue with EchoBot Instance VM, service FILES DELETE
It's about the EchoBot service running on the instances, where files are being deleted.

Describe the issue
We are already running EchoBot, and the service is running on VM instances. When the project is built, there are 175 files that are added for the service execution. However, after some time or when the instance is restarted, the number of files decreases to 82. We want to resolve this issue where more than half of the files are being deleted.
Expected behavior
We want the service to continue running and no files to be deleted even after a certain period of time or when the instances are restarted.
Additional context
We suspect that in the scripts, there might be an error where, upon detecting that the service is not running, it attempts to rebuild or copy the files but fails to complete this action successfully. When the files already exist, it should not attempt to copy anything but simply execute the service.

Hi @jamil-z
The sample uses Desired State Configuration (DSC) for all setup on the Virtual Machine ScaleSets (VMSS).
The DSC configuration is deployed via the DSC extension in the Bicep Template.
The raw configuration is here and there is a specific custom DSC resource that copies the App Files.
https://github.com/microsoftgraph/microsoft-graph-comms-samples/blob/master/Samples/PublicSamples/EchoBot/ADF/ext-DSC/DSC-BotServers.ps1#L393C1-L410C10
That custom DSC Resource is here for deploying the App Files from the Build pipeline and it allows for continuous integration for new builds.
https://github.com/brwilkinson/AppReleaseDSC
All code is in this single file.
https://github.com/brwilkinson/AppReleaseDSC/blob/main/AppReleaseDSC.psm1
DSC is going to always run the first time... then there is a configuration setting to say if it should run later on to autocorrect.
That specific setting is here:
https://github.com/microsoftgraph/microsoft-graph-comms-samples/blob/master/Samples/PublicSamples/EchoBot/ADF/ext-CD/BOT-ConfigurationData.psd1#L20
            # given this is for a lab and load test, just always pull down the latest App config
            DSCConfigurationMode        = 'ApplyAndAutoCorrect'

Which actually gets used here in the DSC on the ConfigurationMode.
https://github.com/microsoftgraph/microsoft-graph-comms-samples/blob/master/Samples/PublicSamples/EchoBot/ADF/ext-DSC/DSC-BotServers.ps1#L95C1-L101C10
        LocalConfigurationManager
        {
            ActionAfterReboot    = 'ContinueConfiguration'
            ConfigurationMode    = iif $node.DSCConfigurationMode $node.DSCConfigurationMode 'ApplyAndMonitor'
            RebootNodeIfNeeded   = $True
            AllowModuleOverWrite = $true
        }

You can comment out that setting in the ConfigurationData, then deploy again and it will be set to ApplyAndMonitor instead of ApplyAndAutoCorrect or change the setting yourself to whatever you prefer.
It was set to autocorrect, since if you rerun the build pipeline, it automatically pulls down the latest build basically CI/CD.
So it's hard to say what your exact issue is or what you are experiencing, however the custom DSC resource above uses AZCopy to do all files copies for the App Files and we log everything to the AzCopy Logs on the Filesystem.
One thing, since you are stopping the service, when DSC runs which is default every 15 minutes, it's going to see that the machine is not in the desired state and it's going to run ALL of the DSC configuration again. So definitely if you plan to stop the service flip to ApplyAndMonitor because it's just going to restart the service anyway.
However you won't get new builds pulled down... But also know without that change, as I just mentioned above, DSC is going to restart the service every 15 minutes anyway, because it's in the DSC configuration.
So let me know how you go... the answer could be in the AZCopy logs, however I think it's best to tweak DSC for your use case.
It could be something unrelated to this, however this appears like the most likely scenario.

one thing... in DSC you run the following to see if the machine is in the desired state
Test-DSCConfiguration
It will show resources in the Desired and also the Non desired state. If there is a resource not in the desired state, then you need to figure out why or what changed to make it that way. Again if it's an issue with copying files, the answer will be in the AzCopy Logs.

You can also see the history of ALL DSC attempts to run.
Get-DscConfigurationStatus -All
You can see if status was in success or failure.

@jamil-z please keep us posted if you were able to resolve your issue on this one?

@brwilkinson Thank you for the answers.
Yes, we were able to solve the problem, but we took a different approach due to the required changes.
We are adding the file generated by default, CurrentBuild.txt, to avoid the files being deleted when making the copy.


pull request for e2e test at 01/16/2017 03:18:11

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


AzureConfigurableImpl.withMaxIdleConnections unused parameter

Hello,
I think that in
https://github.com/Azure/azure-sdk-for-java/blob/457ac0079909991cba39e13f3ad878096208d030/azure-mgmt-resources/src/main/java/com/microsoft/azure/management/resources/fluentcore/arm/implementation/AzureConfigurableImpl.java
public T withMaxIdleConnections(int maxIdleConnections) {
this.restClientBuilder = restClientBuilder.withMaxIdleConnections(5);
return (T) this;
}
should be
public T withMaxIdleConnections(int maxIdleConnections) {
this.restClientBuilder = restClientBuilder.withMaxIdleConnections(maxIdleConnections);
return (T) this;
}
change '5' with 'maxIdleConnections'

Good catch! Assigned my self.

Fixed and released with beta3.


compiling to .exe

Hello!
When I try to compile my script to .exe with py2exe, translations are not included. Any idea how to achieve to include translations (/locales folder).
problematic functions are:
get_program_status_text() and get_execution_status_text().
Thank you!

I was able to confirm your steps, manually adding the translation files makes it work but I can't figure out what I could change in pyLSV2 to make py2exe include the mo files. The packages include the translation files so I would think pyLSV2's setup.py works as intended.
Going forward I can remove the translation stuff entirely and hardcode the messages. As I don't see myself adding additional languages this might be the easiest solution to this problem.

Ok, I did some more digging. It seems to be a problem with py2exe only checking for *.py files and nothing else. A work around is to manually add files but this does not allow adding files to library.zip.
I created #21 which lets you set the path for the translation files manually. This together with adding the files seems to work great!
To test I used this setup.py script:
from distutils.core import setup
import glob
import pyLSV2

baseFolder = pyLSV2.__file__.strip('_init_.py')
mylocaleEN = glob.glob(baseFolder+"\\locales\\en\\LC_MESSAGES\\*.mo")
mylocaleDE = glob.glob(baseFolder+"\\locales\\de\\LC_MESSAGES\\*.mo")

data_files = [("locale\\en\\LC_MESSAGES", mylocaleEN),
               ("locale\\de\\LC_MESSAGES", mylocaleDE)]

setup(console=['lsv2_demo.py'], data_files=data_files)

together with this test script:
import pyLSV2

locale_folder = "./locale"

print(pyLSV2.__version__, pyLSV2.__file__)
print(pyLSV2.get_program_status_text(pyLSV2.PgmState.STOPPED, locale_path=locale_folder))
print(pyLSV2.get_program_status_text(pyLSV2.PgmState.STOPPED, language='de', locale_path=locale_folder))
print(pyLSV2.get_program_status_text(pyLSV2.PgmState.STOPPED, language='en', locale_path=locale_folder))

I hope #21 and changing the setup.py works for you!


Daemon doesn't start properly when using pipewire-pulse

Describe the bug
When pulsemeeter is started using the daemon option after starting pipewire-pulse, it gives me the following error and doesn't work:
Error setting sink Virtual_Input_1 as primary
Error setting source Virtual_Output_B1 as primary

Error on the pipewire-pulse side (using systemctl --user status pipewire-pulse.service):
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.loopback: error id:0 seq:91 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.loopback: error id:0 seq:80 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.null-sink: error id:0 seq:51 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.loopback: error id:0 seq:101 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.null-sink: error id:0 seq:72 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.loopback: error id:0 seq:140 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.null-sink: error id:0 seq:93 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.null-sink: error id:0 seq:102 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.null-sink: error id:0 seq:111 res:-32 (Broken pipe): connection error
Aug 29 11:12:59 ZephyrusLeon pipewire-pulse[48052]: mod.null-sink: error id:0 seq:121 res:-32 (Broken pipe): connection error

To Reproduce
Steps to reproduce the behavior:

Stop pipewire-pulse.socket and pipewire-pulse.service.
Start pipe-wirepulse again.
execute pulsemeeter daemon.
The -d option doesn't print any further errors.

Workaround?
There are two ways of running pulsemeeter properly:
Method 1:

Stop pipewire-pulse.socket and pipewire-pulse.service.
Start pipe-wirepulse again.
execute pulsemeeter (without daemon).

Method 2:

Stop pipewire-pulse.socket and pipewire-pulse.service.
Start pipe-wirepulse again.
Start PulseAudio Volume Control.
Execute pulsemeeter daemon.
You may now quit PAVU.

Expected behavior
Pulsemeeter should, as a daemon, also launch properly and not cause errors.
Desktop (please complete the following information):

Distro: EndeavourOS Linux x86_64
Kernel: 5.18.16-arch1-g14-2
Python 3.10.6

that is known and not implemented yet, there is a branch for pipewire pulse, dunno how functional
looking at the current state of branches i would say patience, patience, patience
seems like he try to implement socket, pipewire while doing an ui refactor. so i would expect a merged release somewhere nextg spring

that is known and not implemented yet, there is a branch for pipewire pulse, dunno how functional
looking at the current state of branches i would say patience, patience, patience
seems like he try to implement socket, pipewire while doing an ui refactor. so i would expect a merged release somewhere nextg spring

There is a nightly branch you can try out which should work much better for pipewire. Guide is on the wiki.

The nightly branch works properly, thank you!
Closing as it's working in a future version.


Add support for PodSecurityPolicy

Add support of Pod Security Policy in the operator. Right now it is not possible to deploy the operator that has PSP enabled in it.
I have restricted PSP on my cluster and then orchestrator fails for me:
$ kubectl logs mysql-operator-orchestrator-0
2019/03/18 05:44:25 unable to create open /etc/orchestrator/orchestrator.conf.json: permission denied
2019/03/18 05:44:25 unable to create open /etc/orchestrator/orc-topology.cnf: permission denied
2019-03-18 05:44:25 FATAL Cannot read config file: /etc/orchestrator/orchestrator.conf.json open /etc/orchestrator/orchestrator.conf.json: no such file or directory

The PSP this pod picked up was:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
    seccomp.security.alpha.kubernetes.io/defaultProfileName:  'docker/default'
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # This is redundant with non-root + disallow privilege escalation,
  # but we can provide it for defense in depth.
  requiredDropCapabilities:
  - KILL
  - MKNOD
  - SETUID
  - SETGID
  # Allow core volume types.
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'projected'
  - 'secret'
  - 'downwardAPI'
  # Assume that persistentVolumes set up by the cluster admin are safe to use.
  - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    # Require the container to run without root privileges.
    rule: 'MustRunAs'
    ranges:
    - min: 1
      max: 99999
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
    # Forbid adding the root group.
    - min: 1
      max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
    # Forbid adding the root group.
    - min: 1
      max: 65535
  readOnlyRootFilesystem: false

Hi @surajssd, thank you for opening this issue!
The problem is with the docker images that run the processes as root.  There are few places where it needs to tweak the Dockerfiles and maybe helm charts. One of them is orchestrator chart and in the sidecar Dockerfile.
I scheduled it for the next major release 0.3.0, but I'd be happy to review and merge a PR that fixes it sooner. :smile:

@AMecea added a PSP config setup in https://github.com/presslabs/docker-orchestrator/pull/5 now will add the configs for mysql-operator.

Add PSP configs for this chart https://github.com/presslabs/mysql-operator/pull/273

The mysql pods that are started by the pod also need root in them to run, I had to give following PSP to the cluster pods
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: mysql-cluster
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
    seccomp.security.alpha.kubernetes.io/defaultProfileName:  'docker/default'
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
  - KILL
  - MKNOD
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'projected'
  - 'secret'
  - 'downwardAPI'
  - 'persistentVolumeClaim'
  - 'hostPath'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
    # Forbid adding the root group.
    - min: 1
      max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
    # Forbid adding the root group.
    - min: 1
      max: 65535
  readOnlyRootFilesystem: false

Is there any solution for k8s version > 1.25?


integrate design for new home page; add new home page to UI preview

Closing this one, we have already merged the changes in #204. Thank you!