Can Zappa work as a Blue/Green Deploy?

Context
I'm currently writing a build server(with python-lamda) to deploy code with Zappa.  An issue I'm running into is that zappa update takes a while to upload the code to s3 and then setting up Lambda.  This causes an issue when doing migrations.  Typically folks want the migrations to run immediately before the new code is live and as quickly as possible to reduce code schema/db schema.
I've considered running a new deploy on each release running zappa manage migrate on the new instance and as the same time update the route53 alias, which should be near instant.  Which would work but seems in excess given the ability to easily rollback lambda functions and would get in the way of using AWS environment variables well.
Would it be possible to split up the update step? One that does the slow upload step and any others possible before hand say(upload) and and then one relase? Or add an option to update like --hold-back which would do the same but would then require rolling forward?
This would allow users to update the code run migrations from the build server on the database and then release the new version(or vice versa to taste).

I've encountered this before actually, I think this is a really good ticket, worth considering.
The shortest path seems to be supplanting zappa update with zappa upload and zappa register, or  something like zappa update --upload-only and zappa update --s3 s3://blahblah.zip. I think maybe the latter. Does that work for your purpose?

Related:
https://github.com/Miserlou/Zappa/issues/62
https://github.com/Miserlou/Zappa/issues/864

@mialinx thanks for the quick response.  either would work great for me.  zappa upload and register make the most sense to me but either is ok.
would these allow for the uploaded version to be run?  it would be good to be able to do say zappa manage  --version version after the upload but before register.  I'm happy with any movement in this direction
Looking at how rollback works, using -n has how many versions to go back. Maybe it would be good to add or change these 2 or 3 commands ultimately and use aliases so that multiple versions of the same code can be swapped out of the same gateway.
zappa upload or zappa update --hold-back
pushes up the newest version and is the $LATEST alias lambda function
zappa versions
lists versions
zappa register -v VERSION
updates $CURRENT alias  -v if it exists or to whatever currently is the $LATEST.  This is partially redundant with rollback but can go forward and backward to a known version number but it would make sense to replace rollbacks implementation with a special version of this.
zappa update
pushes up the newest version and updates the $CURRENT alias lambda function to it(basically just

Is this issue no longer valid?

Currently if you run a zappa update env which includes a new Django migration any calls to the lambda will fail until the migration is executed via zappa run manage env migrate.
Maybe I am missing something but this seems required for zero downtime updates. How do others migrate their Django apps to mitigate this issue?


ISPN-12528 CLI backup create doesn't reflect directory provided

https://issues.redhat.com/browse/ISPN-12528

Integrated into master, thanks @ryanemerson !


Settings Backwards Compatibility

Issue #, if available:
Description of changes:
Cluster setting is updated to legacy setting because there is clusterService.clusterSettings.addSettingsUpdateConsumer
As DB mentioned here, this consumer can update the setting to legacy setting when OpenSearch node joins the cluster
But for index setting, there is no such consumer. So we will need read from 2 places (_plugins first, if not exist, read _opendistro one); and only write to _opendistro. This will not break customer's existing use case.
CheckList:
[ ] Commits are signed per the DCO using --signoff
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #16 (18ffcf6) into main (eee3191) will increase coverage by 0.73%.
The diff coverage is 97.17%.

@@             Coverage Diff              @@
##               main      #16      +/-   ##
============================================
+ Coverage     76.84%   77.57%   +0.72%
- Complexity     1559     1560       +1
============================================
  Files           199      201       +2
  Lines          8395     8588     +193
  Branches       1323     1326       +3
============================================
+ Hits           6451     6662     +211
+ Misses         1246     1224      -22
- Partials        698      702       +4

Impacted Files
Coverage Δ
Complexity Δ

...arch/indexmanagement/rollup/RollupMapperService.kt
58.87% <0.00%> (-0.39%)
23.00 <0.00> (-1.00)

...temanagement/opensearchapi/OpenSearchExtensions.kt
80.95% <50.00%> (-0.53%)
0.00 <0.00> (ø)

...nsearch/indexmanagement/rollup/util/RollupUtils.kt
80.08% <60.00%> (+0.82%)
0.00 <0.00> (ø)

.../rollup/settings/LegacyOpenDistroRollupSettings.kt
97.95% <97.95%> (ø)
1.00 <1.00> (?)

...t/settings/LegacyOpenDistroManagedIndexSettings.kt
99.09% <99.09%> (ø)
1.00 <1.00> (?)

...pensearch/indexmanagement/IndexManagementPlugin.kt
90.79% <100.00%> (+1.66%)
12.00 <1.00> (ø)

...exstatemanagement/settings/ManagedIndexSettings.kt
98.94% <100.00%> (+0.02%)
1.00 <0.00> (ø)

...xmanagement/rollup/actionfilter/FieldCapsFilter.kt
46.54% <100.00%> (ø)
21.00 <0.00> (ø)

...management/rollup/interceptor/RollupInterceptor.kt
68.96% <100.00%> (ø)
31.00 <0.00> (ø)

.../indexmanagement/rollup/settings/RollupSettings.kt
97.56% <100.00%> (ø)
1.00 <0.00> (ø)

... and 8 more

Continue to review full report at Codecov.

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


Seems we never check how many args we have

          Seems we never check how many args we have

Originally posted by @inimbir in https://github.com/Autodoc-Technology/redis-nats-proxy/pull/1#discussion_r1543157882

This is an example one and won't be fixed.


Edge detection function

Write edge detection function in python (eventually should include error handling and tests)

closing this since completed


Is it possible to add support for custom query function like the select2?

@kencaron That involves filter having a reference to the options globally.


Use Java 8's Consumer interface.

Use the Consumer interface introduced in Java 8, as it can be backported for older versions of Android via core library desugaring.

Thanks, but can't merge with the build failures. Is there an update mojo sniffer?
And would need to make sure the API change is backwards compatible too.

Thanks, but can't merge with the build failures. Is there an update mojo sniffer?

I didn't change anything else, so I'm not sure why the build is failing.

And would need to make sure the API change is backwards compatible too.

With existing calls to forEach?

The build fails because we use the Mojo Animal Sniffer plugin to verify that all APIs used are in the appropriate Java and Android language levels. It doesn't believe that the Consumer interface is available on Android -- which is why I added that internal workaround.
The error in the build is:
Error:  /home/runner/work/jsoup/jsoup/src/main/java/org/jsoup/nodes/Node.java:665: Undefined reference: void java.util.function.Consumer.accept(Object)
Error:  /home/runner/work/jsoup/jsoup/src/main/java/org/jsoup/nodes/Element.java:1825: Undefined reference: void java.util.function.Consumer.accept(Object)
Error:  Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.22:check (animal-sniffer) on project jsoup: Signature errors found. Verify them and ignore them with the proper annotation if needed. -> [Help 1]

The check is defined in the POM: https://github.com/jhy/jsoup/blob/29be991198d3b518d64ee36176ae415688468f61/pom.xml#L74-L78
I don't see an update to that signature definition that supports the APIs brought in by new desugaring implementation. So we would need to find a different way to do those tests. Or allow-list the API explicitly, or something.

I added an ignore rule for the Mojo Animal Sniffer plugin.

Cool - the next issue to resolve is the API backwards compat issue - the interface has changed:
Error:  Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.17.1:cmp (default) on project jsoup: There is at least one incompatibility: org.jsoup.helper.Consumer.accept(java.lang.Object):METHOD_REMOVED,org.jsoup.helper.Consumer:SUPERCLASS_REMOVED,org.jsoup.helper.Consumer:CLASS_REMOVED,org.jsoup.helper.Consumer:CLASS_GENERIC_TEMPLATE_CHANGED,org.jsoup.nodes.CDataNode:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.Comment:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.DataNode:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.Document:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.DocumentType:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.Element.forEach(org.jsoup.helper.Consumer):METHOD_REMOVED,org.jsoup.nodes.Element.forEachNode(org.jsoup.helper.Consumer):METHOD_REMOVED,org.jsoup.nodes.Element:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.FormElement:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.Node.forEachNode(org.jsoup.helper.Consumer):METHOD_REMOVED,org.jsoup.nodes.PseudoTextElement:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.TextNode:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.XmlDeclaration:METHOD_REMOVED_IN_SUPERCLASS -> [Help 1]

I think we can deal with that by making the jsoup Consumer extend from the Java Consumer, and mark it deprecated for removal in the next release.

Cool - the next issue to resolve is the API backwards compat issue - the interface has changed:
Error:  Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.17.1:cmp (default) on project jsoup: There is at least one incompatibility: org.jsoup.helper.Consumer.accept(java.lang.Object):METHOD_REMOVED,org.jsoup.helper.Consumer:SUPERCLASS_REMOVED,org.jsoup.helper.Consumer:CLASS_REMOVED,org.jsoup.helper.Consumer:CLASS_GENERIC_TEMPLATE_CHANGED,org.jsoup.nodes.CDataNode:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.Comment:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.DataNode:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.Document:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.DocumentType:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.Element.forEach(org.jsoup.helper.Consumer):METHOD_REMOVED,org.jsoup.nodes.Element.forEachNode(org.jsoup.helper.Consumer):METHOD_REMOVED,org.jsoup.nodes.Element:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.FormElement:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.Node.forEachNode(org.jsoup.helper.Consumer):METHOD_REMOVED,org.jsoup.nodes.PseudoTextElement:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.TextNode:METHOD_REMOVED_IN_SUPERCLASS,org.jsoup.nodes.XmlDeclaration:METHOD_REMOVED_IN_SUPERCLASS -> [Help 1]

I think we can deal with that by making the jsoup Consumer extend from the Java Consumer, and mark it deprecated for removal in the next release.

Yeah, I was thinking of adding overloaded methods for the separate consumer types, but your solution is much better.

I tried removing the accept method in the Jsoup Consumer, but Mojo gave an error saying the method had been removed, even though it's there in the parent interface.

OK, my commit has deprecated the old methods, and added a temporary deprecated overload for the old version. This ensures both source and binary compatibility in this version.  The next version can remove these methods.

Thanks again! Have merged.


Feature request: Please implement IORING_OP_TEE

I was excited to see IORING_OP_SPLICE go in, but disappointed that tee didn't go in at the same time.  It would be very useful to copy pipe buffers in an async program.

I think it'd be more productive to post these on the io-uring mailing list, not sure who actually monitors the liburing issues for feature requests...

It landed in 5.8. Can be closed now, I suppose.

How about to close it?

How about to close it?

On Sun, Jan 10 2021 at 08:24:51 -0800, Jens Axboe quoth thus:
I just read Pavel's reminder and was about to do so, but you beat
me to it.  Thanks!

Closed #116.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/axboe/liburing/issues/116#event-4188187309

On Sun, Jan 10 2021 at 08:24:51 -0800, Jens Axboe quoth thus:
I just read Pavel's reminder and was about to do so, but you beat
me to it.  Thanks!

Closed #116.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/axboe/liburing/issues/116#event-4188187309


More indicators

Add at least a horizontal situation indicator (HSI).
Maybe also the slip skid indicator to complete the classic six indicators.

See future ideas in readme


Cannot pull with rebase: You have unstaged changes.

Hello,
I am unable to upgrade. This is the result:
Upgrading Oh My Zsh Cannot pull with rebase: You have unstaged changes. Please commit or stash them. There was an error updating. Try again later?
I initially installed using the basic installation process.

Hi,
This message means that you made custom changes to OMZ since the last upgrade. (You should be aware of that, since you (or someone using your computer) did it.)
In case you do not know of any changes you made and just want them gone, then this should do it:
cd $ZSH && git stash && cd -

The upgrade process is not designed to allow local changes. If you want to customize your install, you should use the $ZSH_CUSTOM directory (see wiki). If you want to keep local changes in OMZ core, you will have to maintain your own fork.

Indeed, I understand. I will resort to $ZSH_CUSTOM Thanks very much for your very prompt help. Problem solved.

My pleasure. Please close this issue now that your problem is solved ;-)


feat: provide the sha256 digest as an oci_image target

Fixes #60
Ran into this at a client and I'd rather not paste the genrule everywhere.

I suspect this change breaks the build for our images marked with testonly:
ERROR: /__w/BUILD:31:30: in directory_path rule //X:X-e2e-tests_image_index_json: non-test target '//X:X-e2e-tests_image_index_json' depends on testonly target '//X:X-e2e-tests_image' and doesn't have testonly attribute set

I suspect this change breaks the build for our images marked with testonly:
ERROR: /__w/BUILD:31:30: in directory_path rule //X:X-e2e-tests_image_index_json: non-test target '//X:X-e2e-tests_image_index_json' depends on testonly target '//X:X-e2e-tests_image' and doesn't have testonly attribute set

could you please file an issue for this?


Toolbar stomping on jQuery again

The problem introduced about stomping on jQuery with the Toolbar.jsp in #48 and fixed in #210
was reintroduced in #341 when we added back jQuery to the toolbar. Using the default toolbar is back to causing issues for some replayed pages. I think we need to re-remove the jQuery dependency in Toolbar.jsp.

@MohammedElsayyed Do you want to look at a solution for removing the jQuery dependency from the Toolbar?

@ldko I will be happy to work on it, but I already have many tasks should be done.


Jetty startup

This is the simplified Jetty Startup I proposed to address #375

Coverage increased (+0.02%) to 18.383% when pulling c467869d6dafaf3ede5194b5f940ce7f4916e914 on lorrin:jetty_startup into f61b7d7de76d3cb61f6fc5d3586b20cbf86e38d7 on decebals:master.

Coverage increased (+0.03%) to 18.391% when pulling 36e8c337b2d2e8c669835d2db837cdefdefb24da on lorrin:jetty_startup into f61b7d7de76d3cb61f6fc5d3586b20cbf86e38d7 on decebals:master.

OK, I've adjusted the stop() method.
BTW, the threading doesn't seem totally safe here. running and reloading are volatile, but there is unsynchronized logic that checks the current value, then does work and  updates the value. Two threads could call start, both see running==false, then both proceed to try to start the server. Instead of synchronized blocks, it might be better to fix this with an AtomicReference to an Enum that represents the possible states. Then if you want to start the server, you see if it is in Uninitialized state. If it is, try to compareAndSet it to Starting state. if you fail, then probably some other thread was already starting it. If you succeed, you get to start it. Then when you're done, set it to Started state. Etc. But that's unrelated to this PR. Also only a hypothetical concern and not a real-world problem for me so far. ;-)

Thanks!

Sure, happy to help. Thanks for being so response to all the PRs.


Selective export

Was working on something this week where I only wanted to export processes selectively, and thought it would make for a useful feature.
Cliff notes.

Added selective export
Standardised interface to exporters
** Location is now compulsory
** Passing a process name is optional
** Refactoring of duplicate code into [Foreman::Export::Base].
Test coverage

Cheers,
Chris

You should be able to achieve this using concurrency:
foreman export upstart /tmp/example -c "desiredprocess=2,undesiredprocess=0"
Cheers,
David


Socket Map Not Working

Expected Behavior
Map loads and displays trainer, path, and catches.
Actual Behavior
Does not load.  Says: Waiting to get GPS coordinates from Bot...

Steps to Reproduce
Run latest commit.
Other Information
OS: OS X
Git Commit: a716a34

Did you test with Chrome?
Could you past console log, browser log as well as the result of "pip freeze"?

Sorry I didn't include the web browser: chrome, but also occurs on firefox
Typical Console Log:
2016-08-12 11:20:12] [x] PokemonGO Bot v1.0
[2016-08-12 11:20:12] [x] Configuration initialized
[2016-08-12 11:20:12] [Plugins] Loaded plugin "evolver".
[2016-08-12 11:20:12] [Plugins] Not loading plugin "web"
[2016-08-12 11:20:12] [Plugins] Loaded plugin "socket".
[2016-08-12 11:20:12] [Plugins] Loaded plugin "recycle_items".
[2016-08-12 11:20:12] [Plugins] Loaded plugin "catch_pokemon".
[2016-08-12 11:20:12] [Plugins] Loaded plugin "spin_pokestop".
[2016-08-12 11:20:12] [Plugins] Loaded plugin "transfer_pokemon".
[2016-08-12 11:20:12] [Plugins] Loaded plugin "egg_incubator".
[2016-08-12 11:20:13] [Plugins] Plugins loaded: ['catch_pokemon', 'egg_incubator', 'evolver', 'recycle_items', 'socket', 'spin_pokestop', 'transfer_pokemon']
[2016-08-12 11:20:13] [x] Fetching altitude from google
[2016-08-12 11:20:14]
[2016-08-12 11:20:14] [x] Address found: lat, long
[2016-08-12 11:20:14] [x] Position in-game set as: (lat, long, alt)
[2016-08-12 11:20:14]
[2016-08-12 11:20:14] Web client connected
[2016-08-12 11:20:16] [+] Login to Pokemon Go successful.
[2016-08-12 11:20:18] [#]
...Trainer Data ...
[2016-08-12 11:20:18] [#]
[2016-08-12 11:20:18] [x] Starting PokemonGo Bot....
...
[2016-08-12 11:21:42] Web client disconnected
[2016-08-12 11:21:42] Web client connected
Occasionally I get this error:
[2016-08-12 11:28:18] Web client disconnected
Exception in thread Thread-9:
Traceback (most recent call last):
File "/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 599, in process_request_thread
self.handle_error(request, client_address)
File "/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 596, in process_request_thread
self.finish_request(request, client_address)
File "/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 331, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 652, in init
self.handle()
File "/usr/local/lib/python2.7/site-packages/werkzeug/serving.py", line 216, in handle
rv = BaseHTTPRequestHandler.handle(self)
File "/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 340, in handle
self.handle_one_request()
File "/usr/local/lib/python2.7/site-packages/werkzeug/serving.py", line 251, in handle_one_request
return self.run_wsgi()
File "/usr/local/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi
execute(self.server.app)
File "/usr/local/lib/python2.7/site-packages/werkzeug/serving.py", line 181, in execute
application_iter = app(environ, start_response)
File "/usr/local/lib/python2.7/site-packages/flask/app.py", line 2000, in call
return self.wsgi_app(environ, start_response)
File "/usr/local/lib/python2.7/site-packages/flask_socketio/init.py", line 37, in call
start_response)
File "/usr/local/lib/python2.7/site-packages/engineio/middleware.py", line 47, in call
return self.engineio_app.handle_request(environ, start_response)
File "/usr/local/lib/python2.7/site-packages/socketio/server.py", line 308, in handle_request
return self.eio.handle_request(environ, start_response)
File "/usr/local/lib/python2.7/site-packages/engineio/server.py", line 247, in handle_request
socket = self._get_socket(sid)
File "/usr/local/lib/python2.7/site-packages/engineio/server.py", line 359, in _get_socket
raise KeyError('Session is disconnected')
KeyError: 'Session is disconnected'
[2016-08-12 11:28:19] Web client connected
I can provide more logs if you tell me where to look for them.

Run "pip uninstall eventlet"
Send me log from Chrome (ctrl+maj+I) also.
To be sure, are you up to date on github and which url are you using?

From the chrome console:
include.preload.js:425 Calling Element.createShadowRoot() for an element which already hosts a shadow root is deprecated. See https://www.chromestatus.com/features/4668884095336448 for more details.
VM1727:5 Uncaught TypeError: Cannot read property 'removeAttribute' of null(anonymous function) @ VM1727:5(anonymous function) @ VM1727:20
openpogoui.nicontoso.eu/:76 GET http://openpogoui.nicontoso.eu/scripts/ga.js net::ERR_BLOCKED_BY_CLIENT
config.js:63 Load config from storage
jquery-3.1.0.min.js:4 Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience.
I'll have to fix that later.

Ahh! Genesis!  That solved the problem.


Bunny drill fix

Description of the problem

The bunny drill example was broken since the change to Solid Object which were now restarted

Description of the solution

Fix the problem by adding the bunny from the onset of the problem. However,  this required changing insertion mechanism. I used this opportunity to demonstrate the plane insertion as part of an example. I think it's a cool idea.
For a reason I don't know, the time-step was way too small. Updated it to a more coherent value, the simulation is much faster now (like 10 minutes or so)

How Has This Been Tested?

Example was re-run and identical results are obtained

Documentation

Documentation is updated accordingly since we change the insertion mechanism

Comments
Working on this I found another bug. Right now the example will not work correctly if there are no load balancing steps. It seems to be related to the way the objects are displaced and the displacement monitoring is made after the checkpointing. I will use this example to work on fixing this bug, but this will be work this week in a next PR.
Closes the issue in #1129

I think the time step was small because of the rotation of the solid object.
Big time steps had a tendency to deforme the bunny...


Add INFO_CLICK event to markercluster

I'm submitting a ...  (check one with "x")
[ ] question
[ ] any problem or bug report
[x] feature request
Add INFO_CLICK event to markercluster. Currently it only supports MARKER_CLICK.
This can be done by simply changing line 1490 in multiple_maps branch, Map.js to:
if (eventName === event.MARKER_CLICK || eventName === event.INFO_CLICK) {

I'd PR it but that doesn't seem to be going very well...

Not acceptable. You have to add the evebt listetner to the clicked marker.

That works, but it's ugly. Requires more logic to address the possibility that someone would click on another marker, then reclick on that marker - thus adding two event handlers. But whatever. I get the picture.


Adding ability to look up team.roster by week.

Is there any update on being able to pull in team.roster by week at all? It looks like there is a TODO on the sandbox site - TODO: add support for the "week" parameter
Or maybe at least a work-around. I have not had much luck lately.
Appreciate you putting this package together! It's an awesome project.

Let me look into this, it might not be a huge lift.

Uh... so this might actually work and is just a hole in my documentation... but if you simply specify a week, instead of a date, I fall back to using the week...
You can use team_key: mlb.l.5208.t.1 and date: 3 at https://yahoo-fantasy-node-docs.vercel.app/resource/roster/players to see this in action... my league (5208) is public, so you don't need to auth. Let me know if that's what you're looking for and I can update the docs!

I updated the docs roster.players and removed the TODO from team.roster. I hope that this helps you!!

I never got back to you on this but thanks for the response on this! Using that optional parameter is exactly what I was looking for.
The only thing I wish that Yahoo would change about their API is not updating what teams certain players were on. Only takes in account for their current or most recently played team!


Rewoo example wrong array destructure in toolExecution?

In the Rewoo example code in the toolExecution function in the line:
 const [, stepName, tool, , toolInputTemplate] = state.steps[_step - 1];
the toolInputTemplate variable is assigned the entire matching string, not the tool input. I think the line should look like this:
const [, stepName, tool, toolInputTemplate] = state.steps[_step - 1];

Thank you for flagging this! I just checked and you're correct. It looks like reason it worked before is the last element in the array it was extracting included the tool input, but also had extra content which was irrelevant. This change should harden the graph for future runs.
PR here


Performance issues

I get some pretty bad stuttering with mpv playing 1080p video on the example compositor using any backend. We should profile this and figure it out.

Been looking at that bit, this really isn't a cpu/performance problem, but there's something inconsistant somewhere.
Sorry for long logs ahead, feel free to skip through, this is just me thinking aloud - just skip to the end for the important part/question.
Looking with WAYLAND_DEBUG=1 on both mpv and our test compositor, I have this kind of logs on mpv:
[1268950.806]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268951.545]  -> wl_surface@3.commit()
[1268951.720]  -> wl_display@1.sync(new id wl_callback@24)
[1268953.166] wl_display@1.delete_id(24)
[1268963.138] wl_buffer@19.release()
[1268963.419] wl_callback@24.done(0)
[1268967.665]  -> wl_surface@3.attach(wl_buffer@19, 0, 0)
[1268968.220]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268968.935]  -> wl_surface@3.commit()
[1268969.085]  -> wl_display@1.sync(new id wl_callback@24)
[1268970.767] wl_display@1.delete_id(24)
[1268975.286] wl_buffer@19.release()
[1268975.482] wl_callback@24.done(0)
[1268979.953]  -> wl_surface@3.attach(wl_buffer@19, 0, 0)
[1268980.532]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268981.263]  -> wl_surface@3.commit()
[1268981.430]  -> wl_display@1.sync(new id wl_callback@24)
[1268982.689] wl_display@1.delete_id(24)
[1268986.769] wl_buffer@19.release()
[1268986.971] wl_callback@24.done(0)
[1268997.055]  -> wl_surface@3.attach(wl_buffer@19, 0, 0)
[1268997.702]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268998.809]  -> wl_surface@3.commit()
[1268998.999]  -> wl_display@1.sync(new id wl_callback@24)
[1269000.588] wl_display@1.delete_id(24)
[1269008.048] wl_buffer@19.release()
[1269008.283] wl_callback@24.done(0)
[1269015.659]  -> wl_surface@3.attach(wl_buffer@19, 0, 0)
[1269020.650]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1269026.501]  -> wl_surface@3.commit()
[1269026.972]  -> wl_display@1.sync(new id wl_callback@24)
[1269033.122] wl_display@1.delete_id(24)
[1269033.458] wl_buffer@19.release()
[1269033.708] wl_buffer@19.release()
[1269033.891] wl_callback@24.done(0)
[1269036.023]  -> wl_surface@3.attach(wl_buffer@19, 0, 0)
[1269036.713]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1269037.571]  -> wl_surface@3.commit()
[1269037.775]  -> wl_display@1.sync(new id wl_callback@24)
[1269039.247] wl_display@1.delete_id(24)
[1269045.929] wl_callback@24.done(0)
[1277574.568] wl_buffer@19.release()
[1277576.047] wl_buffer@19.release()
[1277577.414] wl_buffer@19.release()
[1277578.627] wl_buffer@19.release()
[1277579.520] wl_buffer@19.release()
... (hundreds of release() events)
[1277675.620] wl_buffer@19.release()
[1277678.921]  -> wl_surface@3.attach(wl_buffer@19, 0, 0)
[1277679.631]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1277680.482]  -> wl_surface@3.commit()
[1277680.699]  -> wl_display@1.sync(new id wl_callback@24)
[1277681.936] wl_display@1.delete_id(24)
[1277688.316] wl_buffer@19.release()
[1277688.740] wl_buffer@19.release()
[1277688.931] wl_buffer@19.release()
[1277689.092] wl_buffer@19.release()
[1277689.252] wl_buffer@19.release()
[1277689.413] wl_buffer@19.release()
[1277689.601] wl_buffer@19.release()
[1277689.759] wl_callback@24.done(0)
[1277695.167]  -> wl_surface@3.attach(wl_buffer@19, 0, 0)
[1277695.882]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1277696.773]  -> wl_surface@3.commit()
[1277696.979]  -> wl_display@1.sync(new id wl_callback@24)
[1277698.613] wl_display@1.delete_id(24)
[1277704.098] wl_buffer@19.release()
[1277704.337] wl_callback@24.done(0)
[1277711.810]  -> wl_surface@3.attach(wl_buffer@19, 0, 0)
[1277712.390]  -> wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1277717.996]  -> wl_surface@3.commit()
[1277718.175]  -> wl_display@1.sync(new id wl_callback@24)
[1277719.532] wl_display@1.delete_id(24)
[1277723.667] wl_buffer@19.release()
[1277723.925] wl_callback@24.done(0)

and matching compositor logs:
1268952.372] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1268952.411] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268952.438] wl_surface@3.commit()
[1268952.475] wl_display@1.sync(new id wl_callback@24)
[1268952.498]  -> wl_callback@24.done(0)
[1268952.511]  -> wl_display@1.delete_id(24)
[1268961.371]  -> wl_buffer@19.release()
[1268969.479] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1268969.527] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268969.578] wl_surface@3.commit()
[1268969.622] wl_display@1.sync(new id wl_callback@24)
[1268969.646]  -> wl_callback@24.done(0)
[1268969.660]  -> wl_display@1.delete_id(24)
[1268976.828]  -> wl_buffer@19.release()
[1268981.887] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1268981.925] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268981.952] wl_surface@3.commit()
[1268981.987] wl_display@1.sync(new id wl_callback@24)
[1268982.009]  -> wl_callback@24.done(0)
[1268982.024]  -> wl_display@1.delete_id(24)
[1268993.508]  -> wl_buffer@19.release()
[1268999.528] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1268999.592] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268999.624] wl_surface@3.commit()
[1268999.663] wl_display@1.sync(new id wl_callback@24)
[1268999.707]  -> wl_callback@24.done(0)
[1268999.725]  -> wl_display@1.delete_id(24)
[1269010.197]  -> wl_buffer@19.release()
[1269026.813]  -> wl_buffer@19.release()
[1269027.649] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1269027.688] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1269027.716] wl_surface@3.commit()
[1269027.745] wl_display@1.sync(new id wl_callback@24)
[1269027.766]  -> wl_callback@24.done(0)
[1269027.781]  -> wl_display@1.delete_id(24)
[1269038.273] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1269038.316] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1269038.344] wl_surface@3.commit()
[1269038.379] wl_display@1.sync(new id wl_callback@24)
[1269038.403]  -> wl_callback@24.done(0)
[1269038.417]  -> wl_display@1.delete_id(24)
[1269043.507]  -> wl_buffer@19.release()
[1269060.121]  -> wl_buffer@19.release()
[1269077.317]  -> wl_buffer@19.release()
[1269093.728]  -> wl_buffer@19.release()
[1269110.453]  -> wl_buffer@19.release()
[1269127.512]  -> wl_buffer@19.release()
[1269144.257]  -> wl_buffer@19.release()
[1269160.988]  -> wl_buffer@19.release()
[1269177.478]  -> wl_buffer@19.release()
[1269194.464]  -> wl_buffer@19.release()
[1269210.834]  -> wl_buffer@19.release()
[1269227.713]  -> wl_buffer@19.release()
[1269244.116]  -> wl_buffer@19.release()
... zillions of release
[1277639.300]  -> wl_buffer@19.release()
[1277655.918]  -> wl_buffer@19.release()
[1277672.594]  -> wl_buffer@19.release()
[1277681.193] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1277681.234] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1277681.261] wl_surface@3.commit()
[1277681.294] wl_display@1.sync(new id wl_callback@24)
[1277681.317]  -> wl_callback@24.done(0)
[1277681.332]  -> wl_display@1.delete_id(24)
[1277689.255]  -> wl_buffer@19.release()
[1277697.513] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1277697.612] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1277697.644] wl_surface@3.commit()
[1277697.695] wl_display@1.sync(new id wl_callback@24)
[1277697.722]  -> wl_callback@24.done(0)
[1277697.739]  -> wl_display@1.delete_id(24)
[1277705.908]  -> wl_buffer@19.release()
[1277718.646] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1277718.688] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1277718.716] wl_surface@3.commit()
[1277718.758] wl_display@1.sync(new id wl_callback@24)
[1277718.780]  -> wl_callback@24.done(0)
[1277718.794]  -> wl_display@1.delete_id(24)
[1277722.624]  -> wl_buffer@19.release()

So we (compositor) send release events all the time consistently (everytime our compositor calls wlr_surface_flush_damage, which it does 60 times a second pretty well) but mpv only gets it after unblocking.
Looking with strace now, mpv is stuck in a poll (POLLIN) on the wayland socket waiting for us to say something ; and surely enough, strace on compositor does show the logging of the release() calls but we never sendmsg() to the client until the moment it's unstuck.
I think we're missing something obvious. This is really just buffering, as the sendmsg when it unblocks is exactly 4k in size.
I tried adding wl_display_flush_clients(state->display) at the end of handle_output_frame, and manually tracking the client to use wl_client_flush to no avail.
Does anything else come to mind?

Hmm, nothing immediately comes to mind. It is probably worthwhile to examine the Weston rendering loop and see what they're doing differently.

Just looked at weston (weston_output_repaint?) and I can't see much difference, nothing that looks like flush anyway.
I've looked at what wayland does when you call flush, there's an internal variable called "want_flush" in the client's connection attribute that is always 0 at this point, so our flush does nothing -- I've tried copying the wl_client/connection structs and manually setting that to 1 before calling wl_client_flush. If I do that, I no longer see hangs (so the flush actually works), but while it confirms the problem it's not really a solution.
I'll try to understand this all a bit better.

Found a slightly better workaround:
diff --git a/types/wlr_surface.c b/types/wlr_surface.c
index 43f8f65..a0e7b5e 100644
--- a/types/wlr_surface.c
+++ b/types/wlr_surface.c
@@ -292,7 +292,7 @@ release:
        pixman_region32_fini(&surface->current.buffer_damage);
        pixman_region32_init(&surface->current.buffer_damage);

-       wl_resource_queue_event(surface->current.buffer, WL_BUFFER_RELEASE);
+       wl_resource_post_event(surface->current.buffer, WL_BUFFER_RELEASE);
 }

 static void surface_set_buffer_transform(struct wl_client *client,

Not very satisfying, because both wlc and weston use queue_event, so there must be another reason they're flushing... But this works.
I believe it's also a bug in wayland that in connection.c, wl_connection_queue does not set connection->want_flush. I'm not actually totally sure. wl_connection_write used for post_event doesn't actually do the sendmsg, it just sets the flag want_flush, so in that sense I guess using post_event isn't too bad when we actually want to make sure the client gets it -- I'm not sure why it matters for a buffer release event, though...
Anyway, I'm done looking. Will post a PR with above patch if you think it's acceptable, otherwise I'll let someone else look.

I'm okay with this for now, but let's not close this issue yet.

Okay, found the difference with wlc.
In sway, on sway side, we have this sequence:
[3648972.416] wl_surface@3.attach(wl_buffer@19, 0, 0)
[3648972.454] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[3648972.475] wl_surface@3.commit()
[3648972.550]  -> wl_buffer@16.release()
[3648972.561] wl_display@1.sync(new id wl_callback@18)
[3648972.571]  -> wl_callback@18.done(51)
[3648972.577]  -> wl_display@1.delete_id(18)

But with wlroots we have
[1268969.479] wl_surface@3.attach(wl_buffer@19, 0, 0)
[1268969.527] wl_surface@3.damage(0, 0,<PHONE_NUMBER>,<PHONE_NUMBER>)
[1268969.578] wl_surface@3.commit()
[1268969.622] wl_display@1.sync(new id wl_callback@24)
[1268969.646]  -> wl_callback@24.done(0)
[1268969.660]  -> wl_display@1.delete_id(24)
[1268976.828]  -> wl_buffer@19.release()

Basically, we won't release the buffer after commit/before sync, but at some point later.
The "done" callback ensures that wlc always sends the release here.
We do it that way because we only release after page flip, so tbh I think we're right here.
Is there anything that says we have to release right away? That doesn't seem efficient, would have to copy...

I think it's a bug on our side to release multiple times though, not sure why we do that. We correctly set surface->current.buffer to NULL after releasing, so not sure how the next flush damage can find it again...

Ah, that current.buffer = NULL is new, we don't anymore. I'm happy with how things are now :)

Cool, thank you for investigating :)


Assassin's Mark and Blasphemy+Quality

Shouldn't quality on Blasphemy Support also increase the Cursed enemies have an additional (5-9)% chance to receive a Critical Strike (and therefore the Effective crit chance stat) as it increases the Cursed enemies take 20% increased Extra Damage from Critical Strikes part of the skill?

Modifiers to curse effect are correctly applying to that stat; however, curse effect calculations always round towards zero, and the 10% effect from 20Q Blasphemy isn't enough to bump the 9% value up to 10 (as 9 * 1.1 = 9.9, which rounds back down to 9). If you get some curse effect from other sources however, you will see that Blasphemy's quality does in fact apply.


Is Sendgrid Supported ??

Is Sendgrid Supported ??

Yeah you can use any smtp service.

Oh Thanks

Yeah you can use any smtp service.

Thanks


request replacement for deprecated CameraBoardSocket::RGB, LEFT, RIGHT, and CENTER.

Commit eecb8de3a1fcb57dce3cc556f0373bc31a913fb5 removed important functionality. I request a replacement method/process/api for an application to use so that the app can programmatically identify color cameras and depth mono pairs of cameras in retail OAK sensors.

My applications need to be able to open and use the color RGB camera.
My applications need to be able to open and use one mono camera, two mono cameras, or combined as a virtual depth.

dai::CameraBoardSocket::RGB is deprecated. it now has an uncertain future. My applications need an alterative programmatic method to definitely access and denote each camera on the sensor. This api needs to be within depthai-xxxx itself...only it knows itself, its firmware, hardware, sensors attached, etc. Customers writing solutions for OAK should not need to build their own database lookup tables or probing mechanisms.
Naturally, the enum is a great solution for retail OAK sensors since it is a compile-time constant that is unvarying, simple, and definitive. Personally...I would revert the deprecation and instead add specialized/new methods for custom OAK boards which have unknown sensors in unknown places/sockets.
Setup

all os, platforms
depthai-shared eecb8de3a1fcb57dce3cc556f0373bc31a913fb5

Repro

Write any depthai-core application that uses CameraBoardSocket::RGB. Or use the many tests+examples included with depthai-core.
config and build your application for Debug

Result
Many warnings (may be elevated to errors)
error C4996: 'dai::CameraBoardSocket::RGB': was declared deprecated
error C4996: 'dai::CameraBoardSocket::LEFT': was declared deprecated
error C4996: 'dai::CameraBoardSocket::RIGHT': was declared deprecated

Expected
No warnings or errors. Code should continue to build and work with no flaws

Check updated examples:

My applications need to be able to open and use the color RGB camera. - use getConnectedCameraFeatures() & check for "COLOR" camera. Use any you see fit.
My applications need to be able to open and use one mono camera, two mono cameras, or combined as a virtual depth. - Addressed with naming. Use 'left' & 'right' to default to those two imagers.

Reason for the change is that board socket does not correlate to the "semantic" of a camera, especially in FFC scenarios or newer devices. The semantic can be inferred either from name, or from type or other features that are retrievable.
This was also a reason for the deprecation - it'll go away in the future, hopefully replaced with something better, but it is api that does not hold correct.
Better will likely be a replacement of sorts: "getDefaultCameraBoardSocket(dai::Camera::RGB)" which returns a socket (perhaps optional) or name, etc... getDefaultCamera(dai::Camera::LEFT) -> None or "left" for instance.
This can then be feed into either:

Constructor of Color/Mono/Camera
camera.setName(getDefaultCamera(dai::Camera::LEFT))
...

I don't see any improvements or replacements in examples
main
https://github.com/luxonis/depthai-core/blob/125feb8c2e16ee4bf71b7873a7b990f1c5f17b18/examples/ColorCamera/rgb_preview.cpp#L19
develop
https://github.com/luxonis/depthai-core/blob/5f75ae74ade6ae12bd56c71c0149c0482f23c18f/examples/ColorCamera/rgb_preview.cpp#L19
The latter would require startups/teardowns of pipelines starting at A -> ? letter to find somewhere a color camera. Naturally, this is unworkable.
I encourage continued compatibility such that today's RGB, LEFT, RIGHT, CENTER continue to work. It would be the job  internal code within depthai-core to map that into the given't device's color camera. for example....
if (value <= easyEnums)
    // map easy enums to technical socket
   value = getDefaultCameraFromEnum(easyEnum)
else
   // nothing, it is an abstracted technical socket letter

doThings(value)

I encourage continued compatibility such that today's RGB, LEFT, RIGHT, CENTER continue to work. It would be the job internal code within depthai-core to map that into the given't device's color camera. for example....

if (value <= easyEnums)
    // map easy enums to technical socket
   value = getDefaultCameraFromEnum(easyEnum)
else
   // nothing, it is an abstracted technical socket letter

doThings(value)

This'd be a good approach - but might fall short in cases where there is no device info available. Likes of CalibrationHandler, etc...
That usage would still be deprecated then, but conditionally. So would have to fall under a runtime check.

Current replacement mechanism would likely be setCamera. left, right, color would be the names corresponding on the usual devices. (Some examples do use them, some do not). Main ones being stereo ones: https://github.com/luxonis/depthai-core/blob/5f75ae74ade6ae12bd56c71c0149c0482f23c18f/examples/StereoDepth/depth_preview.cpp

I saw you recently released a version with these new APIs. Your build has many warnings on the deprecation. I recommend the SDK code's be updated to not deprecate itself and to use the deprecation feature where you can put the new api usage.
https://en.cppreference.com/w/cpp/language/attributes/deprecated.
Naturally, breaking API changes are strongly discouraged as it leads to difficult by customers like me. That is unless you were jumping from depthai v2 -> depthai v3 and then there are many opportunities for breaking changes.

..and what is the plan for inspecting values of EepromData?  version=7 of it needs CameraBoardSocket. How can a program inspect values for the RGB camera? The new setCamera() api does not address this topic.
Keep in mind that EepromData has no field to identify an rgb camera. There is only CameraBoardSocket. So when a program needs to inspect rgb (or any other camera's) properties, then the program needs that enum or some other way to discover the sensor. https://github.com/luxonis/depthai-core/issues/285
For example, my app needs to know if a camera is fixed or auto focus for many reason including https://github.com/luxonis/depthai-core/issues/326. I am still required to inspect rgbCamera->second.lensPosition == 0 to determine this. A subset of new sensors might have the free-form text field productName with a FF at the end, doesn't help the thousands of previous sensors in the marketplace. Naturally, string scraping a std::string field for "FF" is error-prone and a hack for both Luxonis and customers. Naturally, a bool fixedFocus; is one of many fields on a camera struct that would help fill this gap. If we could even identify which CameraBoardSocket contains an rgb camera.

CameraFeatures is the plan - that will be the main "capabilities" of imaging portion of the device.
To discover rgb camera, you may use supportedTypes, where first option describes the type of imager (eg: CameraSensorType::COLOR). There may be many as FFC cases contain imagers that cannot be identified upfront (likes of OV9282 vs its color variant OV9782). This is rare & in progress of being addresses as well, but requires HW changes.
Likewise for autofocus capabilities, which is WIP.

We'll implement replacements using setName (to be able to 'left', 'right', 'center', 'rgb', ..., across all devices) and add means to query for these sockets:
Device::getCameraSocket(string cameraName);

Modifications include:
// CameraFeatures
vector<string> additionalNames;


Bounce tests

Adds in some tests for the feature implemented in #767 and some helper methods we should be able to reuse for any other tests that need more than 2 slaves
/cc @wsorenson @tpetr

LGTM -- @wsorenson ?


Adding test to check for custom scalars using metrics

[x] Bugfix

Changes in this PR
Issue #1432
This PR is an attempt to fix the issue linked above. I added a smoke test in MicrometerServletSmokeTest.kt to set up a test case for it. However, the test case is passing even when I recreated the scenario described in the issue. It's unclear at the moment if the issue is still outstanding or not. Creating this PR so I can link it to the issue and continue discussion there to see if I made a mistake in setting up the failure case.

The issue was regarding queries with variables as well as custom scalars, and your example doesn't cover that, which is why it didn't trigger the issue. The associated issue has been fixed, so I will close this PR.


Problem creating rulesets

Could you expand on how to create your own rulesets? I looked into ServiceLoader javadocs and have the following understanding:
You should have a directory structure similar to:
(taken from the ktlint-ruleset-template)
Project/
    src/main/
        kotlin/
            CustomRuleSetProvider
            Rules
        resources/
            META-INF.services/
                com.github.shyiko.ktlint.core.RuleSetProvider

From the project directory you should be able to run:
jar cf ruleset.jar Project/
And then this can be used by ktlint as:
ktlint -R ruleset.jar ....
Although my rule is never reached! Could you please give more details on how exactly this jar should be created?
Here is what my resources look like:
//resources/META-INF.services
//com.github.shyiko.ktlint.core.RuleSetProvider
mypackage.CustomRuleSetProvider
Here is my CustomRuleSetProvider
//CustomRuleSetProvider
 package mypackage

 import com.github.shyiko.ktlint.core.RuleSet
 import com.github.shyiko.ktlint.core.RuleSetProvider

 class CustomRuleSetProvider : RuleSetProvider {

     override fun get(): RuleSet = RuleSet("custom", TestVisit())
 }

Here is my Rule, which naively prints a test message on each visit.
//TestVisit
package mypackage

import com.github.shyiko.ktlint.core.Rule
import org.jetbrains.kotlin.com.intellij.lang.ASTNode
import org.jetbrains.kotlin.com.intellij.psi.impl.source.tree.LeafPsiElement
import org.jetbrains.kotlin.com.intellij.psi.util.PsiTreeUtil.getNonStrictParentOfType
import org.jetbrains.kotlin.psi.KtStringTemplateEntry

class TestVisit : Rule("test-visit") {

    override fun visit(
        node: ASTNode,
        autoCorrect: Boolean,
        emit: (offset: Int, errorMessage: String, canBeAutoCorrected: Boolean) -> Unit
    ) {
        emit(node.startOffset, "test", false)
    }
}

Hi. src/main/resource/META-INF.services should be src/main/resource/META-INF/services. Take a look at https://stackoverflow.com/questions/51368558/ktlint-custom-reporter/51391651#51391651. Let me know if that doesn't help.

@chaneylc try the following
$ cd ktlint-ruleset-template/
$ ./gradlew build
$ echo 'var v = 0' > test.kt
$ ktlint -R build/libs/ktlint-ruleset-template.jar --debug --relative test.kt

[DEBUG] Resolving build/libs/ktlint-ruleset-template.jar
[DEBUG] Loading file:/tmp/ktlint/ktlint-ruleset-template/build/libs/ktlint-ruleset-template.jar
[DEBUG] Discovered ruleset "standard"
[DEBUG] Discovered ruleset "custom"
[DEBUG] Discovered reporter "plain"
[DEBUG] Discovered reporter "json"
[DEBUG] Discovered reporter "checkstyle"
[DEBUG] Initializing "plain" reporter with {verbose=false, color=false}
[DEBUG] Checking test.kt
[DEBUG] Discovered .editorconfig (..) {charset=utf-8, end_of_line=lf, indent_size=4, indent_style=space, insert_final_newline=true, trim_trailing_whitespace=true}
test.kt:1:1: Unexpected var, use val instead (cannot be auto-corrected)
[DEBUG] 828ms / 1 file(s) / 1 error(s)

Thanks! I should have looked into gradle before trying to make my own jar. From the main readme I would suggest you change "Once packaged in a JAR you can load it with" with the above snippet you shared.

No worries! I'll keep this ticket open until README is updated if you don't mind. :clinking_glasses:

Awesome! Thanks again for your hard work on this project, its great!


Support custom domains

This PR introduces the following features:

Custom domains
Custom cert directory
Custom name of certification

Can be easily set by:
// vite.config.js
import basicSsl from '@vitejs/plugin-basic-ssl'

export default {
  plugins: [
    basicSsl({name: "test", domains: ["*.custom.com"], certDir: "/Users/.../.devServer/cert"})
  ]
}

Some essential options can make our local development more comfortable. In Chrome, there will not be unfriendly security warnings.

It'd be nice to have this feature.
Building on top of it, providing rootCA to use for signing would be nice. (I have my own rootCA that is trusted in my devices) I can work on that after this is merged.

@bluwy Thank you for reviewing, modifications are done.

The options are quite simple, so I just update readme and add some comments on the options.

I guess getCertificate function is exported for testing?

I guess getCertificate function is exported for testing?

It isn't used in the tests, no?

@patak-dev https://github.com/vitejs/vite-plugin-basic-ssl/blob/17ddf64230e60861e57ec8d2f7799058d75ef671/test/test.spec.ts#L2

Let's release a minor then to have this feature and support for Vite 5
@bluwy, would you expand on

My only question I guess is maybe we should rename certDir to cacheDir. Since certDir could mean the directory if you generated the certificates yourself and we respect that (which we don't).

I didn't get that, certDir sounds good here. We should rename cacheDir to certDir in getCertificate to me 🤔

I didn't get that, certDir sounds good here. We should rename cacheDir to certDir in getCertificate to me 🤔

certDir technically is used more as a cache. And the other options didn't have the cert prefix, meaning they're implicitly cert related already. So I figured cacheDir was clearer.

Ah, I see. cacheDir may confuse some folks with the Vite cache dir. But I understand your point. Let's leave it for now then 👍🏼


(edhe-http) Server non-static handler

(
This change is long overdue and I was delaying it in the (now lost) hope that eventually, the server Handler can become compatible with the nightly AsyncFn closures.
Well, it cannot, and there is no way it could, because AsyncFn closures - just like regular ones - cannot be generic over their parameters, which is a road blocker.
If it is not clear, our handler needs to be generic over the socket type T, and I don't see any way around that.
)
Putting aside this ^^^ topic, what this PR does is to move the generics (including the problematic 'b lifetime generic) to the Handler::handle method, instead of having these on the Handler trait itself.
This is necessary, or else - as is the case in the current code - we need at a few places to put for<'t> type constraints - which - rather than having the desired effect of "for any lifetime" are instead seemingly ending up requiring the lifetime to be equal to 'static.
I'm not sure, but I think this might be another occurrence of this problem.
The PR is much noisier as it also contains a change to suppress the Clippy complaints for us using an unnecessary named lifetime parameter 'b where we can get-by with just '_.

@AnthonyGrondin FYI if you are using/implementing the Handler trait, there is an adjustment to its signature that you need to do. Nothing super-major though, and I wonder how the current handler signature is actually not affecting you in the first place?

The current handler situation is affecting me in the sense that I need static lifetimes, on anything that passes to the handler. For example, this currently makes it so that I have to statically borrow peripherals if I run the server in a loop, because it could be borrowed on the previous iteration.
See: esp-rs/esp-mbedtls#46 (comment)

Hm, not sure that the existing handler does enforce 'static on anything but the edge-nal traits and thus on the embassy-net types.
But perhaps you can try this branch here if it solves the problem for you? It definitely does for me, as now I can use non-static edge-nal and embassy-net types.

I can confirm this fixes the issues for me. I updated what I've been working on with esp-mbedtls locally, and I can use the server without requiring static lifetimes. I can also mutably borrow in a loop without triggering a lifetime issue.
I've looked at the changes, and it's mostly generics / lifetime changes, and other metaprogramming markers, rather than logic changes so it LGTM.


[WIP] Added GATT Time Characteristics

Issue
#58
What does this PR Do?
Added GATT Time Characteristics
Where should the reviewer start?
GATTDayOfWeek.swift, GATTTimeZone.swift, GATTDayDateTime.swift, GATTExactDateTime256.swift

Result of Integration 1
Duration: 15 minutes and 17 seconds
Result: Perfect build! All 206 tests passed. :+1:
Test Coverage: 86%

Result of Integration 2
Duration: 11 minutes and 0 second
Result: Perfect build! All 206 tests passed. :+1:
Test Coverage: 86%

Result of Integration 2
Duration: 11 minutes and 0 second
Result: Perfect build! All 206 tests passed. :+1:
Test Coverage: 86%

Result of Integration 2
Duration: 11 minutes and 0 second
Result: Perfect build! All 206 tests passed. :+1:
Test Coverage: 86%


Add editorial to problem 1289: Issue 196

issue: 196

@RobinHood3082 Dear contributor. You have done an excellent step to step clarification in a very solid manner! Excellent 💯  Please fix the minor typo. Will merger as soon as you correct it! Thank you in advance ❤ Keep contributing more ❤

@RobinHood3082 Dear contributor. You have done an excellent step by step clarification in a very solid manner! Excellent 💯  Please fix the minor typo. Will be merged as soon as you correct it! Thank you in advance ❤ Keep contributing more ❤

@RobinHood3082 Dear contributor, thank you very much 🥇


Do not clear up  filled in information if task creation fails

Right now if task creation fails then it clears all the information filled in by the user

[ ] filled in data must not clear if task creation failed
[ ] If task creation is successful then clear the information filled

@Pavangbhat can you assign this to me


Replace (default) Flannel with Weave Net (on vanilla k8s installed using tectonic-installer)

What you expected to happen?
I am trying to replace the default Flannel (CNI) with Weave (CNI) on a k8s cluster that was installed using the tectonic-installer (Terraform edition).
I made some changes to the Terraform code:

opened the ports required by Weave (6783-6784 both TCP & UDP)
replaced the default kube-flannel.yml (DaemonSet) with a kube-weave.yml alternative (some minor changes: IPALLOC_RANGE variable range, and I'm mounting /etc/kubernetes instead of /etc/)

I expected this to work, however it does not...
What happened?
Originally I assumed that my cluster worked, all nodes are healthy:
NAME                                        STATUS    AGE       VERSION
ip-10-0-24-3.us-east-2.compute.internal     Ready     25m       v1.6.7+coreos.0
ip-10-0-38-230.us-east-2.compute.internal   Ready     25m       v1.6.7+coreos.0
ip-10-0-54-94.us-east-2.compute.internal    Ready     25m       v1.6.7+coreos.0
ip-10-0-6-183.us-east-2.compute.internal    Ready     26m       v1.6.7+coreos.0
ip-10-0-75-162.us-east-2.compute.internal   Ready     25m       v1.6.7+coreos.0
ip-10-0-94-16.us-east-2.compute.internal    Ready     25m       v1.6.7+coreos.0

However I notice that some pods (API, controller & DNS) remain stuck in ContainerCreating state:
NAME                                                               READY     STATUS              RESTARTS   AGE
kube-apiserver-bd4p0                                               1/1       Running             0          26m
kube-apiserver-h9gth                                               1/1       Running             0          26m
kube-apiserver-pnj1v                                               1/1       Running             0          26m
kube-controller-manager-3857991999-0g3md                           0/1       ContainerCreating   0          26m
kube-controller-manager-3857991999-4z66p                           0/1       ContainerCreating   0          26m
kube-controller-manager-3857991999-ll9nj                           0/1       ContainerCreating   0          26m
kube-dns-1102003091-gg9p3                                          0/3       ContainerCreating   0          26m
kube-proxy-09rww                                                   1/1       Running             0          26m
kube-proxy-0qhn6                                                   1/1       Running             0          26m
kube-proxy-2k37v                                                   1/1       Running             0          26m
kube-proxy-986kb                                                   1/1       Running             0          26m
kube-proxy-gp8cm                                                   1/1       Running             0          26m
kube-proxy-p95rx                                                   1/1       Running             0          26m
kube-scheduler-151842939-84vxl                                     0/1       ContainerCreating   0          26m
kube-scheduler-151842939-q6zrw                                     0/1       ContainerCreating   0          26m
kube-scheduler-151842939-sjjp4                                     0/1       ContainerCreating   0          26m
pod-checkpointer-qw8kf                                             1/1       Running             0          26m
pod-checkpointer-qw8kf-ip-10-0-6-183.us-east-2.compute.internal    1/1       Running             0          26m
pod-checkpointer-snn20                                             1/1       Running             0          26m
pod-checkpointer-snn20-ip-10-0-38-230.us-east-2.compute.internal   1/1       Running             0          25m
pod-checkpointer-tnrwm                                             1/1       Running             0          26m
pod-checkpointer-tnrwm-ip-10-0-24-3.us-east-2.compute.internal     1/1       Running             0          25m
weave-net-47630                                                    2/2       Running             0          26m
weave-net-92j13                                                    2/2       Running             0          26m
weave-net-k2q6p                                                    2/2       Running             1          26m
weave-net-pwtkt                                                    2/2       Running             0          26m
weave-net-wfwkc                                                    2/2       Running             1          26m
weave-net-zdrw2                                                    2/2       Running             0          26m

When I describe the pods that are in the ContainerCreating state I see:
Events:
  FirstSeen	LastSeen	Count	From							SubObjectPath	Type		Reason			Message
  ---------	--------	-----	----							-------------	--------	------			-------
  29m		29m		5	default-scheduler							Warning		FailedScheduling	no nodes available to schedule pods
  29m		29m		1	default-scheduler							Normal		Scheduled		Successfully assigned kube-scheduler-151842939-84vxl to ip-10-0-6-183.us-east-2.compute.internal
  29m		29m		1	kubelet, ip-10-0-6-183.us-east-2.compute.internal			Warning		FailedSync		Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-scheduler-151842939-84vxl_kube-system(2a5a2f4a-6887-11e7-a58c-0208e7ad5c41)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-scheduler-151842939-84vxl_kube-system(2a5a2f4a-6887-11e7-a58c-0208e7ad5c41)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-scheduler-151842939-84vxl_kube-system\" network: failed to find plugin \"weave-net\" in path [/opt/cni/bin /opt/weave-net/bin]"

  29m	10s	134	kubelet, ip-10-0-6-183.us-east-2.compute.internal		Normal	SandboxChanged	Pod sandbox changed, it will be killed and re-created.
  29m	10s	134	kubelet, ip-10-0-6-183.us-east-2.compute.internal		Warning	FailedSync	Error syncing pod, skipping: failed to "KillPodSandbox" for "2a5a2f4a-6887-11e7-a58c-0208e7ad5c41" with KillPodSandboxError: "rpc error: code = 2 desc = NetworkPlugin cni failed to teardown pod \"kube-scheduler-151842939-84vxl_kube-system\" network: failed to find plugin \"weave-net\" in path [/opt/cni/bin /opt/weave-net/bin]"

However, the binaries seem to be all present:
ip-10-0-24-3 ~ # ls -al /opt/cni/bin/
total 9852
drwxr-xr-x. 2 root root     4096 Jul 14 11:27 .
drwxr-xr-x. 3 root root     4096 Jul 14 11:27 ..
lrwxrwxrwx. 1 root root       18 Jul 14 11:27 weave-ipam -> weave-plugin-2.0.1
lrwxrwxrwx. 1 root root       18 Jul 14 11:27 weave-net -> weave-plugin-2.0.1
-rwxr-xr-x. 1 root root 10057600 Jul 14 11:27 weave-plugin-2.0.1

Does anybody have idea what is going wrong?  I already opened an issue on cores/tectonic-installer, but it was closed because Weave is currently not supported.  If I get it working I will try to have it pushed into tectonic-installer...
Or does anybody have a clue where I have to start looking?
Anything else we need to know?
Running on AWS (irrelevant to my issue I assume)
Versions:
Weave: 2.0.1
Kubernetes: 1.6.7
Docker: 1.12.6
Logs:
Weave
INFO: 2017/07/14 11:30:21.903923 ->[<IP_ADDRESS>:44821] connection accepted
INFO: 2017/07/14 11:30:21.930890 ->[<IP_ADDRESS>:44821|e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)]: connection ready; using protocol version 2
INFO: 2017/07/14 11:30:21.930972 overlay_switch ->[e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)] using fastdp
INFO: 2017/07/14 11:30:21.931002 ->[<IP_ADDRESS>:44821|e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)]: connection added (new peer)
INFO: 2017/07/14 11:30:21.939706 ->[<IP_ADDRESS>:44821|e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)]: connection fully established
INFO: 2017/07/14 11:30:21.961965 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2017/07/14 11:30:21.967475 sleeve ->[<IP_ADDRESS>:6783|e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)]: Effective MTU verified at 8939
INFO: 2017/07/14 11:30:22.038867 Discovered remote MAC 96:27:aa:29:cf:51 at e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)
INFO: 2017/07/14 11:30:22.571458 Discovered remote MAC e6:7b:21:b5:43:93 at e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)
INFO: 2017/07/14 11:30:22.699666 Discovered remote MAC 76:56:f1:65:f5:1c at e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)
INFO: 2017/07/14 11:52:22.104038 Expired MAC be:eb:da:bd:b7:21 at 32:b1:7a:04:fc:d7(ip-10-0-6-183.us-east-2.compute.internal)
INFO: 2017/07/14 11:53:21.463600 Expired MAC 92:d5:3a:6d:8e:10 at 2a:ff:96:9c:32:c0(ip-10-0-24-3.us-east-2.compute.internal)
INFO: 2017/07/14 11:56:21.464164 Expired MAC 1a:99:af:bd:22:b9 at 0a:0f:63:90:ce:d6(ip-10-0-75-162.us-east-2.compute.internal)
INFO: 2017/07/14 11:57:21.464386 Expired MAC 8a:53:2d:ad:aa:b3 at 32:2b:2e:d3:01:16(ip-10-0-38-230.us-east-2.compute.internal)
INFO: 2017/07/14 11:57:21.464415 Expired MAC 9e:32:c9:5d:dc:15 at da:31:df:78:78:5c(ip-10-0-94-16.us-east-2.compute.internal)
INFO: 2017/07/14 11:58:07.827715 Discovered local MAC 92:d5:3a:6d:8e:10
INFO: 2017/07/14 11:58:21.464603 Expired MAC 96:27:aa:29:cf:51 at e6:7b:21:b5:43:93(ip-10-0-54-94.us-east-2.compute.internal)

Network:
ip-10-0-24-3 ~ # ip route
default via <IP_ADDRESS> dev eth0  proto dhcp  src <IP_ADDRESS>  metric 1024
<IP_ADDRESS>/20 dev eth0  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS> dev eth0  proto dhcp  scope link  src <IP_ADDRESS>  metric 1024
<IP_ADDRESS>/16 dev weave  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/16 dev docker0  proto kernel  scope link  src <IP_ADDRESS>

ip-10-0-24-3 ~ # ip -4 -o addr
1: lo    inet <IP_ADDRESS>/8 scope host lo\       valid_lft forever preferred_lft forever
2: eth0    inet <IP_ADDRESS>/20 brd <IP_ADDRESS> scope global dynamic eth0\       valid_lft 3147sec preferred_lft 3147sec
3: docker0    inet <IP_ADDRESS>/16 scope global docker0\       valid_lft forever preferred_lft forever
24: weave    inet <IP_ADDRESS>/16 scope global weave\       valid_lft forever preferred_lft forever

See https://github.com/weaveworks/weave/issues/2613#issuecomment-277988259
In particular we have it working by adding:
                      --volume=opt-cni,kind=host,source=/opt/cni,readOnly=true \
                      --mount volume=opt-cni,target=/opt/weave-net \

so that the rkt hyperkube image can find the weave cni plugin in the right place

@mikebryant thanks a bunch!  Ran into another tiny issue (had to add ExecStartPre=/bin/mkdir -p /opt/cni to kubelet.service as well), but got working now!

@trescst I just ran into the same issue. I modified the kubelet service and made modifications the weave daemonset (i.e mounting /etc/kubernetes instead of /etc) and I am still seeing issues with my dns, controller-manager, and scheduler pods starting. Any luck on this front?


Add support for CoNLL-U data format

For compatibility with the Universal Dependencies treebanks, it would be great if bistparser could support the CoNLL-U data format[1], natively through a command line option. The format is almost identical to CoNLL-09 except for some column names are different, and:

Leave comments in the output
Skip segmentation spans like 2-4

2-4 dámelo
2    da
3    me
4    lo

And empty node spans like 5.1

1      Sue       Sue
2      likes     like
3      coffee    coffee
4      and       and
5      Bill      Bill
5.1    likes     like
6      tea       tea

http://universaldependencies.org/format.html

i made a test code for bist-parser to train UD treebanks.
https://github.com/dsindex/bist-parser
apply convert.py

Writing a conversion script would be one way of doing it, but I think a better way is to integrate the functionality natively, perhaps with a commandline switch --conllu. If you're doing a lot of work with dependency parsers (SyntaxNet, UDpipe, Bist, MST, Malt) it is really convenient if you don't have to have a suite of conversion scripts and you can just expect them to input/output the (now increasingly standard) CoNLL-U format. :)

Thank you for your detailed request and interest in BIST Parser. I have added support of conll-u format in the graph-based parser for now (the transition-based parser will be upgraded soon too). Could please check if it is working ok on your end? (Simply pass the conll-u files instead of the old conll file. The graph-based parser can now parse both conll and conll-u formats seamlessly).

Thanks! Your way of dealing with it is much more elegant than mine was going to be :)
I tried it, it seems like there are still some problems:
$ python src/parser.py --dynet-seed 123456789 --outdir /tmp --train ~/data/ud-treebanks-conll2017/UD_Finnish/fi-ud-train.conllu --dev ~/data/ud-treebanks-conll2017/UD_Finnish/fi-ud-dev.conllu --epochs 30 --lstmdims 125 --lstmlayers 2 --bibi-lstm
[dynet] random seed: 123456789
[dynet] allocating memory: 512MB
[dynet] memory allocation done.
Using external embedding: None
Preparing vocab
Traceback (most recent call last):
  File "src/parser.py", line 57, in <module>
    words, w2i, pos, rels = utils.vocab(options.conll_train)
  File "/home/UT/source/bist-parser/bmstparser/src/utils.py", line 34, in vocab
    for sentence in read_conll(conllFP):
  File "/home/UT/source/bist-parser/bmstparser/src/utils.py", line 54, in read_conll
    tokens.append(ConllEntry(int(tok[0]), tok[1], tok[2], tok[4], tok[3], tok[5], int(tok[6]) if tok[6] != '_' else -1, tok[7], tok[8], tok[9]))
ValueError: invalid literal for int() with base 10: 'Symb'

This diff seems to fix the problem:
$ git diff
diff --git a/bmstparser/src/utils.py b/bmstparser/src/utils.py
index 52bbf79..e9efff7 100644
--- a/bmstparser/src/utils.py
+++ b/bmstparser/src/utils.py
@@ -43,12 +43,12 @@ def read_conll(fh):
     root = ConllEntry(0, '*root*', '*root*', 'ROOT-POS', 'ROOT-CPOS', '_', -1, 'rroot', '_', '_')
     tokens = [root]
     for line in fh:
-        tok = line.strip().split()
-        if not tok:
+        tok = line.strip().split('\t')
+        if not tok or line.strip() == '':
             if len(tokens)>1: yield tokens
             tokens = [root]
         else:
-            if tok[0] == '#' or '-' in tok[0] or '.' in tok[0]:
+            if line[0] == '#' or '-' in tok[0] or '.' in tok[0]:
                 tokens.append(line.strip())
             else:
                 tokens.append(ConllEntry(int(tok[0]), tok[1], tok[2], tok[4], tok[3], tok[5], int(tok[6]) if tok[6] != '_' else -1, tok[7], tok[8], tok[9]))

I think the problem is because .split() splits on both tabs and spaces and CoNLL-U only allows tabs as column delimiters.

Thanks! I integrated the diff you suggested and I hope it is working now. I will apply the same changes to the transition-based parser, and hopefully you could use it with conll-u data very soon.

Added conll-u support for transition-based parsing too..
It seems to be working on my end. I would appreciate if you could check if it is working for you too.
Thanks again!

Great, thanks! :) I've just checked it and it seems to be working fine (at least it's training). I'll train a whole model and get back to you when I've tested it end to end.

The model trains fine, I get some errors with the eval script.
Use of uninitialized value $head_g in string eq at src/utils/eval.pl line 1456, <SYS> line 39536.
Use of uninitialized value $head_g in numeric le (<=) at src/utils/eval.pl line 1462, <SYS> line 39536.
Use of uninitialized value $head_s in string eq at src/utils/eval.pl line 1465, <SYS> line 39536.
Use of uninitialized value $head_s in string eq at src/utils/eval.pl line 1469, <SYS> line 39536.
Use of uninitialized value $head_s in numeric le (<=) at src/utils/eval.pl line 1475, <SYS> line 39536.
Argument "joka" isn't numeric in numeric le (<=) at src/utils/eval.pl line 1462, <SYS> line 39630.
Argument "joka" isn't numeric in numeric le (<=) at src/utils/eval.pl line 1475, <SYS> line 39630.
Use of uninitialized value $head_g in string ne at src/utils/eval.pl line 1446, <SYS> line 39630.
Use of uninitialized value $head_s in string ne at src/utils/eval.pl line 1446, <SYS> line 39630.
Use of uninitialized value $dep_g in string ne at src/utils/eval.pl line 1447, <SYS> line 39630.
Use of uninitialized value $dep_s in string ne at src/utils/eval.pl line 1447, <SYS> line 39630.
Use of uninitialized value $head_g in string eq at src/utils/eval.pl line 1452, <SYS> line 39630.

The prediction also seems to work fine:
$ wc -l ~/data/ud-treebanks-conll2017/UD_Finnish/fi-ud-dev.conllu
22403 /home/UT/data/ud-treebanks-conll2017/UD_Finnish/fi-ud-dev.conllu
$ wc -l /tmp/test_pred.conll
22403 /tmp/test_pred.conll

I changed the eval script for conll-u from the old eval script to the new script used by the conll 2017 shared task. The error messages you experienced should disappear now.

All works on my end :) I had to hack the transitions to disallow multiple roots (see multiple root issue #10) so that the ud eval does not fail but all else works fine! Elegant solution as Fran said :)


Faith on the march

After installing it, I can't find it in JWlib

Like everything else, it should be in:
Library > DOWNLOADED > Guidelines

Hi @shonind
Did you get this resolved?

Ho yes, sorry, I forgot to check in the ENGLISH language


Code fix: SA1610 (PropertyDocumentationMustHaveValueText)

Implement a code fix for #130.
Normally it is not possible to generate the text for a documentation element. However, in many cases where the <summary> text for a property follows a particular form (e.g. the form prescribed in #143 and #144), the <value> text can be filled in using a slightly reworded variant of the summary text. A concrete example of this, although targeted to the documentation requirements of a particular SDK, can be seen in openstacknetsdk/OpenStackNetAnalyzers#6.

:bulb: Since this is also functioning as a code fix for SA1609 (#129), the code fix should be able to insert an empty <value></value> element in the documentation even if the initial text cannot be derived from the summary element text.


Bump gh-pages to 0.0.11

Updated the gh-pages with the changes from 0.0.10 and #11. As this assumes, that #11 gets merged, I skipped a version-number.
Changes:

Updated examples.html, _examples.scss and shapes.html
Removed font-files that are no longer necessary
Added an animation to the example-signs on the landing page

Thank you!


Add filters to find all tests in one run which don't have any result in another

Though, not sure if this will help much. What do you think @jgraham ?

This makes sense; it would presumably be a status of "missing", which would match on the result being NULL.


Switching language mode to Python on an unsaved file throws "Module path should be rooted"

On the old LS in release:
Opening document untitled:Untitled-1
[Error - 10:48:38 AM] Request textDocument/completion failed.
  Message: unknown document
  Code: -32000
   at Microsoft.Python.LanguageServer.Implementation.ProjectFiles.GetEntry(Uri documentUri, Boolean throwIfMissing) in C:\Users\jabaile\python-language-server\src\LanguageServer\Impl\Implementation\ProjectFiles.cs:line 53
   at Microsoft.Python.LanguageServer.Implementation.ProjectFiles.GetEntry(TextDocumentIdentifier document, Nullable`1 expectedVersion, ProjectEntry& entry, PythonAst& tree) in C:\Users\jabaile\python-language-server\src\LanguageServer\Impl\Implementation\ProjectFiles.cs:line 59
   at Microsoft.Python.LanguageServer.Implementation.Server.Completion(CompletionParams params, CancellationToken cancellationToken) in C:\Users\jabaile\python-language-server\src\LanguageServer\Impl\Implementation\Server.Completion.cs:line 34
   at Microsoft.Python.LanguageServer.Implementation.LanguageServer.Completion(JToken token, CancellationToken cancellationToken) in C:\Users\jabaile\python-language-server\src\LanguageServer\Impl\LanguageServer.cs:line 301

The file gets opened, but doesn't seem to get added anywhere, nor analyzed. This may also be causing exceptions on file updates which I'm not sure are logged in the output panel.
To reproduce (same as #597):

Open a new file in VSC, do not save.
Use the command palette to change the language mode to Python.
Try to use the analysis (completion, hover, etc).

That was fixed with https://github.com/Microsoft/python-language-server/pull/837

Yup, this was the issue for the old LS (which is now defunct).


Pinned intersphinx_mapping for Django to version 1.10

Occasionally, Django documentation references change; this will prevent unexpected breakage of links.
Also, we don't support Django's master branch, so we should refer to the latest supported release instead (currently 1.10).

Coverage remained the same at 82.604% when pulling 209eb9bc51840bb721a79841240e9c6aed5578cf on evildmp:docs-conf into 1ef83443e7d8be8439ae1f04bb9460246f000eb0 on divio:release/3.4.x.


A simple fix for OLD code paths.

In iter_unpack The code is always checking OLD  it would be better to change this to:
if OLD:
    def iter_unpack(raw):
        """Yield successive 24-sized chunks from message."""
            return chunks(raw)
else:
    def iter_unpack(raw):
        """Yield successive 24-sized chunks from message."""
            return struct.iter_unpack(EVENT_FORMAT, raw)

Now the OLD vs NEW check is only performed at file load, not on each function call.
Sorry for not making a pull request.

Thanks very much, good tip.


[BEAM-13524] Fixed grammar error in Go ParDo function comments.

Updated comment of ParDo function in Golang sdk.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: lostluck

R: @lostluck


WIP: move scope lesson to start of functions & scope module

Description

Related Issues

@suzicurran I'm going to close this pull request for now. Please let me know if you'd still like to work on this!


Use Wrangler secrets for basic auth?

The docs examples for basic auth store the basic auth username and password in the index.ts in plain text, which is not ideal since it will be visible in the code base. An alternative is to use the Wrangler secrets command to store these as an environment variable with a slight modification to the auth code:
app.use('*', async (c, next) => {
  const auth = basicAuth({
    username: c.env.BASIC_AUTH_USERNAME,
    password: c.env.BASIC_AUTH_PASSWORD
  })
  return await auth(c, next)
})

Storing the secrets can be done with:
echo 'supersecretpassword' | npx wrangler secret put BASIC_AUTH_PASSWORD

Is there any reason this approach should not be taken or that it's not recommended?

Hi @cd-slash !

Is there any reason this approach should not be taken or that it's not recommended?

No! It's better to use environment variables. Your way is correct.
In the "Blog" example, the same way is used:
https://github.com/honojs/examples/blob/main/blog/src/index.ts#L13
middleware.use('/posts/*', async (c, next) => {
  if (c.req.method !== 'GET') {
    const auth = basicAuth({ username: c.env.USERNAME, password: c.env.PASSWORD })
    return auth(c, next)
  } else {
    await next()
  }
})

(However, this code is old and may need to be improved. Regardless, your code is correct!)

Thanks! I created this PR in the docs repo to show an example of this as it took me quite a while to work it out, so it may be helpful to others.

I think this can be closed.


Consul config doesn't need "http://"

Traefik automatically adds it. If you specify it, it causes an error.

Thanks! LGTM

LGTM :stuck_out_tongue_closed_eyes:


do we need more than one suit of reference psnr

./full run test/ffmpeg-vaapi/encode/avc.py -k bframes=0,case=4k2013,gop=30,profile=main,qp=51,quality=1,slices=3
on ICL:
psnr =  25.6864, 39.3725, 39.5874, 28.0653, 41.1952, 40.7418
on KBL:
psnr =  26.8123, 38.7912, 38.7007, 28.5433, 40.9245, 40.3934
use one as reference then the other will fail.

Yes ,  the PSNR are the same every time .

Are the PSNR's different when comparing gstreamer runs on KBL vs. ICL?

run the same case
ffmpeg-qsv
ICL ： 25.6564, 39.3784, 40.1553, 30.1983, 41.9603, 42.2321
KBL ：26.9046, 38.807, 38.9301, 30.7088, 41.6305, 41.7316
gst-vaapi
ICL :   25.6864, 39.3715, 39.6011, 28.0653, 41.1934, 40.7443
KBL  : 26.8123, 38.794, 38.7266, 28.5433, 40.9229, 40.4032
gst-msdk
ICL :  25.6511, 39.3511, 40.3076, 33.4652, 45.7268, 46.4823
KBL :  26.9368, 38.9324, 39.2732, 34.0295, 45.3923, 46.0265
seems have similar phenomena

@zhuqingliang thanks for the info.  Are there a lot of test cases failing due to this phenomena?  Does it only happen with specific encode parameter settings (e.g. slices=3 and/or profile=main, etc)?
There would be high maintenance overhead to manage separate PSNR reference files on a per-platform basis.  So if we can avoid that, it would be ideal.  Maybe we can increase the PSNR tolerance on a per-case basis?
@lizhong1008 can you check with driver team about expectations for ICL vs KBL quality differences?

this two parameter also have this phenomena.
cqp/test(bframes=0,case=4k2013,gop=30,profile=main,qp=51,quality=1,slices=3
cqp/test(bframes=0,case=480p,gop=100,profile=main,qp=51,quality=4,slices=1
and reference + 0.2 is good for most of the case.  These case with the same
phenomena are less than 1% in all test, maybe we can just adjust the ref to fit most of the platform.

Please move this issue to internal suite repo as it only relates to those cases/references.  We can discuss more there.


For issue 1367 Spring FastJsonHttpMessageConverter Support ParamterizedType and TypeVariable

Spring FastJsonHttpMessageConverter Support ParamterizedType and TypeVariable
Fixes #1367

Codecov Report

Merging #1372 into master will decrease coverage by 0.1%.
The diff coverage is 37.83%.

@@             Coverage Diff              @@
##             master    #1372      +/-   ##
============================================
- Coverage     85.71%   85.61%   -0.11%
- Complexity     5581     5586       +5
============================================
  Files           131      131
  Lines         19575    19610      +35
  Branches       4371     4382      +11
============================================
+ Hits          16779    16789      +10
- Misses         1811     1830      +19
- Partials        985      991       +6

Impacted Files
Coverage Δ
Complexity Δ

...baba/fastjson/support/spring/FastJsonJsonView.java
89.47% <ø> (ø)
32 <0> (ø)
:arrow_down:

...n/support/spring/FastJsonHttpMessageConverter.java
75.55% <37.83%> (-14.45%)
39 <8> (+6)

...fastjson/support/jaxrs/JerseyAutoDiscoverable.java
60% <0%> (-20%)
2% <0%> (ø)

...n/java/com/alibaba/fastjson/util/JavaBeanInfo.java
89.38% <0%> (-0.27%)
135% <0%> (-1%)

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 1af975f...baf8c8c. Read the comment docs.


Multiple AWS accounts support + SG count fix + route count fix

Hi, this is the proposal to add multiple AWS account support via ~/.aws/ folder and config files. Currently it breaks backwards compatibility, but I can fix it, if you are OK with those changes.
Routes were not calculated propely, Quota in AWS only applied to user created routes, not all routes. We also had routes created by VPG, and this is not goes into quota.
Also security groups count was not working as it should. AWS data structure is misleading, for example if you have multiple network masks for sg['IpPermissions'] it actually counts as number of networks not as one rule upon quota.

@brennerm @kedoodle @mgreschl @dbermuehler


doc modify the release verify doc

Proposed changes
Change github id to apache id.
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


"Unresolved P/Invoke method" warnings when compiling for ARM64

Visual Studio 2017 15.9 was just released with full support for ARM64 UWP platform.
I've tried to build some of my apps targeting ARM64 but noticed these warnings, when my apps consume Newtonsoft.Json NuGet. These warnings are not produced when I don't reference Newtonsoft.Json NuGet.
Expected behavior
The expected behavior is no P/Invoke warnings when compiling UWP app for ARM64.
Actual behavior
These warnings are shown when compiling for ARM64 with Newtonsoft.Json v 11.0.2 and UWP NuGet 6.2.2.
1>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\Microsoft.NetNative.targets(792,5): warning :       MCG : warning MCG0007: Unresolved P/Invoke method 'advapi32.dll!LsaNtStatusToWinError' for method 'System.UInt32 Interop.Advapi32.LsaNtStatusToWinError(System.UInt32)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisfy those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.
1>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\Microsoft.NetNative.targets(792,5): warning :       MCG : warning MCG0007: Unresolved P/Invoke method 'advapi32.dll!LsaLookupSids' for method 'System.UInt32 Interop.Advapi32.LsaLookupSids(Microsoft.Win32.SafeHandles.SafeLsaPolicyHandle, System.Int32, System.IntPtr[], Microsoft.Win32.SafeHandles.SafeLsaMemoryHandle, Microsoft.Win32.SafeHandles.SafeLsaMemoryHandle)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisfy those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.
1>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\Microsoft.NetNative.targets(792,5): warning :       MCG : warning MCG0007: Unresolved P/Invoke method 'advapi32.dll!LsaLookupNames2' for method 'System.UInt32 Interop.Advapi32.LsaLookupNames2(Microsoft.Win32.SafeHandles.SafeLsaPolicyHandle, System.Int32, System.Int32, Interop.UNICODE_STRING[], Microsoft.Win32.SafeHandles.SafeLsaMemoryHandle, Microsoft.Win32.SafeHandles.SafeLsaMemoryHandle)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisfy those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.
1>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\Microsoft.NetNative.targets(792,5): warning :       MCG : warning MCG0007: Unresolved P/Invoke method 'advapi32.dll!LsaOpenPolicy' for method 'System.UInt32 Interop.Advapi32.LsaOpenPolicy(System.String, Interop.LSA_OBJECT_ATTRIBUTES, System.Int32, Microsoft.Win32.SafeHandles.SafeLsaPolicyHandle)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisfy those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.
1>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\Microsoft.NetNative.targets(792,5): warning :       MCG : warning MCG0007: Unresolved P/Invoke method 'advapi32.dll!LsaClose' for method 'System.Int32 Interop.Advapi32.LsaClose(System.IntPtr)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisfy those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.
1>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\Microsoft.NetNative.targets(792,5): warning :       MCG : warning MCG0007: Unresolved P/Invoke method 'advapi32.dll!LsaFreeMemory' for method 'System.Int32 Interop.Advapi32.LsaFreeMemory(System.IntPtr)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisfy those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.

Steps to reproduce
Create new UWP project, add Newtonsoft.Json package, switch to ARM64/Release and try to build the project.

This is a known issue caused by the Windows SDK forgetting to ship a SupportedApis-arm64.xml file that helps the .NET Native compiler resolve P/invoke entrypoints. This can be worked around by adding UseExactSpelling=true to the p/invoke declaration, but I see this repo doesn't actually declare this p/invoke, so the fix would probably be in a different NuGet package. I'll ask around to see what's the status of this issue.

@MichalStrehovsky Was having problems setting UseExactSpelling=true in my own app experiencing the same issue. Turns out it's actually, ExactSpelling=true


Fix Footnote Link Display

Fixing this current display for links that are part of footnotes
Current

Proposed fix - showing link formatting

Great stuff! Thank you.


[TC-S-2.5, 2.6] Yaml script has to be updated as per Test plan and VS document.

Description:

[ ] TC-S-2.5

In script Precondition step has to be updated as per test plan.

In test step 4b, 5b Log has to be updated as per VS document.

Test plan References:

https://github.com/CHIP-Specifications/chip-test-plans/blob/master/src/cluster/scenes.adoc#test-setup-3

YAML script References:

https://github.com/project-chip/connectedhomeip/blob/master/src/app/tests/suites/certification/Test_TC_S_2_5.yaml

Verification step document:

https://docs.google.com/spreadsheets/d/13zltSz50GRs_kidvobceEuIT8kAAHSK64ANyWcc3xQI/edit?gid=1845308885#gid=1845308885&range=139:139

[ ] TC-S-2.6

In Precondition has to be updated as per Test plan.

Test plan References:

https://github.com/CHIP-Specifications/chip-test-plans/blob/master/src/cluster/scenes.adoc#test-setup-4

YAML script References:

https://github.com/project-chip/connectedhomeip/blob/master/src/app/tests/suites/certification/Test_TC_S_2_6.yaml

Addressed in PR:
https://github.com/project-chip/connectedhomeip/pull/35054


Query for Post request

Hi, is there way to override config to generate Query for requests with method POST instead of mutation.

@wengergruppe, thank you for your question. Currently, Qraft doesn’t support transforming operations from one method (e.g., mutation) to another, and we don’t have any plans to add such functionality.
If you’re looking to modify your OpenAPI Document by changing the operation type (e.g., from GET to POST), you might need to use a third-party OpenAPI transformation tool.
I’ll mention @hkosova here, who might be able to suggest some tools or workflows to help with this kind of transformation.

Closed due to lack of response.


add version tag to docker deployment script

Hi,
for identify and should we redownload the script for deployment, is that possible to add the version tag or change info into the script, so that we can easy to identify the script has any config update?
thanks
Regards,
Lawes

@laweschan You can edit the $HOME/.firezone/docker-compose.yml file to lock the firezone/firezone image to a specific version if you wish. This file is not overwritten on upgrade.


[Bug]: Canadian prices have dollars as unit but the values are in cents

The problem
Basically what the title says. The sensor reports the unit of measure as CAD or CAD/Liter depending on the settings, but the price gets reported in cents. So the sensor reports values like 149.9 CAD. It should be 1.499 CAD.
What version of Home Assistant?
core-2024.9.1
What version of GasBuddy?
1.0.11
Diagnostics information
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response

Same for me, just to add to Justin's comment, include diagnostic information, maybe you can divide by hundred when the unit of measurement is cents per liter
"data": {
"station_id": "160353",
"unit_of_measure": "cents_per_liter",
"currency": "CAD",
"latitude": 45.3715,
"longitude": -73.5174,
"regular_gas": {
"credit": "masskazy",
"price": 145.9,
"last_updated": "2024-09-16T18:27:57.481Z"
},

Thank you very much! I can finally afford fuel again 😄

But that's not how gas is reported at the pump, so why is this an issue?

Price at the pump is reported in cents per liter, so 149.9¢. This is equivalent to $1.499, the value that is now reported by the sensor. It is however not at all equivalent to $149.9, which was the number previously reported by the sensor.

Gotcha. While it doesn't denote with the dollar sign per se, I see what you mean in the inconsistency with how something in "CAD" should mean dollars.
I'll see about opening a separate issue or PR related to this, as the fix in #78 was a breaking change without being properly labeled as such. Messing with the value of the state rather than changing the unit_of_measurement can completely break automations/scripts for folks running 1.0.11 or older. It also ruins the history graphs, as all historical data post-update is now an order of magnitude lower.
I think this should have instead been addressed toward the unit_of_measurement field. By default, the state should be the unmodified (expected) value from the GasBuddy API. If the user wants the dollar value like 1.499, that sounds like a feature for the existing Display precision setting in the entities' configurations.

In my case, I have stations in Canada and US, so I have USD/gallons and CAD/liters values, so values like 3.37 USD/gallons and 1.449 CAD/liter, in the version before the fix I had 144.9 CAD/liter. CAD represents Canadian dollars. I think our problem is that Home Assistant does not recognize the cent per liter and converts it to dollars per liter, The fix provided by Chris is perfect and fixes the problem. Because 144.9$ is a bit expensive for me.
Thanps Chris


fix(aarch64): invalid skip number

Codecov Report
Attention: Patch coverage is 0% with 14 lines in your changes missing coverage. Please review.

Project coverage is 51.95%. Comparing base (9e5bbc5) to head (7ef0232).
Report is 4 commits behind head on main.

Files with missing lines
Patch %
Lines

internal/decoder/optdec/helper.go
0.00%
10 Missing :warning:

internal/decoder/optdec/node.go
0.00%
3 Missing :warning:

ast/decode.go
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #712      +/-   ##
==========================================
+ Coverage   51.85%   51.95%   +0.10%
==========================================
  Files         130      127       -3
  Lines       11020    10881     -139
==========================================
- Hits         5714     5653      -61
+ Misses       4971     4907      -64
+ Partials      335      321      -14

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

🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests


Question about pandas DataFrame conversion

Hi,
In my use case, I have data sets in parquet/CSV format which I then read into a pandas dataframe for processing.
Before starting to use ArrayFire Python, I would like to know if the following operations are at all supported.

Reading a dataframe, with its headers into an ArrayFire equivalent data structure
Reading a CSV, with its headers into an ArrayFire equivalent data structure
Writing an ArrayFire equivalent data structure into a dataframe, with its headers
Filtering as follows:

X_df['Rx_10G_1G'] = X_df.apply(lambda x: findGE(x['NE_OBJECT']), axis=1)
def findGE (str_ne):
    if str_ne.find('10GE-') !=-1:
        return 10000
    if str_ne.find('GE-') !=-1:
        return 1000
    else:
        return 1

Filtering as follows:
X_df=X_df[X_df['Rx_Octets']> 0.0]
x_neg_df=X_df[X_df['RxUtilization_pct']< 0]

Sorting by a time stamp based index:
X_df = X_df.sort_index(by='ReportTime')

Many thanks,

@QuantScientist ArrayFire does not support data frames as of now.

Thanks,
How about np array to AF array?
The documentation states:

But I get an error while trying this syntax:

@QuantScientist you need to use af.to_array(array_foo)

@QuantScientist Where did you find that documentation in the screenshot?

From "Matrix computations on the GPU with ArrayFire
for Python and C/C++"
Where did you take the example you quoted?

@QuantScientist That's from a few years ago and outdated. Please use the documentation from here:
arrayfire.org/arrayfire-python

Where did you take the example you quoted?
From memory :) I wrote the function.