Feature request MissingMemberHandling.Default

I suggest adding MissingMemberHandling.Default
If set and a member is missing during deserialization, try to call a default constructor on the missing type instead of setting it to null.
If there is no default consatructor set it to null (ie fallback to MissingMemberHandling.Ignore
This is especially useful when working with #nullable enable - one is not expecting to get null values without compiler warnings in this case.
Thanks

Breaking change.

@sungam3r  I don't understand, as far as I can see this is not a breaking change. It will only take effect if/when someone is using the suggested new option

@sungam3 fair enough I didn't mean that, how about "TryDefaultConstructor" ? or do you have a better name ?

What is the business value to this? Class (and Record) definitions already define the default state of the object that is instantiated before the properties are set during deserialization.
Serialization and Deserialization should be repeatable, the process should not inject information that was not already there.
Consider the following class:
public class Student
{
    public string Name { get;set; }
    public Student OlderSibling { get;set; }
}

The serialized state for a single record might look like this
{ "Name": "Test Kid" }

With your MissingMemberHandling.Default the deserialized object, if serialized might now look like this:
{
    "Name": "Test Kid",
    "OlderSibling": { }
}

But now if we deserialize this, we start to get more interesting results, in this case the Name field will be initialized to an empty string, because it was missing, and it will have another older sibling:
{
    "Name": "Test Kid",
    "OlderSibling": {
        "Name": "",
        "OlderSibling": { }
     }
}

Where might this issue present itself? If your application allowed a Student to be loaded from a serialized source, then after making changes to other fields they then save this record to a serialized target. Now imagine the user loads and saves the same record many times, suddenly "Test Kid", who is actually an only child in real life, now has a lot of siblings in the application.
Is this a good design to encapsulate a Student, not by far... But only the Author of the Student class and what ever parent structure this record is referenced from knows what the intent of this design was, the definition of the class itself is an expression of that intent, so it is within the definition of the class that the instructions on how to manage the serialization and deserialization should be defined, or in the business logic that manages the serialization process.
Right now, if you actually wanted this behaviour, you would define your class with an initializer for the property that you want to be pre-initialized, noting that this only works if MissingMemberHandling.Ignore is set:
public class Student
{
    public string Name { get;set; }
    public Student OlderSibling { get;set; } = new Student();
}

you could also define this in the default constructor for the class, IMO that is a habit that leads to maintenance issues down the track and is harder to infer from the model during design time when you are using this class.

In this fictitious class, it might be acceptable for Name  to be pre-init, but not OlderSibling, but a MissingMemberHandling.Default would not be able to differentiate between different members, it is all or none.
A more acceptable Student class might be this:
public class Student
{
    public string Name { get;set; } = String.Empty;
    public Student OlderSibling { get;set; }
}

Now the deserializing an empty JSON object, and then serializing would look like this:
{ "Name": "" }

If you wanted specifically to manage deserialization for specific properties or types, you could always use one of the deserialization call backs:
public class Student
{
    public string Name { get;set; }
    public Student OlderSibling { get;set; }

    [OnDeserializing]
    internal void OnDeserializingMethod(StreamingContext context)
    {
        Name = "Default Student";
    }
}

Then run the following code:
var json = @"[
    { },
    { ""Name"": """" },
    { ""Name"": ""Little Johnny"" }
]";

var students = Newtonsoft.Json.JsonConvert.DeserializeObject<Student[]>(json, new JsonSerializerSettings
                    {
                        MissingMemberHandling = MissingMemberHandling.Ignore
                    }
                );

Console.WriteLine(JsonConvert.SerializeObject(students, Formatting.Indented, new JsonSerializerSettings
                    {
                        MissingMemberHandling = MissingMemberHandling.Ignore,
                        NullValueHandling = NullValueHandling.Ignore
                    }
                ));

Which should output this:
[
  {
    "Name": "Default Student"
  },
  {
    "Name": ""
  },
  {
    "Name": "Little Johnny"
  }
]

If you do not want to, or cannot manipulate the class definition, then you could always resort to a JsonConverter.
The following is an example implementing the CustomCreationConverter:
public class StudentDTO
{
    public string Name { get; set; }
    public Student OlderSibling { get; set; }
}
public class StudentConverter : CustomCreationConverter<StudentDTO>
{
    public override StudentDTO Create(Type objectType)
    {
        return new StudentDTO { Name = "Custom Creation" };
    }
}

Execution:
json = @"[
    { },
    { ""Name"": """" },
    { ""Name"": ""Little Johnny"" }
]";

var students = Newtonsoft.Json.JsonConvert.DeserializeObject<StudentDTO[]>(json,new StudentConverter() );

Console.WriteLine(JsonConvert.SerializeObject(students, Formatting.Indented, new JsonSerializerSettings
                    {
                        MissingMemberHandling = MissingMemberHandling.Ignore,
                        NullValueHandling = NullValueHandling.Ignore
                    }
                ));

output:
[
  {
    "Name": "Custom Creation"
  },
  {
    "Name": ""
  },
  {
    "Name": "Little Johnny"
  }
]

Thanks @ChrisSchaller , what you wrote above amounts to 'in some scenarios using this option may give unwanted results' sure I agree, in those cases (ie self referencing records) that option should not be used.
My use case:
C# 9 introduced the short record definition command and non nullable reference types.
It is now common to right:
#nullable enable

record Rec(
   int Age,
   Employee Employee
   .. many other fields ..
);

This form without a constructor is very advantageous. It removes the need to remember to correctly edit the ctor when adding or removing fields which both tedious and a common source of bugs.
working with #nullable enable one expects these record fields to not be null. This is crucial.
To have such a record de serialized and have a field set to null even after explicitly specifying #nullable enable is very confusing - I would consider it a json.net bug
There are three ways out here

as you suggest to forgo the benefits of not having to write a ctor and write it explicitly with default parameters where needed
use a custom converter etc this is both tedious and has the exact same problems with self references
my request for a specific directive to DeserializeObject to tell it in this case I want to use the empty ctor for missing fields. I think this will be a useful addition

I hope this is clearer

The point of #nullable enable is not to make sure that nothing in your code is null, it is to deliberately force you to check that values are null. There is no such expectation that the record fields cannot be null. only that if a record has an immutable property that is instantiated as null, then it's value cannot change.
If your entire code base cannot be null, then we would have to check for zeros or defaults for every comparison, which would be almost as bad. Even with records, I cannot see the argument for setting the Employee property to a default instance.

I'll leave you alone after this :) the main issue for me is that if a review all my recent projects, that cover finaces, Logistics, IOT business domins, I've even deployed a few micro-service and bot architectures, the amount of individual classes, out of the thousands from these real world business data model designs that could legitimately use this feature, where ALL properties could and should be pre-initialised to non-null values is very close to zero. Its pretty much only meta-data structures or single purpose classes where this could be applied.
I would instead argue that having a MissingMemberHandling.Null option would have more value, being able to deliberately override the default initialization to a null state (for nullable types). In fact it would make more sense to me if your name of MissingMemberHandling.Default actually set the value to null as that is the default value for a nullable type. From an implementation point of view this would be the same as using the default literal or the generic default(T).

yes forget about the name it's confusing I now changed the name in the request to TryDefaultConstructor
As for your projects .. are you using records for those thousand of cases ? are you working with #nullable enabled ? otherwise they are not relevant here.

Its pretty much only meta-data structures or single purpose classes where this could be applied

this could be applied to almost any (except self referencial etc which is rare) records

Even when using records, null is still a significant value, with #nullable enabled you just use the null coalescing operator or deliberately check for null.

This type of behaviour, to instantiate a property with a default value that is NOT defined as part of the property declaration or meta-data in the class definition is unusual and does not conform to any existing or previous framework standards.

This perhaps should be a request of record type implementation itself, and not specifically anything to do with JSON.Net?

When using records, it's still simple syntax to declare initialization, the main argument is that only the class or record definition itself can "know" if it is valid for that property to be in a null state or not.

there may be some value in adding this as an option to JsonObjectAttribute but as per this #2380 this attribute is ignored if the property was not declared in the source text that is being deserialized.

It would not be hard to write a generic converter to inspect property attributes on the target class and use them when initialising the initial state of the object instance, however you might have to work a bit harder to make it suit immutable properties on a record when the property is missing from the source text, specifically in the context of records, there might be an argument, but the accepted solution is either to use the verbose record declaration.
Again, this is more of an issue with record declaration syntax and less about deserialization.
Regarding #nullable enabled:
Even if the serializer did generate a default instance of the object to inject into the property you will still be required to use null checking because the property type is itself nullable. To get around this you should use a non-nullable type.
If the property is itself a record type, then what would be the purpose of a value that cannot be changed, it will always be the default state. In this state, I think that null has much more value, rather than having to determine if the value is null because it was not initialized correctly, or if it was deliberately initialized with that effectively empty value.

This discussion goes full circle, your example and reasoning highlight why it is important that as part of serialization we should be able to force these properties to be null. These values did not exist in the serialized content, and therefore there is a strong argument that they should not exist in the hydrated object graph after deserialization either.

This is becoming off topic, to me you misunderstand non-nullable reference types but let's leave it that. You don't think my feature suggestion makes sense I hope others will.


Graceful shutdown for the service

Currently, the service is stopped immediately on Ctrl-C. All the in-flight calls are cancelled abruptly (not that we have many of them). The more important thing at this point is that we leave a lot of garbage after ourselves, i.e. running containers. I think we should clean things a bit after ourselves, at least by stopping all the containers (and maybe deleting them).

Fixed by #65


updated the changes to both the notebooks

Description
This notebook shows the changes to LPJ eosim notebook and MiCASA notebook.
Referring to this PR.

Because of all the branch conflicts, I created a new branch from the main and then made the required changes in the code to generate the outputs in the notebook. @fb0023 I did make this branch from the main branch where you already updated the content but you can double-check the content (if needed). @siddharth0248 You can look for any other changes that might be needed.


Instead of hard coded shortcut for Find My Mouse, it might be better to configure different shortcut keys.

Description of the new feature / enhancement
Instead of hard coded shortcut for Find My Mouse, it might be better to configure different shortcut keys.
I really like this feature, but it blocks one of my app shortcuts. So, i am forced to disable the feature for now.
User should be provided an option to configure it to a different shortcut keys, instead of totally dis-abling it.

Duplicate of #14028

Thanks for your suggestion! We are currently working on this.
I'm linking this issue to #14028 to centralize the discussion thread, please go to that thread for discussion.
Thanks for your help to make PowerToys a better piece of software!


Example code from the README is outdated and incomplete

Service Registration example from the README:
import javax.jmdns.*;

JmDNS jmdns = new JmDNS();
jmdns.registerService(
    new ServiceInfo("_http._tcp.local.", "foo._http._tcp.local.", 1234, 0, 0, "path=index.html")
);

JmDNS cannot be instantiated this way because it is abstract (probably wasn't abstract in an earlier version).
There should be complete code (including class Example and main) or a comment denoting that something has been left out.

Problem 2 is rather cosmetic, but a copy-paste-able example would probably be nice.
The "abstract" problem applies to the Service Discovery example too, as well as the cosmetic problem.

I also just stumbled accross this problem.

@rspielmann Do you plan to create a PR to address these problems?

@kaikreuzer I just did :)

Wonderful, thanks - already merged :-)


e2e tests need to be run in a more targeted manner

Target e2e tests to changes within specific folders. For example, changing "Issue templates" should not trigger any e2e tests.
Tests can take time to run, hence targeting them in this manner is useful to save time during PR review / merge process.
GH Actions workflows make it easy to specify paths. Splitting each e2e test into its own workflow seems like a good idea.

Done.


ImportError: from . import roiaware_pool3d_cuda

When I run the code:
python kitti_dataset.py create_kitti_infos
The error occurred:
Traceback (most recent call last):
File "kitti_dataset.py", line 11, in
from pcdet.utils import box_utils, object3d_utils, calibration, common_utils
File "/home/jhvision5/Michael/pyPrj/PCDet/pcdet/utils/box_utils.py", line 5, in
from ..ops.roiaware_pool3d import roiaware_pool3d_utils
File "/home/jhvision5/Michael/pyPrj/PCDet/pcdet/ops/roiaware_pool3d/roiaware_pool3d_utils.py", line 4, in
from . import roiaware_pool3d_cuda
ImportError: libcudart.so.8.0: cannot open shared object file: No such file or directory
PCDet installation seems to be no problem:
running develop
running egg_info
writing pcdet.egg-info/PKG-INFO
writing dependency_links to pcdet.egg-info/dependency_links.txt
writing requirements to pcdet.egg-info/requires.txt
writing top-level names to pcdet.egg-info/top_level.txt
reading manifest file 'pcdet.egg-info/SOURCES.txt'
writing manifest file 'pcdet.egg-info/SOURCES.txt'
running build_ext
copying build/lib.linux-x86_64-3.7/pcdet/ops/iou3d_nms/iou3d_nms_cuda.cpython-37m-x86_64-linux-gnu.so -> pcdet/ops/iou3d_nms
copying build/lib.linux-x86_64-3.7/pcdet/ops/roiaware_pool3d/roiaware_pool3d_cuda.cpython-37m-x86_64-linux-gnu.so -> pcdet/ops/roiaware_pool3d
Creating /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages/pcdet.egg-link (link to .)
pcdet 0.1.0+2244be4 is already the active version in easy-install.pth
Installed /home/jhvision5/Michael/pyPrj/PCDet
Processing dependencies for pcdet==0.1.0+2244be4
Searching for PyYAML==5.1.2
Best match: PyYAML 5.1.2
Adding PyYAML 5.1.2 to easy-install.pth file
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for easydict==1.9
Best match: easydict 1.9
Adding easydict 1.9 to easy-install.pth file
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for tensorboardX==1.9
Best match: tensorboardX 1.9
Adding tensorboardX 1.9 to easy-install.pth file
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for numba==0.46.0
Best match: numba 0.46.0
Adding numba 0.46.0 to easy-install.pth file
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for spconv==1.0
Best match: spconv 1.0
Adding spconv 1.0 to easy-install.pth file
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for torch==1.1.0
Best match: torch 1.1.0
Adding torch 1.1.0 to easy-install.pth file
Installing convert-caffe2-to-onnx script to /home/jhvision5/anaconda3/envs/michael/bin
Installing convert-onnx-to-caffe2 script to /home/jhvision5/anaconda3/envs/michael/bin
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for numpy==1.17.3
Best match: numpy 1.17.3
Adding numpy 1.17.3 to easy-install.pth file
Installing f2py script to /home/jhvision5/anaconda3/envs/michael/bin
Installing f2py3 script to /home/jhvision5/anaconda3/envs/michael/bin
Installing f2py3.7 script to /home/jhvision5/anaconda3/envs/michael/bin
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for protobuf==3.11.1
Best match: protobuf 3.11.1
Adding protobuf 3.11.1 to easy-install.pth file
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for six==1.13.0
Best match: six 1.13.0
Adding six 1.13.0 to easy-install.pth file
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for llvmlite==0.30.0
Best match: llvmlite 0.30.0
Adding llvmlite 0.30.0 to easy-install.pth file
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Searching for setuptools==39.1.0
Best match: setuptools 39.1.0
Adding setuptools 39.1.0 to easy-install.pth file
Installing easy_install script to /home/jhvision5/anaconda3/envs/michael/bin
Installing easy_install-3.6 script to /home/jhvision5/anaconda3/envs/michael/bin
Using /home/jhvision5/anaconda3/envs/michael/lib/python3.7/site-packages
Finished processing dependencies for pcdet==0.1.0+2244be4
My cuda version is 9.0, why is there an "ImportError: libcudart.so.8.0" error:
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Sep__1_21:08:03_CDT_2017
Cuda compilation tools, release 9.0, V9.0.176
How can I solve this problem, can anyone help me answer it, thank you!

I had a similar error, upgrading from spconv 1.0 to spconv 1.1 solved it for me

Please make sure to buid pcdet with CUDA 9.0.
You could remove the build folder and try to rebuild pcdet with CUDA 9.0

Please make sure to buid pcdet with CUDA 9.0. You could remove the build folder and try to rebuild pcdet with CUDA 9.0

Can this repo not be used with CUDA 11.6?

Please make sure to buid pcdet with CUDA 9.0. You could remove the build folder and try to rebuild pcdet with CUDA 9.0

Can this repo not be used with CUDA 11.6?

I have the same question, could this repo be used with CUDA 11.6?


Configurable default Temp and TopP

Hi @jordac
Thank you for interest and effort. I think tools like ShellGPT benefits from having low and constant tempreature, since it makes LLM response more precise. Therefore I'm closing this PR, thank you for your effort.

https://www.reddit.com/r/ChatGPT/comments/126sr15/gpt_api_analyzing_which_temperature_and_top_p/
This post and my own testing is why I set both of mine to 0.3. Thanks for looking over my PR and for authoring this project,

Having the higher top_p will cause results to be less precise.
The top_p parameter, often used in language models like GPT-3 and GPT-4, refers to "nucleus sampling," a method for generating text. It's a way to balance the randomness and predictability of the text being generated.

top_p = 1.0: This setting means that the model considers the full range of possible next words, as long as their cumulative probability reaches 100%. Essentially, it's looking at a wider range of words, including both high and low probability options. This can lead to more diverse and creative outputs but can also introduce more randomness and potentially less precise or relevant answers.

top_p = 0.3: This setting is more restrictive. The model only considers the smallest set of words whose cumulative probability adds up to 30%. It's focusing on the most likely next words and excludes the less probable ones. This generally leads to more predictable, coherent, and precise outputs but can sometimes be less creative or diverse in its responses.

In summary, a lower top_p (like 0.3) typically results in more precise and coherent text, as it's relying on the most probable words. A higher top_p (like 1.0) allows for more diverse and potentially creative outputs but can also introduce more randomness and less precision. The choice between the two depends on whether the priority is creativity and variety or precision and relevance.


Should add link to Contract Version List

It'd be nice to add a link in the Related Articles to the list of API contract versions similar to this one so that it's easier to match up what version 'number' is needed and matches to which other features/sdks.

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

ID: e4adf9e3-46b9-732a-7659-07d34a9ff469
Version Independent ID: 0dd55994-fed9-6d25-38c8-85e1ee2322ff
Content: Conditional XAML - Windows UWP applications
Content Source: windows-apps-src/debug-test-perf/conditional-xaml.md
Product: uwp
GitHub Login: @eliotcowley
Microsoft Alias: elcowle

This is a reasonable ask. That's the first time I've seen that contracts page ... that one could use some help.

This link has been added.


lightning-specification: add 23/01/30 meeting transcript

Generated transcript for LN spec meeting on 23/01/30.
Done one human-checking pass.
Opening as a draft for now because it needs one more cleanup round before it's worth reviewing.

Thanks for the detailed review @gurwindersahota!
I've included the suggestions + done one more pass on the techincal terminology - diff is here.

@carlaKC can you take this out of draft mode so we can merge it?


(TS) Property 'onError' does not exist on type '{}'

Can anyone explain what one must do to resolve this? Or tell me if it even needs to be resolved?
I'm working on a rudimentary project created in Visual Studio 2017 for ASP.NET Core web app that uses Angular.
I'm running VS 2017 15.5.6 and I'm trying to educate myself about Angular.
When one begins to use a new technology these kinds of warnings/errors are huge because one has no idea if there's something wrong with Visual Studio, Angular, Javascript, some package, etc, etc, etc or one's own code.
Traditionally error messages reported in the Visual Studio Error List window are to be taken very seriously so I'd like to get to the bottom of this.
The presence of this error incidentally, is an example of something else I posted yersterday here:
https://github.com/aspnet/Home/issues/2868
I am only posting this issue here because this repo came up with search hits when I searched for info about it, as a relative novice I'd have absolutely no way of looking at the error message and inferring that I should post an issue to a repo named JavaScriptServices !!!
Although I found several issues here about this none of these help me, they seem to only be of relevance to developers intimately involved in this or that repo, no use whatsoever to the "ordinary" Visual Studio developer trying to fathom these new technologies.
Thanks.
PS: I actually see TWO errors, here's the text of the other:
"The target "UpdateDesignTimeXaml" does not exist in the project."

This error is caused by code in the Angular SPA template in boot.server.ts.

For now I have changed the problematic line to:
(zone as any).onError.subscribe((errorInfo: any) => reject(errorInfo));
But, a MS blessed/sanctioned fix would be preferred.
Thanks.

@joerattz Thanks for the info. The latest Angular template no longer uses that code, so in effect this is "fixed" in the latest templates (fixed in the sense that the issue is no longer present).


Automate creation of conda build assets

Problem: Conda builds require a directory with files:
Example: https://github.com/fastai/fastconda/tree/master/opencv-python-headless

build.bat
meata.yaml
build.sh

You don't have to understand anything about these files, except that these are basically boilerplate with a few variables of things that need to be changed:

bld.bat: example in this file https://github.com/fastai/fastconda/blob/master/opencv-python-headless/bld.bat you need to replace package name with a variable that is the package name
build.sh also just need to replace the package name, however this one can be done via an environment variable called PKG_NM  But Jeremy will change this detail.  Reference: https://docs.conda.io/projects/conda-build/en/latest/user-guide/environment-variables.html#id2
In Meta.yaml

Need to fill in the name and version (see the template variables and this will make sense)
Need to fill in the requirements.run list of dependencies, which can be supplied via arguments from the user
Need to fill in the test.imports. section with an import name, which can be different than the package name (example: opencv-python-headless vs cv2) -- investigate this to see if you can get the import name automatically somehow or if it needs to be supplied by the user.

Approach:  look at fastrelase

pypi_details
update_meta
write_pip_conda_meta for an example of how to create yaml files

Things I'm not 100% sure about but will investigate:

Can I get the import name automatically ex: cv2 vs  opencv-python-headless
Does the file that I materialize need to to be meta.yaml not meta.yaml.tmpl correct?  I assume that meta.yaml.tmpl is an intermediate file that is processed outside of conda build but maybe conda build is providing direct support for templating?

@jph00 please review LMK if I'm missing anything.

In Meta.yaml

You're missing the other stuff that comes from the pypi metadata, such as author, description, and license. There's already fastrelease.conda.write_pip_conda_meta that can create meta.yaml from pypi metadata so you should be able to borrow from (or use) that.

Can I get the import name automatically ex: cv2 vs opencv-python-headless

No, that should be passed as an argument to the function

Does the file that I materialize need to to be meta.yaml not meta.yaml.tmpl correct

Correct. Ignore the current use of a tmpl file - that's just a short-term thing to get an initial version working.

In Meta.yaml

You're missing the other stuff that comes from the pypi metadata, such as author, description, and license. There's already fastrelease.conda.write_pip_conda_meta that can create meta.yaml from pypi metadata so you should be able to borrow from (or use) that.

Can I get the import name automatically ex: cv2 vs opencv-python-headless

No, that should be passed as an argument to the function

Does the file that I materialize need to to be meta.yaml not meta.yaml.tmpl correct

Correct. Ignore the current use of a tmpl file - that's just a short-term thing to get an initial version working.

I've changed bld.bat and build.sh to use the env var now.

I've changed bld.bat and build.sh to use the env var now.


HelpWindow: May interfere with UI Components while active

Discovered this while testing other applications, the commands fail to show if the help window is open in the background.
Refer to: https://github.com/CS2103AUG2017-W14-B4/main/issues/106
exit command is blocked from executing while help window is open too.
Steps to reproduce:

Open help window
2a. Enter any command
Command result messages fail to display to user.
Use case end.

2b. Type exit
Application will not exit until help window is closed
Use case end
Normally closing the application by using the mouse will still close the application
Edit by Zhi Yuan: See https://github.com/nus-cs2103-AY1718S1/forum/issues/181#issuecomment-341664086 as well

Observed similar behaviour in our own application and the one I am testing. The outputs are redirected to the terminal instead of being displayed in the address book command result box.

Great catch ^^

Hi,
With regards to this issue, I think it is because of the method stage.showAndWait()
Would a workaround be using stage.show() instead so that it does not interfere with the MainWindow?
Tested by typing help in commandBox followed by other commands before exit in commandBox.

Yup I'm guessing that the showAndWait() may affect it, though I'm not sure why Pressing F1 / Clicking on the Help button doesn't cause the issue (the issue only occurs when you enter help in the Command Box).
But sure, a quick fix will be to simply use show(). I recall doing so as well when I was taking CS2103. ^^ Perhaps Prof @damithc knows about why showAndWait() was used in the first place?

Perhaps Prof @damithc knows about why showAndWait() was used in the first place?

No idea. Probably not a conscious choice. :-p


Support status color for FormFieldHelperText

Using the color prop instead of the deprecated variant. It should now apply the success/warning/error colour to the helper text based on the form field status.
Should address #3540

Needs a design review, @jpmorganchase/salt-design . Are we happy with this affecting all helper text? Do we want it to be optional

Move to draft as waiting for design discussion.


GDScript: $ get node (dollar) operator completion issues

Godot version
4.0.dev (865b62b)
System information
Linux, Mageia 9 x86_64
Issue description
While working on #53303, I found two issues with the completion for GDScript's $ get equivalent operator (which is equivalent to calling the get_node() function). Both are still reproducible even once #53303 will be merged.

[ ] Completion options are not limited to only valid NodePaths. All classes in the global scope seem included:

[ ] Completion a NodePath which needs quotes (e.g. with spaces or invalid characters for an identifier) will include two quotes at the end when pressing Tab:

Steps to reproduce

Open GDScript editor for a script attached to a node with child nodes
Use the $ operator and try to complete node paths, including paths with spaces

Minimal reproduction project
No response

I haven't tried to debug but the issue probably lies in CodeEdit::confirm_code_completion() or nearby.

With the first one, the issue appears to be the parser incorrectly determining the context:

It should be returning GDScriptParser::COMPLETION_GET_NODE
https://github.com/godotengine/godot/blob/198b49d8b589e88a5ae61fc8418ebf8890d2d1f7/modules/gdscript/gdscript_editor.cpp#L2648-L2653

The problem lies with the parser which is supposed to update the completion context. The function parse_get_node has some checks at the beginning and only pushes a completion context if they don't fail. But without something after $ the checks fail (correctly, this isn't valid GDScript but we want completion anyway.). The completion for get node doesn't use any properties of CompletionContext so pushing an empty context of type GET_NODE when the checks fail should work fine.


StatWorker_Mass.cs edit: Add support for Dead pawns.

Issue: Currently, when a pawn dies the individuality mass stat does not apply because StatWorker_Mass.cs tries to get CompIndividuality from the Corpse. This fix makes it so that the Individuality mass change also applies correctly to the Corpse.
public override float GetValueUnfinalized(StatRequest req, bool applyPostProcess = true)
{

    var compIndividuality = req.Thing.TryGetComp<CompIndividuality>();
    if (req.Thing.def.IsCorpse)
    {
        var corpse = req.Thing as Corpse;
        compIndividuality = corpse.InnerPawn.TryGetComp<CompIndividuality>();
    }
    if (compIndividuality != null)
    {
        return base.GetValueUnfinalized(req, applyPostProcess) +
               compIndividuality.BodyWeight;
    }
    return base.GetValueUnfinalized(req, applyPostProcess);
}

public override string GetExplanationUnfinalized(StatRequest req, ToStringNumberSense numberSense)
{
    var stringBuilder = new StringBuilder();
    var compIndividuality = req.Thing.TryGetComp<CompIndividuality>();
    if (req.Thing.def.IsCorpse)
    {
        var corpse = req.Thing as Corpse;
        compIndividuality = corpse.InnerPawn.TryGetComp<CompIndividuality>();
    }
    if (compIndividuality == null)
    {
        return base.GetExplanationUnfinalized(req, numberSense);
    }
    stringBuilder.AppendLine("BodyWeightOffset".Translate() + ": " +
                             stat.ValueToString(compIndividuality.BodyWeight));
    return $"{base.GetExplanationUnfinalized(req, numberSense)}\n{stringBuilder.ToString().TrimEndNewlines()}";
}

Should be fixed in 69da836, thanks!


xterm right-click context menu is shown only once

 Issue by tuncer
Friday Jun 24, 2016 at 17:38 GMT
Originally opened as https://github.com/Cloudef/wlc/issues/175

After the first time the right-click context menu in xterm has been displayed, any future invocation has no visible effect.

 Comment by VoidNoire
Monday Aug 15, 2016 at 10:00 GMT

This might be a dupe of #104 and SirCmpwn/sway#571


[ConstraintSystem] Remove rudimental TMF_ApplyingOperatorParameter …

…flag
It was useful when logic related to BridgingConstraint was part of
Conversion constraint, which could be generated as a result of implicit
conversion for an operator parameter.

@rudkx Noticed this while looking at how we are simplifying ApplicableFunction constraint.

@swift-ci please test source compatibility

Thanks! I noticed this a while ago and it didn’t make much sense.

@swift-ci please test


updates to free-sort plugin, new functionality

Hi All,
I've created an updated version of the free-sort plugin that has the following additional functionality:

search area shape can be square or circle
items are placed outside the area, on either side, prior to search
search area changes color to indicate (a) whether the item is inside or outside the search area, (b) when all items are inside the search area
items are magnified when dragging, the magnification factor is optional (1.5 by default)
An example of the function in use can be found on my website.

I would love to hear any feedback about how the function works (or does not work) for people, as well as about how I coded this up. I feel reasonably sure that the plugin does what it is supposed under my use case, but I haven't tested it that extensively, and I am still pretty new to javascript so may have done some things in stupid ways.
Best,
Peter

Hey Peter,
This looks great! I think it's a big improvement over the current plugin.
I'd be happy to merge in your changes when we do a future release. It would be a huge help if you would include updates to the documentation in docs/, the example in examples/, and the automated tests in tests/. If you don't feel comfortable doing some/all of that work we can take care of it, but it'll slow down our ability to include these updates.

Great to hear. I will work on docs and examples. I am not sure how tests work though.

@becky-gilbert, this is probably a good PR for you to write tests for. The existing tests are breaking here because they are designed for the old plugin. But the testing framework should be in place and we just need to tweak them for the new features.

Got it, will do! And thanks very much for all of these improvements @pjkohler !

Thanks, Becky.
I've updated the example and docs in my fork. Do I need to do a separate pull request for those changes?

Peter,
No those fork edits will automatically update the pull request, so we're good on that.
Please update the contributors.md document in the root folder too!

Hi @pjkohler, thanks again for this contribution, and sorry for taking so long to get to this!
FYI, one minor issue I noticed is that an empty prompt results in the word 'null' being added in front of the "jspsych-free-sort-counter" text. The fix is to change the prompt parameter default value from null to an empty string.
Another issue is that I can't get the prompt to display below the sort area with prompt_location: "below". It looks like the html_text (prompt and counter text) is appended to the html string after the "jspsych-free-sort-arena" div, which makes sense, but the prompt/counter text is still displayed above the "jspsych-free-sort-border" div. I'll need to look into this to figure out how to fix it.
And if you don't mind, I'd like to make a few minor changes after merging this:

add parameters to control whether or not to change the border/background colors (default to true), and what colors to use (your colors as the default)
add parameters to change the "jspsych-free-sort-counter" text (i.e. "You still need to place..." and "All items placed..."), with the text that you've used here as the default.
move the continue button to the bottom of the sort area, to improve the "jspsych-free-sort-counter" text formatting when there are multiple lines of text

Can you let me know if you have any thoughts on these changes, and if you're happy for me to make them after merging? Or if there's anything you prefer to change yourself, feel free to update the pull request. Thanks again!!

Good suggestions. I took a quick look and was able to fix the above/below issue. Although I now seem to have introduced a thing where when "below" is used, the whole search area shifts in position when it transitions to green fill. Hopefully you can resolve that, and polish a bit further as needed. The other changes (defaults etc.) are great and I hope you will make them after merging. I am a bit business here at the business end of the term, otherwise I would be happy to polish more.

@pjkohler fantastic, and thanks so much for getting back to me so quickly!


Create Workload Agnostic Scenario with ES RIs and IaCS Landing Zone Workloads

Elaborate and develop several combined (ES RIs + IaCS for LZ Workloads) solution approaches like developing quickstarts / RIs with or without AzOps and IaCS Modules (ARM via TemplateSpecs, Artifacts, etc.).
@segraef, @johansciard, @ShantnuS

We have recently converged the reference implementations to 1 single, with all the options. Can you elaborate a bit on what several 'ES RIs + IaCS for LZ workloads' means in this context?

Hey @krnese feel free to ignore this Issue since I was just coming up with ideas and tried to set this up as an item. I will rather look into the eslzArm parts anyway, Thanks!


Adding macro RETURN_IF_FAILED_SUPPRESS_TELEMETRY_IF_EXPECTED

Closes #425.
For the result macros, when one sets a telemetry fallback provider with SetResultTelemetryFallback() and a logging callback with SetResultLoggingCallback(), we always log and send telemetry for HRESULT failures in the RETURN_ macros.
The _EXPECTED macros allows one to skip the reporting for some expected HRESULTs, but that suppresses both logging and telemetry. There was no alternative if one wanted to always log failures but just suppress telemetry in case the HRESULT was expected.
The new macro RETURN_IF_FAILED_SUPPRESS_TELEMETRY_IF_EXPECTED returns an HRESULT if it failed, always logging those failures, but sends a suppressed telemetry callback if the HRESULT matches one of the expected HRESULT values.
The way this is done is leveraging the existing enum FailureFlags::SuppressTelemetry. This enum makes the telemetry callback be called with alreadyReported as true.
There is a new parameter FailureFlags to the internal ReturnHr methods in result_macros.h.
New tests were added to check the feature behavior.

@microsoft-github-policy-service agree


lib, types: Implement string accessors for some padded fields

First of all, thanks a ton for your work on this! It's been invaluable.
This PR adds a library-private helper, str_from_blank_padded, and uses it to implement some convenience accessor functions for a few of the blank-padded fields in the PKCS#11 types.
It also implements the Display trait for CK_VERSION, using the common MAJOR.MINOR format.
Please let me know if there's anything else I can do!

 I'd be happy to help with those tasks (time permitting on my side 😄).

I have added one suggestion in a comment inline, however, more in general ... come to think of it, can you investigate if maybe implementing std::convert::Into (or probably even better std::convert::From) is even better? This way we wouldn't need any additional methods on CK_INFO and CK_SLOT_INFO and we could still access the properties just like simple strings when required.

Yeah, I considered this approach. I wasn't sure what to do about the multiple fields, though -- would std::convert::From<CK_SLOT_INFO> for String return the manufacturerID, the slotDescription, or both concatenated?
Alternatively, I think I could use the newtype pattern to strongly alias [CK_UTF8CHAR; N] and implement std::convert::From there. I haven't tried that yet, but I think that gets around the restrictions on external traits + types.
In either case, I completely agree that the additional methods are an eyesore and I'd prefer to remove them in this PR 🙂

Yeah, so I was hoping to do something like this:
pub struct PaddedString<'a, const N: usize>(pub &'a [CK_UTF8CHAR; N]);

impl std::convert::From<PaddedString<'_>> for String {
  fn from(field: PaddedString) -> String {
    str_from_blank_padded(field.0)
  }
}

And replace each use of [CK_UTF8CHAR; 32] or similar with PaddedString<32>.
But that requires const generics, which are still unstable.
I think the other option would be to newtype CK_UTF8CHAR itself. Will experiment with that.

Yeah, this doesn't work either:
/// an 8-bit UTF-8 character
pub struct CK_UTF8CHAR(CK_BYTE);
pub type CK_UTF8CHAR_PTR = *mut CK_UTF8CHAR;

impl std::convert::From<[CK_UTF8CHAR; 32]> for String {
  fn from(field: [CK_UTF8CHAR; 32]) -> String {
    // ...
  }
}

Since arrays are treated as always foreign, even when their members are local to the crate 😞

This works, but doesn't get us a transitive String::from:
pub struct PaddedString(pub String);

impl std::convert::From<PaddedString> for String {
  fn from(field: PaddedString) -> String {
    field.0
  }
}

// We'd need to duplicate or macro this for 16 and 64 as well.
impl std::convert::From<[CK_UTF8CHAR; 32]> for PaddedString {
  fn from(field: [CK_UTF8CHAR; 32]) -> PaddedString {
    PaddedString { 0: str_from_blank_padded(&field) }
  }
}

@woodruffw ah bummer :( ... but maybe the duplication route for 16 and 64 is the one which will provide us with the best experience at the moment. As long as it keeps a stable API which will convert well, we can "fix" this once Rust provides us with the toolkit for it.
What do you think? You have been experimenting with this more than me by now...

Yeah, I think the duplication route is probably the best for now -- it still requires a nested PaddedString::from on every String::from, but it avoids manual method implementations.
I have one more idea that I want to try: we might be able to use generic-array, which works with Rust stable (1.41+). I'll experiment with that a bit and see I can get it to work; if not then I think the double-wrapper is a decent compromise until const generics arrive 😄

This is sort of what I had in mind. I wouldn't do it on CK_INFO or CK_SLOT_INFO directly.

Yeah, that's what I figured 🙂. I tried that with the PaddedString impl in https://github.com/mheese/rust-pkcs11/pull/26#issuecomment-612959386, but ran head-first into the const generics issue. Maybe I can do the duplication there, instead; will try.

Aha! This works:
#[derive(Debug, Copy, Clone, Default)]
pub struct PaddedString32(pub [CK_UTF8CHAR; 32]);

impl std::convert::From<PaddedString32> for String {
  fn from(field: PaddedString32) -> String {
    str_from_blank_padded(&field.0)
  }
}

So I can either macro or manually duplicate that for 16/32/64, and add a NOTE indicating that it should be refactored into a const generic when they become available 🙂.

@woodruffw cool! let's do the dupliction for now... If you look at all the places where CK_UTF8CHAR is used, it's pretty limited, and is also never returned as a slice anywhere. So they are in the fixed locations.
So I think we can live with this at the moment.
Can you also do the couple of places where CK_CHAR is used? It's the same as with the utf8 variant. Never returned as a slice, and just part of static structs.
Last but not least, maybe putting these helpers into a helper module within types might be a good idea. The general idea behind types.rs was to basically mirror pkcs11t.h.

Last but not least, maybe putting these helpers into a helper module within types might be a good idea. The general idea behind types.rs was to basically mirror pkcs11t.h.

Sounds good!

Done! We now have the types::padding module, which contains PaddedString{16,32,64} as newtypes for [CK_UTF8CHAR; N].
I'll add some additional assertions to the tests to make sure things pass through as expected 🙂

@woodruffw can you also add this one here while you are at it?

Can you also do the couple of places where CK_CHAR is used? It's the same as with the utf8 variant. Never returned as a slice, and just part of static structs.

ok, never mind ... let's merge this first! I'll do this and some minor changes afterwards myself.
This is good work! Thanks again!

Thanks a ton! Would it be possible to get a release cut for these changes (once you're done with your fixups)?

@woodruffw yes, I'm planning to do a 0.5.0 release soon (either today or in the next couple of days), there are some other breaking changes in master right now.

@woodruffw please check out this PR which I have just merged: https://github.com/mheese/rust-pkcs11/pull/28
My worry right now with the change we made is that the arrays are now encapsulated in structs and that might have side-effects on the C representation of the types. I think it is fine and also the Windows build passed, but there are also not enough checks/assertions yet in the retrieved data from the info, slot_info, token_info objects.

Yeah -- I can work on some additional assertions for those structures.
From the language reference, it sounds like repr(C) (which you added) should be sufficient for most ABIs. repr(transparent) would also probably do the trick, but shouldn't be necessary.

It looks like Emscripten might be the only ABI where repr(C) is insufficient, based on https://github.com/rust-lang/rust/issues/41483. But that concerns a newtype that wraps a primitive, not an array like we do, so it may not apply.

@woodruffw awesome link!
I believe this is though exactly what we are looking for, no? repr(transparent) on the newtype
https://github.com/rust-lang/rfcs/pull/1758 is merged as well and available.

I believe this is though exactly what we are looking for, no? repr(transparent) on the newtype

Yes, I think so. I'm still having a little trouble parsing the RFC to understand what underlying ABI it enforces, but this comment seems to suggest that it does what we want it to.

@woodruffw yes, that's exactly the comment on which I have based my conclusion as well! :D ... anyway, I changed it for now. I want to complete some more of the unit tests before I do another release. I already found a bug yesterday for a wrong assumption of mine on how to handle encrypt_final/decrypt_final.


Include link to expanded grid

Include link to expanded grid. New grid has been uploaded to production

@JM-GA I just made a minor edit

Hey @JM-GA, what's the difference between these two files?

https://data.dea.ga.gov.au/derivative/ga_summary_grid_c3_extended_mapping.geojson
https://data.dea.ga.gov.au/derivative/ga_summary_grid_c3_expanded.geojson

Hi @robbibt, I created a mapping between old and new grids, but then I realised someone had already created one that was stored in dev. I have removed the one I created, and copied the one from dev into prod

Hey @JM-GA, this is likely my fault as I think I originally generated this grid, but just noticed that we have some weird issues down in the south:

If yours doesn't have this problem, perhaps we could upload it and rename it "ga_summary_grid_c3_expanded.geojson"?

Thanks for checking @robbibt, I have swapped it out with my version - it seems to be ok


Low views with uploader.

Does it happen to anyone else that using the uploader you have few views? If I upload something manually with the same browser, IP and PC, I have almost 10 times more views than if I upload it with the uploader.

Does it happen to anyone else that using the uploader you have few views? If I upload something manually with the same browser, IP and PC, I have almost 10 times more views than if I upload it with the uploader.

Does the video have 0 views or over 100 views?

Does it happen to anyone else that using the uploader you have few views? If I upload something manually with the same browser, IP and PC, I have almost 10 times more views than if I upload it with the uploader.

Does the video have 0 views or over 100 views?

Those that I publish with uploader have less than 100, those that I publish manually have more than 1000.

Does it happen to anyone else that using the uploader you have few views? If I upload something manually with the same browser, IP and PC, I have almost 10 times more views than if I upload it with the uploader.

Does the video have 0 views or over 100 views?

Those that I publish with uploader have less than 100, those that I publish manually have more than 1000.
Do you use proxies?

Does it happen to anyone else that using the uploader you have few views? If I upload something manually with the same browser, IP and PC, I have almost 10 times more views than if I upload it with the uploader.

Does the video have 0 views or over 100 views?

Those that I publish with uploader have less than 100, those that I publish manually have more than 1000.

Do you use proxies?

Does it happen to anyone else that using the uploader you have few views? If I upload something manually with the same browser, IP and PC, I have almost 10 times more views than if I upload it with the uploader.

Does the video have 0 views or over 100 views?

Those that I publish with uploader have less than 100, those that I publish manually have more than 1000.

Do you use proxies?

No, I use the same IP to publish them by the uploader and manually.

The uploader is alone insufficient to avoid detection.

Thank you very much for the clarification! And what do you recommend?

It is going to take some testing on your part. It has been a while since I have looked more closely into this so I am not too sure what is correct to do now.


Adds Pre-commit

Adds a setup file for pre-commit. This allows the linters to be ran in local before pushing a pr. To install do the following:

Type in pip install pre-commit
Inside an individual repo type in pre-commit install
After this users will have to fix linting issues before a commit will go through.

Note: The pre-commit hooks can be skipped by adding -n to a commit
The following linters were added:

autoflake: used in github actions
isort: used in github actions
black: used in github actions
flake8: used in github actions
Some basic builtins: check-yaml, end-of-file-fixer, trailing-whitespaces, check-merge-conflict, detect-private-key
codespell: makes sure that words in code are spelled correctly
pyupgrade: checks for outdated syntax in python

This looks good, thanks.
My only concern is that we already have these in scripts/check bash script, can we somehow make use of that instead of re-defining these again?

Also im not sure if the output would look as good.

Yeah I also use check on my local, so I was thinking if we could use them as git hooks.

I will look into this this weekend.

Yeah I think if we run scripts/check in pre-commit that should be alright.

Much simpler!


Test Instances vs. Instantiation of Test Classes as Beans (@Producer, @Nested)

Great project and all the examples and explanations work as advertised.
Later I found out that a few successful yet unexpected and some failed attempts to instantiate another test class instance by CDI made me wonder.
Instantiation fails with @Nested classes which JUnit requires not to be static and hence never have a no-arg constructor and are not eligible bean classes.
Such classes are silently ignored by Weld whether or not added to Weld as bean classes, I have the impression which also matches CDI specs according to my understanding, and tests may fail.
Successful second instantiation of a test class happens by CDI if added to Weld and it contains a @Produces annotated member field or method. @Inject alone does not seem to be affected. Haven't checked yet with @Disposes and maybe other stuff (or tried to inject a test into a bean).
Although perfectly compliant with the CDI specs, I initially expected that only JUnit would instantiate test classes as usual until I had a closer look what really happened.
Naturally, this is confusing. For example I would expect people writing tests to refer to a @Produces field and expect the same value or instance as injected anywhere else.
The readme addresses the topic in a brief and very honest way.
https://github.com/weld/weld-junit/blame/master/junit5/README.md#L234-L235

The first option is to add a producer method to the test class and add the test class to the deployment.
The test class will be recognized as a bean and therefore the producer will also be discovered.

https://github.com/weld/weld-junit/blame/master/junit5/README.md#L271

This should work in most of the cases (assuming the test class meets some conditions) although it's a little bit cumbersome.

(Sorry for the blame links but I knew no other way the line numbers work in markdown files.)
Not using @Produces in test classes and defining @Produces fields and methods in separate classes that meet CDI bean requirements and add them to Weld instead of the test classes works always afaik. However, having @Produces directly in test classes is very handy and saves quite some lines of code. Until wiser perhaps, I'd try to improve weld-junit rather than changing the readme.
There is a possibility now to instantiate test classes for JUnit. I don't think that already existed when the comment below was written.
https://github.com/weld/weld-junit/blob/master/junit5/src/main/java/org/jboss/weld/junit5/auto/TestInstanceInjectionExtension.java#L41-L44

NOTE: When JUnit 5 provides a test instance creation extension point this
should be removed and the test instance should be obtained from the
container via proper CDI methods.
https://github.com/junit-team/junit5/issues/672

With such an approach I see some points with difficulties or to be considered (which may look different now than at the time the comment was written):

JUnit extensions can be applied to individual methods. And the test instance lifecycle can be "per-class". The result of such a combination is unclear to me.
There must be at most one extension with a TestInstanceFactory which I consider a most natural constraint but not exactly flexible and better avoided in the first place.
Just like before and also with a TestInstanceFactory, injection should not be carried out immediately after instantiation and before all other extensions, as for example in @Produce @Mock Type field; in combination with @ExtendWith(MockitoExtension.class) or it might produce null.
Thinking towards a most pure CDI approach to identify test classes as beans by CDI, I could imagine something like @Test as a qualifier but then it quickly becomes unclear when it comes to @Nested, parameterized, or dynamic tests. A class cannot be annotated @Produces with or without @Nested and the nested test classes and dynamic tests have to be defined somewhere.
With a TestInstanceFactory, @Nested tests still aren't valid beans.
It might be possible to somehow "explain" Weld how to get the parameter for @Nested test classes constructor such as with an around constructor interceptor or whatever but that still might invoke a constructor resulting in another instance of the test class. Besides, such magic, if feasible at all, could be used just as well without a TestInstanceFactory, I guess.

Therefore I opt against the comment above and prefer to keep test instantiation completely with JUnit.
In my opinion, weld-junit should not (even attempt to) instantiate test classes, (probably not even when explicitly added to Weld and if only so for compatibility).

I took the example from the readme https://github.com/weld/weld-junit/blame/master/junit5/README.md#L238-L268 and extended it a little bit to demonstrate my point:
package org.jboss.weld.junit5.bean;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertSame;

import javax.enterprise.inject.Produces;
import javax.inject.Inject;

import org.jboss.weld.junit5.WeldInitiator;
import org.jboss.weld.junit5.WeldJunit5Extension;
import org.jboss.weld.junit5.WeldSetup;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mockito;

@ExtendWith(WeldJunit5Extension.class)
class ReadmeTestClassProducerTest {

    {
        System.out.println("new "
                + getClass().getSimpleName());
    }

    interface Bar {
        String ping();
    }

    static class Foo {
        {
            System.out.println("new "
                    + getClass().getSimpleName());
        }

        @Inject
        Bar bar;

        String ping() {
            return bar.ping();
        }
    }

    @WeldSetup
    WeldInitiator weld = WeldInitiator
            .from(Foo.class, ReadmeTestClassProducerTest.class)
            .build();

    // Mock object provided by Mockito
    Bar barMock = Mockito
            .when(Mockito.mock(Bar.class).ping())
            .thenReturn("pong").getMock();

    @Produces
    Bar produceBar() {
        System.out.println(getClass().getSimpleName()
                + ".produceBar: this = " + this);
        return barMock;
    }

    @BeforeEach
    void beforeEach() {
        System.out.println(getClass().getSimpleName()
                + ".testFoo: this = " + this);
    }

    @Test
    void testFoo() {
        assertEquals("pong", weld.select(Foo.class).get().ping());
        Mockito.verify(barMock).ping();
        /*
         * => Wanted but not invoked:
         * bar.ping();
         * -> at org.jboss.weld.junit5.bean.ReadmeTestClassProducerTest.testFoo(ReadmeTestClassProducerTest.java:61)
         * Actually, there were zero interactions with this mock.
         */
    }

    @Test
    void testSameFooBarInject() {
        assertSame(barMock, weld.select(Foo.class).get().bar);
        // => org.opentest4j.AssertionFailedError: expected: <Mock for Bar, hashCode:<PHONE_NUMBER>> but was: <Mock for Bar, hashCode: 99042020>
    }

    @Test
    void testSameFooBarParameter(Foo foo) {
        assertSame(barMock, foo.bar);
        // => org.opentest4j.AssertionFailedError: expected: <Mock for Bar, hashCode: 17331878> but was: <Mock for Bar, hashCode:<PHONE_NUMBER>>
    }

}

All three tests fail.

Another example:
package org.jboss.weld.junit5.nested;

import static org.junit.jupiter.api.Assertions.assertNotSame;
import static org.junit.jupiter.api.Assertions.assertSame;

import javax.enterprise.inject.Produces;
import javax.inject.Inject;

import org.jboss.weld.junit5.auto.EnableAutoWeld;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;

@EnableAutoWeld
class ProducesBeanAndTestInstanceTest {

    class MyBean {
    }

    @Produces
    MyBean producesMyBean = new MyBean();

    @Inject
    MyBean injectMyBean;

    @Test
    void testMyBeanSameInstance(MyBean myBean) {
        assertSame(producesMyBean, myBean);
        assertSame(injectMyBean, myBean);
        assertNotSame(new MyBean(), myBean);
    }

}

class ProducesBeanAndTestInstanceNestedTest {

    @Nested
    class NestedProducesBeanAndTestInstanceNestedTest
    extends ProducesBeanAndTestInstanceTest {
    }

}

This fails with the current master of junit-weld due to a circular dependency in ProducesBeanAndTestInstanceTest (which is could probably be fixed with adding @ApplicationScoped to @Produces MyBean but then resulting in a proxy injected instead the real instance) and with an unsatisfied dependency (due to no no-arg constructor of NestedProducesBeanAndTestInstanceNestedTest in NestedProducesBeanAndTestInstanceNestedTest.
With https://github.com/weld/weld-junit/compare/master...philippkunz:nested-v2#diff-a8ebe4626a99c844858b12012399d8fb it works, (but please don't just start yet to review that code or vomit from looking at it, it's not even a draft yet).

Hello,
that's some massive wall of text, I will try to respond with quotes, if I forget to answer something, please point that out.

Instantiation fails with @Nested classes which JUnit requires not to be static and hence never have a no-arg constructor and are not eligible bean classes.
Such classes are silently ignored by Weld whether or not added to Weld as bean classes, I have the impression which also matches CDI specs according to my understanding, and tests may fail.

True, such classes are accordingly to CDI spec not considered beans. Not sure whether we do anything special about these classes, as in preventing any errors being thrown. That might come directly from Weld and usually you'd have at least a LOG msg about it, albeit maybe you would need to have lower logging level to make it pop up.

Successful second instantiation of a test class happens by CDI if added to Weld and it contains a @Produces annotated member field or method. @Inject alone does not seem to be affected. Haven't checked yet with @Disposes and maybe other stuff (or tried to inject a test into a bean).

Few things here. Firstly you correctly discovered that this project was written back when you could not provide JUnit with an instance of the test class. For this reason we couldn't make test classes beans by default and instead had to treat them as non-contextual injection targets (for purpose of @Inject in test classes).
IIRC then if you placed a producer on test class, what we did was that we made it into a bean, effectively forcing Weld to create secondary instance of the test class which had no state and no affiliation to the actual test class where test execution happens. The only purpose was to enable those producers (which, accordingly to CDI spec need to reside in a CDI bean).

For example I would expect people writing tests to refer to a @Produces field and expect the same value or instance as injected anywhere else.

True, this case can differ, the object reference will be different. OTOH it is a bit of an edge case because it only affects producer fields (methods should be fine unless I am missing something?) and you have to access them directly. You don't normally do that in CDI. You mark it as producer so that you can @Inject it elsewhere. But granted, this can break.

With such an approach I see some points with difficulties or to be considered (which may look different now than at the time the comment was written):

The comment you are referring to is pretty outdated, back there we just saw that it is something JUnit plans and it looked promising. I think we even revisited the idea and decided against it some time ago.

JUnit extensions can be applied to individual methods. And the test instance lifecycle can be "per-class". The result of such a combination is unclear to me.

I don't know either but overall it seems to me that there is little use in applying weld-junit on an individual method (as in apply to one method and not to other in same test class).

There must be at most one extension with a TestInstanceFactory which I consider a most natural constraint but not exactly flexible and better avoided in the first place.

+1, there are quite a few weird situations happening once you start combining several JUnit 5 extensions. TestInstanceFactory is one of the issues, then there is parameter resolution and order of extension execution can also matter....

Just like before and also with a TestInstanceFactory, injection should not be carried out immediately after instantiation and before all other extensions, as for example in @Produce @Mock Type field; in combination with @ExtendWith(MockitoExtension.class) or it might produce null.

So, if you were to make the test class a CDI bean, that would mean the injection points in the bean get resolved the moment you create that bean. Which could then be an issue in combination with other extensions.

Thinking towards a most pure CDI approach to identify test classes as beans by CDI, I could imagine something like @Test as a qualifier but then it quickly becomes unclear when it comes to @Nested, parameterized, or dynamic tests. A class cannot be annotated @Produces with or without @Nested and the nested test classes and dynamic tests have to be defined somewhere.

I don't see how that would help. If it were a qualifier, you are now putting a qualifier on a bean method. What good would that be?

With a TestInstanceFactory, @Nested tests still aren't valid beans.

That's a hard constraint IMO, CDI doesn't allow it, neither should we.

It might be possible to somehow "explain" Weld how to get the parameter for @Nested test classes constructor such as with an around constructor interceptor or whatever but that still might invoke a constructor resulting in another instance of the test class. Besides, such magic, if feasible at all, could be used just as well without a TestInstanceFactory, I guess.

Not quite sure what are you getting at with this?

I took the example from the readme https://github.com/weld/weld-junit/blame/master/junit5/README.md#L238-L268 and extended it a little bit to demonstrate my point:

Ok, thanks for example, I see what you mean.
The field reference differs because of the double instantiation and the fact that the bean will use the other instance.

As for your other example, that one is actually illegal in regards to circularity. CDI spec mandates that if there is a circular dependency, at least one bean needs to be normal scoped (non-dependent) so that it can be resolved.
Quoting from here:

The container is required to support circularities in the bean dependency graph where at least one bean participating in every circular chain of dependencies has a normal scope, as defined in Normal scopes and pseudo-scopes. The container is not required to support circular chains of dependencies where every bean participating in the chain has a pseudo-scope.

(which is could probably be fixed with adding @ApplicationScoped to @Produces MyBean but then resulting in a proxy injected instead the real instance) and with an unsatisfied dependency

Proxy injection is expected for normal scoped bean. The unsatisfied dependency you are seeing shouldn't be due to constructor, if the bean were legal bean type and only the constructor would be missing, I think it would blow up with that. I think it is again related to what classes are considered beans by CDI.

With master...philippkunz:nested-v2, particularly with TestInstanceInjectionExtension.java it works

Ok, won't review yet. But truth be told I am now not sure what is it you are trying to fix here. Nested classes won't really work with CDI, not the non static ones at least (am I right @mkouba?). As for the double instantiation of test classes, I am not sure how to remedy that without providing the test class as bean which then presents a whole lot of other issues as you yourself pointed out.

As a summary I think that JUnit has its own concepts to instantiate classes and so has CDI.
Both don't match well without any further consideration and my currently preferred and proposed approach would be to prevent CDI to instantiate test classes and leave that solely to JUnit.

and you have to access them directly. You don't normally do that in CDI. You mark it as producer so that you can @Inject it elsewhere. But granted, this can break.

Referring to member variables directly looks too tempting for me to assume this not to be normal. In contrary, I'd rather assume this to be the most normal thing in JUnit tests.

we just saw that it is something JUnit plans and it looked promising. I think we even revisited the idea and decided against it some time ago.

That's what I figured, too. We both seem to agree on that even now it is possible to provide test instances to JUnit we still don't want it. That also renders few other discussion points redundant.

With a TestInstanceFactory, @nested tests still aren't valid beans.

That's a hard constraint IMO, CDI doesn't allow it, neither should we.

If that means, weld-junit should not support @Nested tests, I have some reservations. It obviously does not work ootb, but that does not mean it cannot be helped.
Whether something should be done or not to support it is in my opinion the core topic here. And either way it would be nice if it be justified and documented.

As for your other example, that one is actually illegal in regards to circularity. CDI spec mandates that if there is a circular dependency, at least one bean needs to be normal scoped (non-dependent) so that it can be resolved.

I think it works because of
https://github.com/weld/weld-junit/blob/529c040bf3dc4d1b0d01f5a327d5de5b42f27c93/junit5/src/main/java/org/jboss/weld/junit5/auto/TestInstanceInjectionExtension.java#L90
but haven't specifically checked or confirmed.

Nested classes won't really work with CDI, not the non static ones at least

Nested test classes are never static in JUnit, I believe. If these are static, JUnit refuses to recognize them as nested.

I am not sure how to remedy that without providing the test class as bean

At the moment I also don't see exactly how it is done best in every detail but a few experiments inforced some hope that it can be achieved by processing the test classes' annotations of the CDI world.
More or less like @Inject works on test instances now, which also aren't instantiated again by CDI (unless @Produces present which I currently consider wrong), with some "magic glue" that connects CDI with JUnit.
Can TestInstanceInjectionExtension be changed in a way that it "kind of redirects" accesses to @Produces field and methods to test instances in a similar way it already does when injecting?
https://github.com/weld/weld-junit/blob/529c040bf3dc4d1b0d01f5a327d5de5b42f27c93/junit5/src/main/java/org/jboss/weld/junit5/auto/TestInstanceInjectionExtension.java#L106-L108

my currently preferred and proposed approach would be to prevent CDI to instantiate test classes and leave that solely to JUnit.

That's what is currently done as far as test instance creation goes.

Referring to member variables directly looks too tempting for me to assume this not to be normal. In contrary, I'd rather assume this to be the most normal thing in JUnit tests.

Fields in test for sure, but injections inside beans, not so much. Take for instance any normal scoped beans for which you have a proxy created. Those beans usually inject fields and make those fields private/protected and expose the values via getters. Anyhow, the issue here is the existence of two instances one of which is purely for bean creation purposes.

Whether something should be done or not to support it is in my opinion the core topic here. And either way it would be nice if it be justified and documented.

I don't really know the original reasoning as to why CDI choose not to support it but my guess would be that it has to do with instantiation and proxies. E.g. with a non-static nested class in order to instantiate inner class, you need to instantiate the outer class. That leaves you with an extra "bean instance" hanging in there. Other things to consider are limitations on the class - constructors for one need to be no-args for both classes. @mkouba do you remember what were the limitations why nested classes cannot be beans?

I think it works because of ...

That's singleton which isn't a normal scope (doesn't use proxy), that still shouldn't do the trick.

Nested classes won't really work with CDI, not the non static ones at least

Nested test classes are never static in JUnit, I believe. If these are static, JUnit refuses to recognize them as nested.

Exactly, that's why I pointed out CDI spec section describing it. The two (CDI and JUnit specs) both recognize different setups limiting valid setups. Note that in CDI TCK there is very likely a test assuming that a nested non-static class will not be considered a bean.

More or less like @Inject works on test instances now, which also aren't instantiated again by CDI (unless @Produces present which I currently consider wrong), with some "magic glue" that connects CDI with JUnit.

So the reason why we can make @Inject work on an instances that aren't "ours" (as in we don't instantiate them) is because CDI offers an API for that. It is not a common feature. nonetheless it is supported one. It works because we already have a class with all the annotations needed, so what Weld does is basically "scan" the class for injection points and try to resolve them on-demand. This is why we ask JUnit for the created test instance and then enrich it. This code shows a simple version of how it is done.

Can TestInstanceInjectionExtension be changed in a way that it "kind of redirects" accesses to @Produces field and methods to test instances in a similar way it already does when injecting?

No and the reason is that CDI doesn't "know" about the producer method. When you initialize CDI deployment, the impl needs to go through the classes and discover all the extensions, beans and so on. The way this is done can differ and what is discovered also differs based on discovery modes. It also discovers all injection points and can then perform validation of them before you get to runtime. For this to work, you need to know all beans (be it class-based or producers) before you boot up. The issue is that the producer can use or store some internal state in the instance from which it is created (which in normally a bean). So we cannot even do anything via extensions. The only "clean" solution would be to provide the instance outselves, but we already ruled that out as bad option :-/

It still looks like insisting on the cleanest approches for both JUnit and CDI results in a conflict regarding instatiating test classes as both want to instantiate them (as we already know).
I found another related piece of text:
https://docs.jboss.org/weld/reference/latest/en-US/html/extend.html#_the_injectiontarget_interface

Note
We recommend that frameworks let CDI take over the job of actually instantiating the framework-controlled objects. That way, the framework-controlled objects can take advantage of constructor injection. However, if the framework requires use of a constructor with a special signature, the framework will need to instantiate the object itself, and so only method and field injection will be supported.

As I now had another look at it, I found that test classes are not instantiated again by CDI in addition to the instance created by JUnit with @EnableAutoWeld. It only happens with @EnableWeld and @WeldSetup and adding the test class to the deployment explicitely, which is at least acceptable o even desired considering this the advanced way to configure weld with full power and control. Sorry, for all the fuzz I wrote.
@Nested test classes are a different story still. Ideally, I figure initially, @Nested test classes should work as similar as possible to non-@Nested ones. In theory, that should not be a big deal, assuming instantiation solely with JUnit. In practive, however, Weld filters @Nested test classes away from the deployment with isTopLevelOrStaticNestedClass in
https://github.com/weld/core/blob/b7745266bc674d145cddd19d26c5d6f0f3966193/impl/src/main/java/org/jboss/weld/util/Beans.java#L445-L450
due to the lack of a no-arg constructor.
This may not be the most reasonable behaviour in the current context considering such a constructor would never be used for a @Nested class and the test instance provided by JUnit would be used instead. Injection into the test classes, even @Nested ones is not affected but all other CDI annotations such as @Produces etc. don't work like that because @Nested test classes are not processed as part of the deployment as opposed to top-level test classes.
In order to make @Nested test classes work as similar as possible to top-level test classes, one option I figure would be to add some similar code like the following and related
https://github.com/weld/core/blob/b7745266bc674d145cddd19d26c5d6f0f3966193/impl/src/main/java/org/jboss/weld/bootstrap/AbstractBeanDeployer.java#L188-L198
However, I don't see a feasible way not to duplicate quite a portion of code from Weld and I rather wouldn't.
That's probably essentially what was stated in above comments already and now I hope I also understood it.
What leaves to be considered could be to clarify the readme. I'm not sure this is optimal yet but what about https://github.com/weld/weld-junit/pull/104?

Finally I guess I found again what confused me in the very beginning. Sorry for the now misleading branch name of #104.
https://github.com/philippkunz/weld-junit/blob/nested-readme/junit5/src/test/java/org/jboss/weld/junit5/nested/TopLevelTestProducesSameInstanceInjectIntoNested.java#L1-L50
Most changes in #104 are not directly related but were inspired by continuous integration feedback and a consequence of the use of JUnit 5's more recent ExtensionContext API now providing access to outer test instances making the TestInstancePostProcessor redundant now that used to store test instances in the extension context.
Most unsure am I still regarding the changes in the readme. It's not very easy to write it precise, compact, and useful at the same time. I hope it is clearer now but I don't expect it to be perfect already. If not asked too much, I would appreciate any suggestion, (not only to the readme of course).

Ok, so to sum up the what's in the PR (since the discussion here is really long) - it actually doesn't change user behaviour, instead it aims to improve docs and changes some internals in regards to how injection is performed. Do I get that right?
I dropped some comments on the PR.

Well, almost.
Assuming "user behaviour" as "behaviour of weld-junit as experienced by software using weld-junit through its public and documented API", there is one change. Before the change, a @Nested test may have instantiated the outer-most test class twice. I write "may" because know it could happen but don't know if it happened always. One instance was created by JUnit as desired and another one by Weld because TestInstanceInjectionExtension.rewriteTestInstanceInjectionTarget only caught the inner-most test instance and could have instantiated the outer-most test class again instead of redirecting or forwarding the injection target to the test class instance already instantiated by JUnit. Other than outer-most test classes could not be instantiated twice this way because @Nested test classes don't meet valid bean requirements and are ignored by Weld.
https://github.com/philippkunz/weld-junit/blob/nested-readme/junit5/src/test/java/org/jboss/weld/junit5/auto/nested/OuterTestClassAndBeanSameInstanceTest.java
I created OuterTestClassAndBeanSameInstanceTest to demonstrate the change.

And yes, I think the readme can possibly be improved and I attempted that.
And then, I needed access to outer test instances and used the more recent JUnit API for that, just before I noticed that there was code for that and instead of undoing the new code I deleted the old one which I cannot justify in a compelling way as I now consider it again. And then the ci server told me what now became TestInstanceInjectionTarget could no longer be an anonymous inner class.

Maybe adding a fake constructor to nested test classes would do the trick.
/**
 * adds a constructor that calls super()
 */
public static void addDefaultConstructor(ClassFile file, List<DeferredBytecode> initialValueBytecode, final boolean useUnsafeInstantiators) {
    addConstructor(BytecodeUtils.VOID_CLASS_DESCRIPTOR, new String[0], new String[0], file, initialValueBytecode, useUnsafeInstantiators);
}

https://github.com/weld/core/blob/6c2b09fac4e694a20877f017424acd6c4b3e3439/impl/src/main/java/org/jboss/weld/util/bytecode/ConstructorUtils.java#L40-L45

True, I know for instance Quarkus does the same thing for beans that are missing it. However, isn't it going a bit too far just to have the nested class be able to host producers/disposers and such?
Also, this doesn't solve the issue that in order to instantiate nested class, you need to instantiate the outer class as well. This can cause conflicts if, for instance, both were beans with different scopes. Imagine the following situation:
@ApplicationScoped
public class Foo {
  // class code...

  @Dependent
  class InnerFoo {
    // inner class code
   }
}

Now, dependent beans mean you need to instantiate it for every injection point. However, that requires you to instantiate the outer class as well. But that is against Foobeing application scoped because you would now have multiple instances out in the wild. On top of that you can add that those classes can leverage internal state of each other (access variables and so on - each will see different state).

Glad to see the discussion getting a slightly different flavor...

However, isn't it going a bit too far

As of now I don't know how far that would be. For people using weld-junit I think such a feature still looks desirable, to a certain extent at least and sure would do no harm.

in order to instantiate nested class, you need to instantiate the outer class

For a start, I imagine JUnit will continue to instantiate test classes exclusively. I guess test instances remain @Singletons like they are already now. I see test classes with other scopes as a different and presumably independent topic which I suspect by the way already exists now.
I was then not sure if I could follow all the remainder of your comment. In that area I think there is already a hopefully good and certainly specific example https://github.com/philippkunz/weld-junit/blob/nested-readme/junit5/src/test/java/org/jboss/weld/junit5/auto/nested/OuterTestClassAndBeanSameInstanceTest.java. As I understood we already agreed Weld must not instantiate test classes at all. Now image that test itself was @Nested inside another level of enclosing test class. Shouldn't it work then just the same?


Loading trained model with custom dataset

Question
Hi, I would like to ask how I can load a trained hybridize gluon model and created .params and .json file to be used in DJL?
Should I create also the synset.txt file for the list of classes then compress it as a tar.gz file?
I'd like to know what is the correct way to do it because from what I have tried, I have compressed these 3 files as a tar.gz file  then from DJL, I've tried this code to load the model:
Criteria<Image, DetectedObjects> criteria =
                Criteria.builder()
                        .optApplication(Application.CV.OBJECT_DETECTION)
                        .setTypes(Image.class, DetectedObjects.class)
                        .optModelUrls("file:///Users/home/mxnet/vgg16_atrous_custom")
                        .optFilter("backbone", "vgg16_atrous_custom")
                        .optModelName("vgg16_atrous_custom")
                        .optProgress(new ProgressBar())
                        .build();

but I am getting this error instead:
Exception in thread "main" ai.djl.repository.zoo.ModelNotFoundException: No matching model with specified Input/Output type found.
	at ai.djl.repository.zoo.ModelZoo.loadModel(ModelZoo.java:173)
	at ai.djl.examples.inference.ObjectDetection.predict(ObjectDetection.java:66)
	at ai.djl.examples.inference.ObjectDetection.main(ObjectDetection.java:48)

Thanks in advance for your help.

How to convert gluon model to symbolic: http://docs.djl.ai/docs/mxnet/how_to_convert_your_model_to_symbol.html
If you load a model directly from an URL, in most cases, you need supply a Translator:

 Translator<Image, DetectedObjects> translator = SingleShotDetectionTranslator.builder()
            .addTransform(new ToTensor())
            .optSynsetUrl("https://mysynset.txt")
            .build();

Criteria<Image, DetectedObjects> criteria =
                Criteria.builder()
                        .setTypes(Image.class, DetectedObjects.class)
                        .optModelUrls("file:///Users/home/mxnet/vgg16_atrous_custom")
                        .optTranslator(translator))
                        .build();

SingleShotDetectionTranslator.Builder, accept synset input in three way:

    .optSynsetArtifactName(String fileName): // this expect a uncompressed file in the model directory
    .optSynsetUrl(String url): // this can download synset.txt from any url
    .optSynset(String[] class): // you can pass classes directory to translator

optModelUrls() accept both local folder or an archive file (.zip/.tar), we don't expect files are compressed in model folder, DJL handle compressed file in the following case:

You created your own modelZoo and defines each file in metadata.json
You compressed your model directory into: .zip or .tar or .tar.gz file, DJL will uncompress the whole folder into cache directory automatically

When you specify optModelUrls() with only single url, you don't need define other filters or artificatId

We are working on an improvement to automatically create Translator, but this is still in progress.

Hi @frankfliu, thanks for the instruction I am now able to use the model I have trained, however, it looks like it's working but I am getting this result from the console:
[INFO ] - [
	class: "pikachu", probability: 0.99466, bounds: [x=111.045, y=283.735, width=78.567, height=103.347]
	class: "pikachu", probability: 0.99373, bounds: [x=176.363, y=246.798, width=81.334, height=120.723]
	class: "pikachu", probability: 0.98868, bounds: [x=266.975, y=159.225, width=81.803, height=120.092]
	class: "pikachu", probability: 0.98227, bounds: [x=376.517, y=251.875, width=81.409, height=120.386]
	class: "pikachu", probability: 0.97852, bounds: [x=270.541, y=244.992, width=73.484, height=124.531]
]

but when I checked the image expecting with detected bbox drawn, there's not a single bbox drawn on the image. Could you please tell me why the output is not what I am expecting? Also, I have noticed that the value of x, y, width, and height is kind of a little off compared to the car, dog, bike model.
The model I just trained for testing has only 1 class which is pikachu with very few datasets to speed up the training and the backbone I have used is the ssd_512_vgg16_atrous_custom.
Thank you.

Do you have any advice or leads on how to fix that? Thanks.

Can you share your training code?

@frankfliu sure. here is the gist > https://gist.github.com/androuino/4d8b552bb1d0474c58c40fe63c4409fe.
This is how I hybridize the trained model > https://gist.github.com/androuino/f62c6878e1c3482b97874f15b34300aa
Thanks again.

Hi @frankfliu, any leads or updates? Thank you very much.

@androuino
I think you need do the following:
Translator<Image, DetectedObjects> translator = SingleShotDetectionTranslator.builder()
            .optRescaleSize(300, 300)
            .addTransform(new Resize(300, 300))
            .addTransform(new ToTensor())
            .optSynsetUrl("https://mysynset.txt")
            .build();

The rescale will based on image size to map the bbox value to 0 - 1

Thanks @frankfliu, I will test it now and get back to you with the result.

Hello again @frankfliu, seems like it's working however, the result when I test the trained model using python, I am getting this result:

while the detection in DJL is this:

I did the changes as you suggested:
List<String> classes = new ArrayList<>();
classes.add("pikachu");
Translator<Image, DetectedObjects> translator = SingleShotDetectionTranslator.builder()
        .optRescaleSize(300, 300)
        .addTransform(new Resize(300, 300))
        .addTransform(new ToTensor())
        .optSynset(classes)
        .build();

 Criteria<Image, DetectedObjects> criteria = Criteria.builder()
        .optApplication(Application.CV.OBJECT_DETECTION)
        .setTypes(Image.class, DetectedObjects.class)
        .optModelUrls("file:///vgg16_atrous_custom.tar.gz")
        .optTranslator(translator)
        .build();

And this is what I get from the console:
[INFO ] - Detected objects image has been saved in: build/output/detected-pikachu.png
[INFO ] - [
	class: "pikachu", probability: 0.99218, bounds: [x=0.678, y=0.451, width=0.249, height=0.327]
	class: "pikachu", probability: 0.99102, bounds: [x=0.467, y=0.442, width=0.245, height=0.324]
	class: "pikachu", probability: 0.98329, bounds: [x=0.155, y=0.512, width=0.245, height=0.290]
	class: "pikachu", probability: 0.97551, bounds: [x=0.638, y=0.042, width=0.241, height=0.305]
	class: "pikachu", probability: 0.97120, bounds: [x=0.491, y=0.281, width=0.231, height=0.308]
]

I don't quite understand why there's a lot of bbox drawn on the image while on the console, it only has 5 bboxes.

@androuino
You are print out the DetectedObjects using it's .toString() method, it only print out top 5 by default. But actually you got more items in the DetectedObjects
for pikachu model, you might want to set a higher threshold:
Translator<Image, DetectedObjects> translator = SingleShotDetectionTranslator.builder()
        .optRescaleSize(300, 300)
        ...
        .optThreshold(0.7)

Nice! it's working perfectly now. Thank you so much @frankfliu.


chore(comments): add inline code comments - src/utils/src/sounds.rs

What this PR does 📖

add inline code comments

The comments you added seem to be fine and working great. But the Rust formatting error is a lot, this will be fixed en masse with https://github.com/Satellite-im/Uplink/pull/424/commits/3d6701d79ed79be1beaac56d282ebd3997b7f018 when #424 is merged. Otherwise, looks fine and works for me.

yes the Rust formatting errors aren't from my side 😂 thanks for fixing them btw 🎉


Derived jenkins docker image fails during init phase on helm install with exec /usr/bin/sh: exec format error

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?
Running in Amazon Linux in an EKS cluster
based (FROM) derived docker image from:  docker.io/jenkins/jenkins:2.375.2-rhel-ubi8-jdk11
Reproduction steps

) Build the a derived docker image using the following docker source, named: XXXXXXXXXXX.dkr.ecr.us-gov-west-1.amazonaws.com/das/gw/jenkins/jenkins

FROM docker.io/jenkins/jenkins:2.375.2-rhel-ubi8-jdk11
ARG user=jenkins

USER root
# make custom changes to jenkins container for this customer

RUN dnf update -y && \
    dnf -y -q install ca-certificates jq bind-utils nmap && \
    rm -rf /var/cache /var/log/dnf* /var/log/yum.* && \
    dnf clean all -y

COPY --chown=${user}:${user} daas-sandbox-root-ca.crt /etc/pki/ca-trust/source/anchors/daas-sandbox-root-ca.crt

RUN chmod 644 /etc/pki/ca-trust/source/anchors/daas-sandbox-root-ca.crt && \
    cat /etc/pki/ca-trust/source/anchors/daas-sandbox-root-ca.crt && \
    echo run update-ca-trust && \
    update-ca-trust && \
    echo ran update-ca-trust

USER ${user}

# as specified in the jenkins Docker file,
# from a derived Dockerfile, can use `RUN install-plugins.sh active.txt` to setup $REF/plugins from a support bundle
RUN install-plugins.sh active.txt

ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/jenkins.sh"]

2.) create a values.yaml file to feed to the helm deploy which has the following settings
controller:
  image: "XXXXXXXXXXX.dkr.ecr.us-gov-west-1.amazonaws.com/das/gw/jenkins/jenkins"
  tag: "2.375.2-rhel-ubi8-jdk11"

run a helm install
Jenkins should startup without issue.
Expected Results
Jenkins should startup without issue.  Init container should install all the plugins, then the jenkins pod should boot strap and start the jenkins app.
Actual Results
It fails at container init.  The following error shows in the log
hector$ kc logs -n cicd jenkins-0 -c init
exec /usr/bin/sh: exec format error

hector$ kc get pods -n cicd
NAME        READY   STATUS                  RESTARTS         AGE
jenkins-0   0/2     Init:CrashLoopBackOff   46 (2m47s ago)   3h34m

The events from this command is
kc describe pod -n cicd jenkins-0
Events:
  Type     Reason   Age                      From     Message
  ----     ------   ----                     ----     -------
  Normal   Pulling  34m (x41 over 3h34m)     kubelet  Pulling image "XXXXXXXXXXX.dkr.ecr.us-gov-west-1.amazonaws.com/das/gw/jenkins/jenkins:2.375.2-rhel-ubi8-jdk11"
  Warning  BackOff  4m11s (x969 over 3h34m)  kubelet  Back-off restarting failed container

Anything else?
What am I doing wrong in my derived Dockerfile?

Hi @hectoralicea , what is the kind of CPU used for the nodes in your Kubernetes cluster?
The errors sounds like an Intel (linux/amd64) Docker image executed on an ARM (linux/arm64) machine (but I could be wrong).

yea, I just realized this.  I'm building this on a M1 MacBook, and but running on an EKS cluster inside an Amazon Linux which I presume is x86-64.  Need to find the docker build parameter which instructs to build an linux/x86-64 architecture.

yea, I just realized this. I'm building this on a M1 MacBook, and but running on an EKS cluster inside an Amazon Linux which I presume is x86-64. Need to find the docker build parameter which instructs to build an linux/x86-64 architecture.

docker build --platform=linux/amd64 <...> is your friend as per https://docs.docker.com/engine/reference/commandline/build/ 🤗
Be warned that it might be slower on your machine (because QEMU or Rosetta will take care of emulating the amd64 platform): be patient 😅
I'm closing the issue as it's not a problem with the Jenkins Docker image.


NordVPN Token Authentication for WireGuard

The method to extract a Private Key seems to be overly convoluted, can the image be updated to allow the use of the Token instead that NordVPN provides on the NordVPN user's account dashboard?

I don't think this is possible for the time being because of how Gluetun is programmed to block all traffic not through the VPN, and that would require some exchange with the nordvpn API (AFAIK). We can keep this opened, this may change in the future (not weeks, more in a few months).


Workaround for #772: Downgrade maven-bundle-plugin to v2.x.

Workaround for #772: Downgrade maven-bundle-plugin to v2.x. This enables JDK6 builds.

Great, thank you!


TypeError: ProactorEventLoop is not supported, got:

Hi elacuesta,
I am new to playwright and scrapy. And I met a problem that after I set the configuration (Download Handler and Twisted reactor), the main code is just the 'Basic usage' you showed in Readme.md. And after I run the code in windows, It shows that "TypeError: ProactorEventLoop is not supported, got: ", I think it is about the Twisted part but I dont know what exactly happened. Did I make any mistakes? Thanks!
Regards,
Ethan

Hey Ethan, indeed it's not currently possible to use this package directly on Windows (#7). I haven't tested it myself, but according to this comment it works well under WSL2 (Windows Subsystem for Linux). I will update the readme with a note about this, thanks for bringing it up.

Well noted. Thanks, elacuesta!


The arguments for vsetvli instruction

Hello, I am confused about the arguments for vsetvli instruction in the vector test loop.
vsetvli t0, a2, e8,m1  uses a2 as the AVL to set vl register, but a2 = src2, a3 is actually the number of vector elements.
Is there anything wrong?
# void add_data_vec_8(int8_t *dest_data, int8_t *src1, int8_t *src2, int data_num);
# a0=dest, a1=src1, a2=src2, a3=n
#
add_data_vec_8:
    // mv      a3, a0          # Copy destination
.loop_8:
    vsetvli t0, a2, e8,m1   # Vectors of 8b
    vle8.v  v0, (a1)        # Load bytes
    add     a1, a1, t0  	# Bump pointer
    vle8.v  v1, (a2)        # Load bytes
    add     a2, a2, t0  	# Bump pointer
    sub     a3, a3, t0  	# Decrement count
    vadd.vv v2, v1, v0      # Vector Add
    vse8.v  v2, (a0)    	# Store bytes
    add     a0, a0, t0  	# Bump pointer
    bnez    a3, .loop_8    	# Any more?
    ret                 	# Return

Oh yes you're right. I fixed but sorry I didn't test my fix at all.


Additional features around HA + pre-configuring HEC

Add support for deploying Splunk tiers across 3 AZs
Enable multisite clustering by default. Make both indexer and search head clustering AZ-aware
Enable Http Event Collector (HEC) in indexer tier, with a new load balancer on port 8088. Return HEC url & token as stack outputs.
Enable indexer discovery so forwarders can retrieve list of indexers dynamically

@rarsan Let me know when you are done from your side and ready to merge the changes.

Thanks for reviewing @sshvans . This is ready to be merged.


MGMT-5241 - Remove 4.8 single override from version bump script

It is no longer required because 4.8 is already part of the default versions JSON
as of this PR https://github.com/openshift/assisted-service/pull/1518

This takes over #69

cc @oshercc


Implement mkvclean & validate with mkvalidator

Mkvclean is a command line application for loseless optimization of mkv for streaming
https://www.matroska.org/downloads/mkclean.html
And after running that on the mkv files run mkvalidator to make sure they are adhering to the protocol correctly and warn users if anything is wrong.
https://www.matroska.org/downloads/mkvalidator.html
Can that be carried over to mp4 if you remux the file? Will the mp4 remux be optimized for streaming too?
Does mp4 automator do remux by default?

Already does remuxing by default and already optimizes for streaming
Would be redundant to implement this

Can you clarify how this script is doing loseless remuxing and optimizing without using mkvclean ?
I believe there is no other way to do a loseless remux while also optimizing for streaming and still being a loseless remux

Loseless remuxing is nothing special
Any sort of remuxing where no transcoding is taking place is lossless, the streams are simply moved from one container to the other without any modifications
The script will attempt lossless remuxing anywhere appropriate codec from the source video are found, then rearranges the MOOV atoms to optimize for streaming