[golf] #4.9 TAC
Piotr Fusik - 23-10-2005 18:18
[golf] #4.9 TAC
Witam,
Zgodnie z zapowiedzią nowa edycja wystartowała.
Tym razem nie trzeba nic rysować, nic obliczać, tylko czyste I/O.
Zadanko jest proste, ale proszę je uważnie przeczytać!
Oby frekwencja była wyższa, niż we wczorajszych wyborach. :-)
Powodzenia!
0xF
---
TAC
Konkurs perlgolfa pl.comp.lang.perl, sezon 4, edycja 9
1. Zadanie
Należy stworzyć filtr odwracający kolejność bajtów.
Skrypt ma zapisać na standardowe wyjście w odwrotnej kolejności bajty
odczytane ze standardowego wejścia. Skrypt będzie uruchamiany bez argumentów.
Operacje na standardowym wejściu i wyjściu muszą być wykonywane w trybie
binarnym. Chodzi o to, aby na każdym systemie odwracana była kolejność bajtów.
Tak więc należy np.
- przed użyciem getc, read, print itp. wykonać binmode STDIN
oraz binmode STDOUT (binmode nie wpływa na seek ani tell)
lub
- operacje we/wy wykonywać wyłącznie przy użyciu sysread, syswrite i sysseek
(oczywiście można też użyć innego sposobu na STDIN niż na STDOUT).
Limit długości strumienia to 2**31-1. Nie wolno zakładać, że wszystkie dane
wejściowe zmieszczą się w pamięci. Uwaga: nie jest to sprawdzane przez skrypt
testujący, ale rozwiązania niezgodne z regulaminem zostaną odrzucone po
terminie nadsyłania rozwiązań.
Na strumieniu STDIN (ale na STDOUT nie koniecznie) będą działać operacje seek,
sysseek oraz tell. Nie wolno próbować ustawiać pozycji w strumieniu przed jego
początkiem (offset < 0) lub za jego końcem (offset > długość; na samym końcu
można). Testy tego nie pilnują!
Skrypt nie może tworzyć dodatkowych plików ani katalogów (nawet tymczasowych)
ani sam siebie modyfikować (przez zapis do pliku skryptu). Zabroniony jest też
zapis na STDERR.
2. Zasady
Konkurs odbywa się zgodnie ze standardowymi zasadami perlgolfa. Nie wolno
jednak wykorzystywać żadnych zewnętrznych modułów, nawet tych, które są w
standardowej dystrybucji Perla. Zabronione jest też użycie więcej niż dwóch
znaków białych na końcu skryptu.
Oficjalną wersją interpretera perla jest (uwaga!) 5.8.7, na niej powinny
działać rozwiązania (tzn. mogą wykorzystywać błędy w perlu 5.8.7, ale nie
błędy we wcześniejszych wersjach, które zostały usunięte w wersji 5.8.7).
Dostępny skrypt testowy test.pl sprawdza poprawność rozwiązania dla kilku
przypadków (swoje rozwiązanie należy nazwać tac.pl). Jeśli odpowiedzi okażą
się poprawne (przejście testów nie dowodzi poprawności!), rozwiązanie jest
kopiowane do pliku mającego w nazwie uzyskany wynik (ilość znaków plus wartość
tie jako ułamek). Wartość tie (standardowo) stanowi procent znaków spoza
zbioru A-Za-z0-9_, im mniejsza - tym lepiej!
Wątpliwości dotyczące treści zadania lub zasad należy zgłaszać na
pl.comp.lang.perl.
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Leonard Milcin Jr. - 23-10-2005 18:18
Piotr Fusik wrote:
> Witam,
>
> Zgodnie z zapowiedzią nowa edycja wystartowała.
> Tym razem nie trzeba nic rysować, nic obliczać, tylko czyste I/O.
> Zadanko jest proste, ale proszę je uważnie przeczytać!
> Oby frekwencja była wyższa, niż we wczorajszych wyborach. :-)
>
> Powodzenia!
> 0xF
>
> ---
>
> TAC
>
> Konkurs perlgolfa pl.comp.lang.perl, sezon 4, edycja 9
>
> 1. Zadanie
>
> Należy stworzyć filtr odwracający kolejność bajtów.
>
> Skrypt ma zapisać na standardowe wyjście w odwrotnej kolejności bajty
> odczytane ze standardowego wejścia. Skrypt będzie uruchamiany bez argumentów.
>
> (...)
>
> Limit długości strumienia to 2**31-1. Nie wolno zakładać, że wszystkie dane
> wejściowe zmieszczą się w pamięci. Uwaga: nie jest to sprawdzane przez skrypt
> testujący, ale rozwiązania niezgodne z regulaminem zostaną odrzucone po
> terminie nadsyłania rozwiązań.
>
> (...)
>
> Skrypt nie może tworzyć dodatkowych plików ani katalogów (nawet tymczasowych)
> ani sam siebie modyfikować (przez zapis do pliku skryptu). Zabroniony jest też
> zapis na STDERR.
> (...)
Nieśmiałe pytanie golfisty który miał zamiar po raz pierwszy stanąć przy
dołku...
Logicznie rzecz biorąc, program może zacząć wysyłać przetworzone dane
dopiero po odebraniu ostatniego bajtu danych. Wynika to z warunków
zadania -- odwraca otrzymane bajty, więc jako pierwszy wysyła ostatni
bajt otrzymanych danych, a ten z definicji otrzymuje po otrzymaniu
wszystkich poprzednich danych. Program musi wobec tego, w ogólnym
przypadku, przechowywać wszystkie odebrane bajty do momentu odebrania
ostatniego z nich. Ponieważ nie można zakładać, że wszystkie zmieszczą
się w pamięci (patrz warunki zadania) należałoby te bajty gdzieś
zapisać. W pliku zewnętrznym nie można. W pliku skryptu nie można.
Czyżby warunki zadania były sprzeczne same ze sobą? A może przewidziano
jakieś inne miejsce przechowywania danych?
Oprócz tego problemu warunki są o tyle nieprecyzyjne, że nie
stwierdzają, ile danych może się zmieścić w pamięci. Skoro nie można
założyć, że zmieszczą się wszystkie, to pytanie nasuwa się: ile może się
zmieścić. Pewna stała ilość danych? A może wyrażona stosunkiem do
wielkości wszystkich danych?
Pozdrawiam,
Leonard Milcin Jr.
Michal Jankowski - 23-10-2005 18:18
"Leonard Milcin Jr." <leonard.milcin@post.pl.wytnij.to> writes:
> wszystkich poprzednich danych. Program musi wobec tego, w ogólnym
> przypadku, przechowywać wszystkie odebrane bajty do momentu odebrania
> ostatniego z nich. Ponieważ nie można zakładać, że wszystkie zmieszczą
> się w pamięci (patrz warunki zadania) należałoby te bajty gdzieś
> zapisać. W pliku zewnętrznym nie można. W pliku skryptu nie można.
W pliku wejsciowym oczywiscie.
Przeczytaj starannie warunki zadania, ze szczegolnym uwzglednieniem
tego:
Na strumieniu STDIN (ale na STDOUT nie koniecznie) będą działać
operacje seek, sysseek oraz tell.
MJ
Piotr Fusik - 23-10-2005 18:18
> Logicznie rzecz biorąc, program może zacząć wysyłać przetworzone dane
> dopiero po odebraniu ostatniego bajtu danych.
Nigdzie nie jest napisane, że musisz odczytywać dane w kolejności.
Natomiast stoi, że możesz wykonywać seek lub sysseek.
Musisz tylko uważać, aby nie próbować wyjechać poza granice z żadnej strony.
> Oprócz tego problemu warunki są o tyle nieprecyzyjne, że nie
> stwierdzają, ile danych może się zmieścić w pamięci. Skoro nie można
> założyć, że zmieszczą się wszystkie, to pytanie nasuwa się: ile może się
> zmieścić. Pewna stała ilość danych? A może wyrażona stosunkiem do
> wielkości wszystkich danych?
>
Załóżmy, że w sumie do dyspozycji skryptu jest 8 MB RAMu.
0xF
P.S. Mamy już pierwszego uczestnika: to Szeryf z wynikiem 63.21, gratuluję!
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Leonard Milcin Jr. - 23-10-2005 18:18
Michal Jankowski wrote:
> Przeczytaj starannie warunki zadania, ze szczegolnym uwzglednieniem
> tego:
>
> Na strumieniu STDIN (ale na STDOUT nie koniecznie) będą działać
> operacje seek, sysseek oraz tell.
>
> MJ
>
>
Right...
Dzięki,
L.
Michał Szafrański - 23-10-2005 18:18
Piotr Fusik wrote:
> Na strumieniu STDIN (ale na STDOUT nie koniecznie) będą działać operacje seek,
> sysseek oraz tell. Nie wolno próbować ustawiać pozycji w strumieniu przed jego
> początkiem (offset < 0) lub za jego końcem (offset > długość; na samym końcu
> można). Testy tego nie pilnują!
>
Czy jest jakiś konkretny powód, aby tego nie robić, czy po prostu takie
utrudnienie zadania?
W danych testowych brakuje pliku pustego (na takim pliku nie można
wykonać seek STDIN,-1,2 zgodnie z regułami).
--
m.
Michal Jankowski - 23-10-2005 18:18
Michał Szafrański <stalker@variable.not.found> writes:
> W danych testowych brakuje pliku pustego
Huh? W moim jest.
MJ
Michał Szafrański - 23-10-2005 18:18
Michal Jankowski wrote:
> Michał Szafrański <stalker@variable.not.found> writes:
>
>
>>W danych testowych brakuje pliku pustego
>
>
> Huh? W moim jest.
Fakt, był taki mały, że nie zauważyłem.
--
m.
Piotr Fusik - 23-10-2005 18:18
> > Na strumieniu STDIN (ale na STDOUT nie koniecznie) będą działać operacje
seek,
> > sysseek oraz tell. Nie wolno próbować ustawiać pozycji w strumieniu przed
jego
> > początkiem (offset < 0) lub za jego końcem (offset > długość; na samym
końcu
> > można). Testy tego nie pilnują!
>
> Czy jest jakiś konkretny powód, aby tego nie robić, czy po prostu takie
> utrudnienie zadania?
Na pewno jest to jakieś utrudnienie.
Nie mam pewności, czy używanie seek-ów poza zakresem jest przenośne:
czy zawsze zwrócą błąd i czy przesuną wskaźnik, czy nie? Najlepiej
tego nie robić.
Pozdrawiam,
0xF
P.S. Obecne wyniki: ja: 58.28, Szeryf: 60.26.
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Twelve Hungry Mammoths - 23-10-2005 18:18
On Mon, 10 Oct 2005 12:07:37 +0200, Piotr Fusik <pfusik@op.pl> wrote:
> 1. Zadanie
>
> Należy stworzyć filtr odwracający kolejność bajtów.
yyyyh... i znowu binary conspiracy... nie wiesz, czy dziala, dopoki po
konkursie ktos Ci nie powie, ze u niego nie dziala. pozostaje golfowanie
wg dokumentacji, co jest sprzeczne z duchem perlgolfa (For perl golf the
executable (not the documentation) defines the language.) beda te same
problemy, co przy gif decompression.
pzdr
szeryf
PS. proponuje znacznie skrocic czas edycji, bo golfowania jest tu na
najwyzej godzine...
Michał Szafrański - 23-10-2005 18:18
Piotr Fusik wrote:
>>>Na strumieniu STDIN (ale na STDOUT nie koniecznie) będą działać operacje
>
> seek,
>
>>>sysseek oraz tell. Nie wolno próbować ustawiać pozycji w strumieniu przed
>
> jego
>
>>>początkiem (offset < 0) lub za jego końcem (offset > długość; na samym
>
> końcu
>
>>>można). Testy tego nie pilnują!
>>
>>Czy jest jakiś konkretny powód, aby tego nie robić, czy po prostu takie
>>utrudnienie zadania?
>
>
> Na pewno jest to jakieś utrudnienie.
>
> Nie mam pewności, czy używanie seek-ów poza zakresem jest przenośne:
> czy zawsze zwrócą błąd i czy przesuną wskaźnik, czy nie? Najlepiej
> tego nie robić.
POSIX chyba to specyfikuje. Ale chyba to i tak nie ma znaczenia, bo
perl nie gwarantuje zgodności funkcji IO z POSIX.
--
m.
Piotr Fusik - 23-10-2005 18:18
> > Nie mam pewności, czy używanie seek-ów poza zakresem jest przenośne:
> > czy zawsze zwrócą błąd i czy przesuną wskaźnik, czy nie? Najlepiej
> > tego nie robić.
>
> POSIX chyba to specyfikuje.
Chyba nie:
http://www.opengroup.org/onlinepubs/...ons/lseek.html
> Ale chyba to i tak nie ma znaczenia, bo
> perl nie gwarantuje zgodności funkcji IO z POSIX.
O ile wiem, perl teraz używa warstwy PerlIO, a kiedyś używał stdio.
Chyba że mówimy o sysseek - to raczej powinien być "goły" lseek.
Pozdrawiam,
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Piotr Fusik - 23-10-2005 18:18
> yyyyh... i znowu binary conspiracy... nie wiesz, czy dziala, dopoki po *
> konkursie ktos Ci nie powie, ze u niego nie dziala. pozostaje golfowanie *
> wg dokumentacji, co jest sprzeczne z duchem perlgolfa (For perl golf the *
> executable (not the documentation) defines the language.)
Wcale nie, wcześniej jest napisane:
"Your solution must be portable in the sense that it should work on all
official unpatched versions of perl 5.8.0 everywhere."
A więc prawdopodobnie najlepiej opierać się na źródłach, bo ciężko
zdobyć dostęp do wszystkich architektur. ;-)
> beda te same problemy, co przy gif decompression.
No cóż, jak się nie ma Windowsa...
Ja nie widzę nic złego w pisaniu przenośnych programów, nawet w golfie.
Poza tym problemy z przenośnością są nie tylko w I/O: przypomnij sobie
moją wpadkę z -undef. A I/O jest jakąś odmianą od tego rysowania i obliczania.
> PS. proponuje znacznie skrocic czas edycji, bo golfowania jest tu na *
> najwyzej godzine...
Sugerujesz, że już nie ruszymy z miejsca?
(ja=Szeryf=58.28, Stalker=67.35)
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Michał Szafrański - 23-10-2005 18:18
Piotr Fusik wrote:
>>>Nie mam pewności, czy używanie seek-ów poza zakresem jest przenośne:
>>>czy zawsze zwrócą błąd i czy przesuną wskaźnik, czy nie? Najlepiej
>>>tego nie robić.
>>
>>POSIX chyba to specyfikuje.
>
>
> Chyba nie:
> http://www.opengroup.org/onlinepubs/...ons/lseek.html
>
O właśnie, dzięki, nie chciało mi się szukać standardu:
Seek przed początek:
ERRORS
[EINVAL]
The whence argument is not a proper value, or the resulting
file offset would be negative for a regular file, block special file, or
directory.
Seek za koniec:
The lseek() function shall allow the file offset to be set beyond the
end of the existing data in the file. If data is later written at this
point, subsequent reads of data in the gap shall return bytes with the
value 0 until data is actually written into the gap.
Choć nadal nie wiem czy sysseek lub seek w perlu gwarantują powyższe.
W activeperlu tak jest.
--
m.
Piotr Fusik - 23-10-2005 18:18
> Seek przed początek:
>
> ERRORS
> * * [EINVAL]
> * * * * The whence argument is not a proper value, or the resulting
> file offset would be negative for a regular file, block special file, or
> directory.
Zadanie nie określa, że STDIN będzie otwarty np. na zwykłym pliku.
Np. w Windowsie zadziała:
dir | perl tac.pl
> Seek za koniec:
>
> The lseek() function shall allow the file offset to be set beyond the
> end of the existing data in the file. If data is later written at this
> point, subsequent reads of data in the gap shall return bytes with the
> value 0 until data is actually written into the gap.
Czyli rozumiem że wyjechanie za koniec nie zwraca błędu seek,
natomiast będzie EOF przy odczycie. Trzeba tylko uważać, żeby nie wyjechać
poza zakres off_t, bo będzie wartość ujemna.
>
> Choć nadal nie wiem czy sysseek lub seek w perlu gwarantują powyższe.
> W activeperlu tak jest.
>
Nie będę dodatkowo upraszczał zadania, skoro Szeryf stwierdził, że jest
na godzinę. :-)
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Maciej Misiak - 23-10-2005 18:18
> No cóż, jak się nie ma Windowsa...
> Ja nie widzę nic złego w pisaniu przenośnych programów, nawet w golfie.
> Poza tym problemy z przenośnością są nie tylko w I/O: przypomnij sobie
> moją wpadkę z -undef. A I/O jest jakąś odmianą od tego rysowania i obliczania.
Zgadza sie, odmiana jest i porusza te strony manuala, ktorych do tej pory na
oczy nie widzialem i na uszy nie slyszalem :) Chociaz idzie mi jak po grudzie :(
pzdr
Grizzley
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Piotr Fusik - 23-10-2005 18:18
Witam,
Żeby była jasność: nie wolno wykonywać seek/sysseek poza zakresem,
nawet jeśli jest to ostatnia operacja wykonywana przez skrypt i zwracana
wartość nie ma znaczenia.
Dlaczego? Przypuśćmy, że niektóre systemy/biblioteki mają błąd
objawiający się wysypaniem programu lub czymś straszniejszym
w przypadku takiej operacji.
Z innej beczki:
Wyczytałem coś o utf8 przy sysread i syswrite.
Ktoś wie, o co chodzi i czy może to nam psuć szyki?
Niezrozumiały jest też komentarz na końcu binmode:
że ma wpływ m.in. na seek i tell - ciekawe jaki?
Właśnie wysłałem perlbug-a (#37419).
Frekwencja coś niska... Spełniajcie swój obywatelski obowiązek. ;-)
0xF
P.S. Najświeższe wyniki:
1. Piotr Fusik (0xF) 57.29
2. Przemysław Kowalczyk (szeryf) 58.28
3. Michal Szafranski (stalker) 67.35
4. Maciej Misiak (grizzley) 89.35
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
pfusik@op.pl - 23-10-2005 18:18
Stalker zaatakował:
1. Michal Szafranski (stalker) 56.31
2. Piotr Fusik (0xF) 57.29
3. Przemysław Kowalczyk (szeryf) 58.28
4. Bartosz Kuźma (bartosz) 66.36
5. Maciej Misiak (grizzley) 89.35
Witamy też nowego golfistę!
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Piotr Fusik - 23-10-2005 18:18
No, no, może nam się objawił nowy talent:
1. Bartosz Kuźma (bartosz) 53.33
2. Michal Szafranski (stalker) 56.31
3. Piotr Fusik (0xF) 57.29
4. Przemysław Kowalczyk (szeryf) 58.28
5. Maciej Misiak (grizzley) 89.35
Czy wszyscy uczestnicy są przekonani o zgodności swoich rozwiązań
z zadaniem oraz tym, co zostało napisane w tym wątku?
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Michał Szafrański - 23-10-2005 18:18
Piotr Fusik wrote:
> No, no, może nam się objawił nowy talent:
>
> 1. Bartosz Kuźma (bartosz) 53.33
> 2. Michal Szafranski (stalker) 56.31
> 3. Piotr Fusik (0xF) 57.29
> 4. Przemysław Kowalczyk (szeryf) 58.28
> 5. Maciej Misiak (grizzley) 89.35
>
> Czy wszyscy uczestnicy są przekonani o zgodności swoich rozwiązań
> z zadaniem oraz tym, co zostało napisane w tym wątku?
Ja nie
--
m.
Maciej Misiak - 23-10-2005 18:18
> Czy wszyscy uczestnicy są przekonani o zgodności swoich rozwiązań
> z zadaniem oraz tym, co zostało napisane w tym wątku?
Nie
pzdr
Grizzley
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Michal Jankowski - 23-10-2005 18:18
"Piotr Fusik" <pfusik@op.pl> writes:
> 1. Bartosz Kuźma (bartosz) 53.33
> 2. Michal Szafranski (stalker) 56.31
> 3. Piotr Fusik (0xF) 57.29
> 4. Przemysław Kowalczyk (szeryf) 58.28
Well... Biorac pod uwage, ze samo:
sysread STDIN syswrite STDOUT sysseek STDIN
to sa 43 znaki, to chyba robicie to jakos inaczej 8-)
MJ
Michal Jankowski - 23-10-2005 18:18
"Piotr Fusik" <pfusik@op.pl> writes:
> Zadanie nie określa, że STDIN będzie otwarty np. na zwykłym pliku.
> Np. w Windowsie zadziała:
> dir | perl tac.pl
Nie wiem co prawda do konca, jaki jest twoj punkt bedacy, ale o ile mi
wiadomo, przy takiej konstrukcji w dosie (wiec i w win$ pewnie tez)
dostawalo sie na wejscie najzwyklejszy plik tymczasowy...
Seek na rurce to raczej, no wiesz, ten, tego...
MJ
Bartosz Kuźma - 23-10-2005 18:18
Piotr Fusik wrote:
> Czy wszyscy uczestnicy są przekonani o zgodności swoich rozwiązań
> z zadaniem oraz tym, co zostało napisane w tym wątku?
>
> 0xF
>
>
Niestety. Czytam przed początkiem, więc nie. Jak można cofnąć swoje
rozwiązanie do wersji poprzedniej?
--
Pozdrawiam, Bartosz Kuźma.
Michał Szafrański - 23-10-2005 18:18
Bartosz Kuźma wrote:
> Piotr Fusik wrote:
>
>
>>Czy wszyscy uczestnicy są przekonani o zgodności swoich rozwiązań
>>z zadaniem oraz tym, co zostało napisane w tym wątku?
>>
>>0xF
>>
>>
>
> Niestety. Czytam przed początkiem, więc nie. Jak można cofnąć swoje
> rozwiązanie do wersji poprzedniej?
>
Logujesz się -> <przeglądaj rozwiązania> -> <oznacz jako niedziałające>
--
m.
Twelve Hungry Mammoths - 23-10-2005 18:18
On Tue, 11 Oct 2005 23:02:42 +0200, Piotr Fusik <pfusik@op.pl> wrote:
> Żeby była jasność: nie wolno wykonywać seek/sysseek poza zakresem,
> nawet jeśli jest to ostatnia operacja wykonywana przez skrypt i zwracana
> wartość nie ma znaczenia.
>
> Dlaczego? Przypuśćmy, że niektóre systemy/biblioteki mają błąd
> objawiający się wysypaniem programu lub czymś straszniejszym
> w przypadku takiej operacji.
jakies konkrety? jezeli nie potrafisz wskazac istniejacego systemu z takim
bledem, to argument pada. Ton Hospel pisal kiedys, ze rozwiazania maja
dzialac na _realnie_ istniejacych systemach (juz nie pamietam przy jakiej
okazji). rownie dobrze mozna by zalozyc, ze istnieja systemy, na ktorych
np. print "dupa" wysypuje sie z bugiem. jaki sens ma golfowanie, jezeli
musimy uwazac, czy na jakims KrzakOSie na architekturze xy777 jest bug w
systemowie bibliotece IO?
powtorze po raz n-ty: w perlgolfie _nie chodzi_ o przenosnosc. owszem, w
standardowych regulach jest wymaganie przenosnosci, ale jest to warunek
poprawnosci, a nie cel. celem jest najkrotszy kod. dlatego zadania powinny
byc sformulowane tak, aby ulatwiac pisanie przenosnych rozwiazan. rowniez
dlatego tematy, ktore z definicji sa nieprzenosne, jak binary I/O czy
jakies bardziej intensywne obliczenia zmiennoprzecinkowe nie sa dobrymi
tematami dla perlgolfa (co zreszta widac po tym, jak rzadko sie pojawiaja
i jakie zawsze powoduja problemy).
> Z innej beczki:
>
> Wyczytałem coś o utf8 przy sysread i syswrite.
> Ktoś wie, o co chodzi i czy może to nam psuć szyki?
LOL
> Niezrozumiały jest też komentarz na końcu binmode:
> że ma wpływ m.in. na seek i tell - ciekawe jaki?
> Właśnie wysłałem perlbug-a (#37419).
tak to jest, jak sie golfuje na podstawie dokumentacji. dlatego prosilbym
o nie anulowanie rozwiazan po konkursie, dopoki ktos nie wskaze
rzeczywistego systemu, na ktorym dane rozwiazanie sie wysypuje
(niezaleznie od bajek, ktore mozna wyczytac w dokumentacji). jako
rzeczywisty rozumiem oczywiscie cos podobnego do Unixa, Linuxa, Windowsa
lub MacOSa, nie wersje VMS z 1966 na PDP-11 i odkurzacz.
pzdr
szeryf
Vava - 23-10-2005 18:18
Twelve Hungry Mammoths <someone@microsoft.com> wrote:
[ciach]
>> Niezrozumiały jest też komentarz na końcu binmode:
>> że ma wpływ m.in. na seek i tell - ciekawe jaki?
>> Właśnie wysłałem perlbug-a (#37419).
>
> tak to jest, jak sie golfuje na podstawie dokumentacji. dlatego
> prosilbym o nie anulowanie rozwiazan po konkursie, dopoki ktos nie
> wskaze rzeczywistego systemu, na ktorym dane rozwiazanie sie wysypuje
> (niezaleznie od bajek, ktore mozna wyczytac w dokumentacji). jako
> rzeczywisty rozumiem oczywiscie cos podobnego do Unixa, Linuxa, Windowsa
> lub MacOSa, nie wersje VMS z 1966 na PDP-11 i odkurzacz.
Ja byłbym za odgórnym ustaleniem, na jakim systemie/wersji mają
rozwiązania działać.
Tak jak to ma miejsce w wypadku wersji perla. Przecież w zasadach jest,
że można wręcz wykorzystywać bugi z oficjalnej wersji perla.
Więc dobrać zestaw systemów i tego się trzymać.
Przykładowo - zgodność z Windą 200 i nowszą (w 9x/Me jest sporo różnic w
działaniu perla),
MacOS'em po przejściu na jądro BSD (perl na stare makówki w ogóle jakiś
taki jest
dziwny... ;-)). Do tego uniksy (hmmm... nie mam pomysłu na cezurę ;-)) i
to wszystko...
VMS, Symbian, MorphOS, QNX, BeOS, OS/2, OS/390, PalmOS, EPOC i inne
dziwactwa bym olał,
mimo iż istnieją dla nich binarki perla...
Wręcz zastanawiam się, czy odgórnie dla potrzeb naszego golfa nie uznać,
że system jest
zawsze little-endian, bo wątpię, by wiele osób miało dostęp OS/390 ;-)
I zgadzam się w całej rozciągłości, że w perlu zabawa polega na szukaniu
krótkich
rozwiązań, a nie na spełnianiu skomplikowanych zasad...
Ja, jeśli nie jestem w stanie na poczekaniu sklecić poprawnie działającego
kodu, to w ogóle
nie biorę udziału w golfie ;-)
BTW: OpenVMS nadal jest rozwijany i używany... Jak COBOL - tego nie łatwo
się pozbyć ;-)
Ale nie jestem w stanie sprawdzać na nim rozwiązań, bo na dostępnym mi
systemie jest perl
w wersji 4 :-(
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
Michal Jankowski - 23-10-2005 18:18
Vava <vava-jedenaste-nie-spamuj@plusnet.pl> writes:
> Wręcz zastanawiam się, czy odgórnie dla potrzeb naszego golfa nie
> uznać, że system jest zawsze little-endian, bo wątpię, by wiele osób
> miało dostęp OS/390 ;-)
Not so fast. Mac jest big-endian, Sparc jest big-endian (w ogole
wszystko poza Intelem i VAX-ami).
MJ
Szymon Sokół - 23-10-2005 18:18
On Wed, 12 Oct 2005 21:11:08 +0200, Vava wrote:
> Wręcz zastanawiam się, czy odgórnie dla potrzeb naszego golfa nie uznać,
> że system jest
> zawsze little-endian, bo wątpię, by wiele osób miało dostęp OS/390 ;-)
Well, ja te golfy, w których uczestniczyłem, robiłem na maszynie big-endian
:->
--
Szymon Sokół (SS316-RIPE) -- Network Manager B
Computer Center, AGH - University of Science and Technology, Cracow, Poland O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982 F
Free speech includes the right not to listen, if not interested -- Heinlein H
Maciej Misiak - 23-10-2005 18:18
Michal Jankowski napisał(a):
> "Piotr Fusik" <pfusik@op.pl> writes:
>
>
>>1. Bartosz Kuźma (bartosz) 53.33
>>2. Michal Szafranski (stalker) 56.31
>>3. Piotr Fusik (0xF) 57.29
>>4. Przemysław Kowalczyk (szeryf) 58.28
>
>
> Well... Biorac pod uwage, ze samo:
> sysread STDIN syswrite STDOUT sysseek STDIN
> to sa 43 znaki, to chyba robicie to jakos inaczej 8-)
Tylko niech mi bron Boze ktos teraz nie wyskoczy z opisem metody... Golf
jest w toku, jest taki szalony jaki jest, trudno, ale niech sie skonczy
bez psucia zabawy.
pzdr
Grizzley
Szymon Sokół - 23-10-2005 18:18
On Wed, 12 Oct 2005 21:41:35 +0200, Michal Jankowski wrote:
> Vava <vava-jedenaste-nie-spamuj@plusnet.pl> writes:
>
>> Wręcz zastanawiam się, czy odgórnie dla potrzeb naszego golfa nie
>> uznać, że system jest zawsze little-endian, bo wątpię, by wiele osób
>> miało dostęp OS/390 ;-)
>
> Not so fast. Mac jest big-endian, Sparc jest big-endian (w ogole
> wszystko poza Intelem i VAX-ami).
Uważaj, odkrycie, że istnieje coś poza Intelem może przyprawić kogoś o
wstrząs :->
--
Szymon Sokół (SS316-RIPE) -- Network Manager B
Computer Center, AGH - University of Science and Technology, Cracow, Poland O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982 F
Free speech includes the right not to listen, if not interested -- Heinlein H
Michal Jankowski - 23-10-2005 18:18
Szymon Sokół <szymon@bastard.operator.from.hell.pl> writes:
> Well, ja te golfy, w których uczestniczyłem, robiłem na maszynie big-endian
Nie tylko "końcowością" mogą się systemy różnić: 8-)
perl -V|egrep 'byteorder|Built'|paste - -
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 Built under solaris
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 Built under linux
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 Built under linux
MJ
Piotr Fusik - 23-10-2005 18:18
> > Czy wszyscy uczestnicy są przekonani o zgodności swoich rozwiązań
> > z zadaniem oraz tym, co zostało napisane w tym wątku?
>
> Nie
>
Za to ja tak na 99%. :-)
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Piotr Fusik - 23-10-2005 18:18
> On Tue, 11 Oct 2005 23:02:42 +0200, Piotr Fusik <pfusik@op.pl> wrote:
> > Żeby była jasność: nie wolno wykonywać seek/sysseek poza zakresem,
> > nawet jeśli jest to ostatnia operacja wykonywana przez skrypt i zwracana
> > wartość nie ma znaczenia.
> >
> > Dlaczego? Przypuśćmy, że niektóre systemy/biblioteki mają błąd
> > objawiający się wysypaniem programu lub czymś straszniejszym
> > w przypadku takiej operacji.
>
> jakies konkrety? jezeli nie potrafisz wskazac istniejacego systemu z takim *
> bledem, to argument pada.
Cofam swoje uzasadnienie. Jednak zasada pozostaje - po prostu tak jest
sformułowane zadanie, żeby nie było zbyt proste.
> Ton Hospel pisal kiedys, ze rozwiazania maja dzialac na _realnie_
> istniejacych systemach (juz nie pamietam przy jakiej okazji).
Czyli olewamy systemy, które dopiero powstaną, a na których będą
działać istniejące binarki perla? Ma to sens.
> powtorze po raz n-ty: w perlgolfie _nie chodzi_ o przenosnosc. owszem, w *
> standardowych regulach jest wymaganie przenosnosci, ale jest to warunek *
> poprawnosci, a nie cel. celem jest najkrotszy kod. dlatego zadania powinny *
> byc sformulowane tak, aby ulatwiac pisanie przenosnych rozwiazan. rowniez *
> dlatego tematy, ktore z definicji sa nieprzenosne, jak binary I/O czy *
> jakies bardziej intensywne obliczenia zmiennoprzecinkowe nie sa dobrymi *
> tematami dla perlgolfa (co zreszta widac po tym, jak rzadko sie pojawiaja *
> i jakie zawsze powoduja problemy).
Nikt nikogo nie zmusza do uczestnictwa w tej edycji.
Zamiana -undef na stringa nie jest czymś kosmicznym, a jednak się na niej
przejechałem.
> > Z innej beczki:
> >
> > Wyczytałem coś o utf8 przy sysread i syswrite.
> > Ktoś wie, o co chodzi i czy może to nam psuć szyki?
>
> LOL
Co w tym zabawnego? Nie chciałbyś wiedzieć, czy możesz perlem odczytać
dane binarne przy pomocy sysread? Uważasz, że I/O perla nadaje się
wyłącznie do plików tekstowych?
Moim zdaniem golf jest dobrą motywacją do nauki Perla, a nie tylko zabawą
w pisanie jak najkrótszych nikomu nie potrzebnych programów.
> > Niezrozumiały jest też komentarz na końcu binmode:
> > że ma wpływ m.in. na seek i tell - ciekawe jaki?
> > Właśnie wysłałem perlbug-a (#37419).
>
> tak to jest, jak sie golfuje na podstawie dokumentacji. dlatego prosilbym *
> o nie anulowanie rozwiazan po konkursie, dopoki ktos nie wskaze *
> rzeczywistego systemu, na ktorym dane rozwiazanie sie wysypuje *
> (niezaleznie od bajek, ktore mozna wyczytac w dokumentacji).
Wychwycenie błędu w dokumentacji perla jest jak najbardziej pożądane.
Uważasz więc, że można np. spokojnie zakładać, że zaalokowanie 2**42 bajtów
się nie powiedzie, bo raczej nikt nie ma tyle pamięci? Skąd wiesz, że REALNY
komputer gdzieś w Pentagonie tyle nie ma? Po to mamy treść zadania
i dokumentację Perla, aby pisać przenośne programy bez testowania ich
na wszystkich możliwych konfiguracjach sprzętu.
Zgadzam się, wygodniej byłoby postawić "farmę golfa" (pole golfowe?)
złożoną z kilku różnych systemów i udostępnić ją każdemu do testowania
swych rozwiązań, co by przesądzało o ich poprawności. Tylko kto to
zasponsoruje?
> jako rzeczywisty rozumiem oczywiscie cos podobnego do Unixa,
> Linuxa, Windowsa lub MacOSa, nie wersje VMS z 1966 na PDP-11 i odkurzacz.
Jakbyś przejrzał perl5-porters z ostatnich miesięcy, to zauważyłbyś,
że najpopularniejsze tematy to VMS i EBCDIC.
Pozdrawiam,
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Piotr Fusik - 23-10-2005 18:18
> Ja byłbym za odgórnym ustaleniem, na jakim systemie/wersji mają *
> rozwiązania działać.
tia i jeszcze ustalimy Jedyny Słuszny Edytor Tekstu Dla Perlgolfa. ;-)
Wolałbym uniknąć wojen.
> Tak jak to ma miejsce w wypadku wersji perla. Przecież w zasadach jest,
> że można wręcz wykorzystywać bugi z oficjalnej wersji perla.
>
> Więc dobrać zestaw systemów i tego się trzymać.
> Przykładowo - zgodność z Windą 200 i nowszą (w 9x/Me jest sporo różnic w *
> działaniu perla),
Mimo wszystko windy serii 9x są wciąż bardzo popularne.
> MacOS'em po przejściu na jądro BSD (perl na stare makówki w ogóle jakiś *
> taki jest
> dziwny... ;-)). Do tego uniksy (hmmm... nie mam pomysłu na cezurę ;-)) i *
> to wszystko...
Jak nie ma cenzury na uniksy, to prawie jakby nie było żadnej cenzury.
>
> VMS, Symbian, MorphOS, QNX, BeOS, OS/2, OS/390, PalmOS, EPOC i inne *
> dziwactwa bym olał,
> mimo iż istnieją dla nich binarki perla...
Może kryterium będzie supportowanie systemu przez producenta? ;-)
> Wręcz zastanawiam się, czy odgórnie dla potrzeb naszego golfa nie uznać, *
> że system jest
> zawsze little-endian, bo wątpię, by wiele osób miało dostęp OS/390 ;-)
Bez komentarza...
> I zgadzam się w całej rozciągłości, że w perlu zabawa polega na szukaniu *
> krótkich
> rozwiązań, a nie na spełnianiu skomplikowanych zasad...
> Ja, jeśli nie jestem w stanie na poczekaniu sklecić poprawnie działającego *
> kodu, to w ogóle nie biorę udziału w golfie ;-)
Ta edycja nawet po uwzględnieniu różnych kruczków i tak pozostaje
jedną z prostszych.
> BTW: OpenVMS nadal jest rozwijany i używany... Jak COBOL - tego nie łatwo *
> się pozbyć ;-)
> Ale nie jestem w stanie sprawdzać na nim rozwiązań, bo na dostępnym mi *
> systemie jest perl
> w wersji 4 :-(
A ja nie mam dostępu do MacOS X. Więc co bym zyskał na cenzurze systemów
pozostawiającej ten system?
OpenVMSy są publicznie dostępne przez internet, więc nawet jeśli nie ma
na nich perla 5.8.7 to może by się udało go skompilować.
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Piotr Fusik - 23-10-2005 18:18
> > Zadanie nie określa, że STDIN będzie otwarty np. na zwykłym pliku.
> > Np. w Windowsie zadziała:
> > dir | perl tac.pl
>
> Nie wiem co prawda do konca, jaki jest twoj punkt bedacy,
punkt bedacy?
> ale o ile mi
> wiadomo, przy takiej konstrukcji w dosie (wiec i w win$ pewnie tez)
> dostawalo sie na wejscie najzwyklejszy plik tymczasowy...
Najzwyklejszy plik tymczasowy to już nie taki zwykły plik.
> Seek na rurce to raczej, no wiesz, ten, tego...
>
No wiem.
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Michal Jankowski - 23-10-2005 18:18
"Piotr Fusik" <pfusik@op.pl> writes:
> Najzwyklejszy plik tymczasowy to już nie taki zwykły plik.
Inaczej na nim seek dziala?
MJ
Piotr Fusik - 23-10-2005 18:18
> > Najzwyklejszy plik tymczasowy to już nie taki zwykły plik.
>
> Inaczej na nim seek dziala?
>
POSIX nie precyzuje jak działa.
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Piotr Fusik - 23-10-2005 18:18
Eh, jeśli ktoś ma ochotę zrobić "English version", to niech ją
zapostuje na grupę, to ja albo admin kernelpanica ją wrzucimy.
1. Christian Schuster (blackout) 30.34
2. Piotr Fusik (0xF) 57.29
3. Michal Szafranski (stalker) 57.34
4. Przemysław Kowalczyk (szeryf) 58.28
5. Bartosz Kuźma (bartosz) 66.36
6. Maciej Misiak (grizzley) 76.35
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Leonard Milcin Jr. - 23-10-2005 18:18
Piotr Fusik wrote:
> 1. Christian Schuster (blackout) 30.34
Że co?
Piotr Fusik - 23-10-2005 18:18
> > 1. Christian Schuster (blackout) *30.34
>
> Że co?
>
Obstawiam, że nie zrozumiał zadania.
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Maciej Misiak - 23-10-2005 18:18
Piotr Fusik napisał(a):
> Moim zdaniem golf jest dobrą motywacją do nauki Perla, a nie tylko zabawą
> w pisanie jak najkrótszych nikomu nie potrzebnych programów.
Podpisuje sie obiema rekami. Z tego rowniez wzgledu mam nadzieje, ze 2
lub 3 edycje zmusza mnie do przerobienia tematyki utf-8, bo w tym
temacie tez mam solidne braki. Tylko blizej grudnia prosze, jak bede
miec juz troche wiecej czasu... :)
Grizzley
Twelve Hungry Mammoths - 23-10-2005 18:18
On Wed, 12 Oct 2005 21:41:35 +0200, Michal Jankowski <michalj@fuw.edu.pl>
wrote:
>> Wręcz zastanawiam się, czy odgórnie dla potrzeb naszego golfa nie
>> uznać, że system jest zawsze little-endian, bo wątpię, by wiele osób
>> miało dostęp OS/390 ;-)
>
> Not so fast. Mac jest big-endian, Sparc jest big-endian (w ogole
> wszystko poza Intelem i VAX-ami).
nie Mac, tylko Motorola czy co tam jest w Macach. no i Apple oglosilo
niedawno, ze przechodzi na Intela (-:
pzdr
szeryf
Twelve Hungry Mammoths - 23-10-2005 18:18
On Thu, 13 Oct 2005 10:22:07 +0200, Piotr Fusik <pfusik@op.pl> wrote:
>> Ton Hospel pisal kiedys, ze rozwiazania maja dzialac na _realnie_
>> istniejacych systemach (juz nie pamietam przy jakiej okazji).
>
> Czyli olewamy systemy, które dopiero powstaną, a na których będą
> działać istniejące binarki perla? Ma to sens.
nie rozumiem. oczywiscie, ze olewamy systemy, ktore dopiero powstana.
chcesz za 10 lat dyskwalifikowac rozwiazania z tej edycji golfa? (-:
> Nikt nikogo nie zmusza do uczestnictwa w tej edycji.
ale ja _chce_ uczestniczyc, a przy okazji tez pomarudzic (-:
> Zamiana -undef na stringa nie jest czymś kosmicznym, a jednak się na niej
> przejechałem.
jezeli dobrze zrozumialem (czego nie jestem pewien :) problem z -undef, to
jest to jakis bug w Perlu dla Windowsa. IMHO czym innym jest bug w Perlu
(chocby dla jednego, ale popularnego, systemu), czym innym bug w
bibliotece I/O systemu.
> Co w tym zabawnego? Nie chciałbyś wiedzieć, czy możesz perlem odczytać
> dane binarne przy pomocy sysread? Uważasz, że I/O perla nadaje się
> wyłącznie do plików tekstowych?
>
> Moim zdaniem golf jest dobrą motywacją do nauki Perla, a nie tylko zabawą
> w pisanie jak najkrótszych nikomu nie potrzebnych programów.
no coz, w sumie masz racje. chociaz dla mnie perlgolf to raczej to drugie
(-:
jezeli juz cos pisze w Perlu (poza perlgolfem), to nie zalezy mi na
przenosnosci.
> Uważasz więc, że można np. spokojnie zakładać, że zaalokowanie 2**42
> bajtów
> się nie powiedzie, bo raczej nikt nie ma tyle pamięci? Skąd wiesz, że
> REALNY
> komputer gdzieś w Pentagonie tyle nie ma?
wlasnie po to, by nie bylo takich argumentow, sa standardowe zasady
perlgolfa. tam masz napisane m.in. ile pamieci na pewno bedziesz mial, a
ile na pewno nie bedziesz mial. te liczby nie wziely sie z sufitu. gdy
kazdy bedzie mial w domu taki komputer, jak dzisiaj Pentagon, to na pewno
zostana zmienione.
> Po to mamy treść zadania
> i dokumentację Perla
....i standardowe zasady (-:
> aby pisać przenośne programy bez testowania ich
> na wszystkich możliwych konfiguracjach sprzętu.
nie, uwazam po prostu, ze lepiej, jezeli temat zadania dobrany jest tak,
ze przenosnosc nie jest glownym zmartwieniem golfujacych. no ale
powiedzmy, ze czasem przyda sie odmiana (-:
> Jakbyś przejrzał perl5-porters z ostatnich miesięcy, to zauważyłbyś,
> że najpopularniejsze tematy to VMS i EBCDIC.
i co z tego wynika? jaki to procent uzytkownikow? ilu z nich bawi sie w
golfa?
pzdr
szeryf
Piotr Fusik - 23-10-2005 18:18
> > Zamiana -undef na stringa nie jest czymś kosmicznym, a jednak się na niej
> > przejechałem.
>
> jezeli dobrze zrozumialem (czego nie jestem pewien :) problem z -undef, to *
> jest to jakis bug w Perlu dla Windowsa. IMHO czym innym jest bug w Perlu *
> (chocby dla jednego, ale popularnego, systemu), czym innym bug w *
> bibliotece I/O systemu.
Nie chodzilo o bug w kodzie perla dla Windowsa, tylko o niekompatybilnosc
funkcji libc zamieniajacej double na stringa (zdaje sie, ze implementacja
M$ jest niezgodna ze standardem). A wiec do buga w bibliotece I/O
niedaleko, zaryzykowalbym nawet stwierdzenie, ze taki bug jest bardziej
prawdopodobny, niz w kodzie, ktory nie zalezy przeciez od systemu operacyjnego,
tylko od architektury (a wiec nie spodziewalem sie, ze perl 5.8.6 na Windowsa
zrobi cos innego niz perl 5.8.6 na Linuxa/x86).
>
> jezeli juz cos pisze w Perlu (poza perlgolfem), to nie zalezy mi na *
> przenosnosci.
To teraz Cie rozumiem.
> > Jakbyś przejrzał perl5-porters z ostatnich miesięcy, to zauważyłbyś,
> > że najpopularniejsze tematy to VMS i EBCDIC.
>
> i co z tego wynika? jaki to procent uzytkownikow? ilu z nich bawi sie w *
> golfa?
>
No niewiele wynika i to znikomy procent uzytkownikow perla.
Ale Ton czasami tam postuje. :-)
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Leonard Milcin Jr. - 23-10-2005 18:19
Piotr Fusik wrote:
> Nie chodzilo o bug w kodzie perla dla Windowsa, tylko o niekompatybilnosc
> funkcji libc zamieniajacej double na stringa (zdaje sie, ze implementacja
> M$ jest niezgodna ze standardem)
Z jakim standardem? POSIX? M$ jest tym akurat najmniej zainteresowany.
L.
Piotr Fusik - 23-10-2005 18:19
> Piotr Fusik wrote:
> > Nie chodzilo o bug w kodzie perla dla Windowsa, tylko o niekompatybilnosc
> > funkcji libc zamieniajacej double na stringa (zdaje sie, ze implementacja
> > M$ jest niezgodna ze standardem)
>
> Z jakim standardem? POSIX? M$ jest tym akurat najmniej zainteresowany.
>
Tak? A kiedyś trąbili, że W2K jest zgodne z POSIXem.
Przed chwilą zgoglowałem:
"Windows 2000 supports character-based POSIX-based applications
that conform to the POSIX.1 standard."
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Piotr Fusik - 23-10-2005 18:19
> Wyczytałem coś o utf8 przy sysread i syswrite.
> Ktoś wie, o co chodzi i czy może to nam psuć szyki?
>
Wygląda na to, że nie ma problemu, chyba że ktoś sam się o niego
poprosi używając np. opcji -C perla. Zakładamy, że nie będzie
żadnego ":utf8" w zmiennej środowiskowej PERLIO (mogłoby sprawiać
problemy nawet w edycjach "tekstowych" ze znaczkami o kodach >127).
Pozdrawiam,
0xF
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
obsługa kamery internetowej (usb) przez jave
[PgSQL] optymalizacja - baza na oddzielnym serwerze?
Monitory...
[MySQL] GREATEST i NULL
programy do sql -mySQL
ktory lepszy???? panasonic czy olympus
Dan Margulis - Korekcja I Separacja - Promocja 30% taniej
POMOCY!!!!pytanie O HTML
wiele do wielu ?
Corel, Flash - biale obramowanie
zanotowane.pldoc.pisz.plpdf.pisz.plmarcelq.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
