[WIP] issue 13936

This is a WIP PR for validating some aspects of a select messages and markdown copy pasting feature.
It is related to #13936 .
This is an experimental version. You can find some example images in the issue page.
For selecting messages you can use shift + click keyboard combination.
The zulip chat discussion topic is:
https://chat.zulip.org/#narrow/stream/137-feedback/topic/copy.20paste

Does Cmd/Ctrl + click also work for individual message selection instead of a range?

Nick, you must select one by one pressing shift + clic. They are going to mark in a red border. Later you can clic the bold pencil for getting the code.

At this moment, it is working in a group of messages (the set grouped by a title).

It should be Shift + Click to select a range, and Cmd/Ctrl + Click to select multiple individual messages, just like system <select multiple=true> fields.

could this be the behaviour? "shift + clic + drag" for a multiple selecting and "ctrl + clic" for an individual selecting

Hi @afreydev , thanks for working on this. Did you test this on different browsers? I worked on a similar feature (#11949) about a year ago and the problem there was the different behavior of browsers.
Chrome was usually problematic (extra content would get copied, etc.) and the Zulip desktop app also runs on Chromium, so that might be an issue.
I also left a comment regarding a linting issue.

Thanks @vinitS101. This approach extracts the info directly from the database.
Selecting action only gets the message id, later we can get the markdown from the backend by an "id list".
I'll fix the differents lint issues. This was a "raw" version for validating some things including which you are commenting.

These are the latest changes:
Copying:

Pasting:

Thanks @vinitS101. This approach extracts the info directly from the database.
Selecting action only gets the message id, later we can get the markdown from the backend by an "id list".
I'll fix the differents lint issues. This was a "raw" version for validating some things including which you are commenting.

That sounds like a great approach. That probably wouldn't work for #11949, but this seems to be going good.


Device Does not respond or  the General Status =0

I connected the Motor driver with 24v(+), 5v(-), 5v(+) but still the General Status =0 in Mtools. It is connected with a Windows 10 machine over COM7(115200) as mentioned and When I click the "Open" button under "Serial", the bottom status said Connected with COM7 but there is no response or feedback from the Driver.
DO you have any Troubleshoot steps to follow to check if the Device is dead or not? I checked visually and could not find any Burn sign or any damaged or burnt peripherals.

solved after replacing a new board.


startup failure (infinite loop?) when upgrading 1.12.6-cs8 to 1.13.1-cs1

Description
We were trying to perform an update from 1.12.6-cs8 to 1.13.1-cs1. We have live-restore enabled. During the update, when docker daemon was starting, the startup time was taking longer than normal, but still, dockerd was logging into /var/log/syslog (server debug enabled). Log messages seemed to be repeating about "container restored". After over 2h of attempted restart, I checked how many containers were recovered by dockerd and how many times each one of them was recovered:
# grep "container restored" /var/log/syslog.1 | egrep "Feb 13 1[34]" | cut -d"=" -f5 | sort | uniq -c | sort -n -r
   3039 290f5dfe635dbf182c3b19d8772de53bf4a2f9c0e98cfa2bafa96642adec1a60
   3039 287d3197ff02cc775eec32899a8b8e099dba77727d638e0e60e50c9a8041960f
   3039 27970ed40608b7789f7639a764afdd7e99e79b5247be1a6326cb6d500aff0f6b
   3039 274934a427f5235523fa11075ec0f047349ca8d894da9507c3748cdc9b551912
   3039 2610bc8b7dc29c4c35bae3872f376a4e6e3f82858f58d0015780ed2218201315
   3039 252c75bb23156375c3e61fea6044664a53ae5be56db0c805537abc57a77b2b0a
   3039 24ea31727a604f1fc96707f4d2a44d3c249158ec5bb9a26ef341151cf33d8041
   3039 24c2240b7d22812e535075dd3021bf70606a7c1f79a1c16cc5a8669aba98ca25
   3039 2323a6294713196d8741de0b8798170a9cb02568401c8b4c463379d870980048
   3039 2288e12c0c1a261921f7b87c35440f4b2990b2f3e71dee3764819b25a7de8e5c
   3039 21d2a01fa82fee71057ad7b72c644523c46b721d4719d7229105dfe49fa7f934
   3039 219b892ddcd7232146a6c447d22c076b8726ad6a2d987c20698331d58fa96534
   3039 216248c9ac21ba52221ea55b4ab2267030ef244536e95810eff60d94b2e9da5a
   3039 211208073fc1bc3ac5370f4764f6cb6b1963672afd5f300faf8bd57b21c8da6a
   3039 20be4e3cdeb2fa6587a30c3e2d867a2ecdd7c01aeed4c3128e47d137d5e50113
   3039 203b2745d71d9a45cc2acda6df7d9539ee0ac0101c5d842739e8a03bd2b0be42
   3039 2005ed693a1b1903be153a445d44e4412d8d929f967a4d42e34d40c43e6bcd28
   3039 1ffff08624f3a84f69c014b7e6533961f6877ea211daa40253b4e56293dc0d2e
   3039 1f530d75b615c9134e8d1161a5322fd871c2ebac876735c5f5401c4cdb051044
   3039 1dce805bc8cc2775772c4c61d00f30362aaff322602f0806d405a4f8a636870a
   3039 1cf57d07a571093755fe11956c90d66495f54220ae88344f121d4e7d76dce865
   3039 1c7c8f12ede29a2bb6916a1b3161ce5f8bdcdc14ea05321b9daff5af8f613141
   3039 1c62b4e7cd4b5940ee03a9a23278d12acb24d049ee51454f4072a5c7375a5c42
   3039 1a0a4e3c0c6c87099a7a2cc906eecb118d07378a3059ad201e51fb4678222e7a
   3039 19325e3636d7fb5bb92013c828a01f49389f27cb8893c326c14b05f75556c764
   3039 18db20c8168f3e7697e06f76be86a43213db07a45f4ba30292f974704af93043
   3039 17c872bea0555c2ca8aa0290609c2a328df70af7c41c994753413a0436b13d45
   3039 17aa4a241cf7e11122c12f80a9affc792fa7b94db1bed17b473484cb51396c6a
   3039 179d52b02b431e13818387783b2c6460ebd672beb970ec240a6341f7e563f331
   3039 175d3c75651c90563a5e19d9386f794c9709c9c75cce095fc6dd2f5ec4461349
   3039 162813839e599235f62fe56b60e75d0569af9a2a7f5fd61bfa327c066a40ed5b
   3039 153044127cbfc005056c99163f2c1f6aaa7c1b02e370c44c7847ff1a2d0fa905
   3039 14243ea28573407f467033bd11ddd62605dd026269dad61ff342359698ea0d1f
   3039 13c6f54fed598a774a741ff740031e4629d00040298a894e250781de03c4fb4f
   3039 12ddca97e8039773236425ba5d5578025a5453c58081b01a1d0381f400207108
   3039 117547be524de050c91977e0993c5f54866892e979af636b56580f634c7bbe0c
   3039 113f88b267413f0eeab2e3a333f48b3f3fd6c70d86e14122d092c05c72bb0a79
   3039 1132f8fe9a01a7637127455b0be54b38d46cee8f89148f413ccf4bf68622ea49
   3039 10686b6c9caf177f482f227287bcd9423089bf8d6517cb5105bb4cb166bd451c
   3039 0fb49be3da1789770ab2918d51882a494b94f1875489d524752f2a4248307650
   3039 0f7c17e43f28641ee4a7bb6ad935f3738f0caf2bfd23f07710222ddb1f6c6f3b
   3039 0f5b40b55129e850d84cbf41da6f727f61ee7e3b59ca0151a0f65320732fa73f
   3039 0f37b29c2257d47345d0d07902c6ba66302a9a4a298b1827e9709914569eb35f
   3039 0e78c2ef1395b11d13271ef394cbde44b2db95cb828d776b5184ba3f470b2f1b
   3039 0c2c153e3fb30a1166ab06614be41a1d7f3f2781ca442f209af0fd7bd0c5004b
   3039 0bfb31a2700c4e70fdb24583698fec4c273355b6c5068f07e9a51462cc5e3345
   3039 0b6882e665e40c69c3d0cb495e4c9d3f38c6db0b33d67f2ac630a54971a67f1f
   3039 0b36d34796b69e5ced6457e7ac70ff63fdaa4ce32dc9dd37d879128097452b16
   3039 0b10248cccedf05d0700790f654f721c6fb34df8bac887032ae25b2d64e35135
   3039 0aa94c9be4d60334a9c3c96b5bf8947de11b5a47d522d56418b63e32762d1135
   3039 0a7fc5e3fb70310efd3512e67b8f361c680e58b5f6f88a75b43dfdf976317757
   3039 097b4d8f37e7872d83377e6481bcff699f6fe3374cea537462b889bcccb96017
   3039 086ba38d72c10a6accd36979be055542eb27168a2e30702e50253efc241aab54
   3039 082d3b04a1d7ac2786e98f0deecfc62a50494326b9963136eea0b603182ba324
   3039 077d27e22c92762e76bded8f8b717d11225778bcdb8957708eb82c530642b6f3
   3039 076522e63fcf2b3fd0fe06eeea3e44202f507b3f1443f75dcef11d016673e81e
   3039 064866b832f7d55b896fcff5d42a497277303bfc430aa23c248a4d606ab52e19
   3039 05ab42e19bfa6b46300bdd1eb382964155ca45c7b47f3a0a3ecf42fb87f9e06b
   3039 051a74dce1f63a7ec3183adc27b1e173c230bd513920c956a7d8d04f789fa71d
   3039 04468560bd81e54bbb5e7e97f8471a12a64af8705fd3be769c14be0f56b8392b
   3039 037298862ec9420f30ce75740b4c8369b799597e241c610acf76aded66032a5d
   3039 030fe700ee3a0c235f9d6290b3e9080125667761d812055ef51ffcd54a652f19
   3039 03091346a3537f457a601ce2ce706924c1f054d2850fd1447aca84490063761f
   3039 01bcffb70143f87ce25836ec20aebe062885a899d6571f5edc1feea77b90120e
   3039 01aeaf3f43c29230ca8d3f47356f10688f585cd02f6c5d109f09f330c4b6e11a
   3039 017f657d8beedb02098cbc350b960f2772fd4600fb0ada574dca0862ff959f41
   3039 011375dc299c94375099da6a78d1fd79daef8d389c65613619e02725ace61840
   3039 00dc610b9a2f0d417b86dcdc764f8559c8aa4e7a1ed9f559c866422f758a9b5c

It turned out, that only 68 containers were logged (out of ~300 that should be), but each one of them was restored over 3000 times. At this point we decided to give up on 1.13.1 and rollback to 1.12.6 (this caused another issue: https://github.com/docker/docker/issues/31007).
Steps to reproduce the issue:

Performed upgrade as described above.

Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
I don't have exact output, but it was definitely latest 1.12.6-cs8 and 1.13.1-cs1.
Output of docker info:
Since dockerd 1.13.1-cs1 didn't even start, we don't have exact output. We had live-restore and server debug enabled, about 300 containers were running at the time of upgrade.
Additional environment details (AWS, VirtualBox, physical, etc.):
Running on AWS, x1.32xlarge instance, ubuntu 16.04 LTS. We got debug level server logs for that time period.

/cc @mlaventure @cpuguy83

yes, it takes too long for the restoring process to happen, so docker thinks containerd is unresponsive, kills and restarts it, and it keep happening in a loop.
A fix was made in containerd to have the grpc registered before doing the restore to avoid this issue (https://github.com/docker/containerd/pull/609 and https://github.com/docker/containerd/pull/627).
It is schedule to make into 17.03.1

Should this be closed, if it's fixed in 17.03.1?

Do we close before or after the final release is out? :angel:

Well, a PR that fixes an issue usually has fixes xyz 😄

Closing then.


Represent doppio point in Bulletproofs

Make an AllocatedPoint type which has:

the encoding of a doppio point (affine might be more efficient in a circuit setting, TBD)
the Bulletproofs variables that represent the doppio point
collection of constraints, which enforce that the point is a valid doppio point
(maybe) a reference to a constraint system, in which it allocates the collection of contraints

Friendly note, we have an implementation of generic Twisted Edwards affine group operations in https://github.com/scipr-lab/zexe/blob/master/snark-gadgets/src/groups/curves/twisted_edwards/mod.rs that could be useful for y'all =)


x/pkgsite: do not show packages of a module at the top level

What is the URL of the page with the issue?
https://pkg.go.dev/search?q=gui
https://pkg.go.dev/search?q=gitea
What did you do?
Searching for GUI packages
What did you expect to see?
A list of modules. Packages and sub-packages of a same module should not show in a scattered manner.
Also, some projects have more than one forks/mirrors and the same packages would show repeatedly, which is confusing.
When searching at pkg.go.dev, it shows all packages and sub-packages of a module and the packages of different modules are interspersed. It makes the result look scattered. I propose that pkg.go.dev only shows modules at the top level and only expands the view of packages of a module when explicitly chosen by the user.
It is probably related to https://github.com/golang/go/issues/26827.

Thanks for the feedback! This seems to be related to #36814, #36806. Also #37810 for tracking.

This will be addressed #47321, so closing this issue.


python310Packages.databricks-cli: 0.17.3 -> 0.17.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.databricks-cli is: "A command line interface for Databricks"
meta.homepage for python310Packages.databricks-cli is: "https://github.com/databricks/databricks-cli"
meta.changelog for python310Packages.databricks-cli is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.17.4 with grep in /nix/store/zrky946ijr57fh08his59mf9az4lypxn-python3.10-databricks-cli-0.17.4
found 0.17.4 in filename of file in /nix/store/zrky946ijr57fh08his59mf9az4lypxn-python3.10-databricks-cli-0.17.4

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

6 total rebuild path(s)

6 package rebuild(s)

First fifty rebuilds by attrpath
dbx
mlflow-server
python310Packages.databricks-cli
python310Packages.mlflow
python39Packages.databricks-cli
python39Packages.mlflow

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/zrky946ijr57fh08his59mf9az4lypxn-python3.10-databricks-cli-0.17.4 \
  --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 python310Packages.databricks-cli https://github.com/r-ryantm/nixpkgs/archive/99dc258685849b22c3c160cf154f8e0ae1e4e380.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/zrky946ijr57fh08his59mf9az4lypxn-python3.10-databricks-cli-0.17.4
ls -la /nix/store/zrky946ijr57fh08his59mf9az4lypxn-python3.10-databricks-cli-0.17.4/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

6 packages built:

dbx
mlflow-server
python310Packages.databricks-cli
python310Packages.mlflow
python39Packages.databricks-cli
python39Packages.mlflow

Maintainer pings
cc @tbenst for testing.

Result of nixpkgs-review pr 205570 run on aarch64-darwin 1

6 packages built:

dbx
mlflow-server
python310Packages.databricks-cli
python310Packages.mlflow
python39Packages.databricks-cli
python39Packages.mlflow


Add a custom button on Navigation menu

I know it's possible using the library repo but it would be awesome if it was possible to do it even using the sample project.
Just a simple button that opens a link. Really useful if the app has a separate paid version.

I don't know if it's really needed by others. I'll considering about this and keep the issue open.

@danimahardhika I actually added this to my app but it can be a useful feature.


[ConformanceLookup] Don't allow skipping inherited unavailable conformances in favor of explicit available ones.

The type checker does not support the notion of multiple protocol conformances; there can only be one conformance, and if that conformance is unavailable, you cannot specify your own available conformance. This is important for Sendable checking; if a framework specifies that a type is explicitly not Sendable with an unavailable Sendable conformance, clients cannot ignore Sendable violations involving that type. If a superclass wants to allow subclasses to add a Sendable conformance, it should not declare an unavailable Sendable conformance.
Note that this change still does not warn if the original unavailable conformance is declared with @_nonSendable due to the way @_nonSendable expansion happens during implicit Sendable derivation, after no explicit conformance has been found.
Resolves: rdar://124423524

@swift-ci please smoke test

@swift-ci please test source compatibility

@swift-ci please smoke test

@swift-ci please test source compatibility

The macOS smoke test is failing due to a driver test failure unrelated to this change. Looks like a revert is being tested at https://github.com/swiftlang/swift-driver/pull/1662

@swift-ci please smoke test macOS


Provide VLC streaming

Hi!
I want to realise a TV from aceproxy at some 'tv' host, an android player and a monitor. I do not like how existing android apps handle playlists, plus I want this setup to be headless and to control it by simply wgetting an URL like http://tv:8000/pid/CID/stream.mp4.
Right now aceproxy internally makes VLC to broadcast to http://tv:8081/CID and proxies this stream to http://tv:8000/pid/CID/stream.mp4.
I wonder if aceproxy could provide an option to not append CID to VLC braodcast destination, so that it would be simply fixed http://tv:8081?
Changes are required then to VLC control:
https://github.com/ValdikSS/aceproxy/blob/master/vlcclient/vlcmessages.py#L15
https://github.com/ValdikSS/aceproxy/blob/master/acehttp.py#L344
And proxy at https://github.com/ValdikSS/aceproxy/blob/master/acehttp.py#L377 then renders redundant as it degenerates into simple blocking call until wgetter exits.
Such setup would allow for easier control over headless TV.
Does the idea understandable and/or welcome?
TIA,
--Vladimir

I still don't understand why do you need this. Can't you just use CID (pid) link then?

I think he means that PID/CID can change sometimes and he need static link
without pid/cid... But not sure :p
On Sat, Jan 3, 2015, 00:25 ValdikSS<EMAIL_ADDRESS>wrote:

I still don't understand why do you need this. Can't you just use CID
(pid) link then?
—
Reply to this email directly or view it on GitHub
https://github.com/ValdikSS/aceproxy/issues/25#issuecomment-68548982.

Well. I have a headless thingy X which I can just hardcode to play from, say, http://foo:8081/bar.
Then I have an aceproxy host Y which waits for requests which are not constant (they have pids there). Evidently, X can't make such elaborate requests.
The point is to operate on Y from another host Z which requests from Y particular pid, but so that Y streamed to the same http://foo:8081/bar (which X expects forever).
That way I could operate implicitly via Z the picture that headless X displays.
Pity, I already see that it can't be done -- when aceproxy is requested a pid, it firstly creates a new stream and only then closes current stream. So it will be the clash if the names of that streams coincides.
So let the issue be just closed. Thanks

You can easily write a plugin which will redirect your thingy X with HTTP Location header to needed pid or torrent or magnet or whatever.


Make size of content fields on sending forms a function of the max message limit

Twilio supports large messages up t0 1600 characters, which it breaks transparently into 160-character ones. I've been broadcasting large texts for months and I wanted to switch to Apostello tonight but got hit with the 150 character limit. Please, add the option to have a textarea with 1600-character limit.

You can alter the limit in Tools --> Site Configuration. So you can send longer messages today.
The text box will however remain the same size.
I can change it so that the number of rows in the text area is a function of the maximum message length.

@monty5811 When I tried sending a longer message and although the limit by default is 160, Apostello complained that the message is longer than 150. So, why 150 and not 160?

It is to handle the %name% substitution functionality.

I could make it more sophisticated so that limit only kicks in if a name is actually being substituted in


Add server quick info to help debug container

In this PR:

Add new Discord commang !stats to show current bound twitter user and package version info.

This hopefully will help us to show current version of installed package on the Docker realm, #3.
Relates with #2

@Namchee, please help me review this one ya. Do this meets your coding standard? Thanks!

@Namchee, please help me review this one ya. Do this meets your coding standard? Thanks!

Hey @Namchee,
I've updated accordingly, just quick request, can you please add the es-lint runner to package.json. I intended to run the eslint check upon PR creation, so things can get attention accordingly.
Thanks!

Hey @Namchee,
I've updated accordingly, just quick request, can you please add the es-lint runner to package.json. I intended to run the eslint check upon PR creation, so things can get attention accordingly.
Thanks!

@chez14,
I've added some linter commands in the package.json. Please merge it first and push it back so I can merge this one :smiley:

@chez14,
I've added some linter commands in the package.json. Please merge it first and push it back so I can merge this one :smiley:

Done. I'm rebasing the branch just to make sure.

Done. I'm rebasing the branch just to make sure.

:rocket: PR was released in v0.1.0 :rocket:

:rocket: PR was released in v0.1.0 :rocket:


[warnings] fix cert-err33-c

Fix unused return values, cast to void if on purpose

@freerdp-bot test

@freerdp-bot test

@freerdp-bot test

@freerdp-bot test

Hum I'm always sceptical with these patches that look like they're there just to make these (sometime inaccurate) check tools happy. Not sure to like the heavy 4ULL * xxx * yy notation all around the place...

Hum I'm always sceptical with these patches that look like they're there just to make these (sometime inaccurate) check tools happy. Not sure to like the heavy 4ULL * xxx * yy notation all around the place...

that is actually a bugfix (C does define how the integer types are expanded, it depends on the first argument)

@freerdp-bot test

Just started to have a look at this beast ... but I do not know what the analysis tool has against if (ptr) or if (!ptr) as this is well defined by the standard and common practice. IMO this does not improve readability and it is also regarded bad practice by the CppCoreGuideliness.

@mfleisz that will be https://clang.llvm.org/extra/clang-tidy/checks/readability/implicit-bool-conversion.html - there seem to be opposing views on this matter ^^
anyway, contained in a single commit, so can be dropped and the check disabled if consensus. (did that with a few of the checks that contradict our coding styles already)

replaced by pull requests for each commit:
#10518
#10519
#10520
#10521


support new symbol download url pattern

Is your feature request related to a problem? Please describe.
baget symbol server is not works in VS2017.
in VS2017, it download symbol file like:
http://baget-host/api/download/symbols/Ne/Newtonsoft.Json.pdb/1F194FBE703D4FCFA949C251C3CCCDE4ffffffff/Newtonsoft.Json.pdb
it's not like
http://baget-host/api/download/symbols/Newtonsoft.Json.pdb/1F194FBE703D4FCFA949C251C3CCCDE4ffffffff/Newtonsoft.Json.pdb
so, it not match baget symbol download route rule.
Describe the solution you'd like
we can add a new route rule to fix the problem.
routes.MapRoute(
  name: Routes.SymbolDownloadRouteName,
  template: "api/download/symbols/{prefix}/{file}/{key}/{file2}",
  defaults: new { controller = "Symbol", action = "Get" });

Hello, I wasn't able to reproduce this using Visual Studio 2017. How do you create your package? How do you create your snupkg? Is this a .NET package? What framework are you targeting? If possible, please share a project that when packaged reproduces this issue.

I'm reluctant from blindly adding this in as there's no symbol store key that accepts a "prefix" as described in this issue. Here are all the documented symbol store routes: https://github.com/dotnet/symstore/blob/master/docs/specs/SSQP_Key_Conventions.md

when VisualStudio download symbol file from symbol server, it's request url like this:
/api/download/symbols/Sy/System.Security.Principal.pdb/5A62888E7E5D4690A8261A0F66281F23ffffffff/System.Security.Principal.pdb
I dont know why, but that was the case.
Whether it's Microsoft's server, or other.

It also does not work in VS 2019

In the fiddler capture, we see both {GUID}ffffffff as well as {GUID}1 and it seems that both cases are not considered when doing a lookup of the symbols.


Edb document update

Modified docs for External Database Connector 10.12 release

@MarkvanMents I see you added some small details in your last commit. I don't think they'll incur errors, so I've merged this as we slacked about.


Workaround conda-build 1.20.1

Downgrade to conda-build 1.20.0 on Windows.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


"Parse" (evaluate) generates smaller assembly

I had to write a bit of a helper to mimic what could be core to the ctre api, but here's a compiler explorer link that illustrates the difference.
https://gcc.godbolt.org/z/VDkQA-
This could also be incorporated in the search_re function, if at compile time the for loop is removed. The key part is to be able to analyze the tree and be sure that an ^ anchor token / assert_begin is what sits at the start of the regex, or at all sub expressions.
Simple test add:
template <typename Iterator, typename EndIterator, typename ...Pattern>
constexpr inline auto search_re(const Iterator begin, const EndIterator end, sequence<assert_begin, Pattern...> pattern) noexcept {
	using return_type = decltype(regex_results(std::declval<Iterator>(), find_captures(pattern)));
	using iterator_category = typename std::iterator_traits<Iterator>::iterator_category;
	return evaluate(begin, begin, end, return_type{}, ctll::list<start_mark, sequence<assert_begin, Pattern...>, end_mark, accept>());
}

And the generated assembly becomes identical.

Doing the analysis could be costly in current architecture of CTRE, I'm already doing something similar in case of greedy => possessive cycle optimisation. Anyway something similar as your parse function could be useful meantime. So I added function starts_with
Added in 4c97c59c67d21cf4959bbdf78ae8f8900a2a9d7a

Ok, it was actually easier than I thought :D
Done in ec4bd9750e1d9c66ef62b567567a2f1940052f03

https://compiler-explorer.com/z/nvjG4E

Year or so later, starts_with is definitely a good name over parse 👍 I'll take it. Did my pr on pattern analysis make sense? Or is that still a wash? It would allow you to add a size check on the input string to see if it's within a valid range, it's a bit iffy conceptually for anything like variable length encoded utf8 strings, but otherwise I'd imagine it'd improve performance on more complicated regexs.

I'm not sure about the PR, as you said it would be problematic with variable length encodings, and in future I want to have better support for unicode in general. Also it would introduce check for a length on every input, CTRE is able to work with zero-terminated strings too, which means basically running strlen. And one of the biggest issue is it would introduce longer compilation time due the analysis.

Well in the event those things can be specialized for w/o too hard of a heavy hit on compile times. My thought process was one bounds check per input string might not be too bad* assuming a random access iterator. It could also be limited to inputs where the pattern has particularly large bounds, I'm not sure the throughput of the library off-hand, but I'd imagine there's some rough # of character comparisons where the length check would make sense to do.
Would adding variations of the original functions with bounds checking impact compile times if the functions aren't instantiated? E.G. ctre::match_checked_bounds_re<>()


plugin-form-builder-select-multiple-support

Description

[] I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

[ ] Chore (non-breaking change which does not add functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Change to the templates directory (does not affect core functionality)
[ ] Change to the examples directory (does not affect core functionality)
[ ] This change requires a documentation update

Checklist:

[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Existing test suite passes locally with my changes
[ ] I have made corresponding changes to the documentation

Idea:
<select name="cars" id="cars" multiple>
  <option value="volvo">Volvo</option>
  <option value="saab">Saab</option>
  <option value="opel">Opel</option>
  <option value="audi">Audi</option>
</select>

Example:
const dataToSend = Object.entries(data).map(([field, value]) => ({
  field,
  value: Array.isArray(value) ? value.join(', ') : value,
}));

<select
  id={field.id}
  className="ml-4"
  {...(field.multiple ? { multiple: true } : {})}
  {...register(field.name, { required: field.required })}
>

https://github.com/payloadcms/plugin-form-builder/issues/58
https://github.com/payloadcms/plugin-form-builder/pull/59


[Typo3] assorted changes

@jousch do you have any extra details or links to help explain these changes?

I'll try to explain some of the changes:
Commit "[TYPO3] Remove AdditionalConfiguration.php"
AdditionalConfiguration.php is used for the config-changes that differ from environment to environment. Instead of editing LocalConfiguration.php you can simply switch out the AdditionalConfiguration.php while keeping the main config intact. Quite handy.
[TYPO3] Add temporary files to .gitignore
These files enable access to the install-wizard and the install-tool. They should never be comitted, because it could allow access to external users, that have no access to the file-system.

@M-arcus thanks!


Migrate configuration handling to the confuse lib

This is very much a work in progress, just wanted to be transparent and make the current status visible. The current state is able to run the example config and known minimal configs but needs more testing.
This change touches all integrations and has minor potential for subtle breakage. The following have been thoroughly tested:

Telegram
Pushover

Groundwork for fixing #361

That all makes sense, thanks for the thorough review!

I think this might now be in a sane state, but was only able to test a couple of the notifiers myself. @martomi if you have some test farm for all the notifiers, could you give it a whirl and make sure I didn't miss anything?

I think I've fixed the ones where there was a clear fix. Happy to tidy up the default values if we have a consensus on which source of truth should be the new defaults. My feeling is that it's unlikely many folks have relied on the code defaults and instead have used the example values instead of explicitly deleting those fields from their config. But, alas I have no way of proving that feeling!
I've got the keepalive structural changes and a keepalive emitter for the wallet ready for review once we nail down this bit, just want to rebase them first on top of this one so you get a clean review slate.

Cool - takes for the quick turnaround!
Note that there are a few more inline comments I left in the code above, but they’re collapsed in the middle of the thread by the github UI. Just wanna make sure you saw? In one of them I had provided more context and example for default values.
My take is that we should use the code defaults for the following reasons:

The example config is still going to be taken by new users, so the default YAML has little effect beside keeping the code functionality being identical as how it used to be before this change
There were a substantial number of users that installed chiadog before we introduced most of the configs in the example config. In the process of installing it, they would have created a copy of the very old config example. We never explicitly required them to change their original configs with the new values from the extended example config. Thus they’ll be having a config that is substantially more minimal than the current example. By keeping the defaults same as in the code, we’ll not introduce any unexpected changes for these users.

Oops, not sure why "close" is on by default in review mode. But did not intend to close and now can't reopen :D

Hmm not sure, the reopen button is also grayed out for me. But more importantly, the code-diff is missing, so maybe that’s the main reason? Maybe you rebased on the wrong base?

Yeah, looks like there's no sane way to re-open after a rebase & close. I'll open a new PR.


Hse 1.18

This completes the conversion to hse-1.18.

Oh man, using TH across four versions of GHC is a nightmare.

Hm, the generated code in src/Data/Derive/*.hs is different on ghc-7.8 and ghc-8.0 compared to ghc-7.10. I have no idea why; it only happens with travis and I cannot replicate it. On my box, I get identical output with ghc-7.8, ghc-7.10, and ghc-8.0.

Thanks for your impressive efforts, that's looks like a lot of work has gone into it.
I've never had an issue with different code generated on different versions - that is weird. It should be entirely dependent on the haskell-src-exts version, which makes it all the more weirder, as that is consistent between them.

You're welcome. When I apply for a job at Barclays, I'll mention derive as a project I've been involved with. :)


There is a competition problem with "spiderpool-controller" when creating ippools at the same time.

Describe the version
version about:
spiderpool

v0.2.2

Describe the bug
Manually creating ippools concurrently, the ippool's Informer callback modified the freeIPsCount etc., causing the version number of the spidersubnet resource to change.
This resulted in multiple ippools being created concurrently under a subnet, some of which failed and the following error was obtained.
{"level":"ERROR","ts":"2022-10-13T10:50:18.871Z","logger":"IPPool-Webhook.Validating","caller":"ippoolmanager/ippool_webhook.go:122","msg":"Failed to create IPPool: status.freeIPs: Internal error: failed to update subnet 'v6-ss-5016-938372124', error: Operation cannot be fulfilled on spidersubnets.spiderpool.spidernet.io \"v6-ss-5016-938372124\": the object has been modified; please apply your changes to the latest version and try again","IPPoolName":"v6pool-5018-633033493","Operation":"CREATE"}

The issue was preliminarily solved in #892. We add a retry mechanism to the operation of updating SpiderSubnet status in the SpiderIPPool webhook. However, these codes have been refactored with the idea of Operator in #1019. It can also solve this issue and work better.

mechanism

Ok, thanks for your answer and for adding the solution to the problem #892 #1019，I will close this issue


Banshee.GStreamer: Deinit gst before shutdown

Technically this isn't really necessary but it help to keep valgrind
logs cleaner

Thanks. Still trying to get accustomed to the code base, so excuse me for the lengthy discussion.
On a side note: GitHub has the feature to squash the commits directly during the merge. Look at the arrow on the merge button.

Knew it - thing put the pull request title in the commit message for the squash. I really hate that button - just force-pushed the right commit for this back out.

Don't worry about going through a bit of discussion - that's what issues and pull requests are for, thanks again for the input :+1:

I haven't looked at the native player engine but looking through your commit logs it looks like I made the right choice in sticking with it

Should I create an issue to track this?

Perhaps, yes, I noticed you'd removed the GStreamerSharp backend - I think your message said the bindings library was unmaintained

Exactly. It's unmaintained, doesn't ship with any large distro and it couldn't play a track.
So pretty useless in my opinion :smile:

Agreed, did you get that behaviour even with their master branch?
I remember experimentally trying it out - had to make some changes to Banshee to get it to compile, see bb1ac5, think I tried it out and it was working at the time.


Scheme creation

To help make it more clear what's being changed or added for the scheme creation module, it would be a good idea to have a base branch to merge into so that's why scheme-creation/_base has been created.

Scheme creation relevant feature or change branches should be named scheme-creation/<name of feature> (e.g. scheme-creation/find-discriminatory-snvs) and a pull request should be opened to merge into scheme-creation/_base instead of development.
Subtyping specific and scheme creation specific code, tests and test data will be separate (biohansel/subtype vs biohansel/create, tests/subtype vs tests/create, tests/data/subtype vs tests/data/create) unless there is common function in some utility function.
click will be used instead of argparse
absolute imports only (e.g. from biohansel.subtype.util import whatever instead of from util import whatever; fully qualified path from biohansel)
command-line application has been changed from hansel to biohansel to align with the name change from bio_hansel to biohansel and to reduce confusion.

We have move the scheme creation work to a separate repo for the scheme creation tool BioCanon https://github.com/phac-nml/bioCanon


Controller - Setup custom styles demo page

Also please expanded the current documentation and tests.

Added a simple demo with all the possible text stylings


"Home Page" Field in "Base Application" - Different Length

Hi,
Can you standardize the length of "Home Page" Field in "Base Application" ?
In table 79 "Company Information", it's a Text[80]:
        field(35; "Home Page"; Text[80])
        {
            Caption = 'Home Page';
            ExtendedDatatype = URL;
        }

In table 5714 "Responsibility Center", it's a Text[90]:
        field(103; "Home Page"; Text[90])
        {
            Caption = 'Home Page';
            ExtendedDatatype = URL;
        }

Thanks

It is 80 in most places, except few with 90 chars, but we cannot decrease field length. Is this really critical for any reason?

Of course you cannot decrease field length. But maybe you can all increase to 90, or 100.
"Home Page" field in table 14 "Location" is also a Text[90].
It's not critical, but it was just a note to warn of a possible overflow, ex:
TableX."Home Page-Text[80]" := TableY."Home Page-Text[90]";

We will make a fix for any reported overflow issues, currently didn't get any.


Not showing in Integrations

After install from HACS and restart of hassio, it is not visible in the integrations tab.

You need to add the config via YAML, as a new sensor - I dont think there is a guided way via the GUI

I did that but I get an error saying there is no integration. I watched a video on the steps and for some reason after installing it from HACS it won’t show in my integration tab.  Looking at the files it looks like everting installed fine, except the init.py is blank.

Once you install it from HACS, configure it and restart HA, the integration will appear under HACS Integrations.
This integration does not support configuration flow, so you'll have to configure it via yaml file.
Please double check it under HACS integrations and get back to me with results.

So I went through all the documentation.  I followed everything, but this part is not an option "Anniversaries can be configured on the integrations menu or in configuration.yaml"
When I go into my config file and add the config example:
"# Example configuration.yaml entry
anniversaries:
sensors:

name: Shakespeare's Birthday
date: '1564-04-23'
name: Shakespeare's Wedding Anniversary
date: '1582-11-27'"

I receive the following error:
Component error: anniversaries - Integration 'anniversaries' not found.

I just looked through all the files in the repo and the files are not all present in the custom comments and one of the files is completely blank.  I tried to install it twice from HACS with the same result.

Hello, I am new of all the HA,
I edited my configuration.yaml introducing the example:
platform: anniversary
name: events
multiple: true
anniversaries:

event: 'Doug birthday'
date: '2000-1-15'
event: 'Steve Butabi'
date: '2000-09-15'
icon: mdi:cake-variant
event: 'Chazz birthday'
date: '9-15'
icon: mdi:cake-variant
event: 'Frank the tank'
date: '1998-8-18'

Unfortunately in the configuration verify I got an error: integration not present.
But the integration in the HACS section is loaded and apparently ok.
I previous installed the anniversaries integration but I would like to use the yours.
Where I am wrong?
Thank you so much.

@ryanbrown783  your yaml is wrong - it is a custom sensor platform, not a new "integration".
If you have a seperate sensor.yaml try this:
- platform: anniversary
  name: events
  multiple: true
  anniversaries:
    - event: "A birthday"
      date: '1999-01-20'
      icon: mdi:cake-variant

If you dont, try this in configuration.yaml - @robertolamm  - this is your example:
sensor:
  - platform: anniversary
    name: events
    multiple: true
    anniversaries:
      - event: "A birthday"
        date: '1999-01-20'
        icon: mdi:cake-variant

Note the default format of Date is YYY-MM-DD

Thank you so much @jonwaland  !!!! Very very good integration. And is only the starting point :)

@ryanbrown783 are you sure you were using the amaximus/anniversary custom integration and not the pinkywafer/Anniversaries (https://github.com/pinkywafer/Anniversaries)?
amaximus/anniversary creates only one sensor on the upcoming event while the other one creates sensors for each event.

@robertolamm yesterday I updated the README with examples on how to use the conditional card - custom button card combo to display upcoming events due in couple of days.

This is the main motivation that me chose your one :)
It Is much simple to maintain (the events).
Inviato da iPhone

Il giorno 31 ago 2021, alle ore 10:35, Atticus Maximus @.***> ha scritto:

@ryanbrown783 are you sure you were using the amaximus/anniversary custom integration and not the pinkywafer/Anniversaries (https://github.com/pinkywafer/Anniversaries)?
amaximus/anniversary creates only one sensor on the upcoming event while the other one creates sensors for each event.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@ryanbrown783 do you need further assistance with this issue or it can be closed?

It can be closed. I was being dumb bc there was one called Anniversary and one called Anniversaries. I got the two combined but fixed my stupidity.


Suggestion for heightmap

I suggest people can add splines and models to the scene file in this branch. Also suggest we slow down the day/night-cycle.


Use with Incremental Builds possible?

Would using the new incremental builds Gatsby Incremental Builds bring any benefit to the speed of the build with this plugin?

Bumping this

Javascript doesn't load when incremental deploys are enabled for some builds

Closing this issue as I think @kik-o already answered this. Feel free to reopen it if you want more discussion on it.


Add CONTRIBUTING.md and LICENSE.txt files

Add Contributing guidelines and license to stellar-tutorials.

:+1:


[5.5][Runtime] Fix concurrent _typeByName with generic arguments, protocol conformances, and superclasses.

When constructing generic type metadata, we can end up checking protocol conformances for metadata that isn't fully built, and in particular the superclass field may not be set up yet. Handle this case properly by falling back to looking up the superclass by mangled name from the nominal type descriptor when necessary.
Previously we were just chasing Superclass fields, which would cause us to terminate the search early sometimes when concurrently looking up the same type from multiple threads. When a protocol conformance is on a superclass, this causes the search to fail incorrectly, causing type lookup failures.
This only arises on the very first attempt to instantiate a given type, since the lookup will be cached (and all metadata fully initialized) after the first success.
rdar://72583931
(cherry picked from commit a80fe8536bdb06f0eb6e6020a7ce3cf487dc2ca9)

@swift-ci please test

@swift-ci please test Windows platform


Struct containing UDTs doesn't deserialize

Values get properly inserted.  Then selected from Scylla no problem:
SELECT RESULT:
QueryResult { rows: Some([Row { columns: [
Some(Uuid(86bfcb0c-3fea-424a-a44d-fb1ba73db6bb)),
Some(Uuid(28e499f7-04f4-484e-ae43-84f83d3e616f)),
Some(List([
UserDefinedType { keyspace: "my_keyspace", type_name: "building_block", fields:
[("id", Some(Uuid(d8eec8f6-674e-49d6-b061-67e8e7599c93))), ("owner_id", Some(Uuid(660abd60-8e39-4897-b502-cb79708d6227))), ("locked", Some(Boolean(false))), ("asset_id", Some(Int(12345)))] },
UserDefinedType { keyspace: "my_keyspace", type_name: "building_block", fields: [("id", Some(Uuid(4bc63c4c-3fc6-418c-9ee8-6fe1dc07fdeb))), ("owner_id", Some(Uuid(970602aa-dd19-42b7-aac7-4b0e6726fd0b))), ("locked", Some(Boolean(true))), ("asset_id", Some(Int(56789)))
] }])),
Some(UserDefinedType { keyspace: "my_keyspace", type_name: "coordinates", fields: [("x_axis", Some(Float(11.1))), ("y_axis", Some(Float(-22.2))), ("z_axis", Some(Float(33.3)))] })] }]),
warnings: [],
tracing_id: None,
paging_state: None,
col_specs: [ColumnSpec { table_spec: TableSpec { ks_name: "my_keyspace", table_name: "prefabs" }, name: "owner_id", typ: Uuid }, ColumnSpec { table_spec: TableSpec { ks_name: "my_keyspace", table_name: "prefabs" }, name: "id", typ: Uuid }, ColumnSpec { table_spec: TableSpec { ks_name: "my_keyspace", table_name: "prefabs" }, name: "blocks", typ: List(UserDefinedType { type_name: "building_block", keyspace: "my_keyspace", field_types: [("id", Uuid), ("owner_id", Uuid), ("locked", Boolean), ("asset_id", Int)] }) }, ColumnSpec { table_spec: TableSpec { ks_name: "my_keyspace", table_name: "prefabs" }, name: "location", type: UserDefinedType { type_name: "coordinates", keyspace: "my_keyspace", field_types: [("x_axis", Float), ("y_axis", Float), ("z_axis", Float)] } }], serialized_size: 194 }
THE PROBLEM  !!!
Then this error deserializing with first_row_typed (or any other similar methods I tried).  Makes no sense, column 2 which is fabrications clearly has 2 values in the query result.
first_row_typed RESULT:
Err(FromRowError(BadCqlVal { err: ValIsNull, column: 2 }))
thread 'components::prefabrication::tests::prefab_persistence_works' panicked at 'called Result::unwrap() on an Err value: FromRowError(BadCqlVal { err: ValIsNull, column: 2 })',
(This approach works from cqlsh no problem)
I use scylla driver  version 0.8.1 and scylla from docker image scylladb/scylla:5.2.0
Table creation:
CREATE TYPE my_keyspace.coordinates (x_axis Float, y_axis Float, z_axis Float);
CREATE TYPE my_keyspace.building_block (id UUID, owner_id UUID, locked Boolean, asset_id Int);

CREATE TABLE IF NOT EXISTS my_keyspace.prefabs (
fab_id UUID,
owner_id UUID,
fabrications list<frozen<my_keyspace.building_block>>,
location my_keyspace.coordinates,
PRIMARY KEY(fab_id, owner_id)
);

My structs:
# THIS is the typed struct that corresponds to the table my_keyspace.prefabs

#[derive(Debug, Clone, PartialEq, FromRow, ValueList)]
pub struct Prefabrication {
    pub fab_id: Uuid,
    pub owner_id: Uuid,
    pub fabrications: Vec<BuildingBlock>,
    pub location: Coordinates,
}

# This is the first UDI in the table

#[derive(Debug, Clone, PartialEq, IntoUserType, FromUserType)]
pub struct BuildingBlock {
    pub block_id: Uuid,
    pub owner_id: Uuid,
    pub locked: bool,
    pub asset_id: i32,
}

# This is the second UDI in the table

#[derive(Debug, Clone, PartialEq, IntoUserType, FromUserType)]
pub struct Coordinates {
    x_axis: f32,
    y_axis: f32,
    z_axis: f32,
}

Please note that I also tried without List/Vec of BuildingBlock and replaced with just a single one to rule out  this causing a problem but had exact same error.

Then this error deserializing with first_row_typed (or any other similar methods I tried). Makes no sense, column 2 which is fabrications clearly has 2 values in the query result.
first_row_typed RESULT:
Err(FromRowError(BadCqlVal { err: ValIsNull, column: 2 }))

Could you show us the query string? When deserializing results to a type that implements FromRow, the order of columns defined in the SELECT query must be the same as the order of struct fields. The column: 2 refers to the second (counting from zero) column as defined in SELECT. Maybe you have a mismatch here and a different column than fabrications is actually null.
In general, if you have a column that can be null, you should wrap the corresponding rust struct field in an Option.

Then this error deserializing with first_row_typed (or any other similar methods I tried). Makes no sense, column 2 which is fabrications clearly has 2 values in the query result.
first_row_typed RESULT:
Err(FromRowError(BadCqlVal { err: ValIsNull, column: 2 }))

Could you show us the query string? When deserializing results to a type that implements FromRow, the order of columns defined in the SELECT query must be the same as the order of struct fields. The column: 2 refers to the second (counting from zero) column as defined in SELECT. Maybe you have a mismatch here and a different column than fabrications is actually null.
QUERY STRING: SELECT * FROM my_keyspace.prefabs where fab_id = ? and owner_id = ?;

Please note that I included the entire QUERY RESULT first thing in the description of the issue.   It looks perfect with column # 2 being a List of 2 UDTs (so everything got selected as expected on the Scylla end).  No values in there are null and they are in the same order as the struct indeed.

In general, if you have a column that can be null, you should wrap the corresponding rust struct field in an Option.
Thanks! Good point.  I will keep that in mind.   No nullable columns for my current use case though.

Just in case, here is troubleshooting code that splits query results and deserialization:
``let qres = session.query(scylla_db::SELECT_PREFAB_QUERY, (id, owner_id))
.await?;
println!("SELECT RESULT: {:?}", qres);
let res = qres
.first_row_typed::();
println!("first_row_typed RESULT: {:?}", res);

PLEASE NOTE:  There are no examples complex as mine.   But from documentation annotating UDTs and Structs it should just work or at least give a more reasonable error.  (Based on what you told me seems like it actually IS a bug)

I think I know where the problem lies. I see that in case of the BuildingBlock Rust struct its field names do not correspond to the UDT field names. For Rust you have block_id, owner_id, locked, asset_id and in case of the UDT you have id, owner_id, locked, asset_id. Both names and the order must match for a UDT to be deserialized properly, and in your case the first two don't match.
The reason why you got a ValIsNull error is because the UDT deserialization logic tries to match the Rust and UDT names one to one and, if there is a mismatch, the Rust field is skipped and treated as if it were null:
quote_spanned! {field.span() =>
    #field_name: <#field_type as FromCqlVal<::std::option::Option<CqlValue>>>::from_cql(
        {
            let received_field_name: Option<&::std::string::String> = fields_iter
                .peek()
                .map(|(ref name, _)| name);

            // Order of received fields is the same as the order of processed struct's
            // fields. There cannot be an extra received field present, so it is safe to
            // assign subsequent received fields, to processed struct's fields (inserting
            // None if there is no received field corresponding to processed struct's
            // field)
            if let Some(received_field_name) = received_field_name {
                if received_field_name == stringify!(#field_name) {
                    let (_, value) = fields_iter.next().unwrap();
                    value
                } else {
                    None
                }
            } else {
                None
            }
        }
    ) ?,
}

It looks like the code assumes that this is an extra field and decides to skip it, treating it as if it were null.
In https://github.com/scylladb/scylla-rust-driver/pull/665 we are going to introduce new macros with more features and better error reporting, and FromRow + FromUserType will be deprecated. We've always had an implicit assumption that the field order must match, including field names - we should document it more clearly for the old macros. I'm not sure if it is worth changing the behavior of the old ones at this point.

Whew!   I literally made sure table matches my main struct and thought I had UDT fields matching as well, except that id vs. block_id in the building block UDT.   Definitely would be nice to have a friendlier error!  But for now this fixed my issue!! Woo-hoo!   Thanks so much for getting back to me so quickly and resolving my issue Piotr! @piodul

The problem was really misleading error messages when there was a column name that didn't match the UDT struct field name.    The functionality works as expected!


Modify index page

Fix #103

Nothing else to add to @RobPasMue review in here. Thanks for taking a look to it, Roberto. Also, thanks for implementing this, @Revathyvenugopal162.


[Tooltip] - hiding of the tooltip on the table hides it everywhere

It looks like the option to hide a tooltip is binned to the dataframe, not to individual visualizations.
Acceptance criteria:

The option to hide the tooltip is binned to the visualizations instead of entire dataframe

Implemented in DG 1.6.4
To hide a tooltip for a table (grid), set the grid property 'Show tooltip' to 'do not show' (it switches the tooltip to custom and hides it).

It can be done for all grids programmatically (grok.events.onViewerAdded), if this is the desired default behaviour for the ID app.
Viewers that use the default tooltip (grid, scatter plot, box plot + PC plot and heatmap in the future) now have two separate tooltip modes (custom and default). Such things as tooltip visibility, form template, selected columns for a tooltip are handled separately. Custom tooltips are set on a viewer instance level (e.g., if you have two grid viewers and want to hide tooltip on both, while using the default tooltip for other viewers, you'll need update properties for both grids).
Can be verified on https://public.datagrok.ai/ [release version 1.6.4]
In addition, you can find some test cases here: https://github.com/datagrok-ai/public/blob/master/help/_internal/tests/tooltip.md


[GE] - Lines get left on the canvas when dragging a GUI button

When dragging a GUI button on the canvas, lines are being left behind and stick to the canvas.

Status update: Think I got this one, coming in the next PR.

Status update: Think I got this one, coming in the next PR.


Complex, ordered multi-command input for Molpro

Is your feature request related to a problem? Please describe.
Molpro input files are very complex, and depend on an imperative programming structure. For example, CCSD can only be performed after a HF command. This leads to very complicated input files, such as the following:
memory,300,m

symmetry,nosym
geometry=geo.xyz

basis=cc-pVDZ

gthresh,ENERGY=1e-10
{df-rhf,;save,2100.2}

{ibba,antibonds=1,THRLOC_IB=1e-12;freezecore;orbital,2100.2}
{locali,boys;print,orbital;fock,2100.2;order,type=fock}

{df-lccsd(t),chgfrac=1.0,canblk=0;core,6}

I want a way to specify this input file inside an AtomicInput.
Describe the solution you'd like
A format for specifying commands, in order. Each command must support args, kwargs, and directives. Directives themselves have args and kwargs. args and kwargs are not ordered. Directives are not ordered. (@sjrl please verify this last point).
One possible format would be:
keywords["commands"]: List[Commands]

class Directive:
    name: str
    args: Optional[List[Union[str,int,bool,float]]]
    kwargs: Optional[Dict[str, Union[str,int,bool,float]]

class Command(Directive):
    directives: Set[Directive]

Under this structure, the above input file would become:
method = "df-lccsd(t)"
basis = "cc-pVDZ"  # note that this replaces the basis command
molecule = Molecule.from_file("geo.xyz")
keywords = {
    "memory": 300,
    "symmetry": "nosym",
    "gthresh": "energy=1e-10",  # gthresh is weird, and this is a lame solution
    "commands": [
        {"name": "df-rhf", "directives": {{"name": "save", "args": ["2100.2"]}}},
        {
            "name": "ibba",
            "kwargs": {"antibonds": True, "thrloc_ib": 1e-12},
            "directives": {
                {"name": "freezecore"},
                {"name": "orbital", "args": ["2100.2"]},
            },
        },
        {
            "name": "locali",
            "args": ["boys"],
            "directives": {
                {"name": "print", "args": ["orbital"]},
                {"name": "fock", "args": ["2100.2"]},
                {"name": "order", "kwargs": {"type": "fock"}},
            },
        },
        {
            "name": "df-lccsd(t)",
            "kwargs": {"chgfrac": 1.0, "canblk": 0},
            "directives": {{"name": "core", "args": [6]},},
        },
    ],
}

Describe alternatives you've considered

Template files (current solution).
dunder representation of nested dictionaries. Will lead to extremely long strings, and does not have the necessary ordered property of commands.

@loriab @sjrl

Directives are not ordered. (@sjrl please verify this last point).
That is correct, directives of a given command are not ordered. As a side tangent directives can be placed on new lines instead of the semicolon separation to partially alleviate the limit on the width of Molpro's input.

I like this idea a lot! I only have a few questions and comments.
First I think we can continue to handle symmetry and memory through the existing AtomicInput (handled through molecule and build_input() respectively), which would only leave us with gthresh and commands. I like the commands structure because we can easily check for the presence of that keyword to replace the method writing in build_input().
gthresh is definitely a little trickier, but it is an example of Molpro directive that is specified without the need of a command. So we could potentially have a directives keyword that lives outside of commands and we could throw gthresh into that. How does that sound?

I think directives is a good solution to gthresh. So keywords["directives"]: Optional[Set[Directive]]?

So keywords["directives"]: Optional[Set[Directive]]?

Yup! So the only thing that this structure wouldn't support is the ability to set directives in between commands. In some complicated inputs (I believe @loriab has some examples) Molpro sets directives in between commands.
Here is a quick example for a PNO calculation in Molpro
{df-hf,basis=vdz}
{local,distp=8,maxit_lmp2=1,thrpno_en_lmp2=0.998,thrpno_occ_lmp2=0,thrdist=0,fitmos=0,fitpao=0,thrpno_dist=0.998,keep_diag=0}
{cfit,locfit=0}
{pno-lmp2,distp=0}

I guess in my above example, we could just use the commands structure and do something like
"commands": [
    {"name": "df-hf",},
    {
      "name": "local",
      "kwargs": {"distp": 8, "maxit_lmp2": 1, "thrpno_en_lmp2": 0.998, ...}
    },
    {
      "name": "cfit",
      "kwargs": {"locfit": 0}
    },
    {
      "name": "pno-lmp2",
      "kwargs": {"distp": 0}
    }
]

if you wanted to specify directives in between commands.

We could explicitly say keywords["commands"]: List[Commands, Directives] just to make things abundantly clear.
Another question is whether method should do anything other than just provide a convenient summary keyword. For example, we could require that the last command's name is the same as method.

I would vote for method == commands[-1]["name"]. This would make the return_result make at least some sense.

@sjrl Any weird molpro edge cases that will break this? I'm okay with not supporting proc, force, weirdly-placed GDIRECT, to name a few...

Hmm I do wonder, how is this meant to interact with the driver call? If the driver is gradient does that mean force should still be added after all commands are written?
And for requiring method == commands[-1][name] this would mean we would have methods like df-mp2 or ump2, which have modifiers in front of the actual method. I believe we were trying to avoid this by having to specify keywords instead. But in the situation that commands is provided is it alright to relax on this rule?
To clarify one more point. Does the presence of commands mean that the input builder ignores all other keywords related to the method such as reference = unrestricted?
Otherwise everything looks good to me! I can't think of any other edge cases and I agree proc and GDIRECT can be left alone.

Hmm I do wonder, how is this meant to interact with the driver call? If the driver is gradient does that mean force should still be added after all commands are written?

Yes. Would this also work for hessians?

And for requiring method == commands[-1][name] this would mean we would have methods like df-mp2 or ump2, which have modifiers in front of the actual method. I believe we were trying to avoid this by having to specify keywords instead. But in the situation that commands is provided is it alright to relax on this rule?

After looking at various programs (and especially GAMESS), @dgasmith and I have moved toward letting method just be whatever the program wants it to be called. So if Q-Chem calls density-fitted MP2 "RI-MP2", and Molpro calls it "df-rmp2", and entos calls it simply "mp2", then that's okay. It's too much work -- and potentially impossible -- to make the methods program-independent. The only place I would be careful is that I would like to normalize known aliases within a program. For example, "HF" and "RHF" do the same thing in Molpro.

To clarify one more point. Does the presence of commands mean that the input builder ignores all other keywords related to the method such as reference = unrestricted?

Non-command keywords would get translated to key=value at the top of the file. AFAIK reference is a special keyword present only in MolproHarness's build_input and would be removed in favor of specifying spin ansatz in the command name.

Otherwise everything looks good to me! I can't think of any other edge cases and I agree proc and GDIRECT can be left alone.

👍

Would this also work for hessians?

I believe so, although I don't have much experience with hessian calculations in Molpro.

After looking at various programs (and especially GAMESS), @dgasmith and I have moved toward letting method just be whatever the program wants it to be called. So if Q-Chem calls density-fitted MP2 "RI-MP2", and Molpro calls it "df-rmp2", and entos calls it simply "mp2", then that's okay. It's too much work -- and potentially impossible -- to make the methods program-independent. The only place I would be careful is that I would like to normalize known aliases within a program. For example, "HF" and "RHF" do the same thing in Molpro.

Okay gerat! That all sounds good to me.

Non-command` keywords would get translated to key=value at the top of the file. AFAIK reference is a special keyword present only in MolproHarness's build_input and would be removed in favor of specifying spin ansatz in the command name.

That is correct reference is something I added back when ump2 was not preferred. I'm happy to have that removed!

Okay, it looks like we've reached consensus on this.

Yeah, sorry, I went to work on these new ideas last week, then got distracted by other projects. I don't have a final proposal, so here are some points.

definitely agree that need another construct for ordered commands

After looking at various programs (and especially GAMESS), @dgasmith and I have moved toward letting method just be whatever the program wants it to be called. So if Q-Chem calls density-fitted MP2 "RI-MP2", and Molpro calls it "df-rmp2", and entos calls it simply "mp2", then that's okay. It's too much work -- and potentially impossible -- to make the methods program-independent. The only place I would be careful is that I would like to normalize known aliases within a program. For example, "HF" and "RHF" do the same thing in Molpro.

I'll interject that I see this as two issues. I totally agree that it's not qcng/qcsk's role to make the methods program-independent -- that is, mp2 in prog A is same mtd/answer as mp2 in prog B. I do see it as a proper role to defend the data layout of QCSchema that only method info appears in model.method and that routing info (e.g., tce) or algorithm info (e.g., ri) be slotted in the grab bag that is keywords (or in an extras prefix/suffix field of model maybe if that's convenient for reconstituting).

here's another molpro input to consider

GTHRESH,ZERO=1.e-14,ONEINT=1.e-14,TWOINT=1.e-14,ENERGY=1.e-8,ORBITAL=1.e-8,GRID=1.e-8

 basis={
 set,orbital; default,aug-cc-pVTZ
 set,jkfit;   default,aug-cc-pVTZ/jkfit
 set,dflhf;   default,aug-cc-pVTZ/jkfit
 set,mp2fit;  default,aug-cc-pVTZ/mp2fit
 }

 gdirect
 ga=1101.2; gb=1102.2
 ca=2101.2; cb=2102.2

 dummy,14,15,16,17,18,19,20,21,22,23,24,25,26
 {df-hf,basis=jkfit,locorb=0; start,atdens; save,$ga}
 {df-ks,lhf; dftfac,1.0; start,$ga; save,$ca}
 eehfa=energy; sapt;monomerA

 dummy,1,2,3,4,5,6,7,8,9,10,11,12,13
 {df-hf,basis=jkfit,locorb=0; start,atdens; save,$gb}
 {df-ks,lhf; dftfac,1.0; start,$gb; save,$cb}
 eehfb=energy; sapt;monomerB

 {sapt,SAPT_LEVEL=3;intermol,ca=$ca,cb=$cb,icpks=0,fitlevel=3,nlexfac=0.0,cfac=0.0
 dfit,basis_coul=jkfit,basis_exch=jkfit,cfit_scf=3}
 eedisp=E2disp

Below is my rough expression of the above in "dunder" format. An obvious weakness is the handling of options associated with repeated commands.

					# commands: [
					#   gthresh,
					#   gdirect,
					#   {ga: 1101.2},
					#   {gb: 1102.2},
					#   {ca: 2101.2},
					#   {cb: 2102.2},
					#   dummy,
					#   df-hf,
					#   df-ks,
					#   {eehfa: energy}
					#   sapt

GTHRESH
    ,ZERO=1.e-14			# gthresh__zero: 1.e-14
    ,ONEINT=1.e-14			# gthresh__oneint: 1.e-14
    ,TWOINT=1.e-14			# gthresh__twoint: 1.e-14
    ,ENERGY=1.e-8			# gthresh__energy: 1.e-8
    ,ORBITAL=1.e-8			# grhresh__orbital: 1.e-8
    ,GRID=1.e-8				# gthresh__grid: 1.e-8

 basis={
 set,orbital; default,aug-cc-pVTZ
 set,jkfit;   default,aug-cc-pVTZ/jkfit
 set,dflhf;   default,aug-cc-pVTZ/jkfit
 set,mp2fit;  default,aug-cc-pVTZ/mp2fit
 }

 gdirect
 ga=1101.2; gb=1102.2
 ca=2101.2; cb=2102.2

 dummy					# dummy: [14, 15, 16, ... 26]
    ,14
    ,15
    ,16,17,18,19,20,21,22,23,24,25,26

 {df-hf
    ,basis=jkfit			# see below
    ,locorb=0
  ; start
    ,atdens
  ; save
    ,$ga}

 {df-ks					# see below
    ,lhf
  ; dftfac
    ,1.0
  ; start
    ,$ga
  ; save
    ,$ca}

 eehfa=energy; sapt;monomerA

 dummy,1,2,3,4,5,6,7,8,9,10,11,12,13

 {df-hf
    ,basis=jkfit			# df-hf__basis: jkfit
    ,locorb=0				# df-hf__locorb: 0
  ;start
    ,atdens				# df-hf___start: atdens  # or [atdens]
  ;save
    ,$gb}				# df-hf___save: $gb

 {df-ks
    ,lhf				# df-ks__
  ;dftfac
    ,1.0				# df-ks___dftfac: 1.0  # or [1.0]
  ;start
    ,$gb				# df-ks___start: $gb
  ;save
    ,$cb}				# df-ks___save: $cb

 eehfb=energy; sapt;monomerB

 {sapt
    ,SAPT_LEVEL=3			# sapt__sapt_level: 3
  ;intermol
    ,ca=$ca				# sapt___intermol__ca: $ca
    ,cb=$cb				# sapt___intermol__cb: $cb
    ,icpks=0				# sapt___intermol__icpks: 0
    ,fitlevel=3				# sapt___intermol__fitlevel: 3
    ,nlexfac=0.0			# sapt___intermol__nlexfac: 0.0
    ,cfac=0.0				# sapt___intermol__cfac: 0.0
  ;dfit					# sapt___dfit__basis_coul: jkfit
    ,basis_coul=jkfit			# sapt___dfit__basis_exch: jkfit
    ,basis_exch=jkfit			# sapt___dfit__cfit_scf: 3
    ,cfit_scf=3}

 eedisp=E2disp

Sorry to be pushing back a bit against the perfectly good repr of complex inputs proposed in this issue. I worry that it violates the below from the infamous #70. By expressing the command and full options set all together, it makes it hard to specify or change a single option using a syntax that works across a variety of programs.

Keywords should be independent and granular such that they're approximately 1:1 with
other programs, not 5:1. That is, no single method option should cover convergence, algorithm, and target roots all wrapped together. Also, separate, yet mutually exclusive, options sets are a last resort (e.g., three independent boolean options for rhf/uhf/rohf).

from above

"commands": [
    {"name": "df-hf",},
    {
      "name": "local",
      "kwargs": {"distp": 8, "maxit_lmp2": 1, "thrpno_en_lmp2": 0.998, ...}
    },
    {
      "name": "cfit",
      "kwargs": {"locfit": 0}
    },
    {
      "name": "pno-lmp2",
      "kwargs": {"distp": 0}
    }
]

I presume the user in your plan enters model.method = 'pno-lmp2', and the df-hf, cfit, and pno-lmp2 commands+directives get filled in by the write_input in the harness. If the user wants to tweak maxit_lmp2 (or some other piece they're methodologically allowed to tweak), do they have a whole
{
      "name": "local",
      "kwargs": {"maxit_lmp2": 2}
    },

section? Is the harness prepared to handle that that's not the full directive but a delta?

I think the plan for the above use of the commands keyword is to completely replace the model.method when writing the input file. So a kind of replacement for current template implementation for the Molpro Harness. And for the very good point you bring up with issue https://github.com/MolSSI/QCEngine/issues/70 I don't see how we can satisfy this goal and also have templates. But perhaps I am missing something?
The delta example you provide I believe can be made a separate task where the commands keyword is not provided, and then we rely on write_input on knowing how to handle the method pno-lmp2 and what keywords it supports.


Fix decrement of reference count

~(As a bonus, I've removed the val-suffixed versions, which weren't being used at all and were adding no value.)~ UPDATE: Nevermind.
Fixes #64791.

Why not consider using signed integer for the reference count?
I think it makes sense that we get a negative number here. Getting -1 or -2 instead of 0 helps me find the problem faster when we debug the program (as I am binding the JavaScript language).

My only concern is how much overhead this adds. If it's negligible, then it's fine. Otherwise, maybe it would be better to add a debug-only check to unreference() or the SafeRefCount methods. Let's keep in mind that manually incrementing and decrementing the refcount is not something the average user should do. And for things like language bindings, it's their responsibility to handle it properly.

I was even considering removing the somewhat duplicate functionality; i.e., keep only the (un)ref() functions in SafeRefCount with an optional pointer to get the value if the caller wants it, but that's out of the scope of this PR, which just aims to fix the wraparound of the ref count.
Performance-wise, you can never be sure without measuring, but this shouldn't be noticeable.

Why not consider using signed integer for the reference count? I think it makes sense that we get a negative number here. Getting -1 or -2 instead of 0 helps me find the problem faster when we debug the program (as I am binding the JavaScript language).

If I understand your suggestion correctly, decrement would be kept unconditional, but increment would still be there to disallow the count from jumping back from 0 to 1. I think that can work just fine.
However, I'm not very fond of the idea that the negative values reach the caller; in other words, the negatives would be an implementation detail of SafeRefCount:
	_ALWAYS_INLINE_ uint32_t unrefval() {
		int32_t rc = count.decrement();
		return rc < 0 ? 0 : (uint32_t)rc;
	}

So, without disregarding the value of such a potential optimization, the way I see the situation we would pay the cost either of having awkward code to hide the implementation detail or that of exposing it, spilling the optimization into the scope of the caller.

Rebased.

To update this, based on Godot RC conversation with @reduz, this PR (or the alternative with a signed RC) is not the appropriate way to avoid the issue. It shouldn't happen in the first place, so no code should be attempting to detect and prevent it.

I guess it might still make sense to add some ERR_FAIL checks if these conditions are not meant to happen. With an appropriate error message it should already make it clear to users when they're wrongly using those methods.

PR repurposed to warn the misusing developer. Please re-review.

Thanks!


Search – Pinned chat in offline mode is not displayed in pinned chats on Search

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.39-0
Reproducible in staging?: Y
Reproducible in production?: N/A - new feature, doesn't exist in prod
Issue was found when executing this PR: https://github.com/Expensify/App/pull/49186
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause Internal Team
Action Performed:

Open staging.new.expensify.com
Go to Troubleshoot> Go offline
Go to LHN> Right click> Pin a conversation
Go to Search> Chats> Pinned

Expected Result:
Pinned chat in offline mode should be displayed in pinned chats results in Search
Actual Result:
Pinned chat in offline mode is not displayed in pinned chats results in Search
Workaround:
Unknown
Platforms:

[x] Android: Native
[x] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/ab9e4374-a839-4a91-86f0-b4c0310a5242

View all open jobs on GitHub

We think that this bug might be related to #wave-control

Feature added in https://github.com/Expensify/App/pull/49186

@luacmartins

This is expected. Search doesn't work offline. Closing.


[YUNIKORN-1090] remove common.Node from the shim

What is this PR for?
Enhanced si_helper methods to create/update/delete node request and use these methods directly instead of using common.Node method wrappers to avoid the unnecessary object creations. Also re-used the methods in other place as well.
What type of PR is it?

[ ] - Refactoring

Todos

[ ] - Task

What is the Jira issue?
https://issues.apache.org/jira/browse/YUNIKORN-1090
How should this be tested?
Screenshots (if appropriate)
Questions:

[ ] - The licenses files need update.
[ ] - There is breaking changes for older versions.
[ ] - It needs documentation.

Mostly LGTM, I added two minor comments.

Observed few more things while doing this clean up:

I can see few more places where SchedulerNode properties gets updates without having lock mechanism in place. For example, schedulerNode.occupied = common.Add(schedulerNode.occupied, resource) in updateNodeOccupiedResources method
I think we should start exploring and see if sync.Map makes sense instead of using map given the no. of reads and writes it is going through.

Please share your views.

Observed few more things while doing the clean up:

I can see few more places where SchedulerNode properties gets updated without having proper lock mechanism in place. For example, schedulerNode.occupied = common.Add(schedulerNode.occupied, resource) in updateNodeOccupiedResources method. We should call setOccupiedResource here.

We should look at all those and we might need to get this fixed throughout. A follow up jira would be the right approach here.

I think we should start exploring and see if sync.Map makes sense instead of using map given the no. of reads and writes it is going through.

The number of writes is minimal. Node updates should not happen at a high rate, not even in large clusters. Reads do occur more often. Optimising the performance of this access would most likely not affect the overall performance. sync.Map also has a different behaviour when ranging over entries which could cause small but really difficult to track down bugs.

Among multiple conditions discussed in https://kubernetes.io/docs/concepts/architecture/nodes/#condition, only "Ready" has been used. Should we use other conditions as well to determine a generic isNodeHealthy factor and eventually passing to core rather than depending on only one condition?

That is surely worth considering. We should file a follow up jira and assess what we can do in this area.


Error Catching

Adds some error catching during the startup process to help identify what could possibly go wrong without forcing them to go into the console

As addition. I can see three groups:

Developer errors - those "could" be solved by cogh, cough tests 😂 and monitored using error monitoring tools (Sentry or Bugsnag have free plans)
Server side config - maybe some validation? if it's wrong, many things could go wrong...
Client side config/filters - for starter some catch and popup with "Your filters/config are broken. You can download them  and restore defaults using button below."

Server side could definitely use some TDD, client side tests are pretty overwhelming at this point though... TypeScript would also make a big difference.
Validation for the config would definitely help...TypeScript
I was thinking for client side errors I could add a GraphQL endpoint that would be for error logging. Then add try/catch blocks in the more complex/logic heavy components to report any errors to that endpoint, that way they're then logged and available for admins to see.
I'm guessing that most users aren't reporting client side errors so it could help quite a bit, if I actually committed to adding try/catch in enough components. We get the user perms in the graphql endpoint as well so errors could be replicated more easily.

Going to come back to this when I'm ready to do a full error catching implementation.


Update new messager?

I  want to be notified when there are new messages, what should I do?

See https://core.telegram.org/tdlib/getting-started.

Update me on new message


Progress update 2

Ok changelog... lets see what we've gots.
Changes to note
The following may effect existing code and implementation, if you disagree with these changes or it breaks something you are using lets discuss.

Lazy initialize class static context.

Moved the static block evaluation to  to be initialised only when needed.

This has the following impact:
global_var = 1;
class AB {
   static int lazy = global_var;
}
global_var = 2;
assertEquals(2, AB.lazy); // lazy initialise
global_var = 3;
assertEquals(2, AB.lazy);

Java 9 and 10 with --illegal-access=deny passes

JDK9+ does not have rt.jar anymore gracefully ignore boot class path
Skip accessibility tests if haveAccessibility false. We assume that you have accessibility to test accessibility.
compile and run tests with accessibility=false (default) now succeeds with --illegal-access=deny with Java 9 or Java 10. Add jdk9 with --illegal-access=deny to travis script

Tests all pass!!!!! Whoop whoop.
Time to break things again so let those tests roll in.

If run with -Daccessibility=true all tests are executed and should succeed. Travis build.
default is still accessibility false for which there are 5 tests that are skipped.

No access modifiers (java's package private) is now public

this is the default behaviour ,regardless of accessibility, if no access modifiers (or package private) bsh default is public visibility
includes class, constructor, methods and fields

The setAccessibility solution, governed via a static variable Capabilities.hasAccessibility() is of course not thread safe Java 10 appears to be reluctant to change accessibility and appears to blatantly refuse certain illegal access like package private constructors etc. Is it worth the effort? This is why the move towards pubic first makes sense and perhaps it is time we get rid of setAccessible too? Thoughts?

Completed merge with pejobo/beanshell2

We are now up to date, all enhancements deemed useful were merged from the beanshell2 fork.

Update dependency modules

ph-javacc-maven-plugin version 4.x uses the new javacc fork ParserGeneratorCC see https://github.com/phax/ParserGeneratorCC don't have an opinion yet seems like half a dozen of the same.
TokenMgrError was made redundant by ParserGeneratorCC so we remove it as well
added bsh.debugClasses as a system property for specifying the location to save generated class files.

New features

Varargs method implementation.

added ELLIPSIS to the grammar and let FormalParameter receive isVarArgs token.
implemented Types.isSignatureVarargsAssignable for method signature comparison.
make type parameter an array of Type if isVarArgs
implement method invocation and appropriate type casting for isVarArgs

Implement interfaces

interfaces are now GeneratedClasses with bshstatic This namespace
implemented public static final constant fields
Implement interface methods (default and static)
implement interface static methods, only accessible on interface
implement interface default methods, inherited by class, overridden by class or interface extends, accessible as class instance method

implemented try-with-resources

added new grammar for try TryWithResources and AutoCloseable
implemented BSHAutoCloseable as a subclass of BSHTypedVariableDeclaration to reuse the variable evaluation.
BSHTryWithResources acts as the collection of resources and interface for evaluating and closing the resources.
added a lookup for 1st Block node to BSHTryStatement to avoid the use of magic numbers
on eval start if the 1st Node is TryWithResources we keep a reference and call eval which will create the variables in the namespace in callstack
in the finally block of the try block evaluation, if we have a reference to BSHTryWithResources we auto close, which ensures that all resources are closed.
suppressed on close exceptions will be collected in the target exception from the try block

Implement try multi catch

add grammar to parse multi catch
implement evaluation of catch block with a list of types
improve check assignability to avoid the previous try fail catch continue manoeuvres
enable ability to throw throwable and subtypes - previously limited to exception types only
added some simple multi catch tests

Abstract methods implemented validation and inheritance rules.

validate abstract methods are implemented or class declared abstract
bsh classes are virtual abstract only or iow abstract classes can be instantiated
apply inheritance rules overridden methods may not reduce visibility

Implemented Final modifier validation

improved final re-assignment validation
fixed final static is set validation includes static block assignment
fixed instance final variable set includes constructor assignment
added final class cannot extend validation
added final method cannot override validation

Generics/Type parameters re-implemented.

re-approached the generics issue, made all generics parseable and cleaned up the grammar
implemented generics raw types, by type casting single character class name not found to java.lang.Object
resolved the "null fromValue" bug
resolves 10 previously failing tests now not marked as known issues to be skipped anymore
collected all the generics tests into a new unit test TypeParameters test with several test additions
Improved generics capture.
Correctly capture nested type parameters, with tests.
Correctly ignore < and > in if statements.

Loose-typed object fields.

make loose typed fields proper citizens
infer loose typed field type from value at assignment
expose namespace variables as object fields
expose namespace fields for inheritance

Implement variable declared array.

Implementation of byte array[] = new byte[0];
Allow multi dimensions
Include primitive and object typed arrays

Implement JDK7 number literal additions.

implement the JDK7, aka  project coin, number literal additions
add binary number literals ex. 0b010101
correctly parsing and processing underscores in numeric literals 0B_0111_1101

Upgrade servlet jar and added run_servlet.sh

Added script to download jetty servlet container to target folder, create a flat war structure and start the servlet container.

Fixes Improvements

Fix calling overridden method from child instance

correct preference for choosing overridden method based on class hierarchy
fix bug loosing correctly chosen class method
fix initialise class instance This and instance init for calling overridden method from super constructor
fix inherit loose-typed class instance fields
less specific is assignable by most specific unless signature is a match
improved varargs matching no argument or null type as varargs

Enhanced for, collection manager and reflection.

Improved Collection manager: everything and anything now iterable.
** Added iterate over number range from 0 up to number or 0 down to number.
** Added unicode character code point range with nearest block set start. iterate over a - z, A - Z, 0 - 9, \ u16A0 - \ u16F8 etc...
** over a string representation of type member reflection detail Includes class definition and produces the true bsh virtual information for generated classes. Allows reflection iteration via class type, object instance or class identifier.

Fix import static

Added field and method static import, previously only * static import was available.

Fixed deprecation

Java 9 and 10 deprecations were addressed
Fixed the deprecation warnings for applets and made a valiant attempt at turning the applets into apps, gui api not my strong suite. Anyone want to improve on that?

Many Improvements to OldScriptsTest. now called BshScriptTestCase

Added system property script to single out a single script for testing.
improved error reporting
Wrap junit asserts for script tests. see Assert.bsh
add ability to skip tests based on assumptions
and more - these are starting to be be choice for writing tests

Fixes to inner class implementation.

Correctly fail on required enclosing instance when trying to instantiate an inner class from static outer class
Added Instance.new Innerclass() parsing and capability for instantiating an innerclass from outer instance

Upgrade ASM 6.1.1

Applied fixes as per changes to ASM api including deprecated method changes to visitMethodInsn
As before we still don't need ClassReader so gutted it out of the ASM API.
We also don't need Annotation or Module support so that got purged too.

Script engine changes.

reduced code duplication
converted TestBshScriptEngine to junit test.
Remove BSF2.x support in favour of JSR223 support. BSF engine moved to external module bsh-bsf-engine for anyone that might still require it.

Improved callerInfo retention for reporting errors from generated methods..

Fix override child namespace for namespace chaining.
A method inherited from a parent namespace refers to a variable changed in the local namespace, we should override the method declared namespace with the child's namespace.

nJoy!

String Literals
You can now use single quotes ' you strings in bsh. Single quoted string literals of 1 character length will be treated as a Primitive.TYPE = char but if it contains anything more or less than a single character it is treated as a string.
The following is therefor true:
https://github.com/beanshell/beanshell/blob/7a6181a55a13fd3ae4a0ee4a83e6fb0fca40c19a/src/test/resources/test-scripts/strings.bsh#L5-L18
https://github.com/beanshell/beanshell/blob/7a6181a55a13fd3ae4a0ee4a83e6fb0fca40c19a/src/test/resources/test-scripts/strings.bsh#L20-L49

You just rock!
Ste
On Fri, Jun 8, 2018 at 10:59 AM, Nick Lombard<EMAIL_ADDRESS>wrote:

String Literals
You can now use single quotes ' you strings in bsh. Single quoted string
literals of 1 character length will be treated as a Primitive.TYPE = char
but if it contains anything more or less than a single character it is
treated as a string.
The following is therefor true:
https://github.com/beanshell/beanshell/blob/7a6181a55a13fd3ae4a0ee4a83e6fb
0fca40c19a/src/test/resources/test-scripts/strings.bsh#L5-L18
https://github.com/beanshell/beanshell/blob/7a6181a55a13fd3ae4a0ee4a83e6fb
0fca40c19a/src/test/resources/test-scripts/strings.bsh#L20-L49
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/beanshell/beanshell/issues/68#issuecomment-395697409,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACoglt8BwKrIubeVl66StavtuNy64xTks5t6jzUgaJpZM4UfkvV
.

@stefanofornari I can always count on your support =) Tx


Octopus Energy

An api is available here:
https://developer.octopus.energy/docs/api/

I'd love to work on this!

Can access live and historical prices without an API key through this endpoint: https://energy-db.energy-stats.uk/api/datasources/proxy/1/query
Queries are formed like this: https://energy-db.energy-stats.uk/api/datasources/proxy/1/query?db=octopus&q=SELECT distinct("unit_price") FROM "agile" WHERE time >%3D<PHONE_NUMBER>000ms and time <%3D<PHONE_NUMBER>999ms GROUP BY time(30m)%2C "area_name" fill(previous)&epoch=ms
Is the plan to get users to upload their API keys so that their consumption can be logged in real-time?

Hi @AyrtonB We need to provide at token login for other upcoming integrations, so I believe we can use the same solution. What do you think?

There's a GraphQL endpoint (see https://developer.octopus.energy/docs/api/#graphql-api) which enables using an existing username/password. @lacexd @AyrtonB is that something you can help out with?

Yeah should be able to help out with that. What format does northapp need the data to be in?

https://github.com/tmrowco/northapp-contrib#electricity-consumption-activity-formatting should cover it, but I suggest look at other existing implementations here: https://github.com/tmrowco/northapp-contrib/tree/master/integrations/electricity

Ah hdan't realised that the NorthApp parsers are all JS unlike the Python ElectricityMap ones. Definitely not the best at JS so I'm probably not the person for this one unless there's a way to integrate a Python parser?


Added default minpower to importers

I get why you added this but the value makes 0 sense and is now always annoying. I would say if you want a template to edit for later, just enable full_dump. What do you think?

Sure we can ask but I think minPower is super irrelevant. For leveling, it doesn't matter since it is easy anyways. For endgame you only really care for weapon ilvl. For everything else the stats are most important. And then you are at a point where only 925 frops anyways 🤷

I just don't see what it hurts to have it, and it gives a minor improvement to people especially while leveling.


Many manual fixes of missing override specifiers (issue #110)

Thirteen more commits that fix compilation warnings about missing override specifiers.
Previous override fixes (pull request #136 and #137) were applied automatically by clang-tidy (modernize-use-override), but the fixes from this pull request has to be done manually, and carefully.
This pull request hopefully completes the fixes for issue #110 ("-Winconsistent-missing-override on MacOS"), submitted by Harmen Stoppels @haampie

Great, thanks a lot!


Are all these options a function of the CPU architecture - as opposed to the SDK?

In Configurations/10-main.conf:
"darwin64-x86_64-cc" => {
    inherit_from     => [ "darwin-common", asm("x86_64_asm") ],
    cflags           => add("-arch x86_64 -DL_ENDIAN -Wall"),
    bn_ops           => "SIXTY_FOUR_BIT_LONG",
    perlasm_scheme   => "macosx",
    shared_ldflag    => "-arch x86_64 -dynamiclib",
},

Were every single one of x86_64_asm, DL_ENDIAN , SIXTY_FOUR_BIT_LONG , and perlasm_scheme   => "macosx" chosen only because of the x86_64 architecture -- as opposed to because of the macOS SDK?
Similarly here:
"ios64-cross" => {
    inherit_from     => [ "darwin-common", asm("aarch64_asm") ],
    cflags           => add("-arch arm64 -mios-version-min=7.0.0 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) -fno-common"),
    sys_id           => "iOS",
    bn_ops           => "SIXTY_FOUR_BIT_LONG RC4_CHAR",
    perlasm_scheme   => "ios64",
},

Were every single one of aarch64_asm , SIXTY_FOUR_BIT_LONG , RC4_CHAR , perlasm_scheme   => "ios64" chosen only because of the arm64 architecture -- as opposed to because the iOS SDK?
I'm trying to understand which settings are due to architecture and which due to SDK.

All the ones you mention are CPU specific, except the perlasm_scheme which is toolchain specific.

@kroeckx Thank you! What about shared_ldflag    => "-arch x86_64 -dynamiclib"? Does this affect static libraries in any way? (My guess it only affects shared libraries, but I thought I'd make sure.)

The first part seems to tell the linker which architecture it's
for, the second probably that it needs to make a shared library,
but I'm really not sure. But it at least looks toolchain specific.

CPU- vs. toolchain-specific is not exactly adequate division. The mesh is three-dimensional: CPU, OS, compiler. As far as assembly modules go, they are maintained CPU-specific but OS- and compiler-neutral. C code is primarily neutral, but has some CPU-specific sections (inline assembly) and some OS-specific sections (e.g. #ifdef _WIN32 or #ifdef __linux). Build system is supposed to tie everything up in compiler/toolchain-specific manner.


Adds GetUserByUsername method

This is "hidden" feature (see https://gitlab.com/gitlab-org/gitlab-foss/-/issues/43843)

Thanks @veverkap, but this logic is already in this client. If you look at the ListUsers method, you can see that one of the options allows you to set the username: https://github.com/xanzy/go-gitlab/blob/master/users.go#L108
So can we close this PR? Or is there something I missed that requires this PR?

Yeah, you're right.  I saw the note regarding admins and thought it was a different endpoint.
Turns out that the ?username= trick will work for non-admins some.


The verifierReports did not include signature digest

What would you like to be added?
The current verifierReports did not include the digest for a signature manifest. If an image has multiple signatures, it will be very hard to know which signature failed verification. It's better to show the digest of every OCI artifact that was verified, so that it can be correlated later for different purposes.
An example of current verifierReports in the Ratify logs:
  "verifierReports": [
    {
      "subject": "***.azurecr.io/fromado@sha256:9bd300b50747ff122cf5c2fb47f1e29a162604e85f37659cde09d6358221a1d4",
      "isSuccess": true,
      "name": "verifier-cosign",
      "type": "cosign",
      "message": "cosign verification success. valid signatures found. please refer to extensions field for verifications performed.",
      "extensions": {
        "signatures": [
          {
            "signature": "*****",
            "verifications": [
              {
                "isSuccess": false,
                "bundleVerified": false,
                "error": "crypto/rsa: verification error",
                "keyInformation": {
                  "provider": "keymanagementprovider-akv",
                  "name": "test-cosign",
                  "version": "849bc742cb674e0aa4cc5573e692209a"
                }
              }
            ]
          },
          {
            "signature": "*****",
            "verifications": [
              {
                "isSuccess": true,
                "bundleVerified": false,
                "keyInformation": {
                  "provider": "keymanagementprovider-akv",
                  "name": "test-cosign",
                  "version": "849bc742cb674e0aa4cc5573e692209a"
                }
              }
            ]
          }
        ]
      },
      "artifactType": "application/vnd.dev.cosign.artifact.sig.v1+json"
    }
  ]
} component-type=server go.version=go1.21.9 trace-id=d38178b1-7dd7-46c3-95d7-c3b57236b40d

Anything else you would like to add?
No response
Are you willing to submit PRs to contribute to this feature?

[ ] Yes, I am willing to implement it.

@yizha1 Can you provide an example scenario where each signature will have a different layer digest? From my testing, I notice that the payload that is signed does not change between various signatures. As a result, the signature digest stays the same. Discussion can be found here: https://github.com/deislabs/ratify/pull/1381#discussion_r1571186979

Per discussion in the community meeting, the digest is same across different cosign signatures. But we have unique signature hash in the report. Closing the issue.


Add proper support for ItemsView.EmptyView

Closes #608

@TimLariviere
do we have an example in AllControlsto see this?

No. But we can easily add one though.

@TimLariviere
tested it on multiple simulators and emulators - worked well for me.
Thanks for this :)


Add Automation to the project deployment (CI/ CD)

@hari Please do automate the process of deployment it will be hard to manually update the deployment after every new code addition. I made some changes, added undo and redo functionality , but it didn't reflected in the site https://pixcell.vercel.app, either add a script that automates the process or we have to update the deployment manually everytime we pushed some code.

@pa1narendra it deploys automatically after merging.

But in the site the undo and redo buttons are not visible?

@hari any updates on this issue ?


Updated to remove default keyspace as well as allow for counter batches

Allows users to pass an Option.batchType to CassandraCqlMapState.java, specifying the BatchStatement type with which to execute CQL statements. Also, removed the default keyspace.

Hi there, quick questions regarding counter updates.

Does this prevent read/write round-tripping by submitting all updates as counter increments?
Have you guys noticed a performance boost by doing so?
Are there any caveats to using the counter update approach?

Thank you!