Camelia, the Perl 6 bug

IRC log for #parrot, 2008-10-14

Parrot | source cross referenced

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

All times shown according to UTC.

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

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

Parrot | source cross referenced