Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Jako jiné knihovny v čistém C, použít cleanup a někde bokem si držet informace o strukturách (to kvůli polymorfismu při úklidu). Na embedded bych tedy především nealokoval nic na haldě, ale obecně se používají v sofistikovaných knihovnách právě ukazatele na “typy”. Je to taková vyšší dívčí céčka, třeba CoreFoundation je dobrý příklad.Bez explicitního free.A jak bys to delal v cistym C?
Jak na to tak koukám, tak pro čisté C by se na embedded hodilo něco jako kqueue — kanály vyžadují extra syntax (nebo hnusné workaroundy).Hm, tak teď už to GCD nepřipomíná...A je tam ten select, co ses na něj ptal.
Bez explicitního free.Taky správa paměti by šla řešit elegantně, když už tam je tolik struktur, klidně by mohla alokace být transparentní.Co je transparentní alokace?
žádné hodiny ráno, na to fakt z vysoka kašluDoporučuji Vysokou školu života.
Typovou kontrolu vskutku nemá, ale to nemá hodně jazyků. Třeba Smalltalk, a taky byl svým způsobem revoluční.Nemá typovou kontrolu. Napsat v tom i triviální kód bylo puzzle. Kůl mi přilo akorát že kód vypadal jako konfigurák.I když LISP je jazyk napikaču.Proč? Všechny jazyky konvergují k Lispu
Torvalds má hodně dobrou angličtinu, soudě podle jeho projevů v diskusích.Kdo je autorem? Ta angličtina je otřesná.Myslim, ze Linus Torvalds. Asi se mu tam pletla Finstina.
https://play.golang.org/p/vcObtS5g4AJKdo je autorem? Ta angličtina je otřesná.
Taky správa paměti by šla řešit elegantně, když už tam je tolik struktur, klidně by mohla alokace být transparentní.Hm, tak teď už to GCD nepřipomíná...Na API CSP se nic nezměnilo
A je tam ten select, co ses na něj ptal. Nakonec jsem ho implementoval jednoduše jako skupinu tasků. Spustí se jenom jeden, ale vymažou se z tabulky všechny.
Hm, tak teď už to GCD nepřipomíná...Na cem jedete, ja chci taky takovej cajA ještě mi pořád nedošel!
"Migrující tasky" (kind of...) jsou na světě
https://youtu.be/GMtUod8J4GA
Zdroják: https://gist.github.com/mprymek/1b93972b71b8d3a59e143819356ea605
Na "super skvělé" škole budeš muset projít řadou sít, která likvidují lidiTo je legitimní postup, jak vyfiltrovat lemply
I když LISP je jazyk napikaču.Proč? Všechny jazyky konvergují k Lispu
Ty argumenty mi nepříjdou dvakrát přesvědčivé, myslel jsem, že to bude silnější. Navíc lecos z toho už asi neplatí nebo nebude platit v blízké budoucnosti. Například u defer, dokumentace tvrdí:Jo, výhled je pozitivní, určitě to postupně vylepší. Go by bylo pro MCU ideální jazyk, kdyby se podařilo nějak eliminovat GC (což je jednodušší, než se může zdát).CitaceThe defer keyword is almost entirely supported, with the exception of deferring some builtin functions.Navíc i když zpřehledňuje kód, dá se bez něj docela dobře žít.
Recover osobně nepoužívám, takže mi taky nechybí, net není a nebude v dohledné době podporován, takže to mne taky neomezuje. Externí síťová knihovna recover nepoužívá. Problémem je map, ani ne tak to omezení typů, ale co jsem četl, tak jeho neoptimalizovanost v některých případech. Chtěl bych věřit, že tohle se brzy spraví.
GC mi připadá, že není tak hrozný jak bylo prezentováno. Zaprvé jde vypnout (jinak by to na malých AVR ani nejelo) a s příchodem čipů s větší pamětí to není kritické. Je jasné, že na alokace člověk musí myslet, ale to platí i když to píše v C. Zadáním gc=none lze navíc trasovat místa, kde se alokuje paměť a jestli s tím nejde něco udělat. RT byl vždy vyšší dívčí a člověk musí myslet na věci, které jinde řešit nemusí. A co se týče zmiňovaného Pythonu, ve zdrojových kódech autoři píší, že se silně inspirovali GC z MicroPythonu.
Co se týče knihoven driverů, kupodivu jsem zatím nenarazil. Osobně to zatím jako velký problém nevidím. V projektech, které plánuji, těch používaných zařízení zase tolik není a přepsat případně driver z C do Go nevidím jako zásadní problém (největší může být s časováním). Zvláště poté, co jsem viděl jaká zvěrstva tam jsou občas páchána, takže bych to musel stejně upravovat. Navíc mi i myšlenka naprototypovat to rychle v Go a pak to případně přepsat do C, pokud je potřeba, připadá jako zajímavá.
Nejsem naivní a je mi jasné, že určitě někde narazím, ale zatím to zkusím dál. Pro kontext ještě jednou doplním, že se primárně bavím o CortexM.
Protože počítá reference. Když napíšu, že se tracing GC chová jako v Go obecně, tak nemůžeš argumentovat něčím, co má počítání referencí, to je zjevně irelevantníPython nemá klasický GC. Nebo se něco měnilo?Vůbec nevím, co má nebo nemá Python, ale vím, že paměť nějak hlídá a tyhle brikule nedělá
(Python má i mark-and-sweep jen pro cykly, jako zadní vrátka, což ovšem na věci nic nemění)Python nemá klasický GC. Nebo se něco měnilo?Takhle funguje každý GC (pokud nějak drasticky nesnížíš GOGC).Nepamatuju si, že bysme tohle řešili s Pythonem.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
