i'm getting error

"[Thu Sep 29 2016 23:50:18 GMT-0700 (PDT)] ERROR LOADING PLUGIN homebridge-foscamcamera:
[Thu Sep 29 2016 23:50:18 GMT-0700 (PDT)] Error: Could not locate the bindings file. Tried:
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/build/binding.node
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/build/Debug/binding.node
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/build/Release/binding.node
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/out/Debug/binding.node
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/Debug/binding.node
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/out/Release/binding.node
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/Release/binding.node
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/build/default/binding.node
→ /usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/compiled/4.2.1/linux/arm/binding.node
at bindings (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/bindings/bindings.js:88:9)
at Object. (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/node_modules/ref/lib/ref.js:5:47)
at Module._compile (module.js:435:26)
at Object.Module._extensions..js (module.js:442:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:311:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object. (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/node-opus/node_modules/ogg-packet/node_modules/ref-struct/lib/struct.js:49:11)
at Module._compile (module.js:435:26)"

Reinstall? What version of node are you using?

v4.2.1

node v4.2.1 raspberry pi 3

I only tested it on 6.6. Not sure if that's the ptoblem

okay i will try update my node

I'm getting errors as well:
[9/30/2016, 12:36:27 PM] FoscamAccessory configured with C2_LivingRoom <IP_ADDRESS> 88 3
Unhandled rejection TypeError: Cannot read property 'split' of null
at new RTSPClient (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/RTSPClient.js:22:25)
at new FoscamStream (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamStream.js:21:27)
at FoscamAccessory._createStreamControllers (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:213:26)
at new FoscamAccessory (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:125:14)
at FoscamPlatform.configureCamera (/usr/local/lib/node_modules/homebridge-foscamcamera/index.js:139:22)
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:63:18
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:111:9
at tryCatcher (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/util.js:26:23)
at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:510:31)
at Promise._settlePromiseAt (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:584:18)
at Async._drainQueue (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:128:12)
at Async._drainQueues (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:133:10)
at Immediate.Async.drainQueues [as _onImmediate] (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:15:14)
at tryOnImmediate (timers.js:543:15)
at processImmediate [as _immediateCallback] (timers.js:523:5)
Unhandled rejection TypeError: Cannot read property 'split' of null
at new RTSPClient (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/RTSPClient.js:22:25)
at new FoscamStream (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamStream.js:21:27)
at FoscamAccessory._createStreamControllers (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:213:26)
at new FoscamAccessory (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:125:14)
at FoscamPlatform.configureCamera (/usr/local/lib/node_modules/homebridge-foscamcamera/index.js:139:22)
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:63:18
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:111:9
at tryCatcher (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/util.js:26:23)
at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:510:31)
at Promise._settlePromiseAt (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:584:18)
at Async._drainQueue (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:128:12)
at Async._drainQueues (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:133:10)
at Immediate.Async.drainQueues [as _onImmediate] (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:15:14)
at tryOnImmediate (timers.js:543:15)
at processImmediate [as _immediateCallback] (timers.js:523:5)
I'm running Node v6.7

Try removing and reinstalling with npm install --unsafe-perm -g homebridge-foscamcamera

@luisiam
still the same error
[9/30/2016, 7:07:37 PM] FoscamAccessory configured with C2_LivingRoom <IP_ADDRESS> 88 3
Unhandled rejection TypeError: Cannot read property 'split' of null
at new RTSPClient (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/RTSPClient.js:22:25)
at new FoscamStream (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamStream.js:21:27)
at FoscamAccessory._createStreamControllers (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:218:26)
at new FoscamAccessory (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:125:14)
at FoscamPlatform.configureCamera (/usr/local/lib/node_modules/homebridge-foscamcamera/index.js:139:22)
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:63:18
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:111:9
at tryCatcher (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/util.js:26:23)
at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:510:31)
at Promise._settlePromiseAt (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:584:18)
at Async._drainQueue (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:128:12)
at Async._drainQueues (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:133:10)
at Immediate.Async.drainQueues (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:15:14)
at runCallback (timers.js:574:20)
at tryOnImmediate (timers.js:554:5)
at processImmediate [as _immediateCallback] (timers.js:533:5)
Unhandled rejection TypeError: Cannot read property 'split' of null
at new RTSPClient (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/RTSPClient.js:22:25)
at new FoscamStream (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamStream.js:21:27)
at FoscamAccessory._createStreamControllers (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:218:26)
at new FoscamAccessory (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:125:14)
at FoscamPlatform.configureCamera (/usr/local/lib/node_modules/homebridge-foscamcamera/index.js:139:22)
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:63:18
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:111:9
at tryCatcher (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/util.js:26:23)
at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:510:31)
at Promise._settlePromiseAt (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:584:18)
at Async._drainQueue (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:128:12)
at Async._drainQueues (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:133:10)
at Immediate.Async.drainQueues (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:15:14)
at runCallback (timers.js:574:20)
at tryOnImmediate (timers.js:554:5)
at processImmediate [as _immediateCallback] (timers.js:533:5)
Unhandled rejection TypeError: Cannot read property 'split' of null
at new RTSPClient (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/RTSPClient.js:22:25)
at new FoscamStream (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamStream.js:21:27)
at FoscamAccessory._createStreamControllers (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:218:26)
at new FoscamAccessory (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/homebridge-foscam-stream/lib/FoscamAccessory.js:125:14)
at FoscamPlatform.configureCamera (/usr/local/lib/node_modules/homebridge-foscamcamera/index.js:139:22)
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:63:18
at /usr/local/lib/node_modules/homebridge-foscamcamera/index.js:111:9
at tryCatcher (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/util.js:26:23)
at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:510:31)
at Promise._settlePromiseAt (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/promise.js:584:18)
at Async._drainQueue (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:128:12)
at Async._drainQueues (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:133:10)
at Immediate.Async.drainQueues (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/bluebird/js/main/async.js:15:14)
at runCallback (timers.js:574:20)
at tryOnImmediate (timers.js:554:5)
at processImmediate [as _immediateCallback] (timers.js:533:5)

Can you post your config.json?

`....
}, {
"platform": "Nest",
"token": "c.",
"clientId": "",
"clientSecret": "*",
"code": "",
            "username": "*********",
            "password": "*********"
    }, {
            "platform": "FoscamCamera",
            "cameras": [{
                    "username": "C2_LivingRoom",
                    "password": "*******",
                    "host": "<IP_ADDRESS>",
                    "port": 88,
                    "stay": 0,
                    "away": 14,
                    "night": 13,
                    "gain": 6,
                    "spkrEnable": true,
                    "spkrCompression": true,
                    "spkrGain": 1
            }, {
                    "username": "C2_*****",
                    "password": "******",
                    "host": "<IP_ADDRESS>",
                    "port": 88,
                    "stay": 0,
                    "away": 14,
                    "night": 13,
                    "gain": 6,
                    "spkrEnable": true,
                    "spkrCompression": true,
                    "spkrGain": 1
            }, {
                    "username": "C2_Bedroom",
                    "password": "jumpjigg#79",
                    "host": "<IP_ADDRESS>",
                    "port": 88,
                    "stay": 0,
                    "away": 14,
                    "night": 13,
                    "gain": 6,
                    "spkrEnable": true,
                    "spkrCompression": true,
                    "spkrGain": 1
            }, {
                    "platform": "Camera-ffmpeg",
                    "cameras": [{
                            "name": "Hallway Nest Camera",
                            "videoConfig": {
                                    "source": "re -i rtsp://stream-ire-bravo.dropcam.com/nexus_aac/*****/playlist.m3u8",
                                    "maxStreams": 2,
                                    "maxWidth": 1280,
                                    "maxHeight": 720,
                                    "maxFPS": 30
                            }
                    }]
            }]
    }]

}
`

C2_LivingRoom is actually the username you use to login to the camera?

Yes it is. The other two have similar prefixes. I blocked out the rest of the info with *s 🙂

Should I change the names of the cameras?

Is that the name of the camera or the username to login?

Ah I see what you mean... No, according to the fiscal app that is the "camera account". I'll use the "camera name" instead and see what happens :)

so C2_LivingRoom is the camera account name. Should I be using the "Camera Name" instead?

Camera Name: FoscamC2 LivingRoom
Camera Account: C2_LivingRoom
Password: *******

Selma to go through homebridge setup, but I can't see the cameras loaded in Home app. Adding/Searching for accessories but Home app can't find the cameras.
I think there might be a bug in iOS 10.0.2 or maybe I might have to do a Reset HomeKit Configuration (which I'm trying to avoid).

Do you have homebridge-foscam2 completely removed?

Yes. I've removed previous foscam plugins only using homebridge-foscamcamera

Do you still see the previous accessories in the home app because it may still be in the cache.

Yes, all my previous homebridge accessories are there.
Should I remove homebridge then re-add it you think?
It's either that or I have to reset my HomeKit config (last resort)

I mean previous foscam accessories, other accessories are fine.

No. no previous foscam accessories.
Only homebridge-foscamcamera
And homebridge-camera-ffmpeg plugins are part of my setup.
I will try to remove my accessory plists. Maybe that will help

May be you can try running a clean home ridge with foscamcamera plugin only on your test server to see if it works
Regards,
Luis Iam.
On Sat, Oct 1, 2016 at 1:34 PM -0700, "leoneleone"<EMAIL_ADDRESS>wrote:
No. no previous foscam accessories.
Only homebridge-foscamcamera
And homebridge-camera-ffmpeg plugins are part of my setup.
I will try to remove my accessory plists. Maybe that will help
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I'll need some time to setup homebridge on a new pi.
will get back to you by monday.
Thanks for all your help 😊

@luisiam thanks for the new homebridge for foscam. i was able to install in may Mac. and all working good. just one question.
the stream only doing VGA quality? how i can change video quality? because after use the home app and look the camera the stream quality in other app change to VGA. is possible use the sub stream instead of main stream?

Glad that it finally works. You may want to thank you @planetbeing since he wrote the entire library for streaming. I just put everything together 😀
It is set up to  choose the best resolution based on the connectivity. If I am on WiFi, it always streams at 720p. If I am on LTE, it always streams at VGA. If you want to limit to sub stream only, you can put
"maxMainStreams": 0
to the config.json. maxSubStreams works too if you want it vice versa.

the problem is i use other app on iPad for my q-see DVR and foscam and the and the foscam picture become low quality after i look on the home app. be great if we can chose SUB or MAIN Stream for homekit.

Just add "maxMainStreams": 0 to the config.json. It will tell iOS that main stream is not available and force iOS to choose sub stream.

I did and no pic

What did you see on the log? Is iOS requesting for streaming?
Regards,
Luis Iam.
On Mon, Oct 3, 2016 at 6:27 PM -0700, "toshibochan"<EMAIL_ADDRESS>wrote:
I did and no pic
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.

Strange thing happens to may mac. 2 days ago i update the node to 6.7.0 and your plugin was working. But yesterday I reboot the Mac and now node showing 4.2.1. I uninstall all node and install again but still showing old node

Same thing happens to my PI 3. I going to reinstall all again and test

I will let you know how works after reinstall
Thanks again for make great things for make or live fun!

Interesting. My node version never roll back to previous version. I am staying on 6.7.0 now and everything is nice and smooth

I don't know what happens!!! Super strange!

Hello I managed to install the plugin but when running the home bridge I get this error message and I have no clue where the problem might be.
Unhandled rejection StatusCodeError: 404 - 404 Not Found
404 Not Found
File not found.

at new StatusCodeError (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/request-promise/lib/errors.js:26:15)
at Request.RP$callback [as _callback] (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/request-promise/lib/rp.js:68:32)
at Request.self.callback (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/request/request.js:187:22)
at emitTwo (events.js:106:13)
at Request.emit (events.js:191:7)
at Request.<anonymous> (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/request/request.js:1048:10)
at emitOne (events.js:96:13)
at Request.emit (events.js:188:7)
at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/homebridge-foscamcamera/node_modules/request/request.js:969:12)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:974:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)

I would appreciate any help.
Thanks

Can you give us more info?

HomeBridge version.
Node version.
Camera model.
Your config.json

Sure.

HomeBridge version - 3.10.8

Node version - v6.7.0

Camera model -  EasyN F-series

Config.json:
{
"bridge": {
"name": "Evil-Base",
"username": "C4:23:3C:A3:CE:30",
"port": 51826,
"pin": "025-42-666"
},
"description": "EVIL-BASE",
 "platforms": [
  {
 		"platform": "HarmonyHub",
 		"name": "Living Room Harmony Hub"
  },

  {
  	"platform": "PhilipsHue",
  	"name": "Philips Hue",
  	"ip_address": "<IP_ADDRESS>",
 			"username": "9aL6krZwqhSEvXupnz5pOkFDff-NiSJfQhqoRoxt"
	 },
  {
 	 "platform": "FoscamCamera",
 		"cameras": [
 			{
 				"username": "admin",
 				"password": "passwd1",
 				"host": "<IP_ADDRESS>",
 				"port": 80,
 				"stay": 0,
         		"away": 14,
         		"night": 13,
         		"gain": 6,
         		"spkrEnable": true,
         		"spkrCompression": true,
         		"spkrGain": 1
 			}
 		]
   },
   {
     "platform": "FHEM",
     "name": "FHEM",
     "server": "<IP_ADDRESS>",
     "port": "8083",
     "filter": "room=Homekit"
   }

]

}
Everything works on the HomeBridge excepting the Camera.
Thanks again for you help.
PS. It is running on a Raspberry Pi.

This plugin won't support any other camera. It only supports Foscam camera

This camera is Foscam compatible and implements the API

I don't know if the API is the same across foscam and easyn. You can just use this plugin as is. I cannot provide any support since I don't own any easyn cameras.

Thanks anyway.


AST data structure

@rheum, what do think about a specialized tree structure for ASTs? Additional features could be a scope that you can set per node to create references. Additional reference pointers in every node, that can be set and special API functions that make the handling of an AST easier. E.g. set_references, … Just all features that are needed by most ASTs.
Tell me what you think.

We will build an own library for that including other compiler related tools.


[Search v2] [App] Create advanced filters

Implement this section of the design doc.
Holding on:

[ ] https://github.com/Expensify/App/issues/45025

cc @adamgrzybowski @Kicu @WojtekBoman

Maybe for this one we can break it down into multiple PRs, maybe adding a couple of filters at a time

yeah sounds good 👍
Let me take care of this task, and I will start with small initial PR, after that if I see possibility of some parallel work, then we will divide this between me and Wojtek if that would make sense.
However I have a question: where do I get the values of some filters from? In, Currency, Merchant - are they somewhere inside Onyx easy to be used?
What about:

Tax
report ID
Category
Tag

And in general: should these filters values mostly be generated inside App using existing data, or come from backend?

These values should come from Onyx for now. So:

in
currency - reuse CurrencySelectionList component, data source
merchant - text input, user can enter whatever they want
tax - policy_<id>.tax. Maybe we can reuse TaxPicker
category - policyCategories_. Maybe we can reuse CategoryPicker
tag - policyTags_. Maybe we can reuse TagPicker

For tax, category and tag we need to combine the data from all policies available in Onyx. I think to reuse the components as is, we might have to lift that Onyx connection and pass the data.

Ready to be worked on!

Will start today, possibly bring 1 more person in because I feel this task can be done in parallel.

Reassigning as I'm heading on leave 🙇

Will continue working on this task to bring in more PRs together with @Guccio163
There are multiple filters to display so expect maybe 2-3 more PRs.

asked a question here: https://docs.google.com/document/d/1G53Ebwl1XJx2ea2c0WO3rg1DmpGK8D0sMCRWvAM3D1o/edit?disco=AAABOsNsBWg
if someone can take a look 🙏

@Kicu replied

Payment summary:

@rayane-djouah $250 - offer sent in Upwork

Paid ✔


A way to know in-editor if sub-resources are unique or not

Hi, if you duplicate for example an AnimationPlayer its sub-resources remain linked and on the editor there is no way to determine if the sub-resources are unique or not. The only way now is to check the .tscn file.
So I was thinking that perhaps a good solution for this would be to show the list of sub-resources ids used by the node on the Inspector, I could try to implement this as well but I would like to know first if you agree with this or not :)

There is no need, sub-resources are never unique, always shared.
On Tue, Aug 23, 2016 at 1:06 PM, Marcelo Fernandez<EMAIL_ADDRESS>
wrote:

Hi, if you duplicate for example an AnimationPlayer its sub-resources
remain linked and on the editor there is no way to determine if the
sub-resources are unique or not. The only way now is to check the .tscn
file.
So I was thinking that perhaps a good solution for this would be to show
the list of sub-resources ids used by the node on the Inspector, I could
try to implement this as well but I would like to know first if you agree
with this or not :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6258, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2-OMeZMBhZredmqPbPHHOfnvnTi4ks5qixqGgaJpZM4JrGhp
.

I see, the "Make Sub-Resources Unique" button is a bit confusing then. Could a unique flag be implemented for sub-resources?

Make sub-resources unique just makes a copy, they are never unique
On Wed, Aug 24, 2016 at 8:49 AM, Marcelo Fernandez<EMAIL_ADDRESS>
wrote:

I see, the "Make Sub-Resources Unique" button is a bit confusing then.
Could a unique flag be implemented for sub-resources?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6258#issuecomment-242036591,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2zYSZ5D3qSpCyvjVpDXuFO2iLy1Kks5qjC_fgaJpZM4JrGhp
.

Maybe the text could be better, I'm not exactly sure what it could say.
I was considering adding a flag to make resources unique for the scene, but
that would still not solve your problem I guess.
On Wed, Aug 24, 2016 at 9:03 AM, Juan Linietsky<EMAIL_ADDRESS>wrote:

Make sub-resources unique just makes a copy, they are never unique
On Wed, Aug 24, 2016 at 8:49 AM, Marcelo Fernandez <
<EMAIL_ADDRESS>wrote:

I see, the "Make Sub-Resources Unique" button is a bit confusing then.
Could a unique flag be implemented for sub-resources?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6258#issuecomment-242036591,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2zYSZ5D3qSpCyvjVpDXuFO2iLy1Kks5qjC_fgaJpZM4JrGhp
.

It would be nice to have that flag implemented, and then the flag is shown on the gui and issue solved :)

It would be relatively easy to do, but It would only work for resources
that are directly placed on a node..
On Wed, Aug 24, 2016 at 9:11 AM, Marcelo Fernandez<EMAIL_ADDRESS>
wrote:

It would be nice to have that flag implemented, and then the flag is shown
on the gui and issue solved :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6258#issuecomment-242040828,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z27x6U6oitFOqt7p248M9oI_KXISKks5qjDT_gaJpZM4JrGhp
.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


Can't use variants inside @apply in Svelte components

Describe the bug
Trying to use the variants with apply in Svelte component

#98


Negative memory usage?

Running the benchmarks in ipfs-log gives me

looks like global.gc() is never called due to how expose-gc is imported.
It looks like according to expose-gc usage we should either use the global import and use global.gc() or import it as a function assigned to a local variable. What it looks like is happening right now is we are mixing them up, importing as a function and looking for the global variable.


Windows When logged out of wallet, existing key in Create Wallet form

When logging out of a wallet and going to 'create wallet' the key form is populated with the old wallet key.
This makes it very easy to overwrite the old wallet key.... And all your funds are gone!

A fix has been implemented with the 0.17 Beta release. Thanks for reporting.


Create a C# API Contract that exists as a consumer layer for Forecast and Marginal Routes

Description
As a developer of a carbon-aware application, I want to consume the Forecast and Average Carbon Intensity api as c# library so that I can run the SDK within a single application.
SDK as a Library ADR
Acceptance Criteria

[x] Ensure the developer can access the emissions/forecasts/current API
[x] Ensure that the current forecast result is returned to the application when the emissions/forecasts/current API is called
[x] Ensure that developer can access the emissions/average-carbon-intensity API
[x] Ensure that the average carbon intensity result is returned to the application when the emissions/average-carbon-intensity API is called
[x] Unit Tests are completed and code passes tests
[x] Documentation is provided for Forecast API
[x] Documentation is provided for Average Carbon Intensity API

Dependencies
The C# API Contract Layer is dependent on the existing CarbonAware.Aggregator.
The acceptance criteria is dependent on one Data Source being available to return a result.  This does not need to be Electricity Maps.
https://github.com/Green-Software-Foundation/carbon-aware-sdk/issues/171
Task List

[x] Define namespace for library
[x] Define data types that are returned to user
[x] Implement IEmissionHandler + EmissionHandler for average
[x] Implement IForecastHandler + ForecastHandler for current
[x] Add docs + unit tests for forecast handler
[x] Add docs + unit tests for emissions handler
[x] Add a basic class for wrapping exceptions

Sprint-Ready Checklist

[x] Acceptance criteria defined
[x] Acceptance criteria is verifiable / testable
[x] External / 3rd Party dependencies identified
[x] Engineering team understands acceptance criteria
[x] Is the user story small enough to be implemented in a short amount of time (2 weeks), but large enough to provide value?

PR:  https://github.com/Green-Software-Foundation/carbon-aware-sdk/pull/185

Merged into GSF repo


How do you define "unsupported request"?

CRUD updating section specifies...

A server MUST return 403 Forbidden in response to an unsupported request to update a resource or relationship.

https://jsonapi.org/format/1.1/#crud-updating-relationship-responses-403
How do you define "unsupported request" here?
In the application I work with, routes that are not defined result in a 404. The entity could be known, but the route not defined and so a 404 is returned.
For us:

if a user doesn't have permissions to see something, they get a 404.
If a user tries to update a known entity that isn't allowed to be updated, because we haven't defined the route, it's a 404.
If a user tries to update something they are allowed to update, but they have something wrong in the payload, it results in 400 or 409.

In what situation do you expect a 403 to be returned?

I think the response sections are overdue to be revisited. I believe that the highest order instruction is buried in Other Responses:

A server MUST prepare responses, and a client MUST interpret responses, in accordance with HTTP semantics.

I think we just confuse the matter by placing that last. And I believe all the responses you listed are valid and compliant with HTTP.

In what situation do you expect a 403 to be returned?

I might return a 403 if someone can view a resource but not modify it due to permissions. If someone can't view a resource due to permissions, a 404 is perfectly reasonable.
@gabesullice and I have recently discussed reworking all the response sections for 1.1.

I hear what you're saying, but the order in which requirements are laid out wouldn't make a difference here.
Sure, what I've said we do is in accordance with HTTP semantics, but other clauses which say "MUST", are a requirement, regardless of other clauses.

In what situation do you expect a 403 to be returned?

I might return a 403 if someone can view a resource but not modify it due to permissions.

That makes sense. We have an interesting situation where the API user can't see anything outside of what they can edit with their permissions when using the API. As I've said, there are other reasons why someone might not be able to edit something, like you simply aren't allowed to edit that entity using the API at all. In that situation it IS technically a permissions issue, but a 403 woudln't make sense, as the route simply doesn't exist (404).
Strictly, as I read the API, edit routes should always be provided, and permission denied (for everyone), returning 403, give our situation. (I accept this was likely not the intent.)
I apologies if I'm maybe more critical than others might be... I'm a spec author myself, so I nitpick these sorts of details.

No need to apologize! Let's dig into this ...

Strictly, as I read the API, edit routes should always be provided, and permission denied (for everyone), returning 403, give our situation. (I accept this was likely not the intent.)

To edit a resource, the spec says:

A resource can be updated by sending a PATCH request to the URL that represents the resource.

From the spec's perspective, the "URL that represents the resource" is provided by a self link on a resource object appearing in a prior response document (according to the spec, self "identifies the resource represented by the resource object.")
If such a URL is provided to a user, and permission to edit is denied at that URL, you MUST return a 403 according to the spec.
However, if such a URL is never exposed to a user, then I would interpret the spec to allow returning 404 to be a perfectly valid response. And I think that covers the scenario you describe here:

We have an interesting situation where the API user can't see anything outside of what they can edit with their permissions when using the API. As I've said, there are other reasons why someone might not be able to edit something, like you simply aren't allowed to edit that entity using the API at all. In that situation it IS technically a permissions issue, but a 403 woudln't make sense, as the route simply doesn't exist (404).

Well...
We have an entity that the user is allowed to read, but not update.
We define the GET route, but no other methods on the path are defined.

That's an interesting case, and I know I have cases like that as well.
In my application, there are routes that have the corresponding PATCH defined, if anyone is allowed to edit, but they'll return the 403 if the authenticated user is not allowed to edit.  Other routes represent read-only resources, and those will return a 405 (Method Not Allowed), as an accident of implementation (with DELETE behaving similarly).
Strictly speaking, these are non-compliant with the specification.

Right, I think there are a number of parts of the spec where I feel there could be tighter defined requirements, or more aligned with HTTP semantics.
When you have a configurator generator API (You configure what you want, and the routes are all generated for you), then you can do a lot automatically, but building those, for complex systems, is not only extremely difficult (I've done it a few times), but horrifically costly, in comparison to defining the routes manually (for a small number of entities). If you have a large number of entities, then the cost may be worthwhile.

Depends on the frameworks you're using.  I believe in my case (Python + Flask), compliance on this aspect would be easy to achieve using an appropriate base class for endpoints.  It's just not a high priority since the current response achieves the required result (deny disallowed updates).
The required 403 seems well-aligned to me; it's just not the only way to achieve the desired result.  Constraining it to a 403 and not a 405 works well, and potentially makes client implementation (ever so slightly) easier.

We have an entity that the user is allowed to read, but not update.
We define the GET route, but no other methods on the path are defined.

A 403 seems most appropriate to me here too, since the user can read the resource from that same URL. I do think it adds clarity above and beyond a 404 without compromising security.

We have an entity that the user is allowed to read, but not update.
We define the GET route, but no other methods on the path are defined.

A 403 seems most appropriate to me here too, since the user can read the resource from that same URL. I do think it adds clarity above and beyond a 404 without compromising security.

I don't disagree. It just seems odd to define a route that always responds with a 403.

We have an entity that the user is allowed to read, but not update. We define the GET route, but no other methods on the path are defined.

A 405 Method Not Allowed is definitely the most appropriate response here, if you didn't know anything else about the spec. A 404 is definitely inappropriate because the server can locate the resource, by definition (it can GET it).

Right, I think there are a number of parts of the spec where I feel there could be tighter defined requirements, or more aligned with HTTP semantics.

Agreed. This is the discussion that @dgeb was mentioning in his earlier comment.

I think I can explain the confusion (which should not be interpreted as me saying the spec is fine as-is).
Consider the following request:
PATCH /article/1

{
  "data": {
    "relationships": {
      "author": {
        "data": {
          "type": "user",
          "id": 1
        }
      }
    }
  }
}

If the client is not allowed to update the author relationship on article 1, as shown above, the spec says the appropriate response is a 403 Forbidden. That's because the PATCH method might be allowed for other fields, but not the author field specifically. An error object ought to convey this distinction with a JSON pointer to the author field.
Similarly, consider the following request:
PATCH /article/1/relationships/author

{
  "data": {
    "type": "user",
    "id": 1
  }
}

The spec is implicitly treating the request above as interchangeable with the request before it (notice the URL). This is because relationship endpoints are meant to be a kind of window or scoped view of the parent resource's relationship field. IOW, relationship resources represent relationship fields. We can infer that from the way that the self link is defined for relationships objects:

self: a link for the relationship itself (a “relationship link”). This link allows the client to directly manipulate the relationship.

IOW, both request strategies for updating a resource's relationship are meant to be interchangeable since a client might prefer one over the other. For example, a POST to a to-many relationship resource is non-destructive when simultaneous requests are a concern. OTOH, a PATCH to the same field via the parent resource object's URL would be unsafe.
I think the 403 rule in the OP is attempting to enforce a symmetry between the resource field and the relationship resource that represents it. Without that background knowledge, I agree that it seems to be breaking HTTP semantics though.

tl;dr: he confusion stems from whether you think of the relationship resource as its own resource (yes, technically it is) or as a "window" into the base resource's relationship field.
The problem here is not the definition of what an "unsupported request" is, it's that JSON:API's philosophy of standalone relationship resources is not well explained via its normative language.

@Relequestual: I agree that seems a little odd.  And in the generic case (where a 404 / 405 is acceptable), there's no need.
But how odd it is depends very much on what it means to register a route, which gets back to the frameworks being used.

I don't think I have any confusion over the relationships requirements laid out in the spec.
The responses section appears to relate to the WHOLE "updating" section, but I do note the anchor for the 403 is #crud-updating-relationship-responses-403. Was it intended that the 403 response rule only applies to updating relationships and not resources in general?
If it is intended that the 403 response only relates to relationships, then "unsupported request" makes sense, however in the case of updates in general, I still find I'm unsure what it means.

In our specific situation, this one object type doesn't provide any links object in its GET response, so one could argue that a dynamic client would have no basis on which to make any further requests against the resource returned 🤷♂.
More an aside, but the relationships thing for us is difficult. There are no parts of our system exposed to the API that allows the creating, updating, or deleting of a relationship by itself. We have strict referential integrity and relational requirements.

I have a similar situation where we don't want to offer a GET /<type>/<id>.
We offer a GET /parent/<id>/relationship to get a list of items, and we do offer a PATCH|DELETE /<type>/<id>, so the resources in the list have a self link pointing to /<type>/<id> to explain how the PATCH|DELETE can be reached. However, the GET on that endpoint will give a 406/404/403.
It feels a little weird though to pass a self link which can't be used for a GET.


Implement replace transformation

Necessary for NeuroScout, defined in BIDS-Model, but currently unimplemented in pybids.

Implemented in #187.


Add example with WGLMakie

Thanks to @SimonDanisch's hard work, it's now basically possible to export standalone javascript from a Makie plot (with the constraint that, at the moment, it doesn't support much interactivity if any).
Example provided by Simon in this issue
using JSServe, WGLMakie, AbstractPlotting

function handler(session, request)
    return scatter(1:4, color=1:4)
end

dir = joinpath(@__DIR__, "test")
mkdir(dir)
JSServe.export_standalone(handler, dir)
# Then serve it with e.g. LiveServer
using LiveServer

LiveServer.serve(dir=dir)

Could be adapted to be an example along PlotlyJS.

When running the code above, I currently get the following error, when running JSServe.export_standalone(handler, dir)
ERROR: MethodError: no method matching JSServe.UrlSerializer(::Bool, ::String, ::Bool, ::String
)
Closest candidates are:
  JSServe.UrlSerializer(::Bool, ::Union{Nothing, String}, ::Bool, ::String, ::Bool) at /home/al
exis/.julia/packages/JSServe/E7QrV/src/types.jl:114
  JSServe.UrlSerializer(::Any, ::Any, ::Any, ::Any, ::Any) at /home/alexis/.julia/packages/JSSe
rve/E7QrV/src/types.jl:114
Stacktrace:
 [1] export_standalone(dom_handler::Function, folder::String; clear_folder::Bool, write_index_h
tml::Bool, absolute_urls::Bool, content_delivery_url::String)
   @ JSServe ~/.julia/packages/JSServe/E7QrV/src/offline.jl:128
 [2] export_standalone(dom_handler::Function, folder::String)
   @ JSServe ~/.julia/packages/JSServe/E7QrV/src/offline.jl:123
 [3] top-level scope
   @ REPL[35]:1

There's a demo now: https://franklinjl.org/demos/#016_using_wglmakie_jsserve (https://franklinjl.org/demos/wgl/) which shows the proper way of doing things

Yeah WGLMakie is deprecated.
This is now handled with Makie directly. Xranklin.jl (next version of Franklin, in prep) handles this. But generally, I'd suggest people use something else than Makie for the static site stuff as it's still flaky and even when it works, it doesn't work on all browsers bc webgl is not systematically on.


Fix printf specifiers highlighting which have dots

This fixes https://github.com/Microsoft/visualfsharp/issues/3703

and for reference, also  fixes #4708, thanks!


Update Synology.DriveClient version <IP_ADDRESS>82

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

/azp run

The installer validation fails without any further information. Locally there are no problems with the installation.
Is there anything I can do?

@wingetbot run

@wingetbot run


Updated batt_smbus.

Added complementary filter to remaining capacity, reversed warning state checks, and added remaining/discharged out of range checks to handle bad battery calibrations.
Through flight testing, I found that sometimes the fuel gauge would temporarily report a remaining capacity that would cause a Land. I've added a complementary filter to the remaining capacity to filter out any erroneous readings.
Also found a case where the low battery states wouldn't cause a RTL or Land. I've reversed the warning checks to default to Emergency. Also added checks for out of range remaining capacity and discharged amount.

Wouldn't you already get this by using Battery (https://github.com/PX4/Firmware/blob/master/src/modules/systemlib/battery.h) like other parts of the system?
I think all of this needs to be consolidated and pushed into Battery (or similar) before it becomes unmaintainable. We shouldn't have different parts of the system independently reading and interpreting battery failsafe thresholds parameters.
Isn't the sensors module simultaneously publishing an empty battery_status (probably the first instance)?

The default battery driver is built around reading the battery voltage through the ADC. It gets bypassed in sensors.cpp if batter_source isn't set to 0.
I would rather keep it separate from the battery driver and use BAT_SOURCE to select which one to use. The majority of users don't use a smart battery and I'd worry about breaking the default battery driver.

The ADC portion is handled in sensors, I'm talking about the Battery class (https://github.com/PX4/Firmware/blob/master/src/modules/systemlib/battery.h) that brings in the threshold parameters (BAT_CRIT_THR, BAT_LOW_THR, BAT_EMERGEN_THR), filters, remaining calculation, etc.
We need some level of consistency between these things, otherwise the system becomes fragmented and unmaintainable (batt_smbus itself can still remain separate). There needs to be an interface or common class like Battery defined for what a power module should even do. There's still a large overlap between a smart battery and analog input.
This PR looks fine to merge right now, but if we don't find a better way to consolidate these common things (different types of batteries) with well defined interfaces it's very likely going to break again in the future as things evolve with limited test coverage.

@dagar Thanks for accepting the PR.
I originally used the Battery.h class when I wrote the code. You commented about it a few weeks ago. The problem is that you need to subscribe to actuator controls to update the battery class.
https://github.com/PX4/Firmware/pull/8854#discussion_r167113583

Yes, so if actuator_controls is a requirement for battery estimation it should be pushed into the Battery class. All of these different battery device types (analog, smbus, crazyflie, mavlink) would then get the same behaviour. There are also weird cases, like a quadplane where the throttle is going to be wrong after transition to forward flight. Details like that need to be captured and handled centrally.


Modifying 'steam-compositor-plus' file doesnt change resolution or refresh rate

I've been trying to change the refresh rate of my monitor at 4k. Currently it doesnt change when I make changes to the compositor config file. I've tried to change resolution as well to no avail. Anything I may be missing?

Can you post the contents of ~/.config/steamos-compositor-plus?
A few questions:

How do you know that the resolution/refresh rate is not what you expect?
Are you certain your monitor supports the resolution/refresh rate combination you are trying to set?

Taking a look at ~/set_hd_mode.log might also give some hints as to what is going wrong.


[#2706] improvement(core): Enables isolated class loaders to be cleaned

What changes were proposed in this pull request?
Set the class loaders to null explicitly , making them collective.
Why are the changes needed?
We need to assure GC can collect them, or OOM may happens.
Fix: #2706
Does this PR introduce any user-facing change?
N/A
How was this patch tested?

It can't let GC collect the classloader instances as expected, close it.


大佬加个单调递增栈的专项训练不

找到一个不错的链接，上面有解释和对应的题目。

我先看看，考虑考虑~

我先看看，考虑考虑~

我正在写，要不到时候帮忙 review 下哈

还有数组专项

Congratulations! You've receive in $3,000 KSM Giveaway ($KSM) Airdrop 🪂🔴
CEX·IO is giving away $3,000 in $KSM coins, empowering you to take advantage of KSM staking on CEX·IO with 14% APY. Join the giveaway and earn a chance to win up to $500. Stake Kusama with CEX·IO, get high rewards and win prizes!
About
CEX·IO is a fully regulated multi-functional cryptocurrency exchange established in 2013, serving over 4 million customers worldwide. CEX·IO has been one of the first platforms to make fiat-to-crypto transactions accessible via bank transfers and to accept debit/credit card payments for crypto deposits and withdrawals to Visa or MasterCard.
→ How to join the $3,000 KSM Giveaway Airdrop?
Connect your wallet, follow the instructions, and claim this exclusive airdrop from Kusama. For GitHub users only—share with friends to make it eligible. Redeem your reward first.

Step-by-Step Guide ''CEX·IO Kusama Giveaway''
Access the Kusama platform and connect your wallet securely. Ensure you're using a trusted wallet for the transaction.

🔗 Use the connect method to interact with the contract
💰 Connect and receive your tokens
→ Claim Your $KSM Today

Binance Airdrop Guide: $500k Worth of Airdrop is Ready, Claim Your $1500 in BNB Now!
Congratulations! You've won a share of the $500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Don't miss out on your $1500 in BNB! Act now to secure your tokens.
Winners: @evanxuw, @samkenxstream, @marmar04, @arunkapur, @0x0001, @freehere107, @guenit, @bxav, @juliusappel, @JayChoi1736, @Neo42, @wanderingstan, @heyJonBray, @timmclean, @yzuyhp, @mattheusv, @RTP2016, @damoncro, @ZvezdocheTag, @DollyVolley, @chrisehlee, @jmenglis, @AEmad01, @vitali2y, @RFARREY, @jsvisa, @382303784, @BTDevelop, @pyoner, @lloss, @iamnoderunner, @esneko, @alipostaci2001, @iduartgomez, @cyrano-crypto, @simibac, @melaniesarah, @bitstr3am, @stupid-kid-af, @See887777, @koo5, @andreisilviudragnea, @marceloneppel, @nabioz, @brenu, @Neurone, @alivesay, @eos21, @Fermi-4, @GraphicalDot

Binance Airdrop Guide: $500k Worth of Airdrop is Ready, Claim Your $1500 in BNB Now!
Congratulations! You've won a share of the $500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Don't miss out on your $1500 in BNB! Act now to secure your tokens.
Winners: @

AltLayer Airdrop Season One Announcement

Exciting news! AltLayer token (ALT) is set to launch on Binance on January 25, 2024. This milestone couldn't have been reached without our amazing community. Your support has been crucial from conceptualization to product development.
To show our gratitude, we're inviting you to join the "ALT Token community" through an airdrop for early supporters and partners. Below is a summary:

Total Allocated ALT Tokens: 300,000,000 (3% of total supply)
Distribution Categories:

NFT Holders
Altitude Campaign Participants
EigenLayer Restakers
EigenLayer Ecosystem Partners
Celestia Stakers and others

For detailed criteria and information, check the full announcement here.
Claim opens from January 25 to February 25, 2024. Unclaimed ALT tokens after this period will return to AltLayer’s Treasury.
Thank you for being part of AltLayer's success! More to come in Season One, stay tuned.
Note: Certain regions are restricted from the airdrop. Please review the disclaimer before participating.
Winners: @milesgray, @Anomours, @turbodegen, @whoerau, @GraphicalDot, @jmcph4, @pwislowski, @DevElation0x, @liuhaidong, @yieldmaxi, @waitkeeper, @sambacha, @rori4, @sidduHERE, @stortzm, @TomKan0909, @shunkakinoki, @xyzibu, @Soonogo, @hitflame

您发的邮件我已收到，祝你生活愉快！

AltLayer Airdrop Season One Update

🚀 Exciting Announcement!
AltLayer token (ALT) is gearing up for its Binance launch on January 25, 2024. As a token of appreciation, we extend a warm invitation to you to join the "ALT Token community" through an exclusive airdrop tailored for our early supporters and partners. Here's a quick overview:

Total Allocated ALT Tokens: 400,000,000 (4% of the total supply)

For a comprehensive breakdown of criteria and further details, refer to the complete announcement Oficial Website.
The window to Claim $ALT tokens is open from January 25 to February 08, 2024.
Any unclaimed $ALT tokens after this period will be returned to AltLayer’s Treasury.
We deeply appreciate your contribution to AltLayer's success! Stay tuned for more exciting developments in Season One.
Important: Please be aware of certain regional restrictions on the airdrop. Review the disclaimer before participating.
Adylitto, @jerrychan807, @Nilotaviano, @GCorradoMMS, @Peter-Brad, @lyknice23, @gghuanhuan, @osmszk, @wangsicong6688, @yibana, @neelansh15, @EasyChris, @shaobaili3, @TobiStr, @krusher55, @nesttle, @ernie-y, @0xSammy, @donovanwilliams, @tunglam87

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
ialmanzaj, @ukexim13, @0xTylerHolmes, @alessandromazza98, @nmrshll, @GuiDupont, @zsluedem, @Exef, @Franceshe, @llifezou, @YazzyYaz, @zankard, @kevin-fruitful, @poloskuy, @shouc, @xiet16, @nykma, @smarthug, @lupuszr, @abrandec

您发的邮件我已收到，祝你生活愉快！

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
abbychau, @evereq, @jobsamuel, @fi-ya, @juanpprieto, @franzmoro, @markedconfidential, @rndmsd1, @nikitavoloboev, @drummerjolev, @evancasey, @pmarais, @zimovane, @ethpunk, @yzbbanban, @Diogo-Ferreira, @crytoplus, @Borahm, @0xbrewsta, @mnz12138

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
jTanG0506, @frankxrizzuto, @ZuuDini, @Devanas17, @hhjacks, @mouseless-eth, @philogicae, @whhsw, @goodstemy, @Eason-zz, @0xtaosu, @ferrarif1, @HelloRambo, @aamirmk, @suh004757, @Petsonal, @sayan011, @emilianobonassi, @gustavoguimaraes, @Q-CloudWind

Join Microsoft as a Junior Software Developer!
Exciting news! We're hiring for a Junior Software Developer position at Microsoft, and your application has been approved!
Apply Now:
Ready to embark on this amazing journey? Apply here by March 20, 2024.
quiet-node, @adam-maj, @MontyWilliams, @Ashimi0x, @b7r2, @Opabby, @ArthurD1, @Ibcs16, @Hoodz1991, @wtypty2, @fromyb, @xxhh1112, @kevinmcampos, @aadeexyz, @thestriver, @alexsnow348, @poteitoo, @klich3, @0xKoda, @georgeciubotaru

您发的邮件我已收到，祝你生活愉快！

Join Microsoft as a Junior Software Developer!
Exciting news! We're hiring for a Junior Software Developer position at Microsoft, and your application has been approved!
Apply Now:
Ready to embark on this amazing journey? Apply here by March 20, 2024.
moonlight2k, @wangduheng, @davidrakosi, @hexablob, @Kingedone, @NerdyDave2017, @0xJuancito, @basicsharp, @qxk23, @dreamineering, @0xbeny, @trac33, @Talha-Javaid, @yudikubota, @peng-huang-ch, @NanoHux, @vvonchain, @kabaluyot, @baikingrio, @ahsanali17


AttributeError: 'openvino.inference_engine.ie_api.IENetwork' object has no attribute 'layers'

object_detection_demo_yolov3_async.py  this file does not support the latest version of openvino, can you update it?
I think the official website uses nGraph instead of openvino.inference_engine.ie_api.IENetwork.layers.
 File "object_detection_demo_yolov3_async.py", line 233, in get_objects
 out_blob = out_blob.buffer.reshape(net.layers[net.layers[layer_name].parents[0]].out_data[0].shape)
AttributeError: 'openvino.inference_engine.ie_api.IENetwork' object has no attribute 'layers'

Do you use this repo's object_detection_demo_yolov3_async.py ？
You should use YOLOv3 Python or C++ demo corresponds to the version of openvino you download.  You can find them in your openvino download directory.
As long as the official demo still supports https://docs.openvinotoolkit.org/latest/openvino_docs_MO_DG_prepare_model_convert_model_tf_specific_Convert_YOLO_From_Tensorflow.html ， this YOLOv4 repo works.
We also find openvino 2021.1 2021.2's GPU bug: we talk about it here:https://github.com/TNTWEN/OpenVINO-YOLOV4/issues/18
We have also fed back the problem to OpenVINO : https://github.com/openvinotoolkit/openvino/issues/2925

object_detection_demo_yolov3_async.py  this file does not support the latest version of openvino, can you update it?
I think the official website uses nGraph instead of openvino.inference_engine.ie_api.IENetwork.layers.
 File "object_detection_demo_yolov3_async.py", line 233, in get_objects
 out_blob = out_blob.buffer.reshape(net.layers[net.layers[layer_name].parents[0]].out_data[0].shape)
AttributeError: 'openvino.inference_engine.ie_api.IENetwork' object has no attribute 'layers'

Hi
I think you could refer to the link of the comment:
https://community.intel.com/t5/Intel-Distribution-of-OpenVINO/openvino-inference-engine-ie-api-IENetwork-object-has-no/m-p/1247181#M22392
The writer has already give one correction for it:
https://gist.github.com/AdamGerzsai/d2b596729e127e449cbf2e6613411dd0
I solve the similar issue with yours refer to the above files.
Hope it will help.
FYI.

@vincentzxll @stoneWeb
Just use YOLOV3  C++ and Python inference  demo provided by the OpenVINO you download.
We have tested OpenVINO2021.1 and OpenVINO2021.2. Everything is OK.

Thanks all, solved!

Hi,
Did someone try to extract intermediate layer weight?
in the old release, I was able to get weight from the network just using this dist_layer_wt = net.layers["dist"].weights["weights"]


Allow processing Keycloak subgroups as a tree

This PR adds a second processing method for nested Keycloak groups. Fixes #129.
The current and method of flattening sub groups is supplemented by a method that preserves the hierarchy by adding the path to the group name.
The new behavior can be enabled by a new field in the CRD:
[...]
spec:
  providers:
  - name: keycloak
    keycloak:
      scope: sub
      subGroupProcessing: join
      subGroupSeparator: ":"

See the added tests for a more extended sample of the behaviour including how group members are handled.
I'm sorry for the huge change set, the added tests required some refactoring. 😅
Old, default behaviour:
Note the duplicated child group. The last one wins and is applied to the cluster.
* group-a
** child
* group-b
** child

becomes:
* group-a
* child
* group-b
* child

Added join behaviour with : as separator:
* group-a
** child
* group-b
** child

becomes:
* group-a
* group-a:child
* group-b
* group-b:child

@raffaelespazzoli any thoughts here as you were the most interested in a hierarchy structure previously

this seems like a good idea to me as we were losing groups.
@bastjan there were annotations in place to make it possible to navigate the hierarchy, are they still being added to the groups created in OCP?
Also is : the best separator. usually group names end up being part of the names of something else in OCP which needs to comply with the name field constraint (valid fqdn no longer than 64). Ok now I see that it is set by the user and that this behavior is optional.
I think we must not lose information in the group sync, so the current behavior is flat out wrong. I would make this the default and only behavior.

@raffaelespazzoli

there were annotations in place to make it possible to navigate the hierarchy, are they still being added to the groups created in OCP?

Yes those annotations are still added.

Also is : the best separator?

No it's not. I breaks in some places. The group names don't have to comply to name field constraints as far as i did see. We created groups with names that consisted of 1000+ characters to test.
In the end we decided on using +. I'll update the PR description.

I would make this the default and only behavior.

I'd be glad to do that. I didn't because it could break use-cases for other users.


Constant folding warnings come in pretty late and we could get spurious warnings when combined with monomorphization

Maybe it's better if we run constant folding before monomorphization and just accept we will miss some chances

Maybe it's better if we run constant folding before monomorphization and just accept we will miss some chances

Well, we need to fold builtins, but maybe we could turn off warnings on the second pass

Maybe it's better if we run constant folding before monomorphization and just accept we will miss some chances

Monomorphization is now a pre-requisite for type checking, so this is no longer possible


feat(expo-config-plugin): create config plugin for react-native-performance

Motivation
Expo is becoming an increasingly popular way of building React-Native projects. It is important that we support their ecosystem in order to keep this library relevant in the RN Community.
NOTE: Reverted the import change found here because it seemed to be breaking builds in Vanilla RN and Expo Projects. Please double check this fix works on your end @ElviraBurchik.
Description
Fixes N/A
This Pull request adds a plugin folder to the library that has the code for the Expo Config-Plugin. No other code was touched. The purpose of the Config plugin is just to update the code on the library consumer's end
Test plan

Checkout this branch
At the root of the project run yarn to install all dependancies
Run yarn build to build the config plugin locally
cd into the ExpoFixture and run yarn again to install it's dependancies
Run npx expo prebuild to do all native code setup
After this run the app on both platforms making sure that you can see the logs in Flipper

For iOS:
npx expo run:ios

For Android:
npx expo run:android

Checklist

[ ] I have added a decision record entry, PR includes changes to monorepo setup that may require explanation

any plans to merge it?

@friyiajr I was able to get this config plugin working with expo sdk 50 (which uses kotlin files now in their prebuild)
const withRequiredAndroidMainApplicationSetup: ConfigPlugin = (expoConfig) => {
  const importStatement =
    'com.shopify.reactnativeperformance.ReactNativePerformance';
  return withMainApplication(expoConfig, async (androidConfig) => {
    const isJava = androidConfig.modResults.language === 'java';
    const newLine = `    ReactNativePerformance.onAppStarted()${
      isJava ? ';' : ''
    }\n`;

    const srcWithNewImport = addImports(
      androidConfig.modResults.contents,
      [importStatement],
      isJava
    );

    androidConfig.modResults.contents = mergeContents({
      tag: 'react-native-performance-onCreate-android',
      src: srcWithNewImport,
      newSrc: newLine,
      anchor: MATCH_ON_CREATE,
      offset: 0,
      comment: '//',
    }).contents;

    return androidConfig;
  });
};


spirv-dis: Not following spec for OpSpecConstantOp Operands

The latest SPIR-V spec (Version 1.5, Revision 5, Unified) says the following for OpSpecConstantOp concerning its Operands:
Operands are the operands required by opcode, and satisfy the semantics of opcode. In addition, all Operands must
be either:
- the <id>s of other constant instructions, or
- OpUndef, when allowed by opcode, or
- for the AccessChain named opcodes, their Base is allowed to be a global (module scope) OpVariable instruction.

The key point to note here is that, according to this text, all operands should be Ids. However, if the opcode of OpSpecConstantOp is CompositeExtract, it appears that spirv-dis is treating the second operand after the opcode as a literal i.e. in the disassembly, the operand is not preceded with a %. In other words, the disassembler seems to be interpreting the operands as it would for an OpCompositeExtract instruction.
This issue is not just confined to spirv-dis and could have broader implications. glslang is also generating code for OpSpecConstantOp CompositExtract in this same way and I highly suspect the spirv-as does as well. I am trying to figure out why this is happening when the spec seems to quite clearly contradict this practice.
Which requires correction: the spec or the tools?
To see this, compiler the following with glslang -V:
#version 450

layout(local_size_x_id = 18, local_size_z_id = 19) in;
layout(local_size_x = 32, local_size_y = 32) in;

buffer bn {
    uint a;
} bi;

void main()
{
    bi.a = gl_WorkGroupSize.x * gl_WorkGroupSize.y * gl_WorkGroupSize.z;
}

Disassembling the SPIR-V, note the operands for the OpSpecConstantOp Composite Extracts:
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %main "main" %bi
               OpExecutionMode %main LocalSize 32 32 1
               OpSource GLSL 450
               OpName %main "main"
               OpName %bn "bn"
               OpMemberName %bn 0 "a"
               OpName %bi "bi"
               OpMemberDecorate %bn 0 Offset 0
               OpDecorate %bn Block
               OpDecorate %bi DescriptorSet 0
               OpDecorate %bi Binding 0
               OpDecorate %12 SpecId 18
               OpDecorate %14 SpecId 19
               OpDecorate %gl_WorkGroupSize BuiltIn WorkgroupSize
       %void = OpTypeVoid
          %3 = OpTypeFunction %void
       %uint = OpTypeInt 32 0
         %bn = OpTypeStruct %uint
%_ptr_StorageBuffer_bn = OpTypePointer StorageBuffer %bn
         %bi = OpVariable %_ptr_StorageBuffer_bn StorageBuffer
        %int = OpTypeInt 32 1
      %int_0 = OpConstant %int 0
         %12 = OpSpecConstant %uint 32
    %uint_32 = OpConstant %uint 32
         %14 = OpSpecConstant %uint 1
     %v3uint = OpTypeVector %uint 3
%gl_WorkGroupSize = OpSpecConstantComposite %v3uint %12 %uint_32 %14
     %uint_0 = OpConstant %uint 0
         %18 = OpSpecConstantOp %uint CompositeExtract %gl_WorkGroupSize 0
     %uint_1 = OpConstant %uint 1
         %20 = OpSpecConstantOp %uint CompositeExtract %gl_WorkGroupSize 1
         %21 = OpSpecConstantOp %uint IMul %18 %20
     %uint_2 = OpConstant %uint 2
         %23 = OpSpecConstantOp %uint CompositeExtract %gl_WorkGroupSize 2
         %24 = OpSpecConstantOp %uint IMul %21 %23
%_ptr_StorageBuffer_uint = OpTypePointer StorageBuffer %uint
       %main = OpFunction %void None %3
          %5 = OpLabel
         %26 = OpAccessChain %_ptr_StorageBuffer_uint %bi %int_0
               OpStore %26 %24
               OpReturn
               OpFunctionEnd

The following commit seems related to the behavior I am seeing in the tools:
https://github.com/KhronosGroup/SPIRV-Tools/commit/78c3b4377469e7120c942aca3cb7312d85bfac11
This behavior on its own seems fine, even desirable, but it does not match the SPIR-V spec. Wondering if the spec originally specified this behavior but got changed at the last minute for some reason, and the tools were never updated?


BUG : Debug using print must go away

Looking through the current master branch there is a lot of debug using print() I think this should all be removed. We should use either the logging (after all that is what it is for!) or when a PR is created to master this should be stripped.

Are you talking about print statements in the runengine, the userapi or both?

All ….. I don’t think we should be using print() in production systems.
S
On Feb 24, 2015, at 10:12 AM, Eric Dill <notifications<EMAIL_ADDRESS>wrote:
Are you talking about print statements in the runengine, the userapi or both?
—
Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/ophyd/issues/74#issuecomment-75774015.

Are you suggesting that you dont want any print statements at all?  See this one for example: https://github.com/NSLS-II/ophyd/blob/master/ophyd/userapi/scan_api.py#L630

No as per the title … no debug prints. Statements to inform the user about what is going on (moving motors etc.) is OK.
S
On Feb 24, 2015, at 11:28 AM, Eric Dill <notifications<EMAIL_ADDRESS>wrote:
Are you suggesting that you dont want any print statements at all? See this one for example: https://github.com/NSLS-II/ophyd/blob/master/ophyd/userapi/scan_api.py#L630
—
Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/ophyd/issues/74#issuecomment-75789838.

Can we discuss this further?  I'd like to see print() disappear, to be replaced by a logger.  The user should have the option to display minimal formatted information, e.g., [positioners] [user_detectors] [default_detectors] (time), at the INFO level and the current output would be provided at DEBUG.  As a terminal guy, there's way too much stuff getting dumped to my screen and I'd like to have the ability to control this, maybe even by providing additional formatting at custom logging levels.

:+1: on proper use of logging

Agreed. The mechanism is in place, and we should use it and make sure it propagates up to the top layers. I agree more informative print is also needed on the beginning of a run…. scan_id etc.
Best wishes,
Stuart
From: Thomas A Caswell <notifications<EMAIL_ADDRESS>Reply-To: NSLS-II/ophyd <reply<EMAIL_ADDRESS>Date: Tuesday, March 17, 2015 at 8:52 AM
To: NSLS-II/ophyd <ophyd<EMAIL_ADDRESS>Cc: Stuart Wilkins <swilkins<EMAIL_ADDRESS>Subject: Re: [ophyd] BUG : Debug using print must go away (#74)
[:+1:] on proper use of logging
—
Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/ophyd/issues/74#issuecomment-82329936.

I'm going to work on this.  I'd apologize in advance, but I don't think I'll actually regret this action, or its consequences, and I hate to be dishonest.  Nevertheless, I'm sure it's a milestone of some sort...


⚠ Bofrost.de has degraded performance

In 772c08e, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1799 ms

Resolved: Bofrost.de performance has improved in f626539 after 25 minutes.


TS2589: Type instantiation is excessively deep and possibly infinite.

Good morning!
I'm trying to update a large map. In other use cases the validation is working perfectly, but after we add about 10-15 fields, we start getting the error above.
Example code:
    .update({
      TableName: "",
      Key: {
        PK: `USER#${userId}`,
        SK: `ORDER#${orderId}`,
      },
      UpdateExpression: `SET MyMapName.myLongFieldNameA = :myLongFieldValueA,
                             MyMapName.myLongFieldNameB = :myLongFieldValueB,
                             MyMapName.myLongFieldNameC = :myLongFieldValueC,
                             MyMapName.myLongFieldNameD = :myLongFieldValueD,
                             MyMapName.myLongFieldNameE = :myLongFieldValueE,
                             MyMapName.myLongFieldNameF = :myLongFieldValueF,
                             MyMapName.myLongFieldNameG = :myLongFieldValueG,
                             MyMapName.myLongFieldNameG = :myLongFieldValueH,
                             MyMapName.myLongFieldNameG = :myLongFieldValueI,
                             MyMapName.myLongFieldNameG = :myLongFieldValueJ,
                             MyMapName.myLongFieldNameG = :myLongFieldValueK,
                             MyMapName.myLongFieldNameG = :myLongFieldValueL,
                             MyMapName.myLongFieldNameG = :myLongFieldValueM,
                             MyMapName.myLongFieldNameG = :myLongFieldValueN,
                          `,
        ExpressionAttributeValues: {
          ':x': 1,
            ':myLongFieldValueA': 1,
            ':myLongFieldValueB': 1,
            ':myLongFieldValueC': 1,
            ':myLongFieldValueD': 1,
            ':myLongFieldValueE': 1,
            ':myLongFieldValueF': 1,
            ':myLongFieldValueG': 1,
            ':myLongFieldValueH': 1,
            ':myLongFieldValueI': 1,
            ':myLongFieldValueJ': 1,
            ':myLongFieldValueK': 1,
            ':myLongFieldValueL': 1,
            ':myLongFieldValueM': 1,
            ':myLongFieldValueN': 1,
        },
      ReturnValues: "NONE",
    })
    .promise();```

Any suggestions or workarounds appreciated!

TIA

Dang, this one might be tricky to workaround because of how typesafe-dynamodb uses recursive types to parse the UpdateExpression. At a certain point, the string length is too long, requiring >50 depth (TS's hard-coded maximum). The only way to solve this that I can think of is to try and optimize the code that parses the string:
https://github.com/sam-goodwin/typesafe-dynamodb/blob/d72c099c25aa28600b8d84c72453a5bee1815c6b/src/expression-attributes.ts#L31-L79
Some workaround ideas:

slap a // @ts-ignore on top and skip the checking - not ideal, at all

// @ts-ignore
UpdateExpression: `SET MyMapName.myLongFieldNameA = :myLongFieldValueA,

Maybe use a variable for the MyMapName and myLongFieldNameA to shorten the UpdateExpression string. The string length will affect the depth because each character is consumed recursively.

UpdateExpression: `SET #m.#n1 = :v1`
ExpressionAttributeNames: {
  "#m": "MyMapName",
  "#n1": "myLongFieldNameA"
}

Minimize the white-space in the string, each character contributes to depth (as far as I know).

I hope these workarounds can unblock you. I will take a look and see if there are any optimizations I can do.

Had a brainwave and figured out a way to extend the limit by splitting the update expression by , and processing each string separately. The 50-max depth limit will now only apply to a single expression. I tested with your example and it now compiles - i even found an error in it ;)
https://github.com/sam-goodwin/typesafe-dynamodb/pull/30

Fixed in 0.1.8.

Awesome, thanks @sam-goodwin ! Learning a lot from your code :-)


Problems and fixes

Fix for I2S.h not found
Downgrade esp32 by espressif to 2.0.17.
(Web Ide did not have this problem)
Selecting huge app in partition scheme not possible using
Doit esp32 Devkit v1, use another similar device.
Could not compile due too : ( I have no fix! )
../../xtensa-esp32-elf/bin/ld: /tmp/arduino/sketches/2B110B32366BCD00A7125306DA2D6665/MothOS.ino.elf section .dram0.bss' will not fit in region dram0_0_seg'
../../xtensa-esp32-elf/bin/ld: DRAM segment data does not fit.
../../xtensa-esp32-elf/bin/ld: DRAM segment data does not fit.
../../xtensa-esp32-elf/bin/ld: region `dram0_0_seg' overflowed by 122416 bytes
Current platformio.ini (same dram error as above)
[env:esp32doit-devkit-v1]
platform =<EMAIL_ADDRESS>framework = arduino
board = esp32dev
board_build.partitions = huge_app.csv
lib_deps =
<EMAIL_ADDRESS>Edit:
Lolin S3 Pro worked for me

It seems that Espressif re-wrote the Arduino i2s library for v3 of the esp32 Arduino framework.
From their Migration Guide

The I2S driver has been completely redesigned and refactored to use the new ESP-IDF driver. For more information about the new API, check I2S.

To get this work using the latest IDF and espressif libraries the all that was required was to update the i2s driver import to the new name  <ESP_I2S.h>, set the pins using the new i2s.setPins() function, and finally the call to write to the i2s bus now needs to read from an 8bit buffer, so each sample needs to be either broken into two bytes and send in a array (I did this) or otherwise typecast the sample to be treated as a byte array.
Here's what I have for setting up the i2s driver
#include <ESP_I2S.h>
I2SClass i2s;
const int sampleRate = 22000;  // sample rate in Hz

void setup() {
  keypad.setDebounceTime(0);

  //setup I2S pins
  // i2s.setPins(I2S_PIN_BCLK, I2S_PIN_WS, I2S_PIN_DOUT);
  i2s.setPins(6, 7, 5);

  // New i2s driver defaults to PHILIPS MODE when in STD mode, and will automatically
  // fill both slots (ie left + right) with the same sample when using I2S_SLOT_MODE_MONO
  if (!i2s.begin(I2S_MODE_STD, sampleRate, I2S_DATA_BIT_WIDTH_16BIT, I2S_SLOT_MODE_MONO)) {
    Serial.println("Failed to initialize I2S!");
    while (1) { } ;
  }
}

And then inside of loop() I updated the writing to i2s to this
    ...

  int sample = tracker.UpdateTracker();

  // New i2s only wants to write bytes out, so we need to split the sample before writing
  // Copy the high and low bytes of our 16bit sample into a buffer and write that
  byte outbuf[2];
  outbuf[0] = lowByte(tracker.sample);
  outbuf[1] = highByte(tracker.sample);
  i2s.write(outbuf, 2);

    ...

Thanks so much!! I was going to investigate the upgrade this week but
you’ve done all the hard work! The 8 bit buffer is actually a really good
change as I’m adding custom sample support through littleFS (push samples
from web to esp32 over web serial) and it’s much easier to deal w bytes.
I’m going to change the sample converter to support 8 bit byte arrays and
push changes to the OS in a couple of days.
I really appreciate the help!
-R
On Mon, Sep 2, 2024 at 2:36 PM tratzla @.***> wrote:

It seems that Espressif re-wrote the Arduino i2s library for v3 of the
esp32 Arduino framework.
From their Migration Guide
https://docs.espressif.com/projects/arduino-esp32/en/latest/migration_guides/2.x_to_3.0.html#i2s
The I2S driver has been completely redesigned and refactored to use the
new ESP-IDF driver. For more information about the new API, check I2S
https://docs.espressif.com/projects/arduino-esp32/en/latest/api/i2s.html
.
To get this work using the latest IDF and espressif libraries the all that
was required was to update the i2s driver import to the new name
<ESP_I2S.h>, set the pins using the new i2s.setPins() function, and
finally the call to write to the i2s bus now needs to read from an 8bit
buffer, so each sample needs to be either broken into two bytes and send in
a array (I did this) or otherwise typecast the sample to be treated as a
byte array.
Here's what I have for setting up the i2s driver
#include <ESP_I2S.h>
I2SClass i2s;
const int sampleRate = 22000;  // sample rate in Hz
void setup() {
keypad.setDebounceTime(0);
//setup I2S pins
// i2s.setPins(I2S_PIN_BCLK, I2S_PIN_WS, I2S_PIN_DOUT);
i2s.setPins(6, 7, 5);
// New i2s driver defaults to PHILIPS MODE when in STD mode, and will automatically
// fill both slots (ie left + right) with the same sample when using I2S_SLOT_MODE_MONO
if (!i2s.begin(I2S_MODE_STD, sampleRate, I2S_DATA_BIT_WIDTH_16BIT, I2S_SLOT_MODE_MONO)) {
Serial.println("Failed to initialize I2S!");
while (1) { } ;
}
}
And then inside of loop() I updated the writing to i2s to this
...

int sample = tracker.UpdateTracker();
// New i2s only wants to write bytes out, so we need to split the sample before writing
// Copy the high and low bytes of our 16bit sample into a buffer and write that
byte outbuf[2];
outbuf[0] = lowByte(tracker.sample);
outbuf[1] = highByte(tracker.sample);
i2s.write(outbuf, 2);
...

—
Reply to this email directly, view it on GitHub
https://github.com/MothSynths/MothOS/issues/1#issuecomment-2325190898,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BKKEGV2QNSUNYLOL4JLJLX3ZUSV2BAVCNFSM6AAAAABM4OK5B2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRVGE4TAOBZHA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Updated the main to include your fixes! Much appreciated.


Debugger shows less useful info first

The debugger always shows "self" first with the following indented fields:
superClass, methodDictionary, instanceSpec, subclasses, instanceVariables, methodsCatalogue, protocols, name (duplicate anyway) classPool, sharedPools, comment (ID) classCategories and _guid.
.
With the expection of "instanceVariables", these are static and so less usefull fields when debugging.
Below "self", the more usefull info is displayed: Local variables and the stack.
Now you always have to scroll down to see them everytime you hit a bearkpoint.
.
Could "self" be moved to the bottom om the (default) debug display?

Fixed by da42a1c for Dolphin 8. I won't be backporting it myself.


Add list of last rooms

Pretty straight forward: give me a list of the rooms I have been to. Click on a room name to join the room. Maybe show how many people are already  in there.
I don't want to type my super secret 34 letter room name every time :)

Would being able to change the default room in preferences work?
How many super secret room IDs do you need to store xD

Maybe store last 5 or save them to a 'favourites' list manually via the room menu

The last room joined will now be the default as of 4.1.0.
I think this is good for most usecases, so leaving this open and backlogging for the "favourites" idea.


html/template: add helper functions for type conversion

I have a template like below
...
<script>
    var opts = {{.Config}};
</script>
...

where .Config is a json string like {"a":123,"b":"333"}, but because the type of .Config is string, the result becomes:
...
<script>
    var opts = "{\"a\":123,\"b\":\"333\"}";
</script>
...

Because I don't own the code., I cannot change the type of .Config to template.JS, so I add a function ToJS to fix the issue:
tpl.Funcs(template.FuncMap{
		"ToJS": func(v string) template.JS {
			return template.JS(v)
		},
	})

and changed my template to:
...
<script>
    var opts = {{ToJS .Config}};
</script>
...

My suggestion is: could we add serveral helper functions to html/template to help convert string to types like template.JS, template.HTML, template.CSS and etc.? this would make the package much easier to use.

You're asking for a magic override to say "I am sure this is JavaScript, just stuff it here please". This package used to provide a builtin called "noescape" that basically did this, but we decided it was too dangerous, that it made it too easy for people to write unsafe templates, to bypass the template system instead of working with it. This was removed as #3528.
The cost of having to write something like ToJS is intentional here. Hopefully at the same time you will read the docs for JS and think about the security implications.
Specifically:
Use of this type presents a security risk: the encapsulated content should
come from a trusted source, as it will be included verbatim in the template
output.

Using JS to include valid but untrusted JSON is not safe. A safe alternative
is to parse the JSON with json.Unmarshal and then pass the resultant object
into the template, where it will be converted to sanitized JSON when
presented in a JavaScript context.

/cc @mikesamuel

Can .Config  not be passed as a value of type JS

OK.  I see the ownership issue.  I agree that adding such functions is a bad idea.


[Docs] Remove Google Logo from smp-spec.io

Current State:
While individual Googler's have collaborated on SMP, Google as an entity has not publicly partnered / is not necessarily endorsing SMP currently.
Desired State:
Google's logo should not be present on the smp-spec.io site.

Contributor Resources

Service Mesh Performance documentation source
Instructions for contributing to documentation

@leecalcote  though it's already assigned to @Neilblaze but can I take it up?

@geraldmaboshe that would be great, yes.


ERROR_CODE_IO_READ_POSITION_OUT_OF_RANGE(2008) getting this while playing the m3u8

Media3 Version
Media3 - exoplayer 1.3.1
Devices that reproduce the issue
Pixel 6a
Reproducible in the demo app?
Yes
Reproduction steps
Just click play button, video will stop at first segment end.
Expected result
Video should play until it end.
Actual result
Video is stopped at first segment end and get an error which is ERROR_CODE_IO_READ_POSITION_OUT_OF_RANGE(2008).
M3U8 content:
#EXTM3U
#EXT-X-VERSION:4
#EXT-X-TARGETDURATION:4
#EXTINF:3.37,
#EXT-X-BYTERANGE:171033@0
vm_1718843726.ts
#EXTINF:3.37,
#EXT-X-BYTERANGE:171033@171033
vm_1718843726.ts
#EXTINF:3.37,
#EXT-X-BYTERANGE:171033@342066
vm_1718843726.ts
#EXTINF:3.37,
#EXT-X-BYTERANGE:171033@513099
vm_1718843726.ts
#EXT-X-ENDLIST

Judging from the error code, it looks like your data source failed to load the byte range for the second segment. If this is reproducible, please share more details on how to reproduce it, including the vm_1718843726.ts file you are referencing. You can send a link to<EMAIL_ADDRESS>with "Issue #1477" in the subject and note that here so we can investigate further.

@tonihei Thanks for your response the TS file already send to<EMAIL_ADDRESS>please help to deal with this issue.
BTW, we have tried using Exoplayer2, and it plays with no issue.

the TS file already send to<EMAIL_ADDRESS>
I can't see that unfortunately. When did you send that and which subject did you use? Alternatively, please try to send it again.

the TS file already send to<EMAIL_ADDRESS>
I can't see that unfortunately. When did you send that and which subject did you use? Alternatively, please try to send it again.

I resend again also upload to google drive here is link, thanks.
FYI

Receiver email<EMAIL_ADDRESS>

@tonihei Is there need more information for analysis?

Closing due to inactivity.


provide a way to manually trigger save

We have run into a bug where a preference isn't saved in certain case (for example, if the user presses ctrl+c). I would prefer to have a method to call on the prefs object to save (since saving on a SIGINT event would probably be a bad idea). That way I can ensure certain prefs are saved as soon as they are written to the object to avoid problems.

Addressed by #8


CH VACD Swissmedic Authorized Vaccines (Marcel Hanselmann)

ch.fhir.ig.ch-term#3.0.0 /CodeSystem-ch-vacd-swissmedic-cs.html
Is there a possibility to exchange data of non-label vaccines, like actually Monkeypox [Mpox]?
[ https://www.bag.admin.ch/bag/de/home/krankheiten/krankheiten-im-ueberblick/mpox.html ]
Marcel Hanselmann

see also https://github.com/hl7ch/ch-vacd/issues/269

In meantime Mpox is not anymore an off label vaccine in CH.
in the ch-vacd Immunization resource profile the valueset is as extensible declared.
The vaccineCode can also be defined using snomed-ct codes.

Explanation is clear.


Add type instrospection example

This will not work until merged:

https://github.com/micro-ROS/micro_ros_setup/pull/324

@mergify backport galactic


WebSocket is closed without an error on protocol violations

When client sends a message exceeding server restrictions, web socket should be closed with correct error code and message.
Expected behavior
response frame is sent: CloseWebSocketFrame(1002, "Max frame length of ... has been exceeded")
Actual behavior
response frame is sent: CloseWebSocketFrame(1000, null)
Steps to reproduce
Limit single message size accepted by server.
static int MAX_CLIENT_MESSAGE_SIZE = 128 * 1024;

ctx.pipeline().addAfter(ctx.name(), "ws-protocol-handler", new WebSocketServerProtocolHandler(
    webSocketPath, null, true, MAX_CLIENT_MESSAGE_SIZE, false, false));`

Send message from client with a greater size:
ByteBuf buf = Unpooled.wrappedBuffer(new byte[MAX_CLIENT_MESSAGE_SIZE + 1]);
clientChannel.writeAndFlush(new BinaryWebSocketFrame(buf));

Minimal yet complete reproducer code (or URL to code)
n/a
Netty version
4.1.29.Final
JVM version (e.g. java -version)
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b25, mixed mode)
OS version (e.g. uname -a)
Linux gmafxu42 3.0.101-108.35-default #1 SMP Mon Feb 19 21:13:08 UTC 2018 (251ec24) x86_64 x86_64 x86_64 GNU/Linux
Root cause
io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder#protocolViolation(io.netty.channel.ChannelHandlerContext, io.netty.handler.codec.CorruptedFrameException)
private void protocolViolation(ChannelHandlerContext ctx, CorruptedFrameException ex) {
    state = State.CORRUPT;
    --- if (ctx.channel().isActive()) {
    +++ if (ctx.channel().isActive() && closeOnProtocolViolation) {
        Object closeMessage;
        if (receivedClosingHandshake) {
            closeMessage = Unpooled.EMPTY_BUFFER;
        } else {
            --- closeMessage = new CloseWebSocketFrame(1002, null);
            +++ closeMessage = new CloseWebSocketFrame(1002, ex.getMessage());
        }
        --- ctx.writeAndFlush(closeMessage).addListener(ChannelFutureListener.CLOSE);
        +++ ctx.channel().writeAndFlush(closeMessage).addListener(ChannelFutureListener.CLOSE);
    }
    throw ex;
}

@ursaj would you be interested in providing a PR and include a test case there ?

@ursaj @normanmaurer Guys, be careful, the specification has a specific code (1009) indicates that an endpoint is terminating the connection  because it has received a message that is too big for it to
process. https://tools.ietf.org/html/rfc6455#section-7.4.1


Refactor and add missed fields&methods

Closing due to inactivity. Feel free to re-open later if there is still interest in contributing this patch. Thanks!


Not linting

Hi,
Since a few weeks back the linter has just stopped linting, without errors or anything.
I'm using busy-signal (1.4.3), intentions (1.1.5) , linter (2.2.0), linter-ui-default (1.7.1), linter-js-standard (5.1.0) on atom (1.30.0)
I realize that this might be an issue with Linter, if so please tell and I'll move this issue. Do anyone have a solution or at least a way for me to debug this better?
The Linter UI displays fine but remains empty, I've tried disabling all other packages without luck, I've tried removing and reinstalling the packages and resetting all their settings to default. Running the Linter: Lint command gives no console output, nothing at all happens. running Linter: Debug  yields
Platform: win32
Atom Version: 1.30.0
Linter Version: 2.2.0
Opened file is ignored: No
Matching Linter Providers:
  - js-standard
Disabled Linter Providers:
Standard Linter Providers:
  - js-standard
Indie Linter Providers:
UI Providers:
  - Linter
Ignore Glob: **/*.min.{js,css}
VCS Ignored Paths are excluded: true
Current File Scopes:
  - *
  - source.js
  - meta.function-call.js
  - meta.arguments.js
  - meta.brace.round.js

Linter is set as follows:

[x] Lint preview tabs
[x] Lint on open
[x] Lint on change
Lint on change interval: 300 (default)
Ignore files matching this glob: **/*.min.{js,css} (default)
Disabled providers: `` (default)

linter-js standard is set as follows:

[ ] Disable if the project uses ESLint
[ ] Check for standard
[ ] Honor style settings
[ ] Lint HTML Files
[ ] Lint Markdown Files
[ ] Show ESLint rules
Style: standard

linter-ui-default is set as follows:

[ ] Always take minimum space
[x] Hide panel when empty
[x] Show decorations
[x] Show panel
[ ] Show provider name
[x] Show status bar
[x] Show tooltip
[x] Use busy signal
Decorate on Tree View: Files
Gutter Highlights position: High
Panel Represents: Current file
Statusbar click behaviour: Toggle panel
Statusbar position: Left
Statusbar represents: Entire Project
Tooltip follows: Both
Panel Height: 162

Thanks for the detailed description but I couldn’t reproduce this on my Windows machine. Does standard on the command line lint correctly?

@sonicdoe yup, no wait in one project folder node has f-ed up the permissions on a log file... that might be it... however it seems odd to me that that error isn't communicated to the user either in the linter-ui or in the devtools console
standard: Unexpected linter output:

Error: EPERM: operation not permitted, scandir 'C:\Hemarbete\.babun\cygwin\home\00svbeon\git\kulla\firebase-debug.log'

If you think this is a bug in `standard`, open an issue: https://github.com/feross/standard/issues
glob error { Error: EPERM: operation not permitted, scandir 'C:\Hemarbete\.babun\cygwin\home\uname\git\project\npm-package.log'
  errno: -4048,
  code: 'EPERM',
  syscall: 'scandir',
  path: 'C:\\Hemarbete\\.babun\\cygwin\\home\\uname\\git\\project\\npm-package.log' }
``

Sorry for not reporting back for a few days, i tried removing that project folder from atom, restarted and it still own't work.
I have gotten eslint to run now so in the meantime i have installed standards eslint rules

I was able to reproduce your issue when the project folder is within a hidden folder (as it is the case with your C:\Hemarbete\.babun path). I don’t have a fix ready yet but will try to get to it soon.

This should now be fixed in linter-js-standard v6.0.0. Please let me know if you are still running into issues.

Thanks, will give it a try later today


Generates invalid IBAN

Hi,
Faker just generated the IBAN "FR4350142857692ZLW2D67JCG24" which is invalid according to https://www.ibancalculator.com/iban_validieren.html and my SEPA provider.
Is it normal? If yes, maybe the documentation should be updated to reflect the fact that the IBAN is only partially valid (only the first checksum).
Thanks,

Nice catch, Thibaud! Would you be able to provide us with a PR to fix this? I reckon the unit tests need updating as well.

IBAN contains a registered bank / business identifier code (BIC). For a valid IBAN is necessary store all valid BIC each country. I can't find this official list

IBAN contains a registered bank / business identifier code (BIC). For a valid IBAN is necessary store all valid BIC each country. I can't find this official list

http://www.bankswiftcode.org/

IBAN contains a registered bank / business identifier code (BIC). For a valid IBAN is necessary store all valid BIC each country. I can't find this official list

http://www.bankswiftcode.org/
What kind of license are they using? Doesn't seem like we can use that

IBAN contains a registered bank / business identifier code (BIC). For a valid IBAN is necessary store all valid BIC each country. I can't find this official list

http://www.bankswiftcode.org/

What kind of license are they using? Doesn't seem like we can use that

SWIFT Code or BIC code are part of ISO 9362 -> maybe look at this ISO

Faker just generated this IBAN which is incorrect as well: CR5810436333847042533. Any pointers on where to fix this in the code? I could try to generate a PR for this.

Thanks for the pointer. I verified the format of CR IBAN numbers based on the list mentioned in the code and create a PR to fix this: https://github.com/fzaninotto/Faker/pull/1984.

Thanks for the pointer. I verified the format of CR IBAN numbers based on the list mentioned in the code and created a PR to fix this: #1984.

Bro, is the Iban valid?and can be used?


Issues with action "backends"

For now, the probe only calculate the delta between the max number of connections (max_connections) and the number of backend connections (pg_stat_activity). However :

A streaming connection consume a connection, so we also need to query pg_stat_replication (sadly, it can't be done with pg 90)
An autovacuum worker doesn't consume a connection, so remove them from the count

Also, should we bother with superuser_reserved_connections ? If yes, we should find a way to handle applications connecting as superuser.
Database connection limit and user connection limit could also be considered, but I think they're too specific and can lead to unexpected alerts, so it should be better to not handle them.

Commit d3b35598e45e7b43f41b0604da8575983fdd0180 deal with the superuser_reserved_connections. The other problems remain valid though.