Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2013-01-25

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

All times shown according to UTC.

Time Nick Message
00:12 Molaf_ joined #pdl
03:43 jberger joined #pdl
13:33 jberger hi all
13:33 jberger run4flat, ping
13:33 jberger I had an idea last night after chicago.pm
13:34 jberger put optional pdl modules into their own dists
13:34 jberger as PDL::Backend::SLATEC for example
13:35 jberger these backend modules are loaded if available and their functions are imported into the PDL namespace (methods) and caller (functions) as usual
13:36 jberger however, there can be a fallback backend that knows about the major functionality of these optional but pdlporters maintained backends and loads stub functions that die
13:38 jberger this could lean-up the core, be backwards compatible (with appropriate installation) and make the makefile situation easier
13:42 jberger so these backends are like Module::Pluggable plugins in that they are found and loaded, but they are like Moo(se)? Roles in that they compose functionality in to the class
13:43 jberger thoughts?
14:19 lungching jberger: maybe start a PDLX namespace?
14:20 jberger lungching, but that wont take the optional dependencies out of the PDL core
14:20 jberger which is (I think) a future design goal of PDL
14:21 jberger the question is, how to do it
14:21 lungching with love?
14:21 jberger obviously
14:21 lungching yay, I got one right!
14:22 jberger in truth, I use PDL often in my internal/personal projects, but I don't feel like I can depend on them in CPAN dists
14:22 jberger mostly because of the blocking tests in the PDL::Graphics::PGPLOT part of the dist
14:23 jberger since chm has done great work in making the rest of the chain install properly
14:23 jberger but that is still a problem and it would be nice if some of the optional dependencies were really optional
14:24 jberger plus forking them out into their own dists means you wouldn't need to recompile all of PDL just to add OpenGL later
14:24 lungching yeah, sounds like that would be helpful
14:25 lungching unfortunately, I don't have any ideas how to do it
14:25 lungching ugh, meeting time
14:35 vividsnow joined #pdl
15:07 Molaf__ joined #pdl
15:47 run4flat jberger, I proposed a similar idea in the past, though my intention was to have the documentation for non-installed modules available so users could find it.
15:48 run4flat I thought that we could even include information in said docs that would tell the user how to install
15:48 run4flat and the stub module would die upon load with information about how to get it
15:48 run4flat unfortunately, this was shot down
15:48 jberger yeah, I've been thinking about how that would work, the problem is syncronization
15:48 jberger (doc syncronization I mean)
15:48 run4flat not sure what you mean
15:49 jberger if you copy the docs from PDL::Backend::Slatec to the main dist, and then someone updates PDL::Backend::Slatec you need to release PDL with the copied changes or else they get stale
15:50 run4flat that is always a risk of this sort of setup
15:50 run4flat but that would hopefully be mitigated by the fact that we have a group of PDL porters who are aware of these things
15:50 run4flat furthermore, my idea is that the default backend stuff would have very different docs
15:51 jberger the best solution (assuming splitting the dist into several) would be to have a central website hosting the docs of all possible modules, then the death message point to that
15:51 run4flat maybe with a summary of what Slatec could do, but mostly focusing on how to install
15:51 run4flat hmmm
15:52 jberger sub PDL::AUTOLOAD { die "The method you have called is not available from any of your installed backends, perhaps you should visit "pdl.perl.org" to see if there is a backend that provides this module" }
15:53 jberger you could even make it smarter and do an online search if you have connectivity
15:53 jberger and yes, you could have overviews of supported backends
15:54 jberger and even known method names from those backends
15:54 run4flat well, like I said, I have had similar ideas in the past
15:54 run4flat but I don't think we should hash this out
15:55 run4flat at least, not until we've revisited what was discussed on the mailing list when I last brought this up
15:55 jberger do you happen to have a link to that?
15:55 run4flat as I recall, one of the porters said that he checked for the presence some way that my suggestion would break
15:57 run4flat starts here: http://mailman.jach.hawaii.edu/pipermail/pdl-porters/2009-October/001603.html
15:57 run4flat and continues into November of that year
15:59 run4flat And if we were to do this, we should probably do so in a move to PDL3
15:59 run4flat imho
16:07 jberger I agree with much of what I'm reading, thought I think my strategy is different in one slight way
16:07 jberger modularize based on dependency rather than on functionality
16:07 run4flat have you read Judd's concerns?
16:07 run4flat He was the primary dissenter
16:07 jberger still reading
16:07 jberger I see that chm is in favor generally
16:07 run4flat His concerns are the main ones that need to be addressed, imo
16:12 jberger quote you: "My greatest concern with modularizing PDL is one that you didn't raise:
16:12 jberger we'll get stuck in the middle and stagnate."
16:12 run4flat link?
16:12 jberger http://mailman.jach.hawaii.edu/pipermail/pdl-porters/2009-November/001618.html
16:13 jberger yes his concerns need addressing, but done well I think they will be by default
16:14 jberger in re your comment, what you think would be better, spinning off dependencies like PDL::Slatec or making a PDL::Tiny (the pure C stuff only) and having PDL (and the rest of the default modules) depend on it?
16:16 run4flat the more I've thought about it, the more I feel that "cpan PDL" should install the same feature set at the end of the day
16:16 run4flat but having PDL depend on the core stuff---I like the name PDL::Tiny---would be a way to simplify the whole thing
16:16 run4flat In effect, the PDL distribution would just be a bundle
16:21 jberger right
16:21 run4flat I remember the days when I wrote that string of emails
16:21 jberger in re: http://mailman.jach.hawaii.edu/pipermail/pdl-porters/2009-November/001620.html
16:21 run4flat I used to write a *lot*
16:21 jberger hahah
16:21 run4flat the net effect of this was to suck of everybody's time reading and writing email instead of code
16:21 jberger anyway, Judd likes that PDL brings in the whole bundle, but its for that reason that I don't depend on it
16:21 run4flat it took me a long time to realize just how many developer hours I wasted writing lengthy emails
16:22 run4flat right
16:22 jberger the only reason that Mojolicious gets away with that is that the whole bundle is super lean
16:23 jberger I cannot release software that will depend on external libraries that aren't needed AND need to be installed
16:23 run4flat well, fortunately that's not a problem with PDL
16:23 run4flat as you know
16:23 run4flat and as Chris has harped many times
16:23 jberger and until I can install without the blocking tests that come from the plotting libraries
16:23 run4flat external dependencies that are not available do not cause PDL's install to fail
16:24 run4flat why do they block?
16:24 jberger waiting for input
16:24 run4flat you mean OpenGL tests?
16:24 jberger and PGPLOT
16:24 run4flat really?
16:24 jberger yep
16:24 run4flat I've never had PGPLOT
16:24 run4flat so I've never encountered this
16:24 jberger so under cpanm (hides output) the thing just sits there
16:24 run4flat that should be an *easy* update to the test, though
16:25 run4flat and none of the other modules do this, to my knowledge
16:25 jberger I always install the whole thing, because who knows when I'm going to want a 3d plot
16:26 jberger so I follow my recipe: http://sourceforge.net/apps/mediawiki/pdl/index.php?title=Installing_Using_cpanm
16:26 jberger which gets you everything
16:26 jberger but notice that you have to cpanm -v OpenGL PGPLOT PDL
16:27 jberger but I have to install everything so that I will be able to use any part in the future
16:27 jberger this is in contrast to Judd's point
16:27 run4flat but, that's not what happens if you list PDL as a dependency in your module's Build.PL and a use tries to install it
16:28 run4flat and the number of PGPLOT users is dwindling
16:28 vividsnow joined #pdl
16:29 jberger ok, but Judd says that installing PDL should get him everything
16:29 jberger that way users are not frustrated when something is missing and they have to install it
16:29 jberger thats what his email (above) says
16:29 jberger you are saying that it already doesn't do that
16:30 jberger so that hypothetical user, now trying to use PDL::Graphics::PGPLOT now not only has to install PDL::Graphics::PGPLOT (and its fortran dependencies)
16:30 jberger he has to recompile PDL
16:30 jberger that seems like a worse scenario than the one he describes
16:30 jberger and its the one we already have
16:31 run4flat bingo
16:31 run4flat one of my chief frustrations with PDL's current build setup
16:31 run4flat not that I hit it... ever...
16:31 jberger i know it is
16:31 run4flat did I reply with this concern?
16:31 run4flat I'm still reading Judd's reply to my reply to his first reply
16:31 * run4flat chuckles
16:31 jberger (haven't gotten there yet)
16:38 jberger I'm looking at the Slatec code, and I see that there are lots of manual injection of subs into other namespaces
16:39 jberger shouldn't this be a concern of some other loader?
16:39 jberger Exporter or somesuch
16:39 run4flat do you have a link to Github handy?
16:39 jberger https://github.com/PDLPorters/pdl/blob/master/Lib/Slatec/slatec.pd#L518
16:39 run4flat thanks
16:40 jberger I'm only focusing on Slatec as an example
16:40 run4flat That's actually quite common in the PDL core
16:40 run4flat *core modules
16:40 jberger any external dep (and the pure C ones too for that matter) could be the target of this comment
16:40 run4flat I don't know why they use this idiom, but it's used in everything that uses PDL::PP, too
16:41 jberger I'm envisioning a Module::Pluggable like system
16:41 run4flat The reason, I think, is so that you get the function name *both* as a PDL method *and* as an exportable function
16:41 jberger I guess this would work under those systems
16:41 run4flat This way, when you say "use PDL::Slatec", it installs a bunch of PDL methods
16:41 run4flat and gives them to you as functions
16:41 run4flat make sense?
16:41 jberger yeah but there are nicer ways to do that
16:42 run4flat true
16:42 run4flat but the underlying concept is really awesome
16:42 run4flat :-)
16:42 jberger the methods should be in PDL::Slatec and then imported into the PDL and caller namespaces
16:42 jberger it is
16:42 jberger but it makes it more difficult to extract
16:43 run4flat Did you know that we have PDL::Exporter?
16:43 jberger then again, it may actually make it easier to extract in the short term
16:43 jberger ?
16:43 run4flat yeah
16:43 run4flat that may be something you could hijack for this purpose
16:44 run4flat since PDL::Exporter does not add too much
16:44 run4flat I mean, it's important for how "use PDL" works
16:44 run4flat but if you update PDL.pm's import method, you should be able to change PDL::Exporter
16:44 run4flat and reduce  these sorts of shinanigans
16:46 jberger ever seen Import::Into?
16:46 jberger https://metacpan.org/module/Import::Into
16:46 * run4flat checks
16:49 run4flat neat
16:49 jberger then see it in practice (eg utf8::all): https://metacpan.org/source/DOHERTY/utf8-all-0.009/lib/utf8/all.pm
16:51 run4flat *very* nice
16:51 run4flat alright, duly noted
16:51 run4flat unfortunately, I need to work. :-)
16:51 jberger indeed I should too
18:00 vividsnow joined #pdl

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