refactor identify backdoor to reduce code redundancy

A small refactoring of CausalIdentifier.identify_backdoor, which contained some duplicated code I though could be tidied up.
Only two methods for effect identification are now supported, and both of them propagate only to the identify_backdoor, The difference in logic is quite minor, in the sense that the one stops as soon as a valid adjustment set is found, and the other continues on to search the whole space.
The other difference was that exhaustive method was searching from the smallest adjustment set to the largest, while the other one was doing in reverse, from largest to smallest. It doesn't seem that important to me, but I could be wrong, so please let me know.
Tests are in general missing for causal identifiers, it would be a good idea to make some as a next step. :)

Thank you @vojavocni . This looks good to me, and a welcome addition! Adding it to master.
Totally agree on the lack of tests for identification. That is sorely needed, especially as the plan is to add more methods like the  complicated ID* algorithm. Would you like to contribute?

Thank you @vojavocni . This looks good to me, and a welcome addition! Adding it to master.
Totally agree on the lack of tests for identification. That is sorely needed, especially as the plan is to add more methods like the  complicated ID* algorithm. Would you like to contribute?

@all-contributors please add @vojavocni for code.

@all-contributors please add @vojavocni for code.

@amit-sharma Thanks, I would definitely like to contribute, both with the tests, and potentially with the IC* algorithm (please correct me if you meant something else) if no one is currently working on it!

@amit-sharma Thanks, I would definitely like to contribute, both with the tests, and potentially with the IC* algorithm (please correct me if you meant something else) if no one is currently working on it!

Hi @vojavocni are you still interested in adding tests for the identifiers? Let me know if there's anything I can do to facilitate.

Hey, @amit-sharma , definitely, I'm just low on bandwith for at least one more week to start working on it.
I will definitely contact you if I have any questions, thanks for offering  🙂

Hey @amit-sharma , I finally have some time to dedicate to this. I'll start working on the tests using some of the well known examples for each identification method. Just wanted to ask, do you maybe have any discord channel or similar to discuss developments for dowhy?

That's a great idea. Just created a discord channel for DoWhy. You can join using this link: https://discord.gg/cSBGb3vsZb happy to discuss any issues as you work on the tests.


Include Engine.ini in plugin package.

Without this change, the Engine.ini with our CoreRedirects doesn't get included in the plugin package. Which means a broken level blueprint in the Metadata sample and elsewhere.

Thanks for the pull request @kring!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.


Bump installer to 1.6.0

:heart:
@tianon @SvenDowideit @icecrime

tianon pushed 8b508882bf06c19e70d02a63e773a4b1d09fdbc5. closing.

PATIENCE :bow:

:heart:

will leave  this here as well just in case as a historical note


Fixes #3063. Stopped directly accessing dict keys to avoid KeyError

exception and provide sane default values.  Normalised representation keys provided as strings types to be returned as list types.
Unit tests were added to test the results of display only dictionaries and representation only dictionaries.

This is awesome, thanks! The code looks good at first glance; I'll load this branch on a vagrant box early next week, play around with it a little just to be sure, and then merge.
Special thanks for the tests!

Current coverage is 77.38% (diff: 100%)

Merging #3083 into master will decrease coverage by 0.02%

@@             master      #3083   diff @@
==========================================
  Files           430        430
  Lines         22063      22067     +4
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits          17076      17075     -1
- Misses         4987       4992     +5
  Partials          0          0

Diff Coverage
File Path

•••••••••• 100%
st2common/st2common/util/actionalias_matching.py

Powered by Codecov. Last update a6b0a60...589bcd2

Alright, tested the PR, works like a charm. Although I can see @dzimine wants to move fast and break things—he already merged it without waiting for testing 😛


[JENKINS-37815] Support buildWithParameters

JENKINS-37815

MatrixCombinationsParameterDefinitionTest.testBuildWithParameters failed as no combinations are activated when triggered with buildWithParameters.
https://jenkins.ci.cloudbees.com/job/plugins/job/matrix-combinations-plugin/70/
I'll add a commit to fix it.

Hi @ikedam can you explain how to select combination from Web API ? I don't find the doc.
I use to select combination like this (https://github.com/novafloss/jenkins-epo/blob/289b910a3cf402be04b5ea63a7ccea9ca309a053/jenkins_epo/jenkins.py#L396-L410)
        if self.combination_param:
            conf_index = len(str(self))+1
            confs = [
                c['name']
                for c in self._instance._data.get('activeConfigurations', [])
            ]
            not_built = [c[conf_index:] for c in contexts]
            data['parameter'].append({
                'name': self.combination_param,
                'values': [
                    'true' if c in not_built else 'false'
                    for c in confs
                ],
                'confs': confs,
            })

This produce a payload like
{"confs": ["AXE=value,NODE=jenkins-front"],
 "name": "COMBINATIONS",
 "values": ["true"]},

It works with 1.0.9. It's broken in 1.1.0.
How to do this now ?

Hi,
Is there any examples about how to use buildWithParameters?
I have tried hours but still can't figure out how to make it work.
Thanks!

Hi,
Is there any examples about how to use buildWithParameters?
I have tried hours but still can't figure out how to make it work.
Thanks!

I have figured it out, just apply the parameter filter as the matrix combinations parameter, e.g.
$ curl -X POST --user JENKINS_USER:JENINS_TOKEN http://localhost:8080/job/matrix-configuration-example/buildWithParameters\?paramFilter=param1%3D%3D%22A%22


The interceptor registry is too rigid

Instead of having an interceptor registry and binding it to the media engine, perhaps it would be enough to have a method that adds an interceptor to a given PC? This, in particular, would make it easy to share state between interceptors:
state := make([]stateful, 42);
i1 := &Interceptor1{state: state}
i2 := &Interceptor2{state: state}
AddInterceptor(pc, i1)
AddInterceptor(pc, i2)

Let me give another example.  Suppose you want to write an interceptor to generate sender/receiver reports (which is something we definitely want to see in Pion, since this functionality is essential both for lipsync and getting decent datarates).  The interceptor will need a data structure to keep information about time offsets and jitter statistics; this data structure is likely to be per-PC, and therefore a different instance will be used for each PC.  Thus, you'll most likely want to stick a separate interceptor on each PC, rather than sticking it in the MediaEngine.

Sorry for the slow response to this @jech !
You can do this with the API object today. You construct an API object and can pass it an Registry (a list of Interceptors). Those interceptors can be anything you want (and have state passed to their constructors as you wish).
@at-wat described this pattern pretty well here https://github.com/pion/webrtc/issues/1749#issuecomment-817498252


Extract serialized class?

Within Unity the code spins up a static class on load via:
return Resources.Load("Settings/ClassName") as ClassName
I've been trying to locate where this is hiding, but I can't seem to find it, even using Display All Assets.  I've tried other extractors as well without success.  Any idea where this might be hiding and how I might go about getting at it?

After some more digging, I think it may have a reference buried inside the ResourceManager asset.  Not sure how to go about digging further into that though to ultimately extract the serialized binary from its hiding place.


AnalyzeDocumentsChain

You can omit the base class implementation. Just one file where this works is enough, we'll highlight the interfaces a bit later.
You can use GPT-4 for initial implementation
Tests are encouraged but not required. It's better to do something minimal than nothing.

References:

https://api.python.langchain.com/en/latest/chains/langchain.chains.combine_documents.base.AnalyzeDocumentChain.html

actually it's already implemented, but not tested
https://github.com/tryAGI/LangChain/blob/main/src/libs/LangChain.Core/Chains/CombineDocuments/AnalyzeDocumentChain.cs


Remove systemd-related driver duplication

Good catch by @dgageot, I had forgotten to initialize the new instances of GenericSSHCommander where needed.
Everything should work swimmingly now.  Tested with GCE and it looks good on my end.
cc @docker/machine-maintainers
Signed-off-by: Nathan LeClaire<EMAIL_ADDRESS>

@SvenDowideit I see an issue with the documentation CI.  Not sure what's causing the failure.

cc also @londoncaling @moxiegirl in case you all might now what's up with the Jenkins docs CI thing.

@nathanleclaire @SvenDowideit is now implementing the documentation validation we've been using on our test repo out into the world.  This PR has no .md files so it should not have triggered the documentation build.
At the moment, only Sven has the means to stop this error. He's been pinged.

Thanks @moxiegirl

ouch. so the problem is that this PR isn't rebased to master, and Jenkins isn't telling the job the branch point that is valid - so in this PR's case, the git diff upstream/master..fc098 so it picked up the docs PR you merged for me as a change.

and resolved in https://jenkins.dockerproject.org/job/docs-machine-pr/32/console \o/ thank you for finding such a nice example of the problem - i'd hacked around it yesterday.

@SvenDowideit :+1:

LGTM


[TE] data completeness resource with endpoints for complete and incomplete dataset segments

working on ci fix #1176

There seems to be an unrelated test failure. The PR builds fine locally, but this is worth investigating:
testRefreshDataset(com.linkedin.thirdeye.autoload.pinot.metrics.AutoloadPinotMetricsServiceTest)  Time elapsed: 0.013 sec  <<< FAILURE!
java.lang.NullPointerException: null
at com.linkedin.thirdeye.autoload.pinot.metrics.AutoLoadPinotMetricsService.checkMetricChanges(AutoLoadPinotMetricsService.java:218)
at com.linkedin.thirdeye.autoload.pinot.metrics.AutoLoadPinotMetricsService.refreshOldDataset(AutoLoadPinotMetricsService.java:150)
at com.linkedin.thirdeye.autoload.pinot.metrics.AutoLoadPinotMetricsService.addPinotDataset(AutoLoadPinotMetricsService.java:105)
at com.linkedin.thirdeye.autoload.pinot.metrics.AutoloadPinotMetricsServiceTest.testRefreshDataset(AutoloadPinotMetricsServiceTest.java:87)

Hi Baolei, the endpoint is fully implemented. The pull request is held up
by an unrelated bug that has been plaguing our CI for some time now.
https://github.com/linkedin/pinot/pull/1159
On Thu, Mar 23, 2017 at 9:26 AM, Baolei Li<EMAIL_ADDRESS>wrote:

@bl44 commented on this pull request.
hi Alex, What's the current status of adding this endpoint? Need this to
automate the onboarding process. Thanks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/linkedin/pinot/pull/1159#pullrequestreview-28704974,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYQu3YEItBks8U-3NXyLf-vdkGES1sxfks5rop1LgaJpZM4Mf0wl
.


show history details

Make box transaction take up entire right sidebar with all details
closes #217

Also fixed 1. Magnifying glass too close to back arrow for box info


Update to node16

Summary of PR changes
Update from node12 to node16
PR Requirements

[x] For JavaScript actions, the action has been recompiled.

See the Recompiling section of the repository's README.md for more details.
This does not apply to Composite Run Steps actions unless a package.json is present and contains a build script.

[x] For major, minor, or breaking changes, at least one of the commit messages contains the appropriate +semver: keywords.

See the Incrementing the Version section of the repository's README.md for more details.

[x] The examples in the repository's README.md have been updated with the new version.

See the Incrementing the Version section of the repository's README.md for more details on how the version will be incremented.

[x] The action code does not contain sensitive information.

This was done in #16.  Thank you for your PR though!


libutp_3_4: unstable-2023-10-16 -> unstable-2023-11-14

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for libutp_3_4 is: uTorrent Transport Protocol library
meta.homepage for libutp_3_4 is: https://github.com/transmission/libutp
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found unstable-2023-11-14 in filename of file in /nix/store/3wpm56j2arv8ips2yw3v6w1nxw0i7wmy-libutp-unstable-2023-11-14

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath
libtransmission_4
libutp_3_4
transmission_4
transmission_4-gtk
transmission_4-qt

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/3wpm56j2arv8ips2yw3v6w1nxw0i7wmy-libutp-unstable-2023-11-14 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libutp_3_4 https://github.com/r-ryantm/nixpkgs/archive/196a660c6c882727954d979f9dcd9629eea56ed7.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/196a660c6c882727954d979f9dcd9629eea56ed7#libutp_3_4

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/3wpm56j2arv8ips2yw3v6w1nxw0i7wmy-libutp-unstable-2023-11-14
ls -la /nix/store/3wpm56j2arv8ips2yw3v6w1nxw0i7wmy-libutp-unstable-2023-11-14/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

5 packages built:

libtransmission_4
libutp_3_4
transmission_4
transmission_4-gtk
transmission_4-qt

Maintainer pings
cc @emilytrau for testing.

Result of nixpkgs-review pr 269404 run on aarch64-linux 1

9 packages built:

libtransmission_4
libtransmission_4.apparmor
libutp_3_4
transmission_4
transmission_4-gtk
transmission_4-gtk.apparmor
transmission_4-qt
transmission_4-qt.apparmor
transmission_4.apparmor


Update gas estimate for low intrinsic gas transactions #16

Resubmit for PR #16

Adds a test to run the transaction using the gas estimate returned and check it succeeds.
Previous behaviour estimated the cost of the transaction but never submitted it, and in this case it ran out of gas due to intrinsic gas differences between public and private gas costs.
Depends on https://github.com/jpmorganchase/quorum/pull/644

Also contains a few formatting changes and a .editorconfig file to keep formatting similar between user IDEs.

https://github.com/jpmorganchase/quorum/pull/644 has been merged


support bucklescript

I tried just aliasing ocamlc to bsc.exe on my PATH, but got an error about cmdliner looking for a config.h file.
It would be awesome to be able to use jbuilder with my web projects!

I thought bucklescript already came with a recommended ninja-based build system? /cc @bobzhang

Bucklescript has a build system, but it's much less flexible than jbuilder. If it's not too much work on your part, I'd really prefer to be able to use jbuilder to target web + native.

I see. I don't have the time to look at bucklescript myself, and can't promise either that rules for it would be integrated into jbuilder, as it is additional maintenance work.
What I would recommend is start by forking jbuilder and change it to use bucklescript rather than the OCaml compiler, then we could see what can be done from there. For instance what could be abstracted in jbuilder to either make it possible to use jbuilder to build bucklescript code, or make it easy to produce a specialized jbuilder for buckescript, etc...

:+1: on this. bsb, their build-system, is very young and yet horribly archaic in some ways.
If nothing else, I'm desperate for (inline_tests); but way more usefully, I want to build hybrid projects which only have small Node-facing and opt-facing modules, most of which are platform-agnostic, with only one build-system — not a Frankensteinian mish-mash of multiple build-systems cobbled together by hand for each project!
I have to admit, I'm a little confused: The Introduction says,

Dune is a build system for OCaml and Reason. It is not intended as a completely generic build system that is able to build any given project in any language.

Was the addition of Reason there a mistake? I can find no other mention of Reason or Bucklescript in the docs; only js_of_ocaml …
Anyway. I understand concerns about the maintenance burden, but I strongly feel like the OCaml/Reason community needs some collaboration / cohesiveness. (I mean, there's oasis and dune of course, whatever's going on with bsb itself, esy, bsb-native …) I really think giving such a first-class build tool first-class support for BS could really bridge that gap!

Reason the syntax is supported. Nothing special to do, it just works. Bucklescript is not reason. Bucklescript is not supported.

Personally, I'm not against supporting bucklescript in dune, but I don't want it to be some kind of competition between dune and bsb, because that would be a big waste of everybody's time.

Seems like a bit off-topic, but I'd posit that a healthy balance of collaboration and competition between open-source projects for mindshare could only benefit the end-user ¯_(ツ)_/¯
Anyway: coming back to this, it looks like I mis-read the response to the OP: you're perhaps not willing to support a BuckleScript extension itself, but you're interested in seeing what is required over here to support such an extension, and implementing/maintaining the subsequent extension-or-whatever-system?
Because forking the entire project, and them maintaining an entire fork, porting forward upstream changes, is hella untenable obviously — but a P.O.C. to motivate otherwise-weclome upstream changes to support a small, maintainable extension, is much more palatable! Seems in-line with the Dune 1.0 spirit, too. Do I understand your suggestion correctly?

Yes, basically at this point none of us has any idea what is required to support bucklescript, so we can't really make promises. If someones spends some time and produce a working prototype, even if it is not a generic solution, then we can look at the diff and assess the complexity to decide whether it is something we are happy to support or not in the long run or not.
In any case, just the initial support is not enought: if we support bucklescript, we need at least one person who uses bucklescript regularly in the dune team, so that we can assign bucklescript issues to this person. So someone has to be happy to take this role.

One issue that I'd like to see resolved in bucklescript itself before supporting it is the 4.02.3 issue. If supporting bucklescript means that we must support 4.02.3 forever, then I'm very much against the idea. In my opinion, we should wait and see that bucklescript is able to keep up with the compiler before spending time on this.

@diml can we assign this to @zploskey somehow?

I plan to start working on this over the weekend with a test project.

Don't hesitate to post your progress here :)

I'll be trying thing out here: https://github.com/zploskey/hello-esy-dune-bsb

The build.ninja file generated by BuckleScript for a simple "hello world" program may be informative. I haven't used ninja directly before but it reads somewhat similarly to a makefile.
bs_package_flags = -bs-package-name hello-esy-dune-bsb
src_root_dir = /home/zach/src/hello-esy-dune-bsb
bsc = /home/zach/src/hello-esy-dune-bsb/node_modules/bs-platform/lib/bsc.exe
bsdep = /home/zach/src/hello-esy-dune-bsb/node_modules/bs-platform/lib/bsb_helper.exe
warnings = -w -30-40+6+7+27+32..39+44+45+101+a -warn-error +a
bsc_flags = -bs-suffix -nostdlib -I '/home/zach/src/hello-esy-dune-bsb/node_modules/bs-platform/lib/ocaml' -bs-g -g -color always
ppx_flags =
bs_package_includes =
bs_package_dev_includes =
namespace =
bsb_dir_group = 0
bsc_lib_includes = -I bin
rule build_ast_and_module_sets
  command = ${bsc}  ${pp_flags} ${ppx_flags} ${warnings} ${bsc_flags} -c -o ${out} -bs-syntax-only -bs-binary-ast ${in}
  description = Building ${out}
build bin/hello.mlast : build_ast_and_module_sets $src_root_dir/bin/hello.ml
rule build_deps
  command = ${bsdep} ${namespace} -g ${bsb_dir_group} -MD ${in}
  description = Building ${out}
build bin/hello.mlast.d : build_deps bin/hello.mlast
rule build_cmj_cmi
  command = ${bsc} ${bs_package_flags} -bs-assume-no-mli -bs-no-builtin-ppx-ml -bs-no-implicit-include ${bs_package_includes} ${bsc_lib_includes} ${bsc_extra_includes} ${warnings} ${bsc_flags} -o ${out} -c  ${in} $postbuild
  depfile = ${in}.d
  description = Building ${out}
build bin/hello.cmj |  $src_root_dir/bin/hello.bs.js bin/hello.cmi : build_cmj_cmi bin/hello.mlast
  bs_package_flags = $bs_package_flags  -bs-package-output commonjs:bin
build build.ninja : phony  ||  bin/hello.mlast.d

For our purposes we will likely require using bsc in place of ocamlc and bsb-helper.exe (aliased to bsdep here) in place of ocamldep, or something like that. I'll be looking more closely at what differences there may be.
Thanks to @jaredly for explaining what is going on with the .mlast files. As we thought, these are the binary AST but with some extra data at the beginning expressing the number of dependency files to follow, then those file paths. The code in bsb that reads the AST is here:
https://github.com/BuckleScript/bucklescript/blob/3cf3133a4978df05e0b5fb351a1d2d18dce16c32/jscomp/depends/binary_ast.ml#L33-L43

I'll have some time to work on this over the weekend today and tomorrow. If anyone more familiar with how Dune is designed could sketch out how you might go about adding the a different back-end you might save me some time. I'm still not clear whether dune will need to learn how to deal with bsconfig.json files (possibly by calling bsb as a library) or if we want to add equivalent configuration to dune files as what BuckleScript adds. The latter seems nicer but a harder transition for people migrating from bsb configs.

I'm still not clear whether dune will need to learn how to deal with bsconfig.json files (possibly by calling bsb as a library)

I think having dune deal with bsconfig.json would be great. Building existing bucklescript projects with dune will immediately open up a large test suite for us, and dramatically reduce the entry barrier for this feature.
However, depending on bsb as a library doesn't seem so useful however. I'd expect that we'd convert the specification to something that is very similar to dune's stanzas, so it doesn't seem like reusing bsb would work.

or if we want to add equivalent configuration to dune files as what BuckleScript adds

If dune supports bucklescript, I'd expect it to be able to build existing libraries and executables using bucklescript. Of course, it's likely that we'll need a field for bucklescript specific configuration.

Hrmmm bsb as currently constituted has some differences from dune that will probably just overcomplicate things -- and honestly the reason I'd want dune w/ bucklescript is to get dune's package semantics instead of bsb's.
So let's get it working with bsc directly, and then maybe add on bsconfig.json support later.

Like, what would even be the benefit of having dune call bsb? bsb is a build tool, dune is a build tool... it would be like having dune call jenga. I don't think it makes sense.

dune calling out bsb is definitely ruled out. This would be impractical and wrong on many levels. However, I do think that dune would need a full understanding of bsconfig.json files.

I created a bucklescript branch here and started working on adding a way to set bsc flags in a dune file

Just curious, do we have a good understanding of the various bucklescript flags yet? Understanding these will be useful in making sure that there are no nasty surprises down the road.

Here's the help output from bsc from latest BS (4.0.6):
$ bsc --help
Usage: bsc <options> <files>
Options are:
  -bs-super-errors  Better error message combined with other tools
  -bs-re-out  Print compiler output in Reason syntax
  -bs-suffix  Set suffix to .bs.js
  -bs-no-implicit-include  Don't include current dir implicitly
  -bs-assume-has-mli  (internal) Assume mli always exist
  -bs-assume-no-mli  (internal) Don't lookup whether mli exist or not
  -bs-D  Define conditional variable e.g, -D DEBUG=true
  -bs-list-conditionals  List existing conditional variables
  -bs-binary-ast  Generate binary .mli_ast and ml_ast
  -bs-syntax-only  only check syntax
  -bs-no-bin-annot  disable binary annotations (by default on)
  -bs-eval  (experimental) Set the string to be evaluated, note this flag will be conflicted with -bs-main
  -bs-g  debug mode
  -bs-sort-imports  Sort the imports by lexical order so the output will be more stable (default false)
  -bs-no-sort-imports  No sort (see -bs-sort-imports)
  -bs-package-name  set package name, useful when you want to produce npm packages
  -bs-package-map  set package map, not only set package name but also use it as a namespace
  -bs-no-version-header  Don't print version header
  -bs-package-output  set npm-output-path: [opt_module]:path, for example: 'lib/cjs', 'amdjs:lib/amdjs', 'es6:lib/es6'
  -bs-no-warn-unimplemented-external  disable warnings on unimplmented c externals
  -bs-no-builtin-ppx-ml disable built-in ppx for ml files (internal use)
  -bs-no-builtin-ppx-mli disable built-in ppx for mli files (internal use)
  -bs-cross-module-opt enable cross module inlining(experimental), default(false)
  -bs-diagnose  More verbose output
  -bs-no-check-div-by-zero  unsafe mode, don't check div by zero and mod by zero
  -bs-noassertfalse  no code for assert false
  -bs-main  set the Main entry module in script mode, for example -bs-main Main
  -bs-I  add source dir search path in script mode
  -bs-files  Provide batch of files, the compiler will sort it before compiling
  -impl <file>  Compile <file> as a .ml file
  -intf <file>  Compile <file> as a .mli file
  - <file>  Treat <file> as a file name (even if it starts with `-')
  -absname  Show absolute filenames in error messages
  -annot  Save information in <filename>.annot
  -bin-annot  Save typedtree in <filename>.cmt
  -c  Compile only (do not link)
  -config  Print configuration values and exit
  -g  Save debugging information
  -i  Print inferred interface
  -I <dir>  Add <dir> to the list of include directories
  -color {auto|always|never}  Enable or disable colors in compiler messages
    The following settings are supported:
      auto    use heuristics to enable colors only if supported
      always  enable colors
      never   disable colors
    The default setting is 'auto', and the current heuristic
    checks that the TERM environment variable exists and is
    not empty or "dumb", and that isatty(stderr) holds.
  -intf-suffix <string>  Suffix for interface files (default: .mli)
  -keep-docs  Keep documentation strings in .cmi files
  -keep-locs  Keep locations in .cmi files
  -labels  Use commuting label mode
  -no-alias-deps  Do not record dependencies for module aliases
  -no-app-funct  Deactivate applicative functors
  -noassert  Do not compile assertion checks
  -nolabels  Ignore non-optional labels in types
  -nostdlib  Do not add default directory to the list of include directories
  -o <file>  Set output file name to <file>
  -open <module>  Opens the module <module> before typing
  -pp <command>  Pipe sources through preprocessor <command>
  -ppx <command>  Pipe abstract syntax trees through preprocessor <command>
  -principal  Check principality of type inference
  -rectypes  Allow arbitrary recursive types
  -safe-string  Make strings immutable
  -short-paths  Shorten paths in types
  -strict-sequence  Left-hand part of a sequence must have type unit
  -strict-formats  Reject invalid formats accepted by legacy implementations
     (Warning: Invalid formats may behave differently from
      previous OCaml versions, and will become always-rejected
      in future OCaml versions. You should use this flag
      to detect and fix invalid formats.)
  -unsafe  Do not compile bounds checking on array and string access
  -v  Print compiler version and location of standard library and exit
  -verbose  Print calls to external commands
  -version  Print version and exit
  -vnum  Print version number and exit
  -w <list>  Enable or disable warnings according to <list>:
        +<spec>   enable warnings in <spec>
        -<spec>   disable warnings in <spec>
        @<spec>   enable warnings in <spec> and treat them as errors
     <spec> can be:
        <num>             a single warning number
        <num1>..<num2>    a range of consecutive warning numbers
        <letter>          a predefined set
     default setting is "+a-4-6-7-9-27-29-32..39-41..42-44-45-48-50-102"
  -warn-error <list>  Enable or disable error status for warnings according
     to <list>.  See option -w for the syntax of <list>.
     Default setting is "-a"
  -warn-help  Show description of warning numbers
  -where  Print location of standard library and exit
  -color {auto|always|never}  Enable or disable colors in compiler messages
    The following settings are supported:
      auto    use heuristics to enable colors only if supported
      always  enable colors
      never   disable colors
    The default setting is 'auto', and the current heuristic
    checks that the TERM environment variable exists and is
    not empty or "dumb", and that isatty(stderr) holds.
  -nopervasives  (undocumented)
  -dsource  (undocumented)
  -dparsetree  (undocumented)
  -dtypedtree  (undocumented)
  -drawlambda  (undocumented)
  -dlambda  (undocumented)
  -help  Display this list of options
  --help  Display this list of options

Last time I tried using bsc directly it required bsconfig.json but that could be empty (I didn't look into why it requires though).

It doesn't seem to need a bsconfig.json to build a simple hello world in ocaml syntax with bsc hello.ml. With Reason syntax I think there is currently not a way to pass the information about it being reason syntax directly to bsc as flags. Running bsc hello.re gives don't know what to do with hello.re. Maybe this is something we can coordinate with BuckleScript on?

Oh I see. For Reason it applies the extra preprocessors. Well, we can do that too I suppose.
bs_package_flags = -bs-package-name hello-esy-dune-bsb
src_root_dir = /home/zach/src/hello-esy-dune-bsb
bsc = /home/zach/src/hello-esy-dune-bsb/node_modules/bs-platform/lib/bsc.exe
bsdep = /home/zach/src/hello-esy-dune-bsb/node_modules/bs-platform/lib/bsb_helper.exe
warnings = -w -30-40+6+7+27+32..39+44+45+101+a -warn-error +a
bsc_flags = -bs-suffix -nostdlib -I '/home/zach/src/hello-esy-dune-bsb/node_modules/bs-platform/lib/ocaml' -bs-g -g -color always
ppx_flags =
bs_package_includes =
bs_package_dev_includes =
namespace =
bsb_dir_group = 0
refmt = /home/zach/src/hello-esy-dune-bsb/node_modules/bs-platform/lib/refmt.exe
reason_react_jsx =
refmt_flags = --print binary
bsc_lib_includes = -I bin
rule build_ast_and_module_sets_from_re
  command = ${bsc} -pp "${refmt} ${refmt_flags}" ${reason_react_jsx}  ${ppx_flags} ${warnings} ${bsc_flags} -c -o ${out} -bs-syntax-only -bs-binary-ast -impl ${in}
  description = Building ${out}
build bin/rehello.mlast : build_ast_and_module_sets_from_re $src_root_dir/bin/rehello.re
rule build_deps
  command = ${bsdep} ${namespace} -g ${bsb_dir_group} -MD ${in}
  description = Building ${out}
build bin/rehello.mlast.d : build_deps bin/rehello.mlast
rule build_cmj_cmi
  command = ${bsc} ${bs_package_flags} -bs-assume-no-mli -bs-no-builtin-ppx-ml -bs-no-implicit-include ${bs_package_includes} ${bsc_lib_includes} ${bsc_extra_includes} ${warnings} ${bsc_flags} -o ${out} -c  ${in} $postbuild
  depfile = ${in}.d
  description = Building ${out}
build bin/rehello.cmj |  $src_root_dir/bin/rehello.bs.js bin/rehello.cmi : build_cmj_cmi bin/rehello.mlast
  bsc_flags = $bsc_flags -bs-re-out -bs-super-errors
  bs_package_flags = $bs_package_flags  -bs-package-output commonjs:bin
build build.ninja : phony  ||  bin/rehello.mlast.d

Running bsc hello.re gives don't know what to do with hello.re. Maybe this is something we can coordinate with BuckleScript on?

Dune's preprocessing pipeline should deal with that as it does now for Reason compiling with ocamlopt/ocamlc.

This is a cool idea, and I'd be curious to see how this works. One question I have is how / if Dune with bsc would compile dependencies? All bs-platform packages currently use bsb. Bsb sort of requires that everything use bsb in order for one bsb package to work. Building with Dune+bsc seems to put us in the same place. I really do like how right now Dune+jsoo can use arbitrary dependencies regardless of how they were compiled and regardless of which build systems they use. I wonder if it would be possible to use jsoo for dependencies when you can't control which build system they use, and then use Dune+bsc for the top level project.

Full support for bucklescript would include support for interpreting bsconfig.json. To make external packages work with this setup, I think we should simply install external dependencies with the full source and build them on demand. This will only make dune dependencies available through the bucklescript target, but it is acceptable to provide new features that are dune only.

I wonder if it would be possible to use jsoo for dependencies when you can't control which build system they use, and then use Dune+bsc for the top level project.

Which cmi's would the bucklescript project use? I think you still need bucklescript to generate the cmi for w/e library it plans to use.

@jordwalke jsoo & bsc have incompatible runtime representations, so there would have to be a serialization/interop layer between them if they are to be used together :/
I think "making dune able to build all bucklescript projects (e.g. support bsconfig.json)" is a way bigger task than just "make dune able to use bsc as the compiler instead of jsoo or ocamlc". So maybe it makes sense to tackle the simpler one first?

I think "making dune able to build all bucklescript projects (e.g. support bsconfig.json)" is a way bigger task than just "make dune able to use bsc as the compiler instead of jsoo or ocamlc". So maybe it makes sense to tackle the simpler one first?

That's my impression as well. Being able to build a project using dune files with bsc seems like a very good first goal.

any new about this ? the ocaml/dune#bucklescript bucklescript branch seems a bit outdated. How can I help ?

:+1: here — I have some free-time at the moment to dedicate to something BuckleScript-related. @abate, if you figure out what's necessary, and want to tag somebody in, catch me in Discord?

I don't really know how the bucklescript compilation pipeline works, but I'm assuming that it is fairly similar to OCaml.
As a result, I suggest to proceed as follow:

setup an environment where you have both ocamlc and bsc in your path
do: cp $(which bsc) $(which ocaml). i.e. overwrite ocamlc by bsc. It's important to overwrite the ocamlc binary in place as dune expect to find all the ocaml* tools in the same directory
try to build a simple hello world program in bytecode (i.e. build prog.bc rather than prog.exe) without preprocessing and without using libraries
do whatever changes necessary in dune to make it work
try to define a simple library and use it in the executable
do whatever changes necessary in dune to make it work

By looking at the diff, we should understand better how all this work and how to properly integrate this feature into dune.

I played a bit with this idea and followed your plan :
First I had to copy the node_modules/lib directory in my _opam directory and add copy the Makefile.config in _opam/lib/ocaml/Makefile.config
Then I linked the bsc file pointing to  _opam/lib/node_modules/bs-platform/lib/bsc and on top of my ocamlc. In the end I created a hello_world.ml and dune file and  run dune build hello_world.exe --verbose
Running[3]: (cd _build/default && _opam/bin/ocamlc.opt -w @a-4-29-40-41-42-44-45-48-58-59-60-40 -strict-sequence -strict-formats -short-paths -keep-locs -g -bin-annot -I .hello_world.eobjs/byte -no-alias-deps -o .hello_world.eobjs/byte/hello_world.cmo -c -impl hello_world.ml)
Rule failed to generate the following targets:
- .hello_world.eobjs/byte/hello_world.cmo

The hello_world.js file is there, but I get an error as the bsc compiler doesn't know how to generate a cmo file and dune complains. Adding a library stanza to dune yield a similar result with the command :
 dune build hello.cma --verbose , and the js artifact is correctly generated. I tried to add another module to test the dependency resolution, but this didn't work out of the box.
Judging from these simple experiments, I guess we need to add a new Js mode to dune to make it select the correct compiler and to stop throwing errors for cm? files that bsc is not going to generate.
But I'm not sure what should be changed. Ideally, calling dune with dune build hello.bsc.js I would expect dune to call bsc instead of ocamlc and picking up the correct makefile. I'm not sure how to use ocamldep or bsb .
Ideas ?

Good work @abate and your initiative is appreciated.
To proceed with the experiment, perhaps we should try to convince dune that .cmo and .cmj files serve the same purpose. One way we can do that is by replacing cmo with cmj in dune. Another way is to add a .cmj -> .cmo copying rule when invoking the compiler from dune.

One way we can do that is by replacing cmo with cmj in dune

That's indeed what I had in mind for the experiment.

I started experimenting here : https://github.com/abate/dune/commit/47ff78a4cdf936c256d96a8279191cc0d28d63b0
To set everything up you should :
yarn add bs-platform --modules-folder $OPAM_SWITCH_PREFIX/lib/node_modules
ln -s $OPAM_SWITCH_PREFIX/lib/node_modules/bs-platform/lib/bsc $OPAM_SWITCH_PREFIX/bin/bsc
cp $OPAM_SWITCH_PREFIX/lib/ocaml/Makefile.config $OPAM_SWITCH_PREFIX/lib/node_modules/bs-platform/lib/ocaml/

This way setting up the env variable DUNE_BSC=1, dune will use bsc instead of ocamlc. Now I've tried to attack this cmj -> cmo problem, but it's not that easy.
Maybe somebody can have a look at what I've done and tell me if there is an easier way of doing it ?

Seems like what you're trying to do is to add proper support for bucklescript in dune. That's definitely the right way to go eventually, but I think that initially what we had in mind was far simpler, just sed s/cmo/cmj/g and then see what breaks.

I tried, but the very nature of dune, doesn't allow for this kind of monkey-patching. There are many hidden dependencies, and in the end it was just easier for me to hack in the code and to try to figure out how to untangle these bundle. But it seems I'm missing something reg extensions, and I'm not sure if adding a new kind is the right way to go. Maybe poeple with a bit more expertise in the dune code can have a quick look and point me in the right direction ?

There's also a bit of a complication with preprocessing. I believe that we'll need some sort of cross compilation here as I'm not sure if we can make our preprocessor work in bucklescript. To hack around this, we might need to build bucklescript dune with the installed version. This will make sure the native pp is used

@rgrinberg since bucklescript seems to produce a different set of artifacts, I was thinking that we would store them in a separate directory, for instance in .<lib>.objs/bs. Although, that would only work well if the cmi files are compatible between ocamlc and bsc.

the .cmi files are compatible, so that should work :)

Great :)

As of bsconfig.json, @andreypopp isn't the game plan to migrate that to esy's package.json and have esy manage the dependencies, leaving only actual building phase to dune?

Has there been any progress on this? We're thinking of building some sort of abstraction library (in ReasonML) that is supposed to work in both BuckleScript and OCaml native(esy,dune) and so far no clues on how to build that from same codebase.
Interestingly, BuckleScript has an issue to support limited subset of dune files.
@bobzhang @chenglou do you guys have any vision to share on what should be the best way to build cross-platform OCaml/Reason projects targeting BuckleScript on the JS side?

No progress so far. Nobody in the current dune team is qualified to maintain such a project and nobody from the community has stepped up.

Supporting dune files in BuckleScript is a really interesting idea!
FTR, the original goal of Jbuilder was to provide a second implementation of a tool that read jbuild files and interpret them to build OCaml projects. The first implementation was Jenga which wasn't suitable for the opensource world, and in particular the opam world. It succeeded because the jbuild language, which has now evolved into the dune language sits just at the right place: it's simple and high-level enough to make it doable to have several implementations of it, but it is complete enough to describe the majority of projects.

@diml thanks!
This is more or less the plan that I had in mind:
1st stage: make something work

[x] Call bsc with regular modules
[x] Call bsc with modules in Reason syntax
[x] Manage to have bsc put the resulting .js files in build folder (right now it seems to be working by adding bsconfig.json as dependency, but I hope it can be done in a more robust way in the future)
[ ] Tweak dune so that executable generation rules don't fail (right now it tries to call ocamlc.opt and pass the resulting cmj files, which fails). With bsc we actually don't need for these rules to do anything, as webpack (or other js bundlers) are generally the ones responsible of "linking" the .js files that already exist from the individual modules (unlike jsoo).

2nd stage: libraries

[ ] Tweak dune so that library rules to generate cma don't fail (right now it tries to call ocamlc.opt and pass the resulting cmj files, which fails).
[ ] Pass package name to bsc as -bs-package-name (right now it's hard coded)
[ ] Fix any issues with wrapped libraries

3rd stage: ppxs

[ ] Try to set an example with just -ppx flag (which all BuckleScript ppxs use now)
[ ] Investigate more modern approaches to ppx (ppxlib mainly)

Let me know when you feel like this is working as you'd like. We can then discuss how we can integrate this work so that it's easier to maintain moving forward.

Having even a hacky proof of concept of these 3 stages will take a while. Maybe we could discuss integration after stage 2 (libraries) is done? I consider that would be a pretty interesting milestone, as it would allow to create examples with reason-react or other libraries. But I am not sure if it's realistic.

That seems good to me, stage 2 seems like an interesting milestone indeed. Good continuation on this project! :)

I appreciate all the work going on here, I created a hybrid project in 2017 and running two build systems was certainly interesting 😅
I do think that some coordination with @bobzhang will be necessary, however, as bsc is starting to angle towards diverging from ocamlc as Jared found out last year:
https://github.com/jaredly/reason-language-server/issues/320#issuecomment-524629540
That specific case was rolled back but I think bob’s comments about having separate handling for bsc versus ocamlc will apply here too.

My recent research:
The differences between bsc and ocamlc are easy to workaround. But that is using (modes byte) if you try to use (modes byte js) then it's not going to work, as JSOO only needs the output, while BS requires the full source to compile.
So compiling with BS must be done as a cross compiler, it solves the problem regarding external dependencies. It works, but there is a huge problem it will try to compile any C file, instead of using javascript_files from JSOO.
So probably we need a mode inside dune for that, which will be a lot more similar to (modes byte) then (modes byte js).

Would you like to take over this project? It seems like it would solve problems for many people. A non-invasive (code wise) cross compilation setup for bucklescript is certainly something we’d love to upstream.
On May 28, 2020, 6:39 PM -0700, EduardoRFS<EMAIL_ADDRESS>wrote:

My recent research:
The differences between bsc and ocamlc are easy to workaround. But that is using (modes byte) if you try to use (modes byte js) then it's not going to work, as JSOO only needs the output, while BS requires the full source to compile.
So compiling with BS must be done as a cross compiler, it solves the problem regarding external dependencies. It works, but there is a huge problem it will try to compile any C file, instead of using javascript_files from JSOO.
So probably we need a mode inside dune for that, which will be a lot more similar to (modes byte) then (modes byte js).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

It is funny because without consultation we have worked on this issue at the same time: Here is my contribution. https://github.com/Et7f3/dune-bs. My idea require 0 work for dune but it isn't perfect. So a mix of our work seem to solve the issue. My idea: I expose ocaml{c,c.opt} binary that take arguments and send to bsc/real ocamlc depending on the target. If it detect .ppx then it run the real otherwise it run bsc. I hit issue with ppx. hopefully refmt allow to convert ppx-ed source to ocaml code that BuckleScript understand. While BS can keep with upstream this hack is required. I might expose a refmt binary that drop the --print binary but then it is less optimal.

You two can both take charge. It's even better this way.

My idea: I expose ocaml{c,c.opt} binary that take arguments and send to bsc/real ocamlc depending on the target. If it detect .ppx then it run the real otherwise it run bsc.

I don't think this is necessary with cross compilation. In cross compilation, we build & run the ppx in the host context anyway.

I hit issue with ppx. hopefully refmt allow to convert ppx-ed source to ocaml code that BuckleScript understand.

Why wouldn't it? Is it a different parsetree than 4.06?

I don't think this is necessary with cross compilation. In cross compilation, we build & run the ppx in the host context anyway.

my idea was 0-work for dune maintainer... That's why I though to this hack. But yeah with x-compil we can get better result.

Why wouldn't it? Is it a different parsetree than 4.06?

The magic number are different. I could have try ocaml 4.06 with a old commit of dune. I couldn't use esy override of @prometheansacrifice because I hit UNIX.XDEV error. But to call refmt it is a 5 lines patch so quicker to do :)

I'm closing this issue as wontfix. Bucklescript is diverging far enough from OCaml that it does not make much sense to keep up with it.

For folks following this issue:

Dune now integrates well melange
The integration is documented in the dune docs here
Melange + dune allow most, if not all, workflows that folks used in BuckleScript

specifically, it supports modern JS workflows and tooling, included (but not limited to) Tailwind, React Server Components, Next.js, monorepos, etc.


Allow Admins to see what Programs a Question is used in.

There is no way to know which Programs a Question is used in currently.

this is a repeat with #239 but open to keeping either due to lack of details

I think Brett already built this into staging?

Correct. This was completed as part of #2788.


Add a plutus executable

This adds a plutus executable with two subcommands: typecheck and evaluate. The input can be passed either as a file or as stdin.
I've also removed run-ck, since plutus evaluate subsumes it, but I could leave it if we wanted.

Docs updated.

Should we call it plutus rather than plutus-core? We'll have plutus-tx later.

I had been thinking that plutus-tx isn't going to have an executable, since you can only really use it via Haskell. I'd also like a relatively short name - how about plc?

plc is fine to me.

I've renamed it (and updated the docs again!).


The inference results based on vllm qwen7B also lead to a decrease in accuracy

Mainly due to significant differences from the original qwen7B answer, we hope to resolve this issue

Yes, I also encountered this problem

Closing as duplicate of #2950


Unable to use Horizontal Pod Auto Scaling (HPA) for Pods in Dev Spaces enabled namespaces

The containers injected (e.g. devspaces-proxy) to support Dev Spaces do not have requests/limits set which break the HPA.
Here's a suggestion to add to troubleshooting topics to help others that may run into this.   It's possible that having a topic about overall environment design to support a range of testing types/goals might be helpful.
Error
When enabling Horizontal Pod Auto Scaling for a Pod in a namespaces with Dev Spaces enabled. Error:  the HPA was unable to compute the replica count: missing request for cpu
Reason
As noted in the docs, “The Kubernetes webhook admission server is used to inject pods with three containers during deployment for instrumentation: a devspaces-proxy container, a devspaces-proxy-init container, and a devspaces-build container.”  Those injected containers do not have resource requests/limits defined, which disables the use of HPA for the Pod.
Try
If you need to use the same AKS cluster for both Dev Spaces debugging and load/scale testing, then load/scale testing should be done in a separate namespaces that does not have Dev Spaces enabled.

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

ID: 5567ba71-654f-3a49-c6b5-c47df5b8f8b9
Version Independent ID: cf86a395-864a-ac30-2480-adbe62a08ae4
Content: Troubleshooting - Azure Dev Spaces
Content Source: articles/dev-spaces/troubleshooting.md
Service: azure-dev-spaces
GitHub Login: @zr-msft
Microsoft Alias: zarhoads

@dave-read Thanks for the feedback! This detail would certainly be helpful to find in the Troubleshooting doc. I've assigned the issue to the content author to evaluate and update as appropriate.

@dave-read Thank you for the feedback!
I have incorporated your suggestion into the docs and it should be published soon.
#please-close

@zr-msft Thanks for the update!


lots of failed WebSocket connections

likely something misconfigured with nginx

@JasonLing95 did we have something similar with Ark and did we have a fix for it?

@jethror1 that's normal. It happens on Genetics Ark as well. If you switch to Firefox, the thing disappears. Emailed Tony before about this but didn't get any solution


Flowchart: wrong escaping in non-html mode

Describe the bug
In a flowchart diagram, when working in a non-html mode, =,<,> symbols are translated into their html form (e.g. &equals)
To Reproduce
Steps to reproduce the behavior:
The following simple diagram:
graph TD
A["a=b"]
with this configuration:
{
"theme": "default",
"flowchart": {
"htmlLabels": false
}
}
results with a square containing the following text:
a & equals; b
Expected behavior
a square with the label a=b
Screenshots
https://mermaidjs.github.io/mermaid-live-editor/#/view/eyJjb2RlIjoiZ3JhcGggVERcbkFbYT1iXSAiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCIsImZsb3djaGFydCI6eyJodG1sTGFiZWxzIjpmYWxzZX19fQ

If you add securityLevel: loose to your config, it works.
I dont think that this should work and I would classify this as a Bug:
Working:

Not Working:


Validate empty string or required string

Hey @deceive3w ,
This can currently be handled by https://github.com/envoyproxy/protoc-gen-validate#strings min_bytes equal to 1. Which ensures the string has at least one particular byte. Did you want something more, or will that work for you?


Players not able to join game on chrome

Issue is because Chrome stores cache differently than Firefox, and credentials for the session are not being saved. TODO


fix: base64 string support for v3 version of the plugin

Pull request checklist
Please check if your PR fulfills the following requirements:

[x] The changes have been tested successfully.

Fixes #68 for v3 (Capacitor v5) version of the plugin

@shiv19 Thank you! You don't have to do that next time. We only support the latest Capacitor version.


Share Patches via QR Code

This would be a nice (non essential) addition for people who use the app on two devices. Often times I develop a patch on my iPhone, but later want to use it on my iPad, the current transfer method takes a few more taps than I'd like it to.

Thanks for the idea. We'll add it to the list of ideas.


Fix find locale file with different size (en, en-us, ...)

Added new function tryFindLocale() with different size (en, en-us, ...)

nice bugfix, waiting for merge

@SAP55 thanks for your contribution.


Github advisories

Title of ticket:
Description
https://github.com/advisories/GHSA-6h5x-7c5m-7cr7/dependabot?query=user:bcgov
DOD

[ ] Check FOI-Flow
[x] Check FOI-Requests
[x] Discuss recommendations for fixing

@mpilchar - don't close this ticket. I am yet to push the changes of FOI-Flow app


feat: use node 20, 16 is deprecated

Hi @hkusu Any chance we could merge this and release 🥺

See this comment, https://github.com/hkusu/s3-upload-action/issues/22#issuecomment-2049334698

See this comment: #22 (comment)

I saw that and it's a good workaround, thank you. I'd still prefer to use a tagged version 😅

Any date for release this upgrade?


Request to add committers

Provided they're willing, I'd like to propose the following candidates for rebar/rebar write permissions based on their contribution history.

Luis Rascão (@lrascao)
Tomas Abrahamsson (@tomas-abrahamsson)
David Kubecka (@kejv)

+1

Yeah, as much as I'd like to be able to put more time in rebar 2.x, I already struggle to find enough time to do work on rebar3.
As long as the overall objective doesn't change (rebar3 is expected to do the lion's share of new feature development, rebar 2.x cannot break compatibility because rebar3 is technically rebar 3.0.0, and so on) I would be happy to get more hands maintaining rebar 2.x.

+1, willing and able

Pulling in some owners of the rebar org: @Vagabond @jaredmorrow

+1
On Friday, October 2, 2015, Tristan Sloughter<EMAIL_ADDRESS>wrote:

Pulling in some owners of the rebar org: @Vagabond
https://github.com/Vagabond @jaredmorrow
https://github.com/jaredmorrow
—
Reply to this email directly or view it on GitHub
https://github.com/rebar/rebar/issues/547#issuecomment-145012799.

@jaredmorrow or @Vagabond can you do the addition? I can't create a new team.

Sorry, just got back from a long meetup last night.  I added an additional team with them being invited.

Hi all,
sorry for late reply, I have just came back from vacation.
I am certainly willing to help (and hopefully also able timewise).
Regards,
David
---------- Původní zpráva ----------
Od: Tuncer Ayaz<EMAIL_ADDRESS>Komu: rebar/rebar<EMAIL_ADDRESS>Datum: 1. 10. 2015 21:24:55
Předmět: [rebar] Request to add committers (#547)
"
Provided they're willing, I'd like to propose the following candidates for
rebar/rebar write permissions based on their contribution history.

Luis Rascão (@lrascao(https://github.com/lrascao))
Tomas Abrahamsson (@tomas-abrahamsson
(https://github.com/tomas-abrahamsson))
David Kubecka (@kejv(https://github.com/kejv))

—
Reply to this email directly or view it on GitHub
(https://github.com/rebar/rebar/issues/547).
"=

@jaredmorrow, ping re: @kejv?

@kejv, if I understand @jaredmorrow correctly, you should be already invited.

Yes, he's indeed been invited.

@jaredmorrow  Hmm, pardon me but I can't see the invitation you are talking about, neither in my github account nor in my mail box. Can you please double check that I was reaaly invited, or direct to the place where I can accept the invitation?

@kejv I just doubled checked and updated the invite.  I don't know how to get rid of the invite and do it again, but it sure seems like it is pending.

I think it's safe to close this as resolved by now.


[BUG] support google cloud storage path in hugeCTR backend

When serving models in cloud, users typically leverage a cloud storage path like gs://GCS_bucket/models/deepfm/1/deepfm0_sparse_0.model
For example, the config.pbtxt will contains
parameters {
  key: "config"
  value {
    string_value: "gs://[bucket_name]/models/deepfm/1/deepfm.json"
  }
}

Current hugeCTR backend will report I1030 21:59:03.044715 167 hugectr.cc:282] Fail to open Parameter Server Configuration, please check whether the file path is correct

Sorry for the late rely. Currently HugeCTR Backend only supports reading model files and configuration files from the local disk to initialize the PS. In later versions, we will gradually support reading configuration files and model files from kafka and the cloud.

Adding @sohn21c could we track this as a FEA?


Minor cleanup in bindNamespaceExportDeclaration

Broken out from #27281

There's a mix of if-else and also early returns. This makes the three cases look different, but they're actually all the same -- file a diagnostic and return.
They also all add the diagnostic in the same way and are distinguished only by the name. So we can put the diagnostic-adding code in one place.

@sandersn good to merge?


Clarifying documentation for crate user

@christianbader All set. Reworded it accordingly. It it purely just to test. The tests did not run any other way.


MC Geofence violation not easy to resolve

Describe problem solved by the proposed feature
When a Geofence is violated the Vehicle will enter Hold Mode (if configured accordingly). It is not possible to back out of the violation by reversing the flight path, since the Flight Mode has changed automatically. This is not as most Users will perceive the function "Hold" on Geofence Violation, as all known Consumer Products would allow to revers the flight path in order to resolve the Geofence violation.
Only current solution is to switch to a Manual Flight Mode (Stabilized) and reverse. As Geofences sometimes act as maximum Distance keepers the Drone might not be easy to recognize and therefore Switching to a Manual Mode for not so experienced Pilots who might already be stressed by the sudden Mode Switch, could crash the vehicle.
This is the current behaviour as of PX4 1.9
Describe your preferred solution
Instead of Switching to a different Flight Mode, I would assume that the PosCtl Controller would switch to Position Hold Mode and not allow further progress, as long as the commanded Flight Vector would continue to further violate the Geofence. When Pilot Input Vector points away from the Geofence the PosHold Controller shall allow the movement by switching to velocity control and therefore resolve the Geofence situation.
--> This is IMHO the normal Behaviour of most (Consumer?) Drones.
This is a duplicate of #9789 as it was automatically Closed by the Bot.

Just to note, by switching from a PosCtl Flight Mode selection to another combination which also enables PosCtl the currenty logic shortly allows the PosCtl Controller to take over. With this, it is possible to violate the Geofence further. In the Example below it was possible to exceed the Geofence by 20m (120m above Start point, despite Geofence ceiling being set to 100m). As I first did not understand what is happening as the Aircraft also performed various uncommanded Yaw Movements (this should be addressed with 1.9.1 though).

Link to log: https://logs.px4.io/plot_app?log=dca11486-c01f-4f20-b364-c8e87852325f

I think the goal of #12057 was to solve this problem.

I guess #12057 did not make it into 1.9.0? I',m going to try 1.9.1 then.

I agree that the a nicer solution would be to simulate a virtual wall similarly to the "Collision prevention" logic. However, the Geofence logic is currently implemented in Navigator and has only access to the fence geometry and the current position of the vehicle: it's a high level class that return a true/false result.
To have that "virtual wall" behavior, we would need to re-implement the logic in a library used in the FlightTasks that have access to stick inputs. Furthermore, since the geofence can be made from any arbitrary polygon and circle checking for the collision is a smart and efficient way will require some effort.

I was afraid, that the solution might be somewhat more complicated as soon as it comes to random Geofence Polygons instead of the simple cylindrical Geofence. However I think on the long run in order not to confuse or scare the Pilot, a smoother solution should be found.
How shall we proceed with this?

@tops4u I see a simple solution that could be implemented without changing the architecture: The navigator continuously stores the current position if in the fence, drives back to that last position as soon as the fence is violated and give the control back to the pilot. This is kind of a "Mario Kart" approach and is the easiest minimal change I see to create that virtual wall without moving the whole logic to FlightTask.


Let user choose padding

Hi,
Actually library, store kmer in an array of u64 it could be nice to let user choose the type of array. I work with very short kmer, use and u64 to store it, would have a significant cost.

Rust-debruijn has an implementation with integers of various sizes: https://github.com/10XGenomics/rust-debruijn/blob/master/src/kmer.rs

I like this idea, though I don't have a good sense of how much it will complexify the code.  In particular, will we have to have many specialize implementations to make use of word-size operations when the backing array is using word-sized elements, with fallbacks to slower implementations for smaller types, etc.?

@rob-p yes it does make some code paths a bit more complicated. See the impls of VarIntKmer which supports kmers that are smaller than the bitwidth of the integer, vs IntKmer which requires that the kmer fills the integer.  There's usually a handful of extra shifts/mask to maintain the invariants of VarIntKmer, but it's not too crazy. There'd also be some overhead to deal with an array of smaller ints rather than a single in an array-backed kmer impl.


Save-Module fails on WS2012R2 + WMF5 + Latest PSGet/PM

Some environments with the setup in the title fail. Others are unable to repro.
Repro
Save-Module on certain WS2012R2 + WMF5 + Latest PSGet/PM environments fails. AdministratorRightsNeededOrSpecifyCurrentUserScope appears to be in PSGet, though this seems to be related to contract issues between PSGet and PM, possibly due to a bad previous installation.
Steps

Install WMF for PS4 on Server 2012 R2
Save-Module PowerShellGet
Install latest PSGet and PackageManagement (this happens on 1.1.4 and 1.1.3 at least)
save-module packagemanagement -requiredversion <IP_ADDRESS> -path $somePath (also tried xjea)

Expected results
Package is saved or a real error is shown
Actual results
WARNING: The property 'AdministratorRightsNeededOrSpecifyCurrentUserScope' cannot be found on this object. Verify that
the property exists.
PackageManagement\Save-Package : Unable to save the module 'PackageManagement'.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\PSModule.psm1:1616 char:21

Spending some time to look into this

Mani mentioned it's just the EN-US folder being left behind. Using this to track whenever the EN-US folder is added back.


Second attempt at default and whitelist Python versions

Support a configurable set of default and allowed Python versions.

Add the PythonDefaultsVersions class which maintains the default Python 2
and 3 versions.  This allows a product to say it supports just '2' or '3'
and it will automatically get the Python 2.x or 3.x default version.
This class also maintains a collection of allowed Major.Minor versions,
and implements a normalize() method that enforces this set.  If a selected
Python version falls outside this set, a GradleException is thrown.

The PythonDetails class is augmented to allow for setting and getting the
PythonDefaultsVersions instance, and it calls the normalize() method in
its setPythonVersion() method.  This completes the enforcement.

Also fix a documentation typo, and describe how to use the new default and
allowed Python versions feature.

This replaces #150.  It has been squashed against current master and the commit message has been updated.


Graticule not displaying properly on wrapped map

The graticule is only displayed on the first/centered version of a wrapped map:
http://jsfiddle.net/g3jq71op/1/

Your fiddle shows nothing. You're requesting http (ol.js) over https.

Is that working now?

The fiddle just adds a graticule to a map. Nothing special.
var map = new ol.Map({
target: 'map',
layers: [
new ol.layer.Tile({
source: new ol.source.MapQuest({layer: 'osm'})
})
],
view: new ol.View({
center: ol.proj.transform(
[-110, 45], 'EPSG:4326', 'EPSG:3857'),
zoom: 3
})
});
var graticule = new ol.Graticule({map: map});

I guess that is just what is expected. Just like the official example.

I'm wondering how difficult this would be to implement.

There is actually a bug with the official example.
If you click on one of the wrapped maps then the graticule switches to that map, however it does not display properly at any zoom level except for the 0 or perhaps 1. Any other zoom level and it will either fail to display the meridians, the parallels, or both, depending on how far you have panned away from the center map, and how far you have zoomed in.
I think it's fine for the graticule to only display over the last wrapped map that was clicked, however it is currently in a broken state.

I was able to get the correct behavior by modifying ol.Graticule.prototype.addMeridian and ol.Graticule.prototype.addParallel to have them not check if the current extent intersects the latitude or longitude (in other words I commented out the if check surrounded the line that adds the meridians and parallels to their repsective arrays).
This might have performance implications by drawing lines that are  unseen.
I am guessing the proper fix is to either modify ol.extent.intersects to handle a wrapped extent, or to pass the wrapped extent.

I have what I think is the proper fix:
In on.Graticule.prototype.handlePostCompose_, on the third line of the function, change:
"var extent = frameState.extent;"
to
"var extent = vectorContext.extent_;"
The graticule will then draw properly on the last map that you clicked on.

Created pull request:
https://github.com/openlayers/ol3/pull/3858

Fixed with #3858

I wouldn't say this was fixed by that pull request. It improved the display of the graticule when wrapping is enabled, but the graticule is still only displayed on the first/centred version of a wrapped map.

You are right. We have an open issue for that, and are accepting pull requests: #4308.


InitialSlide param breaks slideshow

Setting an InitialSlide param breaks the slideshow. Will set up a PR in a bit to fix this issue. It's an issue with slick issue [#396] (https://github.com/kenwheeler/slick/issues/396).

Have set up a PR at #60 please review. Thanks.

I ran into this just now. I fixed it by doing parseInt when setting the setting on slick.
ie: initialSlide: parseInt(scope.initialSlide) || 0,


Add some resiliency

Some errors happen when the data isn't exactly as you'd want it, ignore things that don't match

Thanks!

woo hoo, thanks jack


Visualizing the result and evaluation

Hi,
I'm trying to build the model on tensorrec, it will be very great if I can get a deeper understanding of the model.
Will it be possible to have some visualization of the learning rate, or loss funciton?
Also, if I want to know the rank of items for certain user, is there any function I can use to extract the information? Or I will need to use the predict_rank to get all ranks for all users and map back to userid?
Thank you so much,
Kara

Hi,
for the predict_rank, since the user_features are transformed into index and tuples in the input. Would you please give me any suggestion to map and retrieve the user_features based on the original text values?
Thank you so much,
Kara

Hi,
I can't call the function in the model by tensorrec.fit or tensorrec.fit_partial.
Is this the correct way to call?
fit_kwargs_part = {'epochs': 1, 'learning_rate': .01, 'n_sampled_items': 200, 'verbose': True}
result_part = tensorrec.fit_partial(model, user_features, item_features, train_interactions, test_interactions, fit_kwargs_part,
                              recall_k=30, precision_k=30, ndcg_k=30)

Following are the errors.
AttributeError: module 'tensorrec' has no attribute 'fit'
AttributeError: module 'tensorrec' has no attribute 'fit_partial'
Besides, how can I add the relevant metric in the call?
Thank you so much,
Kara


flow_from_directory yields batch with incorrect size

If the number of samples % batch_size != 0, flow_from_directory will return a batch with size != batch_size. For example with 7 samples and batch size of 4, the iterator yields a batch of 4, then a batch of 3.
The docs say that flow_from_directory will loop over data indefinitely (in batches), but should it instead loop over samples so that the batch size is consistent? I would be happy to open a PR for this.
Or maybe at least a warning should be given stating that samples % batch_size != 0?
There is another issue referencing this issue but it has been stale since August.

This is the expected behavior, consistent throughout Keras. How else would you ever get those 3 samples?

I agree it makes sense that those last 3 samples shouldn't be skipped, but since the generator is looping indefinitely over all the samples, wouldn't it make sense to place another sample with those last 3 to make a batch of 4?
With architectures expecting a fixed batch size, this can cause problems at the end of an epoch, for example I have been training a net on an image set of ~80K images that crashed after hours of training because the batch size was incorrect.

Sometimes it would make sense, but not always. It would also contradict a commonly understood definition of epoch.

Maybe it should show some kind of warning message in this case?

I have this issue while using flow from directory which I use batch_size = 32, but in generator, there are few batch samples with batch_size = 9


"Folder ... contains more Java files then configured in Bazel" when file is used in a java_library package.

I'm getting this error when running the extension on bazel itself:
Folder '/home/yusuke.tsutsumi/workspace/bazel/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/javac' contains more Java files then configured in Bazel. This is a scenario which is challenging to support in IDEs! Consider re-structuring your source code into separate folder hierarchies and Bazel packages.
 - javac/JavacOptions.java
 - javac/WerrorCustomOption.java

I looked at the files, and those are used in a separate target, although indeed they are explicitly excluded from the javac target
Although I think the error is still correct in that the package structure is difficult for parse properly - it is still a technically correct usage of bazel.
At minimum maybe this should be a warning and not an error?

Are you using the project-per-package strategy?

I don't believe so - is there a way I can confirm that?


Globally distributed deployment | DR/HA

If I understand correctly currently Dapr stores its state inside crds. So having two separate k8s clusters it's impossible to keep them in sync. Are there any plans on multi-region deployment support? It might be very useful for DR and HA scenarios

I would like to raise this again. The dapr documentation is not clear whether or not the current version supports multiple clusters / datacenters. ie, distributing / replicating the placement, state and tracing components
https://docs.dapr.io/operations/hosting/self-hosted/self-hosted-overview/
https://docs.dapr.io/operations/hosting/kubernetes/kubernetes-overview/
For example, akka talks about dealing with split brain scenarios but I don't see any reference to this with dapr, presumably because examples are still within the one data center.
https://doc.akka.io/docs/akka/2.6/split-brain-resolver.html
Would be great if someone could expand on this capability further, ie, out of scope for dapr, to be discussed for roadmap, etc.


Add version checking fix, tweak lists

Adds check for semver latest using arduino library registry
Strip version number for FONA repo (\r)
List unreleased libraries as needing release
Adds comparison link for live repos with changes
Adds timestamp to bad lists to help identify relevence
Add list of No-Examples libraries (was silent ignore)

@ladyada there were a few more issues in the script than I initially thought. This addresses the missing functionality around version numbers, and output list fixes.

I flipped this to draft so it won't get merged yet.


Feedback

[The link https://learn.microsoft.com/en-us/security/benchmark/azure/overviewtakes us to https://learn.microsoft.com/en-us/security/benchmark/azure/overview where page title says Overview of Microsoft cloud security benchmark (v1) ]

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

ID: 28d13bd5-9349-cc50-40c5-3b5c7b4b2126
Version Independent ID: 2386c444-4349-1a2e-a547-6ca1bece6434
Content: Overview of the Microsoft cloud security benchmark
Content Source: benchmark/azure/overview.md
Service: security
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

@narayankumargupta
Thanks for your feedback! We will investigate and update as appropriate.

@narayankumargupta
Could you please elaborate the query for better understanding. So, we can assist you further.

@narayankumargupta
Since we have not heard back from you, we will now proceed to close this thread.
If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Staged Comments - comments associated with incorrect site number

Comments are associated with incorrect site number.  First observed in Submitted Comments after submittal.  Confirmed in Staged Comments backup file.
While entering data, Staged Comments was checked after records containing comments were entered.   5 comments entered with no errors.  All were single comments - one per record.  Error appeared at comment 6.  Comments 6 and 7 were entered associated with the same record but 6 was associated with the previous record's site number.
Comment 8 was entered in the next record but was associated with the same site number as comment 5 and 6.
BRC_StagedComments - bug.txt

Attached is the final staged comments file from data entry.  Incorrect site numbers are flagged in red and column added for correct site number.
BRC_StagedComments_flagged.xlsx

This issue has been fixed. Created reactive objects for site, date, and sampler so that they could be passed to module would update appropriately when info changed. Tested several times... could use confirmation from coordinators and I will close issue.

Closing issue - no new reports of this problem


Use the default docker-machine

docker-machine is now assuming a default machine of "default" if you don't specify anything else. I think it would make sense for testcontainer to follow this lead.
https://github.com/docker/machine/pull/2843

Ah, thanks for raising this - I wasn't aware of this change in docker-machine! I'd definitely be happy to do this.
I believe that the behaviour we should aim for is:

If the DOCKER_MACHINE_NAME environment variable is set, use that
Otherwise use 'default'

As Testcontainers execs the docker-machine binary to find out the machine's IP address I'd imagine we need to pass through the resolved name - unless the environment variables are inherited, which I'd need to check.
Thanks
Rich

Thinking about this I'll adopt a slightly different approach to my comment above:

If the DOCKER_MACHINE_NAME environment variable is set, use that
Otherwise, if 'default' exists, use that
Otherwise fall back to using the first machine found in the docker-machine list

This should be backwards compatible with the previous way - and seems most likely to do the right thing by the user.

I've just released v1.0.1 with this change. Thank you for the suggestion!
Richard


Update encode.js

Add CAA RECORD

I'm sorry about the changes to the other lines, but I've put in a little prettier.


[1.13] docker build failed if there is a comment line in the multi-line RUN statements

Description
I ran into a problem that some of my Dockerfile cannot be built under new Docker 1.13.0-rc1. I found it might caused by a comment line in the RUN statement.
Steps to reproduce the issue:
First, create a Dockerfile with the following content:
FROM ubuntu:latest
RUN echo "hello" > /root/article.txt \
# A comment line
    && echo "world" >> /root/article.txt

The RUN statement is a multi-line command, using \ at the end of each line, and a comment line is in the between of those lines.
Describe the results you received:
Try to build the image
$ docker --version
Docker version 1.13.0-rc1, build 75fd88b

$ docker build -t testimage .
Sending build context to Docker daemon 4.096 kB
Error response from daemon: Unknown instruction: &&

Then I got an error: Unknown instruction: &&.
Describe the results you expected:
However, it's used to be ok. If I build this Dockerfile under Docker 1.12, everything is ok:
$ docker --version
Docker version 1.12.3, build 6b644ec

$ docker build -t testimage .
Sending build context to Docker daemon 4.096 kB
Step 1 : FROM ubuntu:latest
latest: Pulling from library/ubuntu
aed15891ba52: Pull complete
773ae8583d14: Pull complete
d1d48771f782: Pull complete
cd3d6cd6c0cf: Pull complete
8ff6f8a9120c: Pull complete
Digest: sha256:35bc48a1ca97c3971611dc4662d08d131869daa692acb281c7e9e052924e38b1
Status: Downloaded newer image for ubuntu:latest
 ---> e4415b714b62
Step 2 : RUN echo "hello" > /root/article.txt     && echo "world" >> /root/article.txt
 ---> Running in 586405a87df6
 ---> cccb2f193a86
Removing intermediate container 586405a87df6
Successfully built cccb2f193a86

Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
Client:
 Version:      1.13.0-rc1
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   75fd88b
 Built:        Fri Nov 11 19:47:07 2016
 OS/Arch:      linux/amd64

Server:
 Version:             1.13.0-rc1
 API version:         1.25
 Minimum API version: 1.12
 Go version:          go1.7.3
 Git commit:          75fd88b
 Built:               Fri Nov 11 19:47:07 2016
 OS/Arch:             linux/amd64
 Experimental:        false

Output of docker info:
Containers: 24
 Running: 3
 Paused: 0
 Stopped: 21
Images: 31
Server Version: 1.13.0-rc1
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: fluentd
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 8517738ba4b82aff5662c97ca4627e7e4d03b531
runc version: ac031b5bf1cc92239461125f4c1ffb760522bbf2
init version: N/A (expected: v0.13.0)
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-47-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 488.5 MiB
Name: d1
ID: M7VK:YNAL:VPTV:T5CX:CAS3:W7WX:WT6E:3PVE:GOBD:TQKT:MJLT:5K7C
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
 provider=digitalocean
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
The test environment is a Digital Ocean Ubuntu 16.04 droplet.

This change was done on purpose to more closely align with how scripts work. For example:
echo hello \
# ignore
  world

generates an error because "world" isn't added to after "hello". IMO, the old behavior as a mistake.

Closing since this was an intentional change.

@duglin Could you redirect me to the docs of the change? Thanks.

@twang2218 in the docs the best I could find is, in
https://github.com/docker/docker/blob/master/docs/reference/builder.md
look for Line continuation characters are not supported in comments.
The PR that introduced this change is: https://github.com/docker/docker/pull/24725

Got it, Thank you.

Oh man, this one's going to fun to communicate -- having comments in the middle of a really long RUN line is a really common pattern in my experience. :sweat_smile:

Yeah, I use the same pattern for comenting a long RUN, which is very common in Dockerfile if you follow the best practices, and it's quite useful. 😊 Now, I have to change every comment to 'echo', which doesn't make any sense as I use 'set -xe' already.😭

Discussion continued in https://github.com/docker/docker/issues/29005
I'll lock this issue from commenting to prevent future "passers by" from commenting here, and the discussion being spread across too many issues


Strict decoding for test configs

With test configs, we want to make sure options aren't ignored if they're misspelled or in any other way malformed, so let's be strict about decoding them and DisallowUnknownFields.

https://github.com/osbuild/images/blob/03212162ff492db563b5805442a1f084a623a835/test/generators/generate-ostree-build-config#L234-L238
Who's petard is this and where did it come from? >_>


Update version to 1.3.5-0 on staging

Update version to 1.3.5-0

Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers!


Feature/user permissions profile page

Description
Proposing simpler counterpart to https://github.com/dockstore/dockstore/pull/4897 (which can be closed if this is accepted)
We don't actually use emails for anything and only return it to the logged in user which is pretty useless.
Aside from that, the user profile and user classes seem to be devoid of PII.
What if we only kept emails on the server and allowed the rest of the User class to be public?
Needs security review: reveals User and UserProfile to end users
Issue
https://ucsc-cgl.atlassian.net/browse/SEAB-4240
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 mvn clean install
[x] Ensure that the PR targets the correct branch. Check the milestone or fix version of the ticket.
[x] Follow the existing JPA patterns for queries, using named parameters, to avoid SQL injection
[x] If you are changing dependencies, check the Snyk status check or the dashboard to ensure you are not introducing new high/critical vulnerabilities
[x] Assume that inputs to the API can be malicious, and sanitize and/or check for Denial of Service type values, e.g., massive sizes
[x] Do not serve user-uploaded binary images through the Dockstore API
[ ] Ensure that endpoints that only allow privileged access enforce that with the @RolesAllowed annotation
[x] Do not create cookies, although this may change in the future

This definitely achieves the goal of disappearing the email.  Longer term, it might be nice if each user could decide what information they want to display, and to whom (maybe a gradated scale like, "private", "other org members", "public"), because some users might want to, for example, publicize their email so people could easily get in touch.

One attack surface to be aware of that's used to find privilege escalation or phishing targets is user enumeration. Can a public internet user determine who the admins are using this?

Yes, it could be and that's an interesting point.
Unlike email, curator and admin status may be something that should be visible to one's self but hidden from others?
This may tip us back toward a more complex solution, but stay tuned.

By cycling through user IDs can an attacker find user information for users that have no public content?

Yes, I believe so.

Taking some notes for myself:
Looking into filtering by security role since I think that makes a lot of sense
https://blog.dejavu.sk/filtering-jax-rs-entities-with-standard-security-annotations/
However, running into problems that look possibly related to https://github.com/dropwizard/dropwizard/issues/1341
Strangely, it looks like we had the workaround already in use and it still doesn't work
Looking more deeply ...

Split out findings on a more sophisticated solution at https://ucsc-cgl.atlassian.net/browse/SEAB-4691
Will have to timebox that due to lack of success and merge this as-is for now.


Define Swift package and add Swift bindings

I mostly took inspiration from the Rust integration because Swift and Rust are similar

Thank you, @conradev!


Provide getProperty method for VError and WError

I find it useful that if VError and WError instance could get its parent(s)'s property value. A use case could be like
var request = require('request');
var VError = require('verror');

function getTestData(callback) {
  request.get('http://test.com/api', function(err, resp, body) {
    if(err){
      err.code = 'ERR:REQ:1';
    } else {
      if(resp && resp.statusCode != 200) {
        err = new Error('Request Failed');
        err.code = 'ERR:REQ:2';
      }
    }
    callback(err, body);
  });
}

function performTest(callback){
  getTestData(function(err, data) {
    if(err){
      callback(new VError(err, "Perform Test Failed"));
    }else{
      var testResult = {};
      callback(null, testResult);
    }
  });
}

performTest(function(err, results){
  if(err){
    console.log('Error occured with code %s', err.getProperty('code'));
  }
});

I have created a utility method like below, but I think it would be better to be part of the library
function getPropertyFromError(err, propertyName) {
  return err && (err[propertyName] ||
    (typeof err.cause === 'function'? getPropertyFromError(err.cause(), propertyName) : undefined));
};

I think it's useful to first-class the notion of properties, and we've been talking about it over on #10.  I've got a branch there with a prototype that I'm getting pretty confident about.  It's a little different than the way you've done it here, but addresses some other issues.

I looked at the verror.js, the info works for the errors chain starting with a VError instance, as it only read from error.jse_info. Other properties from the beginning Error instance will be ignored.
IMHO, there are two things not good with this way:
a). The constructor with options as first parameter is terrifying. (Can't image creating a large block of codes to just make VError work )
b). Have to create VError instance in every the async callback (especially all kinds of libraries - such as request, redis, fs) to wrap Error instance and store its properties to VError's jse_info. Most of 3rd party libraries just assign properties to error instance.
Suggestion with what you have built:

When instantiate VError with cause (Error instance) as first parameter, automatically move all non-function properties (except message, name, stack) to jse_info (address the #a point above)
Provide VError.info(error, propertyName) to find most outer error carrying specified perpertyName and return the propertyValue.(address this issue though compromise #b point above)

My opinion about VError is that it's the best fit in my use case to build errors for both developer and end users. No matter it's 3rd-party npm module or internal lib/util, the error processing always starts with Error instance with whatever properties assigned to it. Take express.js req/res for example
Route Handler ---(invoke)--->  Controller ---(invoke)---> Library
Library ---(Error)---> Controller ---(VError/WError)---> Route Handler ---(WError)---> Client
Library generate whatever error (e.g. request connection timeout error), should be wrapped in Controller with Developer friendly message (e.g. XXX API Request Timeout), and before we send the error to client, we need to wrap it again with Client friendly message (e.g. Oops, something wrong blabla, retry pls...)
In this common use case, the most likely place to set properties is at the Library. And I don't think it's significant better to group all properties to error.jse_info and force user to create a VError at Library.

The "jse_info" bit is an implementation detail, but what you're getting at is that the design for #10 does not use arbitrary properties hanging off the Error object.  That is a little more inconvenient, but it has a couple of advantages:

An important design goal for VError is that it always be valid to take an existing Error and wrap it with a VError (i.e., making the original Error the cause of the new VError) and not have that change the behavior of consumers looking at that Error.  If properties are hanging off the Error object and you wrap it with a VError, then we presumably need to copy those properties onto the VError.  I explored doing this first, but it felt janky.
The current approach protects us from future property names added to the Error class.  As it is, there are a number of properties provided by different implementations (see the MDN Error documentation), which would presumably have to be reserved, which I think would make the interface even more confusing.
This approach makes it easy to collect the set of "info" properties for a given Error (e.g., for logging or inserting into a fault monitoring system).  If we hang info properties off the Error object directly, then callers wanting the list of informational properties need to know to ignore all the pseudo-standard property names linked above.

As for (a), you're right that the constructor can look more like a large block, but I don't think it's very different than if you're using separate properties.  You've got to compare:
err = new VError('message');
err.prop1 = value1;
err.prop2 = value2;
err.prop3 = value3;

to:
err = new VError({
    'info': {
        'prop1': value1,
        'prop2': value2,
        'prop3': value3
    }
}, 'message');

I think it's cleaner that it's declarative.  And in the much more common case where you don't need additional properties, it's still ergonomic:
new VError('my message')

As for (b), I think it's a reasonable idea to provide a VError function that takes an Error provided by a third-party library and creates a VError containing all of the non-standard property names as VError 'info' properties.

Having heard no more, I'm closing this out.  I'm hoping to land #10 soon.


[BUG] Azure.ResourceManager.DeviceRegistry is out of date

Library name and version
Azure.ResourceManager.DeviceRegistry 1.0.0-beta.1
Describe the bug
I tried calling the Assets (IoT Operations) using the C# DeviceRegistry-Library, but it failed.
Expected behavior
I expected to get my assets.
Actual behavior
The exception is the following:
Azure.RequestFailedException: 'Failed to create HTTP response as per the API specification with one or more errors. Please see details for more information. Consider to retry operation with api-versions ''.
Status: 412 (Precondition Failed)
ErrorCode: HttpResponsePayloadAPISpecValidationFailed

Content:
{"error":{"code":"HttpResponsePayloadAPISpecValidationFailed","target":"","message":"Failed to create HTTP response as per the API specification with one or more errors. Please see details for more information. Consider to retry operation with api-versions ''.","details":[{"code":"ObjectMissingRequiredProperty","message":"Missing required property: assetEndpointProfileUri. Paths in payload: '$.value[0].properties.assetEndpointProfileUri'"}]}}

Headers:
Cache-Control: no-cache
Pragma: no-cache
x-ms-ratelimit-remaining-subscription-resource-requests: REDACTED
x-ms-providerhub-traffic: REDACTED
mise-correlation-id: REDACTED
x-envoy-upstream-service-time: REDACTED
Strict-Transport-Security: REDACTED
x-ms-failure-cause: REDACTED
x-ms-request-id: ce75e155-4c0f-4bd5-8f63-236501fe1891
x-ms-correlation-request-id: REDACTED
x-ms-client-request-id: 5c654a0f-ce3a-4ae5-8591-4624b654e872
x-ms-routing-request-id: REDACTED
X-Content-Type-Options: REDACTED
X-Cache: REDACTED
X-MSEdge-Ref: REDACTED
Date: Fri, 22 Nov 2024 11:35:06 GMT
Content-Length: 446
Content-Type: application/json
Expires: -1
'

Reproduction Steps
using Azure.Identity;
using Azure.ResourceManager;
using Azure.ResourceManager.Resources;
using Azure.ResourceManager.DeviceRegistry;

string subscriptionId = ...;
string resourceGroupName = ...;

ArmClient client = new ArmClient(new AzureCliCredential(), subscriptionId);
SubscriptionResource subscription = await client.GetDefaultSubscriptionAsync();
ResourceGroupCollection resourceGroups = subscription.GetResourceGroups();
ResourceGroupResource resourceGroup = await resourceGroups.GetAsync(resourceGroupName);

await foreach (DeviceRegistryAssetResource asset in resourceGroup.GetDeviceRegistryAssets()) // <-- fails

Environment
No response

Thank you @tenthmile for your feedback, @davidemontanari could you please update the sdk?

Thank you for the feedback, @tenthmile. We've got this one in our backlog and will update this issue once the SDK has been updated. In the meantime, as a workaround, you could consider using REST APIs instead.

Here is the https://github.com/Azure/azure-sdk-for-net/pull/47304 to upgrade the sdk


feat: Use permit2 transferFrom

Couple thoughts:

Need to test with signature based approvals on permit2 allowance transfer contract
Need to add a selfPermitWithPermit2 function that accepts a signature to permit posm on permit2. (Similar to SelfPermit on v3 nft manager i believe) but basically this just lets you batch an approval with whatever add/remove liq you want to do
Do we need to support sig transfer?
Possibly still support vanilla transfer in pay

@hensha256 Not sure why CI is failing, it all passes locally looks like its an issue with imports / doesn't know what snapLastCall is in v4-core test 😢


fix: add jsx extensions for next default file convention

This is currently flagged as a false positive since any default.tsx or default.jsx file is not included in the entry point of the project but are also not imported since this is a special next.js file which marks it as unused by knip.

Thanks for the PR! I'll look into it tomorrow, but iirc there was a similar discussion recently where the file turned out to be used by some plugin (not necessarily next/Next.js itself). Any chance you could confirm and/or point me to docs that do?

Thanks for the PR! I'll look into it tomorrow, but iirc there was a similar discussion recently where the file turned out to be used by some plugin (not necessarily next/Next.js itself). Any chance you could confirm and/or point me to docs that do?

I assume your referring to this discussion only one i could find that was related to this on the repo, next.js doesn't explicitly state in the docs that the extension could also be jsx or tsx but in one of their usage examples for modals they have you write a default.tsx file

Thanks again for the PR and all the details, let's merge this.

:rocket: This pull request is included in v5.7.1. See Release 5.7.1 for release notes.

Sorry, not sure 100% if this is related but after updating to<EMAIL_ADDRESS>next route handler is flagged now as unused export.
I am using knip --include-entry-exports
On<EMAIL_ADDRESS>this is not reported and works as expected

How about v5.7.3? 😜

It works! Thank you :)


netlify.toml: pin postcss dependency to ^8.0.0

Description of the change:
Motivation for the change:
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[ ] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[ ] Add or update relevant sections of the docs website in website/content/en/docs

/cc @asmacdo @camilamacedo86


Poor canvas performance (drawImage) probably caused by electron

[x] I am on the latest Hyper.app version

[x] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: Windows 10 (10.0.16299 Build 16299)

Hyper.app version: 2.0.0-canary15

The issue is reproducible in vanilla Hyper.app

Relevant information from devtools:

Issue
Poor performance probably due to electron bug: electron/electron#11051

Yep. The electron issues probably don't help, but it's slow on up-to-date versions of Chrome too.
Xterm.js often draws much more to the screen than it needs to, mostly because of some complications with overlapping wide characters. I'm working towards fixing this, and some other related performance issues, so the idea is that while it'll still be possible to end up with 160 ms frames, they'll be much less common.
I think if we want to completely eliminate these kinds of performance issues, we'll need to use WebGL, since that'll let us fill the entire screen with one or two draw calls. However, that's a lot more complicated, so I'm not interested in working on it the moment.

https://bugs.chromium.org/p/chromium/issues/detail?id=683994


chore: remove unused imports

What kind of change does this PR introduce?

remove unused imports, run prettier

I think there's an issue in your system 😅


Fix: typo.

I signed it!

Thanks, Qiun!
Let's wait until the build issue https://github.com/bazelbuild/rules_apple/issues/142 gets resolved.