From stas w datos.pl Tue May 4 10:03:14 2010 From: stas w datos.pl (Stanislaw Romanski) Date: Tue, 4 May 2010 19:03:14 +0200 Subject: [Warszawa-pm] Ku pokrzepieniu serc Message-ID: <1E4B9F0088FE4A16AB57137209AFAF65@datos57604fe5b> Cześć, Firma Sedlak & Sedlak opublikowała wyniki badań nad zarobkami w IT. Zgadnijcie, jaki język programowania jest najbardziej PLN-dajny ...? http://gazetapraca.pl:80/gazetapraca/1,103345,7788747,Wynagrodzenia_na_stanowiskach_IT_w_2009_roku.html Pzdr, Staś Romański -------------- następna część --------- Załącznik HTML został usunięty... URL: From tadzikes w gmail.com Tue May 4 12:22:48 2010 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Tue, 4 May 2010 19:22:48 +0000 Subject: [Warszawa-pm] Ku pokrzepieniu serc In-Reply-To: <1E4B9F0088FE4A16AB57137209AFAF65@datos57604fe5b> References: <1E4B9F0088FE4A16AB57137209AFAF65@datos57604fe5b> Message-ID: <20100504192248.GC1324@yavin4> On 4-05-2010 19:03:14, Stanislaw Romanski wrote: > > Cześć, > > Firma Sedlak & Sedlak opublikowała wyniki badań nad zarobkami w IT. > Zgadnijcie, jaki język programowania jest najbardziej PLN-dajny ...? Zaskakuje mnie dość wysoki wynik basha/awka. Może to raczej zestawienie tego, jakie języki znają ci najlepiej zarabiający. Patrząc na te w/w wychodziłoby na moje oko, że to sysadmini ;) Pozdrawiam, Tadek From czarek w therek.net Tue May 4 10:38:04 2010 From: czarek w therek.net (Cezary Morga) Date: Tue, 4 May 2010 19:38:04 +0200 Subject: [Warszawa-pm] Ku pokrzepieniu serc In-Reply-To: <20100504192248.GC1324@yavin4> References: <1E4B9F0088FE4A16AB57137209AFAF65@datos57604fe5b> <20100504192248.GC1324@yavin4> Message-ID: <201005041938.04689.czarek@therek.net> On Tuesday, 4 of May 2010 21:22:48 Tadeusz Sośnierz wrote: > On 4-05-2010 19:03:14, Stanislaw Romanski wrote: > > Cześć, > > > > Firma Sedlak & Sedlak opublikowała wyniki badań nad zarobkami w IT. > > Zgadnijcie, jaki język programowania jest najbardziej PLN-dajny ...? > > Zaskakuje mnie dość wysoki wynik basha/awka. Może to raczej zestawienie > tego, jakie języki znają ci najlepiej zarabiający. Patrząc na te w/w > wychodziłoby na moje oko, że to sysadmini ;) Yeah baby! Czyli dobrze, że zrobiłem sobie certyfikat z administracji Solarisem. Szkoda tylko, że z nim na co dzień nie pracuję :) Swoją drogą, nie chce mi się coś xwierzyć, że graficy komputerowi zarabiają średnio (ok, to jest mediana) 2500 PLN. -- Cezary Morga "I believe in looking reality straight in the eye and denying it." (Garrison Keillor) From pp w webtel.pl Tue May 4 16:06:15 2010 From: pp w webtel.pl (pp) Date: Wed, 05 May 2010 01:06:15 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: References: Message-ID: On Wed, 21 Apr 2010 12:49:13 +0100, Zbigniew Lukasiak wrote: > Hej! > > Ostatnio trochę pracowałem nad http://github.com/zby/WebNano - i > wydaje mi się, że to już może być całkiem użyteczne. Macie jakieś > pomysły na ciekawe przykłady? > > Na razie za dokumentację muszą wystarczyć testy - ale mam nadzieję, że > łatwo się zorientować o co chodzi. jak juz zrozumiesz placka, to chyba mozna sie polapac;) znalazlem chwile i posiedzialem sobie troche nad tym plackiem. jak rozumiem, WebNano to taka konkurencja dla Plack::Middleware ? kusi aby napisac sobie framework;) poki co prosta aplikacyjka "hello world" -------------------- package t1; use parent qw(Plack::Component); use Plack::Response; sub call { my ( $self, $env ) = @_; return [ 200, [ 'Content-Type' => 'text/html', 'X-PP' => 'PP' ], ['PEPE'] ]; } t1->to_app; ---------------------- odpalana przez Plack::App::PSGIBin ------------- use Plack::App::PSGIBin; use Plack::Builder; my $app = Plack::App::PSGIBin->new( {'root' => '/home/pp/psgi/1/app'} )->to_app; builder { mount "/psgi" => $app; }; ------------- dziala "in no time" ;) odpalana przez Starleta (serwer http w perlu) -------------------- This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.1 (be patient) Server Software: Plack::Handler::Starlet Server Hostname: 127.0.0.1 Server Port: 5000 Document Path: /psgi/t1.psgi Document Length: 29 bytes Concurrency Level: 1 Time taken for tests: 9.499 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 1730000 bytes HTML transferred: 290000 bytes Requests per second: 1052.77 [#/sec] (mean) Time per request: 0.950 [ms] (mean) Time per request: 0.950 [ms] (mean, across all concurrent requests) Transfer rate: 177.86 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 1 Processing: 1 1 0.9 1 23 Waiting: 0 1 0.9 1 22 Total: 1 1 0.9 1 23 Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 1 98% 2 99% 7 100% 23 (longest request) --- a przez lighttpd i FastCGI --- This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.1 (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 10000 requests Finished 10000 requests Server Software: lighttpd/1.4.26 Server Hostname: 127.0.0.1 Server Port: 80 Document Path: /psgi/psgi/t1.psgi Document Length: 29 bytes Concurrency Level: 1 Time taken for tests: 5.758 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 1640020 bytes HTML transferred: 290000 bytes Requests per second: 1736.77 [#/sec] (mean) Time per request: 0.576 [ms] (mean) Time per request: 0.576 [ms] (mean, across all concurrent requests) Transfer rate: 278.16 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 1 0.4 1 29 Waiting: 0 0 0.4 0 28 Total: 0 1 0.4 1 29 Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 1 98% 1 99% 1 100% 29 (longest request) --- na intel core2duo 2.8GHz widac, ze light jednak lepszy od starleta;) choc przy wylaczonym fastcgi light obslugiwal polaczenie (zwracajac blad 503) w 0.1 sekundy, czyli cala komunikacja z perlem i generowanie napisu zajmowala 0.4 sekundy jak znajde czas to przerobie mala aplikacyjke co dziala przez apache/fastcgi/CGI::Application,CGI,Template::Toolkit na apache/fastcgi/plack,Template::Toolkit i porownam ile sie zyskuje uzywajac plack'a zamiast CGI.pm no i pytanie: pisac wlasny framework, czy kolejne moduly Plack::Middleware ;) zeby to jeszcze mozna puszczac watkami na wielu procesorach jednoczesnie zachowujac dostep do wspolnej pamieci dla dachych (zamiast kilku niezaleznych procesow/interpreterow jak to jest obecnie) , ech... -- pzdr pp From zzbbyy w gmail.com Wed May 5 07:24:02 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Wed, 5 May 2010 15:24:02 +0100 Subject: [Warszawa-pm] WebNano In-Reply-To: References: Message-ID: 2010/5/5 pp : > On Wed, 21 Apr 2010 12:49:13 +0100, Zbigniew Lukasiak > wrote: >> Hej! >> >> Ostatnio trochę pracowałem nad http://github.com/zby/WebNano - i >> wydaje mi się, że to już może być całkiem użyteczne. Macie jakieś >> pomysły na ciekawe przykłady? >> >> Na razie za dokumentację muszą wystarczyć testy - ale mam nadzieję, że >> łatwo się zorientować o co chodzi. > > > jak juz zrozumiesz placka, to chyba mozna sie polapac;) > > > znalazlem chwile i posiedzialem sobie troche nad tym plackiem. > > jak rozumiem, WebNano to taka konkurencja dla Plack::Middleware ? > > kusi aby napisac sobie framework;) Z middleware jako takim to na pewno nie chciałbym konkurować. Będę musiał się nad tym zastanowić jak to moje rozwiązanie umieścić w tym kontekście, na pewno można je używać razem z wieloma plackowymi middleware. Jak masz jakieś własne pomysły co by się miało w takim frameworku znaleźć to możemy podyskutować. WebNano jest ciągle eksperymentem - więc może porzucę go dla Twojego rozwiązania :) Pozdr, Z. From pp w webtel.pl Wed May 5 08:31:57 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Wed, 05 May 2010 17:31:57 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: References: Message-ID: <4BE18F6D.6080901@webtel.pl> > Z middleware jako takim to na pewno nie chciałbym konkurować. Będę > musiał się nad tym zastanowić jak to moje rozwiązanie umieścić w tym > kontekście, na pewno można je używać razem z wieloma plackowymi > middleware. > > Jak masz jakieś własne pomysły co by się miało w takim frameworku > znaleźć to możemy podyskutować. WebNano jest ciągle eksperymentem - > więc może porzucę go dla Twojego rozwiązania :) rozwiazania to ja nie mam. na pewno potrzebne jest howto, jak skladac do kupy poszczegolne elementy aby zbudowac dzialajaca aplikacje. troche mi zajelo zrozumienie te elementy to standard, ktory wystepuje w kazdej aplikacji autentykacja autoryzacja cache baza danych szablony walidacja danych/formularzy filtry uslugi (SOAP, REST) moze wewnetrzne redirecty, automatyczne generowanie formularzy szablony tez sliska sprawa. niektorzy lubia oddzielenie kodu od prezentacji (Tempalte::Tolkit) albo programowanie w perlu zamiast uczenia sie jezyka szablonu (HTML::Mason) Middleware daje proste stackowanie poszczegolnych modulow, kore sa uruchamiane potem w kolejnosci dodawania mozna w ten sposob dodac np autoryzacje czy inne elementy lancucha przetwarzania requestu dla mnie zasadnicza zaleta jest mozliwosc uruchomienia tego przez fastcgi, majac Plack::Request zamiast archaicznego CGI.pm (jak juz pisalem wczesniej) teraz musialbym napisac mapowanie Plack::Request na Apache::Request albo Plack::Request na jakies Plack::CGI (moze juz jest?) i wtedy juz moglbym podpiac HTML::Mason jak w mod_perlu (bez CGI.pm, ktory mnie jakos dziwnie uwiera) albo CGI::Ex. Mason ma wlasny system cache. A troche brakuje mi takiej implementacji, ktora automatycznie czyscilaby elementy wyzszego poziomu, gdy zmieniaja sie elemetny nizszego poziomu. czyli mialbym cache calej strony, i poszceglnych elementow wspolnych dla roznych stron. i przy zmianie jednego z takich elementow czyscilby sie cache rowniez stron zaleznych (rowniez posrednio) od takiego malego elementu. a moze lepiej zintegrowac CGI::Ex z Plack? i rozbudowywac CGI::Ex? choc bardzo podoba mi sie idea Middleware i wkladania kolejnych swoich modulow w proces przetwarzania requestu, zamiast decydowania sie na framework ze swoim "process flow" jak dla mnie, framework musi zalatwiac wszystko tak, aby dalo sie myszka wyklikac aplikacje. inaczej bedzie to tylko kolejne "nieskonczone narzedzie" alternatywa to robic male klocki pasujace do siebie, i niech kazdy buduje swoj framework/aplikacje. czyli bardziej taki zestaw klockow (istniejacych,nowych, byle pasujacych do siebie) plus zestaw "recepies". dla bardziej zaawansowanych a moze lepiej w tym czasie pograc na konsoli ;) ja osobiscie dla siebie widze zapotrzebowanie na cos co pozwoli mi szybko pisac cos co bedzie wystawiane uslugami (zarowno SOAP jak i REST, zwracajace XML,HTML lub JSON). strona wizualna mnie mniej interesuje, a Placka widze jako transport HTTP dla tych uslug. jakby miec framework na cos takiego, moze ten pomysl odciagnalby mnie od konsoli. aha, poczytalem o Moose. powoli sie przekonuje :) tym bardziej, ze to styl perla6 -- pp From pp w webtel.pl Fri May 7 03:34:10 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Fri, 07 May 2010 12:34:10 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE18F6D.6080901@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> Message-ID: <4BE3ECA2.8090507@webtel.pl> postawilem sobie defaultowa aplikacje catalysta zbudowana catalyst.pl Catapp i podmienione domyslne body na 'Hello world' w stosunku do poprzedniej zrobionej w plack/psgi, o ktorej pisalem wczesniej, apache benchmark pokazuje Catalyst: ./script/catapp_server.pl ab -n 1000 http://localhost:3000/ daje 6.6ms/request (151 req/sek) PSGI: plackup main.psgi ab -n 1000 http://localhost:5000/psgi/t1.psgi daje 1.8 ms/req (560 req/sek) jak w kazdym magicznym kodzie/frameworku, wygoda kosztuje :) From pp w webtel.pl Fri May 7 05:03:32 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Fri, 07 May 2010 14:03:32 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE3ECA2.8090507@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> Message-ID: <4BE40194.5010406@webtel.pl> ciag dalszy zabawy, prosta strona przez Template w catalyscie script/catapp_create.pl view TT TT root/hello.tt "Hello TT World" sub hello :Global { my ( $self, $c ) = @_; $c->stash(template => 'hello.tt'); } PSGI: t2.psgi package t2; use parent qw(Plack::Component); use Plack::Response; use Template; my $tt = Template->new({ INCLUDE_PATH => '/home/pp/cat1/CatApp/root', INTERPOLATE => 1, }); sub call { my ( $self, $env ) = @_; my $body; $tt->process('hello.tt',{},\$body); return [ 200, [ 'Content-Type' => 'text/html', 'X-PP' => 'PP' ], [ $body ] ]; } t2->to_app; Catalyst: /usr/sbin/ab -n 1000 http://localhost:3000/hello 7.946 ms/req (125.85 req/sek) (dla porownania catalyst z hello world jako sub { return "hello world"} czyli poprzednia wersja /usr/sbin/ab -n 1000 http://localhost:3000/ 6.946 ms/req (143.97 req/sek) PSGI: /usr/sbin/ab -n 1000 http://localhost:5000/psgi/t2.psgi 2.194 ms/req ( 455.81 req/sek) (hello world jako sub { return "hello world"}) /usr/sbin/ab -n 1000 http://localhost:5000/psgi/t1.psgi 1.854 ms/req ( 539.38 req/sek) czyli wczytywanie pliku przez TT nie daje duzej straty czasowej a te liczby to trzeba z przymrozeniem oka brac, bo testuje na desktopie i wyniki plywaja o kilka/nascie procent w zaleznosci co sie na nim dzieje. psgi wykorzystalbym do rest-a, do wspolpracy z ajaxem. albo zewnetrznymi uslugami. a generowanie stron powierzyl catalystowi. tu widze sile plack/psgi nalozenie na to frameworku (poza autoryzacja) zabije wydajnosc, a catalysta i tak sie nie przeskoczy jesli idzie o funkjonalnosc From pp w webtel.pl Fri May 7 06:17:50 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Fri, 07 May 2010 15:17:50 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE40194.5010406@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> Message-ID: <4BE412FE.4060303@webtel.pl> a proste hello.php "Hello PHP World" daje 1500 req/sek :( niezaleznie czy przez apache z php czy lighttpd/fastcgi/php nie zeby porownywac z catalystem, ale juz z plackiem plack przez fastcgi i lighttpd z "sub {return "hello world"}" max co dalo to 746 req/sek czyli 2 razy wolniej niz php :( czemu Plack::App::PSGIBin i t1.psgi daje taki narzut w stosunku do php? czas na sprawdzenie mod_perl i Apache::Registry ? From zzbbyy w gmail.com Fri May 7 06:36:13 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Fri, 7 May 2010 14:36:13 +0100 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE412FE.4060303@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> Message-ID: 2010/5/7 piotr pogorzelski : > a proste hello.php > "Hello PHP World" > daje 1500 req/sek :( > > niezaleznie czy przez apache z php > czy lighttpd/fastcgi/php > > > nie zeby porownywac z catalystem, ale juz z plackiem > > plack przez fastcgi i lighttpd z "sub {return "hello world"}" > max co dalo to 746 req/sek > > czyli 2 razy wolniej niz php :( > > czemu Plack::App::PSGIBin i t1.psgi daje taki narzut w stosunku do php? > > > czas na sprawdzenie mod_perl i Apache::Registry ? A to nie wiem, ale miyagawa kiedys gdzies publikowal calkiem niezle wyniki Placka przy serwowaniu statycznych plikow - byly calkiem zblizone do golego apacha. Moze to zalezy z jakim serwerem? Probowales Starmana? Na githubie widzialem jeszcze jakies inne jak http://github.com/stash/Feersum - ktory ma tez byc podobno bardzo szybki. Z. From pp w webtel.pl Fri May 7 07:32:06 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Fri, 07 May 2010 16:32:06 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> Message-ID: <4BE42466.6000103@webtel.pl> > A to nie wiem, ale miyagawa kiedys gdzies publikowal calkiem niezle > wyniki Placka przy serwowaniu statycznych plikow - byly calkiem > zblizone do golego apacha. Moze to zalezy z jakim serwerem? > Probowales Starmana? Na githubie widzialem jeszcze jakies inne jak > http://github.com/stash/Feersum - ktory ma tez byc podobno bardzo > szybki. > starman,starlet - podobnie. light/fastcgi jest od nich szybszy mimo, ze jest przejscie przez fastcgi to lifht na tyle szybko serwuje request, ze zarabia nawet na obluge fastcgi (starlet/starman to perl, czyli serwer i kod zwracajacy strng "hello world" jest w jednym interperterze perla) takie juz zupelnie "raw" fastcgi z perlem czyli skrypt perla fcgi na sockecie --------- use FCGI; my $socket = FCGI::OpenSocket( "/tmp/perl.socket", 5 ); my $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR, \%ENV, $socket ); my $count; while( $request->Accept() >= 0 ) { print STDERR "request\n"; print "Content-type: text/html\r\n\r\n"; print "hello perlFCGI world\n"; } FCGI::CloseSocket( $socket ); ------------- i lighttpd jako front-end (ta sama instancja co php) daje ab -n 1000 http://localhost/perl/ 0.477 ms/req (2098 req/sek) uff, czyli da sie szybciej niz php (1500 req/sek) po wylczeniu socketu sam light jest w stanie wygenerowac 4000 req/sek z odpowiedzia 503 - Service Not Available ale 2000 raw fcgi vs 750 placka trzeba pamietac, ze rawcgi jeszcze musialby parsowac parametry plack to pewnie robi przy tworzeniu requestu czy php to robi przy takiej prostej stronie, nie wiem moze dopiero przy pierwszym odwolaniu do parametrow? no i takie testy, to zadne testy, ot sprawdzenie jaki jest narzut technologi/frameworku i szacowanie co sie dzieje, co daje plack w stosunku do reszty dostepnych narzedzi dodanie do tego "raw" fastcgi parsowania argumentow przez CGI ---- use FCGI; use CGI; my $socket = FCGI::OpenSocket( "/tmp/perl.socket", 5 ); my $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR, \%ENV, $socket ); my $count; while( $request->Accept() >= 0 ) { my $q=CGI->new; print STDERR "request\n"; print "Content-type: text/html\r\n\r\n"; print "hello perlFCGI world\n ". $q->param('hello') . "\n"; } FCGI::CloseSocket( $socket ); ---- daje ab -n 1000 http://localhost/perl/ 0.750 ms/req (1332.83 req/sek) CGI tyle zjada ale nadal zjada mniej niz Plack :( gdy czytalem o PSGI nie spodobal mi sie fragment, gdzie napisali, ze decyzje odnosnie protokolu pdejmowali tak aby bylo latwo napisac drajwer do frameworkow. aby latwo przejsc z CGI na PSGI, echhh no i pisali drajwery w godzine a potem latami tracisz polowe wydajnosci serwera teraz czas zobaczyc alternatywne moduly CGI albo znalezc/napisac cos co zamieni FCGI na request ala plack czy apache request object, cgi object i wtedy jest sie w tym samym miejscu co plack, tylko, ze z wydajnoscia x2 w stosunku do placka a fcgi jest uniwersalne, niezaleznie od serwera http -- pp From pp w webtel.pl Fri May 7 07:48:56 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Fri, 07 May 2010 16:48:56 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE42466.6000103@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> Message-ID: <4BE42858.8040907@webtel.pl> CGI ca 1350 req/sek CGI::Simple ca 1630 req/sek CGI::Minimal ca 1680 req/sek czyli porownywalnie z php 1500 req/sek sorry plack, ale biznes is biznes ;) From zzbbyy w gmail.com Fri May 7 07:57:08 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Fri, 7 May 2010 15:57:08 +0100 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE42466.6000103@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> Message-ID: No dobra - takie zabawy to fajne sa - ale porzucając je na chwile i wracajac do tematu frejmworkow (moze ktos zna jakies spolszczenie?) to wydaje mi się, że Catalyst przechodzi teraz w faze stagnacji, jest już za duży i za skomplikowany i już w sumie za bardzo nie będzie się rozwijał. W grudniu zapłacono mi za zrobienie Application-Context split czyli rozdzielenie kontekstu ktory powstaje od nowa przy kazdym requescie i aplikacji ktora trwa. Miala to byc rutynowa i krotka robotka i mialem dostac za to 100$, poniewaz i tak nie mialem co robic i w sumie ciekawilo mnie co tam w środku Catalysta jest to sie zgodzilem, oczywiscie trwalo to w koncu 2 tygodnie i i tak to co napisalem chyba trzeba bedzie powtarzac - no ale sobie obejrzalem te wnetrznosc (a zaplate mi wkoncu podwojono). W kazdym razie to co zrobilem sobie tam siedzi, podobno jest to jedena z najwazniejszych zmian potrzebnych Catalystowi - ale jakos nie ma komu moje zmiany przeniesc do 'trunka', bo to jest ogromna robota. Catalyst ma swoj stack, dispatching itp - moim zdaniem to jest to zupelny balagan i ta funkcjonalnosc ktora daje mozna by osiagnac duzo mniejszym narzutem kodu. Dlatego mam nadzieje na rozwoj Placka ktory otwiera rozne nowe mozliwosci. Z. 2010/5/7 piotr pogorzelski : > >> A to nie wiem, ale miyagawa kiedys gdzies publikowal calkiem niezle >> wyniki Placka przy serwowaniu statycznych plikow - byly calkiem >> zblizone do golego apacha. Moze to zalezy z jakim serwerem? >> Probowales Starmana? Na githubie widzialem jeszcze jakies inne jak >> http://github.com/stash/Feersum - ktory ma tez byc podobno bardzo >> szybki. >> > > starman,starlet - podobnie. light/fastcgi jest od nich szybszy > mimo, ze jest przejscie przez fastcgi to lifht > na tyle szybko serwuje request, ze zarabia nawet na > obluge fastcgi (starlet/starman to perl, czyli serwer i kod > zwracajacy strng "hello world" jest w jednym interperterze perla) > > takie juz zupelnie "raw" fastcgi z perlem > > czyli skrypt perla fcgi na sockecie > > --------- > use FCGI; > > my $socket = FCGI::OpenSocket( "/tmp/perl.socket", 5 ); > my $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR, > \%ENV, $socket ); > > my $count; > while( $request->Accept() >= 0 ) { > print STDERR "request\n"; > print "Content-type: text/html\r\n\r\n"; > print "hello perlFCGI world\n"; > } > > FCGI::CloseSocket( $socket ); > ------------- > i lighttpd jako front-end (ta sama instancja co php) > daje > > ab -n 1000 http://localhost/perl/ > 0.477 ms/req (2098 req/sek) uff, czyli da sie szybciej niz php (1500 > req/sek) > > > po wylczeniu socketu sam light jest w stanie wygenerowac 4000 req/sek z > odpowiedzia 503 - Service Not Available > > > ale 2000 raw fcgi vs 750 placka > trzeba pamietac, ze rawcgi jeszcze musialby parsowac parametry > plack to pewnie robi przy tworzeniu requestu > czy php to robi przy takiej prostej stronie, nie wiem > moze dopiero przy pierwszym odwolaniu do parametrow? > > no i takie testy, to zadne testy, ot sprawdzenie jaki jest narzut > technologi/frameworku i szacowanie co sie dzieje, > co daje plack w stosunku do reszty dostepnych narzedzi > > dodanie do tego "raw" fastcgi parsowania argumentow przez CGI > ---- > use FCGI; > use CGI; > > my $socket = FCGI::OpenSocket( "/tmp/perl.socket", 5 ); > my $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR, > \%ENV, $socket ); > > my $count; > while( $request->Accept() >= 0 ) { > my $q=CGI->new; > print STDERR "request\n"; > print "Content-type: text/html\r\n\r\n"; > print "hello perlFCGI world\n ". $q->param('hello') . "\n"; > } > > FCGI::CloseSocket( $socket ); > > ---- > daje > ab -n 1000 http://localhost/perl/ > 0.750 ms/req (1332.83 req/sek) > > > CGI tyle zjada > ale nadal zjada mniej niz Plack :( > > > gdy czytalem o PSGI nie spodobal mi sie fragment, > gdzie napisali, ze decyzje odnosnie protokolu pdejmowali > tak aby bylo latwo napisac drajwer do frameworkow. > > aby latwo przejsc z CGI na PSGI, echhh > no i pisali drajwery w godzine > a potem latami tracisz polowe wydajnosci serwera > > teraz czas zobaczyc alternatywne moduly CGI > > albo znalezc/napisac cos co zamieni FCGI > na request ala plack czy apache request object, cgi object > > i wtedy jest sie w tym samym miejscu co plack, > tylko, ze z wydajnoscia x2 w stosunku do placka > > a fcgi jest uniwersalne, niezaleznie od serwera http > > > > -- > pp > _______________________________________________ > Warszawa-pm mailing list > Warszawa-pm w pm.org > http://mail.pm.org/mailman/listinfo/warszawa-pm > -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From tadzikes w gmail.com Fri May 7 10:02:48 2010 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Fri, 7 May 2010 17:02:48 +0000 Subject: [Warszawa-pm] WebNano In-Reply-To: References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> Message-ID: <20100507170248.GA1909@yavin4.wifimain.elka.pw.edu.pl> On 7-05-2010 15:57:08, Zbigniew Lukasiak wrote: > wracajac do tematu frejmworkow (moze ktos zna jakies spolszczenie?) Ramówek? Jakoś ostatnio zasłyszałem. Pozdrawiam From pp w webtel.pl Fri May 7 08:18:38 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Fri, 07 May 2010 17:18:38 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> Message-ID: <4BE42F4E.2060300@webtel.pl> -------- Original Message -------- Subject: Re: [Warszawa-pm] WebNano From: Zbigniew Lukasiak To: warszawa-pm w pm.org Date: Fri May 07 2010 16:57:08 GMT+0200 (CEST) > kodu. Dlatego mam nadzieje na rozwoj Placka ktory otwiera rozne nowe > mozliwosci. > > Z. od catalysta bardziej skomplikowane jest chyba tylko jifty ;) ale co wiecej daje ci plack w stosunku do fastcgi/cgi::simple ? Plack::Request to takie CGI::Simple, myle sie? w obu przypadkach reszte trzeba pisac samemu From zzbbyy w gmail.com Fri May 7 08:52:25 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Fri, 7 May 2010 16:52:25 +0100 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE42F4E.2060300@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> <4BE42F4E.2060300@webtel.pl> Message-ID: 2010/5/7 piotr pogorzelski : > -------- Original Message -------- > Subject: Re: [Warszawa-pm] WebNano > From: Zbigniew Lukasiak > To: warszawa-pm w pm.org > Date: Fri May 07 2010 16:57:08 GMT+0200 (CEST) > > >> kodu. Dlatego mam nadzieje na rozwoj Placka ktory otwiera rozne nowe >> mozliwosci. >> >> Z. > > od catalysta bardziej skomplikowane jest chyba tylko jifty ;) > > ale co wiecej daje ci plack w stosunku do fastcgi/cgi::simple ? > > Plack::Request to takie CGI::Simple, myle sie? > > w obu przypadkach reszte trzeba pisac samemu Chodzi raczej o to, że PSGI swietnie podzielilo kod - teraz powstają niezależnie różne fajne kawałki funkcjonalności. A sam Plack::Request to rzeczywiście nic wielkiego, ale z tego co pamiętam to miyagawa dał tam takie sprytne rozwiązanie dla parametrów które mogą mieć wiele wartości (w CGI, a także w Cataliscie to wymaga ciągłego sprawdzania), a także chyba do uploadów plików. W sumie to takie małe ułatwienia. Ale ważne jest to, że właśnie one mogą powstawać sobie niezależnie. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From pp w webtel.pl Fri May 7 10:07:15 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Fri, 07 May 2010 19:07:15 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> <4BE42F4E.2060300@webtel.pl> Message-ID: <4BE448C3.50306@webtel.pl> to tak na zakonczenie zabawy dnia dzisiejszego profiling "plackup main.psgi" coby zobaczyc nad czym on tak ciezko pracuje -- pp -------------- następna część --------- An embedded and charset-unspecified text was scrubbed... Name: dprofpp.txt URL: From tadzikes w gmail.com Sat May 8 07:26:27 2010 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Sat, 8 May 2010 14:26:27 +0000 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE448C3.50306@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> Message-ID: <20100508142627.GA22205@yavin4> On 7-05-2010 19:07:15, piotr pogorzelski wrote: > to tak na zakonczenie zabawy dnia dzisiejszego > profiling "plackup main.psgi" coby zobaczyc nad > czym on tak ciezko pracuje Zastanawiam się czy to kwestia PSGI czy Placka samego w sobie. Oto wyniki Apache Benchmark na Helloworldowej aplikacji w Dancerze [1], najpierw odpalanej przez plackup, następnie przez wbudowany webserver oparty na HTTP::Server::Simple::PSGI ## Plackup ## Time taken for tests: 11.468 seconds Requests per second: 87.20 [#/sec] (mean) Time per request: 11.468 [ms] (mean) ## HTTP::Server::Simple::PSGI ## Time taken for tests: 3.559 seconds Requests per second: 280.94 [#/sec] (mean) Time per request: 3.559 [ms] (mean) Testowane dla 1000 requestów. Pozdrawiam, Tadek [1] http://perldancer.org/ From piotr w fusik.info Sun May 9 02:50:10 2010 From: piotr w fusik.info (=?UTF-8?B?UGlvdHIgRnVzaWs=?=) Date: Sun, 09 May 2010 11:50:10 +0200 Subject: [Warszawa-pm] WebNano Message-ID: <125b581e0dc1413f896af0ec2a2b1ee3.qmail@home.pl> Dnia 2010-05-07 17:02 Tadeusz Sośnierz napisał(a): >On 7-05-2010 15:57:08, Zbigniew Lukasiak wrote: >> wracajac do tematu frejmworkow (moze ktos zna jakies spolszczenie?) > >Ramówek? Jakoś ostatnio zasłyszałem. Nie spotkałem się z żadną próbą spolszczenia ".NET Framework". Piotr From pp w webtel.pl Sun May 9 14:37:15 2010 From: pp w webtel.pl (pp) Date: Sun, 09 May 2010 23:37:15 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: <20100508142627.GA22205@yavin4> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> Message-ID: <5d64a8bae8072715b8d8049440f4c269@webtel.pl> On Sat, 8 May 2010 14:26:27 +0000, Tadeusz Sośnierz wrote: (...) > > Zastanawiam się czy to kwestia PSGI czy Placka samego w sobie. Oto (...) Skoro Dancer potrafi uzywac HTTP::Server::Simple::PSGI to znaczy, ze ma w sobie obsluge PSGI. jesli miedzy Dancera a serwer httpd wstawi sie jescze placka, to dane requestu przetwarzane sa pewnie dwa razy, najpierw przez placka, potem juz przez samego dancera. nic wiec dziwnego, ze dziala wolniej ale to gdybanie, trzeba by przejrzec kod i zobaczyc co sie dzieje w obu przypadkach co ciekawsze prosta aplikacja dancera wg manuala #cat dancer.pl #!/usr/bin/perl use Dancer; get '/hello/:name' => sub { return "Why, hello there " . params->{name}; }; dance; #perl dancer.pl #ab -n 1000 http://localhost:3000/hello/123123 daje mi ca. 700 req/sek aplikacja budowana # dancer -a d1 i pozniej dodane do d1.pm -- get '/hello/:name' => sub { return "Why, hello there " . params->{name}; }; -- #perl d1.pl #ab -n 1000 http://localhost:3000/hello/123123 daje juz ca 250 req/sek. czyli builder dancera dodaje cos. cos co robi cos czego nie wiedac, i spowalnia aplikacje ponad dwukrotnie jakis logger, framework ? obejrzalem sobie co robi plack, bazujac na tym profilingu . kwadrans grzebania w kodzie i: po drobnej przerobce przy niepotrzebnym kopiowaniu %ENV z 750 req/sek zrobilo sie 850 a po wstawieniu 'return;' zaraz na poczatku procedury 'log_line' w Plack::Middleware::AccessLog zrobilo sie 1250 req/sek (mimo ze nie bylo wlaczone logowanie, procedua byla uruchamiana, stad te 850) log_line piekny kawalek kodu, kilka procedur zdefiniowanych wewnatrz log_line, wywolywanych wewnatrz regexpa w celu zbudowania wiersza w formacie apchelog. zamiast sprintf ... jakby pozastapowac te wszystkie wewnetrzne regexpy przez substr/index itp, to moze i daloby sie na placku dociagnac do 1500 req/sek, czyli dociagnac do php. regexpy sa straaaaaasznie kosztowne nomen omen Dancer to chyba taki framework na psgi , cos a'la WebNano :) -- pp From tadzikes w gmail.com Sun May 9 16:45:51 2010 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Sun, 9 May 2010 23:45:51 +0000 Subject: [Warszawa-pm] WebNano In-Reply-To: <5d64a8bae8072715b8d8049440f4c269@webtel.pl> References: <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> Message-ID: <20100509234551.GA21512@yavin4> On 9-05-2010 23:37:15, pp wrote: > obejrzalem sobie co robi plack, bazujac na tym profilingu . > > kwadrans grzebania w kodzie i: > po drobnej przerobce przy niepotrzebnym kopiowaniu %ENV > z 750 req/sek zrobilo sie 850 > > a po wstawieniu 'return;' zaraz na poczatku > procedury 'log_line' w Plack::Middleware::AccessLog > zrobilo sie 1250 req/sek (mimo ze nie bylo > wlaczone logowanie, procedua byla uruchamiana, stad te 850) > > log_line piekny kawalek kodu, kilka procedur zdefiniowanych wewnatrz > log_line, > wywolywanych wewnatrz regexpa w celu zbudowania wiersza w formacie > apchelog. zamiast sprintf ... > > jakby pozastapowac te wszystkie wewnetrzne regexpy przez substr/index itp, > to > moze i daloby sie na placku dociagnac do 1500 req/sek, > czyli dociagnac do php. Brzmi sensownie. Dzieliłeś się tym może z Miyagawą? Planujesz? Pozdrawiam From pp w webtel.pl Mon May 10 02:31:17 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Mon, 10 May 2010 11:31:17 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: <20100509234551.GA21512@yavin4> References: <4BE40194.5010406@webtel.pl> <4BE412FE.4060303@webtel.pl> <4BE42466.6000103@webtel.pl> <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> <20100509234551.GA21512@yavin4> Message-ID: <4BE7D265.40801@webtel.pl> z tych 1250 to jakies 150+ zyskalem wylaczajac FCGI::ProcManager'a, (znaczy podajac swoj dummy module co nic nie robi) zapomnialem o tym wczesniej napisac kazdy request, to 4razy wywolanie sigaction. a kazda funkcja systemowa kosztuje ;) > > Brzmi sensownie. Dzieliłeś się tym może z Miyagawą? Planujesz? > pewnie skrobne do niego. From zzbbyy w gmail.com Mon May 10 02:33:01 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Mon, 10 May 2010 10:33:01 +0100 Subject: [Warszawa-pm] WebNano In-Reply-To: <20100509234551.GA21512@yavin4> References: <4BE40194.5010406@webtel.pl> <4BE42466.6000103@webtel.pl> <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> <20100509234551.GA21512@yavin4> Message-ID: 2010/5/10 Tadeusz Sośnierz : > On 9-05-2010 23:37:15, pp wrote: >> obejrzalem sobie co robi plack, bazujac na tym profilingu . >> >> kwadrans grzebania w kodzie i: >> po drobnej przerobce przy niepotrzebnym kopiowaniu %ENV >> z 750 req/sek zrobilo sie 850 >> >> a po wstawieniu 'return;' zaraz na poczatku >> procedury 'log_line' w Plack::Middleware::AccessLog >> zrobilo sie 1250 req/sek (mimo ze nie bylo >> wlaczone logowanie, procedua byla uruchamiana, stad te 850) >> >> log_line piekny kawalek kodu, kilka procedur zdefiniowanych wewnatrz >> log_line, >> wywolywanych wewnatrz regexpa w celu zbudowania wiersza w formacie >> apchelog. zamiast sprintf ... >> >> jakby pozastapowac te wszystkie wewnetrzne regexpy przez substr/index itp, >> to >> moze i daloby sie na placku dociagnac do 1500 req/sek, >> czyli dociagnac do php. > > Brzmi sensownie. Dzieliłeś się tym może z Miyagawą? Planujesz? Wszystko jest na githubie (http://github.com/miyagawa/Plack) - wiec nic prostszego niż sforkować projekt i wysłać pull request. Trzeba tylko pamiętać, że na różnych listach takie 'benchmarki' są traktowane jako bezsensowne, bo co znaczy to usprawnienie o 1/1000 sekundy, jeśli zapytanie w normalnych warunkach trwa i tak powiedzmy 1/10s., wtedy takie usprawnienie nic nie znaczy. I co prawda chyba każdy się zgodzi, że w pewnych przypadkach chciałoby się jednak mieć te 1000/s, ale zaczynanie dyskusji o takich benchmarkach traktowane jest trochę jak zamulanie listy. Więc trzeba delikatnie. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From pp w webtel.pl Mon May 10 02:46:21 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Mon, 10 May 2010 11:46:21 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: References: <4BE40194.5010406@webtel.pl> <4BE42466.6000103@webtel.pl> <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> <20100509234551.GA21512@yavin4> Message-ID: <4BE7D5ED.8020404@webtel.pl> > Wszystko jest na githubie (http://github.com/miyagawa/Plack) - wiec > nic prostszego niż sforkować projekt i wysłać pull request. Trzeba > tylko pamiętać, że na różnych listach takie 'benchmarki' są traktowane > jako bezsensowne, bo co znaczy to usprawnienie o 1/1000 sekundy, jeśli > zapytanie w normalnych warunkach trwa i tak powiedzmy 1/10s., wtedy > takie usprawnienie nic nie znaczy. I co prawda chyba każdy się > zgodzi, że w pewnych przypadkach chciałoby się jednak mieć te 1000/s, > ale zaczynanie dyskusji o takich benchmarkach traktowane jest trochę > jak zamulanie listy. Więc trzeba delikatnie. > wiadomo, ze trzeba porownywac porownywalne. catalysta moge porownywac z django czy inna joomla takie benchmarki mowia tylko tyle, jaki narzut daje technologia w konkretnej konfiguracji. I jesli sa znaczace roznice, wzbudzaja zdziwienie prowadzace do znjdowania 'log_line' z drugiej strony, jakby postawili mi zadanie napisania RESTa dla facebooka lub twittera to wybor technologii zaczalbym wlasnie od takich testow a, ze delikatne. coz. benchmarki oceniaja. wiec jest dyskusja czy oceniac nalezy, jakie kryteria i czy ocena jest zasluzona. ot ludzka natura :0 From zzbbyy w gmail.com Mon May 10 03:41:11 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Mon, 10 May 2010 11:41:11 +0100 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE7D5ED.8020404@webtel.pl> References: <4BE40194.5010406@webtel.pl> <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> <20100509234551.GA21512@yavin4> <4BE7D5ED.8020404@webtel.pl> Message-ID: 2010/5/10 piotr pogorzelski : > >> Wszystko jest na githubie (http://github.com/miyagawa/Plack) - wiec >> nic prostszego niż sforkować projekt i wysłać pull request. Trzeba >> tylko pamiętać, że na różnych listach takie 'benchmarki' są traktowane >> jako bezsensowne, bo co znaczy to usprawnienie o 1/1000 sekundy, jeśli >> zapytanie w normalnych warunkach trwa i tak powiedzmy 1/10s., wtedy >> takie usprawnienie nic nie znaczy. I co prawda chyba każdy się >> zgodzi, że w pewnych przypadkach chciałoby się jednak mieć te 1000/s, >> ale zaczynanie dyskusji o takich benchmarkach traktowane jest trochę >> jak zamulanie listy. Więc trzeba delikatnie. >> > > wiadomo, ze trzeba porownywac porownywalne. > catalysta moge porownywac z django czy inna joomla > > takie benchmarki mowia tylko tyle, jaki narzut daje technologia w konkretnej > konfiguracji. I jesli sa znaczace roznice, wzbudzaja > zdziwienie prowadzace do znjdowania 'log_line' > > z drugiej strony, jakby postawili mi zadanie napisania RESTa dla > facebooka lub twittera to wybor technologii zaczalbym wlasnie > od takich testow > > a, ze delikatne. coz. benchmarki oceniaja. wiec jest dyskusja > czy oceniac nalezy, jakie kryteria i czy ocena jest zasluzona. > ot ludzka natura :0 Najlepszym chyba argumentem za takimi optymalizacjami jest to, ze to poszerza zakres stosowalnosci. Co prawda dla wiekszosci zastosowan ta 1/1000 sekundy nie ma znaczenia, ale jest duza roznica miedzy czyms co sie nadaje tylko do do 'powolnych' aplikacji a czyms uniwersalnym. Z. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From pp w webtel.pl Mon May 10 04:15:50 2010 From: pp w webtel.pl (piotr pogorzelski) Date: Mon, 10 May 2010 13:15:50 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: References: <4BE40194.5010406@webtel.pl> <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> <20100509234551.GA21512@yavin4> <4BE7D5ED.8020404@webtel.pl> Message-ID: <4BE7EAE6.2090202@webtel.pl> > Najlepszym chyba argumentem za takimi optymalizacjami jest to, ze to > poszerza zakres stosowalnosci. Co prawda dla wiekszosci zastosowan ta > 1/1000 sekundy nie ma znaczenia, ale jest duza roznica miedzy czyms co > sie nadaje tylko do do 'powolnych' aplikacji a czyms uniwersalnym. > ja na to patrze _nie_ w kontekscie ile milisekund moge zaoszczedzic, tylko jak to sie prezentuje na tle konkurecji. i wazniejsze dla mnie: dlaczego jest tak, a nie inaczej. dlaczego dwa razy wolniej niz php? moze jest jakas uzasadniona przyczyna, a moze nie. to jak ze spalaniem w aucie. producent podaje swoje, rzeczywiste zalezy od wielu roznych czynnikow. ale kazdy w papiery patrzy, bo nie wazne te 0.1 litra ale wazne aby nie bylo dwa razy wiecej niz alternatywa ;) From tadzikes w gmail.com Mon May 10 08:35:53 2010 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Mon, 10 May 2010 15:35:53 +0000 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE7EAE6.2090202@webtel.pl> References: <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> <20100509234551.GA21512@yavin4> <4BE7D5ED.8020404@webtel.pl> <4BE7EAE6.2090202@webtel.pl> Message-ID: <20100510153553.GA1319@yavin4> On 10-05-2010 13:15:50, piotr pogorzelski wrote: > > >Najlepszym chyba argumentem za takimi optymalizacjami jest to, ze to > >poszerza zakres stosowalnosci. Co prawda dla wiekszosci zastosowan ta > >1/1000 sekundy nie ma znaczenia, ale jest duza roznica miedzy czyms co > >sie nadaje tylko do do 'powolnych' aplikacji a czyms uniwersalnym. > > > ja na to patrze _nie_ w kontekscie ile milisekund moge zaoszczedzic, > tylko jak to sie prezentuje na tle konkurecji. > i wazniejsze dla mnie: dlaczego jest tak, a nie inaczej. > > dlaczego dwa razy wolniej niz php? > > moze jest jakas uzasadniona przyczyna, a moze nie. > > to jak ze spalaniem w aucie. producent podaje swoje, > rzeczywiste zalezy od wielu roznych czynnikow. > > ale kazdy w papiery patrzy, bo nie wazne te 0.1 litra > ale wazne aby nie bylo dwa razy wiecej niz alternatywa ;) Nie wiem czy porównanie z czystym PHP jest bardzo sensowne, chyba bardziej na miejscu byłoby porównanie z jakimś ichniejszym frameworkiem. Pozdrawiam, Tadek From zzbbyy w gmail.com Tue May 11 13:44:43 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Tue, 11 May 2010 22:44:43 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: <20100510153553.GA1319@yavin4> References: <4BE42F4E.2060300@webtel.pl> <4BE448C3.50306@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> <20100509234551.GA21512@yavin4> <4BE7D5ED.8020404@webtel.pl> <4BE7EAE6.2090202@webtel.pl> <20100510153553.GA1319@yavin4> Message-ID: No dobra - a wracajac do WebNano. Nie jest to konkurencja dla Middleware - to jest framework do budowania aplikacji czyli tego, co pierwsze tworzy 'Response', która później może być przetwarzana przez Middleware. Trudność ze zrozumieniem Placka polega na tym, że aplikacja Plackowa to jest referencja do funkcji (subroutine). Ta funkcja jest odpalana z odpowiednimi parametrami dla każnego nowego Requestu. Tak więc, jeśli się chcemy bawić w programowanie objektowe, to ta referencja musi być domknięciem (closure) zawierającym to co dla nas jest objektem aplikacji. W WebNano (po ostatnim commicie) to wygląda tak, że get_handler tworzy objekt aplikacji (wolając $class->new()) - i zwraca referencję do domknięcia (zawierającego ten nowo utworzony objekt) która się nadaje do wywołania przez plackup. Czyli app.psgi wygląda tu tak: use MyApp; MyApp->get_handler; -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From zzbbyy w gmail.com Wed May 12 02:36:49 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Wed, 12 May 2010 10:36:49 +0100 Subject: [Warszawa-pm] =?utf-8?q?A_propos_edytor=C3=B3w_w_Perlu?= Message-ID: http://blogs.perl.org/users/lichtkind/2010/05/what-is-kephra-about.html -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From piotr.roszatycki w gmail.com Wed May 12 11:05:15 2010 From: piotr.roszatycki w gmail.com (Piotr Roszatycki) Date: Wed, 12 May 2010 20:05:15 +0200 Subject: [Warszawa-pm] =?iso-8859-1?q?A_propos_edytor=F3w_w_Perlu?= In-Reply-To: References: Message-ID: A napiszę może czego ja się spodziewam po dobrym edytorze... Chciałbym mieć drzewko klas rozwijane do metod, również takich, które są implementowane w Moose za pomocą 'around', 'before' czy 'after'. Dodatkowo w drzewku atrybuty klas, czyli to co w Moose jest po słowie kluczowym 'has'. Dla wsparcia Pythona czy PHP w np. Eclipse takie ficzery to standard. W dniu 12 maja 2010 11:36 użytkownik Zbigniew Lukasiak napisał: > http://blogs.perl.org/users/lichtkind/2010/05/what-is-kephra-about.html > > -- > Zbigniew Lukasiak > http://brudnopis.blogspot.com/ > http://perlalchemy.blogspot.com/ > _______________________________________________ > Warszawa-pm mailing list > Warszawa-pm w pm.org > http://mail.pm.org/mailman/listinfo/warszawa-pm > -------------- następna część --------- Załącznik HTML został usunięty... URL: From zzbbyy w gmail.com Sun May 16 04:43:31 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Sun, 16 May 2010 13:43:31 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: References: <4BE42F4E.2060300@webtel.pl> <20100508142627.GA22205@yavin4> <5d64a8bae8072715b8d8049440f4c269@webtel.pl> <20100509234551.GA21512@yavin4> <4BE7D5ED.8020404@webtel.pl> <4BE7EAE6.2090202@webtel.pl> <20100510153553.GA1319@yavin4> Message-ID: W ten weekend 'zdemoosyfikowalem' WebNano. Teraz zarówno jego własny kod jak i zależności są naprawdę leciutkie. Na razie zostawiam 'Moose' jako 'build_requires' bo uzywam tego w testach i w przykładach. Zerknijcie na nowe README: http://github.com/zby/WebNano Czekam na komentarze. Zastanawiam się teraz nad dodaniem jakiejś obsługi szablonów. Co jeszcze Waszym zdaniem powinno się znaleźć w 'web framework'? Z. 2010/5/11 Zbigniew Lukasiak : > No dobra - a wracajac do WebNano. Nie jest to konkurencja dla > Middleware - to jest framework do budowania aplikacji czyli tego, co > pierwsze tworzy 'Response', która później może być przetwarzana przez > Middleware. Trudność ze zrozumieniem Placka polega na tym, że > aplikacja Plackowa to jest referencja do funkcji (subroutine). Ta > funkcja jest odpalana z odpowiednimi parametrami dla każnego nowego > Requestu. Tak więc, jeśli się chcemy bawić w programowanie objektowe, > to ta referencja musi być domknięciem (closure) zawierającym to co dla > nas jest objektem aplikacji. > > W WebNano (po ostatnim commicie) to wygląda tak, że get_handler tworzy > objekt aplikacji (wolając $class->new()) - i zwraca referencję do > domknięcia (zawierającego ten nowo utworzony objekt) która się nadaje > do wywołania przez plackup. > > Czyli app.psgi wygląda tu tak: > > use MyApp; > MyApp->get_handler; > > > -- > Zbigniew Lukasiak > http://brudnopis.blogspot.com/ > http://perlalchemy.blogspot.com/ > -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From piotr.roszatycki w gmail.com Wed May 19 07:48:13 2010 From: piotr.roszatycki w gmail.com (Piotr Roszatycki) Date: Wed, 19 May 2010 16:48:13 +0200 Subject: [Warszawa-pm] Module::Skeleton Message-ID: Ponieważ Piotr chce wrzucić nowy moduł do CPAN-a, pozwoliłem sobie zrobić taki szablon, który ułatwi przygotowanie modułów: http://github.com/dex4er/Module-Skeleton W "master" są pliki wersjonowane, a to co się samo generuje i następnie wrzuca później do CPAN można podejrzeć w branchu "cpan". Wiem, że Zbyszek korzysta z Module::Install, ale ja preferuję Module::Build, jako że nie wymagane jest wtedy instalowanie make, a do przygotowania dystrybucyjnej paczki właściwie potrzebny jest sam Perl. -- .''`. Piotr Roszatycki : :' : mailto:Piotr.Roszatycki w gmail.com `. `' mailto:dexter w debian.org `- -------------- następna część --------- Załącznik HTML został usunięty... URL: From zzbbyy w gmail.com Wed May 19 07:54:27 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Wed, 19 May 2010 15:54:27 +0100 Subject: [Warszawa-pm] Module::Skeleton In-Reply-To: References: Message-ID: 2010/5/19 Piotr Roszatycki : > Ponieważ Piotr chce wrzucić nowy moduł do CPAN-a, pozwoliłem sobie zrobić > taki szablon, który ułatwi przygotowanie modułów: > http://github.com/dex4er/Module-Skeleton > W "master" są pliki wersjonowane, a to co się samo generuje i następnie > wrzuca później do CPAN można podejrzeć w branchu "cpan". > Wiem, że Zbyszek korzysta z Module::Install, ale ja preferuję Module::Build, > jako że nie wymagane jest wtedy instalowanie make, a do przygotowania > dystrybucyjnej paczki właściwie potrzebny jest sam Perl. Ostatnio się przymierzam do Dzilla (http://search.cpan.org/~rjbs/Dist-Zilla-2.101310/lib/Dist/Zilla/Tutorial.pm) - o ile wiem to on działa zarówno z Module::Install jak i Module::Build. Ale do tej pory do generowania szkieletu to używałem Module::Starter (też może generować zarówno M::I jak i M::B). Z. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From piotr.roszatycki w gmail.com Wed May 19 08:20:18 2010 From: piotr.roszatycki w gmail.com (Piotr Roszatycki) Date: Wed, 19 May 2010 17:20:18 +0200 Subject: [Warszawa-pm] Module::Skeleton In-Reply-To: References: Message-ID: W dniu 19 maja 2010 16:54 użytkownik Zbigniew Lukasiak napisał: > Ostatnio się przymierzam do Dzilla > ( > http://search.cpan.org/~rjbs/Dist-Zilla-2.101310/lib/Dist/Zilla/Tutorial.pm > ) > - o ile wiem to on działa zarówno z Module::Install jak i > Module::Build. Ale do tej pory do generowania szkieletu to używałem > Module::Starter (też może generować zarówno M::I jak i M::B). > DistZilla może być niezłą alternatywą dla Windziarzy, który cierpią na brak dobrego shella ;) U mnie w szkielecie dodatkowo jest to co zawsze i tak wrzucam do modułów, tzn. extra testy w katalogu xt, generowanie README, LICENSE i SIGNATURE oraz doklejanie paru adresów do META.yml. -- .''`. Piotr Roszatycki : :' : mailto:Piotr.Roszatycki w gmail.com `. `' mailto:dexter w debian.org `- -------------- następna część --------- Załącznik HTML został usunięty... URL: From radek w pld-linux.org Wed May 19 08:37:07 2010 From: radek w pld-linux.org (=?UTF-8?B?UmFkb3PFgmF3IFppZWxpxYRza2k=?=) Date: Wed, 19 May 2010 10:37:07 -0500 Subject: [Warszawa-pm] Module::Skeleton In-Reply-To: References: Message-ID: 2010/5/19 Piotr Roszatycki : > Ponieważ Piotr chce wrzucić nowy moduł do CPAN-a, pozwoliłem sobie zrobić > taki szablon, który ułatwi przygotowanie modułów: > http://github.com/dex4er/Module-Skeleton W czym to jest lepsze od h2xs? From piotr.roszatycki w gmail.com Wed May 19 13:12:22 2010 From: piotr.roszatycki w gmail.com (Piotr Roszatycki) Date: Wed, 19 May 2010 22:12:22 +0200 Subject: [Warszawa-pm] Module::Skeleton In-Reply-To: References:

Message-ID: W dniu 19 maja 2010 17:37 użytkownik Radosław Zieliński napisał: > 2010/5/19 Piotr Roszatycki : > > Ponieważ Piotr chce wrzucić nowy moduł do CPAN-a, pozwoliłem sobie zrobić > > taki szablon, który ułatwi przygotowanie modułów: > > http://github.com/dex4er/Module-Skeleton > > W czym to jest lepsze od h2xs? Nooo h2xs to niezły oldskool jest :) Ten Module-Skeleton to nie jest moduł, który coś generuje, tylko póki co szablon, który wykorzystuję jako bazę dla nowych modułów. Różnice: Module::Build zamiast MakeMaker, extra testy wręcz niezbędne przed wrzucaniem na serwery CPAN-a, inny układ pliku .pm, dodatkowy skrypt który generuje brakujące pliki na podstawie tych z repozytorium gita. Ja wręcz zachęcam Piotra, aby poprawił sobie ten szablon tak, aby pasował do jego stylu kodowania. Nie mam patentu na jedyny właściwy. -- .''`. Piotr Roszatycki : :' : mailto:Piotr.Roszatycki w gmail.com `. `' mailto:dexter w debian.org `- -------------- następna część --------- Załącznik HTML został usunięty... URL: From radek w pld-linux.org Thu May 20 03:10:46 2010 From: radek w pld-linux.org (=?UTF-8?B?UmFkb3PFgmF3IFppZWxpxYRza2k=?=) Date: Thu, 20 May 2010 05:10:46 -0500 Subject: [Warszawa-pm] Module::Skeleton In-Reply-To: References:

Message-ID: 2010/5/19 Piotr Roszatycki : > W dniu 19 maja 2010 17:37 użytkownik Radosław Zieliński > napisał: >> 2010/5/19 Piotr Roszatycki : >> > Ponieważ Piotr chce wrzucić nowy moduł do CPAN-a, pozwoliłem sobie >> > zrobić >> > taki szablon, który ułatwi przygotowanie modułów: >> > http://github.com/dex4er/Module-Skeleton >> W czym to jest lepsze od h2xs? > Nooo h2xs to niezły oldskool jest :) [...] Erhm... Co to wlasciwie znaczy? Nie dziala? Zle dziala? From piotr.roszatycki w gmail.com Fri May 21 02:13:18 2010 From: piotr.roszatycki w gmail.com (Piotr Roszatycki) Date: Fri, 21 May 2010 11:13:18 +0200 Subject: [Warszawa-pm] Module::Skeleton In-Reply-To: References:

Message-ID: > > >> W czym to jest lepsze od h2xs? > > Nooo h2xs to niezły oldskool jest :) > [...] > W czym Module::Builder jest lepszy od ExtUtils::MakeMaker? No cóż, spróbuj zrobić "make dist" pod Windows bez make, tar i gzip :) -- .''`. Piotr Roszatycki : :' : mailto:Piotr.Roszatycki w gmail.com `. `' mailto:dexter w debian.org `- -------------- następna część --------- Załącznik HTML został usunięty... URL: From radek w pld-linux.org Fri May 21 10:28:09 2010 From: radek w pld-linux.org (=?UTF-8?B?UmFkb3PFgmF3IFppZWxpxYRza2k=?=) Date: Fri, 21 May 2010 12:28:09 -0500 Subject: [Warszawa-pm] Module::Skeleton In-Reply-To: References:

Message-ID: 2010/5/21 Piotr Roszatycki : >> >> W czym to jest lepsze od h2xs? >> > Nooo h2xs to niezły oldskool jest :) >> [...] > W czym Module::Builder jest lepszy od ExtUtils::MakeMaker? Nie. From zzbbyy w gmail.com Sun May 23 14:01:21 2010 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Sun, 23 May 2010 23:01:21 +0200 Subject: [Warszawa-pm] WebNano In-Reply-To: <4BE40194.5010406@webtel.pl> References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> Message-ID: No to ja wyprobowalem WebNano z Template::Tiny i wyszlo mi mniej wiecej tak: Dla Catalysta z TT - 70/s (he he - stary komputer) PSGI z TT - 120/s WebNano z TTT - 210/s PSGI bez TT - 320/s Na razie mam rozgrzebany kod templejtowania (mozecie sobie poczytac co sobie wymyslilem: http://perlalchemy.blogspot.com/2010/05/templates-and-inheritance.html) i nie mam jeszcze TT dla WebNano. A jak tam prace nad przyśpieszeniem samego PSGI? Kod dla WebNano: app.psgi: use MyApp; use WebNano::TTTRenderer; my $app = MyApp->new( renderer => WebNano::TTTRenderer->new( root => 'bench/templates' ) ); $app->psgi_callback; MyApp.pm: package MyApp; use base 'WebNano'; 1; MyApp/Controller.pm: package MyApp::Controller; use Moose; use MooseX::NonMoose; extends 'WebNano::Controller'; use AnyEvent; sub index_action { my $self = shift; return $self->render( 'index.tt' ); } #sub hello_action { 'Hello World' } sub hello_action { shift->render( 'hello.tt' ) } 1; Co ciekawe jak zapakowalem wszystko do app.psgi to bylo tylko 120/s - pewnie require w tym wypadku nie mial cache. Z. From uksza w uksza.net Mon May 24 00:27:05 2010 From: uksza w uksza.net (=?UTF-8?B?xYF1a2FzeiBNxIVkcnp5Y2tp?=) Date: Mon, 24 May 2010 09:27:05 +0200 Subject: [Warszawa-pm] Fwd: [pm_groups] The Perl Survey 2010 is now live In-Reply-To: References: Message-ID: ------ From: Kieren Diment The Perl Survey 2010 is now live. Its purpose is to better understand the demographics and opinions of the Perl community. You can complete the survey at http://survey.perlfoundation.org - it should take about 10 to 15 minutes. Once you've done that, please let your relevant friends and colleagues know about the survey so they can coplete it as well. My aim is to get a response of over 1000 individuals, and to run the survey (lightly adapted) every two or three years so we can see how the community changes over time. The official announcement of the survey is here: http://news.perlfoundation.org/2010/05/grant-update-the-perl-survey-1.html From tadzikes w gmail.com Mon May 24 08:54:34 2010 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Mon, 24 May 2010 15:54:34 +0000 Subject: [Warszawa-pm] =?utf-8?q?A_propos_edytor=C3=B3w_w_Perlu?= In-Reply-To: References:

Message-ID: <20100524155434.GA5706@yavin4> On 12-05-2010 20:05:15, Piotr Roszatycki wrote: > A napiszę może czego ja się spodziewam po dobrym edytorze... > > Chciałbym mieć drzewko klas rozwijane do metod, również takich, które są > implementowane w Moose za pomocą 'around', 'before' czy 'after'. Dodatkowo w > drzewku atrybuty klas, czyli to co w Moose jest po słowie kluczowym 'has'. Dla > wsparcia Pythona czy PHP w np. Eclipse takie ficzery to standard. Obawiam się że przyjdzie Ci poczekać do Perla 6, i wsparcia dla tegoż :) Pozdrawiam, Tadek From stas w datos.pl Mon May 31 12:44:10 2010 From: stas w datos.pl (Stanislaw Romanski) Date: Mon, 31 May 2010 21:44:10 +0200 Subject: [Warszawa-pm] Zanieczyszczenie przestrzeni nazw References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl><4BE40194.5010406@webtel.pl> Message-ID: Cześć, Pomóżcie, bo nie potrafię zrobić a pilnie potrzebuję. S. ========================================================================== Pytanie (sformułowanie krótkie): Jak można zanieczyścić pakiet nazwami z innego pakietu, który jest zdefiniowany w TYM SAMYM pliku ? ================ Pytanie (TO SAMO, forma rozwinięta) Jeśli są 2 pliki: w jednym zdefiniowany pakiet a w drugim jego użycie, to wszystko dziala doskonale. # Plik package test229osobno.pm; package test229osobno; use strict; use Exporter; our @ISA = qw(Exporter); our @EXPORT = qw( funa ); sub funa { print "in funa\n"; } 1; # plik test229.pl package main; use strict; use test229osobno; funa(); # ok bez pisania pelnej kwalifikacji test229osobno::funa() Mozna uuruchomic perl test229.pl i dziala cudnie. ================ Jesli połączymy te pliki w jeden, w ktorym na poczatku jest pakiet a potem 'main' ktory wywoluje funkcję, to jak zrobić, by nie trzyba było pisać pełnej kwalifikacji, z nazwą pakietu ?. # Plik package test230.pl package test230; use strict; use Exporter; our @ISA = qw(Exporter); our @EXPORT = qw( funa ); sub funa { print "in funa\n"; } package main; use strict; # use test230; # cos w tym rodzaju ?? test230::funa(); # ok funa(); # komunikat: nieznana funkcja pakietu 'main' # NIE WIEM CO ZROBIC BY TO DZIALALO ???? From tadzikes w gmail.com Mon May 31 14:56:45 2010 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Mon, 31 May 2010 21:56:45 +0000 Subject: [Warszawa-pm] warszawa.pm.org Message-ID: <20100531215645.GA7775@yavin4> > Coming soon. --jhannah 2010-10-25 Powoli zaczyna być ?od kiedy pamiętam?. Może by warto zamieścić jednak krótką notkę, taką jak Zbyszek jakiś czas temu wygrzebał, dorzucić do tego info o liście? Roboty jest chwila, ale żeby jakaś informacja jednak była. Pozdrawiam, Tadek From uksza w uksza.net Mon May 31 13:41:05 2010 From: uksza w uksza.net (=?UTF-8?B?xYF1a2FzeiBNxIVkcnp5Y2tp?=) Date: Mon, 31 May 2010 22:41:05 +0200 Subject: [Warszawa-pm] Zanieczyszczenie przestrzeni nazw In-Reply-To: References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl> <4BE40194.5010406@webtel.pl> Message-ID: Hej, > Jesli połączymy te pliki w jeden, w ktorym na poczatku jest pakiet a potem > 'main' ktory wywoluje funkcję, > to jak zrobić, by nie trzyba było pisać pełnej kwalifikacji, z nazwą pakietu [...] > # use test230; # cos w tym rodzaju ?? bardzo blisko :) import test230; pzdr, Ł From stas w datos.pl Mon May 31 14:12:06 2010 From: stas w datos.pl (Stanislaw Romanski) Date: Mon, 31 May 2010 23:12:06 +0200 Subject: [Warszawa-pm] Zanieczyszczenie przestrzeni nazw References: <4BE18F6D.6080901@webtel.pl> <4BE3ECA2.8090507@webtel.pl><4BE40194.5010406@webtel.pl> Message-ID: <94C1B2C878574819B56A53BCBB4F3CE5@datos57604fe5b> Ok, Dzięki. Działa i bucy ;-) Pzdr, S.R. ----- Original Message ----- From: "Łukasz Mądrzycki" To: Sent: Monday, May 31, 2010 10:41 PM Subject: Re: [Warszawa-pm] Zanieczyszczenie przestrzeni nazw Hej, > Jesli połączymy te pliki w jeden, w ktorym na poczatku jest pakiet a potem > 'main' ktory wywoluje funkcję, > to jak zrobić, by nie trzyba było pisać pełnej kwalifikacji, z nazwą > pakietu [...] > # use test230; # cos w tym rodzaju ?? bardzo blisko :) import test230; pzdr, Ł _______________________________________________ Warszawa-pm mailing list Warszawa-pm w pm.org http://mail.pm.org/mailman/listinfo/warszawa-pm From uksza w wp.pl Mon May 31 15:55:57 2010 From: uksza w wp.pl (=?UTF-8?B?xYF1a2FzeiBNxIVkcnp5Y2tp?=) Date: Tue, 1 Jun 2010 00:55:57 +0200 Subject: [Warszawa-pm] warszawa.pm.org In-Reply-To: <20100531215645.GA7775@yavin4> References: <20100531215645.GA7775@yavin4> Message-ID: W dniu 31 maja 2010 23:56 użytkownik Tadeusz Sośnierz napisał: >> Coming soon. --jhannah 2010-10-25 > > Powoli zaczyna być ?od kiedy pamiętam?. Może by warto zamieścić jednak > krótką notkę dzięki za zmotywowanie :) Ł