Padre blogs

Making threads suck less in Padre

2010-03-12T05:26:21+00:00

Yes, threads suck. And in several different ways. Slow, memory-bloating, etc etc etc.

However, threads work.

Installing them from the CPAN on Windows, Mac and Linux works.

Using them as they are intended to be used works on Windows, Mac and Linux.

Integration with Wx works on Windows, Mac and Linux.

And using them to saturate a 4 CPU core development machine works, without resorting to having both them AND external processes.

And they work well enough that nobody has yet had an itch strong enough to step up and replace our task management code with something else that can support more than one CPU (and since our task system is derived from Process.pm, it is specifically designed to make it easy to use alternative backends).

So threads work, but they suck. Or at least, interpreter-copy sucks.

And in an IDE scenario where your process needs to load 50-100 meg of code just to drive the cooler IDE functions they suck even harder.

Fortunately, Padre has a rather forgiving attitude to things sucking.

We would rather have someone commit something that works and sucks, than not have it committed at all. And Padre is full of all kinds of features that work but suck. And slowly, gradually, they suck less.

The most recent couple of releases have come with stability warnings due to the arrival of our second-generation "Slave Driver" threading model.

The Slave Driver mechanism attempts to specifically contain and reduce the problems associated with threads.

During startup, we load the minimum number of modules required to conduct communication across threads, and then immediately spawn off a master thread which will remain unused while our main thread continues onward and loads up as much code as it likes.

Later on, when we need to do background work, this master thread is then further cloned into a slave thread which will bloat out incrementally, loading only the code it needs to execute the task.

While the slave driver mechanism itself landed a few weeks ago, the final step of pushing the master spawn point up into the start-up code just landed today.

The result of this is a change in our per-thread cost from 34meg per thread to about 20meg per thread (for a total reduction in memory in a low-usage case from 90meg to 60meg).

If not for the fact that loading Wx is an all or nothing proposition, we could probably cut this in half again. And while a collection of half a dozen 35meg threads (about the maximum we are likely to need to saturate 4 CPU cores) in a thread pool is a nasty amount of RAM, even for an IDE, half a dozen 10meg threads is a lot closer to a tolerable memory cost.

And if we can drop this further to around 5 meg, we get close to the memory cost of a forking/process model, which is the only other parallelism model available in the short term that supports many cores transparently.

Padre 0.58 - It's still a case of careful as you go.....

2010-03-08T09:40:10+00:00

Padre 0.58 has just hit CPAN. Please note it comes with the same warnings and caveats that 0.57 came with; that is we still have a few issues to resolve with the threading changes we saw merged in after 0.56.

To this end we do recommend that distribution package maintainers and anyone else supporting Padre in other formats consider that 0.56 is still where things remain "stable". So again, this release is not for broad public consumption.

However, in saying that, the problems we are seeing are already logged in trac as ticket #866: http://padre.perlide.org/trac/ticket/866.

This ticket has been assigned to Adam Kennedy to sort out. So it's going to linger until such time that Adam gets time to work things out, or we see Steffen back to provide some assistance.

The main issue we are seeing at the moment though isn't a show stopper for those who wish to use live on the bleeding edge. For many of us, we use trunk daily and haven't had a major catastrophe. But to be fair to all, we make sure until we are certain that all the major issues post the threading changes merged in before 0.57 we are aware of are addressed, we'll make it clear to tread with care.

So with a few lingering nits with Padre, why release 0.58?

Well, simply put, development isn't going to stop, and continues along at a fair crack, so for those brave enough to tread where dragons may lie ( http://en.wikipedia.org/wiki/Here_be_dragons ) 0.58 brings with it a number of improvements and fixes:

Translations

In this release we saw Turkish added to Padre by Burak Gürsoy.

New

While not much new has made of it in the Changes this release, there is a fair bit of work being done by Ahmed Zawawi on the key bindings. You can see the work in progress with this release under Tools/Key Bindings. The dialog has a warning in the title that it is still a work in progress.

Such is the nature of Release Early Release Often.

Fixes

What's a software project with out bugs?

One that isn't written.

It's always great to see a new name pop up in the Changes File, this release we see a fix submitted for ticket #835 by Karl Forner.

- Fixed ticket #835: Function list not populated on initial panel showing
(karl.forner)

Our prodigious fixer and hacker on new things Ahmed Zawawi ( http://ahmadzawawi.blogspot.com/ ) has again done outstanding work this release cycle:

    - Fixed ticket #867: Padre dies when hitting Ctrl-. (AZAWAWI)
    - Fixed ticket #807: F2 is broken (AZAWAWI)
    - Bumped Wx::Perl::ProcessStream version requirement to 0.25 (AZAWAWI)
    - Fixed ticket #860: Configurable key bindings dialog (AZAWAWI)
    - Warning editor markers are now actually orange on win32 (AZAWAWI)
    - In advanced preferences, display the storage backend name when it is
      default and 'User' is now called 'Overriden' (AZAWAWI)
    - In advanced preferences, display preferences options for non-boolean
      settings (AZAWAWI)
    - In advanced preferences, display a True/False radio button for boolean
      settings (AZAWAWI)
    - Fixed an incorrect default value display bug in advanced preferences
      when it is toggled (AZAWAWI)
    - In advanced preferences, hide bottom controls at startup (AZAWAWI)
    - In advanced preferences, Set button is hidden when it is a boolean.
      True/false radio buttons handle the switch instead (AZAWAWI)
    - Fixed ticket #858 Recent files does not display anything on Padre startup
      (AZAWAWI)
    - Refresh all menus at startup. This prevents "nothing" open mode (i.e. no
      document) from incorrectly showing an enabled menubar (AZAWAWI)

While working on SDL (http://search.cpan.org/~kthakore/) Kartik Thakore ( http://yapgh.blogspot.com ) found time to chase down a bug and submit an RT ticket against Wx::Perl::ProcessStream and get in a fix for Padre:

- Fixed ticket #863: Continous warnings or prints kill Padre
(AZAWAWI, KTHAKORE)

It should be noted here that Mark Dootson ( http://search.cpan.org/~mdootson/ ) chipped in and responded to the RT ticket raised by KTHAKORE regarding this issue and cut a release to CPAN in amazing time. Mark then hung out in #parde for a while. Thanks Mark!

And just to show that the double teaming goes on, and that you don't have to work alone with adding to or fixing bugs in Padre, Adam Kennedy made the promised changes for Ahmed:

- Added promised PPI lexer configurable max-length limit for azawawi (ADAMK)

Adam also appears to have been a co-contributor with Sebastain Willing on changes to the status bar:

- Speed up status bar updates (ADAMK, SEWI)

Adam continued to find speed improvements within Padre:

    - Removed the unused concept of user-configurable menus, which was slowing
      down a ton of different operations that needed a menu refresh (ADAMK)
    - Removed ->refresh calls during the initial menu construction, as we
      will be refresh'ing again anyway at the end of the startup, and thus
      any work done in the menus is completely wasted CPU (ADAMK)
    - Removed the very expensive window list refresh code from the main menu
      refresh method into it's own dedicated refresh method. We can fire
      this directly in the limited number of situations that the notebook
      adds, removed, or renamed documents (ADAMK)
    - Landed new and much much faster refresh_windowlist (ADAMK)

Gabor (http://szabgab.com/) found some time between FOSDEM ( http://szabgab.com/blog/2010/02/1266258560.html ) and Cebit ( http://szabgab.com/blog/2010/03/1267974609.html ) to add in some plumbing:

- Padre::Util::share() can now get the name of a plugin (e.g. 'Perl6') and
return the share directory of that plugin (SZABGAB)

Patrick Donelan ( http://blog.patspam.com/ ) added his time to the project:

- Fixed "Open File In Existing Padre" for non-win32 (PDONELAN)

And lastly, I managed to sneak in with a minor addition to the preferences Dialog by adding in two missing "Browse" buttons:

- Added Browse Buttons to External Tools Preference Dialog (PLAVEN)

The complete list of Changes for Padre for this release can be found here: http://svn.perlide.org/padre/tags/Padre-0.58/Changes

As always, we can be found in #padre on perl.irc.org. If you have any questions or want to report a bug drop by and let us know. We'll set you up with a trac account and have you improving Padre in no time!

Read and post comments | Send to a friend

Perl::Staff 0.02

2010-03-07T21:50:58+00:00

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

Things I showed to people not knowing Perl but PHP

2010-03-07T16:51:16+00:00

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.

CeBit 2010 is over

2010-03-07T16:27:33+00:00

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…

CeBit und die Illusionen…

2010-03-05T22:55:25+00:00

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.

CeBit 2010: Es kann losgehen

2010-03-02T06:28:56+00:00

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.

Help learning and writing CSS - is there a parsable version of the documentation?

2010-02-22T11:57:23+00:00

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.

Fosdem 2010 Impressions

2010-02-19T19:19:36+00:00

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

Filed under: Misc, Perl Tagged: fosdem, Padre, Perl, photography

Strawberry Perl Professional Alpha 1 announcement.

2010-02-19T01:38:52+00:00

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:

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.)

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

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

Moose and a number of MooseX modules.

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

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

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

... 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.

Padre 0.57 - Bleeding Edge Stuff!

2010-02-18T12:44:56+00:00

Padre's release cycle is somewhere around 2 weeks at the moment. This is a good thing when it comes to getting fixes out for annoying bugs that slip in, or to get your hands on the next incremental improvement.

However, sometimes you have to put out a release that tests more broadly than those game enough to run trunk all the time, some major changes.

0.57 is the first release after the big merge of the new threading code from Steffen's branch which sees improvement to the threading, fixes the classic Scalars Leaked warning, and reduces memory consumption.

Much of the problematic code was thrashed out between both Steffen and Andrew before the merge was done, leaving us with a trunk that for all intents and purposes is completely usable. This has meant a lot of us are running trunk with out major issues and as a bonus has seen on going improvements to the UI and usability in general.

But we do want to make it clear, this release while fine to use, should not be considered a platinum release, maybe bronze!

So for the package maintainers feel free to skip this release, for the brave of soul, please do go ahead and try out Padre 0.57 and report any bugs or problems you see with this release on trac: http://padre.perlide.org/trac/ or jump into #padre at perl.irc.org.

That's the big news. So what are you missing out on if you don't upgrade to 0.57 and wait patiently for in 0.58?

Improvements to the Regex Editor
GotoLine has been improved to and renamed to just Goto - either a line number or position
Project improvements
Mimetype detection for Template::Tool Kit and CSS
Changes to Padre's menu; Plugins has been renamed to Tools
The Preferences dialog has been moved from Edit to Tools
mozilla-style about:config

and of course the improvements to the threading code at startup.

The Exhaustive list of changes follows:

Threading Changes:

    - Spawn a master thread very early in the startup process. Use that
      master to create worker threads as necessary. Cuts down on memory
      usage and fixes the "Leaked Scalars" warning (BRAMBLE, SMUELLER)

Regex Editor:

    - Regex editor dialog is now more compact and it includes regex helper
      buttons (AZAWAWI)
    - Regex editor dialog can now highlight matched text (AZAWAWI)
    - Regex editor dialog can now display regex description (AZAWAWI)
    - Implemented Replace (aka substitution) in Regex editor (AZAWAWI)
    - Right click "Edit with Regex Editor" now works on user-selected
      text (AZAWAWI)

Goto Improvements:

    - GotoLine is now called Goto dialog (AZAWAWI)
    - Goto dialog is now non-modal lazy single instance dialog (AZAWAWI)
    - Goto dialog has a current positon/line number field (AZAWAWI)

Project Improvements:

    - Added "headline" method to Padre::Project, which allows a project
      to try and intuit the "primary" file in the project (for a CPAN
      distribution of Foo::Bar this will be lib/Foo/Bar.pm) (ADAMK)

Mimetype detection:

- Add mimetype detection for Template::Toolkit and CSS files (SEWI)

Mozilla-style about:config:

- Fixed ticket #847: "Implement Mozilla-style about:config for Padre"
(AZAWAWI)

Select some files to open/reload:

- Select some files to close (SEWI)
- Select some files to reload (SEWI)

Padre Menu changes:

- Renamed Plugins menus to Tools and moved Preferences into it (ADAMK)

Additional Fixes and Improvements:

    - Fix pluginmanager error dialog for plugin-event failure (BRAMBLE)
    - Add status messages for Padre::File operations (SEWI)
    - Removed the final usage of the "Provider" phrasing, and made more
      of the modules used by the Perl help provider run-time loaded (ADAMK)
    - Moved padre.exe build from bin to win32-loader folder since bin is a
      bad path for putting the Padre win32 launcher code (SMUELLER, AZAWAWI)
    - Added "Open in File Browser" in the File and right-click menu (AZAWAWI)
    - Added "Find in Files" to right-click menu (AZAWAWI)
    - No need to launch a command shell to execute explorer.exe on
      win32 (AZAWAWI)
    - Added "Open with Default System Editor" in "File -> Open..." (AZAWAWI)
    - Implemented padre --reset to flush and reset the current Padre
      configuration in otherwise unrecoverable situations, such as now
      when the Swarm plugin causes the slave-driver code to instantly
      segfault at startup (ADAMK)
    - Added plugin menu refreshing to the resource locking system (ADAMK)
    - Fixed three cases where code was still manually calling ->Freeze
      and ->Thaw on the main window, breaking the resource locked (ADAMK)
    - Fixed ticket #845: Fix relative filenames from commandline (SEWI)
    - Added "Open In Command Line" to File menu (AZAWAWI)
    - Re-implemented the mechanism for generating a human-oriented list of
      window names (ADAMK)

Read and post comments | Send to a friend

Padre auf der CeBit 2010

2010-02-17T09:03:51+00:00

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.

24/7 commercial quality support – for an open source project

2010-02-17T07:34:16+00:00

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.

Is Padre really better than vi, emacs or Eclipse + EPIC?

2010-02-15T10:59:44+00:00

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.

Video of the Padre talk on FOSDEM

2010-02-15T10:29:20+00:00

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.

Installing Padre on Ubuntu from CPAN

2010-02-14T04:26:33+00:00

Padre being a Perl IDE written in Perl does what all good Perl programs do, it uses modules from CPAN... A lot of modules from CPAN. This can make it difficult to install if you don't use one of the "pre-built" versions of Padre.

First of all you will need to make sure that you have all the required parts to compile C and C++ programs on your system.

For Ubuntu I opened syntaptic and installed:

build-essentials

This is the debian package that is required to be installed to build debian packages, it will install all of the essential build and compile programs.

Configure cpan

So to start with I'm going to setup cpan to make it sudo before running make or Build.

o conf mbuild_install_build_command 'sudo ./Build'
o conf conf make_install_make_command 'sudo make'

Followed by

o conf commit

to save the configuration changes.

I also changed the urllist to point to my 'local' mirror.

After making these changes, I install the missing YAML module. It seems to make sense to install this module since cpan will use it.

So now to we move onto the actual Padre install through cpan.

I'm going to note down here what I install in the order it's done. I'm only going to do it this way because it makes sense to me...

OK, Padre being a GUI application requires a GUI framework, we know that it uses Wx, so lets find and install Wx and then Alien::wxWidgets. Hopefully we have our build environment setup and things should work.

install Wx

You will get told that a number of dependancies are required to be met, answer yes to these. It turns out Alien::wxWidgets is a dependancy for Wx so it will be installed.

That didn't work:

====================================================================== Alien::wxWidgets is missing, you will need to re-run Makefile.PL after it is installed. ======================================================================

======================================================================
For installation instructions and further help please see
docs/INSTALL.pod

For command line switches help use:
perl Makefile.PL --help
======================================================================

==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
make: *** [Makefile] Error 1
MBARBON/Wx-0.9701.tar.gz
/usr/bin/make -- NOT OK
Running make test
Can't test without successful make
Running make install
Make had returned bad status, install seems impossible
Failed during this command:
MBARBON/Alien-wxWidgets-0.50.tar.gz : make NO
MBARBON/Wx-0.9701.tar.gz : make NO

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

Padre Swarm plugin releases in anger

2010-02-12T14:22:29+00:00

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!"

Upcoming features in Padre

2010-02-11T13:18:09+00:00

As our busy Curtis Jewell released Strawberry Plus Padre 0.56 yesterday, Padre developers were already actively working on the next Padre version. Here are some screenshots on what is going on with the upcoming Padre development release. This is of-course NOT a final list of what is going to be released in the next release. Here is a list of the latest Changes.

Regular expression (regex) editor

The complete Regex editor dialog UI is now revamped. It supports substitution now. It tries to describe the regex that you typed via PPIx::Regexp. You can now open it from the "Edit" menu or from the right-click menu when you have selected some text. The dialog is now non-modal.

Enhanced goto dialog

Goto dialog is now more generic and supports position and line numbers. It also displays the current position or line number depending on its operation mode. The dialog is now non-modal.

Open in file browser / system editor

This is one of the things that I really missed when developing on Padre. It already had an open in file browser (or Open containing folder) feature but that was hidden in the project directory tree. You can now access that from the File / Open menu or from the right-click menu. "Open with default system editor" tries to open the current document using the system's default system editor.

Problem with Strawberry + Padre 0.56

2010-02-10T01:29:57+00:00

I included a development version of the wxWidgets libraries in the Strawberry+Padre builds, and it turns out that the development version causes Padre to crash upon exit.

Here's what to do about it, until Padre 0.57 is released and a new build is created:


rem These 2 lines delete the old version, just to be safe.
del /F c:\strawberry\perl\vendor\lib\Alien\wxWidgets.pm
del /F /S c:\strawberry\perl\vendor\lib\Alien\wxWidgets\*.*

rem The next command should all be on one line, 
rem and will install the fixed libraries.
perl -MPAR::Dist -e"install_par q(http://www.strawberryperl.com/download/padre/Alien-wxWidgets-0.50-MSWin32-x86-multi-thread-5.10.1.par)"

rem This rebuilds the Wx perl connector. 
cpan -f Wx

(The .par file has now been updated to use wxWidgets 2.8.10 instead of the 2.9.0 that was used.)

Release Announcements.

2010-02-09T13:31:53+00:00

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

I've got 3 release announcements to do:

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

"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

"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.

Plans for April:

Relocatability on install

"Strawberry Professional"

64-bit versions

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

Non-admin installation and support

Why Ruby is prettier and Padre changes the Perl community

2010-02-09T02:13:57+00:00

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.

Stable Padre 0.56 is out!

2010-02-07T19:49:36+00:00

Peter Lavender (the great Padre release manager) has just released Padre 0.56 to the public. Great job everyone!

To install Padre,

cpan Padre

To upgrade an existing Padre installation,

perl -MCPAN -e "CPAN->upgrade('/^Padre/')"

Padre, Firefox and Chrome

2010-02-07T19:49:26+00:00

Lately there have been a discussion in #padre about integrating Padre with "Edit with Emacs" Chrome extension. We found out that we need to implement a server that services XmlHttp requests at port 9292 in Padre to be able to integrate with that extension. It was a very interesting discussion that led me to do more research on the topic. I learned that there are Firefox add-ons that can edit text field or areas, launch your favorite editor; i.e. Padre :) and then monitor files for changes and reflect those changes in the browser. So here are some popular examples of such add-ons for Firefox:

Firebug Add-on

Website: http://www.getfirebug.com

Firebug adds a simple edit-the-contents-with-your-editor feature. It turned out that you could easily configure Padre with Firebug. In fact you can configure one or more editors:

It is All Text! Add-on

Website: https://addons.mozilla.org/en-US/firefox/addon/4125

This plugin unfortunately supports only one editor but it can actually reflect saved changes from Padre by monitoring opened files.

Future plans

In the future I plan to create a Padre plugin that services "Edit with Emacs" Chrome extension. Please let me know if there are any browser add-ons/extensions of which I may have missed.

Padre 0.56 the Missing Release Announcement

2010-02-07T10:17:38+00:00

Padre 0.56 was a significant release in recent Padre releases. It bought with it a raft of changes in one of the busiest development cycles I've seen a long time.

So what does Padre 0.56 bring with it?

Speed, stability and continued improvement of Perl IDE goodness.

If you have a Padre that hasn't been updated to 0.56 here's what you're missing:

Speed Improvements

As seen in my 0.56 release announcement Adam Kennedy has been working steadily over the last few releases working into the subsystem a new locking mechanism for Padre. His detailed explanation of this can be found here: http://use.perl.org/~Alias/journal/40049.

Release 0.56 sees the culmination of all this work really showing through.

Speed improvements:

    - During DB locks (which are the most likely place for things to make
      changes to the database) disable synchronous SQLite writes. This will
      reduce the time that Padre blocks, at the risk of config.db corruption
      if there is a hardware failure or operating system crash. (ADAMK)
    - Tuned the locking for ->close_where, which should make a variety of
      functions like "Close This Project" and "Close Other Projects"
      noticably faster (ADAMK)
    - Landed new Padre::Startup module which is dramatically faster
      when loading files into an existing Padre via the single instance
      server, and finally provides a mechanism for allowing configuration
      to disable the startup splash image (ADAMK)
    - Bumped ORLite to 1.38 to get faster ARRAY object support and
      Class::XSAccessor acceleration support. If they cause problems,
      these changes can be safely backed out. (ADAMK)
    - Added a fast ascii shortcut to the very slow encode detector. Opening
      files all of a sudden gets much faster if you have ascii files (ADAMK)
    - Fixed the mass-error-popups on mimetypes without help provider (SEWI)
    - Project detection differentiates between four different subclasses
      of Perl build systems (three of those correctly) (ADAMK)

This could be thought of as a fix however, we can't have Adam being the only one contributing to speed improvements Sebastian fixed an issue with the autocomplete and tabbing:

    - Speedup and less false-shows for autocomplete (SEWI)
    - Speedup while changing tabs (use the correct project dir) (SEWI)

Fixes!!

Ahmad ( who seems to show a bit of a flair for design too! ) really pulled out all stops and contributed a raft of fixes to Padre:

    - WIN32, Converted the --desktop registry code to Win32::TieRegistry
      and removed hardcoded strawberry paths (AZAWAWI)
    - WIN32, padre.exe will run with the same UAC privileges as same as
      the invoker (AZAWAWI)
    - Disable debugger menu items when there is no document (AZAWAWI)
    - Fixed a Padre debugger crash when an unsaved document is debugged (AZAWAWI)
    - Fixed Padre no-document crash with Find Next/Find Previous functionality
      (AZAWAWI)
    - Make sure that windows context key shows the refactor menu
      items in the right-click pop-up menu (AZAWAWI)
    - Used Module::CoreList::is_deprecated to display deprecated CORE modules
      in help search title (AZAWAWI)
    - "Goto Line" dialog now supports going to lines and positions (AZAWAWI)
    - Fixed perl to refactor action prefix for refactor menu for
      consistency (AZAWAWI)
    - Fixed ticket #841: Quick Menu Access should show the location of the
      menu item on the menu system (AZAWAWI)
    - Fixed ticket #837: padre.exe should be able to be placed in
      c:\strawberry\perl\site\bin (AZAWAWI)
    - Improved "Goto Line" dialog to be smarter with better validation/error
      messages (AZAWAWI)
    - Open Resource can now display Perl package names for matching resources
      (AZAWAWI)
    - Fixed #838: Author tests should all check RELEASE_TESTING and/or
      AUTOMATED_TESTING (RHEBUS, AZAWAWI)
    - Fixed Regex Editor dialog destruction bug where multiple ->Show and
      ->Destroy could lead to a Padre crash on WIN32 (AZAWAWI)
    - Fixed ticket #822: main window could be off screen on start (BLAKEW)
    - Simple refocus on document after command run (KTHAKORE)
    - Uses correct make from Config.pm for the run menu item -> Build and
      run tests (KTHAKORE)
    - Padre::Util::Win32::ExecuteProcessAndWait doesn't automatically inherit
      the same Cwd as the parent process. Added support for explicit cwd
      parameter and make the syntax checker pass the cwd to it. Syntax checking
      of test scripts and such should now work as intended on Win32(ADAMK)
    - Audit uses of Padre::Util::Win32 to only load it via require. Added a
      TRACE warning to verify it never gets loaded on non-Win32 (ADAMK)

Improvements, Additions and Changes:

These changes bring with them not just a fix, but improvements to Padre, be they GUI elements or adding additional functionality:

    - Plugins may now add their GUI elements to the view menu (SEWI)
    - Padre now displays a dynamic to-do list generated from comments
      in your source code (CORION)
    - Changed a few configuration settings to create a more consistent
      naming pattern for them (ADAMK)
    - Audited dependencies and updated a variety of them (ADAMK)
    - Ctrl-Shift-W is now bound to "Close This Project" (ADAMK)
    - Added an option for traceing Padre subroutine calls to the
      developer plugin (SEWI)
    - padre-client allows you to use Padre for commit messages and other
      synchronous edit events (CORION)
    - Changed func_foo config variables to feature_foo, in anticipation of
      of a future equivalent to the Mozilla "about:config" control (ADAMK)
    - Added feature_cursormemory to allow disabling of Padre's feature to
      remember the location in the file you were scrolled to (ADAMK)
    - Function List has resource locking around it and properly triggers a
      refresh when we show it for an already open document (ADAMK)

And there you have it. The full list of changes for Padre 0.56.

As you can see it's been an amazing development cycle. If you haven't already upgraded to Padre 0.56 don't hold back. It's proving to be fast to start- ok, wow, .56 does start flippin quickly - it feels agile and nimble in normal use ( sorry no quote from the channel on that one ), is more stable and some of the the rough bits are starting to get a little more polish.

The plan now is to merge in the work done by Steffen Meuller which sees improvement to the threading, fixes the classic Scalars Leaked warning, and reduces memory consumption. It's a major effort that will be done right after a release allowing for a clean slate to test and work on before a subsequent release.

It was penciled in for the development period after 0.56 for a 0.57 release, however it's been held over until after 0.57 is released.

Read and post comments | Send to a friend

Padre-Plugin-Swarm becomes useful almost useful.

2010-02-04T13:25:29+00:00

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

Padre 0.56

2010-02-01T11:41:13+00:00

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.

Padre 0.56 has been released...

2010-02-01T10:55:17+00:00

It's always my pleasure to announce the latest release of Padre, the Perl IDE.

As is the case of the release manager, especially this one, I see bits and pieces of what's going on in the IRC channel and do my best to commit fixes or improvements to trunk, but I rarely do. So as release manager I get to spend about 30 minutes getting Padre packaged up and ready and then make an announcement to the world.

For that I get to say I'm part of the Padre team! :)

Without doubt this was one of the busiest development cycles between releases I've seen.

Check out the Changes file as proof of this.

The listed changes this time around are so numerous I'm not going to repeat it all here.

What can be said about Padre 0.56 is that it is faster than it has been in a long time. Adam Kennedy said so himself. There's little to argue that it isn't. I find it amusing that our splash screen has little to do these days. Pity because it's quite pretty.

As is normal with projects like this, people add and take bits from the source tree, each little bit can start to add up in terms of the overall performance of the application. Adam has worked hard on improving the locking subsystem and make plenty of commits which over time has seen incremental improvements to the application's performance.

However it should be noted that Steffan's branch that improves the background task thread memory use is not in this release as Adam said in his blog entry about 0.56.

It was felt that given the number of changes in this release that it would be best to hold the merge of Steffan's branch until after 0.56 allowing the devs to poke and prod at the new changes in the dev cycle to release of 0.57.

This could mean a few things. 0.56 is the last stable and fast release for a while, or we find that the changes coming in with this merge will be fine and we release early a 0.57 to allow work to be done after a successful release.

All in all, Padre continues to move forward. It continues to bring with it incremental improvements and every now and then a release that is simply a giant stride. Such is 0.56.

As always, it's a pleasure to be apart of group of great people each doing their bit to make their programming life, and hopefully others, just that little more pleasant.

If you find any problems with Padre, feel free to drop into #padre on irc.perl.org and tell us about it. There's usually someone around to check into it.

Read and post comments | Send to a friend

The Next Release of Padre

2010-01-29T13:02:25+00:00

Just when it seems like no one is looking a bit of noise is made about the up coming 0.56 release of Padre.

Adam Kennedy kicked things off with a great post about the improvements to Padre in the current development cycle and mentioned the work being done by Steffan Mueller in a branch that will see improvements to Padres threading and memory foot print.

This prompted me to post to the dev list about what to do.

The resultant thread has been one of the more longer ones I've seen for some time on the dev list and highlighted that much of the goings on within the Development group tends to be done in the #padre irc channel.

While this isn't a bad thing as the time overlaps can work well for most of us, it does highlight that we miss a group of people who simply lurk on the mailing list ( which is quite low volume so it's not an onerous task to keep up with ).

The other means of keeping people abreast of developments and goings on is via blogs, the Padre web site has it's own aggregation of Padre related blogs, but not everyone is on there, nor does it guarantee a wider audience that say the ironman blogs do, or even the planets, http://planet.perl.org and http://perlsphere.net/.

So this is just a post to keep in mind that the dev list is still a way of disseminating information or thoughts with Padre to a wider audience.

I'll also make sure that all release posts get a copy on the list too.

Read and post comments | Send to a friend

ORLite ARRAY objects, one last speed up before Padre 0.56

2010-01-28T14:13:58+00:00

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"

Upcoming Padre 0.56 best in a long time, and hugely faster

2010-01-27T05:45:27+00:00

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.

Padre 0.55 Released

2010-01-21T08:37:43+00:00

The subject says it all, Version 0.55 has been let loose on the world.

You can tell that Adam Kennedy is a performance nut ( if the Tiny modules he does isn't already a hint ) with the majority of the work in the Changes file this last 2 weeks being based around finding improvements to the overall performance of Padre itself.

This release is mostly about fixes and performance gains:

Performance Fixes:
    - The directory tree refresh method will shortcut if nothing has
      changed, which should fix a number of bugs relating to the
      directory tree "doing things" when it shouldn't be (ADAMK)
    - Saving files to somewhere other than the current project will now
      correctly flush the document project state, and triggers a directory
      tree flush so that we communicate the change in project (ADAMK)
    - Tuned the directory tree refresh logic to improve startup speed when
      launching Padre with specific named files to open (ADAMK)
    - Tuned the creation and management of tool widgets to remove the need
      to load or construct tools at startup time that are turned off in the
      user's configuration.
    - Tuned lock-release refresh execution to remove low-level refresh
      methods that are also contained in higher level refresh methods.
    - Removed a superfluous AUI Update from the refresh method (ADAMK)
    - Delay loading some additional GUI classes and objects until they
      definitely needed (ADAMK)
    - Suppress warnings that occur during plugin loading (ADAMK)
    - Tuned menubar refresh to only fire if we change document mimetype,
      which saves a ton of CPU and seems to reduce flicker (ADAMK)

Bug Fixes:
    - 'Simple' possible fix for #331 to update the tabs when 'save all' is
      run in Padre. (PLAVEN)
    - Fixed #819: Don't crash on missing project dir (SEWI)
    - Tentatively fixed #796 by spawning migration scripts in a manner which
      does NOT assume the pre-existance of STDOUT. This is at best a
      short-term hack, because this STDOUT problem is going to come back and
      bite us in other ways in the future, for sure (ADAMK)
    - Cloned ORLite::Migrate to a private version as Padre::DB::Migrate
      so we have a better chance of fixing bug #796 (ADAMK)
    - Add full list of file types to the View Document As menu (SZABGAB)
    - dist-zilla projects detection finally fixed (#489) (JQUELIN)

Jerome chipped in to get dist-zilla working correctly in Padre and blogged about it.

Sebastian (SEWI) fixed a bug reported late in the cycle by Jerome and I, hopefully, fixed a rather annoying bug that has been around way too long where "Save All" left the "Modified" Asterisk still showing in the tabs.

So this release doesn't see a lot of new items, that being said, I'd say that Padre is running just that little bit quicker than it was before.

Thanks again to everyone who makes Padre what it is today.

Padre isn't just about the IDE itself, there are also a number of plugins that extend Padre's capability beyond just typing perl and getting syntax highlighting. Some of the commits during the last few weeks see updates to Swarm and the Catalyst plugins.

The svn repository for Padre hosts a number of the plugins, but the ones that actually make the light of day get published to CPAN. That doesn't mean the repo has all Plugins, many others are hosted outside of the repo, so to see what's available for Padre, always check CPAN. Check the list yourself!

The translators are doing stellar work keeping Padre up to date, however if you see your language isn't covered so well in Padre, please feel free to join in. Information about how to get started with translating to your language can be found on the Padre wiki under translation intro .

Read and post comments | Send to a friend

Padre 0.55 Stand alone for Linux based on perl 5.11.4 released

2010-01-21T05:29:31+00:00

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!

next padre version will (finally) recognize dist-zilla projects

2010-01-20T10:19:22+00:00

padre 0.55, due tomorrow, will finally recognize dist-zilla projects correctly. among other things, it means that it will set @INC accordingly for syntax checking, keep the directory browser at the project root, etc.

it took a bit of time since the "installer" detection is spread out in different places in padre... this needs refactoring, for those interested.

Use case for Strawberry Perl for Windows

2010-01-14T10:09:06+00:00

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

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.

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.

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

unzip the file
install Strawberry using the .MSI package
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.

Would you like that people at FOSDEM will hear about your Perl project?

2010-01-12T12:05:26+00:00

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!

Padre starts the new year with version 0.54

2010-01-07T11:26:30+00:00

Awesome, a heading that breaks the tradition!

Introducing Padre 0.54. This is the Christmas and New Year release of our favourite Perl IDE. It's also the first string freeze release in an effort to get some of the translations up to speed, which I think we did well with.

It goes without saying that the Devs always do an amazing job toiling over code, solving niggles they have with the IDE as well as resolving bugs that creep in, but when your application lives in a space where many languages are spoken, the fact that your application of choice also speaks your language is also key to its success.

Many of the translators for Padre also crank out the code, so they tend to pull double duty. Without these people, Padre would be a little less than it is today. Thanks go to the translators for their on going support to Padre. Next time you only get 24 hours to update the strings! :)

OK, so on with the release details:

The Changes file ( yes the one I forgot to update for the release - whoops ) has the usual run down of what's been done for this version.

New for 0.54:
   - Added the first PROJECT-backend config_perltidy setting, so that
      projects can for the first time define a project tidy policy. This
      project-specific policy isn't being used by the plugin itself yet,
      but this change clears the way for that kind of functionality (ADAMK)
    - Added config_perlcritic configuration setting, so that projects can
      define perlcritic policies (ADAMK)
    - Added experimental support for clickable filenames in Output panel.
      Currently only matches: at line 5. (PDONELAN)

Fixes in 0.54
    - If all files are closed, the function list would ->Hide itself
      permanently and never come back. Resolved (ADAMK)
    - Fix perl interpreter selection (SZABGAB)
    - Updated DBD::SQLite dependency to 1.27 and ORLite dependency to 1.30.
      This should now correctly throw an exception on a corrupt padre.db file
      which will cause an immediate crash at startup with a SQLite-related
      error message instead of a secondary error message complaining about
      missing Padre::DB classes (ADAMK)
    - Moved Padre::HelpProvider::Perl to Padre::Document::Perl::Help to
      prevent plugin classes from being scattered all over the namespace
      tree (ADAMK)
    - Moved Padre::QuickFixProvider::Perl to Padre::Document::Perl::QuickFix
      to prevent plugin classes from being scattered all over the namespace
      tree (ADAMK)
    - During shutdown, be more precise about the order in which we clean up
      and be more careful to ensure that ->Update is NOT disabled, to prevent
      segfaults on Windows from the "disabled update at exit" bug (ADAMK)
    - All tests now run without the need for a visible Padre window (ADAMK)
    - Ticket #756: Wx::Perl::ProcessStream 0.24 solved this issue
      Changed the dependency to 0.24 (SEWI)

Adam Kennedy really showed his alpha status over the festive season. While many of us might have had great intentions to crack out some code ( rebuilding my MythTV box IS a valid reason for not coding anything for Padre ), it's good to see that the while some of us did take a break others keep the fires burning. Of course there are those who work on the Plugins that extend Padre's capability who don't get the visibility of a Changes file to highlight their efforts. One such Plugin is the Swarm Plugin, actively worked on by submersible++, a means of adding collaboration to Padre, aptly covered in Adam's first Padre Blog for 2010.

And finally a quick note to say that one of the more annoying bugs ( yes all bugs are annoying ) ticket #390 saw some progress during this development cycle. code4pay++ has taken this on and opened up discussion about how to handle the X11 events on Perlmonks. Lets hope this one is sorted out once and for all.

Padre is a Perl IDE written in Perl, it's an IDE that continues to improve with each new release. If you come across any issues please drop into the Padre IRC channel #padre on irc.perl.org or from Padre itself: Help->Live Support->Padre Support (English).

Read and post comments | Send to a friend

When will Padre move to Git?

2010-01-05T20:10:48+00:00

Yesterday while I was not watching the IRC channel the issue of moving to Git came up again. You can see the log of the conversation. I know many Perl projects moved to Git, including the Perl 5 Porters. Maybe it is time for Padre too, to move?

I have to tell you people I really am getting fed up with the Git fanboyism. This time it wasn't so bad - probably because I did not see it live happening - but for a long time I wanted to write about this already. Git might have a huge technical advantage over Subversion and as we are told it also has an enormous social advantage but if I am pushed (no pun intended) to use Git then I feel very uneasy. To say the least.

I don't know what is your reaction to sales people that are trying to push you into buying things. Usually I kick them out even if I need that thing and will try to buy somewhere else. That means more time invested and sometimes even higher price. I know it is not rational but rather emotional. I am ok with that. I know most of the people reading this will make only rational decisions after carfully weighting all the technical aspects (e.g. of Git and Subversion) but I let emotions get involve as well.

I allow myself doing this as I learned in my marketing studies that most people actually make their decisions based on emotions and then rationalize them. As we were told, it is not surprising that a Porsche comes with a huge manual. After all you don't buy it to pick up chiks. You buy it because of its technical superiority. Or so you tell your friends and yourself!

Well, maybe it was something else we learned. I don't know. I almost failed that class.

Anyway back to

Padre and Git

I have been using Subversion for many many years now, since before it was release as 1.0 and I have been using Git for some time. For a long time I did not get anything about Git. The first thing I liked about it was actually Github. Specifically the ease I could create one-off patches. Even more so to create several small patches to other projects.

If a project is using Subversion I can pull it repository make a small change and send the patch. That's not bad but it requires an off-the-band communication via e-mail or nopaste or putting it in the bug tracking system or some other way to send the patch. The author also has to deal with pulling the patch from that place - and the fact that these places vary already create a head-ache - in short it is more complex than I'd want.

It is much worse in case I want to make several small patches that might depend on each other. I can't easily do it with subversion. I could have done it with SVK or Git, creating a local branch of the remote SVN repository, making several commits locally and then sending the patches one by one.

The other way would be to ask the reposioty owner to give me a commit bit. Even if s/he gives out commit bits easily as happened with Pugs and as happens with Padre it still takes some time to find the person who can give that commit bit. If I just want to make a few small changes the overhead might be too high.

Github

That's where Git+Github actually has an advantage. I - as someone outside of the project does not need to wait for anyone. I can just fork, make changes and push it back to Github. The maintainers of the project can pull my changes later on. This can work very nicely for small patches though for bigger changes people should still talk to each other first.

I don't think it would make much sense for Padre to keep the core developers work on their own fork as with the speed of our development we could easily create integration problems but we are told this only the fear of the unenlightened.

I can see an advantage of moving to Git and Github but I have my fears from the switch. Besides, the biggest disadvantage I see is that many of our developers don't not know Git - including myself. Actually I know several of them did not know even SVN before they joined the project. The main issue Adam Kennedy mentioned regarding Git was the lack of good Git client on Windows. I don't know the state of the Git GUI client market on Windows so it might be just his totally unaccepted emotional reaction (see above) to the pushing but I can't talk in his name.

Anyway I'd be ok moving to Git and Github and keeping a central repository on Github for the core developers and enjoying the benefits of Github for one-off changes but I have a precondition. In order to make that happen we have to make sure our developers can easily use Git so we need a superb Git plugin for Padre with Github integration that works on all operating systems we support.

So take it as a challenge. Improve the Git plugin to the point that it is super easy to use it even without knowing much about Git and you removed the biggest obstacles from our way to Git.

Padre in 2010 - The year Padre becomes a team player

2010-01-05T02:28:01+00:00

In 2008 the Padre project was about building a large development team, with the actual writing of the editor being almost a secondary task (albeit an important one). We knew the actual coding job was utterly immense and too hard for just the few people initially involved to deal with.

A lot of the work on heaviest work on the editor in 2008 was on deep subsystem stuff so that we could more easily recruit more people, like the Config/DB API, the Plugin API, the Locale API, and the basic distribution structure and code layout. And in the process we made enough of the actual editor that people could Understand what we were building.

In 2009 the Padre project took that team building success and built the editor into something we can now honestly call an IDE without our inner pedants cringing.

There are still various problems to solve, lots of rewriting of shitty first implementations to do, and "essential" features to add. An IDE is an Open Problem, and so that is never going to change and there will always be More Things To Do.

But I think it's reasonable to say that we've now built an IDE that the Perl community can call its own, and an IDE that you won't want to leave once you get used to some of the ways in which it excels at Perl development.

In another few months, we should be at something we can reasonable use as a part of the default Strawberry install for the upcoming all-in-one Strawberry Professional distribution.

However, for the most part Padre still lives in a mythical fantasy world where there is only one developer, only one host, and only one desktop. It is still, primarily, a tool for the individual developer. And now we're finally in a position to do something about it.

In 2010 the Padre project will evolve from an IDE into a Collaborative IDE. This isn't something that will happen by fiat. Nothing in Padre happens by fiat, and there is no roadmap.

But if you use Padre on a regular basis, you can see that the place where the most development time is being "wasted" now has now clearly moved from working with Perl code to working with projects, teams, and the internet.

In 2010 you will start to see some of the following:

1. The rise of Policy

One of the biggest themes in Padre is the concept of "Intuition", that your editor should recognise (reliably) what you are doing and adapt to it without having to be told, and in a way that doesn't remove freedom in the process.

Padre already can recognise projects without being told where they are, identify the files and assets in a project without being told where they are, and save files without you saying where. It knows about tabs vs spaces warfare, it knows what language you speak, and it knows how to distinguish things you personally prefer from things you happen to be doing on the current machine.

In 2010 Padre will learn about when it is that the needs of the team outweigh the needs of the individual, and how to selectively apply preferences and intuition differently in different open files, based on the specific preferences of different projects.

You will be able to define, at a project level, rules for your project that Padre will automatically follow, such as spaces vs tabs, perltidy rules, perlcritic preferences, and so on.

This is especially important for making Padre more relevant in corporate environments, where adherence to coding policies and standards are essential.

2. The demise of the host

Even though it hasn't been used to any great effect as yet, Padre has always understood that some configuration is about the user, and some is about the system.

In 2010 Padre will finally start to use that information. A 4th year student team from the University of Western Ontario is currently implementing a synchronisation client/server for configuration data, similar to Mozilla Weave or Google's older bookmark sync.

This will allow all your personal preferences to migrate across multiple installations automatically, without getting mixed up with data that only refers to the machine you are currently working on.

3. The push towards Portable

Another area that I hope to see movement on this year are configuration and GUI improvements to make Padre much more tolerant to changes in the underlying operating system.

While many applications do not support this, I'd like to see Padre automatically adapt to changes in screen position and resolution, mounting and dismounting of drives, and a variety of other crazyness that developers often do in the process of creating applications.

This tolerance and adaptation to screen geometry errors should also allow better configuration of windows and dialog positioning, so that you can more easily tailor the layout of Padre to your particular multi-screen developer setup.

4. The swarming of Collaboration

Finally, the experimental Swarm plugin is (after a long gestation) starting to get closer to producing a usable collaborative communications subsystem that can be used as the basis for chat, file sharing, remote peer review, and other collaborative goodies.

In 2010 Padre should start to take advantage of some of these new capabilities to add new and interesting real-time "Intuitive Collaboration" abilities (which should be quite interesting at conferences and hack-fests).

In summary, it's looking like a great year for Padre, and by the end of the year Padre should hopefully be starting to become the corporate Perl editor of choice.

Padre on ActivePerl, on FOSDEM and on CeBIT - 2010 starts good

2010-01-04T21:57:48+00:00

Adam Kennedy have outlined his plans for Padre for 2010. I don't have such long term plans. Being inpatient in this regard I am usually very bad at projects that take a lot of time to show any signs of life. In a way the Release soon, release often mantra of the open source world very much fits me.

Anyway, there are some Padre related news here:

Padre on ActivePerl on Windows

First of all thanks to Mark Dootson Padre 0.53 is now packaged for ActivePerl on Windows. In order to install it check the instructions on his ppm repository.

As he told me the padre.exe does not work there but the padre.bat does. I am not sure if this is related to the bug that Padre Stand Alone does not start first time after installation. or if it is some other issue but it is better to be awre of it.

If you are using ActivePerl on Windows now is your time to try it and let us know of any issues.

Padre on FOSDEM

FOSDEM is just a month away. My lightning talk proposal about Padre was accepted. That means I'll have 15 minutes to talk about it.

As you might have read we are also going to have a Perl stand there for which I am looking for people to help. We need to make sure there are always going to be at least 1 but better 2 people at the stand to talk to visitors. Explain about projects. Explain where Perl stands now. What is Perl 6 and when will it be ready. What is Moose. What is Catalyst. You know, there are going to be lots of questions.

On FOSDEM we will have to be prepared on how to talk to people who are very intrested in Open Source and programming but has little - in the good case - or wrong information - in the bad case - about Perl.

Padre on CeBIT

This is not really any Padre issue though Padre will also be represented. Our applicaton for a free Perl booth was accepted by the organizers of CeBIT. That means, a month after FOSDEM we have another event - no talks here just a booth - where we can show Perl and Perl related projects to visitors.

This is going to be entirely different from a Perl conference or from FOSDEM as CeBIT and its visitors are really far from the open source world. If on FOSDEM we will have to talk to people who understand our environemnt in general just not our language than on CeBIT we will talk to people many of whom don't know or care about open source or programming at all. They really just want the business value in our tools and products.

retrospective 2009

2010-01-04T17:51:51+00:00

2009's over, but the year was quite a busy one for me on the perl front:

i finally took the time to investigate moose, and decided to port some of my code to use it.
i discovered dist::zilla, and definitely plan to use it in all my dists.
i discovered some other cool new perl modules (thanks guys).
i uploaded some new dists on cpan, including games::pandemic (which i'm quite proud of, even if i need to continue hacking on it).
i updated & released some of my existing dists.
i contributed to other projects such as padre, dist-zilla, etc. sending patches is a good way to thank the author for their work.
it's even easier to contribute with github, which i'm using more and more for my projects (and it's no more slow by now, woohoo!). of course, git is the master piece allowing this easy sharing.
on mandriva's front, i resurrected parrot rpm, and finally shipped rakudo.
2009 was also the year of the great migration to %perl_convert_version
... with lots of new perl modules available as rpm (i am managing 450 of them).
... and finally i took ownership of perl rpm. (thank you perl5 porters btw for 5.10.1 and the push for next stable version!)

so, busy indeed 2009 was... i just hope that 2010 will be as fruitful on the perl front for me, and for the perl ecosystem by large.

The End of 2009 CN Perl Advent Calendar

2009-12-25T21:52:37+00:00

I'm really very happy that we get it done today. the last article is perlthanks from I. and we didn't miss one day. 25 tips 25 days.

I have totally 18 articles published, really Wow! they include ack, autodie, dzil, local::lib, Devel::NYTProf, Padre, pip, Plack, REPL, perlthanks and more.
check them if you missed. :)

Thanks.

Padre Ticket #1 Fixed! - How our new locking code works

2009-12-24T00:46:31+00:00

http://padre.perlide.org/trac/ticket/1

Our Christmas release of Padre 0.53 is done now, and it's looking really really awesome.

My contribution to this release is a shiny new resource locking system, which has significantly improved the speed of most startup, shutdown and file operations.

A couple of people have asked me to post about how it works, so here's the short and simple version.

First, some background on resources in Padre and Wx.

When managing performance and blocking issues in Wx, the main players are the visibility state (changed via ->Show and ->Hide), the update state (changed via ->Freeze and ->Thaw) and the busy state (changed via various mechanisms).

Visibility is most important during startup and shutdown.

When starting up you want to delay the appearance of the window until the event loop is bootstrapped and you are able to take user events on the window, but you can't wait for things like opening files because this may take quite a long time and cause the editor to appear slow and "bloaty". It's a trade off between performance, and PERCEIVED performance (which is almost as important).

When shutting down, things are a bit clearer. As soon as you are sure that the editor will no longer need to interact with the user in any way, you can proactively ->Hide the window and finish shutting down while invisible (letting the user get on with their next task).

The update state is applicable across the entire lifetime of the application.

If updates are enabled, every action results in a paint event (or will be captured by the next paint event). This creates the appearance of things happening, but changes to the application take longer because of the cost of repainting.

Also, often you don't want to be faster in this way. If you are working with a list box, during the process of deleting all the values and generating a new (slightly different) set of values you don't WANT the user to see the box empty and incrementally refill. It acts a form of "flicker" (one of the great enemies of GUI applications). What you want is for the list box to instantly transition from one filled state to the next filled state creating the impression of incremental change even where the underlying code isn't incremental.

The way you solve this problem in Wx is to explicitly disable repainting via the ->Freeze method as late as possible, quickly make your changes to the GUI structure, and then as quickly as possible re-enable painting via ->Thaw.

This must be fast, because if the users are doing anything they will notice after a quarter to half of a second. Also, after 2-10 seconds in some cases the operating system will start to get concerned about your application. Windows for one will sometimes spontaneously ask Wx to repaint your menu after 5-10 seconds. If painting is disabled, the result is a blank white bar where your menu used to be.

Finally, for Padre specifically, we also need to be concerned about expensive refresh operations. If you open a file, we need to regenerate the directory tree, the function list, outline, menu, toolbar, title, recent files list, and directory list and some of those things (like the directory tree) are expensive.

We need to be sure that we avoid updating elements that don't need to be updated (opening a new file in the currently project context shouldn't result in a project file list refresh, for example) and that we avoid or delay any pointless operations (like updating the GUI during a multi-file open) until after the last file is done.

Unfortunately, the update and refresh issues are problematic when most of your application is event-driven, but all your refresh operations are imperative.

When you first start writing Wx code, you usually do something like this.
sub open_file { my $self = shift; my $file = shift;

$self->Freeze;

my $panel = $self->create_editor; $panel->load_file($file); # 10 more lines of setup code here...

$self->refresh_all;

$self->Thaw; }
This kind of thing works, but it will only work if called directly from the user event and only if it doesn't throw an exception.

What if $panel->load_file errors due to file permissions, and we don't get a chance to call ->Thaw?

Or what if we want to open several files?
sub open_files { my $self = shift; foreach my $file ( @_ ) { $self->open_file($file); } }
In this case, open_files will freeze and thaw repeatedly, slowing down the loading process, and will pointless refresh all the GUI resources after each file.

Or what if we want to open a named group of files (a "Session").
sub open_session { my $self = shift; my $name = shift; my @files = $self->get_session($name); $self->close_all; $self->open_files(@files); }
Now we are at two levels of indirection.

Or we want to have a ->next_session method (three), or to support arbitrary scripted "macro" actions contributed by the user (four)?

The real problem with imperative management of these resources is that they don't encapsulate cleanly. You can't nest them inside each other ad infinitum and have code calling your not have to care how you are implemented.

Wx takes care of part of this problem for you, and hints are the right general solution.
my $guard_object = Wx::WindowUpdateLocker->new($window);

This built in "locker" class generates objects that fire ->Freeze on the parameter window at constructor time, and ->Thaw at destructor time (i.e. when they fall out of scope).

Importantly, these objects also nest properly so that the ->Thaw only occurs on the outermost destructor. This provides the encapsulation we need so badly.

Unfortunately, the ORLite-based SQLite database classes in Padre::DB we rely on quite heavily don't have this ability (and Wx native asynchronous SQLite support isn't available yet).

Worse, our resource refresh logic doesn't follow this pattern at all. Often you can't just "lock" the refreshing of the whole window or the directory list, because you have very specific times that you want the refresh to fire.

For example, if the user has two files open and is switching between one and the other, we want to initially lock updates while we change the editor panel to the new file but we DON'T want to refresh the other tools. Once we release the update lock to show the new file, we know it will take around a second for the user to notice and adjust to what they are seeing. So we want to use THAT time to refresh the other tools, applying another update lock during the changes to prevent screen flicker and avoid distracting the user with unexpected secondary movement.

To resolve all these problems, I've added a new locking API based on a similar guard object principle to the internal Wx one, except that it is able to control several locking states at the same time. More importantly it's also able to understand the interplay between the different lock types.

The canonical usage looks something like this.
my $lock = Padre::Current->main->lock('DB', 'UPDATE', 'refresh_menu', 'refresh_title');
This indicates that we should "lock" changes to the SQLite database (causing all database operations to take place in a transaction), lock painting updates, and that some time in the future we'll need to do a refresh of the menu structure and the window title.

To simplify and add extensibility to the implementation, the lowercase refresh locks all match directly to methods on the main window class. So anyone can add a new "lock" type just by adding a refresh_something method.

When the lock handle expires, the lock manager follows a specific release plan. First, release the update lock. Second, fire any refresh events that have accumulated. Thirdly, commit any pending database statements and release our database connection (again, taking advantage of the user needing a small amount of time between screen updates and their next action).

Where the value of a custom lock manager comes in is the Padre-specific semantics.

For example, locks on the database and update state don't interact with each other, but refresh method locks persist beyond the scope of the lock if the release occurs within a higher parent lock.

Take the following example.
SCOPE: { my $lock1 = $main->lock('UPDATE', 'refresh_menu'); SCOPE: { my $lock2 = $main->lock('refresh_directory'); } SCOPE: { my $lock3 = $main->lock('DB'); } }
In this example, the database lock will clear at the end of the nested scope, and a commit will occur. However, the 'refresh_directory' method will NOT fire in the nested scope because there are other active related locks in effect in a parent scope. Instead, the 'refresh_directory' will be transfered up to the higher lock.

When $lock1 releases, it will fire BOTH of the refresh events.

This is a basic implementation of the concept (less than 100 lines) but it does work quite nicely. However, it does have some problems remaining to be solved in the next version.

The syntax is still a bit clunky. To fire a refresh event immediately (if you are at the top level) you still need to do the following.
$main->lock('refresh');

This will do an immediate ->refresh, but remains lock-aware so that if you are in a higher level lock it will add refresh to the list of things to fire later. It would be nice to have a cleaner syntax for this case, or do be able to have the ->refresh method itself inherently know if it is in a lock and just shortcut return true.

Another problem is that the refresh methods come in a natural heirachy that the lock manager doesn't know about.

For example, the top level ->refresh will itself call ->refresh_menu, ->refresh_title and so on. But the lock manager isn't aware of that.

If two nested scopes ask for 'refresh' and 'refresh_menu' locks it will always fire both refresh methods, even those doing the first one means we don't need the second one.

And it won't fire the locks in a reliable order either. Even if ->refresh was smart enough to automatically clear the 'refresh_menu' lock, we can't be sure that ->refresh_menu won't fire first, before the higher one.

This problem discourages the creation of finer-grained locks, because it would increase the number of collisions and pointless double/triple/etc refreshing.

By discouraging finer locks we end up using bigger locks more often, resulting in more waste due to pointless refreshing of GUI elements.

Ideally, the locker would contain information on the relationships between refresh events, so that the refresh events can be fired in the most "correct" order, with pointless methods filtered out.

Padre 0.53 Stand Alone for Linux on perl 5.11.3 released

2009-12-23T12:46:33+00:00

As Peter Lavender has announced Padre 0.53 was released a few hours ago. Among many other things it contains the first version of a built-in debugger. You can download and install Padre from CPAN but if your are using Linux there is also a new binary package that you can download and use.

It is a very experimental package, not only because of Padre but because it is using perl 5.11.3 the recently released monthly build of perl 5.12 to be.

While building it I encountered a few problems related to changes made to perl. These changes might affect your code as well. You might want to try your modules to see how they behave on 5.11.3.

One of the modules was generating warnings like this:

   defined(%hash) is deprecated at .../SomeFile.pm line 82.

Another one was generating warnings like this:

  UNIVERSAL->import is deprecated and will be removed in a future perl at .../SomeFile.pm line 7

They passed their tests but Padre, during its own tests checks if there are not unexpected warnings using Test::NoWarnings and fails if there are. So I had to patch those modules in order to allow the installation to proceed. ( Reports were sent to the authors so I hope these will be fixed soon ).

Test::Exception failed one of its test. I force installed the module and reported to the author and to p5p where I quickly got a response from David Golden pointing out that there is already a fixed developer version on CPAN.

I also had to patch one of the tests of Padre due to a change in a warning text perl 5.11.3 gives. The same change was then committed to the version control of Padre.

It was a bit annoying to hunt down the issues as my build system does not report correctly yet but in the end I got it working. When I tried to install the Perl 6 and the Catalyst plugins I encountered further issues so I decided to postpone them.

If you want to try it now, look at the instructions:

Download

Download perl-5.11.3-xl-0.03.tar.gz (File size: 29,002,849)

  wget http://perlide.org/download/binary/perl-5.11.3-xl-0.03.tar.gz

Unzip it

  tar xzf  perl-5.11.3-xl-0.03.tar.gz

and You can run the padre.sh file:

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

Enjoy and report any issues.

Padre 0.53 is released!

2009-12-23T12:20:21+00:00

This is my third release as release manager for Padre, I really did have to change the heading!

It's been a busy 9 days since the last release. i spent a bit of time chasing up our awesome Translators
to make sure this release would see a complete set of translations. The translators stepped up to the plate and a day before release we had 4 green squares on the translation status report.

Then Gabor found out how to add the tips in the menu to the status bar. While a really nice touch, the changes caught out the translators. I delayed the release for as long as possible, but unfortunately not long enough to get 100% of the French translation. Jerome missed out by barely 2 minutes. Sewi (Sebastian Willing) only just made it, so 100% DE made it into this release.

I'll see if I can't roll out a release with all our languages 100% :)

OK, so lets get on with what has happened in these last 9 days!

New:
    - Add initial version of a debugger using Debug::Client (SZABGAB)
    - Landed new multi-resource locking subsystem. Many operations are now
      prevented from refreshing the GUI multiple times. Startup, shutdown,
      open and close multiple files, session changing all much faster (ADAMK)
    - Ctrl-Tab behaviour is now configurable (SEWI)
    - Reuse the comment field of the menu actions and show them in the toolbar (SZABGAB)
   - Added Preference setting to control autocomplete when editting a script rather than
      a Module. (WAXHEAD)

As with any release not only do we see new items and functionality but there are always a list of fixes. Azawawi got busy fixing problem bugs in Padre that caused bad behaviour with Padre crashing.

Fixed:
    - Fix crashes when running refactor actions when there
      is no document (AZAWAWI)
    - Open resource searches now for user selections (AZAWAWI)
    - The Open resource's OK button is disabled when the
      search results list is empty (AZAWAWI)
    - Fixed "Syntax Check" focus loss bug while switching tabs quickly
      and a syntax error is in one of them (AZAWAWI)
    - Help search does not block when loading a long help topics
      list (AZAWAWI)
    - Fixed missing mime type guessing that caused new Padre documents to
      default always to Scintilla (AZAWAWI)
    - Fixed Padre crash when closing a Perl 5 script tab quickly while syntax
      check is on (AZAWAWI)
    - Added "No errors/warnings to $project-relative-filename" to syntax
      checker. (AZAWAWI)

See!! Azawawi was just unstoppable this release. It's always great to see people return to Padre, rolling up their sleeves and grinding out the improvements!

Performance improvements:

Adam Kennedy got busy with some major changes to the core of Padre regarding the way it handles internal locking and refreshes. This should see some improvements to the speed of Padre opening and closing.

   - Audited the startup process for database operations that either weren't
      being done in a transaction, or were doing crazy bizarre things. Startup
      is now noticeably faster (ADAMK)

And that's not all the changes. You can always see what each release brings with it and get a sneak peak of whats to come by checking out the Changes file.

I'd like to thank everyone involved with Padre. We often can be found in #padre on perl.irc.org It's always a fun channel to hang out in, we have some really clever people working on an IDE that I have come to really enjoy using.

If you haven't tried Padre why not?

Read and post comments | Send to a friend

The slippery Devel::Declare slope for Perl tool support

2009-12-17T00:28:56+00:00

Devel::Declare vexes me greatly.

On one hand, it's interesting to see the kinds of things you can do when you have the ability to temporarily take over parsing of the language.

On the other hand, this ability to just parse whatever the hell you want means the gradual decline in utility for the entire Perl development toolset. It's like someone has taken source filters (which everyone at least KNEW were "evil") and made them popular and "safe".

The real problem here is not that these problems are occurring, but they are occurring for what often seems like (or actually is) a very good reason. And as anyone who has seen my "Nothing Can Possibly Go Wrong" talk should know, the most dangerous failures are the ones we are seduced into because it seems like such a good idea.

For example, take this cool implementation of URLs via Devel::Declare.

Mixed that with LWP::Simple and you can do things like this, that actually run.
my $content = GET http://ali.as/;
Or how about inline SQL, as featured in a couple of other languages. I'm fairly certain that by adding hooks for, say, SELECT, INSERT, UPDATE and DELETE I could easily make the following work.
my $arrayref_of_hashes = SELECT * FROM table_name;

This stuff is supremely shiny, and if you're anything like me as soon as you look at it you want it badly.

But these features aren't free.

In the general case (looking at ARBITRARY modules rather than specific modules) you lose the following.

1. No/degraded syntax highlighting.
2. No/degraded PPI parsing.
3. No/degraded shiny Padre refactoring tools.

You also lose support for things like Perl::Critic almost entirely. PPI's statement classifier drives a lot of critic functionality. It only exists because PPI can reliably find the ends of statements.

If you break the ability to find the end of a statement (as many D:D modules do to define their own block keywords like "class { }") then the parse tree starts to get really really whacky and critic will inevitably start to spit out false positives.

Once you start spewing false positives in enough volume, you undermine confidence in the tool and we might as well stop using it (or at least turn off entirely rule subsets).

There are proposals for ways to extend PPI so somehow support these new keywords (I've even agreed with Matt on how we would go about it) but I continue to suspect they don't work in the general case because you have to have installed the PPI extensions in advance, before you attempt to parse a document containing those D:D modules (or you allow arbitrary execution of user code, at which point Acme::BadExample will complete pwn your machine).

This process gradually grinds onwards. D:D gets more mature and more used, Perl 5.12 contains core enhancements that help make it work better, further legitimising the concept.

Each step along the way is completely rational, and completely defensible. And it all looks great in blog code snippits. To paraphrase one prominent Perl core dev "Should we stop making the language better because it breaks PPI?"

And yet, at the risk of bringing down Godwin's Law on myself, I can help but see the kind of effect described in the famous poem First They Came.

First they came for the communists, and I did not speak out—because I was not a communist;
Then they came for the trade unionists, and I did not speak out—because I was not a trade unionist;
Then they came for the Jews, and I did not speak out—because I was not a Jew;
Then they came for me—and there was no one left to speak out for me.

The difficulty level to modify the parser and break the development tools is already starting to move from "a large effort by experts" to "check out this neat URL hack".

At some point, the use of D:D-style parser hacks becomes routine and normal, and people start implementing new extensions just for their one specific project.

And at some point the primary interface to Moose or Catalyst is using D:D or something like it, because it's SO much more elegant. And so any code written with Moose isn't compatible with Perl Critic, and so on and so forth.

Some time soon, before Perl turns into Smalltalk (for which there are basically NO tools at all that don't also involve running the code), I think we need to have this discussion.

How many useful development tools are we willing to sacrifice (making development harder) in order to make development "easier".

Padre requires a perl built using threads

2009-12-16T14:52:58+00:00

A Padre user entered the Padre IRC channel today because he was unable to run Padre from the Ubuntu repositories on his Ubuntu 9.10. He got the error “Padre requires a perl built using threads”.

szbalint was also there and also using Ubuntu 9.10. He finally noticed that the user wasn’t using the Ubuntu perl.

He installed some CPAN modules some time ago – and one of them required Perl 5.10.1 (Ubuntu comes with 5.10.0). CPAN installed a new Perl but he answered the threading-question with “n”.

Module authors should check their requirements. Few things really require 5.10.1, most modules also run find on 5.9 or older versions.

If you get a thread error while starting any Perl application, try out the “which perl” command. It should point to /usr/bin/perl if you don’t have any custom Perl installed.

Rehovot Perl Mongers, next meeting on Dec 22 - PDL, Padre

2009-12-16T10:15:35+00:00

I am sorry for the delay in the announcement but I am having a busy time wrestling with both clients and Padre as I would like to make sure the debugger already works in the next version. Anyway the next meeting of Rehovot Perl Mongers will take place on 22 December, between 18:00-22:00 in the Weizmann Institute. For directions take a look at the web site of the Rehovot Perl Mongers.

On this meeting Hadar Levi will give another talk, this time about PDL::Indexing explaining the basics of indexing and threading in PDL, The Perl Data Language

I think I'll use some time to give you a deeper introduction to Padre. I'll plan to look at

How the debugger was added (and by that time it should be past tense)
How to add a simple plugin.

If there is interest - as I'll ask on the spot - I'll give a short introduction to Perl. Either to everyone or to the smaller group who are new(ish) to Perl.

After that we will have exercises bot to beginners and more advanced users.

Please RSVP to my e-mail address if you are planning to come.

Please also tell other parties about this meeting and also urge them to sign up to either of our mailing lists that are relevant to them Rehovot.pm mailing list or Israel.pm mailing list

Padre 0.52 fresh on CPAN

2009-12-14T23:24:56+00:00

A German Padre 0.52 announcement was just posted, here is a short English one:

Padre 0.52 is out – and already downloadable from CPAN!

Peter (waxhead) did a very good release post, don’t miss it.

Also don’t miss the new Padre version which has few, but important news. For a full list, please check out Peters blog or the Padre 0.52 ChangeLog.

Padre 0.52 ist da!

2009-12-14T23:15:09+00:00

Padre 0.51 brauchte einige Tage, 0.52 war innerhalb eines Tages fertig – und Padre hat wieder den alten, geplanten Release – Rhythmus erreicht.

Unser Dank gilt Peter (waxhead), dem aktuellen Release – Manager. Er hat bereits jetzt eine Padre Weihnachts – Edition für die nächste Woche angekündigt, die einige kleine Überraschungen beinhalten soll…

Die wichtigsten Neuerungen aus 0.52 in Kürze (die komplette Liste findet sich wie immer im ChangeLog):

Das Entwicker-Script “dev.pl ” akzeptiert wieder die Padre Befehlszeilen – Optionen (SEWI)
Tickets #742, #762, #764 und #771 wurden gefixt, alle hingen mit der Aktualisierung des Menüs zusammen (SEWI)
Es kann jetzt mit Alt + Links/Rechts zwischen den benachbarten Dokumenten und mit Strg + Tab zwischen den Dokumenten in der Reihenfolge der Nutzung umgeschaltet werden (WAXHEAD, SEWI)
Padre erkennt auf Wunsch intuitiv den richtigen Ort und Namen für ein neues Dokument (ADAMK)
Neue Dateien können jetzt mit Template Toolkit bzw. Template::Tiny erstellt werden (ADAMK)
Diverse Bugfixes (AZAWAWI)

Wie immer ist Padre von der Padre Download-Page und von einem CPAN-Server in Deiner Nähe kostenlose erhältlich.

In letzter Zeit gab es einige Hinweise von Mac – Benutzern auf mögliche Fehler mit Padre auf MacOS X. Leider haben wir aktuell keinen aktiven Entwickler auf dieser Plattform. Wenn jemand Lust hat, mitzuhelfen und ein paar Sachen zu testen, freuen wir uns über einen Besuch im Padre IRC-Channel!

PS: Ein kleiner Hinweis in eigener Sache: Mein anderes Hobby

Padre 0.52 is heading to CPAN

2009-12-14T10:55:53+00:00

OK, so catchy headlines aren't my forte'.

I'm happy to announce that Padre 0.52 has been released.

This release brings with it a fix for CRTL-Tab cycling. CRTL-Tab stopped working a couple of releases back. Given such a heavily used key combination not working it was considered a blocker before we released this version.

Sebastian Willing (Sewi) and I spent some time too-ing and fro-ing in #padre trying to track down where the Event was being consumed. With not one, but two fixes later we had it fixed.

The release don't just bring with it a bug fix or two:

New to Padre in this release:

     - Added "Save Intution" to the File menu, to automatically save a new
      file wherever Padre is confident it is appropriate (ADAMK)
     - New file creation is now driven by Template Toolkit templates (using
      Template::Tiny). This should allow even basic new file creation to be
      somewhat adaptive to the user or project context (ADAMK)
    - Alt-Left and Alt-Right switch to the neighbor panels which Ctrl-Tab
      uses the last-used order (SEWI)

Fixes in this release:
    - Padre speedup: Limit number of menu bar refreshs (SEWI)
    - Fixed: Padre command line arguments work again when using dev.pl (SEWI)
    - Fixed: Menu options get disabled/enabled as needed again, this also
      fixed ticket #742, #762, #764 and #771 (SEWI)
    - Fixed ticket #790: Ctrl + Caps Lock reduces font size (AZAWAWI)
    - Fixed ticket #750: Ctrl-Tab works again (WAXHEAD, SEWI)
    - Fixed Padre crash in Module Tools/Install Locale/Module/CPAN config (AZAWAWI)

You can always get a sneak peak at what's to come by checking out the Changes file directly from our SVN repository.

Read and post comments | Send to a friend

Host a party, fix a major bug!

2009-12-13T00:53:45+00:00

I'm in a bit of a reflective mood this morning. Put it down being a bit tired after hosting a teenage boys party where the group played Halo non stop, with breaks for food and hydration only; where not only was the annihilation of each others screen character high on the agenda but so was personal reputation and ego, and a crazy notion of pulling an all nighter. So I knew I wasn't going to be getting to bed myself until late.

It's fun to listen to boys when you live in a house full of girls and women, the way they communicate with each other is very different to the way girls do. Surprisingly I'd say that the boys this year while insulting and loud weren't anywhere near the decibel levels of the two girls parties we hosted earlier in the year.

The mayhem that was my lounge room afforded me guilt free time to look over some ideas I've wanted to see with Padre, namely configurable toolbars that the plugins can use. This would see a plugin register its toolbar so that we can now simply click on the icons for the actions the plugin provides, rather than clicking through a menuing system that can become quite deep.

I spent a bit of time yesterday afternoon mocking up an application with a tool bar to see where one goes with such a thing.

While I did this, I thought back on Alias's blog post regarding the dynamics within the Padre development team, and likely most other project out there.

The point that Alias makes is a fair one and I too would like to see others with the skills and knowledge step up and take Padre into the stratosphere with all that it can do as an editor.

However, this is always going to be hard to do. I think where are more programmers out there like me who tend to dabble, we know the language well enough to do fairly complex things when needed. We do this behind firewalls to meet the necessary outcomes to make our job at the time simpler.

But I suspect few of us feel confident enough to show our knowledge so openly.

This certainly has been my conundrum for years. I've always wanted to contribute something back to a community that has afforded me so much with systems like Linux, GNOME, Debian, Ubuntu etc etc...

How to do that with out facing public humiliation?

I'll happily admit that at times I often suffer what I call the the "blank canvas" effect, a term that a friend and I used often while studying our masters. Often the course work required the design and submission of an application that met the outcomes of the course criteria. We'd often find it hard to start, often staring at a blank screen, be it Word, or an IDE - a blank canvas, but once we finally made a start, things rolled on pretty quickly from there.

It's still like that today. While I was sitting in front of the laptop with Padre open and a blank document in front of me it clicked, that projects will always need their Alpha contributors. These are the ones who don't even see the canvas, they see the outcome and code to it. They have years or a natural talent that sees code flow from their mind to their fingers.. They can read documentation on API's and put the pieces together, and along the way show by example how something works.

They take what some of us do in a limited way and dazzle us with what more can be done when you know how.

Much of what I do really isn't the big ticket stuff, this toolbar idea I have will languish due to a lack of deep understanding of Wx, time and motivation to resolve it.

However as the Alpha's on the team go about their business, as they come and go, those of us willing to look at the things they have done will always learn a lot more as a result.

If this means that we ask questions and poke around and finally work out the fix to an annoying bug where CRTL-Tab stopped working then it's possible those of us who feel daunted with a large code base and working with very clever and dedicated people may one day themselves be an Alpha contributor.

I could start every post I make with "Why I like Padre", as to me this is the essence of why I like it. It is a struggle at times to get things like "how to make toolbars available to Plugins in Padre", but when you feel defeated with that, fixing something like that bug goes a long way in making you feel like you still make a difference.

Read and post comments | Send to a friend

Experimental Stand-alone Padre for Linux

2009-12-09T13:01:07+00:00

The last couple of days I spent building a distribution for Linux to make it very easy to start using a recent version of Padre, the Perl IDE.

On yesterdays entry of the Catalyst Advent Calendar Jonathan Yu explained the advantages and disadvantages of using Catalyst as packaged by Debian vs. installing it from CPAN. Padre has the same issues but as Padre is younger than Catalyst it lags even more in the package management systems of the various Linux distributions. While on CPAN we have v0.51 some distros still come with 0.12 I think and many people use older distros that did not have Padre at all. Padre is also more difficult to install using local::lib than Catalyst due to the need of wxWidgets.

It was also a bit emberassing that we already had a stand alone Padre package with super easy installation for both Windows and Mac OSX Snow Leopard and we don't have one for Linux.

So I built a portable perl (meaning you can put it anywhere on the system), installed Padre into it and you can already download it. (download file size 30,009,562, after unzip 119 Mb)

After downloading it do the following:

  tar xzf perl-5.10.1-xl-0.03.tar.gz

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

Note, you need to run the .sh file!

Not only that you can use Padre now for writing Perl 5 scripts, this package also comes with the Perl 6 plugin so you can use it to write Perl 6 code as well.

Perl 6 on Padre

In order to use the Perl 6 plugin, first you will have to enable it: Go to

Plugins/Plugin Manager - Select Perl 6 and click on Enable Due to a bug you will have to restart Padre for this to take effect.

Then go to

Edit/Preferences/Files and Colors Select Perl 6 as File type and Std.pm as Highlighter in order to get syntax highlighting.

Catalyst

As you could read on the Catalyst advent calendar you can use Padre for Catalyst development. In order to make that easier this version already contains the Catalyst plugin of Padre.

In order to use it you'll need to enable the plugin the same way as you did for the Perl 6 plugin and follow the instructions of Breno G. de Oliveira on Developing Catalyst Applications with Padre.

Warning and bugs

This is a very experimental version with a lot of known flaws. Please, report issues via the regular channels of Padre. (IRC, mailing list).

Known issues:

PERL5LIB

If you have PERLLIB or PERL5LIB configured (e.g. beacuse using local::lib) this installation will get confused. Of course this is not specific to this build. Any other perl would be confused. The simple work-around is to unset those variables in the shell where you launch padre.

The longer term solution is to make changes to perl itself so I'll be able to compile out the PERL5LIB and PERLLIB support from perl. This does not seem to be a hard project and I think if someone wants a bit core perl development this could be a very useful and not too big project. Nicholas Clark told me the code is in perl.c and that I should pay attention to sitecustomize.pl too.

sh-bang

All the scripts installed have an sh-bang that points to the directory where I built the package. Hences none of them will run alone. (That's the reason I had to add a separate shell script for Padre. I am not sure how can I achieve but I'd like to make sure that every script installed will know that the perl it should use is relative to where the script is located.

CPAN.pm

The CPAN client is probably not functional. It might work for pure Perl modules but if you need a compiler then there might be issues with compiler mismatch with the one I used. (I built it on Ubuntu 8.04.03)

post mortem Segmentation fault

When the Catalyst plugin is enabled, there is a segmentation fault after you shut down Padre on some of the machines we checked.

Help and feedback

Your feedback regarding this package would be really appreciated and your help with any of the above issues would be just a really nice present.

Improvements to Save Intuition in Padre

2009-12-08T23:10:52+00:00

Update: This is now working, and you can see it in action on Padre trunk

The recent Padre 0.51 contains the second phase of "Save Intuition", a set of small tweaks designed to make saving quicker and less distracting.

In the first round I discussed earlier, Padre started to guess what it thinks the file name should be for the file based on the content.

In the second round, Padre will now also try to put the save dialog into the correct directory as well.

The logic goes like this.

"New files probably belong to the same project as the file that was open just before the user triggered a File -> New action. If this is a Perl file, in a Perl project, and we're saving 'package Foo::Bar', the user probably wants to save into $project/lib/Foo. Set dialog path to that directory, if it already exists."

My hope is that this feature is subtle enough that most people won't even notice it (or if they do, it's with momentary happy surprise and after that they take it for granted).

Of course, there's gaps in this logic. What if the directory does NOT exist? In the 0.51 release, it just bails out and so falls back to the normal choice for the save directory. Creating nested directory trees without the user asking for it is risky business.

But what if I specifically want that?

If I'm making a new class for an existing project, surely I should be able to just wave my hands at Padre and say "Save in the usual place" and have that just happen without showing a dialog at all (unless Padre gets confused and can't determine what the "usual place" is).

This third phase of Save Intuition is what I plan to be my main feature for 0.52 (assuming I can get it to work). I'm hoping to take Ctrl-Shift-S for this, so it acts just like a normal save, but adding the extra shift key adds more DWIM to the process.

How to debug a Perl project

2009-12-08T19:49:04+00:00

kthakore said on padre.perlide.org" target="_blank" >Padre’s IRC channel today:

kthakore I figured out padre fail !!!!! yay! so simple. padre.perlide.org" target="_blank" >Padre couldn’t write config.yml

You may know that I always try to get people on padre.perlide.org" target="_blank" >Padre. kthakore already walked into this trap some time ago

I asked him to add a error message for this failure, but he’s a Perl SDL expert and has not much time to work on padre.perlide.org" target="_blank" >Padre, so he said

kthakore Sewi: I have no clue where this is please point me to the right direction.

Here is a walk we did together looking for the source of the problem (or: the problem in the source):

Preparing the workspace

My padre.perlide.org" target="_blank" >Padre is running with directory and function-list panels enabled which really speeds up work.

Looking at the padre.perlide.org" target="_blank" >Padre source…

…shows a padre.perlide.org/trac/browser/trunk/padre.perlide.org" target="_blank" >Padre/lib/padre.perlide.org" target="_blank" >Padre/Config.pm">Config.pm module. It might be a good start – we’re talking about config problems.

It has few methods (shown on the right side in the function list panel) even if it’s a very big file. One of the methods is called write and there is no other one with a similar name. A double click on the method name jumps to it’s declaration.

The write method is unfriendly – it doesn’t show clearly what it does: Something with a “Human” and a “Host” config, but the directory panel might help us: There is a “Config” directory and by clicking on the icon in front of the Config directory, the browser shows the content. Oh, there are also Human.pm and Host.pm.

Human.pm uses some YAML module which sounds good – our problem was config.yml. This module has a write method, too.

Here we are. We found the place where the config is being written by jumping through the source using padre.perlide.org" target="_blank" >Padres panels.

An open file dialog could do the same as the directory panel, but it’s less visible and the structure usually gets lost.

Searching for “sub ” through the files would also work – but the functions list shows the list much faster and you could even see the write method accidently even if you don’t search for it.

The hardest part is the start. Where to start, in a project like padre.perlide.org" target="_blank" >Padre which has megabytes of source code. Another idea was the filename: “config.yml” must be defined somewhere. Even if it’s being put into a constant or variable, the constant or variable must be used somewhere.

Debugging well-structured Perl projects usually means jumping through files, looking for references or referenced things, following method calls and multi-level @ISA definitions, but you’ll get a good picture of your problem and the reasons soon.

kthakore found the right place within few minutes and is creating a fix for the problem while I’m writing these lines…

Template::Tiny 0.02 - 40kb for [%- IF foo.bar.2.method %]

2009-12-08T14:17:27+00:00

Second release, and I now have everything I need for doing basic file construction in Padre.

I've got whitespace control in tags via explicit chomping such as [%- foo -%].

The basic recursive expression resolver is done for things like [% hashkey.1.methodname %] and works for arrays, hashes and objects. The resolver also now has the same kind of exception-tolerant, warning-squashing behaviour that Template Toolkit does.

And finally I've added the three simplest and most basic control structures, IF, ELSE and UNLESS.

All this cost about an extra 15-20k of RAM, for around 40kb total so far (with maybe 5-10kb of recoverable fat). But note that I don't yet have support for files, so there's some fairly chunky costs still to come (especially because I can't use things like File::Spec).

Now this is where things get a little more interesting, because the real skill in creating most ::Tiny modules are about selecting the really critical compromises.

For Template::Tiny, the key compromise looks to be stash immutability. If you can be sure that the stash will never mutate (and if you don't allow things to collide with the stash names) you no longer need to process the template elements in order from top to bottom. Which means you don't need to compile the template into intermediate Perl code, the templates won't be turing complete, and you can just evaluate it directly from template to finished text via a series of regex passes.

Of course, now I have some other problems, such as doing a fairly complex and recursive regex matching exercise using only features available in Perl 5.005 (and in very little code, and without resorting to things like Text::Balanced that are 1000 lines of code).

So if you have some serious regex-fu, I'd love some help because my other option is trawling around in Text::Balanced-type Damiancode for clues :)

The Padre 0.51 story

2009-12-07T17:08:29+00:00

Finally,

http://padre.perlide.org" target="_blank" >Padre 0.51 was released last weekend.

It took longer than planned to make this release for various reasons. http://padre.perlide.org" target="_blank" >Padre hat some kind of code silence during the last weeks since 0.50. It was the worst “code silence” I noticed since I first tried http://padre.perlide.org" target="_blank" >Padre – we even had some days without one commit this time!

While 0.51 was coming up, many people got time to work on http://padre.perlide.org" target="_blank" >Padre again and we got a good release with new features and bugfixes.

Special thanks to Peter

Lavender (waxhead) for becoming release manager for 0.51. He managed to publish the release while being busy with other work, a kids birthday and really strange Perl::Critic problems. He did the official 0.51 promotion blog post. Don’t miss it.

http://padre.perlide.org" target="_blank" >Padre news

Here are some (few) lines from the changelog for 0.51:

Find all option showing all matches in bottom tab (CODE4PAY)
Improved “Find Method Declaration” based on perltags (SMUELLER)
XS (perlapi) calltips based on the perlapi of 5.10.1 by default. Can be configured to show the perlapi of any release of perl back to 5.6.0 if http://padre.perlide.org" target="_blank" >Padre::Plugin::XS is installed. (SMUELLER)
Fixed a number of search/replace related bugs (ADAMK)
Upgraded tracing to new http://padre.perlide.org" target="_blank" >Padre::Debug that compiles out when not being used. (ADAMK)

Many more are listed in Peter’s blog and the full list could be found in the http://padre.perlide.org/trac/browser/trunk/http://padre.perlide.org" target="_blank" >Padre/Changes?rev=9467">0.51 changelog.

I was really happy to see Adam Kennedy, Steffen Müller and Ahmad M. Zawawi back on the list of regular committers. Ahmad promised “it is gonna be something special before the end of the year…” on IRC lately.

Upcoming

It looks like http://padre.perlide.org" target="_blank" >Padre 0.52 will be a big bugfixing release. If you don’t want to wait, feel free to look at the http://padre.perlide.org/trac/browser/trunk/http://padre.perlide.org" target="_blank" >Padre/Changes">current changelog.

Please help!

http://padre.perlide.org" target="_blank" >Padre has a strange problem filed as http://padre.perlide.org/trac/ticket/750">ticket #750: Ctrl-Tab and Ctrl-Shift-Tab don’t work anymore on Ubuntu and maybe other Linux versions. I suspect some Wx issue but I’m no Wx guy at all. If you got any idea about this, please come to the http://padre.perlide.org" target="_blank" >Padre IRC channel #http://padre.perlide.org" target="_blank" >Padre on irc.perl.org or add your ideas to http://padre.perlide.org/trac/ticket/750">the ticket. Please also add your experience to it if you’re using a OS not mentioned there.

Template::Tiny 0.01 - Request for features

2009-12-06T20:54:37+00:00

For a few years now, I've been thinking about doing a ::Tiny job on the Template Toolkit. But it was never quite a big enough problem to be worthwhile, because Template.pm doesn't have any particularly horrendous dependencies and always seems like a reasonable way to spend 2.2meg of RAM.

But for Padre 2.2meg is a hell of a lot to spend, because of the multiplier effect of threading. Template.pm is geared much more towards being a load focal point in a website or a content generation system, it is just that much too complex when used as a utility class for simple code generation (which is what I want to use it for in Padre).

So Template::Tiny is happening, and I've just uploaded the first release which support pretty much nothing other than basic [% foo %] insertions from a single variable HASH.

Just adding support for tags, plus a tiny bit of boilerplate, has memory consumption at around 24k of RAM consumed out of my anticipated budget of around 100k.

Before I go any further, I'd like to ask you guys what you consider to be the essential TT features that you would want to retain even in a light weight ::Tiny context.

For me, this includes the three basic array, hash and object foo.bar usages, and IF blocks (and potentially simple | filters).

What do you want?

Padre 0.51 is on the way to CPAN.

2009-12-06T10:05:08+00:00

I'm a first time release manager.. EVER for ANYTHING!!!

I feel the responsibility for making sure I release something that works quite a bit and ended up taking rather tentative steps towards the final event.

I have to say though, that the real hard work has been made easier with the build and release tools the Padre developers have now got in place. By far the most difficult part of the process was getting to a point with a computer that I owned that had everything I needed to create a release.

For some reason I kept getting a lot of critic errors that others weren't seeing on my preferred dev laptop.

It's got problems with it's wireless anyway, so in the end it made sense to get the other laptop sorted out and release off it.

Going through the process of installing Padre on the laptop that has never had it installed showed just how tricky something like this can be sometimes. It really deserves some decent documentation around it. Some of the errors that get reported in the tests really don't help out that much when you first read them.

Anyway, without more ado, I'm proud to announce that Padre 0.51 is only it's way to CPAN.

Of course there are plenty of people who make Padre what it is. In this release some highlights:

    - Find all option showing all matches in bottom tab (CODE4PAY)
    - Improved FTP error handling (SEWI)
    - Open URLs from command line (SEWI)
    - Fixed ticket #654: Lexical Rename of Variable - Can't highlight the
      whole variable (PATRICKAS)
    - Improved "Find Method Declaration" based on perltags (SMUELLER)
    - Basic XS-Document support as needed for the full monty in a plugin (SMUELLER)
    - XS (perlapi) calltips based on the perlapi of 5.10.1
      by default. Can be configured to show the perlapi of any release of
      perl back to 5.6.0 if Padre::Plugin::XS is installed. (SMUELLER)
    - Fixed a number of search/replace related bugs (ADAMK)
    - Fixed ticket #421: crash: no documents, F3/F4 (AZAWAWI)
    - Fixed ticket #678: VACUUM the configuration database at shutdown
      to keep it small and fast (AZAWAWI)
    - Styles now allow configuring of the selected text (ADAMK)
    - Upgraded tracing to new Padre::Debug that compiles out when not
      being used. (ADAMK)

Of course this is a selection of the changes in this release. See the Changes file for the complete list.

I'd like to thank every one on the #padre channel for being there while I tried to get a system built that would allow me to do the release.

I hope with this now in place, we can return to a more regular release cycle.

Read and post comments | Send to a friend

Promoting Padre using Social networks

2009-12-05T23:58:37+00:00

Padre is getting better by every release, but many people have not heard of it yet. It needs some promotion so I am wondering which one of the social networks and other tools could be used for this?

Blogging about it certainly helps. Submitting those posts to Reddit also has its impact and there are number of other ways. In any case it is you who can make the difference.

If you are using Padre already or if you think the Perl world would be better off if people used a Perl aware editor instead of Notepad++ and other generic programmers editors or even if you just think that the whole idea of building an open source IDE for Perl in Perl is a good cause, consider spending a few minutes in helping promoting it.

Some of the things you can do:

Mark yourself as a user of Padre on Ohloh (there are 24 users currently).

Subscribe to Padre on Freshmeat (there are now 16 subscriptions).

Join the Padre group on LinkedIn (there are currently 17 members).

I recently setup a Padre group on Facebook (there is 1 member now :-). and Padre page of Facebook where you can become a fan. (thanks to Bogdan Lucaciu)

I even setup a Twitter account for Padre you can follow.

I tried to search for a Perl IDE on Google. Padre was in 8th place with the perlide.org site being number 5. It is not bad but moving up the ladder would be nice. So if you have a web site, consider linking to Padre or to perlide.org from there.

Just to give it a shot I tried to search for Perl IDE on Bing as well. It shows perlide.org on 3rd place and on the 9th place but padre.perlide.org is only number 15.

After doing all the above, let me know, what other ways do you think Padre could be promoted?

Some interesting group dynamics in Padre

2009-11-30T00:23:34+00:00

Padre continues to move forwards in leaps and bounds, with most of the recent progress made by the ever-enthusiastic Sebastian Willing.

However, over the last year I've noticed an interesting effect in the pattern of volunteering.

Padre seems to go through cycles with "Alpha" contributors. These are the people that are doing huge numbers of commits, and moving things forward rapidly. However, as an Alpha contributor picks up speed we seem to see other contributors start to fall back and go quiet.

It's almost as if people are happy as long as Padre keeps improving and don't feel like Padre needs their help, so they are just getting out the way of the person doing all the heavy lifting.

Of course, last Christmas/New Years when I was the Alpha contributor, this was also because I was breaking major APIs every week or so. Unless you had time to deal with the breakages, you more or less had to just stay out the way.

It's when the current Alpha runs out of steam or time or attention and their commits fall back to low levels that we see the other contributors come out of their shells and start to commit a bit more.

Sometimes it just seems like co-incidence. I've been horribly busy in November until today, and Stephen Mueller has been out and about doing his Physics thing, so we both haven't been able to do much until very recently.

From a productivity point of view, however, I do worry a little about the Alpha effect. From my time as Alpha, I know I was a little disconcerted that I seemed to be the only one doing anything and nobody else seemed to be committing.

Of course, within two weeks of my burning out and slowing, everyone else started to pick up again. But I wish we had a way to support the Alphas a bit more, so they didn't feel quite so alone during their sprints and had more encouragement (in the form of other people lifting their game as well)