[ml] Enable strict sphinx check

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

@kristapratico The only remaining issues we're seeing for azure-ai-ml strict_sphinx compliance is a "duplicate object description" warning. It seems the root of this is having an object exported in multiple module namespaces (i.e. __init__.py files); however, removing an object from an __init__.py file would be a breaking change.

The error messages suggest using :no_index: in the docstring, but I haven't found a way to make that work and I don't see any examples in the azure-sdk-for-python repository of other packages using it. What's your recommendation for dealing with this error?

@kristapratico The only remaining issues we're seeing for azure-ai-ml strict_sphinx compliance is a "duplicate object description" warning. It seems the root of this is having an object exported in multiple module namespaces (i.e. __init__.py files); however, removing an object from an __init__.py file would be a breaking change.

The error messages suggest using :no_index: in the docstring, but I haven't found a way to make that work and I don't see any examples in the azure-sdk-for-python repository of other packages using it. What's your recommendation for dealing with this error?

@diondrapeck we should not have the same object exported in multiple module namespaces. We need to figure out for each type whether it should be imported at the parent or child namespace, and then we can use some init-level getattr magic to remove the type from dunder all (see here for an example) and include a deprecation warning to say that the specific type being imported will eventually be removed.
cc @annatisch

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-ml

@kristapratico The only remaining issues we're seeing for azure-ai-ml strict_sphinx compliance is a "duplicate object description" warning. It seems the root of this is having an object exported in multiple module namespaces (i.e. __init__.py files); however, removing an object from an __init__.py file would be a breaking change.

The error messages suggest using :no_index: in the docstring, but I haven't found a way to make that work and I don't see any examples in the azure-sdk-for-python repository of other packages using it. What's your recommendation for dealing with this error?

@diondrapeck we should not have the same object exported in multiple module namespaces. We need to figure out for each type whether it should be imported at the parent or child namespace, and then we can use some init-level getattr magic to remove the type from dunder all (see here for an example) and include a deprecation warning to say that the specific type being imported will eventually be removed.
cc @annatisch

Done! Thank you.


Implement a batched change size/iterator

As is discussed in https://github.com/octodns/octodns-googlecloud/issues/3, the googlecloud provider batches changes and there's a max batch size of 1000 (it's more complicated than that, but 1k is the simplest limit.) This PR reworks the _apply function to group changes into batches of at most 1000 to avoid that limit.
/cc https://github.com/octodns/octodns-googlecloud/pull/8 @mxdlx

I'm pretty sure I'm doing something wrong. I created my env and installed the provider with:
pip install git+https://github.com/octodns/octodns-googlecloud.git@batched-changes

But I'm still getting a 403 so I think I'm not doing the installation right.

Give this a try:
pip install -e git+https://git@github.com/octodns/octodns-googlecloud.git@batched-changes#egg=octodns

Ok, for completeness, first I got an error:
$ pip install -e git+https://git@github.com/octodns/octodns-googlecloud.git@batched-changes#egg=octodns
Obtaining octodns from git+https://****@github.com/octodns/octodns-googlecloud.git@batched-changes#egg=octodns
  Updating /Users/alvaro/Git/dstillery/cloudops-octodns/env/src/octodns clone (to revision batched-changes)
  Running command git fetch -q --tags
  Running command git reset --hard -q 8c3dd35757688b15627c738bba2bbc89feb7351b
  Preparing metadata (setup.py) ... done
  WARNING: Generating metadata for package octodns produced metadata for project name octodns-googlecloud. Fix your #egg=octodns fragments.
Discarding git+https://****@github.com/octodns/octodns-googlecloud.git@batched-changes#egg=octodns: Requested octodns-googlecloud from git+https://****@github.com/octodns/octodns-googlecloud.git@batched-changes#egg=octodns has inconsistent name: filename has 'octodns', but metadata has 'octodns-googlecloud'
ERROR: Could not find a version that satisfies the requirement octodns (unavailable) (from versions: 0.8.0, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.8.8, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 0.9.6, 0.9.8, 0.9.9, 0.9.10, 0.9.11, 0.9.12, 0.9.13, 0.9.14, 0.9.15, 0.9.16)
ERROR: No matching distribution found for octodns (unavailable)

So changed that to:
$ pip install -e git+https://git@github.com/octodns/octodns-googlecloud.git@batched-changes#egg=octodns-googlecloud

And it worked.
Now, back to sync:
2022-03-28T16:58:53  [4516802048] INFO  GoogleCloudProvider[google_cloud] apply: making 2401 changes to 70.10.in-addr.arpa.
Traceback (most recent call last):
  File "/Users/alvaro/Git/dstillery/cloudops-octodns/env/bin/octodns-sync", line 8, in <module>
    sys.exit(main())
  File "/Users/alvaro/Git/dstillery/cloudops-octodns/env/lib/python3.9/site-packages/octodns/cmds/sync.py", line 38, in main
    manager.sync(eligible_zones=args.zone, eligible_sources=args.source,
  File "/Users/alvaro/Git/dstillery/cloudops-octodns/env/lib/python3.9/site-packages/octodns/manager.py", line 468, in sync
    total_changes += target.apply(plan)
  File "/Users/alvaro/Git/dstillery/cloudops-octodns/env/lib/python3.9/site-packages/octodns/provider/base.py", line 181, in apply
    self._apply(plan)
  File "/Users/alvaro/Git/dstillery/cloudops-octodns/env/src/octodns-googlecloud/octodns_googlecloud/__init__.py", line 97, in _apply
    gcloud_changes.create()
  File "/Users/alvaro/Git/dstillery/cloudops-octodns/env/lib/python3.9/site-packages/google/cloud/dns/changes.py", line 233, in create
    api_response = client._connection.api_request(
  File "/Users/alvaro/Git/dstillery/cloudops-octodns/env/lib/python3.9/site-packages/google/cloud/_http/__init__.py", line 480, in api_request
    raise exceptions.from_http_response(response)
google.api_core.exceptions.Forbidden: 403 POST https://dns.googleapis.com/dns/v1/projects/dst-shared-interconnect-hub/managedZones/zone-70-10-in-addr-arpa--9a1cfcc37c5b40ccbee4bc564216aad1/changes?prettyPrint=false: The change would exceed quota for additions per change.

https://github.com/octodns/octodns-googlecloud/pull/9/commits/d1c565236743e6143427b89f0db604ca6b3483a7 should get it using batch correctly.

All good now:
2022-03-28T17:18:49  [4466003456] INFO  GoogleCloudProvider[google_cloud] apply: making 2401 changes to 70.10.in-addr.arpa.
2022-03-28T17:19:06  [4466003456] INFO  GoogleCloudProvider[google_cloud] apply: making 2911 changes to 71.10.in-addr.arpa.
2022-03-28T17:19:11  [4466003456] INFO  GoogleCloudProvider[google_cloud] Created zone zone-71-10-in-addr-arpa--b6354e907fd94b9ea418d6f1a5a4d387. Fqdn 71.10.in-addr.arpa..
2022-03-28T17:19:35  [4466003456] INFO  GoogleCloudProvider[google_cloud] apply: making 29 changes to [REDACTED].
2022-03-28T17:19:41  [4466003456] INFO  Manager sync:   5341 total changes

Thank you for your help with this one!

I don't currently have access to a google cloud setup, but this change seems sensible/straightforward and I'll go off of @mxdlx's real-world testing, 🤞


[FIREBREAK] Update the ssh command for 'ssh_bosh'

What
Before, we were ssh'ing directly to the bosh ip, which is difficult to set up ssh_config for.
This way, we ssh to `paas_bosh_ssh', but set the hostname to the IP we are ssh'ing to.
~/.ssh/config can then be set up for this fake hostname.
Host paas_bosh_ssh
	User xxxx
	IdentityFile %d/.ssh/xyz.pub

Specifying the user for the SSH to ${USER} is unnecessary, as this is the default behaviour of SSH, and makes it impossible to override with ssh_config. Also, as $USER is not immutable, it's not a security improvement.
This is an improvement which allows for cases where there are a large number of ssh keys in the agent ie. if using 1Password's agent.
In this case, if the needed key is too far down the list, the attempts with invalid keys leads to an authfail before the correct one is tried.
How to review

Run gds aws $role -- make ssh_bosh DEPLOY_ENV=$env before and after checking out this branch, and ensure there are no changes.
Update your ssh config, as-in my example, and then run the make command again. You should see an error, as the username / key are incorrect.
Remove the ssh config again, and note that SSH'ing works again.

Who can review
Not me

🚨⚠ Please do not merge this pull request via the GitHub UI ⚠🚨

I'd be interested in talking about this at a knowledge share session.  I think I like the flexibility it would allow, but I'm not yet sure what problems it would introduce for engineers; especially new engineers being onboarded.

I'd be interested in talking about this at a knowledge share session. I think I like the flexibility it would allow, but I'm not yet sure what problems it would introduce for engineers; especially new engineers being onboarded.

Sure, makes perfect sense.
In essence, though, there would be 0 change to how it works (ssh already uses $USER by default, and it doesn't matter what the 'target' is (ie. ssh target) if -o Hostname=some_ip is set). In theory, you can check this out and test it - it will Just Work™, with no external changes required.
Context: without this change, I can't run this make target, without running two ssh agents.


CUDA out of memory

Hi, i implement Packed Padded Sequences, Masking and interface, but I got some problem with cuda out of memory. My own dataset has about 50000 sentences and I already lower batch size to 1, but I still got RuntimeError with out of memory. Would you provide some solutions for me, thanks

Here is my model setting

GPU : GeFprce GTX 1080 Ti 11G

It is a fairly large model, try to restrict vocabulary to some reasonable size. Alternatively, you can experiment with reducing size of either embedding layers or hidden layers of your encoder/decoder.

I'll basically echo what @xelibrion has said.
I have the same GPU as you (1080 Ti) and it's at 50% capacity with only 20mil parameters (vocab size of ~9k). You'll have to either reduce the amount of parameters in your model as @xelibrion has suggested or try on another GPU with larger capacity.


npm

hey, thank you because of this project. Its awesone... I was wondering why this is not in npm?

Hi, thanks for your interest in the project.
When I did this project, I did not even think that it could be useful to someone. Let's be honest, the project has a terrible documentation and most likely it could be written better.
Now the project has some security bugs (as github says) and I'm busy at work, so at the moment I can't publish it in npm. But I will think about supporting the project, since he has become needed.

Hi! Your project has helped me a lot. Thank you very much!
A few days ago I published the project on npm... I created a repository to which I am adding the documentation.

npm: https://www.npmjs.com/package/@krthr/vue-dataflow-editor
Github: https://github.com/krthr/vue-dataflow-editor
docs: https://krthr.github.io/vue-dataflow-editor/ (under construction)

Thanksssss you guys~！you do me a bigggggg favor，thanks~~

I want to inform why this "library" is not in the npm repository from me.
This code is far from the library code(I have high standards), since it is not easy to change the style of blocks or behavior, it's just a sketch.
I think the best thing for your projects is to copy the code from the "components" and "helpers" folders to your project and modify them as you wish.
Thank you for being interested in this project.

Hi!
If you want, I could give you the permission to publish the package. Or move all the authority over the npm package

@krthr thank you, I think this is not yet required, for the reasons described above.


TFX on Taxi_pipelines_interactive

model_resolver = ResolverNode(
instance_name='latest_blessed_model_resolver',
resolver_class=latest_blessed_model_resolver.LatestBlessedModelResolver,
model=Channel(type=Model),
model_blessing=Channel(type=ModelBlessing))
context.run(model_resolver)
evaluator = Evaluator(
examples=example_gen.outputs['examples'],
model=trainer.outputs['model'],
#baseline_model=model_resolver.outputs['model'],
# Change threshold will be ignored if there is no baseline (first run).
eval_config=eval_config)
context.run(evaluator)
INFO:absl:Running driver for ResolverNode.latest_blessed_model_resolver
INFO:absl:MetadataStore with DB connection initialized
WARNING:absl:Artifact type ModelBlessing not registered
INFO:absl:Running publisher for ResolverNode.latest_blessed_model_resolver
INFO:absl:MetadataStore with DB connection initialized
INFO:absl:Running driver for Evaluator
INFO:absl:MetadataStore with DB connection initialized
INFO:absl:Running executor for Evaluator
UnboundLocalError                         Traceback (most recent call last)
 in
19     # Change threshold will be ignored if there is no baseline (first run).
20     eval_config=eval_config)
---> 21 context.run(evaluator)
~/taxi_pipeline/lib/python3.6/site-packages/tfx/orchestration/experimental/interactive/interactive_context.py in run_if_ipython(*args, **kwargs)
64       # IPYTHON variable is set by IPython, see
65       # https://ipython.org/ipython-doc/rel-0.10.2/html/interactive/reference.html#embedding-ipython.
---> 66       return fn(*args, **kwargs)
67     else:
68       absl.logging.warning(
~/taxi_pipeline/lib/python3.6/site-packages/tfx/orchestration/experimental/interactive/interactive_context.py in run(self, component, enable_cache, beam_pipeline_args)
166         component, pipeline_info, driver_args, metadata_connection,
167         beam_pipeline_args, additional_pipeline_args)
--> 168     execution_id = launcher.launch().execution_id
169
170     return execution_result.ExecutionResult(
~/taxi_pipeline/lib/python3.6/site-packages/tfx/orchestration/launcher/base_component_launcher.py in launch(self)
203                          execution_decision.input_dict,
204                          execution_decision.output_dict,
--> 205                          execution_decision.exec_properties)
206
207     absl.logging.info('Running publisher for %s',
~/taxi_pipeline/lib/python3.6/site-packages/tfx/orchestration/launcher/in_process_component_launcher.py in _run_executor(self, execution_id, input_dict, output_dict, exec_properties)
65         executor_context)  # type: ignore
66
---> 67     executor.Do(input_dict, output_dict, exec_properties)
~/taxi_pipeline/lib/python3.6/site-packages/tfx/components/evaluator/executor.py in Do(self, input_dict, output_dict, exec_properties)
161         else:
162           models[model_spec.name] = _get_eval_saved_model(
--> 163               input_dict[MODEL_KEY], tags)
164           absl.logging.info('Using {} for model eval.'.format(
165               models[model_spec.name].model_path))
UnboundLocalError: local variable 'tags' referenced before assignment

@pradeepmishra11,
Since this issue is related to TFX, could you please raise an issue in the TFX repo using this link. Thanks!

Any updates regarding this issue? Thanks!

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!


Remove nameOverride from config

Remove nameOverride from helm chart. The reason lies in the implementation of operator:

The fullname of the alluxio cluster depends on the nameOverride, according helm chart logic.
The name of a load job will include the fullname of the alluxio cluster, so that the user would be able to know which data the job is loading.
The load crd, which provides the parameters to launch underlying load job, only has the name of the alluxio cluster as a parameter. So to construct the underlying load job name, we grab the alluxio cluster, find nameOverride, and then construct the fullname.
When we destroy the underlying load job, the request doesn't contain the name of the alluxio cluster anymore, and thus there's no way for us to find the name of the underlying load job.
Therefore, by removing nameOverride, the name of the underlying load job doesn't depend on the nameOverride anymore, and thus we are able to find and delete the underlying load job.
nameOverride should not be modified in usual case anyways.

@Kai-Zhang PTAL. Thanks!

Nvm the fullname still depends on the name of the alluxio cluster. The only solution is to make the load job name doesn't contain the alluxio cluster name.


fix(class): Fix error for query strings without an equals sign

This fixes a crash if someone would pass &test instead of &test=blah as a query.

Failed! Wrong branch...


Migrate to gtnhlib config

Config changes like this are trivial, and the config file has only a single config. It's harmless for the stable.

other GTNH-I PRs will have to wait tho

Config changes like this are trivial, and the config file has only a single config. It's harmless for the stable.

config changes like this have broken a lot over the last year. this one is very small indeed though I guess.


Cheat the farm：On April 3rd, 10 hotspots on line, witness each other, a total of more than 40 hot spots, this is only a part of the same manufacturer, the same 1.2 dbi, same antenna height, please add to the reject list,

Hotspot b58 Addresses
Wallet Address：13qfcCkuRq8JNd4TDtzzPicuijMo3YzGQ789a78CbwGzPt6erAx
Hotspot Address：
112tJ2gprgEXXFpWrJCgygKFbQFTnL571tMuST2V4h8P6vH3gnsS
118ZWqzic97a33Fje9W6v83QwkkQiAcRbt7VyK74MKTr3ZKkcSG
112NzmVJYiSaX8sMXJBETPQ8HSn6aaVEqrupU4chihMu7iSvMY9R
112kTH4idcD2T7oi8pvdLsiByqV4eMJSaReYJhfjwmM87hAknJhH
112u7W6EAFZsePziWpFGGSiGJpFPJWaThjNv7LA58NHRzvcbM2TP
11297JDWU5xKVzjzK5VYWMvMGF6tVJmMV1XWpwadVA4fs5Yhe2dH
11hhoYMkcJe8LFcpDdCYspJaARwU2u1WhJegbACz7MxNqRcANKr
11MRh4maaBjovdV3xFVmrPNLQSmFx6KD6yMSDhLBzXJksTpjAwm
112hR1JUDuCNftcsbiXgR1jYSNYCvqmweexTyXBGJmitKmYsqoqt
112iRZ9HHnP2x392Mqh7DEneqzAVLWhAQtFFJMrDz6QVjYWDU5pu
Discord Handle
No response
Reason(s)

From the same cluster hotspot：
11qRraCq1Z4kqReCqNXs1RJyQTAT1h4C11yLuvYRJxZkQVeTyQ
11n1Tr8BKDE7BPebh61VXa4zbddKGmB2roKjEL2g2aSi9yfiM19
112WckGK2YwFMVdh6EgLaLH2VQzTkASfNvapNYbKNwBppCGiQ14o
11rx3W3p4zMcYGoHqNuh9JrvmpEw3E52bpcWQVBHq1EUmPcL4Ua
11UFNQsBwUT1gwmfnAqP4QE6uKwCjFDN2Zeu3MsMxUtLocNoZtE
11NaKLfTmEQJyve2evUddLeZCQ7LRTNqFgEC7NWMZyrBMLwYPQc
112KHXMNhuJH8jQuLxoCqBWN41JGaEJPmJgLtrB7MTfsFd5B5KGD
112D1qMmegj1ThbiTpzVfMy9xvGXxXGj6BBEArhxz2Berxh9uYR9
112AHFyd3wvfQa32JyRqcjaeDu7fpgs173X58bPHwVejCyCmWMMH
112SXE3Nucpa2z9G87nEoVHFWouJYkHhxYGDyJNwM7i7JYt3YREF
11q4tjrGqLRV7tPwsbrhcBJs7Lqr4AQacYYsEZUtMHEFiJ8PNcu
11YQFiEUJvs79YQGdyqV1gTbmVD2KPT8xHKubGi6Lm9bMvbP6dB
112mLx2uqrCDuwuD38YM1hSaYV7jcnumHAjUwL7oZKNP2GgcH43Q
112fZuTTkorVd6zE19B5nKSph5PoDgdfrhVBTVsppNqu4tUdsrUJ
112aa2cJHjTAbZ9b3u4K6DgV85vM6AJtXo3R7TDKaWCA6sB8wAZu
I hope we can get it done. Thank you.There are 45, and I've only listed a few, all from the same manufacturer, only there are witnesses to each other, the same height, I believe that helium can find other hot spots from that same cluster.

These cluster hotspots are all from Italy Isola di Capo Rizzuto， I don't know when the helium will shut down these cheats, but it will take some time, hopefully soon.

这段视频是从哪里来的？知道为什么有人会拍自己这么做吗？

See on Twitter, show off can earn a lot of reward, I went to see, witness each other, all from the same cluster

Why hasn't helium responded to these hot spots? Such obvious cheating.

Restless Myrtle Pheasant

Muscular White Cod


Change horizontal alignment so that 2 is centered and 3 is right, in

accord with the documentation.
Note that this is an incompatible change that will break current projects.

I'd not sure we should do this, since it will break existing projects (but seems more logical and also compatible with the docs).   Suggestions?

Is it possible to write an upgrader? Otherwise I'd be weary to do so.

@josmas What do you think the upgrader should do?  I don't see how to do one in general.

Is this affecting the numbers used in Blocks when setting alignment in arrangements? I'd say it would not only be blocks, but also property values in scm files, right?
If that's so, the upgrader should take all arrangements and swap 2s and 3s?

We can do the swap if the block has a literal 2 or 3, but not if it's a computed value.
Is that second case rare enough that we can go ahead and break things?   Another approach is to mark the block an add a message to the user warning them to fix it.   We did that sort of thing in Google App Inventor when we switch trig function default from radians to degrees.

What do you mean by a computed value in this context? If the value is not either 2 or 3, it should not change.

I mean if  the value is set to an expression, or the value of a variable.
== Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
On Sun, Feb 14, 2016 at 4:40 PM, Jos<EMAIL_ADDRESS>wrote:

What do you mean by a computed value in this context? If the value is not
either 2 or 3, it should not change.
—
Reply to this email directly or view it on GitHub
https://github.com/mit-cml/appinventor-sources/pull/704#issuecomment-183983202
.

Right, that makes sense now.I'd say that would be rare enough, though.

I'll work on it.

Subsumed by #711
Closing


engine: exclude empty requests in requests list

This is to mirror a change in EIP-7685, where we exclude requests with empty request_data from the commitment.

This is to mirror a change in EIP-7685, where we exclude requests with empty request_data from the commitment.

Why?

@tersec Motivation is here: ethereum/EIPs#8989
The reason is that if requests are empty, then it will not matter on a chain which has 7685 activated whatever requests are activated. Previously, the activated request EIPs would change the "empty hash" (if there are no requests) which would depend upon what EIPs were activated.

I'll clarify: what is the motivation for the engine API to mirror this? It's a change in how the hash is calculated, but that's separate from the engine API.

I'll clarify: what is the motivation for the engine API to mirror this?

We need this to make the list relayed on the engine API the same list as is used for the commitment. I think it's important to keep these two the same.

We need this to make the list relayed on the engine API the same list as is used for the commitment. I think it's important to keep these two the same.

As far as I can see there is no "technical" reason to do so and they could be different. However, I think this change has two advantages:

Remove the need to rely on the element index to identify the type of requests: this is even more important for the future, as we add/remove request types.
Reduces the "cognitive load" of thinking about requests. CL sends requests back to EL exactly as they were received. If we don't include empty lists, then EL does not have to remove them before calculating the hash, etc.

To @tersec point, it is not NEEDED but I think it is a nice addition. And the implementation cost on CL side is minimal.

1. Remove the need to rely on the element index to identify the type of requests: this is even more important for the future, as we add/remove request types.

Engine API V3, V4, etc operates within that fork anyway. So if in that fork there's a subset of admissible request types, only those would be part of the interface, both for getPayload and newPayload. The accommodates adding and removing request types.

2. Reduces the "cognitive load" of thinking about requests. CL sends requests back to EL exactly as they were received. If we don't include empty lists, then EL does not have to remove them before calculating the hash, etc.

The CL sending back requests exactly as received is already the case. The EL hash literally adds
-    for r in requests:
-        m.update(sha256(r))
+    for r in block_requests:
+        if len(r) > 1:

That's not particularly different whether the block_requests come in singles or the 3 (currently) lists. So already the EL is doing this "remove them before calculating the hash", right now in the current set of proposals.

if an execution request type is provided but the remaining bytes for the list not provided or is shorter than 1 request I guess we should error and not accept

I agree with @tersec on not having a req on dropping empty requests by CL as EL will be doing this job anyway (during commitment computation) and passing a few bytes over Engine API is free, but if the majority of devs agree that empty requests should be dropped I am fine with that.
What I also think is weird is to have a req on the ordering:

In case of getPayload, the ordering req turns into a redundant verification on CL side
In case of newPayload, EL will have to do the same verification; what if EL do the ordering instead of verifying the order?

We can easily do these two things in the Engine API and I admit that these constraints are unlikely to bite us in the future, but they seem to be unnecessary. So not strongly against but feel weird when see us introducing something that isn't necessary

We don't specifically order the requests before submitting them into the hash.

I see. This sounds a bit odd to me, the order is a part of the commitment computations and the computing function relies on it to be externally set which leaks that responsibility to the caller for no reason IMHO. afaics, sorting will be trivial in terms of computations in this case, so what will be the gain of not sorting requests by type in this case?

I find it a bit pointless to order the requests, since we specifically collect them in the correct order.
In Geth, and I assume in other EL implementations as well, after processing the block, we perform three calls:

collect deposit events into deposit-requests (type 0x00)
call the withdrawals contract and store the output as withdrawal-requests (type 0x01)
call the consolidations contract and store the output as consolidations-contract (type 0x02)

At each step, we add the corresponding element into the list of block requests. At the very end of the block, we compute the commitment over the list. If there will ever be a fork where we change how type 0x00, 0x01 or 0x02 requests are gathered, we may have to introduce explicit sorting into the logic. But as of now, and for the foreseeable future, there is no need for sorting since the requests collection will always happen in order of request type.
W.r.t. the engine API, on the CL side, the implementation likely traverses the block structure in type order as well. There is no good reason to collect them in another order. So the CL will also come up with the requests in the correct ordering without ever having to sort it explicitly.
We do want to ensure there are no bugs though, and that's the point of the validation. The CL is supposed to validate the ordering, and so is the EL when it gets the requests in newPayload. For the Geth, the 'validation' will be that there is a mismatch with the block requestsHash if the CL submits requests in the wrong order.

About empty requests:
For a given block, if a request type has no data, it does not count towards the block requestsHash. The presence of empty requests is not observable in the consensus block either. An SSZ empty list is just empty data, it doesn't make a difference whether you explicitly store empty requests or just leave it empty.
This means, whether we transmit empty requests over the engine API or not does not lead to any observable difference in the block. I am proposing to not transmit them on the engine API because it simplifies the EL implementation: we can drop empty requests very early during processing, and no other part of the code ever has to worry about them again.

Ultimately I just want the spec to allow leaving out empty requests on the engine API, since it's more convenient for our implementation. If it is more convenient for the CLs to send them, we can still allow sending them. As explained, it doesn't make any difference.
I also suspect that, as request types become disused over time, it'd be weird if we had to keep sending them just to satisfy the API. But that's a weaker reason and doesn't apply today.


Async Storage has been extracted from react-native core and will be removed in a future release.

Warning: Async Storage has been extracted from react-native core and will be removed in a future release It can now be installed and imported from '@react-native-async-storage/async-storage' instead of 'react-native'. See https://github.com/react-native-async-storage/async-storage

Thanks. Yeah...i have to find some cycles to clean this up, apply the myriad of changes that others have done to keep this working and move forward.

hello, here is a patch for async storage, if you use version 7 you have to install async storage from pouchdb-react-native and install it separately.
diff --git a/node_modules/pouchdb-adapter-asyncstorage/src/asyncstorage_core.js b/node_modules/pouchdb-adapter-asyncstorage/src/asyncstorage_core.js
index a4c817e..ca18eb3 100644
--- a/node_modules/pouchdb-adapter-asyncstorage/src/asyncstorage_core.js
+++ b/node_modules/pouchdb-adapter-asyncstorage/src/asyncstorage_core.js
@@ -4,7 +4,7 @@
  * Adapted from https://github.com/tradle/asyncstorage-down
  */

-import { AsyncStorage } from 'react-native'
+import AsyncStorage from '@react-native-async-storage/async-storage'
 import {
   safeJsonParse,
   safeJsonStringify
@@ -109,4 +109,4 @@ AsyncStorageCore.destroy = function (dbName, callback) {
   })
 }

-module.exports = AsyncStorageCore
+export default AsyncStorageCore

for version 7 run
rm -r ./node_modules/pouchdb-react-native/node_modules/pouchdb-adapter-asyncstorage/
npm install --save pouchdb-adapter-asyncstorage

I will take a look at this soon.  Thanks!

@seigel I've made a PR https://github.com/seigel/pouchdb-react-native/pull/154

Hello! Checking in because I have just stumbled on this error myself. Is there an update?


ROX-19849: Add scanner pod restart pattern for slow db init

Description
Adds restarted due to slow postgres startup, for pod restart CI check.
CI pod restart fails on some s390x ci runs, with scanner pod error
{"Attempt":18,"Event":"Retrying connection to DB","Level":"warning","Location":"database.go:83","Time":"2023-11-16 20:07:20.305061"}

CI run is passing otherwise
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

Testing Performed
Relying on CI
Here I tell how I validated my change
Relying on CI

/test help

/test ibmcloudz-4-14-qa-e2e-tests

/retest-required

/retest


Improve handling of composite glyph deltas

This better matches the behaviour of fontmake:

we mark (0, 0) all deltas as being optional
we ensure we always write at least one delta for a composite glyph, per https://github.com/fonttools/fonttools/issues/1381

With this patch our gvar diff is down to about 300 lines, the majority of which looks to be something causing the two methods that are computing interpolatable points producing slightly different results in some cases; will investigate that next.
closes #398

added a couple tests, which motivated factoring out the code that processes the composite deltas (which is cleaner anyway, so win-win)

This also fixes https://github.com/googlefonts/fontc/issues/422
no more gvar diffs when building Oswald with fontc vs fontmake! 🥳


Bug: CI failure

Description of the bug
https://app.circleci.com/pipelines/github/help-me-mom/ng-mocks/7734/workflows/3cd7b253-c4f0-43ad-bbef-e9422509bff1/jobs/330302

v14.2.1 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


Simplify restore logic.

With the previous work to make some start-up functions idempotent, we can
simplify the logic used to restore the  AppController state.


HDDS-11249. Bump ozone-runner to 20240729-jdk17-1

What changes were proposed in this pull request?
Bump ozone-runner to latest 20240729-jdk17-1, which reduces image size.
https://issues.apache.org/jira/browse/HDDS-11249
How was this patch tested?
CI:
https://github.com/adoroszlai/ozone/actions/runs/10146353761

@smengcl can you please take a look?

@smengcl can you please take a look?

Sure! lgtm

Thanks @smengcl for the review.


Too much empty space below banner after edit

Obsidian: v1.4.16
Banners: 1.3.3
Reproduce: To ensure I didn't have any conflicting plugins/css, I can reproduce this on a new vault.
Issue: Banners add too much white-space padding below the banner after editing any page. Disable/Enable plugin will remove the spacing. Not able to use banners in the meanwhile.
Notice how the "hello" shifts down. Issue persists at all times after first appearance.
Before edit:

During edit:

After edit:

Hey, I have the same issue.
Mac OS 14.1,
iOS 16.
Tony

Looks like the obsidian-banner-wrapper element needs to be at the top of the markdown preview, but a markdown-preview-pusher element gets added even before that.

As a workaround, I added a CSS snippet to the Appearance Settings:
.obsidian-banner-wrapper {
    margin-top: calc(var(--banner-height) - 200px);
    padding-top: 0.5em;
}

It works fine on Mac OS but doesn't make any difference on iOS.

Not sure why it took me so long, but, adding !important to the snippet got the work around sorted for iOS:
.obsidian-banner-wrapper {
    margin-top: calc(var(--banner-height) - 200px) !important;
    padding-top: 0.5em;
}

Of course, this is only a workaround, and you'll need to adjust for the height you have your banner set.

I've written the following CSS snippet workaround
.obsidian-banner-wrapper {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: var(--banner-height);
    margin-top: 0;
    padding-top: 0;
}

.obsidian-banner{
    position: relative;
}

.markdown-preview-view:has(.obsidian-banner-wrapper) {
    padding-top: calc(var(--banner-height) + var(--file-margins));
}

[!warning]
This fix does not work in preview embedded.
Disable the Show banner in preview embed option in the Banner plugin settings

My simple fix (it works best for me in preview and in embed)
.obsidian-banner-wrapper {
  margin-top: 0;
}


select_zero for SparseVector

Hello there,
First thanks for the very nice library!
I see in the README on Planned Functionality:

select_zero() for SparseVector?

and in the docs:

/// For dense bitvectors or when [SelectZero] is needed, [BitVector] is a better choice.

Our usecase is the following: we have big bitvectors (7bn+ bits) and some of them are very dense (think 99+%). We already use SparseVector when they are sparse and we currently use https://github.com/ajalab/fid when they are not. It works ok but FID is 10-30x slower to build than simple-sds bitvectors. One solution would be to use an inverted sparse vector but we would need to be able to select the real 1s on it. Does it make sense? I could use a normal BitVector but it would end up being much bigger than a SparseVector.

Elias–Fano encoding does not store enough information to support indexed access to the missing values efficiently. The SDSL equivalent of select_zero() is basically binary search with select() to find the right run of 0s and the total number of 0s before that run. You can optimize it a bit by precomputing the results for the first few levels of binary search. And once the range is narrow enough, using select_iter() instead of select() and continuing with a sequential scan will be faster.
I'll probably implement this eventually, but determining good parameters for the optimizations will take some time.

Amazing, thanks!


fix(cli): minore CLI adjustments

What is it?

[x] Feature / enhancement
[x] Bug
[ ] Docs / tests

Description
Some styling changes and improvements on the create CLI 🎉
Checklist:

[x] My code follows the developer guidelines of this project
[x] I have performed a self-review of my own code
[x] I have made corresponding changes to the documentation
[ ] Added new tests to cover the fix / functionality

Rocking it!

merge?


[azservicebus] Return nil in adminClient functions for non-existent entities

Making it so our adminClient returns a nil result when the underlying entity is not found.
This avoids having to fabricate a fake status code (and possibly inconsistent HTTP response), which was the worse alternative.


Blazor Call method

Hello,
before preview 7 I used to call my methods as this:
<button class="btn btn-default btn-ok" onclick="@ShowCloseTicket">Clôturer le ticket</button>

But now I have an error message in Visual Studio:
Cannot convert method group to non delagte type. Did you inted to invoke the method ?
Yes I do.
So I Changed to
<button class="btn btn-default btn-ok" onclick="@ShowCloseTicket()">Clôturer le ticket</button>

But I still get an error message:
Cannot implicitly convert void to object.
Damn Async Tasks with a Task return dont have this issue, they have another one : executing even if the event isn't fired
So what is the new correct way to call a method in preview 7 ?
Thanks.

You need to use @onclick="ShowCloseTicket" after preview 7.
Details were written in https://devblogs.microsoft.com/aspnet/asp-net-core-and-blazor-updates-in-net-core-3-0-preview-7/

Thanks for contacting us. We believe that the question you've raised have been answered. If you still feel a need to continue the discussion, feel free to reopen it and add your comments.


Enhancement | Add components documentation

What?

Describe which components are used in EKS cluster and what role do they play in them

References

Closes #163

@angelofenoglio this 1st iteration looks great, we'll proceed to merge for autodeployment.


Add lyric-search extension

Description

This is the initial commit. It includes one command that is about to use the Genius Lyrics API to search for songs, using bits of lyrics.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi!
Thank you for your contribution! My name is Milena and I will be reviewing it today.
We already have an extension that queries the Genius API. https://www.raycast.com/tkdkid1000/genius-lyrics
Does yours do anything different that would justify having a second extension?

Hello!
The extension you mentioned, Genius Lyrics, uses the Genius API to search for song lyrics using song titles. It utilizes this API link:
https://genius.com/api/search?q
Whereas the Lyric Search extension I developed search's using partial lyrics to find song titles. It utilizes this API link:
https://genius.com/api/search/lyrics?q=
I figured that would be a big enough difference to separate the two.

I don't think this is enough for a new extension. It is the same service! Please, update the existing extension if you would like to add this feature. I will be closing this PR for now. Feel free to contact me on Slack (https://raycast.com/community) if you have any doubts or want to discuss this further.

That's odd. You can try this link https://join.slack.com/t/raycastcommunity/shared_invite/zt-2m9uewog6-qPeqEbmYl988VSOJHLcaEw


Remove adding module name in module_group_path  if it set from cli

When I generate module using this command:
generamba gen MyModule module --module-group-path projectName/Scenarios

Generamba adds MyModule folder in projectName/Scenarios by default. But in my opinion if I change destination with module-group-path option it should add files in same path, that I set in that option
So, instead
projectName/Scenarios/MyModule

it should be
projectName/Scenarios

@IvanUshakov Thanks for your suggestion, seems reasonable.

After discussion with @Beniamiiin we decided that current behavior is more predictable. If some more people will request for this feature, we'll revisit to it.


Add TreeSortable missing functions

I think we can be pretty sure the comparisons won't be called recursively and just skip the RefCell, make it Box<Box<FnMut...>>.

How about changing i32 to SortColumn? The automatic trait would become mostly useless but we'd have a more strongly-typed API for this trait.

we can be pretty sure the comparisons

Uh, actually no, there's no evidence of this yet. :(

For as far as I know, the sort_column_id corresponds to the position of the column inside the its view. Or perhaps you mean adding an unit struct to wrap the i32?

Would enum SortColumn { None, Default, Some(u32) } reflect sort_column_id semantics? It's either unsorted, sorted with the default function or by some column with non-negative index.

Can you test what happens if you change the sort column id from a comparator closure? I don't see any thing preventing recursion in libgtk. So the RefCell will probably panic. In that case the closures need to be Fn.

I'll try once I'm back home.

I've tested calling set_sort_column_id from the comparator recursively and caused RefCell to panic. So Fn it must be after all.

After taking a closer look at get/set_sort_column_id it seems an even more precise treatment of SortColumn is needed:
pub enum SortColumn {
    Default,
    Index(u32),
}

trait TreeSortableExt {
    fn get_sort_column(&self) -> Option<(SortColumn, SortType)>;
    fn set_sort_column(&self, sort_column: Option<(SortColumn, SortType)>);
}

Why? The functions deal with id and SortType together but SortType is meaningless in the unsorted mode so there needs to be an Option somewhere despite SortColumn having an Unsorted variant. If we pull the option out of the tuple, None means "unsorted".
A variation on this scheme avoids Option in the set_ method:
    fn set_sort_column(&self, sort_column: SortColumn, order: SortType);
    fn set_unsorted(&self);

I've just had an idea: we might actually be able to cut down on all that Fn(Foo, Bar) boilerplate. If we define
pub trait TreeIterCompareFunc<T>: Fn(&T, &TreeIter, &TreeIter) -> Ordering + 'static { }

this trait might make everything more readable.

We can merge as is and then I'll play around with various trait-based approaches.

Thanks for implementing this!


Functions for calculating the DA estimator

Facilities for calculating the the MLDA estimator in the two-level case, as well as associated variances

Hi, I am still trying to figure out many things and a few questions with regard to design have come up:

Do you generally think that the two functions as I sketched them are suitable?
If I want to do the get_DA_samples function in analogy to get_samples, I need to modify sampler.py first, so that it the dict that is returned by tda.sample contains also promoted_coarse? Is that something we want generally in the two level/multilevel case?

@louisekluge

I think the best way to do this would be to allow compiling an InferenceData object for the promoted_coarse samples. That way we could easily compute the difference for any quantity, parameters, or qoi or whatever. I would adapt the get_samples function to accept level="promoted_coarse" as an input to condstruct that InferenceData object. Then we can use a function like the one you have sketched DA_estimator(inferencedata_fine, inferencedata_coarse_promoted, attribute) to compute the estimator.
Yes you would have to modify sampler.py to return the additional list. I have made some changes to the RemoteChain class that handles the parallelisation which should make this a lot easier for the parallel case. They are on this branch https://github.com/mikkelbue/tinyDA/tree/mikkel-ray_refactor .. Could you test that branch for me? Then I will merge it.


color is not turning blue and code appears to be correct

Challenge Use CSS Selectors to Style Elements has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

Kitty ipsum dolor sit amet, shed everywhere shed everywhere stretching attack your ankles chase the red dot, hairball run catnip eat the grass sniff.

When I write the code in the challenge color does not turn blue, even though the code appears to be correct. Please observe attachment

in style you can only select what exists. So far you only have a p element but no h2. You have selected h2 in style but it should be p.

Thanks so much!

How do i do that?.....i have also been trying to do this same element code but my text doesn't turn blue....please what code do i use to do that...thanks


New headless Chrome option

See https://developers.google.com/web/updates/2017/04/headless-chrome
Hopefully this project is still going?

Hi @bluepeter! Thanks for sharing the link. Yes; it looks like headless Chrome is almost stable! It also looks like the latest builds now support the printToPDF CDP method!

Great :) Any new commits coming soon to this repo?

@bluepeter It's taken a long time, but... here's a pre-release on a standalone lambda package. Would be great to get some feedback!
yarn add @serverless-chrome/lambda

Then in your Lambda handler function:
const launchChrome = require('@serverless-chrome/lambda')
const CDP = require('chrome-remote-interface')

module.exports.handler = function handler (event, context, callback) {
  launchChrome({
    flags: ['--window-size=1280x1696', '--hide-scrollbars']
  })
  .then((chrome) => {
    // Chrome is now running on localhost:9222

    // do Chrome stuff here

    // for example:
    CDP.Version()
      .then((versionInfo) => {
        callback(null, {
          versionInfo,
        })
      })
      .catch((error) => {
        callback(error)
      })
  })
  .catch((error) => {
    // Chrome didn't launch correctly

    callback(error)
  })
}

Development is happening in the feature/v1.0 branch

Awesome work @adieuadieu, I'm looking forward to trying this out this week! Will let you know if I find any issues.


Broken Link

Origin page
https://substrate.recipes/basic-pow.html
link pre-runtime digests

Here is the source of that doc: https://github.com/JoshOrndorff/recipes/blob/master/text/basic-pow.md
I bet Joshy would really appreciate a scan & update of relevant links @donkey-donkey :grinning:
We can't update the whole universe, it would be epic to get all hand on deck to help update things all over :pray:


Add a route to return all users from db. [For testing/admin purposes - IT MIGHT BE REMOVED]

Route Added. app.get('/users', function (req, res) { /* ... */ });


Get error ASLR disable failed: EPERM: Operation not permitted when executing cargo tarpaulin -v

I use root user , and get the error ASLR disable failed: EPERM: Operation not permitted when executing cargo tarpaulin -v. And i tried sudo cargo tarpaulin -v , it prompt cargo command not found
So i tried sudo -s cargo tarpaulin -v , it also prompt ASLR disable failed: EPERM: Operation not permitted .How can i resolve it ?

So what environment are you running in? A CI server (if so which one) or your personal machine? This issue is a duplicate of #77 so you may find help there. ASLR is a security measure to stop malicious processes inspecting the memory or altering the execution of a process (including arbitrary code execution). So you may need to change a security rule via seccomp to allow tarpaulin to disable ASLR.
As for how to do that I'm not sure but maybe running tarpaulin with setarch -R will work

Btw , why Tarpaulin can run in personal machine(centos system ) , just use normal user which have no sudo authority (So it have no authority  to disable ALSR).
And do not work in docker , even though use root user ?

@new-commer Have you tried the method in the docker section of the readme? And has it solved your issue?

@xd009642 thanks Thank you for your help ， we have tried it works  . And We're trying to do that in gitlab-ci .

@new-commer : did you find any way to make this work with gitlab-ci? I'm hitting the same problem.

You might be able to get it to work using the docker image in gitlab.
Although I tried it myself on a test project last weekend and it worked
fine (using tarpaulin version 0.9.1)
On Tue, Nov 5, 2019 at 10:47 AM Guillaume Desmottes <
<EMAIL_ADDRESS>wrote:

@new-commer https://github.com/new-commer : did you find any way to
make this work with gitlab-ci? I'm hitting the same problem.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xd009642/tarpaulin/issues/146?email_source=notifications&email_token=AA2PZBWRO5LISTWKDTI3D73QSFFLVA5CNFSM4FTQC4NKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDCNCNI#issuecomment-549769525,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA2PZBT3AFE67UIKIZTGSTLQSFFLVANCNFSM4FTQC4NA
.

Hi, just to help if someone is experiencing same issue using a custom built image for the runner.
You can also add security_opt option to your runner configuration file /etc/gitlab-runner/config.toml:
[[runners]]
  [runners.docker]
    security_opt = ["seccomp:unconfined"]

Then restart gitlab-runner service in order to reload configuration.
Note that as said in other issues this option can also be used when running a container by hand:
docker run --rm -it --security-opt seccomp=unconfined ...
It could be interesting to add this to a Wiki/FAQ page.

Just to provide more background for people in situations where seccomp=unconfined is too liberal, one can also use a modified seccomp profile that is used. Per the Docker documentation on seccomp, a number of syscalls are restricted through the default seccomp policy, including the personality syscall which is how tarpaulin and other tools that require ASLR to be disabled can request so.
Docker's built-in default seccomp policy does allow the use of the personality syscall in certain cases, but only with the arguments 0x8, 0x2_0000, 0x2_0008, and 0xffff_ffff (GET_PERSONA), apparently.
The current method of disabling ASLR does not match one of the requested values, so is rejected by the kernel:
https://github.com/xd009642/tarpaulin/blob/c5e8e09c130cf202e399b3716e187e65f60291bd/src/process_handling/linux.rs#L35-L43
All of this is to say that one could add the object
{
  "names": [
    "personality"
  ],
  "action": "SCMP_ACT_ALLOW",
  "args": [
    {
      "index": 0,
      "value": 262144,
      "valueTwo": 0,
      "op": "SCMP_CMP_EQ"
    }
  ],
  "comment": "Enable personality(ADDR_NO_RANDOMIZE) syscall",
  "includes": {},
  "excludes": {}
}

to the syscalls key in their seccomp JSON file to allow ASLR disables to succeed. (If the persona is somehow different than just 0, the "value" might need tuning.)


SEAB-4927 Restricted postgres dependency to only test

Description
This PR restricts the Postgres dependency in the CLI to only the test dependencies.
Review Instructions
Verify the scope for the Postgres dependency is set to test.
Issue
https://ucsc-cgl.atlassian.net/browse/SEAB-4927
Please make sure that you've checked the following before submitting your pull request. Thanks!

[x] Check that you pass the basic style checks and unit tests by running ./mvnw clean install
[x] If this PR is for a user-facing feature, create and link a documentation ticket for this feature (usually in the same milestone as the linked issue). Style points if you create a documentation PR directly and link that instead.

(restarted builds from failed)


bandwhich: add shell completions and man page, add meta.changelog

Description of changes
Pre v0.22.0, shell completions and the man page were static and heavily outdated.
v0.22.0 then removed those entirely.
v0.22.2 then re-added shell completions and the man page, but this time natively generated on build time (assuming $BANDWHICH_GEN_DIR is set).
Technically, shell completions for PowerShell and Elvish are generated as well, but we don't install those, since our installShellCompletions does not support those shells.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Thank you!


MetaDatum type in the ledger implementation matching the Plutus Data type

The Plutus interpreter expects several arguments of type Data. I believe we agreed that this type should be defined in the ledger code, and should be the same as the type of ledger metadata (MetaDatum).
Right now, these two types have different constructors and different names (Data and MetaDatum). They should have the same name and same constructors.
data MetaDatum
  = Map [(MetaDatum, MetaDatum)]
  | List [MetaDatum]
  | I Integer
  | B B.ByteString
  | S T.Text

data Data =
      Constr Integer [Data]
    | Map [(Data, Data)]
    | List [Data]
    | I Integer
    | B BSL.ByteString

We definitely need Constr. I don't know why we didn't add that before. To do this really nicely we'd need the CBOR extension for alternatives which we proposed a while ago. I don't know what happened to that (@dcoutts was pushing it).
The S constructor is worrying. We can't necessarily support that in Plutus. We could add Text as a builtin type but I'm not sure we want to. So we'd have to hack around it. Apparently I reviewed the PR where this was introduced and didn't say anything, which is unfortunate.

We do not need the types to be the same provided we have a suitable conversion.
Fortunately the conversion from MetaDatum to Data is easy. We don't use the Constr in the targer type. The text is just converted to bytes in utf8. That's it.

I thought it was nice and parsimonious for them to be exactly the same...

If they can be different, there is really no reason to even translate them?

Well, at least we probably want the metadata to go into the validation context so scripts can see it. I had hoped this would be beautifully simply since it would already be the same type, but we can translate it if we have to.

Oh hm.. I didnt think MD would be passed. But it makes sense to pass it I guess?

I think we definitely want to pass it!

Ok, we will translate the MetaDatum to Data

Different types, passing MD to scripts is part of the larger question of translating Tx data into a Data type


dbeaver/dbeaver#22858 Launcher fix

How to test:

On Linux
Delete (backup first) DBeaverData and .DBeaverData folders in ~/.local/share.
Install DBeaver 6.1.2 (folder .DBeaverData must be used)
Create several db connections
Install new version

Acceptance criteria:

Existing workspace in ~/.local/share/.DBeaverData must be used. All previously created connection must be there.
Folder DBeaverData mustn't be created.

verified


AWS custom parameters

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6669f7394b9a6521d17a9be5--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6671fe13ff107b5bab3e50fd--harness-developer.netlify.app


DISCUSS: Subdue 2.0!

Creating another meta ticket here, to aggregate all outstanding issues & PRs related to subduing checks and handlers (i.e. notification signal/noise) into a single location for discussion and eventual implementation. If you are aware of a related issue or PR – open or closed – please comment on this issue with a link, so we can take every scenario into consideration before designing Subdue 2.0.
Related issues:

https://github.com/sensu/sensu/issues/777
https://github.com/sensu/sensu/issues/958
https://github.com/sensu/sensu/issues/997
https://github.com/sensu/sensu/issues/999
https://github.com/sensu/sensu/issues/1004
https://github.com/sensu/sensu/issues/1113

We'll update this ticket as we begin planning subdue improvements, so please stay tuned for updates – your feedback is important! #monitoringlove

Related: https://github.com/sensu/sensu-extensions/pull/5

Related: https://github.com/sensu/sensu/pull/847

Could we also use subdue feature to handle messages that are not required to be displayed on the dashboard?  We basically are looking for an option to filter messages.

Tagging https://github.com/sensu/uchiwa/issues/458 here as it may be related.

Hi friends! Please note the following proposed changes to how Sensu handles subdue scheduling:

For simplicity, Subdue rules will only be applied at the "scheduler" (i.e. the check requestor)
Subdue rules will now be supported by subscription checks, and standalone checks
Sensu Filters and Subdues will share a common specification for applying time-based rules (where Subdue rules will be applied at the "scheduler", and Filter rules will be applied at the handler)
subdue attributes will only be referenced from check definitions (i.e. they will be removed from handler definitions)

The new Sensu monitoring flow will be visualized as follows:

check definition => check request => subdue => check execution => check result => event => filters => mutators => handlers

The new Subdue specification (and corresponding time-based rule specification for Filters) is still a work in progress. Stay tuned for more updates on this issue.

Potentially related: #861

Would like to see the use case in #940 be possible. I would think that this is a common enough scenario that it should be a built in, basically being able to subdue or stash something up to a given level. I think it would make sense to apply same thing to subduing checks so that you only get critical's between certain hours.
Another useful thing would be to optionally have stashes be removed when they recover.

Hello, what's going on with https://github.com/sensu/sensu/pull/847 - this functionlity would be great for something I'm currently trying to do.

https://github.com/sensu/sensu/pull/1415 has been merged :+1:

Going to go through the issues/PRs listed in this description and update them accordingly.

@portertech I might have beat you to it on a few of them. :)


Log level coupling to $VERBOSE and $DEBUG not always helpful

Anyone who uses libraries that generate a lot of warnings will resort to using -W0 as a default in Ruby. This does silence the warnings, but it also has the unfortunate side-effect of pretty much silencing Console.logger as well since the default level now moves up a notch.
What's doubly frustrating is anyone with the -W0 default will not see output from Console examples, where this:
require 'console'

Console.logger.info("Hello World")

Does nothing at all. This can be reproduced with RUBYOPT=-W0 ruby example.rb
Overriding this within an application is not convenient. Right now what I've found you have to do is:
ENV['CONSOLE_LEVEL'] ||= 'info'

Where that's a really round-about way of setting a default. It would be more convenient if the default_log_level could be specified, as in Console::Logger.default_log_level = :debug or whatever setting is desired, where that will be applied to all loggers created after that point.

I agree with you, but I'm also not sure what the solution is.
Basically... log data should always be some kind of non-essential "debug output".
I wanted to try and make it tie into existing Ruby constructs for controlling log level.

There's nothing wrong with having defaults tied to Ruby's global verbosity level, but right now it's really awkward to try and separate those two to override it.
Most other logging tools, even Logger, support an arbitrary per-logger logging level override. Logger.new(level: :debug) for example.


[680] Write angular test for footer

Description:
Test for creating footer component.

Codecov Report

Merging #682 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #682   +/-   ##
=======================================
  Coverage   91.77%   91.77%
=======================================
  Files          88       88
  Lines        2661     2661
  Branches        4        4
=======================================
  Hits         2442     2442
  Misses        213      213
  Partials        6        6

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 349d33d...32e5607. Read the comment docs.


Update README.md

The example snippet in the README shows the @geoarrow/geoarrow-js/worker entrypoint but the rollup and src/index.ts config show a worker named import instead. This updates the README to reflect that difference.

@kylebarron This PR fixes the imports of the README example, but it looks like the README example still has other issues, see: https://github.com/geoarrow/geoarrow-js/issues/25

I'm not really sure which is the better import; JS bundling confuses me.
As for the example, as a quick fix to have a working example, we can switch to
const originalData = arrow.makeVector(new Int32Array([1, 2, 3])).data[0];

Haven't had a chance to take another look so will close for now. Thanks for taking a look!


README: Remove Patreon badge for consistency amongst donation methods

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] ~Have you written new tests for your changes? Here's an example.~
[x] ~Have you successfully run brew style with your changes locally?~
[x] ~Have you successfully run brew tests with your changes locally?~

We don't have a badge for other donation methods - this looked slightly out of place.

Agreed, I meant to do this but clearly forgot, thanks @issyl0!


⚠ API - Lens has degraded performance

In fc4788b, API - Lens ($LENS_API_URL) experienced degraded performance:

HTTP code: 503
Response time: 613 ms

Resolved: API - Lens performance has improved in c6d807c after 6 minutes.


Next 16000

'Next' button doesn't work on savings and investment page Ticket

Fix to allow progression past savings investments when applicant is over 61

Yes, go ahead


resolutionCache getDirectoryToWatchFailedLookupLocation always sets recursive watcher for entire project

getDirectoryToWatchFailedLookupLocation in resolutionCache.ts checks if a failed lookup location is in the project's root dir, and if so, watches the entire project root, recursively (intentionally, it has a comment // Always watch root directory recursively).
For projects containing potentially very many subdirectories (just large projects, but also projects with large node_modules subtrees), this will read thousands of directories and create corresponding thousands of watchers.
I wonder if we could do better, but I don't understand the thinking that went into this. Was the idea that just having a recursive watch on the root is more effective than watching lots of more precise locations?
I'd consider only adding a watch for the closest non-existing file from the lookup location, e.g. for a location /foo/bar/baz/index.ts not being found, with baz/ not existing, a watch on /foo/bar would be sufficient, and create fewer watches and file reads than watching every file in the project recursively.

This is fixed in #25811 note that we would still watch sub directory since watching each loacation or watching directory of each location lakes too much time on big projects.


run versionBumpp function in a mjs file

Describe the bug
Here are the steps to reproduce the error:

create a mjs file
import versionBumpp from 'bumpp';
run versionBumpp function

import { ReleaseType } from "semver";
^^^^^^^^^^^
SyntaxError: Named export 'ReleaseType' not found. The requested module 'semver' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:
import pkg from 'semver';
const { ReleaseType } = pkg;
at ModuleJob._instantiate (node:internal/modules/esm/module_job:128:21)
at async ModuleJob.run (node:internal/modules/esm/module_job:194:5)
at async Promise.all (index 0)
at async ESMLoader.import (node:internal/modules/esm/loader:385:24)
at async loadESM (node:internal/process/esm_loader:88:5)
at async handleMainPromise (node:internal/modules/run_main:61:12)

I found a TS type declaration ReleaseType in dist/chunk-L3LY4KGC.mjs.
Reproduction
https://stackblitz.com/edit/stackblitz-starters-7ky89b?file=index.mjs
System Info
System:
    OS: macOS 13.4
    CPU: (10) arm64 Apple M1 Max
    Memory: 1.81 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 16.16.0 - ~/Library/Caches/fnm_multishells/41379_1685869881245/bin/node
    Yarn: 1.22.19 - ~/Library/Caches/fnm_multishells/41379_1685869881245/bin/yarn
    npm: 8.11.0 - ~/Library/Caches/fnm_multishells/41379_1685869881245/bin/npm
  Browsers:
    Chrome: 113.0.5672.126
    Safari: 16.5

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

same error

用 import type 就不会打包到 mjs 里去，看起来是 tsup 打包的问题。
@types/semver 声明了这个type，semver 实际上没有导出。
import type { ReleaseType } from "semver";

但是打包后直接运行 node .\dist\index.mjs 会报 Dynamic require of "tty" is not supported
import { versionBump } from "./dist/index.mjs"; 也一样
file:///D:/Work/bumpp/dist/chunk-DHK6LOKB.mjs:29
  throw Error('Dynamic require of "' + x + '" is not supported');
        ^

Error: Dynamic require of "tty" is not supported
    at file:///D:/Work/bumpp/dist/chunk-DHK6LOKB.mjs:29:9
    at<EMAIL_ADDRESS>(file:///D:/Work/bumpp/dist/chunk-DHK6LOKB.mjs:66:16)
    at __require2 (file:///D:/Work/bumpp/dist/chunk-DHK6LOKB.mjs:44:50)
    at file:///D:/Work/bumpp/dist/chunk-DHK6LOKB.mjs:661:34
    at ModuleJob.run (node:internal/modules/esm/module_job:217:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:308:24)
    at async loadESM (node:internal/process/esm_loader:42:7)
    at async handleMainPromise (node:internal/modules/run_main:66:12)

Node.js v20.7.0


Add 24.04 base

It seems that building for multiple base is not yet supported according to https://github.com/canonical/charmcraft/issues/1789


Improve configuration of native image compilation

Solve msgpack issue with --initialize-at-run-time.
Use quick build mode for 40% faster compilation and 20% smaller executable (tested on Linux amd64). If necessary, this can be disabled for release builds. Note that with the move from GraalVM CE 22 to Oracle GraalVM 23, native image compilation time has doubled and binary size has increased to 120 MiB on Linux amd64.
Use Intel Skylake (2015) CPU features for amd64 executables.
Remove options that are commented out.

How much perf do we gain from targeting skylake? Can you enable the native CLI builds to CI so we can compare it to the default architecture? Or, if you're on an x86 machine, feel free to just run some tests locally and report the results.

Does Pkl have a comprehensive benchmark suite? If you want proof, that’s probably the only way.

These CLIs are libraries, and have a broad set of use-cases. For that reason, I'm thinking that we should probably be conservative here. We probably shouldn't just bump the version, but if there's a significant perf gain, we can consider adding this as an additional architecture.

Your call. I feel that “skylake” is fairly conservative yet enables most CPU features. “x64-v3” is an arbitrary GraalVM default—we should figure out what’s right for Pkl. Also, this is easy to undo depending on feedback.

Does Pkl have a comprehensive benchmark suite? If you want proof, that’s probably the only way.

Not yet. We have some very lightweight benchmark tests, but we don't have an environment (yet) that can run workloads with bare metal isolation. Until then, the best we can do is run benchmarks locally the compare.

Until then, the best we can do is run benchmarks locally then compare

But what benchmarks do you run? ./gradlew pkl-core:testLinuxExecutableAmd64 doesn’t strike me as a meaningful benchmark.

There is an in-language stdlib module that we use to write on-off benchmarks when we want to test specific things when iterating locally.
There's also the bench:jmh task, although we haven't been using that nearly as much to get any signal.
The suggestion of running testLinuxExecutableAmd64 is just a coarse-grained way to get some signal, but definitely not a real benchmark.

Here's a quick benchmark that might be a good starting point for comparison:
amends "pkl:Benchmark"

import<EMAIL_ADDRESS>import<EMAIL_ADDRESS>import<EMAIL_ADDRESS>
local githubActionJson = read("https://json.schemastore.org/github-action.json")

microbenchmarks {
  ["json schema generator"] {
    expression =
      let (parsed = Parser.parse(githubActionJson))
        new ModulesGenerator {
          rootSchema = parsed
          baseUri = URI.parse("file:///foo")!!
        }
          .modules
          .map((it) -> it.moduleNode.output.text)
  }
}

Here's a quick benchmark that might be a good starting point for comparison.

On my laptop, the variance of this benchmark is too high to draw any conclusions about-march settings.
However, I can tell that quick build mode significantly degrades performance, which isn't surprising.
-march=x86-64-v3 requires Intel Haswell (2013) or AMD Excavator (2015), which isn't far off from -march=skylake.
To move forward with this PR, I'll remove -march-skylake.

The one remaining request is to undo the change to --add-opens here.

I’m still working on that. I’m not yet convinced that --add-opens is required.

Ready to review from my side.
The "Improve BinaryEvaluatorSnippetTests(Engine)" refactoring isn't essential because I ultimately added NativeServerTest instead of NativeBinaryEvaluatorSnippetTests. But I think it's a worthwhile improvement regardless.

Look like you're right; --add-opens is not needed :D


Mesh resource

http://www.assimp.org/

Scene

Mesh[]

Name
Geom Data [chanels ...]
Material name

scene graph

MeshComponent:

Scene resource
Mesh
Material maping (slot -> resource)


Fixes flaky integration tests

Description
AbstractDefaultConfigurationTests used configurationFolder as a constant as result all inherited tests could use the same config folder which can be cleaned unpredictably.
Check List

[ ] New functionality includes testing
[ ] New functionality has been documented
[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Looks a bit better now.

@willyborankin  Good find! Thank you for fixing this :)


View all comments on a Google Doc

A request to the /articles/doc/uuid-string endpoint should return information about the Google Doc associated with the article


Color Picker Editor Shortcut

Description of the new feature / enhancement
A separate keyboard shortcut to open the color picker's editor.
Scenario when this would be used?
The editor is very useful but it is situational. I don't want to use the editor every time I use the color picker. I don't want to make the shortcut "Only pick a color" either because  I do want to use the editor occasionally. A separate keyboard shortcut to open the color picker editor would be very convenient.
Supporting information
No response

/dup #12778


Provide an API

MultiSigil is currently a command-line tool.  We should provide an API for use by other programs

I would close this as out-of-scope.
The tool is perfect as it is now =)
Jokes aside, but I would prefer "tiny codebase, not feature-complete and maintainable by Dependabot" to "feature-complete, larger codebase and requires manual interventions to fix/test things before updating dependencies".


Fixed undefined-variable error on site redis clear

Instead of changing site bindings, can we use the Environment#connectionInfo  method instead? Not sure how much work it would be to deprecate the Site#bindings method entirely. https://github.com/pantheon-systems/cli/blob/master/php/Terminus/Models/Environment.php#L258-L287

Good idea! This as the only thing using that function, so I changed SiteCommand#redis and removed Site#bindings.

Very clean :+1:


Produces invalid output when default exporting a named function expression

Do you want to request a feature or report a bug?
Report a bug

What is the current behavior?
Produces invalid output when default exporting a named function expression
If the current behavior is a bug, please provide the steps to reproduce.

try to compile
export default (function hello () {
  return true;
});

What is the expected behavior?
emits valid code, instead it produces
ERROR in main.js from UglifyJs
Unexpected token: punc ()) [main.js:80,1]

when running
webpack --mode=production

both
export default (function () {
  return true;
});

and
export default function hello () {
  return true;
};

Seem to produce valid output
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.
webpack version<EMAIL_ADDRESS>node version: v8.10.0
Code like this is emitted by babel when using the babel-plugin-transform-regenerator plugin
PS
<!-- Also consider trying the webpack@beta version, maybe it's already fixed. -->
=> (webpack@beta doesn't seem to exist)

The problem seems to be in this line. Wrongfully flagging this as an exportDeclaration, rather than an exportExpression. It looks like acorn doesn't preserve parenthesis around expressions.
Either changing that to
if (statement.declaration.id && !statement.declaration.type === 'FunctionExpression') {

or using
  preserveParens: true

in the parser configuration fixes this for my case (but breaks other tests)

acorn parses this correct, this is what it sees:
{
  "type": "Program",
  "start": 0,
  "end": 39,
  "body": [
    {
      "type": "ExportDefaultDeclaration",
      "start": 1,
      "end": 38,
      "declaration": {
        "type": "FunctionExpression",
        "start": 17,
        "end": 37,
        "id": {
          "type": "Identifier",
          "start": 26,
          "end": 31,
          "name": "hello"
        },
        "generator": false,
        "expression": false,
        "async": false,
        "params": [],
        "body": {
          "type": "BlockStatement",
          "start": 35,
          "end": 37,
          "body": []
        }
      }
    }
  ],
  "sourceType": "module"
}

Anyway, https://github.com/webpack/webpack/pull/6889 fixes this.


Unbounded Recursion Research

Summary
As a purely functional programming language, Enso uses recursion as its primary construct for performing looping. However, as we're building on top of GraalVM, we are butting up against the JVM's limited stack depth.
To that end, we need to find a solution for allowing unbounded recursion on the JVM. We're currently exploring two different approaches:

Simulating segmented stacks using threads (quite a heavyweight solution).
Transforming recursive code into continuation-passing style.

Value
This is a semantic stumbling block for Enso as a language that needs to be solved as soon as possible.
Specification

The Enso implementation allows for execution of unbounded recursion.
The performance of using recursion is roughly on par with Haskell's non TCO'd case.

Acceptance Criteria & Test Cases

Execution of unbounded recursion works in the interpreter.
Performance of such execution is acceptable.
It is accompanied by a comprehensive performance suite and set of tests.

As it is unlikely in the extreme that Loom will be the route we take to solving this problem in the near term, we're instead going to approach it in terms of a CPS transform. The exact design details for this are to be worked out as the remaining part of the task.

While we can rely on the StackOverflowError to be a reliable signal of our stack running, out, the lack of a 1:1 mapping between Enso frames and Java frames mean that it isn't a safe signal. The Enso implementation controls only certain frames on the Java stack, which means that it's very possible for a stack overflow to occur after a side-effect has happened, making the unwind unsafe to execute.
This unfortunately means that we're limited to a heuristic-based approach, whether that be used to trigger the CPS transform, or the spawn of a new Loom fibre at a later date.
The current (sketch of a) design is as follows:

In a thread-safe manner, track the execution of functions (and their callees). The necessary information is whether in some function f, its execution history includes a call to f. This is the necessary condition that f is recursive, even through calls to other functions.
Once the number of recursive calls exceeds some (necessarily conservative) threshold, rewrite the all the functions in the entire call chain into CPS. It should be noted that this re-write should be local (but may be cached): it does not affect other calls to the functions involved, and it may end up being re-written again if necessary.
Replace the current FunctionBodyNode with the re-written one, and so forth up the chain.

The CPS re-write can be performed using a deterministic algorithm as described in "Compiling with Continuations", and for execution on the JVM will need to be combined with trampolining or loop-based tail-call elimination. The algorithm provided, however, is not a complete match for Enso's semantics, and will need to be adapted.
There are three main issues with this sketchy design.

If there is a set of mutually-recursive functions large enough, it is possible to overflow the stack even before f ever sees that it was called in its history.
It requires tracking data that may not be available in the current design for the interpreter.
It can result in ballooned memory usage in the face of large numbers of recursive function blocks.

As a result, the only 100% sound approach  is to perform the CPS transform globally for the entire program. This is a very suboptimal state of affairs, as initial (Java-level) benchmarks showed that CPS'd code was around three times slower.

Given that we want to solve the problem in general, we are limited by soundness concerns to doing the full CPS transform across the entire program. However, to make this acceptably fast, it needs to be done as follows:

Implement a static-analysis pass that transforms the entire program from direct style into CPS, ensuring that this transformation preserves semantic soundness.
Perform CPS optimisation, re-writing the basic CPS into a more optimised form.
Perform constant folding, function argument expansion, and various 'contraction'-style optimisations (inlining).
Perform beta-expansion.
Perform eta-reduction and uncurrying where possible. It should be noted that this is generally not possible with Enso's dynamic semantics, and hence may be omitted.
Perform hoisting and CSE.
Perform closure conversion.

There are, however, some significant points that need to be kept in mind when doing this transform:

Trampolining is necessary to ensure that the CPS'd code doesn't stack overflow itself.
Care must be taken to ensure a mapping between the source of the program and the actual CPS'd code being executed. This needs to be a source-level mapping (for inspection), but also needs to account for the transformation of the results of data-dependency analysis alongside the CPS transform. This will ensure that we know which parts of the code to re-evaluate when things change.

Due to the reliance of this process on the availability of an extensible static-analysis framework, it should take place after the new parser and AST has been integrated into the interpreter.

Some useful resources:

CPS Transformer
Compiling with Continuations (book)
Programming Languages: Application and Interpretation (book).

Some more:

SSA vs. CPS for MLton
Pushdown CFA for Free

It has been determined that CPS alone does not provide a complete solution to this problem as it has some major issues with caching and is a bad semantic match for truffle. Attacking this problem has been deferred until after the 2.0 release.


bail not work

Bug report

What is the current behavior?
webpack --config webpack.config --bail when error occured webpack don't exit
and i debuged the case and found maybe is here a bug in NormalModule?
			// if we have an error mark module as failed and exit 			if (err) { 				this.markModuleAsErrored(err); 				this._initBuildHash(compilation); 				return callback(); 			}
should  return callback to be return callback(err) then the bail can work
If the current behavior is a bug, please provide the steps to reproduce.
use mini-css-extract-plugin loader but not use mini-css-extract-plugin plugin

What is the expected behavior?
bail parameter works as what it meaned

Other relevant information:
webpack version:  lastest
Node.js version: v8.11.3
Operating System: window7
Additional tools:

#7994

Workaround for webpack@4
// webpack config
{
  plugins: [
    {
      apply: ({ hooks: { failed } }) =>
        failed.tap('HandleFailurePlugin', e => {
          console.log(e)
          process.exit(1)
        })
    }
  ]
}

Somebody can create minimum reproducible test repo?

That was my fault. In my case, I didn't handle errors in the compilers run method. Using Node API you should call process.exit manually if something went wrong. Seems like the bail option works as expected.

/cc @AMDvsTMD @benpolinsky friendly ping, problem still exists, if yes please create minimum reproducible test repo, thanks!


Implement the address question renderer

Description
Implement the rendering logic for address questions
Checklist

[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Issue(s)
#277

@bion - there are no current tests for the rendering logic, shall I add some? Or do you feel they are not needed since it's mostly boilerplate?

I think it's ok to add without unit test. However I think it'd be good for us to introduce a browser test that includes making questions with all of the different question types and filling them out as the applicant. That's not in the scope of this PR though.

Thanks for clarifying - I filed https://github.com/seattle-uat/universal-application-tool/issues/318 for the browser tests (we have no current way in the browser to navigate to the applicant program list, so this is tricky for now)


Draggable objects break when restarting a scene

Version

Phaser Version: 3.16.10 Beta 4

Operating system: Windows 10

Browser: Chrome

Description

Dragging an object works fine the first time the scene is created, but if you stop a scene and then start it again, you are no longer able to drag the object. I have tried both this.input.on() and gameObject.on() drag events.
Example Test Code

class Drag {
    create() {
        let image = this.add.image(50, 50, 'yes')
            .setInteractive();

        this.input.setDraggable(image);

        image.on('drag', function (pointer, x, y) {
            this.x = x;
            this.y = y;
        });
    }
}

Additional Information

Fix:
https://github.com/photonstorm/phaser/blob/master/src/input/InputPlugin.js#L2288
Change this line to
this._dragState = [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ];

Thank you for submitting this issue. We have fixed this and the fix has been pushed to the master branch. It will be part of the next release. If you get time to build and test it for yourself we would appreciate that.


Make square pictures

Description of the new feature / enhancement
I want to be able to make square pictures that are 300 x 300 or 400 x 400 for example.
Right now it doesn't seem to work as the picture is out of proportions.
Scenario when this would be used?
for profile pics
Supporting information
No response

@HelpdeskRenggli what are you using for your stretch style?


Support for POSIX file locking

I'm curious if YaS3fs could be extended to support file locking. FUSE does support  "POSIX advisory record locking", and I was wondering if it's feasible to extend the code to support this. My thoughts are:

Each node participating in a cluster would need to store the locked state of a file. This would simply be new values in the current cache code, and would need to store enough information to note the byte range of a lock, along with the type. I don't know if FUSE will supply the PID or not, but I assume that it will.
The messaging code between nodes would need to be extended to include new cache update messages for locking. This will need to include a lock identifier that is based on node ID alone, since other nodes in the cluster don't care what PID on a remote node is holding the lock.
File operations would need to check for lock conflicts between PIDs and prevent particular file operations from occurring as required.
The case of a disappearing node in a cluster would need to be handled. If a node was holding locks on behalf of a process and the node suddenly died, the locks would remain forever across the cluster.

The first 2 tasks don't sound overly complex. The 3rd task will require a bit more effort, but once the details are nailed down with a few proper test cases then things should be fine.
The last task is the problem task. I would suggest that locks within the cluster are time based with an expiry, and a node holding locks needs to refresh locks before expiry.
For example, lets say that a single node receives a message noting that the first 100 bytes of file 'lockme' has a read lock held. The receiving node will add that lock to the cache and add a local timestamp for the received lock OR will just update the timestamp if the lock details already exist. A separate thread will run on the sending side to continue to send those lock details out at half the expiration time (lets say expiration is 5 seconds), and the lock checking code on the receiving side will automatically remove the lock from the cache if the timestamp is older than 5 seconds (lazy removal).
My question is, does this sound feasible? I'm not so much interested on whether a developer wishes to implement this change, but whether it would be possible and what would be required.

It's not trivial, but it is doable in theory. Devil -- as it always is with distributed locking -- is in the details. I've seen a few too many projects design themselves into a corner and ultimately end up abandoned. (Paxos is hard to get right. Really, really, hard...)
Rather than try to reinvent the wheel here, I would look at leveraging another system that already does some of this. Zookeeper comes up frequently. It's a neat system, but I don't know of anyone who enjoys maintaining it. Redis comes close (I'd love to be able to use a hosted system here), but doesn't guarantee consistency -- which is usually a non-starter for filesystems.

If we're going to that level, then my thoughts on options are:

Use an existing Raft implementation, there's a few Python libraries available after doing a quick GitHub search. Since the library is independent of the transport, it should be possible to use SQS or the HTTP listener for a transport layer.
Use etcd from CoreOS as an established Raft server, and add options to YaS3fs for using etcd for locks. Since etcd supports TTLs on data, it would work for timing out locks. Additionally, other nodes could subscribe to events from etcd, allowing a blocking wait on a lock to be notified on as soon as the lock expires or is removed.

Thanks for the feedback so quickly. Naturally the devil is in the details.

Hadn't thought about etcd, but it does sound like an interesting approach. I discovered Raft last night as I started thinking about "How do folks do Paxos these days?", and I started reading the paper behind it (but then had to get back to Real Work™). John Ousterhout... ah, the good ol' Tcl days.
One constraint: depending on your design, your underlying locking mechanism may need to support fancier queries than simple key-value lookups. For example, client A has locked bytes 1000-2000 of file F1; now client B wants to lock bytes 500-1500 of file F1, but needs some way to discover the lock from A. To-end-of-file locks present an interesting edge case when the file is appended.
Deadlocks vs. timeouts are a potential issue. AFAIK, no filesystems try to avoid a deadlock (A locks F1; B locks F2; A then tries to lock F2; B then tries to lock F1). Today, the processes just hang. However, if we time these locks out, they might continue on -- with data corruption becoming a possibility here. I don't think I'd try to solve it -- just mark it as a "User Beware" issue if you set the lock timeout to a finite value, or keep the locks fresh though constant pinging ("Yes, client is still here, don't expire the lock").
Note that I'm not signing up to do this -- at least not right now. (Waaay too much on my Real Work plate.) But I'm more than happy to help guide folks who might be interested in playing with this.


fix(ngShow): Make ng-show consistent with ng-if

Consistent in terms of propagation. The expected behavior is that both
are evaluated from the outside in.
Background: http://stackoverflow.com/questions/25159464/how-to-make-angular-directives-evaluate-from-outside-in
All tests are passing.
I think this is pretty self-contained, but if you want me to, I can also expand on the concrete scenario where this unexpected behavior caused a bug in our application.

I would argue that evaluating during the pre-linking phase is any more intutitive than the post-linking phase (i.e. outside-in vs inside-out). In fact, the post-linking phase is the most commonly used (hence there are shortcuts for it, e.g. returning a post-linking function intead of a DDO or assigning a function to DDO's link property (instead of {pre: fn1, post: fn2})).
I am pretty sure this change would break as many usecases as it would fix Considering that (a) post-linking seems more common/intuitive, (b) it will be a breaking change, (c) it is very easy to overwrite ngShow/Hide or use a custom directive, I think it is better to leave things as is.
Closing as won't fix...


Functions to iterate slices

There might be need for functions that allow us to iterate slices in ndarray.

I've added map(i)_slice and iter(i)_slice functions. Please refer to the doc/


Can not register self-hosted codespace

Issue Type: Bug
Can not register self-hosted codespace
VS Code version: Code 1.48.1 (3dd905126b34dcd4de81fa624eb3a8cbe7485f13, 2020-08-19T17:12:13.244Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Xeon(R) CPU E3-1265L V2 @ 2.50GHz (8 x 2494)

GPU Status
2d_canvas: unavailable_softwareflash_3d: disabled_softwareflash_stage3d: disabled_softwareflash_stage3d_baseline: disabled_softwaregpu_compositing: disabled_softwaremultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: disabled_offrasterization: disabled_softwareskia_renderer: disabled_off_okvideo_decode: disabled_softwareviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: unavailable_softwarewebgl2: unavailable_software

Load (avg)
undefined

Memory (System)
15.84GB (13.21GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (4)

Extension
Author (truncated)
Version

vscode-pull-request-github
Git
0.19.0

azure-account
ms-
0.9.2

vsonline
ms-
1.0.2688

team
ms-
1.161.0

Hi there,
I tried all day. still doesn't work.

Hi @enhuichang, can you reopen this in the Codespaces repository? (https://github.com/microsoftdocs/vscodespaces). I'm unfortunately not able to transfer this issue


Training the segmentation model in your own data

Hello. I have been looking for a way to train this model with my own segmentation data, but I only find the way to train several predefined datasets. Do I have to convert my dataset to the style of one of those available in order to train? Or is there an easier way? My dataset is composed of input images and output binary images for each channel.
Thanks

That should be very similar to ADE20K dataset. Please check that out.


Vitest Refactor

Improved the GH workflows by updated and turning on builtin cache
Added Vitest packages, removed Jest/types/ts-jest & Jest config, replaced Jest with Vitest utilities
Added coverage scripts

Huh... weird that it failed. I will take a look tomorrow

Huh... weird that it failed. I will take a look tomorrow

Oh the Action doesnt have a builtin cache for "pnpm" I will fix that later.


Implement deployments(), observations() and media()

They are shortcuts for x$data$deployments, x$data$observations and x$data$media. We need to reexport them from camtrapdp.

Notice also that we should also reexport the accessor functions events() and taxa().

locations() has been added as well.

Done in PR #322


Fix function_cache garbage collection bug

Description
Fixes a bug that would crash the language server when a function node was part of the AST.
#5967 added a function cache to the QueryEngine. Garbage collection needed to be called on this otherwise it returns references to types that have been cleared from the other engines during garbage collection.
In the future, any other nodes that we decide to cache need to have GC applied to them or we will end up crashing the language server on the first key-pressed event.
I've also removed the gc_frequency setting and now run GC on each keystroke. Without doing this, the spans stored in the TokenMap and what was returned from the compiler were falling out of sync. This ensures that everything is always up to date and the correct spans are used. closes #5260
Finally, I've added a launch.json that allows for attaching lldb to a live running forc-lsp process. This was a pretty cruical step for tracking down this bug so would be nice to have it easily accessible for future debugging sessions.
Checklist

[x] I have linked to any relevant issues.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have updated the documentation where relevant (API docs, the reference, and the Sway book).

[ ] If my change requires substantial documentation changes, I have requested support from the DevRel team

[x] I have added tests that prove my fix is effective or that my feature works.
[x] I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
[x] I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
[x] I have requested a review from the relevant team or maintainers.

Thanks, i'm going to merge this PR and then follow up with the suggestions for the launch.json file in a follow up PR.


CommentCompilationWarning typings

What kind of change does this PR introduce?
CommentCompilationWarning typings

Did you add tests for your changes?
no

Does this PR introduce a breaking change?
no

What needs to be documented once your changes are merged?
no

Thanks