Hello everyone, On 2014-06-17 at 08:30:14 -0400, Chris Marshall wrote: > My preference would be to extract the best of iPython for PDL > and implement in perl.
Yes, I totally agree. That's my long-term plan. I've been reading the IPython code and the basics don't seem that difficult to write. In fact, there is a ~500 line version of the IPython architecture available at <https://github.com/fperez/zmq-pykernel>. > AFAICT, iPython doesn't appear to have an interface specification > for their web frameworks and the development logs do not appear > to address any portability for non-python environments. It does have a specification. There are some details at the links below, but I'll summarise it here. - <http://ipython.org/ipython-doc/stable/development/messaging.html> - <http://andrew.gibiansky.com/blog/ipython/ipython-kernels/> You can see in the second link that the architecture is made up of two parts: the frontend (the interface the user sees) and the language kernel (what evaluates expressions, returns data, and provides services like completion). They communicate with each other over ZeroMQ. It is a bit unnecessarily complex, but it allows for using multiple clients with different capabilities at the same time. What I'm working on now is the language kernel (repo here <https://github.com/zmughal/p5-Devel-IPerl>). Right now I've just got a prompt working — I need to connect it to Devel::REPL to support evaluation and completion events. I don't want to give any estimates, but I don't think that getting to an alpha version will take long. The main reason I'm working with IPython is because it has a spec and coding to a spec is easier than coming up with everything from scratch. ;-) > As for the IDE/workbook style, maybe we could start with something > like the LCD of the current implementations: iPython, Matlab, Maple, > Mathematica, Spyder(?),... Once this interface is architected, the > next step would be to implement it. At this point, it would be possible > to hack in an iPython version but that would probably have portability > problems and only of use for Python + PDL users which is a step > backwards from making PDL easy to install/use. > > --Chris > > On Tue, Jun 17, 2014 at 7:05 AM, David Mertens <[email protected]> > wrote: > > Hey everyone, > > > > This and another recent conversation prompted me to dust off > > App::Prima::REPL last night. I was in the middle of a refactoring effort > > when I left it off, so I hammered through that last night. The only obvious > > difference between what's on Github and what's on CPAN is the handling of > > the output window, but a more important refactorization underlies that > > difference. I feel a lot better about it. > > > > It seems that we could pretty easily move forward on two independent fronts. > > Perl has some very nice web frameworks, but since the iPython code is > > already available, we could hook into iPython's framework for the first cut > > of the web stuff. If we later want a pure-Perl solution, we could build a > > Perl web front end that could be swapped out for the iPython one. > > > > Then we'd have to get the GUI side working. One hard part will be the math > > typesetting, but I have a shortcut in mind that we can try using. Another > > hard part will be changing the workflow and layout to mimic iPython instead > > of Matlab. That will take a bit of study, and it may be better to write a > > different GUI app (called perhaps iperl) rather than try to fold this > > functionality into the current GUI (prima-repl). Hmm, after looking at the App::Prima::REPL code, I don't see a structured output format. I was wondering if you've considered looking at the .ipynb format for serialisation. It's just JSON and seems extensible (even though the frequent use of data: URIs feels wrong to me). Using this format means that all notebooks can be viewed online using <http://nbviewer.ipython.org/>. Unfortunately, there is no easy way to add POD formatting to that site instead of Markdown, but I can think of some workarounds. There's a schema for the JSON here: <https://github.com/ipython/ipython/blob/master/IPython/nbformat/v3/v3.withref.json>. Cheers, - Zaki Mughal > > > > I suspect that anybody who wants to get involved can begin by downloading > > and digging into the notebook software. I wonder if the Julia bindings might > > serve as a good reference? > > > > David > > > > > > On Mon, Jun 16, 2014 at 8:32 AM, Chris Marshall <[email protected]> > > wrote: > >> > >> Very interesting discussion so far. A focus on PDL > >> development for me as release manager has been to > >> improve the portability and buildability of PDL across > >> all major perl platforms (windows, macosx, and unix/linux/bsd/*). > >> > >> We've made steady progress but once PDL is installed > >> the user might ask "Now what?". It would be nice to > >> have a clear and simple answer for that. (In addition to > >> the use case of supporting better scientific development > >> and collaboration). > >> > >> The good news is that we have two key pieces already > >> available that could be a foundation for iPDL: > >> > >> (1) Interactive PDL shells (perldl, pdl2) > >> > >> We've already made a start at integrating multiple GUI > >> toolkit event loops. Stalled for now but I think we know > >> what is needed. > >> > >> (2) Prima and Prima::OpenGL > >> > >> This gives us a baseline, *extremely* portable GUI > >> toolkit to build on. We could use other toolkits but > >> it is really difficult to beat the portability of Prima as > >> a powerful GUI for perl. In a sense it is a little known > >> super-power perl module. :-) > >> > >> NOTE: I explicitly call out Prima::OpenGL because > >> I think for high performance and portable graphics and > >> realtime visualization, OpenGL is now the default > >> standard---even including GPU compute shaders in > >> the latest version. > >> > >> I'm sure there are some other ideas but, like the PDL3 > >> development discussions, I think the best approach is > >> to KISS as much as possible. Avoiding outside toolkits > >> and libraries where possible is a win for portability, > >> especially for non-unix-ish platforms such as windows. > >> > >> --Chris > >> > >> > >> On Mon, Jun 16, 2014 at 7:10 AM, Paul Goodall > >> <[email protected]> wrote: > >> > Hi David, Craig, > >> > > >> > I’d be happy to help with this - I should have spare time in between > >> > projects to contribute to it. > >> > > >> > Personally, I don’t think it would be a bad thing for PDL to be more > >> > accessible to the general community. Typically when I explain to others > >> > that I use PDL, I’m met with a blank face, prompting for an explanation. > >> > It > >> > would be nice if PDL were to be recognised as a desirable skill in the > >> > same > >> > way that Python is (particularly, for example, in job interview > >> > situations). > >> > It is a shame that more people don’t know about/have the power of PDL at > >> > their fingertips :-) > >> > > >> > Paul > >> > > >> > > >> > On 13 Jun 2014, at 18:12, David Mertens <[email protected]> > >> > wrote: > >> > > >> > Paul, > >> > > >> > To clarify, the notebooks that you mention in your link have two key > >> > features. First, they provide online sharing, so it is very easy to show > >> > your colleagues some ideas and calculations. Your colleagues can > >> > probably > >> > even try manipulating the data in their browser, if it's fancy enough. > >> > Second, they provide means for (1) writing code, (2) writing prose, (3) > >> > typesetting math, and (4) embedding media such as pictures. They are, in > >> > essence, Mathematica clones for their respective languages. > >> > > >> > PDL does not have an equivalent to this sort of tool. I wrote a > >> > rudimentary > >> > offline GUI data analysis program called App::Prima::REPL, but that was > >> > more > >> > targeted at the Matlab audience, not the Mathematica audience. It was > >> > also a > >> > giant pile of spaghetti, and I got stalled partway through a refactoring > >> > effort. It is not document focused, but rather tab focused. There is an > >> > API > >> > for building our own custom tabs, but it's really more of a programmer's > >> > tool, not a scientists log book. > >> > > >> > I have lately found myself doing a lot of thinking in LyX, then > >> > programming > >> > in Perl. I would really like if there was some way for me to combine all > >> > of > >> > that into a single document, much like the notebooks that you mention. > >> > However, my programming time has lately been dedicated to other projects > >> > (especially, this last week, polishing off some final work on > >> > PDL::Graphics::Prima for a forthcoming release). > >> > > >> > If you are interested in helping, please let me know. I'd love to work > >> > with > >> > somebody on this. :-) > >> > > >> > David > >> > > >> > > >> > On Fri, Jun 13, 2014 at 12:32 PM, Craig DeForest > >> > <[email protected]> > >> > wrote: > >> >> > >> >> I wouldn't say there's an online notebook viewer so much a powerful > >> >> toolkit to build one. David Mertens recently implemented > >> >> PDL::Graphics::Prima, which is an object framework that can be used to > >> >> construct interactive notebooks very simply and quickly. For example, > >> >> you > >> >> can generate a plot object and connect it to a PDL, and very easily > >> >> update > >> >> the plot as the PDL evolves - or autogenerate/autoupdate plots as you > >> >> carry > >> >> out a calculation. > >> >> > >> >> That is sort of in keeping with the PDL "style" -- our niche seems to > >> >> be > >> >> powerful tools that are expert-friendly, rather than polished packages. > >> >> > >> >> > >> >> > >> >> > >> >> On Jun 13, 2014, at 9:27 AM, Paul Goodall > >> >> <[email protected]> wrote: > >> >> > >> >> > Hi, > >> >> > > >> >> > Apologies if this has a very obvious answer, but does PDL have an > >> >> > equivalent to the online notebook viewers available to the likes of > >> >> > Python, > >> >> > Ruby and (even) Julia? > >> >> > http://nbviewer.ipython.org > >> >> > > >> >> > I’d really like to make use of this ‘IPDL’ if it exists. > >> >> > > >> >> > Thanks, > >> >> > Paul > > > > > > > > > > -- > > "Debugging is twice as hard as writing the code in the first place. > > Therefore, if you write the code as cleverly as possible, you are, > > by definition, not smart enough to debug it." -- Brian Kernighan _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
