2.8.0 Python client library for Mac OS Big Sur won't load due to absolute linker paths left over from build environment

Describe the bug
The compilation of the Python binary artifact for the 2.8 client library appears to have been performed incorrectly. The client currently tries to dynamically link against libraries that don't exist, which causes import pulsar to fail.
The library has static (absolute) linker paths baked in which appear to correspond to paths that were only present on the environment on which the current distribution of the binary was originally compiled before being uploaded.
To Reproduce
Steps to reproduce the behavior:

On Mac OS Big Sur, create a python environment using either Python 3.8 or Python 3.9 (I've reproduced on both). I used pyenv for 3.8, and Homebrew for 3.9.
In that environment, do pip install pulsar-client==2.8.0
Launch python and run import pulsar
See error:

>>> import pulsar
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/user/.pyenv/versions/zac37/lib/python3.7/site-packages/pulsar/__init__.py", line 103, in <module>
    import _pulsar
ImportError: dlopen(/Users/user/.pyenv/versions/zac37/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so, 2): Library not loaded: /Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/openssl-1.1.1k-vh6zdk5wa6z2api2aadok7syaaft6b5z/lib/libssl.1.1.dylib
  Referenced from: /Users/user/.pyenv/versions/3.7.10/envs/zac37/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so
  Reason: image not found

Expected behavior
A clear and concise description of what you expected to happen.
Desktop (please complete the following information):

OS: Mac OS Big Sur

Additional context
The error is caused by absolute (rather than relative) linker paths:
 % otool -L /Users/user/.pyenv/versions/zac37/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so
/Users/andris.cakuls/.pyenv/versions/zac37/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so:
    @rpath/_pulsar.so (compatibility version 0.0.0, current version 0.0.0)
    /Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/curl-7.76.1-svdal2fl5lmbov7ilaupyceiovahyixw/lib/libcurl.4.dylib (compatibility version 12.0.0, current version 12.0.0)
    /Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/openssl-1.1.1k-vh6zdk5wa6z2api2aadok7syaaft6b5z/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
    /Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/openssl-1.1.1k-vh6zdk5wa6z2api2aadok7syaaft6b5z/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
    /Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/zlib-1.2.11-xflsouiaysa3uizi6mjcwhv54aa5m6kd/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
    @rpath/libzstd.1.dylib (compatibility version 1.0.0, current version 1.5.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)

Looks like it's published with dynamic linking, I will try and publish new
versions with static linking.
-Ali
On Fri, Jul 2, 2021 at 2:15 PM Zac Bentley @.***> wrote:

Describe the bug
The compilation of the Python binary artifact for the 2.8 client library
appears to have been performed incorrectly. The client currently tries to
dynamically link against libraries that don't exist, which causes import
pulsar to fail.
The library has static (absolute) linker paths baked in which appear to
correspond to paths that were only present on the environment on which the
current distribution of the binary was originally compiled before being
uploaded.
To Reproduce
Steps to reproduce the behavior:

On Mac OS Big Sur, create a python environment using either Python
3.8 or Python 3.9 (I've reproduced on both). I used pyenv for 3.8, and
Homebrew for 3.9.
In that environment, do pip install pulsar-client==2.8.0
Launch python and run import pulsar
See error:

import pulsar
Traceback (most recent call last):
File "", line 1, in
File "/Users/user/.pyenv/versions/zac37/lib/python3.7/site-packages/pulsar/init.py", line 103, in
import _pulsar
ImportError: dlopen(/Users/user/.pyenv/versions/zac37/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so, 2): Library not loaded: /Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/openssl-1.1.1k-vh6zdk5wa6z2api2aadok7syaaft6b5z/lib/libssl.1.1.dylib
Referenced from: /Users/user/.pyenv/versions/3.7.10/envs/zac37/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so
Reason: image not found

Expected behavior
A clear and concise description of what you expected to happen.
Desktop (please complete the following information):

OS: Mac OS Big Sur

Additional context
The error is caused by absolute (rather than relative) linker paths:
% otool -L /Users/user/.pyenv/versions/zac37/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so
/Users/andris.cakuls/.pyenv/versions/zac37/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so:
@rpath/_pulsar.so (compatibility version 0.0.0, current version 0.0.0)
/Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/curl-7.76.1-svdal2fl5lmbov7ilaupyceiovahyixw/lib/libcurl.4.dylib (compatibility version 12.0.0, current version 12.0.0)
/Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/openssl-1.1.1k-vh6zdk5wa6z2api2aadok7syaaft6b5z/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/openssl-1.1.1k-vh6zdk5wa6z2api2aadok7syaaft6b5z/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/Users/admin/spack/opt/spack/darwin-bigsur-skylake/apple-clang-12.0.0/zlib-1.2.11-xflsouiaysa3uizi6mjcwhv54aa5m6kd/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
@rpath/libzstd.1.dylib (compatibility version 1.0.0, current version 1.5.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/pulsar/issues/11203, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5DK7JE46MHE7Q7JAKXFALTVYT5PANCNFSM47XMHHVQ
.

--
-Ali

Hi, it would be really great if you could fix this @aahmed-se , I can find no way to install any version of the python client on mac currently. Building from source and old versions all fail for different reasons. This seems to be the easiest path to fix.

I have the same problem. Any chance for a quick fix to this issue?

Bump. Not to be annoying, but having the latest client library for the 2nd most popular programming language in the world fail to link/load is probably a blocker for many folks.
If it helps, I'm happy to compile and supply properly linked versions of the library to any Pulsar package maintainers if that would expedite a fix here.

The issue is pypi does not allow overriding of published versions. We will have to wait for the next release tag to be created.

Could a pre-release version be created in PyPi as a workaround? Or perhaps a non-semver tag (e.g. 2.8.0-1)?

The issue is pypi does not allow overriding of published versions.

Have you tried to publish the corrected package as a post-
release (e.g. 2.8.0.post1)?
https://michaelgoerz.net/notes/inter-release-versioning-recommendations.html#release-versioning

We have the same issue with the 2.7.2 version. Any chance to publish a fixed version for this issue?

@sijie and @aahmed-se , something that may add a little more color to this issue: the Pulsar Python client library is very hard to build from source, so having working wheels is unusually important for folks who want to talk to Pulsar from Python.
To wit: neither I nor any of my coworkers, with workstations across several years' worth of OSX editions and Linux distros, have been able to effectively build this package from source on our first try. On our production servers we eventually got a build that worked, but our workstations--especially our OSX ones--remain on various editions because of the difficulty satisfying different constellations of OpenSSL/grpc/zlip/etc. dependencies.
This isn't uniquely a Pulsar issue--Python packages with compiled components are just notoriously awful to build on OSX in general, and the fault for that lies with the ecosystem, not this project in any way--but it is within the Pulsar maintainers' ability to easily fix by providing a range of working binary wheels so folks don't have to BFS.
This is complicated by the fact that folks often need versions built against many different combinations of (python version, OS version, library version). For example, I was able to get 2.8.0 BFS working on my Mac against 3.7.7 in an hour of fiddling/environment setup, but python 3.9 and higher hit inscrutable compilation issues in transitive dependencies pretty quickly.
I am happy to volunteer a day or two of my time to build wheels on various OSX versions (I run a few in virtual machines) and supply them, or the steps to build them, if that would help. Anything I can do here?

Please list the pulsar / os / python versions people need I will build then and host is a seperate github repo as downloadable artifacts.

The new 2.8.0.post0 version is properly built and I am able to link against it successfully on OSX on the versions used for development at my company.
I can't speak for all linux, but our debian/ubuntu installs also work with that wheel.
Thanks so much @aahmed-se! From my end, no further action is needed on this issue, though I cannot speak to others in this thread.
(chariot) zac.bentley@ZacBentleyMBP ~/Desktop/Projects/Klaviyo/chariot ∴ otool -L /Users/zac.bentley/.local/share/virtualenvs/chariot-eiENY2kt/lib/python3.9/site-packages/_pulsar.cpython-39-darwin.so
/Users/zac.bentley/.local/share/virtualenvs/chariot-eiENY2kt/lib/python3.9/site-packages/_pulsar.cpython-39-darwin.so:
	@rpath/_pulsar.so (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)

The version 2.8.0.post0 works for me also (tested on Mac). Thx.

With an N of several (folks posting here, colleagues, peers) all successfully using the latest 2.8.0.post0 PyPi release on several MacOS versions, I'm going to close this issue--I filed it, if that's a violation of triage procedure for this project please reopen.

The new 2.8.0.post0 release does not contain a wheel for many Linux, breaking dockerized application that uses the python pulsar client. Are you aware of this issue?


Set iOS deployment target to 6.0, fixes compilation errors

Fixes https://github.com/flutter/flutter/issues/21363.

Just a curiosity question: Why is the deployment target being set so low? iOS 6.0 is very, very old and the user base right now is very low ( https://data.apteligent.com/ios/ ).
However, my major concern right now is that using such a low deployment target may prevent us from adopting modern APIs and development practices. Apple deprecates so many APIs between major releases that we may also be at risk of using something they are no longer allowing to be used in apps.

Short answer: I used what is already set in cloud_firestore plugin.
Long answer: I’m not too familiar with how pods resolve this thing. :)
It looks like without it xcode thinks it supports 5.0 and fails to compile. Note that per Firebase dev answer here https://stackoverflow.com/questions/31076786/error-while-compiling-firebase-based-project-in-objective-c 6.0 is the lowest supported by the sdks.
When I run pod update it prints in the end something like “setting deployment target to 8.0”, do this setting probably works more like minimum supported target?
I’m just thinking out loud though and someone with more experience should weigh in.
Nevertheless this fixes the issue at least.

@ahmedb
From this page in official docs: https://guides.cocoapods.org/syntax/podspec.html#deployment_target

The minimum deployment targets of the supported platforms.

So I guess it does work as >=.

Hi @pulyaevskiy,
Thank you for your notes. I hope someone else can chime in too.
From my personal experience (iOS dev since 2009, former iOS instructor, Cocoapods user since 2013), deployment_target is meant to set the deployment target for the iOS framework generated by the Pod. The deployment target setting in XCode sets the minimum system version the framework can run on, and limits the available APIs to only those available between that minimum setting and the latest version of iOS.
In other words, only allow compilation for APIs that are available on all iOS SDK versions from 5.0 up through 12.0. This excludes all APIs that were introduced after iOS 5.0, as well as all APIs that were deprecated since iOS 5.0 was initially released.
When I was looking at the Runner project Flutter generates, I noticed its deployment target is set to 8.0 . Although I personally think this is also too low, I think it would be a good experiment to see if setting the deployment target to 8.0 has the same result as your changes from setting the version to 6.0 .
Unless there is a bug, Cocoapods should print out setting deployment target to 6.0 if the podfile is configured correctly. There are two quick experiments I think might be good to try out to see what is happening.

Manually specify the the platform is iOS to see if that sets the target correctly (The platform line for most podfiles look like this: platform :ios, '9.0')
Set the deployment target to 11.0 to see if it that prints out setting deployment target to 11.0. It may be the case that Cocoapods does not support iOS 6.0 .

This may be of some help as well: https://github.com/CocoaPods/CocoaPods/issues/7314#issuecomment-356192161
One last comment, Apple sent shockwaves through the iOS community when they released iOS7 and then again when they released Swift with iOS8. iOS7 ushered in the modern iOS UI, and Swift greatly changed the development workflow for iOS (some may say the dust still hasn't settled from either yet.)
Thanks,
Ahmed

Thanks for thorough explanation! This is really helpful.
As a side note, It'd be ok with me to change it to as high a number as makes sense to people more experienced in iOS development.
But, I also think that changing it in just one Firebase plugin of many won't make a big difference. To address the "deployment target" issue we should probably update all of them at once.
I created this PR to address a different blocking issue - adding cloud_functions to an existing project completely breaks it, it just won't compile otherwise. I'd probably prefer to keep it small so that it can be merged sooner and unblock people's work.
That said, I do see value in your suggestions, however my expertise is simply not enough to tackle such a project. I can only encourage you submit a separate PR with updates to deployment targets across all Firebase plugins. This would at least facilitate discussion with the Flutter team and help to resolve it sooner.

Also a friendly ping to @kroikie for a chance to get this reviewed. :)

Thanks @pulyaevskiy . Sounds like a good plan.

Flutter only supports iOS 8.0 and above so there would be no point in setting the deployment target to anything below 8.0: https://flutter.io/ios-release/#review-xcode-project-settings

@pulyaevskiy, CocoaPods together with a line of code in Swift anywhere (in your app or in a dependency) will mechanically require framework support (or the newer CocoaPods 1.5.x with Swift static lib support) and iOS 8+ support. So in order to have the older targets iOS 7 (or iOS 6) supported, one prerequisite would be to have a pure Objective-C app (including all your pods). That's not a popular audience; it's better to encourage Swift+CocoaPods compatibility and have everybody say goodbye to iOS 7 or older.
The next big upcoming goodbye will be 32 bits apps (both on iOS and macOS).

Just pushed a fix for null pointer error when callable function fails with exception.
Also friendly reminder for @kroikie . Would be nice to get this merged and remove dependency override finally. :)

I've stumbled onto this error too. Could we please get this pull request merged @kroikie?

dispatch_queue_t callbackQueue;
This error is still present: https://github.com/flutter/flutter/issues/21363

dispatch_queue_t callbackQueue;
This error is still present: flutter/flutter#21363

Does using my above recommendation fix that for you?

Yes if I manually go to cloud functions / firestore plugin podspec and change deployment target to 8.0 and reinstall pods it works.
ie. I still dont understand why this is not by default set to at least 8.0


Close row when another row starts to swipe

On the built-in apps on iOS (like Mail), when a row is swiped open to show the Delete action, any touch outside the Delete action causes the currently open row to close.
I would like to achieve a similar behavior. I'm not sure how we could capture the touch on "any touch outside the Delete action", but I think we could better simulate that by closing the row if another row is touched (not just a full press).
Is there a way to detect a touch on another row and subsequently close the open row?

Hey @davideweaver, if I understand your comment correctly this should be the default behavior of this component. Here is how the example behaves when touching either the open row or any other row:

Is this not what you are looking for?

Hey @davideweaver, good suggestion! I've added a prop that I think will do what you're looking for. In the next release (which will be later today) set the closeOnRowBeginSwipe prop equal to true to achieve this behavior:

If this isn't what you were looking for please reopen and let me know, thanks!

Yes. That models the behavior for Apple apps. Thanks!
On Mar 5, 2017, at 5:11 PM, Jesse Sessler <notifications<EMAIL_ADDRESS>wrote:
Hey @davideweaverhttps://github.com/davideweaver, if I understand your comment correctly this should be the default behavior of this component. Here is how the example behaves when touching either the open row or any other row:
[https://camo.githubusercontent.com/232e95708b4d25ddae28bfa21c703ac9f4c9181c/687474703a2f2f672e7265636f726469742e636f2f4851764a3239426334672e676966]https://camo.githubusercontent.com/232e95708b4d25ddae28bfa21c703ac9f4c9181c/687474703a2f2f672e7265636f726469742e636f2f4851764a3239426334672e676966
Is this not what you are looking for?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/jemise111/react-native-swipe-list-view/issues/98#issuecomment-284267327, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAtAHeipPT0ni58u9BWKXNtVnCjqG_cvks5rizL4gaJpZM4L7-q7.


Time to set 0.17.60 default

0.17.x branch has been the current stable version of Factorio for a long time now. Experimental is on 0.18 and will become the new 1.0. Almost nobody plays 0.16.x anymore, and by doing this change the site will be already set when the 1.0 arrives.

Nevermind, duplicate https://github.com/KirkMcDonald/kirkmcdonald.github.io/issues/185


Scope not accessible in libcnb 0.4.0

The existing ruby example works, but if you change the toml to point at the released version instead of what's on disk:
$ cat Cargo.toml
[package]
name = "example-02-ruby-sample"
version = "0.1.0"
edition = "2021"
rust-version = "1.56"

[dependencies]
flate2 = "1"
ureq = "2.2.1"
sha2 = "0.10"
tar = "0.4"
toml = "0.5"
tempfile = "3"
libcnb = "0.4.0"
serde = "1.0.126"

You get an error:
$ cargo build
   Compiling libcnb-data v0.3.0
   Compiling libcnb v0.4.0
   Compiling example-02-ruby-sample v0.1.0 (/Users/rschneeman/Documents/projects/work/libcnb.rs/examples/example-02-ruby-sample)
error[E0432]: unresolved import `libcnb::layer_env::Scope`
 --> examples/example-02-ruby-sample/src/main.rs:7:5
  |
7 | use libcnb::layer_env::Scope;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^ no `Scope` in `layer_env`

error[E0432]: unresolved import `libcnb::layer_env::Scope`
  --> examples/example-02-ruby-sample/src/layers/ruby.rs:12:57
   |
12 | use libcnb::layer_env::{LayerEnv, ModificationBehavior, Scope};
   |                                                         ^^^^^ no `Scope` in `layer_env`

For more information about this error, try `rustc --explain E0432`.
error: could not compile `example-02-ruby-sample` due to 2 previous errors

This is expected - TargetLifecycle was renamed to Scope in #257, which has not yet been released.
You either need to use libcnb from main with the examples from main, or libcnb 0.4.0 with the examples from 0.4.0:
https://github.com/Malax/libcnb.rs/tree/v0.4.0/examples/example-02-ruby-sample
Obviously not ideal that the examples from main don't work with the latest published release as-is, but its the tradeoff for having the example exercise our latest code. In general once the number of libcnb breaking changes settles down, this situation shouldn't arise very often :-)

Thanks josh and I figured this out almost the exact same time. Is there a milestone for 0.4.1 or is there anything preventing releasing what's on main?

#257 landed yesterday (you were one of the reviewers requested fwiw), so it's not been waiting long.
I think we're waiting on 1-2 more PRs that are breaking (eg #243 and #265), but otherwise were wanting to release soon.


Test: Search Contributions Cleanup

Refs #162858

[x] anyOS @isidorn
[x] anyOS @rebornix
[x] anyOS @lramos15

Complexity: 1
Create Issue

Background
I recently cleaned up the code in for the search contributions and search actions and I just wanted a sanity check to make sure that everything still works since it was a a heavy overhaul.
Set up:
Have the newest version of insiders installed.
Testing:
You can pick some random commands to test out. There are multiple ways to test the commands, but this list should cover a common way to trigger each of them and a short explaination of what they do.
Testers don't need to complete the testing of all of the commands; I just have it here so that people know what commands they can test. It'd be awesome if people could check off the ones they've tested so that there's some variety in what commands are tested, though! 😊
Command list
Basic search results navigation commands:

[ ] Using action buttons to replace/remove

[ ] enter when focused on a match to open the file and focus on the opened file
[ ] ctrl+enter when focused on a match to open the file to the side and focus on it.
In context menu when right-clicking a search result entry:

[ ] "Copy" - copies the currently focused search result to clipboard
[ ] "Copy All" - copies all of the selected results to clipboard
[ ] "Copy Path" (only for file or folder entries in the search result) - copies path of file or folder to clipboard
[ ] "Reveal in File Explorer" (only for file match) - reveals file in File Explorer viewlet
[ ] "Restrict Search to Folder" (only in folder match) - adds path to "files to include"
[ ] "Exclude Folder from Search" (only in folder match) - adds path to "files to exclude"

In context menu when right-clicking an explorer entry:

[ ] "Find in Folder..." - add this folder to "file to include" in the search viewlet.

Command palette

[ ] "Search: Find in Files" - opens the search viewlet
[ ] "Search: Replace in Files" - opens the search viewlet with the replace field revealed
[ ] "Search: Focus List" - focuses on the list of search results in the viewlet
[ ] "Search: Focus on Next Search Result" / "Search: Focus on Previous Search Result" - toggling between matches in search viewlet

Keybindings:

[ ] ctrl/cmd + shift + J to toggle the files to include/exclude fields
[ ] escape when focused in the "replace" output hides it
[ ] ctrl/cmd + shift + L when selecting multiple results to add cursors to all of them
[ ] ctrl + up/down when focused on search input fields to toggle between them. Note that the ctrl+up when focused on the list of results to go back to the inputs only works when you're focused on the top result.

Top bar buttons:

[ ] refresh, clear search results, open in search editor, treeview/listview toggle, and collapse/expand.

Etc:

[ ] using "#" in command palette to do a workspace-wide symbol search

I tested on macOS. Works great. I did not know all of this functionality - so thanks for the learning.
The only thing I find weird is cmd + up/down to navigate between input boxes. Do we use this pattern anywhere else in our UI? Is there some more common pattern we can use to pass focus between input fields so that the search view aligns with the other accessibility pattern we have in VS Code?

"Copy All" - copies all of the selected results to clipboard

This copies all for me not just the selected ones

I tested on macOS. Works great. I did not know all of this functionality - so thanks for the learning. The only thing I find weird is cmd + up/down to navigate between input boxes. Do we use this pattern anywhere else in our UI? Is there some more common pattern we can use to pass focus between input fields so that the search view aligns with the other accessibility pattern we have in VS Code?

I'm actually not too sure! This has been what it's been like before, but I notice that it's sort of similar to how to move down to the extension list? But strangely, that one doesn't toggle back up with ctrl+up.

"Copy All" - copies all of the selected results to clipboard

This copies all for me not just the selected ones

Oops, yes, that's the intended effect.

Search: Focus List

What's the difference between this and Focus View? They seem to do the same thing for me

Search: Focus List focuses on the list of results regardless of where you were last focused when you were on the search view.
'Search: Focus on Search View` focuses on the search view wherever you last focused.


[NEW ICON] Digital Ocean

Skill Name
Digital Ocean
Why?
its a popular cloud hosting platform
Reference Image

Hey there, if you want, you can also make the request on the new rolling release community driven skill icons repository which has been rewritten in go for better performance.
Since the maintainer of this repository did not show up in months... https://github.com/lelouchfr/skill-icons

Up


fix: do not flood dictionary with data dependent on fuzz inputs

Motivation
Currently data collected during individual fuzz/invariant run (e.g. logs, storage writes) persists in fuzz dictionary resulting in large dictionary sizes due to it being flooded by data dependent on fuzz inputs. In #7551 case it resulted in dictionary accumulating log topics which directly contained fuzz inputs thus decreasing a chance of picking actually useful value from push byte as a fuzz input.
Solution
For fuzz tests we now don't call collect_state_from_call at all making calldata choice completely stateless.
For invariant tests I've refactored EvmFuzzState to keep track of all newly added keys and an option to remove them via revert fn. Thus, on invariant runs we accumulate and persist dictionary between separate calls, but it is getting cleared after each invariant sequence run.
Setters now also don't let dictionary size to grow beyond configured limit which didn't really work before
Results
This does not directly resolv #7551 because in this exact case fuzz-test has a structure with many branches and a chance to reach a branch which should've caused failure is relatively low because most of the runs are getting caught earlier.
For the sake of experiment let's remove some of the branches to increase chance of hitting this exact failure:
function test_initialize(PoolKey memory key0, uint160 sqrtPriceX96) public {
    vm.assume(key0.currency0 < key0.currency1);
    vm.assume(!key0.fee.isDynamicFee());
    key0.tickSpacing = int24(bound(key0.tickSpacing, manager.MIN_TICK_SPACING(), manager.MAX_TICK_SPACING()));

    // Assumptions tested in Pool.t.sol
    sqrtPriceX96 = uint160(bound(sqrtPriceX96, TickMath.MIN_SQRT_RATIO, TickMath.MAX_SQRT_RATIO - 1));

    // tested in Hooks.t.sol
    key0.hooks = IHooks(Constants.ADDRESS_ZERO);

    if (
        (key0.fee & SwapFeeLibrary.DYNAMIC_FEE_FLAG == 0) && (key0.fee & SwapFeeLibrary.STATIC_FEE_MASK >= 1000000)
    ) {
        vm.expectRevert(abi.encodeWithSelector(SwapFeeLibrary.FeeTooLarge.selector));
        manager.initialize(key0, sqrtPriceX96, ZERO_BYTES);
    } else {
        vm.expectEmit(true, true, true, true);
        emit Initialize(key0.toId(), key0.currency0, key0.currency1, key0.fee, key0.tickSpacing, key0.hooks);
        manager.initialize(key0, sqrtPriceX96, ZERO_BYTES);

        (Pool.Slot0 memory slot0,,,) = manager.pools(key0.toId());
        assertEq(slot0.sqrtPriceX96, sqrtPriceX96);
        assertEq(slot0.protocolFee, 0);
    }
}

On latest nightly, forge is not able to catch a revert after 100.000 runs.
On this PR's version, revert is catched on 9261 run.
This benchmark is dependent on exact test and seed and this is kind of an edge case as this test suite results in 7000 push bytes being pre-collected after setUp, but I believe that cleaning up fuzz dictionary is reasonable anyway.

this rang a bell re https://github.com/foundry-rs/foundry/issues/7462 which I cannot reproduce with this PR anymore

I used PoC https://github.com/foundry-rs/foundry/issues/3607#issuecomment-2028112917 to collect and visualize some stats on test_initialize (revert caught locally after 25098 runs), it can be seen that with PR there are less unique values (as dictionary not flooded) and number of times a fuzzed value is picked better distributed than without PR, attaching here, hope it makes sense

Without PR
With PR

hey @grandizzy thanks! an aside: how are you getting these metrics? I think you dropped the info in another issue or PR, but we should document further

hey @grandizzy thanks! an aside: how are you getting these metrics? I think you dropped the info in another issue or PR, but we should document further

hey, tagged you in the metrics issue https://github.com/foundry-rs/foundry/issues/3607#issuecomment-2034801713


Binding issues when port is in use

Hi,
kubefwd reports ERROR: unable to listen on any of the requested ports: [{80 80}] if the port is already in use and bound to <IP_ADDRESS>:80.
This is the output of netstat -a before running kubefwd:
Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    <IP_ADDRESS>:80             DESKTOP-5VE6KMP:0      LISTENING
...

The listening service is the nginx ingress service. Running kubefwd services now returns the unable to listen error.
If I drop the nginx ingress service, run kubefwd, and then create the service again, I get this output from netstat -a:
Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    <IP_ADDRESS>:80             DESKTOP-5VE6KMP:0      LISTENING
...
  TCP    <IP_ADDRESS>:80          DESKTOP-5VE6KMP:0      LISTENING
...

This is the desired result, and it would be awesome if kubefwd was somehow able to bind to the custom ip's without depending on whether the port is already publicly bound.

@rmja, unfortunately, there is no workaround from the perspective of kubefwd. When you bind to <IP_ADDRESS> you are actually binding to all IPv4 addresses on the local machine. kubefwd sets up and uses a variety of local IP address in order to bind the same port, for example, web-service-a:80, web-service-b:80 use local IPs like <IP_ADDRESS> and <IP_ADDRESS>. However, binding a port to <IP_ADDRESS> means binding it to <IP_ADDRESS>, <IP_ADDRESS> and <IP_ADDRESS>, etc.
Rather than use <IP_ADDRESS> for your local nginx, try using '<IP_ADDRESS>`.
Hope this helps.


ci(e2e): add matrix to run for multiple versions

What PR title says :P In preparation to run E2E tests on multiple Angular versions, we add a matrix strategy to the E2E job in the E2E GitHub Workflow

Current dependencies on/for this PR:

main

PR #39   👈

This stack of pull requests is managed by Graphite.


LuckPerms PlaceHolder error

Hey 😄 I have a problem with variables
i have a rank vip+8 and plugin FeatherBoard, LuckPermsMVdWHook
The problem is that the variable does not work because of the character "+"
variables: {luckperms_group_expiry_time_vip+8}
Could this be corrected?

This is an issue with MVdW placeholders, not LP.


Allow to supress warnings for sanity checks

Enhancement
Description
Changes confg.exit_on_failed_sanity_checks that uses a boolean, to config.on_failed_sanity_checks with three options :exit, :warn, :ignore
Some people were seeing the warning on test runs, which can be annoying especially if you are working with TDD. So it would be better to provide an opt out possibility.
Checklist

[x] My code follows the style guidelines of this project
[x] Checks (StandardRB & Prettier-Standard) are passing
[x] This is not a documentation update

Here this was reported as an issue: https://discord.com/channels/629472241427415060/733725826411135107/773114004666318858

One thing that is self-evident from the conversations with both AbuMareBear and Dave Sanders is that there absolutely needs to be a section in the documentation on setting up the Rails test environment so that it can work with the same general configuration used in development. Any actual testing, whether with minitest, RSpec or "does the witch float" could follow.
I am concerned that we are optimizing to minimize the annoyance of folks who (innocently and benevolently) haven't set up their test environments. It stands to reason that if they follow some basic, one-time steps, they won't be plagued with errors. Right?

Make sure you're running Redis
Configure Gemfile with redis and hiredis
Configure test environment of cable.yml similar to development
Update test.rb environment to set cache_store and enable action controller caching
Make sure redis server connection details are available via env or credentials

ANYHOW. 😀
I really like the implementation you've come up with. I could be crazy but what you call :warn could be anything that isn't :ignore or :exit, right? Like literally any other value?
I'm glad that we're still defaulting to :exit, which I read as "warn, then exit" - right?
I am going to make a tiny non-functional tweak to the error message to point to the correct location.

I really like the implementation you've come up with. I could be crazy but what you call :warn could be anything that isn't :ignore or :exit, right? Like literally any other value?

Would be fine for me, but you never know what the future holds. I almost thought to treat everything but :exit and :warn as :ignore, as this would have allowed for this: .conig.on_sanity_checks = :crickets :-)

What do you think? Too much?

@leastbad Nah, that's nice to offer such clear information. I like it.


stereo_gui and zoom all images to same region

stereo_gui does not create GCP correctly when view-all-images-to-same-region is on.

Fixed by ef1aa23


Use cards instead of raw text for leaderboards

see https://github.com/pinano-discord/Pinano-Discord-Bot/blob/master/assets/overall_leaderboard.png
and https://github.com/pinano-discord/Pinano-Discord-Bot/blob/master/assets/weekly_leaderboard.png

So the real question is - do we want to actually do this? Jimp doesn't seem to support Unicode which means that the leaderboard is just going to have "?????" for Unicode usernames.

I feel like we don't have that many people with names like that and its really up to them that theyre not showing on the leaderboard. They can always swap back to a normal character username if they want to be shown on the leaderboard again with their name.

A unicode font would be the best solution, I think. Basically we have a situation where Discord supports unicode but jimp doesn't. So when we moved p!stats to an image, we lost unicode support. If we could avoid ripping out unicode support for the leaderboard too it'd be preferable - the last thing I really want to try to do is figure out what sequence of question marks represents which user.

Note for anyone reading back:
Fixing #53 will fix this issue

See discussion in #78

Problem solved a different way.


Ziomon exit status

This is part of the Ubuntu package. Original patch by IBM from Launchpad.

Hello! This problem was already discussed and solved by commit 69199219bc89d28d06df4f6b3b0d0ca8279efada

ah! excellent.


request sepolia and Goerli Testnet funds.

Hello @pk910! Sorry for bothering you.

I am running dapss on the Goerli network, I need an amount of native ETH tokens on the Goerli network to test the project.
And I read ethereum's documentation that the Goerli Testnet will be shut down at the end of this year, and will migrate to the sepolia network. Can I get ETH on sepolia and prepare for the upcoming switch?

Can I get 5k ETH for Goerli network and 10k ETH for sepolia network?
Thank you very much!
This is my master wallet address:
0xaE456c40Cf4304528235a4f1c4522A25977Fd530

be careful, this is fake, this guy needs huge funds to sell don't send it to him! @pk910 @q9f

It's always the same when people don't provide a proper reason what they need these funds for...
I don't even try to verify it anymore 🤣
"run dapps" is basically the standard explanation everyone uses.. But there is really no need for thousands of eth for deployment 🤷♂

Oh! Can we sell ETH under testnet?
So maybe I know the reason why ETH testnet is so rare.
Actually for the ETH I request, I will distribute ETH under test net to users for a long time to attract potential customers. But if it is valuable ETH and not free ETH for developers then maybe I should stop this issue here.
Anyway, thank you so much for your feedback!

It should be free for everyone... That's actually the intention of having testnets.
Unfortunately there are lots of guys that abuse the goodwill of fund distributors / attack faucets etc to make testnet funds rare and valuable an can therefore sell their stack for own profit...
Too bad that this actually got kind of a business model and prevents us from distributing as easily as before :(


kdbench.scra - No such file or directory

When I'm trying to launch kdbench with storage class name - I've got the error:
~/temp/2022-09/kDbench$ ./kdbench ceph-block
cp: cannot stat '/srv/korepov/.kdbench/kdbench.scra': No such file or directory

Without arguments it starts well and shows me the list of storage classes:
~/temp/2022-09/kDbench$ ./kdbench
ceph-block
ceph-bucket
ceph-filesystem

Where can be the problem and how to fix it?

Seems that paths for this file is hard-coded:
https://github.com/sysnet4admin/kDbench/blob/b1b23f3309c8f5f729b755ae8719984c355cb5b8/kdbench#L24
Maybe make it relative to the script directory?

@MurzNN Yes it is hard coded. so it cannot move to other directory from ~/.kdbench files

So, maybe make it relative, to not force the directory structure? Now, because of this, it works only when git is cloned to the ~/.kdbench - it's a bit strange.

Yes all of them are fixed structure. if you want to modify, fork and modify it.


Apply fixes from StyleCI

This pull request applies code style fixes from an analysis carried out by StyleCI.

For more information, click here.

:tada: This PR is included in version 4.2.14 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Meta node in chaos mesh tests takes 10~15 minutes to detect the failure of CN node

Describe the bug
CN-1 Pod killed around 22:18, but meta detect the failure around 22:32 and starts to recover. The recovery is successful though.

https://risingwave-labs.slack.com/archives/C048NM5LNKX/p1683558910090979
To Reproduce
No response
Expected behavior
No response
Additional context
No response

Since the recovery process is triggered by failure of inject and collect barrier, so if meta didn't detect the CN gone (and no hang about the network issue in k8s env), it must be hang somewhere other than injection and collection barrier with CNs. After looking at the detailed logs and reviewing the code related to the barrier handling process, here are just some random guess about it:

CN-1 pod killed around 22:18.
barrier manager is handling a success barrier complete response and somehow hang, otherwise it should be dealing with barrier injection and trigger recovery immediately.
after 10~15mins, barrier manager turned to handle a failed barrier complete response in the buffered channel and recovery triggered.

During the downtime, the barrier numbers were not updated, nor were all the barrier latencies. At the time of the recovery trigger, the timer for the barrier latency recorded up to 10+ minutes. It indicates that the barrier manager hanged for 10mins+ during the timer, when it was handling the result of a successful barrier complete response. After that complete_barrier returns ok and then failed at handling a failed buffered barrier complete response.
https://github.com/risingwavelabs/risingwave/blob/21e01135d6a688a17a89654de4f1395037cba79d/src/meta/src/barrier/mod.rs#L880

There’s one thing that quite confusing: if it was cause by some hang issues in kernel side, the deterministic recovery test should have already covered and found it. The failover situation in the test is more random and demanding than chaosmesh. 🥵

if it was cause by some hang issues in kernel side, the deterministic recovery test should have already covered and found it.

Not sure if I understand Madsim correctly,
since meta eventually detects the failure and recovers successfully, it seems it does not hang forever.
If it does not hang forever, then in Madsim, even a long period of time will be compressed into several milliseconds in the simulation, which is unable to expose this hang-for-a-while problem. 🤔

since meta eventually detects the failure and recovers successfully, it seems it does not hang forever. If it does not hang forever, then in Madsim, even a long period of time will be compressed into several milliseconds in the simulation, which is unable to expose this hang-for-a-while problem. 🤔

Actually each run of a test statement in the deterministic recovery will be retried up to 5 times with a maximum time of about 31s in Madsim world. Unless the run is also hang-for-a-while in frontend, but I don't find any slow query logs in longevity test and deterministic recovery test. So this retry strategy will expose the hang-for-a-while problem.

updates:
After some further investigation, I found some more clues.  Use the case in this issue as example:

start to kill pod, new compute-c-1 started at 2023-05-08T22:16:57 and start to serve, there were no actors running in this pod.
old compute-c-1 received shutdown signal and finally exited at 2023-05-08T22:17:24, which is roughly 30 seconds after the new one started. DNS resolution would continue to point to it until it exited.

So it indicates that there were two different states of CN co-existing during the kill-pod operation. At that time, the old CN was in a status of graceful shutdown and the new one was serving without any running actors. So meta was somehow hang-for-a-while during handling the result of a successful barrier complete response.

Reopened. This case (https://github.com/risingwavelabs/risingwave/issues/9712#issuecomment-1543642491) also needs to be handled correctly.

It will try to register for like 5m if using the default configuration.
Is 5m too long? I think in any cases recovery should be done in seconds.

Also we may continue to work on https://github.com/risingwavelabs/risingwave/issues/9712, no matter it’s SIGKILL or SIGTERM or even 2 compute nodes coexists shortly

Related: https://github.com/risingwavelabs/risingwave-test/issues/440

It seems that killing CN pod with --grace-peroid 0 can reproduce the problem

It seems that killing CN pod with --grace-peroid 0 can reproduce the problem

More infos:

To delete a pod forcefully, you can use the kubectl delete pod command with the --force and --grace-period=0 options. The --force option will delete the pod immediately, and the --grace-period=0 option will terminate the pod immediately without waiting for the grace period.


processing vector of inputs within Matlab

Hi,
Is it possible to process vectors of e.g. pressures and temperatures for a certain fluid at once instead of via a for loop going over all the pressure-temperature combination one by one? I'm using Matlab.
Thanks for your help!
Maarten

If you calculate different states, there is not much of a benefit passing vectors instead of creating an outer loop. The costly function is the update the state and that cannot be avoided. You can use an output vector to get several quantities at the same state, but that is not what you want.
By the way, this is the old repository, you should go to https://github.com/CoolProp/CoolProp


libsass bindings not found in error

So my gulp was running smoothly about a month ago until I tried to run it today..
This is my package.json file to show all my dependencies I have installed:
{
  "name": "CMS",
  "version": "0.0.0",
  "description": "Node dependencies for Ventrac\\CMS",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Haley Schillig",
  "license": "ISC",
  "devDependencies": {
    "bootstrap": "^3.3.5",
    "bootstrap-sass": "^3.3.5",
    "font-awesome": "^4.4.0",
    "form-serialize": "^0.6.0",
    "gulp-sass": "^2.1.0",
    "jquery": "^2.1.4",
    "node-sass": "^3.4.1",
    "tinymce": "^4.2.6",
    "vue": "^0.12.16",
    "vue-resource": "^0.1.16"
  }
}

I went through this page: https://github.com/dlmanning/gulp-sass/issues/174 And tried all their fixes. I uninstalled gulp-sass and node-sass and reinstalled both. I tried to remove node-sass from gulp-sass node_modules. I removed node_modules and ran npm install again. I tried to clear npm cache... nothing is working.
Thanks for any help.
Node version - 4.2.1
NPM version - 2.4.17
OS - Windows 8.1 (win32 64 bit)
EDIT::
I tried all these solutions too : http://stackoverflow.com/questions/28409100/try-reinstalling-node-sass-on-node-0-12

I'm having the same issue here, but I'm trying to install the last version and getting 404 error for this file:
https://github.com/sass/node-sass/releases/download/v3.4.1/win32-x64-47_binding.node

If you go to the releases directory in the node-sass repo, you will see that in fact the win32-x64-47_binding.node file doesn't exists there, only the earlier version: win32-x64-46_binding.node

@JuanHB this is not related has been answered many times. We do not yet support Node 4 on Windows because the service we use to generate the native code hasn't been updated it. If you're using a node version that's a week old you can expect things not to work. Down grade your node and everything will be fine.

@IntellectProductions this error means only one thing, node-sass wasn't installed correctly. This generally happens when you OS (i.e. in a vm) or version of Node. Removing node_modules always fixes the problem. If the problem persists it's because the version of node you're npm installing with is not the version of node you're executing the code with.
I cannot assist any further as this is an environmental issue. Make sure all the places you're interacting with node-sass you are using the same version of node. You can always run npm rebuild to rebuild the node-sass binary for your new environment.


Implement inheritance of config trees (without YAML anchors...)

Because YAML anchors do not allow specialising a child node of an anchored-in tree, we need to instead roll our own joint of merging user-specific changes via inheritance.
Use case

I have three profiles (one is default which is what contour supplies, then I have master and light which are two themed customised things). When Contour comes with changes to the default schema, it's a PITA to upgrade the other two profiles because a simple diff tool just can't help as my custom profiles are always additions versus the default.
Automatic update of config files will get messy if entire sub-trees need update which may or may not have some keys.

Proposal
1. Hardcode for each top-level listing map (e.g. profiles and colour_schemes) the __default__ key. This is the key where Contour's "official" configuration should be put (e.g., in the contour generate config ... output).
This will make updates to the official configuration easier, as we need to only update one well-defined and reserved tree.
2. (Optionally) Introduce the __inherits__ or __base__ (I'm purposefully using some reserved underscore mangling yadda here) which takes as an argument a single (or multiple?) other named entity from the same tree: e.g., a profile might inherit another profile.
This could make custom configurations more composable (a'la CMakePresets), but might make the implementation unnecessarily messy!
3. (Irrespective of whether 2. is implemented...) when resolving a specific <top-level-tree-structure>.<user-defined-identifier>.whatever.blah key, use the following logic (in this example, rolling with the profiles, but the colour_schemes is the same yadda!):

If profiles.foo.whatever.blah exist, resolve to that value.
If profiles.foo.whatever.blah does not exist, but profiles.<T>.whatever.blah exists, resolve to that.

If entities might inherit from a single but user-specified base "class": <T> is that
If entities might inherit from a list of multiple user-specified base classes: <T> is the last in that list
If entities might not user-customisable inherit, <T> is __default__

If no such value exists, fall back to Contour's baked-in default and emit a warning

4. When new keys are added to the schema (a.k.a. when the warning mentioned above is emitted), optionally offer merging such changes into the __default__ base "class". This way, it will also automatically be inherited into every user-customised profile.
Example
With this, I could achieve the following way of customisation which would make my profile YAML easier to read and edit:

profiles:
  __default__:
     # All the hardcoded b.s.
     ...

  master:
    # __base__: "__default__" (implicitly?)
    font:
      size: 14
      regular:
        family: "JetBrainsMono"

    permissions:
       capture_buffer: allow

    colors: "dracula"

colour_schemes:
    __default__:
       # Similarly, the default stuff...
       ...

   dracula:
     # __base__: "__default__"
     default:
       background: "#282a36"
       foreground: "#f8f8f2"

Why not YAML anchors instead?
default:
  font:
     regular: "JetBrains Mono"
     size: 12

my_profile: &<< default # I have no fucking idea about the syntax
  font:
     size: 14
     # Expectation: "regular" stays the same

YAML anchors do not support the use case described in this ticket, and the Expectation: line above does NOT hold...

I think that  instead of __default__ we can use existing   main name to not break peoples configurations. Also, we have https://github.com/contour-terminal/contour/blob/2d490c86cbd52ff25250a71a130eb226ba21d8ac/src/contour/contour.yml#L65 field in the config. So you can specify which configuration is default one.


Removing empty columns from persisted Dataframe

Pyarrow is saving a different datatype when a column is fully empty.
This PR is removing the empty column from the final parquet file, which allows spark to read without any issues.
Before:
# Parquet file 1
pyarrow.Table
col4: int64
col3: string
col1: string
col2: double
----
col4: [[55555555555555555,null,null,null]]
col3: [["1","2","3",null]]
col1: [["1","2","3","4"]]
col2: [[51.1111,2,3,4]]

# Parquet file 2
pyarrow.Table
col3: string
col1: null
col2: null
----
col3: [["1","2","3"]]
col1: [3 nulls]
col2: [3 nulls]

# Spark schema
root
 |-- col4: long (nullable = true)
 |-- col3: string (nullable = true)
 |-- col1: string (nullable = true)
 |-- col2: double (nullable = true)

# EXCEPTION
org.apache.spark.sql.execution.QueryExecutionException: Parquet column cannot be converted in file file2.parquet. Column: [col1], Expected: string, Found: INT32

After:
# Parquet file 1
pyarrow.Table
col4: int64
col3: string
col1: string
col2: double
----
col4: [[55555555555555555,null,null,null]]
col3: [["1","2","3",null]]
col1: [["1","2","3","4"]]
col2: [[51.1111,2,3,4]]

# Parquet file 2
pyarrow.Table
col3: string
----
col3: [["4","5","6"]]

# Spark schema
root
 |-- col4: long (nullable = true)
 |-- col3: string (nullable = true)
 |-- col1: string (nullable = true)
 |-- col2: double (nullable = true)

+-----------------+----+----+-------+
|             col4|col3|col1|   col2|
+-----------------+----+----+-------+
|55555555555555555|   1|   1|51.1111|
|             null|   2|   2|    2.0|
|             null|   3|   3|    3.0|
|             null|null|   4|    4.0|
|             null|   4|null|   null|
|             null|   5|null|   null|
|             null|   6|null|   null|
+-----------------+----+----+-------+

Test
Added a new unit test test_persist_null_column.
7 passed, 2 warnings in 0.57s

his PR is removing the empty column from the final parquet file, which allows spark to read without any issues.

Does Trino and Hive also work fine with missing column in the file?

Does Trino and Hive also work fine with missing column in the file?

That is a good question @anandnalya! Yes, both work with hive and trino (even though we don't need it because we are only using the ParquetSqoopTransformation to create the new table).
The tables were created to verify it was scratch.pyarrow_test_with_empty_column and scratch.pyarrow_test_without_empty_column, both on hiyu.


added TasksFolderType

I have added this to the psr-4 branch, which will replace the composer branch shortly.


KAS-3313 testdata zip with reindex and 1 publication

The current zip hasn't been reindexed lately.
This one has 1 publication (the first one in testdata) with reindex done.

@ValenberghsSven Since #272 has been merged, which changed the authorization group names, we need to update the search index in testdata.zip again.

Going to merge this one already such that testdata is back in sync with renamed authorization config from #272, otherwise Jenkins build for development branch will start failing


Extend double slash bug

docblockr is adding comments after a double slash even when the 'Extend double slash' setting is disabled.
// this is a comment (cursor here, hit enter)
// new double slash comment created (bug)

+1 Just installed the plugin and having this issue as well.


Better handling of consecutive transactions

FYI: I'm treating this as bug, as it's a blocker for us on another project.
To simplify our lives, we did not consider in-block ordering of dependent transactions.
We also do not allow two dependent transactions to be in the backlog at the same time (e.g. HTTP API blocks from submitting a TRANSFER where the CREATE doesn't exist yet).
This yields a frustrating problem that we have to patch in several libraries right now, a loop that waits for a transaction to be confirmed, see here or here (loop at bottom of section).
Instead, I'd like to propose fixing this issue with the following changes:

Any schema-valid transaction can pass from the HTTP API into the backlog
Either: The backlog's transactions are topologically ordered, such that when a new transaction gets inserted it gets automatically sorted into place
Or: The backlog is not topologically ordered, such that when a new transaction gets inserted it gets appended to the list of transactions to be processed
Upon block creation the node then:
Either: takes the first 1000 transactions (already topologically sorted) from the backlog and puts them into a block. Caution: This will yield unfair results, e.g. when one transaction DAG is very active
or: takes the first 1000 transactions and sorts them topologically and puts them into a blog

In both cases, this would mean that two (or more) dependent transactions can be in one block.
Bitcoin has this, I remember there was a BIP (can't find it right now). This link might be helpful.
FYI: Topological sorting isn't too difficult (meaning that this task shouldn't be too difficult). There are many ready-made algorithms (I use this one for JS).

I'll remove this from the QA milestone, we will reiterate on that soon.

I created issue bigchaindb/BEPs#88 so we don't forget this idea, so I'm closing this issue here.


请问下，下面的这个报错是啥原因？我是在windows环境上进行执行的

Traceback (most recent call last):
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\connectionpool.py", line 699, in urlopen
httplib_response = self._make_request(
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\connectionpool.py", line 445, in _make_request
six.raise_from(e, None)
File "", line 3, in raise_from
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\connectionpool.py", line 440, in _make_request
httplib_response = conn.getresponse()
File "E:\python 3.9.0\lib\http\client.py", line 1347, in getresponse
response.begin()
File "E:\python 3.9.0\lib\http\client.py", line 307, in begin
version, status, reason = self._read_status()
File "E:\python 3.9.0\lib\http\client.py", line 276, in _read_status
raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\requests\adapters.py", line 439, in send
resp = conn.urlopen(
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\connectionpool.py", line 755, in urlopen
retries = retries.increment(
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\util\retry.py", line 532, in increment
raise six.reraise(type(error), error, _stacktrace)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\packages\six.py", line 769, in reraise
raise value.with_traceback(tb)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\connectionpool.py", line 699, in urlopen
httplib_response = self._make_request(
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\connectionpool.py", line 445, in _make_request
six.raise_from(e, None)
File "", line 3, in raise_from
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\urllib3\connectionpool.py", line 440, in _make_request
httplib_response = conn.getresponse()
File "E:\python 3.9.0\lib\http\client.py", line 1347, in getresponse
response.begin()
File "E:\python 3.9.0\lib\http\client.py", line 307, in begin
version, status, reason = self._read_status()
File "E:\python 3.9.0\lib\http\client.py", line 276, in _read_status
raise RemoteDisconnected("Remote end closed connection without"
urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "F:\MobileTerminal\IOS_StressTool\testcase\fundStaff\view_channel.py", line 78, in
view_channel(q, bundle_id, repeat_times)
File "F:\MobileTerminal\IOS_StressTool\testcase\fundStaff\view_channel.py", line 55, in view_channel
query.scroll("up")
File "F:\MobileTerminal\IOS_StressTool\service\query.py", line 222, in scroll
self.s.swipe_up()
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\wda_init_.py", line 976, in swipe_up
return self.swipe(w // 2, h // 2, w // 2, 1)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\wda_init_.py", line 954, in swipe
return self._session_http.post('/wda/dragfromtoforduration', data=data)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\wda\utils.py", line 47, in inner
return fn(*args, **kwargs)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\wda_init.py", line 460, in fetch
response = httpdo(url, method, data, timeout)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\wda_init.py", line 130, in httpdo
return unsafe_httpdo(url, method, data, timeout)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\wda_init.py", line 157, in _unsafe_httpdo
response = request_session.request(method,
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\requests\sessions.py", line 542, in request
resp = self.send(prep, **send_kwargs)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\requests\sessions.py", line 655, in send
r = adapter.send(request, **kwargs)
File "C:\Users\panxr33970\AppData\Roaming\Python\Python39\site-packages\requests\adapters.py", line 498, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

看起来 8100端口没监听吧

使用的是usbClient初始化的，这个需要额外再增加什么条件么？发自我的华为手机-------- 原始邮件 --------发件人： codeskyblue @.>日期： 2021年9月7日周二 下午4:49收件人： openatx/facebook-wda @.>抄送： pxrgod @.>, Author @.>主    题： Re: [openatx/facebook-wda] 请问下，下面的这个报错是啥原因？我是在windows环境上进行执行的 (#114)
看起来 8100端口没监听吧
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.


point to specific files for updates

Designating the file vue reads in from s3 to avoid unintended updates from re-running the pipeline locally before ready to deploy.
This should create the ready-to-release update for the 2022 water year.

A potential issue - I just started working w/i this branch to make the visual for social media and noticed a couple of odd things:

After the animation finishes, it immediate switches to this view:

But that doesn't seem to reflect the starting conditions, if I play and immediately pause:

Water levels in Florida are static from October- January and then again April-end of September:

1 is a known issue with the first draw. I haven't been able to get to it yet https://github.com/USGS-VIZLAB/gw-conditions/issues/48The issue is that the svg that loads with the map initially represents 1 day of data, that is seemingly tied to the prior year's data. It must be that somewhere in the pipeline the map is created but is not linked to the updating data, or that we only created this once. This is set up like this because we wanted the map to appear right away when the page loads, and requiring the data to load first to be able to draw the map all in D3 was slow. Now, it loads a pre-defined svg and then when the data loads, binds it to the sites. This could be related to 2 also because if there were changes in sites between years, sites from last year may be loading and never getting data assigned, and remaining static on the page.
2 is suspicious and may be related to 1 if NA values are defaulting to the first draw state? also possible this is related to the different pcodes in FL.
Will look into this before moving forward.


Knock off some bitrot

The overlay attribute is deprecated and has been removed in favor of overlays.default

This is an attempt to unstick #159.

I'm not entirely satisfied with our interface here, but I'm not sure we can do a lot better without https://github.com/numtide/devshell/issues/223.


Nick: Watch mercedesrepairdubai.com

Nick requests the watch of the watch_keyword mercedesrepairdubai\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Jeff Schaller in Charcoal HQ

mercedesrepairdubai\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.


Expose Catalog trait as python binding

#538

First time writing rust, most of this code is generated but helped me understand the codebase.
Here are a couple of things I've learned

bindings/python/src/lib.rs is how we can expose rust code as python binding
The catalog implementation is in a different crate than the "catalog trait".

"catalog trait" is part of the "iceberg crate" https://github.com/apache/iceberg-rust/blob/main/crates/iceberg/src/catalog/mod.rs#L39
the SQL catalog implementation is part of the "catalog crate" https://github.com/apache/iceberg-rust/blob/main/crates/catalog/sql/src/catalog.rs#L71

Hi, @kevinjqliu I'm fine with adding it in pyiceberg_core module. But instead of adding sql catalog only, I think it's better to add a wrapper around Catalog trait? What do you think?

@liurenjie1024, following up on this comment https://github.com/apache/iceberg-rust/pull/534#issuecomment-2330489500
Is the idea to expose only the Catalog trait to python? And perhaps a function to create different catalog implementations similar to what load_catalog is doing in python?


What serialization(s) will IEEE 3195.1 CCO be in?

Brian Haugh asked: "There is also a question of whether to use Turtle, RDF/XML, or other serializations of the CCO for the reference version. I believe that the DIOWG guidance is leaning towards requiring RDF/XML for ontologies in its Foundry."
Background:  When approved, IEEE 3195.1 CCO will be a printable document, but could also refer to a digital file (most likely stored as a given CCO version at https://opensource.ieee.org/cco).  The paper document will be available for sale as normal, and the digital file will be posted for free download.
My Questions: What serializations will CCO be offered in?  If more than one, are they all equivalent, or is one the standard and others derived?  Will the printable document refer to the digital file?  If so, is that acceptable for a standard?  How did ISO/IEC-JTC1-21838-2 BFO handle this?

We discussed recently in a IEEE CCO subgroup meeting that we might want to reflect the BFO-ISO standard approach: the standard isn't the RDF file per se but a written document that outlines how portions of BFO satisfy the top-level requirements, and points to the GitHub as the site where it's developed and housed, so we should do the same thing with CCO. The particular version of CCO we submit will be changed, updated, expanded, and modified for as long as it's used and contributed to, so we shouldn't think of there being an "IEEE Official Version"
The standard can of course include the file, but the heart of the standard is the written explanation showing how the CCO satisfies mid-level ontology criteria. Moreover, the CCO is really a collection of modules, so the merged-all-core file is technically a convenience file more than a single grand ontology.
Theoretically, RDF, OWL, TTL should be equivalent, so it might not technically matter. However, as developers, we prefer TTL serialization far more than others because it's easier to read, easier to 'cut and paste,' easier to transfer into SPARQL and SHACL, and easier to teach people how to use/read. I personally advocate TTL all the way down, in DIOWG as well (I'm not sure how XML got suggested as the DIOWG standard).
I can gladly leave this issue open how a little while for others to read and offer thoughts. @mark-jensen @johnbeve

My Questions: What serializations will CCO be offered in? If more than one, are they all equivalent, or is one the standard and others derived?

RDF serializations are equivalent. Any one can be converted into any of the others, using publicly-available tools or library features rdflib (not endorsing either, just indicating examples).
Reasons to prefer, say, RDF/XML over N-Triples or Turtle or JSON-LD will depend on implementation details, so neutrality is important. I'm partial to Turtle because I find it easy to read, but I've met many developers who prefer JSON-LD for the same reason.
These observations suggest though that we should provide users with or direct users to directions for re-serialization strategies.

Will the printable document refer to the digital file? If so, is that acceptable for a standard? How did ISO/IEC-JTC1-21838-2 BFO handle this?

ISO 21838 can be purchased in both printed and pdf+epub formats, but it is also downloadable for free assuming you agree to use the download to develop other ISO standards. As I understand, the content in each is the same.

I feel this issue is important enough to be fully vetted, presented to, and voted on by the Ontology Standards Working Group, so please leave this open until after a vote passes.
CCO has the attached approved Project Authorization Request (PAR):
P3195.1 (1).pdf
5.3 states: "This standard must conform to IEEE P3195 Standard for Requirements for a Mid-Level Ontology."   So, I agree CCO must show conformance.
5.2 states: "Scope of proposed standard: This standard defines a mid-level ontology that specifies a set of well-defined terms and relations commonly used across multiple domains..."   This states we are standardizing a specific ontology.  Let's say CCOv2.0 is what gets voted on and approved as a standard.  v2.1 can follow and be released online, but it won't be an IEEE standard unless later approved as such.
I'm now starting to remember the unique arrangement Barry worked out with ISO, where they somehow delegated further development to his group of experts.  We can explore that, but I doubt it applies to CCO and is not what our PAR authorizes.  We would need to change the PAR to take that route.
@johnbeve I suggest you try drafting the paragraph that references the approved standard CCO, so we can show it to people with experience in how to do this.   This might be simple, but I feel we should still get it reviewed sooner than later.

The emerging Verifiable Credential ecosystem is using JSON-LD.  I see this ecosystem as needing P3195 ontologies and starting to use them as soon as the IEEE PURL server provides stable and trustworthy URLs.  If we standardize on one serialization, it doesn't need to be JSON-LD (provided we provide a version in JSON-LD)(so why don't we provide various versions now for CCO v1.4?).  As for PURL responses, why not give it in multiple formats, plus allow the query to ask for a given version.  This standard might help with this:  'Best Practice Recipes for Publishing RDF Vocabularies' https://www.w3.org/TR/swbp-vocab-pub/

Let's consider this solution:  The 'normative' (i.e. what is a standard) wording in P3195.1 CCO (the document that can be printed) would state: "CCO ontology is standardized in the following equivalent serializations (Turtle Syntax, RDF/XML Syntax, OWL/XML Syntax, and JSON-LD) and available for download at ."  We could also include 'informative' wording to explain how additional equivalent serializations can be derived.

CCO ontology is standardized in the following equivalent serializations (Turtle Syntax, RDF/XML Syntax, OWL/XML Syntax, and JSON-LD) and available for download at...

I don't think you should attempt to enumerate serialization formats, partly for the reason raised by @swartik. I suggest: "The CCO artifact is serialized in a standard RDF format at..."
We can then write brief guidance located in the README wherever "..." points, explaining that serializations are semantically equivalent and how users can re-serialize to another format if needed for their environment.

John,     When drafting the PAR, we were severely criticized by an IEEE senior reviewer for not knowing the difference between an artifact and its serialization.  I hear consensus the core of this standard should be CCO.ttl.  I propose we don't call it a serialization, because that begs the question, 'Serialization of what artifact, and shouldn't that artifact be the standard?'  But there is no single artifact that could be the standard.     So, could the standard state: "This document standardizes MergedAllCoreOntology-v1.4-2023-04-07.ttl as found at https://opensource.ieee.org/cco/CommonCoreOntologies/-/blob/master/cco-merged/MergedAllCoreOntology-v1.4-2023-04-07.ttl." (Replace with correct version and PURL and list all ontology modules if we decide to. )
Also, I'm working with the emerging Verifiable Credential community, which uses JSON-LD.  Is there any reason why we could not offer CCO in multiple forms?

We could, but if you have Python and the RDFLib package, it only takes a moment, this code converts it:
from rdflib import Graph

g = Graph()

# Load the ontology with the file name
g.parse("CCO.ttl")

# Change the serialization format
g.serialize("CCO.jsonld", format="json-ld")

But that could still be an obstacle for adoption.  Some might not believe it is equivalent or part of the standard.  So if there is no reason it couldn't be provided as a version of the standard, I propose it should.   Also, for JSON-LD, I committed to do a demo to the Open Wallet Foundation of how a Verifiable Credential claim (for a term, e.g. height) includes a PURL in its JSON-LD code that returns a definition.  As such, I'll need a version of CCO in JSON-LD, which I propose we load on our Gitlab repo.  Plus our PURL Server will need to respond to queries in Turtle, JSON-LD, and any other from we include.     Thoughts anyone?

propose we don't call it a serialization, because that begs the question, 'Serialization of what artifact, and shouldn't that artifact be the standard?'

I agree. This concern about whether the specific files named in the standard are serialized in turtle or xml, or some other,  is a false dilemma. We are standardizing the content of the 11 ontologies that comprise a particular named and dated release of CCO. It has to be verifiable OWL2 in some standard serialization. Is there a reason we need to provide more than format for the standard? Where did that come from? In the ISO spec for BFO under section 4.3 "OWL 2 formalization of BFO-2020", it names two OWL versions, one in RDF (presumably this is XML) and the other in OWL functional syntax. I am not sure why they did this, maybe due to how BFO was built or some other requirement related to the FOL version or consistency checking. @alanruttenberg @johnbeve Do you recall why?

Is there any reason why we could not offer CCO in multiple forms?

If there is enough of a demand signal from users to provide alternate encodings, then of course we can.

Plus our PURL Server will need to respond to queries in Turtle, JSON-LD, and any other from we include.

Who decided that the PURL server has to negotiate gets for JSONLD? Or turtle for that matter?
It is important to keep these three things separate:

CCO as it exists in the repository. It will change as edits are made and new releases generated.
The files that are returned via the IRIs. These are generated using those in no. 1, but nonetheless separate, and will always reflect the current release of CCO.
The files that get named in the P3195.1. These will (I assume) be stored somewhere else as an archive where they can be accessed independently of the repo. They will be copies of the ontology files at certain point in the commit history of the repo, a snapshot of a version of CCO.

@jimschoening1 How does IEEE SA store and archive standards once accepted?
I'd like to note that the scope of this issue has crept and I think it would be wise to keep it limited to the specifics of what   serialization(s) are named, if at all, in the standard 3195.1, as well as the language surrounding how they are described. Discussion about which formats are needed to be returned via the PURLs is a separate issue. Requests for providing CCO in alternate encodings for use-cases is another issue.

@cameronmore, are you suggesting your translation script be part of the CCO standard? I am wary of that. You would have to specify the versions of Python and rdflib. You would have to demonstrate that the script behaves equivalently across platforms and Python implementations. If I were an IEEE reviewer, I would look askance at anything less.
If you're just talking about what expert users can do, that's different. It still leaves open the question of what the standard should contain, and why.
@jimschoening1, can you educate us (me?) about serializations in standards? Is it common to include multiple serializations? What are popular serializations? What documentation describes the relationship between an artifact and its serialization? And what's the relationship between the standard and the gitlab server? Does the standard mention the gitlab server? And the PURL server, for that matter? Or the other way around? Or both? Do standards describe how to obtain serializations?

@swartik definitely not suggesting my script be part of the standard, just making it easier for someone to convert if they want.

John, When drafting the PAR, we were severely criticized by an IEEE senior reviewer for not knowing the difference between an artifact and its serialization.

Understood. I think we can display awareness of the difference without asserting a specific serialization.

I propose we don't call it a serialization, because that begs the question, 'Serialization of what artifact, and shouldn't that artifact be the standard?' But there is no single artifact that could be the standard.

Agreed. To be clear, my suggestion "The CCO artifact is serialized..." was meant to be compatible with the fact that:

What is being standardized is (as @mark-jensen notes) the content of the CCO ontologies

While conveying that:

The content of CCO is represented in some serialization format.
The standard doesn't dictate what format.

Today the serialization might be TTL; in three years it might be RDF/XML.

I'd like to note that the scope of this issue has crept and I think it would be wise to keep it limited to the specifics of what serialization(s) are named, if at all, in the standard 3195.1, as well as the language surrounding how they are described.

Agreed.

I checked with Jonathn Goldberg, our IEEE Staff Advisor, who clarified our standards document will include a link to the ontology.  He said, " Yes, the OS repository is linked in the draft pointing to the code. The code is not included in the draft. "   I conclude this also means we can easily point to multiple serializations and assert they are equivalent.

If you look in the functional syntax spec you will see

This document also defines the functional-style syntax, which closely follows the structural specification and allows OWL 2 ontologies to be written in a compact form. This syntax is used in the definitions of the semantics of OWL 2 ontologies, the mappings from and into the RDF/XML exchange syntax, and the different profiles of OWL 2. Concrete syntaxes, such as the functional-style syntax, often provide features not found in the structural specification, such as a mechanism for abbreviating IRIs"

All the files mentioned in that document have the extension .owl. It also says:

It is recommended that OWL functional-style Syntax files have the extension .ofn (all lowercase) on all platforms.

The OWL/XML document says

It is recommended that OWL XML Serialization files have the extension .owx (all lowercase) on all platforms.

The Manchester syntax document says:

It is recommended that OWL Manchester Syntax files have the extension ".omn" (all lowercase) on all platforms.

If you save an ontology from Protege without giving a file extension OWL/XML will get the extension .owx. If you save it as functional syntax it will get the extension .ofn . If you save it in the Manchester syntax you will get .omn.
Practically speaking you can save all of these with ".owl" and RDF/XML with ".rdf". The OWL 1 reference says uses .owl or .rdf. However, when I see .rdf I always am not sure whether it is OWL or generic RDF, so I don't use that and dislike when others do for owl, given that there are established conventions.
The RDF/XML document does say

It is recommended that RDF/XML files have the extension ".rdf" (all lowercase) on all platforms.

Protege will save RDF/XML with a default .rdf extension, However this is not the convention generally used for OWL files, c.f. the functional syntax document quote above.
The parsers I and Protege use try to figure out the file format based on the contents without really consulting the file extension.
I don't like content negotiation because it takes server configuration to work and because you can't be sure what you are going to get if you put the URL into a browser. I consider the different file formats to be distinct resources, though opinions differ.

@alanruttenberg  Thanks. I haven't looked at the OWL 1 specifications for a long time. Nor have I memorized all the OWL 2 documentation. It always helps when one of the authors contributes.
That said, I'm not convinced suffix used is far enough along to qualify as having widely accepted established conventions. I had a sponsor tell me his tool required an RDF/XML file to have a name end with ".xml". I hope he's an outlier.
What version of Protege are you using? I'm running 5.5.0 on Windows. I just tried saving an ontology in RDF/XML, OWL/XML, and Turtle by entering a non-suffixed name into the file name box. In all three cases, Protege added ".owl" as the suffix.

5.6.1 on MacOS
Not sure which you are not convinced about. In any case a quick check shows the OBOFoundry uses .owl and IOF uses .rdf for RDF/XML

As written here all serializations will contain equivalent content of the CCO.


Cleanup iOS project file

Did a quick pass to clean up the iOS project file. Removes unused targets and files. Renames some stuff. Fixes some awkward obj-c code.

@keybase/react-hackers

this kills the test stuff which makes red box testing no longer work. why?

yeah don't need this


Add Russian to I18nTest (simple i18n smoke test)

Signed-off-by: David A. Wheeler<EMAIL_ADDRESS>

Codecov Report

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

@@          Coverage Diff          @@
##           master   #866   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          45     45
  Lines        1441   1441
=====================================
  Hits         1441   1441

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 57853a7...11b4467. Read the comment docs.

+1


IP address of domain apex should not be <IP_ADDRESS>

Right now, if you set up sandcats, the domain that it controls (e.g. sandcatz.io) gets configured (through PowerDNS) to resolve to <IP_ADDRESS>
It should instead resolve to the machine's external IP.
Since the main Sandcats service runs on Google Compute Engine, I was curious to see if there is a way for a Google Compute Engine specific way to get the external IP address. I can't seem to find one, though, so perhaps we're best-served to do a GET to checkip.dyndns.org in this bootstrapping phase.
The code for this behavior lives in lib/dns.js, for what it is worth. It might be nice to instead make this a config parameter in the Meteor settings file.

curl -H 'Metadata-Flavor: Google' metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/
provides some relevant information.
It's documented at https://cloud.google.com/compute/docs/metadata , for what it's worth.

paulproteus@sandcats-dev:~$ curl -s -H 'Metadata-Flavor: Google' http://metadata/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip | xargs echo
<IP_ADDRESS>
paulproteus@sandcats-dev:~$


Silence compilation warnings for github library

Silence compilation warnings for github library

remove unused imports
disable star-is-type warning while we are supporting GHC 7

Ping @phadej, approving this PR?


zola: 0.8.0 -> 0.9.0

Motivation for this change
changelog
Things done

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

[x] NixOS (x86_64, aarch64)
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @dywedir

@GrahamcOfBorg

@GrahamcOfBorg build zola

0x4A6F thanks!
Let's check x86_64-darwin build on Hydra :eyes:


Add product list file output

Thanks, I'll add a test.
That's correct - using unique_ptr is actually a workaround for optional types not being available (they're not available til c++17 and we're using c++11). In fact, it's just a safer way of using the traditional hack of using a pointer as optional type (0 <--> None, anything else <-->Some). The alternative would be to upgrade to c++17, which I would actually suggest we do at some point :).

@leonardt included tests


test-gdams-debian10-riscv64-1: tests hang after receiving Read-only file system message

The systemtests hang on test-gdams-debian10-riscv64-1 after receiving a message:
Cannot contact test-gdams-debian10-riscv64-1: java.nio.file.FileSystemException<EMAIL_ADDRESS>Read-only file system

Full output at time of the hang:
19:50:50  STF 19:50:50.022 - =========================   S T F   =========================
19:50:50  systemtest-prereqs has been processed, and set to: /home/jenkins/workspace/Grinder_TKG/jvmtest/system/systemtest_prereqsRetrieving amount of free space on drive containing /home/jenkins/workspace/Grinder_TKG/openjdk-tests/TKG/../TKG/output_1616615032575/MathLoadTest_all_CS_5m_0
19:50:50  There is 14087 Mb free
19:50:50  STF 19:50:50.060 - ==================   G E N E R A T I O N   ==================
19:50:50  STF 19:50:50.067 - Checking JVM: /home/jenkins/workspace/Grinder_TKG/openjdkbinary/j2sdk-image
19:50:50  STF 19:50:50.068 - Starting process to generate scripts: /home/jenkins/workspace/Grinder_TKG/openjdkbinary/j2sdk-image/bin/java  -Dlog4j.skipJansi=true -Djava.system.class.loader=net.adoptopenjdk.stf.runner.StfClassLoader -classpath /home/jenkins/workspace/Grinder_TKG/openjdk-tests/TKG/../../jvmtest/system/mathLoadTest/..//systemtest_prereqs/log4j/log4j-api.jar:/home/jenkins/workspace/Grinder_TKG/openjdk-tests/TKG/../../jvmtest/system/mathLoadTest/..//systemtest_prereqs/log4j/log4j-core.jar:/home/jenkins/workspace/Grinder_TKG/jvmtest/system/stf/stf.core/scripts/../bin net.adoptopenjdk.stf.runner.StfRunner -properties "/home/jenkins/workspace/Grinder_TKG/openjdk-tests/TKG/../TKG/output_1616615032575/MathLoadTest_all_CS_5m_0/20210324-195050-MathLoadTest/stf_parameters.properties, , /home/jenkins/workspace/Grinder_TKG/jvmtest/system/stf/stf.core/config/stf.properties" -testDir "/home/jenkins/workspace/Grinder_TKG/openjdk-tests/TKG/../TKG/output_1616615032575/MathLoadTest_all_CS_5m_0/20210324-195050-MathLoadTest"
19:58:16  wrapper script does not seem to be touching the log file in /home/jenkins/workspace/Grinder_TKG@tmp/durable-5028f3b8
19:58:16  (JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)
19:58:16  Cannot contact test-gdams-debian10-riscv64-1: java.nio.file.FileSystemException<EMAIL_ADDRESS>Read-only file system
20:03:18  wrapper script does not seem to be touching the log file in /home/jenkins/workspace/Grinder_TKG@tmp/durable-5028f3b8
20:03:18  (JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)
20:08:20  wrapper script does not seem to be touching the log file in /home/jenkins/workspace/Grinder_TKG@tmp/durable-5028f3b8
20:08:20  (JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)
20:13:22  wrapper script does not seem to be touching the log file in /home/jenkins/workspace/Grinder_TKG@tmp/durable-5028f3b8
20:13:22  (JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)
20:18:24  wrapper script does not seem to be touching the log file in /home/jenkins/workspace/Grinder_TKG@tmp/durable-5028f3b8
20:18:24  (JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)
20:23:26  wrapper script does not seem to be touching the log file in /home/jenkins/workspace/Grinder_TKG@tmp/durable-5028f3b8
20:23:26  (JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)
20:28:28  wrapper script does not seem to be touching the log file in /home/jenkins/workspace/Grinder_TKG@tmp/durable-5028f3b8
20:28:28  (JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)
20:33:30  wrapper script does not seem to be touching the log file in /home/jenkins/workspace/Grinder_TKG@tmp/durable-5028f3b8
...........
Cancelling nested steps due to timeout
03:47:57  Could not connect to test-gdams-debian10-riscv64-1 to send interrupt signal to process
[Pipeline] sh
03:47:57  test-gdams-debian10-riscv64-1 was marked offline: This agent is offline because Jenkins failed to launch the agent process on it.

Sometimes the hang occurs trying to run the first test target - in other runs a few tests are run successfully before hanging.  The specifci test target does not appear to be significant (a passed test in one run hangs in another).

Looks like the machines are both offline at the moment again :-( FYI @gdams

Both machines are unpingable

@sxa - Does this need to be renamed as well? I think they're in your home rack?

@karianna No they are the two that George still has. I have a third board.

@gdams What is your intention with these systems? They have been offline for around a year now.

@gdams You've indicated outside this issue on more than one occasion that you will bring these boards back online but that does not appear to be happening. Can you please clarify the current state of them, whether they will be brought back, and if not I would suggest that they should be relinquished so they can be brought online somewhere else in the project, particularly in light of the possibility of having more JDK releases that can be built on this platform in order to increase testing capacity.

Both boards are now with me and appear to be working. Will run some tests via jenkins to validate.

riscv64 capacity has been stable the Unleashed machine referenced in the subject has been relocated although not significantly used - closing.


add ellipse to 'ShapesToBoxes' transform

Summary
Make 'ShapesToBoxes' transform support Ellipse.

How to test

Checklist

[x] I have added unit tests to cover my changes.
[ ] I have added integration tests to cover my changes.
[ ] I have added the description of my changes into CHANGELOG.
[ ] I have updated the documentation accordingly

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[ ] I have updated the license header for each file (see an example below).

# Copyright (C) 2023 Intel Corporation
#
# SPDX-License-Identifier: MIT

Codecov Report
Patch coverage has no change and project coverage change: -0.94% :warning:

Comparison is base (5f5ac2a) 80.00% compared to head (164311c) 79.06%.
Report is 1 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #1121      +/-   ##
===========================================
- Coverage    80.00%   79.06%   -0.94%
===========================================
  Files          258      258
  Lines        29336    29147     -189
  Branches      5746     5710      -36
===========================================
- Hits         23469    23045     -424
- Misses        4517     4783     +266
+ Partials      1350     1319      -31

Flag
Coverage Δ

macos-11_Python-3.8
79.06% <ø> (-0.04%)
:arrow_down:

ubuntu-20.04_Python-3.8
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

src/datumaro/plugins/transforms.py
76.52% <ø> (ø)

... and 16 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Improve volume functionality

Use cases:
General
I want to define volumes and their options when I define a stack. This means I should be able to define volumes in the UI when creating a stack and in rancher compose.
I expect to be able to manage "local" volumes in the UI. These are volumes created by the default volume driver.
I want to define what scope a volume should have. The scope should control how volumes are created in relation to the creation and deletion of stacks and the scaling of services within the stack.
For all of the below scenarios, I expect that changing the name of a service or stack to not impact the volumes being used.
Scope volume to deployment unit
I want to be able to create a stack with a volume that scales with a deployment unit.
If two deployment units for the same service are on the same host, I expect them to use different volumes.
If I scale up, I expect a new volume to be created for the newly create deployment unit.
If I upgrade a service in the DU, I expect the upgraded service to use the same volume.
If I scale down an entire deployment unit, I expect the per-DU volumes that were created for it to be automatically removed.
Scope volume to stack
I want to be able to create a stack where a volume is scoped to the stack. Meaning I can name a volume "data" in stacks A and B and they will not collide.
When I delete a stack, I expect stack-scoped volumes to be automatically deleted.
Scope volume to environment
I want to be able to create a stack with a volume that is used throughout the entire environment. Meaning I can define the volume in stack A and then use it in both stack A and stack B.
If I delete the stacks or services using an environment-scoped volume, I expect the volume to not be deleted.
Scope volume to "Classic Mode"
I want to be able to scale volumes in the same way that rancher 1.1 supports. This means I expect that:
Volumes are not scoped to stack or deployment unit by default.
If the driver is local, a volume with a matching name should be used if it already exists on the host where the unit is deployed or created if it does not exist.
If the driver is global (like convoy-nfs), the same volume should be used everywhere.
If I delete the stack or scale down a service, no volumes should be deleted.

Another consideration: volume drivers that are not managed by rancher.
rancher/rancher/5219

We also need to really think through all the snaphsot and backup use cases. Right now, the API is supporting the Longhorn use case of snapshots and backups based off of those snapshots, but what if a storage provider supports backups but not snapshots?
Does convoy-nfs fall into this category or does it technically support snapshots by way of full copies of the fs?

The new volume functionality is part of v1.2.0. Assigning to QA to test. But any new bug should be opened separately.

Following are the test cases that were validated for v1.2 release:
Create volumes with Environment scope (external: True) when volume name exists in “requested” mode
Create volumes with Environment scope (external: True) when volume name exists in “active” mode
Create volumes with Environment scope (external: True) when volume name does not exist
Delete all services that use external volume
Create volumes with Stack scope (external: False) when stackname_volumename does not exist
Create volumes with Stack scope (external: False) when stackname_volumename exists
Delete stack that has volumes associated with it.
Create volumes with Container scope (per_container: True)
Delete container (that has container scope volume) by scaling down service.
Delete container (that has container scope volume) by making it unhealthy.
Delete container (that has container scope volume) manually.

Any new issues related to volumes should be opened separately.


about the softmax function

When predicting the scores for every item in the set, you use softmax to normarlize the vector, but it will result in sum 1.
In the multi-label classification, should we use the sigmoid function instead?
Actually, in my own multi-label classification experiment, i use the softmax on my output scores, the performance drops than no softmax.

I think I tested this in my method. The reason I use softmax at that time is to make sure I can get distribution across all items then I can merge the prediction from the decoder and the repeated component. If you work on your case and get better performance, you can definitely use the sigmoid function.


[docs] Doc maintenance

This PR adds a batch of minor docs improvements that include:

make toctree titles more concise and descriptive
provide numbered steps to follow in contributing.md
add pro/con table to low_level_api doc so its easy to skim at first glance
add methods/functions discussed in the docs to the API section

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Thanks for catching those typos!


Extension causes high cpu load

Issue Type: Performance
Extension Name: html-css-class-completion
Extension Version: 1.18.0
OS Version: Darwin x64 18.5.0
VSCode version: 1.33.1

:warning: Make sure to attach this file from your home-directory:
:warning:/Users/ine/Zignd.html-css-class-completion-unresponsive.cpuprofile.txt
Find more details here: https://github.com/Microsoft/vscode/wiki/Explain:-extension-causes-high-cpu-load

Duplicate of #155. Also, it is missing the file you were expected to attach.


chore: Update announcing-vite2.md

Description

Additional context

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[x] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[ ] Read the Contributing Guidelines.
[ ] Read the Pull Request Guidelines and follow the Commit Convention.
[ ] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[ ] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

Thanks for the PR, this word is an old post and I don't think there is value in changing it.