text:
weird exception

TypeError: Cannot read property 'findOne' of undefined
  at [object Object].MongoStore.get (/root/idlebot/src/modules/idle/node_modules/express-brute-mongo/index.js:37:13)
  at [object Object].<anonymous> (/root/idlebot/src/modules/idle/node_modules/express-brute/index.js:82:15)
  at keyFunc (/root/idlebot/src/modules/idle/node_modules/express-brute/index.js:49:41)
  at [object Object].<anonymous> (/root/idlebot/src/modules/idle/node_modules/express-brute/index.js:57:3)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/route.js:100:13)
  at Route.dispatch (/root/idlebot/src/modules/idle/node_modules/express/lib/router/route.js:81:3)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:234:24
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:559:15
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:186:14)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:191:16
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at Function.proto.handle (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:165:3)
  at router (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:34:12)
  at Layer.handle [as handle_request] (/root/idlebot/src/modules/idle/node_modules/express/lib/router/layer.js:82:5)
  at trim_prefix (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:270:13)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:237:9
  at Function.proto.process_params (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:312:12)
  at /root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:228:12
  at Function.match_layer (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:295:3)
  at next (/root/idlebot/src/modules/idle/node_modules/express/lib/router/index.js:189:10)
  at /root/idlebot/src/modules/idle/node_modules/body-parser/lib/read.js:107:5
  at IncomingMessage.onEnd (/root/idlebot/src/modules/idle/node_modules/body-parser/node_modules/raw-body/index.js:136:7)
  at IncomingMessage.g (events.js:199:16)
  at IncomingMessage.EventEmitter.emit (events.js:104:17)
  at _stream_readable.js:898:16
  at process._tickCallback (node.js:343:11)

This is quite the stack trace.
I'd venture to guess that the cause of your exception would be a lack of proper error checking when getting a collection from the database to make sure that no error occurred during the fetching.
Basically, you experienced some kind of database failure and the library you were using did not safeguard against it to handle that gracefully.
If I decide to use express-brute, I'll take a good look at the code and see if I can spot where it could have occurred.

Cannot read property 'findOne' of undefined

Is not a db failure,this library expect a collection object but instead he passed undefined. I should do a better handling of this and throw a more descriptive error

Thanks for the feedback.
I should be more rigorous with bad input handling from programmers in my libraries as well.

authors: Magnitus- jfromaniello seiyria


text:
🛑 Andreas Iten is down

In 010169b, Andreas Iten (https://www.andreasiten.ch) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Andreas Iten is back up in fa1a232.

source: gharchive/issue

repo: authentiqdigital/upptime

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 Jenkins is down

In f34fdc6, Jenkins (https://jenkins.rajlabs.in/login) was down:

HTTP code: 403
Response time: 63 ms

Resolved: Jenkins is back up in a9dfc7a after 15 minutes.

repo: authoritydmc/uptime-status


text:
optimize version?  python, cuda, cudnn

What should be the python version and the cuda and cudnn versions to utilize autodistill?

Hello @bulgam! All autodistill models should run on a CUDA GPU by default if one is available. We don't presently have the ability to specify if you want to use GPU or CPU. Rather, if a CUDA GPU is available, it is used; otherwise, the CPU is used.

I am closing this issue since there have been no more questions. If you need more assistance, feel free to re-open the Issue!

authors: bulgam capjamesg

repo: autodistill/autodistill


text:
Getting this Error : Unhandled Rejection (TypeError): (0 , p.exec) is not a function

I have used the both sync and async version of function , but no luck in getting Machine Id . Getting the error as mentioned in title at the time of starting the React Dev Server .

I also had the same problem,AHHHHHHHHH !

same problem

Yes same here.

yes me too

I had the same problem.
try a solution!!!
replace import by require
I made it!

authors: AnmolChhabra98 Nerdary Tanbo123456 benbowler simplesmall wudidehuangtiandi

repo: automation-stack/node-machine-id


text:
load_incremental() does not communicate partial success

If a load_incremental() has some valid changes and some corrupt data this is not surfaced to the user.  While applying what changes are valid seems like the correct course we should communicate this information.  The current return value of load_incremental() is the number of ops loaded - this isn't very useful information.
My proposal:
if the data has zero  valid changes - return an error
otherwise return the number of valid bytes processed - if the data was totally valid this will equal the length of the buffer passed in

What should load() do in the case of a partial load?

Good question. An all-or-nothing (atomic) approach might be easiest to understand: that is, if an error occurs anywhere, the function should return an error and leave the document unmodified, like a transaction abort in a database.
However, an alternative argument would be that we should try and recover as much as we can of a corrupted file. That would allow a storage model where an app simply appends changes to a file on the filesystem, and if a crash occurs halfway through writing a change, we can still read most of the file and only need to ignore the incompletely written change at the end. This is similar to what a database would do with the WAL on recovering from a crash.
Your proposal of returning the number of bytes processed would satisfy the latter use case, and it would allow the storage layer to truncate the file to keep the portion of the file that is intact, and discard everything from the corrupted record onwards. That may of course lead to data loss, but arguably it would lose less data than refusing to load the file entirely, so maybe that's better?
For load() I think you could take the same approach of returning the number of bytes successfully loaded. This would make sense especially if the data being loaded contains a mixture of a compressed document and a bunch of changes that have been applied on top of it, or even two compressed documents that have been concatenated.

My proposal would be to have load_incremental() return the number of bytes loaded (in rust and js) as its current return value isn't very useful to anyone and I dont think it'll be missed.  load() on the other hand would be burdened with a more complex return type.  My thought would be not to change the return type by add a public bytes_loaded field on a doc (which would be 0 for docs created instead of loaded) and allow users to access this value (rather than having to unpack a tuple every time they load a doc).

authors: ept orionz

repo: automerge/automerge-rs


text:
Unexpected behavior of th command "aut validator info --validator" when the address is not a validator

When we use the command "aut validator info --validator" with an address which is not a validator it returns this response:
{
"treasury": "0x0000000000000000000000000000000000000000",
"addr": "0x0000000000000000000000000000000000000000",
"enode": "",
"commission_rate": 0,
"bonded_stake": 0,
"total_slashed": 0,
"liquid_contract": "0x0000000000000000000000000000000000000000",
"liquid_supply": 0,
"registration_block": 0,
"state": 0
}
It should return that the address is not a validator instead of this response.

shipped in v0.2.0

authors: jfaiza noandrea

repo: autonity/aut


text:
testInstrumentationRunner dependencies are not recognized

Plugin version
1.19.0
Gradle version
7.5
reason output for bugs relating to incorrect advice
UnusedDepdencies
Describe the bug
This plugin does not recognize dependencies where the classes used are referenced solely in the build.gradle. For example test runner classes used for testInstrumentationRunner will not be recognized and will be removed as unused, but this will cause tests to fail.

Thanks for the issue. Can you provide a minimal reproducer?

https://github.com/Vichy97/Dependency-Analysis-Minimal-Repro/tree/issue_873 If you checkout issue_873 branch and run ./gradlew fixDependencies you will see it remove the dependency on module_b which causes tests to fail

Cloning the repo and running buildHealth, the report says
> Task :buildHealth
Advice for :module_a
Unused dependencies which should be removed:
  androidTestImplementation(project(":module_b"))

I'm making this comment just to note that the issue appears before fixDependencies -- the advice is to remove the dependency, which fixDependencies simply follows. With this reproducer, I ought to be able to fix the issue. Thanks!

@Vichy97 should your :module_b actually be androidTestRuntimeOnly? Since it's not used at compile time, I think that makes sense. Could you double-check in your project?


text:
FOV in the data

Hello,
I have question regarding the FOV of the data.
For training data generation, three cameras with a FOV of 60° each are used. The Images are concatinated and cropped to 704x160.
In inference, we have three cameras with a FOV of 120° which are cropped to a third in each dimension. This is done because there are distortions in the cameras for inference (#171). But wouldn’t the cropping to a third result in three images with a horizontal FOV of 40° each, which are then concatinated? Even if there are no distortions in the camera in inference, I tested and the images fit perfectly together.
Thank you!

But wouldn’t the cropping to a third result in three images with a horizontal FOV of 40° each, which are then concatinated?

Nope, cropping the center third of a 120° camera yields a 60° FoV (try drawing it with a pinhole camera model).
Degrees are not evenly distributed along the image.

Thank you for the very fast reply, this makes sense!
Is there a reason why the distorted cameras are used in the inference?

Because it is mandatory on the leaderboard 1.0 test server to use the distorted cameras.

repo: autonomousvision/transfuser


text:
GrammaticalMarkersPerLanguage -- CaseMarkerExpressedCategoriesCount

CaseMarkerExpressedCategoriesCount from GrammaticalMarkersPerLanguage lists 74 languages labelled as expressing 0 categories. This seems odd, as this implies that these languages have a case marker that does not even express the category case.

This also has implications for the variable CaseMarkerExpressesMultipleCategories, as the langauges with "0"

A parallel issue is happening with NounPluralMarkerExpressedCategoriesCount from GrammaticalMarkersPerLanguage which has 73 languages labelled as expressing 0 categories.

authors: annagraff nataliacp

repo: autotyp/autotyp-data


text:
Collect training/test data for object detection for Bus ODD

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I've agreed with the maintainers that I can plan this task.

Description
Collect the data to train and test perception pipeline for Autoware.Universe
Purpose
We have to evaluate if perception pipeline in Autoware.Universe is enough to do a demo for Bus ODD.
Possible approaches
Collect rosbag of sensors using ITRI's Bus.
Definition of done

[ ] #680
[x] collect rosbag of sensor data for lidar

@xmfcx as disscussed in last WG meeting, the data has been collected. Shall I use this issue or you would like to create the subtask "collect rosbag of sensor data for lidar".

LiDAR data has been provided in#562

@xmfcx close this once the rosbags are uploaded to s3

https://autowarefoundation.github.io/autoware-documentation/main/datasets/

authors: Sharrrrk mitsudome-r xmfcx


text:
Torchvision model transforms missing

If I compare the original AlexNet with our configuration, it appears like we are completely missing the transforms that are mentioned. This is also true for all other torchvision models.
This could lead to serious problems with the models as we give them a vastly different input space.
I will investigate and upgrade to a bug if this is indeed missing.

Adding the following seems to substantially improve model performance on some local data (basically going from NaNs to modest performance comparable to the state of the art).
id: AlexNet-T-v2
_target_: autrainer.models.TorchvisionModel
torchvision_name: alexnet
transfer: true

transform:
  type: image
  base:
    - autrainer.transforms.Resize:
        height: 224
        width: 224
    - autrainer.transforms.ScaleRange:
      order: 90
    - autrainer.transforms.Normalize:
        mean: [0.485, 0.456, 0.406]
        std: [0.229, 0.224, 0.225]

I might be missing something here because there are some stuff happening under-the-hood with this match model dataset stuff
@ramppdev @millinma do you have any insights?

So you are referring to the model input size and normalization?
Some time ago we opted to not include them on the model side and make the dataset-side responsible for providing features that are suitable.
The intention behind this choice was that since model transforms take precedence over dataset transforms, it is easier to use them for spectrograms, as these are usually not square.
The only exception are models that can only work with a specific input resolution (e.g. models without GAP) which have the resolution fixed on the model side.

Hm, don't remember the decision and the discussion that led to it..
I think it is quite dangerous to have the models there without the input transforms they need, especially the ones with T. They're not really plug-and-play if they're missing the key input transform.
As for the dataset, it shouldn't be "responsible" for providing features that fit a specific model, as the model is now responsible for carrying its own transform. E.g., AlexNet expects an "image" and then should take care of resizing, normalizing, etc...
P.S. Is this a legacy decision from the time where we had coupled dataset-model transforms?

P.S. Is this a legacy decision from the time where we had coupled dataset-model transforms?

Yes, exactly. Back then we had no way of combining all datasets with all models, and then opted to store these transforms in the model, say a "hypothetical" CIFAR-10 image dataset would then be compatible with all models to the same degree we can just throw any spectrogram dataset at it.

I think it is quite dangerous to have the models there without the input transforms they need, especially the ones with T. They're not really plug-and-play if they're missing the key input transform.
As for the dataset, it shouldn't be "responsible" for providing features that fit a specific model, as the model is now responsible for carrying its own transform. E.g., AlexNet expects an "image" and then should take care of resizing, normalizing, etc...

These are all valid points, but if we would store the expected default transformations for all models, it is inevitable that users have to override the models for basically all of our audio datasets. But i am not sure what the best solution is atm.

it is inevitable that users have to override the models for basically all of our audio datasets

Why? I basically have exactly the opposite problem...I have to go in and add those transforms to all models.

Maybe it could be an option to add models with and without transformations? In cases like resizing and normalisation, it shouldn't even matter if they are defined and applied twice?
I also see for instance an issue when we use EfficientNet that expects a 224 x 224 input. For a dataset like CIFAR10 I think it should rescale to the required input, but for the mel spectrogram version of DCASE2020-Task1A, which comes at 64 x 1001, I don't think the same rescaling should necessarily be applied?

Why? I basically have exactly the opposite problem...I have to go in and add those transforms to all models.

My answer would be what Manuel said, e.g. what happens if we want to use an input size of 64 x 1001 from DCASE2020? Would you prefer to override the model input shape iff you decide to use a non standard one? This perspective now also makes sense to me.

Resizing is one part of the transform that should be, perhaps, configurable.  I think this depends on the model architecture. As most models come with a global pooling layer at the end, and primarily rely on convolutions, it is fine to skip this step.
But I also think normalization is critical. Most of the models first scale to [0, 1] and then standardize using the ImageNet mean/std. I think this is quite important.
I am not sure how to handle this. I don't think it's wise to bloat the package with more configurations. We already have enough as it is..

At this point we need a DSL for handling transformation pipelines :D
I also dont have a good solution, and yeah adding more and more model configs wont be great.

Alright, I'll try to think of something for a later release. For now, it's mainly us 3 using the package, (+@AlexanderGbd) who should be mindful of this

I did a quick experiment on some data I've been using for a local project. It's a regression task and I am reporting Pearson's cc. Below I show the result without (left) and with the range scale + normalization transform (right). I did not add resize+crop as this wouldn't account for the variable length problem.
AlexNet-T -- 0.104 | 0.002 |
ConvNeXt-Base-T -- 0.154 | 0.360 |
ConvNeXt-Large-T -- 0.208 | 0.361 |
ConvNeXt-Small-T -- 0.095 | 0.253 |
ConvNeXt-Tiny-T -- 0.267 | 0.256 |
EfficientNet-B0-T -- 0.285 | 0.319 |
ResNet-50-T -- 0.175 | 0.184 |
Swin-B-T -- 0.050 | 0.221 |
Swin-S-T -- 0.031 | 0.069 |
Swin-T-T -- 0.136 | 0.104 |
VGG-11-T -- 0.020 | 0.076 |
VGG-13-T -- -0.056 | 0.088 |
VGG-16-T -- -0.163 | -0.097 |
VGG-19-T -- 0.086 | 0.003 |

It seems to improve for some models, but not all. I guess this means it's "safe" to leave the transform defaults in their present form. I might set a student to investigate this more closely in the future.

Okay, sounds like a good solution to me.

Audio data? I have the feeling that the impact here is generally pretty small for ImageNet normalization from what i have observed in the past, basically got the same conclusion on DCASE2020 (or 2016, dont remember).
Some time ago, Manuel also ran an experiment with an without scaling + normalization and the impact was actually very small.
The actual input size should have the highest impact on performance, but it would feel too restrictive for an audio first toolkit to enforce the original input sizes of the models.

authors: ATriantafyllopoulos millinma ramppdev

repo: autrainer/autrainer


text:
at or near "@": syntax error

How can I add ts_vector query support?
It's choking on WHERE to_tsvector(unaccent(name)) @@ to_tsquery('portuguese', ':*')

Can you provide the full SQL?
Which database and version does this SQL run on?

It's from the extension pg_trgm
Runs on postgres 9.6+
SELECT
	*
FROM
	movies
WHERE
	to_tsvector( unaccent ( NAME ) ) @@to_tsquery( 'portuguese', 'star:*' )

yeah, i have the similar problem
SELECT * FROM table_name WHERE column1 @@ '$.key == "value"'

I have the same problem using the tsvector and tsquery syntax
error: could not parse sql string: at or near \"@\": syntax error"

authors: DrakoRod auxten localhosted mal-mel

repo: auxten/postgresql-parser


text:
maven plugin: #567 Followup, Simplify ServiceLoader of InjectPlugin

I don't why we have the .filter() and ::cast for the service loading here, seems unnecessary and can simplify.

I'll merge this in an release the 10.0-RC4 of the maven plugin.

source: gharchive/pull-request

repo: avaje/avaje-inject


text:
Fileinfo: VisualBasic header parsing + P-Code detection

Visual Basic can be compiled into binary or P-Code - bytecode for VB virtual machines. Add VBHeader parsing and dumping to fileinfo. Description.
How to do it:

When Visual Basic is detected, look at EP where should be push offset 0x????????. VBHeader should be at this offset. Some of its records are pointers to other structures (e.g. ProjectInfo).
Add detection of P-Code (aNativeCode == 0), tag the input as bytecode, warn users that decompiling this is not a good idea.

This might help: https://github.com/SekoiaLab/pe-tools
Also some pictures from IDA where these structures were defined and used:

I am closing the issue as it has been implemented in #440.

repo: avast-tl/retdec


text:
Feature/ajuste codigos

[FIX] Correção no teste do metodo encomenda e cep, pois ambos não estavam funcionando;
[NEW] Ajustes no setup.py, para que o mesmo mesmo reconheça o diretório de teste. Agora os testes podem ser executador com python setup.py test;
[FIX] As variaveis PAC, SEDEX, SEDEX_10 e etc. agora são atributos de classe. Esse ajuste possibilitar usar esses valores sem precisar criar um objeto Correio(), como estava sendo feito e torna o código mais Orientado a Objeto;
[FIX] Formatação de determinadas partes do código a fim de melhorar a legibilidade do código.

Essa semana gero um release com a sua atualização

authors: avelino mstuttgart

repo: avelino/pycorreios

license: mit

license_source: bigquery


text:
Remove {@inheritDoc} from overridden methods

Note that /** {@inheritDoc} */ is essentially pointless if no comments are added to it, because the API documentation is taken from the super implementation for years already when an @Override is present. Since we enforce @Override for both method extension and interface implementation, the 'bare' {@inheritDoc} comments can be removed.
The regular expression ^ */\*\* \{@inheritDoc\} \*/\R being replaced with nothing removes all lines with /** {@inheritDoc} */.
Note that we can change the way checkstyle behaves for our projects by editing the /checks/dsol-checks.xml file in the main pom project. In line with the documentation for the DesignForExtension module, we should specify the check to allow methods which have @Override annotations to be designed for extension:
    <module name="DesignForExtension">
      <property name="severity" value="warning"/>
      <property name="ignoredAnnotations" value="Override"/>
    </module>

The DesignForExtension module also interferes with the checkstyle module JavadocMethod, which ensures that every method and constructor has appropriate Javadoc. It does, however, exclude @Override methods by default, as specified in https://checkstyle.sourceforge.io/checks/javadoc/javadocmethod.html. This check is executed for interfaces and classes, and therefore guarantees that the 'root' methods have appropriate javadoc.

Applied on the dsol code base.

repo: averbraeck/dsol


text:
Imports in XML not parsed

When parsing from XML, the included definitions such as GTU types, are not parsed. Current simulations are running by the grace of OtsNetworks being created with default types, and all those simulations using default types. The created types happen to create a whole separate set of types, who's id's and parent structure matches with the default types. In overview:
Imported types (default) from XML: not generated
Default types in code: used in simulations
Default types in OtsNetwork: created with matching id's and parent structure

I'm wondering whether the spf variable in the code below (from XmlNetworkLaneParser) does anything. There seems to be no relation with 'jc' or 'unmarshaller'.
        JAXBContext jc = JAXBContext.newInstance(OTS.class);
        Unmarshaller unmarshaller = jc.createUnmarshaller();
        SAXParserFactory spf = SAXParserFactory.newInstance();
        spf.setXIncludeAware(true);
        spf.setNamespaceAware(true);
        spf.setValidating(true);
        return (OTS) unmarshaller.unmarshal(xmlURL);

Good question. It might set a number of parameters that are used in the parsing, but the way it has been coded it looks like it is doing nothing indeed. I will check.

The way it is programmed right now, it does not do anything because it is indeed not connected. The SaxParserFactory part can be safely deleted as far as I can see. In case we want to use a SaxReader with the JAXB contexts at some point, we could use the tips in https://stackoverflow.com/questions/10890323/using-sax-with-jaxbcontext. Right now that does not seem needed.

There is a parseXML(final URL xmlURL) method, in which the includes do not work. It has the above code. There is also parseXML(final InputStream xmlStream) in which the includes do work. It has very similar code, but explicitly uses the SAXParserFactory part. See TrafCodDemo2 on how the working method is used.

SAXSource saxSource = new SAXSource(xmlReader, new InputSource(xmlURL.openStream())); seems to do the trick. It translates the URL in to an InputStream.

Replacing the entire method with return parseXML(xmlURL.openStream()); fixed it.

authors: WJSchakel averbraeck

repo: averbraeck/opentrafficsim


text:
Performance Benchmarks

When using regularization, the training doesn't scale very well with the increase in batch size:
All the benchmarks use the models from here and use Tracker.jl

Batch Size
Vanilla NODE forward
Vanilla NODE backward
Reg NODE forward
Reg NODE backward

1
0.285 ms
3.193 ms
0.315 ms
5.920 ms

64
1.067 ms
5.475 ms
1.147 ms
37.768 ms

256
3.360 ms
11.872 ms
3.671 ms
140.085 ms

Proper Benchmarks available in the paper


text:
Aim
Python script to get song lyrics or find a song from a snippet of it's lyrics, and more.
Details

User can write the lyrics and get the song
User can enter the song name and get the lyrics

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSoC'23 contributor
[X] I want to work on this issue

GO Ahead @sabhisharma-ise

authors: avinashkranjan sabhisharma-ise

repo: avinashkranjan/Amazing-Python-Scripts


text:
DOC: Fixing broken links

What's wrong with the existing documentation

Added admins all 3 social links
Added gssoc link in the open source projects section

Add ScreenShots
As visible in the bottom

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'23 contributor
[X] I want to work on this issue

Since I have added 4 links and also 2 distinct things, so can it be level2 issue?

/assign

repo: avinashkranjan/Friday


text:
Enhance Application Name Generation

We'd like to see the following application naming options:

Default (Prefix (user defined), App Name, Suffix (environment))
Options to disable prefix and suffix (2 separate options)
Option to override application name completely - Property to be passed to deployer from CI for example
Full app name will always be made lower case

Create a class 'ApplicationName' that has the following attributes:

baseAppName (artifact id from pom usually - if not defined)
prefix
suffix
usePrefix (boolean)
useSuffix (boolean)

authors: TimGonz-AVIO kkingavio

repo: avioconsulting/mule-deploy-library


text:
When a new folder is created, the returned object does not contain all properties, like the folder name or description

eg:
>>> from fossology import Fossology
>>> fossology = Fossology(server='http://localhost:8085/repo/',  auth={'username':'fossy', 'password':'fossy', 'token_expire':'2019-09-07', 'token_scope':'write'})
>>> top_folder=fossology.folder(folder_id=1)
>>>
>>>
>>> new_folder=fossology.new_folder(folder_name='untitled', parent_folder=top_folder)
>>> type(new_folder.folder_name)
<class 'NoneType'>        #  <----- This should be a string with value 'untitled', as passed
>>>

Fixed by 3364d3b

repo: avneetkalsi/py-fossology


text:
Use correct namespace on StatusCode enum

I use the CMake FetchContent to retrieve this library in my project. I'm trying out the example code for 30x redirects, but it didn't compile. I found out the code is missing the namespace.
main.cpp:16:43: error: ‘StatusCode’ has not been declared
         if (response.get_status_code() == StatusCode::MovedPermanently ||
                                           ^~~~~~~~~~
main.cpp:17:43: error: ‘StatusCode’ has not been declared
             response.get_status_code() == StatusCode::Found)

My CMakeLists.txt:
# Download external dependency
FetchContent_Declare(
    Cpp20HttpClient
    GIT_REPOSITORY https://github.com/avocadoboi/cpp20-http-client.git
)
FetchContent_MakeAvailable(Cpp20HttpClient)

# Link HTTP Client for C++20
target_link_libraries(${PROJECT_TARGET} Cpp20HttpClient::cpp20_http_client)

Interesting, in the example I used using namespace http_client;, so I don't understand why you are getting that error. It compiles fine on gcc 13.2.0 at least. I don't have anything against removing the using namespace and adding the qualifiers in the example code though.

No worries, thanks a lot for submitting these issues and pull requests as I'm not actively using the library myself :)


text:
Upgrade to grunt-babel 5.0.0

Homework.

This cascades through turtle.io, & tenso.

repo: avoidwork/keigai


text:
Refactor parsing

I think a quick(ish) refactor of the parsing modules could pay dividends in the future. Currently the parsing logic looks through a string and extracts based on string manipulation. Then in the same context, the parsing function determines what type of translation should be used for each of the plucked strings (lets call them ‘atoms’).
What I propose is a lightweight framework that predefines ‘atoms’ as a regular expressions. This allows for multi-worded atoms to be searched for with the same amount of effort as any normal encoded/non-encoded atom. Each atom can be predefined and a translator is responsible for translating/decoding each atom into whatever. This way, each module can just build the atoms it expects to find in whatever it’s going to translate, add them to translators that decode even the most complicated ones (this will allow for those awful ones like tornados and what not), and then in the parser modules, you’d never have to change anything and can add as many handlers as you want.
An example in the remarks could be
PEAK_WIND = r”””
\bPK WND
(?<direction>\d{3})
(?<velocity>\d{2,3})
/
(?<hours>\d{2})?  # rarely present
(?<minutes>\d{2})
\b”””

Using that, some class...
class PeakWindAtom(Atom):
    pattern = PEAK_WIND
    search(str) -> match or None
    __contains__(str) -> bool

would be used by
class PeakWindHandler(AtomHandler):
    atom: some Atom
    <<abstract>> can_translate(str) -> bool : atom in is string
    <<abstract>> translate(str) -> str: decode the data

would be used by
class RemarksParser(Parser):
    - handlers: List[handlers]
    + parse(remarks_string) -> Dict[str, str]: raw-decoded pairs
    + add_handler

The patterns and atoms could be reused. And simple ones like ACFT MSHP could be build using a simple factory (so the API doesn’t have to change for simple ones or complex ones). All of your existing decoding logic could stay in place, or slowly be changed to regex group dicts for easier changes.
No tests would need to be changed as far as I can tell. Added tests will be in their own module that you can place wherever you like best before any merge.
I think starting with the remarks module is a good place to start. Before I’d get started and submit a PR, is this something you’d be open to?

Interesting. The parser handling is roughly how I started organizing the PIREP parser, but that's function-based. I'd be interested to see how effective regex will be in extracting remarks elements as those are by far the most open-ended.
My one recommendation with the code above is to compile the regex expression that is assigned to the class. I'm interested to see how that turns out. I've been meaning to split up the avwx._core module into parts and refactor it anyway.

I was tooling around with the idea last night and came to a similar conclusion. I think that only a single class would be needed if you wanted to commit to regex based internals, but a function-based class could be subclassed to share the interface that the handlers would use as well. If that is the case, we should ensure they are implemented to return something immutable when they look for the presence of an atom in a string. And that should reveal the atom's location in the string, so that it can be extracted if you wanted destructive parsing, and the actual raw match from the input string that a handler would use for the translation.
# all subclass searching should be able to make this
class AtomSpan(NamedTuple):
    """
    Finding within a string. Can be used for slicing as `end` is non-inclusive.
    """
    match: Optional[str]
    start: Optional[int]
    end: Optional[int]

class BaseAtom(abc.ABC):
    """Atom represents a single encoded entity in an encoded string"""

    @abc.abstractmethod
    def to_atom_span(self, item: str) -> AtomSpan:
        """Return an `AtomSpan`. If no match found, return `AtomSpan(None, None, None)`"""
        pass

    def is_in(self, string) -> bool:
        """Return True if the atom is in the string"""
        return self.to_atom_span(string).match is not None

Some subclass that uses regex instead of callables
class RegexAtom(BaseAtom):
    """Atom defined by regex pattern"""

    def __init__(self, regex_pattern: re.Pattern, name: Optional[str] = None):
        self.regex = regex_pattern
        self.name = name

    @property
    def regex(self) -> re.Pattern:
        return self._regex

    @regex.setter
    def regex(self, regex: re.Pattern):
        if not isinstance(regex, re.Pattern):
            raise TypeError("regex must be a compiled `re.Pattern`")
        self._regex = regex

    @classmethod
    def from_pattern_string(
        cls, pattern: str, *flags: re.RegexFlag, name: Optional[str] = None
    ) -> "RegexAtom":
        """
        Return a new instance of `RegexAtom` from a string pattern.
        :param pattern: string to be compiled into regex pattern
        :param flags: flags to pass to `re.compile`
        :param name: name for repr
        """

        if flags:
            regex = re.compile(pattern, sum(flags))
        else:
            regex = re.compile(pattern)

        out = cls(regex, name=name)

        return out

    def to_atom_span(self, string: str) -> AtomSpan:
        """
        Search the string for the atom
        """
        match = self.regex.search(string)
        if match:
            start, stop = match.span()
            return AtomSpan(match=match.group(), start=start, end=stop)
        return AtomSpan(None, None, None)

    def search(self, string: str) -> Optional[re.Match]:
        """
        Return `re.Match` object or None
        """
        return self.regex.search(string)

and a handler
class RegexAtomHandler:
    """Handle the individual translation of an atom"""

    def __init__(
        self, atom: "RegexAtom", translation_callable: Callable[["Match"], str]
    ):
        self.atom = atom
        self.translation_callable = translation_callable

    def __repr__(self):
        return f"{type(self).__name__}(atom={self.atom!r})"

    def __call__(self, *args, **kwargs):
        return self.translate_atom(*args, **kwargs)

    @property
    def translation_callable(self):
        return self._translation_callable

    @translation_callable.setter
    def translation_callable(self, new_callable: Callable[["Match"], str]):
        if not callable(new_callable):
            raise TypeError("translation_callable must be a callable")
        self._translation_callable = new_callable

    def can_handle(self, atom_string: str) -> bool:
        """Return True if handler is qualified to handle translation"""
        return self.atom.is_in(atom_string)

    # todo: allow for default error handling option
    def translate_atom(self, string: str) -> str:
        """Perform translation on the atom string"""
        match = self.atom.search(atom_string)
        if not match:
            raise CanNotHandleError(
                f"{self.atom!r} has nothing to translate from {atom_string!r}"
            )
        result = self.translation_callable(match)

        return result

Quick one-one handlers could still use regex with simple strings and keep the regex internals for parsing.
# atom instance
ACFT_MSHP = RegexAtom.from_pattern_string(' ACFT MSHP ')

# handler class code
...
    @classmethod
    def new_simple_handler(cls, atom, translation: str):
        _callable = lambda match: return translation
        return cls(atom, _callable)
...

...
# handler instance code
acft_mshp_handler = RegexAtomHandler.new_simple_handler(ACFT_MSHP, "Aircraft Mishap")
...

# some parser in the remarks.py module
parser.add_handler(acft_mshp_handler)

translations = parser.parse_into_translations(long_remarks_string)  # Dict[str, str]

But with that same client code...
# some patterns module
RVR_PATTERN = re.compile(r"""\b
R(?P<runway>\d{2}[LCR])
/
(?P<plus>\?P)
(?P<visibility>\d{4})
(?P<units>\w{2})?
V?
(?P<upper>\d{4})
(?P<units>\w{2})?
""", re.M)

# remarks module
rvr_atom = RegexAtom(RVR_PATTERN, some_callable_that_uses_the_match)

...

parser.add_handler(rvr_atom)

I think the benefit would be that even though regex is evil incarnate, you could test that pattern with as many variations as you could muster without affecting the parser code. All the translation callable would need is the regex.match object it could call match.groupdict() on and get all of the parsed units out of.

So I did a little tooling around and drummed up a rough stub of a parsing implementation that could sit on top of any new translations you were thinking up. Since you were looking to start parsing the airep soon, would you want to try this out? And/or, would you want to open a branch for the refactoring of the remarks module? I added a few translations for things like Tornado activity and CIG/VIS as secondary locations for a proof of concept.

The AIREP parsing is on hold for now. The PIREP parser is in place, but it is very error prone when it encounters more descriptive report elements. I can put together a list of reports encountered that break the current version.
I can open a refactor branch in the source we can use.

That sounds like a good place to start. If you open one, I can open a PR against it with the rough work I did and we can poke around at it from there. The changes I made to the existing code are really only impactful in that it adds two sub packages. Nothing else is hooked up to the existing parsing code. The tests I wrote were all pytest based, would you prefer them as unittest testcases?

As long as running pytest can discover them, doesn't matter to the CI. I'm not using unittest.TestCase in an optimal fashion right now anyway.
I've added the refactor branch.

repo: avwx-rest/avwx-engine


text:
Use item

There's an issue with MSQ quests where trying to use a quest item on a target displays "invalid target" making it unable to proceed

What is the simplest way to reproduce it? Which quest it was?

What is the simplest way to reproduce it? Which quest it was?

Blank#8888 I'd be able to send a gif to demonstrate, and explain, basically with the mod installed, whatever quest it is, you're unable to use the quest item.

Any quest item that needs to be used on a target can't be used and you get the 'Invalid Target' error. Happened in the Sylph beast tribe quests, WAR job quest and during the MSQ for me.

What are the names of the quests? Sylph in particular should be easy to reproduce. And I need to reproduce it to investigate the reason.

The Sylph one is called 'Feed Me' and the WAR one is called 'The Bear Necessity' which you can replay with the NG+ feature I guess, so that's easy.

Interesting, do you by chance have a similar problem with MOAction addon? Apparently it's the hack I've lifted from it that is causing this...

Should be fixed, please try new version...

authors: AserAlmighty awgil vrBlanky


text:
Reworked interrupt hint

reworked interrupt hint to make showing a name optional

All of that code just for the name? A lot of that is duplicated.
I think it would be much simpler to add a name as an explicit hint, where it makes sense (eg if you have several mobs active and it's important who to interrupt). I know that localization could be an issue, but tbh I don't really care, as the plugin doesn't handle localization properly anyway, and I'd prefer consistency to having only small bits localized here and there.

Ok I reworked the hint again, it is much shorter now
maybe we should look into adding more localisation options instead of not doing any

authors: CarnifexOptimus awgil


text:
Problems with pipelineFunctions in AppSync

How did you install the Amplify CLI?
yarn
If applicable, what version of Node.js are you using?
v18.12.1
Amplify CLI Version
10.5.2
What operating system are you using?
Debian
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
none
Describe the bug
Hi, I am using the documentation specifically for Extend Amplify-generated resolvers https://docs.amplify.aws/cli/graphql/custom-business-logic/#supported-resolver-slots, but I have errors in the creation of the pipelines functions inside appSync as shown in the following image of the project code.

You may notice that the displayed resources do not have the same information.
The queries are mixed up with the mutations.

I have another project with a similar case, however the only way to prevent this error is to use the Amplify CLI Version 8.3.0 with this version the pipelineFunctions are generated correctly.
Expected behavior
That each function belongs to its corresponding category.
Reproduction steps
1.- amplify push
Project Identifier
Learn more at https://docs.amplify.aws/cli/reference/diagnose/
✅ Report saved: /tmp/testamplify/report-1671766871682.zip
✔ Done
Project Identifier: a6aa7472df30643338c4f9766531972e
Log output

# Put your logs below this line

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

Hi @eliecer2000  - thank you for raising this issue. I think what you're seeing is a side effect of function consolidation which is performed for AppSync functions to reduce the overall function count in a stack, we alias identical functions together, but as you've pointed out that can cause a confusing experience.
Similarly, if your custom resolvers have identical logic, you may see that those are aliased to the same name to reduce the number of resolvers created.
This is a bit of a rough edge, and can lead to confusion as you're seeing. I'll tag this as a feature request to improve the naming here if possible.

repo: aws-amplify/amplify-category-api


text:
Passing dynamo table names to lambda function

Note: If your question is regarding the AWS Amplify Console service, please log it in the
official AWS Amplify Console forum

** Which Category is your question related to? **
lambda function
** What AWS Services are you utilizing? **
Lambda, Cognito, AppSync GraphQL
** Provide additional details e.g. code snippets **
I need a Lambda function to implement some backend logic. In this code I need to access the tables created by the graphQL schema.
My question is how can I pass the table names to the lambda function, taking account that the table names changes from one environment to another.
In fact what it will be ideal, is that when creating a record in a table, then with a pipeline resolver call the function with the correct table names. As I understand the pipeline resolvers are not yet supported, So im planning calling both functions from my angular app.
How can I access the table names from my angular app?

Hi, @sergiorodriguez82, there is a PR #1215 open to export the table name.
Meanwhile, you can use something like this is your template, for example, te pass the table name as an environment variable to the Lamda.
"Environment": {
  "Variables": {
    "TABLE_NAME": {
      "Fn::Sub": "Todo-[GraphQLApiId]-${env}"
    }
  }
},

Todo - replace it with the name of your model.
[GraphQLApiId] - replace it with the name of your GraphQL API ID.
${env} - is a parameter passed to the template, so, no need to change it.
For the GraphQL API ID, there is a feature request #1099 open to pass the value to the Lambdas, so, until it is implemented, we need to hardcoded the GraphQL API ID in the template.
About when creating a record in a table invoking a Lambda, probably what you need is an AWS::Lambda::EventSourceMapping. It will invoke your Lambda when an item is CREATED, UPDATED and DELETED and pass the item in the event. You can use this snippet.
"EventSourceMapping": {
  "Type": "AWS::Lambda::EventSourceMapping",
  "DependsOn": ["LambdaFunction"],
  "Properties": {
    "Enabled": true,
    "EventSourceArn": {
      "Fn::ImportValue": "[GraphQLApiId]:GetAtt:TodoTable:StreamArn"
    },
    "FunctionName": { "Fn::GetAtt": ["LambdaFunction", "Arn"] },
    "StartingPosition": "TRIM_HORIZON"
  }
},

Hope it helps

Thanks for the prompt answer!
I decided to hardcoded the names in the resolver template until the #1099 is done.
Regarding the EventSourceMapping, it sounds right, but again I will need the table names for that request.
To complete my use case information:
I have the following 4 Tables

Objectives: objectives have multiple indexes and multiple measurements
Indexes: belongs to a Objective and have multiple measurements
IndexMeasurements
ObjectivesMeasurements
What I need id whenever an index measurement is created the corresponding objective measurement is created or updated. For this I must get all the indexes and depending on the "weight" of each one I must calculate the corresponding objective measurement.

@sergiorodriguez82 Are you deploying your lambda function via the amplify function category?

@kstro21 Thanks for the helpful tip!
@sergiorodriguez82 Are you deploying your lambda function via the amplify function category?
Yes

In general, I think there should be an easier mechanism to reference (and perhaps tweak) resources created by the transform. I have thought of two mechanisms. Maybe you guys have better ideas.

Allow any custom stack in the stacks/ directory to reference a resource via the CloudFormation Fn::Ref intrinsic function.
Allow a custom stack to overwrite properties on transform resources by providing a resource with the same logical id. As a side effect, this will require the logical ids in all api category stacks to be unique.

There is already logic in the transform that knows how to replace instances of Fn::Ref with corresponding Fn::ImportValue, Fn::ExportValue, and dependsOn expressions. We could use this same logic to allow custom stacks to reference resources resources in other nested stacks as if they were in the same stack (removing the need to worry about messy import/export names). Curious what people think of this?

Not an expert in Cloud Formation, but the first option sounds more "clean". I guess both could work. I think the aws-amplify project rocks! nevertheless when working with the backend api, specially with appsync graphql, this project should keep improving towards making a more easy way for non-cloudformation users in how to create robust backend functionalities.

@sergiorodriguez82 Thanks for the response. The goal is definitely to continue providing simple to use and powerful abstractions that avoid having to write CloudFormation. We provide CFN as an escape route for situations we don't support but #1060 should also provide another route to handle custom, complex use cases.

@kstro21 I do not see where I can define the Environment config in the CustomResources.json template.  When I reference the documentation at https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-appsync-resolver.html  I do not see a place to add it to the template.
Thank you in advance, and I apologize if this is a silly question, I am new to CloudFormation so I am still figuring things out.

Hi, @vlutton, I don't quite understand your question. Probably you will need to share some snippet of what you are trying to do.
Meanwhile, if you are trying to get the Environment in the CustomResources.json template, the value is already injected in a parameter named env, so, all you need to use "Ref": "env" anywhere in your template where you want to use the value, or using Fn::Sub as shown in my example above https://github.com/aws-amplify/amplify-cli/issues/1274#issuecomment-483459091.
Hope it helps

@kstro21 @mikeparisstuff Is there an example of how to use this PR so DynamoDb table name can be accessed in side lambda code? I went to PR link but didn't see any usage instruction on tablename should be used in lambda

@kstro21 @mikeparisstuff Is there an example of how to use this PR so DynamoDb table name can be accessed in side lambda code? I went to PR link but didn't see any usage instruction on tablename should be used in lambda

authors: kstro21 mikeparisstuff sergiorodriguez82 swatipraskar udayraskar vlutton

repo: aws-amplify/amplify-cli


text:
Generated graphql query for @key ignores depth setting

Describe the bug
I accepted the default 2 level depth of generation for queries, mutations and subscriptions. This depth is not being respected by a query generated from a key defined in the schema.
I'm also using mock to develop locally so this means every time I run mock I get an error that the node I need is missing.
Also, because the generated code can't be moved to another directory I'm going to have to create a workaround with different files.
Granted, this adds small steps to my development. But it also slows me down in the beginning stages of a project where I'm trying to iterate quickly and the schema isn't settled yet.
Amplify CLI Version
3.17.0
To Reproduce

create a type with a connection to another type
create a key for the parent type
run codegen statements or mock
see that the connected type is not included in the output

Expected behavior
Include child node in query items
Desktop (please complete the following information):

OS: macOS
Node: v12.10.0

@aireater please update to the latest version of the CLI and share the schema you're trying to use as well as tell us what language/framework you're running codegen against.

I'm generating javascript code.
here's the relevant parts of the schema:
type Customer
  @model
  @key(
    name: "customersByEmail"
    fields: ["email"]
    queryField: "customersByEmail"
  )
{
  id: ID!
  firstName: String!
  lastName: String!
  email: String!
  utility: Utility! @connection
  owner: String
}

type Utility
  @model
{
  id: ID!
  name: String!
  owner: String!
}

and here's the code generated:

export const customersByEmail = `query CustomersByEmail(
  $email: String
  $sortDirection: ModelSortDirection
  $filter: ModelCustomerFilterInput
  $limit: Int
  $nextToken: String
) {
  customersByEmail(
    email: $email
    sortDirection: $sortDirection
    filter: $filter
    limit: $limit
    nextToken: $nextToken
  ) {
    items {
      id
      firstName
      lastName
      email
      owner
    }
    nextToken
  }
}
`;

authors: aireater attilah


text:
Jenkins integration (CI integration)

Is your feature request related to a problem? Please describe.
I am currently using Jenkins to work on new project and automate the CI part of the project. I can't seem to find aws-amplify/cli plugin in Jenkins.
Describe the solution you'd like
A plugin for aws-amplify/cli to use with Jenkins
Describe alternatives you've considered
A way to integrate or use aws-amplify/cli with Jenkins
Additional context
I am not quite sure how to integrate aws-amplify/cli with Jenkins to automate the build and deploy and any of the commands that aws-amplify/cli can do.
I checked the headless mode but I am not sure how Jenkins will understand the amplify commands without installing aws-amplify/cli plugin - which is not available.

@totaland I have typically seen CI systems install the CLI on every build. So you can use npm install -g @aws-amplify/cli to install the CLI as a part of your build step.

@kaustavghosh06 thanks mate it works


text:
amplify mock 'failed to fetch' query

Note: If your issue/bug is regarding the AWS Amplify Console service, please log it in the
Amplify Console GitHub Issue Tracker

Describe the bug
Running a query that returns a ~12kb object takes more than 2 minutes to resolve and terminated with 'failed to fetch`. The query is run locally with amplify mock and the resolver is a lambda function.
When pushing the api and running the query via AppSync console the problem disappears.
Amplify CLI Version
4.19.0
To Reproduce
Steps to reproduce the behavior or terminal output if applicable
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. Mac/Windows/Ubuntu]
MacOs Mojave
Node Version. You can use node -v to check the node version on your system
v12.10.0

Additional context
Add any other context about the problem here.

@mdegrees
A few questions here

Are you seeing this error on the browser?
Is this a full mock? (Mocking the API and the lambda function)
Could you provide a minimal schema and function so that we can try reproduce this issue?

The issue is fixed with CLI version > 4.26.0. Reference issue #4625

authors: SwaySway kaustavghosh06 mdegrees


text:
lint error preventing commits to the repo

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?
yarn
If applicable, what version of Node.js are you using?
v16.1.0
Amplify CLI Version
7.6.23
What operating system are you using?
Ubuntu (WSL2)
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No
Amplify Categories
Not applicable
Amplify Commands
Not applicable
Describe the bug
When I run lint in the project after checkout the latest (without making any code change), I am getting around 18 K lint errors. This prevents me from submitting any features to the repo.
Expected behavior
The default checkout should not give any lint errors.
Reproduction steps

Checkout the repo
Run yarn setup-dev
Run yarn eslint .

GraphQL schema(s)
NA
Log output
eslint log output (last line)

67588 problems (63348 errors, 4240 warnings)
18174 errors and 64 warnings potentially fixable with the --fix option.

Additional information
No response

Hey @vinodsr :wave: thanks for raising this! I would refer to the two lint-fix command in the root package.json for linting purposes, which has recently been updated to run against only changed files.
"lint-fix": "git diff --name-only --cached --diff-filter d | grep -E '\\.(js|jsx|ts|tsx)$' | xargs eslint --fix --quiet",

This command is also ran as a pre-commit git hook:
"pre-commit": "yarn verify-commit && yarn lint-fix"

In the end, we can have ESLint enabled in our editor to catch lint errors as we write, and when we're ready to contribute and commit this command will automatically be run for us. Please let me know if that helps

Thanks for the reply Josef.
I am confused with the lint errors that are not  part of my change. I can’t
commit my change unless I fix about 80+ lint errors in two files. (Not
related to my change)
On Fri, 11 Mar 2022 at 7:18 PM, josef @.***> wrote:

Hey @vinodsr https://github.com/vinodsr 👋 thanks for raising this! I
would refer to the two lint-fix command in the root package.json for
linting purposes, which has recently been updated to run against only
changed files.
"lint-fix": "git diff --name-only --cached --diff-filter d | grep -E '\.(js|jsx|ts|tsx)$' | xargs eslint --fix --quiet",
This command is also ran as a pre-commit git hook:
"pre-commit": "yarn verify-commit && yarn lint-fix"
In the end, we can have ESLint enabled in our editor to catch lint errors
as we write, and when we're ready to contribute and commit this command
will automatically be run for us. Please let me know if that helps
—
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-cli/issues/9962#issuecomment-1065129776,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADQ6OBO7FZ66DLMED2TF7LU7NFJXANCNFSM5QOVLW2A
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Vinod Surendran R
tenthsone.com
tenthsone.com/adspot (new)
tenthsone.com/junk
talk.tenthstone.com [beta]

We recently made a change that would make the linting more aggressive for any files that you would have touched. If you want to ignore the errors, you can still make changes and then patch in the changes you want to stage (git add -p).

I could finally able to push changed using the --no-verify arg.
Thanks

authors: danielleadams josefaidt vinodsr


text:
fix: show warning then delete detached forms

fix: delete detached forms and show warning
Description of changes

On a pre-push show a warning that the detached forms will be deleted. Delete the forms on a post-push event.
Issue #, if available

https://app.asana.com/0/1202185248783861/1203039443118078/f
Description of how you validated changes

Add a custom field to a form in Studio Form Builder based on an existing data model.
Rename the model in the schema.graphql file.
Do an amplify push.
Verify a warning shows that the form with the custom field will be deleted. See attached image.
Verify the push.
Post push the form is deleted.

And I added/updated unit tests.

Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added
[x] Relevant documentation is changed or added (and PR referenced)
[x] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
[x] Pull request labels are added

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #11610 (b555aeb) into dev (930a7ca) will increase coverage by 0.08%.
The diff coverage is 85.52%.

@@            Coverage Diff             @@
##              dev   #11610      +/-   ##
==========================================
+ Coverage   50.20%   50.28%   +0.08%
==========================================
  Files         702      705       +3
  Lines       33935    34000      +65
  Branches     6966     6985      +19
==========================================
+ Hits        17036    17098      +62
- Misses      15421    15424       +3
  Partials     1478     1478

Impacted Files
Coverage Δ

...til-uibuilder/src/event-handlers/handle-PrePush.ts
0.00% <0.00%> (ø)

...til-uibuilder/src/clients/amplify-studio-client.ts
87.71% <75.00%> (-3.87%)
:arrow_down:

...l-uibuilder/src/utils/printDetachedFormsWarning.ts
90.00% <90.00%> (ø)

...-util-uibuilder/src/commands/generateComponents.ts
83.92% <93.75%> (+2.53%)
:arrow_up:

...ibuilder/src/commands/utils/detachedFormCleanup.ts
100.00% <100.00%> (ø)

...amplify-util-uibuilder/src/commands/utils/index.ts
100.00% <100.00%> (ø)

...ilder/src/commands/utils/shouldRenderComponents.ts
57.14% <100.00%> (+3.29%)
:arrow_up:

...c/commands/utils/syncAmplifyUiBuilderComponents.ts
98.30% <100.00%> (ø)

...il-uibuilder/src/event-handlers/handle-PostPull.ts
83.33% <100.00%> (+83.33%)
:arrow_up:

...il-uibuilder/src/event-handlers/handle-PostPush.ts
83.33% <100.00%> (+83.33%)
:arrow_up:

... and 5 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

authors: codecov-commenter letsbelopez


text:
fix(graphql-auth-transformer): add list support for ownerField in subs

support list ownerFields in subscriptions
re #3148
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@182f36c). Click here to learn what that means.
The diff coverage is 72.72%.

@@            Coverage Diff            @@
##             master    #3166   +/-   ##
=========================================
  Coverage          ?   59.37%
=========================================
  Files             ?      254
  Lines             ?    12570
  Branches          ?     2595
=========================================
  Hits              ?     7464
  Misses            ?     4782
  Partials          ?      324

Impacted Files
Coverage Δ

...hql-transformer-core/src/util/getFieldArguments.ts
16.66% <0%> (ø)

...aphql-auth-transformer/src/ModelAuthTransformer.ts
87.19% <88.88%> (ø)

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 182f36c...c1f0363. Read the comment docs.

authors: SwaySway codecov-io


text:
test(cli): add test for resource-status extensions

Description of changes

Increase test coverage of amplify-cli/extensions.
Description of how you validated changes
lerna --scope @aws-amplify/cli run test
Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added
[x] Relevant documentation is changed or added (and PR referenced)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #7744 (c7b3e16) into master (00d6676) will increase coverage by 0.83%.
The diff coverage is 46.06%.

@@            Coverage Diff             @@
##           master    #7744      +/-   ##
==========================================
+ Coverage   51.79%   52.63%   +0.83%
==========================================
  Files         547      547
  Lines       27626    27653      +27
  Branches     5342     5350       +8
==========================================
+ Hits        14308    14554     +246
+ Misses      12326    12116     -210
+ Partials      992      983       -9

Impacted Files
Coverage Δ

...es/amplify-cli/src/init-steps/s0-analyzeProject.ts
40.25% <0.00%> (-1.08%)
:arrow_down:

...chable-transformer/src/cdk/create-cfnParameters.ts
100.00% <ø> (ø)

...r-awscloudformation/src/amplify-service-manager.js
6.48% <0.00%> (-0.07%)
:arrow_down:

...r-awscloudformation/src/amplify-service-migrate.js
10.97% <0.00%> (ø)

...der-awscloudformation/src/configuration-manager.ts
5.49% <0.00%> (-0.06%)
:arrow_down:

...y-provider-awscloudformation/src/push-resources.ts
9.80% <0.00%> (ø)

...vider-awscloudformation/src/utils/admin-helpers.ts
19.60% <0.00%> (ø)

.../src/utils/lambda/populate-lambda-mock-env-vars.ts
0.00% <0.00%> (ø)

packages/amplify-cli-core/src/cfnUtilities.ts
18.75% <50.00%> (+0.10%)
:arrow_up:

...i/src/extensions/amplify-helpers/delete-project.ts
90.90% <50.00%> (ø)

... and 12 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 e00d645...c7b3e16. Read the comment docs.

authors: codecov-commenter fossamagna


text:
Amplify Geo CLI Plugin - Maps and Search

Description of changes

Tagged Release for Amplify CLI Geo category Plugin with Maps and Search features.
Docs PR: https://github.com/aws-amplify/docs/pull/3404
Issue #, if available

Description of how you validated changes
unit and e2e tests
Checklist

[ x PR description included
[x] yarn test passes
[x] Tests are changed or added
[x] Relevant documentation is changed or added (and PR referenced)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

changes reviewed and approved separately.

Not sure if this is the best place to mention Auth Cognito Groups privilege's with regards to Maps.

authors: IsaacTrevino phani-srikar


text:
"parseable" output format isn't easily parseable sometimes

cfn-lint version: (cfn-lint --version): 0.29.4
Description of issue.
This template:
{
  "Resources" : {
    "S3Bucket" : {
      "Type" : "AWS::S3::Undefined"
    }
  }
}

When linted on Windows with: cfn-lint -f parseable -t "C:\Users\mparnisari\Desktop\test.json"
gives one line:
C:\Users\mparnisari\Desktop\test.json:4:7:4:13:E3001:Invalid or unsupported Type AWS::S3::Undefined for resource S3Bucket in us-east-1

If I try to parse this line by doing line.split(':') I get

C
\Users\mparnisari\Desktop\test.json
4
7
4
13
E3001
Invalid or unsupported Type AWS

S3

Undefined for resource S3Bucket in us-east-1

Whereas I expected:

C:\Users\mparnisari\Desktop\test.json
4
7
4
13
E3001
Invalid or unsupported Type AWS::S3::Undefined for resource S3Bucket in us-east-1

I wonder if we should change the : separator to something like , as in CSV.

Changing the spearation token to , just changes the problem, rather than fixing it. It would be better to add an escape character (i.e. \) into the output, and whatever is consuming the output should handle them.
I would imagine the output would look like:
C\:\\Users\\mparnisari\\Desktop\\test.json:4:7:4:13:E3001:Invalid or unsupported Type AWS\:\:S3\:\:Undefined for resource S3Bucket in us-east-1

Changing the separation token to , just changes the problem, rather than fixing it

Agreed. Unfortunately in addition, changing this would be backwards incompatible for anyone who managed to parse the current parseable format. The best solution is probably recommending a better format instead, likely the json format used in the VSCode extension and atom extension. Looks like you landed on the same json format already as well for the JetBrains integration

authors: PatMyron Tro95 miparnisari

repo: aws-cloudformation/cfn-python-lint


text:
Add demo utility functions to the UI component

Establish an initial set of utility functions in the UI component to enable demonstrations. The podinfo application provides lots of these.
Suggested functions:

GET /headers Print the heads of the inbound request
GET /status/{code} Return the given HTTP status code
GET /panic Shutdown the application with an error code
POST /echo Write back the payload sent to it
POST /store Write the payload to a file and return a hash
GET /store/{hash} Return the payload from the file system previously stored

I can work on this.

authors: niallthomson vijayjeevarajaws

repo: aws-containers/retail-store-sample-app


text:
Launch template

Is your feature request related to a problem?
When using EKS node groups the tags are not propagated to the instances. For that you need to specify a launch template.
https://doc.crds.dev/github.com/aws-controllers-k8s/eks-controller/eks.services.k8s.aws/Nodegroup/v1alpha1@v1.0.2
This launch template cannot be created using the controller which makes it unusabled when you need to add dedicated tags
Describe the solution you'd like
launch template should be created using the controller and then referenced using NodeGroup
Describe alternatives you've considered
Crossplane is proposing this feature.

We already have two PRs introducing EC2 Launch templates and Launch templates versions. Once these are merged we can enable cross-controller resources references for this field

authors: a-hilaly speedfl


text:
Ensuring proper resource reconciliation on Repository Creation

Resolves: https://github.com/aws-controllers-k8s/community/issues/1873
TLDR:

Addressed a bug in the ECR controller where Repository Custom Resources (CRs) failed
to create Policy and LifecyclePolicy entries when containing all (possible) fields.
The ECR controller was missing the post sdkCreate hooks; But the resources that
were missing few default-able fields we properly reconciled primarily due to late
initialization, detecting API default values for non-specified fields, causing the controller
to re queue resources after they have been created.
Resolved by adding the necessary hooks to the create path.

Description:
This fix addresses a bug in the ECR controller. When a user submitted a Repository
Custom Resource (CR) containing all fields, the controller failed to create Policy
and LifecyclePolicy entries. However, if one of the fields was missing (excluding
Policy or LifecyclePolicy), the reconciliation process succeeded.
The bug fix was straightforward and intuitive, as it became evident that the controller
lacked the required hook for the create path. However, this raised questions about why
policy and LifecyclePolicy were missing in some specific cases. Our e2e tests
created CRs with isolated fields, such as Policy and LifecyclePolicy, and verified
that these policies were indeed applied to the ECR Repository.
It was evident that the reason these specific cases were successfully reconciled was
due to the correct logic in the update path. This logic ensured that if a Policy or
LifecyclePolicy was missing, an API call was made to update these fields.
The mystery revolved around why these edge cases were reconciled even when we didn't
explicitly request a second reconciliation or requeue of the resource
Debugging:

Our debugging journey began with a review of the logs and a comparison between the logs
of a resource created with all fields and one with only the policy. Surprisingly, the
logs showed a complete aditional reconciliation step, and it wasn't initiated by the controller
itself (no requeue, no drift remediation, no condition). This was puzzling.

To gain deeper insights, we connected the controller to a local clone of the runtime and
added print statements. However, this approach made the logs messier and harder to
interpret. Consequently, we tried to debugging with a go-delve debugger.

Our debugging session took us through the ACK runtime, but the issue didn't originate
there. Instead, it originiated from 'k8s-sigs/controller-runtime.' We cloned it and extended
our debugging to the controller-runtime. There, we discovered that 'c.Do.Reconcile(ctx, req)'
was causing two reconciliations.

Further investigation revealed that 'for c.processNextWorkItem(ctx) {}' was called,
indicating the presence of an extra item in the queue. This item had to be an update
because the first item in the queue was a "create".

The delve debugger showed that we submitted two resources one with only few fields
and the other with all the fields... We then ran a diff on k get repository <repo1/repo2> -o yaml
which revealed a crucial clue: 'metadata.generation' was 1 for the policy+name-only
resource and 2 for the all the fields resource, confirming the update theory.

The controller initiated the resource update because the ECR API returned all fields,
even those not explicitly provided. This behavior prompted the ACK runtime to execute
a patch into the resource spec, incrementing the generation and triggering an update.

Yeah, we know what that late initialisation is a thing, but it completly baited me here...
Signed-off-by: Amine Hilaly hilalyamine@gmail.com
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/lgtm

authors: a-hilaly jljaco


text:
Changed the adaptor to search the entire project for matching composition names instead of just the root folder

What was the problem/requirement? (What/Why)
Projects that had compositions in folders were not rendering.
What was the solution? (How)
The adaptor was only looping through the root folder when searching for compositions. This PR makes it look through the entire project.
What is the impact of this change?
You will now be able to render compositions regardless of if they are organized in a folder or not.
How was this change tested?
I tested with project files that used folders.
Did you run the "Job Bundle Output Tests"? If not, why not? If so, paste the test results here.
No, I don't know what this is.
Was this change documented?
No, it does not need to be documented because it just addresses a bug.
Is this a breaking change?
No

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Merging with https://github.com/aws-deadline/deadline-cloud-for-after-effects/pull/48