Parrot 1.1.0 Released | parrot.org/ | 322 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets
Set by moderator on 13 May 2009.
00:18 japhb joined 00:21 Theory joined
Whiteknight when did Rakudo get moved to it's own HLL? 00:32
last i heard that was still blocked
darbelo I don't follow rakudo but I think I saw a commit about that scroll by this week. 00:33
jonathan Whiteknight: Yes. 00:34
Whiteknight: Happened just yesterday.
Whiteknight wow, nice. what ended up being the problem?
jonathan Whiteknight: Well, there were many issues along the way. 00:35
Whiteknight ...as one would expect
jonathan Whiteknight: One is that we fiddle with Parrot classes.
That maybe was the biggest source of pain.
I'd not say there was any one single huge blocker, just a lot of little bits that all had to be done. 00:36
We've taken a performance hit from it though.
Haven't really figured out why yet.
Whiteknight yeah, I just read your blog post 00:37
there is lots of optimization to be done throughout parrot, it's a little premature though when we don't even have all our subsystems fully implemented
jonathan Sure, that is an issue too. 00:39
Premature optimization is bad, but I fear putting any optimization off too long is going to hurt Parrot adoptation too. 00:40
The optimizations chromatic++ does seem to be quite sensible ones that won't hurt us later.
Whiteknight yes, he's a rockstar
jonathan I agree there are very likely optimzations now that could hurt later too though.
So it's a balance. 00:41
Plus Rakudo itself could easily be more optimal in a lot of places too.
But again, don't want to do it too early.
While being aware that it's already a pain point.
Whiteknight I'm surprised that multis are only 10% slower then single dispatch 00:43
darbelo purl msg cotto When you get a chance give my last commit a look and tell me if I botched the interface too badly. I'm not entirely convinced that what I did is The Parrot Way To Do It either, but it seemed sensible at the time.
purl Message for cotto stored.
jonathan Whiteknight: They probably aren't in Parrot
Perl6MultiSub has a dispatch cache.
Whiteknight yeah, I know the P6 version has some nice caching
jonathan Well, actually the cache is the same one used by opcode dispatch in Parrot. 00:44
Parrot's MultiSub PMC could also use it, if it were refactored to do so.
(Basically, stop inheriting from RPA and have an RPA instead, and then there's space for a cache pointer.) 00:45
(have an = as an ATTR)
The cache could actually be better too. 00:46
As I blogged, I put the current one together in an afternoon because I wanted something that worked and gave a decent gain. 00:47
Whiteknight I wonder how much of that runtime is related to memory allocations and the GC
I'm planning a few big gains in that area 00:48
jonathan I think we allocate a STRING *
Whiteknight or, things that I hope are big gains
jonathan Hopefully. :-) 00:50
Are you planning on a more generational scheme? 00:51
Whiteknight My initial plans aren't to write a new core, but to fix up some of the inefficient things the current one does 00:52
do fewer mallocs, for instance
jonathan *nod*
That'd certainly be a Good Thing.
ok, sleep for me, night 00:58
Whiteknight goodnight 00:59
01:28 mj41_ joined
dalek rrot: r38809 | coke++ | trunk/docs/user/pir (3 files):
[docs] Test more PIR/PASM.

Probably not the best for didactic purposes, but certainly easier for testing our own samples.		 01:34
rrot: r38810 | coke++ | trunk/docs/pmc (2 files):
[docs] mark & test more PIR/PASM code
 01:47
01:51 eternaleye joined
dalek rrot: r38811 | coke++ | trunk/docs (2 files):
[docs] mark & test more PIR/PASM samples
 02:10
rrot: r38812 | coke++ | trunk/docs/imcc (2 files):
[docs] Mark & test more PIR/PASM examples.
 02:13
rrot: r38813 | coke++ | trunk/docs/dev (3 files):
[docs] Mark & test more PIR/PASM
 02:23
rrot: r38814 | coke++ | trunk/docs/pct (2 files):
[docs] Mark & Test more PASM/PIR code.
 02:26
02:34 benjaminvm joined
benjaminvm Can someone help me (I am new to Parrot)? How do I had a .c file to the Makefile/Configuration System? So it compiles and links. 02:46
Thanks in advance.
Whiteknight benjaminvm: what do you need to add? 02:47
benjaminvm I am mapping the call stack.
To create a graph for dependency documentation, using Graphviz. 02:48
Whiteknight okay
02:48 janus joined
Whiteknight You need to add the file to config/gen/makefiles/root.in 02:48
that's the makefile template
Then you need to rerun Configure.pl, which will generate the makefile from the template 02:49
and assuming you have all your dependencies in order, that should work
benjaminvm Thanks!
Whiteknight no problem, I'm logging off but I'll be back here tomorrow if you need more help 02:50
(or you can ask anyone else too)
goodnight
benjaminvm Night.
03:12 darbelo joined, sekimura joined 03:20 donaldh joined 03:22 particle joined
dalek rrot: r38815 | coke++ | trunk/docs/pmc/struct.pod:
[docs] test/mark more PIR/PASM code.
 03:51
03:58 Ademan joined
cotto benjaminvm, feel free to submit a patch to the mailing list. That sounds like an interesting project you're working on. 04:00
benjaminvm I thought a graphical representation of Parrot runtime would be handy for documentation purposes. 04:05
cotto It'd certainly help make the project more approachable.
dalek rrot: r38816 | coke++ | trunk/docs (15 files):
[docs] Mark & test more pasm/pir.

  - upgrading some samples to compile
  - documenting the ones that already did,
  - and marking the rest as INVALID/TODO, hopefully appropriately.		 04:10
Coke thinks that's the last of the PIR/PASM snippets in docs. 04:14
04:20 Austin_Hastings joined
dalek rrot: r38817 | allison++ | trunk/docs/book/ch09_pasm.pod:
[book] Completely gutting the PASM chapter, and removing it (replaced
 04:20
rrot: r38818 | allison++ | trunk/MANIFEST:
[book] Updating the manifest for deleted chapter.
rrot: r38819 | coke++ | trunk/docs/pct/past_building_blocks.pod:
[docs] make pod test happy.

  [book] A quarter of the way through the PIR chapter.		 05:35
05:35 dalek joined 06:20 flh joined
06:55 Andy joined 07:20 donaldh joined 07:39 iblechbot joined 07:50 barney joined 08:00 integral joined
dalek a: c0c33a4 | fperrad++ | src/pmc/lua (3 files):
remove useless #include
 08:00
08:04 clunker3 joined
dalek lscript: e3ac2c9 | fperrad++ | src/pmc/wmls (3 files):
remove useless #include
 08:21
lscript: f9871d6 | fperrad++ | src/pmc/wmls (6 files):
remove useless #include
a: a104000 | fperrad++ | src/pmc/luabytecode.pmc:
remove useless #include
 08:34
cotto does nqp support switch? 08:51
guess not 08:52
bacek cotto: nope. 08:53
cotto bacek, do you subscribe to parrot-commits? 09:08
bacek cotto: nope. Should I?
cotto It'd be a good idea. Then you'd know that I just resynced pmc_pct with trunk. 09:10
(and whatever else might happen)
bacek I did see it. In IRC backlog :)
cotto Whatever works. I just want to prevent us from getting in each other's way when possible. 09:11
bacek cotto: no worries. Git solves almost all problems :)
cotto so I've heard 09:12
bacek afk # making dinner.
I'll try to find some time tomorrow to work on parrot. Still unlikely that it will happen... 09:13
cotto you'll do it when you do it 09:14
Something's goofy. say() isn't working from nqp. 09:15
bacek you have to .loadlib 'compilers/nqp/nqp.pbc' for "say" and other builtins 09:16
cotto I don't remember having to do that in the past, but it makes sense. 09:17
It must have already been there.
bacek You removed it from pmcc.pir few days ago :) 09:18
cotto I did? Silly me. 09:19
I remember that now. It didn't break anything because nothing was using it at the time.
bacek Just add it back. Or add ".sub say" into builtins.pir 09:20
cotto I'm putting it back. 09:21
bacek (less code)++
cotto heh. I think vtable->attribute_defs can be removed. 09:25
testing...
bacek It's probably not. 09:26
cotto nm. It looks like pmcproxy uses it 09:28
although that's the only place. That's suggestive...
plus the code generates the same thing for FLOATVAL and PMC*, which doesn't inspire confidence 09:29
bacek It was discussion few days ago about "inspect" IIRC. Suggestion was to return at least attributes
cotto ok. I'll file a tt if make test passes without it, but I'll reimplement it just in case. It's only a dozen loc anyway. 09:32
Parrot doesn't build without it. 09:34
09:44 iblechbot joined
cotto bacek, have you done any work parsing vtable.tbl? 09:47
nm. you have 09:48
bacek cotto: only in perl5
But I want to redo it. Current VTableInfo can be more useful 09:49
cotto ok. I'll work on that. 09:50
bacek ok
cotto any objection to me creating a .dump once the file's parsed?
bacek no. I can't see any other place to create dump files. 09:52
Or we can create reduced parser to parse ATTR's only and remove .dump files 09:53
But we have to parse all parents in this case. 09:54
cotto Yeah. dump files are much faster and it's already likely to be slower than pmc2c.
bacek It's definitely slower... Just because parrot isn't extremely fast :/ 09:56
And we do full parsing of pmc's instead of cheating in pmc2c :) 09:58
cotto My sekrit plan is to make parrot's build time more heavily dependent on how fast parrot runs. 09:59
sneakily increasing pressure for a faster bird
bacek good plan!
15 seconds to parse default.pmc... 10:00
cotto ouchies
bacek mostly because of <c_body_statement>... 10:01
It creates separated node for each char... But otherwise I can't parse <c_body_macro>. 10:03
10:06 flh joined
dalek rrot: r38821 | chromatic++ | trunk/config/gen/makefiles/root.in:
[config] Added dynpmc dependency on PMC generation libraries.
 10:07
cotto chromatic++ for finally taking care of that dependency 10:10
10:13 darbelo joined
cotto This is going to be less trivial than I was hoping, but it'll still be nice to turn confusing regex soup into a clean grammar. 10:14
darbelo, ping
darbelo cotto: pong
cotto I looked at your commit, and it looks fine, but I'd also consider accepting strings. 10:16
darbelo It does, sort of.
cotto nm. I briefly forgot it was decContext, not one of the numerical types. 10:17
darbelo Calling set_digits with a string literal DTRT for me. 10:18
$P2 = new 'DecContext'
cotto yes
darbelo $P2.'set_digits'("23") 10:19
$I0 = $P2.'get_digits'()
say $I0
should print "23"
s/I0/S0/ works too 10:20
cotto PIR is nice that way 10:21
darbelo "say $P2.'get_digits'() " doesn't but thats a PIR thing.
cotto yeah. One big part of using PIR is that you have to break everything down into opcode-sized chunks. 10:22
btw, I highly recommend getting some sort of automated testing infrastructure in place. 10:23
even for prototype PMCs
darbelo I agree. I've been testing by running the examples and it's starting to get old. 10:25
I'm reading the Test::Harness::TAP docs now and looking at some parrot tests. 10:26
cotto glad to hear it 10:29
laziness is a good motivator
darbelo It looks like I can do the test files in PIR, so long as I generate proper TAP. 10:30
bacek baseball bats are good motivators also
darbelo: look at t/pmc/packfile*t. 10:31
You don't have to think about TAP.
darbelo I am of the opinion that those old L-shaped tire irons are superior motivational tools. 10:32
dalek rrot: r38822 | chromatic++ | trunk/src/pmc (5 files):
[PMC] Modified PMC initializations to avoid unnecessary use of

non-zeroed allocations -- especially as these initializers immediately overwrite allocated memory.		 10:37
cotto hopes that's not the only thing left to optimize ;) 10:39
darbelo I want to be chromatic++ when I grow up.
cotto: given the amount PMCs parrot creates for everything I would expect even that small saving to add up to something measurable. 10:43
cotto probably so 10:44
dalek rrot: r38823 | chromatic++ | trunk (3 files):
[PMC] Modified PMC generator to skip the isa_hash in the case where the PMC has

VTABLE entries to perform a simple exact match instead of the comparatively expensive hash lookup for type equivalence.		 10:47
rrot: r38824 | chromatic++ | trunk (3 files):
[src] Modified raw NCI registration in PMC generator to use CONST_STRINGs

startup. The speedup is minor, but measurable.
darbelo Also, I've been playing with both prototypes, and I think separate contexts are the way to go. It can do, with some effort, everything that per-pmc contexts can do. 10:49
cotto++ for changing my mind on this. 10:50
cotto glad to be of service
10:52 AndyA joined
darbelo Also changed my mind on the order of implementation. I thik now that BigNum will be easier to do first with BigInt coming later. 10:52
cotto It's a near-trivial difference anyway. 10:54
darbelo And while I'm talking about changes: I think doing s/Big/Dec/ on the names might be appropiate, now that we're not aiming to enter the parrot core. 10:55
cotto Have you looked into how to make that play nice with the existing Big* dynpmcs? 10:56
I agree that it makes more sense from a naming perspective. 10:58
darbelo Not in depth. Converting a Big* to a Dec* should be straightforward enough, but I'm not sure how that would interact with the GMP availability issue. 11:01
cotto Be sure to look into it first. It'll be important, since the gmp-based dynpmcs ship with Parrot. 11:02
darbelo The thing is I'm not entirely sure I can detect GMP at run-time. The PMCs are always there, but will throw an exception if GMP isn't. That might bring some troubles. 11:07
cotto You can catch exceptions.
cotto hands darbelo an exception mitt 11:08
darbelo From c ? I haven't seen any parrot PMCs do that. 11:09
cotto Hmm. I know it's possible. lemme dig 11:10
darbelo OTOH it might not be necessary, if GMP isn't there an exception is the right thing to do.
I could use a "big -> string -> dec" conversion, and let Big* do the throwing. 11:12
same for "dec -> string -> big" 11:13
cotto I know there's a way, but I'm about 5 minutes from being a zombie. Feel free to ask on the list, but I'm going to sleep. 11:16
night
darbelo mornin^Wnight 11:17
11:21 donaldh joined
mj41 Hi. TapTinder found some regressions. tt.ro.vutbr.cz/report/pr-Parrot/do?...un-1424=on 11:53
and tt.ro.vutbr.cz/report/pr-Parrot/do?...un-1487=on 11:56
12:06 Whiteknight joined
darbelo Hmm. t/dynoplibs/myops.t passes for me on parrot HEAD 12:06
mj41 On my test machine it really start failing in rr38804 (chromatic) tt.ro.vutbr.cz/report/pr-Parrot/do?...un-1424=on 12:20
nopaste "mj41" at 147.229.5.176 pasted "Failing tests details" (210 lines) at nopaste.snit.ch/16558 12:36
12:39 rg joined
darbelo Did a 'make realclean' and I'm seeing all three failures now. 12:47
12:51 HG` joined 12:52 masak joined
masak gist.github.com/112669 # Parrot build failure 12:52
seems I'm missing this file libintl.h
13:02 AndyA joined 13:14 kid51 joined
dalek rrot: r38825 | jkeenan++ | trunk (3 files):
Renumbering of opcodes no longer differs between pre- and post-1.0.0 Parrot. Revise Parrot::OpsRenumber, the script that uses it, and the file that tests it. Cf.: trac.parrot.org/parrot/ticket/469.
 13:15
Whiteknight I'm getting test failures: t/pmc/managedstruct.t, t/pmc/nci.t t/pmc/packfilefixupentry.t.
Anybody else seeing these?
Infinoid masak: On my machine (linux/x86-64), libintl.h is part of the glibc package 13:16
Whiteknight: packfilefixupentry.t passes here, the other two have some failures (and some ugly crash output from nci.t) 13:17
Whiteknight I wish all this test output was a lot less verbose 13:18
13:21 burmas joined
dalek rrot: r38826 | Infinoid++ | trunk (2 files):
[cage] Pass c_function_docs.t (reran headerizer) and cuddled_else.t (add a newline).
 13:21
darbelo Whiteknight: irclog.perlgeek.de/parrot/2009-05-16#i_1148354 13:24
Whiteknight urg, running make test again (this time with a logfile) dumped core 13:27
invalid pointer going into a realloc()
13:27 szabgab joined
Whiteknight (thanks for the link, darbelo) 13:27
Infinoid Whiteknight: I'm bisecting.
Whiteknight Okay, excellent 13:28
13:28 flh joined
Infinoid it wasn't c's recent NCI STRING stuff 13:28
but it's something in the last 24 hours. I'll let you know when the bisect is done 13:29
flh is there a way in PIR to make getstdin return something else than the actual stdin? I'd like to use that to change the behaviour of HLLCompiler in interactive sessions so that it only tries to parse things that look like (multiline) statements 13:30
Infinoid flh: What exactly do you think it should return?
Whiteknight there are definitely lots of bad failures in the t/pmc/nci.t, that suggests something changed in the NCI system
flh my own-cooked PMC, which would basically be stdin, but with a custom 'readline_interactive' method 13:31
Infinoid There are setstdout and setstderr ops, to override those, maybe we need a setstdin as well.
nopaste "kid51" at 70.107.19.15 pasted "Build failure on Darwin/PPC at r38824" (741 lines) at nopaste.snit.ch/16559 13:33
Infinoid (I've been wishing those overrode C level I/O rather than just pir level, but that's a separate issue.)
kid51: ah, I think masak is seeing the same issue
Whiteknight Okay, all the failures I'm seeing are happening in the final GC run in Parrot_really_destroy 13:34
Infinoid Assuming libintl.h is available may be a linuxism (or a glibcism)
nopaste "kid51" at 70.107.19.15 pasted "Failure point in build at r38824" (10 lines) at nopaste.snit.ch/16560 13:36
Infinoid Whiteknight: r38822
Whiteknight woot. Infinoid++ 13:37
nopaste "darbelo" at 200.49.154.172 pasted "Anothe backtrace of the failure." (14 lines) at nopaste.snit.ch/16561
kid51 My paste 16560 is part of the diff between the log of my last successful build on this box versus today's log of the failed build. 13:38
Infinoid nice.
13:39 rdice joined
Infinoid So what happened to osx's gettext stuff within the last day or two? 13:39
masak Infinoid: I'm back. if there's any way I can help diagnose this, please let me know. 13:44
maybe I should submit a parrotbug?
Infinoid masak: I'm having trouble finding out what caused the failure. If you have time, a bisect wouldn't hurt
Whiteknight okay, I think I have at least part of it fixed
darbelo got a patch9;2~ 13:45
Infinoid masak: definitely parrotbug it if we don't find an immediate fix :)
darbelo Sorry, got a patch? I can help verify.
masak Infinoid: ok, I'll bisect and then file a parrotbug.
Infinoid masak++ 13:46
darbelo: Which platform are you on?
Whiteknight commited 13:47
darbelo OpenBSD-current amd64
Infinoid Ok. I know chromatic tests religiously on linux/x86-32, so I've been running on the assumption that this was x86-64 specific. So that makes sense
13:48 ruoso joined
dalek rrot: r38827 | whiteknight++ | trunk/src/pmc/unmanagedstruct.pmc:
[PMC] undo some changes made in r38822 in unmanagedstruct.pmc. I don't know exactly why this change is causing failures, but I suspect there is something bad happening in inheritance between unmanagedstruct and managedstruct that needs to be explored and fixed
 13:49
Infinoid Testing now
Result: PASS 13:50
Whiteknight w00t
Infinoid Whiteknight++
Whiteknight now just need to find the root cause, figure out why that changed caused failure in the first place
darbelo Infinoid: OpenBSD also pulls all sorts of randomization tricks on memory. It very good at crashing programs that behave fine on other systems :) 13:51
Infinoid hmm. SELF.init() will call ManagedStruct's init, right?
darbelo: linux 2.6 has started doing some of that too 13:52
random stack and heap, random code location, things like that
Makes it impossible to set conditional breakpoints in gdb which depend on pointer values, unless you turn it off first
Good in general tho :) 13:53
Whiteknight: At first glance, I think it's allocating a differently sized attr struct 13:54
Whiteknight I found the problem, tested, and committed it
managedstruct:init_pmc was calling SUPER(value)
which would then reallocate the attributes structure to something smaller 13:55
Infinoid yeah, and leak it
Whiteknight right
Infinoid leak the old one, I mean
Whiteknight so I removed the call to SUPER, and that fixed it
13:55 masak` joined
dalek rrot: r38828 | whiteknight++ | trunk/src/pmc (2 files):
[PMC] Fixed strange coupling between managedstruct and unmanagedstruct in init_pmc that allows chromatic++'s change in r38822 to be reapplied. Infinoid++ for helping bisect
 13:55
Infinoid Cool. currently, SUPER() in ManagedStruct.init_pmc() didn't really seem to do much 13:56
hmm
It does include a call to SELF.set_pmc(value), which in turn calls calc_offsets() 13:57
Whiteknight right
Infinoid so I guess it's initializing some stuff (?)
uck, UnManagedStruct is way too complicated for its own good.
Whiteknight yeah, eventually that's going to need major refactoring
Infinoid oh well, everything is passing now 14:10
if something does depend on that extra initialization, we can always just call it in MS.init_pmc directly
14:12 HG` joined 14:15 AndyA_ joined
kid51 is still experiencing build failures 14:18
dalek rrot: r38829 | jkeenan++ | trunk/lib/Parrot/OpsRenumber.pm:
At present time src/ops/ops.num is the only reasonable argument for renum_op_map_file(). So eliminate one internal ternary op so we don't have to write a test for it.
nopaste "kid51" at 70.107.19.15 pasted "Build failures persist at r38828" (741 lines) at nopaste.snit.ch/16562 14:19
kid51 Let me try a make realclean 14:20
Infinoid kid51: Haven't found a fix for that yet, still not sure what caused it. masak++ was going to do a bisect and post a TT 14:21
kid51 That was on Darwin/PPC. It appears I'm doing okay on Linux i386.
Infinoid yeah, it sounds OSX-specific
kid51 Damn. These OS-specific failures are a real PITA. 14:23
Well, the problem has to have originated between r38784 and r38824. 38784 was my last successful build on Darwin/PPC, done on May 14. 14:25
Infinoid hmm, ok 14:27
nopaste "kid51" at 70.107.19.15 pasted "Difference in build logs between r38784 and r38828 on Darwin/PPC" (89 lines) at nopaste.snit.ch/16563 14:28
kid51 Likely source of problem: parrot/include/parrot/parrot.h:239:23: error: libintl.h: No such file or directory 14:29
What is libintl.h? Something Unicode-related? IIRC there was some discussion of ICU problems on Darwin. 14:30
Infinoid not unicode, it's i18n (string translation)
libintl.h has been included from parrot.h since 2008-04-12, whenever PARROT_HAS_GETTEXT is defined
I can't find any recent differences either in that include or in the gettext detection stuff 14:31
and I can't find anything i18n, libintl, gettext, osx or darwin specific at all in the last couple days' diff
and I can't reproduce it on linux, so I can't do a bisect. sorry 14:32
kid51 Would this TT be relevant: trac.parrot.org/parrot/ticket/673 14:33
14:34 polyglotbot joined
kid51 (And, on top of everything else, smolder is down again.) 14:34
Infinoid probably not relevant. different subsystem 14:35
judging from the google hits, OSX has never had libintl.h, so the issue seems to be that PARROT_HAS_GETTEXT is defined when it shouldn't be
The libintl stuff is used for supporting (for example) chinese or spanish or whatever, by putting all your strings through a lookup table (with a filename like /usr/share/locale/es/LC_MESSAGES/iso_3166_2.mo) at runtime based on some environment variables (like LC_ALL=es) 14:38
If your platform doesn't have it, it doesn't have it. But that shouldn't have changed in the last couple of days
libicu is unrelated, I think. we use it for manipulating unicode on the character level, and transcoding strings between character sets 14:41
nopaste "kid51" at 70.107.19.15 pasted "Commits most likely to have included code which breaks build on Darwin" (52 lines) at nopaste.snit.ch/16564 14:43
kid51 Infinoid: Can you look at that paste and suggest a point at which to begin bisecting?
masak` bisect: r38804. 14:45
Infinoid masak++
masak` (gotta create an automatic bisecting tool for SVN...) 14:46
I don't see how the changes in r38804 can affect the build failure, though.
but perhaps someone else does.
Infinoid masak: There are two of them on CPAN, one written by Coke and one written by me
Coke's is more automatic. Mine is more like git bisect. 14:47
It must be stripping something from the Config array that it shouldn't be
s/ be//
masak Infinoid: would it be useful if I svn upped, reverted r38804, and tried building? 14:49
14:50 AndyA joined
Infinoid Sure 14:50
masak: Actually... I'd love to see the diff of your config_lib.pasm before and after the revert 14:51
nopaste "kid51" at 70.107.19.15 pasted "Instances of PARROT_HAS_GETTEXT" (4 lines) at nopaste.snit.ch/16565 14:52
Infinoid Ok, so it's defined. It shouldn't be. I don't know why, but it sounds like reverting it will change that (and maybe some other stuff) 14:53
kid51 Am building at r38804. There are no significant differences between that r's config_lib.pasm and that of HEAD. 14:56
Infinoid kid51: if r38804 is the first bad rev, I suggest trying r38803
(r38804 will just fail in the same way) 14:57
kid51 Infinoid: yeah that just occurred to me as well.
masak Infinoid: I'll make sure to get you the diff, but I can already say that Parrot builds with the commit reverted. 14:58
Infinoid thanks! that diff will be handy for waving at people on-list
(you shouldn't need to do a full build to get the diff, config_lib.pasm is generated by Configure.pl) 15:00
15:01 tetragon joined
kid51 Build failed at r38804. 15:03
... on Darwin/PPC.
Infinoid r38830 reverts r38804. I can post to list about it when we understand the consequences a little better 15:09
dalek rrot: r38830 | Infinoid++ | trunk/config/gen/config_pm.pm:
[config] Revert r38804.

  /Users/jimk/work/parrot/include/parrot/parrot.h:239:23: error: libintl.h: No such file or directory
Revert it for now, until a better solution can be found.
  masak++ and kid51++ for reporting and bisecting.		 15:11
kid51 Infinoid: Could you open a TT which describes this problem and what steps we've taken so far to correct it? So that we have a record of what we tried. 15:14
Infinoid I will, yes 15:17
masak gist.github.com/112709 # diff of config_lib.pasm 15:19
Infinoid: I haven't created a TT yet, so you're welcome to go ahead and do it. 15:20
15:20 donaldh joined
dalek rrot: r38831 | whiteknight++ | trunk/docs/book/ch04_compiler_tools.pod:
[book] some clarifications in the first sections of chapter 4. These parts were a little confusing and probably need more work still
 15:20
Infinoid I think it must be an include path in ccflags that caused it 15:21
actually, the normal CFLAGS doesn't seem to be used when compiling pbc_to_exe.c, though it's used for lots of other .o files (which apparently compile just fine with gettext) 15:25
kid51 Confirmed that r38803 successfully completed 'make' on Darwin/PPC.
So confirm that problem (in whole or in part) occurred with r38804.
Infinoid thanks 15:26
Ah. the Makefile CFLAGS are right, but r38804 meant ccflags was no longer available to PIR. (pbc_to_exe.o is compiled by tools/dev/pbc_to_exe.pir, not the Makefile)
Infinoid writes it all up 15:27
nopaste "kid51" at 70.107.19.15 pasted "Significant differences in config_lib.pasm between r38803 and r3884 on Darwin/PPC" (127 lines) at nopaste.snit.ch/16566 15:30
kid51 Confirm that r38830 (reverting 38804) builds successfully on Darwin/PPC. 15:35
Infinoid thanks, TT #675 15:38
I think we can reapply r38804, but make it whitelist a few key items
nopaste "darbelo" at 200.49.154.172 pasted "t/dynoplibs/myops.t still fails on OpenBSD amd64" (57 lines) at nopaste.snit.ch/16567 15:42
Infinoid I am a bit worried that additional items pertaining to Configure.pl options may also need to be whitelisted. if they aren't enabled by default, they won't be seen until someone tries them, which will be a really nice, hard-to-find bug causing headaches later on
darbelo Whiteknight: I'm still seeing a failure after your commits. The previous nopaste has the output of prove -v and a backtrace. 15:44
Whiteknight there is a failure in t/pmc/packfile... or something 15:45
is that what you are seein?
darbelo mine's on t/dynoplibs/myops.t 15:46
dalek rrot: r38832 | whiteknight++ | trunk/docs/book/ch04_compiler_tools.pod:
[book] more reworking of the first parts of chapter 4
Whiteknight hmmm, that one isn't failing on my system 15:47
darbelo dumps core on Parrot_exit
nopaste.snit.ch/16567 has the backtrace
Whiteknight right, i saw the backtrace, does look similar to the one for the managed struct issue that I just fixed 15:48
without being able to duplicate it locally, or without getting a bisect, I really can't fix it
Infinoid ooh, context handling
Infinoid tries throwing openbsd into qemu 15:49
darbelo Infinoid is in for some failures :) 15:50
Infinoid suspects it won't be as broken as dragonfly
Whiteknight darbelo: Can you open up the debugger and see if Parrot_Scheduler_destroy() is being called before that call to Parrot_Timer_destroy()? 15:52
15:52 davidfetter joined
darbelo Not entirely sure how to invoke gdb to run a parrot test. 15:53
Whiteknight depends if the test is written in Perl or Parrot 15:54
15:54 HG` joined
Whiteknight if Perl, you would do "start t/dynoplibs/myops_7.pasm" probably 15:54
or maybe .pir 15:55
if Parrot, just "start t/dynoplibs/myops.t"
darbelo Looks like perl to me.
Whiteknight yeah, the test file is t/dynoplibs/myops_7.pir 16:01
darbelo any particular reakpoints ou want me to set? 16:02
Whiteknight Parrot_Scheduler_destroy and Parrot_Timer_destroy 16:03
set both and see which one comes first
okay, I'm going to disappear for a little bit, let me know which goes first when you figure it out 16:12
later
darbelo later
nopaste "infinoid" at 75.28.74.203 pasted "[patch] Redo r38804, but whitelist a few key items" (29 lines) at nopaste.snit.ch/16568 16:19
Infinoid masak,kid51: Do either of you have a moment to try that patch against latest trunk? 16:20
16:20 mberends joined
Infinoid oh, kid51 left. 16:20
16:20 flh joined
nopaste "darbelo" at 200.49.154.172 pasted "Parrot_Timer_destroy and Parrot_Scheduler_destroy calls" (34 lines) at nopaste.snit.ch/16569 16:22
darbelo purl: msg Whiteknight The debug info for the OpenBSD segfault is at nopaste.snit.ch/16569 16:23
purl Message for whiteknight stored.
masak tries the patch 16:29
Infinoid masak: It would probably help if I gave you something that perl5 can parse. s/foreach my key/foreach my $key/ 16:33
masak aye... 16:34
masak tries again
16:38 Theory joined
Whiteknight thanks darbelo++ 16:40
16:41 dukeleto joined, dukeleto_ joined
Infinoid masak: I'm going to throw the whitelist idea out and try a different approach, based on chromatic's comments in groups.google.com/group/parrot-dev/...c89d50d84a 16:42
nopaste "Whiteknight" at 69.249.200.13 pasted "Possible fix for darbelo++" (18 lines) at nopaste.snit.ch/16570
Whiteknight purl msg darbelo check out nopaste.snit.ch/16570. Give that patch a test and see if it fixes your problem 16:43
purl Message for darbelo stored.
Whiteknight purl msg darbelo if that doesn't work, open a trac ticket for the issue with your backtrace. 16:44
purl Message for darbelo stored.
16:57 masak` joined 17:10 HG` joined
darbelo purl: msg Whiteknight All tests successful! Your patch fixed it form me. Thanks. 17:31
purl Message for whiteknight stored.
17:34 AndyA joined 17:53 mikehh_ joined 17:55 rhr joined 18:21 benjaminvm joined
dalek cnum-dynpmcs: r43 | darbelo++ | trunk/t/rounding_mode.t:
Add our first test, not usable yet .
 18:30
18:31 PacoLinux joined
Infinoid darbelo: harness problems? 18:35
darbelo Sort of. There's me, there's a harness, and there are problems ;) 18:36
Infinoid how enlightening :) 18:37
18:40 bsdz joined
darbelo Most of the build infrastructure for decnum-dynpmcs came from the create_language.pl script, but the t/harness file it generates wants to test a langage , I'm trying to convice it otherwise. 18:41
Well, was. Now I'm checking out the one mk_language_shell.pl generates. 18:44
18:46 Whiteknight joined
Whiteknight darbelo: ping 18:53
Infinoid oh, ok. well, if your tests are written in perl, it's enough if your Makefile's test: rule just runs "prove t" 18:57
ah, you're writing them in pir. I'm sure we can throw something together that'll work 18:58
darbelo: I don't see a t/harness in decnum-dynpmcs. But your t/rounding_mode.t doesn't have a tag indicating how to run it... it might be as simple as putting a "#! parrot" at the top of the file 19:01
darbelo It looks like I forgot to svn add the harness. The #! hasn't made any difference, probably becouse parrot isn't in my path. 19:11
dalek rrot: r38833 | petdance++ | trunk/config/gen/makefiles/root.in:
final cleanup of some redundant splint flags
 19:19
19:20 donaldh joined
Infinoid darbelo: I can take a look if you commit it 19:20
darbelo I *think* I have it now. I'll commit something in a few minutes. 19:25
19:42 Whiteknight joined
dalek cnum-dynpmcs: r44 | darbelo++ | trunk/ (3 files):
Minor typo-fixes to t/rounding_mode.t

Uncomment "make test" in the Makefile.		 19:43
rrot: r38834 | whiteknight++ | trunk (6 files):
[gc] separate out the MS core from the general marking and sweeping utility functions. needs cleaning
 19:55
cotto darbelo, you should put a coda at the end of the .t file to get proper syntax highlighting. See t/pmc/env.t for an example. 19:58
Whiteknight, I think you broke the build. 20:08
or not. It may just be a manifest issue. 20:09
Whiteknight did I?
cotto yup 20:10
Whiteknight it builds fine for me, what error are you getting?
Infinoid init::manifest - Check MANIFEST...No such file: src/gc/gc_ms.c
(during configure)
cotto make: *** No rule to make target `src/gc/gc_ms.c', needed by `src/gc/gc_ms.o'. Stop.
Whiteknight ah, shit. I forgot to svn add that file
Whiteknight fixes that now
darbelo cotto: Done. I don't use syntax-hilighting, so I din't notice the lack of it. 20:11
Whiteknight committed. Thanks cotto++!
cotto Whiteknight, always glad to point that out. ;) 20:12
dalek cnum-dynpmcs: r45 | darbelo++ | trunk/t/rounding_mode.t:
Add coda to .t file.
rrot: r38835 | whiteknight++ | trunk/src/gc/gc_ms.c:
[gc] adding a file that I forgot. cotto++
 20:14
cotto darbelo, really? It's shiny. If you're using vim you can run make vim-install in editors. If you're using emacs, there's some .el files that you'll probably know what to do with.
*editors/ 20:15
Infinoid Whiteknight: hmm, I have some linker errors 20:16
/home/infinoid/parrot-dev/test/blib/lib/libparrot.so: undefined reference to `Parrot_gc_ms_free_pmc'
/home/infinoid/parrot-dev/test/blib/lib/libparrot.so: undefined reference to `Parrot_gc_run_init' 20:17
/home/infinoid/parrot-dev/test/blib/lib/libparrot.so: undefined reference to `Parrot_gc_ms_run_init'
dalek rrot: r38836 | whiteknight++ | trunk/src/gc (4 files):
[gc] move a few more functions around, a few funcs that don't need to be in the MS core. Start fixing up the documentation
mikehh I am getting t/compilers/imcc/syn/regressions.t failures in make -k fulltest (test 14) 20:18
cotto Whiteknight, same as Infinoid here
Whiteknight crap damn fart 20:19
Infinoid that was r38835, trying r38836 now
mikehh it passes in make test but fails in the all the runcore tests
20:19 chromatic joined
chromatic Infinoid, ping 20:19
Infinoid Whiteknight++ # that fixed it 20:20
chromatic: pong
darbelo: I get "Invalid rounding mode provided!" from your test on linux/amd64
darbelo On all of them? 20:21
dalek rrot: r38837 | petdance++ | trunk (3 files):
quieted some splint warnings; consted some local vars
chromatic I just sent a message to the list about big performance improvements in Parrot_str_find_cclass(); I think you might be able to implement that idea quickly.
Infinoid darbelo: There's only one test script; it it crashes parrot with that message before emitting any tap output
chromatic: Thanks, I'll check it out
chromatic It should be relatively simple, if my analysis is correct. 20:22
Do you have kcachegrind or can you install it?
Infinoid I do, but I've only used it once or twice, and don't remember the specifics 20:23
chromatic wgz.org/chromatic/tmp/callgrind.out.12081.bz2 20:24
bunzip2 that, then run kcachegrind callgrind.out.12081
Infinoid darbelo: My mistake. There's lots of fail output before that. I'll nopaste it
nopaste "Infinoid" at 75.28.74.203 pasted "decnum-dynpmcs failures for darbelo" (14 lines) at nopaste.snit.ch/16573 20:25
Infinoid It might just be that I've configured it wrong.
chromatic You should see a pretty graph. I like to show absolute costs and display percentage relative to parent. Search for Parrot_str_find_cclass, and the callgraph view in the bottom right pane should help you see what's what.
Infinoid chromatic: 2009-05-16 13:25:57 ERROR 403: Forbidden.
chromatic one chmod later, it's not forbidden. 20:26
Infinoid Like magic.
ok, I can see it spends 60% of its time in get_codepoint() 20:28
jonathan chromatic: oh hi 20:29
purl hi, jonathan.
jonathan chromatic: Interestingly enough, I was trying to debug a hang the other day and broke into some code from the debugger during the parse stage. 20:30
chromatic: And it seemed pretty busy in the cclass handling code. :-|
chromatic Yeah. Inverting the iterator should give us a measurable improvement. 20:31
Perhaps as high as 25% in parsing intensive code, but more likely 15%.
jonathan That'd still be a very welcome change. 20:33
I've started a branch in Rakudo to use hll_map to create Perl6MultiSub straight off rather than creating a MultiSub and re-blessing at startup.
That should shave a little more off startup time. 20:34
chromatic The nice part about the Parrot_str_find_cclass speedup is that it also helps another slow part: CodeString's lineof().
jonathan Didn't you also already add some caching to that? 20:35
chromatic I did. It's less slow than it was.
jonathan Nice.
But more speed would certainly be good.
chromatic Another part of slowness I can't fix now is that PCT holds on to Captures a long time. 20:36
Infinoid Coke++ # Bet you thought all those documentation changes were a thankless task, huh.
jonathan chromatic: I think that's because we keep hold of the parse tree all the way through to the stage of generating the POST. 20:37
darbelo I have to dissapear for a while. I'll check out the tests later.
Bye
dalek rrot: r38838 | whiteknight++ | trunk/src/gc/gc_ms.c:
[gc] update documentaton for the new gc_ms file, separating functions into groups by purpose
cotto bye
jonathan chromatic: Not sure that's easily changable though, given the info is currently needed all the way through.
Coke chromatic: editor-type question for you. 20:39
chromatic: I find a PIR_FRAGMENT In the book that doesn't work; it uses a non-existant syntax. Just mark it as invalid, or rip out the offending docs /and/ code? 20:40
rant. I want a test harness that gives me an option for a summary of test descriptions for failed tests, not numbers. numbers are often useless.
Infinoid: oooh, karma. =-) 20:41
chromatic: I will err on the side of caution for now. 20:42
mikehh make html - Failed to process docs/book/ch09_pasm.pod. - the chapters need renumbering and/or the makefile needs fixing
chromatic Coke, mark it as invalid and leave a note for the editor with =for editor/=end for 20:43
Coke chromatic: I can add that, but having INVALID markers sufficient?
"isn't"
dalek rrot: r38839 | whiteknight++ | trunk (4 files):
[gc] rearrange some functions that a pool-related and not ms-related
 20:44
rrot: r38840 | coke++ | trunk/docs/book/ch03_pir.pod:
[docs] the syntax described here is invalid.
Coke (currently 32 cases of invalid code in the books)
chromatic Probably.
purl Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole.
Coke msg allison before the book goes to press, "t/examples/pod.t" should probably not have any TODOs in docs/book
purl Message for allison stored.
dalek rrot: r38841 | whiteknight++ | trunk/src/gc (4 files):
[gc] rearrange a few more things
 20:50
rrot: r38842 | coke++ | trunk/t/codingstd/c_function_docs.t:
[t] skip some more files that don't have all their function docs yet.
rrot: r38843 | whiteknight++ | trunk/src/gc (6 files):
[gc] rename Parrot_gc_sweep to Parrot_gc_sweep_pool, since that's a more accurate description for what it does
 20:54
cotto no, probably is <reply> 20:57
purl okay, cotto.
20:59 bsdz joined
dalek rrot: r38844 | petdance++ | trunk/lib/Parrot/Vtable.pm:
Starting to note observers for splint
 21:00
rrot: r38845 | whiteknight++ | trunk/src/io/core.c:
[gc] fix a small documentation note in src/io/core.c about what GC function calls it
rrot: r38846 | whiteknight++ | trunk/src/gc (3 files):
[gc] move and rename trace_active_PMCs. It's a static function now
 21:04
rrot: r38847 | chromatic++ | trunk/src/oo.c:
[oo] Fixed a semi-predicate problem in

cached absence of a VTABLE override. Respecting the case where Parrot's already performed the lookup and found no override improves the Rakudo-building benchmark by 10.42%. The improvement is similar in other heavily OO code.		 21:10
Infinoid chromatic: Hmm, the character class checking for unicode is rather complicated. There's still a typetable for the iso8859-1 case, but there's also u_iscclass() for the high characters, which I'm going to have to duplicate across 3 unicode encoding plugins 21:11
Is that what you had in mind? 21:12
chromatic I had only looked at the ASCII case, really.
Infinoid Well, I have that one done, it wasn't hard
chromatic It could be that we only have a shortcut where it's possible to go really really fast.
Infinoid Well, I have no problem with handling ascii really really fast 21:13
chromatic Latin 1 fast is also good.
If we can do those, we get most of Perl 6 faster.
Infinoid If the encoding plugin calls back to the charset plugin for the high characters, should that be a function pointer, or should I un-staticify that function?
chromatic I'm not sure we even have to do that. 21:14
In the ASCII and Latin-1 find_cclass, you can immediately go to the fast encoding iterator instead.
Leave the others untouched.
I *think* that works.
Infinoid Ok, I have most of that already 21:15
(but I have to wonder what charset/encoding rakudo is assuming its code to be, these days) 21:16
chromatic Latin-1 I thought.
Certainly we're hitting the ASCII path in this profile. 21:17
Infinoid Great, then the bonus should be non-zero
chromatic At least 17%, if I read this new profile right.
That's on top of the 10.4% from the OO change.
dalek rrot: r38848 | petdance++ | trunk (3 files):
Adding macros for splint exposure tracking
 21:39
rrot: r38849 | whiteknight++ | trunk/src/gc (8 files):
[gc] a large series of cleanups, trying to rename things to be more consistent.
rrot: r38850 | whiteknight++ | trunk/src/gc (6 files):
[gc] a few more small function moves.
 21:53
22:05 benjaminvm joined 22:30 Theory joined
dalek rrot: r38851 | whiteknight++ | trunk/src/gc/gc_ms.c:
[gc] clean up the function gc_ms_mark_and_sweep a little, remove extraneous comments, etc.
 22:32
Infinoid hmm, now I'm seeing failures in t/pmc/packfileconstanttable.t 22:58
Parrot_PackfileConstantTable_set_pmc_keyed_int is being called with a dead pmc (its vtable pointer is 0xdeadbeef)
23:09 ruoso joined 23:20 donaldh joined
Infinoid The packfile failures I'm seeing happen even without the upcoming commits... 23:28
dalek rrot: r38852 | Infinoid++ | trunk/src (3 files):
[cage] Fix some codetest failures.
 23:30
rrot: r38853 | Infinoid++ | trunk (7 files):
[encoding] Implement chromatic++'s idea to push the Parrot_str_find_cclass() loop down into the encoding plugin, for the ascii and iso-8859-1 cases.
cotto Infinoid, I'm not seeing any test failures on my i386 Hardy box. 23:50
at r38853
bacek good morning 23:52
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
bacek Who broke my shiny packfile pmc's? :) 23:53
Infinoid I think it's an intermittant gc issue 23:55
bisect blamed a rev that tested perfectly earlier today 23:56
23:56 kid51 joined
bacek ouch... 23:56
Infinoid but it seems to be crashing reliably now
so it seems dependent on time of day or phase of moon
dalek rrot: r38854 | cotto++ | branches/pmc_pct/compilers/pmcc/src/emitter/pmc.pm:
[pmcc] emit an attribute_def string similar to what pmc2c does
 23:57
bacek building svn version of parrot to check 23:58
Infinoid heh, now the same tree is passing again. I didn't rebuild or change anything
maybe it's dependent on how many episodes of robot chicken I watch :) 23:59
bacek Stop watching them!!!
You are breaking parrot!

Powered by Cro and the Raku® Programming Language.

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

Thank you!