Camelia, the Perl 6 bug

IRC log for #parrot, 2011-01-31

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 janus left #parrot
00:04 cotto mikehh, you can fix that.  We want to keep the c++ build working.
00:05 mikehh cotto: done, just testing before commit
00:09 pmichaud kid51: thanks... fixed
00:10 pmichaud note that I'm not at all advocating keeping nqp completely out of parrot either; I'm just trying to be non-commital either way (i.e., let parrot devs decide what works best for parrot, and I'll try to help).  Does that come through in the plan okay?
00:12 pmichaud I'll add a statement about that to try to make it clearer
00:13 cotto pmichaud, it sounds like there won't be a way to access features of the underlying vm directly, which is part of what makes nqp-rx useful for core parrot purposes.
00:13 pmichaud well, I'm not sure about that
00:13 pmichaud I've been thinking of ways to access the underlying vm directly
00:13 pmichaud we could still allow :multi and :vtable pragmas to be accessed, for instance
00:13 pmichaud it's a bit too early to know what will and won't be possible
00:14 pmichaud more potentially damaging is that nqp won't run without its "runtime" in place.  So it really depends more on how much of that runtime Parrot chooses to adopt in its core
00:14 pmichaud (i.e., the object model)
00:14 pmichaud if Parrot ultimately adopts the object model into its core in some form, then I'd expect that nqp *could* still access the low level features of Parrot
00:14 cotto From my understanding, it's pretty likely that we'll be adopting something like 6model.
00:15 mikehh yes that was my thought
00:15 pmichaud in fact, because of the changes we're doing now in nqp, it'll be even *more* possible to access underlying parrot features, such as declaring local register variables
00:15 pmichaud s/to access/to access some/
00:15 Topic for #parrot is now Parrot 3.0.0 Released | http://parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches
00:16 pmichaud and to avoid pmc boxing/unboxing
00:19 pmichaud I've rewritten that section a bit:
00:19 pmichaud (semi-long paste coming up)
00:19 pmichaud "Our plan recognizes and fully understands that
00:19 pmichaud Parrot may elect to neither provide nor support nqp directly in its
00:19 pmichaud distributions, and may even migrate existing tools and libraries
00:19 pmichaud completely away from the existing nqp-rx and PCT.  Or, Parrot
00:19 pmichaud might decide to embrace NQP more fully to take advantage of its
00:19 pmichaud new optimization and compiler toolkit capabilities.  We can likely
00:19 pmichaud find ways to preserve the ability to access low-level Parrot features
00:19 pmichaud for Parrot-specific libraries.  (This becomes far more conceivable if
00:20 pmichaud Parrot adopts the new object metamodel, which is the major impetus
00:20 pmichaud behind these changes.)  Whatever the Parrot team chooses to do in
00:20 pmichaud this area, nqp will support as best it can within the goals and
00:20 pmichaud plans described above.
00:20 pmichaud "
00:20 pmichaud does that sound more in the middle?
00:21 cotto pmichaud, that's much less scary.
00:21 cotto thanks for clarifying
00:26 nwellnhof left #parrot
00:27 dalek parrot: a96b35d | bacek++ | src/runcore/main.c:
00:27 dalek parrot: Fix c++ build
00:27 dalek parrot: review: https://github.com/parrot/parrot/commit/a96b35d17f
00:27 NotFound joined #parrot
00:27 NotFound Hi
00:28 cotto hi NotFound
00:38 whiteknight left #parrot
00:50 Coke (instead of a tag called "old" in the old file, have a tag for "version it was removed in.")
00:51 bacek_at_work ... and date
00:51 dalek parrot: c2ffe55 | bacek++ | src/exceptions.c:
00:51 dalek parrot: Explicitely cast enum to INTVAL to pacify c++ compiler.
00:51 dalek parrot: review: https://github.com/parrot/parrot/commit/c2ffe55c90
00:51 dalek parrot: 01bf2d8 | bacek++ | src/packfile/api.c:
00:51 dalek parrot: Use size_t instead of INTVAL for iterating over keys.
00:51 dalek parrot: review: https://github.com/parrot/parrot/commit/01bf2d882f
00:51 dalek parrot: 91d348b | bacek++ | src/hash.c:
00:51 dalek parrot: Pacify c++ compiler by casting value to proper enum.
00:51 dalek parrot: review: https://github.com/parrot/parrot/commit/91d348bb94
00:51 dalek parrot: 6176f08 | bacek++ | src/pmc/imageiothaw.pmc:
00:51 dalek parrot: Use explicit const_cast to pacify c++ compiler.
00:51 dalek parrot: review: https://github.com/parrot/parrot/commit/6176f08cc8
00:51 dalek parrot: 0677041 | bacek++ | src/pmc/packfileannotations.pmc:
00:51 dalek parrot: Pacify c++ compiler by casting to proper type.
00:51 dalek parrot: review: https://github.com/parrot/parrot/commit/0677041ec9
00:53 KaeseEs are there any limits besides the hardware that i'd run into wrt. measuring relatively small time intervals (eg. 500 us)?
00:58 dalek winxed: r751 | NotFound++ | trunk/winxedst1.winxed:
00:58 dalek winxed: operators '<<' and '>>' in stage 1
00:58 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=751
01:01 KaeseEs i ask because i'm looking at writing a metronome-like collector to familiarize myself with the api
01:04 dalek parrot: 5d1baae | bacek++ | src/pmc/imageiothaw.pmc:
01:04 dalek parrot: One more explicit const_cast to pacify c++ compiler.
01:04 dalek parrot: review: https://github.com/parrot/parrot/commit/5d1baaeddf
01:06 mikehh KaeseEs: have a look at t/pmc/timer.t for an example - probably not the best
01:07 KaeseEs thanks!
01:07 hudnix joined #parrot
01:13 jan joined #parrot
01:21 mikehh bacek_at_work: g++ didn't like the last commit - ./src/pmc/imageiothaw.pmc:238:39: error: invalid const_cast from type ‘const unsigned char*’ to type ‘opcode_t*’
01:31 dalek parrot/tt1988_pmcemitter: 6d7aa32 | jkeenan++ | lib/Parrot/Pmc2c/PMC (2 files):
01:31 dalek parrot/tt1988_pmcemitter: Move vtable() method from lib/Parrot/Pmc2c/PMCEmitter.pm to lib/Parrot/Pmc2c/PMC.pm.
01:31 dalek parrot/tt1988_pmcemitter: review: https://github.com/parrot/parrot/commit/6d7aa3204e
01:47 dalek parrot: eaa0a9f | mikehh++ | src/pmc/imageiothaw.pmc:
01:47 dalek parrot: fix cast so g++ builds
01:47 dalek parrot: review: https://github.com/parrot/parrot/commit/eaa0a9f0b5
01:50 dalek parrot/tt1988_pmcemitter: d501954 | jkeenan++ | lib/Parrot/Pmc2c/PMC/RO.pm:
01:50 dalek parrot/tt1988_pmcemitter: Remove unnecessary import of Parrot::Pmc2c::PMCEmitter.
01:50 dalek parrot/tt1988_pmcemitter: review: https://github.com/parrot/parrot/commit/d5019545ff
02:05 dukeleto ~~
02:08 Coke getting warnings in the new *deprecated* tests.
02:08 dalek nqp-rx: ab1ffc0 | Coke++ | src/Regex/P6Regex/Grammar.pm:
02:08 dalek nqp-rx: Fix error message to match STD.
02:08 dalek nqp-rx: review: https://github.com/perl6/nqp-rx/commit/ab1ffc0daf
02:08 dalek nqp-rx: 96e4b67 | Coke++ | src/stage0/ (3 files):
02:09 dalek nqp-rx: update bootstrap for " in Perl 6" error update.
02:09 dalek nqp-rx: review: https://github.com/perl6/nqp-rx/commit/96e4b67a08
02:09 dalek parrot: ed1a4bc | Coke++ | docs/book/draft/appe_source_code.pod:
02:09 dalek parrot: fix header level.
02:09 dalek parrot: review: https://github.com/parrot/parrot/commit/ed1a4bc4b3
02:09 dalek parrot: 814a916 | Coke++ | ext/nqp-rx/src/stage0/ (4 files):
02:09 dalek parrot: pull in NQP changes for updated error message.
02:09 dalek parrot: review: https://github.com/parrot/parrot/commit/814a91684d
02:10 mikehh Coke: so do I
02:27 Hackbinary dumb questions, in npq is := a reference copy and not a value copy, yes?
02:27 Hackbinary *nqp
02:28 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#6411) fulltest) at 3_0_0-348-geaa0a9f - Ubuntu 10.10 i386 (g++-4.5)
02:31 dalek parrot: 013436a | bacek++ | src/packfile/api.c:
02:31 dalek parrot: Use explicit cast to pacify compiler.
02:31 dalek parrot: review: https://github.com/parrot/parrot/commit/013436abbc
02:31 dalek parrot: 8ddc501 | bacek++ | src/nci_test.c:
02:32 dalek parrot: Split declaration and definition of exported vairables to pacify c++ compiler.
02:32 dalek parrot: review: https://github.com/parrot/parrot/commit/8ddc501f40
02:32 bacek_at_work Hackbinary, it's binding. Which is "reference copy"
02:32 bacek_at_work parrot is build warnings free now (at least on Linux/i386)
02:33 Hackbinary thanks
02:36 dukeleto Hackbinary: what are you hacking on?
02:37 Hackbinary dukeleto:  i'm trying to fix the unless statement in cardinal
02:41 dukeleto Hackbinary: awesome!
02:44 kid51 left #parrot
02:48 dukeleto Hackbinary: are you working in a fork of parrot/cardinal ?
02:48 Hackbinary dukeleto:  I'm working off the on from github.com/parrot/cardinal
02:49 Hackbinary I have not committed anything, or created a patch or anything yet as I've yet to really understand what is going on
02:49 Tene Hackbinary: It's really great seeing someone working on Cardinal. :)
02:49 Hackbinary =)
02:51 Hackbinary Tene, dukeleto:  where should I be adjusting how expression is evaluated.
02:52 Hackbinary I'm trying to fix unless 0 which evaluates to false, but should be true, so the ruby unless else block is executed
02:54 Tene Hackbinary: is the problem with the unless statement, or the truth value of 0?
02:54 dukeleto Hackbinary: i would guess in src/parser/actions.pm or src/parser/grammar.pg
02:55 dukeleto Hackbinary: please note that cardinal uses Parrot Grammar Engine (PGE), not NQP
02:55 Hackbinary if 0 should evaluate to false
02:55 dukeleto Hackbinary: PGE is a predecessor of NQP
02:55 dukeleto Hackbinary: i am also excited to see you working on it
02:55 Hackbinary unless 0 should evaluate to true
02:55 dukeleto Hackbinary: yes, i agree
02:56 dukeleto Hackbinary: and feel free to email the parrot-dev list if you have questions
02:56 dukeleto Hackbinary: many parrot devs are on parrot-dev but are rarely on IRC
02:57 Hackbinary so how I'm approaching the solution is putting the fix in the unless_stmt method in the actions.pm file
02:57 Hackbinary but I could be doing it wrong
02:57 pmichaud Hackbinary: that sounds very much correct
02:57 pmichaud (as in, it would be the correct place for a fix)
03:01 Tene dukeleto: Cardinal *does* use nqp, it just doesn't use nqp's grammars.
03:01 sorear PGE and NQP used to be separate
03:01 Tene sorear: they still are
03:01 Tene Hackbinary: No, that's very much not the right place for it.
03:01 sorear later versions of NQP incorporate parser-generator functionality
03:02 Tene Hackbinary: The right thing to do is fix the get_bool behaviour in cardinal's Integer class.
03:03 dukeleto Tene: is it correct to say that cardinal uses the old nqp and not nqp-rx ?
03:03 Tene Hackbinary: putting special-case behaviour to check values in the unless statement does not scale well.
03:03 Tene dukeleto: No, that's not accurate either.  It's using nqp-rx.
03:04 dukeleto Tene: so it uses nqp-rx, but not nqp-rx grammars ?
03:04 Tene dukeleto: That's right.
03:04 dukeleto Tene: is that because it is moving in the direction of nqp-rx grammars ?
03:04 Tene dukeleto: It's using nqp-rx because afaict old nqp isn't present in parrot any more.
03:05 Tene dukeleto: It would be great to migrate to nqp-rx grammars.  Nobody's currently working on it.
03:05 dukeleto Tene: yes, that is correct.
03:05 dukeleto Tene: ok, i think tadzik was interested it in at some point
03:05 Tene It's using nqp-rx because I checked to see if it ran on current parrot, and it didn't because no nqp, so I s/nqp/nqp-rx/ in the rakefile, and then it compiled again.
03:06 Hackbinary tene:  I was thinking that, however can the interger class handle from where it was asked, since if 0 should eval to false from if, but true from unless
03:07 Hackbinary so I was thinking that unless is a special case
03:08 Tene Hackbinary: Let me confirm something, because I'm not all that knowledgeable about ruby.
03:08 Tene if I have: "unless 0 do ... end" or whatever, does the ... run?
03:08 Hackbinary run ruby on t/01-stmts.t
03:09 Hackbinary then if you still have cardinal, run cardinal on t/01-stmts.t
03:09 Tene Hackbinary: see, the issue is that cardinal is just inheriting behaviour from parrot, and in parrot, 0 is false
03:10 Tene Hackbinary: 'unless' just gets the truth value from the argument, and inverts it.
03:10 Hackbinary for both if and unless, which actually makes more sense to
03:10 Hackbinary me
03:10 Hackbinary however, it handles 0 == 1 correctly
03:10 Hackbinary erm
03:10 sorear Who on the cardinal group is a ruby expert?
03:10 Tene sorear: treed
03:10 Hackbinary cardinal handles 0 == 1 correctly
03:12 Hackbinary because I tried adjusting the classes/integer get_bool behaviour, but then that broke if and 0 == 1
03:12 Hackbinary if that makes sense ;)
03:13 Tene Hackbinary: I don't see how that's relevant?
03:15 Tene Hackbinary: 'unless' should have no special cases at all.  The responsibility for evaluating truth belongs in the individual classes.
03:19 Tene Hackbinary: That breaking 0 == 1 means that there's an error elsewhere as well
03:20 Tene So really you should track down that error instead.
03:21 Tene Hackbinary: if you look in src/builtins/cmp.pir you'll see what the problem is.
03:21 Hackbinary tene: okay, that makes sense, but in the Integer.pir file, can I return a different value if the expression is from 'if' or 'unless'?
03:21 Hackbinary ah
03:21 Tene it uses the core parrot ops iseq and friends, and those return hll_mapped integers and dispatch to 'bool', which uses the get_bool vtable.
03:22 Tene I've got the basics of a patch for you in just a minute.
03:31 pmichaud draft of "What Rakudo needs from Parrot in 2011" available at http://pmichaud.com/sandbox/rakpar.txt
03:31 pmichaud comments and suggestions welcome; I'll send the "official message" to parrot-dev tonight or early tomorrow morning
03:35 Tene Haha, I managed to get it exactly backwards.
03:35 Hackbinary ;)
03:36 pmichaud that's common when dealing with "unless", I think.  :)
03:37 Tene Hackbinary: The confounding bug is in src/builtins/cmp.pir
03:37 Tene https://gist.github.com/07ae3cfeb8837ecfb424 is something close to right
03:37 * Tene slight update
03:39 Tene Hackbinary: I hope that helps.  If you can't get it working, don't worry, this has been a pretty big issue for HLLs on parrot.
03:40 Tene So if you don't get it, just move on to something else.  This is a pretty big problem to take on for your first patch.
03:40 Tene :)
03:40 Hackbinary alright cool .. thanks .. it's nearly 4 am here and I'm nackered
03:40 Hackbinary ;)
03:40 pmichaud 4am... good hacking time.  :)
03:41 Hackbinary I think there is something quirky about how ruby handles unless 0
03:43 Hackbinary or maybe not, it looks like that ruby if 0 is true
03:45 bacek_at_work pmichaud, "emitting PBC from Parrot". It's possible now. And it was main reason for me to update PCT to nqp. Just because I've implemented it in nqp :)
03:45 bacek_at_work pmichaud, more work required for Annotations and Debug segments though
03:45 pmichaud bacek_at_work: right, and possibly some documentation about how to do it
03:46 pmichaud and some sort of "official Parrot supported mechanism" for it
03:46 pmichaud i.e., some designation that "Parrot officially supports these methods for creating .pbc"
03:46 Tene Hackbinary: No, nothing quirky, it's just that 0 is true
03:46 Hackbinary tene: okay thanks
03:46 bacek_at_work pmichaud, in bright shiny future - just emit "newPOST". POST::Compiler.pbc() will do all magic
03:46 Tene Hackbinary: in ruby, the only false things are false and nil, and that's it
03:47 Tene everything else, always, is true.
03:47 pmichaud anyway, we'll undoubtedly have a way to get to the PBC generator you've worked on :-)
03:47 pmichaud bacek++
03:47 pmichaud afk, errands
03:47 bacek_at_work pmichaud, major task - emit newPOST from PAST.
03:48 pmichaud well, PAST::Compiler is going to be rewritten in NQP... indeed, much of it has been, I think.
03:48 pmichaud certainly the regex portions will be, too
03:48 bacek_at_work it's not about rewriting it into nqp.
03:49 bacek_at_work Currently it emits about 4 types of POST nodes.
03:49 bacek_at_work It will require much more. About 15 :)
03:49 pmichaud I'm guessing about 10.
03:49 pmichaud And we'll also want a POST that can work for other vm's besides Parrot.  :-)
03:50 bacek_at_work 12 actually
03:50 bacek_at_work 11. POST::Node is base class
03:50 pmichaud But yes, I know it's not just a straight translation of the existing code -- didn't expect it to be
03:50 snarkyboojum left #parrot
03:51 bacek_at_work pmichaud, https://github.com/parrot/pir/tree/master/src/POST + all current POST nodes.
03:52 pmichaud I'm likely to disagree with Key
03:52 bacek_at_work pmichaud, why?
03:52 pmichaud because Key is quite Parrot specific.
03:53 bacek_at_work hmmm
03:53 bacek_at_work What we can use for "Namespace identifier" instead?
03:53 pmichaud also, why is String separate from Constant, ooc?
03:53 bacek_at_work Constant can be PMC
03:54 bacek_at_work String contains .encoding
03:54 bacek_at_work (As we deprecated .charset)
03:54 bacek_at_work But POST::String isa POST::Constant
03:54 pmichaud hmmm.  PAST/POST always considered strings to be fundalmentally unicode
03:54 bacek_at_work yes, they are.
03:55 bacek_at_work But they can be utf8/utf16/ucs4 encoded
03:55 pmichaud ah.  PAST/POST always just thought of them as codepoints, w/o a specific encoding
03:55 bacek_at_work And I'm not in mood to change parrot to have "single internal encoding for strings"
03:55 pmichaud POST could choose whatever encoding it wanted
03:56 bacek_at_work POST - yes.
03:56 bacek_at_work But for compiling PIR I have to preserve it :)
03:56 pmichaud anyway, since you have 11 classes and I estimated about 10, I think we're overall in close agreement
03:56 pmichaud just a few changes here and there
03:56 bacek_at_work of course
03:56 bacek_at_work some polishing required.
03:56 pmichaud afk for errands for real this time :)
03:56 pmichaud bbl
04:11 cotto ~~
04:12 cotto allison_, ping
04:14 cotto dukeleto, ping
04:20 cotto KaeseEs, the profiling runcore tries to use the best available timing method provided by the platform.  You can use Parrot_hires_get_time and it'll try to dtrt.
04:37 cotto pmichaud, thanks for the list
04:38 Hackbinary tene: thanks, got it working =) ... I'm off to bed
04:50 plobsing pmichaud: (re: profiling wonkiness) callgrind inclusive stats seem off, true; however, non-inclusive looks intuitive. performance dominated by Regex::Cursor::!mark_{push,peek,fail} and Ops::Compiler::Grammar::ws. Perhaps something call-tree-related is off which affects the inclusive counts.
05:00 cotto The bright side of the profile wonkiness is that if there's a test case I can make sure it stays fixed.
05:01 cotto well, a small test case
05:01 pmichaud plobsing: I didn't think that parrot;slurp would be "inclusive", though.
05:07 plobsing pmichaud: that's what I'm saying. the call graph is probably messed up and things that aren't called by slurp are counted erroneously. the non-inclusive counts do not appear to be affected and are likely a useful tool.
05:07 nopaste left #parrot
05:08 pmichaud I don't completely understand what you're saying (which is somewhat my original point)
05:09 TonyC left #parrot
05:09 plobsing run callgrind_annotate with --inclusive=no to get counts which, as far as I can detemine, appear to be legit. in fact, --inclusive=no should be the default. not sure why you're seeing inclusive results.
05:10 pmichaud ...callgrind_annotate?  What's that?
05:10 pmichaud (I'm not intentionally playing dumb... this is the first I've ever heard of "callgrind_anotate")
05:11 plobsing callgrind_annotate is how I look at callgrind files, which is what pprof2cg generates
05:11 TonyC joined #parrot
05:12 pmichaud ah.  pprof2cg says to use kcachegrind, iirc.
05:12 nopaste joined #parrot
05:13 pmichaud So that's what I've been using.
05:14 plobsing kcachegrind is probably a prettier and more powerful choice, but cg_ann wfm
05:14 pmichaud well, except that kcachegrind seems to give really misleading results
05:14 pmichaud at any rate, parrot needs some instructions for its profiler, unless we expect everyone that wants to do profiling to visit #parrot for a lesson
05:15 Coke aloha: msg bacek - "seen foo ?" should work the same as "seen foo?"
05:15 aloha Coke: OK. I'll deliver the message.
05:15 pmichaud using callgrind_annotate doesn't tell me what the numbers represent
05:16 plobsing they represent "counts", which are roughly instructions executed, although I'm not sure how exactly that maps to parrot.
05:17 bacek_at_work Coke, ok.
05:17 bacek_at_work I suspect profiling runcore affected by misnumbering lines in IMCC
05:18 pmichaud anyway, this is helpful to get a little farther along in using the profiler.  But my request to Parrot still stands.
05:18 plobsing bacek_at_work: how can it be affected by misnumbered lines in IMCC if the numbering is hardcoded in the source and doesn't depend on IMCC's counting?
05:18 bacek_at_work plobsing, hardcoded where?
05:18 plobsing .annotate 'line' 33
05:19 bacek_at_work I don't think that profiling runcore uses annotations
05:19 bacek_at_work It's all about opcodes
05:19 plobsing so then it has nothing to do with line numbers. I fail to see any connection.
05:19 Tene Hackbinary: Great to hear it!  Let me know when I can review a patch.
05:20 bacek_at_work plobsing, ok. "pir line number in generated files"
05:20 plobsing and that being miscounted is getting into the PBC how?
05:22 pmichaud does callgrind_annotate show me how many times each function was called?
05:23 pmichaud that's pretty important to know
05:25 plobsing there's probably a way of getting that, but I've never needed it
05:28 plobsing looks like the --tree option does what you want
05:33 pmichaud maybe.  it doesn't seem to be accurate
05:34 pmichaud or I'm not understanding what it's saying.
05:45 cotto pmichaud, if you have ways that the profiling runcore could be more useful, please file a ticket or tell me.
05:46 pmichaud I may just expand with followups to parrot-dev.
05:46 cotto that's fine too
05:47 pmichaud I chose the ops2c example because (1) it's relatively small, relative to the size of a Rakudo program, and (2) it's completely contained in the parrot repo, needs no external files
05:47 cotto that's helpful
05:47 pmichaud so it's something we can all talk about and use without having to put together a lot of "setup"
05:49 pmichaud the fact that the call graph doesn't seem to be represented accurately makes me a bit suspicious of the reported counts
05:53 pmichaud afk, sleep
05:54 cotto 'night
05:55 rurban_ joined #parrot
05:58 rurban left #parrot
05:58 rurban_ is now known as rurban
07:04 snarkyboojum joined #parrot
07:11 dalek parrot: 1a28d8a | chromatic++ | lib/Parrot/Pmc2c/PCCMETHOD.pm:
07:11 dalek parrot: [lib] Marked unused return value as UNUSED.
07:11 dalek parrot:
07:11 dalek parrot: This should resolve several Coverity warnings such as CID #1279.
07:11 dalek parrot: review: https://github.com/parrot/parrot/commit/1a28d8a0c8
07:11 dalek parrot: 16ccd1d | chromatic++ | lib/Parrot/Pmc2c/PCCMETHOD.pm:
07:11 dalek parrot: [lib] Avoided double-declaration of a PMC param.
07:11 dalek parrot:
07:11 dalek parrot: This should close several Coverity reports, such as CID #1287. There's still a
07:11 dalek parrot: logical question in this code regarding the value of passing the PMC as a
07:11 dalek parrot: parameter to these functions, then immediately retrieving it from the call
07:11 dalek parrot: object, but that's a much larger change more worthwhile when we rewrite the PMC
07:11 dalek parrot: to C emitter.
07:11 dalek parrot: review: https://github.com/parrot/parrot/commit/16ccd1d386
07:11 dalek parrot: 01fef9c | chromatic++ | src/gc/alloc_resources.c:
07:11 dalek parrot: [GC] Simplified function for debug/non-debug cases.
07:11 dalek parrot:
07:11 dalek parrot: The motivation for this change is to avoid a side effect in the assert,
07:11 dalek parrot: specifically PARROT_ASSERT(--count), reported by Coverity in CID #441. Rather
07:11 dalek parrot: than wrapping #ifdefs around the decrement, it seems clearer to extract the
07:11 dalek parrot: normal behavior of the loop for non-debugging builds and to provide an
07:11 dalek parrot: alternate version in the case of a debugging build.
07:11 dalek parrot: review: https://github.com/parrot/parrot/commit/01fef9c435
07:18 bacek_at_work wow, first commit from chromatic in last 1.5 month! :)
07:21 Tene bacek_at_work: my recent commit to cardinal was my first in rather longer.
07:22 bacek_at_work Tene, welcome back :)
07:27 cotto ccache++
07:48 dalek winxed: r752 | NotFound++ | trunk/winxedst1.winxed:
07:48 dalek winxed: refactor some common parts of binary operators
07:48 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=752
07:50 dukeleto Tene: glad to see cardinal getting some movement
07:50 cotto dukeleto, ping
07:50 dukeleto cotto: pong
07:50 cotto dukeleto, it seems like a good time to start a regular conference call between Parrot's various team leads.
07:51 cotto do you think weekly would be feasible and helpful?
07:51 fperrad joined #parrot
07:51 dukeleto cotto: yes
07:52 cotto ok.  I'll send something out to the team leads.
07:54 cotto any ideas as to what's likely to work on a recurring basis?  I don't relish either setting up or entering data for every hour of the week.
07:54 dukeleto cotto++ # i've been meaning to do that and didn't find time
07:54 cotto the PDS made me think that we need to get on the ball there
07:54 dukeleto cotto: nah, i think with five people we can just talk about it
07:55 cotto also, I'm jazzed to have you and bacek helping with M0.
07:55 dukeleto cotto: it should be scary
07:55 dukeleto cotto: i've bean meaning to tell bacek that we should port parrot internals to YAML...
07:56 dukeleto because i hear he loves YAML
07:56 cotto +like a million
07:57 cotto We can make yaml to parse yaml to parse yaml.  That'll get us some enterprise users for sure.
07:57 dalek parrot: 368bb44 | chromatic++ | / (3 files):
07:57 dalek parrot: [ops] Allowd args ops direct access to sig count.
07:57 dalek parrot:
07:57 dalek parrot: Direct access through the FIA size macro speeds up these PCC hot path ops
07:57 dalek parrot: measurably, giving a 1.9% performance improvement on oofib, a benchmark almost
07:57 dalek parrot: solely devoted to measuring PCC performance.
07:57 dalek parrot: review: https://github.com/parrot/parrot/commit/368bb441fd
07:57 cotto especially since yaml isn't traditionally executable
07:58 dukeleto cotto: we can have YAMLcutables
07:59 cotto and we can have yaml be the serialization format for M0
07:59 cotto the sky's the limit
07:59 bacek Dear motherf^W idiots! Please stop it now :)
07:59 dalek winxed: r753 | NotFound++ | trunk/winxedst1.winxed:
07:59 dalek winxed: optimize a bit some frequent usages of && and ||
07:59 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=753
08:00 cotto bacek, it's nice to have you around.
08:00 dukeleto YAML from the rooftops! YAML on the beaches! YAML in the streets...
08:00 dukeleto Who will YAML the YAMLers?
08:00 dukeleto ok, i am done
08:00 bacek cotto, not for long I suspect. I'll new bloody big project at $work starting from March...
08:01 cotto disappointed face
08:01 dukeleto bacek: can you describe what the next steps for GenGC are?
08:01 bacek dukeleto, 1) read proposed algorithm; 2) implement it; ... 4) Profit!
08:02 dukeleto bacek: i think you missed 3) beer
08:02 bacek dukeleto, no. Beer is step 0
08:02 dukeleto bacek: lulz
08:02 dukeleto bacek: yes, it is
08:02 cotto and 1a and 2a...
08:03 bacek from 1a till 1z actually
08:03 cotto Mmmmm.  uncountable beer.
08:03 dukeleto bacek: which gengc algorithms do you have in mind?
08:03 dukeleto bacek: which fit our current system? have you ruled any out yet?
08:04 cotto dukeleto, he has it documented in some detail in his branch
08:04 dukeleto cotto: well, then
08:04 * dukeleto hasn't looked at the branch, he just likes pestering bacek
08:04 cotto It's cleverly disguised as the description of an existing algorithm.
08:05 dukeleto cotto: which branch are we talking about?
08:05 cotto generational_gc
08:05 bacek dukeleto, https://github.com/parrot/parrot/bl​ob/generational_gc/src/gc/gc_gms.c
08:05 bacek top of the file
08:06 bacek (code isn't related to algorithm at all)
08:07 cotto hence the clever disguise
08:08 dukeleto bacek: so that overview at the top of that file is what needs to happen, but you still need to choose an implementation?
08:08 dukeleto bacek: or do i misunderstand?
08:09 bacek dukeleto, it's what I'm going to implement. If this algo makes sense at all.
08:09 * dukeleto often misunderstands
08:09 dukeleto bacek: what % of what is described at the top already implemented?
08:09 bacek dukeleto, close to 0
08:10 dukeleto bacek: how do you know when you make progress? are you using tests to figure out if stuff works?
08:10 bacek dukeleto, I need second pair of eyes to review it.
08:10 dukeleto bacek: i assume it is hard to test
08:11 bacek dukeleto, and test isn't a huge problem. Just big :)
08:13 dukeleto bacek: is there some kind of papers that i can read which are similar to the algorithm that you describe?
08:14 bacek dukeleto, hmm... Just generic papers about GC. This algorithm is very parrot specific. For example it uses VTABLE_mark for traversing, etc
08:15 dukeleto bacek: well, generational gc's are a specific kind, just wondering which papers you are reading
08:15 cotto that's just an implementation deail though
08:15 dukeleto bacek: and i see many different kinds of gen gc's
08:15 bacek dukeleto, a lot of them. Don't remember which one exactly...
08:15 dukeleto bacek: what is blocking you on that branch? time? or something else?
08:16 bacek dukeleto, <bacek> dukeleto, I need second pair of eyes to review it.
08:16 bacek :)
08:16 dukeleto bacek: just trying to poke into your brains to see what is going on in there
08:16 dukeleto bacek: that doesn't mean too much. what feedback are you looking for?
08:16 bacek dukeleto, "does it make sense at all"
08:17 dukeleto bacek: you are doing it all wrong. You should fix it and work 25 hours a day until it is perfect.
08:17 dukeleto bacek: is that good feedback? ;)
08:17 bacek actually, I can implement simple 2 generations GC as first cut.
08:17 bacek Which is much simpler
08:17 dukeleto bacek: who would be a good code-reviewer ?
08:17 bacek dukeleto, you!
08:18 cotto If you have to ask...
08:18 dukeleto bacek: well, one thing i see is how you decide which generation to collect
08:18 cotto ;)
08:18 dukeleto bacek: that looks like LHF to make a bit better
08:18 dukeleto bacek: basically just adds some counters to keep track of allocated memory per generation, right?
08:18 dukeleto s/just adds/just add/
08:18 bacek dukeleto, may be. But atm I'm at step 0. And run out of beer.
08:19 dukeleto bacek: we need to get you a beer helmet
08:19 bacek bb in about 20m :)
08:19 dukeleto bacek: if I mail you a beer helmet, will that improve productivity?
08:19 bacek with infinite supply of beer!
08:19 bacek www.manuel-blechschmidt.de​/data/Generational_GQ.pdf
08:20 * dukeleto looks
08:20 bacek This is trivial 2gens GC. I can implement it in about a week.
08:20 dukeleto bacek: do it!
08:20 bacek "2gens" is so 90s...
08:20 dukeleto bacek: 2 gens is better than no gens
08:21 bacek we have at least 1!
08:21 bacek afk # shopping
08:21 dukeleto cotto: what are you hacking on?
08:24 cotto I'm shuffling code around to make it easier to get callgrind-compatible output directly from the profiling runcore.
08:25 cotto the current process isn't lazy enough
08:26 cotto It's amazing how often I misspell "cg".
08:26 dukeleto cotto: that sounds very useful
08:27 dukeleto cotto: what is your game plan for the lorito prototype? I invite you to work on my lorito branch
08:27 dukeleto cotto: my game plan is basically the dynop approach that we talked about when we met up with allison and chromatic
08:27 cotto the current meta-plan is to look for holes in the current state of the art and find useful places to steal from to fill in those holes
08:28 dukeleto cotto: and i have the stub of a LoritoContext PMC that will be the continuation that is passed along
08:28 cotto I'm thinking more about the spec than the implementation.
08:28 dukeleto cotto: ok, i like that
08:28 dukeleto cotto: we need a spec
08:28 dukeleto cotto: i am reading about the smalltalk vm
08:28 cotto I suspect that once the spec is ready it'll take maybe a week or two to get a usable prototype from it.
08:28 dukeleto cotto: it is stack based, but uses continuations
08:29 dukeleto cotto: do you have a beginning of a spec in a public place?
08:29 cotto dukeleto, great.  I love cross-pollination of ideas
08:29 dukeleto cotto: i would like the help with it
08:29 cotto nothing more than's on the wiki
08:29 cotto I'd like to set up a series of more orgainzed pages there that read like a more traditional spec
08:30 dukeleto cotto: i have been reading everything i can about continuation-passing-style, because that is basically what M0 has to implement, if i understand correctly
08:30 dukeleto cotto: shall we put the spec in the repo?
08:30 dukeleto cotto: perhaps in docs/ ?
08:30 dukeleto cotto: i think lorito is important enough to have a design document
08:30 dukeleto cotto: perhaps docs/pdds/draft ?
08:31 dukeleto cotto: or we can make a new github repo for it
08:31 cotto dukeleto, I like the wiki but I don't care much.
08:31 dukeleto cotto: whatev. but make it publicly viewable and editable by parrot devs
08:31 dukeleto cotto: the wiki isn't git
08:31 cotto sadly not
08:32 cotto but git does function as something like a wiki
08:32 cotto er, github
08:32 dukeleto cotto: is there a specific wiki page about the first lorito prototype, which we have promised for 3.3 ?
08:32 cotto if it weren't too painful, a github wiki would be nice
08:32 cotto dukeleto, no
08:33 dukeleto cotto: the github wiki system is open source, and understand 11 markup languages, and is a normal git repo to boot
08:33 cotto that's why it'd be nice
08:33 dukeleto cotto: called "gollum"
08:33 dukeleto cotto: but i am not volunteering to convert trac anytime soon
08:34 dukeleto cotto: which wiki page are you going to put the spec on?
08:34 dukeleto cotto: i am going full throttle at the lorito spec and ignoring everything else in parrot
08:34 cotto haven't thouhght about it
08:35 dukeleto cotto: we need a feature set that the first prototype should have
08:35 cotto I'm looking at profiling because pmichaud mentioned that it needs love (and because I want to write code on occasion), but M0 is the first priority.
08:35 Psyche^ joined #parrot
08:36 cotto structs, functions, arrays, support for a hash implementation
08:36 cotto if we have that, we can do 6model
08:36 Patterner left #parrot
08:36 Psyche^ is now known as Patterner
08:36 cotto I consider the deliverable to be a demo (or demos) that show those 4 features.
08:37 cotto runnably
08:37 dukeleto cotto: ok, it is something to shoot for
08:37 dukeleto cotto: is there a roadmap tt that we can add that to?
08:38 cotto I'm learning that you're more structure-oriented than I am.  I suspect this will be a good thing.
08:38 dukeleto cotto: yes :)
08:38 cotto no, btw
08:38 dukeleto cotto: i am learning to be more structured in my coding, mostly from external influence
08:38 dukeleto you know, people who say "where is the code?"
08:39 dukeleto cotto: are you thinking 6model gets implemented in M0 or M1 ?
08:39 dukeleto cotto: i think it could be either
08:39 dukeleto cotto: but i don't fully understant the implications, because M1 is not well-defined
08:39 dalek parrot: 75bb241 | cotto++ | src/platform/generic/error.c:
08:39 dalek parrot: fix headerizer warning
08:39 dalek parrot: review: https://github.com/parrot/parrot/commit/75bb241e49
08:39 dalek parrot: 6074fa4 | cotto++ | / (2 files):
08:39 dalek parrot: [profiling] abstract out the differences between different output methods, make usage a little less awkward
08:39 dalek parrot: review: https://github.com/parrot/parrot/commit/6074fa4d37
08:39 dalek parrot: 899be57 | cotto++ | / (2 files):
08:39 dalek parrot: [profiling] move some more init code into a separate function
08:39 dalek parrot: review: https://github.com/parrot/parrot/commit/899be57596
08:39 dalek parrot: 49b89e4 | cotto++ | include/parrot/runcore_profiling.h:
08:39 dalek parrot: [profiling] fix a leftover debugging statement
08:39 dalek parrot: review: https://github.com/parrot/parrot/commit/49b89e4871
08:39 dalek parrot: 40e1059 | cotto++ | src/runcore/profiling.c:
08:39 dalek parrot: [profiling] shuffle a function around
08:39 dalek parrot: review: https://github.com/parrot/parrot/commit/40e1059179
08:40 dukeleto cotto: but i assume that M1 is roughly isomorphic to PIR, but perhaps that is wrong
08:40 cotto PIR is an M1-level language
08:40 cotto there may be others
08:41 dukeleto cotto: so my question is: Does our MOP get written on top of M0 or M1 ?
08:41 cotto on top of M0
08:41 cotto in M0 ops
08:41 dukeleto cotto: that answers my question
08:41 cotto one down, ...
08:42 dukeleto cotto: that will guide are design of M0
08:42 dukeleto cotto: if we can't implement a MOP in M0 ops, then the set of M0 ops is too small
08:42 cotto exactly
08:42 dukeleto cotto: and we can basically remove ops from M0 until we can't write a MOP anymore
08:42 dukeleto cotto: and then M0 should be about the right size
08:42 cotto yup
08:43 dukeleto cotto: i also have been reading "The Art of the Meta Object Protocol"
08:43 dukeleto cotto: very dry but very informative book
08:43 cotto lisp scares me
08:43 cotto I ought to get over that
08:43 ttbot Parrot 40e10591 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/3343.txt (http://tt.taptinder.org/buildstatus/pr-Parrot)
08:44 dukeleto cotto: i've never used it, but i can still read about concepts and read along and get the gist of lisp
08:44 cotto oh noes
08:44 dukeleto cotto: you broke stuff and things
08:44 cotto no rest for the careless
08:44 dukeleto M0 = { the smallest set of ops required to write a MOP }
08:44 dukeleto i like that definition of M)
08:45 dukeleto M0, rather
08:45 dukeleto it is a bit more concrete
08:45 cotto ambiguous but concise
08:46 dukeleto cotto: the -Ofun is in the details
08:47 dukeleto cotto: i have some implementation questions for you :)
08:47 cotto I'll be up until I fix the build
08:48 dukeleto cotto: i think i can just use a Continuation PMC and I don't need a LoritoContext PMC
08:50 dukeleto cotto: i think i need to gather my thoughts more before i can ask useful questions
08:50 dukeleto cotto: good luck fixing the build
08:50 cotto it's a new error to me
08:53 cotto and thus meaningless casts saved the build
08:53 dalek parrot: 48c1717 | cotto++ | include/parrot/runcore_profiling.h:
08:53 dalek parrot: fix the c++ build
08:53 dalek parrot: review: https://github.com/parrot/parrot/commit/48c1717444
08:54 cotto seen fbrito
08:54 clunker3 Sorry, cotto, I haven't seen fbrito.
08:54 aloha fbrito was last seen in #parrot 3 days 14 hours ago leaving the channel.
08:54 cotto seen fbrito
08:54 clunker3 Sorry, cotto, I haven't seen fbrito.
08:54 aloha fbrito was last seen in #parrot 3 days 14 hours ago leaving the channel.
08:55 cotto msg fbrito How's the github hook hacking going?
08:55 aloha OK. I'll deliver the message.
08:55 * cotto wonders why clunker3 is here
08:56 cotto it was time for sleep an hour ago, but I guess now will have to do.
08:56 cotto 'night
09:03 AzureSto_ left #parrot
09:04 AzureStone joined #parrot
09:05 moritz aloha: msg pmichaud re http://pmichaud.com/sandbox/rakpar.txt "This likely has some relation to #2 above" should be #3
09:05 aloha moritz: OK. I'll deliver the message.
09:16 dip joined #parrot
09:56 bacek aloha, 26 * 60 + 62
09:56 aloha bacek: 1622
09:57 bacek aloha, 25 * 60 + 62
09:57 aloha bacek: 1562
09:57 bacek aloha, (1622 - 1562) / 1622 * 100
09:57 aloha bacek: 3.69913686806412
09:57 bacek Looks about all right
10:04 particle1 joined #parrot
10:06 particle left #parrot
11:08 dalek left #parrot
11:08 elmex_ joined #parrot
11:08 elmex left #parrot
11:08 elmex_ is now known as elmex
11:09 bacek msg cotto I would like to get rid of all old GC MS leftovers (including GC MS itself). Any objections?
11:09 aloha OK. I'll deliver the message.
11:11 dalek joined #parrot
11:12 Maddingue left #parrot
11:12 Maddingue joined #parrot
11:37 kid51 joined #parrot
11:39 contingencyplan left #parrot
11:46 particle joined #parrot
11:49 particle1 left #parrot
12:18 bluescreen joined #parrot
13:19 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#6531) fulltest) at 3_0_0-362-g48c1717 - Ubuntu 10.10 i386 (g++-4.5 with --optimize)
13:21 kid51 left #parrot
13:33 bluescreen left #parrot
13:46 whiteknight joined #parrot
13:48 bluescreen joined #parrot
13:55 rurban_ joined #parrot
13:57 whiteknight good morning, #parrot
13:58 rurban left #parrot
13:58 rurban_ is now known as rurban
14:01 moritz good morning whiteknight
14:01 whiteknight hello moritz, how are you today?
14:03 moritz whiteknight: a bit tired (not too uncommon for fresh parents), otherwise quite well
14:03 whiteknight no, it's not uncommon at all
14:06 PerlJam moritz: It's not uncommon irregardless of the parental "freshness"
14:07 moritz PerlJam: I do hope that I'll get more sleep in a few years :-)
14:08 PerlJam moritz: until my twins were about 3 or so they'd wake me up each night separately.   Now I get less sleep because it's when everyone is in bed asleep that I can have some time to myself
14:09 moritz :-)
14:09 moritz but at least in theory you *could* sleep
14:09 PerlJam in practice, sometimes I have no choice  :)
14:10 PerlJam There have been times when I've served myself a nice glass of tea and settled in with my laptop only  to wake up hours later with the laptop on my lap and a full glass of tea next to me.
14:10 plobsing left #parrot
14:13 pmichaud good morning, #parrot
14:13 Coke PerlJam: that could end worse, so good job. ;)
14:13 Coke pmichaud: hio.
14:13 moritz \o pmichaud
14:14 PerlJam pmichaud: good morning
14:40 ascent left #parrot
14:43 whiteknight pmichaud: it looks like you just got bumped/unsubscribed from parrot-directors
14:43 whiteknight I don't know why
14:47 pmichaud I unsubscribed... I think I was supposed to do that last fall but didn't get around to it
14:47 pmichaud if you want me to remain on the list, I can certainly do that :)
14:48 whiteknight oh, it looked like you got booted because of a bounced email
14:49 whiteknight I'm just making sure it's not unexpected :)
14:49 pmichaud It's not.  I'm just cleaning by backlog of things "oh yes, I'm supposed to ...."
14:50 mikehh forgoit to report:
14:50 mikehh rakudo (fcc46ea) - builds on parrot (3_0_0-362-g48c1717)- make test, make spectest_smolder[(#6541), roast (afcdfa2)] PASS - Ubuntu 10.10 i386 (g++-4.5 with --optimize)
14:50 mikehh 27,600 ok, 0 failed, 611 todo, 1,837 skipped and 0 unexpectedly succeeded
15:03 PacoLinux joined #parrot
15:14 Andy left #parrot
15:24 Coke pmichaud++: thanks for writing those emails up
15:42 plobsing joined #parrot
15:44 Hackbinary hello, where is the best place to read up on PAST::Op ?
15:44 ascent joined #parrot
16:00 Andy joined #parrot
16:01 allison_ is now known as allison
16:04 contingencyplan joined #parrot
16:06 cotto bacek, why would that be objectionable?  As long as you maintain compatibility for existing exposed functions, go ahead.  GC is an internal detail that users shouldn't be relying on.
16:06 bluescreen left #parrot
16:10 Coke Hackbinary: when I was trying to find data on those, the docs in the source files in compilers/pct/src was the best spot.
16:10 Coke (you can read just the docs with "perldoc <file>")
16:12 freeksh0w86 joined #parrot
16:15 Patterner left #parrot
16:15 Psyche^ joined #parrot
16:15 Psyche^ is now known as Patterner
16:23 jsut joined #parrot
16:27 mtk joined #parrot
16:34 freeksh0w86 i got "config/gen/platform/win32/begin.c:10:6: #error Minimum requirement for Parrot on Windows is Windows 2000 - might want to check windef.h" trying to build Parrot 3.0.0 on Windows 7... i'm using a Strawberry Perl binary would that be a problem?
16:35 dalek winxed: r754 | NotFound++ | trunk/winxedst1.winxed:
16:35 dalek winxed: refactor constant optimization of some binary operators and apply it also to '%'
16:35 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=754
16:35 Hackbinary what is dalek?
16:37 freeksh0w86 also is there a way i can use Visual C++ express compiler to build Parrot? apparently strawberry ships with its own deficient gcc3.4 compiler and has problems detecting libraries i have on my system (judging by the Configure.pl output).
16:38 moritz whiteknight++ # very well thought-out email to parrot-dev (PDS aftermath, .nqp)
16:39 moritz plobsing++ # same reasons
16:40 plobsing freeksh0w86: http://trac.parrot.org/par​rot/wiki/Platforms/Windows
16:40 sorear Hackbinary: commit reporter
16:40 pmichaud "Parrot's repository should not contain any tools, utilities, or
16:40 pmichaud libraries written in a language which is not itself provided in the
16:40 pmichaud Parrot repo (with a *very* small handful of exceptions, including
16:40 pmichaud Configure.pl and maybe the Python-based GDB pretty-printers). "
16:40 dalek winxed: r755 | NotFound++ | trunk/winxedst0.cpp:
16:40 dalek winxed: operators '<<' and '>>' in stage 0
16:40 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=755
16:41 pmichaud Somehow I don't think that is really sustainable, but that's just me.
16:41 sorear C?
16:41 sorear sh?
16:41 Coke pmichaud: I think that's overstating the situation, yah.
16:41 plobsing sorear: sshhhh!!!
16:41 Coke I think they meant "that we don't already require to build."
16:41 pmichaud Basically, it says that Parrot itself won't take advantage of any utilities or tools that come from things built on top of Parrot.
16:42 pmichaud it's like saying "Perl won't bundle anything that comes from CPAN"
16:42 * moritz also thought "C?"
16:42 pmichaud (I'll grant that "repository" and "distribution bundle" are separate.)
16:42 pmichaud s/separate/potentially separate
16:43 pmichaud Still, the idea of creating a Perl distribution without using anything from CPAN would seem like overkill to me
16:43 plobsing my opinion is that we already do far too much in C when the language choice is open to hosted HLLs
16:43 pmichaud so saying that "Parrot core can only use things developed by Parrot" seems unsustainable
16:44 Coke pmichaud: where are you quoting that from?
16:44 pmichaud it's meant as a paraphrase, not a direct quote
16:45 pmichaud but certainly there's an underlying theme of "we have to own anything we use"
16:45 pmichaud in both whiteknight++'s and particle++'s messages
16:45 pmichaud er, "underlying theme" is too strong.  "implication"  is more accurate.
16:46 cotto_work ~~
16:46 dalek winxed: r756 | NotFound++ | trunk/winxedst1.winxed:
16:46 dalek winxed: constant optimization of '<<' and '>>'
16:46 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=756
16:47 pmichaud "The problem is that we don't have any real control over it..."    Any HLL could make the exact same claim about using Parrot.
16:47 pmichaud (this last quote is from whiteknight++'s message)
16:48 Coke speaking of strawman, chromatic notices my obvious intentional one, and then dangles several more. wtf.
16:49 pmichaud I guess I should write this up as a reply on parrot-dev, although part of me wants to remain apart from the discussion.
16:50 chromatic joined #parrot
16:50 chromatic Coke: name one.
16:50 pmichaud okay, after reading the latest messages I'm definitely staying out of the thread.
16:51 pmichaud other than to identify factual assistance
16:52 Coke chromatic: replied to your last message.
16:52 chromatic Do you believe we can import a new NQP wholesale into Parrot and explicitly disclaim support for it per our existing support policies?  I'm not sure we can.
16:53 Coke ... is that the plan?
16:53 Coke I must be confused about the plan.
16:53 chromatic I hope it's not the plan. My point is that it's a plan which requires rethinking Parrot's goals.
16:54 chromatic If it becomes the plan, that's fine as long as everyone's clear what it entails.
16:54 Coke are you suggesting it's the plan now?
16:54 Coke (sounds like no. if not, isn't that axiomatically a strawman?)
16:54 pmichaud Coke: are you the best person for me to contact about updating my planetsix feed address?
16:55 Coke pmichaud: I'm a person. I'm here. lemme dig up the repo.
16:55 Coke pmichaud: you don't have a planetsix entry.
16:55 pmichaud I did at one time
16:55 pmichaud maybe it got removed
16:55 pmichaud anyway, http://pmthium.com/category/perl6/feed/
16:56 chromatic I have no idea how to respond. Multiple people have said "Not supporting portability is bad!" I outline reasons why we might not want to do such a thing. What's the problem?
16:56 Coke preferred display for name?
16:57 NotFound BTW I don't have any objection regarding forking winxed, including a snapshot of it in the parrot repo, or any other similar arragement.
16:57 pmichaud Patrick R. Michaud, I guess
16:57 pmichaud let me look at the other examples
16:57 pmichaud yes, just my name
16:57 Coke particle was coming off as more anti-nqp-changes than "
16:57 cotto_work NotFound: what can PIR do that winxed can't?
16:57 pmichaud could be   "Patrick R. Michaud (pmthium)"
16:58 pmichaud to be analogous with jnthn++'s   "Jonathan Worthington (6guts)"
16:58 Coke pmichaud: done.
16:58 pmichaud danke
16:58 NotFound cotto_work: the main limitation now is that winxed doesn not support :multi
16:58 particle did i ever use "must" instead of "may" in my email?
16:58 chromatic Coke, I would have responded to Moritz's silly strawman, but you phrased it much better than he did.
16:59 particle did my summary sentence at the end not make clear my intent with my email? i guess i'll need to clarify.
16:59 moritz chromatic: your first statements to cross-VM portability did sound like you thought the portability itself was a bad thing. That's why I responded the way I did
16:59 Coke I really need to get back to $DAYJOB, but let me find the bit of particle's email that made me run screaming.
16:59 moritz chromatic: maybe it was merely a failure to communicate
16:59 Coke "the concern with parrot supporting the new nqp is that any tools we
16:59 atrodo I'm looking forward to reading the thread, if i can ever find the time
17:00 Coke write using nqp can be easily ported to any other vm." "i only wish to point out the
17:00 chromatic Let me be clearer then: however good cross-VM portability is when I'm not wearing my Parrot hat, I see it as potentially expensive for Parrot.
17:00 Coke specific risks associated with the new version of nqp"
17:00 whiteknight chromatic: so long as that portability is implemented by NQP and isn't based on anything related to Parrot, it shouldn't matter to us
17:00 Coke yes, but I've seen no one suggest that parrot is goin
17:00 Coke damnit.
17:00 whiteknight new NQP can be portable all day long, so long as *they* provide the wrappers
17:01 moritz +1
17:01 Coke is going to have to put out any more effort than we already do to support rakudo.
17:01 chromatic That doesn't alleviate all of my concerns.
17:01 moritz and the "new nqp" actually can exploit parrot features that the old one can't
17:02 Hackbinary what do you want new npq to be portable with?
17:02 whiteknight chromatic: so then how do we alleviate them?
17:02 particle i never mentioned nqp benefits, as i can't speak to them
17:02 Coke Hackbinary: have you read the thread on the parrot-dev mailing list?
17:02 pmichaud Hackbinary:  url coming
17:02 plobsing NotFound: there are other (minor in my mind) mismatches between winxed and PIR. pirops from within winxed cannot use labels (for example). this limits control-flow to built-ins only and prevents the use of local_branch/local_return.
17:02 chromatic I'm not sure NQP can alleviate them. NB those risks might be acceptable, but I want us at least to consider them.
17:03 pmichaud Hackbinary: actually, you can read the details at http://pmthium.com/
17:03 pmichaud parrot-dev threads are at:
17:03 pmichaud alleviate them. NB those risks might be acceptable, but I want us at least to consider them.
17:03 pmichaud grrrrr
17:03 pmichaud bad past
17:03 pmichaud *paste
17:03 pmichaud http://lists.parrot.org/pipermail/p​arrot-dev/2011-January/005408.html
17:04 Hackbinary coke: thanks, I should prolly read that b4 I add my 2p.   But, perhaps from an naive/newbie POV, I would think that nqp should be optimized for parrot first
17:04 NotFound plobsing: yes, I'm thinking about providing a 'label' pseudo-function builtin to allow that, but haven't decided yet.
17:04 pmichaud http://lists.parrot.org/pipermail/p​arrot-dev/2011-January/005402.html
17:04 pmichaud nqp almost certainly is optimized for parrot first
17:05 pmichaud afk, lunch
17:06 Hackbinary and that portiablity as a philosophy is never a bad thing -- from the sense that it creates freedom, and letting people have options
17:07 plobsing NotFound: perhaps I can convince you to provide a prefixed-syntax for labels within pirops, somewhat like I pitched to bacek for PIRATE. if those two were consistent, it would work out very nicely.
17:07 NotFound Hackbinary: philosophy is in the mind, code supporting it must be written, tested, and maintained.
17:07 plobsing eg: ${ goto &label };
17:09 NotFound plobsing: yes, but I try to not over reuse common operators that I may want later for conflicting usages.
17:09 Hackbinary notfound: +1
17:10 plobsing it was just an idea. bacek might not wind up using it either.
17:12 zby_home joined #parrot
17:13 NotFound plobsing: maybe using ':', looks less conflicting to me: ${ goto :label };
17:14 plobsing as usual, I'm happy with whatever you cook up for winxed. just keep increasing the scope of winxed as a better PIR than PIR.
17:15 NotFound From the point of view of human read and write ability, is not hard to beat PIR ;)
17:16 cotto_work not at all
17:16 chromatic IMCC was scope creep for Parrot.
17:17 plobsing and we're hitting the hard limits of its capabilities. for example issues with more complex uses of static PMCs.
17:19 plobsing I'm not really sure how any low-level language would go about providing a general capability like that.
17:19 chromatic No, it can't provide the right level of abstraction.
17:23 Kristaba joined #parrot
17:23 Coke in retrospect, avoiding imcc and having something like scheme that created PASM would have been much better, IMO.
17:23 Coke ah well.
17:23 chromatic Parrot should have tried to build a PCT from the start, as I see it.
17:23 slavorg joined #parrot
17:23 cotto_work yet here we are
17:24 chromatic The first *two* Perl 6 implementations were Perl 5 programs which parsed Perl 6 source code and emitted PASM directly.
17:24 Coke chromatic: so, I definitely understand wanting to avoid spending our scare cycles in the wrong area.
17:24 chromatic That's my concern: scope management.
17:25 NotFound A way to address the speed concerns with "constant" PMCs may be to allow to write to the "constant" table at :load and :init time. Is some cases the speed problem comes from locating the PMC by name in a namespace instead of a numeric addressing in that table.
17:25 chromatic Philosophical discussions of the value of portability in general or to any project in specific miss the point.
17:25 Coke Ok. I think we can do a better job framing that concern. That's all.
17:25 whiteknight I definitely don't think NQP is what we need as a low-level interface language for Parrot. PIR is clearly not it either
17:25 chromatic That is exactly my goal.
17:26 whiteknight so the real question is "what is the perfect language for that role?"
17:26 plobsing left #parrot
17:26 NotFound Klingon
17:26 whiteknight still arguably better than PIR
17:26 chromatic Maybe we don't need a single language but the everything-after-NQP-the-language stages of PCT.
17:27 Coke lojmIt yIpoSmoH!
17:28 whiteknight chromatic: we still need some language to write crap like pmc2c in. I refuse to write those kinds of tools as sequences of PAST tokens
17:28 chromatic I agree, but maybe we're approaching this from the wrong end.
17:28 bluescreen joined #parrot
17:29 chromatic If it's true (and let's assume it is for the sake of argument) that a Python or PHP hacker won't want to write in NQP, what will they write in?
17:29 chromatic If the answer is "Whatever generates tokens for the other stages of PCT", then cool.
17:29 whiteknight Python and PHP, respectively
17:29 chromatic See also MAD in Perl 5.
17:29 plobsing joined #parrot
17:30 whiteknight there is a cultural infight between dynamic languages communities. Python hackers aren't perl hackers for a reason, and vice-versa
17:30 whiteknight a perl-like language is going to be distasteful to a python hacker.
17:30 whiteknight that said, a new, neutral language will not be
17:30 chromatic I question that assumption, but let's assume it for now.
17:30 whiteknight I've heard people say that in this very channel enough
17:30 PerlJam I disagree with that assumption from the peanut gallery
17:31 chromatic I've also heard people say that I hate portability in this very channel, so take that with a salt lick too.
17:31 whiteknight salted
17:32 whiteknight we need a language for our internal toolset that we can control, and we can bend to the needs of our VM
17:32 whiteknight that clearly isn't any existing variation of NQP
17:32 chromatic Let's not throw out all of NQP and its later stages so hastily though.
17:32 whiteknight I'm not throwing it out
17:33 chromatic I know you're not, but this is a public channel so we can afford to be much clearer.
17:33 whiteknight fair enough
17:33 chromatic We have a multiple stage compiler toolkit. If only the first stage, the surface syntax, of NQP may not be what we need, let's see if we can reuse the rest.
17:33 whiteknight right. Any language that compiles down to PAST or something sufficiently PAST-alike works
17:33 NotFound "generates tokens for the other stages of PCT" --> Someone wants to help with a winxed backend that do that?
17:33 PerlJam chromatic++
17:33 whiteknight ...and we come back to Winxed
17:34 freeksh0w86 left #parrot
17:34 whiteknight I like NQP, I really do. But we're at a point where the NQP language is moving away from the needs of Parrot precisely at the time when we are trying to eject PIR and yet still have something that we can have very close to Parrot
17:34 chromatic I like the idea of Winxed, but having a tool written in C++ is a cultural change from Parrot as it's existed as a project until now. We should consider the benefits and drawbacks of that too (but I still think it's worth considering seriously).
17:35 chromatic I'm less enthusiastic about ejecting PIR.
17:35 whiteknight chromatic: that's the stage-0. We can fork out only the stage-1 work
17:35 NotFound chromatic: The C++ stage is just the bootstraping tool.
17:35 chromatic Oh, right.
17:36 whiteknight chromatic: no, I should be clearer. not ejecting PIR, but definitely removing it's privileged status
17:36 chromatic As long as we have a credible replacement for the first-among-equals languages, fine with me.
17:36 whiteknight I am very hopeful that, in the world of Lorito, that PIR is able to improve and gain more and better syntax
17:36 whiteknight chromatic: right. We don't have that yet. May not for a while if we don't set our sights on a target now
17:37 plobsing NotFound: ohm-eta compliments winxed well for parser-type stuff. it is designed for working with sequences (characters, tokens, objects, etc).
17:37 NotFound Of course, the bootstraping tool needs to write pir, unless we provide a tool to parse a text representation of PAST
17:37 whiteknight plobsing: what is the state of ohm-eta? Does it work?
17:37 PerlJam What are the necessary or desired features of a language with which to write compilers?   Maybe someone should nail that down so there's a metric by which  to compare contenders
17:38 chromatic ... or needs to generate PMCs/something that are a PAST in memory.
17:38 plobsing whiteknight: it works and passes all of its tests (2 :( ), albeit with winxed warnings. I've been meaning to write a test harness to ignore the warnings, and to add it to plumage. At that point I'd make some kind of beta release.
17:39 whiteknight plobsing: that's awesome to hear.
17:39 NotFound PerlJam: the most used demonstration of the suitability for writing compilers is to self-compile.
17:40 PerlJam NotFound: Sure, but I was thinking of breaking that down into slightly lower level components  :)
17:40 PerlJam For instance, NQP has Perl 6 grammars. Is that a necessary feature?  (grammars, not necessarily Perl 6 grammars)
17:41 chromatic Maybe what we're trying to do is split NQP into two parts.
17:41 chromatic Or at least merge what of NQP/PCT Parrot needs, wants, and can support into Parrot proper.
17:41 NotFound winxed uses regex only as a helper to parse .pasm include files. That's it's most grammar-alike usage.
17:42 plobsing PerlJam: you can always hand code a parser (a little turing-tarpit) or write a code-generator.
17:42 NotFound Grammars are convenient, but there are other ways.
17:42 whiteknight chromatic: If we forked NQP, we could modify it to be anything we need. It would lose it's relationship with Perl6 since we wouldn't have any need to maintain that
17:42 whiteknight it does have a number of nice syntactical features
17:42 chromatic I don't think forking NQP meets Rakudo's goals though.
17:42 moritz which means you'd have to properly spec and document it
17:42 whiteknight it's not a matter of Rakudo's goals. They've got their own new NQP
17:42 PerlJam plobsing, NotFound: exactly.  So, what are the desired/required features for Parrot's toolchain language?
17:43 whiteknight they use their own tool, we're looking for something that we can call our own and use for our own purposes in our own repo
17:43 chromatic That's been one of the biggest problems between Rakudo and Parrot.
17:43 NotFound PerlJam: obviously for me the answer is: the ones that winxed has ;)
17:44 plobsing plus those that Ωη adds :^)
17:44 NotFound A nice addition, yeah.
17:44 moritz PerlJam: 1) being a pleasant HLL 2) offering low-level access to parrot features and 3) being light-weight
17:45 NotFound Obviously for me winxed does well the "pleasant" part ;)
17:45 whiteknight chromatic: the decision for them is already made. They're using their own toolset, including their own version of NQP. Even if we include a snapshot of the new NQP in the Parrot repo and release tarballs, they probably won't use that one
17:45 whiteknight they have their own versioning needs
17:45 chromatic Let's solve the problem; let's split NQP in two parts.
17:45 whiteknight rip out the compilerish stuff into a compiler library?
17:46 chromatic Yep.
17:46 whiteknight I like that idea very much, and it aligns nicely with some ideas I've been kicking around with plobsing
17:46 PerlJam whiteknight: a C-level library?
17:46 chromatic And Rakudo can customize the rest as Rakudo--and not the rest of HLLs--needs it.
17:46 chromatic That includes the cross-VM compatibility layer Rakudo wants.
17:46 whiteknight we can use that library to hold many compiler-related tools, tools for generating PBC, PMCs  for support compilation, etc
17:47 whiteknight chromatic: so that still leaves the question of what first-among-equals language we're going to keep in the Parrot repo for dogfooding
17:47 whiteknight is that the old-style NQP-RX?
17:48 chromatic Don't know yet.
17:48 chromatic We don't have to pick one today.
17:48 whiteknight In the long term, I would like a single language that we can use for writing all our tools AND implementing all our tests
17:48 whiteknight okay
17:49 whiteknight plobsing: what does ohm-eta output? does it output an AST? Can that be PAST?
17:50 plobsing whiteknight: ATM, it outputs winxed which must then be compiled separately.
17:51 plobsing however, it does "parse" winxed and generate an AST (modulo some cheats because it just gets output again), so it *could* produce PAST
17:53 plobsing and of course, users are left to build up whatever structure they want, no assumptions made. you can build up a PAST tree just like anything else.
17:57 chromatic Wow, ascii_scan is expensive.
17:58 whiteknight plobsing: okay. So that really becomes a pluggable frontend to this compiler library we're talking about
18:00 plobsing it is a suitable candidate, yes.
18:00 plobsing it still has some rough edges ATM (don't say I didn't warn you!)
18:01 plobsing chromatic: where are you seeing ascii_scan as a major contributor to runtime cost?
18:02 whiteknight plobsing: it certainly won't be the only front-end. We'll also have some flavor of NQP. Having multiple frontends will help us ensure that we make a nice library
18:02 chromatic plobsing, examples/benchmarks/stress_strings.pir
18:03 chromatic In that case, as the string comes directly from int_to_str, it's unavoidably ASCII-safe, so walking the string again and testing each character isn't useful.
18:06 plobsing whiteknight: that's a good thing. single-frontend would have a tendancy to pull the two parts closer when each is more general-purpose than the specific use-case.
18:07 chromatic Hah, we've halved the Coverity defects in the past 24 hours.
18:07 chromatic plobsing, removing STRING_scan() from the non-external case and testing that benchmark gives a 6.9% performance improvement.
18:07 plobsing chromatic: nice!
18:07 chromatic That's not necessarily the right approach, but it's informative.
18:08 plobsing I'd also be interested in using machine-word-sized checks in stead of per-character once we got aligned.
18:08 chromatic Maybe we need a flag which says "I know this data is encoding safe; don't check"
18:10 whiteknight plobsing: see also, IMCC
18:10 plobsing my thought exactly. I do not want that to happen again.
18:14 whiteknight so we produce a library that takes PAST, optimizes, creates POST, does whatever, then outputs PBC
18:14 whiteknight in addition to some helper routines to generate PAST in the first place, if needed
18:16 whiteknight plobsing: that works very nicely with what we were talking about a while ago, with moving many of the PackFile methods which are only useful for compilers into a separate library
18:16 whiteknight this is that library
18:17 dukeleto ~~
18:26 plobsing left #parrot
18:37 chromatic Hm, CUR_CTX is declared in every ops function, but not used in all of them.
18:37 whiteknight yeah, the source of many unused variable warnings
18:38 chromatic It's be nice to emit that code conditionally.
18:39 dalek winxed: r757 | NotFound++ | trunk/winxed (2 files):
18:39 dalek winxed: add option --nowarn to stage 1 and non installable driver
18:39 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=757
18:50 dalek winxed: r758 | NotFound++ | trunk/winxed_installed.winxed:
18:50 dalek winxed: add option --nowarn to installable driver
18:50 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=758
18:53 plobsing joined #parrot
18:56 dalek winxed: r759 | NotFound++ | trunk/ (3 files):
18:56 dalek winxed: update installable files
18:56 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=759
19:04 bubaflub joined #parrot
19:21 bubaflub left #parrot
19:23 wknight-phone joined #parrot
19:25 plobsing left #parrot
19:26 bacek ~~
19:26 bacek Good morning, humans.
19:27 dukeleto bacek: greetings, meatbag
19:27 wknight-phone left #parrot
19:29 bacek dukeleto, ignore algorithm in gc_gms.c. It's way too complex. I can design simpler (and better) one.
19:29 plobsing joined #parrot
19:30 cotto_work bacek++
19:32 whiteknight bacek: when I'm done my IMCC work, I'm on GC 100%
19:32 bacek whiteknight, I need couple of days to finalize design in my head.
19:32 whiteknight bacek: so let me know what you want me to do, what algorithm to follow, etc
19:32 whiteknight okay
19:33 whiteknight it's become enough of a priority that I want to focus on it
19:33 whiteknight so just tell me what you need
19:36 bacek whiteknight, nothing yet. Give me couple of days :)
19:38 dukeleto bacek: i like simpler and better
19:41 whiteknight bacek:okay, no rush. It will take me a few days to finish up IMCC
19:46 whiteknight maybe more, if packfiles are more fragile than I anticipated
19:46 dalek Heuristic branch merge: pushed 600 commits to parrot/generational_gc by bacek
19:47 dukeleto good lord
19:51 whiteknight that's nothing. back in my day we had to push 600 commits up hill both ways
19:52 chromatic and merge them by hand
19:53 dalek winxed: r760 | NotFound++ | trunk/winxedst1.winxed:
19:53 dalek winxed: syntax :label in pirop statements in stage 1
19:53 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=760
19:54 NotFound plobsing: ping
19:55 bacek chromatic, 6 conflicts in total to merge 4 month old branch. Not too bad :)
19:58 plobsing NotFound: pong
19:58 NotFound plobsing: ${ goto :label };
19:58 plobsing saw that, nice. NotFound++ on turnaround.
20:12 bacek plobsing, how hard will be to implement such syntax in imcc and deprecate old one?
20:17 bacek plobsing, and "bare function names"? As in foo() vs "foo"()
20:17 plobsing bacek: to implement, not hard. to deprecate... talk to pmichad and get back to me.
20:18 bacek plobsing, I can change PCT to emit new labels syntax. Not a big deal.
20:24 perlite left #parrot
20:25 perlite joined #parrot
20:54 plobsing left #parrot
20:55 bubaflub joined #parrot
20:57 plobsing joined #parrot
21:00 fperrad left #parrot
21:03 dalek winxed: r761 | NotFound++ | trunk/winxedst1.winxed:
21:03 dalek winxed: fix emit helper methods that were losing annotations
21:03 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=761
21:08 AzureStone left #parrot
21:11 Hackbinary left #parrot
21:11 AzureStone joined #parrot
21:11 cotto_work dukeleto: ping
21:12 dukeleto cotto_work: pong
21:12 cotto_work dukeleto: you mentioned something about not using doodle to figure out the concall schedule.  What did you mean?
21:14 dukeleto cotto_work: just work backwards from the person who has the strictest time commitments
21:14 dukeleto cotto_work: which i assume is kid51
21:15 dukeleto cotto_work: feel free to use doodle
21:15 dukeleto cotto_work: it might be easier
21:15 cotto_work gothca
21:15 dukeleto cotto_work: do you have a day in mind?
21:15 cotto_work none yet
21:17 whiteknight dukeleto: I've got an android now, and am probably going to want to put parrot on it eventually
21:18 Tene chromatic: your latest post on modernperlbooks does not have the described error in the quoted code, afaict.  Looks like they updated the code in response to comments between when you read it and when you copied it for the post?
21:19 sheant joined #parrot
21:19 cotto_work dukeleto: I wanted to figure out what you were talking about before sending anything out.
21:20 bluescreen left #parrot
21:21 cotto_work seen kid51
21:21 clunker3 kid51 was last seen on #parrot 21 hours, 21 minutes and 56 seconds ago, saying: "... we may increase of efforts in this area."  s/of/our/
21:21 aloha kid51 was last seen in #parrot 9 hours 43 mins ago joining the channel.
21:21 plobsing clunker3?
21:21 clunker3 was kicked by cotto_work: clunker3
21:22 Hackbinary joined #parrot
21:22 pmichaud 18:14 <whiteknight> so we produce a library that takes PAST, optimizes, creates POST, does whatever, then outputs PBC
21:22 cotto_work I don't see any clunker3
21:22 pmichaud part of the question then becomes, what is that library written in?
21:22 chromatic Tene, they did. I should update the post to reflect that.
21:22 pmichaud The status quo has it that the library is written in PIR.  We're moving away from that in nqp because we find the PIR difficult to maintain.
21:22 whiteknight pmichaud: well, that "library" already mostly exists as the backend to NQP. So we can keep it in PIR
21:23 pmichaud it's also a bit of a question as to what object metamodel that library uses
21:23 Tene chromatic: afaict, the code quoted in your post does not contain the sql injection bug that the original post had at first.
21:23 pmichaud the only other reason we're doing our own PAST is that we need it to be using the new metamodel asap.
21:23 whiteknight pmichaud: the maintainability angle is a little different for Parrot-ish utilities in the Parrot repo maintained by Parrot devs
21:23 Tene So the version you copied doesn't have the error either.
21:23 pmichaud whiteknight: I understand that fully.
21:23 whiteknight pmichaud: I imagine things would be very different for external developers. I wouldn't recommend you or your team use PIR
21:24 pmichaud I think experience has shown us that even Parrot-only developers struggle with writing significant toolsets in PIR
21:24 whiteknight pmichaud: We don't know yet what our ultimate lingua franca for Parrot tools, utilities, and libraries is yet
21:24 whiteknight pmichaud: right. We don't want it in PIR because we love PIR. That's what it is now and that's the path of least resistance
21:24 pmichaud whiteknight: agreed, and I don't think that has to be decided immediately (as chromatic indicated)
21:24 whiteknight we are going to have to come up with a better language over time
21:24 pmichaud but I don't think we have to exclude NQP as a possibility either
21:25 chromatic I'd like to keep most of NQP as a possibility.
21:25 whiteknight no, I don't think so either. the problem is that we need a language that we can use in the Parrot repo that is 100% adapted for use with Parrot
21:25 pmichaud what does 100% adapted mean in this sentence?
21:25 pmichaud that seems to be a very vague notion
21:25 whiteknight I like NQP, but it currently has the conflicting needs of needing to be useful for Parrot, and also needing to be faithful perl6 syntax and be useful to Rakudo
21:25 pmichaud I don't see those as huge conflicts
21:26 whiteknight what I mean is that we need it to be able to expose 100% of the capabilities of the VM
21:26 pmichaud we can do that, especially if we don't have to generate PIR
21:26 whiteknight like I said, I'm not against NQP
21:26 whiteknight what I don't want is to be relying on a language implementation which is beholden to other, possibly conflicting interests
21:27 pmichaud in other words, Parrot has to "own" whatever language it uses?
21:27 chromatic More like Parrot has to be responsible for whichever languages it provides.
21:28 whiteknight I think so, ultimately. I don't mean that in a xenophobic sense, or in the sense that it must be "invented here"
21:28 pmichaud provides?  or uses?  they're aren't exactly the same.  :-)
21:28 pmichaud for example, Parrot uses C but doesn't provide it.  :)
21:28 cotto_work thank goodness
21:28 pmichaud I grant that we might expect "use" plus "provide"
21:28 whiteknight If we're talking about the lowest-level human-writable interface language to the VM, it's going to need to track changes to the VM much more closely than higher-level languages will
21:29 chromatic Provides is the right word; think of PIR.
21:29 pmichaud unless the higher-level language is easily extensible to support the low-level features
21:29 whiteknight in my ultimate vision for future parrot, PIR doesn't really exist anymore. We have Lorito-ish PBC and something higher level that humans write
21:29 Tene There have been times where NQP hasn't easily provided capabilities that parrot supported through PIR.
21:29 Tene Some sub attributes, iirc.
21:29 pmichaud Agreed fully.  (more)
21:29 whiteknight think about C, how developres write C and never ever write asembly. That's what I'm thinking about for our future core language
21:29 pmichaud the reason for that is that providing those would require significant changes to PAST
21:29 pmichaud and POST
21:30 pmichaud and nobody undertook the tuits to provide them
21:30 whiteknight anyway, I have to pack up and leave now. I'll backscroll when I get home.
21:30 pmichaud that's not really a criticism of NQP as much as it is the entire toolchain
21:30 PerlJam whiteknight: you want to use C for Parrot's core language?  ;->
21:30 whiteknight left #parrot
21:30 plobsing left #parrot
21:31 chromatic I think Parrot needs to provide a full-stack PCT with one good language as a default, but pluggable choice.
21:31 pmichaud nqp-rx has already added things like vtable support and :multi support.  There's little reason why the same can't be done in the new nqp.
21:31 * Tene nods.
21:31 chromatic If that language is NQPNG, fine.  Winxed? Fine. PIR++? Fine.
21:32 pmichaud I think we're in agreement.  I'm just bugged by comments that "the new nqp is automatically at a disadvantage because it's serving Rakudo's needs."
21:32 chromatic Yes, that's unfair.
21:32 chromatic Provided....
21:33 chromatic ... that the support burden of features that belong to Rakudo, not Parrot, and vice versa go to the appropriate places.
21:33 pmichaud absolutely
21:33 pmichaud that's part of what the new nqp is trying to tease out
21:33 pmichaud because it's been too hard to do them in either rakudo or Parrot
21:33 pmichaud rakudo is too big, and parrot has non-rakudo goals
21:33 pmichaud there needed to be an intermediate place to do things
21:34 pmichaud we need to temporarily move part of the pct stack into nqp so we can rapid develop, and then we hope that the pct stack can move back down in to parrot as it solidifies
21:34 chromatic I'm all for that, as long as the right features really do move into Parrot this time.
21:34 pmichaud if people think that the existing nqp-rx model has worked reasonably well, then I don't see why we can't do something similar with the new nqp
21:35 pmichaud and because the new nqp will be much better structured for pragmas and the like, it should be much more possible to provide access to Parrot-low-level features
21:35 pmichaud i.e.,  "use Parrot;'  at the top of an nqp program opens all of the parrot-specific stuff
21:35 cotto_work pmichaud: I'm really glad to hear that.
21:36 cotto_work My impression was that it'd be harder to access VM-specific features.
21:36 pmichaud I had thought perhaps so initially as well, but the more I think about it, the more I think it may in fact be far simpler
21:36 Tene I agree about simpler, fwiw.
21:38 jnthn It's easy enough to switch into a subclassed grammar/actions with the VM specific features as the result of a pragma.
21:38 jnthn Probably provides a very neat way to handle it.
21:38 plobsing joined #parrot
21:38 cotto_work I like where this is going.
21:39 chromatic An extensible NQP, with Parrot absorbing it but Rakudo providing its language- or project-specific extensions?
21:40 jnthn ...Parrot absorbing NQP?
21:40 jnthn But yes, Rakudo specific bits would live in Rakudo.
21:41 chromatic Parrot has to provide some sort of PCT.
21:43 jnthn *nod*
21:43 chromatic If NQP-rx has a looming end of life, we should think about replacing it.
21:44 pmichaud well, nqp-rx doesn't have to die anytime soon.
21:44 pmichaud it exists, and can exists for as long as parrot (or anyone else) wants it to exist
21:44 chromatic If it's not getting new features and if NQPNG is (and they're compellingly better), let's make an argument for deprecation.
21:45 pmichaud I agree, deprecation is the likely outcome.  but I think we're a couple of months early for that decision
21:46 pmichaud but I don't know about "Parrot absorbing NQP" in entirety.  NQP still wants some multiplatform ability, which means toolkits for other vms (or a shared toolkit with vm backends).  (more)
21:47 pmichaud it ought to be fairly straight forward to develop parrot-specific sources of nqp that can be placed in ext/, just as we do now.
21:47 pmichaud s/develop/generate/
21:47 jnthn pmichaud: Yes, that's what I think is best.
21:47 jnthn pmichaud: I'd not want to have multiple "master" copies of e.g. PAST::Node and friends.
21:47 pmichaud I concede that there might be philosophical or strategic reasons why Parrot might not find that acceptable.
21:48 pmichaud I'm not asking for an answer anytime soon; just that we don't preclude possibilities prematurely either.
21:48 pmichaud and if parrot feels it needs to be working on a pct replacement in parallel with the nqp effort, that's probably okay too.
21:48 pmichaud (in case the nqp effort doesn't work out for parrot for whatever reason)
21:49 chromatic Out of tree development of NQP doesn't sit well with me.
21:50 pmichaud yes, I've surmised as much.
21:50 pmichaud I have difficulty understanding where Parrot sees its boundaries as being.  It wants to kick all of the hlls out of the repo, but own everything it does internally.  It just feels.... weird.
21:50 pmichaud It feels like Parrot never wants to take advantage of things created externally unless it can subsume them for itself.
21:51 chromatic Let's be more specific then.
21:51 jnthn What problems has nqp-rx living in a different repo created to date, ooc?
21:51 chromatic Remember how, when Perl 6 was in the repo, we could make changes in Parrot and fix problems in Perl 6 in the same commit?
21:51 pmichaud jnthn: the problem were experiencing now might be an example :)
21:51 jnthn pmichaud: :)
21:53 wknight-phone joined #parrot
21:53 * pmichaud waits to see if chromatic has more to say on his last statement.
21:53 dalek winxed: r762 | NotFound++ | trunk/winxedst1.winxed:
21:53 dalek winxed: fix do continue bug and optimize a bit the do ... while(false) case
21:53 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=762
21:53 Coke jnthn: having just fixed a bug in rakudo, it was fun to have to fix nqp-rx, then parrot, then rakudo, then roast.
21:54 Coke (i'm not saying that's a showstopper, it was just a small PITA)
21:54 pmichaud Coke: our new approach makes that much better... in the future you would only fix nqp and rakudo.
21:54 chromatic Now imagine that some features of Parrot we consider core to the tarball relied on external components which had support implications with regard to core changes.
21:55 pmichaud chromatic: I think this is ultimately inevitable.
21:55 pmichaud for any sufficiently advanced and distributed system, at least.
21:55 chromatic Dependency management?
21:55 rurban_ joined #parrot
21:55 cotto_work Would it be sane to keep the Parrot-specific layer of nqp in parrot.git?
21:55 pmichaud yes.
21:56 chromatic Dependency management is inevitable, but we don't have to borrow unnecessary trouble.
21:56 pmichaud especially if Parrot wants to have an idea of "pluggable anything".  At some point parrot is going to want to use one of those things that is pluggable, but that Parrot cannot "own".
21:56 pmichaud i.e., Parrot has a choice of not using it, forking it, or developing its own.
21:57 pmichaud (or figuring out how to manage the dependency)
21:57 chromatic I guess Rakudo has to answer that question then.
21:57 chromatic Is it better to share as much of NQP as possible with Parrot in tree or to develop NQP in a separate repository and not reuse what Parrot provides?
21:58 rurban left #parrot
21:58 rurban_ is now known as rurban
21:58 pmichaud unless of course the NQP in the separate repository reuses what Parrot provides, which is where I think we're heading.
21:58 chromatic I hope so, but it hasn't sounded like that in the past few minutes.
21:59 pmichaud oh.  then somewhere we're not communicating well.
21:59 Tene That's been my understanding, actually.
21:59 chromatic Ultimately, I'd like to see:
21:59 chromatic 1) prototyping of NQPNG in an external repository, until it's ready to consider
21:59 chromatic 2) migrating the Parrot-specific parts of NQPNG into Parrot, concurrent with
21:59 wknight-phone nqpng?
22:00 chromatic 3) migrating the Rakudo-specific parts of NQPNG where they best belong
22:00 pmichaud nqpng is chromatic's name for "new nqp"
22:00 dukeleto i think chromatic means the nom branch of nqp-rx, which is now called "NQP"
22:00 chromatic with the result of
22:00 wknight-phone ok
22:00 chromatic 4) Parrot provides a compiler toolkit that HLLs can use and customize where they see fit without modifying NQP as provided by Parrot
22:00 plobsing nqpng - because we can't get enough consonants
22:01 jnthn Yes, but the Parrot specific parts would not a coherent toolkit make, because there's so many parts that need not be Parrot specific.
22:02 wknight-phone nqprg: nqp really good
22:02 chromatic The Parrot specific parts are everything but the Rakudo-specific parts.
22:02 jnthn ...no.
22:02 pmichaud there's an nqp component in here somewhere.
22:02 pmichaud nqp still wants to be a language that others can use to write compilers other than Rakudo.
22:02 pmichaud it's not all just "Rakudo" and "Parrot".
22:03 chromatic That's why so much of it belongs as part of Parrot.
22:03 jnthn Well, furthermore, the PAST nodes aren't Parrot specific. The NQP grammar and actiosn likely aren't either. They certainly don't live in Rakudo though.
22:04 wknight-phone parrot will be providing a full compiler library
22:04 pmichaud I don't follow the "That's why so much of it belongs as part of Parrot"
22:04 pmichaud wknight-phone: the question is not whether parrot will provide a full compiler library, but whether parrot has to *own* the complete source to it
22:04 wknight-phone to
22:05 pmichaud I'm certain that parrot will provide a full compiler library.
22:05 chromatic I suppose I've been assuming that Rakudo isn't in the business of writing an abstraction toolkit for writing compilers with arbitrary backends.
22:05 pmichaud I'm equally certain that parrot will not ultimately own every library it provides.
22:05 wknight-phone to abstract a changing vm it should
22:05 wknight-phone no
22:05 pmichaud chromatic: I have a Rakudo hat and an NQP hat.
22:06 wknight-phone many libs in the repo should go
22:06 pmichaud Rakudo is in the business of providing the best Perl 6 compiler it can.  NQP is in the business of providing a toolkit for writing compilers.
22:06 pmichaud and other libraries.
22:07 PerlJam From my perspective the "ownership" issue really seems to be about efficiency.  Some people believe it would be more efficient if things were all in the same repo
22:07 pmichaud PerlJam: no.
22:07 chromatic It's not about efficiency for me.
22:07 pmichaud I think the ownership issue is about security
22:07 chromatic It's about costs and benefits and allocating resources.
22:07 pmichaud not security in the "cannot be broken into" sense, but security in the sense of long-term support
22:08 pmichaud Parrot doesn't want to place itself in the position of depending on a component that it cannot control.
22:08 wknight-phone parrot needs a low level language to call its.own
22:08 wknight-phone somethingto.replace pir
22:08 Tene If NQP ends up making changes that actually do conflict with parrot, parrot can certainly fork.
22:08 pmichaud wknight-phone: more precisely, I think what you're saying is "parrot needs a low level language to call its own and that is used to write the compiler toolkit and that compiler writers use to build their compilers"
22:09 wknight-phone no
22:09 Tene It's open-source; it's not like anyone could force changes into parrot or take away nqp, even if anyone wanted to.
22:09 chromatic Parrot needs to provide a compiler toolkit.
22:09 pmichaud then the low-level language that parrot calls its own doesn't seem to be integral to the current topic (as I understand it)
22:09 wknight-phone to write things that we provide in parrot.git
22:10 pmichaud if parrot.git provides a compiler toolkit (as chromatic just said), then what language will it be written in?
22:10 chromatic A language maintained in parrot.git.
22:10 wknight-phone yes. but not the Lang needed to call that library
22:11 pmichaud which is what I said wknight-phone was saying, I think.
22:11 wknight-phone write your compiler in fortran
22:11 PerlJam chromatic: so ... why exactly?
22:12 plobsing wknight-phone: are you offering to write parrot-to-fortran bindings?
22:12 pmichaud if parrot feels that its toolkit and the language used to write that toolkit absolutely must live in parrot.git, then I think nqp (or at least the new implementation of it) is not the system you're looking for.
22:12 chromatic PerlJam, see my message to parrot-dev.
22:12 bubaflub left #parrot
22:12 pmichaud and we can likely leave it at that.
22:12 Tene pmichaud: Can you explain the precise motivations behind nqp having its own independent repo separate from parrot and rakudo?
22:13 chromatic Separate from Parrot, anyway.  Separate from Rakudo makes a lot of sense.
22:13 pmichaud because we want rakudo to be able to run on multiple backends
22:13 wknight-phone have to go
22:13 pmichaud rather than put the multi-backend code into rakudo, it makes sense to put it into nqp
22:13 wknight-phone left #parrot
22:13 pmichaud I'm pretty sure it doesn't make sense to have the multi-backend features in parrot :)
22:14 chromatic Not at all.
22:14 pmichaud I also think nqp has value in its own right, as a language for writing other compilers
22:14 Tene pmichaud: 1) Why would it not make sense in the rakudo repo? 2) I certainly think it could make sense.  We've had the reverse included, bytecode translators.  I can certainly see it as potentially aiding parrot adoption.
22:14 * Tene nods.
22:14 pmichaud Tene: because Rakudo is too heavyweight for other compiler authors to use
22:15 pmichaud if I'm writing an APL compiler, I don't want the whole Perl 6 runtime
22:15 * Tene nods.
22:15 pmichaud I just want those powerful parts of Perl 6 that help me to write a compiler
22:16 pmichaud this has always been pge and nqp's premise... that it makes sense to extract certain parts of Perl 6 out for specific purposes
22:17 Tene My preference, fwiw, is to continue importing from nqp, or even set it up as a git submodule now that we've migrated to git.
22:17 PerlJam Tene: the new nqp or nqp-rx?
22:18 Tene PerlJam: I'd like to see new nqp be used in Parrot.
22:18 chromatic pmichaud, is the vision for the new NQP then to be a platform-agnostic language used for writing platform-agnostic compilers?
22:18 pmichaud platform-agnostic is too strong
22:18 pmichaud multiplatform is more precise
22:18 chromatic multi-backend?
22:19 pmichaud yeah, multi-backend.  I'd like to expose features of the backend
22:19 pmichaud which makes for non-portable code if you use them, but that's okay
22:19 pmichaud Perl 6 has the same issue as well -- we'd like Perl 6 to be able to access specific capabilities of its backends
22:19 pmichaud without having to adopt all of them into the language itself
22:20 Tene chromatic: What's a potential failure mode of using NQP in parrot that you're concerned about?
22:20 pmichaud one failure mode is "resistance to Perl syntax"
22:21 Tene Something like "I want to add functionality to Parrot, but I run into political issues trying to add that functionality to NQP"?
22:21 chromatic An imported NQP that depends on other backends adds friction to making useful/necessary changes to support features in Parrot.
22:21 chromatic I assume, of course, that platform equity is something useful.
22:21 chromatic or desirable
22:21 Tene "platform equity"?
22:22 pmichaud i.e., since platform X can't support Y, we can't allow nqp-parrot to support Y.
22:22 chromatic If NQP is a multi-backend language, the desire is for it to run in about the same fashion on all backends.
22:22 Tene Or, alternately, "Adding support for X to nqp for parrot would also require adding X support for all other backends"?
22:22 pmichaud I think we can mitigate that, but chromatic may be correct that it adds friction.  I think the friction will be small enough to tolerate, but I admit that speculation.
22:23 chromatic More like "NQP expects a specific interface from its backend" and that dictates what kind of features Parrot can provide it.
22:23 pmichaud Tene: or even "adding support for Y to nqp for parrot has to wait until we can support it in X backend"
22:23 chromatic or how it can provide them
22:23 pmichaud chromatic: I disagree wholeheartedly with this last statement
22:23 pmichaud NQP's philosophy has always been to adapt to what the vm provides, not to impose itself on them
22:23 Tene chromatic: given that nqp is targetting VMs that it has no control or influence over, that seems... unlikely.
22:24 chromatic NQP isn't a multi-platform language right now, so none of us have evidence for our suggestions.
22:24 pmichaud except that I think nqp will utterly fail if we start expecing clr or jvm to meet our needs
22:24 pmichaud and I don't have any intention of dumping the problems all on parrot as a result
22:24 pmichaud that's not... success.
22:25 chromatic Abstractions aren't free.
22:25 pmichaud no, but they often provide benefits that far outweight the costs
22:25 pmichaud *outweigh
22:25 PerlJam That's one of those things that make me think "efficiency" is a concern.
22:26 pmichaud PerlJam: I have several answers to that
22:26 pmichaud 1.  I'm trying not to prematurely optimize here
22:26 pmichaud 2.  Our current approaches to efficiency haven't been working all that well, so we need some bigger changes
22:27 pmichaud 3.  Some companies have been very successful in assuming that computing capabilities eventually swamp efficiency concerns
22:28 pmichaud 4.  What we think of as efficient today may change in a disruptive technology environment (as Perl 6 certainly aims to be)
22:29 PerlJam I'm also thinking in terms of  "ability to get things done without having to communicate up/down the toolchain when parts of it lead separate lives" as efficiency too
22:30 pmichaud again, I think that's the reality of computing in the modern era
22:30 PerlJam keeping release schedules in sync,  keeping APIs in sync, etc.
22:30 chromatic That's the efficiency concern I have.
22:30 pmichaud I think that communicating up and down toolchains and component streams is a fundamental part of a thriving ecosystem.
22:30 chromatic I think don't borrow trouble.
22:31 pmichaud There's a reason that many manufacturers outsource their component development :-)
22:31 pmichaud it's more efficient that way, and it allows teams to focus on what's important
22:31 pmichaud that said, don't outsource your core competency
22:31 chromatic Sure, but if you outsource what should be your core competence, you're named Carly Fiorinia and I used to work for her.
22:31 chromatic Fiorina
22:31 pmichaud yes, we're in agreement
22:32 chromatic Providing a compiler toolkit should be a core goal of Parrot.
22:32 chromatic Part of that compiler toolkit should be one good language in which to write compilers.
22:32 PerlJam the toolkit isn't the language though
22:33 pmichaud I see that Parrot can either invent its own compiler language then, or borrow Perl 6.
22:33 chromatic Handing someone a Parrot tarball and telling them to bootstrap the language in which to write their compiler isn't going to work.
22:33 pmichaud NQP has been predicated on the "it's better to borrow Perl 6" concept.
22:33 PerlJam chromatic: no, but you can provide the already-bootstrapped language though
22:34 pmichaud afk for a few minutes -- pickup kid from school
22:34 chromatic If absolutely none of the new NQP can ever live primarily in parrot.git, then we have our answer.
22:35 Tene Explain "primarily"?
22:35 aloha positive: nothing; negative: nothing; overall: 0.
22:36 Tene Thank you, aloha. :P
22:36 chromatic If we're importing generated code from another repository into parrot.git as we do with nqp-rx now, for example.
22:42 Tene So Parrot is going to reimplement PCT and start work on a new language?  Is this really the time for that anyway?
22:43 chromatic I don't think we have a choice.
22:43 pmichaud as in, importing code from another repo will never be acceptable?  Okay.
22:43 Tene Why is it not a choice to import code from nqp like we're currently doing with nqp-rx?
22:43 chromatic Too much technical risk.
22:43 Tene I mean, it's obviously an option as we're *currently doing it*.
22:44 chromatic nqp-rx isn't a project with a strong multi-backend goal.
22:47 chromatic I believe that outsourcing the technical decisions of a core component to another project would be a mistake, especially when those technical decisions necessarily depend on supporting some common substrate of Parrot and competing projects.
22:48 cotto_work Let me try to enumerate the issues here.
22:48 cotto_work 1 - we need something that can be tightly coupled to the VM to take advantage of of VM-specific features
22:48 Tene Please feel free to tell me that I shouldn't have much of a say since I haven't been doing any work myself, and maybe I'm being overly optimistic, but I'd rather wait to see if there actually are problems and try to work them out with cooperative people who also want Parrot to succeed, and take advantage of good tools we've been contributing to and investing in, rather than ignoring nqp and diverting effort from improving our other broken ...
22:48 cotto_work 2 - We want a low time between implementing the VM feature (or deprecating) and having it be accessible in the language.
22:48 Tene ... infrastructure.
22:48 cotto_work 3 - we want something where if there's instability, it's our fault and we can fix it rather than being dependent on an external project
22:48 chromatic And, if it manages to avoid the common substrate problem by tying itself deeply into Parrot, then we have the trouble of supporting a project tied closely to Parrot in some senses that's out of the repository and has its own support and deprecation and release cycles.
22:48 KaeseEs (sorry to interrupt) anyone know the printf format specifier for UHUGEINTVAL off the top of their head?
22:48 cotto_work Is that close?
22:48 chromatic Exactly those, cotto_work.
22:49 pmichaud I like cotto's summary.  Very clear.
22:50 pmichaud ooc, would parrot follow the same logic in not outsourcing, say, jit capabilities?
22:50 cotto_work ok.  So what if nqp made the VM-specific layer a separate component with a simple stable interface?
22:50 pmichaud or a GC engine?
22:50 chromatic That was my suggestion, cotto_work.
22:51 * cotto_work re-reads
22:51 chromatic pmichaud, outsourcing a GC is probably intractable for performance reasons.
22:51 chromatic JIT less so.
22:51 pmichaud but the point is one of instability and dependence on another project
22:51 cotto_work in-sourcing the JIT is difficult, if not intractible
22:52 pmichaud I'm just curious if there's any difference, and if so, what it is
22:52 chromatic You can run, and pretty well, without a JIT.
22:53 chromatic Shipping a compiler for which you have to hand-assemble code isn't that useful.
22:55 pmichaud ICU?  Or is that deemed "not unstable"?
22:56 dalek winxed: r763 | NotFound++ | trunk/winxedst1.winxed:
22:56 dalek winxed: improve detection of empty statements
22:56 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=763
22:57 pmichaud I'll need to run soon... so perhaps this can be continued later if it needs to be.
23:00 Tene "for which you have to hand-assemble code" is rather hyperbole.  It's not like NQP would suddenly go away.  In the absolute worst case, Parrot could just for NQP.
23:00 Tene fork.
23:02 Tene The friction we've seen with out-of-project nqp-rx has been pretty low, IME.  I see no reason to expect it to be higher with NQP.
23:03 cotto_work Tene: I tend to agree and suspect that it's because of how pir:: et al made it easy to get at Parrot's implementation details directly.
23:04 Tene re specific points, I don't expect NQP to be a problem.  1) NQP *wants* to provide tight coupling to a VM and allow taking advantage of VM-specific features.
23:05 Tene 2) I haven't seen any particular delays in getting VM features in nqp-rx, and see no reason to expect it to be different for nqp.
23:05 Tene More often it's been the other way around, nqp being blocked by parrot deprecation policy.
23:07 Tene 3) I don't see any reason to believe that we'd be less competent working on nqp than we'd be on some other hypothetical language, or that there'd be resistance from nqp.  nqp *also* wants to avoid instability and to run well on Parrot.
23:08 Tene Now, that's mostly about my ignorance, which very well may just be a failure of imagination on my part.
23:08 Tene It does seem very low risk compared to the benefits of having a good language right now.
23:10 chromatic nqp-rx isn't a project with a strong multi-backend goal.
23:10 Themeruta joined #parrot
23:10 Themeruta is now known as NotFound_b
23:13 chromatic The new NQP is.
23:13 chromatic That'll change the design decisions.
23:15 chromatic To my knowledge, no substantial program implemented in nqp-rx runs on any other backend right now.
23:16 chromatic Thus I believe that NQP's design and implementation will necessarily change in ways we can't predict right now as part of the goal of supporting multiple backends.
23:16 chromatic Parrot may have to adapt to that,.
23:16 Tene "can't predict the details of" doesn't mean that we can't have any expectations at all.
23:17 chromatic I don't want to overstate my expectation that things will change dramatically.
23:17 chromatic or at least unpredictably
23:17 pmichaud 23:05 <Tene> 2) I haven't seen any particular delays in getting VM features in nqp-rx, and see no reason to expect it to be different for nqp.
23:17 pmichaud to provide a counter example, there have been times when features have been considered for Parrot (or implemented in Parrot) that nqp couldn't/didn't take advantage of
23:18 pmichaud however, that has been more of an issue because of limitations of PAST/POST, and not nqp itself.  I suspect that having past/post in an hll source (e.g., nqp) would've made such changes much easier instead of foregone
23:19 pmichaud also, I should not that nqp-rx has always had a multibackend goal.
23:19 pmichaud *note
23:19 pmichaud the new nqp is the first place where we're starting to act on it.  But ever since November 2009, nqp-rx has had multiple backends as an eventual goal.
23:20 pmichaud that's not new.
23:20 Tene pmichaud: is it currently a goal of yours that nqp will be able to provide Parrot with what it needs, be able to expose parrot-specific features well, etc?
23:20 pmichaud absolutely.  I think nqp users will demand that.
23:20 pmichaud I know that Rakudo will.
23:21 Tene If Parrot runs into problems because of changes in NQP's design and implementation, would you consider that a failure of NQP that needs to be addressed?
23:22 pmichaud Yes.
23:22 pmichaud However, I conceive there might be differences of opinion about what constitutes a "problem".
23:22 pmichaud However, we did manage to accommodate Parrot multisubs and :vtable definitions in the new nqp.
23:22 zby_home left #parrot
23:22 pmichaud sorry
23:22 Tene If support for other backends interfered with good support with Parrot, would that be considered a failure of NQP's design, or at least not meeting NQP's goals?
23:22 pmichaud in nqp-rx
23:23 pmichaud not meeting nqp's goals, definitely.
23:24 pmichaud it might imply failure of design, or even that the goals are too lofty and not realistically achievable.  in which case we'd have to make a choice, or (more likely) fork nqp.
23:24 chromatic Fork NQP how?
23:24 bluescreen joined #parrot
23:25 pmichaud into a very parrot-specific version, and one that is focused on multibackend.  But I don't believe it has to be either/or at this point.
23:25 pmichaud I don't believe such a fork is likely.  And if one occurs, I think both branches of the fork (and Parrot) will have benefitted greatly from the shared efforts leading up to the fork.
23:26 pmichaud we're already seeing that to be the case in the new nqp, where jnthn++'s experiments in 6model on clr made for huge improvements in the parrot implementation of it
23:27 Tene It seems to me that the failure case of "We discover that working with out-of-repo nqp turns out to be horrible" is that we can just fork nqp, and that wouldn't actually be that bad.
23:27 pmichaud I certainly think that if Parrot decides it needs its own internal language, it will be easier to create it from nqp (no -rx) than from nqp-rx or PIR.
23:27 chromatic Merely a waste of time and resources leading up to that point.
23:28 pmichaud I disagree with that, strongly.
23:28 pmichaud I know that it was much easier to create NQP from pge than it would've have been to create it from PIR.
23:28 pmichaud sorry, nqp-rx from pge
23:28 chromatic I was responding to Tene, not pmichaud.
23:28 pmichaud oh, sorry.
23:29 pmichaud but I still disagree with that.  I don't think it would be that bad.
23:29 pmichaud or a waste.
23:29 Tene pmichaud and jnthn are going to be working on nqp *anyway*, and any work done on Parrot to support that I rather expect to be aligned with Parrot's goals.
23:29 bacek_at_work ~~
23:29 Tene Who's going to be wasting effort there?
23:29 Tene Ah, whatever the trouble is leading up to the decision.
23:30 pmichaud Tene: well, wasted effort might be from people who write parrot tools in nqp (e.g., ops2c), only to have to rewrite them in something else later.
23:30 chromatic and whatever changes have to be backed out to do things right.
23:30 bacek_at_work Jusy my $0.02.
23:30 whiteknight joined #parrot
23:30 plobsing left #parrot
23:30 bacek_at_work We can have newPCT (or whatever) imported into parrot. Same as nqp-rx now.
23:31 bacek_at_work POST::Compiler will able to generate bytecode directly.
23:31 bacek_at_work (It can now already)
23:31 pmichaud bacek_at_work: iiuc, chromatic is opposed to such an approach.
23:31 bacek_at_work VM-independent nqp will generate PAST.
23:31 bacek_at_work parrot-dependent PAST::Compiler.post() will generate parrot-specific POST.
23:32 bacek_at_work win-win from my point of view
23:32 chromatic I'm comfortable with that as long as we don't import external projects and redistribute them as PCT.
23:33 bacek_at_work POST can be implemented in nqp, nqp-rx, winxed, whatever. Metamodel of nqp/past/post can be different.
23:33 bacek_at_work chromatic, why?
23:33 pmichaud afk, errands
23:33 chromatic Because that would be silly.
23:33 chromatic That's very polite Russian, so translate accordingly.
23:34 bacek_at_work what is the difference between nqp, pct, ICU, libJIT and BoehmGC?
23:34 bacek_at_work And tree-optimizations from tcurtis
23:34 chromatic ICU, libJIT, and Boehm aren't projects actively developed simultaneously as consumers of core Parrot and producers of core Parrot.
23:34 bacek_at_work Than we have advantage here for nqp and pct
23:35 bacek_at_work Because it's developed by _us_.
23:35 chromatic Why aren't all of our PMCs developed as external projects and imported into our repository?
23:35 bacek_at_work sigh...
23:35 bacek_at_work Let's use git submodules if it will solve concerns.
23:35 dukeleto chromatic: what are you trying to get at?
23:36 bacek_at_work Or "better plumage"
23:36 chromatic Importing NQP snapshots from another repository is, as I see it, a mistake.
23:36 dukeleto chromatic: let's take a concrete example: parrot/yaml-tiny
23:36 chromatic NQP should be produced as a core component of Parrot within parrot.git.
23:36 bacek_at_work chromatic, yeah...
23:36 bacek_at_work in last 2 years we are trying to reduce maintained codebase.
23:37 chromatic By focusing on core features.
23:37 bacek_at_work And you are proposing totally different approach.
23:37 chromatic If a compiler toolkit isn't a core feature, then it's a moot point.
23:37 plobsing joined #parrot
23:37 chromatic Is PAST a core feature? POST? PBC emitting? I believe so.
23:37 whiteknight I think it's certainly core
23:37 bacek_at_work PAST - no.
23:37 bacek_at_work POST - yes
23:37 bacek_at_work PIRATE doesn't use PAST at all for example.
23:38 chromatic That doesn't make PAST not a core feature.
23:38 bacek_at_work If any HLL (including nqp) can emit parrot's POST tree - we are golden.
23:38 bacek_at_work chromatic, is YAML::Tiny core feature?
23:38 chromatic I think not.
23:38 bacek_at_work is JSON::Parser core?
23:38 NotFound_b For me currently there is no problem with having any of that things external because I don't need to use it. But if PIR gets deprecated and the only canonical way of generating code is via PCT, I'll have a problem.
23:38 bacek_at_work LWP?
23:39 bacek_at_work Digest::MD5?
23:39 chromatic Nope.
23:39 bacek_at_work ls runtime/parrot/library/*pbc | wc -l
23:39 bacek_at_work 30
23:39 bacek_at_work which of them should _go_?
23:39 chromatic Anything we don't need to run plumage, I say.
23:39 bacek_at_work Test::More?
23:40 bacek_at_work LWP?
23:40 bacek_at_work Running plumage is matter of bootstrapping.
23:40 bacek_at_work Currently we are using PIR as bootstrapped code.
23:40 bacek_at_work If can have "portable PBC" we can use it.
23:40 chromatic Then let's evict everything we don't need to build Parrot, run tests, and bootstrap plumage.
23:41 bacek_at_work Or "some magical serialized pbc format"
23:41 bacek_at_work chromatic, why not?
23:41 chromatic I don't know what you're trying to prove.
23:42 whiteknight +1 from me on radical library eviction
23:42 NotFound_b bacek_at_work: cuurently I use PIR to generate code.
23:43 bacek_at_work NotFound_b, erm?
23:43 whiteknight NotFound_b: But there's no reason why it always has to be that way
23:43 bacek_at_work chromatic, point is: a lot of stuff can be bundled with parrot, not developed in same repo.
23:43 NotFound_b bacek_at_work: I can'r generate "portable PBC" from winxed.
23:43 whiteknight of course, PIR will probably always exist
23:44 bacek_at_work Either via plumage, import, git submodules, magical fairies, whatever.
23:44 bacek_at_work NotFound_b, there is no such thing as "portable PBC" now.
23:44 chromatic I think the use case for Parrot of "You can write a compiler easily!" relies rather more on the existence of a compiler toolkit than an HTTP library.
23:44 NotFound_b bacek_at_work: and there is no such thing as other way to generate PBCs as fast as PIR right now.
23:45 bacek_at_work NotFound_b, emitting PBC from newPOST tree is quite fast. Modulo speed of parrot it self.
23:46 bacek_at_work chromatic, I don't see any contradictions.
23:46 bacek_at_work If PCT is bundled with parrot.
23:46 NotFound_b bacek_at_work: As fast as winxed is now generating pir and compiling it?
23:47 whiteknight We absolutely need tools in Parrot to take AST, convert to POST and PBC
23:47 whiteknight and we need related tools (optimizers, register allocators, etc)
23:47 bacek_at_work NotFound_b, order of magnitude slower.
23:47 chromatic If I haven't convinced people by now that relying on the development of PCT outside of the Parrot repository is an unacceptable risk, I'm never going to.
23:47 whiteknight and we should probably provide tools for creating AST nodes, for people who don't do that themselves
23:47 whiteknight chromatic: I'm convinced
23:47 bacek_at_work whiteknight, checkout nqp_pct branch (or pirate), look at POST nodes. It's what we almost have now.
23:47 whiteknight we need all that crap in core
23:47 whiteknight bacek_at_work: I've seen it
23:48 whiteknight we need it, we need it in core
23:48 NotFound_b bacek_at_work: the PIR still has an echologic niche, IMO
23:48 chromatic *developed* in core
23:48 whiteknight yes. Developed in core
23:48 bacek_at_work Again...
23:48 bacek_at_work POST is parrot specific
23:48 bacek_at_work And can be developed inside core.
23:48 plobsing left #parrot
23:48 bacek_at_work PAST is language/vm/anything agnostic.
23:48 whiteknight Parrot is going to be changing a hell of a lot in the coming months. We're losing PIR as the standard. We're adding Lorito. We need tools that can track Parrot changes but provide a stable interface for usrs
23:48 whiteknight compiler libraries are fundamental
23:49 sheant left #parrot
23:49 NotFound_b A stable and reasonably fast.
23:49 bacek_at_work we can even bootstrap PAST.nqp into PAST.pir
23:49 bacek_at_work To keep it inside core.
23:51 bacek_at_work Let's draw it:
23:51 bacek_at_work 0. Lorito M0
23:51 bacek_at_work 1. Lorito M1
23:51 bacek_at_work 2. POST::Compiler with .pbc method
23:52 bacek_at_work 3. PAST::Compiler with .post method
23:52 bacek_at_work 4. "HLL which can generate PAST"
23:52 Tene So what were the reasons that nqp left the parrot repo originally?
23:52 chromatic To avoid Parrot's deprecation policy.
23:52 bacek_at_work Tene, development velocity
23:52 NotFound_b bacek_at_work: winxed is out of that graph.
23:52 bacek_at_work Where we should draw line between core vs non-core
23:53 whiteknight bacek_at_work: between 3 and 4
23:53 bacek_at_work NotFound_b, no. For winxed step 4 is "pirate". For now at least.
23:53 chromatic Between one good implementation of 4 and every other implementation.
23:55 NotFound_b bacek_at_work: I think that in that scheme pirate is at step 4, so winxed and anything using the same way will be in: 5. Intolerablily slow.
23:55 whiteknight we only need one language compiler in core. Some kind of low-level system language
23:56 whiteknight like PIR, plus syntax, minus the suck
23:56 chromatic Exactly.
23:56 chromatic People can plug and play parts of the PCT stack as they want, but they have one good option for every stage.
23:56 chromatic one good *default* option for every stage
23:57 whiteknight yes
23:57 chromatic and Parrot controls them for the sake of support, efficiency, deprecation, et cetera
23:57 whiteknight we need a low-level language which allows us to use and test the VM directly. Further up the stack, NQP and the compiler toolchain are the standard tools for building compilers
23:58 chromatic s/NQP/<something, perhaps NQP>/
23:59 NotFound_b whiteknight: and what method should that language use to generate PBCs? An API? An assembler?
23:59 whiteknight NotFound: For winxed, I think we're going to need to write a bytecode generating backend proper

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

Parrot | source cross referenced