Parrot 1.2.0 released | parrot.org/ | 303 RTs left | Weekly Priority: Profiling
Set by moderator on 28 May 2009.
afk_coke chromatic: one thing that might be relevant is that whenever partcl makes a user-defined proc, it's really a subclass of Sub, not Sub. 00:09
chromatic afk_coke, I don't see the same problem in Tcl. It's something specific to Rakudo.
Though there may be a similar leak in Sub invocations.
Coke ah. Well, partcl has plenty of leaks. I can post you the whole valgrind output, not just the excerpt in the ticket if you like. 00:11
dalek rrot: r39348 | allison++ | trunk/docs/pdds/pdd19_pir.pod:
[pdd] Using "flag" to talk about the ':foo' subroutine feature selectors
 00:13
Coke the biggest one is in IMCC. 00:15
Whiteknight allison: ping 00:17
00:21 bacek_ joined
dalek TT #733 created by jkeenan++: Branch cleanup: pdd30install_stage4 00:24
allison Whiteknighe: yes? 00:26
Whiteknight, that is
00:39 Zak joined
Coke sees a big commit from bacek and whips out the test. 00:42
Coke wonders if chromatic's investigation of contexts was not, in fact, inspired by his bug report. 00:45
bacek_ Coke: I've tested tcl before commit. It passed on my box. 00:47
Coke =-)
Coke is just teasin' ya.
bacek_ "test rocks" :) 00:48
Coke FYI, partcl supports 'make TEST_JOBS=3 test"
bacek_ o! Good to know 00:50
00:51 Theory joined
nopaste "coke" at 72.228.52.192 pasted "memory leak in imcc:" (30 lines) at nopaste.snit.ch/16775 00:53
00:56 Limbic_Region joined
dalek TT #734 created by jkeenan++: Branch cleanup: pdd30_install 01:03
Whiteknight allison: Sorry for disappearing. Are you still there? 01:08
allison Whiteknight: yup 01:09
Whiteknight hi. I wanted to run some ideas past you about the io refactors, for sanity
don't want to waste what little time I have chasing bad ideas
allison okay 01:10
Whiteknight you can see some of the changes in the io_rewiring branch, in src/io/api.c
I changed it so the PMC methods call the API functions, not the other way around
and we differentiate PMC types by named roles 01:11
so only PMCs that does "file" can do seek and peek, and tell, for instance
and only PMCs that does "read" can be read from, etc 01:12
allison swapping the methods to call functions makes sense
it's how I had it originally
you should definitely check with jhorwitz to make sure mod_perl still works 01:13
Whiteknight yeah, I've already seen some performance wins doing it that way, but I need to do more comprehensive profiling
allison (mod_perl was the reason I swapped them)
Whiteknight okay, I'll definitely get in touch with him then.
allison it does mean that FileHandle can't be subclassed or polymorphically substituted 01:14
Whiteknight what do you mean? I've kept subclassability in mind
allison but, on the whole I think we can just tell people to use methods on the alternate object instead of opcodes
well, the greatest speed gain is by having the opcodes call the functions directly 01:15
so, no method calls
Whiteknight it should work transparently with subclassed PMCs, but you're right that it probably can't work with polymorphic substitutes
right, methods might be tricky, but the opcodes should Just Work
allison it won't work with subclasses either, if they override any of the methods or vtable functions for different behavior
(which seems like the point of making the subclass) 01:16
Whiteknight but then again, inheriting methods is buggy for all PMC classes, so that's no issue
the IO API functions aren't currently relying on any VTABLEs, only specific ATTRs
allison I'm just saying, we are losing a feature, but I think it's a tolerable loss
Whiteknight so once all the ATTRs are subclasable types, it should work
allison how do the roles enter into it? 01:17
Whiteknight The roles take over where the method calls were allowing polymorphism
so instead of needing a "read" method in order to read, the PMC does the "read" role and can implement it however it needs
allison you're checking the role to see if it's safe to call X on the PMC? 01:18
Whiteknight yes, exactly
allison mmmm... but you're still calling a method
Whiteknight not a method, the "does" VTABLE
I'm absolutely avoiding all PCCINVOKE calls 01:19
allison but, "does" doesn't do anything
it only returns an integer value
so, where does the overridden behavior go?
you can't override a C function 01:20
Whiteknight I've updated all the IO PMCs to check capabilities in does and return 1 or 0
so FileHandle does("file") returns true
and FileHandle.does("read") returns true only if the file is opened in "r" mode
allison mmm... that's not really what roles are for 01:21
Whiteknight it's an early prototype of the idea
allison I mean, a FileHandle can always read 01:22
mugwump I think that depends on whether you consider the mode of a filehandle to be part of its type
allison it has that behavior built into it
so, the "read" role (if there was one) would always be composed into it, whether the read mode was "r" or "w"
Whiteknight The idea obviously needs refinement, I won't deny that.
maybe the world "role" is not one that I should be using for this concept 01:23
allison the general idea of providing an easy way to know what mode the filehandle is in is good
Whiteknight it's like a named capability that's implementation independent
and I couldn't find a VTABLE to use for the purpose that seemed any more appropriate 01:24
allison it's flags & PIO_F_READ 01:25
Whiteknight right
let me look up some links for you
allison mugwump: yes it does depend on that, and no I wouldn't consider its readmode part of the type 01:26
Whiteknight trac.parrot.org/parrot/browser/bra...e.pmc#L101
mugwump I started once on a VFS role using moose types which considered those things part of the type, that's all
Whiteknight that's the does VTABLE in FileHandle that I added, you should see what I'm trying to do, even if I'm not doing it in the rght place
mugwump It had a certain elegance... and a complexity at the same time ;) 01:27
Whiteknight trac.parrot.org/parrot/browser/bra...api.c#L119
That's the Parrot_io_open function, which does a role check to determine behavior
allison Whiteknight: mmm... I see. I was just about to say "this doesn't really solve the polymorphism problem", but it does, at least for a limited pre-defined set of classes 01:29
Whiteknight yeah, it does require that all PMCs be subclasses of a limited set of base types 01:30
so I'm not entirely happy about that restriction
allison the rule of thumb is, the SETATTR calls should never be used outside the .pmc file, or a dedicated supporting .c file
so, they can be used in src/io/filehandle.c
Whiteknight Infinoid suggested that if the PMC was an unknown type we could default back to a PCCINVOKE call 01:31
allison but not in src/io/api.c
Whiteknight and I can't rely on pmc->vtable->base_type == enum_class_FileHandle, because C-based subclasses won't have that relationship
allison so, don't try to 01:32
Whiteknight right, so there aren't a lot of other great options
allison just rip out the polymorphism entirely
the C I/O functions don't have to work with anything other than a FileHandle
Whiteknight whoa there killer, isn't that a little bit overboard?
I mean, I'll be glad to do that if needed, but how are we going to do IO in subclasses without it? 01:33
allison :) like I said, it's a feature loss, but a tolerable one
either we do polymorphism right (with methods), or we don't do it
Whiteknight so get rid of my eggregious abuse of roles, and just use the base_type comparisons? 01:34
allison now, we could take Infinoid's suggestion, but instead of checking a set of types, we just check for FileHandle
that is, if it's a filehandle, we directly manipulate it, otherwise we call the method 01:35
Whiteknight so no subtypes of it at all? subclasses would be forced to delegate?
oh, i see what you're saying
allison but, that might cause some problems internally
Whiteknight I'm happy enough with that, and it provides a good way to optimize IO calls still by avoiding methods in most cases
allison yes, it's the "fast by default, fancy features may slow it down" approach 01:36
and, yes, base_type comparisons will work fine for this (and be very fast) 01:37
Whiteknight okay, thanks for all the input! 01:38
goodnight 01:51
02:02 rhr joined 02:12 Theory joined 02:20 Ademan joined 02:30 darbelo joined
dalek tracwiki: v17 | coke++ | BranchDescriptions 02:38
tracwiki: trac.parrot.org/parrot/wiki/Branch...ction=diff
02:41 payload joined 02:46 Ademan joined 02:48 janus joined 03:20 donaldh joined 03:25 zak_ joined 04:20 tetragon joined 04:24 Zak joined
Coke do parrot namespaces have the concept of "EXPORT_OK" ? 05:05
(or the ability to determine the source location of imported subs?) 05:06
bah. want a macro so I can say import(foo) and have it do .local pmc foo\\nfoo=get_root_global['_tcl'], 'foo' 05:19
dalek rrot: r39349 | coke++ | trunk/docs/pdds/pdd19_pir.pod:
[docs] spelling error.
 05:35
Infinoid OH HAI 05:37
Coke ~~
Infinoid So I'm stuck in Denver. Which means I have a little extra parrot time 05:38
how are things?
Coke partcl's not broken yet. =-)
Infinoid I did a nice big NQP profile (from building rakudo's src/parser/actions.pm) 05:40
bacek_ can help with it. I'm pretty good at breaking stuff 05:41
Infinoid turns out it spends 11% of its time in find_cclass, so I'll see if I can speed that up at all
bacek_ Infinoid: switch to ucs2
Infinoid bacek_: That's in find_cclass itself, not in child functions 05:42
the typetable[] loop iterates around 332 million times
... I think. kcachegrind might be showing me the wrong sourcefile here 05:43
(it says it's just ascii.c)
s/ascii/fixed_8/ 05:44
(inlined)
Coke bacek_: want to fix memory leaks? =-) 05:45
bacek_ Coke: easy. Later. (Not in IMCC :) 05:48
Coke there's plenty.
imcc is just the biggest. 05:49
feather.perl6.nl/~coke/valgrind_expr_t.out
Infinoid bacek_: (regarding packfile PMCs ticket) The ticket just tracks the "packfile pmcs" milestone, which is basically "get the complete pmc interface implemented, adapt everything else in parrot to use it, move the necessary chunks of code out from src/packfile.c into the pmcs themselves, then delete src/packfile.c" I think 06:00
I'll keep ownership of it for now, figure out where we are and then document the remaining steps explicitly 06:01
I already had this laid out in RT, but it collapsed down to one TT when I converted
bacek++ for your great work on the packfile stuff, they're quite a bit nicer than the buggy old readonly things I originally written 06:02
bacek_ Infinoid: (packfiles) ok.
They are actually useable to create PBCs from PIR. So we can reimplement IMCC in NQP 06:03
06:03 Maghnus_ joined
Infinoid That sounds great 06:04
bacek_ (Instead of another bison-based parser :)
Infinoid (is pirc bison-based?)
once the next step of the PBC milestone is defined, I will start working on implementing it if I have time
this week is crazy for me tho, and I'm not sure how much time I'll have 06:05
Infinoid <-- z
06:09 Maghnus_ joined 06:14 snarkyboojum joined 06:15 Zak joined 06:26 Zak joined 06:47 baest joined 07:01 iblechbot joined 07:03 mikehh_ joined 07:20 donaldh joined 07:25 Ademan joined 07:41 mikehh_ joined
cotto bacek_, ping 07:52
bacek_ cotto: pong 07:53
cotto Feel free to take over the vtdumper actions.pm. I've been banging my head against it without getting anywhere long enough. 07:54
bacek_ ok. I tried to merge with current trunk yesterday. EPIC FAIL... 07:55
cotto That's surprising, given how few conflicts there should be. 07:56
dalek rrot: r39350 | cotto++ | branches/pmc_pct/compilers/vtdumper/src/parser/grammar.pg:
[vtdumper] various grammar fixes
cotto The only ones I remember were in the manifest, and that's generated anyway.
I have an actions.pm to go with that grammar, but I suspect that it'll need enough changes that it's easier to start from scratch. 07:57
bacek_ ok, I'll take a look 07:59
cotto Thanks.
08:01 barney joined
cotto This may be useful: 08:03
nopaste "cotto" at 96.26.202.243 pasted "notes on what vtable.tbl is used for" (6 lines) at nopaste.snit.ch/16776
cotto I'm off to bed. night
bacek_ cotto: g'night 08:08
08:16 mikehh_ joined, snarkyboojum joined 08:23 viklund joined 08:42 mikehh_ joined 09:06 masak joined 09:08 bacek joined 09:14 mikehh_ joined 09:49 mikehh_ joined 09:51 Maghnus_ joined
dalek rrot: r39351 | bacek++ | trunk/src/pmc/string.pmc:
[pmc][cage] Fix memory leak in String.set_string_native.

constant pool, not to allocate constant string.		 09:52
bacek Coke: see! see! I've fixed one memory leak :) 09:53
dalek rrot: r39352 | bacek++ | trunk/src/oo.c:
[cage] Remove ARGIN guard for INTVAL arg in get_pmc_proxy.
 09:58
10:00 pjcj_ joined
nopaste "bacek" at 114.73.190.38 pasted "msg Coke Small fix for partcl." (21 lines) at nopaste.snit.ch/16777 10:03
10:18 mikehh joined 10:50 mikehh_ joined
dalek rrot: r39353 | bacek++ | branches/tt452_reduce_mmd:
Removing branch from HEAD. It useless now
 11:20
11:20 donaldh joined
dalek tracwiki: v18 | bacek++ | BranchDescriptions 11:25
tracwiki: Remove tt452_reduce_mmd branch
tracwiki: trac.parrot.org/parrot/wiki/Branch...ction=diff
rblackwe !twitter 110 more registrations needed to tie last years YAPC::NA. Tell others to come to YAPC. #yapc #perl 11:35
oops 11:37
Parrot Virtual Machine Workshop almost full and could use some sponsorship. 11:38
12:01 Whiteknight joined
dalek rrot: r39354 | bacek++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c][cage] Avoid useless call to VTABLE_type.
 12:03
12:09 burmas joined
dalek rrot: r39355 | bacek++ | branches/pmc_i_ops:
Branch to reduce amount of code by reusing i_op from op
 12:13
12:14 burmas joined 12:16 rblackwe joined 12:27 rblackwe joined 12:39 rblackwe joined
Whiteknight irclogs? 12:44
purl i guess irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
13:02 gryphon joined
dalek TT #735 created by gerd++: path fo installed header files 13:05
rtcl: r415 | coke++ | trunk/runtime/builtin/while.pir:
minor code cleanup
 13:17
13:17 snarkyboojum joined
dalek rtcl: r416 | coke++ | trunk/src/grammar/expr/past2pir.tg:
use the canonical case for NaN to future proof this code.
 13:23
bacek Coke: sorry for "nan". I spotted this in your code but forgot to mention in ticket. 13:27
13:33 rblackwe joined
dalek rrot: r39356 | bacek++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] Fallback to MMD even harder from switch-based MULTI optimiser.
 13:34
rrot: r39357 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc] Refactor Integer.add and subtract to use i_add and i_subtract.
rrot: r39358 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc] Integer: implement static function upgrade_self_to_complex.
rrot: r39359 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc] Fix Integer.i_add(Complex).
rrot: r39360 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc] Integer.multiply use i_multiply now.
rrot: r39361 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc] Integer.divide use i_divide
bacek bacek@icering:~/src/parrot$ git diff master --stat 13:38
src/pmc/integer.pmc | 423 ++++++++++-----------------------------------------
1 files changed, 84 insertions(+), 339 deletions(-)
dalek rrot: r39362 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc] Integer.floor_divide use i_floor_divide
rrot: r39363 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc] Integer.modulus use i_modulus.
rrot: r39364 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc] Use MULTI instead of handcrafted switch for is_equal
rrot: r39365 | bacek++ | branches/pmc_i_ops/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] Fallback to MMD even harder from switch-based MULTI optimiser.
rrot: r39366 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc][cage] Use "DEFAULT value" instead of "DEFAULT *value" consistently in Integer.
13:39 skids joined
Whiteknight karma bacek 13:40
purl bacek has karma of 562
bacek oh...
I promise to squash commits next time before dcommit them in svn :) 13:41
Infinoid squashing them to trunk is nice for branch merges, but I don't have a problem with fine-grained commits to branches 13:44
In fact, I prefer them, it makes them easier to review 13:45
bacek Deal :)
13:45 barney joined
dalek rrot: r39367 | bacek++ | branches/pmc_i_ops/src/pmc/integer.pmc:
[pmc][cage] Remove misleading comment in Integer about using *dest.
 13:46
bacek *sigh* If only someone made commit similar to r39367 couple of weeks ago... 13:47
barney bacek++
13:48 whoppix joined
szbalint trust, but verify :) 13:48
bacek this behaviour was even used in some PMCs... 13:49
msg Coke Is it possible to build partcl against non-installed Parrot? It will simplify smoking of my small changes :) 13:51
purl Message for coke stored.
Whiteknight it amazes me that the dest PMC in those VTABLEs would be unue
unused 13:52
bacek this is current semantic... 13:54
13:59 snarkyboojum joined
dalek TT #736 created by hv++: [PATCH] icu-config emits prefix with extra newline 14:01
14:02 gryphon joined
Infinoid (#736) uh, I thought we already fixed that 14:02
bacek ok, almost bed time. 14:13
dalek TT #736 closed by Infinoid++: [PATCH] icu-config emits prefix with extra newline 14:18
tracwiki: v16 | Infinoid++ | NewParrotDeveloperGuide 14:19
tracwiki: Link to parrot.org download page, not parrotcode.org. This page also needs an s/RT/Trac/
tracwiki: trac.parrot.org/parrot/wiki/NewPar...ction=diff
14:31 Steve_H joined 14:39 Austin_Hastings joined 14:43 Theory joined 14:49 barney joined 14:50 Patterner joined
dalek rtcl: r417 | coke++ | trunk/t/cmd_expr (2 files):
Fold cmd_exprOld.t into cmd_expr.t

  - combine some tests into loops
  - avoid duplicating effort with existing tests.
old timings: expr.t: 23.5s, exprOld.t: 112s new timings: expr.t: 25.4s !! Takeaway: partcl(inc parrot)'s combined startup cost is VERY BIG.		 14:52
rrot: r39368 | NotFound++ | trunk/src/pmc/sub.pmc:
[pmc] Sub self assignment protection
 14:59
15:08 ruoso joined 15:20 donaldh joined 15:32 Andy joined 15:46 jan joined
cotto It's so nice how GIMP changes its ui with every release. 15:56
Tene s/changes/improves/ 15:59
dalek kudo: 304ae9b | jnthn++ | t/spectest.data:
Add defer-call.t and defer-next.t to spectest.data.
 16:03
kudo: 11c1c84 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
kudo: e5c8a34 | jnthn++ | (2 files):
Add Temporal.pm to the setting. mberends++
kudo: 12a6019 | jnthn++ | t/spectest.data:
Add temporal.t to spectest.data.
16:22 Steve_H left 16:35 Psyche^ joined 16:39 Hunger joined 16:45 HG` joined
dalek rrot: r39369 | NotFound++ | trunk/src/pmc/stringhandle.pmc:
[cage] cleaning and refactoring, no functional changes
 17:07
kudo: 05a4a1c | jnthn++ | src/parser/actions.pm:
Initial cut of giving methods and submethods a *%_ unless they already have a slurpy hash parameter, to meet Interface Consistency section of S12.
 17:09
kudo: a17b297 | jnthn++ | src/ (2 files):
Refactor BUILD to be more in line with the spec. This should resolve the most common issues people run into.
rtcl: r418 | coke++ | trunk/t/tcl_backslash.t:
Convert test file to tcl instead of perl
 17:10
kudo: 7cfa196 | jnthn++ | t/spectest.data:
Add S12-construction/BUILD.t to spectest.data; we now pass all of it.
 17:14
rtcl: r419 | coke++ | trunk/t/cmd_string (2 files):
merge tests (ICU is now implicitly required for partcl)
 17:15
17:29 darbelo joined
particle 15+42+5 17:30
purl 62
17:43 estrabd joined
dalek TT #715 closed by pmichaud++: [bug] various operations create (incorrect) PMCProxy objects in HLL ... 18:17
rtcl: r420 | coke++ | trunk/ (4 files):
Rename this file;
 18:23
rtcl: r421 | coke++ | trunk/runtime/builtin/expr.pir:
remove unused variables and switch to a .tailcall
rtcl: r422 | coke++ | trunk/runtime/builtin/ (4 files):
minor code cleanups
18:28 japhb joined 18:37 iblechbot joined
dalek rtcl: r423 | coke++ | trunk/runtime/builtin/incr.pir:
remove unneeded clone and .sub invoke to reduce overhead
 18:48
rtcl: r424 | coke++ | trunk/runtime/builtin/set.pir:
big simplification, and uneeded clone removal.
 18:57
19:02 Theory joined 19:11 elmex joined 19:13 Steve_H joined 19:15 Ademan joined
pmichaud cla? 19:20
purl rumour has it cla is Contributor License Agreement or www.perlfoundation.org/contributor_..._agreement or www.parrot.org/foundation/legal or www.parrot.org/files/parrot_cla.pdf
19:21 Austin_Hastings joined 19:29 rblackwe joined
dalek rtcl: r425 | coke++ | trunk/runtime/conversions.pir:
fix .sub parameter syntax

Courtesy bacek++		 19:37
19:47 rblackwe joined 19:48 Theory joined
TimToady phone 19:59
nopaste "coke" at 65.91.151.195 pasted "anyone else think this is leaking? (not on IRC)" (43 lines) at nopaste.snit.ch/16780 20:04
NotFound Coke: Probably the code created by the pir compiler call is never freed. 20:09
20:11 gryphon joined
dalek rkdown: cd19163 | fperrad++ | src/parser/actions.pm:
update actions to use $foo.ast() instead of $($foo)
 20:15
rkdown: 38b5f8f | fperrad++ | src/parser/actions.pm:
clean up actions
20:42 silug joined 20:46 rdice joined 20:50 faloee joined 20:53 gryphon joined
dalek rrot: r39370 | allison++ | branches/pcc_rewiring (12 files):
[pcc_branch] Committing uncommitted changes so others can take a look
 21:06
kudo: 77db80c | tene++ | src/ (2 files):
Fix loading foreign libraries.
 21:28
nopaste "tene" at 65.196.126.11 pasted "pmichaud... am i doing something wrong?" (12 lines) at nopaste.snit.ch/16781 21:36
Tene s/PCT/P6object/ 21:37
pmichaud ummmmmmm 21:38
Tene alternately, can you reproduce?
pmichaud yes, I can reproduce.
I don't know why it fails. 21:39
oh, I know why it fails. The sub gets run twice. 21:40
once for :load, once for :Main
er, :main 21:41
nopaste "tene" at 65.196.126.11 pasted "reproduced without P6object" (8 lines) at nopaste.snit.ch/16782
Tene ah
pmichaud++
21:44 Theory joined, Limbic_Region joined
jonathan Tene: Oh! I was watching for the past on #perl6 ;-) 21:50
pmichaud #perl6 only looks to the future. No past there. 21:51
jonathan *post :-P 21:52
21:52 Theory joined 22:00 bacek joined 22:18 japhb joined 22:23 contingencyplan joined 22:32 rg1 joined
bacek OH HAI 22:37
GeJ G'Day bacek 22:38
bacek GeJ: G'Day
dalek rrot: r39371 | bacek++ | branches/tt24_unicode_numifications (2 files):
[core] Add DEPRECATED handling for non-canonical NaN and Inf.
bacek Looks like it not so DEPRECATED... 22:41
22:44 snarkyboojum joined 22:53 Theory joined
Austin_Hastings Is there anything like a parrot linker? 22:53
dalek rrot: r39372 | bacek++ | branches/tt24_unicode_numifications (2 files):
[core] Add support for Infinity in Str_to_num. Fix comments.
 22:54
cotto Austin_Hastings, you can use ./parrot -o foo.pbc a.pir b.pir c.pir 22:56
Austin_Hastings Yeah, that's what I don't want to do. 22:57
pmichaud used to be a thing called pbc_merge. I never used it because it was so unreliable at the time (several years ago)
Austin_Hastings I found pbc_merge, but docs are a little spotty.
cotto insta-reply
Austin_Hastings wppt
*woot
Okay, new Q: Does the nqp expression PAST::Var.new(...) refer to the "class" PAST::Var or to the "namespace" PAST::Var? 22:58
And,
pmichaud at the moment, NQP thinks of PAST::Var as being the protoobject. 22:59
Austin_Hastings in general, is there an expectation that "class methods" will get a "SELF" type object referring to either the namespace or the class?
pmichaud while PAST::Var::Foo would have PAST::Var as being the namespace containing "Foo"
there's no expectation of a SELF in class methods.
Austin_Hastings Should there be? 23:00
pmichaud In Perl 6, there's a $?CLASS
that is available for all methods.
Austin_Hastings Yeah, but this is #parrot.
:)
pmichaud in NQP we don't implement things until we need them. At present, there's no $?CLASS, if we need one, submit a use case.
Austin_Hastings I'm thinking about inheritance of class methods.
pmichaud for that matter, we don't have class methods in NQP yet either :-P
Austin_Hastings (Or protoobject methods, whatever a protoobject is) 23:01
pmichaud a protoobject is an instance of the class
Austin_Hastings Okay.
pmichaud for example, with PAST::Var.foo(...) "self" is PAST::Var
Austin_Hastings And "typeof self" is ? 23:02
pmichaud do you mean in PIR, or ...?
Austin_Hastings Yeah.
pmichaud currently (and this may change), it's an anonymous class that is a subclass of PAST::Var and P6protoobject
Austin_Hastings Yikes. 23:03
I must have missed that in the code. :(
Or is that some kind of parrot magic?
pmichaud it's P6object magic.
Essentially, a protoobject is just an instance of the class with some extra methods mixed in.
Austin_Hastings Let's back up a little bit, here. 23:04
23:04 skids joined
Austin_Hastings If I say, in PIR, $P0 = get_???_symbol [ 'PAST' ], 'Var' 23:05
what do I get in $P0?
oops. Sorry. s/get_???_symbol/get_hll_global/g 23:06
pmichaud you get the protoobject. 23:07
Austin_Hastings Okay.
And that was set up by the p6meta.new_class call? 23:08
pmichaud Yes.
Austin_Hastings So p6meta creates a class called PAST::Var, and then creates a new instance of that class, and stashes the instance in the PAST::Var global name? 23:09
pmichaud yes.
and the instance is actually got some other stuff in it.
23:10 silug joined
Austin_Hastings So then every "class" X::Y implies a namespace X::Y. And for perl-ish classes, it implies a global symbol hll:X::Y that is a protoobject, not a class. 23:10
pmichaud the namespace is also hll:X::Y, but yes. 23:11
purl okay, pmichaud.
23:12 tetragon joined
Austin_Hastings Okay. 23:12
Now will the protoobject respond to object method requests?
pmichaud Sure.
Austin_Hastings Okay. 23:13
By implication, then, "plain objects" will also have methods like "new" and "init" ?
pmichaud Perl 6 has "class objects", but they tend to be hidden away.
The way that P6object is written, the "plain objects" don't get 'new' and 'init' by default. 23:14
Those are the extra things that get mixed-in to the protoobject.
Austin_Hastings Okay. So the objects are protoobject minus some stuff.
pmichaud er, I should say "composed in" to the protoobject.
I prefer to think of it as the protoobject being plus some stuff.
the protoobject is a normal object, but also has 'new' methods and overrides the meaning of 'defined' 23:15
Austin_Hastings Okay. Where is that happening at object-creation time?
pmichaud (and again, that may change -- the Perl 6 meaning continues to evolve even as we speak, and those will likely be reflected in P6object at some point)
23:17 patspam joined
Austin_Hastings I see PCT::Node having 'init' and 'new' and 'clone', and I don't see any indication that "these are not object methods," so I wonder how they are being stripped off? 23:19
pmichaud They aren't stripped off.
They're just never added.
Here's the sequence:
(1) we create a new PCT::Node class
(2) we then create an anonymous class that has PCT::Node and P6protoobject as parents
(3) the P6protoobject contains the 'new' and othe rmethods 23:20
oh, oh oh oh
my apologies.
Austin_Hastings (1) was in PCT::Node's "onload" sub, right?
pmichaud You're talking specifically about PCT::Node.
I thought you were referring to P6objects in general (there was another conversation about this happening on #perl6, and I got confused).
Austin_Hastings Well, I was assuming that it was a representative example.
pmichaud Let me back up.
It's not representative of P6object, now.
It is representative of Perl 6, however. 23:21
Austin_Hastings Oh. Sorry.
pmichaud The methods that are defined in PCT::Node appear for both the normal objects and the protoobject.
for example, if I have
my $var := PAST::Var.new(...);
then $var.new(...) will also create a new PAST::Var object.
because both PAST::Var and $var are instances of the PAST::Var class. 23:22
Austin_Hastings That makes sense.
pmichaud the same holds for 'init' and 'clone'
and any other methods that we define in the PAST::Var class. The protoobject receives them as well. 23:23
In this case, the protoobject knows that it should accept the class's "new" in preference to its own.
Austin_Hastings The implication is that state-of-the-art P6objects won't define their own "new/init/clone" methods?
pmichaud actually, P6object does expect that many classes will define their own "new" method. 23:24
It simply provides a "new" method on protoobjects that does the right thing for classes that don't.
and that default "new" method does little more than create an instance of the class, iirc. It might also bind attributes, but I don't remember if it does that or not.
The default 'new' method simply creates a new instance of the class. Nothing else. 23:25
PCT::Node overrides that 'new' method to be a little more useful.
Austin_Hastings Okay.
Backing away a little bit, should a PAST generator treat PAST::VAR.new() as a function call with a namespace, or as a method call on an object? 23:27
*VAR=Var
pmichaud it's a method call, because of the dot.
A function call would be PAST::Var::new(....)
Austin_Hastings Alright. 23:28
And in terms of PIR, is PAST::Var::new(proto, arg1, arg2) the same as proto.new(arg1, arg2)?
pmichaud Yes, that's currently the case. 23:29
With a big exception.
So, I'll say "no".
Austin_Hastings But of course :>
pmichaud PAST::Var::new(proto, arg1, arg2) looks up the subroutine called 'new' in the PAST;Var namespace and calls it.
There are two major differences
first, if proto is a subclass of PAST::Var, then proto.new(arg1, arg2) could call the subclass' "new" method instead of the one in PAST::Var 23:30
(i.e., inheritance)
PAST::Var::new(proto, arg1, arg2) would always use the 'new' that is defined in PAST::Var
The other major difference is that at some point methods are not supposed to be automatically entered in the namespace. This is a current parrot bug that should be fixed soon. 23:31
Austin_Hastings Hmm.
pmichaud when that happens, PAST::Var::new might "disappear" and no longer be available as a normal sub. In Perl 6 we would expect "is export" to be placed on the method declaration in order to make it appear.
Austin_Hastings I've already noticed a dearth of introspection stuff. 23:32
pmichaud most of that is because we're still defining the interfaces for introspection.
And P6object, NQP, and PAST tend to work from the "don't add anything until we need it", and "try to match the Perl 6 spec as much as possible".
Introspection in Perl 6 is very underspecified at the moent.
*moment
Austin_Hastings Understood. 23:33
purl Understood. are you on schedule?
Austin_Hastings I'm trying to come up with some sort of #include/import/use mechanism, and poking around was quite unsatisfying.
pmichaud that's what Tene++ and I are working on at the moment.
Austin_Hastings For P6? 23:34
pmichaud We're developing a standard import/use mechanism for Parrot and parrot things that use PCT.
yes, for P6, but it's intended to be cross-hll
so that P6 programs could use Ruby libraries, and the like.
Austin_Hastings FWIW, I'd like to see the various packfile C functions and data rendered visible in PIR. That'd be enough, I think, to start hacking something together. 23:35
pmichaud there's a ticket and milestone to support that. 23:38
trac.parrot.org/parrot/ticket/504 23:39
Austin_Hastings Checking lanes slightly, any pointers on how to go about doing #include?
pmichaud at the moment, not any good ones. That question has come up from time to time and I've basically figured we need a preprocessor (if you're talking about doing #include like a C-style #include)
it doesn't seem to lend itself to a 1-pass-parsing solution.
bacek hey. They are good one!
Austin_Hastings I know I'd have to boink the match object to have a new source, but is that practicable? Or is there another way? 23:40
pmichaud ...boink the match object?
bacek Packfile PMCs allow to pack/unpack PBC from PIR.
pmichaud I'd do a global match for all instances of '^^#include ...' 23:41
then replace each resulting match object with the text of the included file
(the match object tells you the .from/.to locations of the original string)
(so you can do the replacements in the original string)
Austin_Hastings Right. 23:42
pmichaud then once those replacements are done, re-parse that string.
Austin_Hastings Until the hysteresis settles.. 23:43
pmichaud although... it might be possible to do one-pass manipulation of the string using action methods... I hadn't thought about that.
That could be.... very interesting.
Austin_Hastings :)
pmichaud It might be hard to deal with #include ... that is embedded in a comment or something like that, though.
Austin_Hastings That seems a grammar problems. 23:44
*problems=problem.
pmichaud not when the two-pass solution is available, it isn't.
Austin_Hastings Which makes the "action method" approach attractive.
pmichaud I find that more of a characteristic of the language than a deficiency of the grammar.
In other words, C defines itself in terms of a two-pass parser. I'm not sure that the grammar should try to overcome that.
Austin_Hastings Sure. 23:45
But e.g., php doesn't.
pmichaud right, but PHP also doesn't want things like "include" to work even when embedded in comments.
The difference is that in C
/* this is a comment
#include 'foo.c' 23:46
end of comment */
still does the include
(assuming it's at the beginning of the line)
at least, I'm pretty sure that's the case.
But in PHP, include('foo.c') doesn't do the include if it's embedded in a comment.
It just ends up being a runtime-include.
And there, the action method makes more sense.
Thus my comment about it being a characteristic of the language instead of the grammar. 23:47
I have to leave for dinner -- bbl.
Austin_Hastings Actually, no.
/* #include foo */ is a space after preprocessing.
pmichaud even if #include is at the beginning of a line?
Austin_Hastings Regardless. 23:48
Comments are first.
pmichaud okay, so the C pre-process honors comments.
Good, then one-pass is no problem.
Austin_Hastings Yeah, it knows way too much.
Is there a particular action method I should look at for how something like this might be done? 23:49
Anybody already messing around with the source?
pmichaud not that I'm aware of. I might be able to crib together an example later or tomorrow. 23:50
Austin_Hastings If you have the cycles, drop me an email. Otherwise, don't sweat it. I'll get around to it eventually.
Enjoy your dinner. :)
pmichaud I'm definitely short on cycles these days.
Austin_Hastings Good morning, Bacek. 23:53
cotto kisses godaddy goodbye (except without kissing anything) 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!