Parrot 2.0.0 "Inevitable" released! | parrot.org | Priorities: deprecated core PMCs, ops -> dynops, GC tuning and implementation | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 2 February 2010.
00:02 s1n joined, s1n left 00:03 ash_ joined
plobsing who should I talk to about parrot's opengl bindings? 00:13
darbelo japhb, IIRC
plobsing seen japhb?
purl japhb was last seen on #parrot 3 days, 1 hours, 16 minutes and 14 seconds ago, saying: darbelo, used by the Perl 5 embedding somehow (Blizkost)? Though I would have assumed that would be handled by the Blizkost config/make [Feb 5 22:57:16 2010]
dukeleto plobsing: what do you want to know? 00:25
plobsing whether the signatures generated by config/gen/opengl.pm vary or are constant. 00:26
because I want to move to a static call_list and src/nci.c
darbelo plobsing: IIRC those are generated based on local headers. 00:27
They can vary from place to place. 00:28
plobsing yes, that's what I thought, but then there's a list of signatures in the file
so I'm not sure
maybe I should shift around my planned actions and make opengl a testbed for my dynamic nci thunk libraries idea 00:33
00:36 hicx174 joined
bacek_at_work o hai 00:40
Whiteknight hai
bacek_at_work Whiteknight, you are bloody pervert! Why did you create such PMC???
:)
cotto_w0rk bacek_at_work, it's not even done yet. 00:41
clock?
purl cotto_w0rk: LAX: Mon 4:41pm PST / CHI: Mon 6:41pm CST / NYC: Mon 7:41pm EST / LON: Tue 12:41am GMT / BER: Tue 1:41am CET / IND: Tue 6:11am IST / TOK: Tue 9:41am JST / SYD: Tue 11:41am EST /
00:46 abqar joined 01:05 abqar_ joined 01:26 eternaleye joined
Whiteknight bacek_at_work: it's a debugging and analysis tool 01:33
01:38 mikehh joined 01:40 solarion joined
bacek_at_work Whiteknight, like pathoanatomist's tools? 01:46
Whiteknight never heard of them
bacek_at_work Did you see "True Lies" movie? 01:47
Austin What pmc is this? 01:48
bacek_at_work github.com/Whiteknight/parrot-hacke...mchack.pmc 01:51
Whiteknight Austin: I'm trying to conjure pure evil 01:52
Austin And doing a fine job, I'm sure.
cotto good evening 01:54
purl Ah, evening. The tumultuous mind tarries and contemplates, reveling in the silence afforded by the diurnal proletariat. Good evening, indeed.
02:23 hicx174 joined
japhb plobsing: the OpenGL config step tries to wrap as many library functions as it can (basically, what current Parrot NCI can handle). It keeps track of all the unique signatures it came across while parsing the GL* headers, and adds them to the call_list. On any given platform, with any given release of the headers, it will appear unchanging. But upgrade your GL headers, or go to another platform, and the list will be different. 02:35
And, as I said, it will currently be incomplete because there are a number of signatures that current Parrot NCI just can't handle.
cotto NotFound, c++ build should be happy now. 02:40
(well, g++)
dalek rrot: r43788 | cotto++ | trunk (2 files):
[ops2c] fix the C++ build and use enums instead of chars
 02:42
Austin Hey, is there going to be a PVMW @ YAPC this year? (If not, will there be a PVMW not @ YAPC?)
Austin I think in the future we should schedule the PVMW with the super bowl, but in some other city. There's gotta be a discount for that. 02:44
cotto I axed about that earlier and didn't get a good answer. It'd be a good #ps question.
Austin I'll ask the list 02:45
02:50 kid51 joined
dalek rrot: r43789 | coke++ | branches/rm_cflags:
Remove CFLAGS script.
 02:59
cotto Austin, particle can check/verify that your CLA has arrived. Coke and chromatic can give you your secret decoder ring. 03:02
s/and/or
Austin Coke already acknowledged getting the .pdf. He said something about a parrotsketch meeting being required. (Tho I have no idea why.) 03:03
03:03 leto joined
cotto Ok. iirc you have to be proposed and seconded by at least two committers. 03:04
Coke t/pmc/packfile.t is failing in trunk. 03:07
Austin Nobody uses that anyway.
Here's a little bit of joy: I'm passing a list of parameters to a function (actually, lines in an array). I'd like to commingle the parameters with logic, selecting which lines to pass. How to do that in P6? 03:10
dalek TT #1393 closed by jkeenan++: src/gc/api.c: Intermittent test failures at line 245 since r43211 03:11
eternaleye (backlogging) Coke: Fluxx on Parrot would be epic, especially if it was networked multiplayer. Although, since cards mutate the rules, it might be tough adding expansions like Zombie Fluxx without changing core code. 03:13
cotto Coke, what platform are you on?
Austin Whiteknight has developed a PMC that should support that. 03:14
cotto make test is fine on my box
dalek rrot: r43790 | coke++ | branches/rm_cflags (4 files):
Remove cc_flags.pl

Build is now straight $(CC) - no intermediate perl script. Windows users should see a speedup (if it builds). Build just got a lot more verbose.
  (half from warnings, half from actually showing the build line.)		 03:15
Coke cotto: in general, linux. 03:21
why?
eternaleye: yes, presumably you'd have to code against any potential rules changer. 03:24
cotto Coke, I'm not seeing any test failures in trunk.
Coke cotto: this is on timtowtdi 03:25
eternaleye Austin: Can you do up some pseudocode? I'm not sure I understand what you want to do
Austin I got nothing for ya. You mentioned changing core code, and Whiteknight has a PMC that exposes far more of the core than is really safe. 03:26
eternaleye Austin: I meant your commingling params and logic thing
Coke anyone here on windows?
eternaleye And I meant core game logic of a Fluxx game on parrot 03:27
Austin oh. Sorry. Yeah, I'll nopaste something.
Coke something non-strawberry preferred, but I'll take that (wondering about rm_cflags branch)
nopaste "Austin" at 68.37.46.53 pasted "commingling parameters and logic" (8 lines) at nopaste.snit.ch/19520 03:28
cotto For Fluxx you'd probably end up implementing a VM for which the cards would contain various bits of code to modify gameplay. 03:29
Austin The point being that I only want to emit the debug code if $debug is on
cotto For 1000 Blank White Cards, good luck. ;)
03:35 janus joined
treed Someone should play a version of nomic where the object is to print the text "$name wins" or something 03:37
everyone takes turns making commits that have to be approved by the other players.
or that makes it crash or something 03:38
maybe that would make coders better at knowing what makes crashes happen
eternaleye Austin: ( $debug ?? "\\t" ~ "say \\"Fetching attribute: '$attr'\\"" !! Nil ) 03:42
Austin Hmm. What's Nil?
purl somebody said Nil was generally completely equivalent to '()
Austin Thanks purl. But I don't know what that means.
eternaleye Undef in item context, empty list in list context
kid51 is not getting any failure in trunk on t/pmc/packfile.t: Linux/i386, r43790 03:43
Austin So in a parameter list, it simply goes away?
eternaleye Hm, might not
Maybe if you did Array.new( |( ( ...yourargs... ).grep: !*.notdef ) ) - that should work as long as you have no intended undefs in the args 03:45
Somewhat hacky, though 03:46
The reason for the convolution is that I'm not sure if Nil would be in item context (and thus an undef value) or list context (and thus fall away)
kid51 holds his breath waiting to see if this smolder report will be reported back properly 03:47
eternaleye Because it'd be Array.new( 'foo', 'bar', ( $debug ?? 'baz' !! Nil ), 'quux' ), and that comma after the ??!! bit might be enought to make an entry in the array 03:48
TimToady_: ^^^ Thoughts? 03:49
kid51 rm_cflags branch: make test: PASS on Linux/i386
eternaleye Austin: What you really seem to be in need of is a macro, but those are NYI 03:50
Austin :$
kid51 Well, it took about 3 minutes, but both of those smolders were reported properly. 03:51
rm_cflags branch: smolder.plusthree.com/app/projects/...ails/32113
Austin Maybe just making the 3ary test a flattening list? *( $debug ?? 'baz' !! Nil)
kid51 as expected, output of 'make' in rm_cflags branch is ~3.5 times more verbose than in trunk 03:52
dalek rrot: r43791 | jkeenan++ | trunk/lib/Parrot/Ops2c/Utils.pm:
[codingstd] Eliminate trailing whitespace.
 04:04
rrot: r43792 | jkeenan++ | branches/rm_cflags/lib/Parrot/Ops2c/Utils.pm:
[codingstd] Eliminate trailing whitespace.
Austin Is there a way in parrot-nqp to specify a value for Parrot's "-L" flag? 04:11
(The obvious, parrot-nqp -Llibrary foo.nqp, doesn't work.) 04:12
04:12 kurahaupo1 joined
Austin Howdy, kura. 04:12
Tene Austin: no, there is not. 04:16
plobsing Austin: I think you can poke it through the parrotinterpreter pmc
Tene Right, but there are no recognized arguments to parrot-nqp that do that. 04:17
Austin I feel a ticket coming on...
plobsing Tene: is this because HLLs can't see PIR constants? 04:18
Tene plobsing: No, that's not related at all.
Austin plobsing: we're talking about command line arguments
plobsing oh, I thought you wanted to change the library path 04:19
Austin I do.
Tene he wants to change it by providing command-lie arguments to the 'parrot-nqp' binary.
Austin But I was asking about a way to do it via the CLI to parrot-nqp
parrot-nqp -Llibrary foo.nqp
CLASSPATH=$HOME/parrot/classes parrot-nqp foo.nqp 04:20
or something
purl i heard something was really wrong out there :)
eternaleye CLASSPATH would be a less-than-awesome name for that variable 04:22
Austin And that's a less-than-awesome way to implement searching, too. 04:23
eternaleye Unless you _like_ breaking Java horribly
Austin The Cranberries.
purl the cranberries are native to the New World, I think. Can you even grow cranberries in the UK?
dalek TT #1429 created by Austin_Hastings++: Add -L support to parrot-nqp 04:34
04:44 mikehh joined
kurahaupo1 Austin: howdy. 04:45
kurahaupo1 has hands in guts of disassembled computer, hoping to add more RAM.
05:13 petdance joined 05:48 mikehh_ joined
Austin w00t. Kakapo = bad-ass. 05:49
05:56 mikehh_ joined
dalek rrot: r43793 | coke++ | branches/rm_cflags/config/gen/makefiles (2 files):
restore 2 of the CFLAGS directives in the makefile itself.
 05:59
06:02 kurahaupo joined
dalek rrot: r43794 | coke++ | branches/rm_cflags/config/gen/makefiles/CFLAGS.in:
This file generates no warnings as is. don't need this anymore.
 06:15
cotto svn-- 06:25
because reverting to an old revision and updating again shouldn't require manual intervention
06:27 jan joined
dalek rrot: r43795 | coke++ | branches/rm_cflags/config/gen/makefiles/root.in:
re-order and fix these makefile deps (unbreak build)
 06:31
Austin What kind of error is a call to an abstract method? 06:36
cotto "don't do that" 06:38
purl "don't do that" is, like, a perfectly valid workaround :)
Austin Illegal Operation? 06:39
That's where I'm at now.
cotto I guess that'd work. 06:40
Austin class Exception::AbstractMethodCalled\tis Exception::IllegalOperation;
dalek rrot: r43796 | coke++ | branches/rm_cflags/config/gen/makefiles/CFLAGS.in:
These files are warnings-clean in the default build.
 06:49
Austin Mmmm...the severity and type are both integer values. 06:50
That's the kind of excellent documentation we expect from Parrot docs.
cotto We'll get you a commit bit tomorrow. After that you can fix it yourself. ;) 06:54
Austin snicker
Is there a cool tool for checking config settings from the command line? 06:55
cotto ./parrot_config 06:56
Is that what you were thinking of? 06:58
Austin Yes, exactly. Cotto++
Sadly, exception info is not configured.
Is there a way to generate an isotone integer given a PMC? 07:00
The exception types appear to be just an enum.
Any new exceptions won't have types unless there is some kind of registry.
cotto That's a weakness of the current system. 07:02
Austin Ahh! I'm turning into Max Headroom...
make test-test-testcase
dalek rrot: r43797 | petdance++ | trunk/src/call/args.c:
consting and localizing local vars
 07:05
Austin Ahh, my old nemesis: C3 linearization. 07:08
Of course it's an ambiguous hierarchy - it's a straight line.
How's pbc_merge, cotto? 07:09
cotto Your patch and my fix seem to have made it usable. 07:11
Austin Woo-hoo. What did you fix?
cotto I just copy/pasted the extra case to another switch in the same function.
Austin Oh. 07:12
I thought you were doing a rewrite or something.
(the way you were talking the other day, I expected a commit entry with "rm pbc_merge.c" in it...)
cotto I was going to until I saw that you figured out an easier way to make it work. 07:13
Austin laugh
What's next on your plate?
cotto ops_pct
Austin What's that?
purl that is the case, but I don't know
cotto the pct-based ops compiler to replace ops2c 07:14
Austin Ahh. 07:15
I don't suppose you'd like to figure out why C3 doesn't work? 07:16
cotto I figure I can at least get the upgrade tax paid before I get distracted by the next shiny thing,
Austin Laugh!
07:18 uniejo joined
cotto and the award for lamest placement of an exclamation mark in an error message goes to... 07:19
"Class Compiler already registered!"
Austin sings, "I'm the root of all that's evil - yeah - but you can call me 'cookie.'" 07:20
NotFound cotto++ Build fine and pass tests. 07:21
cotto and now we use advanced techniques like "enums" instead of casting to/from char 07:22
Austin You know, I just saw a History Channel show on "1980's tech" 07:23
They didn't mention enums, though.
NotFound feeling old
07:38 eternaleye joined
Austin Okay, I think I just visually found a bug. 07:39
cotto where 07:44
Austin Nopaste coming
nopaste "Austin" at 68.37.46.53 pasted "Register allocation bug, or just a TRACE problem?" (32 lines) at nopaste.snit.ch/19521 07:45
Austin Or perhaps not.
nopaste "cotto" at 96.26.227.153 pasted "HLLCompiler is making me confused" (15 lines) at nopaste.snit.ch/19522 07:48
Austin Interestingly, cotto, the Parrot_oo_register_type function, which throws that message, is checking a parameter called _namespace to see if the class already exists. 07:56
cotto It smells like a bug in the HLLCompiler code. 07:58
cotto wishes pmichaud were here to confirm/deny
Austin deny
Pmichaud's code contains no bugs that can be found by humans. 07:59
It says so on the label.
cotto sleep 08:04
Austin FWIW, the autogenerated stuff doesn't just use HLLCompiler
It loads PCT.pbc or some such. 08:05
But yeah, there's a bug down there someplace.
I tried adding a .namespace with a sub in it, but it still breaks.
08:08 iblechbot joined 08:18 fperrad joined
Austin Aww, crap. 08:27
The problem with finding bugs is writing the steps to reproduce.
dalek TT #1430 created by Austin_Hastings++: Change trace offset numbers to hex format 08:29
08:47 bacek joined 08:49 barney joined
Austin Hey, bacek: does pbc_dump work right when dumping the constants table (specifically, keys)? 09:05
09:05 jhelwig_ joined
bacek Austin, yes afaik 09:05
Austin ticket coming 09:06
bacek patches welcome!
purl patches welcome is always true
Austin tt#1431 09:07
dalek TT #1431 created by Austin_Hastings++: Register assigned to .local string variable is mis-remembered 09:19
09:33 eternaleye joined 09:54 mikehh joined 09:58 lucian joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32117), fulltest) at r43797 - Ubuntu 9.10 amd64 (gcc with --optimize) 10:28
bacek mikehh, merge coming
mikehh it tested ok for me 10:29
the part1 goody 10:30
bacek exactly :)
r43798
bacek offer cheap karma for removing gc_encapsulate_part1 branch from svn 10:31
mikehh ok 10:34
dalek rrot: r43798 | bacek++ | trunk (10 files):
Merge branch gc_encapsulate_part1 back to trunk.
 10:39
rrot: r43799 | bacek++ | branches/gc_encapsulate_part2:
Second part of GC encapsulation
10:48 eternaleye_ joined 10:53 mikehh joined
dalek rrot: r43800 | mikehh++ | branches/gc_encapsulate_part1:
branch merged so remove it
 10:55
rrot: r43801 | bacek++ | branches/gc_encapsulate_part2/src/gc (2 files):
Move pool intialization into gc_ms.c from api.c
rrot: r43802 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Encapsulate allocate_pmc_header
rrot: r43803 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Encapsulate free_pmc_header
rrot: r43804 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Encapsulate allocate/free string headers
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32118), fulltest) at r43804 - Ubuntu 9.10 amd64 (g++ with --optimize) 11:05
11:11 schmalbe joined 11:34 kid51 joined
kid51 rm_cflags branch: PASS at r43804: smolder.plusthree.com/app/projects/...ails/32120 11:50
Austin Hey, kid51 - looks like you'll be getting some real snow this time. 12:01
12:21 cognominal joined 12:24 bluescreen joined 12:30 ruoso joined
dalek rrot: r43805 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Encapsulate allocation/deallocation of attributes and fixed size storage
 12:33
rrot: r43806 | bacek++ | branches/gc_encapsulate_part2/src/gc/gc_ms.c:
Rename gc_ms_finalize to gc_ms_finalize_memory_pools
12:48 plobsing joined
dalek rrot: r43807 | bacek++ | branches/gc_encapsulate_part2 (5 files):
Move pools destruction functions in alloc_resources.c
 12:50
rrot: r43808 | bacek++ | branches/gc_encapsulate_part2/src (3 files):
Encapsulate GC finalization little bit more. Properly implement MS GC
purl i think finalize is not enough
12:57 bluescreen joined 13:03 kvorg joined
kid51 Austin: I grew up in Rochester and went to college in Buffalo. By my standards: New York City *never* gets real snow. 13:04
dalek rrot: r43809 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Encapsulate allocating of buffer and string storage
 13:06
rrot: r43810 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Factor out merge_memory_pools function to decouple merging of Interp
kid51 to $job 13:16
13:24 whiteknight joined
whiteknight good morning #parrot 13:27
13:36 payload joined
bacek aloha whiteknight 13:39
whiteknight did gc_encapsulate_part1 merge?
bacek whiteknight, yes 13:40
loooong time ago
dalek rrot: r43811 | bacek++ | branches/gc_encapsulate_part2 (6 files):
Encapsulate destruction of child interpreter
 13:55
rrot: r43812 | bacek++ | branches/gc_encapsulate_part2 (5 files):
Encapsulate allocate/free bufferlike headers
rrot: r43813 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Encapsulate block/unblock/test mark and sweep. Implement total_unblock in terms of is_blocked/unblock
14:00 Essobi joined
whiteknight I can't keep track 14:08
bacek whiteknight, of what? 14:09
whiteknight of branches merging 14:10
Coke bacek: (long time ago) you mean yesterday?
whiteknight that is a long time, in bacek-time
bacek Coke, yes. At least in my timezone. 14:11
Coke will hopefully have rm_cflags in by the weekend.
(if not tomorrow.)
uh, do we have any platform on which using backwhacks in the makefile is required? 14:15
sorry, backslashes. (as part of file paths) 14:16
I ask again, do we have anyone building on windows that is NOT using strawberry or cygwin? 14:18
bacek Coke, TapTinder? 14:20
Coke TapTinder?
purl TapTinder is software development tool - taptinder.org . For Parrot project running on tt.perl6.cz/ and reporting build failures to #parrot channel as ttbot.
Coke bacek: I see no way there to say "show me the windows" 14:21
bacek declaring victory
Coke, tt.ro.vutbr.cz/file/cmdout/191037.txt
this is "client 5" 14:22
bacek@icering:~/src/parrot$ ack -c 'interp->mem' src/ -r|grep -v ':0'
src/gc/gc_ms.c:63
ooookey
Coke ... ok. I can't see having to drill down into the report to say "what client are you", and also: ... that's strawberry perl.
bacek There is no references to interp->mem_pools left in sources apart from gc_ms.c!
mj41, ping 14:23
Coke bacek: try ack -clQ 'interp->mem' src
mj41 bacek, pong
bacek mj41, Coke want some strange windows build :)
Coke, thanks for ack. Same results :) 14:24
Coke yes, but I saved you a pipe!
mj41 have strawberry perl and cygwin machines online
bacek smoking pipe saved by Coke 14:25
Coke Right. I'm looking for the "real" windows build.
(using the MS compilers)
rm_cflags branch fails on strawberry now because the makefile is all foo\\bar instead of foo/bar 14:26
(that is only tangentially related to my desire to have someone using MS compiler to test.)
dalek rrot: r43814 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Add get_gc_info introspection function.
 14:28
rrot: r43815 | bacek++ | branches/gc_encapsulate_part2/src/gc (2 files):
Move calculation of active/total buffers into gc_ms.c
rrot: r43816 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Encapsulate mark_special. It's wrong way because we have to move whole mark_FOO_alive into gc_ms. But it's good enough for now
rrot: r43817 | bacek++ | branches/gc_encapsulate_part2/src/gc (3 files):
Encapsulate pmc_needs_early_collection
mj41 we have copy of cygwin wm machine somewhere 14:33
Coke ... cygwin is also not the MS compiler.
(I have cygwin here too if I need it.)
mj41 I can make MS from this one 14:34
Do you want to test trunk or any branch? 14:35
whiteknight Anybody around here knowledgable about packfiles? 14:39
Coke only that that test is failing. =-)
whiteknight I'm trying to figure out what the status of the packfile PMCs is, and what is preventing them from being used in Parrot to manage bytecode?
Coke mj41: I'm going to need MS feedback on the rm_cflags branch (though it's not 100% yet) 14:40
bacek whiteknight, nothing
Coke having that to compare to trunk would be nice.
whiteknight bacek: so all that is required is to create a branch and make the switch-over?
bacek whiteknight, yes (almost)
whiteknight ...almost?
bacek whiteknight, currently Packfile PMCs are wrapper around PackFile_foo functions 14:42
They weren't build for "on-line" usage in runtime. 14:43
Main purpose was able to unpack/create/pack PBCs
check examples/pir/make_hello_pbc.pir if you want
whiteknight so what is the design? Are we going to use those PMCs internally to work with packfiles or not? 14:44
bacek we can 14:45
But it will require some adjustments
whiteknight lots of possibilities, but any firm decisions?
bacek And VTABLEs are way too narrow...
whiteknight Adjustments are fine. The whole subsystem needs refactors and fixes
bacek Yeah... Do you mean cleanup with fire? 14:46
Coke can we rip out the #if 0 code in src/runcore/main?
whiteknight Coke: let me look
bacek: yes, cleanup with fire
and encapsulating things into PMCs is a good first start 14:47
Coke whiteknight: if not, no matter, I can shove more in the if 0 black hole in the branch.
bacek whiteknight, than I want to highly recommend again to change PBCs to be truly "portable". And have single format, not zillion of combinations. 14:48
whiteknight Coke: Probably need to leave it for now. CG and CGP cores are slightly fragile and I don't want to remove code we might rely on later
Coke bacek: but the unachieved theoretical runtime efficiency! =-)
bacek Coke, Yay! :)
Coke whiteknight: technically the code is already removed, but ok. I'll keep branch changes minimal.
(that's a good plan regardless) 14:49
whiteknight bacek: yes, I agree with that. I'm looking for good GSoC project ideas
Coke: I mostly want to keep the ideas around, in case we need to make use of them again
Alternatively, delete the code but make a ticket referencing the commit
14:50 lucian joined
whiteknight a portable bytecode format would be awesome. Properly encapsulating bytecode into PMCs would be awesome too 14:51
brb 14:52
14:56 whiteknight joined 14:58 iblechbot joined
Coke rant: having a warning disabled by default and enabling only on certain files is backwards. 14:58
whiteknight which warning?
Coke unused.
whiteknight and why would it be disabled by default?
Coke whiteknight: ... I can't speak to why. 14:59
whiteknight enable it everywhere
Coke whiteknight: ... did you see my rant? =-)
whiteknight I'm enabling!
14:59 cognominal joined
Coke rm_cflags will enable it by default then shut it off for the files where it is hard to fix. 15:00
(and fix it for the rest of the files, since mostly it's just deleting old crap.)
whiteknight "hard to fix" is a challenge, not something to just ignore
Coke whiteknight: you're welcome to challenge yourself, sure.
whiteknight enable the warning by default, we'll clean it before the next release 15:01
Coke I'm going to enable it by default and then disable it on those files that `need` it. easy enough to re-enable it for the file you wish to try to clean. (the hard ones are the generated ops files) 15:02
particle pay attention to the buildbot output
Coke Parrot_compile_string has an unused variable, 'pf'. except it looks like it is not supposed to be unused. anyone? 15:05
whiteknight ah, generated code files might be good candidates to turn that warning off then 15:06
but all "real" code files should have it
NotFound whiteknight: I started a test of dumping pbc using pacfile pmc but not finished it. Extending that tests for reading and writing will be a good way to make sure the PMC are able to do al the work. But in order to do some realistic writing test we need some way to assemble parrot opcodes from HLL. 15:08
whiteknight in other news, some of our code generators should get a lot smarter
NotFound: so something like an op or pmc that can compile a single op to a string of bytecode? 15:09
NotFound whiteknight: I'd like better something that takes an op name and the number and type of parameters and return the opcode number. Even better, other that takes just the name and return an array of variants. 15:13
whiteknight NotFound: so an OpLib PMC that provides PIR-level access to the op list?
including lookup and compilation? 15:14
NotFound whiteknight: PMC, interpreter method, keyed access.... anything.
whiteknight actually a series of ops might be better, less call overhead and more flexibility
I will prototype some ops like that for testing
NotFound I don't care about speed, at least for the first attempts. 15:15
whiteknight ok
Coke ... Andy++ 15:16
Andy for?
purl for is *only* foreach, because c-style for is "loop"
Andy Or do you mean Armstrong?
Coke (just found and removed several useless string creations that were in loops in parrot argument processing.)
Andy haha, awesome!
Coke (which would have been found if this (*&@#$# arg was enabled by default, which it soon will be.) 15:17
whiteknight an OpLib PMC with a get_integer_keyed_string (for specific op variant lookup) and get_pmc_keyed_string (returns a hash of all variants, signature -> opnumber) would work
dalek rrot: r43818 | coke++ | branches/rm_cflags/config/auto/warnings.pm:
CFLAGS enables this for some files, but it's off by default.

necessary, disable it where we have to.
NotFound whiteknight: I think so. At least will be enough for proof of concept tests. 15:19
whiteknight ok 15:20
NotFound Oh, and for the reading part, getting the name and signature from the opcode number will also be useful. 15:21
15:24 bubaflub joined, Psyche^ joined
whiteknight so an Opcode PMC type also might be interesting, that contains lots of info about one op 15:26
NotFound Yeah 15:27
whiteknight an OpLib PMC that provides access to the entire library and returns Opcode PMCs on keyed lookups 15:29
NotFound whiteknight: sounds great 15:30
whiteknight and Opcode.get_string_keyed() could return the compiled bytecode of that statement
NotFound May be helpful, at least for non-jump ops. 15:32
whiteknight yeah, the jump ops get more tricky
dalek rrot: r43819 | coke++ | branches/rm_cflags/src (9 files):
Eliminate some unused variables and static functions.

  - might be worth a benchmark on trunk.		 15:33
rrot: r43820 | whiteknight++ | branches/op_pmcs:
branch to prototype some new PMCs for working with ops
 15:50
moritz public service announcement: the timtowtdi.org server is going to be unavailable to us starting from next week (Coke, japhb, kj have accounts there) 15:56
whiteknight what is that server?
moritz (oh, forgot leto) 15:57
whiteknight: leto did some benchmarking on it, Coke some smoke testing, some others did some web hosting
whiteknight ok
16:00 bubaflub joined 16:01 theory joined, NotFound joined 16:09 payload joined 16:14 whiteknight joined
Austin_away Why, oh why, does C3 not work? 16:15
whiteknight it does work, if you ignore all the bugs and the fact that it doesnt work 16:16
Austin Yeah. Aside from that. 16:17
What? You have two classes with a common ancestor? And you want to make one a parent of the other? No, that's ambiguous. Sorry. 16:19
Coke moritz: it's going away permanently? 16:20
moritz Coke: probably 16:21
Coke thank you for the heads up.
whiteknight Austin: is that an issue with the C3 algorithm, or just our implementation of it? 16:24
Austin It seems like a safe bet that it's an implementation issue. See tt#1426 16:25
whiteknight ok 16:32
mj41 Coke I setup machine with MS VC++ 2008, nmake on rm_cflags ok, now running nmake test 16:42
Coke Result: PASS 16:47
16:49 hercynium joined 16:54 whiteknight joined 16:57 Themeruta joined 17:06 mikehh joined
mj41 TapTinder machine 13 (WinXP, Visual Studio 2008 Express Editions, ActivePerl) added. 17:11
Coke mj41: huh. freaks me out that strawberry is failing but VC++ works. 17:14
danke.
Coke shuts off the lights on timtowtdi 17:20
(at least in my room) 17:21
17:23 whiteknight joined
dalek rrot: r43821 | coke++ | branches/rm_cflags/src (2 files):
Remove more unused code.
 17:28
17:42 plobsing joined
dalek rrot: r43822 | whiteknight++ | branches/op_pmcs/src/pmc (3 files):
Add initial prototypes of three new PMCs with some quick TODO notes
 17:44
17:48 mikehh_ joined
whiteknight I really want to clean up the src/pmc.c file 18:06
Renaming functions from e.g pmc_new() to Parrot_pmc_new(), etc 18:07
Coke Should this function (pcf_v_(PARROT_INTERP, PMC *self) 18:11
actually be generated, or is that an undef leaking through?
(src/nci.c)
18:13 kurahaupo joined 18:17 mj41 joined 18:21 payload joined, plobsing joined 18:26 Psyche^ joined 18:31 cotto_w0rk joined 18:32 Psyche^ joined 18:43 PacoLinux joined
dalek rrot: r43823 | plobsing++ | trunk/tools/build/nativecall.pir:
use a global variable instead of threading a parameter through all calls in the program just for one use-site
 18:51
18:55 ruoso joined 18:56 allison joined
Coke allison: hio 19:03
allison: did you see the src/call/ change in branch? I wonder if that was a time sink.
allison hi 19:04
Coke (branches/rm_cflags)
allison didn't see it yet, will take a look
Coke r43819 19:05
Coke wonders why ICC is adding warnings to the build. 19:07
allison looks good, clearing out some variables we don't need (especially avoiding creating constant strings we don't need)
dalek rrot: r43824 | plobsing++ | trunk/tools/build/nativecall.pir:
add some command line options to nativecall.pir (currently mostly unimplemented)
 19:08
Coke allison: and those were in loops. whee.
allison excellent
Coke this'll get merged back in a few days.
cotto_work allison, is trac.parrot.org/parrot/ticket/866 on your list of things to eventually address? whiteknight had some feedback. 19:09
NotFound I have my Basic interpreter running in the Nokia N900 :) Parrot coming soon, I hope.
whiteknight Sorry about the length of the comments. 19:10
allison cotto: his arguments are sound, I'm okay with eliminating pow
cotto_work ok. Do you feel the same way about bignum? 19:11
allison cotto: it basically comes down to "how common will it be to override the behavior?" and with pow it's uncommon
cotto: it could be argued that any PMC that wants to return a bignum should return it as a PMC anyway 19:12
cotto_work agreed 19:13
(I'm for taking out both bignum and pow, fwiw)
allison cotto: so set_pmc, get_pmc, are sufficient
(I'm reading back over the history of the conversation)
cotto: okay, I'll reverse the earlier comment, we can nuke both pow and bignum 19:16
cotto_work Glad to hear it.
allison cotto: but, that's an important point about "where to draw the line" 19:17
cotto_work Thanks for looking at the ticket.
allison cotto: if we remove pow, are there other common math ops we should also remove from the vtable?
whiteknight I'm a little bit of a VTABLE minimalist, but I won't push the conversation any further than the obviously under-used ones 19:18
allison the discussion might become more relevant with lorito
whiteknight ...despite my obvious dislike of having both a complete set of math ops and i_* math ops which are almost always identical
allison (with a minimalist op set, the monolithic vtable set is less useful)
whiteknight: and all the variants for all the different types 19:19
whiteknight I like the idea of fast vtable-based access to certain operations, but I can distinctly tell there was a "the more, the merrier" attitude earlier in Parrot's history and the ramifications of that were not thought out ahead of time 19:20
of course, I wasn't present for most of Parrot's history, so I really can't say what the attitudes towards these kinds of things used to be 19:23
allison without benchmarks, we really can't say for sure whether vtable-based access is all that much of a speed advantage 19:25
whiteknight over, for instance METHOD calls, we have to assume they are 19:26
allison yes, there was definitely an early philosophy of "the more the merrier"
yes, faster than method calls
though, the old method calls were a simple function pointer invoke, so not actually much slower
whiteknight what are the other alternatives, direct ATTR access? 19:27
allison it depends on the situation
when it's not actually custom behaviour, and external op can be equally good
like, math behavior that really should be consistent
you run into some complexity with deciding if the behavior should be int-like or float-like 19:28
whiteknight but that could easily be decided with a flag
allison (we don't really have a way of making that decision externally at the moment)
whiteknight or a role
allison or with an attribute of the PMC that the op checks 19:29
whiteknight although that's a bit of a shoehorn
VTABLE_get_math_mode()
allison aye, and that's part of why so many of the math ops are vtable functions
it's a clean implementation of polymorphism 19:30
whiteknight so in theory, if we had a way for a pmc to declare how it was handled in a scalar math operation, most of the vtable logic could be moved to consistent ops?
allison yes, definitely
and most of the math ops could be moved to dynops too 19:31
whiteknight you're making my mouth water
I'm a big proponent of a "lean and mean" parrot
but that's no secret
allison It's the direction we're heading now 19:32
it is a break from they earlier design philosophy, but a good one, I think 19:33
whiteknight I strongly agree. Decreasing memory footprint, decreasing the number of thigns to be initialized at startup, removing components that are not frequently used, these are all good things
allison speed has always been one of Parrot's goals, so in a sense we're just tackling a key goal from another angle 19:37
19:42 cognominal joined
Coke chromatic has burst my bubble. ah well. 19:51
19:51 eternaleye joined
Coke makes the mistake of looking in config/auto/warnings 20:02
20:07 lucian joined 20:08 kurahaupo joined, mikehh joined 20:09 lucian joined
dalek rrot: r43825 | chromatic++ | trunk/lib/Parrot/Harness/DefaultTests.pm:
[lib] Made t/src/*.t run before other extended core tests, to make parallel

starting it earlier allows further time overlapping.		 20:13
20:23 joeri joined, chromatic joined
GeJ Good morning everyone 20:26
whiteknight good morning GeJ
how is life in paradise today?
GeJ Heya whiteknight. 20:27
purl whiteknight is, like, mailto:wknight8111@gmail.com or the grand master funk or wknight8111.blogspot.com/
chromatic #ps in 4
whiteknight almost forgot 20:29
dalek rrot: r43826 | mikehh++ | trunk/tools/build/nativecall.pir:
fix codetest failure - trailing whitespace
 20:30
whiteknight is reading through hundreds of lines of code at work, where the original author only used comments as a substitute for the delete key
no english-language explanations of things, but hundreds of lines of inexplicably commented-out code 20:31
GeJ whiteknight: It's ok. Weather's fine. Job's okay. The only remaining problem is that days are only 24 hours long. I'm working on this, but I don't have any obvious solution yet. Still investigating. 20:32
Tene whiteknight: but what if he needed to get the deleted code back some time in the future?!?!
whiteknight GeJ: How much snow do you have there? We have two feet of it on the ground, and another 1.5 feet coming tonight
GeJ whiteknight: How's life treating you in... erm... your side of the globe? (I'd say east coast, but I'm not quite sure) 20:33
whiteknight Tene: I know! It's the ultimate version control system
GeJ whiteknight: snow? You mean that white thing that people seem to enjoy 3 weeks every 4 years on the TV? Yeah, we've heard about it. It could be an urban legend though. 20:34
whiteknight lucky bastard 20:35
GeJ Don't know if that's been said here, but FreeBSD 7.3 will ship with a Parrot 2.0 and Rakudo 2010.01 20:36
Coke huh. 20:37
allison GeJ: excellent
whiteknight GeJ: Great 20:38
GeJ I have nothing to do about it. I just saw the two ports a couple of days ago. 20:40
20:40 cognominal joined, kurahaupo joined
GeJ The guilty one is Aliaksandr Zahatski. Don't know if he's idling around here. 20:42
20:44 hercynium joined
allison Coke: technically the deprecation was for get_bigint and set_bigint, which don't exist 20:45
Coke: is there a rule for deprecation typos? 20:46
20:46 kurahaupo1 joined
dalek rrot: r43827 | whiteknight++ | branches/vtable_massacre:
creating branch to rip out deprecated vtables bitwise*, *pow*, and *bignum
 20:46
Coke .. don't do that?
Coke allison: it looks like DEPRECATED.pod mostly agrees with the most recent ruling, so I'll close my eyes. 20:47
moderator Parrot 2.0.0 "Inevitable" released! | parrot.org | Priorities: merge branches, remove deprecations | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs 20:47
chromatic trac.parrot.org/parrot/wiki/GCSizeTuning -- implementation ideas for a GC tuning 20:47
whiteknight chromatic: looks nice. should run the GC more frequently but with smaller runs 20:49
chromatic Hopefully it runs the GC less frequently. 20:50
dalek tracwiki: v1 | chromatic++ | GCSizeTuning 20:56
tracwiki: trac.parrot.org/parrot/wiki/GCSizeT...ction=diff
chromatic whiteknight, what do you want to do with these deprecations? Want to break them up into individual pieces? 20:58
Coke if anyone wants to hack on rm_cflags, I can carveout some tasks. 20:59
whiteknight chromatic: however. I was planning to go all scorched earth, but if there are other people with their hands in the branch we probably need to be more polite 21:00
chromatic Goes faster with more hands.
bacek Good morning 21:03
purl What's so good about it?
whiteknight First step is probably to update the bitwise and pow ops to call get_int and get_float vtables. Then rip out the unused vtables, then fix all broken tests
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32128), fulltest) at r43826 - Ubuntu 9.10 amd64 (gcc with --optimize) 21:04
bacek I've got small task for bored developer.
chromatic whiteknight, if you make a small wiki page like we did for the CC revamp, we can coordinate there. 21:05
bacek Cut CLI param parsing out of IMCC and do it _before_ init of Interp.
whiteknight okay. I'm getting in my car nowish, but I'll put together the page in 1hr when I get hom
bacek It will be very helpful with run-time GC selection 21:06
chromatic Excellent.
Coke bacek; also with pirc switch.
whiteknight bacek: I've wanted that same thing for a while 21:07
21:13 payload joined, plobsing joined
NotFound cotto_work: ping 21:13
cotto_work NotFound, pong 21:14
NotFound cotto_work: can we close TT #1428? 21:15
cotto_work lemme look
definitely 21:16
NotFound cotto_work: can you add some comment about the fix?
cotto_work Sure. I'll take care of it.
NotFound cotto_work++ 21:17
chromatic msg whiteknight trac.parrot.org/parrot/wiki/GCSweep...ementation
purl Message for whiteknight stored.
chromatic Also bacek: trac.parrot.org/parrot/wiki/GCSweep...ementation
There's the algorithm whiteknight and I have tossed around for a while.
mikehh bacek: gc_encapsulate_part2 - make corevm/make coretest, make test PASS - some codetest failures (working on it) and make: ./pbc_merge: Command not found 21:19
bacek chromatic, it's exactly how previous Gen GC was implemented 21:27
dalek TT #1428 closed by cotto++: pbc_merge breaks c++ build 21:28
chromatic Is that good, bad, neutral, charm, or strange?
bacek chromatic, it's more good than bad
chromatic That's a positive sign. 21:29
How much more GC encapsulation work do you have? Do you have more branches in mind?
bacek chromatic, it's done
next branch - Boehm GC again 21:30
dalek tracwiki: v1 | chromatic++ | GCSweepFreeImplementation
tracwiki: trac.parrot.org/parrot/wiki/GCSweep...ction=diff
chromatic Okay, I'll wait for the merge and then work on this.
bacek chromatic, ok. 21:31
21:32 mikehh joined
dalek rrot: r43828 | mikehh++ | branches/gc_encapsulate_part2/src/gc/gc_ms.c:
fix codetest failures - linelength and trailing spaces
 21:36
rrot: r43829 | mikehh++ | branches/gc_encapsulate_part2/src/gc/gc_ms.c:
fix codetest failure - at least one space between C keyword and subsequent open parenthesis
rrot: r43830 | mikehh++ | branches/gc_encapsulate_part2/src/gc/api.c:
fix codetest failure - at least one space between C keyword and subsequent open parenthesis
21:44 mikehh joined
darbelo purl: msg Austin You may redeem this purl-o-gram for an enchanted +1 Bit of Commiting. Contact Coke for more details. 21:46
purl Message for austin stored.
cotto_work mikehh, the gc branch looks fine apart from some codingstd failures. I don't see any problem with pbc_merge. 21:52
21:52 mikehh_ joined
dalek rrot: r43831 | mikehh++ | branches/gc_encapsulate_part2/src/gc/gc_private.h:
fix codetest failure - at least one space between C keyword and subsequent open parenthesis
 21:53
cotto_work mikehh, the gc branch looks fine apart from some codingstd failures (possibly the ones you just fixed). I don't see any problem with pbc_merge.
Coke darbelo: he already has the commit bit, and he should be talking to whiteknight, not me. =-) 22:01
</deniability> 22:02
darbelo Coke: Oops. Sorry. 22:03
22:04 mikehh__ joined
darbelo purl: msg Austin Oops, I meant Whiteknight, not Coke. Also, your bit is now active. Don't break the build. Increase the awesome. 22:05
purl Message for austin stored.
22:08 mikehh joined
Coke note: new commiters first commit email may be delayed by gremlins. be patient. 22:08
darbelo gremlins-- 22:09
dalek rrot: r43832 | mikehh++ | branches/gc_encapsulate_part2/src/gc/gc_ms.c:
fix codetest failures - unused assert macros
mikehh I am still getting a codetest failure for assert args in src/gc/gc_private.h that I fixed in r43832 for gc_ms.c but make headerizer does not work for me 22:25
that's in gc_encapsulate_part2 branch 22:27
cotto_work not quite fixed. There's an extra "Parrot_" in front of some of the assert_arg macros.
mikehh cotto_work: I thought I fixed those 22:33
22:35 mikehh joined
cotto_work mikehh, there are still some in src/gc/gc_ms.c 22:36
mikehh cotto_work: ok I see them 22:39
22:41 kiwichris joined 22:43 plobsing joined
tewk MMD question, I defined is_equal in PMC A, but not in PMC B, ne A B works but ne B A throws a exception from DefaultPMC. do I have to re define is_equals in B too? 22:45
chromatic Sadly, I believe so 22:46
We don't have a mechanism to identify commutative MMD.
For "commutative" read whichever mathematical word means "reflexive", perhaps. I'm in writer mode, not math mode.
tewk uggh, code duplication
darbelo Would making default try "the other way around" help any? 22:47
Avoiding the obvious infinite recursion, clearly.
tewk YES, As long as we all agree that is_equal is reflexive 22:48
chromatic Or we have some mechanism to mark some candidates as such.
tewk sounds like pmc2c fun :) 22:49
and MMD dispatch work too.
22:51 cotto_work joined
NotFound BTW, i think that PMCNULL is equal to PMCNULL 22:55
darbelo It shouldn't be?
cotto_work You make a good argument.
NotFound Should be, but current code doesn't think so. 22:56
darbelo Ouch. 22:58
dalek rrot: r43833 | plobsing++ | trunk/tools/build/nativecall.pir:
implement head, thunks, loader, coda, and all targets as well as restrict the loader function to loading thunks and nothing else
23:01 mikehh_ joined
darbelo You know, having a VTABLE be always implemented in terms of other VTABLEs is a good sign you can delete safely. 23:03
cotto_work are you thinking of the i versions? 23:04
23:04 Whiteknight joined
darbelo Nope, get_bignum(), I've just killed it. Running make test before commiting. 23:04
cotto_work darbelo++ 23:05
I won't miss that one at all. 23:06
Make sure to take it out of src/vtable.tbl too.
darbelo Yeah, did that.
Incoming! 23:08
purl duck!
cotto_work Urgh. _vtable on x64 is 1968B. 23:09
Whiteknight urg
23:09 mikehh_ joined
chromatic At least x64 has more registers. 23:10
Whiteknight chromatic++ #sweepless gc algorithm 23:11
cotto_work looks like some of the vcgc ideas got in there 23:12
chromatic I don't see any big holes in the idea.
Whiteknight cotto_work: exactly
darbelo I just looked it over and it sounds almost generational.
chromatic It's not quite generational, but it requires very few changes. 23:13
Whiteknight generational uses a similar idea to reduce the mark set
this is the same idea on the sweep set
chromatic We can keep the current precise system without having to track down every place we store a GCable to put guards around it.
darbelo I like it.
Whiteknight ours is hardly precise (*cough&src/gc/system.c*cough*)
darbelo pokes dalek with a stick. 23:15
dalek rrot: r43834 | plobsing++ | branches/nativecall_pir_build:
branch takes wrong approach to solving the problem
rrot: r43835 | darbelo++ | branches/vtable_massacre (9 files):
Remove the get_bignum() VTABLE.
chromatic It's mostly precise; we don't use a lot of the C stack and we don't have to trace much of it.
darbelo In the interst of full disclosure, r43835 should be tested by someone who has GMP installed. 23:16
I can't test Integer->BigInt autopromotion on my box. 23:17
Whiteknight I need to install GMP 23:18
darbelo I also disagree with Integer->BigInt autopromotion, but that's a mostly unrelated phenomenon.
Whiteknight +1
purl 1
Whiteknight Parrot should make fewer assumptions about the behavior of HLLs 23:19
23:21 kurahaupo joined 23:28 eternaleye joined
Coke (assumptions), well it has to work /some way/ in parrot. if there's a way that involves less work on our part that is overridable, go for it. 23:35
23:40 hercynium joined 23:44 kurahaupo joined 23:48 mikehh_ joined 23:50 mikehh joined 23:56 lucian 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!