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.
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.
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.
Open source webový aplikační framework Django slaví 20. narozeniny.
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.
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.
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.
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ů.
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.
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.
from select import select import pty import os,sys import subprocess as sub import time (pid,fd) = pty.fork() if pid == 0: sub.call("python slave.py",shell=True) else: time.sleep(0.5) sent = 0 while True: for i in range(0,10): select([],[fd],[]) size = os.write(fd,"x"*1000) #os.write(fd,"\n") sent += size print(str(sent)) time.sleep(5)slave.py
import fcntl import os,sys from select import select import tty sys.stdout = open("log","w",0) # make stdin a non-blocking file fd = sys.stdin.fileno() fl = fcntl.fcntl(fd, fcntl.F_GETFL) fcntl.fcntl(fd, fcntl.F_SETFL, fl | os.O_NONBLOCK) # tty.setraw(fd) # #sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0) bytes_read = 0 print("on") while True: rlist,_,_ = select([sys.stdin],[],[],1) if sys.stdin in rlist: string = sys.stdin.read(200) bytes_read += len(string) print(str(bytes_read)) else: print("not ready")a ted kdyz pustim 'python master.py' a v terminalu vedle 'tail -f log' tak vidim ze poslednich 800 poslanych bytu zustane v bufferu, select rika ze sys.stdin neni ready pro cteni (protoze master.py nezapsala zadny novy data) a tech 800 bytu z buffer se precte az potom co master.py posle dalsi data do PTY Kdyz odkomentuju tu lajnu v slave.py ktera nastavuje velikost bufferu na 0 tak to jede hezky. Tohle pak vedlo k deadlocku v tom programku co pisu.
from select import select import pty import os,sys import subprocess as sub import time (pid,fd) = pty.fork() if pid == 0: sub.call("python slave.py",shell=True) else: time.sleep(0.5) sent = 0 while True: os.write(fd,"DATA") os.write(fd,"DATA") os.write(fd,"DATA") os.write(fd,"DATA") os.write(fd,"DATA") os.write(fd,"YOYO") select([fd],[],[]) string = os.read(fd,1024) if string == "YOYO": print("master received: YOYO\n") else: print("master:DEAD")slave.py
import fcntl import os,sys from select import select import tty log = open("log","w",0) # make stdin a non-blocking file fd = sys.stdin.fileno() fl = fcntl.fcntl(fd, fcntl.F_GETFL) fcntl.fcntl(fd, fcntl.F_SETFL, fl | os.O_NONBLOCK) # tty.setraw(fd) # #sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0) data_read = "" log.write("on\n") while True: rlist,_,_ = select([sys.stdin],[],[],1) if sys.stdin in rlist: data_read += sys.stdin.read(10) while len(data_read) >= 4: msg = data_read[:4] data_read = data_read[4:] log.write("slave: received "+msg+"\n") if msg == "YOYO": log.write("slave: sending YOYO\n") sys.stdout.write("YOYO") sys.stdout.flush() else: log.write("not ready\n")Kdyz pustite master.py a tail -f log tak vydite ze se zpracuji pouze prvni dve zpravy "DATA" a vse se zasekne. Pokud zmenite sys.stdin.read(10) v slave.py na sys.stdin.read(24) vse bude fungovat krasne v nekonecnem loopu. Pokud odkomentujete v slave.py radek sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0) tak vsechno bude chodit krasne v loopu i kdyz nechate sys.stdin.read(10) A ted moje otazka: Proc to tak je ... je toto chovani nekde zdokumentovano? Tyka se to pouze PTY ? A hlavne proc select nerika "jo sys.stdin je ready ke cteni" kdyz vi ze jsou v bufferu sys.stdin data ktera sys.stdin.read muze precist?
sys.stdin.read(10)Tohle nemůže se selectem dobře fungovat, je to vysokoúrovňové bufferující API, podobně jako funkce ANSI C nad FILE strukturama. Volání
select.select
je nízkoúrovňové API a lze kombinovat
pouze s nízkoúrovňovým čtením, tedy os.read
.
Jako hraní super, ale Python na něco takového absolutně není určený. Doporučuju zůstat jen u pokusů, případně si ty pokusy udělat i v céčku. Na skutečné asynchronní aplikace je lepší použít nějakou pythoní knihovnu, která to celé poskládá, případě si céčkovskou
asynchronní knihovnu napsat a implementovat v ní pythoní rozhraní,
pokud už to člověk musí nutně zkoušet na vlastní kůži.
Na nízkoúrovňové čtení bych radši zůstal u nízkoúrovňových funkcí. ty dokonce fungují i bez přepnutí fd do neblokujícího režimu (testováno v C).Jo, ted uz jsem se poucil a priste to presne takhle resit budu
jedina vec ktera me v pythonu nachytala a v C by se nestalaTo je tím, že python používá pro funkce namespacing, ať už pomocí modulů nebo tříd, popřípadě i objektů (to umí C taky, ale i tak funkce musí mít název alespoň na úrovni modulu). Takže se více funkcí jmenuje read, přitom jsou principiálně odlišné a pracují na odlišné úrovni.
ale i tak by mi to v C trvalo aspon petkrat tak dlouho nez v pythonu a nejspis bych to nikdy nedokoncil.Tak pokud ty céčkoviny zabírají jen nějaký jeden malý modul, takto může být jednodušší než se učit pythoní C API.
Kdyz mas sys.stdin jako priklad primo v python docs tady tak me to zmatlo dobre.To se dá buď brát jako chyba v manuálu nebo jako popis příliš spoléhající na znalosti čtenáře. On si totiž select umí ten deskriptor zřejmě z objektu vytáhnout sám, takže file objekt je sám o sobě ok. Problém je v implementaci file.read(), která i podle manuálu spouští fread(), což nemusí fungovat. Prostě se počítá s tím, že čtení bude realizováno takto:
os.read(f.fileno())
Imho bude sys.stdin fungovat dobre se select pokud neni v PTY.To těžko.
Jo a to co kodim bych hranim nenazyvalTwisted umí být komplikovaný, ale dá se naučit. Jednou jsem v tom něco zkoušel. Problém je, že twisted nejde dobře kombinovat s jinými a spoustu věcí neumí. Ale na asynchronní přístup v C se mi osvědčil glib. V Pythonu se dá použít gobject introspection, takže můžeš pracovat jak v C tak v Pythonu, aniž byses učil pythoní C API., ono je to uzitecny a kodim to jen proto ze jsem zadny program co by resil stejny problem nenasel - a sam bych to na vlastni kuzi taky raci nezkousel ale jak rikam, neumim twisted.
Tak pokud ty céčkoviny zabírají jen nějaký jeden malý modul, takto může být jednodušší než se učit pythoní C API.Jeste to tak abych se ucil
Imho bude sys.stdin fungovat dobre se select pokud neni v PTY. To těžko.Pokud tam pude stdin pres pajpu. To by pak vysvetlovalo ten manual. Jestli v tom manualu mysleli pouzite sys.stdin v select a pak ctete os.read(0,1024) tak je to dost nekonzistetni.
Problém je, že twisted nejde dobře kombinovat s jinými a spoustu věcí neumí.To byl dalsi duvod proc jsem se mu vyhnul.
Jeste to tak abych se ucilTak cygwin je unix jako každý jiný, že :), linuxové distribuci je prostředí cygwinu dost blízké. Jinak bacha, kdybys používal Python přímo na windows, tak spousta věcí funguje trochu jinak. Zvlášť těch nízkoúrovňových. Ono se na první pohled zdá, že vespod je úplně stejná unixovská vrstva, ale není to úplně pravda. Dělal jsem začátečnické školení Pythonu ve firmě se smíšenou výbavou účastnických počítačů a ty Windows jsme dost řešili. Ale všechno nějak vyřešit šlo.me uplne staci jak vypada popis funkce forkpty() v C a naproti tomu pty.fork() v pythonu
... a jeste to kompilovat pro cygwin apod. tady me budes tezko presvedcovat ze jsem to mel psat v C
To byl dalsi duvod proc jsem se mu vyhnul.To je obecný problém kombinace synchronních a asynchronních API, bez ohledu na jazyk. Problém je v tom, že Python je většinou tvůrců knihoven vnímán jako skriptovací jazyk a pro ten sjou synchronní API typická. Problém je, že z asynchronního API jde synchronní vyrobit celkem lehce (v dynamickém jazyce zvlášť), zatímco naopak to nejde a jedinou možností je vláknovat. Spousta vývojářů i core pythoních věcí zase neřeší vlánka, tak se pro jistotu zamyká celý interpret a paralelní zpracování pythoních vláken je z principu vyloučené, tudíž multiprocessing vychází v pythonu mnohem rychlejší než multithreading. Paradoxem ovšem je, že komunikace mezi procesy je synchronní a tudíž i při multiprocessingu je předávání zpráv realizováno vláknem (tedy multithreadingem).
Tiskni
Sdílej: