Camelia, the Perl 6 bug

IRC log for #parrot, 2009-11-11

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 cotto_work I can confirm that the "nci_ssc" test fails, but I don't have 611 tests in that file.
00:01 plobsing Whiteknight: it appears gcc is only doing short->int extension
00:01 plobsing not short->long
00:01 plobsing this is a bug where int!=long
00:01 Whiteknight ah, that makes sense then
00:02 plobsing so my modification of the test had the intended effect :-)
00:04 plobsing cotto_work: the number of tests in that file is 71 + $num_nci_sigs
00:04 abqar joined #parrot
00:04 plobsing where $num_nci_sigs is the number of signatures to be thunked by nativecall.pl
00:04 dalek rakudo: f16c9e2 | pmichaud++ | docs/spectest-progress.csv:
00:04 dalek rakudo: spectest-progress.csv update: 451 files, 32696 (85.2% of 38389) pass, 15 fail
00:04 dalek rakudo: Failure summary:
00:04 plobsing so it will vary from config to config
00:04 dalek rakudo: S02-lexical-conventions/unicode.rakudo aborted 5 test(s)
00:04 dalek rakudo: S12-introspection/methods.t aborted 10 test(s)
00:04 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​16c9e2763e6326e2c6f2ea875717e1e11d6b75f
00:06 chromatic Hm, Rakudo passes more tests than before the great PCC conversion.
00:09 dalek TT #1263 created by jkeenan++: Determine configuration value for 'platform' prior to gen::platform
00:13 dalek TT #1194 closed by jkeenan++: 7 config steps improperly rely on Perl 5 %Config 'OSNAME' element
00:15 dalek parrot: r42413 | jkeenan++ | branches/platform_determine_earlier:
00:15 dalek parrot: Create a branch to work on https://trac.parrot.org/parrot/ticket/1263:
00:15 dalek parrot: determine 'platform' earlier than gen::platform.
00:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42413/
00:23 darbelo joined #parrot
00:24 darbelo I *really* hate it when X crashes.
00:33 nopaste "plobsing" at 76.67.61.178 pasted "ssc non-libjit fix" (13 lines) at http://nopaste.snit.ch/18632
00:34 japhb blizkost appears to have rotted ... or is it just me?
00:34 plobsing this is a quick fix. really all int types (at least signed ones) should be returning INTVALs
00:34 plobsing on the other side of the coin, we should be testing all supported signed int types with negative numbers to exercise sign extension
00:37 kiwichris joined #parrot
00:43 dalek parrot-plumage: 0d6374a | japhb++ | :
00:43 dalek parrot-plumage: [plumage] Simplify action functions considerably by improving CWD handli...
00:43 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/0d6374a21a9ba2f8d2d260fd0ea1b6c3997508c1
00:47 dukeleto parrot github repo should be sync'ing once per hour now, for your pleasure.
00:48 dukeleto also, git.or.cz now supports git mirrors of svn repos. i need to try that out.
00:53 kiwichris Looking at Parrot_new I see its decl states it cannot return NULL. What happens if memory runs out ?
00:54 plobsing msg Whiteknight http://nopaste.snit.ch/18632 should fix the ssc issue on non-libjit x86_64
00:54 purl Message for whiteknight stored.
00:56 * darbelo needs sleep
00:56 darbelo See y'all later.
00:56 darbelo left #parrot
00:56 dalek tracwiki: v2 | samlh++ | RakudoTasklist
00:56 dalek tracwiki: Prettify (probably unnecessarily)
00:56 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Ra​kudoTasklist?version=2&action=diff
00:56 Whiteknight plobsing: i'll take a look at it
01:00 dalek parrot-plumage: 8dcf4b2 | japhb++ | :
01:00 dalek parrot-plumage: [plumage] Use NQP-rx, stage 1: string interpolation
01:00 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/8dcf4b219b16e9561bf887588fc378fe816a0a10
01:03 Austin In the PMC documentation, is =head2 Methods supposed to introduce vtable items or method items?
01:04 Whiteknight method items, I assume
01:05 Austin It seems like the two are regularly conflated, so I'm wondering if I should report those as bugs, or submit patches, or what?
01:05 Whiteknight submit patches
01:06 Whiteknight or better yet, submit a CLA, get a commit bit, and get the karma yourself :)
01:06 Austin (e.g., undef.pmc has lots of vtable functions, but no methods. But it has a =head2 Methods section, not a =head2 Vtable ops or whatever.)
01:06 Austin If I could translate karma into frequent flier miles, maybe.
01:07 Whiteknight if you become a committer, you can qualify for our frequent flier program
01:07 Austin Off the top of your head, WhiteKnight, what methods should Undef have?
01:07 Whiteknight none
01:07 Austin None?
01:07 purl None is, like, :/
01:07 Austin :?
01:07 purl well, : is the path separator
01:07 Whiteknight .'segfault'()
01:07 Austin :-?
01:07 Whiteknight .'throw_weird_exception'()
01:07 Whiteknight .'magically_become_defined'()
01:07 Austin Ahh, you see, I've already defined 5 methods.
01:08 Austin You're just not trying.
01:08 Whiteknight maybe I'm trying hard, but am just really stupid?
01:08 Austin .can(), .does(), .defined(), .isa(), .new()
01:08 Whiteknight never overestimate me
01:08 Whiteknight all those on Undef?
01:08 Austin Yep.
01:09 Austin Meta-stuff should work just about anywhere. (Especially .defined())
01:09 Austin !!Especially!! defined()
01:09 Austin So why not make them methods?
01:10 plobsing what variant of the concept of nullity is Undef trying to provide? Perl5's? Perl6's? Language X's?
01:11 Austin plobsing: yes.
01:13 japhb <nihilism>It's all nothingness anyway ... why try to figure it out?</nihilism>
01:16 nopaste "kiwichris" at 203.206.130.106 pasted "RTEMS: parrot-1.7.0/examples/benchmarks/rand.pir fails." (106 lines) at http://nopaste.snit.ch/18633
01:17 Whiteknight plobsing: patch works. All tests pass here without libjit installed
01:17 Whiteknight next step is to install libjit
01:22 dalek parrot-plumage: 45792ee | japhb++ | :
01:22 dalek parrot-plumage: [plumage] Use NQP-rx, stage 2: pir::
01:22 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/45792ee797e3a9453dba3015d82151c42e0e0030
01:23 Whiteknight plobsing: Is LibJIT installed..../test_29443: error while loading shared libraries: libjit.so.0: cannot open shared object file: No such file or directory
01:23 Whiteknight for libjit, I did "./configure && make && sudo make install"
01:24 Whiteknight and I thought that worked
01:24 plobsing you need to run ldconfig
01:24 theory joined #parrot
01:25 Whiteknight I've got libjit.so.0 in my /usr/local/lib folder
01:25 Whiteknight what's ldconfig?
01:25 purl it has been said that ldconfig is not hard
01:25 Whiteknight thanks, purl
01:25 Whiteknight purl, thanks, purl is <reply>no, thank you
01:26 plobsing ldconfig updates your dynamic linker cache (from what I've gathered)
01:26 plobsing dynamic linking still seems a little voodoo to me
01:27 Whiteknight yeah, definitely voodoo
01:27 Whiteknight but I ran it, and now thigns work
01:27 plobsing yay
01:27 Whiteknight lobsing++
01:27 Whiteknight plobsing++
01:28 Zak joined #parrot
01:28 mikehh joined #parrot
01:33 Whiteknight plobsing: I've been thinking about the framebuilder. I think benefits could be had if we precompiled thunks for the NCI calls commonly used during startup, and delegated everything else to the framebuilder
01:33 plobsing thats probably true.
01:34 plobsing it should be possible to get nativecall.pl to do this
01:34 Whiteknight right, but we'd have to identify the calls that make the most sense to precompile
01:35 Whiteknight it's a small issue though, something we can save till later
01:35 plobsing config/gen/call_list/core.in maybe?
01:37 plobsing of course some of those aren't called by all programs
01:39 Whiteknight right, it would only make sense to precompile the ones that are called during startup
01:39 Austin Or just have the framebuilder log the ones that it builds, and then run it once.
01:40 plobsing Austin++ simplicity=genius
01:40 Austin Git 'r done.
01:40 Whiteknight plobsing: with libjit installed now, I fail that same test
01:40 Whiteknight nci_ssc
01:40 plobsing hmmm.
01:40 plobsing what number are you getting?
01:41 Whiteknight 65530
01:41 plobsing arg. improper sign extension, you are the bane of my existance!
01:46 plobsing fyi 65530 is better known as 2**16 - 6
01:47 Whiteknight ah yes, sign extension. My old nemesis
01:49 dukeleto what a day
01:49 purl somebody said a day was a reasonable time to wait for cpan to catch up
01:49 nopaste "plobsing" at 76.67.61.178 pasted "add proper sign extension for the nth time" (19 lines) at http://nopaste.snit.ch/18634
01:51 diakopter my PAST interpreter in JavaScript proceedeth.  it passes the first 10 nqp-rx test files
01:52 diakopter Tene: ^^ in case you were wondering..
01:52 plobsing oops that paste really shouldn't work!
01:52 plobsing I have no idea how it passed
01:54 Austin Man, tortoisegit is so damn slow I think it would be easier to run a separate git-gui app. :(
01:56 nopaste "plobsing" at 76.67.61.178 pasted "add proper sign extension for the (n + 1)th time" (19 lines) at http://nopaste.snit.ch/18635
01:56 dukeleto anybody have any thoughts about Go? http://golang.org/doc/go_faq.html
01:57 Whiteknight isn't that a game that I'm terrible at?
01:59 Whiteknight dukeleto: that looks very interesting
02:00 Austin Dude, that language will never succeed.
02:00 Austin Remember the rule.
02:01 dalek parrot: r42414 | cotto++ | trunk/DEPRECATED.pod:
02:01 dalek parrot: [DEPRECATED] clarify VTABLE deprecations currently eligible for removal
02:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42414/
02:05 plobsing and what rule is that exactly?
02:05 Austin No language with ':=' will ever succeed.
02:05 plobsing touche
02:05 Austin It's the operator of doom.
02:06 eternaleye joined #parrot
02:06 Whiteknight you only say that because pascal did it and pascal IS TEH SUXXOR
02:06 Austin Nope. Also PL/1, Modula, Oberon, Modula II, Modula III.
02:07 dukeleto Pascal uses := too
02:07 plobsing aren't most of those wirth languages?
02:07 Austin And let's not forget Ada, that uber-success story.
02:08 Whiteknight plobsing: no dice. Latest patch didn't fix the test failure
02:09 Austin Putting ':=' in your programming language is tantamount to saying "I don't want this to be used by anyone except a few undergrad students that I can coerce into using it by basing a 3-credit course on it."
02:09 plobsing nth or (n+1)th?
02:10 Whiteknight same test, nci_ssc
02:10 cotto ohai
02:10 Whiteknight hello cotto_not_at_work
02:11 Whiteknight but can't stay to talk. Need to go to sleep. Goodnight
02:11 cotto night
02:11 dalek parrot: r42415 | cotto++ | trunk/DEPRECATED.pod:
02:11 dalek parrot: [DEPRECATED] add notice about bitwise ops and VTABLE functions
02:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42415/
02:11 dalek parrot: r42416 | whiteknight++ | branches/libjit_framebuilde​r/lib/Parrot/NativeCall.pm:
02:11 dalek parrot: [libjit] apply one patch from plobsing++ to fix short conversions on x86_64 without libjit installed
02:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42416/
02:25 nopaste "plobsing" at 76.67.61.178 pasted "64-bit fix (now with 100% less syntax fail)" (19 lines) at http://nopaste.snit.ch/18636
02:26 plobsing msg Whiteknight this one aught to do it: http://nopaste.snit.ch/18636
02:26 purl Message for whiteknight stored.
02:40 dalek parrot-plumage: 70bda0e | japhb++ | :
02:40 dalek parrot-plumage: [CORE] Add %hash.values and @array.reverse
02:40 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/70bda0e3b2370079fe317b22ecbbd63da820c73a
02:40 dalek parrot-plumage: 294058c | japhb++ | :
02:40 dalek parrot-plumage: [plumage] Use NQP-rx, stage 3: pointy blocks in for loops
02:40 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/294058cf0d60cad7628a8d1ce03f7531076892da
02:41 dalek parrot: r42417 | jkeenan++ | branches/platform_determine_earlier (4 files):
02:41 dalek parrot: Create a Parrot::Configure attribute 'platform' in auto::arch; use it in
02:41 dalek parrot: gen::platform.  Adjust two configuration step tests accordingly.  Still need
02:41 dalek parrot: to adapt tests for _get_platform() in t/steps/auto/arch-01.t.
02:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42417/
03:06 dalek tracwiki: v118 | jkeenan++ | WikiStart
03:06 dalek tracwiki: https://trac.parrot.org/parrot/wiki/W​ikiStart?version=118&amp;action=diff
03:21 kiwichris msg rand fixed by statically linking dynops
03:21 purl Sorry, I've never seen rand before.
03:41 janus joined #parrot
03:43 elmex joined #parrot
03:53 DrForr_ joined #parrot
03:53 dalek parrot-plumage: 2891881 | japhb++ | :
03:53 dalek parrot-plumage: [plumage] Add status command; use grep() in get_installed_projects
03:53 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/2891881a8b78150ec2a2aec9b2407f382218ddf5
03:53 dalek parrot-plumage: bc02198 | japhb++ | :
03:53 dalek parrot-plumage: [META] TODO update
03:53 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/bc02198d6cd082268d2aff871f894d8436dc346c
04:02 hercynium joined #parrot
04:15 dalek parrot-plumage: b327f3c | japhb++ | :
04:15 dalek parrot-plumage: [plumage] Use NQP-rx, stage 4: git rid of as_array() in most places
04:15 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/b327f3c24bda311dc8665870e85d976716c74697
04:31 dalek tracwiki: v41 | bacek++ | ParrotQuotes
04:31 dalek tracwiki: Definition of "operator of doom"
04:31 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=41&amp;action=diff
05:05 kiwichris joined #parrot
05:29 cottoo joined #parrot
06:05 nbrown joined #parrot
06:06 theory joined #parrot
06:21 magnachef joined #parrot
06:39 mikehh joined #parrot
06:51 chromatic joined #parrot
07:03 victori joined #parrot
07:10 JimmyZ joined #parrot
07:11 payload joined #parrot
07:14 uniejo joined #parrot
07:25 bacek joined #parrot
07:59 iblechbot joined #parrot
08:10 barney joined #parrot
08:12 fperrad joined #parrot
08:18 payload joined #parrot
08:22 mokurai left #parrot
08:32 moritz http://golang.org/doc/go_lang_faq.html they use CSP for yet another thing
09:09 pdcawley_ joined #parrot
09:14 AndyA joined #parrot
09:28 victori left #parrot
09:52 dalek parrot: r42418 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
09:52 dalek parrot: [distutils] add chmod
09:52 dalek parrot: which needs ExtUtils::Command
09:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42418/
10:02 TiMBuS joined #parrot
10:36 jsut joined #parrot
10:54 elmex joined #parrot
10:56 AndyA joined #parrot
11:02 payload joined #parrot
11:48 AndyA joined #parrot
12:00 dalek parrot: r42419 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
12:00 dalek parrot: [distutils] add stuff for nqp-rx
12:00 AndyA joined #parrot
12:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42419/
12:03 bluescreen joined #parrot
12:04 mikehh joined #parrot
12:08 bluescreen joined #parrot
12:19 AndyA joined #parrot
12:31 payload joined #parrot
12:39 dalek parrot: r42420 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
12:39 dalek parrot: [distutils] add options : harness_exec & harness_files
12:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42420/
13:05 whiteknight joined #parrot
13:09 dalek parrot: r42421 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
13:09 dalek parrot: [distutils] split cp/install
13:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42421/
13:23 whiteknight good morning #parrot
13:27 plobsing hi whiteknight
13:27 whiteknight hello plobsing
13:27 whiteknight I'll test that new patch out tonight
13:27 plobsing sorry about the other two patches. turns out they didn't even compile
13:28 plobsing serves me right for doing configure; make; test instead of using &&
13:29 whiteknight oh
13:36 whiteknight yeah, I've gotten into those problems before
13:36 whiteknight I've developed a very elaborate alias "build" to do all those things in the right sequence
14:11 payload joined #parrot
14:18 whiteknight I think we should be able to get this branch merged soon
14:18 whiteknight pending more testing.
14:19 whiteknight what we probably want to do is write out a lot of instructions for people on how to get libjit
14:24 mj41 joined #parrot
14:35 pdcawley__ joined #parrot
14:46 whiteknight For anybody who is interested in JIT, here is a very interesting email exchange between the libJIT and LLVM guys:
14:46 whiteknight http://lists.gnu.org/archive/html/d​otgnu-libjit/2004-05/msg00012.html
14:46 whiteknight (gets a little heated, but that's to be expected. And they mention Parrot a lot)
15:01 patspam joined #parrot
15:20 Psyche^ joined #parrot
15:30 Essobi joined #parrot
15:31 Austin joined #parrot
15:32 bubaflub joined #parrot
15:47 theory joined #parrot
15:52 bubaflub morning parrot people
15:56 whiteknight good morning bubaflub
15:57 darbelo joined #parrot
15:57 dalek rakudo: a02a26e | (Kyle Hasselbacher)++ | tools/update_passing_test_data.pl:
15:57 dalek rakudo: tools/update_passing_test_data.pl: ignore spectest.data comments better
15:57 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​02a26ea384145c812b3d8d6b5274bec2c7f66dd
15:58 payload joined #parrot
15:59 * whiteknight thinks he might finally be able to send in his updated PaFo CLA
15:59 whiteknight s/be able to/be unlazy enough to/
15:59 whiteknight plus, I think I finally understand how the fax machine here works
16:02 darbelo Fax machines work on balck magic. You have to offer raw chicken entrails to bribe the gods or thwy won't let your message pass-
16:02 bubaflub the value of a fax machine is directly proportional to the number of people who own fax machines
16:02 fperrad ping allison
16:02 purl I can't find allison in the DNS.
16:02 allison fperrad: hi
16:03 fperrad allison, distutils.pir could replace dynops.pl & dynpmc.pl
16:04 allison fperrad: Sounds good. I haven't looked at it, what does it do?
16:06 fperrad allison, distutils.pir has the same interface as Python Distutils
16:06 fperrad and has rules to build pge, tge, nqp, nqp-rx, dynops, dynpmc, pbc, pbc_to_exe
16:08 nopaste "fperrad" at 78.113.94.6 pasted "setup.pir for Pynie (allison)" (105 lines) at http://nopaste.snit.ch/18637
16:08 Austin Whiteknight: Updated CLA?
16:08 whiteknight Austin: I sent in a Perl Foundation CLA a long time ago, but I need to send in a Parrot CLA now
16:08 whiteknight and I haven't done it
16:08 Austin Ah.
16:09 whiteknight but, I have it all filled out and I'm within swinging distance of a fax machine, so I think I might be able to pull it off
16:10 allison fperrad: I like it! The one thing we know for sure that people have (or will have to install) when they're installing a language or module for Parrot is Parrot.
16:11 fperrad allison, yes, distutils.pir remove many dependencies
16:12 moritz (without having looked at the code) can it still compile different subsystems in parallel?
16:12 allison fperrad: do you have an example of a generated file for dynops and dynpmcs?
16:12 moritz for example by being called concurrently?
16:12 whiteknight fperrad: where is distutils.pir located? parrot repo?
16:13 fperrad in parrot repo, runtime/parrot/library/
16:14 fperrad allison, http://github.com/fperrad/wml​script/blob/master/setup.pir
16:16 Andy_ joined #parrot
16:19 joeri joined #parrot
16:31 dalek parrot: r42422 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
16:31 dalek parrot: [distutils] setup() loops on all targets
16:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42422/
16:34 cotto_work joined #parrot
16:36 cotto_work good morning
16:37 dukeleto cotto_work: hola
16:38 dukeleto good to hear that we are having a testing hackathon soon
16:38 dukeleto i should write a more detailed howto/post about translating tests
16:38 cotto_work good idea
16:38 purl cotto_work: Good Idea: Stopping to smell the roses. Bad Idea: Stopping to feel the roses.
16:41 whiteknight good morning cotto_work, dukeleto
16:41 whiteknight yes, I'm excited about testing hackathon
16:44 cotto_work I just realized that the hackathon is a great excuse to get cracking on writing test code for the profiler.
16:44 cotto_work w00t
16:49 whiteknight has anybody heard from bernhard recently?
16:49 whiteknight He's supposed to do 1.8.0 but I don't think I've seen him around
16:49 moritz he committed a few changelog updates recently
16:49 cotto_work He's been around.
16:49 whiteknight of course, I probably haven't been looking too hard
16:49 cotto_work he's aka barney
16:49 moritz seen barney
16:49 purl barney was last seen on #parrot 7 days, 21 hours, 1 minutes and 3 seconds ago, saying: allison: looks good, tnx  [Nov  3 19:48:18 2009]
16:50 whiteknight bernhard?
16:50 purl bernhard is mailto:Bernhard.Schmalhofer@gmx.de
16:50 whiteknight barney?
16:50 purl barney is a big, purple piece of shit, or gettin' jiggy wid it or see 'grimace'. or purple dupa or o/` I love you / You love me / We're a happy family / with a great big hug /and a kiss from me to you / Won't you say you love me TOO! /`o
16:51 whiteknight ...that's not very flattering
16:51 allison different barney
16:51 whiteknight robble, robble
16:52 allison I believe #perl had a hate-hate relationship with the child's tv character
16:52 cotto_work perfectly understandable
16:52 whiteknight of course, that's a perfectly reasonable way to spend your time
16:52 allison highly logical
16:53 whiteknight hamburglar?
16:53 purl somebody said hamburglar was on the way out too. convicts are complaining
16:54 whiteknight grimace?
16:54 purl hmmm... grimace is a foot-long purple dildo belonging to WareCow, or a 6-foot-long talking purple dildo at McDonald's. or http://www.goats.com/archive/980204.html
16:54 whiteknight ...that's even less appropriate
16:55 cotto_work With the first two entries, I'm definitely not following that link.
16:56 darbelo goat dildos?
16:57 whiteknight I didn't think "barney" was a name of one of the mcdonaldland characters
16:57 darbelo Actually goats.com is a webcomic, and features no dildos, to my knowledge.
16:59 whiteknight oh, right. barney the dinosaur
16:59 * whiteknight needs to get his children's characters straight, since he's going to have a child soon
16:59 whiteknight and if there's one thing kids hate, it's getting their favorite characters mixed up
16:59 cotto_work http://code.google.com/p/go/source/detail?​r=4a3f6bbb5f0c6021279ccb3c23558b3c480d995f
16:59 whiteknight ...or mixing up star trek and star wars :)
17:00 cotto_work longest overdue commit ever
17:01 whiteknight I propose that we delete the current repository and rewrite Parrot from the ground up in Go
17:02 cotto_work +1
17:02 purl 1
17:02 whiteknight proof that the language is suitable, or that it will provide any actual benefits is not necessary
17:02 cotto_work Go is obviously the future.  We should abandon this C junk.
17:02 whiteknight I take it as self-evident that the quality of Go code we produce will be just as good or better than the C code we produce
17:03 Austin Go is a doomed language. Forget it.
17:03 Austin They broke the rule, they suffer the consequences.
17:03 whiteknight so is C. In another 200-300 rules, it will slowly be phased out
17:04 whiteknight and then what? That's right, Go
17:04 whiteknight "200-300 years"
17:04 cotto_work nice typo
17:05 mokurai joined #parrot
17:05 Austin Whiteknight has a rules fetish.
17:06 Austin Despite all this dynamic language stuff, he's with me in thinking we'd all be better off doing this in C++.
17:06 dalek rakudo: 50e495b | (Kyle Hasselbacher)++ | t/spectest.data:
17:06 dalek rakudo: [spectest.data] add a couple runnable files
17:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​0e495b8dd96c1df579ff64a4d549ffb9cb62952
17:07 cotto_work It'd be interesting if Parrot got to the point where there were multiple implementations.
17:07 Austin Isn't that what branches are for?
17:07 Austin Maybe we could get the transmeta guys to do parrot in silicon for us...
17:09 redbrain joined #parrot
17:11 Austin What's the right name for the progression indicated by labels like ":anon", ":init", ":load", and ":main"?
17:12 Austin Are those phases, stages, lifecycle-states, events, ...?
17:12 barney whiteknight: I'm here, been on the phone
17:13 * barney prefers to be Barney from the Flintstones
17:13 brubble Sorry, taken.
17:13 brubble ;)
17:14 darbelo ;)
17:15 whiteknight barney: okay, I'm just making sure everything is ready for the release
17:16 barney I'll send out a call for updates (NEWS,PLATFORMS) tonight
17:17 whiteknight awesme
17:18 redbrain is it hard getting the releases out?
17:18 cotto_work not at all
17:18 cotto_work it just involves a lot of waiting while tests run
17:18 Austin It's only hard getting the release out if you make the mistake of believing the people who tell you it's easy to get the release out.
17:18 cotto_work and gathering information
17:19 redbrain lol
17:19 cotto_work and submitting to various news site
17:19 Austin Look at the logs for the 1.7 release.
17:20 whiteknight anomaly
17:20 Austin After 1.4, 1.5, and 1.6 going out, with everyone saying "Wow, the documentation makes this really simple. This was much easier than I thought it would be!" the cool-aid finally got drunk.
17:20 Austin Then it was "Yeah, this *is* easy. I'm just following along the documenta ... holy crap!"
17:21 redbrain yeah i have got like no documentation at all for my programming language :P though i havent made a release yet lol
17:21 redbrain well i do have a bit of a readme to compile it etc
17:21 Austin Welcome to the team.
17:22 redbrain i havent had any time to integrate any of it with parrot or anything keeping it as my own interpreter from scratch untill 2 interations of the language
17:22 whiteknight the release was easy. It always is. The problem was woefully inadequate testing on Windows
17:22 whiteknight we've already done more of that this month
17:22 mikehh joined #parrot
17:23 whiteknight redbrain: is it hosted publicly
17:23 whiteknight ?
17:23 redbrain yeah i guess lol
17:23 whiteknight link?
17:23 purl or "Link is ... like ... this pointy eared goblin that walks around in midi-music land with a letter opener attacking circles and things and wooing princesses but not bannon, you know?" or preaction is Error.
17:23 redbrain its on crules.org but i had some server problems recently so i lost my wiki content and my redmine project tracking content
17:23 redbrain at least thats all i lost
17:23 redbrain lol
17:23 redbrain i had backups of everything else
17:23 whiteknight #perl is raping my childhood
17:24 redbrain i was more worried about the 4/5 people i host on my servers but it was ok
17:24 diakopter whiteknight: ouch.
17:27 Austin whiteknight ?
17:27 purl it has been said that whiteknight is mailto:wknight8111@gmail.com or the grand master funk or http://wknight8111.blogspot.com/
17:28 whiteknight Austin?
17:28 purl Austin is, like, nice. or a city in Texas
17:28 whiteknight you *are* like a city in Texas
17:28 Austin Raping your childhood?
17:28 whiteknight yeah, calling grimace a dildo, or saying like is a pointy eared goblin
17:28 Austin Bigger than I should be, and full of criminals?
17:28 whiteknight no, that's just the Cowboys
17:29 redbrain are most of you guys in america then? :) I am in ireland lol
17:29 Austin Redbrain: It depends on when you're here.
17:29 PerlJam redbrain: far too many of us are in Texas, let alone America  :)
17:30 redbrain lol awesome one of my friends lived in texas for like 3/4 years
17:30 redbrain he liked it
17:30 Austin I'm in the US, and I'm on at all hours. But Bacek is in British Texas, and a couple of regulars are in the EC.
17:31 moritz EC?
17:31 purl EC is probably Elvis Costello or the short form of EvanCarroll, who is not worth the bytes necessary to transfer the characters in his full name. or Extended Core
17:31 Austin They'll be here at localtime-appropriate points.
17:31 redbrain what time is it with you guys then its 17:31 here :)
17:31 purl redbrain: It's just about half past five in the afternoon where I am.
17:31 Austin European Commonwealth
17:31 cotto_work I've never heard Australia referred to as British Texas.
17:31 whiteknight it's lunch time here
17:32 Austin Well, technically Texas is the American Australia. But I had to work with the antecedents I was given.
17:32 whiteknight cotto_work: that's probably because you like all the australians you've met :)
17:32 PerlJam redbrain: it's 17:31 here too ... but my clock is set to UTC  ;)
17:32 Austin clock?
17:32 purl Austin: LAX: Wed 9:32am PST / CHI: Wed 11:32am CST / NYC: Wed 12:32pm EST / LON: Wed 5:32pm GMT / BER: Wed 6:32pm CET / IND: Wed 11:02pm IST / TOK: Thu 2:32am JST / SYD: Thu 4:32am EST /
17:32 redbrain hehe :)
17:32 PerlJam Austin: are you saying Texas was colonized by a bunch of criminals?
17:32 Austin PerlJam: yes.
17:32 whiteknight s/colonized/still inhabited by/
17:33 PerlJam Austin: including your namesake?  :)
17:33 * whiteknight jokes
17:34 PerlJam whiteknight: no, you're right.  But most of them seem to live in Houston for some reason, so at least they're semi-isolated
17:34 redbrain rofl sure ireland is inhabited by alcoholics :P
17:34 Austin PerlJam: Technically, my namesake is Ulysses S. Grant. But if you mean Sam Austin, then (as they say in Texas), "Hell yes!"
17:34 whiteknight redbrain: but that's not a "problem", it's a "tradition"
17:34 PerlJam "Sam Austin"?
17:34 redbrain thats true :)
17:34 PerlJam Stephen F. Austin
17:34 PerlJam Sam Houston
17:34 Austin Ah.
17:34 Austin You have me there.
17:35 redbrain is it your full time job to work on parrot then? :)
17:36 whiteknight I wish that were my job
17:36 PerlJam That would be something.
17:36 redbrain rofl
17:36 whiteknight I would quit all my other jobs in a heartbeat
17:36 redbrain yeah same
17:36 Austin Whiteknight: Can't you get one of those grant things?
17:36 whiteknight well, s/in a heartbeat/with two weeks notice/
17:36 whiteknight Austin: grant from where?
17:36 PerlJam whiteknight: start a company that provides software solutions based on parrot.
17:36 whiteknight they don't just grow on trees
17:37 PerlJam whiteknight: market to google, mozilla, microsoft, etc. (people with money)
17:37 Austin Isn't one of the foundations handing out grants for parrot development?
17:37 redbrain i worked for sap research for a year and a half there but back finishing my mathematics and comp science degree now part time over 2 years but i do lots of bits and pieces in between
17:37 whiteknight sap? I LOVE to hate sap
17:37 whiteknight :)
17:37 redbrain haha yeah i hated that job haha
17:38 redbrain sap are crooks tbh esp research
17:38 redbrain never want to work in research ever!
17:38 redbrain lol
17:38 cotto_work TPF does grants, but it's mostly for Perl 6 work atm.
17:39 whiteknight right, but not the "I can quit my job now" grants
17:39 cotto_work nope
17:39 whiteknight meh, it's a pipedream
17:40 cotto_work back to rl
17:40 moritz TPF has rather little money for grants. There's an additional funding which is tied to Perl 6 develepment though (funded by Ian Hague)
17:41 Austin That's what I was thinking of.
17:41 Austin The Hague grants. For some reason, I knew it was a city name, but couldn't recall which one.
17:42 Austin Well, city reference, anyway.
17:45 Austin Why the hell is it 69 degrees today?
17:45 whiteknight Austin: do you think that's good or bad?
17:45 Austin I thought fall was over and winter was upon us?
17:45 Austin I think it's terrible.
17:46 whiteknight I don't get bothered by the cold so much
17:46 Austin Nor I.
17:46 PerlJam Fall doesn't end until Dec.
17:46 whiteknight the rain is shitty, but whatevs
17:46 Austin But it was all "hot Brazillian chicks in tight sweaters" for a few weeks. Now they're confused, and wearing baggy sweat-shirts or jackets.
17:46 Austin It's interfering with my scenery.
17:47 bubaflub it's 52 here in the middle of Illinois
17:47 bubaflub it's also boring here in the middle of IL, but that's a different story
17:47 whiteknight I'm more worried about people getting sick. My wife has an immune system like a '63 volkeswagon
17:47 Austin I was going to say something about that being its own reward...
17:48 Austin whiteknight: Meaning it doesn't work?
17:48 whiteknight exactly
17:48 Austin Man, have you been following the news from New Jersey?
17:48 bubaflub hmmm, i've had a number of friends come down with the flu
17:48 whiteknight not to mention that she's 9 months pregnant. A goddamn biological house of cards
17:48 bubaflub yikes.  yeah, keep her quarantined
17:48 whiteknight Austin: what news from durty jersey?
17:48 Austin I live in Burlington County, and the health department has been really aggressive about getting flu shots from the govt.
17:49 Austin We've had these flu clinics a couple of times, and every time they have them, they gets these "stay overnight for Journey concert tickets" lines that go forever.
17:50 Austin The other day, they had 1500 doses, and something like 9000 people showed up. They were parking on the side of the road and walking a mile to get in line, and the clinic was expressly for pregnant women.
17:50 Austin From all over the state.
17:51 Austin Apparently, there's a little public panic going on that nobody knows about or wants to talk about.
17:51 whiteknight I'm not even planning to get the shot
17:51 whiteknight I'm not a big believer in flu shots
17:51 cotto_work plobsing, the nci_ssc test from t/pmc/nci.t fails on the framebuilder branch on x64 with libjit installed and detected
17:52 whiteknight cotto_work: yeah, I pointed out that problem last night
17:52 whiteknight he nopasted a patch somewhere at some point that I have yet to try
17:54 cotto_work http://nopaste.snit.ch/18636 seems to be the one.  I'll give it a shot.
17:54 whiteknight w00t
17:56 cotto_work still broken
17:57 payload joined #parrot
18:00 whiteknight urg
18:09 dalek parrot: r42423 | barney++ | trunk/NEWS:
18:09 dalek parrot: More news for 1.8.0.
18:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42423/
18:14 NotFound allison: ping
18:14 allison NotFound: pong
18:15 NotFound allison: have you seen TT #1262 ?
18:15 * allison looking...
18:17 allison NotFound: short and sweet, nice
18:17 allison NotFound: any test failures?
18:17 purl any test failures are a cause for concern, blah blah blah.  Plus it might illuminate something you're tracking down.
18:18 NotFound allison: the ones for p.invoke(p), as expected.
18:18 allison NotFound: and, how about if the Object is a sub rather than a method?
18:19 allison NotFound: meaning it's a problem if you pass the object as the first argument? or just general failure if you invoke a method?
18:20 NotFound allison: a good question, I was unaware of that posibility.
18:20 NotFound allison: The test failure? Just wrong number of arguments.
18:20 allison NotFound: ah, yeah
18:21 allison NotFound: IIRC, there's an older ticket with some more thoughts on the subject, will look
18:21 NotFound We can add a naive fix: if the first argument is self, do nothing.
18:22 allison NotFound: yes. mainly at the moment, just get it working, and we'll make some fixes to the PIR 'self' syntax later
18:23 allison NotFound: (like, later we'll have to deal with updating the signature stored in CallSig to match the args it's holding)
18:24 NotFound allison: chromatic mentioned that yesterday, yes.
18:25 NotFound allison: so can I commit if the simple fix for the test cases works?
18:26 allison NotFound: yes, it can't break any existing code because the code would have already been broken
18:26 allison NotFound: bonus points if you can handle the Sub case too
18:26 allison NotFound: (oh, but please double-check that the Sub case isn't working currently, just in case I'm remembering wrong)
18:27 NotFound allison: hard to tell, I never tried to set a Sub as vtable override.
18:28 whiteknight NotFound++
18:29 whiteknight I knew that fix would be an easy one with the new PCC system. I just didn't realize how easy
18:29 allison NotFound: I'm thinking of the more general case of invoking a PIR object, hang on, will nopaste...
18:29 NotFound Yeah, the pcc refactor has been great :)
18:30 whiteknight that reminds me, I'm supposed to be reading up how "self" is done now in IMCC
18:30 whiteknight allison mentioned it was an ugly hack
18:30 davidfetter joined #parrot
18:32 whiteknight actually, the code in compilers/imcc/pcc.c:unshift_self() doesn't look so horrible
18:32 whiteknight I seem to remember it used to be worse
18:33 whiteknight I can see some immediate ways we could improve performance here, however
18:33 nopaste "allison" at 77.98.130.30 pasted "Invoking a Sub object, for NotFound" (11 lines) at http://nopaste.snit.ch/18639
18:33 allison NotFound: and, it doesn't work now, so you're safe if it still doesn't work after, but would be nice to fix
18:34 whiteknight when I do foo.'method'(), it calls invoke on foo?
18:34 allison whiteknight: no
18:34 allison when you call foo.bar() it calls invoke on bar
18:34 whiteknight okay, I was lead to believe that was the case
18:34 allison (if bar is a PMC)
18:35 whiteknight okay, so foo.invoke is only called when I do foo()?
18:35 allison aye
18:35 allison or thingy.foo()
18:36 whiteknight oh, okay. So how would I create my own Sub type and insert it as a method like that on an object?
18:36 whiteknight and, in that second case, would foo.invoke "self" refer to thingy or foo?
18:36 allison whiteknight: see my nopaste above, but add a call to add_method on some object
18:36 whiteknight ok
18:37 allison whiteknight: that has always been the great debate (what should 'self' be when invoking on an Object sub)
18:37 allison whiteknight: arguably, self shouldn't even exist for foo()
18:38 whiteknight okay, I remember having that debate, just making sure my memories are accurate
18:38 allison whiteknight: (since it's a sub, and 'self' only exists on methods)
18:38 whiteknight methods and vtables
18:38 allison aye
18:39 whiteknight I would maybe advocate a "current sub" keyword that would exist also in PIR code
18:39 allison whiteknight: IIRC someone raised the question of how to access the sub object when you need it
18:39 whiteknight so in foo(), self == currsub == foo
18:39 whiteknight whereas in bar.foo(), self == bar, currsub == foo
18:39 allison whiteknight: I'd move away from keywords entirely and go for opcodes for both self and current_sub
18:39 NotFound allison: I don't see a Sub object in that nopaste :?
18:39 whiteknight I'm in favor of that very much
18:39 allison or, param types
18:40 allison NotFound: it's MySub, an object acting as a sub
18:40 whiteknight param types would be nice and relatively easy to implement
18:40 allison whiteknight: .param pmc self :object
18:40 NotFound allison: ah, I thinked you talked about a subclass of Sub, or something like that.
18:40 whiteknight though I worry if we proliferate too many .param flags, we'll slow some things down
18:40 allison er, :self
18:40 whiteknight and .param pmc this :sub
18:41 allison whiteknight: yup, sounds good
18:41 allison or :current_sub
18:41 whiteknight sounds like ammunition for an RFC. I'll hit the list and see how many complaints the HLL devs can come up with :)
18:41 allison whiteknight: it certainly complicates the param checking code, but it is just an integer check
18:41 allison whiteknight: thanks
18:42 allison NotFound: it could be a subclass of Sub
18:42 whiteknight the "special" kinds of flags that will be used infrequently, I think we can mask them off and reduce the number of checks for them
18:43 whiteknight so it shouldn't be a huge complexity increase
18:43 allison NotFound: but mainly I meant that Object's 'invoke' vtable should handle cases where there is no invocant
18:44 NotFound allison: that's what the patch makes.
18:45 * allison <slaps head> figuring it out about 2 seconds before
18:46 allison NotFound: okay, so that treads deeper into the debate whiteknight and I just reviewed...
18:46 allison NotFound: at first glance I though you were handling the case of adding thingy to the argument list for thingy.foo()
18:46 allison NotFound: (that is, adding the invocant)
18:47 whiteknight allison: in a related question, for all other VTABLEs, "self" should refer to the object who's vtable it is? But in invoke, "self" is only that object if it's not the invocant?
18:48 allison whiteknight: that's the problem, how do you access the invocant if the sub object takes over self
18:48 whiteknight allison: adding the :current_sub param type
18:48 allison whiteknight: self should always refer to the invocant
18:49 whiteknight okay
18:49 NotFound allison: The case for overriding invoke in a method, I don't even looked at it. First I must know some possible use case.
18:49 NotFound Well, in a thing acting as a method, maybe better said.
18:49 allison NotFound: will make a new nopaste...
18:50 NotFound But in that case... who is 'self' ?
18:54 nopaste "allison" at 77.98.130.30 pasted "Invoking a Method object, for NotFound" (18 lines) at http://nopaste.snit.ch/18640
18:54 allison NotFound: this one apparently does currently work
18:54 allison NotFound: so need to not break it
18:54 NotFound allison: so maybe we must add a test before applying the patch.
18:54 allison NotFound: self should always be the invocant (as in the actual invocant argument to a method call)
18:56 allison NotFound: it is confusing in the vtable case
18:56 NotFound In that usage: how can MyMethod.invoke access the MyObject instance?
18:57 Austin In that case, what is the method?
18:58 Austin That is, if my_obj becomes self, what does $p1 become?
18:58 allison NotFound: trying a few more code examples before I make a call...
19:01 whiteknight email sent. Let the warnocking begin
19:02 whiteknight bernhard++
19:03 NotFound With a simple check for self in call_sig[0], all test pass.
19:05 whiteknight Since the invocant is already stored in the CallSignature, I don't see any reason why we would need to pass it as the first argument the way IMCC does it currently
19:07 whiteknight we can still manually insert a ".param pmc self :invocant" to the list on the callee side, but we don't need to pass self as an arg
19:07 nopaste "allison" at 77.98.130.30 pasted "currently, a :vtable sub has access to the 'self' argument of a method call, as well as other arguments of the call, for NotFound" (29 lines) at http://nopaste.snit.ch/18641
19:07 allison NotFound: this example works now too
19:08 allison Austin: not sure I understand the question
19:08 allison Austin: oh, I see, yes, the MyObject instance isn't available in side the body of the 'invoke' sub at all
19:08 Austin Allison: In your nopaste, you have 7 my_obj.$P1()  as an example call.
19:09 Austin I think that's a mistake.
19:09 allison Austin: yes, the $P1 is only executed, it's not available inside (at the moment)
19:09 Austin Okay.
19:09 allison Austin: I agree it should be accessible, but it shouldn't override 'self' (or we limit ourselves from creating PIR methods)
19:10 allison PIR method object classes, I should say
19:10 whiteknight I like the :current_sub .param flag
19:10 whiteknight I think that's the most straightforward
19:11 whiteknight and :invocant too
19:11 allison whiteknight: me too
19:11 NotFound allison: your first example works if I also add a check for current_object being null.
19:11 whiteknight because then we can name it whatever the hell we want
19:11 whiteknight .param pmc self :current_sub
19:11 allison whiteknight: can we add :invocant now, without interfering with the old self?
19:12 whiteknight allison: yes.
19:12 whiteknight but more importantly, I think we can reimplement the "self" keyword in terms of :invocant for a modest savings
19:12 allison NotFound: as in, 'self' is the current sub for a sub call, but the invocant for a method call?
19:12 allison NotFound: the tricky bit would be how to access the current sub from a method call
19:13 pmichaud normally the "current sub" is available through the interpreter object, fwiw
19:13 pmichaud $P0 = getinterp;   cursub = $P0['sub']
19:13 pmichaud (unless you're describing something different)
19:13 whiteknight pmichaud: so is the current callsig. :current_sub would just be shorthand
19:13 NotFound Take it easy, guys, we are starting to make work the more common case, don't expect that any conceivabe usage works today ;)
19:14 payload joined #parrot
19:14 allison pmichaud: aye
19:14 pmichaud I'm not sure that level of shorthand is needed.
19:14 allison NotFound: I'm mainly concerned about the confusion
19:14 whiteknight a named lookup isn't going to be nearly as fast as a .param with a flag
19:14 pmichaud whiteknight: sure, but how often do we need to look up the current sub?
19:15 whiteknight everytime we call VTABLE_invoke, potentially
19:15 whiteknight again, I think it's analogous to :cal_sig
19:15 whiteknight :call_sig*
19:15 pmichaud I'm a bit confused by "everytime we call VTABLE_invoke"
19:15 pmichaud maybe I just understand the use case.
19:15 pmichaud *don't understand
19:16 allison pmichaud: it's a good point, and I'm trying to remember the initial request that prompted it
19:16 whiteknight we're talking about overriding VTABLE_invoke from PIR
19:16 pmichaud whiteknight: yes, I got that part.
19:16 whiteknight and we're looking to differentiate betwen calls "$P1()" from "foo.$P1()"
19:16 allison pmichaud: looking through old tickets. It has to do with "make VTABLE_invoke work"
19:17 pmichaud ah, and the second case the problem is that there are two 'selfs'
19:17 pmichaud there's the invocant foo, and there's the thing being invoked $P1
19:17 whiteknight pmichaud: exactly. We need to get references to both objects
19:17 whiteknight plus I think having :current_sub around would make the functional guys happy: easy anonymous self-recursion
19:17 NotFound allison: the second nopaste also works
19:18 allison NotFound: with your fix? that's good
19:18 dukeleto 'ello
19:18 pmichaud I think the name "current_sub" is entirely misleading
19:19 pmichaud for one, $P1 is not really a sub
19:19 allison quick public poll: is it confusing if 'self' refers to something different in an Object 'invoke' override than it usually does?
19:19 pmichaud allison: I don't have a quick answer, alas
19:19 pmichaud from the vtable perspective, 'self' should refer to the thing being invoked
19:20 pmichaud from the caller perspective, 'self' should refer to the invocant
19:20 nopaste "NotFound" at 213.96.228.50 pasted "Updated patch for Object.invoke" (18 lines) at http://nopaste.snit.ch/18642
19:20 whiteknight funny: http://code.google.com/p/go/issues/detail?id=9
19:20 allison NotFound: I suggest committing it, mentioning it in the 'experimental' section of DEPRECATED.pod, so we're not tied to keeping it
19:21 NotFound allison: I think the question is: what do you think it usually does? ;)
19:21 allison NotFound: and post to the list about it
19:21 pmichaud speaking strictly from a p6 perspective (which I recognize may not be appropriate for parrot), I would think of 'self' inside of VTABLE_invoke as being the invoked object, with the first argument as the invocant, if anyway
19:21 allison NotFound: it usually holds the method invocant, the 'object'
19:21 barney whiteknight: same thing happened to Kea
19:21 allison NotFound: but we're talking about a case that has no invocant
19:21 pmichaud i.e., P6 tends to think of   obj.$P0(arg)   as being the same as $P0(obj, arg)
19:22 NotFound allison: Can some other write the deprecated entry? My english is very poor for clearly explain it.
19:22 allison NotFound: go ahead and write it, someone can edit it later
19:22 pmichaud to put it another way, my naive approach for writing an invokable method object would be
19:22 NotFound Ok
19:23 pmichaud .sub :vtable('invoke')
19:23 pmichaud .param pmc invocant   # this is the object on which the method is being invoked
19:23 pmichaud .param pmc arg1
19:23 pmichaud ...
19:23 pmichaud .end
19:23 Austin whiteknight: Somebody already suggested goatse. :(
19:23 pmichaud thus in   obj.$P1(arg1)    we would see $P1 as 'self', obj as 'invocant', and arg1 as 'arg1'
19:24 Austin pmichaud++
19:24 pmichaud i.e., vtable-ness overrides method-ness
19:24 Austin Objectness.
19:24 allison pmichaud: and in fact, that may be what we're moving to, but with the invocant param marked with :invocant
19:24 pmichaud I'd be okay with that too.
19:25 pmichaud (of course rakudo won't be using this, but it's good to know what would be there if we needed it :-)
19:25 whiteknight the "self" keyword is too magical right now
19:25 allison self has always been a bit of a weird hack
19:25 pmichaud I think self works out quite naturally, fwiw
19:25 particle what about .invocant self
19:25 whiteknight it works, but not in all corner cases
19:25 particle rather than .param pmc foo
19:25 pmichaud well, the tricky part with  obj.$P1(arg)  is that there are in fact *two* operations being performed
19:26 particle is it worth a new macro to distinguish invocant from other params?
19:26 pmichaud particle: I think a flag is sufficient
19:26 whiteknight particle: I don't think so
19:26 whiteknight flag is more consistent
19:26 pmichaud anyway, my vote on the quick poll is that inside of vtable_invoke, 'self' refers to the invoked object, always.
19:26 particle .sub :vtable('invocant')
19:26 NotFound allison: What section in DEPRECATED.por ? PMCS ?
19:26 particle .param string invocant
19:26 pmichaud if I want the actual sub, I can use getinterp
19:26 particle oops!
19:26 whiteknight pmichaud so "foo.bar()", self is foo?
19:27 pmichaud whiteknight: no, self is bar
19:27 purl okay, pmichaud.
19:27 pmichaud (assuming that bar has a PIR vtable_invoke)
19:27 whiteknight pmichaud: I think that's exactly the opposite of what you just said
19:27 pmichaud in foo.bar(),  foo is definitely _not_ the invoked object
19:27 whiteknight "'self' refers to the invoked object, always"
19:27 pmichaud the thing being invoked is bar
19:28 pmichaud it's being invoked on foo, but bar is the actual thing doing the executing.
19:28 particle we'll need an error if the sub is marked :vtable('invoke') and the first param is sot a pmc
19:28 whiteknight I think that's pretty far backwards
19:28 particle *not a pmc
19:28 whiteknight an object of a method pmc class would have exactly opposite meanings for "self" from what a normal PIR method would have
19:29 pmichaud only in vtable invoke
19:29 allison pmichaud, but if I invoke a method that was defined with .sub bar :method, self is foo in foo.bar()
19:29 pmichaud keep in mind that method pmcs can have their own methods as well
19:29 pmichaud allison: I understand the distinction yes.  I think the distinction has to be made in vtable invoke versus methodcall semantics
19:29 whiteknight but so can the invocant have other methods
19:30 whiteknight "self" should always be the invocant. Changing it in different contexts is wrong
19:30 pmichaud whiteknight: right, and if the invocant has other methods, then those are treated as methodcalls
19:30 pmichaud whiteknight: in    $P0(xyz)   --- what is the invocant?
19:30 whiteknight none
19:30 allison whiteknight: I think this just shows that 'self' is wrong
19:30 pmichaud what is the thing that is handling vtable_invoke ?
19:30 allison pmichaud: there is no invocant in $P0(xyz)
19:30 whiteknight allison: if "self" exists at all (and maybe it shouldn't) it should be consistent
19:30 pmichaud let me put it this way, then
19:31 pmichaud in all of the other vtable methods, "SELF" refers to the thing that controls the vtable
19:31 pmichaud if I have   $I0 = $P0
19:31 pmichaud then it's $P0's   "get_integer" vtable that controls
19:31 whiteknight right, and $P0 is self
19:31 pmichaud correct
19:31 pmichaud so if I have   $I0 = $P0()
19:31 pmichaud then it's $P0's "invoke" that controls
19:31 allison so the confusion is between SELF in C and self in PIR?
19:32 pmichaud I don't find it confusing.
19:32 pmichaud but that's just me
19:32 pmichaud my point is that  "self" should be the object that is controlling
19:32 whiteknight in PIR VTABLE overrides, self is the same as SELF in C
19:32 pmichaud do we agree that in   $I0 = $P0()   it's $P0's invoke that is in charge?
19:32 whiteknight pmichaud: my solution, in the face of this confusion, is to say "self" should disappear
19:32 NotFound The ticket to be mentioned in DEPRECATED is TT #103 ?
19:32 whiteknight in that case, $P0 is being invoked, but it isnot the invocant
19:33 pmichaud whiteknight: fair enough, I have no problem with that
19:33 pmichaud the same is true for   $I0 = obj.$P0()   then
19:33 allison okay, an "invocant" is always the object on which a method is invoked
19:33 pmichaud it's $P0's "invoke" that is in charge.  "obj" has absolutely nothing to do with it.
19:33 whiteknight so the question is this: is "self" the invocant, always, or is "self" some magical wonderful thing which means different things at different times and will unpleasantly suprise programmers?
19:33 allison I've always read self == invocant, rather than self == SELF
19:33 whiteknight if it's the former, fine: we have some fixing to do. If the later, kill it
19:34 pmichaud I've already read self == first argument to a method
19:34 pmichaud *always
19:34 whiteknight pmichaud: that's a perl-ism.
19:34 pmichaud (because that's the Perl way of thinking of it, yes)
19:34 whiteknight hardly suitable for the default behavior of a language-agnostic VM
19:34 pmichaud I disagree.
19:34 pmichaud (more)
19:35 pmichaud it just depends on whether you believe methods are first-class objects or not
19:35 pmichaud and I think that Parrot _has_ to treat methods as first class
19:35 pmichaud and since methods are first class, they have their own notion of 'self' that may be different from whatever invocant they're operating on
19:35 allison pmichaud: agreed, this is just a question of what syntax we use to do it
19:35 whiteknight how does first-classness have any impact on whether the invocant is passed as a normal argument or not?
19:36 pmichaud therefore, in the case of something like
19:36 pmichaud $I0 = obj.$P0(arg)
19:36 pmichaud where there's no find_method taking place on obj
19:36 pmichaud (which is the other major difference here)
19:36 whiteknight obj is the invocant, $P0 is the invoked sub
19:36 pmichaud obj isn't the invocant, though.  It has absolutely nothing to do with the method invocation
19:37 pmichaud as opposed to    obj.'foo'(arg),  where obj determines which method is to be invoked
19:37 allison pmichaud: we could define invocant that way, but we're safer sticking with Damian's definition
19:37 pmichaud okay, I'm not familiar with Damian's definition
19:38 allison from a Perl 5 perspective it would be "the first argument"
19:38 allison but more technically "the object in a method call"
19:38 pmichaud I'm fine with defining invocant that way
19:38 allison (without any consideration for what the method is or how invocation happens)
19:39 pmichaud in the case of   obj.$P0(arg1)   I'll argue that no method call takes place
19:39 allison we can come up with a different name for the PMC SELF that controls the current behavior
19:39 pmichaud even though it looks like one
19:39 whiteknight In most languages, trying to call foo.bar() as bar(foo) would be a big error
19:39 allison whiteknight: that may be a bit of a rabbit trail
19:39 pmichaud whiteknight: I'm not arguing for Perl semantics just to have Perl semantics
19:39 allison I have a more practical problem, if a .sub is defined as :vtable :method, what should 'self' be inside it?
19:40 pmichaud traditionally, subs defined as :vtable have had 'self' as the vtable's invocant
19:40 whiteknight pmichaud: I'm arguing against perl semantics just to not have to deal with perl semantics
19:40 allison (that is, if we hypothetically decide that 'self' should be SELF)
19:40 whiteknight I think Parrot should not impose semantics on the HLLs
19:40 bacek joined #parrot
19:40 whiteknight allison: I think we need to get rid of the PIR "self" entirely
19:40 allison pmichaud: do you mean Damian's invocant, or PMC SELF?
19:41 allison whiteknight: yes, I'm walking through Socratically here
19:41 pmichaud I mean PMC SELF, which also implies to me exactly Damian's invocant
19:41 pmichaud i.e., I don't see a conflict there.
19:41 allison more detailed
19:41 allison ...
19:41 allison .sub foo :vtable :method...
19:42 allison called $P0.foo() #assume foo is a variable holding a PMC object
19:42 pmichaud (it would have to be)
19:42 allison inside the body of 'foo' what is self?
19:43 pmichaud I would see 'self' as being foo (more)
19:43 pmichaud my reasoning is that $P0 has no impact whatsoever on the method being called
19:43 pmichaud except as an argument
19:43 allison this isn't a vtable override, this is an ordinary method
19:43 pmichaud oh, you meant   $P0.'foo' then
19:44 allison nope, any method can be called as either a name or an object
19:44 pmichaud no.
19:44 allison there's no way for Parrot to know how the method object was defined when it's invoked
19:44 pmichaud right
19:44 pmichaud so, detailing further...
19:44 dalek parrot: r42424 | NotFound++ | trunk (2 files):
19:44 dalek parrot: [pcc] experimental object vtable invoke, TT #103, TT #1262
19:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42424/
19:45 pmichaud .sub 'foo' :vtable :method  :subid('xyz')
19:45 pmichaud ...
19:45 pmichaud .end
19:45 allison so, you can always pull a method object out of the class object and call it directly
19:45 pmichaud .const 'Sub' foo = 'xyz'
19:45 pmichaud like that?
19:45 allison and, it acts just like a normal method call
19:45 allison yup
19:45 pmichaud and then
19:45 pmichaud $P0.foo(1)
19:45 pmichaud like so?
19:45 allison aye
19:45 pmichaud in that case, I would see   self as $P0   (more)
19:45 allison which should have exactly the same behavior as $P0.'foo'(1)
19:46 pmichaud because foo is not an object that has a custom VTABLE_invoke
19:46 pmichaud foo is a Sub
19:46 whiteknight that's a very arbitrary decision to make
19:47 whiteknight .sub foo :method could be any type, once we have hll overrides working properly in all cases
19:47 pmichaud in that case I would expect that my answer could change (more)
19:48 whiteknight it's the changing that's infuriating! Inconsistency is bad
19:48 bubaflub joined #parrot
19:48 pmichaud one could argue that Parrot's vtable_invoke for Sub simply replaces self with the first parameter
19:48 whiteknight we shouldn't implicitly treat PMCs differently depending on how they are defined. Semantics of "invoke" should be consistent
19:48 dalek TT #1262 closed by NotFound++: Simple patch for the overriding of invoke for objects
19:48 pmichaud and that this is a Sub semantic, which other objects and methods would not be constrained to follow
19:49 whiteknight pmichaud: IMCC currently does that with the first parameter, yes. But I view that as a very bad legacy bug
19:49 pmichaud it's not just IMCC that does it
19:49 pmichaud Sub PMC does it as well
19:49 whiteknight the behavior is completely defined in IMCC
19:49 pmichaud incorrect.
19:49 whiteknight Subs get their arguments from CallSignature now, which doesn't enforce that
19:49 pmichaud okay, then incorrect prior to the pcc refactor.
19:49 whiteknight invocants are a distinct object in the CallSignature
19:50 whiteknight compilers/imcc/pcc.c:unshift_self() is where all the "magic" happens
19:50 allison whiteknight: they're part of the list, but marked with Pi
19:50 pmichaud the point being that the previous behavior allows me to do    obj.$P0(arg)   with any Sub PMC, not only those that are marked as :method
19:50 whiteknight allison: right, it's the Pi that makes them distinct. They arne't just another argument
19:50 pmichaud and therefore the notion that the first argument becomes 'self' is actually handled in the Sub PMC as well.
19:51 pmichaud it's not strictly within IMCC.  At least, I don't see how it could be.
19:51 allison pmichaud: that should continue working, even now
19:51 pmichaud allison: right.
19:51 pmichaud allison: afaik, it does.  (thank you :-)
19:51 whiteknight IMCC generates the code that does that. Without this incorrectly-generated code, it would still work fine
19:51 allison pmichaud: but, should it stop working if $P0 was defined in some other way than as a PIR .sub/.end block?
19:52 whiteknight we wouldn't have the "self" keyword, IMCC appends a .param line to the sub definition when they keyword "self" is present in the sub
19:52 whiteknight in any case, no code inside Sub PMC has anything to do with any of that
19:52 pmichaud meaning if $P0 was some custom PMC with its own vtable invoke?
19:52 allison pmichaud: I would argue that it shouldn't stop working, and should always work no matter how the Sub was created
19:52 allison pmichaud: yes
19:52 pmichaud I'd say that the self semantic depends on the custom PMC then
19:53 whiteknight A sub should be able to determine when it has or has not been called as a method
19:53 pmichaud and that vtable_invoke would be explicitly recognizing a potentially different meaning of 'self'
19:53 allison pmichaud: probably should, but custom PMCs can't control PIR syntax parsing
19:53 whiteknight and making that determination means having an invocant be null or not-null
19:53 whiteknight which means not just filling in the invocant with whatever first argument was passed
19:54 whiteknight mymethod(1), where 1 is not the invocant
19:54 allison it sounds like the best solution long-term is to split "invocant" (as object in a method call) from however we access the SELF object inside a vtable invoke override
19:54 whiteknight mymethod has been incorrectly called as a standalone sub
19:54 pmichaud whiteknight:  if we follow the Damian definition, 1 is an invocant.
19:54 whiteknight then I don't follow that definition
19:54 pmichaud I also think that saying that "been incorrectly called as a standalone sub"  is Parrot imposing a semantic as well.
19:54 allison pmichaud: no, obj would be the first parameter
19:55 allison (because Perl 5 makes no distinction between foo(obj, 1) and foo->obj(1)
19:55 whiteknight pichaud: saying that methods should not be entered into the namespace to call is exactly the same as saying we shouldn't be able to call the method without a find_method lookup
19:55 allison obj->foo(1)
19:55 pmichaud whiteknight: it is not.
19:55 pmichaud I can certainly have anonymous subs and methods
19:55 pmichaud and I can certainly invoke methods without having to do a find_method
19:56 pmichaud indeed, how else would one have an anonymous method if you had to go through find_method to do it?
19:56 whiteknight how do you call an anonymous method without it?
19:56 allison pmichaud: if you invoke a method on an object, don't you expect to be able to access that object inside the method body?
19:56 pmichaud allison: yes, sure.
19:57 pmichaud anyway, here would be my suggestion
19:57 pmichaud inside of vtable methods, perhaps we need 'vself'
19:57 pmichaud instead of 'self'
19:57 pmichaud the far more common case is non-vtable methods, and so huffmanization would seem to argue that 'self' should be the invocant there
19:57 allison as in, something more generic than 'current sub'
19:58 whiteknight I'm fine with that. Whatever we call it so long as distinct concepts have distinct names and non-confusing semantics
19:58 pmichaud whatever was being invoked
19:58 pmichaud note that 'current sub' is actually different from vself
19:58 pmichaud with
19:58 allison it is if you look it up through the interpreter
19:58 pmichaud .sub 'foo' :vtable('invoke')
19:58 allison it's the same in the very specific case of .sub invoke :vtable
19:59 pmichaud let me be a bit more specific
19:59 pmichaud .namespace ['MyMethod']
19:59 pmichaud .sub 'foo' :vtable('invoke')
19:59 pmichaud ...
19:59 pmichaud .end
19:59 whiteknight allison: not in all cases of invoke :vtable
19:59 pmichaud $P0 = new ['MyMethod']
19:59 pmichaud obj.$P0()
19:59 pmichaud the thing on which 'invoke' is occuring is $P0
19:59 pmichaud it's an instance of MyMethod
19:59 pmichaud current sub is 'foo'
19:59 whiteknight inside foo, obj is self, $P0 is vself
20:00 TimToady phone
20:00 pmichaud i.e., vself is not the current self
20:00 pmichaud sorry
20:00 pmichaud vself is not the current sub
20:00 pmichaud the current sub is 'foo', it's the invoke vtable function for objects of type MyMethod
20:00 pmichaud thus I would expect vself to be an instance of MyMethod
20:01 pmichaud and then 'self' can continue to be obj, if you like :-)
20:01 NotFound Maybe we need a invoke_method vtable
20:01 whiteknight NotFound: I thought about that several times today
20:02 chromatic joined #parrot
20:03 NotFound For a now I'll just enjoy the long awaited ability of creating real functors :)
20:06 whiteknight Notfound: we can't now?
20:06 dalek xml: 0972202 | fperrad++ | plumage/xml.json:
20:06 dalek xml: update plumage with setup.pir (distutils)
20:06 NotFound whiteknight: Yes we can
20:06 dalek xml: review: http://github.com/fperrad/xml/commit/09​72202e18486e0da5b15bb18ede574ff1f9b03c
20:09 mikehh joined #parrot
20:18 dalek markdown: 8484de1 | fperrad++ | plumage/markdown.json:
20:18 dalek markdown: update plumage with setup.pir (distutils)
20:18 dalek markdown: review: http://github.com/fperrad/markdown/commit​/8484de1d2a73148003566c0b1a1c606d9fa81e9b
20:21 bubaflub fperrad: ping
20:21 fperrad pong
20:22 bubaflub i was rewriting one of your tests, t/dynpmc/gdbmhash.t in PIR and ran into some snags
20:22 bubaflub would you mind taking a look at some code and pointing out where my insanity is?
20:23 allison NotFound, whiteknight: alternate suggestion
20:23 whiteknight shoot
20:24 whiteknight and I hope it's not "flip a coin, if it's heads self is the invocant"
20:24 allison in :vtable, 'self' is the object that the vtable function was defined on
20:24 bluescreen joined #parrot
20:24 allison and .sub invoke :vtable takes a single argument, the call signature object
20:25 allison (instead of trying to take all the arguments from the original sub/method call)
20:25 bubaflub fperrad: it's sittin pretty at http://gist.github.com/232263, any pointers would be appreciated
20:26 whiteknight I do like the idea about using the call signature, but then again I can think of plenty of places where we are just going to want to get our hands on the raw processed arguments
20:26 whiteknight that prevents vtable invoke from getting processed arguments to use
20:26 allison it does, but 'invoke' is the metainvoker
20:27 whiteknight and I still don't like the inconsistency that "self" means different things in different places
20:27 allison so, it makes the call self.'something'(arg :call_sig) work
20:27 whiteknight that's true, but plenty of types are going to treat invoke like the main act, not redirecting
20:27 allison (just pass along the current args)
20:28 fperrad bubaflub, sorry, I can't help with GDBM, I am not the author of this code.
20:28 bubaflub fperrad: my bad.  i must have misread the logs.
20:28 whiteknight allison: I won't disagree with that. It's certainly more sane than the current situation
20:28 fperrad bubaflub, but digest PMC is mine, I see & test your patch
20:29 bubaflub fperrad: cool.  the only snafu there was that converting the template to use PIR fails a coding standard
20:29 bubaflub i think if i take off the "filetype=pir" at the bottom of the template the coding standard will ignore that file
20:30 NotFound allison: I hope that now that we have working a sane invoke for the common case we are not going to break or complicate it.
20:30 fperrad bubaflub, which codingstd test fails
20:30 allison NotFound: should simplify it, actually
20:30 bubaflub fperrad: ahhhh. the reason i thought you were the author was because my parrot only goes back to R40000 and that just so happens to be yours. git blame was saying it was _before_ your commit...
20:31 allison NotFound: that is, we don't need the exceptions for a method call
20:31 NotFound allison: Looks as simple as a sub right now to me.
20:31 allison NotFound: so, self should always be set to SELF in your patch
20:32 bubaflub fperrad: t/codingstd/pir_code_coda.t fails because config/gen/crypto/digest_t.in has a template symbol @TEMP_md_name@
20:32 bubaflub i.e. it fails because i have flagged that files as PIR and the test i think is trying to compile it
20:32 allison NotFound: and we just tell people that the usual interface is to have one param of :call_sig
20:32 whiteknight Allison: so VTABLE_invoke override would always be called with signature Pi-> and just unpack the signature itself?
20:33 bubaflub so i could either flag that file as generated, have the test skip that file, or take off the filetype=pir on the last line
20:33 whiteknight that mirrors pretty closely how it's called from C
20:33 NotFound allison: I talk about the pir code for defiing and for using a functor. The complexity of the C that supports it is a different problem.
20:33 NotFound Now the pir looks to me exactly as I want.
20:33 allison whiteknight: it's only called with a Pi-> signature if it's called as obj.foo()
20:34 whiteknight so otherwise it's just "->"
20:34 whiteknight and how do we determine which is which inside Object.invoke()?
20:34 allison whiteknight: well, it's called with whatever was passed into the call
20:36 whiteknight ah, I get it. Just reuses the same CallSignature
20:36 whiteknight fancy
20:36 whiteknight allison: while on that note, what's the signature for a :call_sig arg? "Pc"?
20:37 fperrad bubaflub, we have different coda, for PIR, Perl & C, you must convert Perl coda to PIR coda
20:37 allison lower-case 's' is already taken? (looking...)
20:37 whiteknight s was slurpy?
20:37 whiteknight (param, but nice to avoid confusion)
20:37 whiteknight no wait, params don't get signatures
20:37 * whiteknight is confusing himself.
20:37 bubaflub fperrad: ok, so that option is out. i totally wasn't thinking about how that code is going to be generated...
20:38 allison whiteknight: yup, slurpy
20:38 whiteknight oh wait, it would be :slurpy on the returns side
20:38 whiteknight "results" side
20:38 whiteknight so there is a Ps signature
20:38 allison whiteknight: yeah, we use the same flags on both sides
20:39 whiteknight right, but you can't have a slurpy arg
20:39 whiteknight at least, I don't seem to think you can
20:39 allison 'c' is taken for constants
20:39 whiteknight in a signature?
20:39 allison yes, but let's avoid the confusion of a different letter meaning something different on each side
20:39 whiteknight I know it's that in an ops signature
20:39 allison parse_signature_string
20:40 whiteknight damnit
20:40 bacek Good morning
20:40 whiteknight "Pr"?
20:40 allison whiteknight: it's all unified now :)
20:40 whiteknight what's all unified now?
20:40 whiteknight too much stuff needs a'unifyin'
20:40 allison the calling conventions, but particularly parsing signature strings
20:40 whiteknight okay, right right right
20:41 allison "Pg"?
20:41 whiteknight I'm fine with that
20:41 allison it's at least close to the beginning of "sig"
20:41 whiteknight so Object.invoke() will use "Pg->Pg"?
20:41 allison even though s and i are taken
20:41 bubaflub particle: ping
20:42 whiteknight so it will take a CallSignature and produce a CallSignature with results (or reuse the first one, in this case)
20:42 allison whiteknight: technically, it'll be P->Pg
20:42 allison or, wait
20:42 allison PiPg->Pg
20:42 allison yes
20:42 whiteknight we're calling it with a CallSignature "Pg" full of args
20:42 whiteknight the signature lready contains the Pi, so we shouldn't need to send that again
20:43 mikehh joined #parrot
20:43 donaldh_ joined #parrot
20:43 allison the Pi is the object the VTABLE function was defined on
20:43 allison (this is what it's virtual signature is)
20:43 whiteknight but Pi is invocant
20:43 dalek parrot: r42425 | fperrad++ | trunk/config/gen (2 files):
20:43 dalek parrot: applied patch from TT#1227 (with improvement)
20:43 dalek parrot: Converts generated tests to PIR (from Perl)
20:43 whiteknight if we want something else for vtable object, I think it should be Pv
20:43 dalek parrot: Courtesy of bubaflub
20:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42425/
20:44 allison Parrot_Sub_invoke(PARROT_INTERP, PMC *pmc, void *next)
20:44 whiteknight Right, but the Sub there isn't the invocant
20:45 allison whiteknight: if it helps clarify your thinking, there are two call signatures here
20:45 whiteknight I was hoping you weren't going to say that
20:45 whiteknight hoping and praying
20:45 allison one is the call signature of "return = obj.foo(arg)"
20:46 allison the other is the call signature of vtable invoke
20:46 whiteknight my understanding was that if we called a sub with :call_sig, thta would be the signature
20:46 allison there's already this separation in Sub
20:46 whiteknight we wouldn't put that signature inside a signature
20:46 allison we're trying to provide a way to do the same things from PIR
20:47 whiteknight the (lousy) :call_sig implementation in trunk now does this. if we do foo(bar :call_sig) we don't create a new sig to stuff bar into
20:47 allison yes, if you call a sub with :call_sig, it becomes the actual call signature
20:47 whiteknight set_args simply sets that as the current signature
20:48 dalek TT #1227 closed by fperrad++: [PATCH] config/gen/crypto/digest_t.in for generated tests in t/dynpmc
20:48 whiteknight ok
20:48 whiteknight and now why does that change in vtable invoke?
20:48 allison yes, for all usual cases, that's how it works
20:48 mikehh joined #parrot
20:48 allison because vtable invoke is a way to allow people to implement invocation plumbing from PIR
20:48 allison so, they need access to all the features
20:49 whiteknight and the "results = obj.meth(args)" signature doesn't give that to them?
20:49 allison it does, but they lose information
20:49 allison we've been trying to dumb vtable invoke down in PIR
20:49 whiteknight ...do they still lose information if they have a :vtable_self .param?
20:50 whiteknight besides the vtable owner, what else are they losing?
20:50 allison no, but we do end up adding a feature that's only needed in one very special case
20:51 allison they lose consistency, mainly
20:51 whiteknight okay, let me see if I have this straight: Inside invoke :vtable, "self" is "method" and callsig contains the original object plus original args?
20:51 whiteknight and vtable invoke will return a CallSignature with the set results and returns?
20:52 whiteknight or does invoke :vtable not return anything?
20:52 allison vtable invoke doesn't return anything, technically, but it needs a way to return things to the original call
20:52 allison returning a CallSignature seems the most straightforward
20:52 whiteknight in the interests of future-proofing it (think unifying args and returns) I think it should return a signature with returns
20:53 whiteknight okay. So Object.invoke() calls the override with the signature "PiPg->Pg"
20:53 allison (technically, it returns an opcode pointer, but we're not giving folks access to do that in PIR
20:54 whiteknight okay. I think I have it all straight in my mind now
20:54 allison whiteknight: yes, handling packaging up the old sig into the new sig, and unpackaging the return sig into the actual returns
20:54 allison whiteknight: can't do this until after 2.0, and NotFound's patch is the right fix for now
20:55 whiteknight okay. I think we could put together a branch to prototype some things now though
20:55 whiteknight what deprecation needs to happen for this to go in?
20:58 whiteknight just the current behavior of invoke :vtable?
20:58 NotFound invoke uses the siganture provided for the original call.
20:58 whiteknight okay
20:58 NotFound On returning you just need to put values on it.
20:59 NotFound And .return already does that.
20:59 allison whiteknight: we would be deprecating direct access to the parameters from the original call
21:00 whiteknight gotcha.
21:00 allison that is, an 'invoke' vtable override in PIR would always take a single argument .param pmc call_signature
21:01 allison and always return a single result, a call signature object
21:01 NotFound What? And complicating the more common usage?
21:01 allison NotFound: yes
21:01 NotFound That's insane.
21:02 allison NotFound: it's clean, which is important
21:02 allison it's also explainable, unlike most of our solutions so far
21:02 NotFound You mean the non-solutions?
21:03 allison and, it's the one solution that means the PIR invoke override is functionally equivalent to the C invoke vtable functions, instead of acting completely different
21:03 particle is it insane if it works, is correct, and is easy to explain?
21:03 NotFound If you want a clean and undesrstandable invoke method, just add a vtable invoke_method
21:03 allison and, when we move to Lorito, and are defining all vtable functions in terms of ops, it's how it'll have to work
21:04 allison (that is, there will be no C version to handle all the complex behavior of invoke)
21:04 NotFound particle: show me something that works now.
21:04 allison NotFound: your code works now
21:05 NotFound allison: yes, and you want to break it.
21:05 allison NotFound: a PMC defined in PIR needs to be able to do everything a PMC defined in C can do
21:06 allison (specifically, a Sub-like PMC defined in...)
21:07 NotFound allison: I don't think that means to force the simplest cases to add unnecessary complexity.
21:07 chromatic Where's the unnecessary complexity?
21:07 allison NotFound: the way I originally implemented Object.invoke (which you just fixed) was trying to dumb down invoke
21:08 NotFound If direct access to arguments is deprecated, some more convoluted way must be used.
21:08 allison NotFound: but it ends up hampering PMC writers
21:08 allison NotFound: the idea is that 'invoke' is a dispatcher
21:08 allison that's what it is in the VTABLE
21:09 allison and by making it act like a dispatcher, we make PMC writers more powerful
21:09 NotFound Very nice, but I still don't see the need to complicate the pir side.
21:09 allison we could even add a second string argument, with the name used to invoke the method/sub
21:09 allison that would be really helpful
21:10 chromatic We're *simplifying* the PIR side and the C side simultaneously.
21:10 allison it doesn't really complicate the PIR side, it just means that the really simple case of PIR invoke will probably be
21:11 allison .param pmc sig
21:11 allison self.'foo'(sig :call_sig)
21:11 allison (or something like that)
21:11 NotFound So the simplest and potentially faster case will need to use pir code to access his arguments.
21:12 chromatic ... unless you have an easy way to make the VTABLE_invoke macro take varargs in C.
21:13 NotFound Where are C args in that thing?
21:13 dalek parrot: r42426 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
21:13 dalek parrot: [distutils] split exe_pbc/installable_pbc
21:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42426/
21:13 allison NotFound: vtable overrides are overriding a C-level vtable function
21:14 allison NotFound: and usually have exactly the same signature as the C-level function
21:15 allison NotFound: I know it's strange, and it took me a while to wrap my head around it, but it is cleaner and more powerul this way
21:15 allison NotFound: even though the syntax isn't as pretty
21:16 jan joined #parrot
21:16 NotFound allison: the signature of invoke uses no C args.
21:17 allison NotFound: exactly, the call signature is handled out-of-band from the signature of the vtable function
21:17 NotFound Unless you call opcode_t * a C arg in that context.
21:18 allison NotFound: and the interpreter, and the PMC object (the sub), and a void pointer
21:18 allison but, we hide the interpreter from vtable overrides (consistently)
21:18 allison and the opcode_t* and void pointer aren't at all useful in PIR
21:19 NotFound allison: we hide the C arguments and provide pir ones in all other vtable overrides.
21:19 allison it's the one vtable function that really wasn't designed to be used from PIR, which is the cause of our headache
21:20 allison NotFound: aye, but we can't even do that with 'invoke'
21:20 dalek markdown: a6922c6 | fperrad++ | setup.pir:
21:20 dalek markdown: use installable_pbc instead of exe_pbc
21:20 dalek markdown: review: http://github.com/fperrad/markdown/commit​/a6922c6ed2b294bfb7a14622e6d70be7e47d4c48
21:20 allison NotFound: PIR doesn't have access to opcode pointers, or even an encapsulated way to deal with them
21:20 NotFound allison: we are currently doing.
21:21 allison NotFound: are currently doing what? (lost the train somewhere)
21:22 NotFound allison: we are passing to the invoke override the arguements from the pir that uses it, same as for any other.
21:22 NotFound Ii I override set_string_native I get a string.
21:23 NotFound If I overrdie invoke and use obj(string), I get a string.
21:26 chromatic If you override it from PIR, but not from C.
21:28 NotFound Of course.
21:28 purl Indubitably.
21:28 bluescreen joined #parrot
21:30 chromatic In one fell swoop, we can unify the behavior and implementation and interface of the C version and the PIR version.
21:31 NotFound chromatic: At the cost of complicating and slowing down the pir usage?
21:31 chromatic How does that slow it down and how does that complicate it?
21:32 chromatic Answer "slowing down" very carefully, because you don't have a benchmark.
21:32 NotFound Now I can just use the argument. If I must take a signature argument and extract the real arguments from it...
21:32 NotFound chromatic: I can't benchmark against a non exisent thing.
21:34 allison NotFound: how about if CallSignature had an "unpack" method?
21:35 allison ($P0, $P1, $S2) = sig."unpack"()
21:35 allison well, it would probably be named something like "fetch_args"
21:35 NotFound allison: even better if parrot does that automatically... as already does.
21:36 chromatic How is that better?  It slows down code that doesn't need to unpack the arguments.
21:36 allison NotFound: it's only better when the automatic behavior is what you want, but it's limiting in all other cases, because there's no way to get around it
21:37 allison i.e. there's no really good way to turn off the automatic behavior
21:37 NotFound allison: I have no problem with providing solution for more convoluted cases, I just fail to see why that implies complicating the simpler.
21:37 allison but, the one that really convinced me is that the automatic behavior can't be consistent
21:37 dalek TT #1264 created by quietfanatic++: Memory leak on sub call
21:38 allison 'self' just can't be right when a PIR object sub is acting as a method
21:38 allison in obj.foo(), self is wrong if it's object and wrong if it's foo
21:39 xenoterracide joined #parrot
21:39 allison (wrong if it's obj, because foo is really the vtable self, and wrong if it's foo because there's no way to get at the object of the method call)
21:39 NotFound I think the clean way can be to add an invoke_method and drop current_object from the context.
21:40 allison that complicates the whole system to provide some syntactic sugar
21:40 chromatic And that keeps a difference between the C version and the PIR version.
21:41 japhb joined #parrot
21:45 dalek wmlscript: aaba1f9 | fperrad++ | setup.pir:
21:45 dalek wmlscript: use installable_pbc instead of pbc_exe
21:45 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/aaba1f9828a1e8c7b16db7805c63d4b821f07f3c
21:49 dalek lua: bd95266 | fperrad++ | setup.pir:
21:49 dalek lua: use installable_pbc instead of exe_pbc
21:49 dalek lua: review: http://github.com/fperrad/lua/commit/bd​952664bf70fcb33ec8dd806ef02a3d443cf993
21:58 Austin_away Do we know if roles work in Parrot?
21:58 Austin Sorry.
21:58 Austin Do we know if roles work in Parrot?
21:59 moritz perl 6 roles work on top of parrot ;-)
21:59 moritz gues that doesn't really answers your question though
22:00 allison Austin: they are function, but not extensively tested
22:00 Austin Thanks.
22:00 allison functional
22:00 purl i think functional is probably difficult. Might be possible though. or side-effect free
22:01 Austin t/pmc/role.t is very short.
22:01 Austin :)
22:02 Austin According to Pdd15, roles mixin without inheritance. Does that mean that if Base does Role, and Base -> Sub, that Sub does not do Role?
22:02 allison Austin: it could be even worse than I remember
22:03 allison do you mean if Base does a role?
22:03 allison or Base composes Role itself?
22:03 Austin "Cheer up," they told me, "things could be worse." And so I cheered up. And sure enough, things got worse.
22:03 allison :)
22:04 Austin My understanding is that a class "does" a role.
22:04 Austin "A role adds attributes and methods into a class" [pdd15].
22:04 allison yes
22:04 Austin So if I define a Base class, and mixin Role to it, then Base does Role, yes?
22:04 NotFound Austin: mine was, but last time I tried to use does instead of isa people almost killed me X-)
22:04 allison but I'm not clear if you're asking about your own role
22:04 Austin In particular, the "does" opcode will set its output to non-zero
22:05 allison oh, you don't compose in Role, you create an instance of Role
22:05 allison and compose in the instance
22:05 Austin What does that mean?
22:05 purl That boy needs therapy.
22:05 allison as in $P0 = new ["Role"]
22:05 Austin Hmm.
22:05 allison to be less confusing
22:05 allison ...
22:06 mikehh joined #parrot
22:06 allison let's say you have a role "stringy"
22:06 allison it has some methods, like "get_my_string"
22:06 Austin okay
22:07 Austin So I have a .namespace ['stringy'] with those methods, yet?
22:07 Austin *yes?
22:07 allison if you define a class Base, and compose the role "stringy into it, then Base will have the method "get_my_string" in it
22:07 Austin Sounds good.
22:07 purl Sounds good. is there a good way for me to find out when branches are merged, other than read every svn commit?
22:07 Austin How do I do that?
22:07 allison roles are like classes, their methods live in the role, not in the namespace
22:07 Austin Umm.
22:08 allison not an important detail
22:08 Austin Since I'm spending a lot of time defining methods in namespaces, I'm really unsure what you mean by that.
22:08 Austin Okay.
22:08 pmichaud purl, forget Sounds good.
22:08 purl pmichaud, I didn't have anything matching sounds good
22:08 Austin So I have a new [ 'Role' ]
22:09 allison Austin: if you look at the code for the namespace, it stores those methods in the class, but it's not an important detail
22:09 allison yes, you have a new Role
22:09 Austin According to role.t, I give it a name in the init pmc.
22:09 particle how do i set up irssi for irc.perl.org?
22:09 allison and, you add methods and attributes to it
22:09 Austin Now I want Base to "does" my Role.
22:09 Austin (stringy)
22:09 allison yes
22:09 Austin So I get my Base class object. And add_role to it?
22:09 Whiteknight joined #parrot
22:10 allison yes, exactly
22:10 Austin So now Base does stringy.
22:10 allison yes
22:11 Austin And if I say 7 $P0 = get_class ... Base ... ; $I0 = does $P0, [ 'stringy']  then $I0 will be non-zero.
22:11 allison it should be, yes
22:12 Austin Or do roles not use keys? Should it be 7 does $P0, "stringy"  ?
22:12 pmichaud would 'does' apply to the class object, or just to instances of the class?
22:12 allison Austin: it should accept keys
22:12 pmichaud (that sounds like the same isa/typeof issues we've talked about in the past, so just curious)
22:12 Austin Hmm. Good question, pmichaud.
22:13 allison pmichaud: have to check the code
22:13 * allison looks
22:13 pmichaud anyway, possibly not important to the current discussion.
22:13 pmichaud but I'd certainly expect   $P0 = new ['Base'];  $I0 = does $P0, ['stringy']   to be true
22:13 Austin So if I create a derived class Base -> Derived, what is the status vis-a-vis Derived does stringy ?
22:14 pmichaud instances of derived should also be "does stringy"
22:14 Austin The suggestion in pdd15 is that "no."
22:14 pmichaud Austin: line no?
22:14 Austin =head3 role
22:14 pmichaud (or key phrase)
22:15 Austin "A role adds attributes and methods intlo a class without inheritance"
22:15 Austin *into
22:15 pmichaud ah, there's a different interpretation there
22:15 Austin My impression is that you add in the role and it dissolves.
22:15 allison pmichaud: it looks like it's currently checking what's composed into the class or role
22:15 pmichaud a class with a role composed into it is not a subclass of the role
22:16 pmichaud a role simply composes methods and attributes into a class
22:16 allison pmichaud: so, not restricted to responding from the object like isa is
22:16 allison pmichaud: (and there's a good chance that should change)
22:16 pmichaud allison: good to know, thanks.
22:16 purl good to know, thanks. is there a free version of that I can install (linux or win32) to play with?
22:16 NotFound Austin: that means that you don't need to inherit from other class, in order to get some methods and attributes from other part.
22:16 NotFound At least, I read it that way.
22:16 pmichaud Austin: subclasses of the composed class will have all of the methods and attributes of the base class, including those obtained from role
22:17 Austin Sure.
22:17 Austin But will they "does stringy" or not?
22:17 pmichaud I'm pretty sure they "does stringy".
22:17 allison Austin: mostly true, in that you don't keep a search tree of all the parents and traverse them for finding methods
22:17 Austin :)
22:17 allison Austin: but you do keep an idea of what roles you've composed
22:17 NotFound Write a test, and if it fails, TODO it ;)
22:17 allison Austin: specifically so you can check "does stringy"
22:18 Austin Okay, so for e.g., C3 computations, the methods from stringy are dissolved into Base. But for "does stringy" purposes, Base remembers that it has stringy, and Derived will also know that it inherits "does stringy" from Base?
22:19 Austin *has stringy = does stringy
22:19 allison yes
22:20 Austin What's the mechanism for composing in a role?
22:20 Austin I think P6object goes hunting for methods and adds them to the child class. Does role composition need that?
22:23 Austin Allison: On an unrelated note, is there a documentation standard for indicating "vtable methods" versus "pir-callable methods" on pmcs? Right now I see "=head3 Methods" on top of a bunch of VTABLE declarations.
22:23 allison when you call add_role, it inserts the existing role methods into the class
22:23 allison "vtable function" versus "method"
22:23 Austin Okay.
22:24 Austin Okay.
22:24 allison so, if you see Methods as a header for vtable functions, it should be changed to "Vtable Functions"
22:25 allison (old documentation, especially before we had an object system, was pretty confused on the naming)
22:25 chromatic Hm, a memory leak in CallSignatureReturns.
22:29 dalek parrot: r42427 | chromatic++ | trunk/src/pmc/callsignaturereturns.pmc:
22:29 dalek parrot: [PMC] Added init() to CallSignatureReturns PMC to set the custom destruction
22:29 dalek parrot: flag.  This plugs a memory leak and partially fixes TT #1264 (reported by Lewis
22:29 dalek parrot: Wall).
22:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42427/
22:33 cotto_work doesn't pmc2c take care of that?
22:33 cotto_work chromatic: ^
22:34 chromatic If so, I didn't know.
22:34 chromatic Certainly the code doesn't behave as if that were the case.
22:35 Whiteknight apparently microsoft patented sudi
22:35 Whiteknight sudo
22:35 Whiteknight so that makes me happy
22:35 allison cotto: pmc2c couldn't know it needed custom destruction, could it?
22:35 cotto_work pmc2c really should be smart enough to set those flags when a custom mark/destroy is defined
22:35 chromatic Where would pmc2c set those flags?
22:35 darbelo cotto_work: It should be. It isn't.
22:36 cotto_work wherever it allocates memory for the attrs
22:36 chromatic msg fperrad Is there any reason PackfileDirectory doesn't set the destroy flag in init()?
22:36 purl Message for fperrad stored.
22:36 chromatic We can handle attrs automatically.  That's not the problem.
22:36 NotFound cotto_work: I thinked about that in the auto_attrs branch, but decided it was to risky at that moment.
22:36 NotFound s/to/too
22:38 theory joined #parrot
22:39 cotto_work It might be good to do now.  You could even do a runtime check by comparing pointers and setting the flags if those VTABLE entries don't match Default's destroy/mark, though that might not be the prettiest method.
22:40 darbelo cotto_work: You'll need a deprecation notice.
22:40 NotFound cotto_work: I'll better wait until auto_attrs becomes the default.
22:41 cotto_work probably so.  It just strikes me as silly that those flags need to be set manually.
22:41 NotFound And we don't even have no_auto_attrs implemented.
22:42 darbelo no_auto_attrs? I like the idea, but with a better name.
22:43 NotFound darbelo: ideas welcome.
22:43 cotto_work manual_attrs?
22:43 darbelo Better than anything I'd come up with. +1
22:44 * cotto_work whips out thesaurus
22:44 NotFound My idea is to introduce that flag, later emit a warning if no manual nor auto are specified, and later make auto the default.
22:44 NotFound A lot of deprecation points.
22:44 * darbelo looks up thesaurus in his dictionary.
22:45 cotto_work explicit_attrs?
22:45 NotFound I must create a ticket to discuss that plan.
22:46 darbelo NotFound: If you implement the other flag before 2.0 you can put a notice there and ship 2.1 with the new behaviour.
22:46 cotto_work +1 < and a preemptive purl-- >
22:46 NotFound Well, implementing it will be easy, it just needs to do nothing.
22:46 darbelo Then what's holding you back?
22:46 darbelo ;)
22:47 cotto_work It's nice to have a deprecation point coming up.  it makes it feel like deprecations can make a foreseeable difference.
22:47 NotFound Maybe checking that both are not specified together.
22:47 cotto_work stick_attrs?
22:47 cotto_work ;)
22:47 NotFound darbelo: thinking about editing and checking perl code makes me feel lazy ;)
22:48 chromatic Hm, and there's a memory leak in Context.
22:48 darbelo Stop checking. We'll let you know if you break it.
22:49 chromatic Yep, 104 bytes leaked for every Context... but the good news is they're merely leaking PMC attribute pools, so they get cleaned up during global destruction.
22:49 NotFound Well, I think that you can start using the flag right now with the name you choose, because there is no check for non existent flags.
22:50 cotto_work pmc2c--
22:50 darbelo pmc2c-- indeed.
22:50 cotto_work karma pmc2c
22:50 purl pmc2c has karma of -9
22:51 darbelo -9? pmc2c--
22:51 darbelo pmc2c--
22:51 darbelo pmc2c--
22:51 darbelo pmc2c--
22:51 moritz seen Infinoid
22:51 purl Infinoid was last seen on purl 8 days, 11 hours, 59 minutes and 17 seconds ago, saying: <private message>  [Nov  3 10:51:48 2009]
22:51 cotto_work I'll be very happy the day it dies.
22:52 darbelo Preach it!
22:52 chromatic You're going to love this next commit
22:52 moritz is there any subsystem that doesn't either need a major rewrite, or die?
22:52 cotto_work Oh boy!
22:52 diakopter chromatic: you wrote a new pir backend?
22:53 darbelo moritz: We have code too scary to rewrite or kill. Does that count?
22:53 NotFound moritz: maybe the Null PMC
22:53 chromatic I plugged more of a leak.
22:53 cotto_work moritz, anything that's been rewritten in the last year or two.
22:53 * moritz wonders if that's the case in most larger projects
22:54 diakopter to scary to rewrite or kill? sounds like it needs another wrapper layer on top. :)
22:54 diakopter too*
22:54 darbelo Probably.
22:54 diakopter or bottom.
22:55 cotto_work chromatic, wow.
22:55 dalek parrot: r42428 | chromatic++ | trunk/src/pmc/context.pmc:
22:55 dalek parrot: [PMC] Plugged a memory leak in Context's destroy(), where NULLing the Context's
22:55 dalek parrot: attributes prevented Parrot_pmc_destroy() from being able to recycle
22:55 dalek parrot: auto-allocated attributes.  This fixes at least part of the leak reported by
22:55 dalek parrot: Lewis Wall in TT #1264.
22:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42428/
22:57 darbelo That can be a lot of leaked memory.
22:58 chromatic Huge.
22:59 darbelo Pity I'm too lazy to get some hard numbers.
23:01 cotto_work chromatic, have you looked for similar bugs?
23:02 chromatic I'm looking now.
23:02 cotto_work PackfileDirectory looks suspicious
23:03 cotto_work afaict the rest are fine, assuming they all use PMC_data(x)
23:03 payload joined #parrot
23:03 chromatic PackfileDirectory bothers me, but when I added a custom destroy flag, I saw a lot of invalid free() errors.
23:04 chromatic ... though that's probably because it doesn't need its own destroy.
23:05 bacek_at_work chromatic, PackfileDirectory.destroy is wrong
23:05 chromatic Looks that way.
23:07 NotFound The default packfile destruction and the interpreter destruction are itermixed in a hard to fix way.
23:08 darbelo packfiles look like they could go into the 'ItsABugHunt' wiki page.
23:10 NotFound The packfile structures by itself doesn't look too bad, but his integration with other parts complicates the ensemble.
23:10 bacek_at_work darbelo, there is old idea about using PMCs for packfiles. I didn't have time to do it during implementing Packfile* PMCs...
23:10 darbelo NotFound: That page is more about the surrounding code than the structures mentioned, FWIW.
23:11 NotFound bacek_at_work: by the way, are all PackfileSegment subtypes supposed to have a type method?
23:11 darbelo bacek_at_work: Is it documented anywhere? I'll be knee deep in packfiles for the freeze/thaw refactor.
23:12 bacek_at_work NotFound, I think so.
23:13 NotFound bacek_at_work: PackfileAnnotations lack it
23:13 Austin bacek_at_work: A while ago, I remember reading a document you wrote on how to generated a pbc from PIR. Where is that document?
23:14 chromatic bacek_at_work, does set_integer_native() in CallSignatureReturns need a Parrot_gc_free_fixed_size_storage() when switching to the system allocator?
23:14 bacek_at_work NotFound, it probably inherit it from PFSegment
23:14 bacek_at_work Austin, somewhere in examples
23:14 NotFound bacek_at_work: surely not.
23:15 Austin ok, thanks
23:15 bacek_at_work chromatic, no idea. I can't dig into parrot sources now.
23:15 bacek_at_work NotFound, then we have to add it.
23:15 bacek_at_work darbelo, nope. It was some old ticket about Packfiles.
23:15 * darbelo goes ticket digging.
23:16 NotFound bacek_at_work: I was doing a simple pbc dumper using Packfile PMC, in order to check his capabilities, and discovered that.
23:16 bacek_at_work NotFound, bug... Just add it.
23:16 NotFound Doing it with Winxed, BTW ;)
23:16 NotFound bacek_at_work: ok
23:19 bacek_at_work darbelo, TT#504
23:20 bacek_at_work Austin, TT#1011
23:20 darbelo bacek++
23:25 chromatic Ahhh, this one is subtle.
23:26 chromatic ... and there it is.
23:27 * darbelo shudders every time chromatic says 'subtle'
23:27 japhb "Subtle are the ways of wizards and dragons" ?
23:28 darbelo japhb: Exactly, up until the moment they strike you down with lightning or eat you.
23:28 dalek parrot: r42429 | NotFound++ | trunk/src/pmc/packfileannotations.pmc:
23:28 dalek parrot: [pmc] METHOD type in packfileannotations
23:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42429/
23:29 diakopter rakudo: tlety
23:29 diakopter darn
23:30 diakopter darbelo: I didn't know dragons could strike you down with lightning
23:30 chromatic We always allocate at least a pointer's worth of fixed-sized memory for every Context's register set even if the Context needs no registers.
23:30 japhb darbelo, depends on the type of dragon ...
23:30 chromatic However, we never free that memory back to a fixed size pool if the Context has no registers.
23:30 japhb er, that was to diakopter
23:32 darbelo chromatic: Ugh. That has potential be another *big* wad o' leaked memory.
23:32 chromatic It doesn't anymore.
23:33 darbelo chromatic++
23:33 kid51 joined #parrot
23:35 dalek parrot: r42430 | chromatic++ | trunk/src/pmc/callsignaturereturns.pmc:
23:35 dalek parrot: [PMC] Fixed a memory leak in set_integer_native() when switching from a fixed
23:35 dalek parrot: size allocation for the returns array to a system-malloc()ed allocation.
23:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42430/
23:35 dalek parrot: r42431 | chromatic++ | trunk/src/call/context.c:
23:35 dalek parrot: [PCC] Fixed a memory leak of register storage for Contexts which need no
23:35 dalek parrot: registers.  Previously, we allocated fixed-sized storage for the register set
23:35 dalek parrot: even if we didn't need it; that allocation always returns at least one
23:35 dalek parrot: pointer's worth of memory.  However, Parrot_pcc_free_registers() skips freeing
23:35 dalek parrot: the register storage back to a fixed-size pool if the Context has no registers.
23:35 dalek parrot: Skipping the allocation avoids this problem.  This fixes the final part of the
23:35 dalek parrot: leak reported by Lewis Wall in TT #1264.
23:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42431/
23:37 dalek TT #1264 closed by chromatic++: Memory leak on sub call
23:44 dalek rakudo: 365404e | moritz++ | src/setting/Any-str.pm:
23:44 dalek rakudo: optimize Str.samecase a wee bit
23:44 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​65404e92751be94660c6e5ebe5fea03710b7131
23:44 dalek rakudo: f87efac | moritz++ | src/builtins/any-str.pir:
23:44 dalek rakudo: fix RT #70415, substr() returned a parrot String, not a Str
23:44 dalek rakudo: This resulted in split() also returning Strings.
23:44 dalek rakudo: jnthn++ for suggesting the correct fix.
23:44 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​87efac027edf84bff2b8578a9762ac8ab8b44ca
23:45 cotto_work I love it when people close bugs that quickly.
23:45 cotto_work chromatic++
23:46 whoppix joined #parrot
23:48 plobsing hi #parrot
23:48 darbelo hi plobsing
23:49 japhb o/
23:50 plobsing whats the status on libjit_framebuilder?
23:50 darbelo cotto_work (or was it cotto? I keep confusing them.) had a failing test today.
23:51 nopaste joined #parrot
23:51 plobsing seen cotto
23:51 purl cotto was last seen on #parrot 21 hours, 40 minutes and 2 seconds ago, saying: night
23:51 plobsing seen cotto_work
23:51 purl cotto_work was last seen on #parrot 6 minutes and 36 seconds ago, saying: chromatic++
23:52 plobsing cotto_work: you had test failures in libjit_framebuilder?
23:54 cotto_work plobsing, yes
23:54 plobsing what test(s)?
23:54 plobsing what platform?
23:55 cotto_work Ubuntu 9.04 x64
23:55 cotto_work The nci_ssc test in t/pmc/nci.t
23:55 plobsing that gem.
23:55 plobsing what's the diag?
23:55 purl well, the diag is quite clear from test onwards
23:55 cotto_work It works fine without libjit but fails with
23:55 cotto_work ?
23:55 plobsing diagnostic message
23:55 purl i guess diagnostic message is explained as "The lexeer counted more opening curly brackes (braces) than closing ones."
23:55 cotto_work 65530
23:55 cotto_work that one?
23:55 purl rumour has it that one is fairly new
23:56 cotto_work purl, go play in traffic
23:56 * purl wanders off to dent some cars.
23:56 plobsing yes. thats useful
23:56 plobsing though I thought I nopasted a fix for that
23:56 cotto_work Cool.  I thought it was just broken noise
23:57 nopaste "cotto" at 131.107.0.74 pasted "current diff from libjit branch" (21 lines) at http://nopaste.snit.ch/18644
23:57 cotto_work That's what I have applied against that branch.
23:58 plobsing hmmm... that ought to do it
23:58 plobsing it worked on my machine before. retesting...
23:59 cotto_work it failed even after a realclean

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

Parrot | source cross referenced