ahoj :) 1) no prave v tom, je ten pes zakopany, ze sa ma odoslat ten buffer, len co sa naplni, a neviem, ze aka ina akcia by sa mala vykonat ;( v dokumentacii k asyncore nieje nic take napisane ;(
2) diky veeeeeelmi pekne za krasne napisane vysvetlenie celej tej veci s riadiacimi znakmi ;) k tomu ps: napisal som to preto, lebo nemam rad, ked mi niekto vyka(mam to zo skoly, co mi od minuleho roku zacali novi ucitelia vykat, a ja nie a nie si na to zvyknut ;(( ) :) este raz diky za vysvetlenie :) 2007/11/28, Petr Prikryl <[EMAIL PROTECTED]>: > Tomy novella > > ------ > > c = atlantis_client() > > c.buffer = "JEDEN PRIKAZ\r\n" > > c.buffer = "DRUHY PRIKAZ\r\n" > > ------ > > > > ... a odoslalo mi LEN tu druhu vec(v tomto pripade "DRUHY PRIKAZ\r\n") > > preco? ako mam odoslat obe? > > Dvakrát za sebou se naplnil buffer, pokaždé > něčím jiným. Asi se mezi tím musí provést > nějaká akce, která obsah bufferu odešle. > > > 2) (filozoficka): stale ked poslem po nejakom protokole prikaz, tak > > ma koncit "\r\n"? - totiz donedavna som novy riadok ukoncoval len > > "\n"a stacilo to, preco je tak aj \r ved to je tabulator a ten predsa > > nevidno! :) aspon ja v tom nevidim logiku ;( > > Není to filosofická, ale technická otázka. Sekvence \r reprezentuje > řídicí znak Carriage Return (návrat vozíku), posloupnost \n > reprezentuje řídicí znak Line Feed (odřádkování). Oba řídicí znaky > dostaly název v době, kdy vznikl klasický mechanický dálnopis. > Znamenaly skutečně takto pojmenované mechanické akce. (Proto se taky > řídícím znakům začalo říkat řídicí znaky.) V uvedeném > pořadí se používaly proto, protože mechanická konstrukce dovolovala, > aby se přechod na nový řádek (pootočení válce) prováděla i při > pohybu vozíku na začátek. Pro zpětný pohyb vozíku tedy bylo dvakrát > tolik času. Tolik tedy k postrádané logice. > > Postupem doby se sekvence označovaná také jako CR LF stala oddělovačem > řádků v textových souborech, které už se na dálnopisnou stanici > neodesílaly. V unixových systémech se vypustilo \r, u Mac je to > myslím naopak. V DOSu a ve Windows zůstaly oba znaky. > > Aby se to programátorsky sjednotilo, zavedl se pojem "otvírání > souboru v textovém režimu", kdy se všechny možné koncové sekvence > při načítání upravují na jediný znak \n a při zápisu se \n > expanduje na příslušnou sekvenci, která se používá v daném OS. > > Pokud se ale soubor otvírá binárně, je nutné zapisovat všechny > znaky koncové sekvence. Při odesílání přes buffer se typicky > pracuje v binárním režimu. > > (Rýpnu si.) Unixoví programátoři otvírání souborů v textovém > režimu často ignorují právě proto, že při otvírání v binárním > režimu se vše v Unixu chová stejně, jako v textovém režimu. > Díky tomu někteří na-Unix-hrdí jedinci vytvářejí špatně > přenositelné zdrojové texty. > > Python až do verze 3.0 nedefinuje přísný datový typ řetězec > (ne unicode). Do uvozovek zapisujeme posloupnost bajtů, i když > nám je editor ukazuje jako písmenka. Ke konverzi jednoho znaku > \n z řetězce na příadnou dvojici dochází až při zápisu > do souboru otevřeného v textovém režimu -- a to jen v DOS/Windows. > Nikdy jindy. > > pepr > > > PS: prosim v mailoch tykat! nie vykat ;) > > P.S. Klidně mi v mailech vykej. Není to věc použitého média ;) > _______________________________________________ > Python mailing list > Python@py.cz > http://www.py.cz/mailman/listinfo/python > -- PS: prosim v mailoch tykat! nie vykat ;) [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python