Keresés

Új hozzászólás Aktív témák

  • Mr Dini

    addikt

    válasz buherton #15 üzenetére

    szerintem a Decompile ablak csak annyit mond, hogy az egyes sor milyen symbolt használ. A bal oldali ablak meg "csak" annyit, hogy az fmt-ben milyen symbolok vannak.

    Igen. Itt arra voltam kíváncsi, hogy van az fmt csomag. Annak van ugye Println, Print stb metódusa. Mivel én csak a Println-t használom, felesleges lenne a fordítónak a Printet is a binárisba rakni, hiszen ezt a metódust nem hívom meg. Abban a tévhitben éltem eddig, hogy ilyen esetben is belekerül a teljes fmt csomag a binárisba. De a screenshoton az látszik bal oldalt, hogy a végleges bináris az fmt-ről annyit tud, amennyi szükséges neki. Nincs pl. Print benne. A jobb oldal lényegtelen, az csak kontextusként szerepel, hogy demonstráljam, mi történik a main()-ben. Megerősítés, hogy tényleg ez a helyzet.

    Szóval a nagy méret inkább tényleg linkelésnél jöhet be a nagy méret, meg azért a runtime sem kicsi.

    De ez pozitív a Go oldalról, nem tudtam.

    A videót meg köszi. Jó áttekintés volt.

    emacs vs vim: Én is azért kezdtem vimet használni, mert erről hallottam korábban és be is vált. Egész megszoktam a szkriptelését is. Illetve a kiosztása is kézre áll. Ettől függetlenül nem zárkózom el az új dolgoktól, szóval adok neki majd mindenképp egy esélyt, csak ehhez kell egy kis szabadidő. :)

    [ Szerkesztve ]

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • Mr Dini

    addikt

    válasz buherton #12 üzenetére

    Hogy őszinte legyek, egész jól bánik már az erőforrásokkal, persze sosem fog labdába rúgni az említett szerkesztők mellett memory footprint szempontjából. Egyébként én a VsCode-ot a neovim kiegészítővel használom. Két dologért szeretem nagyon ezt a setupot. Az egyik az a Markdown preview extension, amivel le tudom osztani a képernyőt egyrészt a szerkesztett nyers fájlra, illetve a másik oldalt kapok egy előnézetet, ami szinkronizálva van a szerkesztői oldallal.

    A másik meg a container integráció. Baromi hasznos C# fejlesztésnél a Containers extensionjük, mivel ilyenkor felhúz automatikusan egy dev containert nekem, majd valami HTTP API-n keresztül kommunikál a Code-dal és rendesen lehet breakpointokat berakni, látni, hogy éppen mi volt a változók értéke stb. Nyilván vimmel is meg lehetne csinálni azt, hogy konténerben fejlesztek, de ez így nekem nagyon kényelmes. C# ugyanis hajlamos a szemetelésre és jó érzés egy-egy projekt után kitörölni mindent (a kódot kivéve) egy paranccsal. :)

    emacs egy ideje bakancslistás, ha oda jutok nagyon szeretném jobban megtanulni.

    Szerintem bold claim a részedről, hogy nem tartod magad programozónak. A megnyilvánulásaid alapján nekem az jön le, hogy mélyebben tisztában vagy a dolgok mikéntjével és a 10 év sem a tegnap kezdtem kategória. :R

    Ja meg én elvagyok a Pythonnal is. Ha HTTP kérést kell manipulálni, vagy kell valami párszor használatos dirty szkript, arra teljesen jó. Prod. szoftvert nem szeretnék benne már írni.

    [ Szerkesztve ]

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • Mr Dini

    addikt

    válasz buherton #11 üzenetére

    Húú, na pontosan ezekért az elképesztő hasznos szakmai kommentekért, illetve pl. a lajosdani2 féle élménybeszámolók miatt éri meg vezetni ezt a blogot. Köszönöm a meglátásokat!

    Én nem szeretem a Go-t, hogy őszinte legyek, bár piszok kényelmes. De lehet azért, mert rustról váltottam vissza, ami elég erősen kikényszeríti a programozótól, hogy szép kódot írjon. Nem rossz amúgy, de kb az a kód le is fog fordulni, amire nem panaszkodik az IDE. Találkoztam egyszer egy érdekes problémával, hogy adott volt egy Go backend. Ez egy websocketet nyitott a kliensek felé és eventeket küldött, majd kapott válaszokat a kliensektől. Ha sok kliens volt, egyszer csak pánikolt. Pedig látszólag mindenhol rendesen figyeltem a lock-ra. Később rájöttem, hogy maga a library volt a hibás, mivel a pingek küldésnél elfelejtettek lockolni és ha pont akkor olvastam a streamről, mint amikor ezek pingeltek, akkor meghalt a processz. Újraírtam rustban, ami le se engedte fordítani úgy a kódot, hogy nem lockoltam valamit. És még ki is oktatott informatívan, hogy ez meg ez nem jó és nesze, old meg így. Az lehet, hogy több effort volt a végén a kód és sokkal hosszabb lett, mint a Go megoldás, de a nem létező mérnöki szememmel sokkal precízebb lett a végeredmény.

    Lehet ez egy senior Go devnek nem hátrány, hiszen ő már eleve gondol mindenre is, de én ettől sajnos messze vagyok.

    sync.Map-et meg ismerem és használtam is máskor. Csak ez is egy extra faktor, amire figyelni kell.

    A C++t én sem szeretem, de úgy általában az OOP nyelveket sem igazán. Egy két valid use-case-t tudok elképzelni, amúgy szerintem a funkcionális nyelveknél nincs gyorsabb. :U Az lehet, hogy áttekinthetőbb, meg a polimorfizmusnak köszönhetően könnyebb kiegészíteni, így pikk-pakk lehet vele haladni, de nem feltétlen lesz az optimális. Meg sokszor jár vele a tömény absztrakció is, ami szerintem egy szint után már felesleges overhead. Egyetemen nálunk nagyon nyomják a C#-ot, de C és társai sosem voltak terítéken. Az OOP-ra esküsznek. De ezzel most egy háborút fogok elindítani. :B Nem akarok persze senkinek a lelkébe gázolni.

    Az alábbi kód maximum a szerencsének köszönhetően menti el a fájlt.

    Köszönöm az észrevételt, teljesen jogos! Bevallom, a kész kódból másoltam ki részleteket és a saveImage alatt bőven van blocking call, ami miatt nem fog kilépni a program, csak a copy-pastenél azt pont nem írtam át. A példa kedvéért most kiszedtem a go kulcsszót.

    A linkelésről pedig. Úgy néz ki én tudtam rosszul, vagy azóta változtak a dolgok. Lefordítottam az alábbi kódot:

    package main

    import "fmt"

    func main() {
    fmt.Println("Hello, World!")
    }

    Az volt az elvárásom, hogy az fmt egyetlen függvénye miatt bekerül a binárisba az fmt összes szimbóluma. A szemléltetés kedvéért nem strippeltem a kész binárist. Ghidrában megtekintve az eredményt, jól látható, hogy rosszul tudtam:

    Általában mindennek utánanézek, amikor állítok valamit, de úgy néz ki, itt hibáztam. A cikket majd frissítem egy update formájában, hogy I stand corrected és nem is olyan vészes a helyzet. Köszönöm!

    A linker meg... Az világos, hogy statikus ELF fájl lesz például linuxon. De itt most a Hello World kedvéért simán elegendőnek kéne legyen egy libc linking. Rusttal megcsinálod ugyanezt egy musl toolchainnel buildelve és kapsz egy pár száz KiB-os optimalizált, teljesen static binary-t. Macerásabb, mint Go-t buildelni, de ég és föld a végeredménybeli különbség.

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • Mr Dini

    addikt

    válasz lajosdani2 #7 üzenetére

    Hát, én is jót szórakoztam. Nem gondoltam volna, hogy ilyesmi le tud kötni, mert sosem érdekeltek a játékok. De amikor algoritmust kell a mozgásra írni, az tényleg nagy sikerélménnyel tud eltölteni. :)

    LEGO robotnál gondolom azért limitáltabb a számolási kapacítás. Ott milyen módon írtatok AI-t? Felmappeltétek, hogy hol járt már, aztán arra nem ment többet és próbálkozott?

    Meg írod, hogy egész napos volt. Hány óra volt rá?

    Mondjuk nem tudom mit csinálnék, ha még szenzorokra is kellene figyelnem... :DDD

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • Mr Dini

    addikt

    válasz ergoGnomik #3 üzenetére

    Olyan gyors, hogy kétszer 180-at is fordul. Kösz, javítottam. :B

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • Mr Dini

    addikt

    Akkor ezt most megnyitom... :)

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

Új hozzászólás Aktív témák