Camelia, the Perl 6 bug

IRC log for #parrot, 2008-02-11

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:03 Tene lolcode patch sent.  I'm confident that this patch is decent, and 'make test' passes.
00:13 rdice joined #parrot
00:23 svnbotl r25634 | chromatic++ | trunk:
00:23 svnbotl : [src] Replaced a magic constant about the size of the destination STRING to
00:23 svnbotl : preallocate with a much smarter heuristic: the destination has to be at least
00:23 svnbotl : the size of the format string, but doubling that size will help us avoid the
00:23 svnbotl : first reallocation when substituting into it.
00:23 svnbotl : Not only is the code clearer, but we avoid at least one potentially-slow memory hit and waste less memory on smaller strings.
00:23 svnbotl : I also cleaned up some formatting in this function while it was hurting my
00:23 svnbotl : eyes.  It's far too deeply nested, but I mitigated some of the damage.
00:23 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25634
00:26 wknight8111 joined #parrot
00:29 simcop2387 ok i'm fairly new to parrot and just playing around, but it seems that pbc_merge fails with a segfault for me when i try to use it to merge a pbc that was compiled with .HLL 'Lua', 'lua_group' set, so i guess my question is, have i done something i'm not supposed to or is pbc_merge?
00:29 simcop2387 pbc_merge not doing something its supposed to*
00:35 adu simcop2387: interesting
00:36 adu simcop2387: I'm new too, I've never heard of pbc_merge
00:36 simcop2387 adu: that was my thought too, sounds to me like a bug in pbc_merge and something to test for in the future but i've got no clue how to fix it
00:37 simcop2387 i'm currently playing around with mixing lua and pir and turning them into an executable for the heck of it, but i've run into this
00:37 chromatic joined #parrot
00:37 chromatic pbc_merge is probably doing something untoward.
00:38 chromatic The best thing to do is run the program under the debugger and post a backtrace to parrotbug@perl.org.
00:38 simcop2387 thats what i figured, i'll have to figure out why gdb doesn't find any symbols but thats another problem (probably because i did it wrong quickly)
00:40 simcop2387 ok... it works fine in the parrot directory... segfaults outside of it
00:40 simcop2387 i'm missing something here...
00:41 svnbotl r25635 | chromatic++ | trunk:
00:41 svnbotl : [src] Remove string_nprintf(), which is unused except in t/src/sprintf.t.  If
00:41 svnbotl : we need it later, we can get it out of SVN.  Closes RT #44053.
00:41 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25635
00:41 Tene Hmm.  That lolcode patch I sent hasn't showed up on RT yet.
00:41 chromatic It probably can't load the dynpmc shared library (lua_group.so, right?) and doesn't have a check for it.
00:42 simcop2387 thats what i'm thinking now
00:42 wknight8111 What are PMC's, exactly? I'm having a lot of trouble in the code and documentation finding out what they are and what role they play
00:43 chromatic They're the fourth type of primitive in Parrot.
00:43 chromatic The other three primitives are integers, floats, and strings.
00:43 chromatic A PMC is anything that's more complex, including aggregates, objects, coroutines, and threads.
00:44 chromatic There's a standard PMC interface which describes operations that all PMCs must implement; that's the vtable interface we talk about sometimes.
00:44 chromatic The semantics of that interface depend on the PMC, but every PMC supports all of those operations in the sense that you can perform them on the PMC without crashing Parrot.
00:45 chromatic You might get an exception, but you can catch exceptions more easily than segfaults.
00:45 wknight8111 okay, thanks. That helps a lot
00:45 chromatic You're welcome.
00:46 simcop2387 chromatic: yep that looks like the problem exactly (symlinked the runtime directory into place where i'm building it and it works fine, i'll file a bug as soon as i figure out a good way to describe it)
00:46 kid51 joined #parrot
00:47 chromatic I'll be sure to take a look at the report.  There may be a simple solution.
00:48 simcop2387 k
00:51 adu wknight8111: so far as I understand them, a PMC is vaugely similar to an IObject interface
00:52 Theory joined #parrot
00:56 wknight8111 thank you
01:13 AndyA joined #parrot
01:46 svnbotl r25636 | jkeenan++ | ports:
01:46 svnbotl : This branch was intended to accommodate development of a module for
01:46 svnbotl : detecting macports during configuration, but will not be needed.
01:46 svnbotl r25637 | jkeenan++ | trunk:
01:46 svnbotl : Tag may be deleted because the branch it was marking has been deleted.
01:46 svnbotl r25638 | jkeenan++ | trunk:
01:46 svnbotl : Tag no longer needed.
01:46 svnbotl r25639 | jkeenan++ | trunk:
01:46 svnbotl : Tag no longer needed.
01:46 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25639
02:56 slightlyoff joined #parrot
03:33 petdance joined #parrot
03:44 diakopter weird, I do not know why svnbotl stopped giving diff URLs
03:44 petdance chromatic: Did you mean to remove string_npsrintf but not do so?
03:45 chromatic I thougth I did.
03:45 chromatic thought
03:45 petdance you didn't.
03:45 petdance or didn't comit at least.
03:46 Andy That's OK, I'll do it.
03:48 chromatic Okay, thanks.
03:50 svnbotl r25640 | jkeenan++ | trunk:
03:50 svnbotl : Applying patches supplied by Alan Rocker documenting more C functions.
03:50 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25640
03:56 svnbotl r25641 | petdance++ | trunk:
03:56 svnbotl : add a macro PARROT_HAS_SAL for the SAL annotations in MSC
03:56 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25641
04:12 Andy chrmoatic: Maybe you just removed the tests?
04:13 Andy chromatic: Maybe you just rmeoved the tests?
04:20 chromatic I did.
04:20 chromatic Forgot to commit src/string.c.
04:20 Andy you gonna commit it or am I?
04:21 chromatic Just did.
04:21 Andy k
04:24 chromatic Thanks for the check.
04:25 Andy SO what can we do about all the uninitialized memory usage?
04:25 svnbotl r25642 | chromatic++ | trunk:
04:25 svnbotl : [src] Actually remove string_nprintf(), which I forgot to do in r25635.
04:25 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25642
04:26 Andy we've got 94 unintialized usages, and only 48 leaks
04:44 Tene sjansen++ # useful feedback, can actually read a spec.
04:57 svnbotl r25643 | petdance++ | trunk:
04:57 svnbotl : remove a trailing space
04:57 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25643
05:02 Andy Mmmm, interesting: By using one of the _zeroed_ macros, I gain a bunch more of uninitialized usages.
05:02 svnbotl r25644 | petdance++ | trunk:
05:02 svnbotl : use the malloc wrapper macros more
05:02 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25644
05:21 chromatic Uninitialized how?
05:21 chromatic I'm starting to wonder if those uninitialized uses are coming from the stack scanning code.
05:40 svnbotl r25645 | petdance++ | trunk:
05:40 svnbotl : using more wrapper macros
05:40 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25645
05:40 Andy chromatic: where's the stack scanning stuff?
05:41 chromatic trace_system_areas() I believe.
06:04 keijohz joined #parrot
06:04 keijohz has anyone tried to use parrot in a game engine environment?
06:05 keijohz or would there be any major obstacles doing it?
06:05 Andy Prob'ly not
06:05 chromatic The embedding interface isn't entirely mature, but trying it is a good way to help get it mature.
06:06 keijohz and how is the performance comparable to say Mono / Lua / plain C?
06:07 keijohz i guess it will still be optimized, but i just want to have a vague ideia
06:07 chromatic It's slower with Parrot, partly because Parrot's more flexible and partly because we haven't optimized much.
06:07 chromatic My guess is probably a little bit slower than Lua, but not by an order of magnitude.
06:07 keijohz ok thanks
06:08 chromatic Possibly faster in some ways.
06:08 keijohz also can we control when garbage collection runs?
06:09 chromatic Yes, from either C or Parrot bytecode.
06:09 keijohz neat. :)
06:14 Andy huh.  NOT calling trace_system_stack() causes a segfault.
06:15 chromatic Yeah, PObjs in registers and on the stack will get collected.
06:16 chromatic CPU registers, that is.
06:19 chromatic You could temporarily comment out the calls to sweep and recollect, if you're debugging what I think you're debugging.
06:20 Andy I'm just flailing, really
06:20 Andy I don't get what pobject_lives does.
06:20 chromatic It's the mark part of mark-and-sweep.
06:21 chromatic All of the live GCable objects in the system should be reachable.
06:21 Andy So it's really "mark_pobject_to_live"
06:21 chromatic Yep.  "Don't collect this PMC/Buffer/String during the sweep phase of GC."
06:22 Andy Sounds like we might use a s/pobject_lives/mark_pobject/g
06:22 chromatic I want to make one more change to the function if we change it.
06:22 chromatic Instead of the if POINTER IS NOT NULL/then pobject_lives
06:22 chromatic I want to move the if POINTER check into pobject_lives.
06:23 chromatic This actually solves a problem that we'd have with a copying collector.
06:24 Andy go ahead
06:24 chromatic We can swap the internals of the macro if we use a copying collector -- in that case, before doing the check on the location where we have the pointer to the PObj, we check to see if something else in the mark phase has copied the PObj to a new pool.  If so, we update the pointer to point to the new location.
06:24 chromatic Otherwise, we copy it to the new location and update the old location with the new location.
06:25 Andy which macro?
06:25 purl rumour has it which macro is this? =-)
06:26 chromatic Well whatever pobject_lives is.  Macro or function.
06:26 Andy function
06:26 purl i think function is called from all over, including src/ops/io.ops and lib/Parrot/OpLib/core.pm.  but I don't think anyone calls the macros except io.c itself.
06:27 chromatic purl, forget function
06:27 purl chromatic: I forgot function
06:28 chromatic Thus we get to keep all of our lovely marking code, but we avoid (mostly) the trouble of updating references with a copying/compacting collector.
06:28 svnbotl r25646 | petdance++ | trunk:
06:28 svnbotl : teeny documentation
06:28 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25646
06:31 Ademan joined #parrot
06:31 chromatic I'm not entirely sure how it works for pointers in system areas though.
06:47 zostay joined #parrot
06:47 zev_ joined #parrot
06:47 MikeJS_ joined #parrot
06:47 Coke_ joined #parrot
06:52 Andy joined #parrot
06:55 diakopter joined #parrot
06:58 japhb joined #parrot
06:58 simcop2387 joined #parrot
07:00 TimToady joined #parrot
07:00 man_in_shack joined #parrot
07:00 Andy oh look, potential null derefs
07:03 Andy In fact, all-but-guaranteed null derefs
07:15 Andy ok, I am so pleased for tonight
07:16 uniejo joined #parrot
07:19 chromatic Down with null derefs.
07:19 chromatic Up with miniskirst.
07:19 chromatic aw it wasn't that clever anyway.
07:20 AndyAway SO PLEASED
07:20 AndyAway All those "use of uninitialized memory" is really NULL derefs
07:20 AndyAway Or rather, all those NULL derefs were "use of uninitialized memory"
07:20 AndyAway although clealry the reverse may not be true.
07:20 svnbotl r25647 | petdance++ | trunk:
07:20 svnbotl : This little || should have been &&.  Otherwise, we dereference NULL.
07:20 svnbotl : Thanks, splint!
07:20 svnbotl : Diff in runs from running valgrind on "hello world":
07:20 svnbotl : 4974c2974
07:20 svnbotl : <  ERROR SUMMARY: 973 errors from 99 contexts (suppressed: 14529 from 5)
07:20 svnbotl : ---
07:20 svnbotl : >  ERROR SUMMARY: 879 errors from 59 contexts (suppressed: 14529 from 5)
07:20 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25647
07:20 chromatic Are you *sure* about r25647?
07:21 AndyAway AHA
07:21 chromatic Actually, I've just convinced myself.
07:22 Andy Some of these are two derefs in succession.
07:22 Andy It'll complain about dod.c:199 and then dod.c:203
07:22 Andy we could probably throw an assert in pobject_lives and go from there.
07:23 Andy but now, I must head to bed.
07:23 chromatic I'll try that tomorrow.
07:27 svnbotl r25648 | fperrad++ | trunk:
07:27 svnbotl : [Lua]
07:27 svnbotl : - aligned with Lua 5.1.3 (part 1)
07:27 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25648
07:34 paq joined #parrot
07:53 iblechbot joined #parrot
08:38 shamu joined #parrot
08:38 arcady joined #parrot
08:39 HG` joined #parrot
08:40 SCalimlim joined #parrot
08:59 nina29 joined #parrot
08:59 svnbotl r25649 | chromatic++ | trunk:
08:59 svnbotl : [src] Changed raw assert() calls to PARROT_ASSERT(), which gives us a nice
08:59 svnbotl : backtrace when it fails (at least for certain platforms that support it).
08:59 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25649
09:00 alvar joined #parrot
10:01 Tene Mmm... much nicer.
10:07 IllvilJa joined #parrot
10:24 ruoso joined #parrot
11:56 mj41 joined #parrot
12:08 rdice joined #parrot
12:42 mire joined #parrot
13:06 MagNET joined #parrot
13:06 svnbotl r25650 | fperrad++ | trunk:
13:06 svnbotl : [install]
13:06 svnbotl : - add punie & pynie
13:06 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25650
14:13 gryphon joined #parrot
14:58 Andy joined #parrot
14:58 jhorwitz joined #parrot
15:00 davidfetter joined #parrot
15:04 svnbotl r25651 | petdance++ | trunk:
15:04 svnbotl : more malloc macro retrofitting
15:04 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25651
15:17 svnbotl r25652 | petdance++ | trunk:
15:17 svnbotl : remove an unnecessary assert.h
15:17 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25652
15:23 svnbotl r25653 | petdance++ | trunk:
15:23 svnbotl : arg is really ARGMOD, not ARGIN.  Thanks, splint!
15:23 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25653
15:24 drforr_ joined #parrot
15:54 ilbot2 joined #parrot
15:54 Topic for #parrotis now  #parrot Parrot 0.5.2 Released | http://parrotcode.org/ | see http://www.parrotcode.org/misc/parrotsketch-logs/ for logs
15:59 moritz joined #parrot
16:39 claes joined #parrot
16:39 claes left #parrot
17:21 sjansen joined #parrot
17:23 Theory joined #parrot
17:37 parrot-poke joined #parrot
18:05 mire joined #parrot
18:06 mire joined #parrot
18:13 Theory joined #parrot
18:30 gryphon joined #parrot
18:41 Ron joined #parrot
19:25 davidfetter joined #parrot
19:28 coke joined #parrot
19:28 coke will ya look at that.
19:29 * davidfetter looks around
19:29 davidfetter at what?
19:29 coke We have coke sign.
19:31 particle hey there coke.
19:50 coke slow day today.
19:52 Pabellon joined #parrot
19:52 Tene Nice, that means there's more time to get things done.
20:01 zaphod joined #parrot
20:35 zaphod joined #parrot
20:37 DarkWolf84 joined #parrot
20:41 kj joined #parrot
20:45 Andy OK, you kow what sucks?
20:45 Andy When I'm the last person to have done a commit.
20:45 Andy GET TO WORK PEOPLE!!!!
20:45 Andy FASTER FASTER
20:46 sjansen What's that you say? Free caffeine with each commit?
20:46 Andy YES YES YES GOD YES
20:46 Andy FASTER
20:50 Andy I think I'm gonna make Parrot_assert a func
20:53 silug joined #parrot
20:54 coke yes, but why.
20:54 * Tene looks for something to hacka t on rakudo.
20:57 zaphod I think that PAST might need to mangle variable names to support lexical scoping as many languages would expect it.
20:58 Tene zaphod: explain?
20:58 kj zaphod: each scope has its own lexpad
20:58 kj no need for mangling, the var is just stored in a different lexical pad
20:58 zaphod so pir has .lex, but it puts at compile time the lexicals in the lexinfo
20:58 kj iiuc
20:59 zaphod which means that when you do something like "my $x = 1; {my $x = $x +1; }" that $x in the inner scope is seperate from the $x in the outer scope.  The "$x +1" is the outer scope $x
20:59 zaphod but .lex will say that $x is in my inner scope, even though I haven't set it yet
20:59 kj mmm
21:00 kj well it depends...
21:00 kj that is a declaration
21:00 kj but not declared YET
21:00 kj so first you evaluate the rhs
21:00 zaphod doesn't work in pir
21:00 zaphod I've tried
21:00 kj oh right
21:00 kj i was thinking symbol tables
21:00 kj pir is different
21:00 kj right. good point I think
21:01 kj find_lex used to take 3 arguments; one indicating what level of lexpad
21:01 kj (on a "stack" of lexpads)
21:01 kj but that's long gone
21:01 zaphod that would be useful
21:02 zaphod otherwise the vars of closures and such are very "flat" and static
21:02 kj mm i see what you mean
21:02 zaphod which makes you have to mangle names to distinguish
21:02 kj well preferably not mangling
21:02 kj that's such a primitive solution
21:02 kj imho
21:03 zaphod I was thinking of hiding inside the PAST compiler
21:03 zaphod hiding it
21:03 zaphod I don't want to hide inside a compiler
21:03 kj better have parrot support it i think?
21:04 zaphod might be right
21:04 zaphod otherwise I have to admit I have a really hard time seeing the benifit of the lexpad stuff
21:05 zaphod useful for closures, but not for nested scopes
21:05 kj there is ccurrently still a .namespace <ident> directive in PIR
21:06 kj it's deprecated, but I'm not sure if we should keep it ( i sent an email on that earlier; no reply yet)
21:07 zaphod would it solve this problem?
21:07 nopaste "zaphod" at 79.207.244.211 pasted "lexical problem example" (19 lines) at http://nopaste.snit.ch/12306
21:07 coke .namespace is deprecated !?
21:07 kj ehm. no, you're right.
21:07 kj only if a language doesn't use lexicals
21:08 kj coke: only the directive that happens to be spelled the same way
21:08 zaphod which is probably quite seldom
21:08 kj not the .namespace []
21:08 kj coke: i mean the .namespace my_namespace / .endnamespace
21:09 zaphod was the find_lex with the third arg to specify how far back in the stack to start searching?  That would be perfect (maybe)
21:09 kj zaphod: yah something like that
21:10 kj -1 was the top level or whatever
21:10 kj -2 the level below that
21:10 kj it's been a few years back I think
21:10 kj since :lex was introduced I *think*
21:10 kj (uhm, since then it's gone)
21:10 zaphod the main problem is that from the docs, as I understand it, there is no stack anymore
21:11 kj well, it was a conceptual stack I guess
21:11 kj mmm good point :-)
21:11 zaphod so for a closure everything is squished together
21:12 kj well, why not send this thing to list?
21:12 zaphod sure thing
21:12 kj I think you have a point; but then again, I'm no expert in this field
21:15 buildbot joined #parrot
21:21 coke coke?
21:21 coke purl, coke?
21:22 coke left #parrot
21:46 purl joined #parrot
21:51 slightlyoff joined #parrot
21:52 Tene purl: coke?
21:52 purl somebody said coke was mailto:coke@cpan.org or Will Coleda or the documentation monkey or seriously considering forking and starting with a dumber version of tcl that works on PCT
22:03 paq joined #parrot
22:17 HG` joined #parrot
22:32 peeps[work] joined #parrot
22:35 Theory joined #parrot
22:37 TonyC joined #parrot
22:40 Limbic_Region joined #parrot
22:57 nopaste joined #parrot
23:03 TonyC joined #parrot
23:05 ruoso joined #parrot
23:06 wknight8111 joined #parrot
23:09 gryphon joined #parrot
23:17 ruoso joined #parrot
23:22 Limbic_Region joined #parrot
23:28 Coke_ coke is also wcoleda@gmail.com
23:28 purl okay, Coke_.
23:40 svnbotl r25655 | petdance++ | trunk:
23:40 svnbotl : reheaderized
23:40 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25655
23:47 ruoso joined #parrot
23:47 svnbotl r25656 | petdance++ | trunk:
23:47 svnbotl : Added Parrot_assert() as a true assert wrapper around Parrot_confess(), because splint needs to operate on a function to understand the assert() semantics, not a macro
23:47 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=25656

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

Parrot | source cross referenced