Gruby perl

Nie, 28 Lip 2002, 13:55:16 CEST

On Sun, 28 Jul 2002, Radoslaw Zielinski wrote:

> [[ Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> ]]:
> > On Sat, 27 Jul 2002, Radoslaw Zielinski wrote:
> >> Nie mógłby, bo perldoc -f i -q przestanie działać.
> > Może by zxrobić tu jakeigoś małego wrappera o takeij samej nazwie który 
> > uzywałby mana ? :)
> 
> Nie wyobrażam sobie tego.  Poza tym:
> 1. Nowy progam, nowe błędy.  A obecne rozwiązanie się sprawdza.
> 2. Po co kombinować?  Cały perlowy świat używa oryginalnego perldoc,
> dlaczego w PLD ma być inaczej?
> 
> Ale kwestia jest do rozważenia, jak już ktoś ten programik napisze.
> 
> Przypominam, że musi on umożliwiać także czytanie normalnych PODów: do
> modułów, których nie ma w pakietach i własnych.  Czyli nie będzie taki
> mały.  No i formaty nroff i POD należą zdaje mi się do zupełnie innych
> klas: pierwszy przechowuje informacje o wyglądzie, drugi o strukturze.
> Może być problem... :->

Robić takie rzeczy watrto po to żeby nie powielać pewnych zasobów. 
Wszystkie te kłopoty znikną kiedyś o ile zacniemy używać manów czy ogólnie 
dokumentacji instalowanych w systemie w xml.
Zapewne taka pzreglądarka do man dobzre żeby miała wtedy pewne funkcje 
perldoca :)

> >>> Tak wogóle to ktoś wie może jak prosto wycinać z plików z modułami
> >>> dokumentację (która jest jzu w manach) ?
> >>> Coś takiego możnaby robić w %__install_post.
> >> Tego nie wolno robić!  Trochę zabrakło mi słów, jak to zobaczyłem, ale
> [...]
> > No dobra .. ale dlaczego tego nie wolno robić ?
> 
> Bo zepsujesz. :-p
> 
> Kolejny powód (oprócz tych, które podaję poniżej i podałem w poprzednim
> mailu): to zmniejszy prawdopodobieństwo, że dany user będzie w modułach
> grzebał.  Że zagryzie do śniadanka AutoLoaderem, poprawi CGI.pm, do
> obiadku porównanie Mail::{Mailer,Sender}, na deser Symbol.pm, a po
> kolacji jakaś kobyła typu Mason.  Nie chciałbyś być współodpowiedzialny
> za spadek poziomu edukacji społeczności OSS, nieprawdaż? :-P [1]

Wybacz lale tu nie ma związku miedzy tymi zreczami wprost. Istnieje o tyle 
ze są pewne zwyczaje i o ile sie zmieną i np. dokumentacja bedzie 
separowana od źródeł modułu juz w źródłach to zapewne sporej ilści ludzi 
na pewien okres to zamiesza. Niemniej jeszcze raz: postać źódłowa nie musi 
i nie powinna mieć większego związku z pstacia instalowaną w tym i to że w 
postaci źródłowej dokumentacja i źródła sa w jednym pliku nie powinno w 
żaden sposób wpływać na to jak to bedzie wyglądać w postaci zainstalowanej 
w systemie .. poprostu.

> > [..]
> >> Dobrze osadzone POD-y zastępują komentarze.  Bez nich, mam przechlapane;
> >> nawet nie chcę sobie wyobrażać, ile dłużej zajmowałoby znalezienie
> >> odpowiedniego kawałka kodu.
> > Gdyby kod modułu był spleciony z podem w jakis sposób to bym zrozumiał .. 
> > ale to jest poprostu jedno z dugim sklejona :)
> 
> Czy uważasz, że w takim LWP::UserAgent jest to sklejone?

Może być i splecione .. to nie powinno mieć wpływu na to jak to jest 
instalowane. Jeżeli występuje gzieś błąd to zwykle ściaga się postać 
źródłową i na tejże poprawia sie co trzeba. Pzrez takie powiazanai 
powstają włąsnie takei róne nieelastycznosci jak niemożność potraktowanai 
dokumentacji globalnie niezaleznie od tego czy to jest dokumentacj do 
perla czy czegokolwiek innego. Wiem z czego to sie nierze niemniej twórcy 
zasobów perlowych także IMHo powinni patrzeć dalej niż na dystans własnego 
czubka nosa dostosowując (tylko nieco) własne metody pracy do pewnych 
ogólnych schematów które na granicy większych klas zasobów ciągnę sie 
docieraja i ujednolicaja niż atomizują.

> >> Druga sprawa: zdarza mi się podsyłać autorom patche, a do tego
> >> potrzebuję oryginalnych wersji modułów.
> > I tu posługujesz się na wypadek takeij operacji źródłowym pakietem :)
> 
> Tomku, grzebiesz w modułach Perla na codzień?

Wcale.

> Nie ma takiej możliwości, żebym wiedział, jak wygląda taki LWP::UserAgent
> od środka, gdybym musiał do tego ściągać libwww z CPANu.

"Obecnie" dodaj do powyższego a sie zgodże z Tobą :)

> Po prostu jeśli widzę coś spapranego, albo dokumentacja jest
> niewystarczająca, albo chcę lepiej rozumieć, co się dzieje czy
> wyprofilować swój śmietnik przy pomocy Devel::DProf (czy zobaczyć, jak
> efektywne jest to, co poeta miał na myśli i czy wogóle była tam jakaś
> myśl), zaglądam do modułu.

Załóżmy że prerl dla przyśpieszenie operacji zacznie dawać możliwść 
generowanai bajtkodu i tenże będzie się instalowało i używałao. Nadal
będziesz chciał używać w postaci źródłowej z połączona dokumentacja czy
będzieśz już raczje operował własnie na źródłach generując 
bajtkod i dokumentację w manach w np. xml ?

Zauważ że od stanu obecnego do tego co nakreśliłem jest ciut, ciut i że
nawet gdyby tego bajtkodu w tym przykłązie nie uwzględniać to ow schemat
pracy z zasobami perlowymi i tak wymaga relatywnie kosmetycznych raczje
zmian niż rewolucyjnych .. i to tylko dlatego że konkretne ttechnologie w
tym i konwersja poda do xml juz istnieją, i nic tylko zacząć myśleć o tym
jak tu to wszyetko spadowywac zeby nie zastanawiać się nad tym jak się
sięga po dokumentacje do perla :)
Widzisz to ?
Jeszcze raz: zmiana podejścia nie jest do wdrożenia momentalnie. Wymaga
pewneg pzrygotowania, a zapewne pewne częci tych zmian mozna wykonywać 
etapami. Możemy sie zastanawiać co i jak dobzre byłoby zrobić dowolnei 
długo :)

> Chcę widzieć wersję niezmodyfikowaną: żeby móc szybko się w tym połapać,
> połatać _bez potrzeby posiadania połączenia z siecią_, żeby na innej
> maszynie nie mieć zonka w stylu ,,szlag, ostatnio to inaczej wyglądało''
> (to przykłady, znalazłyby się też inne powody, których sobie po prostu
> w tej chwili nie uświadamiam).  Ba, chcę, żeby inni też taką widzieli.
> Bo wtedy jest większa szansa, że 1) znajdą błąd, i 2) poprawią go, a na
> tym ja -- razem z resztą użytkowników danego softu -- skorzystam.

Na wschodzi maja takie ładnie przysłowie (w transkrypcji polskiej) 
"prywyćka wtarojom naturom cieławieka" .. mniaje juz osób zna dobzre język 
Puszkina więc pzretłumaczę: "Przyzwyczajenie drugą naturą człowieka".
To co pzreskadza Ci tutaj w spojzreniu na to nieco inaczej to tak 
faktycznie jakbyś się uderzył w klatę to .. tylko przyzwyczajenie :)

> > To tak jakbyś chciał poprawiać bład w programie dostarczając wynik cmp z 
> > konkretnej binarki :)
> 
> Nie, bo moduły Perla to nie binarki (poza XS).

Co nie znaczy że wprowadznie takiej jasnej separacji de facto .. wiele ytu 
zmienia :)

[..]
> A co przekonało Cię do uznania tego za sensowne?  Jakie są zyski?

O zysku już wspomniałem. 
Pzrez dażenie do ujednolicania zasobów dokumenytacji masz wiele zysków:
- nie musisz zastanawiać się czym nalezy siegać po dokuemnacje do czegoś 
  tam,
- możesz łatwo uzyskiwać dowolna inna postać dokumentacji (roff output, 
  ps, pdf, txt .. cokolwiek); wszystko to jednym zestawm narzędzi, a nie 
  narzędziami które daja te same wyjścia ale pzrystosowanymi do 
  poszczególnych kawąłków zasobów (jakby nie patrzeć to możliwości 
  wygenerowania tego co wymieniałem z poda są ale są one sdosć ściśle 
  zwiazane z perlem jako takim)

.. i wiele innych które bendą mutacjami czy też konsekwencjami powyższego.

[..]
> Tak wogóle, to nudzi Wam się?  Tyle jest pożytecznych rzeczy do
> zrobienia...

Gdyby było inaczje to zapewne wogóle byśmy i to obydwoje nie dyskutowali
teraz :)
Tak nudzi nam się i dlatego przecież robimy dystrybucję :)

> Na przykład, brakuje jeszcze speców do wielu modułów.

O tym wiedzą Ci co tego potzrebuja używać .. ja przykłdowo nic o tym nie 
wiem .. więcej za bardzo wiedzieć nawet nie chcę, a i nawet nie muszę :)

> SpamAssassina przydałoby się gruntownie przeczyścić; dziś np.
> stwierdziłem, że nie da się zdefiniować własnej ścieżki do regułek --
> tylko jedna z predefiniowanych...

Z buildloga o tegoż:

U spamassassin.spec
U Mail-SpamAssassin-2.31.tar.gz
cvs server: nothing known about findbin.patch
Error: some source, patch or icon files not stored in CVS repo. (findbin.patch)

:)

[..]
> Nad Masonem możnaby posiedzieć (od przekonania autorów do normalnego
> wersjonowania, po zagadnienie portowalności CGIHandler <-> mod_perl)...

z ftp://ftp.pld.org.pl/.stat/*chk:

error: perl-HTML-Mason-1.12-1: req perl(Exception::Class) not found
error: perl-HTML-Mason-1.12-1: req perl-Exception-Class >= 1.01 not found

:)

Co do błedów na tym poziomie to sa jeszcz trzy inne:

error: perl-Astro-FITS-Header-CFITSIO-2.2-1: req 
error: perl-Astro-FITS-Header-NDF-2.2-1: req perl(NDF) not found
error: perl-Tie-Cache-bench-0.17-3: req perl(Tie::Cache::LRU) not found

[..]
> Co, zbyt drobna dłubanina?

Na poziomie perla jest tego multum jak sam nadmieniasz .. niemniej mnie 
interesuje nieco barziej nie tylko tylko dłubanie w perlach co poziom 
wyżej na poziomie całej dystrybucji i to o czym mówie/pisze wynika wprost 
z postzreganai pewnych niejednolitości na tym poziomie. Tym nie musisz być 
zainteresowany wprost niemeniej taka kwestia jak mozliwie jedeno podejście 
do dokumentacji gdziekolwiek istnieje nawet jeżlei nbedziesz się 
zasłaniała tradycyjnym podejściem do zasad pracy z zasobami perlowymi. O 
ile uznasz że ta kwestia jest do pewnego stopnai drażliwa/warta 
przemyślenai o niewątpliwie pomożesz mi podpowiadajac jak taką operacje 
pzreprowadzić możliwie małym nakładem zmian które dla typowego "perlojada" 
bendą do pzrełknięcia :)

.. i o ten mniejwiecej rodzaj myślenia i współpracy apelowałbym w tym co
próbujemy robić wspólnie :)

Nie koniecznie wszystko musi wygladać dokąłdnie jak próbuje opisuywać bo 
opisuję konkretne sirodki techniczne .. niemniej jeżeli zdasz sobei sprawę 
z tego że owe sirodki dla mnie na przykąłd nie sa aż tak ważne wobec 
pewnychc wyżej położonych celół to o ile jesteś w stanie myśleć także
przedewszytkim o celu to być może zaoferujesz inny sidek tecchniczny, 
który o ile będzie lepiej spełniał pewne warunki musi być zaakceptowany 
także i przezemnie :)

Tak czy inaczej: spokój i rozwaga to dobrzy doradcy. Tam gdzie w rozmowe 
zaczynają sie wkradac emocje o dobre rozwiązanie jest już conajmniej 
trudniej :)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*