Parrot 2.0.0 "Inevitable" released! | parrot.org | Priorities: merge branches, remove deprecations | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 9 February 2010.
chromatic So much for easy questions. 00:00
darbelo That would expand to "((s)->flags) & PObj_constant_FLAG" right?
chromatic yes 00:01
s is probably not a valid pointer there.
00:01 shamu left
Austin Fwiw, the problem changes if I rearrange some code, which is why I'm guessing it's a wild pointer someplace. 00:01
darbelo s=0x29 in the bt
chromatic Maybe stronger than "probably" then.
Austin But it's time to go, so I'll bang my head on this later.
chromatic The String PMC may not be a String PMC.
darbelo It may not be a String PMC, but it's for sure calling String's get_string() VTABLE. 00:11
00:16 sri joined 00:46 ash_ joined 00:48 ash_ joined 00:50 mikehh joined 01:07 patspam joined
dalek rrot-plumage: fe89202 | leto++ | t/03-util.t:
Add some basic tests for hash()
 01:09
01:19 Whiteknight joined
cotto_work hi Whiteknight 01:19
Whiteknight 'ello 'ello 01:20
cotto_work it is merging time
?
Whiteknight I have to run to the store to buy eggs 01:29
then...MERGERIN' TIME
mikehh++ on the fix, by the way 01:30
cotto_work looks like that branch takes 400B off the _vtable struct on x64. 01:31
chromatic Nice. 01:35
Coke I am probably going to miss my merge window. 01:36
dukeleto Coke: merging what?
purl i guess merging is slow
Coke rm_cflags 01:37
chromatic matt.might.net/articles/writing-an-...mall-step/
mikehh rm_cflags branch: 01:39
plobsing @cbind <Ctrl>f = scroll vertical 95%
@cbind <Ctrl>u = scroll vertical -95%
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32173), fulltest) at r43920 - Ubuntu 9.10 amd64 (g++ with --optimize)
01:39 ruoso joined
plobsing oops, unintentional paste. sorry 01:40
cotto_work startup is also moderately faster in vtable_massacre, with 6% less time being spent initializing PMCs 01:42
purl okay, cotto_work.
cotto_work startup? 01:43
purl i guess startup is taking over 45 seconds... or moderately faster in vtable_massacre, with 6% less time being spent initializing PMCs
dukeleto cotto_work: how are you measuring that?
cotto_work I'll leave that. Maybe someday I too can confuse people talking about startup.
callgrind
purl i think callgrind is a very intresting profiling tool for linux with details at kcachegrind.sourceforge.net/cgi-bin/show.cgi
cotto_work it's a lovely tool 01:44
looking at total cycles, it's ~1.50M in Parrot_initialize_core_pmcs branch and ~2.55M in trunk. 01:45
Whiteknight ...back! 01:48
cotto_work wb
dukeleto i have tried many times to get kcachegrind to work on os x, but no dice. i should just put it on my dusty linux laptop 01:49
cotto_work I <3 kcachegrind.
Whiteknight I need to learn kcachegrind better 01:51
cotto_work It helps to have a large monitor. 01:52
mikehh chromatic: as I understand the article parrot is a small-step interpreter, right? 01:54
chromatic Sounds right. 01:55
dukeleto chromatic: is that similar to the difference between braod and narrow compilers?
s/braod/broad/ 01:56
chromatic I don't know that. 01:59
02:01 nbrown joined
Whiteknight who is looking at one of those OpenVMS accounts? 02:02
INCOMING 02:06
purl duck!
Whiteknight ...and vtable_massacre has landed. now to close some tickets! 02:13
dukeleto Whiteknight: coleda was looking into the openvms acct 02:14
Whiteknight I would be interested in hacking there, if hacking were needed 02:18
chromatic Ugh. 02:19
Anyone who wants something to do so badly that making Parrot work on a platform where we're likely to have no users and which gives us no benefit for other platforms, please look at the list of HLL bugs and development priorities for 2.3 first. 02:20
dalek rrot: r43921 | whiteknight++ | failed to fetch changeset:
merge vtable_massacre branch
 02:21
dukeleto chromatic: i tend to agree. 02:37
chromatic I know volunteer labor and people work on what they want to, but I can't see how a VMS port has value right now. 02:38
Whiteknight depends how much effort the port is 02:54
it may slap together
chromatic It won't; I have code that runs on VMS. 02:56
Forget everything you think you know about processes and filesystems.
purl chromatic, I didn't have anything matching everything you think you know about processes and filesystems
cotto and here I was, thinking it was just another commercial unix 02:57
chromatic There's a POSIX-compatible layer, but it's not that widespread and not that POSIX. 02:58
Windows is easier to port to.
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32175), fulltest) at r43921 - Ubuntu 9.10 amd64 (g++ with --optimize) 03:01
Whiteknight dukeleto: what if I want to go apeshit reimplementing unicode? 03:19
mikehh Whiteknight: you really want to re-invent the wheel :-} 03:29
chromatic In that case, we all owe Mrs. Whiteknight an apology for the beating you'll receive.
src/main.c:417: warning: cast from function call of type ‘long unsigned int’ to non-matching type ‘enum <anonymous>’ 03:31
Oh C, your attempts to have a working type system are so sad and cute at the same time.
mikehh chromatic: had to put that cast in to get it to build on g++ 03:36
chromatic Yeah, I know why we need it. It's just... poor C. 03:37
mikehh I get the warning on gcc build
chromatic Not "that's awful code" but "aww, isn't C CUTE?"
03:41 janus joined
mikehh be interesting to see where Pike, Thompson et al go with Go :-} 03:43
Whiteknight decides to start a C-on-Parrot compiler called "CUTE" 03:56
I would like to get the op_pmcs branch merged in tomorrow probably and have those PMCs marked as experimental 03:57
shouldn't affect the build at all, but does bump PBC_COMPAT
04:04 kid51 joined
kid51 trunk: r 43921: Linux/i386: PASS make test; make buildtools_tests; make codetest 04:04
Whiteknight but I have to go in to work tomorrow morning because management is bad at things like "planning" and "deadlines"
and "resource management" 04:05
kid51 reads scrollback 04:06
At PPW a couple of years ago, Schwern remarked: "I like to work on VMS from time to time. It's like visiting another planet." 04:07
Whiteknight I've never used VMS. it might be a fun learning experience 04:08
anyway, I need sleep if I have to wake up and work tomorrow 04:09
later
kid51 There's one guy who comes to Perl Seminar NY from time to time,
... trained as a physicist, but who has worked as a programmer for many decades
... who swears "I've never lost a file on VMS" 04:10
And, of course, Dan was a VMS expert in his youth.
Tried to view dukeleto's slides on Google Docs at same time as I was building Parrot on my Mac. 04:18
result: eternally spinning kaleidoscopic ball
one of the rare times I had to cut the juice entirely, then start from cold 04:19
Util My first quarter of CompSci was Pascal on Vax VMS. I ended up doing Tiger work (authorized attempted break-ins) via DCL, and became proficient, but have not touched VMS in the last 20 years. 04:21
I have heard VMS called the anti-unix. I agree with the sentiment. 04:23
kid51 had to google for DCL
Util Digital Control Language? Halfway between mainframe JCL and unix shell scripts 04:24
kid51 DCL? 04:25
purl DCL is, like, digital control language, the VMS shell or a project tracking system. see dcl.sourceforge.net/index.php
kid51 purl, DCL is also www.nationmaster.com/encyclopedia/D...d-Language
purl okay, kid51.
nopaste "kid51" at 71.246.114.173 pasted "t/pmc/bigint.t FAILed due to bad plan on darwin/ppc -- but at same rev it passed on linux/i386" (59 lines) at nopaste.snit.ch/19585 04:32
kid51 I thought that I changed the plan on that test from 34 to 45 when it was still in branch. 04:33
But it appears that someone (whiteknight?) changed it back ...
perhaps for good reason ...
but I can't tell because this is one of those files on which 'svn blame' does not work ... 04:34
due to long-ago corruption when we went from CVS to SVN.
too tired to ponder this more now 04:35
starting make fulltest and going to bed
kid51 must sleep
purl $kid51->sleep(8 * 3600);
04:40 mikehh joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32178), fulltest) at r43921 - Ubuntu 9.10 i386 (g++ with --optimize) 05:11
mikehh enough - must sleep 05:12
05:30 patspam joined 06:08 kurahaupo joined 06:10 kurahaupo joined 06:47 iblechbot joined 06:56 TiMBuS joined
dalek rrot: r43922 | bacek++ | branches/boehm_gc_2/t/op/string_mem.t:
Disable string_mem.t on non-MS GC.
 07:20
rrot: r43923 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
Add commented-out finalizers. Apparently they are making parrot 3x times slower
rrot: r43924 | bacek++ | branches/boehm_gc_2/t/op/gc.t:
Skip county tests for non-MS GC.
rrot: r43925 | bacek++ | branches/boehm_gc_2/src/gc/gc_private.h:
Put void* gc_private into GC_Subsystem
rrot: r43926 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
Use typed allocating of PMC ans STRING.
rrot: r43927 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
Use alloc/copy in reallocate_string instead of GC_REALLOC. This behavior
rrot: r43928 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
Collect memory in gc_boehm_mark_and_sweep
07:34 shockwave joined
shockwave I'm in the code generation part of my compiler design. This process involves generating code Parrot code for each construct in my language. So i generate the Parrot code, and manually check it, of course. However, and this is my question, has anyone devise a way to automate part of this process? To make sure the generated code works as intended? 07:36
I know there may not be a clear answer to this, or none at all. What I'm looking for is for the machine to help me do what I'm manually doing; to make sure the generated code does what is supposed to. 07:37
Thanks.
bacek shockwave, check nqp-rx test suite. It can probably help 07:45
shockwave @bacek, I will. Thanks. 07:48
In order to define a class, newclass must be used? Just having the namespace with the class name is not enough, right? 08:14
cotto correct 08:16
shockwave Thanks, @cotto 08:18
bacek cotto, are you just woke up or going to sleep? 08:21
shockwave Let's say that I'm defining a class in file A, to be used in file B. Ideally, file B would just load file A and then instantiate the class. How can this be done if newclass needs to be used to tell parrot that a class exist? 08:24
Can one of the vtable methods help here? 08:25
bacek shockwave, can you use .include?
shockwave sure.
maybe load_bytecode, as well.
cotto bacek, I'm up. It'll be a while before my brain winds down so I can go to sleep. 08:26
it's 0030 here.
~
dalek rrot: r43929 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
Alias interp->gc_sys to reduce noice.
rrot: r43930 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
Decypher Boehm GC bitmap creation
bacek cotto, sound good :)
shockwave @bacek, is .include the answer?
cotto shockwave, once you run new_class, you can do new ['your';'class';'here'] and it'll dtrt 08:27
bacek shockwave, .include erm.. include other pir file.
shockwave Right. But the issue is that I would like the 'newclass' to automagically be ran by the file that defines the class.
Not in the file that is using the class. 08:28
Am I making sense?
bacek shockwave, you can use something like ".sub 'init' :anon :immediate :load" with newclass in it 08:29
to create your classes
shockwave @bacek, Sweet. That what I was looking for. Thanks. 08:30
bacek This sub will run automatically during compilation
cotto bacek, are there any prereqs for building the boehm branch?
bacek cotto, apt-get install libgc1-dev
shockwave One more question for you guys. Should the .HLL directive be placed in all the generated files, or only on the main one that includes the other files? 08:33
cotto looks like it's libgc-dev on my box 08:34
let's see if this works
bacek shockwave, it doesn't harm to put .HLL in all files 08:35
shockwave OK
cotto looks like the boehm branch is slightly slower at parsing tools/dev/pprof2cg.nqp, but it seems to be within 10%. 08:39
It looks like it's to the point where it'll be better than the default for some workloads. 08:40
bacek++
bacek cotto, do you have svn checkout? Can you kill old boehm branch? It's useless now 08:42
cotto np 08:43
you mean boehm_gc? 08:44
bacek indeed
cotto baleeted 08:45
anyone know why vtable_massacre is still around? 08:46
It was merged earlier today.
well, yesterday
purl it has been said that yesterday is seemingly so far away
cotto seen darbelo 08:48
purl darbelo was last seen on #parrot 8 hours, 36 minutes and 33 seconds ago, saying: It may not be a String PMC, but it's for sure calling String's get_string() VTABLE.
dalek rrot: r43931 | cotto++ | branches/boehm_gc:
deleting now-unused branch
 08:59
09:02 fperrad joined
cotto bacek, ooc are you thinking about implementing the sweepless gc on the wiki once boehm_gc_2 is merge-worthy? 09:11
bacek cotto, may be.
09:30 fperrad_ joined
bacek cotto, are you still alive? 09:30
cotto should the inf gc be expected to segfault in the branch? 09:31
yup
bacek cotto, can you check TT#1402?
cotto ./parrot -g inf parrot-nqp.pbc --target=pir tools/dev/pprof2cg.nqp >/dev/null
'splode
sure
dalek rrot: r43932 | bacek++ | trunk (5 files):
Remove unused CallContext.current_results. It should give small performace improvements due less allocations
bacek We basically need few functions exposed via interp->gc_sys
rrot: r43933 | bacek++ | trunk/src/main.c:
Replace Parrot_ex_throw with fprintf(stderr) in CLI parsing. Part of TT#1436.
cotto bacek, +1 to merge those functions. 09:32
actually, your moving CLI parsing out of imcc may enable me to close a bug 09:33
(unrelated but helpful to me) 09:34
dalek rrot: r43934 | cotto++ | trunk/src/interp/inter_create.c:
[interp] reorder initialization code a bit to minimize apparent dependencies between PMC initialization passes
 09:48
cotto It worked! 09:49
purl What do you mean it worked? Did it run to completion? Did it bomb out early? Did it finish the job early? Did it tell your girlfriend "let's just be friends"? Be specific!
cotto msg Coke r43935 adds --hash-seed to parrot. Next time you think you have an ordering-dependent bug, you can use that to verify. 09:51
purl Message for coke stored.
09:57 kurahaupo joined
dalek TT #1383 closed by cotto++: [PATCH] add a cli option to set Parrot's hash seed 10:02
rrot: r43935 | cotto++ | trunk/src (2 files):
[string] add --hash-seed and -H to explicitly set the seed used for hashing
 10:04
10:05 shockwave joined
shockwave @bacek mentioned this: shockwave, you can use something like ".sub 'init' :anon :immediate :load" with newclass in it 10:08
This works well. But, I noticed that if I have to '.include' directives with the same file, the 'init' method gets run twice. 10:09
I have two '.include'...^^^
something like:
.include 'foo.pir'
.include 'foo.pir' 10:10
The anon gets ran twice. Is there a way to limit it to only running once, in order to register the class with Parrot using 'newclass'?
chromatic Don't include it twice. 10:20
I know that sounds facile, but .include is a textual inclusion at that point in the source code.
10:21 Austin joined
shockwave @chromatic, right now, all the inclussions are on one file. My only concern would be if in the future (like, tomorrow), the inclussions needed to be in all generated files. That could cause problems. 10:21
I was just curious if there was a work-around for this. 10:22
chromatic Use load_bytecode instead, if you can't avoid multiple inclusion. 10:23
shockwave @chromatic, Ok. Thanks.
this short code: 11:00
.sub main
say 'from PROOF file'
.end
error:imcc:syntax error, unexpected $end ('�')
in file 'TestXXX.pir' line 1
Gives me that error^^^^
I don't understand what's going on. 11:01
Does anyone have an idea why errors would be issued when running the hello world example, like the first code here: docs.parrot.org/parrot/latest/html/...o.pod.html 11:05
chromatic No idea. 11:10
Works for me.
shockwave Something's fucked up on my machine. This is weird.
11:11 kjeldahl joined, nbrown joined
shockwave These are the exact contents of the file: 11:14
.sub main
say "Hello world!"
.end
Weird.
chromatic Any strange newlines? Whitespace? 11:15
shockwave I setup vim to write Unix, Windows, and Mac new lines. 11:16
But nothing.
purl i heard nothing was shared - this is why things work
shockwave I created another file, and saved it brand new from vim. 11:18
It worked.
purl What do you mean it worked? Did it run to completion? Did it bomb out early? Did it finish the job early? Did it tell your girlfriend "let's just be friends"? Be specific!
shockwave Oh you know what, Since I'm running on windows, and, originally, the previous file was created from Windows Powershell, it may have added some bogus Unicode byte mark. Maybe. 11:19
chromatic That's the only other thing that comes to mind. 11:20
shockwave Anyhow, Thanks for the help, @chromatic
chromatic You're welcome. 11:21
dalek rrot: r43936 | chromatic++ | branches/boehm_gc_2 (2 files):
[GC] Allow build to link and run on systems without Boehm GC installed.
 11:42
chromatic Ugh, Boehm GC and Valgrind are NOT friends. Callgrind goes boom. 11:45
Austin_away Yow. Walking off the end of a sub is way better than doing a 'return'. 11:55
(In nqp)
Here's a nopaste that didn't seem to make it: nopaste.snit.ch/19586 12:01
12:06 joeri joined
Austin Pmichaud: What is the nqp pir:: syntax for the delete_p_k opcode - delete $P0[$P1] ? 13:05
shockwave In order to assign null to a PMC one has to: $P0 = new 'Null' ? 13:47
Or is there a null opcode
Austin There is a null opcode. 13:48
"null $P0"
shockwave How about for this form: $P0 = null ?
I'll try it.
Thanks 13:49
Austin seems to work
nopaste "Austin" at 68.37.46.53 pasted "Does ' = null' work?" (9 lines) at nopaste.snit.ch/19588 13:50
shockwave Sweet. 13:51
Austin Out of curiousity, why are you trying to nullify something?
Isn't that what undef is for?
shockwave It's for creating variables, which in my language are null.
Austin Okay. What language is that? 13:52
purl I'm not sure... but it doesn't sound like any kind of English I know.
shockwave My own custom DSL.
Austin Cool. 13:53
(Cooler if it isn't lisp.)
shockwave I agree with that. 13:54
Austin :)
About the last eleventy-six people doing HLLs were doing lisp variants. There ought to be a special page on the wiki
"How to lisp in parrot"
mikehh thsquaaak 13:56
Austin lol
mikehh++
That's dethpicable!
mikehh :-} 13:57
Austin Man, I hate it when I'm like "Whoa, I'm totally going to rewrite this gnarly code!" and I wind up with the same gnarly code. 14:06
What do you call a sub or method that returns multiple values? 14:15
14:26 TiMBuS joined
mikehh t/run/options.t is failing at r43936 - Ubuntu 9.10 i386 (gcc/g++ with --optimize) 14:27
shockwave Austin, I don't think it has a special name. 14:28
Austin Google was not my friend.
I named them "tuple_sub" and "tuple_method" respectively.
shockwave Sounds good enough. 14:29
mikehh also it is failing in make coretest and that shouldn't be in make coretest
also fails in make test 14:30
Austin I can has parse error? 14:56
dalek TT #1440 created by Austin_Hastings++: parrot-nqp does not parse { in string correctly 14:58
Austin Not a bug, but a heretofore unused feature. 15:01
Okay, why is P6object::__dump getting called when dumping a Sub? 15:08
dalek TT #1440 closed by Austin_Hastings++: parrot-nqp does not parse { in string correctly 15:14
pmichaud Austin: we don't have a syntax for that. 15:33
(delete_p_k opcode, that is)
Austin The delete_p_k?
Okay.
I'll leave that in PIR 15:34
pmichaud dealing with the _k syntaxes is a real pain.
Austin :)
pmichaud 11:54 <Austin_away> Yow. Walking off the end of a sub is way better than doing a 'return'.
yes. 'return' is very expensive.
Austin A lot of things just got converted from return ...; to ...; 15:35
pmichaud I think using 'return' in the fib.nqp benchmark makes it about 2.5x slower
user0m10.370s # fall-through 15:37
user0m23.790s # using 'return'
Austin !! 15:38
Puts pressure on developers to code 'fat' methods.
Use less infrastructure.
15:40 Psyche^ joined 15:41 whiteknight joined
whiteknight purl msg bacek the boehm numbers are looking fantastic! 15:48
purl Message for bacek stored.
15:53 mikehh joined
dalek kapo: ae5b8fe | austin++ | src/Pmc/ (3 files):
Changed some Opcode:: names

Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>		 15:55
Austin Woot. Kakapo P6objects now dump correctly. 16:02
dalek TT #1441 created by jkeenan++: t/run/options.t: new failures in 14 tests 16:03
TT #1442 created by Austin_Hastings++: Sub PMC should support getattribute
16:07 iblechbot joined
whiteknight t/run/options.t is failing 14 tests for me this morning 16:14
wasn't seeing those failures last night after the vtable_massacre branch merged
Ah, nevermind. I didn't see TT #1441 16:15
TT #1442 +1.
Austin: ping
Austin Whiteknight: ? 16:16
whiteknight Austin: can we get a list of what getattribute values you want from Sub?
I could put together a prototype
16:16 theory joined 16:18 jsut_ joined
whiteknight hates BigInt and BigNum, would love to see them exorcised from the repo and moved to external projects 16:19
whiteknight would like to see several things exorcised in such a way
nopaste "Austin" at 68.37.46.53 pasted "Sub attributes" (33 lines) at nopaste.snit.ch/19596
dalek rrot: r43937 | whiteknight++ | trunk/t (2 files):
fix skip numbers in t/pmc/bigint.t and t/op/arithmetics_pmc.t. Patch from Andy++
 16:20
Austin Whiteknight: The 'Sub' class makes a bunch of promises. I think that the individual objects need to be able to keep 'em. 16:21
whiteknight Austin: so getattributes could just call VTABLE_inspect, build that hash, and return the keyed value from it?\\
sounds easy enough for a prototype
Austin I think the problem lies in building the hash.
My goal here is to have a consistent introspection mechanism. 16:22
whiteknight how so? you're building it in the example
or are you saying that it's needlessly wasteful?
Austin I'm not building the hash of Sub data, I'm getting a hash full of promises from class Sub.
The PMC would have to actually get that data, and I understand that some of it may be hard to get. 16:23
(I don't *know* it's hard to get, but I acknowledge the possibility)
whiteknight so that hash in your example contains all the keys, but no values? 16:25
Austin Right. I think each key foo maps to another hash, that has "name => 'foo'" in it, 16:26
It's pretty lame.
whiteknight that is pretty lame
Austin %attributes<foo> := Hash.new( :name('foo') ); 16:27
I added my nopaste to the ticket
whiteknight extend your example to say($_ + " " + %attrs[$_]) 16:28
I want to see what you are actually getting
Austin bide
whiteknight Sub.inspect calls Sub.inspect_str to get the values, but it doesn't look to me like inspect_str does anything like what we want 16:30
maybe it does, just in a roundabout way 16:31
nopaste "Austin" at 68.37.46.53 pasted "More details" (63 lines) at nopaste.snit.ch/19597
Austin It's teh suxx0rs. 16:32
whiteknight Well, looking at the code I don't think that should be the case 16:36
it should be returning at least a few integer values
Austin I don't think it does getattribute at all. It supports inspect.
whiteknight actually, no, it's not calling Sub.inspect at all 16:37
Austin Frankly, I'm not sure why we seem to have two different systems for getting instance data: inspect and getattribute.
whiteknight because Sub.inspect should be returning a different hash with different values
Austin :)
whiteknight see src/pmc/sub.pmc:760
So what the hell is "my &sub := Foo::foo" returning? 16:38
because it sure as hell isn't a Sub PMC
Austin It's a sub.
whiteknight Austin: can you dump the PIR output of the NQP compiler for me and nopaste it? 16:39
whiteknight is at work and having a hard time doing any development
nopaste "Austin" at 68.37.46.53 pasted "test.pir" (72 lines) at nopaste.snit.ch/19598 16:40
Austin look for the .annotate line 6
whiteknight okay, right 16:41
Sub is a built-in type and doesn't have a Class PMC associated with it. it does have a PMCProxy, which we might be returning 16:42
so the behavior you're looking at is in PMCProxy, not Class
and I'm not sure if we can make PMCProxy smart enough to fix it
check what "my $type = pir::typeof__sp($class)" is, I suspect it will be PMCProxy 16:43
in which case, we probably need to call "my %attrs = pir::inspect__pp(&sub)" to get the info you want 16:44
but, we should also fix Sub.getattributes to return more good data
Austin $class is a PMCProxy, &sub is a Sub 16:45
(per typeof)
The trouble is in Sub.pmc, not in the proxy.
The proxy is saying "here are the attributes that class.pmc told me to tell you about."
But Sub says "I don't support getattribute." 16:46
whiteknight ah, ok. so PMCProxy is calling getattribute internally?
Austin No.
There's no Proxy involved
whiteknight ...so...why do we need getattribute?
I
'm not following
Austin The type of &sub, per typeof__sp(), is 'Sub'. 16:47
Not 'PMCProxy'
whiteknight okay. So from your code example it doesn't look like you are calling getattributes on &sub at all
plobsing whiteknight, Austin: this appears to me to be a result of auto_attrs, which sets vtable->attribute_defs, which PMCProxy reads 16:48
nopaste "Austin" at 68.37.46.53 pasted "typeof" (28 lines) at nopaste.snit.ch/19599
Austin Right!
I'm not calling getattribute because I know better. :) 16:49
whiteknight okay, so I was looking for the problem in your example, but that's not where it is. I see now
so you want Sub.getattribute to return values for that list of strings that the PMCProxy.inspect is returning? 16:50
whiteknight sincerely wonders why the hell we need both inspect_str and getattribute
nopaste "Austin" at 68.37.46.53 pasted "error" (38 lines) at nopaste.snit.ch/19600 16:51
Austin Right. The inspect in question is "attributes".
Which suggests to me that "these are valid attributes" 16:52
I can see where you might not want certain information to be an attribute, especially since "attributes" are what objects routinely store into. But if there is an "attributes" tag in the inspect tree, then those should be attributes. 16:54
(Ditto for the "methods", "roles", etc. tags.) 16:55
whiteknight I really would like to find out what the intended differences are between getattribute and inspect_str 16:58
because I dont think there is any rule that getattribute needs to correspond directly to the list of defined ATTRs 16:59
Austin I think that inspect is a general-purpose introspection mechanism. While attributes are things that objects have.
whiteknight that may be the original intention, but in practice getattribute is often used to return things that aren't necessary defined ATTRs
Austin I'd agree that there's no required correspondence, *until and unless* you tell me, via .inspect('attributes'), that "here is a list of attributes." 17:00
whiteknight that may be the case. inspect should return the list of strings (maybe a hash of complete string+values) that getattribute responds to
but that still doesn't leave much room for inspect_str to avoid the axe 17:01
Austin Well, inspect('attributes') should.
whiteknight purl msg allison we're trying to figure out the differences between inspect_str and getattribute, and whether inspect_str is redundant. Can you shed some light? 17:03
purl Message for allison stored.
mikehh getting a codetest faiulure - assert args with - include/parrot/context.h: Parrot_pcc_set_results_func but the function and assert only seems to exist in context.h 17:04
in the headerizer section
Austin Hey, when's 2.1 going out 17:05
whiteknight tuesday, I believe
Austin Well, maybe some of these segfaults will go away.
darbelo materializes
whiteknight segfaults?
purl No whammies!
darbelo 2.1 is going out on tuesday. But my mail announcing it didn't reach the list. 17:06
Austin Yeah, it's blowing up left and right.
mikehh what about the middle?
17:06 tetragon joined
Austin mikehh: The middle is where I get some kind of progress made. 17:06
whiteknight Austin: I haven 17:07
't seen too many segfault reports recently
Austin I guess that depends on how you define "too many".
mikehh tried to run make headerizer but it failed on me - can't find HEADERIZER HFILE directive in 'compilers/pirc/src/pircompiler.c' at tools/build/headerizer.pl line 521.
whiteknight I can't recall any
Austin I'm just running everything two or three times.
To get past the segfaults. 17:08
whiteknight Austin: nopaste me an example that esplodes
Austin Hahahahahaha!
purl LOLCON 6 reached.
Austin If I had a nopasteable example, I'd submit a patch. 17:11
whiteknight oi, nevermind. I'm seeing failures in PLA now 17:13
well, looks like we have some debuggerin to do tonight 17:15
Austin :)
whiteknight which is not nearly as much like English buggering as it sounds
Austin Stop now, dude. 17:16
There's no way you're going to sound any better.
whiteknight usually i get into a hole where I can't possibly sound any worse 17:17
Austin Perhaps you should run for elected office.
dalek kapo: 2d03d94 | austin++ | src/Classes/P6 (2 files):
Changed attribute code to use '$!foo' instead of just '!foo' so that intended-type will show in dump.

Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
kapo: 4fd0e18 | austin++ | (14 files):
Slamming code to try to show segfaults.
Austin Well, all that work for a "die" op 17:19
dalek rrot: r43938 | fperrad++ | trunk/src/ops/math.ops:
the opcode pow must honor HLL types
 17:26
a: cdc873f | fperrad++ | dynext/pmc/lua (3 files):
vtable pow & i_pow are gone, since the merge of branch vtable_massacre

currently, we lost the support of metamethod __pow.		 17:29
dukeleto 'ello 17:40
whiteknight heya duke 17:41
dukeleto whiteknight: how goes it? what are you up to now that vtable_massacre has merged? 17:42
whiteknight dukeleto: Austin has clued me into the fact that we've got some instability issues. Parrot-linear-algebra fails all tests apparently
so once I get home it's debugging time 17:43
dukeleto whiteknight: on trunk and 2.0.0 ?
whiteknight on trunk. Everything built and tested fine that I'm aware of for 2.0
dukeleto Austin: have you looked at Util.nqp in plumage? it might have some useful stuff for kakapo 17:44
whiteknight: did vtable_massacre cause the breakage?
Austin duke: I haven't looked recently, but I already know there's a bunch of stuff I'd like to steal in there.
dukeleto Austin: it is even tested, to boot! although i think some bugs may still lurk 17:45
Austin :)
whiteknight dukeleto: I'm not sure. need to test
I'm still at work, so when I get home I'll check things out more 17:46
dukeleto Austin: gitorious.org/parrot-plumage/parrot...b/Util.nqp 17:47
whiteknight Austin: any insight into when these errors started happening?
dukeleto Austin: tests are here: gitorious.org/parrot-plumage/parrot.../03-util.t
Austin whiteknight: Not usefully. I'm catching up on back taxes from before the new year, so it could have been anytime from 1.7 17:48
dukeleto Austin: git bisect is your friend
whiteknight well, PLA was working fine about a week ago when I last tested it 17:49
Austin Actually, dukeleto, I've got very little opportunity to git bisect, since part of paying my taxes is adopting the new nqp-rx.
That's killing me, since it's a bunch of syntax changes, and I've got a pretty large code base.
whiteknight I've got to pay the nqp-rx tax in Matrixy soon
I'm thinking that might be the opportunity for me to do the big dispatch refactor I have planned 17:50
dukeleto Austin: gotcha 17:51
whiteknight Okay, I'm heading home now. Should be at the debugging station within 2 hours. 17:58
later 17:59
18:13 chromatic joined
dukeleto chromatic: ahoy 18:14
chromatic morning
Austin Yay! Another nqp problem.
Whoa. 18:41
I think I just made 'progress'.
darbelo Austin++
Austin I think I just made 'progress'. 18:42
Whoops. Wrong window. 18:43
shockwave --Austin
Austin Well, so much for that. 18:50
nopaste "Austin" at 68.37.46.53 pasted "Class creation quandary" (15 lines) at nopaste.snit.ch/19602 19:02
Austin Why does this keep happening to me?
Coke chromatic: my openvms testing wsa going to amount to "hey, look that, it <does|doesn't> work!" 19:28
chromatic Sure. Like I said, I think the amount of work beyond that will be non-trivial. 19:32
Austin Any idea why a class woud appear non-existent to the oo code, but be accessible otherwise? 19:44
shockwave Is the current Parrot PIR compiler an optimizing compiler? 19:51
darbelo Not as such. 19:53
chromatic Hm, the naive GC-per-MB patch (a couple of lines of changes) runs fib.pir 12.894% faster. 19:54
darbelo Nice. 19:55
chromatic Let me verify that number; I want to isolate the changes.
darbelo Any percentage above 2 is nice. 19:56
chromatic 12.855%
purl 0.12855
chromatic Still worth doing.
darbelo Indeed. 19:57
chromatic Let me review the KCachegrind visualizations. 19:58
darbelo That reminds me...
You once mentioned that we might benefit from setting the 'special' flag when we attach metadata to PMCs in order to reduce branching in the gc code. Is that still worth investigating?
Austin What's the gc-per-mb patch do? 19:59
chromatic Austin, run the GC only after we've allocated a megabyte of memory, not whenever we run out of free objects.
Austin Ahh
chromatic Huge difference in number of GC runs. 20:08
3.895% improvement in an NQP benchmark. 20:13
This all depends on the ratio of easily recyclable GCables to live GCables.
darbelo I wonder if NQP-generated code holds on to GCables we could recycle. 20:14
chromatic Possibly. 20:15
How do you feel about a 4 - 13% performance improvement this close to a release?
darbelo I'm all for it.
chromatic Incoming. 20:16
purl duck!
20:23 Whiteknight joined 20:25 nbrown joined
chromatic dukeleto, benchmarks before and after r43939 will be informative. 20:26
Whiteknight what happened at r43939? 20:27
darbelo The world changed.
darbelo pokes dalek with a stick.
chromatic I closed one world and opened the nexT.
Whiteknight ah, I see. chromatic's magic GC magic
chromatic We have *less* code in the GC with that tiny patch. 20:28
dalek rrot: r43939 | chromatic++ | trunk/src/gc (3 files):
[GC] Changed the mark/sweep GC so that it runs a GC only if it's allocated a

stick around for longer, but reduces the amount of time marking and sweeping live GCables. Note that we may have to reduce the tunable for the maximum size of a GCable pool.
rrot: r43940 | chromatic++ | trunk/src/gc (2 files):
[GC] Tidied some code and fixed some typos. No functional changes.
Whiteknight I'm seeing failures in t/pmc/hash.t now 20:29
and t/run/options.t
purl t/run/options.t is failing 14 tests for me this morning
chromatic I had the latter before.
I'm not sure how the GC tuning would affect the former. 20:30
darbelo same here with the options.
bacek good morning
purl What's so good about it?
bacek options.t is my fault. I'll fix it soon.
darbelo --bacek++ # decrement for breaking, increment for fixing. 20:32
Damm is decnum-dynpmcs full of FAIL today. 20:33
Whiteknight PLA is building on this computer now. I need to check it on an x86 machine now
yay! I think VirtualBox fixed my Xorg bug! I should be able to run Fedora12 again 20:40
dalek rrot-data-structures: 49a435d | Whiteknight++ | t/pmc/ (3 files):
fix test plans. All tests pass
 20:41
darbelo Whiteknight: ping 20:43
Whiteknight darbelo: pong 20:45
darbelo Say, how did the vtable massacre affect PIR's "z = x ** y" pow syntax?
Should that still be valid? 20:46
chromatic It should be, yes.
Whiteknight should be 20:47
darbelo From what I see here, it's still is. But doesn't dtrt for decnum-dynpmcs, which I expected.
Just wanted to check.
Whiteknight darbelo: right, calls VTABLE_get_number, calls pow() in libc, then VTABLE_set_number_native for result PMC
chromatic bacek, looks like -R is broken. 20:50
bacek chromatic, tt#1441 20:51
darbelo Whiteknight: Yeah, I kinda guessed that when the pow() tests started failing horribly.
chromatic That's the one.
Whiteknight darbelo: probably best to convert pow() to a METHOD 20:52
darbelo Just did that.
But I was curious about the ** syntax staying. 20:53
I was expecting an altogether different kind of FAIL. 20:54
Whiteknight yeah, the ** syntax just gets translated to the pow opcode 20:55
so that still works because the opcode still exists
darbelo I'm guessing you'll go after the opcode on the next cycle, eh? 20:56
chromatic Ah, there's the fix.
Whiteknight darbelo: the opcode is, I believe, intended to become a dynop along with several other math ops 20:57
dalek cnum-dynpmcs: r196 | darbelo++ | trunk/ (2 files):
After the VTABLE massacre, pow() is no longer a VTABLE, rather than lose the
Whiteknight so it will still exist, and may eventually get smarter, but will be a dynop
chromatic bacek, fix coming in a moment.
dalek rrot: r43941 | chromatic++ | trunk/src/main.c:
[parrot] Added missing curly brackets to "No runcore found, bailing out!" case
 21:01
rrot: r43942 | chromatic++ | trunk/t/run/options.t:
[t] Added diagnostic output to display failed command when testing command-line
chromatic All tests pass for me again on trunk. 21:02
dalek TT #1441 closed by chromatic++: t/run/options.t: new failures in 14 tests 21:03
Whiteknight okay, pla passes all tests on x86 again too 21:05
no idea why it failed earlier, must have been a fluke
chromatic If you don't trust me to delete code from the GC now... GOSH! 21:09
dalek rrot: r43943 | mikehh++ | trunk/include/parrot/context.h:
remove lines that headerizer keeps even though function has been removed
 21:34
Whiteknight what needs to get done prior to the release? Just test reports?
any serious bugs need a look?
21:36 AndyA joined
chromatic Anything reported in the last few weeks, I'm sure. 21:39
21:42 hercynium joined
mikehh t/pmc/hash.t is failing (Segmentation fault) - Parse errors: Bad plan. You planned 168 tests but ran 79. - r43942 - Ubuntu 9.10 amd64 (gcc with --optimize) 21:47
Whiteknight urg
chromatic mikehh, can you bisect? 21:51
mikehh chromatic: I will in a minute 21:53
chromatic Thanks. A backtrace will be informative too. 21:55
mikehh chromatic: passes at r43938 - fails at r43940 - trying r43939 22:05
chromatic That's not a good sign. 22:07
mikehh fails at r43939 22:10
how do you get a backtrace again? - I've done it it before but I cat't recall how 22:11
chromatic Run it within gdb, let it segfault, then do bt. 22:13
mikehh hmnn - sure I did something else, but anyway 22:14
chromatic: it don't seg fault under gdb or ./parrot -v 22:33
chromatic Does it segfault under prove?
or perl t/harness t/pmc/hash.t ? 22:34
If the latter, there's an extra command line argument in there.
Whiteknight I'm seeing the hash.t failure here too, under --optimize 22:41
mikehh chromatic: yes for both and ./parrot t/pmc/hash.t
it fails with both gcc and g++ (with --optimize) havcen't tried without yet 22:43
haven't
nopaste "Whiteknight" at 68.46.29.192 pasted "t/pmc/hash.t segfault backtrace" (20 lines) at nopaste.snit.ch/19607 22:45
Whiteknight for that, I ran gdb --args ./parrot t/pmc/hash.pmc 22:46
no other args
ImageIO->buffer is null for some reason 22:49
I don't know enough about the PMC to tell if that's an acceptable condition
do Buffer* objects need to be marked for FC? 22:51
GC?
purl GC is the boehm conservative garbage collector at reality.sgi.com/boehm/cg.html or a really really bad perl "programmer" or GrandCentral.com or branches/gsoc_pdd09 or a travesty against god
chromatic Looks like it can be NULL. 22:54
nopaste "chromatic" at 173.50.130.127 pasted "mikehh, Whiteknight try this patch" (16 lines) at nopaste.snit.ch/19608 22:55
Whiteknight I wonder why an error doesn't appear in non-optimized version
chromatic Address space randomization. 22:56
Whiteknight I'm already building with a variation on that patch 22:58
...and works
committed 22:59
23:06 payload joined 23:10 lucian joined
mikehh ok - looks good 23:12
dalek rrot: r43944 | whiteknight++ | trunk/src/pmc/imageio.pmc:
fix ImageIO.mark() to not try to mark a NULL buffer. Patch inspired by chromatic++, mikehh++
rrot: r43945 | whiteknight++ | trunk/src/pmc/imageio.pmc:
add a const modifier like I should have originally
 23:28
23:29 hercynium joined
dalek TT #1443 created by jonathan++: Segfauts possibly caused by pool compaction bug 23:31
23:33 dukeletoz joined
dukeletoz 'ello 23:35
Whiteknight hello
chromatic dukeletoz, benchmarks before and after r43939 will be informative. 23:42
Whiteknight, can you poke at TT #1443?
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32187), fulltest) at r43944 - Ubuntu 9.10 i386 (g++) 23:44
dalek rrot: r43946 | whiteknight++ | trunk/src/pmc/imageio.pmc:
fix indenting in ImageIO to be like all other .pmc files
 23:45
dukeletoz chromatic: i will try to make that happen 23:46
chromatic Thanks.
I expect between a 4 and 13% performance improvement.
dukeletoz chromatic: ok. are there any specific benchmarks, or just the usuals, like oofib and friends? 23:47
chromatic The usuals. 23:49
dalek tracwiki: v2 | chromatic++ | GCSizeTuning 23:51
tracwiki: Implemented.
tracwiki: trac.parrot.org/parrot/wiki/GCSizeT...ction=diff
23:53 payload 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!