RPC protocol

This is not a issue, but a quick note from my experience.
IMHO SparkR RPC is the most terrible part of SparkR project. It incredibly slow and memory inefficient. R <-> jvm data transfer is so painful with sparkr RPC... (here I made some timings  for transfer of small data.frame)
Of course I don't have full information about goal of this package (but I think, main goal is to create foundation for dplyr backend ), but I'm not sure it is good idea to use it. Mb something that relies on rJava will be much better choice. Hope this may be useful.
Also I will be happy to contribute when project will have roadmap.

Hi, thanks for the feedback!
The main idea right now is to define an API to abstract away the underlying
RPC implementation (so it can evolve, get faster, etc.). We are naturally
starting with what is already implemented but that in no way precludes
future improvements along the lines you suggest.
On Tue, Jun 21, 2016 at 6:12 AM, Dmitriy Selivanov<EMAIL_ADDRESS>
wrote:

This is not a issue, but a quick note from my experience.
IMHO SparkR RPC is the most terrible part of SparkR project. It incredibly
slow and memory inefficient. R <-> jvm data transfer is so painful with
sparkr RPC... (here http://dsnotes.com/articles/r-read-hdfs I made some
timings for transfer of small data.frame)
Of course I don't have full information about goal of this package (but I
think, main goal is to create foundation for dplyr backend ), but I'm not
sure it is good idea to use it. Mb something that relies on rJava will be
much better choice. Hope this may be useful.
Also I will be happy to contribute when project will have roadmap.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rstudio/sparkapi/issues/1, or mute the thread
https://github.com/notifications/unsubscribe/AAGXxx2iP0_B-1BdXpV0686lK_NMX05Bks5qN7j5gaJpZM4I6kXs
.

ok, good to know, closing...


how to config transform

// .swcrc
[
    {
      "test": ".tsx?$",
      "jsc": {
        "parser": {
          "syntax": "typescript",
          "tsx": true,
          "decorators": false,
          "dynamicImport": true
        },
        "transform": {
          "react": {
            "throwIfNamespace": false
          }
        }
      }
    },
]

this is no work

Yeah this is not configurable. What is missing for you?

It would be great to be able to configure "throwIfNamespace": false. As far as I can tell, React supports JSX namespaces at least as far back as v17.

Can you provide an example usage via stackblitz with the Babel version? I'm never encounter them.
If this is something, maybe you should ask to change the default in SWC


Blogger / Blogspot issue

 Issue by ontopicprojects
Mon Oct  5 15:37:20 2020
Originally opened as https://github.com/codelucas/newspaper/issues/847

Some blogspot / blogger sites don't seem to parse:  here is an example:
`from newspaper import Article
url = 'http://www.righto.com/2011/07/cells-are-very-fast-and-crowded-places.html'
article = Article(url)
article.download()
article.parse()
print(article.text)`
this prints ""

Works in v0.9.1


fix: description of github action

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


feat: add support for ActionImport and FunctionImport

Introduces a separate type representing both <ActionImport> and <FunctionImport> (similar to the single type representing both <Action> and <Function>).
I hope that this can improve robustness when looking up the actions from annotations - UI.DataFieldForAction  (and hopefully be useful in the mockserver, too).
Another option (hack!) could be to erase the ActionImports by adding the referenced Action under the ActionImports FQN into the set of actions. The drawback of this option is that the converted data would end up with actions that actually do not exist (because they do not have their original FQN any longer).

The code looks nice but i'm unsure about the concept behind and the implication there are with it, can you quickly explain that here ?

In the existing implementation the annotation converter fails to resolve unbound actions when processing DataFieldForAction annotations. That is, the DataFieldForAction.ActionTarget property stayed undefined.
TL;DR: the goal primarily was to fix that.
But there is another aspect: Unbound actions can only be called if they are exposed as action imports in the entity container. This implies that DataFieldForAction annotations must use the action import path in the annotation, not the action.
With the exiting implementation, both got mixed up in terms of Action vs. ActionImport, but also OData 2 vs. OData 4 (both have a FunctionImport, but they work differently). So it is not that straightforward to separate them in the converter. The converter might resolve something that is not callable from an OData perspective.
I think implications on other components are limited and mostly affect consumers of the annotation converter. They must provide the additional actionImports property when using it. If they just provide an empty array to satisfy type constraints, it will fail to resolve unbound actions, as before. Other than that, the action target resolution now works much better 😃
Also, the action parameters have an isEntitySet flag. It does not have any effect and probably can be removed? #188


Honister Humble Build fails on graphviz with demo image

Describe the bug
Configuration of graphviz fails during build of the recipe outlined in this article: https://news.accelerationrobotics.com/ros-2-humble-in-nvidia-xavier-agx-with-yocto/
To Reproduce
Branch: honister-humble
Target: Jetson Xavier AGX devkit
BSP: meta-tegra
Platform information:
coalman321@ros-ws:~/$ uname -a Linux ros-ws 5.13.0-44-generic #49~20.04.1-Ubuntu SMP Wed May 18 18:44:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Build Configuration:
BB_VERSION           = "1.52.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-20.04"
TARGET_SYS           = "aarch64-oe4t-linux"
MACHINE              = "jetson-agx-xavier-devkit"
DISTRO               = "tegrademo"
DISTRO_VERSION       = "3.4.3+snapshot-20220606"
TUNE_FEATURES        = "aarch64 armv8a crc"
TARGET_FPU           = ""
DISTRO_NAME          = "OE4Tegra Demonstration Distro"
ROS_DISTRO           = "humble"
ROS_VERSION          = "2"
ROS_PYTHON_VERSION   = "3"
meta                 = "HEAD:580532cfd0c23e27a366c074e806fc0b6908b874"
meta-tegra
contrib              = "HEAD:b2481c12ae0468c85b76332faa2922682245e185"
meta-oe
meta-python
meta-networking
meta-filesystems     = "HEAD:a19d1802b15fe07e9b1e7584ff9af7c33bfe642a"
meta-virtualization  = "HEAD:bd7511c53b921c9ce4ba2fdb42778ca194ebc3e8"
meta-tegra-community = "HEAD:4a47d3798404904eec5299306d063a6ec753b158"
meta-tegra-support
meta-demo-ci
meta-tegrademo       = "honister:a70a14f6403955d62ca53ba19254efa75d29e6f6"
meta-ros2
meta-ros2-humble
meta-ros-common      = "honister-humble:20927e8fcf5cea099386a0933f95bb312b4f295d"

The specific error given by bitbake on exit is:
ERROR: graphviz-native-2.44.1-r0 do_configure: configure failed
ERROR: graphviz-native-2.44.1-r0 do_configure: ExecutionError('/home/coalman321/tegra-bsp-honister/build/tmp/work/x86_64-linux/graphviz-native/2.44.1-r0/temp/run.do_configure.1465090', 1, None, None)
ERROR: Logfile of failure stored in: /home/coalman321/tegra-bsp-honister/build/tmp/work/x86_64-linux/graphviz-native/2.44.1-r0/temp/log.do_configure.1465090

The full logs are located in this gist: https://gist.github.com/coalman321/d0295d4572815c4ab32dffe586d5c32b
Expected behavior
Expected to build a demo image as demonstrated in the article.
Any help on this would be appreciated. Thank you.
@vmayoral Any suggestions here? I can build the tegrademo fine but one of the meta-ros dependencies seems to cause the issue above. I'm wondering if I am missing specific dependencies on the system to make this work correctly.

Thanks for the report @coalman321, this is a nicely explained/written support ticket.
I've experienced this before myself and wrote about it at https://news.accelerationrobotics.com/ros2-humble-yocto-petalinux/#graphviz-dpkg-architecture-command-not-found.
In a nutshell, what worked for me:
sudo apt-get remove libtcl8.6
sudo apt-get update
sudo apt-get install blt libopencv-contrib-dev libopencv-dev libopencv-viz-dev libopencv-viz4.5d libtcl8.6

And then re-build again the graphviz recipe.

@coalman321 if that addresses your issue and you move beyond this, can you comment in here if you successfully manage to build all the recipes for humble?

@vmayoral
Yes that package change does fix the graphviz configuration for ubuntu 20.04. As a quick note, the libopencv-viz4.5d package does not exist in 20.04, and may be causing other issues as opencv from the meta-oe layer is now failing to compile.
I have put together another gist of the relevant logs here:  https://gist.github.com/coalman321/47e4a4eeb020f508922d47a011c8e4e1
The opencv error as far as I can tell looks to be an assembler error. I'm not sure why that would happen but it sure does cause a lot of terminal spam... Also there are failures on the example packages. I haven't taken a look at those failures yet though.
Build results.
NOTE: Tasks Summary: Attempted 10119 tasks of which 5888 didn't need to be rerun and 5 failed.

Summary: 5 tasks failed:
  /home/coalman321/tegra-bsp-honister/layers/meta-ros/meta-ros2-humble/generated-recipes/examples/examples-rclcpp-multithreaded-executor_0.15.0-2.bb:do_compile
  /home/coalman321/tegra-bsp-honister/layers/meta-ros/meta-ros2-humble/generated-recipes/demos/demo-nodes-cpp-rosnative_0.20.1-2.bb:do_compile
  /home/coalman321/tegra-bsp-honister/layers/meta-ros/meta-ros2-humble/generated-recipes/examples/examples-rclcpp-minimal-service_0.15.0-2.bb:do_compile
  /home/coalman321/tegra-bsp-honister/layers/meta-ros/meta-ros2-humble/generated-recipes/demos/demo-nodes-cpp_0.20.1-2.bb:do_compile
  /home/coalman321/tegra-bsp-honister/layers/meta-oe/recipes-support/opencv/opencv_4.5.2.bb:do_compile
Summary: There were 5 ERROR messages shown, returning a non-zero exit code.

@coalman321, the details above don't help assessing your error. Can you paste your actual error while building the opencv recipe? Note that you need to make sure you have enough memory/SWAP to build certain recipes.

@vmayoral,
My apologies. I missed checking the log to see if it had relevant information. I located the cmake build logs for opencv. It looks like the assembler error may have been a distraction, as the errors that cmake shows look to be related to opencl support. The gist with actual logs is here: https://gist.github.com/coalman321/3afaaaca614acbd0aa97bbe7df981a09 . I would suggest looking at the CMake logs first, but the Ninja outputs have been provided as well.

The gist with actual logs is here: https://gist.github.com/coalman321/3afaaaca614acbd0aa97bbe7df981a09

Had a quick look. It's still a bit unclear but from the error dumps I couldn't see any issues related to meta-ros recipes. It appears you've got indeed some build issues with opencv (which is totally unrelated to meta-ros), but that's something else. Can't put time into debugging that, sorry.
It seems your current meta-ros issue has been addressed with the Humble branch @coalman321- If so, can we close this ticket? (feel free to open another one if other issues appear).
I'd suggest bringing the opencv issue you're experiencing elsewhere (e.g. maybe to the https://github.com/OE4T/meta-tegra repo? you'll need to ask there).

I did some additional testing by re-running the build. It never ran out of memory during the compile and is currently only failing at the minimal service example now. I’m not sure if it was able to re-run the others to know if those successfully completed.

I think the original error here has been resolved on my end with the package change. It looks like the OpenCV failure was unrelated, and now gone so I’ll close the ticket out.


Wacked Planet 001a.zip
Here is the file, of note you will have to fly to the planet that exhibits this behavior. Small moon orbiting a gas giant (or frozen giant, I forget which).

Just to be totally clear, were you using this mod when you first made the
save, or are you loading an existing save after freshly installing the mod?
On Sat, Feb 27, 2021, 5:22 PM Sherkhan-1<EMAIL_ADDRESS>wrote:

Wacked Planet 001a.zip
https://github.com/Touhma/DSP_Plugins/files/6055658/Wacked.Planet.001a.zip
Here is the file, of note you will have to fly to the planet that exhibits
this behavior. Small moon orbiting a gas giant (or frozen giant, I forget
which).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Touhma/DSP_Plugins/issues/36#issuecomment-787196536,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJCSF7MTY2ZNQPS5IRPY5TTBFWAPANCNFSM4YKIKA2A
.

Nope - started a brand new play through with this mod from the get-go.

alright
We might have a fix for it coming soon
hang on !

Same bug (probably),
When I jumped back to my home system, I got the big bad red message, and well, screenshot attached

ps : reloading the game fixed the graphical bug for me, so maybe not the same issue ?
pps:  1.1.2

I've had a similar issue, however, it seems to only occur where i've placed items.  Had the ground in a perfect little belt line, then where all my miners and smelters were.

And another one.  All where I've built things.  This occured when leaving the planet and coming back.  Maybe something to do with LOD?

To note, Saving and reloading the game (Didn't exit the game) fixes the issue, until you leave the planet and come back.

well, saving and reloading certainly did not fix my issue though.

should be fixed in 1.3.0

Well, the save did not survive whatever the fix is - hehe... Here is what the home planet looks like now (note: The pretty lights in space was my research, and other factory stuff)


Changed some words in the IPv4/IPv6 dual-stack korean doc.

This is a Bug Report
Problem:
The Korean team transliterated the word masquerading.
Proposed Solution:
we should change the word translated 위장 to 마스커레이딩.
Page to Update:
https://kubernetes.io/ko/docs/concepts/services-networking/dual-stack/
/language ko

/assign


Avoid using named functors in nested_executor & flattened_executor

The code is so confusing. We should be able to deduce the type of the lambda parameters without resorting to functors.

Try to do this one at the same time as #248


E2E test of challenging

Description
Implements a basic e2e test for challenging-v0
Basic Test Outline

seeds the channel in the database ( to simulate co-operative open)
funds the channel on chain based on the channel's outcome
Calls challenge on the wallet
mine blocks until the wallet detects the challenge
Verify that the adjudicator status gets set to 'Challenge"
mine a block with a timestamp>=finalizesAt
Verify that the adjudicator status gets set to 'Finalized"
Verify that both the payer and receiver have received funds based on the outcome.

Shortcomings

This does not test handling a challenge as a receiver as that's out of scope for challenging-v0.
The test only tests the "happy" path

Checklist:
Code quality

[x] I have written clear commit messages
[x] I have performed a self-review of my own code
[x] This change does not have an unduly wide scope
[x] I have separated logic changes from refactor changes (formatting, renames, etc.)
[x] I have commented my code wherever necessary (can be 0)
[ ] I have added tests that prove my fix is effective or that my feature works, if necessary

Project management

[x] I have applied the appropriate labels
[x] I have linked to all relevant issues (can be 0)
[x] I have added all dependent tickets (can be 0)
[x] I have assigned myself to this PR
[x] I have chosen the appropriate pipeline on zenhub

Is this a fix? Is it fixing a bug?

I think so? It was a fix of broken behavior. Or do you expect a fix to correspond to a issue/ticket?

Is this a fix? Is it fixing a bug?

I think so? It was a fix of broken behavior. Or do you expect a fix to correspond to a issue/ticket?


something broken with filterConfs.py?

Got this in the plan2pyrB set:
Traceback (most recent call last):                                                                                File "/work/cluster/limvt/qm_AlkEthOH/pipeline/01_scripts/executor.py", line 123, in <module>                                                                                main(**opt)                                                                                File "/work/cluster/limvt/qm_AlkEthOH/pipeline/01_scripts/executor.py", line 79, in main                                                                                filterConfs.filterConfs(osdf, tag, suffix)                                                                                File "/data12/cmf/limvt/qm_AlkEthOH/pipeline/01_scripts/filterConfs.py", line 163, in filterConfs                                                                                if IdentifyMinima(mol,tag,thresE,thresRMSD):                                                                                File "/data12/cmf/limvt/qm_AlkEthOH/pipeline/01_scripts/filterConfs.py", line 56, in IdentifyMinima                                                                                if not oechem.OEHasSDData(testmol, Taglabel):                                                                                File "/beegfs/DATA/mobley/limvt/local/miniconda3/envs/oepython3/lib/python3.6/site-packages/openeye/oechem.py", line 25343, in OEHasSDData                                                                                return _oechem.OEHasSDData(*args)                                                                                NotImplementedError: Wrong number or type of arguments for overloaded function 'OEHasSDData'.                                                                                Possible C/C++ prototypes are:                                                                                OEChem::OEHasSDData(OEChem::OEMolBase const &)                                                                                OEChem::OEHasSDData(OEChem::OEMolBase const &,std::string const &)

Fixed with commit 68002e1


Make electron-screenshot a separate module?

The electron-screenshot directory would make a handy module on it's own. It could be used from within Electron app. Like https://github.com/JamesKyburz/electron-screenshot but more full featured.

I just created electron-screenshot-app which contains the core functionality.


Updated and added testing of tokenize by file input

Related #80.
Tokenize testing was in progress, so updates and additions have been made.
As a result, advanced succeeds, but basic fails.
Referring to the following, ... is Spread
https://github.com/erg-lang/erg/blob/870f88e14d47b0cd57c11992ec45dd94175c7057/compiler/erg_parser/token.rs#L156-L157
... will be tokenized to EllipsisLit
a, _, ...b = five_elem_tuple

I would like you to determine if the execution results are correct or if the comment is correct.
Also, I have created this as a draft, since I want you to determine if other files should be tested as well.
Changes proposed in this PR:

Updated basic syntax test(failed)
Added new test for advanced syntax(success)
Updated priority values(success)

9/14 update

Rename file test to tokenize_test
Add tests for literals as currently implemented(success)

@mtshiba

Thank you.
Some of the grammar was outdated and has been corrected.


Can you help to setup the carrierwave gem with digital ocean with block storage?

I would like to user block storage of digitalocean for storing the images and files, and need to help to do with fog-digital ocean and carrierwave gem.

up

up

👍

For CarrierWave and DO Spaces (instead of AWS S3):

Generate access key here: https://cloud.digitalocean.com/settings/api (Under Spaces access keys)
Edit config/initializers/carrierwave.rb to:

CarrierWave.configure do |config|
  config.fog_credentials = {
    :provider               => 'AWS',
    :aws_access_key_id      => [YOUR_ACCESS_KEY],
    :aws_secret_access_key  => [YOUR_SECRET_KEY],
    :region                 => 'nyc3',
    :endpoint               => 'https://nyc3.digitaloceanspaces.com'
  }
  config.fog_directory  = 'your-space-name'
  config.fog_attributes = {'Cache-Control'=>'max-age=315576000'}
end

Restart your server and enjoy it !

Use Digital Ocean Space storage if in staging
CarrierWave.configure do |config|
    config.storage = :fog

    config.fog_provider = 'fog/aws' # required
    config.fog_credentials = {
        provider: 'AWS', # required
        aws_access_key_id: [YOUR_ACCESS_KEY], # required
        aws_secret_access_key: [YOUR_SECRET_KEY], # required
        region: 'nyc3', # required
        endpoint: 'https://nyc3.digitaloceanspaces.com' # required
    }

    config.fog_directory = 'your-space-name' # required
    # config.fog_public = false # optional, defaults to true
    config.asset_host = "https://#{config.fog_directory}.nyc3.digitaloceanspaces.com"
    config.fog_attributes = { 'Cache-Control' => 'max-age=315576000' } # optional, defaults to {}
end

Not sure if anybody has had this issue, but I am fighting using the fog/aws provider for carrierwave when doing authenticated urls. Please note, the below config works when replacing fog_public as true. Thanks in advance for your help or pointers.
  config.fog_credentials = {     provider:              'AWS',                        # required     aws_access_key_id:     yyy,                        # required     aws_secret_access_key: zzz,                        # required     region:                'nyc3',                  # optional, defaults to 'us-east-1'     host:                  'nyc3.digitaloceanspaces.com',             # optional, defaults to nil     endpoint:              'https://nyc3.digitaloceanspaces.com' # optional, defaults to nil   } config.fog_directory  = Rails.configuration.x.aws.s3_media_bucketconfig.fog_public     = false config.fog_attributes = { cache_control: "public, max-age=#{365.days.to_i}" } config.fog_authenticated_url_expiration = 3600

In my answer, I forgot to mention that I was not using 'fog-digitalocean', I was using 'fog-aws';
I'm not really sure, I have changed of provider four months ago;
Give it a try!

@davidplappert I also ran into issues with the v4 API. Downgrading to aws_signature_version to 2 makes the download work. See https://github.com/fog/fog-aws/issues/428#issuecomment-401248048 for more details.


test(extension): disable flaky test LW-7819

Allure Report
allure-report-publisher generated test report!

processReports: ✅ test report for 220897ec

passed
failed
skipped
flaky
total
result

Total
32
0
0
0
32
✅


Null safety

are you going to put out a release for null safety? would you merge a pr and release or should i fork? thanks

Hi Jay. Sure I will really appreciate if you can open a PR. I will merge and create a release.
Thanks

I just realized I found one that would work.
And appeared to already have other years. Does look cool though. Maybe you
can merge in the existing pull request.
I wouldn't mind doing it to be honest but I'm really behind on my current
project.
I'll snooze your message and check back in a few months perhaps.
Sorry about the trouble.
....sent from my phone
On Sun, Sep 4, 2022, 3:22 PM Rohan Malik @.***> wrote:

Hi Jay. Sure I will really appreciate if you can open a PR. I will merge
and create a release.
Thanks
—
Reply to this email directly, view it on GitHub
https://github.com/404shades/Gender-Selection-Flutter/issues/4#issuecomment-1236408956,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXBGYJ3VY3BRS6C5D3GIP3V4UAHRANCNFSM6AAAAAAQEOPJOU
.
You are receiving this because you authored the thread.Message ID:
@.***>


Coverage testing CharmFL-dev

Describe the bug
After we run the built-in coverage test the program describes code coverage as seen below on screenshot:
To Reproduce
Steps to reproduce the behavior:

Go to Pycharm, open CharmFL-dev project.
Click on main.py, More Run/Debug, run 'main' with coverage to see coverage test results.
Browse file structure to see respective coverage results.
According to the test mere 45% of main.py is covered, meaning less than half of it is actually used during running, leaving the rest of it as dead code. It is not unforseen in big, legacy projects or just 8-10 year old, never-refactored projects but not expected in small, dense projects like this.

Expected behavior
It is expected that the overall coverage of src folder should be well above 70-80%.

Desktop (please complete the following information):

It may be irrelevant, however I provide the environment information:
OS: [Linux, debian]
Browser [mozilla]
Version [92]

Additional information

By default I wanted to test a small python project found on github, however due to technical issues during the environment setup I failed to test the above mentioned small project thus decided to test the sourcecode of the plugin itself, which is always interesting. It gives a better understanding about how certain programs work as intended even tough producing average (or even below average) scores on tests such as coverage tests.

The tests are still under development, hence the coverage for the backend's code will not result in high scores.


Please change background

It's distracting.

Hi
I removed the background and it's now a white screen.
Thanks,
nikhilhex


Added new modified client and rabbitmq images. Updated genesis block.

@gluckzhang

That's a great fix. Thanks @javierron ! We may also propose some of these changes to the original repo someday later :)


Setup apt-repo for Debian

Done here - https://bintray.com/zulip/debian/zulip-electron
Instructions added in - https://github.com/zulip/zulip-electron/commit/949d786f1f1d467484d29d8560edcb5491a0f126


TLS certificates generated by TLSCA do not contain IP SANs

I see the following error when I enable TLS for peer communication
2016/04/01 05:36:02 grpc: ClientConn.resetTransport failed to create client transport: connection error: desc = "transport: x509: cannot validate certificate for a.b.c.e because it doesn't contain any IP SANs"; Reconnecting to "a.b.c.e:30303"
I have enabled TLS for peer by setting the following environment variables.
OPENCHAIN_PEER_TLS_ENABLED=true
OPENCHAIN_PEER_TLS_CERT_FILE=/var/openchain/production/crypto/validator/test_vp2/ks/raw/tls.cert
OPENCHAIN_PEER_TLS_KEY_FILE=/var/openchain/production/crypto/validator/test_vp2/ks/raw/tls.key

Am I missing something here ?

@diegomasini, please, may you take care of this?

@adecaro @JonathanLevi is this still an issue or can it be closed?

Hi,have you fix this issue? I have met the same problem.


[BUG] --server-addr不生效

Description
使用 illa deploy 时  --server-addr 不生效
Steps to reproduce

运行illa deploy --port=10000 --server-addr=<IP_ADDRESS> --self
得到输出✨  ILLA Builder started, please visit http://localhost:10000
无法通过<IP_ADDRESS>:10000访问

ILLA Builder Version
1.2.5
Browser
No response
Operating System

[ ] macOS
[ ] Windows
[X] Linux

Additional Information
No response

@myuanz I run the same command with a public IP address, and it works. So, it's difficult for me to predict what will happen with a private IP address.

Hello, <IP_ADDRESS> is a class B address, and the server and my device are in the same LAN (I connect to it through ssh). So I think whether it's a public IP or not might not be relevant to the problem.
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b0:7b:25:20:05:55 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/20 brd <IP_ADDRESS> scope global dynamic noprefixroute enp2s0
       valid_lft 17281sec preferred_lft 17281sec
    inet6 2400:dd02:1011:2:12d2:96bb:bc75:18e6/128 scope global dynamic noprefixroute
       valid_lft 558sec preferred_lft 558sec
    inet6 fd00:6cb1:5823:576c:b487:705:704c:65bb/64 scope global deprecated dynamic noprefixroute
       valid_lft 30291sec preferred_lft 0sec
    inet6 fe80::a4fe:1522:aeb3:73a7/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

@myuanz please provide more information on this problem, such as docker logs, API requests, and responses.

closed due to no response over 5 days.


Computing requirements

This works very well. May I ask what are the computational requirements of this method, such as the GPU model and number, and how such a large data set is stored?

Hi, we run all of the experiments on A100 GPU devices and the dataset is stored in the Azure storage. Theoretically, Ampere GPU devices like A6000 should also work.

How about the cost for pretraning DINOv2 on your 1384M tile dataset, i mean the number of nodes, GPUs on each node and the time cost for a complete trial.  I would be greatful if you can show me the loss curves. Thank you ！


Network Icon

Folder Category: Containers related to networking
Animation Suggestion: ?
File:network.zip

I think it should open with only the top center rectangle visible. Then a mask covering  the lines and bottom boxes slides down revealing them. The bottom portion then fades out and the animation loops again.
As an alternative ( and possibly preferable), Do the icon as a line animation, where the icon draws itself and then the color fills fade in while the strokes fade out. Line animation like:
https://medium.com/bitmatica-lab/svg-line-animation-for-the-uninitiated-5a65d91c6044

I decided to animate this one with a packet being transmitted since I ended up doing a fade for dependencies. Let me know what you think. Added in 7a8d68220869685d7b64a7213595b880fd84238e


Edit custom cluster does not have Save button

Rancher versions: 2.0 master 3/7
Steps to Reproduce:

Create a custom cluster
Edit cluster

Results:  Save/Cancel buttons are missing. Should be there since I can Add/remove Members from this screen

Version - 2.0 master 3/11
Verified fixed


style matrix (2.3)

styles.yaml is still very annoying to configure, unfortunately most config files don't support for loops. Use matrices (more like jagged arrays) to speed up configuration via "multiplicative inheritance" (avoid having to write python scripts to generate style files, or worse write the styles by hand)
- matrix:
  - - style_id: style-1
    - style_id: style-2
  - - style_id: style_3
    - style_id: style_4

# is equivalent to

- style_id: style-1
- style_id: style-2
- style_id: style-3
- style_id: style-4
- style_id: style_3-style-1(style-1)
- style_id: style_3-style-2(style-2)
- style_id: style_4-style-1(style-1)
- style_id: style_4-style-2(style-2)

Can combine multiple rows (though flatter rows will give shorter names)
- matrix
  - row-1
  - row-2
  - ...
  - row-n

Now add some commonly used rows as aliases
- matrix:
  - row: grid4-complete # a built-in row covering every grid4 configuration

# equivalent to

- style_id: "00"
  box_data.grid4: [0, 0]
- style_id: "01"
  box_data.grid4: [0, 1]
- ...
- style_id: "44"
  box_data.grid4: [4, 4]

allows
- matrix:
  - - style_id: character
  - row: grid4-complete

# equivalent to

- style_id: "00"
- ...
- style_id: "44"
- style_id: character
- style_id: character-00(character, 00)
- style_id: character-01(character, 01)
- ...
- style_id: character-44(character, 44)

Probably also a good idea to add a 'nickname' for a style, so we don't have to write long names.
Order matters, style ids will be concatenated together in the order in which they appear in the rows of matrix.
Intention is to remove the dash between two style ids (just for demonstration purpose)

neutra;l netwprds


Airline theme is not working properly

The airline theme is not working.

Airline support was removed, if you want that theme checkout nvcode.vim it's archived.


Auto refresh file list in network shares

Resolved / Related Issues
Items resolved / related issues by this PR.

Closes #5869

Details of Changes
Add details of changes here.

Listen for directory changes in network shares using FTP

Validation
How did you test these changes?

[x] Built and ran the app

@yaichenbaum could you deploy a beta for testing this? This bug was sneaky and while debugging in VS the networks folders refreshed as expected, and for some reason with VS 2022 I can't create any longer packages to install it.

Perhaps you can test the release azure build? Should be the same as the sideload version:
https://dev.azure.com/filescommunity/db556b89-8bf0-4c03-8053-434c8f8714ff/_apis/build/builds/11016/artifacts?artifactName=drop&api-version=7.0&%24format=zip

A couple of notes:

I've just noticed the linked issue was also about MTP folders. This PR does not help with them, only with network folders.
Folders will stop update if you minimize and restore the app untill you refresh once. I'm still thinking how to fix this but should not be a blocking point.

Folders will stop updating if you minimize and restore the app untill you refresh once. I'm still thinking how to fix this but should not be a blocking point.

Can this be resolved by automatically triggering a refresh when the app resumes from being suspended?

Yeah that should be the easiest path. Just have to refresh network folders and not all of them.

Yay! Fixed point (2) without the need to refresh the items.

@gave92 Just curious if maybe in a separate PR we can evaluate whether a StorageLibraryChangeTracker would suffice for MTP locations?

We tried that didn't we? Turned out to not work for generic folders iirc?

@gave92 I thought we tried that for network attached storage locations. I heard from Microsoft it does work for local StorageFolders.  From a quick check, MTP does not work either I'm getting an "invalid path" exception when getting the tracker). Let me know if you have better luck 🤞.

@gave92 this is just for network drives, right? I tried 2 FTP's servers and it doesn't refresh there.
On the network drive now it's working as expected btw.

Good. Yes it's network drives only (and not even all network drives). The other devices (ftp, mtp) don't send filesystem notifications this way (or at all).
Solution for those would simply be to update the list when a file operation done from Files completes.

Edited PR description to not close the linked issue, since it's a partial solution.


c2cpg: method fullname contains absolute filepath of the source directory

importCode.c("/home/mp/Projects/shiftleft/codescience/sptests/code/c/damn-vulnerable-c")

cpg.method.fullName(".*codescience.*").l
// 13 results, which mostly look like this:
  Method(
    id -> 51351L,
    astParentFullName -> "/home/mp/Projects/shiftleft/codescience/sptests/code/c/damn-vulnerable-c:<includes>:<global>",
    astParentType -> "NAMESPACE_BLOCK",
    code -> "<global>",
    columnNumber -> None,
    columnNumberEnd -> None,
    filename -> "/home/mp/Projects/shiftleft/codescience/sptests/code/c/damn-vulnerable-c:<includes>",
    fullName -> "/home/mp/Projects/shiftleft/codescience/sptests/code/c/damn-vulnerable-c:<includes>:<global>",
    hash -> None,
    isExternal -> false,
    lineNumber -> Some(value = 1),
    lineNumberEnd -> None,
    name -> "<global>",
    order -> 1,
    signature -> ""
  )

I'd expect something like

astParentFullName=<includes>:<global>
fullName=<includes>:<global>
not sure about filename tbh...

I had a look in the frontend code: the fullname is set in https://github.com/joernio/joern/blob/master/joern-cli/frontends/c2cpg/src/main/scala/io/joern/c2cpg/astcreation/AstCreator.scala#L86, and it takes it from the GlobalNamespaceBlockFullName, which is set at https://github.com/joernio/joern/blob/master/joern-cli/frontends/x2cpg/src/main/scala/io/joern/x2cpg/AstCreatorBase.scala#L29

Easy fix would look like the one used in jssrc2cpg: https://github.com/joernio/joern/blob/master/joern-cli/frontends/jssrc2cpg/src/main/scala/io/joern/jssrc2cpg/astcreation/AstCreator.scala#L61

depends on some internals which we're discussing on slack including @fabsx00

Done with: https://github.com/joernio/joern/pull/2090 and follow-ups.


Update WATCHOS_DEPLOYMENT_TARGET to 3.0 for Submission to Apple

With Xcode 10 apple no longer support  WATCHOS_DEPLOYMENT_TARGET under 3.0.
https://github.com/ReactiveX/RxSwift/issues/1752

👍 You update is released in version 13.


label update v2020-12-08 = 1.24.2

Issue Number

Overview
Just a label update in readme.
Comments

I think no re-tag.

bors r+


Apollo server v2

Hi,
Apollo server v2 came out yesterday and they have File Upload enabled by default.
do you think is there any use case for this package anymore?

As you can see here this package is what lets apollo server support file uploads, so it's probably worth keeping around :)

Nice!
So because it's now part of Apollo-server-core we don't need to install it separately?

I haven't tried the default settings in Apollo 2.0 (that's on the list for today) but I do believe that's correct!


Create subset exports

@celineaubert is beginning to create subsets using the in_subset AP. We should start exporting these for easy consumption by developers. Our recipe from ENVO (which will be a bit different from what we need here) is summarised below:

First, we create a "simple" version of the ontology as a sort of subset in itself using owltools. The Makefile drives this here. We should try to avoid the need to create an OBO version (here) and make the point below only rely on the simplified OWL file. @cmungall is that possible?
With the basic file (currently an OBO file in ENVO), we can use owltools' subset extraction to pull out named subsets. See these lines

@marieALaporte, perhaps you could try to implement this?

@marieALaporte points out that there may be no need for OWL subsets at this stage.We agree that generating flat files of all classes in each subset may have more immediate use for the developers of the fieldbook.
Thus, (correct me if I'm wrong @marieALaporte) we'll fuse the idea of subsets and reports (#11) and export flat files containing the IDs, labels, and definitions of classes in subsets.

Since the "subset reports" will be SPARQL-driven, perhaps the other reports from #11 can be done en passant:

Over in ENVO, we create simple tabular files for non-owl-inclined software developers to work with. These are dubbed "reports" and are simplistic exports of the ontology content. As this is SPARQL-driven (via arq and jena), perhaps you'd like to take a crack at impementing (and improving?) this @marieALaporte?

Our  sparql files produces reports. The Makefile drives this in these lines

If you do want subsets, then another method is to keep a list of URIs in a file or spreadsheet and then MIREOT the subset. YMMV.
For SPARQL, we have an open ticket to do this from Robot https://github.com/ontodev/robot/issues/24
But for now arq is probably easiest. One extra moving piece, mildly annoying.


Add a warning/error message for cubes with dimensions of 0

Expected Behavior
Give an error and continue to render fine when a cube is created with 1 or more dimensions equal to 0.
Actual Behavior
Browser loads forever until a memory overflow (presumably).
Steps to Reproduce the Problem

Load the attached JSCAD file.
See that it loads fine as it is.
Change the cube on Line 26 to be: cube([1000, 0, 0]).
Reload.
It loads forever until a memory overflow (presumably).

Specifications

Version: 1.9.0
Platform: Windows
Environment: browser
Arm Rest Clamp.txt

@ThePiGuy thanks for the request.
We aren't sure how much checking of parameters should be performed, however V2 does additional checks.
  if (!Array.isArray(size)) throw new Error('size must be an array')
  if (size.length < 3) throw new Error('size must contain width, depth and height values')

The new V2 JSCAD API looks like this...
/**
 * Construct an axis-aligned solid cuboid in three dimensional space.
 * @param {Object} [options] - options for construction
 * @param {Array} [options.center=[0,0,0]] - center of cuboid
 * @param {Array} [options.size=[2,2,2]] - dimensions of cuboid; width, depth, height
 * @returns {geom3} new 3D geometry
 * @alias module:modeling/primitives.cuboid
 *
 * @example
 * let myshape = cuboid(size: [5, 10, 5]})
 */


Unable to load Interop.UIAutomationClient.dll

Hi,
I'm getting an exception when trying a very simple test to load a WPF app:
System.IO.FileNotFoundException : Could not load file or assembly 'Interop.UIAutomationClient, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=5b28cd3eabb9203e' or one of its dependencies. The system cannot find the file specified.  at Gu.Wpf.UiAutomation.Application..ctor(ProcessReference process, Boolean isStoreApp)    at Gu.Wpf.UiAutomation.Application.Launch(ProcessStartInfo processStartInfo, OnDispose onDispose) in C:\Git\Gu.Wpf.UiAutomation\Gu.Wpf.UiAutomation\Application.cs:line 314    at Gu.Wpf.UiAutomation.Application.Launch(String exeFileName, OnDispose onDispose) in C:\Git\Gu.Wpf.UiAutomation\Gu.Wpf.UiAutomation\Application.cs:line 289
I can see the DLL in the packages, so I recon it is a dependency problem.
My test code is:
   [TestFixture]     public sealed class MyTestFixture     {         [Test]         public void Test()         {             using (var app = Application.Launch("TestWpfApp.exe"))             {                 System.Threading.Thread.Sleep(5000);             }         }     }
The test app appears and stays open. The exception occurs immediately (before the sleep).
Details:

Using Nuget package v0.1.17
Windows 10 host
Test assembly is targeting .Net 4.6.1
WPF test app is also .Net 4.6.1, empty window.

This is my first go at using this framework ... have I missed something?
Thx
Rob

it sounds like a problem with .net 4.6.1. If you change project to .net 4.5 the exception will gone?

Hi,
Changing the projects to .net 4.5 has no effect. Error remains as reported.

Ah, now I look closer I have found that the problem is that the "Interop.UIAutomationClient" assembly is not copied to the output folder. If I manually copy it the problem is fixed.
The reference in my project file (added by the NuGet package) is:
   <Reference Include="Interop.UIAutomationClient, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=5b28cd3eabb9203e, processorArchitecture=MSIL">       <HintPath>..\packages\Gu.Wpf.UiAutomation.<IP_ADDRESS>\lib\net45\Interop.UIAutomationClient.dll</HintPath>       <EmbedInteropTypes>True</EmbedInteropTypes>     </Reference>
I'm not familiar with the 'EmbedInteropTypes' element here. I'm not able to configure the reference to have a local copy in VS2017.
How do I fix this?
Thanks
Rob

Sounds like we may have dumbed the packing somehow, I have only used it with Paket, maybe nuget does things differently. Ideally we should remove the interop dll, maybe we can use ILMerge or somethin.
Thanks for reporting, we'll try to repro and fix.

@RobSmyth If you have time you can clone the repo and run the tests, if that works chances are the difference is nuget.exe.

Repro with nuget.exe was easy, question is how to fix it in a nice way. Copy local was set to true by default but that did not copy the dll.
Surprisingly setting <EmbedInteropTypes>False</EmbedInteropTypes> made it copy on build, guess that is a hack solution but we should find something nicer.

I'm gonna have a go ad embedding the interop assembly in https://github.com/JohanLarsson/Gu.Wpf.UiAutomation/tree/embed
I don't know much about COM but it seems constants cannot be embedded. Strategy is to hardcode constants in Gu.Wpf.UiAutomation and throw tests at it.

Hi,
I found that deleting Interop.UIAutomationClient.dll from my project fixed the problem. It appears I do not need it. So it looks like it was trying to load it as it was a reference in my project, although not used.
Do we need this assembly in the distribution?
Rob

We need to find a nicer solution for this, other libraries use a PS script in the tools folder of the package that changes  on install.
TBH I'm not sure we need the interop thing at all. Hopefully we can refactor away from it. The issue is great!

Refactored away from the interop thing. Cleaning up some more stuff before releasing, will be bumped major due to some breaking changes, hopefully the most used APIs will not be affected much.

I'm closing this, new version uses UIAutomationClient and UIAutomationTypes and no interop dll.
This refactoring meant a couple of breaking changes but hopefully it did not touch the common APIs too much.


#21 Ft logout 21

What does this PR do?
Create, read, update and delete routes
Description of Task to be completed?
As an authenticated user, I want to be able to logout, so that none else can access my account as well
How should this be manually tested?

Trello Board
Screenshots (if appropriate)
N/A

Questions:
N/A

Good work! I am little confused here, is email and password needed to logout?


Cant find plugin in package control

Hi,
I installed sublimelinter by package control but still there is no SublimeLinter-jshint plugin in the list of packages for install.
Also i checked disabled plugins, There's nothing.
How can i find this plugin in package control?!

I have the same problem. You can get around it by adding the repository manually:

Open Command palette, and select Package Controll: Add repository
Add the GitHub url: https://github.com/SublimeLinter/SublimeLinter-jshint
Select Package Control: Install Package. It will then fetch the repo info.
If you search for jshint, the plugin should show up. Install as normal.

I did it but i don't see any action after selecting SublimeLinter-jshint in the install plugins palete. Just palete will close and there isn't any error or success message.

This is probably more an issue with package control that the code in this plugin.


Where did LMS Utilities go?

I wonder why the "LMS Utilities" extension is not displayed on the extensions page.
It was a really helpful extension that - I think - deserves to be in the extensions page.

https://github.com/TurboWarp/extensions/pull/429

It's not removed, it's just hidden. I still use it.


Fix rust#cargotest namespace search

The position.file property seems to often be just a file name; for files
like mod.rs this would throw an error due to the way the special casing
was set up; to fix this (and to assist with building the full module
path for 'nearest' and 'file' tests) I've expanded to the full path
(which is what the code seems to have been expecting).
Next, with the full path to the file in hand, the way it searched for
Cargo.toml would just not work on macOS (at least) since it would look
like, eg: Users/name/path/to/Cargo.toml, which glob() would treat as
relative, and so not match. To fix this in a (hopefully)
platform-agnostic way, I've pulled out the prefix before the first
"modules" entry and prepended it to the proposed path.

Make sure these boxes are checked before submitting your pull request:

[x] Add fixtures and spec when implementing or updating a test runner
[x] Update the README accordingly
[x] Update the Vim documentation in doc/test.txt

Hi @codeinabox sorry for the long delay—I've been a bit busy with Real Life and this fell off my radar.
I found some time recently to finally figure out how to run the unit tests, and investigated this a bit further. It seems like the reason the unit tests work fine but I run into errors in practical use is autochdir. I automatically change directory whenever I move buffers, so expand('%') is always just the filename for me. However, the unit test environment does not have this logic, and so when it does view src/file.rs the buffer name (even made relative to the current directory with ":.") still contains src/file.rs.
I can probably proceed with updating the fixtures/tests to pass using my approach here of forcing absolute paths, but I wonder if there are other runners that have this brittleness, assuming noautochdir. Also, I couldn't quite verify this behavior in the tests; I would've expected calling set autochdir in the before hook would work, but nothing seems to change. I did verify, however, that running nvim -u NONE and executing :e src/cli.rs | echo expand('%:.') with and without set autochdir before it will result in cli.rs and src/cli.rs, respectively 🤔

Also it seems that vim-flavor v3.0.0 doesn't work anymore due to changes on github's side:
fatal: remote error:
[1440]()  The unauthenticated git protocol on port 9418 is no longer supported.
[1441]()Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.

Locally, I had to install a newer version of ruby and install the latest vim-flavor there to get the tests to run.

Also it seems that vim-flavor v3.0.0 doesn't work anymore due to changes on github's side:
fatal: remote error:
[1440]()  The unauthenticated git protocol on port 9418 is no longer supported.
[1441]()Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.

Locally, I had to install a newer version of ruby and install the latest vim-flavor there to get the tests to run.

Thank you for spotting this, I have fixed the build

@codeinabox Sorry for the delay, I've been totally swamped and this keeps
falling off my radar. I suspect that the actual issue here was just from me
being unaware of the test#project_root config, and the implications of
it. I don't know if/when I'll have a chance to confirm this, but I suspect
that there's actually no change needed here, so long as the project root is
configured the way vim-test expects.
On Wed, Sep 14, 2022, 8:16 AM Mathew Attlee @.***>
wrote:

@dhleong https://github.com/dhleong keen to get this merged in though
there is still one failing test, could you please look into this and let me
know if you need a hand
—
Reply to this email directly, view it on GitHub
https://github.com/vim-test/vim-test/pull/613#issuecomment-1246676882,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGHIFSBH2S4UPLUUM7W2QTV6G6ZRANCNFSM5K5DNY6A
.
You are receiving this because you were mentioned.Message ID:
@.***>


Natural earth geometries are not imported correctly

The geometry column of the natural earth table is empty. This seems to be related to spatialite and the st_makevalid function.
@nicolas-heigvd Any idea where the problem comes from?

I have reproduced this strange behaviour. I cannot explain it. input data are messy on the one hand, and sqlite is not the db engine I prefer.
-> checkout https://github.com/baremaps/openstreetmap-vecto/tree/hotfix to keep the original geometries but also the fixed geometries in a separate column, hopping they would come back in the future...


Error creating item - NullPointerException: null

Magic dev 3522
I have a custom GUI from the plugin BossShopPro that when you interact with an item, it runs the command /mgive <name> to give the player the item. Recent dev builds of Magic seem to break this and now output an error.
[05:13:09] [Server thread/INFO]: mibby issued server command: /hats
[05:13:11] [Server thread/INFO]: Gave 1 Test Hat to mibby
[05:13:11] [Server thread/WARN]: [Magic] Error creating item: hat_test
java.lang.NullPointerException: null
	at com.elmakers.mine.bukkit.wand.Wand.doShowBoundInstructions(Wand.java:926) ~[?:?]
	at com.elmakers.mine.bukkit.wand.Wand.takeOwnership(Wand.java:1009) ~[?:?]
	at com.elmakers.mine.bukkit.wand.Wand.tryToOwn(Wand.java:899) ~[?:?]
	at com.elmakers.mine.bukkit.magic.Mage.tryGiveItem(Mage.java:3823) ~[?:?]
	at com.elmakers.mine.bukkit.magic.Mage.tryGiveItem(Mage.java:3771) ~[?:?]
	at com.elmakers.mine.bukkit.magic.Mage.giveItem(Mage.java:3746) ~[?:?]
	at com.elmakers.mine.bukkit.magic.Mage.giveItem(Mage.java:3765) ~[?:?]
	at com.elmakers.mine.bukkit.magic.command.MagicGiveCommandExecutor$1.updated(MagicGiveCommandExecutor.java:136) ~[?:?]
	at com.elmakers.mine.bukkit.magic.MagicController.createItem(MagicController.java:5832) ~[?:?]
	at com.elmakers.mine.bukkit.magic.command.MagicGiveCommandExecutor.onCommand(MagicGiveCommandExecutor.java:126) ~[?:?]
	at org.bukkit.command.PluginCommand.execute(PluginCommand.java:45) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:172) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at org.bukkit.craftbukkit.v1_16_R3.CraftServer.dispatchCommand(CraftServer.java:806) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at org.bukkit.Bukkit.dispatchCommand(Bukkit.java:758) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at org.black_ixx.bossshop.core.rewards.BSRewardTypeCommand.giveReward(BSRewardTypeCommand.java:43) ~[?:?]
	at org.black_ixx.bossshop.core.BSBuy.purchase(BSBuy.java:507) ~[?:?]
	at org.black_ixx.bossshop.core.BSBuy.purchaseTask(BSBuy.java:449) ~[?:?]
	at org.black_ixx.bossshop.core.BSBuy.purchaseTry(BSBuy.java:423) ~[?:?]
	at org.black_ixx.bossshop.core.BSBuy.click(BSBuy.java:392) ~[?:?]
	at org.black_ixx.bossshop.listeners.InventoryListener.purchase(InventoryListener.java:189) ~[?:?]
	at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor791.execute(Unknown Source) ~[?:?]
	at org.bukkit.plugin.EventExecutor.lambda$create$1(EventExecutor.java:69) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:76) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:611) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.PlayerConnection.a(PlayerConnection.java:2643) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.PacketPlayInWindowClick.a(SourceFile:32) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.PacketPlayInWindowClick.a(SourceFile:10) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.PlayerConnectionUtils.lambda$ensureMainThread$1(PlayerConnectionUtils.java:43) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.TickTask.run(SourceFile:18) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.executeTask(IAsyncTaskHandler.java:136) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.IAsyncTaskHandlerReentrant.executeTask(SourceFile:23) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.executeNext(IAsyncTaskHandler.java:109) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.MinecraftServer.bb(MinecraftServer.java:1220) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.MinecraftServer.executeNext(MinecraftServer.java:1213) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.awaitTasks(IAsyncTaskHandler.java:119) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.MinecraftServer.sleepForTick(MinecraftServer.java:1189) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.MinecraftServer.w(MinecraftServer.java:1029) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at net.minecraft.server.v1_16_R3.MinecraftServer.lambda$a$0(MinecraftServer.java:176) ~[1.16.5-patched.jar:git-Yatopia-dev/threaded-worldgen-"9b84e5e"]
	at java.lang.Thread.run(Thread.java:832) [?:?]
[05:13:11] [Server thread/INFO]: Unknown item type hat_test

Edit: Magic dev 3521 works fine.

Sorry about that, seems like it's a problem with the bind_on_give config option, which I'm guessing you have set to true?
I'll get this fixed in the next dev build.

That's correct, bind_on_give: true is set. No worries though, I'll just stay 1 dev build behind for now.

I do have it fixed already, just polishing up some other things before I push, but the next dev build will fix it up.
One thing I noticed though (that I think is not new), giving items that way won't show most of the wand instructions if you're using class wands, since the wand won't have any spells or mana configured when it is bound. Not sure I can fix that, but maybe you're not using class wands?

Probably not. I just have simple wand setups with a MagicHat spell bound to equip the hat on wand use.
I might have discovered another bug as well a couple weeks ago. The target_self: true spell param seems to trigger pvp checks. This was causing the MagicHat particles to appear where the player was looking when they interacted with the wand instead of the smoke particles appearing around them as they equipped the item.
I had to grant everyone the permission Magic.bypass_pvp so the particle worked fine again. Did something change around this param logic?
Full spell configuration;
magichat:
    icon: diamond_axe{CustomModelData:138}
    icon_disabled: diamond_pickaxe{CustomModelData:138}
    hidden: true
    icon_url: http://textures.minecraft.net/texture/2abee4fe341011b9a0ae2fb83644f695521fd4e4c6198fe23112f1acbf38369
    category: utility
    worth: 100
    actions:
      cast:
      - class: Delay
        delay: 1
      - class: Hat
      - class: CheckRequirements
        fail:
        - class: Command
    effects:
      cast:
      -  class: EffectSingle
         location: target
         effectlib:
           class: SphereEffect
           iterations: 4
           particle: smoke_large
    parameters:
      target_self: true
      use_item: true
      reason: custom
      cooldown: 1000
      range: 1
      allow_max_range: true
      console: true
      command: lp user @uuid permission set hat.example
      requirement:
        permission: hat.example

I did re-arrange the targeting checks, but I don't think a player should need pvp to target themselves. Are you sure that's what is happening? The way that spell is set up, the smoke should always appear one block in front of the player since it is set to location: target
I can try it out.

And I don't thinktarget_self: true needs to be in there for you, it is in the base spell because there is an AreaOfEffect that we want to be able to effect the caster.

Well some quick testing shows that something is in fact broken and probably has been for a while.. players can no longer target themselves if they can't pvp. I'll fix that for the next dev build too.

Testing as of Magic dev 3527;
The NPE seems fixed now. No more error when trying to spawn from a GUI with bind_on_give.
The PVP issue I think is fixed? It's hard to tell. I have to use target_self: true otherwise the hat spell does not equip the item. I'm noticing a problem with the fix that wasn't present before, unless it's a 3rd issue that just got introduced.
The particle does not appear around you / on the player target when you equip if you look at a certain far block at an angle. It appears more than a block away. My intention is for the effect to appear at the target, which is the player. This seems to occur regardless if bypass_pvp: true is set on the wand or not. I do not remember it functioning like this with earlier dev builds.
https://imgur.com/a/Xk7SWc7
magichat:
    icon: diamond_axe{CustomModelData:138}
    icon_disabled: diamond_pickaxe{CustomModelData:138}
    hidden: true
    icon_url: http://textures.minecraft.net/texture/2abee4fe341011b9a0ae2fb83644f695521fd4e4c6198fe23112f1acbf38369
    category: utility
    worth: 100
    actions:
      cast:
      - class: Delay
        delay: 1
      - class: Hat
      - class: CheckRequirements
        fail:
        - class: Command
    effects:
      cast:
      -  class: EffectSingle
         location: target
         effectlib:
           class: SphereEffect
           iterations: 4
           particle: smoke_large
    parameters:
      target_self: true
      use_item: true
      reason: custom
      cooldown: 1000
      range: 1
      allow_max_range: true
      console: true
      command: lp user @uuid permission set hat.example
      requirement:
        permission: hat.example

The target there is not the player, though, as I tried to explain before- the particles should always appear about 1 block in front of where you are looking. Are you seeing them appear a lot farther away than that?

I am, yes. It occurs when looking at certain angles, such as diagonally and far away blocks / air. As well as when using the wand while moving.
I figured location: target would use the target of the player with target_self: true.  Is there a way to specify the player position as the target instead?

You can do target: self to target yourself. That does sound odd though- I'll play with it a bit in the default configs, maybe there's some case there were targeting goes weird.

target: self seems to occur where the item is in your hand rather than the player position. Is there any way to change that?
    effects:
      cast:
      -  class: EffectSingle
         target: self
         effectlib:
           class: SphereEffect
           iterations: 4
           particle: smoke_large

Casts come from the wand item, you can change its location in thew and config with
cast_location: 0,0,0 which will be at the eyes, you can apply relative offsets from there.

Great thanks! That actually does solve it.
Doing some more testing with the targeting oddity, it seems to be technically one block but appears very misleading. If you are on the very corner diagonally of one block and aim across, the cast appears at the very furthest edge of the next block over. Practically 2 blocks distance and appearing upwards in the air, but might as well be 2 blocks.

That sounds like 1 block away though?
It doesn't mean like "target the next block in front of you", it means "target 1 meter in front of you", (1 block = 1 meter distance) - does that sound like what's it's doing?

Not if the meter is suppose to be the exact same distance regardless of direction you are targeting. If it's always suppose to be say exactly 1 block in distance or 0.5 coordinate offset from current position, that's not how it is functioning.

That does sound wrong then, or else I'm misunderstanding, but I'll do some testing :)

exactly 1 block in distance or 0.5 coordinate offset from current position,

These are two different things though- it should be exactly 1 meter in the distance, but that's no the same as 0.5 coordinate offset (Pythagorus would like a word)

0.5 was just an example. I assume the cast offset would be an exact approximation from your current position to the direction you are looking. :)

Well to be clear it's also 1 meter maximum - if you're looking at a block that is closer to you than 1 meter it will target the spot on that block you're looking at.

Sure. Definitely seems longer than 1 meter though diagonally.

I'm going to close this since the ticket got a little convoluted, but if you are still having targeting issues please feel free to open another issue. Thanks!


WorkflowAlerts Can Only Be Retrieved, Not Deployed via the CLI

Summary
The metadata type WorkflowAlert can be successfully retrieved from the org using the CLI. However, when you attempt to deploy this metadata type with the same manifest file, the deployment will fail with An object XXXXXXXX of type WorkflowAlert was named in package.xml, but was not found in zipped directory. The same applies for other child metadata types under Workflow. The only way to currently deploy workflow related items is by using the Workflow metadata type.
Please update the CLI to allow deployments with WorkflowAlert and other children metadata types under Workflow.
We are only able to move Email Alerts by themselves via Change Set. The file created by CLI retrievals for Email Alerts matches the file created for a change-set, so it seems to be compatible for deployments.
I found other issues regarding this but they were closed

https://github.com/forcedotcom/cli/issues/1228 (closed due to no response. Only workaround given is to use Workflow, which deploys the entire Workflow over just the email alert)
https://ideas.salesforce.com/s/idea/a0B8W00000H4r9GUAR/we-need-to-be-able-to-deploy-workflowrelated-elements-as-we-do-for-retrieving

Steps To Reproduce

Update the manifest file with WorkflowAlert
Retrieve manifest from org
Deploy manifest to org

Expected result
Retrieve and deploy completes successfully.
Actual result
Retrieve completes successfully. Deploy fails with An object XXXXXXXX of type WorkflowAlert was named in package.xml, but was not found in zipped directory.
System Information
Seen on Windows 11/PowerShell and Linux Ubuntu/Bash.
{
  "architecture": "win32-x64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v20.8.1",
  "osVersion": "Windows_NT 10.0.22621",
  "rootPath": "C:\\Users\\matthew.carvin\\AppData\\Local\\sf\\client\\2.16.7-ee67deb",
  "shell": "cmd.exe",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.1 (core)",
    "@oclif/plugin-commands 3.0.5 (core)",
    "@oclif/plugin-help 6.0.5 (core)",
    "@oclif/plugin-not-found 3.0.2 (core)",
    "@oclif/plugin-plugins 4.0.1 (core)",
    "@oclif/plugin-search 1.0.5 (core)",
    "@oclif/plugin-update 4.1.3 (core)",
    "@oclif/plugin-version 2.0.4 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.2 (core)",
    "@oclif/plugin-which 3.0.7 (core)",
    "@salesforce/cli 2.16.7 (core)",
    "apex 2.3.20 (core)",
    "auth 2.8.25 (core)",
    "data 2.6.1 (core)",
    "deploy-retrieve 1.19.3 (core)",
    "info 2.6.51 (core)",
    "limits 2.3.41 (core)",
    "login 1.2.40 (core)",
    "marketplace 0.3.2 (core)",
    "org 2.11.7 (core)",
    "schema 2.3.32 (core)",
    "settings 1.4.37 (core)",
    "sobject 0.2.14 (core)",
    "source 2.10.46 (core)",
    "telemetry 2.3.8 (core)",
    "templates 55.5.17 (core)",
    "trust 2.6.22 (core)",
    "user 2.3.41 (core)",
    "sfdx-git-delta 5.28.0 (user)"
  ]
}

Yes, this behavior is broken and has been for a long time.  The workaround is to deploy/retrieve the entire Workflow.  I understand that the metadata API allows addressing Workflow children individually so we will be trying to solve this very soon.
There is a discussion on this topic here: https://github.com/forcedotcom/cli/discussions/2356

Internally tracked with W-11385847

@shetzel - is there any update on fixing deploying workflow children using the CLI? Last CLI version I checked a few weeks ago still had the issue even with the decomposed workflow preset.
Not sure if this is impacted by the upcoming deprecation of workflow rules or if this is still planned for a fix??

@mcarvin8 - decomposed Workflows are supposed to solve this.  With the decomposeWorkflowBeta preset did the retrieve write the decomposed file as expected (per this doc)?
If you convert just WorkflowAlert to a directory does the convert happen as expected?
What is the exact command you were using to deploy?  I'll give it a try as well.

@shetzel - the retrieve with the decomposed workflow preset worked fine.
Deploying it failed as the Salesforce CLI skipped over the entry in the package.xml for WorkflowAlert.
Just using the standard "sf project deploy start -x manifest/package.xml" in vs code (windows 11). Not in a CI/CD pipeline.

After upgrading to today's latest CLI, I still see the same behavior.

With "WorkflowAlert" in the package.xml, it deploys successfully but with 0 components.

package.xml
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account.AlertAccountIdentifiedAtRisk</members>
        <name>WorkflowAlert</name>
    </types>
</Package>

CLI version:
{
  "architecture": "win32-x64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v22.11.0",
  "osVersion": "Windows_NT 10.0.22621",
  "rootPath": "C:\\Users\\matthew.carvin\\AppData\\Local\\sf\\client\\2.69.14-c6442ee",
  "shell": "powershell",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.11 (core)",
    "@oclif/plugin-commands 4.1.12 (core)",
    "@oclif/plugin-help 6.2.18 (core)",
    "@oclif/plugin-not-found 3.2.29 (core)",
    "@oclif/plugin-plugins 5.4.19 (core)",
    "@oclif/plugin-search 1.2.16 (core)",
    "@oclif/plugin-update 4.6.14 (core)",
    "@oclif/plugin-version 2.2.16 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.24 (core)",
    "@oclif/plugin-which 3.2.19 (core)",
    "@salesforce/cli 2.69.14 (core)",
    "apex 3.6.6 (core)",
    "api 1.3.2 (core)",
    "auth 3.6.78 (core)",
    "data 3.12.3 (core)",
    "deploy-retrieve 3.15.17 (core)",
    "dev 2.4.2 (user) published 106 days ago (Mon Aug 26 2024) (latest is 2.5.1)",
    "info 3.4.25 (core)",
    "limits 3.3.42 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.2.7 (core)",
    "packaging 2.9.5 (core)",
    "schema 3.3.43 (core)",
    "settings 2.4.8 (core)",
    "sobject 1.4.46 (core)",
    "telemetry 3.6.26 (core)",
    "templates 56.3.33 (core)",
    "trust 3.7.45 (core)",
    "user 3.6.4 (core)",
    "apex-code-coverage-transformer 2.0.0 (user) published 51 days ago (Mon Oct 21 2024) (latest is 2.2.0)",
    "apex-tests-git-delta 2.0.0 (user) published 51 days ago (Mon Oct 21 2024)",
    "apextestlist 1.9.1 (user) published 30 days ago (Sun Nov 10 2024)",
    "sf-package-combiner 1.2.3 (user) published 0 days ago (Tue Dec 10 2024)",
    "sfdx-git-delta 5.49.0-dev-942.11663286254-1 (user) published 37 days ago (Mon Nov 04 2024) (latest is 5.50.0)"
  ]
}

Looks like you're doing everything correct to me.  I'm seeing the same behavior so it's doubtful that workflow children were addressable by the CLI (or VS Code extension) like this.
The simple way to test this is to do a convert of the source to mdapi format using your manifest.  E.g.,
sf project convert source -x package.xml -d convertedWorkflowAlert
If you look at the directory it doesn't contain anything and that's what happens during the deploy.
So this is a bug.  You'll have to deploy/retrieve the entire workflow as a workaround.  As you pointed out, Workflows are deprecated and that affects the priority of the bug fix but we'll look into it.

Thanks.
Glad to see it's reproducible but I understand it's low priority since workflows are deprecated.

@mcarvin8 - if you're willing to try this, you could copy the decomposeWorkflowBeta preset into your sfdx-project.json, modify all the workflow children to be addressable (i.e., remove "isAddressable": false,), and then try running the command again.  It's possible that's the only problem.
Just assign the preset JSON to a property called, "registryCustomizations" peer to "packageDirectories".

Thanks @shetzel . That seems to be a viable workaround. I was able to deploy/retrieve the WorkflowAlert in my package.xml after setting the "registryCustomizations" section in my sfdx-project.json
I'm good with using this workaround for now

Only thing I'm seeing that's still weird with the decomposed workflow beta preset is that it's missing workflowFlowActions.
In its current state, Workflow Flow Actions are added to the *.workflow-meta.xml file instead of decomposed into their own sub-directory and files.
I think I figured out how to manually add this to the preset JSON file, which was able to decompose them into a folder with their own files.
But at least in our org, we have a decent amount of workflows with Workflow Flow Actions.

Decided to create a PR for this on the existing preset.
https://github.com/forcedotcom/source-deploy-retrieve/pull/1467
But up to you or your team if you wanna make this a beta2 or not.
I wasn't sure how to update the test classes, but it seems like the existing tests should cover this change. But let me know if something's wrong or if you wanna reject it and add your solution instead. No issues either way.


osx-arm64 libraries not signed

Hi there,
I suspect something is wrong with the osx-arm64 build. When trying to run a downstream package, I get the following error:
dyld[18550]: Library not loaded: @rpath/libQt5Widgets.5.dylib
  Referenced from: /Users/fischert/mambaforge/envs/ros_galactic/lib/rviz2/rviz2
  Reason: tried: '/Users/fischert/mambaforge/envs/ros_galactic/lib/rviz2/../libQt5Widgets.5.dylib' (code signature in <CEB7B2BE-A114-3936-BD30-8C710361D296> '/Users/fischert/mambaforge/envs/ros_galactic/lib/libQt5Widgets.5.15.2.dylib' not valid for use in process: library load disallowed by system policy), '/Users/fischert/mambaforge/envs/ros_galactic/lib/rviz2/../libQt5Widgets.5.dylib' (code signature in <CEB7B2BE-A114-3936-BD30-8C710361D296> '/Users/fischert/mambaforge/envs/ros_galactic/lib/libQt5Widgets.5.15.2.dylib' not valid for use in process: library load disallowed by system policy), '/usr/local/lib/libQt5Widgets.5.dylib' (no such file), '/usr/lib/libQt5Widgets.5.dylib' (no such file)

Also:
code sign -vvvv /Users/fischert/mambaforge/envs/ros_galactic/lib/rviz2/../libQt5Widgets.5.dylib
code object is not signed at all

Any ideas why this happens?

Possibly related but I am really not sure, just mentioning: https://github.com/conda/conda-build/issues/4256

Actually I am very confused, I guess the code should not be signed. But why am I then getting this error?

/cc @wolfv

I think this is not an issue anymore - I've been able to build rviz2 successfully.


Fatal Error concerning county code.

Very strange error I am getting with yourls.
Please see tgimagine.com/ozh
This is a default url that is not working in other states from me.  I live in Virginia, USA. It seems that any other state that uses my yourls is getting this error:
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'country_code' cannot be null' in /home4/tygiles/public_html/includes/vendor/aura/sql/src/ExtendedPdo.php:748 Stack trace: #0 /home4/tygiles/public_html/includes/vendor/aura/sql/src/ExtendedPdo.php(748): PDOStatement->execute() #1 /home4/tygiles/public_html/includes/vendor/aura/sql/src/ExtendedPdo.php(306): Aura\Sql\ExtendedPdo->perform('INSERT INTO yo...', Array) #2 /home4/tygiles/public_html/includes/functions.php(897): Aura\Sql\ExtendedPdo->fetchAffected('INSERT INTO yo...', Array) #3 /home4/tygiles/public_html/includes/functions.php(740): yourls_log_redirect('ozh') #4 /home4/tygiles/public_html/yourls-go.php(21): yourls_redirect_shorturl('http://ozh.org/', 'ozh') #5 /home4/tygiles/public_html/yourls-loader.php(37): require_once('/home4/tygiles/...') #6 {main} thrown in /home4/tygiles/public_html/includes/vendor/aura/sql/src/ExtendedPdo.php on line 748
I test this using VPN, but I have heard from people living in different states than I reporting the same error.  This website is being hosted through hostgator which is located in Texas, USA, But even when I VPN to dallas, I get the same error.  Please advise!  This yourls application works PERFECTLY for me when I am not on a VPN.  When I do VPN to Washington DC, the yourl works aswell.  I use ExpressVPN.  Washington DC server works, other servers do not.  I do not see any country code in config, and my time zone is correct anyway.  Please help!  Thank you!
Oh and if you are at a location that does get the error above, you can get to tgimagine.com/admin with no issue proving that yourls is installed v 1.7.4.  Thanks again!

Screenshot of the issue.  This works fine when I am not using a VPN.  And I get complaints of my links not working from people in other states.

Closing as duplicate of #2526


Enhance config usage by multi-node benchmarks.

See #512.

Standardizes names for VM groups in database and Hadoop benchmarks to
workers (data serving / processing nodes) and clients (load generating
nodes). Systems with a master have an additional master node.
Splits out VM roles for CloudSuite benchmarks.
Adds multi-server support to Aerospike benchmark.

@ehankland: would you mind taking a look?

LGTM - thanks for taking the time to do this

Thanks. All done.

:+1:

Re-tested everything and added cassandra_ycsb.  Both CloudSuite benchmarks failed for me - I've removed that change until I sort out what happened.
@ehankland: would you mind taking a quick look at cassandra_stress and cassandra_ycsb?

Fixed cloudsuite as well.

LGTM - there are a few places where vm_count gets set unconditionally to some flag value (e.g. ycsb_client_vms) - it would be nice if we checked for the presence of the flag so that setting the vm_count in a user config would work.

there are a few places where vm_count gets set unconditionally to some flag value (e.g. ycsb_client_vms) - it would be nice if we checked for the presence of the flag so that setting the vm_count in a user config would work.

For the YCSB case, done in 61c674ce6a743f70c4e9a98f2e5d76a98865cdd4


Support getting/reporting current values

The cli only seems to support blindly setting new values. It would be super useful to be able to get a summary of current device values to know existing settings.
My device in particular is a SteelSeries Rival 310, but this request appears to be applicable to all devices.

This is currently a work in progress. Since the last version (v4.4.0), Rivalcfg starts to save the current configuration on the HDD: this will be required to develop a GUI.
Please note that it is not possible to read-back values from SteelSeries mice (to be more complete, we could be able to get some of the settings (sometime with partial information only) from few devices but this will not be implemented as this is not rally reliable → more info)


Crossfold analysis example?

Do you have a way to do this?
Or do I have to split the data - fine to do - but then can I call model.fit() multiple times to update or will it overwrite the model?

GBDT-RS doesn't have related APIs. You may need to split the data.
Calling model.fit() will overwrite the model.
See https://github.com/mesalock-linux/gbdt-rs/blob/master/src/gradient_boost.rs#L252


Write a "Debugging Hipcheck" RFD

We really ought to care about the debuggability of Hipcheck, especially considering the transition to a plugin architecture will mean parts of Hipcheck's execution will be out of our immediate control. The things we likely care about include, but are not limited to:

Structured logging for Hipcheck Core (the non-plugin parts of Hipcheck)

Providing a logging API to plugins

Tracing support

We probably ought to try to support both eBPF-based tracing for Linux systems, and dtrace-based tracing for Macs, some BSDs, and Solaris-derived operating systems. The phrase we'd be looking for to identify the right existing libraries to hook into would be "USDT" (Userland Statically Define Tracing). I know there's a good Rust crate called usdt to support dtrace.

The things we probably care about being able to debug include:

Data flow between Hipcheck core and plugins.
Interactions with the filesystem API provided by core to plugins.
Network activity from core and plugins.
Operation of the incremental computation engine in Hipcheck core.

Recognizing that support for debugging within plugins may be limited by plugins own use of any APIs Hipcheck core exposes to support debugging.
Debugging should not only incorporate failure cases, but also cases of slowness, as a slow tool isn't a usable tool.
There's likely more that I've missed here. The basic idea though is this: we as Hipcheck maintainers, and Hipcheck users as well, should be empowered to understand what Hipcheck is doing so we can reduce the time to track down and address bugs.

Closing as no longer a priority.


The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #1517      +/-   ##
=========================================
- Coverage     7.7%   7.69%   -0.02%
=========================================
  Files         411     411
  Lines       62834   62834
=========================================
- Hits         4842    4833       -9
- Misses      57584   57593       +9
  Partials      408     408

Flag
Coverage Δ

#aFlag
7.69% <ø> (-0.02%)
:arrow_down:

Impacted Files
Coverage Δ

pkg/util/rbacutils/rbac.go
71.33% <0%> (-3.43%)
:arrow_down:

pkg/util/seclib2/seclib.go
95.74% <0%> (+4.25%)
:arrow_up:

Continue to review full report at Codecov.

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

/hold

/hold cancel

/lgtm
/approve


[release/0.4] Cherry pick fixes from main branch

Cherry picks https://github.com/microsoft/go-winio/commit/8f0d50b3b381b741820d6737cfbda5b9284be616 , https://github.com/microsoft/go-winio/commit/008bc6ea439f15884bef0b52f2772190c382bf46

@helsaawy  could you take a look? Cherry-picking a few changes primarily that were needed to bring https://github.com/microsoft/go-winio/pull/312 into containerd/1.6 via new tag for hcsshim/release/0.9


Add support of batch operations to URID extension

Some hosts like Carla perform complete isolation of plugins: all plugins are launched as separate processes in the system so crash of one plugin will not affect other plugins. Additionally, all UIs are executed as separate processes, so the communication between UI and the plugin is performed via standard system IPC that is slow.
That yields to the following case: when plugin requests many URIDs at instantiation time, all calls are synchronously executed via the IPC mechanism of the host, so each URID.map and URID.unmap call takes much longer time than expected. Launching multiple sequential requests performs TIMES slower than on hosts that shares the common address space with plugins.
That's why very reasonable would be implementation of extensions for the URID interface that allow batch operations with URIDs. The following gist shows an prototype of such interface, as a part of the original <lv2/ns/ext/urid/urid.h> header:
https://gist.github.com/sadko4u/8f11ae5632424c30c0578ba233a899a4
Here's the related issue:
https://github.com/sadko4u/lsp-plugins/issues/25
Also It would be nice to see any suggestions related to this feature from @x42 and @falkTX .

My opinion is that process isolating plugins makes no sense. It only adds unreasonable overhead.
If a plugin that processes audio crashes, there will be audible artifacts. Game Over. It now no longer matters if other plugins are affected or not.

the DSP is not bridged, just the UI, as that is the biggest reason of crashes.

the DSP is not bridged, just the UI, as that is the biggest reason of crashes.
can the DSP survive in a sane state if the UI crashes?

yes. of course. it is as if the UI got closed by the user.
DSP side knows the full state, when user opens UI again, the UI receives the full parameter/state again

@sadko4u  did you investigate speeding up the IPC mechanism itself? If that is indeed a bottleneck, I'd expect more issues, not simpy URID mapping.. That is usually a one-time operation.
I also recall @drobilla considering to hardcode some common URIDs (in particular those that the forge uses regularly)

IPC could be optimized a lot more, pipes are slow by design compared to other things...
(I had the idea of porting the fast shared-memory sync code used for audio to these ui bridges)
but anyway 500+ URID maps on init is a bit much.
being able to batch these operations would be nice regardless of carla, bridges and whatever else.

I think a host that wants to do this should implement an appropriate URI map that accounts for this, by caching, or mapping most up front, for example.  This would dramatically reduce the amount of IPC needed in most cases, often to zero.  I've considered doing this for ingen but never gotten around to it for lack of need.
It seems inappropriate to complicate the extension API to support a poor implementation of an esoteric use case, especially when it wouldn't help with existing plugins anyway, and require a bunch of porting for just this reason.
I'd be more open to this if it was a part of work that made things nice in general (maybe standard strict in extensions that are all mapped at once, sort of like the forge is abused for now, or the static thing) that also moved towards this benefit.

As @falkTX mentioned, the plugin UI requires a lot URIDs to be mapped at instantiation time. It can not be optimized because is already done in a cycle. The bottleneck is the IPC between host and UI. Batching such operations is a good way to optimize the interaction between UI and host.
As you said, 10 URD mappings won't give any sense. But 500+ URDs sure will. Even more, because URIDs are the main identification mechanism that is used anywhere, I think it should be a good mechanism to retrieve them fast, even with slow communication channel.

Are you sure that batch-processing does make a difference for hosts that don't use IPC?
For hosts that do not use IPC, the proposed batch-processing may even be  tad slower since you need to allocate and free memory for the array to be batch processed, and the plugin needs to provide a free callback (for windows to share heap between dlls).  While I expect context-free function call overhead to be negligible.
Also most plugins that I've seen so far don't dynamically map that many URIDs, so it's unlikely any other plugins would check if a host supports this and optionally use the batch-API.
Regarding Carla.  Since IPC is used for general DSP <> UI communication there, not only URID mapping, perhaps that should be optimized first.  Realistically, a single request on localhost should take less than a msec (compare to what HTTP servers do).  @falkTX  do you think ~1ms per request is realistic for Carla, too?

For hosts that do not use IPC, the proposed batch-processing may even be tad slower since you need to allocate and free memory for the array to be batch processed
If you look at the code snippet I've provided, the host is not required to allocate the memory. The plugin provides array of strings and array to store URIDs, so actually host needs just to store valid URIDs to this array.

and the plugin needs to provide a free callback (for windows to share heap between dlls)
No, it doesn't. Or I've missed something?

Yesh, I understand the problem.  It can be optimized, because you can, for example, copy the existing map to the other process first and only do fine-grained IPC for new stuff.  In combination with a sensibly pre-populated map, this would all but eliminate this flurry of round trips.
Again, I think there is a bunch of stuff that would improve things in general and perhaps move in this direction which would be nice to see.  This, however, just adds complexity to plugins, in an area where we need to do exactly the opposite.  It requires any plugin and/or UI to be rewritten to use this strange interface, with the only benefit being that it instantiates more quickly in this weird scenario.  The reality is that every single existing UI that maps URIs at all does it with the existing function, and will for a long time, if not ever.
Plus, plugins that are properly designed to work in remote situations don't require the same URI map in UI and instance at all.  There's a reason atoms are host transparent and can be serialized.  The only reason it would have to be that way is if they have dirty raw pointers into each other (via instance-access, for example, or other nasty behind the scenes tricks), in which case the goal of crash prevention is pointless anyway.
In summary, sorry, but this causes a lot of problems in the spec that must be used by everyone, to work around something in a host that seems massively slower than it could be (even with the given design), in a design that is a bit questionable and contrary to many of the core design decisions of LV2.  I'd suggest improving your IPC performance first, since that will actually improve the situation right now regardless, then considering other optimizations, before this.
If it does get to that point, there should be a solid answer to the question "why are you doing round-trips to map URIDs that were already mapped when the process/UI was launched anyway?"  Surely if you can implement a batch URI mapping protocol, you can also implement sending over the existing map first.

Yes, I understand the problem.  It can be optimized, because you can, for example, copy the existing map to the other process first and only do fine-grained IPC for new stuff.  In combination with a sensibly pre-populated map, this would all but eliminate this flurry of round trips.
Again, I think there is a bunch of stuff that would improve things in general and perhaps move in this direction which would be nice to see.  This, however, just adds complexity to plugins, in an area where we need to do exactly the opposite.  It requires any plugin and/or UI to be rewritten to use this strange interface, with the only benefit being that it instantiates more quickly in this weird scenario.  The reality is that every single existing UI that maps URIs at all does it with the existing function, and will for a long time, if not ever.
Plus, plugins that are properly designed to work in remote situations don't require the same URI map in UI and instance at all.  There's a reason atoms are host transparent and can be serialized.  The only reason it would have to be that way is if they have dirty raw pointers into each other (via instance-access, for example, or other nasty behind the scenes tricks), in which case the goal of crash prevention is pointless anyway.
In summary, sorry, but this causes a lot of problems in the spec that must be used by everyone, to work around something in a host that seems massively slower than it could be (even with the given design), in a design that is a bit questionable and contrary to many of the core design decisions of LV2.  I'd suggest improving your IPC performance first, since that will actually improve the situation right now regardless, then considering other optimizations, before this.
If it does get to that point, there should be a solid answer to the question "why are you doing round-trips to map URIDs that were already mapped when the process/UI was launched anyway?"  Surely if you can implement a batch URI mapping protocol, you can also implement sending over the existing map first.

It requires any plugin and/or UI to be rewritten to use this strange interface, with the only benefit being that it instantiates more quickly in this weird scenario. The reality is that every single existing UI that maps URIs at all does it with the existing function, and will for a long time, if not ever.

It doesn't require UI or any plugin to be rewritten. The plugin/UI can utilize the previously well-defined URID:map and URID:unmap interface. Nobody asks to deprecate these interfaces. I'm asking to add two new interfaces that can provide batch functionality as an addition to URID:map and URID:unmap. Most hosts even don't need to implement these interfaces. But hosts that have bottleneck with IPC can do this as a fast solution for the serious problem.

Plus, plugins that are properly designed to work in remote situations don't require the same URI map in UI and instance at all. There's a reason atoms are host transparent and can be serialized.

It also depends on the host that launches UI and DSP code.

In summary, sorry, but this causes a lot of problems in the spec that must be used by everyone

No, as I previously described, it should not be used by everyone. Moreover, plugins that do not use extensively URID:map won't meet any problems. The main problem is related to plugins that use URID:map extensively at the instantiation stage which yields to long instantiation delay which is annoying for several plugin users.

I'd suggest improving your IPC performance first, since that will actually improve the situation right now regardless, then considering other optimizations, before this.

The IPC of LV2 is always bottleneck because Atoms ports are slow and very complicated to use. Even for Ardour transferring of ~100k byte data @ 25 Hz rate is a really hard task, so the plugin developers are forced to use 'dirty' and 'tricky' LV2:Instance interface if it is possible and the host provides such capability.

If it does get to that point, there should be a solid answer to the question "why are you doing round-trips to map URIDs that were already mapped when the process/UI was launched anyway?"

Is it a question to host developer or plugin developer? As a plugin developer I just use URID:map at the instantiation time, but it works damn slowly. And then, I get a bug report that my UI is slowly working under certain hosts. And this is a result of that fact that I am required to use Atoms to transfer plugin state between UI and the plugin to conform the LV2 standard. And the transport is slow.
Surely if you can implement a batch URI mapping protocol, you can also implement sending over the existing map first.

A note here from Carla. Carla already does what you suggest, it sends the mapped URIDs to the UI process when it starts. In https://github.com/falkTX/Carla/blob/develop/source/backend/plugin/CarlaPluginLV2.cpp#L1443
Only new urid map calls have to be transferred over.
There is an issue of the UI wanting to map a lot of URIDs that were not needed beforehand.
I guess initializing those on the DSP side would help things a bit, but it is also a bit wasteful for cases where the UI is never opened.

Moreover, in LSP, all URIDS are taken in DSP code once at instantiation time:
https://github.com/sadko4u/lsp-plugins/blob/1d41a52f6b2236f38670c2d3a28ab97c419a4754/include/container/lv2/ports.h#L25
and:
https://github.com/sadko4u/lsp-plugins/blob/1d41a52f6b2236f38670c2d3a28ab97c419a4754/include/container/lv2/extensions.h#L465
https://github.com/sadko4u/lsp-plugins/blob/1d41a52f6b2236f38670c2d3a28ab97c419a4754/include/container/lv2/extensions.h#L448

@sadko4u, I've given your plugin UIs a spin on my crappy synthpod host [1]. It runs each UI in a separate process, too. synthpod has a separate URID hash per process, though (like @drobilla explained above) and serializes atoms via shared memory. This is real quick.
Your LV2 plugin UI's (after adding a bloody hack to fix #32), open up instantaneously on synthpod.
So, your issue is not specific for hosts that run UIs in separate processes.
You seem to do everyting correctly.
There's really nothing to fix in the LV2 URID spec, imho.
The only thing that needs fixing is one-or-another implementation of the LV2 URID spec :)
[1] https://git.open-music-kontrollers.ch/lv2/synthpod

@ventosus thank you for information. I'll fix the #32 issue ASAP. It's curious how I've missed this and kept for a long time being not changed.
So it seems that implementation of LV2 URID is a bottleneck in Carla.

No, as I previously described, it should not be used by everyone. Moreover, plugins that do not use extensively URID:map won't meet any problems. The main problem is related to plugins that use URID:map extensively at the instantiation stage which yields to long instantiation delay which is annoying for several plugin users.

This is the usual use case of URID mapping.  Pretty much the only relevant one here, really: doing this is the whole point of the API.


fix scope example in PowInvitation README

As mentioned in #22 , scope cannot be... scoped to the MyApp context when dealing with Pow or Pow extension controllers. The README has been updated to reflect a working example.

Thanks!


[FR] - Bech32 commands for cardano-cli

External
Area
Other
Describe the feature you'd like
Please add the bech32 featureset into cardano-cli, so that we all have it in one package. Feature same as https://github.com/input-output-hk/bech32

Closing this. If this is still relevant please re-open.


Going to close this one.


[FEAT]: Integration of Litellm as model proxy such as Ollama

What would you like to see?
it could be good to integrate Litellm proxy https://github.com/BerriAI/litellm in addition to ollama
so AnythingLLM could be comaptible with a multiple api model serving
I have seen the post https://github.com/Mintplex-Labs/anything-llm/issues/271 but perhaps it has evolved in the right direction?

Do you mean using LiteLLM as your LLM provider or adding LiteLLM within AnythingLLM as the main backend? That other issue was the latter, which is not possible because that is a python service and would be more set up and configuration and overhead than it is worth to undertake.
Adding it as an LLM provider where you have to run LiteLLM on your own and we simply connect to it is very doable

Hello
I mean "running Littellm on my own" and "siimply connect anythingllm" to it.
This is a good pattern since Litellm can proxy model provider such as vllm
which can serve and multiplex several llm models.
I have setup a full configuration with ollama / litellm / vllm
and i have tested anythingllm server with ollama: it works like a charm
so i will be able to test anythingllm to litellm to serve llms models from
vllm and so test the speed increase in anythingllm
Let me if you want i make something.
I am sorry for my english.
François from France
On Sun, Apr 21, 2024 at 8:33 PM Timothy Carambat @.***>
wrote:

Do you mean using LiteLLM as your LLM provider or adding LiteLLM within
AnythingLLM as the main backend? That other issue was the latter, which is
not possible because that is a python service and would be more set up and
configuration and overhead than it is worth to undertake.
Adding it as an LLM provider where you have to run LiteLLM on your own and
we simply connect to it is very doable
—
Reply to this email directly, view it on GitHub
https://github.com/Mintplex-Labs/anything-llm/issues/1154#issuecomment-2068158265,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABKZRFBBISI4HSFTVLY4LZ3Y6QA55AVCNFSM6AAAAABGQZ62Q2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRYGE2TQMRWGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
François Le Fèvre
36 rue Jean Poulmarch
91190 Gif-sur-Yvette
0665604928

Understand completely and that makes plenty of sense! I just wanted to ensure we were talking about the same feature.

Hello,
Implementing the Litellm binding in Anythingllm will help to solve such problem #1153 where AnythingLlm is able to connect to the vllm, but not to use the model served by vllm due to the specificity of each model, such as in my case mixtral8x7b.
do you know if this feature of Anythingllm Litellm compatibility will be put in the near future feature?
Thanks again. François

@flefevre it is certainly not out of the question and would alleviate many of such cases of unsupported LLM runners not being able to use AnythingLLM while we later build more dedicated support for specific runners over time.

Hi @timothycarambat may I know if this feature is being planned to be integrated in AnythingLLM, the integration of LiteLLM is something which we would like to see in the AnythingLLM.