jozef's Journal http://use.perl.org/~jozef/journal/ jozef's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T01:54:55+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 jozef's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~jozef/journal/ Bundles Packages Builds Releases Tests http://use.perl.org/~jozef/journal/40504?from=rss <p>When I showed Benjamin (a college of mine) my <a href="http://news.perlfoundation.org/2010/08/2010q3-grant-proposal-cpan-to.html">TPF 2010Q3 grant proposal</a>, we slipped to a discussion about deploying Perl software. Nice (and recent) list of different approaches can be found <a href="http://www.modernperlbooks.com/mt/2010/08/on-deployment.html">@modernperlbooks.com</a>. To sum it up =&gt; TIMTOWTDI. Which is good, but none of those is perfect. The Perl+CPAN world is way too complex.</p><p>During out discussion with Benjamin I proposed an idea of shipping the application altogether with the OS. Insane? The base Debian system is ~190MB, all the rest is needed for the application. Then deployment will be a matter of running this system on a virtual machine, somewhere in the cloud or in a simple chroot. (btw any Linux distribution can have any other Linux distribution working in a chroot) The files will never clash, all the "machines" would be dedicated. No fear of putting files <a href="http://jozef.kutej.net/2010/06/where-to-put-files.html">where they belong to</a>.</p><p> <small>(<a href="http://jozef.kutej.net/2010/08/bundles-packages-builds-releases-tests.html">crossposted</a>)</small> </p> jozef 2010-08-19T15:09:12+00:00 journal XML + XPath + GUI = Xacobeo http://use.perl.org/~jozef/journal/40476?from=rss <p> <a href="http://search.cpan.org/perldoc?Xacobeo">Xacobeo</a> a Perl GUI to visualize XML and perform XPath queries just entered Debian unstable - <a href="http://packages.debian.org/sid/xacobeo">http://packages.debian.org/sid/xacobeo</a>.</p> jozef 2010-08-02T14:07:42+00:00 journal You just upload your application, ... http://use.perl.org/~jozef/journal/40465?from=rss <p>It is amazing what happened to the Python thanks to just one company. The killer feature of that company is that they can handle and manage millions of servers and even give them for a public usage =&gt; "..., there are no servers to maintain: You just upload your application, and it's ready to serve your users.". I would like this to be true one day for Perl too!</p><p>I really do. In coming months (years?) I'll try to plug together &#171; MiniCPANInject + SmokeTesting + ContinuousIntegration + Virtualization + Debian + Monitoring &#187; to create an architecture for Debian-Perl hosting. Actually who cares about OS used, when the uploaded code just works, right?... A hosting that is aware that one server is not enough for everyone and will offer an architecture for development, user-acceptance, staging and production environments to start with a project from $day == 1.</p><p> <small>(<a href="http://jozef.kutej.net/2010/07/you-just-upload-your-application.html">crossposted</a>)</small> </p> jozef 2010-07-28T17:00:46+00:00 journal sub r {return if !$_[0]; r($_[0]-1); } leaktrace{ r(1);}; http://use.perl.org/~jozef/journal/40411?from=rss <p>Today @$work we discovered that even dummy recursive calling of a function is leaking memory. Here is the one-liner 10000x calling it self and returning:</p><p> <code>perl -MEnglish -MGTop -le 'my $g=GTop-&gt;new();$m=$g-&gt;proc_mem($PID);print $m-&gt;size; sub r { return if not $_[0]; r($_[0]-1); } r(100000); $m=$g-&gt;proc_mem($PID); print $m-&gt;size;' </code> </p><p>The output is:</p><p> <code> 7122944<br> 34729984 </code> </p><p>Before the recursion 7MB allocated. After the recursion (that finished) 34MB...</p><p>Here is what <a href="http://search.cpan.org/perldoc?Test::LeakTrace">Test::LeakTrace</a> say about it:</p><p> <code> $ perl -MTest::LeakTrace -le 'sub r { return if not $_[0]; r($_[0]-1); } leaktrace{ r(1); };'<br> leaked ARRAY(0x9b7e8e8) from -e line 1.<br> leaked SCALAR(0x9b98cb8) from -e line 1.<br> leaked ARRAY(0x9c311f8) from -e line 1.<br> leaked SCALAR(0x9c311e8) from -e line 1. </code> </p><p>Are we doing anything wrong? Is it ok? How to release the memory?</p> jozef 2010-06-22T17:22:15+00:00 journal UNIX / in Strawberry %INC http://use.perl.org/~jozef/journal/40406?from=rss <p>That was a surprise for me to see / in MSWin32 paths. Dump of %INC:</p><p> <code> $VAR1 = {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;bytes.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/bytes.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;XSLoader.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/XSLoader.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;Carp.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/Carp.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;warnings/register.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/warnings/register.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;File/Spec/Unix.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/File/Spec/Unix.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;Exporter.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/Exporter.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;vars.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/vars.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;strict.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/strict.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;warnings.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/warnings.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;File/Spec.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/File/Spec.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;overload.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/overload.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;base.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/base.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;File/Spec/Win32.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/File/Spec/Win32.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;Data/Dumper.pm&#39; =&gt; &#39;C:/strawberry/perl/lib/Data/Dumper.pm&#39;,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&#39;App/whichpm.pm&#39; =&gt; &#39;lib/App/whichpm.pm&#39;<br> &nbsp; &nbsp; &nbsp; &nbsp;};<br> </code></p> jozef 2010-06-19T14:29:51+00:00 journal Learning from StackOverflow.com http://use.perl.org/~jozef/journal/40345?from=rss <p> <a href="http://www.youtube.com/watch?v=NWHfY_lvKIQ">http://www.youtube.com/watch?v=NWHfY_lvKIQ</a> </p><p>Joel shows that <a href="http://stackoverflow.com/">StackOverflow</a> is (||was?) running on 2 servers (+1 backup) using C# and SQL Server. Impressive<nobr> <wbr></nobr>:-) seek to 24:56 to see the full performance+tech table.</p><p>There is also a Perl+Perl6 mentioned in this talk, seek to 38:00 to hear the #1 thing you should never do...</p><p> <small>(<a href="http://jozef.kutej.net/2010/05/learning-from-stackoverflowcom.html">crossposted</a>)</small> </p> jozef 2010-05-06T06:55:28+00:00 journal Data::Keys http://use.perl.org/~jozef/journal/40327?from=rss <p>is just a base module responsible for loading extension (Data::Keys::E::*) during the object build time. It just makes sure one of the extensions supplied get() and set() method. The rest is up to the extensions.</p><p>get() should be called with one argument a $key and return value for it. set() should be called with $key and $value arguments returning modified (if it was) $key.</p><p>So far I've created this extensions:</p><ul> <li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Store::Dir">Store::Dir</a> - folder storage</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Store::Mem">Store::Mem</a> - in memory storage</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Dir::Auto">Dir::Auto</a> - auto create folder when needed</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Key::Adapt">Key::Adapt</a> - change key with a callback</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Key::Auto">Key::Auto</a> - auto create key via callback</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::UniqSet">UniqSet</a> - a key can be set only once</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Value::InfDef">Value::InfDef</a> - inflate/deflate values</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Locking">Locking</a> - get/set locking</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Dir::Lock">Dir::Lock</a> - uses additional folder to lock files</li><li> <a href="http://search.cpan.org/perldoc?Data::Keys::E::Dir::LockInPlace">Dir::LockInPlace</a> - place locks directly on the stored files</li></ul><p>How I want to use it now? Value::InfDef to help reading folders full of JSON files. Key::Auto to store data as Git does - based on the hash of data. Key::Adapt to easily access Debian distribution files in the pool folder or CPAN distributions files based on the AUTHORID/DISTRIBUTION in CPAN mirror folder structure.</p><p>For now there is just folder storage as I want to use it for some tasks, but it should be quite easy to create any key/value storage extension.</p><p> <small>(<a href="http://jozef.kutej.net/2010/04/datakeys.html">crossposted</a>)</small> </p> jozef 2010-04-25T17:40:23+00:00 journal dh-make-perl --locate Foo::Bar http://use.perl.org/~jozef/journal/40273?from=rss <p>I didn't know about this easy way to locate Perl modules in Debian packages.</p><p> <code> $ dh-make-perl --locate Foo::Bar<br> Using cached Contents from Fri Mar 26 10:25:51 2010<br> Foo::Bar is not found in any Debian package<br> <br> $ dh-make-perl --locate Moose::Meta::Class<br> Using cached Contents from Fri Mar 26 10:25:51 2010<br> Moose::Meta::Class is in libmoose-perl package<br> <br> $ dh-make-perl --locate Test::More<br> Using cached Contents from Fri Mar 26 10:25:51 2010<br> Test::More is in Perl core (package perl) since 5.6.2<br> </code> </p><p>So there is a ready made solution how to locate Perl modules in Debian packages. The '--locate' option is in Squeeze (testing) version of dh-make-perl or in <a href="svn:cvsaliothdebianorgsvnpkg-perltrunkdh-make-perl">the source repositiory</a>.</p> jozef 2010-03-26T09:44:16+00:00 journal How to get a CPAN module into Debian http://use.perl.org/~jozef/journal/40239?from=rss <a href="http://pkg-perl.alioth.debian.org/howto/RFP.html">http://pkg-perl.alioth.debian.org/howto/RFP.html</a> jozef 2010-03-11T10:35:49+00:00 journal Perl 5.12 for Squeeze? http://use.perl.org/~jozef/journal/40238?from=rss <p>"The squeeze freeze is also just around the corner AFAIK so I don't think there's much chance of 5.12 making it in. If somebody wants to step up and push for it, they should definitely talk to the release team first."</p><p> <a href="http://lists.debian.org/debian-perl/2010/03/msg00045.html">http://lists.debian.org/debian-perl/2010/03/msg00045.html</a> </p> jozef 2010-03-11T10:01:23+00:00 journal Illegal character 0x1FFFF http://use.perl.org/~jozef/journal/40136?from=rss <code> $ perl -le 'use warnings; my $x=chr(0x1FFFF)'<br> Unicode character 0x1ffff is illegal at -e line 1.<br> </code> <p>XML supports UTF-8 so I check for <a href="http://search.cpan.org/perldoc?String::isUTF8">valid UTF-8 string</a> and use it in XML if valid. Right? No!!!</p><p>There are some "non-illegal" characters that are perfect valid in UTF-8 (or even in the plain old ASCII), but are invalid for XML. The most obvious 0x00. Here is what <a href="http://www.w3.org/TR/REC-xml/#charsets">W3C XML 1.0 specification</a> say:</p><p> <i>[2] Char<nobr> <wbr></nobr>::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]<nobr> <wbr></nobr>/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */</i> </p><p>I spend some time playing with it and the result is <a href="http://search.cpan.org/perldoc?XML::Char">XML::Char-&gt;valid()</a>. The <a href="http://github.com/jozef/Data-asXML">dev Data::asXML</a> is using it now. If you you want, have a look at the test suit and try to break it.<nobr> <wbr></nobr>:-) </p> jozef 2010-01-27T20:56:05+00:00 journal My first Perl6 regexp grammar in Perl http://use.perl.org/~jozef/journal/40118?from=rss <p>Once I told <a href="http://use.perl.org/~potyl/journal">potyl</a> - "hey let's have a wiki it will be easy to use for everyone". He wasn't so excited, not at all. Why? What is so bad about wiki? Look at this table of <a href="http://www.wikimatrix.org/syntax.php?i=23&amp;x=25&amp;y=19">130+ wiki syntaxes</a>. Anyone still complaining that there are too many simmilar choices on CPAN? The wiki community decided to solve the problem by creating <a href="http://www.wikicreole.org/">yet another wiki syntax</a>...</p><p>What this has to do with Perl6 regexp grammars? After <a href="http://search.cpan.org/~DCONWAY/">Damian</a> talk at <a href="http://yapceurope2009.org/ye2009/talk/2088">YAPC::EU::2009</a> I really wanted to try out the <a href="http://search.cpan.org/perldoc?Regexp::Grammars">Regexp::Grammars</a>. Finally I found some time during the Christmas and here is <a href="http://gist.github.com/281109">the result</a>:</p><p> <code> use Regexp::Grammars;<br> use re &#39;eval&#39;;<br> my $parser = qr@<br> &lt;Wiki&gt;<br> <br> &lt;rule: Wiki&gt; &lt;[Block]&gt;*<br> &lt;rule: Block&gt; &lt;.EmptyLine&gt; | &lt;Code&gt; | &lt;Para&gt;<br> &lt;token: Para&gt; &lt;Heading&gt; | &lt;List&gt; | &lt;TextLines&gt;<br> &lt;token: EmptyLine&gt; ^ \h* \R<br> &lt;token: TextLines&gt; (?:^ (?! &lt;Code&gt; | &lt;Heading&gt; | &lt;List&gt; | &lt;EmptyLine&gt; ) [^\h]<nobr> <wbr></nobr>.+? \v)+<br> &lt;token: CodeStart&gt; ^ {{{ \h* \v<br> &lt;token: CodeEnd&gt; ^ }}} \h* \v<br> &lt;token: Code&gt; &lt;.CodeStart&gt; &lt;CodeLines&gt; &lt;.CodeEnd&gt;<br> &lt;token: CodeLines&gt;<nobr> <wbr></nobr>.+?<br> &lt;token: Heading&gt; &lt;HeadingStart&gt; \s &lt;HeadingText&gt; \s =+ \h* \v<br> &lt;token: HeadingStart&gt; ^=+<br> &lt;token: HeadingText&gt; [^=\v]+<br> &lt;token: List&gt; &lt;[ListItem]&gt;+<br> &lt;token: ListItem&gt; ^ &lt;ListItemSpaces&gt; &lt;ListItemType&gt; \h+ &lt;ListItemText&gt; \v<br> &lt;token: ListItemSpaces&gt; \h+<br> &lt;token: ListItemType&gt; (\*|\d+\.|a\.|i\.)<br> &lt;token: ListItemText&gt;<nobr> <wbr></nobr>.+?<br> @xms;<br> </code> </p><p>It is probably not the best piece of regexp gramar, Perl6 experts will for sure spot some error, but hey it works! "<a href="http://www.codinghorror.com/blog/archives/000818.html">Works on my computer</a>". I've used it to transform <a href="http://trac.edgewall.org/wiki/TracWiki">TracWiki</a> syntax to XHTML div and then using XSL to <a href="http://www.dokuwiki.org/syntax">DokuWiki</a> syntax. <a href="http://github.com/jozef/trac-export">Here are the scripts</a> that does it completely.</p> jozef 2010-01-21T17:37:53+00:00 journal we lost three men :-/ http://use.perl.org/~jozef/journal/40098?from=rss <p>It is only the beginning of 2010 and we already lost 3 men. Who? Why?</p><ol> <li>Emmanuel - a Perl guru now finally leaving Bratislava for <a href="http://www.booking.com/general.en.html?tmpl=docs%2Fcareer_opportunities#ams">booking.com</a> in the Amsterdam</li> <li>Jonathan - a <a href="http://rakudo.org/">Rakudo</a> (and many other programming or human spoken languages) guru <a href="http://www.jnthn.net/cgi-bin/blog_read.pl?id=713">leaving for Sweden</a></li> <li>Martin - network guru and manager that is programming in Perl, leaving for Sweden too</li> </ol><p>I would like officially say "Thank you!" to all three of them for what they have done and brought to the <a href="http://bratislava.pm.org/en/">Bratislava.pm</a> group.</p> jozef 2010-01-12T19:24:40+00:00 journal Wide screen? Let the search engines fight! http://use.perl.org/~jozef/journal/40085?from=rss <p> <a href="http://google.com/">Google</a> vs <a href="http://cuil.com/">Cuil</a> vs <a href="http://yahoo.com/">Yahoo</a> vs<nobr> <wbr></nobr>...</p><p>Wide screen offers a lot of horizontal space so why not to use it and search with two (or more) search engines at the same time? Try <a href="http://search.meonl.com/">search.meonl.com</a> (<a href="http://search.meonl.com/en/about.html">about</a>).</p><p>Where is the Perl there? There in the back. In the name of <a href="http://yapceurope2009.org/ye2009/talk/1930">static can be more</a> the meonl.com files are pure HTML+CSS+JS generated using <a href="http://search.cpan.org/perldoc?Template">Template Toolkit</a> ttree and some <a href="http://jozef.kutej.net/2009/11/make-for-fun-and-profit.html">Makefile rules</a>.</p><p>The <a href="http://search.meonl.com/">search.meonl.com</a> page is basically an input box and 1 or more iframes with search engines. Submitting a text in the input box results in reloading search engines with a search url.</p><p>Why was the <a href="http://search.meonl.com/">search.meonl.com</a> created? I got an idea how to do the web searches a little different way. But then I've realized - who the hell will try just another <a href="http://en.wikipedia.org/wiki/Web_search_engine">search engine</a>??? Well no one of course<nobr> <wbr></nobr>:-), but if there will be a way to keep <a href="http://google.com/">Google</a> (or any other major search engine) next to the new one, may there will be a little chance... I will probably never have enough time, money, energy and the rest one needs to start and finish such a project, but at least now there is a way how to compare how good the current search engines are - side by side.</p><p>The few days that I'm playing and searching with multiple search engines at once made me realize that, yes - the search engines are different. And yes - the other (than <a href="http://google.com/">Google</a> in my case) search engines can give better results sometimes.<nobr> <wbr></nobr>:-)</p> jozef 2010-01-07T21:24:16+00:00 journal I feel like no one ever told the truth to me... http://use.perl.org/~jozef/journal/40074?from=rss <p> <cite> I feel like no one ever told the truth to me<br> About growing up and what a struggle it would be<br> In my tangled state of mind,<br> I've been looking back to find where I went wrong.<br> -- Queen - Too Much Love Will Kill You </cite> </p><p>There are people that say reinventing the wheel is bad, that it shouldn't be done. That we should find an existing project and contribute there. Some even say that there are too many variants and choices of CPAN modules that are doing the same thing, and it is wrong. That it is contra productive and scary for the newbies. There are people that call them self CPAN police that hunt down new uploaders trying to show them how many mistakes they made...</p><p>Now look at the kids. Those experience <a href="http://news.bbc.co.uk/2/hi/education/4697461.stm">deferred success</a> 1000 times a day. Even if they don't fail they play most of the day. They play by repeating, copying from adults or other kids. They speak the same sentences wrongly over and over. They do the same things over and over. They fail over and over. They are just kids. Every one knows that this is how they learn. Next to the kids there is always some adult. Until the kids are really small, the adults seems like perfect to them, because they just do everything perfect.</p><p>After growing up, one day, kids finds out that the adults are not perfect. They don't do always the right thinks. And they don't know everything. The trouble is that there are many adults that think that they perfect are. But that is different topic. Let's go back to childhood.</p><p>To be precise the Perl programmer childhood. Perl programmer life. The difference is everyone is free to be born to the Perl world and grow up here. The other nice thing is that everyone is free to leave it and go and live a different life.</p><p>/me a Perl kid. I like to play, I like to try out things. I like to reinvent the wheel over and over. I don't mind that there are Perl grown-ups that do the same thing much better than I do. I don't mind that I will hit the ground while doing weird experiments. And? It's fun and everybody has to fall the first time. (and second and third and<nobr> <wbr></nobr>...) And I'm just a kid!</p><p>The Perl world is different to the "reality". The biggest difference is that it's hard to see the age. Everyone is growing with a different rate and some will never grow up - like me<nobr> <wbr></nobr>:-P</p><p>So I would like encourage all kids to come play with toys, throw them away if they don't like them any more and not be ashamed that they "just" build "another" sandcastle. You can always destroy it and build another one, don't you?</p><p>Now back to the desert of the real. There is a plenty of legacy Perl code every where around us. Legacy sometimes mean undocumented, unmaintained, badly written or just not understood. Sending bad words and blaming people that wrote it will not fix the situation. Everyone is doing the best he can, considering his experience, mood, moon phase, weather conditions,<nobr> <wbr></nobr>... at the time of writing the code. If the makes the job done, it is good. If it makes someone happy writing it, it is even better. And if there is no replacement, it is the best code ever!</p> jozef 2010-01-04T19:44:43+00:00 journal Just put it where it belongs http://use.perl.org/~jozef/journal/40055?from=rss <p>Still there after reading <a href="http://jozef.kutej.net/2009/12/once-uppon-a-time-there-was-a-sysadmin.html">this</a> and <a href="http://jozef.kutej.net/2009/12/use-config-discover-your-path.html">this</a>?. What I would like to show next is <a href="http://search.cpan.org/perldoc?Module::Build::SysPath">Module::Build::SysPath</a> and the usage for <a href="http://hexten.net/cpan-faces/">CPAN authors</a>. What are the features?</p><ul> <li>pre/post install paths (dev+test/prod)</li> <li>system paths configured once when <a href="http://search.cpan.org/perldoc?Sys::Path">Sys::Path</a> is installed</li> <li>"Debian way" of handling configuration files</li> <li>automatic all files copying</li> <li>creating of empty folders (for state, log, etc. files)</li> </ul><p> The main reason for existence is to install files (configuration, templates, data files,<nobr> <wbr></nobr>...) where <a href="http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard">FHS</a> recommends and also to know where to put temporary files (like state, lock, cache,<nobr> <wbr></nobr>...). </p><p> There are couple of stages that the CPAN distribution is going through. Development, smoke testing, pre install and install stage. In all of those it is good to know where our files are.<nobr> <wbr></nobr>:-P Before the final install the files are always inside the distribution folder, only after install the files are in the system folders. There for the <a href="http://search.cpan.org/perldoc?Module::Build::SysPath">Module::Build::SysPath</a> requires a special module YouModuleName::SPc that gets overwritten with values from <a href="http://search.cpan.org/perldoc?Sys::Path">Sys::Path</a> once installed. </p><p> There are, as always, couple of other ways how to store and work with non-perl modules files. Here are some that I'm aware of: </p><ul> <li>storing data inside __DATA__ in<nobr> <wbr></nobr>.pm file</li> <li>storing files in the same folder as<nobr> <wbr></nobr>.pm files</li> <li>storing files in auto/ - <a href="http://search.cpan.org/perldoc?File::ShareDir">File::ShareDir</a></li> <li>hardcoded system folders</li> <li>use Sys::Path paths directly</li> <li>???</li> </ul><p>Everyone can choose.</p> jozef 2009-12-29T16:59:33+00:00 journal use Config; # discover your path http://use.perl.org/~jozef/journal/40044?from=rss <p> Reasoning why knowing the system paths is a good idea can be found <a href="http://jozef.kutej.net/2009/12/once-uppon-a-time-there-was-a-sysadmin.html">here</a>. Now let's see how one can guess (get?) them in Perl. </p><p> There are a lot of Perl installation made to non-standard paths. Like: </p><ul> <li>/usr/local/bin/perl</li> <li>/home/$USERNAME/local/bin/perl</li> <li>C:\Strawberry\bin\perl</li> <li>/opt/bin/perl</li> </ul><p> I was trying to find out what do this installations share and what could be used to find out if the Perl is in file hierarchy standard folder -<nobr> <wbr></nobr>/usr/bin/perl. The simplest way, that I found out, was to: </p><p> <code> use Config;<br> if ($Config::Config{'prefix'} eq '/usr') {<nobr> <wbr></nobr>... do stuff<nobr> <wbr></nobr>... }<br> </code> </p><p>That is basically all <a href="http://search.cpan.org/perldoc?Sys::Path">Sys::Path</a> does. If the installation prefix was set to "/usr" (in all Linux distributions standard Perl packages it is), than the rest of system paths is by default set to <a href="http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard">FHS</a>. If not all of the paths are based on the prefix - $PREFIX/etc, etc.</p><p>Just check the Pod of <a href="http://search.cpan.org/perldoc?Sys::Path">Sys::Path</a> for all the different paths and their usage.</p><p>too simple? but works<nobr> <wbr></nobr>:-)</p> jozef 2009-12-22T13:38:46+00:00 journal Once uppon a time there was a sysadmin http://use.perl.org/~jozef/journal/40023?from=rss <p>Once upon a time I was a young system administrator. Having all the strange looking<nobr> <wbr></nobr>/usr,<nobr> <wbr></nobr>/var,<nobr> <wbr></nobr>/etc,<nobr> <wbr></nobr>... all round me was scary and I was not sure what to "do" with all those folder trees. At some point I started to compile the extra programs that I needed. With a default prefix all ended up in<nobr> <wbr></nobr>/usr/local which looked safe to me. I knew that my stuff is there and the mysterious system stuff is everywhere else.</p><p>Well it worked. Having to maintain some more servers later I started to do some packaging. I was using Slackware at that time and the Slackware packaging system was really simple - just a tarball that got extracted to the root of the file system with some scripts that got executed during the package installation time. Simple and worked for me. Still I kept the stuff in<nobr> <wbr></nobr>/usr/local to be on the safe side.</p><p>And the time passed<nobr> <wbr></nobr>:-) and I'm using Debian now, but most important change is that I've lost all my respect to the file system and I've learned where and why to put files. Why to use<nobr> <wbr></nobr>/etc for configs,<nobr> <wbr></nobr>/var/log for logfiles,<nobr> <wbr></nobr>/var/lib for state files,<nobr> <wbr></nobr>/var/cache for cache files,<nobr> <wbr></nobr>/usr/share for templates or static data files, etc.? Simple because it is standard. Because it is standard, standard compliant distribution will stick to it. Besides being standard there are some really good reasons too. Helper tools will understand the files and then act based on the files category. Automatically rotating logs, backup-ing the important (non static distribution) files, cleaning up the temporary files etc. Well and there are also humans out there. Co-admins or newcomers, that will login to the machine and look for files or trouble shoot the programs. Knowing where to look for stuff really helps!</p><p>With today advance of virtualization techniques there is no reason to mix too many things (projects) on one server. So there is no reason to play safe with the paths and files should be put to the right place where they belong - <a href="http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard">FHS</a>.</p><p> (to be continued with Perl part of the story...)</p> jozef 2009-12-15T20:18:21+00:00 journal Installing CPAN module dependencies listed in META.yml http://use.perl.org/~jozef/journal/40007?from=rss <p>Have you ever had a Perl distribution extracted and wanted to install all it's dependencies afterwards? You can do it using:</p><p> <code> cpan -i Test::Install::METArequires<br> perl -MTest::iMETAr -le 'Test::iMETAr-&gt;t'<br> </code> </p><p>The output will be <a href="http://www.testanything.org/">TAP</a>. One test per dependency. Is there some other (better) way to do it? Should be as always...</p> jozef 2009-12-11T10:52:12+00:00 journal Re: when virtualization is too expensive http://use.perl.org/~jozef/journal/40003?from=rss <p>Reply to two commanets from "<a href="http://use.perl.org/~jozef/journal/39979">when virtualization is too expensive</a>".</p><p>1st was from <a href="http://use.perl.org/comments.pl?sid=44251&amp;cid=71324">grantm</a>. Thanks for pointing out the <a href="http://wiki.openvz.org/Main_Page">OpenVZ</a>. It's much more professional tool than debootstraping and chrooting, but comes with more configuration and setting-up complexity. It's possible to share memory using OpenVZ which is the resource that we never have enough.</p><p>2nd was from <a href="http://use.perl.org/comments.pl?sid=44251&amp;cid=71349">Alias</a>. Alias is pointing out the deduplication of disk data. Disk space is kind of cheep these days, comparing to memory, bandwidth and cpu processing costs when dealing with huge data. The deduplication can offer, besides saving the disk space, a better cache efficiency, that will increase disk read speed, that is never fast enough. ZFS should soon (first quarter of 2010) support <a href="http://en.wikipedia.org/wiki/Zfs#Deduplication">deduplication</a>. It seems that there will be no native ZFS support for Linux because of the <a href="http://en.wikipedia.org/wiki/Zfs#Linux">licencing problems</a><nobr> <wbr></nobr>:-( . Easy Linux deduplication that can come in handy is <a href="http://freshmeat.net/projects/cowdancer/">cowdancer</a>. <code>`cp -al some-folder/ some-folder.copy &amp;&amp; cd some-folder.copy &amp;&amp; cow-shell`</code> will copy "some-folder" via creating hardlinks which is really fast. Than any write operation under this shell and folder will result in removing the hardlink and creating a new file =&gt; copy-on-write. This works good with chroot-ed systems to test new Perl module versions or do some other experiments.</p> jozef 2009-12-10T19:22:02+00:00 journal when virtualization is too expensive http://use.perl.org/~jozef/journal/39979?from=rss <p>Yes the thing that turns your single computer to multiple computers. Why should it be expensive? Simply because the virtual machines are not sharing one disk space and one memory. To make the the virtual system run smoothly, it needs some decent amount of dedicated memory and a disk volume with some reserve so it doesn't have to be resized too often.</p><p>First find the reasons for doing virtualization, why would anyone want to run multiple machines on a single hw? Most likely to clearly separate the programs and the whole operating systems. Give the strictly defined virtual hw resources, limit the access for security reasons. And also to add one level of abstraction which then allows systems to live in a cloud. But that is a different topic.</p><p>Let's search for the solutions how not to do virtualization and fulfil some (!) of the requirements of it. Mainly the clear files and whole system separation for Perl development.</p><p>If just Perl is in the play, then compiling and installing user own Perl is an option. Simply having the Perl binary and all the installed CPAN modules in the $HOME directory of the user.</p><p>If Apache is needed or some extra binary libraries, it is still possible to compile and install to the user home, but it is quite a lot of "hand work" and not every one has time and passion to do it. Much more simple way is to use chroot. What chroot does is that it sets root of the filesystem for the child processes to a folder. And as we are in UNIX, where (nearly) anything is a file, this means a different machine. Both systems, the parent and the chroot-ed, still share the same<nobr> <wbr></nobr>/proc,<nobr> <wbr></nobr>/dev, network devices etc., but the separation is enough to be able to install programs with standard distribution commands and run them. Fair enough to have chroot-ed machine as a development machine. Benefiting of shared memory and disks pace, easy file sharing (one filesystem) and not having to maintain virtualization sw.</p><p>Here is how to create a chrooted system on Debian and switch to it:</p><p> <code> debootstrap lenny<nobr> <wbr></nobr>/usr/chroot/$MACHINENAME<br> echo ${MACHINENAME}_chroot &gt;<nobr> <wbr></nobr>/usr/chroot/$MACHINENAME/etc/debian_chroot<br> chroot<nobr> <wbr></nobr>/usr/chroot/$MACHINENAME su -<br> </code></p> jozef 2009-12-04T19:49:19+00:00 linux CHI -- Unified cache interface http://use.perl.org/~jozef/journal/39964?from=rss <p><a href="http://search.cpan.org/perldoc?CHI">CHI</a> looks interesting - one Perl module interfacing to any kind of cache. The "L1 cache" + "mirror cache" is a technique worth looking at and it adds more value to the module beyond just an unified interface.</p> jozef 2009-11-30T20:04:19+00:00 journal So I've thrown away my feedback http://use.perl.org/~jozef/journal/39949?from=rss <p>I wrote recently about <a href="http://jozef.kutej.net/2009/11/6-feed-us-back.html">feedback.cgi</a> on <a href="http://bratislava.pm.org/">Bratislava Perl Mongers</a> page. It turned out to be useful only to deliver more spam. Today I've replaced it with a <a href="http://www.google.com/support/toolbar/bin/answer.py?hl=en&amp;answer=164493">JavaScript bookmarklet</a> to the new evil thing from Google - <a href="http://www.google.com/sidewiki/">Sidewiki</a>. So everyone has still a chance to annotate the pages and I have one less thing to maintain. Win-Win.</p><p>Btw this is how one can get the sidewiki RSS feed url for http://bratislava.pm.org/ page:</p><p> <small> <code> perl -MURI::Escape -le 'print "http://www.google.com/sidewiki/feeds/entries/webpage/", uri_escape($ARGV[0]), "/default?includeLessUseful=true"' http://bratislava.pm.org/ </code> </small></p> jozef 2009-11-26T17:00:03+00:00 journal simple (stupid?) other XML way arround http://use.perl.org/~jozef/journal/39937?from=rss <p> There are 2625 XML modules atm on CPAN. (`zcat 02packages.details.txt.gz | grep -E '\bXML\b' | wc -l`) So why not create another one? There are number of modules that are trying to map XML structure to Perl data structures. This can never be perfect and sometimes needs custom hooks to adapt. What about the other easy (easier) way around? Serializing Perl data structures to XML? I've made an experiment. More about it <a href="http://jozef.kutej.net/2009/11/simple-stupid-other-xml-way-arround.html">here</a> or in Pod of <a href="http://search.cpan.org/perldoc?Data::asXML">Data::asXML</a>.</p> jozef 2009-11-24T08:37:19+00:00 journal Anyone working on event-based MVC? http://use.perl.org/~jozef/journal/39903?from=rss <p>Does anyone knows of a Perl MVC implementation that is based on some event loop? Having non-blocking IO (filesystem/database) in web request handling would be nice to have. That will enable to have just one process per CPU. The IO is the only reason why "<a href="http://jozef.kutej.net/2009/11/8-one-apache-child-must-be-enough-for-everyone.html">one process is NOT enough for every CPU</a>"</p> jozef 2009-11-16T10:50:49+00:00 journal finished the series on friday http://use.perl.org/~jozef/journal/39876?from=rss <p>enjoy! (ignore?)</p><ol> <li> <a href="http://jozef.kutej.net/2009/11/make-for-fun-and-profit.html">make mehappy &nbsp; # make for fun and profit</a> </li><li> <a href="http://jozef.kutej.net/2009/11/2-a-hook-for-you.html">a hook for you</a> </li><li> <a href="http://jozef.kutej.net/2009/11/3-scraping-my-self.html">scraping my self</a> </li><li> <a href="http://jozef.kutej.net/2009/11/4-less-can-be-more.html">less can be more</a> </li><li> <a href="http://jozef.kutej.net/2009/11/5-doveruj-ale-preveruj.html">d&#244;veruj ale preveruj</a> </li><li> <a href="http://jozef.kutej.net/2009/11/6-feed-us-back.html">feed us back</a> </li><li> <a href="http://jozef.kutej.net/2009/11/7-xslt-hammer.html">XSLT hammer</a> </li><li> <a href="http://jozef.kutej.net/2009/11/8-one-apache-child-must-be-enough-for-everyone.html">one Apache child must be enough for everyone</a> </li></ol><p> <small>(hmm I was missing word Perl for IronMan here...)</small> </p> jozef 2009-11-11T08:08:37+00:00 journal 5. d&#244;veruj ale preveruj http://use.perl.org/~jozef/journal/39830?from=rss <p>"5. trust but verify" - some time ago I've promised to do <a href="http://use.perl.org/~jozef/journal/39548">blog series</a> and a lot of water went down the river since then so it's really time to full fill the promise.</p><p>Why starting with part 5? As there was just one comment, from <a href="http://andy.sh/">andy.sh</a> that he likes the $title, on the schedule announcement, I assume it is the most interesting one.<nobr> <wbr></nobr>:-)</p><p> All (most?) CPAN authors are writing tests. Tests are cool, let us sleep well, let us discover "oh I forgot" thinks. </p><p>While code is once written and remains that way for a while, most pages these days are generated on the fly to put personalized information, banners or what ever fancy shiny stuff. This may make the testing a bit more difficult. Having the pages statically generated allows to easily test and most important validate pages still on dev system. </p><p> Let's have a look at <a href="https://cle.sk/repos/pub/www/tt-pm/trunk/script/vxml">vxml</a> script. It will validate any xml file or a folder with<nobr> <wbr></nobr>.html,<nobr> <wbr></nobr>.xml,<nobr> <wbr></nobr>.rdf files using <a href="http://search.cpan.org/perldoc?XML::LibXML">XML::LibXML</a> for validation. In addition all internal links (a href, img src) in HTML files are extracted and tested if their target files exists. The output of testing is <a href="http://testanything.org/">TAP</a>. What else will be better if TAP can test anything?<nobr> <wbr></nobr>;-). </p><p>While <a href="http://bratislava.pm.org/">ba.pm.org</a> can be generated statically some pages can not, especially the once requiring users to login. Lot of them have a high load and testing every request will kill (already loaded) machines. One technique is to take randomly only every Xth request and test that one as the part of response to the client. When put to <a href="http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlCleanupHandler">PerlCleanupHandler</a> than it has no effect on user experience.</p> jozef 2009-11-02T16:30:42+00:00 journal "the Perl is dying" vs "you ain't seen nothing yet" http://use.perl.org/~jozef/journal/39793?from=rss <p> <a href="http://www.ted.com/talks/view/id/286">Benjamin Zander on music and passion</a> </p><p>In case of Perl, you ain't seen nothing yet!</p> jozef 2009-10-23T15:08:43+00:00 journal about a future of Perl http://use.perl.org/~jozef/journal/39770?from=rss <p>Last Thursday we have had a <a href="http://bratislava.pm.org/">Bratislava.pm</a> meeting with two topics. </p><p>1st one, thanks to <a href="http://andy.sh/">Andrew Shitow</a>, was about code generation or if you want compiling for compilers. He demonstrated this on a finding primes with Perl6 program. It was nice and you can still enjoy this talk on many places that Andrew has on his this year's roadmap. It is an example of reusability, the beauty of code generation and a showcase of a way which to try when doing optimizations. It's also a really good example how we, Perl hackers, want to always do thinks our own way<nobr> <wbr></nobr>;-) The speed is nice, but not always and the Rakudo project should not get tied with premature optimization at this stage.</p><p>2nd talk, thanks to <a href="http://search.cpan.org/~potyl/">Emmanuel Rodriguez</a>, was about a game made with CPAN authors - <a href="http://github.com/potyl/pexeso">Pexeso</a>. Most of Perl developers don't like to do graphics, JavaScript, web design and graphics effects. Seeing 3D OpenGL effects animating, rotating, zooming in and out done in couple of lines of Perl code looked impressive. And showing this to someone that is asking "why Perl?" might do the trick of convincing.</p><p>effect++ # is selling</p> jozef 2009-10-19T06:10:58+00:00 journal now back to work (again?) http://use.perl.org/~jozef/journal/39758?from=rss <p>It has a long time agon since I've posted here. Until YAPC::EU (for 3+ months) I'he tried to keep up with one post per week even it was not easy. The Iron Man competition (challenge?) has a good intention to make a lot of noise, but this can also slip to become an low-quality noise. On the other hand, not every post has to be crowded with information. Does it? After all it's just a blog. Or? Still it takes time and it is suppose to take time every week. Hopefully it's a good investment (payback?) to Perl community.</p><p>Another, or different kin, Iron Man issue is that it aims for English blog posts. Yes I know that there are also Russian, Japanese blogs, but those are minor and look strange, in the middle of the English flood. Still blogging (or doing noise) in local language can be much more useful for the purpose or bringing (enlightening) to Perl new people than writing in English where the information flow is plentiful. The same reasoning as for translating perlpod.</p><p>Jet another reason was that I was busy doing different things than blogging. Actually working<nobr> <wbr></nobr>:-) besides the day job, I did an experiment to bring <a href="http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard">FHS</a> to Perl which is not ready to blog about. Or should we blog also about things that are a total drift to unknown? Than when it turns out to be "no so great" (read stupid), the internet will never forget... I've also managed to install a <a href="http://www.movabletype.org/">MT4</a> on my server (which was not without <a href="http://jozef.kutej.net/2009/09/mt4-utf-8-encoding-problems.html">a, still unresolved, issue</a>) and created not one but two blogs! One for things that are <a href="http://jozef.warum.net/">not sane</a> and one for <a href="http://jozef.kutej.net/">more serious stuff</a>. The main reason, among others, for not using <a href="http://use.perl.org/">use.perl.org</a> is that there is no way to post entries with images. Still I'll post my Perl blog entries here, but I'll post different not-just-Perl related there. After all this blog is registered to the Iron Man competition not those.<nobr> <wbr></nobr>:-)</p> jozef 2009-10-15T06:09:38+00:00 journal