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

Reply via email to