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
