Hírek | Archívum | Fórum | IRC | Amiga | AmigaOS | FAQ | RSS

 - Fórumok - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
<< 1 ... 9 . 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17 . 18 . 19 ... 24 . 25 . >>
Szerző Üzenet
AliveMOon
Tag

# Elküldve: 2019. Máj. 16. 07:27 - Szerkesztve: alivemoon


Quoting: charlie
Másként nem kéne pl. \ karaktert használni sorfolytatónak bizonyos esetekben.



Visual c-ben semmi gondja nincsen vele ha pl.
char sSTR[] = "Ez egyetlen "
"string lesz "
" a kódban.";


Viszont már nem lehet inline asm-ot írni, külön asm forrást kell írni és mondjuk extern "C" float4* gp_f44_qlen( float4* p_s ); nel lehet használni.

Dodi
Tag

# Elküldve: 2019. Máj. 16. 19:05


lemezmelléklet: http://amiga.uw.hu/melleklet.html
korlátozott ideig

Yellow Dog
Tag

# Elküldve: 2019. Máj. 16. 19:47


Köszönöm!

dh1
Mr. DTP

# Elküldve: 2019. Máj. 17. 20:46


Danke!

Yellow Dog
Tag

# Elküldve: 2019. Máj. 22. 17:57 - Szerkesztve: yellowdog


Pár kérdésem volna: C-ben vagy akár assembly-ben milyen függvénnyel tudok a könyvtárból egy szintet feljebb lépni, Illetve mivel tudom megnézni, hogy éppen mi az aktuális elérési út, valamint az elérhető meghajtók listáját hol találhatom?
Köszönöm

Rágom a doksikat, de ezekre nem lelem a választ...

Chain-Q
Divatamigás

# Elküldve: 2019. Máj. 23. 15:29 - Szerkesztve: charlie


mivel tudom megnézni, hogy éppen mi az aktuális elérési út,

Marmint hogy milyen konyvtarak vannak a PATH-on (erre nincs egyszeru megoldas, amugy, csak mindenfele takolassal lehet), vagy hogy milyen konyvtarban vagy eppen? Ha utobbi, akkor nincs ra egy fuggveny, ellenben a dos.library/CurrentDir() fuggveny miutan uj eleresi utat allitott be, visszaad egy a korabbi konyvtarra mutato file lock-ot. Ebbol a lock-bol aztan dos.library/NameFromLock()-kal tudsz stringet csinalni (ha pl. ki akarod iratni), vagy egy ujabb CurrentDir-rel visszaalltani. Pl.

my_path_lock = CurrentDir(null); // korabbi path lekerdezese es gyokerre valtas
CurrentDir(my_path_lock); // visszaugras a korabbi konyvtarba

A null valid parameter a CurrentDir()-hez, es csak az aktualis meghajto gyokerkonyvtarat jelenti.

Ha csak az aktualis konyvtar neve kell string-kent, akkor 2.0 felett a dos.library/GetCurrentDirName() is hasznalhato.

milyen függvénnyel tudok a könyvtárból egy szintet feljebb lépni,

A fent leirt modon a CurrentDir()-tol megszerzett Lock-kal meghivod a dos.library/ParentDir()-t, szerintem, kb...

az elérhető meghajtók listáját hol találhatom?

Erre csak 2.0-tol felfele van modszer, egyebkent a DOS belso pointerlistajan kell vegigmenni Forbid/Permit kozott... Reszletek a 2.0-tol hasznalhato dos.library/LockDosList() fuggveny manualjaban vannak, ahol van egy 1.3-mal kompatibilis rovid pelda is, ami legalabb koncepcio szintjen hasznalhato:

http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0187.html

Chain-Q
Divatamigás

# Elküldve: 2019. Máj. 23. 16:03


Ja es vigyazat, nehany dolog az ilyen konyvtarvaltogatas meg rendszerbol kinyeres teren teljesen mashogy mukodik ha Workbench alol inditod a programod, mintha CLI-bol inditod, szoval nem biztos h. erdemes elterni attol ami ajanlott, meg akkor is ha 'egyszerubbnek' tunik. Pl. a parancssorbol inditott programoknak van CLI struktura, amibol egy csomo minden kinyerheto, de ez pl. Workbenchbol inditasnal nincs jelen! Stb. Eleg macera. Az AmigaDOS amilyen sokoldalu sok szempontbol annyira felkesz is, foleg a korai verziok.

Yellow Dog
Tag

# Elküldve: 2019. Máj. 23. 17:04


Köszönöm a részletes magyarázatot, pont ezeket a dolgokat szerettem volna megtudni.

YADA
Tag

# Elküldve: 2019. Máj. 24. 08:21


Igen, assembly/c/pascal alatt en is a DosList strukturak segitsegevel kezeltem annak idejen, mint egyetlen valoban mukodo kb mindennel kompatibilis lehetoseget hasznalva. Sajat listakat epitve, a forbid/permit parosra nem emlekszem hogy kellett, de ha irja a doksi akkor kellett.

A drive lista is hasonloan megy, de emlekeim szerint a device/logicalname/assign lista csak valami flag alapjan volt elkulonitheto a teljes listabol (celszeruen szurve ra vagy flag alapjan megjelolve a tipusat kiiraskor)

Sajnos nem hinnem, hogy barmi kodom is fennmaradt abbol a korszakbol, egy hatalmas backuppal egyutt ment a levesbe. Forraskod reszeleteket mar talaltam lemezeken kutatva, de semmi hasznalhato nem elte tul a backupot.
Mindnesetre a sajat kod maradvanyokat nezve el sem hittem, hogy en irtam azokat valaha.

Yellow Dog
Tag

# Elküldve: 2019. Máj. 24. 09:49 - Szerkesztve: yellowdog


Sajnos a helytelen tárolás miatt nekem is tönkrement az összes lemezem, játékok és a saját dolgokat tartalmazók is, ráadásul a drive-okat is tönkretették amikor pár éve szerettem volna megnézni őket. Szerencsémre van egy 96-os (nevezhetjük) backup CD-m de sajna minden nem került rá, igaz azért pár (assembly) programom megvan illetve a minek leginkább örülök, egy kígyó játék félkészen... Talán egyszer befejezem, de nyilván soha sem ;-)

sZamu
Tag
# Elküldve: 2019. Máj. 24. 19:49


Mit jelent a helytelen tárolás? Csak mert én ma autóztam közel 300 km-t, és vettem egy Amiga 500-ast, hogy meg tudjam nézni a régi lemezeimet, akkor lehet, hogy hiába?

Yellow Dog
Tag

# Elküldve: 2019. Máj. 24. 22:35


Quoting: sZamu
helytelen tárolás?

Másfél évnyi tárolás szigeteletlen, nyirkos garázsban....

Yellow Dog
Tag

# Elküldve: 2019. Nov. 09. 14:45


Kliens programot írok PC - Amiga fájl átvitelhez (USB) és szeretném megkérdezni, hogyan oldható meg, hogyan illik megoldani a többszörös kijelölés esetén a fájlok másolását? Nem szeretném feltalálni a "spanyol viaszt" az szeretném megtudni, milyen elven van ez megvalósítva úgy általában, OS-től függetlenül, tehát a logika érdekelne.
Köszönöm

Chain-Q
Divatamigás

# Elküldve: 2019. Nov. 09. 19:34


@Yellow Dog:
Eloszor is, mivel ez egy fejlesztesi kerdes, es nem felhasznaloi szintu atraktam ebbe a topicba.

Masodszor - nem ertem a kerdest. Nyilvan tobb fajl egyideju kezelesere es odebb-masolasara nem igazan van OS fuggveny, plane nem valamilyen custom USB atviteli megoldashoz, szoval feltetelezve h. az OS-tol/felhasznalotol kapsz egy fajllistat, amit aztan siman egyesevel beolvasol es atkuldesz a tuloldalra.

A legprimitivebb megoldas pedig tenyleg ez, hogy csak beolvasod a fajlokat egyesevel aztan csinalsz a bajtokkal amit akarsz (pl. atkuldod akarhova) aztan kesz. Esetleg meg ajanlott valamifele protokolt feltalalni a fajlattributumok/protection bitek atkuldesere. Aztan ezt ciklusban amig elfogynak a fajljaid. Nyilvan a konyvtarak es egyeb specialis esetek kezelesere is fel kell talalni valamit.

Az ennel egyel fejlettebb megoldas, hogy foglalsz egy valamekkora (visz. nagy) buffert a RAM-ban, aztan ebbe kopizod az eppen atkuldendo adatmennyiseget, es lekezeled h. akar egynel tobb fajl adatai is lehetnek ebben a bufferben. Ez azert jo, mert a sok kicsi fajl vs. egy nagy fajl atviteli sebessege nem lesz tulzottan kulonbozo. Nyilvan itt is meg kell oldani az attributumok es a konyvtarak (vmit egyeb specialis allomanyok, pl. link, ha erre igeny van) atvitelet is.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 09. 20:21 - Szerkesztve: yellowdog


Sajnos én sem találtam OS szintű támogatást, ezért kérdeztem, mi ennek a korrekt megoldása. Nem is az USB a lényeg, a fájl lista a kijelölt fájlok feldolgozása amire szeretnék ötletet, vagyis a bevált módszer érdekelne. Több fájl kijelölése okés, a kijelölt fájlok listáján végigmenve sorban történik egy másolás, de mi a helyzet ha egy könyvtár van kijelölve, amely mondjuk nem csak fájlokat tartalmaz, hanem további könyvtárakat, amelyek szintén fájlok mellett további könyvtárakat tartalmaznak? Na itt akadtam el, erre szeretnék egy algoritmust vagyis mi a logikája?

Yellow Dog
Tag

# Elküldve: 2019. Nov. 09. 20:21


Quoting: charlie
mivel ez egy fejlesztesi kerdes, es nem felhasznaloi szintu atraktam ebbe a topicba

Rendben, köszönöm.

Chain-Q
Divatamigás

# Elküldve: 2019. Nov. 09. 21:27 - Szerkesztve: charlie


Fastruktura (értsd: könyvtárstruktúra) bejárásához ugye valamiféle rekurzív algoritmus a könyvi példa. Tehát nagyjából így (nagyon primitíven, egy csomó határesetet nem kezelve):

fuggveny utvonal_feldolgozasa(eleresi_ut)
....lista = fajllista_lekerese(eleresi_ut)
....ciklus listaelem a listaban:
.........ha eleresi_ut_tipusa(listaelem) == konyvtar akkor
..............utvonal_feldolgozasa(eleresi_ut + listaelem) // itt a rekurzio, meghivjuk onmagunk
.........egyebkent
..............egyeb_muvelet(eleresi_ut + listaelem)
....ciklus vege
fuggveny vege

Végül meghívod ezt valami bemeneti fájllista elemeire egy ciklusban.

Amúgy megoldható a dolog rekurzió nélkül is, de az elég macerás... Csak a rekurziónál ugye arra kell figyelni, főleg amigán, hogyha nagyon nagy mélységben dolgozol fel könyvtárat akkor kifuthatsz a stackből. Erre a favágó primitív megoldás ha beleírod a readme-be az usernek h. a programod futtatása előtt adjon neki nagy stacket, a jó megoldás meg az ha megoldod a stackswapet magad induláskor, ha túl kicsi a stack. :P És még ilyenkor is ajánlott stack-ellenőrzést építeni a programba. Nem mondom, hogy a Free Pascal ezt mind megcsinálná neked, de ha magad akarod, akkor ez egy ilyen szakma... :)

Összefoglalva, én azt ajánlom, próbaként írj magadnak egy saját "list" paranccsot. Ami kilistázza az összes alkönyvtárat. Ezzel remekül tesztelheted majd az algoritmusod, és utána csak a másolást kell beleépíteni.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 09. 23:03


Igen, köszönöm, így érthető!

Yellow Dog
Tag

# Elküldve: 2019. Nov. 09. 23:08


Quoting: charlie
ajánlott stack-ellenőrzést építeni a programba

Lehet valahol olvasni Amiga fájlrendszer korlátokról, könyvtárak egymásba ágyazhatósága, fájlnév hossz és hasonlók, mert nem nagyon találom.

Chain-Q
Divatamigás

# Elküldve: 2019. Nov. 10. 00:53 - Szerkesztve: charlie


Nemigazán van erről perdöntő infó, mert rengeteg minden fájlrendszer függő, de egy rakás limit jön magából az AmigaDOS-ból is.

A maximum fájlnév hossz 107 karakter(+ asszem zéró terminálás) lehet, az LhA manuáljában találtam rá utalást, hogy legalábbis egyes AmigaDOS verzióknak gondja van a 180-190 karakternél hosszabb elérési utakkal (a fájl nevét is beleértve). Gondolom ez tesztelhető is, ha valaki nagyon akarja, de persze ez is lehet fájlrendszer függő is. Ezen kívül van ugye fáljkomment is amigán, ami max. 80 karakter lehet. Nyilván az egymásba ágyazhatósági korlátot meg diktálja maga a maximális path hossz.

Én az FPC-ben arra építettem, hogy a maximális név és path hossz mindenhol max. 255 karakter lehet. Eddig még nem volt róla bugreport (de ha valaki tesztesettel bizonyítja, hogy ez hülyeség, kijavítom).

Yellow Dog
Tag

# Elküldve: 2019. Nov. 10. 08:58 - Szerkesztve: yellowdog


Én is 255 byte elérési út és szintén 255 byte fájlnév buffert választottam, akkor ezzel nem lőttem nagyon mellé, illetve ezek szerint elegendőnek kell lenni :-)
De azért kíváncsiságból teszek pár próbát, pl. azt jó lenne még tudni, mennyi könyvtár ágyazható egymásba illetve mely karakterek használhatók és melyek nem. Ez utóbbi még megér egy misét, mert az angol még oké, de mi van a magyar karakterekkel, főleg a hosszú ű ő és hasonlókkal?

szerk.
Ebből sok minden kiderül:

STRUCTURE FileInfoBlock,0
LONG fib_DiskKey
LONG fib_DirEntryType ; Type of Directory. If < 0, then a plain file.
; If > 0 a directory
STRUCT fib_FileName,108 ; Null terminated. Max 30 chars used for now
LONG fib_Protection ; bit mask of protection, rwxd are 3-0.
LONG fib_EntryType
LONG fib_Size ; Number of bytes in file
LONG fib_NumBlocks ; Number of blocks in file
STRUCT fib_DateStamp,ds_SIZEOF ; Date file last changed.
STRUCT fib_Comment,80 ; Null terminated. Comment associated with file

; Note: the following fields are not supported by all filesystems.
; They should be initialized to 0 sending an ACTION_EXAMINE packet.
; When Examine() is called, these are set to 0 for you.
; AllocDosObject() also initializes them to 0.
UWORD fib_OwnerUID ; owner's UID
UWORD fib_OwnerGID ; owner's GID

STRUCT fib_Reserved,32
LABEL fib_SIZEOF ; FileInfoBlock

AliveMOon
Tag

# Elküldve: 2019. Nov. 10. 11:22 - Szerkesztve: alivemoon


Minden rendszerrel amivel dolgoztam, meg van adva a MAX_PATH vagy valami hasonló én azokat szoktam megkeresni és használni. Akkor ninncsen meglepi. Ha jól emlékszem linux on vagy 4kiló, gondolom az utf-8 miatt mert ott egy karakter akár 4byte is lehet.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 10. 11:23


Und vó iszt in Amiga rendszerben?

AliveMOon
Tag

# Elküldve: 2019. Nov. 10. 11:44 - Szerkesztve: alivemoon


Amiga sdk: The maximum length of a standard Shell command line is 512 characters

Azaz egy dos parancs sorba 4x256 - (nORDER+nKEY) ASCII fér?

LINUX on a limit.h ban vannak, én azt csinálnám, ha amigán nincs, hogy venném a linuxos h-t és ha Amigan sok, vagy kevés akkor azt #ifdef AMIGA-vel kiegészíteném

És használnám a LINUX deffinicióit

Chain-Q
Divatamigás

# Elküldve: 2019. Nov. 10. 12:13 - Szerkesztve: charlie


Már megint brillírozunk, édes istenem.

Minden rendszerrel amivel dolgoztam, meg van adva a MAX_PATH vagy valami hasonló

vs.
LINUX on a limit.h ban vannak, én azt csinálnám, ha amigán nincs


Az egyetlen logikus konklúzió: AliveMOon még sosem dolgozott amigával.

Amúgy a PATH_MAX egy POSIX definíció, az Amiga meg nem POSIX rendszer. Bónusz ráadás: A PATH_MAX define használata a legtöbb POSIX rendszerben (a Linuxot is ideértve) broken by design, szóval használata a javasolt formában nem ajánlott.

Következésképpen - lehetne hogy egy Linuxon is broken koncepciót nem hozunk be Amigára? :) (Főleg, hogy emberünk amúgy nem is C-ben kódol, hanem assemblyben.)

Ettől függetlenül persze valamiféle definíció a jól jön a PATH-ek hosszára, de hogy ennek mi köze a Linuxhoz... Rejtély. :)

Szerk: mellékesen Windowson is broken a cucc, mert Windows-specifikus MAX_PATH define 260 karaktert ad meg, miközben az NTFS max. 32K karakter hosszú elérési utakat is támogat. Erre a problémára pedig feltaláltak valami ritka gusztustalan "extended path" hacket, mivel Microsoft. Szóval ahem, ja. Jó tanács sose rossz, kivéve ha mégis.

Szerk 2: Gyorsan körbetúrtam az Amiga SDK-t, az egyetlen hasonló PATH-hossz limitet a diskfont.library headerjében (diskfont.h ill. diskfont.i) találtam, amelyik szimplán 256 karaktert definiál a hosszra (beleértve a zeró terminálást is) a MAXFONTPATH define-nal. Szerintem ha a diskfont.library-nak elég jó így, akkor az alkalmazásodnak is jó lesz az a hardwired 256 limit. :)

AliveMOon
Tag

# Elküldve: 2019. Nov. 10. 12:32 - Szerkesztve: alivemoon


Quoting: charlie
Amúgy a PATH_MAX egy POSIX definíció

Ezért írtam, valami hasonló, mert mondjuk a dos/dos.h-ban van olyan, hogy " char fib_FileName[108];"
dos.i-ben ugyan ez: STRUCT fib_FileName,108 ; Null terminated. Max 30 chars used for now, de később?

azaz lehet mondjuk ezt alapul venni. azaz filenévnek a dos ezek szerint 108 byte-ot el tud tárolni.

#define MAX_nFILE 10
#define MAX_lFILE sizeof(fib_FileName)
#define MAX_PATH MAX_nFILE*MAX_nFILE

És van egy saját MAX_PATH-od.

Chain-Q
Divatamigás

# Elküldve: 2019. Nov. 10. 12:34 - Szerkesztve: charlie


Az csak a fájlnév. Nem tartalmazza az elérési utat. Továbbá a "max 30 chars used for now" komment a 25 évvel ezelőtti FFS-re vonatkozik, nem a modern FS-ekre (PFS, SFS, FFS2, stb), nyilván.

AliveMOon
Tag

# Elküldve: 2019. Nov. 10. 12:35 - Szerkesztve: alivemoon


Quoting: alivemoon
#define MAX_nFILE 10

ezt akorára definiálod amekorára akarad, de ha a dos.h ban változik a 108 egy meglepivel kevesebb.

Chain-Q
Divatamigás

# Elküldve: 2019. Nov. 10. 12:37


Aki ilyet csinál C programozó a csapatomban, kirúgom. Csak mondom.

AliveMOon
Tag

# Elküldve: 2019. Nov. 10. 12:40 - Szerkesztve: alivemoon


Az én javaslatom 10 mélységig biztos jobb mint beírni valami konstans értéket.
Nyilván sokkal jobb, ha azt javaslod hogy írjanak fix értéket oszt csókolom és nem adjanak esélyt a későbbi fejlesztéseknek, gratulálok :)

<< 1 ... 9 . 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17 . 18 . 19 ... 24 . 25 . >>
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
 
 

Powered by web forum software miniBB™ © 2001-2024