abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 00:11 | Nová verze

    Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.

    Ladislav Hagara | Komentářů: 0
    včera 20:44 | IT novinky

    Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.

    Ladislav Hagara | Komentářů: 0
    včera 17:22 | Nová verze

    3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.

    Ladislav Hagara | Komentářů: 0
    14.7. 22:22 | Komunita

    Open source webový aplikační framework Django slaví 20. narozeniny.

    Ladislav Hagara | Komentářů: 0
    14.7. 16:11 | Komunita

    V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.

    Ladislav Hagara | Komentářů: 0
    14.7. 11:33 | IT novinky

    Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.

    Ladislav Hagara | Komentářů: 26
    14.7. 10:55 | IT novinky

    Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.

    Ladislav Hagara | Komentářů: 20
    13.7. 17:55 | Zajímavý projekt

    Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.

    Ladislav Hagara | Komentářů: 17
    11.7. 16:44 | Komunita

    Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.

    Ladislav Hagara | Komentářů: 3
    11.7. 14:55 | Humor

    McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.

    Ladislav Hagara | Komentářů: 16
    Jaký je váš oblíbený skriptovací jazyk?
     (59%)
     (26%)
     (7%)
     (3%)
     (1%)
     (1%)
     (4%)
    Celkem 399 hlasů
     Komentářů: 16, poslední 8.6. 21:05
    Rozcestník

    Dotaz: Python a pojmenovana roura (uz zase)

    12.8.2010 10:55 Radim
    Python a pojmenovana roura (uz zase)
    Přečteno: 342×
    Zdravim, Mam opet problem s pojmenovanou rourou a screenletem. Mam script v bashi. Script spocita cislo, otevre si pojmenovanou rouru, soupne tam spocitane cislo a rouru zavre. To vsechno se deje pomoci normalniho presmerovani vystupu ">". Screenlet si otevre onu rouru pouze pro cteni a v non blocking modu a pomoci gobject.io_add_watch() se diva, jestli tam uz je cislo. Kdyz ne, ceka, kdyz ano, zavola funkci, ktera cislo nacte do promenne a dal s nim pracuje. Akorat kdyz onen script rouru zavre, zacne se mi to cyklit a vytizi procesor na 100%, coz je samozrejme nezadouci. Toto trva do chvile, nez si script znovu rouru otevre pro dalsi cislo a az ji znova zavre, zacykli se to zas. Rouru ve screenletu otviram pomoci os.open(self.cesta_k_roure,os.O_RDONLY|os.O_NONBLOCK)". Vi nekdo, co s tim? Dik

    Odpovědi

    12.8.2010 15:10 Patrik Uhrak | skóre: 31 | blog: pato
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)

    Zdravim.

    Mne toto pripada, akoby ten skript kontroval az prilis casto(resp. tak casto, ako je to v jeho silach). Nie je problem vytazit cpu na maximum, ak sa mu nezada daky casovy limit, interval, v ktorom to kontrolovat. Takze by som tam skusil dat sleep a spustil to opat. Ale vsetko je to len moja domnienka skromna :)

    import time
    time.sleep(sekundy)
    16.8.2010 10:31 Radim
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    Podle me, fce os.open (pote, co se roura z druhe strany zavre) snazi se usilovne spojeni obnovit nebo neco podobneho a to zpusobi narust zatizeni. Akorat to reseni nepomaha. Kdyz dam do fce, kterou vola prave io_add_watch 1 sec pauzu a krmici script pracuje v intervalu napr. 5 sec, tak porad zbyvajici 4 sec. se cykli. Jistou nadeji jsem vkladal do flagu pro os.open (os.O_RDONLY apod.), ale jeste to budu muset pohledat. Zatim se mi zda, ze v kombinaci flagu, kterou pouzivam (os.O_RDONLY|os.O_NONBLOCK) se pri prvotnim otevreni sveho konce roury fce os.open nastavi do nejakeho mezistavu, ceka az se otevre i ten druhy konec a pak se prepne do "finalniho" stavu. Kdyz se ale druhy konec zavre, uz se nedokaze prepnout do toho mezistavu zpatky a proto pak zmatkuje. Kdyby nekdo vedel, jak ten mezistav nanutit zpatky, to by myslim bylo resenim.
    Chytrex avatar 16.8.2010 19:05 Chytrex | skóre: 30 | Bohumín
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    tak mě napadá.. a proč tu rouru nenecháš open a nefedruješ do ní jen čísla?
    Hrdý člen KERNEL ULTRAS .:. define QUESTION ((bb) || !(bb)) .:. Odmítám vaši realitu a nahrazuji ji svou vlastní..
    17.8.2010 02:25 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    Zase otázka bez kousku funkčního kódu... Tak jsem si testovací program vytvořil:
    import gobject
    import os
    
    def handler(fd, *args):
        print os.read(fd, 1024)
        return True
    
    fd = os.open("x", os.O_RDONLY | os.O_NONBLOCK)
    gobject.io_add_watch(fd, gobject.IO_IN, handler)
    gobject.MainLoop().run()
    Provedu mkfifo x, v jednom okně spustím tento program, v druhém zapíšu něco do té roury (echo foo >>x), a hurá - procesor je vytížen. Co s tím?

    První věc je podívat se, co to vlastně furt dělá. Tzn. nedomýšlet, zda onen deskriptor není v nějakém tajemném mezistavu a nehledat magickou kombinaci flagů pro os.open(), ale podívám se na výpis strace. Vidím spoustu řádků
    poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}], 3, -1) = 1 ([{fd=3, revents=POLLHUP}])
    V man poll se praví:
    The bits that may be set/returned in events and revents are defined in <poll.h>: 
        ...
        POLLHUP
               Hang up (output only).
    Takže to vypadá, že od té doby, co shell po vykonání příkazu echo foo >>x uzavřel rouru, ten poll neustále vyhazuje POLLHUP, glib pak poll volá stále dokola a to vytěžuje ten procesor.

    Nějaké řešení... Napadlo mě uzavřít zápisovou stranu pomocí shutdown, nevím, jestli by to fungovalo, ale protože v Pythonu shutdown jaksi ani není, nebudu se tím vůbec zabývat :-)

    Informace o HUPu bude nejspíš jen jeden bit nastavený v nějaké tabulce kernelu, možná by šel nějak vyresetovat, ale teď si na nic nevzpomínám. (Možná by zrovna tohle udělal ten shutdown.)

    Další řešení by bylo rouru uzavřít a znovu otevřít, tím bychom se zbavili toho POLLHUPu. Nejspíš by se ten nový deskriptor musel znovu zaregistrovat přes io_add_watch(). Taky není zrovna elegantní řešení.

    Na Mac OS X by dle příslušné manuálové stránky mohlo pomoct přidat POLLHUP do zachytávaných eventů při volání poll(), ale na Mac OS X asi nejsme.

    Celkem dobré řešení by ale bylo mít neustále tu rouru otevřenou pro zápis, protože ten POLLHUP se objeví zřejmě až když tu rouru uzavře poslední "zapisovatel". Experimentálně ověřeno, funguje, když
    fd = os.open("x", os.O_RDONLY | os.O_NONBLOCK)
    se nahradí za
    fd = os.open("x", os.O_RDWR | os.O_NONBLOCK)
    Zkus to :-)

    (Takže nakonec stačilo najít magickou kombinaci flagů pro os.open(), ale teď aspoň víme proč.)
    17.8.2010 02:38 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    Jak tak nad tím přemýšlím, tím shutdownem bych možná musel uzavřít čtecí stranu. Což je dost na houby, když z toho pak chci ještě číst :-)
    17.8.2010 10:36 chochi | skóre: 29 | Praha
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    Ja bych to videl spis tak, ze by tazatel potrboval neco takoveho:
    import gobject
    import os
    
    def handler(fd, *args):
        st = os.read(fd, 1024)
        print st
        if st == "":
            # Konec souboru - zavrem stary a otevrem novy
            os.close(fd)
            fd2 = os.open("x", os.O_RDONLY | os.O_NONBLOCK)
            gobject.io_add_watch(fd2, gobject.IO_IN | gobject.IO_HUP, handler)
            return False
        else:
            return True
    
    fd = os.open("x", os.O_RDONLY | os.O_NONBLOCK)
    gobject.io_add_watch(fd, gobject.IO_IN | gobject.IO_HUP, handler)
    gobject.MainLoop().run()
    
    Vzdy po konci souboru skoncit stary io-watch a pridat novy na novem souboru.
    19.8.2010 10:23 Radim
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)

    Hmm. Jako programator amater a samouk jsem zase koukal, co vsechno se da zjistit. O "strace" jsem do ted nemel potuchy.
    Napad se zaviranim a opetovnym otviranim jsem mel taky, ale jak pises, neni to moc elegantni a hlavne mi to fungovalo jenom nekdy. Sem asi tu myslenku asi implementoval nejak blbe, protoze zpusob jakym to napsal Chochi(viz nize) se jevi jako funkcni (testovano).
    Nicmene os.RDWR se jevi jako pekne a (aspon zatim) funkcni reseni, takze jsem si vybral tohle.
    Dik.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.