QB64 może skompilować samego siebie ze źródeł... Są dołaczone do kompilatora, chciałem przepisać go na polskie komunikaty (i chyba się podejmę, jak czasu będzie), ale za dużo tego było do rozkminienia.
Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:5ba5019b$0$587$ snipped-for-privacy@news.neostrada.pl...
Ale byli tacy, co tego nie wiedzieli i edytory popełnili :)
FreeBASIC tak samo.
"Zdzich64" ?
Mateusz
W QuickBasic oraz QBasic też jest PEEK/POKE. Wpływać w ten sposób na zachowanie programu i danych można na czymkolwiek co działa w trybie rzeczywistym - na tym polega piękno tej architektury.
Mateusz
QBASIC niczego nie kompilował. QuickBasic owszem.
A czy to nie była po prostu tokenizacja? Nie wiem, C64 nie miałem, ale BASICA (i chyba GW-BASIC też) potrafiły zapisać program w postaci binarnej. Ale nie jako kod wykonywalny, tylko ciąg tokenów. Zamiast "IF" było dajmy na to 0x01, zamiast "WHILE" 0x05 itp. Ale to dalej program interpretowany.
Nie taki niszowy, chyba w każdej polskiej szkole był znany :) Jeśli dobrze pamiętam to był taki spolszczony Pascal.
Niszowy to był Sphinx C--, coś w połowie drogi między C a assemblerem.
Mateusz
W dniu 21.09.2018 o 22:24, J.F. pisze:
Pozwólcie, że się wtrącę :-) Chemicy, którzy nie zajmują się modelowaniem molekularnym, zwykle wykorzystują program Gaussian. Nie wiem jednak, czy z czystym sumieniem mogę odesłać do opisów tego programu, z całym szacunkiem, dla kogoś, kto nie siedzi w chemii, może to być jak próba wyjaśnienia transformacji operatorowej poloniście. Ale na pewno da się zauważyć, jak daleko wychodzimy poza równanie Schrodingera. Czy odległe atomy oddziaływują na siebie? Jeśli jesteście zainteresowani, proponuję poczytać o regułach orientacji w aromatycznej substytucji elektrofilowej. Trzeba będzie poświęcić nieco czasu na zrozumienie mezomerii, proste przeczytanie definicji w Wikipedii jest tego czasu marnowaniem. Już na tak prostym przykładzie widać, że zagadnienie nie jest trywialne. Co to znaczy, że atomy są blisko lub daleko od siebie? Wzory cząsteczek rysujemy na papierze. Prowadzi to do błędnego obrazu płaskości, w rzeczywistości cząsteczka nie jest płaska i atomy pozornie odległe mogą być bardzo blisko. Może to dziwne w czasach powszechnego wykorzystywania komputerów, ale chemicy stosują modele Dreidinga. "Drajdingi" oddają kąty i długości wiązań i są łatwo montowalne. Jeśli ktoś ma praktykę, to model kilkunastowęglowej cząsteczki zbuduje w dwie minuty. Policzenie tego na dobrym pececie zajmuje dobę. I trzeba programowi podpowiadać, bo pozostawiony sam sobie potrafi policzyć durnotę. Z kwestii oczywistych: w cząsteczkach pojawiają się grupy naładowane, na przykład COO- lub NH3+. Tworzą one pole elektryczne , które w oczywisty sposób oddziaływuje na orbitale, które są przecież chmurą ładunku. Inny przykład to grupa karbonylowa C=O która jest dipolem. Jeśli w pobliżu znajdzie się jakieś ugrupowanie, to oddziaływanie jest zrozumiałe.
P.P.
Pan Paweł Pawłowicz napisał:
Ależ oczywiście! Proszę, śmiało.
Odruchowo, nie bacząc na ostrzeżenia, zacząłem guglem poszukiwać miejsca, skąd mógłbym sobie ściągnąć źródła tego gaussiana -- celem oszacowania jaka część kodu jest w fortranie, a jaka w niefortranie. Bowiem to było głównym celem prowadzonych tu rozważań. Niestety, nic z tego nie wyszło. (To co było poniżej, z uwagą i w miarę możności ze zrozumieniem, przeczytałem)
No, ale w tym momencie, to one chyba raczej służą jako rejestry... choć nie pamiętam, ale zachęcony tym co piszesz, mam taką możliwość i sprawdzę reakcję QBASICa ze starych Windoz, oraz obecnego QB64, QuickBasic... no, moze też... Ale najpierw piszczek do czajnika :))
Oj, chętnie bym to powitał. Jest nieco przaśny, ale daje malutki kod, a możliwości ma, choćby wbudowaną obsługę myszy. Ale niestety, tylko QB64, do takiego przepisania. Ale, to kupa gównienia w rzeźbie. Najważniejsze, aby program działał.
Ja nie mówię, że kompilował, ja mówię, że zachowywał się, jakby kompilował.
Zdecydowanie był/jest interpreter, gdzie rzeczywiście, komendę zastępuje jednobajtowy kod tejże.
Nie inaczej, zdecydowanie to był interpreter, nawet chyba bez porządnego programowania strukturalnego, numery linii były jeszcze numerami linii, nie etykietami i GW układał je sobie po kolei, nie tak, jak już QBASIC, gdzie program mógłbyć zapisany tak:
23 k=0 13 k=k+1 PRINT k; GOTO 13I działa.
Pewnie tak, choć jego składnie nie bardzo kojarzę Pascalowo... ale przyznam, niespecjalnie usiłowałem ją porównywać, liczy(ło) się dla mnie, czy (i jak) wykonuje powierzone zadanie. Bo Pascala jako takiego po polsku, to kojarzę. Mam nadzieję, że nie taki niewypał, jak wersja Borlanda 5.5.
Odnalazłem na jakiejś ruskiej stronce, rzeczywiście, najnowsza wersja ma 22 lata... Więc nisza głęboka była.
Robiłem to ze 20 lat temu i takie rzeczy albo się robiło właśnie ze Schrodingera albo półempirycznie. Nie przypominam sobie jakiś ograniczeń co do ilości atomów. Głównym problemem przy Schrodingerze był czas. Liczyłem dość proste pierścienie fosfazenowe i na dość dobrych maszynach jak na tamte czase (ale też znowu nie jakiś super wypas) - SGI O2, zajmowało to tygodnie.
Półempirycznie (molecular mechanics) to był relatywnie błysk, nawet jak na tamte czasy.
Jak to teraz wygląda to nie wiem, ale raczej skłaniam się ku opinii Jarka, bo problem był w mocy obliczeniowej.
No cała radość po kilku dniach zobaczyć, że to wszystko się "rozchodzi" zamiast "schodzić".
Gaussian jest kompercyjny. Nie sądze aby źródła były dostępne. Ale tu:
Ale po co się w sumie afiszowali, że jest jak nie było? Fakt, że pewnie Linuks nadal dość niszowy... Z drugiej strony jeśli innych frustratów załatwili z podobną klaśa jak mnie, to może nawet i lepszy PR im z tego wyszedł, niż jakby mieli anonsować sterowniki pod Linuksa w późniejszym terminie.
Ale pewnie to był jakiś wypadek przy pracy.
Pierwszy raz zetknąłem się z problemem na studiach, ponad czterdzieści lat temu. Ab initio dawało się policzyć jon H2+, i to by było na tyle...
P.P.
Pan Marcin Debowski napisał:
Kontekst przepychanek z p.c.o.a był taki, że w linuksie wszystko już jest prawie, prawie, a za pół roku będzie całkiem. Rzeczywistość jest taka, że jeśli czegoś nie potrzeba, to tego nie ma i nie będzie.
Albo wyjątkowy przypadek, że ktoś coś obiecał, zaplanował i w końcu zrobił.
Dość często spotykam się z takim przypadkiem, że producent ogłasza wszem i wobec, że jego sprzęt ma wsparcie dla Linuksa. Jako dowód dołącza płytę CD ze "sterownikami". Te sterowniki to wyrwany z kontekstu fragment kodów kernela mający z dziesięć lat. Od tego czasu w nowych wydaniach jądra nastąpił znaczący postęp, obsługa tego sprzętu zmieniła się, polepszyła. Ale producent sprzętu może o tym wcale nie wiedzieć, nie obchodzi go to, nie on to wszystko pisze.
Pan Marcin Debowski napisał:
Fortran też jest całkiem nieźle rozwinięty jak na swoje 60 lat i tego typu zastosowania. Chociaż dzisiaj zaliczenie go do "języków wysokiego poziomu" brzmi nieco dziwnie. Bliżej mu do assemblera niż do javy.
Współczesne języki programowania obrały inną drogę. Wszystko można w nich zrobić łatwo i przyjemne. Chyba żeby ktoś chciał coś policzyć, wtedy gorzej. Rację mają Francuzi. Dzisiaj komputer to nie "computer" (liczydło), ale "ordinateur" (zarządca, organizator, porządkowy).
Dnia Sun, 23 Sep 2018 13:46:06 +0200, Jarosław Sokołowski napisał(a):
Ale Fortran tez nie stoi w miejscu
J.
Pan J.F. napisał:
Są też tacy, którzy wciąż jeszcze grzebią w commodorach i basicach. Można stworzyć całkiem nowy język i z sentymentu nazwać go "basic" albo "fortran" z odpowiednim przedrostkiem. Tak samo są też ludzie, u których już siódmy pies z kolei wabi się Azor.
O ile wiem, to w C64 tak wlasnie bylo. W spectrum bylo od samego poczatku - nie wpisuwales I i F, tylko odpowiednia kombinacja klawiszy na token IF
Hm ... piszesz takie LET A=A+1, to i tak trzeba wywolac prodedure "biblioteczna" dodawania liczb FP, bo innych nie znal. I czy w programie bedzie bezposredni call czy przejscie przez tablice adresow funkcji dla tokenow, to juz nie taka duza roznica.
Tyle ze Spectrum juz w trakcie wykonania wyszukiwal adresy zmiennych, analizowal wyrazenia, wiec sporo tej interpretacji zostalo.
J.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.