Opened 10 years ago

Closed 10 years ago

#796 closed defect (fixed)

Padre Stand alone does not start on Windows after installation

Reported by: szabgab Owned by: azawawi
Priority: blocker Milestone:
Component: External dependency Version: 0.50
Keywords: Cc: CSJewell


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.

Change History (3)

comment:1 Changed 10 years ago by adamk

  • Owner set to adamk
  • Status changed from new to accepted

31<Alias>30 Right!
>30 I think I know the root cause of the padre.exe bug
31<Alias>30 It goes through a normal boot up sequence
>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
>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
>30 And then immediately starts loading DBI's
31<Alias>30 So if I had to guess, it's that IPC::Run3 fails to launch the scripts when run under padre.exe
>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
>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@ has joined #padre
>30 OK
31<Alias>30 So the difference between padre.exe vs padre.bat is that padre.bat runs as perl.exe, and padre.exe runs it as wperl.exe
18<PerlJam?>18 Alias++ (that sounds rightish to me)
>30 oh, shite
31<Alias>30 I know what it is
>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
>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
>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"
>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
>30 2. Porting ORLite::Migrate to use something like Padre::Probe instead of Probe::Perl
31<Alias>30 3. Taking over Probe::Perl
>30 Or something in the general vicinity of those three
31<Alias>30 Anyone know what bug number the padre.exe thing is?

comment:2 Changed 10 years ago by adamk

  • Component changed from downstream to External dependency
  • Owner changed from adamk to azawawi
  • Status changed from accepted to assigned

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;

comment:3 Changed 10 years ago by adamk

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.