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
