26

Odp: MultiBASIC

by ten nie znalazł się w następnej :) - poza tym co - po każdym princie mam zamykać kanał, by uzyskać "koniec linii" ?? :D:D

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

27

Odp: MultiBASIC

Nie Pinek, tylko w ostatnim, przed zamknięciem kanału. Ale i tak chyba lepiej znaleźć EOF-a ;)

Sikor umarł...

28

Odp: MultiBASIC

kurde - niby prosta sprawa, a tyle z tym problemu. Ok - czyli pusta linia załatwiona, ale jak w takim razie zakończyć nadpisywaną linie? - tak, by różnica w ilości nadpisywanych danych w linii nie miała znaczenia...

heh;- ale dupa; teraz sobie tak myśle. Przecież i tak dane traktowane są jako całość/plik, więc można nadpisać, lecz jeśli danych będzie więcej, to pozostającej reszty "pliku" nie przesunie dalej, tylko zamarze tyle bajtów danych, o ile więcej danych nadpisujemy w danej linii. Czyli - chcąc coś nadpisać w takim przypadku, oraz chcąc mieć dowolność w kwestii dopisywania różnej ilości danych w linii trzeba rozwiązać sprawe starym sposobem. open source, open dest - i kopiowanie, a tam gdzie nadpisujemy zamiast ze source - dożucamy dane z programu, później kontunuacja kopiowania aż do EOF;-

Draco - masz jakiś pomysł na obejście problemu w MltBasic ??

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

29

Odp: MultiBASIC

Hmm, Pinek, jeżeli chcesz dopisać w środek - trza nową funkcję zaimplementować, nie takie głupie. Widzę to tak:
Open #chn,xx,0,"d:dupa.cośtam", gdzie:
#chn - wiadomo
0 - wiadomo
"d:..." - wiadomo
xx - nowy kod operacji: dopisz do pliku
Po takim wywołaniu - od wskazanego bajtu by dokładało w środek (to znaczy: tworzyło bufor do przekopiowania reszty). Kod mógłby wyglądać jakoś tak: (zakładam dopisanie od 5-go bajtu):

 
100 o.#1,xx,0,"d4:nadpisz.dta"
110 put #1,5: . 5 - piąty bajt, od tego miejsca dopisywanie
111 put #1,dane
112 cl.#1

Oczywiście, składnia open z numerem xx przyjmuje, że pierwsze put (jeśli nie chcemy tworzć dodatkowych instrukcji) mówi nam o kolejnym bajcie (lub linii - trza by ustalić) w pliku. Kolejne instrukcje - już standardowe - przesuwają kolejne elementy w środku pliku, aż do napotkania close.
Myślę, że tak by to można było zaimplementować, ale nie znam się na tym, więc musi się wypowiedzieć Draco. Oczywiście, to tylko taka mała sugestia...
Aha, w tym momencie nadal pozostaje nam open z parametrem 12 na nadpisywanie bez przerzucania...
Hmm, jeszcze jedno mi wpadło do głowy - Draco, nie da rady zrobić skróconej wersji open, np w postaci:

o.#1,xx

Dałoby to możliwość do operacji na pliku już otwartym, ale ze zmianą parametru? (np. otwieramy plik do zapisu, zapisuje się coś, trza zmodyfikować, więc zamiast ,8 dajemy ,12 i po sprawie)? xx oznacza tutaj standardowe kody open:
4 - otwarcie do odczytu
8 - do zapisu
12 - zmiana wewnątrz pliku...

Ostatnio edytowany przez Sikor (2005-08-19 12:14:48)

Sikor umarł...

30

Odp: MultiBASIC

ale w tym miejscu zmianie uległa by składnia instrukcji PUT - że tak powiem w standartowym układzie taka składnia opisuje zapis poprzez otwarty kanał na wskazane urządzenie jednego bajtu danych (od znacznika), czyli w tym wypadku jednobajtowa wartość /5/. Cięzko w MB by było traktować w specjalny sposób put występujący po open wywołanego wraz ze wspomnianym nowym auxem /XX/. Buforowanie końcówki pliku? - też bym się zastanawiał - bo co w przypadku, gdy końcówka pliku będzie równa 1MB? - heh;- nie na darmo powstała nowa koncepcja funkcji dla Sparta DOS X. nazywa się:  SET TEMP=path :) - serio. Będzie dodatkowy aux w tym celu dodany.

i tak sobie jeszcze myśle, że w pierwszym moim przykładzie - czyli tam, gdzie dopisujemy "$0000" itd. i tak - jeśli przyjmujemy, że dane nie są przesuwane - to coś się nie zgadza - bo wynik jest częściowo przesunięty, a częściowo "niewłaściwie" zamazany - czyli znikają nam potrzebne dane. Heh- myśleć, myśleć,. ..... . ..

Ostatnio edytowany przez Pin (2005-08-19 13:14:01)

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

31

Odp: MultiBASIC

Pinek: to nie musi być put, trza tylko określić standard. Może źle napisałem: buforowanie, chodziło raczej o przesunięcie "w locie". Można zamiast przez put ustawić się przez wczytanie iluśtam bajtów (bez sensu), lub przez pojechanie (z pominięciem odczytu - aby zwiększyć prędkość) do któregośtam bajtu w pliku. Put w tym momencie wydało mi się najrozsądniejszym wyjściem, choć przyznaję - nie do końca przemyślanym. Ale jak wiadomo, programy i sugestie rodzą się w bólach, nie mam koncepcji jaką instrukcję (znaną) zastosować. Hmm, może po prostu get?

get #1+bajt_do_którego_się_chcemy_dostać,adres_ulotny,0

Wymagałoby to tylko drobnej modyfikacji instrukcji get, a pozwoliłoby na ustawienie się na porządanym przez nas miejscu, a jednocześnie nie blokowało by pamięcio komputera (w przykładzie pobiera 0 bajtów z pliku, od miejsca, gdzie chcemy coś wstawić). Nie wiem, myślę, że jakoś to można rozwiązać... Pod rozwagę należy wziąć dokładnie ten moment:

 #1+bajt_do_którego_się_chcemy_dostać

, aby był wilk syty, i owca cała - jest to niejako kompilacja dyrektyw GET oraz MOVE, trza by tylko określić możliwość wykorzystania adresowania nie w pamięci komputera, a od znacznika początku pliku z danymi.
A co sądzisz o pomyśle użycia skróconego OPEN? (zmiana tylko atrybutu pliku, bez close)?

Sikor umarł...

32

Odp: MultiBASIC

no ale po kiego coś takiego, jeśli i tak w interesującej nas sytuacji ( :) ), choć i nie tylko - w celu ustawienia znacznika w pliku używa się instrukcji POINT, a do ew. zapisania tejże - NOTE.

Co do OPEN - zastanawiałbym się, czy ma to sens. Bo - w zasadzie można by powiedzieć, że potrzeba otwarcia pliku do R/W istnieje w opisanej powyżej sytuacji, a poza tym zastosowanie takiej składni można poddać wątpliwości sensu istnienia :) - nawet nie moge sobie teraz wyobrazić zastosowania takiej konstrukcji... tzn. jeśli chodzi o zmiane AUX1 bez zamykania IOCB. Bo teoretycznie - możliwość opcjonalnego skrócenia open o AUX2 nie jest głupim pomysłem.

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

33

Odp: MultiBASIC

Plik jest otwarty jednoczesnie do zapisu i odczytu. Wskaźnik pliku jest tylko jeden dla odczytu i zapisu. W programie odczytałeś 7 linijek (po 2 bajty każda), a potem zapisałeś 3 linie (po 6 znaków = 18 bajtów) i wcięło dokładnie tyle. Linie   8 - 14, to 19 bajtów, czyli o 1 więcej niż zapisałeś ciagiem $0000, $0001, $0002. Ten ostatni bajt to właśnie pusta linia.

Aleś Sikor wymyślił funkcje. Pokaż gdzie coś takiego masz. Należy się cieszyć, że system Atari ma w ogóle podział na pliki binarne i tekstowe. Do takich rzeczy jak wstawianie danych w środek pliku służą: katalog /tmp i pliki *.tmp. :P

Do MM:
Gdzie jest k*.* : twisted : ????????
I gdzie się podział k*.* : mrgreen :

Ostatnio edytowany przez Lizard (2005-08-19 14:27:21)

Zawsze mam rację, tylko nikt mnie nie słucha.

34

Odp: MultiBASIC

a fakt - bo jest w linii 1 - 7 i znak i eol... :ups: :) - zioło w tym roku mocne.

Lizard - mrgreen - nie musiałeś haczyć forum :) - (to żart)

Ostatnio edytowany przez Pin (2005-08-19 14:30:17)

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

35

Odp: MultiBASIC

A tak w ogóle, to mamy OT. Miał być MultiBasic, a jest TurboBasic. :P

Zawsze mam rację, tylko nikt mnie nie słucha.

36

Odp: MultiBASIC

nie - bo rozmowa dotyczy problemu, którego można uniknąć w MULTIBASICU :P hehe

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

37

Odp: MultiBASIC

Problem dotyczy systemu, a nie jakiegokolwiek basica. :P

Zawsze mam rację, tylko nikt mnie nie słucha.

38

Odp: MultiBASIC

Ale pisząc interpreter można błąd spaczować :P

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

39

Odp: MultiBASIC

Pin napisał/a:

Draco - a oto i przykładzik nieprawidłowego działania nadpisywania danych w pliku:

Nie widzę tu żadnego błędu, program zachowuje się dokładnie tak, jak mu kazałeś. Najpierw generujesz 15 "wierszy" tekstu (for b=1 to 15:? #1;b:next b), gdzie każdy wiersz zaczyna się od liczby zapisanej cyframi ASCII, a kończy się znakiem RETURN - bo tak działa instrukcja PRINT. Daje to plik tekstowy o długości 36 bajtów (9*2 + 6*3 = 36).

Następnie otwierasz tenże plik do wymiany danych, wczytujesz przez INPUT siedem pierwszych wierszy pliku. A więc w tym momencie znacznik odczytu i zapisu wskazuje na początek wiersza ósmego, tego zaczynającego się od cyfry "8". Dalej każesz zapisać trzy ciągi tekstowe "$0001", "$0002", "$0003". Ponieważ zapisujesz je instrukcją PRINT, więc każdy z nich kończy się przez znak RETURN, i ma nie pięć, tylko sześć znaków długości. Przeto ciąg binarny:

$38,EOL,$39,EOL,$31,$30,EOL,$31,$31,EOL,$31,$32,EOL,$31,$33,EOL,$31,$34,EOL,$31,$35,EOL

nadpisywany jest przez:

$24,$30,$30,$30,$31,EOL,$24,$30,$30,$30,$32,EOL,$24,$30,$30,$30,$33,EOL,EOL,$31,$35,EOL

Ostatni wiersz (ten zaczynający się od "15") wcale się nie przesuwa ani nie ma żadnych dodatkowych linii, ani nic niczego nie "wpi*". Po prostu koniec ostatniego ciągu hex (jego EOL) wypada w miejscu, gdzie poprzednio była cyfra "4" (ze stringu "14"). Dlatego masz ten odstęp. Ale nie ma tu żadnego błędu, wszystko jest OK, i nie ma czego paczować - moim zdaniem.

Jeśli chcesz uniknąć wpisywania przez system dodatkowych znaków EOL, to nie posługuj się trybem tekstowym (czyli instrukcją PRINT), lecz binarnym (czyli instrukcją PUT i BPUT).

Ostatnio edytowany przez drac030 (2005-08-21 18:02:24)

KMK
? HEX$(6670358)

40

Odp: MultiBASIC

Sikor napisał/a:

xx - nowy kod operacji: dopisz do pliku

Ten parametr funkcji OPEN decyduje tylko o kierunku przepływu danych, nie ma natomiast nic wspólnego z zagadnieniem, w którym miejscu pliku będziemy dopisywać (no, prawie - niektóre DOSy mają chyba tryb 9 - dopisywanie na końcu).

Oczywiście, składnia open z numerem xx przyjmuje, że pierwsze put (jeśli nie chcemy tworzć dodatkowych instrukcji) mówi nam o kolejnym bajcie (lub linii - trza by ustalić) w pliku.

Wymyśliłeś właśnie funkcję seek(). W Atari nazywa się ona POINT i pod SpartaDOS-em działa właśnie tak, że po otwarciu pliku przesuwasz "znacznik" wewnątrz pliku, od którego zacznie się następna operacja zapisu albo odczytu. Dzieje się to bez przesyłania danych. Poza tym definiowanie jakiegoś specjalnego PUT wprowadzałoby tylko bałagan - że nie wspomnę już o takim detalu, że argumentem PUT może być liczba z zakresu 0-255, średnio się ta funkcja więc nadaje do ustalania pozycji w pliku, bo pliki, jak wiadomo, mogą być dłuższe.

Aha, w tym momencie nadal pozostaje nam open z parametrem 12 na nadpisywanie bez przerzucania...
Hmm, jeszcze jedno mi wpadło do głowy - Draco, nie da rady zrobić skróconej wersji open, np w postaci:

o.#1,xx

Dałoby to możliwość do operacji na pliku już otwartym, ale ze zmianą parametru? (np. otwieramy plik do zapisu, zapisuje się coś, trza zmodyfikować, więc zamiast ,8 dajemy ,12 i po sprawie)? xx oznacza tutaj standardowe kody open:
4 - otwarcie do odczytu
8 - do zapisu
12 - zmiana wewnątrz pliku...

Wszystko się da, ale obawiam się, że zmianę atrybutu dostępu do pliku już otwartego źle może znieść DOS. Poza tym nie można przeprowadzić OPEN na otwartym pliku, to wymagałoby zbyt dużych zmian w ROM-ie i chyba nie jest potrzebne. Ostatecznie, jeśli przewidujesz, że plik będzie i czytany i zapisywany, to od razu możesz go otworzyć w trybie 12, bez kombinacji.

Ostatnio edytowany przez drac030 (2005-08-21 18:22:12)

KMK
? HEX$(6670358)

41

Odp: MultiBASIC

Pin napisał/a:

Draco - masz jakiś pomysł na obejście problemu w MltBasic ??

Raczej nie, interpreter tego za ciebie nie zrobi. Jeśli chcesz dostawiać wiersze tekstu w środek pliku, to trudno darmo, musisz kopiować. Ewentualnie możesz to jakoś załatwić znacznikami, to znaczy na początku pliku rezerwujesz miejsce na wskaźniki do poszczególnych wierszy (np. 256 wskaźników), i jak chcesz dopisać coś w środek, to dopisujesz fizycznie na końcu i tylko poprawiasz tablicę wskaźników tak, żeby przy sekwencyjnym czytaniu ta dopisana linia wypadała tam gdzie powinna. Oczywiście po jakimś czasie przy czytaniu takiego pliku "sekwencyjnie" głowica dysku będzie fruwać w tę i we wtę po całości, ale z twardzielem to nie taki znowu problem ;)

KMK
? HEX$(6670358)

42

Odp: MultiBASIC

drac030 napisał/a:

Ewentualnie możesz to jakoś załatwić znacznikami, to znaczy na początku pliku rezerwujesz miejsce na wskaźniki do poszczególnych wierszy (np. 256 wskaźników)

He he, a 256-ty wskaźnik będzie wskazywał na kolejną tablicę 256-u wskaźników. Łańcuszek szczęścia? Może się nie wysypie? ;) Ja bym to opatetował, zanim ktoś inny to zrobi. :)

Zawsze mam rację, tylko nikt mnie nie słucha.

43

Odp: MultiBASIC

Nie, tablica miała być jedna. Ale jak masz lepszy pomysł na uniknięcie kopiowania rekordów w sytuacji, kiedy potrzebujesz dostawić jeden w środku, to zamieniam się w słuch. Moim zdaniem inaczej niż za pomocą wskaźników tego się zrobić nie da. Można oczywiście rozłożyć je po całym pliku, tj. żeby każdy rekord miał nagłówek złożony ze wskaźnika do poprzedniego rekordu, wskaźnika do następnego rekordu, ilości danych no i bajtu statusu oczywiście. Tyle, że to zajmuje więcej miejsca i komplikuje trochę poprawianie łańcucha indeksów w przypadku dostawienia czegoś. Ale można i tak, rzecz jasna - wszystko zależy od potrzeb.

Ostatnio edytowany przez drac030 (2005-08-22 01:53:39)

KMK
? HEX$(6670358)

44

Odp: MultiBASIC

Już zrobiłem to inaczej :) - ponieważ musze podmienic część pliku /a/ na dane wprowadzone z zewnątrz, to poprawione dane kopiuje do /b.tmp/ na początek (bo kolejność nie gra mi tu roli), następnie z /a/ kopiren do /b.tmp/ wszystko z pominieciem części, której dotyczy zmiana, del"a", ren "b.tmp,a".... i działa. :).

.. a co do nadpisywania pliku; początkowo doszedłem do błędnych wniosków - w kwestii działania tegoż :) - zdarza się :D

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

45

Odp: MultiBASIC

No tak, ale najszybsze to to nie jest.

KMK
? HEX$(6670358)

46

Odp: MultiBASIC

w temacie multibasica podobałyby mi się jeszcze obliczenia na intach, może nawet o różnych rozmiarach

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

47

Odp: MultiBASIC

Inty się w innych basicach chyba oznacza przez % (np. WYNIK = 0 to real, a WYNIK% = 0 to int). W Acornie BBC taki int to liczba 32-bitowa ze znakiem. Jak proponujesz deklarować inty o różnej wielkości, albo np. ze znakiem i bez?

Ktoś wie, jak to jest zrobione w GFA?

KMK
? HEX$(6670358)

48

Odp: MultiBASIC

32bitowy int i tak bedzie szybszy niz reale. a dasz rade z parserem jesli masz tez operator '%'?

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

49

Odp: MultiBASIC

Parser to jest żaden problem.

KMK
? HEX$(6670358)

50

Odp: MultiBASIC

było kiedyś takie gówno jak qbasic i miało dużo różnych typów. dawno tym się nie bawiłem, ale można oblukać, jak to jest tam zrobione z deklarowaniem/oznaczaniem.
OPL na psion-y też miał % dla intów.

Ostatnio edytowany przez epi (2005-08-31 22:58:39)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.