Parrot 0.8.1 "Tio Richie" Released! | www.parrot.org/
Set by moderator on 22 November 2008.
Infinoid I've also got a "src/inter_call.c:390: failed assertion 'PObj_is_PMC_TEST(sig_pmc)'" from t/spec/S12-class/declaration-order.t, which somehow wasn't reported as a failure in the harness summary 00:00
pmichaud Infinoid: that's a known failure.
Infinoid ok
pmichaud that one is in trunk also.
allison pmichaud: yeah, don't block the branch merge on Lua/Closure
pmichaud the declaration-order.t and increment.t tests are known failures.
Infinoid ok, I'll see if I can get some more info about the others
pmichaud Infinoid: try running them directly from command line
jonathan pmichaud: NQP passes all here.
pmichaud yes, gc bug somewhere.
jonathan OK 00:01
pmichaud dinnertime here... I'll backscroll reports a bit later
jonathan ok
jonathan will prob sleep soonish
00:01 bacek_ joined
Infinoid all of the tests I listed before are marked as TODO, yet they were reported by the harness summary for some reason. -G has no effect on them. 00:02
sorry for the false alarm. things are looking pretty good 00:03
00:05 bacek joined
Infinoid maybe it was reporting TODO passes, there are several of those. 00:07
00:09 AndyA joined
dalek r33168 | allison++ | pdd22io_part2: 00:14
: [pdd22io] Update Unicode string tests to use new way of setting UTF-8 encoding
: on a filehandle.
diff: www.parrotvm.org/svn/parrot/revision?rev=33168
00:18 Whiteknight joined 00:22 tetragon joined 00:26 cognominal joined
Infinoid ok, I'm confused. t/spec/S06-signature/type-capture.t, t/spec/S04-statements/next.t and t/spec/S04-statement-modifiers/if.t run fine from the command line, but when run under the harness, they get "No subtests run". that doesn't seem to be the case in trunk. (if.t fails 4 tests in trunk, but they all at least run.) 00:29
jonathan That's...odd. 00:31
chromatic The harness adds extra flags.
They might be aborting on exit thanks to a double free.
Infinoid no extra flags according to "ps ax | grep parrot". something in the environment, perhaps? 00:32
Infinoid attaches gdb to parrot running under the harness 00:35
chromatic Try -D40
Infinoid ah, the old if(!VTABLE_does(interp, p_arg, CONST_STRING(interp, "hash"))) segfault trick.
odd that it crashes under the harness but not on the command line, given that they are both run with exactly the same args. 00:36
chromatic That's a segfault? 00:37
Infinoid that's a segfault, p_arg's vtable is 0xdeadbeef
I nopasted a backtrace of that a little while ago, nopaste.snit.ch/14711
that was from a different spectest. it seems to have migrated 00:38
pmichaud said he was seeing the same thing in an nqp test. 00:39
chromatic Oh, those are easy to trace. 00:41
Break on the return value of new_pmc_header.
Infinoid conditional breakpoints make gdb slow. let me guess, once it's there, put a watchpoint on the address of pmc->vtable, right? 00:46
chromatic Nah, that'll only tell you that src/gc/dod.c poisons the vtable. 00:48
Look for what *allocates* the PMC and that'll give you better hints as to why it gets collected early. 00:49
Infinoid wow, these backtraces are getting big. 00:50
nopaste "Infinoid" at 96.238.213.50 pasted "backtrace of the dying PMC's allocation" (365 lines) at nopaste.snit.ch/14714 00:51
Infinoid ooh, pretty sunset 00:52
chromatic I hate "Class %Ss already registered."
jonathan oh, it's that fun exception
Did anyone manage to track down that's beneath that yet? 00:53
(Put another way: is it a "we know what it is and don't know how to fix it", or a "we don't know what it is"?) 00:54
chromatic I don't know what it is. I don't know if anyone else knows what it is. 00:55
I do wonder "What happens when code run from an exception handler throws an exception?"
jonathan Perhaps, this... :-) 00:56
Infinoid hardware CPU designers typically reserve a special place in hell for software that does that. 00:57
chromatic Just a thought.
purl it has been said that Just a thought. is _smtp_code_220 really an object method ?
Infinoid that said, having an error in a catch block isn't really that evil, and should be handled gracefully 00:58
pmichaud back again.
chromatic There's "should be" and there's "is" and I don't know the difference here. 00:59
Infinoid hey Pm. I think the other errors I was seeing were other instances of the same segfault you were seeing in nqp.
pmichaud yes, I think so also.
I'm going to have to increase my gdb-fu though.
Infinoid I've posted a backtrace of where that PMC was allocated, if it helps.
in half an hour, I should have more time for digging through it
pmichaud my best guess is that tailcalls are releasing the context containing the arguments before they get processed.
it was allocated from init_first_dest_named? 01:00
chromatic Yes.
pmichaud okay then, my guess would be wrong. Or at least not indicated by this backtrace.
that actually makes me happier.
how can I find the equivalent for my segfault in nqp? 01:01
that ought to be much simpler to debug/trace (smaller code and all that)
chromatic Find the PMC with the invalid vtable.
Then break on new_pmc_header's return value (break src/pmc.c:xx if retval == 0x....) 01:02
pmichaud (gdb) break src/pmc.c:238 if pmc == 0x82688a8 01:04
didn't seem to do it.
I'll try... 01:05
nopaste "pmichaud" at 72.181.176.220 pasted "backtrace of gc'd pmc header" (33 lines) at nopaste.snit.ch/14715 01:07
chromatic RetContinuation getting recycled early?
pmichaud could be, especially on a tail call. 01:08
or other things. Will keep looking...
src/inter_call.c:2677 01:10
set_context_sig_returns(interp, ctx, indexes, ret_x, result_list);
...that looks suspicious.
chromatic The ctx parameter? 01:11
pmichaud yes. 01:12
the ctx might have already been reclaimed by the time we get back from runops.
since the return continuation that was holding it for us will have already been invoked (and released) 01:13
chromatic Makes sense. 01:15
pmichaud trying it now.
that didn't appear to fix it. 01:16
01:17 gmansi joined
pmichaud I'll step through a few things in that area and see what happens. 01:19
dalek r33169 | Whiteknight++ | trunk: 01:20
: [Book] Update some things in the beginning of chapter 5, reference some things from the PIR chapters, and delete some stuff that I know to be deprecated or removed entirely.
diff: www.parrotvm.org/svn/parrot/revision?rev=33169
Whiteknight chromatic, pmichaud, if you guys find a solution to this problem let me know, I think it will affect a problem I've been having 01:21
in fact, if you need me to help with anything, let me know
pmichaud will do.
I might need some questions answered about argument handling at some point.
Whiteknight ...and if you don't want my help, keep it to yourself :)
Hell, I might need some questions answered about argument handling too 01:22
If there was ever a case to make parrot stack-based, it's our messy argument passing conventions
chromatic I'm not sure that would help. 01:23
pmichaud well, I think that's because they were bolted on to something that was kinda stack based. :-)
chromatic Every time we mix C calling conventions and PIR calling conventions we run into trouble. 01:24
Whiteknight it's trouble that we are going to need to clear up eventually
for performance, if not for our sanity 01:25
time to go, talk to you gentlemen later 01:30
Infinoid I think he must have been talking about you guys. 01:33
ok. so how can I help?
allison chromatic: re "mixing calling conventions" yes, they need to be merged as much as possible 01:40
chromatic I intend to send mail to the list raising the possibility of making MMD variants in vtables use PCC not CCC. 01:41
allison well, CCC is collapsing into PCC
that is, everything is going through pcc_invoke 01:42
(one of the pcc_invoke variants
)
chromatic: though, MMD is already using pcc_invoke
chromatic Yeah, through the ops->CCC->MMD->NCI->CCC conversion chain.
01:43 gmansi joined
allison chromatic: that's just because everything is using that chain at the moment 01:43
chromatic: agreed that PCC needs some simplification still
chromatic If VTABLE_cmp always does multidispatch, why even have cmp as a vtable entry? 01:44
allison because it doesn't always do multi dispatch
several PMCs have VTABLE_cmp overridden
chromatic To do multi dispatch.
allison no, to do single dispatch 01:45
chromatic Hm, if only single dispatch were a degenerate case of multi dispatch....
allison the default PMC does multidispatch, so multi happens anywhere a VTABLE_cmp isn't defined
the expensive part of multidispatch is the lookup
the call is cheap 01:46
chromatic I have code which proves otherwise. 01:47
allison is this code after you revamped the look up process? or using a cache?
chromatic Yes. 01:49
allison okay, well that changes the game :)
pcc_invoke definitely needs some streamlining
chromatic It's all of the conversions which throw away information and marshall and unmarshall the same known arguments in and out of generic datastructures that makes things slow. 01:50
allison but, better to have one call path and streamline that one path, than keep going with what we have now (which is half-a-dozen different call paths)
chromatic In an op, we know the name of the MMD call and the name and (often) types of its arguments.
We convert that to C calling conventions and throw away some type information.
Then we call the MMD dispatcher, converting the C-style arguments into varargs, throwing away all type information. 01:51
Then we unpack them, parsing a string to get back some type information.
allison chromatic: so, at the moment pcc_invoke is bolted on top of another argument passing scheme, but part of the calling conventions refactors is to make pcc_invoke *the* argument passing strategy
chromatic Then we shove them into a PMC (which contains at least one other PMC), which we pass elsewhere to look up the proper MMD variants. 01:52
That often hits a cache, now.
allison so, you can build a CallSignature from within the MMD lookup, and make a call with that directly
chromatic The madness hasn't ended yet though.
allison cutting out several layers of indirection
it's stages of refinement
chromatic We take that PCC-style dispatch and call an NCI PMC, which unmarshalls the arguments into a C-style system and invokes a function pointer. 01:53
pmichaud ick, I'm in a maze of twisty argument passing code, all opaque.
chromatic Which calls the vtable-style entry.
allison oh, you mean for the MMD's defined in C?
chromatic Yes.
allison well, that's the only way we have to make C functions act like full subs 01:54
nopaste "Coke" at 72.228.52.192 pasted "sample text for old non-core platform test failure." (19 lines) at nopaste.snit.ch/14716
chromatic They could take PCC-style args.
That would help.
allison at least, at the moment
yeah, we could generate MULTIs like METHODs 01:55
chromatic That would be a big improvement.
allison can't think of any drawbacks at the moment 01:56
Coke was "miniparrot" discussed at the summit?
allison Coke: as in parrot on embedded devices? or parrot as the replacement for the perl configure/build tools?
chromatic On the invocation side, I think a separate mechanism to invoke a multi given an existing context would work nicely. 01:57
Coke whatever corresponds to the broken --miniparrot option to configure. =-)
allison chromatic: but, it doesn't have an existing context
chromatic It does in ops.
allison Coke: that's documented as "Build parrot assuming only pure ANSI C is available.", so I'd have to say "No" 01:58
Coke: not even a desired feature anymore, AFAICT
chromatic: an MMD execution needs its own context, otherwise you tromp all over existing registers 01:59
chromatic see src/ops/math.ops 02:00
allison chromatic: because calling, for example 'add $P0, $P1' might just call a C function, but it might also call a PIR subroutine
Coke allison: --miniparrot isn't desired, or targeting ansi c isn't desired? 02:01
allison chromatic: what about src/ops/math.ops?
Coke: I guess it depends on the definition of "pure ANSI C" 02:02
Coke allison: can you comment on 55386 ? If you say it's safe to rip out, I can add it to my queue.
pretty sure no one is using it now since it's borked. =-)
chromatic . o O { Hm, we could get rid of direct vtable invocation altogether. }
Don't worry, that's a 3.0 thought. 02:03
allison Coke: we conform to C '89
Coke: don't see any need for a configuration flag that conforms to some other standard
chromatic allison, within math.ops, plenty of PMC-arg ops get those PMCs from contexts and immediately dispatch to MMD.
Not just infix, but VTABLE_add, VTABLE_cmp, etc.
Coke allison: en.wikipedia.org/wiki/ANSI_C is C89. sort of. 02:04
I think it was meant to be the same thing, anyway.
allison chromatic: yes, I wrote them to do that, but they go via vtables so they can be overridden to do something else
Coke: yes, saying it's "ANSI C" isn't specific enough 02:05
Coke so, anyway, I'll rip it out. =-)
allison Coke: three cheers!
Infinoid rip rip, hooray
allison oh, yeah, looking at src/ops/math.ops again, do we have a ticket in place to rip out the old 'infix' opcodes? 02:06
it's about time to do it
Coke New in 0.0.9 02:07
- Miniparrot (Josh)
allison looks like no 'infix' ticket 02:08
they're not even listed in DEPRECATED.pod yet... 02:12
Coke kid51: ping? 02:15
dalek r33170 | coke++ | rm_miniparrot: 02:19
: Create a branch for RT#55386, remove --miniparrot option from Configure.pl
diff: www.parrotvm.org/svn/parrot/revision?rev=33170
r33171 | allison++ | trunk:
: [cage] Add deprecation notice for 'infix' and 'n_infix' opcodes.
diff: www.parrotvm.org/svn/parrot/revision?rev=33171
02:28 TiMBuS joined
pmichaud yes, the issue I'm having appears to be a tailcall issue. 02:31
Coke facebook++ 02:35
dalek r33172 | coke++ | rm_miniparrot: 02:44
: First pass at removing the --miniparrot option to Configure.pl
: Note that this doesn't impact the creation of the "miniparrot" executable,
: which is still part of the build process.
: "make test" passes everything except for t/steps/.
diff: www.parrotvm.org/svn/parrot/revision?rev=33172
Coke there. I /think/ the only thing left to do in that branch is to fixup the t/steps/ tests from trying to use --miniparrot as an option to Configure.pl 02:47
-> 02:48
03:02 Alias joined
pmichaud ...can I cheat and put a "gc run sequence number" into mark_context? 03:03
if I don't mark the caller_ctx nodes, then I lose them in a tailcall (and possibly other situations) 03:05
03:05 chromatic joined
pmichaud If I mark them, then in some situations I end up in endless recursive loops, as well as the fact that we may mark some contexts multiple times in a single gc run. 03:05
s/may/will/
afk for a while. 03:09
Infinoid how about just checking whether the various PMCs have already been marked, before marking them? 03:14
it may be a little slower, but I think it should work
oh, mark_context calls itself directly. oof. 03:17
pmichaud right. 03:26
I would think that the PMCs already check if they've been marked.
03:28 jimmy joined 03:29 kid51 joined
kid51 Coke ping 03:29
tewk pmichaud: could the tailcall ops be modified to mark the context for you?
03:37 petdance joined 03:41 PerlPilot joined, pmichaud_ joined 03:42 wolverian joined
allison pmichaud: the infinite looping mark_context is what prompted me to do the first draft fo shifting contexts to PMCs (since GC already handles loops). just go for the quickest possible fix for now, contexts will become GC-able soon 03:43
03:46 jonathan joined 03:47 wolverian joined 03:51 jonathan_ joined
tewk .return FUNCCALL is now .tailcall right, no one fixed ncigen :( 03:55
03:57 polyglotbot joined 03:58 leo joined, wolverian joined, dalek joined
kid51 must sleep 04:00
purl $kid51->sleep(8 * 3600);
04:02 pmichaud joined, adu joined, jonathan joined 04:07 PerlJam joined 04:11 pmichaud joined 04:13 dalek joined
pmichaud I think quickest fix is a gc run counter to break loops, so I'll go with that. 04:15
it'll also improve some efficiency. 04:18
04:21 leo joined, dalek joined
dalek r33174 | allison++ | trunk: 04:31
: [pdds] Renaming PDD 14, preparing for merge of three PDDs.
diff: www.parrotvm.org/svn/parrot/revision?rev=33174
r33175 | allison++ | trunk: 04:33
: [pdds] Regenerating the manifest for renamed draft PDD.
diff: www.parrotvm.org/svn/parrot/revision?rev=33175
04:51 stockwellb joined 05:00 tetragon joined
allison hmmmm... it looks like PDD 14 (bignum) is just a proposal, never implemented 05:06
05:07 bacek joined
dalek r33176 | tewk++ | trunk: 05:25
: [ncigen] ncigen now generates a majority of the sqlite3 signatures correctly
diff: www.parrotvm.org/svn/parrot/revision?rev=33176
lathos tewk: Did you apply your fix to not require C? 05:26
Ah, yes. Excellent. 05:27
I've been corresponding with Tim Bunce on DBDI, and next time I have some spare time I shall start implementing that.
nopaste "tewk" at 155.97.237.62 pasted "ncigen_attempt_on_sqlite3.diff" (605 lines) at nopaste.snit.ch/14717 05:28
lathos Does anyone else remember h2ph? 05:30
dalek r33177 | allison++ | trunk: 05:34
: [pdds] Descriptions of the native integer and float types.
diff: www.parrotvm.org/svn/parrot/revision?rev=33177
r33178 | allison++ | trunk:
: [pdds] Deleting the now completly redundant datatypes PDD (number 4 is
: now available for reuse).
diff: www.parrotvm.org/svn/parrot/revision?rev=33178
tewk lathos:just tried h2ph on sqlite3.h, cool it pulled out #defines. 05:42
ncigen can't do that yet, it just pulls function definitions.
lathos Yes, it's a very old (Perl4) way of doing extensions by parsing header files. I just found it amusing that that's where we're up to with Parrot. :)
So where do you see this going? Do you plan to apply that ncigen result patch? Or do you want to handle it manually? 05:43
tewk ncigen uses a full c99 parser generated from PGE, if that makes you feel anybetter.
lathos I'm feeling good. :) Just want to know what the plan is. 05:44
tewk I though I'd ask you what you wanted. I could apply it and you could modify from there if it will save you time.
adu I plan on rewriiting languages/c99 in Haskell 05:45
lathos Oh. I dunno. It looks good. But if we're planning to have things autogenerated from ncigen, then probably best *not* to check it in, but to check in something which creates and builds it.
pmichaud as of r33179 in the lex5 branch, all tests pass that are expected to pass. 05:47
I'm tired now, so I'll see what reports people have and about merging into trunk tomorrow morning.
dalek r33179 | pmichaud++ | lex5:
: Add a context gc run counter to avoid loops in mark_context.
diff: www.parrotvm.org/svn/parrot/revision?rev=33179
tewk Hmmm, ncigen doesn't have a programatic interface right now, but it would be cool to interface it with perl6 and write a perl6 script to autogenerate portions of the interface.
adu: why haskell? 05:49
dalek r33180 | allison++ | trunk:
: [pdds] Removing PDD 4 from the manifest.
diff: www.parrotvm.org/svn/parrot/revision?rev=33180
adu tewk: because its parsing abilities are beyond awsome 05:52
and you can implement lisp in one line
lisp = number <|> identifier <|> parens $ many $ lexeme lisp 05:53
05:54 stockwellb left
lathos The problem is, you do that and you end with lisp. 05:56
adu then maybe I should work on languages/lisp
tewk PGE parsing is awesome too, it will be great when it gets a speed boost soon. 06:19
06:24 baa joined 06:32 Hadi joined 06:33 Hadi left 06:41 TiMBuS joined
baa QUIT 06:54
jimmy QUIT 06:55
06:56 contingencyplan joined 07:05 TiMBuS joined 07:18 uniejo joined
dalek r33181 | allison++ | trunk: 07:41
: [pdds] Add interface definition for Integer PMC.
diff: www.parrotvm.org/svn/parrot/revision?rev=33181
moritz purl, msg pmichaud in lex5 I get no new failures (compared to trunk) in both parrot's 'make test' and rakudo's 'make spectest 07:57
purl Message for pmichaud stored.
08:03 alvar joined
dalek r33182 | fperrad++ | trunk: 08:06
: [WMLScript] change PASM registers to PIR registers
diff: www.parrotvm.org/svn/parrot/revision?rev=33182
r33183 | fperrad++ | trunk:
: [WMLScript] update syntax
diff: www.parrotvm.org/svn/parrot/revision?rev=33183
08:08 Hadi joined 08:15 Hadi left 08:26 UltraDM joined 08:31 Hadi1 joined, Hadi1 left 08:43 ff-wonko joined 08:52 iblechbot joined 09:07 elmex joined 09:08 Hadi joined 09:10 Hadi left 09:34 rob joined
dalek r33184 | fperrad++ | trunk: 09:50
: [Lua] change PASM registers to PIR registers
diff: www.parrotvm.org/svn/parrot/revision?rev=33184
r33185 | fperrad++ | trunk: 09:59
: [Lisp] change PASM registers to PIR registers
diff: www.parrotvm.org/svn/parrot/revision?rev=33185
10:00 ff-wonko joined 10:01 Ademan joined
dalek r33186 | moritz++ | trunk: 10:02
: [cage] remove trailing whitespaces
diff: www.parrotvm.org/svn/parrot/revision?rev=33186
r33187 | moritz++ | trunk: 10:04
: [cage] fix line length in PDD14 to make codetest happier; still needs a
: VERSION section.
diff: www.parrotvm.org/svn/parrot/revision?rev=33187
10:11 tomyan joined
cotto Does ~$<foo> in nqp mean "the string matched by foo"? 10:11
Also, it's hard to search for syntax like that, but maybe that's just a result of the relative age of nqp. 10:13
moritz the string matched by the subrule <foo> 10:14
these things are described in S05
dalek r33188 | moritz++ | trunk: 10:16
: [cage] some more line wrappings in pdd14
diff: www.parrotvm.org/svn/parrot/revision?rev=33188
cotto You're right. I just needed to look more at the context. 10:17
moritz (the prefix ~ isn't described in S05, that's just basic Perl 6 :)
jimmy 122 \t \t=item i_[add|subtract|multiply|divide|floor_divide|modulus|pow]_float(INTVAL b) 10:22
123 \t=item i_[add|subtract|multiply|divide|floor_divide|modulus|pow]_float(INTVAL
124 \tb)
moritz: why ?
seems ugly 10:23
moritz jimmy: it's ugly, but otherwise the coding standard tests fail 10:24
jimmy I see. thought it's really ugly.
moritz it is. 10:25
other suggestions are welcome
jimmy none :) 10:26
moritz I've now done the line wrapping after the =item 10:27
dalek r33189 | moritz++ | trunk:
: [cage] neither line wrapping in pdd14
diff: www.parrotvm.org/svn/parrot/revision?rev=33189
jimmy I don't know what the coding standard is.
moritz see docs/pdds/pdd07_codingstd.pod 10:28
s/neither/nicer/
ouch, my english is too bad
jimmy moritz: me too.
dalek r33190 | fperrad++ | trunk: 10:29
: [parrot_compiler] change PASM registers to PIR registers
diff: www.parrotvm.org/svn/parrot/revision?rev=33190
10:31 gmansi joined 10:46 peansen joined 11:23 kj joined 11:58 iblechbot joined 12:40 ff-wonko joined 12:59 ff-wonko joined 13:05 rkh joined
pmichaud moritz++ # checking lex5 branch for me 13:06
13:13 jimmy joined 13:16 ff-wonko joined
Coke gets close to removing --miniparrot 13:51
it boggles me that we have passing tests for a feature that doesn't work. 13:52
s/feature/option/
msg kid51 I pinged you on the ticket. Thanks for any help!
purl Message for kid51 stored.
13:55 pmichaud joined, PerlJam joined, wolverian joined 13:56 dalek joined 13:57 polyglotbot joined 13:59 jonathan joined 14:00 leo joined 14:03 masak joined 14:15 gryphon joined 14:20 apeiron joined 14:26 PacoLinux joined
jonathan hi all 14:31
moritz OH HAI 14:32
jonathan I can haz Rakudo hacking. 14:33
masak \\o/ 14:34
14:42 Alias joined 14:50 jimmy_ joined
Coke Alias: hio. 14:55
Alias hi
purl hola, Alias.
Coke feels the urge to say "crikey!"
Coke tries to avoid it.
how goes fruity parrot? 14:56
... we are so totally making a breakfast cereal. 14:57
szbalint G'Day mate!
Coke lukcy charms?
lucky charms?
purl, you disappoint.
purl Coke: excuse me?
dalek r33191 | jonathan++ | trunk:
: [rakudo] Eliminate a now-unrequired global.
diff: www.parrotvm.org/svn/parrot/revision?rev=33191 14:58
pmichaud I think the lex5 branch is about done -- testing, please? 14:59
jonathan pmichaud: Were there were any changes since I tested last night? 15:00
pmichaud yes, I think so. 15:01
r33179 was done at 05:47 UTC
jonathan pmichaud: Doing a testing run then.
Oh, I suspect I was sleeping then.
Or trying to sleep.
pmichaud: Advice wanted. 15:03
When generating the code for a routine/param type checks etc it'd be helpful to know if we're in a multi sub or not.
I know that a way is to use a $?OH_PLEASE_NOT_ANOTHER_GLOBAL ;-) 15:04
Any better suggestions?
Coke pmichaud: kicking off a lex5 test on osx/85
er, 86 =-)
pmichaud jonathan: how does it help us to know about multi? 15:05
jonathan pmichaud: For one, I want to stop emitting type checks in the sub itself if we know it's a multi
Because we already determined the sub accepted the types in the dispatcher.
I'd also like to know whether it's a method or a sub, so I know whether to stick an invocant (if one isn't declared) into the signature object.
pmichaud the general approach would be to create a generic signature object, and the adjust that object at a higher level when we know if it's a multi, method, or whatever. 15:06
as opposed to trying to do it all in the signature object part.
jonathan That's possible, if I make a way to make the signature object easily obtainable, I guess. 15:07
In fact, we may already have that...
pmichaud well, parameter passing is high on my list of things to do next.
jonathan Yeah...
pmichaud since lexicals now work :-)
jonathan w00t
masak tests lex5
Coke gets a build failure, and tries a realclean. 15:08
moritz needed a realclean in that branch as well
jonathan just did one before even trying to build
pmichaud: What was your plan on the whole "what does the signature method actually build" issue? 15:09
I'd like to see $?SIG_BLOCK_NOT_NEEDED go away preferably.
particle say what? lexicals work?
pmichaud particle: they work if we can get testing of lex5 :-)
particle on its way 15:10
Coke particle: you get windows. *tag*
pmichaud yes, $?SIG_BLOCK_NOT_NEEDED should go away.
Coke pmichaud: aside from core test, should I also do nqp & rakudo?
jimmy_ masak: what does lex5 mean?
jonathan Well, I didn't want it in the first place, I just didn't have any better ideas.
Coke (known failure in t/pmc/bigint.t)
moritz particle: actually masak's (in)famous for+recursion test passes in lex5/
masak jimmy_: 'the fifth branch fixing lexicals stuff in Parrot'
moritz particle: (if I interpreted the one unexpected passing TODO test correctly) 15:11
pmichaud jonathan: I can't say for sure until I get into it. But I'd like for $( $<signature> ) to just return the right thing.
jimmy_ masak: čÆę³•čµ„ę–™?
jonathan Well, that's the code to make a signature object I guess...
pmichaud lex5 resolves: 56512, 56612, 58392, 58916, 59082, and 60604
jonathan Trouble is we tend to need some code as well.
pmichaud ...like, what sort of code? 15:12
jonathan Like, PAST::Var param nodes.
pmichaud right, those are part of the signature object.
Coke should know about how many tests are in t/ by now.
jonathan What do you mean by that, though?
masak jimmy_: åƹäøčµ·ļ¼Œęˆ‘听äøåŠØ怂
pmichaud do you mean signature object or the signature ast? 15:13
(sorry, I'm getting confused on my end -- still early here.)
jimmy_ lexicals stuff means 'čÆę³•' ?
jonathan Well, thing is we need to build up to two things.
masak jimmy_: I don't know.
pmichaud oh.
jonathan We want to build some PAST that creates the instance of Signature
masak jimmy_: my Mandarin is not that advanced.
jimmy_: it has to do with variables and bindings.
PerlJam masak: haven't you been learning it for 2 years?
jonathan And we also need to build the PAST the creates the .param style stuff - *if* it's the signature for a block or routine. 15:14
PerlJam masak: you should know everything by now! :)
masak PerlJam: two years, and still no talk about lexicals in class!
it's an outrage.
jimmy_ masak: actually, I don't know what deos lexcals stuff mean.
pmichaud my best guess is that I'd like to build up a signature ast (the part that does the .param style stuff), and then when we get to the block/routine we introspect the that ast to build the code to generate the signature object.
masak jimmy_: I'll try to find you a resource.
jimmy_ s/lexcals/lexicals/g
15:14 barney joined
pmichaud if that doesn't work, then we build up both items in parallel 15:14
jonathan pmichaud: That feels the wrong way around to me.
pmichaud jonathan: it really needs to be that way, because of $^a 15:15
moritz jimmy_: lexicals are variables that are only available in a small piece of code, and that scope is known at compile time
jonathan If you write :($x, $y) style things, you want to build a signature object.
jimmy_ masak: lexical analyzer means "čÆę³•åˆ†ęž' in chinese.
jonathan Unless we make sigterm also build the signature out of the PAST made.
masak jimmy_: take a look at en.wikipedia.org/wiki/Scope_(progra...scoping.29
jonathan (As in, the PAST with all the paramters declared in it)
jimmy_ thanks moritz 15:16
pmichaud I guess I could see doing it the other way around, too.
jimmy hi
jimmy_ I know that it is a private var.
jonathan I guess we can factor the signature object out of that, and in sigterm we just throw away the other bit, and in the case of a routine we keep both.
pmichaud I still need to think about it a bit more. And for me, it's writing the code that will give me the correct answer.
i.e., when it becomes too difficult to do one way, I'll know to use the other (or try a third :-) 15:17
jonathan OK
One other thing I was pondering was maybe moving type checks into the dispatcher (when I re-work the dispatcher for the other stuff) even for single dispatch.
masak jimmy_: there are two of you. no, there's not really such a thing as a 'private var'. but you might still have grasped the concept.
jonathan Then we don't have the "should we emit the check or not" worry. 15:18
pmichaud jonathan: would that also include initializations?
jimmy_ the other is me too.
jonathan pmichaud: Example?
jimmy_ but my friend is using my computer. hehe
pmichaud sub foo(Int $a = 3, Num $b = 4.0) { ... }
jimmy this is jimmy 15:19
PerlJam speaking of initializations ... does has $.foo = "hello world" still not work?
pmichaud PerlJam: it still does not work.
Coke pmichaud: lex5 passes core tests, nqp, rakudo, and tcl on intel OS X
jonathan PerlJam: No, but I'm about tired enough of people moaning about that to go refactor the relevant bit of the grammar... ;-)
pmichaud: Perhaps - I guess we should verify such things.
Hmm.
I'm still thinking it all through quite a bit. 15:20
15:20 Zaba joined
pmichaud I think that initializations imply it should still take place in the sub. 15:20
jonathan becuase of the things like sub foo($a, $b where { $a < $b }) { ... } style things.
pmichaud Also, we have the lexical scoping issues discussed yesterday, which also would seem to imply "in the sub"
jimmy_ I don't know what is the difference between lexicals and private vars.
jonathan Yeah. Apart from we've gotta deal with this somehow in the multi case.
pmichaud although wrapper+tailcall doesn't look that bad to me at this point. 15:21
jimmy I think it's the same.
jonathan That's one way...
pmichaud it'll also depend on how the calling_conventions branch shakes out. If we can bind signatures to captures and then pass that efficiently to a sub, it all becomes much easier.
jonathan Yes. 15:22
moritz jimmy: the term "private" is mostly used for object attributes nowadays, but I also know that name for lexicals (from my old programming days :)
pmichaud Coke: (OSX + lex5) Yay!
jimmy thanks moritz.
pmichaud Coke: thanks
jonathan Well, I did already float a while back the "just take a slurpy array and slurpy hash (which one day becomes a capture object instead when Parrot supports those) and then pass them to the signature object to bind" idea.
jimmy actually, i heard lexicals just from perl
pmichaud jonathan: yes, that's still a possibility also. 15:23
jonathan pmichaud: I rather like that idea.
pmichaud I didn't like building the slurpy array and slurpy hash
jonathan OK, but if the direction we're supposed to be going is that Parrot builds and gives us a capture object... 15:24
pmichaud correct
jonathan Which is pretty much what it *is* doing interally now from what I can see.
pmichaud I haven't seen the details of how that's working yet.
jonathan Then we can say "OK, for now we use what Parrot provides us, then it's an easy switch when it does provide a capture"
particle jonathan: isn't that the CallSignature pmc? 15:25
jonathan Then code-gen becomes easy-ish. Build a signature object up. Doing so provides us with a list of variables that this signature binds.
Then emit lexical declarations for 'em.
particle: Yes 15:26
pmichaud ...and attach constraints, also?
jonathan I'm pretty sure what that's doing
pmichaud: Yes, we can have the signature object attach them as it binds, maybe.
Probably most efficient.
Well, maybe. 15:27
You can do it either way I figure.
I'd be tempted to have the signature binding do it in the first cut.
pmichaud I think I'd want the signature binding code to work in its caller's lexical environment directly.
jonathan Speed? 15:28
purl hmmm... Speed is too subjective, I think.
pmichaud yes, but also because then the signature is doing its work directly on the sub's lexicals.
which is where it should be doing its work. 15:29
maybe we need this in two steps
jonathan Then we're basically back to generating code in the sub itself to unpack the sig. :-)
Which is OK too I guess.
pmichaud no, I'm thinking the sub can do a method call on the signature object 15:30
jonathan So was I.
OH!
I mis-interpreted what you said, I think.
jimmy F:\\pipp\\parrot-dev\\docs>make html
make: `html' is up to date. 15:31
jonathan When you said you wanted the signature binding code to work in its caller's lexical environment directly, what exactly did you mean?
nopaste "tewk" at 155.97.237.62 pasted "lex5 passing TODOS" (8 lines) at nopaste.snit.ch/14718
masak pmichaud: three failed tests in t/pmc/bigint.t on the lex5 branch. but maybe that's to be expected.
pmichaud I meant in the sub's lexical environment, assuming that the sub is the 'caller' to the signature
yes, that was ambiguous
masak: the bigint.t failures are expected, I think.
15:32 Andy joined
jonathan OK, so it'd take the LexPad of the caller and just do keyed access? 15:32
pmichaud jonathan: yes.
jonathan Oh, OK
Then we were thinking the same thing. :-)
I thought you might have meant a different thing.
pmichaud I still don't know how to make {...} things work, though.
jonathan Phew. :-)
{...} ?
pmichaud $a where { ... }
such that the { ... } is properly lexically scoped. 15:33
jonathan Maybe for the single dispatch case we should leave the checking done in the sub itself. Can we just capture_lex such blocks before calling the !BIND or whatever we call it method on the Signature? 15:34
pmichaud <brainstorm> what we _really_ want is:
when we bind to a signature, that creates a new context and lexpad based on the sub that is being called. We haven't invoked the sub yet, though. 15:35
jonathan Yes.
pmichaud then when we call the sub, it simply "adopts" the context that was built in the bind.
15:35 Lorn joined
jonathan Yes. 15:35
That way occured to me.
Another approach was (maybe too evil) 15:36
That a multi with subtypes to check gets code emitted to bind the signature and then throw a resumable exception.
The dispatcher calls all of the possibilities and sees which throw "cannot bind" exceptions and which throw resumable "I'm OK" exceptions
pmichaud oooh 15:37
jonathan Then it just resumes the one it decides on, if there is one.
pmichaud I kinda like that.
jonathan *If* we can do it without making Parrot explode, it would be rather neat.
particle seems a natural parrot way to do it, in fact 15:38
pmichaud another item: are we going to expect that rakudo subs will be called by other than the rakudo dispatcher?
s/will/may/
jonathan For the single dispatch case: if we leave all the checks inside the sub rather than doing them in the dispatcher it'll just work. 15:39
For multiple dispatch case: they call invoke on the multi-sub - which does the Rakudo dispatcher anyway.
So I think it'd Just Work.
15:39 davidfetter joined
pmichaud so we'd need to generate separate code for multi vs non-multi 15:40
jonathan Yeah, but actually maybe it's not so bad.
pmichaud I'm thinking it might not be.
jonathan Just a !BIND_SINGLE and !BIND_MULTI on the Signature.
pmichaud in the multi case, is it ever possible to try to grab a specific sub from the multi and call it as a single-dispatch? 15:41
jonathan You can do things like &foo<Int,Num>
pmichaud ...that wouldn't go through the multi dispatcher, right?
jonathan *but* I'm not sure that's promised you'll still get anything unique from that.
Because the thing is that that form may still leave many possibilities. 15:42
pmichaud so what does that do, exactly?
jonathan I'd be happy enough for that form to return a Perl6MultiSub that just has the possibilities in it.
Basically it finds all candidates that would match being dispatched with an Int and a Num.
pmichaud does that only do type checks, or does it include where clauses? 15:43
jonathan No, because where clauses check values, not just nominal types.
(e.g. type checks)
pmichaud so, would &foo<3, 5> get me all of the subs that would dispatch with a 3 and 5 ?
jonathan I don't remember seeing that in the synopses 15:44
pmichaud or are we limited to protoobjects in there?
jonathan I can only recall the case where you stuck type names in there.
I guess protos or maybe role names will fly too
I'm not sure what on earth happens if you put a named subtype in there... :-| 15:45
pmichaud I guess i'm asking, would &foo<Int> match multi sub foo(Int $x where { $x % 2 == 0 }); ?
jonathan Yes
I believe so
pmichaud so the where clauses don't participate in the matching.
jonathan AFAIK, they don't.
pmichaud that's a bit surprising.
jonathan tries to find the relevant bit of synopsis 15:46
pmichaud okay, here are my initial thoughts then 15:47
overall I like the idea of doing the bindings as a method call on a signature object
I think we should do that even for single dispatch -- in the single dispatch case, the (Parrot) sub simply takes the params, binds them to the signature, and then calls the signature to import the results into the current lexical scope 15:48
as opposed to generating code to do it.
jonathan Yes, agree.
Oh, I wasn't advocating doing that differently. I was only questioning whether we do the type *checks* for nominal types in the dispatcher or in the binder for single dispatch. 15:49
I wasn't thinking binding would differ besides that. 15:50
pmichaud I can argue that one both ways.
I need to think about it a bit.
particle Bug: Attempting to mark dead context 11f65f0 15:51
pmichaud particle: you _must_ be running lex4, or a very outdated copy. 15:52
the "attempting to mark" is gone from the branch.
particle aha, yep, i never switched on my ubuntu x64
jonathan pmichaud: I can argue it both ways too.
particle so far, win32 passes core, nqp, and i'm doing rakudo spectest now
jonathan pmichaud: My main clincher for doing the checks in the binder for single dispatch is interoperability with other languages. 15:53
pmichaud jonathan: agreed there.
is there a way for a sub to know if it's being called from the multidispatcher?
jonathan pmichaud: OTOH, if we are putting the custom dispatching stuff in by overriding the invoke VTABLE and having our own PMC type for subs (no, *not* one for everything!)...which I am pondering doing...
Then invoke would do the right thing anyway. 15:54
pmichaud if we could make it possible for a sub to detect that it's being called from the multidispatcher, then we put all of the checks inside of the sub 15:55
if being called from the multidispatcher, it throws a resumable exception saying "checks passed"
jonathan Hmm.
pmichaud if being called as single-dispatch, it simply keeps going.
jonathan Off the top of my head, not completely sure where we'd stick that flag.
pmichaud does it have to be a flag? 15:56
can't the sub check the identity of its caller?
surely there's some level of introspection we can have for this. :-)
jonathan Thing is, the dispatcher doesn't really call it, as such.
The invoke VTABLE method hands back an opcode_t specifying where to continue execution. 15:57
pmichaud how about a property on the sub? ;-)
I see.
jonathan Not unless you want to have to go refactor it when we start invoking the same sub in many threads...
So in a multi we chosoe the variant we will invoke, and call its vtable invoke 15:58
For the subtype case we'd finish up by actually doing a vTABLE_invoke on the continuation from the winner.
And falling back into the original runloop at the right point. 15:59
pmichaud doesn't "choose the variant" involve some code execution, though?
jonathan Yes. 16:00
But we do that by forcing it to run that there and then.
16:00 gmansi joined
jonathan Parrot_run_meth_fromc_... 16:00
pmichaud we can't force the sub itself to run that there and then?
install a handler, invoke the sub, wait for it to return an exception (which it must do). 16:01
after getting the exception, save the exception and go to the next sub in the list
when we've gotten them all, resume the exception from the sub with the best match. 16:02
jonathan Yes.
That's the plan.
Or, what I'm thinking would be a good plan, anyway.
pmichaud within the sub, it processes arguments and does argument checking, and _if_ it's being called as a multisub it throws an exception when that's done.
.....OR!!!!
jonathan No, if it's being called as a multi sub it maybe only does subtype checks. 16:03
We do the nominal type stuff in the dispatcher.
pmichaud I'd like verification that we only do type checks for multis.
why not do it all in the sub?
we could do nominal type stuff as an optimization in the dispatcher, yes.
jonathan Well, it's also the optimization that enables caching to work out. ;-) 16:04
But more seriously
We sort by nominal types etc. 16:05
The code is already in place to do all of that.
(Which isn't a "it works so we shouldn't change it" argument, but rather "it works so undoing it only to do it as a future opt" seems odd).
We can do nominal type checks in the single dispatcher too for consistency, if you're happier that way. 16:07
Provided we make our own Sub PMC type it can work out.
Even in the language interop case.
pmichaud yes.
I need to brainstorm it just a bit more in my head. 16:08
jonathan OK.
16:08 Hadi joined
pmichaud a _lot_ more stuff makes sense now, though. 16:08
jonathan This is fitting together quite nicely from my side. :-)
pmichaud same here.
I just want to decide how I want to build the object in the parser.
jonathan Yes.
pmichaud *signature object
jonathan That wants some thought.
16:08 Hadi left
jonathan Since we'll want to be able to easily introspect the PAST to pull out stuff we need to declare. 16:09
pmichaud I know the grammar for signatures has changed a bit, so I need to review it as well.
jonathan Yes.
pmichaud actually, I don't think it's a problem to do that any more.
jonathan OK
pmichaud if the signature object is the thing that attaches constraints, there's no need for the sub to have to duplicate that.
jonathan See sig_extract_declarables for some (maybe bad) ideas.
Oh yes, indeed. 16:10
pmichaud and that's true for all lexicals, not just parameters.
jonathan Yup
So my ($a, $b) etc just falls nicely out of it.
pmichaud which is where I've been headed from this to begin with. :-) 16:11
and that's why I was asking about initializations
16:11 ff-wonko joined
pmichaud because initializations are part of the signature. 16:11
jonathan Aye.
OK, this is looking promising.
pmichaud I don't want to hold you back on stuff, but I would like to take a crack at signature parsing in the next day or two. 16:12
it really is the next item on my plate to look at (and why I wanted lexicals to work, because it's all kinda useless without them.)
jonathan That is fine for me. 16:13
pmichaud thanks, this _really_ helps clarify things for me a lot. I think we have a plan.
jonathan I think we have enough of a shared vision on where we want to go with this.
pmichaud "jinx!"
jonathan So I'm completely comfortable leaving you to handle that side of things. 16:14
pmichaud same to you on the multidispatch side.
this can work out *really* well. :-)
jonathan Awesome.
pmichaud so, how's that lex5 branch looking?!? ;-)
jonathan I've worked out pretty much how auto-threading is going to fit very neatly into this too.
pmichaud autothreading++
jonathan erm, I got a bit tied up in this discussion and forgot to keep running tests ;-) 16:15
Parrot and NQP fine
Rakudo ones happening now
masak crosses fingers
pmichaud I really do think that lex5 fixes it.
when we get a generational gc (and convert over to using it), we'll get a nice speed boost. 16:16
particle pmichaud: i'm on S29-array/push.t atm
pmichaud right now a gc sweep ends up going through every context
okay, I have an errand I *must* run right now, I'll be back in 20 or so
jonathan (auto-threading in a sentence: we'll have an !AUTOTHREAD thread sub that does a level of threading by the S09 criteria; if we need to do an auto-thread then we clone this and attach the sub we were originally calling as a property to the clone) 16:17
OK
Will have spectest results for when you return.
pmichaud ...why clone? Why not just invoke !AUTOTHREAD ? 16:18
and pass the sub as a param?
(this is what junctions are doing now.)
bbiab
jonathan pmichaud: Ah, yes 16:20
That may work too
particle i got 43 failures in rakudo
increment's 41 we expect *blech*
S06-signature/slurpy-params.t fails 2 16:21
jonathan pmichaud: Yes, and 2 from declarattion-order?
Oh.
oops, s/pmichaud/particle/
particle yeah, i expected declaration-order, not slurpy-params :(
PerlJam I didn't get any failures in S06-signature/slurpy-params.t
particle current instr.: 'die' pc 12219 (src/gen_builtins.pir:7463) 16:22
called from Sub '!TYPECHECKPARAM' pc 13133 (src/gen_builtins.pir:8011)
called from Sub 'x_typed_join' pc 1259 (EVAL_13:396)
jonathan That's...interesting.
particle > sub x(Int *@args){1}; x(1); 16:24
Parameter type check failed
jonathan wonders why that would work anywhere 16:25
Given that we don't have typed arrays yet.
That doesn't fail here. Very, very strange. 16:26
16:26 hercynium joined
jonathan (the test, that is) 16:26
particle it doesn't fail in lex5 there?
jonathan For me in the REPL
> sub x(Int *@args){1}; x(1);
Parameter type check failed
The test doesn't fial in lex5, no
I'd not expect this code to work yet. 16:27
(As in, it shoudln't fail, but it will until we get typed arrays)
particle odd that it fails here, then, although my failure seems correct
jonathan Question is why it doesn't fail elsewhere
particle right
jonathan We both get the same error with that code in the REPL 16:28
particle are types parsed but ignored for arrays?
i'm rebuilding trunk now to test that
jonathan No, it tires to do a type check
*tries
But it doesn't know how to type check arrays yet.
So it just fails.
particle fails in trunk repl
jonathan OK. So we all consistently fail it in the REPL.
But the test file behaves differently. 16:29
particle lemme check ubuntu
moritz if in doubt, don't trust the REPL
jonathan particle: In the test file 16:30
#?rakudo skip 'types on slurpy params'
So why on earth you're running that when it should be fudged is a mystery.
particle hrmm, i don't have that line here
jonathan :-S
particle oh, i know...
Coke repl? 16:31
purl repl is Read Eval Print Loop
particle i ran tools/test_summary.pl, which *doesn't* update t/spec from svn
jonathan pmichaud: lex5 tests pass as in trunk
particle: Oh. :-)
pmichaud ...all is well so far?
jonathan pmichaud: I've checked parrot tests, Rakudo test, Rakudo spectest and NQP. All good. 16:32
particle pmichaud: i'm rerunning rakudo spectest, i ran an old rev of t/spec :(
16:32 workbench joined
jonathan Test*er* fail! 16:33
particle i blame the tools
masak my lex5 spectests just finished too.
particle why doesn't test_summary.pl update t/spec?
jonathan What's that saying about "a bad workman..."? ;-)
pmichaud ...because it's not run from 'make'? 16:34
masak 41 failed in t/spec/S03-operators/increment.t and 41 failed in t/spec/S04-statements/for.t
s:2nd/41/43/
pmichaud ...for.t?
that seems new.
masak aye,
moritz particle: because sometimes we want to run old versions, to update docs/spectest.data for example
masak pmichaud: I'll nopaste it for you. 16:35
pmichaud also I run old versions to generate the spectest-progress
masak: try running from command line
I'm thinking it's a harness bug.
moritz erm yes, spectest-progress, that's what I meant
masak pmichaud: you think correctly. all pass.
pmichaud okay, not a blocker.
jonathan smells a merge coming on 16:36
16:36 jhorwitz joined
tewk Merge baby merge :) 16:36
masak has the champagne ready
Coke is sad that tcl isn't using this. =-)
16:37 leto_ joined
tewk Well I'm not sure its going to help speedwise, but at least it will be correct. 16:37
masak Coke: tcl doesn't do recursion in for loops?
pmichaud tcl doesn't use parrot's lexicals.
masak ah. 16:38
well, good for tcl! :)
pmichaud I know this because I once went looking to see how partcl was able to get lexicals to work, only to discover it wasn't using Parrot's lexicals at all. :-| 16:40
tewk What does tcl do?
pmichaud it keeps a hash
moritz perhaps because they didn't work? :-)
pmichaud and manages it directly
moritz: that's part of it, but tcl also needs dynamic lexpads
tewk ah, right. 16:41
Coke [uplevel] sucks immensely. =-)
but it's probably implementable using parrot. I don't think anyone who could fix it is interested in working on tcl over perl6, though. =-) 16:42
tewk pmichaud: how close is perl6 to operating on PIR objects, say I have a ncigen AST tree that I want to maniuplate from perl6.
Should I just use nqp
pmichaud either should work.
The trick is that both expect to have protoobjects as handles. 16:43
16:43 dngor joined
pmichaud if the ast tree is being generated by PCT, then it all Just Works. 16:44
tewk It's not PCT, but I'm using P6metaclass
pmichaud that's good enough.
tewk cool, tewk plans on digging into perl6 this evening. 16:45
pmichaud either rakudo or nqp should work. We still may need a bit more glue here and there but that can happen quickly.
tewk ncigen + perl6 is going to generate SQLite PIR bindings. 16:46
pmichaud most excellent
I look forward to that.
particle that seems like an odd dependency
pmichaud I still need to see about troubleshooting lathos' assignment issues.
jonathan With the unmanaged struct stuff?
pmichaud yes.
tewk I don't think we are using umanaged stuct stuff no, but might have to again in the future. 16:47
We are using the Pointer PMC in a unmanaged struct style though.
particle tewk: as a proof-of-concept, using perl6 seems nice, but when rakudo leaves the repo you'll need to use nqp 16:48
jonathan tewk: How are structs handled at the moment with ncigen?
tewk jonathan: they aren't :), they are parsed, but I'm not generating ManagedStructs yet.
jonathan Ah, OK. 16:49
tewk a lot of structs in c libraries are opaque to PIR, so it hasn't been a blocker yet.
jonathan The Perl 6 view of this kinda thing is that a struct is a class that has all native types.
I don't think we'll get to looking at that for a little bit though. 16:50
tewk Early on all we need is pointers.
jonathan Sure.
pmichaud okay, anyone have any reason I should hold the merge?
Coke holds his peace.
16:50 Whiteknight joined
tewk Merge, the sooner its it the sooner someone will start toying around with GC'ed contexts 16:50
16:51 Theory joined
tewk particle: thats one reason I thing we should keep pbc of common languages in the repo. 16:52
Build tools should eventually be written in HLLs
pmichaud ...and NQP is probably not H enough for general-purpose tool building. 16:53
otoh, the build tools can be compiled to .pbc and *those* can go in the repo :-)
tewk Once you have ruby, rakudo, or python, why would you want to go back? 16:54
pmichaud (might still need the .pbc of the HLL library, though.)
tewk :)
Coke tewk;back to perl? excellent question.
tewk back to nqp, pir
Coke (joke) 16:55
tewk ;) 16:56
pmichaud initial merge done, testing. 16:58
dalek r33192 | jonathan++ | trunk: 16:59
: [rakudo] Recognize ;; parameter separator; set invocant and multi_invocant fields in the signature.
diff: www.parrotvm.org/svn/parrot/revision?rev=33192
17:00 AndyA joined 17:03 ambs joined 17:07 ruoso joined
particle pmichaud: only increment.t failures, so okay by me to merge 17:09
pmichaud excellent. I had one or two codingstd fixes to make, so a final 'make test' and then commit.
particle better svn up after jonathan's commit
pmichaud already got it. :-)
particle i don't see any bonus tests listed in test_summary.pl 17:10
pmichaud test_summary.pl doesn't really report bonuses (yet)
there's one.
particle are they not listed at all, ah.
jonathan pmichaud: I guess after this merge there will be a bunch of spectests that begin working, though? 17:12
pmichaud jonathan: could be -- I haven't seen it or checked.
particle i'm checking now
pmichaud I do know that it closes six rt tickets.
particle should take a while
jonathan If not, the RT tickets that it closes should turn into tests I guess.
pmichaud (at least six.)
jonathan Assign them to moritz! ;-)
pmichaud I'm not too worried about all of them becoming tests. They were all different manifestations of the same problem. 17:13
i.e., I don't need to come up with tests for every way that array slices can fail when they're not implemented. :-)
particle tools/autounfudge.pl --auto # running now
jonathan pmichaud: OK, so long as we have enough coverage to not regress. 17:14
:-)
pmichaud the recursive for test has made it into the spectests, so that's pretty good.
tewk If they would be valuable to the the context refactor, I would add them now.
pmichaud merged, r33193. 17:15
bug reports welcomed -- send them to /dev/null. :-P
dalek r33193 | pmichaud++ | trunk:
: Merge lexicals branch into trunk. "make realclean" required (new opcodes).
diff: www.parrotvm.org/svn/parrot/revision?rev=33193
tewk pmichaud++
pmichaud time for lunch -- I'll be back for parrotsketch (starts in 75) 17:16
moritz pmichaud++ indeed 17:19
(for all lurkers, after r33193 you have to 'make realclean', otherwise you'll get build failures) 17:20
oh, it even says so int he commit message
moritz should start reading first ;)
masak pmichaud++ 17:21
...many times over.
I'll email the November list.
jonathan pmichaud++ indeed 17:22
17:30 ambs left
masak pops champagne bottle 17:30
17:33 chromatic joined
chromatic might be late to #ps 17:33
nopaste "tewk" at 155.98.69.7 pasted "known failure? t/spec/S12-class/declaration-order.t" (38 lines) at nopaste.snit.ch/14721 17:36
jonathan tewk: Yes. 17:37
moritz there's a ticket for that 17:38
tewk trunk passes all tests parrot and rakudo 17:41
17:46 gmansi joined
PacoLinux same for me (and 21 second less in making trunk tests ? :) ) 17:55
18:06 rurban joined
jhorwitz preposted my status in #ps 18:08
Infinoid hum. 18:09
# Failed test 'nci_vV - char** out parameter' 18:10
# at t/pmc/nci.t line 2707.
# Exited with error code: [SIGNAL 3]
# Received:
# Parrot VM: PANIC: vV is an unknown signature type.
18:13 cognominal joined
Tene Which spectests pass now that didn't pass before the lexicals merge? 18:18
pmichaud: did you add a parrot test to test lexicals behavior?
moritz Tene: I unfudge one in for.t
Tene: and autounfudge is currently running, and finds more
Tene Ah. Nice. 18:19
particle moritz: i'm running it too, ...slowly...
jonathan Parallel unfudging!
particle if only we weren't running over the same data :) 18:20
moritz particle: I'm already at S29
particle moritz: i'm at S04 more than 1h later
moritz jonathan: actually with --jobs=2 you can parallelize autounfudge ;)
Tene can I --jobs=8 ? 18:21
moritz Tene: sure you can.
Tene builds parrot.
Tene builds rakudo 18:22
rurban switches to git
Tene rurban: let me know if you run into any issues. I've had to deal with most of them. :) 18:23
rurban First I have to understand the basics
keeping a branch with svn in sync is way too much work for me.
Tene Aw. My work's dev box doesn't have TAP::Harness. :( 18:24
moritz particle: I've applied (parts of) autounfudge now locally, and I'm testing right now
particle okie
tewk Infinoid: add vV to config/gen/call_list/misc.in 18:31
jonathan Arrrgh. 18:33
jonathan creates a segfault 18:34
cotto jonathan is in good company
masak aye. 18:37
Infinoid tewk: I'd love to, I just don't understand the syntax of that file. 18:39
jonathan won't commit this patch
Damm. This is teh suck...
18:42 rurban_ joined
cotto errand & 18:44
dalek r33194 | moritz++ | trunk: 18:46
: [rakudo] add tests for [perl #60404] to t/spectest.data
diff: www.parrotvm.org/svn/parrot/revision?rev=33194
barney pmichaud: Could you take a quick look at $?INIT in languages/pipp/src/pct/actions.pm ? 18:50
It doesn't behave as expected with t/php/oo_2.php 18:51
Tene pmichaud: rt 58854 needs to be fixed.
pmichaud easier is now to add things using the loadinit attribute on PAST::Block
Whiteknight wouldn't you know that the repair guy shows up exactly when #ps starts?
Tene newclosure workaround for gather blocks.
18:53 alvar joined
barney pmichaud: I'll look into loadinit. Still it looks like $?INIT should have been set, but is undefined in the method TOP 18:53
tewk Infinoid: added 18:55
jonathan -> nom
tewk svnup
pmichaud barney: is class_constant_definition being called?
dalek r33195 | tewk++ | trunk:
: [NCI] added "vV" signature
diff: www.parrotvm.org/svn/parrot/revision?rev=33195
rurban www.parrotcode.org/release/devel still points to 0.8.0 18:56
nopaste "barney" at 84.154.59.31 pasted "No $?INIT, but class_constant_definition() was called" (56 lines) at nopaste.snit.ch/14723 18:57
barney Yes, it emits an empty block with name 'class_constant_definition'
pmichaud there is no defined( ... ) function in PCT. 18:58
are you planning for it to use one from PIPP?
19:00 Hadi joined, Hadi left
pmichaud ...and the INIT block *is* in the nopaste you just showed me. 19:01
so that part's working.
Coke I see we have no tweety.
barney pmichaud: where is the $?INIT block ? 19:02
pmichaud oh wait, maybe not.
I was thinking the PAST;Block with the :init :load flags was it. 19:03
btw: for $<sea_or_code> {
looks very funny to me.
is $<sea_or_code> a match object?
if so, you might want @($<sea_or_code>)
barney pmichaud: If i remove the defined check in actions.pm I get: Method 'blocktype' not found for invocant of class 'Undef' 19:05
pmichaud yes, that sounds a lot like an undef. hrm. 19:06
barney for $<sea_or_code> is like in the Rakudo actions.pm 19:07
I tried to a add a testcase in complete_workflow.t, but It works as expected there
pmichaud okay.
oh, $<sea_or_code> is an array of matches.
yes, that's okay. 19:08
dalek r33196 | infinoid++ | trunk: 19:09
: [ops2pm] Fix a mkdir race condition when running with "make -j".
diff: www.parrotvm.org/svn/parrot/revision?rev=33196 19:10
19:14 apeiron joined
nopaste "pmichaud" at 72.181.176.220 pasted "$?INIT is being set properly (for barney)" (52 lines) at nopaste.snit.ch/14724 19:16
masak rakudo: my $a = 5; $a = [ $a, 6 ]; say $a 19:17
polyglotbot No output (you need to produce output to STDOUT)
masak on #perl6 and in November this now creates an infinite regress
that can't be right, now can it?
pmichaud we don't have list interpolation done yet. 19:18
masak ah.
so how do I write the above in current Rakudo>
?
pmichaud could try +$a
masak or ~$a
pmichaud barney: is looks as though defined( ... ) on the PAST::Block is returning false. 19:20
(in TOP)
19:20 Hadi joined
pmichaud it's looking in php_constants for "Hash[0xb74a238c]" (the stringification of the PAST::Block node) and not finding it. 19:20
19:21 Hadi left 19:22 Hadi joined, Hadi left
pmichaud bbiab 19:22
barney pmichaud++
dalek r33197 | bernhard++ | trunk: 19:42
: [Pipp]
: Fix support for class constants.
: Do not use the PHP function 'defined' for definedness of a PIR register
diff: www.parrotvm.org/svn/parrot/revision?rev=33197
barney cotto: I'll look at '--target=pir' tomorrow. 19:43
cotto thanks.
masak pmichaud++ # closing a lot of tickets 19:44
cotto How good are you with actions?
masak who, me? 19:45
cotto I have a grammar that parses opening/closing tags, but it's taking me a long time to wrap my head around what actions.pm should look like.
no, barney
masak ah.
barney Not very. Problem is mostly to know which PAST to generate
cotto I'll keep hacking at it, then.
barney actions most likely need to know the tagstyle, for deciding whether to echo the last value 19:48
cotto you mean first?
as in <?="foo"; $i++;?>
barney Or first. I'm pretty bad with PHP
cotto lawl 19:49
19:49 Whiteknight joined
barney cotto: yes 19:50
I'm still astonished that this isn't a PHP syntax error 19:51
maybe do the same as in <?php echo "foo"; $i++ ?> 19:53
bacek good morning 19:54
cotto yes, those two produce identical output
bacek pmichaud++ !!!
barney if tagstyle == '<?=' then wrap an 'echo' around the first child 19:55
cotto basically
purl it has been said that basically is the might have on one side justified is ribasushi's question
cotto no, basically is <reply>
purl okay, cotto.
barney like it is done in the method 'arguments()' and setting :name('echo') 19:58
cotto yes. Pipp currently handles <?= correctly (for simple cases, at least). 20:00
PerlJam isn't that being deprecated? 20:01
dalek Krishna Sethuraman | Parrot Development on Windows:
link: www.perlfoundation.org/parrot/index...on_windows
cotto PerlJam, you mean <?= ? 20:05
dalek r33198 | pmichaud++ | lex3: 20:14
: Removing obsolete branch.
diff: www.parrotvm.org/svn/parrot/revision?rev=33198
r33199 | pmichaud++ | lex4:
: Removing obsolete branch.
diff: www.parrotvm.org/svn/parrot/revision?rev=33199
r33200 | pmichaud++ | lex5:
: Removing obsolete branch.
diff: www.parrotvm.org/svn/parrot/revision?rev=33200
r33201 | pmichaud++ | lex2:
: Removing obsolete branch.
diff: www.parrotvm.org/svn/parrot/revision?rev=33201
GeJ Good morning everyone
PerlJam cotto: aye 20:15
masak GeJ: evenin' 20:17
particle stop trying that mind trick on me, GeJ, it's still yesterday here. you can't convince me it's tomorrow already! 20:18
cotto PerlJam, Where'd you see that? The manual (which usually mentions such things) doesn't say anything.
GeJ hej masak
masak hej :)
GeJ particle: sure I can... and if it's any consolation, I can already tell you that tomorrow looks pretty nice. warm and nice. 20:19
masak refuses to believe that 20:20
there's snow everywhere! 20:21
pmichaud I have seen the future and it can be summed up in just one word... "Plastics."
GeJ checks outside.
masak: no there isn't!
masak pmichaud: :D
GeJ: check again.
it's that white giant sheet outside
20:22 Debolaz joined
GeJ blue liquid thingy all around, check! whitish dust that goes in the shoes and socks, check! blue intangible stuff above the head, check! big hot yellow ball in the blue stuff, check! 20:24
see, no snow in here.
20:24 sjansen joined
jonathan is return 20:30
Infinoid no big hot yellow ball here
bacek GeJ: you jocking! There is clouds everywhere!
jonathan My snows are gone. :-(
Infinoid there will be moar
Coke ~/ This was a triumph /~ 20:32
pmichaud bright yellow ball here, not so very hot.
Coke all day rain here.
(expected snow this evening as temps drop)
Infinoid snow tonight here too
pmichaud afk # pick up kids from skool 20:33
Coke leaks memory.
Infinoid o/~ I'm making a note here: HUGE SUCCESS
Coke Infinoid++ 20:34
is the vtable_self branch done? 20:35
Tene pmichaud: can I get you to look at r31136? That was a lexicals workaround that needs to be addressed now. 20:42
I don't have the concentration available today to think about this and figure out what happened on the lexicals branch. 20:43
Coke 580+41 20:46
purl 621
Tene karma tene?
purl tene has karma of 310
dalek r33202 | chromatic++ | trunk:
: [src] Promoted some MMD and NCI STRINGs to cached constant strings. This saves
: 426 (or 17.39%) STRING creations from "Hello, world!" startup. It's a very
: modest performance improvement there, but the fewer GCable elements at the
: start, the fewer GC runs -- and the faster Parrot starts.
diff: www.parrotvm.org/svn/parrot/revision?rev=33202
Coke what's the difference between CONST_STRING and const_string ? 20:47
Tene 31*5*2
purl 310
chromatic CONST_STRING constants have to be compile-time constants in the source code.
Coke ah 20:48
Tene 311 is prime. Dammit, I wasn't going to work on parrot today.
chromatic That's a subtle naming distinction which should not be so subtle.
jonathan pmichaud++ # posting on rakudo.org too 20:49
allison chromatic: yes, the lowercase version needs a more explicit name (as do many of our string functions)
chromatic: (adding to strings tastlist)
chromatic ****ing_const_string
Though I don't like gerunds where verbs should be. 20:50
Coke CONST_CONST_STRING and DYNAMIC_CONST_STRING. ;)
pmichaud Tene: I've already started it -- just waiting for spectest to finish. 20:51
...which it did while I was out getting kids.
allison CONST_STRING_MACRO and Parrot_str_build_constant_string
chromatic _MACRO? 20:52
Doesn't HAI_I_AM_UPPERCASE signify that enough now?
allison chromatic: just being overly verbose
it is more than just an ordinary macro, though 20:53
chromatic Hm, removing PARROT_EXPORT from vtable subs in C improves startup by 38.14%.
dalek r33203 | pmichaud++ | trunk:
: [rakudo]: Remove gather workaround introduced in r31116 (RT #58854, Tene++)
diff: www.parrotvm.org/svn/parrot/revision?rev=33203
Tene karma tene?
purl tene has karma of 311
Tene Much better.
allison like 'CONST_STR_FILE_ENTRY' 20:54
pmichaud there... got you your prime and you didn't have to do any work. :-)
Tene :)
chromatic "Hello, world!" in PIR is only 154 times slower than "Hello, world!" in C, mostly thanks to startup time. 20:55
Previously it was 250 times slower.
Tene moritz: do you remember how you made gather/take break earlier? Did you commit a test for it? Can you check to see if it works now?
allison chromatic: startup time is something we'll have to work on over time
pmichaud what's the speed difference for perl 5 ? 20:56
that's perhaps a more accurate comparison.
chromatic 26 times
pmichaud perl 5 : C == 26 : 1 ?
allison chromatic: is it worth doing a general cleanup/removal of PARROT_EXPORT tags? 20:57
pmichaud also, are you profiling the .pir or the .pbc ?
chromatic PIR.
pmichaud so, that includes compilation time. okay.
Coke ohoh, can I do tclsh85 to partcl? =-)
20:57 Whiteknight joined
Tene Coke: yes plz. 20:58
Coke: is it fast or slow?
Coke for "puts hi":
Tene >.>
chromatic PIR is 1.73 times slower than PBC.
jonathan chromatic: Should check that dynamic extensions still work after removing those.
Coke .177 / 0.014
purl 12.6428571428571
chromatic jonathan, they don't work.
Coke huh. that's not as slow as I thought.
chromatic I'm not checking this in yet.
jonathan chromatic: I feared so. :-|
Coke but when you add in anything real, it's MUCH slower.
jonathan chromatic: I'm trying to remember why we need to export them all. If the call is through the vtable...or is the problem that the call isn't always through the v-table? 20:59
chromatic jonathan, the problem is initializing their vtables in the PMC-specific init functions.
They use raw C function pointers in ancestor PMCs. 21:00
Mostly they need a way to grab the ancestor's PMC vtable, copy it, and stuff their own (could even be static) function pointers in the table.
We still export some 2700 symbols from our shared library.
43% of startup time is dynlib relocations.
jonathan Ouch. 21:01
chromatic 26.11% of startup time is initializing core PMCs.
21:01 nopaste joined
chromatic 8% of startup time is initializing BigInt and Integer. 21:01
jonathan wonders why we spend 26% of our time doing that 21:02
allison chromatic: possibly a quick optimization there
jonathan: building vtables and C-level MULTIs, likely
chromatic Parrot_mmd_add_multi_list_from_c_args. 21:03
That itself is 17.49% of startup time.
Called *six* times.
allison some of that can be delayed, just cache the data and process it when the mmd is actually invoked
chromatic Each call is ~3% of startup time.
tewk chromatic: its possible to fix those dynlib relocations at build time by telling the linker to be smart, no
allison chromatic: yeah, but it doesn't do all the work every time it's called 21:04
chromatic tewk, I would think so.
tewk I know you can on windows,
kde has fixed the dynlib problem before, too, now that I think about it. 21:05
chromatic I wonder how much -fPIC hurts us (not that we can get rid of it).
moritz Tene: I don't know which breakage you mean 21:06
dalek r33204 | pmichaud++ | trunk: 21:07
: [pge]: accessing vtable functions by name is now deprecated (RT #60384)
diff: www.parrotvm.org/svn/parrot/revision?rev=33204
Tene moritz: there was a lexicals issue with gather/take that you reported a while back.
moritz Tene: chances are that it was actually masak, because he actually uses that stuff ;) 21:08
Tene ... oh, right, there are TWO people with m-names.
pmichaud I think it was masak.
Tene I'm really not awake today. :/
Sorry.
pmichaud I'm not sure it ever got filed as a ticket.
or a spectest.
purl i think a spectest is only helpful for people hacking on partcl at this point, i think.
tewk en.wikipedia.org/wiki/Prelink
21:12 Limbic_Region joined
Limbic_Region pmichaud++ # lexicals finally work properly 21:12
Tene pmichaud: are you planning a more significant blog post?
pmichaud Tene: not at the moment... do I need one? 21:13
Limbic_Region $everyone_who_contributes++ # because it is mostly a thankless job that everyone wants done but few are willing to do
Tene I'd be interested in a summary of what has changed. I can probably get it from a diff or something with more work, though.
Just curious.
pmichaud with respect to lexicals? Bottom line is that they work. :-)
moritz ;)
pmichaud how they work is currently at www.pmichaud.com/perl6/lexical.txt 21:14
I might need to update that a bit to match reality, since that was the design idea behind it
for example, the handling of autoclose changed slightly
I could turn lexical.txt into a blog post, yes. 21:15
probably for parrotblog
Tene It would be good to have documentation of the lexicals system in docs/ somewhere too
Limbic_Region assumes state is still broken or unimplemented though?
moritz state is NYI, right
dalek r33205 | Whiteknight++ | calling_conventions: 21:16
: [calling_conventions] update to trunk r33195, fixing a few conflicts and adjusting for a few changes. Still doesn't pass that test, however
diff: www.parrotvm.org/svn/parrot/revision?rev=33205
pmichaud one of the milestones is updating pdd20
jonathan pmichaud: Would be good to have it turned into a PDD. ;-)
Limbic_Region remembers pointing out to Jeff Horowitz at YAPC::NA how one of his examples would be better done with state before he knew it wasn't implemented
Tene Right, there's a PDD for it! 21:17
Clever.
jhorwitz perks up
pmichaud that pdd needs to be rewritten.
Tene Man, I need to stay off of IRC today before I embarass myself further.
spelling.
purl spelling is not one of Nicholas's strong points or trucky. or tricky :)
Coke Tene: too late!
pmichaud since it is, well, wrong. that pdd has caused me a lot of headaches.
Limbic_Region jhorwitz - sorry to have disturbed your slumber but nothing new to report yet ;-) 21:18
Coke so, does that fact that we're so slow concern anyone other than me? =-)
21:18 donaldh joined
jonathan pmichaud: I know you've spent more of your life on lexicals than you probably wanted to already, but I suspect the PDD has the best chance of being right if you (at some point, when you can face it) were to update it. 21:18
allison Coke: of course, but actually working comes before working fast 21:19
jhorwitz crawls back under his rock
pmichaud jonathan: yes, I'm already resigned to the fact that I'll have to be the one to rewrite it.
moritz Coke: oh come on, jonathan and chromatic did the MMD cache, and chromatic did a startup profile
pmichaud to be honest, fixing lexicals was a lot harder than writing PCT, and I got paid for that part. :-) 21:20
allison heads out to drive across town
Tene pmichaud: if you can update your lexicals.txt and mail me, I can do the PDD for you. 21:21
Limbic_Region pmichaud - speaking of which, how is your funding these days?
pmichaud Tene: that would be great
l_r: well, I have the ian hague grant for redesigning pge, but of course there's a lot more to do than just that :-)
Tene @ allalone.org 21:22
21:22 alvar joined
pmichaud more funding would always be helpful :-) 21:22
Limbic_Region well, I am looking at possibly doing something like jonathan's sponsorship - one day a week/month thing starting at the beginning of the new year 21:23
last we spoke, you were more interested in help with travel but I know that is dynamic 21:24
pmichaud one day a week/month a-la jonathan style would be excellent
Coke ls 21:25
ww
Limbic_Region ww not found
pmichaud okay, I need a break for a short while -- bbl
Limbic_Region will send you an email
Coke why do we have "parrot_is_shared" ? should we not default to that? 21:26
(er, as a config option)
(esp. given our 3 core platforms.)
chromatic I think it's because Mac OS X is weird. 21:28
Coke fair enough.
chromatic That's the only platform I recall where building a static libparrot ever worked or made sense.
Coke Someone should copy allison's final response to 36249 to the trac wiki and resolve the ticket. 21:31
Tene pmichaud: did you close the ticket about the gather workaround?
Ah. You did.
Email is friendly.
chromatic Hm, prelinking didn't seem to do much. 21:34
Coke chromatic: speaking of caching: rt.perl.org/rt3/Ticket/Display.html?id=45987 21:36
jonathan Do we even have a method cache these days?
dalek r33206 | moritz++ | trunk:
: [rakudo] follow a moved test in spectest.data
diff: www.parrotvm.org/svn/parrot/revision?rev=33206
chromatic I doubt it. 21:37
If we do use a cache, I'd rather use call-site PIC.
jonathan I didn't ever investigate that much (leo's implementation was too opaque for me to grok it from that and I never got around to reading the paper)
chromatic The paper's not too bad. 21:38
jonathan Got a URL handy or is Google the best bet?
21:38 alvar_ joined
chromatic I'd have to Google it to find it. 21:38
jonathan ok, I'll google myself
...that sounded dirty...
Found the info 21:40
dalek r33207 | moritz++ | trunk: 21:44
: [rakudo] track merge test files in spectest.data
diff: www.parrotvm.org/svn/parrot/revision?rev=33207
donaldh Are there any Cygwin users around? 21:46
Coke I have cygwin, haven't done much parrot with it rece4ntly. 21:48
donaldh Hmmm, I used to be able to debug parrot. Now I only get a hex stack, i.e. no symbols. 21:49
I have a parrot crash that I can reproduce so I'm trying to debug it. 21:50
Coke what configure options did you use?
donaldh Coke: the default. It's compiling with -g
Coke bah. can't help ATM: my cygwin svn is too old. 21:51
(oh, wait, i have like 4 copies of svn here.)
donaldh I used to get an erroneous -s link flag, inherited from perl5 that I had to manually remove, but there's no trace of that any more.
Coke yah. I'll check in with you when i get home; too many obstacles to doing a quick check at work. 21:52
donaldh np
Coke If you don't hear back, opening a ticket is also fine.
donaldh Yup. It looks like a Cygwin weirdness tho. Or do you mean for the SEGV? 21:53
Tene Both would be fine.
donaldh Coke: oh joy. debugging is there. it's just that the stack is corrupted. 22:07
chromatic Cygwin hates longjmp :)
22:08 johbar joined, ff-wonko joined
Coke maybe someone on another platform can duplicate the segv? 22:10
dalek r33208 | jonathan++ | trunk:
: [core] Implement remove_method vtable method in the Class PMC, plus the method variant.
diff: www.parrotvm.org/svn/parrot/revision?rev=33208
donaldh Will try myself on Linux when I get a chance.
Coke donaldh++
if it's a segfault, also try running the program with -G to see if it's a GC related segfault. 22:11
moritz if somebody needs a linux box to test, on you can either get a login on feather or on the machine where the #perl6 evalbot runs on
dalek r33209 | pmichaud++ | trunk:
: [rakudo]: Add quote with multiple bracket characters, and texas quotes.
: * Partially fixes RT #60670.
diff: www.parrotvm.org/svn/parrot/revision?rev=33209
Coke when did those turn into "texas" quotes? 22:12
thought they were french. =-)
pmichaud Ā« is french
<< is Texas
Texas quotes are working. French aren't.
jonathan stares at the two and tries to decide if the Texan ones are bigger ;-) 22:14
Coke stares at pmichaud's two sends.
donaldh Coke: it's a GC related segfault. -G runs fine. Does --gc-debug do anything useful. It doesn't seem to do anything for me.
moritz they are (two codepoints vs. one)
jonathan Ooh, multi methods nearly work...
Coke donaldh: --gc-debug, as i recall, works by not actually reclaiming anything, causing the GC pressure to increase. 22:15
chromatic has a nice article on tracking down parrot GC bugs.
www.oreillynet.com/onlamp/blog/2007..._in_p.html
donaldh Coke++
Coke chromatic++
also: www.oreillynet.com/onlamp/blog/2007...parro.html 22:16
note that --runcore=gcdebug is INSANELY slow. 22:17
(so if you're running a language instead of PIR, you might want to trim it down a bit first.)
chromatic: I'd love to see an article about how to fix memory leaks. =-)
chromatic Run Valgrind. 22:18
Read output.
Think really hard.
Check in fix.
Infinoid Profit.
Coke I have trouble on step 3 there.
chromatic Me too, because WE FIXED THE LEAKS.
donaldh bugger. SIGILL from --runcore=gcdebug
Coke yo yo, sig illin.
chromatic I thought it was --runcore=gc-debug
Coke I could be mistaken.
chromatic That one has anti-vomiting properties. 22:19
Coke (fixed the leaks) ah, but this is tcl, innit!
chromatic No, THIS IS SPARTA.
Coke (I mean, the leaks are in parrot, but still, tcl seems to break things that core doesn't notice.)
THIS IS CAKETOWN!
chromatic Wait. Tcl's madness.
Coke I'd kick you down in the large hole we have in the centre of our town if I didn't need you to fix my memory leaks.
(why the (&*#$ do they even have that hole? huh?)
chromatic They're baking the world's largest cake. 22:21
donaldh I'll happily share my testcase, but it involves PIR, NCI, sqlite3 and a sample DB.
22:22 gmansi joined
Coke chromatic: so my 'thinking hard' basically involved trying to match up the init sub the alloc was usually called from with a corresponding destroy sub. 22:24
I was unable to do this on the one or two I started out with, though.
also, I hate C. :|
-> 22:25
chromatic That's basically how it works.
22:41 tak joined 22:44 gmansi joined
jonathan wishes he wasn't so thick today 22:51
dalek r33210 | jkeenan++ | rm_miniparrot: 22:58
: Eliminate tests for Configure.pl --miniparrot option, which is no longer being offered.
diff: www.parrotvm.org/svn/parrot/revision?rev=33210
23:09 TiMBuS joined 23:21 alvar joined
dalek r33211 | jonathan++ | trunk: 23:30
: [rakudo] Some final bits to get multi methods working.
diff: www.parrotvm.org/svn/parrot/revision?rev=33211
23:33 bacek_ joined 23:34 tak joined 23:48 tak joined 23:49 ffwonko joined
dalek r33212 | jonathan++ | trunk: 23:57
: [rakudo] Add another spectest.
diff: www.parrotvm.org/svn/parrot/revision?rev=33212

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!