perlce-user

RE: [perlce-user] PerlCE and "real" console

[Konovalov, V. <vko...@sp...>]

> sorry if this question appeared before, I'm new to the list 
> and didn't 
> find anything on the FAQ/ML archive/etc.

in ideal world - this eventually grow throughought WiKi
In real world - it will not be done until someone will do.
But, being even more realistic - information will eventually grow indeed.

> 
> is it possible to have PerlCE _without_ the fake console window, but 
> with _real_ STDIN/STDOUT/STDERR hooks?
> 
> as probably many of you did, I have installed PocketConsole from 
> http://www.symbolictools.de/ and Microsoft's CMD.exe on my 
> iPAQ: so now 
> I have a command prompt. but the current PerlCE, launched from there, 
> still pops up its own window and place its output in 
> /perl_(stdout|stderr|stdin).txt.

its own window will not show up if -nocolsole option is used
I am not exactly sure for spelling, but I will be more precise after RTFSing
a bit.

As another point, CMD.exe is not supported on (very) old WinCEs


> 
> what I would like to have is a Perl executable really 
> interacting with 
> the CLI, as on any regular desktop computer.

IMO,  using PerlIDE is probably a way to make sutuation easier.

> 
> I tried to investigate the issue by looking at the code, but 
> it seems to 
> me that this "fake-console" is a feature of celib, which 
> can't be avoided.

it can be avoided but this is not largest problem, unfortunately :)

RE: [perlce-user] PerlCE and "real" console

[Konovalov, V. <vko...@sp...>]

> > As another point, CMD.exe is not supported on (very) old WinCEs
> 
> I know and I understand, but since it is supported on (most commonly 
> used, I guess) non-very-old PocketPC devices, it makes lot of 
> sense to 
> have proper CMD.exe interaction. at least as an option, 
> either at build 
> time or at runtime.

I also think so.
More to say, I think it will be better when PerlCE port will be greatly
reorganized, may be dropping obsolete configs and agreeing on supported
ones...

Yet ruby on WinCE could be happily used from CMD.exe.
Don't know of other languages.

It was in my plans to look closer but, once again, my weak efforts were just
not enough.
Also, I asked for an advice in wince-developers ML but no good from that
side either...


> > IMO,  using PerlIDE is probably a way to make sutuation easier.
> 
> hrm. not quite. I mean, PerlIDE is fine, but I _do_ want 
> PerlCE to be a 
> command line friendly executable. the biggest use I see for Perl on a 

....

I agree with you.


> on the other hand (and on a completely unrelated topic) "real world" 
> applications on a PDA need a GUI very badly. for example, I think 
> porting Win32::GUI on PerlCE should not be terribly hard. at least, 
> should be more light-weight than Perl/Tk. and we all know 
> that weight is 
> an issue here :-)

You're right, and having Win32::GUI will be a real advantage there...

But Perl/Tk is very special on WinCE: ported by Rainer Keuchel is only older
version without unicode, which is noticeable long to start, but another
approach makes this situation considerable better. I use Tcl::Tk module, so
things are more lightweight. See URL at
http://perlce.sourceforge.net/cgi-bin/perlce-tcltkce-wiki.pl?Happy_Screensho
ts for such screenshot examples

Of course native widgets will help.


> 
> > it can be avoided but this is not largest problem, unfortunately :)
> 
> so let's talk about the largest problems first, and my 
> problem then :-)

One is
http://perlce.sourceforge.net/cgi-bin/perlce-tcltkce-wiki.pl?Be_Aware,_WinCE
,_PocketPC_Have_Serious_Design_Limitations which most often appears on
devices with GSM radio stack, when many processes are always exist to
support a phone.  

Another one is - probably latest patches to WinCE made some bad changes and
now script often sporadically exits with a message "Exit code 14".

Probably my bad :(

> 
> seriously, I have a good knowledge of the Perl codebase, internals, 
> build process, etc. as well as good experience on the Win32 
> platform. I 
> have very little spare time at hand, but if there's something 
> I can do 
> for PerlCE, just let me know. eventually, post a todolist on the wiki 
> and I'll see if I can do something.

I have no single doubts about your excellent experience in Perl internals,
externals and surrounding environment!

In case you'll make additions - of course they will be greatly appreciated
by following PerlCE users.

When I did my changes, I sent patches to p5p. I think it is still reasonable
to do same way. There's no WinCE pumpking.

Inserting all kind of information to Wiki  - I am sure all people who have
usefull things to say - they should share those useful bits.

Best regards,
Vadim.

Re: [perlce-user] PerlCE and "real" console

[Aldo C. <da...@pe...>]

Konovalov, Vadim wrote:
> It was in my plans to look closer but, once again, my weak efforts were just
> not enough.
> Also, I asked for an advice in wince-developers ML but no good from that
> side either...

I know the feeling :-)

> You're right, and having Win32::GUI will be a real advantage there...
> 
> But Perl/Tk is very special on WinCE: ported by Rainer Keuchel is only older
> version without unicode, which is noticeable long to start, but another
> approach makes this situation considerable better. I use Tcl::Tk module, so
> things are more lightweight. See URL at
> http://perlce.sourceforge.net/cgi-bin/perlce-tcltkce-wiki.pl?Happy_Screensho
> ts for such screenshot examples

by "weight" I mean mostly "size". the Perl tree on my iPAQ is 10.68 mb, 
which means that I must put it on a Storage Card (not a big deal, as I 
have an SD card that fits inside the iPAQ main body; but my first iPAQ 
only had a Compact Flash jacket, which made it bigger :-). I guess the 
Perl/Tk distribution weights some mb more. compiling  Win32::GUI for the 
CE platform shouldn't (I hope) add much more to the desktop version, 
which actually is ~800kb DLL. but I don't have time to work on it right 
now, so this isn't really an issue.

> One is
> http://perlce.sourceforge.net/cgi-bin/perlce-tcltkce-wiki.pl?Be_Aware,_WinCE
> ,_PocketPC_Have_Serious_Design_Limitations which most often appears on
> devices with GSM radio stack, when many processes are always exist to
> support a phone.  

I don't see how this one is related to PerlCE (more than any other WinCE 
program, I mean). is there any special reason to consider this as a 
problem for Perl? and if this is a design limitation, I think there's 
very little to do, except maybe sign a petition and send it to Microsoft :-)

> Another one is - probably latest patches to WinCE made some bad changes and
> now script often sporadically exits with a message "Exit code 14".
> 
> Probably my bad :(

well, right now I'm trying to run the whole perl test suite on my iPAQ. 
should take quite a while, but, well, while I'm at the office the iPAQ 
sits on its cradle doing nothing but sync most of the time; battery 
time, at least, is not a problem :-)

I encountered some problems with @INC, but if I come up with something, 
I will post the results and write an how-to for the wiki.

I hope that running the test suite should help isolate problems.

> When I did my changes, I sent patches to p5p. I think it is still reasonable
> to do same way. There's no WinCE pumpking.

but maybe a CVS repository on sourceforge could help, don't you think?

> Inserting all kind of information to Wiki  - I am sure all people who have
> usefull things to say - they should share those useful bits.

I will, definitely.

cheers,
Aldo

RE: [perlce-user] PerlCE and "real" console

[Konovalov, V. <vko...@sp...>]

> > You're right, and having Win32::GUI will be a real 
> advantage there...

...

> 
> by "weight" I mean mostly "size". the Perl tree on my iPAQ is 
> 10.68 mb, 

That number could be greatly reduced.
Not only you can freely delete unused PMs.
I had few working experiments with Archive::Zip and some modules hidden
inside zip archive... but this hase little in common with PerlCE... Also
with many lib files on SD there is no problem with several megabytes more or
less...


> guess the 
> Perl/Tk distribution weights some mb more. compiling  
> Win32::GUI for the 
> CE platform shouldn't (I hope) add much more to the desktop version, 
> which actually is ~800kb DLL. but I don't have time to work 
> on it right 
> now, so this isn't really an issue.

Well, size is one aspect of 'lightweight', but startup speed is another one.
Rainer Keuchel notes that his build of Perl/Tk on WinCE is rather slow.
Obviously, he spend some efforts on profiling


> ,_PocketPC_Have_Serious_Design_Limitations which most often appears on
> devices with GSM radio stack, when many processes are always exist to
> support a phone.  

> I don't see how this one is related to PerlCE (more than any other WinCE 
> program, I mean). is there any special reason to consider this as a 
> problem for Perl?

you're right: this has nothing to do with Perl.
But I can't resist explaining when after upgrading to much more powerful
device I got much weaker Perl capabilities...


> > Another one is - probably latest patches to WinCE made some bad changes
and
> > now script often sporadically exits with a message "Exit code 14".
> > 
> > Probably my bad :(
> 
> well, right now I'm trying to run the whole perl test suite on my iPAQ. 
> should take quite a while, but, well, while I'm at the office the iPAQ 
> sits on its cradle doing nothing but sync most of the time; battery 
> time, at least, is not a problem :-)
> 
> I encountered some problems with @INC, but if I come up with something, 
> I will post the results and write an how-to for the wiki.
> 
> I hope that running the test suite should help isolate problems.

sounds very promising.

> 
> > When I did my changes, I sent patches to p5p. I think it is still
reasonable
> > to do same way. There's no WinCE pumpking.
> 
> but maybe a CVS repository on sourceforge could help, don't you think?

I will setup CVS this weekend, then.
If you will be kind to participate perlce project on SF - I'll give you all
permissions to that, just say me your user ID.

If development will have progress, then it will be reasonable to create
mailing list on perl.org: usually they create such lists quite quick.
(Mailing list for users of Tcl::Tk module was kindly created within a day!)

Best regards,
Vadim.

RE: [perlce-user] PerlCE and "real" console

[Konovalov, V. <vko...@sp...>]

> > by "weight" I mean mostly "size". the Perl tree on my iPAQ is 
> > 10.68 mb, 
> 
> That number could be greatly reduced.
> Not only you can freely delete unused PMs.
> I had few working experiments with Archive::Zip and some 
> modules hidden
> inside zip archive... but this hase little in common with 
> PerlCE... Also
> with many lib files on SD there is no problem with several 
> megabytes more or
> less...

I must correct confusing place before anyone confused:

I mean I tried that approach with PMs inside ZIP succesfully on PerlCE

by "little in common with perlCE" I meant that it does not closely related
to WinCE problems

Vadim.

Re: [perlce-user] PerlCE and "real" console

[Aldo C. <da...@pe...>]

Konovalov, Vadim wrote:
> its own window will not show up if -nocolsole option is used
> I am not exactly sure for spelling, but I will be more precise after RTFSing
> a bit.

you're right, I didn't noticed (the option is --noconsole, BTW). this is 
fine, but still output is placed in /perl_stdout.txt, not emitted on the 
command line.

> As another point, CMD.exe is not supported on (very) old WinCEs

I know and I understand, but since it is supported on (most commonly 
used, I guess) non-very-old PocketPC devices, it makes lot of sense to 
have proper CMD.exe interaction. at least as an option, either at build 
time or at runtime.

> IMO,  using PerlIDE is probably a way to make sutuation easier.

hrm. not quite. I mean, PerlIDE is fine, but I _do_ want PerlCE to be a 
command line friendly executable. the biggest use I see for Perl on a 
little device, except for prototyping algorithms, is to script small 
sydadmin tasks (such as backing up important files on a storage card, 
for example), for which a command line interface is much, much better 
than using PerlIDE.

on the other hand (and on a completely unrelated topic) "real world" 
applications on a PDA need a GUI very badly. for example, I think 
porting Win32::GUI on PerlCE should not be terribly hard. at least, 
should be more light-weight than Perl/Tk. and we all know that weight is 
an issue here :-)

> it can be avoided but this is not largest problem, unfortunately :)

so let's talk about the largest problems first, and my problem then :-)

seriously, I have a good knowledge of the Perl codebase, internals, 
build process, etc. as well as good experience on the Win32 platform. I 
have very little spare time at hand, but if there's something I can do 
for PerlCE, just let me know. eventually, post a todolist on the wiki 
and I'll see if I can do something.

cheers,
Aldo