@Taurus1100 / @Taurus1099 I got your adapter today and made some quick test and it look to be working fine for me.

See video:
 URL

I tested with your F-Zero X and TH1 cartridge with a NUS-CPU-04 and NUS-CPU-08-01 motherboards. Both work fine.

I got others N64 mobo in storage will dig them this weekend and report back.

Meanwhile can you confirm which mobo your N64 got? Did you install any mods? Are you using an original AC adapter?


I have an icecast mp3 stream that does play with IcecastMetadataPlayer on iOS Safari and on iOS Firefox. I can't hear anything on iOS Chrome. Also, in none of these iOS browsers I am able to use AnalyserNode to read and visualize the sound levels (as bars that go up and down in a frequency spectrum). This visualization (data from analyser being all zeroes) seems to be a known issue and I can live without it. In desktop Chrome and Android Chrome the audio plays and I can also visualize the audio. On iOS I just use a generic animation that does not reflect the audio levels.

I might be able to provide useful debug information. My goal at the moment is to get sound in iOS Chrome.


That's very odd that there is no sound in only iOS Chrome, but other iOS browsers work fine. As far as I'm aware, iOS uses the same WebKit engine behind the scenes for all browsers.

What version of iOS and Chrome are you testing with?

In iOS, MP3 and Opus streams are decoded in WASM and played through the WebAudio API. If you want to clone down the repo and debug, you'd probably have the best luck starting here where the AudioContext is set up before playback starts.

 URL


Thank you for that. It would most probably hurt later :wink:


@ahmadzraiq They announced that version 3 should resolve this: URL


Thanks for taking a look. My console revisions is NUS-CPU-08-01 (modded with N64 Digital) and I'm using the original power supply. I also tested with an additional power supply and no change. When you are able to do further testing, are you able to get into a game on F-Zero? I've seen the game respond to controller inputs for 10-15 seconds but eventually it stops completely. The N64 Digital menu is still accessible however. Also, any issues with the rumble in Goldeneye?


Thanks for your reply!

I'm testing on an iPad with iOS 15.3.1 and iOS Chrome 101.0.4951.58. I've noticed that with iOS Chrome I also can't hear sound in the demo on URL while iOS Safari does produce sound.

I've set up my environment such that I can put breakpoints in iOS Safari and view the console of iOS Chrome (unfortunately I don't know how I can arrange breakpoints in iOS Chrome). I've added console.log()'s to IcecastMetadataPlayer though, and I can already see a difference in the logs between my app in iOS Safari and iOS Chrome.

iOS Safari: IcecastMetadataPlayer.play() gets called twice, and the sound works.
iOS Chrome: IcecastMetadataPlayer.play() gets called once, and then WebAudioPlayer._getAudioContext() gets called once, and the sound doesn't work.

WebAudioPlayer._getAudioContext() does not get called in iOS Safari.

There is a chance that this difference is related to my implementation in my app, but I don't think I'm doing anything special. I've just followed the example from the documentation.

I suppose now we just have to figure out where the code paths start to deviate for the 2 browsers. I'm not very familiar with IcecastMetadataPlayer but I'm willing to investigate further :) Any tips though are greatly appreciated!


I think its likely the N64 digital that interferes with the pad data lines. I can test more this weekend but its likely all fine.

I don't know much about N64 digital but I think you could remove the one connection for pad and it would likely work fine. But you would lose the OSD access.


Update: today's release (now live) re-introduces the fix for too-large line heights. We're working on adding customizable vertical/horizontal spacing to settings; should be live in the next week or two.

Please let me know if you still encounter issues with incorrect line heights after updating!


General note - we're delegating to CoreText for glyph rasterization, so rendering in the terminal grid should be largely the same as other Mac apps. Rendering of proportional fonts is definitely off, as we're not currently respecting fractional pixel advances between glyphs (things get forced to pixel boundaries). This may also be what's leading to low-quality font rendering on non-retina displays, as that forcing would be moving glyphs further from the desired location (in mm/inches).

I'm working on improving kerning this week. :) (FYI @jonohill)

The comments about glyphs appearing bolder is due to iTerm (and, presumably, Terminal.app) using a private API to render glyphs with thinner outlines on retina displays. When you disable that functionality, glyphs for Warp should be pixel-identical to iTerm (as of today's release).

Similarly to kerning, I'm working on addressing the too-bold issue this week. :)

If you want some more details about known issues with our font rendering, or a visual comparison with iTerm, see my comment here: URL


Must be related to the N64 Digital. I noticed a similar issue on another open source project:

 URL


I tested with my N64 with N64 Digital and had the same issue with F-Zero. Could not test with my stock N64 yet. But in my other tests I remember there were no issues with the game on a stock N64.

Thank you both for investigating further.

Holen Sie sich Outlook für Android
Sent: Thursday, May 19, 2022 12:52:29 AM
To: darthcloud/BlueRetro ***@***.***>
Cc: bixxewoscht ***@***.***>; Mention ***@***.***>
Subject: Re: [darthcloud/BlueRetro] bixxewoscht's dongle gitches Nintendo 64 Controller Pak / F-Zero (Issue #264)

Must be related to the N64 Digital. I noticed a similar issue on another open source project:

Ryzee119/usb64#42


Bien reçu le besoin @dellac, le ticket est et restera ouvert le temps que ce développement soit intégré dans notre roadmap interne.

J'en profite pour rappeler que nous sommes ouvert à toutes contributions au code de la passerelle via les Pull Request


Hey @cescoffier I just filed #25688. This creates a problem when using stork with the various kubernetes extensions if you have created any of your own kubernetes files in `src/main/kubernetes`. The resulting yamls generated by the combination of the `kubernetes-client` and the kubernetes extensions aren't deployable.


Hi @umnex , thanks for reporting. I'm not able to reproduce using your example when importing when using path or tags folder organization. It looks at first glance like the 10 stack limit nesting level hasn't been reached either.
<img width="1779" alt="Screen Shot 2022-05-19 at 11 39 12 AM" src=" URL

Is there a different example you're using that has more nesting happening? To get around these limits, I'd recommend checking out the openapi-to-postman project and this thread in particular where these limits are discussed for how to bypass them:
 URL


Would you be able to paste a stack trace that shows where the MediaSource error is being thrown? I have a guess where that's coming from, but I'm not entirely sure.

Could you also try setting `playbackMethod` to `webaudio` and `html5` in the options when instantiating IcecastMetadataPlayer? You can also select the playback method in the HTML demo page.

Worst case scenario, you should still get playback through the HTML5 audio element playback method. There are a few things that can prevent HTML5 audio playback, other than a bug in the library, such as not interacting with the page to start playback: see URL Sometimes there are quirks / differences in how browser enforce standards like this.

MediaSource support has been absent in iOS for a very long time even though it's been a standard for many years now. (Probably not due to any technical reasons...) Now that you mention you're using an iPad, I remember reading somewhere that MediaSource support was added to some degree on the iPad. I've never tried MediaSource on an iPad, since I can't install Chrome on the iPad Simulator. It's possible there are quirks in how it's implemented.

_Some background on how IcecastMetadataPlayer works:_
IcecastMetadataPlayer tries to detect the supported playback method by reading the audio codec from the Icecast stream and then checking for MediaSource, WebAudio, and HTML5 support. If MediaSource and Web Audio aren't supported by the browser or the audio codec isn't supported, then HTML5 audio is used as a fallback. ICY and Ogg Metadata will still be read and displayed by the first request, and a second request is started to play the audio in the HTML5 Audio element. This isn't ideal, since there are two requests, one for metadata and another for audio playback, but it shouldn't really happen since MediaSource and WebAudio should be supported by all mainstream browsers.


Sorry I attached the spec where i solved the issue by removing the nesting. Here is the spec sample that generates issues.
spec_with_issues.txt


the line-height looks good now. lunarvim looks normal now.. except that the text doesn't hide behind menus (not related to the line-height)


FYI @michalszynkiewicz / @aureamunoz - I discovered this after I merged quarkusio/quarkus-super-heroes#82. After that merged I was no longer able to deploy the system to k8s using the yamls generated by the various kubernetes extensions.

I had to remove the `kubernetes-client` dependency and re-add the bouncycastle ones manually in order to work around this (see URL I'll revert that once this is fixed & rolled into a Quarkus release.


n64_test_push_pull.zip

This is untested but it change the data line from open-drain, to push-pull. Maybe that will help if the issue is on the TX side.


Hey @miscco , I assume this question is addressed to me? If so, thanks for asking! Unfortunately, currently I wont find the time to work on this. The missing parts in my branch are noexcept-strengthening, unit tests as well as `adjacent` and `adjacent_transform`.


Note that you do not need to implement everything in a go.

Could you do a squash and rebase on main? I would be happy to give it another round of review and Tam implemented most prerequisites


Thanks for the explanation! I've also read the code and I understand the flow now.

Here is the stack trace for the thrown error in iOS Chrome:

ERROR ReferenceError: Can't find variable: MediaSource
canPlayType @ URL
_buildPlayer @ URL
 @ URL
generatorResume @[native code]
Ox @ URL
o @ URL
onInvoke @ URL
run @ URL
 @ URL
onInvokeTask @ URL
runTask @ URL
_ @ URL
promiseReactionJob @[native code]

This is in WebAudioPlayer.js on line 43:

`new MediaSource();`

Even though caniuse.com says MediaSource is supported by iOS Chrome (since iOS 13, I think), it's not working. Strangely in iOS Safari the constructor does work. I've also tried WebKitMediaSource but it cannot be found by iOS Chrome either.

Assuming that iOS Chrome just doesn't work with MediaSource, I can try and get WebAudio to work. It seems possible because for at least 1 particular mp3 stream on the HTML Demo page, iOS Chrome DOES play sound (though not in the React app...). The HTML demo tells me that WebAudio is being used in that case.

Setting HTML5 as player in my app does not work. No sound played, but I can try debug it later.

Now, I'm trying WebAudio and adding console.logs to WebAudioPlayer._getAudioContext(). I can see that the audio context state is set to 'running' when resume() is called. But no sound yet. Any idea which property is good to inspect? In the meantime I'll investigate further.


Everything is now working perfectly! The added ability to get vibration feedback on switching between rumble/memory pak is very helpful. Is there any functionality lost by changing the data line?


Hi @darthcloud, I'm the guy that slid into your DM's. Similar to the above user, I can confirm that the new firmware fixes all of the issues I was having. I played with it for quite a while today and exercised all of the main functionality and everything worked great. Thaks for finding a workaround so quickly... I was excited, then super bummed, and now excited again... this is a really neat implementation and will be my goto N64 setup going forward!
________________________________________________________________________________________________________________
Just in case it is useful info for future reference, when I _was_ having problems it was the following setup:
NUS-CPU-08-01 with N64Digital mod
stock PSU
Switch Pro controller
v1.5.1 of your firmware
@bixxewoscht receiver

What was happening (this was only for P1 on my modded system; P2 worked fine and my stock NUS-CPU-08-01 worked fine)
Controller pak emualation wasn't working at all (games either wouldn't recognize it or would report it corrupted)
Every few seconds an uncommanded controller input [Dpad down + Dpad right + main joystick (1,-1)] would register


Thanks for the stack trace and the debugging so far. I fixed that MediaSource error and a bug in iOS playback #121.

There was a bug when using the Audio element controls in iOS where the AudioContext wouldn't start properly so there would be no sound. iOS prevents AudioContext from running when it's not triggered directly by a user interaction, even when the user clicks the "play" button on the Audio element controls. I'm not sure if was related to your issue.

Could you give `icecast-metadata-player/1.11.7` a try and see if that helps or changes anything?


I've tried version 1.11.7 but I can't hear sound yet in iOS Chrome. Looking at the changes in #121 I assume an audio element needs to be present in the html? I did not have that before. So I've now tried adding it and passing it on to the IcecastMetadataPlayer constructor but no luck. I do see in my logs that when I click on the play button of the audio element, the resume() promise in unlock() is being called and resolved. As an experiment I also tried removing the call to resume() in WebAudioPlayer._initAudioContext(), because it seems to me it shouldn't be used together with the other resume()?

Unfortunately I don't know the ins and outs of the code and of playing audio on the web well enough to know what to do. But I can help with testing and experimenting when needed. For now I do have iOS Safari still available, which I assume most iOS users will use. But it would be great to support iOS Chrome as well. I still have hope that it can work, because the HTML demo page DOES play sound in iOS Chrome for some of the stream I tried.

I appreciate your help so far. Let me know if I can be of further assistance. A clear head after taking a break might also help me :)


Same here. I was hoping this would fix my problem, too. The stream is loading but I can't hear any sound. The log looks the same as on android, no errors - load, start buffer and play is triggered.


@jonathandv Which streams work and don't work on the demo page? If there's some correlation to audio codec or something like that, it would help narrow down this issue. Could you also post a screenshot of the supported codecs table on the HTML Demo page that shows up on iOS Chrome? It's the table just below the player controls on the demo. What audio codec is the stream that you have on your page?

The Audio element isn't required to be in the HTML, it's just one of the ways to use IcecastMetadataPlayer. This is useful if someone just wants to use the controls on the Audio element to start and stop playback, rather than using the `.play()` and `.stop()` methods. Essentially this makes it a drop in library for a page that already has an Audio element on it.


Hvala za opombe, `requests` smo odstranili url-je smo pa naredili tako kot smo se menili na vajah.
Imamo še eno vprašanje glede `binder`-ja, ali moramo spremeniti oz. dodati še kaj za delovanje le-tega
(poleg povezave z _javnost_ na bazo).


With latest versions of iOS Chrome and iOS Safari.

Stream: URL
iOS Chrome, HTML demo : ok
iOS Chrome, React demo: sound does not work (but does show stream metadata).
iOS Safari, HTML demo : ok
iOS Safari, React demo: ok

Stream: URL
iOS Chrome, HTML demo : ok
iOS Chrome, React demo: sound does not work (says: "Waiting for metadata...").
iOS Safari, HTML demo : ok
iOS Safari, React demo: ok

Streams other than mp3 don't seem to play in iOS Chrome in the HTML demo (at least: no audio).

My stream I prefer not to share right now (not meant for public), but it is an icecast mp3 stream and I printed the codec to the console: 'audio/mpeg; codecs="mpeg"'. It plays in iOS Safari using MediaSource, and does not play in iOS Chrome (using WebAudio). But I've been testing with the 2 public streams above, to make the scenario as close as possible in my app.

iOS Safari:
iOS_Safari

iOS Chrome:
iOS_Chrome


I do understand what you mean when you say that competitive companion wouldn't be as consistent when we add parsers for websites which require code to be in a predetermined format and the rest cases are not stdin/stdout.

However, when I use the extension I usually just want to code the problem using my local ide to get faster compilations and use the debugger. Just a click on the extension opens my editor and I can start the problem there. If it is sometimes not able to get the boiler plate code or the test cases, it still helped me to get on my ide and create a file without any effort.

A perfect solution for such websites may not exist but we can still provide this partial support instead of avoiding then. Some extra info can be shown when the user tries to parse a problem from unsupported website.


I think I finally found the issue on this one.

One of my downstream dependencies had a compatibility issue with bundlers that polyfill ES6 classes. This was causing the web audio decoder to not serialize all of the code when it is loaded as a web worker. In the React demo, this error only happens in the production build, which is heavily minified and polyfilled by the create-react-app build pipeline. Additionally, it only shows up on platforms that don't support MediaSource, i.e. iOS.

I've released a fix in icecast-metadata-player/1.11.8. Could you try that out?


I can confirm this firmware seems to resolve the issues I was having on my n64digital console as well, both with F-Zero X and overall memory pak issues.


A simple PrepareStatement will also report an error. I wonder if there is a problem with the support of PrepareStatement.
In this example, the sharding column is userid.

java
 String jdbcUrl = "jdbc:mysql://localhost:3307/sharding_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai";
// String jdbcUrl = "jdbc:mysql://localhost:3306/p1?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai";
 DriverManager.registerDriver(new Driver());
 Connection connection = DriverManager.getConnection(jdbcUrl, "root", "123456");

 String sql = "INSERT INTO remark(userid, content, `time`) values (?, ?, ?)";
 java.sql.Date date = new java.sql.Date(remark.getTime().getTime());
 PreparedStatement statement = connection.prepareStatement(sql);
 statement.setLong(1, remark.getUserId());
 statement.setString(2, remark.getContent());
 statement.setDate(3, date);
 statement.execute();

com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'org.apache.shardingsphere.sharding.rewrite.token.pojo.ShardingInsertValuesToken@' at line 1
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
 at com.mysql.jdbc.Util.getInstance(Util.java:408)
 at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:944)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3978)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3914)
 at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2530)
 at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2683)
 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2495)
 at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1903)
 at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1242)


Hi @wingkingbobo, thank you for your feedback, can you provide your sharding configuration?


Thank you @wingkingbobo, can you provide your original sql, I will try to reproduce this problem.


@mikeislearning "If you’d like to try running Reanimated on the new Fabric architecture, make sure that you are using at least version 0.69 of React Native"

so it's not working for expo SDK 45, right? (Expo SDK 45 uses v0.68.2)


Version 3 is coming 😏 and hopefully solving this issue.

 URL


I left a comment now on the tc39 proposal. I hope for now that Firefox reverts this behavior but the issue is known from our side. Since not all Firefox versions agree on the offset it's unfortunately a pretty frustrating situation right now that we do not want to try to make too many guesses about.


@strongduanmu
`MySQLSyntaxErrorException` thrown by prepareStatement seems to be another problem, so I raised an issue #17888 separately.
For the current problem, I'm trying to make a simplified demo to reproduce it.


@strongduanmu
The problem is that the blob length is equal to 0.
The description of this issue is incorrect, so I opened a new one #17892.


Sorry for the delay, @umnex. I've added a feature tag here for our Product team to review this as a feature request where the implementation will likely take time. It is a fixed limit of 10 levels of nesting I believe.

As mentioned in my last post, to get around these limits, I'd recommend checking out the openapi-to-postman project and this thread in particular where these limits are discussed for how to bypass them:
postmanlabs/openapi-to-postman#306 if that's a feasible workaround in the meantime?


Thanks for the update. I don't think I passed the 10 levels limit in my spec. Can you confirm it please?


Untitled

Thank you so much! :) The sound now also works properly in iOS Chrome. I've tested your React demo app and my own app.

I'll have a look at the changes and learn from them. Getting to know the code better will make it easier to contribute, maybe the next time.

I did notice 2 things:
- the first couple of times in my app sometimes the sound wouldn't play, but I haven't been able to reproduce it. It might have been a temporary caching issue.
- when I stop the sound and try to start it again it doesn't play anymore (only in iOS Chrome, in my app). I haven't investigated this yet and is maybe easily solved. I'll report back if turns out to be something real.


I just had this happen to me after ejecting from a fresh Expo app. `expo init my-app` then `yarn eject`.


Upgrading `expo-cli` from `4.12.10` to the latest (`5.4.6`) resolved it for me.


I found the SQL was not rewritten correctly.

[INFO ] 2022-05-25 15:44:55.387 [ShardingSphere-Command-9] ShardingSphere-SQL - Logic SQL: INSERT INTO remark(userid, content, `time`, b) VALUES (4, 'test0', '2022-05-25', _binary'blob')
[INFO ] 2022-05-25 15:44:55.387 [ShardingSphere-Command-9] ShardingSphere-SQL - SQLStatement: MySQLInsertStatement(setAssignment=Optional.empty, onDuplicateKeyColumns=Optional.empty)
[INFO ] 2022-05-25 15:44:55.387 [ShardingSphere-Command-9] ShardingSphere-SQL - Actual SQL: p1 ::: INSERT INTO remark(userid, content, `time`, b) VALUES (4, 'test0', '2022-05-25', 'binary'blob')


Hi @tuichenchuxin
The value was recognized as `expr` instead of `blobValue`. I found this may be related to #16493. Could you take a look at this?

<img width="1680" alt="image" src=" URL
<img width="347" alt="image" src=" URL


Nice! I can take a look at merging that into the `p384` crate. It seems to largely follow the same structure.


Interesting... I would like to compare performance of that with the WolfCrypt C implementation...


I'd be happy if we could merge that and therefore remove the `broken-arithmetic-do-not-use` stuff ^^


I'm from Taiwan, and I connect Internet with a Wi-Fi from a optical fiber network:

<img width="1440" alt="截圖 2022-05-26 上午9 27 04" src=" URL


@jedisct1 I opened a draft PR here: URL

Alternatively if you'd like to open a PR yourself, that works too


A dependency date was set as 15 November 2022 to align with the Energy release timeframe and considerations to change this date will be discussed further through Issue #507 in Maintenance Iteration 11.

This change was incorporated into release v1.17.0.

Please refer to Decision 237 for further details.


@daviddrysdale would you be interested in helping add Wycheproof test vectors?


An arithmetic implementation derived from `p384-rs` was merged in #565.

Thank you @jedisct1 and @brycx! And vicarious thanks to the fiat-crypto people!

For anyone following this issue, I've opened a tracking issue for a v0.11 release with arithmetic support: #566


@jedisct1 did you want to take a look at adding 32-bit support? If not, I probably can in the next few days


@kickbk @mnm458 I came across some use info in the React Native documentation.

From the Caveats section,
"Because you don't build any native code when using Expo to create a project, it's not possible to include custom native modules beyond the React Native APIs and components that are available in the Expo client app."

So until that changes from the React Native side, we will not be able to support the Expo client


#573 implemented (currently untested) 32-bit support except for field and scalar inversions, which presently use a 64-bit only implementation.

Once that has been addressed, we can add `cross` tests for 32-bit targets, and after that I'd say it's ready to release.


@wunschradio, have you had a chance to try out icecast-metadata-player/1.11.9 to see if that solves your issue?


Happy to put in something analogous to the P256 test vectors, but it doesn't seem like the various traits (e.g. `SigningKey`, `VerifyingKey`) needed to use `new_wycheproof_test!` are available yet?


@wunschradio Excellent, thanks for confirming!

@jonathandv If you think this is a problem with this library, could you open another issue? We can continue investigating there if needed.

Thank you both for helping work through this issue!


I already created (with the help of the expo team) a fork that works with a custom expo client. I just need to find the time to clean it up and share.
It is highly likely that if you have a project that requires this library, you'd be ok with a custom Expo client. You'd be handling native via a config plugin.


To summarise, the contention remained that the `interimId` presented increased complexity for ACCC delivery, conflicting with industry highlighting the urgency of delivery of this API with a mandatory identifier in order to be fit for purpose.

With this being considered, the DSB’s position remained unchanged as the interim solution shares the implementation burden between the CDR Register and clients until the complete solution is available. No other solution has been proposed which is seen as fit for purpose. The 1 October 2022 delivery date proposed is the latest that this API can be released and provide meaningful value to the CDR. Later delivery will erode the value of this API as industry may look for alternative sources for discovery. Earlier delivery will increase the value of this API as it will increase the period unauthenticated clients are able to leverage its value and increase confidence that the CDR Register is the source of truth in the CDR.

| API Details | |
| ------------- | ------------- |
| **API Name** | Get Data Holder Brands Summary |
| **Path** | `GET /cdr-register/v1/{industry}/data-holders/brands/summary` |

Release v1.17.0. for the CDS incorporates the interim solution **(V1)** into the standards.

Issue #518 has been raised to track delivery of the Complete Solution **(V2)**

Please refer to Decision 237 for further details.


I'm still getting `'react/config/ReactNativeConfig.h' file not found` when building react-native v0.68.2 with v3.0.0-rc.0 and Fabric enabled.

Could you anyone confirm that v3.0.0-rc.0 is supposed to work with Fabric enabled?


@umnex sorry to be mistaken on my part! I spoke with @VShingala and the "Too many levels of nesting to fake this schema" problems are due to how big the spec is where there are only six layers of nesting.

As a workaround, you can turn off Optimize Conversion setting, which should prevent the deeper layers of nesting from being populated with "Too many levels of nesting to fake this schema". I verified this with your file as well.
Screen Shot 2022-05-30 at 2 32 13 PM


@maxperry Yes, but only with using RN 0.69, where you have the new arch enabled.


@ccorcoran-nydig Hi! I added the ability to view annotations on enum constants - URL . But this feature will appear only in release `3.6.0`. After that, it will be possible to implement this feature


Thanks!
Currently getting

java
'int org.bytedeco.libffi.global.ffi.FFI_TYPE_SMALL_STRUCT_1B()'
java.lang.UnsatisfiedLinkError: 'int org.bytedeco.libffi.global.ffi.FFI_TYPE_SMALL_STRUCT_1B()'
 at org.bytedeco.libffi.global.ffi.FFI_TYPE_SMALL_STRUCT_1B(Native Method)
 at org.bytedeco.libffi.global.ffi. (ffi.java:109)
 at java.base/java.lang.Class.forName0(Native Method)
 at java.base/java.lang.Class.forName(Class.java:467)
 at org.bytedeco.javacpp.Loader.load(Loader.java:1282)
 at org.bytedeco.javacpp.Loader.load(Loader.java:1227)
 at org.bytedeco.javacpp.Loader.load(Loader.java:1203)
 at org.bytedeco.libffi.ffi_cif. (ffi_cif.java:16)

`

when calling `new ffi_cif();` on `org.bytedeco:libffi-platform:3.4.2-1.5.8-SNAPSHOT`


I see, those values are not available on that platform, but they only seem to be used internally, so we probably don't need them. I've fixed that by commenting them out in commit URL Please give it another try! Thanks for testing @TheMode


Adding note that we have URL - To move prebuild configurations to the project page. It might therefore make sense to move the JetBrains prebuilds configurations also to that page in the UI rather than in the configuration.


Going to close this out but feel free to reopen it if this issue is persisting! I'll log a ticket internally to try to better this error messaging where it's not intuitive to know to disable this Optimize conversion setting I realize.


I had a similar error and doing the following resolved the error. Make sure all 'obsm' objects that are dataframes have the same index as the 'obs' dataframe.


hello everyone. is there any kind of update on this?
I currently have a `Package Resolution Failed` error
image


@danipralea What URL you specified as a dependency? I guess the way to the future is to use Parse Swift SDK implementation and fall back to this legacy repository only when you really need it and know what you are doing.

Feel free to use the `spm` branch of my fork from URL that should resolve and work just fine but the question is whether this will ever get merged at all? CC @drdaz ?


Got it. I think as long s this repo is embeddable with in some way, I think we're good. We made carthage work recently, so it's available I'd say.


Hi @cowtowncoder, could you please clarify what methods are affected by this vulnerability? I am specifically interested if ObjectMapper.readTree is affected?


@tarcieri Is there anything left blocking the `0.11.0` release? I see you've changed the inversion to work with the 32-bit backend as well :rocket:


readTree is not affected, readValue is affected if you use untyped fields somewhere in the object graph youre deserializing


Hi @edeandrea ,

I've checked and seems that #25750 fixes this problem.
Let me know if you need anything else.


Thanks @aureamunoz !

How about helping get #25750 and #25756 merged? Right now they are still just sitting open.


Going to reopen this since it hasn't really been fixed and Daniel is seeing the issue as well. We are working on switching modules so maybe that will help but still want to keep this as a tracking issue.


FYI we're still hitting this in VS Code where we run the module in an Electron window. URL

Even though it doesn't look like you specifically target web, you can prevent this exception by supporting both environments like so:

ts
const x = setTimeout(...) as number | NodeJS.Timeout;
if (typeof x !== 'number') {
 x.unref();
}


@MaximilianTews see #2816 for more information. This is just a rewrite of that fix.

And @yawkat is correct: `readTree()` is not affected. `readValue()` MAY be affected BUT ONLY if the nominal type is or includes target type of `java.lang.Object`. Term "untyped" in Jackson context means `java.lang.Object` as binding target type (either explicitly, or via raw types, `?` type parameter and so on).


#589 adds `const fn` support to field elements

After that it would be nice to expose `const fn` wrappers for the field arithmetic functions, and then rewrite the various constants back into canonical form, transforming them into Montgomery form at compile time.

And after that, I'm good to ship it!


Will this cause a crash or stale when running for a longer period of time?


Do I need to update Appium library for that ? as i am facing exact issue in mac while setting location
getDriver().setLocation()


I updated appium using `npm install appium -g` but still getting same error , I think appium did not get updated.


Newer versions are available via appium 2. You can get it via npm as `appium@next`.


Thanks a lot for quick response !! Updated but seems lot of change is required for appium 2.0, had to revert that for now. Any other workaround plz for version 1.22.3?


No, it is impossible to resolve. Also setLocation() it is just an example but not only one method which crashing run by python path error


Unfortunately we don't provide patches for older Appium versions. Closed as fixed


Can someone test the electron v19 based build (build log / changes)? There is a hope that the following changes will make some effect: updated proton clients, updated electron, dropped MutationObserver use in the project.


Currently the most recent xcuitest driver version is 4.4.5. It is only available as part of Appium2. Appium1 is is legacy and not maintained anymore


@brenzi So far I have not managed to bring the system to a complete halt/crash, but the system performance goes all the way down until only a single transaction is processed per block.
See the following section from the log where there are more than a thousand transactions in the queue waiting but sometimes only and handful get processed into the block:

[2022-06-03T12:09:01Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1249 Time slot: 5 Transactions in Block: 1
[2022-06-03T12:09:01Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1478 Time slot: 94 Transactions in Block: 197
[2022-06-03T12:09:02Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1536 Time slot: 22 Transactions in Block: 11
[2022-06-03T12:09:03Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1957 Time slot: 37 Transactions in Block: 59
[2022-06-03T12:09:05Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2327 Time slot: 0 Transactions in Block: 1
[2022-06-03T12:09:05Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2547 Time slot: 15 Transactions in Block: 1
[2022-06-03T12:09:06Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2645 Time slot: 69 Transactions in Block: 115
[2022-06-03T12:09:06Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2530 Time slot: 184 Transactions in Block: 382
[2022-06-03T12:09:06Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2148 Time slot: 26 Transactions in Block: 19
[2022-06-03T12:09:07Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2129 Time slot: 23 Transactions in Block: 10
[2022-06-03T12:09:07Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2119 Time slot: 16 Transactions in Block: 1
[2022-06-03T12:09:07Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2118 Time slot: 64 Transactions in Block: 109
[2022-06-03T12:09:08Z ERROR its_consensus_aura::slot_proposer] Operations queue: 2009 Time slot: 114 Transactions in Block: 222
[2022-06-03T12:09:08Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1787 Time slot: 30 Transactions in Block: 1
[2022-06-03T12:09:08Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1786 Time slot: 2 Transactions in Block: 1
[2022-06-03T12:09:08Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1785 Time slot: 21 Transactions in Block: 2
[2022-06-03T12:09:09Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1783 Time slot: 14 Transactions in Block: 1
[2022-06-03T12:09:09Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1782 Time slot: 2 Transactions in Block: 1
[2022-06-03T12:09:09Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1781 Time slot: 35 Transactions in Block: 36
[2022-06-03T12:09:10Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1745 Time slot: 65 Transactions in Block: 118
[2022-06-03T12:09:10Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1627 Time slot: 50 Transactions in Block: 69
[2022-06-03T12:09:10Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1558 Time slot: 26 Transactions in Block: 14
[2022-06-03T12:09:10Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1544 Time slot: 20 Transactions in Block: 1
[2022-06-03T12:09:11Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1543 Time slot: 95 Transactions in Block: 183
[2022-06-03T12:09:11Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1360 Time slot: 47 Transactions in Block: 74
[2022-06-03T12:09:11Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1286 Time slot: 36 Transactions in Block: 36
[2022-06-03T12:09:12Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1250 Time slot: 35 Transactions in Block: 33
[2022-06-03T12:09:12Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1217 Time slot: 70 Transactions in Block: 128
[2022-06-03T12:09:12Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1089 Time slot: 3 Transactions in Block: 1
[2022-06-03T12:09:13Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1088 Time slot: 24 Transactions in Block: 3
[2022-06-03T12:09:13Z ERROR its_consensus_aura::slot_proposer] Operations queue: 1085 Time slot: 66 Transactions in Block: 120

It also leads to the effect that sometimes the block production does not happen at regular 300ms intervals anymore but instead takes more than twice as long:

Time since last slot: 671
Time since last slot: 640
Time since last slot: 707
Time since last slot: 683
Time since last slot: 660
Time since last slot: 587
Time since last slot: 613
Time since last slot: 604
Time since last slot: 369


ok.
* the good: lifeness is still maintained
* the bad: availability is severely harmed
* the ugly: this happens way too soon

so I think an investigation is necessary


@haerdib I think I have to correct myself regarding the behavior after a restart: If I just kill the `integritee-service` and restart it then it goes back to having a high CPU load immediately.
@brenzi Before I had 4 MB of state, but I'm not sure it is directly related to the state size. I will keep an eye on it tough.


Well this may finally be it :).
It has not yet shown any signs of excessive resource usage, even after a restart and some usage.


Thanks for the feedback. If possible, please keep using this build for a while. Hopefully, the next app release switches to the recent @electron version.


I support this request! I set up a form for an organizer of a small community festival and wish to assign editing rights to the organizing circle. See also URL


I'd be happy to just have a group or circle with the right to edit - only one at a time. I'm just a user but wouldn't a file lock be enough while one is editing?


Still haven't found any issues, after multiple days, many restarts and actual usage.
We probably need a second person from this thread to confirm, but as far as I can see it's fixed.

Also, thank you for continually thinking of us :).


Can you try using following phases:-
BEFORE_COMMIT – The event will be handled before the transaction commit.
AFTER_COMPLETION – The event will be handled when the transaction has completed regardless of success.
AFTER_ROLLBACK – The event will be handled when the transaction has rolled back.
AFTER_COMMIT – The event will be handled when the transaction gets committed successfully.


@RyanCavanaugh

This statement is simply not true! TS is a compiler and it is defined in the documentation as "TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.", in fact, it does even generate output not present in the input, for example, polyfills for handling "await" etc, depending on the selected target. So it is very much a compiler that outputs JS, the rest seems to be confabulation used not to fix issues that do not fit your current mental model of what TS should or should not do.


@UDAYBIDKAR did some great work on this in URL but unfortunately isn't available to finish the work. If anyone would like to build on their great contribution and take it to the finish line, that would be great — there's just some review comments to address (see the PR for details).


@dl8dtl There are many xmega related issues, not so sure this one (as well as others) is still relevant or not.

I have tried to link the xmega related issues here:
* URL


With the tray becoming a module, is it possible that true transparency could be added (as per URL

Not to impose more features on this issue, just curious as to the possibility/complexity as someone without much understanding of X/WMs.


I also barely know anything about X and window managers :sweat_smile: so I'm probably not really qualified to answer that.

The changes we added in these PRs are basically one big hack. As you might know the tray right now is a separate window overlayed over the bar window. Instead of removing this window and incorporating the tray into the bar, we decided to internally create blank module with the same size as the tray window. The tray window is then just moved over the blank window in the bar. Therefore, the tray now behaves like a normal module but is still a separate window.

I think that since we only change the window position the same problem still remains with true transparency although @patrick96 probably knows a lot more about it.

I hope this helps!


See the following two graphs that show the percentage of transactions in the queue that are included in the next block over time (max. 20 Transactions are in the queue). In both cases the performance degrades over time but much slower in the second case (note the different time scale in the two graphs). Orange line is the moving average.

benchmark

After the changes from @mullefel that keep the state in memory:
benchmark-improved


How does this behave if we increase block time to 1s? Does it also go down to near zero tps or does it approach a steady level?


can you plot state size / number of accounts along the performance plz?


I have a fresh install of GitHub Desktop and still having this issue. Any other suggestions?


Nevermind, my issue was that when choosing "Open With GitHub Desktop", it was not entering the entire URL correctly. I added ".git" at the end and cloned successfully.


Sorry for the radio silence, I have been swamped the past few weeks. I appreciate your work on this :smiley:

I should have some time to start reviewing stuff again next week, but I will only be around sporadically for at least a month or two.

---

:+1:

True transparency remains as difficult as it has before, this "new" tray module didn't really change how the tray is rendered, just where it is placed on the bar. I am considering adding back true transparency in #2609, but no promises.

I don't think we will ever get away from doing it like this. Since each tray icon is a separate window, we have to somehow overlay them over the bar window.


have you checked that the issue is not the content-type header? we had the same issue (server not receiving anything when the request came from iOS but worked fine on android) and setting no content-type header worked for MultipartFormDataUpload
Related issue #204


So instead of doing an "outwards" sync (Jellyfin -> AniList/MAL/Kitsu), we sync the Jellyfin library to a provider (AniList/MAL/Kitsu -> Jellyfin)?
This has been requested before here #12.
While it wasn't exactly the original idea of the plugin, I still feel like it falls into the same realm.
We could even make it an optional scheduled event, for those who update their AniList/MAL/Kitsu manually outside of Jellyfin.
I can't see how it would be that difficult to achieve, simply retrieve the users complete/in progress list and update the Jellyfin library.
I'll look into it and keep you updated.


The main issue is you need to-be very carefully how/what you sync and also offer/study the settings options the trakt plugin has.

There can be a catastrophic case, where you wrongly sync the "unwatched" state to from remote to the local library and than quickly via a scheduled task, resync this new bad "unwatched" state back to the external list, basically wiping your watched states.

To prevent this case all trakt plugins by default disable remote->local "unwatched" sync via settings and also arrange the update jobs, so that the user has a chance to fix setting issues, before a full resync happens.

So by default you want the plugin to handle mainly "watched" states between local remote lists and via settings allow certain "unwatched" state combinations.

As example, the trakt plugin has specific settings to only set remote "watched/unwatched" if the user manually set the state. This is safer, since we detect a specific user toggled state change instead of doing some general assumptions.

So if you don't use the trakt plugin already, i strongly recommend to check it out and what settings combinations it offers, so you can avoid running into those catastrophic cases. We want safe defaults and carefully worded settings, similar to trakt so users quickly understand whats happening.


Sink for save file:

[sink0]
enable=0
type=3
# 1 = mp4, 2 = mkv
container=1
# 1 = h264, 2 = h265
codec=1
# Encoder type: 0 = Hardware 1 = Software
enc-type=0
sync=0
bitrate=4000000
output-file=out.mp4
source-id=0

Sink for rtsp output:

[sink0]
enable=0
type=4
# 1 = h264, 2 = h265
codec=1
# Encoder type: 0 = Hardware 1 = Software
enc-type=0
sync=0
bitrate=400000
rtsp-port=8554
udp-port=5400

The output link for RTSP streaming is `rtsp://localhost:8554/ds-test`

You can use multiple sinks by change their numbers (example: [sink0], [sink1], etc)


I'm sorry, but I still can't output MP4 files or RTSP using the method you recommended.


The vertical problem does not happen if you use the default font, but if you change to Monaco, for example, it starts to happen:

Default font
<img width="1136" alt="Captura de Tela 2022-06-11 às 10 41 10" src=" URL

Monaco
<img width="1136" alt="Captura de Tela 2022-06-11 às 10 41 28" src=" URL


Yeah OK not super surprising, the region is hardcoded:

 URL


+1 I keep nearly making embargoed requests by mistake. It'd be good to be able to set a default that applied to all my requests unless I said otherwise.


Its not, you need to pass the right region. We can't guess region for your deployment.


@vosmiic btw i took the liberty to add the plugin to the official documentation: URL


Ah great, thanks. I think we are now in a comfortable enough position to have it there.


Just as a FYI, #12 isn't really about what @Andy2244 is asking for here, which is importing watch status from a remote Trakt-like third-party provider (i.e. AniList/MAL/Kitsu -> Jellyfin) but rather an extended functionality of what Ani-Sync already does, which is exporting watch status to a third-party provider (i.e. Jellyfin -> AniList/MAL/Kitsu) but _without_ the hard requirement that I must first initiate playback of an anime for AniSync to scan it and update its remote status.

My issue (and I'm pretty certain I'm far from the only one affected) is that many of my anime were already watched or in various states of _media res_ before I ever installed AniSync, but I'd just never bothered to manually update my MAL profile. So what I'd love for AniSync to be able to do, and what I asked for in #12, would be that it be able to scan my local Jellyfin library, find which anime I have already watched and which shows I'm currently watching, and then update my MAL profile accordingly. And if it could also add my completely untouched anime to the "plan to watch" category, that would be even more awesome.

After this has been done, then adding what @Andy2244 is actually asking for, i.e. the ability to also import watch state from MAL et al to Jellyfin, would be the cherry on top.


I kinda included your scenario, its just a subpart of what a full 2-way sync does.


I know, I was replying to @vosmiic here:

"This" isn't what has been requested in #12 :)


Yeah sorry I got a bit confused.
I think I understand what would like to be achieved here, as it has been said before we would like both way sync between Jellyfin and the providers.
I also understand what @Andy2244 said with being careful how we handle it. Need to make sure it doesn't turn into a nasty loop of updating each others lists and end up with broken watch statuses on both sides. I can see that you explained how the trakt plugin handles it, and it seems to be the best method.
I'll take all of this into account when implementing these changes.


@harshavardhana As you can clearly see in the linked source code, it is hard coded.

When I pass in the region the behavior doesn't change.


js
 this.makeRequest({method}, '', [200], 'us-east-1', true, (e, response) => {
 // ^ here


I'll look over/reorganize my existing PRs till next week and try to finish the settings one.

Since the plan is to release this feature with 3.7. What's your timetable for that release?


We will send a fix soon for using the configured region param. Thank you @louwers


More prior work:

* URL

Actually the entire modern-async library is quite interesting, as it has implemented some of the things that we've been working on as well. But I think we won't just bring in that library, but instead extract parts out of it for our own implementation.

It has interesting ideas for promise cancellation as well, `Delayer`, `Scheduler` and `Queue` can all help. I believe that our usage of async generators and decorators might be more advanced though.

The library also exports a bunch of collection combinators that can work with asynchronous execution. So instead of say `Array.map` mapping a synchronous function, it could map an asynchronous function, and then wait for all of them to finish. Basically we do this with `Promise.all` atm. It also works with asynchronous iterables like async generators. This I feel is a different kind of thing, and I'd only want to bring in these utility functions where it's relevant. Maybe if JS had better treeshaking and package specific imports ( URL it would work well.


Note that `age` and wireguard both use URL

It's an alternative to AES GCM which has higher performance when the hardware doesn't support AES-NI instructions.

AES GCM is still good for compliance though, some places like government require this.

But the algorithm apparently works and is designed for software-only implementations.


There is no fixed timeline. It is mainly tied to which features I want in it. In the 3.6 blog post I said that I wanted to have a fixed tray, new font renderer, and some config syntax improvements in 3.7. But it is starting to look like that will be take too much time for a single release (I really want to release more often than every 12 months).

So I think we should release 3.7 once the tray module is stable and I am finished with #2609. I do want to finish #2609 before 3.7 because it will result in some breaking tray changes (basically if you had the tray anywhere outside of the bar window, this will no longer work) and if people should migrate to the module anyway that won't be a big problem.


Everyone - I checked with Engineering a few day ago, which confirmed they are currently working on a hotfix for this issue.
The plan is to release it this calendar year, I don't have a more specific date.


Same here!
I have developed forms, but need my editor to be able to edit them also


Gitpod current focus is on the IntelliJ experience (which has a lot of overlap with the other JetBrains IDEs), which is also where JetBrains themselves are focussing a lot of their remote development energy. As the experience improves for the other IDEs we'll be looking to roll those as soon as we reasonably can 🙏


I'm not sure, but I'd used `data="jitterbuffer_msec=60:120:20"` based on this.


Other than documented, looking at the actual implementation, the third parameter seems to be ignored: URL -> maxlen is set if there is a colon, but that's it. A second colon does not do anything.


Also, ` ` and ` ` do different things if I understand that correctly. The first one controls the RTP jitterbuffer within freeswitch, the second one sets parameters for the opus codec, which also has a jitterbuffer. They may both have an impact.


Thanks, @LeSuedois. Unfortunately, I don't think it's an M1 owner I need assistance from here. The issue is that I cross-compile everything, from Raspberry Pi to Win32 to Mac x64 to AARCH64, all in a Docker container on a Linux system. So what needs to be done is figure out how to cross-compile for the M1/MacOS, not actually run builds on one.

It's been a while since I built the container, but IIRC it depends on a manually cross-built XCode. If Apple is still doing XCode, then it's probably a matter of doing the same to the latest bundle.


Thanks for mentioning this. I hadn't noticed the difference.
By the way, I wonder why the problem is solved after not calling `enableMultipleKurentos` function.
I thought it might do some overwrite that causes media to become out of sync, since I've read that BBB 2.5 uses mediasoup instead. (I'm not a developer, so it's just a guess!)


I'm using vercel cicd to deploy my project, has the same problem.
remove `package.lock` & `yarn.lock`, and `yarn install` reinstall again, that's work for me!


In fact, I have consulted NVIDIA's official blog, but it still hasn't been resolved。
my deepstream_app_config.txt is below:
`[application]
enable-perf-measurement=1
perf-measurement-interval-sec=5

[tiled-display]
enable=1
rows=1
columns=1
#width=704
#height=576

width=1920
height=1080
gpu-id=0
nvbuf-memory-type=0

[source0]
enable=1
type=4
#uri=file:///opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4
#uri=file:///home/dvadmin/wxp/safeHat/video/show-safetyhelmet.avi
uri=rtsp://admin:beSdeV99@192.168.0.64:554
#uri=rtmp://192.168.0.186:1980/live
num-sources=1
gpu-id=0
cudadec-memtype=0

[sink0]
enable=0
#Type - 1=FakeSink 2=EglSink 3=File 4=RTSPStreaming
type=4
#1=h264 2=h265
codec=1
sync=0
bitrate=4000000
# set below properties in case of RTSPStreaming
rtsp-port=8554
udp-port=5400

[osd]
enable=1
gpu-id=0
border-width=5
text-size=15
text-color=1;1;1;1;
text-bg-color=0.3;0.3;0.3;1
font=Serif
show-clock=0
clock-x-offset=800
clock-y-offset=820
clock-text-size=12
clock-color=1;0;0;0
nvbuf-memory-type=0

[streammux]
gpu-id=0
live-source=0
batch-size=1
batched-push-timeout=40000
width=1920
height=1080
enable-padding=0
nvbuf-memory-type=0

[primary-gie]
enable=1
gpu-id=0
gie-unique-id=1
nvbuf-memory-type=0
config-file=config_infer_primary_yoloV5.txt

[tests]
file-loop=0`


In fact, I have consulted NVIDIA's official blog, but it still hasn't been resolved。see in: URL
my deepstream_app_config.txt is below:
[application]
enable-perf-measurement=1
perf-measurement-interval-sec=5

[tiled-display]
enable=1
rows=1
columns=1
#width=704
#height=576

width=1920
height=1080
gpu-id=0
nvbuf-memory-type=0

[source0]
enable=1
type=4
#uri=file:///opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4
#uri=file:///home/dvadmin/wxp/safeHat/video/show-safetyhelmet.avi
uri=rtsp://admin:beSdeV99@192.168.0.64:554
#uri=rtmp://192.168.0.186:1980/live
num-sources=1
gpu-id=0
cudadec-memtype=0

[sink0]
enable=0
#Type - 1=FakeSink 2=EglSink 3=File 4=RTSPStreaming
type=4
#1=h264 2=h265
codec=1
sync=0
bitrate=4000000
# set below properties in case of RTSPStreaming
rtsp-port=8554
udp-port=5400

[osd]
enable=1
gpu-id=0
border-width=5
text-size=15
text-color=1;1;1;1;
text-bg-color=0.3;0.3;0.3;1
font=Serif
show-clock=0
clock-x-offset=800
clock-y-offset=820
clock-text-size=12
clock-color=1;0;0;0
nvbuf-memory-type=0

[streammux]
gpu-id=0
live-source=0
batch-size=1
batched-push-timeout=40000
width=1920
height=1080
enable-padding=0
nvbuf-memory-type=0

[primary-gie]
enable=1
gpu-id=0
gie-unique-id=1
nvbuf-memory-type=0
config-file=config_infer_primary_yoloV5.txt

[tests]
file-loop=0


In fact, I have consulted NVIDIA's official blog, but it still hasn't been resolved。see in: URL
my deepstream_app_config.txt is below:
[application]
enable-perf-measurement=1
perf-measurement-interval-sec=5

[tiled-display]
enable=1
rows=1
columns=1
#width=704
#height=576

width=1920
height=1080
gpu-id=0
nvbuf-memory-type=0

[source0]
enable=1
type=4
#uri=file:///opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4
#uri=file:///home/dvadmin/wxp/safeHat/video/show-safetyhelmet.avi
uri=rtsp://admin:beSdeV99@192.168.0.64:554
#uri=rtmp://192.168.0.186:1980/live
num-sources=1
gpu-id=0
cudadec-memtype=0

[sink0]
enable=0
#Type - 1=FakeSink 2=EglSink 3=File 4=RTSPStreaming
type=4
#1=h264 2=h265
codec=1
sync=0
bitrate=4000000
#set below properties in case of RTSPStreaming
rtsp-port=8554
udp-port=5400

[osd]
enable=1
gpu-id=0
border-width=5
text-size=15
text-color=1;1;1;1;
text-bg-color=0.3;0.3;0.3;1
font=Serif
show-clock=0
clock-x-offset=800
clock-y-offset=820
clock-text-size=12
clock-color=1;0;0;0
nvbuf-memory-type=0

[streammux]
gpu-id=0
live-source=0
batch-size=1
batched-push-timeout=40000
width=1920
height=1080
enable-padding=0
nvbuf-memory-type=0

[primary-gie]
enable=1
gpu-id=0
gie-unique-id=1
nvbuf-memory-type=0
config-file=config_infer_primary_yoloV5.txt

[tests]
file-loop=0


@brenzi Is this what you had in mind?
The state size saturates because hardly any transactions are processed. The number of accounts is directly linked to the number of transactions.
benchmark-with-state

Some findings:
- Keeping the state in memory instead of writing it on the disk definitely helps (see plots above)
 - The call `write_after_mutation(..)` in `apply_state_update(..)` is still getting slower over time even though it is now supposed to write anymore. Would need further investigation to see why.
- `apply_state_update(...)` in `impls.rs` is a function that generates more and more CPU load as the state grows
 - Calculating the hash over the state twice is quite expensive
 - Also the `clone()` and assignment of the copy grow more and more expensive as the state grows


Gesloten, omdat het verwerkt is in versie 1.2 en omdat die versie goedgekeurd is.


We changed the setting back to ` ` and could not reproduce the high-delay issue since then. Still not 100%, but we'll keep the `60:120` setting for now.


This jitterbuffer setting doesn't cause any problem for me. Since it's now 120 and everything is alright.
and when I was facing described problem, it was 60:120, and still not fixed (more than 2 seconds delay.)


I understand your use case of having quick access to a local file in an environment that's all set to get going, but it's not what this extension is built for, and easily something that external tools can provide on their own.

I don't agree. I'm not willing to drop the aforementioned consistency for the sake of adding partial parsers that are (in my opinion) out-of-scope for this extension.


Error 404 issued with the text the "unknow" text is not a valid resource Closing issue.
The 404 is given for both 4.0 and 4.3 fhir versions


Some first findings for a slot duration of 6s:
- Scenario: 100 clients generating 250 transactions as fast as possible
- The maximum number of transactions that can be in the queue is currently 8192
- The maximum number of transactions I saw in a single block so far is 5400
 - around 2000-3000 transactions is typical
 - Two threads are reaching 100% CPU usage on a core under these circumstances. So I think we reach some kind of CPU bottleneck.
 - The CLI client is also creating a lot of CPU load


Thanks. How does the throughput degradation look with growing state?


I just gave the script I put above a try on prod optimism, the tx for the initialize call fails there as well:

$ forge script script/Contract.s.sol --rpc-url $OPTIMISM_RPC_URL --private-key --broadcast --slow -vvvv [16:33:43]
[⠢] Compiling...
Nothing to compile
Traces:
 [113155] ContractScript::run()
 ├─ [0] VM::broadcast()
 │ └─ ← ()
 ├─ [49699] → new Contract@0x8eb4600bbab2286a46103f4923866de9653b737b
 │ └─ ← 248 bytes of code
 ├─ [0] VM::broadcast()
 │ └─ ← ()
 ├─ [22402] Contract::initialize(0x0000000000000000000000000000000000000001)
 │ └─ ← ()
 └─ ← ()

Script ran successfully.
Gas used: 113155
==========================
Simulated On-chain Traces:

 [106971] → new Contract@0x8eb4600bbab2286a46103f4923866de9653b737b
 └─ ← 248 bytes of code

 [43606] Contract::initialize(0x0000000000000000000000000000000000000001)
 └─ ← ()

==========================

Estimated total gas used for script: 128175

Amount required: 0.000000128175 ETH

==========================

###
Finding wallets for all the necessary addresses...
##
Sending transactions [0 - 1].
⠁ [00:00:00] [########################################################################################################################>------------------------------------------------------------------------------------------------------------------------] 1/2 txes (0.4s)⠉ [00:00:07] [#############################################################################################################################################################################################################################################] 1/1 receipts (0.0s)
#####
✅ Hash: 0x1a972cf266cbfd61a028e1fdd694686130ce4b6dc0c7202bd21212ef775c8589
Contract Address: 0x8eb4600bbab2286a46103f4923866de9653b737b
Block: 12073464
Gas Used: 106971

⠉ [00:00:07] [#################################################################################################################################################################################################################################################] 2/2 txes (0.0s)⠉ [00:00:07] [#############################################################################################################################################################################################################################################] 1/1 receipts (0.0s)
#####
❌ Hash: 0x1b07ca2cce8b7302dbdb0e4a257c07d19689647c50de8df8a3549a2eedd1a3ff
Block: 12073469
Gas Used: 21204

Transactions saved to: broadcast/Contract.s.sol/10/run-latest.json

Error:
 0: ["Transaction Failure: 0x1b07…a3ff"]

The failed tx.

But, notice that executing a tx with the same args but with `cast` and a gas limit of `75000` results in success:

$ cast send 0x8eb4600bbab2286a46103f4923866de9653b737b "initialize(address)" 0x0000000000000000000000000000000000000001 --gas 75000 --rpc-url $OPTIMISM_RPC_URL --private-key [16:41:41]

blockHash 0xf6c411ec971b21c1ec5c41487929b814bad5be151f4831de7b07d0e36c6a44c0
blockNumber 12074683
contractAddress
cumulativeGasUsed 43606
effectiveGasPrice
gasUsed 43606
logs []
logsBloom 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
root
status 1
transactionHash 0x1493c477c18629ab75f6759f95bed118517f6a4e66602460a2c3643c93486801
transactionIndex 0
type

So, seems like this is a gas estimation issue


Per @mds1 suggestion let's go with the following 2 steps:

1 Add a broadcast overload that lets you specify the gas limit for the tx, `vm.broadcast(uint256 gasLimit)` and `vm.broadcast(address sender, uint256 gasLimit)`
2. add bespoke logic for each L2, determined by chainId, this will need to be fork-aware when #1715 is merged

cc @joshieDo


We should probably add those broadcast interfaces. However, this is actually a result from another issue.

Since L2s have different gas calculations, we discard the gas estimated locally, and request a new one from the RPC. To support batching, they're happening at the same time for tx1 and tx2. However, tx2 needs tx1 to be submitted and accepted first.

We should probably force `--slow` on L2s or any other transaction that requires `--slow`. In this case, even with `--slow` won't work, since we estimate everything before we start sending, which needs to be fixed.


I was under the impression Arbitrum and Optimism had different gas metering, but it seems that only Arbitrum has.


Going to publish this build later today as a release. Can someone do a final test?


- This is a similar plot as in #775 but with a slot time of 6s and 100 clients instead of 20 (leading to more transactions per block in general)
- As expected the throughput remains unaffected by the CPU for a longer time.
- In the end the state was around 20 MB in size, so still a long shot from 128 MB. I think it will be difficult to reach 128 MB with the current benchmark.
- Every 6s there is a high amount of interrupts on the system (around 7500/s). Seems quite high. Not sure this can be explained with just disk IO or network.
- The system seemed to "recover" at the end for a bit before degrading again. Not sure what happened there. Maybe something else was consuming system resources for a while (compiling or so)

benchmark-slot-time-6s-100-clients

@brenzi @masapr


Just summarizing what we ended up on as the path forward:
1. Remove Optimism from the `has_different_gas_calc` function

 URL
 URL

2. Force `--slow` on Arbitrum and Optimism. Both of don't have mempools like L1's so if you send multiple txs they get rejected with `nonce too low`.

3. Move RPC gas estimation right before sending the intended tx, and add a note to the output indicating the "total gas/ETH cost estimates" shown beforehand aren't guaranteed to be accurate (since we don't estimate Optimism costs correctly)

4. This one wasn't settled on, but I think we should change the broadcast overloads to specify margin on the gas estimate, instead of absolute limits. So if I'm estimating gas for a uniswap v2 trade where cost varies by block position, I can do `vm.broadcast(20)` to mean "add 20% margin to the gas estimate". IMO this is better UX than needing to harcode gas limits directly.


In the meantime we should try to get Mac x64 version running on M1. Right now it just blows up with
`Could not find the package with 'earlephilhower/toolchain-rp2040-earlephilhower @ ~5.100300.0' requirements for your system 'darwin_arm64'`
Rosetta emulation works pretty well for most apps. Is there a flag or a way to force PlatformIO to just use the X64 version of the toolchain package?


Yup, that'd be the problem right there...it is looking for `darwin_**arm64**` and not falling back to `darwin`. What app are you running?


Thanks Vikas. It looks like the client was dependent on $validate being served at `[base]/Resource/$validate`.
We used to support that but I removed that support in #3265.
I think we'll need to update the client to infer the resource type from the resource that was passed.

 URL for more info.


I'm running PlatformIO with the latest config that looks like

[env:OpenPPG-CRP2040-SP140]
platform = URL
board = sparkfun_promicrorp2040
framework = arduino
board_build.core = earlephilhower

board_build.filesystem_size = 14M ; 14 Mbyte for filesystem and 2 Mbyte for program

I see on the PIO registry that as expected its not showing a version for Mac Arm64
 URL


Ah, I see. Arduino doesn't know what `darwin_amd64` is...it doesn't even know what `winx64` is and that's waaaay older. :(

Is there an override to specify the PIO architecture? the Mac x64 binaries are good and should run (as they do in the IDE) but just a little slower since evidently Rosetta 2 is pretty good stuff.

Alternatively, I might be able to publisy the Mac x64 binaries as Mac ARM64 but that seems like cheating and might cause some grief upstream...


during the linear phase, you create 100'000 accounts within ~1900 blocks, 6s each. If the number of accounts equals the number of tx, then we only have 8.77 tps. As I understand, this low throughput is caused by the limited number of clients.
I suspect we would see degradation much earlier if we could send more tps. I guess we need to combine burst tests (send tx without waiting for any confirmation with this state growth test. Possibly with one service per strategy, simultaneously hitting the validateer. What do you think?


Yes the throughput is limited by the number of clients. I did not test with too many clients on purpose as I did not want to introduce new issues/problems due to that.
At the moment the tests without waiting are very hard to control and then to make sense on what happened.
Maybe we could add some kind or rate limiting. For example each client can have N outstanding transactions or send maximum N transactions per second.
I think this could help to increase the throughput while still maintaining some kind of predictability and control.


I'm confused about the 8.77 tps. Above @Niederb said, he has 2000-3000 transactions in a single block. With a block time of 6s this results to 333 tps, doesn't it? Wouldn't that be the result?


@vikforfda what kind of object is your `finalBundle`?

our FHIRClientImpl validate implementation is already invoking validate on a type-specific basis, and so I now suspect this is an issue with your code and not ours.


Sorry, but I don't know what's going on in your case. Here it works normally.


Hitting into some trouble syncing Jellyfin from the providers (AniList/MAL/Kitsu -> Jellyfin).
As most of the APIs don't contain the season number, we can't actually tell what season the user is on. Luckily each item in the providers database is a separate season.
The obvious way to accomplish this is to get the users watch list from the appropriate provider, get the IDs of the anime in said list and then run them through the anime offline database to get the AniDB ID and AniList ID of each season (if we are not using it as the selected provider to sync from) and then cross reference that to Jellyfin's database to see which seasons we have locally that match the IDs (we cannot use the local anime list XML file as that would only give us a TVDB ID which is bound to the series, not the season).
Only problem being is that Jellyfin does not seem to store season provider IDs, at least not for me. It stores the _series_ provider IDs, but not separate seasons.
The only time that we will get a match with a provider ID from the Jellyfin database is if we are working with the first season of a show from the users watch list.
Could someone please confirm that it isn't only me not having any provider IDs (labelled "external IDs" in the Jellyfin interface) for seasons? I have tried running the metadata fetcher multiple times and I don't get any extra provider IDs for seasons. I get a TVDB ID, but when I cross reference it with the XML file I get no results. I'm not entirely sure what the ID represents as I even tried looking it up on TVDB but got no results.


For accurate fee estimation on Optimism, the L2 (execution) fee and the L1 (availability) fee needs to be taken into account. See here for how to do so. If special logic is added that is chain aware, perhaps handling this could just be abstracted away from users. See URL for a higher level explanation


This is a flamegraph that is maybe worth looking at:
flamegraph-worker-good.svg


If we did this we'd have to be a little careful about how it interacts with the special behaviour of some tags and showing notes based on a request's tags (#6912).

Let's say we have a Note that applies to requests tagged `foo`. This would likely be deducible from the exposed tags and the note content. Users could then add `foo` to other requests and the Note would appear, whether relevant or not. Do we want e.g. #7106 to be user-controllable?

We could automatically generate a moderation notification in this scenario based on the fact that we'd know an added tag relates to a Note or special behaviour, but that creates admin work. Would we then also want to tweak the behaviour of #6912 to list out content that an in-creation Note would get added to in the case that the tag `foo` unexpectedly exists on some requests?


### 1. Brisanje nepremičnine
Težava je, da želite iz tabele `komitent` izbrisati vrstice, kjer se kupuje nepremičnina, ki jo želite izbrisati. Trenutno brišete iz tabele komitent vrstice, ki imajo v `id_komitent` vrednost `id`, namesto v `kupuje_nepremicnino`. To lahko rešite tako (namesto vaših vrstic 505-515):

python
cur.execute("DELETE FROM hisa WHERE id_hisa =%s" % (id))
cur.execute("DELETE FROM stanovanje WHERE id_stanovanje=%s" % (id))
cur.execute("DELETE FROM komitent WHERE kupuje_nepremicnino=%s" % (id))
cur.execute("DELETE FROM nepremicnina WHERE id =%s" % (id))
conn.commit()

### 2. Težava z vpisovanjem emša

Poleg tega sem opazil pri vas težavo: če med registracijo vpišem svoj emšo, mi vrne napako

python
psycopg2.errors.NumericValueOutOfRange: value "1812999500000" is out of range for type integer
LINE 3: VALUES ('1812999500000', 'Maj', 'Gaberšček',...

To se zgodi, ker imate stolpec `id` v tabeli `oseba` tipa `SERIAL`, ki omogoča samo števila do $2^{31} - 1$. Svetujem vam, da stolpcu spremenite tip na `BIGINT`, ki omogoča precej večja števila (do $2^{63} - 1$). To lahko storite z ukazi:

sql
ALTER TABLE oseba ALTER COLUMN id TYPE BIGINT;
ALTER TABLE agent ALTER COLUMN id_agent TYPE BIGINT;
ALTER TABLE komitent ALTER COLUMN id_komitent TYPE BIGINT;


Seveda pazite še na to, da ne odpirate možnosti napadov SQL injection - tako kot drugod podajte `id` v seznamu kot drugi argument metode `execute` (tj., ga ne vstavljate v niz s `%` ali na kak drug način), npr.

python
cur.execute("DELETE FROM hisa WHERE id_hisa = %s", [id])

Kar se tiče EMŠOv, kot je opozoril @majbc1999, bi predlagal, da jih imate kar v poljih tipa `TEXT`. Morda bo celo bolje, da pustite `id` v tabeli `oseba` tipa `SERIAL` (in tako ostanejo nespremenjene reference na ta stolpec), sam EMŠO pa imate v svojem stolpcu (z omejitvijama `NOT NULL UNIQUE`, da se vrednosti ne bodo ponavljale), ID-je pa pustite, da se vam sami generirajo.

Še to: vidim, da na več mestih uporabljate funkcijo `url`, ki pa ji podaste kar pot (tj., začne se z `/`). Prvi argument funkcije `url` naj bo kar ime ustrezne funkcije - tako se bodo zgradile ustrezne poti tudi, ko boste aplikacijo poganjale na Binderju. Seveda na isti način gradite poti tudi v predlogah. Za več podrobnosti si poglejte MatejRojec/Gamma#1.


At this point I feel pretty satisfied just having this be a distinct category of finding, "override conflict" -- distinct from "irrelevant annotation" and from "types not assignable". Does that make this issue resolved?


Ref: xmega relared issues
* URL
* URL
* URL
* URL
* URL
* URL
* URL
* URL
* URL
* URL
* URL
* URL
* URL (but also affect other AVR chips).
* URL
* URL
* URL


Having another category of finding sounds eminently inoffensive :)

I imagine that we'll have more to discuss around:

- any user-facing docs about this
- the more general question of whether the _spec_ makes these sorts of distinctions

But it sounds like the high-order bit is the "just" in your proposal: We get most of what we want by calling this "another category" without additionally trying to take positions on whether a particular way of annotating is "correct," what tools should do, etc.?


The issue was on our side. We were using an older version of fhir client to invoke the validation operation API. After we updated it to use versions 4.11.1 (most recent IBM-FHIR release) or 5.0.0-SNAPSHOT (corresponds to the WIP IBM-FHIR R4b release) then the validation correctly identified the error


Hvala za pomoč, smo popravile tako izbris nepremičnine, kot tudi url povezave.


I have now got it updating shows from a users AniList watched list.
Just need to clean it up and get it working with other providers.


That must be due to the recent update to fix the un-deleted trees bug #4. I thought I tested that in MP, but I guess not! You can always go back to the previous release for now while I look into it: URL


Not sure how to download mods manually. Any chance you can point me in the right direction? Removing the mod from the server and uploading the previous release to the server and placing it in the mod folder on the harddrive seems like the logical way to go.


I think it was the most embarrasing mistake I've ever made!
image

At least easy to fix. New release incoming.


I was thinking about this the other day, and I think I have a solution that'd work nicely: a `CustomNames` plugin on the Kaleidoscope side, which we could use to store custom names for keys or layers, in eeprom or in progmem. Chrysalis would simply query the names, and use those instead of the built-in ones.

For storage in EEPROM, I'd use the following format: 4 bits for the type of name, 4 bits for the number of names (N). Then we have N index->name mappings, where the index size depends on the type, and names are NULL terminated. Initially, we'd have two types: layer & key names. For layers, the index is 1 byte, for keys, its two bytes. If we need to have more than 16 names of the same type stored, we can store multiple series of the same type. The serialization ends when the number of names is 0.

So, for example, to have a custom name for layer #0 and #1, and a custom name for Dynamic Macro #0, we'd encode it as:

 "QWERTY\0" "FUN\0"
 "Greet\0"

For PROGMEM, it's a bit tougher, doing this kind of encoding at compile-time is more difficult. I'm not sure what the best approach would be there.

Maybe if we separated type and length... that'd allow 255 custom names per type, should be a plenty, even if we disallow multiple series of the same type (but we could have multiple series anyway). But maybe I can fit the bit fiddling into a macro. We'll see.

In any case, to keep up with the spirit of storing keymap and keyboard settings on the keyboard, I'd store the custom names there, too, rather than somewhere on the Chrysalis side.


we got RN 0.69 released but the error 'react/config/ReactNativeConfig.h' file not found is still here


Which version of the auto hatchery script are you using ?
If you dont want to update, you will need to use a version before the commits on the 26th
 URL


The script version is 1.6, which seems to correspond with the latest version. Do these scripts update automatically? That would explain it. Is there a way to avoid this update process? Thank you very much!


V1.6 contains yesterday changes which were made for pokeclicker v0.9.6 and are unhappily not retroactive.
I do not know how the scripts work for windows and how they are updated so I am not of a great help here :(


The scripts should update automatically and should also support new scripts, at least this is the design of it and how I made the client edit initially work, but then again ever since catchfilterfantasia got introduced, that has also been causing problems.

It's likely that the custom edit needs to be updated and needs to be looked at, but then again I haven't touched this or have been wanting to maintain this since January.


I think I'll update to 0.9.7, since now the XP nerf isn't that bad, and everything should work ok. Thanks for taking the time of looking into it.


The docs on the website need to be updated. `quarto publish gh-pages` is specifically made to work with the `gh-pages` branch not a docs directory. We will do this soon.


I can confirm that there is problems with some newer scripts.

The last additionalvisualsettings is just broken. It doesn't load, OR it loads but other scripts don't. Seems to be random on every reload of the desktop app.

Some goes for catchfilterfantasia. Sometimes it just load alone, or 99% of the time it doesn't load at all. (and even before the last additionalvisualsettings update)

Also, perkypokeruspandemic seems to never load.


Haven't had the issue it loading but not other scripts loading for any of them, the ones I mentioned just outright refuse to load anymore.

From what I can tell it's something to do with a `var` to `const` change, because if I put them into the `scripts` folder and do a rename for every `const` to be `var` instead it works perfectly and loads, same with the other two scripts (changing all `const` to `var).


About where things are currently with Desktop support: URL (well thought I'd include this in for transparency)

As for the changes being mentioned, I suspect it's maybe the changes being done to the initialization portion (unable to test these myself atm and hadn't prior).

Try reverting just this portion of the script and keep the rest of the variable declaration (const & let) changes throughout the rest of the script:
image

If this is the issue I can revert it in the next revision being worked on at the moment, and changing this in a few other scripts where it may be problematic.


@Ephenia Yep that's exactly it from the looks of things, as reverting that portion back to the previous revision seems to make things work and load correctly, can also confirm that it changing that partion in the other scripts that I mentioned above works as well.


@Ephenia actually scratch that, it's causing other issues and idk why I didn't notice >.< for some reason or another it's now only loading a portion of the scripts. So many others just seem to disappear..

Going to test a bit more to see what is causing this new issue.


Okay after a bit more testing I have found these things:

doing the above does work correctly but there seems to be more changes needed in at least the `additionalvisualsettings` script, from what I can tell I needed to change the

let checkWildPokeName;
let checkWildPokeDefeat;
let checkWildPokeImg;
let checkWildPokeHealth;
let checkWildPokeCatch;
let checkAllNotification;
const notificFunc = Notifier.notify;
let newSave;
let trainerCards;

to be

var checkWildPokeName;
var checkWildPokeDefeat;
var checkWildPokeImg;
var checkWildPokeHealth;
var checkWildPokeCatch;
var checkAllNotification;
const notificFunc = Notifier.notify;
var newSave;
var trainerCards;

to actually make it work and stop the whole other scripts randomly disappearing act also seems that only needing to change the `const scriptName` and `const scriptElement` to be `var scriptName` and `var scriptElement` is what is needed for the loadscript function (from what I can tell)


oof I can't seem to test now as I'm now randomly getting this error for some reason >.<
06-29-2022_22-23-32


@Ephenia Okay back to normal, from my latest testings everything is now working correctly from the looks of it, other than `catchfilterfantasia` is the only one missing.


Loving all this information and all the testing that you're doing, you're a huge help and I really appreciate it as well as your time! I must say that you're great with providing quality testing. You're always free to hit me up personally too if you want by the way, if it would also be easier or more convenient.

Anyway, are you happening to load all of the scripts by the way?


@Ephenia it's not a problem at all, I try my best to test things and figure things out as I go along with issuing bug reports and such :p

Sounds good :D

as for loading all the scripts, the only one that seems to be missing/not loading currently on multiple refreshes is the `infiniteseasonalevents` script. Everything else seems to be at least loading correctly now for the most part from my multiple refreshes from what I can tell.


Maybe the simpleweatherchanger could be bugging it out or interfering with it, since it also had the slight change to initialization. But, if that isn't it, then loading the script standalone would definitely tell if the script itself is the issue, probably.


yea shit so confusing, because if I go to put `infiniteseasonalevents` script into the scripts folder to load it standalone, it then makes the `catchfilterfantasia` stop loading instead xD


You should be able to override all the scripts with blank ones with the same names and just have `infiniteseasonalevents` load, at least this should still be doable (I think) ;p


okay so did a little bit of testing with everything blanked out in scripts and then moving between these last 3 (infiniteseasonalevents/simpleweatherchanger/catchfilterfantasia) these are the things I noticed:

With `infiniteseasonalevents` and `simpleweatherchanger` being the only two that wasn't blanked out, they loaded fine, if I re-added `catchfilterfantasia` it stopped loading the `infiniteseasonalevents` but `simpleweatherchanger` would still load, blanking out `simpleweatherchanger` didn't seem to bring back `infiniteseasonalevents` however if I was do that, if I was to blank out `catchfilterfantasia` again `infiniteseasonalevents` would however load just fine again.

so from this bit of testing it seems to be something to do with `catchfilterfantasia` causing issues atm.


Hm... quite interesting...

I wonder if it has something to do with the use of `window`, which may be unfortunate if that's actually the case.


hmm yea that could possibly be it, sadly with how late it is getting here and the fact I sadly have to work in the morning I may need to call it a night on testing for now and come back to testing things again once I return from work tomorrow. I'll throw you an add on disc tomorrow once I'm around and we can see if we can figure things out.


I'm pretty late because I didn't have much time. Anyway, I tried doing this but it doesn't work for me. It appears the executable does not see variables set in `LSEnvironment`, so the app cannot start.

Apparently `LSEnvironment` by processes started via "Launch Services" and not via terminal (source?). However, it also does not work for me when I try to launch it from Launchpad. Maybe it's because I'm using the old macOS 10.15.7 (the latest I could install into VM)? But in any case, I would like if launching from the terminal (using `firefoxpwa site launch` and `open`) would also work.

Is there any more reliable way of setting environment variables for a bundle? Or, is `swiftc` included in standard macOS out-of-the-box? This isn't the nicest solution, but maybe PWAsForFirefox could compile a new executable when installing each PWA and include `exePath` and `pwaId` directly in the source code.


Sent you a FR on discord, and should be around for most of the day.


Of the 4 items listed in my above comment, I believe 1 and 2 are implemented, 3 and 4 are not.


please follow the issue template by providing a codesandbox to reproduce this issue then will reopen and look into it.


It looks like vite@2.8.6 is the last working version

I was able to revive the examples (I tried `examples/svelte-kit`) with pinning vite-plugin-svelte and vite package versions in package.json:

jsonc
// package.json
{
 ...
 "devDependencies": {
+ "@sveltejs/vite-plugin-svelte": "1.0.0-next.36",
 ...
+ "vite": "2.8.6"
 },
+ "pnpm": {
+ "overrides" : {
+ "@sveltejs/vite-plugin-svelte": "1.0.0-next.36",
+ "vite": "2.8.6"
+ }
+ },
 ...
}


I am facing this issue while trying to build my app on Netlify. URL

In my packagelock.json I see the following:

"node_modules/ethereumjs-abi": {
 "version": "0.6.8",
 "resolved": "git+ssh://git@github.com/ethereumjs/ethereumjs-abi.git#ee3994657fa7a427238e6ba92a84d0b529bbcde0",
 "license": "MIT",
 "dependencies": {
 "bn.js": "^4.11.8",
 "ethereumjs-util": "^6.0.0"
 }


Codesandbox link: URL

Although the app runs in the sandbox (it fails for me locally), if you open src/TextField.tsx and src/MyForm.tsx you will see the highlighted errors.

Change the react-hook-form dependency to 7.32 and it makes those errors go away.


Going to split this in two, because they will be implemented separately: custom layer names (this issue), and custom key labels.


Same problem. The typedef has some sort of breaking change where it no longer passes a string.


Thank you so much! It's working perfectly as I expected... 🚀


Same problem. Something is off with the typedef…

`TS2367: This condition will always return 'false' since the types 'Merge >> | undefined' and 'string' have no overlap.
 199 | maxLength: 110,
 200 | }}

 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 202 | />`


can you provide a codesandbox to reproduce the issue or supply a test case to demonstrate the issue?

Screen Shot 2022-07-04 at 6 02 15 pm


If you want to use Fabric in your app you need to install Reanimated 3, but if you just want to use react-native@0.69 you should use Reanimated 2.9.1


We could use tagging to help capture PIT extensions, which could help to differentiate between requests that are illegally late, and ones where the deadline had been legally extended. This could even feed into the Pro dashboard in some way.


the enabling of asymmetric liquidity adds is on pause at the moment. To tackle this issue, it is suggested to try multiple times


Probably it could be helpful for someone, I tried workaround suggested above ( URL but i need to use server side search by many attributes, and if i simply add `no-filter` prop then selected options would still be displayed in list, regardless of whether they meet search condition or not.
So i added `filter` prop with following value:

 filter(item) {
 return this.searchResults.some((itemFromServer) => itemFromServer.id === item.id)
 },

Here i just check if item exist in array received from the server. And if it exists, then it will be displayed in the list. If it not, then it won't be displayed, but it still will be presented in VAutocomplete items, thus selected items remain visible.


<img width="613" alt="image" src=" URL

It's working because there is no type check.


Forgot to update here recently but I believe I have got updating the Jellyfin library from providers anime list fully working.
I have added a warning to let users know that the feature is in "alpha" and that it may disrupt their Jellyfin libraries.
Next to do is to get the other direction working (Jellyfin to provider anime list).


What if 0.68.2 (expo 45) is a hard requirement and the app depends on reanimated?


Support for Rcurl and httr are now in the Postman platform

<img width="482" alt="image" src=" URL


This issue has been mentioned on **NixOS Discourse**. There might be relevant details there:

 URL


The issue seems to have unfixed itself at the moment: see #9698 and #10159


Revisiting this, I believe that the default behavior is incorrect in the Traefik charm. The current default when in path_routing mode requires that the backend's webroot be updated in order to service the request proxied through or a 404 will be served. In fact, no configuration changes should be *required* in order for the proxied requests to succeed. If it is Traefik that adds the path-prefix for routing purposes, then it should strip the path-prefix by default before sending this off to the backend. In other words, the backend service should not have to care about how the ingress service proxies the request.

To be clear, the url that is currently passed to the backend should continue to be the public endpoint that is exposed by Traefik. Services that need to know should be able to opt-in and that, I believe, would be a good use case for traefik-route. I believe things should just work by default for the general use case.


We will need to elevate this issue to a higher priority, we now have empirical results on how long it takes to generate a root key in multiple arenas:

1. Tests
2. AWS fargate

On fargate, using the 0.25 CPU containers, it takes 20 minutes to generate a root key pair. Se can be seen by this cloudwatch cpu utilisation graph:

cpu

At the same time, key generation is using all cores by default. This doesn't even require the worker manager to be integrated, I think `node-forge` does this by default.

We believe that this is causing CPU starvation of all the other testing workers that jest creates and thus leading to test timeouts as can be seen in #394.

As we have deployed our testnet, and we expect the need to autoscale the agents, key generation is going to be an important workload, as it delay the scaling up process. Remember even if we pass in a recovery code, the keys must still be generated and this still takes time.

Furthermore we want to get #168 done before going to mainnet, because at that point users will be using our system, and we don't want to get stuck on legacy RSA.


I agree - I think using the StripPrefix middleware in the default path-based routing mode would make sense.


I faced this issue while using yarn to get the dependences, I disabled SSL Verification by running:
_git config --global http.sslVerify "false"_
and it worked!
Erro (2)


It's possible to override the number of workers that the `generateKeyPair` `src/keys/utils.ts:64` uses. We can provide `workers: 1` as part of the options.


JpGraph is not deprecated. It is just not maintained in Composer, and the version there is not Php8 compatible (maybe not even some versions of 7) so we can't allow its use in our test suite. However, you can manually substitute the current version of that product for the version that Composer brings in, and it should work just fine. I have no idea what it's doing with lineMarker, but am reluctant to make it stop working (under the uncertain assumption that it works now).

As for smoothLine, that was one of your first requests that I worked on. It seemed to me at the time that Excel required it at both the DS and the DSV levels. I can look into it again.


This annoying behavior tripped me up while I was testing Axis cases.

Thank you for the JpGraph clarification - I had hoped to use it, and I now feel free to try it - if I can find a compatible version.

[N.B. I understand removing properties is a breaking change, but having two identically-named properties in two similarly-named classes (DataSeriesValues & DataSeries) with identical getter/setter methods is seriously confusing. At least to me.]

I repeat my previous request to remove DataSeries property $smoothLine and its getter/setter methods. In a ScatterChart, the accidental assignment of 'lineMarker' to $plotStyle will suppress a $DSV whose $smoothLine property is true, and the user will have a difficult time discovering the reason for the resultant straight-line. To prevent this unfortunate circumstance, I propose that Writer/Xlsx change the qualification for the call to startElement('c:smooth') in the "// Values" section of function writePlotArea() from:

WAS: if ($groupType === DataSeries::TYPE_SCATTERCHART && $plotGroup->getPlotStyle() === 'smoothMarker')

IS: if ($groupType === DataSeries::TYPE_SCATTERCHART)

This will allow a $DSV->smoothLine property value of TRUE to be expressed correctly in the xml regardless of its containing $DS->plotStyle value, (which is the correct behavior in my opinion.)


Under what circumstances would you "accidentally" set the style to lineMarker? It sounds like you're trying to get PhpSpreadsheet to ignore something the programmer has explicitly requested - it certainly isn't used as any kind of a default. Perhaps, after looking at the finished product, smooth lines aren't desired after all, and it's easier to change the DataSeries property to lineMarker in one place than it is to remove the smooth declarations from all the DSVs? It is possible that you can make a stronger case for using the c:smooth tag for "not lineMarker"; I would still need to think about that.

Issue #2783 has more details about how to use JpGraph.


Excel describes 'smooth line' charts as well as 'line charts'. It is not a stretch to associate those choices with 'lineMarker' and 'smoothMarker'. But what if you want a mix?

I submit that a programmer who assembles a ScatterChart may simply ignore assigning any value to the DS->plotStyle property since it is possible to desire an XY chart with both smooth lines and straight lines, and maybe no lines. So the programmer omits it, and its value is null. If the programmer has assigned TRUE to any DSV->smoothLine property, she will be mystified why it doesn't work. (We'll know, but she won't have much of a clue.) Changing Writer masks her (unfortunate) choice of not assigning 'smoothMarker' to DS->plotStyle.

Thank you for the JpGraph link.


I just wanted to encourage continued work on this issue. I'm trying Miryoku on the Atreus, and it has 6 layers, and it's really hard to remember the main purpose of each layer without custom layer names such as Mouse, Function, Numbers, etc. This is true both for mapping the keys initially and for having the layer names on the layout cards I want to print for reference to learn the layout.


The Chrysalis side of this is pretty much complete. We just need to figure out how to approach the firmware-side, and we're good to go. It's coming soon™!


Honestly, I would love it if you just released the Chrysalis part and stored the information in a file on the computer while working on a solution to store it in firmware also. I bet most people are like me and do their keyboard configuration on one main computer, so for those people having the info in a way that can be viewed in Chrysalis and printed out solves 98% of the issue. Storing the custom names for the layers in firmware is nice also but doesn't seem as necessary. Just IMHO.


I have answered this at length in both URL and our discussion in Discord. Capturing the core bit from the latter:

Continuing to conflate "Linux-specific Dart" and "Flutter-1P-Linux-embedding-specific Dart" isn't constructive.

That support already exists; you can write Linux-specific Dart using `Platform.isLinux` checks.

If what you want is the ability to auto-generate Dart plugin registration code for your custom embedding, as I've said before we're happy to review designs for such a system, as part of the custom embedding hook support in the tool.

What you are specifically requesting here though, which is for your embedding to get Flutter-1P-Linux-embedding-specific Dart, is a wontfix.


This is related to udev not initializing devices. NetworkManager never completes startup because a WireGuard interface is never initialized by udev. A workaround is just putting the affected device into `networking.networkmanager.unmanaged`.