www.parrot.org | planet.parrot.org | 1.4.0 | Feature Freeze: No big changes before the 1.5.0 release | Current Focus: TESTING!
Set by moderator on 17 August 2009.
Coke allison: will the PCC rewiring branch, in addition to sunshine and puppies, provide reduced memory usage? 00:04
dalek rrot: r40610 | allison++ | branches/pcc_arg_unify/src/debug.c:
[pcc] Add some safety features to PDB_backtrace so it can't get stuck in

the backtrace.		 00:05
allison Coke: the current refactor won't, but it lays the groundwork for more refactors later that could
00:05 patspam joined
Whiteknight yes, lots of delicious groundwork 00:05
allison: you have an ETA for the current branch? 00:06
allison Coke: mainly want to get it working and merged for now
Coke yes please.
Whiteknight allison: and I hate to keep asking, but is their anything that the peasantry can do to help? 00:07
allison Whiteknight: I'm over the hump now, the conversions are done and I'm just debugging test failures (which have mainly turned out to be a few lines of changes scattered here and there)
Whiteknight: I'm down to 374 'coretest' failures
Whiteknight oh only 374? That's a solid hour worth of work :)
allison Whiteknight: and most of those seem to be caused by one failure in Test::Builder (which means all the PIR test files fail) 00:08
Whiteknight: :) Yeah, I can't really give a time, because it's all debugging, but we're close anyway.
Whiteknight okay. I seriously don't mean to nag or harass, I'm just very excited by the whole thing :) 00:09
allison :) that's okay
Coke OOOH, can I nag? =-)
allison it's not really a big deal of a branch, but the excitement is appreciated anyway :) 00:10
Coke actually, allison is (I think) the only architect or pumpking I haven't pissed off.
allison lol :)
Coke goes off to play _inFamous_ while this spectest run churns. 00:12
00:12 kid51 joined 00:14 rdice joined
dalek rrot: r40611 | allison++ | branches/pcc_arg_unify/src/hash.c:
[pcc] Convert an impossibly horrible assert to a condition. This means

shouldn't ever be turned off.		 00:15
rrot: r40612 | allison++ | branches/pcc_arg_unify/src/scheduler.c:
[pcc] Conversion that didn't apply in the patch from the 'pcc_rewiring'
 00:25
00:27 davidfetter joined
l3t0 i have been keeping the mirror of all of our current svn branches up to date on github, in case anybody cares: github.com/leto/parrot/tree/master 00:29
00:38 ruoso joined
Whiteknight I'm always struck by how much easier it would have been to implement some of these systems "the right way" the first time instead of having to go through and fix them in place 00:38
00:38 michaelnussbaum08 joined
Whiteknight of course, you don't know what is "the right way" until you've already screwed it up the first time, so we are at an impasse 00:38
chromatic Encapsulation is always the right way, at least for a first approximation. 00:42
Whiteknight okay, then whoever wrote some of these things originally did it the wrong way, at least for a first approximation 00:45
but now we're the master reapproximatos 00:46
that's spanish for reapproximators
I also have an acute overabundance of self-importance 00:48
Coke a historically non-rare commodity in the project. 00:50
chromatic Self-importance or the wrong way?
Coke first one... 00:51
purl first one is often the best one
treed Hm. 00:52
Coke some of the tests which ABEND in the partcl spec suite seem to do so randomly. PITA.
treed Would it be reasonably to have Parrot-space methods that are not presented to users of a given HLL?
s/ably/able/
Coke yes.
er.
treed And what would be the best way to achieve that? Just keep a separate list of user-space methods?
Coke do you literally mean "methods on objects", or just "things in other namespaces" ?
treed I mean methods on objects. 00:53
Coke yes, it would be reasonable, but I know of no way to do it.
treed In particular, I'm running into a problem where I don't want parrot:Integer's methods visible to users of cardinal;Integer
Coke if it were tcl, i'd probably name the HLL methods "&method", and leave the parrot ones with no prefix.
so if someone tried to invoke "foo.blah", I'd rewrite it to "foo.&blah" 00:54
or something equally evil.
treed I'm considering an array of HLL methods.
Including renaming.
The particular issue here is parrot;Integer.to_int
Coke treed: as long as "find_method" works for the HLL, I suppose it doesn't matter.
treed cardinal;Integer must not have a method by that name.
"find_method" is an opcode?
treed has been trying to figure out how method calling happens 00:55
er
s/Integer/String/g
Having a to_int method in Ruby indicates that the object can be treated as if it were an int.
(Whereas to_i is the explicit conversion method.) 00:56
Whiteknight treed: find_method is an opcode, and I think there is a VTABLE that does that too
Coke the method name collision is definitely a potential issue. I don't hink parrot has a standard way for avoiding it.
Whiteknight so you can override the find_method VTABLE and just return PMCNULL for to_int
Coke the C++-like name mangling seems easiest.
Whiteknight BLASPHEMY!
Coke METHOD not VTABLE
Whiteknight Coke: right, override the VTABLE that finds the methods, and then only find the ones you want 00:57
treed nods.
Now, does that affect within-parrot as well as HLL usage though?
Coke that almost seems sane. bet you a dollar it doesn't work. =-)
yes. 00:58
treed Because I'd prefer to leave within-parrot stuff accessible.
Coke treed: but arguably that isn't a problem.
why?
treed Because sometimes you need a given method or whatever to interact properly with the rest of the system.
I guess those are vtables.
So I could leave them unnamed.
Coke treed: yes. 00:59
but arguably, if your PMC shouldn't be an int, it should NEVER be an int. no?
but you can decide whether to override the vtables, too.
Whiteknight goodnight all
treed Coke: Well, there are other vtables as well. 01:01
Things that return a parrot bool (ie, an integer), rather than a cardinal bool.
The two are not compatible.
Unless I make a get_integer vtable on TrueClass and FalseClass.
(Maybe?)
And I don't want those vtables polluting the Ruby namespaces. 01:02
Coke vtables aren't in the namespace.
at least, they should not be.
methods yes, vtables no.
treed .sub 'foo' :method :vtable('get_whatever')
That's not usable as a method?
Coke sure.
but you're deliberately exposing that vtable as a method. 01:03
treed So you don't need to in order for it to work as a vtable?
Coke if you don't want the vtable in the namespace, don't use :method
treed Cardinal has no cases that I know of where :vtable is used but :method is not.
And it'll still work for that object?
Coke vtables don't need to be methods. Yes.
treed And the vtable sub can still use self?
Coke if not, it's a bug. 01:04
treed Huh, neat.
Coke (i hesitate to say anything works.)
treed nods.
That'll make things a little easier, I think. 01:05
Now, the other issue with to_int is that I still need access to it, so I don't want to just disable it outright. 01:06
I need to call it from to_i.
Coke you don't invoke vtables directly, you have opcodes for that.
so if you need the get_integer vtable, you say ".local int foo; foo = myObj"
treed Is there an opcode for to_int? 01:07
Also, is find_method where I'd handle MRO? 01:08
dalek rtcl: r591 | coke++ | trunk/docs/spectest- (2 files):
update spec test after latest run.
mikehh Coke: should I run make spectest again in partcl? 01:20
well giving it a try anyway (and logging it) 01:32
01:36 dukeleto joined
dukeleto 'ello 01:44
is there anything that needs to be done for the release tomorrow? 01:45
chromatic Fix all bugs?
dukeleto chromatic: Yes, please. Let me know when you are done :) 01:46
does anybody need last minute testing/etc ?
it would be nice to fix this: trac.parrot.org/parrot/ticket/930 01:49
chromatic Does quoting paths help? 01:51
dukeleto chromatic: sure, until someone puts a double quote in their directory name :) 01:52
chromatic File::Spec to the rescue. 01:53
dukeleto it is getting a bit close to the release to start fiddling with how the makefile is generated 01:54
we should at least add a note somewhere about the issue 01:55
mikehh dukeleto: I had a look at this - how does this effect makes other than gnu make 02:00
I know that there are problems with quoting in gnu make but what about nmake and others 02:02
02:03 Andy joined
nopaste "chromatic" at 72.87.39.97 pasted "Escape freaky characters in checkout directory (TT #930)" (20 lines) at nopaste.snit.ch/17576 02:05
02:05 japhb joined 02:14 Andy joined
kid51 Well, this release is shaping up to be ... boring! 02:15
kid51 observes a faint smile crossing chromatic's face
02:16 nathanmccauley joined
dalek rdinal: c34fa18 | treed++ | build/Makefile.in:
Cause the Makefile to use the rakefile for testing.
 02:23
02:31 hercynium_ joined 02:36 janus joined
Coke anyone interested in helping with some bug admin for partcl? 02:42
dukeleto Coke: what kind of yak shaving does that entail? 02:43
Coke at partcl.googlecode.com, opening tickets for spec tests that don't run to completion.
(mainly the ones skipped due to segfaults, and then putting the ticket information back in the list of failing tests.) 02:44
code.google.com/p/partcl/wiki/SpecTestStatus
{Spider Robinson}++ 02:45
dukeleto mikehh: i am not quite sure about how the various flavors of make are effected 02:48
mikehh Coke: I got 7 of those which exited with !! child died with signal 11, without coredump 02:49
02:49 nathanmccauley joined
Coke mikehh: yah, I have trouble keeping track of which ones are failing and which are not; it would be helpful if you could open tickets for those which failed that way so we can start doing a better job tracking. 02:50
mikehh dukeleto: we should try the patch by chromatic++ (after the release)
Coke something like "lindex.test does not run to completion", or something. 02:51
dukeleto mikehh: i am trying it now, but I agree about waiting until after the release to commit it
mikehh: since that is not something that is tested or easy to write a test for
mikehh dukeleto: we need to get the windows bunch and other platforms to try it 02:52
Coke bah. for finding segfaults, non-optimized parrot is better. 02:55
mikehh Coke: append, appendComp, cmdIL, compExpr-old, expr-old, format, set-old 02:57
kid51 mustg sleep 02:58
kid51 must sleep
purl $kid51->sleep(8 * 3600);
mikehh ok I got cardinal to build and test
I couldn't get lua to build
Coke mikehh: did cmdIL generate a line that looks like: 03:03
cmdIL.test: Total 122 Passed 71 Skipped 3 Failed 48
if not, what test did it stop on? (my last run for that file, it completed, but exited with value 1)
03:05 nathanmccauley joined
Coke bah. lsearch.test fails in an optimized parrot, but not in a regular parrot. 03:05
mikehh Coke: no it ran ++++ cmdIL-1.29 PASSED, !! child died with signal 11, without coredump then Skipping t_tcl/cmdInfo.test: see code.google.com/p/partcl/wiki/SpecTestStatus
Coke: the log file is 19729 lines 03:07
Coke I can eliminate some of that; I've been printing out PASSED and SKIPPED when the regular tcl suite doesn't.
I can probably remove that now.
mikehh It allows you to keep track - if you output to a log file 03:08
I used make spectest 2>&1 | tee spectest.591.40606.log 03:09
03:12 nathanmccauley joined
mikehh I am using konsole with unlimited scrollback and at the moment 15 tabs in 2 windows :-} 03:13
it's taking 585.7 MiB of virtual memory, but only 37.2 MiB of actual memory 03:16
anyway I need to get some sleep - I have to take my grandsons to school in about 4 or so hours - bbl 03:19
dukeleto chromatic: parrot compiles and tests successfully with your patch when I have the a space in the path (on OSX) 03:32
cotto yay for last-minute patching! 03:46
03:54 mikehh_ joined
dukeleto chromatic: i attached a patch and note to trac.parrot.org/parrot/ticket/930, I think we should test on a few more platforms to be sure 03:57
cotto dukeleto, I'll test it on Linux/x86. That's a rare platform, right? 03:59
dukeleto cotto: like a striped zebra 04:00
cotto dukeleto, so if the build works, the patch is good? 04:06
dukeleto cotto: pretty much, although I rant the full test suite as well since I am paranoid
cotto I'll call it good then. 04:07
dukeleto cotto: should we test it on more platforms or commit it? i just don't know what the policy on last minute commits is 04:08
mikehh: can you test the patch at trac.parrot.org/parrot/ticket/930 on windows?
cotto this also gives me a good chance to see how email2trac works 04:09
chromatic The bug's been around for a long, long time; no rush to apply the patch before the release. 04:10
I'd rather leave a known problem existing than risk a regression here.
dukeleto chromatic: my thoughts exactly 04:12
cotto This is great. every time I sit down to figure out Continuations and CPS I can feel myself getting closer to understanding them. 04:27
chromatic fork() creates a continuation.
cotto in its own limited way 04:29
dukeleto a continuation is kind of like git for the history of the state of execution of the program. you can reset to any intermediate state and act on and modify that state. or something like that 04:31
dalek rtcl: r592 | coke++ | trunk/runtime/builtin/namespace.pir:
Fix usage for [namespace code ...]
 04:39
rtcl: r593 | coke++ | trunk/runtime/builtin/info.pir:
Make [info commands] work on namespaces.
rtcl: r594 | coke++ | trunk/runtime/builtin/info.pir:
die with a proper tcl error.
05:20 cotto joined
Coke yay. I actually committing things that pass more tests, instead of avoiding deprecations or doing refactors. 05:47
"committed"
dalek rtcl: r595 | coke++ | trunk/runtime/builtin/namespace.pir:
fix [namespace children] for namespaces other than tcl's root.
 05:49
06:10 uniejo_ joined
dalek rrot: r40613 | allison++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] The value of PARROT_ARG_INTVAL is '0', so can't use a simple truth

variable to mark when the argument has been set instead.		 06:18
chromatic Ah. Renumbering that enum wouldn't work. 06:20
dalek TT #932 created by dukeleto++: Warnings in compiling bignum.pmc 06:23
rtcl: r596 | coke++ | trunk/runtime/builtin/info.pir:
improve [info vars]/[info globals] when used inside a child namespace
 06:44
06:47 HG` joined
dalek rtcl: r597 | coke++ | trunk/runtime/builtin/namespace.pir:
fix [namespace qualifiers x]
 06:54
06:59 nathanmccauley joined
dalek kudo: 5a2aeaf | moritz++ | (17 files):
remove some trailing whitespaces
 07:01
bacek_at_work moritz: do you use vim or emacs? 07:05
07:05 mokurai left
moritz bacek_at_work: vim 07:05
nopaste "bacek" at 211.29.157.151 pasted "small vim enhancement for moritz" (5 lines) at nopaste.snit.ch/17578 07:06
bacek_at_work moritz: just stick into .vimrc. It will highlight a lot of trailing spaces in rakudo :)
moritz bacek_at_work: I know; most of them are due to jonathan's editor, whatever it is 07:07
bacek_at_work suspect VC... 07:08
moritz something along these lines, yes 07:09
bacek_at_work returning back to $dayjob duties 07:10
08:11 sjn joined 08:33 chromatic joined 08:54 ComLock joined 08:59 masak joined
NotFound notfound.posterous.com/autoattrs-branch 09:35
09:36 jrtayloriv joined 09:39 jrtayloriv joined
moritz NotFound++ 10:19
10:19 bacek joined
bacek o hai 10:44
seen whiteknight 10:48
purl whiteknight was last seen on #parrot 9 hours, 49 minutes and 9 seconds ago, saying: goodnight all
bacek time to wake up... 10:49
rrot: r40610 | bacek++ | trunk (27 files)
merge context_pmc2 branch into trunk
 10:55
dalek rrot: r40614 | bacek++ | branches/context_pmc2/include/parrot/register.h:
Fix macros from previous commits
 11:16
bacek msg whiteknight I jumped on context_pmc2 train^W branch. I really want it done.
purl Message for whiteknight stored.
bacek msg whiteknight I'm going to convert Parrot_Context structure in the same way as I did for Parrot_sub. Hold your breath for couple of hours 11:19
purl Message for whiteknight stored.
moritz holding breath for a couple of hours is likely mortal. 11:20
bacek scratching his shiny metal ass. 11:21
O RLY? :) 11:22
11:45 kid51 joined
kid51 'make fulltest' passed all tests on Darwin/PPC at r40612 and on Linux/i386 at r40607 11:46
11:47 Whiteknight joined
moritz now let's merge some branches... :-) 11:48
kid51 ... uh, we haven't released yet, correct? 11:51
moritz right, that's why there was a smiley at the end :-) 11:52
11:56 quek joined
bacek wiping out smile from his face and run "git merge; git svn dcommit" 11:56
Whiteknight no release yet 12:08
soon, I hope
bacek: ping 12:09
bacek Whiteknight: pong
Whiteknight bacek: that branch is not a trainwreck!
bacek It will be! 12:10
At least I already wrecked it locally :)
Whiteknight oh, okay
well feel free to do whatever you want to it, I'm busy with other things today
And I still don't have a good name for the release either, so I have to make something up quick! 12:11
bacek Thats good. No one will stop me on my evil path to conquer the world!
Whiteknight it's really not so evil 12:12
bacek It is! 12:13
bacek evilly laughing
kid51 Ah, but is it *encapsulated* evil?
bacek Yes. In this universe.
kid51 goes to $job 12:17
12:21 payload joined
bacek Whiteknight: bah... Parrot_Context, Parrot_sub and Parrot_cont are closely coupled... 12:24
dalek TT #933 created by gerd++: building NQP on ppc stops with 'Segmentation fault' 12:25
12:26 szabgab joined
bacek msg Whiteknight I'll continue breaking context_pmc2 tomorrow right after merging tt795 branch to trunk and trunk to context_pmc2. 12:33
purl Message for whiteknight stored.
Whiteknight okay, awesome 12:34
Could everybody take a look at NEWS after r40615 and please update it? 12:35
dalek rrot: r40615 | whiteknight++ | trunk/NEWS:
Add NEWS entry for 1.5.0
Whiteknight anybody around on 32-bit linux? 12:51
dalek rrot: r40616 | whiteknight++ | trunk/PBC_COMPAT:
I can't generate the native PBCs on this platform, so I'm changing PBC_COMPAT here and hoping somebody else can do it.
 12:53
rrot: r40617 | NotFound++ | trunk/NEWS:
NEWS update
 13:00
rtcl: r598 | coke++ | trunk/docs/spectest- (2 files):
update spec test info.

  .test files have come and gone. This run was much slower, though.		 13:05
Coke Whiteknight: you don't have an account on feather? 13:10
Whiteknight nope
Coke ask juerd? 13:11
juerd?
purl somebody said juerd was root or at juerd.nl/ or mailto:juerd@juerd.nl
Coke I can run it now. moment.
Coke wonders why mk_native_pbc is running configure /twice/ 13:14
purl Hmm. No matches for that, Coke.
Coke (and rebuilding 2x.)
Whiteknight: I ran the script, it appears to have had no effect. 13:19
(no files were changed in my checkout.)
Whiteknight well, I don't know anything about it really
I can't run it on my x64 box, always gives me errors 13:20
dalek rrot: r40618 | NotFound++ | branches/auto_attrs (70 files):
merge from trunk r40617
Whiteknight so I usually ask Infinoid to do it for me :)
Infinoid is useful, when properly scripted 13:28
moritz :-) 13:29
bacek Coke: try --noconf. mk_native_pbc trying to build with different FLOATVAL size... 13:36
NotFound Whiteknight: I think PBC_COMPAT requires tab delimited entrie 13:37
s
bacek really hate PBC's format... It's too fragile...
dalek rrot: r40619 | bacek++ | trunk/t/native_pbc (4 files):
[cage] Rebuild native PBCs
Coke was there a thread to the email that email2trac was now working? 13:40
... to the mailing list, I mean.
(because it doesn't really work yet.) 13:41
(nope, doesn't look like it was, good.)
msg cotto your email reply to that ticket was lost, btw. 13:42
purl Message for cotto stored.
Coke wonders why I have to specify an arg to mk_native_pbc to get it to work. 13:44
(instead of it just... workign) 13:45
Whiteknight okay, updated PBC_COMPAT to use tabs in r40620 13:50
Coke: open a ticket!
Coke Whiteknight: if you had an account on feather, I wouldn't have had to know about it at all. =-) 13:51
dalek rrot: r40620 | whiteknight++ | trunk/PBC_COMPAT:
[PBC_COMPAT] now with tabs instead of spaces
Coke has a bite from dukeleto on a parrot bug that's been open for a year and is affecting tcl. 14:04
14:10 masak joined 14:14 Andy joined
Coke what branches needed testing? 14:16
Whiteknight all of them
are there any other NEWS items? 14:17
pmichaud good morning, #parrot
Coke pmichaud: hio.
Whiteknight I've got the release ready to roll as soon as I get a GO! on outstanding NEWS items 14:18
14:19 quek left, szabgab joined 14:21 jsut joined
Coke Whiteknight: we did NOT remove the PASM1 compiler. 14:24
We just kind of snapped it half and left it there to rot. 14:25
Whiteknight we removed all the parts of it that did anything
we removed the "compiler" part, but we still let people search for the PASM1 compreg
Coke see my ticket for why that was the wrong approach, and no one cares because no one was using it anyway, but we dodn't remove it.
Whiteknight so when the release lands, just rip it the hell out 14:26
14:26 ruoso joined
Whiteknight Coke: and update NEWS if you feel like something in there is wrong 14:27
Coke I'm sorry, I thought you had asked for feedback rather than commits, my bad. moment.
Whiteknight ME THOR DEMAND COMMITS! 14:28
(not all commits, just stuff like NEWS) 14:29
14:29 nathanmccauley joined
Coke Done. 14:31
bacek Whiteknight: it wasn't very good idea to change PBC version to 6.0...
Coke bacek: that number is internal only. why does it matter? 14:32
bacek For consistency sake 14:33
Coke it looks consistent to me. =-)
(other releases have increased the major #.)
dalek rrot: r40621 | coke++ | trunk (2 files):
Update docs WRT PASM1
 14:34
Coke ah, but those were supported and this is devel.
bumping that number down to 5.1 should be safe.
bacek indeed
Coke (but then you have to re-re-make the pbcs, I bet.)
bacek 5.3 is better
I can remake them in next 5 minutes
Coke I don't care enough about the fraction to argue. =-)
bacek before departing to bed 14:35
I don't care enough about TGE to rip it off :)
Whiteknight The release_mangers_guide says to bump the major version number 14:36
I don't make these thigns up
Coke several of us are using TGE, tyvm.
bacek On "supported release"
Anyway, not a big deal 14:37
We can have 7.0 PBC in 2.0 parrot
Coke to be fair, there /were/ changes this release so the number needed incr'ing. the docs seem to be more verbose about supported release.
bacek wave from future 14:38
good night, bed time
Whiteknight oh, maybe Imissed that part about "Developer release"
I can undo the PBC_COMPAT change then 14:39
14:40 MikHel joined
bacek Whiteknight: ignore it. We can have next supported release with 7.0 14:43
bacek finally going to bed
14:43 ash_ joined
Whiteknight I just committed an undo. No big deal 14:44
I have time before the release anyway
14:44 Psyche^ joined
dalek rrot: r40622 | whiteknight++ | trunk/PBC_COMPAT:
[PBC_COMPAT] I wasn't supposed to bump the PBC major version, this is just a dev release
 14:45
mikehh All tests PASS (pre/post-config, test, fulltest) at r40621 - Ubuntu 9.04 amd64 (g++) 14:52
NotFound No tab in 5.1 and 5.2 PBC_COMPAT entries, they are filled with spaces. 14:59
Can't we kill this format and use some human readable separator 15:00
?
Whiteknight NotFound: please
fixed the file 15:01
dalek rrot: r40623 | whiteknight++ | trunk/t/native_pbc (4 files):
[PBC_COMPAT] rolled back the updated PBCs since I shouldn't have bumped PBC_COMPAT
 15:02
rrot: r40624 | whiteknight++ | trunk/PBC_COMPAT:
[PBC_COMPAT] change spaces to tabs again
Whiteknight okay, the release is 100% ready to go. Just need to commit and tag. ~57 minutes 15:03
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40624 - Ubuntu 9.04 amd64 (gcc) 15:25
15:26 theory joined
Coke for those of you that remember mdiep, I hear he's getting married this weekend. 15:34
mdiep++
mikehh rakudo (5a2aeaf) builds on parrot r40624 - make test PASS, make spectest (up to 28020) FAILs 1 test - t/spec/S12-enums/thorough.rakudo - Failed test: 2 15:45
16:00 davidfetter joined
Whiteknight Release happening now. 16:09
NotFound Go, go, 16:10
go!
mj41 Whiteknight: some test fails on win32 tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk 16:11
dalek rrot: r40625 | whiteknight++ | trunk (9 files):
[RELEASE] Release 1.5.0
 16:12
rrot: r40626 | whiteknight++ | branches/RELEASE_1_5_0:
[RELEASE] tagging 1.5.0 release
PerlJam Whiteknight++
Whiteknight well, too late!
mj: I've been running tests on Windows and saw no problems 16:13
mj41 ok, these are 64bit with 32bit WinXP, one mingw one MS VC
on vmware
Whiteknight oh, okay. 16:14
mj41 err sorry, no vmware, only cygwin is vmware
Whiteknight I'm mingw on Win32 and saw no errors
mj41 ok, will try to setup fresh win32 mingw vmware, my machine is probably broken somehow 16:18
I was trying to debug t/src/extend.t ... nopaste.snit.ch/17561 ... there is no "done" ... problem is Parrot_PMC_set_string(interp, testpmc, value); or new_value = Parrot_PMC_get_string(interp, testpmc); 16:20
I have no ICU installed
moderator www.parrot.org | planet.parrot.org | 1.5.0 "TEH PARROTZ!" Released! | Feature freeze over, coders start your engines! 16:27
16:28 mj41 joined
jonathan lol...release name win! 16:29
dalek tracwiki: v93 | whiteknight++ | WikiStart 16:30
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
Whiteknight I was thinking about naming it "LOLPARROTZ!" or "I CAN HAZ PARROTBURGER", but nether were as good 16:31
dalek website: Whiteknight++ | Parrot 1.5.0 "TEH PARROTZ!" Released!
website: www.parrot.org/news/2009/Parrot-1.5.0
16:34 mokurai joined 16:35 HG` joined 16:43 smash joined
smash hello everyone 16:43
16:43 payload joined
Whiteknight hello smash 16:43
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40626 - Ubuntu 9.04 amd64 (g++) 16:51
dalek TT #702 closed by whiteknight++: Remove stacks.c and stack-related ops 16:53
Coke smash: hey. Did you decline your nom nom nomination? 16:55
dalek rrot: r40627 | NotFound++ | branches/auto_attrs (80 files):
merge from trunk r40626
Coke (I saw you nominated and then not on the final list, which confused me.)
Whiteknight I can't mark the 1.5 milestone "Completed" on trac. The box is greyed out for me 16:56
Coke checking.
perhaps you need super admin privs. 16:57
try now. 16:58
particle confused me, too
Whiteknight works!
Coke particle, you are now an admin. 16:59
(i mean, before I touched anything)
particle the nomination list confused me
Coke oh!
17:00 bkuhn joined 17:03 riffraff joined
Coke is rakudo now succesfully overriding the "invoke" vtable? 17:04
Whiteknight++ # trolling for RMs. 17:05
jonathan Coke: Yes. 17:06
Coke: But only because we subclass the Object PMC. ;-) 17:07
17:07 jhorwitz joined
jonathan (We subclass it really to totoally replace find_method, but it meant I could write an epic hack around Parrot's invoke override issues ;-)) 17:07
Coke That seems to be more work than I want to do just now. =-)
Coke wonders if there is anyway to really subclass the ParrotInterpreter. 17:08
(... and have it used whenever someone creates a new interp)
17:09 theory joined
Coke hurls code.google.com/p/partcl/issues/detail?id=12 for a low hanging, mostly parrot TODO item for partcl. 17:21
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40626 - Ubuntu 9.04 amd64 (gcc)
17:22 brooksbp joined
brooksbp Are there any popular languages that allocate stack frames on the heap? 17:24
jonathan Coke: Yes, it was..."fun". :-)
dalek rrot: r40628 | NotFound++ | trunk (59 files):
merge auto_attrs branch into trunk
 17:27
Coke NotFound: the "#if 0" concerns me. 17:30
NotFound Coke: I left it just in case someone wants to do some quick becnchmark between fixed size allocator and mem_sys 17:31
smash Coke: i revoked my voluntereed state 17:32
ttbot NotFound: Parrot trunk/ r40628 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73018.txt
NotFound Error -1073741819 ? What's that? 17:34
jonathan NotFound: Convert to hex... 17:35
If it matches C0000005 then it's a segv.
pmichaud #ps in 54 17:36
NotFound I suspect a lack of realclean
Whiteknight Once we get some good testing on that fixed-size allocator, I want to start using it to do more things in Parrot 17:37
if we use it consistently we could cut a lot of overhead out
mj41 NotFound: ttbot is doing make on fresh svn copy
NotFound Is there some human buliding on windows? 17:38
mj41 NotFound: see tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk ... there is also tt.ro.vutbr.cz/file/cmdout/73025.txt 17:39
smash Coke: it turned out i wasn't skilled enough 17:41
NotFound Why on earth are someone defning his own version of LLONG_MAX and such macros? 17:42
Whiteknight those aren't defined on Win64 17:43
well, Win64 with MSVC64 17:44
NotFound Then don't use it
Whiteknight have to use it, sizeof(long) on those systems is 4
and then sizeof(long) != sizeof(void*) which causes huge build problems
NotFound The comments in the file says: * Define the values for PARROT_INTVAL_MAX and PARROT_INTVAL_MIN
Then do that instead of playing with foreign macros.
Whiteknight You're welcome to change that if you want 17:45
NotFound I don't have msvc compilers
17:47 chromatic joined
cotto Whiteknight++ for getting out the release before #ps 17:51
smash Whiteknight++ # release
chromatic pie++ 17:52
Whiteknight pie++ 17:54
I only do the releases for all the free karma :)
17:56 joeri joined
Coke pie? 17:59
purl it has been said that pie is true. or www.piecouncil.org/national.htm or london.randomness.org.uk/wiki.cgi?a..._value=Pie or www.austinthirdgen.org/upload/piechart.jpg or www.weebls-stuff.com/wab/ or flickr.com/photos/cowfish/3137913195/ or dilbert.com/fast/2009-03-07/
Coke wah, no room for the cool dr. horrible pie quote.
Infinoid pie is also position-independent executable (like PIC libraries but more so)
purl okay, Infinoid.
chromatic Sometimes quotes executables are layered like that. 18:02
Util Whiteknight++ # release 18:03
Coke chromatic-- # thwap thwap
dalek rrot: r40629 | NotFound++ | trunk/config/gen/platform/generic/platform_limits.h:
[cage] ugly attempt to fix LLONG_MAX related problems
 18:05
allison iz in ur computer, runnin ur languages 18:07
Whiteknight I figured "TEH PARROTZ!" would either be a fun little name or a head-slapping embarassement 18:09
18:09 barney joined
Whiteknight I was hoping for the former :) 18:09
ttbot NotFound: Parrot trunk/ r40629 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73070.txt 18:11
Whiteknight all these good projects going on is very exciting!
allison Whiteknight: I think it's great :) 18:13
jonathan #ps is in 15 mins, yes? 18:14
cotto jonathan, yup
jonathan refrains from going to dinner 18:15
cotto NotFound, don't forget to delete the auto_attrs branch
NotFound cotto: I'll try to first learn how to delete branches without risk of deleting trunk ;) 18:16
Whiteknight NotFound: it's "sudo rm -rI /" 18:17
smash NotFound: deleting trunk it's not that big of a problem
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40628 - Ubuntu 9.04 amd64 (g++)
Whiteknight NotFound: just kidding, don't type that!
NotFound Whiteknight: too late, is running 18:18
;-)
Whiteknight Coke: bevity++ 18:19
brevity*
dalek rrot: r40630 | Util++ | trunk/src/packfile.c:
Fixed an error in packfile.c reference to pbc_header.pl. Courtesy of dukeleto++
 18:20
Coke Whiteknight: I left out the snarky "nothing that anyone would care about". =-)
dalek kudo: 6c7b8b3 | jnthn++ | build/PARROT_REVISION:
Bump us up the the current Parrot release, in preparation for the next Rakudo release.
 18:22
chromatic Hm, Parrot startup is 2.874% faster today than it was last night.
ttbot Util: Parrot trunk/ r40630 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73121.txt
Whiteknight hmm, it must be something i did
davidfetter not 2.873%?
Whiteknight :)
davidfetter always amused by figures that don't have error bars or like kind 18:23
chromatic According to callgrind output anyway.
davidfetter measure with a micrometer; draw with chalk; cut with an axe
;)
NotFound Maybe auto_attrs+fixed size allocator has something to do with that
chromatic My guess is auto_attrs.
I'll look at the profile in a bit.
Coke davidfetter++ 18:24
Util For the record, I assert that ttbot erred in assigning blame to me for that failure in r40630. 18:25
Coke so if --optimize causes things in tcl to fail, what sort of things might be causing that?
18:26 payload joined
NotFound I suspect since some time that the gc can fail to mark some PMC in the C stack because of optimizing putting them in registers rather than in the stack 18:27
Whiteknight no, the GC dumps register contents onto the stack before tracing the stack
in theory, anyway
purl hmmm... in theory is my pants or it's too dark to read or somewhat intrusive to David Wheeler
dalek rrot: r40631 | NotFound++ | branches/auto_attrs:
delete auto_attrs branch after merging to trunk
NotFound Unfortunately, to check that hypotesis we need to add a volatile qualifier to *all* PMC * local vars 18:28
Whiteknight some of that code is pretty fragile, however, and it wouldn't surprise me if those lines that perform that magic are being optimized out themselves
theory purl++
Whiteknight src/gc/system.c 18:29
purl src/gc/system.c is probably a known mess and I'm working on it as we speak
Whiteknight well, it is a mess
NotFound purl is working on the gc? 18:31
Whiteknight might as well be 18:32
allison NotFound: anything stored in registers is always marked
NotFound Good to know 18:33
jonathan fail...joined #parrotsketch on wrong server... 18:35
Coke jonathan?
purl i heard jonathan was mailto:jnthn@jnthn.net or trying to put together a grant application. or however seeing weird issues.
jonathan Also forgot to pre-paste. Fail. 18:36
brooksbp Are there any languages that allocate stack frames on the heap? 18:37
Whiteknight brooksbp: what do you mean by that? 18:39
jonathan brooksbp: In Parrot? Well, all Parrot "stack frames" (though there isn't really a stack) are heap-allocated.
Whiteknight because it's not really possible. by definition, a "stack frame" is always on the stack
jonathan So all languages running on Parrot have their invocations records living on the heap.
If that is what you mean.
Whiteknight right, Parrot's "stack frames" are more accurately called "Contexts" and are created on the heap
brooksbp No, for compiled languages. 18:44
Heap-allocated stack frames
NotFound Thread packages usually allocate in the heap the stack space for threads other than the main one. 18:45
brooksbp NotFound: could you provide any references or papers on this? 18:46
Whiteknight I'm not sure that's accurate. Again, by definition,"stack frames" are on the stack 18:48
NotFound Yes, doing it for each frame must be done by the compiler in a function by function basis 18:49
brooksbp: the references are the documentation of the thread creation functions. 18:50
dalek rrot: r40632 | whiteknight++ | trunk/docs/project/release_manager_guide.pod:
Adding dukeleto++ as release manager for Oct
 18:56
ttbot whiteknight: Parrot trunk/ r40632 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73189.txt 18:58
Whiteknight don't give me that shit, ttbot, I didn't break no build! 18:59
mj41 Whiteknight: sorry, ttbot is too stupid :-( 19:00
allison jonathan: the more detailed answer to your question, if you take a sub object (however you looked it up) and invoke it under the new calling conventions passing it an invocant, it'll just dump it as the first argument to the sub 19:04
pmichaud ETOOMANY"IT"
jonathan What do you mean by "passing it as an invocant"?
allison jonathan: object."foo"(bar, baz) 19:05
jonathan: object is an invocant
pmichaud No.
that's not the question.
object.$P0(bar, baz)
allison pmichaud: that's half the question
pmichaud and $P0(object, bar, baz) 19:06
jonathan OK, let me give an example of what I'm expecting to work.
Suppose I have this:
.sub 'foo' :method
.param pmc args :call_sig
...
.end
And I (somehow) end up with the sub object mapping to that in $P0
Will both
a.$P0(b, c)
and
$P0(a, b, c) 19:07
Result in a CallSignature with three positionals, a, b and c?
allison If you invoke a method object as a sub ($P0(a, b, c)) it won't receive any argument marked as an invocant
and will complain about a missing parameter
jonathan That's going to break things.
chromatic Good. 19:08
Coke what if you could explicitly say $P0(a :invocant, b, c). would that make everyone happy?
jonathan chromatic: Erm. How exactly?
chromatic It's broken in Perl 5. Very badly broken. Discontinuing that kind of brokenness is Very Good.
allison Coke: that would work
pmichaud Coke: we don't always (easily?) have enough information to be able to know to flag an invocant
jonathan Coke: The point is that today we rely on the ability to invoke as $P0(a, b, c) and a.$P0(b, c) 19:09
And have both bind a to self.
pmichaud Perl 6 expects this behavior as a core semantic.
allison jonathan: I don't believe that actually works now.
pmichaud it does work now.
Coke so you can't figure out at runtime if $P0 is a method or not?
pmichaud Coke: that's a check we'd prefer not to make on every subroutine call. 19:10
jonathan allison: It works now because we're using - and have been using for a long time - those semantics in many places.
chromatic I can't believe that Perl 6 allows you to invoke methods as if they were subs; what am I missing?
allison that can't have worked, because invocants aren't currently passed as parameters at all
jonathan chromatic: is export, perhaps? 19:11
allison they're stored as 'interp->current_object'
pmichaud methods can be invoked as subs currently, yes. (more)
the first argument ends up being 'self'
chromatic That's the first thing I fix in Perl 7 then. Yuck.
pmichaud so if I have a method in $P0, and I do $P0(a, b, c), then inside of $P0 the register named 'self' is bound to the first argument
19:12 payload joined
japhb implementation accident ...? 19:13
chromatic I can't get behind that idea.
TimToady the invocant has to be available as a parameter *anyway*, so why treat it as out-of-band?
chromatic Because invocants are special. 19:14
TimToady not that special
chromatic That's why we have a special noun to describe them.
TimToady they are important to the dispatcher
that's all
chromatic They're important inside method bodies too.
TimToady and we want to be able to write dispatchers in p6
nopaste "pmichaud" at 72.181.176.220 pasted "invocant passed as argument" (24 lines) at nopaste.snit.ch/17584 19:15
TimToady all the dispatchers in p6 assume that the point of a dispatcher is to turn a method name into a list of candidate subs and call them
as subs
allison TimToady: well, that's changing in the new system, interp->current_object goes away 19:16
but, we do mark invocants, and a parameter marked as an invocant is treated specially
chromatic If you can mark an invocant when you invoke something invokable, does the problem still exist?
allison most languages have a sharp distinction between the invocant and the rest of the arguments
it's really easy to relax that restriction for p6, but it's hard to add the distinction back when the fundamental system ignores it 19:17
jonathan allison: I'm fine with Parrot providing support for those languages to distinguish them, but we really need a way for a Perl 6 method to say "hey, I don't care how I'm invoked".
(And other languages that feel the same way.) 19:18
TimToady *cough* python *cough*
allison as I understood it, talking to patrick, you all would plan to use call signatures instead of the direct parameter binding in most cases anyway
in which case, you don't care
pmichaud we care that the invocant be available in the call signature, though
jonathan allison: It may cause us some language inter-op issues.
pmichaud which is jonathan's exact question
Coke Seems like it should be possible to roll a custom "invoke" app that hides away the work. 19:19
allison pmichaud, oh, it is, it always is
TimToady the distinction on the receiving end is only whether to assume there's an implicit self in the signature, which is a compile-time decision, not run-time
allison we don't modify the call signature after setting 'self'
(we never modify the call signature)
pmichaud but you're saying that 'self' isn't treated like a positional in that case
allison so, here's what would be useful to me 19:20
pmichaud i.e., 'self' is taken out of the list of positionals before the called method gets the call signature
jonathan OK, so a.$P0(b, c) and $P0(a, b, c) both produce the same call signature modulo some extra bit of data saying "in one of these, a was passed as an invocant"?
allison basically, what features do you need to support, and what PIR syntax are you currently using to support it
(just for dispatch) 19:21
pmichaud first, I think that jonathan's question isn't about dispatch as much as invocation (more)
but for dispatch we need to be able to invoke methods as both object.<something>(args) and <something>(object, args)
we don't need Parrot to automatically look up <something> 19:22
well, I should rephrase this last part
object.'foo'(args) should work as it does now
i.e., look up 'foo' as a method on object
'foo'(object, args) should work as it does now
i.e., do a 'find_name' on 'foo', and invoke that as a sub
object.$P0(args) should work as it does now, invoking $P0 and passing object as 'self' 19:23
allison jonathan: yes, they'd have the same array of arguments passed, but one would have a signature string of PiPP and the other PPP
pmichaud $P0(object, args) should work as it does now, invoking $P0 and passing object as 'self' (when $P0 is flagged as :method)
jonathan allison: OK, then that's a big part of what we want.
allison (you'd be free to ignore the extra 'i', but parrot respects it)
pmichaud did I miss anything on dispatch, jonathan?
jonathan allison: The only place we need clarify is on what the "i" there implies. 19:24
allison: That is, if I write a .sub 'foo' :method, I get the impression the default semantics you are proposing is that unless the first parameter is Pi, and not just P, then an error will be raised?
allison jonathan: yes 19:25
TimToady as long as in P6 $randomref.($object: 1,2,3) doesn't have to introspect $randomref to see if it's a method or a sub, I'm happy (I think...)
jonathan allison: OK, and there will be a way to say to Parrot, "please don't do that check"?
chromatic I've used CGI.pm. I'm not happy with that.
allison distracted at the moment wrapping up #parrotsketch, will read pmichaud's dispatch info in a minute 19:29
mikehh dukeleto: IIRC a signalling Nan is expected to generate an exception, a quiet Nan not 19:36
Infinoid "NaN but die"
allison pmichaud: okay, the only one I have a contention with is $P0(object, args) passing object as 'self' 19:37
mikehh well it can be caught ;_}
bah :-}
allison pmichaud: but, if you're using ':' to mark the invocant, surely you can translate that to "object :invocant, args"? 19:38
jonathan allison: But we don't always know.
pmichaud allison: p6 doesn't require using : to mark the invocant argument
jonathan allison: And we shouldn't have to.
pmichaud $foo($object, $arg) is perfectly valid in Perl 6, even if $foo is a method.
allison jonathan: I'd argue you should, but I'm not going to make assertions about p6 syntax :) 19:39
jonathan allison: Basically, I'm OK if you want to make the *default* in Parrot be that if you try to bind a non-Pi to self, it's an exception.
allison: But there has to be a way to say to Parrot, "don't worry about that"
allison the lazy solution would be to add a ":maybeinvocant" modifier
pmichaud alternatively, perhaps we could always mark our first argument as an invocant :-)
jonathan lol! 19:40
TimToady I wasn't going to say that...
but I thunk it...
jonathan That's a rebellion, not an ideal solution. ;-)
pmichaud I expect that allison will say then that normal subs will then throw an exception if we pass an invocant to something not expecting one
allison it's like :lookahead, in that it checks one thing and does another
jonathan allison: Not really. It's just like asking for a check not to be made.
pmichaud i.e., $P0(a :invocant, b, c) will throw an exception if $P0 is not a method
allison that is, check if I need an invocant, and if so, use it as one, otherwise pass as the first argument
TimToady that's the same introspection we're trying to avoid 19:41
allison pmichaud: aye, that's the idea. so the default is restrictive, but we support the more relaxed model
l3t0 mikehh, Infinoid: i was familiar with the concept but wanted to know what kind of exceptions should be thrown
jonathan allison: I think it wants to be a flag on the receiver, not on the caller side.
allison TimToady: all you're really doing is not throwing an exception
pmichaud flag on receiver: exactly 19:42
TimToady dispatch will be faster if you don't check at all :)
allison TimToady: so it's more like "be permissive" than "perform an introspective check"
TimToady and we want fast dispatch
mikehh l3to: a Nan of vcourse :-}
NotFound That type of things can be handled by subclassing 'Sub' ? 19:43
allison TimToady: well, we'd have to check if the ":maybeinvocant" is set on the argument, but that's a simple integer flag test, very cheap
TimToady p5 is slow because it keeps checking this and checking that
pmichaud allison: but why check the arguments -- why not let the sub itself say "I don't care" in the parameters
allison TimToady: and, yes, would allow it to skip some code
pmichaud: what would that mean, though?
jonathan allison: And I assume that if I say ".param pmc args :call_sig" then Parrot isn't going to do any checks at all for me?
pmichaud allison: if I have a sub that takes a :call_sig, it means that the sub wants to do its own argument packing and unpacking (more) 19:44
that implies that the sub *doesn't* want parrot imposing its own checks on the bindability of arguments
allison jonathan: right now, it would still complain if you call a method and don't give it a Pi argument
jonathan allison: Why though?
allison (because it has to figure out what to set 'self' to, and that isn't bypassed)
TimToady we would love to kill that very dead 19:45
jonathan Oh.
pmichaud 'self' is always set to the first argument? or no?
I'm also fine if :call_sig doesn't set a 'self'
allison we can get rid of 'self', though :)
jonathan allison: I was figuring part of the unpacking would involve setting up a self if needed.
That is, Parrot really doesn't do much at all for you other than just hand over the CallSignature.
allison okay, when we implement :call_sig, we can add that exception. It's a sensible one. 19:46
pmichaud can you clarify? "exception" scares me in this context.
jonathan allison: I'd imagine we rather would just never hit the code-path that would do such a check anyway though? 19:47
allison I mean it in the more general sense of "exception to the rule", rather than the computer science sense of "throwing an exception"
pmichaud so, a sub that specifies a .param of :call_sig gets no argument checking from Parrot?
allison pmichaud: and doesn't set 'self'
pmichaud that's fine.
I'm happy with that if jonathan++ is.
jonathan That works well for me. 19:48
allison it does nothing at all except pass the call signature object in as a single PMC parameter
jonathan That sounds just what I want.
pmichaud in Rakudo we don't even need a 'self' register anyway, because 'self' is a lexical
jonathan Well, lexicals live in registers, but yes, we need to handle it as a lexical.
pmichaud I mean we don't need a register symbol of 'self' 19:49
allison I'm regretting that we ever added an automatic 'self' in the first place
jonathan pmichaud: Ah, OK.
allison it's a stupid pain
and a hack
pmichaud that sounds like TimToady++'s position :-) 19:50
allison well, I'd replace it with .param pmc foo :invocant
so, I still want it explicitly marked 19:51
dalek TT #895 closed by NotFound++: Towards automatic allocation and deallocation of PMC attributes
pmichaud I'd want it to work even if not marked, though :-) 19:52
jonathan So let me try and summarize. 19:53
$P0(a, b, c) and a.$P0(b, c) produce a CallSignature with 3 positionals, but the first produces a signature starting P and the second a signature starting Pi.
Default Parrot semantics will change such that a Sub flagged with :method will only accept a signature whose first item is a Pi.
:call_sig just puts the CallSignature PMC into a register and that's it - we're done. It doesn't do any checking, wether or not it's a :method.
Does everyone agree that is where we're at so far?
pmichaud +1
purl 1
jonathan no purl, +1 is <reply>-1
purl okay, jonathan.
jonathan
.oO( heh, heh )
 19:54
allison jonathan: yes, but the Pi required will only change on a deprecation cycle
jonathan: (i.e. 2.1)
jonathan allison: OK.
allison: I think the only remaining issue is that it would be nice to suppress that check even if you're not doing all of your own unpacking.
allison the :call_sig can happen now, since it's an addition 19:55
jonathan: that I can't guarantee
jonathan While all Perl 6 code (that is, code that Rakudo emits) will use :call_sig... (more)
allison jonathan: that is, it needs a lot more thinking about the use
pmichaud wait 19:56
allison and if rakudo isn't using it, then it needs another demonstration language to figure out *how* it'd be used
jonathan ...it may be nice if it's possible for us to write built-ins in PIR that have the correct semantics (invokable as a sub or a method, as things work today) otherwise.
pmichaud the current parrot behavior is that passing an invocant as an argument does not throw an exception
so changing it to throw an exception should be at the deprecation point
not vice-versa
allison pmichaud: what syntax/behavior do you mean?
pmichaud in other words, Parrot currently *does not* do a check of its arguments
19:56 hercynium joined
pmichaud so the addition of checking arguments should only occur at a deprecation point 19:57
Coke msg purl +1
purl Message for purl stored.
Coke bad coke.
allison Parrot doesn't currently have any way to mark an invocant except that invocants aren't passed in the argument list at all
they're currently "out of band" parameters
(interp->current_object)
NotFound Don't forget the vtable invoke issue.
pmichaud allison: I'm talking about the current $P0(a, b, c) syntax
currently Parrot does not complain if $P0 is a method 19:58
i.e., 'self' is bound to 'a'
allison which was bad design (that dates back to the earliest parrot calling conventions)
pmichaud: right, that's what jonathan was talking about with the Pi marking
pmichaud my point is that "suppress the check" should be the behavior even before the deprecation point
and that making the check should occur after the deprecation point 19:59
allison the deprecation point is adding the check
pmichaud okay.
jonathan pmichaud: That's what allision said.
pmichaud I misread "that I can't guarantee" then.
jonathan 21:54 <@allison> jonathan: yes, but the Pi required will only change on a deprecation cycle
pmichaud oh, I see
Okay. pmichaud--
jonathan pmichaud: I think that was in response to my suggestion that we provide another way to suppress the check.
pmichaud jonathan was asking about the case of not doing your own.... right
allison I'm saying we're deprecating (unchecked invocant passing), and I'm not promising that we'll provide a general way to supress it once it's added, though :callsig will supress it 20:00
pmichaud I'm fine with that waiting until 2.1, but there may be a large number of languages and libraries that expect the current behavior to work also
TimToady to my mind, this is all really about making dispatch completely orthogonal to binding at a fundamental level rather than signing up for one particular model of OO that assumes there's an interaction
but what do I know? :) 20:01
allison well, there is an interaction between dispatch and binding, they have to meet in the middle
chromatic I like the idea of that orthogonality, but I really dislike making that orthogonality look like Normal Sub Invocation.
allison but, what we may do is deprecate the automatic 'self' binding
because that's the real case of "dictating semantics" 20:02
TimToady sub is more primitive then method, so it's unnaturally to decompose to something more complex
jonathan allison: OK, I'm happy to take this answer for now. I really think a general way to ask for suppression from the callee side would be valuable.
allison everything else is "whatever you declare in your parameters determines the semantics of binding"
jonathan allison: But we don't need to decide that right now (though I do agree with pmichaud that people will want a good bit of time to adapt.) 20:03
pmichaud jonathan: does this give you a sense of timeframe for these things as well...?
allison aye, the current refactor doesn't really touch on this (it doesn't change semantics, just the internals)
pmichaud jonathan: i.e., when we might be able to unblock some of our calling issues? 20:04
jonathan pmichaud: As I see it, since allison's changes are towards building a CallSignature object, as soon as the bugs are resolved and that branch is merged, then :call_sig should be a relatively small amount of work.
pmichaud okay. That's consistent with what I see. 20:05
and once :call_sig is in place we can start on our rakudo binding refactors
chromatic goto/branch/invoke continuation is more primitive than sub; why stop at sub?
allison chromatic: ? 20:06
jonathan pmichaud: We can start using it in Rakudo, yes.
pmichaud hopefully I'll be a good ways along on contextuals by then
that seems very likely.
jonathan pmichaud: However, since the branch, from what I gather, is in fixing mode now, there's nothing to stop me working on the design side of the binding changes.
Since I know now what we cna expect from Parrot.
allison chromatic: oh, you mean lorito
pmichaud jonathan: wherever you sense the most optimum use of your time, I'm fine with that. 20:07
chromatic No, I mean "Why make methods invokable as subs?"
pmichaud jonathan: I think we both have a sense of the overall direction now so we just need to bring the various pieces together
pmichaud is excited to be seeing progress on this front.
jonathan pmichaud: Remember I'm spending a lot of september wandering around Asia. ;-) 20:08
pmichaud jonathan: noted.
allison chromatic: I have to agree, but <shrug> :)
Whiteknight if we can do the final work to make Subs subclassable properly, and if CallSignatures are subclassable, there is no issue
jonathan pmichaud: So my thinking is that I'll get onto figuring out what signature objects are going to look like in Rakudo, and what the binding algorithm will be.
pmichaud Whiteknight: unless you want PGE to always be using its own sub PMCs, sure.
jonathan I'll start on that this month.
chromatic I also think there's an issue with Perl 6's C<is export> and methods exported as multis, but I'm not sure what it is or how to explain it yet. 20:09
pmichaud s/unless/if/
jonathan: that's fine. I don't expect the binding algorithm to be that difficult, although I haven't seen what CallSignature objects look like.
Tene chromatic: I've been thinking the same thing lately.
pmichaud jonathan: but I'm thinking even with your asia jaunts the timings all work out about right. 20:10
it gives me a little room to get the pge stuff in place.
jonathan pmichaud: My wanderings in Asia give slack for PGE stuff to land and Parrot calling conventions stuff to land.
pmichaud Whiteknight: one of the problems with subclassing Sub is that there's not an easy way in PIR to declare ".subs" as being of that type. 20:11
jonathan: exactly.
jonathan OK, I think we have a plan.
Whiteknight pmichaud: if it's an HLL override, conceivably that mapping would be done by parrot internally
pmichaud Whiteknight: I don't see any way to do that presently.
Whiteknight that is, you wouldn't specify the subclass on a per-sub basis
pmichaud because HLL overrides are runtime
and sub compilation is compile-time 20:12
Coke you can put the HLL overrides in an immediate block.
pmichaud immediate blocks aren't stored in .pbcs
(we've had this conversation before)
20:12 darbelo joined
pmichaud in general the question is one of thaw+freeze a dynamic pmc type 20:12
Coke if you're storing the PBC that was generated with the overrides, shouldn't the PMCs in that PBc already have the right type? 20:13
pmichaud if they're dynamically loaded PMCs, how can they? 20:14
allison pmichaud: CallSignature objects are like captures, they have an array interface for positionals, a hash interface for named parameters, and an array attribute for returns
pmichaud (yes, I'll argue that they should. The point is that currently they don't)
Coke k.
allison: why not a hash for returns, too!
allison Coke: :) well, we could support ('foo' => $P1, 'bar' => $P2) = 'sub'('baz') 20:16
Whiteknight that would actually be very cool
pmichaud I think that's already supported.
jonathan Don't we already support taht?
Whiteknight I can't imagine where it would be used, but cool idea nonetheless
allison and, insanely simple
I'm not aware of any languages that actually use it
pmichaud No, but it's been defined in the calling conventions pdd before. 20:17
allison has it?
pmichaud yes.
jonathan Yes, for sure.
purl like totally!
allison maybe one of the much older drafts
pmichaud no, it sat around for a very long time in the pdd description of calling conventions
same for handling of :optional and :slurpy and other flags
allison well, we may support it one day, if a language needs it 20:18
pmichaud pdd03 -- line 393
(i, j :optional, ar :slurpy, value :named('key') ) = foo()
allison but not in this refactor! (detecting a note of creature feep) 20:19
pmichaud note that it already exists.
in the current pdd03.
20:19 payload joined
pmichaud and PGE *does* depend on :optional working there 20:19
(I think there might be a place or two where we also depend on :slurpy, but cannot remember off the top of my head) 20:20
jonathan taking dinner - bbiab
allison pmichaud: that's a code example
Whiteknight well returns are just invokes on continuations, so they should support passing arguments in exactly the same way 20:21
Coke pmichaud: hey, speaking of PGE. 2 things of interest to partcl at the moment: ability to define our on RE syntax (which may or may not live in core parrot as the P5 stuff currently does.), and also the bug about the zero-width repeated markers.
allison yah, I'm interested in alternate re-syntaxes too
(BNF, anyone?) 20:22
nopaste "pmichaud" at 72.181.176.220 pasted "named return arguments already supported in Parrot" (15 lines) at nopaste.snit.ch/17585
Coke hee!
allison heh :) 20:24
fortunately, I'm not really modifying that code 20:25
pmichaud fortunately. :)
allison it's logical, but it may be 20 years before anyone uses 20:26
perhaps someone will be inspired to invent a new language just to take advantage of it. :)
pmichaud note that using :slurpy in an argument return list is currently used by P6object
and Rakudo. 20:27
rakudo also needs :slurpy :named
allison if :slurpy and :named work now, I can't see any reason :slurpy :named wouldn't
pmichaud right 20:28
just making sure the calling refactor doesn't break them :)
allison are there tests for them? that's the surest way to make sure the refactor doesn't break it
pmichaud yes, there are
TimToady is that because we currently return Capture? if so, returning Parcel presumably would just want positionals...
allison then it's all good
pmichaud oh, there's test for :slurpy, but not :slurpy :named 20:29
I'll see about adding a couple.
20:30 payload joined
pmichaud TimToady: I think that getting return results into :slurpy and :slurpy :named is what we have to do when we don't know how many things the called function actually returns 20:30
have to be afk for a bit 20:31
20:38 davidfetter joined
chromatic The performance improvements are all related to fewer malloc/calloc/free calls. 20:41
Coke chromatic: any idea if those are from post-1.5.0? 20:43
chromatic Yes, they are.
10.89% performance improvement in the primes.pasm benchmark.
I think it's the auto_attrs merge. 20:44
msg Whiteknight I'm happy to do a release when needed. 20:45
purl Message for whiteknight stored.
chromatic Yep, that's all auto_attrs behavior. Very, very nice. 20:49
NotFound chromatic: goooooood :) 20:51
chromatic Now let's make PMCs with only one attribute faster....
dalek rrot: r40633 | chromatic++ | trunk/config/init/defaults.pm:
[config] Added escaping for freaky characters in checkout paths. This should
mikehh I am getting a backtrace in t/tools/parrot_debugger.t - test 41 - it does a backtrace and reports ok 41?
ttbot chromatic: Parrot trunk/ r40633 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73263.txt 20:55
chromatic Heh: src\\packfile.c:1008:50: warning: "/*" within comment 20:56
dalek rtcl: r599 | coke++ | trunk/runtime/ (2 files):
Make this a .Const sub, move it where it's used.
 20:57
20:58 bacek joined
mikehh chromatic: it builds on 'test parrot' BUT there are test failures 21:03
dalek rtcl: r600 | coke++ | trunk/docs/spectest-progress.csv:
This test run was slower since it wasn't an optimized parrot.
rtcl: r601 | coke++ | trunk/runtime/tcllib.pir:
Remove unused lookup table.
chromatic I'm working on those now, mikehh. 21:04
I saw your comment on the ticket right after I committed.
mikehh it also has some post-config test failures 21:05
NOT when running in parrot dir but in 'test parrot'
21:06 MoC joined 21:15 payload joined 21:18 joeri left 21:22 MikHel joined
dalek rrot: r40634 | mikehh++ | trunk/config/gen/platform/generic/platform_limits.h:
fix codetest failure - indent in config/gen/platform/generic/platform_limits.h
 21:24
21:27 fperrad joined
fperrad ping Whiteknight 21:28
purl I can't find Whiteknight in the DNS.
ttbot mikehh: Parrot trunk/ r40634 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73322.txt 21:29
chromatic This Makefile hackery is a rat's nest of hate. 21:30
Coke to revisit my --optimize complaint - I should expect to be able to run with --optimize by default these days, no? 21:31
chromatic Yes. 21:32
I build with --optimize on by default.
Coke ok.
chromatic Now if your PMCs and dynops aren't optimize safe, you'll have a problem....
NotFound Note that autotools has problems building in paths with spaces, is not an easy problem.
Coke chromatic: I have very few of those; presumably that would be easy to check if you knew what you were looking for.
chromatic Anywhere you pass in what could be a NULL pointer where you assume you never do. 21:35
dalek rrot: r40635 | chromatic++ | trunk/config/init/defaults.pm:
[config] Reverting r40633; this is the wrong approach to escaping freaky
fperrad seen whiteknight
purl whiteknight was last seen on #parrot 1 hours, 14 minutes and 41 seconds ago, saying: well returns are just invokes on continuations, so they should support passing arguments in exactly the same way
21:36 Whiteknight joined
dalek kudo: b9c79c2 | jnthn++ | (3 files):
Stub in AttributeDeclarand and ContainerDeclarand, as a start to getting something in place for trait application to container declarations. Based on discussion on #perl6, and not spec yet.
 21:38
ttbot chromatic: Parrot trunk/ r40635 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73373.txt 21:40
fperrad Whiteknight, I can see the tag svn.parrot.org/parrot/tags/RELEASE_1_5_0
see item 7 in release_manager_guide
Whiteknight, I cannot see the tag svn.parrot.org/parrot/tags/RELEASE_1_5_0 21:41
21:43 Zak joined
davidfetter hei Zak 21:43
Whiteknight fperrad: well, I thought that I created it 21:45
so I must have broken something
irclogs?
purl i heard irclogs was irclog.perlgeek.de/parrot/today or see also: infrared clogs
Whiteknight Ah, I created it in /branches/, not /tags/ 21:47
dalek rrot: r40636 | whiteknight++ | tags/RELEASE_1_5_0:
Should have been a tag, not a branch. Whiteknight--, fperrad++
 21:49
rrot: r40637 | whiteknight++ | branches/RELEASE_1_5_0:
[RELEASE] removing unnecessary branch
 21:53
Whiteknight eventually I'm going to get this whole release thing right 21:57
practice may eventually make perfect 21:58
22:02 ruoso joined
fperrad Whiteknight, another thing : could you review my patch on TT #113 ? 22:02
Whiteknight sure thing 22:03
bacek_at_work morning. good morning 22:07
cotto Next week, instead of having our goal be to focus on testing, what about trying to increase test coverage by %x?
darbelo cotto: ping 22:08
cotto darbelo, pong
darbelo Just wanted to let you know: I accomplished nothing in the past week, but I am still alive.
22:09 Hunger joined
cotto good to know 22:10
darbelo I migh drop out of sight again untill friday/saturday due to some family problems. But you can msg me or mail me if you need anything.
Mail is more likely to reach me than purl msgs this week, though. 22:11
Sorry I left you hanging this week. 22:13
cotto iirc today is the firm pencils down date, meaning that I'll evaluate the project based on what's been completed by the end of the day. 22:14
NotFound Whiteknight: did you plan do some measurements with auto_attrs using the fixed allocator / using sysmem, or can I delete the #if 0 related?
darbelo cotto: Wasn't that yesterday? 22:15
cotto You're right.
I somehow got it associated with #ps.
22:15 fperrad left
cotto I thought tsqueues were nuked from orbit a long time ago 22:19
dalek tracwiki: v30 | cotto++ | ParrotQuotes 22:20
tracwiki: blessed be the tie that binds
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
rrot: r40638 | chromatic++ | trunk/src/gc/gc_ms.c:
[GC] Tided some code and removed some compiler warnings with casts.
 22:24
l3t0 cotto: you have the freedom to consider any work done by darbelo up until you submit your gsoc survey.
the "firm" deadline was yesterday, but "firm" in the gsoc world is relative. 22:25
but by all means, please fill out the final survey at your earliest convenience, so you won't get nasty emails from me later this week :) 22:26
ttbot chromatic: Parrot trunk/ r40638 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73439.txt 22:27
Whiteknight NotFound: where is that #if 0 ? 22:28
NotFound Whiteknight: src/pmc.c and src/gc/api.c 22:31
Allocation and deallocation of attrs
Chnaging them to 1 revert to mem_sys 22:32
Whiteknight I'm setting these things to use a macro instead 22:35
so we can change it
NotFound I'm going to delete that if'ed code, then. 22:37
Whiteknight no, I'm working on it now
NotFound Ok 22:38
Whiteknight Just running a quick coretest before I commit
okay, committed in 40641 22:39
allison: ping
Whiteknight just remembered a question he should have asked at #ps 22:40
22:40 rg1 joined
allison Whiteknight: yes? 22:40
Whiteknight allison: have you taken a look at the pmc_sans_unionval branch? 22:41
allison Whiteknight: I haven't
Is it pretty much ready to go?
Whiteknight It does two things: removes UnionVal, almost completely, and merges the PMC_EXT struct into PMC
yes, It's passed all my tests, although I can probably throw a few more at it
anyway, it's a big enough architectural change that I wanted to run it past you first
dalek rrot: r40639 | bacek++ | branches/tt795_kill_parrot_sub_structure (83 files):
Bring branch up-to-date with trunk
 22:42
rrot: r40640 | bacek++ | branches/tt795_kill_parrot_sub_structure/t/native_pbc (4 files):
Rebuild native PBC.
rrot: r40641 | whiteknight++ | trunk (2 files):
[GC] change the allocator system to use a macro for fixed-size attribute allocations instead of just saying #if 0 in various places
rrot: r40642 | cotto++ | branches/pluggable_runcore (2 files):
[profiling] fix some compiler warnings
allison both sensible as struct cleanups 22:43
Whiteknight I think the branch is ready to go, I want to update it to trunk now and maybe run rakudo spectest run with it first to double-double check
22:43 allison joined
ttbot whiteknight: Parrot trunk/ r40641 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73500.txt 22:44
allison Whiteknight: mmmm... sorry about that, my connection resets every 24 hours at this hotel
Whiteknight oh, nice feature
allison Whiteknight: what were you saying?
purl nice feature is that you can get a SunPCI card to run Windows natively within the workstation itself. So it's virtually a Sun WS and a nice gaming PC
Whiteknight I think the branch is ready, I want to update it to trunk and run another rakudo spectest to double check
bacek_at_work Whiteknight: hey! my turn to merge branch!!! 22:45
allison does it have additional merges from trunk since it was started?
Whiteknight bacek_at_work: yes, you go first. I don't even have a green light yet!
bacek_at_work Whiteknight: ok. 22:46
Whiteknight allison: no, it's virgin
allison Whiteknight: okay, I'll look over the diff
Whiteknight okay, it'sa big one. I should have mentioned it earlier and given you plenty of time 22:47
cotto allison, I have a diff. Let me nopaste it.
Whiteknight and no hurry, bacek is dropping a branch to trunk soon, NotFound's branch landed earlier, I think we can be patient with this
allison Whiteknight: do you want questions here or in email? 22:48
nopaste "cotto" at 74.61.2.46 pasted "diff of pmc_sans_unionval branch" (2751 lines) at nopaste.snit.ch/17586
allison (I'm doing a quick pass now)
Whiteknight either or, I should be on IRC for another few hours (and purl msgs will be read early tomorrow morning)
Most of the bulk of the patch is renaming some PObj_* macros 22:49
cotto That's between the branch and the last time it was synced against trunk
allison okay, I'll do a running commentary here, can bundle up into email later if needed
Whiteknight ok
allison src/ops/set.ops: Why are we still checking PObj_is_PMC_EXT_TEST? 22:50
since nothing is using pmc_ext?
Whiteknight basically it's a flag to determine whether it has valid _metadata and pointers that used to be in PMC_EXT and need to be marked
better ways to go about that, I'm sure
allison The traditional route is to check if those pointers are non-null and mark them then 22:52
Whiteknight yes, assuming I understand what he was doing with that flag, that's definitey an aesthetic improvement to make 22:53
allison in this case, it's just setting them to null if they (might have) had a value
it's pretty cheap to just go ahead and set them to null 22:54
Whiteknight yeah
bacek_at_work got green light on merged branch. Committing soon. 22:55
22:55 cono joined
allison lots of changes of PObj_* to Buffer_* make sense (buflen doesn't exist in PObj now) 22:55
Coke yawns. 22:56
cotto Oh good. The drugs are working.
bacek_at_work wish drugs working instead of me 22:57
allison Whiteknight: is GC_MS_PObj_Wrapper generic?
Whiteknight: the name would seem to imply that it's only for gc_ms, but it's used in incremental_ms also 22:58
22:58 japhb joined
NotFound allison: I think Buffer is a too generic prefix for macros 22:58
Whiteknight allison, when I originally added that it was specific, but it's become more generic 22:59
a way to overlay a pointer on a PObj in order for the GC to organize them into a linked list
bacek_at_work Whiteknight: icanhascheezburger.files.wordpress....t-link.jpg :)
dalek rrot: r40643 | bacek++ | trunk (30 files):
Merge tt795_kill_parrot_sub_structure back to trunk.
Whiteknight NotFound: I agree with that, it's also a lousy name for the datastructure
allison then, let's at least change it to GC_PObj_Wrapper
bacek_at_work crossing fingers an watching ttbot
chromatic "Wrapper" isn't much better. 23:00
allison well, PObj is pretty bad too, while we're at it, but let's change a few things at a time :)
Whiteknight GC_PObj_Bikeshed
bacek_at_work GC_PObj_thingy 23:01
Whiteknight GC_MS_PObj_Wrapper predates the branch though, I'll rename it separately
allison existing terrible names aren't a good reason to add new terrible names :)
okay, sensible
purl hmmm... sensible is usually inappropriate, yes :)
Whiteknight (want to keep the diff from growing too huge)
bacek_at_work But it consistent!
Whiteknight consistently terrible is the wrong kind of consistent 23:02
ttbot bacek: Parrot trunk/ r40643 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/73552.txt
Whiteknight WTF is happening on Win32?
that stupid bot has been freaking out all day
allison Whiteknight: when you do change the name, make sure it follows the coding standards (I'm sure the old names don't)
bacek_at_work NotFound branch broke Win32 23:03
Whiteknight will do
dalek rtcl: r602 | coke++ | trunk/docs/spectest- (2 files):
Hey, more spectest churn. :|
Whiteknight do we have any coders on Win32 who can actually look at it?
I guess I could boot up my other machine... 23:04
allison Whiteknight: in src/gc/gc_private.h, why is buffer_header_pool commented out? 23:05
NotFound bacek_at_work: I've seen it, but I don't have a windows system at hand right now
Whiteknight looking...
allison Whiteknight: if not used anymore, delete it (but I don't see it mentioned in the overall purpose of the branch)
Whiteknight it doesn't appear to be used anymore, no 23:06
mentioned in a few comments, but not used
I'll delete it
23:07 Limbic_Region joined
Limbic_Region jonathan ping 23:07
allison Whiteknight: src/gc/api.c has some more uses of PObj_is_PMC_EXT_SET and PObj_is_PMC_EXT_TEST that appear to be unuseful 23:09
Whiteknight I'm sure all instances of it are not useful anymore
Whiteknight is building a large TODO list 23:10
Coke converts it to tickets.
allison would need to double check line 429 on context
in context
Whiteknight Coke: don't bother with tickets, these things will be fixed in branch
line 429 in context?
allison Whiteknight: look at src/gc/api.c and see if it's safe for the lines after 429 to run whether the PMC is using the PMC_EXT struct members or not 23:11
23:12 kid51 joined
Whiteknight yeah, that function could easily be reworked to not need that flag 23:13
In fact, that whole function can almost disappear
allison Whiteknight: oh yeah, because it checks PObj_is_PMC_shared_TEST next anyway
Whiteknight but that will take a little bit of energy
yeah, exactly 23:14
allison The function named 'Parrot_gc_free_pmc_ext', mmm... yes, likely removable
at the very least, you can merge the sync free code inline wherever 'Parrot_gc_free_pmc_ext' was called 23:15
Whiteknight right, and I don't think it was called from too many places
allison and, wherever it was should have been freeing metadata anyway
Whiteknight right 23:16
smash should be there a .deb or .rpm built for release 1.5.0 ?
chromatic Parrot_gc_free_pmc_ext gets called by pointer, remember.
Whiteknight smash: Building those things isn't part of the normal release procedure, no
chromatic: yes. a quick ack brought that up 23:17
smash Whiteknight: i know it's not part of the release procedure
Coke Whiteknight: I'm not sure I want to see what a quick ack brought up.
Whiteknight smash: I'm sorry, I mis-read you
yes, those files should be made
Coke hurm. ==== expr-old-15.7 FAILED 23:18
Failed allocation of 2043948 bytes
2043948 / 1024
purl 1996.04296875
Coke 1996 / 1024
purl 1.94921875
Coke 2Mb seems like a big single allocation.
no?
purl no is DCC SEND "DHOSSLIKESTRANNIES" 0 0 0
Coke purl, no, no is <reply>Maybe. 23:19
purl okay, Coke.
l3t0 coke++
cotto What's wrong with transmissions? 23:20
;)
nopaste "kid51" at 70.85.31.226 pasted "Are all these branches still needed? Spoken for?" (22 lines) at nopaste.snit.ch/17587 23:21
Coke suggests someone re-run the branch status script.
Whiteknight the context_pmc* ones are taken, io_cleanups is good (but getting older), gsoc_pdd09 is getting ripe but I'll delete it, pmc_sans_unionval is being discussed right now and could merge relatively soon 23:23
allison Whiteknight: another PObj_is_PMC_EXT_TEST in src/pmc.c
(probably removable, needs review)
Whiteknight yeah, ack turned up a handful of them
I'll kill them all, one way or another
allison chromatic: except Parrot_gc_free_pmc_ext doesn't get called at all anymore 23:24
chromatic It's part of one of the pool structs. 23:25
allison chromatic: this branch does away with pmc_ext entirely 23:26
Whiteknight I'll look through it to make sure the function is free to be deleted
I suspect it is
brb 23:27
kid51 tools/dev/branch_status.pl requires XML::Twig. Tried installing that with 'cpan'. That depends on XML::Parser. Unable to install XML::Parser from CPAN. Not worth it to me to proceed further.
allison Whiteknight: the UnionCallStateVal can go away after the pcc rewiring merge 23:31
Whiteknight: okay, done with the review, looks great! 23:38
Whiteknight awesome thanks! 23:39
I was pretty startled by this patch, came out of left-field and does so much
I'll make the changes we need and hopefully get it merged tonight or tomorrow 23:40
allison Whiteknight: yup, a nice surprise 23:44
cotto Whiteknight, thanks for adopting it. 23:45
Whiteknight no problem 23:46
somebody needs to
(and I've been secretly wishing for PMC_EXT to disappear for some time)
dalek rrot: r40644 | whiteknight++ | branches/pmc_sans_unionval (3 files):
[pmc_sans_unionval] remove all references to the now-unused buffer_header_pool
 23:51
Whiteknight really wants to kill the "high-priority" mark stuff in the GC 23:56
I'm becoming more and more convinced that it serves no benefit whatsoever
cotto Isn't that for timely destruction? 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!