Cu ce provocari tehnice v-ati lovit in ultima perioada

Salut @Dani! Multumesc pentru feedback! :slight_smile:

I-am adaugat la final ptr. ca erau adaugati in format str (eg: “42”) si nu in cum e int/uint/etc reprezentat de limbajul de programare. Prin urmare marimea putea sa fie “425” (3 bytes), “123456” (6 bytes), etc. A parut mai logic in momentul respectiv sa fac append decat prepend (desi se putea).

Vad acum ca nu-i un mod bun de a trimite datele in formatul asta, la recomandarea lui @serghei o sa ii zic dev-ului pe backend sa encodeze int-ul in format nativ (4 sau 8 bytes) folosind un tool gen htonl ptr. a decoda/encoda in bytes.

E interesant insa cum marimea in format string ar putea fi mai eficienta daca datele sunt sub 1024 (folosim sub 4 bytes, economisim cativa bytes). Ptr. marimi de peste 1024 e mai eficient cu formatul serializat al int-ului (4 bytes).

Specific GDScript, nu merge daca nu stie marimea initiala.
PoolByteArray decompress ( int buffer_size, int compression_mode=0 )
Hey, vad ca are si o metoda care nu cere marimea initala dar e mai lenta si suporta doar gzip. :confused:

https://docs.godotengine.org/en/stable/classes/class_poolbytearray.html#class-poolbytearray-method-decompress

Huh, interesant, nu stiam! O sa studiez mai bine subiectul, se pare ca nu e suportat complet inca.

Nu e simplu mai ales când restul codului este complicat.

Eu am rescris un command line app într-un package utilizabil din cod care va sfârși prin a fi folosit tot ca și comand line app. Un pic frustrant, dar măcar am învățat chestii.

Am încercat să rezolv un bug care părea a fi race condition dar s-a dovedit a fi și mai rău. Am sfârșit concluzionând că trebuie un nou API endpoint.