- A hozzászóláshoz be kell jelentkezni
Hozzászólások
> A 20 év alatt összejött 300 ezer C89 kódsor, amit kevés ember ért,
> vagy kevésnek van gusztusa hozzányúlni.
Hová lett a világ? :(
- A hozzászóláshoz be kell jelentkezni
Most ebből tulajdonképpen mi nem tetszik neked, a 300k sor, a 20 év, vagy a gusztus? :-) Csak mert nekem ez egy jó hírnek tűnik. Emberek nekiálltak gatyába rázni egy régi, de kellemesen használható szoftver forráskódját.
- A hozzászóláshoz be kell jelentkezni
Az, hogy az ANSI C manapság speciális gusztust igényel. Főként egy olyan szoftvertermék esetében, aminek az elsődleges platformja a POSIX/*NIX. Nekem speciel ahhoz kell speciális gusztus, hogy megpiszkáljak bármint, ami nem ANSI C-ben készült :)
- A hozzászóláshoz be kell jelentkezni
A C89-hez azert eleg kemeny perverzio kell.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Igen. Mindig tudtam, hogy valami baj van velem... :-)
- A hozzászóláshoz be kell jelentkezni
Pedig a c89 jó.
- A hozzászóláshoz be kell jelentkezni
A seggbebaszás is.
- A hozzászóláshoz be kell jelentkezni
Nos, akkor kellemes időtöltést kívánunk neked, mi viszont maradnánk a C-nél.
- A hozzászóláshoz be kell jelentkezni
+1 :)
- A hozzászóláshoz be kell jelentkezni
Annyira nem gáz, nekem leginkább az snprintf és a variadic macros hiányzik belőle.
- A hozzászóláshoz be kell jelentkezni
variadic macros, inttypes.h, inline functions, thread-local storage, designated initializers, anonymous struct/union
Ezek nelkul C-ben kodolni borzalom es kokorszaki erzes.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Igen, viszont a régi kód ezek nélkül is érthető, aztán ahol kell, ott az új dolgokkal kiegészíthető. Ezt hívják (többek között) refactoringnak.
- A hozzászóláshoz be kell jelentkezni
Ertheto, persze, szoval sem mondtam, hogy nem. Csak a C99/C11 jobb, es ezert jo elkepzeles a Vim refaktoralasa :)
--
|8]
- A hozzászóláshoz be kell jelentkezni
Nem is feltétlenül az ANSI C-vel lenne a gond, hanem hogy egy 20 éves kódban iszonyatos mennyiségű gányolás lehet, ahogy jöttek be az új feature-ek. Lehet, hogy
tized annyi kódból, háromszor olyan karbantarthatóra át lehetne írni... csak ugye ez bazi nagy meló, amit eddig senki nem mert bevállalni..
- A hozzászóláshoz be kell jelentkezni
> Nem is feltétlenül az ANSI C-vel lenne a gond
+1. Ez az egyik leghordozhatobb nyelv, me'g mindig.
- A hozzászóláshoz be kell jelentkezni
Fejlődik. A konzervatívok örök bánatára.
Aki nem gépi kódot ír amúgy sem nevezheti magát programozónak, minden C kóder casual pleb.
- A hozzászóláshoz be kell jelentkezni
Dehogy, az igazi programozó FORTRANban dolgozik.
- A hozzászóláshoz be kell jelentkezni
érdekelne hogy ha az ANSI C-t nem értik, akkor miben gondolták megírni a sajátjukat? mert akkor c++ kizárva esélyesen
- A hozzászóláshoz be kell jelentkezni
Az én olvasatomban nem a C89-cel van a baj, hanem konkrétan ezzel a C89-ben megírt 300000 sorral. (Az angol nyelv szépsége, hogy mindenki úgy érti félre, ahogy akarja. :-) ) Másrészt a linkelt bejelentést végigolvasva kiderülnek ennél sokkal fontosabb részletek is.
-----
(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-
- A hozzászóláshoz be kell jelentkezni
viszont 300k sort refactorálni C99/C++á úgy hogy értelme is legyen nem hangzik egy túl megvalósítható dolognak
- A hozzászóláshoz be kell jelentkezni
Bennem inkább az a kérdés merül fel, hogy tényleg kell-e egy karakteres szövegszerkesztőbe 300.000 sor... Gyorsan megnéztem: a 3.7-es joe 43.000 sorban elfér, és az is tele van fölösleges funkciókkal, amit a kutya se használ. Ezek alapján a vim megérett a pokolra takarításra.
- A hozzászóláshoz be kell jelentkezni
Úgy látom nagyon nem ismered a Vim-et, nem "egy karakteres szövegszerkesztő", annál sokkal több.
/Ráadásul van grafikus felülete is: gVim (Gnome), mVim (Mac)/
Inkább az IDE-kkel lehet összehasonlítani.
Kb. az a kategória, ahol az Emacs, Eclipse, IntelliJ, Visual Studio, ... szerepel.
Mélyebben én is csak mostanában kezdek megismerkedni vele, minél inkább megismerem, annál inkább lenyűgöz.
Érdemes egy-két hétvégét rászánni! ;)
- A hozzászóláshoz be kell jelentkezni
Egy-két évtizedet :P
- A hozzászóláshoz be kell jelentkezni
"Inkább az IDE-kkel lehet összehasonlítani.
Kb. az a kategória, ahol az Emacs, Eclipse, IntelliJ, Visual Studio, ... szerepel."
Léccineeeeeee.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Én is nagyjából ezt gondoltam korábban, így elnézem neked.
- A hozzászóláshoz be kell jelentkezni
Oké, milyen integrált megoldásokat nyújt refactoringra, debugolásra, deploymentre, profilingra, unit testingre, stb.?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Deployment kimaradt.
Nem, mégsem.
Egyébként tényleg kíváncsi vagyok a válaszra, nem csak a flame-et akarom szítani.
- A hozzászóláshoz be kell jelentkezni
Ha nem csak flame-elni akarnál, akkor ezek közül mindegyikre találnál példákat magad is egy perc alatt.
- A hozzászóláshoz be kell jelentkezni
Ja, nagyon jó tutorialokat láttam arra, hogy hogyan csináljam meg önmagamnak azt, amit a VS/Eclipse már tud. Kössz, de ez így lófasz. Lehet, hogy a vim nagyon jó kódfosásra, de annál azért már jóval továbbhaladott a technika.
Pl. amikor a debugolás itt tart: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-8…
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Kinek a pap, kinek a papné. Attól, hogy neked nem tetszik, attól még a vim használható mint IDE, az általad felsorolt funkciók valamilyen szinten benne vannak.
Azt láttad, hogy a debugger canvashoz vs 2010 ultimate kell? Meg, hogy halott projekt? Nem gáz olyan fordítót használni amiben még snprintf sincs?
- A hozzászóláshoz be kell jelentkezni
"Azt láttad, hogy a debugger canvashoz vs 2010 ultimate kell?"
...és? .NET 4 a target nálam jelenleg.
"Meg, hogy halott projekt?"
Igen, anyázom is rendesen. Van az új VS-ekben 1-2 dolog, ami félig hasonló módon próbál segíteni átlátni a kódot, de debugolásra és edit&continue aktív használatára alkalmatlan. Sajnos.
"Nem gáz olyan fordítót használni amiben még snprintf sincs?"
Mimimimimimimimi? Mióta a fordító "tartalmazza" a függvénykönyvtárat? Másrészt miután általában C#-ra fejlesztek VS-ben, nem igazán izgat, hogy a C99-ből mit támogat és mit nem. (Abba már bele se megyek, hogy az IDE-khez mi köze).
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Mimimimimimimimi? Mióta a fordító "tartalmazza" a függvénykönyvtárat?
Nem a fordító, hanem a VS2010 tartalmazza a fordítót is, meg az SDK-t is. Vagy nem?
Másrészt miután általában C#-ra fejlesztek VS-ben, nem igazán izgat, hogy a C99-ből mit támogat és mit nem. (Abba már bele se megyek, hogy az IDE-khez mi köze).
Csak annyi köze van, hogy a VS 2010-ben, ami szerinted IDE, benne van fordító, meg az SDK is. És e remek debugger miatt kénytelen vagy azt használni. De biztos egyszerű használni egy újabb fordítót is régi VS-sel igaz?
Az rendben, hogy téged ez nem mind izgat, de akkor miért szólsz valakinek akit meg az nem izgat, hogy milyen C# debugger van a vimben?
- A hozzászóláshoz be kell jelentkezni
"Az rendben, hogy téged ez nem mind izgat, de akkor miért szólsz valakinek akit meg az nem izgat, hogy milyen C# debugger van a vimben?"
A vita onnan indult, hogy vim egy lapon emlitendo, mint a VS, Eclipse meg a tobbi IDE. Csak epp semmi olyat nem tud, ami miatt IDE-nek lehetne nevezni. a Vim egy szovegszerkeszto. Van benne syntax highlight ehhez-ahhoz, hozza lehet meg reszelni ezt-azt, de ettol meg fenyevekre van attol, hogy IDE-nek lehessen nevezni.
Magam is hasznalok Notepad++-t, mikor mondjuk egy <100 soros PHP scriptet irok, de attol meg azt sem nevezem IDE-nek.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
#ifdef MSVC_VER
#define snprintf _snprintf
#endif
esetleg sprintf_s
- A hozzászóláshoz be kell jelentkezni
Csak éppen az _snprintf nem ugyanazt csinálja.
http://stackoverflow.com/questions/7706936/is-snprintf-always-null-term…
- A hozzászóláshoz be kell jelentkezni
Jaj, gyerekek, akkor bedobtok egy snprintf implementációt a projektbe. Félálomban is összedobok egyet egy óra alatt, de aki lusta, kimásolhatja a kedvenc libc forrásából. Most komolyan, ennek ekkora feneket keríteni?
Én is rühellem a billy összes szarát, de nem pont ezért szarkupac az egész...
- A hozzászóláshoz be kell jelentkezni
Nem nagy ügy, persze, de nem csak erről van szó, hanem sok másról a C99-ből, C könyvtárból, ami nincs a VS2010-zel érkező fordítóban/SDK-ban.
Btw. good luck bedobni egyet a kedvenc libc forrásból. GNU libc nem játszik a licenc miatt, freebsd snprintf meg pl. így néz ki:
http://fxr.watson.org/fxr/source/stdio/snprintf.c?v=FREEBSD-LIBC;im=exc…
Ezt csak úgy be lehet dobni VS-ba?
- A hozzászóláshoz be kell jelentkezni
Nem tudom, szerintem a C99 előtt is volt világ. Én mondjuk írtam akkoriban is már programokat C-ben, olyat is, ami n platformon volt kénytelen fordulni. Meg lehetett csinálni, és nem őszültem bele.
Akinek meg abból a FreeBSD-s __vfprintf-ből akkora gondot okoz összeollózni egy snprintf-et, az tényleg inkább ne írjon C-ben programot...
A licenszdolgot se értem: LGPL, kirakod egy külön dll-be, és jónapot.
- A hozzászóláshoz be kell jelentkezni
Ez a szál onnan indult, hogy milyen egy modern IDE, hogy "kell", hogy kinézzen egy modern debugger environment.
A szépséghiba az, hogy a "modern" debuggert már nem fejlesztik, és egy egyébként elavult fejlesztőkörnyezetet kell használni hozzá.
Erre volt példa az snprintf, lehet, hogy nem volt jó példa. De akkor tessék, ha csak windowsra fejlesztesz c++-ban, akkor ezekről kell lemondanod, ha ezt a debuggert akarod használni:
http://msdn.microsoft.com/en-us/library/vstudio/hh409293(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/hh409293.aspx
- A hozzászóláshoz be kell jelentkezni
Az megvan, hogy a VisualC++ egy C++ fordító es nem C99 fordító?
(Debugger Canvas meg egyebkent is .NET-het van, csodallom, hogy ez meg nem tűnt fel. Mondjuk meg az alap VC++ Express debug funkcionalitasat sem tudja a vim, innen kezdve tárgytalan az egész.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Hmmm, akkor VS-ben nincs C fordító? Akkor miért tárgyalják a C99 újdonságokat a C++ újdonságok között?
http://msdn.microsoft.com/en-us/library/vstudio/hh409293
Konkrétan mit nem tud a vim amit a VC++ Express igen?
- A hozzászóláshoz be kell jelentkezni
Nincs hat, valamennyire támogatja a C-t, de ennyi.
"Konkrétan mit nem tud a vim amit a VC++ Express igen?"
Mondjuk integráltan debugolni. Amit mondjuk már egy Turbo Pascal is tudott tizenrengeteg évvel ezelőtt.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ezzel szemben a valóság az, hogy van benne C fordító.
http://msdn.microsoft.com/en-us/library/bb384838.aspx
"Visual Studio includes a C compiler that you can use to create everything from basic C programs to Windows API applications."
Integráltan debugolni mondjuk éppen tud a vim. Többféle nyelvet is.
- A hozzászóláshoz be kell jelentkezni
"Integráltan debugolni mondjuk éppen tud a vim. Többféle nyelvet is."
Engedtessek meg a ketkedes joga. Az, hogy el tud inditani tobbfele debuggert, az nem jelenti, hogy integralodik is vele.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
http://clewn.sourceforge.net/features.html
Pedig integrálódik, ha nem hiszed, próbáld ki. Mondjuk ha tényleg érdekelne, akkor már kipróbáltad volna, és akkor nem írtad volna meg ezt a posztot sem, amire válaszolok most.....
- A hozzászóláshoz be kell jelentkezni
"Clewn is a GDB wrapper"
Ez nalam nem meriti ki a tobbfele nyelv tamogatasat. Egyebkent meg fogsz lepodni: erdekel a dolog, mert hasznalok VIM-et eleg sok mindenre, de pont debuggingra egyaltalan nem talaltam normalisan mukodo megoldast.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
A normálisan működő relatív. Arról volt szó, hogy nincs megoldás.
Többféle nyelv, ha már lusta vagy használni a google-t:
https://sourceware.org/gdb/onlinedocs/gdb/Supported-Languages.html
http://www.vim.org/scripts/script.php?script_id=4170
- A hozzászóláshoz be kell jelentkezni
A GDB csak a forditott nyelveket tamogatja, Java-t, Ruby-t, Python-t nem tamogat.
Ezzel a Vdebuggal tapasztalatod is van, vagy csak powered by Google? En probaltam par debug modult a Vim-hez, es nem igazan talaltam _hasznalhatot_.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Miket próbáltál?
- A hozzászóláshoz be kell jelentkezni
Pfff, fejbol meg nem mondom mar neked, a git repoba pedig nem commitoltam be oket, mert oda csak vegleges megoldasokat teszek (legalabb 3 gep szinkronizal abbol a profilbol, szoval oda nem mukodo, vagy pocsek plugineket nem rakok fel). Foleg rubyhoz keresgelek debuggert egyebkent, van 1-2 olyan Rails projektem, ami eleg kicsi ahhoz, hogy meg vimben kezelheto, de eleg nagy ahhoz, hogy idonkent igeny lenne a debuggingra.
A legtobbszor amugy az a baj, hogy szepen elindul a debugger, meg ott van a konzol, de ennyi, nem tudok a debuggerbol visszajutni a VIM-be pl. egy breakpointnal.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Értem, szóval eljutottunk oda, hogy a vim azért nem (jó) IDE, mert nincs hozzá jól integrálódó Ruby debugger.
- A hozzászóláshoz be kell jelentkezni
És miután az IDE azt jelenti, hogy "integrált fejlesztői környezet" (amely egyébként nem azt feltételezi, hogy van hozzá integrálódó valami, hanem azt, hogy az már a csomagban integrálva van), továbbra sem minősül IDE-nek a vim.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Az általad fent említett debugger benne van a VS-ben? Mert én nem találom....
- A hozzászóláshoz be kell jelentkezni
Komoly szövegértési probléma lehet, ha még mindig nem esett le, hogy az egy kísérleti bővítmény volt a debugger koncepciójának továbbgondolására. És nem, alapból nincs benne, bővítményként tölthető le. Viszont a vimben alapból semmilyen debugger nincs (ami mondjuk kb. 40 éve alapkövetelmény bármilyen IDE-től...)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"amikor a debugolás itt tart" vs. "kísérleti bővítmény volt"
Hát ebből tényleg nem esett le, bocs. Már azt hittem, hogy tényleg itt tart a debugolás, nem fogtam, hogy ez nem komoly. Honnan lehet ezt tudni egyébként, mert én az oldaluk alapján teljesen bedőltem neki, hogy munkára is alkalmas....
"alapból semmilyen debugger nincs"
Na erről nem fogok vitázni az biztos. Szerinted nem IDE, szerintem az (a megfelelő kiegészítőkkel együtt, nyilván). Ezzel nem is vagyok egyedül szerintem:
Developers who favor command-line oriented tools can use editors with support for many of the standard Unix and GNU build tools, building an IDE with programs like Emacs or Vim.
http://en.wikipedia.org/wiki/Integrated_development_environment
- A hozzászóláshoz be kell jelentkezni
Ahhoz képest, hogy szerinted munkára nem alkalmas, teljesen jol mukodik.
De igen, a vim mindent tud, amit a vs/eclipse/stb, csak valahogy a vegen mindig kiderul, hogy megse, maximum, ha valaki megepiti belole az idejet.
De ugy érzem, ez mar részedről csak trollkodas, mikor a vimet idenek nevezed, mikor semmi nincs benne alapbol egy kis syntax highlighten kivul, az autocompletetol a debugon at a mindenféle egyeb kodvizualizalason, profilen, stb. at max valami felig-meddig működő megoldast lehet hozzahackooni, addig azokat a bővítményeket, amelyek az IDE-k eseten a meglévő funkcionalitast bővítik (értsd: alapbol tobbet tudnak, mint a szethakkolt vimed, legalabbis az SW fejlesztést támogató dolgokban), azokat szimplán munkára alkalmatlannak nevezed. Hat kössz, inkabb nézz korul, hogy mi a helyzet a nagyvilágban.
---------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
+1
Itt azt kéne tisztába tenni, hogy attól, hogy valami nem IDE, még lehet egy hasznos eszköz. Ott van pl. a fúrógép. IDE? Nem. De attól még elég sok dologra jó. A Vim is lehet egy baromi hasznos eszköz, fejlesztésre is lehet alkalmas, de attól még definíció szerint nem IDE.
- A hozzászóláshoz be kell jelentkezni
Igen, csak ez valamiért a vimfanoknak nagyon sérti a világnézetét.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ki definiálja mi az az IDE? Te meg saxus? Akkor tényleg nem IDE. Szerintem és a Wikipedia szerint az.
- A hozzászóláshoz be kell jelentkezni
A Wikipedia szerint text editor, az "IDE" sztring meg sem található a lapon.
https://en.wikipedia.org/wiki/Vim_%28text_editor%29
- A hozzászóláshoz be kell jelentkezni
Lehet én nem értem az angolt, de mintha itt is azt írná, hogy egyesek IDE alapnak használják (valahol mégiscsak egy "felhízlalt" szövegszerkesztő egy IDE) és készítenek belőle "IDE-t" (topicban már ki lett tárgyalva ennek nem túl meggyőző eredménye), és nem azt állítja, hogy IDE lenne.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ahhoz képest, hogy szerinted munkára nem alkalmas, teljesen jol mukodik.
TE mondtad, hogy "kiserleti bovitmeny", en meg bedoltem neked. Az a baj, hogy elhiszem amit mondasz, pl. hogy a VS-ben nincs C fordito, aztan kiderul, hogy megis van.
De igen, a vim mindent tud, amit a vs/eclipse/stb, csak valahogy a vegen mindig kiderul, hogy megse, maximum, ha valaki megepiti belole az idejet.
Senki se allitotta, hogy mindent tud.
azokat szimplán munkára alkalmatlannak nevezed.
Megegyszer, te nevezted "kiserleti bovitmenynek", akkor ez mint jelent? Vagy megint csak fullentettel? :)
Hat kössz, inkabb nézz korul, hogy mi a helyzet a nagyvilágban.
Úgy érted használjak Visual Studiot? :) Hát használnék én, de valahogy nem megy benne a C++-11. Meg nincs beleintegrálva a git.
- A hozzászóláshoz be kell jelentkezni
> Meg nincs beleintegrálva a git.
Default állapotban tényleg nincs, de a VS ablakának elhagyása nélkül, kb. három kattintással engedélyezhető a Git, mint source control provider.
- A hozzászóláshoz be kell jelentkezni
Kihagytad azt a 3 betűt, amit valoszinuleg be kell meg irni a keresobe :(
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Partially. Igazabol a gdb-vel sem integralodik annyira, amennyire kellene, mindent, amit meg akarsz tenni, valojaban a gdb-ben kell megtenned, a vim csak annyi segitseget ad - ha jol ertettem az oldalt, amit linkeltel - hogy oda tud ugrani, ahol a gdb all.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Rosszul értetted.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Sok ilyen rendszer van, ahol egész más szemlélet kell, mint a GUI-s csodaprogramok egérrel való bökdösése.
Pl. Latex kiadványszerkesztésre, AwesomWM ablakkezelésre, Git parancssori használata, ...
Ezeknek a tanulási görbéje általában valamivel nagyobb, mint a GUI-s megfelelőjüké, cserébe jó beállításokkal, megfelelő testreszabással, kisebb erőforrás igény mellett hatékonyabb lehet a munka és akár jobb eredményre is vezethet.
Félreértés ne essék, nem azt mondom, hogy ezek jobbak és azok rosszak, csak halkan annyit, hogy nem kell egyik oldalt sem lesajnálni, főleg, ha nem értesz azon rendszerekhez.
- A hozzászóláshoz be kell jelentkezni
"mint a GUI-s csodaprogramok egérrel való bökdösése."
Ok, teljesen biztos, hogy nem használtál még VS-t.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Tévedsz, kb. 10 évig használtam.
Jelenleg is több GUI-s csodaprogramot bökdösök egérrel ;)
- A hozzászóláshoz be kell jelentkezni
Annyira azért nem használhattad alaposan, ha odáig jutottál csak, hogy VS = egérrel kattintgatás.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Kivetelesen +1
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
> http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-8…
Wow, kösz, bookmark'd.
- A hozzászóláshoz be kell jelentkezni
Azt nem vitatja senki, hogy a fenti IDE-k bizonyos dolgokból sokkal többet tudnak, mint a Vim. Itt inkább az a kérdés, hogy a Vim is tekinthető-e IDE-nek és mikor jobb, mint a fenti IDE-k.
A fenti IDE-k sem tudnak megtámogatni minden nyelvet és mindenféle rendszert.
Nagyjából itt jön képbe a Vim, amikor olyan rendszereket, nyelveket kell használnod, amiket a nagy IDE-k nem támogatnak, vagy egyszerre több mindent kell használnod. Illetve olyankor, ha nem túl erős fejlesztői gépen vagy kénytelen időnként dolgozni, pl. laptop.
A konkrét kérdésre is válaszolva. Vannak olyan fejlesztési forgatókönyvek, ahol nem igazán szükséges a debug és a profile, vagy, ha valamelyest igen, akkor ki lehet váltani naplózással (logolással), ami egyébként is szükséges. Lehet olyan megoldás is, hogy ha nagyon szükséges valamit profilozni, akkor arra időnként egy profiler eszközt bevetnek, de a napi munkához általában nem használják az egyes fejlesztők.
Deployment, unit testing és egyéb build rendszerekből meg vannak nagyon jó, nagyon nagy tudású külső eszközök, az Eclipse is előszeretettel használ ilyeneket, pl. az Ant, Maven, Gradle, Sbt (vagy az ősöreg, kis tudású Make ;).
Rengeteg fejlesztőtől hallottam, hogy teljesen Vim-re állt át, illetve van olyan fejlesztő cég is, ahol az elsődleges (ha nem az egyetlen) fejlesztői környezet a Vim (főként Ruby-s fejlesztések), ez a http://hashrocket.com.
- A hozzászóláshoz be kell jelentkezni
Azért a make nem kis tudású, ezt merem állítani. Nehézkes, az tény.
- A hozzászóláshoz be kell jelentkezni
Hat, attol fugg, melyik make-ra gondolsz. En a GNU Make-t ismerem, de eddig for ciklust egy make implementacioban sem lattam, mind az alatta futo shell hasonlo parancsara epitett.
A masik meg az, hogy a make es az ANT/Maven jellegu build toolok nem hasonlithatoak ossze, reszben mert masra valo a ketto, reszben pedig tudasban sincs pariban sehol.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
$(foreach)
- A hozzászóláshoz be kell jelentkezni
Ez melyik make? Just to make clear.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
A GNU Make, amit ismersz.
Szerk: nem oltani szerettelek volna, hanem mondani, hogy nyilván arról fogok írni, amit ismersz, nem valami egészen másról ;-)
- A hozzászóláshoz be kell jelentkezni
A "text" argumentuma az egy vegrehajthato parancs is lehet? Illetve, ugy nezem, hogy ez nem blokkos formula (mint az if), igy bonyolult muveleteket nem lehet vegezni ciklusban.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
A harmadik argumentum lehet függvényhívás is.
$(foreach elem, srcs, $(addsuffix .o, $(basename elem)))
Jó, ez mondvacsinált példa, a basename és az addsuffix is elfogad listát, valamint egyszerű helyettesítéssel megoldható volna.
- A hozzászóláshoz be kell jelentkezni
Ha van egy tiz soros ciklustorzsem, amiben egy parancs sem hasznalja fel az elotte levo kimenetet semmi modon, hogy lehet megoldani vele?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Azért mindent ne én keressek meg helyetted :-)
http://stackoverflow.com/questions/6520914/defining-custom-gnu-make-fun…
- A hozzászóláshoz be kell jelentkezni
> eddig for ciklust egy make implementacioban sem lattam
Nyilván agyonra nem kerested, mert a korábban már emlegetett GMake mellett pl. a FreeBSD-féle make is tud cklust, igaz ott teljesen eretnek módon kell írni:
.for i in 1 2 3
echo ${i}
.endfor
Szóval lehet itt ekézni másokat, hogy ismerik vagy nem egy alkalmazás funkcióit, de akkor legyük már igényesek, és mi is ismerjük meg a túloldalt. Nem feltétlenül ebben a szintaxisban ugyan, de vagy 20 éve tud ilyesmit jó pár make implementáció.
Ami meg az integrált debuggert illeti, jól értem, hogy a vizuál stúdióban olyan hibakereső van, ami nem használható ónállóan debuggolásra, csak a hozzáépített egyéb funkciókkal? Hát legyen nektek. De ugye ebben az esetben nem hívjuk IDE-nek, hisz semmi nincs integrálva semmivel. Ha jól értem ezt a baromi hosszú, értelmetlen, "de-az-én-apukámnak-meg-csébje-van" szálat, akkor nincsen benne C-fordító se, vagy igen, meg nincsen benne debugger se, vagy igen, és editor sincs benne, vagy igen.
Ez a nem-IDE eszköz tartalmaz olyan részt, ami a kód odahányását megkönnyíti (régen tán editornak mondtuk volna), meg valamit, ami egy pontosan meg nem fogalmazott nyelv kompilálását is elvégzi (régen fordítónak híttuk volna, de egyelőre brit tudósok próbálják megfejteni, hogy melyik ismert nyelvre hasonlít az a nyelvjárás amit ismer), sőt valami futtatható előállító rész-izé is van (hint: ezt hívták régen linkernek); hasonlóan olyan komponense is van, amivel nem a kódba kell beleírni az if (debug) { printf( "%d\n", i ) ; } valamit, hanem katténtok az i változóra, és külön ablakban látom az echo $i kimenetét. Régen debuggernek hívtuk volna, de jelenleg ez csak egy szeletkéje ennek a hatalmas kódtömegnek.
Szóval ha ez így van, akkor örüljetek, használjátok. De ne hívjátok IDE-nek, hisz semmi önmagában működő valami nincs semmi mással integrálva. Hívjátok mondjuk Egybehányt Kódelőállító Egyvelegnek (rövide: EKE). És innentől mindenki megnyugszik, aki tudja használni a vimet meg a gdb-t, az is képes korábban megszokott módján további kódot előállítani, meg aki a VS-t ismeri, az is.
És béke leszen a Földön, meg napsütés.
- A hozzászóláshoz be kell jelentkezni
"A fenti IDE-k sem tudnak megtámogatni minden nyelvet és mindenféle rendszert."
Nem is kell. Azt támogassák jól, amihez készült. Ne mindenfélét jobb-rosszabb szinten.
"Vannak olyan fejlesztési forgatókönyvek, ahol nem igazán szükséges a debug"
Bullshit.
"vagy, ha valamelyest igen, akkor ki lehet váltani naplózással (logolással), "
Überbullshit. Az ilyen "de nem kell debug" blődségekből vannak az //echo "lofasz"-ok és a bennfelejtet print_r($asdf); -ekkel teleszarva a PHP-s tákolmányok jelentős része*. Elég szánalmas, amikor valaki úgy áll hozzá, hogy kódot kell módosítani ahhoz, hogy a működését vizsgálja. (Az, hogy ez más nyelveken, pl. C-nél még mivel jár, azt már inkább meg sem említem...)
Az, amikor futás közben berakok egy töréspontot, és látom, hogy hol a hiba, és menet közben átírom a kódot, legyen szó C# vagy korlátozott mértékben C++-ról (vagy Java esetén még töréspont sem kell) és a háttérben beleszerkeszti a futó programba az új kódot az IDE/fordító, azt a csodás vimedben már azért kicsit nehezebben hozod össze, mint egy arra fejlesztett IDE-ben. És azért egy-egy ilyen nem keveset tud dobni a produktivitáson. Persze, meg lehet ragadni ott, ahol a C tartott 40 éve, de azt a pöcsölést nekem nem fizetik.
* Ott a jelenség mondjuk súlyosabb az xdebug nyomoréksága miatt.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"Nem is kell. Azt támogassák jól, amihez készült. Ne mindenfélét jobb-rosszabb szinten."
Bármilyen hihetetlen, de sokan vannak úgy, hogy inkább használnak egy rendszert, mint 5 másikat, amik valamely részekre vannak optimalizálva.
Ha az az egy rendszer, amit használsz lefed mindent, akkor nyilván lehet az a jó választás.
"Überbullshit. Az ilyen "de nem kell debug" blődségekből vannak az //echo "lofasz"-ok és a bennfelejtet print_r($asdf); -ekkel teleszarva a PHP-s tákolmányok jelentős része*. Elég szánalmas, amikor valaki úgy áll hozzá, hogy kódot kell módosítani ahhoz, hogy a működését vizsgálja. (Az, hogy ez más nyelveken, pl. C-nél még mivel jár, azt már inkább meg sem említem...)"
Úgy látom nem láttál még normális Log rendszert. Azt hogy valamit lehet rosszul csinálni, az nem azt jelenti, hogy az a mérce. Az überfasza VS-sel is lehet benne hagyott print "lofasz"-okat rakni, de ez elég messze áll a logolástól.
Megint a debug erőltetésével jössz, de én nem írtam olyat, hogy azt a Vim-ben kellene erőltetni.
- A hozzászóláshoz be kell jelentkezni
"de én nem írtam olyat, hogy azt a Vim-ben kellene erőltetni."
Értem, szóval szerinted sokkal egyszerűbb
1) egy külön programban végigstepelni,
2) majd átlépni az editorba,
3) megszerkeszteni a kódot,
4) újrafordítani,
5) újraindítani az egészet és
6) eljutni ugyanoda ahelyett, hogy
1) a szerkesztőben ugyanott végigmegyek a kódon, majd ha megtalálom a hibát,
2) átírom a kódot
3) és már az új kód fut tovább.
Intuitív ez a vim valóban.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
A debuggolás és a logolás akkor sem tökéletes helyettesek a legtöbb projektben.
Rendes debuggerrel már azelőtt ki lehet szűrni egy csomó dolgot, mielőtt akár egy dev környezetet összelegóznál az alkalmazás alá. Elvi hibát is talán könnyebb levadászni vele, hiszen sorról sorra látod, hogy mit csinál a cucc. Lehet, hogy a kódban olyan hiba van, ami miatt el sem jut odáig, hogy benyögjön valamit a logba.
A log nálam inkább már az exceptionök és társaik világa: előbb legyen egy _ideális_ körülmények között _mindig_ működő alkalmazás, utána a dinamikusan keletkező hibákról meg nyilván ír majd valamit a logba, ami alapján lehet javítani. De egyik lépést sem tartom jónak kihagyni.
- A hozzászóláshoz be kell jelentkezni
A logolas meg a debug nem ugyanarra valo. Ha a logolast arra hasznalod, hogy kideritsd, mi tortenik az alkalmazasodban, az mar regen rossz.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
> ha nem túl erős fejlesztői gépen vagy kénytelen időnként dolgozni, pl. laptop.
Azért a VS-nek nincs akkora rendszerigénye ám. Nyilván több, mint egy vimnek, de ha a 24 giga rammal megáldott dev gép elől átültem a 4 giga rammal szeránykedő laptopom elé, nem állt meg a világ.
> Vannak olyan fejlesztési forgatókönyvek, ahol nem igazán szükséges a debug és a profile, vagy, ha valamelyest igen, akkor ki lehet váltani naplózással (logolással), ami egyébként is szükséges.
What did I just read? Hirtelen nem tudok elképzelni ilyen forgatókönyvet már azon kívül, hogy valaki hegeszt egy pársoros, egyszer használatos szkriptet valamire.
- A hozzászóláshoz be kell jelentkezni
"Azért a VS-nek nincs akkora rendszerigénye ám. Nyilván több, mint egy vimnek, de ha a 24 giga rammal megáldott dev gép elől átültem a 4 giga rammal szeránykedő laptopom elé, nem állt meg a világ."
Akkor itt nem Rólad volt szó. Eclipse egy közepes projektnél is pár száz MB alatt meg se moccan és még sok ilyen összetevőt tudok sorolni, amiket nem mind lehet elhagyni (böngésző, adatbázis kezelő, ...)
"What did I just read? Hirtelen nem tudok elképzelni ilyen forgatókönyvet már azon kívül, hogy valaki hegeszt egy pársoros, egyszer használatos szkriptet valamire."
Például a TDD-nél (Test-driven development), ott nagyon ritkán van szükség debugra. Amikor meg szükség van, akkor is jobb általában egy log rendszer, mert pl. nem a program sima futása okozza a hibát, hiszen azt a teszt rendszer kiszűri, hanem több komponens összeakadása. Ezek azok a tipikus hibák, amik úgy tűnnek, mintha véletlenül jönnének nagy ritkán. No ezeket szinte lehetetlen kidebuggolni, de naplózással sokkal egyszerűbb rájönni mi okozza.
Részemről egyébként itt befejezem ezen szálat (Saxus részét is), mert nem nagyon látom, hogy ezen információkra valójában kíváncsiak lennétek, inkább egyfajta kötekedést látok csak. Bár leírtad, hogy nem akarsz flamelni, de mégis olybá tűnik.
- A hozzászóláshoz be kell jelentkezni
Mar megbocsass, de szerintem a TDD pont nem erre valo. TDD-nel (pontosabban a jol megirt tesztek eseteben) vizsgaljuk a bemenetet, meg a kimenetet. Azt, hogy maga az algoritmus _belul_ hogy mukodik, azt nem vizsgaljuk, pont azert, mert a teszteknek ez nem feladatuk, illetve a TDD definicioi szerint az algoritmus jol mukodik akkor, ha az adott bemenetre adott kimenetet ad. De ha a teszt elfailedezik, mert nem a megfelelo kimenet jon a megfelelo bemenetre, akkor igenis debuggerrel a legegyszerubb kinyomozni, hogy miert. A logolas nem a debugger helyettesitesere valo, es nem is a print "foobar=#{foobar}" sorok helyettesitesere.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
> Vannak olyan fejlesztési forgatókönyvek, ahol nem igazán szükséges a debug és a profile, vagy, ha valamelyest igen, akkor ki lehet váltani naplózással (logolással), ami egyébként is szükséges.
What did I just read? Hirtelen nem tudok elképzelni ilyen forgatókönyvet már azon kívül, hogy valaki hegeszt egy pársoros, egyszer használatos szkriptet valamire.
Ezek szerint még életedben nem fejlesztettél 8-bites mikrokontrollerre, amiben van 512 byte RAM, output device-ként meg mondjuk szumma kettő darab LED meg egy relé...
- A hozzászóláshoz be kell jelentkezni
Miért? 512 byteon elfér egy vi+C fordító? A ledeken meg kimorzézza a forráskódot, a relé meg bekapcsolja az elektrosokkolót compiler hiba esetén?
Értsd: irreleváns, hogy mire fordítasz. Én speciel mikrokontrollerezni is Eclipse-ből szoktam. Van egy jó automatizált buildrendszerem, azt használom.
- A hozzászóláshoz be kell jelentkezni
És ennek mi köze van ahhoz, amire válaszoltam? Hogy nem tudja elképzelni azt a forgatókönyvet, ahol egész egyszerűen nincs a debugra lehetőség se, tehát irreleváns, hogy a forráskód szerkesztésére használt eszköz tud-e ilyet vagy sem.
Értsd: a vi nem a fordított kód, hanem a szövegszerkesztő, amiben a forráskódot szerkeszted.
- A hozzászóláshoz be kell jelentkezni
Hát ezt amúgy pont eltaláltad.
Tehát akkor a mikrokontrollereken lehet logolni debugolás helyett? Mert ugye az eredeti szál onnan indult, hogy szerintem a kettő nem egymás tökéletes helyettesei.
- A hozzászóláshoz be kell jelentkezni
Mikrokontrollereken általában nem lehet debuggolni (vagy egyáltalán - nincs is benne erre hardver, vagy praktikusan nem: kell a láb másra; nem tolerálja a periféria vagy a kívül rákötött hardver, ha megállítod a kód futását, meg ilyenek). Logolni akkor lehet, ha van valami értelmes periféria, ahol a log "ki bír jönni", mondjuk egy soros port már jó erre a célra - bonyolultabb perifériákkal (pl. USB) meg az a baj, hogy az azt működtető szoftverrész kell a logoláshoz is, tehát abból a szekcióból nem tudsz logolni, plusz interrupt handlerből se könnyű logolni. Néha egyébként még ez sincs, van egy pár LED, oszt azokat lehet villogtatni.
Szóval az eredeti felvetésre: természetesen nem 100%-os helyettesítői egymásnak, de aki amit nem tud megoldani logolással, az debuggolással se nagyon fogja.
- A hozzászóláshoz be kell jelentkezni
Azért szerencsére ezen már túljutott a tudomány: a JTAG debuggerek pont az ilyen helyzetekre lettek kitalálva.
- A hozzászóláshoz be kell jelentkezni
Nem az ANSI C a gond, hanem a C89, es a rengeteg legacy platform tamogatas. Egy csomo altaluk feleslegesnek itelt dolgot mar kidobtak, es elkezdtek refaktoralni. Teljesen vallalhato feladat (mondjuk ahogy a plugineket meg GUI-t tervezik, az meglehetosen naiv, de az mar egy masik kerdes).
--
|8]
- A hozzászóláshoz be kell jelentkezni
Már csak az a nagy kérdés, hogy az általuk feleslegesnek itélt dolgokkal kapcsolatban másnak mi a véleménye. (Rémlik, hogy GCC-fejlesztők leszarták a FreeBSD-fejlesztők által kért változtatásokat; kidobták az a.out formátum támogatást, és nyilván lehet ezt még sorolni a végtelenségig. A "legacy platform" meg kicsit rosszul hangzik. Van grafikuskártya gyártó, aki a nem túl régi kártyáit minősíti ilyenre, van desktop os gyártó, aki a 32-bites x86-ot minősítette így, és ez sokaknak fáj. Persze értem, az majd használ változatlanul vim-et.
- A hozzászóláshoz be kell jelentkezni
Jaja, és az a rohadt OSX sem fut rendesen PDP-11-en, nem úgy mint a régi Unixok :o)
- A hozzászóláshoz be kell jelentkezni
Akinek faj, az hasznal majd Vimet tovabbra is, igy van. Neha aldozatokat kell hozni, es ha a fejlesztok 99%-a Linuxon van, es a userek nagyja is, akkor barmi mast supportalni nem eri meg (nem tudom, hogy neovimnel mi a helyzet, es milyen platformokat celoztak meg, altalanossagban mondom).
Elofordul olyan, hogy egy szoftver hirtelen dobja a $kedvenc_platform tamogatast. Ez faj, de ez van.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Emlekszik meg valaki az yzis projektre?
https://github.com/chrizel/Yzis
A kvim-es sracok akartak irni 0-rol egy jol integralhato vim enginet. Sajnos a dolog elhalt.
En nem hiszek egy ekkora projekt refaktoralasaban. Jo ugyan a szandek, hogy a mukodokepesseg folyamatosan megmaradjon, de valahogy az ilyen merteku valtoztatasok nem szoktak megturni a regi kod szerkezetet. Azert kivancsi vagyok es drukkolok nekik. Egy jol integralhato vim enginere nagy igeny lenne. Egy csomo editor / IDE ir maganak kulon vim emulaciot.
- A hozzászóláshoz be kell jelentkezni
0-rol irni != refaktoralni
0-rol eselytelen irni, de egy nagy kodbazist szep lassan refaktoralni (mint ahogy a libreoffice-osok csinaljak az openoffice fork utan) lehetseges, sot, egy ido utan meg jo otlet is lehet.
- A hozzászóláshoz be kell jelentkezni
"0-rol irni != refaktoralni"
Nem tudom, hogy en hol allitottam az ellenkezojet.
- A hozzászóláshoz be kell jelentkezni
A Vim karbantartója - Bram Moolenaar - reagált a Neovim-re:
Total refactoring is not a solution.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Kár hogy a GitHub-on felsorolt célokkal (és kritikákkal) kapcsolatban nem fejtette ki a véleményét.
-----
(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-
- A hozzászóláshoz be kell jelentkezni
Hat, ha tovabbra is alatamasztanak minden valtoztatast tesztekkel, es nem tornek funkcionalitast, en tamogatom a projektet. A Vim Windowsos forditasa nehezkes, lehetne sokkal-sokkal konnyebb is. Viszont arra jo lenne figyelni, hogy a Ruby, Python, Perl, stb. tamogatas Windowson se torjon el...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
wikin találtam:
You might also want to read :help development.
Head rev buildelés után :help development
output:
E149: Sorry, no help for development
:)
- A hozzászóláshoz be kell jelentkezni