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

Powered by Cro and the Raku® Programming Language.

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

Thank you!