HF5BS pisze:

>>> potrafi się skompilować do ponad megabajta... Ki diabeł?
>> Nie diabeł, tylko interpreter. To, że coś stało się plikiem wykonywalnym,
> Mnie akurat chodzi o kompilację.

No to trzeba wziąć coś innego niż basic. Ten do kompilacji się nie
nadaje. Chyba, że ja czegoś nie wiem.

>>> Skoro w kompilatach osadza się rzeczy, których przez 25 lat ani
>>> jedna osoba na świecie, ani razu nie użyje, a świrus zainfekuje
>>> i się rozstrzeli, bo dołączony śmieć ma dziurę, której nikt nie
>>> zauważył poza crackerami i hackerami.
>> Nie, w kompilatorach tak nie jest, nie osadza się nadmiarowych rzeczy.
>
> Jarku, drobna różnica - "w kompilatach" vs "w kompilatORach"...

W kompilatorach tak nie jest, żeby osadzały [one] nadmiarowe rzeczy
[w kompilatach]. Tak lepiej?

>> Pozwoliłem sobie nieco zmodyfikować poprzedni kod (mam nadzieję, że
>> licencja tego nie zabrania). Wygląda teraz tak:
>
> To jeden z programików że tak powiem, szkoleniowych, gdy ktoś zaczyna
> w tymże programować. Moje dialekty na PC, traktują numer linii nie
> jako numer, lecz etykietę, równoważną np., ":dupa", wtedy, np. robiąc
> podprogram, robisz nie "GOTO 20", lecz "GOTO dupa", to samo także z GOSUB.
> Nie ma na niego żadnej licencji.

Interpreter i tak sobie te linie ponumeruje po swojemu w pamięci.

>> 10 k=0 ! linia zbędna, ale co mi szkodzi sieknąć komentarz
>
> A Róbta Co Chceta panie, byle program chodził.
>
>> 20 k=k+1
>> 30 PRINT *, k
>
> Nie mam w swoich dialektach wersji z gwiazdką... zamiast spacji?
> Niektóre wykonania, zależnie od dialektu, nie wstawiają spacji
> przed liczbą dodatnią, a jak już mam "nasrać", to "nasrać" choćby
> z odrobiną elegancji, by każda kup...wróć, liczba, miała odstęp
> jednej spacji od kolejnych.

To nie jest gwiazdka zamiast spacji. To jest gwiazdka oznaczająca
"format swobodny" wydruku. Zamiast niej mogłaby być tam etykieta
wskazująca na wiersz z dyrektywą "FORMAT" opisującą sposób druku.

>> 40 GO TO 20
>> 50 END
>
> Nie skompiluje się bez END?

Nie.

>> Zapisałem to w pliku "hf5bs.f", a następnie wydałem zaklęcie:
>>
>> gfortran hf5bs.f -o hf5bs
>
> Acha, bo to Fortran...

Wybrałem fortran, bo (jak widać) jego kod jest często identyczny
z basikiem. Gdy po raz pierwszy zobaczyłem basic, pomyślałem sobie
o niem, że to taki uproszczony fortran, który można interpretować
zamiast kompilować. W prostych komputerach ośmiobitowych miało to
sens. Dlaczego dzisiaj wciąż ktoś męczy ten basic -- tego nie wiem.

> Ponoć dobrze się nadaje do obliczeń na liczbach zespolonych?

Też. Ale python również ma typ liczb zespolonych. Fortran nadaje się
do kompilowania dawno napisanych (i dobrze przeterstowanych) źródeł
i łączenia tego z nowym kodem w nowych językach. W fortranie nikt
już chyba nic nie pisze, bo co było potrzebne, dawno napisano.

>> Skompilowało się do pliku "hf5bs" o długości 8968 bajtów. Działa.
>> Następnie "strip hf5bs" -- i już jest 6352. Też działa.
>
> I o to chodzi. Pewnie jakieś drobne procedurki, trudno, przeboleję,
> ale nie 2 mega...

Z językami interpretowanymi nie da się inaczej.

> Tak mi zostało po sytuacji, gdy działałem, a do dyspozycji, jeszcze
> przed C64, miałem ledwie 3.5 kB RAM (VIC-20 bez rozszeszeń pamięci),
> a kładłem na tym programy znacznie bardziej skomplikowane i musiałem
> się postarać, aby się zmieściły i ruszyły.

Za to w językach interpretowanych zapisany kod może być bardzo mały.
Interpreter siedzi sobie w ROM i interpretuje.

--
Jarek

do góry

On 2018-09-20, Queequeg <q...@t...no1> wrote:
> J.F. <j...@p...onet.pl> wrote:
>
>>>Pytanie czy drukarka czy driver. Nie wiem niestety na ile producenci
>>>mają dowolność w przenoszeniu renderowania do drivera.
>>
>> Klient moglby sie troche wk*, gdyby kupil drukarke z PS, i sie
>> dowiedzial, ze taka dostal, ale musi drukowac przez Windows.
>> A on kupil z PS, bo nie ma Windows ...
>
> Ja się zawsze upewniam, czy są do mojego sprzętu drivery dla Linuksa :)

Można się czasami przejechać ale też o różnych producentach sporo
dowiedzieć. Kupiłem żonie do firmy parę lat temu laserówkę Canona,
właśnie dlatego, że miała mieć sterowniki pod Linuksa (tak stało na ich
stronie). Okazało się, że nie miała. Canon stanął na wysokości zadania i
dał nam, do czasu gdy sterowniki będą dostępne, zastępczo lepszy model
włączając w to toner. Pół roku im to zajęło.

> Jeśli jest driver, to niech on renderuje PS lub robi co uważa za stosowne.
> Jeśli nie ma, to nie chcę takiego sprzętu.
>
> To, o czym mówisz, skojarzyło mi się z winmodemami.

Nie nazywało się to czasami GDI printer?

--
Marcin

do góry

Dnia Thu, 20 Sep 2018 23:20:21 +0200, Jarosław Sokołowski napisał(a):
> HF5BS pisze:
>>>> potrafi się skompilować do ponad megabajta... Ki diabeł?
>>> Nie diabeł, tylko interpreter. To, że coś stało się plikiem wykonywalnym,
>> Mnie akurat chodzi o kompilację.
>
> No to trzeba wziąć coś innego niż basic. Ten do kompilacji się nie
> nadaje. Chyba, że ja czegoś nie wiem.

Czemu nie ? Nadaje sie podobnie jak inne jezyki.

>> Acha, bo to Fortran...
>
> Wybrałem fortran, bo (jak widać) jego kod jest często identyczny
> z basikiem. Gdy po raz pierwszy zobaczyłem basic, pomyślałem sobie
> o niem, że to taki uproszczony fortran, który można interpretować
> zamiast kompilować.

A czemu by fortranu nie interpretowac ?

> W prostych komputerach ośmiobitowych miało to
> sens. Dlaczego dzisiaj wciąż ktoś męczy ten basic -- tego nie wiem.

Microsoft ?
Ale ... dzisiejszy Basic sie az tak bardzo od innych jezykow nie
rozni.

>> Ponoć dobrze się nadaje do obliczeń na liczbach zespolonych?
> Też. Ale python również ma typ liczb zespolonych.

Ale python jest chyba tylko interpretowany.

Za to ... obiecywalem sobie porownac Fortran i C++ jesli chodzi o
liczby zespolone. Fortran ma wbudowane, a w C++ narzut obiektowy nie
zezre wydajnosci ? Co prawda teraz sporo operacji jest inline ..

> Fortran nadaje się
> do kompilowania dawno napisanych (i dobrze przeterstowanych) źródeł
> i łączenia tego z nowym kodem w nowych językach. W fortranie nikt
> już chyba nic nie pisze, bo co było potrzebne, dawno napisano.

Mowisz ?
Troche dziwne by to bylo, ze programow nie trzeba rozwijac :-)

>> Tak mi zostało po sytuacji, gdy działałem, a do dyspozycji, jeszcze
>> przed C64, miałem ledwie 3.5 kB RAM (VIC-20 bez rozszeszeń pamięci),
>> a kładłem na tym programy znacznie bardziej skomplikowane i musiałem
>> się postarać, aby się zmieściły i ruszyły.
>
> Za to w językach interpretowanych zapisany kod może być bardzo mały.
> Interpreter siedzi sobie w ROM i interpretuje.

A w takim spectrum, i VIC pewnie tez, program byl tokenizowany ...
mozna by nazwac pół skompilowanym. W pelni skompilowany nie bylby duzo
szybszy, bo jednak pojedyncza operacja jezyka, to wiele instrukcji
8-bit. Trzeba by typy zmiennych ograniczyc ..

J.

do góry

On Thu, 20 Sep 2018 23:20:21 +0200, Jarosław Sokołowski wrote:
> No to trzeba wziąć coś innego niż basic. Ten do kompilacji się nie
> nadaje. Chyba, że ja czegoś nie wiem.

Nadaje się jak najbardziej. QuickBasic piękne binaria kompiluje, a nawet
optymalizuje je (jeśli mu się tak nakaże) pod 286.

Wprowadziłem program 'goto k++' kolegów do QuickBasic 7.1 i
skompilowałem. Plik wynikowy waży 20 KiB w wersji samodzielnej, a 4 KiB w
wesji stubowej (w tym drugim wypadku wymaga jednak obecności biblioteki
runtime brt71 w %PATH%, a ta waży 83 KiB).

Mateusz

do góry

Pan Marcin Debowski napisał:

> Kupiłem żonie do firmy parę lat temu laserówkę Canona, właśnie dlatego,
> że miała mieć sterowniki pod Linuksa (tak stało na ich stronie).
> Okazało się, że nie miała. Canon stanął na wysokości zadania i dał nam,
> do czasu gdy sterowniki będą dostępne, zastępczo lepszy model włączając
> w to toner. Pół roku im to zajęło.

Czyli trwało tyle, ile powinno. Kiedyś na p.c.o.a wymyślono nawet termin
"linuksowe pół roku".

--
Jarek

do góry

Pan Mateusz Viste napisał:

>> No to trzeba wziąć coś innego niż basic. Ten do kompilacji się nie
>> nadaje. Chyba, że ja czegoś nie wiem.
>
> Nadaje się jak najbardziej. QuickBasic piękne binaria kompiluje,
> a nawet optymalizuje je (jeśli mu się tak nakaże) pod 286.
>
> Wprowadziłem program 'goto k++' kolegów do QuickBasic 7.1 i
> skompilowałem. Plik wynikowy waży 20 KiB w wersji samodzielnej,
> a 4 KiB w wesji stubowej (w tym drugim wypadku wymaga jednak
> obecności biblioteki runtime brt71 w %PATH%, a ta waży 83 KiB).

No to faktycznie czegoś nie wiedziałem. I nadal nie wiem po co
komu ten basic.

--
Jarek

do góry

Pan J.F. napisał:

>> Fortran nadaje się do kompilowania dawno napisanych (i dobrze
>> przeterstowanych) źródeł i łączenia tego z nowym kodem w nowych
>> językach. W fortranie nikt już chyba nic nie pisze, bo co było
>> potrzebne, dawno napisano.
>
> Mowisz ?
> Troche dziwne by to bylo, ze programow nie trzeba rozwijac :-)

Co w tym dziwnego? To jest wyłącznie numeryka. Programy liczą to,
co powinny. Optymalizacja wydajności osiągnęła kres, nie ma już
czego zmieniać.

--
Jarek

do góry

On Fri, 21 Sep 2018 08:39:27 +0200, Jarosław Sokołowski wrote:
> No to faktycznie czegoś nie wiedziałem. I nadal nie wiem po co komu ten
> basic.

By pisać programy w miejscach gdzie Fortran nie daje rady. :)

Mateusz

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>> Fortran nadaje się do kompilowania dawno napisanych (i dobrze
>>> przeterstowanych) źródeł i łączenia tego z nowym kodem w nowych
>>> językach. W fortranie nikt już chyba nic nie pisze, bo co było
>>> potrzebne, dawno napisano.
>
>> Mowisz ?
>> Troche dziwne by to bylo, ze programow nie trzeba rozwijac :-)

>Co w tym dziwnego? To jest wyłącznie numeryka. Programy liczą to,
>co powinny. Optymalizacja wydajności osiągnęła kres, nie ma już
>czego zmieniać.

No i co - jesli nawet szybciej sie nie da, to wiecej i wyzej mozna :-)

A na lepsza, szybsza metode nikt nie wpadl ?

J.

do góry

Pan J.F. napisał:

>>>> Fortran nadaje się do kompilowania dawno napisanych (i dobrze
>>>> przeterstowanych) źródeł i łączenia tego z nowym kodem w nowych
>>>> językach. W fortranie nikt już chyba nic nie pisze, bo co było
>>>> potrzebne, dawno napisano.
>>> Mowisz ?
>>> Troche dziwne by to bylo, ze programow nie trzeba rozwijac :-)
>> Co w tym dziwnego? To jest wyłącznie numeryka. Programy liczą to,
>> co powinny. Optymalizacja wydajności osiągnęła kres, nie ma już
>> czego zmieniać.
>
> No i co - jesli nawet szybciej sie nie da, to wiecej i wyzej mozna :-)

Co znaczy "więcej i wyżej"?

> A na lepsza, szybsza metode nikt nie wpadl ?

Matematyka się rozwija, ale nie tak, że ktoś co chwilę wpada na nową
szybszą metodę odwracania macierzy.

--
Jarek

do góry