Parrot 1.9.0 "Blue-fronted Amazon" released! | parrot.org | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 16 December 2009.
00:02 kid51 joined 00:06 tetragon joined
nopaste "kid51" at 70.85.31.226 pasted "context_unify3 branch: Linux/i386: make corevm && make coretest: fewer test failures than Sunday" (109 lines) at nopaste.snit.ch/19116 00:13
"kid51" at 70.85.31.226 pasted "(better) context_unify3 branch: Linux/i386: make corevm && make coretest: fewer test failures than Sunday" (198 lines) at nopaste.snit.ch/19117 00:15
00:23 Whiteknight joined
Whiteknight context_unify3 builds? 00:25
chromatic Two of those failing test files have the same source. 00:26
s/source/cause/
Whiteknight which ones, the backtrace ones?
00:26 nopaste joined
chromatic yes 00:27
That may fix the lexical test too, but I'm not completely certain. 00:29
Whiteknight these dynpmc tests are new failures 00:31
chromatic touch src/dynpmc/*.pmc 00:33
cotto_work The makefile is not very smart about dynpmc dependencies. 00:37
chromatic s/not very smart/often bafflingly wrong/
00:38 abqar joined
cotto_work yeah, that too 00:38
00:41 nopaste joined 00:42 davidfetter joined
Whiteknight okay, dynpmc tests are cool again 00:50
dalek nxed: r272 | julian.notfound++ | trunk/winxedst1.winxed:
improve and simplify error checking in stage 1
 00:51
nopaste "kid51" at 71.255.57.92 pasted "t/tools/pgegrep.t: Failure at r43115 (Darwin/PPC)" (93 lines) at nopaste.snit.ch/19118
Whiteknight so where does context->current_sub get set, and why is it Null in these tests?
kid51 That paste is from trunk, so it's a very new failure, probably within last 24 hours. 00:53
NotFound Looks like someone 'fixed' Getopt usage. 00:55
chromatic Whiteknight, should be in Sub.invoke and Coroutine.invoke. 00:56
00:57 plobsing_ joined
bacek_at_work Whiteknight, it was cleared in init_context, ivoked from pcc_prepare_call. I did add hackish check to avoid unnecessary clearing 01:18
01:32 xenoterracide joined 01:36 nopaste joined 01:53 lucian joined 01:56 nopaste joined 02:01 TonyC joined 02:05 JimmyZ joined 02:18 TonyC joined
plobsing_ why do GET_ATTR_* and SET_ATTR_* get compiled away by pmc2c? 02:21
chromatic Syntactic sugar, I suppose. 02:23
plobsing_ but they can't be used from macros. Do they need to be compiled away? 02:24
chromatic They only work within the body of the PMC.
plobsing_ which is where I want to use the macro I am writing 02:25
purl Writing is easy; all you do is sit staring at a blank sheet of paper until the drops of blood form on your forehead. -- Gene Fowler.
02:25 TonyC joined 02:26 nopaste joined
Coke seen pmichaud ? 02:26
purl pmichaud was last seen on #parrot 6 hours, 18 minutes and 34 seconds ago, saying: phone
chromatic You need the expanded form then.
plobsing_ I want to write a VISIT_PMC_ATTR macro to abstract away the common case of visiting a PMC element from the visit vtable of a containing PMC. 02:27
is there a good way to do that?
chromatic Not really, no. 02:28
plobsing_ should there be? is this something I should be wanting to do?
02:29 patspam joined
chromatic Write it the naive way, and we'll see if we can make it easier. 02:30
02:30 bacek joined
nopaste "coke" at 72.228.52.192 pasted "NQP question" (16 lines) at nopaste.snit.ch/19119 02:31
pmichaud pong 02:33
where's the index rule? 02:34
in the grammar?
pmichaud checks
Coke: I can't find an 'index' rule 02:36
Coke moment.
nopaste "coke" at 193.200.132.135 pasted "full diff in progress" (134 lines) at nopaste.snit.ch/19120
pmichaud anyway, the 'MATCH' not found isn't due to whatever you're passing in, it's due to whatever the <index> rule is returning. 02:37
Coke ah. index occasionally is returning an int.
(occasionally? always, I think)
pmichaud no, the <index> subrule, not the action method
and not the .ast
Coke ah.
pmichaud looking.
aside: +token index:sym<m+n> { $<a>=<integer> '+' $<b>=<integer> } 02:38
would be more canonical as
token index:sym<m+n> { <m=integer> '+' <n=integer>
}
oh
even better (and perhaps part oft he issue)
token index:sym<m+n> { <m=.integer> '+' <n=.integer> }
to avoid the separate capture into $<integer> 02:39
any idea what input is causing it to fail with the error? 02:40
02:41 Maddingu1 joined
Coke joe 02:42
02:42 davidfetter joined, preflex joined
pmichaud oh, the case where the rule doesn't match? that's possible. 02:43
(and a bug if so)
Coke yah. if the index is "joe", then invoking the parse line there fails. 02:44
doesn't even get to the ?$parse check.
pmichaud right
Coke I'll commit what I have.
pmichaud I think the problem is that the match result ends up being an integer
Coke (it's still an improvement.)
pmichaud oh, I know what it is.... 02:45
very sneaky
you're calling directly into a protoregex. I didn't handle that case properly.
now to decide what "properly" should be in this case. 02:46
pmichaud thinks...
okay, I know what the fix should be 02:48
Coke pushed.
pmichaud need to fix nqp, then bring that into parrot
also need to switch keyboards.. bbiab
Coke you can duplicate it with ... puts [string first a abcd joe] 02:49
dukeleto looks like pgegrep is broken
Coke someone tried to fix it for getopt, IIRC.
needs to be unfixed. 02:50
probably can just rever the last commit that hit it.
02:51 davidfetter joined
dukeleto Coke: ok 02:51
02:52 JimmyZ_ joined
dalek rtcl-nqp: 08ad627 | coke++ | (5 files):
Add string indexing rules/actions/method, invoke from [string first]
 02:53
nopaste "pmichaud" at 66.25.4.52 pasted "reproducing the nqp bug found by Coke++" (9 lines) at nopaste.snit.ch/19121 03:02
Coke whee. 03:15
pmichaud about to push fix.
pushed (into parrot trunk) 03:23
it should work now... at least avoid the error you were seeing. 03:24
dalek p-rx: c9be3ee | pmichaud++ | (4 files):
Update bootstrap files, PARROT_REVISION.
 03:26
p-rx: 503f76f | pmichaud++ | src/NQP/Grammar.pm:
Merge branch 'master' of git@github.com:perl6/nqp-rx
p-rx: 88757e9 | pmichaud++ | (2 files):
Fix bug when protoregex is called directly from Grammar.parse (Coke++)
p-rx: ac7c519 | pmichaud++ | src/stage0/ (4 files):
Update bootstrap with protoregex fail fix.
03:30 KatrinaTheLamia joined
dalek kudo/master: d2dc84c | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to latest release.
 03:31
kudo/master: 5cccc22 | pmichaud++ | (3 files):
Merge branch 'master' of git@github.com:rakudo/rakudo
kudo/master: 2198ecc | pmichaud++ | docs/announce/2009-12:
Some more announcement updates.
Coke pmichaud++ # those tests now pass. 03:34
03:34 darbelo joined
dalek rrot: r43116 | pmichaud++ | failed to fetch changeset:
[nqp]: Fix for direct calls to failing protoregexes (reported by Coke++).
 03:34
03:35 Hunger joined
darbelo nopaste? 03:35
purl rumour has it nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
dalek rtcl-nqp: 543280f | coke++ | (2 files):
Bump parrot revision to get fix which resolves outstanding index issue.
 03:39
nopaste "darbelo" at 190.3.154.176 pasted "[pmc_freeze_cleanup] Segfault when freezing large ResizablePMCArray" (24 lines) at nopaste.snit.ch/19123 03:43
03:46 davidfetter joined
dukeleto msg fperrad do you know what is up with this? does it work for you? gist.github.com/258482 03:57
purl Message for fperrad stored.
04:03 davidfetter joined 04:04 davidfetter joined
dalek rrot: r43117 | darbelo++ | branches/pmc_freeze_cleanup/src/pmc_freeze.c:
Adding _NULLOK() to STRING parameters was unnecesary, we have STRINGNULL now.
 04:07
04:12 davidfetter joined
dalek TT #1373 created by jkeenan++: ./t/tools/pgegrep.t: New failures 04:12
Coke msg kid51 : tt #1373 is probably fixable by just reverting the last commit against pgegrep.t 04:15
purl Message for kid51 stored.
Coke msg kid51: er, against pgegrep itself.
purl Message for kid51 stored.
Coke msg pmichaud 04:16
purl Message for pmichaud stored.
Coke er, pmichaud?
pmichaud pong
Coke bah! I pre-emptively ping you suspecting latency, and you're here! 04:17
=-)
trying to track down an ast issue, might have it... 04:18
nope. getting rotating failures: 04:20
pushing...
purl Shoving...
Coke touch src/Partcl/Actions.pm && make && ./partcl t/cmd_string.t 2>&1 | more 04:21
if I do this, I occasionally get this failure:
pmichaud hums "take this bot and shove it..."
Coke Method 'ast' not found for invocant of class 'Undef'
current instr.: 'tcl;Partcl;Actions;index:sym<m-n>' pc 31117 (src/Partcl/Actions
.pir:1843)
... but occasionally this one:
bad index "1+1": must be integer?[+-]integer? or end?[+-]integer?
current instr.: '_block1007' pc 31916 (src/Partcl/Actions.pir:2154)
pmichaud pulling 04:22
token index:sym<m+n> { $<a=.integer> '+' $<b=.integer> }
Coke (each fails a different test in t/cmd_string.t) I am assuming a LTM issue plus hash randomization.
pmichaud no $'s
it's just <a=.integer> and <b=.integer>
Coke ok, trying that...
still getting the 1+1 failure, but now alternating with: 04:23
running the test to completion.l 04:24
dalek rtcl-nqp: e2a0b30 | coke++ | src/TclString.pm:
negative result from the Action means "length from end".
rtcl-nqp: d0afb4b | coke++ | src/Partcl/commands/string.pm:
fix [string last], pass all tests.
rtcl-nqp: 4e5d192 | coke++ | src/ (3 files):
first pass at [string index] - change action logic for index.

to beginning or end. (Allows for over/under on index spec.)
pmichaud what happens if passed an index that doesn't match any of the protoregex patterns? 04:28
e.g., as in the 'joe' case?
Coke those tests seem to be working.
(they throw the appropriate error)
pmichaud oh, yes, it's likely to be a ltm issue here
Coke any way I can force the issue? 04:29
pmichaud yes
Coke aside from ditching the proto and hand_ordering?
pmichaud change index:sym<int> to index:sym<integer>
purl pmichaud: that doesn't look right
pmichaud the longer name will cause it to be attempted last
or, combine the three integer cases into a single one 04:30
dalek rtcl-nqp: c60d4cf | coke++ | src/Partcl/Grammar.pm:
don't need the $'s.
rtcl-nqp: 598e336 | coke++ | src/Partcl/commands/string.pm:
First pass at [string length]
pmichaud e.g.: index:sym<int> { <a=.integer> [ <[+\\-]> <b=.integer> ]? }
Coke I'll do the combination. 04:31
the first suggestion didn't seem to have an effect.
pmichaud (you might have needed to update actions to be index:sym<integer> also?)
Coke did that.
pmichaud okay, I don't know then 04:32
combining them will definitely work, though, and be more efficient anyway
oh, you'll need to capture the sign
so
e.g.: index:sym<int> { <a=.integer> [ $<op>=[<[+\\-]>[ <b=.integer> ]? }
er
e.g.: index:sym<int> { <a=.integer> [ $<op>=[<[+\\-]>] <b=.integer> ]? }
or 04:33
e.g.: index:sym<int> { <a=.integer> [ $<op>=['+' | '-'] <b=.integer> ]? }
Coke is there a defined op in NQP ?
pmichaud currently it's just pir::defined
Coke k
pmichaud pir::defined($val)
eventually it'll be defined $val
but in this case note that $<op> and $<b> will end up being arrays 04:34
(because of the ? quantifier)
so you can just do if $<op> { ... }
and ~$<op>[0] will have the operator, and $<b>[0].ast will have the second integer 04:35
Coke yup, that seems to avoid the random failure mode. 04:41
... at this point, seems prudent to just remove the proto. =-) 04:46
pmichaud well, the proto will definitely help in the 'end' cases
04:47 lucian joined
dalek rtcl-nqp: 89eca8a | coke++ | src/Partcl/ (2 files):
avoid LTM issue with the index proto; simplify end rules slightly.
 04:52
darbelo pokes dalek. 04:53
cotto pokes darbelo for no apparent reason 04:55
dalek rrot: r43118 | darbelo++ | branches/pmc_freeze_cleanup/src/pmc_freeze.c:
Fix the segfault in examples/benchmarks/freeze.pasm by ensuring that aggregates with no elements still get some space allocated at buffer creation.
darbelo cotto: Did I fail to report something? 04:56
;)
Coke if $<op> { } doesn't seem to be triggering., 04:57
pmichaud could try +$<op> > 0 (but that really shouldn't be needed) 04:58
Coke ah, I spelled it differnetly than you suggested in teh grammar. fixing... 04:59
(I had done <op=>, incorrectly aping the <a=.integer> 05:00
dukeleto just fought a git beast and won
darbelo git beast?
pmichaud seems like <op=> ought to produce a compile time error
I need to fix that.
05:01 bacek joined
dukeleto bacek: o hai 05:01
pmichaud hmmm... my subs with :immediate flags don't seem to be converting into the thing they return
Coke you need .const for that magic to work, I think. 05:02
pmichaud I am using .const
let's see if I can make a small test case
Coke hurm. I am currently using that in partcl; e.g. runtime/builtins/string.pir 05:03
(if you want to see a working example)
pmichaud I'm trying out chromatic's constant exception handlers
dalek rtcl-nqp: 25dd2f4 | coke++ | src/Partcl/Grammar.pm:
Fix index rules with integer +/- : was using incorrect syntax to capture $<op>
 05:04
cotto darbelo and/or plobsing_, how big are the freeze/thaw changes you both are working on? 05:08
Will the branch instantly make freeze/thaw sane or is it step 1 of 30?
darbelo The branch will make freeze/thaw as sane as we can make it without breaking the deprecation policy. 05:09
cotto I imagine you'll have a nice long list of changes to make as soon as 2.0 is cut. 05:10
darbelo svn rm the file.
plobsing_ +1
purl 1
darbelo After that, we can start a new, sane file. 05:11
cotto Don't forget to add a deprecation notice.
dalek rrot: r43119 | plobsing++ | branches/pmc_freeze_cleanup (4 files):
remove unused visit actions VISIT_FREEZE_SIZE, VISIT_CLONE, VISIT_DESTRUCTION_ORDER
 05:12
rrot: r43120 | dukeleto++ | trunk/tools/util/pgegrep:
[cage] Fix pgegrep, which was merely an innocent bystander in the Great Namespace Wars
darbelo It's already there. I think I added it two releases ago or thereabouts.
plobsing_ trunk or branch?
cotto Add another. It can't hurt. ;) 05:14
darbelo plobsing_: I made it in trunk some time back, but mentioned the wrong struct. I fixed that, again in trunk, some days back.
plobsing_: unless you weren't asking about the deprecation notice... 05:16
plobsing_ darbelo: just read it. looks good. 05:18
about having to change PMCs after the change, with any luck we can have a new API in place parallel the old busted one 05:19
cotto That'd be ideal. 05:20
plobsing_ trying to find wording that makes the change sound a bit less abrupt
cotto As much as we love old 'n' busted, it's currently functional.
darbelo plobsing_: Yeah, but the VTABLE_freeze() signature will have to change. There's no way around that. 05:21
I agree that 2.0 should ship with as much of the new interface in place as we can manage, but there *will* be incompatibilities. 05:22
plobsing_ oh? #define visit_info PMC
doesn't that do it?
darbelo That won't work for people that were accsesing the actual image inside visit_info with '->' 05:23
plobsing_ I'm trying to eliminate places where that happens 05:24
providing alternatives
Coke pmichaud: every several dozen 'make test' runs, I get something like: 05:26
# got : 'STRING: 12799 microseconds per iteration' 05:27
darbelo Sure, but we can't fix code we don't have access to. The deprecation policy is there to protect the darkpan.
Coke # expected : 'REGEXP: [0-9]+ microseconds per iteration'
dalek rtcl-nqp: d0309c8 | coke++ | build/PARROT_REVISION:
fix typo in parrot revision
rtcl-nqp: 41d0c32 | coke++ | (3 files):
Add stub [interp]
rtcl-nqp: b337c16 | coke++ | src/Partcl/commands/info.pm:
improve stub for [info exists]
rtcl-nqp: c6f74ae | coke++ | src/init.pm:
Pull in parrot's config hash, we'll need it to setup more globals...
pmichaud Coke: odd. I wonder if it's a -G bug.
darbelo plobsing_: Look at the Getopt::Obj mess, it's a trivial change, but we can't make it if it breaks other people's code. 05:28
That's also the reason behind line 72 in include/parrot/pmc_freeze.h 05:29
Coke this break error is weird. something is eating my break exception. 05:33
when Partcl.Compiler.compile() creates an invokable object, does it eat CONTROL exceptions? 05:34
pmichaud it might 05:37
can't say for sure... exception handling is really weird overall
msg chromatic your comments and/or analysis on TT #1374 would be helpful 05:38
purl Message for chromatic stored.
Coke ok. that isa HLL::Compiler isa PCT::HLLCompiler... 05:39
pmichaud compilers/pct/src/PCT/HLLCompiler.pir
(in parrot repo)
Coke yah. so, 'compile' there, which then dispatches... 05:40
dukeleto the namespace wars broke Tapir as well. so many bloody bodies 05:41
pmichaud I can't see anywhere that HLL::Compiler or PCT::HLLCompiler would be catching exceptions
(they do catch some exceptions on transcoding operations, but those handlers are removed before doing the actual parsing step) 05:42
Coke pmichaud: k. it was the most obvious place I could posit where those break exceptions were vanishing. 05:43
(first test in t/cmd_break.t is failing because the exception is eaten inside the for{} body.
(so the loop runs to the end.)
05:44 urigard joined
Coke I'm exhausted, though. and will call the index updates a major victory. Thanks for your help/patches. 05:44
pmichaud my pleasure
excellent work
dalek rrot: r43121 | plobsing++ | trunk/DEPRECATED.pod:
change wording on freeze/thaw deprecation to highlight interim API
purl dalek: that doesn't look right
rrot: r43122 | plobsing++ | branches/pmc_freeze_cleanup (2 files):
add VISIT_PMC_ATTR macro to visit an attribute easily
pmichaud I was working on being able to have constant return exception handler pmcs, but that didn't work out. :immediate subs seem not to be so immediate in NQP for some reason. 05:45
i.e., they aren't being converted to constants in the .pbc -- they're remaining as Sub PMC objects.
Coke hurm. I'd have to look at the generated pir.
(I would try wrapping it in an INIT block)
ugh. zzzzzzzzzzzzzzzzzzzzz 05:46
pmichaud ...INIT block?
INIT blocks translate to :load :init, not :immediate
Coke Was trying to think of a way to get it to dump to PIR sooner. also, zzz. 05:47
pmichaud ah
anyway, zzz here also
dalek TT #1374 created by pmichaud++: :immediate semantics have changed 05:50
cotto Is there any likelihood that we'll care about dynamically registering new kinds of PackFile segments? There's an old TODO by leo to that effect in src/packfile.c. 06:04
06:05 abqar joined
cotto trac.parrot.org/parrot/browser/trun...2917#L1441 06:05
darbelo I sincerely doubt it. Not enough people undarstand that code enough to care about improving it. 06:06
cotto So far it doesn't look that bad.
I'll clobber it. A random TODO won't have any effect and if we need it we can implement it. 06:07
plobsing_ thats not about segments I don't hink 06:08
s/hink/think/
darbelo cotto: He's not bad, just misunderstood ;)
plobsing_ nm 06:09
darbelo The only one I've seen make changes to that code is bacek, and he's a magical coding robot.
cotto and I can clean up a header while I'm in there 06:14
darbelo Hm, looks like the segfault wasn't gone. Just hidden. 06:15
But I have to sleep now. 06:16
cotto night
darbelo collapses
dalek rrot: r43123 | plobsing++ | branches/pmc_freeze_cleanup/src/pmc_freeze.c:
eliminate logical || with non-zero constant warning
 06:17
dukeleto the differrences between :load, :init and :immediate seem to have scary black magic when stored in PBC's 06:19
dalek pir: bb85fd7 | dukeleto++ | (2 files):
Update TODO and .gitignore
pir: 81de7fc | dukeleto++ | t/harness.pir:
Fix our use of Getopt::Obj, which changed in the Great Namespace War
Tene dukeleto: it got put back to how it was before.
oh, you're going back. 06:21
It'll go back again, um, someday, I guess.
dukeleto Tene: it is nice to have a passing test suite 06:22
dalek TT #1373 closed by dukeleto++: ./t/tools/pgegrep.t: New failures 06:23
dukeleto pmichaud: we should really have some tests for that :immediate business. that is kind of scary.
06:29 bacek joined
chromatic I made all of the :immediate tests we have in the repo work. 06:32
It's a giant jungle of mess though: not just the code, but also the semantics.
dalek rrot: r43124 | cotto++ | trunk (2 files):
[packfile] some header cleanup and removal of a decrepit and unlikely TODO
 06:33
cotto We don't have opcodes that can take a variable number of arguments, do we? From what I can tell, a given opcode number takes a known constant number of arguments.
chromatic Right. 06:34
cotto OK. The pdd needs fixing then.
0x1d1 + 1 06:35
1+1
purl 2
cotto 1+0x1
1+0h1 06:36
1+purlisstupid
chromatic Once upon a time there were variadic opcodes I think, but I think they went away after the big MMD change. 06:39
cotto It's good to know that the docs are simply out-of-date instead of purposefully deceptive. 06:40
chromatic There's very little intentional malice in our docs. 06:41
cotto "There are hardly any mines in our back yard." 06:42
Tene Okay, I have a patch for Getopt::Obj that doesn't break existing uses.
dalek TT #1375 created by jimmy++: [patch]changed class.pmc to use GET_ATTR syntax 06:55
dukeleto Tene: where? 06:56
nopaste "tene" at 24.10.252.130 pasted "Here, dukeleto" (321 lines) at nopaste.snit.ch/19124 06:57
Tene dukeleto: It doesn't seem to actually be usable from HLLs, though, so I'm trying to track that down first. 06:58
Dunno if it's a failure in rakudo or in parrot or in G::O or whatever
dukeleto Tene: um, that undoes my most recent patch 06:59
Tene: have you run the test suite on that patch?
Tene dukeleto: I ran t/library/getopt_obj.t, which passed.
Both before and after the patch.
I'm running 'make test' now anyway. 07:00
dukeleto Tene: um, you should run "make test" but prove -v t/tools/pgegrep.t will fail on your patch
Tene dukeleto: I get "all tests successful"
dukeleto Tene: something is up 07:02
nopaste "tene" at 24.10.252.130 pasted "prove -v t/tools/pgegrep.t" (19 lines) at nopaste.snit.ch/19125 07:04
cotto chuckles at old docs that mention "v-table methods". 07:05
Tene Oh, things are failing because nqp-rx's HLL::Compiler registers itself as the 'parrot' compiler, so existing HLLs don't load languages/parrot/parrot.pbc, and they also haven't been migrated over to using HLL::Compiler's new interface. 07:07
Tene re-starts 'make test' 07:08
dukeleto Tene: i am running your patch on my machine now 07:09
Tene dukeleto: can you explain why you expected pgegrep.t to fail? does it fail for you with that patch?
dukeleto Tene: pgegrep was failing in trunk 07:10
Tene: are we in the same universe?
Tene dukeleto: that patch leave Getopts::Obj in its old namespace, but *also* installs the classes in the appropriate namespaces. 07:11
cotto pdd 13 has some dust on it, but it's not too bad. 07:12
dukeleto Tene: yes, your most recent patch passes on my machine. go for it 07:13
Tene: i didn't realize you put them in both
Tene dukeleto: I've suddenly been kicked offline. My cable modem refuses to give out an address. So, maybe I can commit tomorrow. 07:20
cotto nqp-rx.pbc makes pbc_dump act oddly. 07:22
stupid need for sleep 07:24
dukeleto Tene: you want me to commit? 07:27
Tene it's not like it's an urgent patch. If you want it in, go ahead. 07:31
07:31 nopaste joined 07:34 he joined, szg joined 07:36 szg joined
dukeleto Tene: it is all yours :) 07:37
cotto Goodie. PBC is documented in pdd13 and in docs/parrotbyte.pod 07:41
This is more than would be wise to attempt in a night. It's sleeping time.
moritz good night cotto 07:42
cotto chromatic, is there any reason we need both docs/parrotbyte and pdd13? I'm thinking that it'd be a good idea to merge whatever's unique into the pdd and nuke parrotbyte.pod. 07:43
(I'm going to bed, but I'll check the backscroll.)
chromatic Merge away.
07:44 szabgabx joined 07:46 nopaste joined
dalek rrot: r43125 | cotto++ | trunk/docs/pdds/pdd13_bytecode.pod:
[pdd] update pdd13, mostly deleting obsolete information and improving formatting and clarity
 07:54
07:56 iblechbot joined 08:03 bacek joined
dalek tracwiki: v10 | cotto++ | CottoTasklist 08:06
tracwiki: trac.parrot.org/parrot/wiki/CottoTa...ction=diff
chromatic aha 08:20
JimmyZ what? 08:25
chromatic I fixed t/op/debuginfo.t on the context_unify3 branch. 08:26
JimmyZ chromatic++ 08:29
chromatic Two more test files have failures. 08:30
Three failing tests.
08:33 TonyC joined
JimmyZ X-D 08:34
0042 test 08:35
1 test
13 test
08:42 fperrad joined
dalek rrot: r43126 | chromatic++ | branches/context_unify3/src/call/args.c:
[PCC] Ensured that the current context of a tailcall has a CallContext PMC;
 08:42
rrot: r43127 | chromatic++ | branches/context_unify3/src/pmc/null.pmc:
[PMC] Added a specific invoke() VTABLE entry for Null PMC to pop the context

number for the backtrace caused by the exception thrown from invoking a Null PMC.
rrot: r43128 | chromatic++ | branches/context_unify3/src/debug.c:
[PDB] Tidied code in PDB_backtrace(); no functional changes.
08:43 fperrad_ joined
dalek pir: 38d7b56 | dukeleto++ | t/harness.pir:
Add a --help command line argument and print it out when given no arguments as well
 08:48
chromatic ... and there's a fix. 09:04
Unfortunately, it causes one test failure.
JimmyZ chromatic: I had uploaded class.pmc patch, a big patch. 09:05
09:09 payload joined
chromatic KABOOM! 09:14
dalek pir: 02fdb6c | dukeleto++ | metadata/tapir.json:
Add a Plumage metadata file for Tapir, generated with 'parrot setup.pir plumage'
 09:16
chromatic You're all going to like this one. 09:17
JimmyZ oh, esoteric codes appears in another place again. 09:19
chromatic It was already esoteric. 09:20
From the figurative mountains of madness.
My first attempt to fix that problem led me to IMCC's PBC generating code, and I had a moment where I had to think "If I do this *that* way, how will it interact with the GC?" 09:21
dalek rrot-plumage: 24d8c96 | leto++ | metadata/tapir.json:
[METADATA] Add metadata for Tapir
chromatic It's like a triple-double in basketball.
You get to mess with calling conventions, IMCC, PBC storage, lexicals, NCI, the IMCC->PIR->IMCC boundary, and the garbage collector all at once. 09:22
moritz "patch of everything" 09:23
JimmyZ o_O
where does 09:26
where is CONST_STRING defined?
chromatic tools/build/c2str.pl 09:27
09:28 UltraDM joined
dalek rrot: r43129 | chromatic++ | branches/context_unify3 (4 files):
[PMC] Set the current sub of NCI calls to the parent sub, so that calls into

set_outer() method to ignore the NCI calling context when attaching the correct context to another Sub PMC. If that sounds esoteric, be glad that bacek and I know what it means, and that we have a test which catches it.
  (Roll on Lorito to make this all go away.)		 09:31
chromatic msg bacek context_unify3 passes all of its tests. 09:32
purl Message for bacek stored.
chromatic msg whiteknight context_unify3 passes all of its tests.
purl Message for whiteknight stored.
chromatic Hm, and that's the fastest I've ever seen coretest run. 09:33
Oops, no... t/library/streams.t has one. 09:34
JimmyZ seems that the second args in CONST_STRING is not used
Do I understand correctly? 09:35
chromatic There are only two arguments.
JimmyZ the second args in CONST_STRING is not used?
chromatic tools/build/c2str.pl processes files with CONST_STRING and writes filename.str, which defines the CONST_STRING macro. 09:36
JimmyZ I see it's #define CONST_STRING(i, s) _CONST_STRING(i, __LINE__)
09:37 mj41 joined
chromatic Yes. 09:38
JimmyZ I don't know where s arg is used?
chromatic Later in the .str file. 09:39
Hm, the context_unify3 branch creates twice as many RetContinuations as trunk.
JimmyZ chromatic: I couldn't find. 09:41
chromatic #define _CONST_STRING_14128 737
This means that the CONST_STRING on line 14128 is the constant string #737 in all_cstring.str. 09:42
c2str.pl also writes all of the s from CONST_STRING(i, s) into a single file which becomes an array in the interpreter.
JimmyZ them I think #define CONST_STRING(i) _CONST_STRING(i, __LINE__) is right too.
chromatic ... except that the preprocessor, c2str.pl, won't write anything to all_cstring.str 09:43
msg bacek Do we need to create a RetCont in the callmethodcc op? That's wiping out any performance gains. 09:44
purl Message for bacek stored.
JimmyZ I see many places use like CONST_STRING(interp, "ExceptionHandler"); what does 'ExceptionHandler' translate to? 09:46
chromatic see all_cstring.str
JimmyZ oh, it's there. 09:47
09:47 rhr joined
chromatic msg bacek Wait, I could be reading that wrong.... 09:50
purl Message for bacek stored.
10:02 fperrad joined
JimmyZ Does parrot need to change Context/CallContext to subclassable? 10:09
chromatic I don't know. 10:10
msg bacek Found the reason and pushed it in r43130; it's a bit of a hack we need to address in a better way. 10:20
purl Message for bacek stored.
dalek rrot: r43130 | chromatic++ | branches/context_unify3/src/ops/object.ops:
[ops] Made callmethodcc op skip creating a RetContinuation when invoking an NCI

the invokee's responsibility to create the RetCont. This improves branch performance by 2.499% on fib4.pir.
chromatic sleeps 10:21
JimmyZ good night 10:23
dalek rrot: r43131 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] when parrot-tapir is available, use it instead of prove
 10:37
10:41 bacek joined 11:21 estrabd joined
dalek rrot: r43132 | mikehh++ | trunk/docs/pdds/pdd13_bytecode.pod:
fix codetest failure - docs/pdds/pdd13_bytecode.pod - max pod linelength is 78 (plus some trailing spaces)
 11:25
mikehh my editor (kate) is set to remove trailing spaces and did so in the above commit - the file was not tested for trailing spaces 11:28
the test t/codingstd/trailing_space.t misses a lot of files that it should test 11:30
Infinoid I've heard that mentioned at least once before. Patches are still welcome :) 11:38
mikehh looking into it :-}
12:31 lucian joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31006), fulltest) at r43132 - Ubuntu 9.10 i386 (gcc) 12:33
All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31011), fulltest) at r43132 - Ubuntu 9.10 i386 (g++) 12:41
12:42 lucian joined 12:49 lucian joined 12:54 patspam joined
Coke AIGH 12:57
mikehh that sounds ominous 12:59
Coke tene, pmichaud ; my break issues are likely because "our sub if()" is implemented with an NQP while loop. 13:00
Coke tries to figure out how to say please don't bother catching that, but let it go.
moritz context_unify3 make test just fails one test 13:01
t/library/streams.t test 12 13:02
13:02 JimmyZ joined 13:04 Patterner joined
moritz /pmc/object-meths.t test 15 in 'make testg' 13:05
13:10 whiteknight joined
whiteknight good morning, #parrot 13:10
JimmyZ good moring, whiteknight 13:11
whiteknight chromatic++, bacek++ 13:12
(context_unify3 passing tests)
JimmyZ whiteknight: ?
whiteknight JimmyZ: Did you get a commit bit yet?
JimmyZ whiteknight?
purl hmmm... whiteknight is mailto:wknight8111@gmail.com or the grand master funk or wknight8111.blogspot.com/
JimmyZ whiteknight: hadn't, I couldn't find a scanner here.
whiteknight ah, okay. I had that problem too 13:13
I ended up mailing a hard copy
JimmyZ whiteknight: It's really hard to visit your blog. I couldn't get a proxy. 13:14
:)
whiteknight ah right, you had mentioned that before
so what can I do to help?
Coke JimmyZ: he's aggregated on planet.parrotcode.org, if that helps. 13:15
13:15 payload joined
whiteknight Coke: not everything gets aggregated there, only the stuff labled with "parrot" is 13:15
of course, the rest of it isn't so interesting :)
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31012), fulltest) at r43132 - Ubuntu 9.10 i386 (g++ with --optimize)
JimmyZ Coke: good 13:17
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31013), fulltest) at r43132 - Ubuntu 9.10 i386 (gcc with --optimize)
13:20 patspam joined
mikehh context_unify3 branch - same result as moritz++ above 13:31
context_unify3 branch - make test fails 1 test - t/library/streams.t - Failed test: 12 - Ubuntu 9.10 i386 (gcc with --optimize) 13:32
whiteknight mikehh: I resolved that test failure last night by doing touch src/dynpmc/*, make clean, make 13:33
it might be a makefile dependency issue, if I'm correct
pmichaud good morning, #parrot 13:36
whiteknight good morning, pmichaud
pmichaud 13:00 <Coke> tene, pmichaud ; my break issues are likely because "our sub if()" is implemented with an NQP while loop.
interesting.
Coke pmichaud: sent you an email with more details. 13:39
pmichaud Coke: yes, got it.
Coke ETOOMUCHDOGFOOD 13:40
pmichaud you've undoubtedly found the problem. I'm not quite sure how to resolve it at the moment.
might just do the loop in PIR 13:41
I think I'll try that. 13:43
Coke if I had goto and labels, I could handroll it and still be nqp. =-)
but yah, pir is probably the simplist out.
pmichaud yeah.... but goto itself requires control exceptions
(not *this* control exception, but it does require some) 13:44
Coke switch will require similar treatment.
dalek TT #1376 created by fperrad++: [NQP-rx] cannot support an empty string as token
TT #1098 closed by fperrad++: [CAGE] rename parrot_nqp to parrot-nqp
TT #853 closed by fperrad++: Can't load OpenGL
Coke (and possibly time) 13:45
pmichaud yes, time needs it also
hrm.
13:46 Patterner joined
pmichaud looks like 'switch' forces a 'last' after an eval anyway, though? 13:46
nopaste "mikehh" at 81.149.189.7 pasted "context_unify3 branch - fulltest failures" (64 lines) at nopaste.snit.ch/19126 13:49
pmichaud has a patch for if() 13:55
testing now
13:56 jan joined
whiteknight mikehh: you're right. t/library/streams.t does fail 14:04
dalek kudo/master: b01665b | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 449 files, 32192 (86.1% of 37376) pass

primarily represent changes to the spectest suite as opposed to regressions.		 14:07
purl regressions are always confusing...
kudo/master: 39685ac | pmichaud++ | docs/announce/2009-12:
More documentation updates.
Coke pmichaud: that last is just meant to be internal to that while loop, and isn't part of the control flow of the app. 14:13
pmichaud ah, good point. 14:20
Coke pmichaud: ok. I have something that passes a few tests in t/cmd_break.t now. 14:27
nopaste "coke" at 193.200.132.135 pasted "avoid while in if()" (47 lines) at nopaste.snit.ch/19127 14:28
pmichaud I just pushed my patch for if()
Coke excellent, will revet.
I like yours better anyway. 14:29
dalek rtcl-nqp: 5617db1 | pmichaud++ | src/Partcl/commands/main.pm:
Refactor if() so that it doesn't use nqp's while statement,

to catch.
Coke the remaining failures in t/cmd_break.t are fixable by causing the subs generated by proc to catch continue and break and complain about it. 14:32
:q 14:33
ww
14:33 bluescreen joined
Coke looks like [continue] is really generating a REDO. 14:35
(or it's being interpreted as a redo)
14:35 mariano__ joined
Coke yah. looks like a bug in nqp - I'm generating a 65, but the loop is just repeating over and over at that point. 14:36
... damnit. cannot reproduce. 14:42
dalek rrot: r43133 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] some refactor
 14:44
Coke aha. there we go. 14:48
nopaste "coke" at 193.200.132.135 pasted "shows the continue bug in NQP" (12 lines) at nopaste.snit.ch/19128
Coke pmichaud: that should print out a few dozen lines and quit, but goes into an infinite loop. 14:49
(repeating with FOO: 6\\nCONT)
pmichaud it's being caught by the while 14:50
Coke Yes, but wrongly.
pmichaud well, I'm not sure that's a bug in nqp, though.
Coke that is, it's an excpetion that should be caught and dealt with.
but CONTINUE doesn't mean REDO
pmichaud it's not redo
Coke it is redoing, though.
pmichaud we never get to the $a++
Coke AH.
ok. so there's a bug in our implementation of for. I can fix that. 14:51
pmichaud++
(have to put in a CONTROL override to handle "next" so our "incr" logic is run. 14:54
14:57 davidfetter joined 15:01 whiteknight_ joined 15:02 lucian joined
Coke pmichaud: fixed. thanks for the diagnosis. 15:08
I would have stared at that for another hour. =-)
for loops now work with break -and- continue.
dalek rtcl-nqp: 887571a | coke++ | src/Partcl/commands/main.pm:
Fix usage args for [break]
 15:11
rtcl-nqp: 4c9273d | coke++ | src/Partcl/commands/string.pm:
implement [string repeat]
rtcl-nqp: 033f0ff | pmichaud++ | src/Partcl/commands/main.pm:
Refactor if() so that it doesn't use nqp's while statement,

to catch.
rtcl-nqp: 9fcf4a5 | coke++ | src/Partcl/commands/main.pm:
when [for] loop gets a [continue], we still must process our 'next' arg.
rtcl-nqp: de0ecae | coke++ | src/Partcl/commands/main.pm:
Merge branch 'master' of github.com:partcl/partcl-nqp
15:32 davidfetter joined 15:36 Psyche^ joined
dalek nxed: r273 | julian.notfound++ | trunk/winxedst1.winxed:
operator || in stage 1
 15:42
15:51 patspam joined 16:02 theory joined
cotto_work good mooring 16:03
dalek p-rx: 9652695 | pmichaud++ | (3 files):
Fix empty string in regexes (TT #1376, fperrad++).
 16:12
p-rx: 17492b7 | pmichaud++ | src/stage0/ (4 files):
Update bootstrap.
rrot: r43134 | pmichaud++ | trunk/ext/nqp-rx/src/stage0 (4 files):
[nqp]: Update nqp with fix for TT #1376 (fperrad++)
 16:23
TT #1376 closed by pmichaud++: [NQP-rx] cannot support an empty string as token 16:33
Coke pmichaud: so if I wanted to make a glob compiler for partcl, I'd probably start by copying ARE and then gutting it. 16:42
but looking at it, I see nibbler & termish... I'm not sure what those are for or if I'd need them for globbing. can you enlighten me? 16:44
(atom and quantifier make sense to me.) 16:45
16:47 brianwisti joined 16:58 whiteknight joined 17:16 darbelo joined, iblechbot joined 17:39 mikehh joined 17:41 chromatic joined
pmichaud Coke: nibbler and termish have their roots in the regex parser for the p6 grammar. I suspect that a glob compiler wouldn't need to copy that part so directly 18:01
(p6's regex parsing overlays onto the operator precedence parser... I'm hoping to come up with a slightly saner way to achieve the same thing)
TimToady p6's regex parsing has to stay as extensible as the rest of the language, hence the insanity 18:03
pmichaud sure, but I'm thinking a slightly different approach besides termish/nibbler :-)
anyway, you can veto whatever I come up with :)
Coke ok. so, given that, I think I can come up with something globby. 18:04
pmichaud the biggest thing to remember is that in globs, the * and ? aren't quantifiers, they're metachars 18:05
Coke yup 18:06
I was more concerned about the whole 'implementing in nqp" bit. =-)
pmichaud ah
Tene the * and ? issue is a common struggle for students when i teach regular expressions. 18:08
Coke pmichaud: can I also avoid buildsub? 18:09
pmichaud I think you'll still need buildsub
Coke ok.
pmichaud looking.
oh, maybe not 18:10
you need something that does the equivalent of buildsub
I've been thinking it should be provided by HLL::Actions, though -- haven't gotten that far yet.
I forget why I re-listed it in ARE
dalek rrot: r43135 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] first attempt of spec rpm
 18:18
rrot: r43136 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] stores plumage description in a file
18:26 theory joined 18:28 etworks joined
etworks quick question: would Parrot be a good platform for implementing an array-oriented language (like APL, J, K/Q, Nial, IDL, etc)? 18:28
would it be easy to implement "array comprehensions", e.g. 9 9 9 = 1 2 3 + 8 7 6 18:29
darbelo There was an "APL on parrot" some time back. 18:30
paraplegic?
or something like that...
cotto_work sounds right 18:31
etworks was there?
interesting, let me ask google
(and I thought I was so orriginal)
darbelo code.google.com/p/paraplegic/
cotto_work code.google.com/p/paraplegic/
darbelo second result for "paraplegic parrot" ;)
cotto_work I went to trac.parrot.org/parrot/wiki/Languages 18:32
etworks well, that answers my question. thanks guys. I'll see if I can write a J interpreter on Parrot.
cotto_work etworks, there's a new tool in active development called nqp-rx that will be the recommended way to develop a Parrot-hosted language. Take a look at github.com/partcl/partcl-nqp for a language that the author of nqp-rx (pmichaud) is helping to develop. 18:34
etworks ew, Tcl 18:35
cotto_work there's also the ng branch of rakudo, but it's not finished yet (though it's passing a large chunk of the Perl 6 test suite). 18:36
etworks but I guess I should use best practices....
darbelo paraplegic is, amusingly, being not-developed by the same two people ;)
cotto_work etworks, feel free to hang out here and take copious notes about what needs to be documented about nqp-rx.
etworks well spun sir, well spun. 18:37
hmm, maybe Rakudo is a good way for me to learn Perl6 and Parrot simultaneously.... I've been itching for P6 for a few years 18:38
cotto_work There's also winxed, which is C++ code that generates PIR independently of any Parrot tools.
Coke I'd offer you a commit bit on partcl-nqp if you weren't such a hater. =-) 18:39
cotto_work Perl 6 is pretty sweet. I'd recommend the advent calendar if you want to get started.
etworks what's the advent calendar?
purl hmmm... the advent calendar is dev.catalyst.perl.org/wiki/adventca...ararticles
cotto_work perl6advent.wordpress.com/
perl 6 advent calendar is perl6advent.wordpress.com/ 18:40
etworks Coke: I'm not a hater, per se. I've just been ruined by languages that let me be lazy (e.g. Perl)
oh, that's neat. 18:41
are the Perl6 grammar things pretty much code-complete? I coudl get my feet wet by just writing the J grammar .... or wait, does it have to be context-free? 18:44
Tene There's also github.com/tene/steme/ my scheme compiler written using nqp-rx 18:45
etworks I really don't know Tcl well, so I would have a long road to lear nqp-rx 18:48
dukeleto brianwisti: welcome to our corner of the interwebs!
etworks: what do you mean "code-complete" ? 18:49
etworks dependable, unlikely to change their syntax, more or less robust
dukeleto etworks: Perl 6 grammars are implemented and function quite well, if that is what you mean
cotto_work etworks, nqp (and nqp-rx) is based on Perl 6 so there'll be some overlap. Looking at nqp-rx's tests will also help you get a feel for the language.
etworks that's exactly what I mean
dukeleto etworks: you want to learn about nqp-rx, then
etworks: it gets installed as parrot-nqp with parrot
brianwisti dukeleto: thanks, great to lurk here.
dukeleto brianwisti: you will find the people here pleasant and helpful, except purl 18:50
purl, die in a fire
purl HALP
etworks maybe I'm confused ... what is nqp's purpose?
dukeleto etworks: it is an easy to parse subset of Perl 6 that Parrot and Rakudo use to get shit done
dalek rrot: r43137 | mikehh++ | trunk/runtime/parrot/library/distutils.pir:
fix codetest failure - pod syntax in runtime/parrot/library/distutils.pir
brianwisti etworks: Dunno about purpose as such, but I'm using it to 1) define grammars; and 2) script simple tasks. 18:51
Coke why nqp is use.perl.org/~pmichaud/journal/34974
etworks oh, ok
Coke (that refers to the old version of nqp but is still valid) 18:52
etworks I was just confused -- this does look useful for my needs
cotto_work www.searchviews.com/wp-content/them...rests1.jpg
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31025), fulltest) at r43137 - Ubuntu 9.10 amd64 (g++ with --optimize) 19:01
etworks should I have any particular expectations about array-processing performance in parrot? I know P6 plans some hyperoperators that are very close to some APL/J concepts, so maybe array processing has been given some attention/tuning? 19:06
chromatic Not a lot. 19:07
purl Not a lot. are you still in hong kong?
dukeleto etworks: we have benchmark scripts for array processing. what exactly are you interested in knowing about? 19:14
etworks whether I can/should expect an (almost exclusively) array-oriented language to perform well when hosted by parrot 19:16
or whether parrot is targetted towards more "standard", scalar-oriented (i.e. von Neumann type) languages 19:17
dukeleto etworks: parrot aims to support all dynamic languages 19:18
etworks: if you find something you need, tell us
etworks I undetstand, but usually "maintain generality" means "lower performance for niche markets", and array-orientation is niche....
dukeleto etworks: do you know about our language skeleton creation script? 19:19
etworks nope, I know ~0 about Parrot
particle etworks: the abstract data type in parrot is called a PMC. the pmc defines a data storage mechanism and api.
dukeleto etworks: tools/dev/mk_language_shell.pl will make a lang skeleton for you, using nqp-rx 19:20
particle the internals of the pmc are opaque
dukeleto etworks: PMC = PolyMorphic Class or Parrot Magic Cookie
particle so, there are some PMCs, like 'Integer', that only deal with integers
and ResizablePMCArray, which is an array type that stores other PMCs 19:21
dukeleto etworks: you probably want to know about FixedPMCArray and ResizablePMCArray
etworks yep, that's the kind of thing I'm looking for
I guess, where do I get started?
dukeleto etworks: FPA's are much faster than RPA's, since the length is fixed and fewer shenanigans can happen 19:22
etworks with the advent calendar?
particle as it stands now, none of the array-type PMCs deal with sparse arrays, or have many optimizations.
dukeleto etworks: perl tools/dev/mk_language_shell.pl mylangname
etworks yeah, but I definitely need RPAs
I don't need sparse arrays to begin ... we haven't even got that right in J yet
dukeleto particle: parrot-linear-algebra may have some kind of sparse array type, or it will soon
particle right, that's the other thing... if our core PMCs don't turn you on, write your own 19:23
etworks for now this is a proof of concept
I was just trying to set my expectations, not making any requests
particle aye.
i'm trying to help set your expectations.
by the way, nqp allows you to write top-down, shift-reduce, and custom parsers, and they can all call each other 19:25
i don't foresee any problems in writing the J grammar with nqp
etworks FYI, the J grammar is not context-free 19:27
but I can live with a starter kit that is 19:28
Tene non-context-free is not a problem at all. 19:31
etworks good news!
what version of Perl should I use to run Parrot?
and I'm on Windows/Cygwin if that matters
Tene Parrot doesn't run on Perl.
oh, do you mean the Configure script? 19:32
etworks e PMCs don't turn you on, write your own
dukeleto etworks: perl 5
etworks perl tools/dev/mk_language_shell.pl mylangname
Tene Yes, that's Perl 5.
etworks any perl 5? not like 5.10 or whatever?
dukeleto etworks: any version of perl 5 from this century should work
chromatic You need at least 5.8.6 or better.
etworks there we go.
that I can do.
oh `make', how I hate you 19:38
ok, I'm getting Unrecognized line: 'inline op end(), which according to the IRC logs means I have the wrong line endings 19:41
I just downloaded a fresh stable Parrot, unzipped, opened a cygwin shell, Configure.pl'd, and make'd. 19:42
Coke how did you download? 19:43
etworks FTP
Coke I would do the unzip inside the cygwin shell, to help avoid line ending evil. 19:44
etworks i should check whether I'm configuring with the same version of Perl that's making
I'm pretty sure I only have the cygwin perl installed, but I know at some ponit I had activestate
Coke further steps use the perl you config'd with.
etworks yep, and they're all the cygwin version 19:45
ok, let me unzip using cygwin ... hold please
PerlJam Isn't there a cygwin package for parrot that someone put together? 19:46
(perhaps not the latest release yet)
Coke Honestly, on windows, I'd just use strawberry perl, skipping activestate and cygwin both.
(give that a shot unless cygwin is a must have for y ou.)
etworks I've never heard of strawberry perl 19:47
Coke EGADS!
strawberry perl?
etworks (and I use cygwin for the shell, mostly)
purl strawberry perl is found at strawberryperl.com/
PerlJam etworks: strawberry perl is the one to use on windows.
Coke strawberry comes with a compiler baked in.
etworks I am intrigued.
PerlJam etworks: it comes with Padre which is a GUI editor for Perl written in Perl.
etworks I haven't perled in a while.... last few years I've been nearly exclusively J
19:48 kjeldahl joined
etworks yep, tar xvf instead of winzip solved the problem 19:52
thanks @Coke
19:58 theory joined
Coke etworks: np 19:59
cotto_work are our docs licensed under the same terms as the code? 20:19
20:20 joeri joined
etworks man, this is a comprehensive test suite 20:25
darbelo etworks: actually, if you check the irclog you'll see a fair amount of bitching about the places where it isn't ;) 20:26
But, yeah. There's a lot of testing done.
cotto_work coverage? 20:30
purl somebody said coverage was cv.perl6.cz
Coke cotto_work: yes. 20:32
anything in the repo unless otherwise noted.
cotto_work I was just pointing that out to etworks 20:35
Coke (license) 20:36
cotto_work oh. Thanks.
dalek TT #1377 created by baest++: Build fails on OSX in continuation.c 20:39
cotto_work baest, is that from a clean checkout or tarball? 20:49
Coke oh, didn't realize he was here. 20:50
also, what what version of OSX?
Coke remembers to try context_unify3 against a HLL 20:51
chromatic Only a couple of tests fail there, Coke.
Util baest: TT #1377 - With a fresh checkout of the same rev on OS X 10.5, I get a successful build. 20:54
Coke chromatic: partcl dies horribly during build.
src/ops/tcl.ops: In function 'Parrot_tcl_return_p':
src/ops/tcl.ops:170: error: dereferencing pointer to incomplete type
partcl-nqp also dies, probably due to a lack of recent merge from trunk to that brench. 20:56
Util baest: also, our generated continuation.c files are identical (except for the directory names embedded in #line statements) 21:00
chromatic Sounds like a missing header.
21:01 jsut_ joined
dalek TT #1377 closed by coke++: Build fails on OSX in continuation.c 21:12
cotto_work ... and thus baest learned the importance of working from a clean checkout. 21:15
dukeleto cotto_work: lulz 21:17
cotto_work: everyone has to learn that sometime
When in doubt, "make realclean"
cotto_work yup. I don't mind, especially since the release isn't actually b0rked. 21:18
baest yeah, sorry guys 21:20
japhb pmichaud or Tene, ping
dalek kudo/master: 55a5c07 | moritz++ | build/Makefile.in:
[build] use the same spectest revision for the release as everything else uses
baest I made a real clean and thought that was enough, but when it failed I should have made a clean checkout before making a ticket
Tene japhb: Hi! 21:21
japhb Tene, Hi there!
Would you mind adding bit shift ops to NQP-rx? (That's assuming they are still << and >>, which is what I tried and didn't work.) 21:22
Or is it +>> and +<< now?
Coke japhb: why do you need those?
japhb Coke, converting some PIR to NQP
Coke ah. I've just been using pir::dumb_opcode__xxx for that. 21:23
japhb Coke, yeah, me too. But it seemed like this should be easy for someone who is in the parser often enough.
And they are, after all, standard arithmetic ops in most computer languages, so seemed reasonable from that angle too. 21:24
21:27 bacek joined
Tene japhb: I'm just diving back in at work, but I'll look at that in a bit. It would help if you could work out if it's supposed to be << or +<< or ā‰Ŗ or whatever 21:29
japhb Tene, thanks. I'll take a look.
Tene: +< and +>, see perlcabal.org/syn/S03.html#Multipli...precedence 21:33
Tene and what are the PIR ops for that?
japhb shl and shr
21:35 xenoterracide joined
whiteknight how is context_unify3 doing now? 21:53
wasn't really looking at it today
chromatic whiteknight, a couple of fulltest test failures. 21:54
whiteknight okay 21:55
Coke ls 22:02
ww
22:07 bacek joined
bacek chromatic, ping 22:11
chromatic pong, bacek 22:12
bacek chromatic, we can resurrect usage of NEED_RET_CONTINUATION 22:13
22:13 xenoterracide joined
bacek we just have to update "new_ret_continuation" to use caller_ctx, not CURRENT_CONTEXT 22:13
chromatic My approach wasn't very clean at all. I wonder if making the invokee create the retcont is better. 22:14
bacek this approach used in trunk
pmichaud 19:20 <dukeleto> etworks: tools/dev/mk_language_shell.pl will make a lang skeleton for you, using nqp-rx
I don't recommend mk_language_shell.pl, fwiw. 22:15
use tools/dev/create_language.pl instead -- it's more up-to-date
moritz why do we keep the outdated script then? 22:16
Tene can we get mk_language_shell.pl to warn and prompt without violating deprecation policy?
moritz: deprecation policy, of course!
pmichaud moritz: deprecation policy
purl deprecation policy is a major pain in the kiester.
bacek chromatic, t/library/streams.t (Wstat: 256 Tests: 20 Failed: 1)
Failed test: 12
japhb pmichaud, question:
pmichaud a lot of people made changes to mk_language_shell.pl that I disagreed with, so I created a new one earlier this year.
chromatic Right.
pmichaud I've been keeping that one up to date.
I don't see any issue with having mk_language_shell.pl warn 22:17
japhb How do I set caller's $! from within an NQP library routine?
pmichaud japhb: have to do it from PIR
chromatic A warning is different from changed behavior.
pmichaud japhb: and the caller has to declare a $!
japhb pmichaud, I'm converting (working) Glue.pir code to NQP. Problem is, 22:18
pmichaud (i.e., a called routine can't suddenly give the caller a $!)
japhb as soon as I turn the top-level function into NQP from PIR, it has its own $!.
pmichaud ?
I don't quite understand that part.
afaik, NQP never creates its own contextuals; you have to do it explicitly
japhb Well, maybe I did it by accident somehow, but my PIR code contains anon blocks that set up $_ and $! 22:19
er
the PIR generated from the NQP
by parrot-nqp --target=pir
pmichaud the only place that NQP is supposed to create a $_ is on blocks that need it as a parameter 22:20
ooooops
I'm guessing that Tene++ added $! as automatic lexicals
urgh.
Tene If I did, they shouldn't be on everything, only on things that use exceptions. 22:21
japhb ... and there would be my problem
DAMMIT
pmichaud code looks like it adds them to every block that doesn't have explicit params
japhb I was trying to use exceptions in my library code ... that also wants to set callers $!
pmichaud oh, wait
never mind
I see
Tene++ is correct
japhb blarg
hmm 22:22
pmichaud I'm not sure that's the behavior I ultimately want
japhb: anyway, what do you want your routine to do if a caller doesn't have a $! ?
japhb how am I going to catch an exception thrown by a PIR op without setting $!?
Tene I do remember being uncertain if tha was the right way to handle it.
Coke (warn) can we deprecate the old one so we can rip it out after 2.0?
japhb pmichaud, I have this code:
my $bang := pir::find_dynamic_lex('$!');
pir::store_dynamic_lex__vsP('$!', $pipe.exit_status)
if pir::defined($bang);
Tene japhb: Doesn't the NQP try{} set $! for you? 22:23
22:23 theory joined
japhb Tene, I have to set caller's $! 22:23
pmichaud Coke: I'm fine with that. Once mk_language_shell had been patched beyond what I felt was salvageable I simply abandoned it (including abandoning any decisions about its future support)
japhb Definition of qx()
22:23 cotto_work joined
pmichaud japhb: but what if the caller doesn't have a $! ? 22:23
japhb ... which I was implementing
pmichaud, see magic code above
pmichaud that doesn't tell me anything
find_dynamic_lex will throw an exception if none of the callers have a $! 22:24
japhb If caller doesn't have $!, $bang is not defined, so the store doesn't happen.
pmichaud hmmmm
okay, that's right
Coke ... but you call the store before you check for defined?
pmichaud Coke: it's a statement modifier
japhb It's the only way I found to "fill in" contextuals from a library when you don't know if the caller declared them or not.
Coke oh.
japhb Like $*EXECUTABLE_NAME and such
Coke i didn't realize nqp did that yet. =-)
pmichaud japhb: is this occuring from inside a nested block ? 22:25
because find_dynamic_lex never finds a $! in the current sub
japhb hmmm
pmichaud (in the current Parrot sub, that is)
japhb pmichaud, nod 22:26
It looks to be nested inside some humongous sub that just does a pile of capture_lex ops on all of the subs in my library 22:27
(The qx() sub is nested inside ...) 22:28
WTH is this thing? 22:29
Implements the file scope?
pmichaud well, sure, since any subroutines there are nested in file scope. 22:31
darbelo people talking about removin mk_language_shell.pl: The script seems to have changed somewhat from what you want to remove.
pmichaud darbelo: I don't follow what you mean. (I don't *need* to follow it, but I don't follow it :-) 22:33
japhb pmichaud, sorry, came across wrong, I just trying to understand the generate code, and thinking out loud.
er generated
pmichaud japhb: sure, no problem.
japhb: I agree that the lexical generation stuff tends to be ugly at times.
darbelo pmichaud: I'm looking at the file and it's been substatialy updated. It now generates a setup.pir driven build. 22:34
pmichaud darbelo: ...and I have no desire to deal with that. 22:35
thus, create_language.pl :-)
japhb Oooh, I think I partially misdiagnosed, due to a bug in parrot Test::More. Checking to be sure ...
darbelo pmichaud: create_language.pl predates the change I'm mentioning. There's little reason to dis-recomend mk_language_shell.pl nowadays. 22:36
pmichaud darbelo: (looking at code) fair enough. But all of the tutorials I intend to write are going to be makefile based. 22:41
darbelo pmichaud: I'm not trying to change your mind at all. Diversity is good. I'm just pointing out it's been revamped and it's much better than it was before. 22:43
pmichaud I agree, it's been updated and is much better than before.
it seems to assume that languages will always be built from an already-installed parrot, instead of the approach of getting a language tarball which then downloads the appropriate parrot 22:44
japhb pmichaud, why teach people makefile methods? setup.pir is the way most of the modules in Parrot world are going 22:45
pmichaud japhb: says who?
purl well, says is not reliable, in that errors are reported but no automatic retry.
japhb pmichaud, you seem to be holding on to this idea of the HLL being the center of the world, it is no more the center of the world than Parrot is. The user's *app* is what is important, the order that stuff needs to be installed before that doesn't matter.
pmichaud, I'm judging by the metadata I've seen. 22:46
And the vast number of setup.pir conversions that have happened.
pmichaud I'm not holding onto the idea of the HLL being the center of the world.
I'm simply saying I'm not sure that Parrot is.
japhb Sure, but if neither the HLL nor Parrot is, then it doesn't matter which order they are installed in. And we've got a working system for Parrot first, and a kinda broken way of doing anything else first. 22:47
pmichaud I think the parrot-first way is "broken". It certainly doesn't meet the expectations of my users.
japhb (BTW, sorry if I was a little abrasive just now, just had issues with a person local to here, so was a little tense) 22:48
pmichaud so, describe for me how someone wanting to download and use language Xyz from an Xyz tarball would do that.
(via setup.pir) 22:49
darbelo tar xzf Xyz.tgz; cd Xyz; parrot setup.pir install 22:50
pmichaud I don't have parrot installed yet
japhb I'm saying they should not start with an XYZ tarball. They should start from a README that says "Download Parrot, configure and make install, then say "plumage install Xyz"". The idea that the first operation is to download a tarball is a side effect of history, not the way things really happen. The user reads a how-to on a blog or web site somewhere, and it starts off by telling them to download a tarball of Xyz. There's no reason it
can't tell them to do something else.
pmichaud japhb: "Download Parrot" --- which version? 22:51
darbelo pmichaud: You should, nobody tries to run a python app without installing python beforehand.
dalek kudo/master: 7f1c3fe | chromatic++ | docs/release_guide.pod:
[docs] Updated release guide.
pmichaud darbelo: python is a lot more mature than parrot
pmichaud darbelo: I can be reasonably certain that whatever version of python is on my machine will run my python app. That's absolutely *not* the case for our hlls at this time. 22:52
japhb pmichaud, is the issue that you want to have people riding rakudo HEAD? Because for any released rakudo, there is a matching parrot. Plumage simply inverts that relationship, and downloads the best Rakudo it can given the parrot ...
pmichaud japhb: even if I download a release rakudo
*released
...then what?
japhb pmichaud, That's not the case for Python either. On Debian, there's often several Pythons installed at once.
pmichaud japhb: let's suppose I downloaded the 2009-11 release of Rakudo. 22:53
so, I unpack the tarball.
I can't run setup.pir -- I don't have a Parrot yet.
I can't run plumage -- I don't have a parrot yet.
japhb pmichaud, you don't start with downloading Rakudo. You start by reading instructions that say "Want Rakudo? Install Parrot, then tell Parrot to install Rakudo"
pmichaud japhb: and which version of Parrot should someone install? 22:54
japhb They only know how to find a Rakudo tarball now because you point them to it with some instructions somewhere. So give them different instructions.
pmichaud, if they want the most recent release of Rakudo, it would be the most recent release of Parrot
pmichaud not true
what if the most recent release of Parrot doesn't *have* a most recent release of Rakudo? 22:55
As is the case yesterday and today, for example.
japhb Hold on, @family
darbelo pmichaud: To me, you are suggesting that the way to install apache is via a mod_whatever tarball.
pmichaud darbelo: To me, you're saying that I have to redo my HLL makefiles to instead use setup.pir
and if setup.pir doesn't do some operation that I need in order to build the application, I'm hosed. 22:56
22:56 ingy joined
darbelo pmichaud: I'm not saying 'do it now', but if you can add it to the makefile you canadd it to your setup.pir they are seriously extensible and a lot more portable than makefiles. 22:57
pmichaud assuming I know PIr. 22:58
PIR
does setup.pir support parallel make/build?
darbelo You can do a setup.nqp too.
I know japhb means to use that for plumage. 22:59
Hmm. Haven't checked parallel building. 23:00
japhb As a matter of fact, switching Plumage to 'setup.nqp' was waiting on Tene++ to do =>, which he did a couple days ago. 23:01
pmichaud anyway, the setup.pir approach seems to assume that HLLs and their libraries are integrated into a general form of "Parrot module archive network", where Parrot is the foundation for everything that happens. That's a valid view, but I'm not sure that HLLs in general are going to adopt it.
japhb Anyway, pmichaud, I was going to say about today and yesterday, the problem is that I was trying to respond quickly rather than pedantically.
When I say, "for the newest Rakudo, start with the newest parrot release", I should have said: 23:02
"On the page where you tell people how to get Rakudo, you should always point people to *the most recent Parrot that supports the most recent released Rakudo*" 23:03
So, for yesterday, you would have pointed them to Parrot 1.8, even though 1.9 was latest.
pmichaud ...and most people would say "oh, 1.9 is out, I think I'll grab that one instead"
japhb Because 1.8 was the latest Parrot release that supported the most recent Rakudo release.
So you put a line on there that says "We'll support 1.9 tomorrow" 23:04
Or "We'll support 1.9 on Dec 17"
pmichaud japhb: why are you putting so much work on HLL devs?
every time Parrot makes a release, I have to update my site to say when I'll support it?
PerlJam japhb: Is parrot installable via plumage?
Tene Are there any comparable situations with other pieces of software?
japhb pmichaud, that's the thing, it's LESS work for HLL devs. Remember how long it took to get everything working to build a local Parrot install? New HLL creators shouldn't have to do that.
PerlJam, chicken and egg. 23:05
If Parrot could create a REAL executable, it would be,.
chromatic Don't forget that this solution only has to work for a year or so.
pmichaud japhb: "how long it took" was because parrot installs were broken, not because of setup/config utilities
PerlJam japhb: If parrot is installable via plumage, then you always start with the latest parrot and use it to install rakudo and that parrot it depends upon.
japhb The other thing is that having every HLL build a private parrot kills HLL interop, which is the whole magic of Parrot
pmichaud japhb: By no means do I advocate building a private parrot in every instance 23:06
that's why the default Configure.pl always finds whatever parrot is already installed
we only advocate --gen-parrot now because Parrot is not sufficiently stable to be able to say "install Parrot, build Rakudo"
japhb pmichaud, that just runs over the very same version compatibility issue you're calling Plumage on.
Ah!
pmichaud if I thought that downloading a separate copy of Parrot for every HLL was the answer, then --gen-parrot would be the default. 23:07
japhb OK, so when Parrot stabilizes, you will be telling people to get Parrot first then?
(honest question)
pmichaud yes, when I think that rakudo development has stabilized to the point that I recommend "latest release" instead of "latest HEAD", then the default instructions will change 23:08
Tene japhb: will plumage work with the --gen-parrot version of Parrot?
I'd imagine not, at least until we get the build dir looking like the install dir, yes?
pmichaud Tene: even the --gen-parrot version does an install 23:09
Tene pmichaud: Oh, okay. I didn't know that.
pmichaud Tene: --gen-parrot no longer uses the build tree
japhb Tene: pmichaud is correct
(of course)
Parrot Test::More bug: 23:11
$ parrot-nqp -e 'pir::load_language("parrot"); pir::compreg__PS("parrot").import("Test::More"); my $undef; is($undef, 0)'
ok 1
pmichaud japhb: what answer are you expecting? 23:12
japhb pmichaud, you get 'ok 1' if you change is() to isnt(). The latter is correct, according to the usual semantics of undefined values. 23:13
'you also get'
pmichaud japhb: I'm not sure that's a Test::More bug 23:14
I suspect it's an Undef bug
just a sec
japhb Fair enough.
pmichaud (building a nopaste)
nopaste "pmichaud" at 66.25.4.52 pasted "parrot comparisons don't always do what you expect" (20 lines) at nopaste.snit.ch/19131 23:16
japhb While you're working on that ... I guess my frustration is (at least I gather) that Parrot and Rakudo will not be at the stability level you're looking for for some time. In the meant time, if we teach everyone how to set things up in a way we know we will change, we've just mistrained a bunch of people, and increased the momentum on an already known-LTA technique. 23:17
23:17 TiMBuS joined
japhb Yep, that nopaste is buggy all right. 23:18
Oh dear.
pmichaud japhb: let's try an analogy 23:21
japhb And as for the "lots of work for HLL guys to update the instructions", it could be part of the release announcements, which you do already. No extra work.
pmichaud japhb: ... except you said I have to do it at the point of a parrot release
23:04 <japhb> So you put a line on there that says "We'll support 1.9 tomorrow"
"We'll support 1.9 tomorrow" isn't a release announcement
japhb I realized my mistake, and corrected myself. Sorry I did not make it clear. :-) 23:22
pmichaud I didn't see the correction.
japhb fair enough. 23:23
pmichaud (I still don't see the correction.)
...what was the correction? 23:24
23:04 <japhb> Or "We'll support 1.9 on Dec 17"
...that?
japhb Yes, that was part of the correct. It was unclear, because I had meant that you could write that *on the day you support 1.8*. Then I mentioned above about writing the correct instructions in your release announcements. 23:25
pmichaud I'm sorry, but I would be very uncomfortable making any sort of prediction about 1.9
japhb I can understand that. 23:26
pmichaud when 1.8 comes out, I can't guarantee that we'll even be able to support 1.9
for that matter, we almost got burned when 1.4 came out.... and 1.4 was supposed to be a "supported release"
japhb You could also say "This release supports exactly Parrot 1.8, not any newer release. Please wait for our next release before upgrading Parrot."
darbelo "We support this. Try later version at your own peril" is a stardard disclaimer in opoensource software.
japhb What darbelo said
pmichaud anyway, in the long run I suspect that "mistrained a bunch of people" won't apply anyway, because what I'll really be saying is "install this .rpm or .deb package" 23:28
japhb Right, and setup.* is already (as of today) beginning to support generating said RPMs and DEBs. 23:29
pmichaud I also cannot see wanting to take something declarative like a Makefile and converting it to something procedural like a script. 23:30
japhb Plumage fully supports Makefiles, and always will ... I just don't think we should teach people that's the right way, any more than we teach new Perl 5 people to use MakeMaker.
setup.* is essentially declarative
pmichaud not if I have to write my own custom components for it 23:31
japhb The script just builds the data structure.
pmichaud, right, but those are exactly the places you write your own makefile rules.
pmichaud 22:57 <darbelo> pmichaud: I'm not saying 'do it now', but if you can add it to the makefile you canadd it to your setup.pir they are seriously extensible and a lot more
japhb The basic stuff is declarative in both setup and a Makefile. And the unusual stuff is a script in both cases. 23:32
What is the difference?
purl the difference is not enough to make the US the only super power.
pmichaud anyway, this is eating up more of my time than I care to use right now (more) 23:33
I agree with darbelo, there's not (any longer) a reason to recommend create_language.pl over mk_language_shell.pl . You all have done a good job of updating it.
Personally, I'll spend my tuits keeping creating_language.pl up to date and using it, because the audience I want to reach likely already understands makefiles and they have enough new stuff coming at them anyway (more) 23:34
I would also be very interested in seeing someone create a setup.pir for nqp-rx and/or rakudo.
I can't say that I'll adopt it, but if I could see it working for one or both of those I might be less adverse to it.
japhb msg fperrad Please see irclog.perlgeek.de/parrot/2009-12-17#i_1850132 23:35
purl Message for fperrad stored.
dukeleto pmichaud: fperrad will probably take you up on that offer 23:41
23:41 NotJack joined
pmichaud excellent 23:42
I look forward to it.
(seriously)
dukeleto pmichaud: fperrad has been writing everyone's setup.pir for them, if you just ask. he wrote one for Tapir :) 23:44
pmichaud: i even got him to add a pbc_merge stage
cotto_work I don't like that bus number.
pmichaud japhb: tene's => patch only works if the lhs is a bareword identifier... is that going to be sufficient for your needs? 23:45
japhb pmichaud, I think so. I'll raise a flag if not
pmichaud okay
NotJack Configure.pl suggests I make, then make test, but not make install 23:47
japhb cotto_work, I've looked through the underlying code. It's not complex, there's just a lot of it. I think right now it's just a matter of using people's time effectively. I don't see a big bus number problem (a minor one, maybe).
NotJack is that for a reason?
cotto_work japhb, ok. He's certainly the most qualified to write the code. 23:48
pmichaud I'm curious to see if setup.pir can easily handle a complex makefile like nqp-rx or rakudo
cotto_work Wow. 4400+ lines of pir is a lot. 23:57

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!