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

Stran: 1 ... 18 19 [20] 21 22 ... 133
286
Vývoj / Re:Investor pro C++ IDE
« kdy: 13. 09. 2021, 11:40:24 »
Já ho třeba používám protože implementace Amulet (https://amulet.works/) je podobná Haskellu, umí nějaké ty zajímavé featury a kompiluje mi to do Lui. Žádná další zvláštní motivace v tom není.
Kompilace do Luy? Proč? Zrovna Lua mi pro tenhle účel přijde extrémně nevhodná. A s dokumentací na stránkách toho jazyka je to takové nijaké.
Asi nerozumím tvému příspěvku. Extrémně nevhodná na co?


Ale to není úplně Ocaml, ne?
Ne? Já bych řekl že jo. Ale i kdybych se mýlil, tak co?  :)

287
Vývoj / Re:Investor pro C++ IDE
« kdy: 12. 09. 2021, 23:10:58 »
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)

Můžu se zeptat, proč? Koukal jsem, že se v něm dělaly nějaké kryptoprojekty (Tezos) a nějaké finanční systémy, ale co je na něm tak super?
Já ho třeba používám protože implementace Amulet (https://amulet.works/) je podobná Haskellu, umí nějaké ty zajímavé featury a kompiluje mi to do Lui. Žádná další zvláštní motivace v tom není.

288
Vývoj / Re:Investor pro C++ IDE
« kdy: 12. 09. 2021, 21:48:17 »
Pointa je v tom, že Rust se svým počítáním referencí může být pohodlnější než ledasjaký jazyk s GC.
V čem je RC pohodlnější? Má hodně výhod, ale zrovna pohodlnost se k nim většinou neřadí.

Nejsem BoneFlute, ale on přece netvrdí, že RC je pohodlnější. Jenom to, že konkrétní jazyk s RC se může někomu jevit jako příjemnější nástroj, než jiný jazyk s GC. Původní příspěvek totiž zaváněl manipulací - proč nepoužít jazyk s GC, když to jde...

Díky, sám bych se neobhájil lépe  :)

Mě Rust rozsekal v okamžiku, kdy jsem viděl nějaký kód, který byl schopen vytvořit program bez závislosti na libc. Tehdá jsem prozřel.

Rust, dle mého chápání, je skvělý jazyk na nízkoúrovňové programování. Takové ty mikročipy etc. Což znamená, že uvažuješ nějakým způsobem, počítáš každý bajt, etc. Začít tam cpát GC je poněkud nepohodlné, zatímco Rc a spol jsou přirozené. (Říká se, že první věc, kterou si vývojář pro mikročipy naprogramuje je vlastní správu paměti  ;D )

Pak máš složitější/větší/komplexnější aplikace - opět se bavíme o aplikaci, na kterou by si normálně použil C/C++. A tam buď potřebuješ výkon a rychlost (takže GC asi padá, navíc už to máš v ruce, když ten Rust tam chceš použít), a nebo změníš komplet jazyk na něco jako Java, Python, C#. A tam motivace pro změnu jazyka asi fakt nebude GC v první řadě.

Hodně mě zaujalo Go. Tam díky brutální escape-analýze se GC skoro nedostane ke slovu. To mi přišlo dost dobré.

BoneFlute: Ale neodpověděls na otázku. Dokáže tě (jako tebe, BoneFlute) uživit Rust?

Já jen aby to nebylo tak, že tu něco sice opěvuješ, ale v práci stejně boucháš něco jiného :) Takových teoretiků je tu hodně.
Ano, dokáže mě uživit.
Ne, neživí mě. Nedělám v něm. Dokonce nedělám ani v C. Živí mě mišmaš všelijakých technologií a jazyků.
A na soukromé programování mám Haskell, OCaml, a Luu.
(Aktuálně)

289
Vývoj / Re:Investor pro C++ IDE
« kdy: 12. 09. 2021, 15:56:05 »
Rust ma oblasti pouziti, ale cpat ho vsude je jen honeni ega
Kdo ho cpe všude?


kdyz GC vylozene neprekazi, neni duvot nepouzit jednodussi jazyk s GC
Pointa je v tom, že Rust se svým počítáním referencí může být pohodlnější než ledasjaký jazyk s GC.

290
Vývoj / Re:Investor pro C++ IDE
« kdy: 11. 09. 2021, 18:09:58 »
BTW: BoneFlute - a vyděláváš si Rustem? Mi se třeba Rust líbí, ale práci mám v C++ - díky zkušenostem moje hodnota na trhu práce roste velmi rychle. I kdyby byl C++ mrtvý jazyk, tak je mi to vlastně jedno, protože je v tom napsané všechno a já se nebojím o to, že by najednou nebyl zájem o programátory :) Hodně lidí zmiňuje různé jazyky a jaká je to budoucnost, ale když se člověk podívá na trh práce, tak tam nejsou :)
Já ti to samozřejmě přeju. Pokud máš práci v C++, a baví tě to, tak v tom určitě není problém. Určitě bude ještě dlouhé desetiletí po něm poptávka, stejně jako po cobolu, javě, fortranu, a dalších.
Nové jazyky vznikají proto, aby usnadnili práci vývojářům a zvýšila se kvalita software. Proto třeba Rustu predikuju budoucnost.
Poptávka po něm je a IMHO se bude zvyšovat. To, že není tak velká jako po C/C++ je jen otázka času. Vždyť je to mlaďoch, vznikl v roce 2009.

291
Vývoj / Re:MariaDB - synchronizace DB schématu test/prod
« kdy: 11. 09. 2021, 00:09:01 »
A k tomu ako sa vyhnut problemu ze modifikujete schemu cez pma: zakazat uzivatelovi pod ktorym mate pma vsetky DDL...

Používám prográmek, který spočítá checksum schematu, a pokud nesedí, tak odmítne aktualizovat. Příkazem diff mi ukáže co se změnilo a mohu uvést do původního stavu. Tím je zajištěno, že nebudu ničit databázi. Kontrolu provádí externí nástroj, takže nemusím nijak přizpůsobovat schema tomu verzování.

Pre take to domace bastlenie to staci. Aj v mensom teame je to vsak peklo. Ak sa budete chciet vyhnut koliziam s kolegami, tak sa udifujete k smrti. A ak budete chciet nasadit nejaku formu CI, tak sa bez tych migracii nezaobidete, budete ich musiet napisat dodatocne. Dalsia vyhoda je modularizacia. Kazdy modul moze mat vlastnu sadu migracii, nasadia sa len tie z pouzitych modulov.
Ve skutečnosti nemáš pravdu. Je to nasazené na celkem rozsáhlých projektech, od dvou, do šesti lidí. CI samozřejmě taky. Automatizace je moje druhé jméno.

Naviac vyspelejsie databazy ako mysql uzatvaraju do transakcie aj DDL, nie len DML. Cize ak uzavriete migraciu do transakcie, tak pri chybe v migracii dojde na rollback a db mate v povodnom stave. Nemusite potom bud obnovovat db zo zalohy, alebo este horsie nemusite riesit rozbitu produkcnu db.
Já vím.

To ci prejdu niektore dotazy (namatkou alter stplca, vytvorenie cudzieho kluca a podobne) vam nezaruci ze budete mat rovnaku strukturu, dost to zavisi aj na tom ake data su v tej db ulozene. Cize pri rovnakej strukture na teste aj na produkcii, vam script moze zbehnut bez problemov na test db, ale pri produkcnej vam to moze rachnut kdekolvek v tom scripte a mate veselo.
Je to tak jak říkáš. A?

Snažíš se narvat do otevřených dveří. Ten "script", o kterém mluvím je v tvojí řeči právě ty migrace. Jen to není svázáno s ORMkem, což je motivace proč ho upřednostňuju.

292
Vývoj / Re:Investor pro C++ IDE
« kdy: 10. 09. 2021, 22:35:38 »
C/C++ je imho mrtvá záležitost.
A co je teda in?
Na nízkoúrovňové záležitosti Rust. Na ostatní věci cokoliv jiného.

Abyste mě neobviňovali z ignorance - já jsem na C vyrůstal. Umím ho používat, něco jsem v něm napsal, je to jazyk, který ve své době spasil svět. Ale taky je to hnusná mrcha, která vůbec nepomáhá a při sebemenším zaváhání či ztrátě pozornosti se ti vysměje do obličeje s ironickým core-dump.

293
Vývoj / Re:Investor pro C++ IDE
« kdy: 10. 09. 2021, 22:15:45 »
C/C++ je imho mrtvá záležitost.

Desktopovku v tom nebudeš vyvíjet, ale řeknu ti, jak prasím aplikace pro ESP a podobný.
Nejprve si otevřu okna prohlížeče v hojném počtu a pak v každém z nich hledám návod, jak zrovna kdo komunikuje s SPI. Najebu to do nějakého prototypu třeba v Micropythonu.
Otevřu si další milion oken a dívám se, jak se stejná věc dělá třeba v čistém C.
Tj. to IDE by kombinovalo dva jazyky, jeden na prototypování a druhý "na finální práci".

Kdysi, je to už drahně let, jsem si hrál s projektem "vizuálního programování", prostě drag&drop prvků.
(Něco jako umisťování ovládacích prvků do formuláře a jejich propojení "mašličkou".)
Tak to pojďme spojit.

Otevřu si nový projekt, načtu si definiční soubor pro ESP, drag&drop si přetáhnu PIN 1 do kódu editoru a MicroPythonem ho nastavím. Paralelně se mi v Cčkovém kódu (někde na pozadí) objevil vzorek kódu (v C/C++), který tu samou věc dělá v Cčku. Jasně, můj Micropython by to do Cčkového programu zkopírovalo zakomentovaný, ale to nevadí (Funguje jen jako kostra).

Párkrát klikneš na PIN, vybereš funkci a místo toho, abys měli milion oken na googlování, ti to ukáže ukázky kódu, které někdo jiný už takhle naprasil. 

Než se objevil github a podobný vyfikundace, všechno se dělalo dřevně. Proč by nemohlo být IDE napojené na vlastní jako-Github, kam bys vkládat vlastní segmenty kódu, který v různých projektech používáš? Neplatící uživatel by svoje části kódu sdílel s ostatními, členství třeba za $24.

Rozumím a souhlasím. Měl bych následující poznámky:
1/ Nemůže ti nabízet fragmenty v C, protože to bude matoucí a IMHO to nebudeš dělat (soudím od stolu, máš-li z reálu jiné zkušenost, beru zpět). Třeba já používám na některé své projekty OCaml-like jazyk kvůli typům, které se mi na pozadí překládají do lua kódu. Někdy se do toho lua kodu podívám, ale ne moc často.
2/ Takové fragmenty budou snadno rozbitelné. Takže se postupným zohledňováním dostaneš ke knihovnám. V souvislosti k bodu 1/ nebudeš vůbec nabízet C, ale prostě to tam frkneš na pozadí a basta. Postupným zohledňováním se dostaneš k něčemu takovém jako je VCL/CLX.
3/ Domnívám se, že strategie nafrkat butonky a pak to provázat (aka Delphi, VisualStudio, XCode) je nešťastné. Mnohem vhodnější mi přijde strategie vytvořit datový model, a nechat si butonky generovat (aka Zope/Django). Sám mám v tomto duchu načrtnutý nějaký projekt, ale známe se.
4/ Že by si používal existující fragmenty kódu - to by si nejdřív musel naučit stroj, aby těm fragmentům kódu rozuměl - pokud by si to chtěl extrahovat. Nebo by si musel přimět vývojáře, aby tyto fragmenty poskytovali vhodně kategorizovaný. Obojím jsem si prošel a nevidím to optimisticky.

294
Vývoj / Re:MariaDB - synchronizace DB schématu test/prod
« kdy: 10. 09. 2021, 00:45:21 »
A k tomu ako sa vyhnut problemu ze modifikujete schemu cez pma: zakazat uzivatelovi pod ktorym mate pma vsetky DDL...

Používám prográmek, který spočítá checksum schematu, a pokud nesedí, tak odmítne aktualizovat. Příkazem diff mi ukáže co se změnilo a mohu uvést do původního stavu. Tím je zajištěno, že nebudu ničit databázi. Kontrolu provádí externí nástroj, takže nemusím nijak přizpůsobovat schema tomu verzování.

295
Vývoj / Re:Investor pro C++ IDE
« kdy: 10. 09. 2021, 00:41:06 »
Slyšeli jste o věcech jako:
- robot Karel (http://karel.oldium.net/)
- projekt Lazarus (https://cs.wikipedia.org/wiki/Lazarus)
- Mathlab (https://www.pnopava.cz/)

Představa, že udělám kulervoucí náhradu VisualStudia v týmu tří lidí je možná směšná, možná šílená, možná nainvní.

Ale třeba nějaké IDE pro školy by se chytit mohlo.
Navíc, do budoucna bude potřeba programátorů víc a víc.
Stejně tak by se mohlo chytit AI programování / vizuální programování, kdy nepotřebujete umět programovat.


Dám vám soudruzi kontrolní otázku, v čem v roce 2005 programovalo na světě nejvíc lidí? V Excelu vole...

Udělat vizuální IDE pro datové transformace, které vezme data ze schránky, provede jejich transformaci a pak je vyzvrací do SAP/Excelu/Účetnictví... Každý den spousta účetních jen přebouchává data z tabulek do účetních programů, importy jdou pomalu. Spousta vocasů přebouchává data z webových stránek do eshopů....to by se dalo krásně transformovat.

Takže, ano, pro nějaký super projekt by to IDE mělo význam.
Naprostej souhlas.
Mě přijde, že se ten vývoj furt točí v kruhu, ve spirále. V sestupný.


A co IDE pro Cčko?
Jasně, je pro to obrovský a nikým nepolíbený trh.
Jenže to nesmí být bžumbiliontá kopie PSpadu.
C/C++ je imho mrtvá záležitost.

296
No hlavně je zbytečné počítat hashe u souborů, které mají unikátní velikost. Proto je fdupes tak úžasně rychlý. (možná ještě velké soubory porovnává po kouscích - když se liší začátek, je zbytečné číst dál - ale to nevím)

Dobrej postřeh! +1

297
Vývoj / Re:XSLT - xpath axes uvnitř cyklu
« kdy: 22. 07. 2021, 17:31:30 »
@BoneFlute
tak verzi co jsi mi poslal už jsem zprovoznil
@Filip Jirsák
šablony určitě také zkusím, snad se k tomu dnes dostanu

všem díky!

Rádo se stalo. V čem byl problém?

298
Vývoj / Re:XSLT - xpath axes uvnitř cyklu
« kdy: 20. 07. 2021, 11:26:35 »
Pánové moc díky za Vaše rady a nápady, které jste mi poskytli.
On ten Integrační framework od SAPu je taková parní lokomotiva :) a ne všechno tam funguje standardně.
Každopádně si nejsem jist, zda mohu 'apply-templates' použít uvnitř volané template.
jj, můžeš, ale v tvém případě platí - to prostě zkus, je-li ten SAP tak nestandardní.

299
Vývoj / Re:XSLT - xpath axes uvnitř cyklu
« kdy: 18. 07. 2021, 19:30:28 »
Negeneruje to požadovaný výsledek. Nesedí Parent.
Místo zbytečných keců

Omlouvám se. Napsat to kratšeji mi už přišlo hulvátské.


...
Co říkáš, na toto řešení? Toto ti funguje?

300
Vývoj / Re:XSLT - xpath axes uvnitř cyklu
« kdy: 18. 07. 2021, 16:43:34 »
Pokud platí, že na vstupu jsou řádky správně seřazené, pak bude fungovat např. toto:

Kód: [Vybrat]
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
    <xsl:template match="/">
        <Workbook>
            <xsl:apply-templates select="ResultsSet/ResultSet[1]/Row"/>
        </Workbook>
    </xsl:template>

    <xsl:template match="/ResultsSet/ResultSet[1]/Row">
        <xsl:variable name="id" select="Parent"/>
        <Pack>
            <Type>Pallet</Type>
            <ID><xsl:value-of select="$id" /></ID>
            <Sequence><xsl:value-of select="count(preceding-sibling::Row) + count(/ResultsSet/ResultSet[2]/Row[Parent = $id][1]/preceding-sibling::Row) + 1" /></Sequence>           
        </Pack>
        <xsl:apply-templates select="/ResultsSet/ResultSet[2]/Row[Parent=$id]"/>
    </xsl:template>

    <xsl:template match="/ResultsSet/ResultSet[2]/Row">
        <xsl:variable name="current" select="."/>
        <Pack>
            <Type>Box</Type>
            <ID><xsl:value-of select="Child" /></ID>
            <Sequence><xsl:value-of select="count(preceding-sibling::Row) + count(/ResultsSet/ResultSet[1]/Row[Parent = $current/Parent]/preceding-sibling::Row) + 2" /></Sequence>           
            <Parent><xsl:value-of select="Parent" /></Parent>
        </Pack>
    </xsl:template>   
</xsl:stylesheet>

BoneFlute si může všimnout, že to není imperativní program, takže tam není žádná pojmenovaná funkce (šablona) ani žádný cyklus.

Negeneruje to požadovaný výsledek. Nesedí Parent.

Jestli chceš být užitečný, zkus se pochlubit jak se dělá to "Dá se udělat to, že výstup XSLT transformace proženete další transformací (klidně i v rámci jedné šablony)". To neumím, to mě zajímá.

Stran: 1 ... 18 19 [20] 21 22 ... 133