Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2013-05-11

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

All times shown according to UTC.

Time Nick Message
00:31 LimitSupremum joined #pdl
01:27 LimitSupremum joined #pdl
01:40 LimitSupremum left #pdl
02:34 sivoais joined #pdl
13:24 chm joined #pdl
13:29 chm run4flat: Have you tried the latest 64bit-index-support stuff and does it work for you?
13:29 chm run4flat: I would like to see it part of PDL-3.000 but don't want to break things in the process but don't want to wait until 2020 either...
13:45 jberger chm, o/
13:45 jberger I believe run4flat is out of town this weekend
13:52 rindolf joined #pdl
14:09 chm jberger: o/
14:09 jberger hi
14:10 chm Are you all defended?
14:11 chm If you've been following the list posts, I'm trying to get a push for PDL3 this summer.
14:11 chm It seems like all the pieces are there and it would be nice to have "PDL the next generation" sooner than later.
14:12 chm I'm in the process of adding 64bit index option to perldl.conf so we can release a CPAN developers version this weekend.
14:13 chm I would really like to see the non-core PDL modules able to use 64bit support if it makes sense.
14:13 chm Don't want their code to break for v3 either.
14:15 jberger I am all defended!!
14:15 jberger good work on the 64 bit stuff too!
14:16 jberger I like the idea of PDL 3 being the beginning of a cleanup
14:17 jberger it seems that the idea of a major overhaul by then is rather impractical
14:21 jberger chm, I think one of the easiest things that PDL3 could do is to deprecate (not remove) the use of the .pd extension
14:21 jberger I have come around to run4flat's way of thinking that they really should be .pm.PL
14:22 jberger or possibly .xs.PL
14:22 jberger from discussions we have had with the metacpan guys this might just fix some of the doc online problems right off the bat
14:24 jberger also I think that the pdldoc documentation database needs to be re-examined
14:24 jberger it really should have its own api etc etc
14:50 chm jberger: Congratulations!
14:50 jberger thanks!
14:50 chm jberger: re the .pd extension, .pm.PL makes sense, what about .pd.PL instead?
14:51 chm At least is is unambiguous that it is a perl code file
14:51 jberger meaning that the script would generate the .pd file?
14:51 jberger .PL files are used to generate the files of the type before the .PL
14:51 chm Oh, just saw your xs.PL, that is probably more correct.
14:52 jberger let me check the metacpan file-finding regex to see if those fit
14:52 chm One thing I was hoping your might have some thoughts on is the use of Moo[se] in the new PP
14:52 chm It is *really* difficult to follow what is being done by the PP generation stuff
14:53 chm I'm thinking there must be a way to make it more comprehensible.  If we had method modifiers in
14:53 chm the code generation then we could add ->around() etc to provide debugging, more meta data for JIT or run time processing
14:54 jberger I'm all for Moo[se]ifying the PDL codebase
14:54 jberger David and I have discussed a plan of action for trying to understand the PP process
14:55 chm Did he/you ever construct a flow chart of what is in there now?  That would be a huge help.
14:55 jberger it sounds like quite a bit of work, but its something that needs to be done
14:55 jberger not yet
14:55 chm I have the same sort of problem with TriD since I can refactor it without understanding the current code
14:55 jberger but we've talked about it
14:56 chm One of the challenges for PDL3 is that I already have a number of items on my plate (TriD, OpenGL, NiceSlice,..)
14:57 chm and will really need some other folks to help with the coding for this release.  I've been limping along
14:57 chm with little steps as I can myself with occasional quantum steps when some other developer gets activated
14:58 chm but I think we have a critical mass in developers and progress that even a PDL3 as a start could be *major*
14:59 chm One thing that would be an enormous help for PDL and CPAN would be Alien::XXX for the PDL dependencies.
14:59 chm I keep seeing platform maintenance issue that might mostly disappear if with had needed Alien::XXX
14:59 chm would you be willing to take point on that effort?
15:00 jberger I'm happy to help there sure, but of course, the Alien::Base effort was meant to make writing an Alien:: module so easy that everyone could and would do it
15:00 jberger :-)
15:01 jberger personally I'm more interested in making PDL leaner and more modern
15:02 jberger so far I have considered PDL too heavy of a module to use as a prerequisite for other modules
15:02 jberger I really want to make that less of a problem
15:02 chm I meant more in terms of coordinating the efforts, maybe start with stubs and let others help out.
15:02 jberger sure
15:02 chm Tutorial/documentation/training to help us grok Alien::Base would help people.
15:03 chm Even just enumerating the modules, setting up git and the basic framework with tests would help.
15:03 jberger well here is the basic starting doc: https://metacpan.org/module/JBERGER/Alien​-Base-0.003/lib/Alien/Base/Authoring.pod
15:03 chm I'm very willing to help debug and contribute but monitoring that would probably keep me from finishing OpenGL 2.x support
15:04 chm which is critical for new TriD and others (e.g., Prima::OpenGL and many others would be much more capable
15:04 chm if OpenGLES stuff were there---can you say PDL on your smartphone?
15:04 jberger I don't want to tie you up, you are needed elsewhere
15:05 jberger I doubt ARM is going to happen soon :-)
15:05 jberger does Perl even build on ARM yet
15:05 jberger ?
15:06 chm There is already wxWidgets + perl on raspberry pi (which is ARM 6 or 7).  I know support is there for more recent ARMs.
15:06 chm I'm not sure about non-linux type oses.  However, the vendor graphics all seem to be targeting OpenGLES 2 which
15:06 chm means none of the legacy OpenGL stuff currently in POGL and TriD.
15:07 jberger chm: btw here is the doc indexing bug report: https://github.com/CPAN-AP​I/metacpan-web/issues/679
15:09 jberger and from here: https://github.com/CPAN-API/cpan-api/blob/​master/lib/MetaCPAN/Document/File.pm#L588
15:09 chm Thanks, I think we might do better with the idea I proposed a day or so ago---sort of like weave with TeX stuff
15:09 jberger anything that matches /\.(pl|pm|pod|t)$/i will be indexed as a Perl file
15:09 jberger chm do you remember my experiment down the TeX road?
15:09 chm The idea is that only valid link pod constructs would end up in the distributions.  We would provide functionality
15:10 chm to reverse the process to regenerate the full in-line .pd source so developers and debugging could work
15:10 chm I don't recall the details.  Do you have a pointer?
15:11 jberger http://pdlporters.github.i​o/?docs=Acme::Pod::MathJax
15:11 jberger its my mirror/port of pdl.perl.org but with MathJaX powered TeX rendering
15:11 jberger and a dummy module that demonstrates it in the pod
15:12 jberger oh, you are talking about process not ACTUAL tex
15:12 jberger heeh
15:13 jberger ok, yeah, preprocess out the documentation before shipping to CPAN would work
15:13 chm It would have the advantage that .pd would still mean the same as always (after all PDL is >10yrs)
15:14 jberger but I also think that just renaming the .pd files to .pm.PL or .xs.PL would also trick the major sites into pod indexing them again (as search.cpan.org used to)
15:14 jberger there's no reason to remove the ability to process .pd files
15:14 jberger but if we can fix this problem just by changing some file names, that would be my vote
15:15 chm But, AFAICT, the real problem is not just the fact that the file names are wrong, but that the docs don't necessarily exist
15:15 chm until after the .pd is run.  The extraction to make distribution .pod would address that problem.  Renaming would not.
15:16 jberger well that may be true, but I thought that part of the reason that the .pd files were constructed as such was that pod-renderers would see the doc correctly
15:16 jberger try running perldoc on one of the .pd files in the source tree
15:16 jberger IIRC it works
15:16 chm No, we've been doing some clean up of .pd doc strings so that pod parsers don't get [too] confused but that is not a real fix
15:17 jberger no its not
15:17 chm since some .pd files actually generate the PP code at runtime from the library includes or some other source
15:17 jberger in that case though, even if the core PDL figures out a process to extract the pod from pd before tarring
15:17 jberger that's something that we should try to be able to provide to non-core module authors
15:18 jberger which brings me to another question, Modules::Build??
15:18 chm definitely, we would need to add it to PDL::Core::Devel or some such.
15:18 chm In fact, something like that is needed if we want to really be able to clean up the PDL core distribution
15:19 chm I'm all for making it small and lean.  Ideally, anyone needing a multidimensional array blob could just use
15:19 jberger oh, that would be nice
15:19 chm the core of PDL and have it just work without any garbage dependencies.
15:19 jberger exactly
15:20 chm It would make things much easier for us to interface with other perl modules if they can use our core as their data structures
15:20 chm Another reason to lean in the Moo[se] direction.
15:20 jberger yes
15:21 chm On the general organizing front, do you have any suggestions for how to better coordinate
15:21 chm the PDL3 effort to keep things timely, more concrete, and on schedule?
15:22 chm It would be nice if there were some project tracker that we could use.  I can wiki-fy the tasks
15:22 chm but to close the loop needs some interaction.  My experiences with Trac is that it is far too complex
15:22 chm and heavy weight.
15:23 jberger github has some interesting things for checklists etc
15:24 chm I like the idea of Module::Build but there are still some issues with it (see Craig's recent post)
15:24 chm which would make such a change much more disruptive than could be safely addressed in
15:24 chm the proposed PDL2->PDL3 step this summer.
15:25 chm I think the Alien::XXX could provide a way for those of us not conversant with MB
15:25 chm to come up the learning curve a little.
15:26 jberger https://github.com/blog/1375-task-​lists-in-gfm-issues-pulls-comments
15:26 chm Circling back to your interest in making PDL leaner and more modern, are there other
15:27 chm things you think should/could happen for PDL3?  For one thing, it would be nice to have a strawman
15:27 chm pdl3 core that we could work with
15:28 jberger strawman?
15:28 chm First cut implementation that doesn't necessarily work all the way but serves as a concrete start point
15:28 jberger oh ok
15:29 chm for discussion and development---people seem to do better when things are more specific than vague
15:29 jberger the first thing I would do is fork out anything from the core that has any external dependency
15:30 chm The good news is that you can pretty much get that by turning off all the options in perldl.conf
15:30 jberger yes Alien:: modules could help, but this is really the way to make it tiny
15:30 chm Alien:: modules are important since much of the reason for portability problems is just that
15:30 jberger true, but there's a side effect
15:31 chm the external libs need to be rolled up by hand by an expert...
15:31 jberger build time will be much less without all the extra code that comes from the external libraries
15:31 jberger a move to Module::Build might be interesting if just to clean up the build process :-)
15:32 jberger (remember I'm just spitballing here)
15:32 jberger then the question is how far down the Moo[se] path can we get quickly-ish
15:32 jberger the big problem is attaching the C data structure correcly
15:32 jberger correctly
15:32 chm I understand.  I was thinking to start with the pdl object.  It could be essentially what we have now but with some
15:33 chm function pointers or arrays of function pointers added.  These would permit method modifier support at the C level.
15:33 chm My idea for the strawman implementation would be to immediately call a perl level routine to tie thing
15:34 chm back to Moo.  Now we can do all the prototyping at the perl level (with a performance cost).  When we get something
15:34 jberger have you seen this: https://metacpan.org/module/FLORA/XS-Ob​ject-Magic-0.04/lib/XS/Object/Magic.pm
15:34 chm we like we could move needed stuff to XS level.
15:35 jberger I think I'm suggesting going the other way
15:35 jberger more stuff at the Moose level, with the PDL data attached via XS::Object::Magic
15:37 chm That looks pretty much equivalent too me.  So we could start with the pdl2 struct tied up to Moo[se] and go from there?
15:38 chm I was thinking a next step would be to make the new implementation work as the PDL2 does?  If we can be equivalent, then back compatibiliy would be doable.
15:39 jberger the question is getting the current methods to find the C struct
15:39 jberger basically one more indirection step
15:39 jberger but yeah, that seems like a reasonable path
15:40 chm I was thinking that Moo as the core dependency was the way to go.
15:40 chm Some discussion on the #moose that "why don't you just use Moose" but
15:41 chm even with the differences in syntax, aiming for minimal external dependencies for the runtime
15:41 chm is a better way to go.  It should be quite doable provided we start with Moo.  We can promote to Moose
15:41 chm when we need the full MOP.  Thoughts?
15:42 jberger the only real different between the two is the type system
15:42 jberger but I don't really think we need it
15:42 jberger so I would say Moo
15:42 chm And some restrictions on method modifiers supported.  I would rather discipline now and Moo than mess and Moose required...
15:42 jberger I use it everywhere except for Physics::UEMColumn
15:43 jberger in which I need the MOP because of my MooseX::Types::NumUnit that needs the MOP
15:44 chm Yes, but the key is that Physics::UEMColumn would not require Moose because of PDL core.
15:44 jberger right
15:44 chm Moose is actually much more installable than it used to be and strawberry perl includes it already.
15:44 jberger that's not what I was saying, I'm saying that 95% of the time Moo is enough for me in my other (non PDL) work
15:44 chm I like KISS
15:44 jberger me too
15:45 chm Right, I was just pointing out that we don't want PDL to force Moose, but you can have your cake and eat it too if you wish
15:45 jberger exactlhy
15:45 jberger s/h//
15:46 chm Where I was thinking roles could help out would be in the PP code generation stuff.\
15:46 jberger yeah, if we could figure that out it would be great
15:46 chm What if the various code generation items were added as roles to an object representing the pp_def
15:47 jberger but even more, roles help splitting out the external dependencies
15:47 chm That would allow for all sorts of nice things.
15:47 chm Y
15:47 jberger rather than having the external dependency on say GSL, you could make a CPAN module PDL::Role::GSL which depends on GSL
15:48 jberger then if you install that, the role can be composed into PDL
15:48 jberger and you get the GSL methods
15:48 jberger without needing to have some wrapper class like PDL::GSL which isa PDL
15:48 chm What about a role providing threading to encapsulate the whole cryptic code stuff in PP?
15:49 chm The key for threading is stuff like indexes, dims, loops, not the specific C code required
15:49 chm It would be nice if that were clear in the implementation
15:49 jberger it could simplify the code probably
15:50 chm It would also be possible to apply roles at runtime---maybe it could be a live Inline::Perldlpp?
15:51 chm I'm already planning to use roles to support multiple GUI toolkits for visualization with OpenGL stuff.
15:51 jberger for example: Module::Build is essentially one giant class declaration: https://github.com/Perl-Toolchain-Gang/Modul​e-Build/blob/master/lib/Module/Build/Base.pm
15:51 chm Rather than testing GLUT/FreeGLUT, I would require a role providing the needed functions.
15:52 jberger but I have started a project to rolify many of the like functionalities: https://github.com/jberger/Moodule-Bui​ld/tree/master/lib/Moodule/Build/Role
15:52 chm That could be provided seamlessly by any number of GUI libraries...
15:53 jberger basically in the MB case the roles are all composed all the time (probably) but it makes the code much easier to navigate and understand IMO
15:53 chm Roles could definitely clean up a lot of the OO mess.  By composing rather than inheriting we get faster method resolution as well
15:53 chm Performance!
15:54 jberger chm: you are basically looking to go down the "interface" route for GUI libraries
15:54 chm Yes, and now that perl has them via roles, it seems applicable
15:54 jberger yep, I like that too
15:55 chm For example, I switched to GLUT with POGL for portability.  Now I need to reverse that to require the interface instead to work with Prima, Tk, wxWidgets...
15:56 chm It will also keep POGL from having hard dependencies on any specific GUI
15:57 jberger << went way over my head >>
15:57 * jberger does most of his "GUI" work via the browser and Mojolicious
16:00 chm nice
16:00 chm too bad it doesn't work with firewalls
16:00 jberger ?
16:01 jberger oh if your computer blocks outgoing port 80
16:01 chm that is, a firewall that is not user configurable
16:01 jberger for a cool example, see Farabi
16:02 jberger Mojolicious-based in-browser IDE
16:02 chm I try to keep to the Least Common Denominator for PDL development for flexibility.
16:03 chm BTW, I was finally able to install Padre from CPAN on my strawberry perl so things
16:03 chm are looking up on that front as well.
16:04 chm jberger: It has been great chatting, I've got to head out.  later, o/
16:05 jberger great chatting with you too, we'll keep the dialogue going
16:05 jberger o/
18:44 rindolf joined #pdl
18:50 rindolf Hi all.
19:14 pdurbin rindolf: hi
19:14 rindolf pdurbin: what's up?
19:15 pdurbin well, I launched a new IRC channel/community on freenode this morning: http://irclog.greptilian.c​om/wonderstudy/2013-05-11
20:35 sivoais joined #pdl

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