github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 4 June 2013.
05:25 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
05:34 FROGGS joined 05:38 tomyan joined
hoelzro I'm trying to build MoarVM, but I keep getting this error: 3rdparty/apr/.libs/libapr-1.a 07:12
hmm...if I do a fresh clone, I get this instead: /usr/bin/ld: 3rdparty/apr/.libs/libapr-1.a(rand.o): undefined reference to symbol 'uuid_generate@@UUID_1.0' 07:15
nwc10 does your machine have the APR headers installed in /usr/include ? 07:16
In that, someone reported that before (might have been you, I can't remember)
and it's really not obvious why it's going wrong
hoelzro yeah, I have the headers 07:17
under /usr/include/apr-1, though
nwc10 I wonder if that's it.
I'm guessing (obviously) but I wonder if the build is seeing headers from one version, but trying to link to a different version 07:18
hoelzro tries again after removing packages
no dice 07:21
07:23 lizmat joined
nwc10 hoelzro: I get that failure if I install the package libapr1-dev 08:03
hoelzro interesting
has anyone successfully built the VM on Arch Linux? 08:04
nwc10 and these 4 lines of error which I'm going to have fun with as all start with /
/usr/bin/ld: 3rdparty/apr/.libs/libapr-1.a(rand.o): undefined reference to symbol 'uuid_generate@@UUID_1.0'
/usr/bin/ld: note: 'uuid_generate@@UUID_1.0' is defined in DSO /lib/x86_64-linux-gnu/libuuid.so.1 so try adding it to the linker command line
/lib/x86_64-linux-gnu/libuuid.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
er, OK, 3 out of 4 did
hoelzro that's what I see 08:05
nwc10 but, that Ubuntu box will build MoarVM (and pass tests) before I install libapr
and fails afterwards
OK, nailed it 08:12
the problem is uuid-dev
if I install the package uuid-dev the build breaks
uuid-dev is a pre-req of libapr1-dev
hoelzro hmm 08:13
hoelzro tries
hmm
nwc10 so installing libapr1-dev has the side effect of making uuid.h available, at which point the *bundled* libapr sees it, and wants to use it
hoelzro hmm, I can't get rid of uuid that easily...
nwc10 and so the built bundled libapr now has a dependency on a symbol in the uuid library
I think you (or someone) needs to fix the MoarVM Makefile to use the proper libapr supplied config tool about "what extra libraries do I need?" and add that to the MoarVM link line 08:14
08:30 cognominal joined 09:03 Guest1337 joined 10:17 flaviusb joined 11:25 kbenson joined 12:14 JimmyZ joined
diakopter anyone want to port libuv's build system to Perl? 12:59
needs done sometime in the next few months
JimmyZ github.com/joyent/libuv this one? 13:00
diakopter yes
replacing apr with libuv at some point soon
Perl version of gyp, I guess 13:01
JimmyZ will be libuv in 3rdparty dir or other dir? 13:02
diakopter 3rdparty
13:40 lizmat joined 13:46 FROGGS joined
nwc10 diakopter: sorry if this is a silly question, but if libuv's build system is currently "just" Python 2, what's the problem in leaving it that way "for now"? 14:40
also, if you read scrollback, I think I know where the APR link failures are coming from.
diakopter nwc10: I agree 14:41
I wouldn't mind it being in python and shipping pre-configured versions for various platforms
jnthn would prefer there's no python dependency
nwc10 that's reasonable, but which platforms don't have Python on them by default?
diakopter :)
nwc10 Python 2 that is 14:42
diakopter fewer than have Perl? :)
benabik Obv, we just need to write a python interp on MoarVM. ;-D
nwc10 as in, I think that pretty much any Linux distro will end up with Python these days, OS X seems to
tadzik Python 2.6 is in LSB, iirc
along with Perl 5.8 :) 14:43
TimToady wonders if Python 4 will be a version of Python 2 that leapfrogs Python 3... :)
nwc10 Long term I'd like the Perl 5 build dependency to go away, 'cos otherwise someone has to maintain Perl 5 forever just to bootstrap Perl 6
14:46 rurban joined
masak +1 14:47
I've heard people level criticism on Parrot for its Perl 5 dependency. 14:48
nwc10 Aha, right. I certainly had one specific criticism of it - it kept using Perl 5 for its build system 14:49
rather than bootstrapping a parrot as early as possible and then using that parrot to build the rest
TimToady of course, if moarvm advertises Perl 5 interop, we have to bundle it anyway...
(probably)
nwc10 I assume so to 14:50
but maybe 10 years from now it won't be needed
masak or there should at least be a viable option to build without it for people who want just Perl 6, for example. 14:51
TimToady so, at what point do we get lazy and start calling it "moar" instead of "moarvm"? <-- already too lazy to capitalize
14:51 lizmat joined
TimToady also wonders how soon till we have a fork named 'moa' 14:53
masak :P
TimToady: "moar" is simply a short form of the full "MoarVM", just as "p5" is a short form of "The Democratic People's Republic of Perl 5". 14:55
14:55 bronco_creek joined
masak bronco_creek: \\o 14:55
TimToady moar.org seems kinda like a squatted name with ads on it 14:56
benabik in spanish
masak .oO( maz.org ) 14:57
bronco_creek masak: Hi. I'm just a one-time perl scripter who keeps an eye on Perl 6 development. Wish I had time/skills to contribute. Look exciting at the moment. 14:58
TimToady bronco_creek: we hope to increase your excitement in the future :)
bronco_creek TimToady: I enjoyed the video of your talk at YAPC:NA. Thanks! 15:00
TimToady bows, and hits his head on the laptop
where are you located?
JimmyZ well, windows always doesn't have python 15:01
bronco_creek Boulder, CO, USA
TimToady ah, tchrist-town :)
benabik Windows doesn't always have perl, either. Although I suppose one added dependency is better than two.
JimmyZ you may not want to build MoarVM with perl and python together 15:02
nwc10 JimmyZ: yes, I should have said that I was assuming *that*. And I guess that some of the commercial Unixes may not. But Windows is a sufficiently predictable platform that you can ship a pre-configured something for libub?
er, libuv
JimmyZ and Perl 6
nwc10 heck, does libuv currently need Python to build on Win32?
TimToady maybe we should do the build system in JavaScript :) 15:03
JimmyZ well README says you can just run Make in linux too 15:04
;)
masak TimToady: you jest, but... :) 15:05
nwc10 it would seem the logical choice for the libuv maintainers, as they will have V8 around already, won't they?
masak ...there are build systems in JavaScript...
TimToady and eventually you can compile the P6 build system down to JS, and then...
benabik There is too much in JavaScript.
nwc10 I'm sure the CPU manufactures and computer retailers will disagree on that 15:06
diakopter TimToady: probably we'll find a ride 15:07
TimToady thanks, I told her to call when she gets in
(to find out)
benabik Web pages, sure. But node gives me shivers. We develop type systems for a reason. 15:10
TimToady it would be pretty amusing if, with the JS backend, untyped Perl 6 ended up better optimized than typed Perl 6... 15:12
15:18 birdwindupbird joined
moritz well, if you create proper objects with a MOP and all that fun, I guess won't make much of a difference anymore :-) 15:19
TimToady is not sure what that means unless you clarify whether you think JS has "proper objects" :) 15:20
moritz ok, let me rephrase that
even a JS backend will have to provide some kind of object to represent a P6 Int, which will be different from the JS integer 15:21
so I guess in P6-on-JS, you won't have much of an advantage when not declaring types
TimToady nodnod 15:22
strolling toward hackathon &
(while it's still only hot outside)
moritz and it seems that js engines slowly converge on a subset of JS that is particularly fast, and suitable for code generation 15:24
so that's a bit of a typed subset
masak indeed. 15:26
15:47 benabik joined
benabik asm.js seems to be what all the popular kids are using these days. 15:48
nwc10 to get them even closer to the metal than Node? 15:50
benabik More or less. It tags expressions to mark them as int/float/etc so the JIT can produce better code 15:53
sorear asm.js as it exists today has a couple serious limitations 16:04
you can't muck with GCable objects in an asm.js function
moritz there are no debian packages for libuv :( 16:05
sorear you can implement your own GC if you want based on a compact array, but there's no sbrk()
which is kind of troublesome for an interpreter. have to decide a priori how much memory to reserve
16:06 japhb_ joined
nwc10 moritz: but at one time there were no debian packages for parrot. 16:06
(but I see your point)
jnthn pmichaud feels quite strongly that we should not bundle stuff in the Moar repo itself. 16:09
But that we could have our own copies of stuff in repos to build it
sorear git-submodule!!! 16:12
bronco_creek I disappeared into a meeting there for a while. 16:14
I am an experienced technical writer/editor. I could edit English docs, as time allows. 16:15
masak is here too late to say "bronco_creek: awesome!" 16:56
17:01 FROGGS joined
dalek arVM: 617250c | jonathan++ | src/gc/collect.c:
Fix a warning.
 17:15
arVM: 6ab684e | jonathan++ | src/gc/ (3 files):
Cleanup inter-generational roots list.
pmichaud good afternoon, #moarvm 17:29
17:29 nwc10 joined
benabik o/ pmichaud 17:29
dalek arVM: 07d5eac | jonathan++ | / (6 files):
Implement and map nqp::lexprimspec.
 18:00
arVM: eb23312 | jonathan++ | nqp-cc/nqp-src/NQPHLL.nqp:
Uncomment more of NQPHLL.
18:03 Guest1337 joined 18:14 colomon joined
kbenson Q: regarding the build system of libuv discussion earlier (replace python build system), what's the reason for needing to *build* as opposed to just use libuv as a library? 18:15
similar question in my mind, why is APR bundled at all? Is it not installed as a shared lib when built?
sorear o/ kbenson 18:21
developer friendliness, I guess
benabik I think it's preferred that MoarVM be able to build without hunting down dependencies. There was talk of changing the build to use system APR if available and perhaps downloading APR rather than having it in repo. 18:23
kbenson to me it seems a sort of chicken/egg problem, when viewed through the lens of developer friendliness 18:27
WRT libuv, if you want to include it in the repo (or download and build on demand) to be friendly to developers, but then that makes you want to change the build system from python to something else, that creates enough extra work to defeat the purpose of being included 18:28
o/ sorear.
I don't have a lanyard to forget to wear that you can point out today. ;) 18:29
benabik Looking at libuv, it may make more sense to just keep copies of the generated build system for platforms we care about.
eternaleye Also, having moarvm build its dependencies is (unless trivial to disable) actively packaging-hostile
benabik I think the long term is to use --with-* and --gen-*.
eternaleye In many ways, even just autodetecting installed deps is packaging-hostile 18:30
18:30 Util joined
kbenson ya, I was thinking that as long as the libraries are stable enough, a one time build for the platform and then using the system version would make sense (but I'm not sure of other benefits that I may not see) 18:30
eternaleye (another package pulled in an optional dep, configure autodetects, and suddenly an undeclared dependency is introduced)
benabik OTOH, it's far less friendly to have to specify every required package to configure. Not doing that is why people write configure scripts. 18:31
eternaleye benabik: --{en,dis}able-$feature can turn multiple deps on or off at once. 18:32
benabik: --with is mostly "we'll use X, but which X?"
While --enable is "Do we use X or not?" 18:33
like --with-python=/path/
kbenson or, "we'll use X, but you can't find it and it's $HERE" 18:34
eternaleye Exactly.
--enable-foo tells it to use foo, and die if it can't find it. --with gives it the information it needs to find a non-standard install of foo. 18:35
kbenson I'm not aware, does the autogen/configure toolchain work at all on windows (well, I KNOW it does with certain prereqs, but what's the minimum)?
benabik This feels extremely academic, given that I see precisely zero optional features in MoarVM. :-/
eternaleye kbenson: Not really, no. CMake can generate MSVC project buildfiles, but uses very different syntax from autotools 18:36
benabik: Fair enough
kbenson what's msys/mingw get you? 18:37
18:37 rurban joined
eternaleye kbenson: Never used them, I'm pure linux. 18:37
I think they're more along the lines of cross-compiling, though
benabik For the required deps, I personally feel like "try to detect system versions and provide --with and --gen for when we can't" is a reasonable thing. But Moar still seems to be at the level of "we got it working, awesome." 18:38
kbenson benabik: I think not (well, the use/don't use portion maybe), I was spurred into asking because it was expressed that it may be desirable to rewrite the build system of libuv to make it easier to include and build (not rely on python)
benabik kbenson: Yes, but the conversion had veered a bit from that. 18:39
kbenson I'll give you that this is a bit beyond that original question, but I think getting something decided on how to deal with those dependencies may alleviate the need to rewrite build systems for those that want it
(I'm gonna backpedal here and try to revert any authoritative style statements I may have said. I dislike reading previous comments of mine where I appear to making statements in an authoritative tone that's not in line with how I feel. I've contributed zero so far besides these words and my attention...) 18:46
benabik I rather like the --gen-* system that NQP has developed, even if I never use it. And re-writing other people's build systems seems like a waste of our time. 18:54
kbenson benabik++ 18:55
benabik But that mostly means I won't do it. Open Source means not dictating how other people spend their time. That would make it work. :-D 18:56
19:02 vmspb joined
jnthn The current Moar build stuff probably works *better* on Windows given that's the first thing it supported. :) 19:12
19:15 FROGGS joined
kbenson jnthn: ya, I understand that, and that's probably a big reason why it uses Perl in the configure script, I imagine. 19:22
[Coke] kbenson: there's also 10 years of existing scripts using perl5 for config. 19:25
japhb_ jnthn, in while_concat_native I get 'Internal error: invalid thread ID in GC work pass' starting at scale 65536
jnthn japhb_: Odd, I got it to run up to a million or so 19:26
japhb_ 32-bitness?
jnthn yeah
FROGGS .oO( a million and one would be odd )
kbenson [Coke]: Yes, but when used for making what may BE a perl5 implementation, there's a bit of a chicken/egg problem 19:27
benabik 65536 is only 16b though.
kbenson o/ japhb 19:28
lizmat more like a int vs smallint issue? 19:30
int / long
?
jnthn Not sure yet 19:32
19:42 tgt joined 19:43 japhb_ joined
eternaleye 65536 is 16-bit unsigned, which would be... odd for an int. 19:43
(Or rather, it overflows a 16-bit unsigned) 19:44
19:50 lizmat joined 19:55 flussence joined
flussence decides to lurk moar 19:56
benabik arg
FROGGS benabik: you need to say to where you want to pass your arg to 20:06
20:37 FROGGS joined 21:11 benabik joined 21:22 cognominal joined
dalek arVM: daf8b3d | jonathan++ | src/ (2 files):
Add a BOOTIO, like nqp-jvm has.

Means we'll be able to have a default/base filehandle type to hand.		 21:52
arVM: 1985085 | jonathan++ | / (16 files):
Start cleaning up IO bits.

Use BOOTIO, kill the anonfhtype op. Starts getting things closer to being useful for doing the IO bits in HLL::Compiler, etc.
23:03 japhb_ joined 23:05 lizmat joined 23:13 FROGGS joined 23:22 benabik 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!