Parrot 1.2.0 released | parrot.org/ | Weekly Priority: Profiling | Parrot VM Workshop, Pittsburgh, June 20-21
Set by moderator on 7 June 2009.
jonathan OK, that would be my (muchly) favored option. 00:00
pmichaud being able to build against the build tree is very useful, especially when testing new features in Parrot
i.e., I use it alos.
*also
jonathan Right, I think it's valuable to have the choice.
pmichaud okay, will hopefully see you tomorrow
(errands here)
darbelo cotto: I *think* I read somewhere that Singletons were allocated out of the constant PMC pool. 00:01
jonathan Sleep here.
night all
Coke Any chance someone could poke at TT #732? 00:02
cotto darbelo, I can confirm that. 00:03
Infinoid Coke: Won't that go away when we have GCable contexts? 00:04
Coke Infinoid: perhaps. in the mean time, the memory leaks are killing me.
dalek rtcl: r447 | coke++ | trunk/docs/spectest- (2 files):
Update spec test with a recent run.
 00:05
darbelo Then you are probably right about them living on. AFAICT the gc ignores the constant PMC pool.
Infinoid I just know I've tried and failed to clean up context allocations in the past. That code has dragons.
Coke Infinoid: I have an IMCC memory leak that needs love too. you want that one? =-)
Infinoid I need to pack right now, maybe next week? :) 00:06
Coke thanks for not just coming out and saying no. =-)
chromatic: started the test now. Ping me in about 2 hours. :| 00:07
cotto darbelo, you're safe. The constant PMC pool is only swept when Parrot exits.
Whiteknight, unping
darbelo So long as users thaw the context before using any decnums we're safe, then. 00:08
cotto Whiteknigh++ for making it less painful to skim through the gc code 00:09
Coke Infinoid: we're not close to getting GC-able contexts, are we?
darbelo If not, then 'undefined behaviour will occur' and it won't be our problem either.
Infinoid There's a branch, I think, but parrot keeps flapping away from it
cotto darbelo, that sounds good. I'd also recommend some sanity checks in the number PMCs' thaw VTABLE functions, in the interests of failing early. 00:10
Infinoid Coke: Guess there used to be a branch but it was removed. trac.parrot.org/parrot/ticket/596 00:11
cotto Sanity will ensue if users thaw a decContext before they thaw any decNums that depend on that decContext. Otherwise, Bad Things may happen. 00:12
kid51_at_dinner Infinoid: I got no speedup in 'make coretest' between trunk and io_rewiring branch. 00:13
trunk @ r39458: 5:22 00:14
branch @ r39460: 5:24
darbelo Actually, I'd just pmc_new() the context on DecNum's thaw too. If the context was thawed earlier, we get the right one. If the context is thawed after, we allocate it and the DecNumContext thaw() modifies it. We're safe even if you thaw a DecNum with no context. 00:15
Infinoid kid51: That's odd. coretest went from 7 minutes to 2 here 00:17
Which platform?
purl I'm running on OS/2 on an Atari, can you help?
Infinoid watches purl swapping 00:18
darbelo The only catch is: if you want to thaw both a DecNum and a DecNumContext, you have to thaw them both before performing any operations.
nopaste "infinoid" at 24.182.55.77 pasted "The '000,'-string output benchmark, courtesy of pmichaud" (20 lines) at nopaste.snit.ch/16836 00:21
Infinoid kid51: You should also see a ridiculous difference between trunk and branch, for that simple pir benchmark (like, 46 seconds -> 0.7 seconds) 00:22
00:24 eternaleye joined
kid51 Infinoid: Linux/i386 00:27
Infinoid: I'll try again. 00:28
00:28 snarkyboojum joined 00:29 Zak joined, bacek_ joined
Infinoid You should definitely see a difference on linux. I'll re-test here too 00:30
If you don't see a difference on linux, you've either got a superfast disk or you're running in a VM that doesn't propagate disk write/flush events 00:32
kid51 This time was faster: 5:06 -- but, of course, there could be a positive side-effect from additional ccache-ing 00:34
This is a Linode Linux VM.
What do you mean by "propagate disk write/flush events" 00:35
Infinoid The speedup was from removing an extra fsync() parrot was doing after every write(). In effect, it was doing the equivalent of the command line "sync" command, for the file, which meant parrot went to sleep waiting for a round-trip to/from disk before resuming execution, every time it wrote 00:36
VMs typically don't expose filesystem flushes to the host OS, so you wouldn't see any difference in one
(or at least, it sounds like Linode doesn't) 00:37
kid51 I don't understand much about VMs ... all I know is that for all of *my* purposes my Linode is a box out there in cyberspace somewhere ... even though I know it's a slice of a disk in Dallas or Nashville or somewhere. 00:38
Infinoid Looks like it's a xen instance, and it looks like xen handles fsync()'y things a lot more efficiently than real hardware does. 00:39
Coke since it's all fake anyway, makes sense. =-)
kid51 make benchmark_tests: 69 seconds in trunk; 67 seconds in io_rewiring branch 00:40
Infinoid Save nopaste.snit.ch/16836 as x.pir and try comparing that. :)
That should hit all the other things that Whiteknight++ sped up 00:41
kid51 Should that be called: ./parrot x.pir ? 00:42
Infinoid yeah
or time ./parrot x.pir
(to see how long it took)
kid51 Was it supposed to have generated output? I got nothing on STDOUT.
Infinoid It creates a file called test-pir.txt, to benchmark file I/O 00:43
or file writes, at least
kid51 trunk:
[li11-226:parrot] 534 $ time ./parrot x.pir 00:44
real 0m24.128s
user 0m11.340s
sys 0m0.220s
Infinoid Your trunk time is quite a bit better than any real hardware I have access to. Timings on my thinkpad are about twice that
kid51 Yeah, baby:
io_rewiring:
[li11-226:io_rewiring] 538 $ time ./parrot x.pir
real 0m1.992s
user 0m0.780s
sys 0m0.010s
Infinoid There we go.
Funny how in both cases, wallclock time was twice the userspace cpu time 00:45
I would have expected that from trunk but not branch
kid51 Where is the time that is neither user nor sys? 00:46
real -( user +sys ) ??
Infinoid yeah.
that's waiting for disk, executing other processes, etc 00:47
kid51 There's considerable variance. Here's another round -- one even more favorable to branch: 00:48
[li11-226:parrot] 542 $ time ./parrot x.pir
real 0m24.224s
user 0m11.730s
sys 0m0.250s
[li11-226:parrot] 543 $ cd -
[li11-226:io_rewiring] 544 $ time ./parrot x.pir
real 0m1.651s
user 0m0.810s
sys 0m0.010s
Infinoid how much RAM you got in that vm? 00:49
kid51 Tell me how to measure it.
Infinoid "free"
kid51 [li11-226:io_rewiring] 545 $ free
total used free shared buffers cached
Mem: 295528 122700 172828 0 1608 22988
-/+ buffers/cache: 98104 197424
Swap: 263160 54588 208572
Infinoid hmm. I suppose there's no telling how loaded the host OS is, but assuming all your memory is real and not being swapped, you should be able to hit disk cache for test-pir.txt, no problem 00:50
if you're seeing variance, you probably aren't operating in cache. 00:51
which means all bets are off :)
kid51 Well, I believe ccache is on ... because periodically it fills up the disk! 00:52
Infinoid ccache shouldn't affect runtime performance 00:54
oh. disk cache != ccache 00:55
Coke chromatic, Infinoid: I haven't finished yet, but it certainly /seems/ faster. 01:03
(I may be comparing my 'feel' to 4.5 months ago, though.) 01:08
Whiteknight Coke: I start work on GCable contexts as soon as the cc_rewiring branch lands
Coke Whiteknight++ 01:09
Whiteknight these io branch numbers keep looking better and better 01:11
Coke I wonder how much is attributable to just the fsync() fix. 01:13
chromatic A fair amount of wallclock time, but IO in loops in long-running programs will benefit from far fewer PMCs allocated. 01:15
Whiteknight I dont know. fsync is more expensive then PCCINVOKE, but the later was called more frequently
Infinoid It's all good. Making the parrot flap faster
Coke chromatic, Infinoid, Whiteknight: tcl's spectest took 4045s in trunk, and 4177s in branch; but for some reason the branch passed 2 more tests. I wonder if someone on feather was killing my tests earlier. 01:16
2 more test /files/
"2009-06-08 21:36",440,"r39452",57,3275,1791,866,618,4045
+"2009-06-09 02:04",440,"r39460",59,3547,1933,992,622,4177
1st is last run on trunk; second is run on io_rewiring.
"date","revision","parrot revision","files","test","pass","fail","skip","time in seconds" 01:17
Whiteknight Coke: I almost can't believe those numbers. There's no way it takes more time in branch that I can find
Coke Whiteknight: is feather.perl6.nl a virtual machine?
Infinoid Coke: Yes.
Whiteknight i have no idea what feather is
Coke Whiteknight: there you go.
feather?
purl feather is feather.perl6.nl/ or a perl6 community development server or run by juerd.
chromatic Looks like the branch passed 142 more tests. 01:18
Coke chromatic: 2 test files passed this time that failed in the run on trunk.
Whiteknight well, they're about to be passing in trunk too
Infinoid Whiteknight++
Coke chromatic: I've had people kill processes on my on feather in the past, and I already threw up the log file from the trunk run earlier. 01:19
chromatic Oh, test files. I counted something else.
Coke so it's a little slower, but it did more, and if I had known it was a virtual machine, I'd not have bothered since we now know it's a waste there. =-)
59:57, 1933:1791.
+lsearch.test: Total 101 Passed 47 Skipped 0 Failed 54 01:20
+scan.test: Total 171 Passed 95 Skipped 4 Failed 72
Infinoid sees patches of blue sky through the hail
Whiteknight hold on, I'm getting a t/pmc/undef.t failure in the branch now, a fresh checkout 01:21
Coke chromatic: any suggestions on dealing with all my memory PANICs ? 01:23
(aside from opening tickets like #732)
chromatic That's the best option I can see.
Coke (and allocating less PMCs, which I'm trying to do.)
chromatic You know what makes them easy for me to debug; any help there helps everyone.
Coke oh; someone here might be able to help with this; right now "4/-3" with tclints gives -1; it should give -2; I presume I can fix this with a strategic vtable override... 01:25
chromatic Tcl has its own math? 01:26
Tene Tcl uses floor() instead of round() 01:27
Coke and integer division stays integer. 01:28
4/-3.0 NE 4/-3
(uses floor) - ah. that gives me a clue as to where to put that. 01:29
d- VTABLE_set_integer_native(INTERP, dest, SELF.get_integer() / d); 01:30
+ VTABLE_set_integer_native(INTERP, dest, floor(SELF.get_integer() / d));
(i would have guessed that in src/pmc/tclint.pmc, but no love.) 01:31
Whiteknight Infinoid: ping
Infinoid Whiteknight: yo
Coke ah. need to do the division as float manually (was forcing it to int before then.)
Whiteknight infinoid: I'm getting a segfault test failure in the branch now suddenly. t/pmc/undef.t
Infinoid bt? 01:32
purl bt is pretty cool, as well. or Brian Transeau, one of the foremost electronica artists in the world or Just Another Evil Telco or www.btmusic.com or (: british telecom) or mp3z.darkuncle.net/electronica/trance/BT/ or "base-T" as in 100bT or BitTorrent or debt without the "de" or bluetooth or (see: pcbt)
Coke tene++
Infinoid bt is also backtrace
purl okay, Infinoid.
Whiteknight bt is weird
nopaste?
purl well, nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
Infinoid Whiteknight: It passes here (if that matters)
nopaste "Whiteknight" at 68.44.174.229 pasted "Segfault for Infinoid" (137 lines) at nopaste.snit.ch/16837 01:33
Whiteknight Infinoid: it passed for me until I did a fresh checkout
Infinoid Aaw, my favorite! How did you know? You shouldn't have.
obj=0x21 is very obviously an invalid pointer 01:34
chromatic 0x21, oh yeah. The little PMC that couldn't.
Whiteknight yeah, that jumped out at me too
no idea where it's getting set to that though
my only thought is that somewhere I borked up the last merger with trunk
because we definitely didn't do any work in the OO system
Infinoid Class is trying to mark its _class->parents 01:35
Whiteknight right, and for some reason it is not right
Infinoid I don't really know what to tell you, except to echo 0 to /proc/sys/kernel/randomize_va_space and try to set a watchpoint on it 01:37
You might get lucky with valgrind, or you might not. 01:38
chromatic Did you 'make realclean'? PBC has changed.
Infinoid This is a fresh checkout, I think
Whiteknight yeah, fresh checkout 01:39
Infinoid I'll try a fresh checkout here. Did you pass any arguments to configure? 01:40
Whiteknight no arguments 01:41
Infinoid really wants perl Configure.pl -j
chromatic That would be lovely.
dalek rtcl: r448 | coke++ | trunk/ (2 files):
Use floor for integer division, pass a TODO test.
 01:42
kid51 Here's some more data, this time Darwin PPC:
trunk:
time ./parrot x.pir
real 2m24.749s
user 1m20.430s
sys 0m3.822s
io_rewiring:
$ time ./parrot x.pir
real 0m6.473s
user 0m4.049s
sys 0m0.192s
Infinoid Nice. I'd love to see your coretest timings, too 01:43
(I have no idea how much fsync bogs down darwin)
Whiteknight: Aaw, no crash here in fresh checkout 01:44
Whiteknight so what the hell is wrong with my system? 01:45
Infinoid Your system aligns the planets just right
Whiteknight: What do --gc-debug or --no-gc do?
"./parrot t/pmc/undef.t", "./parrot --no-gc t/pmc/undef.t" and "./parrot --gc-debug t/pmc/undef.t" all pass fine here 01:47
I can help you try to set a watchpoint to catch the corruption in action, but it's a time-consuming process 01:48
chromatic Are you both using 64-bits?
Infinoid yeah.
Whiteknight I am
I'm rebuilding
Infinoid By the way, sizeof(PMC) is 48 on x86-64 linux... that's always bugged me
chromatic It'd be nice to halve that. 01:49
Whiteknight sans UnionVal, we would get closer
Infinoid odd, sizeof(PMC) is 28 on x86-32. I thought these were supposed to be powers of 2 01:50
mugwump how big is a vtable these days? 01:52
chromatic Big.
Some 80 pointers.
85 maybe. 01:53
mugwump well, that's down from 144 when I first looked
Whiteknight I'm still getting the failure here. I think my system is cursed
mugwump that was gross overhead ... *rimshots*
bacek_ chromatic: 240+ pointers
chromatic Yeah, I just looked again.
Infinoid Whiteknight: Reproducable means debuggable 01:54
Coke does parrot provide the PID of the running instance?
Whiteknight Infinoid: I know, but I'm running out of time before I'm going to sleep 01:55
Infinoid Whiteknight: How long do you have? If you have at least 10 minutes, we can at least try it
If not, it'll probably crash tomorrow too :) 01:56
Whiteknight I have 5 minutes before I'm heading to bed
Infinoid Great, echo 0 to /proc/sys/kernel/randomize_va_space and get the crash in gdb 01:57
Then set a breakpoint in Parrot_Class_init if pmc == (the value of your Class PMC pointer)
Then re-run parrot and set a watchpoint on _class->parent
With any luck, that won't have a huge lifetime 01:58
If it takes too long, I'd just come back to it tomorrow... though I think this heisenbug has popped up a few times and eluded us so far 02:00
Whiteknight weird, it's telling me that Parrot_Class_init isn't defined 02:01
my whole system is retarded. this is a tomorrow-project
Infinoid it needs to run once to load libparrot.so's symbols
No problem, sleep well
Whiteknight goodnight 02:02
chromatic A modern gdb should offer to apply the breakpoint on the appropriate library load. 02:04
dalek rtcl: r449 | coke++ | trunk/runtime/builtin/pid.pir:
Return a numeric stub value instead of an empty string.
 02:05
Coke feedback: worth running a tcl spec test file that only passes one test?
rtcl: r450 | coke++ | wiki/SpecTestStatus.wiki:
with [pid] stub fix, all tests skipped instead of failing.
kid51 make coretest on Darwin PPC:
trunk:
02:06 snarkyboojum joined
kid51 real 10m29.536s 02:07
user 4m39.691s
sys 2m51.736s
io_rewiring:
real 9m50.837s
user 4m32.295s
sys 2m48.847s
Not as much difference there as on x.pir
Infinoid That's on real hardware? 02:09
chromatic CPU bound, I assume.
Infinoid Still more difference than he was getting on xen 02:11
I'll take what I can get :)
kid51 It's on a 5-y-o iBook 02:15
kid51 must sleep
purl $kid51->sleep(8 * 3600);
dalek rtcl: r451 | coke++ | wiki/SpecTestStatus.wiki:
Skip the http tests; fixup init.
 02:20
rtcl: r452 | coke++ | trunk/runtime/builtin/interp.pir:
[interp create] shouldn't die; make it do nothing for now.
rtcl: r453 | coke++ | trunk/library/safe.tcl:
add safe.tcl from the 8.5.6 tcl release.
 02:25
rtcl: r454 | coke++ | wiki/SpecTestStatus.wiki:
added a library file, new error
 02:29
rtcl: r455 | coke++ | wiki/SpecTestStatus.wiki:
fix wiki markup typo
 02:30
02:35 janus joined
Coke unicode question: 02:43
purl unicode question: is 'Sx{f6}ll' the same as Söll?
Coke $S1 = unicode:"abcd\\udead"
should that be value?
"valid"? 02:44
dalek rtcl: r456 | coke++ | wiki/SpecTestStatus.wiki:
note the source of the failure.
 02:53
02:56 cotto joined
dalek rtcl: r457 | coke++ | wiki/SpecTestStatus.wiki:
we have unknown, fix wiki error,
 02:58
Coke :q 02:59
GeJ Good night Coke 03:04
03:08 Alias joined
Coke ww. 03:09
Alias ww?
purl ww is probably wrong window
cotto ww is also 2/3 of www 03:10
purl okay, cotto.
cotto no need to thank me
Coke wonders if alias can answer his unicode question. 03:12
Alias I seriously doubt it :)
Coke is trying to get tcl's udead to generate a valid string in parrot. 03:13
Alias just turned up to keep an eye on any conversations on packaging formats and CPAN6
03:20 kesselhaus joined, donaldh joined
chromatic Coke, yes. 03:20
Coke chromatic: I can't seem to make a string there. composing a msg to parrot-dev, but if you can show me how to create a string in parrot with that codepoint... 03:24
03:24 tetragon joined
Alias chromatic: BTW, nice comeback in www.modernperlbooks.com/mt/2009/06/...oject.html 03:24
Coke $S1 = utf16:unicode:"abcd\\udead" - Illegal escape sequence in uxxx escape - too short 03:25
Alias chromatic: Of course, some of the underlying ideas are still a bit nuts
(Removing the dual-life modules that are needed to bootstrap CPAN)
Coke $S1 = utf8:unicode:"abcd\\udead" - Malformed UTF-8 string (also the default of unicode:)
Alias chromatic: Also, the dependency graph you want already exists. Take a look at some of the code in CPANTS::Weight 03:26
Coke $S1 = ucs2:unicode:"abcd\\udead" - unimpl ucs2
Alias (Although I've never needed an outright first class Graph.pm graph, but exporting to that wouldn't be hard)
chromatic With *that* codepoint? Do you have ICU? 03:30
I never suggested removing bootstrap modules. Someone claimed I did; it's a strawman. 03:32
Coke chromatic: ~/bird/bin/parrot_config revision slash has_icu
39460/1
purl 39460
chromatic You should have it then. 03:33
Coke icu 3.4.1
03:34 snarkyboojum joined
chromatic src/string/encoding/ucs2.c is mostly unimplemented. 03:35
Coke I shouldn't need ucs2 for this, though, neh? 03:36
(I was just checking various encodings to see fi I had better luck.)
03:39 Andy joined 03:42 Eevee joined
Coke hey, c? 03:46
purl c is for cookie, and it's good enough for you.
Andy purl, c is also chromatic 03:48
purl okay, Andy.
Coke (I just mailed the list) 03:54
chromatic Thanks. 03:57
Coke of course, I just found that I'm not doing raw strings, but using chr.
chromatic Talk to the bear! 03:58
Coke (should still work)
(20 partcl spec tests failing due to memory panic) 04:00
chromatic Hm, get_byte() almost certainly does the wrong thing in UCS-2. 04:04
At least the name is wrong. 04:05
Parrot_str_unescape() looks like it should call u_unescapeAt if we have ICU and are working with a UCS-2 STRING. 04:47
dalek rtcl: r458 | coke++ | trunk/runtime/builtin/lset.pir:
[lset] should only convert its argument to a list Obj if it's successful.
 04:49
rtcl: r459 | coke++ | wiki/SpecTestStatus.wiki:
This test passes now.
rrot: r39461 | petdance++ | trunk (2 files):
adding some consts, and ornamenting some parms for the headerizer
 04:53
04:55 cotto joined
Coke mark biggar? 05:04
biggar?
05:07 flh joined 05:12 eternaleye joined 05:27 eternaleye joined 05:32 tetragon joined
chromatic ./src/pmc/bignum.pmc:483: warning: ‘bn’ may be used uninitialized in this function 06:00
That looks bad.
06:07 uniejo joined
Coke OOC, how long does it take to run the spectest for rakudo? 06:14
Alias sorry, meeting 06:21
chromatic: You said "all"... I took that at face value
Well, more accurately
"Remove dual-lived modules from the core."
Still without nuance or caveat 06:22
You did mention it once back at the very beginning towards the bottom of the first ever mention 06:23
But that's been lost on anyone who joined the conversation since
06:33 viklund_ joined
dalek rtcl: r460 | coke++ | trunk/docs/spectest- (2 files):
update spectest numbers
 06:35
chromatic I updated that post to clarify, Alias. Thanks for the suggestion. 07:07
Tene Coke: like 20 minutes or something, I think. 07:09
07:21 donaldh joined
dalek rrot: r39462 | cotto++ | branches/pmc_pct/compilers/pmcc (2 files):
[pmcc] move vtable dump reading code into pmcc.pir, which is a much better place than in the actions
 07:23
rrot: r39463 | cotto++ | branches/pmc_pct/config/gen/makefiles/pmcc.in:
[makefile] add a generated file to pmcc's make clean and reorder existing files
07:41 Zak joined
chromatic This should scare you. 07:58
dalek rrot: r39464 | chromatic++ | trunk/compilers/imcc/reg_alloc.c:
[IMCC] Plugged a memory leak in the register allocator when counting the number

terrible, I managed to knock one at least one exponent off of it, making it run slightly faster (especially for complex compilation units) and leak less memory.		 07:59
08:02 clinton joined
dalek rrot: r39465 | chromatic++ | trunk/src/ops/io.ops:
[ops] Replaced expensive Parrot_sprintf_c() call in print_p_i op with a call to
 08:03
cotto It's nice that candidates for that optimization are marked by INTVAL_FMT. 08:05
chromatic Very easy to find.
08:08 tetragon joined 08:17 payload joined
chromatic Hm, that cleaned up a lot of Rakudo's leaking too. 08:24
dalek rrot: r39466 | chromatic++ | trunk/src/pmc/coroutine.pmc:
[PMC] Plugged a memory leak in the Coroutine PMC, where it didn't set a

contexts if their ref counts are negative to avoid crashes, but this meant that when it was time to recycle this context, it didn't get reclaimed.		 08:26
08:29 barney joined 08:35 payload joined
cotto a class of bugs soon to be eliminated 08:35
chromatic We still leak contexts, but I think I've plugged another IMCC leak. 08:36
dalek rrot: r39467 | cotto++ | branches/pmc_pct/compilers/pmcc (5 files):
[pmcc] store vtable info as a member of the emitter and don't generate VTABLE function prototypes in the header, plus a few minor fixes
 08:42
Alias chromatic: BTW, I had a discussion with Larry a couple of years back about modules and Perl 6 08:43
chromatic Me too!
Alias chromatic: I believe the idea was to define the modules in "layers"
So Layer 1 are the modules you need to load modules
Layer 2 are the modules you need build modules
Layer 3 are the modules you need to run a CPAN client
chromatic That sounds right.
Alias Layer 4 is the CPAN...
And then you define a "Standard Library" over the top of that, and require it for distribution certification 08:44
chromatic I have the impression that @Larry[0] isn't sure about a "Standard Library" on top of that. 08:45
Alias Right, that last bit is mostly me :)
chromatic Certainly all(@Larry) isn't.
dalek rrot: r39468 | chromatic++ | trunk/compilers/imcc (2 files):
[IMCC] Plugged a memory leak of the C strings used to keep track of the names
08:46 tetragon joined
Alias I have some plans for Chocolate (now probably to be called "Strawberry Professional" due to inevitable brand inertia) 08:46
chromatic I think that's the way to go.
Alias They come pretty close to being a "Standard Library (Desktop)"
chromatic You have quarterly releases, right? 08:47
Or is it biannual?
Alias quarterly 08:48
chromatic Do you have magic powers?
Alias Lest I be used as part of an argument I disagree with in future, I'd like to note that the ONLY reason I can pull that off is that I don't actually create any functionality. I just package up whatever is already release by other people :)
Half my releases contain no new Strawberry features, just updated CPAN modules and tiny config tweaks 08:49
The quarterly release is as much a marketing tool as anything
chromatic Sort of like p5p does for dual-lived modules.
Alias It makes me look more magic than I am 08:50
chromatic Sure, it makes your project look alive and well-maintained.
Alias And it reminds me to update my three-page website with something new so I don't look stale
right
chromatic That tends to attract contributions. 08:51
Alias Not really
For for me at least
I've had one contributor in 2 years
But then I'm just a packager
chromatic Don't you get bug reports?
Alias Mostly wrong ones 08:52
But sure, I get a handful
chromatic I define "contribution" more broadly than you might expect.
dalek rrot: r39469 | chromatic++ | trunk/compilers/imcc (2 files):
[IMCC] Plugged a memory leak of lexical variable names used with the .lex
purl i think directive is divisible by 2, hence it is not prime.
rrot: r39470 | barney++ | trunk/tools/dev/fetch_languages.pl:
[tools] Put 'languages' into a variable.
Alias I guess I define contributor more tightly than contribution
Non-symmetrically
Anyways 08:53
chromatic I see no reason to, but as long as we know the other person doesn't speak English, we can still commuincate.
Alias Indeed (Re: "stable")
chromatic And look, I'm fixing memory leaks right now. 08:54
Releases get downloaded.
People use them.
Alias Sure thing :)
chromatic People report bugs.
I can fix reported bugs.
We make a new release, people get bugfixes. 08:55
It's a virtuous cycle.
Alias Do you have any leak tests?
(... now?)
chromatic Not really. They're difficult to write reliably.
Alias Have you seen the SQLite test suite? 08:56
chromatic I haven't.
Alias They've been particularly hardcore about testing
They claim 45million lines of test code
chromatic How much of that is fixture data?
Alias No idea 08:57
And it's in a hodge-podge of languages, some of which I assume are auto-converted to others
And the count may include the entire codebase of TCL
Hard to say
08:57 masak joined
Alias But they are probably a good project to investigate for clues 08:58
chromatic We could set up a target to run selected known-good tests through Valgrind, but it'd take hours to get decent coverage.
Alias I do this now...
chromatic We could play tricks with a debugging malloc and ld.so and get answers faster perhaps.
... but that doesn't give good diagnostics. 08:59
Alias The fuzz test for PPI runs for several orders of magnitude longer under AUTOMATED_TESTING
Just make the tests run a really cut down version of themselves except under RELEASE_TESTING or something
cotto It'll get more feasible as we decrease the amount of C in the codebase.
Alias The tests you do before release that consume 20 hours of CPU
chromatic I don't want tests that consume 20 hours of CPU. 09:00
Alias TBH, that demo case I posted to the bug tracker was almost identical to my problem case
Then you run it for 5 hours across 4 cpus
Again, take a look at how SQLite does it 09:01
chromatic If we had a compilation farm that could give us results in 60 minutes, maybe.
Alias The ramp up the testing standards as it moves closer to a release
The final hardcore heavy tests never get run except on the final validation run for a prod release 09:02
Strawberry does something similar, it always runs all tests on all variations, from scratch
Building a strawberry release takes 10-25 hours
But I only do it once or twice a quarter
10-15 09:03
purl -5
chromatic I want to be able to build a release in an hour.
That's my constraint.
Alias Even if it prevents certain types of testing?
chromatic It doesn't prevent them. 09:05
I don't want that process overhead getting in the way of producing releases.
Barring the occasional obsessive nut like you or me, I find that people avoid work that's tedious, difficult, time-consuming, or involved. 09:08
Alias It doesn't have to get "in the way" 09:09
There's nothing to stop you rolling a release without running through full QA 09:10
It's just that you'd want to provide certainty once people start relying on you
How do I know that parrot will ever run my program (which takes longer than an hour) if the parrot development process itself never runs anything longer 09:11
And yes, eventually this results in diminishing returns
chromatic That's just it. I don't believe we can provide that certainty. 09:12
Alias Then parrot is just an academic exercise
chromatic At some point all of our stochastic testing is insufficient. 09:13
Alias Testing is not a matter of absolutes
chromatic Yes, that's what I'm saying.
I believe it's infeasible to test Parrot to the degree that we can offer certainty for anything other than a few specific use cases. 09:14
Alias If testing can consume between 1 second and 1 year of CPU to validate the safety of a release, why pick one hour as the limit
You're going to need to test to the standards of the uses to which you advocate Parrot being adopted for 09:15
chromatic Nothing succeeds like success.
Nothing tests your use cases like your use cases.
Alias Except tests... 09:16
chromatic If only users could contribute bug reports and test cases....
Alias What happens when you hit an hour 09:17
Will you reject test cases?
chromatic We find a way to speed them up.
Alias And if you can't?
chromatic We reevaluate the value of the slow tests. 09:18
Alias Speed suffers from diminishing returns, testing increases incrementally
chromatic That's why the coding standards tests don't run by default now.
Alias Do you run them before releasing?
chromatic Yes.
Alias But you'll stop once the incremental additional time goes over an hour? 09:19
chromatic I'll consider it.
We may move to a weekly report or a compile farm or something similar.
If it costs us two minutes to discover that a piece of Perl 5 code uses a bareword filehandle in violation of a Perl::Critic policy, I can argue that we have better tests for those 120 CPU seconds. 09:20
Alias Sure, but what if that test is watching for leaks 09:21
Or something less obviously secondary
chromatic If we have tests watching for leaks, I don't want to run them only right before a release.
Anyone who messes with memory management a day or two before a release gets a handslap. 09:22
Alias That seems in conflict with the hour thing
You know as well as I nobody ever thinks that are impacting something important when they do the minor commit that breaks something they didn't expect 09:23
chromatic Sure, I broke Rakudo in 0.9.0 fixing a coding standards test.
That's why there's an 0.9.0.1 on the CPAN.
It didn't take an hour to release that.
Alias That only has to happen a few times before it gets embarrasing 09:24
And people start asking why they should bother downloading instead of just waiting a few days to make sure you didn't release a broken version
chromatic Sure, that's why we have a documented release process.
Alias What does that mean? 09:25
purl You're a nut! You're crazy in the coconut!
chromatic That means that I can point you to the appropriate documentation and you can make a release any time you want.
You know exactly what it takes and you know how to ensure that the release is of appropriate quality. 09:26
Alias And that will say the same thing as you just said?
That you don't have to run all the tests before releasing?
chromatic That's not what I said. 09:27
Alias So you do run all tests, even the heavy tests, even if they take longer than an hour? 09:28
chromatic They don't take an hour. Yet.
dalek rrot: r39471 | cotto++ | branches/pmc_pct/compilers/vtdumper (5 files):
[vtdumper] s/argument/parameter/ and add some methods to make this code similar to what pmcc expects from vtable_info
Alias Clearly, I've never gotten a Perl 6 script running for more than a minute in any case
chromatic Perhaps you're thinking of the Rakudo test suite, which is a separate discussion on a separate channel. 09:30
Alias I'm aware
What's the longest any parrot process has run for?
chromatic I don't know. Jeff Horwitz might be the person to ask. 09:31
I don't know how often some of the IRC bots reset either.
I suspect what you're getting at is what I would call "exploratory testing". 09:37
It's valuable, but I'm not going to make it part of the release process (as far as my opinion matters). 09:38
We can isolate bugs through good exploratory testing and create tests for them as part of our automated testing, which is part of the release process as well as the development process.
This is, in fact, the most effective way I know to develop software. 09:39
10:00 mj41 joined 10:12 payload joined 10:13 gaz joined 10:33 payload joined
dalek kudo: fa4198c | masak++ | src/builtins/io.pir:
[src/builtins/io.pir] removed 'prompt' undef warning

was issued. Fixed this.		 10:37
10:53 payload joined 10:56 payload1 joined 11:11 payload joined 11:23 donaldh joined 11:56 ruoso joined 12:12 bacek joined 12:21 payload joined 12:46 Steve_H joined 13:20 gryphon joined 13:48 sekimura joined 13:49 Whiteknight joined 13:50 sekimura_ joined, uniejo joined 13:52 sekimura joined 13:56 sekimura joined 14:00 sekimura joined 14:02 sekimura joined 14:06 Steve_H_ joined
dalek TT #748 created by coke++: memory leak in IMCC 14:18
rtcl: r461 | coke++ | wiki/MemoryLeaks.wiki:
Created wiki page through web user interface.
 14:34
14:35 whoppix joined
dalek rtcl: r462 | coke++ | wiki/MemoryLeaks.wiki:
add a recent run.
 14:39
14:40 snarkyboojum joined 14:47 mberends joined 14:49 kj joined
dalek rtcl: r463 | coke++ | wiki/MemoryLeaks.wiki:
The web site doesn't seem to like rendering this in the wiki. Will move it
 14:53
14:53 snarkyboojum joined 14:59 Theory joined
dalek rrot: r39472 | whiteknight++ | trunk (81 files):
[io_rewiring] Merge the io_rewiring branch into trunk.
 15:08
15:10 kj joined 15:20 donaldh joined 15:22 viklund_ joined, bacek joined
dalek rrot: r39473 | whiteknight++ | trunk/NEWS:
[NEWS] Create the new NEWS section for 1.3.0, and add some information about the IO refactors
 15:28
15:35 jhorwitz joined
Whiteknight purl msg infinoid that error last night magically went away again. I did a fresh checkout of trunk and merged in the branch and the error was just gone. So, I merged branch into trunk and cross my fingers 15:38
purl Message for infinoid stored.
jhorwitz pmichaud: where do we stand w/ interpolated namespaces? just tried on the latest rakudo and got no love. 15:47
pmichaud last time I talked to the guy in charge (me), it still wasn't done. I think various forms of physical pain may be in order.
15:48 japhb joined
pmichaud although there _have_ been lots of type-related changes that have gone in that continually make me revise how it might work. Another set is going in today :-| 15:48
jhorwitz will bring a wet noodle to YAPC
pmichaud good idea. 15:49
purl pmichaud: Good Idea: Feeding stray kittens in the park. Bad Idea: Feeding stray kittens in the park to a bear.
jonathan Better than the bear eating you... 15:51
pmichaud: What type related changes are going in today?
pmichaud fulltypename --> typename
(assuming you did get to it today -- no real rush.)
jonathan oh, you decided to do that one?
Oh, you're assuming I'm doing it :-)
pmichaud (just another example of a change that would affect namespace interpolation) 15:52
jonathan It would?
pmichaud slightly
the parse gets affected a bit.
jonathan Ah, I didn't mean to give the impression I was going to do it today but if it's helpful to you if I do...
pmichaud oh. It's not at all critical.
jonathan (Was more working on fixing meta-class methods up.)
pmichaud meta-class ++
anyway, it's an easy change when we get to it. 15:53
jonathan Yes, I'd figured that, and figured I'd do it if a need came up. :-)
15:58 Andy joined 15:59 zostay joined 16:02 DanielC joined
DanielC Hi. Can you use numbers in a function name? e.g. .sub 'fletcher32' 16:16
I just started learning PIR. I'm roughly at the hello-world level.
16:17 NotFound joined
kj DanielC: yes, as long as the name starts with an alpha character 16:22
DanielC thanks
kj also, if you use a quoted string, i think it can even start with a number
easy to check out :-)
16:22 NotFound joined
NotFound hi 16:23
16:28 Psyche^ joined 16:32 payload joined
NotFound Debian amd64 all test pass. Good news, or someone deactivated the test that failed on 64? 16:39
mj41 seems like merging io fixed these tt.ro.vutbr.cz/report/pr-Parrot/do?...un-3835=on 16:47
16:48 darbelo joined
NotFound Good :) 16:49
mj41 but t/dynoplibs/myops.t is weird one 16:51
NotFound Is passing here 16:52
mj41 yes, but can start failing tomorrow, tt.ro.vutbr.cz/report/pr-Parrot/do?...un-1839=on 16:57
Whiteknight what test was failing on debian x674? 17:03
x64?
purl x64 is VS Professional and higher
17:06 masak joined
NotFound Whiteknight: the dynop alarm test failed for me all times I tried in the last months, for example 17:07
17:07 viklund_ joined
Whiteknight hmmm, that's weird 17:07
NotFound Not only in debian, in several linux 64 17:08
Now I have a new machine, I hope I can put sone eye on that.
jonathan wishes he could smack whoever decided that MultiSub in Parrot should inherit from ResizablePMCArray. 17:09
Tene purl: parrotsketch?
purl parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
Tene Tue Jun 9 17:10:18 UTC 2009 17:10
Whiteknight MultiSub inherits from RPA? For serious?
NotFound Users, Take Care ?
jonathan Whiteknight: Yes for serious.
17:11 coke_ joined
Tene Coke: you asked about spectest speed last night. I just ran a rakudo spectest. 'time' reports 19m8.301s 17:11
Whiteknight that's a ridiculous abuse of inheritance.
CokeZero Tene: danke.
Tene CokeZero: why?
CokeZero because it takes an insane amount of time to run partcl's. 17:12
17:12 Theory joined
jonathan Whiteknight: Damm right it is. 17:12
Tene ah
Whiteknight I merged in the IO branch this morning, so times *should* be down for most things
CokeZero code.google.com/p/partcl/source/bro...ogress.csv (last run took 4187s)
4187 / 60 ?
purl, 4187 / 60 ?
purl cokezero: no idea
CokeZero 4187 / 60
purl 69.7833333333333
Tene Nice. 17:13
CokeZero we've gotten a lot faster since parrot 0.8.1, but still.
masak Tene: do you think the new HLL is Rakudo might be why Rakudo suddenly doesn't return with 1 as the exit code on 'exit 1'? 17:14
Tene Whiteknight: what's next on your master plan after this IO branch?
masak s/is/in/
Tene masak: I'd be very surprised.
CokeZero masak: I doubt it. 17:15
Whiteknight Tene: More IO cleanups mostly. Once the pcc_rewiring branch lands (if ever) I'm on to GCable Contexts
Otherwise, AIO after 1.3.0 comes out
CokeZero tcl also used to exit properly but no longer does.
anyone here using ICU with strawberry perl? 17:16
(I just grabbed a newish ICU for win32, it doesn't come with icu-config) 17:17
oooh. chromatic's recent memory leak fixes were big. 17:18
masak Tene, CokeZero: ok, these are my observations: line 310 in perl6.pir in Rakudo, 'exit 1', quits Rakudo with exit code 0. line 125 in examples/pir/uniq.pir in Parrot, 'exit 1', quits with exit code 1. 17:19
which hypothesis could explain that?
CokeZero masak: rakudo has a top level exception handler.
to catch "everything but exit exceptions"
Tene masak: try disabling the EH
masak Tene: sure, how?
purl sure, how are you going to enforce this on the tcp level?
Tene masak: comment out lines 207 and 209 in perl6.pir 17:20
CokeZero msg chromatic - at least one of the files that was running out of memory on feather just completed with your recent memory leak plugs.
purl Message for chromatic stored.
masak Tene: ok. 17:21
CokeZero parrotsketch?
purl rumour has it parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
CokeZero clock?
purl CokeZero: LAX: Tue 10:21am PDT / CHI: Tue 12:21pm CDT / NYC: Tue 1:21pm EDT / LON: Tue 6:21pm BST / BER: Tue 7:21pm CEST / IND: Tue 10:51pm IST / TOK: Wed 2:21am JST / SYD: Wed 3:21am EST /
CokeZero
17:24 barney joined
masak Tene: yep. that did it. return code is now 1. what does that mean, in terms of fixing the problem? 17:29
jonathan masak: Ah, hmm 17:31
exit:
pop_eh
exit 0
It seems the same handler stays active and re-catches the exit exception through by exit 1 17:32
Try a pop_eh after the trap_errors: line.
But I suspect that the code I just pasted needs to look in the exception for the correct exit code to use also. 17:34
masak is lost
but it seems the problem is well understood now, which makes me happy. 17:35
CokeZero jonathan: can you proffer me a patch for code.google.com/p/partcl/source/bro...sh.pir#165 too? =-)
jonathan CokeZero: You getting a hang or something? 17:37
CokeZero: And what is .catch() - a macro?
CokeZero yes.
jonathan Which is that yes too? :-)
CokeZero if I try to exit tcl from the REPL, I stay in the loop.
[exit] also doesn't exit.
and yes, it's a macro.
code.google.com/p/partcl/source/bro...ros.pir#34 17:38
jonathan oh :-(
I was going to say "you're missing a pop_eh"
But your macro does it.
CokeZero ayup.
this used to work back around 0.9 or so. =-) 17:39
jonathan That rethrow trick looks sensible, I'd like to steal it...apart from you say it doesn't work so hmm. :-/
CokeZero eeet used to! =-) 17:42
(the only reason I have macros is because I was sick of rewriting syntax.)
17:44 chromatic joined
chromatic Hm, in the t/pmc/undef.t problem, the class being marked looks invalid. 17:44
cotto #ps in 35 17:55
CokeZero curses the internets, as he now has a box heading his way from amazon.com 18:00
cotto The internets have been suitably cursed. I'll blame you when something goes wrong. 18:03
CokeZero chromatic: only getting a few more files not running out of memory, but most of the ones still failing at least fot further. 18:05
chromatic Yeah, that context leak is the big one.
Though if you compile a lot of PIR, the IMCC leaks can add up.
CokeZero I compile a LOT of pir. =-) 18:06
chromatic The IMCC leaks are usually *really* easy to fix if you can trace it down to a small snippet of PIR.
CokeZero any procedure invocation or expression invocation will do it.
chromatic I fixed a few last night just by reading 10 lines of PIR and saying "Oh, I bet it's THAT!" and confirming it.
CokeZero chromatic: so noted. I'll see if I can duplicate it.
pmichaud #ps in 24. I may be late/distracted during #ps, so I'm pre-pasting my report. 18:07
cotto That's prepasterous.
CokeZero *groan* 18:08
chromatic The assign opcode is the problem. 18:11
... which calls set_pmc in Undef. 18:12
betcha it's pmc_reuse_by_class.
Tene masak: it means there's a problem with the exception handler. 18:13
masak Tene: ok.
any help appreciated.
Tene masak: I can't work on it right now, as I'm behind at work. I'll try to get to it tonight. 18:14
(sorry)
starting to pack up my house tonight. 18:15
masak Tene: that's still good news, by me. thanks! 18:16
jonathan oh gah I forgot about doing dinner :-/
jonathan will go after giving his #ps report 18:20
18:20 allison joined
dalek TT #5 closed by coke++: partcl's [puts hi] exposes memory leaks in r33137 18:21
kudo: b677d60 | masak++ | src/ (2 files):
moved 'prompt' into the setting
Tene I have my ps report ready ahead of time! 18:27
I think I'm missing a few things, and I don't know how much of it was actually in the past week...
It's all been since the last time I reported, though. 18:28
cotto pmichaud, ping
pmichaud cotto: pong
cotto What would it take to make a PAST iterable?
18:28 darbelo joined
Whiteknight pmc_reuse_by_class is b0rked? 18:29
cotto specifically a PAST::Block
Whiteknight #ps in 1
chromatic I commented out everything else in t/pmc/undef.t and ran it through the gcdebug core. 18:30
If I comment out the assign op, it's fine.
pmichaud cotto: it's already iterable (more)
chromatic It's either pmc_reuse_by_class or Parrot_oo_clone_object.
pmichaud cotto: just call .'iterator'() on it, and you get back an iterator. 18:31
cotto Great! Thanks.
pmichaud we could potentially make that a vtable method, too, I suppose.
cotto That'd be more intuitive. 18:32
18:32 particle1 joined
Whiteknight chromatic: When did that t/pmc/undef.t problem appear? 18:34
chromatic After the merge.
I suspect it was lying in wait though. 18:35
jonathan feels hard done by in the sort order stakes 18:37
chromatic I don't recognize the letter J. I'm like mainland and Taiwan.
jonathan :-P 18:38
jonathan can go for dinner now :-)
cotto appointment & 18:39
Whiteknight chromatic: I saw that failure before the branch merged, but I did a fresh checkout and it disappeared 18:48
so I'm sure it's some weird transient thing if it's appeared again now
chromatic Run just set_undef_to_object in t/pmc/undef.t and you'll trigger it with the gcdebug core. 18:49
Very reproducable.
CokeZero chromatic++ # memleak fixes. 18:50
Whiteknight good, reproducible is good 18:51
chromatic Not according to my neighbors. They passed around a petition.
TimToady they finally got tired of those wild parties, eh? 18:53
Tene Whiteknight: Rakudo's socket tests are now failing after the IO merge. 18:55
Method 'close' not found for invocant of class 'Socket'
CokeZero I thought rakudo was tested pre-merge-back? 18:56
dalek rtcl: r464 | coke++ | wiki/SpecTestStatus.wiki:
Recent memleak fixes in parrot were make-or-break for these tests.
Whiteknight Rakudo was tested before the merge
Tene: I hate to ask, but did you realclean?
Tene I realcleaned everything. 18:57
Whiteknight damnit. 18:59
Tene Whiteknight: however, spectest time did drop from 20m to 14m, though 19:00
Whiteknight Okay, so two questons:
1) How did we miss this failure prior to the merge and
2) do you have a small test case that demonstrates the problem? 19:01
Tene Whiteknight: looks like it just reported the message in the spectest output, but didn't report as a failure in the test summary
Whiteknight Tene: Okay, that would explain it
so I assume somebody is calling "close socket_pmc" and it's throwing an error message? 19:02
Tene t/spec/S32-io/IO-Socket-INET.t
looks like it's $client.close();
mberends Whiteknight, Tene, that was me bumbling around. Any corrections gratefully received ;) 19:05
19:05 clinton left
NotFound I don't see a close method in the socket pmc. 19:05
19:05 clinton joined
Whiteknight how does an open socket become closed then? 19:06
chromatic Velociraptors.
Whiteknight damnit, the velociraptors didn't make it into the branch
NotFound goto close;
TimToady whew, that was a close call... 19:07
Whiteknight the socket PMC doesn't look like it contains any functionality to terminate an existing connection 19:08
no close() method, no disconnect() method, nothing
Tene Whiteknight: so probably not caused by IO branch. sorry. :)
Whiteknight it's okay, it's an issue that needs resolving in any case.
will be addressed in the next IO branch 19:09
NotFound We are on line with the modern trend of 'always conneced'
Parrot_io_close defaults to PCCINVOKE 'close' 19:12
allison in general, the opcodes shouldn't be called on sockets at all 19:13
sockets use only methods
(but then, if sockets happened to have a method called 'close' it wouldn't really matter) 19:14
NotFound Looks like currently there is no way, method or not, to close them. 19:15
Whiteknight right, I shouldn't have said opcode
allison NotFound: aye, that needs to be fixed
NotFound Well, at least destroy does it.
19:16 kj joined
mberends good people, on the subject of sockets, could you perhaps look into this little test case that hangs after opening a socket? gitorious.org/net-smtp/mainline 19:18
Tene that's not a link to a useful file. 19:19
:P
Whiteknight I think a socket for some operations can be made to work with existing IO opcodes: open, close, read, print, etc 19:20
19:21 donaldh joined
Whiteknight I don't think they need any specialized opcodes though 19:21
Tene argh what's all this proto stuff?
Whiteknight like open "localhost", "L" could open a listening socket, while open "localhost", "C" could open a client socket, etc 19:22
Tene Hmm.
Whiteknight print socket, string could write data to the socket, string = read socket could read, etc 19:24
of course, these would just use basic options (TCP/IP?) so if you wanted more control you would use the methods directly.
Anyway, I'll muse about this stuff more later. I'm out for now. 19:26
chromatic src/io/api.c:123: warning: ‘filehandle’ may be used uninitialized in this function 19:28
NotFound Looks like the diagnostic is right. The last else does not set it 19:29
nopaste "Coke" at 65.91.151.194 pasted "for chromatic: leaker.pir" (20 lines) at nopaste.snit.ch/16839 19:31
chromatic Thanks, that should be relatively easy. 19:34
jhorwitz re: the PDD10 question in #ps, we should rebuild it from embed.pod (kind of backwards, but i rewrote embed.pod last year to reflect reality) 19:42
cotto chromatic, where's your attack plan for profiling? 19:44
CokeZero chromatic: was that thanks to me? 19:45
nopaste "chromatic" at 72.90.115.31 pasted "Deliverables for Profiling Core (cotto)" (21 lines) at nopaste.snit.ch/16840
chromatic CokeZero, yes. 19:46
NotFound jhorwitz: The reality that if reflected the last time I looked at it was that embedding sucks :( 19:47
jhorwitz it's actually not bad at all
CokeZero arigato, chromatic-san
jhorwitz NotFound: the hardest part is not writing the code, but figuring out the right compiler/ilnker flags from the parrot_config mess 19:48
CokeZero wow. software that makes me want to upgrade my os. 19:50
(chrome is OSX 10.5 only.)
NotFound jhorwitz: strange, that was the easy part for me ;)
jhorwitz: look at examples/embed/Makefile 19:51
dalek tracwiki: v17 | cotto++ | ParrotQuotes 19:52
tracwiki: velociraptors
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
jhorwitz yeah, it *can* be easy. but even after a recent svn up, my linker flags suddenly moved from libparrot_ldflags to libparrot_linkflags
(or something similar, i forget the exact name)
CokeZero jhorwitz: in our defense, adoughera cleaned up that stuff quite a bit. :|
but I feel your pain, living outside the core sucks. =-) 19:53
jhorwitz CokeZero: yep, cleaning is good. but the rug certainly can be pulled out from under you in this place. ;-)
NotFound The problem I see is that current usages of embedding just jump over the problems by including all parrot headers they want and using all available functions. That way we never knows what things the external interface needs. 19:55
chromatic Exactly. 19:56
jhorwitz agreed
the headers have always been a problem in that regard 19:57
NotFound In fact I added seevral functions after discovering that it was impossible to write even a minimal example without breaking the rules.
jhorwitz added several functions for what? 19:58
NotFound To be able to put something that works in t/src/embed.t 19:59
jhorwitz looks at that file...been a long time
NotFound All code in that file were examples of what to NOT do. 20:00
dalek rrot: r39474 | chromatic++ | trunk/compilers/imcc/pcc.c:
[IMCC] Added braces to avoid a compiler warning about an ambiguous else.
rrot: r39475 | chromatic++ | trunk/src/pmc/undef.pmc:
[PMC] Fixed Undef morph to Object code in the Undef PMC to avoid odd mark()

is ideal, but it's an improvement.
rrot: r39476 | chromatic++ | trunk/src (2 files):
[src] Tidied code; no functional changes.
jhorwitz NotFound: it starts off well. pretty clean. then gets progressively uglier. 20:01
i know mod_parrot doesn't use a single internal datatype or unexported function, so it's possible to keep things clean.
NotFound jhorwitz: I let the previous content, skipping all.
chromatic Wow, CokeZero. That's a very leaky example. 20:02
Of course, if you put 'emit' in quotes, it's better.
CokeZero ... it shouldn't even allow it without quotes. whoops! 20:03
NotFound jhorwitz: we have lots of things exported that are not intended for external usage
jhorwitz understood.
purl understood. are you on schedule?
jhorwitz smacks purl
purl Oh baby, you do it so *good*!
chromatic It doesn't, but IMCC doesn't clean up allocated memory when it exits due to a parse failure.
jhorwitz purl: you know it
purl jhorwitz: excuse me?
CokeZero chromatic: will try to find you a better leaker.
NotFound jhorwitz: did you see something ugly before the '# Old tests, skipped all' ? 20:05
jhorwitz didn't see that line. looking...
NotFound Other than the lack of the last 'l' in that comment ;)
jhorwitz no, looks clean 20:06
NotFound Good :)
jhorwitz was able to grok it pretty quickly -- reads like mod_parrot. :) 20:07
NotFound So at least now we have some clean examples. 20:08
jhorwitz yes! and i used embed.pod to document the functions i was using in mod_parrot, most of which are also in those examples.
so i guess the question is, what do we want to see from PDD10? 20:10
NotFound jhorwitz: Maybe will be better to unify extend.pod and embed.pod
jhorwitz NotFound: yes, allison and i agreed on that last year.
make extend.pod disappear
ttbot chromatic: Parrot trunk/ r39476 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/30435.txt
20:11 gryphon joined
NotFound jhorwitz: I think the PDD for embedding must be very short, and refer to the extend pdd for almost all. 20:11
jhorwitz i think we also agreed to unify those PDDs
NotFound Even better.
jhorwitz they're just not separate entities
and then, maybe one day, we'll have one include file too. ;-) 20:12
NotFound Just a short paragraph about how to embed must be enough.
Or for people that really dislike the separation of concepts, on how to start a parrot interpreter from C main ;) 20:13
But if we all agree on unify those docs, I think what must be done now is to unify them now. 20:14
CokeZero chromatic: here's an interesting leak tester; run some tcl.pbc with parrot -D60; leaktest all the resulting EVAL files. 20:15
doing so now, hoping to find a culprit. 20:16
jhorwitz yep. and the pdd10 ticket for the 1.3 milestone implies unification.
NotFound That implies also pdd renumbering? 20:17
jhorwitz or maybe just deprecation
*sigh* i guess i have some work to do this weekend. 20:18
NotFound jhorwitz: Have you looked at examples/embed/lorito.c ? 20:20
CokeZero chromatic: bah. turns out that those aren't really runnable in isolation anyway. ah well.
jhorwitz hm, doesn't sound familiar
NotFound jhorwitz: I wrote it some months ago.
chromatic CokeZero, are the top culprits in IMCC? 20:21
CokeZero chromatic: let me try an actual tcl file and see.
jhorwitz NotFound: looks pretty straightforward 20:22
NotFound jhorwitz: that was the attempt on writing something that used only emebed.h and extend.h that showed me the need to add some functions to the external interface. Don't remember now what were. 20:25
jhorwitz NotFound: i maybe saw one function in there that isn't documented in embed.pod (and should be)
that's really encouraging
NotFound We're starting to have a usable interface, just need to follow that path and document it. 20:26
jhorwitz yes, that was the point of me keeping embed.pod up to date
so now we move onto the PDD and profit 20:27
NotFound It helped to figure some flaws, at least ;)
jhorwitz just a few. ;-)
nopaste "coke" at 193.200.132.135 pasted "leak output from examples/power.tcl" (4795 lines) at nopaste.snit.ch/16841
NotFound I'm not blaming, the general scheme was not bad, just lacked a few important functions. 20:28
chromatic Okay, now we just have to trim that PIR output down to the point where we can identify which part of the grammar causes a leak CokeZero. 20:29
jhorwitz i wouldn't even know where to begin blaming anyway. :)
i just documented the fallout. :)
CokeZero chromatic: trac.parrot.org/parrot/ticket/748 seems to be the biggest leaker. 20:31
(which is just the leak output, not the pir)
cotto msg Whiteknight doc.cat-v.org/inferno/concurrent_gc/ looks like it might be of interest, should you ever have the time to read it 20:32
purl Message for whiteknight stored.
chromatic CokeZero, I need to be able to say "Oh, this file has :named( 'foo' ) in it three times and leaks 18 bytes." 20:33
Then it's a trivial fix.
Do you have a lot of .macros?
CokeZero yes. 20:35
chromatic That'll do it. 20:36
CokeZero since I'm not using PCT, narrowing down the generated PIR is a pita. working on it.
dalek rrot: r39477 | NotFound++ | trunk/src/pmc/socket.pmc:
[pmc] add close method to Socket
 20:46
NotFound velociraptors-- 20:47
CokeZero acceloraptors! 20:48
mugwump how do you differentiate those from velociraptors? 20:50
NotFound attrs - PMC_data(SELF); ? 20:51
udef.pmc:54
mugwump oh, dv/dt
chromatic Hm, that should be =.
NotFound mugwump: you don't care, you just run 20:52
ttbot NotFound: Parrot trunk/ r39477 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/30518.txt
NotFound ttbot: looks like the same problem 20:53
CokeZero mugwump: that's a horrible pun. it puts me in an awkward position. 20:54
dalek rrot: r39478 | chromatic++ | trunk/compilers/imcc (5 files):
[IMCC] Plugged a memory leak of (generated) labels in IMCC.
 21:00
rrot: r39479 | chromatic++ | trunk/src/pmc/undef.pmc:
[PMC] Fixed a stupid typo which makes picky compilers run home to mommy. This
 21:03
21:04 bacek joined
NotFound My g++ feels hurt because of that comment 21:05
ttbot chromatic: Parrot trunk/ r39478 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/30562.txt
chromatic g++ can stay. It's MSVC that goes.
NotFound Several commits with all test passing in linux amd64. Looks some recent change killed some hidden problem. 21:13
Good thing that this happens the first time I have a 64 bit OS at home :) 21:14
dalek kudo: 1ff28a3 | jnthn++ | src/ (7 files):
Lots of fixes to get method introspection mostly working. Not 100% there yet, but a whole load better than it was. Also prevents us getting quite so explodely when we're putting MultiSubs into arrays (Parrot's MultiSub inheriting from RPA is srsly stupid), and makes .name work on Multis too.
 21:15
kudo: c7d4dad | jnthn++ | t/spectest.data:
Add S12-introspection/methods.t to spectest.data.
kudo: 5af9cf3 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
GeJ Good morning everyone 21:21
CokeZero pmichaud: spoke briefly to someone on the #tcl channel. basically, "yah, it probably shouuld throw an error, but..." 21:22
but I have a fallback plan.
21:24 Theory joined 21:48 kj left
pmichaud CokeZero: surely they could come up with a different test for that 21:51
i.e., one that uses a valid unicode char. I'm sure there are plenty to choose from... ;-) 21:52
dalek rrot: r39480 | fperrad++ | trunk/src/pmc/socket.pmc:
[codingstd] fix C parentheses
 21:53
21:58 Whiteknight joined 22:00 jan joined 22:12 jan joined
dalek rrot: r39481 | bacek++ | branches/pmc_i_ops (7 files):
[pmc] Replace SELF.clone with pmc_new/set combo
 22:17
bacek good morning #parrot 22:24
dalek kudo: f80f12c | jnthn++ | src/parrot/misc.pir:
Make .perl on a Parrot MultiSub not explode when we take .perl of a list containing it (yes, this patch sucks some...plan to improve .perl a bit on routines soon, though, and this is better than exploding).
kudo: 86aeafb | jnthn++ | src/parrot/ClassHOW.pir:
Fix :tree support for .^methods.
bacek pmichaud: around?
pmichaud here, briefly 22:25
bacek main argue about pmc_i_ops branch is about using VTABLE_clone or changing semantic to use i_op?
(I replaced VTABLE_clone to new/set combo in r39481) 22:26
22:26 ruoso joined
pmichaud vtable_clone was the one that caused immediate concern. I'm still not sure about the i_op semantic. 22:26
it doesn't feel right to me to think that we can/should define everything in terms of i_op
bacek But it's just math. And reduces amount of code to maintain 22:27
dalek rrot: r39482 | bacek++ | branches/pmc_i_ops (87 files):
Sync branch with trunk.
pmichaud I'm not sure it's always "just math".
bacek hm... How that? 22:28
pmichaud I can imagine that there might be scenarios where the inplace math is not the right thing to do. 22:29
22:29 contingencyplan joined
bacek But I use inplace for core pmcs only. With predefined semantic. 22:30
pmichaud if you're limiting it to core pmcs, but not affecting the ability of others pmcs to do something different, I have less concern.
bacek It's just core ops.
pmichaud ops, or pmcs?
there's a difference.
bacek pmcs.
It's still early morning there :) 22:31
jonathan s/there/here/ ;-)
pmichaud It's definitely not early morning here. :-)
bacek Derived pmcs can provide any semantic for "add"/"i_add"
jonathan hands bacek some good strong кофе
bacek accepting coffee swearing in second language 22:32
22:33 rg1 joined
bacek pmichaud: Is there other objections about branch assuming that I already changed VTABLE_clone to pmc_new/set and it affects only core pmcs? 22:34
pmichaud I'm looking now. But I'm not sure I should be the only one reviewing them. 22:35
I'd want to get allison++ approval before merging to trunk, since she's the one who most recently worked on this stuff. 22:36
bacek Ok, I'll write new message to parrot-dev requesting for review. 22:37
22:48 itrekkie joined
dalek rrot: r39483 | chromatic++ | trunk/compilers/imcc (2 files):
[IMCC] Plugged a memory leak of macro names used in PIR programs (in
 22:53
bacek "No; your specific uses may rely on the presence of bugs, unspecified features, happy accidents, or other behaviors not captured in the test suite." 23:16
Speaking of which. Can I merge tt24_unicode_numifications branch to trunk? :)
dalek rrot: r39484 | chromatic++ | trunk/compilers/imcc (2 files):
[IMCC] Plugged a memory leak of the comma separating macro parameters (yes,
 23:17
23:17 skids joined 23:22 Theory_ joined 23:27 sekimura joined
dalek rrot: r39485 | chromatic++ | trunk/compilers/imcc (2 files):
[IMCC] Plugged a memory leak in PIR macros using curly braces to delineate
 23:36
purl arguments is what's left after action selection
23:37 mongui joined
Whiteknight chromatic++ 23:46
chromatic Want to try your hand at it? 23:47
23:47 patspam joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!