Updated Dockerfile (include dependencies for building documentation), moved documentation to main README

Changelog / Overview
Updated Dockerfile (such that built images come with all dependencies required for building the documentation). Also, moved the user-oriented part of the docker documentation to the main README (so that these instructions are also synced to https://hub.docker.com/r/manimcommunity/manim).
Closes #994.

Testing Status
Tested the new image locally -- it builds and the documentation also builds successfully.

Checklist

[x] I have read the Contributing Guidelines
[x] I have written a descriptive PR title (see top of PR template for examples)
[x] I have written a changelog entry for the PR or deem it unnecessary
[x] My new functions/classes either have a docstring or are private
[x] My new functions/classes have tests added and (optional) examples in the docs
[x] My new documentation builds, looks correctly formatted, and adds no additional build warnings

Reviewer Checklist

[ ] The PR title is descriptive enough
[ ] The PR is labeled correctly
[ ] The changelog entry is completed if necessary
[ ] Newly added functions/classes either have a docstring or are private
[ ] Newly added functions/classes have tests added and (optional) examples in the docs
[ ] Newly added documentation builds, looks correctly formatted, and adds no additional build warnings

Thanks for this pr.
As the online binder examples also use this docker file, will it then take longer for them to build?

Thanks for this pr.
As the online binder examples also use this docker file, will it then take longer for them to build?

I'm not exactly sure I understand what you mean. The images are built on DockerHub, binder just needs to download and use the image when there is a new one. Downloading the image is what takes some time, but only for the first time. Then the image is locally available for binder, and they can access it much faster.

Then the image is locally available for binder

Ah, that is something I did not know, I thought they need to load the dependencies each time (and normally it takes approx. 30 seconds to launch a notebook), so I just was not sure if the extra dependencies would increase the loading time significantly. But when this is not the case, then perfect!


Purpose of this library

There's already an official API available for modeling a webhook response in python. What value does this library add?

Here's a link to the official one: https://dialogflow-python-client-v2.readthedocs.io/en/latest/gapic/v2beta1/types.html#dialogflow_v2beta1.types.WebhookResponse

This will be beneficial if you are building your webhook responses using pure Dialogflow JSON.


Build Scenario 5.3 - Webapp Deployment

Deployment - ok; Except being prompted about not having the Extend Location provider registered.
Added - az provider register -n Microsoft.ExtendedLocation --wait
Suggestion - adding the provider registration before?
Second deployment - OK full
Step: 2024-11-05T10-31-47Z: Checking Microsoft.ExtendedLocation RP Registration state for this Subscription, and get OID, if registered
'Custom-locations' feature couldn't be enabled on this cluster as the pre-requisite registration of 'Microsoft.ExtendedLocation' was not met. More details for enabling this feature later on this cluster can be found here - https://aka.ms/EnableCustomLocations
Microsoft.ExtendedLocation provider is not registered.  Run az provider register -n Microsoft.ExtendedLocation --wait.
(ResourceNotFound) The Resource 'Microsoft.ExtendedLocation/customLocations/arc-location' under resource group 'azrez' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix
ERROR: (ResourceNotFound) The Resource 'Microsoft.ExtendedLocation/customLocations/arc-location' under resource group 'azrez' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix
Webapp Deployment:
- Here I had a bit of trouble.
- Could not zip up the package.zip via that command, as it did not work & I did not know how to make it work, so I made the .zip manually.

The webapp webapp-6671 is now created.
To provide code to the webapp, you may use the example below:
git clone https://github.com/Azure-Samples/nodejs-docs-hello-world
cd nodejs-docs-hello-world
zip -r package.zip .
az webapp deployment source config-zip --resource-group azrez --name webapp-6671 --src package.zip
- Deployment:

$ az webapp deployment source config-zip --resource-group azrez --name webapp-6671 --src package.7z
D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\paramiko/pkey.py:100: CryptographyDeprecationWarning: TripleDES has been moved to cryptography.hazmat.decrepit.ciphers.algorithms.TripleDES and will be removed from this module in 48.0.0.
D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\paramiko/transport.py:259: CryptographyDeprecationWarning: TripleDES has been moved to cryptography.hazmat.decrepit.ciphers.algorithms.TripleDES and will be removed from this module in 48.0.0.
The behavior of this command has been altered by the following extension: appservice-kube
Getting scm site credentials for zip deployment
<urllib3.connection.HTTPSConnection object at 0x000001D7A42FD690>: Failed to establish a new connection: [Errno 11001] getaddrinfo failed

Testing...

The scope of the scenario here is to have the webapp created and running in an arc-enabled kubernetes cluster via the appservice extension.
Indeed, the commands:
git clone https://github.com/Azure-Samples/nodejs-docs-hello-world
cd nodejs-docs-hello-world
zip -r package.zip .
az webapp deployment source config-zip --resource-group azrez --name webapp-6671 --src package.zip

are requiring 'git' to be installed, then 'zip' is on Linux
leaving it by design for now for the user to add their code if required


Improve doc for elementHandle.toString()

https://pptr.dev/#?product=Puppeteer&version=v2.0.0&show=api-elementhandletostring doesn't say much. I was looking for a method to return the text content of the element, similar to page.content(), but what I get is a useless constant, JSHandle@node. Is this method worth documenting even?

@dandv let hrefValue = await (await mainLink.getProperty('href')).jsonValue(); works for me


converted model inference on myriad usb stick

Hello
I fine tuning some pytorch face models, but im getting a poor performance doing inference on intel usb stick 2. In fact doing inference on CPU intel i5 is 2x faster than doing on MYRIAD target.
I followed the instructions here
https://github.com/opencv/openvino_training_extensions/tree/develop/pytorch_toolkit/object_detection/face-detection
What can be wrong¿

Hi @natxopedreira
Which model do you use, face-detection-0100?
Did you test performance of model from open_model_zoo? And what performance do you have on cpu and usb stick?
But yes, usb stick is less powerful than i5. It is expected that inference on CPU can be faster in several time than on usb stick.

@AlexanderDokuchaev
Hi, yes i used face-detection-0100, no i didn't compare with open_model_zoo version.... will do it
On stick i get around 8fps and on CPU 14-15.... i expected to have more fps on stick :( as the plan is to use this on a rpi.
Is there anything i can do to improve it?
Thanks

@natxopedreira
Try to use export.py with --alt_ssd_export option, it should improve performance.

@AlexanderDokuchaev
Thank you, i used that option, i have to review but i think without that flag it doesnt work....

@AlexanderDokuchaev
Without that flag i get a warning and later an error
[ WARN:0] global ../opencv/modules/dnn/src/dnn.cpp (3542) createNetworkFromModelOptimizer DNN/IE: Can't determine output layer type: '1060_1061.0'
[ WARN:0] global ../opencv/modules/dnn/src/dnn.cpp (3542) createNetworkFromModelOptimizer DNN/IE: Can't determine output layer type: 'boxes/Split.0'
[ WARN:0] global ../opencv/modules/dnn/src/dnn.cpp (3542) createNetworkFromModelOptimizer DNN/IE: Can't determine output layer type: 'boxes/Split.1'

OpenCV(4.3.0-openvino-2020.3.0) ../opencv/modules/dnn/src/ie_ngraph.cpp:600: error: (-2:Unspecified error) Failed to initialize Inference Engine backend (device = MYRIAD): Failed to compile layer "536": AssertionFailed: (inputImage->desc().dims().size() == 4) && (inputImage->desc().dim(Dim::C) == 3) in function 'initPlugin'

@natxopedreira
Inference speed on USB stick (without preprocessing and postprocessing, only time of work of model) is more than 15 fps. You have 8fps on full pipeline, right?
You can optimize your code by using asynchronous inference (example: object_detection_demo_ssd_async.py).
And you can reduce input size of the model (for example to 192x192), it's increase performance through precision.
In code:
net.reshape({'input': (N,C,H,W)})

Or run mo.py with  --input_shape [N,C,H,W].

@AlexanderDokuchaev
Those fps you mentioned are with that model?
Im doing async
`# neural feed
in_frame = cv.resize(image, (model_w, model_h))
in_frame = in_frame.transpose((2, 0, 1))  # Change data layout from HWC to CHW
in_frame = in_frame.reshape((model_n, model_c, model_h, model_w))
exec_net.start_async(request_id=0, inputs={input_blob: in_frame})
if exec_net.requests[0].wait(-1) == 0:
	res = exec_net.requests[0].outputs[out_blob]

	for obj in res[0][0]:
		if obj[2] > 0.5:

			xmin = int(obj[3] * cap_w)
			ymin = int(obj[4] * cap_h)
			xmax = int(obj[5] * cap_w)
			ymax = int(obj[6] * cap_h)

`

Those fps you mentioned are with that model?
Yes, it's face-detection-0100. You can run benchmark_tool to get performance of inference.

Add to your code net.reshape({'input': (1,3,120,160)}) before initializing exec_net and remove in_frame = in_frame.reshape((model_n, model_c, model_h, model_w)). You will avoid resize function, and inference of model will be faster.

Thanks for your time
seems that input is not the name of the layer... how can i see layers name?
AttributeError: Specified 'input' layer not in network inputs '{'image': <openvino.inference_engine.ie_api.DataPtr object at 0x7f5618965cf0>}'!

Yeap, it' should be image.

great!!!! 55fps ;)
Thank you!

Also you can fine tune model on target resolution.

Nice to know, i always belive that using a different input layer size was a bad idea... im happy to be wrong.
Thank you again!


added correct link

as per user feedback #2845, so i added the below link  after  verification,
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/mm-bad-pointer#mmgetsystemaddressformdlsafe
In that page, it directly pointed to MmGetSystemAddressForMdlSafe

Thanks @RAJU2529 -- I am actually going to do a broader overhaul on these pages -- you can watch the original issue for updates.  Appreciate the PR


[PSA] LAG resolution in PRE

I might be missing something, but I believe we have not really talked about LAGs in PSA. AFAIK, the ingress output metadata egress_port should be set to a singleton port value. So, for LAG resolution, a P4 table mapping a LAG port number to a singleton port is needed in the ingress. However, this means that when programming multicast groups to the PRE (at least as currently defined), the egress port in the multicast group entry should be a singleton, since the egress port value cannot be modified in the egress pipeline.
I imagine that the clone port value cannot be a LAG number for the same reason, i.e. the clone port values should also be LAG-resolved in the ingress pipeline.
Do we want the LAG resolution table to become part of the PRE? The advantages are that the P4 programs will become simpler and sending multicast replicas to LAGs would become possible. The disadvantage is that PRE definition will get more complex: we will need to define hash parameters for it, and a more complex API. Thoughts?

One option is to configure the hashing for LAG resolution PRE through the switch config. The P4 API can just have a function to add a lag port and it's mapping to a set of singletons, with the resolution logic being applied as defined in the switch config.

This did come up once briefly before in a Github comment thread on an issue, where I raised a question about what to do if someone wanted to do something different than hash-based selection of LAG members.
One possibility would be to do as you suggest above to handle what is likely the common case, i.e. hash-based selection of LAG members.
If someone wanted to do anything besides hash-based selection of LAG members, then they must write explicit P4 code for it, and always have the ingress code choose the singleton ports they want packets to go to (of course they could mix and match port selection methods for different LAGs if they wished, too).
I can't immediately think of any other complexities than the one you mention, i.e. the control plane API gets LAG-specific stuff added to it.  Hardware implementations would want to know about this well in advance, of course (although some could implement it by having extra P4 logic invisibly appended to the end of your P4 ingress code, to implement the LAG selection behavior, at least for unicast).
If you wanted LAGs to be members of multicast replication lists in PRE, that is not something that the extra invisible P4 code approach would necessarily work for, unless someone also had variable-length loops in their implementation.  Hardware-based targets would want to know about that even more so than for unicast traffic, I would guess.
I can't think of any fundamental reason not to allow this in PSA v1.0, but it would be good to discuss it at the next meeting to get thoughts from other working group members, too.

A minor point -- even without special LAG support in PSA, a common technique I have seen is that the control plane code hashes and selects a LAG member for each multicast group with a LAG in its replication list.  Then of course it is up to the control plane to update all such multicast groups if a LAG member fails, so I understand and agree that is going to be slower for control plane code to react to, vs. having the extra level of indirection existing in the fast path.

@samar-abdi ,
I do not think that LAG resolution per se should be a part of PSA. There is nothing special about it and it can be easily coded in a variety of ways using the existing primitives. This also allows one to have a lot of flexibility in terms of how it is performed. Even the most "LAG-related" mechanism, i.e. selector match kind is more of a convenience, rather than a necessity -- it can be implemented using regular tables and hash calculation.
What I do agree with you on is that the functionality of PRE needs to be specified more formally. We can debate whether or not to add a notion of LAG or ECMP group to a standard PRE, but whatever we decide should be made very clear, because otherwise people will not be able to write non-trivial programs that involve multicast in a portable fashion.
For everything, other than multicast, doing resolution in the ingress pipeline sounds like a reasonable approach to me.
Thanks,
Vladimir

@vgurevich I believe that perhaps the functionality of PRE already does have a specification written down in the latest draft PSA, although perhaps not as formal as you might wish.
The part relevant for multicast replication functionality is in Section 6.3.2 "Multicast operation".  No control plane API is specified in the PSA for modifying the PRE multicast replication behavior, but I am guessing that will be covered by the P4 Runtime API working group?
Another thing hinted at, but not required or specified, is that there might be queues and a buffer between ingress and egress (of course any hardware implementation pretty much has to, if it doesn't want to have a very high packet drop rate due to even very short-term contention for the same output port).  The PSA does suggest that normally packets should be processed in the egress control block in the same order as they were processed by the ingress control block for unicast packets with the same (input port, class_of_service, output port) combination, and similarly for multicast packets.  This is in Section 6.2.
Another things already specified is that the PRE can drop packets that ingress sends to it, or that egress sends to it via clone operations, e.g. due to congestion.  The PSA says nothing about mechanisms by which a P4 program can observe such drops.  It only recommends that a PSA implementation should provide counters for such drops.  Section 6.2 has a paragraph about that after the pseudocode, and the end of Section 6.5 also does.
Is there anything above that you don't think should be specified about PRE behavior in the PSA spec?
Is there anything you think should be specified about PRE behavior that isn't listed above?

@vgurevich
Thanks! There are multicast use-cases today that send replicas to LAGs, with the LAG resolution happening after the replication. With current PSA, adding a P4 table for LAG resolution after PRE is not possible since the egress_port is immutable. One could theoretically have a twisted implementation with resubmit, but it would be nice to avoid that and reflect the actual packet processing behavior in the P4 program.

@jafingerhut
Yes, we are proposing a multicast group entry in P4Runtime and I imagine we will have a richer PRE API. Anyway, I would request that we set aside substantial time at the next architecture WG meeting to define PRE semantics and API requirements. Thanks!

@samar-abdi ,
I do not think you can do much in P4 program, since P4 does not know anything about multicast. It is all implemented in PRE and while P$ is perfectly OK describing the interfaces to and from PRE, you can't really use it to describe PRE behavior.
This is also true about any other fixed component that P4 interacts with and we should probably accept the fact that P4 does not describe the full (serdes-to-serdes) data plane processing algorithm, but only the key parts of it as allowed by the given architecture.
So, for your practical problem, I think that the solution is in the detailed PRE specification nd I see 3 options:
The simplest and the most portable solution is that PRE knows nothing about LAGs/ECMP groups. When the software is being asked to add a LAG or ECMP group to a multicast group, It should then pick and add only one port (one path) of a LAG or ECMP group to that multicast group. It is not ideal, but very portable and is not that bad if you have many multicast groups, since they can be carried over different LAG/ECMP members.
Another, very simple solution is to add all ports/members of LAG/ECMP to the multicast group and let PRE produce more packets than needed and then drop all but one of them in the egress control (while having the full power of P4 available to do that).
The more difficult and less portable solution involves making PRE LAG/ECMP-aware. If we decide to go that route (e.g. the PRE in simple_switch is LAG-aware) then you will need to decide how PRE should do LAG resolution, whether additional metadata will be required to control it and how it will be compatible/incompatible with unicast LAG/ECMP resolution that will still be fully defined in P4 code.

@vgurevich
Thanks. These are very good points.
With the last option, can't we just remove LAG resolution table from the P4 program and let PRE do LAG resolution for all egress packet instances, whether they are the result of unicast, clone or multicast? Is there value in doing different types of lag resolution for the different packet instance types?
I agree that configuring the PRE with the LAG table data is going to be challenging, because we need to provide the selector input to PRE in the P4 program and the group/flow programming through the API.

@samar-abdi ,
You can certainly define PRE functionality so that it resolves LAGs, but I would advice against that for several reasons.

On the philosophical/ideological grounds: the more functionality you move into the fixed function components, the less programmable and more fixed-function the device becomes. Also, as a result, the whole architecture will become less and less portable as fewer and fewer devices will be able to implement it correctly (including by the way some of the devices you are familiar with)
On the flexibility front: by moving LAG resolution into PRE you
a. Define a very specific algorithm for that
b. Force it to always be done at the very end, right between ingress and egress processing
The questions then become: what to do if you need to resolve LAGs multiple times (e.g. you want a port-based ACL that can redirect a packet to another LAG)? What do you do with ECMP (especially over LAGs), what do you do with Virtual Port LAGs, etc, etc, etc? What if you want, say, stateful LAG resolution?
c. You still need to reconcile ingress port->LAG mapping with the egress one (and even more difficult thing happens when you think about ECMP, VP-LAGs and such).

My recommendation is to keep all this to be as simple and generic as possible, otherwise, PSA will not be portable or flexible enough to to non-standard things.

@vgurevich
I would much prefer to do all port resolution with a P4 table. It is just the placement of that table that I am concerned about. Right now, we are forced to do LAG resolution before replication because that table must reside in ingress. PSA would be more flexible if it provided an option to do LAG resolution after replication. Another P4 programmable control block after replication would be nice, but I can see the downsides to that.

@vgurevich's first solution -create a multicast group per port in the LAG, compute the hash in the ingress pipeline and pick the multicast group from a set based on the hash result- sounds good to me.
@samar-abdi I'm not sure why you want to do LAG resolution after replication (although that does sound like @vgurevich's third solution); you would just be creating copies for nothing.

@antoninbas Probably a use case that Samar is thinking about is L3 multicast routing.  Each of the output interfaces could be a single physical port, or a LAG (among other possibilities, depending on what features you support, e.g. IP tunnels).  You either need to pick a LAG member for the multicast group when you configure the multicast group, or you need a system that can do LAG member selection after multicast replication, to implement L3 multicast to LAG ports.

"You either need to pick a LAG member for the multicast group when you configure the multicast group". That's exactly @vgurevich's first solution, right? Even though you do end up with an exponential number of multicast groups if you want to have the complete distribution.

@jafingerhut
Thanks, yes this is good example and my use case is similar. We are not creating copies for nothing, it's just that the egress_port of a copy is a trunk, not singleton. The LAG resolution table should resolved the singleton value and overwrite the egress_port, so that the copy in the egress pipeline has a singleton value of egress_port.
As for @vgurevich first solution, I imagine, we are defining multicast groups only with singletons. The controller sets a logical multicast group, which is then resolved in a P4 table to a multicast group programmed in the PRE? In this case, the multicast group resolution table would need to watch all ports of the resolved multicast group. Again, this seems like the P4 program not matching the pipeline's reality.

@antoninbas It is completely impractical to create an exponential number of groups for a complete distribution.  If you support hundreds or more of L3 multicast groups, you can just make a single choice for each multicast replication group, and trust/hope that your hashing choices are good enough (or the control plane can even potentially make choices based on criteria other than hashing, too).  There is unlikely to be a reason to emulate exactly the behavior of a "LAG choice after multicast replication" implementation by means of an implementation that requires one to pick a physical port in the PRE replication lists.

@antoninbas The simplest thing for the P4Runtime API to do is support only physical ports as members of multicast group replication lists, of course.  If you don't provide the option to specify LAG interfaces at all, it is clearly up to the caller to update failed member ports with different member ports, if the caller wishes.
If you think it would provide enough benefit to have an option that picks a LAG member for callers that want to provide LAG interfaces in the P4Runtime API, you could consider that, but it will of course raise questions like:

Does that mean that P4Runtime API also promises to replace failed LAG member ports with good ones automatically?  If so, how quickly?
I need an API to determine which member port the implementation picked for me for each LAG member of a replication list.
Can I register a callback that will be called to inform me whenever a member port selection changes?
What knobs do I have to control the member selection?

Additional note on my previous comment:
The direction for fast re-route of unicast packets to LAG interfaces seems to be to have a separate action selector in the P4 program for that purpose, and then use the multi-controller option recently discussed in the P4Runtime API working group to choose to control that action selector (and maybe other externs and/or tables) from a "close by" controller with low latency to the device, vs. in a "far away" controller.
The same technique could be considered for PRE multicast replication groups, as a mitigating factor for reaction time, if the only option provided in the API was to add physical ports to the replication lists.

The problem with offloading this to the P4 Runtime caller is the same as for action profile member fast failover (https://github.com/p4lang/p4-spec/issues/457): in the case of a SDN deployment, the latency between a LAG member going down and the dataplane being updated is not acceptable.
If P4 Runtime is meant to be a unique API for both SDN and local OS, then we have to some kind of support for this.
In the end I imagine that this thread and the decision of the PSA WG to describe that use case in the description of the PRE extern in the PSA spec don't really need to have an impact on the design of the API. It seems we have pretty much already reached a decision to support LAGs for action profile member fast-failover, and it seems inconsistent to me to not propagate this to the PRE API.

@samar-abdi ,
We can (and already do) use regular P4 tables for LAG resolution in the ingress pipeline, but we can use them only for unicast packets.
The reason we can't use P4 tables for multicast packets (in the ingress) is because P4 controls can only transform packets. They cannot create multiple packets on their own (and then transform them individually) -- that's the job of PRE that P4 ingress control requests to create multiple copies (e.g. by setting the multicast group id).
The reason we do not resolve LAGs in the egress pipeline is because that's not how the modern high-speed hardware works :( I would love to be able to set/change the egress port in the egress pipeline and we can certainly define such an architecture, but I would not be able to name a device on which we can implement it, at least not in the terabits-per-second family (or even hundreds of gigabits per second).
I totally agree that PSA solution is complex/complicated, but it does follow the standard industry practices (as do at least some of the solutions that I proposed), so if we want to be portable, we need to restrain ourselves.

@jafingerhut ,
In terms of multicast operation, I think we do need to add more meat. For example, what is the contents of a multicast group? Is it just a set of ports, or is it sets (port, rid) pairs, or is it a set of rids with sets of ports associated with each? Is it LAG-aware (i.e. these are sets of ports or LAGs)? If yes, what does it mean? etc.
P4Runtime is a good proxy for the answers to many of these questions, but it is not the answer. I am more and more convinced that control plane APIs cannot be used to define data plane functionality and vice versa (data plane interfaces cannot be used to define control plane APIs) -- they are orthogonal. So, regardless of P4Runtime, we need to define PRE functionality in great detail.

@samar-abdi , @antoninbas , @jafingerhut
I think we can have a great discussion on this topic tomorrow. Sounds like face-to-face is better.

Glad to add clarifying details to the spec for PRE operation and restrictions.  I will add a couple more questions to the list:

Should PORT_CPU be allowed in a PRE multicast group replication list?
Similarly, should PORT_RECIRCULATE be allowed?

My thought was that a PRE multicast replication list would be a list of (port, replication_id) pairs, and the control plane API would allow adding such pairs to, or removing such pairs from, a given multicast group.  Restricting them to not contain any duplicate (port, replication_id) pairs for the same multicast_group value seems reasonable (could easily be enforced in software, with an error status if you try to violate it).
I wouldn't call data plane and control plane issues 'orthogonal', quite.  Each affects the other in significant ways.  But none of that discussion needs to be in the PSA spec :-)

@jafingerhut
Yes, I will have a P4Runtime pull request shortly with the multicast replication list programming API.

@jafingerhut ,
On which ports should be allowed in multicast group...
I would think that as long as a port can appear as egress_port in psa_ingress_output_metadata_t, it's a fair game.
So, CPU_PORT for sure. In case of recirculation, if we do it via a separate flag, than the answer is "no", if we do it by simply sending a packet to a special port number, then the answer is "yes".

Discussed during the 2017-Dec-06 P4 Arch WG meeting.  Decision was made that PSA does not require an implementation to support LAG interfaces in PRE multicast groups.  That lack of a requirement has proposed mention in the PSA spec as part of this PR: https://github.com/p4lang/p4-spec/pull/513

@samar-abdi I haven't read through every comment in this discussion today, but wanted to ask whether you are aware of anything left unanswered related to this issue.  The PR #513 mentioned in my previous comment is now merged into the PSA spec.
If everything has been resolved, I would like to close this issue.

The plan on the API side is to stay with singleton ports in PRE programming for now. We will revisit LAG handling in the API separately, but as far as PSA is concerned, we can close this.

Great.  Closing this one.


Observers set up using { handler() { .... } } won't always fire

Description:
Observers' handlers set up using "options-friendly" object won't always fire on change.
Still working on a reproducible fiddle, as it happened on a complex side of my application.
I was observing a passed computed property (from parent component, passed via attribute, isolated: true), using an observer set up via { handler() { .... } }. Sometimes, it wouldn't fire.
Simply switching to a plain function, rather than the object with handler, fixed the issue.
Versions affected:
1.0.0-build-64
Platforms affected:
Chrome
Code (I'm still working on reproducible fiddle):
Observers written like this, sometimes fail to trigger:
Ractive.extend({
  // ...

  observe: {
    myKey: {
      handler() { /* won't always trigger */ }
    }
  }

  // ...
});

While observers set up like this, seem to always work properly:
Ractive.extend({
  // ...

  observe: {
    myKey() { /* always works as expected */ }
  }

  // ...
});

Are observers handled differently based on how they're set up?

The code that handles subscribing from on and observe keys is here, and there should be no difference between using a handler in a object vs using a function. What options are you passing in the config version?

What options are you passing in the config version?

No option, just a plain object with the handler.

On Monday I'll try some debuggers here: https://github.com/ractivejs/ractive/blob/dev/src/Ractive/prototype/observe/Observer.js
I think I'll start from handleChange and see where things go.

..ok, hopefully I'll debug it next week :)

Finally reduced to a simple fiddle: https://jsfiddle.net/7ojwab76/1/
Looks like it wasn't a problem on 0.9.3: https://jsfiddle.net/7ojwab76/2/
// child component
const MyComponent = Ractive.extend({
  template: `<button on-click="@this.add('proxiedCounter')">Change data: {{proxiedCounter}}</button>`,

  isolated: true,

  data() {
    return {
      proxiedCounter: null,
    };
  },

  observe: {
    proxiedCounter: {
      handler() {
        // will never fire when interacting with the button
        console.info('fired handler');
      },
    },
  },

  oninit() {
    this.observe('proxiedCounter', () => {
      console.info('fired observe');
    });
  },

});

// root component
const r = window.r = new Ractive({
  el: '#main',
  template: `

  	Open the console and click the button.

    Two observers should fire each time, but only the one set up via this.observe(...) does.

    {{#if show}}
	    <MyComponent proxiedCounter="{{counter}}"/>
    {{/if}}

  `,
  components: { MyComponent },
  data: {
    show: true,
    counter: 0,
  },
  onrender() {
    // without this code, everything works as expected
    this.toggle('show').then(() => {
      this.toggle('show'); // final state => true
    });
  }
});

Ah! The config object was getting a fragment set on the first run, which caused further init to resolve in the wrong context. The fix was simply to use the config object as a prototype on an empty object to pass through the observe machinery. This should now be fixed on edge.
That was a nasty one to reproduce. Thanks wading through it!


Replace database to store in javadoc

Replace all word database to store in javadoc for TokenStore. Because class has name TokenStore and we will't find a any mention of any database.

@Alykoff Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@Alykoff Thank you for signing the Contributor License Agreement!

Thanks for the Pull Request! This is now merged into master :)


Turn off Intellisense by file type.

VSCode Version: 1.4.0
OS Version: OS X 10.11.3

Steps to Reproduce:

Create Markdown file.
Begin typing.
After writing enough you end up getting Intellisense prompts for every new word you write:

This makes for a terrible Markdown editing experience.

@nathanhammond As a global workaround you can turn off all textual completions with editor.wordBasedCompletion: false

@jrieken Indeed, but that cure is worse than the malady since the majority of the time I do want (and benefit tremendously) from textual completions.
So rather than do that I simply moved my markdown editing into a different tool (also suboptimal).

I've notice the same behaviour editing markdown that actually drove me to another tool (just for Markdown). Often I'll have a short todo list or notes in a plain text file this will happen to also, less often / irritating but similar.
I would love to see something like:
// blanket disabled for everything
editor.wordBasedCompletion: false
// blanket enabled for everything
editor.wordBasedCompletion: true
// on for everything except for file types in the exclude list.
editor.wordBasedCompletion: {
exclude: [".md", ".txt", ".text"]
}
// off for everything except for file types in the inclusion list.
editor.wordBasedCompletion: {
include: [".js", ".cs"]
}

Understood - I will tackle this in September. With it we should also think about configuring word based completions wrt  strings and comments. Tho not interesting for markdown folks like or hate it...

A "grand unified plan" of configuring it would be fantastic and I'm in no particular rush. Blacklists or whitelists at a global level provide some alleviation as a quick fix, but if instead everything were context aware you could provided completions inside of a Markdown code block that is annotated for a language.
```javascript
setTimeout(...

So your proposal for taking context into account is valuable in many scenarios. So please don't feel unnecessarily pressured into the "quick fix" solution and take the time to design the solution that you actually want.

@nathanhammond fyi with the January release we have enabled language specific settings, so you could have:
"editor.wordBasedCompletion": true,
"[markdown]": {
  "editor.wordBasedCompletion": false
}

@jrieken Thanks for the ping, that does make life far smoother. The language specific settings actually work as a simple but elegant design. Regardless of how it is implemented now (maybe as a file type switch?) it allows for a future in which you detect the scope.
Given you're closing things as duplicates of this issue I'll leave it open as a tracking issue for the thoughts you have on this. 😄

dupe of #1657


fix: add auth buttons to the login view only

fixes #8

Thanks! 👍

Just merged this into a release branch to test it on some of our installations. It seems that the check does not always work and the login buttons are not added to the form. I think this is a race condition, when you start your request with /panel (without the login at the end) and the panel redirects to /panel/login. Then in some cases our script is faster and only sees /panel in the url. I think a better solution will be to don’t redirect every plugin request to the panel when the user is logged in (https://github.com/blankogmbh/kirby-oauth/blob/master/src/Controller.php#L25). I’ll try to implement this today or tomorrow.

Damn, I was expecting something like this… I guess the best solution would be to create a custom login view as mentioned in #5

Yes sure! But for a quick fix i think moving the mentioned line(s) into Controller::index() would at lease eliminate the console error in the panel…


Update node troubleshooting docs to cover both < 0.28 and >= 0.28

Description
How can the docs be improved?
The node troubleshooting docs at https://karpenter.sh/docs/troubleshooting/#node-notready need to cover versions < 0.28 and >= 0.28 differently.
In the event of some mis-configuration where the node doesn't talk to the API server:
< 0.28
- Node object is created, hangs around forever

>= 0.28
- Machine object is created, but will be deleted after 15 minutes
- This cycle repeats

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

CC @jonathan-innis


tracker update empty list with yolov5

Hi community, I am trying to use the demo of yolov5 in a custom video.
The problem is that norfair does not draw anything at all.
I have done some debugging and I can see that yolo_detections look fine. It contains the bounding boxes, the score and the category. Besides, detections also looks fine, it contains the centroid of the object and the score.
The main problem lies on: tracked_objects = tracker.update(detections=detections).
tracked_objects remains an empty list...
Any ideas on what is going on?
Thanks in advance! 😄

For some reason the tacker is not able to track onto any objects. This could happen for a ton of reasons, incorrect distance function or threshold, or bad detections. You can draw your detections on your video and see how they look to start debugging.

We just merged a fix to the Yolov5 demo, so it may help you https://github.com/tryolabs/norfair/pull/78

hello @joaqo , I'm thankful for this awesome library. I have some newb questions about how to integrate the class label ID to norfair.draw_tracked_objects to display it on the frame? I've tried the yolov5 demo example and I wonder how to display the class ID and tracking ID at the same time. As I read the docu, the Detection class has a data attribute that stores additional data, and I think the scores and the class ID were stored there, or maybe I'm wrong.

hi @jbottala02 draw_tracked_objects currently doesn't support setting a class_id. A workaround would be to use a different color for each class, though I understand thats not ideal.

It's ok now, I found out how. Anyways, I really appreciate your reply and thanks for this library.  I want to view the class_id because there were sudden changes with tracking_ID. I speculate that there is something wrong with Yolov5's classifying objects that cause these sudden tracking ID changes. https://ibb.co/bJvcjSp


responsive routes

I've been through the docs but didn't find anything regarding responsive routes. There's navigate that could be used to do that I guess?

I suspect you might want to manage this separately from the Router - thus in turn allowing you to use different Router components per device vs including this logic as part of the router.  With that said, I think different routes per device is something you should try to avoid.  I'm not sure, but I suspect it'll create issues with chunking and other optimizations.

Responsive routes could be added with multiple routers that conditionally render based on the viewport, however as @niccai mentioned, you'd likely wan to use dynamic imports to lazy load your routes to avoid package bloat.


Specifying an empty array for transforms should be possible.

Currently you can't specify an empty array for transforms, it should be possible.
https://github.com/sajari/sajari-sdk-php/blob/master/src/Sajari/Client/Client.php#L211
Not sure how you can get around this in PHP though?  Maybe just check isset instead of also checking count (and remove the default [] value).

Fixed by using null as the default so that we can distinguish between an intentional empty array and nothing being passed.
https://github.com/sajari/sajari-sdk-php/commit/ed5263141a03bb78b37d2a12013f3ec719ab86eb


[bug]: Cannot add ed2k links

Affected part
Other (none of the above)
Extension version
3.16.1
DSM version
DSM 7.2.1-69057 Update 5
Browser version
130.0.6723.92 (Build officiel)
Description
It's been roughly one week that I cannot add ed2k links anymore.
The links in the pages are recognized, the submenu is displayed, but when I add to download I get an error message.
Same message appear if I create a custom task and copy/paste the link.
Also in the console I see below errors, not sure if they were here before:
Uncaught (in promise) Error: Cannot access contents of the page. Extension manifest must request permission to access the respective host.
Unchecked runtime.lastError: The page keeping the extension port is moved into back/forward cache, so the message channel is closed.
Adding the link directly in DownloadStation works as expected.
Steps to Reproduce the Issue

Go to a page with ed2k links
Click on a ed2k link and select download destination
Error pops in, failing to add the task

or

Add download task
Paste the ed2k link
Click on Create
Error pops in, failing to add the task

Screenshots or Mock up

Failure Logs
background.entry.js:1 Uncaught (in promise) Error: Cannot access contents of the page. Extension manifest must request permission to access the respective host.Understand this errorAI
Unchecked runtime.lastError: The page keeping the extension port is moved into back/forward cache, so the message channel is closed.

Store snapshots
{
    "state": {
        "logged": true,
        "sid": "",
        "modal": {
            "popup": false,
            "option": true,
            "standalone": false
        },
        "content": {
            "menu": false,
            "dialog": false
        },
        "loading": 1,
        "badge": {},
        "history": {
            "destinations": ["downloads"],
            "folders": [],
            "logs": []
        },
        "download": {
            "enabled": true,
            "defaultFolder": "downloads"
        },
        "api": {},
        "count": {
            "badge": 1,
            "total": 1,
            "tabs": {
                "all": 1,
                "active": 1,
                "inactive": 0,
                "completed": 0,
                "downloads": 0
            }
        }
    },
    "navbar": {},
    "tasks": {
        "taskForm": {},
        "stopping": {},
        "tasks": {}
        },
        "tasksIds": [],
        "files": {},
        "filesIds": {},
        "stats": {
            "emule_speed_download": 0,
            "emule_speed_upload": 0,
            "speed_download": 0,
            "speed_upload": 0
        }
    },
    "downloads": {
        "entities": []
    },
    "scraped": {
        "page": {},
        "contents": {}
    },
    "settings": {
        "notifications": {
            "count": {
                "enabled": true,
                "template": "all",
                "status": ["downloading", "paused", "error", "seeding", "waiting", "extracting", "finishing", "finished", "hash_checking", "filehosting_waiting", "downloading_in_progress", "paused_in_progress", "error_interrupted", "cancelled_interrupted", "finished_complete", "finished_deleted"],
                "destination": {
                    "enabled": false
                },
                "color": "#4285f4"
            },
            "snack": {
                "enabled": true,
                "level": 0,
                "scope": {
                    "popup": true,
                    "content": true
                },
                "timeout": 5000,
                "position": {
                    "vertical": "top",
                    "horizontal": "right"
                }
            },
            "banner": {
                "enabled": true,
                "level": 0,
                "scope": {
                    "background": true,
                    "popup": true,
                    "finished": true,
                    "failed": true
                }
            }
        },
        "connection": {
            "type": "local",
            "authVersion": 7,
            "username": "",
            "password": "",
            "otp_code": "",
            "enable_device_token": false,
            "device_name": "Download Station Client",
            "device_id": "",
            "rememberMe": true,
            "autoLogin": true,
            "protocol": "https",
            "path": "",
            "port": 5001
        },
        "polling": {
            "enabled": true,
            "background": {
                "enabled": true,
                "interval": 20000
            },
            "popup": {
                "enabled": true,
                "interval": 3000
            }
        },
        "tabs": [{
                "id": "48245c70-ca79-4e90-a77a-957f38d3cd94",
                "name": "all",
                "template": "all",
                "status": ["downloading", "paused", "error", "seeding", "waiting", "extracting", "finishing", "finished", "hash_checking", "filehosting_waiting"],
                "destination": {
                    "enabled": false
                },
                "color": "primary"
            }, {
                "id": "3a45b86d-6383-414e-bd7f-1de411b2aa34",
                "name": "active",
                "template": "active",
                "status": ["downloading", "finishing", "hash_checking", "extracting", "seeding"],
                "destination": {
                    "enabled": false
                },
                "color": "secondary"
            }, {
                "id": "47d97f4b-9ae5-45d2-997b-a198008528c7",
                "name": "inactive",
                "template": "inactive",
                "status": ["waiting", "filehosting_waiting", "paused", "error"],
                "destination": {
                    "enabled": false
                },
                "color": "warning"
            }, {
                "id": "6fd7dc36-eb8e-47bf-9093-981244531d59",
                "name": "completed",
                "template": "completed",
                "status": ["finished"],
                "destination": {
                    "enabled": false
                },
                "color": "success"
            }, {
                "id": "452e77af-2c50-443f-91aa-e396534eac5b",
                "name": "downloads",
                "template": "downloads",
                "status": ["downloading_in_progress", "paused_in_progress", "error_interrupted", "cancelled_interrupted", "finished_complete", "finished_deleted"],
                "destination": {
                    "enabled": false
                },
                "color": "secondary"
            }
        ],
        "menus": [{
                "id": "3ca675ba-e048-4b52-b0f4-a463d8d82bf9",
                "title": "Add to Synology Diskstation",
                "contexts": ["link", "audio", "video", "image", "selection"],
                "modal": false,
                "destination": {
                    "custom": false,
                    "path": ""
                }
            }, {
                "id": "a8904ed5-3bbf-42e8-98de-751255a84098",
                "title": "Add to TV",
                "contexts": ["link", "audio", "video", "image", "selection"],
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/tv"
                }
            }, {
                "id": "507f89e4-89dc-46bb-b71d-758293f9e819",
                "title": "Add to Movies",
                "contexts": ["link", "audio", "video", "image", "selection"],
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/movies"
                }
            }, {
                "id": "c1a7637a-b609-4848-8dad-f818b2add4d5",
                "title": "Add to Audiobooks",
                "contexts": ["link", "audio", "video", "image", "selection"],
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/books"
                }
            }, {
                "id": "91d27fd8-fc87-4d1e-8299-0543dcba50fa",
                "title": "Add to Games",
                "contexts": ["link", "audio", "video", "image", "selection"],
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/games"
                }
            }, {
                "id": "a88486aa-659c-4012-b5fa-11f29183425b",
                "title": "Add to BDs",
                "contexts": ["link", "audio", "video", "image", "selection"],
                "modal": true,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/comics"
                }
            }
        ],
        "quick": [{
                "id": "3dd2a25b-8444-4cf7-b977-dd04745a9242",
                "title": "Send to Synology",
                "icon": "server",
                "modal": false,
                "destination": {
                    "custom": false
                },
                "max": 5,
                "type": "task"
            }, {
                "id": "ab15c38d-4aac-44e1-951d-38a91d099eac",
                "title": "Open custom modal",
                "icon": "server",
                "modal": true,
                "destination": {
                    "custom": false
                },
                "max": 5,
                "type": "task"
            }, {
                "id": "af5e0fa8-474b-49de-9a94-9be8c1078dcd",
                "title": "Recent destinations",
                "icon": "history",
                "modal": false,
                "destination": {
                    "custom": false
                },
                "max": 5,
                "type": "recent"
            }, {
                "id": "d6c5a59b-b4cf-48bd-b959-c868f2081372",
                "title": "Save to disk (local)",
                "icon": "download",
                "modal": false,
                "destination": {
                    "custom": false
                },
                "max": 5,
                "type": "download"
            }, {
                "id": "4aafdd45-72e3-47c7-a3d2-d60d241a722c",
                "title": "Recent folders (local)",
                "icon": "historyAlt",
                "modal": false,
                "destination": {
                    "custom": false
                },
                "max": 5,
                "type": "recent_download"
            }, {
                "id": "b8604ff7-e1da-4744-b080-91ff5e057bf0",
                "title": "Send to TV",
                "icon": "video",
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/tv"
                },
                "max": 5,
                "type": "task"
            }, {
                "id": "b3cf32c9-ce11-4e35-98a4-fc6cc74fd149",
                "title": "Send to Movies",
                "icon": "video",
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/movies"
                },
                "max": 5,
                "type": "task"
            }, {
                "id": "82298d23-de04-47d6-a1d8-4c57c33ed7cd",
                "title": "Send to Audiobooks",
                "icon": "musicLibrary",
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/books"
                },
                "max": 5,
                "type": "task"
            }, {
                "id": "63f5fb92-22f7-406b-9639-c13ae5d5e0f6",
                "title": "Send to Games",
                "icon": "game",
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/games"
                },
                "max": 5,
                "type": "task"
            }, {
                "id": "2b8934e4-2cea-4bca-bdb8-8098052a702f",
                "title": "Send to BDs",
                "icon": "photo",
                "modal": false,
                "destination": {
                    "custom": true,
                    "path": "data/torrents/comics"
                },
                "max": 5,
                "type": "task"
            }
        ],
        "global": {
            "theme": "auto",
            "actions": "all",
            "loading": {
                "enabled": true,
                "threshold": 300
            },
            "task": {
                "progressBar": true,
                "background": true
            },
            "download": {
                "progressBar": true,
                "background": true
            },
            "navbar": {
                "buttons": ["clear", "add", "scrape", "openSynology", "configs", "resume", "pause"]
            },
            "interface": {
                "size": 1,
                "pullToRefresh": true
            }
        },
        "tasks": {
            "clearOnExist": true
        },
        "downloads": {
            "enabled": false,
            "buttons": true,
            "notifications": true,
            "transfer": {
                "erase": true,
                "resume": true,
                "modal": true
            },
            "intercept": {
                "enabled": true,
                "resume": false,
                "erase": true,
                "modal": false,
                "all": false,
                "extensions": [{
                        "ext": ".torrent",
                        "mime": "application/x-bittorrent"
                    }, {
                        "ext": ".flac",
                        "mime": "audio/flac"
                    }, {
                        "ext": ".wav",
                        "mime": "audio/wav"
                    }, {
                        "ext": ".mp3",
                        "mime": "audio/mpeg"
                    }, {
                        "ext": ".aac",
                        "mime": "audio/x-aac"
                    }, {
                        "ext": ".ogg",
                        "mime": "audio/ogg"
                    }, {
                        "ext": ".mp4",
                        "mime": "video/mp4"
                    }, {
                        "ext": ".mpeg",
                        "mime": "video/mpeg"
                    }, {
                        "ext": ".mkv",
                        "mime": "video/x-matroska"
                    }, {
                        "ext": ".7z",
                        "mime": "application/x-7z-compressed"
                    }, {
                        "ext": ".zip",
                        "mime": "application/zip"
                    }, {
                        "ext": ".gz",
                        "mime": "application/gzip"
                    }, {
                        "ext": ".tar",
                        "mime": "application/x-tar"
                    }, {
                        "ext": ".jpeg",
                        "mime": "image/jpeg"
                    }, {
                        "ext": ".jpg",
                        "mime": "image/jpeg"
                    }, {
                        "ext": ".png",
                        "mime": "image/png"
                    }, {
                        "ext": ".svg",
                        "mime": "image/svg+xml"
                    }, {
                        "ext": ".tif",
                        "mime": "image/tiff"
                    }, {
                        "ext": ".gif",
                        "mime": "image/gif"
                    }, {
                        "ext": ".pdf",
                        "mime": "application/pdf"
                    }
                ],
                "active": [{
                        "ext": ".torrent",
                        "mime": "application/x-bittorrent"
                    }
                ]
            }
        },
        "advanced": {
            "logging": {
                "enabled": true,
                "levels": {
                    "background": 4,
                    "content": 4,
                    "popup": 4,
                    "option": 4,
                    "standalone": 4
                },
                "history": false,
                "historyMax": 1000
            }
        },
        "sync": {
            "mode": "sync"
        }
    }
}

Hello,
Did it ever work before ?
From what I gather, ed2k links do not pass standard URL sanitization:

So it would require a special handling here

Well, yes, I wouldn't send a bug report otherwise :)
I did use it a lot before, and now it doesn't work anymore, I'm guessing due to a Chrome update perhaps.

Maybe linked to manifest v3?

Possible, but it would be surprising as the manifest spec shouldn't cover what seems to be a change in URL prototype.
Seems that| used to be considered uri safe but not anymore.
I'll manually encode it for now, synology seems to decode all params anyway.
Hopefully it doesn't have any side efects on other links 🤔 .

I pushed a new release, can you try it to see if it fixes things ?
(I don't really use eMule, so I can't test much beyond test links)

Updated to 3.16.3 but same issue.

If not, uou might need to force an update in chrome extension page, or manually download the package from github

It is

I even restarted the browser.

Does it throw the same error while using this link ?
ed2k://|file|emule0.60a_x64_beta.zip|4069312|A2682308A965960BFB71B37A18905983|h=KJDDEXSC44F323625RJYWJ4IMVIIP55W|/

If your not comfortable sharing the link you're using, can you instead describe it's format ?
I beleive, ed2k link should follow this pattern if I'm not mistaken:
/^ed2k:\/\/\|file\|[^|]+\|\d+\|[a-fA-F0-9]{32}\|(h=[a-zA-Z0-9]{32}\|)?\/$/

Only difference I saw between your link and the links I'm trying to add is in the file name, in my case it has unencoded square brackets ([ and ]) while spaces are encoded as %20.
This never caused any issue until now but when I manually replace the brackets with %5B and %5D I can add the link.
Not sure why this is happening now, also adding the link with the unencoded square brackets in DownloadStation directly does work without issue.

Um, well I pushed a new version where we skip completely URL validation for emule links and I just encode the whole string.
Hopefully that fixes things, but if not I think it would be better to open an issue on chromium side directly, as it seems to be a broswer change behavior more than anything.

It looks OK now, thanks.

Awesome :)
If you enjoy the app don't hesitate to leave a review too !


Cleanup the "Attach Node Script" dialog

Made section names be in the same style as other dialogs (starting from the left and ending with a ":").
Cleanup unnecessary nodes and redundant calls.

Thanks!


[Feature]

Feature description
As we use the realistic phantom for unit testing, SNR is poorly defined. The phantom uses T1/T2 values to generate realistic tissue contrasts. This means that "noise" is added to the signal, but that this does not mean "SNR" is 1/noise. It also means that SNR changes per organ (depending on their T1/T2 values). It makes the phantom more realistic, but the SNR is harder to define.
Describe the solution
For our paper, I think it is "easier" to have unit tests at fixed SNR-levels, instead of fixed noise levels.
To me there are two solutions;
1: We could simulate a noise-less signal curve using the phantom, and then rescale per tissue and add noise for unit testing purposes.
2: We could have an option to turn off T1/T2 weighting in the phantom and generate the json files with this option turned off.
Describe alternatives
No response
Additional context
No response
Are you working on this?
Yes

@etpeterson I tagged you as the unit testing is more of your IP. I will try and work on option 2 :). Let me know if it is a bad idea :)

This should be solved in my latest pull request :).

This should be solved in my latest pull request :).

So this is being worked on? If so, you should assign it to yourself so nobody else starts work on it too.

@etpeterson I tagged you as the unit testing is more of your IP. I will try and work on option 2 :). Let me know if it is a bad idea :)

Not actually sure how the two options differ. It sounds like both generate noiseless phantom data and then the noise is added again later. I think maybe option 1 is still generating noisy json data and 2 doesn't? If that's the case then I think I'd prefer 2 so we can scale the noise on the test side more easily.


Migrating project to use groups in allowlist

This PR migrates the project to use groups of IPs in their allowlist.
By referring to groups to IP addresses, we can centralize the definition of groups of ip addresses.
If these lists require changing in the future, we can change the definition once and future deploys across all services will automatically include these new IPs.
3 allowlist(s) have been detected that can be migrated.
Allowlist: helm_deploy/send-legal-mail-to-prisons-api/values.yaml
New Groups
The effect of applying this PR is as follows:

The following groups will be applied: internal
The size of the allowlist defined in this file will change: 7 => 0 (7 removed)

Added IPs
The new Group membership will result in the following IPs being added to your allowlist by applying this PR:

petty-france-wifi

Removed IPs
The following IPs have been identified as unnecessary and will be removed by applying this PR:

health-kick

Allowlist: helm_deploy/values-dev.yaml
New Groups
The effect of applying this PR is as follows:

The following groups will be applied: circleci
The size of the allowlist defined in this file will change: 21 => 0 (21 removed)

Added IPs
The new Group membership will result in the following IPs being added to your allowlist by applying this PR:
Merging this PR should not result in any additional IP addresses being added to the allowlist.
Removed IPs
The following IPs have been identified as unnecessary and will be removed by applying this PR:
No IPs have been identified for removal
Allowlist: helm_deploy/values-preprod.yaml
New Groups
The effect of applying this PR is as follows:

The following groups will be applied: circleci
The size of the allowlist defined in this file will change: 21 => 0 (21 removed)

Added IPs
The new Group membership will result in the following IPs being added to your allowlist by applying this PR:
Merging this PR should not result in any additional IP addresses being added to the allowlist.
Removed IPs
The following IPs have been identified as unnecessary and will be removed by applying this PR:
No IPs have been identified for removal

Thanks for your review @dhirajshettymoj, had to fix conflicts.
Please merge if you're happy with it.
cc: @psoleckimoj


Update reduxReactRouter to accept history object

When using history basename function it returns an object. Before this it would only accept a function that returns an object. This update gives users the ability to use other helpers provided by history.
Also update to the tests to account for this new behavior. Most of the tests were kept in this describe block to ensure all other routes stayed the same and that history properly uses the basename for determining root.
One other piece I would like to note is that similar logic also lives in useDefaults. I considered creating an abstraction for both of these instances, but rather not create the wrong one and have to create edge cases for both down the line.
This would fix issue #158

@agirton-twitter there is some problem with merging this correctly. I´m looking into it...
Thanks for the PR though!

@agirton-twitter It would be nice, if you could update your branch. This should resolve the merge issue.

@Scarysize I've rebased on top of the latest master. Re-ran tests to ensure all pass. Last I checked Travis was failing but that was because it said it couldn't find the history/lib/useBaseName module.

@agirton Nice one. Just checked the tests locally, everything passes. Thank you!


Get demo of Flowmapp

Ask new team member to give you an overview of how she's been using it, and please record so I can watch later if it's next week while I'm out.

In Team's channel: files > demos > FlowMapp walkthrough.


HOTFIX: link to doc

Same as IA-3531 in https://github.com/BLSQ/iaso/pull/1701 but can be hotfixed, because docs are released independently of iaso
DO NOT MERGE as the change is already in another PR
THIS BRANCH CAN BE DELETED ON RELEASE
Related JIRA tickets : IA-3531
Self proofreading checklist

[ ] Did I use eslint and black formatters
[ ] Is my code clear enough and well documented
[ ] Are my typescript files well typed
[ ] New translations have been added or updated if new strings have been introduced in the frontend
[ ] My migrations file are included
[ ] Are there enough tests
[ ] Documentation has been included (for new feature)

Doc

Tell us where the doc can be found (docs folder, wiki, in the code...)

Changes
Explain the changes that were made. The idea is not to list exhaustively all the changes made (GitHub already provides a full diff), but to help the reviewers better understand:

which specific file changes go together, e.g: when creating a table in the front-end, there usually is a config file that goes with it
the reasoning behind some changes, e.g: deleted files because they are now redundant
the behaviour to expect, e.g: tooltip has purple background color because the client likes it so, changed a key in the API response to be consistent with other endpoints

How to test
Explain how to test your PR.
If a specific config is required explain it here (dataset, account, profile, ...)
Print screen / video
Upload here print screens or videos showing the changes
Notes
Tag: v1.245a

Fix has been released with v1.256


404 at /docker-for-azure/

I found a broken link : https://docs.docker.com/docker-for-azure/
I arrived on this page through: https://github.com/docker/docker.github.io/issues/11904

This appears to be a duplicate of #11904 . Closing here, lets track this in the other issue.

This appears to be a duplicate of #11904 . Closing here, lets track this in the other issue.


For items that have no translation yet, it is impossible to enter a new translation

If there is no translation yet for a certain translation key then the "Translation"-text field is not shown. Thus, it's not possible to enter a translation (and save it).

Fixed and pushed. Now new importet reference translations are added to alltranslations.


No arm32v7 platform present in eclipse-temurin:latest

I got an image which is build with docker builds on circleci and it suddenly failed today. The platform armv7 seemed to be missing. I did not find anything in the docker docs about the sudden absence of the platform. Could this be an error somewhere?

@tdedobbeleer  What version of our OpenJDK and where are you pulling the image from?

@karianna Good questions, should have been clearer.
I'm pulling from the docker hub and using the latest tag, which is according to the docs OpenJDK19 (don't know if this matters at all). Since I'm using only one dockerfile, I do not specify the platform in the image (I'm not using arm32v7/eclipse-temurin), just eclipse-temurin:latest. This did always succeed, because latest included the arm32v7 platform as well. But now latest does not contain it anymore:
https://hub.docker.com/layers/library/eclipse-temurin/latest/images/sha256-41acc982e932eeb61a51af3262f3070ccfc23a32fd6f89bc16e7fec7647979fa?context=explore
Hence my docker build fails:
------
 > [linux/arm/v7 internal] load metadata for docker.io/library/eclipse-temurin:latest:
------
Dockerfile:1
--------------------
   1 | >>> FROM eclipse-temurin:latest
   2 |
   3 |     ARG JAR
--------------------
ERROR: failed to solve: eclipse-temurin:latest: no match for platform in manifest sha256:f2f82ba81dae08f785bd1e37bd0597b7e514408d1f08d6676a0cba170568b776: not found

this is due to the fact that latest switched to JDK20 and (for now) we cannot ship JDK20 on arm32. I'd suggest you switch your tag to eclipse-temurin:19 and your problem should be solved.

@gdams Thanks, that explains!
The downside of using latest. Should have expected platform issues :) Keep up the good work!


Add module pkl.pipe

Thanks very much to @bioball for bring this code over!
This looks (aside from renames, links etc) unchanged from the internal implementation written by @adstastic and I.
I'm hoping to take these base modules and use https://github.com/jasongwartz/pklpack to build self-contained CLIs for eg. a jq-like tool with Pkl expressions.

Thanks! There's some test failures:
java.lang.AssertionError:
                Expected module name pkl.pipe.tests.examples, but was examples in file file:///home/circleci/project/packages/pkl.pipe/tests/examples.pkl

                To fix, replace the following:

                - module examples
                + module pkl.pipe.tests.examples

You can run the same test locally via ./gradlew in case there's some other issues here.

It's good to see this come back out!


Content should be as high as course navigation

https://de.serlo.org/30195/uebersicht
@creitiv @Knorrke

Or discuss a different solution with michael


Dynamically change background color

Hello,
Is it possible to change the background color dynamically? If not, is it planned to implement it? Or what could I do to implement it myself ?
Thanks in advance,
Have a nice day.

All styling is controlled via CSS, so you can just do <mwl-gauge [style.backgroundColor]="bgColor"></mwl-gauge>

That's not what i'm talking about, i would just change the color of gauge. Ex : if the gauge is at 50% it's orange, 75% it's red, etc...
Thanks for your quick reply

Ah right, you would need to dynamically add CSS classes to control this:
mwl-gauge.red > .gauge > .dial {
  stroke: red;
}

mwl-gauge.orange > .gauge > .dial {
  stroke: orange;
}

<mwl-gauge [class.red]="value > 75" [class.orange]="value < 75 && value > 50"></mwl-gauge>

I'll try it this afternoon, I'll feedback you in the end afternoon. Thanks again.

I don't use your idea, but it works. I prefer to inject class="myColor" which it change the stroke color.
Have a nice day.


[feedback] az feedback feature updates

Feature Updates. When az feedback is run:

[x] The CLI should include the autogenerated issue in the opened browser via the url. If necessary, any exceptions should be minified to stick with the defacto standard of 2000 characters.
[x] The CLI should open a bug report issue if the command selected failed, otherwise it should open a feedback issue.
[ ] It should incorporate the new landing page being worked on by @achandmsft.
[ ] Attempt to report "logical"/brand version names like OS X or Ubuntu 18.04

cc: @yugangw-msft

Concerning getting brand / os flavor names, see:

https://unix.stackexchange.com/questions/92199/how-can-i-reliably-get-the-operating-systems-name/92218#92218
https://github.com/easybuilders/easybuild/wiki/OS_flavor_name_version
https://askubuntu.com/questions/459402/how-to-know-if-the-running-platform-is-ubuntu-or-centos-with-help-of-a-bash-scri

closing this due to lack of bandwidth and urgency
cc: @achandmsft


Do not mutate the users HTTP::Headers object in HTTP::Client

We should not modify a user passed object, that's violating OOP principles. In this case it also actually causes erroneous behavior in case a user reuses a HTTP::Headers object for quite different kind of objects or requests to different hosts. Having a common HTTP::Headers assigned to some constant and be used throughout a library or application is and will not be an uncommon burden. The user should not be responsible for creating copies just because we mutate their object.
The solution chosen here of taking a copy is not the ideal one, but everything else seems to require heavy restructuring of HTTP::Client. This is to fix the issue for the short term, we can open an issue to track work towards a solution that can work without copies.

Yes, definitely, mutating an argument is almost never right.
Just made a small comment, feel free to merge after that. Thanks!


Plans to have an asynchronous client?

I read through the code and concluded the code is synchronous and it's doubtful if it's thread safe.
Are you guys planning to implement an asynchronous version? As the docs note for a running production server with metric points in a few places it might start to become heavy. The solution proposed by the docs is to sample but for counts of requests sampling might not be accurate.

Closing. Please head over to datadogpy which is threadsafe.


tab-delimited key-value file windows line endings

I haven't tested this, but do you check for type of line endings when using -k with a csv/tsv file?
For example, using a csv created under Windows and renaming under Unix...

Sure, I did.
https://github.com/shenwei356/brename/blob/master/brename.go#L981


Create a doc which states what shouldn't be Open

If OSS by Default means starting with open, what are the right arguments for saying something should be closed/private.
Re: https://github.com/artsy/potential/issues/166#issuecomment-412677219

Since I brought this question up in another forum, here are a few proposals:
Always private:

contact or role details for individuals
any information about candidates or new hires before they've consented to announce they're move (this would include onboarding issues)
production data or logs (including indirectly through migration output, etc.)
repositories representing substantial business value, novelty, or criticality (such as the main API, content management system, or auction operator tools)

Maybe should be private, depending on sensitivity:

security or compliance topics, including pending security work items or GDPR procedures
incident/support instructions, including data recovery or incident-mitigation procedures
sensitive business rules, definitions, or implementations (tiering, targeting, buyer/bidder qualification, spam heuristics, search ranking algorithms, data partnerships...)
un-announced feature work
industry or user research or analysis that may hold some competitive value
references to private content (according to the criteria above) including documentation of private systems, links to private gists that may include private data or logs, etc.

The "maybe" category is pretty large and nebulous. Any more concrete criteria we can introduce there could be helpful. Especially valuable would be ways to enforce these considerations over commits or discussions, since lots of content that is already public overlaps with these potentially-sensitive topics.

I'm struggling with the same single-source-of-truth vs. open by default, and want to provide one example recently while working on an onboarding session for new hires.
The tour of collector experience is a great session to show case Artsy experience as a collector for new hires and is perfect to be public. However, when working on the counterpart, tour of Artsy partner experience, I realized it may not be a good candidate to be public. it includes many internal processes and admin workflow. It's not ideal I have to put our onboarding sessions in different places.

Yeah, I agree with all of the always and maybes there @joeyAghion
I don't think there is a one-size fits answer all unless we move all documentation private, and personally I'd rather that didn't happen - when we had them private . Yet, if folks feel strongly about it though, we can have an RFC for it though!
We have contemporary examples in the platform practice docs in README where it jumps from  README to Potential pretty seamlessly because most of the useful platform docs need to be private.  Maybe the answer is to move both to potential and just say that's where they live if they need to be I the same place? We don't need to be dogmatic about it.

Closing this issue as stale


Jos branch

So many hrs...

whatever the confilcts are, take my commits in because it all works!!


profileAdd - DomathID

Add me

Seems no conflicts there. Make sure to mark a star to the repository ⭐


Get rid of static this for initializing std{in,out,err}

Convert awkward globals to functions that return ref File and lazily initialize themselves. This should rid us of a bunch of troubles linked to circular dependencies, betterC etc.

This seems more complex than necessary. Just make stdin a pointer to a function that returns a ref. Statically initialize it to a function that initializes stdin, and rewrites the function pointer to point to a function that returns a ref without checking initialization.

@WalterBright that won't work for e.g. functions that take a File and get passed stdout.

Updated

I'm guessing the performance implication of this is likely negligible? Tot that it really matters, but I wonder if an indirect function call is going to be less expensive than an atomic load...

Been thinking of the pointer to function approach. In summary: it can be made to work and in all likelihood it is marginally more efficient, but it's more complicated than the code in this PR.
An arbitrary number of threads may enter the "initialize" pointer to function simultaneously. So inside the function that does the initialization code must exist that does essentially what initOnce does right now. Then the initialization code changes the pointer to the "steady state" function.
Then, for each call in the steady state, we have an atomic load of the pointer to function and an indirect call. On x86 the atomic load is free.

Thanks for all reviews. May I suggest a means to improve the efficiency of reviews.
The PR is an engineering solution in the sense that it uses the tools available (in this case: initOnce and shared bool) to achieve a purpose (in this case lazy initialization of the stdc file handles). A way to look at this is:

Is this a valid engineering solution, i.e. does it use the available tools appropriately to achieve the need? If not, suggest better ways to do so.
Could the tools available be better? In this case, a runOnce function in the style of https://linux.die.net/man/3/pthread_once would make things clearer and simpler, assuming it can be implemented efficiently.

What happens sometimes is that discussion on the first topic (appropriate for the PR) get into the second. At best, we would enhance collaboration by helping the PR creator instead of assigning him/her the second task in addition to the first one. Right now we are in the position where a couple of collective hours have already been spent in debating what would be correct and what wouldn't. The same time could be spent infinitely more productively by simply writing a better tool (e.g. runOnce or something better) and proposing it in the form of a PR for the standard library.
So, @klickverbot you clearly have the know-how and the enthusiasm in the topic. Could you please implement runOnce or whichever primitive you think is best?

(I'll note that @radcapricorn would be just as indicate for the task but if I asked "could @klickverbot or @radcapricorn ..." each would assume the other would do it and there'd be no progress.)

Thanks :) I'd ask for another candidate in any case, I already have a few PR which I want to see through into Phobos or rejected first.

I committed an alternative implementation that does not use initOnce. LMK if that's preferable.

@klickverbot The fly in the ointment is __gshared, which indeed is poorly defined. The code (whether using initOnce or atomic integrals) assumes that stores to __gshared variables cannot be moved across reads or writes of shared data. This is similar to the way Java defines the interaction between volatile and non-volatile data.

@klickverbot

D currently has no formal memory model, but given that the good old "hope that the compiler doesn't transform the code too much" approach works just fine with DMD...

This one should not apply. According to TDPL, shared implies a compiler barrier, so the compiler should not reorder anything past shared read or write instructions (I see @andralex confirms that). If any of the compilers do that today, that's a bug.

The problem with the proposed change is that loading true from initialized on thread A is not enough to introduce a happens-before edge from the stores to the FILE variables on another thread B that ran the initializers to whatever later uses on thread A there might be. Non-atomic accesses to different memory locations are simply not ordered with respect to each other at all.

Yes it is in the initOnce version, because both stores are protected by a memory barrier (incurred by the mutex). It can load false after FILE was stored, yes. It can never load true before that.

@klickverbot could you please please kindly please write five lines of code that clarify what you say? Essentially could you please paste the code as you think LDC would find it correct? Thanks!

According to TDPL, shared implies a compiler barrier, so the compiler should not reorder anything past shared read or write instructions (I see @andralex confirms that).

Unless something has changed very recently, in spite of what TDPL says, shared does not currently imply a barrier, and it's been debated as to whether it should (because of the performance hit that memory barriers incur). It's one of those aspects of shared that really needs to be fully defined but hasn't been. So, even if we all agreed that it should imply a memory barrier, it's not what the compiler does, and relying on it would be error-prone.

@jmdavis compiler barrier, not memory. The part about shared and memory barriers in the book was fuzzy at best. And IMHO, there should be no such requirement, as each case is unique and requires a manual approach.

@klickverbot ok just to make sure. You are saying:

https://github.com/dlang/phobos/pull/5421/commits/099fa37bb528b561d472c92ed5b5c244fce38229 is correct albeit slow
https://github.com/dlang/phobos/pull/5421/commits/38ebccd929888bf0d555936bdf598ff3acccc2db is incorrect
https://github.com/dlang/phobos/pull/5421/commits/ee318374bd7938e9156e2c29da53785d65958e36 you're not sure about yet

Is that correct?

@klickverbot in one more attempt at understanding what you mean, I created https://github.com/dlang/phobos/pull/5421/commits/3f583249f8a315515918c92ddc513f464b9d27b5. Is that correct?

@klickverbot and since you say ldc does not handle loads from shared in any special way, I added them in https://github.com/dlang/phobos/pull/5421/commits/e445f185591fc8a4c52f6e1b9db722c8d643eb9a. So is that code correct?

The store to initialized would need to be at least release, which it won't implicitly be for LDC.

Isn't that the responsibility of initOnce? I.e. if it doesn't do so it has a bug. No?

@klickverbot btw by<EMAIL_ADDRESS>we cannot afford the solution that uses only initOnce - it's a considerable performance regression. So I'm looking for a better way.

@klickverbot I'm very much lost over here. Getting back to practicality: Can you please paste here a correct and fast implementation of lazy initialization for the std handles?

LDC and GDC will hopefully fare better (a fix would be easy if not).

Could you please verify how they currently fare? That would be helpful information.

@klickverbot I think I get it. A key part of that is that this line uses a plain store, not an atomic store:
https://github.com/dlang/phobos/blob/master/std/concurrency.d#L2422
It seems to me we should make that an atomic store. That way we don't need to rely on interaction between atomic stores and regular stores.

@klickverbot all told I think the solution currently present in this PR is adequate: it's fast, uses the same assumptions as initOnce, doesn't need a mutex, and uses a simple spin lock which is appropriate given that the payload is only two assignments. Works?

@radcapricorn tried the email I had for you at loniir.ru, not working. Could you please email me? Thx!

@andralex done. Yeah, that old address should be dead.

thx!

This function was added about a year ago to simplify lazy initialization, no need to roll your own spinlock either @andralex.

@MartinNowak the initial version used initOnce indeed. It marked a performance regression for using std* handles.

@MartinNowak the initial version used initOnce indeed. It marked a performance regression for using std* handles.

I'll have a look at<EMAIL_ADDRESS>doesn't seem like much investigation happened.
Meanwhile this PR broke unit-threaded Issue 17472 – [Reg 2.075] typeof(stdin) is no longer a File.

Generally we should offer implementations the freedom to swap properties for variables. Granted, that's not present in the specification so yes this PR is liable to break code that queries the type of stdin etc. But we need to make progress on larger issues and not all breakages are equal. This change stays.

Generally we should offer implementations the freedom to swap properties for variables.

Only you didn't make it a @property, this being the case where it matters.
struct S {}

S foo() { return S(); }
@property S bar() { return S(); }

pragma(msg, typeof(foo));
pragma(msg, typeof(bar));

@MartinNowak: Agreed, as mentioned above I don't think the inline spinlock thing is worth it (my green checkmark thing concerned the actual implementation, which was broken before).

Performance of initOnce isn't that well because a common Mutex is passed as default argument, but this one is also created lazily. Combined with dmd's incapable inliner, this makes 2 function calls, and 2 atomic loads (in non-inlineable asm block functions).

@MartinNowak thanks for the PR. @mdparker interested in a blog on "The One Use Case of @property"?

@mdparker interested in a blog on "The One Use Case of @property"?

@mdparker if you follow up on this, accessors and this NG post might be helpful.

Yeah, I'll add it to my list for after my @nogc post.

interested in a blog on "The One Use Case of @property"?

Are you sure this is a good idea? I mean... https://wiki.dlang.org/Language_issues#Properties

I think @property has gotten to a stable fixed point; any improvements we may add to it will allow more code to compile without breaking what it serves for right now.

Perhaps I missed this in the discussion about, but this P.R. breaks code that takes the address of std{in,out,err}, i.e. File* a = &stdin;.

Is there a reason why makeGlobal isn't @trusted? Seems mad that std{err,out}.writeln("some string literal") can't happen in @safe code.

@John-Colvin missed that. Could you please create a short PR? Thanks!

Is there a reason why makeGlobal isn't @trusted? Seems mad that std{err,out}.writeln("some string literal") can't happen in @safe code.

In case someone is wondering whether that's a regression - it's luckily not.
Before this wasn't possible due to Issue 15768
import std.stdio;
void main() @safe {
    stderr.writeln("Hello World");
}

Yes, and until that issue is addressed I'm strongly against marking that function trusted. I'll try to take a look at that issue again today; maybe it's easier to fix now, but it may still turn out that File needs major restructuring for shared.


[boost-ext-mp] Add new port

Co-author-by @ex-purple .

[X] Changes comply with the maintainer guide
[X] SHA512s are updated for each updated download
[ ] ~The "supports" clause reflects platforms that may be fixed by this new version~
[ ] ~Any fixed CI baseline entries are removed from that file.~
[ ] ~Any patches that are no longer applied are deleted from the port's directory.~
[X] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[X] Only one version is added to each modified port's versions file.

I want to ask other maintainers about using the name starting with boost. No changes requested right now.

I want to ask other maintainers about using the name starting with boost. No changes requested right now.

I believe it would be prefixed with bext- so this port would be bext-mp as bext-di bext-sml bext-sml2 and bext-ut already have been ported to vcpkg.


07/30/2018 05:55 : Create Pull Request for branch prTesting_2018073005 -> master

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

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


MongoDB X.509 Certificate Authentication

MongoDB supports X.509 Certificate Authentication, but I am unable to find a way to use this authentication mechanism via Mikro ORM.
Either:

Support for X.509 Certificate Authentication, or
Updated documentation in the MikroORM docs explaining how to do this

More info:
https://www.mongodb.com/docs/manual/core/security-x.509/

You can use driverOptions to pass anything down to the mongodb client, so search for how to do that with node mongo driver. I wont be documenting every single driver specific thing, MikroORM is about the abstraction on top of those things.
Right now there are few smaller notes like this one:
https://mikro-orm.io/docs/configuration#driver
I will do a bigger refactor of the docs before v6 gets out, so will try to add some dedicated section about it.


Tensor Flow blog post

Writeup Tensor Flow example / results

This is really old.  Closing


Cold not load the dark theme

I am not able to load the dark theme in your app. And it seems that the app is crashing after I try to select the theme. I have attached a zip (Steps.zip) that contains the .mht file which can be opened using Internet explorer. Please look into the issue.
Steps.zip

Hi,
I can t change the theme and I can t use the caligator after trying to change the theme.
I added a video of my attemtp to test it in the zip.
I m under WIndows8.1 using caligator-setup-0.0.1-0.exe
caligator.zip

Hi
Nothing happens when I click on theme selection dropdown on Linux Mint 19.3

The app is in pre-release state. For now, what you can do is

Clone the repository

cd caligator-master

npm install && npm start

We will be updating the packages soon.