Padre Stand alone does not start on Windows after installation

[szabgab]

There seems to be a bug with the Padre Stand Alone for Windows (v 0.50 ) that prevents padre.exe from running after the installation.
The work around is to run padre.bat once - then shut down Padre.
The subsequent execution of padre.exe will already work.

[adamk]

31<Alias>30 Right!
31<Alias>30 I think I know the root cause of the padre.exe bug
31<Alias>30 It goes through a normal boot up sequence
31<Alias>30 Creates the directory structure, and an empty config.db
31<Alias>30 Then it queries C:\strawberry\perl\site\lib\auto\share\dist\Padre\timeline
31<Alias>30 Which would mean it's seen that the new config.db is too old
31<Alias>30 Then it writes some stuff to a temp file, which I'm guessing is the IPC::Run3 pipe emulation
31<Alias>30 And then immediately starts loading DBI's DESTROY.al
31<Alias>30 So if I had to guess, it's that IPC::Run3 fails to launch the migrate.pl scripts when run under padre.exe
31<Alias>30 Which freaks it out
31<Alias>30 The reason you have to run .bat first, is that once the normal padre.bat run has gotten the config.db up to date and to the correct version, it doesn't need to run any scripts, which means it can't hit that bug, and so Padre runs
31<Alias>30 My guess would be, if we added a new migrate script, padre.exe would stop working for the new install to
31<Alias>30 too
<-- 23marcela has quit (23Remote host closed the connection23)
--> 19cognominal (~cognomina@82.67.232.89) has joined #padre
31<Alias>30 OK
31<Alias>30 So the difference between padre.exe vs padre.bat is that padre.bat runs migrate-1.pl as perl.exe, and padre.exe runs it as wperl.exe
18<PerlJam?>18 Alias++ (that sounds rightish to me)
31<Alias>30 oh, shite
31<Alias>30 I know what it is
31<Alias>30 So we had some issues with wperl.exe and running stuff
31<Alias>30 And we realised we needed a starter way of finding "perl" than Probe::Perl could handle
31<Alias>30 So we wrote Padre::Perl as a smarter replacement that knew when to switch between wperl and perl
31<Alias>30 UNFORTUNATELY, ORLite::Migrate doesn't have the luxury of using such a thing
31<Alias>30 And so it's called the regular Probe::Perl
31<Alias>30 Which is returning wperl.exe instead of "one with a working stdout"
31<Alias>30 So, solutions involve
31<Alias>30 1. Running migrate scripts in ORLite::Migrate in a different way, such that it doesn't need a stdout or stderr
31<Alias>30 2. Porting ORLite::Migrate to use something like Padre::Probe instead of Probe::Perl
31<Alias>30 3. Taking over Probe::Perl
31<Alias>30 Or something in the general vicinity of those three
31<Alias>30 Anyone know what bug number the padre.exe thing is?

[adamk]

Even though it now uses perl.exe instead of wperl.exe, it is still failing.

The specific line that behaves differently in padre.bat and padre.exe is

open STDOUT_SAVE, ">&STDOUT" or croak "run3(): $! saving STDOUT" if defined $out_fh;

[adamk]

This is tentatively fixed now, but doesn't answer the issue of why there's no STDOUT under padre.exe. This is going to cause serious ongoing issues unless we sort it out.

But the most visible problem with this issue is now resolved.