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.


Příspěvky - Mirek Prýmek

Stran: 1 ... 20 21 [22] 23 24 ... 618
316
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 17:15:54 »
Z hlavy nevím, ale můžu zkusit něco najít o “obvyklých podezřelých” (například Cheney apod.). Stay tuned ;)
Jezkovanoho, nedelej z toho vedu. Ukazal jsem problematicky priklad na par radku. Pokud jde nejak opravit, tak to bude oprava na par radku. Tak shut up and show the code :)

317
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 17:12:14 »
To, cos napsal, zjistit, jestli někde v hloubi objektového grafu není ukazatel.
Coz prave PRAKTICKY nejde. Pouzivam nejakou knihovnu. Tahle informace neni soucasti API, cili i kdyz si projdu zdrojaky, je mi to platny jak mrtvymu zimnik, protoze uz s nasledujici zmenou MINOR verze se to muze zmenit.

A vubec nemusi jit o cizi knihovnu. Muze jit o dve casti jedne aplikace, ktere pisou dva tymy. Jeden vubec nevi, ze druhy spoliha na to, ze tam ukazatel neni.

A ani o dva tymy nemusi jit. Muzu to klidne psat sam a po trech letech uz si vubec nepamatuju, ze jsem na to, ze v B zadny ukazatel neni, spolihal. Bezelstne ho tam pridam a najednou mi to zacne na produkci delat psi kusy, neznamo proc a jenom obcas.

Akorát už měníš “zadání”, nejdřív píšeš “není možné”, a pak “chci, aby překladač zařval”. To není totéž.
To JE totez. Pokud prekladac nezarve, tak to neni ROZUMNE, PRAKTICKY mozne. Protoze pokud ta informace neni ve zdrojaku (a opakuju: C to umi ve zdrojaku vyjadrit) a prekladac ji neumi zkontrolovat, muzu o tom, ze to jde, tak leda pindat na rootu a v praxi to porad bude u zakaznika zahadne padat. Coz neni moje definice "bezpecneho" reseni konkurentnosti.

318
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 16:45:15 »
Nic z toho není pravda, kontrolovat kompozici objektů jde a dokonce se to v částech standardní knihovny využívá. Donovan a Kernighan mají v knize “The Go programming language” příklady.
Nevím, co si představuješ pod "kontrolovat kompozici objektů". Jestli to nějaký řešení má, tak mi ho ukaž na tom příkladu.

1. Píšu jenom consumer(), producer() a main()
2. Neznám obsah B, není dokumentovaný
3. Chci, aby na mě překladač zařval, že dělám nebezpečnou věc - buď že měním něco, co měnit nemám, nebo že používám něco, co se mi pod rukama může změnit. Oboje v C udělat jde.

319
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 15:36:05 »
A proto, milé děti, nepraste a sdílejte jen immutable objekty.
To je sice dobra rada a radostne bych souhlasil, jenze imutabilita nejde v Go vynutit a dokonce ani zkontrolovat.

Takze v Go proste zadny dobry reseni nemas. Imutabilitu nevynutis, ze struct neobsahuje (na jakekoliv urovni!) zadny pointer nezkontrolujes a jediny, co ti zustane, jsou neopodstatnena velkolepa prohlaseni, ze kanaly jsou "bezpecne a blbuvzdorne", pricemz nejsou ani jedno, protoze narozdil od Erlangu v gocku implementovali CSP ponekud nedomrle. O cemz se ale nesmi mluvit, protoze Go je dokonale ve sve jednoduchosti ;)

320
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 14:07:44 »
Takova mensi ilustrace:

https://play.golang.org/p/jjbq2b4NyI0

Kdyz si predstavim, ze obsah A a B je nedokumentovany a ja pisu jenom consumer(), asi budu hodne kroutit hlavou, co delam spatne...

321
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 13:40:51 »
A co když ten odkazovaný objekt je immutable?
Pokud je immutable, tak samozřejmě k žádnému problému nedojde. Čili úplně stejně jako v C :) S tím rozdílem, že Go neumí konstanty hlídat tak dobře jako C :) (např. const field structu)

322
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 13:11:47 »
Jak "nevhodně"? Když vytvořím objekt a pak ukazatel na něj pošlu kanálem, tak příjemce s ním může normálně pracovat a GC ho nechá na pokoji, dokud na něj existují odkazy (když je v bufferu, tak do uzavření kanálu).
No právě. Vytvořím tak shared memory úplně stejně jako v C, se všema nebezpečíma, který to v C má. Žádná větší "bezpečnost" se v takovým případě neděje. Čili "blbuvzdorný" to moc není, dají se tam velice snadno udělat stejný průsery jako v C.

323
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 09:00:54 »
Treba v GO je to pres gorutiny s prstem v nose, mechanismus channelu je z bezpecny a blbuvzdorny
S tou bezpečností ani blbuvzdornstí bych to nepřeháněl. Stačí si přes channel nevhodně poslat pointer a je na světě problém úplně stejnej jako v C. A vzhledem k tomu, že pointery na structy jsou tak nějak default... Zákeřnější varianta stejné chyby je poslat si sice kopii structu, ale nevšimnout si, že má přes pointer embeddovaný jiný struct. Moc pěkná chyba, hledat ji je čirá extáze :)

Opravdu blbuvzdornou konkurentnost má Erlang, kde chybu tohodle typu udělat z principu nejde, protože sdílet paměť mezi vlákny ("procesy") prostě nejde a basta :) I tam samozřejmě pořád zůstává možnost deadlocku.

324
Hardware / Re:Datové disky pro malý server
« kdy: 06. 12. 2020, 01:23:36 »
Ja to mám v Proxmox 6.x na ZFS na SSD. ZFS je verzia 0.8.x (aktualne 0.8.5), takže tam TRIM funguje out of the box.
Tak to je dobrý vědět a zároveň je to dobrá zpráva. Díky!

325
Hardware / Re:Datové disky pro malý server
« kdy: 05. 12. 2020, 21:49:06 »
TRIM vo Windows guestovi na Proxmoxe funguje korektne, len sa mu musí dať vedieť, že je to podporované. Takže Windows musí byť nainštalovaný na disku, ktorý je obsluhovaný buď cez virtio-scsi, alebo aspoň cez virtio-block, plus vo vlastnostiach disku povoliť discard, neublíži ani povoliť ssd emulation. Virtio-scsi funguje úplne bezproblémovo, bol pôvodne vytvorený na to, aby bolo možné robiť diery v sparse image hostovaných na NAS/SAN, takže je to dlhé roky odladené. Pri použití virtio-block treba použiť virtio drivery pre Windows z poslednej doby, bol tam relatívne nedávno opravený bug, ktorý zabraňoval použitie TRIM.

Potom v guestovi pôjde spustiť Optimize-Volume a korektne otrimuje voľné miesto.
To je první část problému - hostovaný FS TRIM pošle. Druhá část je to, že TRIM musí být správně zpracovaný hostujícím filesystémem. A to, alespoň v PVE 5.x, podle mně dostupných informací, nefungovalo. V 6ce to zatím vyzkoušené nemám, tam by to snad fungovat mohlo (?)

Viz https://forum.proxmox.com/threads/trim-ssds.46398/#post-294307

EDIT: P.S. A ještě třetí část příbehu by byla, kdyby bylo hostující ZFS na SSD, tak aby TRIM probublal až do železa. Ale to je mimo téma.

326
Hardware / Re:Datové disky pro malý server
« kdy: 05. 12. 2020, 08:57:20 »
Na SATA karty, natoz USB prevodniky se vyprdni, neziskas tim nic krome potencialnich problemu. ZFS je skvele prave v tom, ze si muzes vytvaret libovolne mnozstvi oddelenych filesystemu, ktere sdili jednu dostupnou fyzickou kapacitu - nemusis porad resit nejake nafukovani/smrstovani jako u LVM. Pouzivej to, co mas dobre k dispozici, nevymyslej komplikace.

PVE standardne na data virtualu a kontejneru pouziva FS rpool/data, takze kdyz si vytvoris rpool/data2, muzes si tam ukladat data a vytvaret dalsi filesystemy dle libosti a nic neriskujes, naopak - lip vyuzijes dostupne prostredky. A pokud bys nekdy v budoucnu chtel data nekam prelit, udelas to jednim prikazem "zfs send -R rpool/data2 | zfs receive -F -d ...".

Dalsi vyhoda, kterou ziskas, je, ze si do toho usetreneho NVMe portu muzes dat male rychle SSD na ZIL/L2ARC a budes z nej tezit pro system, virtualy i ty svoje pokusny data.

neviem vsak ci je dobre riesenie postavit freenas nad KVM
Na domaci chroustani je to asi celkem jedno, ale obecne plati, ze je vzdycky lepsi mit vsechno v kontejneru, pokud neni vazny duvod mit VM.

Do virtualu si jako disk predas ZVOL, nad kterym si FreeNAS vytvori dalsi vlastni zpool a prida ti tam timpadem dalsi zbytecnou vrstvu indirekce, bude zrat RAMku na cachovani atd.

Co je horsi, ZFS je CoW a PVE jeste nedavno[1] neumelo z virtualu predavat spravne do hostujiciho zpoolu TRIM, takze v tomhle setupu by ti misto zabrane na hostujicim poolu utesene rostlo dokud nezaplni celou kvotu. Smazani dat ve virtualu nepomuze, musis rucne do volneho mista zapsat nuly, coz je opruz.

[1] Jak je to uplne aktualne ted presne nevim, ale myslim, ze se na tom zatim nic nezmenilo.

327
Odkladiště / Re:Seriály o IT
« kdy: 19. 08. 2020, 10:21:01 »
Během jednoho dílu tam padlo dvacekrát slovo BIOS, při reverzním inženýringu si při čtení napětí na čipech vzali místo debilního multimetru osciloskop (jakože ok, just why?..) a jejich dump instrukcí z eeprom vypadal, že vydá na knihu velikosti dvou telefonních seznamů. Ale asi jsem jen hnidopich :D
https://www.eevblog.com/forum/chat/halt-and-catch-fire/msg455441/#msg455441 :)

328
Software / Re:Hrátky s textem
« kdy: 17. 08. 2020, 01:13:43 »
Což v tomhle případě nehraje žádnou roli, protože nejprimitivnější regex udělá přesně to co má.
Kód: [Vybrat]
sed 's/;.*;/;;/'
Pěkně! :thumbsup:

329
Software / Re:Hrátky s textem
« kdy: 16. 08. 2020, 15:39:16 »
Mirek Prýmek: Nikde jsem napsal co je nebo není středník.
???

mezi dvěma slovy/stríngy/znaky (v našem případě znak středník z obou stran)
----

Pokud tam misto "jmeno" chces "bambule", tak si tam v tom vyrazu napises "bambule". Jestli misto stredniku chces zavinac, tak si tam napises zavinac. Nechapu pointu tve vyhrady.

330
Software / Re:Hrátky s textem
« kdy: 16. 08. 2020, 09:47:12 »
Nebo sedem:

sed 's/^\(jmeno:[^;]*;\).*\(;prijmeni:.*\)$/\1\2/'

Omezení:
  • oddělovač (středník) je znak, ne string
  • string ";prijmeni:" se nesmí vyskytovat v balastu

Stran: 1 ... 20 21 [22] 23 24 ... 618