Parrot 0.9.1 Released | parrot.org/ | 451 RTs left!
Set by moderator on 24 February 2009.
00:09 AndyA joined
rg notfound: i think those extra 16 bytes on 64bit archs really have to go 00:37
i also find that either the spec is unclear as to where the extra alignment is enforced, or it is enforced too much. 00:40
notfound: check_overlap could be simplified if you called it after sorting the directory. 00:54
01:00 bacek joined 01:03 davidfetter joined 01:10 HG` joined 02:10 frodwith joined 02:12 bacek_ joined
dalek rrot: r37142 | Util++ | trunk/docs (21 files):
[docs] Typo corrections
 02:34
02:39 ilia joined 02:41 Tene_ joined
dalek rrot: r37143 | Util++ | failed to fetch changeset:
[compilers] Typo corrections
 03:31
03:35 janus joined 04:07 Andy joined 04:13 bacek joined
dalek rrot: r37144 | Util++ | trunk/config (6 files):
[config] Typo corrections
 04:29
05:01 tetragon joined 06:22 masak joined 07:08 uniejo joined 07:50 mj41 joined 08:05 wayland76 joined
wayland76 Hi all. I'm trying to make an RPM of rakudo, and do it with the parrot and parrot-devel RPMs installed, rather than installing a special version of parrot into rakudo 08:08
It seems there are some files that need to be in the parrot-devel package that are not being included in any package 08:09
For example, the nqp compiler (and maybe it would be a good idea to include the whole "compilers" directory) 08:10
rakudo also seems to need the tools directory
It also seems to want the lib directory, so it can run 08:11
$(PERL) -I$(BUILD_DIR)/lib build/gen_objectref_pmc.pl $(PMC_DIR)/objectref_pmc.template \\
$(PMC_DIR)/objectref.pmc
Thoughts anyone? 08:12
08:15 Tene joined
moritz wayland76: allison put a patch into RT to allow rakudo to build and run against an installed parrot - maybe you can draw inspiration from there (and/or review the patch) 08:18
wayland76 moritz: thanks. I'll start looking for it.
moritz wayland76: rt.perl.org/rt3/Ticket/Display.html?id=63360 08:21
08:22 riffraff joined
wayland76 moritz: Thanks! My RT-fu isn't very good :) 08:26
08:26 Tene_ joined 08:32 Tene joined
wayland76 Looks like I should toss out my stuff :) 08:38
Do people know that if you go to www.parrot.org/download and click "Current Development Release", you get 0.9.0? 08:40
moritz shouldn't that be 0.9.1?
wayland76 Should, yes. Is, no :) 08:41
moritz I'll open a ticket.
wayland76 I think the problem is the www.parrot.org/release/current link points to the wrong place. 08:42
The 0.9.1 release is there if you navigate around the place
moritz yes 08:43
if it happened once, it'll happen again unless we do something about it.
cotto we can at least add it to the release manager's guide 09:09
moritz it can be automated, so it should be. 09:13
either by upload hooks, or by a cron job that checks for svn tags
09:14 gaz joined
dalek rrot: r37145 | fperrad++ | trunk/MANIFEST.generated:
[install] since r37123, pmc_continuation.h needs to be installed, in order to build PMC for language.
 10:01
10:11 alvar joined 10:31 wayland76 joined 11:39 Debolaz joined 11:54 rdice joined 12:07 contingencyplan joined 12:30 justin joined 12:33 rg1 joined
Infinoid moritz: heh. updating the /release/current alias is on my list of website tasks, but I'm not sure how to automate it 12:48
moritz Infinoid: svn ls svn.parrot.org/parrot/tags/ | grep ^RELEASE|sort |tail -n 1 12:49
if a tarball of the corresponding name exists on the server, update the link to point there
Infinoid Yeah. But try telling drupal that. 12:50
moritz uhm.
i'm asking our drupal expert over in #perl6 12:51
Infinoid It'd probably be best if we just dropped a copy of the tarball as a well-known filename (like latest.tar.gz) as part of the release process 12:52
ok
moritz Infinoid: that works for me too 12:53
12:54 ruoso joined
moritz irclog.perlgeek.de/perl6/2009-03-06#i_961341 12:55
Infinoid also, it might be debateable whether we want to include the monthly releases in that download link. 12:56
moritz it doesn't say "latest stable release" 12:57
what are the monthly releases, if not development releases?
man, all this terminology is going to kill us
Infinoid heh. I didn't say I wanted to do the debating :) 12:58
moritz ;-)
Infinoid thanks, anyway a latest/ symlink in ftp sounds reasonable
moritz aye 12:59
13:00 Fayland_logger joined
Infinoid allison: I'm getting "The selected file ParrotInDetail2.pdf can not be attached to this post, because the disk quota of 1 MB has been reached." 13:01
I've uploaded the talks I could, for now. On to old release accouncenemts. 13:02
allison: Nevermind, I found where to bump up the limit, life is good. 13:06
dalek rrot: r37146 | jkeenan++ | trunk/t/pharness/03-handle_long_options.t:
Add tests to cover --archive and --send-to-smolder options.
 13:07
13:08 alvar joined 13:29 bacek joined 13:49 justin joined 13:52 tetragon joined 13:56 gryphon joined
Infinoid ok, there. parrot.org has a better 404 page, /release/current is updated, and /dev/talks is happy. (of course, it doesn't seem to have anything more recent than 2007... but at least it's off the parrotcode.org migration task list.) time for breakfast 14:06
14:18 ron joined 14:36 alvar joined
rg infinoid++ # getting loads of work done even before breakfast 14:39
Infinoid rg: :) It seems like I get most of my work done this time of day. By the time I hit noon, I'm too easily distracted by shiny things 14:41
14:46 frodwith joined
Coke_^_^ Infinoid: "add a trac ticket" should be a hyperlink to trac. 14:57
Coke danke. 14:58
Infinoid I was actually hoping for a "submitting tickets" document that went through the process of creating an account and all of that too, but I hadn't gone and looked for such a document yet 15:00
I was aiming for the knows-nothing-about-parrot-and-isn't-likely-to-put-much-effort-into-finding-out crowd 15:01
15:04 Tene joined
Coke we could make a trac wiki page on "Submitting Tickets" and for now just have it say "click on teh link above, fool!" 15:05
Infinoid that works for me
rg i can tell you one thing from my own experience: if i don't care much about some tool that i found a bug in, making me register to report a ticket will only result in no report for the ticket. 15:07
for the bug i mean.
Infinoid agreed. requiring registration cuts our newbie submissions by 90% (but also cuts the spam, thankfully)
of course, we not only require registration, but also confirmation via the user's inbox. (and wasn't there some confusion in the past about trac not properly telling the user why their unconfirmed account didn't work yet?) 15:08
rg i thought allison disabled the confirmation requirement recently 15:09
Infinoid I wouldn't know, but that would help.
with this stuff in mind, I'm thinking it might be easier to just link them to IRC, its the closest thing to a support forum we have :)
rg that would probably be much better. 15:10
Infinoid anyway, it's a starting point 15:11
it is quite possible to overthink the 404 page :)
rg oh that was in regard to the 404 page? i didn't catch that. 15:12
Infinoid yeah, www.parrot.org/404 15:13
strange that it appears normally there (that's its normal name) yet when it's being delivered as an actual 404 page for some other link, we lose the sidebar with the search form 15:14
otherwise I'd tell them to STFW 15:15
Util purl, seen davidfetter?
purl davidfetter was last seen on #parrot 1 days, 19 hours, 9 minutes and 8 seconds ago, saying: Util, around? [Mar 4 20:06:01 2009]
particle1 confirmation has not been disabled 15:27
there is a bug in trac about poor notification of non-confirmation
that's known by the trac software team
particle1 thinks the parrot logo should link to parrot.org/ 15:29
it doesn't, on docs.parrot.org... there's no clear way to get to the home page 15:30
dalek a: a99b6fb | (Francois Perrad)++ | config/makefiles/root.in:
fix makefile
 15:32
a: 8aad557 | (Francois Perrad)++ | src/pmc/luatable.pmc:
now LuaTable uses ATTR
a: 5917928 | (Francois Perrad)++ | src/pmc/luatable.pmc:
replace PMC_hash by t_val
shorten dalek's url is at xrl.us/beijng
shorten dalek's url is at xrl.us/beijni
dalek's url is at xrl.us/beijnk
dalek a: 34f9a8b | (Francois Perrad)++ | src/pmc/luatable.pmc:
clean up
purl clean up is a breeze
shorten dalek's url is at xrl.us/beijnn
15:43 rakudohudson joined
Coke particle1: that's a pretty easy fix in 'make html', I think. 15:48
Infinoid particle1: I'm going to kick "make html" around a bit in the near future, I'll add that to my list.
particle1 sweet.
15:48 pjcj joined 15:50 zostay joined 16:11 Theory joined 16:24 contingencyplan joined
dalek kudo: f6cdf9b | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 317 files, 7121 passing, 0 failing
 16:42
shorten dalek's url is at xrl.us/beijv7
17:05 justin joined 17:33 barney joined
Coke svn question. if we branch, modify some files, merge from trunk, modify, RENAME THE BRANCH, modify, merge from trunk... should we experience extra difficult merging the renamed branch back to trunk? 17:37
Not entirely hypothetical, but also entirely unrelated to parrot. =-)
rg imho no, but my svn experience is still quite limited. 17:38
Infinoid SHOULD you? no. but you will. 17:45
Coke yah. Thankfully, said branch occurred 99.9% in a single directory. 17:52
so I just did an svn copy and found the one stray commit to keep elsewhere, did the merge as 2 commits.
no clue why the developer decided to renaming the branch (I asked them to rename the one directory they were hacking on, that's it.)
*rename 17:54
Infinoid in svn, there's not much difference between a branch and a directory 17:59
Sounds like you lucked out tho... could have been a lot worse.
PerlJam Infinoid: "not much difference"? you mean "not *any* difference" :-) 18:02
Coke yah. I'd not have expected the conflicts I'm see. I'm sure some other thing is screwed up.
damnit. "I'm seeing". 18:03
I apparently have participle trouble.
our troubling participles.
OR!
Coke takes his fingers out back and shows them what fer.
18:03 rurban joined 18:09 jan joined
Infinoid PerlJam: the only difference I can see is that branches have an svn:mergeinfo attribute and directories don't. But given their overall philosophy, that might be construed as a design issue. 18:09
I suspect when they finally get this stuff right, you'll see svn:mergeinfo in a lot more places 18:10
PerlJam oh, "they" have already got it right ... it's just that "they" are the git-devs ;) 18:11
Infinoid git has a different overall philosophy. svn will do things their own way, stable and slow, but the path they're on will lead to something reliable I think 18:13
The only reason git's gotten this right is because pretty much *everything* is a branch merge for them. :) 18:14
PerlJam Well, IMHO, branching + merging is (and should be) fundamental to a VCS. Those operations should be easy and painless. 18:15
Coke (mergeinfo) note that I'm using svn server of 1.2, I think. 18:16
PerlJam the svn folks coming at the problem from "making a better CVS" haven't quite gotten there yet.
Infinoid Sure they have. It's MUCH better than CVS. :)
PerlJam Coke: that's ooooold. You should upgrade to 1.5 at least.
Coke "not having this conversation again." =-)
PerlJam Coke: That's okay 1.6 is due to arrive soon anyway :) 18:17
Infinoid: Indeed. When I started using svn, I absolutely and completely stopped using CVS.
Infinoid Yep. Night and day. 18:18
Coke double checked; work is using 1.2.1
an upgrade is planned, but this infrastructure is really outside of my control.
rg coke: complain often and loudly. ;) 18:19
PerlJam Coke: svn < 1.5 is just fine for almost anything you want to do as long as you don't mind painful merges :)
(or don't need merges at all)
Infinoid the simplest solution is to keep the branch topology linear by never merging any trunk changes into the branch, ever 18:29
That's pmichaud++'s solution, and it works.
PerlJam Infinoid: If you used svn 1.5, that's essentially what the new merge goodness does (but you can still merge from trunk to branch) 18:32
particle1 yep 18:33
svn1.5++
now if only they supported custom metadata 18:34
Infinoid PerlJam: Yeah. Doesn't seem to handle renames very well though. Still a step in the right direction
particle1 i think svn mv branches/foo branches/bar would work fine
Infinoid Most of the merging issues I've seen with parrot were just a normal file being modified and renamed 18:35
18:35 Psyche^ joined
Infinoid Also, complex merge topologies only work when all of the branches mentioned in svn:mergeinfo still exist 18:36
PerlJam particle1: what sort of "custom metadata support" are you after?
particle1 %Copyright%, %Year%, etc.
Infinoid Ah, that does sound nice
PerlJam Well, you can stick those in svn properties now. 18:37
particle1 it's been requested since 1.1, promised "any day now" since 1.3
PerlJam (and use a similar trick to getting the version in a file to retrieve them)
particle1 you can't expand them in a file 18:38
PerlJam (but, yeah, you'd still need some sort of scripting support to make it work)
Infinoid You can always fix those things up after the fact, I guess. (Kinda like headerizer)
PerlJam Those svn guys may be smarter than we think. They leave stuff out so that whole ecosystems can be created to support the absent features. That way they spread the love of svn support contracts and such rather than hoarding it all for themselves ;) 18:41
Infinoid Nice conspiracy theory :) 18:44
18:53 ruoso joined 18:56 japhb joined
Theory conspires against Infinoid 19:19
Paranoid <.< >.>
ron Is there any kind of architecture for creating/using test built-in (non dynamid) PMCs? 19:26
s/dynamid/dynamic/
Coke architectures? 19:28
s/es/e/ ? 19:29
you mean a tool?
particle1 creating a new core pmc type? sure, create the file, modify the thing in config that specifies that it get built
Coke particle1: I'm not entirely sure step 2 is necessary.
particle1 neither am i, but you'll definitely need to reconfig
ron You might want to create a pmc for testing purposes that isn't need in "production". 19:30
Coke ron: is this something you'd commit to the repo?
just trying to figure out your use case here.
particle1 ron: then you shouldn't compile it into parrot in production :)
ron In src/dynpmc there is foo.pmc 19:31
rg i've been thinking the same thing, but i would have suggested a dynpmc (if i ever got around to building anything ;))
allison ron: yes, that's a dynpmc
Coke we have dynpmcs that should have been deprecated before 1.0, as an aside.
allison: be nice if we could cull those and any experimental ops we don't want to keep. 19:32
allison Coke: also dynops (why do we have dynops named "dan"?
Coke (in fact, experimental.ops should b e empty in 1.0)
particle1 well, if they were moved under examples, that'd be fine with me
Coke allison: for testing. hopefully we're not installing them.
allison Coke: experimental we can remove, they've never been "precated", so don't need to be "deprecated"
Coke particle1: it's ok to build them and test them, I think. 19:33
particle1 some experimental ops are relied upon, iirc
Coke allison: except that experimental.ops really hasn't been treated that way anywhere.
pmichaud lots of ops listed as "experimental" are in fact highly used.
particle1 i think c went through experimental.ops and classified them on the ml
ron I am working on some tests that operate similarly (but not identically) on pmcs and dynpmcs. I will just include the pmcs with the test for the moment.
allison Coke/pmichaud: sure, so the ones that are used and useful should move out of experimental into core or other relevant file 19:34
pmichaud splice, iter, morph, pow_n_n_i, find_sub_not_null
morph might not be used as much any more.
allison experimental is exactly that, a testing ground to decide if something is worth keeping
Coke: though, I'm not keen on making big ops changes before 1.0 at this point just from a stability perspective, would rather make them in 1.1 19:36
Coke: or if we make them, no later than this weekend 19:37
Coke allison: (worth keeping) and now is an excellent time to formulate that decision. 19:38
not as good as last month would have been, sadly, but it didn't float to the top of my brain then.
I'm not suggesting removing anything in experimental.ops, though; just moving them to their permanent homes. 19:39
allison Coke: there's no time like the present :)
Coke then we can add NEW ops into experimental in non-stable releases, making it easier to know which ones are killable before the next stable. 19:40
allison Coke: that should be safe
Coke: we might want a permanent entry in DEPRECATED.pod that simply lists whatever is currently in experimental.ops 19:41
(since we're pointing people there to see what they shouldn't rely on in future releases) 19:42
Coke allison: I'd rather just have it be empty on stable releases.
Infinoid is the stable release the *last* version in a deprecation cycle, or the *first*?
Coke Infinoid: can't parse.
allison Coke: oh, I thought you just said not removing anything from experimental?
Coke what?
allison: for 1.0; I don't want to have to decide what to keep or not at this point. 19:43
I'm assuming that if it's been in there that long, we're using it.
allison Coke: that is, if we're running all the development releases with a set of experimental ops, but don't include them in stable, then our stable release isn't really the same as the development releases (and so, not really tested)
Coke allison: let's remove experimental ops entirely then. 19:44
(the file, not the OPS)
allison Coke: I'm fine with that too
Coke Ok.
allison Coke: there are some ops in experimental that aren't becoming full ops, though
Coke allison: but they weren't deprecated, so they're in 1.0. neh?
allison Coke: some failed experiments 19:45
Coke: well, that's the question. we sure aren't going to move them into core.ops
Infinoid Coke: since the stable releases are the boundary points for deprecation cycles, I was wondering whether we remove a bunch of stuff before those releases, or after.
Coke why not? move them in, add a :deprecated warning, open a ticket, pull them in 1.1
Infinoid: it's all between. =-) 19:46
but, basically, immediately after.
allison Coke: if we do that, let's keep the experimental file. I don't want to put stuff in core that we really don't want people using
Coke allison: ... but it's already IN CORE.
allison Coke: I mean core.ops 19:47
Coke let's try a different tack.
Which opcodes need to be removed?
(then once I have a concrete list, I can worry about moving what's left.) 19:48
allison gcd, exec, maybe classname (wasn't that deprecated?), trap, need_finalize, runinterp 19:49
not sure about substr_r
the implementation of substr_r is "a temporary hack", so I'd be inclined not to promote it out of experimental 19:50
Coke then we should kill it.
adding tickets... 19:51
allison these ops have always been explicitly tagged as "experimental", which means they've always been deprecated 19:52
Coke ... fine. closing tickets. nevermind. 19:53
allison that wasn't against tickets, just a question of timing
Coke I'm just trying to clean up some messes before 1.0. that's all.
allison thinks it's difficult to get tone of voice across in IRC 19:54
Coke: I'm enthusiastically supporting you :) 19:55
(maybe too enthusiastically) 19:56
Coke: do you want to remove experimental.ops before or after 1.0?
Coke allison: Ok. I certainly wasn't getting that impression, you're right. Thanks.
I propose we eliminate experimental.ops before 1.0; I would rather not have anything labeled 'experimental' in the 1.0 release. 19:57
allison Coke: ok, sounds good
Coke: there are some ops we know we want to keep and move to core.ops (or other files)
Coke: what do you want to do with the others (failed experiments)?
Coke allison: I was going to leave them in 1.0 with a deprecation notice. 19:58
and then immediately yank them post release.
I understand you're saying we can avoid that and just yank them now. 19:59
allison Coke: okay, agreed, that's most consistent with our deprecation policy
Coke of course, now I have no actual desire to do any of this. =-)
I'll see if I can get to this weekend; if nothing else, I'll make a ticket. 20:00
allison Coke: bleh, just from this discussion?
Coke allison: the misinterpretation of your sends pretty much killed any enthusiasm I had. Not your fault. 20:01
I'm sure some will return in a day or two.
pmichaud substr_r appears to be heavily used in examples/ , nowhere else that I can see. afaict Rakudo isn't using it.
allison Coke: bummer, sorry
Coke pmichaud: once "make examples_tests" passes again, that might not be true.
Infinoid Hmm. If we deprecate a bunch of stuff immediately after a stable release (as opposed to before), doesn't that result in a worst case support scenario? 20:09
If you want a fix for a "not quite critical enough to issue a minor stable bump release" bug, you can't upgrade to the next monthly without also crossing a deprecation boundary and breaking lots of other stuff.
(sorry about the delay, lots of stuff going on at once here.) 20:10
Coke Infinoid: please clarify deprecate vs. remove.
Infinoid Coke: thanks, you're right that it's all between, but I was curious about the interaction with monthlies
we remove things only on deprecation boundaries. That's why we call them deprecation boundaries. 20:11
Coke Infinoid: the first monthly after a stable could be completely different.
the deprecations must announced in at least one stable before removal. that means as soon as that one stable occurs, all bets are off. 20:12
Infinoid Yeah. I'm just concerned about the interaction between deprecation cycles and support cycles. We've defined a value of "support" that sets a threshold of bugginess, which if exceeded will trigger a new stable bump (like 1.0.1) 20:13
Any bugs below that, and our response is "we've fixed that, upgrade to the latest monthly"
Coke Infinoid: how is 1.0.1 a problem ?
Infinoid: that's the policy, yes.
Infinoid It isn't. But the deprecation cycle occurs at the same time, which means there's guaranteed to be much more work following the above advice
Coke as described by the kind folks at PDS.
Infinoid 1.0.1 isn't a problem, I mean.
Coke Infinoid: so what is the problem them?
then? 20:14
(that is, I'm just parroting the party line here.)
Infinoid The problem is that our answer for not-quite-critical bugs is "we've fixed that, upgrade to the latest monthly", yet doing so means you also have to handle a bunch of deprecated stuff, to cross that line
Coke Infinoid: that only matters if you've already upgraded to a monthly. no? 20:15
Infinoid If we deprecated stuff before the stable releases, that wouldn't be such an issue. Though I guess that would require having 6 month foresight on what to put into DEPRECATED.pod
Coke Infinoid: deprecations only matter on things that have been in a stable release. does that help?
Infinoid: so, let me play this back. 20:16
Infinoid I'm just having trouble getting it straight in my head, I guess
Coke someone has 1.0; we release ... 1.2; it has a lot of bugfixes.
Infinoid it seems like the interaction between the deprecation cycles and the support cycles generates a guaranteed worst-case scenario
Coke someone reports a bug with 1.0 that is fixed in 1.2. we say "you can either upgrade to 1.2 now or 1.4 when it comes out"
in EITHER case, they have to deal with the removal of deprecated items that has occurred since 1.0 20:17
Infinoid even though you're still relying on the 1.0 API, because we've promised to backport the important bugs, for some value of "important"
but the bug in question didn't quite meet that "important" threshold
Coke Infinoid: yes.
Infinoid so either way you've got to cross a deprecation boundary to get the fix
Coke yes.
Infinoid if the actual removals happened between 1.3 and 1.4, that wouldn't be an issue 20:18
but now that I think about it, that causes other issues.
Coke Infinoid: then there would be no releases testing the removal.
Infinoid Yeah. And it requires an unreasonable amount of foresight
Ok. I don't like it much, but the alternative is worse. I think I understand now... Thanks for putting up with me. 20:19
Coke I don't think that in theory our users will like it either. I think in practice it problably won't be so bad.
if we did more incremental releases (like what most people expect a 1.1 to be), then we'd have another problem; we'd have to start a new branch to work on all the 1.4 stuff that we can't put into 1.1 20:20
particle1 in theory, theory and practice are the same.
Infinoid hah
Tene So theoretically that should be true in practice as well. 20:21
Coke so this way, we end up with a more linear release cycle. From a development standpoint, that's better. I think our plan is going to be a tough marketing sell, though.
sorry. s/our/the/ 20:22
caveat: I may still not understand what the hell the plan is. =-)
Infinoid The entire point of calling a release "1.0" is marketing, anyway. But marketing never made much sense to me.
dalek pp: 3a345b6 | (Bernhard Schmalhofer)++ | build/PARROT_REVISION:
Ask for last Parrot version that works for Pipp.
 20:57
shorten dalek's url is at xrl.us/beik54
20:58 particle1 joined 21:10 babygirl24 joined, particle1 joined 21:16 rurban_ joined 21:44 elmex joined 21:51 Rhyolite joined
Rhyolite Hi 21:51
purl salut, Rhyolite.
Rhyolite salut 21:52
21:52 davidfetter joined
Rhyolite does anyone have a moment to answer some basic questions about Parrot memory management? 21:52
Coke I do not, but the list is always a good place to ask such things. 21:53
parrot-dev
purl somebody said parrot-dev was mailto:parrot-dev@lists.parrot.org or lists.parrot.org/mailman/listinfo/parrot-dev
Coke (also, usually easier to throw out a basic starter question rather than ask if you can. =)
... ok, apparently I do have enough time. what's up? =-)
Rhyolite I see the low-level gc stuff 21:56
and resources.c / res_lea.c
I am trying to find where the symbol table accesses objects
is that through what parrot calls vtables? 21:57
Coke I don't follow "symbol table" - doesn't help that I am not a c programmer, I suspect.
Rhyolite I mean the dictionary for accessing global variables 21:58
Coke globals are done via the global ops; the ops definitions call out to various C-level functions to do the heavy lifting.
moment...
particle1 [sg]et_global 21:59
Coke for example: src/ops/var.ops defines "get_global" as:
op get_global(out PMC, in STR) { PMC * const cur_ns = CONTEXT(interp)->current_namespace; $1 = Parrot_find_global_op(interp, cur_ns, $2, expr NEXT());
}
Rhyolite okay, it is in the ops stuff
Coke that's how I'd start looking for it, anyway. 22:00
(but that's because I tend to approach things from the PIR level.)
Rhyolite Yes, I was a little confused by the wrappers in the ops directory 22:01
so it's really Parrot_find_global_op
particle1 make tags-vi can help
Coke Rhyolite: the C-level function that does the work of the get_global op is Parrot_find_global_op, yup.
particle1 if you're a vi user :)
Rhyolite I also assumed that most of this was through PMC 22:02
and started looking in pmc/integer.pmc
and get_integer
etc.
but those accessors did not lead me very far
particle1 globals aren't used much in parrot
Coke Rhyolite: that will help once you /have/ a PMC.
particle1: bite your tongue.
purl NNNF!
particle1 ;) 22:03
Rhyolite particle1: yes, I realize that live values will be loaded into Parrot registers
but whatever language is being fed to the Parrot VM
the global namespace needs to be accessed initially from somewhere 22:04
particle1: or do I completely misunderstand things?
for Parrot's implementation
Coke ah. if you're looking for the root namespace, that's a different op.
get_global gets you something from a slot in the global namespace.
get_root_namespace is the op for ... well, doing that. 22:05
Rhyolite I'm looking for the critical path in Parrot for accessing variables
Coke Rhyolite: Are you trying to solve a particular problem, or just understand parrot?
Rhyolite It's a little more complicated in Parrot because values are cached in registers
Coke cached? 22:06
Rhyolite and then there is the question of mapping Parrot registers to the system on which Parrot is running
sorry, cached is the wrong term
live values are loaded into Parrot registers
I'm not trying to solve a problem or a bug
I'm analyzing various VMs for memory access behavior 22:07
and Parrot is next on my list
at some point there is a name lookup for the program variable in the original program
that Parrot needs to find to extract the actual value 22:08
that's the path I'm trying to understand in Parrot
Coke Rhyolite: it might be instructive to take an actual language like perl6, write some code, and see what the compiler generates.
then you can see what opcodes are used, what PMCs are generated, and follow the code in the opcodes or PMCS or Objects to see what C is getting invoked. 22:09
rakudo-past: "Hello".say();
polyglotbot No output (you need to produce output to STDOUT)
Coke rakudo.past: "Hello".say(); 22:10
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (112 lines) at nopaste.snit.ch/15795
Coke rakudo.pir: "Hello".say();
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 pir" (55 lines) at nopaste.snit.ch/15796
Coke something like that last one. 22:11
Rhyolite ok
Coke ... if I knew the syntax for globals in perl6, I'd just give it to you. =-)
ron If a PMC has an hll modifier, is it reasonable to expect that the PMC's methods be accessible through the namespace specified in the hll modifier rather than the 'parrot' hll namespace? 22:12
particle1 rakudo.pir: $::foo = 1; 22:13
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 pir" (10 lines) at nopaste.snit.ch/15797
particle1 guess i don't know it, either :)
Rhyolite I assumed that I could find the name lookup mechanism in the interpreter without tracing sample code 22:14
tho it looks like global.c:internal_ns_keyed() and related functions may be the place 22:15
pmichaud Rhyolite: maybe I can help a bit. IIUC, namespaces are just PMCs.
they're PMCs with a hash interface.
so, a namespace is just a symbol table
Rhyolite yes
pmichaud mapping (string) keys to PMC objects
Rhyolite it looks like everything comes down to VTABLE_get_<blah> 22:16
pmichaud yes, if I want to look up a symbol in a namespace, that probably goes through the NameSpace PMC's get_pmc_keyed vtable function.
this allows different namespaces to provide different lookup behaviors (e.g., for different HLLs) 22:17
ron: in answer to your question, I suspect that methods should not be accessed via a namespace at all. 22:19
TT #389 has more details about that. 22:20
sjn sigusr2.net/2009/Mar/04/dispatching...-with.html 22:25
how would that be done with perl6? 22:26
s/with/in/ (bad, my english is) 22:27
Rhyolite thanks for the guidance! 22:28
22:29 Rhyolite left
pmichaud sjn: might ask on #perl6 or on perl6-users@perl.org mailing list. 22:30
(I don't know the answer off the top of my head)
ron pmichaud: it sounds to me like you are saying that if I have a method 'printhi' associated with a pmc of class foo which has an hll modifier of (say) dale, then foo.'printhi'() should work regardless of the current hll namespace. Correct? 22:31
pmichaud ron: methods are always looked up via the object, not via a namespace.
so short answer to your question: yes, that should work.
(and assuming that the foo in foo.'printhi'() is an instance of the class and not the PMC class object itself) 22:32
ron I was considering a pmc instance like new ['Integer'] rather than a pmc resulting from a newclass operation in some way - if that makes sense ... 22:36
except here its new ['foo'] 22:37
sjn pmichaud: ook 22:39
Coke $P1 = new ['TclList']; $P1.'reverse'() ?
pmichaud right, so if you did foo = new ['foo'] and then foo.'somemethod'() then it should invoke whatever 'somemethod' method is defined in the foo class. Namespaces don't enter into the picture at all. 22:40
Coke pmichaud: it's possible that method is /defined/ in a namespace somewhere.
pmichaud Now then, when 'somemethod' is invoked, it will run within the namespace in which it was defined, and not in the caller's namespace.
Coke: yes, it's possible for a method to be entered as a symbol in a namespace (and that's Parrot's current erroneous default), but invoking a method doesn't involve the namespace.
Coke pmichaud: I'm still trying to figure out what problem he's trying to fix. 22:41
pmichaud oh, I didn't do that at all. I'm just answering whatever question ron happens to ask. :-)
ron In rt #40438 (again :)) changing the current hll namespace with .HLL changes whether or not you can access a pmc method ... 22:43
pmichaud looking at 40438
interesting. Testing. 22:44
22:56 Whiteknight joined 23:01 ron joined
pmichaud sorry, I got called away. I think the original bug report in #40438 (and the subsequent ones) are bogus. 23:01
23:02 Hinrik left
nopaste "ron" at 168.100.250.30 pasted "Updated 40438 example using Perl6str" (21 lines) at nopaste.snit.ch/15798 23:03
23:03 Limbic_Region joined
pmichaud Except that Perl6Str isn't in the perl6 HLL yet. 23:03
that's what's wrong with the original ticket and the examples -- the PMCs involved are all in the Parrot HLL namespace. 23:04
So no, I wouldn't expect methods from a different HLL namespace to end up as methods in the PMCs
ron perl6str.pmc has a 'hll Perl6' modifier in its pmclass declaration. Does that matter? 23:05
pmichaud Apparently it doesn't (more) 23:06
even with that modifier in place, it looks as though Perl6Str is going into the Parrot HLL namespace. But let me test.
23:06 particle1 joined
davidfetter Util, you rang? 23:06
pmichaud (I'm fairly certain that the PerlString in the original ticket were in the parrot hll) 23:07
Limbic_Region wonders if it is "sometime tonight" yet
pmichaud L_R: sorry, I didn't forget you, but I did get taken away by wife again 23:08
I'll do that as soon as I troubleshoot this issue.
Tene Oh, is this about the rakudo pmc HLL issues? 23:09
ron Your last argument seemed to be that the current hll ns shouldn't matter for method access. The pasted example seems off there. No?
Limbic_Region no worries
pmichaud for method *access*, no. 23:10
called away again for a minute -- brb
ron No the ns shouldn't matter or no the pasted example is no problem ... 23:11
pmichaud back 23:13
when invoking a method, the method is looked up through the object's list of methods. It's not looked up in the namespace.
When installing a method into a object, the namespace matters, yes.
ron But in the pasted example the result of invocation seems to be determined by the current hll namespace. 23:14
if invocation is only determined by the object is that correct behavior? 23:16
pmichaud when I run the code you posted, I get:
pmichaud@orange:~/rakudo$ parrot/parrot y.pir 23:17
fop
Method 'perl6str_printhi' not found for invocant of class 'NewPerlString'
current instr.: 'perl6;Perl6Str;main' pc 30 (y.pir:21)
is that what you're seeing?
ron yes .. did you uncomment the line that says .HLL parrot and see the difference ?
pmichaud weird. (more) 23:19
wait, testing more examples. 23:21
23:23 kid51 joined
nopaste "parrot" at 72.181.176.220 pasted "no HLL needed" (20 lines) at nopaste.snit.ch/15799 23:23
23:24 rurban_ joined
nopaste "pmichaud" at 72.181.176.220 pasted "with .HLL, the Perl6Str method has to be in the parrot namespace when .loadlib is in parrot" (21 lines) at nopaste.snit.ch/15800 23:26
23:27 rurban__ joined
ron do you consider the examples you are pasting OK or a problem? 23:28
nopaste "pmichaud" at 72.181.176.220 pasted "even with .loadlib being done in Perl6 HLL, the Perl6Str method still expects to be in parrot HLL" (23 lines) at nopaste.snit.ch/15801
pmichaud it appears to me as though the "hll Perl6" declaration in the Perl6Str PMC has no direct effect. 23:29
ron So if I rephrased my initial view of the problem as below might you agree? 23:30
Methods for PMCs with an hll modifier may be expected to be installed in the hll namespace in their modifier rather than the 'parrot' hll namespace.
pmichaud I have trouble with the phrase "methods ... installed in a namespace" 23:31
Methods aren't installed in a namespace, they're installed in a class.
we use namespaces as an easy shortcut to indicate the class that a method should be installed in, but the method itself isn't supposed to go into a namespace. 23:32
ron the problem is about * HLL * namespaces though
pmichaud same point, though -- the method goes into the class, not into the namespace.
my phrasing of the problem would be something like: 23:33
PMCs that declare themselves to be in a different HLL namespace are not receiving methods declared in that namespace.
I don't know if the problem exists for only dynpmcs or if it would exist for non-dynpmcs as well. I don't think we have any core PMCs that go into a namespace other than Parrot. 23:34
ron Should such PMCs be receiving methods declared in 'parrot' or other hll namespaces?
pmichaud I would think that a PMC should receive methods only declared in the namespace corresponding to the PMCs declaration. 23:35
so, if the Perl6Str PMC says it's in the
'Perl6' HLL namespace, I would expect its methods to be in .HLL 'perl6' and .namespace ['Perl6Str'] 23:36
I would not expect methods declared in the 'parrot' HLL namespace to be installed in the Perl6Str class.
ron What is the distinction between receive and install ? (going back to my earlier rephrase)
pmichaud the distinction isn't between receive and install; it's in where it's received or installed. Your phrasing says it goes into the namespace; in reality it goes into the class. 23:37
if I do:
.namespace ['XYZClass']
.sub 'xyzmethod' :method
...
.end
Then there should not be any entries in the XYZClass namespace. However, the XYZClass should end up with a method called 'xyzmethod' in it. 23:38
ron thanks for explaining this btw
pmichaud the :method flag means that a sub goes into a class instead of into a namespace. 23:39
ron If I change 'installed' to 'declared' in my phrasing does that help some? 23:40
pmichaud yes, a lot.
the next ambiguity is "may be expected to..."
there shouldn't be any "may" 23:41
ron So maybe: Methods for PMCs with an hll modifier are expected to be declared in the hll namespace in their modifier rather than the 'parrot' hll namespace.
pmichaud for any given PMC, there should be only one location (hll + namespace) in which we would expect to declare its methods.
I see it as two related problems, instead of being a single problem. 23:42
(1) Methods declared in the 'parrot' HLL namespace are being installed in classes declared in other HLL namespaces.
(2) Methods declared in the same non-parrot HLL as a PMC are not being installed in that PMC. 23:43
where we might need to s/classes/PMC/ in #1 above. 23:44
okay, gotta go -- my wife wants me to meet her for dinner. bbl. 23:48
Limbic_Region: (message sent)
23:48 wayland76 joined
ron I am off for a bit too. The explanations have clarified my understanding of the rt some but not that much. Thanks again. 23:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!