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 - registrovany_ava

Stran: 1 2 3 [4] 5 6 ... 12
46
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 18. 11. 2021, 09:38:16 »
K tomu navrhu cez Lazy Init, super napad, rovno to pouzijem, uvazoval som ale nic lepsie ma prakticky na momentalne sksuenosti nenapada.
Jde to elegantněji přes get_or_insert.

HashSet::get_or_insert je nightly, a stejně nevím jak by se to na to dalo použít. Šlo by použít get_or_insert_with, a tu closure na počítání hodnoty k vložení do HashSety zneužít k inicializaci tabulky takhle: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d221825d869185554b7077d109a55157 , ale jestli je to elegantnější, to je s otazníkem. Je fakt, že to možná bude o trochu rychlejší, odpadne duplicitní lookup, ale možná že by to optimalizátor v té první verzi eliminoval.

Kdybych nechtěl používat nightly a chtěl to takhle v jednom kroku, dala by se místo HashSet použít HashMap<TypeId, ()> a entry api HashMap-y, za cenu jistého zamlžení sémantiky (premature optimization is the root of all evil, že).

K tomu pro zajímavost - přesně takhle je v rustu implementovaná HashSet - když to zjednoduším, je to obal nad HashMapou s unit hodnotama, mírně zjednodušeno

pub struct HashSet<T> {
    map: HashMap<T, ()>,
}

impl<T> HashSet<T> {
    pub fn contains<Q>(&self, value: &Q) -> bool
    {
        self.map.contains_key(value)
    }

 // atp...
}

Přijde mi naprosto úžasný, že takhle definovaná HashSeta je optimálně rychlá, nemusí se znovu nic reimplementovat, unit hodnoty vnitřní hashmapy se vyoptimalizují pryč.




47
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 18. 11. 2021, 09:14:09 »
Zrovna TypeId je stejně haram jako Any.

Jo, já osobně TypeId taky zatím nikdy nepoužil, ale pro tohle zadání mi to přišlo jako elegantní jednoduchý řešení .. alespoň jsem nepřišel na lepší, napadá tě něco?

48
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 17. 11. 2021, 16:33:27 »
Devirtualizovat to asi vždy půjde jen omezeně
To dá rozum, když je to heuristická optimalizace. ...Každopádně až v Rustu bude, enumy už nebudou mít výhodu rychlosti.

Spíš bych řekl, že "až v Rustu bude, enumy v některých případech už nebudou mít výhodu rychlosti, nebo bude rozdíl v rychlosti menší".

49
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 17. 11. 2021, 16:28:27 »

Debilní root fórum systém, psal jsem se s tím asi půl hodiny, mezitím mě to odhlásilo a příspěvek nenávratně zmizel. Tak ještě jednou v rychlosti:

push<T: DatabaseBuilder> - dobrý.

Chtělo by to trochu učesat:

Nelíbí se mi ty Optiony v push, create_table, a možná i v Database, myslím že by bylo lepší je zrušit. Navíc bych čekal, že budou brát &mut self.

Kdyby ses chtěl zbavit těch DatabaseMembers, který jsou opravdu podivný, mohla by se třeba udělat lazy inicializace tabulek přímo v Database, např. něco jako (nevím jestli půjde přeložit)

pub struct Database {
    initialized_tables: HashSet<TypeId>,
    c: Connection,
}

impl Database {
    fn init_table<T: DatabaseBuilder + 'static>(&mut self) {
        let type_id = TypeId::of::<T>();
        if !self.initialized_tables.contains(&type_id) {
            T::create_table(&self.c);
            self.initialized_tables.insert(type_id);
        }
    }

    pub fn push<T: DatabaseBuilder + 'static>(&mut self, data: &T) {
        self.init_table::<T>();
        data.push(&self.conn)
    }
}

50
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 17. 11. 2021, 16:05:24 »
fn push<T:B>(&mut self, data:T)
Ano, k tomuto som sa rovnako dopracoval +- ked ste to postol.
Jo, tohle je standard (nejen) v Rustu. Součtové typy (rustí enum) můžou být rychlejší (překladač Rustu traity evidentně nedevirtualizuje).

Když použiješ traitu jako typový parametr funkce (fn f<T>(t: T)...), překladač ji pro konkrétní typ "monomorfizuje", tj. přeloží specializovanou verzi přímo tomu typu na míru. To se výkonově těžko dá překonat.

Když použiješ traitu jako trait object (Box<dyn T>, nebo &dyn T, které naházíš třeba do Vec, abys mohl mít "heterogenní" kolekci), dostaneš fat pointer - vtable+data. Volání se děje dispatchem přes tu vtable. Devirtualizovat to asi vždy půjde jen omezeně, v principu může být těch implementací (tj. různých vtablů) spousta.

Když použiješ enum, je to obyčejný datový typ, tj. žádný fat pointer, na konkrétní variantě matchuješ, a když je těch variant málo, je vcelku zjevný, že to matchování se dá implementovat rychleji (jedním dvěma ify, což pak může spekulativní provádění instrukcí vykonat prakticky hned), než dereference přes vtable (i když samozřejmě když pak v kolekci bude třeba jeden typ trait objectu výrazně převažovat, tak to díky cache a branch predikci nejspíš bude taky docela odsejpat, ale i tak je to alespoň dvakrát tolik dat než jednoduchý enum).

V praxi se samozřejmě člověk mezi enumem a trait objectem rozhoduje nejvíc podle toho, jestli jde o uzavřený nebo otevřený typ.

51
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 16. 11. 2021, 11:58:34 »
...A enumy jsou taky dynamické (... interní implementace je stejným dynamickým mechanismem jako traity)...

Už jsme asi dosti offtopic, ale toto IMHO není pravda. Pro zajímavost: https://docs.rs/enum_dispatch/0.3.7/enum_dispatch/

52
Vývoj / Re:Rust - std::ANY alebo lepší návrh?
« kdy: 16. 11. 2021, 10:16:30 »
Jak píše Idris, asi základní otázka v tvém případě je, jestli push opravdu musí umět zpracovávat Any (tj. za překladu neznáš typ pushovaných dat), nebo jestli ten typ za překladu znáš, a chceš jen, aby push bylo generické a umělo pracovat s různými typy dat.

Pokud typ za překladu znáš (a pokud je to jen trochu možné, snažil bych se to tím směrem tlačit), půjde se nějak odpíchnout od Idrisova nástřelu, když napíšeš víc, napíšeme víc i my.

Pokud ne, asi skutečně nezbude než dělat nějaký dynamic dispatch přes např. Any. I v takovém případě bych se ovšem spíš snažil případná neznámá data co nejdřív převést na nějaký konkrétní typ a udělat push generické s trait boundem a bez Any.

53
Sítě / Náhodné výpadky připojení k internetu
« kdy: 10. 11. 2021, 15:33:42 »
Na vesnici nám (spíš obydlené zatáčce) internet vetšinou jede normálně (cca 20MBit download, to mi stačí), ale občas se zasekne, strašně se zpomalí, nebo nejede vůbec, po pár vteřinách, minutách, občas desítkách minut se zas rozjede normálně.

Jsem připojen přes wifi anténu poskytovatele ke stodole o pár baráků dál, odtamtud už to mají nějak vedené do města. Na počasí se to nezdá záviset.

Už jsem to párkrát reklamoval (regionální tlapnet), ale vždycky se to vrátí do starých kolejí. Sousedovi to dělá taky. Vzhledem k tomu, jak je to občasné, tak se to blbě prokazuje, ale samozřejmě to otráví když je člověk třeba zrovna na nějakém meetingu nebo tak. Nepřipomíná to někomu znalejšímu nějaký typický problém, popř. co s tím?

54
Vývoj / Re:Tutorial pro Scalu pro programatora
« kdy: 07. 10. 2021, 08:31:20 »
Já byl v podobné situaci před několika lety. Jestli neznáš funkcionální jazyky, ten skok bude docela velký a nějaký tutorial na pár dní tě nezachrání. Doporučuju plnohodnotnou knížku, buď přímo https://www.artima.com/shop/programming_in_scala_5ed (ze staršího vydání jsem se učil já, a je super na vysvětlení co, jak a hlavně proč), nebo https://www.handsonscala.com/ - to tehdy ještě neexistovalo, ale bude to asi praktičtější, přístupnější, Li Haoyi umí velmi srozumitelně a prakticky vysvětlovat, za investované peníze to bude jednoznačně stát.

Další otázka je kterou scalu se učit - dvojku, nebo dotty? Je v nich dost rozdílů, dvojka je starší ale rozšířenější.

A možná taky důležitá otázka je jestli se vůbec scalu učit. Kdybych chtěl praktický managovaný jazyk, šel bych spíš do Kotlinu, je jednodušší a má podle mě větší budoucnost. Kdybych se chtěl funkcionálně vzdělat, šel bych do Haskellu nebo F#. A nebo bych šel prostě do Rustu :-)

56
(offtopic): Klávesnice je naštěstí taky řešitelná, https://agateau.com/2013/remapping-keyboard-keys-on-lenovo-laptops/

57
Díky všem. Nakonec jsem nainstaloval nový systém vedle stávajících Windows která jsem gparted-em zmenšil, rsync-nul home, a podle potřeby doinstalovával pomocí apt-get. Teoreticky to bylo snadné, v praxi spousta potíží - netinstall flashka nebootovala v EFI módu když jsem ji vytvořil pomocí dd, po spoustě zkoušení jsem musel použít rufus, ovladače síťovky nebyly na standardním netinstall cd, tak jsem musel znovu s -nonfree, protože ani když jsem ten ovladač přiložil na dalším médiu tak ho Debian nenašel, po instalaci a rebootu se zapomělo síťové nastavení - přenášení networkmanageru po flashce, stejně síťovka nefungovala - rfkill po flashce, nenainstaloval se bootloader, protože Debian neviděl na EFI variables (i když bylo bootováno v EFI režimu) - nakonec jsem musel konfigurovat z Windows pomocí bcdedit, a nainstaloval jsem refind. Zkrátka celý den v tahu, a kdybych tam neměl ty Windows a vedle další počítač s Linuxem, asi bych to v životě nedodělal.

Ale mám to za sebou, a jsem s notebookem (aspoň teda na idiotské rozvržení kláves na klávesnici, např klávesa "Kontextové menu" vpravo od mezerníku, kterou jsem si docela oblíbil, je nahrazená Printscreenem, proboha proč?) spokojený.

58
Záhada plastového konektoru vyřešena - on to nebyl opravdový disk, ale jen takový plastový obdélníček co vyplňuje místo, kam se může dát druhý disk. Opravdový první disk je taková destička kousek vedle, velká asi palec čtvereční, miniaturizace je úžasná.

Dík za tip na clonezillu, zamyslím se nad tím.

59
Předestírám, že jsem HW diletant, takže budu asi klást naprosto pitomé otázky.

Mám starší workstation, a teď jsem si pořídil "nový notebook z druhé ruky", Lenovo edge 495. V workstation mám asi třetím rokem SSD disk (256 GB) s Debianem, v notebooku je 512 GB SSD s jakýmisi Windows. Mým cílem je dostat, ideálně jako byte copy, to co mám ve workstation, na ten notebook, abych tam nabootoval to samé a mohl pracovat a hotovo. Počítám s tím, že bych si potom v parted-u jen zvětšil nebo přidal partition z těch zbývajících 256 GB.

Už jsem to jednou nebo třikrát dělal, stylem vyndat disk z notebooku, vrazit do workstation, "dd if= of=", přehodit zpátky, víceméně hotovo. Ale tady mi workstation disk z notebooku vůbec nevidí, ani BIOS, ani Linux. Kabely štymují (tj. i napájecí, i datový kabel jdou zapojit, a to ještě jen jedním způsobem), ale co mě zaráží je, že na konektoru disku nevidím vůbec nic kovového, jen takový plastový lehounký vroubky. Ale v notebooku disk funguje, a to i po opětovném vrácení disku a spuštění (je tam tedy na konektor jakýsi adaptér, který se strčí na straně disku do datového i napájecího konektoru zároveň, udělá se z toho tenký pásek vodičů, který pak vede do jiného konektoru v notebooku, ale to asi není relevantní). Může tento prapodivný konektor nějak souviset s tím, že workstation disk nevidí? Opět si předem sypu popel na hlavu, vývoj v oblasti SATA konektorů jsem v posledních letech absolutně nesledoval.

Co mi kdyžtak může pomoci? Je kdyžtak nějaká jiná, blbuvzdorná a rozumně rychlá cesta, jak přesunout systém z počítače s Linuxem v jednom rohu místnosti na notebook s Windows ve druhém rohu místnosti? Nejraději bych tedy stále to přesunutí disku a dd, to se mi osvědčilo jako rychlý a spolehlivý - když to tedy zrovna fungovalo.


60
Hardware / Re:Výběr klávesnice pro pracovní účely
« kdy: 03. 08. 2021, 07:45:53 »
Taky jednoznačně split, jsem dlouho let spokojený s https://www.alza.cz/microsoft-sculpt-ergonomic-desktop-wireless-cz-sk-d470115.htm?o=2 , hranatá klávesnice je pro lidi kterým rostou ruce z břicha a mají prsty jako hrábě, z hlediska používání naprosto nedává smysl.

Stran: 1 2 3 [4] 5 6 ... 12