Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2014-05-02

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

All times shown according to UTC.

Time Nick Message
00:00 mohawk where would what live?
00:01 sivoais Inline::Interface. Would it be its own mostly-empty dist?
00:01 mohawk good question
00:01 mohawk that's probably best
00:02 mohawk otherwise if it were in Inline, it would pull that in
00:02 mohawk although that might not be a catastrophe
00:02 mohawk probably easiest to put it inside Inline, actually
00:02 mohawk it's not like Inline has a massive footprint
00:05 mohawk so, conceptually (maybe in there but commented for now), A::L will "depend on" Inline::Interface
00:05 mohawk does that make sense?
00:07 sivoais yeah
00:07 sivoais I'm testing that out
00:08 mohawk and the docs for it could supply a suggested *.t file to test the ::Inline method
00:08 sivoais do you think AUTO_INCLUDE should be part of the return value
00:08 mohawk if it's necessary, yes
00:09 mohawk i'd expect it normally would be?
00:09 sivoais makes things simpler, I think
00:13 mohawk whatever any C program using the library would need
00:13 mohawk i'd be quite surprised if AUTO_INC weren't required, really
00:22 sivoais ok, it seems to work nicely... pushing
00:23 mohawk legend
00:23 sivoais <https://github.com/zmughal/p5-Alien-Leptonica​/commit/4c2eb76a595bdd55daeb0d492a3b10b493197​2a5#diff-95eb7763a757ef848783596d81efd185L7>
00:24 sivoais I've got a simple test in there too
00:24 mohawk seen
00:24 mohawk that's beautiful
00:25 sivoais now to do add the typemap in I::L and that should complete more :-)
00:25 sivoais :-D
00:25 mohawk amazing, dude
00:28 mohawk really amazing
00:28 mohawk and that test shows it really works
00:29 mohawk i'm seeing that Inline as workable going into Alien::Base - what do you think?
00:30 sivoais definitely. It's useful too. Making sure things build is frustrating.
00:31 mohawk damn right
00:31 mohawk and from a perl point of view, what better test for a C library being "built and ready to roll" than a snippet that works with Inline?
00:33 sivoais yeah, that's a two-in-one test
00:33 mohawk does jberger ever say much? ;)
00:34 sivoais I think he's been busy lately.
00:36 mohawk fair one
00:36 mohawk i might just make a patch and fire it at him
00:37 mohawk does A::L get & build the source, or just test it's there?
00:38 sivoais it has a pruned copy of the source and it builds it
00:39 mohawk awesome
00:39 mohawk where does it install?
00:40 sivoais to a shared directory in @INC
00:42 mohawk makes sense
00:42 mohawk in the same spirit as typemaps get installed, i expect
00:43 sivoais speaking of... how do I get the path to the typemap that get installed with a particular package?
00:44 mohawk that is an awesome question
00:44 mohawk welcome to ExtUtils::Depends!
00:45 sivoais so I want the I::L typemap at runtime so I can use it in I::L::Inline()
00:45 mohawk does I::L support EU::D?
00:46 mohawk look in GP's Makefile.PL for the 3 lines it takes
00:46 sivoais OK
00:46 mohawk it should be in A::L as well - same reason as the ::Inline discussion above
00:49 sivoais ok, so what is Gimp::IFiles ? I assume that is where the config is dumped
00:50 sivoais also... if something supports EU::D, shouldn't Inline 'with' support be mostly done?
00:51 mohawk IFiles is just a filename - it gets installed as ::Install::Files
00:51 mohawk sivoais, not really
00:51 mohawk it's easy for Inline to do so - there's still a gap, but you're right that it's small
00:51 mohawk i'm here to close that gap
00:52 mohawk i would say that if you support EU::D, that's what makes the A::L module small because you can just use the ::I::F variables
00:52 mohawk make sense?
00:53 sivoais yeah
00:53 mohawk so you were quite right, it's just via a certain path ;)
00:53 mohawk in other words, when i said "no", i meant "yes"
00:53 mohawk ahem
00:54 sivoais haha
01:03 sivoais mohawk: ok, so the main thing I see over using an Alien::Base directly is that this supports having a tree of deps rather than just the one
01:03 sivoais right?
01:03 mohawk i don't know what you mean by a tree of deps?
01:04 sivoais say you had Alien::Gimp and Alien::Gtk2
01:04 mohawk ok
01:05 sivoais and say Alien::Gimp->cflags only returns Gimp headers (unlikely)
01:05 sivoais but you also need Alien::Gtk2->cflags
01:06 sivoais you'd have to merge them, right? EU::D does that for you
01:06 mohawk it doesn't merge them as such
01:06 mohawk it just concatenates
01:06 mohawk it lets cc sort it all out
01:07 mohawk in fact, since GP effectively includes Alien::Gimp, it does only provide the GIMP C headers
01:07 mohawk but the tree thing isn't something i have thought about, because i never want to prune it?
01:08 mohawk EU::D just does the right thing
01:08 mohawk let's not agonise too much? ;)
01:08 sivoais I'm trying to see where EU::D fits with Alien::Base
01:09 mohawk A::B would provide (probably only in docs) the info for the A::* author
01:09 mohawk so they make a Makefile.PL that includes the EU::D snippet
01:10 mohawk and by inheriting off A::B, they'd inherit the ::Inline method (i think it's currently only a function, but i've made a note to fix that)
01:10 mohawk that method would rely on EU::D and the info available from that
01:10 mohawk the author would supply the extra bits like the AUTO_INCLUDE
01:10 mohawk done
01:10 mohawk i haven't read too deeply yet into what A::B provides
01:11 sivoais mohawk: this is my current Makefile.PL <https://metacpan.org/source/ZMUGHAL/​Image-Leptonica-0.01/Makefile.PL#L46>
01:12 sivoais so instead I'll pass the A::* cflags to EU::D and get them back from EU::D
01:14 mohawk in the M.PL?
01:15 mohawk that's the way i'd recommend
01:17 mohawk wait
01:17 mohawk having read it, just pass it along to EU::D
01:18 mohawk sorry, that's what you mean
01:18 mohawk wait
01:18 mohawk the way i'd recommend
01:18 mohawk in the I::L M.PL, which is what we're talkingabout
01:18 mohawk is what you say - pass into, get out of, EU::D
01:18 mohawk phew
01:19 mohawk i am still getting baffled by the difference between A::L and I::L
01:19 mohawk apologies
01:20 sivoais like this in I::L's Makefile.PL <https://gist.github.com/zmughal/11465847>
01:21 sivoais in the future that could use EU::D->new( 'I::L', 'A::L' )
01:21 mohawk not what i'm thinking of
01:21 mohawk damn, i mean yes
01:22 sivoais I'm confused with all these abbreviations as well :-P
01:22 mohawk it's not the abbreviations, it's the actual thing that throws me ;)
01:22 mohawk alien would do ->new('A::L'), ->set etc, ->save
01:23 mohawk i::l goes ->new('I::L', 'A::L'), ->pkg_vars - done
01:23 mohawk does that make sense?
01:24 mohawk the 2nd one would include ->add_typemaps
01:24 * sivoais nods
01:24 sivoais makes perfect sense
01:24 mohawk awesome
01:25 mohawk and I::L's ::Inline func/method will call and add to A::L's as said before
01:25 sivoais I'm going to have to come back to this later though...
01:25 mohawk A::L's one can just use the ::Install::Files data stored by EU::D
01:25 mohawk grin
01:25 sivoais I'll note this down
01:29 sivoais mohawk: I anticipate one problem. How do I use EU::D in A::L if A::L hasn't been installed yet?
01:29 sivoais I don't know the paths
01:30 mohawk this would be done in A::L's Makefile.PL
01:31 sivoais yes, set_inc(), set_libs() are done when Makefile.PL runs, right
01:31 sivoais but that happens before the .h and .so files are installed
01:31 mohawk A::L's substantive module would rely on the ::I::F module being there when it runs, which is post M.PL
01:32 mohawk sure, but you know where they'll go
01:32 sivoais I think that'll require digging in Alien::Base
01:33 mohawk no doubt
01:33 mohawk do you use A::B yet?
01:34 sivoais yeah, A::L extends A::B
01:34 mohawk cool
01:34 mohawk i'd ask what it provides but i should just rtfm
02:00 jberger wow look at the back log!
02:00 jberger mohawk: hi
02:00 mohawk jberger, pleased to virtually meet you!
02:00 jberger yes I have been spectacularly busy lately
02:01 mohawk i have in fact just finished r-ing tfm on A::B
02:01 jberger same to you sir
02:01 mohawk jberger, have you read through the above, or would you like me to try to summarise?
02:01 jberger it's quite a read
02:01 jberger If you could please summarize
02:01 mohawk sure thing
02:02 mohawk sivoais and i were talking through the platonic Alien module and how it would interact with the XS counterpart making a full perl module
02:03 mohawk clearly using Alien::Base is an essential step
02:03 jberger provision and location
02:03 mohawk getting the XS part to work easily benefits enormously from using Inline
02:03 jberger I won't say it's anywhere near perfect yet, but I hope it's a good start
02:04 mohawk supporting XS is easy in an extremely concise way using ExtUtils::Depends
02:04 mohawk so we've been talking through the specifics of how to make all these modules work together
02:04 mohawk i'm part way through adding the necessaries to Inline, and i've added some to EU::D
02:05 mohawk i'll show you the relevant bit of Inline doc, it's only a couple of paras:
02:05 mohawk http://search.cpan.org/~sisyphus/Inlin​e/Inline.pod#Playing_%27with%27_Others
02:06 mohawk i propose adding an inheritable ::Inline module to Alien::Base, along with a snippet of docs on how to use ExtUtils::Depends
02:06 jberger xs that depends on xs shouldn't necessarily be related to ab
02:06 mohawk i see you're using github for it
02:06 mohawk damn, i said ::Inline module - meant method, obviously
02:06 jberger and online should just work with inline
02:07 mohawk so - if you are receptive to the above, i'll github fork A::B and have at it?
02:07 jberger well I goofed too. swipe type. s/online/alien/
02:08 mohawk wait, does alien implement a "::Inline" function?
02:08 mohawk i don't see it
02:09 jberger I don't get what you mean, inline is just a wrapper for compilation
02:09 mohawk what i mean is literally reducing even further the number of lines required to use with Inline
02:09 mohawk yes, it is
02:10 mohawk i'm just proposing something that will make it even more perl-one-liner-ish
02:10 jberger it's just a couple keywords to eumm no?
02:10 mohawk it = what, supporting EU::D?
02:13 jberger I don't know what eud is for
02:13 mohawk it standardises the storage of -I, -L, -l, etc
02:14 mohawk meaning Makefile.PLs become fun to write, not a horrid twisted nightmare like Gimp-Perl's was when i started looking into it
02:14 mohawk and that might actually be an understatement
02:16 mohawk i'm aware that the Alien hierarchy is actually an alternative to the EU::D concept, because with the Alien module, one has the .so already loaded
02:16 jberger right
02:17 mohawk it seems to me that getting at any library-specific data structure is going to require a typemap etc
02:18 jberger it will use a system installed version if available and install one locally if not and handle must of the compiling and loading for you
02:18 mohawk sure
02:18 mohawk but on doing "use Alien::X", one ends up with a loaded .so
02:18 mohawk that seems to me to be essential to operating with those C data structures, to do further XS compilation - no?
02:18 * jberger moves to a proper keyboard
02:18 mohawk grin
02:19 jberger at use time that is what happen (getting a loaded so) at dependent module build time you get compile flag
02:19 jberger s
02:22 sivoais EU::D lets you say: "I want the build time flags of that module" so you can use them for your own builds
02:23 mohawk believe me, i know what EU::D provides ;)
02:23 mohawk my point is that it seems to me that the "customer" for Alien::* modules is a perl module that will provide a proper perl interface
02:24 mohawk and to do so it will probably need to do some XS itself, as mentioned above - no?
02:25 jberger not usually no
02:25 jberger oh, wait, I misread
02:25 jberger yes
02:25 jberger (sorry, reading too fast)
02:25 mohawk i've been doing that all evening ;)
02:25 mohawk so
02:26 jberger https://metacpan.org/pod/Alien::Base​::Authoring#Alien::Base-for-Building
02:26 mohawk if further XS compiling is required, let's use EU::D which makes parts of that really easy
02:26 mohawk yes, i saw that earlier
02:27 mohawk are you saying you don't see a reason to support EU::D?
02:27 jberger I think it already does what EU::D does
02:28 mohawk it spells it out every time
02:28 jberger unless I am mistaken (I am literally just reading the EU::D docs for the first time)
02:28 mohawk you are in principle correct
02:28 mohawk the point is, that if i'm writing the alien counterpart (as i'm now calling it)
02:29 mohawk my Makefile.PL can just go:
02:29 mohawk my $pkg = new EU::D My::Package, Alien::Pkg;
02:29 jberger let me put it a different way, I think an interface between these two would be an excellent candidate for a separate CPAN module, I would have to see a major benefit to include an extra dependency at this level
02:29 mohawk WriteMakefile($pkg->method_name);
02:29 mohawk done
02:30 jberger remember that AB is at the base of a very large compilation chain by the time you get to the end-user product
02:30 mohawk well, you wouldn't need an extra dependency
02:30 mohawk this is the great thing
02:31 mohawk because i'm documenting / updating EU::D, you'd only need to provide an extra .pm file with a few lines in, to support EU::D
02:31 mohawk so if i the counterpart-author want to use EU::D, i can
02:31 mohawk if i like cut-and-paste programming, then i can do that instead
02:31 mohawk you the maker of A::B don't need any extra dependency
02:32 mohawk the interface required to support it is dead simple
02:32 jberger are you the author/maintainer of EU::D
02:32 jberger ?
02:32 mohawk i contributed
02:33 mohawk specifically, i contributed the documentation for the interface it wants from its "::Install::Files" modules
02:33 mohawk that is therefore what one must support
02:33 mohawk code is malleable, docs are sacred
02:34 jberger I would look at what was necessary for inclusion, but I still am not sure what the added benefit is
02:34 mohawk i think you are sure, but i think you're saying it doesn't justify the cost ;)
02:35 jberger I'm not trying to sound like a jerk or anything, but you can imagine that all the code that is included in the AB core distro is code that I and the other maintainers have to shepherd for the rest of forever
02:35 mohawk you don't need to add any dependencies for this
02:36 jberger put it this way, I would look at what you would want to contribute to the AB, but I'm not guarenteeing anything (we have dev-group anyway now so its not just my vote that is needed)
02:36 mohawk sure
02:36 mohawk well, when i get to it (quite soon)
02:37 jberger A::B is already the most complex thing I have ever written, any added complexity (on our end) will need to come with marked benefit
02:37 mohawk i'll do the github thing and the dev-group can have a look
02:39 mohawk my personal design philosophy is that deleting code (and therefore complexity) is a wonderful thing
02:39 mohawk the Gimp-Perl build system was about 400 lines of accretion
02:40 mohawk it's now about 100 lines and easy to read/understand
02:41 jberger I absolutely agree
02:42 mohawk anyway, the promise i'm making is that the minor change i'm proposing here will lead to the same simplification for many, at no serious extra complexity for A::B maintainers
02:42 mohawk but! don't take my word for it - see the code when i make it
02:42 jberger :-)
02:43 mohawk what i'm taking away here is that you're content to look at what i produce, and the dev-group will take a look
02:43 mohawk is that your position?
02:45 jberger yep
02:45 mohawk cool potatoes
02:45 mohawk and/or beans
02:45 jberger that is basically always true (though a head's up before a blind PR is always a good idea)
02:45 mohawk sure
02:46 mohawk and the not-adding-a-dependency thing isn't a consideration i had, but i can now incorporate it easily
02:47 jberger its hugely important for such a low level module
02:47 mohawk i did look at the list of dependencies
02:47 mohawk and i get you!
02:49 jberger Alien::Base --> Alien::MyCLibrary --> MyCLibrary::PerlBindings --> SomeModuleThatNeedsCLibrary --> App::MyActualProduct
02:49 jberger ^^ that is basically the best-case dependency scenario
02:50 mohawk sure
02:51 mohawk except the penultimate one might not be there
02:51 jberger maybe not
02:51 mohawk a minor quibble ;)
02:52 jberger but for every time that's true, it also possible that the penulitmate is three more layers deep
02:54 jberger The reason I formed the dev-group is .,, by the time I wrote AB, I no longer really needed it, so while I try to shepherd its development and keep the vision sound, the other devs are people who actually need it for their work
02:56 mohawk it's important to have the acid test of people really using it
02:58 jberger Alien:: modules are going to be hugely important for PDL going forward certainly
02:59 mohawk well, yes
02:59 mohawk that's part of my "vision thing"
03:43 drrho joined #pdl
07:56 rindolf joined #pdl
08:45 mohawk i'd appreciate opinions on http://testing.gimp.org/tutorials/Basic_Perl/
12:59 gtodd mohawk: nice ... what I *really* want is some kind of generic plotting SVG surface so I can use pdl or re.pl as a shell and use perl to plot and play and graph data into SVGs.   I'm agnostic - could be gimp illustrator chrome inkscape firefox ....  preferably all of the  above ;-)
13:00 gtodd mohawk: ;-) but seriously though ... I'll try following along the gimp-perl tutorial. It looks pretty good from a quick glance.
13:03 gtodd I'm curious ff Alien:: had existed, is that where all XS using modules would have lived?
13:03 gtodd I guess I'm asking how alien is Alien:: ?
13:05 gtodd is it strictly for wrapping existing libraries (i.e. that exist for some other real application) ?
13:09 gtodd e..g when I first heard of Alien::V8 I thought I'd be able to drop some javascript library into a directory and have it wrapped or made convenient to wrap in callable from perl subs ...
14:06 vicash gtodd: Alien and XS are for different purposes. from what I understand, Alien is to help install dependent libraries for any project that may need native libraries on that system. these libraries may internally be used by XS and/or Perl Inline::C style modules .
14:07 vicash gtodd: this way one can abstract out installations of libraries for different OSes using an Alien::* module
14:08 gtodd right
14:08 gtodd thanks
14:14 gtodd for the clarification.  Of the few things I've tried (e.g. V8) some that build and install fine on my system wouldn't build under Alien:: and since I had mostly misunderstood the purpose of Alien:: I'd not looked at it much.  Alien::Base makes it easier to grok too.
14:15 drrho joined #pdl
17:01 mohawk joined #pdl

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