Overridable default locale YAML

I changed the path of locale files from locale/*.yml to config/locale/*.yml(It's Rails Engine default).
Before
I18n.load_path
=> ["/Users/koshikawa/tmp/fugo/vendor/bundle/gems/activesupport-4.2.5/lib/active_support/locale/en.yml",
 "/Users/koshikawa/tmp/fugo/vendor/bundle/gems/activemodel-4.2.5/lib/active_model/locale/en.yml",
 "/Users/koshikawa/tmp/fugo/vendor/bundle/gems/activerecord-4.2.5/lib/active_record/locale/en.yml",
 "/Users/koshikawa/tmp/fugo/vendor/bundle/gems/actionview-4.2.5/lib/action_view/locale/en.yml",
 "/Users/koshikawa/app/config/locales/en.yml,
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/af.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/ca.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/de.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/en.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/es.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/fr.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/it.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/ja.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/nl.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/pl.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/pt-BR.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/ru.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/tr.yml"]

After
I18n.load_path
=> ["/Users/koshikawa/tmp/fugo/vendor/bundle/gems/activesupport-4.2.5/lib/active_support/locale/en.yml",
 "/Users/koshikawa/tmp/fugo/vendor/bundle/gems/activemodel-4.2.5/lib/active_model/locale/en.yml",
 "/Users/koshikawa/tmp/fugo/vendor/bundle/gems/activerecord-4.2.5/lib/active_record/locale/en.yml",
 "/Users/koshikawa/tmp/fugo/vendor/bundle/gems/actionview-4.2.5/lib/action_view/locale/en.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/af.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/ca.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/de.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/en.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/es.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/fr.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/it.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/ja.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/nl.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/pl.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/pt-BR.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/ru.yml",
 "/Users/koshikawa/repository/github.com/codegram/date_validator/config/locales/tr.yml",
 "/Users/koshikawa/app/config/locales/en.yml"]

This change makes us be able to override default locale setting as below.
path_to_your_app_root/config/locale/*.yml
en:
  errors:
    messages:
      not_a_date: "is not a DATE!!!"

Could you check this? @codegram


centos 7 Missing Python Libs?

I followed the steps to build for Centos.  Looks like I got all the way down to the end and got this:
-- Performing Test COMPILER_RT_HAS_WD4800_FLAG
-- Performing Test COMPILER_RT_HAS_WD4800_FLAG - Failed
-- Looking for func
-- Looking for func - found
-- Looking for fopen in c
-- Looking for fopen in c - found
-- Looking for dlopen in dl
-- Looking for dlopen in dl - found
-- Looking for shm_open in rt
-- Looking for shm_open in rt - found
-- Looking for pow in m
-- Looking for pow in m - found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Looking for __cxa_throw in stdc++
-- Looking for __cxa_throw in stdc++ - found
-- Looking for i686
-- Looking for i686 - not found
-- Looking for i386
-- Looking for i386 - not found
-- Compiler-RT supported architectures: x86_64
-- Looking for rpc/xdr.h
-- Looking for rpc/xdr.h - found
-- Looking for tirpc/rpc/xdr.h
-- Looking for tirpc/rpc/xdr.h - not found
-- Performing Test COMPILER_RT_HAS_STD_C11_FLAG
-- Performing Test COMPILER_RT_HAS_STD_C11_FLAG - Success
-- Performing Test COMPILER_RT_HAS_VISIBILITY_HIDDEN_FLAG
-- Performing Test COMPILER_RT_HAS_VISIBILITY_HIDDEN_FLAG - Success
-- Performing Test COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG
-- Performing Test COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG - Success
-- Performing Test COMPILER_RT_HAS_FREESTANDING_FLAG
-- Performing Test COMPILER_RT_HAS_FREESTANDING_FLAG - Success
-- Performing Test COMPILER_RT_HAS_XRAY_COMPILER_FLAG
-- Performing Test COMPILER_RT_HAS_XRAY_COMPILER_FLAG - Failed
-- Performing Test COMPILER_RT_HAS_ATOMIC_KEYWORD
-- Performing Test COMPILER_RT_HAS_ATOMIC_KEYWORD - Success
-- Builtin supported architectures: x86_64
-- Performing Test COMPILER_RT_TARGET_HAS_ATOMICS
-- Performing Test COMPILER_RT_TARGET_HAS_ATOMICS - Success
-- Performing Test COMPILER_RT_TARGET_HAS_FCNTL_LCK
-- Performing Test COMPILER_RT_TARGET_HAS_FCNTL_LCK - Success
-- check-xray-fdr does nothing.
-- Looking for sys/resource.h
-- Looking for sys/resource.h - found
-- Clang version: 4.0.0
-- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG
-- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed
-- LLD version: 4.0.0
CMake Error at /usr/local/mapd-deps/20170608/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS)
Call Stack (most recent call first):
/usr/local/mapd-deps/20170608/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
/usr/local/mapd-deps/20170608/share/cmake-3.7/Modules/FindPythonLibs.cmake:255 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
tools/lldb/cmake/modules/LLDBConfig.cmake:179 (find_package)
tools/lldb/CMakeLists.txt:4 (include)
-- Configuring incomplete, errors occurred!
See also "/home/vagrant/github/mapd-core/scripts/build.llvm-4.0.0/CMakeFiles/CMakeOutput.log".
See also "/home/vagrant/github/mapd-core/scripts/build.llvm-4.0.0/CMakeFiles/CMakeError.log".

@andrewseidl Any idea what's wrong here?

@hung135 Did this occur while you were trying to build the dependencies?
if you are using centos 7 you can grab the dependencies already built and ready for you.  Please see instructions here https://github.com/mapd/mapd-core#centos-7

You might need to install package python-devel. I'll update the docs once I get a chance to reproduce.
That being said, as @dwayneberry mentioned, the easiest and quickest way to get up and running is to use the prebuilt dependencies.

Thanks guys.
@dwayneberry those were the directions I followed. Manualy many times. I must be missing something.
I also made a vagrant file just so I can destroy and re-create the evironment from scratch each time.  https://github.com/hung135/vagrant_mapd_centos/blob/master/Vagrantfile.  I'll keep at it until I get it to compile.  Any other guidence would be appreciated.

You do not need to manually build the dependencies at all you can download for centos 7 a prebuild set of dependencies
from the instructions I point to above:
Next download and install the prebuilt dependencies:
curl -OJ https://internal-dependencies.mapd.com/mapd-deps/deploy.sh
sudo bash deploy.sh

These dependencies will be installed to a directory under /usr/local/mapd-deps. The deploy.sh script also installs Environment Modules in order to simplify managing the required environment variables. Log out and log back in after running the deploy.sh script in order to active Environment Modules command, module.
The mapd-deps environment module is disabled by default. To activate for your current session, run:
module load mapd-deps

To disable the mapd-deps module:
module unload mapd-deps


Why do we build compiler-rt/libcxx/libcxxabi with RelWithDebugInfo?

Why are we building them with RelWithDebugInfo instead of Release? Apart from lower optimization level, it causes dwarf sections to be linked into the final wasm with default linking flags, which IMHO is not desirable for most wasi-sdk users.

I think if you don't want debug info in your binary you probably want to either link with -Wl,--strip or run llvm-strip on the final binary.
The alternative is that we ship two copies of all the libraries, one with debug and one without, but that adds complexity we probably don't want.

It seems to me that consumers of debug flavored sysroot will tend to build their own sysroot anyway (with Debug, and other custom flags). So simply changing to Release seems to be the best thing to do here?

I don't have a strong opinion.  It does main that anyone who builds a debug binary won't be able to step into any system functions, but maybe that fine/normal/expected?

It does main that anyone who builds a debug binary won't be able to step into any system functions

Note that wasi-libc is already built sans debug info, and that's where most important system functions live.

It does main that anyone who builds a debug binary won't be able to step into any system functions

Note that wasi-libc is already built sans debug info, and that's where most important system functions live.

I see, perhaps that should be built with debug info then?   In emscripten we chose to build all libraries with debug info, and have the linker strip it when a release build is desired.   It really depends how many wasi-sdk users will end up wanting to debug system library level stuff.

Yes, the strip-at-link-time approach is reasonable. It's just that when debug info is enabled (at least via cmake RelWithDebugInfo compared to Release), the optimization level is lower and that impacts code quality for users who don't debug the sysroot.

Really?  I thought that point of RelWithDebugInfo was that it was the same as Release in terms of opt level but with debug into?  Maybe I'm wrong?

Really. See https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake#L59, by default Release is -O3 -DNDEBUG, while RelWithDebInfo is -O2 -g -DNDEBUG. And this is another place where wasi-libc build flags is inconsistent with the rest of toolchain, currently wasi-libc is built with -O2 -DNDEBUG. We should at least make it consistent with rest of the sysroot.

We should probably be consistent about shipping debug info or not for all libraries.
Being consistent about optimization levels isn't critical I think, but it should be done deliberately.   There may be some part of libc/compiler-rt/libc++ that would be best built with -O2, -O3 or -Oz.

One thing I forgot to mention in the previous discussions: shipping sysroots with debug info doesn't really allow one to debug them, because the dwarf sections do not embed the source code (even with -g3), and only refer to source absolute paths. They are not present in the wasi-sdk tarball anyway.

One thing I forgot to mention in the previous discussions: shipping sysroots with debug info doesn't really allow one to debug them, because the dwarf sections do not embed the source code (even with -g3), and only refer to source absolute paths. They are not present in the wasi-sdk tarball anyway.

Okay, so that is inconvenient, but when you're trying to make sense of a stack trace you don't absolutely need to see source files in your debugger.
(Note to self: figure out how debian could ship source suitable for debugging sometime...)


WIP feat(image-stream): Support Apple Disk Images

This adds support for flashing Apple Disk Images (.dmg)
To Do:

[x] Add tests and test images
[x] Implement ADC decompression in UDIF

Change-Type: minor

So, I have now added ADC block decompression to UDIF, added tests and test images to image-stream, and replaced archive-type with file-type under addition of mime-types. Should be ready for another round of eyeballing @jviotti  @lurch :)


Support passing DNS options

Each build will be run in a container that uses Docker's default DNS servers (Google's public DNS servers <IP_ADDRESS> and <IP_ADDRESS>). Docker supports passing a --dns option for its docker run command, however JoliCi does not currently expose this option through its options.
Handing all DNS to Google's public DNS infrastructure might leak private information and might be an issue for those concerned about privacy.
More importantly I'm currently evaluating using JoliCi as part of our CI setup. One of our project uses an integration test that performs live queries against one of our internal servers hosted on intranet.acme.com. This server is not listed in our public DNS infrastructure, and can only be resolved via our local DNS server (<IP_ADDRESS>).
Arguably this feature might be out of scope because this address can't be resolved via the hosted Travis service either.
Given that adding support for the DNS option should be fairly straight forward, I figured it would be worth posting: Relevant place would be the Executor and passing Dns in the $hostconfig.

Hello,
Thanks for opening this issue.
Unfortunately, we don't support this repository anymore.
I'm sorry, but I'll close this issue.
I hope you understand.


Safe subscriber

codemods to migrate most name changes:
codemod --accept-all -d . --extensions h,cpp 'public (yarpl::flowable::?)Subscriber' 'public \1LegacySubscriber'
codemod --accept-all -d . --extensions h,cpp 'public (flowable::?)Subscriber'        'public \1LegacySubscriber'
codemod --accept-all -d . --extensions h,cpp 'public Subscriber'                     'public LegacySubscriber'
codemod --accept-all -d . --extensions h,cpp '\bSubscriber<(.+)>::subscription'      'LegacySubscriber<\1>::subscription'
codemod --accept-all -d . --extensions h,cpp 'using (.+?)\bSubscriber;'              'using \1LegacySubscriber;'
codemod --accept-all -d . --extensions h,cpp '\bSubscriber<(.+)>::on(\w+)\('         'LegacySubscriber<\1>::on\2('
codemod --accept-all -d . --extensions h,cpp '\bSubscriber::(\w+)\('                 'LegacySubscriber::\1('

Makes Subscriber a pure interface to implement; effectively renames Subscriber -> LegacySubscriber, adds SafeSubscriber which manages its Subscription on behalf of the subclass.
LegacySubscriber exists as a drop-in for what used to be Subscriber to allow code to be incrementally changed to use SafeSubscriber. Above codemods will handle 98% of cases where Subscriber is currently used. Eventually LegacySubscriber can be deprecated and removed.
SafeSubscriber checks that a Subscriber hasn't been subscribed to multiple times (the spec is inconsistent about if this should be allowed; for now this is conservative, but the constraint can be relaxed later if need be).
New Subscriber implementations should inherit from SafeSubscriber, and implement:

onSubscribeImpl() (note that it does not take a Reference<Subscription>)
onNextImpl(T)
onCompleteImpl()
onErrorImpl(folly::exception_wrapper)

Subclass accesses the associated subscription via this->subscription().
Why make Subscriber a pure interface and remove Subscription state?

Most subclasses of Subscriber add their own Subscription member and manage it rather than calling Subscriber::subscription() to get a reference to it
Most subclasses of Subscriber don't properly call their superclass methods, and miss out on D?CHECKs and reference clearing in the parent (which may lead to missed bugs and leaks)
The ideal would be all implementations of Subscriber can inherit a set of checks guaranteed to run
SafeSubscriber can be safely (and in a non-breaking way) extended with additional callbacks such as onTerminate()
SafeSubscriber can provide a wrapping Subscription which provides stronger, weaker, more flexible threading guarantees based on what the application requires
Forcing implementation of onComplete/onError makes a missed callback or missed override obvious; you're not going to be able to instantiate a subclass unless you know you've implemented all required callbacks.
In the case where the Subscription implementation is small or you want the convenience, SafeDefaultSubscription provides default implementations of signaling method callbacks (similar to what LegacySubscriber does), but with the checks and flexibility of SafeSubscriber.

Why do we need to have two versions of Subscriber, let's have one safe version alone?
Might we do it once in everywhere fix it once and get rid of all faulty usages? Do we have lot's of users that use the Subscriber wrong way, and will it take too much effort to fix them?

@phoad
There is only one version of Subscriber. Subscriber becomes a proper interface, instead of having implementation tied to it. {Legacy,Safe,SafeDefault}Subscriber are partial implementations which simplify writing correct and non-repetative Subscribers in the application (for the Safe and SafeDefault case).
Eventually LegacySubscriber goes away. I didn't want to start migrating anything over (except in one or two places to exercise it) to SafeSubscriber yet because I'm sure we're going to iterate a bit on the design.

Let's create an issue for this. We can discuss this as an issue or in the discussion group (rsocket engineering). We can ask people to join and comment if they would like to by pointing that issue link.

@lehecka
Agreed regarding SafeDefaultSubscription; I thought it would be more useful, but it only saved implementing signal methods in one or two places in the codebase. It's otherwise a net increase in LOC.
Regarding keeping Subscriber as it is for internal use; that's basically what's already happening in this PR, it's just been renamed to LegacySubscriber. It can be renamed to InternalSubscriber or something if that's better.
If Subscriber is kept unmodified and as an abstract class (rather than a pure interface), SafeSubscriber will need to awkwardly inherit from it. If we're going for a pure reactive streams implementation, we want to get all of the implementation out of Subscription anyways; it's an interface in Reactive Streams anyways.

@dymk please don't check this in up till we have time to do a nice review of ideas around. You might start a discussion and we can focus on it in the following week.

AtomicReference and its helpers will be best broken out into a separate PR, yeah. I'll do that now that it looks like we know what we want the SafeSubscriber API to look like

needs rebasing and answers to the rest of the comments..


Revert "python: gym: 0.15.3 -> 0.15.4"

Motivation for this change
This package was prematurely updated as part of updating the package set for python3.8
0.15.4 requires python-opencv, which isn't packaged yet,
and is not trival to package

This reverts commit 8ee4062480e78f17f47c0e9893c6e16fdff35b73.

closes: #75749
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
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)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @
technically, these are all broken on master :)
8 built (2 failed), 258 copied (2260.6 MiB), 783.3 MiB DL]
error: build of '/nix/store/jpn71f3m0l5wk6zfs6sya83vh25bw64x-env.drv' failed
https://github.com/NixOS/nixpkgs/pull/75802
2 package failed to build:
python37Packages.rl-coach python38Packages.baselines

6 package were built:
python27Packages.gym python37Packages.baselines python37Packages.gym python37Packages.roboschool python38Packages.gym python38Packages.roboschool

@GrahamcOfBorg build python27Packages.gym python37Packages.baselines python37Packages.gym python37Packages.roboschool python38Packages.gym python38Packages.roboschool

failures unrelated to PR


GEODE-2709: modify backward-compatibility support to work better with geode

Removed the "product name" from toDataPre/fromDataPre methods and from
sanctionedDataSerializable.txt files.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[x] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[x] Is your initial contribution a single, squashed commit?

[x] Does gradlew build run cleanly?

[n/a] Have you written or updated unit tests to verify your changes?

[n/a] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

I think Dan has a good point.  It is a bit confusing to have the old GemFire numbers and new Geode numbers without "GFE" and "GEODE" in the method names.  I think I'm going to yank this PR.  I've created a different ticket to improve our help for developers in catching naming mistakes.


Addresses Issue 8

What does this PR do?

added check for rhel-7-fast-datapath-rpms repo in OCP 3.5

How can it be tested?
No usage change. The script is still launched as before, it just adds an additional repo to check for

@etsauer this should close https://github.com/redhat-cop/openshift-toolkit/issues/8


chronyd doesn't own state directory.

Describe the bug
chronyd does not own it's state directory and regularly produces the following error:
Could not open temporary driftfile /var/lib/chrony/chrony.drift.tmp for writing

To Reproduce
services.chrony.enable = true;

Expected behavior
chronyd can write the files it needs.
Additional context
This appears to be because it uses the systemd StateDirectory option which sets the owner to the User and Group of the unit. However chronyd runs as root before changing user itself. This results in chronyd not being able to access the directory.
If possible chronyd could be started as the chrony user or we can rely on tmpfiles to create the directory and remove the StateDirectory option from the service config.
Notify maintainers

Maintainer: @thoughtpolice
Author: @flokli https://github.com/NixOS/nixpkgs/commit/f25a301a0a98a96b54b1a221c2dd410a3b32c4f1

I created https://github.com/NixOS/nixpkgs/pull/97592 with the simple solution of just not changing the owner to root.


Difficulty Compiling

Might just be a skill issue but when I compile with gradlew build the mod causes a crash inside my world.  The version on curseforge works fine but when I try to compile it myself, upon opening any inventory in the world it crashes with the following error:
"The game crashed whilst rendering screen
Error: java.lang.ClassCastException: class net.minecraft.world.level.block.RotatedPillarBlock cannot be cast to class dev.shadowsoffire.apotheosis.ench.api.IEnchantingBlock (net.minecraft.world.level.block.RotatedPillarBlock is in module<EMAIL_ADDRESS>of loader 'TRANSFORMER' @25131637; dev.shadowsoffire.apotheosis.ench.api.IEnchantingBlock is in module<EMAIL_ADDRESS>of loader 'TRANSFORMER' @25131637)
The manually compiled file size is a few hundred kb smaller so it is definitely different.  Any suggestions on how to build it successfully?
Thanks for all your work on this mod, it really is one of the best ones out there.

The last commit (after the release) was a PNG optimization pass, so I expect newly-compiled jars to be smaller than the prior 7.4.0 release.  For me, a fresh jar (with a minimal local change) is 2,595 KB.
You shouldn't need to perform any actions other than gradlew build to create the mod.  The crash you're receiving (though, there might be a different crash, since you have not provided the full crash log) indicates that the BlockMixin has failed to apply, which would only occur if the apotheosis.mixins.json file is absent from the built jar.
You should first provide the full debug.log file from your crashing production launch, and we can work from there.

Apologies, I was almost certain it was an issue on my end building.  Here is the crash log. Didn't realize how big these things are:
https://file.io/k41cRsKtZTTo
I'm playing on 1.20.1 with quark along with a ton of other mods.  Just working on balancing right now.

5a79de2646cc9b76927fe965598ab49c89b770f0


Add favicon

Add a favicon.ico to the UI to stop errors in the console.

Hey I would like to do this.

Sounds good. You'll need to create a fork and submit a pull request.
Here's a summary of our contribution guidelines: https://github.com/gchq/Gaffer/blob/master/README.md#contributing

I think the REST API has a favicon, so you could probably just steal that one

Hey, if this still hasn't been done yet, I think I can quite quickly tackle this

Sure you can do it.
Sorry for delay from my side.
On Wed 13 Feb, 2019, 9:05 PM c015dariu<EMAIL_ADDRESS>wrote:

Hey, if this still hasn't been done yet, I think I can quite quickly
tackle this
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/gchq/gaffer-tools/issues/626#issuecomment-463245039,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX_5XjX1a_6VpoD97sxmzphArlbpRk0xks5vNDCwgaJpZM4X6ZZa
.

Merged into develop


NotebookRenderers extension

Add image for marketplace
Update Readme (sample output of plotly/vega)

Do we need to mention Jupyter or Python extension

Do we need telemetry in this extension?

Currently do not see the need for this.

Closing until we decide we ARE shipping the renderer extension.


build: Simplify operator bundle build in Konflux

Description
Per title.
See also commit descriptions.
Note: after https://github.com/stackrox/stackrox/pull/11187 we should not even need to run make tag in a different directory (-C operator) because .x in tags will be replaced with .0.
User-facing documentation

[x] CHANGELOG is updated OR update is not needed
[x] documentation PR is created and is linked above OR is not needed

Testing and quality

[x] the change is production ready: the change is GA or otherwise the functionality is gated by a feature flag
[ ] CI results are inspected

Automated testing
No change to automated tests.
How I validated my change

[x] Checked image tag of the resulting bundle and compared to some built from master.

Since this did not touch anything but .tekton and Konflux builds are successful, I'm not going to wait for the OSCI tests and will merge this already.


[EdgeTPU] Update Toolchain run notification and log

Modify notiTitle in JobConfig.ts from 'Running onecc...' to 'Running tools...'
Use active toolchain name in notification and log of ToolchainProvider _run method
Add notiTitle in ToolchainEnv run method to provide notification differently for each toolchain
ONE-vscode-DCO-1.0-Signed-off-by: profornnan<EMAIL_ADDRESS>

LGTM 👍


Add missing i18n to various strings

For cherry-picking: In editor/animation_track_editor.cpp, some cases (track types) don't exist in 3.x.

Thanks!


Fix broken tutorial links in docs index page body

http://dropbox.github.io/dropbox-sdk-js/index.html
Tutorial links on docs index page are broken. They are pointing at markdown files rather than the html files in the gh-pages branch.
I've ran the publish-docs script and it appears to have fixed the issue.

Thanks! It looks like we missed this in #233 / #238 / #239. I'll ask the team to review and merge this.

Thanks!


Switch to Vite

I took a quick peek at the package.json for the web app and noticed that you have a lot of dev dependencies for the dev mode and prod builds. I quickly cloned the repo and started experimenting with replacing webpack and react-scripts with just one tool: Vite. It took me just a moment and I had the app up-and-running with just 2 dependencies, replacing these:

react-scripts
@babel/plugin-transform-runtime
@babel/core
@babel/preset-typescript
babel-preset-react
copy-webpack-plugin
css-loader
css-minimizer-webpack-plugin
eslint-webpack-plugin
html-loader
html-webpack-plugin
mini-css-extract-plugin
postcss-loader
raw-loader
webpack
webpack-bundle-analyzer
webpack-cli
webpack-dev-server
webpack-merge

That's just the first benefit, Vite would simplify the project's setup, it has multiple built-in loaders to handle for example CSS and other file types, it has HMR support, it works out of the box with TS and of course it's super fast.
My question is whether you would accept my PR that would replace webpack/react-scripts with Vite. I could have a draft tomorrow for you to take a look and ask any questions.

Hi, that sounds good, prepare please PR and I review it


LibXML: xmlVersion is always 1.1

XML parser always sets xmlVersion to the same value https://github.com/LadybirdBrowser/ladybird/blob/2534e7aeff54281f6ceb1a87cfa4dd1236711ed8/Userland/Libraries/LibXML/Parser/Parser.cpp#L335-L362
As we do not support xmlVersion property, I didn't find a way to test this within js, but the current code is kind of misleading and it's easy to suppose Version::Version10 is set when required, whereas it is always overridden with Version::Version11

Version will be set to 1.1 but we'll parse in compatibility mode, I don't see why this is a problem when that value is not exposed anywhere?

(and that property you mentioned would always return 1.0 anyway)


Appstudio update test-custom-default-branch-xhcg

Pipelines as Code configuration proposal

Pipelines as Code CI is skipping this commit.User rhtap-qe-bots is not allowed to run CI on this repo.


Selecting embargo more than 4 years in the future gives bad error message [OSF-6106]

Purpose
Produce correct error message for selecting an embargo date more than four years in the future
Issue:
https://openscience.atlassian.net/browse/OSF-6106
Code
Separated the conditions of validation for selecting an embargo date, and added the approprite error message for failing to choose a date less than four years in the future:
    {
    validator: function() {
        var endEmbargoDateTimestamp = self.embargoEndDate().getTime();
        return (endEmbargoDateTimestamp < FOUR_YEARS_FROM_TODAY_TIMESTAMP);
    },
    message: 'Embargo end date must be less than four years in the future.',
}

Weird, thought this was already fixed in: https://github.com/CenterForOpenScience/osf.io/pull/5517/commits/7c48db51161a67daba67b2a8cd512818494abd24

Sure enough, this seems to have already been fixed.


Websocket Server over TLS (IDFGH-3822)

Hi, every new IOT software we write is hosted over HTTPS (client application like IONIC that connects to the ESP32).  This got the effect that a simple websocket server is not allowed anymore. (An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.)
I need to find a solution to connect from a web page to the ESP32 to transfer realtime data.  I'm currently doing an simple web socket server, but that doesn't work anymore :-(
The simplest solution would be to use a Secure WebSocket Server on the ESP32.  But I can't find any implementation that does that within IDF.  Many Client WSS samples on the web, but not any complete WSS Server.  Why is that ?  I've looked at the current WS I'm using.. But it's using netconn and going to mbedTLS looks complicated !
I'm trying to stream about 10kBytes / sec.
Thanks for the help !

Thanks for raising this feature request.

Hi @Francois-Belanger
You can setup a WebSocket server on top of a esp_https_server component adding corresponding ws handlers and setting is_websocket = true, so combining these two below example in one:

https://github.com/espressif/esp-idf/tree/master/examples/protocols/https_server
https://github.com/espressif/esp-idf/tree/master/examples/protocols/http_server/ws_echo_server

Here is an example of a wss-echo-server main file. To test it quickly you can just

copy-paste this to the current https_server example
update the certificate from the example

#include <esp_event.h>
#include <esp_log.h>
#include <esp_system.h>
#include <nvs_flash.h>
#include <sys/param.h>
#include "esp_netif.h"
#include "esp_eth.h"
#include "protocol_examples_common.h"

#include <esp_https_server.h>

static const char *TAG = "wss_echo_server";

static esp_err_t echo_handler(httpd_req_t *req)
{
    uint8_t buf[128] = { 0 };
    httpd_ws_frame_t ws_pkt;
    memset(&ws_pkt, 0, sizeof(httpd_ws_frame_t));
    ws_pkt.payload = buf;
    ws_pkt.type = HTTPD_WS_TYPE_TEXT;
    esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt, 128);
    if (ret != ESP_OK) {
        ESP_LOGE(TAG, "httpd_ws_recv_frame failed with %d", ret);
        return ret;
    }
    ESP_LOGI(TAG, "Received packet with message: %s", ws_pkt.payload);
    ret = httpd_ws_send_frame(req, &ws_pkt);
    if (ret != ESP_OK) {
        ESP_LOGE(TAG, "httpd_ws_send_frame failed with %d", ret);
    }
    return ret;
}

static const httpd_uri_t ws = {
        .uri        = "/ws",
        .method     = HTTP_GET,
        .handler    = echo_handler,
        .user_ctx   = NULL,
        .is_websocket = true
};

static httpd_handle_t start_wss_echo_server(void)
{
    httpd_handle_t server = NULL;

    // Start the httpd server
    ESP_LOGI(TAG, "Starting server");

    httpd_ssl_config_t conf = HTTPD_SSL_CONFIG_DEFAULT();

    extern const unsigned char cacert_pem_start[] asm("_binary_cacert_pem_start");
    extern const unsigned char cacert_pem_end[]   asm("_binary_cacert_pem_end");
    conf.cacert_pem = cacert_pem_start;
    conf.cacert_len = cacert_pem_end - cacert_pem_start;

    extern const unsigned char prvtkey_pem_start[] asm("_binary_prvtkey_pem_start");
    extern const unsigned char prvtkey_pem_end[]   asm("_binary_prvtkey_pem_end");
    conf.prvtkey_pem = prvtkey_pem_start;
    conf.prvtkey_len = prvtkey_pem_end - prvtkey_pem_start;

    esp_err_t ret = httpd_ssl_start(&server, &conf);
    if (ESP_OK != ret) {
        ESP_LOGI(TAG, "Error starting server!");
        return NULL;
    }

    // Set URI handlers
    ESP_LOGI(TAG, "Registering URI handlers");
    httpd_register_uri_handler(server, &ws);

    return server;
}

static void stop_wss_echo_server(httpd_handle_t server)
{
    // Stop the httpd server
    httpd_ssl_stop(server);
}

static void disconnect_handler(void* arg, esp_event_base_t event_base,
                               int32_t event_id, void* event_data)
{
    httpd_handle_t* server = (httpd_handle_t*) arg;
    if (*server) {
        stop_wss_echo_server(*server);
        *server = NULL;
    }
}

static void connect_handler(void* arg, esp_event_base_t event_base,
                            int32_t event_id, void* event_data)
{
    httpd_handle_t* server = (httpd_handle_t*) arg;
    if (*server == NULL) {
        *server = start_wss_echo_server();
    }
}

void app_main(void)
{
    static httpd_handle_t server = NULL;

    ESP_ERROR_CHECK(nvs_flash_init());
    ESP_ERROR_CHECK(esp_netif_init());
    ESP_ERROR_CHECK(esp_event_loop_create_default());

    /* Register event handlers to start server when Wi-Fi or Ethernet is connected,
     * and stop server when disconnection happens.
     */

#ifdef CONFIG_EXAMPLE_CONNECT_WIFI
    ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT, IP_EVENT_STA_GOT_IP, &connect_handler, &server));
    ESP_ERROR_CHECK(esp_event_handler_register(WIFI_EVENT, WIFI_EVENT_STA_DISCONNECTED, &disconnect_handler, &server));
#endif // CONFIG_EXAMPLE_CONNECT_WIFI
#ifdef CONFIG_EXAMPLE_CONNECT_ETHERNET
    ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT, IP_EVENT_ETH_GOT_IP, &connect_handler, &server));
    ESP_ERROR_CHECK(esp_event_handler_register(ETH_EVENT, ETHERNET_EVENT_DISCONNECTED, &disconnect_handler, &server));
#endif // CONFIG_EXAMPLE_CONNECT_ETHERNET

    /* This helper function configures Wi-Fi or Ethernet, as selected in menuconfig.
     * Read "Establishing Wi-Fi or Ethernet Connection" section in
     * examples/protocols/README.md for more information about this function.
     */
    ESP_ERROR_CHECK(example_connect());
}

Hi @david-cermak this is great and sure looks simple.  Sadly I had to change direction for lack of options, but I will surely use it later.  Can you please add this to the examples ?  I'm sure it will be very useful for the community :-)
Thanks again !
Francois

Hi @david-cermak,
I am trying using your suggestion above.

Chrome Javascript:
When i trying to connect from chrome browser, the esp32 log below appear, and the chrome message(undefined error).
I (62861) esp_https_server: performing session handshake
E (63731) esp-tls-mbedtls: mbedtls_ssl_handshake returned -30592
E (63731) esp_https_server: esp_tls_create_server_session failed
W (63771) httpd: httpd_accept_conn: session creation failed
W (63777) httpd: httpd_server: error accepting new connection
If i register a new uri in addition to the websocket uri, and first access this uri, ie: https://<IP_ADDRESS>/config
the same messages appear, but, i accept the chrome security exception, and ends up connecting(message: Hello Secure World!).
After that, i can connect to websocket uri, ie: https://<IP_ADDRESS>/
if i clean the chrome history(cache), the same problem appear again.
`static const httpd_uri_t get_access_point_page =
{
.uri       = "/config",
.method    = HTTP_GET,
.handler   = get_access_point_page_handler,
.user_ctx  = NULL,
.is_websocket = false
};
httpd_register_uri_handler(server, &get_access_point_page);
static esp_err_t get_access_point_page_handler(httpd_req_t *req)
{
httpd_resp_set_type(req, "text/html");
httpd_resp_send(req, "Hello Secure World!", HTTPD_RESP_USE_STRLEN);
return ESP_OK;

}
`

Android studio app using okhttp3 secure websocket(wss):
Erro message:  java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
If i try to connect to "wss://echo.websocket.org", from app, works ok.
Note: Android studio app using okhttp3 websocket(ws), works ok before i am using wss.

@baldhead69 Have you checked this note about using self signed certificates? What kind of CA did you use with your example?
Please note that the wss://echo.websocket.org uses well know Let's encrypt certificates.

Hi @david-cermak ,
I read "this note".
"What kind of CA did you use with your example?"
A: I only generated a new certificate using:
openssl req -newkey rsa:2048 -nodes -keyout prvtkey.pem -x509 -days 3650 -out cacert.pem -subj "/CN=ESP32 HTTPS server example"
I read about "Let's encrypt certificates".
I am new with that, so i'm really lost.
From what I understand, I need to have a domain of my own, register this domain in "yaler" for example, only then i could generate a key on the "Let's encrypt" site.
Thank's.

Hi @david-cermak,
Now i have the problem in the image in annex.
I think that is a okhttp3 lib error.

Hi @david-cermak ,
Wouldn't you be able to generate a local certificate ?
Perhaps espressif would be interested in making a script to help generate this certificate for esp32 https server using this link:
https://letsencrypt.org/pt-br/docs/certificates-for-localhost/
I think that it need has a hostname, it would not be possible to generate the certificate by the ip, at least i think that the okhttp3 lib does not accept.
I already tried to use mdns with esp32 on my local network and I had problems.

Hi @david-cermak ,
Some suggestion on hostname not verified error ?
Thank's.

Hi @david-cermak ,
I solved the problem partially in the link: "https://github.com/square/okhttp/issues/6276"


Training Time and Cost

Do you have any benchmarks on how long it would take to train various ResNets and the cost would be?
I'm looking for info comparable to this: https://dawn.cs.stanford.edu/benchmark/
E.g. Time taken to train an image classification model to a top-5 validation accuracy of 93% or greater on ImageNet.
Thank you!

Hi @wmpauli Thank you for reaching out Since this channel is for driving improvements towards MS Docs, could you provide the URL of the specific documentation that your feedback is applicable to? That way, we are able to make sure your feedback is addressed by the right team.

Hi @DixitArora-MSFT , thanks for your response. I was referring to this page.


Enable batch release part 3

Enable batch release for the following service directories:

attestation - azure-resourcemanager-attestation defaulted to false since the library hasn't released since April of 2021
communication - all pipelines
containerregistry
eventhubs
monitor
schemaregistry
tables

API change check
API changes are not detected in this pull request.


TilingSprite BaseTexture resolution

I ran into a problem if the base texture resolution is not 1 and the renderer is not WebGL. The resolution auf the base texture is nowhere considered. This is how i solved it. The solution is probably not the best...

Actually that looks OK


Add three-finger tap to toggle between normal, pencil, and autocorrect input modes

Toggle has been added but there's no visual affordance to let the user know the mode has changed


Use react-query for data fetching

Fixes #1472

Background

TODO

[x] useQuery for useFeatureSelection
[ ] useQuery for data processing tasks?
[x] multi-level useDataTypeMulti (for #1399 / #1561)?

Changes

Use react-query for data fetching
Remove the addUrl callback from all data hook functions; return a list of { url, name } objects as part of the data fetching

Switch from [url, name] to { url, name } everywhere
(The alternative was to call addUrl in useQuery.onSuccess which also works but that parameter is deprecated)

Checklist

[ ] Ensure PR works with all demos on the dev.vitessce.io homepage
[ ] Open (draft) PR's into vitessce-python and vitessce-r if this is a release PR
[ ] Documentation added or updated

Is the to-do here a cleanup checklist for after this is merged?  Or before?

Sorry, meant to clean that up, I think the final remaining TODO item should be covered in a follow-up issue/PR


HDDS-11059. Reduce OM DEBUG messages

What changes were proposed in this pull request?
When DEBUG logging is enabled for OM, there are many un-useful messages as mentioned in the JIRA description. These messages are now in TRACE log level.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-11059
How was this patch tested?
Tested the patch on docker.
Before changing the log level:
2024-06-27 07:56:36 2024-06-27 02:26:36 INFO  OzoneManager:1228 - Creating RPC Server
2024-06-27 07:56:36 2024-06-27 02:26:36 DEBUG RocksDatabase:684 - get: size=-1, remaining=4096
2024-06-27 07:56:36 2024-06-27 02:26:36 INFO  RaftServer$Division:256 - om1: new RaftServerImpl for group-C5BA1605619E:[om1|om:9872] with OzoneManagerStateMachine:uninitialized
2024-06-27 07:56:36 2024-06-27 02:26:36 DEBUG LifeCycle:154 - om1: NEW

After changing the log level:
2024-06-27 08:00:29 2024-06-27 02:30:29 INFO  OzoneManager:1228 - Creating RPC Server
2024-06-27 08:00:29 2024-06-27 02:30:29 INFO  RaftServer$Division:256 - om1: new RaftServerImpl for group-C5BA1605619E:[om1|om:9872] with OzoneManagerStateMachine:uninitialized
2024-06-27 08:00:29 2024-06-27 02:30:29 DEBUG LifeCycle:154 - om1: NEW

When TRACE log level is enabled, we can see this line in the output:
2024-06-27 07:52:42 2024-06-27 02:22:42 INFO  OzoneManager:1228 - Creating RPC Server
2024-06-27 07:52:42 2024-06-27 02:22:42 TRACE SecurityUtil:577 - Name lookup for om took 0 ms.
2024-06-27 07:52:42 2024-06-27 02:22:42 TRACE RocksDatabase:684 - get: size=-1, remaining=4096
2024-06-27 07:52:42 2024-06-27 02:22:42 INFO  RaftServer$Division:256 - om1: new RaftServerImpl for group-C5BA1605619E:[om1|om:9872] with OzoneManagerStateMachine:uninitialized
2024-06-27 07:52:42 2024-06-27 02:22:42 DEBUG LifeCycle:154 - om1: NEW

Thank you @sarvekshayr for the patch. Could you please share the output log messages from before vs after implementing the change?

I've shared the output screenshots now.

I've shared the output screenshots now.

Please share logs text as text, not screenshots.  Plain text makes it easier to

read (especially for those with visual impairments)
reference (e.g. quote)
search

It also reduces size to be stored by GitHub.
(Not relevant for now, but sharing code can be even better by using permalink URLs.)

Please share logs text as text, not screenshots.

Updated and shared the logs as text. Thank you for pointing this out @adoroszlai

Thank you @sarvekshayr for the patch, thank you @adoroszlai for the review.

@sarvekshayr , thanks a lot for working on this!
@tanvipenumudy , thanks for reviewing and merging this!


publish a Docker container

Dean pointed out it'd be a lot easier to play with this if we had a docker container that included the right/recent version of Node and the dependencies pre-installed.

@dtribble can you elaborate on the use case at all here? I got started (#14) but then I couldn't tell how close I was to finished.

I think what we could really use is a container that just offers the vat and client executables, ready to run. I guess the use case is for someone who doesn't know how Node.js works and doesn't want to run npm install -g playground-vat (assuming we'd published it to npm correctly), but wants to experiment with vat create and vat run and client run (although TBH I don't remember if client run actually works right now).
I don't know Docker very well.. #14 might do just that, although I see mention of examples/quorum so maybe it's doing slightly too much? Not sure.

I published the result on docker hub; it's set up to automatically rebuild on pushes to my fork:
https://cloud.docker.com/u/dckc/repository/docker/dckc/playground-vat
To finish this issue, you guys should set up an account and do likewise. I'm happy to help if you get stuck or whatever.


Fix R6031 error with python3.4

In WinUser.h:
#if (_WIN32_WINNT >= 0x0400)
#define WH_KEYBOARD_LL     13
#define WH_MOUSE_LL        14
#endif // (_WIN32_WINNT >= 0x0400)

#if(WINVER >= 0x0400)
#if (_WIN32_WINNT >= 0x0400)
#define WH_MAX             14
#else
#define WH_MAX             12
#endif // (_WIN32_WINNT >= 0x0400)
#else
#define WH_MAX             11
#endif

So size of callback_funcs  and hHooks should be bigger than WH_MAX

I download the whole folder and I do not understand how to install with cmd. I do not have too much experience with it. Could you please explain how to do it?


mount: Handle storage options as flags and options combination

mount: Handle storage options as flags and options combination

The Options field inside Storage structure is used to pass both
flags and data to the mount() system call. The semantic behind
this actually checks if an option from the list matches with a
flag from a specific list of flags. In case it does not match
any flag, the option is considered as a real option that should
be used as data parameter.

Fixes #26

Signed-off-by: Sebastien Boeuf<EMAIL_ADDRESS>

Fixes #26
cc @sameo @bergwolf @gnawux @laijs @WeiZhang555

PR updated.

LGTM now

@sameo @bergwolf @WeiZhang555 please take a look and merge if you're fine with this.

@laijs PR updated.

LGTM

lgtm


Renamed procedure in use statment not recognized

When renaming an external/module procedure name in the local namespace via "use", it is not recognized by Intellisense. In issue #109, this problem was already addressed for the case of variable names.
Here is a MWE of a potentially tricky case:
module test_module
   implicit none

   contains

   function func_1(x) result(out)
      integer              :: out
      integer, intent(in)  :: x
      out = x + 1
   end function
end module test_module

program test
   use test_module, func_1_ref => func_1
   implicit none

   logical  :: func_1
   func_1 = .true.

   write(*, *) func_1
   write(*, *) func_1_ref(3)
end program test

In the main program's scope, func_1 is a valid variable name that is correctly recognized as logical by Intellisense. However, in the line containing the use statement, func_1 is incorrectly identified as a logical variable as well. As stated above, func_1_ref is not recognized.

Sorry about the delay and thanks for the report. In the current version 1.10.3 I am not able to fully reproduce your bug. In particular, func_1_ref seems to be recognized as expected. I do see the issue with func_1 on the USE line. Can you verify you still see the buggy behavior?

Sorry, I was absent for a few days myself.
That is odd. I copied the MWE I posted above into a fresh editor window and still see the same behavior. All extension are up-to-date and fortls shows version 1.10.3 on python3.7.3. The only non-default option I have set is variableHover but that doesn't change the outcome.
My VSCode version info:
Version: 1.41.1
Commit: 26076a4de974ead31f97692a0d32f90d735645c0
Date: 2019-12-18T15:04:31.999Z
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 4.15.0-65-generic


sdk: python: Migrate to httpx

Fixes #3693
Signed-off-by: Helder Correia

This migration and the latest changes to provisioning made it clear that the current architecture isn't the best one.

The point of the current architecture was to allow for multiple ways to connect to the engine that I was seeing at the time: http, unix socket, dial stdio, bin;
Current dispatch based on DAGGER_HOST scheme is essentially only used for provisioning, so rename the connectors package to provision;
Move HTTPConnector specific code to Connector and move connectors.base to connection.
With only httpx for sync/async, we can mount httpx transports for unix sockets for example, and not do the dispatch ourselves.

Based on the last 3.4.0 release, there will be at least another rc before we can expect 3.5.0 GA. Do you have a rough timeline in mind @leszekhanusz? e.g. 4 weeks for the beta stage, then 4 more weeks for the rc stage before GA can be released.

The reason gql is currently in a pre-release is because the latest version uses graphql-core v3.3.0a2 which is also in a pre-release.
graphql-core itself is dependent on the upstream javascript reference graphql-js v17.0.0a2
So there is no timeline for a stable version since we are dependent on upstream packages.
httpx support in gql was added very recently in the v3.5.0b0 version and even tough it's a pre-release I believe it should work if you request gql>=3.5.0b0

Dependency resolution would fail for strawberry-graphql, I'll vendor for now.


workers.api.error.too_many_crons: Crons have to be deleted manually before republishing

🐛 Bug report
Describe the bug
I have 2 cron jobs configured.
When using wrangler publish i get workers.api.error.too_many_crons [API code: 10072]
Limit is currently 3 per script.
It seems like they are added instead of overwritten.
Therefore I have to manually remove them before publishing.
Also happens in wrangler-action (I am about to implement an automatic deletion before publishing in my action script)
Reproduce the bug

Create 2 cron jobs.
Publish
Publish again
-> Error

Expected behavior
Jobs are overwritten instead of added, automatically deleted then added or not affected at all, if unchanged.
However, publishing seems to work
wrangler-action fails though, since it is marked as an error instead of a warning

This breaks my workflows as well. Having a wrangler command to clear up the cronjobs would allow to have a workaround, where all cronjobs are emptied and then recreated via publish.

wrangler 2 follows this behaviour, so I'm going to close this issue.


Inconsistence with >= <=

This is valid:
1 >= 2

this is not:
1 => 2

this is valid:
1 <= 2

this is not:
1 =< 2

This is inconsistent.

Care to elaborate? How's operator modifier being allowed inconsistent with disallowing modifier operator?

well, I expected that the same order of the operator will result in similar behavior
as in
1 >= 2
one is bigger or equal to two.
1 =< 2
one is smaller to equal to two.
it looks the same.
but, because this "rocket" shape => is for hashes and other operators it is not allowed to be used in the mathematical expressions.
So i guessed this one <= wont be used as well (or at least be an alias to =< )
Is this just my OCD ?

Both => and =< look weird to me, probably because almost no language uses that (I know Erlang has some that always confuse me).
Chances of adding => and =< as comparison operators are %0, sorry. There's nothing to win here except having to learn new syntax.

I  don't follow your reasoning
              1  > =  2
              ^       ^
              |  ^ ^  |
  +-----------+  | |  +-------------+
  |              | |                |
  +          +---+ +----+           +
[one] is [bigger] or [equal] than [two]

              1  < =  2
              ^       ^
              |  ^ ^  |
  +-----------+  | |  +-------------+
  |              | |                |
  +          +---+ +----+           +
[one] is [lower] or [equal] than [two]

@jhass you are right, when saying it it sounds better, when looking at it it looks weird...
It's a nonsense discussion, I also saw that Ruby does the same.
I'll close the issue, ignore it ;)


[SYSTEMML-1256] Add download link for previous releases

Added note with link to http://archive.apache.org/dist/incubator/systemml/ at bottom of download page for convenient access to previous systemml releases.

LGTM. Thank you @gweidner!
Let me know if you'd like me to publish. I generally follow these procedures: https://gist.github.com/deroneriksson/e0d6d0634f3388f0df5e#main-systemml-website-updates---new

Thank you @deroneriksson for reviewing - your documented procedures are very helpful!  I'll merge and publish.


⚖ Register Validator:

Network Choice
nemeton-1
Who are you?
We represent a rapidly growing community in which we train people to set up nodes, a kind of elementary school for those who are not yet familiar with this. We promote the conscious installation of nodes (we don’t like one-line scripts), we want to teach our students to carefully delve into projects and interact with them as much as possible! We will be happy to join your project and carry it to the masses!
We also raise the nodes of many projects in the test and main networks.
gentx
{"body":{"messages":[{"@type":"/cosmos.staking.v1beta1.MsgCreateValidator","description":{"moniker":"SmartHamster","identity":"","website":"https://smarthamster.tech","security_contact":"sh.node.studio@gmail.com","details":"Smart Hamster Nodes Studio"},"commission":{"rate":"0.050000000000000000","max_rate":"0.200000000000000000","max_change_rate":"0.010000000000000000"},"min_self_delegation":"1","delegator_address":"okp41an7rh6gt0fj05609perwtej4ctq284gc956yql","validator_address":"okp4valoper1an7rh6gt0fj05609perwtej4ctq284gcsn2d77","pubkey":{"@type":"/cosmos.crypto.ed25519.PubKey","key":"Ysxlv6POIvye9AVlQ9NPrqo6kUD9bL+vJ98LvuGDbGk="},"value":{"denom":"uknow","amount":"10000000000"}}],"memo":"87fa3e5b6998765b6cd2475be98cd8fbd3c57d72@<IP_ADDRESS>:26656","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[{"public_key":{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AqCM3E0oA8WQJQivUjFO8IUeux4un3GjCi/vBYDd6ziY"},"mode_info":{"single":{"mode":"SIGN_MODE_DIRECT"}},"sequence":"0"}],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""},"tip":null},"signatures":["Pi/jh8fP9oqjcvQtYh4ZseZE1HFXIMxAYnE4TkXPU3psKhhYmBmaImbibbzunqaLKJ2y25k2Upj/gvIwZPP04Q=="]}

😉 Here is the corresponding PR: https://github.com/okp4/networks/pull/317


Print a more meaningful message when decoding an object fails.

This PR changes the error message printed when decoding any of the RPKI objects fails from whatever wondrous thing the decoder says to a generic message stating that decoding an object of a certain expected type failed.

The decoder does indeed not provide any useful information. This is a limitation of the current error handling model in both bcder and rpki-rs. It can (and should) be fixed at some point. This PR really only provides a work-around for showing missing further values (at position 2) to users as the only error reason.


feat(AlgebraicGeometry/EllipticCurve/DivisionPolynomial/Basic): add maps for division polynomials

[x] depends on: #6703
[x] depends on: #13356

Does it make sense to put this in a new file? Because the current import adds 300 new transitive imports. Or do you think that everything importing .Basic will also want access to the new results from this PR anyways?

Does it make sense to put this in a new file? Because the current import adds 300 new transitive imports. Or do you think that everything importing .Basic will also want access to the new results from this PR anyways?

Very understandable. I do think that users of \Psi and \Phi should have access to their equivalence with \psi and \phi in the coordinate ring, because that's the original motivation for having separate definitions. This only requires the definition of the coordinate ring and some basic properties, hence only requires importing AdjoinRoot and Norm. Unfortunately the file defining the coordinate ring is interlaced with the proof of the group law that imports ClassGroup, which presumably is the majority of the 300+ transitive imports. How about this: let's merge this PR, and I'll open another PR immediately that splits off the stuff on the coordinate ring into another file, and this file can just import that new file.

The central result about division polynomials is the formula for zsmul on the group of rational points in terms of division polynomials, and the group structure already require CoordinateRing, ClassGroup and Norm,  so I don't think it makes much sense to avoid them.

Yes, but ZSMul.lean or Group.lean will be a different file from Basic.lean. Maybe there are uses of division polynomials without needing the fact that the points form a group, e.g. if you just need an explicit duplication/triplication formula?
I think it's probably good to split off a file just for the coordinate ring anyway - this can include all the API for the universal elliptic curve, the evaluation and specialisation maps, and whatever else that are universal constructions.
Now that I think of it, we don't actually need the two definitions to agree until we actually compute the structure of the n-torsion. Maybe I'll leave the lemmas here for now, and the move it out eventually once I get to that.

It seems our consensus is to merge this PR first, so let's do that and worry about splitting later? If you put your proposed splitting in some branch I can check whether it's reasonable ...

In fact, I think it's pretty rare that people would want to talk about elliptic curves without knowing the rational points form a group. Do you have such examples in mind?

I tend to agree that the split can be done later, if at all

In fact, I think it's pretty rare that people would want to talk about elliptic curves without knowing the rational points form a group. Do you have such examples in mind?

Not specifically the theory of division polynomials, but my primary example would be moduli problems (e.g. the moduli stack of genus one curves, or just modular curves X/X_0/X_1), where the group law is not relevant? Obviously this is very far away and proving any useful theorems about moduli spaces would require some form of Riemann-Roch, in which case the group law is pretty much automatic, but maybe there's a nice description of the Weierstrass coefficients in terms of the moduli space.
Another argument for avoiding the import could be if the user prefers to write a different group law (e.g. the one induced by complex uniformisation), which might have properties easier to work with, but that's probably a weak argument.

Well, the modular curves seem pretty closely connected to the group structure:

You might be able to define modular curves through their own equations but as soon as you connect them to elliptic curves you'd be talking about torsion points.


Hangs after ' Enter phone number: '

Couldn't find option to enable verbose logging, so i'm writing here

Hi, thanks for reporting a bug.

Could you please share the content of your ~/.nchat/td.log ?
Did you enter your phone number with country code? I.e. if in U.S. like +16505551234 with the leading +1?
Do you have an existing Telegram account, or trying to register a new number?
Thanks,
Kris

mbp-denis:build delneg$ cat ~/.nchat/td.log
Using key: mi4JuEVsIWsytVaf
Using key: fTSfDsqB4HBeZcUF

Tried both
Existing account

Thanks. Hmm I would expect the td.log to contain something more. Do you mind trying to run nchat setup again and see if there's some more in td.log? You can alter the actual data from td.log if your phone number or other personal info is there.
To be honest you are probably the first user aside from myself. But I do use it daily without issues.

And to clarify, the phone number should be entered with country code. After which you should be prompted to enter a confirmation code sent to your phone/telegram.
I should probably add more documentation in the README regarding this.

I'm not the first, a couple of my friends are building it right now.
One is struggling with the same issue after build on OpenBSD.
I tried to enter phone in the format of +7903XXXXXXX

You should probably add much more verbose logging, as well as set logging param for tdlib to at least 14

Thanks, it's probably a good idea to increase the logging verbosity. I'm on my phone now and won't get a chance to change that until I'm at my PC tomorrow evening. Btw, which OS are you using? Nchat is mainly developed/tested on macOS 14 Mojave and Ubuntu 18.04,

As you could've guessed from my shell prompt, i'm using macOS.
The version is 10.14 mojave as well

Yep I did guess macOS, but just wanted to make sure. Thanks.

Btw did you try to re-run nchat setup and see if td.log contained any additional stuff?
The "Using key" entry should only be there once authentication has been passed and nchat is started with plain nchat I think.

Yep, i did it at least 5 times. The only log is Using key: stuff

Ok, thank you. I won't be able to do much today, but hopefully tomorrow. Will post updates here.

I've implemented support for verbose logging. You can try running the setup with verbose logging enabled like this:
nchat --verbose --setup

Also, I'm wondering regarding your phone number example (+7903XXXXXXX) - is the country code +79? If yes, you can try to omit the first 0 after the country code. Or open the Telegram app on your phone, press menu button and check the number format shown there and use the same.

No updates received the last 3 weeks, so I will proceed to close this issue. Feel free to re-open with additional log data if the issue persists.


Titanic Spaceship Project

*What is the awesome project you're thinking of?
This is a beginner machine learning project, a classification problem to be precise.
Additional context
All the problem details can be found here: https://www.kaggle.com/competitions/spaceship-titanic/overview/description

Hey @muhammadanas0716  I would like to work on this issue, can this issue be assigned to me under hactober fest?

Nope, sorry this repo is not part of Hacktoberfest.

Project Completed!
Link: https://github.com/muhammadanas0716/Machine-Learning-Projects-101/tree/main/Spaceship Titanic


We need add more information and some pictures in the repo homepage

Especially some attractive pictures to let the users know what is the porpose of this projet~

For example, although not sure the exact meaning of this picture  :-)

+1
Maybe we can add some detailed description of Developer Collaboration Network and Project Correlation Network to README. For example:

Developer Relationship Exploration

Developer Collaboration Network: Developer Collaboration Network shows the collaboration between the given developer and his associated developers. From this graph you can find other developers who are closet to a given developer.
Most Participated Repos: From this graph you can find out the most active repositories for a given developer.

Project Relationship Exploration

Project Correlation Network: From this graph you can find the projects that are related to the given project.
Active Developer Collabration Network: From this graph you can find the active developers in the given project. What's more, you can find the collaborative relationships between these developers.

@xiaoya-Esther @frank-zsy Can you help to review or think about the exact meaning or description of these graph? Thanks :)

Closed.


Render code blocks in repo description

Backtick syntax now works in repo description too. Also, I replaced the CSS for this was a new single class, making it more flexible and not dependent on a parent. Also, very slightly reduced font size from 16.8px to 16px.

I guess we can merge this now and defer the discussion about HTML rendering in repo description to later, to not expand the scope of this change.


Enemies retain spawn protection?

Enemies are retaining spawn protection after their first activation.
Here I had the base reinforcements spawn, act, and the Behemoth still has 7 evasion pips despite only moving 1 or 2 hexes.
https://bep.s-ul.eu/Hj1KLWuP.jp
RogueLogs(1).zip
RogueLogs.zip
g

I think this is a bug in the base game. I had the same problem without IRTweaks loaded.


Base structure and guidance comments created.

Base structure and guidance comments created.

 Base HTML wireframe, as a developer i need a clear division structure through the site to start building sections.

After the talk we have yesterday about component css being isolated on a file per component i came around to implementing this but have come to appreciate this should not be necessary if we use BEM as our selected style guide suggests, therefore i still think this code chunk is done, please let me know if you still think differently and we can discuss it.

Hey i need the contact info, location and the social media info from hostal las paisas.

Hey i need the contact info, location and the social media info from hostal las paisas.

this question is not pertinent to this PR, it should be done in trello.


Unification with snet-cli

SDK lacks some features which already exist in snet-cli (dynamical caching of everything (channels/service metadata/compiled protobuf), time based strategies for gas price, support of different types of identities, etc). Instead of re-implemented all these features in SDK we should isolated them in separate library and use them in SDK and in snet-cli together.
General strategy should as following: if we need some functionality in SDK and this functionality is already presented in snet-cli we should take it from snet-cli. If we don't like how it is implemented in snet-cli we re-implement it, but we also replace old functionality in snet-cli.
@vforvalerio87 @raamb do you agree with this approach?
Functionality which already present in snet-cli, but lucking in SDK

Support of different identity types. We should directly use identity.py (@vforvalerio87 if you don't like how it is implemented it should be re-implemented in such a way that snet-cli could also use it)
Mechanism for dynamical caching everything: channels/service_registration/service_metadata/compiled protobuf. SDK should also use ~/.snet by default (as I believe @ferrouswheel suggested). In such a way SDK and snet-cli will use the same cached information which is great.
General mechanism for sending on-chain transactions including time based strategies for gas price. I'm not big fun how it is implemented in snet-cli. So we could re-implement it (but in such a way that snet-cli could use it!).
Small libraries: utils_agi2cogs.py utils_agi2cogs.py utils_agi2cogs.py, some functions from utils.py
Functions for calculate call metadata from mpe_client_command.py

I just want to clarify I think the .snet directory should be per project. Just like .git. Projects will be fixed to a particular published service spec, so we don't want different projects interacting with the same cache.
This .snet directory would still be used by SDK and CLI, but wouldn't be on the home directory.
The reason for this is that if I build an application using SNet, I should be able to bundle it up and all dependencies should be inside the project directory. I don't want to have to extract compiled protobuf/grpc files from a home directory, and I especially don't want to have to filter and find only the files related to my current project (if I'm working on multiple applications).
Related issue is here: singnet/snet-cli#173 which makes it clear it should be per project.

Essentially the same as issue singnet/snet-cli#214
Choosing the right strategy will also solve for singnet/snet-cli#219 as the functionality of invoking a service using just the service-id and org-id can be provided by the SDK itself.
My preference is the second option proposed by Vitaly, which essentially has the snet-cli built around the SDK
snet-client-common
^
|
snet-client-sdk
^
|
snet-cli
Lets align on the approach and we can figure out the implementation. Eventually would like for all out client tools to be built around the SDK so that we eat our own dog food.
Thoughts @vforvalerio87 @pennachin @ferrouswheel @astroseger @arturgontijo @vsbogd @ksridharbabuus

I think final solution should be discussed among with discussing API which sdk provides to client. There should be some difference between specific and generic client implementation. Obviously client code for specific service (generated by sdk) can directly use service API. And snet-cli code should make generic calls. I think we need to describe and discuss sdk API first and then discuss how to implement snet-cli using it.
My thoughts on other items raised by @astroseger in issue description:
Items 1, 3, and 5 sounds reasonable to me.

Mechanism for dynamical caching everything

I think sdk should NOT restrict client in a way of storing caching information. Instead I would provide some generic interface which can be implemented by client to use cache storage of his choice. To simplify client writing I would also provide file storage implementation which can be in turn reused in snet-cli. I would make storage path to be a parameter of this implementation to allow client choosing file path to store cache.

Small libraries: utils_agi2cogs.py utils_agi2cogs.py utils_agi2cogs.py, some functions from utils.py

It is difficult to say right now, but sounds like a good candidate for snet-client-common package

I would make storage path to be a parameter of this implementation to allow client choosing file path to store cache.

As long as this has a sensible default (e.g. file cache in a project's .snet directory) and isn't yet another configuration parameter to think about.
Customisation should take a back seat to "Everything Just Works" with minimal cognitive overhead for a developer trying to use SNet.

Customisation should take a back seat to "Everything Just Works" with minimal cognitive overhead for a developer trying to use SNet.

Sure, just would like to emphasize that sdk should be more flexible than current snet-cli implementation.
For example I don't think that sharing cache between snet-cli and sdk is the best option, as it raises question about version compatibility for instance. As developer I would prefer having two different directories to not bother whether sdk and snet-cli versions I use are compatible. I don't insist they should be different by default, but I think we definitely need to provide such option.

2. I agree that it would be nice to rewrite snet-cli using SDK. But with current API it is "not practical".

I see your point on the practicality of doing this.

3. I still think that general strategy should be as described in the first post of this issue! We should extract existed functions and functionality from snet-cli. I can help with it, after we define API.

Sure, as you suggest lets work on pulling out common functionality into a common dependency for both the client and the SDK. 1,3,4 and 5 are clear candidates for this.
With regards to the API that the SDK will support it should

Provide the ability to abstract all channel interaction. It must expose the underlying methods to the inquisitive end user but must have logical defaults for anybody to use (like what the allow_transactions option provides)
Provide the ability to invoke grpc methods as you would normally do and where possible abstract this to allow the use case referred to by @astroseger  in  singnet/snet-cli#219

I doubt that any of this is new and pardon if this is at a very high level.

I think in the long run having the CLI built on top of the SDK is a good idea, but I also agree that's not the best short term path. We should plan for that in the medium term.
I also agree with this:

For example I don't think that sharing cache between snet-cli and sdk is the best option, as it raises question about version compatibility for instance. As developer I would prefer having two different directories to not bother whether sdk and snet-cli versions I use are compatible. I don't insist they should be different by default, but I think we definitely need to provide such option.

About the "sdk cache" issue:
I think first and foremost, the sdk should be completely stateless by default. You can't assume the user who runs it will have a reliable filesystem at his disposal (fargate cluster, AWS lambda, whatever).
That being said, I proposed having a "pluggable cache" system where you basically specify what persistence engine you want to use, which could be things that the SDK understands like "filesystem" (based on pickle in the Python iteration of the SDK, for example), or "cli" (which means, "I have e CLI installed on my system, please leverage that for caching", which is the same thing that the AWS SDKs do if you have an AWS CLI installed and configured on your system... but you can still specify whatever authentication options you prefer and override that), or provide a class with conventional methods that do serialization and deserialization (example: persistance=DatabaseStorage or something, which would be a class with by convention a "save" and "load" method that would serialize and deserialize the cache for you).
This way the developer who uses SNET CLI and has it configured could use that in his (Python) client application, while the user who runs his service on whatever distributed docker cluster could do persistency on an external database / nfs mount / dynamoDB / whatever so if he destroys / re-creates containers they can all still access and leverage the same cache for the whole cluster.

Lets get started with the refactor effort as proposed by Sergey and look to build a common dependency layer across SDK and CLI

@vsbogd @vforvalerio87  I think your slightly over complicate things about cache. I want to underline that it is rather cheap to find channels (~5 sec) and it is rather cheap to download metadata and recompile protobuf (~5 sec). We obviously shouldn't do it at each call, or even at each application start, but there is no reason to make something complicated here.... We already have implementation of dynamical caching in snet-cli and directory can be made optional if you want...

I will extract the following functionality from snet-cli

configuration (I believe SDK could share configuration file with snet-cli)
function which open new channel or do nothing if channel is already exists
function which get channel with given org_id/service_id (with dynamical caching)
function which get metadata for service + download and dynamically compile protobuf (with dynamical caching! so this function can be used at each call)
function which form grpc-metadata for a call (this can be used to make a call as current SDK does)
function which make a call as in singnet/snet-cli#219

As a first step I will simply isolate these functions inside snet-cli without putting them in separate repo. @raamb Do you agree?

@raamb @pennachin @vforvalerio87
I have impression that original intention of people who initially developed snet-cli was to use snet-cli as python SDK. It is what I see from design of the code and this issue of Lev https://github.com/singnet/snet-cli/issues/29 . I just stating a fact here, I'm not sure that they were right...

(I've removed item 3 from my previous post because it is irrelevant now... )

As a first step I will simply isolate these functions inside snet-cli without putting them in separate repo. @raamb Do you agree?

Agree with this. We can start pulling out code.

@vsbogd @vforvalerio87  I think your slightly over complicate things about cache. I want to underline that it is rather cheap to find channels (~5 sec) and it is rather cheap to download metadata and recompile protobuf (~5 sec). We obviously shouldn't do it at each call, or even at each application start, but there is no reason to make something complicated here.... We already have implementation of dynamical caching in snet-cli and directory can be made optional if you want...

The point here is that the caching strategy should be pluggable. The first version would be the one you describe of dynamically downloading to a project specific directory but the solution should be able to support other options as required. The point @vforvalerio87 made about Lambda is quite valid as we have seen interest in some Telegram groups on building out services on a serverless framework. We should be able to support any persistent store which is what the pluggable approach affords.

Same... literally everybody I spoke to asked how to set it up with Lambda, and nobody will have the snet cli installed on the server where the service runs. Having the sdk share configuration / cache with the cli is just for convenience for developers who test locally on their computer.
I agree about extracting all the code you mentioned so it can be used in both places.

@vforvalerio87 @raamb
Sorry guys, but still don't get why the existed solution with dynamical caching is not enough for your... You simply specify directory where cache is stored. It is totally fine works in Docker (cache will be rebuild on fly after restart)....

In Docker, yes. In Lambda cache would be lost at every call (same with Azure functions or Google Cloud Functions)

Cool. But I assume that filesystem is a common way to represent information in linux. Isn't it?
If there is no means to have any persisted storage in lambda. Then the only one solution is to have "static" cache. So you simply create container with all information (including cached channels and compiled protobufs) inside. If this information became outdated it will be automatically replaced in each call but there is no magical solution for it.. Isn't it?

Ah yes... Am I right that you are saying that as a persisted storage in lambda is better to use some kind of DB and not a filesystem?

As I was suggesting above and in issue #7, there is a very simple solution: the user provides a class with a pre-defined interface which takes care of serializing and deserializing the application state.
Example:

from snet import Snet
from state_cache import MySQLCache

snet = Snet(persistence_engine=MySQLCache, ...)

MySQLCache is a custom class provided by the user which must expose at least the following methods: save, load. save takes a key (example: "logs") and dict, load takes a key (example: "logs") and returns a dict.
So then in the snet_sdk when I want to cache information I'll do for example: self.persistence_engine.save("logs", logs) or self.persistence_engine.load("logs")
In __init__ for the class I'll check if the class provided by the user implements the methods I require with the signature I expect. If user specifies nothing, we use the file system.
With this we can also offer the user the possibility to avoid asking the channel state from the daemon completely, making calls faster. You store the state locally, and even if you have multiple machines using the same private key it's not an issue because they use the same storage for things like channel state, so if client1 makes a call and the state is updated, client2 can take the information from the same storage without asking the daemon all the time. It's 1 grpc call every service call instead of 2.
If something happens on the daemon side, for example the service provider makes a claim, we should have a background process (async) in the SDK that gets the logs and the channel information from the blockchain every time a new block is mined.

@vforvalerio87

With this we can also offer the user the possibility to avoid asking the channel state from the daemon completely, making calls faster. You store the state locally, and even if you have multiple machines using the same private key it's not an issue because they use the same storage for things like channel state, so if client1 makes a call and the state is updated, client2 can take the information from the same storage without asking the daemon all the time. It's 1 grpc call every service call instead of 2.

Unless you use some locking mechanism, that is how you get race conditions ;-)

client1 gets state
client2 gets state
client1 makes call
client1 stores state
client2 makes call, gets error because local state is out of date


Use loop with counter in ToResponse conversion

This converts loops like this:
for i, a := range applications {
  out[i] = *a.ToResponse()
}

to
for i := 0; i < len(applications); i++ {
  out[i] = applications[i].ToResponse()
}

for i, a := range - fields in a struct has same address and in this case we stores pointers in out[I] and when new value is assigned inside loop to a it is reflected in all elements in out.
Issue is reproducible in endpoint /api/sources/v3.1/sources when names are same  (I am not sure why only name) but this change prevents this behaviour.

cc @MikelAlejoBR

Yes, I had a fun day yesterday trying to debug what was going on, and why my tests were failing for the internal endpoint. After debugging the database queries, fixtures and following every pointer I was using, it seemed to be an issue with the for ... range loop. It was a fun thing to learn indeed...
Thanks for the PR!


typo: Double word "must"

@nschonni : Thanks for your contribution! The author, @aashishb, has been notified to review your proposed change.

Editorial fix verified.


A suggestion and need about trt_yolov4 on ros

Can this function be compiled into ros nodes, such as trt-yolov4. For robots, ros is essential and convenient.If you can integrate all the functions (googlenet/sdd/mtcnn) into the ros package at the same time, it will be perfect.

I found a similar project, but the author no longer updates yolov4 and yolov4-tiny, so stop at yolov3, do you have an idea to update yolov4 to ros package?

Thanks for the suggestion.  I'm not familiar with ROS at this moment.  I will take a look when I have a chance.
By the way, I think it shouldn't be too difficult to integrate my TensorRT YOLO code to other applications.  You only need to make sure the requirements (TensorRT library, cv2, pycuda) are installed properly.  And copy over these 3 files: "yolo/yolov4-xxx.trt",  "plugins/libyolo_layer.so", and "utils/yolo_with_plugins.py".  Then you can do inference (detect objects) using the "TrtYOLO" class.


[Bug] Error occurred when using pytest

The error message occurs when using pytest indicates that there's an issue with the array being passed to 'np.matrix'. The array is not contiguous, which means it does not occupy a single block of memory, and np.matrix requires a contiguous array.
I've send a PR to correct this.

Thanks for your comment, we will fix this problem.


FrankerFaceZ custom mod badges do not update after being changed

Describe the bug
FrankerFaceZ custom mod badges do not update after being changed
To reproduce

Set a custom mod badge on FrankerFaceZ.
Remove the current mod badge and submit a new one.
the new mod badge appears in normal twitch chat but the old mod badge continues to appear in Chatterino.
(Image 1)

Screenshots

Chatterino version
Chatterino Nightly 2.2.2 (commit b67e20d96, 27.09.2020)
Operating system
Windows Version 10.0.18363 Build 18363
Additional information
I have fixed this issue before by clearing the Chatterino roaming files and reinstalling the program, additionally the new mod badge appears when viewing the larger version of the image but is not visible in chat (Image 2)

I have fixed this issue before by clearing the Chatterino roaming files

smells like a caching issue to me

Pretty sure that refreshing FFZ emotes refreshes the mod badge too.
https://github.com/Chatterino/chatterino2/blob/1eeb09a78e11e1bab1c12b56f13dd1a74681ae15/src/providers/ffz/FfzEmotes.cpp#L192-L212
https://github.com/Chatterino/chatterino2/blob/58a698379650e9d2b0b2487ef1722ae0dd3b4aa7/src/providers/twitch/TwitchChannel.cpp#L226-L238

Pretty sure that refreshing FFZ emotes refreshes the mod badge too.

yeah i believe there is a caching issue that overwrites that

^Still an issue, I still see the old mod and vip badges even after clicking on the "reset" button under cache.

@VulpesHD the "Reset" button only resets the custom cache path back to default, doesn't actually "reset cache". You should just delete your cache folder and badges should be refreshed. But we Should really just make a fix that overrides cache element and keeps refreshed one instead.


examples: slipdev integration example

Contribution description
This PR it's to add the slipdev example, to use the UART as net device.

Testing procedure
when you are using pyterm console in your board, use:
ifconfig
> ifconfig
2022-01-13 14:30:46,017 # ifconfig
2022-01-13 14:30:46,020 # Iface  4
2022-01-13 14:30:46,024 #           Long HWaddr: AE:4F:B5:37:F8:1D:6C:EF
2022-01-13 14:30:46,027 #           MTU:65535  HL:64
2022-01-13 14:30:46,029 #           Link type: wired
2022-01-13 14:30:46,035 #           inet6 addr: fe80::ac4f:b537:f81d:6cef  scope: link  VAL
2022-01-13 14:30:46,038 #           inet6 group: ff02::1
2022-01-13 14:30:46,041 #           inet6 group: ff02::1:ff1d:6cef
2022-01-13 14:30:46,042 #
2022-01-13 14:30:46,045 #           Statistics for Layer 2
2022-01-13 14:30:46,048 #             RX packets 9  bytes 468
2022-01-13 14:30:46,052 #             TX packets 49 (Multicast: 0)  bytes 2580
2022-01-13 14:30:46,056 #             TX succeeded 0 errors 0
2022-01-13 14:30:46,058 #           Statistics for IPv6
2022-01-13 14:30:46,061 #             RX packets 9  bytes 468
2022-01-13 14:30:46,066 #             TX packets 49 (Multicast: 4)  bytes 2580
2022-01-13 14:30:46,069 #             TX succeeded 49 errors 0
2022-01-13 14:30:46,070 #

then use ping to the link local address of the another board that is connected in the UART. in this example it's used fe80::e405:df5c:7fc4:2314 to the secondary board.
ping fe80::e405:df5c:7fc4:2314

expected outpu after pingt:
2022-01-13 14:30:59,292 # 12 bytes from fe80::e405:df5c:7fc4:2314%4: icmp_seq=0 ttl=64 time=10.384 ms
2022-01-13 14:31:00,291 # 12 bytes from fe80::e405:df5c:7fc4:2314%4: icmp_seq=1 ttl=64 time=9.962 ms
2022-01-13 14:31:01,291 # 12 bytes from fe80::e405:df5c:7fc4:2314%4: icmp_seq=2 ttl=64 time=9.970 ms
2022-01-13 14:31:01,292 #
2022-01-13 14:31:01,296 # --- fe80::e405:df5c:7fc4:2314 PING statistics ---
2022-01-13 14:31:01,301 # 3 packets transmitted, 3 packets received, 0% packet loss

Issues/PRs references
fixes #85

looks good, but you not added the  EOF space of the end every file bro.

missing EOF space

missing EOF space

Let's go ahead @eduazocar

please squash before merge bro


ninja -n works poorly with gn

It can be useful to test build flag settings by changing a .gn file and then running:
ninja -n -d keeprsp -C out\Default base

The intention is that this will regenerate the .ninja files and then do a dry run that will generate the .rsp files, for manual examination, without the overhead of running those pesky build commands.
Unfortunately the "dry run" switch also applies to the generation of the .ninja files so this doesn't work. No .ninja files are updated so the .rsp files are either not generated or are generated from stale data.
The workaround is to go:
gn gen out\Default & ninja -n -d keeprsp -C out\Default base

which is clumsy and less obvious. I'm not sure if this is something that should be fixed in ninja, in gn, or in neither.
Not high priority, but it seemed worth mentioning.

In many/most cases the workaround above does not work. "gn gen" doesn't write enough files for ninja to think that the files are up to date so the "ninja -n" command still fails to run the build. And, ninja then lies about the reason for why the .ninja files are dirty.
This actually blocks some types of investigations completely by making NOP builds impossible. Changing the behavior of "-n" to always write the .ninja files would be a simple way to solve this. Adding a new switch that is like "-n" but still writes the .ninja files when needed would be a more conservative fix. Any thoughts?
This is discussed in more detail in crbug.com/535589.

Do you still need this after #1223?

@randomascii is this still reproducible with Ninja 1.10.0?

Chromium is stuck on 1.8.2 due to (IIRC) a problem with time stamps (https://github.com/ninja-build/ninja/issues/1554) but I built 1.10.0 to test it and the behavior is unchanged. That is, when I run "ninja -n" then this prevents the .ninja files from being generated, which then stops ninja from running the build step, which stops the .rsp files from being generated. I don't think issue 1223 is enough to change things - .rsp files are still needed for some link commands and understanding the build completely requires having them. When I build the 'base' target for Chromium I get 22 .rsp files.
Here is the output from the test I just ran:
c:\src\chromium3\src>C:\src\github\ninja\ninja.exe -n -d keeprsp -C out\Default base
ninja: Entering directory `out\Default'
[1 processes, 1/1 @ 2193.0/s : 0.000s ] Regenerating ninja files
c:\src\chromium3\src>C:\src\github\ninja\ninja.exe --version
1.10.0.git
c:\src\chromium3\src>dir out\default
Volume in drive C has no label.
Volume Serial Number is 18D4-8BE5
Directory of c:\src\chromium3\src\out\default
02/05/2020  10:15 AM              .
02/05/2020  10:15 AM              ..
02/04/2020  05:08 PM                54 args.gn
02/05/2020  10:15 AM               209 build.ninja
02/05/2020  10:15 AM                33 build.ninja.d
3 File(s)            296 bytes
2 Dir(s)  146,956,333,056 bytes free

I just tested this with a locally-built version of tip-of-tree ninja by modifying an args.gn file with "gn args out\ninjatest" and then running "ninja.exe -n -d explain -C out\ninjatest base". Previously I would get this output:
ninja explain: recorded mtime of build.ninja older than most recent input args.gn (666663141 vs 666671106)
[1 processes, 0/1 @ ?/s : 0.000s ] Regenerating ninja files
However with the latest ninja.exe I got the desired results which was a dry run of the build of base, rather than a dry run of regenerating the ninja files.
So, this is tentatively fixed and I hope that we can get Chromium onto the latest ninja.exe.

I think that my testing is wrong and that the behavior is unchanged. It's arguably a gn bug since there is not much point in gn gen or gn args generating the .ninja files if ninja then decides (always) that it has to regenerate them.

Could this be a similar restat issue to https://bugs.chromium.org/p/gn/issues/detail?id=136 and/or the fix from there not triggering?


build(devs-dep): upgrade deps to be compatible to jest 27

Summary

Upgrade deps to be compatible to jest 27
Test plan

Green CI
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information
N.A.

Pull Request Test Coverage Report for Build 875294771

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 93.936%

Totals

Change from base Build 873761180:
0.0%

Covered Lines:
1004

Relevant Lines:
1034

💛  - Coveralls


Restore environment variables between stages

This should fix https://github.com/uber/makisu/issues/315

Thanks for the fix!


[AQUMV] Support DISTINCT clause on origin query.

SELECT DISTINCT clause references are processed in target list, open it on origin query.
DISTINCT in aggregation and Group By DISTINCT are already supported, add cases to verify that.
create incremental materialized view mv as
select c1 as mc1, c2 as mc2, c3 as mc3, c4 as mc4
from t1 where c1 > 90;
Origin querys:
select DISTINCT c2 from t1 where c1 > 90;
select count(DISTINCT c2) from t1 where c1 > 90;
select c1, c2, c3, sum(c4) from t1 where c1 > 90
group by DISTINCT rollup(c1, c2), rollup(c1, c3);
Could be rewritten to:
select DISTINCT mc2 from mv;
select count(DISTINCT mc2) from mv;
select mc1, mc2, mc3, sum(mc4) from mv
group by DISTINCT rollup(mc1, mc2), rollup(mc1, mc3);
Authored-by: Zhang Mingli<EMAIL_ADDRESS>

fix #ISSUE_Number

Change logs
Describe your change clearly, including what problem is being solved or what feature is being added.
If it has some breaking backward or forward compatibility, please clary.
Why are the changes needed?
Describe why the changes are necessary.
Does this PR introduce any user-facing change?
If yes, please clarify the previous behavior and the change this PR proposes.
How was this patch tested?
Please detail how the changes were tested, including manual tests and any relevant unit or integration tests.
Contributor's Checklist
Here are some reminders and checklists before/when submitting your pull request, please check them:

[ ] Make sure your Pull Request has a clear title and commit message. You can take git-commit template as a reference.
[ ] Sign the Contributor License Agreement as prompted for your first-time contribution(One-time setup).
[ ] Learn the coding contribution guide, including our code conventions, workflow and more.
[ ] List your communication in the GitHub Issues or Discussions (if has or needed).
[ ] Document changes.
[ ] Add tests for the change
[ ] Pass make installcheck
[ ] Pass make -C src/test installcheck-cbdb-parallel
[ ] Feel free to request cloudberrydb/dev team for review and approval when your PR is ready🥳

icw-orca-test failed.


Genesis block broadcast and verification

Closes #595

Summary by CodeRabbit

New Feature: Introduced a more secure method for verifying the origin of the genesis block, enhancing the overall security of the system.
New Feature: Added a function to broadcast a newly created block to the closest nodes in the network, improving network efficiency.
Refactor: Improved code readability and clarity by renaming methods and comments in the SignerEngine struct.
Test: Added new functions to generate dummy blocks and accounts for testing purposes, enhancing the robustness of the testing suite.
Chore: Cleaned up unused imports and reorganized import statements across multiple files, improving code maintainability.

Looks like there's a test failure in the wallet crate @nopestack


Editor setting -> run -> Window Place -> centered is not actually centered

Godot version:

3.2.3
OS/device including version:

Windows 10
Issue description:

In Editor Settings  -> Run -> -> Window Place -> Rect
If set to centered window is not actually centred on a screen. Top left corner of the window is in the centre of a screen whereas user will expect a centre of the window to be in centre of a screen.
Steps to reproduce:
Any project
Minimal reproduction project:

Any Project

Are you using a hiDPI display (Windows scaling above 100%)? If so, this is a duplicate of https://github.com/godotengine/godot/issues/13017.

Yes this is the same issue. I have 1440p display scaled up above 100%


Don't use external input as cache keys.

Fixes #24464
@JunTaoLuo I know you don't own this doc now, but was this your intention?

@mkArtakMSFT 30 second review, please assign someone.

@adityamandaleeka 30 second review, please assign someone.

Thanks @Rick-Anderson


Update partitioning logic in ShuffledBatchRDD

This PR updates the logic in ShuffledBatchRDD to reflect recent changes in Spark's ShuffledRowRDD related to AQE support.

@abellina Could you take a look when you get a chance? This is one of the changes I had to make when working on the AQE POC.

build

I'll try and chime in this weekend on this change.

To me at high level this looks fine. It is echoing the changes made in the row-based ShuffledRowRDD. The question I have is how it works with the shuffle plugin. Given AQE, with the shuffle plugin, the expectation is that this will likely fail, so we may want to turn off the shuffle plugin in that case (it could be a separate bug). I'll test with your patch (AQE) and the shuffle plugin also.

@andygrove I haven't had time to test this yet, but I am fairly sure it will fail if the shuffle plugin is enabled, I'll try this today with some help from you likely (not sure what I can run with it enabled).
Here's what I am thinking: the writes are going to be cached and stamped as rapids blocks, and then the reads are going to ignore this all together (the getReaderForRange falls back as if it were a CPU shuffle). We do need to implement getReaderForRange for the plugin, but one way to get around this is to revert back to the legacy shuffle if AQE is on for now (https://github.com/NVIDIA/spark-rapids/blob/branch-0.2/sql-plugin/src/main/scala/org/apache/spark/sql/rapids/RapidsShuffleInternalManager.scala#L194).

@andygrove here's the issue I mentioned on the read side: https://github.com/NVIDIA/spark-rapids/issues/362. I think it's a separate issue, that should come with tests also (somehow)

build

build

build

There was a build failure with the 3.1.0 shim:
13:44:04  [ERROR] case class GpuBroadcastHashJoinExec(
13:44:04  [ERROR]            ^
13:44:04  [ERROR] /ansible-managed/jenkins-slave/slave4/workspace/spark/rapids_premerge-github/shims/spark310/src/main/scala/com/nvidia/spark/rapids/shims/spark310/GpuShuffledHashJoinExec.scala:77: class GpuShuffledHashJoinExec needs to be abstract, since:
13:44:04  it has 2 unimplemented members.
13:44:04  /** As seen from class GpuShuffledHashJoinExec, the missing signatures are as follows.
13:44:04   *  For convenience, these are usable as stub implementations.
13:44:04   */
13:44:04    // Members declared in org.apache.spark.sql.execution.CodegenSupport
13:44:04    def inputRDDs(): Seq[org.apache.spark.rdd.RDD[org.apache.spark.sql.catalyst.InternalRow]] = ???
13:44:04
13:44:04    // Members declared in org.apache.spark.sql.execution.joins.HashJoin
13:44:04    protected def prepareRelation(ctx: org.apache.spark.sql.catalyst.expressions.codegen.CodegenContext): (String, Boolean) = ???

Seems to be related to this recent Spark commit:
https://github.com/apache/spark/commit/ae82768c1396bfe626b52c4eac33241a9eb91f54

build