Yes, Term::ReadLine::Perl also works for windows. The catch is getting a GUI window that supports readline. One approach might be to use a VT102 terminal emulator module to provided the various escape sequence support for most readline control
Another option would be to implement the features directly for the GUI shell but I'm not sure if there would be compatability issues from that "special" term type and generic readline libraries... --Chris On Tue, Jan 24, 2012 at 11:10 AM, Joel Berger <[email protected]> wrote: > I am the new maintainer of the Zoidberg Perl-based shell. Once I track > down the windows problems it might be just the ticket. Even if that > doesn't work, Zoidberg forked out its readline module called > Term::ReadLine::Zoid. It has the nice feature of allowing multiline > editing, and the CPANtesters results show that it works on W$. > > Joel > > > > https://metacpan.org/module/Term::ReadLine::Zoid > > On Tue, Jan 24, 2012 at 9:45 AM, Chris Marshall <[email protected]> > wrote: >> It is a plus that more PDL developers and perl coders >> are becoming aware of the issue. An implementation >> of our own could be better if we make a simple, general >> framework. We could implement a nice, extensible GUI >> REPL that would work with and without the GUI. >> >> It would be useful not only for PDL but also for other Perl >> modules that face the win32 blockade. A possible >> approach would be one based on OpenGL and some type >> of Term::ReadLine that could connect generically to a >> set of INPUT/OUTPUT/ERROR handles. >> >> --Chris >> >> On Tue, Jan 24, 2012 at 10:36 AM, Joel Berger <[email protected]> >> wrote: >>> Darn, I really thought it ran on W$! >>> >>> Oh well, I always do try to think cross-platform, I made a false >>> assumption in this case. I know (*think*) that Plack is x-platform, so >>> I thought this would go. NM. >>> >>> Joel >>> >>> On Tue, Jan 24, 2012 at 9:31 AM, Chris Marshall <[email protected]> >>> wrote: >>>> Yes, because it is *not* totally cross-platform and >>>> I'll let you guess which OS it doesn't work on (the >>>> problem is IO::Pty support). >>>> >>>> The unix-only development bias for perl modules is >>>> a real drag in trying to get win32 perl stuff working. >>>> >>>> It is seeming more and more that the only fix >>>> is going to be doing our own implementation. :-( >>>> I know it is possible because IPython works on >>>> win32.... >>>> >>>> --Chris >>>> >>>> On Tue, Jan 24, 2012 at 10:13 AM, Joel Berger <[email protected]> >>>> wrote: >>>>> Any reason not to use showmetheshell and Plack to make a local >>>>> in-browser pdl2 shell? I could mock that up in just a few hours and it >>>>> would be totally cross-platform. >>>>> >>>>> Joel >>>>> >>>>> https://github.com/vti/showmetheshell >>>>> >>>>> On Tue, Jan 24, 2012 at 8:38 AM, Chris Marshall <[email protected]> >>>>> wrote: >>>>>> I would like to see a GUI REPL that could tie into >>>>>> the existing pdl2 or perldl shells. Basically, we >>>>>> would need something that would support Term::ReadLine >>>>>> and connect to STDIN, STDOUT, and STDERR and would >>>>>> work with win32 from the start. >>>>>> >>>>>> Cheers, >>>>>> Chris >>>>>> >>>>>> On Tue, Jan 24, 2012 at 8:25 AM, David Mertens >>>>>> <[email protected]> wrote: >>>>>>> Mark, >>>>>>> >>>>>>> You go for the command-line option, I'll work on packaging my gui repl. >>>>>>> But >>>>>>> do NOT send the resulting files to the mailing lists. They will be huge. >>>>>>> Create a project on sourceforge.net or github.com and post links to the >>>>>>> list >>>>>>> instead. >>>>>>> >>>>>>> I'm looking forward to working this! >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On Jan 24, 2012 4:47 AM, "MARK BAKER" <[email protected]> wrote: >>>>>>>> >>>>>>>> So what we need to do is get a person from Windows , Linux , Mac >>>>>>>> to work on a Tk interface then those three people need to collaborate >>>>>>>> so to make sure that all three are the same as far as functionality and >>>>>>>> overall look... then we need to use the PAR::Packer and pp to then >>>>>>>> make >>>>>>>> a (Windows linux Mac exe) and other extensions for the other Operating >>>>>>>> systems >>>>>>>> >>>>>>>> Where if we click the exe with out a script then it goes to a command >>>>>>>> line >>>>>>>> PDL interface >>>>>>>> I will make some examples for Windows and Linux as I dont have a Mac >>>>>>>> Yet >>>>>>>> ... >>>>>>>> >>>>>>>> they will be command line only interfaces but I will send them as a >>>>>>>> attachment in a >>>>>>>> Tar to the Perldl list so every can download and see if they have any >>>>>>>> bugs >>>>>>>> unless there is a better way to get them to be tested >>>>>>>> Please Let me know !! >>>>>>>> >>>>>>>> Cheers ! >>>>>>>> >>>>>>>> --Mark R baker >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: David Mertens <[email protected]> >>>>>>>> To: Matthew Kenworthy <[email protected]> >>>>>>>> Cc: "[email protected]" <[email protected]> >>>>>>>> Sent: Monday, January 23, 2012 7:04 AM >>>>>>>> Subject: Re: [Perldl] Let us Kvetch! (was: PDL book checking) >>>>>>>> >>>>>>>> On Mon, Jan 23, 2012 at 8:16 AM, Matthew Kenworthy >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> *my personal take, and this thread does have "kvetch" in the subject >>>>>>>> :) * >>>>>>>> >>>>>>>> > Alien is the conceptual namespace given to managing (or at least >>>>>>>> > querying) >>>>>>>> > >>>>>>>> > local::lib provides a simple cross-platform (Windows, Linux, Mac, >>>>>>>> > probably >>>>>>>> > >>>>>>>> > This is terrific, but what changed over the last couple of years in >>>>>>>> > PDL >>>>>>>> > that >>>>>>>> > made this possible? >>>>>>>> >>>>>>>> One click installations with 2D plotting for all platforms makes all >>>>>>>> the difference. It means that I can point collaborators to an install >>>>>>>> package, and get them using my scripts ASAP. My collaborators don't >>>>>>>> care at all about Alien, local::lib, CPAN or dependencies. They want >>>>>>>> something that works without thinking about the installation or >>>>>>>> support. >>>>>>>> >>>>>>>> >>>>>>>> Here is a version of one-click that I would *love* to see, and which >>>>>>>> should happen, I think and hope, by this fall: >>>>>>>> >>>>>>>> cpan Task::PDL::David >>>>>>>> >>>>>>>> If I can point an interested user to a one click install of PDL and it >>>>>>>> works, then we have a new user of PDL. As soon as they hit one >>>>>>>> roadblock, they're *gone*. It doesn't matter if it was a non-PDL >>>>>>>> dependency fail, they assume it's a PDL problem and they walk away. >>>>>>>> When you can seamlessly install SciPy with one click but your build of >>>>>>>> PDL requires knowledge of CPAN to build it, you immediately lose out >>>>>>>> on the mindshare. >>>>>>>> >>>>>>>> >>>>>>>> Sounds like a GUI interface to CPAN would be really helpful. Perhaps we >>>>>>>> can write something using Prima so it's cross-platform? >>>>>>>> >>>>>>>> >>>>>>>> Unless there is a driving reason why they need to >>>>>>>> install/configure/maintain some package, people will go with what is >>>>>>>> (a) run by their friends/associates, so they have someone to ask them >>>>>>>> for local help, and (b) something that has a huge online support >>>>>>>> community with immediate response time. >>>>>>>> >>>>>>>> My current view of the PDL community is that there is a group of about >>>>>>>> 100-200 people who use and run PDL code, with 10 to 20 people in >>>>>>>> active voice on the mailing lists, and a significant fraction of these >>>>>>>> people have used PDL for > 5 years. If anyone knows what the current >>>>>>>> email distribution size is, it would be interesting to know. >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> >>>>>>>> It turns out that if you are registered on the mailing list, you can >>>>>>>> get >>>>>>>> these details. The Perldl (users) mailing list has 175 non-digested >>>>>>>> subscribers and 29 digested subscribers. The Porters list has 51 >>>>>>>> non-digested subscribers and 6 digested subscribers. The number of >>>>>>>> people >>>>>>>> who *use* PDL could be far bigger, for all we know. Also, there are >>>>>>>> about >>>>>>>> four regulars on IRC (and two regular bots). >>>>>>>> >>>>>>>> I argue that one-click installers are only easy to implement if the >>>>>>>> underlying library is well structured. This may take some one-time >>>>>>>> effort >>>>>>>> for SciPDL, but if that's your only complaint, I would be happy to >>>>>>>> help out >>>>>>>> with that. The first step would be to put instructions on the wiki for >>>>>>>> how >>>>>>>> SciPDL is currently built. We can only enhance the build process once >>>>>>>> it's >>>>>>>> known. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> -- >>>>>>>> Sent via my carrier pigeon. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Perldl mailing list >>>>>>>> [email protected] >>>>>>>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Perldl mailing list >>>>>>> [email protected] >>>>>>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Perldl mailing list >>>>>> [email protected] >>>>>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
