use Perl

I said

and today I found this blog post: Do you still use the MessageBox API in your Windows Service? (Or do you display any type of User Interface?)

and it says:

Starting with Windows Vista and above, user interfaces generated by Windows services can’t be seen. And even worst, your service could be stuck waiting for some user input that the user cannot give as she does not see anything!

It goes on to give a generic solution (plus a simple solution for just a messagebox), but it's anything but trivial.

But I was right to be wary.

And I'm not sure that this solution will work on a Windows earlier than Vista. At worst, you might have to hack in 2 interfaces, for multiple versions of Windows.

As you said

do you even need a GUI toolkit? It seems to me like a plain MessageBox API call is all you need.

That is, unless you want the script to continue running while the message is shown. In that case, you could set up a simple window with The GUI Loft. Oldie, but probably good enough.

And I've never seen a service with a GUI, I'm not sure if it will behave nicely.

Just like that one text editor...

I often use an idiom that I try to fetch an item, and if successful I want to do something with it; if not successful, the code returns undef (false). Typically, the code goes something like this:

if(my $item = get_item(@params)) {
    # do something with $item
    print $item->{text};
}

but this text editor complains about it, stating, in a dialog box:

a single = in a conditional is usually a typo, use == or eq to compare.
Do you want to continue?

every. single. time. I run that script.

Goddamnit, I know already. It's not a typo. Just get out of my way already, and let me do as I please.

That text editor is Padre.

For Strawberry Perl, and Padre, I use a custom entry in the Start Menu, which technically is a shortcut (*.LNK file). For example, for Padre the command line in the shortcut file was:

C:\WINDOWS\system32\cmd.exe /c PATH=c:\strawberry\perl\bin;c:\strawberry\c\bin;%PATH% && padre

Likewise, the command line for my Strawberry shell was:

Wow, this looks incredibly fun. Things like this make me actually want to play with Perl6 — which, admittedly, is something that does not happen too often.

I don't see why one shouldn't be allowed to do this, as it's not really different from plain calling

BEGIN {
     &sick;   # or sick();
}

As part of the source hasn't been compiled (or parsed) yet, you can only jump — or call — backwards.

Interesting approach — if only it worked... It turns out not to be so easy.

I tried the "experimental" "Padre Stand Alone for Linux", but it immediately died, complaining about an incompatibility between Wx and libstdc++.so ("GLIBCXX_3.4.9 not found").

Anyway... Do you see this approach as a solution for all big projects in Perl? Building all these binary distros seems like a lot of work to me. Plus, with several projects, you get a lot of separate file trees, with possibly a lot of overlap. That may be a bit of a shame, depending on how you look at it.

I recently thought of installing Padre on the most recent CentOS (which, in case you didn't know, is a community supported enterprise version of Red Hat Linux). The huge number of modules that need an upgrade is discouraging: it wants to upgrade 24 modules (and install 81 more), even after I already installed Wx.

The main problem I have with that is that I don't want to change anything in the system Perl, as this is contrary to the spirit of CentOS: don't upgrade anything that is stable, as the upgrade might break stuff.

What I want is to "upgrade" these modules only for Padre, i.e. locally.

Now what dagolden already mentioned would easily solve that problem: CPAN should be set up to install locally, i.e; not modifying the system libraries, by default, or at the very least, provide a painless option to do so.Having to mess with arguments for Makefile.PL with sometimes dubious, or at the very least, unpredictable results, is not the best imaginable solution.

p.s. I recently upgraded Padre to the newest version on Windows, and again, it wanted to upgrade tens of modules. Is that really necessary? It's so bad, eh, there are so many of them that CPAN almost chokes, that I almost skipped the upgrade.

Eh, no, you don't have to patch perl.exe. Instead, put it in a module. Just like diagnostics does nothing but explaining warnings and errors better.

You can load this module on the command line using -M, or you could set an environment variable like PERL5LIB, so it gets used in every Perl script that gets run from the batch file.

Earlier today, moritz uploaded a new module, Encode::Repair, to CPAN, which has fixing this kind of trouble in mind. But 5 times? That's a bit steep...

One major problem we have had in the past is with Scalar::Util, which has 2 modes: XS mode, and PP mode. The latter did not include the functionality to create weak references, and it was the version that PPM installed. Often, that was precisely the functionality we needed the module for... Yet, the version number of Scalar::Util was the same for both... Just requiring a high enough version number for the module did not do any good.

Can your extension detect that? "We need Scalar::Util so and so and it has to include weaken"?

Thanks for cross-posting between blogs.perl.org and use.perl.org. I still have a soft spot for use.perl.org and I'm still not quite following blogs.perl.org closely, so it's much appreciated, even though I guess it's not making your life easier. Probably quite the contrary.

Here's another thing that I don't remember actually having seen on an editor yet — or at least, on a free or cheap editor — I don't actually know if Kephra does: let the tool buttons and menu entries depend on the type of file.

It removes clutter if you don't show any menu entries that don't make sense on this type of file.

For example, if you have the Java compiler (javac) defined as a tool, it makes no sense to show it as an option for a Perl script. And vice versa: show perl only as a tool for Perl scripts and modules, but not for Java source files, or for HTML.

That implies making the context menus very dynamic, as they should be both dependent on file type, and be user configurable as well. This may be a bit of a technical challenge.

And filters. I may not imagine the bad things that would happen if item.name and/or item.value contain text with substrings that are meaningful as HTML markup.

Besides, for a template system I want to be able to insert text between every listed item, but not after the final item; just like join does in Perl, but then with a loop-ish instead of a functional syntax. (Just being able to test for the last iteration in the loop, would do the trick.)

I don't remember the syntax TT2 uses for such a feature, but I'm pretty sure it can do it.

This is not working with incomplete sample code, is it? Code that does not include the necessary (but trivial) use Foo::Bar lines, or object instantiation (Foo::Bar->new)?

Just because code is incomplete, doesn't mean that it's wrong.

And adding redundant code is not making examples clearer.