Grzegorz Krukowski wrote:
>>A po co Ci FORTRAN?
> Aby jak najmniejszym kosztem obGUIć 30 letnie programy w FORTRANie. U
> mnie w firmie krążą takie staruszki - użyteczne lecz wiekowe.

Przyznam, że to bolesne zadanie. Powodzenia, z F w .NET mam 0
doswiadczeń (na szczęście).

do góry

On Tue, 19 May 2009 11:34:15 +0200, Jacek Czerwinski <...@...z.pl> wrote:

>Fortran (przynajmniej ten klasyczny) ma takie fikuśne struktury danych
>a dokładnie to brak współczesnych struktur danych, że nie wyobrażam
>sobie pełnej kompatybilności. To musi wyjść potworek jak Managed C++

Masz pojecie o Fortranie jak ja o japonskim teatrze Kabuki. Nawet nei
miales w reku ksaizki o Fortranie

A.L.

do góry

A.L. pisze:
> On Tue, 19 May 2009 11:34:15 +0200, Jacek Czerwinski <...@...z.pl> wrote:
>
>> Fortran (przynajmniej ten klasyczny) ma takie fikuśne struktury danych
>> a dokładnie to brak współczesnych struktur danych, że nie wyobrażam
>> sobie pełnej kompatybilności. To musi wyjść potworek jak Managed C++
>
> Masz pojecie o Fortranie jak ja o japonskim teatrze Kabuki. Nawet nei
> miales w reku ksaizki o Fortranie

Zaledwie od 1983 roku i sporo kaski na tamte czasy mi przyniósł, ale to nic.
Z nowszymi oczywiście nie mam nic wspólnego.

Przenieś na .NET BLOCK DATA (chyba się to tak pisało) i COMMONY, te
rzeczy ... to są śmiercionośne jak na dziś techniki ale tak ma być
(miało być).

Nie po to są języki z VM zeby fortany dziś implementować.

do góry

On Tue, 19 May 2009 15:17:30 +0200, Jacek Czerwinski <...@...z.pl> wrote:

>A.L. pisze:
>> On Tue, 19 May 2009 11:34:15 +0200, Jacek Czerwinski <...@...z.pl> wrote:
>>
>>> Fortran (przynajmniej ten klasyczny) ma takie fikuśne struktury danych
>>> a dokładnie to brak współczesnych struktur danych, że nie wyobrażam
>>> sobie pełnej kompatybilności. To musi wyjść potworek jak Managed C++
>>
>> Masz pojecie o Fortranie jak ja o japonskim teatrze Kabuki. Nawet nei
>> miales w reku ksaizki o Fortranie
>
>Zaledwie od 1983 roku i sporo kaski na tamte czasy mi przyniósł, ale to nic.
>Z nowszymi oczywiście nie mam nic wspólnego.

No wlasnei na tym polega problem. O Fortranei wiesz tyl co o jakpnskim
teatrze Kabuki. A i w 83 roku Frotran (f77) byl calkiem znosny.

Odswiez sobie pamiec, zwlaszcza popatrz na fortrany 200+

http://en.wikipedia.org/wiki/Fortran

A.L.

do góry

On Tue, 19 May 2009 15:17:30 +0200, Jacek Czerwinski wrote:
> Przenieś na .NET BLOCK DATA (chyba się to tak pisało) i COMMONY, te
> rzeczy ... to są śmiercionośne jak na dziś techniki ale tak ma być
> (miało być).

Nie wdając się w szczegóły, nie znam absolutnie Fortrana,
te konstrukcje wyglądają jak (statyczne/globalne) zmienne i
ich inicjalizacja...

Cóż w tym takiego "śmiercionośnego" i nie
implemenetowalnego na czymś "aktualnym"?

Chetnie się dowiem co to robi, jeżeli się mylę.

--
Pozdrawiam,
Łukasz 'Maly' Ostrowski. http://maly.nemo.pl/
ICQ: 148498663 GG: 2544385 AIM: malyzgora
GTalk: l...@g...com ASTRA: L3viathan

do góry

Łukasz 'Maly' Ostrowski pisze:
> On Tue, 19 May 2009 15:17:30 +0200, Jacek Czerwinski wrote:
>> Przenieś na .NET BLOCK DATA (chyba się to tak pisało) i COMMONY, te
>> rzeczy ... to są śmiercionośne jak na dziś techniki ale tak ma być
>> (miało być).
>
> Nie wdając się w szczegóły, nie znam absolutnie Fortrana,
> te konstrukcje wyglądają jak (statyczne/globalne) zmienne i
> ich inicjalizacja...
>
> Cóż w tym takiego "śmiercionośnego" i nie
> implemenetowalnego na czymś "aktualnym"?
Bloki pamięci rozmiarze bliżej nieokreślonym, nieznanym w innych
modułach (i bez API by ta wiedzę tam przekazać). Ułomna być może oamięć
mi podpowiada, że drugą i kolejną zmienna tablicowa się obliczało.

Co więcej, ówczesne podręczniki zupełnie swobodnie sugerowały żeby
tablicę (tfu, tfu obszar pamięci) integerów * 1000 interpretować z
drugiego modułu jako dwuwymiarową itd. To był na tamte czasy 'normalny'
sposób przekazywania pamięci, przez przestrzeń globalną.

Konstrukcja żywcem wzięta z asemblerów.
W sumie to grupa zagadnień podobna jak w normalnym C.

Na dzisiejszych językach (zwłaszcza opartych na VM) ochrona jest podstawą.

Zaimpelmentuj z 'dzisiejszym języku z JVM'
void fun(char * s)
{
s[-3] = '\0';
}


Jakoś nie chce mi się wierzyć ani w pełną implementację C w JVM, ani w
Fortran w .NET

do góry

On Tue, 19 May 2009 17:04:12 +0200, Łukasz 'Maly' Ostrowski
<m...@n...pl> wrote:

>On Tue, 19 May 2009 15:17:30 +0200, Jacek Czerwinski wrote:
>> Przenieś na .NET BLOCK DATA (chyba się to tak pisało) i COMMONY, te
>> rzeczy ... to są śmiercionośne jak na dziś techniki ale tak ma być
>> (miało być).
>
>Nie wdając się w szczegóły, nie znam absolutnie Fortrana,
>te konstrukcje wyglądają jak (statyczne/globalne) zmienne i
>ich inicjalizacja...
>
>Cóż w tym takiego "śmiercionośnego" i nie
>implemenetowalnego na czymś "aktualnym"?

BLOCK DATA niespeclalnie byla potzrebna, ale COMMON to bym "namespace
dla ubogich" i rzecz dosyc uzyteczna. Mianowicie mozna bylo
zarezerowwac onszar pamieci i nadac mu nazwe. Ten obszar mogl byc
widziany z wnetrza dowolnej procedury, i co ciekawe, interpretowany w
sposob specyficzny dla daneg procedury. I tak w obszarze o nazwie
/AAA/ jedna procedura mogla widziec 4 liczby INTEGER, a inna procedure
atlice zlozona z 4 elementow

Byl to konecpt dosyc niskopoziomowy (jak wszystko w Fortranie) ale
calkiem uzyteczny. Czasami zaluje ze go nie ma. Mozna symulowac przy
pomocy statycznych atrybutow klas

A.L.

do góry

On Tue, 19 May 2009 11:34:15 +0200, Jacek Czerwinski <...@...z.pl> wrote:

>Jest taki? Nie wiedziałem ...
>Fortran (przynajmniej ten klasyczny) ma takie fikuśne struktury danych
>a dokładnie to brak współczesnych struktur danych, że nie wyobrażam
>sobie pełnej kompatybilności. To musi wyjść potworek jak Managed C++
Z opisu Lahey/Fujitsu FORTRAN .NET
,,Ponieważ niektóre cechy starszej wersji języka Fortran (takie jak
COMMON lub EQUIVALENCE) mogą łamać reguły bezpieczeństwa i standardu
interfejsowego środowiska CLR, aplikacje Fortran .NET nie są w 100%
zgodne ze standardem Fortran.''
--
Grzegorz Krukowski

do góry

Grzegorz Krukowski pisze:
> On Tue, 19 May 2009 11:34:15 +0200, Jacek Czerwinski <...@...z.pl> wrote:
>
>> Jest taki? Nie wiedziałem ...
>> Fortran (przynajmniej ten klasyczny) ma takie fikuśne struktury danych
>> a dokładnie to brak współczesnych struktur danych, że nie wyobrażam
>> sobie pełnej kompatybilności. To musi wyjść potworek jak Managed C++
> Z opisu Lahey/Fujitsu FORTRAN .NET
> ,,Ponieważ niektóre cechy starszej wersji języka Fortran (takie jak
> COMMON lub EQUIVALENCE) mogą łamać reguły bezpieczeństwa i standardu
> interfejsowego środowiska CLR, aplikacje Fortran .NET nie są w 100%
> zgodne ze standardem Fortran.''

cholera chyba zacznę przewidywać wyniki totolotka
;)

do góry

On Tue, 19 May 2009 18:09:56 +0200, Jacek Czerwinski wrote:
> Co więcej, ówczesne podręczniki zupełnie swobodnie sugerowały żeby
> tablicę (tfu, tfu obszar pamięci) integerów * 1000 interpretować z
> drugiego modułu jako dwuwymiarową itd. To był na tamte czasy 'normalny'
> sposób przekazywania pamięci, przez przestrzeń globalną.

Takie, uhm, globalne union'y, right? Brzydkie, imo =].

> Na dzisiejszych językach (zwłaszcza opartych na VM) ochrona jest podstawą.

Bezdyskusyjnie.

> Zaimpelmentuj z 'dzisiejszym języku z JVM'
> void fun(char * s)
> {
> s[-3] = '\0';
> }
>
>
> Jakoś nie chce mi się wierzyć ani w pełną implementację C w JVM, ani w
> Fortran w .NET

Jak sie uprzeć to wszystko może być w unsafe blocku ;-).
I wtedy se można mazać "prawie wszędzie" po pamięci
bez kontroli. ;-).

<flame>
Do JVM się nie ustosunkuje, bo to język dla bezdomnych ;-).
</flame>

--
Pozdrawiam,
Łukasz 'Maly' Ostrowski. http://maly.nemo.pl/
ICQ: 148498663 GG: 2544385 AIM: malyzgora
GTalk: l...@g...com ASTRA: L3viathan

do góry