Camelia, the Perl 6 bug

IRC log for #parrot, 2009-03-06

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:09 AndyA joined #parrot
00:37 rg notfound: i think those extra 16 bytes on 64bit archs really have to go
00:40 rg i also find that either the spec is unclear as to where the extra alignment is enforced, or it is enforced too much.
00:54 rg notfound: check_overlap could be simplified if you called it after sorting the directory.
01:00 bacek joined #parrot
01:03 davidfetter joined #parrot
01:10 HG` joined #parrot
02:10 frodwith joined #parrot
02:12 bacek_ joined #parrot
02:34 dalek parrot: r37142 | Util++ | trunk/docs (21 files):
02:34 dalek parrot: [docs] Typo corrections
02:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37142/
02:39 ilia joined #parrot
02:41 Tene_ joined #parrot
03:31 dalek parrot: r37143 | Util++ | failed to fetch changeset:
03:31 dalek parrot: [compilers] Typo corrections
03:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37143/
03:35 janus joined #parrot
04:07 Andy joined #parrot
04:13 bacek joined #parrot
04:29 dalek parrot: r37144 | Util++ | trunk/config (6 files):
04:29 dalek parrot: [config] Typo corrections
04:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37144/
05:01 tetragon joined #parrot
06:22 masak joined #parrot
07:08 uniejo joined #parrot
07:50 mj41 joined #parrot
08:05 wayland76 joined #parrot
08:08 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:09 wayland76 It seems there are some files that need to be in the parrot-devel package that are not being included in any package
08:10 wayland76 For example, the nqp compiler (and maybe it would be a good idea to include the whole "compilers" directory)
08:10 wayland76 rakudo also seems to need the tools directory
08:11 wayland76 It also seems to want the lib directory, so it can run
08:11 wayland76 $(PERL) -I$(BUILD_DIR)/lib build/gen_objectref_pmc.pl $(PMC_DIR)/objectref_pmc.template \
08:11 wayland76 $(PMC_DIR)/objectref.pmc
08:12 wayland76 Thoughts anyone?
08:15 Tene joined #parrot
08:18 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.
08:21 moritz wayland76: http://rt.perl.org/rt3/Tic​ket/Display.html?id=63360
08:22 riffraff joined #parrot
08:26 wayland76 moritz: Thanks!  My RT-fu isn't very good :)
08:26 Tene_ joined #parrot
08:32 Tene joined #parrot
08:38 wayland76 Looks like I should toss out my stuff :)
08:40 wayland76 Do people know that if you go to http://www.parrot.org/download and click "Current Development Release", you get 0.9.0?
08:40 moritz shouldn't that be 0.9.1?
08:41 wayland76 Should, yes.  Is, no :)
08:41 moritz I'll open a ticket.
08:42 wayland76 I think the problem is the http://www.parrot.org/release/current link points to the wrong place.
08:42 wayland76 The 0.9.1 release is there if you navigate around the place
08:43 moritz yes
08:43 moritz if it happened once, it'll happen again unless we do something about it.
09:09 cotto we can at least add it to the release manager's guide
09:13 moritz it can be automated, so it should be.
09:13 moritz either by upload hooks, or by a cron job that checks for svn tags
09:14 gaz joined #parrot
10:01 dalek parrot: r37145 | fperrad++ | trunk/MANIFEST.generated:
10:01 dalek parrot: [install] since r37123, pmc_continuation.h needs to be installed, in order to build PMC for language.
10:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37145/
10:11 alvar joined #parrot
10:31 wayland76 joined #parrot
11:39 Debolaz joined #parrot
11:54 rdice joined #parrot
12:07 contingencyplan joined #parrot
12:30 justin joined #parrot
12:33 rg1 joined #parrot
12:48 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:49 moritz Infinoid: svn ls https://svn.parrot.org/parrot/tags/ | grep ^RELEASE|sort |tail -n 1
12:49 moritz if a tarball of the corresponding name exists on the server, update the link to point there
12:50 Infinoid Yeah.  But try telling drupal that.
12:50 moritz uhm.
12:51 moritz i'm asking our drupal expert over in #perl6
12:52 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 Infinoid ok
12:53 moritz Infinoid: that works for me too
12:54 ruoso joined #parrot
12:55 moritz http://irclog.perlgeek.de/​perl6/2009-03-06#i_961341
12:56 Infinoid also, it might be debateable whether we want to include the monthly releases in that download link.
12:57 moritz it doesn't say "latest stable release"
12:57 moritz what are the monthly releases, if not development releases?
12:57 moritz man, all this terminology is going to kill us
12:58 Infinoid heh.  I didn't say I wanted to do the debating :)
12:58 moritz ;-)
12:58 Infinoid thanks, anyway a latest/ symlink in ftp sounds reasonable
12:59 moritz aye
13:00 Fayland_logger joined #parrot
13:01 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:02 Infinoid I've uploaded the talks I could, for now.  On to old release accouncenemts.
13:06 Infinoid allison: Nevermind, I found where to bump up the limit, life is good.
13:07 dalek parrot: r37146 | jkeenan++ | trunk/t/pharness/03-handle_long_options.t:
13:07 dalek parrot: Add tests to cover --archive and --send-to-smolder options.
13:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37146/
13:08 alvar joined #parrot
13:29 bacek joined #parrot
13:49 justin joined #parrot
13:52 tetragon joined #parrot
13:56 gryphon joined #parrot
14:06 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:18 ron joined #parrot
14:36 alvar joined #parrot
14:39 rg infinoid++ # getting loads of work done even before breakfast
14:41 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:46 frodwith joined #parrot
14:57 Coke_^_^ Infinoid: "add a trac ticket" should be a hyperlink to trac.
14:58 Coke danke.
15:00 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:01 Infinoid I was aiming for the knows-nothing-about-parrot-and-isn't-lik​ely-to-put-much-effort-into-finding-out crowd
15:04 Tene joined #parrot
15:05 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
15:07 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 rg for the bug i mean.
15:07 Infinoid agreed.  requiring registration cuts our newbie submissions by 90% (but also cuts the spam, thankfully)
15:08 Infinoid 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:09 rg i thought allison disabled the confirmation requirement recently
15:09 Infinoid I wouldn't know, but that would help.
15:09 Infinoid 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 :)
15:10 rg that would probably be much better.
15:11 Infinoid anyway, it's a starting point
15:11 Infinoid it is quite possible to overthink the 404 page :)
15:12 rg oh that was in regard to the 404 page? i didn't catch that.
15:13 Infinoid yeah, http://www.parrot.org/404
15:14 Infinoid 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:15 Infinoid otherwise I'd tell them to STFW
15:15 Util purl, seen davidfetter?
15:15 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]
15:27 particle1 confirmation has not been disabled
15:27 particle1 there is a bug in trac about poor notification of non-confirmation
15:27 particle1 that's known by the trac software team
15:29 * particle1 thinks the parrot logo should link to http://parrot.org/
15:30 particle1 it doesn't, on docs.parrot.org... there's no clear way to get to the home page
15:32 dalek lua: a99b6fb | (Francois Perrad)++ | config/makefiles/root.in:
15:32 dalek lua: fix makefile
15:32 dalek lua: review: http://github.com/fperrad/lua/commit/a9​9b6fb9f76bdb608404749accc812d216013c9b
15:32 dalek lua: 8aad557 | (Francois Perrad)++ | src/pmc/luatable.pmc:
15:32 dalek lua: now LuaTable uses ATTR
15:32 dalek lua: review: http://github.com/fperrad/lua/commit/8a​ad55758ceffbdaddab01ea229e1e7bed7f7f3c
15:32 dalek lua: 5917928 | (Francois Perrad)++ | src/pmc/luatable.pmc:
15:32 dalek lua: replace PMC_hash by t_val
15:32 shorten dalek's url is at http://xrl.us/beijng
15:32 dalek lua: review: http://github.com/fperrad/lua/commit/59​17928f4811f694cdaf7edefa87823cfd4fd1d9
15:32 shorten dalek's url is at http://xrl.us/beijni
15:32 shorten dalek's url is at http://xrl.us/beijnk
15:32 dalek lua: 34f9a8b | (Francois Perrad)++ | src/pmc/luatable.pmc:
15:32 dalek lua: clean up
15:32 purl clean up is a breeze
15:32 dalek lua: review: http://github.com/fperrad/lua/commit/34​f9a8b7897471fb53e08d336b9f0667dcdfcb58
15:32 shorten dalek's url is at http://xrl.us/beijnn
15:43 rakudohudson joined #parrot
15:48 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.
15:48 particle1 sweet.
15:48 pjcj joined #parrot
15:50 zostay joined #parrot
16:11 Theory joined #parrot
16:24 contingencyplan joined #parrot
16:42 dalek rakudo: f6cdf9b | pmichaud++ | docs/spectest-progress.csv:
16:42 dalek rakudo: spectest-progress.csv update: 317 files, 7121 passing, 0 failing
16:42 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​6cdf9bd3af2e27b574a0f1727cfc15fe14e1a08
16:42 shorten dalek's url is at http://xrl.us/beijv7
17:05 justin joined #parrot
17:33 barney joined #parrot
17:37 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 Coke Not entirely hypothetical, but also entirely unrelated to parrot. =-)
17:38 rg imho no, but my svn experience is still quite limited.
17:45 Infinoid SHOULD you?  no.  but you will.
17:52 Coke yah. Thankfully, said branch occurred 99.9% in a single directory.
17:52 Coke so I just did an svn copy and found the one stray commit to keep elsewhere, did the merge as 2 commits.
17:52 Coke 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.)
17:54 Coke *rename
17:59 Infinoid in svn, there's not much difference between a branch and a directory
17:59 Infinoid Sounds like you lucked out tho... could have been a lot worse.
18:02 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.
18:03 Coke damnit. "I'm seeing".
18:03 Coke I apparently have participle trouble.
18:03 Coke our troubling participles.
18:03 Coke OR!
18:03 * Coke takes his fingers out back and shows them what fer.
18:03 rurban joined #parrot
18:09 jan joined #parrot
18:09 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:10 Infinoid I suspect when they finally get this stuff right, you'll see svn:mergeinfo in a lot more places
18:11 PerlJam oh, "they" have already got it right ... it's just that "they" are the git-devs  ;)
18:13 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:14 Infinoid The only reason git's gotten this right is because pretty much *everything* is a branch merge for them. :)
18:15 PerlJam Well, IMHO, branching + merging is (and should be) fundamental to a VCS. Those operations should be easy and painless.
18:16 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.
18:16 Infinoid Sure they have.  It's MUCH better than CVS.  :)
18:16 PerlJam Coke: that's ooooold. You should upgrade to 1.5 at least.
18:16 Coke "not having this conversation again." =-)
18:17 PerlJam Coke: That's okay 1.6 is due to arrive soon anyway  :)
18:17 PerlJam Infinoid: Indeed. When I started using svn, I absolutely and completely stopped using CVS.
18:18 Infinoid Yep.  Night and day.
18:18 Coke double checked; work is using 1.2.1
18:18 Coke an upgrade is planned, but this infrastructure is really outside of my control.
18:19 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  :)
18:19 PerlJam (or don't need merges at all)
18:29 Infinoid the simplest solution is to keep the branch topology linear by never merging any trunk changes into the branch, ever
18:29 Infinoid That's pmichaud++'s solution, and it works.
18:32 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:33 particle1 yep
18:33 particle1 svn1.5++
18:34 particle1 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
18:34 particle1 i think svn mv branches/foo branches/bar would work fine
18:35 Infinoid Most of the merging issues I've seen with parrot were just a normal file being modified and renamed
18:35 Psyche^ joined #parrot
18:36 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?
18:36 particle1 %Copyright%, %Year%, etc.
18:36 Infinoid Ah, that does sound nice
18:37 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
18:37 PerlJam (and use a similar trick to getting the version in a file to retrieve them)
18:38 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)
18:38 Infinoid You can always fix those things up after the fact, I guess.  (Kinda like headerizer)
18:41 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:44 Infinoid Nice conspiracy theory :)
18:53 ruoso joined #parrot
18:56 japhb joined #parrot
19:19 * Theory conspires against Infinoid
19:19 Paranoid <.< >.>
19:26 ron Is there any kind of architecture for creating/using test built-in (non dynamid) PMCs?
19:26 ron s/dynamid/dynamic/
19:28 Coke architectures?
19:29 Coke s/es/e/ ?
19:29 Coke you mean a tool?
19:29 particle1 creating a new core pmc type? sure, create the file, modify the thing in config that specifies that it get built
19:29 Coke particle1: I'm not entirely sure step 2 is necessary.
19:29 particle1 neither am i, but you'll definitely need to reconfig
19:30 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?
19:30 Coke just trying to figure out your use case here.
19:30 particle1 ron: then you shouldn't compile it into parrot in production :)
19:31 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 ;))
19:31 allison ron: yes, that's a dynpmc
19:31 Coke we have dynpmcs that should have been deprecated before 1.0, as an aside.
19:32 Coke 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"?
19:32 Coke (in fact, experimental.ops should b e empty in 1.0)
19:32 particle1 well, if they were moved under examples, that'd be fine with me
19:32 Coke allison: for testing. hopefully we're not installing them.
19:32 allison Coke: experimental we can remove, they've never been "precated", so don't need to be "deprecated"
19:33 Coke particle1: it's ok to build them and test them, I think.
19:33 particle1 some experimental ops are relied upon, iirc
19:33 Coke allison: except that experimental.ops really hasn't been treated that way anywhere.
19:33 pmichaud lots of ops listed as "experimental" are in fact highly used.
19:33 particle1 i think c went through experimental.ops and classified them on the ml
19:33 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.
19:34 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
19:34 pmichaud morph might not be used as much any more.
19:34 allison experimental is exactly that, a testing ground to decide if something is worth keeping
19:36 allison 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:37 allison Coke: or if we make them, no later than this weekend
19:38 Coke allison: (worth keeping) and now is an excellent time to formulate that decision.
19:38 Coke not as good as last month would have been, sadly, but it didn't float to the top of my brain then.
19:39 Coke 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 :)
19:40 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
19:41 allison Coke: we might want a permanent entry in DEPRECATED.pod that simply lists whatever is currently in experimental.ops
19:42 allison (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.
19:42 Infinoid is the stable release the *last* version in a deprecation cycle, or the *first*?
19:42 Coke Infinoid: can't parse.
19:42 allison Coke: oh, I thought you just said not removing anything from experimental?
19:42 Coke what?
19:43 Coke allison: for 1.0; I don't want to have to decide what to keep or not at this point.
19:43 Coke I'm assuming that if it's been in there that long, we're using it.
19:43 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)
19:44 Coke allison: let's remove experimental ops entirely then.
19:44 Coke (the file, not the OPS)
19:44 allison Coke: I'm fine with that too
19:44 Coke Ok.
19:44 allison Coke: there are some ops in experimental that aren't becoming full ops, though
19:44 Coke allison: but they weren't deprecated, so they're in 1.0. neh?
19:45 allison Coke: some failed experiments
19:45 allison Coke: well, that's the question. we sure aren't going to move them into core.ops
19:45 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.
19:45 Coke why not? move them in, add a :deprecated warning, open a ticket, pull them in 1.1
19:46 Coke Infinoid: it's all between. =-)
19:46 Coke but, basically, immediately after.
19:46 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
19:46 Coke allison: ... but it's already IN CORE.
19:47 allison Coke: I mean core.ops
19:47 Coke let's try a different tack.
19:47 Coke Which opcodes need to be removed?
19:48 Coke (then once I have a concrete list, I can worry about moving what's left.)
19:49 allison gcd, exec, maybe classname (wasn't that deprecated?), trap, need_finalize, runinterp
19:49 allison not sure about substr_r
19:50 allison 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.
19:51 Coke adding tickets...
19:52 allison these ops have always been explicitly tagged as "experimental", which means they've always been deprecated
19:53 Coke ... fine. closing tickets. nevermind.
19:53 allison that wasn't against tickets, just a question of timing
19:53 Coke I'm just trying to clean up some messes before 1.0. that's all.
19:54 * allison thinks it's difficult to get tone of voice across in IRC
19:55 allison Coke: I'm enthusiastically supporting you :)
19:56 allison (maybe too enthusiastically)
19:56 allison Coke: do you want to remove experimental.ops before or after 1.0?
19:56 Coke allison: Ok. I certainly wasn't getting that impression, you're right. Thanks.
19:57 Coke 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
19:57 allison Coke: there are some ops we know we want to keep and move to core.ops (or other files)
19:57 allison Coke: what do you want to do with the others (failed experiments)?
19:58 Coke allison: I was going to leave them in 1.0 with a deprecation notice.
19:58 Coke and then immediately yank them post release.
19:59 Coke 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
19:59 Coke of course, now I have no actual desire to do any of this. =-)
20:00 Coke 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?
20:01 Coke allison: the misinterpretation of your sends pretty much killed any enthusiasm I had. Not your fault.
20:01 Coke I'm sure some will return in a day or two.
20:01 pmichaud substr_r appears to be heavily used in examples/ , nowhere else that I can see.  afaict Rakudo isn't using it.
20:01 allison Coke: bummer, sorry
20:01 Coke pmichaud: once "make examples_tests" passes again, that might not be true.
20:09 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 Infinoid 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.
20:10 Infinoid (sorry about the delay, lots of stuff going on at once here.)
20:10 Coke Infinoid: please clarify deprecate vs. remove.
20:10 Infinoid Coke: thanks, you're right that it's all between, but I was curious about the interaction with monthlies
20:11 Infinoid 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.
20:12 Coke 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:13 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 Infinoid Any bugs below that, and our response is "we've fixed that, upgrade to the latest monthly"
20:13 Coke Infinoid: how is 1.0.1 a problem ?
20:13 Coke Infinoid: that's the policy, yes.
20:13 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
20:13 Coke as described by the kind folks at PDS.
20:13 Infinoid 1.0.1 isn't a problem, I mean.
20:13 Coke Infinoid: so what is the problem them?
20:14 Coke then?
20:14 Coke (that is, I'm just parroting the party line here.)
20:14 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
20:15 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
20:15 Coke Infinoid: deprecations only matter on things that have been in a stable release. does that help?
20:16 Coke Infinoid: so, let me play this back.
20:16 Infinoid I'm just having trouble getting it straight in my head, I guess
20:16 Coke someone has 1.0; we release ... 1.2; it has a lot of bugfixes.
20:16 Infinoid it seems like the interaction between the deprecation cycles and the support cycles generates a guaranteed worst-case scenario
20:16 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"
20:17 Coke 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"
20:17 Infinoid but the bug in question didn't quite meet that "important" threshold
20:17 Coke Infinoid: yes.
20:17 Infinoid so either way you've got to cross a deprecation boundary to get the fix
20:17 Coke yes.
20:18 Infinoid if the actual removals happened between 1.3 and 1.4, that wouldn't be an issue
20:18 Infinoid but now that I think about it, that causes other issues.
20:18 Coke Infinoid: then there would be no releases testing the removal.
20:18 Infinoid Yeah.  And it requires an unreasonable amount of foresight
20:19 Infinoid 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.
20:20 Coke 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.
20:20 Infinoid hah
20:21 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.
20:22 Coke sorry. s/our/the/
20:22 Coke caveat: I may still not understand what the hell the plan is. =-)
20:22 Infinoid The entire point of calling a release "1.0" is marketing, anyway.  But marketing never made much sense to me.
20:57 dalek pipp: 3a345b6 | (Bernhard Schmalhofer)++ | build/PARROT_REVISION:
20:57 dalek pipp: Ask for last Parrot version that works for Pipp.
20:57 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/3a345b61a4e64c240776212abfc204ad819f495f
20:57 shorten dalek's url is at http://xrl.us/beik54
20:58 particle1 joined #parrot
21:10 babygirl24 joined #parrot
21:10 particle1 joined #parrot
21:16 rurban_ joined #parrot
21:44 elmex joined #parrot
21:51 Rhyolite joined #parrot
21:51 Rhyolite Hi
21:51 purl salut, Rhyolite.
21:52 Rhyolite salut
21:52 davidfetter joined #parrot
21:52 Rhyolite does anyone have a moment to answer some basic questions about Parrot memory management?
21:53 Coke I do not, but the list is always a good place to ask such things.
21:53 Coke parrot-dev
21:53 purl somebody said parrot-dev was mailto:parrot-dev@lists.parrot.org or http://lists.parrot.org/ma​ilman/listinfo/parrot-dev
21:53 Coke (also, usually easier to throw out a basic starter question rather than ask if you can. =)
21:53 Coke ... ok, apparently I do have enough time. what's up? =-)
21:56 Rhyolite I see the low-level gc stuff
21:56 Rhyolite and resources.c / res_lea.c
21:56 Rhyolite I am trying to find where the symbol table accesses objects
21:57 Rhyolite 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.
21:58 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.
21:58 Coke moment...
21:59 particle1 [sg]et_global
21:59 Coke for example: src/ops/var.ops defines "get_global" as:
21:59 Coke 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());
21:59 Coke }
21:59 Rhyolite okay, it is in the ops stuff
22:00 Coke that's how I'd start looking for it, anyway.
22:00 Coke (but that's because I tend to approach things from the PIR level.)
22:01 Rhyolite Yes, I was a little confused by the wrappers in the ops directory
22:01 Rhyolite so it's really Parrot_find_global_op
22:01 particle1 make tags-vi can help
22:01 Coke Rhyolite: the C-level function that does the work of the get_global op is Parrot_find_global_op, yup.
22:01 particle1 if you're a vi user :)
22:02 Rhyolite I also assumed that most of this was through PMC
22:02 Rhyolite and started looking in pmc/integer.pmc
22:02 Rhyolite and get_integer
22:02 Rhyolite etc.
22:02 Rhyolite but those accessors did not lead me very far
22:02 particle1 globals aren't used much in parrot
22:02 Coke Rhyolite: that will help once you /have/ a PMC.
22:02 Coke particle1: bite your tongue.
22:02 purl NNNF!
22:03 particle1 ;)
22:03 Rhyolite particle1: yes, I realize that live values will be loaded into Parrot registers
22:03 Rhyolite but whatever language is being fed to the Parrot VM
22:04 Rhyolite the global namespace needs to be accessed initially from somewhere
22:04 Rhyolite particle1: or do I completely misunderstand things?
22:04 Rhyolite for Parrot's implementation
22:04 Coke ah. if you're looking for the root namespace, that's a different op.
22:04 Coke get_global gets you something from a slot in the global namespace.
22:05 Coke 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
22:05 Coke Rhyolite: Are you trying to solve a particular problem, or just understand parrot?
22:05 Rhyolite It's a little more complicated in Parrot because values are cached in registers
22:06 Coke cached?
22:06 Rhyolite and then there is the question of mapping Parrot registers to the system on which Parrot is running
22:06 Rhyolite sorry, cached is the wrong term
22:06 Rhyolite live values are loaded into Parrot registers
22:06 Rhyolite I'm not trying to solve a problem or a bug
22:07 Rhyolite I'm analyzing various VMs for memory access behavior
22:07 Rhyolite and Parrot is next on my list
22:07 Rhyolite at some point there is a name lookup for the program variable in the original program
22:08 Rhyolite that Parrot needs to find to extract the actual value
22:08 Rhyolite that's the path I'm trying to understand in Parrot
22:08 Coke Rhyolite: it might be instructive to take an actual language like perl6, write some code, and see what the compiler generates.
22:09 Coke 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 Coke rakudo-past: "Hello".say();
22:09 polyglotbot No output (you need to produce output to STDOUT)
22:10 Coke rakudo.past: "Hello".say();
22:10 nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (112 lines) at http://nopaste.snit.ch/15795
22:10 Coke rakudo.pir: "Hello".say();
22:10 nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 pir" (55 lines) at http://nopaste.snit.ch/15796
22:11 Coke something like that last one.
22:11 Rhyolite ok
22:11 Coke ... if I knew the syntax for globals in perl6, I'd just give it to you. =-)
22:12 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:13 particle1 rakudo.pir: $::foo = 1;
22:13 nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 pir" (10 lines) at http://nopaste.snit.ch/15797
22:13 particle1 guess i don't know it, either :)
22:14 Rhyolite I assumed that I could find the name lookup mechanism in the interpreter without tracing sample code
22:15 Rhyolite 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.
22:15 pmichaud they're PMCs with a hash interface.
22:15 pmichaud so, a namespace is just a symbol table
22:15 Rhyolite yes
22:15 pmichaud mapping (string) keys to PMC objects
22:16 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.
22:17 pmichaud this allows different namespaces to provide different lookup behaviors (e.g., for different HLLs)
22:19 pmichaud ron:  in answer to your question, I suspect that methods should not be accessed via a namespace at all.
22:20 pmichaud TT #389 has more details about that.
22:25 sjn http://sigusr2.net/2009/Mar/0​4/dispatching-with-with.html
22:26 sjn how would that be done with perl6?
22:27 sjn s/with/in/ (bad, my english is)
22:28 Rhyolite thanks for the guidance!
22:29 Rhyolite left #parrot
22:30 pmichaud sjn:  might ask on #perl6 or on perl6-users@perl.org mailing list.
22:30 pmichaud (I don't know the answer off the top of my head)
22:31 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.
22:31 pmichaud so short answer to your question:  yes, that should work.
22:32 pmichaud (and assuming that the foo in foo.'printhi'() is an instance of the class and not the PMC class object itself)
22:36 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:37 ron except here its new ['foo']
22:39 sjn pmichaud: ook
22:39 Coke $P1 = new ['TclList']; $P1.'reverse'() ?
22:40 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.
22:40 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.
22:40 pmichaud 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.
22:41 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.  :-)
22:43 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
22:44 pmichaud interesting.  Testing.
22:56 Whiteknight joined #parrot
23:01 ron joined #parrot
23:01 pmichaud sorry, I got called away.  I think the original bug report in #40438 (and the subsequent ones) are bogus.
23:02 Hinrik left #parrot
23:03 nopaste "ron" at 168.100.250.30 pasted "Updated 40438 example using Perl6str" (21 lines) at http://nopaste.snit.ch/15798
23:03 Limbic_Region joined #parrot
23:03 pmichaud Except that Perl6Str isn't in the perl6 HLL yet.
23:04 pmichaud that's what's wrong with the original ticket and the examples -- the PMCs involved are all in the Parrot HLL namespace.
23:04 pmichaud So no, I wouldn't expect methods from a different HLL namespace to end up as methods in the PMCs
23:05 ron perl6str.pmc has a 'hll Perl6' modifier in its pmclass declaration.  Does that matter?
23:06 pmichaud Apparently it doesn't (more)
23:06 pmichaud 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 #parrot
23:06 davidfetter Util, you rang?
23:07 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
23:08 pmichaud L_R:  sorry, I didn't forget you, but I did get taken away by wife again
23:08 pmichaud I'll do that as soon as I troubleshoot this issue.
23:09 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?
23:09 Limbic_Region no worries
23:10 pmichaud for method *access*, no.
23:10 pmichaud called away again for a minute -- brb
23:11 ron No the ns shouldn't matter or no the pasted example is no problem ...
23:13 pmichaud back
23:13 pmichaud when invoking a method, the method is looked up through the object's list of methods.  It's not looked up in the namespace.
23:13 pmichaud When installing a method into a object, the namespace matters, yes.
23:14 ron But in the pasted example the result of invocation seems to be determined by the current hll namespace.
23:16 ron if invocation is only determined by the object is that correct behavior?
23:16 pmichaud when I run the code you posted, I get:
23:17 pmichaud pmichaud@orange:~/rakudo$ parrot/parrot y.pir
23:17 pmichaud fop
23:17 pmichaud Method 'perl6str_printhi' not found for invocant of class 'NewPerlString'
23:17 pmichaud current instr.: 'perl6;Perl6Str;main' pc 30 (y.pir:21)
23:17 pmichaud is that what you're seeing?
23:17 ron yes .. did you uncomment the line that says .HLL parrot and  see the difference ?
23:19 pmichaud weird. (more)
23:21 pmichaud wait, testing more examples.
23:23 kid51 joined #parrot
23:23 nopaste "parrot" at 72.181.176.220 pasted "no HLL needed" (20 lines) at http://nopaste.snit.ch/15799
23:24 rurban_ joined #parrot
23:26 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 http://nopaste.snit.ch/15800
23:27 rurban__ joined #parrot
23:28 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 http://nopaste.snit.ch/15801
23:29 pmichaud it appears to me as though the   "hll Perl6" declaration in the Perl6Str PMC has no direct effect.
23:30 ron So if I rephrased my initial view of the problem as below might you agree?
23:30 ron 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.
23:31 pmichaud I have trouble with the phrase "methods ... installed in a namespace"
23:31 pmichaud Methods aren't installed in a namespace, they're installed in a class.
23:32 pmichaud 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
23:32 pmichaud same point, though -- the method goes into the class, not into the namespace.
23:33 pmichaud my phrasing of the problem would be something like:
23:33 pmichaud PMCs that declare themselves to be in a different HLL namespace are not receiving methods declared in that namespace.
23:34 pmichaud 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?
23:35 pmichaud I would think that a PMC should receive methods only declared in the namespace corresponding to the PMCs declaration.
23:35 pmichaud so, if the Perl6Str PMC says it's in the
23:36 pmichaud 'Perl6' HLL namespace, I would expect its methods to be in .HLL 'perl6'    and .namespace ['Perl6Str']
23:36 pmichaud I would not expect methods declared in the 'parrot' HLL namespace to be installed in the Perl6Str class.
23:36 ron What is the distinction between receive and install ? (going back to my earlier rephrase)
23:37 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 pmichaud if I do:
23:37 pmichaud .namespace ['XYZClass']
23:37 pmichaud .sub 'xyzmethod' :method
23:37 pmichaud ...
23:37 pmichaud .end
23:38 pmichaud 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
23:39 pmichaud the :method flag means that a sub goes into a class instead of into a namespace.
23:40 ron If I change 'installed' to 'declared' in my phrasing does that help some?
23:40 pmichaud yes, a lot.
23:40 pmichaud the next ambiguity is "may be expected to..."
23:41 pmichaud 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.
23:41 pmichaud for any given PMC, there should be only one location  (hll + namespace) in which we would expect to declare its methods.
23:42 pmichaud I see it as two related problems, instead of being a single problem.
23:42 pmichaud (1)  Methods declared in the 'parrot' HLL namespace are being installed in classes declared in other HLL namespaces.
23:43 pmichaud (2) Methods declared in the same non-parrot HLL as a PMC are not being installed in that PMC.
23:44 pmichaud where we might need to s/classes/PMC/ in #1 above.
23:48 pmichaud okay, gotta go -- my wife wants me to meet her for dinner.  bbl.
23:48 pmichaud Limbic_Region: (message sent)
23:48 wayland76 joined #parrot
23:51 ron I am off for a bit too.  The explanations have clarified my understanding of the rt some but not that much.  Thanks again.

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

Parrot | source cross referenced