How do you use the toypadEmu js files?

Just wondering how the toypadEmu js files are used. Not fimiular with Hex and also tried playing with charCryptoExample.js to no avail. Thinking maybe theses are not for pc or used with the toypad base. Looking for a little direction.

While the Toypad class processes the protocol to communicate with the toypad,
toypadEmu is for communicating as the toypad.
I have it running on a Raspberry Pi Zero that has been programmed to pretend to be the portal when connected to my WiiU. Therefore I have total control over what data the WiiU gets from the emulated portal. (AKA: placing characters without having an actual portal)

Ok that explains a lot. Would be intrested in how this is setup.
Saw an older video for Disney Infinity which used 2 itzy (unsure of spelling) USB HID emulators connected to each other and a laptop. Also had a passthrough for Xbox 360 version of base. https://youtu.be/6MNwy_pa35A
Thought it could be intresting for you.

itzy

https://www.pjrc.com/teensy/

connected to each other and a laptop.

https://github.com/brandonlw/USBSimulator

I actually bought two small boards like that after seeing that video. :)
After failing at avr coding, (I am not good at hardware coding) I switched to an Odroid C1+ and uses its OTG port.
Then it was discovered that the Pi Zeros OTG port is usable.
The Pi has an advantage of a mainline kernel so was much easier to deal with
I'm using a kernel that Adafruit compiled with CONFIGFS support, which allows me to have a basic script to setup USB emulation. (Also works on ANY linux device with CONFIGFS and OTG support)

Glad this was of use. Will be trying to get a Pi Zero  once they come back in stock. Really intrested in seeing how this works.

Have a Pi Zero now and ordered a USB to TTL serial cable so I can still connect when board usb is in use. Taught myself how to run scripts at startup with Linux (as service). Will try keyboard HID elum first and more up from there. Am I taking the right path?

Yes. :) Also, the main kernel has configfs support now, so that makes it easier. (No custom kernel needed)
Heres the script I used to setup the usb gadget, it creates a device at /dev/hidg0 than can be read/written like a file.
http://pastebin.com/TpJvZJtP

Notice toypadEmu.js is no longer in latest samples. Use older version of node-ld and got following error. Any ideas?
pi@pizero:~/node-ld-master1/samples $ sudo node toypadEmu.js
module.js:340
throw err;
^
Error: Cannot find module 'lodash'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/home/pi/node-ld-master1/lib/common.js:1:71)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)

Sorry about that, I imported a ton of repos from my private git server when github changed to unlimited private repos, it looks like it pushed the node-ld from there which rolled it all back. I have re-pushed the correct repo so it should work now. Also note that it can be easily installed by npm install node-ld too ;)

Hi,
Took me a while to find out how to update node and npm. Once I managed to do that and ran the command alot of errors came up. Think i'll try again next weekend. Screen output and logs attached for reference.
screen_output.txt
npm-debug_log.txt

From what I can tell, it looks like you've got the distro gyp program installed which is outdated, it comes bundled in npm.
try
sudo apt-get remove gyp
npm explore npm -g -- npm install node-gyp@latest

Hi,
I believe I managed to finally update all the parts needed. The command above removes npm and nodejs needs removing and reinstalling to fix. Founnd node-gyp install/update works.
The output was the following
pi@pizero:~/script/ld $ sudo bash setup
--2016-05-21 21:55:04--  http://repo.ags131.com/install.sh
Resolving repo.ags131.com (repo.ags131.com)... <IP_ADDRESS>, 2607:5300:60:4759::
Connecting to repo.ags131.com (repo.ags131.com)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 181 [application/octet-stream]
Saving to: ‘STDOUT’

              100%[=====================>]     181  --.-KB/s   in 0s

2016-05-21 21:55:05 (3.08 MB/s) - written to stdout [181/181]
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.zfXgmeCnEF --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --fetch-keys http://repo.ags131.com/repo.ags131.com.gpg.key
gpg: key E334008C: "Adam Shumann<EMAIL_ADDRESS>not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

Hi, had some success with usb serial and ethernet devices. Will try to setup something I found called a "g probe" (gadget probe). Looks very simular to one provided in a past comment .Why does your script remove a number of modules at the end?

the script removes the other modules as they conflict, libcomposite is the one exception, it ends up reloaded

I keep getting "usb device descriptor failed" message from pi zero. Maybe i do need to switch out kernel. USB serial cable blue screened my computers and have returned that. Will give up for now. Did write a script node-js npm gyp update script which worked. Also descovered two pi's can communicate between serial connections. Thought far top left pins on pi zero back were for lan but after researching found out its for teensy.

Hi, managed to get the pizero to show as a lego 2.0 reader. PC is asking for driver though (real base does not). Also read up and there could be something missing. Possably a little c program to allow node to talk to HID devices (dev folder)

Using configfs it should create a /dev/hidg0 device, node-ld automatically uses that for toypademu.
Make sure your configfs only has a HID device added, and not ecm or acm.

Can you help me :) ?
OS: Windows 7 x64
Nodejs: 4.1.2
C:???\node-ld-master\node-ld\samples>node toypademu
C:???\node-ld-master\node-ld\dist\lib\ToyPadEmu.js:53
if (!opts.transport && opts.transport !== false) opts.transport
= new ld.transports.RawTransport('/dev/hidg0');
files.zip
  ^

ReferenceError: ld is not defined
at new ToyPadEmu (C:???\node-ld-master\node-ld\dist\lib\Toy
PadEmu.js:53:73)
at Object. (C:???\node-ld-master\node-ld\samples
\toypademu.js:3:10)
at Module._compile (module.js:434:26)
at Object.Module._extensions..js (module.js:452:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:475:10)
at startup (node.js:118:18)
at node.js:952:3

toypadEmu will not work on windows unless using a socket based transport (TCP, UDP, etc).

So i try to install it on a RPI Zero , but the same issue.
OS: Raspbian Jessie  2016-05-27
Nodejs: 4.1.0
http://img5.fotos-hochladen.net/uploads/bild11mu2jhvpcx.png
I also had a problem when generate the dist folder . The install script runs through clean , but lacks the dist folder .
I have both sudo npm install node- ld , and sudo npm install attempts .
It would be great if you can help me :) .

OK, just ran it on my end, adn for some reason ld is undefined, you can solve this by editing toypadEmu.js to have
var tp = new ld.ToyPadEmu({
        transport:  new ld.transports.RawTransport('/dev/hidg0')
})

Funny, i had the same problem. Got the piZero to should up. Hopefully this will be the last piece of the puzzle.

The problem is thus solved , thanks for that .
Here already is the next error ; ( .
pi@raspberrypi:~/lego/node_modules/node-ld/samples $ sudo node toypadEmu.js
/home/pi/lego/node_modules/node-ld/dist/lib/ToyPadEmu.js:60
_this.burtle = new ld.Burtle();
^
ReferenceError: ld is not defined
at new ToyPadEmu (/home/pi/lego/node_modules/node-ld/dist/lib/ToyPadEmu.js:60:22)
at Object. (/home/pi/lego/node_modules/node-ld/samples/toypadEmu.js:3:10)
at Module._compile (module.js:434:26)
at Object.Module._extensions..js (module.js:452:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:475:10)
at startup (node.js:117:18)
at node.js:951:3

I patched ToyPadEmu and did a push, looking at file history it got broke when I standardized to ES6 classes everywhere. It should be working now, I can't easily test as I'm at work right now.

should be a simple npm install node-ld to update

Ok , now he wants firstonce install :) .
I thank you in any case for your quick and good help !

The emulator seems to work, but he is very buggy.
Now I have to ask whether it is up to the software or the hardware.
My problem is that the emulator works sometimes and sometimes not. Time will come all the figures and another time comes from only one part.
I suspect the error comes from the module libcomposite. Your script tries to quit, but that is not possible.
$ Rmmod: ERROR: Module libcomposite is in use by: usb_f_hid
When I start the Raspberry I am able to quit the module libcomposite.
But that disappears the "/ sys / kernel / config / usb_gadget" and I can not use the emulator.
I use the PS3.
Do you have an idea?
Best wishes
chaos

One thing I have noticed, if adding and removing figures too rapidly, the game will ignore some of them, try adding a delay between placing/removing multiple.
Also, while that script does try to remove libcomposite, libcomposite should not be removed. I've since corrected that in newer copies of the script.

Ok I'll try it.
Thanks anyway for this emulator :) .

Ran these two commands after installing node. One does not appear to do anything but the other returns an error.
I am using raspbian jessie lite.
pi@pizero1:~/node-ld/samples $ node toypadEmu.js
pi@pizero1:~/node-ld/samples $ nodejs toypadEmu.js
module.js:340
throw err;
^
Error: Cannot find module './dist/node'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/home/pi/node-ld/index.js:1:80)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)

Finally got the correct version of node and this worked in my pi zero. Ran your npm install command but could only run from .stage folder. Used js timeouts to add delays between tags.
Suggested improvement is to have interactive script for pre defined tags. E.g. press 1 for batman then the number of pad to place it on.
Notice certain character ids don't work. E.g. Shaggy clear all characters off base.
Thanks for the hard work.

The samples are more meant to help others create the more useful tools, this is mostly just an API
usual install would be to run npm install node-ld  in a project folder ;)

Can the emulator only cope with one character and one vehicle at a time?
Managed to work out how to swap pads. Think UID will need to be the same for swapped character (lets say between pad 2 to 1).

It can handle upto 7 vehicles/characters at a time
They each have to have a unique UID though
When swapping pads, call tp.remove(token) then tp.place(token,newID,index,uid) to place that same token on a different pad. Note that index MUST be unique among the tokens and from 0-6
Tokens cannot share an index.

Ok thanks. tp.remove accept a string which i believe to be token.uid and character is not removed. Maybe I am giving it the wrong value. When I do another tp.place the existing character is taken off. Not sure if this should happen.

remove accepts either the index or the original token object

Hello ags131,
I would like to offer you a small gift for your hard work.
Your example script for the emulator I have a little expanded.
With this script it is possible to implement a meaningful administration of the characters.
The script can: - manage the tags
- manage the Index (0 - 6)
- manage the toypad places
There are 3 "commands" for the control:

status 	         = Overview of occupied indexes + Name of the tag + position on the toypad
TagID + place = Set a figure to the toypad
TagID 	         = remove a character

Some information:

The script checks if the fields of the Toypad are overloaded (eg Pad 3 already has 3 figures)
The script checks if all 7 indexes are occupied.

toypadEmu.zip

Hi ags131,
Love your toypadEmu files, just got them working today and they're great!
One question though,
You said that the tp.place syntax is like this:
tp.place(token,id,index,uid)
I get what token and uid do, but what about id and index?
Thanks,
2BoysAndHats

Thanks to this project I learned a lot about the communication with the portal and about NFC tags.
I even were able to set up a USB gadget to emulate the portal. (Using the real figures is way more fun!)
Nevertheless, chaos363 was right with placing characters is brittle. Was there any improvement on that?
@chaos363 Would you provide the updated version of your ToyPadEmu with the web interface ?
@ags131 Might it be that the portal won't write any pages equal to or higher than page 28(hex) ?


Update overview.md

Description

Include a summary of the new content you're adding or the reason for the change.
Include relevant context.
Do not link to work items.
Any PNG images should be compressed using Tiny PNG or equivalent.

Type of change
Please delete options that are not relevant.

[ ] New document(s)/updating existing
[ ] Fixes
[ ] Styling
[ ] Bug fix (non-breaking change which fixes an issue)

Reviews and merging
You are responsible for getting your PR merged. Address review comments promptly and make sure to merge the PR when ready.
Feel free to 'Enable automerge' - your PR will automatically merge when accepted and passing the build.

not what you planned, I assume? :D

Thats a shame


zkVM: add the ability to use bonsai to register binaries and run proofs

This allows running bonsai from some zkVM functions in order to run proofs. This is intended for "dogfooding" so that we're running bonsai as much as possible. For now, we'll run proofs and retrieve the proof receipts from bonsai.

@mothran do you have any suggestions on how to do implement tests? With the code how it is now, I need to set BONSAI_DOGFOOD_URL environment variable when doing cargo test which could reveal information that we want to keep private...

@mothran do you have any suggestions on how to do implement tests? With the code how it is now, I need to set BONSAI_DOGFOOD_URL environment variable when doing cargo test which could reveal information that we want to keep private...

I would look into if there are proc_macro's that can disable certain unit tests if a given env var is not present until the API is accessible from the CI machines.

@mothran I implemented a RemoteProver. I saw that we needed access segments[0].preimage.get_root() for the image ID to call verify and it kind of seemed a little clunky in my case. I added an Optional<Digest> in session representing this instead.. Let me know what you think...

@mothran I implemented a RemoteProver. I saw that we needed access segments[0].preimage.get_root() in LocalProver to get the image ID to call verify and it kind of seemed a little clunky in my case. I added an Optional<Digest> in session representing this instead.. Let me know what you think... I remember Frank talking about the pluggable executor thing too. I'll give this a try tomorrow. I think it'll make things cleaner.

Yeah I see, I guess I would have probably opted to access the the pre_image from segment[0] vs add a new attribute. But it makes sense either way to me.

superseded by #677


Error 405 (Not allowed) after clicking send message button on Contact page

Describe the bug
A clear and concise description of what the bug is.
#Error 405 Not allowed is showing after clicking send message button on the Contact page
To Reproduce
Steps to reproduce the behavior:
1.
2.
3.
4.
Expected behavior
A clear and concise description of what you expected to happen.
It is should show "message sent successfuly and our support team will contact you soon"
Logs
If applicable, add logs to help explain your problem (e.g. the error message and/or exception traceback).
Environment (please complete the following information):

OS:
Browser:

Additional context
Add any other context about the problem here.

Hi @Vishal-raj-1, Please assign it to me.

Check it out may be it's done


⚠ ClamAV has degraded performance

In 841531d, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 567 ms

Resolved: ClamAV performance has improved in 14da6a7.


Make more crates and features optional

We're using this library, but noticed that somewhere along the dependency tree, a ton of winit/egui features end up getting enabled. And a few crates that are only used for the examples are specified as dependencies.
This cuts down on a lot of that, and makes it possible to opt out of egui-winit features.
I also migrated to Rust 2021, since that brings the new cargo resolver. And that awesome new cargo resolver lets us cut down on even more features.
cargo fix --edition                                                                                10/12/2023 12:48:35 PMnote: Switching to Edition 2021 will enable the use of the version 2 feature resolver in Cargo.
This may cause some dependencies to be built with fewer features enabled than previously.
More information about the resolver changes may be found at https://doc.rust-lang.org/nightly/edition-guide/rust-2021/default-cargo-resolver.html
When building the following dependencies, the given features will no longer be used:

  ahash v0.8.3 removed features: default, getrandom, runtime-rng
  ash v0.37.3+1.3.251 removed features: linked
  bytemuck v1.14.0 removed features: aarch64_simd, extern_crate_alloc
  cc v1.0.83 (as host dependency) removed features: jobserver, parallel
  libc v0.2.149 removed features: default, extra_traits, std
  syn v2.0.38 (as host dependency) removed features: full, visit
  winapi v0.3.9 removed features: consoleapi, fileapi, minwindef, processenv, std, sysinfoapi, wincon, winnt, winsock2

The following differences only apply when building with dev-dependencies:

  bytemuck v1.14.0 removed features: aarch64_simd

    Checking egui-winit-ash-integration v0.3.0 (C:\Coding\GitHub\Libraries\egui-winit-ash-integration)
   Migrating src\lib.rs from 2018 edition to 2021
   Migrating examples\user_texture\main.rs from 2018 edition to 2021
   Migrating examples\example\main.rs from 2018 edition to 2021
    Finished dev [unoptimized + debuginfo] target(s) in 5.42s

Thank you so much for taking your time to look at this so quickly! Super duper appreciated


Wrong SQL syntax in queries.getUserAtHomeAndNotSeenSince

Hello,
There is an issue when multiple user in house in query getUserAtHomeAndNotSeenSince in api/core/house/house.queries
I think you should add line 56 GROUP BY user.id because with multiple users, the MAX(event.datetime) takes the max of any users, so when one user is at house and the other(s) have left, Gladys consider nobody's left home because the max return the user still in house.

Sorry for the (really late) reply, you're right!
I'll correct that just after summer !


FIELDS_IDS_SIZE Dalvik dex file max reached when having multiple library modules

We receive the following error when executing the Run Configuration for our Android application: Dx trouble writing output: Too many fields: 65757; max is 65536. By package:
2857 com.android.foo.bar
12 com.android.foo.bar.util
236 com.blah.yo.io
6 com.blah.yo.util
2 com.hmm
82 com.hmm.android.app
2761 com.hmm.android.common
2761 com.hmm.android.map
2761 com.hmm.android.map.common
. . .
A list of namespaces follows with similar numbers preceding them
Conversion to Dalvik format failed with error 2
Here's an example of our project structure:
Conceptual structure: A - main/non-library module
B - library module/Android dependency of A
C - library module brought in as an Android dependency of library module B
D - library module/Android dependency of A
E - library module/Android dependency of A
F - library module/Android dependency of E
G - library module/Android dependency of E, B, D(a common IO module used across the different modules)
Folder structure:
/Project A/
   B/*Android module structure*
   C/*Android module structure*
   D/*Android module structure*
   E/*Android module structure*
   F/*Android module structure*
   G/*Android module structure*

At first we thought "wow, we've hit the max fields_ids_size so our app must have gotten that big", which it is a rather large app functionality-wise.
After some attempts at cleanup/discovery on the issue we are doubtful this is the cause. After analyzing the classes.dex file for the fields_ids_size and attempting different things we find that we can shrink the number of fields_ids down if we remove the library modules and just include them into the main project. Horrible for code/module reuse across projects, but takes the number from the above error message from 65757 down to nearly 24,000. Likewise, if jar'ing up a library module and including it into the classpath of the dependent entity(whether its the main non-library module or a library module), the number also shrinks if you remove the Android dependency to that library module and just use the jar file.
Seeing this, I took D from the example above and made it it's own standalone app with no dependencies/tie-ins to other modules and created the classes.dex file for it. Let's assume for this example that D has the namespace com.android.foo.bar. From the example error above this namespace was taking up 2857 fields ids when used as a library module of A. When compiled as it's own app and analyzing the classes.dex file, I saw this number fall to around 120 fields ids.
This is a rather large issue for our app as we're hitting this upper limit. We do have a workaround of sorts, but it is rather clunky and time consuming. I'm hoping there is a solution for this to allow us to have these library references and not have the issue of the number of fields_ids for library modules seemingly being inflated causing this issue.

Sorry but you wrote on the wrong project. This is a precursor gradle plugin for Android, born well before the official Android IDE integrated Gradle. So I think, if you've not already done, I need to repost your issue there.


make sure sortenter event is fired when a dragged element enters container the first time

Motivation: be able to listen to sortenter event - useful when dragging to a different list and wish to update placeholder content.

Coverage remained the same at 8.0% when pulling 88ad41f1d9e73dcf495881924cdd9c30d5b0d305 on christophe-g:dispatch-sortenter into 872e0ce8d226a77dd9166927fab9567b1560ecec on lukasoppermann:master.

Sorry for the number of commits on this one. Had to reconcile history tree between my branch and yours.

@lukasoppermann - hey
If you agree with the proposed changes, I'll re-push with a clean commit history (just re-branch from your master and replay the changes).

Closing as replaced by #492


Company: make autocomplete after typing "func" optional

As it is right now, with a default company-minimum-prefix-length company-go will popup function names after you type func and selecting them replaces the previously written func. This is pretty strange behaviour, and no other autocompletion I've used would open up a list of candidates after typing function or whatever the language's keyword for it is.
Are there any plans of adding something like this? If not that's fine, I'm okay with patching it myself. It seems simple enough from the emacs side, but if this was added to the core gocode is beyond my capability. But there's a few places I could put this, and I'm not sure where is best. Any pointers would be appreciated.

I am learning Go recently and meet the problem. I am still confused about what I should do to fix it, can anybody tell me?


Relative paths for mocks do not work

Describe the bug
Custom mock files are defined the following in the docs:
transforms:
  - mock:
      mocks:
        - apply: User.fullName
          custom: ./user-mocks#fullName

However, we're building with nextjs and it can't resolve the imports. In the generated file we have a importedModules
The ./user-mocks should also be available as key to make this work.
To Reproduce
Steps to reproduce the behavior:
Nextjs build wit the mock transform with a relative file path.
Expected behavior
It would JustWork™

Environment:

OS:
@graphql-mesh/...:
NodeJS:

Additional context

Could you share a reproduction? Thanks!

Closing the issue due to the lack of the response! Feel free once you have a reproduction. Thanks!

@ardatan Sorry for not responding, that wasn't very nice of me. Should have closed the issue as it seems to have been solved for us..


Radarr 4.0.0 release didn't seem to work

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "nginx-stable" chart repository
...Successfully got an update from the "billimek" chart repository
Update Complete. ⎈ Happy Helming!⎈
$ helm search repo billimek | grep radarr
billimek/radarr              	3.2.0        	v<IP_ADDRESS>0-ls58                                  	Radarr is a movie downloading client

Looking at the gh-pages branch, the yaml still says 3.2.0 is the newest.
The helm release action seems to have happened in the actions too.
I already followed to docs to merge the download and movies mounts into one place so now I'm in limbo.  The next course of action is cloning this repo and using the charts directly.  Just wanted to see if there was some re-publishing mechanism or if I missed something.

This is really odd.  Commit https://github.com/billimek/billimek-charts/commit/e28bddada21d9e27d3ec5810d792aa38c2eb7ad2 shows that it was added, but when looking at the file on the branch, it's not there.
I'll dig into this and try to figure out what broke and why.

Ok, the lidarr release seemed to remove it in this commit: https://github.com/billimek/billimek-charts/commit/1ec6cab63854144ca0b178ec77d4c11f5393d9ee
I suspect there is an issue with the action(s) when they are run too close together.

Just created radarr release 4.0.1 via automation to get around the missing version.
I'm still exploring why this happened and how to prevent in the future.

https://github.com/helm/chart-releaser-action/issues/27 created for this, FYI

https://github.com/billimek/billimek-charts/pull/232 may fix this from happening in the future.


[RFC] Bitswap

Link to the RFC
This PR presents an RFC for Bitswap.
It was last edited a long time ago and now presents largely a historical artifact, though most details of the design described in it was implemented.
Another document should be prepared to be a specifications of how Bitswap integration was actually implemented, whereas this document fulfilled its purpose to align vision on earlier stages well.

After putting the RFC together and running through the architecture again, I realized that (as it is written right now) there is a weakness in the proposed design. Currently, for a Bitswap block to be available to serve to peers, the entire Bitswap block tree must be downloaded, sent to the daemon, and then written to the Bitswap block cache. This presents a significant delay in availability of Bitswap blocks to the network, which will have a very heavy and direct impact on our ability to quickly propagate Bitswap blocks throughout the network. Even if we were to stream the individual Bitswap blocks back to the daemon one by one rather than waiting for the entire tree, we still have to wait for the daemon process to finish processing other IPC messages and schedule a job to write the Bitswap blocks to the cache. This is wasteful and goes counter to the model under which Bitswap is meant to work (from what I gather in reading up on documentation and Bitswap use cases).
What we are supposed to be doing is making each Bitswap block we download from any peer immediately available to other peers on the network. In fact, the default Bitswap implementation automatically calls Provide on the DHT whenever it receives a new block from a peer, which other peers will look at to find out that we can serve it.
There are a couple of ways to try an address this. The dumbest way (which I'm not convinced is a good idea) would be to have a temporary in-memory cache for new Bitswap blocks we learn about, which we would expire after a timeout where we double check that this block data is available in the Bitswap block cache. However, this still requires the daemon to transfer all the data from the libp2p helper IPC stream over to the Bitswap block cache, which is an unnecessary step that still puts pressure on our daemon process.
The more ideal thing to do would be to have a 2-writer solution for the Bitswap block cache. In this model, the libp2p helper process would immediately write the new blocks to the Bitswap block cache (which it uses as the BlockStore in out libp2p implementation), skipping the daemon all together. However, this puts new constraints on the technology choice for the Bitswap block cache that are hard to meet (seems like we need to choose one: either persistence, or multiple writers, not both).
Another solution would be to introduce a 3rd process into the mix which acts as a write-proxy for the LMDB instance. Both the libp2p helper and daemon processes would have an open pipe over which they can write messages to this write-proxy process. The write-proxy process would synchronize the writes to LMDB and be the only process that keeps a write connection open to the LMDB instance. This model allows us to continue using LMDB as out Bitswap block cache, but adds additional complexity to the problem in the form of more process management. Since this write-proxy process is stateless and simple, it should suffice to spawn only 1 during the daemon's lifetime, and crash the application should the process die unexpectedly.
Below is a diagram displaying this last idea. Note that the diagram also shows a new optional read connection that the daemon can open to the Bitswap block cache. This is not required, but it seems (on face value) that it may be more efficient to have the helper process write only the block CIDs to the daemon process rather than the full unfolded binary data. By doing so, the libp2p helper process does not need to cache block data as it downloads them, and can just asynchronously send the blocks to the write-proxy to be written. The daemon would then read all the blocks from the Bitswap block cache when the helper process notifies it of a successful download.

256kb for our maximum size

The tree you want to build, is it a balanced tree? What is the degree of each vertex on the tree?
Do you realize that a single 15mb block amounts to 60 pieces of 256kb size?
This is at the very least 60 hashes to be calculated and 60 forth-and-backs to request and retrieve data.
Can not we simply pick up a single peer with reliable connection (which we can collect metrics on) and retrieve the whole 15mb block of data from it? Or at least use 1mb to 10mb as the minimal transmittable chunk of data?

Why would we go with trees at all? Why not just have a sequential list of data hashes?
If we go with 1mb chunks, one such chunk can hold up to 32768 hashes (as a sequential list). That is enough to support blocks up to 32 gb which is in my opinion unreachable in any realistic timeline?
Chunk size 10mb allows blocks up to 3 tb which is certainly more than one could even imagine to have.

Also, even if you want to target nodes on extremely poor connection (Edge mobile internet, basically), why not we allow the p2p protocol to expose an optional parameter to request not the whole chunk but the range of bytes of it? This way, if the node stalls and disconnects, we do not have to start "from scratch".
And IMHO it makes little sense to derive a network where nodes would want to advertise that they have some chunks of a 15mb block, not the whole block. Let's assume that if the nodes downloaded only part of the block, it doesn't upstream it. This may theoretically limit the potential for data sharing in the Bittorrent-like way. But practically, in a well-enough chosen network topology, difference between states "I have some chunks of block" and "I have the whole block" is on average less than 10s (for bocks of size up to 50mb). So why bother with chunking at all?
I advocate for 1 block -- one CID policy. At least for blocks up to 50mb size. Where first byte of CID is a version byte, for 0 being the raw data, 1 being the sequential list of CIDs for further retrieval. This will allow getting hashes of all chunks in one hop for any foreseeable future and some backward-compatible strategy for the non-foreseeable future too,

Shipping as a Soft-Fork

Should we also talk about the change below in the soft-fork section?

In order to prevent this, we must now include a commitment in the snark not only to the target staged ledger hash, but also the root Bitswap block CID of the staged_ledger_diff that brings us to that state.

one alternative to using LMDB as the Bitswap cache would be to use SQLite

Is it this the only alternative?
If we stick to > 10mb chunks, I believe file system will also do a good job.
It's also suitable for "one writer -- many readers" narrative and allows as much memory-mapped I/O as is possible.

Shipping as a Soft-Fork

Should we also talk about the change below in the soft-fork section?

In order to prevent this, we must now include a commitment in the snark not only to the target staged ledger hash, but also the root Bitswap block CID of the staged_ledger_diff that brings us to that state.

Good catch. We won't be able to do this if we want to ship this work as a soft-fork. I wonder if there's something else we could do here in the meantime. I don't know how comfortable I would be shipping this work without some way of preventing an adversary for spamming the network with invalid staged ledger diffs. Perhaps @mrmr1993 or @imeckler might have an idea.

Do you realize that a single 15mb block amounts to 60 pieces of 256kb size?
This is at the very least 60 hashes to be calculated (depending on the tree structure) and 60+ forth-and-backs to request and retrieve data.

It's not 60+ back and forth messages. The node would include the root block CID in existing want-list messages it sends out for other data. When it receives a have-list message from a peer that contains that root block CID, then the node would want-block message to that peer that contains that root block CID (along with any other blocks it wants from that peer). The peer would serve the block back to the requester. Once it has the root block, it would deserialize it and discover the other 59 block CIDs related to the data, and start the process over again, except now there are 59 block CIDs it's attaching to the want-list messages. Each of these blocks do not incur a unique back-and-forth protocol; they are bundled together in chunks for all the want-list, have-list, want-block, and block messages, and each of those are multiplexed over streams with the peers the node is connected to.

Why would we go with trees at all? Why not just have a sequential list of data hashes?
You want to have a single root block CID so that you have a succinct hash to advertise. As the size of data increases, the number of blocks required to store it increases as well. So if we have a sequential list of data hashes that we need to broadcast with all the block headers, the block headers would get larger and larger over time. Forming Bitswap blocks into trees or DAGs is the way Bitswap was intended to be used, according to the documentation and existing use cases.

Can not we simply pick up a single peer with reliable connection (which we can collect metrics on) and retrieve the whole 15mb block of data from it? Or at least use 1mb to 10mb as the minimal transmittable chunk of data?

As mentioned in the RFC, we can tune the size of Bitswap blocks (and I think we should play with it in testing to see what the performance characteristics of changing it are). But keep in mind: we do not download 1 chunk at a time from peers all the time. We use multiplexed streams to request multiple blocks at a time from individual peers. Each Bitswap block download does not involve a unique connection and roundtrip cycle; messages are batched and connections are reused.

If we go with 1mb chunks, one such chunk can hold up to 32768 hashes (as a sequential list). That is enough to support blocks up to 32 gb which is in my opinion unreachable in any realistic timeline?
Chunk size 10mb allows blocks up to 3 tb which is certainly more than one could even imagine to have.

256kb can hold up to 8192 hashes which. At depths of only 2 on the trees, this can support a total of ~2.09gb. If we ever need to exceed that, we can just extend the trees to be deeper (packing the trees in an unbalanced fashion would have the highest efficiency for discovering the full set of CIDs required, I believe).

The tree you want to build, is it a balanced tree? What is the degree of each vertex on the tree?

These are unbalanced rose-trees. Perhaps I should just replace the term "tree" with "DAG" to reduce potential confusion.

Also, even if you want to target nodes on extremely poor connection (Edge mobile internet, basically), why not we allow the p2p protocol to expose an optional parameter to request not the whole chunk but the range of bytes of it? This way, if the node stalls and disconnects, we do not have to start "from scratch". If Bitswap "takes care" of downloading and is not flexible enough to support partial downloads, maybe it's not so good a solution after all?

Sorry, I don't quite follow this part. If I understand what you are saying, this is precisely what Bitswap does. It breaks data up into ranges of bytes so that you have the flexibility to support partial and distributed downloads.

And IMHO it makes little sense to derive a network where nodes would want to advertise that they have some chunks of a 15mb block, not the whole block. Let's assume that if the nodes downloaded only part of the block, it doesn't upstream it.

Why assume this? Bitswap is intended so that you upstream the Bitswap blocks as you download them.

But practically, in a well-enough chosen network topology, difference between states "I have some chunks of block" and "I have the whole block" is on average less than 10s (for bocks of size up to 50mb). So why bother with chunking at all?

Can you quantify this? Even if this is true, the inability to upstream partial block data hurts your ability to propagate information throughout the network without putting large amount of stress on the originating node. If it takes 10s for any other node on the network to be able to serve any of the block body data, then for that whole 10s, every node that receives a block header will attempt to connect to the originating node and download the entire block body. Not only can the originating node not handle those connections, but that's a huge bandwidth load you put on that node.

I advocate for 1 block -- one CID policy. At least for blocks up to 50mb size. Where first byte of CID is a version byte, for 0 being the raw data, 1 being the sequential list of CIDs for further retrieval. This will allow getting hashes of all chunks in one hop for any foreseeable future and some backward-compatible strategy for the non-foreseeable future too.

Can you spec out what you mean a little more specifically? I don't follow what you mean by the storing data in the CID (it wouldn't be a CID anymore https://docs.ipfs.io/concepts/content-addressing/#identifier-formats). Are you saying that block IDs should be non-succinct and carry data?

one alternative to using LMDB as the Bitswap cache would be to use SQLite

Is it this the only alternative?
If we stick to > 10mb chunks, I believe file system will also do a good job.
It's also suitable for "one writer -- many readers" narrative and allows as much memory-mapped I/O as is possible.

If I understand correctly, it sounds like you are implying we should rebuild something like LMDB from scratch? This sounds like a lot of work and risk, I'm not sure why we wouldn't use an off-the-shelf solution for managing memory-mapped file based key value stores. As called out in the schema, this is not just storing the raw block info, but also indices that are used to resynchronize and recovery the persisted Bitswap block cache.

In order to prevent this, we must now include a commitment in the snark not only to the target staged ledger hash, but also the root Bitswap block CID of the staged_ledger_diff that brings us to that state.

I didn't think deep into that to discuss on the topic properly, but is there a way to avoid changing the block/header structure without altering the design as whole?

So if we have a sequential list of data hashes that we need to broadcast with all the block headers, the block headers would get larger and larger over time.

I don't follow your line here. I was talking about a sequential list of chunks, where each chunk is a piece of a block body. I proposed to use one CID per Mina block. I do not understand what you mean "sequential list of data hashes and block headers" as if it was about more than a single block.

But keep in mind: we do not download 1 chunk at a time from peers all the time.

I would say that normally we want to download one chunk from just one peer which we choose based on stats we gathered on the connection with it.

256kb can hold up to 8192 hashes which. At depths of only 2 on the trees, this can support a total of ~2.09gb.

Yeah, and as I proposed above, with 1mb we can afford 32 gb. And the sequential list structure is much easier to build and maintain than a tree.

Perhaps I should just replace the term "tree" with "DAG" to reduce potential confusion.

If it's a tree, let's call it a tree. If it's a few trees, let's call it a forest. I doubt you would want to store anything in a DAG that is not a tree, at least this makes little sense to me.

Sorry, I don't quite follow this part. If I understand what you are saying, this is precisely what Bitswap does. It breaks data up into ranges of bytes so that you have the flexibility to support partial and distributed downloads.

Not exactly. We must distinguish between addressing and partial retrieval. When you say a block is 256kb, that means that you have a unique address per each 256kb of block data. Which increases the use of bandwidth and hashing CPU, though I can not say if the increase is marginally significant. On the other hand, it's inconvenient to make a unique address contain data from more than a single block. But IMHO, there is no problem to have address per Mina block for Mina blocks less than 50mb. And simplifies many things a lot.
An advantage of 256kb per address approach is that then there is no need for a partial download protocol. We either download the data associated with address in full or we can just drop the peer. With 50mb probability of network failure even when communicating with good citizen peer is much higher, hence we do need a partial download protocol to be able to reconnect to this or other peer and request only byte range that wasn't received yet.
And yeah, there is a disadvantage of 1 CID per 1 Mina block policy in that some data pieces may not be readily available immediately as they come to the node. I.e. if the node has already range 0-1MB, it will not upload it to the other nodes that do not have this range of data (yet), but will wait to retrieve all of 50MB of the data.
So, to summarize:

Concern
256kb per address
1 CID per 1 Mina block

Doesn't require partial download protocol
✅
❌

Less data necessary to exchange a single CID
❌
✅

Unique address per application-level data
❌
✅

Smaller data pieces readily available
✅
❌

Better performance
⁇
⁇

In my opinion, introducing a partial download protocol is a more flexible and generic way than hard-coding the chunk size statically,

Why assume this? Bitswap is intended so that you upstream the Bitswap blocks as you download them.

Just try downloading some data from a server in Australia. For me on a 4G connection it's still ~7s to establish and warm-up the TCP stream and ~7s second to download 50mb at a max speed (which is 40 Mbps for me). If you try it with https://www.speedtest.net/, it's very informative how the speed changes over the first few seconds of downloading.
Okay, it totals to 15s rathen than 10s for a 50mb. But AFAIU Mina blocks today are less than 50mb.

Not only can the originating node not handle those connections, but that's a huge bandwidth load you put on that node.

That's why we need to work accurately on controlling the amount of traffic the originator node tries to handle. Control it on the node itself. Basically, if it feels like it's not progressing well, it should drop connections or not accept them at all why the old ones do not free up.
Transmitting smaller data pieces is a heuristic approach to load reduction problem. And frankly speaking, I'm very uncertain about that it actually works that well.
My take on this is that we should try to solve the load balancing of the node by protocol-grade heuristics, but actually control the load on the node.

Can you spec out what you mean a little more specifically? I don't follow what you mean by the storing data in the CID (it wouldn't be a CID anymore https://docs.ipfs.io/concepts/content-addressing/#identifier-formats). Are you saying that block IDs should be non-succinct and carry data?

From https://github.com/multiformats/cid#human-readable-cids there is an example (I use human-readable a.k.a. debug form of the CID notation):
base58btc - cidv1 - raw - sha2-256-256-6e6ff7950a36187a801613426e858dce686cd7d7e3c0fc42ee0330072d245c95

Basically, I want to use the same, except for instead of sha2-256-256-6e6ff7950a36187a801613426e858dce686cd7d7e3c0fc42ee0330072d245c95 we'll have block hash like blake2b-256-.... And AFAIU this will be an address of the bitswap block corresponding 1:1 to a Mina block.

one alternative to using LMDB as the Bitswap cache would be to use SQLite

Is it this the only alternative?
If we stick to > 10mb chunks, I believe file system will also do a good job.
It's also suitable for "one writer -- many readers" narrative and allows as much memory-mapped I/O as is possible.

If I understand correctly, it sounds like you are implying we should rebuild something like LMDB from scratch? This sounds like a lot of work and risk, I'm not sure why we wouldn't use an off-the-shelf solution for managing memory-mapped file based key value stores. As called out in the schema, this is not just storing the raw block info, but also indices that are used to resynchronize and recovery the persisted Bitswap block cache.

Can you specify what indices do you need?
If you just need a single key-value table for storing CID - data relation, you can simply make a directory structure like follows:
./<a>/<b>/<c>/<full cid>.dat

where <a>, <b>, <c> are prefixes of 1-2 bytes of the hash being kept in CID. Directory structuring is only for better support of non-Linux setups, we can even drop these <a>, <b> and <c> altogether.
Like 0e2b/13cc/78aa/0e2b13cc78aa(..).dat.
This is a common approach used in many applications AFAIU.
I do not say that we should necessary use this approach, I just say this is an alternative approach and for the task you specified I think it will perform not any bit worse than LMDB and might be more flexible actually. And I wonder are there more requirements which would be hard to support with this simplest-possible data storage scheme. Because advantage is evident to me: filesystems are universally supported (require no additional driver for the database), widely used (more likely you will hit a bug in LMDB which is niche), support mmap naturally on OS level and, finally, solve the task.

use an off-the-shelf solution for managing memory-mapped file based key value stores

Because, again, ext4+Linux kernel is exactly a solution for managing memory-mapped file based KV store

That's why we need to work accurately on controlling the amount of traffic the originator node tries to handle. Control it on the node itself. Basically, if it feels like it's not progressing well, it should drop connections or not accept them at all why the old ones do not free up.
Transmitting smaller data pieces is a heuristic approach to load reduction problem. And frankly speaking, I'm very uncertain about that it actually works that well.
My take on this is that we shouldn't try to solve the load balancing of the node by protocol-grade heuristics, but actually control the load on the node.

@georgeee my understanding is bitswap already made these decisions and it's not something we'd be able to change without reimplementing portions of bitswap. Given that this proejct is already very large in scope, I think we should stick with what they've done (and likely they thought carefully about using the chunks with the 256kb suggestion, many other blockchain projects are using this, etc)

Critical update to the RFC:
I was talking with @imeckler yesterday, who was curious about how blocks were so large. After he investigated some more, @imeckler determined that the number we pulled from the archive node was incorrect. He setup a some additionally logging on his local node, and measured the binary size of a fairly full block to be (transactions=27, works=125, bytes=1793203). This block doesn't have the full number of transactions or work bundles (128 max for both), but this does indicate that blocks should be well under the 15mb size that was originally quoted in the RFC. This brings the current max block size on the network to ~2mb.

@georgeee I’m going to do my best to address all of your points. Github’s lack of sub-threads in conversations makes it a little hard to track all of the conversation, so please let me know if I miss any of your points. Also, happy to hop on a call to discuss any of these details in person to help clear up the details, just trying to keep the conversation here for now os that there’s a public thread of discussion around these decisions.
First off, I wanted to provide some framing for the Bitswap consideration so far, to be explicit about the tradeoffs we are discussing here. Some of these points can be achieved through alternatives to Bitswap, but just wanted to get these written down for clarity of the decision we are making.
Pros:

Decrease gossip pub/sub message size by exfiltrating data from the gossiped messages.
Increased gossip pub/sub consistency (due to smaller message size, we can more quickly propagate the initial message throughout the network)

This is important because we have a hard time cutoff for block broadcasts, and already observe gossip inconsistencies

Reduce total bandwidth requirements to operate as a node on the network (comes naturally as part of decreasing gossip pub/sub message size, since pub/sub broadcasts duplicate messages multiplicatively based on connected peers that share topics)
Spread outgoing bandwidth used for synchronizing resources across more nodes on the network
Increased resiliency to networking errors and adversaries due to Merkle DAG addressing model, allowing nodes to quickly determine when data is corrupted or incomplete and recover quickly
Decreased delay in data availability from nodes on the network due to the fact that nodes can serve partial chunks of resources while they are still downloading the full resource

Cons:

Possibly increased overall latency for downloading resources in this fashion as opposed to idealized network scenarios

P2p networks not exactly ideal, however

Increased complexity for implementation in the code

Luckily, much of this complexity is handled inside of the Bitswap implementation, but there is still some that gets pushed onto us

These are from my own opinion, but hopefully these points are clear and make sense, and we can use these to guide our discussion regarding which pros/cons are valid, and how we should weigh them in our decision.
With this out of the way, I’ll attempt to tackle each of your points by grouping them under different topics of discussion.
General Bitswap Concerns

We must distinguish between addressing and partial retrieval. When you say a block is 256kb, that means that you have a unique address per each 256kb of block data. Which increases the use of bandwidth and hashing CPU, though I can not say if the increase is marginally significant.

How does it increase hashing CPU? Hashing complexity is linear, so hashing 1gb of data all at once, vs. hashing 1gb of in chunks of 256kb, takes the same amount of time. I’m not convinced that there is a significant increase of bandwidth by adding more unique addresses. If we want to download 1gb of data over Bitswap with a block size of 256kb, there would be 3907 unique addresses involved. Given that each CID will be only a few bytes of data (say, 49 bytes each, if we take an example CID provided by IPFS docs), that’s 186.95kb of addresses necessary to determine which peers have the data we need over the network, a mere 0.01% of the 1gb we are trying to download. Even given that we broadcast this to multiple peers in our want-list, it’s small fractional increase in bandwidth for all the advantages Bitswap brings us.

But IMHO, there is no problem to have address per Mina block for Mina blocks less than 50mb. And simplifies many things a lot.

I disagree that it simplifies things. If you have a single address for a full 50mb chunk of data, and you download sub-ranges of that data from multiple peers in parallel, then you have no way of knowing if each chunk you download is valid until you have download every single chunk. Imagine you break up the 50mb of data into 1000 sub-ranges, but only have 1 address for the entire 50mb of data. Perhaps 999 sub-ranges you download from honest peers are valid and correct, but 1 sub-range you download is from an adversary and is not correct. You would need to wait until you have all 1000 chunks, recompute the address of the 50mb of data, and find out the data is not correct. You would have no way of knowing which chunk out of the 1000 was invalid. In Bitswap, this is not an issue, as you take a Merkle DAG and download chunks of data from the top down, immediately verifying each chunk of data you download is a valid segment of the larger structure you are trying to receive.
Block aggregative structures and CIDs

Why would we go with trees at all? Why not just have a sequential list of data hashes?

… So if we have a sequential list of data hashes that we need to broadcast with all the block headers, the block headers would get larger and larger over time. …

I don't follow your line here. I was talking about a sequential list of chunks, where each chunk is a piece of a block body. I proposed to use one CID per Mina block. I do not understand what you mean "sequential list of data hashes and block headers" as if it was about more than a single block.

I think there might be a miscommunication here. If I understand correctly, we are discussing 2 different things here at once:

The idea that, should we need multiple Bitswap blocks to store data, that we should use sequential lists of data hashes instead of trees.
The idea that we could have a single Bitswap block per each Mina block body.

Let me address each of these points separately in their own sections.
Structure and References of Aggregative Bitswap Blocks

Why would we go with trees at all? Why not just have a sequential list of data hashes?

To have a sequential list of data hashes pointing to the Bitswap blocks that comprise a resources, you either have to transmit that sequential list of data hashes with the gossip message so that the node knows the set of blocks upfront, or you have to store the sequential list of data hashes in the root Bitswap block for the resource and only gossip around the root block CID. The latter of these 2 approaches forms a tree of depth = 2 (specifically, a rose tree).
The idea of structuring Bitswap blocks as trees/DAGs (which is what Bitswap dictates you should do) is that we don’t have to choose the block size based on maximum size of any data we want to sync over Bitswap. Additionally, the root block (or any blocks with children) can carry binary data when it is not completely full of hashes, which reduces the total number of blocks necessary.
I can illustrate this more concretely if it would be valuable. The RFC does contain a description of how binary data gets projected into blocks, and how the blocks would be represented as binary data, but perhaps a diagram would be useful to help show how this plays out in practice.

Perhaps I should just replace the term "tree" with "DAG" to reduce potential confusion.

If it's a tree, let's call it a tree. If it's a few trees, let's call it a forest. I doubt you would want to store anything in a DAG that is not a tree, at least this makes little sense to me.

A rose tree is just a subset of a DAG where all nodes in the graph have only 1 incoming arc. I ended up using the term “tree” here instead of “DAG” (despite the fact that the Bitswap docs refer to block structures as a “DAG”) because, in the context of storing Mina blocks, it will always be a tree. However, when we do plan to sync ledgers in the future over Bitswap in the future, and when we do that, it is possible that ledgers with different merkle roots can share graph nodes when the section of the ledger associated with those nodes have not been modified across the ledgers in question.

256kb can hold up to 8192 hashes which. At depths of only 2 on the trees, this can support a total of ~2.09gb.

Yeah, and as I proposed above, with 1mb we can afford 32 gb. And the sequential list structure is much easier to build and maintain than a tree.

I don’t think we should be choosing the block size based on how many hashes it can hold. That decision should be driven by networking performance and download time, which in theory, is effected by the Bitswap block size. The point I was trying to illustrate here is that even with 256kb blocks, we can store a large amount of information with only 2 layers of a tree.
Consolidation of Bitswap Blocks (each Bitswap block fully encapsulating a single Mina resource)
There’s 2 issues with treating Bitswap blocks as 1-1 with data we want to download from peers.
Firstly, doing so means that we will need to adjust our Bitswap block size as our max resource size for resources we sync over Bitswap increases. That means, as we scale TPS and blocks get bigger, we need to adjust the Bitswap block size. Even more critically, we plan to synchronize ledgers over Bitswap in the future, and ledgers are (obviously) very large to download from a single peer.
Secondly, storing each resource in a single large Bitswap block defeats much of the purpose of Bitswap. It doesn’t let us download partial data from multiple peers, which in turn means we will have decreased resiliency to networking errors. Additionally, we will rely more on originating nodes to serve us data, since this will increase the delay before which any other node on the network has at least partial data they can stream to other nodes. I understand you are still not convinced around these advantages, but we should first settle on the an agreement regarding this before we consider taking an option that removes these advantages of Bitswap.
Multiple Block Downloads per Peer

But keep in mind: we do not download 1 chunk at a time from peers all the time.

I would say that normally we want to download one chunk from just one peer which we choose based on stats we gathered on the connection with it.

I’m not sure I follow why this is what you would want to do. Once we have a connection established to a peer and are already paying off the cost of TCP slow start, wouldn’t you want to download more data over that connection rather than download lot’s of small pieces of data from different connections? This seems to fall in line with the points you had been making earlier about bandwidth performance.
Avoiding updating the block header structure

In order to prevent this, we must now include a commitment in the snark not only to the target staged ledger hash, but also the root Bitswap block CID of the staged_ledger_diff that brings us to that state.

I didn't think deep into that to discuss on the topic properly, but is there a way to avoid changing the block/header structure without altering the design as whole?

We currently don’t have a block header in the system, so we are defining that as a new structure. For the most part, that newly defined block header is just all the fields in the currently defined block structure minus the staged_ledger_diff, however, we now need some sort of reference in the block header to the staged_ledger_diff a node needs to download in order to construct the full block structure. If we are moving to Bitswap, this reference would be the root block CID of the staged_ledger_diff, but even if we don’t move to Bitswap and are still separating the block header and block body as concepts, this reference would be some identifier (likely hash) of the staged_ledger_diff associated with the block.
LMDB vs. Raw File System
I can go ahead and include the raw file system approach as an alternative in the RFC, but I think it’s an expensive alternative. Your suggestion seems to rely on 2 assumptions, namely that we will have large enough blocks to warrant this approach (> 10mb), and that we only have 1 key-value table that maps CIDs to these large blocks.
I will avoid commenting on the requirement to have large blocks, as I believe that conversation already covered in my response and we should continue that discussion separately to this detail. However, in the world that Mina resources are projected into many small Bitswap blocks, using a naive file system based approach would use a very high number of inodes and file descriptors, which does not seem ideal. If we want to compress multiple key-value entries into less inodes on the file system, then we would need to solve new problems related to concurrent reads/writes that a solution like LMDB already does for us. This could be complex and brittle, which is why I would lean towards an out-of-the-box solution.
Regarding the schema layout of the Bitswap block cache, the RFC dictates that we need 2 key-value tables: one that maps Mina’s existing content addresses to the full set of Bitswap block addresses associated with the projection of that resource. This is required for the synchronization model defined in the RFC.

Once we have a connection established to a peer and are already paying off the cost of TCP slow start, wouldn’t you want to download more data over that connection rather than download lot’s of small pieces of data from different connections?

Problem with TCP is that slow start happens every time you start to increase speed of data flow. Not just on connection. With low traffic you're basically paying this cost on every message. Smaller the message size, higher the probability we experience this issue. Though with multiple data requests multiplexed (which as I understand now is also something Bitswap is doing), we're fine.
Nevertheless, after doing some calculations I found comfort in consideration that amount if hops needed to deliver the block to the far-most node will be logarithmic to the number of nodes and hence with > 120s allowed latency a number of hops as small as 10 would suffice even for tens of thousands of nodes in a loosely connected network. And if it becomes a million of nodes, we'll have something around 20 hops. So if we manage to transmit 2mb block between two nodes within 6s on average, we can sleep safely for a very long time without caring about. Even if we manage to do that within 12s, we're fine.
And all of that renders network topology optimizations and optimizing the TCP throughput with no slow start a waste of time, overall.

!ci-build-me

!ci-build-me


embedded dylibs/frameworks are only supported on iOS 8.0 and later (@rpath/AFNetworking.framework/AFNetworking) for architecture x86_64

Hi~  Mr.kCharWood.
I got an error below it is a detail issue when I upgraded this framework to 3.0 version.
Because of supporting iOS7.0 . This project that my company's demand so I really help you can help me.
If I wanna support iOS7.0 when I'm using the latest version of AFN v3.0 . How can I do?
I'm really appreciate you can help me with.
embedded dylibs/frameworks are only supported on iOS 8.0 and later (@rpath/AFNetworking.framework/AFNetworking) for architecture x86_64

I have solved this issue . The reason is My project's Podfile below
platform :ios, '7.0'
use_frameworks!
target 'AFNetwork_DEMO' do
pod 'AFNetworking', '~> 3.0'
end
If developers add this use_frameworks!   , and then Xcode compile the minimum target is iOS 8.
If developers remove this use_frameworks!, everything will be okay.
Thanks for AFN team!

'use_frameworks!' is mandatory in some situations (hello, 'libextobjc' + modules enabled). So, it's better to have fixed minimum target for framework-based setup.


Check for multisample support

It is very common to have samples=4 supported. It even works with software renderers.
However, the supported number of samples should be collected and checked against the image parameters.

resolved with the soft limit for max samples.
the soft limit ensures the maximum supported samples are used when the user-provided value is above the limit.


Problem of Subtask 2 training set in AbdomenCT-1K Fully Supervised Learning Benchmark

In the Subtask 2 of AbdomenCT-1K Fully Supervised Learning Benchmark, it said that the training set is adapted from MSD Pancreas (281 cases) , LiTS (40 cases) , and KiTS (40 cases), where the cases are from different phases. However, after checking the data set, I found that the training set consists of MSD Pancreas (281 cases) , MSD Spleen (9 cases), LiTS (27 cases) , and KiTS (44 cases).

Hi @liqiang3235 ，
Thank you so much for pointing out this critical issue. We are so sorry for uploading the wrong folder. The data has been updated in the baidu net disk just now. And we will also check all the other uploaded datasets.
Best,
Jun

@liqiang3235
Any further questions?


gfx942 80cu XFP32 GridBased tuning (NN,NT,TN,TT)

The definition of UseScaleAlphaVec has been changed as below, please kindly modified your YAML file accordingly.
UseScaleAlphaVec=False -> UseScaleAlphaVec=0
UseScaleAlphaVec=True -> UseScaleAlphaVec=1
Redefined UseScaleAlphaVec
0 - Alpha Vector Scaling is disabled
1 - Calculated Alpha Vector Scaling along M-dim
2 - Calculated Alpha Vector Scaling along N-dim
3 - Calculated Alpha Vector Scaling along either M-dim or N-dim.

The definition of UseScaleAlphaVec has been changed as below, please kindly modified your YAML file accordingly.
UseScaleAlphaVec=False -> UseScaleAlphaVec=0
UseScaleAlphaVec=True -> UseScaleAlphaVec=1
Redefined UseScaleAlphaVec 0 - Alpha Vector Scaling is disabled 1 - Calculated Alpha Vector Scaling along M-dim 2 - Calculated Alpha Vector Scaling along N-dim 3 - Calculated Alpha Vector Scaling along either M-dim or N-dim.

Thanks for letting me know.
Updated.

Merged latest develop and converted UseScaleAB to "".

@vin-huang can you please review this PR? Thanks.

Some error in ubuntu22 & gfx942 at docker stage.
I do not think my change causes any issue at docker stage.
Most likely unrelated to my change.

One gfx942 precheckin test failed.
pre_checkin_matmul_real_1b_dst_f8_amaxD_bf8_rf8_rf8_rf8_rf32_r_relu_TT_127_129_127_1_127_129_0_127_127_1_SA_SB_SD_AMaxD
This is f8 case. It is unlikely related to this change.

Try rebasing locally and run hipblaslt-test to see if it still fails

Try rebasing locally and run hipblaslt-test with filter to see if it still fails

I tried it locally and it passed.
[  PASSED  ] 35002 tests.
hipBLASLt version: 800
command line: ./build/release/clients/staging/hipblaslt-test --gtest_output=xml --gtest_color=yes --gtest_filter=*

Hi @KKyang
CI test finally passed after merging the latest develop commits.
Do you have any more comments?

No, thanks.


Update model-cards.md

More reword ("your" --> "the model's")
Clarifying metadata vs longform
Adding link to Annotated model card

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


Bug? Clicking Save adds duplicate relation(s).

Hi Erik,
Using the 1.0.5 tag.
We have two Documents (A and B) related by a single row in the Relations table. The relationship is Bidirectional. If we open the Editor action panel (on either A or B) the one relationship appears correctly. If we click SAVE without doing anything else a new duplicate relation is added to the table. Repeating the process continues to add more duplicates.
Here is our basic editor configuration:
[ObjectType Name="Document" Alias="A"]
[EnabledRelation Alias="AToB"]
[EnabledChildType Alias="B"/]
[/EnabledRelation]
[/ObjectType]
[ObjectType Name="Document" Alias="B"]
[EnabledRelation Alias="AToB"]
[EnabledChildType Alias="A"/]
[/EnabledRelation]
[/ObjectType]
Also wondering if there is a way to prevent multiple row entries for bidirectional relationships (where the the parent/child ids are reversed). Not sure if that is a default Umbraco behavior, though.
Thank you for your help!

Fixed in upcoming release.


[Golang] Failed lint check in server/models/package_manager.go

Current Behavior
The return value of ap.UpdatePackageData needs checked. See screenshot.
Screenshots/Logs

Contributor Guides and Handbook

🛠 Meshery Build & Release Strategy
📚 Instructions for contributing to documentation

Meshery documentation site and source

🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@leecalcote I would love to work on this

Hey @leecalcote
I would love to try solving this issue. Can you give me a brief about how this issue can be solved?

Thank you gents for showing interest on this issue, assigning based on FCFS .
@khanjasir90 :+1:

Hey @khanjasir90 !!!
Would you like to work on this issue together? As this is a good first issue, I think it would bring me some good learnings and I really want to give it a try. What say?

Yep sure!

you got discord or slack? @khanjasir90

// @leecalcote This issue has been fixed via this commit https://github.com/meshery/meshery/commit/04e6dab2cd67a5bbf174ffeb971d771a7b8aaedb and it's already on master, we can close this issue.

Thank you, @acald-creator 👍


feat: Upgrade Quarkus version to 3.2.6.Final

@wjglerum Would you like to review this PR? This is the last change before you could start with the Wiremock 3 integration.

@all-contributors add @chberger for doc

@all-contributors add @wjglerum for review


Could not find page for PDFRef Error during flatten

What were you trying to do?
flatten document.
How did you attempt to do it?
example to reproduce below
What actually happened?
crash on flatten call
Error: Could not find page for PDFRef 220 0 R
    at PDFForm.findWidgetPage (/home/roman/Projects/monorepo/packages/lambdas/pdfService/node_modules/pdf-lib/cjs/api/form/PDFForm.js:603:23)
    at PDFForm.flatten (/home/roman/Projects/monorepo/packages/lambdas/pdfService/node_modules/pdf-lib/cjs/api/form/PDFForm.js:458:33)

What did you expect to happen?
not having a crash
How can we reproduce the issue?
const { PDFCheckBox, PDFDocument, PDFTextField } = require('pdf-lib');
const fs = require('fs');

const fill = async () => {
  try {
    const Body = fs.readFileSync(
      'internshipApplicationForFurtherEducation.pdf',
    );

    const pdfDoc = await PDFDocument.load(Body);
    const form = pdfDoc.getForm();
    form.flatten();

    const result = await pdfDoc.save({ useObjectStreams: true });
    fs.writeFileSync('result.pdf', result);
  } catch (e) {
    console.error(e);
    throw e;
  }
};
fill();

file
Version
1.17.1
What environment are you running pdf-lib in?
Node
Checklist

[X] My report includes a Short, Self Contained, Correct (Compilable) Example.
[X] I have attached all PDFs, images, and other files needed to run my SSCCE.

Additional Notes
In our project I have around 30 different pdfs and only 2 has such issue. Not sure if it's corrupted metadata or something else. Before it was working with pdftk.

I've made minor patch to ignore this error inside flatten and findWidgetPage functions and result doc look fine. So my assumption is that some editor left broken meta-data, thus pdflib "see" widget, but cannot find it on page. Ideally we should check it during load and clean such broken widgets/refs.
I'll publish the workaround tomorrow.

here is my workaround
you can test it via @visaright/pdf-lib npm package. (you can use package with caution, cause it will be removed after the issue is properly fixed in the mainstream)


Get tilePixelRatio from MVT tiles

When working with MVT tiles, we can determine the tilePixelRatio from metadata in the tile. This pull request changes things so users no longer need to configure the source with a tilePixelRatio when ol.format.MVT is used to parse tiles.

Tests added.


How to set a sticky background image inside renderHeader?

I am trying to set a sticky background image inside render header, I used headerFixedTransformY but when I scroll the image will not stay fix. I need only the bg to stay fix all the time so when the user scroll the upper part of image will stay visible. Right now when I scroll the only the lower part of image will end up being visible. Any idea if it is possible to do this?

Hi @juand89, I think I don't understand right, do you have any examples?

Like this I want only the background Image to stay fix all the time and not to move even if I scroll. I try to change the style of the image to position absolute onHeaderFixed function but is not as smooth as I want to be. Like this:

Try to add parallaxBackgroundScrollSpeed={0.0001}, I think it can help...

thanks for the answer but the problem is that I'm using only the renderheader and onheaderFixed={true}. I wonder if there is not an option like headerFixedTransformY for the parallaxBackground

You can try to use renderParallaxBackground to render background with the parallaxBackgroundScrollSpeed={0.0001} prop to disable background scrolling

You can close this issue, I could do it using setnativeprops.


How to echo video stream?

This is the case, I want to transfer the video stream obtained by getUserMedia to the media server, then the media server will return the video stream to the local, and finally display the stream on the local video tag.
In fact, I have received the stream returned by the media server on the onaddstream event of the RTCPeerConnection , but after I set the stream to videoEl.srcObject , the stream does not play properly. This is really frustrating...
Here are some code snippets:
Client：
const local = new RTCPeerConnection({
    bundlePolicy: "max-bundle",
    rtcpMuxPolicy: "require"
});

if(localStream){
    local.addStream(localStream);
}

local.onnegotiationneeded = () => {
    local.createOffer({offerToReceiveVideo: true}).then((offer) => {
        local.setLocalDescription(offer, () => {
            websocket.send(JSON.stringify({
                type: "OFFER",
                offer
            }));
        }, () => {});
    });
};

local.onaddstream = ({stream}) => {
    videoEl.srcObject = stream;
};

websocket.on("answer", (answer) => {
    local.setRemoteDescription(new RTCSessionDescription(answer), () => {}, () => {})
});

Server:
const endpoint = MediaServer.createEndpoint(SERVER_SETTINGS.IP);

const { SDPInfo, MediaInfo, CandidateInfo, DTLSInfo, ICEInfo, StreamInfo, TrackInfo, Direction, CodecInfo } = SemanticSDP;

function server(sdp) {
    let offer = SDPInfo.process(sdp);

    const transport = endpoint.createTransport({
        dtls: offer.getDTLS(),
        ice: offer.getICE()
    });

    transport.setRemoteProperties({
        audio: offer.getMedia("audio"),
        video: offer.getMedia("video")
    });

    const dtls = transport.getLocalDTLSInfo();
    const ice = transport.getLocalICEInfo();

    const answer = offer.answer({
        capabilities: {
            video: {
                codecs: ["vp9", "h264;packetization-mode=1"],
                rtx: true,
                rtcpfbs: [
                    { "id": "transport-cc" },
                    { "id": "ccm", "params": ["fir"] },
                    { "id": "nack" },
                    { "id": "nack", "params": ["pli"] }
                ],
                extensions: ["http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01"]
            }
        }
    });

    answer.setDTLS(dtls);
    answer.setICE(ice);

    const candidates = endpoint.getLocalCandidates();
    candidates.forEach((candidate) => {
        answer.addCandidate(candidate);
    });

    transport.setLocalProperties({
        audio: answer.getMedia("audio"),
        video: answer.getMedia("video")
    });

    for (let offered of offer.getStreams().values()) {
        const incomingStream = transport.createIncomingStream(offered);

        const outgoingStream = transport.createOutgoingStream({
            audio: false,
            video: true
        });

        outgoingStream.attachTo(incomingStream);

        const info = outgoingStream.getStreamInfo();

        answer.addStream(info);
    }

    return answer;
}

double check what is the ip that you are using to create the endpoint, it should be the one that the browser the media to.
Also, check chrome://webrtc-internals for more insights.

So, the ip of the endpoint should be the ip of the local browser?
For example, my local browser ip is <IP_ADDRESS>, the media server ip is <IP_ADDRESS>, I should be like this const endpoint = MediaServer.createEndpoint('<IP_ADDRESS>')?

It should be the media server's  ip.

it should be
const endpoint = MediaServer.createEndpoint('<IP_ADDRESS>')

Please enable logging via:
MediaServer.enableLog(true);
MediaServer.enableDebug(true);
MediaServer.enableUltraDebug(true);
```

And send me the output please

Yes, I set it up at the beginning.
But now it still doesn't work.
I saved the log of the media server (see the attached file), and I saw that it always shows DTLSICETransport::ActivateRemoteCandidate() | Remote candidate [<IP_ADDRESS>:50351,use:1,prio:1853824767]  in a loop.
Is it because I have not set the server generated candidate to local or set the locally generated candidate to the server?

Sorry about that, I found this problem is caused by the cloud server's port security policy. o(╥﹏╥)o
@murillo128 @notedit Thanks!

There is another problem, the video stream only plays smoothly at the beginning, and then stops.
When the video stops, I see the loop in the server's log:
[0x7fad8efad700][1531206104.598][DBG]-DTLSICETransport::SendPLI() | [ssrc:2857972602]
[0x7fad8efad700][1531206104.598][DBG]-DTLSICETransport::ReSendPacket() | resending [seq:13152,ssrc:362380999]
[0x7fad8efad700][1531206104.598][DBG]-DTLSICETransport::ReSendPacket() | packet not found, requesting PLI instead [seq:13152,ssrc:362380999]

Last log:
[0x7fad8efad700][1531206104.598][DBG]-DTLSICETransport::SendPLI() | [ssrc:2857972602]
[0x7fad8efad700][1531206104.598][DBG]-Lost packets [ssrc:2857972602,seq:45186,lost:127,total:71]
[0x7fad8efad700][1531206104.598][DBG]-Lost packets [ssrc:2857972602,seq:45187,lost:0,total:70]
[0x7fad8efad700][1531206104.598][DBG]-Lost packets [ssrc:2857972602,seq:45188,lost:0,total:69]
[0x7fad8efad700][1531206104.598][DBG]-Lost packets [ssrc:2857972602,seq:45189,lost:0,total:68]
[0x7fad8efad700][1531206104.598][DBG]-Lost packets [ssrc:2857972602,seq:45190,lost:0,total:67]

So, is it disconnected?

Please, open a different issue for this new topic, or better, use the mailing list for answers.


Scroll into view after uploads

When uploading a table, the new table is selected but the table view does not scroll into the selection.

Fixed with 2.17.0


Dedupe imports

TypeScript compilation into system doesn't dedupe imports.
Currently I believe this will work, but it won't give as good performance because duplicated imports run through normalization and tree tracing twice.
We need to include a duplicate check on each import, like was provided in https://github.com/systemjs/systemjs/pull/623/files.

Or, we should blanket throw on this scenario, and somehow catch it...

TypeScript has been updated not to output duplicates, so having the performance regression is fine.


error Killed   java $before -jar $PROG/../share/halign-stmsa.jar $after

I run with command
halign -o merge_genome_dna.aln -t 20 -Xmx1000g merge_genome_dna.fna
that merge_genome_dna.fna contain 2 sequence that first sequence length=8,735,486 and second sequence length = 7,023,957
that error
reading merge_genome_dna.fna... finished in 209 ms
suffix tree: 4985 ms
name: 7319 ms
anti-name: 11 ms
/miniconda3/envs/halign/bin/halign: line 56: 2434645 Killed                  java $before -jar $PROG/../share/halign-stmsa.jar $after
how should i slove this problem?
thank you

@Thtcare , Thank you for reporting the issue.
The problem is likely due to the length of the sequences being aligned, which causes a memory overflow during the dynamic programming process. In the next version of HAlign, we are considering incorporating the Wavefront Alignment Algorithm (WFA) to address such issues. In the meantime, we recommend using WFA2-lib or other software to perform the alignment of these large sequences.
Please let us know if you have any further questions.


ThemeData.copyWith() doesn't update dependent themes

Summary: Adding colors to ButtonThemeData (https://github.com/flutter/flutter/pull/22013) highlighted a general problem with ThemeData.copyWith: subordinate themes (like ThemeData.buttonTheme) aren't updated when a ThemeData property they depend on is changed.
ThemeData.copyWith has simple semantics: it updates the specified fields, but not dependent fields. For example there are 10 subordinate themes, each with its own set of ThemeData dependencies:
  colorScheme
  buttonTheme
  sliderTheme
  tabBarTheme
  chipTheme
  inputDecorationTheme
  pageTransitionsTheme
  textTheme
  primaryTextTheme
  accentTextTheme

None of the subordinate themes are changed if (say) a color they depend on is changed with ThemeData.copyWith(). For example:
myThemeData.copyWith(buttonColor: myButtonColor) doesn't change myThemeData.buttonTheme.
We could add a ThemeData.apply method, like TextTheme.apply but more complicated. The basic idea would be to update all of the subordinate themes that depend on ThemeData properties like primaryColor and accentColor.
To implement ThemeData.apply, we'd have to implement colorScheme.apply, buttonTheme.apply etc.
Documenting ThemeData.apply would be complicated itself because each subordinate theme has its own set of ThemeData dependencies.
That said, in the applications I've looked at - usually - where developers use ThemeData.copyWith they're usually careful to rebuild the subordinate theme they're trying to effect. The ButtonTheme is an exception because it's new, and see https://github.com/flutter/flutter/issues/22711.
For the moment I'm inclined to leave things as they are. Some improvements in the docs (including some examples) would help.

Seems like the problem stems from the fact that copyWith calls ThemeData.raw. This misses out on all of the clever logic that happens in the factory ThemeData constructor. Could copyWith delegate to the regular ThemeData factory constructor rather than ThemeData.raw?

We have same issue. We created a light and a dark theme that should preferably inherit shared properties from a base themedata object. But using copyWith on the base theme will not work, so the only workaround for now is to have redundant properties in both the light and the dark theme.

Same issue here. I think its
I think this is because the reason associated with buttonTheme in ThemeData is not correctly told when copyWith.
The constructor of ThemeData did this, so it works fine.
buttonTheme ??= ButtonThemeData(
      colorScheme: colorScheme,
      buttonColor: buttonColor,
      disabledColor: disabledColor,
      highlightColor: highlightColor,
      splashColor: splashColor,
      materialTapTargetSize: materialTapTargetSize,
    );

Can we solve this problem?  Because this behavior was used in the code of this codalabs and caused the wrong effect.
// TODO: Build a Shrine Theme (103)
final ThemeData _kShrineTheme = _buildShrineTheme();

ThemeData _buildShrineTheme() {
  final ThemeData base = ThemeData.light();
  return base.copyWith(
    accentColor: kShrineBrown900,
    primaryColor: kShrinePink100,
    buttonColor: kShrinePink100,
    scaffoldBackgroundColor: kShrineBackgroundWhite,
    cardColor: kShrineBackgroundWhite,
    textSelectionColor: kShrinePink100,
    errorColor: kShrineErrorRed,
    // TODO: Add the text themes (103)
    // TODO: Add the icon themes (103)
    // TODO: Decorate the inputs (103)
  );
}

I think copyWith method or buttonTheme should be refactored due to current mechanism could cause side effect

I was able to reproduce in 1.21.0-1.0.pre.
The ThemeData.copyWith() method doesn't currently update dependents theme as we can se at:
https://github.com/flutter/flutter/blob/54c9441723ec61baaeb0fbf71fdcf4e415116e6e/packages/flutter/lib/src/material/theme_data.dart#L1107-L1253

 flutter doctor -v
[✓] Flutter (Channel dev, 1.21.0-1.0.pre, on Mac OS X 10.15.5 19F101, locale en-AO)
    • Flutter version 1.21.0-1.0.pre at /Users/pedro/dev/SDKs/flutter_dev
    • Framework revision f25bd9c55c (5 days ago), 2020-07-14 20:26:01 -0400
    • Engine revision 99c2b3a245
    • Dart version 2.9.0 (build 2.9.0-21.0.dev 20bf2fcf56)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/pedro/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Users/pedro/Library/Application
      Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/193.6514223/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.5)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.5, Build version 11E608c
    • CocoaPods version 1.9.3

[✓] Chrome - develop for the web
    • CHROME_EXECUTABLE = /Applications/Google Chrome.app/Contents/MacOS/google-chrome-unsafe

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] Android Studio (version 4.0)
    • Android Studio at /Users/pedro/Library/Application
      Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/193.6514223/Android Studio.app/Contents
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.47.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.12.1

[✓] Connected device (3 available)
    • macOS (desktop)  • macos      • darwin-x64     • Mac OS X 10.15.5 19F101
    • Web Server (web) • web-server • web-javascript • Flutter Tools
    • Chrome (web)     • chrome     • web-javascript • Google Chrome 83.0.4103.116

• No issues found!

This issue still exists. Updating labels to reflect the same


Index finger and pinky splay bug?

It appears that your index and pinky have their splay effected by height in the world and hand rotation?

https://github.com/Dyslex1k/VRC-Skeletal-Hands/assets/27322698/747a7601-5f5a-411e-a1fd-ea2926db6da8

Hi are you using index controllers. If so I believe this is just how skeletal hand tracking works on the steam vr end. It does this so your hand can make poses like peace!


Implement an event that triggers every time an user is moved by an admin to a different voice channel

General Troubleshooting

[x] I have checked for similar issues.
[x] I have updated to the latest JDA version.
[x] I have checked the branches or the maintainers' PRs for upcoming features.

Feature Request

Example Use-Case

Already possible. See GuildVoiceUpdateEvent
Also #1337

This event only allows me to see the affected Entity. I cannot retrieve the Entity that triggered the GuildVoiceUpdateEvent.

Discord doesn't give that information, thus JDA cannot either.

Discord doesn't give that information, thus JDA cannot either.

I managed to find a workaround by using the audit logs of the guild, thanks!


What is the limit of requests per hour?

What is the limit of requests that can be made per hour for each endpoint?

https://github.com/mgp25/Instagram-API/issues/1661


Discord Version

is it only for Discord.jsv14, and not v13?

Check Releases, There are  2 releases, 1 discord.js v14, and 1 for discord.jsv14


fixed type cast issue; added handler for uncaught errors

When sending illegal JSON query request, unexpected exceptions may raise, which will print stack traces to expose server's file structure. the way to recreate the issue is
curl -vv  http://localhost:18022/graphql -H 'Content-Type: application/json' --data '{"": "query { __schema { types {name } }}"}'

and the response is
< HTTP/1.1 500 Internal Server Error

<!DOCTYPE html>

<meta charset="utf-8">
<title>Error</title>

Error: Must provide document
    at invariant (./node_modules/graphql/jsutils/invariant.js:19:11)
    at Object.validate (./node_modules/graphql/validation/validate.js:56:34)
    at doRunQuery (./node_modules/apollo-server-core/dist/runQuery.js:110:38)
    at ./node_modules/apollo-server-core/dist/runQuery.js:21:56
    at process._tickCallback (internal/process/next_tick.js:68:7)

so I write an error handler to disable stack printing when error occurs.

it seems the stack can be suppressed by settings NODE_ENV=production


Kodi Hardware acceleration RK3368 Support Android

Cant enable any hardware acceleration in KODI, LED's just blink. Once disabled (all) everything works fine. Do you have any updated XBMC clients that I can install. Thanks

Could you please add some more information?
I am sure there is no special android support for hyperion with kodi
But you could try this one
https://github.com/brindosch/script.service.hyperion

Thanks for the response and I'll try and explain my problem in more detail.
I am running with hyperion server from a pi connected to an Arduino Mega R3. I have a 4k android box with kodi running the hyperion client and everything works fine if I disable hardware acceleration in the video options in kodi. There are 3 hardware codecs I can chose from however the rockchip RK3368 codec for hardware acceleration when enabled causes the led just to flash. Some of the content I play needs the support of hardware in the video departments. )

So you are using the Hyperion Kodi plugin. There are problems with devices that uses that hw blobs. I am sure there will never be a clean solution for this. Due to the point that rockchip have a very bad reputation (open source/documentation access) (in terms of software).
I am sorry. If someone find a solution, don´t hesitate to submit it.
/Closed


Sphinx Extension Continuous Integration and Testing ...

Need to add testing suite for the sphinx-extension. Not entirely sure how to implement this.
Option 1
Construct a sphinx environment and run make jupyter to test known conversions between input and output?
Option 2
Direct tests on node types in the sphinx builder
any ideas are welcome

Option 1 is implemented in PR #34


find another name for temp, add sample misaligned test

https://github.com/clean-code-craft-tcq-m-2/test-failer-in-py-PedroITello/edit/main/misaligned.py?pr=%2Fclean-code-craft-tcq-m-2%2Ftest-failer-in-py-PedroITello%2Fpull%2F1

https://github.com/clean-code-craft-tcq-m-2/test-failer-in-c-riceloya/blob/c9981713f396ad9869319a55c02cd4d1633c0e50/misaligned.c

Inclided in recap


tooltip data use outside chart

hello, I'm using your library to adjust project
but I have question about something.
I checked the module about event. example onPress, onDataZoom
but I need data about tooltip outside your module
I try to manipulate your module to listen event about tooltip
but Only receive event are Touch event OnPress or DataZoom.
would you able to get tooltip info if touch event triggered?
that event get outside on your module. that would be great to use my project.
but I really thank you about your sincere feedback on your project
Thank you

Can you tell the event's name？
There have a event :
legendSelectChanged

Too long no reply, wait for new message I will open again.


Update sponsor information

@JohnTitor readme also needs an update with a badge or removing the caffeine entry.

Okay, removed


NEON64: enc: ASM build fails on gcc with dd7a2b5f31

It looks like at least gcc fails now with BASE64_NEON64_USE_ASM set and -O0. Example output:
18:45:00 In file included from ../deps/base64/base64/lib/arch/neon64/codec.c:63:
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:11:36: error: invalid character ' ' in raw string delimiter
18:45:00   "ld3 {"P".16b, "Q".16b, "R".16b}, [%[src]], #48 \n\t"
18:45:00                            ^
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:18:28: error: invalid character ' ' in raw string delimiter
18:45:00   "ushr %[t2].16b, "R".16b,   #6         \n\t" \
18:45:00                     ^
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:23:28: error: invalid character ' ' in raw string delimiter
18:45:00   "and  %[t3].16b, "R".16b,   %[n63].16b \n\t"
18:45:00                     ^
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:31:16: error: invalid character ' ' in raw string delimiter
18:45:00   "tbl "R".16b, {v8.16b-v11.16b}, %[t2].16b \n\t" \
18:45:00         ^
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:37:35: error: invalid character ' ' in raw string delimiter
18:45:00   "st4 {"P".16b, "Q".16b, "R".16b, "S".16b}, [%[dst]], #64 \n\t"
18:45:00                            ^
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c: In function 'enc_loop_neon64':
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:11:27: error: stray 'R' in program
18:45:00   "ld3 {"P".16b, "Q".16b, "R".16b}, [%[src]], #48 \n\t"
18:45:00                            ^
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:65:2: note: in expansion of macro 'LOAD'
18:45:00   LOAD("v2", "v3", "v4") \
18:45:00   ^~~~
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:114:10: note: in expansion of macro 'ROUND_A_FIRST'
18:45:00    "    " ROUND_A_FIRST()
18:45:00           ^~~~~~~~~~~~~
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:11:28: error: expected ':' or ')' before string constant
18:45:00   "ld3 {"P".16b, "Q".16b, "R".16b}, [%[src]], #48 \n\t"
18:45:00                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:65:2: note: in expansion of macro 'LOAD'
18:45:00   LOAD("v2", "v3", "v4") \
18:45:00   ^~~~
18:45:00 ../deps/base64/base64/lib/arch/neon64/enc_loop_asm.c:114:10: note: in expansion of macro 'ROUND_A_FIRST'
18:45:00    "    " ROUND_A_FIRST()
18:45:00           ^~~~~~~~~~~~~

and a bunch of similar "stray 'R'" errors after that.
clang compiles without errors however.

It looks like the character "R" is some kind of reserved token that I'm blanking on offhand. Changing the macro variables to start with "A" instead of "P" in all of the macro functions fixes things.

Ah ok it seems that "R" is a valid string literal prefix much like "L" can be for wide strings. Apparently there are others that I was unaware of like "U"/"u" and ""u8" according to here.

I think this might be a side effect of compiling this C library as C++ code. We're being hit by a language incompatibility.
In the C world, this would be gross behavior by GCC, because the R variable is only supposed to be seen by the preprocessor. And the preprocessor is only supposed to do textual substitution. The R is never supposed to be visible to the compiler, at all, ever. So through that lens, this bug makes no sense and seems bizarre.
In C++ it's apparently acceptable?
Anyway, thanks for finding this bug/incompatibility. I think your PR is the right fix.


HDDS-4395. Ozone Data Generator for Fast Scale Test

This patch is a joined effort of @jojochuang and me (He implemented the hard part, I finalized it for a final PR)
What changes were proposed in this pull request?
New Freon tests to generate data offline.
Note: datanode generator generates closed containers where pipeline data is not necessary. There are two small modifications to make it possible to use ozone even if the pipline info is not saved to OM. (pipeline info is always updated with SCM data, anyway)
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-4395
How was this patch tested?
Tested on real cluster.

Started ozone cluster (without writing any data)
Stopped the cluster
Generated OM, SCM, and DN data with the freon tool
Started cluster again
Executed tests to check the data

The exact commands can be found in helper scripts:
hadoop-ozone/dist/src/main/compose/upgrade/delete-data.sh                                                         |  29 +++++++
hadoop-ozone/dist/src/main/compose/upgrade/generate-data.sh

Can you please help with a review @lokeshj1703 or @jojochuang?

Can we also have the delete-data script as well? It becomes easier to delete all the data after generation.

Sure I created a script just with the deletion part.

Thanks the review @adoroszlai and @lokeshj1703
I am merging it now...