Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-05-09

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
04:40 ribasushi joined #perl6-toolchain
05:11 MadcapJake ugexe: `zef build` doesn't seem to run my Build.pm file https://github.com/Perl6-Noise-Gang/Audio-FluidSynth/blob/master/Build.pm
05:12 MadcapJake gotta get some sleep though
05:39 domidumont joined #perl6-toolchain
05:44 domidumont joined #perl6-toolchain
06:10 domidumont joined #perl6-toolchain
06:37 nine_ Random thought on Build.pm: we should really aim for a systemd like declarative way to specify the build process with hooks for custom code that users are really discouraged from using and which should only be meant for extreme situations.
07:06 moritz +Inf
07:21 cognominal joined #perl6-toolchain
07:37 cognominal joined #perl6-toolchain
13:06 sufrostico joined #perl6-toolchain
15:26 ugexe ive been saying for for 3 years
15:27 mst Build.pm is an utterly terrible idea, but not the most proximate yak as yet, I suspect
15:27 mst leont's build-graph stuff looks interesting
15:27 mst what we could really do with is an audit of what people are actually using Build.pm *for* to figure out what the feature set needs to be
15:28 mst nine_: I'd like our build process to be deterministic though, so systemd isn't the ideal thing to compare it to :)
15:28 ugexe almost all of them are for running make, or aborting the install for some reason
15:28 mst \o/
15:29 mst /o\
15:29 mst *sob*
15:31 MadcapJake My goal was to generate Perl 6 files when a user installs the module
15:32 ugexe s22 even mentions how to declare it: leaf nodes that are hashes which CURs are meant to ignore and builders/packagers can interpret and do what they need
15:33 MadcapJake So that I could change the bindings according to architecture, OS
15:34 MadcapJake if that's not the preferred route for accomplishing what I described, then what is?
15:39 ugexe MadcapJake: i'll check your build... fwiw you can do ZEF_BUILDPM_DEBUG=1 to get the output
15:40 MadcapJake ok well I just took out the Panda::Build stuff and there's a few kinks that I haven't ironed out yet.  I'll get it working as a regular script then plug the builder interface back in
15:40 ugexe but you certainly dont need to depend on panda for this
15:41 MadcapJake yeah? how do I do it then? just a build sub?
15:41 MadcapJake or will zef just run the script and it can do it's thing
15:41 ugexe https://github.com/titsuki/p6-Term-Readsecret/commit/bd18dabcfb36cd21c7a606c3a07120fb167545bc
15:42 ugexe that shows how to turn a build.pm that requires panda into one that does not
15:42 ugexe basically you remove the is Panda::Builder and add the `method isa`
15:42 MadcapJake ok neat thanks! just a Build class with a build method then eh? (the rest I assume is LibraryMake stuff, right?)
15:42 ugexe thats only for compatability with panda, zef does not need it
15:43 ugexe yeah, but you need the method isa to work with panda this way
15:43 MadcapJake gotcha
15:44 * MadcapJake notes that he'll need to do that LibraryMake stuff too
15:46 ugexe first thing though, the META.info has a comma after the last item
15:48 ugexe then it looks like you call transpile and pass it Str args, but calls `.child` on them
15:49 ugexe s/.child/.IO.child/ and it builds
15:50 tadzik I may just remove that bit from old panda so you don't need to torment yourself with isa
15:51 nine_ ++tadzik
15:51 tadzik there may have been one at some point, when Build was actually meaningful, but these days there is no reason for it to be there
15:54 tadzik or so I think
15:55 tadzik I know p6doc uses some actually panda-specific features, but iirc it's just Installer
15:55 tadzik I'd be as happy as everyone to see Build.pm gone, fwiw :)
15:56 tadzik requirement gone as of now
15:56 tadzik no, I didn't bump the version number ;)
15:58 MadcapJake why all the Build.pm hate in here? :P
15:58 mst because it's complete crap?
15:59 MadcapJake what is?
15:59 tadzik (hey, sorry for making this whole module thing work for the last 5 years... :P)
15:59 mst it's a classic example of "we've no idea what we should be doing here, so let's try something" ossifying into a de-facto standard without anybody going back and actually designing it
15:59 mst tadzik: hey, if I'd tried to achieve the same thing at the same time, my answer would've been just as crap
15:59 mst you did fine. but it's still crap.
16:00 MadcapJake I don't see anything wrong with having essentially a post-download script that lets module authors generate files or install libraries
16:00 tadzik Build.pm is as much of a PITA to me now as to everyone else (or more so), since it makes shipping a new, incompatible panda version a massive clusterfuck
16:00 mst MadcapJake: yes, but it's rather more than that
16:00 tadzik (for modules that actually depend on panda now)
16:00 mst an actual *just* a post-download script would be a much nicer thing
16:00 MadcapJake mst: how so?
16:00 MadcapJake what makes it more than that?
16:01 tadzik my reasoning, as far as I remember, was "Perl 5 has that Build.PL thing, I'll just do something similar but make it not spawn a subprocess because that's costly as fuck"
16:01 tadzik ah, I know why inheritance now
16:01 tadzik so you can have your own Build.pm do a callsame at the end, or something? I guess? Maybe? :)
16:02 tadzik nah, that'd just recurse indefinitely
16:02 tadzik *shrug*
16:02 nine_ MadcapJake: #1 Build.pm is panda-specific even if there are hacks around that. #2 panda will load all Build.pm files into the same process, overwriting the same class Build every time. I'm not even sure that's supposed to work...
16:03 ugexe in addition to that, when you smoke test and use Build.pm in the same process as the package manager, you make it possible for other modules to cause build failures for other modules by breaking the packager
16:03 nine_ MadcapJake: #3 you cannot reason at all about what a given dist will install if it contains a Build.pm. For all you know it could replace your distribution with something downloaded from elsewhere. IOW you cannot statically analyze it at all.
16:05 tadzik heh, I think there are modules who do exactly that :P
16:05 MadcapJake While #1 and #2 are implementation-dependent, I can definitely see now how #3 could be problematic.
16:05 jdv79 #3 sucks pretty hard
16:05 tadzik then again, if they need it they may as well do it in BEGIN { } time or whatever
16:06 ugexe a solution to that is mentioned in S22 under %?RESOURCES `"resources" : [ 'libraries' : { 'blah.so' : build-time }`
16:07 jdv79 do we have ability to spec the arch yet?  i think that was a/the major issue there; specifically.
16:07 tadzik there's a module somewhere that grabs .so or .dll from the internet in build-time, isn't that gtk::simple?
16:07 MadcapJake jdv79: yeah that's what I'm wondering, I see that generating on install is dangerous but then how can I hinge on architecture wrt nativecall types?
16:08 tadzik yep: https://github.com/perl6/gtk-simple/blob/master/Build.pm
16:08 jdv79 but does that handle other archs?  pretty sure that's not the full breadth of reasonable possibilities.
16:08 tadzik "dangerous" is a little bit silly when you literally download code to run it on your computer
16:09 tadzik you'll never be safe from shit in modules you download
16:09 nine_ MadcapJake: the idea is that the installer can do whatever you need and there is a declarative way to tell it to do so. Preferably this infrastructure is even shared between installers.
16:11 nine_ MadcapJake: a package repository or database like modules.perl6.org will then be able to give detailed analysis (like "which module contains a libp5helper.so?") without even having to be able to run Perl 6 code
16:11 MadcapJake so by declarative you mean like S22's %?RESOURCES as ugexe mentioned?
16:12 nine_ yes
16:13 MadcapJake I'm still left wondering how I would handle int32/int64 in my nativecall bindings
16:15 nine_ MadcapJake: how exactly do you do that right now?
16:16 MadcapJake I don't! :P I wrote a Build.pm that parses header files and generates Perl 6 subs (like gptrixie) and I was planning on just using ternaries for arch/os related stuff
16:19 MadcapJake but then that would mean that all of the nativecall stuff would not be in the gh repo nor available for static analysis until after Build.pm is run (which will probably be at least half of the code)
16:21 nine_ Inline::Perl5 does it at BEGIN time: sub p5_size_of_iv() is native($p5helper) returns size_t { ... }; BEGIN my constant IV = p5_size_of_iv() == 8 ?? int64 !! int32;
16:21 MadcapJake I could generate both, do it on my end and thus include it in the gh repo, and then in my non-arch-dependent code, use the appropriate nativecall "backend". but this would mean users are installing lots of extra junk, I suppose that's preferable though, perhaps?
16:24 MadcapJake nine_: cool! what's the p5_size_of_iv function from?
16:25 nine_ p5helper.c that comes with Inline::Perl5. Of course that means that I have to build a shared library as part of the build process...
16:25 nine_ You could however parse those headers instead
16:30 domidumont joined #perl6-toolchain
17:13 hankache joined #perl6-toolchain
17:29 Kassandry joined #perl6-toolchain
19:43 sufrostico joined #perl6-toolchain
21:25 sufrostico joined #perl6-toolchain

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary