SHIGORBIRDMAN: No, já si myslim, že ne. Proto se tu ptám, jak. :)

Jak postavíš loop na proměnnym počtu iterací?

LOOCAS: a to je takovy problem nacist si to vsechno do toho pole bajtu (jak uz to delas) a brat to z nej? to "getdata" podle toho co pises vraci pole bajtu, to je takovy problem pouzit ji misto readbytes? odnekud musis vedet kolik v tom streamu je dat, to je takovy problem si to hlidat?

SHIGORBIRDMAN: No, problém je v tom, že ten stream je speciální cStream objekt knihovny OpenMCDF. Nemá metodu ReadBytes, má pouze metodu GetData(od, do).
Druhá věc je ten loop while. Já nezjistim žádný EOF. v IronPythonu ani žádnej takovej objekt neni. Afaik.

var id = stream.ReadBytes(16);
var lenbytes = stream.ReadBytes(4);
long len = lenbytes[0]+lenbytes[1]*256+lenbytes[2]*256*256+lenbytes[3]*256*256*256; //teda za predpokladu, ze je to ulozene jako maly endian
var strbytes = stream.ReadBytes(len);

a tak dal do, to cele do while cyklu dokud neni pozice ve streamu na konci. Neni mi moc jasne, v cem je konkretne problem.

SHIGORBIRDMAN: No, na to se právě ptám. :D Jak napsat cyklus, kterej bude procházet pole po různě dlouhejch krocích?

16 Bytů: ID (nepotřebuju)
4 Byty: množství dalších Bytů, ve kterejch je uloženej string (potřebuju!)
XY Bytů (dýlka je variabilní, uložená v předchozích Bytech, podle dýlky stringu), kde je string, kterej potřebuju upravit = změnit a tim i změnit jeho dýlku, což pak musim následně zapsat do předchozích 4 Bytů
4Byty: množství dalších Bytů, ve kterejch je uloženej string (ten nepotřebuju)
XY Bytů, množství určeno v předchozích čtyřech Bytech

a tohle pořád dokola, dokud jsou v poli Byty.

Jednoduše použít for x = 0 to len(Array[Byte]) použít nemůžu, jelikož by to chodilo po jednom Bytu.

LOOCAS: Pokud tě dobře chápu, tak bych si vytvořil vlastní implementaci stream readeru / writeru, která bude mít ReadString / WriteString, a která bude sama načítat, resp. zapisovat ty tvoje DYLKY. Takže v principu pak bys měl něco jako

while ((string token = inputStream.ReadString()) != null) {
  var modToken = token.ToUpper(); // do something with the token
  outputStream.WriteString(modToken);
}

Popřípadě tedy, pokud to nechceš konvertovat do stringu, tak si to ukládej do pole bajtů.

LOOCAS: mas to oparvdu jako normalni stream?
pak fakt nevidim duvod proc to neudelat jako cyklus, kdy postupne nactes 4 bajty id, 4 bajty delku stringu, tolik bajtu kolik ma mit string atd.

H_U_N_T_E_R: Array[Byte] mi vrací metoda .GetData() na tom stream objektu, kterej potřebuju upravit. Dělám to pomocí OpenMCDF knihovny na OLE strukturovanym storage v binárnim souboru (proprietárnim).


SHIGORBIRDMAN: No, mě jde spíš o to, že tak, jak to dělám, mám pocit, že neni úplně košer. :) Můj postup:

1) načtu soubor
2) vycucnu z něj ten stream objekt
3) ze stream objektu načtu všechny Byty v pořadí do Array[Byte] objektu

a teď ta moje prasárna:
4) pomocí Encoding.Unicode.GetString() překlopim celej Byte Array na unicode string
5) rozdělim si celej string na list objektů podle speciálního terminate charakteru theString.split("\x00")
6) vyměnim řetězce v poli, který potřebuju
7) složim zpětně string z toho pole s pomocnym terminate charakterem: "\x00".join(theList)
8) přeložim zpět na Byte Array: Encoding.Unicode.GetBytes(theString)
9) zapíšu do streamu
10) přepíšu stream v souboru, commitnu a uložim na disk.

Tomu překládání pomocí UTF-16 bych se chtěl vyhnout a řešit to na úrovni toho Byte Array, proto se ptám, jak iterovat Byte Array, když mám předem daný pravidla:

16 Bytů - vyhrazeno pro ID
4 Byty - délka následujícího stringu (UTF-16) (uložíme do proměnný DYLKA)
Len(DYLKA+1)*2 - počet následujících Bytů, který nesou textovou hodnotu (UTF-16)
4 Byty - délka násleudjícího stringu (UTF-16) (uložíme do proměnný DALSIDYLKA)
Len(DALSIDYLKA+1)*2 - počet následujících Bytů, který nesou textovou hodnotu (UTF-16)

(mimochodem, psaný je to v IronPythonu)

LOOCAS: pokud chces libovolne menit obsah toho streamu, jako ze jednotlive objekty muzou menit sve hodnoty a velikost, tak se z toho, pokud je to opravdu klasicky Stream, "pobavis".

Asi nacist vsechno do pameti jako deserializaci objektu v linked list seznamu (za predpokladu, ze je potrea nejak poradi).
Nebo projet cely stream a zjistit si indexy, na kterych zacinaji jednotlive objekty, a udelat si dictionary ID/index

zaroven bych asi musel definovat i nejvyssi pocet znaku v patternu, protoze jinak by mi to zakonite vratilo jen cely retezec jako ze se jednou opakuje.

ANDY_WARHOL: vybralo by to zaroven ty nejdelsi nejdriv.

H_U_N_T_E_R: chtel bych nejak definovat nejmensi pocet znaku v tom patternu, takze tvuj priklad bych definoval ze chci mit 2
a pak by vystup byl jen abab - 2x
protoze to co uz by jednou v tom paternu bylo by se uz nepocitalo znovu.
proste vypichnout unikatni co nejdelsi sequence

LOOCAS: proč to máš jako pole bytů? Pokud to není stream, tak si to stejně celý načítáš do paměti a ukládáš zpětně, pak bych použil nějakou vhodnější strukturu a custom serializaci/deserializaci. A jelikož se ti to vejde do paměti, tak rozdíl mezi zpracováním RAW pole a nějakého spojáků/něčeho jiného bude minimální.

ANDY_WARHOL: co je nejdelší opakující se sekvence znaků?
pro vstup "ababfabab" chceš mít výstup:
abab - 2x
ab - 4x
a - 4x
b - 4x

a f protože se neopakuje tam nemít?

mam taky dotaz. potreboval bych vyhledat v retezci nejdelsi opakujici se sekvence znaku. jak byste na to sli ?
nemam moc napad jak to udelat a na internetu sem nic moc nenasel.

LOOCAS: Ukazatel do toho pole?

Zdravim vespolek. :)

Mám tu jeden trochu nevšední problém. Potřebuju nějakym rozumnym způsobem parsovat ByteArray, bohužel je to ale proměnlivě veliký pole v závislosti na obsahu.

Ten stream objekt, kterej dostanu se sestává z následujících Bytů:

16 Bytů - vyhrazeno pro ID
4 Byty - délka následujícího stringu (UTF-16) (uložíme do proměnný DYLKA)
Len(DYLKA+1)*2 - počet následujících Bytů, který nesou textovou hodnotu (UTF-16)
4 Byty - délka násleudjícího stringu (UTF-16) (uložíme do proměnný DALSIDYLKA)
Len(DALSIDYLKA+1)*2 - počet následujících Bytů, který nesou textovou hodnotu (UTF-16)

A tohle se v tom streamu opakuje různě krát (podle toho, kolik těch textovejch proměnnejch je uloženo).

Máte někdo tip na to, jak efektivně podobnej stream parsovat a měnit jeho hodnoty? Zajímaj mě vždycky jen ty stringy, který budu měnit + zapisovat jejich novou dýlku. Celý je to stream Bytů (resp. ByteArray) a já bohužel nevim, kde začít, jak iterovat přes ty Byty s proměnlivou velikostí kroku.

Předem díky za tipy.

TENCOKACISTROMY: jj, sharpdevelop (nebo aspon monodevelop) na androidu, to bych si asi radosti strikl do textilu ;)

a ano, bez debuggeru ani ranu, printf debugging je neuveritelny terror (uzil jsem si to s unity na macu, kde debugger byval tak stabilni, ze nemelo nejmensi smysl ho spoustet)

SHIGORBIRDMAN: Ja javu taky moc nemusim. Mam to s ni stejne jako ty se C#. Nemoznost debugingu je trosku voser (stravil jsem asi 2 hodiny hledanim chyby pres logy, kterou bych pri debugingu nasel za par minut).

Na druhou stranu jako IDE na neco, kde jen udelas rychly hotfix resici nejakou trivialni chybu mi to prijde idealni.

Rozhodne bych ale uvital, abych takovejhle nastroj mel pro C#. To by bylo fakt super :).

TENCOKACISTROMY: mam aide nainstalene, chvilicku jsem v tom neco zkousel. Neexistence debuggingu je pro me dost smrtici, ale ta moznost naflakat si nejaky kod primo na tabletce je velmi prijemna.

Ja obecne javu velmi nerad, zvlast kdyz ji porovnam s mnohem prijemnejsim c#... bez anonymnich metod a eventu ani ranu :)

proto zvazuju ze bych teda zkusil monodroida / monotouch, jak to bude pouzitelny na appy a obecne jak to na tom je.
SAmozrejme hry bych mohl mastit v unity, kdyz uz mam i droidi licenci, ale to je prece jen spis na hry :)

SHIGORBIRDMAN: Doporucuju si vyzkouset AIDE ( https://play.google.com/store/apps/details?id=com.aide.ui&hl=cs ) ja v tom udelal dve maly appky a oproti eclipse/netbeans to je cely mnohem jednodussi a sviznejsi. Pravda i za cenu neexistence ruznych ficur (treba debugging).

Nicmene o tom monodroidu fakt uvazuju, protoze jako java v UI opravdu sucks! Ten jejich koncept s anonymnima tridama misto anonymnich metod je fakt pekelenej. Radoval jsem se ze maji generics, ale je ve skutecnosti jen fakovana. Coz nevadi v dobe vyvoje, ale pri runtime to uz trochu prekazi.