Camelia, the Perl 6 bug

IRC log for #parrot, 2012-09-14

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:15 benabik joined #parrot
00:21 MikeFair joined #parrot
00:34 kid51 joined #parrot
02:06 nopaste joined #parrot
02:34 mvorl left #parrot
03:45 benabik joined #parrot
04:09 benabik joined #parrot
05:08 alvis_ joined #parrot
05:43 cosimo joined #parrot
05:45 NotFound_b joined #parrot
05:48 arnsholt_ joined #parrot
05:48 Maddingu1 joined #parrot
05:53 ttbot joined #parrot
07:22 woosley joined #parrot
08:11 lucian joined #parrot
08:20 Psyche^ joined #parrot
08:48 mdupont joined #parrot
12:21 mtk joined #parrot
12:24 benabik joined #parrot
12:33 JimmyZ joined #parrot
13:20 bluescreen joined #parrot
13:59 benabik joined #parrot
14:14 benabik ~~
14:14 PacoAir joined #parrot
14:58 benabik_ joined #parrot
15:00 mvorl joined #parrot
15:27 dmalcolm joined #parrot
15:58 dalek parrot/native_pbc2: e697588 | rurban++ | t/native_pbc/number_4_4_be.pbc:
15:58 dalek parrot/native_pbc2: native_pbc/number_4_4_be.pbc added
15:58 dalek parrot/native_pbc2: review: https://github.com/parrot/parrot/commit/e697588d93
16:34 dalek parrot/native_pbc2: 5f4222d | rurban++ | config/gen/config_pm/myconfig.in:
16:34 dalek parrot/native_pbc2: display FLOATTYPE_? in myconfig
16:34 dalek parrot/native_pbc2: review: https://github.com/parrot/parrot/commit/5f4222ddff
16:55 alvis joined #parrot
17:03 tuxit joined #parrot
17:24 patspam joined #parrot
17:33 mvorl joined #parrot
17:45 contingencyplan joined #parrot
17:45 aloha joined #parrot
18:06 benabik_ joined #parrot
18:08 benabik__ joined #parrot
18:12 sivoais joined #parrot
18:17 zby_home joined #parrot
18:24 zby_home joined #parrot
18:28 dalek rakudo/nom: a19ce8b | jnthn++ | src/core/LoL.pm:
18:28 dalek rakudo/nom: Make infix:<X> a bit cheaper. This doesn't really deal with what seems to be an algorithmic problem, but it is an easy and noticable win.
18:28 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a19ce8b0f9
18:37 zby_home joined #parrot
19:05 benabik rurban++ pointed out vmkit on #perl6.  Pondering it as a version of M0.
19:06 benabik 1) LLVM does not appear to natively support continuations.
19:07 benabik 2) VMKit _looks_ to be designed to support stack-based languages, but I see nothing that would prevent doing registers.
19:08 benabik It would allow us to use LLVM as our ops language, which means they could be written in, basically in-VM C.
19:11 benabik llvm-lua is talking about doing continuations via LLVM
19:12 sorear the interesting question then becomes, do you try to use the native stack, or do you set up a special parrot stack?
19:12 benabik Parrot doesn't use the stack.
19:13 sorear a custom stack with a register allocated for the top works quite well for ghc
19:13 benabik Right.
19:13 rurban That's up to LLVM. Native stack of course
19:13 benabik It's not entirely up to LLVM.
19:13 sorear Don't say "of course" so quickly.
19:13 rurban but with fastcall most of the the args are in registers.
19:13 sorear There are a lot of restrictions on the use of the native stack
19:13 rurban with i386 on the stack.
19:14 rurban which?
19:14 rurban stacksize 8MB? faster?
19:14 sorear no tailcalls in half the cases on unix
19:14 benabik If we generate code that always .tailcalls and mostly store variables in GC-managed continuations, that's very different than what LLVM would do by default.
19:14 sorear large stacks since no good resize support
19:14 benabik https://code.google.com/p/llvm-​lua/wiki/StacklessJITFunctions
19:14 rurban true
19:15 sorear no easy coroutines on Windows
19:15 sorear makes on-stack replacement and precise stack marking a bit harder
19:16 Coke if parrot can be made to use llvm - what's left of parrot?
19:16 benabik Ops, interop, object model.
19:16 benabik LLVM is the base on which Parrot ops are written.
19:16 rurban Coke: pbc only
19:17 rurban I don't know about the pmc's
19:17 rurban But parrot will always be the default basis for nqp and rakudo. At least to bootstrap it.
19:18 rurban But if parrot's calling convention is way too slow, why bother.
19:18 benabik Coke: llvm is a compiler tool, not a VM.  vmkit adds memory management and JIT core.  Parrot would add objects, high-level ops, etc.
19:18 rurban And I don't think lorito is a practical way.
19:19 benabik Parrot is far more than a calling convention.  It's a pain point right now, but it can be fixed.
19:20 benabik vmkit seems to be completely agnostic to execution style and variable storage.  stack, register, continuation, etc
19:21 atrodo How would LLVM and vmkit imrpvoe interop more than m0/lorito?
19:21 atrodo or even compared to parrot today
19:22 benabik It could improve speed (JIT vs interp), free developer time from GC and Threads...
19:22 benabik (We'd still need the conceptual models that nine++ developed, but implementation is much freer.)
19:23 benabik Interop is still our problem.  :-D
19:23 benabik Although building on LLVM might ease Parrot<->C jumps.
19:23 atrodo So is parrot's goal speed or interop or rakudo?
19:23 rurban rakudo which is speed
19:23 atrodo Put another way, what exactly is parrot goal at this point?
19:24 rurban not die
19:24 Coke rakudo has to be our main priority, I think.
19:24 rurban if it does not get a performance boost rakudo is forced to use better vm's
19:24 rurban See nqp QAST
19:25 benabik Parrot's goal is to be a wonderland of interop and ease of development for dynamic languages.
19:25 benabik More practical goals include speed and learning from Rakudo's improvements.
19:25 rurban yes, if rakudo is gone, parrot can try to persuade the others to come back.
19:26 atrodo If I was rakudo, I'd be asking why it even needs parrot at all
19:26 benabik I'm excited by Parrot as an educational and development environment.
19:26 benabik While I'm interested in Rakudo, it's not why I care about Parrot.
19:26 rurban They are asking themselves this constantly.
19:26 * benabik sighs.
19:27 moritz atrodo: hysterical raisins
19:27 atrodo benabik: I am too.  I think parrot has huge potential, but if it only chases rakudo, what future does it really have?
19:27 benabik Can I not ponder possibilities about how to implement a register and continuation based VM for dynamic languages without dredging up this crud?
19:28 moritz though parrot does have some very helpful bits that other VMs don't offer
19:28 * benabik really hates this recurring "why does Rakudo need Parrot" business.
19:28 Coke benabik: Sure, but at some point, don't we have to ask "if we're going to write code for parrot, why are we doing it" ?
19:28 moritz like the ability to write your own multi dispatch in C
19:28 atrodo benabik: Sorry, I'm not aiming at you, I'm also wondering outloud
19:28 rurban You can do, but we need to focus on helping our main customer
19:29 benabik Parrot is about providing tools.  Most VMs come with built-in object models, built-in ideas about exceptions and control flow.
19:29 Coke so, backing up: what are we arguing about?
19:29 rurban Because when rakudo goes away parrot is dead, rakudo only needs it for bootstrapping nqp.
19:29 benabik rurban: When Rakudo goes away I co-opt Parrot as my personal thesis research playground.  :-D
19:29 Coke benabik: you can do that today with a fork.
19:30 rurban rakudo might be renamed if it switches to another vm.
19:30 benabik Coke: Like, say, a vmkit based fork?
19:30 Coke as someone who's tried to target parrot for a while, I've given up on targetting parrot directly. I'm targetting nqp these days.
19:30 rurban I would do so, to keep a straight face.
19:30 rurban The vmkit based fork was my idea :)
19:31 Coke given that most of rakudo is written in perl6 and not parrot, I doubt that'll happen.
19:31 moritz rurban: now write a patent application for it :-)
19:31 benabik rurban: vmkit based NQP...  I wanted to talk more generally about it for other languages.
19:31 benabik I've been pondering what I'd like to see Parrot be, to some extent, and vmkit is a lovely match for some of it.
19:32 benabik Assuming I can get efficient continuations out of it.
19:36 benabik Parrot is amazingly pluggable, but much of its extensibility comes with large costs.
19:37 benabik Our ops generation is painful, our calling conventions are too slow, our object model is clunky.
19:37 benabik The way we manage our namespaces makes my head hurt.
19:37 rurban Our ops.pmc's are quite nice imho.
19:37 benabik In concept, yes.
19:38 benabik But we suffer from huge code bloat in opsgen.
19:38 rurban yes
19:38 rurban We have no good optimizer
19:39 benabik It's just code duplication.  We expect ops to handle the difference between registers and constants and piles of other things instead of having a nice generic interface to these things.
19:42 dalek parrot/native_pbc2: ecd4ef1 | rurban++ | config/ (2 files):
19:42 dalek parrot/native_pbc2: use PARROT_FLOATVAL_DIG for rounding, set i_quadmath
19:42 dalek parrot/native_pbc2: review: https://github.com/parrot/parrot/commit/ecd4ef12d2
19:42 dalek parrot/native_pbc2: f98d38b | rurban++ | / (4 files):
19:42 dalek parrot/native_pbc2: [GH #807] Refactor native_pbc endianness, bswap64. Add header argument to converters
19:42 dalek parrot/native_pbc2:
19:42 dalek parrot/native_pbc2: Convert endianness upfront does not work.
19:42 dalek parrot/native_pbc2: Some converters work on native floats, to do compiler casts. They
19:42 dalek parrot/native_pbc2: need to know the packfile byteorder.
19:42 dalek parrot/native_pbc2: Other bitfiddling converters work only on little-endian, so we also need
19:42 dalek parrot/native_pbc2: to know the packfile byteorder, and they also need to convert endianness
19:42 dalek parrot/native_pbc2: back to to the target format.
19:42 dalek parrot/native_pbc2:
19:42 dalek parrot/native_pbc2: Refactor bswap64, as it only works with 64bit registers. Tested with HAS_INT64.
19:42 dalek parrot/native_pbc2: So there are two bswap64 API's, one for fast native conversion via a register
19:42 dalek parrot/native_pbc2: and one with two unsigned char * args, which might point to the same buffer,
19:42 dalek parrot/native_pbc2: for easier in-place conversion.
19:42 dalek parrot/native_pbc2:
19:42 dalek parrot/native_pbc2: Added dummy ROUND_NUM_TO macro, which needs to round a long number down to the given
19:43 dalek parrot/native_pbc2: precision (when converting upwards). Can be done with sprintf, but need to find a
19:43 dalek parrot/native_pbc2: better way.
19:43 dalek parrot/native_pbc2:
19:43 dalek parrot/native_pbc2: Simplify converter casts with unions.
19:43 dalek parrot/native_pbc2:
19:43 dalek parrot/native_pbc2: Replace SWAB_12 with SWAB_10. TODO: Need to check the last two bytes.
19:43 dalek parrot/native_pbc2: review: https://github.com/parrot/parrot/commit/f98d38b202
19:43 benabik The lack of optimization is a problem across the board to some extent, which is why vmkit making it easy to reuse all the LLVM optimizers is nice.
19:43 rurban yes, that was one of my ideas, also to use a better GC.
19:44 benabik Yeah, the mention of Immix in vmkit really caught my eye.
19:44 moritz is GC still a bottleneck?
19:44 rurban A stop-the-world gc always has some marketing issues.
19:44 moritz in parrot, that is
19:44 benabik It's probably not our major bottleneck, but being able to get better GC without additional work is a plus in my book.
19:45 rurban it's tricolor with generations now, but still I'd like a batter concept at all, sooner or later
19:45 rurban better
19:45 benabik Better meaning more featured.  A global stop-the-world GC is very bad with threads.
19:45 rurban Better copying then mark-sweep
19:46 moritz benabik: but isn't it stop-the-thread in the threads branch?
19:46 rurban Our threads do fine with the gc now and proxies, that's fine. No measurable speed loss.
19:47 rurban stop the threads and stop the world. and best: it does not check out-of-memory.
19:49 benabik moritz: I'll have to admit I don't know.  :-/
19:49 benabik Really GC from vmkit is nice for me because I don't want to maintain a GC.  :-D  And attracting developers who do is difficult.
19:49 Coke Anyway, I'm happy to see people discussing where to spend tuits, thanks for keeping parrot alive.
19:50 Coke benabik: that is an excellllllent point which I think has not been enough embraced over parrot's lifetime. We should definitely not be reinventing wheels when perfectly round ones are available.
19:50 rurban The vmkit is really mmtk from Jikes
19:50 benabik Coke: But have they tried octagonal?  I think we have some of those around in the codebase.
19:51 * benabik kids.
19:51 rurban MMTk
19:52 Coke ooh, jikes. I remember when that was first available.
19:52 rurban The vmkit GC is really MMtk from Jikes (sigh)
19:53 benabik Hey, if I can get a GC written by IBM research, I'll take it.  :-D
19:54 rurban But it's written in java!
19:55 benabik I rather doubt they wrote the GC in Java, although I could be wrong.
19:55 rurban http://jikesrvm.svn.sourceforge.net/viewvc/j​ikesrvm/rvmroot/trunk/rvm/src/org/jikesrvm/
19:56 rurban That's why I am a little bit nervous.
19:56 benabik Well, then, I'm wrong.
19:57 benabik I don't see the memory managers in there, just the Java interface.
20:00 benabik It looks like the MMTk bits in vmkit are in C++
20:00 benabik http://llvm.org/viewvc/llvm​-project/vmkit/trunk/mmtk/
20:01 rurban http://llvm.org/viewvc/llvm-project/vm​kit/trunk/mmtk/java/src/org/mmtk/plan/
20:01 benabik So vmkit requires a running JVM?
20:01 benabik This feels wrong.
20:01 rurban j3 is basically a jvm.
20:01 benabik c3 isn't.
20:01 benabik Or was it N3?
20:01 rurban forgot
20:02 benabik N3 for Net, I think.
20:03 benabik We'd lose a lot of portability, apparently.  LLVM's JIT is x86 only.
20:04 Coke no worse than our previous JIT.
20:04 benabik Yes, but I don't see a non-JIT mode for vmkit.
20:04 Coke odd.
20:04 rurban There is a AOT compiler
20:04 benabik And they apparently use Java-written GCs, compiled to LLVM via their JVM.
20:05 benabik That's... odd.
20:05 rurban yep
20:05 rurban we could write a GC in nqp
20:06 Coke +1
20:06 Coke Or winxed, which is filling the slot that I thought scheme might at some point.
20:08 rurban Anyway, first I'll have to fix my numbers, then threads, then study vmkit.
20:26 dalek parrot/native_pbc2: f9561fc | rurban++ | t/native_pbc/number_8_4_le.pbc:
20:26 dalek parrot/native_pbc2: add t/native_pbc/number_8_4_le.pbc (it crashes on different ptrsizes)
20:26 dalek parrot/native_pbc2: review: https://github.com/parrot/parrot/commit/f9561fcf91
20:37 dalek parrot/native_pbc2: 1716ee5 | rurban++ | / (2 files):
20:37 dalek parrot/native_pbc2: Improve number.t output (print desc)
20:37 dalek parrot/native_pbc2:
20:37 dalek parrot/native_pbc2: Update testmatrix.
20:37 dalek parrot/native_pbc2: review: https://github.com/parrot/parrot/commit/1716ee578a
21:27 benabik joined #parrot
21:28 dalek nqp: c810874 | jnthn++ | src/QRegex/P5Regex/Grammar.nqp:
21:28 dalek nqp: Toss P6Regex leftover.
21:28 dalek nqp: review: https://github.com/perl6/nqp/commit/c810874a30
21:28 dalek nqp: 37cb811 | jnthn++ | src/QRegex/P5Regex/Grammar.nqp:
21:28 dalek nqp: Parse non-alphanumerics without a meaning as literal characters to match.
21:28 dalek nqp: review: https://github.com/perl6/nqp/commit/37cb811b4a
21:28 dalek nqp: f1027a4 | jnthn++ | t/p5regex/rx_charclass:
21:28 dalek nqp: Test for /a]/.
21:28 dalek nqp: review: https://github.com/perl6/nqp/commit/f1027a4e92
21:40 dalek nqp: 1a194af | jnthn++ | / (2 files):
21:40 dalek nqp: Fix \B, plus a test.
21:40 dalek nqp: review: https://github.com/perl6/nqp/commit/1a194af38c
21:48 dalek rakudo/nom: ba04210 | jnthn++ | tools/build/NQP_REVISION:
21:48 dalek rakudo/nom: Get latest NQP for P5Regex improvements.
21:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ba04210c6c
21:48 dalek rakudo/nom: d624613 | jnthn++ | t/spectest.data:
21:48 dalek rakudo/nom: Run S05-modifier/perl5_1.t.
21:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d62461350a
23:32 benabik joined #parrot

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

Parrot | source cross referenced