Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-06-07

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

All times shown according to UTC.

Time Nick Message
05:25 _ilbot joined #moarvm
05:25 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:34 FROGGS joined #moarvm
05:38 tomyan joined #moarvm
07:12 hoelzro I'm trying to build MoarVM, but I keep getting this error: 3rdparty/apr/.libs/libapr-1.a
07:15 hoelzro 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:16 nwc10 does your machine have the APR headers installed in /usr/include ?
07:16 nwc10 In that, someone reported that before (might have been you, I can't remember)
07:16 nwc10 and it's really not obvious why it's going wrong
07:17 hoelzro yeah, I have the headers
07:17 hoelzro under /usr/include/apr-1, though
07:17 nwc10 I wonder if that's it.
07:18 nwc10 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
07:21 hoelzro no dice
07:23 lizmat joined #moarvm
08:03 nwc10 hoelzro: I get that failure if I install the package libapr1-dev
08:03 hoelzro interesting
08:04 hoelzro 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 /
08:04 nwc10 /usr/bin/ld: 3rdparty/apr/.libs/libapr-1.a(rand.o): undefined reference to symbol 'uuid_generate@@UUID_1.0'
08:04 nwc10 /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
08:04 nwc10 /lib/x86_64-linux-gnu/libuuid.so.1: could not read symbols: Invalid operation
08:04 nwc10 collect2: error: ld returned 1 exit status
08:04 nwc10 er, OK, 3 out of 4 did
08:05 hoelzro that's what I see
08:05 nwc10 but, that Ubuntu box will build MoarVM (and pass tests) before I install libapr
08:05 nwc10 and fails afterwards
08:12 nwc10 OK, nailed it
08:12 nwc10 the problem is uuid-dev
08:12 nwc10 if I install the package uuid-dev the build breaks
08:12 nwc10 uuid-dev is a pre-req of libapr1-dev
08:13 hoelzro hmm
08:13 * hoelzro tries
08:13 hoelzro hmm
08:13 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
08:13 hoelzro hmm, I can't get rid of uuid that easily...
08:13 nwc10 and so the built bundled libapr now has a dependency on a symbol in the uuid library
08:14 nwc10 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:30 cognominal joined #moarvm
09:03 Guest1337 joined #moarvm
10:17 flaviusb joined #moarvm
11:25 kbenson joined #moarvm
12:14 JimmyZ joined #moarvm
12:59 diakopter anyone want to port libuv's build system to Perl?
12:59 diakopter needs done sometime in the next few months
13:00 JimmyZ https://github.com/joyent/libuv this one?
13:00 diakopter yes
13:00 diakopter replacing apr with libuv at some point soon
13:01 diakopter Perl version of gyp, I guess
13:02 JimmyZ will be libuv in 3rdparty dir or other dir?
13:02 diakopter 3rdparty
13:40 lizmat joined #moarvm
13:46 FROGGS joined #moarvm
14:40 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 nwc10 also, if you read scrollback, I think I know where the APR link failures are coming from.
14:41 diakopter nwc10: I agree
14:41 diakopter I wouldn't mind it being in python and shipping pre-configured versions for various platforms
14:41 diakopter jnthn would prefer there's no python dependency
14:41 nwc10 that's reasonable, but which platforms don't have Python on them by default?
14:41 diakopter :)
14:42 nwc10 Python 2 that is
14:42 diakopter fewer than have Perl? :)
14:42 benabik Obv, we just need to write a python interp on MoarVM.  ;-D
14:42 nwc10 as in, I think that pretty much any Linux distro will end up with Python these days, OS X seems to
14:42 tadzik Python 2.6 is in LSB, iirc
14:43 tadzik along with Perl 5.8 :)
14:43 * TimToady wonders if Python 4 will be a version of Python 2 that leapfrogs Python 3...  :)
14:43 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 #moarvm
14:47 masak +1
14:48 masak I've heard people level criticism on Parrot for its Perl 5 dependency.
14:49 nwc10 Aha, right. I certainly had one specific criticism of it - it kept using Perl 5 for its build system
14:49 nwc10 rather than bootstrapping a parrot as early as possible and then using that parrot to build the rest
14:49 TimToady of course, if moarvm advertises Perl 5 interop, we have to bundle it anyway...
14:49 TimToady (probably)
14:50 nwc10 I assume so to
14:50 nwc10 but maybe 10 years from now it won't be needed
14:51 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 #moarvm
14:53 * TimToady also wonders how soon till we have a fork named 'moa'
14:53 masak :P
14:55 masak 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 bronco_creek joined #moarvm
14:55 masak bronco_creek: \o
14:56 TimToady moar.org seems kinda like a squatted name with ads on it
14:56 benabik in spanish
14:57 * masak .oO( maz.org )
14:58 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 :)
15:00 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
15:00 TimToady where are you located?
15:01 JimmyZ well, windows always doesn't have python
15:01 bronco_creek Boulder, CO, USA
15:01 TimToady ah, tchrist-town :)
15:01 benabik Windows doesn't always have perl, either.  Although I suppose one added dependency is better than two.
15:02 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?
15:02 nwc10 er, libuv
15:02 JimmyZ and Perl 6
15:02 nwc10 heck, does libuv currently need Python to build on Win32?
15:03 TimToady maybe we should do the build system in JavaScript :)
15:04 JimmyZ well README says you can just run Make in linux too
15:04 JimmyZ ;)
15:05 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?
15:05 masak ...there are build systems in JavaScript...
15:05 TimToady and eventually you can compile the P6 build system down to JS, and then...
15:05 benabik There is too much in JavaScript.
15:06 nwc10 I'm sure the CPU manufactures and computer retailers will disagree on that
15:07 diakopter TimToady: probably we'll find a ride
15:07 TimToady thanks, I told her to call when she gets in
15:07 TimToady (to find out)
15:10 benabik Web pages, sure.  But node gives me shivers.  We develop type systems for a reason.
15:12 TimToady it would be pretty amusing if, with the JS backend, untyped Perl 6 ended up better optimized than typed Perl 6...
15:18 birdwindupbird joined #moarvm
15:19 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:20 * 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
15:21 moritz 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 moritz so I guess in P6-on-JS, you won't have much of an advantage when not declaring types
15:22 TimToady nodnod
15:22 TimToady strolling toward hackathon &
15:22 TimToady (while it's still only hot outside)
15:24 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 moritz so that's a bit of a typed subset
15:26 masak indeed.
15:47 benabik joined #moarvm
15:48 benabik asm.js seems to be what all the popular kids are using these days.
15:50 nwc10 to get them even closer to the metal than Node?
15:53 benabik More or less.  It tags expressions to mark them as int/float/etc so the JIT can produce better code
16:04 sorear asm.js as it exists today has a couple serious limitations
16:04 sorear you can't muck with GCable objects in an asm.js function
16:05 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()
16:05 sorear which is kind of troublesome for an interpreter.  have to decide a priori how much memory to reserve
16:06 japhb_ joined #moarvm
16:06 nwc10 moritz: but at one time there were no debian packages for parrot.
16:06 nwc10 (but I see your point)
16:09 jnthn pmichaud feels quite strongly that we should not bundle stuff in the Moar repo itself.
16:09 jnthn But that we could have our own copies of stuff in repos to build it
16:12 sorear git-submodule!!!
16:14 bronco_creek I disappeared into a meeting there for a while.
16:15 bronco_creek I am an experienced technical writer/editor.  I could edit English docs, as time allows.
16:56 * masak is here too late to say "bronco_creek: awesome!"
17:01 FROGGS joined #moarvm
17:15 dalek MoarVM: 617250c | jonathan++ | src/gc/collect.c:
17:15 dalek MoarVM: Fix a warning.
17:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/617250c0fd
17:15 dalek MoarVM: 6ab684e | jonathan++ | src/gc/ (3 files):
17:15 dalek MoarVM: Cleanup inter-generational roots list.
17:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6ab684ec17
17:29 pmichaud good afternoon, #moarvm
17:29 nwc10 joined #moarvm
17:29 benabik o/ pmichaud
18:00 dalek MoarVM: 07d5eac | jonathan++ | / (6 files):
18:00 dalek MoarVM: Implement and map nqp::lexprimspec.
18:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/07d5eac35d
18:00 dalek MoarVM: eb23312 | jonathan++ | nqp-cc/nqp-src/NQPHLL.nqp:
18:00 dalek MoarVM: Uncomment more of NQPHLL.
18:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eb23312439
18:03 Guest1337 joined #moarvm
18:14 colomon joined #moarvm
18:15 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 kbenson similar question in my mind, why is APR bundled at all?  Is it not installed as a shared lib when built?
18:21 sorear o/ kbenson
18:21 sorear developer friendliness, I guess
18:23 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:27 kbenson to me it seems a sort of chicken/egg problem, when viewed through the lens of developer friendliness
18:28 kbenson 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 kbenson o/ sorear.
18:29 kbenson 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.
18:29 eternaleye Also, having moarvm build its dependencies is (unless trivial to disable) actively packaging-hostile
18:29 benabik I think the long term is to use --with-* and --gen-*.
18:30 eternaleye In many ways, even just autodetecting installed deps is packaging-hostile
18:30 Util joined #moarvm
18:30 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)
18:31 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:32 eternaleye benabik: --{en,dis}able-$feature can turn multiple deps on or off at once.
18:32 eternaleye benabik: --with is mostly "we'll use X, but which X?"
18:33 eternaleye While --enable is "Do we use X or not?"
18:33 eternaleye like --with-python=/path/
18:34 kbenson or, "we'll use X, but you can't find it and it's $HERE"
18:34 eternaleye Exactly.
18:35 eternaleye --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)?
18:35 benabik This feels extremely academic, given that I see precisely zero optional features in MoarVM.  :-/
18:36 eternaleye kbenson: Not really, no. CMake can generate MSVC project buildfiles, but uses very different syntax from autotools
18:36 eternaleye benabik: Fair enough
18:37 kbenson what's msys/mingw get you?
18:37 rurban joined #moarvm
18:37 eternaleye kbenson: Never used them, I'm pure linux.
18:37 eternaleye I think they're more along the lines of cross-compiling, though
18:38 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)
18:39 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
18:46 kbenson (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:54 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:55 kbenson benabik++
18:56 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
19:02 vmspb joined #moarvm
19:12 jnthn The current Moar build stuff probably works *better* on Windows given that's the first thing it supported. :)
19:15 FROGGS joined #moarvm
19:22 kbenson jnthn: ya, I understand that, and that's probably a big reason why it uses Perl in the configure script, I imagine.
19:25 [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
19:26 jnthn japhb_: Odd, I got it to run up to a million or so
19:26 japhb_ 32-bitness?
19:26 jnthn yeah
19:26 * FROGGS .oO( a million and one would be odd )
19:27 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.
19:28 kbenson o/ japhb
19:30 lizmat more like a int vs smallint issue?
19:30 lizmat int / long
19:30 lizmat ?
19:32 jnthn Not sure yet
19:42 tgt joined #moarvm
19:43 japhb_ joined #moarvm
19:43 eternaleye 65536 is 16-bit unsigned, which would be... odd for an int.
19:44 eternaleye (Or rather, it overflows a 16-bit unsigned)
19:50 lizmat joined #moarvm
19:55 flussence joined #moarvm
19:56 * flussence decides to lurk moar
19:56 benabik arg
20:06 FROGGS benabik: you need to say to where you want to pass your arg to
20:37 FROGGS joined #moarvm
21:11 benabik joined #moarvm
21:22 cognominal joined #moarvm
21:52 dalek MoarVM: daf8b3d | jonathan++ | src/ (2 files):
21:52 dalek MoarVM: Add a BOOTIO, like nqp-jvm has.
21:52 dalek MoarVM:
21:52 dalek MoarVM: Means we'll be able to have a default/base filehandle type to hand.
21:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/daf8b3d84c
21:52 dalek MoarVM: 1985085 | jonathan++ | / (16 files):
21:52 dalek MoarVM: Start cleaning up IO bits.
21:52 dalek MoarVM:
21:52 dalek MoarVM: Use BOOTIO, kill the anonfhtype op. Starts getting things closer to
21:52 dalek MoarVM: being useful for doing the IO bits in HLL::Compiler, etc.
21:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/198508542e
23:03 japhb_ joined #moarvm
23:05 lizmat joined #moarvm
23:13 FROGGS joined #moarvm
23:22 benabik joined #moarvm

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