Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2015-06-27

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
16:10 estrabd joined #pdl
17:59 rindolf joined #pdl
19:44 opkick [pdl] zmughal comment on issue #124: I wanted to know if this bug was a regression or not, so I used a tool I wrote (in the [devops](https://github.com/PDLPorters/devo​ps/tree/master/regression-vagrant) repository on GitHub) and it appears that this bug has [been around since at least 2008](https://github.com/zmughal/pdl-r​egression-logs/blame/sf390/log).... http://git.io/vt06c
21:51 chm joined #pdl
21:54 chm sivoais: regarding http://sourceforge.net/p/pdl/bugs/390/ the issue is the perl scalar <-> pdl scalar conversion
21:54 chm not the stats which has bad value support.
21:54 sivoais chm: yes
21:54 chm The fact that it showed up for that command was because it was where he saw it.
21:55 sivoais I know. There are 2 bugs there. I wrote my tests to show both.
21:55 chm I'll have some time to look at this today/tomorrow and definitely some time next weekend over the holiday.
21:56 chm I'll start with how much of the 64bit support is working for 2.011
21:56 chm BTW, in my last 64bit push, I was trying to get the typemap working for the union type PDL_Any
21:57 chm I think there may be some iffy-ness in the logic which I hope will pop out with some time away.
21:57 sivoais is that work on a branch?
21:57 chm I thought I saw some stuff merged into master by mohawk but don't know how much
21:58 chm The last stop I had was in the branch...remotes/origin/longlong-double-fix
21:58 chm I thought some had been merged into master but I dont' know.
22:00 sivoais Ah, OK. I might have time here and there, so if you want me to take a crack at writing more tests, I can help with that.
22:00 chm mohawk: PDL/perl vs NumPy from the FFTW3 thread...
22:01 chm I do find that NumPy has a much stronger user base.  I think that allowing PDL to interop with NumPy
22:02 chm would be a serious help for PDL to avoid re-inventing the wheel and all.
22:02 chm Unfortunately the python experts rarely stoop to learning perl and perl experts have no use for python.
22:02 sivoais for reference, link to thread here <https://github.com/dkogan/PDL-FFTW3/issues/5>
22:03 chm Maybe Dmitri will learn enough python to help bridge the gap.
22:03 sivoais I do use both and I've had some interesting successes with Inline::Python
22:03 chm sivois: really?  That was where I hit the wall and even the original author switched to python. :-(
22:04 sivoais I managed to use the ITK and VTK bindings through that. It was a little tricky since those libraries are very C++ oriented
22:04 sivoais let me link them here, one sec
22:04 chm my plan was to get the 64bit index support working for PDL-2.x and then get onto PDL3
22:05 sivoais <https://github.com/EntropyOrg/p5-Graphics-VTK> and <https://github.com/EntropyOrg/p5-Image-ITK> work
22:05 chm Whilst splitting PDL-2.x into clean, modular, packages.
22:05 sivoais they aren't on CPAN because right now they work through Python bindings
22:06 chm I recently looked at generating the OpenCV bindings from the python starting point (as done with java)
22:06 * sivoais nods
22:06 chm NumPy has suport for handing off thier arrays to and from C code that looks a lot like the
22:06 chm basics of the data part of the pdl struct
22:07 chm Since I have need of OpenCV, I guess I'll be learning enough python to get perl/PDL ones.
22:07 sivoais yeah, most libraries support that in some form or another.
22:07 chm With luck they can be pushed upstream with the java and python
22:08 chm In my experience, PDL where it works is *much* cleaner and nicer than NumPy
22:08 sivoais I'm going to have more time after the end of July, so I'll be able to help then
22:08 chm Of course, with the large user base, there are a lot more python modules being generated.
22:09 sivoais I'd say NumPy has better namespacing, but it is very much based on MATLAB which is a minus
22:09 chm One feature of PDL is how well it builds now.  I had a friend (python-er) need PDL for something and, unassisted, it built out of the box for him.
22:09 sivoais and has less clean support for ufuncs
22:10 chm I think ufuncs are like our PP signature routines, right?
22:10 sivoais yeah, the SciPy stack is notorious for having a difficult build. That's why Conda exists
22:10 chm On challenge that PDL has is that it hasn't crashed and burned twice.
22:10 sivoais yep
22:10 chm NumPy->Numarray->NumPy (the phoenix!) and they finally "caught up" in a sense.
22:11 chm Now of course, the large user and funding base keeps things moving.
22:11 chm If we can stabilize PDL-2.x with full 64bit support then PDL3 + PDL::Core could give
22:12 chm an opportunity for significant advances in portability, data type support, performance, jit...
22:13 sivoais re the last three: Julia, Blaze, and some parts of APL are going to be worth looking at
22:13 chm definitely we should learn from the best and keep the best of our own.
22:15 chm sivoais: I've got to go.  I'll report back on the bad/64bit/type bug---at least what I try.
22:15 chm o/
22:15 sivoais o/

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary