Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot Developer Summit: 2200 UTC 29 Jan | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches
Set by moderator on 26 January 2011.
00:01 janus left
cotto mikehh, you can fix that. We want to keep the c++ build working. 00:04
mikehh cotto: done, just testing before commit 00:05
pmichaud kid51: thanks... fixed 00:09
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:10
I'll add a statement about that to try to make it clearer 00:12
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
I've been thinking of ways to access the underlying vm directly
we could still allow :multi and :vtable pragmas to be accessed, for instance
it's a bit too early to know what will and won't be possible
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
(i.e., the object model)
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
cotto From my understanding, it's pretty likely that we'll be adopting something like 6model.
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
s/to access/to access some/
moderator Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches 00:15
pmichaud and to avoid pmc boxing/unboxing 00:16
I've rewritten that section a bit: 00:19
(semi-long paste coming up)
"Our plan recognizes and fully understands that
Parrot may elect to neither provide nor support nqp directly in its
distributions, and may even migrate existing tools and libraries
completely away from the existing nqp-rx and PCT. Or, Parrot
might decide to embrace NQP more fully to take advantage of its
new optimization and compiler toolkit capabilities. We can likely
find ways to preserve the ability to access low-level Parrot features
for Parrot-specific libraries. (This becomes far more conceivable if
Parrot adopts the new object metamodel, which is the major impetus 00:20
behind these changes.) Whatever the Parrot team chooses to do in
this area, nqp will support as best it can within the goals and
plans described above.
"
does that sound more in the middle?
cotto pmichaud, that's much less scary. 00:21
thanks for clarifying
00:26 nwellnhof left
dalek rrot: a96b35d | bacek++ | src/runcore/main.c:
Fix c++ build
 00:27
00:27 NotFound joined
NotFound Hi 00:27
cotto hi NotFound 00:28
00:38 whiteknight left
Coke (instead of a tag called "old" in the old file, have a tag for "version it was removed in.") 00:50
bacek_at_work ... and date 00:51
dalek rrot: c2ffe55 | bacek++ | src/exceptions.c:
Explicitely cast enum to INTVAL to pacify c++ compiler.
rrot: 01bf2d8 | bacek++ | src/packfile/api.c:
Use size_t instead of INTVAL for iterating over keys.
rrot: 91d348b | bacek++ | src/hash.c:
Pacify c++ compiler by casting value to proper enum.
rrot: 6176f08 | bacek++ | src/pmc/imageiothaw.pmc:
Use explicit const_cast to pacify c++ compiler.
rrot: 0677041 | bacek++ | src/pmc/packfileannotations.pmc:
Pacify c++ compiler by casting to proper type.
KaeseEs are there any limits besides the hardware that i'd run into wrt. measuring relatively small time intervals (eg. 500 us)? 00:53
dalek nxed: r751 | NotFound++ | trunk/winxedst1.winxed:
operators '<<' and '>>' in stage 1
 00:58
KaeseEs i ask because i'm looking at writing a metronome-like collector to familiarize myself with the api 01:01
dalek rrot: 5d1baae | bacek++ | src/pmc/imageiothaw.pmc:
One more explicit const_cast to pacify c++ compiler.
 01:04
mikehh KaeseEs: have a look at t/pmc/timer.t for an example - probably not the best 01:06
KaeseEs thanks! 01:07
01:07 hudnix joined 01:13 jan joined
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:21
dalek rrot/tt1988_pmcemitter: 6d7aa32 | jkeenan++ | lib/Parrot/Pmc2c/PMC (2 files):
Move vtable() method from lib/Parrot/Pmc2c/PMCEmitter.pm to lib/Parrot/Pmc2c/PMC.pm.
 01:31
rrot: eaa0a9f | mikehh++ | src/pmc/imageiothaw.pmc:
fix cast so g++ builds
 01:47
rrot/tt1988_pmcemitter: d501954 | jkeenan++ | lib/Parrot/Pmc2c/PMC/RO.pm:
Remove unnecessary import of Parrot::Pmc2c::PMCEmitter.
 01:50
dukeleto ~~ 02:05
Coke getting warnings in the new *deprecated* tests. 02:08
dalek p-rx: ab1ffc0 | Coke++ | src/Regex/P6Regex/Grammar.pm:
Fix error message to match STD.
p-rx: 96e4b67 | Coke++ | src/stage0/ (3 files):
update bootstrap for " in Perl 6" error update.
rrot: ed1a4bc | Coke++ | docs/book/draft/appe_source_code.pod:
fix header level.
rrot: 814a916 | Coke++ | ext/nqp-rx/src/stage0/ (4 files):
pull in NQP changes for updated error message.
mikehh Coke: so do I 02:10
Hackbinary dumb questions, in npq is := a reference copy and not a value copy, yes? 02:27
*nqp
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:28
dalek rrot: 013436a | bacek++ | src/packfile/api.c:
Use explicit cast to pacify compiler.
 02:31
rrot: 8ddc501 | bacek++ | src/nci_test.c:
Split declaration and definition of exported vairables to pacify c++ compiler.
bacek_at_work Hackbinary, it's binding. Which is "reference copy"
parrot is build warnings free now (at least on Linux/i386)
Hackbinary thanks 02:33
dukeleto Hackbinary: what are you hacking on? 02:36
Hackbinary dukeleto: i'm trying to fix the unless statement in cardinal 02:37
dukeleto Hackbinary: awesome! 02:41
02:44 kid51 left
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
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. :)
Hackbinary =)
Tene, dukeleto: where should I be adjusting how expression is evaluated. 02:51
I'm trying to fix unless 0 which evaluates to false, but should be true, so the ruby unless else block is executed 02:52
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
Hackbinary: please note that cardinal uses Parrot Grammar Engine (PGE), not NQP 02:55
Hackbinary if 0 should evaluate to false
dukeleto Hackbinary: PGE is a predecessor of NQP
Hackbinary: i am also excited to see you working on it
Hackbinary unless 0 should evaluate to true
dukeleto Hackbinary: yes, i agree
Hackbinary: and feel free to email the parrot-dev list if you have questions 02:56
Hackbinary: many parrot devs are on parrot-dev but are rarely on IRC
Hackbinary so how I'm approaching the solution is putting the fix in the unless_stmt method in the actions.pm file 02:57
but I could be doing it wrong
pmichaud Hackbinary: that sounds very much correct
(as in, it would be the correct place for a fix)
Tene dukeleto: Cardinal *does* use nqp, it just doesn't use nqp's grammars. 03:01
sorear PGE and NQP used to be separate
Tene sorear: they still are
Hackbinary: No, that's very much not the right place for it.
sorear later versions of NQP incorporate parser-generator functionality
Tene Hackbinary: The right thing to do is fix the get_bool behaviour in cardinal's Integer class. 03:02
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.
dukeleto: No, that's not accurate either. It's using nqp-rx.
dukeleto Tene: so it uses nqp-rx, but not nqp-rx grammars ? 03:04
Tene dukeleto: That's right.
dukeleto Tene: is that because it is moving in the direction of nqp-rx grammars ?
Tene dukeleto: It's using nqp-rx because afaict old nqp isn't present in parrot any more.
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.
Tene: ok, i think tadzik was interested it in at some point
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.
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:06
so I was thinking that unless is a special case 03:07
Tene Hackbinary: Let me confirm something, because I'm not all that knowledgeable about ruby. 03:08
if I have: "unless 0 do ... end" or whatever, does the ... run?
Hackbinary run ruby on t/01-stmts.t
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
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
me
however, it handles 0 == 1 correctly
erm
sorear Who on the cardinal group is a ruby expert?
Tene sorear: treed
Hackbinary cardinal handles 0 == 1 correctly
because I tried adjusting the classes/integer get_bool behaviour, but then that broke if and 0 == 1 03:12
if that makes sense ;)
Tene Hackbinary: I don't see how that's relevant? 03:13
Hackbinary: 'unless' should have no special cases at all. The responsibility for evaluating truth belongs in the individual classes. 03:15
Hackbinary: That breaking 0 == 1 means that there's an error elsewhere as well 03:19
So really you should track down that error instead. 03:20
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'?
ah
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.
I've got the basics of a patch for you in just a minute. 03:22
pmichaud draft of "What Rakudo needs from Parrot in 2011" available at pmichaud.com/sandbox/rakpar.txt 03:31
comments and suggestions welcome; I'll send the "official message" to parrot-dev tonight or early tomorrow morning
Tene Haha, I managed to get it exactly backwards. 03:35
Hackbinary ;)
pmichaud that's common when dealing with "unless", I think. :) 03:36
Tene Hackbinary: The confounding bug is in src/builtins/cmp.pir 03:37
gist.github.com/07ae3cfeb8837ecfb424 is something close to right
Tene slight update
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:39
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
:)
Hackbinary alright cool .. thanks .. it's nearly 4 am here and I'm nackered
;)
pmichaud 4am... good hacking time. :)
Hackbinary I think there is something quirky about how ruby handles unless 0 03:41
or maybe not, it looks like that ruby if 0 is true 03:43
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
pmichaud, more work required for Annotations and Debug segments though
pmichaud bacek_at_work: right, and possibly some documentation about how to do it
and some sort of "official Parrot supported mechanism" for it 03:46
i.e., some designation that "Parrot officially supports these methods for creating .pbc"
Tene Hackbinary: No, nothing quirky, it's just that 0 is true
Hackbinary tene: okay thanks
bacek_at_work pmichaud, in bright shiny future - just emit "newPOST". POST::Compiler.pbc() will do all magic
Tene Hackbinary: in ruby, the only false things are false and nil, and that's it
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 :-)
bacek++
afk, errands
bacek_at_work pmichaud, major task - emit newPOST from PAST.
pmichaud well, PAST::Compiler is going to be rewritten in NQP... indeed, much of it has been, I think. 03:48
certainly the regex portions will be, too
bacek_at_work it's not about rewriting it into nqp.
Currently it emits about 4 types of POST nodes. 03:49
It will require much more. About 15 :)
pmichaud I'm guessing about 10.
And we'll also want a POST that can work for other vm's besides Parrot. :-)
bacek_at_work 12 actually 03:50
11. POST::Node is base class
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
bacek_at_work pmichaud, github.com/parrot/pir/tree/master/src/POST + all current POST nodes. 03:51
pmichaud I'm likely to disagree with Key 03:52
bacek_at_work pmichaud, why?
pmichaud because Key is quite Parrot specific.
bacek_at_work hmmm 03:53
What we can use for "Namespace identifier" instead?
pmichaud also, why is String separate from Constant, ooc?
bacek_at_work Constant can be PMC
String contains .encoding 03:54
(As we deprecated .charset)
But POST::String isa POST::Constant
pmichaud hmmm. PAST/POST always considered strings to be fundalmentally unicode
bacek_at_work yes, they are.
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
bacek_at_work And I'm not in mood to change parrot to have "single internal encoding for strings"
pmichaud POST could choose whatever encoding it wanted
bacek_at_work POST - yes. 03:56
But for compiling PIR I have to preserve it :)
pmichaud anyway, since you have 11 classes and I estimated about 10, I think we're overall in close agreement
just a few changes here and there
bacek_at_work of course
some polishing required.
pmichaud afk for errands for real this time :)
bbl
cotto ~~ 04:11
allison_, ping 04:12
dukeleto, ping 04:14
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:20
pmichaud, thanks for the list 04:37
Hackbinary tene: thanks, got it working =) ... I'm off to bed 04:38
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. 04:50
cotto The bright side of the profile wonkiness is that if there's a test case I can make sure it stays fixed. 05:00
well, a small test case 05:01
pmichaud plobsing: I didn't think that parrot;slurp would be "inclusive", though.
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
05:07 nopaste left
pmichaud I don't completely understand what you're saying (which is somewhat my original point) 05:08
05:09 TonyC left
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:09
pmichaud ...callgrind_annotate? What's that? 05:10
(I'm not intentionally playing dumb... this is the first I've ever heard of "callgrind_anotate")
plobsing callgrind_annotate is how I look at callgrind files, which is what pprof2cg generates 05:11
05:11 TonyC joined
pmichaud ah. pprof2cg says to use kcachegrind, iirc. 05:12
05:12 nopaste joined
pmichaud So that's what I've been using. 05:13
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
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
Coke aloha: msg bacek - "seen foo ?" should work the same as "seen foo?" 05:15
aloha Coke: OK. I'll deliver the message.
pmichaud using callgrind_annotate doesn't tell me what the numbers represent
plobsing they represent "counts", which are roughly instructions executed, although I'm not sure how exactly that maps to parrot. 05:16
bacek_at_work Coke, ok. 05:17
I suspect profiling runcore affected by misnumbering lines in IMCC
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?
bacek_at_work plobsing, hardcoded where?
plobsing .annotate 'line' 33
bacek_at_work I don't think that profiling runcore uses annotations 05:19
It's all about opcodes
plobsing so then it has nothing to do with line numbers. I fail to see any connection.
Tene Hackbinary: Great to hear it! Let me know when I can review a patch.
bacek_at_work plobsing, ok. "pir line number in generated files" 05:20
plobsing and that being miscounted is getting into the PBC how?
pmichaud does callgrind_annotate show me how many times each function was called? 05:22
that's pretty important to know 05:23
plobsing there's probably a way of getting that, but I've never needed it 05:25
looks like the --tree option does what you want 05:28
pmichaud maybe. it doesn't seem to be accurate 05:33
or I'm not understanding what it's saying. 05:34
cotto pmichaud, if you have ways that the profiling runcore could be more useful, please file a ticket or tell me. 05:45
pmichaud I may just expand with followups to parrot-dev. 05:46
cotto that's fine too
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
pmichaud so it's something we can all talk about and use without having to put together a lot of "setup"
the fact that the call graph doesn't seem to be represented accurately makes me a bit suspicious of the reported counts 05:49
afk, sleep 05:53
cotto 'night 05:54
05:55 rurban_ joined 05:58 rurban left, rurban_ is now known as rurban 07:04 snarkyboojum joined
dalek rrot: 1a28d8a | chromatic++ | lib/Parrot/Pmc2c/PCCMETHOD.pm:
[lib] Marked unused return value as UNUSED.

This should resolve several Coverity warnings such as CID #1279.		 07:11
rrot: 16ccd1d | chromatic++ | lib/Parrot/Pmc2c/PCCMETHOD.pm:
[lib] Avoided double-declaration of a PMC param.

This should close several Coverity reports, such as CID #1287. There's still a logical question in this code regarding the value of passing the PMC as a parameter to these functions, then immediately retrieving it from the call object, but that's a much larger change more worthwhile when we rewrite the PMC to C emitter.
rrot: 01fef9c | chromatic++ | src/gc/alloc_resources.c:
[GC] Simplified function for debug/non-debug cases.

The motivation for this change is to avoid a side effect in the assert, specifically PARROT_ASSERT(--count), reported by Coverity in CID #441. Rather than wrapping #ifdefs around the decrement, it seems clearer to extract the normal behavior of the loop for non-debugging builds and to provide an alternate version in the case of a debugging build.
bacek_at_work wow, first commit from chromatic in last 1.5 month! :) 07:18
Tene bacek_at_work: my recent commit to cardinal was my first in rather longer. 07:21
bacek_at_work Tene, welcome back :) 07:22
cotto ccache++ 07:27
dalek nxed: r752 | NotFound++ | trunk/winxedst1.winxed:
refactor some common parts of binary operators
 07:48
dukeleto Tene: glad to see cardinal getting some movement 07:50
cotto dukeleto, ping
dukeleto cotto: pong
cotto dukeleto, it seems like a good time to start a regular conference call between Parrot's various team leads.
do you think weekly would be feasible and helpful? 07:51
07:51 fperrad joined
dukeleto cotto: yes 07:51
cotto ok. I'll send something out to the team leads. 07:52
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
cotto the PDS made me think that we need to get on the ball there
dukeleto cotto: nah, i think with five people we can just talk about it
cotto also, I'm jazzed to have you and bacek helping with M0. 07:55
dukeleto cotto: it should be scary
cotto: i've bean meaning to tell bacek that we should port parrot internals to YAML...
because i hear he loves YAML 07:56
cotto +like a million
We can make yaml to parse yaml to parse yaml. That'll get us some enterprise users for sure. 07:57
dalek rrot: 368bb44 | chromatic++ | / (3 files):
[ops] Allowd args ops direct access to sig count.

Direct access through the FIA size macro speeds up these PCC hot path ops measurably, giving a 1.9% performance improvement on oofib, a benchmark almost solely devoted to measuring PCC performance.
cotto especially since yaml isn't traditionally executable
dukeleto cotto: we can have YAMLcutables 07:58
cotto and we can have yaml be the serialization format for M0 07:59
the sky's the limit
bacek Dear motherf^W idiots! Please stop it now :)
dalek nxed: r753 | NotFound++ | trunk/winxedst1.winxed:
optimize a bit some frequent usages of && and ||
cotto bacek, it's nice to have you around. 08:00
dukeleto YAML from the rooftops! YAML on the beaches! YAML in the streets...
Who will YAML the YAMLers?
ok, i am done
bacek cotto, not for long I suspect. I'll new bloody big project at $work starting from March...
cotto disappointed face 08:01
dukeleto bacek: can you describe what the next steps for GenGC are?
bacek dukeleto, 1) read proposed algorithm; 2) implement it; ... 4) Profit!
dukeleto bacek: i think you missed 3) beer 08:02
bacek dukeleto, no. Beer is step 0
dukeleto bacek: lulz
bacek: yes, it is
cotto and 1a and 2a...
bacek from 1a till 1z actually 08:03
cotto Mmmmm. uncountable beer.
dukeleto bacek: which gengc algorithms do you have in mind?
bacek: which fit our current system? have you ruled any out yet?
cotto dukeleto, he has it documented in some detail in his branch 08:04
dukeleto cotto: well, then
dukeleto hasn't looked at the branch, he just likes pestering bacek
cotto It's cleverly disguised as the description of an existing algorithm.
dukeleto cotto: which branch are we talking about? 08:05
cotto generational_gc
bacek dukeleto, github.com/parrot/parrot/blob/gene...c/gc_gms.c
top of the file
(code isn't related to algorithm at all) 08:06
cotto hence the clever disguise 08:07
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
bacek: or do i misunderstand?
bacek dukeleto, it's what I'm going to implement. If this algo makes sense at all. 08:09
dukeleto often misunderstands
bacek: what % of what is described at the top already implemented?
bacek dukeleto, close to 0
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.
dukeleto bacek: i assume it is hard to test
bacek dukeleto, and test isn't a huge problem. Just big :) 08:11
dukeleto bacek: is there some kind of papers that i can read which are similar to the algorithm that you describe? 08:13
bacek dukeleto, hmm... Just generic papers about GC. This algorithm is very parrot specific. For example it uses VTABLE_mark for traversing, etc 08:14
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
dukeleto bacek: and i see many different kinds of gen gc's
bacek dukeleto, a lot of them. Don't remember which one exactly...
dukeleto bacek: what is blocking you on that branch? time? or something else?
bacek dukeleto, <bacek> dukeleto, I need second pair of eyes to review it. 08:16
:)
dukeleto bacek: just trying to poke into your brains to see what is going on in there
bacek: that doesn't mean too much. what feedback are you looking for?
bacek dukeleto, "does it make sense at all"
dukeleto bacek: you are doing it all wrong. You should fix it and work 25 hours a day until it is perfect. 08:17
bacek: is that good feedback? ;)
bacek actually, I can implement simple 2 generations GC as first cut.
Which is much simpler
dukeleto bacek: who would be a good code-reviewer ?
bacek dukeleto, you!
cotto If you have to ask... 08:18
dukeleto bacek: well, one thing i see is how you decide which generation to collect
cotto ;)
dukeleto bacek: that looks like LHF to make a bit better
bacek: basically just adds some counters to keep track of allocated memory per generation, right?
s/just adds/just add/
bacek dukeleto, may be. But atm I'm at step 0. And run out of beer.
dukeleto bacek: we need to get you a beer helmet 08:19
bacek bb in about 20m :)
dukeleto bacek: if I mail you a beer helmet, will that improve productivity?
bacek with infinite supply of beer!
www.manuel-blechschmidt.de/data/Generational_GQ.pdf
dukeleto looks 08:20
bacek This is trivial 2gens GC. I can implement it in about a week.
dukeleto bacek: do it!
bacek "2gens" is so 90s...
dukeleto bacek: 2 gens is better than no gens
bacek we have at least 1! 08:21
afk # shopping
dukeleto cotto: what are you hacking on?
cotto I'm shuffling code around to make it easier to get callgrind-compatible output directly from the profiling runcore. 08:24
the current process isn't lazy enough 08:25
It's amazing how often I misspell "cg". 08:26
dukeleto cotto: that sounds very useful
cotto: what is your game plan for the lorito prototype? I invite you to work on my lorito branch 08:27
cotto: my game plan is basically the dynop approach that we talked about when we met up with allison and chromatic
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
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.
dukeleto cotto: ok, i like that
cotto: we need a spec
cotto: i am reading about the smalltalk vm
cotto I suspect that once the spec is ready it'll take maybe a week or two to get a usable prototype from it.
dukeleto cotto: it is stack based, but uses continuations
cotto: do you have a beginning of a spec in a public place? 08:29
cotto dukeleto, great. I love cross-pollination of ideas
dukeleto cotto: i would like the help with it
cotto nothing more than's on the wiki
I'd like to set up a series of more orgainzed pages there that read like a more traditional spec
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
cotto: shall we put the spec in the repo?
cotto: perhaps in docs/ ?
cotto: i think lorito is important enough to have a design document
cotto: perhaps docs/pdds/draft ?
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.
dukeleto cotto: whatev. but make it publicly viewable and editable by parrot devs
cotto: the wiki isn't git
cotto sadly not
but git does function as something like a wiki 08:32
er, github
dukeleto cotto: is there a specific wiki page about the first lorito prototype, which we have promised for 3.3 ?
cotto if it weren't too painful, a github wiki would be nice
dukeleto, no
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
dukeleto cotto: called "gollum"
cotto: but i am not volunteering to convert trac anytime soon
cotto: which wiki page are you going to put the spec on? 08:34
cotto: i am going full throttle at the lorito spec and ignoring everything else in parrot
cotto haven't thouhght about it
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
cotto structs, functions, arrays, support for a hash implementation 08:36
if we have that, we can do 6model
08:36 Patterner left, Psyche^ is now known as Patterner
cotto I consider the deliverable to be a demo (or demos) that show those 4 features. 08:36
runnably 08:37
dukeleto cotto: ok, it is something to shoot for
cotto: is there a roadmap tt that we can add that to?
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 :)
cotto no, btw
dukeleto cotto: i am learning to be more structured in my coding, mostly from external influence
you know, people who say "where is the code?"
cotto: are you thinking 6model gets implemented in M0 or M1 ? 08:39
cotto: i think it could be either
cotto: but i don't fully understant the implications, because M1 is not well-defined
dalek rrot: 75bb241 | cotto++ | src/platform/generic/error.c:
fix headerizer warning
rrot: 6074fa4 | cotto++ | / (2 files):
[profiling] abstract out the differences between different output methods, make usage a little less awkward
rrot: 899be57 | cotto++ | / (2 files):
[profiling] move some more init code into a separate function
rrot: 49b89e4 | cotto++ | include/parrot/runcore_profiling.h:
[profiling] fix a leftover debugging statement
rrot: 40e1059 | cotto++ | src/runcore/profiling.c:
[profiling] shuffle a function around
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
there may be others
dukeleto cotto: so my question is: Does our MOP get written on top of M0 or M1 ? 08:41
cotto on top of M0
in M0 ops
dukeleto cotto: that answers my question
cotto one down, ...
dukeleto cotto: that will guide are design of M0 08:42
cotto: if we can't implement a MOP in M0 ops, then the set of M0 ops is too small
cotto exactly
dukeleto cotto: and we can basically remove ops from M0 until we can't write a MOP anymore
cotto: and then M0 should be about the right size
cotto yup
dukeleto cotto: i also have been reading "The Art of the Meta Object Protocol" 08:43
cotto: very dry but very informative book
cotto lisp scares me
I ought to get over that
ttbot Parrot 40e10591 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/3343.txt (tt.taptinder.org/buildstatus/pr-Parrot)
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
dukeleto cotto: you broke stuff and things
cotto no rest for the careless
dukeleto M0 = { the smallest set of ops required to write a MOP }
i like that definition of M)
M0, rather 08:45
it is a bit more concrete
cotto ambiguous but concise
dukeleto cotto: the -Ofun is in the details 08:46
cotto: i have some implementation questions for you :) 08:47
cotto I'll be up until I fix the build
dukeleto cotto: i think i can just use a Continuation PMC and I don't need a LoritoContext PMC 08:48
cotto: i think i need to gather my thoughts more before i can ask useful questions 08:50
cotto: good luck fixing the build
cotto it's a new error to me
and thus meaningless casts saved the build 08:53
dalek rrot: 48c1717 | cotto++ | include/parrot/runcore_profiling.h:
fix the c++ build
cotto seen fbrito 08:54
clunker3 Sorry, cotto, I haven't seen fbrito.
aloha fbrito was last seen in #parrot 3 days 14 hours ago leaving the channel.
cotto seen fbrito
clunker3 Sorry, cotto, I haven't seen fbrito.
aloha fbrito was last seen in #parrot 3 days 14 hours ago leaving the channel.
cotto msg fbrito How's the github hook hacking going? 08:55
aloha OK. I'll deliver the message.
cotto wonders why clunker3 is here
it was time for sleep an hour ago, but I guess now will have to do. 08:56
'night
09:03 AzureSto_ left 09:04 AzureStone joined
moritz aloha: msg pmichaud re 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
bacek aloha, 26 * 60 + 62 09:56
aloha bacek: 1622
bacek aloha, 25 * 60 + 62 09:57
aloha bacek: 1562
bacek aloha, (1622 - 1562) / 1622 * 100
aloha bacek: 3.69913686806412
bacek Looks about all right
10:04 particle1 joined 10:06 particle left 11:08 dalek left, elmex_ joined, elmex left, elmex_ is now known as elmex
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 11:12 Maddingue left, Maddingue joined 11:37 kid51 joined 11:39 contingencyplan left 11:46 particle joined 11:49 particle1 left 12:18 bluescreen joined
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:19
13:21 kid51 left 13:33 bluescreen left 13:46 whiteknight joined 13:48 bluescreen joined 13:55 rurban_ joined
whiteknight good morning, #parrot 13:57
13:58 rurban left, rurban_ is now known as rurban
moritz good morning whiteknight 14:01
whiteknight hello moritz, how are you today?
moritz whiteknight: a bit tired (not too uncommon for fresh parents), otherwise quite well 14:03
whiteknight no, it's not uncommon at all
PerlJam moritz: It's not uncommon irregardless of the parental "freshness" 14:06
moritz PerlJam: I do hope that I'll get more sleep in a few years :-) 14:07
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:08
moritz :-) 14:09
but at least in theory you *could* sleep
PerlJam in practice, sometimes I have no choice :)
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
14:10 plobsing left
pmichaud good morning, #parrot 14:13
Coke PerlJam: that could end worse, so good job. ;)
pmichaud: hio.
moritz \\o pmichaud
PerlJam pmichaud: good morning 14:14
14:40 ascent left
whiteknight pmichaud: it looks like you just got bumped/unsubscribed from parrot-directors 14:43
I don't know why
pmichaud I unsubscribed... I think I was supposed to do that last fall but didn't get around to it 14:47
if you want me to remain on the list, I can certainly do that :)
whiteknight oh, it looked like you got booted because of a bounced email 14:48
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 ...."
mikehh forgoit to report: 14:50
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)
27,600 ok, 0 failed, 611 todo, 1,837 skipped and 0 unexpectedly succeeded
15:03 PacoLinux joined 15:14 Andy left
Coke pmichaud++: thanks for writing those emails up 15:24
15:42 plobsing joined
Hackbinary hello, where is the best place to read up on PAST::Op ? 15:44
15:44 ascent joined 16:00 Andy joined 16:01 allison_ is now known as allison 16:04 contingencyplan joined
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
16:06 bluescreen left
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
(you can read just the docs with "perldoc <file>")
16:12 freeksh0w86 joined 16:15 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner 16:23 jsut joined 16:27 mtk joined
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:34
dalek nxed: r754 | NotFound++ | trunk/winxedst1.winxed:
refactor constant optimization of some binary operators and apply it also to '%'
 16:35
Hackbinary what is dalek?
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:37
moritz whiteknight++ # very well thought-out email to parrot-dev (PDS aftermath, .nqp) 16:38
plobsing++ # same reasons 16:39
plobsing freeksh0w86: trac.parrot.org/parrot/wiki/Platforms/Windows 16:40
sorear Hackbinary: commit reporter
pmichaud "Parrot's repository should not contain any tools, utilities, or
libraries written in a language which is not itself provided in the
Parrot repo (with a *very* small handful of exceptions, including
Configure.pl and maybe the Python-based GDB pretty-printers). "
dalek nxed: r755 | NotFound++ | trunk/winxedst0.cpp:
operators '<<' and '>>' in stage 0
pmichaud Somehow I don't think that is really sustainable, but that's just me. 16:41
sorear C?
sh?
Coke pmichaud: I think that's overstating the situation, yah.
plobsing sorear: sshhhh!!!
Coke I think they meant "that we don't already require to build."
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.
it's like saying "Perl won't bundle anything that comes from CPAN" 16:42
moritz also thought "C?"
pmichaud (I'll grant that "repository" and "distribution bundle" are separate.)
s/separate/potentially separate
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
pmichaud so saying that "Parrot core can only use things developed by Parrot" seems unsustainable
Coke pmichaud: where are you quoting that from? 16:44
pmichaud it's meant as a paraphrase, not a direct quote
but certainly there's an underlying theme of "we have to own anything we use" 16:45
in both whiteknight++'s and particle++'s messages
er, "underlying theme" is too strong. "implication" is more accurate.
cotto_work ~~ 16:46
dalek nxed: r756 | NotFound++ | trunk/winxedst1.winxed:
constant optimization of '<<' and '>>'
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
(this last quote is from whiteknight++'s message)
Coke speaking of strawman, chromatic notices my obvious intentional one, and then dangles several more. wtf. 16:48
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:49
16:50 chromatic joined
chromatic Coke: name one. 16:50
pmichaud okay, after reading the latest messages I'm definitely staying out of the thread.
other than to identify factual assistance 16:51
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.
Coke ... is that the plan? 16:53
I must be confused about the plan.
chromatic I hope it's not the plan. My point is that it's a plan which requires rethinking Parrot's goals.
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?
(sounds like no. if not, isn't that axiomatically a strawman?)
pmichaud Coke: are you the best person for me to contact about updating my planetsix feed address?
Coke pmichaud: I'm a person. I'm here. lemme dig up the repo. 16:55
pmichaud: you don't have a planetsix entry.
pmichaud I did at one time
maybe it got removed
anyway, pmthium.com/category/perl6/feed/
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?
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
let me look at the other examples
yes, just my name
Coke particle was coming off as more anti-nqp-changes than "
cotto_work NotFound: what can PIR do that winxed can't?
pmichaud could be "Patrick R. Michaud (pmthium)"
to be analogous with jnthn++'s "Jonathan Worthington (6guts)" 16:58
Coke pmichaud: done.
pmichaud danke
NotFound cotto_work: the main limitation now is that winxed doesn not support :multi
particle did i ever use "must" instead of "may" in my email?
chromatic Coke, I would have responded to Moritz's silly strawman, but you phrased it much better than he did.
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
Coke I really need to get back to $DAYJOB, but let me find the bit of particle's email that made me run screaming.
moritz chromatic: maybe it was merely a failure to communicate
Coke "the concern with parrot supporting the new nqp is that any tools we
atrodo I'm looking forward to reading the thread, if i can ever find the time
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.
Coke specific risks associated with the new version of nqp"
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
Coke yes, but I've seen no one suggest that parrot is goin
damnit.
whiteknight new NQP can be portable all day long, so long as *they* provide the wrappers
moritz +1 17:01
Coke is going to have to put out any more effort than we already do to support rakudo.
chromatic That doesn't alleviate all of my concerns.
moritz and the "new nqp" actually can exploit parrot features that the old one can't
Hackbinary what do you want new npq to be portable with? 17:02
whiteknight chromatic: so then how do we alleviate them?
particle i never mentioned nqp benefits, as i can't speak to them
Coke Hackbinary: have you read the thread on the parrot-dev mailing list?
pmichaud Hackbinary: url coming
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.
chromatic I'm not sure NQP can alleviate them. NB those risks might be acceptable, but I want us at least to consider them.
pmichaud Hackbinary: actually, you can read the details at pmthium.com/ 17:03
parrot-dev threads are at:
alleviate them. NB those risks might be acceptable, but I want us at least to consider them.
grrrrr
bad past
*paste
lists.parrot.org/pipermail/parrot-d...05408.html
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.
pmichaud lists.parrot.org/pipermail/parrot-d...05402.html
nqp almost certainly is optimized for parrot first
afk, lunch 17:05
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:06
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.
plobsing eg: ${ goto &label };
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
plobsing it was just an idea. bacek might not wind up using it either. 17:10
17:12 zby_home joined
NotFound plobsing: maybe using ':', looks less conflicting to me: ${ goto :label }; 17:13
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:14
NotFound From the point of view of human read and write ability, is not hard to beat PIR ;) 17:15
cotto_work not at all 17:16
chromatic IMCC was scope creep for Parrot.
plobsing and we're hitting the hard limits of its capabilities. for example issues with more complex uses of static PMCs. 17:17
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
Coke in retrospect, avoiding imcc and having something like scheme that created PASM would have been much better, IMO. 17:23
ah well.
chromatic Parrot should have tried to build a PCT from the start, as I see it.
17:23 slavorg joined
cotto_work yet here we are 17:23
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.
chromatic That's my concern: scope management.
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.
Coke Ok. I think we can do a better job framing that concern. That's all.
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
chromatic That is exactly my goal.
whiteknight so the real question is "what is the perfect language for that role?" 17:26
17:26 plobsing left
NotFound Klingon 17:26
whiteknight still arguably better than PIR
chromatic Maybe we don't need a single language but the everything-after-NQP-the-language stages of PCT.
Coke lojmIt yIpoSmoH! 17:27
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
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
If the answer is "Whatever generates tokens for the other stages of PCT", then cool.
whiteknight Python and PHP, respectively
chromatic See also MAD in Perl 5.
17:29 plobsing joined
whiteknight there is a cultural infight between dynamic languages communities. Python hackers aren't perl hackers for a reason, and vice-versa 17:30
a perl-like language is going to be distasteful to a python hacker.
that said, a new, neutral language will not be
chromatic I question that assumption, but let's assume it for now.
whiteknight I've heard people say that in this very channel enough
PerlJam I disagree with that assumption from the peanut gallery
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
we need a language for our internal toolset that we can control, and we can bend to the needs of our VM 17:32
that clearly isn't any existing variation of NQP
chromatic Let's not throw out all of NQP and its later stages so hastily though.
whiteknight I'm not throwing it out
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
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.
whiteknight right. Any language that compiles down to PAST or something sufficiently PAST-alike works
NotFound "generates tokens for the other stages of PCT" --> Someone wants to help with a winxed backend that do that?
PerlJam chromatic++
whiteknight ...and we come back to Winxed
17:34 freeksh0w86 left
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).
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
NotFound chromatic: The C++ stage is just the bootstraping tool.
chromatic Oh, right.
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.
whiteknight I am very hopeful that, in the world of Lorito, that PIR is able to improve and gain more and better syntax
chromatic: right. We don't have that yet. May not for a while if we don't set our sights on a target now
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
whiteknight plobsing: what is the state of ohm-eta? Does it work?
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
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.
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.
PerlJam NotFound: Sure, but I was thinking of breaking that down into slightly lower level components :) 17:40
For instance, NQP has Perl 6 grammars. Is that a necessary feature? (grammars, not necessarily Perl 6 grammars)
chromatic Maybe what we're trying to do is split NQP into two parts. 17:41
Or at least merge what of NQP/PCT Parrot needs, wants, and can support into Parrot proper.
NotFound winxed uses regex only as a helper to parse .pasm include files. That's it's most grammar-alike usage.
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.
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
it does have a number of nice syntactical features
chromatic I don't think forking NQP meets Rakudo's goals though.
moritz which means you'd have to properly spec and document it
whiteknight it's not a matter of Rakudo's goals. They've got their own new NQP
PerlJam plobsing, NotFound: exactly. So, what are the desired/required features for Parrot's toolchain language?
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.
NotFound PerlJam: obviously for me the answer is: the ones that winxed has ;)
plobsing plus those that Ī©Ī· adds :^) 17:44
NotFound A nice addition, yeah.
moritz PerlJam: 1) being a pleasant HLL 2) offering low-level access to parrot features and 3) being light-weight
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
they have their own versioning needs
chromatic Let's solve the problem; let's split NQP in two parts.
whiteknight rip out the compilerish stuff into a compiler library?
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
PerlJam whiteknight: a C-level library?
chromatic And Rakudo can customize the rest as Rakudo--and not the rest of HLLs--needs it.
That includes the cross-VM compatibility layer Rakudo wants.
whiteknight we can use that library to hold many compiler-related tools, tools for generating PBC, PMCs for support compilation, etc
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
is that the old-style NQP-RX?
chromatic Don't know yet. 17:48
We don't have to pick one today.
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
okay
plobsing: what does ohm-eta output? does it output an AST? Can that be PAST? 17:49
plobsing whiteknight: ATM, it outputs winxed which must then be compiled separately. 17:50
however, it does "parse" winxed and generate an AST (modulo some cheats because it just gets output again), so it *could* produce PAST 17:51
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:53
chromatic Wow, ascii_scan is expensive. 17:57
whiteknight plobsing: okay. So that really becomes a pluggable frontend to this compiler library we're talking about 17:58
plobsing it is a suitable candidate, yes. 18:00
it still has some rough edges ATM (don't say I didn't warn you!)
chromatic: where are you seeing ascii_scan as a major contributor to runtime cost? 18:01
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
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:03
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:06
chromatic Hah, we've halved the Coverity defects in the past 24 hours. 18:07
plobsing, removing STRING_scan() from the non-external case and testing that benchmark gives a 6.9% performance improvement.
plobsing chromatic: nice!
chromatic That's not necessarily the right approach, but it's informative.
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"
whiteknight plobsing: see also, IMCC 18:10
plobsing my thought exactly. I do not want that to happen again.
whiteknight so we produce a library that takes PAST, optimizes, creates POST, does whatever, then outputs PBC 18:14
in addition to some helper routines to generate PAST in the first place, if needed
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
this is that library
dukeleto ~~ 18:17
18:26 plobsing left
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
chromatic It's be nice to emit that code conditionally. 18:38
dalek nxed: r757 | NotFound++ | trunk/winxed (2 files):
add option --nowarn to stage 1 and non installable driver
 18:39
nxed: r758 | NotFound++ | trunk/winxed_installed.winxed:
add option --nowarn to installable driver
 18:50
18:53 plobsing joined
dalek nxed: r759 | NotFound++ | trunk/ (3 files):
update installable files
 18:56
19:04 bubaflub joined 19:21 bubaflub left 19:23 wknight-phone joined 19:25 plobsing left
bacek ~~ 19:26
Good morning, humans.
dukeleto bacek: greetings, meatbag 19:27
19:27 wknight-phone left
bacek dukeleto, ignore algorithm in gc_gms.c. It's way too complex. I can design simpler (and better) one. 19:29
19:29 plobsing joined
cotto_work bacek++ 19:30
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.
whiteknight bacek: so let me know what you want me to do, what algorithm to follow, etc
okay
it's become enough of a priority that I want to focus on it 19:33
so just tell me what you need
bacek whiteknight, nothing yet. Give me couple of days :) 19:36
dukeleto bacek: i like simpler and better 19:38
whiteknight bacek:okay, no rush. It will take me a few days to finish up IMCC 19:41
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
dukeleto good lord 19:47
whiteknight that's nothing. back in my day we had to push 600 commits up hill both ways 19:51
chromatic and merge them by hand 19:52
dalek nxed: r760 | NotFound++ | trunk/winxedst1.winxed:
syntax :label in pirop statements in stage 1
 19:53
NotFound plobsing: ping 19:54
bacek chromatic, 6 conflicts in total to merge 4 month old branch. Not too bad :) 19:55
plobsing NotFound: pong 19:58
NotFound plobsing: ${ goto :label };
plobsing saw that, nice. NotFound++ on turnaround.
bacek plobsing, how hard will be to implement such syntax in imcc and deprecate old one? 20:12
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.
bacek plobsing, I can change PCT to emit new labels syntax. Not a big deal. 20:18
20:24 perlite left 20:25 perlite joined 20:54 plobsing left 20:55 bubaflub joined 20:57 plobsing joined 21:00 fperrad left
dalek nxed: r761 | NotFound++ | trunk/winxedst1.winxed:
fix emit helper methods that were losing annotations
 21:03
21:08 AzureStone left 21:11 Hackbinary left, AzureStone joined
cotto_work dukeleto: ping 21:11
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?
dukeleto cotto_work: just work backwards from the person who has the strictest time commitments 21:14
cotto_work: which i assume is kid51
cotto_work: feel free to use doodle 21:15
cotto_work: it might be easier
cotto_work gothca
dukeleto cotto_work: do you have a day in mind?
cotto_work none yet
whiteknight dukeleto: I've got an android now, and am probably going to want to put parrot on it eventually 21:17
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:18
21:19 sheant joined
cotto_work dukeleto: I wanted to figure out what you were talking about before sending anything out. 21:19
21:20 bluescreen left
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/
aloha kid51 was last seen in #parrot 9 hours 43 mins ago joining the channel.
plobsing clunker3?
21:22 Hackbinary joined
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
pmichaud part of the question then becomes, what is that library written in?
chromatic Tene, they did. I should update the post to reflect that.
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.
whiteknight pmichaud: well, that "library" already mostly exists as the backend to NQP. So we can keep it in PIR
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.
pmichaud the only other reason we're doing our own PAST is that we need it to be using the new metamodel asap.
whiteknight pmichaud: the maintainability angle is a little different for Parrot-ish utilities in the Parrot repo maintained by Parrot devs
Tene So the version you copied doesn't have the error either.
pmichaud whiteknight: I understand that fully.
whiteknight pmichaud: I imagine things would be very different for external developers. I wouldn't recommend you or your team use PIR
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
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
pmichaud whiteknight: agreed, and I don't think that has to be decided immediately (as chromatic indicated)
whiteknight we are going to have to come up with a better language over time
pmichaud but I don't think we have to exclude NQP as a possibility either
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
pmichaud what does 100% adapted mean in this sentence?
that seems to be a very vague notion
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
pmichaud I don't see those as huge conflicts
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
whiteknight like I said, I'm not against NQP
what I don't want is to be relying on a language implementation which is beholden to other, possibly conflicting interests
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.
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. :-)
for example, Parrot uses C but doesn't provide it. :)
cotto_work thank goodness
pmichaud I grant that we might expect "use" plus "provide"
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
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
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
Tene There have been times where NQP hasn't easily provided capabilities that parrot supported through PIR.
Some sub attributes, iirc.
pmichaud Agreed fully. (more)
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
pmichaud the reason for that is that providing those would require significant changes to PAST
and POST
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.
pmichaud that's not really a criticism of NQP as much as it is the entire toolchain
PerlJam whiteknight: you want to use C for Parrot's core language? ;->
21:30 whiteknight left, plobsing left
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.
Tene nods.
chromatic If that language is NQPNG, fine. Winxed? Fine. PIR++? Fine.
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.
Provided....
... that the support burden of features that belong to Rakudo, not Parrot, and vice versa go to the appropriate places. 21:33
pmichaud absolutely
that's part of what the new nqp is trying to tease out
because it's been too hard to do them in either rakudo or Parrot
rakudo is too big, and parrot has non-rakudo goals
there needed to be an intermediate place to do things
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.
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
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
i.e., "use Parrot;' at the top of an nqp program opens all of the parrot-specific stuff
cotto_work pmichaud: I'm really glad to hear that.
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
Tene I agree about simpler, fwiw.
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
Probably provides a very neat way to handle it.
21:38 plobsing joined
cotto_work I like where this is going. 21:38
chromatic An extensible NQP, with Parrot absorbing it but Rakudo providing its language- or project-specific extensions? 21:39
jnthn ...Parrot absorbing NQP? 21:40
But yes, Rakudo specific bits would live in Rakudo.
chromatic Parrot has to provide some sort of PCT. 21:41
jnthn *nod* 21:43
chromatic If NQP-rx has a looming end of life, we should think about replacing it.
pmichaud well, nqp-rx doesn't have to die anytime soon. 21:44
it exists, and can exists for as long as parrot (or anyone else) wants it to exist
chromatic If it's not getting new features and if NQPNG is (and they're compellingly better), let's make an argument for deprecation.
pmichaud I agree, deprecation is the likely outcome. but I think we're a couple of months early for that decision 21:45
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:46
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
s/develop/generate/
jnthn pmichaud: Yes, that's what I think is best.
pmichaud: I'd not want to have multiple "master" copies of e.g. PAST::Node and friends.
pmichaud I concede that there might be philosophical or strategic reasons why Parrot might not find that acceptable.
I'm not asking for an answer anytime soon; just that we don't preclude possibilities prematurely either. 21:48
and if parrot feels it needs to be working on a pct replacement in parallel with the nqp effort, that's probably okay too.
(in case the nqp effort doesn't work out for parrot for whatever reason)
chromatic Out of tree development of NQP doesn't sit well with me. 21:49
pmichaud yes, I've surmised as much. 21:50
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.
It feels like Parrot never wants to take advantage of things created externally unless it can subsume them for itself.
chromatic Let's be more specific then. 21:51
jnthn What problems has nqp-rx living in a different repo created to date, ooc?
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?
pmichaud jnthn: the problem were experiencing now might be an example :)
jnthn pmichaud: :)
21:53 wknight-phone joined
pmichaud waits to see if chromatic has more to say on his last statement. 21:53
dalek nxed: r762 | NotFound++ | trunk/winxedst1.winxed:
fix do continue bug and optimize a bit the do ... while(false) case
Coke jnthn: having just fixed a bug in rakudo, it was fun to have to fix nqp-rx, then parrot, then rakudo, then roast.
(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.
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.
pmichaud chromatic: I think this is ultimately inevitable. 21:55
for any sufficiently advanced and distributed system, at least.
chromatic Dependency management?
21:55 rurban_ joined
cotto_work Would it be sane to keep the Parrot-specific layer of nqp in parrot.git? 21:55
pmichaud yes.
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".
i.e., Parrot has a choice of not using it, forking it, or developing its own.
(or figuring out how to manage the dependency) 21:57
chromatic I guess Rakudo has to answer that question then.
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, rurban_ is now known as rurban
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.
pmichaud oh. then somewhere we're not communicating well. 21:59
Tene That's been my understanding, actually.
chromatic Ultimately, I'd like to see:
1) prototyping of NQPNG in an external repository, until it's ready to consider
2) migrating the Parrot-specific parts of NQPNG into Parrot, concurrent with
wknight-phone nqpng?
chromatic 3) migrating the Rakudo-specific parts of NQPNG where they best belong 22:00
pmichaud nqpng is chromatic's name for "new nqp"
dukeleto i think chromatic means the nom branch of nqp-rx, which is now called "NQP"
chromatic with the result of
wknight-phone ok
chromatic 4) Parrot provides a compiler toolkit that HLLs can use and customize where they see fit without modifying NQP as provided by Parrot
plobsing nqpng - because we can't get enough consonants
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:01
wknight-phone nqprg: nqp really good 22:02
chromatic The Parrot specific parts are everything but the Rakudo-specific parts.
jnthn ...no.
pmichaud there's an nqp component in here somewhere.
nqp still wants to be a language that others can use to write compilers other than Rakudo.
it's not all just "Rakudo" and "Parrot".
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.
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"
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
wknight-phone to
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.
pmichaud I'm equally certain that parrot will not ultimately own every library it provides.
wknight-phone to abstract a changing vm it should
no
pmichaud chromatic: I have a Rakudo hat and an NQP hat.
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.
and other libraries.
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.
chromatic It's not about efficiency for me.
pmichaud I think the ownership issue is about security
chromatic It's about costs and benefits and allocating resources.
pmichaud not security in the "cannot be broken into" sense, but security in the sense of long-term support
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
somethingto.replace pir
Tene If NQP ends up making changes that actually do conflict with parrot, parrot can certainly fork.
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"
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.
chromatic Parrot needs to provide a compiler toolkit.
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)
wknight-phone to write things that we provide in parrot.git
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.
wknight-phone yes. but not the Lang needed to call that library
pmichaud which is what I said wknight-phone was saying, I think. 22:11
wknight-phone write your compiler in fortran
PerlJam chromatic: so ... why exactly?
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.
chromatic PerlJam, see my message to parrot-dev.
22:12 bubaflub left
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?
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
wknight-phone have to go
pmichaud rather than put the multi-backend code into rakudo, it makes sense to put it into nqp
22:13 wknight-phone left
pmichaud I'm pretty sure it doesn't make sense to have the multi-backend features in parrot :) 22:13
chromatic Not at all. 22:14
pmichaud I also think nqp has value in its own right, as a language for writing other compilers
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.
Tene nods.
pmichaud Tene: because Rakudo is too heavyweight for other compiler authors to use
if I'm writing an APL compiler, I don't want the whole Perl 6 runtime 22:15
Tene nods.
pmichaud I just want those powerful parts of Perl 6 that help me to write a compiler
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:16
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?
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?
pmichaud platform-agnostic is too strong
multiplatform is more precise
chromatic multi-backend?
pmichaud yeah, multi-backend. I'd like to expose features of the backend 22:19
which makes for non-portable code if you use them, but that's okay
Perl 6 has the same issue as well -- we'd like Perl 6 to be able to access specific capabilities of its backends
without having to adopt all of them into the language itself
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"
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.
I assume, of course, that platform equity is something useful.
or desirable
Tene "platform equity"?
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.
Tene Or, alternately, "Adding support for X to nqp for parrot would also require adding X support for all other backends"?
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.
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"
chromatic or how it can provide them
pmichaud chromatic: I disagree wholeheartedly with this last statement
NQP's philosophy has always been to adapt to what the vm provides, not to impose itself on them
Tene chromatic: given that nqp is targetting VMs that it has no control or influence over, that seems... unlikely.
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
and I don't have any intention of dumping the problems all on parrot as a result
that's not... success.
chromatic Abstractions aren't free. 22:25
pmichaud no, but they often provide benefits that far outweight the costs
*outweigh
PerlJam That's one of those things that make me think "efficiency" is a concern.
pmichaud PerlJam: I have several answers to that 22:26
1. I'm trying not to prematurely optimize here
2. Our current approaches to efficiency haven't been working all that well, so we need some bigger changes
3. Some companies have been very successful in assuming that computing capabilities eventually swamp efficiency concerns 22:27
4. What we think of as efficient today may change in a disruptive technology environment (as Perl 6 certainly aims to be) 22:28
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:29
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.
chromatic That's the efficiency concern I have.
pmichaud I think that communicating up and down toolchains and component streams is a fundamental part of a thriving ecosystem.
chromatic I think don't borrow trouble.
pmichaud There's a reason that many manufacturers outsource their component development :-) 22:31
it's more efficient that way, and it allows teams to focus on what's important
that said, don't outsource your core competency
chromatic Sure, but if you outsource what should be your core competence, you're named Carly Fiorinia and I used to work for her.
Fiorina
pmichaud yes, we're in agreement
chromatic Providing a compiler toolkit should be a core goal of Parrot. 22:32
Part of that compiler toolkit should be one good language in which to write compilers.
PerlJam the toolkit isn't the language though
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.
pmichaud NQP has been predicated on the "it's better to borrow Perl 6" concept.
PerlJam chromatic: no, but you can provide the already-bootstrapped language though
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.
Tene Explain "primarily"? 22:35
aloha positive: nothing; negative: nothing; overall: 0.
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.
Tene So Parrot is going to reimplement PCT and start work on a new language? Is this really the time for that anyway? 22:42
chromatic I don't think we have a choice. 22:43
pmichaud as in, importing code from another repo will never be acceptable? Okay.
Tene Why is it not a choice to import code from nqp like we're currently doing with nqp-rx?
chromatic Too much technical risk.
Tene I mean, it's obviously an option as we're *currently doing it*.
chromatic nqp-rx isn't a project with a strong multi-backend goal. 22:44
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:47
cotto_work Let me try to enumerate the issues here. 22:48
1 - we need something that can be tightly coupled to the VM to take advantage of of VM-specific features
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 ...
cotto_work 2 - We want a low time between implementing the VM feature (or deprecating) and having it be accessible in the language.
Tene ... infrastructure.
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
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.
KaeseEs (sorry to interrupt) anyone know the printf format specifier for UHUGEINTVAL off the top of their head?
cotto_work Is that close?
chromatic Exactly those, cotto_work.
pmichaud I like cotto's summary. Very clear. 22:49
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?
pmichaud or a GC engine?
chromatic That was my suggestion, cotto_work.
cotto_work re-reads 22:51
chromatic pmichaud, outsourcing a GC is probably intractable for performance reasons.
JIT less so.
pmichaud but the point is one of instability and dependence on another project
cotto_work in-sourcing the JIT is difficult, if not intractible
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.
Shipping a compiler for which you have to hand-assemble code isn't that useful. 22:53
pmichaud ICU? Or is that deemed "not unstable"? 22:55
dalek nxed: r763 | NotFound++ | trunk/winxedst1.winxed:
improve detection of empty statements
 22:56
pmichaud I'll need to run soon... so perhaps this can be continued later if it needs to be. 22:57
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
fork.
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:02
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:03
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:04
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
More often it's been the other way around, nqp being blocked by parrot deprecation policy.
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:07
Now, that's mostly about my ignorance, which very well may just be a failure of imagination on my part. 23:08
It does seem very low risk compared to the benefits of having a good language right now.
chromatic nqp-rx isn't a project with a strong multi-backend goal. 23:10
23:10 Themeruta joined, Themeruta is now known as NotFound_b
chromatic The new NQP is. 23:13
That'll change the design decisions.
To my knowledge, no substantial program implemented in nqp-rx runs on any other backend right now. 23:15
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
Parrot may have to adapt to that,.
Tene "can't predict the details of" doesn't mean that we can't have any expectations at all.
chromatic I don't want to overstate my expectation that things will change dramatically. 23:17
or at least unpredictably
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.
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
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:18
also, I should not that nqp-rx has always had a multibackend goal. 23:19
*note
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.
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?
pmichaud absolutely. I think nqp users will demand that.
I know that Rakudo will.
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:21
pmichaud Yes. 23:22
However, I conceive there might be differences of opinion about what constitutes a "problem".
However, we did manage to accommodate Parrot multisubs and :vtable definitions in the new nqp.
23:22 zby_home left
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?
pmichaud in nqp-rx
not meeting nqp's goals, definitely. 23:23
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
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
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.
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:26
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.
chromatic Merely a waste of time and resources leading up to that point.
pmichaud I disagree with that, strongly. 23:28
I know that it was much easier to create NQP from pge than it would've have been to create it from PIR.
sorry, nqp-rx from pge
chromatic I was responding to Tene, not pmichaud.
pmichaud oh, sorry.
but I still disagree with that. I don't think it would be that bad. 23:29
or a waste.
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.
bacek_at_work ~~
Tene Who's going to be wasting effort there?
Ah, whatever the trouble is leading up to the decision.
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.
bacek_at_work Jusy my $0.02.
23:30 whiteknight joined, plobsing left
bacek_at_work We can have newPCT (or whatever) imported into parrot. Same as nqp-rx now. 23:30
POST::Compiler will able to generate bytecode directly. 23:31
(It can now already)
pmichaud bacek_at_work: iiuc, chromatic is opposed to such an approach.
bacek_at_work VM-independent nqp will generate PAST.
parrot-dependent PAST::Compiler.post() will generate parrot-specific POST.
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.
bacek_at_work POST can be implemented in nqp, nqp-rx, winxed, whatever. Metamodel of nqp/past/post can be different. 23:33
chromatic, why?
pmichaud afk, errands
chromatic Because that would be silly.
That's very polite Russian, so translate accordingly.
bacek_at_work what is the difference between nqp, pct, ICU, libJIT and BoehmGC? 23:34
And tree-optimizations from tcurtis
chromatic ICU, libJIT, and Boehm aren't projects actively developed simultaneously as consumers of core Parrot and producers of core Parrot.
bacek_at_work Than we have advantage here for nqp and pct
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?
bacek_at_work sigh...
Let's use git submodules if it will solve concerns.
dukeleto chromatic: what are you trying to get at?
bacek_at_work Or "better plumage" 23:36
chromatic Importing NQP snapshots from another repository is, as I see it, a mistake.
dukeleto chromatic: let's take a concrete example: parrot/yaml-tiny
chromatic NQP should be produced as a core component of Parrot within parrot.git.
bacek_at_work chromatic, yeah...
in last 2 years we are trying to reduce maintained codebase.
chromatic By focusing on core features. 23:37
bacek_at_work And you are proposing totally different approach.
chromatic If a compiler toolkit isn't a core feature, then it's a moot point.
23:37 plobsing joined
chromatic Is PAST a core feature? POST? PBC emitting? I believe so. 23:37
whiteknight I think it's certainly core
bacek_at_work PAST - no.
POST - yes
PIRATE doesn't use PAST at all for example.
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.
chromatic, is YAML::Tiny core feature?
chromatic I think not.
bacek_at_work is JSON::Parser core?
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.
bacek_at_work LWP?
Digest::MD5? 23:39
chromatic Nope.
bacek_at_work ls runtime/parrot/library/*pbc | wc -l
30
which of them should _go_?
chromatic Anything we don't need to run plumage, I say.
bacek_at_work Test::More?
LWP? 23:40
Running plumage is matter of bootstrapping.
Currently we are using PIR as bootstrapped code.
If can have "portable PBC" we can use it.
chromatic Then let's evict everything we don't need to build Parrot, run tests, and bootstrap plumage.
bacek_at_work Or "some magical serialized pbc format" 23:41
chromatic, why not?
chromatic I don't know what you're trying to prove.
whiteknight +1 from me on radical library eviction 23:42
NotFound_b bacek_at_work: cuurently I use PIR to generate code.
bacek_at_work NotFound_b, erm? 23:43
whiteknight NotFound_b: But there's no reason why it always has to be that way
bacek_at_work chromatic, point is: a lot of stuff can be bundled with parrot, not developed in same repo.
NotFound_b bacek_at_work: I can'r generate "portable PBC" from winxed.
whiteknight of course, PIR will probably always exist
bacek_at_work Either via plumage, import, git submodules, magical fairies, whatever. 23:44
NotFound_b, there is no such thing as "portable PBC" now.
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.
NotFound_b bacek_at_work: and there is no such thing as other way to generate PBCs as fast as PIR right now.
bacek_at_work NotFound_b, emitting PBC from newPOST tree is quite fast. Modulo speed of parrot it self. 23:45
chromatic, I don't see any contradictions. 23:46
If PCT is bundled with parrot.
NotFound_b bacek_at_work: As fast as winxed is now generating pir and compiling it?
whiteknight We absolutely need tools in Parrot to take AST, convert to POST and PBC 23:47
and we need related tools (optimizers, register allocators, etc)
bacek_at_work NotFound_b, order of magnitude slower.
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.
whiteknight and we should probably provide tools for creating AST nodes, for people who don't do that themselves
chromatic: I'm convinced
bacek_at_work whiteknight, checkout nqp_pct branch (or pirate), look at POST nodes. It's what we almost have now.
whiteknight we need all that crap in core
bacek_at_work: I've seen it
we need it, we need it in core 23:48
NotFound_b bacek_at_work: the PIR still has an echologic niche, IMO
chromatic *developed* in core
whiteknight yes. Developed in core
bacek_at_work Again...
POST is parrot specific
And can be developed inside core.
23:48 plobsing left
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
compiler libraries are fundamental
23:49 sheant left
NotFound_b A stable and reasonably fast. 23:49
bacek_at_work we can even bootstrap PAST.nqp into PAST.pir
To keep it inside core.
Let's draw it: 23:51
0. Lorito M0
1. Lorito M1
2. POST::Compiler with .pbc method
3. PAST::Compiler with .post method 23:52
4. "HLL which can generate PAST"
Tene So what were the reasons that nqp left the parrot repo originally?
chromatic To avoid Parrot's deprecation policy.
bacek_at_work Tene, development velocity
NotFound_b bacek_at_work: winxed is out of that graph.
bacek_at_work Where we should draw line between core vs non-core
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.
chromatic Between one good implementation of 4 and every other implementation.
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
like PIR, plus syntax, minus the suck 23:56
chromatic Exactly.
People can plug and play parts of the PCT stack as they want, but they have one good option for every stage.
one good *default* option for every stage
whiteknight yes 23:57
chromatic and Parrot controls them for the sake of support, efficiency, deprecation, et cetera
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
chromatic s/NQP/<something, perhaps NQP>/ 23:58
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

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!