Some examples not working with Pico clone

Hello, everyone!
So I was planning to make a pull request adding support (a pinout description in the "common_dvi_pin_configs.h") for one of our boards - RP2040-PICO-PC (https://www.olimex.com/Products/MicroPython/RP2040-PICO-PC/).
But when tested with the provided examples from this repository it worked well with about half of them.
Here is list of the behavior:
Working fine:
dht_logging, hello_dvi, mandelbrot, terminal, tiles, tiles_parallax
Semi-working:
colour_terminal (colors seem weird), moon (picture is visible but only black and white)
Not working:
bad_apple, christmas_snowflakes, dual_display (understandable since I tested with only 1 display), mandel-full, sprite_bounce, tiles_and_sprites, vista
on all of these I see red screen and sometimes blinking lines somewhere on the screen
Vista-Palette - not working at all - it gives me a message "Input signal out of range".
So I was wondering what could cause some of the examples to work fine, some of the others partially and the rest not working at all?
I don't think it's pinout related since then none of the examples would have worked at all and thus I was thinking of making pull request but I decided to ask for this first.
RP2040-PICO-PC_rev_C.pdf

dual_display is broken, see https://github.com/Wren6991/PicoDVI/pull/41
Moon is 1bpp so b/w is okay.
Red lines indicate the RP2040 lagging behind: https://github.com/Wren6991/PicoDVI/blob/51237271437e9d1eb62c97e40171fbf6ffe01ac6/software/libdvi/dvi.c#L210
Did you run cmake using -DPICO_COPY_TO_RAM=1 as indicated in the README?


Iterating Wallet Onboarding UI/UX

What would you like to be added:
The current Mnemonic Wallet https://github.com/DeFiCh/wallet/pull/124 was merged into main so that we do not block other implementation progress for better velocity. The implementation was iterated on by the engineers as there some technical differences that require a few changes. This is the only set of screens that were largely incompatible with what was designed, while for the rest it's unlikely that we will do such a drastic change.
However, as the implementation was more geared towards technical reconciliation reasons, we need to iterate on this heavily.
Summary of changes, read #124 for more details.

Screen
Changes

Wallets Onboarding
You can only create one wallet in your app, labeling the wallet doesn't help now. We might enable multiple wallets in the future but not anytime soon.

Create Mnemonic Wallet
Zig zag layout to a more linear for better traversing of content/words.

Create Mnemonic Wallet Verification
Every single word must be verified, leaving any word unverified is not worth the risk.

Restore Mnemonic Wallet
There is no good reason why I changed this other than to reduce complexity on my end.

Lastly, we also need a new set of copy, new onboarding sequence/experience. A wallet creation onboarding screen (so that users know we are a noncustodial wallet, no one can help you if you lose your mnemonic phrase).
/triage accepted
/assign @jtlntno-cake please coordinate this, you need to create and branch off issue discussing changes and creating the narrative for change.
/priority important-soon

@fuxingloh I created this new onboarding flow on mid-fidelity with much considerations on the UX copy, page flows and the above comments.
Please see this link for better view:
https://whimsical.com/light-wallet-onboarding-iteration-HHsUYWsDDwWnLiiSfHfZN7
(no added password)
A few notes:

I maintained the same flow but tinkered heavily on how we display the critical information
I've added some modals as feedback for the users to contextually provide support.
Screens and flow are designed in mid-fidelity. Once we aligned on this iteration, I can proceed in providing any required assets/components as needed by the team.

/design in-progress

/design ready


feat(l2): use ethereum_rust dev as local L1

Motivation

We need a special setup of this client for users to play around with a local L1 devnet because regularly the execution client needs a consensus counterpart to advance blocks. For example, when initializing a local L2, we use a local L1 devnet that continuously produces blocks. Today we're using reth but want to replace it asap.
Description

Adds a dev (ethereum_rust-dev) crate with

an engine_client implementation. An EngineClient is an HTTP client that supports performing calls to the EngineAPI. It is used for "advancing the blockchain".
a block_producer module with the logic that makes the blockchain "advance".

ethereum_rust-dev is added as an optional dependency in cmd/ethereum_rust and it is only used under the dev feature flag which if set, starts the block production.
Adds a Dockerfile for running a dev client. This is useful to track the client logs, as most L2s are run by a single command, and if the client is run locally its logs would interfere with the L2 ones.

Try it yourself
docker compose -f crates/blockchain/dev/docker-compose-dev.yaml up
docker compose -f crates/blockchain/dev/docker-compose-dev.yaml down

Superseded by https://github.com/lambdaclass/lambda_ethereum_rust/pull/890


getcmdprompt() may return the previous prompt

Problem:  getcmdprompt() may return the previous prompt.
Solution: Clear the prompt text when a prompt has ended.

@zeertzjq can you check https://github.com/vim/vim/pull/15743 implementation?


[MIP-5] Support standalone dynamic regex subscription

Motivation
See #562
Modifications

Support standalone dynamic regex subscription.

Verifying this change

[x] Make sure that the change passes the CI checks.

Documentation

[x] no-need-doc

Codecov Report

Merging #567 (581a84d) into master (57ac481) will increase coverage by 0.34%.
The diff coverage is 81.57%.

@@             Coverage Diff              @@
##             master     #567      +/-   ##
============================================
+ Coverage     74.98%   75.32%   +0.34%
- Complexity      711      724      +13
============================================
  Files            97       97
  Lines          3130     3186      +56
  Branches        209      216       +7
============================================
+ Hits           2347     2400      +53
- Misses          642      643       +1
- Partials        141      143       +2

Impacted Files
Coverage Δ

...andlers/mqtt/support/event/DisableEventCenter.java
75.00% <ø> (+50.00%)
:arrow_up:

...tt/support/DefaultProtocolMethodProcessorImpl.java
76.87% <71.42%> (-1.56%)
:arrow_down:

...ulsar/handlers/mqtt/AbstractQosPublishHandler.java
94.73% <100.00%> (+0.29%)
:arrow_up:

.../streamnative/pulsar/handlers/mqtt/Connection.java
88.65% <100.00%> (+0.86%)
:arrow_up:

.../mqtt/support/event/PulsarTopicChangeListener.java
87.50% <100.00%> (+4.16%)
:arrow_up:

...e/pulsar/handlers/mqtt/utils/EventParserUtils.java
90.00% <100.00%> (+23.33%)
:arrow_up:

...e/pulsar/handlers/mqtt/utils/PulsarTopicUtils.java
77.60% <100.00%> (ø)

...ystemtopic/SystemTopicBasedSystemEventService.java
78.09% <0.00%> (+2.85%)
:arrow_up:

...ve/pulsar/handlers/mqtt/MQTTConnectionManager.java
69.04% <0.00%> (+4.76%)
:arrow_up:

...lers/mqtt/support/event/PulsarEventCenterImpl.java
92.00% <0.00%> (+8.00%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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


add auto range

Codecov Report

Merging #37 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master     #37      +/-   ##
=========================================
- Coverage    0.27%   0.27%   -0.01%
=========================================
  Files          36      36
  Lines        3586    3608      +22
=========================================
  Hits           10      10
- Misses       3576    3598      +22

Impacted Files
Coverage Δ

P13pt/drivers/yoko7651.py
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Please rewrite the functions set_voltage and set_current so that they make use of set_range (https://github.com/DamienFruleux/P13pt/blob/a2cd74e97b8b2e5fb518886237575ae769229e49/P13pt/drivers/yoko7651.py#L128) to avoid redundancy. Please catch exceptions in case an invalid range is requested.


Make anvils work

I made anvils work.

This function (combineEnchants(ItemStack item, boolean safe)) was unused and I wasn't sure what it did or if it was gonna be used in the future, so I deleted it, add it back in if you had plans.

I did have plans to use it in the future, I was going to add anvil support

This function (combineEnchants(ItemStack item, boolean safe)) was unused and I wasn't sure what it did or if it was gonna be used in the future, so I deleted it, add it back in if you had plans.

I did have plans to use it in the future, I was going to add anvil support

Thanks by the way!

No worries!

Thanks by the way!

No worries!


Outdated dependencies

Trying to install the driver fails due to the usage of deprecated dependencies.
Sample install output:
> deno cache<EMAIL_ADDRESS>Download ⠴ https://deno.land/std/hash/mod.ts
Warning Implicitly using latest version (0.161.0) for https://deno.land/std/hash/mod.ts
error: Module not found "https://deno.land/std/hash/mod.ts".
    at https://deno.land/x/god_crypto@v0.2.0/src/primitives.ts:1:28

Closed by merging #132


Fix for non-library tracks not being displayed

Hi, the macos15 applescript was not working for tracks which are not in the library (#16). This should fix it (I've only tested it by running the applescript, I did not build the app around it) :)

That does indeed fix that issue, so thanks for finding it! The issue is that now there's a problem where the app keeps going from "Current song playing: " to "There's no song playing", so I'll have to figure out why that happens.


make verify-vendor fails on old bash version

Description
When trying to make verify-vendor locally on my dev environment which is running  Amazon Linux 2 OS, I got error(check below sections for details).  However the same command runs fine on Ubuntu 20.04 which is the CI agent.
The error pointing to this bash script which complains entry in the go.mod is missing in this go.mod.  A manual check did see the entry is present in both files.
Debug: added some prints in the above script, found out that the output of the piece of code is multiple lines of string. But when it piped into the while read block, it was treated as one single string instead of multiple line(seems the string was removed the special character, like \n). Hence the maps are not created as expected. Newer version of bash(v4.4.20 on Ubuntu 18.04) treated the multiple-line strings as expected.
We should update the script to support older version of bash.
Steps to reproduce the issue

Create an EC2 instance with OS - Amazon Linux 2
Install git, go, make, jq if you don't have them.
Clone and checkout the latest code on main branch
cd containerd
make verify-vendor

Describe the results you received and expected
Running make verify-vendor gives below error.  I expect no error as the commit on main branch which passed the CI check.
$ make verify-vendor
+ verify-vendor
github.com/opencontainers/runtime-tools  has an entry in root go.mod replace section, but is missing from  replace section in integration/client/go.mod
Found 1 error(s).
make: *** [verify-vendor] Error 1

What version of containerd are you using?
HEAD of main, commit c0c3546de4caf462e4fafea2071a25208aa04346
Any other relevant information
 $ uname -a
Linux <host_name> 5.10.157-139.675.amzn2.x86_64 #1 SMP Thu Dec 8 01:29:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ bash --version
GNU bash, version 4.2.46(2)-release (x86_64-koji-linux-gnu)

Show configuration if it is related to CRI plugin.
No response

@dims Do you mind if I rewrite this script in something other than bash? :)

@kzys go for it! :)

Should we just make the bash script compatible? If it can be handled by small change....


Optimise SpaceEngine.signature

Fixes #21569

I've run the OpenCB against these changes. So far there seems to be no new regressions since last nightly.

@lrytz dropped the extra special handling, happy to approve this now?

"may my presence forever slow your build" is one of the lesser known Halloween curses, but there you have it.
Hopefully this annoys somebody enough to look into why the compilation performance regressed so much in the first place vs Scala 2, not just for this recent change. Or is this now expected to have Scala 2 levels of perf?
Probably these test files need some attribution on them, since they are so big, but I don't feel like I'm so proud enough of them to push for that. Have fun.

@WojciechMazur should we backport this to 3.6.2?


Making sure target is not null for components that renders null for a moment

This fix comes when target (children) element sometimes renders null, so target will be null when popover componentDidMount is called making the popover to break.
An use case of this is a themed button, so it renders null until theme data is loaded asynchronously, so HTML won't appear in the UI until CSS is ready, instead of having the mark up rendered with no styles and this way we avoid UI flickering. So by the time popover is mounted it is not possible to get the target and when target element is clicked popover will break the whole page.
This change makes sure to calculate target every time the popover is updated.

Thanks for pointing this out! Hopefully the issue is now fixed!


Implement accounts/create endpoint

Adding implementation and tests for the account
creation endpoint.

@PMooreWand Thank you!


curr and next features are not additive.

What version are you using?
20.0.0-rc1
What did you do?
Cargo features are supposed to be additive. See the official docs: https://doc.rust-lang.org/cargo/reference/features.html

A consequence of this is that features should be additive. That is, enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features. A feature should not introduce a SemVer-incompatible change.

These features are not additive because these public glob imports are disabled when a feature is activated:
#[cfg(feature = "curr")]
pub mod curr;
#[cfg(all(feature = "curr", not(feature = "next")))]
pub use curr::*;

#[cfg(feature = "next")]
pub mod next;
#[cfg(all(not(feature = "curr"), feature = "next"))]
pub use next::*;

Cargo is designed with the assumption that all features are additive, likewise that there is no harm in enabling features. If you build projects with cargo, non-additive features are likely to cause problems.
For example, let's say you depend on two separate libraries, one that enables the "next" feature and one that depends on the "curr" feature. If either of those libraries uses the glob imports, the entire thing will fail to compile because the activation of both features at once prevents either of the glob imports from being included.
This is an actual problem I have encountered when implementing something that depends on soroban-client and transitively depends on soroban-sdk. Simply having both of those crates in your dependency tree will cause any attempted compilation to fail. The root cause of this issue is that the curr and next features are not additive.

Hi @dnut! The code snippet shared looks like it is from an old version of the crate before we removed the behavior described.
In the latest version of the crate, v20.0.0-rc1, the exports are not re-exported at the top level and the code looks like this:
https://github.com/stellar/rs-stellar-xdr/blob/16f4d7ccd37a8f96b1ebb59fc7878a8457fce22e/src/lib.rs#L121-L125

Note that the stellar-xdr crate is still pretty new and we have not yet released a stable version of the crate.

Nice, thanks for the quick reply. Apologies for failing to look at the master branch. It looks like you've already resolved the issue in the git repository.
FYI, I actually copied that code directly from the latest release available on crates.io, which is 20.0.0-rc1. You can also view the source for any particular version on docs.rs. https://docs.rs/crate/stellar-xdr/20.0.0-rc1/source/src/lib.rs

Ahh, yes, apologies, I thought we had made that change before the last release but I was incorrect. The next release slated for sometime next month should have this change.

Closing as this has been fixed in the main branch slated for next release.


What does the statement below mean

when you'll be ready for release please use another ctor with admobReleaseUnitId instead.

that means that you should use a different constructor for release version. Just pass a real ad unit id from your admob dashboard to it


Visualize texture from Dae file

Hi, folks,
I am using meshcat to visualize the Pinocchio robot and found the texture is missing. My visual files are using *.dae.
I checked API "pinocchio: mesh cat-viewer-dae" and it seems only the geometry shape has been imported to the viewer.
https://docs.ros.org/en/melodic/api/pinocchio/html/meshcat__visualizer_8py_source.html
Is there any way to show the texture from dae file? I might miss some API functions.

It has been fixed in Pinocchio 3.x. We hope to be able to release it soon.

Hi,
I built the pinocchio3-preview from source and install it, but it seems this issue still exist.
Should I try it by myself?
I used this function in pinocchio to visualize my dae file, maybe different API?
pin_robot = pin.RobotWrapper.BuildFromURDF(urdf, package_dirs)
self.viz = viz = pin.visualize.MeshcatVisualizer(
            pin_robot.model, pin_robot.collision_model, pin_robot.visual_model
        )
        viz.initViewer(viewer)
        viz.loadViewerModel()


Fix AssertionError and prep 0.0.27 release

A user reported seeing an "AssertionError" when running the Noteable/Prefect integration example.
I was able to reproduce the error locally:
(.venv) ➜  test-prefect-noteable-cloud python example.py
Traceback (most recent call last):
  File "example.py", line 4, in <module>
    from prefect_jupyter import notebook
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/prefect_jupyter/notebook.py", line 8, in <module>
    import papermill as pm
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/papermill/__init__.py", line 4, in <module>
    from .execute import execute_notebook
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/papermill/execute.py", line 9, in <module>
    from .engines import papermill_engines
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/papermill/engines.py", line 443, in <module>
    papermill_engines.register_entry_points()
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/papermill/engines.py", line 38, in register_entry_points
    self.register(entrypoint.name, entrypoint.load())
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/entrypoints.py", line 79, in load
    mod = import_module(self.module_name)
  File "/Users/rohitsanjay/.pyenv/versions/3.8.16/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/papermill_origami/engine.py", line 40, in <module>
    from .manager import NoteableKernelManager
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/papermill_origami/manager.py", line 12, in <module>
    class NoteableKernelManager(KernelManagerABC):
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/papermill_origami/manager.py", line 113, in NoteableKernelManager
    interrupt_kernel = run_sync(async_interrupt_kernel)
  File "/Users/rohitsanjay/playground/test-prefect-noteable-cloud/.venv/lib/python3.8/site-packages/jupyter_core/utils/__init__.py", line 147, in run_sync
    raise AssertionError
AssertionError

This PR fixes the AssertionError bug and preps a new 0.0.27 release.

Ah, here's the jupyter_core commit that enforces the iscoroutinefunction check - https://github.com/jupyter/jupyter_core/commit/589bf43e14b505fa6c22f74316d60b2c4a54be5c


key backup: Add a dedicated section to settings

@manuroe commented on Mon Jan 21 2019
See details in the meta issues.

Done in #2908


fixes examples folder

What's this PR do?

removes validators from libarary
adds a pre-release script
adds new examples folder with the replica from sandbox

Where should the reviewer start?
/examples folder and validators.ts
How should this be manually tested?

run builds
npm start in examples folder

What are the relevant tickets / issues?
#34 #37

Codecov Report

Merging #47 into master will decrease coverage by 1.48%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #47      +/-   ##
==========================================
- Coverage   84.61%   83.13%   -1.49%
==========================================
  Files           4        3       -1
  Lines          91       83       -8
  Branches       16       14       -2
==========================================
- Hits           77       69       -8
  Misses          8        8
  Partials        6        6

Impacted Files
Coverage Δ

src/validators.ts
80% <100%> (-8.89%)
:arrow_down:

Continue to review full report at Codecov.

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

Coverage decreased (-1.04%) to 83.761% when pulling b09351dd66e370c1cfd78b4cd3576e75e46d6f37 on issue/34-remove-validators into e10761e57e00aa1448f1f8c4936ba5b6eee49abc on master.

I get
/Users/mdell/Repos/form-container/examples/src/validators.ts
(2,26): Could not find a declaration file for module 'validator/lib/isEmail'. '/Users/mdell/Repos/form-container/examples/node_modules/validator/lib/isEmail.js' implicitly has an 'any' type.
  Try `npm install @types/validator` if it exists or add a new declaration (.d.ts) file containing `declare module 'validator';`

Installing the package fixes it and I can finally see the examples project! 🎉
Worth adding this build to CI as part of this PR?

added disabled attribute to the button
added build for examples folder


Dark Mode

Here's the updated theme

)

I've made the changes you requested! let me know if anything needs to be tweaked!

Thank you!


[SeaTunnel #780][issue] Add umbrella issue template

Purpose of this pull request
Add umbrella issue template.
Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] Change does not need document change, or I will submit document change to https://github.com/InterestingLab/seatunnel-docs later

@CalvinKirs thanks for your review, updated.


Kotlin multiplatform and flatbuffer support

Is your feature request related to a problem? Please describe.
The project is currently on halt, since kmp support for flatbuffers is not yet fully working.
Describe the solution you'd like
Either:

stop waiting for kmp support --> work on flatbuffer support, and later on rewrite everything as KMP
a) less work now, more later
b) a bit stupid IMHO, since java library already exists, and it can be imported in kotlin, making this one "redundant"
manually implement kmp flatbuffer classes --> rewrite from scratch everything already
a) more work now, less later
b) I honestly don't have much time during the week, but I could cut out some time on weekends to work on it
c) If I work too slowly and the flatbuffer compiler gets kmp fully implemented then all the work is going to be wasted
work on the actual flatbuffer compiler and then come back to this project
a) it would be a ton of work for me, since I have absolutely no idea of how the flatc compiler works
b) would benefit other devs as well

Additional context

Google flatbuffer repo has a few PRs waiting to be merged
Main issue is silent since September, but was already moving slow before
Java SDK already implemented in the repo

PS: I know this is more like a personal note, but feel free to comment on wtf I should do (or what you could do to help :smile:)

Please also see #40 on the website repo for original issue and brainstorming ideas

IMO, a good first approach would be
Use Java bindings in this library, make it Kotlin-JVM only, but prepare the API and system design using Kotlin-Common
When other platforms (ie Kotlin for Flatbuffers) are ready, we can just include them as supported platform.
This would make this project
1. KMP-Ready
2. Kotlin-like (Real Kotlin DSL, real Kotlin project)

One thing to take into consideration: Part of Open-Meteo API is still not available in the SDK as FlatBuffers. We can ignore flatbuffers and use http until both the SDK and Kotlin are 100% flatbuffer-compatible

IMO, a good first approach would be
Use Java bindings in this library, make it Kotlin-JVM only, but prepare the API and system design using Kotlin-Common
When other platforms (ie Kotlin for Flatbuffers) are ready, we can just include them as supported platform.
This would make this project 1. KMP-Ready 2. Kotlin-like (Real Kotlin DSL, real Kotlin project)

Lol I didn't think about this way of solving the issue, thanks! I got a first implementation of the common sub-package up and running in kmp :tada: ; the only features missing are: Date/Time stuff, URL encoding and http client (maybe ditching the one I implemented in java with something more sustainable like KTOR could solve these last two points)
I need to do more testing. Actual implemetation of all APIs should happen after the http client thing is solved: possibly flatbuffer implementation could be available in KMP by then, and even if it's still a kotlin/jvm only thing we can implement it just for that.

One thing to take into consideration: Part of Open-Meteo API is still not available in the SDK as FlatBuffers. We can ignore flatbuffers and use http until both the SDK and Kotlin are 100% flatbuffer-compatible.

Yep, currently the sdk was using protobuf, which initially was planned to be used in the other apis as well, but since flatbuffer was picked it's probably going to be used across all APIs when it's going to be finalized.
Sidenote/fun fact: csv and xlsx formats are also available to download.

We can generate the API from the OpenAPI definition instead https://github.com/melix/open-meteo/blob/main/openapi.yml

Unluckily this doesn't always reflect the latest API, as opposed to flatbuffers, which use a single source of truth (the .fbs schema files) across the server and the sdk :smile:
Again, thank you for the brillant idea @LeoColman :bow:

After some more testing I decided to create a dedicated kmp branch and push my "tests" to it.
Currently I tested the Ktor OkHttp client, with Json parsing. Protobuf should work fine too. Flatbuffers currently throw an error as "not yet implemented" (probably should use a @UseExeperimentalFlatbuffers annotation or something).
The logic is still the same: using interfaces, which allow "mixins", as opposed to classes, which let you to have only one parent class at a time, which lead to SuperVeryLongClassNames. When I get to Flatbuffer implementation I can start implementing all the response stuff.

Update 2024-01-04
Date/time problem: kotlinx-datetime should work just fine for us. I still need to test TimeZones (especially "auto" implementation) :+1:
Flatbuffer: added a git submodule to the google flatbuffer library + soft link to the main targets source code (google's repo tests require some generation in the gradle script, but I couldn't understand where the hell to place the generated output to make it so commonTest would recognize the folder; didn't link them, for now).
By adding the google/flatbuffers repo as submodule we also get a working copy of flatc (by compiling it, tho) that can generate kmp source code. If we were to add the main sdk repo (removing it when this one is merged into it) we could generate the response parse "automagically" :magic_wand:
Tested targets: my tests pass on jvm, linux, node.js & chromium.
Apple targets: I do not own any macOS device, but I do have a tethered-jailbroken iPhone; to my understanding, I would need XCode, maybe in a macOS VM, so for the time being I removed all apple stuff. Just in case, for future reference, @LeoColman do you have any macOS device to run the library tests on? It could be a big time saver, honestly :smile:

I don't have any mac :(
Only Github can run with mac for me 😂
https://github.com/kotest/kotest/blob/master/.github/workflows/release_macos.yml

Update 2024-01-21
I got some interesting stuff working on https://github.com/DadiBit/Open-Meteo-KMP
I decided to start from scratch with a "temporary" repo to experiment with gh actions and more.
I still need to figure out how to properly implement multiple location queries, but the main deal of content fetching & decoding is done. I do not plan to touch it any more[^1] :tada:
I think I could also start trying to work on a forked repo from the official open-meteo/sdk one to get everything in the kotlin subdirectory.
[^1]: Yeah I know, I know, I need to get tests done, please have mercy

experiment with gh actions

I suggest experimenting with https://github.com/typesafegithub/github-workflows-kt . Kotlin all way down :)
That repo is pretty interesting! 🎉

Thank you again for the support! It looks interesting, I'm going to have a look later on this week.
Quick update: I got the multiple location thing working, but it's not super dev-friendly. I would like to be able to pass both lists and single entries, and perhaps even add a thing that "unzips" each entry.
Meanwhile, I got my hands dirty with the flatbuffer kmp compiler, and I'm probably going to make a PR from DadiBit/flatbuffers, since, right now, the compiler doesn't use enum class for enums... It would make the code cleaner and overall more intuitive. If you have any C++ knowledge I would love some feedback on.


Windows desktop shell needs to pass --aot-shared-library-name in profile/release mode

Abandoned change to do so for linux is here: https://github.com/flutter/engine/pull/12796/files
This will allow the tool to provide AOT artifacts for Windows desktop builds. (Yes, the so will work on windows).

This should be closed in favor of #50778, right?


Remove little caret ^ from package.json

Here is the article that justifies all Software Versions are Broken.
A little intro:
"I’ll admit it. Like almost everybody in the Node community, I’m in the habit of abusing npm’s save feature:
npm install --save lodash

The problem is, it uses a neat little caret ^ to indicate that your software should automatically use non-breaking changes.
But this could be dangerous. We all know that John-David Dalton is an unstoppable robot from the future.
....
What if he’s on a secret mission to stop Skynet by slipping a time bomb into all of our code? One of these days, he’ll make a breaking change to lodash, and the next time you npm install, BOOM!
Your code will break. Because he won’t increment the major version number… (sneaky robot).
...."
What do you think?

I think including and excluding the version range both have some pros and cons.
Exact matches gives you the certainty that malicious (intentional) and accidental minor/patch versions won't break your code.
This just happened with awesome-typescript-loader, and after reporting the issue I put in the exact match.
Range matches will put some trust into the package authors that they correctly use semver, but in turn you benefit from automatic fixes (solving bugs or improving performance).
Imagine you have an issue, spend some time finding it, and see that it was already fixed.
Granted, this only helps if you (periodically) re-install your npm modules, otherwise you won't get the updated modules.
Important note, this only helps for dependancies directly listed in your package.json, sub-dependancies are out of your hand. If you want to properly lock all installed versions, you can use the shrinkwrap feature.

Important note, this only helps for dependencies directly listed in your package.json, sub-dependencies are out of your hand. If you want to properly lock all installed versions, you can use the shrinkwrap feature.

I vote for idempotent builds and think every one of us should fix our dependencies, but shrinkwrap looks great.

Most of us have switched to yarn, which created a yarn.lock file, locking all versions.
Also, npm@5 will --save by default now. Additionally, package-lock.json will be automatically created unless an npm-shrinkwrap.json exists.
So we could switch to that version as well.


Adds generation of creationInfo for all Individuals

A minimal approach of adding a valid creationInfo for all defined Individuals.
Waiting for @bact and/or @goneall to verify that the generated RDF passes validation.
Signed-off-by: Alexios Zavras (zvr<EMAIL_ADDRESS>

This is much simpler than #154 and I believe it correctly generates the required RDF structures.

There is one point about creationInfo's identifier: https://github.com/spdx/spec-parser/pull/154#issuecomment-2346906588
@sbarnum do you mind to review this please?

Merging after discussion in the special call of 2024-12-05


Can't play DOOM on it

This should be self-explanatory.

when?

I am sorry, but this project is dead, as seen in commit e409d1b.


Revisit log level for errors in gvisor-tap-vsock

Currently we are using error log for places like below,
https://github.com/containers/gvisor-tap-vsock/blob/main/pkg/services/forwarder/tcp.go#L45
Even though we get this error, there is no actual impact in the working due to this.
Can we move such errors as debug. This way we will reduce the noise in upstream services when integrated.
Related ticket in Lima - https://github.com/lima-vm/lima/issues/1160

If we are okay in doing it, am happy to raise a PR for the same.

Do you know when this error occurs? When a port on the host is forwarded to the VM, but nothing listen on this port in the VM? Looking at this specific error, I wonder if we should be doing this when it happens:
		ep, tcpErr := r.CreateEndpoint(&wq)
		if tcpErr != nil {
			log.Errorf("r.CreateEndpoint() = %v", tcpErr)
			r.Complete(true)
			return
		}
		r.Complete(false)

A PR making the warning less visible is welcome.

PR:

https://github.com/containers/gvisor-tap-vsock/pull/408

I didn't touch the r.Complete in this PR, to avoid causing regressions right before the new release


Inconsistent frame/elapsed time for camera sensor data in 0.9.10-2

I am seeing inconsistent frame numbers and elapsed time values using the latest 0.9.10-2 debian release on Ubuntu.
I have scenario where I am placing random pedestrians in each frame, and viewing them with three co-located cameras: rgb, depth and segmentation. I am using synchronous mode with a fixed time delta of .1s (10fps). This worked ok with 0.9.10-1,
but with the latest release I am sometimes getting consecutive records from each sensor that have the same frame number or same elapsed time as the previous frame and if you look at the images, they don't line up consistently. So I basically cannot trust the frame and timestamp labels I am getting from Carla.
Here are a few frames from the segmentation and rgb cameras. In this case, the segmentation camera frame numbers are one less than the corresponding rgb frames and the elapsed times are either one behind or are just wrong. But there is no consistent pattern even within a single episode.

I don't have a simple script to reproduce this right now, but I can write one if you need it.
Is this a known issue?

Here is a script to reproduce at least some of the bad behavior.
Using this script, I have not observed a total mismatch of images with the same frame #'s as was shown in the above example, but it does usually show duplicate frames and mismatches with frames with the same elapsed timestamp. I suspect the reason my own code is showing worse effect is due to some difference in timing.
Unless there is some workaround for this, I don't think I can do any sensor fusion with the data from this version of Carla.
"""
Script to reproduce Carla bug 3391
"""

import argparse
import csv
import os
import re
import subprocess
import sys
import time
from abc import ABC, abstractmethod
from glob import glob
from queue import Queue, Empty
from shutil import rmtree
from threading import Thread
from typing import cast

carla_root = os.getenv('CARLA_PYTHON_ROOT', '/opt/carla-simulator')
assert os.path.isdir(carla_root)
glob_expr = os.path.join(carla_root, 'PythonAPI', 'carla', 'dist', 'carla-*-py3.7-*.egg')
print(glob_expr)
carla_egg = glob(glob_expr)
sys.path.append(carla_egg[0])

import carla
import numpy as np

class CarlaSession:
    server_process = None
    client = None

    def __init__(self):
        pass

    def start(self):
        self.server_process = subprocess.Popen(
            [os.path.join(carla_root, 'CarlaUE4','Binaries', 'Linux', 'CarlaUE4-Linux-Shipping'), 'CarlaUE4'],
            stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL
        )
        time.sleep(5)
        self.client = carla.Client('localhost', 2000)

    def stop(self):
        proc = self.server_process
        proc.terminate()
        for i in range(20):
            try:
                proc.wait(1)
            except (TimeoutError, subprocess.TimeoutExpired):
                print(i)
                proc.kill()

    def __enter__(self):
        self.start()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        self.stop()

class Camera(ABC):
    name:str
    input_queue:Queue
    thread:Thread
    actor:carla.Sensor
    timeout:float = 10.0
    outdir:str = ''
    frames:int = 10

    def __init__(self, name, *,
                 world:carla.World,
                 pose:carla.Transform
                 ):
        self.name = name
        self.input_queue = Queue(maxsize=100)
        bp = world.get_blueprint_library().find(f'sensor.camera.{name}')
        bp.set_attribute('fov', '120')
        bp.set_attribute('image_size_x', '1000')
        bp.set_attribute('image_size_y', '1000')
        bp.set_attribute('role_name', name)
        self.actor = world.spawn_actor(bp, pose)
        self.thread = Thread(
            target = self.process_queue,
            name = f"{name}_thread",
            daemon = True
        )

    @property
    def frames_file(self) -> str:
        return os.path.join(self.outdir, f'{self.name}-frames.csv')

    def data_file(self, offset:int) -> str:
        return os.path.join(self.outdir, f'{self.name}-{int(offset)}.npy')

    def process_queue(self):
        q = self.input_queue
        try:
            count = 0
            prev_frame = -1
            prev_elapsed = -1.0
            with open(self.frames_file, 'w', newline='') as f:
                csvout = csv.writer(f, dialect='unix', quoting=csv.QUOTE_MINIMAL)
                csvout.writerow(['n','frame','elapsed'])
                while count < self.frames:
                    entry:carla.Image = q.get(timeout = self.timeout)
                    a = self.to_array(entry)
                    np.save(self.data_file(count), a)
                    csvout.writerow([count, entry.frame, entry.timestamp])
                    if entry.frame == prev_frame:
                        print(f'{self.name} {count} has same frame # as previous # {prev_frame}',
                              file = sys.stderr)
                    if entry.timestamp == prev_elapsed:
                        print(f'{self.name} {count} has same elapsed time as previous {prev_elapsed:.2f}',
                              file = sys.stderr)
                    prev_frame = entry.frame
                    prev_elapsed = entry.timestamp
                    count += 1
        except Empty:
            pass

    def read_frame_data(self, strip_duplicates=False) -> np.ndarray:
        with open(self.frames_file, newline='') as f:
            csvin = csv.reader(f, dialect='unix')
            rows = list(csvin)

        data = np.array(rows[1:], dtype=float)

        if strip_duplicates:
            # strip any rows that contain an entry with a non-unique frame or elapsed value
            frames = data[:,1]
            _, idx, count = np.unique(frames, return_index=True, return_counts=True)
            uframeidx = idx[count == 1]
            elapsed = data[:,2]
            _, idx, count = np.unique(elapsed, return_index=True, return_counts=True)
            uelapsedidx = idx[count == 1]
            idx = sorted(set(uframeidx).intersection(uelapsedidx))
            data = data[idx]

        return data

    def start_listening(self):
        self.actor.listen(self.enqueue_input)

    def enqueue_input(self, image:carla.Image):
        self.input_queue.put(image)

    @abstractmethod
    def to_array(self, image:carla.Image) -> np.ndarray:
        pass

class RGBCamera(Camera):
    def __init__(self, *, world, pose):
        super().__init__('rgb', world=world, pose=pose)

    def to_array(self, image:carla.Image) -> np.ndarray:
        bgra = np.frombuffer(image.raw_data, dtype=np.uint8).reshape(image.height, image.width, -1)
        return np.flip(bgra, axis=-1)[:,:,1:]

class DepthCamera(Camera):
    def __init__(self, *, world, pose):
        super().__init__('depth', world=world, pose=pose)

    def to_array(self, image:carla.Image) -> np.ndarray:
        rawdepth = np.frombuffer(image.raw_data, dtype='>u4').reshape(image.height, image.width)
        # BGRA form where BGR holds the depth where max value is 1000 meters
        return cast(np.ndarray, np.multiply(rawdepth, 1000.0 / 0xFFFFFF00, dtype=np.float32))

class SegCamera(Camera):
    def __init__(self, *, world, pose):
        super().__init__('semantic_segmentation', world=world, pose=pose)

    def to_array(self, image:carla.Image) -> np.ndarray:
        bgra = np.frombuffer(image.raw_data, dtype=np.uint8).reshape(image.height, image.width, -1)
        # initially in BGRA format, only the red channel is used
        return bgra[:,:,2].copy()

def main(argv=None):
    basedir = os.getcwd()
    out_prefix = os.path.splitext(os.path.basename(__file__))[0]
    prev_dirs = glob(os.path.join(basedir, out_prefix + '-*'))
    highest_counter = 0
    for path in prev_dirs:
        m = re.search('-(\d+)', path)
        if m:
            highest_counter = max(highest_counter, int(m.group(1)))
    outdir = os.path.join(basedir, out_prefix + f'-{highest_counter+1}')

    parser = argparse.ArgumentParser(
        description = "Reproduce Carla issue #3391"
    )
    parser.add_argument(
        '--frames', metavar='<n>', type=int, default=10,
        help="Number of frames to generate"
    )
    parser.add_argument(
        '--out', metavar='<dir>', default=outdir,
        help = 'Output directory (%(default)s).'
    )
    parser.add_argument(
        '--clean', action='store_true',
        help = 'Remove existing output directories'
    )

    parsed = parser.parse_args(argv)

    frames = int(parsed.frames)

    if parsed.clean:
        for path in prev_dirs:
            rmtree(path, ignore_errors=True)
        if parsed.out == outdir:
            parsed.out = os.path.join(basedir, f'{out_prefix}-1')

    outdir = parsed.out
    os.makedirs(outdir, exist_ok=False)

    with CarlaSession() as session:
        client = session.client
        world = client.load_world('Town01')
        world.apply_settings(
            carla.WorldSettings(
                synchronous_mode = True,
                fixed_delta_seconds = 0.1
            )
        )
        location = carla.Location(68.133, 192.315, 3)
        pose = carla.Transform(location, carla.Rotation(-90,0,0))
        world.get_spectator().set_transform(pose)

        world.set_weather(carla.WeatherParameters.ClearNoon)

        bpl = world.get_blueprint_library()

        cameras = tuple(
            Cam(world=world, pose=pose)
            for Cam in (RGBCamera, DepthCamera, SegCamera)
        )
        rgbcam, depthcam, segcam = cameras

        for camera in cameras:
            camera.outdir = outdir
            camera.frames = frames
            camera.thread.start()

        # tick once so that sensors will have locations
        world.tick()
        # world.tick()

        # HACK: not sure why this sleep is necessary, but otherwise
        # we end up getting an empty initial frame.
        time.sleep(1)

        for camera in cameras:
            camera.start_listening()

        # Generate a frame with no pedestrians
        world.tick()

        frame_data = []

        for _ in range(frames):
            people_bps = list(bpl.filter('pedestrian'))
            n_people = np.random.randint(1, len(people_bps))
            people_bps = np.random.choice(people_bps, n_people, replace=False)
            people = []
            for bp in people_bps:
                person_pose = carla.Transform(
                    carla.Location(
                        x=location.x + np.random.uniform(-3.0, 3.0),
                        y=location.y + np.random.uniform(-3.0, 3.0),
                        z=.1,
                    ),
                    carla.Rotation(
                        yaw=np.random.uniform(-180.0, 180.0)
                    )
                )
                try:
                    people.append(world.spawn_actor(bp, person_pose))
                except RuntimeError:
                    pass # probably a collision

            world.tick()

            for person in people:
                person.destroy()

        for camera in cameras:
            camera.thread.join()

        # Read CSV files
        rgb_frames = rgbcam.read_frame_data(strip_duplicates=False)
        seg_frames = segcam.read_frame_data(strip_duplicates=False)
        depth_frames = segcam.read_frame_data(strip_duplicates=False)

        rgb0 = np.load(rgbcam.data_file(0))
        seg0 = np.load(segcam.data_file(0))
        depth0 = np.load(depthcam.data_file(0))

        PEDESTRIAN_FLAG = 4
        # there should be no pedestrians in first frame
        assert np.all(seg0 != PEDESTRIAN_FLAG)

        for row in seg_frames[1:]:
            n = int(row[0])
            frame = int(row[1])
            elapsed = float(row[2])
            segn = np.load(segcam.data_file(n))
            pedmask = segn == PEDESTRIAN_FLAG
            if not np.any(pedmask):
                continue # no pedestrians in view

            # find corresponding depth frame
            for row in depth_frames:
                depth_frame = int(row[1])
                depth_elapsed = float(row[2])
                if depth_elapsed == elapsed:
                # if depth_frame == frame:
                    dn = int(row[0])
                    depthn = np.load(depthcam.data_file(dn))
                    depthn[pedmask] = depth0[pedmask]
                    # the pixels without pedestrians in them should have the same values
                    # really they should be the same, but we will allow a fudge factor
                    norm = np.linalg.norm(depthn - depth0)
                    isclose = norm < 10
                    # if isclose:
                    #     print(f'Depth and seg at frame {frame} are ok')
                    if not isclose:
                        print(f'Depth {dn} and seg {n} at frame {frame} {elapsed:.2f}s are mismatched',
                              file=sys.stderr)
                    break

if __name__ == '__main__':
    main()

Hello! Did your problem solved in the latest release <IP_ADDRESS>?

I'm not sure, but I think your problem is that you use wold.tick() multiple times there.
It should be use once for each iteration of the synchronous mode.


Error sending confirmation SMS (Golang unable to marshal JSON)

Bug report
Describe the bug
Phone Auth is not working properly when calling
const { user, error } = await supabase.auth.signUp({
  email: values.email,
  password: values.password,
  phone: values.phoneNumber
})

To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

Use Phone Auth
See error

Expected behavior
A confirmation SMS should be sent
Screenshots

System information

OS: Windows
Browser (if applies) Chrome
Version of supabase-js: 1.24.0

Additional context
The phone number is a Malaysian phone number starting with +60, since this error is coming from Golang, I suspect it's something wrong with the supabase backend?

thanks for the report @marcustut
can I ask are you using the default template in Auth > Templates?
and how are you passing the mobile number? Does it still fail if you remove the + ?

it seems like gotrue is choking on one of these provided values https://github.com/supabase/gotrue/blob/9dfe6fe65e5607fbd020233c0bc98dd954f084a8/api/sms_provider/twilio.go#L23
it appears we may need to do some extra validation on either the template body, or something else


Maya: Context plugin shouldn't be tied to family

Changelog Description
Maya Current File collector was tied to workfile unnecessary. It should run even if workile instance is not being published.
Testing notes:

Disable workfile instance and publish
Collect Scene Version shouldnt fail

Code looks good to me, and i tested it by myself. The instance published successfully without workfile instance.


feat: load tsconfig from the root of the project

I was able to load the tsconfig.json file from the root of the project directory. One issue that I came across was that if the tsconfig.json file has comments in it, it doesn't work.
Edit: works for all types of JSON
Example:
This works:
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "dist",
    "sourceMap": true
  }
}

This doesn't:
{
  "compilerOptions": {
    "target": "es5", /* comment */
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "dist",
    "sourceMap": true
  }
}

I have a doubt about this line './':
https://github.com/metacall/core/pull/79/commits/7b2ee4301ecab210dabaaba70f3ffe7ce085a39d#diff-c3ca75029244d601e86b44b1fa2dab42a36607df0bf0d6ec295c7882c4651889R93
In the source ( https://github.com/microsoft/TypeScript/blob/5053b0b987295296108598bdfd87865d9751f237/src/compiler/commandLineParser.ts#L2360 ) we can see that the third parameter is basePath. To what path is this relative?
Maybe we should use the LOADER_SCRIPT_PATH environment variable like I have pointed out here: https://github.com/metacall/core/blob/cd843ef37fe2efcfb33bbb64dccf0973b52e8493/source/loaders/ts_loader/bootstrap/lib/bootstrap.ts#L94
This environment variable is the standard folder where MetaCall will load the scripts. In the CLI, it is set up to process.cwd() but it can be overwritten.
What do you think about it?

I have a doubt about this line './':
7b2ee43#diff-c3ca75029244d601e86b44b1fa2dab42a36607df0bf0d6ec295c7882c4651889R93
In the source ( https://github.com/microsoft/TypeScript/blob/5053b0b987295296108598bdfd87865d9751f237/src/compiler/commandLineParser.ts#L2360 ) we can see that the third parameter is basePath. To what path is this relative?

Yeah, I think we should use currentDirectory instead of ./

Maybe we should use the LOADER_SCRIPT_PATH environment variable like I have pointed out here:
https://github.com/metacall/core/blob/cd843ef37fe2efcfb33bbb64dccf0973b52e8493/source/loaders/ts_loader/bootstrap/lib/bootstrap.ts#L94
This environment variable is the standard folder where MetaCall will load the scripts. In the CLI, it is set up to process.cwd() but it can be overwritten.
What do you think about it?

Right now I'm treating currentDirectory as the root of the project but it's also where I run metacall index.ts so I tried running it from another folder and it seemed to work fine. I don't think I know enough right now to comprehend about replacing with LOADER_SCRIPT_PATH.

Fair enough, the TSX test has to be updated because the tsconfig was hardcoded and will fail. But this is another PR that I can do easily.


Move all the variables to globals.scss

So add-ons can have access to all the variables without including all the files.

Clean up add-ons:

[ ] atGrid
[ ] UI
[ ] Add-on boilerplate

Done.


认证: practice/authentication.md

This article is waiting to be claimed. practice/authentication.md

/accept

/merged


Basic isometry types

Objective
Introduce isometry types for describing relative and absolute position in mathematical contexts.
Solution
For the time being, this is a very minimal implementation. This implements the following faculties for two- and three-dimensional isometry types:

Identity transformations
Creation from translations and/or rotations
Inverses
Multiplication (composition) of isometries with each other
Application of isometries to points (as vectors)
Conversion of isometries to affine transformations

There is obviously a lot more that could be added, so I erred on the side of adding things that I knew would be useful, with the idea of expanding this in the near future as needed.
(I also fixed some random doc problems in bevy_math.)

Design
One point of interest here is the matter of if/when to use aligned types. In the implementation of 3d isometries, I used Vec3A rather than Vec3 because it has no impact on size/alignment, but I'm still not sure about that decision (although it is easily changed).
For 2d isometries — which are encoded by four floats — the idea of shoving them into a single 128-bit buffer (__m128 or whatever) sounds kind of enticing, but it's more involved and would involve writing unsafe code, so I didn't do that for now.
Future work

Expand the API to include shortcuts like inverse_mul and inverse_transform for efficiency reasons.
Include more convenience constructors and methods (e.g. from_xy, from_xyz).
Refactor bevy_math::bounding to use the isometry types.
Add conversions to/from isometries for Transform/GlobalTransform in bevy_transform.

I think the changes should be pretty clear from the commit history, but here's what I did:

Deviated from Affine conventions to rename to just IsometryNd::new and transform_point, reordering parameters as well.
Added all of the standard #[derive] stuff to each new struct.
Added Mul<VecN> (essentially uses transform_point, but the return type always matches the input type) and Mul<DirN> (ignores translation component) impls.
Added feature-conditioned impls for AbsDiffEq, RelativeEq, and UlpsEq, which all just look at the components.
Added some tests.

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to https://github.com/bevyengine/bevy-website/issues/1656 if you'd like to help out.


ARROW-16554: [Java] Download Java nightlies artifacts from https://nightlies.apache.org/arrow/java/org/apache/arrow/

Download Java nightlies artifacts from https://nightlies.apache.org/arrow/java/org/apache/arrow/

The instructions work from a quick test, I think we can just clarify the wording

The instructions work from a quick test, I think we can just clarify the wording

Just compiling that locally and it is rendering properly. Thank you.
There are points needed to review as an improvement about the version number ready to use, this is going to be managed in another PR after the CI Java is implemented.


Update riak_core to use clique 0.3.1

We don't currently need to use the new features of clique 0.3.1, but it won't hurt to preemptively update the develop branch, and we'll definitely want the latest version at some point. We also need the latest clique version for the data platform so this will help prevent version conflicts.

+1

+1 ab0b7a3

@borshop merge


enable tc-restore support

I'm not in favor of this frankly because it's yet more behavior that I won't be testing (and there's already mountains of that type of functionality here that I'm not happy about but we can't really get away from at this point).
From what I can tell about this tiny core feature, it sounds like you're trying to use boot2docker beyond it's limited intended purpose (namely that of being a limited/lightweight distro for docker-machine), which is typically when I recommend folks turn to a more suitable distribution such as Debian, Ubuntu, or even Alpine.
In your case it sounds like you've got a decent amount of Tiny Core experience already, so you might even be better off using Tiny Core itself directly.

Alpine is great, Thank you for mentioning.


Tutorial 3 - Build a proof of existence dApp

Hi,
may you help?

I Added a skeleton set of pallet dependencies and macros as described and replaced the macros with the given code lines.
cargo check -p node-template-runtime -> Gives me the following errors:

robert@robert:~/substrate-node-template/pallets/template/src$ cargo check -p node-template-runtime
   Compiling node-template-runtime v4.0.0-dev (/home/robert/substrate-node-template/runtime)
    Checking pallet-template v4.0.0-dev (/home/robert/substrate-node-template/pallets/template)
error[E0599]: the function or associated item `contains_key` exists for struct `frame_support::pallet_prelude::StorageMap<_GeneratedPrefixForStorageProofs<T>, frame_support::Blake2_128Concat, Vec<u8>, (<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber), frame_support::pallet_prelude::ValueQuery>`, but its trait bounds were not satisfied
   --> pallets/template/src/lib.rs:75:31
    |
75  |         ensure!(!Proofs::<T>::contains_key(&proof), Error::<T>::ProofAlreadyClaimed);
    |                               ^^^^^^^^^^^^ function or associated item cannot be called on `frame_support::pallet_prelude::StorageMap<_GeneratedPrefixForStorageProofs<T>, frame_support::Blake2_128Concat, Vec<u8>, (<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber), frame_support::pallet_prelude::ValueQuery>` due to unsatisfied trait bounds
    |
   ::: /home/robert/.cargo/git/checkouts/substrate-7e08433d4c370a21/22d40c7/frame/support/src/storage/types/mod.rs:89:1
    |
89  | pub struct ValueQuery;
    | ---------------------- doesn't satisfy `_: QueryKindTrait<(<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber), GetDefault>`
    |
   ::: /home/robert/.cargo/git/checkouts/substrate-7e08433d4c370a21/22d40c7/frame/support/src/traits/misc.rs:420:1
    |
420 | pub struct GetDefault;
    | ---------------------- doesn't satisfy `_: frame_support::traits::Get<(<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber)>`
    |
    = note: the following trait bounds were not satisfied:
            `frame_support::pallet_prelude::ValueQuery: QueryKindTrait<(<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber), GetDefault>`
            `GetDefault: frame_support::traits::Get<(<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber)>`

error[E0599]: the function or associated item `insert` exists for struct `frame_support::pallet_prelude::StorageMap<_GeneratedPrefixForStorageProofs<T>, frame_support::Blake2_128Concat, Vec<u8>, (<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber), frame_support::pallet_prelude::ValueQuery>`, but its trait bounds were not satisfied
   --> pallets/template/src/lib.rs:81:22
    |
81  |         Proofs::<T>::insert(&proof, (&sender, current_block));
    |                      ^^^^^^ function or associated item cannot be called on `frame_support::pallet_prelude::StorageMap<_GeneratedPrefixForStorageProofs<T>, frame_support::Blake2_128Concat, Vec<u8>, (<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber), frame_support::pallet_prelude::ValueQuery>` due to unsatisfied trait bounds

The AccountId that is stored in the map is not defaultable anymore, could this but out the tutorial here?

Hi,
how can I set the AccountID to nondefaultable?

If you remove the ValueQuery from the end of the StorageMap definition, but then a lot of other things are probably going to break.
@bkchr should now if this is indeed a problem with the tutorial.

Yes, you need to use OptionQuery. Then it will not require anymore that the type implements Default

I changed ValueQuery to OptionQuery.
now the following error is occurring. May you please help again?
cargo check -p node-template-runtime    Compiling node-template-runtime v4.0.0-dev (/home/robert/substrate-node-template/runtime)     Checking pallet-template v4.0.0-dev (/home/robert/substrate-node-template/pallets/template) error[E0308]: mismatched types    --> pallets/template/src/lib.rs:102:13     | 102 |         let (owner, _) = Proofs::<T>::get(&proof);     |             ^^^^^^^^^^   ------------------------ this expression has type std::option::Option<(::AccountId, ::BlockNumber)>    |             |     |             expected enumstd::option::Option, found tuple     |     = note: expected enum std::option::Option<(::AccountId, ::BlockNumber)>              found tuple(_, _)`
error[E0277]: the trait bound Vec<u8>: MaxEncodedLen is not satisfied
--> pallets/template/src/lib.rs:46:15
|
46 |     #[pallet::pallet]
|               ^^^^^^ the trait MaxEncodedLen is not implemented for Vec<u8>
|
= note: required because of the requirements on the impl of StorageInfoTrait for frame_support::pallet_prelude::StorageMap<_GeneratedPrefixForStorageProofs<T>, frame_support::Blake2_128Concat, Vec<u8>, (<T as frame_system::Config>::AccountId, <T as frame_system::Config>::BlockNumber)>
Some errors have detailed explanations: E0277, E0308.
For more information about an error, try rustc --explain E0277.
error: could not compile pallet-template due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed
`


[debugger] Windows support + process-drawable + joint

Looks like these two files havn't been added to the reference tests

merged in https://github.com/water111/jak-project/pull/953

Awesome, thanks.


Adds "completed" signal to GDFunctionState

Closes #3235
Allows code like this:
func _ready():
    whatever()
    print("_ready finished")

func whatever():
    var ret = yield(do_something(), "completed")
    prints("do_something() returned:", ret)

func do_something():
    print("do_something began")
    yield(get_node("timer"), "timeout")
    print("do_something resumed")
    return 13

# Output
# _ready finished
# do_something began
# do_something resumed
# do_something returned: 13

Rejoice.
Note: In the above example, whatever() would never be resumed if do_something() used a normal yield which returns a GDFunctionState that must be manually resumed. I think that's what #7618 complains about.

Clearly, using normal yield together with yield on signal in the same function is an horrible idea and should not be done. I'll make a proposal soon to separate the concept of yielding on signal from the yield keyword. Maybe something like await. What the hell, we could even have an Awaiter class that one could derive from.

Oh, that's very nice. 👍

I think it's just a matter of documentation.
But it's really nice and clever to get this feature with such a small change. Thanks!

The added functionality is nice. But I'm still not sure about the use of a hardcoded signal name.
Not that it's an absolutely bad thing (after all, it's just adding a signal to an object's API), but maybe we can come up with a better syntax that would make this perfect, more like something builtin in the language.

I don't quite understand what you want to point out: in the backed, he added a signal called "completed", and this signal is exposed to GDScript as-is, and the signal name as is hard-coded just like the name of any other signal.
Are you saying that this signal should be hidden from GDScript and put behind some special syntax, or it should be implemented using a totally different mechanism that doesn't involve signals?
I don't think using a signal is any weirder than the fact that yield() returns a function state object which you're supposed to use for dealing with them.

Option 1, I'd say. :)
Not sure about the "should" part. I'm just trying to encourage a bit
further discussion on this.
I find that adding a signal to a class' API is perfectly fine, but in
this context, using it to overcome a limitation of the language, I feel
we are mixing high and low level elements.
If the signal has allowed to implement this in a painless way, that's
great and a clever usage of it, but maybe it should be hidden as an
implementation detail. That's my point. Hope makes sense.
El 16/05/2017 a las 0:23, Ferenc Arn escribió:

I don't quite understand what you want to point out: in the backed, he
added a signal called "completed", and this signal is exposed to
GDScript as-is, and the signal name as is hard-coded just like the
name of any other signal.
Are you saying that this signal should be hidden from GDScript and put
behind some special syntax, or it should be implemented using a
totally different mechanism that doesn't involve signals?
I don't think using a signal is any weirder than the fact that yield()
returns a function state object which you're supposed to use for
dealing with them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/8573#issuecomment-301622123,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCtir3BGGU7vS-Zz4k6r6Tp39fcNxhks5r6NBvgaJpZM4NL0cF.

Yes, we can keep discussing until eternity until we find the most perfect solution, but it wouldn't be productive. Godot's yield mechanism is weird to me, and clean solution is to have true coroutines with channels.
But given the current state of Godot (yield with function state object), this is a very clean cut solution to the problem, within the current status quo.

Also, adding this signal doesn't prevent adding a syntax sugar for it.

And regardless of the original context, even just for the sake of completeness, I think it's clear that function state should have a completed signal.

The potential new syntax would not be an alternative way of dealing with
the signal, but the only documented, reliable way of using the enhanced
yield.
The signal would probably remain visible (like happens with other
signals the engine uses internally) but with an underscore-prefixed
name, indicating it's an implementation detail, not intended for direct
use, subject to change, etc.
So this cannot be done as a two step process because the "syntax sugar"
would break compatibility.
El 16/05/2017 a las 0:41, Ferenc Arn escribió:

Also, adding this signal doesn't prevent adding a syntax sugar for it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/8573#issuecomment-301625506,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCtjwg5LdpFbwtILWVIly_wlkdPD8Sks5r6NSfgaJpZM4NL0cF.

Forget about the original context or "enhanced yield" or any bikeshed about syntax. Tell me why shouldn't GDFunctionState have a signal indicating its completion? Because that's what this PR is.

Just to be clear, you're talking about blocking a non-invasive, working practical solution to a real-life issue based not on it's technical defects but a hypothetical future solution that you don't have.

This discussion is getting unproductive.
Let the project maintainers decide when to merge.
If in the meantime (or before 2.1.4, from where there will not be going
back) I have time, I'll give this some thought and try to propose something
concrete.
El 16 may. 2017 1:20 a. m., "Ferenc Arn"<EMAIL_ADDRESS>escribió:

Just to be clear, you're talking about blocking a non-invasive, working
practical solution to a real-life issue based not on it's technical defects
but a hypothetical future solution that you don't have.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/8573#issuecomment-301631771,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCtk8tSdMSDThs0UGzUbLX6Mz8eA38ks5r6N21gaJpZM4NL0cF
.

Just to be clear, you're talking about blocking a non-invasive, working practical solution to a real-life issue based not on it's technical defects but a hypothetical future solution that you don't have.

@tagcup, I would encourage you to read https://opensource.com/open-organization/17/2/assuming-positive-intent
@RandomShaper is not a random know-it-better whose opinion should be discarded as irrelevant. He's an active contributor and has often expressed very helpful opinions on various topics, especially API changes. If you don't want to participate in a discussion about a "hypothetical future solution" or better syntax, it's totally fine, but then just let his comment drop without trying to expose his alleged "bikeshedding". I very much prefer discussions to happen before a new API is introduced, than after it landed in a stable release and can't be changed without breaking compatibility.
Now, regarding the actual discussion, I have no opinion myself, but I'm glad that some contributors are reviewing changes and giving feedback (something I'm always asking for and trying to encourage). Having to reach a consensus is a healthy stage in the development of core new features.

@neikeq, what do you think about this?:

renaming the signal to _completed to mark it as an implementation detail (and as such, keep it undocumented) so that the effective experience is that GDScript supports recursive yielding;
then adding another built-in function to GDScript that does the same as yield(..., "_completed") while hiding the signaling; not sure if await would be suited here (you can tell as you are more versed in .NET or it may conflict with your other idea); other names could be wait, wait_for, hold or something like those.

@akien-mga Except this has been discussed for over a year #3223 #3235, and I already gave two solutions which would be a totally different yield, a clean wait or await, or adding CSP style channels mechanism which would solve even more than that specific issue.

Now, regarding the actual discussion, I have no opinion myself, but I'm glad that some contributors are reviewing changes and giving feedback (something I'm always asking for and trying to encourage). Having to reach a consensus is a healthy stage in the development of core new features.

Now that's funny because I remember you guys favoring practicality over thinking about better solutions when I defended this exact argument in the past.
He's just talking about implementing exactly the same thing, but with a different syntax. Now if you don't wanna call it bikeshedding because you drank a few beers together, that's fine. I'd rather remain objective.
If you want to see discussion, you'd see to get an answer from him for this:

Tell me why shouldn't GDFunctionState have a signal indicating its completion? Because that's what this PR is.

If he can't answer this, his objection has no value. But go ahead, ignore that question, be with your buddy.

renaming the signal to _completed to mark it as an implementation detail (and as such, keep it undocumented) so that the effective experience is that GDScript supports recursive yielding
When I wrote this:

Are you saying that this signal should be hidden from GDScript and put behind some special syntax, or it should be implemented using a totally different mechanism that doesn't involve signals?

I just wrote it to illustrate how silly those would be.

then adding another built-in function to GDScript that does the same as yield(..., "_completed") while hiding the signaling; not sure if await would be suited here (you can tell as you are more versed in .NET or it may conflict with your other idea); other names could be wait, wait_for, hold or something like those.

This is nothing more that implementing what I said #3235, using this PR as the backend. You're just reiterating what has already been discussed.

And BTW, he is the one talking about adding a new API. Which is not the same thing as adding a new and totally sensible signal isn't.
And again, there is no real reason you can have this signal and add an await function later on if you want (if you ignore "there should be one and only one true way to do a thing" kind like philosophical arguments, which is already not true for GDScript anyway).

I'm starting to think you are not interested in the actual topic, but
rather in getting some fun (there are many kinds of people with weird ways
of getting fun).
 Would that
satisfy your ego?
You are talking as a tyrannical boss, and I'm not your employee. If you
can't be respectful online, please stop participating until you learn.
Would you be talking to me so harshly if you were in front of me?
Your opinion about my proposal is welcome, after all. Our interest is
making Godot as good as possible. But forget for how long your issue has
been opened and limit yourself to the present.
El 16 may. 2017 5:10 p. m., "Ferenc Arn"<EMAIL_ADDRESS>escribió:

And BTW, he is the one talking about adding a new API. Which is not the
same thing as adding a new and totally sensible signal isn't.
And again, there is no real reason you can have this signal and add an
await function later on if you want (if you ignore "there should be one and
only one true way to do a thing" kind like philosophical arguments, which
is already not true for GDScript anyway).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/8573#issuecomment-301813309,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCtssPsM7Medq3NZnqErQmrHwtrfvmks5r6bxvgaJpZM4NL0cF
.

sigh
Locking that conversation as it's going nowhere. People from the GH org (esp. @neikeq as PR author and @reduz who should review it) are still free to discuss the actual technical questions here.

The idea of this PR is to have something working without touching GDScript. We can discuss better solutions that would invole changing GDScript, but I can tell you that any solution would most likely have to use the "completed" signal under the hood to know when a function actually completed.
The following is a solution I had in mind and the problems I found when implementing it:
When I mentioned await I didn't really mean (or not necessarily) implementing the Awaitable pattern like in C#. Just a different syntax, with the purpose of separating it from yield, since yield() without arguments must not be used together with yield on signal.
Yield on signal should also return a different type than GDFunctionState (although it would use GDFunctionState under the hood), to prevent users from resuming it manually.
A problem I found when implementing this is the behavior when a function never yields, e.g.:
func hello_there():
    var ret = await(oh_its_you())
    print(ret)

func oh_its_you():
    if whatever:
        await(timer, "timeout")
    return 10

In the above example, it's possible that the called method never yields, therefore await would error because it expects a value of the awaitable type that is returned by await in the called method. There are 3 possible solutions:

Make await continue without suspending if the returned type is not our awaitable type.

Cons: Allows syntax like var ret = await(10) which would be the same as var ret = 10, while the user could understand that as waiting 10 seconds.

Force the user to manually wrap the return type, e.g.: return AwaitResult(10).

Cons: Well, it forces you to wrap it.

Make the GDScript compiler or parser detect when a method can yield with await and automatically wrap the return value in such cases, so return 10 would be automatically compiled to return AwaitResult(10).

Cons: You tell me, I can't think of anything right now.

Make await continue without suspending if the returned type is not our awaitable type.
Cons: Allows syntax like var ret = await(10) which would be the same as var ret = 10, while the user could understand that as waiting 10 seconds.

Is'nt "being not a function" enough criteria to label something as "this will not be awaited"? This would be more simple to detect when parsing IMO.

No, you may want to do something like this:
var awaiter = async_method()
do_something_else()
await(awaiter)

If everything is awaitable await() may autocast the return values to AwaitResult before further processing some how? Since this seems a mandatory part of the await processing anyway I think.

That's the last point:

Make the GDScript compiler or parser detect when a method can yield with await and automatically wrap the return value in such cases, so return 10 would be automatically compiled to return AwaitResult(10).

It seems to be the best option, and shouldn't be too hard (I've got a bit more familiar with GDScript source code lately).

Is'nt there a difference between making parser guess the yielding part of code and making an autocast on return values internally while processing results inside await() function?

Yes, that one looks as the best option.
Does "when a method can yield" mean 'when a method contains at least one
call to yield()'' or the check would need to be more complex?
El 17/05/2017 a las 14:54, Ignacio Etcheverry escribió:

That's the last point:
  * Make the GDScript compiler or parser detect when a method can
    yield with |await| and automatically wrap the return value in
    such cases, so |return 10| would be automatically compiled to
    |return AwaitResult(10)|.

It seems to be the best option, and shouldn't be too hard (I've got a
bit more familiar with GDScript source code lately).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/8573#issuecomment-302080841,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCtnRPGWUhjwh9-Gmvn9xB0OFceeSYks5r6u39gaJpZM4NL0cF.

Ah, no. I'm getting it now.
Do you mean that the thing to be detected is that the method is eventually await()ed so it doesn't return until that point, don't you?

If that's the case, the await() should be in the same scope as the initial call to the async method.
You wouldn't be able to add the awaitables to an array for later processing (potentially during a future frame), for instance.
Perhaps then we should start considering marking awaitable methods with some keyword. That would be added work in the user side, but simpler than wrapping the returns.
That way, one will never forget to wrap any return point, but at the cost of less flexibility:

every return from an async-tagged method would be intended for being await()ed;
and, as a consequence, an async method cannot be used synchronously without calling await() on it immediately, but that is no big issue, IMO.

What I meant by a function that can yield with await is a like the example above:
func oh_its_you():
    if condition:
        await(timer, "timeout")
    return 10

This function can yield with await (although it only does so if the condition is met).

Here you can see an incomplete implementation of what I was talking about: https://github.com/neikeq/godot/commit/72bcc67a
Don't pay too much attention to GDFuncAwaiter and GDAwaitableResult, they are just placeholders that wrap GDFunctionState. I haven't thought of an API for a serious implementation yet (maybe the Awaitable pattern?).
You can test it with the following script:
extends Node

onready var timer = get_node("Timer")

func _ready():
    timer.start()
    print("_ready() begin")
    var ret = await(do_something()) # One parameters -> Await on awaiter
    prints("do_something() returned:", ret)
    print("_ready() end")

func do_something():
    print("do_something() begin")
    var ret = await(timer_awaiter()) # One parameters -> Await on awaiter
    prints("timer_awaiter() returned:", ret)
    print("do_something() end")
    return ret

func timer_awaiter():
    print("timer_awaiter() begin")
    await(timer, "timeout") # Two parameters -> Await on signal
    print("timer_awaiter() end")
    return 13

Apologies for the late feedback. Very busy these days.
I'll play a bit with your code, but in the meantime I can tell you this looks nice. Clean and readable.

@neikeq bump, there are build errors 😛 But you have reduz' consent 😄

Rebased

What about the discussion above though? The example I shared could be a better alternative. I'm not available to do it for 3.0 though.

I can't say, but since the current code is relatively simple and non intrusive, I guess that it could be merged and either reverted and replaced by something "better" before 3.0, or kept if everyone is happy with it.


Should rgba function behave like sass rgba function?

The rgba function that you created expects
${rgba(255, 205, 100, 0.7)} or
${rgba({ red: 255, green: 205, blue: 100, alpha: 0.7 })};
when we use it in styled-components.
I don't know, my approach might be wrong but If I use your rgba function like ${rgba('#000', 0.1)} in order to get the same css rgba(0, 0, 0, 0.1) when I use rgba function in Sass, it would be better.
I use this function to get the result that I mentioned.
const hexToRgb = (hex) => {
  // http://stackoverflow.com/a/5624139
  var shorthandRegex = /^#?([a-f\d])([a-f\d])([a-f\d])$/i;
  hex = hex.replace(shorthandRegex, function (m, r, g, b) {
    return r + r + g + g + b + b;
  });

  var result = /^#?([a-f\d]{2})([a-f\d]{2})([a-f\d]{2})$/i.exec(hex);
  return result ? {
    r: parseInt(result[1], 16),
    g: parseInt(result[2], 16),
    b: parseInt(result[3], 16),
  } : null;
};

const rgba = (hex, alpha) => {
  const color = hexToRgb(hex);
  return `rgba(${color.r}, ${color.g}, ${color.b}, ${alpha})`;
};

export const Header = styled.div `
  box-shadow: 0 0 5px ${rgba('#000', 0.1)};
`;

I wonder your ideas about it.
I look forward to use Polished in a real project.
Thanks

Interesting case. The functionality is already covered by https://polished.js.org/docs/#transparentize
To be honest I'm not sure. I thought this would not be needed, but if this is a very common case for Sass users we might want to consider supporting it.

Thanks for your thoughts Nik,
I've been asking many people around me for 2 weeks. the most common built-in functions in sass in my circle like that 1) rgba 2) lighten, darken
Additionally, I've investigate the most popular front-end libraries uses Sass,
if I compare their usage of rgba(#hex, alpha) or transparentize(alpha, #hex)

Library
rgba usage
transparentize usage

Bootstrap
>3+
0

Bourbon
>3+
0

Foundation
>3+
0

Ionic
>3+
0

Materialize
0
1

Bulma
>3+
1

Personally, I always preferred to use rgba rather than transparentize due to these reason

It is simple just 4 letters
Easy to write while setting colors #34d instead of rgba(51, 68, 221, 1)
Easy to remember hex codes
When collecting colors on Sketch or Photoshop, easy to copy to hex code and give the alpha channel
It is the same experience on Sketch or Photoshop like opacity. with Transparentize, you need subtract 1 - opacity (that you see on design application)

I do see where this would be useful, what we would need to sort out though is how this jives with what RGBA currently does for us. Would the API become a bit too confusing if it supported both this use case as well as what it currently does?

@bhough shouldn't be too crazy to do since we can match for the amount of arguments
I'm still be undecided if we want to encourage a simpler API with the explicit function or opt in for this special case …

@tolgaergin thanks a ton for the research! 🙌

@nikgraf agreed, meant more confusing as it seems to be doing two different things using the same method. If that pattern is already established, it may not be too bad to just implement it as opt in, while leaving transparentize in place.

question is: do we want this now or wait a bit longer until more people ask for it?

In the interest of getting a release out soon(ish), I would vote for us to wait. If we lacked a method for doing this it would be different, but with tranparentize, at worst it's a minor inconvenience.

sounds good!

@bhough Max was thinking about launching at React London. I tried to reach you via private message on Twitter.

Personally I always use rgba like this; rgba(#fff, .5). I think this should be supported.

I hope the polished can support multiple function like ${rgba('#000', 0.1)} or ${rgba('#cbcbcb', 0.1)} or ${rgba(200, 200, 200, 0.1)} or ${rgba(green, 0.1)}. Thank you!

@nikgraf @mxstbr I think at this point there is enough demand to warrant implementing this.

Just left a comment on the PR. We are going to merge this asap.

Found another issue with rgba and gradient functions.
This cause an error:
background-image: linear-gradient(to right, ${rgba(#DE6262, .2)}, ${rgba(#FFB88C, .2)});
Use this instead
export const linearGradient = string => {   return linear-gradient(${string}) }
Usage example:
background-image: ${linearGradient(to right, ${rgba('#DE6262', .2)}, ${rgba('#FFB88C', .2)})};
I hope someone will find this solution usefull.


Fix IPython-less mode of get_environment

Former fix was incomplete, so in environments without IPython at all, the ImportError being raised wasn't caught properly.
This PR is supposed to fix it.

Sorry for the mess...

I think it's better to isolate ImportError in a separate one. For example, if import IPython fails with a NameError (due to some environment issue or pkg_resources mess) I don't think this should just declare the environment as "terminal"...

@vmalloc This has been released in 0.0.16 🎉


Reinstate RR-R statement

The RR-R statement on https://www.europeana.eu/portal/en/rights/rr-r.html is currently not available

This is now working for me - with no intervention from me - can you please check it works from your side? I'll report the bug.

Ok.  I needed to clear my cache.  The page should be published now.  Can you check please?

yes fixed now for me as well. thanks @juliafallon


 They belong in PR #2396, which is awaiting review. This PR removes the premature files.

Codecov Report

Merging #2641 (9195f42) into master (8abebc9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2641   +/-   ##
=======================================
  Coverage   93.85%   93.85%
=======================================
  Files          86       86
  Lines        6172     6172
  Branches     1264     1264
=======================================
  Hits         5793     5793
  Misses        348      348
  Partials       31       31

Continue to review full report at Codecov.

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


Add example how to set a network policy that blocks all egress traffic by default

It would be nice to add an example to the "How it works" section that blocks egress traffic on the default namespace by default as a first step. This makes it easier to follow the tutorial.

Seems that creating one egress policy on the namespace automatically results in "block by default", so issue closed :)


Credit Report requests are failing

Describe the bug
I am unable to receive data related to credit reports.
What version of MintAPI are you using?

I tested on the current version of main
I also tested on a branch created from commit 4c0a1713dc7aa0f9691b9989d6db3834fe613490 (https://github.com/mintapi/mintapi/commit/4c0a1713dc7aa0f9691b9989d6db3834fe613490)
I also tested on a branch created from commit 56c01912309dad557bd70125645ef8af994c0382 (https://github.com/mintapi/mintapi/commit/56c01912309dad557bd70125645ef8af994c0382)

What command[s] did you run / steps to reproduce?
python3 mintapi/api.py --keyring<EMAIL_ADDRESS>--credit-report -f ./credit.json --session-path=None
python3 mintapi/api.py --keyring<EMAIL_ADDRESS>--credit-score --session-path=None
Stacktrace/error received:
Traceback (most recent call last):
  File "/Users/matthewburke/github/mintapi/mintapi/api.py", line 1451, in <module>
    main()
  File "/Users/matthewburke/github/mintapi/mintapi/api.py", line 1418, in main
    data = mint.get_credit_report(details=True)
  File "/Users/matthewburke/github/mintapi/mintapi/api.py", line 1148, in get_credit_report
    credit_report['reports'] = response.json()
  File "/usr/local/lib/python3.9/site-packages/requests/models.py", line 910, in json
    return complexjson.loads(self.text, **kwargs)
  File<EMAIL_ADDRESS>line 346, in loads
    return _default_decoder.decode(s)
  File<EMAIL_ADDRESS>line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File<EMAIL_ADDRESS>line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

What did you expect to happen?
The request was complete and save data related to credit reports.
What actually happened?
The request failed due to missing data from the response.
Additional context
This seems to be a change on the Mint side because with 56c01912309dad557bd70125645ef8af994c0382 , I was able to get results.
Additionally, it appears that a Response of 401 is received when trying to pull the data.

The JSON code means that nothing was returned in your stack trace, not even an error. It's likely that you had connection problems and never hit mint.com. This problem would seem intermittent because it worked on 56c019 but not more recent ones which shouldn't have affected your command if I understand it correctly.

@jaron-l it's isolated to this specific type of request. All others work. I've also tried several different days with the same behavior.

Got it. That does sound weird. I'll take a look.

 I'm just calling get_credit_report and asserting all the keys are there. Seems that should trigger what you're seeing. Can you confirm your sign in process worked successfully?

@jaron-l it's not that the tests are failing, it's that the response itself from the endpoint fails.  If you use the same set of commands I did at the command-line, do you get a successful response with the data?

I wrote my own small test that calls get_credit_report and asserts that the response contains all the needed keys. It is working on the endpoint mentioned. I can try the command line route but it shouldn't make a difference unless it's the way the command line sets up the Mint class.

Oh I see. I misunderstood. This is super weird. I guess I'll try again and see if I'm having the issue today.

@jaron-l Okay I figured out the key distinction.  In headless mode, the request works correctly.  I think it must be because of the cookie handling with regards to the separate URL (MINT_CREDIT_URL).  With that being said, we should either add a validation for --credit-report or --credit-score that requires the use of --headless or we need to hardcode the use of --headless with either of these scenarios.  I'm inclined to say the former.
@mrooney I'm curious your thoughts on the above as well.

I would think we should investigate whether there is a way to make it work in GUI mode before we rule it out.

I was able to reproduce this today. I think the best way to handle this might be to do it the same way that seleniumrequests merges the cookies from different domains. We probably need to be using seleniumrequests to manage the cookies for the credit endpoint anyways because that is the whole reason that we use it in the first place. I'll continue to look into this. Hopefully there's a way to manage the two different domains.

@jaron-l let me know if you want me to look into anything with it as well.


add llm_bench to openvino.genai

update to llm.bench 2df32ee59df7e2e9c566e171d2d5f125039f92a5

@wgzintel @peterchen-intel @xipingyan  I'm not sure that directory name is correct. llm/cpp used for demo pipeline in c++, it supposes that python directory content will be the same, just in python (sounds misleading and do not permit to provide the same content like in c++ for python), maybe better to move it in separated directory, like llm_bench/python?


Update version

Closes #180

Codecov Report

Merging #213 (7d257b2) into master (35bc97d) will not change coverage.
The diff coverage is 0.00%.

@@            Coverage Diff            @@
##             master     #213   +/-   ##
=========================================
  Coverage     51.12%   51.12%
  Complexity      616      616
=========================================
  Files           118      118
  Lines          2707     2707
  Branches        322      322
=========================================
  Hits           1384     1384
  Misses         1224     1224
  Partials         99       99

Impacted Files
Coverage Δ

src/main/java/seedu/address/MainApp.java
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Exasol 6.2 Beta

Hi
Do you have already plans for releasing a Exasol 6.2 Beta release. Background are the lockfree metadata queries which we like to try as we assume this will fix some of our failing regression tests.
Thanks
Regards
Petr

"Lock-free" snapshot transactions are available in earlier Exasol versions.
It's not officially documented, but uou may try to use it and see how it goes: https://github.com/badoo/pyexasol/blob/master/docs/SNAPSHOT_TRANSACTIONS.md

Thank you for the advise. I assume so it will be available in the 6.1.3 container?
But as we currently mix read and write operations. Is there an option also to change the isolation level within a active connection?  (I think something like in other databases: SET TRANSACTION ISOLATION LEVEL xyz?

In theory, you may switch snapshot_transaction ON and OFF using direct .set_attr() calls. But I strongly advise against doing so, since potential side-effects are unknown.
It's a good idea to open separate connection and use it for meta-requests only.

https://github.com/exasol/docker-db/releases/tag/6.2.0-d1


ak.to_numpy(ak.Array([[], [], []])) should return an array of shape (3, 0), not (0, 0)

Version of Awkward Array
HEAD
Description and code to reproduce
>>> ak.to_numpy(ak.Array([[], [], []]))   # should have shape (3, 0)
array([], shape=(0, 0), dtype=float64)

It's probably not setting the zeros_length argument when converting the ListArray or ListOffsetArray into a RegularArray. It's possible to express such an array:
>>> shape30 = ak.Array(ak.layout.RegularArray(
...     ak.layout.NumpyArray(np.array([])),
...     size=0,
...     zeros_length=3,
... ))
>>> shape30
<Array [[], [], []] type='3 * 0 * float64'>

... or maybe the outer length is being lost later in the process, because look at this:
>>> ak.to_numpy(shape30)
array([], shape=(0, 0), dtype=float64)

Anyway, it's probably an easy fix, once we know where the outer length is being lost.

@jpivarski - I wanted to check if this is still the case in v2 and stumbled an another issue with EmptyArrays in v2:
>>> array = ak._v2.highlevel.Array([[], [], []])
>>> ak.to_list(array.layout.toRegularArray())
[[], [], [], []]
>>> array = ak._v2.highlevel.Array([[1], [2], [3]])
>>> ak.to_list(array.layout.toRegularArray())
[[1], [2], [3]]
>>> array = ak.Array([[], [], []])
>>> ak.to_list(array.layout.toRegularArray())
[[], [], []]

For more detail, here's where ListOffsetArray.toRegularArray is going wrong:
>>> array = ak._v2.highlevel.Array([[], [], []])
>>> array.layout
<ListOffsetArray len='3'>
    <offsets><Index dtype='int64' len='4'>[0 0 0 0]</Index></offsets>
    <content><EmptyArray len='0'/></content>
</ListOffsetArray>
>>> array.layout.toRegularArray()
<RegularArray size='0' len='4'>
    <content><EmptyArray len='0'/></content>
</RegularArray>

The length of the ListOffsetArray is 3, but the length of the RegularArray is 4.
Here's the new Python code with the error:
https://github.com/scikit-hep/awkward-1.0/blob/7705900c44db2ced202ae61ce605f9d7ea536f4a/src/awkward/_v2/contents/listoffsetarray.py#L159-L165
The length of the RegularArray that gets returned should be len(self) or len(self._offsets) - 1 (because offsets are one longer than the ListOffsetArray itself).
Here's the original C++ code that it was translated from:
https://github.com/scikit-hep/awkward-1.0/blob/7705900c44db2ced202ae61ce605f9d7ea536f4a/src/libawkward/array/ListOffsetArray.cpp#L383-L387
This uses length(), a function that doesn't exist in the Python version but means len(self). That's how the error was made.
@ianna Are you working on something where it would be easy to include this fix, or should I?

@ianna You already fixed it in #1150 (which I'm reviewing right now). Exactly this fix is included in the diff.
We should keep this issue here because it was for a different problem, the to_numpy shape issue. (Or is that handled by #1150? I'll check. Nope; the issue is still there in ianna/to_numpy, at the time of writing.)


Program Management fields

In the Program Management, when we edit details for program, there are several fields that say None. It should be empty

 Program Management fields


Add Askar and Askar JavaScript repos and teams

Signed-off-by: Stephen Curran<EMAIL_ADDRESS>

Do you intend to create a new repo askar-javascript?