adapt to JSON changes (January 2022)

New additions noticed in January 2022:

v3 Data File:

Flight Plans:

assigned_transponder (string), default 0000?

FSD Servers:

client_connections_allowed (bool)
is_sweatbox (bool)

JSON Network Status:

in data:

servers_sweatbox
servers_all

Check if support for data.servers has been added at some point to this parser.
These changes were not publically announced (again). API documentation seems to be offline (would be located at https://api.vatsim.dev/#operation/DataServerV3)

New fields are now available via Client#getAssignedTransponderCodeDecimal() and FSDServer#isSweatbox().
client_connections_allowed is a weird one. The previous field clients_connection_allowed (note the swapped plural) was "always" there (same as on legacy format) and never observed with any different value than 1, so I already assumed that it's probably a boolean encoded as an integer (and offlined servers simply are never exposed through the data files). According to my code comments, JSON v3 API documentation (still offline...) stated that the old field is int32. parseClientConnectionAllowedInteger translated 0 to false and all other values to true (as would be the case when comparing an integer on low-level languages or machine code) but logged a warning (via SLF4J, not parser log) in case we encounter some other value. With the new field I added an additional check which reports any mismatch between the two fields to the parser log but ultimately trusts the boolean (because the boolean indication isClientConnectionAllowed is what our FSDServer class was always supposed to transport, not an integer). Let's see if we ever hit that message; I suspect the old field is simply cargo cult from migrating the legacy formats to JSON and might be deleted in a future JSON format version.
Nothing needed to be done to support servers_sweatbox and servers_all on NetworkInformation. Any key on data will be transported. Whoever needs that data can already access it using getDataUrls or getAllUrlsByDataKey.


"*.gradle" should be recognized as ft=groovy

Gradle build.gradle files are written in groovy, so they should be detected as ft=groovy.

index 4d8b7d8..3ec4a74 100644
--- a/runtime/filetype.vim
+++ b/runtime/filetype.vim
@@ -826,7 +826,7 @@ au BufNewFile,BufRead *.gs           setf grads
 au BufNewFile,BufRead *.gretl           setf gretl

 " Groovy
-au BufNewFile,BufRead *.groovy          setf groovy
+au BufNewFile,BufRead *.gradle,*.groovy     setf groovy

 " GNU Server Pages
 au BufNewFile,BufRead *.gsp         setf gsp

Justin M. Keyes wrote:
Gradle build.gradle files are written in groovy, so they should be detected as ft=groovy.

index 4d8b7d8..3ec4a74 100644
--- a/runtime/filetype.vim
+++ b/runtime/filetype.vim
@@ -826,7 +826,7 @@ au BufNewFile,BufRead *.gs           setf grads
 au BufNewFile,BufRead *.gretl           setf gretl

 " Groovy
-au BufNewFile,BufRead *.groovy          setf groovy
+au BufNewFile,BufRead *.gradle,*.groovy     setf groovy

 " GNU Server Pages
 au BufNewFile,BufRead *.gsp         setf gsp

Thanks, I'll include it.
--
You have heard the saying that if you put a thousand monkeys in a room with a
thousand typewriters and waited long enough, eventually you would have a room
full of dead monkeys.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///


BrainVision Analyser data format version 2

Hello,
I have some issues with importing Brainvision Files. When i do some preprocessing in Brainvision Analyser and then export the data, it exports data  headers in "Brain Vision Data Exchange Header File Version 2.0" format. It is slightly different from that, which is now implemented in MNE, so I had to brutally hack existing function to read my files. Unfortunately every update breaks my code and I don't feel up to the task of officially maintaining it on github.
So I thought that it would be great if someone could review my code and maybe incorporate it into the MNE, you can find those dirty hacks here: http://pastebin.com/BbgsP4Wv It is for MNE 0.9
And some headers here:
ICA_OBS_MRC_LTMAM2_01_p1.vhdr.txt
ICA_OBS_MRC_LTMAM2_01_p1.vmrk.txt

the good approach is to send us the patch as a PR on github so we can integrate it and you don't have to maintain it.

please give it a try. And ask if you need help.

Should I fork and do a PULL request on 0.9 branch, or should I do it on master?

do it on master and we can backport to 0.10 eventually.

I've created pull request.
I don't think code is too clean, I just created mne.io.read_raw_brainvision2 function for those headers. It is usable, but can do more. Header v2.0 saves electrode locations, but I never realized support for reading them.

@mdovgialo what is the difference between the two functions? I would prefer to keep it one function that checks for the version to adapt for the different versions. It would simplify the code and we would be able to see what the differences are for the different versions too

@teonlamont didn't you (or possibly I) fix some stuff in .9 that made reading of bv2 files possible?
mdovgialo have you tried it with a recent version?

I've done some checking. I remember that I had to change quite some stuff for it to work, in mne 0.8, mostly in marker - reading code. After upgrade to 0.9 my hacks didn't work, so I started over and
@jona-sassenhagen you are right, there were fixes, and function in mine pull request is pretty much the same as in mne 0.9, only asserts are changed to "Version 2.0", and some units multipliers changed and I added cases for reading markers tagged as "Pulse Artifact" and "Bad Interval" (I needed them for my code).
But the newest version was changed a lot, and I don't know if just changing asserts will work now.

@mdovgialo sorry, but could you try using the v0.10 to see where the problem is now.

on 0.10 I get the same assertion error
/usr/local/lib/python2.7/dist-packages/mne/io/brainvision/brainvision.pyc in _get_vhdr_info(vhdr_fname, eog, misc, response_trig_shift, scale)
302         # extract the first section to resemble a cfg
303         l = f.readline().strip()
--> 304         assert l == 'Brain Vision Data Exchange Header File Version 1.0'
305         settings = f.read()
306
AssertionError:
In [71]:
It looks like it was ready for use in 0.9, but assertions for v2.0 headers where not added.

@teonlamont
Sharing the v2.0 files:
http://www.fuw.edu.pl/~mdovgialo/ICA_OBS_MRC_LTMAM2_01_p1.vhdr
http://www.fuw.edu.pl/~mdovgialo/ICA_OBS_MRC_LTMAM2_01_p1.vmrk
http://www.fuw.edu.pl/~mdovgialo/ICA_OBS_MRC_LTMAM2_01_p1.dat


[wip] [tracking] Using reth and revm in our stack

We're playing with the idea of (also) using reth and revm in the same places we use jerigon.

flowchart TD
jerigon --execution traces--> zero-bin --reshape--> trace_decoder --trim/reshape-->  evm_arithmetization --prove--> plonky2
native-tracer --execution traces--> zero-bin
zeth["'zeth'"] --execution traces--> zero-bin

This issue charts a path for this integration.
fraktal-zkp/zeth
Folks on the team have seen the zeth prototype stack successfully prove transactions with our zk_evm.
This consists of:

Changes to zero_bin to handle the new client: permalink
Changes to revm to allow it to collect execution traces: comparison
Changes to reth to plumb the traces: comparison
Trivial change to revm-inspectors to juggle dependencies.

SMT support
We would want our zeth client to support using SMTs as the "world" storage.
I'm aware of two SMT "flavours": a "standard SMT", described in this post, and a "modified SMT" used in practice by Hermez.
It is NOT clear what the differences are, but it has been noted that they are not compatible.
It is NOT clear at this time which we want to target for this work.
SMTs also use a dense binary serialization format.
scroll-tech has a fork of reth, broken down in https://github.com/paradigmxyz/reth/issues/11830, which abstracts over storage formats for their own zktrie structure.
We should be able to build off this work for our needs.
We may want to use their zktrie directly, but note that we'd need to pull in a go toolchain into our repo.
If not, revm's trait Host is the right level to target.
Strawman decision/workstream

[ ] #777

[ ] Check in a test with the above into zk_evm CI. (medium, low risk (because we already do similar things in CI, right?))

Acceptance:

assert that zeth produces a given witness file after a particular RPC call.
assert that a given witness proves in zk_evm.

Do we want to own/collaborate/drive/fund work on zeth?

[own it in 0xPolygonZero] Should we fork the above repo, or start from scratch?
Note that fraktal-zkp/zeth does not list its license. paradigmxyz/reth and bluealloy/revm both list MIT licenses.

[start from scratch] in a fresh fork of revm

Forking reth looks like it'll be a necessity for the plumbing work - existing execution extension and other APIs are not sufficient to get the traces we need.
Forking will be inevitable was we'll want to upstream changes. It looks like reth is reasonably open to external contributions.
It looks like the evm_interpreter changes should be trivial to implement in terms of the public trait Database, so we may not need to fork it, but we will need to change the code in reth that runs the interpreter.
[ ] Have a current fork of reth, with changes as outlined above producing the same snapshot as zeth (medium, low risk - we're building off proven work).

Acceptance:

Repo does not need CI other than the snapshot testing.

[ ] Open a PR against reth with our changes. Likely to be mired in API discussion, so we'll need a viable plan to keep our branch current. (medium, low risk but long tail)

How do we do cross-repo testing?

Having each repo pull in the latest version of the other to do "current" testing is going to be painful - let's agree on a snapshot, and advance that in-step, decoupling the two repos.

Our current SMT library is unsuitable for use in a client, and probably needs to be rewritten, or heavily refactored to be used in the way we'd need: https://github.com/0xPolygonZero/zk_evm/issues/706 (medium, low risk, nonblocking).

spike: start introducing an SMT into https://github.com/paradigmxyz/reth/pull/11786, and note the key APIs that might need tweaking

Thanks Aatif,
@wborgeaud -- could you comment on the difference in the smts?
I think now is the time to cut to the more vanilla implementation.

Comment from @paulgoleary in stand-up today was that Hermez compatibility is NOT what we mean by "SMT support".
Does that not mean that the work looks a bit like adding Type 2 support?

new client exposes (probably scroll's) SMT format (probably in binary).

Surely we don't need to do anything here if scroll are working on this, and we plan on treating their thing as "the most standard SMT"?

new work in trace_decoder to parse and pre-process that format.
new work in evm_arithmetization to prove off the new SMT format.

Thanks Aatif.
It's been noted elsewhere but worth doc'ing here that it is not a goal of this work (afaik) to be compatible with the Hermez SMT. In fact, we should be as standard as possible.
A related point is that we expect that the REVM zkVM compilation path (e.g. Succinct RSP) to also be a viable proving stack for use in the CDK. This emphasizes the need to be as standard 'as possible' since one of the major benefits of the approach is the ability to compile the 'standard' REVM directly to a prover.

I'm aware of two SMT "flavours": a "standard SMT", described in this post, and a "modified SMT" used in practice by Hermez.
It is NOT clear what the differences are, but it has been noted that they are not compatible.
It is NOT clear at this time which we want to target for this work.

Because of time/resource constraints, we'd probably want to stick with Hermez SMT for now (we had actually targeted a more optimized version first, but then reverted for easier compatibility during transition Hermez -> Zero prover). Given that we also need to target cdk-erigon (which uses hermez'), we probably would want to stick to this one here (though there were some discussions about tweaking the internals, see point below on smt_trie).

Note that fraktal-zkp/zeth does not list its license.

They do not have a given LICENSE.md file but mention being MIT-licensed in their README.

Our current SMT library is unsuitable for use in a client, and probably needs to be rewritten, or heavily refactored to be used in the way we'd need

Agreed on this. You mention this being medium, would you have an idea of the time it would take for a full revamping? I mentioned internal tweaks above, because Hermez and our SMT / prover backend rely on Poseidon, while we initiated discussions some time ago on possibly using Poseidon2 which is much faster, while providing roughly the same security benefits. If we wanted to do this, we'd need to decide whether this comes with dropping fully Poseidon support, or through a more modular fashion, to then support both Hermez style and the more generic/efficient cdk stack that could leverage Poseidon2.

@0xaatif https://github.com/0xPolygonZero/zk_evm/pull/511/files

@0xaatif for first point - created 2 tasks https://github.com/0xPolygonZero/zk_evm/issues/790, https://github.com/0xPolygonZero/zk_evm/issues/791
Will be picking them up

Closed https://github.com/0xPolygonZero/zk_evm/issues/790
Native tracer might fail and no need to handle this for now


Apim 1614 use execution context

Description
Avoid System.getEnv and use executionContext.getComponent to retrieve the Configuration object

:tada: This PR is included in version 1.1.3 :tada:
The release is available on:

1.1.3
GitHub release

Your semantic-release bot :package::rocket:


[FEAT] Timeshift at pid level

Hi @lelegard ,
Is your feature request related to a problem?
I describe the use case to explain the problem:

Using TSDuck I'm manually muxing (with the file input with interleave) two different VBR services inside the same CBR MPTS. Even the services are VBR, the input files are CBR. The problem is that with this method both services have the same GOP start point (they have the same GOP length). Then some troubles could appear when the first I-frames are very large. As you know a professional multiplexer tries to never put I-frames at the same point. When using this technique with files this can be solved with the --add-start-stuffing option of the input file. Adding different start stuffing sizes for each service displaces the start of the GOP between services.

However, when I want to reproduce this in realtime (with HLS chunks) I can't use this technique. So, I need a method to "timeshift a service inside a Transport Stream".
Proposed solution:
I propose to enhance the timeshift plugin to support not only the entire TS (that's in fact delaying ALL packets), but to delay only a pid list. In this case, the user requires to guarantee that sufficient NULL stuff exist inside the TS to execute this "pid level timeshift". However, this can be achieved for example doubling the bitrate initially (as this grants sufficient NULL stuff). Then for any delayed TS packet it will be space to write it. After that processing it's easy to remove the NULL stuff and restore the initial CBR bitrate of the MPTS.
Alternatives:
The alternative is to split the HLS chunks in subchunks, but this implies a lot of work and requires some changes to support it.
Additional information:
If this enhancement will be implemented then I suggest to support a "pid list" and a "service list". With these two access method will be sufficient to delay any type of data inside the TS.
I hope you agree with this suggestion.
Regards.

Hi @lelegard ,
I close this as I feel with the new plugin pidshift could be used for this. Thank you!


Minor healthcheck UI improvements

Currently healthchecks sort oldest to newest, the reverse might be more useful?
If a task is bouncing, and the new tasks are launched but not yet healthy, the status will show as TASK_RUNNING for the new (unhealthy) instances and TASK_CLEANING for the old (but healthy) instances.  This is a little confusing to the end user, they think that since one is "cleaning" it is being killed and since one is "running" they say "why hasn't my deploy succeeded yet???"
The behavior is fine, it's just the messaging that could use improvement -- maybe a little badge next to healthy vs unhealthy instances?  Or a TASK_RUNNING_NOT_YET_HEALTHY state?

#1626 is a step towards this. It exposes tasks which are healthy/not yet healthy and we can use that to inform the ui in future PRs

There is a healthy/not yet healthy indicator next to tasks in the ui in the most recent release. Closing this one


Card UI

The card/ project can  be improved by adding hover effect on card.
Solution:
When we Hover on card the border colour should change and little bit zoom of card it will look good.

Hey i can improve the Ui please assign it to me for hacktoberfest 2023.
I would love to contribute!

Go ahead with your work, @Dhruvrode

Thank you so much I'll let you know when I am done

Hi @Manishak798   I have made the necessary PR for this issue. Make sure to label the PR with hacktoberfest-accepted after reviewing it.
#25  And please inform me if I have made a mistake .

Hey @Manishak798  why it saying excluded repo ??/

Unfortunately, This project has been excluded from hacktoberfest.


feature: additionalTypes

Would a PR to add configuration for accepting additional commit types be accepted?
Something along the lines of:
additionalTypes:
    - foo
    - bar
    - baz

This would validate the message type is one of these types https://github.com/commitizen/conventional-commit-types/blob/master/index.json or one of the additional types.
According to the SPEC other types may be added. https://www.conventionalcommits.org/en/v1.0.0-beta.2/#specification I would like to explicitly configure those types.

Yeah this sounds like a good idea. Go for it!

@mrchief parse-commit-message indeed doesn't care about the type
However semantic-pull-requests does:
https://github.com/probot/semantic-pull-requests/blob/df5cba1a7ca11af18713af2a1e05e7252efa49f3/lib/is-semantic-message.js#L18
Therefore, PR title like "improvement: Enhance navbar" will not pass as a semantic message.

@mrchief I was thinking the same too (allowing additional types to be passed in).
I have made a PR to do that #67

It seems like this issue can be closed now?
BTW I found it a little confusing because to me "additional types" is something that add more types while the implementation is more about "override types". I know it's not so hard to copy&paste around 10 existing types but it still could be easier if there will be "additionalTypes"/"customTypes" or "extraTypes" field.

Yep this was resolved by #67, thanks for pointing that out.

I found it a little confusing because to me "additional types" is something that add more types

☝ The key that ended up in the implementation is called types, so there shouldn't be much confusion now. If you need all the existing types plus others, you can enumerate them all in the types array. See https://github.com/probot/semantic-pull-requests#configuration


Privacy Modal

This modal has different behavior for the client and server version:
For the client version, this will not show up on page load, but will give a popup if you click on the 'Privacy' text. It's just text and an okay button.
For the server version, this will show up on page load (unless you have accepted beforehand), and if the user accepts and it's not a shared computer, the cookie will last for 1 year. If it is a shared computer, it will last for the session. If the user rejects, it will bring them back to the menu page.
Cookies don't work for local files so you won't be able to test that locally I think. If you toggle the 2 instances of "SERVER_URL" in LearnerView, then you should be able to see the modal change (however, it still won't remember your decision).

P.S. Please also merge master into this branch when you get a chance -- there was an issue with Travis that should be fixed by doing so. Thanks!

Okay, the cookies are working for both expiring and session, tested using locally deployed server.
The only caveat is that when the user has the option for their browser to remember their tabs, then it doesn't count as a session when they close out the window. So I think if someone checks that option and the browser has that option, then the cookie will live on?

Great, thanks @theresa-lee! Do you want me to review this as the PR for submission, or do you have further changes coming?
Also, what do you mean that "it doesn't count as a session when they close out the window"?

@seanlip You can review this for submission!
Well, a session is finished usually by when the user closes out their window. But if that option is selected, the browser does not count the closing of the window as the end of a session because it is remembering where the user left off and still has the cookies stored.

Looks good, thanks! Will wait for @rabidbit's approval prior to merge.


Bump pytorch to 2.0.0, torchvision to 0.15.1

Bumps pytorch from 1.13.1 to 2.0.0.

Release notes
Changelog
Commits

Bumps torchvision from 0.14.1 to 0.15.1.

Release notes
Commits

Lockfile update failed at https://github.com/pangeo-data/pangeo-docker-images/actions/runs/4878623460/jobs/8704433492#step:4:22:
Could not solve for environment specs
The following packages are incompatible
├─ python-graphviz   is installable with the potential options
│  ├─ python-graphviz [0.11|0.11.1|...|0.8.4] would require
│  │  └─ graphviz   with the potential options
│  │     ├─ graphviz 2.38.0 would require
│  │     │  └─ freetype 2.5.* , which does not exist (perhaps a missing channel);
│  │     ├─ graphviz [2.38.0|2.40.1|2.42.3] would require
│  │     │  └─ jpeg [9* |>=9c,<10a ], which can be installed;
│  │     ├─ graphviz 2.38.0 would require
│  │     │  └─ zlib 1.2.8 , which can be installed;
│  │     ├─ graphviz 2.38.0 would require
│  │     │  └─ zlib 1.2.11 , which can be installed;
│  │     ├─ graphviz 2.42.3 would require
│  │     │  └─ jpeg >=9d,<10a , which can be installed;
│  │     └─ graphviz [2.46.1|2.47.0|...|8.0.4] would require
│  │        └─ libgd [>=2.3.0,<2.4.0a0 |>=2.3.2,<2.4.0a0 |>=2.3.3,<2.4.0a0 ] with the potential options
│  │           ├─ libgd 2.3.3 would require
│  │           │  └─ icu >=72.1,<73.0a0 , which can be installed;
│  │           ├─ libgd 2.3.3 would require
│  │           │  └─ jpeg >=9e,<10a , which can be installed;
│  │           └─ libgd [2.3.0|2.3.2|2.3.3] would require
│  │              └─ jpeg >=9d,<10a , which can be installed;
│  └─ python-graphviz [0.16|0.17|...|0.20.1] would require
│     └─ graphviz >=2.46.1 , which can be installed (as previously explained);
├─ python 3.10**  is installable and it requires
│  └─ python_abi 3.10.* *_cp310, which can be installed;
├─ pytorch >=2.0.0 *cuda112* is uninstallable because there are no viable options
│  ├─ pytorch 2.0.0 would require
│  │  ├─ libprotobuf >=3.21.12,<3.22.0a0 , which requires
│  │  │  └─ libzlib >=1.2.13,<1.3.0a0 , which requires
│  │  │     └─ zlib 1.2.13 *_4, which conflicts with any installable versions previously reported;
│  │  └─ python_abi 3.8.* *_cp38, which conflicts with any installable versions previously reported;
│  ├─ pytorch 2.0.0 would require
│  │  ├─ libprotobuf >=3.21.12,<3.22.0a0 , which cannot be installed (as previously explained);
│  │  └─ python >=3.10,<3.11.0a0 , which can be installed (as previously explained);
│  ├─ pytorch 2.0.0 would require
│  │  └─ python_abi 3.11.* *_cp311, which conflicts with any installable versions previously reported;
│  └─ pytorch 2.0.0 would require
│     ├─ libprotobuf >=3.21.12,<3.22.0a0 , which cannot be installed (as previously explained);
│     └─ python_abi 3.9.* *_cp39, which conflicts with any installable versions previously reported;
├─ rasterio   is installable with the potential options
│  ├─ rasterio 1.3.6 would require
│  │  └─ python_abi 3.8.* *_cp38, which conflicts with any installable versions previously reported;
│  ├─ rasterio [1.3.3|1.3.4] would require
│  │  ├─ libgdal [>=3.5.2,<3.6.0a0 |>=3.5.3,<3.6.0a0 |>=3.6.0,<3.7.0a0 ] with the potential options
│  │  │  ├─ libgdal [3.5.3|3.6.3|3.6.4] would require
│  │  │  │  └─ proj >=9.2.0,<<IP_ADDRESS>a0 , which can be installed;
│  │  │  ├─ libgdal [3.4.1|3.4.2|...|3.6.2] would require
│  │  │  │  └─ jpeg >=9e,<10a , which can be installed;
│  │  │  └─ libgdal [3.5.3|3.6.2|3.6.3] would require
│  │  │     └─ icu >=70.1,<71.0a0 , which conflicts with any installable versions previously reported;
│  │  └─ proj >=9.1.0,<<IP_ADDRESS>a0  with the potential options
│  │     ├─ proj 9.1.0 conflicts with any installable versions previously reported;
│  │     └─ proj [9.0.1|9.1.0|9.1.1] would require
│  │        └─ libtiff >=4.4.0,<4.5.0a0 , which requires
│  │           └─ jpeg >=9e,<10a , which can be installed;
│  ├─ rasterio [1.0.23|1.0.24|...|1.1.5] would require
│  │  └─ libgdal [>=2.4.1,<2.5.0a0 |>=2.4.2,<2.5.0a0 |...|>=3.0.4,<3.1.0a0 ], which requires
│  │     └─ jpeg >=9c,<10a , which can be installed;
│  ├─ rasterio [1.1.6|1.1.7|...|1.2.9] would require
│  │  ├─ libgdal [>=3.1.2,<3.2.0a0 |>=3.1.3,<3.2.0a0 |...|>=3.4.1,<3.5.0a0 ] with the potential options
│  │  │  ├─ libgdal [3.4.1|3.4.2|...|3.6.2], which can be installed (as previously explained);
│  │  │  └─ libgdal [3.1.2|3.1.3|...|3.4.1] would require
│  │  │     └─ jpeg >=9d,<10a , which can be installed;
│  │  └─ proj >=9.0.0,<<IP_ADDRESS>a0 , which requires
│  │     └─ libtiff >=4.3.0,<4.5.0a0  with the potential options
│  │        ├─ libtiff [4.3.0|4.4.0], which can be installed (as previously explained);
│  │        └─ libtiff 4.3.0 would require
│  │           └─ jpeg >=9d,<10a , which can be installed;
│  ├─ rasterio [1.2.10|1.3.0|...|1.3.3] would require
│  │  └─ proj >=9.0.1,<<IP_ADDRESS>a0 , which can be installed (as previously explained);
│  ├─ rasterio 1.3.6 would require
│  │  ├─ libgdal >=3.6.2,<3.7.0a0  with the potential options
│  │  │  ├─ libgdal [3.5.3|3.6.3|3.6.4], which can be installed (as previously explained);
│  │  │  ├─ libgdal [3.4.1|3.4.2|...|3.6.2], which can be installed (as previously explained);
│  │  │  └─ libgdal [3.5.3|3.6.2|3.6.3], which cannot be installed (as previously explained);
│  │  └─ proj >=9.1.1,<<IP_ADDRESS>a0  with the potential options
│  │     ├─ proj [9.0.1|9.1.0|9.1.1], which can be installed (as previously explained);
│  │     └─ proj 9.1.1 conflicts with any installable versions previously reported;
│  ├─ rasterio 1.3.6 would require
│  │  └─ python_abi 3.11.* *_cp311, which conflicts with any installable versions previously reported;
│  └─ rasterio 1.3.6 would require
│     └─ python_abi 3.9.* *_cp39, which conflicts with any installable versions previously reported;
└─ torchvision >=0.15.1 *cuda112* is uninstallable because there are no viable options
   ├─ torchvision 0.15.1 would require
   │  ├─ libjpeg-turbo >=<IP_ADDRESS>,<3.0a0 , which requires
   │  │  └─ jpeg <0.0.0a , which conflicts with any installable versions previously reported;
   │  └─ python_abi 3.8.* *_cp38, which conflicts with any installable versions previously reported;
   ├─ torchvision 0.15.1 would require
   │  ├─ libjpeg-turbo >=<IP_ADDRESS>,<3.0a0 , which cannot be installed (as previously explained);
   │  └─ python >=3.10,<3.11.0a0 , which can be installed (as previously explained);
   └─ torchvision 0.15.1 would require
      └─ python_abi 3.11.* *_cp311, which conflicts with any installable versions previously reported.

Conflict is likely due to torchvision depending on libjpeg-turbo, but graphviz and rasterio depending on jpeg>=9, see also https://github.com/conda-forge/conda-forge.github.io/issues/673. The proj920 migration at https://github.com/conda-forge/rasterio-feedstock/pull/264 should help with this, as PROJ 9.2.0 which depends on libtiff>=4.5.0 uses jpeg-turbo (since https://github.com/conda-forge/libtiff-feedstock/pull/95), so graphviz=8.0.4 will become compatible with torchvision =0.15.1.

/condalock

/condalock

thanks @weiji14 !


set up testing for pinia store

Resolves #88
What changed

added following dependencies:

@testing-library/vue
@vitejs/plugin-vue
jsdom
vitest

removed jest
added new store for language navigation: stores/navigationStore.js
added corresponding test test/stores/navigationStore.spec.ts

Testing instructions
run yarn run test, it should be 🟢

@RageZBla There's one failing step in the CI. It looks like a dependency is missing.

@RageZBla it looks like the workflow is still failing. I think it just needs a yarn install?


chore(metric): display actor count per CN in grafana

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Resolve #16955
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Example:


When scrolling images are resized

Describe the bug
When opening the console or scrolling on the iphone or ipad images are being resized to the point where you can't see them anymore
To Reproduce
Use an image which has vertically more px the horizontally
Steps to reproduce the behavior:
Open browser (chrome) and console and drag it up and down or scroll with ipad
What is the expected behavior:
No resizing the image
What happened instead:

In what environment (browser/device etc.) does this bug happen/not happen:
Keywords help others to find this issue:
⚠ Search for existing open/closed issues/discussions before you report the issue.
⚠ If you do not provide enough information to reproduce your bug. We won't be able to work on the issue. In most cases just providing a fraction of your code is not enough!

@Isengo1989 hi, i have the same problem. What was you solution to fix this?


calling chart.fit() after expanding/collapsing a node (onButtonClick)

Hi,
I want to call chart.fit() after a node is expanded or collapsed. How can I do that?
I am using React/TypeScript but you can explain in JS too.

The only workaround that comes to my mind is to listen to expand/collapse click and the invoke fit() method inside setTImeout with 2-3 sec delay


Add adjustments to S3 module to allow for use with Google Cloud Storage buckets

Brief description of the changes [REQUIRED]
These changes allow for uploading to Google Cloud Storage (GCS) using the S3 part of fine-uploader (per issue #1158).
The main change was simply to include storage.googleapis.com in the list of patterns that "detects" the bucket name when generating the policy document.
I also had to make an additional change which specifies the content min/max length (image size) as numerics rather than as strings, due to google apparently being more strict about validating the policy document.
Please note that the PR is showing a change to the logo in the root README.md (possibly backing out dfff19b), I'm not really sure why that happened.
What browsers and operating systems have you tested these changes on? [REQUIRED]
{example: Safari on iOS 9.1.0 and IE11 on Windows 8.1}
Chrome on OS X El Capitan.
Are all automated tests passing? [REQUIRED]
{Choose one: "yes" or "no". If "no", then why not?}
Yes, all automated tests passed.
Is this pull request against develop or some other non-master branch? [REQUIRED]
{Choose one: "yes" or "no". If "no", then why not?}
In my fork I made the changes in branch 1158-s3-to-gcs-interop, then merged into my develop branch, and the PR is for develop. Let me know if you prefer it a different way. It's possible that I format the comments exactly right, I didn't see those guidelines until after I did my commits.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: rnicholus:x: Nate WeissNate Weiss seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.

I would really like to see this feature get merged in or have some documentation made available that instructed how to get this set up. I am very interested in being able to upload files client-side directly to a GCS bucket.

Hi, Aaron, I have been meaning to write up the steps that I took to get
this working. Will try and finally do that later today. I've found that
things work fine with GCS after a few esoteric config steps.
Nate
On Sun, Dec 4, 2016 at 10:50 AM Aaron J. Olson<EMAIL_ADDRESS>wrote:

I would really like to see this feature get merged in or have some
documentation made available that instructed how to get this set up. I am
very interested in being able to upload files client-side directly to a GCS
bucket.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/FineUploader/fine-uploader/pull/1674#issuecomment-264711470,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXZ4rIqVf1dcRpE-wVVkY4jkwVekbtbks5rEuFMgaJpZM4KZ9OZ
.

If you can pair this with documentation updates, I think this will be ready to merge into develop.

@nateweiss thanks again for your help with this! Have you had a chance to put that write up into the documentation? I think it would be awesome if this got merged.

Was a writeup/guide ever made?

Hi, I apologize for not getting this written up yet. The reason is that I found that the file does get successfully uploaded to GCS, but for some reason the file doesn't inherit the default permissions from the bucket. As a practical matter this makes it not work for my use case and I suspect others.
I suspect the problem is that fine-uploader is providing a default policy document along with the upload, or something along those lines. I imagine the fix is simple, but the holidays took me away from it and I just haven't delved back in. I will try to do so. Sorry again about the delay.

For non-chunked uploads, a policy document is provided. This is required for non-multipart uploads to an S3 bucket. For chunked uploads, the S3 multipart REST endpoint is used instead, and no policy document is sent.

No problem nateweiss.

Hello nateweiss.  Thank you so much for your (soon to be) writeup on direct upload to Google Cloud Storage.
I'm approaching GCS from the Google Firebase side of things.  Firebase has a storage solution - which is, in fact, GCS, but with slightly different credentials.  Do see any issues with uploading directly to Firebase's GCS?

Hello @nateweiss
Shall we know the status of this merge request?


Unstable automated tests random crashes (possible 3rd party cause related to PhantomJS).

To reproduce the issue:

clone the project,
open solution in Visual Studio 2015 (Update 1 or above),
rebuild solution in the RELEASE mode,
execute test1.ps PowerShell script (multiple execution may be required, issue is non-determinictic).

You're likely to see the following (or similar, depends on PhantomJS version) errors:

Selenium IWebElement.Click() timeout exception (random failing test shown):

OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL http://localhost:36739/session/61c45350-d1aa-11e5-9878-b1f29258417c/element/:wdc:1455296622916/click timed out after 15 seconds.
---- System.Net.WebException : The operation has timed out
Stack Trace:
  at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
  at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
  at OpenQA.Selenium.Remote.DriverServiceCommandExecutor.Execute(Command commandToExecute)
  at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
  at OpenQA.Selenium.Remote.RemoteWebDriver.InternalExecute(String driverCommandToExecute, Dictionary`2 parameters)
  at OpenQA.Selenium.Remote.RemoteWebElement.Execute(String commandToExecute, Dictionary`2 parameters)
  at OpenQA.Selenium.Remote.RemoteWebElement.Click()
D:\Projects\internal\github\ExpressiveAnnotations\src\ExpressiveAnnotations.MvcWebSample.UITests\HomePage.cs(128,0): at ExpressiveAnnotations.MvcWebSample.UITests.HomePage.SafeClick(IWebElement elem)
D:\Projects\internal\github\ExpressiveAnnotations\src\ExpressiveAnnotations.MvcWebSample.UITests\HomePage.cs(35,0): at ExpressiveAnnotations.MvcWebSample.UITests.HomePage.SetMode(String mode)
D:\Projects\internal\github\ExpressiveAnnotations\src\ExpressiveAnnotations.MvcWebSample.UITests\ServerModeTest.cs(14,0): at ExpressiveAnnotations.MvcWebSample.UITests.ServerModeTest..ctor(DriverFixture classContext, Serve
rFixture assemblyContext)
----- Inner Stack Trace -----
  at System.Net.HttpWebRequest.GetResponse()
  at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)

PhantomJSDriver shutdown hangs:
[INFO  - 2016-02-12T17:03:07.337Z] ShutdownReqHand - _handle - About to shutdown

Note: the tests are executed in parallel - one thread (its own PhantomJSDriver instance) tests client-side scenarios (scripts execution only, postbacks to server limited), other thread (separate PhantomJSDriver instance) goes through server-side scenarios (postbacks only, validation scripts disabled).

Switched to FirefoxDriver.


UI: not clear

As a new user, It's hard for me which specifies which info (don't know which is phone number, jobcode, name)

edit the user guide + png


Fix #4133: Remove comma between weekday and date in Italian

As described in issue #4133, there shouldn't be a comma between weekday and date in Italian locale.
I've checked this by comparing the output of:
Intl.DateTimeFormat("it", {
  weekday: "long",
  day: "numeric",
  month: "long",
  year: "numeric",
  hour: "2-digit",
  minute: "2-digit"
}).format(new Date());
// "sabato 19 agosto 2017, 15:55"

(I've not addressed the fact that the browser-native Intl implementation puts a comma between the date and time as I'm not sure if moment is trying to mimic Intl functionality - and commas in that position are also missing in other locales - e.g. de, en-us, en-gb...)

The usual process with those tickets is that we @ the original authors and if they agree we go with it. If there's a dispute we usually defer to CLDR. Intl implementations are generally built on CLDR, so it's a pretty good indicator, though not authoritative.

@aliem any comments on this one?

Commas in that particular position is present based on the context. For
standalone dates, the pr, it makes sense.
So lgtm
On 25 Oct 2017 12:35 AM, "Iskren Ivov Chernev"<EMAIL_ADDRESS>wrote:
@aliem https://github.com/aliem any comments on this one?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/moment/moment/pull/4134#issuecomment-339156523, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACWEh1ACnKSreGTYbrrC2xi_r3cWo8eks5svmYagaJpZM4O8Ww6
.


Write a test to check if a user can redeem the same coupon code multi…

Fixes
akto-api-security/akto#175

Closing this PR as need to raise another one against develop.


Feature request: Option to load as Java System properties

Plugin for Java project is loading values as System Environment Property, no issues with that. In workflows where initialization happens via call to System.getProperty(key), we need to fallback to Run configuration in IntelliJ. This fragments utility of the plugin. If an option can be considered under Enable EnvFile which will toggle loading .env as Java System properties, it increases use of this plugin in such workflow.
Plugin is otherwise useful, Thank You.

This goes beyond the initial intent of the plugin, thought I'd be curious to see a PR adding such functionality.


[android] Let it build and use orc from nnstreamer

Let android build use nnstreamer's orc code (tensor_transform).
Requires https://github.com/nnstreamer/nnstreamer/pull/4651 to be merged.

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #585. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.


support for node 0.10 ?

nice! I like the native approach :+1:
build.js fails immediately with node 0.10 due to execSync missing from child_process, which is an easy thing to fix.
though I wonder if the rest of the native code supports node 0.10 ?

No this version of node webrtc is only working with latest nodejs. v0.12.x

Just need to rewrite 5000 lines of code with using nan.

Now supports older versions and Iojs.


As a user, I want to discover additional blog content after I've read a piece

This is planning ticket for team to discuss structure of the blog page.

As a user, when I finish reading a blog post, I may want to discover other additional posts. I would like easily be able to navigate to other posts from the node page. I don't want to have to click back to the list view all the time to get more details about about to read.

Some ideas

show posts with similar tags
show other posts by author, if they exist
have a block that lists tags so user can select another tag and see all posts with that content

Personally, I've never found archive blocks that list all the posts by year very helpful. Just feels like a long list of stuff with very little context. I do like how sites are using next/previous to let users read pieces sequentially, especially when there's a bit more context, like title of the post, as @skyfaerie currently has included, or a little teaser. However, as a user, I would also like to discover content that's related to the post i'm reading by some determined criteria.


Document and clean SourceRelativeLinksEval code

The second commit also renames the functions to be consistent with the config option - if you like it, i'll squash :)

@bep. I'm not sure what direction to take wrt the repositoryPathPrefix - it would allow users that have their docs in a subdirectory in the github repo to make links that look like [asdf](/docs/something.md) which would work on GitHub, and to run hugo from within the /docs dir.
it turns out we don' t need it, because we don't have links like that anymore, but it may be useful to someone - should I make it another config option?

asdf which would work on GitHub, and to run hugo from within the /docs dir.

Do you mean [asdf](/docs/content/something.md) ?
Then I would say that, without remembering what your setup looks like, a "Hugo Project Folder" setting should do it in all cases? If that is "/docs" or "/subfolder/docs" shouldn't matter.

@bep - nice, yup, that would work well for people that mix Github and hugo.

mmm, CircleCI test failure seems to be unrelated?

@bep and @spf13 if you're happy with these changes, I'll squash them

I added a couple of minor comments, but this looks much better. Thanks.

This looks good. Can you squash the commits?

@bep @moorereason @spf13 sorry, had a week off - hope this can be merged for 0.16 :)

I've just found an interesting buglet, I'll get back to you.

Merged in 1648e32. Thanks for this, I like it when people follow-up on their contributions.


On VS Code it would be great to have an upload button/option for uploading local files.

Why you need this feature:
it would be great to have an upload button/option for uploading local files.
Describe the solution you'd like:
Have a upload button
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Right click in the files explorer shows me an Upload option. Isn't it what is desired in this bug?

As mentioned above this option already exists.
closing this issue.


Use object destructuring for controller methods

fix some codacy linting errors
switch to yarn for running tests

Coverage remained the same at 94.545% when pulling 3e77076aca6f581a42393adff35961cd03ddfd8d on refactor-routes-controller-usage into 6b0d349f96e4159773de89a87686e6cb1cd0d2ef on master.

Coverage remained the same at 94.545% when pulling 22300d744de12cbdcfe6adf4c7d8d679e4f2f629 on refactor-routes-controller-usage into 6b0d349f96e4159773de89a87686e6cb1cd0d2ef on master.


defmt-test: can't find crate for test

Hi, I am trying to set up defmt-test for unit testing with an app build using Embassy. I have added the following very simple test to my app's main.rs:
#[cfg(test)]
#[defmt_test::tests]
mod unit_tests {
    use defmt::assert;

    #[test]
    fn it_works() {
        assert!(true)
    }
}

but when I try cargo test, I am confronted with:
error[E0463]: can't find crate for `test`

Unfortunately I have no idea where this is coming from. I have tried to compare the basic of my project with the template at https://github.com/knurling-rs/app-template/tree/main, but cannot see any difference that would explain this issue.
I have the following Cargo.toml for my workspace:
[workspace]
members = ["bootloader", "app"]
resolver = "2"

# cargo build/run
[profile.dev]
codegen-units = 1
debug = 2
debug-assertions = true # <-
incremental = false
opt-level = 'z'         # <-
overflow-checks = true  # <-

# cargo test
[profile.test]
codegen-units = 1
debug = 2
debug-assertions = true # <-
incremental = false
opt-level = 3           # <-
overflow-checks = true  # <-

# cargo build/run --release
[profile.release]
codegen-units = 1
debug = 2
debug-assertions = false # <-
incremental = false
lto = 'fat'
opt-level = 3            # <-
overflow-checks = false  # <-

# cargo test --release
[profile.bench]
codegen-units = 1
debug = 2
debug-assertions = false # <-
incremental = false
lto = 'fat'
opt-level = 3            # <-
overflow-checks = false  # <-

[patch.crates-io]
embassy-stm32 = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-futures = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-net = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-usb = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-usb-dfu = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-boot = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-boot-stm32 = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-sync = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-time = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-time-driver = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-time-queue-driver = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }
embassy-embedded-hal = { git = "https://github.com/embassy-rs/embassy", rev = "d3fd34e5ffa45a71cca650fc13d2438f1c2f0861" }

And the following Cargo.toml for my app:
[package]
name = "mcu-fw-app"
version = "0.1.0"
edition = "2021"

[dependencies]
defmt = "0.3"
defmt-rtt = "0.4"

embassy-stm32 = { version = "0.1", features = [
    "stm32f439zi",
    "time-driver-any",
    "exti",
    "chrono",
] }
embassy-executor = { version = "0.6", features = [
    "task-arena-size-32768",
    "arch-cortex-m",
    "executor-thread",
    "executor-interrupt",
    "integrated-timers",
    "defmt",
] }
embassy-futures = "0.1"
embassy-boot-stm32 = "0.2"
embassy-time = { version = "0.3", features = ["tick-hz-32_768"] }
embassy-net = { version = "0.4", features = [
    "defmt",
    "tcp",
    "dhcpv4",
    "proto-ipv4",
    "medium-ethernet",
] }
embassy-usb = "0.3"
embassy-sync = "0.6"
embassy-embedded-hal = "0.2"

cortex-m = { version = "0.7", features = ["critical-section-single-core"] }
cortex-m-rt = "0.7"
embedded-io = { version = "0.6" }
embedded-io-async = { version = "0.6" }
panic-probe = { version = "0.3", features = ["print-defmt"] }
static_cell = { version = "2" }
picoserve = { version = "0.12", features = ["embassy", "defmt"] }

[dev-dependencies]
defmt-test = "0.3.2"

Any idea what could be causing this or advise for where I should be looking? Thanks!

That error normally appears when you try and compile the standard Rust test runner for a bare-metal target that doesn't have the test crate available.
Have you got the extra Cargo.toml entries as described at https://crates.io/crates/defmt-test?
# Cargo.toml

# for the library crate (src/lib.rs)
[lib]
harness = false

# for each crate in the `tests` directory
[[test]]
name = "test-name" # tests/test-name.rs
harness = false

[[test]]
name = "second" # tests/second.rs
harness = false

@jonathanpallant oops, my bad, that was indeed the problem. Fixing that was indeed as simple as adding test = false to my bin in Cargo.toml so that I now have:
[package]
name = "mcu-fw-app"
version = "0.1.0"
edition = "2021"

[[bin]]
name = "mcu-fw-app"
test = false

...

Now I get other problems related to the cortex-m-rt linker script not finding the interrupt vectors it needs. Unfortunately I won't have time to troubleshoot that further as I have already moved on to using https://crates.io/crates/embedded-test and have that working.
I had a similar problem with embedded-test though and in that case this was ultimately fixed by using their Embassy integration correctly. So for anyone struggling with that, maybe https://github.com/probe-rs/embedded-test/issues/48 can help.


Lowercase and asciifold keyword fields in Elastic

When searching for v{insert sierra ID} we get nothing, but searching for V{insert sierra ID} we get results.
You can use normalisers which normalise the data at index and query time, I haven't read a huge amount about them, but initially see no down side.
https://www.elastic.co/guide/en/elasticsearch/reference/6.4/normalizer.html
e.g.
https://wellcomecollection.org/works?query=V0004569ER
https://wellcomecollection.org/works?query=v0004569ER

If you try these queries now, you get the correct result – I believe we're copying all the identifiers into an identifiers field, which has a lowercase keyword analyser.
Also, these are Miro IDs, not Sierra IDs.


enhancement Avoid frequent variable retrieval from connect context when calculating cost

Proposed changes
Issue Number: close #xxx
Avoid frequent variable retrieval from connect context when calculating cost
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 49.27 seconds
stream load tsv:          456 seconds loaded<PHONE_NUMBER>9 Bytes, about 156 MB/s
stream load json:         19 seconds loaded<PHONE_NUMBER> Bytes, about 118 MB/s
stream load orc:          57 seconds loaded<PHONE_NUMBER> Bytes, about 18 MB/s
stream load parquet:          29 seconds loaded 861443392 Bytes, about 28 MB/s
insert into select:          25.7 seconds inserted 10000000 Rows, about 389K ops/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230711075332_clickbench_pr_176295.html

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 53.48 seconds
stream load tsv:          500 seconds loaded<PHONE_NUMBER>9 Bytes, about 142 MB/s
stream load json:         19 seconds loaded<PHONE_NUMBER> Bytes, about 118 MB/s
stream load orc:          65 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select:          28.5 seconds inserted 10000000 Rows, about 350K ops/s
storage size:<PHONE_NUMBER>9 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230711155843_clickbench_pr_176296.html

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 51.29 seconds
stream load tsv:          449 seconds loaded<PHONE_NUMBER>9 Bytes, about 158 MB/s
stream load json:         19 seconds loaded<PHONE_NUMBER> Bytes, about 118 MB/s
stream load orc:          57 seconds loaded<PHONE_NUMBER> Bytes, about 18 MB/s
stream load parquet:          29 seconds loaded 861443392 Bytes, about 28 MB/s
insert into select:          26.1 seconds inserted 10000000 Rows, about 383K ops/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230711122357_clickbench_pr_176485.html

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 48.99 seconds
stream load tsv:          452 seconds loaded<PHONE_NUMBER>9 Bytes, about 157 MB/s
stream load json:         19 seconds loaded<PHONE_NUMBER> Bytes, about 118 MB/s
stream load orc:          57 seconds loaded<PHONE_NUMBER> Bytes, about 18 MB/s
stream load parquet:          29 seconds loaded 861443392 Bytes, about 28 MB/s
insert into select:          25.6 seconds inserted 10000000 Rows, about 390K ops/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230712023110_clickbench_pr_176796.html

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 54.65 seconds
stream load tsv:          501 seconds loaded<PHONE_NUMBER>9 Bytes, about 142 MB/s
stream load json:         19 seconds loaded<PHONE_NUMBER> Bytes, about 118 MB/s
stream load orc:          65 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select:          28.5 seconds inserted 10000000 Rows, about 350K ops/s
storage size:<PHONE_NUMBER>1 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230712103356_clickbench_pr_176798.html

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 45.34 seconds
stream load tsv:          547 seconds loaded<PHONE_NUMBER>9 Bytes, about 130 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          65 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          32 seconds loaded 861443392 Bytes, about 25 MB/s
insert into select:          30.4 seconds inserted 10000000 Rows, about 328K ops/s
storage size:<PHONE_NUMBER>3 Bytes


pspg: 4.0.1 -> 4.2.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/okbob/pspg/releases.
meta.description for pspg is: "Postgres Pager"
meta.homepage for pspg is: "https://github.com/okbob/pspg"
meta.changelog for pspg is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 4.2.1 with grep in /nix/store/xxwcbqlrh9fcn631ny04frp3bnqinxbi-pspg-4.2.1

directory tree listing: https://gist.github.com/849fba3ce2fad18cf738d7fd43945969

du listing: https://gist.github.com/468fd2fb6341a23589ca29813ca0bf7e

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

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
pspg

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xxwcbqlrh9fcn631ny04frp3bnqinxbi-pspg-4.2.1 \
  --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 pspg https://github.com/r-ryantm/nixpkgs/archive/f8cd914e3b7b33846409b6bdbf12abe856e424ef.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/xxwcbqlrh9fcn631ny04frp3bnqinxbi-pspg-4.2.1
ls -la /nix/store/xxwcbqlrh9fcn631ny04frp3bnqinxbi-pspg-4.2.1/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

1 package built:

pspg

Maintainer pings
cc @jlesquembre for testing.

Result of nixpkgs-review pr 113864 run on x86_64-linux 1

1 package built:

pspg


Fix xrdp incompatible Ubuntu 18.04.2 clean install

Intro
I installed Ubuntu 18.04.2 minimal in Windows 10 Pro 1903 Hyper-V, but can't connect to enhanced session mode.
Thanks @RainCat1998, this issue solved the problem. https://github.com/Microsoft/linux-vm-tools/issues/76#issuecomment-481502084
I just copied ubuntu/18.04/install.sh into ubuntu/18.04.2/install.sh and fixed it.
Tested

Ubuntu 18.04.2 minimal

Other
I tried @albadokhon https://github.com/Microsoft/linux-vm-tools/issues/76#issuecomment-486073202, but the Basic Session mode is not available.

+1 please help. My work has stopped. I cant get to vscode without it.


[error]Compiling av failed during pip install scrcpy-client

python 3.11.3
windows11
msvc 14.36.32532

OK, I download this wheel from av pypi history


Correct hint in error message to match plugin's ProblemFilter class

As this plugin comes with it's own ProblemFilter class which has a
different name, the helpful error message of MiMa can't be copy-and-pasted.
This PR replaces the string to allow copy-and-paste-ing.

Bump

Sorry, hadn't the time to look at it. I'll check it this weekend :)

This is a friendly reminder. Also, I wish you Merry Christmas!

Thank you for the reminder. Merry Christmas to you too @lefou :)
I have a review for you too :)
In https://github.com/com-lihaoyi/mill/pull/1638 I refined the algorithm to not add redundant source folders. It made the algorithm more complicated but the number of folders added is very low now :)


[BUG] [dojo-bindgen] [unity] Generated actions methods try to call FieldElements in calldata

Describe the bug
bindgen will generate code trying to call Inner on systems calldata elements.
To Reproduce
Steps to reproduce the behavior:

clone dojo-starter
run sozo build --unity
Inspect Actions's Move in dojo_starter::systems::actions::actions.gen.cs which shows

calldata = new dojo.FieldElement[] {
    new FieldElement(direction).Inner()
}

Which doesn't compile.
Expected behavior
The resulting code should be
-    new FieldElement(direction).Inner()
+    new FieldElement(direction).Inner

Additional info
It seems that format_system always formats calldata with FieldElement({}).Inner() https://github.com/dojoengine/dojo/blob/010444fa3797429a4903b3e480956e2df8ea3153/crates/dojo-bindgen/src/plugins/unity/mod.rs#L209-L234
I'm guessing it should probably just be Inner everywhere. If confirmed, I'd be happy to make a PR.

Hi I would like to work on this


mini status line errors out when attempting to edit init.lua on MacOS

Describe the bug
When attempting to edit the init.lua file, statusline throws the following error.
E5108: Error executing lua ....local/share/nvim/lazy/mini.nvim/lua/mini/statusline.lua:617: attempt to call field 'count' (a nil value)
stack traceback:
        ....local/share/nvim/lazy/mini.nvim/lua/mini/statusline.lua:617: in function 'diagnostic_get_count'
        ....local/share/nvim/lazy/mini.nvim/lua/mini/statusline.lua:300: in function 'section_diagnostics'
        ....local/share/nvim/lazy/mini.nvim/lua/mini/statusline.lua:555: in function <....local/share/nvim/lazy/mini.nvim/lua/mini/statusline.lua:551>

I know this might be a issue for mini.nvim but considering I've ONLY been able to reproduce it when editing THIS project's init.lua file, I figured I'd raise it here in case there are any others who have experienced it.
Troubleshooting steps taken:

Used a fresh clone of kickstart. No modifications made (issue persists)
Ran "rm -rf ~/.local/share/nvim" to force Lazy to reinstall everything (issue persists)
Attempted to reproduce on a second machine (running ubuntu) (could not reproduce)
-- weird, right?
Tested in the following terminals: Kitty, Terminal, iTerm2, Warp (issue persists)

To Reproduce

Use a mac (cringe, I know)
Edit init.lua (either via nvim ~/.config/nvim/init.lua, or via netrw, or via the "e" command within nvim i.e. ":e ~/.config/nvim/init.lua")

Desktop

OS: macOS 14.3.1 23D60 arm64
Terminal: Kitty (happens on any terminal)

Neovim Version
NVIM v0.10.0-dev-751+gd086bc1e8
Build type: Release
LuaJIT 2.1.0-beta3

I ran into this same issue when I first ran kickstart. It looks like it has to do with the version of neovim you are on. I found this issue: https://github.com/echasnovski/mini.nvim/issues/699 in the mini repo and after getting the latest nightly version this issue went away.

Use a mac (cringe, I know)

LOL
But seriously, you're on a pretty old version of "nightly", this was "nightly" many many nights ago :laughing: Try updating nvim and see if that fixes it.

You're right, @rbaumgardner93 and @tjdevries! How I didn't realise that before is beyond me.
Updated neovim, and no more error!
That's most likely more so the reason why it was working on my other machine. Makes more sense. It's a skill issue, not a mac issue...
Thanks for the help gentlemen!


Changed to always use namespace when a name is involved

Fixes #285 by using namespaces whenever a name is involved. Before this change, deploying a Jaeger instance in a namespace tenant2 when there's already a Jaeger instance in another namespace (tenant1) would cause the underlying objects, such as Deployment objects, to be removed in favor of the one in the new namespace.
Signed-off-by: Juraci Paixão Kröhling<EMAIL_ADDRESS>

@jkandasa , this can be tested as follows:
# make sure the environment is clean:
$ kubectl get deployments --all-namespaces
NAMESPACE     NAME                       READY     UP-TO-DATE   AVAILABLE   AGE
kube-system   coredns                    2/2       2            2           28h
kube-system   default-http-backend       1/1       1            1           28h
kube-system   kubernetes-dashboard       1/1       1            1           28h
kube-system   nginx-ingress-controller   1/1       1            1           28h

$ kubectl create namespace tenant1
namespace/tenant1 created
$ kubectl create namespace tenant2
namespace/tenant2 created
$ kubectl apply -n tenant1 -f deploy/examples/simplest.yaml
jaeger.jaegertracing.io/simplest created
$ kubectl apply -n tenant2 -f deploy/examples/simplest.yaml
jaeger.jaegertracing.io/simplest created
$ kubectl get deployments -n tenant1
NAME       READY     UP-TO-DATE   AVAILABLE   AGE
simplest   1/1       1            1           40s
$ kubectl get deployments -n tenant2
NAME       READY     UP-TO-DATE   AVAILABLE   AGE
simplest   1/1       1            1           28s
$ kubectl get jaegers --all-namespaces
NAMESPACE   NAME       AGE
tenant1     simplest   51s
tenant2     simplest   38s

@objectiser sorry for such a bit PR. Most of it are changes to the NewJaeger function, affecting pretty much all tests. I left comments in the important parts.

@jpkrohling can you provide a docker image for this PR?


🐞

Describe the bug
After a voting proposal passed successfully the button to withdraw my tokens (BAST in this case) from the smart contract was not available.
To Reproduce
Steps to reproduce the behavior:

From DFOhub main page, I clicked on BAST.
I then clicked on the Governance tab.
I then clicked on the Proposals tab.
Other members of BAST told me that I would need to click on the info button beside the appropriate proposal to see a withdraw button, but once I did this there was no withdraw button available.

Expected behavior
A withdraw button is expected to be available for me to remove my tokens from the voting smart contract.
Screenshots
If applicable, add screenshots to help explain your problem.

I have added a screen shot of the area of where the withdraw button should be.
Web3 Scenario (please complete the following information):

Device: Desktop PC
OS: Windows 10
Browser: Chrome
Version: Version 85.0.4183.83 (Official Build) (64-bit)
Provider: Metamask

Additional context
Some of the members of the BAST community and myself were doing testing to try to figure out the problem. I personally tested:
Different browser: BRAVE browser.
Different computer with same setup (windows 10 + chrome + metamask).
I turned off all extensions in chrome except for metamask then re-tested. I also turned off the developer mode in Chrome then re-tested. I tried changing from nighttime mode to daytime mode using the DFOhub button then re-tested. I tried refreshing many many times and even CTRL+F5 but nothing worked. (apparently some members of BAST did get the withdraw button to reappear after many refreshes but I was not successful with this).
One BAST member noticed that if he connected a wallet to metamask that didn't have any BAST at all (none in the vote contract or in the wallet) he could see the withdraw button, but as soon as he connected his wallet with BAST in the vote contract he could not see the button.
Reward
If you want to be rewarded:

Read carefully the DFOhub Community Guidelines and Reward Rules
Join the DFOhub Discord Server
Discord Username and #: Crypto P.I.   #6930
ETH Wallet: 0x1C6c4B0Bb7778024587F664469Ec1B8aDb34f835

We made some updates in the proposals refresh logic which improved the user experience of the Withdraw button.
Please, tempestively notify us through this issue if the problem persists, so we can grab the correct moment in wich the trouble occurs.
Thank you!


Error adding cover / shutters

First of all, great work on putting this to work. Works brilliant for my light that are connected with the X Comfort Bridge.
I do get an error with my sunshades though when Home Assistant is loading this platform "Error adding entities for domain cover with platform xcomfort_bridge". This is what I find in the log. Any idea on how I can fix this?
Logger: homeassistant.components.cover
Source: helpers/entity_platform.py:507
Integration: Cover (documentation, issues)
Error adding entities for domain cover with platform xcomfort_bridge
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 752, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1057, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 779, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 879, in _async_write_ha_state
state, attr = self._async_generate_attributes()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 822, in _async_generate_attributes
attr.update(self.state_attributes or {})
^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/cover/init.py", line 284, in state_attributes
if (current := self.current_cover_position) is not None:
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/xcomfort_bridge/cover.py", line 149, in current_cover_position
return 100 - self._state.position
^~~~~~~~~~~~~~~~~~
TypeError: unsupported operand type(s) for -: 'int' and 'NoneType'

Just bumping this because I'm curious if anyone else is having this issue? Home Assistant does recognise the shades in the integration, but when clicking the device it shows: "this entity is no longer provided by the comfort_bridge integration with the above log details... Would be great if we could get this working. I don't have enough experience with programming myself unfortunately.

@Makestudio20 Can you verify that it works after https://github.com/jankrib/ha-xcomfort-bridge/pull/28

Thanks very much for the fix! Actually the XComfort Bridge itself annoyed me so much that I have decided to swap the devices I used for Shelly's. So I can't check if it works anymore. Sorry that this caused you extra work, hopefully someone else might still think this is a useful update.


1080 x 1080 px or 1200 x 628 px banner

Hey! Packt requested a 1080 x 1080 px or 1200 x 628 px banner with larger text. Is this possible to create?

NVM, Packt created it in house


I lost my permissions to the NeuroDesk repositories

Maybe something has changed with all the latest modifications. Can you please grant it back? (@civier)
Likewise, please also grant access to Dave White (@DavidjWhite33) and Will Woods (@willw1). Both of them need to add containers to neurocontainers.
Thanks,
Oren

Hi @civier. DavidjWhite33 and willw1 have been added to neurocontainers.
Which repository did you want access to?

@civier - instead of giving everyone access to everything we need to be more careful with permissions and grant them more granularly (mainly for security reasons since one wrong commit could by now cause considerable damage to the infrastructure we set up). The best and most secure option is to send pull request to the repositories that then get reviewed and approved - could you try if this workflow works for you?

I want access to Neurocontainers as well. Regarding the other ones, I agree
that using pull requests is better.
Could you please coordinate with me the next time that you change
permissions? Today I was working, and got stuck in the middle.
Best,
Oren
--
Oren Civier
Neuroimaging Informatics Fellow
Swinburne Neuroimaging | National Imaging Facility
https://anif.org.au/team/oren-civier/
https://www.swinburne.edu.au/neuroimaging
Swinburne University of Technology
Hawthorn Campus, Advanced Technologies Centre, Room 914
+61 3 9214 4628 | +61 4 3101 6603
@.*** (Email/Teams video call)
https://twitter.com/orencivier
On Tue, 21 Sep 2021, 19:11 Aswin Narayanan, @.***>
wrote:

Hi @civier https://github.com/civier. DavidjWhite33 and willw1 have
been added to neurocontainers.
Which repository did you want access to?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NeuroDesk/neurodesktop/issues/45#issuecomment-923788103,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB7FUI5H6ZNEO77B35OJMWLUDBD4XANCNFSM5ENTJEKQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@civier, the access rights were changed a few weeks ago
have added you to neurocontainers now

@civier - Pull requests would also work for Neurocontainers, but I agree that the risk of breaking things is low in this repository - so a direct access of the core team contributing is ok.
Regarding information of the next change: I informed everyone who contributed to the neurocontainers repository of the change, but you had not contributed anything yet, so you were not on the list:


Highlights section must fill the screen in mobile view

Our stand-up team member needs to design the width to fit 100% of the mobile view

Thanks for the feedback.
This has been worked on.


help: unable to replay in nodeos 1.8.1

Hi all, i am doing a replay with state_history_plugin enable in nodeos v1.8.1.
The block.log was downloaded from https://eosnode.tools/blocks and blocks_2019-07-23-07-03.tar.gz
However, when i tried to replay, i hit some issues. The screenshot of the logs show as per attached.
the command i used to do a replay:
./nodeos --disable-replay-opts --replay-blockchain
The config.ini file

agent-name = "DSP"
p2p-server-address = addr:8888
http-server-address = <IP_ADDRESS>:8888
p2p-listen-endpoint = <IP_ADDRESS>:9876
blocks-dir = "blocks"
abi-serializer-max-time-ms = 3000
max-transaction-time = 150000
wasm-runtime = wabt
reversible-blocks-db-size-mb = 1024
contracts-console = true
p2p-max-nodes-per-host = 1
allowed-connection = any
max-clients = 100
network-version-match = 1
sync-fetch-span = 500
connection-cleanup-period = 30
http-validate-host = false
access-control-allow-origin = *
access-control-allow-headers = *
access-control-allow-credentials = false
verbose-http-errors = true
http-threads=8
net-threads=8
read-mode = head
trace-history-debug-mode = true
trace-history = true
plugin = eosio::producer_plugin
plugin = eosio::chain_plugin
plugin = eosio::chain_api_plugin
plugin = eosio::net_plugin
plugin = eosio::state_history_plugin
state-history-endpoint = <IP_ADDRESS>:8887

Appreciate any inputs on this. Thanks.

Can you show the beginning of the log?

hi there, here is the beginning of the log. Thanks.

And the section after the log index reconstruction completes?

And the section after the log index reconstruction completes?

It never get completed i think. It stops at the first screenshot i show you. This is error is from the physical server. However, on Google Compute engine, this works fine strangely. Both are on ubuntu 18.04

I just hit the exact same error at the exact same block.

@elnoxvie & @i-love-to-code Any update? Did you try a different block and newer version of eosio?


Invert namespace injection selection criteria

Fixes https://github.com/istio/istio/issues/5576
Copy of https://github.com/istio/istio/pull/6439

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: ayj
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: ostromart
Assign the PR to them by writing /assign @ostromart in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ayj, ostromart
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS [ostromart]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

The new opt-out behavior is off by default to match existing install configuration.
Namespace labeled is required to avoid bootstrap problems. Annotating the pods alone (w/o namespace labels) won't work. The api-server will still invoke the webhook for properly annotated pods, including the injector pod itself. And the injector pod can inject into itself before it's running.
Any suggestions for labeling namespaces automatically in the install processes? If helm isn't sufficient, do we need a real installer/upgrader (e.g. operator pattern)?

+Andy - we may need to revert this for the RC1.

Never mind - the values.yaml doesn't set this option, so no need to revert. Still won't work if someone
sets it explicitly - but it's not documented.

This option is disabled by default (see https://github.com/istio/istio/pull/6704#issuecomment-401573433). We should document this prerequiste requirement in the setup instructions (or hide it from docs entirely for 1.0).
To handle this automatically with helm we'll likely need an install job (see https://github.com/istio/istio/pull/6823) unless helm gets native support for namespace labeling.


Changes to DataFrames/GBIF integrations not picked up by Revise.jl

I'm trying to use Revise.jl to make the changes discussed in #74, and I'm running into some issues. I'm new to Revise though.
For now, calling using Revise before using SimpleSDMLayers in a dev project works great when I make changes to any functions from the package, except for the GBIF/DataFrames integrations. I know they are loaded through Requires.jl, but this is supposed to be supported by Revise (see here)
I managed to make it work by removing the joinpath() in https://github.com/EcoJulia/SimpleSDMLayers.jl/blob/db148a57a597dbb7412bae50b2c0168815ad0df1/src/SimpleSDMLayers.jl#L55-L65 to
function __init__()
    @require GBIF="ee291a33-5a6c-5552-a3c8-0f29a1181037" begin
        @info "GBIF integration loaded"
        include("integrations/GBIF.jl")
    end
    @require DataFrames = "a93c6f00-e57d-5684-b7b6-d8193f3e46c0" begin
        @info "DataFrames integration loaded"
        include("integrations/DataFrames.jl")
    end

end

@tpoisot I know your preference for joinpath, but do you mind leaving that one? Is there another fix?

I have never used Revise, so I have no idea why that might be...
That being said, joinpath is actually important here because of the dirname / pathof part. I would open an issue on Revise.


Openssl 3.1.6+quictls

Update to 3.1.6 with vulnerabilities fixed:

CVE-2024-4741
CVE-2024-4603
CVE-2024-2511

Closing in favor of https://github.com/quictls/openssl/pull/167


[stable/prometheus-operator] Fix duplicate prometheus server scrape when per-replica service enabled

What this PR does / why we need it:
If the Prometheus per-replica service is enabled along with
prometheus.serviceMonitor.selfMonitor, then the match conditions on the
serviceMonitor will also match the per-replica service meaning each
Prometheus server replica will be scraped twice.
This updates the main Prometheus service resource to include a new self-monitor
label that will be set to the value of prometheus.serviceMonitor.selfMonitor. The
label matching on the Prometheus serviceMonitor has been updated to include a
new condition where the new self-monitor label must be present with a the value set
to true.
Another I thought we could solve this is to hard code a relabeling drop action on the prometheus serviceMonitor resource that drops any metrics from endpoints that included the statefulset.kubernetes.io/pod-name pod label.
e.g.
relabelings:
  - source_labels: [__meta_kubernetes_pod_label_statefulset_kubernetes_io_pod_name]
    regex: .+
    action: drop

I'm sure there's other ways and am happy to adapt this PR to suit whatever the collective suggest.
Also fixes a namespace reference issue for the per-replica ingress resource from the changes in #17689

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/ok-to-test

Currently the ci values do not enable the per-replica service or ingress resources since they're off by default and that state was carried over to the test values file.
This will mean the automated testing never applies config related to those chart features and we won't see failures for future changes that may impact them.
Should we flip prometheus.servicePerReplica and prometheus.ingressPerReplica to true to have them created during testing and try catch failures earlier?
This would have helped avoid some of the issues introduced with #17689

/test pull-charts-e2e

/ok-to-test
/lgtm

@shaunmansell
I think we should temporary turn off selfMonitor as False in values.yaml, or might think a way to limit prometheus scrapping all namespaces. This is the reason why pull-charts-e2e test failed (inquiry too many unrelated charts in other PRs causing timeout). Check pull-charts-e2e -> Details in below to see the detail.

I think they failure is being caused by node capacity issues on scheduling the node-exporter pods. Looking through the test logs I can see:
I1015 09:42:28.432] Events:
I1015 09:42:28.433]   Type     Reason             Age                   From                Message
I1015 09:42:28.433]   ----     ------             ----                  ----                -------
I1015 09:42:28.433]   Normal   NotTriggerScaleUp  5m3s (x6 over 9m26s)  cluster-autoscaler  pod didn't trigger scale-up (it wouldn't fit if a new node is added): 1 node(s) didn't match node selector, 1 node(s) didn't have free ports for the requested pod ports
I1015 09:42:28.434]   Warning  FailedScheduling   13s (x45 over 10m)    default-scheduler   0/3 nodes are available: 2 node(s) didn't match node selector, 3 node(s) didn't have free ports for the requested pod ports.
I1015 09:42:28.434]   Normal   NotTriggerScaleUp  4s (x56 over 10m)     cluster-autoscaler  pod didn't trigger scale-up (it wouldn't fit if a new node is added): 1 node(s) didn't have free ports for the requested pod ports, 1 node(s) didn't match node selector

This is reported for all 3 node-exporter pods that are from the inclusion of [stable/node-exporter] as a chart dependency.
The self monitor configuration has always been enabled and my changes here have not altered that. Other recent PRs like #17918 have passed testing with the same self monitor configuration. More recent PRs like #17975 are impacted by the same capacity issue.
To fix this in the immediate term I can update nodeExporter.enabled to false in the test values, though it seems that it would be better to sort out the cluster capacity issues so that node-exporter testing is always done.
Who manages the test cluster capacity?
Should I proceed with disabling the node-exporter in the test values?

/retest

@zanhsieh disabling the node-exporter chart in the test values fixes the test failures, though this doesn't seem like the best solution for the long term.

@vsliouniaev
Would you mind to LGTM this chart?
@shaunmansell
Yeap, I agreed. So far I cannot see the configuration to let node-exporter only exports some labeled nodes; that's the best thing we can do.

Could you please update from latest, the tests should work
/test all

@shaunmansell
Would you mind to resolve conflict file please?
stable/prometheus-operator/Chart.yaml
Usually it's just version bump.

@vsliouniaev I've pulled in master and fixed the chart version conflict and see all tests are passing so this should be good to go

/lgtm


Group acronym restriction to not start with a letter should be scoped to our groups, not external groups

It should be possible to model new 3gpp groups if needed.
The field validator for acronym should be tweaked to pay attention to group type.

Missed this when searching. Will close it in favor of #6825 since other issues link there already.


Added Alertift in Alert & Action Sheet.

Project URL
https://github.com/sgr-ksmt/Alertift
Description
Swifty, modern UIAlertController wrapper.
This library enables to create alert and action sheet easily and to reduce your typing(code).
Why it should be included to awesome-ios (optional)
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 3
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Error

:no_entry_sign:
Found 2 link issues

Link issues by awesome_bot

Line
Status
Link

1848
301
https://github.com/uacaps/PageMenu redirects tohttps://github.com/PageMenu/PageMenu

2535
522
http://rypress.com/tutorials/objective-c/index

  Generated by :no_entry_sign: Danger

Nice wrapper! Thank you for contributing! 👍


fix conig enable/disable commands

This checklist is used to make sure that common guidelines for a pull request are followed.
Related command

General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)
[ ] My extension version conforms to the Extension version schema

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

Thank you for your contribution! We will review the pull request and get back to you soon.

@sophiaso In order to make the CLI publicly available when user run az extension add -n spring, we need to update the version.

In setup.py, VERSION = '1.24.1
In HISTORY.md, add description for 1.24.1

LGTM

/azp run


[IMPROVE] piotroski stock criteria

this seems backward
(https://github.com/JerBouma/FinanceToolkit/blob/b39fa9e111d464a6bff645c0e84eda1bea541baf/financetoolkit/models/piotroski_model.py#L278)

Care to elaborate?

my mistake, apologies :D i misread the "did not issue common equity" part of the original paper.


[AutoRelease] t2-cosmosdb-2022-10-25-72506(Do not merge)

https://github.com/Azure/sdk-release-request/issues/3296
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=984
BuildTargetingString
azure-mgmt-cosmosdb
Skip.CreateApiReview
true

issue link:https://github.com/Azure/sdk-release-request/issues/3296


docker images for chains

for automation and testing, would be great to have a field for the docker images for chains — ideally on dockerhub, but if not, should list the registry

+1
This would be really helpful for having the official docker images for the chain versions, that anyone can use for spining up chain nodes for development and testing.

+1

Just putting a note here for automatic pre built images on all the top networks
https://github.com/orgs/strangelove-ventures/packages?repo_name=heighliner


Allow to send shutdown message on SIGINT

As far as I remember @AlexanderMoskovkin has access writes to write and release. PR LGTM though.

Yes, I have. We've discussed the PR, it's ok, I'll merge and release it


Connection recovery doesn't happen with HAProxy without available backends

This continues the discussion from https://github.com/logstash-plugins/logstash-input-rabbitmq/issues/76 . I have confirmed that this is a March Hare bug. This is potentially also a Java client bug, but I'm not knowledgeable enough about the internals here to know that.
The bottom line is that there are situations where, even with :automatic_recovery on, the TCP connection can completely disappear and yet March Hare will not attempt to reconnect, and essentially goes dead into an unrecoverable state. Restarting the server on the other end has no effect, that client is permanently borked.
I confirmed this using the logstash <-> haproxy <-> rmq <- producer setup in the link above with a wireshark capture and lsof.
The short summary here is that if the following sequence happens:

RabbitMQ dies
HA Proxy Sends FIN,ACK, MarchHare sends ACK
MarchHare sends FIN,ACK, HA Proxy sends ACK
Connection now closed
MarchHare attempts reconnect 5s later
No response is received
5s after reconnect attempt MarchHare sends FIN,ACK
HAProxy sends ACK
Silence, no connection exists in the OS stack.

NOTE that by step 8. the connection is half-open, the final FIN,ACK from HA Proxy is never sent. However, the connection is dead at the OS level, so presumably an exception was surfaced to the socket (my sockets knowledge is rusty) that was not handled.
At this point nothing can be done to repair the connection because the client will not attempt to reconnect again.
The stack trace of the MarchHare with a healthy logstash (receiving RMQ input correctly) has 3 background thread pools that I believe come from March Hare, while the one that's unhealthy (in a wedged state) only has one.
Any ideas @michaelklishin ? My money is on some threadpools dying with the socket in a weird state.
On the one hand HAProxy has some fault here perhaps, but the client library should recover from any bad connection state at the TCP level. A bad router could also inflict this kind of damage.

@andrewvc I'm sorry but "threadpools dying with the socket in a weird state" doesn't make any sense. No thread pools are used for connection I/O and RabbitMQ Java client uses JDK I/O exceptions to detect connection failures. If none are thrown then it can only learn about peer termination after a heartbeat timeout. "Bad connection state at TCP level" cannot be reliably detected any other way.
How can this be reproduced without Logstash?

I demonstrated in https://github.com/logstash-plugins/logstash-input-rabbitmq/issues/76 that I cannot reproduce it with March Hare alone.

@acogoluegnes can you try reproducing this with https://github.com/logstash-plugins/logstash-input-rabbitmq/issues/76#issuecomment-256156464 on Linux? I'd not use the compose thing just yet because the last thing we need is involving more moving parts.
It would be interesting to conduct the same test for the Java client (e.g. with a JRuby or Groovy script).

From https://github.com/logstash-plugins/logstash-input-rabbitmq/issues/76#issuecomment-257710198:
Interestingly MarchHare does recover if rabbitmq comes back in under the 5s window

so a hypothesis that looks plausible is that MarchHare::Session#reconnecting_on_network_failures gets an exception it does not expect.

From https://github.com/logstash-plugins/logstash-input-rabbitmq/issues/76#issuecomment-257726747:
Based on the behavior, I was able to reproduce this without docker and without haproxy

Run rabbitmq + logstash
Let logstash rmq input connect
Stop rabbitmq
run nc -l 5672 to accept the next connection retry from Logstash
wait until 'AMQP' appears on nc (this is the rmq client attempting to reconnect)
After this attempt to reconnect, rmq input never tries again.

so what's really going on is AMQConnection in RabbitMQ Java client not receiving a protocol handshake response and no heartbeat mechanism is initialized at that point. To cope with that, Java client has a handshake timeout but March Hare did not retry on a  java.util.concurrent.TimeoutException.

Thanks to solid investigative work by @andrewvc and @jordansissel, this should be resolved by #108.


Feature: Publisher support for async iterator

I have a yielding generator that produces msgs into a topic.
I wish the following syntax was valid:
import asyncio
import random
from contextlib import asynccontextmanager
from typing import AsyncIterator

from faststream import ContextRepo, FastStream
from faststream.kafka import KafkaBroker

broker = KafkaBroker("localhost:9092")

@broker.publisher("number_of_the_day")
async def num() -> AsyncIterator[int]:
    while True:
        yield random.randint(0, 10)
        await asyncio.sleep(86400)

@asynccontextmanager
async def lifespan(context: ContextRepo):
    asyncio.create_task(num())
    yield

async def main():
    await FastStream(broker, lifespan=lifespan).run()

if __name__ == '__main__':
    asyncio.run(main())

Current workaround
import functools

def pub(publisher):
    def decorator(func):
        @functools.wraps(func)
        async def inner(*args, **kwargs):
            async for x in func(*args, **kwargs):
                await publisher.publish(x)
        return inner
    return decorator

# [...]
@pub(broker.publisher("number_of_the_day"))
async def num() -> AsyncIterator[int]:
    while True:
        yield random.randint(0, 10)
        await asyncio.sleep(86400)
# [...]

I would in fact also like publisher to be usable standalone.
In my example I am scheduling it in the background using asyncio.create_task as part of lifespan with the help of my "workaround" pub  decorator.

You can use publisher.publish interface alone
I don't like an idea to create publish side-effect on original function call, so all interfaces can be used only in explicit way: @broker.publisher(...) obly with @broker.subscriber(...), publisher.publish(...) - on other cases


A bug in switch_gate

Describe the bug
In fmoe/gates/switch_gate.py line 45:
 capacity = math.ceil(cap_rate * inp.shape[0])
should be:
 capacity = math.ceil(cap_rate * inp.shape[0] / self.num_expert) ?

That is a good point. I think you are right. Can you please open a  pull request on this? Thanks.
BTW, I am also wondering if the capacity calculation in GShardGate is wrong. @zms1999

Hi, guys!
Thanks for your fantastic work.
I met a problem when I use class SwitchGate, can you take a look at it for me?
The following is my code:
import torch
from fmoe.gates import *

device = torch.device("cuda:0")

sg = SwitchGate(d_model=64, num_expert=5, world_size=2)
sg = sg.to(device)

input = torch.rand(128, 64) # (batch_size, d_model)
input = input.to(device)

idx, val = sg(input)
print(idx, idx.shape)
print(val, val.shape)

Parameter word_size can only set to 1, or it will occur the error "Segmentation fault (core dumped)".

@Peg-Wu As you are not using torch distributed, world_size has to be 1.

谢谢您的回复~
如果我想用DDP进行加速，
我应该怎样修改代码，
可以使用pytorch官方的DDP并行吗

@Peg-Wu Refer to this test

非常感谢！


Add TTL/Throttle to initialism

Just playing around with multi-version and apigateway-controller - found this tiny edge case
Signed-off-by: Amine Hilaly<EMAIL_ADDRESS>By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/lgtm


Error with  example grin-server.toml

In  example grin-server.toml

Seeding type is set to List with line 104 seeding_type = "List"

line 109 is commented which lists seeds list #seeds = ["mainnet-seed.grinnode.live:3414"]

When grin server is initialized it gives the error
ERROR grin_util::logger -
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
 Configuration("Seeds must be configured for seeding type List")': src/bin\cmd\server.rs:57   0: <unknown>

Is the line 109 accidently commented?

line 109 is commented which lists seeds list #seeds = ["mainnet-seed.grinnode.live:3414"]
should be commented-in, so you will get the Seed list from the Grinnode.live seed-server
Did you try it with the commented-in version like this:
seeds = ["mainnet-seed.grinnode.live:3414"]

Can we close this issue now? @stakervali