Time evolving BCS

The current code doesn't allow any of the boundary conditions to change over time. In order to run more interesting simulations, we need to be able to provide users the ability to modify the boundary conditions over various time steps.
Most of the code to allow for this should already be there. However, we'll need to do a few things first:

[ ] Create a good file format that makes it easy for users to modify the boundary conditions at a given time step
[ ] Additional toml options are needed to signal that modified BCS are being used
[ ] Methods written to modify BCS need to work with partial assembly structure

Overall, the design for this should be for our users to write out the evolving BCS. Next, we also want the new code design to be developer friendly. If we add more advance BCS (for example traction BCS) later on for our users the design should be adaptable to allow for this.

In order to be able to effectively implement changing boundary conditions, we need implement a new solver within our SystemDriver class. This new solver will replace our old solver_init function in all intents as purpose as well.
Based on some discussions with the Serac team and how they're dealing with similar issues, the general form of this solver will look like the following:
Step 1:

Calculate tangent stiffness matrix (K_{stiff}) using previous Dirichlet BCs

Calculate K_{stiff}{uc} (v_c{n+1} - v_c_{n}) = \Delta R_u (the change in force for the unconstrained nodes due to the change from the constrained / applied nodes (change in Dirichlet BCs)). It should be noted that u here represents the unconstrained dofs, c represents the constrained dofs, R is the residual, v is our primal variable / velocity field, and n is our time step.

Solve K_{stiff} \Delta v_{n+1} = -(R_{n} + \Delta R) (where our is our previous time step residual)

Step n:

Now apply v_c_{n+1} to the velocity field
Solve things as normal

See discussion in https://github.com/mfem/mfem/issues/1720#issuecomment-709505317 which covers a very similar issue. Based on that discussion, it appears that for the PA and EA simulations we can just set a true vector to 0 and then insert the (v_c{n+1} - v_c_{n}) values and multiple by our previous values. The full assembly method will require a bit more effort and will be more or less a copy of the already existing NLF::GetGradient and ParNLF::GetGradient but we apply the multiplication before the ess. bcs are applied.

So, a few things are going to need to

[ ] Need to revamp our boundary condition manager and data storage. BC Manager needs to clear storage option for when new BCs are going to be applied
[ ]  Allow for essential true dofs to be updated in our nonlinear form that our NonlinearMechOperator class holds. Also, we can just have a version that our class holds, since it's a nonlinearform as well.
[ ] Update the MFEM exaconstit-dev branch to finally remove the BCManager logic that we have inside the NonlinearForm::SetEssentialBCPartial. We should just be able to feed it in a Array2D of components that it needs to touch.
[ ] For the initial guess of things, if we're doing FullAssembly we can just make use of the ParNLF::GetLocalGradient(), since it doesn't get rid of the essential bcs DOFs yet. For the other code we don't need to change anything.
[ ] In the initial guess, we'll want to zero out all of the new constrained DOFs in the residual.
[ ] The initial guess code is only responsible for returning an initial guess in the solution. We'll make use of the normal solve path to solve everything. Therefore, we're only going to do 1 iteration of the newton raphson to get our initial guess.
[ ] The setup phase for NonlinearMechOperator should be templated on whether or not we want to update the mesh coordinates. If we're doing an initial guess step for changing BCs we don't want to update the mesh.
[ ] Create a nice easy to parse file format that can be used for the changing BCs. We'll also need to abstract out quite a bit of the BC logic into functions to make this easier to deal with as well.

The BC file format and the related tasks that go along with that will be done last after I can verify the new method works. Also, the nice benefit from all of the above is that we can remove all of the initial step logic that exists in the material models. Since, it'll no longer be needed.


Video based tracker

Needs some porting to 0.2, and some cleanup (particularly some Eigen usage).

OK, I rebased this branch on the latest master, fixing the (primarily build system) conflicts. I also fixed up the files a smidge (re-wrapping comments, pasting the headers into the templates from the boilerplate generator which I really need to port to Ruby and stick on a better URL). It builds, haven't tested it.

OK, now have a standalone app that can do camera tracking, next will abstract out the source of the images so we can have an automated test run on the saved images.

OK, so I did a fair bit of cleanup, though didn't get it fully testable yet. Thinking we can probably merge this into master (it currently will build as part of CI builds, but the plugin doesn't get installed) - I tested the build on Windows MSVC and MinGW/GCC 4.9.2. Have a few questions that I'll stick in as comments on the pull request.

Fixed the constructors when using the fake images to use the factory instead.  Then it runs with the fake images from the OSVR HDK and displays images correctly.  I think this is ready to merge.

Note that this branch needs either boost 1.56 or the patch described for 1.55 in this post: https://svn.boost.org/trac/boost/attachment/ticket/9332/vc12_fix_has_member_function_callable_with.patch


Create KIP-15, Update Status for KIP-12 & 14

Draft for KIP-15: title: devDAO Community Role Structure
Fix Status for 12 and 14

Thanks Ralf!


upgrade to dbuild-friendly version of sbt-bintray

if this is merged, we'll no longer need to use a forked version
of doodle in the Scala community build

I don't know what problem you apparently had with 0.4.0, but from what I've seen, 0.5.1 is a version multiple projects are successfully using

Thanks!


Quick Fix for issue #6.

Simply adds the snapshot report to the top of the page

Thank you for this!

Hey.
Do you think you could publish this fix to npm?
This is now causing problems for my colleagues.
Thanks

How could I forget! Thanks Red 5.

Should be published now.


Fix CI bugs about TimeWindow

What is the purpose of the change
In TimeUtils, shutdownHook may be executed early, thus affecting the result of CI

Brief changelog
Verifying this change

Checklist

[ ] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

PTAL @AlbumenJ

Codecov Report

:exclamation: No coverage uploaded for pull request base (3.2@d093579). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             3.2   #11848   +/-   ##
======================================
  Coverage       ?   68.86%
  Complexity     ?        2
======================================
  Files          ?     1533
  Lines          ?    63538
  Branches       ?     9303
======================================
  Hits           ?    43756
  Misses         ?    15534
  Partials       ?     4248

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Change cellStates logging to DEBUG

In a very large environment (we have 660 cells and almost over 200K LRPs) this printing of the whole cellState list is massive.
It caused issue where the auctioneer was too busy logging that it would not respond to requests and we had then more auction failures.
Moved this to "DEBUG" so normal production envs would not see the huge amount of data.
Really we do want to maybe print the AvailableResources, Rootfses, and PlacementTags and not the complete structure.  I can look at that as a secondary PR.

Thanks! Looks good


Adding Toggle abilities to Commands/wierd website.

Adding Toggle abilities to Commands.
And creating an adding command method (May subject to change).

Alright, I think I fixed the doumentation

@Swords123456 please use different branches for different features/prs. Currently everything you do will be added to this pr.

Yeah it should, but right now I don't think there is a command firing/event firing implementation


How to use distil-whisper-large-v3-de-kd model from HF?

Officially, multi-language support is still not implemented in distil-whisper.
But I noticed, that the esteemed @sanchit-gandhi uploaded a German model for distil-whisper to HuggingFace, called 'distil-whisper-large-v3-de-kd'
How can I use this specific model for transcribing something?

You can even use the recipe for this checkpoint to train a model in a different language: https://huggingface.co/sanchit-gandhi/distil-whisper-large-v3-de-kd#training-procedure
Simply swap out the --train_dataset_config_name and --eval_dataset_config_name to the common voice split of your choice: https://huggingface.co/datasets/mozilla-foundation/common_voice_16_1

@sanchit-gandhi Thanks a lot for the quick and insightful response!!
Last question: Do you maybe also know, whether I can use the German model via faster-whisper or would it be necessary to convert it with ctranslate2?
Okay, last last question: Do you know the speed difference of transcription via distil-whisper vs. faster-distil-whisper? I coudln't find a comparison.

Hey @Arche151, no problem!

You would indeed need to convert the weights from HF Transformers format to faster-whisper format (CTranslate2). You can use this script for the conversion
Distil-Whisper is an architectural change that leads to a faster model (the model itself is inherently faster). Faster-Whisper is an implementation change (the model is the same, but the code is more efficient). That means that speed gains from Distil-Whisper should carry over to Faster-Whisper (now you have a more efficient model and more efficient code), but this might not necessarily be the compound of the two speed gains combined

@sanchit-gandhi Ahh okay, that background information is super useful. Thanks for taking the time to explain!
Thanks for the script! Should've read the repo better 😅
Do you maybe also know whether I need a lot of compute or a GPU for the conversion and how long it should take?

@sanchit-gandhi  So, I converted the model and used float16 quantization and the quality of the transcription compared to the original large-v3 is really bad :(
A lot of words are transcribed falsely, some words are just not transcribed at all and some words are transcribed twice, so there's duplicates.
In my test script I wrote this:  model = WhisperModel(/path/distil-whisper-large-v3-de-kd-ct2", device="cpu", compute_type="int8")

Hey @Arche151 - could you provide a reproducible code snippet for the behaviour you're seeing? Both for the original large-v3 model, and for the distil-whisper one? This should help discern where the divergence is occurring

I'm guessing here that you're using a long audio file (> 30 seconds)? One of the limitations with the current Distil-Whisper training code is that it shifts the distribution of the model to shorter audio lengths. This means it often breaks when used with OpenAI's sequential long form algorithm. I'm going to push some updated training code in the coming days, where this phenomenon is addressed

@sanchit-gandhi I wanted to ask, whether you had the time to look at my scripts and if the updated training code, that you mentioned, has already been pushed :)


Search addresses by xpub

Can be very useful feature for those who seeks transparency

Extended Public keys can have unlimited number of addresses, each address is derived from a public key of each derived path.
So, searching by public key of each address is meaningless because you could just search the address and searching by Extended Public key nearly impossible because there could be unlimited address for that extended public key.
I made a script that let's you generate as many addresses for the wallet from Extended Public Key. I hope it helps https://runkit.com/tarmo888/5d72cf0c75a29c001ae4382f
You can find a xpub for each of your wallet when you click on Gear icon -> Advanced -> Wallet Information.


Changed wording and fixed grammatical errors in Advantages and Disadvantages of JavaScript tutorial

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.


End of line comment parse error

This:
valid = [
  "xx" // ok
  "yy"
]

invalid = [
  "xx" // still ok
  "yy" // oh no!
]

fails with:
[Error: Parse error on line 8:
... // still ok  "yy" // oh no!]
----------------------^
Expecting ',', ':', '=', ':=', ')', ']', got '}']

Is this a bug?

I'd say so.  I think it seems perfectly reasonable however uncommon to use the currently invalid case.

Oh this is probably the same as https://github.com/featurist/pogoscript/issues/53


tls-check not compatible with PeerAuthentication object

Bug description
Hello,
The istioctl authn tls-check always report a status set to CONFLICT: it doesn't manage to retrieve the authentication policy object applying to the host.
HOST:PORT                                  STATUS       SERVER      CLIENT           AUTHN POLICY     DESTINATION RULE
reviews.default.svc.cluster.local:9080     CONFLICT     DISABLE     ISTIO_MUTUAL     None             default/my-destination-rule

The status seems correct when I use a MeshPolicy object:
HOST:PORT                                  STATUS     SERVER     CLIENT           AUTHN POLICY     DESTINATION RULE
reviews.default.svc.cluster.local:9080     OK         STRICT     ISTIO_MUTUAL     /default         default/my-destination-rule

Expected behavior
tls-check should report the correct status of mtls.
Steps to reproduce the bug

Enable automatic sidecar injection: kubectl label namespace default istio-injection=enabled

Deploy the bookinfo application (https://github.com/istio/istio/blob/master/samples/bookinfo/platform/kube/bookinfo.yaml).

Apply a destination rule

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: reviews
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
    - name: v3
      labels:
        version: v3

Apply a virtual service

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 0
        - destination:
            host: reviews
            subset: v2
          weight: 100
        - destination:
            host: reviews
            subset: v3
          weight: 0

Apply an authentication policy

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "example-policy"
  namespace: "default"
spec:
  mtls:
    mode: STRICT

Result:
istioctl authn tls-check reviews-v1-756b7ff5cc-6rp7l reviews.default.svc.cluster.local
HOST:PORT                                  STATUS       SERVER      CLIENT           AUTHN POLICY     DESTINATION RULE
reviews.default.svc.cluster.local:9080     CONFLICT     DISABLE     ISTIO_MUTUAL     None             default/my-destination-rule

Workaround:
Use of the MeshPolicy type:
apiVersion: "authentication.istio.io/v1alpha1"
kind: "MeshPolicy"
metadata:
  name: "default"
spec:
  peers:
    - mtls: {}

HOST:PORT                                  STATUS     SERVER     CLIENT           AUTHN POLICY     DESTINATION RULE
reviews.default.svc.cluster.local:9080     OK         STRICT     ISTIO_MUTUAL     /default         default/my-destination-rule

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
$ > istioctl version --remote
client version: 1.5.0
control plane version: 1.5.0
data plane version: 1.5.0 (10 proxies)

$ > kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:16:51Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.10-gke.24", GitCommit:"f2734800eba37df4400813ab9340886059d56105", GitTreeState:"clean", BuildDate:"2020-02-05T18:38:43Z", GoVersion:"go1.12.12b4", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
With istioctl.

Obsolete. This tool is deprecated in 1.5 and will be completely remove in 1.6. Rationale:

With auto-mTLS (enabled by default since 1.5), it is less likely to set DR explicitly for mTLS.

The policy model changes (service -> workload-based) make it more complicated to provide accurate correct analysis. Given (1), having a replacement tool is not high priority at this point.


Optimize state store usage

This PR introduces some improvements to how Kafka Streams state stores are used in the vulnerability-analyzer.
Automatic cleanup of completed-scans-table state store
The completed-scans-table store is where we aggregate results from all applicable scanners, per ScanKey. The intention is to only forward a result events to dtrack.vuln-analysis.result once all scanners completed their work. The store was prone to accumulating lots of data, for the following reasons:

Scanner results can be quite big (depending on how many vulnerabilities were identified). The data is compressed in Kafka topics, but it's uncompressed in the local state store.
KTables do not support manual deletions or TTL policies, so entries never expire and stay around forever
The default segment.bytes for changelog topics is 256 MiB. Kafka can only delete records of "inactive" segments, meaning that partitions in the changelog topic must accumulate >256 MiB of data first before compaction can kick in.

All of the above are amplified by the fact that ScanKeys are unbounded, as there is no finite set of keys.
We worked around (2) by introducing a processor that emits Tombstone records for ScanKeys for which no update to the completed-scans-table was observed for over an hour. This approach is recommended by Confluent.
While this does keep the table from growing indefinitely, we could still run into situations where lots of unique keys accumulate over the course of 1h. This is unfortunate because we don't need the aggregated scanner results anymore, once they are "complete" and we forwarded them.
This PR adds a custom Processor that replaces the previously used KTable. It includes logic to delete completed aggregates from the store, but it also still performs TTL enforcement to regularly clean up old records. This change is backward-compatible, because it reuses the existing state store.

Note
The topic hyades-vulnerability-analyzer-completed-scans-table-last-update-store-changelog is no longer necessary and should be removed after deploying the updated vulnerability-analyzer service.

Configurable state stores
It is now possible to configure whether in-memory or persistent state stores shall be used. Further, certain customizations to RocksDB are configurable (e.g. the compaction style and compression type). These settings are currently applied globally to all state stores. In the future we can scope them to individual state stores, too.
To switch all state stores to RocksDB, and enable compression, the following properties may be used
state-store.type=rocks_db
state-store.rocks-db.compression-type=lz4_compression

Smaller changelog topics
When using state stores, Kafka Streams will, per default, create changelog topics with segment.bytes set to 256 MiB, which is a lot (too much) data in many cases. It artificially increases restoration times.
We now have a centralized default configuration for changelog topics, that applies a few stricter limits:
https://github.com/DependencyTrack/hyades/blob/33bee8685498bbf70db0658dd3dfa850e8dbb8a7/vulnerability-analyzer/src/main/java/org/hyades/util/StateStoreUtil.java#L54-L59
Log segments are limited to 64 MiB, and records are signaled to be eligible for compaction immediately after they've been written. This should help with keeping topics smaller, and having compaction kick in sooner.
For some topics it may even be practical to reduce the segment.bytes even further, but I am not quite sure yet what the actual performance impact on the broker side is yet.

But is failing, but the change to the proto definition is in fact backward-compatible: https://protobuf.dev/programming-guides/proto3/#deleting


Experimental v5 crashes, ev3 works

Experimental v5 (ALVR server binaries from GitHub release and ALVRClient built from https://github.com/JackD83/ALVRClient/commit/dbaaf13393f161882ddb771ddc37f9b55dabb1d0 or https://github.com/JackD83/ALVRClient/commit/7a20a4e3f435967793ca562d8f4162bae47fdeb1 + https://github.com/JackD83/ALVRClient/pull/1) is constantly crashing when starting Steam.
Experimental v3 (ALVR server binaries from GitHub release and ALVRClient built from source with the same modification) is working.
All ALVR settings (%LOCALAPPDATA%\ALVR folder) on PC were deleted. FFR was not enabled.
Excerpt from the crashlog:
Exception: Unhandled Exception.
ExceptionCode=E06D7363
Address=000007FEFD2AB87D (000007FEE4DF0000 +<PHONE_NUMBER>4BB87D)
OSVer: MajorVersion=6 MinorVersion=1 Build=7601
Module: 000007FEE4DF0000
----------------------------------------
[00:20:18.089 698] got tracking info 3582 -0.313637 -0.078612 -0.065789 0.943994
[00:20:18.089 698] CONTROLLER 0 0.000000,0.000000,0.000000 - 0.000734,-0.004234,0.005565
[00:20:18.089 698] Controller0 0 1: 00000000 00000013 0.000000:0.000000
[00:20:18.089 698] CONTROLLER 1 0.000000,0.000000,0.000000 - -0.000308,0.000604,0.002268
[00:20:18.089 698] Controller1 1 2: 00000000 00000011 0.000000:0.000000
[00:20:18.089 698] Rotation Matrix=(0.978984, 0.173519, -0.107151, 0.000000) (-0.074897, 0.794608, 0.602485, 0.000000) (0.189685, -0.581798, 0.790905, 0.000000)
[00:20:18.089 698] GetPose: Rotation=(-0.313637, -0.078612, -0.065789, 0.943994) Position=(0.010037, -0.055899, -0.135191)
[00:20:18.089 698] Try to send.
[00:20:18.089 698] Poller::Do(). Select 10000 us
[00:20:18.089 698] Cuda kernel execution failed. code=18 invalid texture reference
[00:20:18.089 698] Unhandled Exception.
ExceptionCode=E06D7363
Address=000007FEFD2AB87D (000007FEE4DF0000 +<PHONE_NUMBER>4BB87D)
[00:20:18.089 698] GetNextSwapTextureSetIndex<PHONE_NUMBER>001280<PHONE_NUMBER>001340 0 0
========== Exception info start ==========
ExceptionCode=E06D7363 Address=000007FEFD2AB87D ThreadId=7388
RaiseException(RaiseException) +61
========== Exception info end ==========

Has anybody else faced similar issue?

A very strange error.
What hardware setup do you have? You already wrote me that you updated to the latest nvidia driver. I have two working setups with two different quests, but both have a GTX1070 and the latest 436.15 driver.
Have you tried to uninstall the alvr_driver and re-install? Maybe something is stuck.
Maybe @zarik5 has more insight, the changes from ev4  to 5 came from him.

I have Nvidia GTX 1660 Ti. Driver version is 436.15.
I have tried to click "Uninstall driver" and "Install driver".
Just tested and ALVR Experimental v4 is working (together with ALVRClient ev3). So the problem is introduced in ev5.
CC: @zarik5

I just upgraded from Visual Studio 17 to 19 and from CUDA 9.2 to 10.1
Maybe you give it a try. You need to rebuild everything and reinstall the alvr driver

I can confirm that it crashes for me too. What crashes is SteamVR and then I get an error message which I assume it's from SteamVR too? Or maybe ALVR but the application keeps it open and "working" (not hang). V4 works perfectly fine and it's the one that I am using right now. I have tried several times going back and forth with V5 and there is no way of making it to work. I always uninstall and reinstall drivers. There is something on that build that makes it to not work. I don't even enabled FFR. So, unless there is some charasteristic introduced that requires Win10 (I use Win7 right now) I have no idea what could it be. Either way, if for some reason the addition of FFR would require such feature, it would be better if we could still use the software turning it off otherwise people like me wouldn't be able to use the whole ALVR all together.
Thank you for your hard work ♥

For the rest of humans like me, does that means that it's fixed? When will we see the next experimental release? I am not avid enough to compile and such :(

I made a release of experimental v6 and hope that its fixes this error

I can confirm - v6 works well (at least on my PC where v5 always crashed).


"Response ID mismatch" error when trying to send

Response ID mismatch.

Was this an isolated incident or is it reproducible ?

Closing as no response, issue not reproducible and in any case from the above suspect was a companion app issue.


Application/json POST

Hello, before today's update, I was able to reuse Auth_Token value obtained after login, but now it seems not possible to put this value somewhere, I am missed :(
Before I was able to have something like:
Auth_Token: Code
Content-Type: application/json
Now I have
Body content type
applicatio/json
But no idea where and how to add Auth_Token: Code
Thanks for any help

Sorry just find, if someone else need the information:
Click on Headers, the auth_token is there ;)


Status errors in Youtube-DLG

Checklist

[ ] I'm reporting a broken site support issue
[y ] I've verified that I'm running youtube-dl version 2020.03.24
[y ] I've checked that all provided URLs are alive and playable in a browser
[y ] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[ y] I've searched the bugtracker for similar bug reports including closed ones
[y ] I've read bugs section in FAQ

Verbose log

PASTE VERBOSE LOG HERE

Description

WRITE DESCRIPTION HERE
I just discovered this. Everything seems to work as expected but all recent downloads give a status error. The downloads seem OK, but I can't figure out how to see the audio bitrate. Properties shows bitrate of zero. I have mp3 128 copies of these, but I was hoping to get higher rez copies.
Why am I getting these errors?

If the issue isn't reproducible from the command line youtube-dl, it's likely to be a defect with your frontend app. Consider reporting the issue on the GUI's GitHub page instead. Good luck! :)


Redirect on HTTPS

Is it possible to force Umami to redirect on HTTPS URL when a user visits an insecure HTTP URL?

Umami doesn't know anything about the environment it's hosted on. You will have to configure it on your web server.

Heroku tells that this task should be solved on application level
https://help.heroku.com/J2R1S4T8/can-heroku-force-an-application-to-use-ssl-tls

Maybe something like this will work, https://www.npmjs.com/package/redirect-ssl


💯 Write funner, better culturally-relevant, mind-expanding, interesting Exercisms 🗓

User story
As a person who appreciates non-Western date formats,
I want to come up with an excuse to write code in different languages,
So I wrote this issue to intrigue Fullstack-ers:
Exercism problem submission idea:

Write a problem that asks the user to turn a Western year format (e.g. 2012) into a Japanese format (平和　２６）and other non-Western formats.

Start:

https://github.com/exercism/x-common/blob/master/CONTRIBUTING.md#implementing-a-completely-new-exercise

Made at Fullstack :zap:

I've played with this idea before: worked on Traditional Chinese DateTime (https://github.com/IanDCarroll/TemporalConverter). I suppose I could write a test script for someone to code against...


Update CC compatibility notes for java-gradle-plugin

Publishing plugins with Ivy is not yet supported, even though general Ivy publishing works.

@bot-gradle test BD

I've triggered the following builds for you:

BuildDistributions build

@bot-gradle test and merge

I've triggered a build for you.


npm update fails in CRA app after node-sass

Describe the bug
After the install of node-sass in a newly create CRA app, npm update fails with below error.
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@babel/core
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/react-scripts
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@svgr/webpack
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/react-scripts
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!   9 more (babel-jest, babel-loader, ...)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@babel/preset-env/node_modules/@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@babel/preset-env
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/@svgr/webpack
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!       node_modules/react-scripts
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See C:\Users\peter\AppData\Local\npm-cache\eresolve-report.txt for a full report.

npm ERR!      C:\Users\peter\AppData\Local\npm-cache\_logs\2021-03-25T20_42_43_029Z-debug.log

Did you try recovering your dependencies?
Yes, cleared npm cache and setup new project.
Environment
- create-react-app version: 4.0.3
- NPM version: 7.7.4
- Node version: v14.16.0
- Node Process: {
  node: '14.16.0',
  v8: '8.4.371.19-node.18',
  uv: '1.40.0',
  zlib: '1.2.11',
  brotli: '1.0.9',
  ares: '1.16.1',
  modules: '83',
  nghttp2: '1.41.0',
  napi: '7',
  llhttp: '2.1.3',
  openssl: '1.1.1j',
  cldr: '37.0',
  icu: '67.1',
  tz: '2020a',
  unicode: '13.0'
}
- Node Platform: win32
- Node architecture: x64
- node-sass version:
    node-sass       5.0.0   (Wrapper)       [JavaScript]
    libsass         3.5.5   (Sass Compiler) [C/C++]

- npm node-sass versions:
├──<EMAIL_ADDRESS>└─┬<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    └──<EMAIL_ADDRESS>deduped

Steps to reproduce

npx create-react-app test3 typescript --use-npm
npm install node-sass
npm update

I've got the same issue, did anyone find a fix?

This is an issue in npm version 7+. @petersowa and @SirPryderi. You will need to downgrade your npm versions to the stable 6.14.11
Solution: npm install<EMAIL_ADDRESS>-g

I've got the same issue, did anyone find a fix?

For a workaround I switched to yarn.

I've got the same issue, did anyone find a fix?

For a workaround I switched to yarn.

Brilliant move @petersowa. Yarn is better than npm in numerous things

Closing as this appears to be an NPM issue.

Possibly https://github.com/npm/cli/issues/2999

Work with npm version 7.8.0

Work with npm version 7.8.0

I am having this issue with npm 7.8.0

Work with npm version 7.8.0

I am having this issue with npm 7.8.0

Im add in my composer.json "@babel/core": "^7.13.14"`

Updated to the newest version of NPM and added npm install --save-dev @babel/core. No more update fails with node-sass.

This is an issue in npm version 7+. @petersowa and @SirPryderi. You will need to downgrade your npm versions to the stable 6.14.11
Solution: npm install<EMAIL_ADDRESS>-g

thanks a lot, this helped me

Solution from @paramore2k Worked, thanks

i'm having the issue with the npm ..(latest version of the npm is : 7.16.0

@pavantanniru try using latest node 14.17.1

npm install<EMAIL_ADDRESS>-g

I had NPM version 7.20.0. Downgrading to 5.14.11 works like a magic. Thanks.


Not keen on 2nd parameter of defProc function in Network.js

If you look at https://github.com/jpaulm/jsfbp/blob/master/examples/update_c.js , you will see 3 occurrences of the reader.js component.  The 2nd parameter of the defProc calls seems to be there just to produce meaningful list items in the trace log, if one is requested.  OTOH it means thinking up what is really a 3rd name for the process.  I would suggest that the name simply be generated using func plus a number, thus removing the requirement for a 2nd parameter on defProc.  Comments, anyone?

I'm not sure that all functions have a name property in JavaScript, since it supports anonymous functions.
Perhaps you could support name templates a little bit like the old C function mktmp (http://linux.die.net/man/3/mktemp)... Just not quite so restrictive.

I was able to confirm my first point from the node REPL:
$ node
> var foo = function a(){}
undefined
> foo.name
'a'
> var bar = function(){}
undefined
> bar.name
''

Anonymous functions do, indeed, have no name, so they can't be relied upon for naming Processes.
I'm going to create a speculative PR for a possible solution to this.

Just curious - why?!
On Wed, Jun 1, 2016 at 10:42 PM, Dan Rumney<EMAIL_ADDRESS>wrote:

Reopened #35 https://github.com/jpaulm/jsfbp/issues/35.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jpaulm/jsfbp/issues/35#event-679269889, or mute the
thread
https://github.com/notifications/unsubscribe/AATGJ5irmfofOO7b95_V7Onplvy2HNBSks5qHkMbgaJpZM4HGh_N
.

I closed it by accident... i meant to close the PR


Created Flush Search

This is just an idea. Wasn't that hard to implement. I hope I did it right.

#59

@syentix Please make a PR to my feature branch as mentioned in the Contributing.Md file

I'm sorry, I totally forgot. Should be ready :)


cloudflare modules

https://github.com/nuxt/nuxt.js/issues/11747
https://developers.cloudflare.com/workers/cli-wrangler/configuration#modules
Using this, we can natively use imports for chunks instead of using one entry (maybe behind a flag?)
An alternative might be using KV + eval but last time checked both eval and importScripts were forbidden due to security concerns they had. So it is probably the only way to use the native option.
Note: This is not replacing normal workers as is a paid service.

Note: This is not replacing normal workers as is a paid service.

I'm not sure what you mean with this sentence... But I can confirm that eval is not supported : https://developers.cloudflare.com/workers/runtime-apis/web-standards/#javascript-standards

I was going to open a issue for a cloudflare pages preset proposal based off of this https://github.com/unjs/nitro/discussions/110 discussion, but wanted to make sure it's not a duplicate of this one first. This issue is tagged as a preset proposal as well, though atleast to me cloudflare modules itself sound like a change from the existing old cloudflare workers syntax to to ES modules. Does this issue include a cf pages preset or should I open a seperate one which people can then be pointed at?

If the unjs/nitro team is willing to document a preferred approach to custom presets, I'd be more than happy to take a crack at the CF modules upgrade. Looking at the source code, it seems like a majority of the work would involve creating a runtime entry file, of which I'm moderately familiar with (since its primarily just a CF worker script/handler). Even just a few pointers from the unjs team would probably be enough; I can leave a simple gist link here rather than commit a new preset.

Closing as this landed with https://github.com/unjs/nitro/pull/681


WIP: change storage version to v1beta1

Signed-off-by: Matthias Wessendorf<EMAIL_ADDRESS>Fixes #
Proposed Changes

setting storage version to v1beta1

Release Note

Docs

/assign

@matzew https://github.com/knative/eventing-contrib/issues/1396 is the ticket for this PR.
feel free to assign it to yourself.

@matzew there's also the source and we need to do the same thing there too.
Let me create the setup for migration and then we can do the same thing for channel as well.

More specifically:

Example PR for storage version update and migration job: https://github.com/knative/eventing/pull/3923
Example PR for tooling for the storage version update: https://github.com/knative/eventing/pull/3283

About required tooling changes: https://github.com/knative/eventing-contrib/issues/1394#issuecomment-681882435

/close
Created tickets in new repo, knative-sandbox/eventing-kafka for the remaining tasks: https://github.com/knative-sandbox/eventing-kafka/issues/65


Derive everything for the ENUM! generated types

#[derive(Clone, PartialEq, Eq, Hash, Debug)] - at least that
This is an easy one. Please make it happen before releasing a new version.

All of those except for Hash are already implemented https://github.com/retep998/winapi-rs/blob/master/src/macros.rs#L210
However, due to long compile times caused by all the codegen from all those impls I'm considering making the representation just be a plain integer in winapi 0.3 so I don't have to impl any traits.

Should be fixed by https://github.com/retep998/winapi-rs/commit/04c79789cb577a1fc0db7e8df741403dd4d4fc1e

ENUM! now creates simple integer constants so no traits need to be derived.


vscode API - workspace - Should send a single FileWillRenameEvent instead of separate events when moving multiple files at once

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=147024&view=logs&j=4d2898ab-dfbe-557e-92e7-aaac158fdd2f&t=0a31a1a1-76c6-5f31-444a-2b6049ed7294&l=436
  1 failing
  1) vscode API - workspace
       Should send a single FileWillRenameEvent instead of separate events when moving multiple files at once#111867:
     Error: Timeout of 60000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/__w/1/s/extensions/vscode-api-tests/out/singlefolder-tests/workspace.test.js)
      at listOnTimeout (internal/timers.js:554:17)
      at processTimers (internal/timers.js:497:7)

A few lines above:
Unable to move/copy when source 'fake-fs:/' is parent of target 'fake-fs:/ellvsq'.
IGNORING workspace edit {}

Maybe another instance of a random file name clash?

Maybe another instance of a random file name clash?

My theory is that the rndName function returns an empty string, https://github.com/microsoft/vscode/blob/ab8e74352064fb4485ab8f9773f1554552165860/extensions/vscode-api-tests/src/utils.ts#L10-L12
It can happen that Math.random().toString(36) is just numbers which than all get replaced with ''. I will come up with a new name generator and see how that goes

Pushed better logic for rndName, calling Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 10) in a loop until it hits '' takes surprisingly little time

Oh interesting, will check all the other usages we have of Math.random for file names, looks like there are more, even outside of tests.


Render ready markdown text

I don't actually understand how to initially render markdown text with markdown style, what do I suppose to add in markdown-editor template?
<markdown-editor
          toolbar=""
          v-model="content"
            ></markdown-editor>

You can read config: https://morioh.com/p/2a1c9c34024b

Indeed you can't have just preview if you do this:
<markdown-editor           toolbar=""           v-model="content"             ></markdown-editor>
it will show just a box with the markdown normally without toolbar.
It should be a way to get to the preview variable inside, like adding something like preview-mode which would set that to true:
<markdown-editor           toolbar=""           v-model="content"           preview-mode="true"             ></markdown-editor>
Maybe there is one to access the command function but I can't figure it out
Cheers.

I agree, it would be very helpful if we could just pass an option to trigger the preview prop to be set to true on instantiation. I want two instances next to each other with the same model, so the second one shows a preview of what the user enters in the first one


sap_ha_*: update module names to fqcn

Several tasks are still missing the fqcn in the module names.
Known gap to be fixed.
https://github.com/sap-linuxlab/community.sap_install/pull/161#discussion_r909578611

@ja9fuchs I think all FQCN are added in 1.2.0 release of sap_ha_* Ansible Roles?

Reviewed and looks like the gaps have all been fixed.


error 500 when accessing features/search

{"featureSetId":"WyIxa2dlbm9tZXMiLCJnZW5jb2RlX3YyNGxpZnQzNyJd", "start":3864, "end":11592, "pageSize":1, "parentId":"", "featureTypes":[      "gene" ], "referenceName":"chr1"}

I'm was seeing 404 on api requests (/variants/search) to http://1kgenomes.ga4gh.org/

@cmdcolin We just upgraded the 1kgenomes server to the protobuf version here As part of that effort we had to re-import all of the data. This changed all the hash ids so you may be running into a problem with trying to access a stale id. That is just a guess. If that is not your problem then please post the exact query you are making and we will have a look.

@kozbo gotcha. I had some inkling that it might be related to this 500 error, but i'll recheck hash ids. thanks!

We had a permissions issue on one of the directories holding the data. Added 777 permissions to the directory holding the gencode annotations file. Original error should be fixed. @cmdcolin Please open a new ticket if you are still getting a 404 error.


LogAnalytics Custom Tables are not created

Hi, We have deployed this solution as per the documentation and added multiple Log analytics workspaces for VM/VMSS perf metrics. Runbooks are running as per schedulers, but when we check workspace for these custom tables, we dont see them and workbooks are throwing table not found errors.
AzureOptimizationVMsV1_CL
AzureOptimizationResourceContainersV1_CL
AzureOptimizationConsumptionV1_CL
AzureOptimizationAdvisorV1_CL
As result of which, recommendations exporter runbook throwing tables not found (0 records found) message.

@mmaroth-BRONGA, I understand other tables are being populated correctly and only these 4 ones have no data. Can you please check if the following runbooks have been running correctly, I mean have they completed successfully and do their logs indicate data rows were generated?

Export-ARGVirtualMachinesPropertiesToBlobStorage
Export-ARGResourceContainersPropertiesToBlobStorage
Export-ConsumptionToBlobStorage
Export-AdvisorRecommendationsToBlobStorage

Furthermore, the Ingest-OptimizationCSVExportsToLogAnalytics runbook executions should have evidence of having ingested into Log Analytics the rows coming from the CSVs exported by the runbooks above, which should have been stored in the following Storage containers:

argvmexports
argrescontainersexports
consumptionexports
advisorexports

Hi there, I am having a similar issue.
i get these errors when i go into the Workbooks:
'where' operator: Failed to resolve table or column expression named 'AzureOptimizationVMsV1_CL'...
'where' operator: Failed to resolve table or column expression named
I am new to this and not sure how to resolve. Please can you give me a detailed steps of how to fix it.
regards,

@slamho, please review my previous comment to original issue posted by @mmaroth-BRONGA . Also, you must give a couple of hours to AOE, so that it has time to export data, ingest it into Log Analytics and have it indexed by the Log Analytics service. It may take 2 to 3 hours after deployment.

@helderpinto. thanks for the response!
The solution was deployed last week Thursday.
When i look at the above-mentioned runbooks I can see they all completed successfully. I checked the output and see they all ran ok with DONE at the end. In the output i can also see it exporting to the CSV file or uploading to CSV to Storage.
When i go to the AOE's storage account, and scroll to Storage browser, it shows me there is data in the Blob containers and Tables (Only system generated tables exist).
I'm assuming these Tables should have been created in the storage account as part of the deployment?
AzureOptimizationVMsV1_CL
AzureOptimizationResourceContainersV1_CL
AzureOptimizationConsumptionV1_CL
AzureOptimizationAdvisorV1_CL
I think i found out why they weren't created.
When I try to manually add the table, it gives an error with the name not conforming. When i remove the underscore, it accepts it.

@slamho, AOE does not use Storage Tables. It uses Log Analytics tables. You should open the Log Analytics workspace created/reused as part of the AOE deployment and look for Custom Logs.

Don't forget to check the Ingest-OptimizationCSVExportsToLogAnalytics runbook, as I referred to in a comment above.

@slamho, the only custom log that is being ingested is the AzureOptimizationMonitorMetricsV1_CL. This means that either:

The Export-* runbooks are not generating CSVs in other Storage Containers (argvmexports, argrescontainersexports, consumptionexports, avisorexports, etc.)
The Ingest-OptimizationCSVExportsToLogAnalytics runbook does not have the required schedules to process those Storage containers.

If you can't find the reason for these issues, can you try deploying AOE again, using the same options you chose in the initial deployment? The deployment script will just update the setup, fixing missing/incomplete resources and keep existing data untouched.

@helderpinto Thanks for the feedback. I manually ran the Remediate runbook and it seems to have created the CL tables now. I also noticed the Remediate runbooks have no schedules.

I am going to leave it and let all schedules run for the week. Will check it on Friday and let you know.
PS: My PowerBI report is blank. Do i need to transform data for it to display?

@slamho, remediation runbooks do not create any table. The only runbook that is capable of doing it is Ingest-OptimizationCSVExportsToLogAnalytics. But I am glad you were finally able to see some data flowing in the Log Analytics workspace.
After setting up the Power BI report according to the instructions, you must wait for the first successful execution of the Ingest-RecommendationsToSQLServer runbook and then refresh the Power BI report. That runbook will collect all the generated recommendations and insert them into the SQL Database where the recommendations history is stored.

Remediation runbooks should be scheduled ONLY if you want to automatically fix recommendations. For example, resizing a VM according to recommended size or deleting an unattached disk. Azure customers generally like to have control over when and how they remediate recommendations, especially in production environments. However, it may be a perfectly valid approach to automatically remediate resources in dev/test environments. As this feature is undocumented, please review carefully the runbook code to understand what is done and in which conditions.
The Transform Data step in the Power BI setup is not required, unless you want to customize some of the report columns with your own tags.

@mmaroth-BRONGA , AdvisorCostAugmentedToBlobStorage will generate results only if Azure Advisor is currently providing Cost recommendations for the subscriptions in the scope of AOE. Having 0 results is not unusual if Azure Advisor considers your environment fully cost optimized (see full list of potential Cost recommendations). However, you also have the custom Cost recommendations that were developed specifically for AOE (VMs deallocated for a long time, unattached disks, Public IPs, etc.).

Thank you @helderpinto  Now we are able to see recommendations in PowerBI.


Allow crons to run during internal testing in maintenance mode

What version of Magento are you using (the full version ex. 2.1.11)?
Magento Open Source 2.2.2
What did you do?
Enabled maintenance mode with exempt IPs for internal testing
magento maintenance:enable --ip=<ip address>
What did you expect to see?
Expected to see crons run in order to validate internal testing.
What did you see instead?
Crons suspended due to maintenance mode.
Context
In cases where maintenance has been enabled with exempt IPs, it's understood that developers or other testing team members will need to utilize the site to test functionality before opening up to customers. This includes performing integration tests which require cron execution (ex. synchronization of order status, tracking, and stock).
Alternative
Using the IP exemption list seems like a good flag for determining whether to enable/disable cron execution. However, if other users of the extension have differing requirements, I'd suggest we add another option, similar to Cron Enabled , to support this requirement. Or perhaps change the Cron_Enabled from a boolean to a select with different options for when crons should run.

Closing issue as this PR was merged in the 1.2.5 release. Thanks!


Newly added table won't show in popup selection menu

On Non-ChromeOS (not sure about case of ChromeOS),
when we add a new table, the new entry won't appear on page popup menu
until we've made more modifications in preference (ex, move items)

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 11 Sep 2013 at 10:16

Fixed in 06509dfac57abaacbeb4a0845aac3fd9b2bc5886

Original comment by<EMAIL_ADDRESS>on 18 Sep 2013 at 5:32

Changed state: Fixed


Service includes pods from across namespaces that have matching selectors.

Rancher Version: v1.1.0-dev5
Steps to create the problem:
Create service/rc/pod in 1 namespace.
Create the same set of service/rc/pod (using the same yml file) in another namespace.
When service is listed in UI (from any of the namespace),  pods from both the namespaces are listed

> kubectl create namespace test1
namespace "test1" created
> kubectl create -f test1.yml --namespace==test1
Error from server: error when creating "test1.yml": namespaces "=test1" not found
Error from server: error when creating "test1.yml": namespaces "=test1" not found
> kubectl create -f test1.yml --namespace test1
service "k8test1" created
replicationcontroller "k8testrc1" created
> kubectl create namespace test2
namespace "test2" created
> kubectl create -f test1.yml --namespace test2
service "k8test1" created
replicationcontroller "k8testrc1" created

cat test1.yml
apiVersion: v1
kind: Service
metadata:
 name: k8test1
 labels:
   k8s-app: k8test1-service
spec:
 ports:
 - port: 81
   targetPort: 81
   protocol: TCP
   name: http
 selector:
   k8s-app: k8test1-service
---
apiVersion: v1
kind: ReplicationController
metadata:
 name: k8testrc1
spec:
 replicas: 2
 selector:
   k8s-app: k8test1-service
 template:
   metadata:
     labels:
       k8s-app: k8test1-service
   spec:
     terminationGracePeriodSeconds: 60
     containers:
     - name: testcontainer
       image: sangeetha/testnewhostrouting
       ports:
       - containerPort: 81

When ingress is created for this service , lb traffic gets redirected to all the pods ( from both the namespaces).

Tested with v1.2.0-pre1-rc4  and kubernetes 1.3.0 ( rancher/k8s:v1.3.0-rancher3)
Create service/rc/pod in 1 namespace.
Create the same set of service/rc/pod (using the same yml file) in another namespace.
When service is listed in UI (from any of the namespace), pods from both the namespaces are listed.

@vincent99 looks like UI needs to be fixed. Not sure what calculation it uses for displaying pods under service, but it does include pods with matching selectors cross namespaces.
We've put a fix on k8s agent to inject namespace info to the selector of the k8s service that we propagate to Rancher. So this way pods cross namespaces don't join the service. So in the DB, I'm seeing 2 pods behind the service; kubectl also shows only 2 endpoints. Yet UI includes 4 pods

Version - master 8/2
Verified fixed


gtsegs_ijcv.mat

Hello, thank you very much for sharing your work. I have a few questions and look forward to your answers. How do I get the gtsegs_ijcv.mat file? As far as I know, imagenet does not seem to have segmentation labels. Thanks again, and look forward to your reply.

Hi @coderrubbish, thanks for your interest in our work!
Please refer to the results reproduction section of our README, there's a link to download the data.
Best,
Hila.


Proposed legal & governance improvements for the OpenSSF

There have been some formalizations with governance for projects in the OpenSSF.
I think these are all for the better, but if you have a concern, PLEASE let me know soon! I plan to wait for 1 month (2024-03-12) before starting down this path.
Here is the full documents
LLC Series. LF Legal would like this project to become a "series" within "LF Projects, LLC". This creates a legal identity for the project & provides various legal protections. We hope to not need legal protections, but it's best to have them. To do that, the TSCs to be listed on the project page on who is in the TSC.
The TSC then needs to vote on the
Technical Charter Draft.
Make sure the mission is accurate.
Choose a delegate to sign the
Contribution Agreement Draft
Then the LF will submit the
Series Agreement Draft on your behalf.
Please let me know if you have any questions or concerns.

Just an update. We are waiting on our legal and OSPO teams to provide support on this.


Start specific Julia version if it is specified in Project.toml/Manifest.toml

This is probably a bit speculative at this point, but it would be fairly simply to look at a Project.toml/Manifest.toml if one is specified via the --project command line arguments and see whether these specify a specific Julia version. If they do, run things in that specific version.
Of course, right now there is no official way to specify a Julia version in a Manifest.toml. For Project.toml, the situation is a bit different: at least for packages one can specify a version in the compat section. The mybinder integration for example looks for a julia entry in the compat section to decide what Julia version to use. We could do something similar, for example if there was an entry julia = "=1.3.1" in the Project.toml, we could start Julia 1.3.1.
But maybe this should also just wait until there is an official way to record Julia versions in Manifest.toml files.

The entire handling of this from rustup is interesting: https://rust-lang.github.io/rustup/overrides.html. We might want to add the same options here as well.

Of course, right now there is no official way to specify a Julia version in a Manifest.toml

Just to say, Pkg in Julia 1.7+ already does this! See https://github.com/JuliaLang/Pkg.jl/pull/2561 and followups.

Ah, nice!
I think the big question is how we would want this to actually behave. One option would be that we always try to use the exact Julia version that is recorded in the manifest, but maybe that is a bit too drastic, as one probably would want to normally at least use the closest minor matching version, or something like that... Not really sure what the right design here is :)

When this is supported, I would imagine adding some alias
alias julia='juliaup'
alias julia-1='juliaup launch 1'

and everything just works smarter.

No one is working on this, as far as I know. I thought about it, but that is it :)
In my mind, the override hierarchy should probably look like this, highest priority first:

A channel selector used on the command-line, such as julia +beta (implemented).
The JULIAUP_CHANNEL environment variable (not implemented).
A directory override that is stored in the central juliaup.json config file in the Julia depot (not implemented).
The .juliaup.toml file (not implemented, could also come later).
The Julia version stored in the Manifest.toml (not implemented).
The default Juliaup channel, stored in the Juliaup.json config file in the Julia depot (implemented).

I think generally everything except 5 would store a channel name, and therefore be valid only on a specific user machine, i.e. not info that could be checked into source control.
For 4 things are very unclear to me right now. Questions are: is this a file that would be checked into git? Or is this a local config file that we would add to .gitignore? What exactly would we actually store in there? My gut feeling is that we would just not add this in a first implementation and think more about it.
I think 3 could also come later, although that is fairly simple to figure out how it should work, so maybe we should just add it now. We would need to provide a command line interface to use it, as we never want users to manually modify the juliaup.json file.
5 is going to be tricky :) The primary problem is that Manifest.toml doesn't store a channel name, but a Julia version. In general a user can have many channels installed that all provide the same Julia version. We probably also want to consider what should happen if a Manifest.toml stores say Julia version 1.7.2, but the user has a channel with Julia 1.7.3. Should that automatically be used? Should the Manifest.toml be updated? Or offered to be updated? What should happen if a Manifest.toml has a Julia version stored and there is no channel installed locally that matches even the minor version? Prompt that offers to install? In non-interactive mode, should we error and not start? There are also questions how the default project activation interacts with this. If a user does not specific --project=. on the command line, should the Manifest.toml even be considered at all?
I think maybe a pragmatic approach would be to start with an implementation of 2 and 3, and think a bit more about the other options.

I think the implementation of a layered configuration approach itself shouldn't be too bad. Two crates I've used for such purposes before are figment and config. If you prefer fewer dependencies in this instance, it should be possible to emulate it via HashMaps as well.

So as this implementation will sit on the "hot" path of everything, and also be included in the julialauncher executable which we are trying to keep small, I would probably go for a complete "by hand" implementation here... Where we for example don't even read config files that we don't need to read etc. I don't think that would be too cumbersome?
Also CCing @StefanKarpinski and @staticfloat, in particular on the order of overrides.

A channel selector used on the command-line, such as julia +beta (implemented).

👍

The JULIAUP_CHANNEL environment variable (not implemented).

Hmmm, I can see this being useful, but only in rare situations.

A directory override that is stored in the central juliaup.json config file in the Julia depot (not implemented).

I'm not sure why this would be used.  Can you explain more about this?

The .juliaup.toml file (not implemented, could also come later).

I'm not sure why you would use this over a Project.toml or Manifest.toml approach.

The Julia version stored in the Manifest.toml (not implemented).

I like this, but I think it probably needs to be enabled somehow, as it's a breaking behavioral change.  Perhaps julia +manifest, or perhaps an option set at install time.

The default Juliaup channel, stored in the Juliaup.json config file in the Julia depot (implemented).

The thing I'm most concerned about is that a user runs julia --project foo test.jl and sees something that works (because it uses v1.7, matching the Manifest), then they run julia, then run Pkg.activate("foo"); include("test.jl") and it breaks because their default channel is v1.8, or something like that.  Also note the possibility for confusion if someone has defined JULIA_PROJECT.
I think for this manifest-matching mode to not confuse users we need one of the following:

juliaup matches automatically, but it prints out that it's matching to a particular version when it does so.
juliaup does not match automatically, it must be manually-enabled.

Given that we already potentially autoupdate versions when starting julia via juliaup, I've increasingly been wondering what the point of having specific versions installed is. What I mean is: suppose I run julia +1.3 and I haven't added the 1.3 channel.  Currently I get an error. And I can go ahead and add that channel and run it. But why make me do that? Why not just do whatever is necessary to install and run the latest version of 1.3 for me? At that point the idea of having a channel installed becomes a non-concept. You either have a version or you don't and when you use a channel it either has to get a version for that or not.
Ok, how is that related? Well it somewhat simplifies the logic of deciding what version to use since you don't have to worry about what channels are installed. You're either in "offline mode" and have to use a version that is already installed, in which case you pick the best installed version based on some policy, or you're allowed to download any version you want, in which case you pick the best of all published versions also according to some policy. I got her because I started trying to write down an preference ordering on channels and that was hard. The  ordering on versions already exists, why do we have to worry about channels at all when we're trying to pick a version not a channel?
Regarding policies, it seems like you want to choose how much of the recorded version to match exactly and how much to ignore and vary freely. The default would probably be to respect the major and minor versions and ignore the patch. That would mean that in offline mode you'd look at all the installed versions with the same major/minor version and then pick the latest one. In online mode you'd do the same but pick the latest of all patch releases with the same major/minor version. You could also pick a policy that only matches the major number or matches the whole version number.

The JULIAUP_CHANNEL environment variable (not implemented).

Hmmm, I can see this being useful, but only in rare situations.

I think it would make it simple to integrate with something like https://asdf-vm.com/ for those folks that use that. It also should be super easy to implement ;)

A directory override that is stored in the central juliaup.json config file in the Julia depot (not implemented).

I'm not sure why this would be used. Can you explain more about this?

Initially I just copied it from the rust list ;) But here is one scenario where it might be useful: say I get a project from someone that has Julia 1.3.2 stored in the Manifest.toml. I have a 64 and 32 bit version of Julia 1.3.2 installed on my system, so at that point the launcher would presumably default to the 64 bit version, but maybe I want to temporarily (for a few days) test things with a 32 bit version of Julia. But I don't want to record that choice into the Manifest.toml because I don't want to commit this to the repo, I just want to switch this one folder for a few days over to some specific Juliaup channel. I think it would essentially just be a way to locally reconfigure a given directory without putting anything into that directory that might end up in source control. How useful that would really be in the end I don't know.

The .juliaup.toml file (not implemented, could also come later).

I'm not sure why you would use this over a Project.toml or Manifest.toml approach.

It would essentially be another way to locally override things. Or for example make a specific choice that can't be made in the Manifest.toml, like the 32 vs 64 bit binaries. Or maybe one could also configure auto-update behavior for this specific folder or something like that. But, this is all pretty vague in my mind right now, so I would just not do anything about this right now, we can always later add additional entries in this list.

The Julia version stored in the Manifest.toml (not implemented).

I like this, but I think it probably needs to be enabled somehow, as it's a breaking behavioral change. Perhaps julia +manifest, or perhaps an option set at install time.

The default Juliaup channel, stored in the Juliaup.json config file in the Julia depot (implemented).

The thing I'm most concerned about is that a user runs julia --project foo test.jl and sees something that works (because it uses v1.7, matching the Manifest), then they run julia, then run Pkg.activate("foo"); include("test.jl") and it breaks because their default channel is v1.8, or something like that. Also note the possibility for confusion if someone has defined JULIA_PROJECT.
I think for this manifest-matching mode to not confuse users we need one of the following:

juliaup matches automatically, but it prints out that it's matching to a particular version when it does so.
juliaup does not match automatically, it must be manually-enabled.

Yes, that all makes sense to me. Couple random other thoughts:

Maybe 4 (.juliaup.toml) could actually help with this, i.e. it could be a way to locally store a Julia version that will always be used, irrespective of whether one activates a project or not. But it also feels like weird duplication...
I do know what my preferred solution would be: make<EMAIL_ADDRESS>the default :) I know that there were some security concerns around that, but I think one could probably solve them in other ways. In my mind, though, that would at the end of the day be the solution that is closest to what users would expect to happen.
I hadn't really appreciated that with the ability to change project interactively during a running Julia session, we would then always have an aspect of a project that doesn't change when the user does that interactively... I don't like that but also don't really know how one could possibly get around that.

@StefanKarpinski ah, interesting. A couple quick reactions:

I think we can most definitely do way, way more auto-things. julia +1.3 could just install the 1.3 channel etc., so I think much of the behavior you describe we could get while we still maintain the notion of "installed channels", installation of channels would just happen more often automatically. In my mind we should do that no matter what.
So then the question is do we need the notion of installed channels at all? I think it might still be useful for things like juliaup status, or simply the command juliaup update, but I'll have to think a bit more about that...

Btw, I got here because I started trying to write down an preference ordering on channels and that was hard. The ordering on versions already exists, why do we have to worry about channels at all when we're trying to pick a version not a channel?

I know, we already have one attempt at that in the Julia extension for the notebooks. We have the same problem there: we get a Jupyter notebook that has a Julia version recorded and then need to pick the right channel for that. This is the implementation. It is really pretty ad-hoc at the moment...
One very easy out of this would be to just be way more aggressive about auto-installing the x.y.z channels.

My thought on matching a recorded version, 1.2.3 for the sake of example, is:

prefer to match major and minor version, but use the latest patch available, so 1.2.8, if that's the latest patch version of the 1.2 release

no warning if the patch is at least at recent as the recorded version, i.e. 1.2.x for x ≥ 3
warn if the patch is less than the recorded version, i.e. 1.2.x for x < 3 (might be missing bug fixes)

if a matching minor version isn't available (e.g. we're offline), prefer:

the latest patch of the smallest greater minor version, i.e. 1.3.x if available (preferred to 1.4.x, etc.)

slightly more aggressive warning than above (should work but might break if relying on internals)

otherwise, the latest patch of the closest largest lesser minor version, i.e. 1.1.x (preferred to 1.0.x, etc.)

most aggressive warning (may not work if code relies on newer features)

In the meantime, just having JULIAUP_CHANNEL to control the default channel would be really handy as that would at least allow me to use direnv to control the default for various directories and it's pretty clear what setting that should do—it's just equivalent to having set the default channel to the variable's value.

Coming to this a bit late, but I think we should try to integrate the julia version management with the package manager as close as possible. i.e.:

It should respect --project and JULIA_PROJECT as per julia
It should use the exact julia_version in the Manifest.toml

print a warning if not using the latest patch version
support +channel overrides (but these would not change the Manifest.toml)

juliaup instantiate [+channel] --project=... would

install the correct Julia channel using the following logic
a. if specified, use channel (and modify the Manifest.toml accordingly)
b. otherwise use version from Manifest.toml if it exists (with a warning if not the most recent patch)
c. otherwise use most recent [compat]
call julia --project=... -e 'using Pkg; Pkg.instantiate()'

juliaup update [+channel] --project=... would

install the correct Julia channel
call julia --project=... -e 'using Pkg; Pkg.update

So if I have a Manifest.toml with julia_version = "1.8.3", and the most recent patch is 1.8.5 and most recent release is 1.9.2, then
juliaup instantiate --project=...

would install julia 1.8.3 and instantiate the dependencies, but print a warning suggesting I do
juliaup instantiate +1.8 --project=...

Doing this would modify the Manifest.toml to change julia_version = "1.8.5", and install julia 1.8.5 (and precompile for 1.8.5)
If I then did
juliaup update

as long as I didn't have an upper bound in my Project.toml, it would install julia 1.9.2 and Pkg.update() all the packages.

There is a lot in @simonbyrne's list that I like :) A few thoughts on some random parts of it:

print a warning if not using the latest patch version

Or we could essentially use the julia entry in the compat section of the Project.toml to decide whether we should encourage an update, that would probably give us the most flexibility.

instantiate

I generally think that instantiate should never modify the Project/Manifest, but otherwise completely on board.
I think the operation where one manually specifies a channel and tells the system to update the project to that Julia version should be resolve, right?

juliaup CMD

So, I completely agree that ideally we would have a way to issue things like update, instantiate (and I think resolve) on projects from the command line, not just from within the package or Julia REPL. But my thinking lately was that we probably shouldn't pack that into the juliaup command, but instead have a separate juliapkg command line utility that is essentially a command line wrapper for Pkg.jl. And then (in an ideal world) I think Pkg.jl would actually call juliaup internally if it needs to install a certain Juliaup channel to properly resolve a project. One problem with that idea is that older versions of Pkg.jl wouldn't handle the Julia part properly. I think in my ideal world we might have something where Pkg.jl is able to resolve things for any Julia version, and then juliapkg would always use the latest version of Pkg.jl, or something along those lines. That would then still leave a problem if a user uses Pkg.jl from within Julia from an older version of Julia, but maybe there is some way around that as well...

Oh, and one other thing: I generally think we can add a lot of convenience via interactive prompts. Say I run julia --project=..., then I think the julialauncher should really check whether that project is fully instantiated (i.e. Julia + packages), and if not and we would end-up in an interactive Julia REPL, show a prompt that asks whether we want to instantiate. And if things are not fully instantiate, just abort right away and instruct the user to instantiate first.

Or we could essentially use the julia entry in the compat section of the Project.toml to decide whether we should encourage an update, that would probably give us the most flexibility.

I kind of like that the Manifest always gives exactly what is specified, it would be a bit odd that julia itself is an exception to this. Although patch releases are supposed to be non-breaking, there are occasional issues (e.g. there was a change from using RPATH -> RUNPATH linking in a patch release, which caused us enough headaches that we were stuck on an old patch release for a few weeks)

Oh, just to be clear: I definitely want us to always start with the exact Julia version in the manifest, unless someone explicitly provides a higher priority override. I don't think we should do things like "if there is a newer patch version than in the manifest, use that". I was really just thinking about an informational message, but maybe that should just be show like info about new package updates as well.

One thing I will add is that when you do julia --project you are explicitly saying "I trust this code" so it would be reasonable to automatically resolve a manifest, instantiate it and install the Julia version and any package versions that are in an existing manifest. The reason not to do that by default is that someone could start a julia REPL when they happen to be in a directory that is a project and maliciously forces them to do bad things when that happens. Similarly, if someone runs a script that somehow (we don't currently have a mechanism for this) indicates that it uses a project file, we're already running that script's code, we might as well trust it fully. So while having explicit instantiate commands is fine, we may want to just automatically install and use the right Julia version and similarly automatically instantiate and run the right package versions.

So the "vision" is that when using juliaup you would be able to just to julia --project and have it automatically install the right Julia version and the right package versions for you (maybe with some interactive prompting, but then again maybe not even that).

I think the operation where one manually specifies a channel and tells the system to update the project to that Julia version should be resolve, right?

Ah, yes, that would make more sense!

@StefanKarpinski auto-instantiate would be fantastic for scripts. Would you envision this as part of julia itself, or a juliaup-specific feature?

I think it would have to be a combination: juliaup would auto-install the necessary julia version while Julia itself would auto-install the package versions. Of course the end-user shouldn't have to care what is installing what as long as it all just works. I think we're always going to have two layers of installer, the key is to make a coherent experience for the user so they don't need to think too much about those two layers.

What I do today to get scripts to just work is to start with the stanza
using Pkg
Pkg.activate(@__DIR__)
Pkg.instantiate()

but this requires the right version of Julia, which I've typically enforced by mandating a docker image. Automatically getting the right version from juliaup instead of the docker image would be a huge improvement and getting rid of the stanza would be a nice bonus.
I'd also like to note that what's being discussed here may have some not entirely trivial interactions with version specific manifests if some solution for that gets implemented.

I thought a bit more about this, and I have another idea around this. At some level this would be quite a deviation from the current Juliaup philosophy, but I think there would be ways to phase that in gently, maybe even in a non-breaking way. Haven't really figured out how, though ;)
I'll use julialauncher in the description, but of course users would just type julia instead.
Imagine a world for a moment where we didn't have the concept of Juliaup channels, nor the concept of a default Juliaup channel or any of this. Instead, when one runs julialauncher without any extra info, julialauncher will look for a project named ~/.julia/environments/default/. For a moment let's assume that this always exists and worry how we bootstrap that later. julialauncher would then read the Julia version from the Manifest.toml from that file and launch that version of Julia with that default project activated, i.e. --project=~/.julia/environments/default/. So, in this design, instead of storing the default Julia version in a Juliaup config file, we store that info in the manifest of the default project.
If a user launches julialauncher with a project specified, i.e. julialauncher --project=SOMETHING then we read the Julia version from that manifest, and launch that version of Julia with that project activated.
In this world, juliaup update would no longer exist. Instead, the package manager would be in charge of updating Julia versions in manifest files. Instead of specifying a channel, we would use compat entries in the Project.toml for Julia itself.
So, specifically, when julialauncher looks at a project to active, it will also look at the julia item in [compat] in the Project.toml for that project, and if a newer version of Julia exists that matches, it would output a message "A new version of Julia exists, to update, run pkg> update." The package manger would have to be able to handle Julia itself, but from a user's point of view if one runs pkg> update then the package manager resolves not just package versions, but also the Julia version itself. If that leads to a change in the Julia version, the package manager ends with "Please restart Julia" or something like that.
Picking a specific Julia version now essentially becomes an exercise of either pinning Julia to a specific version with the package manager, or just generally editing the compat section of the Project.toml. Maybe the package manager could gain a compat command that would make it easier to modify the compat entry for something, so that I could for example say pkg> compat julia ~1.8 and that would be equivalent of using the 1.8 channel in the current Juliaup design. We could also have some custom compat values for Julia itself, for example pkg> compat julia lts could work.
Some other random thoughts:

this would probably all work better if the package manager could be invoked from a shell directly, i.e. if we say had a juliapkg or juliaproj command line tool.
I haven't thought how we would handle different platforms in this world, i.e. the choice between 32 and 64 bit versions or different libc implementations. These should obviously not be stored in the Manifest.toml. So we would need some solution for that.
I find the current julialauncher +CHANNEL syntax super convenient. It would be nice if that could somehow be combined with this idea of having the Manifest.toml be the "truth" about version selection... This is especially true because julialauncher --project=@something feels especially verbose... Maybe there is a way that one could use the + syntax for project selection, and maybe that could even be backwards compatible with how it works today... Not sure, though.

I see two main things that this design would do for us:

In generally I think it is not ideal that at the moment one can change the Julia version independently of updating a Manifest.toml. It seems to me that one by definition then will be in a state where things might not compatible. I think the core idea of this proposal is that any change to the Julia version should be done holistically by also looking at the packages in a project and making sure that everything resolves properly and then modifying a Manifest.toml. Essentially the only version selector for the Julia version would always be the version specified in some Manifest.toml.
As a side benefit, this would also supersede this proposal. I.e. we would automatically always have an active project, and we would get rid of the problem that users add all sorts of things to a project that is always active via the stacked environment stuff.

Alright, this is obviously not a fully fleshed out proposal, but I thought I'd throw it out here and see what others think :) CC @StefanKarpinski, @KristofferC, @staticfloat and obviously everyone else who wrote in this thread before.


Upgrade to celery 4

We don't use much of celery so the upgrade was simple

Codecov Report

Merging #267 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #267      +/-   ##
==========================================
+ Coverage   91.05%   91.05%   +<.01%
==========================================
  Files          46       46
  Lines        2739     2740       +1
==========================================
+ Hits         2494     2495       +1
  Misses        245      245

Impacted Files
Coverage Δ

lintreview/web.py
84.61% <100%> (+0.3%)
:arrow_up:

Continue to review full report at Codecov.

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


Accessory will still show up after deactivating LAN control

I added LAN control to a Halo ceiling lamp.
When switching it off, the accessory still appears in Home but is not functional.
It should not appear anymore.

issue related to cached accessories with home bridge


Insert & get floating point function cause errors in Keil / mbed compiler

STM32F401RE NUCLEO gets hardfault when getting floating point, as #1 mentioned.
I should figure out why.

I suspect it is because of floating point data address alignment problem.

fc2b05a Solved Problem.
See comment on commit above.


Get a OneDriveClient object sample code is outdated

The sample code under the Get a OneDriveClient object section has the following
final DefaultCallback<IOneDriveClient> callback = new DefaultCallback<IOneDriveClient>(activity) {...};
final IOneDriveClient oneDriveClient = new OneDriveClient.Builder()
                                            .fromConfig(oneDriveConfig)
                                            .loginAndBuildClient(getActivity(), callback);

The OneDriveClient.Builder.loginAndBuildClient function is now async, returning the IOneDriveClient in the given DefaultCallback. The sample code still expects a IOneDriveClient value returned from loginAndBuildClient however it's return type is now void.
A simple fix but confusing to first time readers.

I agree with  @ajpeacock0, the sample is outdated. I simply replaced DefaultCallback with ICallback:
ICallback<IOneDriveClient> callback = new ICallback<IOneDriveClient>() {
    @Override
    public void success(IOneDriveClient iOneDriveClient) {

    }

    @Override
    public void failure(ClientException ex) {

    }
};

new OneDriveClient.Builder()
        .fromConfig(oneDriveConfig)
        .loginAndBuildClient(activity, callback);

Thank you @hollaus lifesaver... thought I was going crazy - someone should really update the examples!

so what happen to the rest of sample ?  * get root folder
how to get oneDriveClient object to call it's method?
oneDriveClient
.getDrive()
.getRoot()
.buildRequest()
.get(new ICallback() {
@Override
public void success(final Item result) {
final String msg = "Found Root " + result.id;
Toast.makeText(getActivity(), msg, Toast.LENGTH_SHORT)
.show();
}
...
// Handle failure case
});

Thank you for reaching out and for your patience. This SDK is being officially deprecated. See #172 for more information


feat(connector-corda): read privateKey from filesystem

Allow plugin-ledger-connector-corda to read privateKey from filesystem
instead of obtain it directly from corda-aio container
Relationed with #789
Signed-off-by: Elena Izaguirre<EMAIL_ADDRESS>

@elenaizaguirre
Would something like this work (need to substitute the container ID variable)?
export CORDA_AIO_IMAGE_KEY=$(docker exec $CONTAINER_ID cat /etc/hyperledger/cactus/corda-aio-image.key)

then in the compose file you just use the environment variable as usual:
https://docs.docker.com/compose/environment-variables/#pass-environment-variables-to-containers
https://docs.docker.com/compose/environment-variables/#substitute-environment-variables-in-compose-files
And finally what I wanted to double check is the specific reason for using docker compose. Is it to simplify manual testing or are you somehow embedding the docker compose parts into a test case?

@elenaizaguirre
Would something like this work (need to substitute the container ID variable)?
export CORDA_AIO_IMAGE_KEY=$(docker exec $CONTAINER_ID cat /etc/hyperledger/cactus/corda-aio-image.key)

then in the compose file you just use the environment variable as usual:
https://docs.docker.com/compose/environment-variables/#pass-environment-variables-to-containers
https://docs.docker.com/compose/environment-variables/#substitute-environment-variables-in-compose-files
And finally what I wanted to double check is the specific reason for using docker compose. Is it to simplify manual testing or are you somehow embedding the docker compose parts into a test case?

@petermetz
I am using docker compose because I think it improves the user experience by deploying all containers with a single command, but I'm having a lot of problems because of it.
If you want to see what I am doing it is available in this branch.
Now I am not sure how to deal with this issue, I think there are three ways to do it:

Forget docker compose and do it with independent containers

Create the keys from the host and also send them to corda-aio as environment variables (we would have to modify the image so I don't think this is the best option).

Merge this PR, I now have the key located inside the second container so it would not be a problem. I used your command to export the key to a host file and then pass it as a secret to the second container (it is not possible to do it in this case with environment variables because they are evaluated before starting the first container).


Feature Request:Set different sort methods for different albums

For some albums, I want to sort them by the date they were added. For some albums, I want to sort by file name.
Provides the option to select a sorting method to apply to a single album

Duplicate:

#207


feat: Add support for arbitrary schema annotations.

The 'description' property is useful in that it permits a non-functional tag in the schema that could be used by external tools; there are other arbitrary use-cases where a similar pattern could be useful, for example:

Titles or names for an editor context
Marking fields as sensitive [e.g. PIII]
Tooltips or longer-form descriptions

To this end, add a new method annotate() that supports arbitrary key-value data in a schema.
Note: It would be possible (but potentially an interface change) to re-implement description ontop of this - I have not done that in this PR but can if desired.

@colinhacks wondering your thoughts?

Why not change the name of annotate to meta?

@colinhacks just checking if this makes sense? It's proven very useful to us [and I imagine could re-implement definition on top of it too]

Seems a like overkill that we're requiring the key to be a symbol, here, instead of just a string.

Seems a like overkill that we're requiring the key to be a symbol, here, instead of just a string.

Here's an example that supports this statement. There are multiple OpenAPI generating libraries. With the support for metadata OpenAPI implementors can agree on the key names and then users should be able to switch between implementations. With just symbols this will not be possible. Keep symbols though, people will still probably need them.
What also seems a bit off is that you need to call annotate multiple times if you have more than one annotation. Let's just accept the annotations object. This should reduce the schema copying a bit, but the copying is probably not necessary to begin with. Metadata doesn't change the actual schema, so it's not like you can break someone by mutating the annotations object.

@extradosages @IvanovES slow turn-around on my part, but agree completely - updated to support bulk assignment of objects (so permitting any object-key as a key)
Wondering if anyone else has comments? We're using this happily

I need this so badly!

@colinhacks any input?

I see this feature isn't master, and there are a number of people with different takes on it. FOr now I'm just monkey-patching along the lines of:
`import { z, ZodType } from 'zod';
import { ZodTypeDef } from 'zod/lib/types';
declare module 'zod' {
interface ZodType<
Output = any,
Def extends ZodTypeDef = ZodTypeDef,
Input = Output

{
annotate(symbol: string, value: any): this;
meta: { [key: string]: any };
}
}

// Extend ZodType's prototype
Object.defineProperty(ZodType.prototype, 'annotate', {
value: function (key: string, value: any) {
if (!this.meta) {
this.meta = {};
}
this.meta[key] = value;
return this;
},
writable: true
});
// Use
const annotatedString = z.string().annotate('someSpecialThing', true);
// Access meta
console.log(annotatedString.meta['someSpecialThing']); // true
`
Any chance of an official solution being rolled into zod?


Charges - (New datamodel, part 2) refactor repository (Store and Get) for charge create

Description:
Upon implementing the new data model in the sql database, we need to refactor:

StoreChargeAsync (used for storing 'Create' operations)
GetChargeAsync

So they work with the new data model.
Preconditions:

New datamodel implemented #201

Acceptance criteria:

AC#1 Valid 'create charge operations' for fee, subs, and tariffs are persisted in the database, including prices
AC#2 When you persist a create charge operation, the tables must be filled as shown in the below tables
AC#3 GetChargeAsync must use (Owner, ChargeId, ChargeType) when fetching a charge from the database with the new data model (Only the Charge table with the static values are in scope in this AC)
AC#4 Existing integration tests for storing charges (including prices) are refactored and pass
AC#5 Remove old (dbo) tables

Charge
1 new row in the table.

Column
Value

RowId
Autoincrement (db)

ChargeId
ChargeOperation.ChargeId

ChargeType
ChargeOperation.ChargeType

Owner
RowId field from the MarketParticipant table where ChargeOperation.ChargeOwner matches MarketParticipant.MarketParticipantId

TaxIndicator
ChargeOperation.TaxIndicator

Resolution
ChargeOperation.Resolution

Currency
A value representing DKK (cannot be changed in the danish market)

TransparentInvoicing
ChargeOperation.TransparentInvoicing

ChargeOperation
1 new row in the table.

Column
Value

RowId
Autoincrement (db)

ChargeRowId
RowId of the record in the Charges table representing the charge

CorrelationId
CorrelationId

ChargeOperationId
ChargeOperation.Id

WriteDateTime
IClock.Instance.GetCurrentInstant()

ChargePeriodDetails
1 new row in the table.

Column
Value

RowId
Autoincrement (db)

ChargeRowId
RowId of the record in the Charges table representing the charge

StartTimeDate
ChargeOperation.StartDateTime

EndDateTime
Null

Name
ChargeOperation.ChargeName

Description
ChargeOperation.ChargeDescription

VatClassification
ChargeOperation.VatClassification

Retired
false

RetiredDateTime
Null

ChargeOperationRowId
RowId of the record in the table ChargeOperation representing the current operation

ChargePrice
1 new row in the table for each Point in ChargeOperation.Points.

Column
Value

RowId
Autoincrement (db)

ChargeRowId
RowId of the record in the Charges table representing the charge

Time
Point.Time

Price
Point.Price

Retired
false

RetiredDateTime
Null

ChargeOperationRowId
RowId of the record in the table ChargeOperation representing the current operation

@prtandrup, I think it would be nice to have an integration test verifying (at least) one persisting - e.g. saving a fee with all required values (price etc). How about adding that as either an AC or another issue?

:+1: Extended with one more ac, see AC#4.

The issue has been tested on the T-environment.
Test result:
AC#1 Valid 'create charge operations' for fee, subs, and tariffs are persisted in the database, including prices - PASSED
AC#2 When you persist a create charge operation, the tables must be filled as shown in the below tables - TEST PENDING
AC#3 GetChargeAsync must use (Owner, ChargeId, ChargeType) when fetching a charge from the database with the new data model (Only the Charge table with the static values are in scope in this AC) - TEST PENDING
AC#4 Existing integration tests for storing charges (including prices) are refactored and pass - TEST  PENDING
AC#5 Remove old (dbo) tables - TEST PENDING
AC1:
Tariff:
A postman message creating a tariff was sent to the T-environment as shown below.

The tariff was saved to the database as shown below:

Including prices:

Subscription:
A postman message creating a subscription was sent to the T-environment as shown below:

The subscription was saved to the database as shown:

And prices are saved as well:

Fee:
A postman message creating a fee was sent to the T-environment as shown below:

The fee was saved to the database as shown:

And prices are saved:

Michael and I decided to strike out (including prices) in AC#4 - #323 has been created to do this work.


VueUI crashed after creating Vue Project

Version
4.5.15
Environment info
Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
<EMAIL_ADDRESS><EMAIL_ADDRESS>
Steps to reproduce
after create Vue Project
What is expected?
Vue UI not crashed
What is actually happening?
node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: ENOENT: no such file or directory, scandir '/Users/dextercai/project/xxxxxx/node_modules/@vue/cli-service/locales'
    at Object.readdirSync (node:fs:1390:3)
    at exports.readdir (/opt/homebrew/lib/node_modules/@vue/cli/node_modules/@mrmlnc/readdir-enhanced/lib/sync/fs.js:18:20)
    at Object.safeCall [as safe] (/opt/homebrew/lib/node_modules/@vue/cli/node_modules/@mrmlnc/readdir-enhanced/lib/call.js:24:8)
    at DirectoryReader.readNextDirectory (/opt/homebrew/lib/node_modules/@vue/cli/node_modules/@mrmlnc/readdir-enhanced/lib/directory-reader.js:78:10)
    at Readable.DirectoryReader.stream._read (/opt/homebrew/lib/node_modules/@vue/cli/node_modules/@mrmlnc/readdir-enhanced/lib/directory-reader.js:57:18)
    at Readable.read (node:internal/streams/readable:496:27)
    at readdirSync (/opt/homebrew/lib/node_modules/@vue/cli/node_modules/@mrmlnc/readdir-enhanced/lib/sync/index.js:27:21)
    at Function.readdirSyncStat (/opt/homebrew/lib/node_modules/@vue/cli/node_modules/@mrmlnc/readdir-enhanced/lib/index.js:34:10)
    at ReaderSync.dynamicApi (/opt/homebrew/lib/node_modules/@vue/cli/node_modules/fast-glob/out/providers/reader-sync.js:64:24)
    at ReaderSync.api (/opt/homebrew/lib/node_modules/@vue/cli/node_modules/fast-glob/out/providers/reader-sync.js:56:25)
Emitted 'error' event on Readable instance at:
    at emitErrorNT (node:internal/streams/destroy:164:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -2,
  syscall: 'scandir',
  code: 'ENOENT',
  path: '/Users/dextercai/project/xxxxxx/node_modules/@vue/cli-service/locales'
}

I had the same problem. I rolled node back to 16.13.1 (LTS) and that seemed to solve it 🤷♂

Thank @thejaylee that helped me as well.
Given that vue-cli is only in maintenance mode now, is there an alternative like vue ui for vite?


chore: add pattern to dependabot

Referer: https://github.blog/2023-08-24-a-faster-way-to-manage-version-updates-with-dependabot

Thanks!


ARTEMIS-2765 Fix parsing error in XMLUtil

Fix a StringIndexOutOfBoundsException in XMLUtil while parsing system
properties in XML that contains curly braces or unterminated property
references

Nice work. Thanks for the commit!