$  ipython --version
0.13.2

tried both, getting the same error !!
-------| http://ifni.co


On Tue, Jul 15, 2014 at 3:06 PM, Zakariyya Mughal <[email protected]> wrote:
> On 2014-07-15 at 14:34:07 -0400, mraptor wrote:
>> The same error !!!
>> Btw Python syntax works !!? Probably because I have also Python..
>> Is there some way to force Perl ?
>
> OK, the problem is that the kernel that is being loaded is the Python
> one.
>
> Which version of IPython are you using? I have 2.1.0 here.
>
>     $ ipython --version
>     2.1.0
>
> The way that IPython sets up the language kernel is through profile
> configurations. Perhaps deleting the profile directory and rebuilding it
> might help?
>
>     rm -Rf `ipython locate profile perl`           # delete an existing 
> profile
>
> Then try running
>
>     ./bin/iperl notebook
>
> again. That should copy the profile into the directory. If that doesn't
> work, we can try doing what the iperl script does manually:
>
>     # from the p5-Devel-IPerl directory
>     rm -Rf `ipython locate profile perl`             # delete an existing 
> profile (start off with a clean slate)
>     ipython profile create perl                      # create a Perl profile
>     cp -vR profile/* `ipython locate profile perl`/  # copy the config into 
> the profile directory
>     export PERL5LIB=`pwd`/lib:$PERL5LIB              # so that Devel::IPerl 
> is in @INC
>     ipython console --debug --profile perl           # start IPython with 
> Perl kernel config (and debugging enabled)
>
> Let me know if that works.
>
> Cheers,
> - Zaki Mughal
>
>>
>> >>
>> [NotebookApp] Serving notebooks from /my/compile/p5-Devel-IPerl
>> [NotebookApp] The IPython Notebook is running at: http://127.0.0.1:8888/
>> [NotebookApp] Use Control-C to stop this server and shut down all kernels.
>> [NotebookApp] Using system MathJax
>> [NotebookApp] Kernel started: dc829946-9fdf-462c-b9f5-dc8144217c02
>> [NotebookApp] Connecting to: tcp://127.0.0.1:34272
>> [NotebookApp] Connecting to: tcp://127.0.0.1:32965
>> [NotebookApp] Connecting to: tcp://127.0.0.1:54452
>> [IPKernelApp] To connect another client to this kernel, use:
>> [IPKernelApp] --existing
>> kernel-dc829946-9fdf-462c-b9f5-dc8144217c02.json --profile perl
>> -------| http://ifni.co
>>
>>
>> On Tue, Jul 15, 2014 at 1:49 PM, Zakariyya Mughal <[email protected]> 
>> wrote:
>> > On 2014-07-15 at 10:48:50 -0400, mraptor wrote:
>> >> Any idea why it does not work :
>> >
>> > Hi,
>> >
>> > I just made the startup more robust when you don't pass in the type of
>> > frontend you want. Try updating the repository and see if that fixes it.
>> >
>> > IPython has three frontends: console, qtconsole, and notebook. I
>> > recommend starting IPerl under the notebook frontend as that is a web
>> > REPL that let's you use multimedia output rather than just text (which
>> > Perl already has with Devel::REPL, etc.). Run
>> >
>> >     ./bin/iperl notebook
>> >
>> > to start it up.
>> >
>> > I'd love to hear your feedback.
>> >
>> > Cheers,
>> > - Zaki Mughal
>> >
>> >
>> >> ----------------------------------------
>> >>
>> >> /my/compile/p5-Devel-IPerl $ ./bin/iperl
>> >> Python 2.7.5+ (default, Sep 19 2013, 13:48:49)
>> >> Type "copyright", "credits" or "license" for more information.
>> >>
>> >> IPython 0.13.2 -- An enhanced Interactive Python.
>> >> ?         -> Introduction and overview of IPython's features.
>> >> %quickref -> Quick reference.
>> >> help      -> Python's own help system.
>> >> object?   -> Details about 'object', use 'object??' for extra details.
>> >>
>> >> IPython profile: perl
>> >>
>> >> In [1]: $x = 10
>> >>   File "<ipython-input-1-6ebffcaf5f84>", line 1
>> >>     $x = 10
>> >>     ^
>> >> SyntaxError: invalid syntax
>> >>
>> >>
>> >> -------| http://ifni.co
>> >>
>> >>
>> >> On Sat, Jun 28, 2014 at 5:00 AM, Zakariyya Mughal <[email protected]> 
>> >> wrote:
>> >> > On 2014-06-27 at 14:19:36 -0400, David Mertens wrote:
>> >> >> Hey everyone,
>> >> >>
>> >> >> Although I am very interested to see this happen, I have not done 
>> >> >> anything
>> >> >> for it. However, just today I was hunting around Software Carpentry's 
>> >> >> web
>> >> >> page and found that they are interested in a Perl backend for iPython
>> >> >> <http://software-carpentry.org/pages/create.html> (scroll to the 
>> >> >> bottom of
>> >> >> the list). In case you have not heard of Software Carpentry, it has 
>> >> >> become
>> >> >> a go-to resource for grad students to learn Python. Their interest in
>> >> >> adding Perl is unexpected, and worth contributing to, I think.
>> >> >
>> >> > Wow, I'm on the SWC mailing list and this is a pleasant surprise.
>> >> > Perhaps we can work with them to develop a Perl curriculum. That would
>> >> > certainly help PDL get better documentation for beginners.
>> >> >
>> >> >> Don't get me wrong: I'd like to eventually create a stand-alone 
>> >> >> pure-Perl
>> >> >> application. However, I think that iPython integration is both a 
>> >> >> suitable
>> >> >> goal and a suitable intermediate step towards the pure-Perl 
>> >> >> application.
>> >> >
>> >> > Agreed.
>> >> >
>> >> >> Zaki, what would be the must useful thing we can do to help with your 
>> >> >> work?
>> >> >
>> >> > I've uploaded an IPython notebook file with the current status of the
>> >> > IPerl kernel which can be viewed here 
>> >> > <http://nbviewer.ipython.org/gist/zmughal/d8a37222c814956aebb8>.
>> >> >
>> >> > There are still a couple of bugs to fix. In particular, the interface
>> >> > for displaying images is a bit rough, but that can all be addressed. Now
>> >> > that the IPerl kernel exists and is somewhat usable, I think we can
>> >> > start writing generic modules that would help with using Perl both in
>> >> > the IPython Notebook and any future frontends.
>> >> >
>> >> > In terms of helping with the kernel, I would really like some feedback
>> >> > on the code and future improvements I'm planning. And any patches are
>> >> > welcome!
>> >> >
>> >> > Cheers,
>> >> > - Zaki Mughal
>> >> >
>> >> >>
>> >> >> David
>> >> >>
>> >> >>
>> >> >> On Wed, Jun 18, 2014 at 3:39 PM, Chris Marshall 
>> >> >> <[email protected]>
>> >> >> wrote:
>> >> >>
>> >> >> > On Wed, Jun 18, 2014 at 3:10 PM, Zakariyya Mughal 
>> >> >> > <[email protected]>
>> >> >> > wrote:
>> >> >> > > On 2014-06-17 at 14:30:23 -0400, Chris Marshall wrote:
>> >> >> > >> On Tue, Jun 17, 2014 at 1:13 PM, Zakariyya Mughal <
>> >> >> > [email protected]> wrote:
>> >> >> > >> > 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.
>> >> >> > >>
>> >> >> > >> I like the layered architecture but it would be nice if we could
>> >> >> > >> have a base implementation without adding a complex, 3rd party
>> >> >> > >> networking and concurrency library to the mix.  Any chance of
>> >> >> > >> a simple framework that could be extended to full 0MQ features
>> >> >> > >> if required?
>> >> >> > >
>> >> >> > > Yes, this is definitely possible. My design separates the wire 
>> >> >> > > protocol
>> >> >> > > from the message format, so a simpler protocol is possible for
>> >> >> > > communicating with just a single client.
>> >> >> >
>> >> >> > Sounds good.  Is the implementation based on a plugin type
>> >> >> > approach?
>> >> >> >
>> >> >> > > Another possibility is to fix Alien::ZMQ on Win32 (either by 
>> >> >> > > fixing the
>> >> >> > > compilation or work on providing something pre-compiled from
>> >> >> > > <http://zeromq.org/distro:microsoft-windows>).  Every other 
>> >> >> > > platform
>> >> >> > > has packages which work. I have some experience with
>> >> >> > > Alien packages, so the latter shouldn't be too difficult
>> >> >> >
>> >> >> > Removing the hard dependency for 0MQ for the basic implementation
>> >> >> > is preferred.  There are a large number of partially implemented
>> >> >> > Alien modules that only sort of work (usually if you happen to use
>> >> >> > the OS/platform of the developer).  I've been working to update the
>> >> >> > Alien manifesto to be more usable:
>> >> >> >
>> >> >> >
>> >> >> > http://blogs.perl.org/Fusers/chris_marshall/2013/12/a-framework-for-alien-modules-the-alien2-manifesto.html
>> >> >> >
>> >> >> > But getting traction and agreement has been slow/difficult.  Lots of
>> >> >> > differing opinions.  :-)   Fixing Alien:XXX for all the libraries 
>> >> >> > that PDL
>> >> >> > builds with is a definite goal to improve portability.
>> >> >> >
>> >> >> > > My current design requires IO::Async which seems rather portable
>> >> >> > > by the results on CPAN Testers.
>> >> >> >
>> >> >> > One thing that often happens with portability for windows platforms
>> >> >> > is that a module sounds great and tests pass *but* if you look at
>> >> >> > the details it is possible that many of the key features actually 
>> >> >> > don't
>> >> >> > work for windows so if an implementation requires those features,
>> >> >> > the result is non-portable (doesn't work) to windows.  Looking at the
>> >> >> > test output it appears that the usual suspects are missing for
>> >> >> > IO::Async: signals and fork.
>> >> >> >
>> >> >> > >> > 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.
>> >> >> > >>
>> >> >> > >> Do you have to hardwire in the REPL or is there a way to just
>> >> >> > >> provide an IN and OUT handles for any REPL?  Mentioning this
>> >> >> > >> since I'm thinking to refactor pdl2 from Devel::REPL to Reply
>> >> >> > >> which is lighter weight and cleaner for shell type applications.
>> >> >> > >
>> >> >> > > No, it isn't hardwired. All I'm doing is creating a Term::ReadLine
>> >> >> > > subclass that feeds in commands from a string, so it should be
>> >> >> > > compatible with anything that uses ReadLine including Reply or even
>> >> >> > > Devel::Trepan.
>> >> >> >
>> >> >> > Ok.  I would like to have the console interface (completion, syntax
>> >> >> > coloring, ...) be generic enough to be usable with the GUI front end
>> >> >> > as well to avoid duplication of code.
>> >> >> >
>> >> >> > > As a sidenote, as far as I can tell, IPython Notebook isn't 
>> >> >> > > attempting
>> >> >> > > to deal with excessive output, so you can crash the browser by 
>> >> >> > > executing
>> >> >> > > an infinite loop that quickly prints out lots of data. I will 
>> >> >> > > probably
>> >> >> > > try to deal with those problems later as an unresponsive REPL is
>> >> >> > > unacceptable (this actually leads to losing code). I think it will 
>> >> >> > > have
>> >> >> > > to be dealt with both on the kernel side and frontend side. Just
>> >> >> > > thinking ahead.
>> >> >> >
>> >> >> > Definitely something to be avoided.  --Chris
>> >> >> >
>> >> >> > > Cheers
>> >> >> > > - Zaki Mughal
>> >> >> > >
>> >> >> > >>
>> >> >> > >> > 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. ;-)
>> >> >> > >>
>> >> >> > >> Definitely.
>> >> >> > >>
>> >> >> > >> >> 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
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >>  "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

_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to