What's the license?

The LICENSE file says it is Apache License 2.0, but in the run.py it is AGPL?
https://github.com/Evoland-Land-Monitoring-Evolution/sentinel2_superresolution/blob/83fa1ba00e3fdea82dca71bb3ba744013e98cfa3/src/sentinel2_superresolution/run.py#L77
Which is the correct one?
A nice project, by the way.

Licence is indeed Apache 2.0 and this is a glitch in the code.
Fixed in https://github.com/Evoland-Land-Monitoring-Evolution/sentinel2_superresolution/commit/6fd0befc49986823d6fd55044cd5653fc101e2b3


fix: link to Experiments (index page)

per https://github.com/iterative/dvc.org/pull/4271#pullrequestreview-1272139385

Not sure how these passed PR link checks. Do we need a post-mortem?

Thanks! I didn't mean something that formal really. I was just curious as to how it might have happened, and now I know.

Did we not have the redirects?

I think that there was a temporary (302) redirect from /doc/user-guide/experiment-management to /doc/user-guide/experiment-management/experiments-overview before and that was simply removed then the latter ceased to exist. We just somehow forgot to update all the links, oops -- that was probably me :p

U: I wasn't able to find the redirects change I was referring to (this is the closest). I suppose it can't hurt to add a redirect since these links were broken: See https://github.com/iterative/dvc.org/pull/4275.


luci-app-nlbwmon: Raw values pushed up to human readable ones, seeming way too large

Steps to reproduce:

go to: Services → Bandwidth Monitor → Display tab → Traffic Distribution tab

Actual behavior:

Connections, Download (Bytes), Download (Packets), Upload (Bytes) and Upload (Packets) look weird:

because each table cell contains two text nodes that are rendered indistinguishable from one single text node containing both strings, without separation with a space. The numbers thus appear as one, very large number.
(screenshot on Chromium Version 122.0.6261.39 (Official Build) Arch Linux (64-bit))

Expected behavior:
Raw numbers only displayed on mouse hover or otherwise distinguished from the human readable one.

Additional Information:
OpenWrt version information from system /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='22.03.2'
DISTRIB_REVISION='r19803-9a599fee93'
DISTRIB_TARGET='ath79/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt 22.03.2 r19803-9a599fee93'
DISTRIB_TAINTS=''

luci-app-nlbwmon version: git-23.119.78260-8aaf581

Looks like https://github.com/openwrt/luci/commit/90a2b1eaeb58b7169b31fdc097c5bfe6f557c778 is missing. Did you try clearing your browser cache?  Also a duplicate of #6388

Yes thanks, I just saw on another installation that it looked like in your screenshot. I will update luci then.

Thanks! Was wondering about that (also on 22.03.2). Appreciate the fix, upgraded luci-base and all looking good!


feat: port ModelTheory.Graph

[x] depends on: #3980

This PR/issue depends on:

leanprover-community/mathlib4#3980
By Dependent Issues (🤖). Happy coding!

This PR/issue depends on:

leanprover-community/mathlib4#3980
By Dependent Issues (🤖). Happy coding!

bors merge


Close button inactive when file upload failed

The red interactive close button does not work

Hello, are you talking about the red icon in the picture above? If so, you may be mistaken, this is just a picture display, there is no closing function.


[incubator/jaeger] query sidecar agent has no resource request

the sidecar to the jaeger-query deployment has no resource requests:
https://github.com/helm/charts/blob/master/incubator/jaeger/templates/query-deploy.yaml#L112
Which chart:
incubator/jaeger
What you expected to happen:
All pods should have resource requests so the kubernetes scheduling works correctly.

The chart has been deprecated / moved: https://github.com/helm/charts/commit/42892c2304f89d389ab7cd747d591d876fadb0e5


AtomicCell: Use atomic-maybe-uninit

This fixes UB when lock-free and the value has uninitialized bytes, by using atomic-maybe-uninit crate.
Fixes #315
Fixes #748
Also, this makes 128-bit atomics lock-free on some platforms.
Closes https://github.com/crossbeam-rs/rfcs/issues/13
Currently, this patch always uses fallback (seqlock) on environments that do not support inline assembly, such as Miri.
It is possible to use atomic-maybe-uninit crate to fix UB of concurrent access with volatile read/write in seqlock/deque (#744, #859), but that is not included in this PR and is left to subsequent PRs.

cc @RalfJung

Currently, it is not possible to use MaybeUninit in the input registers of an inline assembly (i.e., when processing MaybeUninit, values must be passed through memory), so this worsens performance.
Before:
test concurrent_load_u8     ... bench:     600,658 ns/iter (+/- 11,986)
test concurrent_load_usize  ... bench:     601,385 ns/iter (+/- 11,719)
test concurrent_store_u8     ... bench:   1,358,933 ns/iter (+/- 192,961)
test concurrent_store_usize  ... bench:   1,356,045 ns/iter (+/- 20,230)

After (pass by memory):
test concurrent_load_u8     ... bench:     868,554 ns/iter (+/- 150,633)
test concurrent_load_usize  ... bench:     851,380 ns/iter (+/- 7,139)
test concurrent_store_u8     ... bench:   2,029,710 ns/iter (+/- 178,712)
test concurrent_store_usize  ... bench:   2,038,341 ns/iter (+/- 196,265)

If I change the atomic-maybe-uninit implementation to pass by value using transmute, performance will be equivalent to the current one, but it is UB when the input value contains uninitialized bytes (because it is transmuted to integer).
After (pass by value):
test concurrent_load_u8     ... bench:     601,504 ns/iter (+/- 12,824)
test concurrent_load_usize  ... bench:     600,052 ns/iter (+/- 15,885)
test concurrent_store_u8     ... bench:   1,357,697 ns/iter (+/- 211,465)
test concurrent_store_usize  ... bench:   1,357,504 ns/iter (+/- 252,722)

It would be nice if the inline assembly could allow MaybeUninit registers as thomcc had previously proposed.

Filed https://github.com/rust-lang/rust/pull/114790 to allow MaybeUninit in input and output of inline assembly.

Since this PR was opened we have made many improvements to both atomic-maybe-uninit and the compiler. Resolving performance issue (https://github.com/rust-lang/rust/pull/114790), improving and stabilizing inline assembly support on tier 2 targets (https://github.com/rust-lang/rust/pull/131258, https://github.com/rust-lang/rust/pull/131781, etc.), fixing or avoiding rustc/LLVM bugs, improving code quality (https://github.com/taiki-e/atomic-maybe-uninit/pull/30, etc.), improving platform support (atomic-maybe-uninit currently supports all CPU architectures supported by Rust other than C-SKY), etc.
I think we can now finally merge this.


improvement(auto-completion): fix documentation and format of suggestions

closes #208

Can we easily export the documentation into a table so others can easily review this? This is on of the primary interaction methods with Prisma schema, so getting these right would be nice.

For sure, I can move out all strings to a JSON file, which is more readable and just access that file also in the code.


screenshots hang in jupyter notebook

Following along the jupyter-notebook-demo example:  https://github.com/google/neuroglancer/blob/master/python/examples/jupyter-notebook-demo.ipynb, the block on screenshots causes the cell to hang when running the notebook. In particular, this line:
screenshot_image = Image(value=viewer.screenshot().screenshot.image)
The rest of the notebook works fine for me. I'm using the python neuroglancer version 1.1.3.
There was a similar issue raised in the Seung lab fork: https://github.com/seung-lab/neuroglancer/issues/277, but this was closed because the user was satisfied with a script solution. They were using a different method for taking screenshots:
viewer = ng.Viewer()

ss = ng.ScreenshotSaver(viewer, '/tmp/')

ss.capture()

This method also freezes for me in jupyter notebook, but works in a script. It would be great to get screenshots working in jupyter notebook.

I can't reproduce this locally with Python 2.7 and Jupyter notebook server 5.7.8, but what version of Python/jupyter are you using?
Capturing a screenshot waits until all of the data is successfully loaded in Neuroglancer.  If something prevents that from happening, then it will hang indefinitely (obviously not ideal behavior).
You could try checking the browser developer console to see if there are any errors.

Python 3.6 or 3.7, Jupyter notebook 6.0.0. Console log is clean other than the usual favicon 404 error.

Okay, I can reproduce in Python 3.7 with Jupyter notebook 6.0.1.  I'll look into it.


Do not show warning if it is unneccessary

Do not show warning "Depending on the settings and add-ons of your browser, it may not be possible to export corpus excerpts that require authentication." for export instances which do not require authentication.

This may best be enabled by a config flag "session-riding".


adobe_flex_sdk: <IP_ADDRESS>59 -> apache-flex-sdk: 4.16.1

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

I just built this locally. It turns out that jre is missing as a runtime dependency since most of the binaries call java. You can either patch all scripts to replace java with its full path in the nix store or wrap the programs calling it using makeWrapper.

@GrahamcOfBorg  build apache-flex-sdk

Success on x86_64-linux (full log)
Attempted: apache-flex-sdk
Partial log (click to expand)
unpacking source archive /nix/store/f56fii2rd9lc5v8gh1l251nfprp9cv66-apache-flex-sdk-4.16.1-bin.tar.gz
source root is apache-flex-sdk-4.16.1-bin
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file apache-flex-sdk-4.16.1-bin/samples/themes/graphite/src/assets/flex_skins.swf
patching sources
configuring
no configure script, doing nothing
building
installing
post-installation fixup
/nix/store/lwxxjxcwkn3f42yhk5g8yvym0rvhr0iq-apache-flex-sdk-4.16.1

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: apache-flex-sdk
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-darwin (full log)
Attempted: apache-flex-sdk
Partial log (click to expand)
unpacking source archive /nix/store/f56fii2rd9lc5v8gh1l251nfprp9cv66-apache-flex-sdk-4.16.1-bin.tar.gz
source root is apache-flex-sdk-4.16.1-bin
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file apache-flex-sdk-4.16.1-bin/samples/themes/graphite/src/assets/flex_skins.swf
patching sources
configuring
no configure script, doing nothing
building
installing
post-installation fixup
/nix/store/nbc3c2l05j1il9z533j9a3s3c3cd70d2-apache-flex-sdk-4.16.1


Update README.md

Pull Request Template
Description
Added a scholarship and enhanced the readme.md
Type of change
Please delete options that are not relevant.

[x] This change requires a documentation update

Checklist:

[x] My contribution follows the style guidelines of this project
[x] I have performed a self-review of my own contribution
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have checked my code and corrected any misspellings

@shikha-16 @nehakalbande, please consider this PR under Hacktoberfest and give this PR hacktoberfest-accepted tag.


Adapt table query bbe to new ballerina syntax

Purpose
$subject

This is fixed in https://github.com/ballerina-platform/ballerina-lang/pull/17239/files


⚠ Bofrost.fr has degraded performance

In 3605bba, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1312 ms

Resolved: Bofrost.fr performance has improved in cbcc086.


Concurrent problems with client-side connection creation

The issue tracker is ONLY used for bug report(feature request need to follow RIP process). Keep in mind, please check whether there is an existing same report before your raise a new one.
Alternately (especially if your communication is not a bug report), you can send mail to our mailing lists. We welcome any friendly suggestions, bug fixes, collaboration and other improvements.
Please ensure that your bug report is clear and that it is complete. Otherwise, we may be unable to understand it or to reproduce it, either of which would prevent us from fixing the bug. We strongly recommend the report(bug report or feature request) could include some hints as the following:
BUG REPORT

Please describe the issue you observed:

What did you do (The steps to reproduce)?
Send two messages at the same time. When the producer needs to create a new connection with the broker, one message will fail because the connection is disconnected.

What did you expect to see?
Both messages were sent successfully

What did you see instead?
From the producer, we can see from the log.

2019-03-20 17:07:35,911 INFO test1-send2mq-thread-1 NettyRemotingClient createChannel: remote host[<IP_ADDRESS>:10909] success, DefaultChannelPromise@2c99850(success)
2019-03-20 17:07:35,912 INFO test2-send2mq-thread-2 NettyRemotingClient createChannel: remote host[<IP_ADDRESS>:10909] success, DefaultChannelPromise@5a0a54b3(success)

From the broker, we can see it from the remoteing.log.
2019-03-20 17:07:35 INFO NettyServerCodecThread_1 - Netty Sever PIPELINE: channelRegistered <IP_ADDRESS>:41548
2019-03-20 17:07:35 INFO NettyServerCodecThread_1 - Netty Sever PIPELINE: channelActive <IP_ADDRESS>:41548
2019-03-20 17:07:35 INFO NettyServerCodecThread_1 - Netty Sever PIPELINE: channelInactive <IP_ADDRESS>:41548
2019-03-20 17:07:35 INFO NettyServerCodecThread_1 - Netty Sever PIPELINE: channelUnregistered <IP_ADDRESS>:41548
2019-03-20 17:07:35 INFO NettyServerCodecThread_1 - Netty Sever PIPELINE: channelRegistered <IP_ADDRESS>:41659
2019-03-20 17:07:35 INFO NettyServerCodecThread_1 - Netty Sever PIPELINE: channelActive <IP_ADDRESS>:41659

Please tell us about your environment:
rocketmq version: 4.3.2
jdk version: 1.8.0_101

Other information (e.g. detailed explanation, logs, related issues, suggestions how to fix, etc):

FEATURE REQUEST

Please describe the feature you are requesting.

Provide any additional detail on your proposed use case for this feature.

Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have). Are you currently using any workarounds to address this issue?

If there are some sub-tasks using -[] for each subtask and create a corresponding issue to map to the sub task:

sub-task1-issue-number: sub-task1 description here,
sub-task2-issue-number: sub-task2 description here,
...

I have fixed this problem. #1109

@zhanguohuang Good catch, It seems that it's indeed a bug in creating remoting channel.

@duhenglucky  Thanks.

This issue has already been resolved by link:https://github.com/apache/rocketmq/pull/1109

this is my fix:
private Channel createChannel(final String addr) throws InterruptedException {
ChannelWrapper cw = this.channelTables.get(addr);
if (cw != null && cw.isOK()) {
return cw.getChannel();
}
    if (this.lockChannelTables.tryLock(LOCK_TIMEOUT_MILLIS, TimeUnit.MILLISECONDS)) {
        try {
            cw = this.channelTables.get(addr);
            if (cw == null) {
                ChannelFuture channelFuture = this.bootstrap.connect(RemotingHelper.string2SocketAddress(addr));
                log.info("createChannel: begin to connect remote host[{}] asynchronously", addr);
                cw = new ChannelWrapper(channelFuture);
                this.channelTables.put(addr, cw);
            }
        } catch (Exception e) {
            log.error("createChannel: create channel exception", e);
        } finally {
            this.lockChannelTables.unlock();
        }
    } else {
        log.warn("createChannel: try to lock channel table, but timeout, {}ms", LOCK_TIMEOUT_MILLIS);
    }

    if (cw != null) {
        ChannelFuture channelFuture = cw.getChannelFuture();
        if (channelFuture.awaitUninterruptibly(this.nettyClientConfig.getConnectTimeoutMillis())) {
            if (cw.isOK()) {
                log.info("createChannel: connect remote host[{}] success, {}", addr, channelFuture.toString());
                return cw.getChannel();
            } else {
                log.warn("createChannel: connect remote host[" + addr + "] failed, " + channelFuture.toString(), channelFuture.cause());
            }
        } else {
            log.warn("createChannel: connect remote host[{}] timeout {}ms, {}", addr, this.nettyClientConfig.getConnectTimeoutMillis(),
                channelFuture.toString());
        }
    }

    return null;
}

private Channel createChannel(final String addr) throws InterruptedException {
ChannelWrapper cw = this.channelTables.get(addr);
if (cw != null && cw.isOK()) {
return cw.getChannel();
}
    if (this.lockChannelTables.tryLock(LOCK_TIMEOUT_MILLIS, TimeUnit.MILLISECONDS)) {
        try {
            cw = this.channelTables.get(addr);
            if (cw == null) {
                ChannelFuture channelFuture = this.bootstrap.connect(RemotingHelper.string2SocketAddress(addr));
                log.info("createChannel: begin to connect remote host[{}] asynchronously", addr);
                cw = new ChannelWrapper(channelFuture);
                this.channelTables.put(addr, cw);
            }
        } catch (Exception e) {
            log.error("createChannel: create channel exception", e);
        } finally {
            this.lockChannelTables.unlock();
        }
    } else {
        log.warn("createChannel: try to lock channel table, but timeout, {}ms", LOCK_TIMEOUT_MILLIS);
    }

    if (cw != null) {
        ChannelFuture channelFuture = cw.getChannelFuture();
        if (channelFuture.awaitUninterruptibly(this.nettyClientConfig.getConnectTimeoutMillis())) {
            if (cw.isOK()) {
                log.info("createChannel: connect remote host[{}] success, {}", addr, channelFuture.toString());
                return cw.getChannel();
            } else {
                log.warn("createChannel: connect remote host[" + addr + "] failed, " + channelFuture.toString(), channelFuture.cause());
            }
        } else {
            log.warn("createChannel: connect remote host[{}] timeout {}ms, {}", addr, this.nettyClientConfig.getConnectTimeoutMillis(),
                channelFuture.toString());
        }
    }

    return null;
}


Add uninstall target

This change is

Coverage remained the same at 86.225% when pulling 95fbbe2253a79fd1ca42ff350a2408089b2ae93a on uninstall into 48f4f7db0394c4f65cc6d3eb3d781d914e89a3e4 on master.

Coverage remained the same at 86.225% when pulling f3af7df5fda7bc137735bb9f8456da9a1720dd4a on uninstall into dfc06b6771db93dde6dd2f50cf346f37be006746 on master.

This is a pretty cool trick!


⚠ WSINGRESOS - RECIBOPAGO has degraded performance

In 39198c6, WSINGRESOS - RECIBOPAGO (https://srvshyweb.yucatan.gob.mx/cgi-bin/wspd_cgi.sh/WService=wsingresos/internet/servicios/wsRecibosPagosWeb.r) experienced degraded performance:

HTTP code: 200
Response time: 2081 ms

Resolved: WSINGRESOS - RECIBOPAGO performance has improved in 4e3d34d.


Initial generated gcloud-java-pubsub API and GAX

/cc @mziccard -- Thanks @garrettjonesgoogle !

/cc @tmatsuo

Great to see it's coming. Have some questions.

What does GAX stand for?
The size of the change exceeds the threshold of comfortably reviewing the code on github. Are there any other options?
However, most of the files are just auto-generated and no need for review, please state so in the description, which might be helpful for reviewers.

Thanks!

@tmatsuo : This code is auto-generated by an internal team hoping to give us a bunch of tools to use. This was clear to us (they sent us an e-mail beforehand).

I have a few things to mention:

The stuff under gcloud-java-gax is going to move to a separate repository in the near-ish future, so gcloud won't hold it for too long.
Pubsub doesn't yet have grpc turned on externally, so the code can't be tested against the real service yet.
The List* functions don't work (even against a version of pubsub with grpc turned on) - we need to do some extra work for the page streaming pieces to work.

Great! I will look at this PR more carefully tomorrow.
Few questions/comments:
What is stopping us from moving gax into its own gitHub repository sooner than later?

Also, I wonder in the case of GAX if you really want to check-in the generated part or can
that be generated in the build?
Because PubSub is not yet public I think this PR should be against a dedicate branch and not master (as people expect anything in master to be fully functional).
Also, this PR is too big for GitHub to work correctly. e.g. it can't show the full file list, or I can't
even comment on files as I can only see them in "View" mode (which does not allow adding comments). I was about to add a comment in the gcloud-java-pubsub/README.md saying that some links are broken and it does not conform to the new page style...
As for the service specific generated code, I think we did say before that we would check them in but
I think it would be good to publicly (e.g. here) explain why we prefer that over dynamic generation based on the service proto (which could be checked in or retrieved as a maven dependency).
I also find the src/main/java vs src/generated/main/java distinction a bit strange, as also the files
under src/main/java are generated.
So far, services also included a package-info.java with a "how-to-use-this-service" example, do you think this is something that you can generate as well?
As for the generated code, it looks like "@param" wrapping is not using the google-style.
amd Javadoc does not include "@return" or "@throws".
Also, I am not sure the ServiceApi classes are easily testable, considering their private constructor
and no public interface. BTW, so far for all gcloud-java classes we scope them under "com/google/gcloud" package.
Overall, I think we should treat the ServiceApi classes as spi files (e.g. gcloud-java-pubsub/src/main/java/com/google/gcloud/spi/v1/SubscriberApi.java) and provide a hand-crafted APIs that will be the user-facing and use the common setup mode (using gcloud-java-core).

/cc @anthmgoogle

We are going to put GAX into its own org, and we'll need to go through the open source approval process. We didn't want to block the pubsub effort on that.
We know how to generate the GAX code using gradle, and we already have that working internally, and that's what we'll use in our own repository. It doesn't seem worth the effort to get it working under maven (if that's possible, we're not sure) for the short term.
I can switch the PR to a different branch and break it apart. What is github's limit?
Checking in service-specific generated code: This is to allow for manual additions to the generated code, and also short-term edits for expediency.
It is true that files under src/main/java are generated, but they also take manual edits, so they aren't purely generated either.
I do have some example code to use this wrapper, but it doesn't run yet (due to the issues named earlier), which is why I held back on submitting it. I could put some example code into a package-info.java file though.
I will look into the @return and @throws parts of the javadoc.
I have a separate work item to figure out how to test the wrapper. I have been looking at mocking something in the grpc level.

This submission is clearly very large. As a first step, let's separate the size challenges, I think it is a reasonable request to break this down into:

gRpC code-gen. This either needs to be dynamically generated or to be a static copy. The proposal in the near term is that this is static, so it includes a static copy of the code-gen that is api-specific for pub-sub, but also the transitive closure of dependencies. The reasoning is that this should be stable enough in the short term, and this drastically simplifies the run-time dependencies. The plan is to make this dynamic going forward.
GAX or Google API eXtensions. This is the static library that the code-generation depends on. The medium term plan is that this will be live in its own GitHub repo. In the short term, JJ told us to go ahead and check it in to the gcloud-java repo to unblock pubsub.
The wrapper code gen is what our new tooling has produced. At minimum this should be a building block. We should discuss if the "spi" namespace is appropriate.

To drill more into the "spi" namepace, it would be good to understand what that is meant for.
The code generated layer is intended to have good usability in its own right. It should allow for dropping down to direct gRPC use in advanced cases.

@aozarov / others from the team - could you address these points?

Are you ok with allowing the gax component of this PR as-is, i.e. using the src/main/java vs src/generated/main/java pattern, and checking in the generated code instead of generating it in the build? (Just to reduce the churn on this piece, since it is a short-term thing)
I looked up github's limit, and the limit we seem to have hit was the 10k lines changed limit (https://help.github.com/articles/what-are-the-limits-for-viewing-content-and-diffs-in-my-repository/). I was thinking of splitting the PR this way:
A. "low-scrutiny" PR's:

PR for GAX protoc-generated code
PR for GAX handwritten code
PR for protoc & grpc generated pubsub code
B. "high-scrutiny" PR:
PR for ServiceApi generated classes

Does this sound good?

We can consider changing the src/main/java vs src/generated/main/java pattern for the pubsub piece; do you have any specific suggestions?
Do you consider the non-testability of the ServiceApi classes a blocker for checking in the first iteration?
Can you explain the spi namespace?

@garrettjonesgoogle

Are you ok with allowing the gax component of this PR as-is, i.e. using the src/main/java vs src/generated/main/java pattern, and checking in the generated code instead of generating it in the build? (Just to reduce the churn on this piece, since it is a short-term thing)
Sure, if it helps to get things forward faster. Do we agree that in some point later that would be moved to its own repository and consumed as a maven artifact by gcloud-java?

Your PR split proposal sounds fine to me.
Though I would like all of your changes to be in a branch I wonder if the "temporary" gax parts could go to master as they are not consumable by clients directly and in order to avoid the same problem when trying to merge the branch to master...
The spi namespace basically suggests that this code is a lower-level gateway to the service however not recommended to be directly used by clients. The client facing API, which delegates the calls to the spi, is a consistent, simplified, testable and highly documented part of the library that is also go through a much more strict backward compatibility policy.
I suggest to take a look at storage and/or datastore modules of this repository to get more clarification on the distinction.
In its current state it does not look like the service specific parts match the criteria mentioned above, but I was not sure if that was the plan (as we did discuses the options of wrapping the generated code with a thin hand-crafted layer).  @jgeewax what is your take on it?
I think agreeing on this part would clarify and help to resolve some of the other issues mentioned.
Honestly, I think it would be nice if all services (generated or not) share the same setup code (part
of gcloud-java-core). That part already takes care of finding default project and authentication for
AE, GCE and other.
I do think non-testable API is a blocker but that should not be an issue if it lives in a development branch.
BTW, is there some public documentation on Google API eXtension?
Also, I could not see in ServiceApiSettings any options to configure timeout/deadline should
I be looking in a different place?

In its current state it does not look like the service specific parts match the criteria mentioned above, but I was not sure if that was the plan (as we did discuses the options of wrapping the generated code with a thin hand-crafted layer).

@aozarov : This is a super long thread. Can you be more specific about which criteria above we're talking about here?

Just to be clear to everyone regarding the purpose of this code....
Purpose of this auto-generated stuff
For cloud client libraries (ie, gcloud-java), this auto-generated code is meant as a tool for the library maintainers (aka, if you write code that lives in the gcloud-java repository).
If consumers of gcloud-java want to use auto-generated code (or gRPC code) directly (ie, some super advanced case), we shouldn't stop them, however, the auto-generated methods won't be advertised widely as "the way to use gcloud-java".
In short, anyone using these methods directly should be intimately familiar with the source code of gcloud-java, not just how to use it based on our API documentation.
Broader scope: beyond Google Cloud Platform
For non-cloud client libraries (ie, Maps? in the future?), auto-generated code like this is intended to be used directly by customers, as those services don't have a team (like us) working on the client library.
The team working on auto-generating this code has a goal to make it more user-friendly (better method naming, more closely fitting to the language, better documentation), and we will likely benefit from that.
Regardless of how good the auto-generation gets, there are debates about API surfaces that have no right answer, which means we will continue to own and curate the design of the API surface, and can hopefully benefit from auto-generated code doing some of the heavy lifting for us.
This pull request
I requested that the code be sent to us as a pull-request rather than as a dependency so that we could modify the auto-generated code if we needed to, rather than our changes being blocked by pull requests, merges, and then releases before we could get what we wanted from the code.
If the auto-generated code settles to the point where we feel changes are extraordinarily rare, we should discuss breaking it out into it's own repository.
That said, the size of the PR is larger than I expected, so we should try to get an idea of what auto-generated code we expect to need to modify and what code we won't. Anything that falls under the "it's unlikely we'll need to change it" should be kicked off to a separate repository and treated like any other dependency.
/cc @aozarov @mziccard @garrettjonesgoogle @anthmgoogle

@aozarov : This is a super long thread. Can you be more specific about which criteria above we're talking about here?

Mentioned once sentence above "consistent, simplified, testable and highly documented part of the library that is also go through a much more strict backward compatibility policy".
In this PR, issues with "testable" and "highly documented" are clearly visible, but the I think also the lack
of consistency with the other hand-crafted services (e.g. initial setup and usage patterns) is a problem.
However, based on your comment,"Purpose of this auto-generated stuff", I think this case falls exactly in the bucket of our spi layer, which though can be used by clients directly, is not exposed by the main api
and does not adhere to the same standards (e.g. documentation, backward compatibility,..).
In that case, I think the package structure should be changed and some of the things I mentioned earlier
(such as missing a package-info.java)  are no longer an issue.

The biggest part of this is the gRPC codegen for API-independent dependencies (e.g. the java codegen from timestamp.proto). We measured this to be about 2.4Mb in binary form. This is required to use gRPC one way or another. This part could potentially consumed as a dependency instead of source, although we don't have the repository ready to do that right now. If this part is not too big, it would be simplest if we could include it as source in the short term, and switch to either a dependency or dynamic generation later.

Actually it is 2.4Mb in source form, and 767k in compiled jar form.

Just giving my two cents. First, thanks for this PR as it's going to make our job much easier on pub-sub.
What I know/understood:

You can not move (part of) the generated code to its own repository/artifact yet
Looking at the code I expect we will not need to touch the GAX part but I still don't know if we'll need to change the pub-sub generated code

What I suggest:

PR splitting proposed by @garrettjonesgoogle sounds good to me
Merge everything (even the GAX part) to a different branch: so that we can move/rename/experiment and do whatever without affecting the master branch (and Travis) or possible contributors.
Considering all the pub-sub code in this PR as what we call spi (this implies a package renaming): this should allow us to build our (thin) layer on top of it following gcloud-java conventions and practices

What I expect from the future:

You pushing other PRs to if the generated code changes
Us providing you feedback on what we added to/would like to have in the generated code
As soon as we converge to a stable spi layer (no changes on either sides) moving all that should not be in gcloud-java (I am thinking of GAX here) to a different repo+artifact

Question:

Do we need to (try to) test generated code? Can we consider it as trustworthy and rely solely on integration tests?

Thoughts? Sorry for the long post:)

I created a branch pubsub-alpha in my fork, but I don't see a way to submit a pull request to the equivalent branch name in GoogleCloudPlatform (it doesn't exist there yet) - do you guys need to create it first?

I created one for you. same name pubsub-alpha. Even on this branch lets split the PR as you suggested in the proposal.

For those watching, I created the first pull to pubsub-alpha with the generated proto classes: https://github.com/GoogleCloudPlatform/gcloud-java/pull/311

Closing this PR in favor of chunking it into smaller PRs (some of which such as ##320 and  #317were already merged).
However, this thread still have few unanswered questions such as:

timeout/deadline handling
testing of generated code


Fix AtriumDB version in requirements.txt to match desired release.

The current atriumdb version specified in requirements.txt: 2.2.4 doesn't exist and fails when trying to install from PyPi.
This branch corrects the error to specify 2.4.0

Note that this PR works in conjunction with #105 , without the most recent version of AtriumDB, the new data writing methods added in #93  and return_nan_filled param name in the Nan Adapter introduced in #105 will not work.

thanks will!


7/01 Publish for lynn

Docs Build status updates of commit 6214c76:
:warning: Validation status: warnings

File
Status
Preview URL
Details

rd/index.yml
:warning:Warning

Details

rd/map.yml
:warning:Warning

Details

rd/lynn-langit.yml
:white_check_mark:Succeeded

rd/media/profiles/lynn-langit.jpg
:white_check_mark:Succeeded

rd/toc.yml
:white_check_mark:Succeeded

rd/index.yml

Line 0: [Warning-InvalidFileLink] Invalid file link:(~/about).
Line 0: [Warning-InvalidFileLink] Invalid file link:(~/CodeOfConduct).
Line 0: [Warning-InvalidFileLink] Invalid file link:(~/map).

rd/map.yml

Line 0: [Warning-InvalidFileLink] Invalid file link:(~/about).
Line 0: [Warning-InvalidFileLink] Invalid file link:(~/CodeOfConduct).
Line 0: [Warning-InvalidFileLink] Invalid file link:(~/map).

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


⚠ ClamAV has degraded performance

In 2d431d2, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 76 ms

Resolved: ClamAV performance has improved in b0f8922 after 543 days, 2 hours, 57 minutes.


Write Remix integration guide

Is your feature request related to a problem? Please describe.
Write an integration guide on the official documentation for using Remix, Tailwind CSS, and Flowbite.
Describe the solution you'd like
Create a new remix.md file and based on the structure of other integration guides (ie. TypeScript) write a guide using this structure:

Introduction to Remix & what companies use it
Create a new Remix project
Install and configure Tailwind CSS with Remix
Install and configure Flowbite
Showcase Flowbite components and example
Starter project repository with MIT License

Describe alternatives you've considered
None.
Additional context
The Remix guide should most likely be based on Flowbite React rather than the main library for obvious reasons.
@tulup-conner created a Remix starter a while ago but I'm not sure if it works with the latest version of Flowbite React - has to be verified.

It works yeah, I use this configuration for my startup

Hey @tulup-conner,
The guide shouldn't be for the vanilla library - it should be based on Flowbite React.
So if your starter configuration works then there's no need to build a starter anymore, just write the integration guide!

I'll take on this one 😈
@tulup-conner I'll use your starter for reference - I might ping you if there's a need for an update.
Cheers,
Zoltan


TypeError: 'ABCMeta' object is not subscriptable

> gh extension install gh640/gh-repo-list
Cloning into '/home/giermulnik/.local/share/gh/extensions/gh-repo-list'...
Enter passphrase for key '/home/giermulnik/.ssh/nb.yz.kiev.ua.key':
X11 forwarding request failed
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 19 (delta 4), reused 15 (delta 3), pack-reused 0
Receiving objects: 100% (19/19), 4.74 KiB | 1.58 MiB/s, done.
Resolving deltas: 100% (4/4), done.
✓ Installed extension gh640/gh-repo-list

> gh repo-list
Traceback (most recent call last):
  File "/home/giermulnik/.local/share/gh/extensions/gh-repo-list/gh-repo-list", line 40, in <module>
    def list_commands() -> dict[str, Callable[[], None]]:
TypeError: 'ABCMeta' object is not subscriptable

The python3 resolves on my end to python3.8. Changing it to python3.9 fixes the issue.
It might worth to adjust README with the requirement since now it says it's Python 3 compatible while it requires at lease 3.9.
Thanks.

...or make the script backward compatible with Python 3.8 🤔

@yermulnik
Thanks. Though I've not tested yet, I guess the problem with Python 3.8 is only on the type hint. I'll make the script compatible with Python 3.8 (and 3.7 if easily possible) in a few days.

@yermulnik
I adjusted the type hints to support Python 3.8 (and 3.7) in #3. If you don't mind, please try checking if the HEAD works in your environment.
Related commits:

https://github.com/gh640/gh-repo-list/commit/d207c1692462af9d21e366bc30ec643dbeec0a02
https://github.com/gh640/gh-repo-list/commit/ab1827921410d7c5af620b5bdea17ea13c83afe4

😲
> gh extension install gh640/gh-repo-lis
extension is not installable: missing executable

@yermulnik
Thanks. Maybe gh640/gh-repo-lis last t is missing?

Oh 🤦🏻 Copy-paste user error 😂 Thanks for the pointer. I already went with cloning it directly into ~/.local/share/gh/extensions 😂
It works now w/o issues with Python 3.8. Thanks!

@yermulnik
Yay! Thanks :D


merge from arlac77/npm-package-template-esm-only

.gitignore

chore(git): update .gitignore from template

Codecov Report

Merging #842 into master will decrease coverage by 1.26%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #842      +/-   ##
==========================================
- Coverage   96.24%   94.98%   -1.27%
==========================================
  Files          17       17
  Lines        2293     2293
  Branches      264      255       -9
==========================================
- Hits         2207     2178      -29
- Misses         83      112      +29
  Partials        3        3

Impacted Files
Coverage Δ

src/service-config.mjs
73.86% <0%> (-5.69%)
:arrow_down:

src/service.mjs
89.57% <0%> (-4.05%)
:arrow_down:

src/endpoints-mixin.mjs
92.24% <0%> (-1.73%)
:arrow_down:

src/service-provider-mixin.mjs
94.16% <0%> (-0.37%)
:arrow_down:

Continue to review full report at Codecov.

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

Coverage decreased (-1.1%) to 95.623% when pulling 49696cb73c574165a09c421ef66c2b4b7a986093 on npm-template-sync/1 into ff69bcc6c5fe8235d34c785a0c87cc421291ef80 on master.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Bugfix i2c_smbus_write_block_data

Fixed a bug where the i2c_smbus_write_block_data function would fail to send the last byte of the array.
What's in this pull request?
I Fixed a bug where the i2c_smbus_write_block_data function would fail to send the last byte of the array. This was due to an incorrect range for the for loop. It discarded the last element of the array.  This change makes sure the last element gets sent as well.
Is there something you want to discuss?
There is something wrong with the i2c_smbus_read_block_data function as well, but I was not sure about how to make the correct changes. Wasn't sure about the structure that the data array has. We might need to discuss that further.
Pull Request Checklist

[x] I've added a copyright header to every new file.
[x] Every new file has been correctly indented, no tabs, 4 spaces (you can use swiftlint).
[x] Verify that you only import what's necessary, this reduces compilation time.
[x] Try to declare the type of every variable and constant, not using type inference greatly reduces compilation time.
[x] Verify that your code compiles with the currently supported Swift version (currently 3.0.2 to support boards with Raspbian, don't use any 3.1 or 3.1.1 feature)
[x] You've read the contribution guidelines.

Oh man, you’re totally right! I need to get my github knowledge on track... I’ll correct it later :)


How to add a new point of interest permanently in the Dreamview interface

Hi,
I am trying to add a new point of interest through the Route Editing panel available in Dreamview. I first select the start and end routing point and then click on "Add Point of Interest" but it just shows me the window for the already existing Points of Interest and need to select one of the existing ones.
What is the procedure to add a new point of interest? And also how to add it permanently so that i can reuse the same route whenever i want in the future.
Thanks in Advance.

There's a default_end_way_point file for each map to specify point of interest, you can refer to: https://github.com/ApolloAuto/apollo/blob/master/modules/map/data/demo/default_end_way_point.txt.

Hi Just need to select one end point and click "send rouint request" you can add permanent POI at modules/map/data/your_map/default_end_way_point.txt ——Reply reference comes from the Apollo developer community issue master contest https://apollo.auto/developer/questiondata_cn.html?target=658


autocomplete-plus should be implemented

At this moment autocomplete-plus is not working. I can't autocomplete anything, not even the main()

Autocompletion in Atom is not provided/handled by language packages, but rather specific autocomplete provider packages. Although I suspect you might be referring to snippets since you mention main(), and in that case, yes that is not currently working. There is currently no way to "inherit" snippets from other languages, so in order to get C/C++ snippets working in this package, we'd need to duplicate the snippets from language-c. That is entirely doable, I just never got around to it.


Publish mingw version

Currently, the jvm, js, linux packages are deployed, but not mingw.

+1 for mac

fixed in 2.1.15.


Console.WriteLine logging (remnant I guess)

https://github.com/NetSparkleUpdater/NetSparkle/blob/a38b203a58c97ff43d43d8dd3ef801590b0048b7/src/NetSparkle/Downloaders/WebRequestAppCastDataDownloader.cs#L135
I don't think having CW here is intentional, more likely a remant of old-style logging.

Fixed in #522


posix/passing_args.md: Improve phrasing

Hey there, excellent tutorial! As I'm following it for an assignment I thought I'd come by and make a few suggestions. I can keep them all in this one PR if you like but I don't know how many things I'll spot.

I see you have this as a draft, once you're ready for it to merge, feel free to remove the draft marker and I can merge it.


error

I'm getting an error when running this and not really sure how to diagnose or fix it.
Traceback (most recent call last):
  File "C:\Users\rober\Downloads\confluence-page-copier-master\confluence-page-copier-master\copier.py", line 508, in <module>
    recursion_limit=args.recursion_limit
  File "C:\Users\rober\Downloads\confluence-page-copier-master\confluence-page-copier-master\copier.py", line 136, in copy
    skip_attachments=skip_attachments
  File "C:\Users\rober\Downloads\confluence-page-copier-master\confluence-page-copier-master\copier.py", line 115, in copy
    self._copy_attachments(source, page_copy_id)
  File "C:\Users\rober\Downloads\confluence-page-copier-master\confluence-page-copier-master\copier.py", line 347, in _copy_attachments
    attachment_comment=attachment_comment
  File "C:\Users\rober\Downloads\confluence-page-copier-master\confluence-page-copier-master\copier.py", line 363, in _create_attachment
    return self._process_attachment(url, attachment_name, attachment_content, attachment_type, attachment_comment)
  File "C:\Users\rober\Downloads\confluence-page-copier-master\confluence-page-copier-master\copier.py", line 376, in _process_attachment
    prepared_request = req.prepare()
  File "C:\Python27\lib\site-packages\requests\models.py", line 251, in prepare
    hooks=self.hooks,
  File "C:\Python27\lib\site-packages\requests\models.py", line 298, in prepare
    self.prepare_body(data, files, json)
  File "C:\Python27\lib\site-packages\requests\models.py", line 449, in prepare_body
    (body, content_type) = self._encode_files(files, data)
  File "C:\Python27\lib\site-packages\requests\models.py", line 152, in _encode_files
    fdata = fp.read()
AttributeError: 'NoneType' object has no attribute 'read'

Hello, @robertlevy.
First of all, sorry for late reply :( Got a lot of work...
Can you please give me a sample command that you are trying to execute?
There is definitely something wrong with attachments.


Flush stdout and stderr so messages appear immediately even when piped

This ensures that messages will appear in a timely manner even when piped through a program like tee.

:+1: this is a very annoying issue when running big number of benchmarks. (you have to tee otherwise some benchmarks get lost in the terminal history etc.)

Nice, thanks!


Add detail to instructions for Windows

The command prompt needs to be run as an administrator, or else attempting to update results in this error below:
npm ERR! code EPERM
npm ERR! syscall mkdir
npm ERR! path C:\Program Files\nodejs\node_modules\.staging
npm ERR! errno -4048
npm ERR! Error: EPERM: operation not permitted, mkdir 'C:\Program Files\nodejs\node_modules\.staging'
npm ERR!  [OperationalError: EPERM: operation not permitted, mkdir 'C:\Program Files\nodejs\node_modules\.staging'] {
npm ERR!   cause: [Error: EPERM: operation not permitted, mkdir 'C:\Program Files\nodejs\node_modules\.staging'] {
npm ERR!     errno: -4048,
npm ERR!     code: 'EPERM',
npm ERR!     syscall: 'mkdir',
npm ERR!     path: 'C:\\Program Files\\nodejs\\node_modules\\.staging'
npm ERR!   },
npm ERR!   errno: -4048,
npm ERR!   code: 'EPERM',
npm ERR!   syscall: 'mkdir',
npm ERR!   path: 'C:\\Program Files\\nodejs\\node_modules\\.staging'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It's possible that the file was already in use (by a text editor or antivirus),
npm ERR! or that you lack permissions to access it.
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

Although the error message says to run the command as an administrator, I think it would be helpful for the documentation to instruct users to run cmd.exe as an administator

Thanks for taking the time to open the PR!


sdk 50 against main

This PR is a test run of making changes directly to main instead of a feature branch, as was originally done for this
PR.

@tac0turtle ; @crodriguezvega

Hey guys, I am currently doing the merge for this and I must say that I agree with Marko, it is much better to target main.  Currently the merge is just a lot of playing catch-up.

@crodriguezvega could you please let us know if you are OK with targeting main instead of a feature branch by closing either this PR or #3883 ?
thanks!

Thank you, @faddat. I replied in the other PR.

I'm going ot close this one and keep the branch for reference later.


LDAPFilter::Match throws std::runtime_error if a bundle contains a key that is a leading substring of another key

Calling LDAPFilter::Match on a bundle that contains the keys:
"apple" : "granny smith"
"applesauce" : "yum"

throws a std::runtime_error when creating an instance of cppmicroservices::Properties because Properties::Find_unlocked only does a strncasecmp of key.size() between key and keys[i].
Properties::Find_unlocked should check that the sizes of the two strings are equal before reporting duplicate keys and any exceptions thrown by Properties should be swallowed by LDAPFilter::Match before returning false since Match isn't supposed to throw exceptions.

The way this bug manifests is worth documenting - it's dependent on

if a key is a substring of another key, and
the AnyMap iteration order in Properties constructor.. specifically the line:

  for (auto& iter : p)
in Properties::Properties(const AnyMap& p)
Suppose the range-based iterator gives out the key apple first and applesauce next, there is no exception triggered. However, if the iterator gives out the key applesauce first and then the key apple, the Properties::Find_unlocked call in the constructor does a strncasecmp of the key in question apple and the first 5 characters of applesauce, which is apple and throws an exception because they are equal.
It turns out I can't reproduce the bug with the keys specified in the Issue, however I can reproduce the bug with different sets of keys i.e. hosed, hosedd, hose

Merged.


RedisCommandException: Multi-key operations must involve a single slot while storing PersistedGrant

Hi,
I am getting the following exception while trying to perform the Authorization code flow with IdentityServer4 configured to use the Redis as an operational store:
RedisCommandException: Multi-key operations must involve a single slot; keys can use 'hash tags' to help this, i.e. '{/users/12345}/account' and '{/users/12345}/contacts' will always be in the same slot
IdentityServer4.Contrib.RedisStore.Stores.PersistedGrantStore.StoreAsync(PersistedGrant grant)
IdentityServer4.Stores.DefaultGrantStore<T>.StoreItemAsync(string key, T item, string clientId, string subjectId, DateTime created, Nullable<DateTime> expiration)
IdentityServer4.Stores.DefaultGrantStore<T>.CreateItemAsync(T item, string clientId, string subjectId, DateTime created, int lifetime)
IdentityServer4.ResponseHandling.AuthorizeResponseGenerator.CreateCodeFlowResponseAsync(ValidatedAuthorizeRequest request)
...

My instance of IdentityServer4 based server is configured to use Redis as an operational store:
.AddOperationalStore(options =>
                {
                    options.KeyPrefix = IdSrvConstants.IdentityServerSolution;
                    options.RedisConnectionMultiplexer = scope.ServiceProvider.GetRequiredService<IConnectionMultiplexer>();
                });

and the Redis is AWS ElasticCache clustered Redis instance.
The same code works fine on a single-node Redis.
Based on my understanding, the problem is related to the way the PersistedGrantStore generates the key's names - it does not use the keys hash tags (see https://redis.io/topics/cluster-spec#keys-hash-tags) in order to make sure all the keys will involve a single slot while performing a single Redis transaction.

Can you elaborate more on the mode of Elasticache instance, is Cluster mode On or Off ?

Another question, what is the value of IdSrvConstants.IdentityServerSolution ?

Elasticcache instance is in clustered mode. (Cluster mode on). The constant value is IdM.
We have switched the ElasticCache to non-clustered mode to test (Cluster mode off) and now it's working fine ...

I'm trying to figure out why it's not working in Cluster mode on.
I will keep digging, I though IdSrvConstants.IdentityServerSolution may have { } as a value, but looks it's not.

I was actually thinking that putting the KeyPrefix wit { } might resolve the issue because then all the keys will be hashed based on KeyPrefix only. I will try to change the code and see if it has any impact...

is it possible that the SubjectId format on your side is formatted like {...} ? maybe it's a GUID that you convert into a string by calling .String() which will result in default formatting as `{....}' ?

This is how the Redis store looks like when I run it locally:

As you can see, all sub are GUIDs, but they are formated as a GUID without any {}. The name of the client also doesn't contain the {}

I have tried to wrap the PrefixKey with {}, so it will be {IdM} and it's actually working with clustered ElastiCache

but what will happens is that hashing algo will result in storing all the key/values in one shard only of your cluster, so I don't think this is the outcome you want.
I'm looking at the code, it will be complicated to do this as a fix, rather it will need big investment from my side to implement that here.
I will try to dedicate a time for this, but I can't promise to be anytime soon, sorry for that, feel free to PR if you want to drill into that.

Understood, thank you for your efforts.
In the meanwhile, since I have only 1 shard in my ElastiCache cluster anyway, this resolution will work fine in this use case.

I've also just run into this issue, similar AWS config - has there been any update to this @AliBazzi ?

Can confirm - works when prefix is wrapped in curlies

Hi @simonpinn wrapping the prefix will solve the problem but that will leave your Redis cluster unbalanced and not taking advantage of the clustered Redis
maybe you can use non-clustered instance so you don't waste money/resources on unused nodes, I found out that "fixing" this will leave current data in Redis unreachable, was thinking of wrapping the sub with curlies last year but found out that will leave current users in "logged-out" state cause their old data are no longer reachable.

@AliBazzi Any updates on the issue?


dockerfile to build and launch this in a notebook

I expect the link to the dockerfile will work when it is in the master branch

Codecov Report

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

@@           Coverage Diff           @@
##           master      #63   +/-   ##
=======================================
  Coverage   92.70%   92.70%
=======================================
  Files          16       16
  Lines        1000     1000
  Branches      163      163
=======================================
  Hits          927      927
  Misses         43       43
  Partials       30       30

Flag
Coverage Δ

#unittests
92.70% <ø> (ø)

Continue to review full report at Codecov.

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


Ved sengupta

Assignment 2 List manipulation.

Assignment 2 ompleted .Please Check it

Can you please tell me what the problem is as I am new to git hub it's
difficult for me to loacate the problem
On Sun, 30 Sep 2018 at 20:28, Sushil Maurya<EMAIL_ADDRESS>wrote:

Merged #20 https://github.com/MLCCKolkata/Assignment-2/pull/20 into
VedSengupta.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MLCCKolkata/Assignment-2/pull/20#event-1875393158,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcNLvPzsskFUdstQIcK20GeFi0VNz0DLks5ugNwngaJpZM4W52uY
.

Sorry now I get it that my asssignment has gotten submitted. Thanks!
On Sun, 30 Sep 2018 at 20:32, Ved Sengupta<EMAIL_ADDRESS>wrote:

Can you please tell me what the problem is as I am new to git hub it's
difficult for me to loacate the problem
On Sun, 30 Sep 2018 at 20:28, Sushil Maurya<EMAIL_ADDRESS>wrote:

Merged #20 https://github.com/MLCCKolkata/Assignment-2/pull/20 into
VedSengupta.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MLCCKolkata/Assignment-2/pull/20#event-1875393158,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcNLvPzsskFUdstQIcK20GeFi0VNz0DLks5ugNwngaJpZM4W52uY
.


Fix invalid memory access

I've noticed occasional segfaults from accessing beyond the end of
the file buffer. This adds the correct bound to index variable i.

Can you create a test case or give me an example file & query that this fails on? I haven't been able to reproduce it.
Also, your change causes matches at the very end of a file to not be printed. I've added a test case to master that causes this PR to fail. If you rebase off master, make test should fail for you.

Debugging this was a throwback to my operating systems class.
It's pretty easy to verify (by printing or asserting) that print_file_matches will read one past the buffer end (address buf[buf_len]) on line 136.
Interestingly, that's rarely a problem (even though it's a buffer overrun) because of how mmap works — mmap buffers are implicitly rounded up to the nearest multiple of 4096 bytes. But if buf_len is already a multiple of 4096 bytes, and if buf[buf_len] isn't the start of another mmapped file, you get a segfault.
I can reproduce this reliably under Linux 3.16.0 by searching very large codebases e.g. https://github.com/torvalds/linux with random strings. Specifically, the pattern "W*" seems to segfault every time on that repo.

I just repushed the branch with a fix for the end-of-file problem. Take another look (at your convenience).

Excellent work. Thanks so much for tracking this down.


Support for Table metadata with python

Description
Adds the ability to retrieve Table metadata like description/comment, right now its only possible for columns
Use Case
I am developing a POC that reads the delta from s3 and saves it on Glue, the only missing feature is to save table comment/description to Glue because there's no way to retrieve that information using delta-rs
dt = DeltaTable("<PATH>")
dt.metadata()

This should be pretty straight forward to add using pyo3. If you are interested in doing some Rust hacking, we can help guide the process. Otherwise, we would need to wait for someone to claim the task since a lot of the contributors are busy working on s3 multi writer support.

Hello @cristianoperez,
Thank you for your request!
I will look into it and get you updated.


Release a new binary version of plugin

Hey there!
The last available binary version is 0.4 from 8 months old.
Can you please release a new jar version and mark it in github releases?

Hi Ilya, we're about to release 0.5 this week, we're testing everything is fine on all of our internal projects. Will let you know when that happens. Thanks for interest!
In case you don't want to wait: mvn clean install should do the work. :-)

Any progress with this? It would be extremely useful to have a jar produced and published to more easily integrate with our puppet provisioning for SonarQube.

Hi @scotty6435 @ifourmanov,
2 new versions of plugin have been released. 0.5 for SQ 4.5.7 & 0.6 for SQ 5.4
Let me know if that works for you.


Include links to pure jstar?

You had part of this before (and if you think it was better before, feel free to revert it), but links to the pure jstar executable (in the bin folder) and source code (is this it?) might be good additions to the links section. For this project, I thought links to the jstar-eclipse plugins were more appropriate for the bare minimum.

I think it's fine to leave it the way it is.


[tests] Fixed CI build

Fixed CI build issues due to changes in latest versions of dependencies

coverage: 99.35%. remained the same
when pulling 55f9ef216907901560888dafb9dc250dd781e7f3 on fix-build
into d150127e6ee244b2c25aa2d35f804d3d1124bde4 on master.


Remove Docker Compose make targets

We were only making a single reference to the services-start target in the README.md — and it was to test the Docker image.
Now we explictely tell developers to use docker-compose up application if they want to use Docker Compose to test the image they just built 😄

🦀 Requesting reviewers for this pull request:

@Madumo (contributor with 1 commits in the last 90 days and 19 commits overall)


HostDevice code unification

What this PR does / why we need it:
Recent work on SR-IOV has revealed that although kubevirt uses very similar functionality to passthrough a host-device from the node to the guest, the code does not reflect the common aspects of it.
This PR focuses on unifying and structuring the hostdevice handling in kubevirt for generic host-devices, GPU/s and SR-IOV.
The change also covers the "legacy" handing of (v)GPU/s using the NVIDIA DP.
As part of the change, the following main points have been handled:

Generic, GPU & SR-IOV host-devices now share the same env parsing in
the form of address pools.
The creation of PCI devices are shared between all.
The creation of domain MDEV based devices are shared between GPU and
host-devices.

In terms of code-tree structure:

device:

hostdevice:

generic
gpu
sriov

The hostdevice package contains the common infrastructure.
As part of this change, all host-devices now include an alias which is
composed from a type name prefix (hostdevice, gpu, sriov), followed by
the device name (e.g. gpu-mydev0).
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Generic host-device, legacy and SR-IOV are covered by e2e tests, however, vGPU (mdev) is not.
Release note:
NONE

/test all

/test all

/cc @vladikr

/cc @enp0s3

change: Rebase

Thanks, this is quite a huge PR!
I scrolled through the code and it looks good at first glance.
However, automated testing is quite minimal around mdevs for lack of hardware, as already pointed out in the PR description.
So, I'd like to run some manual testing on this before I feel comfortable approving it.
I should have access to an mdev-capable cluster at the end of the week / beginning of next.
Please bear with me!

Thanks, this is quite a huge PR!
I scrolled through the code and it looks good at first glance.
However, automated testing is quite minimal around mdevs for lack of hardware, as already pointed out in the PR description.
So, I'd like to run some manual testing on this before I feel comfortable approving it.
I should have access to an mdev-capable cluster at the end of the week / beginning of next.
Please bear with me!

Hi @jean-edouard , @vladikr. Just checking to see if there is something I can help with on this (like splitting the PR :) )

Thanks, this is quite a huge PR!
I scrolled through the code and it looks good at first glance.
However, automated testing is quite minimal around mdevs for lack of hardware, as already pointed out in the PR description.
So, I'd like to run some manual testing on this before I feel comfortable approving it.
I should have access to an mdev-capable cluster at the end of the week / beginning of next.
Please bear with me!

Hi @jean-edouard , @vladikr. Just checking to see if there is something I can help with on this (like splitting the PR :) )

@EdDev Thanks for this work! So far I went over most of the changes and everything makes sense to me.
At the first glance, it seemed that we have broken the correlation between the API objects and the allocated devices, but now I see that it's well preserved.
I don't think it makes sense to split the PR.
Please allow me some more time to review the tests and complete the review.

/approve
Thanks @EdDev, really nice PR. Looks good to me.

/hold
Sorry this is taking so long but we now have automated mdev testing provided by:
https://github.com/kubevirt/kubevirt/pull/5974
I suggest we wait until that PR is merged so we can ensure this one doesn't break anything mdev-related.
That probably means this PR will have to be manually rebased, but it seems like the best course of action to ensure code stability.

change: Rebase

/test pull-kubevirt-e2e-kind-1.19-vgpu

/hold cancel

/retest

@jean-edouard , @vladikr , is this ready now?

thanks @EdDev
/approve
/lgtm


Resolve Configuration directly

https://scans.gradle.com/s/2rzfompkwgkx6/tests/overview?outcome=FAILED


[Question] Parsing back log files create by ECS for Serilog.

Hi,
I want to create a parser for exist log file for my https://github.com/Analogy-LogViewer/Analogy.LogViewer application.
Is there an example how to read back a file? All the units test seems to only write logs.

Hi,
I guess you can just read the log file using File.ReadAllLines() and then parse every line using EcsDocument.Deserialize(). You'll need to reference Elastic.CommonSchema package for that.

@andreycha Thanks, I'll try it.

BTW, are the latest changed released as nuget? The last one is from 2021

No. Looks like the plan is to upgrade the library right to 8.4.0, I believe you can follow it here: https://github.com/elastic/ecs-dotnet/issues/197

@andreycha  Thanks!

Thanks for answering @andreycha :+1: Closing this out while we gear up to release #197


FEATURE-RELEASE:support for actionJSON Photoshop API

Adobe introduced actionJSON service, which allows for execution of Photoshop actions in JSON format. See more details https://developer.adobe.com/photoshop/photoshop-api-docs/api/#tag/Photoshop/operation/actionJSON
Description

Bumped up @adobe/aio-lib-photoshop-api version
Added a sample code for actionJson API

Motivation and Context
Since actionJSON supports Photoshop actions in JSON format, which is plain text, it offers more flexibility for Photoshop API users and allows for easy integration of Photoshop API with their workflows.
How Has This Been Tested?

Tested manually

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] I have signed the Adobe Open Source CLA.
[X] My code follows the code style of this project.
[X] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[X] I have added tests to cover my changes.
[  ] All new and existing tests passed.

lgtm. thanks.


Different options to different chunks in one pluign instance.

When webpack make two chunks(eg: a.js and b.js) and I need minify them with different options(for example, a.js can be mangled but b.js shouldn't be mangled)
The uglifyjs-webpack-plugin can not make different options to those two chunks in one plugin instance.
Is it best practice to add two uglifyjs-webpack-plugin instance to webpack config.
Like below:
const UglifyJSPlugin = require('uglifyjs-webpack-plugin');
module.exports = exports = {
    plugins : [
        new UglifyJSPlugin({ /use for a.js/ }),
        new UglifyJSPlugin({ /use for b.js/ })
    ]
}

Is there any way to do this just write one uglifyjs-webpack-plugin in webpack config.Or is there any plan to support the follow way to support multi rule in just one plugin instance.
const UglifyJSPlugin = require('uglifyjs-webpack-plugin');
module.exports = exports = {
    plugins : [
        new UglifyJSPlugin([{
            // options for a.js
        },{
            // options for b.js
        }])
    ]
}

@tsangint better use two instance for this purpose, no plans to support this

@evilebottnawi Thanks for your reply,I'm not sure is it reasonable to use a plugin twice at one webpack config before.I tried and it seems everyting is ok by using two instance.

@tsangint it si normal usage same plugin with difference options twice


Add script to tune parameters

Add a simple script to perform an exhaustive search on the parameter space, based on #154.
For the RTX 4070, these are the results:
Optimal parameters:
NN: Any[128, 64, 32, 1, 4, GemmKernels.Kernel.matmul_singlestage]
NT: Any[128, 64, 32, 1, 4, GemmKernels.Kernel.matmul_singlestage]
TN: Any[128, 64, 32, 8, 1, GemmKernels.Kernel.matmul_singlestage]
TT: Any[128, 64, 32, 2, 4, GemmKernels.Kernel.matmul_singlestage]

plot.pdf
I've been gradually generalising the kernel by fixing any miscompilations / incorrect results that come up, but we still only explore a relatively small part of the design space (around 3.2 / (100 - 85) = 21.3% of the configurations that ought to work). At some point I'll have to look into the incorrect results and error-throwing configurations:
====================================================================================================
Overall configurations:
====================================================================================================
Total:                                     4000 configurations
----------------------------------------------------------------------------------------------------
Skipped due to invalid GemmKernels config: 3402 (85.0%)
Produced incorrect result:                 112 (2.8%)
Threw an error:                            359 (9.0%)
Successful runs:                           127 (3.2%)

@maleadt Could you have a look at this and run it on more recent hardware as well?
Some notes:

Using Octavian to generate the groundtruth on the CPU is pretty much a requirement if you don't want to wait around forever. Probably better to generate the groundtruth on the GPU instead.
I've noticed some configurations result in an illegal memory access. Seems to be a codegen issue, as adding @cuprintf resolves it. I've added an assert for now to mask the issue so we can test that configuration. (Under the assumption that that will not influence the run time too much...)

RTX6000 Ada:
Optimal parameters:
NN: Any[64, 256, 128, 2, 8, GemmKernels.Kernel.matmul_singlestage]
NT: Any[128, 128, 128, 8, 1, GemmKernels.Kernel.matmul_singlestage]
TN: Any[128, 128, 128, 4, 4, GemmKernels.Kernel.matmul_singlestage]
TT: Any[128, 128, 128, 4, 2, GemmKernels.Kernel.matmul_singlestage]

plot.pdf
H100:
NN: Any[256, 128, 128, 2, 8, GemmKernels.Kernel.matmul_singlestage]
NT: Any[128, 128, 64, 4, 2, GemmKernels.Kernel.matmul_singlestage]
TN: Any[128, 256, 128, 4, 4, GemmKernels.Kernel.matmul_singlestage]
TT: Any[256, 64, 128, 2, 4, GemmKernels.Kernel.matmul_singlestage]

No plot, as it failed during make_plot:
N = 128
N = 256
ERROR: LoadError: ConfigError: Requested too many threads for this kernel: This kernel can be launched using at most 384 threads, while this configuration required 512
Stacktrace:
 [1] matmul(conf::GemmKernels.Config{(M = 256, N = 256, K = 256), (M = 256, N = 128, K = 128), 16, (M = 256, K = 1), (M = 8, K = 1), (K = 128, N = 2), (K = 8, N = 1), (M = 128, N = 1), (M = 4, N = 1), (M = 128, N = 16, K = 16), (M = 16, N = 16, K = 16), GemmKernels.Layout.UnsafeAlignedColMajor{Float16}, GemmKernels.Layout.UnsafeAlignedColMajor{Float16}, GemmKernels.Layout.Zero{Float32}, GemmKernels.Layout.UnsafeAlignedColMajor{Float32}, GemmKernels.Layout.Padded{GemmKernels.Layout.UnsafeAlignedColMajor{Float16}, 8}, GemmKernels.Layout.Padded{GemmKernels.Layout.UnsafeAlignedColMajor{Float16}, 8}, GemmKernels.Layout.UnsafeAlignedColMajor{Float32}, GemmKernels.Layout.UnsafeAlignedColMajor{Float32}, GemmKernels.Operator.WMMAOp{16, 16, 16, Float16, Float32}, true, true}, a::CuArray{Float16, 2, CUDA.Mem.DeviceBuffer}, b::CuArray{Float16, 2, CUDA.Mem.DeviceBuffer}, c::CuArray{Float32, 2, CUDA.Mem.DeviceBuffer}, d::CuArray{Float32, 2, CUDA.Mem.DeviceBuffer}; transform_global_to_shared_a::GemmKernels.Transform.Elementwise{typeof(identity)}, transform_global_to_shared_b::GemmKernels.Transform.Elementwise{typeof(identity)}, transform_global_to_shared_c::GemmKernels.Transform.Elementwise{typeof(identity)}, transform_shared_to_global_d::GemmKernels.Transform.Elementwise{typeof(identity)}, transform_shared_to_regs_a::GemmKernels.Transform.Elementwise{var"#3#5"{Float16}}, transform_shared_to_regs_b::GemmKernels.Transform.Elementwise{typeof(identity)}, transform_shared_to_regs_c::GemmKernels.Transform.Elementwise{var"#4#6"{Float16}}, transform_regs_to_shared_d::GemmKernels.Transform.Elementwise{typeof(identity)}, epilogue::GemmKernels.Epilogue.Default, kernel::typeof(GemmKernels.Kernel.matmul_singlestage))
   @ GemmKernels ~/Julia/pkg/GemmKernels/src/matmul.jl:40
 [2] run_gemm(cf::Configuration, a::CuArray{Float16, 2, CUDA.Mem.DeviceBuffer}, b::CuArray{Float16, 2, CUDA.Mem.DeviceBuffer}, c::CuArray{Float32, 2, CUDA.Mem.DeviceBuffer}, d::CuArray{Float32, 2, CUDA.Mem.DeviceBuffer})
   @ Main ~/Julia/pkg/GemmKernels/configs/configs.jl:78
 [3] macro expansion
   @ ~/Julia/pkg/CUDA/src/profile.jl:308 [inlined]
 [4] make_plot(BLOCK_M::Int64, BLOCK_N::Int64, BLOCK_K::Int64, WARPS_M::Int64, WARPS_N::Int64, kernel::Function, transpose_a::Bool, transpose_b::Bool)
   @ Main ~/Julia/pkg/GemmKernels/tuning/tune-wmma.jl:151

@maleadt I made some changes to the script, most importantly:

Write data and logs to files for persistence
Restart tuning script automatically using Bash wrapper, rather than the ugly hack with the @cuassert (which also didn't seem to work in all cases)
Tuning separately for all values of N
Show "error bars" to estimate how reproducable the ratios are; for now the line is $\frac{cuBLAS_{min}}{GK_{min}}$ and the error bars show a "range" of ratios: $\left[ \frac{cuBLAS_{min}}{GK_{Q_3}}, \frac{cuBLAS_{Q_3}}{GK_{min}} \right]$.
Rather than measuring a fixed amount of samples per configuration, continue sampling until the uncertainty is low enough (or a timeout is reached).

Here are some plots already:

plot-rtx-4070.pdf
plot-rtx-2080.pdf

Can you run it on your hardware as well? Depending on how long you want to wait, you may want to tweak BENCH_NORM_CI_THRESHOLD, BENCH_MAX_NUM_SECONDS, BENCH_MIN_NUM_SAMPLES, PLOT_RATIO_MAX_UNCERTAINTY, PLOT_MAX_NUM_SECONDS, and PLOT_MIN_NUM_SAMPLES.


Simplify wasmi bytecode by unifying {I32,I64,F32,F64}Const instructions

During compilation we convert from the actual type to its 64-bits representation and just use that.
This way we also avoid conversions at runtime and have fewer wasmi bytecode instructions.
This could also play an important role since now any constant instruction is the same and therefore the branch predictor might have better chances to correctly predict in cases where many constant instructions are used.

Codecov Report

Merging #338 (727d720) into master (5270b32) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #338      +/-   ##
==========================================
+ Coverage   80.66%   80.74%   +0.07%
==========================================
  Files          76       77       +1
  Lines        9502     9487      -15
==========================================
- Hits         7665     7660       -5
+ Misses       1837     1827      -10

Impacted Files
Coverage Δ

wasmi_v1/src/engine/bytecode/mod.rs
100.00% <100.00%> (ø)

wasmi_v1/src/engine/code_map.rs
86.95% <100.00%> (+0.69%)
:arrow_up:

wasmi_v1/src/engine/exec_context.rs
96.92% <100.00%> (+0.96%)
:arrow_up:

wasmi_v1/src/engine/inst_builder.rs
91.47% <100.00%> (+0.34%)
:arrow_up:

wasmi_v1/src/module/tests.rs
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Rename BoundingBox "extent" property to "edges"

This is a gentle suggestion to simply rename the extent property to edges.  When I see extent I immediately think it's a "size" of some kind, e.g. 3 meters in extent.  I think edges is a better name, since it's returning the edges of the bounding box and not a "size".  @astrofrog?

I'm not even sure it's a useful property and would even be OK to remove it.
Here's what we have now:
http://astropy-regions.readthedocs.io/en/latest/api/regions.BoundingBox.html
The reason we added it was to be able to plot the bbox. Now there's as_patch.
Long term I could imagine we add something like footprint or BoundingBox.to_poly that returns a little more useful representation that you can easily convert to sky coords as well.
Short term I have no opinion on what to put.
Maybe let's just do the rename suggested here.
@astrofrog, @larrybradley - Thoughts?

Ah but I thought it was also used for the extent option in matplotlib, to center the image on the correct coordinates (not just to plot the box).

The only place I see it being used is in the as_patch() method (and I just added that in #92), defining the lower-left edge of the patch.

Sorry, just to clarify, even though it's not used currently in the documentation, it's been very useful for me when calling imshow with the extent keyword. I don't object to the renaming though, but I'd object to the removal.

Ah, OK.  I was unaware that imshow has an extent keyword (I've never used that).  Given that this the name in matplotlib, I don't think we should rename this (even though I don't like the name :smile:).

However, I will modify the PR to include the bit of clarification in the docs that extent values are the edges and not exclusive slice indices.

By the way, I do actually use extent from imshow in http://astropy-regions.readthedocs.io/en/latest/getting_started.html#masks

I modified this PR to leave extent alone, but added some clarification to the docs.


Remove bsdtar

bsdtar on ubuntu 18.04 does not support --no-xattrs. This means it is unsuitable for
use and is currently breaking release.
This PR simply removes the bsdtar use from .drone.yml and changes the Makefile to allow users to set
TAR="bsdtar --no-xattrs" in future should they wish to use that.
Fix #14578 (again)
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

#15256

I'm apologizing again here. I wouldn't have thought it could even bork twice on CI even after many testing by then, and npm 7 was another big issue I had no idea about before. If only there were some sort of guidance on creating a similar CI workflow on my own fork (which has CI enabled on drone.io) I would have discovered these stuff long before.

bsdtar removal is also included in https://github.com/go-gitea/gitea/pull/15273.

Since two mentioned pulls are not ready jet i propose: mergebthis first & let the other pulls be followups that can be checked & reviewed without blocking things

I'd prefer the other one to be merged but if @zeripath would port the bsdtar changes from https://github.com/go-gitea/gitea/pull/15273 into here, we can merge this first.


Add package for keyd

This PR adds keyd, a tool for remapping keys. It has been tested on an rM2.
No configuration is currently bundled. My intent is to create a separate keyd-configs package with community configs (and possibly a mechanism to automatically apply the right one for the active keymap).

I'll have to give this a test on my rM1 to make sure it works as expected. I assume you've tested the latest changes on your rM2 to make sure it works as expected?

I'll have to give this a test on my rM1 to make sure it works as expected. I assume you've tested the latest changes on your rM2 to make sure it works as expected?

Yep, all the keys appear to remap properly.
Testing tips:

Remaps should be as simple as:

[main]
a = x # remaps the a key to output x

Output of keyd should give you device ids, or you can just specify *

So it looks like this won't work on the rM1 in 2.15.1. This will also fail to work on the rM2 for the same reason.
The keyd group also doesn't exist, and the default configuration expects it to exist. This will either need to fixed by the install scripts, or the configuration changed to not use the group.

Do you know what version the uinput module was enabled from? Should a version check be added to the package script?

Not offhand, it was one of the earlier 3.x versions I believe.
A version check doesn't make too much sense in the package, in reality we need to better support version limiting in the toltec repos themselves.
At this point, we will have to hold off on merging this until 3.x support is in progress.

I just want to note that, when I installed the ipk from the build artifact, in the keyd.service, the expected line for ExecStart is /opt/bin/keyd. However, when I installed it, it was /usr/bin/keyd
So either we add a symlink, or try and fix this(which shouldn't happen considering it was supposed to be /opt/bin/keyd)

I just want to note that, when I installed the ipk from the build artifact, in the keyd.service, the expected line for ExecStart is /opt/bin/keyd. However, when I installed it, it was /usr/bin/keyd
So either we add a symlink, or try and fix this(which shouldn't happen considering it was supposed to be /opt/bin/keyd)

No we wouldn't want to have it be in /usr/bin. That's very odd that the file provided isn't being used. My guess is that the keyd source has its own copy of the service file that is replacing the one included in this repo.

Yup, so I thought, why not copy over keyd.service later in the package code instead of at the very beginning(So maybe put it in a temp folder first)
So maybe just copy it over to /etc/systemd/system/ in configure()

I haven't looked too closely, but if there is a keyd.service file in the source that's overwriting the one included in the package folder, changing the order you install the files from the source directory wont do anything. The file isn't there to copy, because it's been replaced. The file will need to be renamed in this repo, and then renamed as part of package() when it's installing it to the final location in the package. Ideally the toltec build system (and toltecmk) should be updated to detect this kind of thing and error if there are files that are going to be clobbered.

Checking for clovvered files it is probably hard: in this particular instance there is no overlapping in the sources, the problem arises at compiel time: https://github.com/rvaiya/keyd/blob/master/Makefile#L37

In this particular case having a separate keyd.service is not needed: it suffices to add PREFIX=/opt/ to the build environment

In this particular case having a separate keyd.service is not needed: it suffices to add PREFIX=/opt/ to the build environment

A tiny bit more than that was required to do it properly, but it should be working now.

This is still not working: the binary is /opt/bin/keyd but the service calls /opt/usr/bin/keyd. I think you are over engineering it a little, setting PREFIX should take care of the path in keyd.service

This is still not working: the binary is /opt/bin/keyd but the service calls /opt/usr/bin/keyd. I think you are over engineering it a little, setting PREFIX should take care of the path in keyd.service

It does not, which is why I added the sed line. I forgot that the default prefix is /usr.

The latest code does, but we are dealing with the v2.4.3 tag which is missing some build process fixes.

This is annoying

The latest code does, but we are dealing with the v2.4.3 tag which is missing some build process fixes.

This is annoying

It is :laughing: , the next time they push a release it will no longer be an issue.

For future reference when we get here, I think this is a good/sane default for the US layout. It at least makes the legends match what the keyboard actually outputs, and exposes some needed keys for terminal usage.
[ids]
2edd:0001 # type folio

[main]
end = layer(opt)
leftshift+end = layer(opt+shift)
= = -
\ = ~

[shift]
= = _
\ = `

[opt]
1 = esc
= = =
\ = \
0 = +
, = [
. = ]
right = end
left = home

[opt+shift]
\ = |
, = {
. = }
right = pagedown
left = pageup

Xochitl doesn't seem completely happy with allowing +/= on the 0/- keys though.

Keyd seems to freak out on boot and has key-repeats even when the key is clicked once.. I have to restart the service to fix it

Keyd seems to freak out on boot and has key-repeats even when the key is clicked once.. I have to restart the service to fix it

I haven't experienced this. What settings are you using?

[ids]
2edd:0001 # type folio

[main]
capslock = overload(control, esc) # Sets the capslock to act as Esc when tapped and Control when held
leftcontrol = overload(control, capslock) # similar or left control

# below 2 lines setup the layers for
# Opt and AltOpt on the Type Folio
end = layer(opt)
rightalt = layer(alternate)

[opt]
1 = esc
, = [
. = ]
/ = \
= = -
right = end
left = home
up = pageup
down = pagedown
backspace = delete

[alternate:G]
1 = f1
2 = f2
3 = f3
4 = f4
5 = f5
6 = f6
7 = f7
8 = f8
9 = f9
0 = f10
= = f11
backspace = f12

That’s my config fire

For the scandinavian keyboard (and others that need non-ascii input keys), one would need xkbmap to make the compose-hack work.

I've tested https://github.com/toltec-dev/toltec/pull/744/commits/a2ab07855dfebca2f1d845a2d5b1527edab7ede6 (build<PHONE_NUMBER>) on an rm2 at <IP_ADDRESS>6.
Upon installation, it instructed me to disable the shutdown target, which seems not relevant.
reMarkable: ~/ opkg install keyd_2.4.3-1_rmall.ipk
Installing keyd (2.4.3-1) to root...
Configuring keyd.

Run the following command(s) to enable the keyd service
$ systemctl disable --now shutdown.target
$ systemctl enable --now keyd

You will need to modify /opt/etc/keyd/default.conf before starting the service

I was able to set the `dvorak` layout with the following config file
[ids]
2edd:0001 # type folio

include layouts/dvorak

[global]
default_layout = dvorak

[main]

Having set the dvorak layout, the shortcuts in https://github.com/toltec-dev/toltec/pull/744#issuecomment-1890389124) do not work. I'll post a config later to make them work again.

Upon installation, it instructed me to disable the shutdown target, which seems not relevant.

What launcher are you using? And what is the output of toltecctl status?

I was able to set the dvorak layout with the following config file
Having set the dvorak layout, the shortcuts in #744 (comment)) do not work. I'll post a config later to make them work again.

If you have a configuration to change the layout to dvorak, it would conflict with the settings I provided. I would recommend reviewing the keyd logs to see if it complains about anything (journalctl -ae keyd), and then you'd need to modify the dvorak layout instead of using the configration.

What launcher are you using?

reMarkable: ~/ opkg list-installed remux
remux - 0.3.0-4

And what is the output of toltecctl status?

reMarkable: ~/ toltecctl status
Enabled: Yes
Supported: Yes
Branch: stable
Model: rm2
OS: <IP_ADDRESS>6

reviewing the keyd logs to see if it complains about anything

Nothing beyond the usual startup messages.
[[0;1;39m-- Reboot --[[0m
Jun 27 21:33:32 reMarkable systemd[1]: Started key remapping daemon.
Jun 27 21:33:32 reMarkable keyd[188]: CONFIG: parsing /opt/etc/keyd/default.conf
Jun 27 21:33:32 reMarkable keyd[188]: Starting keyd v2.4.3 ()
Jun 27 21:33:32 reMarkable keyd[188]: DEVICE: ignoring 0fac:1ade  (keyd virtual pointer)
Jun 27 21:33:32 reMarkable keyd[188]: DEVICE: match    2edd:0001  /opt/etc/keyd/default.conf    (rM_Keyboard)
Jun 27 21:33:32 reMarkable keyd[188]: DEVICE: ignoring 056a:0000  (Wacom I2C Digitizer)
Jun 27 21:41:04 reMarkable keyd[188]: DEVICE: removed   2edd:0001 rM_Keyboard
Jun 27 21:53:58 reMarkable keyd[188]: DEVICE: match    2edd:0001  /opt/etc/keyd/default.conf    (rM_Keyboard)

you'd need to modify the dvorak layout instead of using the configration.

Yes, I'll do that and post it.

launcherctl status would be another output you could share to show what launcher you are on. Forgot to ask for that instead. What you provided works though.
Everything looks fine here, so it would be just that the two configurations are compatible with each other, as one overrides the other.

here is my dvorak keyd config, along with an image of the keyboard with the symbols overlaid
https://gist.github.com/plredmond/6da75360e660a7e240a9013f56af0603


Dependabot Core "free license" for commercial project ?

The repository README.md has this statement:

If you would like to add Dependabot's functionality to your for-profit company's offering then we DO NOT give you permission to use Dependabot Core to do so. Please contact us directly to discuss a partnership or licensing arrangement.

The license file also has this section.

This license lets you use and share this software for free, with a trial-length time limit on commercial use

but here Dependabot is joining GitHub  I find

Dependabot is now free. You'll no longer be billed for it, and if you paid for future months, we'll be in touch to refund you.

Please clarify the different statements. I am not sure whether I can use  Dependabot Core for my Azure DevOps project.

The key statement on dependabot-core licensing is the README. The license is a close approximation to implement that - you're welcome to use dependabot-core for your Azure DevOps project, as long as you're planning to use it to bump only your own / your company's repos (not to provide it as a service to others).

See also https://github.com/dependabot/dependabot-core/issues/3645#issuecomment-839916100


[CI] Upgrade Circle CI to version 2.0

@RocketChat/android

Closes #821

Circle CI 2.0 works much faster than Circle CI 1.0.
Also we can separate the code-analysis job (checkstyle, pmd, ...) from the main build job with Circle CI 2.0, and run them in parallel like this 😆

The new config.yml introduced in this PR doesn't include deployment processes (uploading APKs to Google Play alpha or beta) because Triple-T/gradle-play-publisher is not configured at this time.
(Also, I think it would be better to use fastlane for deploying APKs)

@YusukeIwaki This is looking good to me, and I also agree on using fastlane! Thank you!!! 👏


Faster parsing by changing lhs of assignment-expression to conditional-expression.

Hello,
This change makes parsing much faster (6x as fast in the bench I've created: from 13.7s to 2.0s on my machine) by changing the lhs of assignment-expression to be conditional-expression, and making the rhs optional. That specific rule was a huge bottleneck, and backtracking from assignment-expression-inner (unary-expression lhs) to conditional-expression on almost every single expression was causing some non-linear behavior.
That change alone takes the bench from 13.7s to 8s. Then, removing the cache attribute from postfix_expression speeds it up further to 2s. The cache attribute is no longer needed and so only adds overhead. Before this change, running without the cache attribute would make parsing too slow to be usable.
This change technically deviates from the c11 standard. However, Clang also does the same thing (I actually got this idea from Clang). Here is their justification in ParseExpr.cpp:
/// Note: we diverge from the C99 grammar when parsing the assignment-expression
/// production.  C99 specifies that the LHS of an assignment operator should be
/// parsed as a unary-expression, but consistency dictates that it be a
/// conditional-expession.  In practice, the important thing here is that the
/// LHS of an assignment has to be an l-value, which productions between
/// unary-expression and conditional-expression don't produce.  Because we want
/// consistency, we parse the LHS as a conditional-expression, then check for
/// l-value-ness in semantic analysis stages.

Since this deviates from the strict standard implementation, I completely understand if you don't want to accept this pull. If you can refactor the rules in such a way as to achieve the same speed-up, I'd happily take that change instead!
Notes:
The bench I created was automatically generated by a tool called yarpgen. It's obviously not what real-world C code looks like, but it acts as a good stress-test because it is guaranteed to generate valid c11 code.
Cheers!

Thanks, this is great!
I think this is a reasonable compromise to make, given the huge difference in performance. It shouldn't make user's life much harder, since not all unary expressions are assignable, and lvalueness needs to be checked anyway.

Is it possible to make benchmark smaller? Adding 10M to the repo just for this seems excessive.
Please also add a comment to the grammar file explaining why we deviate from the standard grammar.


[HUDI-5072] Extract transform duplicate code.

Change Logs
When reading the code, I found that the transform methods of MultipleSparkJobExecutionStrategy and SingleSparkJobExecutionStrategy have redundant code. I think we can extract them to make the code cleaner.
Impact
none
Risk level (write none, low medium or high below)
none
Documentation Update
none
Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

@xushiyan Can you help review this pr? Thank you very much!

@nsivabalan Can you help review the code again? Thank you very much!


Find a better way to display the workspaces navbar dropdown

When a project has registered a large number of different WorkspaceData types, the navbar dropdown for Workspace gets very unwieldly. Figure out a better way to display this dropdown.

Possibly move the workspace boxes on the current home page to a "workspace landing page". In the navbar, have the top three "general" items and then a link to the workspace landing page.

Closed by #308


Erlang 21 Support

Only updated supported Erlang release level
I have tested both make slim_cowboy and make rel_cowboy without any issues on Ubuntu 18.04

I'm just removing the otp version check.

Thank you, though :)


[Animation] Expose SkeletonProfile.set/is_required

Fixes: https://github.com/godotengine/godot/issues/89892

Thanks!

Thank you!


Danger breaks on non-english locale systems (Jenkins)

Problem
Danger breaks in https://github.com/danger/danger/blob/master/lib/danger/scm_source/git_repo.rb#L26 if the Jenkins job isn't running with an english locale set in LANG OR LC_ALL since it's expecting git responds in english and matches Fetch URL.
bundler: failed to load command: danger (/var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/bin/danger)
NoMethodError: undefined method `split' for nil:NilClass
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/danger-3.0.1/lib/danger/scm_source/git_repo.rb:26:in `origins'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/danger-3.0.1/lib/danger/request_source/request_source.rb:23:in `validates_as_ci?'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/danger-3.0.1/lib/danger/danger_core/environment_manager.rb:26:in `block in initialize'
  /var/lib/jenkins/.rbenv/versions/2.2.0/lib/ruby/2.2.0/set.rb:283:in `each_key'
  /var/lib/jenkins/.rbenv/versions/2.2.0/lib/ruby/2.2.0/set.rb:283:in `each'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/danger-3.0.1/lib/danger/danger_core/environment_manager.rb:22:in `initialize'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/danger-3.0.1/lib/danger/danger_core/executor.rb:26:in `new'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/danger-3.0.1/lib/danger/danger_core/executor.rb:26:in `run'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/danger-3.0.1/lib/danger/commands/runner.rb:56:in `run'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/claide-1.0.0/lib/claide/command.rb:334:in `run'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/gems/danger-3.0.1/bin/danger:5:in `<top (required)>'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/bin/danger:23:in `load'
  /var/lib/jenkins/jobs/playground-danger-php-test/workspace/vendor/bundle/ruby/2.2.0/bin/danger:23:in `<top (required)>'

Workaround
Set your LANG before you call danger:
export LANG=en_US

This will run git with an english command line interface.
Note In case your system sets LC_ALL you have to overwrite that variable it instead of LANG.
Better solution?
I'm no expert in Ruby and its gem ecosystem, but is there an option you can set on the Git class to set its locale to english? That would have prevented that bug.

In theory, this command can have that environment var set before executing the git command?

Could work:
    def exec(string)
      `LANG=en_US git #{string}`.strip
    end

Aye

Is this resolved no that #485 is merged?


chore: merge plugins-ee into plugins

also remove quite some convolution around merging those at runtime.
this also enables typechecks in the formerly unchecked plugins. the most severe
(has no exported member named "xyz") are fixed right away.
the other ~2000 new type errors are put in our snapshot for now.
Testing

Trade-offs

Dependencies

Screenshots

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

v3.0.33
GitHub release

Your semantic-release bot :package::rocket: