Potential Support for API access [enhancement]

Was inspired by my own desire to toggle idle_inhibitor programmatically, as well as #1642, #1237, #690, and #1791.
I am thinking about extending waybar to include listening on a localhost socket for requests. A simple CLI client could then be written that could send one-off messages to the socket. This CLI could then be called by custom scripts, click events, keybindings, you name it.
An example use case for this would be toggling idle_inhibitor. Then CLI would send a toggle message of some sort intending for the idle_inhibitor. Waybar would receive this message and forward to the appropriate module. The module would then handle the message, in this specific case, by toggling the state.
Would need to have local socket connection handling for waybar to accept requests and forward to the appropriate modules, as well as adding a virtual method to IModule to handle an incoming request from the main process (which would then be implemented by individual modules).
Would this be within the scope of the project, i.e. @Alexays would you even consider a PR of this nature? Thanks!

Sure!

imo.
as waybar support -RTMIN signal. on sending signal via this waybar performs exec commands .
what if a config option like "signal-exec":"exec,on-click,on-scroll-up" will execute these sets when the signal is received to waybar?

imo. as waybar support -RTMIN signal. on sending signal via this waybar performs exec commands . what if a config option like "signal-exec":"exec,on-click,on-scroll-up" will execute these sets when the signal is received to waybar?

This could be a more lightweight option, but wouldn't have the flexibility of the rewrite I have in progress. When sending a signal to the waybar process, this is a very coarse - the signal gets sent to every module and it isn't customizable. The signal also can't communicate any metadata, or anything else.
Whereas opening an IPC socket allows for a more fully fledged API to communicate with modules and such.


Couldn't resolve requests in D435i

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
{ D435i }

Firmware Version
2.50

Operating System & Version
Ubuntu20.04

Kernel Version (Linux Only)
(e.g. 4.14.13)

Platform
NVIDIA Jetson AGX Orin

SDK Version
{  2.3.2 }

Language
python

Segment
Robot

Issue Description
<Describe your issue / question / feature request / etc..>

The realsense-viewer shows it is USB3.2, and it runs normally in it. “rs.stream.color” this line is normal, but “rs.stream.depth” is not normal. And I have tried many combinations of resolution and frame rate. Could you tell me how to work it out? Thank you very much!

Hi @yizhixia666  Does the error with the depth line still occur at 848x480 resolution if you set its FPS to the supported minimum of 6 instead of 60?

Hi @yizhixia666 Does the error with the depth line still occur at 848x480 resolution if you set its FPS to the supported minimum of 6 instead of 60?

Thanks for your reply! No matter what the resolution and the FPS is, the error is the same——"couldn't resolve requests". Now i can't find a correct way to run the code smoothly.

What happens if you remove the word config from the brackets of the pipeline start line?  The script should then ignore the config.enable_stream lines and apply the default stream configurations that the camera is currently able to provide.
pipeline.start()

After removing the word"config", the script has no error

The script code above can access the streams now, but cannot do anything useful with the streams.
There is a test script at the link below that you can use to make the program produce a visible on-screen output.
https://github.com/IntelRealSense/librealsense/blob/master/wrappers/python/readme.md#examples

Sorry, the test script seems to produce an output above. Is it possible to change the resolution and FPS of the stream?

Thanks for your suggestion! I just tried the method you mentioned and even restarted the system. But once config is added to pipeline.line(), an error will be reported.

Please try inserting the block of Python code below at the line immediately before the pipeline start line to reset the camera with the hardware_reset() instruction to see whether your config lines will then work after the reset.
ctx = rs.context()
devices = ctx.query_devices()
for dev in devices:
dev.hardware_reset()

OK！I will get back for you in a few hours，thank you

Hi! It seems to be a new error like this: for dev in devices: RuntimeError: xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument

If programs run once the 'config' command is removed from the pipe start brackets then it suggests that your pyrealsense2 installation is okay and does not have an obvious fault.
It is not clear though why it is having problems with config instructions or with hardware reset.
Would it be possible for you to use the default stream configurations that are applied when config is not used?  For a D435i that is 848x480 depth at 30 FPS and 1280x720 color at 30 FPS when on a USB 3 connection.

Can I understand that if I don't set config.enable_stream() and directly use pipeline.start(), it corresponds to the default stream configurations?

You are correct.  If config instructions are not used then the default stream configurations are automatically used.

OK! I will test it in Windows 11 to see what the reason is. Thank you very much!

Hi! It is tested successfully in Win11.

Thanks very much for the confirmation of success in your Windows test!

In addition, I would like to ask whether the RGB image and depth map obtained by pyrealsense2 are aligned

Hi! I just tried the default stream configuration, and the aligned_depth_frame returned by the method aligned_depth_frame = aligned_frames.get_depth_frame() is None. It seems that everything related to depth will report an error. Is this related to the ARM architecture I am using?

RGB is not aligned with depth by default.
There are rare occasions when alignment  does not work on Jetson, though that is usually in ROS rather than the pyrealsense2 wrapper.
If you test the SDK's example Python depth-color alignment script align_depth2color.py, is it able to provide an aligned image?
https://github.com/IntelRealSense/librealsense/blob/master/wrappers/python/examples/align-depth2color.py

Unfortunately, align-depth2color.py is stuck in an infinite loop because of aligned_depth_frame=None

The issues that you have been experiencing do not sound as though they are related to the librealsense version that you are using.
Do you know what your camera firmware driver version is, please?  If librealsense 2.50.0 is being used then the firmware version that should be used with it is <IP_ADDRESS>.
If you have access to the realsense-viewer tool then you can find the firmware version by clicking on the 'Info' option near the top of realsense-viewer's options side-panel.  Another way is to use the command rs-enumerate-devices -s
If you can use realsense-viewer then you could also try resetting your camera's calibration to its factory-new defaults using instructions at https://github.com/IntelRealSense/librealsense/issues/10182#issuecomment-1019854487
This factory reset also repairs any corruptions in a 'calibration table' stored inside the camera hardware, which can cause the camera to not work correctly if the table has become corrupted.

Unfortunately, align-depth2color.py is stuck in an infinite loop because of aligned_depth_frame=None. Is it possible to solve this problem by upgrading the version of librealsense?

Hi! Is there any other way to solve this problem?

Assuming that the problem is not with the camera or the firmware driver since is works fine on Windows, sometimes when there is an apparently unsolvable problem it gets fixed if a complete wipe of the computer and reinstallation of everything (including Ubuntu) is performed.  Doing this can fix a problem by removing hidden glitches that were causing the problem.

Well, anyway, thank you very much for your advice.

Hello, I just installed realsense-viewer version 2.55.1. Where does the stereo module display the depth map?

when I run "realsense-viewer" on the ternimal, it occurs errors above, how to solve it?

When realsense-viewer is working correctly, the depth should be displayed in the center panel when Stereo Module is enabled.
What method did you use to install realsense-viewer, please?  Usually when librealsense is compiled from source code with CMake, it is installed by adding -DBUILD_EXAMPLES=True -DBUILD_GRAPHICAL_EXAMPLES=true to the CMake build instruction.
I would not recommend building realsense-viewer separately using its GitHub source code page.
https://github.com/IntelRealSense/librealsense/tree/master/tools/realsense-viewer

I installed realsense-viewer through librealsense. If it is v2.55.1, I cannot view the depth map under available streams, only two infrared maps. If it is v2.50.0, it will report the above error. But I used v2.50.0 before, and the function was normal. Is it related to the fact that I recently installed the opencv 4.5.5 with cuda?

If you are using librealsense 2.50.0 then your camera firmware driver should ideally be version  <IP_ADDRESS>.  Is that the firmware that you currently have installed in your camera, please?

I don't know where to find the firmware version, because the "rs" command in the terminal will report an error.

We established earlier that the camera and firmware driver works fine on your Windows 11 computer and it is Ubuntu that has the problem.
Did you perform the wipe and complete reinstallation of your Ubuntu computer that I suggested earlier at https://github.com/IntelRealSense/librealsense/issues/13596#issuecomment-2545654180 please?

We can't reinstall the system

If the camera works on Windows and you can enable the depth stream in it, could you try resetting the camera to its factory-new settings using the instructions at https://github.com/IntelRealSense/librealsense/issues/10182#issuecomment-1019854487 please?  As the adjustments made by the reset are saved to the camera hardware, you can take the reset camera back to your Ubuntu computer to test whether it has made a difference.

Uh! I will try this method, thanks

Hello, I would like to ask two questions. Question 1: When both RGB image and depth image are set to 30hz, why is the ros topic "/camera/camera/aligned_depth_to_color/image_raw" only 10hz? Question 2: Does the realsense-ros package use ros::now() to timestamp the image topic? If so, can I understand that the camera timestamp is actually the system time? Looking forward to your reply

When both depth and color are enabled, the speed of one of the streams may lag.  Please try disabling the RGB setting auto-exposure priority.

You can do this in Python code by first defining a color_sensor to access the RGB sensor and then setting rs.option.auto_exposure_priority to a value of '0'.  https://github.com/IntelRealSense/librealsense/issues/11246 provides guidance about how to implement this.
depth_sensor, color_sensor, *_ = profile.get_device().query_sensors()

color_sensor.set_option(rs.option.auto_exposure_priority, 0)

Thanks for your reply.
1.How do I set the auto-exposure parameters in the realsense-ros package?
2.Now I have used external GNSS to synchronize the system time. In this case, is the timestamp in the ROS image the system time?

In realsense-ros, please try adding auto_exposure_priority:=false to your roslaunch instruction.

If you know how to edit the rs_camera.launch file then it can also be disabled inside the launch file by adding the following block of code to the file.
<rosparam>
/camera/rgb_camera/auto_exposure_priority: false
</rosparam>

To make sure that global time is disabled and only ROS time is being used for timestamping, add global_time_enabled = false to your roslaunch instruction.

Maybe is it rs_rgbd.launch?

If you wish to edit rs_rgbd.launch instead of rs_camera.launch then the block of rosparam code should still work.


windowScroll - eventlistener is not removed

Hi @wesjones,
I'm using the windowScroll addon and get errors after a route change because the datagrid is destroyed but the scroll eventlistener on window will be still triggered.
I've temporarily fixed this by adding
if (angular.element(document).injector().get('windowScroll')) {
    window.removeEventListener("scroll", inst.scrollModel.onUpdateScroll)
}

to the destroy() method.
This seems a bit ugly so no PR but if you provide me with a hint how to do it better I'll try to send a PR.
Btw. thank you very much for this awesome datagrid!

Thanks :) I'm not sure how I missed that one! And I am glad you are enjoying the datagrid.
This is fixed and added to release 1.5.3.


Add reclaim mannequin command

With the reclaim-mannequin it is now possible to reclaim a mannequin directly on gei instead of having to do it on the UI.
If the mannequin has been already map, the reclaim will fail unless the --force parameter is used.
This command only reclaims one user at a time, another PR will follow to reclaim multiple users with a CSV file

[x] Did you write/update appropriate tests
[ ] Release notes updated (if appropriate)
[x] Appropriate logging output
[ ] Issue linked

Also since this is a new feature and def. a customer facing one, RELEASENOTES needs to be updated too.

Also since this is a new feature and def. a customer facing one, RELEASENOTES needs to be updated too.

Done 7f77907e7


Query language over object graphs.

It would be nice to be able to get selections like "all 8th_flag objects that share a notehead with a 16th_flag object".

Powerful esp. with #149

Powerful esp. with #149


Integration Test - Release - 2020/11/19 19:12:51

Auto create for integration test. AnotherAuthorUpdatedArticleFlow

@PRMergerTest2 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


implicit instantiation of undefined template 'std::basic_stringstream'

Will enter details at a later time!

Needed to include "sstream" !!!


Puzzle zebra

What article on docs.github.com is affected?

What part(s) of the article would you like to see updated?

Additional information

Puzzle zebra

Puzzle

Java


Issue 12

This PR aims to fix issue #12.

I implemented thorough code cleaning and model building process streamlining, with the highlight being generation and saving of state IO data are simplified to 4 instead of 6 steps with the intermediate steps eliminated.
After merged into dev, gh actions workflows can be triggered to generate and save state IO data. However, this requires the dependency on useeior to point to a branch/version that contains updated IO data.


improper token passed

everything is correct I have rechecked the bot token 20  @times
File "/app/.heroku/python/lib/python3.9/site-packages/discord/http.py", line 303, in static_login
2021-06-06T14:43:10.968122+00:00 app[worker.1]:     raise LoginFailure('Improper token has been passed.') from exc
2021-06-06T14:43:10.968122+00:00 app[worker.1]: discord.errors.LoginFailure: Improper token has been passed.

everything is correct I have rechecked the bot token 20 @times
File "/app/.heroku/python/lib/python3.9/site-packages/discord/http.py", line 303, in static_login
2021-06-06T14:43:10.968122+00:00 app[worker.1]: raise LoginFailure('Improper token has been passed.') from exc
2021-06-06T14:43:10.968122+00:00 app[worker.1]: discord.errors.LoginFailure: Improper token has been passed.

Token must be exclusively from a user account, BOT tokens are not supported.
See more in #23

If I want to use both bot and selfbot how can I use any solution?

If I want to use both bot and selfbot how can I use any solution?

Since the module name is the same, you could run 2 different python files in 2 different virtual enviroments

Bro I want to make crowd ans bot can I?

If I want to use both bot and selfbot how can I use any solution?

Since the module name is the same, you could run 2 different python files in 2 different virtual enviroments

Bro I want to make crowd ans bot can I?

https://github.com/Rapptz/discord.py/issues/516
If you really want to do this, I would recommend you use discum, which has built-in support for this.

Same issure here. I used a usertoken and the issure is still happening

Try to check if your token is really valid using requests or something like that, me and another friend are using the library normally.
https://github.com/caiocinel/Selfium/blob/1549e1ed374e7c4bf492573fdd59c02f83a73dec/app/auth/parse.py#L4

Same issure here. I used a usertoken and the issure is still happening

What version of the library are you using? Latest PyPi release? Have you cloned a branch?

Same issure here. I used a usertoken and the issure is still happening

What version of the library are you using? Latest PyPi release? Have you cloned a branch?

Im using the newest version. i installed it directly from pypi so it is the latest release. maybe other libs like discord.py slashcommands causing this issure because maybe pycharm select them instead of discord.py-self. if so it woul d be great, if anyone can reply me how i can set what module a single project should use.

Try development branch
https://github.com/dolfies/discord.py-self/tree/development

Any news about this issue?
I get an improper token error with client.run function using a valid token. I am using the client for parsing channels, with a client token gathered from the browser's network history. The same code, I am using, works fine on a friend's computer.

Try to check if your token is really valid using requests or something like that, me and another friend are using the library normally.
https://github.com/caiocinel/Selfium/blob/1549e1ed374e7c4bf492573fdd59c02f83a73dec/app/auth/parse.py#L4

With this function I checked and it returns successfully the information
Here is the error of client.run(TOKEN):
Traceback (most recent call last):
  File "C:\Users\Desktop\Miniconda3\envs\xx\lib\site-packages\discord\http.py", line 300, in static_login
    data = await self.request(Route('GET', '/users/@me'))
  File "C:\Users\Desktop\Miniconda3\envs\xx\lib\site-packages\discord\http.py", line 254, in request
    raise HTTPException(r, data)
discord.errors.HTTPException: 401 Unauthorized (error code: 0): 401: Unauthorized

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Desktop\Miniconda3\envs\xx\lib\site-packages\discord\client.py", line 723, in run
    return future.result()
  File "C:\Users\Desktop\Miniconda3\envs\xx\lib\site-packages\discord\client.py", line 702, in runner
    await self.start(*args, **kwargs)
  File "C:\Users\Desktop\Miniconda3\envs\xx\lib\site-packages\discord\client.py", line 665, in start
    await self.login(*args, bot=bot)
  File "C:\Users\Desktop\Miniconda3\envs\xx\lib\site-packages\discord\client.py", line 511, in login
    await self.http.static_login(token.strip(), bot=bot)
  File "C:\Users\Desktop\Miniconda3\envs\xx\lib\site-packages\discord\http.py", line 304, in static_login
    raise LoginFailure('Improper token has been passed.') from exc
discord.errors.LoginFailure: Improper token has been passed.

Here is the result of the manual parse(TOKEN) function:
'id':'xx'
'username':'xx'
'avatar':None
'discriminator':'xx'
'public_flags':0
'flags':0
'banner':None
'banner_color':None
'accent_color':None
'bio':''
'pronouns':''
'locale':'xx'
'nsfw_allowed':True
'mfa_enabled':False
<EMAIL_ADDRESS>'verified':True
'phone':None


feat: support findByKeyword()

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


⚠ gorzdrav.org has degraded performance

In 5ba3286, gorzdrav.org (https://gorzdrav.org) experienced degraded performance:

HTTP code: 200
Response time: 2465 ms

Resolved: gorzdrav.org performance has improved in 9823059.


Add storage bounds to account procedures

Currently, we specify storage offsets for account procedures. That is, if storage offset for a procedure is 1, whenever the procedure tries to access storage item 0, the actual item accessed will be 1, when i tries to access storage item 1, the actual accessed item will be 2 etc. This puts a "lower bound" on the item a procedure can access - but we do not restrict the upper bound. That is, a procedure can access any storage item (up to a max of 255) starting from its offset.
It would be good to make sure that a given procedure can access only a specific set of storage items. This would prevent potential overlaps between different procedures. To do this, we need to do the following:
Update the AccountProcedureInfo struct to look something like this:
pub struct AccountProcedureInfo {
    mast_root: Digest,
    storage_offset: u8,
    storage_size: u8,
}

Where storage size would be the number of storage slots a procedure can access. So, the "physical" storage slots accessible by a procedure would be bounded by [storage_offset, storage_offset + storage_size).
We would also need to update the transaction kernel to handle this properly.

Largely closed by #886.
@phklive - could you create an issue (unless it already exists) on what remains to be done to remove the temporary code?


No scroll bar and no X button for the tabs

I find this awesome, but I just realised there's no scroll bar. The X button aren't much of a problem because I can simply middle-click. But I really miss the scroll bar.

Just remove the section under /* Hide scrollbar */ in the userContent.css file


[6.5.x] RHBPMS-4456 - Locking of elements is corrupted for WIN hosts

@hasys @manstis Hi guys, with @jlindop out for a while I need help to review this PR. Thanks!


Games downloaded through the Xbox app cannot be properly dumped.

After the recent updates of Xbox app you could now choose custom installation location, due that fact when you try to dump the game, it detects amount of files/name of files properly but dumps it as the single file which assuming is the msixvc package, so in fact it only dumps one file which is the whole package.

i dont have any problems...

Can you please choose other installation place other than C drive and test it out?


Cannot build in prod with Nuxt typescript typecheck option enabled

I added the module (1.1.2) to my project (Nuxt 3.5.3) and noticed my build pipeline failed with the following error:
Property 'fromNow' does not exist on type 'Dayjs'
It happens when I enable the typescript typecheck option in nuxt.config.ts and/or use the following vite config:
vite: {
  plugins: [checker({ eslint: { lintCommand: "eslint ." }, vueTsc: true })],
},

For now, I disabled both and I typecheck manually.
dayjs config in nuxt.config.ts is:
dayjs: {
  locales: ["fr"],
  plugins: ["relativeTime", "timezone", "utc"],
  defaultTimezone: "Europe/Paris",
},

try the latest @agenordebriat


Requirement Installation

Error during  requirement installation in Windows 10, python 3.9.1
(venv) PS D:\_ai\depthai_hand_tracker> pip.exe install -r .\requirements.txt Looking in indexes: https://pypi.org/simple, https://artifacts.luxonis.com/artifactory/luxonis-python-snapshot-local/ ERROR: Could not find a version that satisfies the requirement open3d ERROR: No matching distribution found for open3d
Change requirements.txt, from 'open3d' to 'open3d-python'

Hi,
It seems that for python 3.9, you need the development version of open3d: http://www.open3d.org/docs/latest/getting_started.html#development-version-pip
What versions of open3d do you get when using  'open3d-python' ?


Parse temp file as certain file type

Sometimes I would write a "temp file" like a code snippet or a short markdown document but not really save it ( just paste it into other apps like email client or IM). It would be helpful if there's a function that I can tell vscode to parse the temp file as a certain type ( .md or .java, etc) and active highlight and plugins about the type ( markdown support, code completion, etc).

You can! You can click the language mode in the status bar ("plain text" by default) to pick a language mode. Or run the command "Change Language Mode".

Thank you roblourens. It helps a lot. But I found it doesn't active all plugins related to the chosen type. For example, in a saved Java file:

in the temp Java file:

That's up to the language extension, you can file an issue on them.

OK, thank you.


Whitelist is Reset after restarting the server.

Describe the problem
After pulling the newest docker image and then restarting my minecraft servers, the whitelist got reset on each server to the default that I had in my docker compose file.  Updating the whitelist and then restarting the server would also cause it to get reset again.
In each log file I see this line:
[init] Enabling whitelist functionality
Container definition
minecraft:
    image: itzg/minecraft-server
    restart: always
    ports:
      # Main Game
      - "25566:25565"
    volumes:
      - "server:/data"
    environment:
      EULA: "TRUE"

      TYPE: "SPIGOT"
      VERSION: "1.20.1"

     [omitted]

      WHITELIST: "me"
      OPS: "me"

      [omitted]

Container logs
[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 13 1000 1000 4096 Aug 16 20:26 /data'
[init] Resolving type given SPIGOT
[init] Downloading Spigot from https://download.getbukkit.org/spigot/spigot-1.20.1.jar ...
 [init] Enabling whitelist functionality
 [init] Setting initial memory to 15G and max to 15G
 [init] Starting the Minecraft server...
Unbundling libraries to /data/bundler
 Expected file /data/bundler/versions/spigot-1.20.1-R0.1-SNAPSHOT.jar to have hash 37cbe1da24cb7a66e90648519ebb70895b8c9bfa5d734cb84061b7d3bd45af19, but got 2223cfff7d6c1ad5027509e8c3983b8b336f1d37baaad710756a3f35159c04a5
 Unpacking spigot-1.20.1-R0.1-SNAPSHOT.jar (versions:spigot-1.20.1-R0.1-SNAPSHOT.jar) to /data/bundler/versions/spigot-1.20.1-R0.1-SNAPSHOT.jar
 Expected file /data/bundler/libraries/spigot-api-1.20.1-R0.1-SNAPSHOT.jar to have hash 6c4a0d22f308bf8cde4d919f06e6a2c836649776904bfa7405e88cda2995d358, but got 55da66e6f174351ab82fa0e767363d66704f1c2a231c068a8135cef2216902cd
 Unpacking spigot-api-1.20.1-R0.1-SNAPSHOT.jar (libraries:spigot-api-1.20.1-R0.1-SNAPSHOT.jar) to /data/bundler/libraries/spigot-api-1.20.1-R0.1-SNAPSHOT.jar
 Starting server
 Loading libraries, please wait...

That's by design. It is keeping the whitelist/ops files in sync with what's been specified in the env var. Either set APPEND_WHITELIST/APPEND_OPS to true or manage the file manually and don't set OPS/WHITELIST.
See  https://docker-minecraft-server.readthedocs.io/en/latest/configuration/server-properties/#whitelist-players

Actually, I'll flip this back to a bug. I need to introduce an option like old behavior to skip when the file exists.

Thank you, I did not realize the change.

I should also add a warning/note to those doc sections to emphasize the new behavior when I re-add the option to retain the old "change only if file does not exist" behavior.

Sorry for breaking the old default behavior. I have restored the original behavior as the default but allow for choosing the new options more consistently. That change is building now https://github.com/itzg/docker-minecraft-server/actions/runs/5946367157


Avoid recursive inclusion between soci-{config,platform}.h

This resulted in SOCI_HAVE_CXX_C11 not being defined in soci-platform.h if
soci-config.h was the first header to be included, as soci-platform.h is
included from it before defining this symbol, but uses it.

Now Linux build fixed :+1:


Optimize cleanup existing kubernetes resources policy regarding Jobs

Jobs in terminated state (Succeeded or Failed) state could not be restarted, so we can safely ignore images used by these resources. Only keep those images that are used by active Jobs resources.

solved


Fix broken build and a typo

Two errors were preventing the file to be built on my local machine:

(<>) was not on scope. Fixed by importing Data.Monoid
Turtle.echo required a Turtle.Line. Fixed by building it with the unsafe constructor provided

It seems that there's a version mismatch for both GHCI and Turtle between our builds.

https://github.com/bollu/teleport/pull/5 amends the build to use Cabal and GHC 8.0.1, this fixes the problems introduced in the update.

Thanks :)


Update README

There are a few other places that reference 2016: https://github.com/youtube/spfjs/search?utf8=✓&q=2016
@nicksay ok to update all references?

Happy New Year!
You can update src/license.js, LICENSE, and README.md.
Thanks for the PR!

Great, I will update this PR now

@nicksay Ok, done.


Keep up with Opensearch standard codebase requirements

https://github.com/opensearch-project/.github/issues/13 Branching, labeling requirements
https://github.com/opensearch-project/.github/issues/8 Doc requirements

Seems like a stale issue as the Notifications repo is in line with these conventions. Closing.


Allow self-signed certs

smctl should have the option to trust self-signed certs. Like cf cli's "--skip-ssl-validation" smctl should have "--insecure" for example

To be fixed with #13


Update x-lite to 5.1.0_89320

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

The HTTPS audit is new and sometimes incorrectly advises the use of HTTPS.
https://github.com/caskroom/homebrew-cask/issues/41735

Thanks @commitay.
The audit wouldn't let me past with http (I used cask-repair). The https version redirected to http so I thought putting https here should be fine. ¯_(ツ)_/¯


Use array_from_callback when initializing a model from a state_dict

i think this will make the code cleaner, even if not particularly faster.

fixed


Need to add refresh_token grant to the DCR

Description:
when doing the current DCR request in APIM 3, we only use authorization_code grant-type. In order to get a token after the token get expired, we need to use refresh_token grant to generate a refresh token.
Suggested Labels:
APIM 3.0
Affected Product Version:
APIM 3.0

Fixed by @CrowleyRajapakse  in https://github.com/wso2/carbon-apimgt/pull/6238


Misc Fixes

@wrboyce does this connect to any of the open issues? If so can we please connect accordingly to these by using 'Fixes #issueNumber'?
Are we addressing the window-changes and dangling exec shells in a separate PR or is this still a WIP that will include these fixes as well?

@lekkas I'm still working on those, this is just the fixes for #17 (possible security implications) and addressing #16 so we are producing releases via circle and not manually.
There are appropriate Connects to tags in the first and third new commits.

I see, @wrboyce can you please add 'Fixes ' in the PR description? It's easier to see in the description which Issues (if any) are being addressed by a PR, also connects to mostly applies to issues that have a staging/testing/production lifetime (e.g. the backend components)


Using this sdk in a web app with Jetpack compose?

If anyone has succeeded in getting this library to work properly for the web I'd love to hear what versions you're using and what setup do you have. It seems that the library only works with legacy JS compiler, I had it forked and made it work with IR but then I was having this error
> Task :web-app:compileDevelopmentExecutableKotlinJs FAILED
e: Module <dev.gitlive:firebase-auth> is a module[ModuleDescriptorImpl@62ac83c2] has reference public dev.gitlive.firebase.auth/FirebaseUser.displayName.<get-displayName>|-7122534302014937473[1], unfortunately neither itself nor its dependencies [
        org.jetbrains.kotlin.ir.backend.js.lower.serialization.ir.JsIrLinker$JsModuleDeserializer@5b30eb79
        org.jetbrains.kotlin.ir.backend.js.lower.serialization.ir.JsIrLinker$JsModuleDeserializer@17c9428e

org.jetbrains.kotlin.ir.backend.js.lower.serialization.ir.JsIrLinker$JsModuleDeserializer@4974c
        org.jetbrains.kotlin.backend.common.serialization.IrModuleDeserializerWithBuiltIns@5d0478f0
] contain this declaration
Please check that project configuration is correct and has required dependencies.

After which I switched to react and legacy compiler with useCommonJs
kotlin {
    js {
        useCommonJs()
        browser()
}

I was wondering if anyone successfully go everything to work and what versions were they using for the common libraries like compose, kotlin, coroutines, ktor and such.

@Nikola-Milovic I've been succeeded with IR compiler. Try to remove default args in updateProfile() method at dev/gitlive/firebase/auth/user.kt


Double short opts -f

Noticed you've used -f twice
force | f)
        FORCE=true
        ;;

montage-file | f)
        MONTAGEFILE="${OPTARG}.jpg"
        ;;

@shmup : ugh, so embarrassing!!!  thanks for pointing this out, short flag letters are always a struggle.
The fix here is completing the rename of montage-file to output-file and use -o as the short opts flag.


I didn't understand

I don't understand, you attached a photo with bit rat, which indicates the functions and so on, I don't understand one thing, there are some packages that relate to the c++ language
But this project does not have any c++ code, only c# codes and dcrat modifications
What's the matter, why didn't you upload the original code?
https://github.com/oreillymedia/Learning-OpenCV-3_examples

Because he's just spreading the virus
It's just shit, garbage


Lathe que bug

Description

If you manage to que up something that the lathe had no resource to produce at the time , it would clog up the lathe's que , rendering it useless. And the issue would persist even if you inserted the nessary resource.
Step to reproduction :

Put 30 glass/steel/plastic into the lathe
spam click the crew monitor until it turns black
insert more resource and the lathe will not produce more and is now broken
Screenshots

https://user-images.githubusercontent.com/60119809/166107356-d56bbef1-0092-4df1-ae8c-4cc53cdca7ef.mov
Additional context

Was able to reproduce, I'll attempt to fix it

Is this the same bug that caused #7639?

Is this the same bug that caused #7639?

I think so


Use alternative selector script

Description

This pull request addresses the issue described here: #<?>

In this pull request, I have …

For features/enhancements:

[ ] I have added/updated the relevant references in the documentation files.

For API changes:

[ ] I have made the necessary changes in the types index file.

This POC is not relevant. Couldn't make it work better that the espresso solution


refactor requireheader dependency to es6

What kind of change does this PR introduce?
refactor
Did you add tests for your changes?
current tests should pass
If relevant, link to documentation update:
N/A
Summary
upgrade RequireHeaderDependency and RequireHeaderDependencyTemplate to es6
Does this PR introduce a breaking change?
No

Nice work.


Fix typo in isChangedSignagure

The correct spelling is isChangedSignature.

Thangs!

Ha I see what you did there!


ENTER key should submit a guess

The Winforms application would benefit from this enhancement.
When the user types in a guess, they should be able to press the ENTER key to submit a guess, rather than click on the Guess button.

@naitii Please check if you can complete this requirement. Also look other issues in this repo.


Implement (DataFrame|Series).plot.hist in plotly

This PR is dependent on https://github.com/databricks/koalas/pull/1998 and https://github.com/databricks/koalas/pull/1997. This is being tested via: https://mybinder.org/v2/gh/HyukjinKwon/koalas/plotly-histogram?filepath=docs%2Fsource%2Fgetting_started%2F10min.ipynb

Codecov Report

Merging #1999 (92ce526) into master (ddbdc9a) will decrease coverage by 2.26%.
The diff coverage is 74.82%.

@@            Coverage Diff             @@
##           master    #1999      +/-   ##
==========================================
- Coverage   94.51%   92.25%   -2.27%
==========================================
  Files          50       50
  Lines       10965    10946      -19
==========================================
- Hits        10364    10098     -266
- Misses        601      848     +247

Impacted Files
Coverage Δ

databricks/koalas/plot/plotly.py
12.28% <5.26%> (-82.46%)
:arrow_down:

databricks/koalas/plot/core.py
92.48% <100.00%> (+0.76%)
:arrow_up:

databricks/koalas/plot/matplotlib.py
92.53% <100.00%> (-0.83%)
:arrow_down:

databricks/koalas/tests/plot/test_frame_plot.py
100.00% <100.00%> (ø)

...s/koalas/tests/plot/test_series_plot_matplotlib.py
100.00% <100.00%> (ø)

...bricks/koalas/tests/plot/test_frame_plot_plotly.py
26.43% <0.00%> (-73.57%)
:arrow_down:

databricks/koalas/usage_logging/__init__.py
25.66% <0.00%> (-66.65%)
:arrow_down:

...ricks/koalas/tests/plot/test_series_plot_plotly.py
37.73% <0.00%> (-58.88%)
:arrow_down:

databricks/koalas/usage_logging/usage_logger.py
47.82% <0.00%> (-52.18%)
:arrow_down:

... and 21 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #1999 (92ce526) into master (ddbdc9a) will decrease coverage by 2.26%.
The diff coverage is 74.82%.

@@            Coverage Diff             @@
##           master    #1999      +/-   ##
==========================================
- Coverage   94.51%   92.25%   -2.27%
==========================================
  Files          50       50
  Lines       10965    10946      -19
==========================================
- Hits        10364    10098     -266
- Misses        601      848     +247

Impacted Files
Coverage Δ

databricks/koalas/plot/plotly.py
12.28% <5.26%> (-82.46%)
:arrow_down:

databricks/koalas/plot/core.py
92.48% <100.00%> (+0.76%)
:arrow_up:

databricks/koalas/plot/matplotlib.py
92.53% <100.00%> (-0.83%)
:arrow_down:

databricks/koalas/tests/plot/test_frame_plot.py
100.00% <100.00%> (ø)

...s/koalas/tests/plot/test_series_plot_matplotlib.py
100.00% <100.00%> (ø)

...bricks/koalas/tests/plot/test_frame_plot_plotly.py
26.43% <0.00%> (-73.57%)
:arrow_down:

databricks/koalas/usage_logging/__init__.py
25.66% <0.00%> (-66.65%)
:arrow_down:

...ricks/koalas/tests/plot/test_series_plot_plotly.py
37.73% <0.00%> (-58.88%)
:arrow_down:

databricks/koalas/usage_logging/usage_logger.py
47.82% <0.00%> (-52.18%)
:arrow_down:

... and 21 more

Continue to review full report at Codecov.

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


level2 git hint has mistake

Version: 0.3.36
Platform: PC
Publisher: Steam

It should be purple 3 and blue 4


Enable cert-manager addon

I get the following errors when trying to enable the cert manager addon:
 Error: unable to build kubernetes objects from release manifest: [resource mapping not found for name: "cert-manager-ca" namespace: "cert-manager" from "": no matches for kind "Certificate" in version "cert-manager.io/v1"
│ ensure CRDs are installed first, resource mapping not found for name: "cert-manager-selfsigned" namespace: "" from "": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1"
│ ensure CRDs are installed first, resource mapping not found for name: "cert-manager-ca" namespace: "" from "": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1"
│ ensure CRDs are installed first]
│
│   with module.eks_blueprints_kubernetes_addons.module.cert_manager[0].helm_release.cert_manager_ca[0],
│   on .terraform\modules\eks_blueprints_kubernetes_addons\modules\kubernetes-addons\cert-manager\main.tf line 10, in resource "helm_release" "cert_manager_ca":
│   10: resource "helm_release" "cert_manager_ca" {
│
╵
╷
│ Error: unable to build kubernetes objects from release manifest: [resource mapping not found for name: "cert-manager-letsencrypt-production-route53" namespace: "" from "": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1"
│ ensure CRDs are installed first, resource mapping not found for name: "cert-manager-letsencrypt-staging-route53" namespace: "" from "": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1"
│ ensure CRDs are installed first]
│
│   with module.eks_blueprints_kubernetes_addons.module.cert_manager[0].helm_release.cert_manager_letsencrypt[0],
│   on .terraform\modules\eks_blueprints_kubernetes_addons\modules\kubernetes-addons\cert-manager\main.tf line 20, in resource "helm_release" "cert_manager_letsencrypt":
│   20: resource "helm_release" "cert_manager_letsencrypt" {

Here's the relevant terraform:
enable_cert_manager = true
cert_manager_helm_config = {
  name       = "cert-manager"
  repository = "https://charts.jetstack.io/"
  chart      = "cert-manager"
  version    = "v1.11.1"
  namespace  = "cert-manager"
  timeout    = "1200"

  values = [
    <<-EOF
    installCRDs: true
    tolerations:
      - key: "CriticalAddonsOnly"
        operation: "Exists"
        effect: "NoSchedule"
    EOF
  ]
}
cert_manager_domain_names = [var.hosted_zone_name]

How are the CRD's supposed to be installed?

please see https://github.com/aws-ia/terraform-aws-eks-blueprints-addons where addons will be managed going forward
Ref: #1421


Fix python interpreter as to use max result setting

What is this PR for?
zeppelin_python.py used a hard-coded 1000 rows limit when returning results. This PR makes sure that the interpreter retrieves the max_results from PythonInterpreter.java and that the latter retrieves this configuration from the configuration via the properties object.
What type of PR is it?
Bug Fix
Todos

[ ] - Task

What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-2447
How should this be tested?

use %python interpreter
make a dataframe with more than a 1000 rows
z.show the dataframe
export it in csv
the numbers of rows should exceed 1000 rows

Screenshots (if appropriate)
Questions:

Does the licenses files need update?
no
Is there breaking changes for older versions?
no
Does this needs documentation?
no

Ready for review

ping @paularmand Can you fix the comment ?

@zjffdu Thanks for review. Added 1000 hard coded as default for now, although I believe a better solution would be to add fallbacks to a property class upfront (see https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#defaults).

Thanks @paularmand LGTM

@paularmand Could you add jira to the title of your PR ? name it as [ZEPPELIN-2447] Fix python interpreter as to use max result setting

Is the Jenkins failure an unrelated selenium test failure, or do I have to look into it?

ping @zjffdu Do I have to look into it the Selenium test failure?

@paularmand Selenium test is flaky, one thing left is unit test. Could you add unit test in PythonInterpreterTest ？

@zjffdu I'll have a look. Can expect something later on this week.

ping.

Pong @jongyoul . I wrote the unit test, but it is not passing on Jenkins. I have trouble setting up my local IDE to run the python tests in IntelliJ (all other tests, except the python ones, are running fine), so I'll have to dig deeper in the IDE settings. Pointers/help appreciated.

Let me check


[Bug] .jar file too big

The .jar file now is too big, possibly due to the fact that unnecessary dependencies are installed

v1.6 wrap up


Feedback section

The feedback section lists a GitHub issue that has been closed. It should be removed. The issue showed overwhelming support for rolling back this change, or at least making top-level statements optional, rather than the default, so maybe this should be addressed?

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 447e23ae-0256-d8c1-4dca-d31fe21602a5
Version Independent ID: 926db74c-be79-f7cd-a4e9-e156dafa6287
Content: C# console app template changes in .NET 6+ - .NET
Content Source: docs/core/tutorials/top-level-templates.md
Product: dotnet-fundamentals
GitHub Login: @tdykstra
Microsoft Alias: tdykstra

Thanks for your feedback. Top-level statements in the project template were made optional via a checkbox in Visual Studio and an option in dotnet new.


py2pack failing on jpy

$ py2pack generate -t opensuse.spec -f python-jpy.spec jpy
generating spec file for jpy...
Error: environment variable "JAVA_HOME" must be set to a JDK (>= v1.7) installation directory
/usr/lib/python3.11/site-packages/py2pack/__init__.py:230: UserWarning: Could not get setuptools information from tarball jpy-0.13.0.tar.gz: Command '/usr/bin/python3.11 setup.py -q --command-packages metaextract metaextract -o /tmp/tmpb5eaoj49 ' returned non-zero exit status 1.. Valuable information for the generation might be missing.
  warnings.warn("Could not get setuptools information from tarball {}: {}. "

JAVA_HOME is set (properly?):
$ echo $JAVA_HOME
/usr/lib64/jvm/jre-openjdk
$

Installed packages (on Tumbleweed):

python311-setuptools_scm-7.1.0-1.2.noarch
python311-setuptools-67.8.0-1.3.noarch
python311-py2pack-0.9.0-2.2.noarch

Thanks for your reply. If I understand you correctly, this means that this needs to be worked around / solved within py2pack?

It will work if jpyutil is installed -- if you create a venv with py2pack and jpyutil, it will likely work, but I have not tested this. We probably do not want to use importlib.metadata and packaging, but probably project_wheel_metadata from build.util.

Yep, looks like this problem can't be solved either using build.project_wheel_metadata because it produces the same error, it's not possible to build the wheel from the sources for this package, until you have jpyutil. That's the weird thing about setup.py that it can contain any python code, but hopefully, the new pyproject.toml will solve this issue in the future.
In any case, get the metadata from the wheel, or using the build module could be still interesting, because metaextract is a setuptools extension and we're not getting all the metadata from packages that don't use setuptools.


What type of update are you requesting?
A new version of an existing package
Current Package Identifier
f4exb.sdrangel
Package Version
7.20.1
Please describe the changes you would like to see
There is a new release (7.20.1) available. Download Page Url: https://github.com/f4exb/sdrangel/releases (https://github.com/f4exb/sdrangel/releases/download/v7.20.1/sdrangel-7.20.1-win64.exe)

https://github.com/microsoft/winget-pkgs/pull/154539


[Swag 2021] Distribution logistics

2021 -Shirt Swag - Distribution Plan - Global

minutes by @edbratt from 5/23 meeting:
Process for swag distribution linked to 2021 swag
2021-Shirt Swag- Distribution Plan - Global  spreadsheet allocates the 380 shirts, globally.
2021 Spend Proposal Swag for JUGs  logic sheet behind the $5,000 order.
[INFRA] Swag email creation #686  swag email created with Emily and Amelia as Admin owners. More MicroProfilers who wished to help with distribution of MP swag are welcomed.
[Infra email] Contact organizations via private email to see if they would like to get the MP swag (address, phone numbers etc
[Amelia] Find a Vendor who will tackle the shipments. Swag is in Los Angeles.
Discussed the shirt allocation. Allocation in spreadsheet is good for estimation. Final allocation is limited by number of shirts.
Should we make 3K stickers to include as hand-out, especially for distribution to JUGs? Allocate from 2022 budget. No one on the meeting objects.  [Swag] MP Stickers for 2021 t-shirt distribution - Costs #687 Budget from 2022 will also be used to cover shipping costs of 2021 shirts. Both these budget requests must be approved by a quorum steering committee meeting. We would propose a Steering Committee resolution to cover shipping costs.
We will work on a draft resolution over e-mail and try to finalize it at the next Marketing meeting – then refer it to the Steering committee for a formal vote

12_7_2021_Deluxe MPWG - 380 Shirts_Invoice23173607.pdf

During the Sept 12 Marketing & Sept 13 Community calls, the 2021 logistics were discussed, and it was decided:
UPDATE:

That as part of the swag pilot "distributing swag," MPWG will distribute to the 2021 MPWG members the 380 printed shirts that the printing Deluxe Vendor is holding since May 2022.
The EF team will provide its contact person who will be in charge of 1) payment to the BSC shipping Vendor, 2) delivering the MPWG members' information to BSC

@emecas, in order to add you to this ticket, you ought to comment :)

@emecas, in order to add you to this ticket, you ought to comment :)

thanks @aeiras  :)

hey @emecas,
The "logistics" spreadsheet  was created to facilitate
LogisticDRAFT - Swag Allocation - Steering Committee Members.xlsx
each Member sending their information to the EF foundation.
Paul today via https://www.eclipse.org/lists/microprofile-wg/msg01595.html delivered the EF point of contact.

@croundy confirmed that the distribution list provided above is final and I have shared it with the supplier.

@croundy confirmed that the distribution list provided above is final and I have shared it with the supplier.

Thanks @shanda-eclipse  , may you confirm that the final distribution list contains Payara's shipping information?

Again, all you @emecas :) Kudos!


When uploading a file, the file forwarded to downstream is empty

Expected Behavior / New Feature
Actual Behavior / Motivation for New Feature
Steps to Reproduce the Problem
1.There are files in custom Ocelot middleware

2.There are no documents downstream

Specifications

Version:
Platform:
Subsystem:

@mcslove808 Please try on latest version. Issue is not replicated on latest version.

@mcslove808
Hi! And welcome to Ocelot world!
As far as I know Ocelot doesn't support routing of form-data and its files.
So we need to open a feature ticket to work on it...
We welcome your PR to create!
For now, I will keep this issue open to be able to return back in future to work on it as a feature.
P.S. And, if you use our gateway, please fork Ocelot into your account!
@ggnaegi  FYI

@mcslove808
Upgrade to the latest version please!
And if issue still persists, open a PR with the fix please, and reopen this one.


migration creation should not require DATABASE_URL

Literally:
$ pg-migrate create social_contact_table
The $DATABASE_URL environment variable is not set.

It does not use it while creation, maybe exclude it?

👍 will look on it


Where is EXTERNREF_HEAP_START defined?

Summary
externref-xform/src/lib.rs:26 mentions that the constant DEFAULT_MIN must kept in sync with src/lib.rs and EXTERNREF_HEAP_START, however I can not find any mention of EXTERNREF_HEAP_START in the repository. Where is this constant defined?
Additional Details
I need to increase the size of the stack used by wasm-bindgen from 32 to 64. So far, I have updated the code in a fork in the following locations:

src/lib.rs:94
cli-support/src/js/mod.rs:79
externref-xform/src/lib.rs:27

Are there any other locations that I am missing?

I believe all those offsets are the set of locations that need to be updated and the comments here are all outdated. I think having a larger default is also reasonable, it was never intended for 32 to be a final "this was tested to be perfect number", it was just sufficient for the small tests at the time. Ideally this number would be configurable by the wasm-bindgen CLI itself as well.

Ideally this number would be configurable by the wasm-bindgen CLI itself as well.

That would indeed be ideal. Although seeing that the HEAP_START constant is defined in three separate locations in the repository, I guess this is not so easy to fix? Perhaps it is related to the offsets of the true, false, undefined, and null JsValue constants?

I think having a larger default is also reasonable, it was never intended for 32 to be a final "this was tested to be perfect number", it was just sufficient for the small tests at the time.

In #2884, I found that I needed a stack of 128 for my application, however, it does seems for most cases that 32 is a reasonable default.


aya: netlink: use NETLINK_EXT_ACK from libc crate

NETLINK_EXT_ACK is available since libc crate version 0.2.105, see
https://github.com/rust-lang/libc/releases/tag/0.2.105

Thank you! I think we need to bump the libc dep in Cargo.toml too?

@alessandrod thanks, I've updated the libc version in Cargo.toml as well.


Pytorch Point to Plane similar to SimpleICP

Hi, I tried out SimpleICP and it seems to work very well for my problem. The only issue with SimpleICP for me is that it's very slow due to not being batched (as I need a distribution of ICP results). I was wondering if you knew any pytorch implementations of point to plane ICP? pytorch3d's implementation I believe is point to point and produces much worse fits than SimpleICP. If not, I am interested in porting this python implementation to pytorch to support batching.

Hi, its not completely clear to me what you mean with "batching". Can you clarify this? Is the goal to run register n point cloud pairs at the same time, i.e. in parallel?

The goal is to register two point clouds together but with different initial pose estimates in parallel. This is achieved in pytorch3d by passing the point cloud as B x N x 3 and B x M x 3 inputs with B x 4 x 4 initial homogeneous transform estimates. (This formulation allows registration of different pairs of point clouds in parallel, but I just use it to duplicate my input point clouds B times).


Proper DeadlockDetectedException handling

Hi,
what would be a proper way of catching DeadlockDetectedException. I see TransientException. Does TransientException.Code contain actual neo4j error name which I can use? In this case DeadlockDetectedException.
Thanks

I found that the actual code should be Neo.TransientError.Transaction.DeadlockDetected.
Could we introduce these error codes in the driver to be able to reference them?

The driver needs the server to send the code first. Will investigate on this and come back to you. But expecting a bit longer waiting time than a normal driver only issue.

https://github.com/neo4j/neo4j/pull/7463
Also more work will follow to clarify what behaviour the driver would take after these errors, such as rollback tx, close session, etc. And also examples, recommendations for driver users will be added for how to deal with these error.
Sorry for a bit random right now.

I am closing this issue as the server already surfaced the DealockDetectedException to the client side.
The cypher statement that raises ClientException or TransientException could be retried, while DatabaseException will result in connection termination.
Please be free to raise another issue if you get more questions.


SQL Observer

There should be an Observer that can store experiments in a SQL database.

Just got started with this project and was surprised that SQL was not the default.

The reason is simply that the information that you might want to store alongside your experiment can differ in structure. A schemaless database allows to just store it anyways and MongoDB even provides a powerful query-engine.
That being said, SQL would be nice to have since it is the most widespread and well-developed database technology. If you are interested, I have some work-in-progress in the feature/sql branch.
Unfortunately I don't have any time at the moment to work on this.

A working version of the SQL Observer is part of the labwatch branch (see c73e5934da368992edd30827810f1eebecd9c13f).
It will be part of the 0.7 release.

The SqlObserver is part of the current beta release 0.7b1. Check it out and let me know if it doesn't work as expected.

It appears that the SqlObserver could only accept a single number as the result. Returning a dictionary would could an exception.

Indeed. Could you make this a separate issue? Thanks.

Could you make certain fields that need to be schemaless to be a JSON data type?  For instance - https://www.postgresql.org/docs/current/static/datatype-json.html  Postgresql supports indexes on JSON data types.  MySQL and MSSQL also support JSON types.  I'm not sure how sqlalchemy supports JSON data types however.


remove kfctl operator

Signed-off-by: Adrian Zhuang<EMAIL_ADDRESS>Signed-off-by: Tommy Li<EMAIL_ADDRESS>/cc @Tomcli
Thanks submitting your Operator. Please check below list before you create your Pull Request.

Flat operator directory structure is obsolete from 23-rd of October 2019, only nested directory structure will be accepted.

This PR will remove the current kubeflow operator under directory kfctl.
New Submissions

[ ] Has you operator nested directory structure?
[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?

[ ] Have you tested your Operator in all supported installation modes?
[ ] Is your submission signed?

Updates to existing Operators

[ ] Is your new CSV pointing to the previous version with the replaces property?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Submit operators to both upstream-community-operators and community-operators at once
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need
2 For more information see here

I consent.


Add Faqt

Hi, any chance to merge this? 🙂

Yeah, sorry, I’ll check everything soon.
Had a little trouble


Not unique measurements are overwritten in Influx

Hello Brandawg93
thank you for creating this. I just noticed something and wanted to inform you.
InfluxDB needs a unique tag Value. If we don't send one, only one measurement will be available.
Let's take this example. (I added the the hostname tag, because i am running two piholes)
{'measurement': 'FTL', 'tags': {'host_name': 'npi02', 'type': 'A (IPv4)', 'status': 'localhost', 'domain': 'clients1.google.com', 'client': '<IP_ADDRESS>', 'forward': '<IP_ADDRESS>'}, 'time': '2020-02-15T16:03:18', 'fields': {'id': 298}}
{'measurement': 'FTL', 'tags': {'host_name': 'npi02', 'type': 'A (IPv4)', 'status': 'localhost', 'domain': 'clients1.google.com', 'client': '<IP_ADDRESS>', 'forward': '<IP_ADDRESS>'}, 'time': '2020-02-15T16:03:18', 'fields': {'id': 299}}
as you can see the tag values are the same, unfortunately the the timestamp in the pihole db is not unix time with nanoseconds.
if you check in the InfluxDB you'll only find one measurement
I guess the fix would be to send the id twice. once as a filed and once as a tag.
For my usecase with two pihole instances. i think i'll try something to send a tag like this:
uniq_id=item[0]+host_name
Here is some information from Influx: https://v2.docs.influxdata.com/v2.0/write-data/best-practices/duplicate-points/
thanks again for crating this

This is good to know! So anything with the same timestamp is just overwriting the id field with the latest value? But if I add another tag called uniq with the same value as the id, it should be separate values?

I've added a new tag called uniq to help with duplicate data points. Thanks again for the heads up!

I'm not using the full docker setup; however, I am using the sql_influx script for monitoring. Adding the uniq tag causes the cardinality to be too high. As a result, InfluxDB responds with a 400 when trying to write the measurement due to max-values-per-tag.
filling data...
Traceback (most recent call last):
  File "main.py", line 89, in <module>
    add_new_results(last)
  File "main.py", line 79, in add_new_results
    client.write_points(json_body)
  File "/home/pi/.local/lib/python3.7/site-packages/influxdb/client.py", line 599, in write_points
    consistency=consistency)
  File "/home/pi/.local/lib/python3.7/site-packages/influxdb/client.py", line 676, in _write_points
    protocol=protocol
  File "/home/pi/.local/lib/python3.7/site-packages/influxdb/client.py", line 410, in write
    headers=headers
  File "/home/pi/.local/lib/python3.7/site-packages/influxdb/client.py", line 369, in request
    raise InfluxDBClientError(err_msg, response.status_code)
influxdb.exceptions.InfluxDBClientError: 400: {"error":"partial write: max-values-per-tag limit exceeded (100000/100000): measurement=\"pihole-FTL\" tag=\"uniq\" value=\"240807\" dropped=1"}

I think instead, of the monotonic id as the uniq you should take the modulo by 100 or something to make it sufficiently unique for the time granularity of 1 second without blowing up the cardinality. In other words "uniq": item[0] % 1000. Happy to make that change.

@sudowork Feel free to submit a pr with this change. I can test it from there.


Feature/labels

Label CRUD
Label --> Sensor relationship
List/Add/Remove sensors from a Label

Completes: https://github.com/helium/helium-ruby/issues/4

Coverage remained the same at 100.0% when pulling 7644f65361d8e9682e54f046519acd0fffb9bfd9 on feature/labels into 7f2651ba51a46d4f968965d2ad9eb2a45f18e75f on master.


(chore)app: update labware image

Fixes a black line on a labware library image

@koji Got it! I updated the file in that location too. Let me know if that is correct, thanks


chore(deps): bump gogo proto and ethereum version

Overview

Now that gogo proto also cut a new release using the latest x/exp package, we can bump its version and also the
version of Ethereum.
This would help me fix dependencies downstream in orchestrator-relayer and testground tests.
We can also bump its version in cosmos-sdk, but I am not sure whether we want to do that ourselves or wait until we get that from upstream. There is a note in gogoproto stating:

Dependencies depending on earlier version of x/exp may not be able to bump to v1.4.11 because slices.SortFunc had some breaking changes. For limiting breaking changes in patch versions, for instance, the Cosmos SDK v0.47.x will not bump to v1.4.11.

Checklist

[ ] New and updated code has appropriate documentation
[ ] New and updated code has new and/or updated testing
[ ] Required CI checks are passing
[ ] Visual proof for any user facing features like CLI or documentation updates
[ ] Linked issues closed with keywords

Codecov Report

Merging #2338 (cc8e2c2) into main (7f97788) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2338   +/-   ##
=======================================
  Coverage   20.24%   20.24%
=======================================
  Files         132      132
  Lines       15508    15508
=======================================
  Hits         3140     3140
  Misses      12067    12067
  Partials      301      301


Tracking PR Custom Derive (#146)

This is the tracking PR for Custom Derive discussed in #146

Currently Outstanding Discussion Points / Questions

Should TryFromArgMatches be implied by FromArgMatches?
Propose having SubCommands imply SubCommandFromArgMatches

Todo from previous discussion points

[x] Rename DefineX to X in traits (DefineApp->App)
[x] Move code to public code_gen module (stomp->code_gen)
[ ] Have FromArgMatches actually generate From<ArgMatches>

To Do
Derive FromArgMatches
#[derive(FromArgMatches)]
struct MyApp {
    verb: bool
}

fn main() {
    let m: MyApp = App::new("test")
        .arg_from_usage("-v, --verbose 'turns on verbose printing'")
        .get_matches()
        .into();

    println!("Verbose on: {:?}", m.verb);
}

[ ] #[derive(FromArgMatches)]

[ ] Docs
[ ] Tests
[ ] Ensure requirements can't be violated (i.e. use Default where possible and document such)

Derive TryFromArgMatches
#[derive(TryFromArgMatches)]
struct MyApp {
    verb: bool
}

fn main() {
    let m: Result<MyApp, clap::Error> = App::new("test")
        .arg_from_usage("-v, --verbose 'turns on verbose printing'")
        .get_matches()
        .try_into();
}

[ ] #[derive(FromArgMatches)]

[ ] Docs
[ ] Tests

Derive App
/// Does stuff
#[derive(App)]
struct MyApp {
    /// Turns on verbose printing
    #[clap(short = 'v', long = "verbose")]
    verb: bool
}

[ ] #[derive(App)]

[ ] Docs
[ ] Tests

Derive Subcommands
#[derive(SubCommands)]
pub enum Commands {
    Test(Test),
}

[ ] #[derive(SubCommands)]

[ ] Docs
[ ] Tests

Derive SubcommandFromArgMatches
#[derive(SubCommandFromArgMatches)]
pub enum Commands {
    Test(Test),
}

[ ] #[derive(DefineSubCommands)]

[ ] Docs
[ ] Tests

Misc.

[ ] Add other get_matches variants (get_matches_from, etc.)
[ ] Ensure feature parity with all Arg methods
[ ] Apply the unstable clap feature (will be used until Rust 1.17 ships stable, to maintain Stable-2 compatibility)
[ ] Rebase commits to clog conventions (can be done last)

Propose changing DefineX to X in traits (DefineApp->App)
Propose moving code to public code_gen module (stomp->code_gen)
Propose renaming FromArgMatches::from to FromArgMatches::from_matches to avoid conflicts with From (assuming we can't just use std::convert::From which would be most optimal)

Those all sound good to me. I just tried #[proc_macro_derive(From<ArgMatches>)] and #[proc_macro_derive("From<ArgMatches>")] in case one worked, but unsurprisingly not. I was hoping we could have something like impl<T> Into<T> for ArgMatches where T: FromArgMatches, but it doesn't look like there's any way to do that without coherence issues 🙁
Actually, I guess #[derive(FromArgMatches)] could just generate an implementation of From<ArgMatches>, there's no reason it needs to generate the trait it says it does...

Rebase commits to clog conventions

Yeah, I was thinking of creating some nice, pretty, fake history for this 😆 there's definitely some internal stuff that needs to be designed properly before doing that (looking at it again I really dislike the code parsing the attributes, there must be a cleaner way to do it).

Actually, I guess #[derive(FromArgMatches)] could just generate an implementation of From, there's no reason it needs to generate the trait it says it does...

I like this a lot because it allows using the standard From and Into traits.

Yeah, I was thinking of creating some nice, pretty, fake history for this :laughing:

No worries! This can be done last. In all honesty, so long as the relevant commits get picked up by clog in order to add the changelog I'm good :wink:

Coverage decreased (-0.007%) to 89.075% when pulling 33f7266eaa97ce599f119d251cb37d574cd89aae on Nemo157:stomp into 72d7bf39b948cada1acc5d1754650136df85714e on kbknapp:v3-master-dev.

Made those changes and also

SubCommands imply SubCommandFromArgMatches

I'm tempted to actually just merge those two traits back together.
I was having lifetime issues with the constraints on the ParseApp trait so killed it until there's a better design for it, something that follows the different get_matches* functions and works with TryFrom<&ArgMatches> as well.

Coverage decreased (-0.007%) to 89.075% when pulling bb0d7bd67b20fa8210078a51399ce92f7a577d36 on Nemo157:stomp into 72d7bf39b948cada1acc5d1754650136df85714e on kbknapp:v3-master-dev.

Coverage decreased (-0.007%) to 89.075% when pulling bb0d7bd67b20fa8210078a51399ce92f7a577d36 on Nemo157:stomp into 72d7bf39b948cada1acc5d1754650136df85714e on kbknapp:v3-master-dev.

I've put in a PR with some very minor changes. I'm just starting to dig into the code, so I expect we'll both be making changes for a little bit and additions/deletions, so I view the code as living for the time being :smile:
Once we start to knock off some of these todos and we can clean up the commits and ensure everyhing is properly exported/visible. I also don't expect doc comments until we're settled on the implementation so don't worry about those yet unless something gets finalized.

I've been thinking about the attributes parsing a bit, it should be possible to create a macro based crate (probably macros 1.1 for extra metaness) to actually parse them, which will make using the values much nicer. It will probably also make updating them as the design changes a lot easier.
I threw together a macro_rules prototype, but extending it to support all the literal types would require a massive amount of duplication. You can see the simplification it would allow in Arg::from(syn::Field) though.
I think I could probably get a working derive crate for attributes up tomorrow and switch clap-macros over to it.

Took a little longer than I thought, but I've got a near production ready attribute parser up (https://github.com/Nemo157/prom-attire-rs) and opened a PR for switching clap-macros over to using it so you can take a look before I merge it https://github.com/Nemo157/clap-rs/pull/3

Hi, StructOpt author here.
First, I must say that there is high quality code and features in this PR. In fact, I feel quite depressed to see that my idea and implementation is present here with much more features and better error handling.
After reading all the related issues and lightly read this PR, I just have a few remarks:

Looking at the 61 stars of structopt in less that 24h, this feature is highly wanted. Thus I think that's important to publish this PR soon. If, that's not mergeable now, providing this in a temporary experimental crate (structopt, stomp or something else) will be very interesting  for user experience and to get feedback without the need of something highly polished.
There is some divergences with the clap interface. I think to the automatic Arg::long implementation when clap doesn't do such thing and the doc thing that generate some App::help. I think that's important to have an easy translation from attributes to builder pattern.
Most remarks say that the simple API is a killer feature. So, for the developper experience, I think that having something similar to MyApp::from_args() is very important. We can imagine a #[derive(Clap)] that implement App, FromArgMatches and an hypothetic FromArgs.
This code abuse implementing the From trait with possible panic. But the official rust doc explicitly say that "this trait must not fail". Thus, I think that's better not implementing this trait if failure is possible.
The TODO list at the top of this PR is quite confusing. I think that expressing them in the form of a simple test will help to understand the goal.
Some cosmetic stylish remarks.

If you have any remarks or thing I can do to help, just talk! ;-)

@TeXitoi Thanks for the comments! I agree this is a much wanted feature and something we need to look at merging soon. I'm good with merging something early under the unstable cargo feature as well, so it doesn't need to be perfect. I do however want to have most of the ergonomics and user-experience pieces to be worked out first though.
My only concern with having something like stomp or StructOpt around too long, is if their design goes against anything clap provides it presents a fracture in the ecosystem and makes it harder for people to adopt/change.
To be clear, I'm more concerned with deriving the ArgMatches->MyArgs conversion. The MyArgs->App can come later. Having said that, the MyArgs->App piece may be easier to implement in which case, if ti's done it's done, we can merge that part. I don't have hard requirement to finish one before the other. I'm only saying that I think people want the ArgMatches->MyArgs the most.
Here's what I mean by the two and how I imagine them working. Literally, this is my only requirements and once a PR reaches this state I'll be happy with a merge.
ArgMatches->MyArgs
User code:
enum VerbLevel {
    Off,
    Some,
    All
}

#[derive(FromArgMatches)]
struct MyArgs {
    verb_lvl: VerbLevel,
    files: Vec<PathBuf>,
    debug: bool
}

fn main() {
    let args: MyArgs = App::new("myprog")
        // ..snip
        .get_matches()
        .into();

    println!("Debug turned on?: {:?}", args.debug);
}

Subcommands can complicate this. But here's how Imagine those working:
enum VerbLevel {
    Off,
    Some,
    All
}

#[derive(FromArgMatches)]
struct MyArgs {
    verb_lvl: VerbLevel,
    files: Vec<PathBuf>,
    debug: bool,
    cmd: MySubCommands
}

#[derive(SubCommands)]
enum MySubCommands {
    Test(Test),
    Stuff(Stuff)
}

#[derive(FromArgMatches)]
struct Test {
    val: String
}

#[derive(FromArgMatches)]
struct Stuff {
    config: Option<String>
}

fn main() {
    let args: MyArgs = App::new("myprog")
        // ..snip
        .get_matches()
        .into();

    println!("Debug turned on?: {:?}", args.debug);
    match args.cmd {
        Test(t) => println!("val: {}", t.val),
        Stuff(s) => println("Config: {:?}", s.config),
    }
}

MyArgs->App
/// Some text that goes into App::about
#[derive(IntoApp)]
struct MyArgs {
    /// Some text that goes into Arg::help
    #[long = "verb", short = "v", takes_value=true, default_value="Off"]
    verb_lvl: VerbLevel,
    /// Some text describing --files <path>...
    #[long="files", takes_value=true, required=true, multiple=true]
    files: Vec<PathBuf>,
}

fn main() {
    let args: App = MyArgs::into()
        .get_matches();
}

Again, this may be more simple than ArgMatches->MyArgs and I'm fine if this merges independently from it.

Hopefully that clears some things up.

This code abuse implementing the From trait with possible panic.

Yes, but it shouldn't panic. Meaning, if it panics, there was a developer error and the program can't run anyways. In which case I think it should panic. I can't imagine a case where failing to parse should be allowed, or is desired. IMO it's perfectly acceptable, and even within the Rust guidelines, to panic due to developer error or when the program shouldn't be allowed to run further, which I view as this case.

I think that's important to have an easy translation from attributes to builder pattern.

I 100% agree! 👍 And I'm OK with /// some text being used Arg::help or App::about, but also 100% want to support #[help = "some text"] too. In clap there are already multiple ways to do things, and I'm OK supporting multiple ways so long as they make sense.
The automatic long handling, I'm less inclined about. I don't want to do something magically unless the user requested it. This could create issues when the user doesn't want a long.

Most remarks say that the simple API is a killer feature.

Again, I 100% agree with your comments 😄

The TODO list at the top of this PR is quite confusing. I think that expressing them in the form of a simple test will help to understand the goal.

I'll rework the TODO :wink:

@TeXitoi Welcome 😄 I had a brief look at StructOpt when it was posted to users and I was very impressed at how much it supported with such a small codebase.

the automatic Arg::long implementation when clap doesn't do such thing

The automatic long handling, I'm less inclined to support. I don't want to do something magically unless the user requested it. This could create issues when the user doesn't want a long.

I agree, that was just an artifact of my philosophy on CLI design.  It should be disabled and instead there could be the shortcut attribute #[clap(long)] that just uses the field name to determine the long option name.

the doc thing that generate some App::help.

And I'm OK with /// some text being used Arg::help or App::about, but also 100% want to support #[clap(help = "some text")] too.

Should be pretty simple, if there is a help or about attribute specified disable the doc handling and just use the values specified.

something similar to MyApp::from_args() is very important.

I had something like that as an extension trait originally, but when switching to implementing From<&ArgMatches> instead of a custom FromArgMatches I had difficulty getting the lifetimes to line up. I guess having it as an inherent impl on the type might avoid the lifetime issues.

I can't imagine a case where failing to parse should be allowed, or is desired.

I can't either, but I could definitely see it happening in the future. One way to future-proof it would be to implement TryFrom as well and have From::from be TryFrom::try_from(...).unwrap() (or something similar with nicer error messages). That way we would be forced to add proper errors for issues now, but most users can avoid doing any real error handling and treat any failures here as bugs in their application.

I also have some thoughts on the overall crate/code structure after setting up tests on prom-attire. I'll try and post something about them later today.

One way to future-proof it would be to implement TryFrom as well and have From::from be TryFrom::try_from(...).unwrap() (or something similar with nicer error messages).

I absolutely agree. But this is also something that can be added post initial merge too, so long as we think about it during the design.

The main change to the crate structure I think is useful is to divide clap-macros into two crates, the user-facing crate clap-macros (or maybe clap-derive) just defines the proc_macro and does minimal work. That then calls into an "internal" crate clap-codegen (or something similar) that has a function like pub fn derive(input: &str) -> Result<String, Vec<Error>> that does the actual derive.
This division makes it possible to test error cases, you can write tests in clap-codegen that pass in invalid strings and check the errors that are returned make sense. Passing back multiple errors lets you report on as many issues as possible each time the user attempts compilation.
Positive test cases can be put into the clap-macros test folder, they can just use #[derive(FromArgMatches)] like normal code would and check that the derived implementation behaves correctly.
clap-codegen should avoid panic! as much as possible, instead returning errors, clap-macros should pretty-print the errors returned then panic! to tell rustc that the derive invocation failed.

In addition, I may want to consider moving all the user facing macros to clap-macros.

I don't think a proc-macro crate can export macro_rules macros. But it could have non-derive proc-macros once they're stabilised.

Ah ok, no worries.