Parrot 1.1.0 Released | parrot.org/ | 322 RTs left | Weekly Priority: Remove Deprecated Items
Set by moderator on 6 May 2009.
darbelo cotto: ping 00:02
cotto darbelo, pong 00:03
darbelo With exeptions out of the way I'm starting out with the standalone DecContext pmc. 00:05
I only need one pointer here, should I bother with an ATTR?
"best practice"-wise. 00:06
cotto flip a coin ;) 00:07
darbelo He. I guess ATTRs are better encapsulation. 00:08
cotto Yes, although a good implementation could work either way.
and it'll be easier if you find that you need another ATTR 00:09
chromatic www.mono-project.com/Compacting_GC
darbelo Leaving the ATTR there also means I get to copy-paste from the other file :) 00:10
cotto I wonder what kind of changes Parrot will need to be able to support such a GC. 00:11
btw, I haven't been giving your commits a proper review. I apologize for that. 00:12
chromatic First we need Whiteknight to figure out the proper API.
darbelo No worries. Nothing very interesting to review so far. Just bashing prototypes and getting to know the tools. 00:13
Whiteknight waiting for me to figure something out is futile 00:15
I can only figure at third grade level 00:16
cotto Great! Then we'll have a GC so simple a 3rd-grader can use it. 00:18
darbelo But wouldn't that be generational instead of compacting? ;-) 00:19
chromatic It thinks everyone over 19 is old. 00:20
Whiteknight darbelo: We're lucky that it's even functional, much less "generational" or "compacting" or anything fancy
darbelo Also I don't think compacting 3rd-graders is legal here. 00:21
jonathan chromatic: In what you linked to...
"Moving collector (it can compact the heap)." 00:22
chromatic: I've figured moving collectors won't fly in Parrot because one of the things we promise is that PMCs don't move?
Or am I misunderstanding?
Whiteknight jonathan: We could have PMC headers that don't move, and PMC guts that do 00:23
jonathan Whiteknight: We can, though it limits the scope of what the moving GC can do. 00:24
But yes, good point.
dalek rrot: r38519 | whiteknight++ | trunk/src (2 files):
A basic fix for TT #595. Throw or rethrow on a null PMC or a non-exception PMC should cause a fatal error, instead of random and ungraceful results like we used to have. Probably not an ideal fix, but a basis for later improvements. NotFound++ for ideas
 00:26
chromatic We *could* have moving headers as well... just look at Smalltalk/80 00:31
dalek rrot: r38520 | whiteknight++ | branches/gc_api:
Creating a new branch to do some cleanup work on the GC API
 00:33
Whiteknight chromatic: That would require some major rewrites throughout the codebase 00:35
cotto It's so nice to have a noninteractive RPG. 00:37
darbelo cotto: Huh?
cotto progress quest 00:38
purl progress quest is probably mesmorizing
chromatic I don't think the rewrites would be that bad.
00:38 bacek_ joined
cotto It lets you play an RPG without any of the tedious stuff. 00:39
darbelo Q: But I'll help! 00:41
A: Look deep into your heart, then say that again.
Heh 00:42
jonathan chromatic: Rather you than me. ;-) 00:44
:-)
00:45 bacek joined
jonathan chromatic: Reading that doc more, it seems it is a stop-the-world rather than asynch model too. Of course, so's our current one... 00:47
chromatic I'm not sure what the best model is. 00:48
I think there's a G1 implementation that can run async.
jonathan Aye, there's plenty of models out there... 00:49
I suspect getting something that's somewhat generational would be a win for Parrot over where we are today.
chromatic Yeah, identifying short-lived versus long-lived is very important. 00:54
jonathan OK, sleep time for me...night all. 00:56
00:57 eternaleye joined
dalek rrot: r38521 | whiteknight++ | branches/gc_api (5 files):
[gc_api] start renaming some of the GC API functions to Parrot_gc_*
 01:05
01:14 ilia left
Whiteknight chromatic: I'm convinced now that we can use the Boehm collector if we want to do that 01:40
however, I don't think there's any good way it can be used to guarantee order-of-destruction, like we have on our long-term roadmap 01:41
would probably give us a performance win in the short term, however
01:43 kid51 joined
chromatic Order of destruction only matters because we need to destroy some objects before others. 01:57
Not all... just some.
Also, you missed spaces between if and () in r38519. Coke will be along shortly to rap your knuckles like some great bald manly nun. 01:58
rg chromatic: can you give an example where order of destruction matters? 02:00
chromatic Events. 02:01
The Scheduler has to shut down after the destruction of all events, as they rely on being able to remove themselves from it on their destruction. 02:02
rg thanks 02:03
dalek tracwiki: v12 | cotto++ | ParrotQuotes 02:43
tracwiki: add a couple old quotes I found when looking for something else
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff 02:44
02:47 janus joined
dalek rrot: r38522 | jkeenan++ | trunk/src/ops/core.ops:
Correct violation of c_parens coding standard in three locations.
 03:10
03:11 japhb joined
dalek rrot: r38523 | jkeenan++ | trunk/runtime/parrot/library/P6object.pir:
No trailing whitespace: correction on 4 lines.
 03:13
03:20 donaldh joined
dalek rrot: r38524 | jkeenan++ | trunk/t/codingstd/pdd_format.t:
Rework the 78-char line length restriction in PDDs to permit some long 'F<>' tags to pass.
 03:23
kid51 must sleep 03:26
purl $kid51->sleep(8 * 3600);
04:00 Theory joined 04:17 Theory joined 04:19 autarch joined, autarch left 05:09 bacek joined 05:11 rakudohudson joined 05:16 mikehh joined 05:21 mikehh joined 06:14 uniejo joined 06:16 mikehh joined 07:20 donaldh joined 07:39 iblechbot joined
cotto bacek, ping 08:37
bacek cotto: pong 08:41
cotto the pmc compiler build is broken because pmc.pir thinks some files are in the wrong place 08:42
Should I fix it or do you want to? 08:43
bacek cotto: I'll probably will not have much time till weekend. 08:45
I'm trying to simplify RO handling in PMC... EPIC FAIL. 08:46
cotto I'll take it then. Is the file layout correct or is pmc.pir?
in pmc2c?
bacek lemmecheck 08:48
cotto btw, multiple PMC inheritance is an unintended consequence of the way the pmc2c was written 08:50
I thought you'd like that.
bacek oh shi...
really? 08:51
cotto yes
lemme dig up the reference
rt.perl.org/rt3/Ticket/Display.html...txn-523214 08:52
bacek (pmc.pir) Looks about alright. But if you want you can change it to separate generated files into somewhere else.
cotto So the layout should mirror pmc.pir?
bacek erm... What do you mean? 08:53
bacek just read #48014...
cotto nm. pmc.pir refers to a file that doesn't exist, not one that's been moved 08:55
bacek ah. maybe...
afk # going home.
see you in about 1 hour.
cotto ok 08:56
09:12 masak joined
dalek rrot: r38525 | cotto++ | branches/pmc_pct/config/gen/makefiles/pmc.in:
[pmc] update the makefile template so the compiler builds again
 09:16
09:17 Ademan joined
masak WhiteKnight: ping 09:17
cotto msg bacek nm about the pmc compiler. I committed a fix. 09:29
purl Message for bacek stored.
10:07 bacek joined
cotto wb 10:13
bacek hi again
purl oh, you're back!
dalek rrot: r38526 | bacek++ | branches/tt631_part2:
Second part to TT#631 cleanup - stop putting VTBALE functions into headers
 10:21
rrot: r38527 | cotto++ | branches/pmc_pct/compilers/pmc/src (3 files):
[pmcc] store ATTR info somewhere meaningful
 10:41
10:42 mikehh_ joined
dalek rrot: r38528 | bacek++ | branches/tt631_part2/lib/Parrot/Pmc2c (2 files):
Stop emitting VTABLE functions into header files and declare them static. (Build is broken, because of TT#640
 11:00
rrot: r38529 | bacek++ | branches/tt631_part2/src/pmc_freeze.c:
Don't use default_thaw and default_thawfinish directly.
rrot: r38530 | bacek++ | branches/tt631_part2/lib/Parrot/Pmc2c/PMCEmitter.pm:
Declare vtable-related functions in headers
rrot: r38531 | bacek++ | branches/tt631_part2/lib/Parrot/Pmc2c/PMCEmitter.pm:
Properly emit function signatures.
rrot: r38532 | bacek++ | branches/tt631_part2/src/pmc/object.pmc:
Don't invoke vtable functions by name.
cotto work it! 11:07
purl emulates Rupaul
cotto I'm not entirely sure I want to look that up.
bacek cotto: which part? 11:09
purl which part is confusing?
bacek horray. It compiles! :) 11:13
dalek rrot: r38533 | bacek++ | branches/tt631_part2/src/pmc/integer.pmc:
Don't call vtable function directly.
 11:14
rrot: r38534 | bacek++ | branches/tt631_part2/src/pmc/scalar.pmc:
Don't call vtable functions directly.
bacek Any win32 devs around? (For smoking tt_631_part2 branch)
11:14 Casan joined
cotto I also almost have ATTRs doing something useful. 11:15
bacek cotto: that's good. I'm going to finish TT#631 before jumping back to pmc_pct branch 11:17
cotto +1 to anything that simplifies the pmc compiler
bacek BTW, we probably have to wait till allison's branch for PCC refactoring merged back before implementing METHOD's handling. 11:18
Current implementation is overcomplicated for my small brain...
cotto It's funny how much refactoring this compiler is going to end up depending on. 11:19
bacek "Result: PASS" on my box for tt631_part2.
cotto: but it already proven to be useful :)
11:20 donaldh joined
bacek ok. No win32 devs around... 11:21
bacek wearing T-Shirt with "Better to ask for excuse" phrase. 11:22
I'm going to merge this branch into trunk.
cotto I can make sure someone tests it tomorrow, if you like
bacek Which tomorrow? :)
cotto May 7 11:23
bacek It's already May 7. 9:23 PM
cotto For me it's only 04:23
bacek waves from the future 11:24
cotto asks for lottery numbers
it never works
bacek It's just nature of lottery. You can know numbers, but you never wins
seen jonathan 11:26
purl jonathan was last seen on #parrot 10 hours, 29 minutes and 56 seconds ago, saying: OK, sleep time for me...night all.
cotto 10.5 hours ought to be enough
bacek I hope so. 11:27
jonathan: ping?
pmichaud enough for what? ;-)
bacek for sleep :)
pmichaud well, I should get ready to board my flight... I'm first on the plane today. 11:28
bacek 10.5 hours probably enough to flight from US to Australia. 11:29
jonathan bacek: what're you after? :-) 11:31
bacek jonathan: good morning :) Smoking tt631_part2 branch on most popular operating system
cotto or windows 11:33
;)
bacek I said "popular", not "useful" :) 11:34
Is "make testj" tests JIT? 11:36
moritz only if configured with --jitcapable 11:37
bacek moritz: thanks
jonathan bacek: kinda tied up with something at the moment - will try and get to that soonish for you. 11:38
bacek dreaming about buildbot which will build all branches on set of platforms... 11:39
cotto There are a lot of branches for which testing wouldn't be useful, although a smart buildbot could figure out which ones need testing. 11:40
bacek cotto: indeed... 11:41
purl indubitably
bacek t/op/trans (Wstat: 256 Tests: 22 Failed: 1) 11:43
Failed test: 13
Is it expected to fail in trunk for "make testj"? 11:44
cotto I think you can ignore that one. 11:46
dalek rrot: r38535 | cotto++ | branches/pmc_pct/compilers/pmc/src (2 files):
[pmcc] generate (non-inheriting) ATTR wrapper structs in headers
bacek cotto: Yeah. Just checked. It fails in trunk as well. 11:47
cotto bacek, do you have any objections to me getting pmc_pct updated to trunk later today? 11:48
bacek cotto: no.
cotto ok. I'll do that.
night
jonathan bacek: building
bacek night
jonathan: ok. Thanks! 11:49
11:51 kid51 joined
jonathan bacek: did you want me to test Rakudo against this build also? 11:55
bacek jonathan: yes please. But I didn't expect failures if it builds. 11:56
ouch. My English abilities fading... 11:57
jonathan Beats my abilities in any other language... 12:00
bacek even Perl6? ;) 12:02
12:11 bkuhn joined
Coke yawns. 12:18
kid51 seen smash? 12:20
purl smash was last seen on #parrot 232 days, 17 hours, 42 minutes and 1 seconds ago, saying: hello everyone [Sep 16 18:35:37 2008]
masak famous last words. 12:21
purl Nothing Can Possibly Go Wrong!
bacek jonathan: any progress?
jonathan bacek: parrot make test is has a pass 12:25
bacek horray. I'll commit it. (We can revert it later in case of zombie atta^W^W^W^W) 12:27
bacek taking of T and wearing PJ. 12:28
good night everyone.
dalek rrot: r38536 | bacek++ | trunk (6 files):
Merge tt631_part2 branch into trunk.

used by many people.		 12:29
jonathan gotta go for Slovak class now, will rakudo-test later 12:31
12:37 ruoso joined 12:39 rg1 joined
Coke speaking of zombie attack, I highly recommend the game "Plants vs. Zombies" 12:45
12:54 iblechbot joined 13:00 gryphon joined 13:09 riffraff joined
particle-nyc cute commit message, bacek, but i prefer to see the platform name there somewhere. 13:28
Infinoid uck, and the compiler, they are quite different targets on win32 13:32
hi particle, how's nyc?
particle-nyc nyc is same as it ever was, which is wonderful. hope to enjoy some more of it tonight after work. 13:56
14:18 Theory joined
Coke misses Tir Na Nog. 14:23
14:27 davidfetter joined 14:29 particle1 joined 14:30 particle2 joined
NotFound ./src/pmc/managedstruct.c: In function 'VTABLE* Parrot_ManagedStruct_get_vtable(parrot_interp_t*)': 14:34
./src/pmc/managedstruct.c:1089: error: 'Parrot_UnManagedStruct_update_vtable' was not declared in this scope
Coke just include the header? 14:40
NotFound What header? That function isn't in any header. 14:41
Coke ah. I assumed it was a reference to an explicit vtable on UMS. 15:04
Infinoid yep, ./src/pmc/managedstruct.c:1089: warning: implicit declaration of function 'Parrot_UnManagedStruct_update_vtable' 15:07
NotFound: Let me guess, you're using g++? 15:08
NotFound Infinoid: yes, and for exactly that reason, mainly. To catch 'just warnings'
Infinoid NotFound++
Looks like this came from the tt631_part2 branch merge 15:09
NotFound Silly commint coming...
Infinoid NotFound: I've posted your error message to TT #631 15:14
NotFound Infinoid: I think the error message is not enough, I'll make a commit with all the changes required to make it compile, to be able to find a way to generate and maybe avoid a lot. 15:15
Infinoid well, I think pmc2c just needs to put another couple of prototypes in the pmc_unmanagedstruct.h header it generates 15:16
it generates the function, it should generate the prototype too. 15:17
NotFound Infinoid: unmanagedstruct is just the first file that manifest the problem
Infinoid yeah
NotFound Every pmc with a parent has the same problem, some of them worse
15:20 donaldh joined
nopaste "infinoid" at 75.140.33.106 pasted "test to work around a tt631 warning/error" (17 lines) at nopaste.snit.ch/16492 15:21
Infinoid That fixes the warning for me. Clearly the logic is a little screwy there, but I don't understand what the original intention was. 15:22
NotFound: Are there additional build issues after applying that? 15:23
I think maybe the Default PMC isn't as special a case as the author of that code had thought 15:24
looks like the digest dynpmcs have an additional, similar issue 15:28
NotFound I think this initialization scheme needs some improvement. 15:29
Those update_vtable function return a VTABLE pointer that is never used. 15:31
Infinoid the dynpmc errors need a little more work, but I can commit this first fix 15:32
digest_group.c:75: warning: implicit declaration of function 'Parrot_MD2_class_init'
NotFound And each of those functions calls the update_vtable functions of all his parents. I think will be better that each parent takes care of his own parents. 15:33
Infinoid pmc2c is generating the prototypes for those, but for some reason they're ending up in md2.c rather than pmc_md2.h
Maybe you should post that to the ticket :) 15:34
NotFound Still elaborating the idea...
Infinoid I'm not very good with MI concepts 15:35
But maybe the idea is that only the class knows exactly which parents it inherits from?
NotFound No MI, just grandfathers
For example, Boolean does this: Parrot_scalar_update_vtable(vt); Parrot_Integer_update_vtable(vt); Parrot_Boolean_update_vtable(vt); 15:36
And Boolean doesn't even declare it extends scalar, it extends Integer, and Integer extends scalar 15:37
Coke the class doesn't know, pmc2c knows. 15:38
NotFound And the dependencies of the generated C needs to know
Coke all the inheritance is compile time, there's no lookups going on at runtime.
they used to, no. Is this in trunk you're having this problem? 15:39
dalek rrot: r38537 | Infinoid++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] Fix warnings caused by tt631_part2 branch merge.

This fixes the following warnings:
  ./src/pmc/managedstruct.c:1089: warning: implicit declaration of function 'Parrot_UnManagedStruct_update_vtable'
  ./src/pmc/managedstruct.c:1100: warning: implicit declaration of function 'Parrot_UnManagedStruct_ro_update_vtable'
  (Those warnings turn into errors under a C++ compiler.)
Infinoid Coke: Yeah. Apparently all this became dynamic earlier today
NotFound Well, if they doesn't know is even worse, because the code really depends on it. 15:40
Coke I would, in general, hope that merge backs like that don't increase the build warnings.
NotFound Coke: many times it doesn't because I fix them for c++ build before someone notice ;) 15:41
Infinoid NotFound: What you're saying makes sense to me. Think you can hack it to only emit first-order inheritance? 15:42
Infinoid wonders if this has any ordering dependencies
NotFound If it has, will be good to know now, and fix it.
Infinoid definitely 15:43
NotFound I think I need to drop some const qualifier to fix another problem 15:45
Infinoid I saw that too. Testing a fix for the digest dynpmcs and *_class_init first 15:47
Coke Infinoid: do we need similar changes for dynpmcs?
Infinoid Coke: Yes, working on that. 15:48
Coke (digest) ah, there. danke.
Infinoid if I'm right, the dynpmcs just need a oneliner fix
NotFound: your const issue was in src/multidispatch.c? 15:49
ouch, my oneliner caused lots of "./include/../src/pmc/pmc_sub.h:85: warning: 'Parrot_Sub_assign_pmc' declared 'static' but never defined" warnings 15:50
NotFound Infinoid: yes, this is a symptom of an old problem: several string functions must accept const STRINGs. They don't, and then we can't make const lost of things that ideally must be. 15:51
Infinoid sounds worthy of a ticket, if there isn't already one
NotFound And changing that string functions is difficult, because the charset/encoding functions implied has the same problem. 15:52
Infinoid yeah, it cascades
consting is a nightmare :)
NotFound I'll put a TODO comment in include/parrot/multidispatch.h, and later create a ticket about it. 15:53
Infinoid I'd just create a ticket, we already have enough untracked TODOs
NotFound Infinoid: I dislike to drop a reasonable const qualifier without a comment about the reason. 15:54
Infinoid ah, so you're fixing it at the same time. NotFound++ 15:55
Coke I would rather have const warnings needing fixing than build failures on C++
NotFound Mmmm.... I can create the ticket first, and later edit it to add the release number.
Coke: const warnings *are* failures on C++ 15:56
The ticket will be to find a way to be able to restore the const qualifiers without problems. 15:57
Coke NotFound: blah. 16:00
Infinoid In a way, consting is one thing that really annoys me about C. It's the kind of thing the language really should do for you. 16:04
NotFound I like consting, it helps find errors. But needs a lot of care. 16:05
Infinoid I like the idea of consting, I just don't want to do it manually. When you change a low level function, you have to update 10 layers of APIs, it's a maintenance burden that doesn't scale very well 16:07
NotFound Infinoid: yes, but the better known solution is to always make const the arguments that doesn't need to not be from the beginning. Relaxing them later is easier than enforcing. 16:09
dalek rrot: r38538 | Infinoid++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] Fix more warnings caused by tt631_part2 branch merge.

digest_group.c:75: warning: implicit declaration of function 'Parrot_MD2_class_init'		 16:11
NotFound Infinoid: testing now with this last commit and the multidispatch.h change... 16:13
16:16 iblechbot joined
NotFound It builds :) 16:17
Infinoid Was the multidispatch.h issue triggered somehow by the tt631_part2 merge? 16:18
NotFound I looked at the diff, and looks like the file hasn't change in that commit.
Infinoid msg bacek There was some breakage from your tt631_part2 merge, please see r38537, r38538 and my comments to TT #631. 16:19
purl Message for bacek stored.
NotFound But maybe the functions that uses his members are the culprit.
Infinoid Ok. Either way, I'm glad you're testing this. :) 16:20
NotFound Test pass :) 16:22
Committed 16:25
dalek rrot: r38539 | NotFound++ | trunk/include/parrot/multidispatch.h:
[cage] drop some const qualifiers, TT #646
Infinoid For reference, it looks like those warnings were caused by r38504 16:30
NotFound I'll take a look at it 16:32
Ah, yes, it were char * before 16:33
16:48 whoppix joined 17:00 rdice joined 17:01 tewk joined 17:39 amoc joined
Coke (drop const qualifiers) didn't you say it needed to be MORe consty? 17:44
NotFound Coke: ideally. In the meantime, we want to make it work 17:45
Coke roger. 17:46
NotFound We need to make a lot of functions more consty, in order to be able to have variables and struct menbers const.
Coke seems like that's a decent cage task. "make this const, and then fix everything that breaks' 17:48
NotFound And while we can't make it const, let's not lie to the compiler.
Coke: unfortunately, people tends to "fix" it by adding lots of const casts.
17:50 cognominal joined
NotFound This is funny: we have a function called init_world_once that is called lots of times. 17:52
jonathan lol
NotFound Parrot_platform_init_code is supposed to be called one time for interpreter, or only for the first interpreter? 17:55
Coke msg whiteknight Hey, can we kill the old gsoc branches if you're starting a new one? =-) 17:57
purl Message for whiteknight stored.
17:58 mtk joined 18:00 mtk left 18:11 janus joined 18:48 Andy joined 19:08 darbelo joined
dalek rrot: r38540 | NotFound++ | trunk/src/embed.c:
[cage] drop an unused declaration
 19:15
19:20 donaldh joined 19:24 cognominal joined
dalek kudo: 06e2f1d | jnthn++ | src/parrot/ClassHOW.pir:
When generating parents list, need to stop at Perl 6's Object.
 19:32
kudo: 194b524 | jnthn++ | src/setting/Object.pm:
Fill out the implementation of .WALK such that it passes all of S12-introspection/walk.t.
kudo: 6db88b0 | jnthn++ | t/spectest.data:
Add S12-introspection/walk.t.
19:40 krg joined 19:58 bacek joined
cotto bacek, do you mind if I rename the pmc compiler to pmcc? 20:02
msg bacek Do you mind if I rename the pmc compiler to pmcc? 20:10
purl Message for bacek stored.
tewk perl5 question: is there anyway to modify a my variable at package scope from outside the package? 20:45
PerlJam tewk: er ... yes? what do you mean by "outside the package"? 20:46
tewk: lexicals are orthogonal to packages, so if you said package foo; my $blah = 5; package bar; $blah = 7; that's fine 20:47
20:48 chromatic joined
chromatic The algorithmic performance of CodeString's lineof() method is terrible. 20:48
Infinoid tewk: you can ... yeah, what PerlJam said. Or you can export a reference to it by declaring that reference as "our"
chromatic Rakudo parsing gets a 25% speed improvement by fixing that.
Infinoid tewk: But the guy maintaining your code 3 years from now will stab you.
chromatic (estimated -- I haven't done it yet)
Infinoid Wow, that's huge.
PerlJam chromatic: awww ... I was about to ++ you for the 25% boost :)
chromatic++ anyway for the digging. 20:49
tewk PerlJam: I want to reach into Test::Builder and set $Opened_Testhandles to 0
PerlJam tewk: you can't do that except from within the Test/Builder.pm file itself.
jonathan chromatic: is lineof() called much apart from when there's an error and we need the line number?
PerlJam jonathan: anything that makes rakudo even just a little faster is good in my book :) 20:50
jonathan Oh, for sure. 20:51
purl like totally!
jonathan Especially if it's 25%. ;-)
tewk PerlJam: Yeah thats what I thought.
Infinoid If we can save 25% by improving something that's only used in the error path, we're spending way too much time in the error path. So I think it must be called a lot more often than that 20:52
jonathan aye
Infinoid Oh, aren't annotations set up ahead of time? 20:53
chromatic lineof() gets called 8,442 times when processing actions.pm.
bacek good morning 20:54
Coke chromatic: Codestring was migrated to C from PIR, as I recall. I may even have had a hand in it. I wonder if it would be faster in PIR.
Infinoid morning bacek 20:55
chromatic This part won't be faster in PIR.
Coke PerlJam: (anything that makes it a little faster) that's dangerous, taken to the extremes it was in parrot. 20:57
GeJ Good mornning everyone
Infinoid hi GeJ
Coke I mean, I think we're past the point of premature optimization, but still.
moritz so basically lineof() doesn't do any caching, right? 20:58
chromatic Right. 21:00
I'm adding two "last line number/pos seen" INTVALs as a cache, presuming we always inchworm along the string (given that this is a parser, it's an easy assumption). 21:01
moritz yes, that should account for 90% of all cases with 10% effort, or so ;-) 21:02
bacek Infinoid: (r38537) oops. Sorry.
bacek making note to self - "Disable ccache after merge for checking build"
chromatic At least 90%.
PerlJam Coke: are you saying that chromatic is dangerous? :) 21:03
bacek purl: msg cotto Just rename it.
purl Message for cotto stored.
Infinoid bacek: It's ok. We fixed one of chromatic's breakages at the same time, r38539 :) 21:04
chromatic Sure, it compiles now... but it also compiles faster now too! 21:06
moritz let's ship it! 21:07
cotto ok 21:08
Infinoid bacek: More importantly, did I fix it in the correct way? (I'm not familiar with the changes you were making.) 21:11
bacek Infinoid: not 100%... 21:13
r38542
dalek rrot: r38541 | cotto++ | branches/pmc_pct/compilers/pmc (2 files):
[pmcc] generate PARROT_FOO macro, plus a test for it and the ATTR wrapper struct
 21:14
rrot: r38542 | bacek++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
Don't emit Parrot_default_update_vtable signature into header. We don't have this functions.
Infinoid Oh. So the original check just needed to be inverted 21:15
bacek Yes...
Infinoid Ok, thanks for fixing the fix :) 21:16
bacek ;)
Infinoid++ # Fixing bacek-- silly mistakes :/ 21:19
dalek rrot: r38543 | bacek++ | branches/tt631_part2:
Removed tt631_part2 branch. It was merged and fixed in trunk.
 21:21
21:22 jq joined
bacek cotto: If you'll have time you can remove "parents" Hash in nodes.pir. It should be scalar similar to "class_init". 21:23
cotto bacek, are you thinking that it should be a csv list? We need to support multiple inheritance, even if it wasn't originally intended. 21:28
although I really would like to get that "feature" deprecated 21:31
bacek hm. I'm not sure that such complexity to support multiple inheritance required.
let's "deprecate" it :)
cotto we should at least wait until partcl's working before we kill it again 21:32
jonathan That would really need a deprecation cycle. Accidental or not, it's something people could easily have come to use... 21:33
cotto No, it's something that they *have* come to use.
jonathan Well, there you go then. :-) 21:34
cotto but getting in a deprecation notice now would give them plenty of time to update before 2.0, when it'd be removed
jonathan *nod* 21:35
Infinoid Hmm. if Parrot_Boolean_ro_update_vtable (for example) assigns all the "write" slots in the vtable with functions which throw exceptions, is it valid to assume Parrot_scalar_ro_update_vtable(), Parrot_Integer_ro_update_vtable() and Parrot_Boolean_ro_update_vtable() all do the same thing? if so, it would seem Parrot_Boolean_ro_get_vtable() doesn't have to call all 3 of those, only the last one. 21:40
dalek cnum-dynpmcs: r22 | darbelo++ | trunk/src/pmc/decnum.pmc:
Incorporate suggestions by cotto++ and WWhiteknight++.
bacek Infinoid: indeed. I'm going to refactor _ro_ handling in next branch. tt631_part3. 21:42
darbelo Crap. I mistyped Whiteknight++.
Infinoid: Karma aliases work :) 21:43
cotto That's ok. purl is only smart enough to do one karma change per line
bacek Problem in "src/dynpmc/rotest.pmc". It overrides "get_integer" with ":write" trait :/
darbelo I'll keep that in mind.
Infinoid Cool. NotFound++ mentioned something earlier (see irclog.perlgeek.de/parrot/2009-05-07#i_1126109 ) about update_vtable functions calling eachother recursively, resulting in redundant calls to grandparent methods. But I don't see it - the get_vtable functions call the update_vtable functions, but that all looks fine to me
21:44 Whiteknight joined
NotFound Not redundant, just think it can be done in a cleaner way. 21:45
bacek NotFound: it definitely can.
Infinoid I misunderstood what you said, sorry.
NotFound Is esasy to misunderstand my misenglish ;) 21:46
bacek Actually, we doesn't support multiple inheritance of PMC. So update_vtable/get_vtable can be merged into one. 21:47
derived_get_vtable() { VTABLE * vt = parent_get_vtable(); ... ; return vt }; 21:48
dalek rrot: r38544 | whiteknight++ | branches/gc_api (8 files):
[gc_api] rename add_pmc_ext and add_pmc_sync to Parrot_gc_*
 22:03
22:05 chromatic joined
dalek rrot: r38545 | whiteknight++ | branches/gc_api/src/gc/api.c:
[gc_api] Throw exceptions to uniformly handle cases where a memory allocation has failed
 22:10
22:10 allison joined
dalek rrot: r38546 | whiteknight++ | branches/gc_api/src/gc/pools.c:
[gc_api] change sized pools so they can allocate objects of size sizeof(void*) and up, where they previously couldn't allocate objects smaller then sizeof(Buffer)
 22:17
22:23 hudnix joined
dalek cnum-dynpmcs: r23 | darbelo++ | trunk/Configure.pl:
Remove an unused option from Configure.pl
 22:39
22:39 kid51 joined 22:41 chromatic joined 22:42 Whiteknight joined 22:45 allison joined
dalek rrot: r38547 | chromatic++ | trunk/src/pmc/codestring.pmc:
[PMC] Added simple line number caching to CodeString PMC to avoid repeatedly

5.96%.		 22:46
rrot: r38548 | cotto++ | trunk/CREDITS:
[CREDITS] add dalek alias for cotto
rrot: r38549 | whiteknight++ | branches/gc_api/src/gc (2 files):
[gc_api] Add some comments about how to eventually allocate Sync objects from the memory pools. Uncommenting those things causes a segfault, but I'm not dealing with that right now.
 22:56
22:58 tetragon joined
chromatic Hm. Isn't "I'll deal with segfaults later" what causes problems with so many branches? 22:59
23:11 darbelo joined
kid51 Does anyone know how the HTML version of our PDDs is generated? 23:15
darbelo make html?
purl make html is Geekneeus's next step :D
rg make html?
purl make html is, like, Geekneeus's next step :D
kid51 Yeah, but is there something a bit more focused I can use to test a small segment of POD? (Am looking at trac.parrot.org/parrot/ticket/634) 23:17
I don't understand what this line in Makefile means: html : html.dummy 23:18
rg not that i could find. it's basically one big script that generates the whole set including index pages 23:19
kid51 ... and in any event, what I really want is a Perl program I can use to test patches quickly.
darbelo pod2html?
purl pod2html is broken on &s or a subroutine of Pod::Html or the main source of warnings garbage in me logs or obsidianrook.com/devnotes/pod-html-summary.html
kid51 purl, forget pod2html 23:20
purl kid51: I forgot pod2html
rg and it needs to be the html version? otherwise perldoc should do fine.
23:20 donaldh joined
kid51 Well, for that particular TT, we need to see what's rendered in HTML. 23:20
rg i guess the makefile rule is so that it can be switched between html.stub and html.dummy depending on whether configure was able to find perldoc. 23:21
kid51 For other 'make' targets, I know what Perl, shell, or c programs are being invoked by the target.
rg huh? look at the Makefile in docs 23:22
kid51 But in none of the docs* or html* targets do I see a program invoked.
dalek rrot: r38550 | cotto++ | branches/pmc_pct (0 files):
[pmcc] start renaming pmc compiler to pmcc
 23:23
kid51 So it's a *different* Makefile?
rg the main Makefile just invokes make html in docs
yes
kid51 k
Whiteknight chromatic: The thing that causes segfaults is a change that I haven't made yet
it's like a "wishlist item" that I made a personal note do implement later 23:24
kid51 This looks more promising:
html: all
$(PERL) -I../lib ../tools/docs/write_docs.pl --silent --version=$(VERSION)
rg that's the one.
chromatic Okay good. 23:25
dalek rrot: r38551 | whiteknight++ | branches/gc_api (6 files):
[gc_api] rename new_string_header to Parrot_gc_new_string_header
 23:26
Whiteknight chromatic: I've learned my lesson on that point. Learned it but good.
a few more credits till I graduate from chromatics programming school of hard knocks
23:28 eternaleye joined
dalek rrot: r38552 | whiteknight++ | branches/gc_api/src/gc/api.c:
[gc_api] throw an exception when we cannot allocate a new string, and fix some other error messages that I blindly copypasta'd earlier
 23:29
rrot: r38553 | cotto++ | trunk/config/gen/makefiles/root.in:
[pmc] add a missing makefile dependency
 23:32
rrot: r38554 | whiteknight++ | branches/gc_api/src/gc/api.c:
[gc_api] delete unused function new_buffer_header
rrot: r38555 | cotto++ | branches/pmc_pct (10 files):
[pmcc] finish renaming pmc compiler to pmcc, fix references to changed files, etc
 23:39
rrot: r38556 | whiteknight++ | branches/gc_api (3 files):
[gc_api] rename new_bufferlike_header to Parrot_gc_new_bufferlike_header
 23:42
cotto merging is fun 23:47
and by fun I mean slow
chromatic and by slow you mean "Wow, that glacier cut me off!" 23:48
dalek rrot: r38557 | whiteknight++ | branches/gc_api/src/gc/api.c:
[gc_api] add a small comment note about how buffer-like headers are only used in one place right now apparently, and we might be able to repurpose the concept for something else later
 23:49
Whiteknight I'm finding some weird stuff with the PObj_sysmem flag 23:54
23:59 Andy 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!