- 2014. november 10.: Eric S. Raymond (ESR) egy év után sikeresen konvertálta a GNU Emacs forráskódját GNU Bazaar-ról Git-re. ESR ezzel együtt felhívta a nyílt forrású projekteket, hogy váltsanak CVS-ről is Git-re.
- 2015. február 10.: ESR válaszul Richard Stallman-nek, aki kritizálta az LLVM debugger használatát az Emacs projektben, kijelentette, hogy az LLVM-é a jövő és sokkal jobb compiler, mint a GCC és a világnak fel sem tűnne, hogy ha a GCC egyik napról a másikra eltűnne.
- 2015. augusztus 23.: Miután ESR tudomást szerzett arról, hogy a GCC fejlesztők arról tanakodnak, hogy a korábban használt SVN-t le akarják cserélni Git-re, felajánlotta hogy segít véghez vinni a konverziót a saját Reposurgeon programjával. Közben hozzátette, hogy a korábbi CVS->SVN konverzió összekavarhatott néhány dolgot, amit javítani kell.
- 2015. augusztus 27.: ESR saját Patreon oldalán kezdett gyűjteni a GCC konverzió segítésére.
Egy kis ugrás az időben:
- 2018. július 8.: ESR bejelentette, hogy megoldotta az egyetlen fennmaradó technikai problémát, viszont ezzel együtt azt is bejelentette, hogy sajnos a saját 64GB RAM-al rendelkező gépen nem elegendő a konverzió végrehajtásához és sajnos 128GB DDR4-es RAM túl drága, így megoldást kell találnia a RAM használat visszaszorítására.
- 2018. július 20.: ESR bejelentette, hogy sajnos újabb hibába futott a Reposurgeon fejlesztése és sajnos még egy PC upgrade sem segítene a helyzeten, mert nem lehetne párhuzamosítani a folyamatot, ezért bejelentette, hogy a Reposurgeon-t Python-ról Go-ra portolja, aminek számításai szerint 40x-es sebesség növekedést kell eredményeznie.
- 2018. december 18.: ESR állítása szerint a Go port 90%-ban kész van és a GCC repón 3x-4x-es sebességet sikerült elérni, aminek következtében a számítások szerint 3 óra alatt véghez vihető a GCC konverzió, de további tuningolások szükségesek még.
- Kis érdekességként 2019. januárjában az LLVM projekt is elkezdte a megbeszéléseket, hogy Git-re és GitHub-ra állnak át SVN-ről, melyhez saját eszközt fejlesztettek. A konverzió lezárását október 21.-re tervezve.
- 2019. május 15.: A Linaro egyik fejlesztője, Maxim Kuvyrkov beküldött egy adag patch-et, ami egy 300 soros Bash szkripttel és az SVN és Git alapértelmezett eszközeivel elvégzi a konverziót.
- 2019. május 19.: ESR válaszul Maxim patch-ére, kijelentette, hogy ő nem bízik a git-svn programban és szerinte hajlamos hibákat elkövetni a konverzióban.
Ugyanezen levelében válaszul, hogy szeptemberre készen áll-e a Reposurgeon a konverzióra, azt válaszolta, hogy 65% az esélye, hogy igen.
A System76-tól kapott egy AMD Threadripper-el szerelt gépet, hogy ezzel gyorsítsák a munkálatokat. Így ezzel a géppel már 15x-ös sebességnövekedést mért a Python verzióhoz képest.
Állítása szerint a Go port már 90%-ban készen van, illetve felvetette, hogy ha egy lelkes C programozó szeretné, akkor a Go verziót átírhatná C-re. - 2019. október: Az LLVM csapata meglépte a Git konverziót és az infrastruktúrájukat átdolgozását megkezdték.
- 2019. december: A GCC csapata elhatározta, hogy december közepéig eldöntik, hogy ESR vagy Maxim megoldása mellett rakják-e le a voksukat, hogy az ünnepek alatt meglépjék a konverziót. Közben Maxim továbbfejlesztette a szkriptjét és már csak néhány hibát kellett orvosolnia. Közben ESR a Freenode-on demonstrálta a saját konverziós megoldását.
- 2019. december 16.: A GCC csapata nem tudott teljesen dűlőre jutni, hogy akkor melyik konverziós megoldást is pártolják. A többség ESR megoldását pártolta, míg a többiek inkább a két konverziós megoldás eredményeit szerették volna összevetni, hogy melyik eredményez jobb végterméket. Közben ESR továbbra is kiállt amellett, hogy Maxim megoldása, hogy a git-svn -t alkalmazzák, nem túl okos döntés.
- 2019. december 24.: ESR bejelentette, hogy szerinte a Reposurgeon már teljes mértékben készen áll a GCC konverzióra, már csak egy-két kisebb hibát kell orvosolni, de az nem gátolja a konverzió lefutását, így még egy-két nap halasztást kért, hogy javítsák a dolgokat.
- 2019. december 29.: Maxim nyíltan megkérdőjelezte, hogy ESR megoldása készen áll-e a konverzióra, ugyanis több, igen komoly hibát is felfedezett a Reposurgeon-féle konverzióban és nem érti mihez ide, ennyi idő, mikor az ő megoldása már a nyár alatt készen állt a konverzióra és azóta nem volt nagyobb volumenű módosítás a kódjában, mint a Reposurgeon esetén. Maxim ajánlotta is, hogy egy hozzáértő fejlesztő hasonlítsa össze a Reposurgeon-féle kimenetet egy már létező Git-re konvertált GCC verzióval mielőtt bárki kijelenti, hogy ESR új megoldása készen áll a feladatra és jobbnak számít-e.
Mindeközben a GCC csapatának még mindig nem sikerült döntenie a konverziós megoldások között. - 2020. január 8.: Joseph Myers bejelentette, hogy miután ESR megoldása kapott még néhány további finomítást már készen áll arra, hogy elvégezzék vele a konverziót.
- 2020. január 11.: Megkezdődött a konverzió, ami reggel 8 órára le is futott.
Azóta a GCC már csak a saját infrastruktúrájukat igazítja a Git-hez.
- pehsa blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
OMG, a sztori így pontokba szedve olyan mint egy paródia bohózata. Amúgy belemenve a részletekbe biztos tényleg nehéz probléma ez, mert ESR nem hülye. Ha ennyi idejébe tellett a jó megoldás, akkor valami nehéz volt benne. Lehet, hogy öregszik is. Gratulálok mindenkinek aki dolgozott rajta, és reméljük nem lesz túl sok regresszió!
- A hozzászóláshoz be kell jelentkezni
(yakety sax)
- A hozzászóláshoz be kell jelentkezni
Ennyire rossz a Python teljesítménye a Golanghoz képest?
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
igen ;-)
python nem rosz amikor a problema tenyleg I/O -ra var, vagy az esetek tobsegeben native library -bol szarmazo kodot hajt vegre,
vagy egyeb dark megic altal generalat kodot (GPU) ...
python kifejezetten szivas, ha egy shell loopol python cumokat hivsz.
A sima python code nagysagrendileg perl,ruby,php,javascript sebessegu.
Tobb szallusag limitalt, mindegyikben.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Azert nem egeszen.
Peldaul a python alapadatszerkezetei optimalishoz kozelibbek, mint a tobbi scriptnyelve.
De a kulso konyvtarakban tenyleg vannak borzalmasan bugos es optimalistol nevetsegesen tavol allo megoldasok. A "batteries included" egy illuzio.
Multithread: az tenyleg limitalt.
- A hozzászóláshoz be kell jelentkezni
De ugye nem tévedek nagyot, ha úgy gondolom, hogy ettől függetlenül a Python még mindig scriptnyelv, azaz a kód interpretált futtatása versus a kód fordítása + futtatása áll egymással szemben?
- A hozzászóláshoz be kell jelentkezni
Ez eppenseggel igaz. De a jobb fajta szkriptnyelvek koze tartozik, ami alapadatszerkezeteket hasznalva csak linearisan lassabb a forditott kodnal, nem exponencialisan (PHP Array() rad mutogatok epp).
- A hozzászóláshoz be kell jelentkezni
Jó, hát array()... Nem úgy van, hogy nyomikat nem ér ütni? :)
Szegényke tömbnek hívja magát, de valójában egy hashset, ami egy picit tömb is meg picit objektum is, meg picit minden is.
- A hozzászóláshoz be kell jelentkezni
A lenyeg:
Ami O(1) std::unordered_map-ban C++-ban, az legalabb python dict()-ben is O(1) lesz, PHP-ban meg kurvara nem, sehogy sem, orulj, ha az O(log n) osszejon az erre leginkabb hasonlito adatszerkezettel (array())
Erre ertettem, hogy "csak linearisan lassabb" (konstansszor annyi utasitas assembly-ben a pythonos valtozat, nem konstansszor valtozoszor annyi)
- A hozzászóláshoz be kell jelentkezni
Értem én, de a PHP-s array()-jal nem csak az a gond, hogy lassú, hanem az, hogy koncepcionálisan el van cseszve.
- A hozzászóláshoz be kell jelentkezni
Ertem. Tokeletesen megertem, mi a bajod azzal, hogy
<?php
$arr = array(
1 => 'valami',
2 => 'mas',
0 => 'lofasz'
);
foreach ($arr as $key => $val) {
echo $key . ' ';
}
azt irja ki, hogy
1 2 0
- A hozzászóláshoz be kell jelentkezni
"Nincs" baj ezzel sem, csak ne hívjuk array-nak a hashsetet.
- A hozzászóláshoz be kell jelentkezni
Ugy tudom mas nyelvek is bunosok abban, hogy "associative array"-kent emlitik a hashsetet. Meg mindig jobb, mint amikor a Kiskapu "hasitotabla"-nak forditotta ;)
(hirtelen csak a bash meg az awk jut eszembe, ahol ugyanilyen "associative array" hibrid van)
- A hozzászóláshoz be kell jelentkezni
hasitotabla
azt a kurva eletbe, ez komoly?
- A hozzászóláshoz be kell jelentkezni
Teljesen komoly, bevett kifejezés, a Kiskaputól függetlenül. Most gondolj bele, hogy volt olyan magyar elnevezés, hogy i-bög... Na az szerencsére nem maradt meg a szaknyelvben :-)
- A hozzászóláshoz be kell jelentkezni
De miert???? :D
- A hozzászóláshoz be kell jelentkezni
A hasítótábla, mint kifejezés teljesen bevett dolog, nem Kiskapu-only.
- A hozzászóláshoz be kell jelentkezni
elégnagybaj
- A hozzászóláshoz be kell jelentkezni
Azt teljesen biztosan tudom, hogy az AWK associative array néven emlegeti amióta egyáltalán létezik - azaz 1977-től legalább; a hashset mikori találmány? Nekem a hash legelőször a Perl-ből ismerős, ami deklaráltan az AWK után egy jó 10 évvel keletkezett. Ettől nyilván lehet hogy más nyelvekben / környezetben már korábban is előfordult bármelyik.
Nekem az volt a tapasztalatom, hogy speciel a tömb -> asszociatív tömb mint oktatási irány teljesen jól kezelhető volt, kb. senkinek nem okozott problémát megérteni, hogy a hash-t (vagy assoc array-t) úgy kell felfogni, mint egy olyan tömb, ahol az elemek eléréséhez használt index nem csak nem-negatív egész szám, hanem bármi más is lehet (jellemzően valami szöveglánc), e miatt pedig nyilvánvalóan az elemek "sorrend szerinti bejárása" nem feltétlenül egy átlagember számára is logikus sorrendben fog történni, és értelemszerűen a halmazokon értelmezett "eleme-e" egy létező tulajdonság. És kész.
- A hozzászóláshoz be kell jelentkezni
Ez mind remek, csak a legalapvetőbb probléma az, hogy PHP-ban csak és kizárólag ez az izé van, ahelyett, hogy lenne
- egy rendes interface, hogy felsorolható típus (gyk.: oda lehet adni a foreachnak)
- lenne egy rendes tömbtípus
- lenne egy dictionary/hashset típus
Meg akkor már stack meg queue, de ilyen finomságokról már álmodni sem merek.
- A hozzászóláshoz be kell jelentkezni
Csak egy gyors keresés eredménye benchmark-ra Go vs Python:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-…
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Sokkal sokkal lassabb. A Golang, akárcsak a Java, erősen típusos nyelv, azaz egy változóról tudható hogy mit takar. Ezzel szemben a Python értelmezőnek minden függvényhívás előtt futás időben meg kell vizsgálnia a típust amire meghívták, sőt még az argumentumok típusát is ki kell deríteni, így választódik ki a ténylegesen meghívandó függvény. Hogy ez mennyire összetett, hány függvényhívás rejlik pl egy sima "+" (összeadás) mögött, azt bemutatják itt:
How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework
Az előadó többek között a lassúság okának nevezi meg, hogy olyan belső dolgok, amelyek a leírt bonyolult működést tudnák gyorsítani, kiszivárogtak (elérhetők a Python programból), ami csak tovább bonyolítja a dolgot.
A Python értelmező alatt általában CPython értelmezőt értik, amiről a video is szól. Más Python értelmezők jobb teljesítményt nyújthanak, de azok nyelvi értelmezést tekintve nem feltétlen 100% kompatibilisek a szabvánnyal, másrészt a Python lib-ek nagyrésze direkt a CPython-hoz készült és csak azzal működik.
- A hozzászóláshoz be kell jelentkezni
Édes jó istenem.
- A hozzászóláshoz be kell jelentkezni
:-) Látom magam előtt, ahogy ezt sóhajtod... :-D De megértem.
- A hozzászóláshoz be kell jelentkezni
Abból látszik h nem értek hozzá, h azt gondoltam volna, az aktuális svn "mastert" átviszik és mindenki onnan folytatja. (Sose használtam svn-t.)
- A hozzászóláshoz be kell jelentkezni
Itt (meg máshol is) az volt a fő ok, amiért nem csak egy aktuális állapotot emeltek át és onnan folytatják, mert a teljes code history-t is át kell emelni, hogy később ha valamivel probléma van, akkor kiderüljön, hogy ki és mikor csinálta a módosításokat. Illetve az épp aktuális branch-ek is kellenek, hogy mindenki zavartalanul folytathassa a megkezdett munkálatokat.
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Gondoltam h nem sima copy-paste a cucc.
Az viszont fura h nincs official migrációs tool * > git irányba.
Ha én lennék vmelyik git szolgáltató, biztos csinálnék, hogy jöjjenek az ügyfelek.
- A hozzászóláshoz be kell jelentkezni
Van... Említve is van, a git-svn. A Git saját tool-ja, hogy SVN repót behúzzon Git alá. Ez ellen emelt hangot ESR, hogy szerinte nem jó.
Maxim pont ezekre az eszközökre alapozta a megoldását és nem egy teljesen új sajátot csinált, mint ESR.
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
A `git-svn` igazából nem migrációs tool, bár arra is lehet használni. A fő célja, hogy kétirányú kapcsolat legyen egy központi Subversion repo és a user Git repo-ja között, másszóval hogy Git-et használva is lehessen Subversionben tárolt projekten dolgozni.
Ami tényleg hivatalos "* -> Git" migrációs eszköznek tekinthető, az a fast-import stream formátum az azt feldolgozó `git fast-import` paranccsal. Persze ehhez kell valami eszköz, ami ilyen stream-et köp ki magából: erre egyrészt ott a beépített `git fast-export` parancs, ha esetleg valaki Git-ről szeretne valami másra migrálni (vagy egy Git repo-n mindenféle átalakításokat eszközölni), és mindenki kedvenc internetes keresője szerint számos verziókezelőhöz (hg, bzr, svn, cvs, rcs, ...) elérhetőek hasonló fast-export eszközök. Hogy ezek mennyire megbízhatóak, azt nem tudom, se azt, hogy a GCC migráció során próbálták-e ezt a lehetőséget (a fenti (egyébként remek, köszi) történeti áttekintés nem említi).
- A hozzászóláshoz be kell jelentkezni
Ha én lennék vmelyik git szolgáltató, biztos csinálnék, hogy jöjjenek az ügyfelek.
A github-ot lehet svn-nel is használni :)
- A hozzászóláshoz be kell jelentkezni
Nem igazan - probaltad mar?
Az "svn-nel hasznalas" elso lepese, hogy a github megmondja, hogy milyen toollal konvertald az svn repot git repova, es utana tarolhatod githubon a gites repot.
- A hozzászóláshoz be kell jelentkezni
Checkout biztos megy, talán bármi a github-ról.
Létrehoztam egy teszt-repót a github-on, azt svn-nel checkout-oltam (nem git-svn-nel), egy teszt-commit (svn commit...) minden hiba nélkül lefutott és a githubon is megjelent. Komolyabban nem teszteltem.
Legalábbis én erre gondoltam, azaz nem feltétlen kell svn-t git-re konvertálni, hogy a github-on tudd használni - talán ez nem volt egyértelmű (utólag visszanézve a hozzászólásom).
(Szerk.: feljegyzést írtam korábban, hogyan lehet egy svn repot githubra tükrözni, bár ehhez git is kell)
- A hozzászóláshoz be kell jelentkezni
Ja, csak akkor meg a history az ugrik. Meg minden jelenleg aktív hotfix és feature branch. Ott meg viszont a branchelések meg tudják kavarni az életet elég alaposan.
- A hozzászóláshoz be kell jelentkezni
igazi gcc sikersztori
- A hozzászóláshoz be kell jelentkezni
Vajon milyen szinu lett a biciklitarolo? :)
- A hozzászóláshoz be kell jelentkezni
lol, money time well spent
- A hozzászóláshoz be kell jelentkezni
remek forgatokonyv.
mikor mutatjak be a filmet ?
HUP te Zsiga !
- A hozzászóláshoz be kell jelentkezni
még nem dőlt el, hogy vígjáték lesz (az svn-t jim carrey játssza) vagy skandináv dráma.
- A hozzászóláshoz be kell jelentkezni
Az ilyenek végén szokás megkérdezni, hogy 'emlékszik még valaki, miért is kezdtünk bele?'
- A hozzászóláshoz be kell jelentkezni