Welcome, Guest. Please login or register.


Author Topic: EP128emu (Read 401776 times)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #495 on: 2016.August.01. 19:48:53 »
Oke, de ettol fuggetlenul az scons nem fogja elolrol kezdeni?

Csak a konfigurálást, az .o file-okat nem fordítja újra scons -c nélkül.

Egy másik lehetőség a CacheDir használata, például CacheDir("./build_cache") valahol az SConstruct elején. Ez minden a fordítás során generált file-t tárol a megadott könyvtárban (md5sum alapján), majd ha később azonos feltételek mellett ugyanazt a file-t kellene fordítani, akkor egyszerűen onnan másolja.

A CacheDir tartalma scons -c után sem veszik el.
« Last Edit: 2016.August.01. 19:52:56 by IstvanV »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #496 on: 2016.August.01. 20:11:52 »
Jó is a scons is installálásra, azt tudom, hisz van egy pár project, mely ezt használja.
Csak nem tudom, hogy nem lehetne e majd egyszerű környezeti változóval definiálni a cél installálási területet anélkül, hogy belerondítanék egy folttal a leendő scons install részbe?

Környezeti változó lekérdezésére már van példa a fenti néhány sorban, ahol az instDir $HOME/bin (instDir = os.environ["HOME"] + "/bin").

Quote
Azt is fel kellne sorolni valahol, hogy milyen fájlokat és hova telepítsen az insDirbe, ahhoz relatívan persze.

A példában ez az [ep128emu, makecfg, tapeedit] tömb. Idézőjelekben file nevek is megadhatók forrásként, ha ezeket nem az SConstruct generálja (pl. ikonok).

Több instDir is lehetséges, ilyenkor ezeket az Alias-nál tömbként kell megadni (pl. Alias("install", [instDir, instDir2])).

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #497 on: 2016.August.01. 20:37:41 »
Nekem semmi kedvem belerondítani a szépen megírt Sconstruct fájlba, biztosan elrontanám.
Eddig is meg tudtam csinálni az installállást is bash szkripttel, csak szebb és elegánsabb lenne, ha erre redukálható lemme:

export DESTDIR=${UB_INSTALLDIR}
scons   install

És ezzel egycsapásra minden cucc, ikonokkal, desktopokkal, binárisokkal, adatokkal együtt a helyére röppenne.

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #498 on: 2016.August.01. 22:22:01 »
Szerintem LGB meg tudná írni a makefilében az install részt linuxokra, az őhozzá még közelebb áll (hozzám is), mint a scons-ba belegyűrni a kívánalmakat.

Ez az install rész megcsinálná a kívánt könyvtárakat és odaröppentené a kívánt fájlokat.

Utána ezzel lehetne hívni minden disztrónál:

make DESTDIR="akármilyenhely" install

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #499 on: 2016.August.01. 22:35:02 »
Szerintem LGB meg tudná írni a makefilében az install részt linuxokra, az őhozzá még közelebb áll (hozzám is), mint a scons-ba belegyűrni a kívánalmakat.

Meg tudnam :) scons barmilyen jo, valahogy nem all a kezemre, de nyilvan szokas kerdese, meg hat nem is ertek hozza, lassuk be. Hiaba python, meg hiaba ilyenre vagytam mindig, hogy ne kelljen Makefile-ba script-eket eroszakolni neha :D meg hasonlok.

Valahogy kisse tulbonyolitott a dolog. Pl ez masik vesszoparipam, az arch. fuggo object file-ok. Probraltam a cache-dir-t de nem az igazi. -c -re nem torlodik, ugyanugy ganyolhatok kore script-et. Mert "make clean" hasonlo esetben viszont torolje ... Szerintem igy logikus. Raadasul egy csomo zavaro es fura uzenet jon, hogy visszaszedi cache-bol ... Es a cache-ben nem is normal file-kent van tarolva, nem tudok csak ugy belenezni, object file-t objdump-olni stb ... Szoval ez valahogy nem jon be. Marad az object file pre/postfix, de ott meg mindig nem tul szep, hogy az elejen a config-ot akkor is ujra csinalja, es nem tudja per arch letarolni. Szoval barhogy is nezem, nekem ez tul darabos. Pedig gondolom, hogy az en hozzaallasommal van baj, es lehet az nem termeszetes, amit en akarok :D

Lehet siman tul oreg vagyok en mar az ilyen ujhullamos tool-okhoz :D Ahogy pl a C++ sem jon be, mert nekem a C az a C ahogy isten megteremtette mindenfele plusszok nelkul ... :-/ Az meg mar egyesen elborzaszto, hogy ilyen youtube-os oktato videokban ami C-ben egy sima cast egy tipusra, oda C++-ban odairnak valami fel kepernyosornyi fortelmet, es buszkek ra, hogy megoldottak. Na ezt en mar nem ertem, hogy miert jo ennyire tulbonyolitani szandekosan :)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14739
  • Country: hu
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #500 on: 2016.August.01. 22:49:08 »
Én meg csak a kötőszavakat értem abból amit beszéltek :oops:

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #501 on: 2016.August.01. 23:03:55 »
Én meg csak a kötőszavakat értem abból amit beszéltek :oops:

:)

A C++ -os "szokasos kiborulasom" stilszeruen Enterprise-os (igaz, az urhajo) peldaval:

Scotty: The Enterprise. Show me the bridge of the Enterprise, you chatterin' piece of...
Computer Voice: There have been five Federation ships with that name. Please specify by registry number.
Scotty: N-C-C-1-7-0-1. No bloody A - B - C - or D!

:) En is igy vagyok vele. Sima, mezei, eredeti C, semmi ++ moge :) Bar a peldat nemikepp zavarja, hogy a fenti idezetben pont a C nem kell neki :D tobbek kozott ...

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1299
  • Country: hu
  • Stray cat from Commodore alley
Re: EP128emu
« Reply #502 on: 2016.August.02. 08:10:11 »
Ahogy pl a C++ sem jon be, mert nekem a C az a C ahogy isten megteremtette mindenfele plusszok nelkul ... :-/ Az meg mar egyesen elborzaszto, hogy ilyen youtube-os oktato videokban ami C-ben egy sima cast egy tipusra, oda C++-ban odairnak valami fel kepernyosornyi fortelmet, es buszkek ra, hogy megoldottak. Na ezt en mar nem ertem, hogy miert jo ennyire tulbonyolitani szandekosan :)
OFF

Azért jó túlbonyolítani, mert utoljára akkor van a program az ellenőrzésed alatt, amikor elindítod a buildelést. A C++ filozófiájának egy része, hogy a programot úgy írd meg, hogy elkerülöd a típuskényszerítéseket. Ha ilyen van a programban, akkor ott valamilyen elvi hiba húzódik meg vagy a program szerkezetében, vagy az adatstruktúrák absztrakciójában. A C++ erősebben típusos nyelv, mint a C. És persze hordozza az összes eszközt is amivel pusztító erővel lehet ágyékon rúgni az erős típusosságot, de ez más tészta.

Persze itt gondolom megjegyzed, hogy neked ne ugasson bele a nyelv, mert te úgyis jobban tudod, csak ez körülményektől függően elég sokszor nem így van. Azután meg ott van az is, hogy senki sem nélkülözhetetlen, vagy legalább is az alkalmazók – érthető módon – baromira nem szeretik a helyettesíthetetlenséget. Ha nincsenek garanciák arra, hogy a következő jézuska képes lesz hatékonyan folytatni az eltávozott munkaerő feladatait, akkor az jelentős veszteséget is okozhat, amitől a tulajdonosok és/vagy befektetők nagyon nem szoktak boldogok lenni. Ennek – mármint a hatékony fejlesztő csere lehetősége megvalósításának – egy része lehet a fenti alapelv.

Igen, minden magára valamit is adó cégnél létezik specifikáció, ami meghatározza hogyan kell programozni, de nem jobb ha ennek egy részét maga az alkalmazott programozási nyelv követeli meg/kényszeríti ki? Egyszerűbb lehet a kézikönyv, így nagyobb valószínűséggel fogja az alkalmazott a lefektetett irányelveket követni. Sőt, rendes helyeken van folyamatosan frissített projekt specifikáció is, de ugye azt is csak egy fejű, két kezű emberek csinálják. Nem sokkal hatékonyabb a munka, ha valamilyen változtatást nem sikerült rendesen végiggörgetni a teljes specifikáción, akkor egy belső teszt fordításnál ez rögtön kiugrik, nem kell nekihajtani a szoftvert a tényleges futtatási teszteknek?

ON

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #503 on: 2016.August.02. 08:23:38 »

Ahogy pl a C++ sem jon be, mert nekem a C az a C ahogy isten megteremtette mindenfele plusszok nelkul ...

Nem hiszem, hogy egy Makefile install rész-nek sok köze lenne a C++-hoz.
Magát a fordítást elvégzeztethető István jól megírt, habár öreg agyamat elborzasztó ( mivel nem értek hozzá) Sconsscriptje, az installálási fázist meg LGB leendő ragyogóan megírt Makefile install része.

Vagy esetleg CmakeFiles.txt ? :idea:

Én arra hajlanék, hogy a cmake-val lenne jó elvégeztetni minden Makefile generáltatást, ehhez csak jól megírt CmakeFiles.txt kellne, melyhez sajnos szintén nem értek, csak tudom, hogy az a menő manapság, főleg a keresztfordításokhoz, mindenféle operációs rendszerhez.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #504 on: 2016.August.02. 08:59:24 »
Nem hiszem, hogy egy Makefile install rész-nek sok köze lenne a C++-hoz.

Nincs is. Csak a szokasos hulyesegem, hogy elkalandoztam :)

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #505 on: 2016.August.02. 09:39:45 »
Ja, közben a romhalmazt elhelyeztem a gitt forkomba, talán a megfelő helyre és küldem Pull request -et a fő gittbe.
Ez is nélkülözhetetlen a működéshez. Mármint a romhalmaz, amik remélem, hogy már nem jogvédettek.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #506 on: 2016.August.02. 12:40:36 »
Ha már az ep128emu a GitHub-ra került, akkor a teljesség kedvéért plus4emu is lehetne. :) Itt több lehetőség is van a fejlesztésre, például a debugger GUI kissé elavult az ep128emu-hoz képest, viszont ez az emulátor tartalmaz C API-t SDL példa programmal. Nagyobb kihívást jelentene a két emulátort újra egy programba építeni, az ep128emu 2.0 beta verzióhoz hasonlóan.

https://github.com/lgblgblgb/plus4emu

Csak ugy kivancsisagbol :) Igaz, szokasos C++ elmebajom miatt amugy se mennek sokra ezzel se, nomeg le sem fordul (es otletem sincs mit jelent a hibauzenet):

Code: [Select]
g++ -o util/compress/compress0.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -DHAVE_DOTCONF_H -DHAVE_SDL_H -DENABLE_GL_SHADERS -DFLTK1 -I. -Isrc -IFl_Native_File_Chooser -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Iutil/compress util/compress/compress0.cpp
util/compress/compress0.cpp:607:3: error: 'Plus4Compress::Compressor_M0::CompressionParameters::CompressionParameters' names the constructor, not the type
   Compressor_M0::CompressionParameters::CompressionParameters&
   ^

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1299
  • Country: hu
  • Stray cat from Commodore alley
Re: EP128emu
« Reply #507 on: 2016.August.02. 13:09:01 »
https://github.com/lgblgblgb/plus4emu

Csak ugy kivancsisagbol :) Igaz, szokasos C++ elmebajom miatt amugy se mennek sokra ezzel se, nomeg le sem fordul (es otletem sincs mit jelent a hibauzenet):

Code: [Select]
g++ -o util/compress/compress0.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -DHAVE_DOTCONF_H -DHAVE_SDL_H -DENABLE_GL_SHADERS -DFLTK1 -I. -Isrc -IFl_Native_File_Chooser -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Iutil/compress util/compress/compress0.cpp
util/compress/compress0.cpp:607:3: error: 'Plus4Compress::Compressor_M0::CompressionParameters::CompressionParameters' names the constructor, not the type
   Compressor_M0::CompressionParameters::CompressionParameters&
   ^
Megnézni nem fogom rendesen, de arra panaszkodik, hogy típus helyett egy konstruktor kapott, vagis hogy ezt jelenti a hibaüzenet. Meg lehet próbálni javítani a kifejezés végére '&' jel biggyesztésével, de miután nem néztem meg, fogalmam sincs használ-e?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #508 on: 2016.August.02. 13:29:56 »
https://github.com/lgblgblgb/plus4emu

Csak ugy kivancsisagbol :) Igaz, szokasos C++ elmebajom miatt amugy se mennek sokra ezzel se, nomeg le sem fordul (es otletem sincs mit jelent a hibauzenet):

Code: [Select]
g++ -o util/compress/compress0.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -DHAVE_DOTCONF_H -DHAVE_SDL_H -DENABLE_GL_SHADERS -DFLTK1 -I. -Isrc -IFl_Native_File_Chooser -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Iutil/compress util/compress/compress0.cpp
util/compress/compress0.cpp:607:3: error: 'Plus4Compress::Compressor_M0::CompressionParameters::CompressionParameters' names the constructor, not the type
   Compressor_M0::CompressionParameters::CompressionParameters&
   ^

Ez egy egyszerűen javítható hiba, a Compressor_M0::CompressionParameters::CompressionParameters& helyett Compressor_M0::CompressionParameters& kell. Ha máshol is előfordul ez a hiba, akkor ugyanígy javítható. Meglepő, hogy a GCC régi verziói ezt elfogadták. :oops: Egyébként az epcompress forráskódja is tartalmaz(t)a ezt a hibát.

Ha már epcompress, akkor a teljesség kedvéért még ez és az egyéb segédprogramok (epimgconv, dtf, stb.) is a GitHub-ra kerülhetnének, talán egy "ep-utils" vagy hasonló csomag részeként. :)
« Last Edit: 2016.August.02. 13:33:21 by IstvanV »

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #509 on: 2016.August.02. 14:20:29 »
Ja, közben a romhalmazt elhelyeztem a gitt forkomba, talán a megfelő helyre és küldem Pull request -et a fő gittbe.
Ez is nélkülözhetetlen a működéshez. Mármint a romhalmaz, amik remélem, hogy már nem jogvédettek.
A békesség és jogviták elkerülése végett inkább visszacsináltam.
Majd a júzer fogja magának letöltögetni őket, vagy egy, a githubba rakott wrapper segítségével, vagy anélkül a kívánatos helyre, ha használni is akarja az emulátort .
Így egyedileg fogja majd az esetleges jogvitákat elszenvedni, ha lebukik, hogy jogvédett ROM-ot használ a ROM alkotóinak tudta és engedélye nélkül.