www.parrotcode.org/ | Last release: 0.7.1 "Manu Aloha"
Set by moderator on 17 September 2008.
00:10 AndyA joined 00:38 Zaba_ joined 00:49 gryphon joined 00:59 tetragon joined
dmknopp if some one wanted to get a unique id for every instance of a object in an HLL, whats the best approach? /pmc_freeze.pod suggests the vm already has a unique key per object referenced by the GC. " The seen hash holds keys being the address of the PMC and values being a PMC id, which is unique for this PMC. " Is there a hook to get this id? Is that even a good idea? maybe I could use the uuid.pir instead... 01:15
cotto use the address in memory? 01:17
dmknopp also, i thought i read some where about an op code for weak refs in the GC, but I dont know where I read it 01:18
how would I get the mem addr? I tried a assignment like this $I0 = self, but that just calls a get_integer :vtable
I guess to be specific, do you know how to get the mem addr in PIR 01:19
cotto oh. from PIR. 01:20
dmknopp yeah sorry, should have been more specific 01:21
maybe its not even a good idea to do it from PIR 01:22
cotto you might look at the get_addr opcode
dmknopp ohh cool, didnt see that one in the docs
cotto I found it just now by acking src/ops 01:23
for addr
dmknopp cool. I think that put me on the right track. thx. Also, I know to check src/ops for now on. 01:28
cotto it looks like most (probably all) get_pointer implementations do what you'd expect 01:30
01:31 Zaba joined 01:38 Whiteknight joined
dalek r31928 | Whiteknight++ | calling_conventions: 01:38
: [Calling_conventions] Started refactoring things. Made a big mess and it doesn't compile, but I'm moving in the right direction.
diff: www.parrotvm.org/svn/parrot/revision?rev=31928
Whiteknight I should have put more stress on the "big mess" part of that 01:40
like, a really really big mess
01:53 petdance joined
dalek r31929 | Whiteknight++ | calling_conventions: 01:54
: [Calling_conventions] Undid changes to Parrot_PCCINVOKE and it actually compiles. Need to work now on converting it over to use the new helper function.
diff: www.parrotvm.org/svn/parrot/revision?rev=31929
01:59 tetragon joined
dalek r31930 | Whiteknight++ | calling_conventions: 02:10
: [Calling_conventions] Fixed a segfault, migrated Parrot_PCCINVOKE to the new calling helper, but we're getting an argument number mismatch somewhere (not counting the object as being passed properly, for some reason). Will debug it tomorrow.
diff: www.parrotvm.org/svn/parrot/revision?rev=31930
02:49 tetragon joined 03:08 Coke left 03:15 dmknopp left 03:20 coke joined
coke moritz: did you just kill my process again? 03:20
cotto pr0c3ss k1LL0rz 03:25
coke sighs, it probably wasn't killed by anyone. 03:50
coke needs a faster tcl, damnit.
04:11 MariachiElf joined, petdance joined
confound tcl me quickly, tcl me sweet 04:34
cotto tcl? 04:36
purl tcl is www.tcl.tk/ or TCL7::TCL8 as perl4::perl5 or possibly partcl. or rt.perl.org/rt3/NoAuth/parrot/List....;Value=tcl or segfaulting parrot since 2001. or the canary in the mine shaft, as far as parrot is concerned. or www.tcl.fr/
petdance Do we have Parrot running under Klocwork?
dalek r31931 | chromatic++ | trunk: 04:40
: [tools] Allowed smoke script to run against installed Parrot in a different
: directory (Reini Urban, RT #58852).
diff: www.parrotvm.org/svn/parrot/revision?rev=31931
r31932 | chromatic++ | trunk:
: [src] Cleaned up some conversion and signedness warnings.
diff: www.parrotvm.org/svn/parrot/revision?rev=31932
04:42 MariachiElf1 joined 04:54 MariachiElf joined
dalek r31933 | chromatic++ | trunk: 05:02
: [PMC] Pushed a standard array copying idiom into libc in ResizablePMCArray's
: append() method. See RT #58460, from Stephen Weeks.
diff: www.parrotvm.org/svn/parrot/revision?rev=31933
r31934 | chromatic++ | trunk: 05:14
: [t] Added tests to verify that isa I0, P0, P1 and isa I0, P0, S0 give the same
: results (RT #56622, Patrick Michaud).
diff: www.parrotvm.org/svn/parrot/revision?rev=31934
05:40 Zaba_ joined
dalek r31935 | chromatic++ | trunk: 05:54
: [examples] Fixed ncurses_life.pir, reformatting it and tidying whitespace and
: indentation. This fixes half of RT #57120, reported by Reini Urban.
diff: www.parrotvm.org/svn/parrot/revision?rev=31935
r31936 | chromatic++ | trunk: 05:57
: [PMC] Fixed Env PMC, which mistakenly returned CONST_STRING-created strings to
: its caller. You can't do this, lest other code modify the constant string in
: place, and things go kablooie elsewhere. Arguably, CONST_STRING should avoid
: this problem, but for now, Env PMC now returns fresh empty strings for calling
: code to mangle as it sees fit. Weird segfaults in the string subsystem
: averted. See RT #57120, filed by Reini Urban, for one symptom.
diff: www.parrotvm.org/svn/parrot/revision?rev=31936
r31937 | chromatic++ | trunk: 06:13
: [PIRC] Improved Makefile to work on Linux. (We'll see if it works on Windows
: still; but the brains came straight out of the root Makefile.) See RT #59862,
: by Klaas-Jan Stol.
diff: www.parrotvm.org/svn/parrot/revision?rev=31937 06:14
r31938 | moritz++ | trunk: 06:17
: [cage] codingstd: remove cuddled else in smoke.pl
diff: www.parrotvm.org/svn/parrot/revision?rev=31938
06:17 Zaba joined 06:22 uniejo joined
dalek r31939 | fperrad++ | trunk: 06:51
: [PCT] hllmagic
: 2 fixes needed by Lua
: - method 'push_new' (deprecated & only used by Lua)
: - method 'clone' (initialty added for Lua)
diff: www.parrotvm.org/svn/parrot/revision?rev=31939
r31940 | fperrad++ | trunk: 06:56
: [Lua] hllmagic merge
: Ugly hack.
: Modify the TGE output only for POSTGrammar.
: TGE was not updated by hllmagic (generates old form "foo::bar" instead of new one ['foo';'bar']).
diff: www.parrotvm.org/svn/parrot/revision?rev=31940
r31941 | fperrad++ | trunk: 06:58
: [Lua] hllmagic merge
: - fix Lua compiler
diff: www.parrotvm.org/svn/parrot/revision?rev=31941
07:07 Zaba_ joined 07:45 cosimo joined 07:50 iblechbot joined 07:57 particle joined 08:29 tomyan joined 08:36 bacek joined 08:49 masak joined 08:54 kj joined
dalek r31942 | kjs++ | trunk: 08:55
: [pirc/heredoc] silence compile warnings.
diff: www.parrotvm.org/svn/parrot/revision?rev=31942
r31943 | kjs++ | trunk: 08:56
: [pirc/macro] consting and fixing warnings.
diff: www.parrotvm.org/svn/parrot/revision?rev=31943
r31944 | kjs++ | trunk: 08:58
: [pirc/new] const'd about everything and fix compile time warnings.
: * so apparently, by #define'ing YYFREE and YYMALLOC /before/ #include'ing the flex-generated lexer header in the parser, the 'inconsistent dll linkage' warning is removed. Yay!
diff: www.parrotvm.org/svn/parrot/revision?rev=31944
09:01 barney joined
dalek r31945 | fperrad++ | trunk: 09:39
: [Lua] hllmagic merge
: - fix r31940
diff: www.parrotvm.org/svn/parrot/revision?rev=31945
09:45 bacek joined 10:12 particle joined 10:15 Debolaz joined 10:19 GeJ joined
dalek bernhard.schmalhofer@gmx.de | Pipp: 10:27
link: www.perlfoundation.org/parrot/index.cgi?pipp
10:41 Zaba joined 10:44 bacek joined 10:51 omega joined
bacek hi 11:03
ENOPURL?
purl ENOTTODAY
bacek ;)
11:07 rdice joined
Zaba hehe 11:19
11:26 rdice_ joined 11:32 TiMBuS joined 12:13 Bzek joined 12:25 ruoso_ joined
ruoso_ hi... 12:26
considering multi's... I've seen that parrot treats Multi as a code object... 12:27
which basically means that it should receive postcircumfix:<( )> calls directly...
but the variants for multis can be lexically declared... 12:28
which means that a single multi object is not aware of all the variants at call time
I've been considering (multi)sub dispatch process to be defined outside each sub object 12:29
basically meaning that it goes looking for all the variants on the lexical scope, and then on the package
so... for Multi to handle postcircumfix:<( )>, it means one of the following: 12:32
1) it goes in the CALLER to find all the variants...
2) making that call explicitly on that Multi object means taking into account only the variants known by that object
of course there's the option of thinking on Multi as simply a container that holds the variants, and the sub dispatcher is the one that should figure out it's a multi and make the proper lookup in the variants 12:33
what do you think? 12:36
purl I think ruoso_ should try flossing more often!
12:46 Wknight8111 joined 12:52 iblechbot joined 12:55 Andy joined
ruoso_ later & 13:14
13:17 Lorn joined 13:22 grim_fandango joined 14:02 PacoLinux joined
dalek r31946 | pmichaud++ | trunk: 14:03
: [rakudo]: spectest-progress.csv update: 204 files, 4380 passing tests
diff: www.parrotvm.org/svn/parrot/revision?rev=31946
r31947 | pmichaud++ | trunk: 14:04
: [rakudo]: Don't use leading '::' for storing generic type lexicals.
: This gets us closer to supporting interpolated namespaces.
diff: www.parrotvm.org/svn/parrot/revision?rev=31947
14:06 gryphon joined 14:30 leo joined 14:31 cognominal joined 14:48 silug joined 14:59 particle joined
particle pmichaud: i can't create 'infix:=:=', it causes a segfault :( 15:00
moritz segfaults-- 15:03
particle indeed.
moritz rakudo: my $x = 3; say ++$x++
polyglotbot OUTPUT[4ā¤]
particle it was a frustrating plane ride trying and failing to track that one down
dalek r31948 | pmichaud++ | trunk: 15:10
: [rakudo]: Eliminate <generic_binder> and remove '::' as a <sigil>.
diff: www.parrotvm.org/svn/parrot/revision?rev=31948
pmichaud reading scrollback now 15:16
Infinoid good morning pmichaud 15:18
moritz kj: pirc/macro/macrolexer.c has comment that it's autogenerated from compilers/imcc/imcc.l. That seems vaguely wrong. (And it has a POD error) 15:19
kj moritz: ah ok. I copy pasted that piece I think
I'll fix it tonight (kinda busy now)
thanks for noticing
moritz ok
np
kj but it compiles rather cleanly don't you think :-) 15:20
moritz it compiles, but it doesn't link
kj did you update and run Perl Configure?
chromatic++ fixed the pirc.in file 15:21
and it worked on your box :-)
(i tried this morning)
moritz I think I did, but I'll do again, just to be on the safe side
particle do you need a full configure? 15:23
or is there a make Makefile?
if not, i'll add that, it's so handy
kj there is a make Makefile, but not sure if it's working
I messed up the pirc.in file a bit
maybe by now it's working...
particle crappity. dynoplibs are busted on win32 15:24
some report about invalid dlls
*sigh*
nopaste "moritz" at 89.13.219.42 pasted "pirc link failure" (37 lines) at nopaste.snit.ch/14288
moritz (on a different box, but same system) 15:25
kj ah right
yes, that's only the heredoc preprocessor
eh, my bad. I added a #define that acts as a swtich to link to libparrot or not
and it's enabled now...
so either disabling it or by fixing the pirc.in file to link libparrot will make it work 15:26
I'll do that as well tonight ;-)
moritz allright
kj but running the macro processor and pir parser will work
afk. bbiaw 15:27
moritz who runs rakudo.org? its CSS is busted. 15:28
15:28 jq joined
moritz it has an @import that's a 404 15:28
rakudo.org/mt-static/themes/unity-t...screen.css # this one
pmichaud andy lester runs that one 15:29
(aka petdance)
moritz summon petdance 15:30
no summon bot here ;)
pmichaud alester: ping petdance: ping Andy: ping 15:31
purl I can't find petdance: in the DNS.
15:31 Zaba_ joined 15:40 silug joined 15:45 johbar joined 16:04 hercynium joined 16:06 cjfields joined
Wknight8111 we need a word to get somebody's attention besides "ping", because that confuses purl 16:08
like "alester: Holla-back-gurl" 16:09
or, something even less inappropriate then that
moritz we shouldn't let purl dominate our communication habits.
I'd rather kick her than adapt
Wknight8111 we shouldn't, but I do anyway
moritz ... myself 16:10
particle ping myself
purl I can't find myself in the DNS.
Wknight8111 particle: Holla back
16:10 jan joined
Wknight8111 or, particle: Where you at? 16:11
all I know about interpersonal communications, I learned from rap songs and cell phone ads
pmichaud we need purl to be smart enough to know that if we say 'ping' but follow that with a non-dotted name, it's probably not a DNS request.
Wknight8111 whoa! you act like purl is some virtual agent that can be repurposed easily, as if by entering a new sequence of commands 16:12
16:12 peepsalot joined
Wknight8111 actually, that's probably better 16:13
Infinoid Wknight8111: word
pmichaud I agree with the principle that purl should adapt to our needs and not vice-versa.
I also recognize that "fixing purl" may in fact be very unlikely.
Infinoid pings Masque about it. 16:16
16:20 jhorwitz joined 16:24 Theory joined
dalek r31949 | Whiteknight++ | trunk: 16:31
: [Book] Add small blurb about the purpose of PCT
diff: www.parrotvm.org/svn/parrot/revision?rev=31949
Wknight8111 Anybody around here know about sub signatures? 16:32
moritz a bit
I removed the wort cruft from $Book 16:33
but not sure about the some of the rest
Wknight8111 If we're calling a method, do we include the invocant somehow in the signature?
moritz optinally
*optionally
Wknight8111 how? like "P..." for the invocant?
moritz method foo ($invocant: $args, *@rest)
if there's no invocant, you can still access it as `self' 16:34
Wknight8111 Oh no, I'm talking about at the Parrot level, not the perl 6 level
moritz sorry ;)
Wknight8111 it's okay
cjfields I think self works if the sub is a method 16:35
in PIR
s/works/only works/ 16:36
moritz if it's not a method you don't have an invocant ;)
cjfields right
Wknight8111 for intance, if I call $P0.my_method(), is the signature "P->" or is it "->"? 16:37
16:37 DietCoke joined
DietCoke ps? 16:37
purl i guess ps is postscript or process status or see "parrotsketch"
DietCoke parrotsketch?
purl i think parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
Wknight8111 Yeah Coke, you're about 2 hours early
16:38 Andy joined
DietCoke just double checking the teim. 16:38
seen tene?
purl tene was last seen on #parrot 23 hours, 6 minutes and 58 seconds ago, saying: Oh, attachment
Infinoid Andy!
particle error:imcc:Sub isn't a PMC
...lovely.
Andy \\Yes?
Infinoid [08:28] <@moritz> who runs rakudo.org? its CSS is busted. 16:39
Andy May I help you?
oh, busted how?
moritz no, me ;)
Andy: one of the @import URLs is a 404
17:28 <@moritz> rakudo.org/mt-static/themes/unity-t...screen.css # this one
DietCoke seen chromatic? 16:40
purl chromatic was last seen on #parrot 4 days, 10 hours, 6 minutes and 0 seconds ago, saying: It made sense at the time. [Oct 10 06:34:13 2008]
DietCoke where are the latest parrotsketch logs? 16:41
www.parrotcode.org/misc/parrotsketch-logs/ stops in 200809
Infinoid irclog.perlgeek.de/parrotsketch/today
moritz or just irclog.perlgeek.de/parrotsketch/ (that's a calendar)
DietCoke are the official logs no longer kept?
particle kj: ping
DietCoke have those replaced them? 16:42
Andy wow, that's awful moritz
DietCoke Or is that just a supplement that we're lucky to have?
particle DietCoke: i think the bot was missing for a bit
moritz doesn't even know how runs the offical logs
particle tweety logs #parrotsketch for perl.org
moritz s/how/who/
particle robrt is tweety's slave 16:43
Wknight8111 indentured servant
moritz not the other way round?
particle who wants to hack imcc.y?
Wknight8111 what do you need hacked?
Actually, I can't do it till I get home, no compiler on this system 16:44
DietCoke I sent an email to webmaster@perl.org asking after tweety's logs
16:44 Zaba joined
nopaste "particle" at 98.232.28.49 pasted "this rakudo code busts imcc" (17 lines) at nopaste.snit.ch/14289 16:45
Tene DietCoke: pong
particle applying that patch, relative to languages/perl6/ makes imcc throw an exception 16:46
Andy moritz: Fixed.
Tene DietCoke: my girl was using my laptop all last night, so I wasn't able to get it from her to work on your bug
Andy Thansk for the heads-up.
particle the line it hits is compilers/imcc/imcc.y:1655
Andy So has anyone talked to Klocwork about them running our stuff?
moritz Andy++
Andy Like Coverity?
particle has never heard of klocwork
Andy they're like Coverity
and they do open source stuff too
There used to be opensource.klocwork.com 16:48
but it is no more
Wknight8111 particle, I'll take a look at this tonight when I get home, if nobody does it first 16:50
DietCoke the one sample they show here (www.klocwork.com/products/insightDefects.asp) should be caught by how we're declaring our functions, neh?
s/one/first/
particle aargh! Wknight8111, nevermind 16:54
Wknight8111 ???
particle .return $I0 should be .return ($I0)
then it works.
Wknight8111 okay, but I'm telling people that I fixed it 16:55
Infinoid "To have your open source project analyzed, contact opensource@klocwork.com." 16:57
-- www.klocwork.com/company/releases/06_26_06.asp
I can do that, if noone else wants to
particle sure, go ahead. Infinoid++ 17:00
17:11 ruoso joined
Infinoid (email sent) 17:11
ruoso is this channel still logged? 17:12
yes it is
hercynium so... I can't just shout out random profanities anymore? 17:13
17:13 ZuLuuuuuu joined
PacoLinux irclog.perlgeek.de/parrot/2008-10-14#i_620927 17:14
moritz hercynium: sure you can. There's so much data noise in here that nobody will evver fiind it. Except your future empolyer of couse, by pure chance ;)
hercynium :) 17:15
They can just look thru the comments in my code for more damning evidence 17:17
Coke I see parrot's lolcode mention in wikipedia is gone. "(Removed a statement supported only by blog posts) (undo)"
Coke is bemused by the thought that blog posts don't count. 17:18
moritz uhm, isn't lolcode mentioned in languages/LANGUAGES_STATUS.pod?
kj particle: pong 17:19
particle hey there kj
kj hi
particle imcc throws a funny error when you leave out the parens in .return
kj what .return? :-) There's different contexts for .return 17:20
particle .return $I0 gives "error:imcc:Sub isn't a PMC"
.sub 'foo'
kj .begin_return, .return()
particle .return $I0
.end
kj yeah probably because it wants to do a tailcall?
particle ah, yeah, probably
Coke en.wikipedia.org/w/index.php?title=...on=history :: edit from oct 1, 00:41
kj but yeah, not helpful
NotFound Coke: write 'LOLCODE in a nutshell' or something for O'Reilly, to have a published source to quote it in the article.
kj particle: with any luck, I'll make some progress the coming months on Packfile writing 17:21
particle yes, it's a syntax error because i'm not .return-ing a PREG
kj so we dont' need to fix IMCC :-)
particle imcc should only attempt tailcalls when .return-ing PREG
Coke NotFound: if only I cared that much.
particle otherwise emit error about missing parens
Coke I am merely sad that my only reference on wikipedia was edited out.
NotFound 'LOLCODE for dummies' will be redundant, it isn't?
particle "I CAN HAZ LOLCODE?" 17:22
Coke It would probably inappropriate for me to add myself back in, so I mention it here as a curiosity. 17:24
en.wikipedia.org/wiki/Wikipedia:List_of_policies doesn't seem to prohibit blogs as a source. =-)
particle it can be backed up by a readme file in an svn repo, can't it? 17:25
NotFound Coke: en.wikipedia.org/wiki/Myself
17:25 ZuLuuuuuu left 17:26 apeiron joined
Coke I presume that's just a riff on "adding myself"? 17:27
or are you correcting my grammar?
NotFound Coke: I'm even unable to correct my own. 17:28
dalek r31950 | julianalbo++ | trunk: 17:34
: some tests for the 'open' opcode, RT#59544
diff: www.parrotvm.org/svn/parrot/revision?rev=31950
Wknight8111 Coke: Trust me, WP forbids using blogs as sources 17:39
I've fought that battle on more then one occasion
I wish I had brought my personal laptop to work today, I could be compiling parrot as we speak. But, no 17:43
pmichaud how about presentations ... do those count as sources? 17:47
17:55 chromatic joined
kj chromatic++ # thanks for fixing pirc.in! 17:56
chromatic You're welcome. Does Windows still build? 17:57
kj I just tried, doesn't seem so
my system can't find libparrot.lib 17:58
cannot open file 'libparrot.lib' is the message
chromatic I didn't copy over any of the conditioned lines in root.in. 17:59
kj copying libparrot.lib to compilers/pirc didn't help matters; then I get all sorts of link errors
18:10 grim_fandango joined 18:12 barney joined 18:14 Ivatar joined
Coke chromatic: thought you'd like this: when I run "../../parrot tcl.pbc t_tcl/expr.test", and it eventually hangs, consuming memory, if I run that through gdb first, and hit ^C, I get a backtrace several hundred (thousand?) lines long, looks like it's infinitely throwing an exception. 18:17
(So far efforts to reduce the amount of code necessary to generate the hang have come to naught. Think I'm going to see if mac's "sample" tells us anything interesting. 18:18
chromatic Rakudo has something similar. 18:19
I'm surprised you don't run out of stack space before it consumes all memory.
18:19 rdice_ joined
Coke maybe the garbage collector is really good. 18:19
Wknight8111 if it's throwing exceptions repeatedly, it wouldn't consume much stack space, would it?
Coke </straight man> 18:20
would on the c-stack, no?
chromatic A backtrace in gdb that's thousands of lines long eats up stack space.
Coke chromatic: honestly, I never let it fail. After 30m of chewing CPU and memory, I typically give up and kill it. 18:21
chromatic 30m is a lot of CPU and memory.
Coke yes.
chromatic You have to multiply by one a lot of times to figure out how much memory it is.
Coke ^_- 18:22
18:22 Wknight8111_ joined
chromatic Something in the exception "Hey, I can't handle this! Rethrow!" code is either A) difficult to use interface wise or B) completely rotten. 18:23
I think we need to put a lot more "Here's what I can handle!" data in our exception handlers.
Tene chromatic: do you have pir to reproduce?
Tene starts reading scrollback 18:24
Coke even before the hang, I'm getting a huge sample file: (nopaste shortly)
Tene If you can find the exception handler it's looping in, we can add filters. 18:26
chromatic I don't like an interface where it's possible to create infinite loops in PIR by writing simple code that's not obviously an infinite loop. 18:27
#ps in 2 18:28
Tene Oh, #ps! 18:29
chromatic: what do you think about requiring exception handlers to declare the type of exception they handle? 18:30
18:30 peepsalot joined
chromatic Tene, I like that a lot better. 18:30
Coke I wouldn't mind that if we had a well thoughtout set of types. 18:31
chromatic There's the slutty cheerleader, the math nerd, the sensitive social outcast, the jock.... 18:32
Wait, did you say "types" or "tropes"?
pmichaud ...requiring? Or allowing?
chromatic We already allow them, but my inclination is to require them -- unless we can find a way to avoid that easy-to-fall-into redispatching bug. 18:33
Wknight8111 Dietcoke changed his name back to Coke so he could report ahead of cotto 18:34
pmichaud as long as there's a way to have exception handlers that can handle multiple exception types, I think I'm okay with that.
(and I'd like an easy way to say "catch everything")
Tene chromatic: Can you find an EH that currently loops? 18:35
chromatic Right. We have to balance ease of use with the idea that you shouldn't be able to crash Parrot by writing normal-looking PIR.
Coke ... ANY kind of pir, TYVM. =-) 18:36
but especially that kind, yes.
Tene EHs shouldn't be looping unless you're throwing an exception type that you've asked the exception handler to handle.
18:36 silug joined
Coke ... yes, but since you can't specify that now, how is the looping even happening? 18:36
Tene It should still have the old behavior otherwise
chromatic They shouldn't, but look at the Rakudo backtrace I posted last week.
Tene Coke: you can specify that now.
pmichaud I don't think that's a "loop"
I think that may be four separate exception handlers. 18:37
(Haven't looked closely yet.)
Coke tene: really? how?
purl i heard really? how was that possible?
chromatic jhorwitz, did I fix the name segfault problem you had in RT #59732?
Tene Coke: look at the end of t/pmc/exceptionhandler.t
jhorwitz checking RT..
Wknight8111 purl forget really? how? 18:38
purl Wknight8111: I forgot really? how
Tene eh.min_severity/max_severity/handle_types
jhorwitz chromatic: yes, that was was fixed.
Coke Tene: I feel dirty, but ok.
Tene Coke: huh?
pmichaud PGE and Perl6Grammar have traditionally used exception handlers to handle the case of calling new_class multiple times... because for a while there wasn't a way to check if a class already existed.
chromatic Tene, RT #59778. 18:39
pmichaud (well, before the exception handler approach they used find_type to do it, but find_type was removed.)
Coke tene: it's very different from the push/pop code I'm used to seeing for exception handlers.
Tene Coke: if you want to define a macro for it, feel free
Coke I'm wondering how the simple push/pop stuff would recurse. 18:40
Tene Coke: it shouldn't, but it's sketchy.
pmichaud ...are we sure it's a recursion?
Coke I'm not, no. 18:41
chromatic For RT #59778 it certainly looks recursive.
At least at the C level it is.
pmichaud I think it might simply be four separate attempts to create the same class
(or four attempts to create an existing class)
again, I haven't looked all that closely, but that's my initial guess. 18:42
chromatic That may be, but I think I've seen it many more times than just four. 18:43
pmichaud I suspect that if I recode Perl6Grammar to not use push_eh/pop_eh when creating its classes that the problem will disappear. 18:46
dalek r31951 | kjs++ | trunk:
: [pirc/macro] fix pod error and fix a comment mentioning imcc.
diff: www.parrotvm.org/svn/parrot/revision?rev=31951
r31952 | kjs++ | trunk:
: [pirc/new] fix comment 18:47
diff: www.parrotvm.org/svn/parrot/revision?rev=31952
18:48 Wknight8111_ joined
Wknight8111_ did my report to #ps go through? 18:48
chromatic Looked like a two liner.
pmichaud anyway, I'll try removing the exception handlers surrounding the various calls to newclass and we'll see what we get.
Wknight8111_ yeah, that was it
my client is goofy today 18:49
pmichaud or, more likely, I'll just switch the code to let me see when those handlers are being invoked.
dalek r31953 | kjs++ | trunk:
: [pirc/heredoc] fix comments pointing to imcc.l
diff: www.parrotvm.org/svn/parrot/revision?rev=31953
cjfields chromatic, did you post allison's report?
Coke yes. 18:50
cjfields ok
Coke purl, cjfields?
purl wish i knew, coke
18:51 Zaba joined
cjfields purl, cjfields? 18:53
purl you are, like, Chris Fields, a core developer for the BioPerl project
Coke was just curious since you weren't on the email containing the report. =-)
nopaste "particle" at 98.232.28.49 pasted "[p6] export.t diff for particle" (75 lines) at nopaste.snit.ch/14291 18:54
Wknight8111 what is BioPerl?
purl i think BioPerl is the perl used by the human genome project to scan sequence data.
Wknight8111 o, woot
cjfields yep
barney cjfields++ for contributing to BioPerl 18:55
cjfields thx
cjfields working towards an (eventual) bioperl6 18:56
barney It helped me a lot when I worked at Biomax
cjfields Great to hear that!
I may be giving Rakudo a bit of a work out with genome and microarray data once grammars are a bit further along 18:58
particle what's missing in grammars?
cjfields Coke: I was backlogging #parrotsketch on irclog.perlgeek.de/parrotsketch/today, just didn't see the report 18:59
particle: how we tie rule matches into (perl6) closures. I don't think it's implemented yet.
pmichaud cjfields: do you mean embedding closures inside of matches? Or something different? 19:00
chromatic Why does IMCC parse this class name as a Slice? 19:01
$P0 = get_class ['TGE'; 'Parser']
particle almost implemented Q:PIR last night
cjfields pmichaud: well, I would like something which passes along match information to a Closure or method 19:02
particle imcc is as imcc does
chromatic Oh goodie, I get to change a *parser* again.
Let me go put on my party hat. 19:03
Wknight8111 I like parsers, I wish I were better at them
pmichaud afk for a bit.
cjfields (I could do something like this w/ Q:PIR for the time being)
chromatic klass = newclass [ 'Not'; 'A'; 'Slice' ] 19:04
1 newclass P0, PC21 P0=PMCNULL PC21=Key=PMC(0x80ee9a8)
klass = get_class [ 'Not'; 'A'; 'Slice' ] 19:05
0 get_class P0, PC7 P0=PMCNULL PC7=Key=PMC(0x80eea6c)
Okay. My mind is now officially boggled.
cotto it's like a Zen koan 19:07
kj (parsing as a slice) It's probably because it's the first or second operand is a keylist 19:09
I had some trouble figuring that out recently; problem is that a keylist can be just any operand 19:10
chromatic That's exactly what it is.
kj but PIR also allows special sugar for keyed access
so there you go. shift/reduce errors if you don't figure out your grammer properly
chromatic I added maybe_ns for the NEW state a while back, but get_class can accept a namespace and not a slice there too. 19:11
Maybe we should add some token for class-based assignment to the assignment rule and require that they have maybe_ns instead of '[' keylist ']'
kj parsing gets tricky if there's a (possibly dynamic, user-defined) op that takes 2 operands, like this: $P0 = foo ['hi there'] 19:12
19:12 cotto joined
kj what happens if 'foo' is an op? 19:12
that's a rhetorical question :-) 19:13
chromatic I'm willing to go only so far in beating IMCC in any given day.
kj i gave up already...
chromatic I just don't want to let its worst bugs stand in the way of people getting serious work done. 19:14
particle write your own parser to replace it. that seems to be the way around here.
kj so what happens if you don't use the PIR sugar?
just get_class, then the ops
particle: seemed like the way I would have most fun :-) 19:15
particle :)
chromatic I'm not sure IMCC would do any better that way, either.
kj I have a tiny bit of hope it would work better 19:16
chromatic I'm not aware of anything in the IMCC grammar which disambiguates between a slice and a classname-as-key. 19:17
At least, besides what I added for NEW.
kj weren't slices deprecated anyway? 19:19
19:22 davidfetter joined, gryphon joined
Coke wwould any other hlls find it useful to be able to define a sub's usage error message? 19:22
dalek r31954 | particle++ | trunk: 19:23
: [rakudo] add 'infix:=:=' and 'infix:!=:=' ops
diff: www.parrotvm.org/svn/parrot/revision?rev=31954
Coke (tcl is currently forced to have a blanket signature and then do its own arg checking so it can throw an exception with teh right usage)
pmichaud Rakudo is likely to end up with its own dispatcher.
kj particle: I looked briefly in the weird error message with the tailcall 19:24
particle pmichaud: ping
kj can't really fix it easily..
pmichaud particle: pong
particle kj: that stinks
but, that's imcc :)
Coke pmichaud: that doesn't seem to bode well for interop, does it/
?
pmichaud Coke: if Parrot's dispatcher isn't going to support Perl 6 semantics, what choice do we have?
particle pmichaud: can you svn up and look at src/parser/actions.pm:866 19:25
dalek r31955 | particle++ | trunk:
: [rakudo] refactor 'is export()' trait code to prepare for handling taglists
diff: www.parrotvm.org/svn/parrot/revision?rev=31955
Coke yay, balkanization.
kj particle: of course, the error message itself can be easily changed, possibly into something more descriptive; but there would be no difference in .return $I0() and $I0() in a non-return context.
particle having trouble getting at the contents of (...) in is export
kj: you can't invoke anything but PREG 19:26
pmichaud Coke: Don't get me wrong, I'd love to be able to use the built-in dispatch. But my feeling is that Parrot isn't likely to get there.
particle ...so no difference between .return foo and foo is fine with me 19:27
actually, hrmm
kj: there is a difference
kj particle: exactly, and so if you write $I0() you'll get the error message Sub isn't a PMC
particle .return <something not inside parens> # invokes something
<something not inside parens, no trailing parens> # doesn't invoke 19:28
kj particle: .return tailcalls will be marked by .tailcall , as in .tailcall foo(), in the future. Allison suggested that.
19:28 bacek joined
Coke pmichaud: ah well; if there's no point pushing for this in core, I'll just roll my own. ah well. 19:29
pmichaud Coke: I'm not saying it's pointless for core... just that I'm not sure Rakudo will be able to take advantage of it
I don't know if it would be useful for other Parrot languages 19:30
I could potentially see NQP using it, and possibly Pynie
particle: the things inside of an <EXPR> are almost never identifiers. 19:32
look at a parse tree and see what's really there.
in this case they're likely be to be a list of pairs 19:33
however, as S11 is written that seems a little weird -- I'm not sure that colonpairs parse quite like that in an expression.
although STD.pm seems to parse them okay. 19:35
Coke pmichaud: fair enough; but to my way of thinking, if I can't interoperate with rakudo, there's not much point.
pmichaud well, there's nothing that says that rakudo's dispatcher can't use the same attribute that parrot's dispatcher is using 19:36
or something similar
19:36 sjansen joined
particle pmichaud: the <identifier> thing is tacked on there, but anything i try to assign to $list causes an error 19:37
pmichaud particle: compile or runtime?
particle trying now
pmichaud there's also the issue that you can't necessarily expect the <postcircumfix> node to contain a <semilist>. 19:39
particle yeah, i kept questioning how to interrogate the postcircumfix for named args 19:40
s/named args/taglists/
i don't really know what i should do there 19:41
pmichaud I'm not sure either... I need to see how that actually parses
particle i'll paste it as soon as rakudo rebuilds
pmichaud currently Rakudo doesn't parse is export(:DEFAULT :others) 19:42
it does parse is export(:DEFAULT, :others)
moritz shouldn't that be :DEFAULT, :others)
pmichaud S11 shows it without the comma.
yes, life is easier (I think) if we require the comma.
but I suspect $Larry has reasons for the current syntax. 19:43
dalek r31956 | kjs++ | trunk:
: [imcc] this fixes the 'inconsistent dll linkage' warning on windows systems. Compiles both on windows and linux.
diff: www.parrotvm.org/svn/parrot/revision?rev=31956
moritz STD.pm says it's a noun with two colonpairs
which doesn't look like a mis-parse 19:44
pmichaud ah, that's new.
we can update Rakudo to have that.
moritz bug perhaps ask TimToady first
pmichaud ("new" == "relatively new" == "changed since the last time I looked at noun parsing)
particle ah, i assumed commas were needed 19:45
moritz I'm not looking at the parsing, just at the parse tree ;)
pmichaud token noun has
| [ <colonpair> <.ws> ]+
moritz ah
pmichaud last time I looked at this it was just | <colonpair>
moritz there are two occurences of such things in the test suite 19:46
(from a casual ack)
S11-modules/OuterModule.pm and packages/S11-modules/Foo.pm
particle ...both edited by me recently... 19:47
pmichaud that gets kinda weird, because it means that 3 + :a :b is a valid parse I think
and :b isn't an adverb.
particle oh well 19:49
cjfields pmichaud: that is similar to the issue I was having with regex modifiers 19:50
particle at least the code is ready for taglists, when it's decided how they'll be specified
pmichaud++
pmichaud particle: I'd focus on getting it to work for is export(:DEFAULT, :other) for now
I *know* that will be valid.
(at least, based on current S11 and STD.pm)
particle ok, that is what i was trying to do
cjfields as in, $foo.match(:g, /\\d+/) vs $foo.match(:g /\\d+/)
pmichaud you'll want to look at the value of $($aux<postcircumfix>) 19:51
you can run through its children looking for nodes with a 'named' attribute.
(once again, trying to grab things out of the syntax tree itself is not the right way to do it :-)
moritz d'uh, I was trying to find tests that the =:= made pass, and couldn't find any... then I noticed that I should 'svn up' first ;) 19:52
particle pmichaud: yeah, that was debugging, i was trying to understand the tree, $() is the way to go. thanks 19:54
pmichaud postcircumfix:<( )> will generate a PAST::Op node of type 'call', with the arguments as its children
named arguments will have a 'named' attribute 19:55
particle while debugging nqp, can i print the past immediately? 19:59
like: my $list_past := $( $aux<postcircumfix> ); say($list_past);
particle rebuilds and tries
dalek r31957 | kjs++ | trunk: 20:01
: [pirc/new] fix c++ warnings.
diff: www.parrotvm.org/svn/parrot/revision?rev=31957
20:02 lasermike026 joined
pmichaud ...you want to "say" a PAST::Op node? 20:04
you might be able to dump it
particle yes, and it works
pmichaud _dumper($list_past)
afk for a short while 20:05
dalek r31958 | kjs++ | trunk: 20:07
: [pirc/heredoc] disable linking to libparrot.
diff: www.parrotvm.org/svn/parrot/revision?rev=31958
20:15 particle1 joined 20:20 Theory joined 20:25 johbar joined
nopaste "chromatic" at 69.64.234.10 pasted "Buggy IMCC Patch to Enforce Key Context for Classy Ops" (80 lines) at nopaste.snit.ch/14292 20:27
chromatic kjs, that nopaste might be interesting to you.
20:27 bacek joined
kj does it work? 20:28
purl does it work is it used? =-)
chromatic Not entirely. 20:29
error:imcc:syntax error, unexpected '\\n', expecting COMMA
in file 'runtime/parrot/library/Data/Dumper/Base.pir' line 29
error:imcc:syntax error, unexpected '\\n', expecting '['
in file 'runtime/parrot/library/Data/Dumper/Base.pir' line 34
error:imcc:syntax error, unexpected '\\n', expecting COMMA
kj I guess for a short-term solution, it looks fine. However, long-term, especially with dyn.loadable ops, having special rules is not a good idea. But I guess you would agree on that.
chromatic There's a comment in iNEW in parser_utils.c which suggests tagging ops which expect a classname as a parameter. 20:30
20:30 particle joined
chromatic Somehow I added way too many s/r conflicts, and we're triggering the wrong rules in the wrong situations. 20:30
I need to get back to paying work, but I thought you might have some insight. 20:31
kj ddb_class = get_class "Data::Dumper::Base"
this might be a problem; this is the line that is an error
needs to be converted to [] style I think
chromatic In theory the string form should still work; I don't believe we've deprecated it. 20:37
kj it's deprecated, but that's what triggers the error 20:38
I think
*deprecated but not yet removed
but as slices are deprecated too, that should be removed, and then the problem might be solved. Not sure, though. 20:39
chromatic I can't figure out which rule I added trips the problem.
Did we deprecate slices altogether?
kj well, depends on your definition :-)
nested keys is still ok i think as in ['x';'y']
chromatic If we did and can remove them, I can solve the problem in IMCC by removing all of the slice code, which doesn't hurt my feelings.
kj so in my understanding, a slice is a fancy notation for a subset of an array 20:42
like [1 .. 2] or [1, 10] 20:43
or whatever.
and that includes I think [1;10], I see the rule keylist_force
eh, *keylist, where imcc->in_slice = 0; in keylist, however, in_slice = 1. 20:44
aaaah. I don't understand that code. I think keylist_force is the rule for keylists that are an operand to an op, whereas keylist is the key on a register. 20:46
chromatic That sounds right to me. 20:57
kj gotta go, otherwise no bus back home. Good night 21:02
21:06 particle1 joined 21:13 particle joined 21:37 TiMBuS joined 22:03 Whiteknight joined
Whiteknight chromatic, you still here? 22:03
Coke seen tene? 22:05
purl tene was last seen on #parrot 3 hours, 25 minutes and 35 seconds ago, saying: Coke: it shouldn't, but it's sketchy.
Tene seen Coke? 22:06
purl Coke was last seen on #parrot 6 seconds ago, saying: seen tene?
Coke tene: any chance you've been able to look at Tcl/Glob?
Tene gimme link to rt or nopaste or whatever
I have time right now
Coke rt.perl.org/rt3/Ticket/Display.html?id=59870 22:08
it relies on some guts that I think got updated on the faux namespace to real namespace cleanup.
if I can get even an updated version of the test file working, I can then update partcl to do it the new way and then hopefully be able to use the release next week as a stable-ish release for partcl to rely on. 22:09
Tene works on it now 22:10
Coke tene++ # in anticipation 22:11
Tene So that file, on its own, you claim should work in parrot trunk?
Coke ... no
Tene Oh. 22:12
Coke Attached is a test file that works in r31835, but fails in r31925.
Tene Ah.
I see it now
I was trying to ask "Parrot should be updated so that that file works with parrot trunk" 22:15
Coke that file or something like it. =-)
If the 'compreg' line changes in the test, for example, that'd be fine.
Tene But not if I replaced it with: print "ok 1\\nok 2\\nok 3\\n" 22:16
;)
Coke *thwap*
Tene Ack!
Coke don't make me give you a partcl commit bit. :P
chromatic Whiteknight, pong. 22:17
Coke (which, btw, you're welcome to if you want one.)
Coke pounces on chromatic.
"make parrot faster!!!!! *whinge*"
chromatic Give me a shortish (< 100 lines) (hey that's valid Pheme code) example of slowness and I'll do what I can. 22:18
Tene Coke: Wait, lemme check my karma before I commit this fix
purl: karma tene
purl tene has karma of 286
Tene 286 is a good number
Whiteknight sorry for the delay!
Tene 2*11*13 22:19
purl 286
Tene Nice factors
Whiteknight chromatic, in a function signature, is the invocant explicitly listed as one of the parameters or not?
Tene 2*2*2*5*7
purl 280
chromatic It gets stored in a special slot in the interpreter. 22:20
Tene 7*41
purl 287
chromatic I'm not sure if that's what you're asking though.
Tene Yeah, okay, 287 is better.
Whiteknight like the function P.meth(S, N, I) have the signature "PSNI" or "SNI"?
chromatic In an NCI context, an MMD context, or something else?
Whiteknight yeah, it gets stored in interp->current_obj, and is also gets passed as the first argument
contexts? damn I dont know about contexts 22:21
chromatic I don't think it's the first argument; there's a special P reg for it in the calling conventions. P5 or something. At least, that's how it worked the last time I read the calling conventions PDD.
Not context as in "What's the guts of a Continuation" but as in "Which working set of jargon do I need to swap in for this conversation?"
dalek r31959 | tene++ | trunk:
: [library]: Fix namespace issues reported by Coke++
diff: www.parrotvm.org/svn/parrot/revision?rev=31959
Coke tene; can you add the test file? =-) 22:23
tene++
Tene Coke: can you tell me where in t/ it should go? 22:24
Whiteknight The invocant of a method definitely gets passed as the first parameter, I'm certain of that because that's the exact mechanism that I broke 22:25
Coke t/library/tcl_glob.t, probably
Whiteknight What I don't know is if the signature string reflects it's existence or not
I guess I'm talking about regular MMD signatures
or whatever signature type is taken by Parrot_PCCINVOKE
chromatic I don't believe you need to put a P in there for the invocant. 22:26
I'm 85% certain. 22:27
Whiteknight no, I just did an ack and it doesn't look like it's required. All I need to do then is push in the invocant into the CallSignature PMC, and not affect the signature string
that's good for me
chromatic That sounds right to me too.
dalek r31960 | tene++ | trunk: 22:29
: [library]: Add a test for Tcl::Glob
diff: www.parrotvm.org/svn/parrot/revision?rev=31960
Tene Someone using svn should update MANIFEST and metadata for that file.
chromatic Just a moment. 22:30
Tene Coke: Thank you for following through and harassing me to update that. I really appreciate that.
Coke orly?
purl YA RLY.
Tene Coke: YARLY. Harassing people about bugs isn't fun, but it's an important task.
Infinoid karma Tene 22:32
purl tene has karma of 289
Infinoid 17*17 22:33
purl 289
cotto it'd be more efficient to make purl do that
(although less nerdy, so it probably won't happen) 22:34
chromatic purl factor 289
purl chromatic: i'm not following you...
Infinoid we need a more hackable purl.
chromatic Tene, as long as you're fixing class namespaces, did you take a look at TGE?
Tene chromatic: I know very little about TGE, and I've never used it. Can you point me to examples of breaks? 22:35
Oh, 'make test' in compilers/tge 22:36
chromatic When it turns .tg files into PIR (like PGE turns .pg files into PIR), it uses the old style of class namespaces.
Tene Okay, so its code-generation needs to be updated.
Infinoid (3*3+2*2*2)**2 22:37
purl 289
Infinoid cotto: is that nerdy enough?
cotto it passed "enough" a long time ago 22:39
although I'm just saying that because I'm not good at it
Tene Neither am I. I try to care about karma factorization to get practice. 22:40
Infinoid chromatic: quick question... are CPointer PMCs supposed to point at a PObj? because that's what CPointer.mark() seems to be assuming
guess the factored question is... is everything a PObj? 22:41
chromatic If it's an 'S' or a 'P' CPointer, yes.
Infinoid apparently it is a 'P' CPointer; the crash happens when it calls pobject_lives() on the PMC pointer 22:42
chromatic You might have to set a watchpoint on that value to see when it changes. 22:43
Tene ... oh, 'make test' was only failing because I needed a realclean.
chromatic At least, on the assumption that it's valid sometime.
Infinoid the pointer value doesn't seem to change
perhaps the PMC's contents have been overwritten
22:44 ruoso joined
dalek r31961 | coke++ | trunk: 22:44
: [distro] minor cleanup on new file
diff: www.parrotvm.org/svn/parrot/revision?rev=31961
chromatic I'd set a breakpoint in new_pmc_header when something allocates that PMC, then set a breakpoint on its data member.
Although in this case, you can see the enclosing PMC_data and set a breakpoint within init when it first allocates the struct's memory. 22:45
Then set a watchpoint to see how the value of the ->pointer attribute changes over time.
Coke bah. now I'm failing tryin gto set the &!ws attribute on my optable.
chromatic My guess is that something sets it to an invalid value somewhere we don't intend.
Tene chromatic: can you show me anywhere in the tree where there are TGE-related failures? 22:46
chromatic Pheme
Tene Okay. I'll look.
Coke Hurm. that may be what's affecting me as well. I'm getting a NULL return value on $P0 = get_hll_global ['TclExpr::Grammar'], '$optable' 22:48
chromatic That should probably be [ 'TclExpr'; 'Grammar' ] 22:50
Tene We really need to start updating everything in the tree to use real namespaces instead of fakes
Infinoid hmm. are there any places where a PMC is created without new_pmc_header() being called? it seems to be sneaking past the breakpoints I've set.
chromatic ... but TGE doesn't use a real namespace there.
Coke chromatic: yes, well, that doesn't work either. =-)
Tene chromatic: woudl you endorse updating TGE to use real namespaces this close to the release?
chromatic Infinoid, there shouldn't be, unless it's a constant PMC baked into the tree.
Tene, only if we want those languages to pass their tests before the release. 22:51
Coke I'd endorse fixing ... what chromatic said. =-)
Tene chromatic: I meant in TGE itself
chromatic Is that necessary to fix the languages, or just an ancillary cleanup?
Tene Probably ancillary cleanup, but it might make the problem more obvious. 22:52
Although, to be honest, I'm also trying to avoid reading and understanding all of TGE
chromatic The next release is a week away. We'll have time to fix any breakage if we stay on top of it. 22:53
Coke yah, as soon as there are failures in the smolder tests, they'll get fixed. =-) 22:54
Tene If someone who knows TGE could add a failing test to t/compilers/tge, I'd be very grateful. I'm not holding my breath, though.
Infinoid sigh, my breakpoint condition needed an extra set of parens, working now 22:55
22:56 dmknopp joined 23:03 jrockway joined
Infinoid chromatic: when you said "->pointer attribute", did you mean ->data? or ->cache._ptrs._pmc_val? 23:05
I'm still not very familiar with the pmc structure internals.
chromatic Look at the ATTR declaration in the CPointer PMC. 23:06
One element is the type and one element is the pointer.
Infinoid so that's a structure pointed to by pmc->pmc_ext? 23:07
or do they overlay the pmc structure elements directly somehow?
Infinoid reads pdd17 23:09
Tene Going home now.
Infinoid ah, that's what data points to. got it
chromatic Exactly. 23:11
dalek r31962 | Whiteknight++ | calling_conventions: 23:14
: [Calling_conventions] As promised, committing a change that allows parrot to compile without segfaulting. Undid changes to Parrot_PCCINVOKE, but I think I'm getting closer to a merger of the two implementations.
diff: www.parrotvm.org/svn/parrot/revision?rev=31962
r31963 | cotto++ | trunk:
: [pmc] POD formatting fix
diff: www.parrotvm.org/svn/parrot/revision?rev=31963
Infinoid the pointer was initialized to zero, assigned once, then segfault. pointer value is still the same at the time of the segfault
...and is not the same as the value that pobject_lives() was apparently called with 23:15
chromatic That's bizarre.
Infinoid that value isn't even aligned to a dword boundary.
chromatic There's part of the problem.
Infinoid well, the pointer value is good... pobject_lives is called with random trash tho
err, a valid base with random trash added to it
good value: 0x7fff1f63cf88 23:16
bad value: 0x7fa416d731ab
23:16 bacek_ joined
Infinoid gonna break in Parrot_CPointer_mark, to see where it gets that value from 23:16
chromatic Is the (PObj *) cast buggy? 23:19
Infinoid is it really a pointer to a pointer? or is it just a pointer?
chromatic As far as I can tell, it's a pointer to a pointer. I read all assignments to it in CPointer and that's what it is. 23:20
That technique doesn't thrill me with glee, but it ought to work.
Infinoid ok, misunderstanding on my part then. 0x7fff1f63cf88 points to a pointer whose value is 0x7fa416d731ab 23:21
gotta add another * to my watchpoint.
cotto t/pmc/cpointer.t is anemic. Feel free to fatten it up once you understand it well enough. 23:24
Infinoid on the 4th or 5th assignment, it's set to a non-aligned (but still even) value by some assembly code in pmc_new@plt 23:27
that doesn't sound right.
23:30 Limbic_Region joined
Limbic_Region purl msg chromatic thanks for the perl6 meeting minute summaries - I see you are catching up to real time. 23:31
purl Message for chromatic stored.
Limbic_Region particle ping 23:33
chromatic I should be up to date by Thursday.
Limbic_Region well, I know it is a mostly thankless task 23:34
chromatic True. 23:35
23:35 jrockway joined
Limbic_Region but with my freelance gig consuming 15 to 20 hours a week, my full time job, and 2 little ones at home - I don't have any other way to keep up with what's going on 23:35
so I for one appreciate it
nopaste "Infinoid" at 96.238.213.50 pasted "corrupt PMC and where it was assigned from" (306 lines) at nopaste.snit.ch/14293 23:36
Infinoid I did some subsequent snooping around (rather spammy) and saw that the CPointer PMC and its pointer attribute are still intact and still pointing to the right place. 23:37
its a shame gdb doesn't support reverts and snapshots. 23:39
chromatic 0x00007f324568313e in Parrot_gt_p_ic_ic (cur_opcode=0x1517628,
interp=0x13bd080) at src/ops/cmp.ops:430
Infinoid 430 PMC *temp = pmc_new(interp, enum_class_Integer); 23:40
chromatic Want a crazy guess?
Infinoid sure
Whiteknight i like crazy
chromatic Something's not marking the CPointer PMC properly and it's getting GCd and reused and we're seeing its guts getting reassigned out from under it.
Infinoid Parrot_CPointer_mark was called for this instance, right before the crash 23:41
cotto Should t/distro/test_file_coverage.t care if there are t/pmc/*.t files with names that don't match PMCs?
It seems like the only concern should be PMCs without test files, not vice versa.
chromatic Hm, that does shoot down most of my crazy guess.
cotto, I agree.
Infinoid I can check the PMC flags... which flags should I check for? 23:42
cotto thanks.
chromatic If it gets GCd, its vtable should get set to 0xdeadbeef.
Which reduces the likelihood of anything ever calling its mark.
Now its PMC_EXT might get recycled accidentally, but that's unlikely too. 23:43
Infinoid nope, vtable and data values still look unchanged
the CPointer PMC is still intact, and so is attributes.pointer 23:44
but the bounce pointer pointed to by attributes.pointer has been overwritten
by what looks like some runtime linking code, or whatever the assembly in pmc_new@plt is doing
chromatic Are we allocating the pointer to the pointer on the stack, and running into the concomitant problem there? 23:45
Infinoid the first pointer is contained within the attributes structure, allocated by malloc() via mem_sys_allocate() 23:46
chromatic This seems like one place where a union does make sense though.
Infinoid the second level pointer came from somewhere, I didn't do a backtrace there. I'll run through it again 23:47
oh, it's still in Parrot_build_sig_object_from_varargs() 23:51
its a PMC, one of the varargs params, gonna take some more digging to figure out how it was allocated. 23:54
but the PMC's vtable pointer is set to 0x9040000000000000, which seems unlikely 23:58
chromatic Very unlikely.
It's probably not a PMC, just something cast to a PMC. 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!