Padre blogs

Perl::Staff has just been released as version 0.02 which includes updated and new blog links to CeBit reports and fixes some POD char and formatting errors.

Look at it on CPAN or grab and perldoc it

Thank you for reading this article. If you continue, please read it completly before judging or writing about it and expecially before using any information written here!

We were talking to many PHP guys on CeBit 2010. I tried showing the huge power of Perl but – as far as I remember – I never said anybody “forget PHP”. Here are the most important items (odered by usual order of appereance):

1. You don’t need to learn Perl

Neither PHP not Perl people like that fact, but PHP was originally based on Perl. There are still many similarities between both considering keywords and syntax. But most PHP people agree if you say: “If you know PHP, you basically know a good amount of Perl.”

2. CPAN

There are about 20.000 modules for all kinds of things on CPAN, like database access, file parsing, templating and math and all of them are free. All CPAN modules could be installed by a CPAN client which usually comes with your Perl.

Please tell me if you know any other language which has something comparable.

3. DBIx::Class

Most of the PHP users also use MySQL but for the full time of CeBit 2010, I met only one person (who actually was a database expert with some PHP knowledge) who answered the question “Do you like to write SQL statements, expecially SELECT JOINs over some tables?” with yes, all others answered between “no”, “not really” and “less than writing PHP”.

Basically DBIx::Class abstracts the SQL statement layer: Your source dosn’t need to contain one SQL statement any longer. The results are:

• No need to SELECT JOIN, just point DBIx::Class to some property of the table row you need, maybe using a referenced table in just one line of source.
• Once you got your object, you could use all referenced tables as simple childs. Sample: $user->customer->company gets the company name out of the customer table starting from the user table pointing to the customer table.
• DBIx::Class reduces database load by fetchting the object when it’s first actually used, not at the time the object is created.
• DBIx::Class makes SQL injection impossible because it’s encapsulated by DBIx::Class without any additional development.
• Reduces development time of database actions by about 50% compared to writing SQL statements (depending on the developer, of course)

Nothing written above has anything to do with comparing PHP and Perl. It’s just comparing DBIx::Class to $dbh->select… (or other ways sending SQL statements in other languages). There is something on PHP which might be compareable to DBIx::Class even (up to me) it isn’t nearly as powerful as DBIx::Class, but most PHP – people I met on CeBit 2010 were still writing plain SQL statements – as I did about eight month ago.

Also remember that using DBIx::Class will introduce a slight part of OOP even to people who don’t actually use it. Up to me this would be the preferred way of starting OOP development because it’s a slow start – you could add more and more OOP as time goes by and you feel ready to look into another world.

4. Catalyst and Template::Toolkit

There are technologies for PHP which are really better in many situations than these two. Catalyst is a complete Web framework which reduces the typical programming amount for weblications and Template::Toolkit (TT) provides a very powerful template engine, but I was working together with some webdesigners in the past which can’t handle it because it was too programmish.

If you pass a DBIx::Class object to TT, the one writing the HTML code could easily access all data of the table row including any child objects and any future changes to the table structure without any additional application source.

5. Coming back to CPAN

I wrote about three examples of the more than 20.000 CPAN modules, but if you ask people what else do they want to do and live-search for it on CPAN, it usually gives you some results. Please recheck this if/when the CPAN search engine (which shows modules even on very slow relations to the search) is being fixed.

Good samples to show are

• Parse::CSV for parsing CSV files in two minutes development time instead of ten
• Creating or modifiing PDF files
• Accessing external things like network servers of any kind

6. How to start

Padre, the free Perl IDE comes with some few lessons within the examples, not enough for really learning Perl but good for looking into the syntax.

The next step would be http://learn.perl.org for many more resources how to learn Perl.

If you want to meet the community, look at the PerlMongers groups who meet maybe also in your area.

If you don’t even want to look at Perl…

…you should at least try Padre which also has a PHP plugin for working on PHP files. You’re welcome to improve it by testing or changing the source.

Last notice: Writing Padre Plugins in PHP should theoretically be possible using the Parrot engine, if you want to try it, please add your experiences to the Padre Trac wiki.

Five days CeBit 2010 are over now. Perl was lucky to be one of 15 open source projects who got a booth for free, sponsored by the CeBit and Linux New Media.

Facts about CeBit 2010:

• 334.000 visitors
• 4.157 exhibitors from 68 countries
• 3% more visitors per day (until friday)
• 80% business visitors (until friday)

(source: http://www.cebit.de)

The first two days were the most successful ones in terms of business contacts and interest in Perl.

Wednesday to friday also went good on contacts even if the amount of private visitors increased a little bit each day.

Saturday was mostly private day, many young people came to our booth and asked about Perl.

We planned to…

…introduce Perl to the companies we may meet there. Three special project days were planned for Padre, Foswiki and OTRS where people of these projects planned to be at the booth. We also had beermats of DBIx::Class, Moose and Catalyst, some Tuits and many many marketing papers for distribution.

We failed on…

…bringing Perl into the companies because we learned that most companies already use Perl; for many applications like

• basic network management
• oneliners for quick testing
• data conversion
• preprocessing high volume print job data
• many things in banking business
• telecommunication and internet processing
• health data processing and analysis

If I’d write down the company names for each sample, you’d be as surprised as we were, but most people visiting us were developers or IT managers and they’re usually not allowed to give us permission to write that their company uses Perl.

Some few companies refused to be published at all for security reasons and I will respect this, but the other Perl::Staff people and I are in contact with the people we meet and I hope that we’ll be able to publish the first company names with official approval during the next week.

We learned…

…many things including that we brought something for every visitor to our booth:

• Developers currently using (Visual) Basic, PHP or Phyton were mostly interested to hear about Perl and Padre
• Java, C++ and C developers usually liked the idea that Perl could easily test their programs because most of them didn’t do any automated tests at all
• All the OOP people (Java, C++ and others) were really impressed about Moose
• Everybody using SQL statements wondered how much DBIx::Class could speed up their development
• Most developers found Padre interesting (except of one guy using the Progress language which currently isn’t supported)
• Businessmen not developing themself were impressed that Foswiki is able to limit read and/or write access to documents to users or groups and could be used for employees, the public homepage and printing brochures and manual books without maintaining three individual copies of the same document
• A women leading the account department of her company confirmed heavily that customers like to write mails to the wrong department, ask the same things multiple times each day and love to write question mails without and required information. We “sold” her OTRS which manages incoming requests, has groups, allows tracing of who-did-what-and-when and simple forwarding of requests to the correct group while terms of open source “sold” stands for “promised to download and try it”
• It’s easier to actually run a booth even on such a big event like CeBit than we expected, but
• it’s much more tiering to run a booth on such a big event like CeBit than we expected.

It was really nice…

to meet szabgab, reneeb, getty and the other Perl::Staff people in reality.

Szabgab and I had interesting discussions in the evening, some new ideas were born and I learned many things about Perl, the Perl community and Perl-related tools on the net.

Getty donated some Vodka to Hessen (actually to their booth people) and also enjoyed the other after-CeBit-parties (I think).

Final results and thanks

We talked to some of the people from other projects and Britta from Linux New Media while packing our things together on Saturday evening and most of them (including us) said that Perl was “the winner” of this event. I think we were one of the projects getting the most visiters within the Open Source Lounge, learned very much about running a booth and Perl usage.

Very big thanks go to Andreas “ads”, the Postgres guy, he told us about the OpenSource Lounge and how to get there.

Also thanks to reneeb and szabgab for organizing everything and Britta from Linux New Media for inviting us and arranging an unplanned lighting talk for szabgab.

Currently, we all would like to meet again on CeBit 2011…

Eigentlich wollte ich jeden Abend hier ein bisschen über die CeBit 2010 und unsere Erlebnisse auf dem Perl-Stand bloggen. Eigentlich.

Die Realität sieht so aus, dass das gesamte Perl::Staff – Team @ CeBit Abends einfach nur fertig ist

Wir hatten sehr sehr viele interessante Gespräche und mussten feststellen, das unser Plan, Firmen für Perl zu begeistern, in den allermeisten Fällen undurchführbar ist – weil fast jede Firma es bereits nutzt.

Wir haben von vielen interessanten Applikationen erfahren, wurden aber in aller Regel gebeten, keine Firmennamen oder Anwendungsdetails zu veröffentlichen, bevor die entsprechen Marketingabteilungen der Firmen ihr OK gegeben haben.

Hier vorab eine kleine Liste von Branchen, in denen Perl teilweise sogar sehr weitreichend engesetzt wird:

• Banken
• Telekommunikation (SMS, Datenaufbereitung, Datenbankkopplung)
• ISPs
• Consulting
• Wetterdatenaufbereitung

Morgen ist der letzte CeBit-Tag und das ist einerseits schade, denn es macht viel Spaß mit den Leuten über Perl zu reden und andererseits gut, weil die Energie und Konzentration jeden Tag nachlässt – bei allem Spaß ist es auch ein ziemlicher Stress.

Als CeBit Fazit kann man bereits jetzt sagen, das ich nicht annähernd mit diesem Erfolg gerechnet hätte. Wir haben fast durchgehend Leute auf dem Stand, sehr sehr viele kannten Perl bereits und fast allen konnten wir Perl nahebringen oder zumindest einige neue Informationen und Arbeitserleichterungen vermitteln. Zudem haben wir viele sehr interessante Kontakte knüpfen können, die nächste Woche nachbearbeitet und gepflegt werden müssen.

Nach einigen kleineren Problemchen wie defekten Autos oder sturmbedingte Zugausfälle haben es dennoch alle geschafft, wie geplant am Abend vor der Messe in Hannover einzutreffen.

Was erwartet Besucher am Padre / Perl – Stand?

• Padre – Entwickler und Perl – Experten treffen
• In Perl geschriebene Spiele mit der Möglichkeit, diese nach Bedarf abzuwandeln
• Präsentationen von Foswiki, OTRS und anderen Perl – Projekten
• Viel Informationsmaterial rund um Perl

Perl und Padre sind in der Open Source Lounge in Halle 2, Stand F34.

As my secret new years resolution I decided to turn CPAN::Forum into the most awesome resource for everything about CPAN. It's a long project. Among the many things it needed a facelift to make it nicer to the visitor. As I hardly know any web design I looked around and tried to copy from other websites while learning more about HTML, CSS and design in general.

With CSS one of the problems I encounter is that I keep forgetting the order of the values padding and other elements can get. This is partially due to old age but also due to the fact that I am not too familiar with the subject yet. I need more hand holding than an expert in CSS. So I reached for my favorite Perl editor and updated its CSS support to provide context sensitive help for CSS documents.

The basics are very simple. When I press F2 while the cursor is on one of the elements (e.g. padding:) the code looks up the relevant explanation in a yaml file I started to create. As I need help with various CSS tags I read about them and then I can add the explanations to the yaml file. The file is now loaded every time I ask for help (which is actually I think a bug in Padre or in my code) but right now it is actually good as this way it is enough for me to update the yaml file with my latest understanding and voila, I have the help showing up.

The tight feedback cycle helps me a lot working on this.

Parsable version of the CSS documentation?

It is very nice that I can write my own documentation for CSS now but I believe there are various documents that could be used to provide all this text with a much higher quality. I just have not found the documentation yet. So if you happen to know where can I get a file describing the various CSS tags and possible values that could be parsed and from which I could extract a mapping of CSS keywords to description, please let me know.

The implementation in Padre

If I am already writing about this, let me go through the code as I implemented in Padre. While by the time you are reading this the actual code might have changed, this can be a good start to implement similar help for any computer language regardless if that is a programming language, a markup language or any other language.

In Padre every document type has (or can have) its own class. So does CSS, in the Padre::Plugin::CSS. The first step was to implement a call-back in the CSS document class:

  sub get_help_provider {
    require Padre::Plugin::CSS::Help;
    return Padre::Plugin::CSS::Help->new;
  }

This is actually a bit too much. I think Padre should support the return of the name of the provider and call new by itself but it is good enough now.

When a text is selected and F2 is pressed, Padre automatically sends the selected text to the helper class but if there is no selection then Padre will look up the word around the cursor.

In order to provide better customization, Padre also calls the find_help_topic method of the document class and allows that call to return the current topic.

This code I copy pasted from the main find_help_topic function and it will require some further refactoring but as a first pass it is good enough.

Once the topic is selected Padre uses the Help Provider as defined in the get_help_provider and uses that to look-up and display the help.

The help provider class needs to have three methods:

The help_init method is there to load any external look-up table. I think it should be called only once per document per Padre but currently it is called every time I press F2. Maybe the idea is that each helper class should decide on its own caching strategy. After all maybe it is connected to a huge database and we don't want to load all that content into memory.

In my case it is now reloading the yaml file every time which is actually quite good for development.

  sub help_init {
    my ($self) = @_;

    my $help_file = File::Spec->catfile(Padre::Util::share('CSS'), 'css.yml');
    $data = LoadFile($help_file);

    return;
  }

The window displaying the help has a list of all the keywords. This list is given by the help_list method. In our case it is quite simple and looks like this:

  sub help_list {
    my ($self) = @_;
    return [keys %{ $data->{topics} }];
  }

The third method is the actual code that gets a keyword (though it is called topic in our case) and return both an html file to be displayed and a string that is going to be the title bar. In perl 5 we put the path to the source of the documentation - the pod file - there but in the case of CSS I just returned the topic.

  sub help_render {
    my ( $self, $topic ) = @_;

    $topic =~ s/://;
    my $html = "No help found for '$topic'";
    if ($data->{topics}{$topic}) {
      $html = "$topic $data->{topics}{$topic}";
      $html =~ s/REPLACE_(\w+)/$data->{replace}{$1}/g;
    }
    return ( $html, $topic );
  }

That's it. It was quite simple to add the supporting code, though there are still items that need to be implemented. E.g. I'd like to make sure words with a dash in the name such as background-color, values that include a number (e.g. 4px) and pseudo-class selectors such as :visited are also recognized and provide proper help.

It would be nice to use some ready made CSS documentation and finally to actually make CPAN::Forum look good.

This year’s FOSDEM was great. Not only did we have a Perl stand, but we could also meet face to face with other Padre developers. Here follow some loose impressions of the weekend…

Hall of Distributions

Hacker Room

Open Solaris

Erik @ the Perl Stand (with a "tuit")

Perl/Padre developers Dave and Gabor

Catalan Perl Monger (forgot the name, please forgive me...)

O'Reilly

FSF Europe: respect!

BSDs

Gabor's CPAN talk

Salve's talk on Kaizendo.org

The Hat

Well, there is now an alpha version of Strawberry Perl Professional up. I'm calling it 5.10.1.1 Alpha 1 (as opposed to, say, "5.10.1.2 Alpha 1") because it's be built on top of Strawberry Perl 5.10.1.1. [The January 2010 version.]

"Strawberry Perl Professional 5.10.1.1 Alpha 1" includes:

1. All graphical toolkits that I know about and can get to build easily (Tk, Wx, and Win32::GUI at the moment. OpenGL will be in the next version.)


2. Graphical CPAN client (CPANPLUS::Shell::Wx) and POD viewer (Tk::Pod) *


3. The Padre perl IDE, and Perl::Tidy, Perl::Critic, and Catalyst plugins for it.


4. Moose and a number of MooseX modules.


5. Catalyst::Runtime, Catalyst::Devel, and a number of Catalyst/CatalystX modules, including the Catalyst::Manual.


6. A console Perl-language shell (Perl::Shell) - Devel::REPL may be in the next version. **


7. Dist::Zilla, Devel::NYTProf, Perl::Critic, Perl::Tidy, BioPerl...


8. ... and everything that's already in Strawberry Perl.

(Everything that's specifically in Professional is listed in DISTRIBUTIONS.txt)

One goal for the next release is to have Padre linked in as the default editor for .pl, .pm, and .pod files. This alpha is just to test the modules chosen and to shake things down - and maybe prod a few more CPAN module authors into getting their modules working better on Windows.

There is no release notes page for this build yet - that will come with the next alpha or beta, whatever I decide to call it.

There will be no 5.8.9.x version of Strawberry Perl Professional - It will only come in 5.10.1.x versions for the moment. It's taking me 4 1/2 hours to do one build of Professional, and I just bought this machine in October - anybody want to contribute to a second machine to start a build farm?

To download this version, go to the Strawberry Perl beta page.

I'm calling it an alpha because I KNOW some things do not work, and others may not work well.

In particular, CPANPLUS::Shell::Wx (the graphical CPAN shell linked from the start menu) crashes just after the splash screen starts. You, in particular, have been prodded. :) If you know Wx, send the author patches. (I'm going to start learning it)

* Devel::ebug::Wx [a graphical Perl debugger] would be nice to have, also, but Devel::ebug is not testing correctly at the moment, so I don't trust it enough to include it here. If you want it, apply tuits.

** I may or may not remove one of these before release. Depends on what is wanted and working well.

Die CeBit 2010 präsentiert in Form der Open Source Lounge in Halle 2 auf dem Stand F34 insgesamt 15 Open Source Projekte. Perl wurde als eines dieser Projekte ausgewählt.

Die Perl Foundation zeigt dabei stellvertretend für alle Perl Projekte Padre, Foswiki und OTRS.

Das Linux-Magazin stellt Perl in seiner CeBit – Sonderausgabe kurz vor.

Yesterday a fellow developer had a problem with a well known very big open source project. He tried to get support from that project, but nobody answered. It was one of those tools installed on most Linux servers – but the community wasn’t able to answer simple questions.

The Padre IRC channel window was next to his IM window when he told me and I was thinking about Padre support.

The Padre support channel (called #Padre on irc.perl.org) is open 24/7, and there are about 45 people and one or two bots around, but at least some of them are always alive and ready to answer questions.

There are two facts that gave us this high reachability (I think):

1. Our developers are all around the world

Some Australians are really pushing Padre, including Alias who did 16% of the core code and waxhead, our current release manager. We got some few US guys and a strong European and Middle Eastern group. Most of them are online and usually happy to help users when they’re at their desks.

2. Padre is a working tool

This is true for many open source things, but Padre is something you use everyday and – compared to tools like “less” or “traceroute” – you recognize it. Many people use Padre for working, it’s always visible while it’s being used – compared to Apache or syslogd that are hidden if they’re working probably.

Some people using Padre also open their IRC client or the Mibbit web-based IRC client for joining the Padre support, asking  questions and answering others.

Give us a try

Padre is a complex IDE. If you try it out, you’ll likely have questions or maybe even problems. Feel free to come to our support channel and ask your question. It might take some minutes or even half an hour until someone replies – as many people are busy with work – but I guess you’ll get your answer. And you’re welcome to stay there and spend a minute on answering a question of someone else.

I am using Google Alert to get notifications on blogs news about various subjects. Today I got a link to the archive of the mailing list of the Boston Perl Mongers where they discussed a presentation and demo of Padre.

I am really happy that people talk about the project but there were two questions asked that often come up. Let me address them.

Is Padre better than vi or emacs?

I don't think the Padre developers ever hoped to replace either vi or emacs. Those two have a totally different mind-set than Padre. We hope that Padre will have some advanced features that will make it worth to switch to it once in a while or that those features will be stolen and integrated into vi or emacs as already happened in the past.

We also hope that the vi and emacs user will understand that vi and emacs do not fit the mind-set of many people. Especially beginners, people who are used to live in their IDE and people who live in a mostly Windows world. If they accept this then they will see that Padre is not a competition to their tool-set but complementary tool.

Is Padre better than Eclipse + EPIC?

Short answer: Not yet, but we are getting there.

Long answer: If you are already familiar with Eclipse then probably it will make more sense to use EPIC and stick to those two. If you are not yet familiar then Padre will be a better choice for Perl programming as it is faster and knows more about Perl than EPIC does.

The editing part and the generic feature of Eclipse are still way ahead of Padre but in the Perl specific features Padre is already head to head with EPIC. In some fields it is still behind but in other fields it is already more advanced.

Most importantly, Padre has a much better potential in the Perl world as it is written in Perl so every user can also easily improve it or extend it.

If you are still interested check out Padre, the Perl IDE or just join our community.

Many of the videos recorded on FOSDEM are already online. Including the 15 minutes long "lightning" talk about Padre I gave. There was also the talk of Giuseppe Maxia about blaming the unknown, or a constructive approach to technology which is not a strictly Perl related talk but worth seeing.

There were two other Perl related talks in the distribution mini conference. I hope we'll have the videos available soon.

The slides of the talk are here but apparently they don't work on the latest Firefox so I'll need to fix them.

However a heck of a lot of dependencies were installed though.  A lot of the test modules it seems.

So lets see if we can get Wx installed from here.

Looks to me like we need to resolve the matter of Alien::wxWidgets not being installed for Wx to build.

So lets look at the Alien::wxWidgets build.

In the cpan shell, type look Alien::wxWidgets.

Once at the prompt, like create the make file: perl Makefile.PL.

Then make.

OK, so we now have an error:


checking for GTK+ - version >= 2.0.0... no
*** Could not run GTK+ test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK+ is incorrectly installed.
configure: error:
The development files for GTK+ were not found. For GTK+ 2, please
ensure that pkg-config is in the path and that gtk+-2.0.pc is
installed. For GTK+ 1.2 please check that gtk-config is in the path,
and that the version is 1.2.3 or above. Also check that the
libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config
--libs' are in the LD_LIBRARY_PATH or equivalent.
                           
system: echo exit | sh ../configure --prefix=/usr/local/lib/perl/5.10.0/Alien/wxWidgets/gtk_2_8_10_uni --with-gtk --disable-compat24 --enable-unicode --disable-debug --disable-monolithic --disable-universal_binary : 256 at Build line 60
make: *** [all] Error 2

We're missing the GTK+ development libraries ( and like a few more things, but lets step through this one problem at a time ).

So lets fix this up.

Using synaptic I seach for gtk+, it looks to me like libgtk2.0-dev might be what we need.

Mark this for installation and Apply.  This will take a bit of time to download and install.

Once done go back to the shell and make clean and perl Makefile.PL and then make.

This time a whole lot more seems to happen... finally we can start to see things being built.

Once that's finished:

make test and then when it passes sudo make install and then exit from the shell.

OK, that's Alien::wxWidgets installed... lets see if we can get Wx to finish installing:

at the cpan prompt: install Wx  This fails with an error because it knows it failed to install previously.

So lets get that sorted out:

look Wx

Now perl Makefile.PL

This returns an interesting error:

Note (probably harmless): No library found for -lwx_gtk2u_media-2.8

If it's harmless, lets move on ( to be honest I couldn't find it in synaptic ).

make
make test
sudo make install

So that looks like we now have Wx installed.

Lets start with Padre.

install Padre

Remember to install all required dependencies as it goes through - just keep hitting Enter to answer Yes when asked if you want to follow dependencies.

WOW! So that's it for my install of Padre, after meeting all the depandencies, Padre appears to have installed fine.  The big test is going to be running padre from the command line.

In cpan, q to quite.. and then padre.

And there it is!

While I have to say that installing Padre this way didn't turn out to be overly difficult, it should show you how to address those moments when installing fails when a depandancy isn't met.
 

Read and post comments | Send to a friend

Let it never be said that I am a good release manager.

Padre-Plugin-Swarm-0.091 is making it's way to cpan. Much of the groundwork for some real collaborative editing in now in place, albeit buggy.

Upon enabling the plugin - padre users are able to chat with other padre users in a small panel at the bottom of the editor. In addition to the standard padre Directory/Project file tree in the left panel - swarm adds a resources view allowing other swarmers to see what files you have open and if they choose - open a copy of those.

The 'Run document in other Editor' feature has been disabled temporarily - despite all the disclaimers I believe that feature to be just too evil for use until swarm can distinguish between global and local swarm messages - on the assumption that someone on your local network will be less inclined to do evil things to your editor if the victim is able to walk across the office / domicile and slap the offender soundly across the head.

Much thanks go to Peter Lavender (waxhead) the present Padre release-manager for the most recent live test of the swarm global network transport, and for his kind and encouraging words.

Swarm is now at a stage where the network layer can be abstracted away enough to allow me to get on with the more interesting features detailed in the original swarm charter - namely editor collaboration.

It is my hope that some of the padre developers can be drawn into this vortex and "Surrender to the Swarm!"

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere anarchy is loosed upon the world...
Surely some revelation is at hand;
Surely the Second Coming is at hand.
  —William Yates, The Second Coming

1. Strawberry Perl January 2010.
   
   It's been out for over a week - I really should start writing these release announcements beforehand. This is an "upgrade version" - The only new module is GDBM_File. There are a number of non-user-facing internals changes, however. Things just got too busy over the holidays to do the user-facing changes that were planned.
   
   5.10.1.1 is at: http://strawberry-perl.googlecode.com/files/strawberry-perl-5.10.1.1.msi
   Other releases are mentioned at: http://strawberryperl.com/releases.html
   



2. "Strawberry Perl plus Padre" 0.56.
   
   This is the new version of what has been previously called "Padre Standalone". In this case, it's been updated to the latest versions of both Strawberry Perl and Padre.
   
   http://strawberryperl.com/download/padre/strawberry-plus-padre-0.56.msi http://strawberryperl.com/download/padre/strawberry-plus-padre-0.56.zip
   


3. "Merge Module" for Strawberry Perl.
   
   We're starting to build a merge module that can be used in other Windows Installer packages. The infrastructure to do this was one of the things that got added to Strawberry Perl in this version.
   
   If you're wondering "What is a merge module?" - a merge module is a Windows Installer "sub-package" that can be included in other packages.
   
   More documentation about how to include Strawberry Perl in their own software will be posted within the next few days.

• Relocatability on install


• "Strawberry Professional"


• 64-bit versions


• perl 5.12.x (assuming it gets released soon enough)


• Non-admin installation and support

Why is PHP so much easier for newbies?

Why does Java have the best IDE tools?

Why is Ruby prettier than Perl?

Why does Perl have the best package repository?

As I've played through Mass Effect 2 over the last few weeks, I see some interesting parallels.

In the Mass Effect universe, human technology is bootstrapped by the discovery of an ancient abandoned alien observation outpost on Mars, and the further discovery that the dwarf planet Charon is really an abandoned but active interstellar jump gate covered in ice.

Other similar species have done the same, resulting in a galactic community of around a dozen civilisations all based around the same basic technological underpinnings.

Despite these civilisations believing a recently (50,000 years) extinct civilisation built the gates, it turns out the technology is perhaps millions of years old.

Every 50,000 years, the synthetic AI race that built them returns from hiding in intergalactic space to wipe out all of the existing advanced species based on "their" technology, and reset the galaxy for the next set of civilisations to rise.

In a conversation between the game's protagonist and one of these old AIs, we are lambasted by the AI for taking the shortcut on their technology. The jump gates and other technology is left in place intentionally, so that each new generation of civilisations take a controlled and predictable development path, making it easier to destroy them.

The AI posits that it is the overcoming of adversity on your own that drives true technological advancement, and that easy routes make you (technologically) weak.

I think you can see something similar in the development of the different programming languages.

Java is long and wordy, taking a long time to type. The need to work around this limitation resulted in the proliferation of powerful IDEs, resulting in the annual 20 million line of code Eclipse release train.

PHP as a web language would have been stillborn if it didn't deal competently and quickly with the need to easily deploy code, the result of which is that you can effortlessly just change .html to .php, add a hello world tag, and upload via FTP as normal (something Perl still can't do well).

Python's need to gain mindshare against an entrenched Perl led to a huge focus on being easy to learn, to a simplification of the language, and to hugely popular things such as the PyGame library and game competitions.

Faced with the lack of truly great package repository, and with a web-heavy community, Ruby became the "prettiest" language. Creating an elegant website is both expected and required if you are going to gain mindshare for an idea.

And Perl's messy syntax and difficulties in the area of maintaining large codebases, combined with a pragmatic sysadmin-heavy community, resulted in an unmatched packaging system that allowed code to be maintained in small pieces, with enormous volumes of support infrastructure around it.

The ease of publishing and trend to smaller package that the CPAN allowed conversely means that the Perl community has never really had the need for pretty and elaborate websites, and the smaller package size means that we lack the giant headline libraries that make the payoff from website work better.

Our bias towards a pragmatic tech-savvy sysadmin userbase means we haven't really provided anything like the focus on learnability that has driven Python's gradual dominance in the mindshare of the young. It takes a certain rigour in your prioritisation to intentionally remove and dumb down existing powerful features so that the language is easier to learn.

Even for Strawberry, which focuses on the userbase with the lowest traditional knowledge, we intentionally have the smallest and most maintainable website possible and we don't even have the kind of introductory screencasts that we really really need (which should be easy but which I never seem to find the time to do).

If you throw a bunch of Perl coders against some PHP coders in a website competition, it is not unexpected that when both sides play to their strengths you will see something like http://geo2gov.com.au/html?location=e.g.+1+Oxford+Street from the Perl coders and something like http://www.hackdays.com/knowwhereyoulive/postcodes/view/2000 from the PHP coders.

The former required a massive amount of data extraction, transformation, aggregation, a gigabyte-sized PostGIS database, and deployment via a Linux virtual appliance to Amazon EC2 to allow for strategic load-shedding.

The latter required the ability to turn data into presentable and understandable information for real humans, and to make it pretty enough that they WANT to look at it.

Driving true technological progress, then, may often be about identifying weaknesses that are hard to solve but aren't completely impossible (and don't have any crippling long-term conceptual flaws at an economic or project-management level).

The three best projects I have driven - PPI, Strawberry, and (in part) Padre - all share this property. All three of these represent hard but not impossible problems, and require an awareness about which issues are intractable and which issues merely exist because there's been no need to solve them any better.

Padre in particular has suffered greatly from issues with Wx quality and threading. But given the low takeup of both threading and Wx it was reasonable to move forward on the basis that these would be fixed once there was something depending on them, and driving a need to fix them.

All of our early problems are gone now, and there is continued pressure to find ways to improve our use of (and the efficiency of) Perl's native ithreads.

Similarly, the creation of Strawberry required a lengthy year-long process of fixing Win32 bugs in all kinds of toolchain and low level modules, because we'd never had a proper working developer feedback loop before.

Similarly, Perl's current push for marketing and blogging and websites is directly resulting from Python's success in mindshare capture.

So my question for you to ponder this week is the following:

What can you see that Perl as a whole struggles to do well, for which a good solution is not impossible, and is only being held back by smaller problems which would go away if there was a working candidate solution put in place that needed those small problem solved.

The experimental plugin for collaborative editing in Padre is making it's way to cpan. Padre-Plugin-Swarm-0.07 no longer depends on IO::Interface and should be installable in a very recent Padre like 0.56.

Features

• no-config networking
• chat console
• see other users list of open files
• steal other users files
• open your files in other editors
• run your files in other editors!
• ... other remote execution bugs and more

Screenshot http://padre.perlide.org/trac/attachment/wiki/Screenshots/Screenshot-Padre-Plugi n-Swarm-0.07.png

Nach einigen Verzögerungen ist Padre 0.56 endlich da!

Peter (waxhead), der Release-Manager schreibt dazu ausführlich in seinem Blog. Die Liste der Änderungen dieser Version ist so umfangreich geworden wie schon lange nicht mehr.

Die meisten Änderungen dieser Version kommen von Adam Kennedy und Ahmad M. Zawawi, aber wir konnten auch wieder einige Neuzugänge im Padre-Entwickerteam verzeichnen, die mehr oder weniger kleine Änderungen beigetragen haben.

Wie immer ist Padre über CPAN oder via http://padre.perlide.org/download.html kostenlos verfügbar.

In the spirit of trying to jam as many speed hacks into Padre as possible, I've finally taken it upon myself to take the awesome work demonstrated in ORLite::Array (which uses ARRAY based objects instead of HASH based objects) and moved it into the ORLite core.

The removal of the need for a hash slice in DBI doubles the speed of SELECT statements, reduces the memory cost of objects, and makes accessors quicker.

I've also integrated support for Class::XSAccessor, so now not only are they faster ARRAY objects (if you want them) the accessors are all XS-accelerated as well.

As a bonus to this I've altered the ORLite::Mirror sub-class to always use ARRAY-based objects by default, which means that all of the ORDB family of modules just instantly got doubled in speed without me needing to do any new releases.

So all up, Padre 0.56 is looking awesome.

To quote one person in the #padre channel, "padre is so fast to start now that the splashscreen is an irritation"

Now that the new resource locking system has been landed for a couple of weeks and some of our worst performance bugs have been resolved, we've been able to uncover and fix a ton of routine performance problems.

Padre 0.55 landed the first pass of these, but the upcoming Padre 0.56 is looking to be incredibly fast and has ditched much of the weight that you expect from an IDE. It's actually starting to feel light like an editor again, instead of heavy like an IDE.

Amoungst the improvements, we have a new tricksy startup mechanism that can apply startup preferences without having to load the user's config file at all (or any of the accompanying weight).

The startup process has become so fast that we're seriously considering ditching the splash screen (because it slows down the startup too much) and open files in an existing Padre has become nearly instantaneous.

Opening files is at least twice as fast thanks to an encoding detection shortcut for simple ascii files. Changing tabs is 5+ times faster due to removal of some filesystem operations and refresh locking. Closing a file is at least twice as fast, and 3-4 times faster if you choose to use the new feature preference to disable Padre's remembering of cursor locations in files.

Closing groups of files "Close This Project" and "Close Other Projects" etc has gained locking and now works incredibly quickly. With the cursor memory off the time between clicking close and the Padre window vanishing is almost instantaneous now.

Finally, we've also added a number of new refresh shortcutting to different tools and widgets, which makes Padre in general much snappier when moving around inside the same project or just doing operations that trigger off refresh cascades within the same file.

The sum total of all these improvements is that Padre feels almost like a whole new editor. It's fresh, snappy, and generally a joy to use.

And even more fancy improvements are in the pipeline. Mattias and Steffen between them have spawned a special new "slave master" threading branch which is already able to save 4-5meg of RAM per background thread by spawning of a master thread very early in the Wx startup process, while our list of loaded modules is very small. As a bonus, because it doesn't have to fork the entire Wx application tree, the slave master branch also fixes the long-time "Leaked Scalar" bug.

0.56 is definitely shaping up as something special and when it comes out I highly commend it to everyone to take a look, especially if you haven't had a look at Padre in the last 10 or so releases.

Ricardo Signes (RJBS) has just announced the release of perl 5.11.4, the latest development version on the way to perl 5.12. Of much less significance but the Padre team has also released version 0.55 of Padre, you know, the Perl IDE. You can read about it in the announcement of Peter Lavender.

In order to make it easier for people to try those I built a new experimental version of the Stand Alone Padre for Linux.

It contains

• perl 5.11.4
• Padre 0.55
• Padre::Plugin::PerlTidy
• Padre::Plugin::PerlCritic
• Padre::Plugin::Plack

During the build I encountered only one issue. A line in Pod::POM generates a warning about defined %hash being deprecated. As Parse::ErrorString::Perl, one of the dependencies of Padre is checking for errors using Test::NoWarnings, this module now fails to build. I had to manually patch Pod::POM in order to allow the installation of Parse::ErrorString::Perl.

In addition two major plugins of Padre failed to install:

Padre::Plugin::Perl6 has a deep dependency on YAML::LibYAML which fails and Padre::Plugin::Catalyst depends on Devel::Caller which currently fails on perl 5.11.4.

If you'd like to try it download perl-5.11.4-xl-0.03.tar.bz2 (29,804,273 bytes). Unzip it using

  tar xjf perl-5.11.4-xl-0.03.tar.bz2

and run the padre.sh:

  ./perl-5.11.4-xl-0.03/perl/bin/padre.sh

Enjoy and report any issues!

Yesterday someone called me for whom I did some work 7 years ago that he is now at a new company and need some quick Perl script written. A 2 days long work. As I was just heading home from a conference and I was close to their office we decided I go over so we can talk about it.

They have a system that provides its results in a CSV file but they have a client that needed the result in an XML file with some extra processing.

So the project involved processing a CSV file and based on a small XML configuration file the script was supposed to generate an XML output file.

As the system of the client runs on Windows this had to work there.

After looking at the actual project we decided I'll start to work on it immediately at their offices.

They put me in front of a Windows machine. I downloaded and installed the Stand Alone Padre editor and had almost everything I needed. As it has a version of Strawberry Perl for Windows underneath it already had XML::LibXML for XML processing.

I tried to use it in order to process the configuration file but I have never used that module and I felt it would be faster to install and use XML::Simple for reading the small configuration file. The already configured cpan client allowed me to type

   c:> cpan XML::Simple

and after a few seconds I already had the module. When I got to the point of processing the CSV file I probably could get away with a simple split() statement on every row but I did not want to take the risk of having a field with quotation marks and a comma inside a value breaking the code. So I opted for [dits://Text::CSV_XS]. I had to install it but it was easy:

  c:> cpan Text::CSV_XS

After about 5 hours total work including the initial discussion and finding a computer for me that took about 2 hours I was done with the script.

Then comes the hard part.

The actual production system does not have access to the Internet so one cannot simply use the cpan client. They could use a VPN to copy files to the machine just could not let the cpan client fetch the modules.

Luckily the solution was not difficult. I told them to copy Strawberry Perl to the system and the source code version (.tag.gz files) of the two modules to the production machine. After installing Strawberry Perl they could use

  c:> pip Text-CSV_XS-0.70.tgz

to install the module.

Of course I was lucky as there were only two extra modules I needed and neither of them had dependencies that Strawberry did not have. In a more complex case I might need several other modules and as the person who will install this on the target system does not know any Perl s/he will only feel it as an unnecessary complex installation.

Solutions

A

It would be nice if there was a simple way to build a package from this. That could be the planned Strawberry Perl Professional that will include many other CPAN modules reducing the chance that I'll need extra modules.

B

It could be a way to build the MSI installer based on a released version of Strawberry Perl and several modules from CPAN. This should be very easy that does not need any extra things beyond Strawberry Perl and the specific extra modules.

C

It could be taking the Strawberry Perl MSI package and the source versions of the required extra modules and zipping them together. On the target system the sysadmin could

1. unzip the file
2. install Strawberry using the .MSI package
3. Run a script that will install the extra modules that were supplied with the package

The last item needs some thinking so the script will either make sure that the dependencies are installed first or will let the user configure the local directory holding the extra files as the cpan server where pip needs to look for dependencies.

Thinking about this, this might be built by using CPAN::Mini we just need to configure the cpan client to look there first.

FOSDEM will take place in less than a month and the Perl stand is still waiting to be filled with interesting projects. I'am going to be at FOSDEM and I am going to give two talks. One of is 15 minute long lightning talk about Padre, the Perl IDE under the title Building an open source team, getting the project to users against the odds.

The other one is going to be in the distribution mini-conference about CPAN, packaging on CPAN and how CPAN authors and downstream packagers of the distributions (e.g. Debian, Ubuntu, Mandriva, Fedora, SuSE, etc...) can interact better. For this second talk I have 45 minutes.

So when people will come to the Perl stand Padre will be represented quite well. What about your project? Will you come to FOSDEM to show it? Is there anyone in your project who might be coming and could show it?

Even if none of the project members will come, the people who are going to be at the Perl stand will be able to show your project if you help us prepare the material. You don't have much time though as I am going to be off-line the last week of January so basically you have 10 days now to get the initial material ready.

What we will need is a tool we can use to demonstrate your project on our notebooks. We will need and easy way to install it - maybe its own live CD, maybe adding it to the live DVD Thomas Fahle created.

Remember there are going to be some 3-4000 people attending FOSDEM, but thet are not Perl programmers. I am not sure what exactly to expect. I am sure people will ask questions about Perl 6 and they will want to know if Perl can be used to create web applications. So the material should be ineteresting enough for them to look at your project or to look at Perl and try to get them start to use it.

So, if you'd like some publicity to you project. Start talking to me now about it!