00:27 llfourn joined 00:35 camelia joined 01:27 llfourn joined 02:04 vendethiel joined 02:48 ilbot3 joined 02:59 zhi joined 05:40 vendethiel joined 06:39 karl_ joined 06:45 karl_ left 08:01 geekosaur joined 08:02 geekosaur joined 08:19 domidumont joined 08:22 domidumont joined 10:59 vendethiel joined 11:01 patrickz joined 11:03 patrickz joined 12:33 mohij joined 12:34 vendethiel joined 12:47 mojca joined
mojca I would like to package MoarVM (and Perl6) in MacPorts and I'm having some issues with it, mainly connected with the use of internal vs. external libraries like libuv, libtommath etc. 12:48
In the perl6 channel people told me that I should really try to use the internal libraries (shipped with the tarball) 12:50
but then I have this problem: github.com/MoarVM/MoarVM/issues/321
timotimo wait wait, don't we have macports already?
cf. trac.macports.org/ticket/47803 12:51
mojca whoooops
timotimo trac.macports.org/ticket/48904 - a bit less out of date
mojca I didn't see it
timotimo [coke] is your contact for this :)
mojca I'm sorry, my bad 12:52
timotimo don't worry about it! :)
mojca Just to make sure: did anyone already package Perl6 then :)
timotimo i honestly have no clue about macports
mojca OK, in any case we desperately need to update the port in order to make it compatible with the latest release (and also fix it in various ways then) 12:54
timotimo OK 12:56
in that case your help would probably be nice to have! 12:57
mojca does [coke] refer to the irc user (including the brackets)? 13:00
lizmat mojca: yes 13:01
well, [Coke] technically
mojca In case he's not listening at the moment, does anyone else know what "may need ExtUtil::Command if by chance our default perl5 binary does not match what Apple ships." could mean? 13:23
I opened trac.macports.org/ticket/50153 for MacPorts 14:25
I'm looking forward to see [Coke]'s feedback, so that we could eventually add perl6 to MacPorts 14:26
and I need some of your general help to fix this issue with conflicting locations of files of 3rd party libraries 14:27
14:30 leont joined 14:42 _wiz_ joined
_wiz_ hi. 14:42
I want to build MoarVM using the installed libffi, but 14:43
probing whether your compiler thinks that it is gcc Shared object "libffi.so.6" not found
and that part of the configure script doesn't seem to honor ENV{LDFLAGS}
timotimo did you try --with-libffi for this? 14:47
unfortunately i didn't do anything much with the build system yet
_wiz_ yes, i'm using that flag 14:48
that does unshift @{$config{usrlibs}}, 'ffi'; 14:50
and that probably adds -lffi
but not the necessary -L / -Wl,-R 14:51
[Coke] ok, opening a macport ticket with 30 issues on it is going to be hard to clear. :| 15:37
we specifically did not add universal variant because, IIRC, it failed testing. 15:40
the perl comment was added, I believe, by the macport committer who helped me get the port in; his concern was that we might end up with a version of perl that didn't have ExtUtil::Command available. (but ISTR that the version we depended on in ports would always have it) 15:44
what is "openmaintainer" ? 15:47
mojca: there are no tests. what would we run?
mojca I'm sorry, I noticed that about tests later
But tests can be run in nqp 15:48
[Coke] that's for the nqp port. right.
mojca openmaintainer means that other maintainers have the freedom to do trivial updates and changes
sometimes ports are maintained by people that are hardly active and it might take a long time to get approval to update the port 15:49
[Coke] is a maintainer a specific person or just anyone who submits a patch?
mojca openmaintainer means that anyone can, say, upgrade to a later version
developers are not supposed to change port unless maintainer approves the change (or doesn't respond for at leat 72 hours) 15:50
maintainers are assigned tickets
with problems etc.
[Coke] I'm happy to have have multiple specific maintainers. we also have github.com/MoarVM/MoarVM/tree/mast...s/macports which I don't think you found yet.
mojca no, I didn't
thank you
see what Ionic just wrote on #macports (echelog.com/logs/browse/macports/1451257200) 15:51
[Coke] I'm sure we don't want to create a macport bundle for each 3rd party library with mods we use. 15:54
(because it's a lot of work. It's probably the right thing to do, but we're not designed for that.)
hoelzro o/ #moarvm 15:56
mst that doesn't mean we wouldn't be rather happy if somebody else created those ports though, right?
dalek arVM: 64b13bc | coke++ | ports/macports/Portfile:
Warning no longer needed:

  See: echelog.com/logs/browse/macports/1451257200
search for "Ionic: can you please explain me your comment about Perl in MoarVM?"		 16:06
hoelzro I know that I asked last week about GC order in MoarVM, but I was wondering if there's an ordering if, for example, A is reachable from B but neither is reachable from the root set. Obviously that gets complicated when there are circular references 16:08
diakopter no, still not predictable 16:09
dalek arVM: dc0db11 | coke++ | ports/macports/Portfile:
Issue #321 - document conflict with std versions
 16:10
diakopter why would it help if it was predictable?
[Coke] mojca: there's 2 things added to our copy of the portfile. 16:11
hoelzro ok, that's what I thought
it would help because if A has a reference to B, it might need to do something with B in its own cleanup 16:12
but now that I type it, that seems like a contrived example, because any clean up B needs should be in B's gc_free
dalek arVM: db4e43d | coke++ | ports/macports/README:
Easier way to get checksums.

  mojca++		 16:16
arVM: 8d74b9d | coke++ | ports/macports/Portfile:
Update port to 2015.12
arVM: 851bdf0 | coke++ | ports/macports/README:
Even easier instructions

  mojca++		 16:17
[Coke] mojca: if you have updates for the README in our portfile directory, please submit a PR. Or gist an updated copy. 16:26
mojca ok, will do 16:27
I'll just commit the change if that's ok and then we can proceed to nqp?
[Coke] you have commit bits to moarvm? sure.
also, what's your comaint line look like? 16:28
happy to share. I was planning on doing this stuff this week since I was tied up with other perl6 things earlier, glad to have someone else show up with it mostly done. :) 16:29
oh, you meant in macports. also fine. 16:30
mojca yes, in MacPorts 16:32
I'll try to get the other changes to you afterwards
[Coke] So the plan for nqp and rakudo was to get them working with both moarvm & jvm backend variants, which is why I didn't just do them. 16:34
the plan for this week was going to be: hell with JVM for now, get nqp & rakudo ports that are moarvm only out there. 16:35
mojca nqp: should there be a single package supporting both?
[Coke] I was going to do the same thing of keeping a snapshot in the existing repos of the portfile to make it easier for a project dev (rather than a macport dev) get them committed on future releases.
mojca but if you don't care about jvm for now, we could start with moarvm only for now
[Coke] mojca: was going to use variants so you could use nqp-moar or nqp-jvm (or, I suppose, both) 16:36
Yes. don't care about jvm for now; it's not part of christamas.
*christmas
16:36 camelia joined
mojca ok 16:36
[Coke] So glad you showed up! I now get a day back on my holiday. :)
mojca a day back? 16:37
[Coke] I am happy to take comaint on the nqp/rakudo ones; but also fine with you being sole maint. Thanks for your help on the moarvm one, too!
camelia nqp-moarvm: OUTPUT«Confused at line 2, near "should the"␤ at gen/moar/stage2/NQPHLL.nqp:521 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:panic:105)␤ from gen/moar/stage2/NQP.nqp:921 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/nqp.moarvm:comp_unit:872)␤ from …»
[Coke] it was going to take me a day to get all that sorted, I imagine.
camelia ..nqp-parrot: OUTPUT«Can't exec "./rakudo-inst/bin/nqp-p": No such file or directory at lib/EvalbotExecuter.pm line 206.␤exec (./rakudo-inst/bin/nqp-p /tmp/tmpfile) failed: No such file or directory␤Server error occurred! Closing Link: ns1.niner.name (Quit: camelia)␤Lost connect…»
..nqp-jvm: OUTPUT«(signal ABRT)»
[Coke] mojca: nqp::say(3) ; # huh? 16:38
oh, no it was you saying "nqp: ". :)
you triggered the eval bot. :)
mojca ooooops 16:39
I initially copy-pasted the description for nqp from the README 16:41
"Not Quite Perl" (NQP) is a subset of Perl 6 clearly not intended as a Perl 6 implementation for end user. ...
I would like the description to mention "Not Quite Perl" somewhere. Otherwise it becomes impossible to remember the name
trac.macports.org/ticket/50154 16:53
[Coke] I would remove everything after "for end user" in the description. 17:12
that all refers to parrot, which we really don't support at this point. (would be fine in a list of all backends, but lets just leave it out)
(for nqp)
18:00 colomon joined 18:03 virtualsue joined 18:42 domidumont joined 18:59 mojca joined 19:04 llfourn joined 19:48 mst joined
_wiz_ any suggestions how to get LDFLAGS into the Configure.pl compiler checks? 20:00
hoelzro _wiz_: which flags in particular? 20:04
20:05 llfourn joined
_wiz_ I'd like to pass in -L/usr/pkg/lib -Wl,-R/usr/pkg/lib so that libffi is found correctly 20:06
hoelzro hmm, that I'm not sure how to do 20:09
_wiz_ I need this because I want to use the installed libffi. 20:12
hoelzro apparently Configure.pl will read from LDFLAGS and add them to the Makefile 20:14
_wiz_: ↑
_wiz_ it looks that way, but if it does, it does it too late. 20:18
hoelzro hmm
ah, I see 20:19
or maybe not...
I see it in the "link" part of Configure's report
but not libs
_wiz_: I got it working on my box 20:26
CFLAGS=-I/tmp/ffi-install/lib/libffi-3.2.1/include LDFLAGS=-L/tmp/ffi-install/lib perl Configure.pl --has-libffi
_wiz_ no, no luck here. 20:33
paste.debian.net/356775/
hoelzro _wiz_: which OS are you on? 20:38
_wiz_ NetBSD, why? 20:40
have you tried with LDFLAGS with a space inside?
hoelzro I haven't
20:41 brrt joined
hoelzro ok, just did 20:41
that worked =/
brrt ohhai
hoelzro o/ brrt
brrt hi hoelzro 20:42
_wiz_ hm, weird.a 20:46
hoelzro _wiz_: I think I understand now 20:49
I don't think the probing stuff respects LDFLAGS or CFLAGS 20:50
brrt no, it doesn't 20:51
can be made too
but doesn't do it now
hoelzro ah, well that explains it
brrt you'll want something like $config{ldflags} .= $ENV{LDFLAGS} // '' 20:52
somewhere
for what it's worth, /me can't figure out why libuv can build without cfmakeraw on solaris, but it's probably a mad flags issue
_wiz_ I just added printf debugging and here's the command line (even with LDFLAGS in the env): 20:54
gcc -o try try.o -lffi -ltommath -latomic_ops -luv -lm -lpthread -lkvm >/dev/null 2>&1
hoelzro that looks consistent with what I saw 20:56
so now making a change similar to brrt's suggestion would probably fix things
_wiz_ this seems to work: paste.debian.net/356781/
brrt actually, in keeping with nwc10++'s suggestion, the whole darn thing will want rewriting 20:57
as far as i'm concerned
and... i wonder
hoelzro that makes sense to me
you'll probably want a parallel CFLAGS change further up
brrt why have all this probing logic, when we can just compile a file using the standard compiler, and figure out all bits of our architecture 20:58
there are all sorts of compiler standard definitions that can be used to figure out our toolchain and platform 20:59
hoelzro mhmm
brrt and if you just evaluate the equivalent of 'cc', well, it will figure out all bits by itself
hoelzro sourceforge.net/p/predef/wiki/Home/
↑ comes in handy
brrt that's pretty much what i mean, yes 21:00
21:04 llfourn joined 21:06 virtualsue joined 21:27 domidumont joined 21:34 domidumont joined 21:48 ggoebel7 joined 22:00 _wiz_ left 22:05 llfourn joined 22:31 camelia joined 23:08 llfourn joined 23:21 vendethiel joined 23:33 vendethiel joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!