Camelia, the Perl 6 bug

IRC log for #parrot, 2009-08-18

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:04 Coke allison: will the PCC rewiring branch, in addition to sunshine and puppies, provide reduced memory usage?
00:05 dalek parrot: r40610 | allison++ | branches/pcc_arg_unify/src/debug.c:
00:05 dalek parrot: [pcc] Add some safety features to PDB_backtrace so it can't get stuck in
00:05 dalek parrot: an infinite loop that segfaults the process. Use the real call chain for
00:05 dalek parrot: the backtrace.
00:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40610/
00:05 allison Coke: the current refactor won't, but it lays the groundwork for more refactors later that could
00:05 patspam joined #parrot
00:05 Whiteknight yes, lots of delicious groundwork
00:06 Whiteknight allison: you have an ETA for the current branch?
00:06 allison Coke: mainly want to get it working and merged for now
00:06 Coke yes please.
00:07 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)
00:07 allison Whiteknight: I'm down to 374 'coretest' failures
00:07 Whiteknight oh only 374? That's a solid hour worth of work :)
00:08 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 allison Whiteknight: :) Yeah, I can't really give a time, because it's all debugging, but we're close anyway.
00:09 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
00:09 Coke OOOH, can I nag? =-)
00:10 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.
00:10 allison lol :)
00:12 * Coke goes off to play _inFamous_ while this spectest run churns.
00:12 kid51 joined #parrot
00:14 rdice joined #parrot
00:15 dalek parrot: r40611 | allison++ | branches/pcc_arg_unify/src/hash.c:
00:15 dalek parrot: [pcc] Convert an impossibly horrible assert to a condition. This means
00:15 dalek parrot: it can't be turned off with a compile-time switch, but this check
00:15 dalek parrot: shouldn't ever be turned off.
00:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40611/
00:25 dalek parrot: r40612 | allison++ | branches/pcc_arg_unify/src/scheduler.c:
00:25 dalek parrot: [pcc] Conversion that didn't apply in the patch from the 'pcc_rewiring'
00:25 dalek parrot: branch.
00:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40612/
00:27 davidfetter joined #parrot
00:29 l3t0 i have been keeping the mirror of all of our current svn branches up to date on github, in case anybody cares: http://github.com/leto/parrot/tree/master
00:38 ruoso joined #parrot
00:38 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 michaelnussbaum08 joined #parrot
00:38 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:42 chromatic Encapsulation is always the right way, at least for a first approximation.
00:45 Whiteknight okay, then whoever wrote some of these things originally did it the wrong way, at least for a first approximation
00:46 Whiteknight but now we're the master reapproximatos
00:46 Whiteknight that's spanish for reapproximators
00:48 Whiteknight I also have an acute overabundance of self-importance
00:50 Coke a historically non-rare commodity in the project.
00:50 chromatic Self-importance or the wrong way?
00:51 Coke first one...
00:51 purl first one is often the best one
00:52 treed Hm.
00:52 Coke some of the tests which ABEND in the partcl spec suite seem to do so randomly. PITA.
00:52 treed Would it be reasonably to have Parrot-space methods that are not presented to users of a given HLL?
00:52 treed s/ably/able/
00:52 Coke yes.
00:52 Coke er.
00:52 treed And what would be the best way to achieve that? Just keep a separate list of user-space methods?
00:52 Coke do you literally mean "methods on objects", or just "things in other namespaces" ?
00:53 treed I mean methods on objects.
00:53 Coke yes, it would be reasonable, but I know of no way to do it.
00:53 treed In particular, I'm running into a problem where I don't want parrot:Integer's methods visible to users of cardinal;Integer
00:53 Coke if it were tcl, i'd probably name the HLL methods "&method", and leave the parrot ones with no prefix.
00:54 Coke so if someone tried to invoke "foo.blah", I'd rewrite it to "foo.&blah"
00:54 Coke or something equally evil.
00:54 treed I'm considering an array of HLL methods.
00:54 treed Including renaming.
00:54 treed The particular issue here is parrot;Integer.to_int
00:54 Coke treed: as long as "find_method" works for the HLL, I suppose it doesn't matter.
00:54 treed cardinal;Integer must not have a method by that name.
00:54 treed "find_method" is an opcode?
00:55 * treed has been trying to figure out how method calling happens
00:55 treed er
00:55 treed s/Integer/String/g
00:55 treed Having a to_int method in Ruby indicates that the object can be treated as if it were an int.
00:56 treed (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
00:56 Coke the method name collision is definitely a potential issue. I don't hink parrot has a standard way for avoiding it.
00:56 Whiteknight so you can override the find_method VTABLE and just return PMCNULL for to_int
00:56 Coke the C++-like name mangling seems easiest.
00:56 Whiteknight BLASPHEMY!
00:56 Coke METHOD not VTABLE
00:57 Whiteknight Coke: right, override the VTABLE that finds the methods, and then only find the ones you want
00:57 * treed nods.
00:57 treed Now, does that affect within-parrot as well as HLL usage though?
00:57 Coke that almost seems sane. bet you a dollar it doesn't work. =-)
00:58 Coke yes.
00:58 treed Because I'd prefer to leave within-parrot stuff accessible.
00:58 Coke treed: but arguably that isn't a problem.
00:58 Coke why?
00:58 treed Because sometimes you need a given method or whatever to interact properly with the rest of the system.
00:58 treed I guess those are vtables.
00:58 treed So I could leave them unnamed.
00:59 Coke treed: yes.
00:59 Coke but arguably, if your PMC shouldn't be an int, it should NEVER be an int. no?
00:59 Coke but you can decide whether to override the vtables, too.
00:59 Whiteknight goodnight all
01:01 treed Coke: Well, there are other vtables as well.
01:01 treed Things that return a parrot bool (ie, an integer), rather than a cardinal bool.
01:01 treed The two are not compatible.
01:01 treed Unless I make a get_integer vtable on TrueClass and FalseClass.
01:01 treed (Maybe?)
01:02 treed And I don't want those vtables polluting the Ruby namespaces.
01:02 Coke vtables aren't in the namespace.
01:02 Coke at least, they should not be.
01:02 Coke methods yes, vtables no.
01:02 treed .sub 'foo' :method :vtable('get_whatever')
01:02 treed That's not usable as a method?
01:02 Coke sure.
01:03 Coke 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?
01:03 Coke if you don't want the vtable in the namespace, don't use :method
01:03 treed Cardinal has no cases that I know of where :vtable is used but :method is not.
01:03 treed And it'll still work for that object?
01:03 Coke vtables don't need to be methods. Yes.
01:03 treed And the vtable sub can still use self?
01:04 Coke if not, it's a bug.
01:04 treed Huh, neat.
01:04 Coke (i hesitate to say anything works.)
01:04 * treed nods.
01:05 treed That'll make things a little easier, I think.
01:06 treed 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 treed I need to call it from to_i.
01:06 Coke you don't invoke vtables directly, you have opcodes for that.
01:06 Coke so if you need the get_integer vtable, you say ".local int foo; foo = myObj"
01:07 treed Is there an opcode for to_int?
01:08 treed Also, is find_method where I'd handle MRO?
01:08 dalek partcl: r591 | coke++ | trunk/docs/spectest- (2 files):
01:08 dalek partcl: update spec test after latest run.
01:08 dalek partcl: purl, segfaults?
01:08 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=591
01:20 mikehh Coke: should I run make spectest again in partcl?
01:32 mikehh well giving it a try anyway (and logging it)
01:36 dukeleto joined #parrot
01:44 dukeleto 'ello
01:45 dukeleto is there anything that needs to be done for the release tomorrow?
01:45 chromatic Fix all bugs?
01:46 dukeleto chromatic: Yes, please. Let me know when you are done :)
01:46 dukeleto does anybody need last minute testing/etc ?
01:49 dukeleto it would be nice to fix this: https://trac.parrot.org/parrot/ticket/930
01:51 chromatic Does quoting paths help?
01:52 dukeleto chromatic: sure, until someone puts a double quote in their directory name :)
01:53 chromatic File::Spec to the rescue.
01:54 dukeleto it is getting a bit close to the release to start fiddling with how the makefile is generated
01:55 dukeleto we should at least add a note somewhere about the issue
02:00 mikehh dukeleto: I had a look at this - how does this effect makes other than gnu make
02:02 mikehh I know that there are problems with quoting in gnu make but what about nmake and others
02:03 Andy joined #parrot
02:05 nopaste "chromatic" at 72.87.39.97 pasted "Escape freaky characters in checkout directory (TT #930)" (20 lines) at http://nopaste.snit.ch/17576
02:05 japhb joined #parrot
02:14 Andy joined #parrot
02:15 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 #parrot
02:23 dalek cardinal: c34fa18 | treed++ | build/Makefile.in:
02:23 dalek cardinal: Cause the Makefile to use the rakefile for testing.
02:23 dalek cardinal: review: http://github.com/cardinal/cardinal/commit​/c34fa1833df80cf89fe3ea00d3f75edb494282d3
02:31 hercynium_ joined #parrot
02:36 janus joined #parrot
02:42 Coke anyone interested in helping with some bug admin for partcl?
02:43 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.
02:44 Coke (mainly the ones skipped due to segfaults, and then putting the ticket information back in the list of failing tests.)
02:44 Coke http://code.google.com/p/p​artcl/wiki/SpecTestStatus
02:45 Coke {Spider Robinson}++
02:48 dukeleto mikehh: i am not quite sure about how the various flavors of make are effected
02:49 mikehh Coke: I got 7 of those which exited with  !! child died with signal 11, without coredump
02:49 nathanmccauley joined #parrot
02:50 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)
02:51 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
02:51 dukeleto mikehh: since that is not something that is tested or easy to write a test for
02:52 mikehh dukeleto: we need to get the windows bunch and other platforms to try it
02:55 Coke bah. for finding segfaults, non-optimized parrot is better.
02:57 mikehh Coke: append, appendComp, cmdIL, compExpr-old, expr-old, format, set-old
02:58 * kid51 mustg sleep
02:58 * kid51 must sleep
02:58 purl $kid51->sleep(8 * 3600);
02:58 mikehh ok I got cardinal to build and test
02:58 mikehh I couldn't get lua to build
03:03 Coke mikehh: did cmdIL generate a line that looks like:
03:03 Coke cmdIL.test:     Total   122     Passed  71      Skipped 3       Failed  48
03:03 Coke 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 #parrot
03:05 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 http://code.google.com/p/p​artcl/wiki/SpecTestStatus
03:07 mikehh 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.
03:07 Coke I can probably remove that now.
03:08 mikehh It allows you to keep track - if you output to a log file
03:09 mikehh I used make spectest 2>&1 | tee spectest.591.40606.log
03:12 nathanmccauley joined #parrot
03:13 mikehh I am using konsole with unlimited scrollback and at the moment 15 tabs in 2 windows :-}
03:16 mikehh it's taking 585.7 MiB of virtual memory, but only 37.2 MiB of actual memory
03:19 mikehh anyway I need to get some sleep - I have to take my grandsons to school in about 4 or so hours - bbl
03:32 dukeleto chromatic: parrot compiles and tests successfully with your patch when I have the a space in the path (on OSX)
03:46 cotto yay for last-minute patching!
03:54 mikehh_ joined #parrot
03:57 dukeleto chromatic: i attached a patch and note to https://trac.parrot.org/parrot/ticket/930, I think we should test on a few more platforms to be sure
03:59 cotto dukeleto, I'll test it on Linux/x86.  That's a rare platform, right?
04:00 dukeleto cotto: like a striped zebra
04:06 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
04:07 cotto I'll call it good then.
04:08 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 dukeleto mikehh: can you test the patch at https://trac.parrot.org/parrot/ticket/930 on windows?
04:09 cotto this also gives me a good chance to see how email2trac works
04:10 chromatic The bug's been around for a long, long time; no rush to apply the patch before the release.
04:10 chromatic I'd rather leave a known problem existing than risk a regression here.
04:12 dukeleto chromatic: my thoughts exactly
04:27 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.
04:29 cotto in its own limited way
04:31 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:39 dalek partcl: r592 | coke++ | trunk/runtime/builtin/namespace.pir:
04:39 dalek partcl: Fix usage for [namespace code ...]
04:39 dalek partcl: reclaim 2 spec tests.
04:39 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=592
04:39 dalek partcl: r593 | coke++ | trunk/runtime/builtin/info.pir:
04:39 dalek partcl: Make [info commands] work on namespaces.
04:39 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=593
04:39 dalek partcl: r594 | coke++ | trunk/runtime/builtin/info.pir:
04:40 dalek partcl: die with a proper tcl error.
04:40 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=594
05:20 cotto joined #parrot
05:47 Coke yay. I actually committing things that pass more tests, instead of avoiding deprecations or doing refactors.
05:47 Coke "committed"
05:49 dalek partcl: r595 | coke++ | trunk/runtime/builtin/namespace.pir:
05:49 dalek partcl: fix [namespace children] for namespaces other than tcl's root.
05:49 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=595
06:10 uniejo_ joined #parrot
06:18 dalek parrot: r40613 | allison++ | branches/pcc_arg_unify/src/call/pcc.c:
06:18 dalek parrot: [pcc] The value of PARROT_ARG_INTVAL is '0', so can't use a simple truth
06:18 dalek parrot: test to determine whether an argument has been set. Using a special
06:18 dalek parrot: variable to mark when the argument has been set instead.
06:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40613/
06:20 chromatic Ah.  Renumbering that enum wouldn't work.
06:23 dalek TT #932 created by dukeleto++: Warnings in compiling bignum.pmc
06:44 dalek partcl: r596 | coke++ | trunk/runtime/builtin/info.pir:
06:44 dalek partcl: improve [info vars]/[info globals] when used inside a child namespace
06:44 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=596
06:47 HG` joined #parrot
06:54 dalek partcl: r597 | coke++ | trunk/runtime/builtin/namespace.pir:
06:54 dalek partcl: fix [namespace qualifiers x]
06:54 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=597
06:59 nathanmccauley joined #parrot
07:01 dalek rakudo: 5a2aeaf | moritz++ |  (17 files):
07:01 dalek rakudo: remove some trailing whitespaces
07:01 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​a2aeaf5166c3274d99b2620b47f2fdc46dc73bf
07:05 bacek_at_work moritz: do you use vim or emacs?
07:05 mokurai left #parrot
07:05 moritz bacek_at_work: vim
07:06 nopaste "bacek" at 211.29.157.151 pasted "small vim enhancement for moritz" (5 lines) at http://nopaste.snit.ch/17578
07:06 bacek_at_work moritz: just stick into .vimrc. It will highlight a lot of trailing spaces in rakudo :)
07:07 moritz bacek_at_work: I know; most of them are due to jonathan's editor, whatever it is
07:08 * bacek_at_work suspect VC...
07:09 moritz something along these lines, yes
07:10 * bacek_at_work returning back to $dayjob duties
08:11 sjn joined #parrot
08:33 chromatic joined #parrot
08:54 ComLock joined #parrot
08:59 masak joined #parrot
09:35 NotFound http://notfound.posterous.com/autoattrs-branch
09:36 jrtayloriv joined #parrot
09:39 jrtayloriv joined #parrot
10:19 moritz NotFound++
10:19 bacek joined #parrot
10:44 bacek o hai
10:48 bacek seen whiteknight
10:48 purl whiteknight was last seen on #parrot 9 hours, 49 minutes and 9 seconds ago, saying: goodnight all
10:49 bacek time to wake up...
10:55 bacek parrot: r40610 | bacek++ | trunk (27 files)
10:55 bacek parrot: merge context_pmc2 branch into trunk
10:55 bacek parrot: review: https://trac.parrot.org/parrot/changeset/40610/
11:16 dalek parrot: r40614 | bacek++ | branches/context_pmc2/include/parrot/register.h:
11:16 dalek parrot: Fix macros from previous commits
11:16 bacek msg whiteknight I jumped on context_pmc2 train^W branch. I really want it done.
11:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40614/
11:16 purl Message for whiteknight stored.
11:19 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.
11:20 moritz holding breath for a couple of hours is likely mortal.
11:21 * bacek scratching his shiny metal ass.
11:22 bacek O RLY? :)
11:45 kid51 joined #parrot
11:46 kid51 'make fulltest' passed all tests on Darwin/PPC at r40612 and on Linux/i386 at r40607
11:47 Whiteknight joined #parrot
11:48 moritz now let's merge some branches... :-)
11:51 kid51 ... uh, we haven't released yet, correct?
11:52 moritz right, that's why there was a smiley at the end :-)
11:56 quek joined #parrot
11:56 * bacek wiping out smile from his face and run "git merge; git svn dcommit"
12:08 Whiteknight no release yet
12:08 Whiteknight soon, I hope
12:09 Whiteknight bacek: ping
12:09 bacek Whiteknight: pong
12:09 Whiteknight bacek: that branch is not a trainwreck!
12:10 bacek It will be!
12:10 bacek At least I already wrecked it locally :)
12:10 Whiteknight oh, okay
12:10 Whiteknight well feel free to do whatever you want to it, I'm busy with other things today
12:11 Whiteknight 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!
12:12 Whiteknight it's really not so evil
12:13 bacek It is!
12:13 * bacek evilly laughing
12:13 kid51 Ah, but is it *encapsulated* evil?
12:13 bacek Yes. In this universe.
12:17 * kid51 goes to $job
12:21 payload joined #parrot
12:24 bacek Whiteknight: bah... Parrot_Context, Parrot_sub and Parrot_cont are closely coupled...
12:25 dalek TT #933 created by gerd++: building NQP on ppc stops with 'Segmentation fault'
12:26 szabgab joined #parrot
12:33 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.
12:34 Whiteknight okay, awesome
12:35 Whiteknight Could everybody take a look at NEWS after r40615 and please update it?
12:35 dalek parrot: r40615 | whiteknight++ | trunk/NEWS:
12:35 dalek parrot: Add NEWS entry for 1.5.0
12:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40615/
12:51 Whiteknight anybody around on 32-bit linux?
12:53 dalek parrot: r40616 | whiteknight++ | trunk/PBC_COMPAT:
12:53 dalek parrot: 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 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40616/
13:00 dalek parrot: r40617 | NotFound++ | trunk/NEWS:
13:00 dalek parrot: NEWS update
13:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40617/
13:05 dalek partcl: r598 | coke++ | trunk/docs/spectest- (2 files):
13:05 dalek partcl: update spec test info.
13:05 dalek partcl: some churn; namespace-old has increased pass rate from recent commits, other
13:05 dalek partcl: .test files have come and gone. This run was much slower, though.
13:05 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=598
13:10 Coke Whiteknight: you don't have an account on feather?
13:10 Whiteknight nope
13:11 Coke ask juerd?
13:11 Coke juerd?
13:11 purl somebody said juerd was root or at http://juerd.nl/ or mailto:juerd@juerd.nl
13:11 Coke I can run it now. moment.
13:14 * Coke wonders why mk_native_pbc is running configure /twice/
13:14 purl Hmm.  No matches for that, Coke.
13:14 Coke (and rebuilding 2x.)
13:19 Coke Whiteknight: I ran the script, it appears to have had no effect.
13:19 Coke (no files were changed in my checkout.)
13:19 Whiteknight well, I don't know anything about it really
13:20 Whiteknight I can't run it on my x64 box, always gives me errors
13:20 dalek parrot: r40618 | NotFound++ | branches/auto_attrs (70 files):
13:20 dalek parrot: merge from trunk r40617
13:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40618/
13:20 Whiteknight so I usually ask Infinoid to do it for me :)
13:28 * Infinoid is useful, when properly scripted
13:29 moritz :-)
13:36 bacek Coke: try --noconf. mk_native_pbc trying to build with different FLOATVAL size...
13:37 NotFound Whiteknight: I think PBC_COMPAT requires tab delimited entrie
13:37 NotFound s
13:37 * bacek really hate PBC's format... It's too fragile...
13:37 dalek parrot: r40619 | bacek++ | trunk/t/native_pbc (4 files):
13:37 dalek parrot: [cage] Rebuild native PBCs
13:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40619/
13:40 Coke was there a thread to the email that email2trac was now working?
13:40 Coke ... to the mailing list, I mean.
13:41 Coke (because it doesn't really work yet.)
13:41 Coke (nope, doesn't look like it was, good.)
13:42 Coke msg cotto your email reply to that ticket was lost, btw.
13:42 purl Message for cotto stored.
13:44 * Coke wonders why I have to specify an arg to mk_native_pbc to get it to work.
13:45 Coke (instead of it just... workign)
13:50 Whiteknight okay, updated PBC_COMPAT to use tabs in r40620
13:50 Whiteknight Coke: open a ticket!
13:51 Coke Whiteknight: if you had an account on feather, I wouldn't have had to know about it at all. =-)
13:51 dalek parrot: r40620 | whiteknight++ | trunk/PBC_COMPAT:
13:51 dalek parrot: [PBC_COMPAT] now with tabs instead of spaces
13:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40620/
14:04 * Coke has a bite from dukeleto on a parrot bug that's been open for a year and is affecting tcl.
14:10 masak joined #parrot
14:14 Andy joined #parrot
14:16 Coke what branches needed testing?
14:16 Whiteknight all of them
14:17 Whiteknight are there any other NEWS items?
14:17 pmichaud good morning, #parrot
14:17 Coke pmichaud: hio.
14:18 Whiteknight I've got the release ready to roll as soon as I get a GO! on outstanding NEWS items
14:19 quek left #parrot
14:19 szabgab joined #parrot
14:21 jsut joined #parrot
14:24 Coke Whiteknight: we did NOT remove the PASM1 compiler.
14:25 Coke 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
14:25 Whiteknight we removed the "compiler" part, but we still let people search for the PASM1 compreg
14:25 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.
14:26 Whiteknight so when the release lands, just rip it the hell out
14:26 ruoso joined #parrot
14:27 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.
14:28 Whiteknight ME THOR DEMAND COMMITS!
14:29 Whiteknight (not all commits, just stuff like NEWS)
14:29 nathanmccauley joined #parrot
14:31 Coke Done.
14:31 bacek Whiteknight: it wasn't very good idea to change PBC version to 6.0...
14:32 Coke bacek: that number is internal only. why does it matter?
14:33 bacek For consistency sake
14:33 Coke it looks consistent to me. =-)
14:33 Coke (other releases have increased the major #.)
14:34 dalek parrot: r40621 | coke++ | trunk (2 files):
14:34 dalek parrot: Update docs WRT PASM1
14:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40621/
14:34 Coke ah, but those were supported and this is devel.
14:34 Coke bumping that number down to 5.1 should be safe.
14:34 bacek indeed
14:34 Coke (but then you have to re-re-make the pbcs, I bet.)
14:34 bacek 5.3 is better
14:34 bacek I can remake them in next 5 minutes
14:34 Coke I don't care enough about the fraction to argue. =-)
14:35 bacek before departing to bed
14:35 bacek I don't care enough about TGE to rip it off :)
14:36 Whiteknight The release_mangers_guide says to bump the major version number
14:36 Whiteknight I don't make these thigns up
14:36 Coke several of us are using TGE, tyvm.
14:36 bacek On "supported release"
14:37 bacek Anyway, not a big deal
14:37 bacek We can have 7.0 PBC in 2.0 parrot
14:37 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.
14:38 * bacek wave from future
14:38 bacek good night, bed time
14:38 Whiteknight oh, maybe Imissed that part about "Developer release"
14:39 Whiteknight I can undo the PBC_COMPAT change then
14:40 MikHel joined #parrot
14:43 bacek Whiteknight: ignore it. We can have next supported release with 7.0
14:43 * bacek finally going to bed
14:43 ash_ joined #parrot
14:44 Whiteknight I just committed an undo. No big deal
14:44 Whiteknight I have time before the release anyway
14:44 Psyche^ joined #parrot
14:45 dalek parrot: r40622 | whiteknight++ | trunk/PBC_COMPAT:
14:45 dalek parrot: [PBC_COMPAT] I wasn't supposed to bump the PBC major version, this is just a dev release
14:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40622/
14:52 mikehh All tests PASS (pre/post-config, test, fulltest) at r40621 - Ubuntu 9.04 amd64 (g++)
14:59 NotFound No tab in 5.1 and 5.2 PBC_COMPAT entries, they are filled with spaces.
15:00 NotFound Can't we kill this format and use some human readable separator
15:00 NotFound ?
15:00 Whiteknight NotFound: please
15:01 Whiteknight fixed the file
15:02 dalek parrot: r40623 | whiteknight++ | trunk/t/native_pbc (4 files):
15:02 dalek parrot: [PBC_COMPAT] rolled back the updated PBCs since I shouldn't have bumped PBC_COMPAT
15:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40623/
15:02 dalek parrot: r40624 | whiteknight++ | trunk/PBC_COMPAT:
15:02 dalek parrot: [PBC_COMPAT] change spaces to tabs again
15:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40624/
15:03 Whiteknight okay, the release is 100% ready to go. Just need to commit and tag. ~57 minutes
15:25 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40624 - Ubuntu 9.04 amd64 (gcc)
15:26 theory joined #parrot
15:34 Coke for those of you that remember mdiep, I hear he's getting married this weekend.
15:34 Coke mdiep++
15:45 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
16:00 davidfetter joined #parrot
16:09 Whiteknight Release happening now.
16:10 NotFound Go, go,
16:10 NotFound go!
16:11 mj41 Whiteknight: some test fails on win32 http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk
16:12 dalek parrot: r40625 | whiteknight++ | trunk (9 files):
16:12 dalek parrot: [RELEASE] Release 1.5.0
16:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40625/
16:12 dalek parrot: r40626 | whiteknight++ | branches/RELEASE_1_5_0:
16:12 dalek parrot: [RELEASE] tagging 1.5.0 release
16:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40626/
16:12 PerlJam Whiteknight++
16:12 Whiteknight well, too late!
16:13 Whiteknight 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
16:13 mj41 on vmware
16:14 Whiteknight oh, okay.
16:14 mj41 err sorry, no vmware, only cygwin is vmware
16:14 Whiteknight I'm mingw on Win32 and saw no errors
16:18 mj41 ok, will try to setup fresh win32 mingw vmware, my machine is probably broken somehow
16:20 mj41 I was trying to debug t/src/extend.t ... http://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 mj41 I have no ICU installed
16:27 Topic for #parrotis now http://www.parrot.org | http://planet.parrot.org | 1.5.0 "TEH PARROTZ!"  Released! | Feature freeze over, coders start your engines!
16:28 mj41 joined #parrot
16:29 jonathan lol...release name win!
16:30 dalek tracwiki: v93 | whiteknight++ | WikiStart
16:30 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=93&action=diff
16:31 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!
16:31 dalek website: http://www.parrot.org/news/2009/Parrot-1.5.0
16:34 mokurai joined #parrot
16:35 HG` joined #parrot
16:43 smash joined #parrot
16:43 smash hello everyone
16:43 payload joined #parrot
16:43 Whiteknight hello smash
16:51 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40626 - Ubuntu 9.04 amd64 (g++)
16:53 dalek TT #702 closed by whiteknight++: Remove stacks.c and stack-related ops
16:55 Coke smash: hey. Did you decline your nom nom nomination?
16:55 dalek parrot: r40627 | NotFound++ | branches/auto_attrs (80 files):
16:55 dalek parrot: merge from trunk r40626
16:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40627/
16:55 Coke (I saw you nominated and then not on the final list, which confused me.)
16:56 Whiteknight I can't mark the 1.5 milestone "Completed" on trac. The box is greyed out for me
16:56 Coke checking.
16:57 Coke perhaps you need super admin privs.
16:58 Coke try now.
16:58 particle confused me, too
16:58 Whiteknight works!
16:59 Coke particle, you are now an admin.
16:59 Coke (i mean, before I touched anything)
16:59 particle the nomination list confused me
16:59 Coke oh!
17:00 bkuhn joined #parrot
17:03 riffraff joined #parrot
17:04 Coke is rakudo now succesfully overriding the "invoke" vtable?
17:05 Coke Whiteknight++ # trolling for RMs.
17:06 jonathan Coke: Yes.
17:07 jonathan Coke: But only because we subclass the Object PMC. ;-)
17:07 jhorwitz joined #parrot
17:07 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. =-)
17:08 * Coke wonders if there is anyway to really subclass the ParrotInterpreter.
17:08 Coke (... and have it used whenever someone creates a new interp)
17:09 theory joined #parrot
17:21 * Coke hurls http://code.google.com/p/p​artcl/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 #parrot
17:24 brooksbp Are there any popular languages that allocate stack frames on the heap?
17:24 jonathan Coke: Yes, it was..."fun". :-)
17:27 dalek parrot: r40628 | NotFound++ | trunk (59 files):
17:27 dalek parrot: merge auto_attrs branch into trunk
17:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40628/
17:30 Coke NotFound: the "#if 0" concerns me.
17:31 NotFound Coke: I left it just in case someone wants to do some quick becnchmark between fixed size allocator and mem_sys
17:32 smash Coke: i revoked my voluntereed state
17:32 ttbot NotFound: Parrot trunk/ r40628 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/73018.txt
17:34 NotFound Error -1073741819 ? What's that?
17:35 jonathan NotFound: Convert to hex...
17:35 jonathan If it matches C0000005 then it's a segv.
17:36 pmichaud #ps in 54
17:36 NotFound I suspect a lack of realclean
17:37 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 Whiteknight if we use it consistently we could cut a lot of overhead out
17:37 mj41 NotFound: ttbot is doing make on fresh svn copy
17:38 NotFound Is there some human buliding on windows?
17:39 mj41 NotFound: see http://tt.ro.vutbr.cz/buil​dstatus/pr-Parrot/rp-trunk ... there is also http://tt.ro.vutbr.cz/file/cmdout/73025.txt
17:41 smash Coke: it turned out i wasn't skilled enough
17:42 NotFound Why on earth are someone defning his own version of LLONG_MAX and such macros?
17:43 Whiteknight those aren't defined on Win64
17:44 Whiteknight well, Win64 with MSVC64
17:44 NotFound Then don't use it
17:44 Whiteknight have to use it, sizeof(long) on those systems is 4
17:44 Whiteknight and then sizeof(long) != sizeof(void*) which causes huge build problems
17:44 NotFound The comments in the file says: * Define the values for PARROT_INTVAL_MAX and PARROT_INTVAL_MIN
17:44 NotFound Then do that instead of playing with foreign macros.
17:45 Whiteknight You're welcome to change that if you want
17:45 NotFound I don't have msvc compilers
17:47 chromatic joined #parrot
17:51 cotto Whiteknight++ for getting out the release before #ps
17:51 smash Whiteknight++ # release
17:52 chromatic pie++
17:54 Whiteknight pie++
17:54 Whiteknight I only do the releases for all the free karma :)
17:56 joeri joined #parrot
17:59 Coke pie?
17:59 purl it has been said that pie is true. or http://www.piecouncil.org/national.htm or http://london.randomness.org.uk/wiki.cgi?action=in​dex;format=map;index_type=category;index_value=Pie or http://www.austinthirdgen.org/upload/piechart.jpg or http://www.weebls-stuff.com/wab/ or http://flickr.com/photos/cowfish/3137913195/ or http://dilbert.com/fast/2009-03-07/
17:59 Coke wah, no room for the cool dr. horrible pie quote.
17:59 Infinoid pie is also position-independent executable (like PIC libraries but more so)
17:59 purl okay, Infinoid.
18:02 chromatic Sometimes quotes executables are layered like that.
18:03 Util Whiteknight++ # release
18:03 Coke chromatic-- # thwap thwap
18:05 dalek parrot: r40629 | NotFound++ | trunk/config/gen/platform/​generic/platform_limits.h:
18:05 dalek parrot: [cage] ugly attempt to fix LLONG_MAX related problems
18:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40629/
18:07 allison iz in ur computer, runnin ur languages
18:09 Whiteknight I figured "TEH PARROTZ!" would either be a fun little name or a head-slapping embarassement
18:09 barney joined #parrot
18:09 Whiteknight I was hoping for the former :)
18:11 ttbot NotFound: Parrot trunk/ r40629 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/73070.txt
18:11 Whiteknight all these good projects going on is very exciting!
18:13 allison Whiteknight: I think it's great :)
18:14 jonathan #ps is in 15 mins, yes?
18:14 cotto jonathan, yup
18:15 * jonathan refrains from going to dinner
18:15 cotto NotFound, don't forget to delete the auto_attrs branch
18:16 NotFound cotto: I'll try to first learn how to delete branches without risk of deleting trunk ;)
18:17 Whiteknight NotFound: it's "sudo rm -rI /"
18:17 smash NotFound: deleting trunk it's not that big of a problem
18:17 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40628 - Ubuntu 9.04 amd64 (g++)
18:17 Whiteknight NotFound: just kidding, don't type that!
18:18 NotFound Whiteknight: too late, is running
18:18 NotFound ;-)
18:19 Whiteknight Coke: bevity++
18:19 Whiteknight brevity*
18:20 dalek parrot: r40630 | Util++ | trunk/src/packfile.c:
18:20 dalek parrot: Fixed an error in packfile.c reference to pbc_header.pl. Courtesy of dukeleto++
18:20 dalek parrot: �http://irclog.perlgeek.de/p​arrot/2009-08-15#i_1396510
18:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40630/
18:20 Coke Whiteknight: I left out the snarky "nothing that anyone would care about". =-)
18:22 dalek rakudo: 6c7b8b3 | jnthn++ | build/PARROT_REVISION:
18:22 dalek rakudo: Bump us up the the current Parrot release, in preparation for the next Rakudo release.
18:22 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​c7b8b3b3dca9366eb7948111645c2bcdeaba39a
18:22 chromatic Hm, Parrot startup is 2.874% faster today than it was last night.
18:22 ttbot Util: Parrot trunk/ r40630 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/73121.txt
18:22 Whiteknight hmm, it must be something i did
18:22 davidfetter not 2.873%?
18:22 Whiteknight :)
18:23 * davidfetter always amused by figures that don't have error bars or like kind
18:23 chromatic According to callgrind output anyway.
18:23 davidfetter measure with a micrometer; draw with chalk; cut with an axe
18:23 davidfetter ;)
18:23 NotFound Maybe auto_attrs+fixed size allocator has something to do with that
18:23 chromatic My guess is auto_attrs.
18:23 chromatic I'll look at the profile in a bit.
18:24 Coke davidfetter++
18:25 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 #parrot
18:27 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
18:27 Whiteknight in theory, anyway
18:27 purl hmmm... in theory is my pants or it's too dark to read or somewhat intrusive to David Wheeler
18:27 dalek parrot: r40631 | NotFound++ | branches/auto_attrs:
18:27 dalek parrot: delete auto_attrs branch after merging to trunk
18:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40631/
18:28 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
18:28 theory purl++
18:29 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
18:29 Whiteknight well, it is a mess
18:31 NotFound purl is working on the gc?
18:32 Whiteknight might as well be
18:32 allison NotFound: anything stored in registers is always marked
18:33 NotFound Good to know
18:35 jonathan fail...joined #parrotsketch on wrong server...
18:35 Coke jonathan?
18:35 purl i heard jonathan was mailto:jnthn@jnthn.net or trying to put together a grant application. or however seeing weird issues.
18:36 jonathan Also forgot to pre-paste. Fail.
18:37 brooksbp Are there any languages that allocate stack frames on the heap?
18:39 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.
18:39 Whiteknight because it's not really possible. by definition, a "stack frame" is always on the stack
18:39 jonathan So all languages running on Parrot have their invocations records living on the heap.
18:39 jonathan If that is what you mean.
18:39 Whiteknight right, Parrot's "stack frames" are more accurately called "Contexts" and are created on the heap
18:44 brooksbp No, for compiled languages.
18:44 brooksbp Heap-allocated stack frames
18:45 NotFound Thread packages usually allocate in the heap the stack space for threads other than the main one.
18:46 brooksbp NotFound: could you provide any references or papers on this?
18:48 Whiteknight I'm not sure that's accurate. Again, by definition,"stack frames" are on the stack
18:49 NotFound Yes, doing it for each frame must be done by the compiler in a function by function basis
18:50 NotFound brooksbp: the references are the documentation of the thread creation functions.
18:56 dalek parrot: r40632 | whiteknight++ | trunk/docs/project/release_manager_guide.pod:
18:56 dalek parrot: Adding dukeleto++ as release manager for Oct
18:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40632/
18:58 ttbot whiteknight: Parrot trunk/ r40632 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/73189.txt
18:59 Whiteknight don't give me that shit, ttbot, I didn't break no build!
19:00 mj41 Whiteknight: sorry, ttbot is too stupid :-(
19:04 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"
19:04 jonathan What do you mean by "passing it as an invocant"?
19:05 allison jonathan: object."foo"(bar, baz)
19:05 allison jonathan: object is an invocant
19:05 pmichaud No.
19:05 pmichaud that's not the question.
19:05 pmichaud object.$P0(bar, baz)
19:05 allison pmichaud: that's half the question
19:06 pmichaud and $P0(object, bar, baz)
19:06 jonathan OK, let me give an example of what I'm expecting to work.
19:06 jonathan Suppose I have this:
19:06 jonathan .sub 'foo' :method
19:06 jonathan .param pmc args :call_sig
19:06 jonathan ...
19:06 jonathan .end
19:06 jonathan And I (somehow) end up with the sub object mapping to that in $P0
19:06 jonathan Will both
19:06 jonathan a.$P0(b, c)
19:06 jonathan and
19:07 jonathan $P0(a, b, c)
19:07 jonathan Result in a CallSignature with three positionals, a, b and c?
19:07 allison If you invoke a method object as a sub ($P0(a, b, c)) it won't receive any argument marked as an invocant
19:07 allison and will complain about a missing parameter
19:07 jonathan That's going to break things.
19:08 chromatic Good.
19:08 Coke what if you could explicitly say $P0(a :invocant, b, c). would that make everyone happy?
19:08 jonathan chromatic: Erm. How exactly?
19:08 chromatic It's broken in Perl 5.  Very badly broken.  Discontinuing that kind of brokenness is Very Good.
19:08 allison Coke: that would work
19:08 pmichaud Coke: we don't always (easily?) have enough information to be able to know to flag an invocant
19:09 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 jonathan And have both bind a to self.
19:09 pmichaud Perl 6 expects this behavior as a core semantic.
19:09 allison jonathan: I don't believe that actually works now.
19:09 pmichaud it does work now.
19:09 Coke so you can't figure out at runtime if $P0 is a method or not?
19:10 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.
19:10 chromatic I can't believe that Perl 6 allows you to invoke methods as if they were subs; what am I missing?
19:10 allison that can't have worked, because invocants aren't currently passed as parameters at all
19:11 jonathan chromatic: is export, perhaps?
19:11 allison they're stored as 'interp->current_object'
19:11 pmichaud methods can be invoked as subs currently, yes. (more)
19:11 pmichaud the first argument ends up being 'self'
19:11 chromatic That's the first thing I fix in Perl 7 then.  Yuck.
19:11 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 #parrot
19:13 japhb implementation accident ...?
19:13 chromatic I can't get behind that idea.
19:13 TimToady the invocant has to be available as a parameter *anyway*, so why treat it as out-of-band?
19:14 chromatic Because invocants are special.
19:14 TimToady not that special
19:14 chromatic That's why we have a special noun to describe them.
19:14 TimToady they are important to the dispatcher
19:14 TimToady that's all
19:14 chromatic They're important inside method bodies too.
19:14 TimToady and we want to be able to write dispatchers in p6
19:15 nopaste "pmichaud" at 72.181.176.220 pasted "invocant passed as argument" (24 lines) at http://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
19:15 TimToady as subs
19:16 allison TimToady: well, that's changing in the new system, interp->current_object goes away
19:16 allison but, we do mark invocants, and a parameter marked as an invocant is treated specially
19:16 chromatic If you can mark an invocant when you invoke something invokable, does the problem still exist?
19:16 allison most languages have a sharp distinction between the invocant and the rest of the arguments
19:17 allison 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".
19:18 jonathan (And other languages that feel the same way.)
19:18 TimToady *cough* python *cough*
19:18 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
19:18 allison in which case, you don't care
19:18 pmichaud we care that the invocant be available in the call signature, though
19:18 jonathan allison: It may cause us some language inter-op issues.
19:18 pmichaud which is jonathan's exact question
19:19 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
19:19 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
19:19 allison we don't modify the call signature after setting 'self'
19:19 allison (we never modify the call signature)
19:19 pmichaud but you're saying that 'self' isn't treated like a positional in that case
19:20 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
19:20 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"?
19:20 allison basically, what features do you need to support, and what PIR syntax are you currently using to support it
19:21 allison (just for dispatch)
19:21 pmichaud first, I think that jonathan's question isn't about dispatch as much as invocation (more)
19:21 pmichaud but for dispatch we need to be able to invoke methods as both    object.<something>(args)   and   <something>(object, args)
19:22 pmichaud we don't need Parrot to automatically look up <something>
19:22 pmichaud well, I should rephrase this last part
19:22 pmichaud object.'foo'(args) should work as it does now
19:22 pmichaud i.e., look up 'foo' as a method on object
19:22 pmichaud 'foo'(object, args) should work as it does now
19:22 pmichaud i.e., do a 'find_name' on 'foo', and invoke that as a sub
19:23 pmichaud 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
19:23 pmichaud $P0(object, args) should work as it does now, invoking $P0 and passing object as 'self'   (when $P0 is flagged as :method)
19:23 jonathan allison: OK, then that's a big part of what we want.
19:23 allison (you'd be free to ignore the extra 'i', but parrot respects it)
19:23 pmichaud did I miss anything on dispatch, jonathan?
19:24 jonathan allison: The only place we need clarify is on what the "i" there implies.
19:24 jonathan 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?
19:25 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...)
19:25 jonathan allison: OK, and there will be a way to say to Parrot, "please don't do that check"?
19:25 chromatic I've used CGI.pm.  I'm not happy with that.
19:29 * allison distracted at the moment wrapping up #parrotsketch, will read pmichaud's dispatch info in a minute
19:36 mikehh dukeleto: IIRC a signalling Nan is expected to generate an exception, a quiet Nan not
19:36 Infinoid "NaN but die"
19:37 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 ;_}
19:37 mikehh bah :-}
19:38 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.
19:38 pmichaud allison: p6 doesn't require using : to mark the invocant argument
19:38 jonathan allison: And we shouldn't have to.
19:38 pmichaud $foo($object, $arg)   is perfectly valid in Perl 6, even if $foo is a method.
19:39 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.
19:39 jonathan allison: But there has to be a way to say to Parrot, "don't worry about that"
19:39 allison the lazy solution would be to add a ":maybeinvocant" modifier
19:39 pmichaud alternatively, perhaps we could always mark our first argument as an invocant :-)
19:40 jonathan lol!
19:40 TimToady I wasn't going to say that...
19:40 TimToady but I thunk it...
19:40 jonathan That's a rebellion, not an ideal solution. ;-)
19:40 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
19:40 allison it's like :lookahead, in that it checks one thing and does another
19:40 jonathan allison: Not really. It's just like asking for a check not to be made.
19:40 pmichaud i.e.,  $P0(a :invocant, b, c)   will throw an exception if $P0 is not a method
19:40 allison that is, check if I need an invocant, and if so, use it as one, otherwise pass as the first argument
19:41 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
19:41 l3t0 mikehh, Infinoid: i was familiar with the concept but wanted to know what kind of exceptions should be thrown
19:41 jonathan allison: I think it wants to be a flag on the receiver, not on the caller side.
19:41 allison TimToady: all you're really doing is not throwing an exception
19:42 pmichaud flag on receiver:   exactly
19:42 TimToady dispatch will be faster if you don't check at all :)
19:42 allison TimToady: so it's more like "be permissive" than "perform an introspective check"
19:42 TimToady and we want fast dispatch
19:42 mikehh l3to: a Nan of vcourse :-}
19:43 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
19:43 TimToady p5 is slow because it keeps checking this and checking that
19:43 pmichaud allison: but why check the arguments -- why not let the sub itself say "I don't care" in the parameters
19:43 allison TimToady: and, yes, would allow it to skip some code
19:43 allison pmichaud: what would that mean, though?
19:43 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?
19:44 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 pmichaud that implies that the sub *doesn't* want parrot imposing its own checks on the bindability of arguments
19:44 allison jonathan: right now, it would still complain if you call a method and don't give it a Pi argument
19:44 jonathan allison: Why though?
19:44 allison (because it has to figure out what to set 'self' to, and that isn't bypassed)
19:45 TimToady we would love to kill that very dead
19:45 jonathan Oh.
19:45 pmichaud 'self' is always set to the first argument?  or no?
19:45 pmichaud I'm also fine if :call_sig doesn't set a 'self'
19:45 allison we can get rid of 'self', though :)
19:45 jonathan allison: I was figuring part of the unpacking would involve setting up a self if needed.
19:45 jonathan That is, Parrot really doesn't do much at all for you other than just hand over the CallSignature.
19:46 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.
19:47 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"
19:47 pmichaud so, a sub that specifies a .param of :call_sig gets no argument checking from Parrot?
19:47 allison pmichaud: and doesn't set 'self'
19:47 pmichaud that's fine.
19:47 pmichaud I'm happy with that if jonathan++ is.
19:48 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
19:48 jonathan That sounds just what I want.
19:48 pmichaud in Rakudo we don't even need a 'self' register anyway, because 'self' is a lexical
19:48 jonathan Well, lexicals live in registers, but yes, we need to handle it as a lexical.
19:49 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
19:49 jonathan pmichaud: Ah, OK.
19:49 allison it's a stupid pain
19:49 allison and a hack
19:50 pmichaud that sounds like TimToady++'s position :-)
19:50 allison well, I'd replace it with .param pmc foo :invocant
19:51 allison so, I still want it explicitly marked
19:51 dalek TT #895 closed by NotFound++: Towards automatic allocation and deallocation of PMC attributes
19:52 pmichaud I'd want it to work even if not marked, though :-)
19:53 jonathan So let me try and summarize.
19:53 jonathan $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.
19:53 jonathan Default Parrot semantics will change such that a Sub flagged with :method will only accept a signature whose first item is a Pi.
19:53 jonathan :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.
19:53 jonathan Does everyone agree that is where we're at so far?
19:53 pmichaud +1
19:53 purl 1
19:53 jonathan no purl, +1 is <reply>-1
19:53 purl okay, jonathan.
19:54 jonathan .oO( heh, heh )
19:54 allison jonathan: yes, but the Pi required will only change on a deprecation cycle
19:54 allison jonathan: (i.e. 2.1)
19:54 jonathan allison: OK.
19:54 jonathan 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.
19:55 allison the :call_sig can happen now, since it's an addition
19:55 allison jonathan: that I can't guarantee
19:55 jonathan While all Perl 6 code (that is, code that Rakudo emits) will use :call_sig... (more)
19:55 allison jonathan: that is, it needs a lot more thinking about the use
19:56 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
19:56 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.
19:56 pmichaud the current parrot behavior is that passing an invocant as an argument does not throw an exception
19:56 pmichaud so changing it to throw an exception should be at the deprecation point
19:56 pmichaud not vice-versa
19:56 allison pmichaud: what syntax/behavior do you mean?
19:56 pmichaud in other words, Parrot currently *does not* do a check of its arguments
19:56 hercynium joined #parrot
19:57 pmichaud so the addition of checking arguments should only occur at a deprecation point
19:57 Coke msg purl +1
19:57 purl Message for purl stored.
19:57 Coke bad coke.
19:57 allison Parrot doesn't currently have any way to mark an invocant except that invocants aren't passed in the argument list at all
19:57 allison they're currently "out of band" parameters
19:57 allison (interp->current_object)
19:57 NotFound Don't forget the vtable invoke issue.
19:57 pmichaud allison:  I'm talking about the current  $P0(a, b, c)   syntax
19:58 pmichaud currently Parrot does not complain if $P0 is a method
19:58 pmichaud i.e., 'self' is bound to 'a'
19:58 allison which was bad design (that dates back to the earliest parrot calling conventions)
19:58 allison pmichaud: right, that's what jonathan was talking about with the Pi marking
19:58 pmichaud my point is that "suppress the check" should be the behavior even before the deprecation point
19:59 pmichaud and that making the check should occur after the deprecation point
19:59 allison the deprecation point is adding the check
19:59 pmichaud okay.
19:59 jonathan pmichaud: That's what allision said.
19:59 pmichaud I misread "that I can't guarantee" then.
19:59 jonathan 21:54 <@allison> jonathan: yes, but the Pi required will only change on a deprecation cycle
19:59 pmichaud oh, I see
19:59 pmichaud Okay.  pmichaud--
19:59 jonathan pmichaud: I think that was in response to my suggestion that we provide another way to suppress the check.
19:59 pmichaud jonathan was asking about the case of not doing your own.... right
20:00 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
20:00 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
20:01 TimToady but what do I know? :)
20:01 allison well, there is an interaction between dispatch and binding, they have to meet in the middle
20:01 chromatic I like the idea of that orthogonality, but I really dislike making that orthogonality look like Normal Sub Invocation.
20:01 allison but, what we may do is deprecate the automatic 'self' binding
20:02 allison 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
20:02 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.
20:02 allison everything else is "whatever you declare in your parameters determines the semantics of binding"
20:03 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...?
20:03 allison aye, the current refactor doesn't really touch on this (it doesn't change semantics, just the internals)
20:04 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.
20:05 pmichaud okay.  That's consistent with what I see.
20:05 pmichaud and once :call_sig is in place we can start on our rakudo binding refactors
20:05 chromatic goto/branch/invoke continuation is more primitive than sub; why stop at sub?
20:06 allison chromatic: ?
20:06 jonathan pmichaud: We can start using it in Rakudo, yes.
20:06 pmichaud hopefully I'll be a good ways along on contextuals by then
20:06 pmichaud that seems very likely.
20:06 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.
20:06 jonathan Since I know now what we cna expect from Parrot.
20:06 allison chromatic: oh, you mean lorito
20:07 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?"
20:07 pmichaud jonathan: I think we both have a sense of the overall direction now so we just need to bring the various pieces together
20:07 * pmichaud is excited to be seeing progress on this front.
20:08 jonathan pmichaud: Remember I'm spending a lot of september wandering around Asia. ;-)
20:08 pmichaud jonathan: noted.
20:08 allison chromatic: I have to agree, but <shrug> :)
20:08 Whiteknight if we can do the final work to make Subs subclassable properly, and if CallSignatures are subclassable, there is no issue
20:08 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.
20:08 pmichaud Whiteknight: unless you want PGE to always be using its own sub PMCs, sure.
20:08 jonathan I'll start on that this month.
20:09 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/
20:09 pmichaud 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.
20:09 Tene chromatic: I've been thinking the same thing lately.
20:10 pmichaud jonathan: but I'm thinking even with your asia jaunts the timings all work out about right.
20:10 pmichaud it gives me a little room to get the pge stuff in place.
20:10 jonathan pmichaud: My wanderings in Asia give slack for PGE stuff to land and Parrot calling conventions stuff to land.
20:11 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 pmichaud jonathan: exactly.
20:11 jonathan OK, I think we have a plan.
20:11 Whiteknight pmichaud: if it's an HLL override, conceivably that mapping would be done by parrot internally
20:11 pmichaud Whiteknight: I don't see any way to do that presently.
20:11 Whiteknight that is, you wouldn't specify the subclass on a per-sub basis
20:11 pmichaud because HLL overrides are runtime
20:12 pmichaud and sub compilation is compile-time
20:12 Coke you can put the HLL overrides in an immediate block.
20:12 pmichaud immediate blocks aren't stored in .pbcs
20:12 pmichaud (we've had this conversation before)
20:12 darbelo joined #parrot
20:12 pmichaud in general the question is one of thaw+freeze a dynamic pmc type
20:13 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:14 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
20:14 pmichaud (yes, I'll argue that they should.  The point is that currently they don't)
20:14 Coke k.
20:14 Coke allison: why not a hash for returns, too!
20:16 allison Coke: :) well, we could support ('foo' => $P1, 'bar' => $P2) = 'sub'('baz')
20:16 Whiteknight that would actually be very cool
20:16 pmichaud I think that's already supported.
20:16 jonathan Don't we already support taht?
20:16 Whiteknight I can't imagine where it would be used, but cool idea nonetheless
20:16 allison and, insanely simple
20:16 allison I'm not aware of any languages that actually use it
20:17 pmichaud No, but it's been defined in the calling conventions pdd before.
20:17 allison has it?
20:17 pmichaud yes.
20:17 jonathan Yes, for sure.
20:17 purl like totally!
20:17 allison maybe one of the much older drafts
20:17 pmichaud no, it sat around for a very long time in the pdd description of calling conventions
20:17 pmichaud same for handling of :optional and :slurpy and other flags
20:18 allison well, we may support it one day, if a language needs it
20:18 pmichaud pdd03 -- line 393
20:18 pmichaud (i, j :optional, ar :slurpy, value :named('key') ) = foo()
20:19 allison but not in this refactor! (detecting a note of creature feep)
20:19 pmichaud note that it already exists.
20:19 pmichaud in the current pdd03.
20:19 payload joined #parrot
20:19 pmichaud and PGE *does* depend on :optional working there
20:20 pmichaud (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
20:20 allison pmichaud: that's a code example
20:21 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.
20:21 allison yah, I'm interested in alternate re-syntaxes too
20:22 allison (BNF, anyone?)
20:22 nopaste "pmichaud" at 72.181.176.220 pasted "named return arguments already supported in Parrot" (15 lines) at http://nopaste.snit.ch/17585
20:22 Coke hee!
20:24 allison heh :)
20:25 allison fortunately, I'm not really modifying that code
20:25 pmichaud fortunately.  :)
20:26 allison it's logical, but it may be 20 years before anyone uses
20:26 allison perhaps someone will be inspired to invent a new language just to take advantage of it. :)
20:26 pmichaud note that using   :slurpy  in an argument return list is currently used by P6object
20:27 pmichaud and Rakudo.
20:27 pmichaud rakudo also needs :slurpy :named
20:27 allison if :slurpy and :named work now, I can't see any reason :slurpy :named wouldn't
20:28 pmichaud right
20:28 pmichaud just making sure the calling refactor doesn't break them :)
20:28 allison are there tests for them? that's the surest way to make sure the refactor doesn't break it
20:28 pmichaud yes, there are
20:28 TimToady is that because we currently return Capture?  if so, returning Parcel presumably would just want positionals...
20:28 allison then it's all good
20:29 pmichaud oh, there's test for :slurpy, but not :slurpy :named
20:29 pmichaud I'll see about adding a couple.
20:30 payload joined #parrot
20:30 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:31 pmichaud have to be afk for a bit
20:38 davidfetter joined #parrot
20:41 chromatic The performance improvements are all related to fewer malloc/calloc/free calls.
20:43 Coke chromatic: any idea if those are from post-1.5.0?
20:43 chromatic Yes, they are.
20:43 chromatic 10.89% performance improvement in the primes.pasm benchmark.
20:44 chromatic I think it's the auto_attrs merge.
20:45 chromatic msg Whiteknight I'm happy to do a release when needed.
20:45 purl Message for whiteknight stored.
20:49 chromatic Yep, that's all auto_attrs behavior.  Very, very nice.
20:51 NotFound chromatic: goooooood :)
20:51 chromatic Now let's make PMCs with only one attribute faster....
20:51 dalek parrot: r40633 | chromatic++ | trunk/config/init/defaults.pm:
20:51 dalek parrot: [config] Added escaping for freaky characters in checkout paths.  This should
20:52 dalek parrot: clear up TT #930.  Testing very welcome on various platforms.
20:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40633/
20:52 mikehh I am getting a backtrace in t/tools/parrot_debugger.t - test 41 - it does a backtrace and reports ok 41?
20:55 ttbot chromatic: Parrot trunk/ r40633 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/73263.txt
20:56 chromatic Heh: src\packfile.c:1008:50: warning: "/*" within comment
20:57 dalek partcl: r599 | coke++ | trunk/runtime/ (2 files):
20:57 dalek partcl: Make this a .Const sub, move it where it's used.
20:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=599
20:58 bacek joined #parrot
21:03 mikehh chromatic: it builds on 'test parrot' BUT there are test failures
21:03 dalek partcl: r600 | coke++ | trunk/docs/spectest-progress.csv:
21:03 dalek partcl: This test run was slower since it wasn't an optimized parrot.
21:03 dalek partcl: Should really just track that from the parrot_config and report it in here.
21:03 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=600
21:03 dalek partcl: r601 | coke++ | trunk/runtime/tcllib.pir:
21:03 dalek partcl: Remove unused lookup table.
21:03 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=601
21:04 chromatic I'm working on those now, mikehh.
21:04 chromatic I saw your comment on the ticket right after I committed.
21:05 mikehh it also has some post-config test failures
21:05 mikehh NOT when running in parrot dir but in 'test parrot'
21:06 MoC joined #parrot
21:15 payload joined #parrot
21:18 joeri left #parrot
21:22 MikHel joined #parrot
21:24 dalek parrot: r40634 | mikehh++ | trunk/config/gen/platform/​generic/platform_limits.h:
21:24 dalek parrot: fix codetest failure - indent in config/gen/platform/generic/platform_limits.h
21:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40634/
21:27 fperrad joined #parrot
21:28 fperrad ping Whiteknight
21:28 purl I can't find Whiteknight in the DNS.
21:29 ttbot mikehh: Parrot trunk/ r40634 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/73322.txt
21:30 chromatic This Makefile hackery is a rat's nest of hate.
21:31 Coke to revisit my --optimize complaint - I should expect to be able to run with --optimize by default these days, no?
21:32 chromatic Yes.
21:32 chromatic I build with --optimize on by default.
21:32 Coke ok.
21:32 chromatic Now if your PMCs and dynops aren't optimize safe, you'll have a problem....
21:32 NotFound Note that autotools has problems building in paths with spaces, is not an easy problem.
21:32 Coke chromatic: I have very few of those; presumably that would be easy to check if you knew what you were looking for.
21:35 chromatic Anywhere you pass in what could be a NULL pointer where you assume you never do.
21:35 dalek parrot: r40635 | chromatic++ | trunk/config/init/defaults.pm:
21:35 dalek parrot: [config] Reverting r40633; this is the wrong approach to escaping freaky
21:35 dalek parrot: characters in paths in the Makefile.
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40635/
21:35 fperrad seen whiteknight
21:35 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 #parrot
21:38 dalek rakudo: b9c79c2 | jnthn++ |  (3 files):
21:38 dalek rakudo: 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 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​9c79c2175ac46b7ba7cbb393bc06c6f2db0646e
21:40 ttbot chromatic: Parrot trunk/ r40635 MSWin32-x86-multi-thread make error http://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
21:40 fperrad see item 7 in release_manager_guide
21:41 fperrad Whiteknight, I cannot see the tag svn.parrot.org/parrot/tags/RELEASE_1_5_0
21:43 Zak joined #parrot
21:43 davidfetter hei Zak
21:45 Whiteknight fperrad: well, I thought that I created it
21:45 Whiteknight so I must have broken something
21:45 Whiteknight irclogs?
21:45 purl i heard irclogs was http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
21:47 Whiteknight Ah, I created it in /branches/, not /tags/
21:49 dalek parrot: r40636 | whiteknight++ | tags/RELEASE_1_5_0:
21:49 dalek parrot: Should have been a tag, not a branch. Whiteknight--, fperrad++
21:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40636/
21:53 dalek parrot: r40637 | whiteknight++ | branches/RELEASE_1_5_0:
21:53 dalek parrot: [RELEASE] removing unnecessary branch
21:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40637/
21:57 Whiteknight eventually I'm going to get this whole release thing right
21:58 Whiteknight practice may eventually make perfect
22:02 ruoso joined #parrot
22:02 fperrad Whiteknight, another thing : could you review my patch on TT #113 ?
22:03 Whiteknight sure thing
22:07 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?
22:08 darbelo cotto: ping
22:08 cotto darbelo, pong
22:08 darbelo Just wanted to let you know: I accomplished nothing in the past week, but I am still alive.
22:09 Hunger joined #parrot
22:10 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.
22:11 darbelo Mail is more likely to reach me than purl msgs this week, though.
22:13 darbelo Sorry I left you hanging this week.
22:14 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?
22:15 darbelo cotto: Wasn't that yesterday?
22:15 cotto You're right.
22:15 cotto I somehow got it associated with #ps.
22:15 fperrad left #parrot
22:19 cotto I thought tsqueues were nuked from orbit a long time ago
22:20 dalek tracwiki: v30 | cotto++ | ParrotQuotes
22:20 dalek tracwiki: blessed be the tie that binds
22:20 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=30&amp;action=diff
22:24 dalek parrot: r40638 | chromatic++ | trunk/src/gc/gc_ms.c:
22:24 dalek parrot: [GC] Tided some code and removed some compiler warnings with casts.
22:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40638/
22:24 l3t0 cotto: you have the freedom to consider any work done by darbelo up until you submit your gsoc survey.
22:25 l3t0 the "firm" deadline was yesterday, but "firm" in the gsoc world is relative.
22:26 l3t0 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:27 ttbot chromatic: Parrot trunk/ r40638 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/73439.txt
22:28 Whiteknight NotFound: where is that #if 0 ?
22:31 NotFound Whiteknight: src/pmc.c and src/gc/api.c
22:31 NotFound Allocation and deallocation of attrs
22:32 NotFound Chnaging them to 1 revert to mem_sys
22:35 Whiteknight I'm setting these things to use a macro instead
22:35 Whiteknight so we can change it
22:37 NotFound I'm going to delete that if'ed code, then.
22:37 Whiteknight no, I'm working on it now
22:38 NotFound Ok
22:38 Whiteknight Just running a quick coretest before I commit
22:39 Whiteknight okay, committed in 40641
22:39 Whiteknight allison: ping
22:40 * Whiteknight just remembered a question he should have asked at #ps
22:40 rg1 joined #parrot
22:40 allison Whiteknight: yes?
22:41 Whiteknight allison: have you taken a look at the pmc_sans_unionval branch?
22:41 allison Whiteknight: I haven't
22:41 allison Is it pretty much ready to go?
22:41 Whiteknight It does two things: removes UnionVal, almost completely, and merges the PMC_EXT struct into PMC
22:41 Whiteknight yes, It's passed all my tests, although I can probably throw a few more at it
22:41 Whiteknight anyway, it's a big enough architectural change that I wanted to run it past you first
22:42 dalek parrot: r40639 | bacek++ | branches/tt795_kill_parrot_sub_structure (83 files):
22:42 dalek parrot: Bring branch up-to-date with trunk
22:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40639/
22:42 dalek parrot: r40640 | bacek++ | branches/tt795_kill_parrot_​sub_structure/t/native_pbc (4 files):
22:42 dalek parrot: Rebuild native PBC.
22:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40640/
22:42 dalek parrot: r40641 | whiteknight++ | trunk (2 files):
22:42 dalek parrot: [GC] change the allocator system to use a macro for fixed-size attribute allocations instead of just saying #if 0 in various places
22:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40641/
22:42 dalek parrot: r40642 | cotto++ | branches/pluggable_runcore (2 files):
22:42 dalek parrot: [profiling] fix some compiler warnings
22:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40642/
22:43 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 #parrot
22:44 ttbot whiteknight: Parrot trunk/ r40641 MSWin32-x86-multi-thread make error http://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
22:44 Whiteknight oh, nice feature
22:44 allison Whiteknight: what were you saying?
22:44 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
22:44 Whiteknight I think the branch is ready, I want to update it to trunk and run another rakudo spectest to double check
22:45 bacek_at_work Whiteknight: hey! my turn to merge branch!!!
22:45 allison does it have additional merges from trunk since it was started?
22:45 Whiteknight bacek_at_work: yes, you go first. I don't even have a green light yet!
22:46 bacek_at_work Whiteknight: ok.
22:46 Whiteknight allison: no, it's virgin
22:46 allison Whiteknight: okay, I'll look over the diff
22:47 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.
22:47 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
22:48 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 http://nopaste.snit.ch/17586
22:48 allison (I'm doing a quick pass now)
22:48 Whiteknight either or, I should be on IRC for another few hours (and purl msgs will be read early tomorrow morning)
22:49 Whiteknight 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
22:49 allison okay, I'll do a running commentary here, can bundle up into email later if needed
22:49 Whiteknight ok
22:50 allison src/ops/set.ops: Why are we still checking PObj_is_PMC_EXT_TEST?
22:50 allison since nothing is using pmc_ext?
22:50 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
22:50 Whiteknight better ways to go about that, I'm sure
22:52 allison The traditional route is to check if those pointers are non-null and mark them then
22:53 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
22:54 allison it's pretty cheap to just go ahead and set them to null
22:54 Whiteknight yeah
22:55 * bacek_at_work got green light on merged branch. Committing soon.
22:55 cono joined #parrot
22:55 allison lots of changes of PObj_* to Buffer_* make sense (buflen doesn't exist in PObj now)
22:56 * Coke yawns.
22:56 cotto Oh good.  The drugs are working.
22:57 * bacek_at_work wish drugs working instead of me
22:57 allison Whiteknight: is GC_MS_PObj_Wrapper generic?
22:58 allison Whiteknight: the name would seem to imply that it's only for gc_ms, but it's used in incremental_ms also
22:58 japhb joined #parrot
22:58 NotFound allison: I think Buffer is a too generic prefix for macros
22:59 Whiteknight allison, when I originally added that it was specific, but it's become more generic
22:59 Whiteknight a way to overlay a pointer on a PObj in order for the GC to organize them into a linked list
22:59 bacek_at_work Whiteknight: http://icanhascheezburger.files.wo​rdpress.com/2009/08/funny-pictures​-kitten-calls-you-weakest-link.jpg :)
22:59 dalek parrot: r40643 | bacek++ | trunk (30 files):
22:59 dalek parrot: Merge tt795_kill_parrot_sub_structure back to trunk.
22:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40643/
22:59 Whiteknight NotFound: I agree with that, it's also a lousy name for the datastructure
22:59 allison then, let's at least change it to GC_PObj_Wrapper
22:59 * bacek_at_work crossing fingers an watching ttbot
23:00 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 :)
23:00 Whiteknight GC_PObj_Bikeshed
23:01 bacek_at_work GC_PObj_thingy
23:01 Whiteknight GC_MS_PObj_Wrapper predates the branch though, I'll rename it separately
23:01 allison existing terrible names aren't a good reason to add new terrible names :)
23:01 allison okay, sensible
23:01 purl hmmm... sensible is usually inappropriate, yes :)
23:01 Whiteknight (want to keep the diff from growing too huge)
23:01 bacek_at_work But it consistent!
23:02 Whiteknight consistently terrible is the wrong kind of consistent
23:02 ttbot bacek: Parrot trunk/ r40643 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/73552.txt
23:02 Whiteknight WTF is happening on Win32?
23:02 Whiteknight that stupid bot has been freaking out all day
23:02 allison Whiteknight: when you do change the name, make sure it follows the coding standards (I'm sure the old names don't)
23:03 bacek_at_work NotFound branch broke Win32
23:03 Whiteknight will do
23:03 dalek partcl: r602 | coke++ | trunk/docs/spectest- (2 files):
23:03 dalek partcl: Hey, more spectest churn. :|
23:03 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=602
23:03 Whiteknight do we have any coders on Win32 who can actually look at it?
23:04 Whiteknight I guess I could boot up my other machine...
23:05 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
23:05 Whiteknight looking...
23:05 allison Whiteknight: if not used anymore, delete it (but I don't see it mentioned in the overall purpose of the branch)
23:06 Whiteknight it doesn't appear to be used anymore, no
23:06 Whiteknight mentioned in a few comments, but not used
23:06 Whiteknight I'll delete it
23:07 Limbic_Region joined #parrot
23:07 Limbic_Region jonathan ping
23:09 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
23:10 * Whiteknight is building a large TODO list
23:10 * Coke converts it to tickets.
23:10 allison would need to double check line 429 on context
23:10 allison in context
23:10 Whiteknight Coke: don't bother with tickets, these things will be fixed in branch
23:10 Whiteknight line 429 in context?
23:11 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:12 kid51 joined #parrot
23:13 Whiteknight yeah, that function could easily be reworked to not need that flag
23:13 Whiteknight In fact, that whole function can almost disappear
23:13 allison Whiteknight: oh yeah, because it checks PObj_is_PMC_shared_TEST next anyway
23:13 Whiteknight but that will take a little bit of energy
23:14 Whiteknight yeah, exactly
23:14 allison The function named 'Parrot_gc_free_pmc_ext', mmm... yes, likely removable
23:15 allison 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
23:15 allison and, wherever it was should have been freeing metadata anyway
23:16 Whiteknight right
23:16 smash should be there a .deb or .rpm built for release 1.5.0 ?
23:16 chromatic Parrot_gc_free_pmc_ext gets called by pointer, remember.
23:16 Whiteknight smash: Building those things isn't part of the normal release procedure, no
23:17 Whiteknight chromatic: yes. a quick ack brought that up
23:17 smash Whiteknight: i know it's not part of the release procedure
23:17 Coke Whiteknight: I'm not sure I want to see what a quick ack brought up.
23:17 Whiteknight smash: I'm sorry, I mis-read you
23:17 Whiteknight yes, those files should be made
23:18 Coke hurm. ==== expr-old-15.7 FAILED
23:18 Coke Failed allocation of 2043948 bytes
23:18 Coke 2043948 / 1024
23:18 purl 1996.04296875
23:18 Coke 1996 / 1024
23:18 purl 1.94921875
23:18 Coke 2Mb seems like a big single allocation.
23:18 Coke no?
23:18 purl no is DCC SEND "DHOSSLIKESTRANNIES" 0 0 0
23:19 Coke purl, no, no is <reply>Maybe.
23:19 purl okay, Coke.
23:19 l3t0 coke++
23:20 cotto What's wrong with transmissions?
23:20 cotto ;)
23:21 nopaste "kid51" at 70.85.31.226 pasted "Are all these branches still needed? Spoken for?" (22 lines) at http://nopaste.snit.ch/17587
23:21 * Coke suggests someone re-run the branch status script.
23:23 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
23:23 allison (probably removable, needs review)
23:23 Whiteknight yeah, ack turned up a handful of them
23:23 Whiteknight I'll kill them all, one way or another
23:24 allison chromatic: except Parrot_gc_free_pmc_ext doesn't get called at all anymore
23:25 chromatic It's part of one of the pool structs.
23:26 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
23:26 Whiteknight I suspect it is
23:27 Whiteknight 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.
23:31 allison Whiteknight: the UnionCallStateVal can go away after the pcc rewiring merge
23:38 allison Whiteknight: okay, done with the review, looks great!
23:39 Whiteknight awesome thanks!
23:39 Whiteknight I was pretty startled by this patch, came out of left-field and does so much
23:40 Whiteknight I'll make the changes we need and hopefully get it merged tonight or tomorrow
23:44 allison Whiteknight: yup, a nice surprise
23:45 cotto Whiteknight, thanks for adopting it.
23:46 Whiteknight no problem
23:46 Whiteknight somebody needs to
23:46 Whiteknight (and I've been secretly wishing for PMC_EXT to disappear for some time)
23:51 dalek parrot: r40644 | whiteknight++ | branches/pmc_sans_unionval (3 files):
23:51 dalek parrot: [pmc_sans_unionval] remove all references to the now-unused buffer_header_pool
23:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40644/
23:56 * Whiteknight really wants to kill the "high-priority" mark stuff in the GC
23:56 Whiteknight I'm becoming more and more convinced that it serves no benefit whatsoever
23:57 cotto Isn't that for timely destruction?

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced