Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2013-12-15

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

All times shown according to UTC.

Time Nick Message
00:00 jberger joined #pdl
01:24 webart oh I saw "store several terabytes, but pay less than $10/month."
01:24 webart I guess you have a lot :P
02:17 jberger_ joined #pdl
02:20 vicash left #pdl
03:40 jberger__ joined #pdl
05:54 jberger has anyone ever needed 6 uses of the 'local' keyword in one function before? :-D
05:54 jberger http://pastie.org/8553146
06:02 jberger I guess I can get rid of one :-/
13:09 dcmertens joined #pdl
15:34 vicash joined #pdl
16:25 chm joined #pdl
16:27 chm run4flat : Thinking about MOP and PDL3, I wonder if any more thought has taken place about connecting the Prima object model with perl5 mop, and Moo[se]?
16:28 chm Prima seamlessly generating and interacting with Moo or perl5-mop might be a nice addition?
16:28 chm Any thoughts about an MOP for Prima?
16:35 jberger dcmertens ^^
16:36 chm Maybe something along the lines of the inside-out support for p5-mop could be implemented for Prima types
16:42 sivoais jberger: oh, hey, have time to look at your PRs for Alien::Base? I have one and I see a couple other useful ones :-)
16:42 sivoais <https://github.com/jberger/Alien-Base/pulls>
16:42 jberger yeah, that's on my plate for today
16:42 jberger this was an aweful week for free time
16:43 jberger work was busy on its own, AND I had both work and non-work holiday parties
16:43 sivoais I know the feeling. :-)
16:43 jberger *awful # obviously
16:45 jberger the nuisance of testing AB is slowing me up a little this particular morning, but that's my laziness and not the other thing :-)
16:47 jberger ick, there are few old ones I had completely forgotten about :-/
17:02 dcmertens jberger, thanks
17:03 jberger dcmertens, any progress on Primo?
17:03 dcmertens chm, I was thinking recently about writing a Moo-ish sugar layer for Prima
17:03 dcmertens but no, no progress or Prima, or Hummingbird
17:03 dcmertens not since last spring
17:03 dcmertens :-(
17:03 jberger its been quite a year for you tho
17:03 jberger (me too)
17:03 dcmertens yeah, no kidding
17:03 dcmertens :-)
17:04 dcmertens also, yesterday and today I've been hammering on some Prima stuff
17:04 dcmertens but it's been higher level stuff, not OO things
17:14 jberger sivoais, got yours in
17:17 sivoais ah, thanks! I was wondering if Repository::HTTP is supposed to support https:// links as well. I see HTTP::Tiny supports it (if you have the deps)
17:17 jberger right
17:17 sivoais it's not an issue I came across, but something to note in the future
17:17 jberger it should, does it not?
17:17 sivoais well, several parts of the code assume the link starts with http:
17:18 sivoais (including a part of my patch)
17:18 jberger hmmm, you're right
17:18 jberger that's bad
17:18 jberger wow, I'm rusty on this code base
17:19 jberger Repository::HTTP was always most kludgy
17:19 jberger you wouldn't believe how close I came several times to using Mojo::UserAgent rather than the LWP stack
17:20 sivoais haha :-)
17:20 sivoais Is the best practice to include the tarball in the CPAN package? I wasn't sure about that point
17:20 jberger tarball of the C library source?
17:20 jberger depends
17:21 jberger I build AB with the idea that you wouldn't need to cut a new Alien:: release if the library released a new version
17:21 jberger if you bundle the library, then you would have to do that
17:23 sivoais yeah... but in some cases you may need to patch it
17:23 sivoais for various reasons
17:28 jberger right
17:31 dcmertens o/
17:32 dcmertens heading to my sister's handbell concert
17:32 dcmertens happy holidays!
17:32 dcmertens :-D
17:35 jberger o.
17:35 jberger o/
17:36 jberger sivoais/chm, ok that's two merges, two comments, one I'm going to ask preaction about (https://github.com/jberger/Alien-Base/pull/24) ... and then there's this one: https://github.com/jberger/Alien-Base/pull/30
17:37 jberger I'm still not sure what I want to do about it
17:48 chm jberger, sorry I missed the discussion, I'm hoping to address some of the Alien::XXX stuff this week
17:48 chm I'll take a look at thelatest Alien::Base
17:49 chm I'm handicapped by the fact that I know nothing about Module::Build
17:50 chm One idea I had was a modified Alien contract where a standard use Alien::XXX would die if no XXX was there
17:51 chm However, it would install an Alien::XXX with configuration info that could be accessed with a different call or an arg to the import call
17:52 chm The idea is that since Alien::XXX would always install, CPAN Testers reports could indicate FAIL for
17:52 chm unsupported platforms and provide context in tghe testoutoput that could help Alien::XXX developers
17:53 chm Does that seem doable for Alien::Base, jberger?
18:01 jberger sorry, stepped away for a second
18:03 jberger chm, I don't understand your suggestion
18:09 sivoais I'm reading it as something where you can use different options with the Alien package
18:09 sivoais use Alien::XXX q(:system); use Alien::XXX q(:local); use Alien::XXX q(:check);
18:10 jberger the problem with that is placement
18:10 jberger its the Perl module that is going to do that, but its the end-user who really should have the choice
18:10 jberger it would probably have to be an ENV var
18:13 jberger BEGIN {ALIEN_XXX_CHOICE} = 'system'} use Module::Needs::XXX; xxx(...);
18:13 jberger BEGIN { $ENV{ALIEN_XXX_CHOICE} = 'system'} use Module::Needs::XXX; xxx(...);
18:16 jberger back to PR 30
18:17 jberger the more I think about it, the more I think I agree with the PR
18:22 chm jberger, I guess my question is what happens in an Alien::XXX module using Alien::Base when the XXX cannot be installed.
18:22 chm My suggestion is that Alien::XXX would be installed but that use Alien::XXX would croak
18:23 jberger that seems counterintuitive to me
18:23 chm but that that behavior could be changed by passing options to the import
18:23 chm What I am hoping to accomplish is a fix for the problem where non-functioning Alien modules
18:24 chm for a given platform would be able to have a test suite and other options to help with the install and development.
18:24 jberger you seem to be thinking more about the tester system, but the problem is an end-user install chain
18:24 chm Where would you say the problem is?  I see the biggest single issue is that the Alien::XXX developers
18:24 jberger if I install some deep chain that depends on an Alien:: module, it should be that install that dies and not the module that uses it
18:25 chm are often familiar with only one platform and they have very little ability to develop for other platforms.
18:25 chm The result is that Alien modules are often broken and useless on the very systems/platforms
18:25 chm that most need that functionaltiy (usually windows)
18:26 jberger true, but as I have said before, I think in most cases, windows systems will need pre-compiled binaries, since strawberry does not have a complete build chain
18:27 chm Regarding the install issue, the module depending on Alien::XXX should have a 'use Alien::XXX' in it.
18:27 jberger so the dev needs access to a windows platform or a prebuilt binary in any case
18:27 chm That *would* fail and but now the depended module would show unknown since the module dependency was not available
18:28 chm in the config stage.  NOTE: this is different in that the current approaches seem to assume if the Alien::XXX cannot install XXX, then the install itself fails.
18:28 jberger yes, that is how Alien modules work
18:29 jberger it is in the definition
18:29 chm My proposal would push the install failure up to the module actually use-ing Alien::XXX but now there would be the option
18:29 chm of clear feedback on where the problem was and the Alien::XXX module could always have a test which would show a failure
18:30 chm if a given platform was not able to complete the install of XXX.  That seems much more likely to result in an eventual fix.
18:30 jberger I just really disagree
18:30 chm If you look at the Alien manifesto, the definitions just says it should croak.  It says *nothing* about whether the install should build an Alien::XXX for testing.
18:31 jberger the Alien:: module's main task is to install the external library (or else know that the system provides it)
18:31 chm My proposal is that something would always be built, although if the tests failed, it would not be installed.
18:32 chm The problem I am trying to fix is that current approaches to Alien::XXX don't even make it past the config stage.
18:32 jberger nor should it
18:32 chm So there is no feedback from attempts to install the Alien::XXX which means that the developers get no real
18:32 jberger the dependent module is not available, as with any other perl module
18:32 chm feedback on what is missing and where a fix might be needed.
18:33 chm Sigh, if your goal is the keep the same old, same old., then clearly you would prefer that Alien::XXX only work in a limited
18:33 jberger that feedback is available from the Alien::XXX module, not the dependent module
18:33 jberger its a separation of concerns
18:33 chm and crippled fashion except on a given developers platform of choice.
18:33 jberger Alien::XXX must be thought of as a separate entity from its dependent modules
18:34 chm I fail to see how failing in configure is informative when failing in tests is more informative and results in no Alien::XXX installed unless forced.
18:34 jberger lets say I'm a C author and I chose to provide an Alien wrapper for CPAN for it
18:34 jberger must I also provide a dependent module to see if it works?
18:34 chm Again, even in this case, the Alien::XXX module should croak as per the original specification
18:35 chm I'm confused here, I'm saying if an Alien::XXX module is built for install, the tests should indicate if it worked.
18:35 chm At that point an install would take place.
18:35 chm If the user forced an install, the Alien::XXX should croak which is whatwould happen in the test suite as well
18:36 chm Again, I think Alien::Base is great and would help here directly except that I don't know M::B.
18:37 chm But, I do see the problems of alien modules not getting good feedback from tests.
18:37 chm And yes, without good feedback there is no way for fixes to happen.  In fact, short of me trying Alien::XXX installs
18:38 chm by hand and emailing the authors, there is no way to get the details of a platform failure back to the developers
18:38 chm for a possible fix.  Right now, if I want to fix an Alien::XXX for my platform, I basically have to reverse engineer what
18:38 chm is currently being done, understand the needed build process, and then determine how it might be fixed.
18:39 chm Again, in my case, not knowing M::B is an enormous obstacle although I really like the idea that M::B is the basis
18:39 jberger M::B is not hard to understand really
18:40 chm for an Alien::XXX configuration since the user may not evenhave the needed make or whatever
18:40 chm I'm glad you understand M::B.
18:41 chm I can see what is being done, I just can't get things working quickly.  My focus has been on PDL and OpenGL
18:41 jberger unfortunately, I've chatted about 15 mins longer than I should haev
18:41 chm with little free time to spend coming up yet another learning curve for a complex package.  Even if the approach
18:41 * jberger needs to leave VERY soon
18:41 chm is relatively elegant and modular.
18:41 * jberger still needs to shower/dress
18:42 chm Me, I'll keep you posted on my other progress.
18:42 chm o/
18:42 jberger o/
18:43 chm jberger, P.S. thanks for the conversation---it has helped to clarify things on my end.
18:44 chm I'll try to collect my updated thoughts for an Alien2 manifesto.  Cheers, o/

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