typo: resourcegroups type missing the s at the end so policy wont work as described

In the section above that discusses the policy mode the resourcegroups type is incorrectly specified :
"indexed should be used when creating policies that enforce tags or locations. While not required, it prevents resources that don't support tags and locations from showing up as non-compliant in the compliance results. The exception is resource groups. Policies that enforce location or tags on a resource group should set mode to all and specifically target the Microsoft.Resources/subscriptions/resourceGroup type."
type = “Microsoft.Resources/subscriptions/resourceGroup”
it should be:
type = “Microsoft.Resources/subscriptions/resourceGroups” - note the 's' at the end.

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

ID: 9762f1b7-0e3a-d58f-fd99-a27ad948907b
Version Independent ID: 89e28332-184e-ba84-df1f-e7698c5e0f7c
Content: Details of the policy definition structure - Azure Policy
Content Source: articles/governance/policy/concepts/definition-structure.md
Service: azure-policy
GitHub Login: @DCtheGeek
Microsoft Alias: dacoulte

@Danrawlings-msft Great catch!  Thank you for pointing it out. Since you found the issue, I'd love for you to get contributor status for it, but that requires submitting a Pull Request (PR).  If you've never done it, it's only a few steps.  I'll walk you through them, and if you don't want to or don't have time, I'll go ahead and fix this myself mid-day on Tuesday.
Here's the steps:

Click on the link in your Issue for Content Source. This will open the markdown document in GitHub. The alternative way to get there is from the docs.microsoft.com page where you saw the problem -- at the top on the right click Edit.
Sign in to GitHub if you aren't already.
On the right side of the document header is a pencil icon. The tooltip is Fork this project and edit the file if you haven't forked the repo, or Edit this file in your fork of the project if you've previously forked the repo.
Update the markdown to make the change.  In this case, add the 's' inside the codefence on line 90.
In the Propose file change box below the markdown editor, provide a title and description of your change. Be short, but accurate.
Click Propose file change. This opens a page comparing the changes you've made. If you are satisfied you made all the changes you intended to, click Create pull request.

I'll get notified and review the update for accuracy. Occasionally I have to request changes, but I'll work with you if that's necessary. For full steps, see How to Contribute to docs.microsoft.com.
Thanks again for spotting this issue!
@MicrosoftDocs/azure-cxp-triage Please assign to me, label 'doc-bug', and #in-progress

Thanks for submitting the fix for this @Danrawlings-msft !
@MicrosoftDocs/azure-cxp-triage #please-close

@Danrawlings-msft We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Update cosmos-db.md Example code and Samples

Corrects #39 and #40
Request #sign-off as per @TomArcher

@clarkio,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-services/cosmos-db.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


add steps to aliquot sum calculator

Is your feature request related to a problem? Please describe.

I want to add steps in this cal please assign me this issue

@ShrutiOmer I had opened the issue before #3000 Issue So I request to kidly close the issue

@khareyash05 I have opened the PR and actually worked on it, if you also worked please tell then I will close. Otherwise let me to go ahead with this issue.

Actually I have not..... So you may go ahead with the same

@khareyash05  Thankyou very much for this.


Change some unsigned int variables to NodeId.

Fix the getNodeId() function return value to NodeId
toInteger() is used because you want to be compatible with uint64_t

toInteger does not return an unsigned number. It has nothing to do with the compatibility with uint64_t.
Qt5 which is still supported by this library does not have the function toInteger

I merged some changes from this PR


hello# brother of good

@andrewachen @pablete @zkwentz @fabiokung @jkriss @devesh
I've spent time futile by tried for to find an application GUI for Windows, to extract informations via id or username of facebok, like as maltego. but maltego is very complication. i would like to buy this program 100$, but not cost 100$, but cost more.
Is there any thing for windows as the gift, to extract some informations from facebook, location, place, email.
I buy. In 100$
Other I there no
How I Can Use This Product !!!
Brother, there I can't see an video demonstration for to learning how is the use and implemention in those scripts that are programmed with python,ruby,perl.
Make things easy brother.

Setup instructions for this application can be found: https://github.com/Netflix/Scumblr/wiki.  We do not support windows for this tool.


Find winmd files without reading PATH nor copying to target/

Fixes #979
Non-Windows platforms - which are supported for cross-compiling - do not set the output directory in PATH nor use semicolons to separate this variable, resulting in errors Split out winmd "discovery" by emitting the path to these files in a build step, that is subsequently compiled into windows_gen.  This is more efficient than include_bytes! which was used prior to the PATH system as no copies or binary includes are required at all.  Copying of DLL targets to the target/ dir for easy consumption and running of crates is still performed, but only on Windows for the same PATH reason.
In the future, if a chain of crates is required to export winmd files for downstream crates to consume, this can be extended to also export their $CARGO_MANIFEST_DIR/.winmd/windows in such a way that the next crate can pick it up, again without copying any files around.
TODO
@riverar Linked to the copy function on an older commit, but I think he intended to link to the way the target directory for those copies was derived:
https://github.com/microsoft/windows-rs/blob/49ecfbc2f99cbc4bac32d6d771eeb589fe9d4e76/crates/macros/src/lib.rs#L121
Should be migrate back to this and drop any and all PATH handling entirely?

My link was just meant to show that we copy artifacts out of the .windows subfolders. No PATH handling should remain.

@riverar I interpreted it as pointing to a specific commit, conveniently right before PATH handling was introduced. Will remove!

https://github.com/microsoft/windows-rs/blob/49ecfbc2f99cbc4bac32d6d771eeb589fe9d4e76/crates/macros/src/lib.rs#L121-L132
I don't understand this loop. That's wrong if someone builds with their target folder in a different location.

Yep, that loop should not be needed anymore. It was an attempt to find dirs across crates which we no longer need.

Yep, that loop should not be needed anymore. It was an attempt to find dirs across crates which we no longer need.

It's gone now, let me know if this is okay. I'm happy because this has now unblocked building on Linux (I'm not cross-compiling at all :flushed:), but it should work for your Windows (and rustdoc) purposes as well.

@MarijnS95 🤣 I've actually had some internal interest for cross-platform support, so you never know.

@MarijnS95  I've actually had some internal interest for cross-platform support, so you never know.

Just shoot and I'll throw the cross-platform working DirectXShaderCompiler example back online :grin:
Joking aside, really glad to hear this.

Haven't had a chance to dig in, but a quick smoke testing compiling https://github.com/microsoft/windows-app-rs fails unfortunately.

For a change as invasive as this, it may also help to smoke out issues by building https://github.com/microsoft/windows-samples-rs

@kennykerr Can you clarify what exact issue you're seeing? For windows-app-rs, after fixing capitalization issues in cargo.toml, I'm left with the following:
error: `Microsoft.UI.Xaml.Application` not extendable
  --> src/main.rs:27:41
   |
27 | #[implement(extend Microsoft::UI::Xaml::Application, override OnLaunched)]
   |

Is this a result of building with the wrong metadata?
Same for the samples; what errors should I be looking out for? Do I need to be on Windows to test specific things (need to revive a Windows install first that decided to corrupt itself for no apparent reason)?

Yes, that's the error I saw. I would its misleading because the type is not actually found in metadata at all.

Yes, that's the error I saw. I think its misleading because the type is not actually found in metadata at all and because its not found its not extendable.

And that error isn't present when compiling against windows-rs master? This is hard to test for me currently due to the original "Path doesn't contain ;" errors.

Yes that error is not present in master.

@kennykerr It's pretty obvious what happens: bindings/ has the .windows/winmd directory used to generate bindings, but #[implement] in the root crate needs to use these files as well. We have various ways to solve this including ln -s .windows/winmd from the crate root, or "exporting" the winmd path from bindings as suggested in https://github.com/microsoft/windows-rs/issues/979#issuecomment-880198391 and pointing windows-rs to that one way or another, so that it uses the winmds directed by the bindings crate.
Let's discuss before jumping on an implementation detail.

ln -s .windows/winmd from the crate root

Tip: Symlinks in Windows require administrative privileges in normal scenarios, so that's out.

@riverar I'm unfortunately aware, and it nauseates me. IMO this should be fully solved from Rust, no messing around with paths and links/copies by the user.

(EDIT: This requirement is pretty much your "scenario 3" we were trying to avoid 😛)

This worked before because the .windows folder was relative to the workspace rather than the crate so both crates shared the same .windows/winmd folder.

Basically, the TypeReader should

look in <workspace>/.windows/winmd and
add the gen crate's default winmd files if the previous step didn't have any windows.* winmd files.

This worked before because the .windows folder was relative to the workspace rather than the crate so both crates shared the same .windows/winmd folder.

"Before" referring to the situation before, PATH changes, correct? Now on master it works because of unregulated copies to the target folder.

Basically, the TypeReader should

look in <workspace>/.windows/winmd and
add the gen crate's default winmd files if the previous step didn't have any windows.* winmd files.

That's what it's doing already, but not relative to <workspace> but the <crate> (CARGO_MANIFEST_DIR), as you said in your previous comment. This <crate> changes between building a "toplevel" package and its bindings crate.
Should we use cargo metadata to point windows-rs to a different directory, so that we can just parse $CARGO_MANIFEST_DIR/Cargo.toml?

Yes, that's the way it worked before the binary packaging support was added.

I need to get this wrapped up. It sounds like you still have some open questions about how to proceed. Do you mind terribly if I just take this over and get it done. I'd like to get this fixed up and publish a new version of the crate.

Closing in favor of #1067

It sounds like you still have some open questions about how to proceed. Do you mind terribly if I just take this over and get it done. I'd like to get this fixed up and publish a new version of the crate.

I don't have time for this back-and-forth so feel free. Looks like #1067 is a simple "yes" to my question inhttps://github.com/microsoft/windows-rs/pull/1047#issuecomment-900512379, but in code form.

@kennykerr Do you mind awfully if I rebase this branch and open a new PR after yours is merged, so that we at least keep some cleanups/simplifications?

That would be great.


avoid decode to nil value

Codecov Report

Merging #21 into master will decrease coverage by 0.18%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master      #21      +/-   ##
==========================================
- Coverage   59.65%   59.46%   -0.19%
==========================================
  Files          24       24
  Lines         632      634       +2
==========================================
  Hits          377      377
- Misses        209      211       +2
  Partials       46       46

Impacted Files
Coverage Δ

net/addr.go
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


[vcpkg ci,liburing] Improve license identifier check

Add annotations directly below license field, for better visibility.
Write to workflow summary.
Handle more complex license expressions.

Screenshot:

We will take this subject to the nitpicks :)


[TOMEE-4035] Upgrade dependencies (SmallRye, Jackson, ...)

versions of SmallRye that were RC are now stable releases.
hibernate 6.0 is EOL, use 6.1 instead (compatible jakarta 9.1).
updated mojarra (faces) to 3.0.2 eclipselink to 3.0.3 krazo (mvc) to 2.0.2

@rzo1 it's ready

Thanks! CI is currently failing due to RAT checks on main. I will push a fix shortly.

ok, thank you for letting me know !

Thanks! CI is currently failing due to RAT checks on main. I will push a fix shortly.

I think that's my fault.  I'm happy to clean my mess if you haven't already done it.

@dblevins I added the missing header, so we are good to move ahead here :)

Thanks @sultan


mpv doesn't open automatically when selected through the prompt after running watch, but does when running watch -- --mpv

Hi,
So if I type just watch in the command line, go through the prompts, and select mpv on the last step, the streaming server will start but mpv doesn't automatically open and connect. If I manually start mpv, it connects to the server fine.
When I type watch -- --mpv, mpv starts automatically upon selecting a download.
A similar thing happens with VLC. VLC opens and plays automatically when it's specified in the first command, but when I select it through the prompts it opens but doesn't play automatically. I suspect that this issue might have to deal with webtorrent, and not watch.
I have both VLC and mpv installed with Homebrew Cask.
mpv:
mpv 0.26.0 (C) 2000-2017 mpv/MPlayer/mplayer2 projects
 built on Mon Jul 24 16:20:40 CEST 2017
ffmpeg library versions:
   libavutil       55.58.100
   libavcodec      57.89.100
   libavformat     57.71.100
   libswscale      4.6.100
   libavfilter     6.82.100
   libswresample   2.7.100
ffmpeg version: 3.3.2

Running on a MacBook Pro, Early 2015. macOS Sierra 10.12.6. Shell is zsh.

Never mind; when I tried to debug the issue it fixed itself? Not sure what's going on.

I've no clue on this.
The latest version (1.2.0) supports calls like watch -- --app more reliably though, I'd recommend an update.

I'm on the latest version of watch.
I'm pretty sure what happened is that I didn't let webtorrent buffer the video long enough. It seems that it only starts playing the video when the video is completely buffered.
I probably tested watch -- --app with a video that was easier to buffer, or had already been cached by my first run with just watch, so it seemed like latter was more responsive than the former. If I run just watch and wait for webtorrent to buffer, then everything works fine.
There doesn't seem to be a bug here in watch. I wish webtorrent printed some line that said "buffering media before opening video player."

I'm not terribly familiar with how webtorrent-cli works but I think it opens the media player right away, but still the latter has to wait until the beginning of the video has been downloaded, depending on how popular a particular torrent is and how lucky you are with your peers this may take a bit.


Implement crop_active_window function

#84
This pull request implements the crop_active_window function and adds necessary helper functions in record.py and utils.py to support the cropping of the active window from a screenshot.
Changes Made:
In record.py:
Added get_active_window_coordinates_windows() to retrieve the coordinates of the active window on Windows.
Added get_active_window_coordinates_macos() to retrieve the coordinates of the active window on macOS.
Added get_active_window_coordinates_linux() to retrieve the coordinates of the active window on Linux.
Added get_active_window_coordinates() to get the coordinates of the active window based on the current operating system.
Implemented crop_active_window() to crop the active window from a screenshot.
In utils.py:
Updated the crop() function to accept window_coordinates as an argument.
Calculated the width and height of the cropping region based on the provided window coordinates.
Used the mss library to grab the data of the cropped region from the screenshot.
Any feedback is appreciated 🙏🏻thanks!

Hi @jesicasusanto , thank you for the PR!
It looks like I may not have been clear about the approach. Is there a reason why we don't want to use WindowEvent.left/top/width/bottom https://github.com/MLDSAI/OpenAdapt/blob/main/puterbot/models.py#L221 here?

Hi @abrichr ! thanks for giving feedback🙏🏻! I have tried getting the window event by this line of code :
window_event = get_window_events(get_latest_recording())
I think that I wasn't able to get the window events within the crop_active_window function because I am trying to access an SQLite object which is the recording object from the main thread. However, crop_active_window is being called in the screen_event_reader thread.
My approach to address this issue is to delete the crop_active_window and directly crop the active window within the read_screen_events function.
This was the error message I got regarding the threading issue :
 File "c:\users\jesic\pycharmprojects\pat\puterbot\record.py", line 358, in crop_active_window     window_event = get_window_events(get_latest_recording())       File "c:\users\jesic\pycharmprojects\pat\puterbot\crud.py", line 86, in get_latest_recording     .first()   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\site-packages\sqlalchemy\orm\query.py", line 2823, in first            return self.limit(1)._iter().first()   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\site-packages\sqlalchemy\orm\query.py", line 2915, in _iter            result = self.session.execute(   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\site-packages\sqlalchemy\orm\session.py", line 1714, in execute        result = conn._execute_20(statement, params or {}, execution_options)   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\engine\base.py", line 1705, in _execute_20     return meth(self, args_10style, kwargs_10style, execution_options)   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\sql\elements.py", line 333, in _execute_on_connection     return connection._execute_clauseelement(   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\engine\base.py", line 1572, in _execute_clauseelement     ret = self._execute_context(   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\engine\base.py", line 1806, in _execute_context     self._handle_dbapi_exception(   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\engine\base.py", line 2124, in _handle_dbapi_exception     util.raise_(   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\site-packages\sqlalchemy\util\compat.py", line 208, in raise_          raise exception   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\engine\base.py", line 1800, in _execute_context     context = constructor(   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\engine\default.py", line 1020, in _init_compiled     self.cursor = self.create_cursor()   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\engine\default.py", line 1391, in create_cursor     return self.create_default_cursor()   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\si te-packages\sqlalchemy\engine\default.py", line 1394, in create_default_cursor     return self._dbapi_connection.cursor()   File "C:\Users\jesic\PycharmProjects\PAT\puterbot\.venv\lib\site-packages\sqlalchemy\pool\base.py", line 1111, in cursor           return self.dbapi_connection.cursor(*args, **kwargs)         sqlalchemy.exc.ProgrammingError: (sqlite3.ProgrammingError) SQLi te objects created in a thread can only be used in that same thr ead. The object was created in thread id 18248 and this is thread id 26056. [SQL: SELECT recording.id AS recording_id, recording.timestamp A S recording_timestamp, recording.monitor_width AS recording_moni tor_width, recording.monitor_height AS recording_monitor_height,  recording.double_click_interval_seconds AS recording_double_cli ck_interval_seconds, recording.double_click_distance_pixels AS r ecording_double_click_distance_pixels, recording.platform AS rec ording_platform, recording.task_description AS recording_task_description FROM recording ORDER BY recording.timestamp DESC  LIMIT ? OFFSET ?] [parameters: [{}]] (Background on this error at: https://sqlalche.me/e/14/f405)

Hi @jesicasusanto , to clarify, I don't think we want to modify record.py in any way for this. Instead, let's add a ScreenShot.get_active_window() that gets the most recent WindowEvent before the ScreenShot and uses it to crop the image.
Does that make sense? Please let me know if anything is unclear!

Thank you for your feedback! Yes, that makes sense and I will work on that.

Hi @abrichr
I have created a get_active_window class method.
I would like to ask clarification on a related matter. When we refer to "cropping" the screenshot, does it mean that we should modify the  Screenshot.take_screenshot()  to capture only the active window?
Please let me know if you have concerns or suggestions.
Thank you!

I would like to ask clarification on a related matter. When we refer to "cropping" the screenshot, does it mean that we should modify the Screenshot.take_screenshot() to capture only the active window?

Hi Jesica!,
I believe the goal is to continue taking screenshots as normal, but have access to a cropped version of the screenshots to assist with replay strategies.
Motivation: during DemoReplayStrategy we extract all text using OCR, and convert the screenshot to an ASCII representation. It would be more efficient to instead use a cropped version of screenshot and only extract/convert what's necessary.
If this is the case, this pull request, should help with cropping.
Please let me know if I should make any changes or corrections.
Thanks!

Hi @AvidEslami Thank you for your help! I'll test the get_active_window function too.


GH-43487: [Python] Sanitize Python reference handling in UDF implementation

Remove spurious increfs (the function object is already incref'ed at an upper level)
Add unit test with an ephemeral Python function object
Streamline and improve Python reference handling

GitHub Issue: #43487

@github-actions crossbow submit -g python -g wheel

@rtpsw You're one of the people who made significant changes to the UDF implementation, can you perhaps take a look?

@lysnikolaou Are you able to test this PR to see if this solves your issue?

@pitrou Thanks for having a look at this.
Confirmed that the whole test suite passes when run under a debug build of 3.13 with this PR.

Thanks @lysnikolaou . By the way, do you build a debug mode Python yourself? Or is there a Conda package available somewhere?

By the way, do you build a debug mode Python yourself?

I'm either building by myself or using pyenv.

@rtpsw You're one of the people who made significant changes to the UDF implementation, can you perhaps take a look?

Apologies, I currently don't have the resources to handle this.

Our new test-conda-python-3.12-cpython-debug CI job now passes.

@pitrou I can help review the best I can but please give me a little bit of time. I will try to get to this tomorrow.


[qa] Move CI to GitHub Actions #224

Removed Travis CI integration
Closes #224

Testing the build.

I messed up the commit message while squashing through GitHub's UI. I have fixed it now.

I messed up the commit message while squashing through GitHub's UI. I have fixed it now.


Veterinarians tab showing null values on second visit

When I start the application and visit the veterinarians tab, it initially appears populated with data. When I then visit the home page and return to this tab, it appears populated with null values, as in the attached screenshot.

There is nothing in the logs indicating that this request is even making it to the server (though the error tab still generates the (expected) exception [Request processing failed; nested exception is java.lang.RuntimeException: Expected: ontroller used to showcase what happens when an exception is thrown] with root cause

I have the same issue.

It's the cache config, sorry. Fixed in c7657df.


Remove open/close datachannels in the PeerConnection interface

https://github.com/uProxy/uproxy-lib/blob/dev/src/webrtc/peerconnection.ts
https://github.com/uProxy/uproxy-lib/blob/dev/src/webrtc/datachannel.ts
Some meeting this past fall, we decided the PeerConnection interface would be a good place to abstract out the notion of a network transport plugin (e.g. WebSockets)
In light of the recent developments in using DataChannel pools due to problems with the WebRTC spec and performance, we might want to consider removing the notion of opening/closing datachannels and assume that the transport provider takes care of this. (the original freedom.js transport API had a notion of a tag, which loosely corresponds to a datachannel ID here)
This would be compatible with a provider that would, for example, maintain a pool of 4 WebSocket connections.

And it would be up to the transport provider to silently open/close/re-use channels?
Seems like this might make sense for some kind of "transport" interface, but probably not for a peerconnection-like interface.

https://github.com/uProxy/uproxy/issues/1309

That sounds great! I agree we should think about a more generic transport interface (e.g. that a Web Socket-based transport would write against). Last time we had a meeting about this, it was suggested we conform to PeerConnection. I am in favor of a more generic transport interface.

Seems like this issue may be converging with this one: https://github.com/uProxy/uproxy/issues/653
We definitely need an abstraction of transport to support other forms of transport for proxying (e.g. WebSockets https://github.com/uProxy/uproxy/issues/588 or DropBox https://github.com/uProxy/uproxy/issues/197). I think the next step here is to write a design proposal for what that would looks like. Lets get the designs to include the interface as a TypeScript type so that it's easily readable.

Agree this code could really use a cleanup but I don't see us changing the peerconnection interface anytime soon.


Data preprocessing

Hi,
Could you please provide the command you used to generate the parses to use as input, as well as any other preprocessing steps required? I have some data that I would like to test your system on, how should I generate an input file in the correct format?
Thanks!

Thanks!


Exhaustion of dynamic TCP ports by reverse proxy middleware

1. What version of Caddy are you running (caddy -version)?
v0.8.3 / v0.9.0
OS Windows Server 2012 R2 running on Azure instance 'Standard D3 v2' (4 cores, 14 GB memory)
2. What are you trying to do?
Measure performance of caddy reverse proxy middleware under heavy load using Apache Bench.
3. What is your entire Caddyfile?
caddyfile_proxy:
http:// {
	errors CaddyErrors.log
	header / {
		-Server
	}
	proxy / localhost:580 {
		proxy_header Host {host}
		proxy_header X-Real-IP {remote}
		proxy_header X-Forwarded-Proto {scheme}
	}
}

caddyfile_upstream:
http://:580 {
	errors CaddyErrors_upstream.log
    header / {
		-Server
	}
	root WebRoot
}

The WebRoot folder contains file index.html:
<!DOCTYPE html><meta charset="utf-8"><meta name="format-detection" content="telephone=no"><meta name="viewport" content="width=device-width,initial-scale=1"><title>1234567 12345</title>

4. How did you run Caddy (give the full command and describe the execution environment)?
caddy.exe -conf=Caddyfile_proxy

and then in new shell:
caddy.exe -conf=Caddyfile_upstream

5. What did you expect to see?
Apache Bench completing with 0 failed requests.
6. What did you see instead (give full error messages and/or log)?
Apache Bench with the following result (note the failed requests):
This is ApacheBench, Version 2.3 <$Revision: 1748469 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking *** (be patient)

Server Software:
Server Hostname:        ***
Server Port:            80

Document Path:          /
Document Length:        224 bytes

Concurrency Level:      10000
Time taken for tests:   104.036 seconds
Complete requests:      1000000
Failed requests:        953057
   (Connect: 0, Receive: 0, Length: 953057, Exceptions: 0)
Non-2xx responses:      953057
Keep-Alive requests:    1000000
Total transferred:      179237926 bytes
HTML transferred:       25764144 bytes
Requests per second:    9612.05 [#/sec] (mean)
Time per request:       1040.361 [ms] (mean)
Time per request:       0.104 [ms] (mean, across all concurrent requests)
Transfer rate:          1682.46 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0      20
Processing:    62  445 1122.4    219   65240
Waiting:       62  445 1122.4    219   65240
Total:         62  445 1122.4    219   65240

Percentage of the requests served within a certain time (ms)
  50%    219
  66%    313
  75%    359
  80%    422
  90%    656
  95%   1391
  98%   2416
  99%   3957
 100%  65240 (longest request)

CaddyErrors.log:
19/Jul/2016:07:33:31 +0000 [ERROR 502 /] unreachable backend
19/Jul/2016:07:33:31 +0000 [ERROR 502 /] unreachable backend
19/Jul/2016:07:33:31 +0000 [ERROR 502 /] unreachable backend
...

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?
Run Apache Bench on another machine with the following parameters (note 10k concurrent connections):
ab.exe -n 1000000 -c 10000 -k http://remote-machine-running-caddy/

Hypothesis
The failed requests are most likely caused by the exhaustion of ephemeral TCP ports by the reverse proxy middleware. When querying the remote machine I get:
PS C:\Users\localadmin> Get-NetTCPConnection

LocalAddress                        LocalPort RemoteAddress                       RemotePort State
------------                        --------- -------------                       ---------- -----
<IP_ADDRESS>                           64381     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64380     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64379     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64378     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64377     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64376     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64375     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64374     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64373     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64372     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64371     <IP_ADDRESS>                           580        TimeWait
<IP_ADDRESS>                           64370     <IP_ADDRESS>                           580        TimeWait
...
(followed by thousands of entries)

PS C:\Users\localadmin> Get-NetTCPConnection -RemotePort 580 -LocalAddress '::1' | measure
Count    : 0
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

PS C:\Users\localadmin> Get-NetTCPConnection -RemotePort 580 -LocalAddress '<IP_ADDRESS>' | measure
Count    : 15629
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

PS C:\Users\localadmin> netsh int ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

Once the exhaustion occurs, the proxy starts failing by returning 502 Bad gateway errors and recovers only after the ports are recycled.
The behaviour is worse on Caddy v0.9.0 as the ports seem to be exhausted faster. Also after benchmark of v0.9.0, I get a large number of IPv6 connections as well:
PS C:\Users\localadmin> Get-NetTCPConnection -RemotePort 580 -LocalAddress '::1' | measure
Count    : 11697
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

PS C:\Users\localadmin> Get-NetTCPConnection -RemotePort 580 -LocalAddress '<IP_ADDRESS>' | measure
Count    : 8286
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

I can reproduce the issue with Gatling as well. To rule off issues with the caddy_upstream instance, I ran the benchmark against the caddy_upstream instance directly and received no failing requests.
I know it is possible to reconfigure OS to use more ephemeral ports and shorten the TIME_WAIT period. The condition could also be mitigated by having multiple upstream hosts but once the condition occurs, the proxy is basically dead until the ports are recycled.
Does caddy implement TCP connection pooling or is a new connection opened for every upstream request? Maybe there should be some connection limit to prevent the condition from happening.

When a proxy upstream has an error with one request, that upstream is marked as down for a certain period of time (default is 10s) to give it a chance to recover without suffering performance hits.
We're aware this could be improved; perhaps @nemothekid would have some ideas. Probably related to #667.
I'm not sure why 0.9 would be performing much differently here though.

In this case, since the ports are exhausted, every upstream will technically be marked as down, (which is causes the 503). The actual reverse proxy is handled by the golang net/http code and that should support connection pooling (via keep-alive, see the DisableKeepAlive value on Transport). I don't immediately see why this wouldn't work - it will probably take a deeper dive in the pooling code in net/http

@mholt

When a proxy upstream has an error with one request, that upstream is marked as down for a certain period of time (default is 10s) to give it a chance to recover without suffering performance hits.

Thank you for the information, I re-tested using boom with proxy options fail_timeout 0 and max_fails 0 and the behavior changed. Now there are no errors in the log and all requests seem to succeed :+1: (albeit after a while). This seems to be a partial fix as an attempt to contact the upstream is made every time.
However even with this fix, the proxy seems to be making only a small number of requests to the upstream caddy as most of the connections lingers in TIME_WAIT state.  So it still seems there is an unbounded connection pool where a new upstream connection is opened for every incoming request :-(

Seeing the same in CoreDNS. I'm going to add some socket pooling for this.
On 20 Jul 2016 9:55 a.m., "Tomáš Deml"<EMAIL_ADDRESS>wrote:

@mholt https://github.com/mholt
When a proxy upstream has an error with one request, that upstream is
marked as down for a certain period of time (default is 10s) to give it a
chance to recover without suffering performance hits.
Thank you for the information, I re-tested using boom with proxy
options fail_timeout 0 and max_fails 0 and the behavior changed. Now
there are no errors in the log and all requests seem to succeed 👍
(albeit after a while). This seems to be a partial fix as an attempt to
contact the upstream is made every time.
However even with this fix, the proxy seems to be making only a small
number of requests to the upstream caddy as most of the connections lingers
in TIME_WAIT state. So it still seems there is an unbounded connection
pool where a new upstream connection is opened for every incoming request
:-(
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mholt/caddy/issues/938#issuecomment-233891704, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVkW5d-kmdECtmgJ3vGTbxfqFAVWL1Lks5qXeKPgaJpZM4JPhdl
.

@mholt, @nemothekid Could you reproduce the issue? I would be happy to provide more information, if you need some.
Also may I ask if you plan to address the issue in near future? IMO with default OS configuration, the proxy may not be very usable under production workloads.

Sorry, been busy with a few things -- I will get around to this soon! Anyone is welcome to take a look at this in the meantime.

I may be seeing a related issue when trying to reverse proxy a rethinkdb admin ui.  I created a branch in my repo where one can reproduce the issue using docker containers here:
https://github.com/ubergarm/stack-in-a-box/tree/proxy-issue
1. What version of Caddy are you running (caddy -version)?
$ docker --version
Docker version 1.11.2, build b9f10c9
$ docker-compose --version
docker-compose version 1.8.0-rc1, build 9bf6bc6
$ docker run --rm -it ubergarm/caddy --version
Caddy 0.9.0
$ cat /proc/version
Linux version 3.10-2-amd64<EMAIL_ADDRESS>(gcc version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.10.7-1 (2013-08-17)
# also confirmed the problem exists on new Ubuntu 16.04 desktop

2. What are you trying to do?
Reverse proxy rethinkdb Admin interface.
3. What is your entire Caddyfile?
http://localhost {
    redir https://localhost{uri}
}

https://localhost {
    root /html

    proxy /admin rdb:8080 {
        without /admin
    }

    log stdout
    errors stderr

    tls self_signed
}

4.
From the Dockerfile.caddy you can see it is calling caddy_linux_amd64 -agree. The rethinkdb is linked to the Caddy container so it can find it at hostname rdb.
5. What did you expect to see?
I expected to see all 200 responses.
6. What did you see instead (give full error messages and/or log)?
Sometimes I would get a 502 error instead, but this never happens when hitting
the service directly instead of through the reverse proxy.
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:49 +0000] "POST /admin/ajax/reql/?conn_id=G+r4LTLCk3MAw0arPi4GAQ== HTTP/2.0" 200 86
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:50 +0000] "POST /admin/ajax/reql/?conn_id=G+r4LTLCk3MAw0arPi4GAQ== HTTP/2.0" 200 86
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:52 +0000] "POST /admin/ajax/reql/?conn_id=G+r4LTLCk3MAw0arPi4GAQ== HTTP/2.0" 200 86
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:52 +0000] "POST /admin/ajax/reql/?conn_id=BhMc83y3tIBZ3hAEbwakVg== HTTP/2.0" 200 308
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:52 +0000] "POST /admin/ajax/reql/?conn_id=fOvF/MDLQxOqZ2CzXClMUA== HTTP/2.0" 200 451
caddy_1  | 30/Jul/2016:17:30:52 +0000 [ERROR 502 /ajax/reql/] unreachable backend
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:52 +0000] "POST /admin/ajax/reql/?conn_id=ZLD9NCq4/ytwEolR8YHn4Q== HTTP/2.0" 502 16
caddy_1  | 30/Jul/2016:17:30:53 +0000 [ERROR 502 /admin/ajax/reql/] unreachable backend
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:53 +0000] "POST /admin/ajax/reql/?conn_id=G+r4LTLCk3MAw0arPi4GAQ== HTTP/2.0" 502 16
caddy_1  | 30/Jul/2016:17:30:57 +0000 [ERROR 502 /admin/ajax/reql/] unreachable backend
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:57 +0000] "POST /admin/ajax/reql/?conn_id=BhMc83y3tIBZ3hAEbwakVg== HTTP/2.0" 502 16
caddy_1  | 30/Jul/2016:17:30:57 +0000 [ERROR 502 /admin/ajax/reql/] unreachable backend
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:30:57 +0000] "POST /admin/ajax/reql/?conn_id=fOvF/MDLQxOqZ2CzXClMUA== HTTP/2.0" 502 16
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:20 +0000] "POST /admin/ajax/reql/close-connection?conn_id=fOvF/MDLQxOqZ2CzXClMUA== HTTP/2.0" 200 0
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:20 +0000] "POST /admin/ajax/reql/close-connection?conn_id=G+r4LTLCk3MAw0arPi4GAQ== HTTP/2.0" 200 0
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:21 +0000] "POST /admin/ajax/reql/open-new-connection?cacheBuster=0.8526856273987615 HTTP/2.0" 200 24
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:21 +0000] "POST /admin/ajax/reql/?conn_id=JR35LdPBV83pMJiV+ulBew== HTTP/2.0" 200 136
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:21 +0000] "POST /admin/ajax/reql/close-connection?conn_id=JR35LdPBV83pMJiV+ulBew== HTTP/2.0" 200 0
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:21 +0000] "POST /admin/ajax/reql/open-new-connection?cacheBuster=0.06600066906892221 HTTP/2.0" 200 24
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:21 +0000] "POST /admin/ajax/reql/open-new-connection?cacheBuster=0.3583739526723704 HTTP/2.0" 200 24
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:21 +0000] "POST /admin/ajax/reql/open-new-connection?cacheBuster=0.9304607503322764 HTTP/2.0" 200 24
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:22 +0000] "POST /admin/ajax/reql/?conn_id=JmLkP3jf4Xfc7MEr6Lyyyw== HTTP/2.0" 200 308
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:22 +0000] "POST /admin/ajax/reql/?conn_id=WQdrwkyUaT+BZB1z3lKxbg== HTTP/2.0" 200 86
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:22 +0000] "POST /admin/ajax/reql/?conn_id=HisapNMBfQhcmne46hqqPg== HTTP/2.0" 200 450
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:23 +0000] "POST /admin/ajax/reql/?conn_id=WQdrwkyUaT+BZB1z3lKxbg== HTTP/2.0" 200 86
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:24 +0000] "POST /admin/ajax/reql/?conn_id=WQdrwkyUaT+BZB1z3lKxbg== HTTP/2.0" 200 86
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:25 +0000] "POST /admin/ajax/reql/?conn_id=WQdrwkyUaT+BZB1z3lKxbg== HTTP/2.0" 200 86
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:26 +0000] "POST /admin/ajax/reql/?conn_id=WQdrwkyUaT+BZB1z3lKxbg== HTTP/2.0" 200 85
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:27 +0000] "POST /admin/ajax/reql/?conn_id=JmLkP3jf4Xfc7MEr6Lyyyw== HTTP/2.0" 200 308
caddy_1  | <IP_ADDRESS> - [30/Jul/2016:17:31:27 +0000] "POST /admin/ajax/reql/?conn_id=HisapNMBfQhcmne46hqqPg== HTTP/2.0" 200 451

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?o reproduce the issue do:
git clone https://github.com/ubergarm/stack-in-a-box
cd stack-in-a-box
git checkout proxy-issue
docker-compose build
docker-compose up

Keep an eye on TCP port status (see how TIME WAIT (tw) increases):
watch -n.5 -d cat /proc/net/sockstat

Open a browser to https://localhost/admin.
Each reload of the main page adds just under 100 to tw.
Hypothesis
Reload the main page and click around on the UI or just wait and it
seems that as the number of TCP tw sockets grows it will eventually miss
a request.  Then after the default 10 seconds timeout the OS might have
recycled some sockets and it will start working again.
Quick Fix
Thanks @tomasdeml , setting fail_timeout 0 and max_fails 0 alleviates the symptoms for now.

So I was able to actually "fix" the issue by setting MaxIdleConnsPerHost on the transport to something relatively high (I set it to 8192, the default is 2).
b@cass3:~$ ab -n 1000000 -c 10000 -k http://<IP_ADDRESS>:4040/
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking <IP_ADDRESS> (be patient)
Completed 100000 requests
Completed 200000 requests
Completed 300000 requests
Completed 400000 requests
Completed 500000 requests
Completed 600000 requests
Completed 700000 requests
Completed 800000 requests
Completed 900000 requests
Completed 1000000 requests
Finished 1000000 requests

Server Software:
Server Hostname:        <IP_ADDRESS>
Server Port:            4040

Document Path:          /
Document Length:        226 bytes

Concurrency Level:      10000
Time taken for tests:   75.011 seconds
Complete requests:      1000000
Failed requests:        0
Keep-Alive requests:    1000000
Total transferred:      458000000 bytes
HTML transferred:       226000000 bytes
Requests per second:    13331.30 [#/sec] (mean)
Time per request:       750.115 [ms] (mean)
Time per request:       0.075 [ms] (mean, across all concurrent requests)
Transfer rate:          5962.63 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3  32.5      0     439
Processing:     7  743 300.9    687    3477
Waiting:        7  733 286.8    684    3376
Total:          7  746 302.4    688    3477

Percentage of the requests served within a certain time (ms)
  50%    688
  66%    797
  75%    884
  80%    945
  90%   1134
  95%   1317
  98%   1538
  99%   1775
 100%   3477 (longest request)

Like I suspected, the "problematic" code isn't with Caddy, but with golang's http pooling implementation (in transport.go). When there are large number of incoming connections, the number of pooled idle connections essentially doesn't matter and a new connection is opened (and maybe closed?) for every request.
The pooling functionality has changed a bit in tip, however I'm not sure if the new code fixes this issue.
Possible suggestion for moving forward.

Expose a keepalive directive  (like nginx) that allows you to specify the number of maximum idle connections you want to keep around (although I had to set it pretty high for ab to work - I'm not sure what the optimal number should be).

See if there are any optimization you can make in golang's connection pooling to alleviate this issue.

I recommend we go with option 1, despite any other changes as its probably a tuning parameter we need to expose.
w.r.t option 2, I'm not 100% if the current pooling code is performant. When I tried with 2048 MaxIdleConnsPerHost I still got errors, and I'm not sure if a server like nginx would be able to handle the same benchmark with the same amount of idle connections. I'd also need more info on how nginx manages idle connections to know for sure (for example, does nginx temporarily increase the pool, and only close after some timeout?)

https://engineering.gosquared.com/optimising-nginx-node-js-and-networking-for-heavy-workloads (see nginx section)
If you are hitting this error, consider increasing MaxIdleConnsPerHost option (if I end up writing this PR, it will likely be called keepalivelike nginx). I'm not sure what the optimal values are, but if you have 10,000 concurrents, the default pool size (2) is likely not enough.
Setting fail_timeout 0 and max_fails 0 only masks the issue, it simply keeps retrying to contact the upstream server until the OS finally clears some of the sockets in TIME_WAIT, at which point it can communicate again.


Serial data encoding format

Version: 1.0.120
Platform: win32 10.0.18363
Plugins: relaxed-theme, save-output
Does the serial data encoding format support modification?

What kind of format do you mean?

What kind of format do you mean?


set env flag to allow chef install to complete in ci jobs

Signed-off-by: Jose Hernandez<EMAIL_ADDRESS>Description
The CI jobs that install chef are failing due to the add-path deprecation as explained here: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands. This is blocking PRs from being evaluated/merged.
This PR is to set the ENV var that should allow the chef-install action in the ci jobs to complete.
Check List

[ ] All tests pass. See TESTING.md for details.
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable.

Hi, can someone please review this and push it through?

Thank you Lance. We are back to running into the same deprecation issue with the windows cookbook that this cookbook depends on.
I saw that Tim Smith did a commit to address this (https://github.com/chef-boneyard/windows/commit/1f803a01d405de4f2a7e0b99042104e5744a22df) back in May 26th on that repo. Given that the cookbook is said to be deprecated and no longer maintained per the chef supermarket page for it, do you know if anyone is intending to update it in supermarket with the latest changes so that the ci jobs in this repo can complete?
Or are there any plans to break the dependency on the windows cookbook now that it is no longer maintained? Until this is resolved the only way to merge PRs in this repo would be by forcing the merge.

Hi again Lance,
I think I resolved the windows cookbook dependency issue. The only thing I found using it was in the server.rb recipe, which was using the 'win_friendly_path' helper from the windows cookbook when creating the SQL installer config file. I can't think of a reason why this is needed anymore, as Chef can handle the windows paths natively without issue now. Maybe in the past that wasn't the case.
In any case, I removed the use of that windows_cookbook helper and removed the windows cookbook dependency from the metadata file. I also added the required line to the configure.rb & install.rb resource files to avoid the Chef Client 17+ deprecation warning issue. All the test kitchens on my end were successful after doing that. Please review at your convenience.

@JHBoricua yeah removing that cookbook dep would be great. Looks like you need to fix the ChefSpec for this to move forward.

@ramereth looks like 4 out of the 17 windows integration checks failed with what appears to be vagrant/virtualbox resource contention issues leading to either failure to launch the vm instance or timeout issues during the test. Not sure if the four failed checks can be re-run individually by you. Otherwise everything looks good.

Good morning @ramereth,
I see the checks were kicked off again last night. This time 3 of the 17 integration tests failed instead of 4, so this seems to validate my suspicion that too many of the integration jobs are trying to run in parallel and are overwhelming the system that's running the VMs, leading to random timeouts. For this latest test cycle I see the following:

integration (windows-2016, install) - Chef successfully completed install and issued reboot. The VM either failed to reboot due to a locked process preventing it or failed to reboot fast enough for chef to reconnect in its allotted time, thus the job failed.
integration (windows-2016, server2016) - Chef timed out and was unable to connect to the VM via winrm 23 minutes after the install of SQL was initiated.
integration (windows-2019, install) - Chef successfully completed install and issued reboot. The VM either failed to reboot due to a locked process preventing it or failed to reboot fast enough for chef to reconnect in its allotted time, thus the job failed.

Are we ok with calling this good and allowing it to merge so that other PRs can be properly evaluated? I'm not sure what else I can do to alleviate the VM integration test issue, as I'm not too familiar with Github CI.

Hi,
Quick ping on this PR. Can someone review the failed tests and my comments on them 9 days ago and make a call on whether to allow this to merge?

Thanks @JHBoricua, nice little fix!
Can you add an entry in the CHANGLOG under unreleased please?

Hi @damacus, I added the entries you requested.

There's a bug with Windows 2016, but I think that's one for the next PR!
big thanks for fixing this!

Released as: 7.0.0


Accept an optional platform spec in the environments.yaml

I have found platform specifications to be a useful feature in conda-lock, as it provides an option for locking dependencies per environment specified. It would be great if conda-env-builder could also include this option.
Currently, conda-env-builder does not support platform specifications in the environment.yaml file. This requires developers to manually add platform specifications, which can be a time-consuming process and could potentially lead to errors.
I understand that adding new features can be a complex process, but I wanted to request that this feature be considered for future development. Thank you for your work on this tool.

Are you looking for full support for conda-lock (see #21) or are you looking for a platforms section on the same level as channels and dependencies?

@leeleavitt see #31 . Can you give it a shot?

Hi Nihls,
Just wanted to follow up on my previous message here. It turns out that the feature requires one more change to work properly. My apologies for approving the pull request before thoroughly testing it on my end.
Best regards, Lee

@leeleavitt no worries, can you take a look here: #34?  Note that the Assemble and Solve commands will not actually use platforms (e.g. solve using conda-lock, see #21), but will pass through as-is.

Thanks again for this rapid feature development.


It doesn't work on MacOS BigSur

I was trying to run examples:mac:input it on MacOS BigSur. And nothing happened. It just waited some time and closed with timeout event.

@MaxLevs Can you share how it was resolved, as I am facing the same issue in MacOS BigSur.

@vikasraj789 I didn't resolve it. I've just use another way.

@MaxLevs Thanks for you prompt reply. Can you let me know the alternative you have used?

@MaxLevs Thanks for your prompt reply. Can you let me know the alternative you have used?

I run terminal command via node.js. There is terminal-notifier that can make notifications through terminal. It looks like a trash but still works.

@MaxLevs Thanks

check if you have "do not disturb" on, that was my problem


Rename license.txt

Rename the license.txt to LICENSE to make it other Programms, Applications & Humans easier to know the license. They check for a file called "LICENSE" and not for license.txt. In my issue yarn assign these repo as "UNKNOWN" instead of MIT License.

Fixed

Thanks


ros one for 22.04 in dockerhub

Use debian package from the 0.0.6 release https://github.com/lucasw/ros_from_src/releases/tag/ros2204-v0.0.6
Download the full deb file and extract it in ros_from_src/debian
https://github.com/lucasw/ros_from_src/tree/debianize
Make the lateset here contain the 0.0.6 version:
https://hub.docker.com/r/lucasw0/ros_from_src_ubuntu_2204
cd ros_from_src
docker build debian -t ros_from_src_ubuntu_2204
...
docker tag ros_from_src_ubuntu_2204 lucasw0/ros_from_src_ubuntu_2204:latest
docker push lucasw0/ros_from_src_ubuntu_2204:latest

The push refers to repository [docker.io/lucasw0/ros_from_src_ubuntu_2204]

Once tested push to :latest
And once that is done other dockerfiles can use it like this:
FROM lucasw0/ros_from_src_ubuntu_2204:latest

Having an issue running catkin when using the deb installed in a docker image- rebuild the deb so source /opt/ros/one/setup.bash works and try again.

Now the deb installed in docker isn't producing a ROS_PACKAGE_PATH, can set it manually but commands like rosrun xacro xacro don't work:
root@df3591567419:~# export ROS_PACKAGE_PATH=/opt/ros/one:/usr/share
root@df3591567419:~# rosrun xacro xacro
[rosrun] Couldn't find executable named xacro below /opt/ros/one/share/xacro
[rosrun] Found the following, but they're either not files,
[rosrun] or not executable:
[rosrun]   /opt/ros/one/share/xacro
root@df3591567419:~# rospack find xacro
/opt/ros/one/share/xacro
root@df3591567419:~# xacro
Usage: xacro [options] <input>

xacro: error: expected exactly one input file as argument
root@df3591567419:~# which xacro
/opt/ros/one/bin/xacro

Set it up to use the pre-built install.tgz instead

Next will have a v0.0.7 version with https://github.com/lucasw/ros_from_src/releases/tag/ros2204-v0.0.7-vdb-mapping


[bug] csv_provider Docker image fails to start

With 665440f008c44bfa7363e36cca8ad4969bb7f3a4 the Docker image created for the csv_provider no longer starts up but fails with the following error:
> docker run ghcr.io/eclipse/kuksa.val.feeders/csv-provider:main
Traceback (most recent call last):
  File "provider.py", line 128, in <module>
  File "asyncio/runners.py", line 44, in run
  File "asyncio/base_events.py", line 649, in run_until_complete
  File "provider.py", line 79, in main
  File "kuksa_client/grpc/aio.py", line 55, in __init__
TypeError: BaseVSSClient.__init__() got an unexpected keyword argument 'tls_server_name'
[7] Failed to execute script 'provider' due to unhandled exception!

My understanding is that the BaseVSSClient's init function does not accept arbitrary kwargs at that position in kuksa-client 0.3.x.
The init function's signature seems to have been changed in 0.4.0a3 to support this. However, the pip install command used in the csv_provider's Dockerfile does not match against pre-release versions and therefore picks up the incompatible kuksa-client 0.3.1 instead.
I see two ways forward here:

adjust the Dockerfile's pip install command to include --pre
do not include the tls_server_name argument when constructing the VSSClient

FMPOV option 1 would be more appropriate and also seems to have been anticipated by #93.
I would be happy to provide a PR ...
@erikbosch WDYT?

I think alternative 1 is the best. I have also written down as we as part of release should remove any --pre, see https://github.com/eclipse/kuksa.val.feeders/wiki/Release-Process
But we might have another problem, in requirements.txt we state that version shall be >0.3. Looking at the build log it seems to use a cached version. The intention of >0.3 is that it shall complain/fail if it cannot find any 0.4+ version, but that does not seem to happen. So maybe we need to change the build config as well. I did a quick test at https://github.com/eclipse/kuksa.val.feeders/pull/120 but it is stuck in the queue, will check tomorrow.

I think this one can be closed as #120 is merged


Custom characters for backspace mapping

Hi, only issue I'm having is that I can't use ^H instead of backspace (which is very handy sometimes). However ^M instead of an actual return key works, but not ^J. I believe one way to fix that is to provide a config field for both BS and CR mappings, that will accept keys to interpret as CR or BS
{
  bs={
    lhs={'<BS>', '<C-h>'}
  },
  cr={
    lhs={'<BS>', '<C-j>'}
  }
}

Still a great plugin, thank you

Currently, this configuration option is only supported in the pre-alpha-0.5.0 version.
If you can't wait for the 0.5.0 release then you could:
vim.keymap.set('i','<C-h>',require'ultimate-autopair.maps.bs'.backspace,{expr=true})
vim.keymap.set('i','<C-j>',require'ultimate-autopair.maps.cr'.newline,{expr=true})

@altermo, thank you for the answer, will use that
I guess it isn't very different from :imap <c-h> <bs>, which i was using


Fixed extents on bokeh HistogramPlot

The extents of the Histogram were not correctly computed previously showing just the region between the min and max bin value. Histograms bins should instead reach down (or up) to zero.

Looks good. Merging.


chore: major bump of oclif/core

Proposed changes
Migrating to @oclif/core@V2
Breaking changes
No!
Testing

[ ] Unit Tests:

[ ] Functionnal Tests:

[ ] Manual Tests:

🍿


Unknown custom element

Unknown custom element:  - did you register the component correctly? For recursive components, make sure to provide the "name" option.
i use exactly this example :
https://www.fusioncharts.com/charts/gauges/gauge-with-trend?framework=vue

@PouriaSeyfi Did you find any solution ?

@hafiztahajamil
I think resolved it this way :
`import VueFusionCharts from 'vue-fusioncharts';
import FusionCharts from 'fusioncharts';
import Widgets from 'fusioncharts/fusioncharts.widgets';
import Charts from 'fusioncharts/fusioncharts.charts';
import Theme from 'fusioncharts/themes/fusioncharts.theme.fusion';`
and
   Vue.use(VueFusionCharts, FusionCharts, Charts,Widgets,Theme);

Bonjour,
J'ai la même erreur, y a t'il une solution?

Hey I couldn't resolve the same issue with your way. Any updates..?

Hey I couldn't resolve the same issue with your way. Any updates..?

The same problem

I have the same problem , i resolved , registering globally the chart in this form:
import VueFusionCharts from 'vue-fusioncharts';
import FusionCharts from 'fusioncharts';
import Column2D from 'fusioncharts/fusioncharts.charts';
import TimeSeries from 'fusioncharts/fusioncharts.timeseries';
import FusionTheme from 'fusioncharts/themes/fusioncharts.theme.fusion';
Vue.use(VueFusionCharts, FusionCharts, Column2D, TimeSeries ,FusionTheme);
i didn´t register in my local component, the  FusionCharts component have all the necessary

I'm also facing the same issue. Any fix in 2022?


Add Clusterfuzzlite integration

This adds fuzzing by way of ClusterFuzzLite, which is a GitHub action that will perform a short amount of fuzzing for new PRs. The goal is to use fuzzing to catch bugs that may be introduced by new PRs.
If you'd like to test this the way ClusterFuzzLite runs it (by way of OSS-Fuzz) you can use the steps:
git clone https://github.com/google/oss-fuzz
git clone https://github.com/DavidKorczynski/iniparser
cd iniparser
git checkout cflite

# Build the fuzzers in .clusterfuzzlite
python3 ../oss-fuzz/infra/helper.py build_fuzzers --external $PWD

# Run the fuzzer for 10 seconds
python3 ../oss-fuzz/infra/helper.py run_fuzzer --external $PWD fuzzer -- -max_total_time=10

Hi @DavidKorczynski
Thanks for your contribution!
I tested ClusterFuzzLite as suggested. The end of the output is
###### Recommended dictionary. ######
"\000\000" # Uses: 881
"c=" # Uses: 767
"\"\"" # Uses: 731
"\001\000" # Uses: 708
"h\"" # Uses: 723
"''" # Uses: 694
"\000\000\000\000\000\000\000\021" # Uses: 444
"\377\377\377\377\377\377\377\377" # Uses: 399
"\376\377\377\377\377\377\377\377" # Uses: 426
"\001\000\000\000\000\000\000\000" # Uses: 225
"\022\000\000\000\000\000\000\000" # Uses: 201
"\001\000\000\000" # Uses: 97
"\377\001" # Uses: 87
"\200\034\272\324" # Uses: 42
###### End of recommended dictionary. ######
Done 71810 runs in 11 second(s)

What does it mean?
We moved to Gitlab. Here is the copy of this PR.  So I will close this PR here and suggest continuing on Gitlab. Unfortunately Gitlab was not able to assign your Github account to any Gitlab account.
Do you like to refactor your PR on Gtilab to integrate it into our Gitlab CI?


Controller Manager not available

Hi,
I am currently running hardware.launch from the humble branch to bring up a real robot. I made sure to setup the robot's client as described in the doc. However, there seems to be a problem between the lbr_system_interface and ros2_control because even though the controller_manger node appears in the ros2 node list, the controller_manager is not available for the joint_state_broadcaster and the joint_trajectroy_controller to spawn properly.
See the below log.
~/lbr_ws$ ros2 launch lbr_bringup hardware.launch.py  model:=med14
[INFO] [launch]: All log files can be found below /home/jetsonadmin/.ros/log/2024-09-20-12-16-23-899873-jetsonadmin-desktop-87821
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [robot_state_publisher-1]: process started with pid [87830]
[INFO] [ros2_control_node-2]: process started with pid [87833]
[INFO] [spawner-3]: process started with pid [87837]
[INFO] [spawner-4]: process started with pid [87839]
[ros2_control_node-2] [INFO] [1726798584.504025510] [controller_manager]: Subscribing to '~/robot_description' topic for robot description file.
[ros2_control_node-2] [INFO] [1726798584.508064372] [controller_manager]: update rate is 1000 Hz
[ros2_control_node-2] [INFO] [1726798584.509668172] [controller_manager]: Successful set up FIFO RT scheduling policy with priority 50.
[robot_state_publisher-1] [INFO] [1726798584.558961863] [robot_state_publisher]: got segment link_0
[robot_state_publisher-1] [INFO] [1726798584.559213734] [robot_state_publisher]: got segment link_1
[robot_state_publisher-1] [INFO] [1726798584.559235653] [robot_state_publisher]: got segment link_2
[robot_state_publisher-1] [INFO] [1726798584.559246181] [robot_state_publisher]: got segment link_3
[robot_state_publisher-1] [INFO] [1726798584.559255109] [robot_state_publisher]: got segment link_4
[robot_state_publisher-1] [INFO] [1726798584.559262949] [robot_state_publisher]: got segment link_5
[robot_state_publisher-1] [INFO] [1726798584.559270181] [robot_state_publisher]: got segment link_6
[robot_state_publisher-1] [INFO] [1726798584.559277349] [robot_state_publisher]: got segment link_7
[robot_state_publisher-1] [INFO] [1726798584.559284293] [robot_state_publisher]: got segment link_ee
[robot_state_publisher-1] [INFO] [1726798584.559291301] [robot_state_publisher]: got segment mount
[robot_state_publisher-1] [INFO] [1726798584.559298245] [robot_state_publisher]: got segment world
[robot_state_publisher-1] [INFO] [1726798584.559305029] [robot_state_publisher]: got segment zedm_camera_center
[robot_state_publisher-1] [INFO] [1726798584.559312485] [robot_state_publisher]: got segment zedm_camera_link
[robot_state_publisher-1] [INFO] [1726798584.559319205] [robot_state_publisher]: got segment zedm_left_camera_frame
[robot_state_publisher-1] [INFO] [1726798584.559326245] [robot_state_publisher]: got segment zedm_left_camera_optical_frame
[robot_state_publisher-1] [INFO] [1726798584.559333509] [robot_state_publisher]: got segment zedm_right_camera_frame
[robot_state_publisher-1] [INFO] [1726798584.559340517] [robot_state_publisher]: got segment zedm_right_camera_optical_frame
[ros2_control_node-2] [INFO] [1726798584.642479074] [controller_manager]: Received robot description file.
[ros2_control_node-2] [INFO] [1726798584.643544605] [resource_manager]: Loading hardware 'lbr_system_interface'
[ros2_control_node-2] [INFO] [1726798584.650571708] [resource_manager]: Initialize hardware 'lbr_system_interface'
[ros2_control_node-2] [INFO] [1726798584.650825947] [lbr_fri_ros2::AsyncClient]: Configuring client
[ros2_control_node-2] [INFO] [1726798584.650861051] [lbr_fri_ros2::AsyncClient]: Client command mode: 'POSITION'
[ros2_control_node-2] [INFO] [1726798584.650868923] [lbr_fri_ros2::AsyncClient]: Command guard variant 'default'
[ros2_control_node-2] [INFO] [1726798584.650943707] [lbr_fri_ros2::CommandGuard]: *** Parameters:
[ros2_control_node-2] [INFO] [1726798584.650955995] [lbr_fri_ros2::CommandGuard]: *   Joint A1 limits: Position: [-170.0, 170.0] deg, velocity: 85.0 deg/s, torque: 200.0 Nm
[ros2_control_node-2] [INFO] [1726798584.650970651] [lbr_fri_ros2::CommandGuard]: *   Joint A2 limits: Position: [-120.0, 120.0] deg, velocity: 85.0 deg/s, torque: 200.0 Nm
[ros2_control_node-2] [INFO] [1726798584.650978587] [lbr_fri_ros2::CommandGuard]: *   Joint A3 limits: Position: [-170.0, 170.0] deg, velocity: 100.0 deg/s, torque: 200.0 Nm
[ros2_control_node-2] [INFO] [1726798584.650985435] [lbr_fri_ros2::CommandGuard]: *   Joint A4 limits: Position: [-120.0, 120.0] deg, velocity: 75.0 deg/s, torque: 200.0 Nm
[ros2_control_node-2] [INFO] [1726798584.650992315] [lbr_fri_ros2::CommandGuard]: *   Joint A5 limits: Position: [-170.0, 170.0] deg, velocity: 130.0 deg/s, torque: 200.0 Nm
[ros2_control_node-2] [INFO] [1726798584.650999034] [lbr_fri_ros2::CommandGuard]: *   Joint A6 limits: Position: [-120.0, 120.0] deg, velocity: 135.0 deg/s, torque: 200.0 Nm
[ros2_control_node-2] [INFO] [1726798584.651006330] [lbr_fri_ros2::CommandGuard]: *   Joint A7 limits: Position: [-175.0, 175.0] deg, velocity: 135.0 deg/s, torque: 200.0 Nm
[ros2_control_node-2] [INFO] [1726798584.651017626] [lbr_fri_ros2::JointPIDArray]: *** Parameters:
[ros2_control_node-2] [INFO] [1726798584.651023002] [lbr_fri_ros2::JointPIDArray]: *   p: 0.1
[ros2_control_node-2] [INFO] [1726798584.651029658] [lbr_fri_ros2::JointPIDArray]: *   i: 0.0
[ros2_control_node-2] [INFO] [1726798584.651034778] [lbr_fri_ros2::JointPIDArray]: *   d: 0.0
[ros2_control_node-2] [INFO] [1726798584.651039706] [lbr_fri_ros2::JointPIDArray]: *   i_max: 0.0
[ros2_control_node-2] [INFO] [1726798584.651044538] [lbr_fri_ros2::JointPIDArray]: *   i_min: 0.0
[ros2_control_node-2] [INFO] [1726798584.651049210] [lbr_fri_ros2::JointPIDArray]: *   antiwindup: false
[ros2_control_node-2] [INFO] [1726798584.651082778] [lbr_fri_ros2::StateInterface]: *** Parameters:
[ros2_control_node-2] [INFO] [1726798584.651088794] [lbr_fri_ros2::StateInterface]: *   external_torque_cutoff_frequency: 10.0 Hz
[ros2_control_node-2] [INFO] [1726798584.651095162] [lbr_fri_ros2::StateInterface]: *   measured_torque_cutoff_frequency: 10.0 Hz
[ros2_control_node-2] [INFO] [1726798584.651102970] [lbr_fri_ros2::AsyncClient]: Open loop 'true'
[ros2_control_node-2] [INFO] [1726798584.651109370] [lbr_fri_ros2::AsyncClient]: Client configured
[ros2_control_node-2] [INFO] [1726798584.716336906] [resource_manager]: Successful initialization of hardware 'lbr_system_interface'
[ros2_control_node-2] [INFO] [1726798584.716718057] [resource_manager]: 'configure' hardware 'lbr_system_interface'
[ros2_control_node-2] [INFO] [1726798584.716748489] [resource_manager]: Successful 'configure' of hardware 'lbr_system_interface'
[ros2_control_node-2] [INFO] [1726798584.716777960] [resource_manager]: 'activate' hardware 'lbr_system_interface'
[ros2_control_node-2] [INFO] [1726798584.716819880] [lbr_fri_ros2::App]: Opening UDP socket with port_id '30200'
[ros2_control_node-2] [INFO] [1726798584.716903336] [lbr_fri_ros2::App]: Socket opened successfully
[ros2_control_node-2] [INFO] [1726798584.717133991] [lbr_ros2_control::SystemInterface]: Awaiting robot heartbeat. Attempt 1, remote_host 'INADDR_ANY', port_id '30200'
[ros2_control_node-2] [INFO] [1726798584.717278790] [lbr_fri_ros2::App]: Realtime kernel recommended but not required
[ros2_control_node-2] [INFO] [1726798584.717298182] [lbr_fri_ros2::App]: Starting run thread
[ros2_control_node-2] [INFO] [1726798584.727023673] [lbr_fri_ros2::AsyncClient]: LBR switched from 'IDLE' to 'MONITORING_WAIT'
[spawner-4] [INFO] [1726798585.048554112] [spawner_joint_trajectory_controller]: waiting for service /controller_manager/list_controllers to become available...
[spawner-3] [INFO] [1726798585.089320290] [spawner_joint_state_broadcaster]: waiting for service /controller_manager/list_controllers to become available...
[ros2_control_node-2] [INFO] [1726798585.717280690] [lbr_ros2_control::SystemInterface]: Robot connected
[ros2_control_node-2] [INFO] [1726798585.717529425] [lbr_ros2_control::SystemInterface]: Control mode 'POSITION_CONTROL_MODE'
[ros2_control_node-2] [INFO] [1726798585.717558193] [lbr_ros2_control::SystemInterface]: Sample time 0.010 s / 100.0 Hz
[ros2_control_node-2] [INFO] [1726798585.717588721] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_WAIT'.
[ros2_control_node-2] [INFO] [1726798586.204893007] [lbr_fri_ros2::AsyncClient]: LBR switched from 'MONITORING_WAIT' to 'MONITORING_READY'
[ros2_control_node-2] [INFO] [1726798586.717735539] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798587.717958571] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798588.718200345] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798589.718420318] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798590.718752729] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798591.719026635] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798592.719331187] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798593.719607826] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798594.719830536] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[spawner-4] [WARN] [1726798595.070440935] [spawner_joint_trajectory_controller]: Could not contact service /controller_manager/list_controllers
[spawner-4] [INFO] [1726798595.071335331] [spawner_joint_trajectory_controller]: waiting for service /controller_manager/list_controllers to become available...
[spawner-3] [WARN] [1726798595.115693392] [spawner_joint_state_broadcaster]: Could not contact service /controller_manager/list_controllers
[spawner-3] [INFO] [1726798595.117622503] [spawner_joint_state_broadcaster]: waiting for service /controller_manager/list_controllers to become available...
[ros2_control_node-2] [INFO] [1726798595.720059253] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798596.720285752] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798597.720502706] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798598.720820258] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798599.721044617] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798600.721315207] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798601.721577244] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798602.721798055] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798603.722029994] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[ros2_control_node-2] [INFO] [1726798604.722381730] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.
[spawner-4] [WARN] [1726798605.094114042] [spawner_joint_trajectory_controller]: Could not contact service /controller_manager/list_controllers
[spawner-4] [INFO] [1726798605.095798514] [spawner_joint_trajectory_controller]: waiting for service /controller_manager/list_controllers to become available...
[spawner-3] [WARN] [1726798605.139529150] [spawner_joint_state_broadcaster]: Could not contact service /controller_manager/list_controllers
[spawner-3] [INFO] [1726798605.140469689] [spawner_joint_state_broadcaster]: waiting for service /controller_manager/list_controllers to become available...
[ros2_control_node-2] [INFO] [1726798605.722598962] [lbr_ros2_control::SystemInterface]: Awaiting 'COMMANDING_WAIT' state. Current state 'MONITORING_READY'.

hi @jclinton830. So the connection is established well. The driver awaits COMMANDING_WAIT state.
To achieve this, simply press the green play button whilst holding one of the gray enabling switches on the KUKA smartPAD.
In automatic mode, the robot will connect immediately.

hi @jclinton830. So the connection is established well. The driver awaits COMMANDING_WAIT state.
To achieve this, simply press the green play button whilst holding one of the gray enabling switches on the KUKA smartPAD.
In automatic mode, the robot will connect immediately.

Hi @mhubii I am running the robot in automatic mode.
My question is not about the awaiting 'COMMANDING WAIT'
I want to know why the controller manager is not available for the joint state broadcaster and the joint trajectory controller to spawn?

the controller manager is stuck loading the lbr_ros2_control::SystemInterface since the robot never enters COMMANDING_WAIT state. This likely happens because the robot is in test mode T1

Thanks for the explanation. I can confirm this is now working.


bug(windows): Not working in Windows Server VM

Describe the bug
f2f8464f0 isn't running in my VM. Even 9b7c5d4ebd44 from Jan 11th doesn't work. I last ran a test in the VM on Jan 12th, so that should have worked.
f2f8464f0  starts, prints the GIT_VERSION log, doesn't elevate, then exits. It does show the systray icon, so maybe it's already elevated? It does unpack wintun.dll, too.
To Reproduce
https://github.com/firezone/firezone/blob/d999c4b8b1f9c72d988649ae22eb4a96fed05aef/rust/windows-client/docs/vm_testing.md
Expected behavior
Expected the exe to run on a clean Windows system even if it's not installed by the MSI.
Screenshots / Logs
Getting this from a debug build of f2f8464f027d. Even 9b7c5d4ebd (Jan 11) shows it, too.

Platform (please complete the following information):

Firezone Version f2f8464f0
OS: Windows Server 2022
Deployment method: pnpm build

Additional context
N/A

VCRUNTIME might not be a problem - Looks like Tauri does some magic in release mode to bundle it? https://github.com/tauri-apps/tauri/issues/4565
There might also be something in the MSI that handles this, hard to tell

I think there's a 2nd problem here. If it was only vcruntime, the process should completely fail to start and not enter our main. But if we're printing GIT_VERSION and then the logs stop, we're in our main. I'll keep looking.

Build a debug exe with static VC runtime that will run but still has some secondary issue on the VM:
STATIC_VCRUNTIME=true cargo build -p firezone-windows-client --features=custom-protocol

Oh there's the Occam's Razor explanation - Webview2 isn't installed. How was it working before? 🤔 Is this a different build of Windows Server?

native_dialog works but you can't copy-paste a URL from it, Windows dialog boxes don't allow selection by default. (Or maybe you can copy-paste. But if users don't think you can, they won't try.)


Didn't triger onScrollChanged when put this widget into a fragment

I am using pulltonextlayout and this widget in project, and when I put it into a fragment, the scrolling will not triger onScrollChanged function, it's making me confused. btw,this is an awesome widget, I really like it. Thanks.

Is that this library?
I checked the sample app in this library, replaced ScrollView to ObservableScrollView in ScrollViewModel class, and it seems working.
ScrollViewModel.java:
public class ScrollViewModel extends PullToNextModel
    implements ObservableScrollViewCallbacks { // ADDED
    ...
    private ObservableScrollView scrollView; // CHANGED
    ...
    public void onBindView(int position, View v, PullToNextView pullToNextView) {
        ...
        scrollView = (ObservableScrollView) v.findViewById(R.id.scrollView); // CHANGED
        scrollView.setScrollViewCallbacks(this); // ADDED
        ...
    }
    ...
    // ADDED FOLLOWING CALLBACKS
    @Override
    public void onScrollChanged(int i, boolean b, boolean b1) {
        Log.e(TAG, "AOSV: onScrollChanged");
    }

    @Override
    public void onDownMotionEvent() {
        Log.e(TAG, "AOSV: onDownMotionEvent");
    }

    @Override
    public void onUpOrCancelMotionEvent(ScrollState scrollState) {
        Log.e(TAG, "AOSV: onUpOrCancelMotionEvent");
    }
}

fragment_scrollview.xml:
<!-- Just changed ScrollView to ObservableScrollView -->
<com.github.ksoichiro.android.observablescrollview.ObservableScrollView
  xmlns:android="http://schemas.android.com/apk/res/android"
...
</com.github.ksoichiro.android.observablescrollview.ObservableScrollView>

And I can get these logs:
06-11 00:03:42.504  19468-19468/? E/ScrollViewModel﹕ AOSV: onDownMotionEvent
06-11 00:03:42.555  19468-19468/? E/ScrollViewModel﹕ AOSV: onScrollChanged
06-11 00:03:42.572  19468-19468/? E/ScrollViewModel﹕ AOSV: onScrollChanged
06-11 00:03:42.589  19468-19468/? E/ScrollViewModel﹕ AOSV: onScrollChanged
06-11 00:03:42.606  19468-19468/? E/ScrollViewModel﹕ AOSV: onScrollChanged
06-11 00:03:42.621  19468-19468/? E/ScrollViewModel﹕ AOSV: onScrollChanged
06-11 00:03:42.623  19468-19468/? E/ScrollViewModel﹕ AOSV: onUpOrCancelMotionEvent

Thank you for help, I fix my code and it works :D, It's just I used this in pulltonextlayout and I didn't put the model in the right place:p

Great :) Closing issue.


[BUG] - creating the first commit on a branch other than master fails

Describe the bug
cocogitto_bot_playground on  main
❯ coco chore "First commit"
Error: reference 'refs/heads/main' not found; class=Reference (4); code=UnbornBranch (-9)

The issue seems to be in libgit2 https://github.com/libgit2/libgit2/issues/6049 where the is_empty function only returns true if the branch is called "master". This causes the issue in this line where is_empty is set to false for empty repositories with a "main" branch instead of "master".
The fix is pretty simple, just need to try and get the head, if we can't get the head the repo is empty, otherwise, it is not.
 src/git/commit.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/git/commit.rs b/src/git/commit.rs
--- a/src/git/commit.rs
+++ b/src/git/commit.rs
@@ -8,7 +8,7 @@ impl Repository {
         let sig = self.0.signature()?;
         let tree_id = self.0.index()?.write_tree()?;
         let tree = self.0.find_tree(tree_id)?;
-        let is_empty = self.0.is_empty()?;
+        let is_empty = self.0.head().is_err();
         let has_delta = self.get_diff(false).is_some();

         if !is_empty && has_delta {

I'd be happy to submit a pull request for this as well if you prefer.

@Zshoham thanks for investigating this.
You are more than welcome to submit a PR.


Improve date

I added new date functions and manipulations. Inspirited by dart_date (but fixed week issues).

I fixed week test


Remove support for Selenium 2 and older versions of Firefox

Selenium WebDriver 3 has been out for a long time and newer versions of Firefox only work with this newer version of WebDriver. We should remove support for the Selenium 2+old Firefox combination from the tests.

As a reminder: the changes should include removing conditions like c.seleniumVersion.Major == 2 and similar.

Note to self: If version 47 of Firefox runs after a newer version of Firefox and uses the same profile (which isn't great to begin with), the v47 instance will disable the WebDriver extension because of some version checks in the existing preferences. However, Selenium 2 and Firefox 47 don't allow preferences to be set via capabilities, so this non-hermeticity means that test will fail.
The only solution AFAIK is to delete the Firefox profiles and re-run the tests.


Added document for how to run kuebflow on IBM Cloud Private

IBM Cloud Private is an Enterprise Kubernetes distribution, we will try to add a getting started guide for this.

/cc @jinchihe

Thanks @gyliu513 - I've added this issue as a candidate for our upcoming doc sprint, in case you can't complete it before then. Maybe you can join us in the sprint. :)

/assign @jinchihe

Thanks @sarahmaddox , @jinchihe will start work for this.

Will draft that after Labor holidays. Thanksl

FYI @khahmed


Give Matteo Bachetti correct permissions as astropy core maintainer

Description
@matteobachetti is listed as a core maintainer for astropy.io.misc on the astropy team page, and has requested to be added to the CODEOWNERS file being introduced by astropy/astropy#13241. However, GitHub is detecting an error which appears to be related to his permissions: https://github.com/astropy/astropy/pull/13241/files.
Could someone make sure @matteobachetti has the correct core-maintainer privileges for astropy?

@matteobachetti should have write permission and it seems we've overlooked this before - so, I'm glad we are doing this and find these inconsistencies.
@matteobachetti : You should have gotten an email from github to join the astropy organization. I can't give you write permissions until you accept that. Once you do, this problem should be solved.

Thanks @hamogu!

So, is this resolved? Thanks, all!

astropy/astropy#13241 now shows no errors. So it looks all fixed


github-merge-queue bot needs to be added to allow merge queues to be used

Because merge queues wait for status from all required checks, any use of merge queues in a repro configured with the CLA bot will timeout waiting for the github-merge-queue bot to sign the CLA. For this feature to work as expected, the bot needs to be added to the approved list.

As the comment on the linked PR explains, the real fix is being tracked by https://github.com/microsoft/ContributorLicenseAgreement/issues/107.


NeuronX compiler: specify data type

Description
Currently, the options for Transformers-NeuronX Engine in LMI don't include the possibility to specify the data type for compilation. It would be nice to have this parameter added to the set.
Will this change the current api? How?
Yes, a new parameter needs to be added and propagated to the neuron compiler
Who will benefit from this enhancement?
Everyone
References

list reference and related literature
list known implementations

Thanks @CoolFish88 - Dtype as a parameter is available for Neuron model compilation and runtime in the form of option.dtype=bf16 in a serving.properties or OPTION_DTYPE=bf16. It does appear that the documentation is not clear on this fact, as it skips over common option and only outlines advanced options. I will make an update to the documentation in this regard.  In the near term you can see the options that are available to you here https://github.com/deepjavalibrary/djl-serving/blob/master/engines/python/setup/djl_python/properties_manager/tnx_properties.py#L32-L35. This list will expand as the Neuron frameworks support.


Bearer auth for oai compatibility

Pull Request Summary
What is this PR changing? Why is this change being made? Any caveats you'd like to highlight? Link any relevant documents, links, or screenshots here if applicable.
Support bearer token auth. This allows openai client to be used against llmengine with no additional headers
Test Plan and Usage Guide
How did you validate that your PR works correctly? How do you run or demo the code? Provide enough detail so a reviewer can reasonably reproduce the testing procedure. Paste example command line invocations if applicable.

can you add a ticket to this PR?


Civil 3D alignment Arcs not rendered correctly in 3D Web Viewer

What package are you referring to?
frontend (I suppose)
Describe the bug
Arcs of Civil 3D alignments sent to speckle server are rendered as lines in the 3D web viewer.
Receiving data (into a new Civil 3D document, in my case) correctly reconstructs the alignment.
To Reproduce
Steps to reproduce the behavior:

Create an alignment with some arc curves in Civil 3D
Send the alignment to a Speckle repository
View the repository in the web interface: curves are shown as lines
(4. On a new document, receive the repository data: curves are correctly built)

Expected behavior
Arcs should be correctly rendered in the 3D viewer.
Screenshots
(disregard the warning signs in the received alignment, it could be due to the the original alignment having many short segments in place of clothoids).

System Info
Desktop (please complete the following information):

OS: Windows 10
Browser: Chrome
Version: 98.0.4758.102

Additional context
I'm part of the R&D/SW development team in a civil engineering firm, and I'm investigating your great work for potential integrations in our workflows.
I didn't have the time (yet) to properly analyze the source code for this (cosmetic) issue, but I suspect it's related to how the stored geometry is interpreted by the viewer geometry converters.

[moved to speckle-sharp]

Thanks @clairekuang !
It is indeed a low priority issue, but I thought it was worth mention it (you can see that for very long arcs this simplification is too harsh!)
For the clothoids: what I was trying to say is that the original (leftmost) model doesn't have clothoids, but they already are many short segments (the alignment was converted from a dwg polyline by a lazy person - me!), so the warnings appearing in the rightmost image are somewhat expected :wink:
I'll try another model with proper clothoids, but I'm sure you've done a great job!
Thanks again

Closing for now as stale.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


maint: Upload to PyPI as trusted publisher

Closes #64

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 59.70%. Comparing base (c49487e) to head (af38cc1).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #82   +/-   ##
=======================================
  Coverage   59.70%   59.70%
=======================================
  Files          21       21
  Lines         675      675
=======================================
  Hits          403      403
  Misses        272      272

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


No res.body received from GET

I am testing a Node.js API with supertest, and the res.body object superset returns is empty. The data shows up in the res.text object, but not res.body. This appears to be a bug, as the exact same code works in a similar project.
I am using Express and body-parser:
app.use(bodyParser.json());
app.use(bodyParser.json({ type: jsonMimeType }));
app.use(bodyParser.urlencoded({ extended: true }));

Here is the API method I am testing:
app.get(apiPath + '/menu', function(req, res) {
  var expiration = getExpiration();

  res.set({
    'Content-Type': jsonMimeType,
    'Content-Length': jsonTestData.length,
    'Last-Modified': new Date(),
    'Expires': expiration,
    'ETag': null
  });

  res.json({ items: jsonTestData });
}

Here are the tests I am executing against this API method:
describe('GET /menu', function() {
  describe('HTTP headers', function() {
    it('responds with the right MIME type', function(done) {
      request(app)
        .get(apiPath + '/menu')
        .set('Accept', 'application/vnd.burgers.api+json')
        .expect('Content-Type', 'application/vnd.burgers.api+json; charset=utf-8')
        .expect(200, done);
    });

    it('responds with the right expiration date', function(done) {
      var tomorrow = new Date();
      tomorrow.setDate(tomorrow.getDate() + 1);
      tomorrow.setHours(0,0,0,0);

      request(app)
        .get(apiPath + '/menu')
        .set('Accept', 'application/vnd.burgers.api+json; charset=utf-8')
        .expect('Expires', tomorrow.toUTCString())
        .expect(200, done);
    });

    it('responds with menu items', function(done) {
      request(app)
        .get(apiPath + '/menu')
        .set('Accept', 'application/vnd.burgers.api+json; charset=utf-8')
        .expect(200)
        .expect(function (res) {
          console.log(res);
          res.body.items.length.should.be.above(0);
        })
        .end(done);
    });
  });
});

The failure I receive:
1) GET /menu HTTP headers responds with menu items:
     TypeError: Cannot read property 'length' of undefined
      at /Users/brian/Development/demos/burgers/menu/test/MenuApiTest.js:42:25
      at Test.assert (/Users/brian/Development/demos/burgers/menu/node_modules/supertest/lib/test.js:213:13)
      at Server.assert (/Users/brian/Development/demos/burgers/menu/node_modules/supertest/lib/test.js:132:12)
      at Server.g (events.js:180:16)
      at Server.emit (events.js:92:17)
      at net.js:1276:10
      at process._tickDomainCallback (node.js:463:13)

And finally, here is an excerpt of the result of console.log(res):
...
text: '{"items":[{"id":"1","name":"cheeseburger","price":3},{"id":"2","name":"hamburger","price":2.5},{"id":"3","name":"veggie burger","price":3},{"id":"4","name":"large fries","price":2},{"id":"5","name":"medium fries","price":1.5},{"id":"6","name":"small fries","price":1},{"id":"7","name":"large drink","price":2.5},{"id":"8","name":"medium drink","price":2},{"id":"9","name":"small drink","price":1}]}',
  body: {},
...

Did you ever solve this?

@mikker The issue seems to have been resolved on a question on StackOverflow.
I have the same problem, and my Express application actually does return application/json; charset=utf-8 and yet the result doesn't have a body property -- only the text property. Strange.

This isn't really an issue with supertest, it's a known issue with the chaining system of shouldjs and described in the documentation:
"Almost all assertions return the same object - so you can easy chain them. But some (eg: .length and .property) move the assertion object to a property value, so be careful."
https://github.com/shouldjs/should.js#chaining-assertions
It happens also when you use foo.bar.should.be.an.Array.and.blah
but if you use foo.bar.should.be.an.instanceOf(Array).and.blah it loves it (i mean it  works..)

same problem here

Same here, using hapi.js with default settings

"content-type": "application/json; charset=utf-8"

Yes, this was resolved in the question mentioned above at Stack Overflow.

Hi,
I had the same issue because routes was used before bodyParser, set routes after bodyParser solves the problem.

Did you ever solve this?

I faced the same issue using Mocha on node js with Express. I used the expect function to run the test like this
import chai, { expect } from "chai";
//omited code
expect(res.body.data.length).to.eql(0)
//call done()


Added the RGB Color Game...!

Hi @KasunHewagama , You need to add your project details in the main README.md File
You can follow this Example: example-readme-details


Owers with derefType Pointers should be classified as Pointers?

std::vector<int> is an owner of int
std::vector<int*> is an owner of int* not, but according to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2816r0.pdf , it should be viewed as pointers

ColumnFamilyData* DBImpl::PickCompactionFromQueue(
    std::unique_ptr<TaskLimiterToken>* token, LogBuffer* log_buffer) {
  assert(!compaction_queue_.empty());
  assert(*token == nullptr);
  autovector<ColumnFamilyData*> throttled_candidates;
  ColumnFamilyData* cfd = nullptr;
  while (!compaction_queue_.empty()) {
    // pset(compaction_queue_) = {*this}
    // pset(compaction_queue_.begin()) = {*this}
    // pset(*compaction_queue_.begin()) = {**this}
    auto first_cfd = *compaction_queue_.begin();
    compaction_queue_.pop_front();
    assert(first_cfd->queued_for_compaction());

    // RequestCompactionToken is a non-const member function so `first_cfd` is invalidated
    if (!RequestCompactionToken(first_cfd, false, token, log_buffer)) {
      // pset(first_cfd) = {invalid}
      throttled_candidates.push_back(first_cfd);
      continue;
    }
    cfd = first_cfd;
    cfd->set_queued_for_compaction(false);
    break;
  }
  // Add throttled compaction candidates back to queue in the original order.
  for (auto iter = throttled_candidates.rbegin();
       iter != throttled_candidates.rend(); ++iter) {
    compaction_queue_.push_front(*iter);
  }
  return cfd;
}


Updating issue templates.

Describe the chore
An option of yes or no should be provided in the issue templates.

Would you like to work on the issue?
YES.

no priority at the moment.


5.2.x is missing @angular/cdk/testing

Bug, feature request, or proposal:
Bug
What is the expected behavior?
import { dispatchTouchEvent } from '@angular/cdk/testing';

What is the current behavior?
https://github.com/angular/material2/tree/5.2.x/src/cdk/testing
What are the steps to reproduce?
see above
Is there anything else we should know?
I think the BUILD.bazel is missing. Would you release a bugfix 5.2.x version? I'll send you a PR!

cdk/testing isn't part of our public API, see https://github.com/angular/material2/issues/9531#issuecomment-359969115.