Parrot 1.7.0 "African Grey" is out! | Testing hackathon November 14 and 15 -- improve opcode coverage | find out what's up with the slice opcode | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 10 November 2009.
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
not short->long
this is a bug where int!=long
Whiteknight ah, that makes sense then
plobsing so my modification of the test had the intended effect :-) 00:02
cotto_work: the number of tests in that file is 71 + $num_nci_sigs 00:04
00:04 abqar joined
plobsing where $num_nci_sigs is the number of signatures to be thunked by nativecall.pl 00:04
dalek kudo: f16c9e2 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 451 files, 32696 (85.2% of 38389) pass, 15 fail

S02-lexical-conventions/unicode.rakudo aborted 5 test(s) S12-introspection/methods.t aborted 10 test(s)
plobsing so it will vary from config to config
chromatic Hm, Rakudo passes more tests than before the great PCC conversion. 00:06
dalek TT #1263 created by jkeenan++: Determine configuration value for 'platform' prior to gen::platform 00:09
TT #1194 closed by jkeenan++: 7 config steps improperly rely on Perl 5 %Config 'OSNAME' element 00:13
rrot: r42413 | jkeenan++ | branches/platform_determine_earlier:
Create a branch to work on trac.parrot.org/parrot/ticket/1263:
 00:15
00:23 darbelo joined
darbelo I *really* hate it when X crashes. 00:24
nopaste "plobsing" at 76.67.61.178 pasted "ssc non-libjit fix" (13 lines) at nopaste.snit.ch/18632 00:33
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
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
dalek rrot-plumage: 0d6374a | japhb++ | :
[plumage] Simplify action functions considerably by improving CWD handli...
 00:43
dukeleto parrot github repo should be sync'ing once per hour now, for your pleasure. 00:47
also, git.or.cz now supports git mirrors of svn repos. i need to try that out. 00:48
kiwichris Looking at Parrot_new I see its decl states it cannot return NULL. What happens if memory runs out ? 00:53
plobsing msg Whiteknight nopaste.snit.ch/18632 should fix the ssc issue on non-libjit x86_64 00:54
purl Message for whiteknight stored.
darbelo needs sleep 00:56
See y'all later.
00:56 darbelo left
dalek tracwiki: v2 | samlh++ | RakudoTasklist 00:56
tracwiki: Prettify (probably unnecessarily)
tracwiki: trac.parrot.org/parrot/wiki/Rakudo...ction=diff
Whiteknight plobsing: i'll take a look at it
dalek rrot-plumage: 8dcf4b2 | japhb++ | :
[plumage] Use NQP-rx, stage 1: string interpolation
 01:00
Austin In the PMC documentation, is =head2 Methods supposed to introduce vtable items or method items? 01:03
Whiteknight method items, I assume 01:04
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
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.)
If I could translate karma into frequent flier miles, maybe.
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?
Whiteknight none
Austin None?
purl None is, like, :/
Austin :?
purl well, : is the path separator
Whiteknight .'segfault'()
Austin :-?
Whiteknight .'throw_weird_exception'()
.'magically_become_defined'()
Austin Ahh, you see, I've already defined 5 methods.
You're just not trying. 01:08
Whiteknight maybe I'm trying hard, but am just really stupid?
Austin .can(), .does(), .defined(), .isa(), .new()
Whiteknight never overestimate me
all those on Undef?
Austin Yep.
Meta-stuff should work just about anywhere. (Especially .defined()) 01:09
!!Especially!! defined()
So why not make them methods?
plobsing what variant of the concept of nullity is Undef trying to provide? Perl5's? Perl6's? Language X's? 01:10
Austin plobsing: yes. 01:11
japhb <nihilism>It's all nothingness anyway ... why try to figure it out?</nihilism> 01:13
nopaste "kiwichris" at 203.206.130.106 pasted "RTEMS: parrot-1.7.0/examples/benchmarks/rand.pir fails." (106 lines) at nopaste.snit.ch/18633 01:16
Whiteknight plobsing: patch works. All tests pass here without libjit installed 01:17
next step is to install libjit
dalek rrot-plumage: 45792ee | japhb++ | :
[plumage] Use NQP-rx, stage 2: pir::
 01:22
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
for libjit, I did "./configure && make && sudo make install"
and I thought that worked 01:24
plobsing you need to run ldconfig
01:24 theory joined
Whiteknight I've got libjit.so.0 in my /usr/local/lib folder 01:25
what's ldconfig?
purl it has been said that ldconfig is not hard
Whiteknight thanks, purl
purl, thanks, purl is <reply>no, thank you
plobsing ldconfig updates your dynamic linker cache (from what I've gathered) 01:26
dynamic linking still seems a little voodoo to me
Whiteknight yeah, definitely voodoo 01:27
but I ran it, and now thigns work
plobsing yay
Whiteknight lobsing++
plobsing++
01:28 Zak joined, mikehh joined
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.
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
it's a small issue though, something we can save till later 01:35
plobsing config/gen/call_list/core.in maybe?
of course some of those aren't called by all programs 01:37
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.
plobsing Austin++ simplicity=genius 01:40
Austin Git 'r done.
Whiteknight plobsing: with libjit installed now, I fail that same test
nci_ssc
plobsing hmmm.
what number are you getting?
Whiteknight 65530 01:41
plobsing arg. improper sign extension, you are the bane of my existance!
fyi 65530 is better known as 2**16 - 6 01:46
Whiteknight ah yes, sign extension. My old nemesis 01:47
dukeleto what a day 01:49
purl somebody said a day was a reasonable time to wait for cpan to catch up
nopaste "plobsing" at 76.67.61.178 pasted "add proper sign extension for the nth time" (19 lines) at nopaste.snit.ch/18634
diakopter my PAST interpreter in JavaScript proceedeth. it passes the first 10 nqp-rx test files 01:51
Tene: ^^ in case you were wondering.. 01:52
plobsing oops that paste really shouldn't work!
I have no idea how it passed
Austin Man, tortoisegit is so damn slow I think it would be easier to run a separate git-gui app. :( 01:54
nopaste "plobsing" at 76.67.61.178 pasted "add proper sign extension for the (n + 1)th time" (19 lines) at nopaste.snit.ch/18635 01:56
dukeleto anybody have any thoughts about Go? golang.org/doc/go_faq.html
Whiteknight isn't that a game that I'm terrible at? 01:57
dukeleto: that looks very interesting 01:59
Austin Dude, that language will never succeed. 02:00
Remember the rule.
dalek rrot: r42414 | cotto++ | trunk/DEPRECATED.pod:
[DEPRECATED] clarify VTABLE deprecations currently eligible for removal
 02:01
plobsing and what rule is that exactly? 02:05
Austin No language with ':=' will ever succeed.
plobsing touche
Austin It's the operator of doom.
02:06 eternaleye joined
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.
dukeleto Pascal uses := too 02:07
plobsing aren't most of those wirth languages?
Austin And let's not forget Ada, that uber-success story.
Whiteknight plobsing: no dice. Latest patch didn't fix the test failure 02:08
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?
Whiteknight same test, nci_ssc 02:10
cotto ohai
Whiteknight hello cotto_not_at_work
but can't stay to talk. Need to go to sleep. Goodnight 02:11
cotto night
dalek rrot: r42415 | cotto++ | trunk/DEPRECATED.pod:
[DEPRECATED] add notice about bitwise ops and VTABLE functions
rrot: r42416 | whiteknight++ | branches/libjit_framebuilder/lib/Parrot/NativeCall.pm:
[libjit] apply one patch from plobsing++ to fix short conversions on x86_64 without libjit installed
nopaste "plobsing" at 76.67.61.178 pasted "64-bit fix (now with 100% less syntax fail)" (19 lines) at nopaste.snit.ch/18636 02:25
plobsing msg Whiteknight this one aught to do it: nopaste.snit.ch/18636 02:26
purl Message for whiteknight stored.
dalek rrot-plumage: 70bda0e | japhb++ | :
[CORE] Add %hash.values and @array.reverse
 02:40
rrot-plumage: 294058c | japhb++ | :
[plumage] Use NQP-rx, stage 3: pointy blocks in for loops
rrot: r42417 | jkeenan++ | branches/platform_determine_earlier (4 files):
Create a Parrot::Configure attribute 'platform' in auto::arch; use it in

to adapt tests for _get_platform() in t/steps/auto/arch-01.t.		 02:41
tracwiki: v118 | jkeenan++ | WikiStart 03:06
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
kiwichris msg rand fixed by statically linking dynops 03:21
purl Sorry, I've never seen rand before.
03:41 janus joined 03:43 elmex joined 03:53 DrForr_ joined
dalek rrot-plumage: 2891881 | japhb++ | :
[plumage] Add status command; use grep() in get_installed_projects
 03:53
rrot-plumage: bc02198 | japhb++ | :
[META] TODO update
04:02 hercynium joined
dalek rrot-plumage: b327f3c | japhb++ | :
[plumage] Use NQP-rx, stage 4: git rid of as_array() in most places
 04:15
tracwiki: v41 | bacek++ | ParrotQuotes 04:31
tracwiki: Definition of "operator of doom"
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
05:05 kiwichris joined 05:29 cottoo joined 06:05 nbrown joined 06:06 theory joined 06:21 magnachef joined 06:39 mikehh joined 06:51 chromatic joined 07:03 victori joined 07:10 JimmyZ joined 07:11 payload joined 07:14 uniejo joined 07:25 bacek joined 07:59 iblechbot joined 08:10 barney joined 08:12 fperrad joined 08:18 payload joined 08:22 mokurai left
moritz golang.org/doc/go_lang_faq.html they use CSP for yet another thing 08:32
09:09 pdcawley_ joined 09:14 AndyA joined 09:28 victori left
dalek rrot: r42418 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add chmod
 09:52
10:02 TiMBuS joined 10:36 jsut joined 10:54 elmex joined 10:56 AndyA joined 11:02 payload joined 11:48 AndyA joined
dalek rrot: r42419 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add stuff for nqp-rx
 12:00
12:00 AndyA joined
12:03 bluescreen joined 12:04 mikehh joined 12:08 bluescreen joined 12:19 AndyA joined 12:31 payload joined
dalek rrot: r42420 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add options : harness_exec & harness_files
 12:39
13:05 whiteknight joined
dalek rrot: r42421 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] split cp/install
 13:09
whiteknight good morning #parrot 13:23
plobsing hi whiteknight 13:27
whiteknight hello plobsing
I'll test that new patch out tonight
plobsing sorry about the other two patches. turns out they didn't even compile
serves me right for doing configure; make; test instead of using && 13:28
whiteknight oh 13:29
yeah, I've gotten into those problems before 13:36
I've developed a very elaborate alias "build" to do all those things in the right sequence
14:11 payload joined
whiteknight I think we should be able to get this branch merged soon 14:18
pending more testing.
what we probably want to do is write out a lot of instructions for people on how to get libjit 14:19
14:24 mj41 joined 14:35 pdcawley__ joined
whiteknight For anybody who is interested in JIT, here is a very interesting email exchange between the libJIT and LLVM guys: 14:46
lists.gnu.org/archive/html/dotgnu-l...00012.html
(gets a little heated, but that's to be expected. And they mention Parrot a lot)
15:01 patspam joined 15:20 Psyche^ joined 15:30 Essobi joined 15:31 Austin joined 15:32 bubaflub joined 15:47 theory joined
bubaflub morning parrot people 15:52
whiteknight good morning bubaflub 15:56
15:57 darbelo joined
dalek kudo: a02a26e | (Kyle Hasselbacher)++ | tools/update_passing_test_data.pl:
tools/update_passing_test_data.pl: ignore spectest.data comments better
 15:57
15:58 payload joined
whiteknight thinks he might finally be able to send in his updated PaFo CLA 15:59
s/be able to/be unlazy enough to/
plus, I think I finally understand how the fax machine here works
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
fperrad ping allison
purl I can't find allison in the DNS.
allison fperrad: hi
fperrad allison, distutils.pir could replace dynops.pl & dynpmc.pl 16:03
allison fperrad: Sounds good. I haven't looked at it, what does it do? 16:04
fperrad allison, distutils.pir has the same interface as Python Distutils 16:06
and has rules to build pge, tge, nqp, nqp-rx, dynops, dynpmc, pbc, pbc_to_exe
nopaste "fperrad" at 78.113.94.6 pasted "setup.pir for Pynie (allison)" (105 lines) at nopaste.snit.ch/18637 16:08
Austin Whiteknight: Updated CLA?
whiteknight Austin: I sent in a Perl Foundation CLA a long time ago, but I need to send in a Parrot CLA now
and I haven't done it
Austin Ah.
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:09
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:10
fperrad allison, yes, distutils.pir remove many dependencies 16:11
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?
moritz for example by being called concurrently?
whiteknight fperrad: where is distutils.pir located? parrot repo?
fperrad in parrot repo, runtime/parrot/library/ 16:13
allison, github.com/fperrad/wmlscript/blob/m.../setup.pir 16:14
16:16 Andy_ joined 16:19 joeri joined
dalek rrot: r42422 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] setup() loops on all targets
 16:31
16:34 cotto_work joined
cotto_work good morning 16:36
dukeleto cotto_work: hola 16:37
good to hear that we are having a testing hackathon soon 16:38
i should write a more detailed howto/post about translating tests
cotto_work good idea
purl cotto_work: Good Idea: Stopping to smell the roses. Bad Idea: Stopping to feel the roses.
whiteknight good morning cotto_work, dukeleto 16:41
yes, I'm excited about testing hackathon
cotto_work I just realized that the hackathon is a great excuse to get cracking on writing test code for the profiler. 16:44
w00t
whiteknight has anybody heard from bernhard recently? 16:49
He's supposed to do 1.8.0 but I don't think I've seen him around
moritz he committed a few changelog updates recently
cotto_work He's been around.
whiteknight of course, I probably haven't been looking too hard
cotto_work he's aka barney
moritz seen barney
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]
whiteknight bernhard? 16:50
purl bernhard is mailto:Bernhard.Schmalhofer@gmx.de
whiteknight barney?
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
whiteknight ...that's not very flattering 16:51
allison different barney
whiteknight robble, robble
allison I believe #perl had a hate-hate relationship with the child's tv character 16:52
cotto_work perfectly understandable
whiteknight of course, that's a perfectly reasonable way to spend your time
allison highly logical
whiteknight hamburglar? 16:53
purl somebody said hamburglar was on the way out too. convicts are complaining
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 www.goats.com/archive/980204.html
whiteknight ...that's even less appropriate
cotto_work With the first two entries, I'm definitely not following that link. 16:55
darbelo goat dildos? 16:56
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.
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
and if there's one thing kids hate, it's getting their favorite characters mixed up
cotto_work code.google.com/p/go/source/detail?...3c480d995f
whiteknight ...or mixing up star trek and star wars :)
cotto_work longest overdue commit ever 17:00
whiteknight I propose that we delete the current repository and rewrite Parrot from the ground up in Go 17:01
cotto_work +1 17:02
purl 1
whiteknight proof that the language is suitable, or that it will provide any actual benefits is not necessary
cotto_work Go is obviously the future. We should abandon this C junk.
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
Austin Go is a doomed language. Forget it. 17:03
They broke the rule, they suffer the consequences.
whiteknight so is C. In another 200-300 rules, it will slowly be phased out
and then what? That's right, Go 17:04
"200-300 years"
cotto_work nice typo
17:05 mokurai joined
Austin Whiteknight has a rules fetish. 17:05
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 kudo: 50e495b | (Kyle Hasselbacher)++ | t/spectest.data:
[spectest.data] add a couple runnable files
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?
Maybe we could get the transmeta guys to do parrot in silicon for us...
17:09 redbrain joined
Austin What's the right name for the progression indicated by labels like ":anon", ":init", ":load", and ":main"? 17:11
Are those phases, stages, lifecycle-states, events, ...? 17:12
barney whiteknight: I'm here, been on the phone
barney prefers to be Barney from the Flintstones 17:13
brubble Sorry, taken.
;)
darbelo ;) 17:14
whiteknight barney: okay, I'm just making sure everything is ready for the release 17:15
barney I'll send out a call for updates (NEWS,PLATFORMS) tonight 17:16
whiteknight awesme 17:17
redbrain is it hard getting the releases out? 17:18
cotto_work not at all
it just involves a lot of waiting while tests run
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.
cotto_work and gathering information
redbrain lol 17:19
cotto_work and submitting to various news site
Austin Look at the logs for the 1.7 release.
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.
Then it was "Yeah, this *is* easy. I'm just following along the documenta ... holy crap!"
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
well i do have a bit of a readme to compile it etc
Austin Welcome to the team.
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
we've already done more of that this month
17:22 mikehh joined
whiteknight redbrain: is it hosted publicly 17:23
?
redbrain yeah i guess lol
whiteknight link?
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.
redbrain its on crules.org but i had some server problems recently so i lost my wiki content and my redmine project tracking content
at least thats all i lost
lol
i had backups of everything else
whiteknight #perl is raping my childhood
redbrain i was more worried about the 4/5 people i host on my servers but it was ok 17:24
diakopter whiteknight: ouch.
Austin whiteknight ? 17:27
purl it has been said that whiteknight is mailto:wknight8111@gmail.com or the grand master funk or wknight8111.blogspot.com/
whiteknight Austin? 17:28
purl Austin is, like, nice. or a city in Texas
whiteknight you *are* like a city in Texas
Austin Raping your childhood?
whiteknight yeah, calling grimace a dildo, or saying like is a pointy eared goblin
Austin Bigger than I should be, and full of criminals?
whiteknight no, that's just the Cowboys
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.
PerlJam redbrain: far too many of us are in Texas, let alone America :)
redbrain lol awesome one of my friends lived in texas for like 3/4 years 17:30
he liked it
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.
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
Austin They'll be here at localtime-appropriate points.
redbrain what time is it with you guys then its 17:31 here :)
purl redbrain: It's just about half past five in the afternoon where I am.
Austin European Commonwealth
cotto_work I've never heard Australia referred to as British Texas.
whiteknight it's lunch time here
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 :)
PerlJam redbrain: it's 17:31 here too ... but my clock is set to UTC ;)
Austin clock?
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 /
redbrain hehe :)
PerlJam Austin: are you saying Texas was colonized by a bunch of criminals?
Austin PerlJam: yes.
whiteknight s/colonized/still inhabited by/
PerlJam Austin: including your namesake? :) 17:33
whiteknight jokes
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
Austin PerlJam: Technically, my namesake is Ulysses S. Grant. But if you mean Sam Austin, then (as they say in Texas), "Hell yes!"
whiteknight redbrain: but that's not a "problem", it's a "tradition"
PerlJam "Sam Austin"?
redbrain thats true :)
PerlJam Stephen F. Austin
Sam Houston
Austin Ah.
You have me there.
redbrain is it your full time job to work on parrot then? :) 17:35
whiteknight I wish that were my job 17:36
PerlJam That would be something.
redbrain rofl
whiteknight I would quit all my other jobs in a heartbeat
redbrain yeah same
Austin Whiteknight: Can't you get one of those grant things?
whiteknight well, s/in a heartbeat/with two weeks notice/
Austin: grant from where?
PerlJam whiteknight: start a company that provides software solutions based on parrot.
whiteknight they don't just grow on trees
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?
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
whiteknight sap? I LOVE to hate sap
:)
redbrain haha yeah i hated that job haha
sap are crooks tbh esp research 17:38
never want to work in research ever!
lol
cotto_work TPF does grants, but it's mostly for Perl 6 work atm.
whiteknight right, but not the "I can quit my job now" grants 17:39
cotto_work nope
whiteknight meh, it's a pipedream
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)
Austin That's what I was thinking of. 17:41
The Hague grants. For some reason, I knew it was a city name, but couldn't recall which one.
Well, city reference, anyway. 17:42
Why the hell is it 69 degrees today? 17:45
whiteknight Austin: do you think that's good or bad?
Austin I thought fall was over and winter was upon us?
I think it's terrible.
whiteknight I don't get bothered by the cold so much 17:46
Austin Nor I.
PerlJam Fall doesn't end until Dec.
whiteknight the rain is shitty, but whatevs
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.
It's interfering with my scenery.
bubaflub it's 52 here in the middle of Illinois 17:47
it's also boring here in the middle of IL, but that's a different story
whiteknight I'm more worried about people getting sick. My wife has an immune system like a '63 volkeswagon
Austin I was going to say something about that being its own reward...
whiteknight: Meaning it doesn't work? 17:48
whiteknight exactly
Austin Man, have you been following the news from New Jersey?
bubaflub hmmm, i've had a number of friends come down with the flu
whiteknight not to mention that she's 9 months pregnant. A goddamn biological house of cards
bubaflub yikes. yeah, keep her quarantined
whiteknight Austin: what news from durty jersey?
Austin I live in Burlington County, and the health department has been really aggressive about getting flu shots from the govt.
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:49
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
From all over the state.
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
I'm not a big believer in flu shots
cotto_work plobsing, the nci_ssc test from t/pmc/nci.t fails on the framebuilder branch on x64 with libjit installed and detected
whiteknight cotto_work: yeah, I pointed out that problem last night 17:52
he nopasted a patch somewhere at some point that I have yet to try
cotto_work nopaste.snit.ch/18636 seems to be the one. I'll give it a shot. 17:54
whiteknight w00t
cotto_work still broken 17:56
17:57 payload joined
whiteknight urg 18:00
dalek rrot: r42423 | barney++ | trunk/NEWS:
More news for 1.8.0.
 18:09
NotFound allison: ping 18:14
allison NotFound: pong
NotFound allison: have you seen TT #1262 ? 18:15
allison looking...
NotFound: short and sweet, nice 18:17
NotFound: any test failures?
purl any test failures are a cause for concern, blah blah blah. Plus it might illuminate something you're tracking down.
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?
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:19
NotFound allison: a good question, I was unaware of that posibility. 18:20
allison: The test failure? Just wrong number of arguments.
allison NotFound: ah, yeah
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.
allison NotFound: yes. mainly at the moment, just get it working, and we'll make some fixes to the PIR 'self' syntax later 18:22
NotFound: (like, later we'll have to deal with updating the signature stored in CallSig to match the args it's holding) 18:23
NotFound allison: chromatic mentioned that yesterday, yes. 18:24
allison: so can I commit if the simple fix for the test cases works? 18:25
allison NotFound: yes, it can't break any existing code because the code would have already been broken 18:26
NotFound: bonus points if you can handle the Sub case too
NotFound: (oh, but please double-check that the Sub case isn't working currently, just in case I'm remembering wrong)
NotFound allison: hard to tell, I never tried to set a Sub as vtable override. 18:27
whiteknight NotFound++ 18:28
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...
NotFound Yeah, the pcc refactor has been great :)
whiteknight that reminds me, I'm supposed to be reading up how "self" is done now in IMCC 18:30
allison mentioned it was an ugly hack
18:30 davidfetter joined
whiteknight actually, the code in compilers/imcc/pcc.c:unshift_self() doesn't look so horrible 18:32
I seem to remember it used to be worse
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 nopaste.snit.ch/18639
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
whiteknight when I do foo.'method'(), it calls invoke on foo? 18:34
allison whiteknight: no
when you call foo.bar() it calls invoke on bar
whiteknight okay, I was lead to believe that was the case
allison (if bar is a PMC)
whiteknight okay, so foo.invoke is only called when I do foo()? 18:35
allison aye
or thingy.foo()
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
and, in that second case, would foo.invoke "self" refer to thingy or foo?
allison whiteknight: see my nopaste above, but add a call to add_method on some object
whiteknight ok
allison whiteknight: that has always been the great debate (what should 'self' be when invoking on an Object sub) 18:37
whiteknight: arguably, self shouldn't even exist for foo()
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)
whiteknight methods and vtables
allison aye
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
whiteknight so in foo(), self == currsub == foo
whereas in bar.foo(), self == bar, currsub == foo
allison whiteknight: I'd move away from keywords entirely and go for opcodes for both self and current_sub
NotFound allison: I don't see a Sub object in that nopaste :?
whiteknight I'm in favor of that very much
allison or, param types
NotFound: it's MySub, an object acting as a sub 18:40
whiteknight param types would be nice and relatively easy to implement
allison whiteknight: .param pmc self :object
NotFound allison: ah, I thinked you talked about a subclass of Sub, or something like that.
whiteknight though I worry if we proliferate too many .param flags, we'll slow some things down
allison er, :self
whiteknight and .param pmc this :sub
allison whiteknight: yup, sounds good 18:41
or :current_sub
whiteknight sounds like ammunition for an RFC. I'll hit the list and see how many complaints the HLL devs can come up with :)
allison whiteknight: it certainly complicates the param checking code, but it is just an integer check
whiteknight: thanks
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
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
NotFound allison: that's what the patch makes. 18:44
allison <slaps head> figuring it out about 2 seconds before 18:45
NotFound: okay, so that treads deeper into the debate whiteknight and I just reviewed... 18:46
NotFound: at first glance I though you were handling the case of adding thingy to the argument list for thingy.foo()
NotFound: (that is, adding the invocant)
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:47
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
allison whiteknight: self should always refer to the invocant
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.
Well, in a thing acting as a method, maybe better said.
allison NotFound: will make a new nopaste...
NotFound But in that case... who is 'self' ? 18:50
nopaste "allison" at 77.98.130.30 pasted "Invoking a Method object, for NotFound" (18 lines) at nopaste.snit.ch/18640 18:54
allison NotFound: this one apparently does currently work
NotFound: so need to not break it
NotFound allison: so maybe we must add a test before applying the patch.
allison NotFound: self should always be the invocant (as in the actual invocant argument to a method call)
NotFound: it is confusing in the vtable case 18:56
NotFound In that usage: how can MyMethod.invoke access the MyObject instance?
Austin In that case, what is the method? 18:57
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...
whiteknight email sent. Let the warnocking begin 19:01
bernhard++ 19:02
NotFound With a simple check for self in call_sig[0], all test pass. 19:03
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:05
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 nopaste.snit.ch/18641
allison NotFound: this example works now too
Austin: not sure I understand the question 19:08
Austin: oh, I see, yes, the MyObject instance isn't available in side the body of the 'invoke' sub at all
Austin Allison: In your nopaste, you have 7 my_obj.$P1() as an example call.
I think that's a mistake. 19:09
allison Austin: yes, the $P1 is only executed, it's not available inside (at the moment)
Austin Okay.
allison Austin: I agree it should be accessible, but it shouldn't override 'self' (or we limit ourselves from creating PIR methods)
PIR method object classes, I should say 19:10
whiteknight I like the :current_sub .param flag
I think that's the most straightforward
and :invocant too 19:11
allison whiteknight: me too
NotFound allison: your first example works if I also add a check for current_object being null.
whiteknight because then we can name it whatever the hell we want
.param pmc self :current_sub
allison whiteknight: can we add :invocant now, without interfering with the old self?
whiteknight allison: yes. 19:12
but more importantly, I think we can reimplement the "self" keyword in terms of :invocant for a modest savings
allison NotFound: as in, 'self' is the current sub for a sub call, but the invocant for a method call?
NotFound: the tricky bit would be how to access the current sub from a method call
pmichaud normally the "current sub" is available through the interpreter object, fwiw 19:13
$P0 = getinterp; cursub = $P0['sub']
(unless you're describing something different)
whiteknight pmichaud: so is the current callsig. :current_sub would just be shorthand
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
allison pmichaud: aye 19:14
pmichaud I'm not sure that level of shorthand is needed.
allison NotFound: I'm mainly concerned about the confusion
whiteknight a named lookup isn't going to be nearly as fast as a .param with a flag
pmichaud whiteknight: sure, but how often do we need to look up the current sub?
whiteknight everytime we call VTABLE_invoke, potentially 19:15
again, I think it's analogous to :cal_sig
:call_sig*
pmichaud I'm a bit confused by "everytime we call VTABLE_invoke"
maybe I just understand the use case.
*don't understand
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
pmichaud whiteknight: yes, I got that part.
whiteknight and we're looking to differentiate betwen calls "$P1()" from "foo.$P1()"
allison pmichaud: looking through old tickets. It has to do with "make VTABLE_invoke work"
pmichaud ah, and the second case the problem is that there are two 'selfs' 19:17
there's the invocant foo, and there's the thing being invoked $P1
whiteknight pmichaud: exactly. We need to get references to both objects
plus I think having :current_sub around would make the functional guys happy: easy anonymous self-recursion
NotFound allison: the second nopaste also works
allison NotFound: with your fix? that's good 19:18
dukeleto 'ello
pmichaud I think the name "current_sub" is entirely misleading
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?
pmichaud allison: I don't have a quick answer, alas
from the vtable perspective, 'self' should refer to the thing being invoked
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 nopaste.snit.ch/18642
whiteknight funny: code.google.com/p/go/issues/detail?id=9
allison NotFound: I suggest committing it, mentioning it in the 'experimental' section of DEPRECATED.pod, so we're not tied to keeping it
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
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
allison NotFound: it usually holds the method invocant, the 'object'
barney whiteknight: same thing happened to Kea
allison NotFound: but we're talking about a case that has no invocant
pmichaud i.e., P6 tends to think of obj.$P0(arg) as being the same as $P0(obj, arg)
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
pmichaud to put it another way, my naive approach for writing an invokable method object would be
NotFound Ok
pmichaud .sub :vtable('invoke') 19:23
.param pmc invocant # this is the object on which the method is being invoked
.param pmc arg1
...
.end
Austin whiteknight: Somebody already suggested goatse. :(
pmichaud thus in obj.$P1(arg1) we would see $P1 as 'self', obj as 'invocant', and arg1 as 'arg1'
Austin pmichaud++ 19:24
pmichaud i.e., vtable-ness overrides method-ness
Austin Objectness.
allison pmichaud: and in fact, that may be what we're moving to, but with the invocant param marked with :invocant
pmichaud I'd be okay with that too.
(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
allison self has always been a bit of a weird hack
pmichaud I think self works out quite naturally, fwiw
particle what about .invocant self
whiteknight it works, but not in all corner cases
particle rather than .param pmc foo
pmichaud well, the tricky part with obj.$P1(arg) is that there are in fact *two* operations being performed
particle is it worth a new macro to distinguish invocant from other params? 19:26
pmichaud particle: I think a flag is sufficient
whiteknight particle: I don't think so
flag is more consistent
pmichaud anyway, my vote on the quick poll is that inside of vtable_invoke, 'self' refers to the invoked object, always.
particle .sub :vtable('invocant')
NotFound allison: What section in DEPRECATED.por ? PMCS ?
particle .param string invocant
pmichaud if I want the actual sub, I can use getinterp
particle oops!
whiteknight pmichaud so "foo.bar()", self is foo?
pmichaud whiteknight: no, self is bar 19:27
purl okay, pmichaud.
pmichaud (assuming that bar has a PIR vtable_invoke)
whiteknight pmichaud: I think that's exactly the opposite of what you just said
pmichaud in foo.bar(), foo is definitely _not_ the invoked object
whiteknight "'self' refers to the invoked object, always"
pmichaud the thing being invoked is bar
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
whiteknight I think that's pretty far backwards
particle *not a pmc
whiteknight an object of a method pmc class would have exactly opposite meanings for "self" from what a normal PIR method would have
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()
pmichaud keep in mind that method pmcs can have their own methods as well
allison: I understand the distinction yes. I think the distinction has to be made in vtable invoke versus methodcall semantics
whiteknight but so can the invocant have other methods
"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
whiteknight: in $P0(xyz) --- what is the invocant?
whiteknight none
allison whiteknight: I think this just shows that 'self' is wrong
pmichaud what is the thing that is handling vtable_invoke ?
allison pmichaud: there is no invocant in $P0(xyz)
whiteknight allison: if "self" exists at all (and maybe it shouldn't) it should be consistent
pmichaud let me put it this way, then
in all of the other vtable methods, "SELF" refers to the thing that controls the vtable 19:31
if I have $I0 = $P0
then it's $P0's "get_integer" vtable that controls
whiteknight right, and $P0 is self
pmichaud correct
so if I have $I0 = $P0()
then it's $P0's "invoke" that controls
allison so the confusion is between SELF in C and self in PIR?
pmichaud I don't find it confusing. 19:32
but that's just me
my point is that "self" should be the object that is controlling
whiteknight in PIR VTABLE overrides, self is the same as SELF in C
pmichaud do we agree that in $I0 = $P0() it's $P0's invoke that is in charge?
whiteknight pmichaud: my solution, in the face of this confusion, is to say "self" should disappear
NotFound The ticket to be mentioned in DEPRECATED is TT #103 ?
whiteknight in that case, $P0 is being invoked, but it isnot the invocant
pmichaud whiteknight: fair enough, I have no problem with that 19:33
the same is true for $I0 = obj.$P0() then
allison okay, an "invocant" is always the object on which a method is invoked
pmichaud it's $P0's "invoke" that is in charge. "obj" has absolutely nothing to do with it.
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?
allison I've always read self == invocant, rather than self == SELF
whiteknight if it's the former, fine: we have some fixing to do. If the later, kill it
pmichaud I've already read self == first argument to a method 19:34
*always
whiteknight pmichaud: that's a perl-ism.
pmichaud (because that's the Perl way of thinking of it, yes)
whiteknight hardly suitable for the default behavior of a language-agnostic VM
pmichaud I disagree.
(more)
it just depends on whether you believe methods are first-class objects or not 19:35
and I think that Parrot _has_ to treat methods as first class
and since methods are first class, they have their own notion of 'self' that may be different from whatever invocant they're operating on
allison pmichaud: agreed, this is just a question of what syntax we use to do it
whiteknight how does first-classness have any impact on whether the invocant is passed as a normal argument or not?
pmichaud therefore, in the case of something like 19:36
$I0 = obj.$P0(arg)
where there's no find_method taking place on obj
(which is the other major difference here)
whiteknight obj is the invocant, $P0 is the invoked sub
pmichaud obj isn't the invocant, though. It has absolutely nothing to do with the method invocation
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
pmichaud okay, I'm not familiar with Damian's definition
allison from a Perl 5 perspective it would be "the first argument" 19:38
but more technically "the object in a method call"
pmichaud I'm fine with defining invocant that way
allison (without any consideration for what the method is or how invocation happens)
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
pmichaud even though it looks like one
whiteknight In most languages, trying to call foo.bar() as bar(foo) would be a big error
allison whiteknight: that may be a bit of a rabbit trail
pmichaud whiteknight: I'm not arguing for Perl semantics just to have Perl semantics
allison I have a more practical problem, if a .sub is defined as :vtable :method, what should 'self' be inside it?
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
allison (that is, if we hypothetically decide that 'self' should be SELF)
whiteknight I think Parrot should not impose semantics on the HLLs
19:40 bacek joined
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?
whiteknight: yes, I'm walking through Socratically here 19:41
pmichaud I mean PMC SELF, which also implies to me exactly Damian's invocant
i.e., I don't see a conflict there.
allison more detailed
...
.sub foo :vtable :method...
called $P0.foo() #assume foo is a variable holding a PMC object 19:42
pmichaud (it would have to be)
allison inside the body of 'foo' what is self?
pmichaud I would see 'self' as being foo (more) 19:43
my reasoning is that $P0 has no impact whatsoever on the method being called
except as an argument
allison this isn't a vtable override, this is an ordinary method
pmichaud oh, you meant $P0.'foo' then
allison nope, any method can be called as either a name or an object 19:44
pmichaud no.
allison there's no way for Parrot to know how the method object was defined when it's invoked
pmichaud right
so, detailing further...
dalek rrot: r42424 | NotFound++ | trunk (2 files):
[pcc] experimental object vtable invoke, TT #103, TT #1262
pmichaud .sub 'foo' :vtable :method :subid('xyz') 19:45
...
.end
allison so, you can always pull a method object out of the class object and call it directly
pmichaud .const 'Sub' foo = 'xyz'
like that?
allison and, it acts just like a normal method call
yup
pmichaud and then
$P0.foo(1)
like so?
allison aye
pmichaud in that case, I would see self as $P0 (more)
allison which should have exactly the same behavior as $P0.'foo'(1)
pmichaud because foo is not an object that has a custom VTABLE_invoke 19:46
foo is a Sub
whiteknight that's a very arbitrary decision to make
.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)
whiteknight it's the changing that's infuriating! Inconsistency is bad 19:48
19:48 bubaflub joined
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
dalek TT #1262 closed by NotFound++: Simple patch for the overriding of invoke for objects
pmichaud and that this is a Sub semantic, which other objects and methods would not be constrained to follow
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
Sub PMC does it as well
whiteknight the behavior is completely defined in IMCC
pmichaud incorrect.
whiteknight Subs get their arguments from CallSignature now, which doesn't enforce that
pmichaud okay, then incorrect prior to the pcc refactor.
whiteknight invocants are a distinct object in the CallSignature
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
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
whiteknight allison: right, it's the Pi that makes them distinct. They arne't just another argument
pmichaud and therefore the notion that the first argument becomes 'self' is actually handled in the Sub PMC as well.
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
pmichaud allison: right.
allison: afaik, it does. (thank you :-)
whiteknight IMCC generates the code that does that. Without this incorrectly-generated code, it would still work fine
allison pmichaud: but, should it stop working if $P0 was defined in some other way than as a PIR .sub/.end block?
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
in any case, no code inside Sub PMC has anything to do with any of that
pmichaud meaning if $P0 was some custom PMC with its own vtable invoke?
allison pmichaud: I would argue that it shouldn't stop working, and should always work no matter how the Sub was created
pmichaud: yes
pmichaud I'd say that the self semantic depends on the custom PMC then
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'
allison pmichaud: probably should, but custom PMCs can't control PIR syntax parsing
whiteknight and making that determination means having an invocant be null or not-null
which means not just filling in the invocant with whatever first argument was passed
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
whiteknight mymethod has been incorrectly called as a standalone sub
pmichaud whiteknight: if we follow the Damian definition, 1 is an invocant.
whiteknight then I don't follow that definition
pmichaud I also think that saying that "been incorrectly called as a standalone sub" is Parrot imposing a semantic as well.
allison pmichaud: no, obj would be the first parameter
(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
allison obj->foo(1)
pmichaud whiteknight: it is not.
I can certainly have anonymous subs and methods
and I can certainly invoke methods without having to do a find_method
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?
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?
pmichaud allison: yes, sure.
anyway, here would be my suggestion 19:57
inside of vtable methods, perhaps we need 'vself'
instead of 'self'
the far more common case is non-vtable methods, and so huffmanization would seem to argue that 'self' should be the invocant there
allison as in, something more generic than 'current sub'
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
note that 'current sub' is actually different from vself
with
allison it is if you look it up through the interpreter
pmichaud .sub 'foo' :vtable('invoke')
allison it's the same in the very specific case of .sub invoke :vtable
pmichaud let me be a bit more specific 19:59
.namespace ['MyMethod']
.sub 'foo' :vtable('invoke')
...
.end
whiteknight allison: not in all cases of invoke :vtable
pmichaud $P0 = new ['MyMethod']
obj.$P0()
the thing on which 'invoke' is occuring is $P0
it's an instance of MyMethod
current sub is 'foo'
whiteknight inside foo, obj is self, $P0 is vself
TimToady phone 20:00
pmichaud i.e., vself is not the current self
sorry
vself is not the current sub
the current sub is 'foo', it's the invoke vtable function for objects of type MyMethod
thus I would expect vself to be an instance of MyMethod
and then 'self' can continue to be obj, if you like :-) 20:01
NotFound Maybe we need a invoke_method vtable
whiteknight NotFound: I thought about that several times today
20:02 chromatic joined
NotFound For a now I'll just enjoy the long awaited ability of creating real functors :) 20:03
whiteknight Notfound: we can't now? 20:06
dalek l: 0972202 | fperrad++ | plumage/xml.json:
update plumage with setup.pir (distutils)
NotFound whiteknight: Yes we can
20:09 mikehh joined
dalek rkdown: 8484de1 | fperrad++ | plumage/markdown.json:
update plumage with setup.pir (distutils)
 20:18
bubaflub fperrad: ping 20:21
fperrad pong
bubaflub i was rewriting one of your tests, t/dynpmc/gdbmhash.t in PIR and ran into some snags 20:22
would you mind taking a look at some code and pointing out where my insanity is?
allison NotFound, whiteknight: alternate suggestion 20:23
whiteknight shoot
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
allison and .sub invoke :vtable takes a single argument, the call signature object 20:24
(instead of trying to take all the arguments from the original sub/method call) 20:25
bubaflub fperrad: it's sittin pretty at gist.github.com/232263, any pointers would be appreciated
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
that prevents vtable invoke from getting processed arguments to use
allison it does, but 'invoke' is the metainvoker
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
whiteknight that's true, but plenty of types are going to treat invoke like the main act, not redirecting
allison (just pass along the current args)
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.
whiteknight allison: I won't disagree with that. It's certainly more sane than the current situation
fperrad bubaflub, but digest PMC is mine, I see & test your patch
bubaflub fperrad: cool. the only snafu there was that converting the template to use PIR fails a coding standard 20:29
i think if i take off the "filetype=pir" at the bottom of the template the coding standard will ignore that file
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
allison NotFound: should simplify it, actually
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...
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.
allison NotFound: so, self should always be set to SELF in your patch
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
i.e. it fails because i have flagged that files as PIR and the test i think is trying to compile it
allison NotFound: and we just tell people that the usual interface is to have one param of :call_sig
whiteknight Allison: so VTABLE_invoke override would always be called with signature Pi-> and just unpack the signature itself?
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
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.
Now the pir looks to me exactly as I want.
allison whiteknight: it's only called with a Pi-> signature if it's called as obj.foo()
whiteknight so otherwise it's just "->" 20:34
and how do we determine which is which inside Object.invoke()?
allison whiteknight: well, it's called with whatever was passed into the call
whiteknight ah, I get it. Just reuses the same CallSignature 20:36
fancy
allison: while on that note, what's the signature for a :call_sig arg? "Pc"?
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...)
whiteknight s was slurpy?
(param, but nice to avoid confusion)
no wait, params don't get signatures
whiteknight is confusing himself.
bubaflub fperrad: ok, so that option is out. i totally wasn't thinking about how that code is going to be generated...
allison whiteknight: yup, slurpy 20:38
whiteknight oh wait, it would be :slurpy on the returns side
"results" side
so there is a Ps signature
allison whiteknight: yeah, we use the same flags on both sides
whiteknight right, but you can't have a slurpy arg 20:39
at least, I don't seem to think you can
allison 'c' is taken for constants
whiteknight in a signature?
allison yes, but let's avoid the confusion of a different letter meaning something different on each side
whiteknight I know it's that in an ops signature
allison parse_signature_string
whiteknight damnit 20:40
bacek Good morning
whiteknight "Pr"?
allison whiteknight: it's all unified now :)
whiteknight what's all unified now?
too much stuff needs a'unifyin'
allison the calling conventions, but particularly parsing signature strings
whiteknight okay, right right right
allison "Pg"? 20:41
whiteknight I'm fine with that
allison it's at least close to the beginning of "sig"
whiteknight so Object.invoke() will use "Pg->Pg"?
allison even though s and i are taken
bubaflub particle: ping
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
or, wait
PiPg->Pg
yes
whiteknight we're calling it with a CallSignature "Pg" full of args
the signature lready contains the Pi, so we shouldn't need to send that again
20:43 mikehh joined, donaldh_ joined
allison the Pi is the object the VTABLE function was defined on 20:43
(this is what it's virtual signature is)
whiteknight but Pi is invocant
dalek rrot: r42425 | fperrad++ | trunk/config/gen (2 files):
applied patch from TT#1227 (with improvement)

Courtesy of bubaflub
whiteknight if we want something else for vtable object, I think it should be Pv
allison Parrot_Sub_invoke(PARROT_INTERP, PMC *pmc, void *next)
whiteknight Right, but the Sub there isn't the invocant
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
hoping and praying
allison one is the call signature of "return = obj.foo(arg)"
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
allison there's already this separation in Sub
whiteknight we wouldn't put that signature inside a signature
allison we're trying to provide a way to do the same things from PIR
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
whiteknight set_args simply sets that as the current signature
dalek TT #1227 closed by fperrad++: [PATCH] config/gen/crypto/digest_t.in for generated tests in t/dynpmc 20:48
whiteknight ok
and now why does that change in vtable invoke?
allison yes, for all usual cases, that's how it works
20:48 mikehh joined
allison because vtable invoke is a way to allow people to implement invocation plumbing from PIR 20:48
so, they need access to all the features
whiteknight and the "results = obj.meth(args)" signature doesn't give that to them? 20:49
allison it does, but they lose information
we've been trying to dumb vtable invoke down in PIR
whiteknight ...do they still lose information if they have a :vtable_self .param?
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
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?
and vtable invoke will return a CallSignature with the set results and returns?
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
returning a CallSignature seems the most straightforward
whiteknight in the interests of future-proofing it (think unifying args and returns) I think it should return a signature with returns
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
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
whiteknight: can't do this until after 2.0, and NotFound's patch is the right fix for now
whiteknight okay. I think we could put together a branch to prototype some things now though 20:55
what deprecation needs to happen for this to go in?
just the current behavior of invoke :vtable? 20:58
NotFound invoke uses the siganture provided for the original call.
whiteknight okay
NotFound On returning you just need to put values on it.
And .return already does that. 20:59
allison whiteknight: we would be deprecating direct access to the parameters from the original call
whiteknight gotcha. 21:00
allison that is, an 'invoke' vtable override in PIR would always take a single argument .param pmc call_signature
and always return a single result, a call signature object 21:01
NotFound What? And complicating the more common usage?
allison NotFound: yes
NotFound That's insane.
allison NotFound: it's clean, which is important 21:02
it's also explainable, unlike most of our solutions so far
NotFound You mean the non-solutions?
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?
NotFound If you want a clean and undesrstandable invoke method, just add a vtable invoke_method
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
(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.
allison NotFound: your code works now
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
(specifically, a Sub-like PMC defined in...) 21:06
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?
allison NotFound: the way I originally implemented Object.invoke (which you just fixed) was trying to dumb down invoke
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
NotFound: the idea is that 'invoke' is a dispatcher
that's what it is in the VTABLE
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.
allison we could even add a second string argument, with the name used to invoke the method/sub
that would be really helpful
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
.param pmc sig 21:11
self.'foo'(sig :call_sig)
(or something like that)
NotFound So the simplest and potentially faster case will need to use pir code to access his arguments.
chromatic ... unless you have an easy way to make the VTABLE_invoke macro take varargs in C. 21:12
NotFound Where are C args in that thing? 21:13
dalek rrot: r42426 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] split exe_pbc/installable_pbc
allison NotFound: vtable overrides are overriding a C-level vtable function
NotFound: and usually have exactly the same signature as the C-level function 21:14
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
NotFound: even though the syntax isn't as pretty
21:16 jan joined
NotFound allison: the signature of invoke uses no C args. 21:16
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.
allison NotFound: and the interpreter, and the PMC object (the sub), and a void pointer 21:18
but, we hide the interpreter from vtable overrides (consistently)
and the opcode_t* and void pointer aren't at all useful in PIR
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
NotFound: aye, but we can't even do that with 'invoke' 21:20
dalek rkdown: a6922c6 | fperrad++ | setup.pir:
use installable_pbc instead of exe_pbc
allison NotFound: PIR doesn't have access to opcode pointers, or even an encapsulated way to deal with them
NotFound allison: we are currently doing.
allison NotFound: are currently doing what? (lost the train somewhere) 21:21
NotFound allison: we are passing to the invoke override the arguements from the pir that uses it, same as for any other. 21:22
Ii I override set_string_native I get a string.
If I overrdie invoke and use obj(string), I get a string. 21:23
chromatic If you override it from PIR, but not from C. 21:26
NotFound Of course. 21:28
purl Indubitably.
21:28 bluescreen joined
chromatic In one fell swoop, we can unify the behavior and implementation and interface of the C version and the PIR version. 21:30
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?
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...
chromatic: I can't benchmark against a non exisent thing.
allison NotFound: how about if CallSignature had an "unpack" method? 21:34
($P0, $P1, $S2) = sig."unpack"() 21:35
well, it would probably be named something like "fetch_args"
NotFound allison: even better if parrot does that automatically... as already does.
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
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.
allison but, the one that really convinced me is that the automatic behavior can't be consistent
dalek TT #1264 created by quietfanatic++: Memory leak on sub call
allison 'self' just can't be right when a PIR object sub is acting as a method 21:38
in obj.foo(), self is wrong if it's object and wrong if it's foo
21:39 xenoterracide joined
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.
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
dalek lscript: aaba1f9 | fperrad++ | setup.pir:
use installable_pbc instead of pbc_exe
 21:45
a: bd95266 | fperrad++ | setup.pir:
use installable_pbc instead of exe_pbc
 21:49
Austin_away Do we know if roles work in Parrot? 21:58
Austin Sorry.
Do we know if roles work in Parrot?
moritz perl 6 roles work on top of parrot ;-) 21:59
gues that doesn't really answers your question though
allison Austin: they are function, but not extensively tested 22:00
Austin Thanks.
allison functional
purl i think functional is probably difficult. Might be possible though. or side-effect free
Austin t/pmc/role.t is very short. 22:01
:)
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
do you mean if Base does a role? 22:03
or Base composes Role itself?
Austin "Cheer up," they told me, "things could be worse." And so I cheered up. And sure enough, things got worse.
allison :)
Austin My understanding is that a class "does" a role. 22:04
"A role adds attributes and methods into a class" [pdd15].
allison yes
Austin So if I define a Base class, and mixin Role to it, then Base does Role, yes?
NotFound Austin: mine was, but last time I tried to use does instead of isa people almost killed me X-)
allison but I'm not clear if you're asking about your own role
Austin In particular, the "does" opcode will set its output to non-zero
allison oh, you don't compose in Role, you create an instance of Role 22:05
and compose in the instance
Austin What does that mean?
purl That boy needs therapy.
allison as in $P0 = new ["Role"]
Austin Hmm.
allison to be less confusing
...
22:06 mikehh joined
allison let's say you have a role "stringy" 22:06
it has some methods, like "get_my_string"
Austin okay
So I have a .namespace ['stringy'] with those methods, yet? 22:07
*yes?
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
Austin Sounds good.
purl Sounds good. is there a good way for me to find out when branches are merged, other than read every svn commit?
Austin How do I do that?
allison roles are like classes, their methods live in the role, not in the namespace
Austin Umm.
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.
Okay.
pmichaud purl, forget Sounds good.
purl pmichaud, I didn't have anything matching sounds good
Austin So I have a new [ 'Role' ]
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
yes, you have a new Role
Austin According to role.t, I give it a name in the init pmc.
particle how do i set up irssi for irc.perl.org?
allison and, you add methods and attributes to it
Austin Now I want Base to "does" my Role.
(stringy)
allison yes
Austin So I get my Base class object. And add_role to it?
22:09 Whiteknight joined
allison yes, exactly 22:10
Austin So now Base does stringy.
allison yes
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
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?
allison Austin: it should accept keys
pmichaud (that sounds like the same isa/typeof issues we've talked about in the past, so just curious)
Austin Hmm. Good question, pmichaud.
allison pmichaud: have to check the code 22:13
allison looks
pmichaud anyway, possibly not important to the current discussion.
but I'd certainly expect $P0 = new ['Base']; $I0 = does $P0, ['stringy'] to be true
Austin So if I create a derived class Base -> Derived, what is the status vis-a-vis Derived does stringy ?
pmichaud instances of derived should also be "does stringy" 22:14
Austin The suggestion in pdd15 is that "no."
pmichaud Austin: line no?
Austin =head3 role
pmichaud (or key phrase)
Austin "A role adds attributes and methods intlo a class without inheritance" 22:15
*into
pmichaud ah, there's a different interpretation there
Austin My impression is that you add in the role and it dissolves.
allison pmichaud: it looks like it's currently checking what's composed into the class or role
pmichaud a class with a role composed into it is not a subclass of the role
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
pmichaud: (and there's a good chance that should change)
pmichaud allison: good to know, thanks.
purl good to know, thanks. is there a free version of that I can install (linux or win32) to play with?
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.
At least, I read it that way.
pmichaud Austin: subclasses of the composed class will have all of the methods and attributes of the base class, including those obtained from role
Austin Sure. 22:17
But will they "does stringy" or not?
pmichaud I'm pretty sure they "does stringy".
allison Austin: mostly true, in that you don't keep a search tree of all the parents and traverse them for finding methods
Austin :)
allison Austin: but you do keep an idea of what roles you've composed
NotFound Write a test, and if it fails, TODO it ;)
allison Austin: specifically so you can check "does stringy"
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:18
*has stringy = does stringy 22:19
allison yes
Austin What's the mechanism for composing in a role? 22:20
I think P6object goes hunting for methods and adds them to the child class. Does role composition need that?
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
"vtable function" versus "method"
Austin Okay.
Okay. 22:24
allison so, if you see Methods as a header for vtable functions, it should be changed to "Vtable Functions"
(old documentation, especially before we had an object system, was pretty confused on the naming) 22:25
chromatic Hm, a memory leak in CallSignatureReturns.
dalek rrot: r42427 | chromatic++ | trunk/src/pmc/callsignaturereturns.pmc:
[PMC] Added init() to CallSignatureReturns PMC to set the custom destruction

Wall).		 22:29
cotto_work doesn't pmc2c take care of that? 22:33
chromatic: ^
chromatic If so, I didn't know. 22:34
Certainly the code doesn't behave as if that were the case.
Whiteknight apparently microsoft patented sudi 22:35
sudo
so that makes me happy
allison cotto: pmc2c couldn't know it needed custom destruction, could it?
cotto_work pmc2c really should be smart enough to set those flags when a custom mark/destroy is defined
chromatic Where would pmc2c set those flags?
darbelo cotto_work: It should be. It isn't.
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()?
purl Message for fperrad stored.
chromatic We can handle attrs automatically. That's not the problem.
NotFound cotto_work: I thinked about that in the auto_attrs branch, but decided it was to risky at that moment.
s/to/too
22:38 theory joined
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:39
darbelo cotto_work: You'll need a deprecation notice. 22:40
NotFound cotto_work: I'll better wait until auto_attrs becomes the default.
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.
darbelo no_auto_attrs? I like the idea, but with a better name. 22:42
NotFound darbelo: ideas welcome. 22:43
cotto_work manual_attrs?
darbelo Better than anything I'd come up with. +1
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.
A lot of deprecation points.
darbelo looks up thesaurus in his dictionary.
cotto_work explicit_attrs? 22:45
NotFound I must create a ticket to discuss that plan.
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-- >
NotFound Well, implementing it will be easy, it just needs to do nothing.
darbelo Then what's holding you back?
;)
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.
cotto_work stick_attrs?
;)
NotFound darbelo: thinking about editing and checking perl code makes me feel lazy ;)
chromatic Hm, and there's a memory leak in Context. 22:48
darbelo Stop checking. We'll let you know if you break it.
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.
cotto_work pmc2c-- 22:50
darbelo pmc2c-- indeed.
cotto_work karma pmc2c
purl pmc2c has karma of -9
darbelo -9? pmc2c-- 22:51
pmc2c--
moritz seen Infinoid
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]
cotto_work I'll be very happy the day it dies.
darbelo Preach it! 22:52
chromatic You're going to love this next commit
moritz is there any subsystem that doesn't either need a major rewrite, or die?
cotto_work Oh boy!
diakopter chromatic: you wrote a new pir backend?
darbelo moritz: We have code too scary to rewrite or kill. Does that count? 22:53
NotFound moritz: maybe the Null PMC
chromatic I plugged more of a leak.
cotto_work moritz, anything that's been rewritten in the last year or two.
moritz wonders if that's the case in most larger projects
diakopter to scary to rewrite or kill? sounds like it needs another wrapper layer on top. :) 22:54
too*
darbelo Probably.
diakopter or bottom.
cotto_work chromatic, wow. 22:55
dalek rrot: r42428 | chromatic++ | trunk/src/pmc/context.pmc:
[PMC] Plugged a memory leak in Context's destroy(), where NULLing the Context's

auto-allocated attributes. This fixes at least part of the leak reported by Lewis Wall in TT #1264.
darbelo That can be a lot of leaked memory. 22:57
chromatic Huge. 22:58
darbelo Pity I'm too lazy to get some hard numbers. 22:59
cotto_work chromatic, have you looked for similar bugs? 23:01
chromatic I'm looking now. 23:02
cotto_work PackfileDirectory looks suspicious
afaict the rest are fine, assuming they all use PMC_data(x) 23:03
23:03 payload joined
chromatic PackfileDirectory bothers me, but when I added a custom destroy flag, I saw a lot of invalid free() errors. 23:03
... though that's probably because it doesn't need its own destroy. 23:04
bacek_at_work chromatic, PackfileDirectory.destroy is wrong 23:05
chromatic Looks that way.
NotFound The default packfile destruction and the interpreter destruction are itermixed in a hard to fix way. 23:07
darbelo packfiles look like they could go into the 'ItsABugHunt' wiki page. 23:08
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...
darbelo NotFound: That page is more about the surrounding code than the structures mentioned, FWIW.
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.
bacek_at_work NotFound, I think so. 23:12
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?
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
Austin, somewhere in examples
NotFound bacek_at_work: surely not.
Austin ok, thanks 23:15
bacek_at_work chromatic, no idea. I can't dig into parrot sources now.
NotFound, then we have to add it.
darbelo, nope. It was some old ticket about Packfiles.
darbelo goes ticket digging.
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.
NotFound Doing it with Winxed, BTW ;)
bacek_at_work: ok
bacek_at_work darbelo, TT#504 23:19
Austin, TT#1011 23:20
darbelo bacek++
chromatic Ahhh, this one is subtle. 23:25
... and there it is. 23:26
darbelo shudders every time chromatic says 'subtle' 23:27
japhb "Subtle are the ways of wizards and dragons" ?
darbelo japhb: Exactly, up until the moment they strike you down with lightning or eat you. 23:28
dalek rrot: r42429 | NotFound++ | trunk/src/pmc/packfileannotations.pmc:
[pmc] METHOD type in packfileannotations
diakopter rakudo: tlety 23:29
darn
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.
japhb darbelo, depends on the type of dragon ...
chromatic However, we never free that memory back to a fixed size pool if the Context has no registers.
japhb er, that was to diakopter
darbelo chromatic: Ugh. That has potential be another *big* wad o' leaked memory. 23:32
chromatic It doesn't anymore.
darbelo chromatic++ 23:33
23:33 kid51 joined
dalek rrot: r42430 | chromatic++ | trunk/src/pmc/callsignaturereturns.pmc:
[PMC] Fixed a memory leak in set_integer_native() when switching from a fixed
 23:35
rrot: r42431 | chromatic++ | trunk/src/call/context.c:
[PCC] Fixed a memory leak of register storage for Contexts which need no

even if we didn't need it; that allocation always returns at least one pointer's worth of memory. However, Parrot_pcc_free_registers() skips freeing the register storage back to a fixed-size pool if the Context has no registers. Skipping the allocation avoids this problem. This fixes the final part of the leak reported by Lewis Wall in TT #1264.
TT #1264 closed by chromatic++: Memory leak on sub call 23:37
kudo: 365404e | moritz++ | src/setting/Any-str.pm:
optimize Str.samecase a wee bit
 23:44
kudo: f87efac | moritz++ | src/builtins/any-str.pir:
fix RT #70415, substr() returned a parrot String, not a Str

  jnthn++ for suggesting the correct fix.
cotto_work I love it when people close bugs that quickly. 23:45
chromatic++
23:46 whoppix joined
plobsing hi #parrot 23:48
darbelo hi plobsing
japhb o/ 23:49
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
plobsing seen cotto 23:51
purl cotto was last seen on #parrot 21 hours, 40 minutes and 2 seconds ago, saying: night
plobsing seen cotto_work
purl cotto_work was last seen on #parrot 6 minutes and 36 seconds ago, saying: chromatic++
plobsing cotto_work: you had test failures in libjit_framebuilder? 23:52
cotto_work plobsing, yes 23:54
plobsing what test(s)?
what platform?
cotto_work Ubuntu 9.04 x64 23:55
The nci_ssc test in t/pmc/nci.t
plobsing that gem.
what's the diag?
purl well, the diag is quite clear from test onwards
cotto_work It works fine without libjit but fails with
?
plobsing diagnostic message
purl i guess diagnostic message is explained as "The lexeer counted more opening curly brackes (braces) than closing ones."
cotto_work 65530
that one?
purl rumour has it that one is fairly new
cotto_work purl, go play in traffic 23:56
purl wanders off to dent some cars.
plobsing yes. thats useful
though I thought I nopasted a fix for that
cotto_work Cool. I thought it was just broken noise
nopaste "cotto" at 131.107.0.74 pasted "current diff from libjit branch" (21 lines) at nopaste.snit.ch/18644 23:57
cotto_work That's what I have applied against that branch.
plobsing hmmm... that ought to do it 23:58
it worked on my machine before. retesting...
cotto_work it failed even after a realclean 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!