| mrkubax10 | słyszeliście o GitHub Copliot? | 07:28 |
|---|---|---|
| mrkubax10 | w sumie to już od dawna to istnieje ale nie podoba mi się to ponieważ kradnie kod z repozytoriów (pewnie tych prywatynych też) | 07:29 |
| Ashiren | :3 https://img-comment-fun.9cache.com/media/a7wxRe/aRwKGEMX_700w_0.jpg | 07:47 |
| Voldenet | mrkubax10: github copilot nie kradnie kodu, tylko uczy się na publicznych repozytoriach githuba, a to duża różnica | 08:24 |
| Voldenet | przecież normalni programiści też wykorzystują skrawki publicznego kodu z GH, dokumentacji i SO | 08:25 |
| Voldenet | mi się nie podoba to AI-driven programming głównie z tego powodu, że to AI jest zwyczajnie tępe | 08:25 |
| mrkubax10 | tak | 08:26 |
| Voldenet | rozumienie kodu na poziomie dna | 08:26 |
| Voldenet | podobnie jak junior, który kopiuje losowy kod z GH i liczy na to, że zadziała dobrze :D | 08:27 |
| Voldenet | praktycznie ai-driven nie musi dostać problemu millenijnego żeby się wyłożyć, wystarczy coś wykraczającego poza "gettery i settery ze sprawdzaniem nulli" i już leży | 08:28 |
| mrkubax10 | hmm a to ciekawe | 08:28 |
| Voldenet | próbowałem używać czegoś podobnego w visual studio i jedyne z czym sobie radziło, to kopiowanie garści patternów z reszty projektu | 08:29 |
| mrkubax10 | nigdy sam nie sprawdzałem jak copilot działa ale z tego co widzę wiele nie straciłem | 08:30 |
| Voldenet | Nie mówię, że to zło absolutne, bo to dobre narzędzie do automatyzowania żmudnych czynności, ale nic poza tym | 08:30 |
| Voldenet | no i nawet jak już AI rozwiąże jakiś problem, to często wygląda to jak robota juniora | 08:30 |
| Voldenet | za często | 08:31 |
| Voldenet | Także AI nie za bardzo radzi sobie z feedbackiem, że zrobiło coś źle, chociaż to może/mogło zostać poprawione | 08:32 |
| mrkubax10 | może to dobrze że AI nie jest (jeszcze) zbyt rozwinięte, ponieważ jeżeli ludzie przestaną rozumieć kod napisany przez AI nie będzie dobrze | 08:33 |
| mrkubax10 | chodzi mi tu głównie o zastąpienie znacznej części programistów sztuczną inteligencją co się raczej nie stanie ale nigdy nie wiadomo | 08:34 |
| Voldenet | to kompletnie nie ten rząd rozumowania | 08:34 |
| Voldenet | obecnie ai jest na poziomie pisania czegoś, co nie rzuca syntax errorów, ale notorycznie nie ma żadnego sensu | 08:36 |
| Voldenet | pisanie inputu w języku naturalnym specjalnie po to, żeby wygenerować funkcję, bo język docelowy to czysty boilerplate, to w zasadzie jedyne sensowne zastosowanie w praktyce | 08:37 |
| mrkubax10 | w sumie to tak | 08:38 |
| Voldenet | ale język naturalny też jest mniej precyzyjny niż kod | 08:38 |
| Voldenet | więc bot musi mieć poziom rozumowania na tyle, żeby zrozumieć do czego to jest i wziąć tylko potrzebne tradeoffy | 08:39 |
| mrkubax10 | zmieniając temat, podobno Rust ma być wykorzystywany do pisania Linuksa, nie jestem pewien od której wersji | 08:40 |
| Voldenet | na razie rust to skrajny przerost formy nad treścią | 08:42 |
| Voldenet | rust ma ten problem że każda funkcja generyczna jest pesymizowana do najgorszego lifetime'u, więc struktury danych są nieźle udekorowane lifetime'ami | 08:43 |
| mrkubax10 | tak szczerze to nie mam za bardzo opinii o tym języku poza tym że niezbyt podoba mi się składnia | 08:44 |
| Voldenet | rust dba, żeby dev dostał po twarzy za błędy, ale nie kwapi się żeby je poprawić za niego | 08:44 |
| mrkubax10 | no i LLVM... | 08:45 |
| mrkubax10 | ale chyba też jest jakiś frontend dla GCC | 08:45 |
| Voldenet | po prostu imo zbyt formalny język - to może być zaleta, ale typescript podchodzi do problemów lepiej | 08:46 |
| mrkubax10 | moja tierlista nowoczesnych języków, których próbowałem wygląda tak: Go > Rust > Zig | 08:48 |
| Voldenet | tak, go jest praktyczny i z kolei bardzo nie lubi nadmiernej abstrakcji, więc trudno odwalić coś nie do utrzymania | 08:50 |
| Voldenet | a ziga nie próbowałem, to nie wiem do końca | 08:50 |
| mrkubax10 | może i lepiej | 08:51 |
| Voldenet | polecam typescript, btw | 08:51 |
| mrkubax10 | używałem | 08:51 |
| Voldenet | świetna rzecz, ktoś napisał kompilator typescripta w systemie typów typescripta | 08:51 |
| mrkubax10 | zig ma taki problem że wcięcia MUSZĄ być spacjami (znak \t jest uznawany jako błąd) w sumie nie wiem dlaczego | 08:52 |
| jacekowski | taby > spacje | 08:52 |
| mrkubax10 | tak | 08:52 |
| mrkubax10 | taby zajmują mniej miejsca | 08:52 |
| mrkubax10 | w sensie że jeżeli ktoś używa 4 znaków spacji vs 1 znak \t | 08:53 |
| Voldenet | taby są lepiej obsługiwane przez niewidomych | 08:53 |
| mrkubax10 | no i każdy może sobie dostosować szerokość tabulatora | 08:53 |
| Voldenet | niemniej tu obronię ziga, zgodzenie się na jeden system zapisu jest wygodny | 08:54 |
| Voldenet | bo standaryzuje kod | 08:54 |
| jacekowski | czy rust ma kompilator na arm-le | 08:54 |
| jacekowski | ale bare-metal | 08:54 |
| mrkubax10 | główny kompilator rust'a w tym momencie używa LLVM | 08:54 |
| jacekowski | czyli niby cos by sie dalo zrobic | 08:55 |
| mrkubax10 | czyli jeżeli LLVM to wspiera to pewnie tak | 08:55 |
| jacekowski | uzeram sie ostatnimi czasy z stm32f4 i kodem od ST do ethernetu | 08:55 |
| jacekowski | jakie to gowno jest zabugowane | 08:56 |
| mrkubax10 | ST? | 08:56 |
| jacekowski | https://www.st.com/ | 08:56 |
| jacekowski | producent elektroniki | 08:57 |
| jacekowski | a to co uzywam to stm32f407, arm cortex-m4, 168MHz | 08:57 |
| jacekowski | 192kB ramu | 08:57 |
| mrkubax10 | aa | 08:57 |
| Voldenet | wszystkie te army hipsterskie mają problemy z driverami | 08:58 |
| Voldenet | nie widziałem jeszcze devboardu, który nie robiłby problemów | 08:58 |
| jacekowski | stm32 w sumie nie jest hipsterski, najpopularniejszy mikrokontroler chyba | 08:58 |
| mrkubax10 | nie miałem za bardzo styczności z mikrokontrolerami może poza Arduino i programowaniu asemblerze ARM na Raspberry Pi | 08:59 |
| mrkubax10 | *programowaniu w | 08:59 |
| Voldenet | No dobra, może przesadziłem z *wszystkie*, ale większość z jakimi się stykałem | 08:59 |
| jacekowski | Voldenet: dzisiaj udalo mi sie osiagnac to ze ethernet dziala stabilnie i sie nie wywala, naprawilem bugi ktore powodowaly ze kod od ST nie byl thread safe, naprawilem bugi ktore powodowaly deadlocki, naprawilem bugi ktore powodowaly ze ramki nie byly wysylane pomimo tego ze kod od ST zwracal informacje ze byly wyslane | 08:59 |
| Voldenet | …najgorsze jest to, że trzeba sobie samemu te drivery reperować ;/ | 09:00 |
| jacekowski | czesc bugow byla juz znana i na forum st byla informacja co jest problemem (chociaz nikt nie podjal sie tematu thread safety) | 09:01 |
| jacekowski | a ze ja w moim urzadzeniu mam 2 watki ktore duzo danych wysylaja to nie bylo opcji nie naprawienia tego | 09:02 |
| jacekowski | boje sie tylko tego ze do nastepnego prototypu bede uzywal innego mikroprocesora od ST i beda nowe bugi | 09:04 |
| mrkubax10 | kojarzy mi się z tym pewien system operacyjny | 09:05 |
| jacekowski | ludzie krytykuja windowsa, ale, w wiekszosci wypadkow, blue screeny to nie byly bugi w windowsie tylko sterownikach dostarczanych przez innych | 09:06 |
| jacekowski | na nowszych windowsach microsoft wprowadzil scilejsze standardy jakosci, duzo zostalo przeniesione do userlandu i/lub odseparowane od kernela w inny sposob, dlatego teraz masz mniej problemow | 09:08 |
| mrkubax10 | w sumie teraz blue screen to rzadkość | 09:08 |
| jacekowski | jak sie sterownik grafiki wywali to go windows potrafi zrestartowac | 09:08 |
| jacekowski | tylko masz przez chwile czarny ekran | 09:08 |
| mrkubax10 | ale kernel panic'a w Linuksie nie widziałem nigdy | 09:09 |
| jacekowski | ja widziale | 09:09 |
| mrkubax10 | pewnie za krótko używam | 09:09 |
| mati75 | ja widzę prawie codziennie | 09:09 |
| mati75 | wystarczy wywalić swap | 09:09 |
| jacekowski | co to swap? | 09:09 |
| mati75 | i odpalić gówno apki w java | 09:09 |
| jacekowski | nie mam swapa na zadnej maszynie | 09:10 |
| mati75 | https://wiki.archlinux.org/title/swap | 09:10 |
| jacekowski | nie znam, nie uzywam | 09:10 |
| jacekowski | root@px1:~# free -m | 09:11 |
| jacekowski | total used free shared buff/cache available | 09:11 |
| jacekowski | Mem: 64160 45004 15790 61 3365 18408 | 09:11 |
| jacekowski | Swap: 0 0 0 | 09:11 |
| mrkubax10 | jeżeli ktoś ma wystarczająco dużo ramu swap jest raczej niepotrzebny | 09:11 |
| jacekowski | swap to proteza | 09:12 |
| mati75 | ja mam 32GB ramu to i tak dałem 4GB bo czasem potrafi wejść na swap | 09:12 |
| mati75 | w szczególności jak się coś kompiluje | 09:12 |
| jacekowski | nie zdarzylo mi sie | 09:13 |
| mati75 | współczesny kod nie jest zoptymalizowany | 09:13 |
| jacekowski | i to nawet kompilujac firefoxa, chrome czy oo.o | 09:13 |
| mrkubax10 | jak ktoś da make -j$(nproc) to może swap się przyda | 09:13 |
| mati75 | przy kompilacji ff ostatnio zdziwiłem się że ramu zaczynało brakować | 09:13 |
| mrkubax10 | przeglądarki w dzisiejszych czasach są skomplikowane więc co się dziwić | 09:14 |
| jacekowski | daje tak i sie nie przydaje, | 09:15 |
| mrkubax10 | razem użyte wolne dzielone buf/cache dostępne | 09:18 |
| mrkubax10 | Pamięć: 7906 1310 3896 106 2699 6251 | 09:18 |
| mrkubax10 | Wymiana: 3814 0 3814 | 09:18 |
| mrkubax10 | też nieużywany | 09:18 |
| mrkubax10 | mimo to że jest | 09:18 |
| mrkubax10 | zastanawia mnie 1 rzecz, jakim sposobem program segfaultuje jak jest uruchamiany normalnie ale jak z GDB to już nie | 09:44 |
| jacekowski | mechanika kwantowa | 09:45 |
| jacekowski | obserwowanie programu go zmienia | 09:45 |
| mrkubax10 | :) | 09:47 |
| jacekowski | ale gdb wylacza duzo rzeczy, aslr o ile mi wiadomo tez | 09:48 |
| Ashiren | :3 https://i.redd.it/axiqtmrosuo91.jpg | 18:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
