Camelia, the Perl 6 bug

IRC log for #parrot, 2009-04-22

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:03 bacek_ joined #parrot
00:09 AndyA joined #parrot
00:19 darbelo left #parrot
00:35 Coke anyone have thoughts on what we should do with milestone tickets for milestones that have passed? I hesitate to auto-bump them to the next release.
00:36 Infinoid I suppose there should be some kind of review process to find a time slot (and possibly someone with more tuits)
00:37 Infinoid maybe group them with a "late" tag if there are a lot of them?
00:40 Coke they already have a milestone, no need to add more meta info.
00:43 rg since they have proved to not be essential enough for anyone to care, i'd just remove them.
00:45 Infinoid not having time != not caring
00:46 Infinoid all these milestones set a pretty brisk development pace, to be honest.
00:46 rg wrong choice of words maybe. i didn't want to offend anyone.
00:47 cotto I guess we forgot to review them during #ps today.
00:47 Infinoid and unfortunately, all the milestones I've signed up for so far (website migration, packfile stuff) have proved to be quite remarkably boring. :)
00:48 cotto After all the PMC hackery I was doing, I though it'd be nice to have some documentation to work on.
00:48 cotto not the case
00:48 Infinoid heh
00:48 cotto especially when it's not inline documentation
00:49 cotto I start documenting, and suddenly vacuuming my apt looks attractive.
00:49 Infinoid oh, don't get me wrong, I've gotten quite a lot of useful things done as a result that I wouldn't have otherwise.  But I haven't made much progress on the actual tasks
01:10 Coke cotto: I was going to review them, but it's not like we were going to do any of them in 5m.
01:10 cotto I have to wonder how much of tewk's work will be reusable if we're eventually going to switch over to writing PMCs and ops in L1.
01:10 Coke the time to review them was last week. We'll do better next release.
01:10 cotto Coke, this is true.
01:10 Coke if tewk finishes before the L1 stuff hits, he wins. =-)
01:11 cotto s/L1/L1 ops/
01:11 cotto which he will, since L1 is only a sparkle in chromatic's eye
01:12 cotto more familiarity with LLVM will help us in any case
01:13 rg if more than just tewk become familiar with llvm ;)
01:19 Infinoid a tewk familiar with llvm is better than no tewk familiar with llvm
01:32 eternaleye joined #parrot
01:34 dalek parrot: r38263 | whiteknight++ | trunk/docs/book/ch09_pasm.pod:
01:34 dalek parrot: a number of major improvements and rewrites to the second quarter of chapter 9. This chapter is far too huge to all the necessary improvements in one commit
01:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38263/
01:45 bacek_ hi there
01:45 bacek_ "L1"?
01:45 bacek_ what is it?
01:45 purl it's it!
01:49 AndyA joined #parrot
01:52 rg some discussion (including jit) that went around here: http://irclog.perlgeek.de/p​arrot/2009-04-21#i_1083550
01:52 rg ah no even before that
01:53 rg the whole thing started about here: http://irclog.perlgeek.de/p​arrot/2009-04-21#i_1083259
02:07 kid51 joined #parrot
02:07 rdice joined #parrot
02:10 bacek_ wow. Sounds good.
02:24 amoc joined #parrot
02:29 darbelo joined #parrot
02:39 fperrad left #parrot
02:39 dukeleto joined #parrot
02:41 janus joined #parrot
02:44 Fayland_logger joined #parrot
02:46 kid51 From the channel message, I take it that the release is complete.  Okay to resume commits?
02:51 wayland_ joined #parrot
02:57 rg kid51: yes, there have been quite a couple already.
02:59 kid51 thx
03:19 gryphon joined #parrot
03:24 dalek parrot: r38264 | jkeenan++ | trunk/src/packfile.c:
03:24 dalek parrot: Applying patch submitted by Andy Dougherty in
03:24 dalek parrot: https://trac.parrot.org/parrot/ticket/254, slightly revised to pass c_parens
03:24 dalek parrot: coding standard test..
03:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38264/
03:32 cspencer joined #parrot
03:39 cspencer parrot has the "compose" opcode which normalizes a unicode string, and reading through some of the unicode docs, i note that there're four normalization forms (NFD, NFC, NFKD and NFKC) - is there a way of specifying which one you'd like?
03:53 dukeleto joined #parrot
04:29 Infinoid he: I've split your netbsd-alpha patch into two issue-focused patches, and created two tickets: #573 and #574.  I didn't have time tonight to do any actual fixing, but I think I've got the current state of things documented.
04:37 tetragon joined #parrot
04:39 Infinoid Hearing no objection to the TT #571 patch, here it comes.
04:40 dalek parrot: r38265 | Infinoid++ | trunk/config/gen/makefiles/CFLAGS.in:
04:40 dalek parrot: [config] Apply patch from doughera++ in TT #571:
04:40 dalek parrot: Enable optimizations in CFLAGS for gcc
04:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38265/
04:51 eternaleye Hm, NEWS contains 'Add another dumper format to assist syntax highlighters
04:51 eternaleye How do I invoke that?
04:51 eternaleye It sounds interesting
04:55 Infinoid https://trac.parrot.org/parrot/changeset/38208
04:55 Fayland_logger joined #parrot
04:56 Infinoid Apparently you invoke a pct compiler object with the --dumper option, or something like that.  I'm not really sure.
04:56 Tene --dumper=padre
04:57 Tene doesn't look like rakudo supports it...
05:01 Infinoid invoking as ./perl6 --dumper=padre <somefile> takes the option but doesn't do anything visible with it
05:10 baest try perl6 --target=parse --dumper=padre <file>
05:12 Andy joined #parrot
05:33 allison joined #parrot
05:45 cotto allison, do you know off the top of your head what kind of PMCs should have need_ext?  It doesn't seem to be especially well-documented.
05:46 allison it used to be PMCs that used the 'data' member, but we moved that into the core struct. Any PMC that does a custom mark will need it.
05:46 allison let's see...
05:46 cotto It contains _synchronize, _metadata and _next_for_gc
05:47 allison properties, that's the other big one
05:47 allison _synchronize is used for some forms of thread sharing
05:47 allison it was used for the old STM, but we've ripped that out
05:48 cotto There are still some places where _synchronize is used.  Should I try ripping them out and seeing what happens?
05:49 allison looks like it's only used in the PMC_sync macro
05:49 allison checking where the macro is used...
05:49 cotto right, but that's used in a half-dozen places
05:50 allison in the gc and in HLLs
05:51 allison it's probably safe to remove
05:51 allison not certain, but likely
05:51 cotto Sounds worthwhile.
05:52 cotto If all PMCs are GC'd, why do only some need the PMC_EXT, with its _next_for_gc?
05:53 allison cotto: it's only used for PMCs with children that need marking
05:53 allison it's a bit of a hack, and will likely be removed eventually
05:54 allison which would leave us with only properties
05:54 cotto ok, so all aggregate PMCs should have need_ext?
05:55 allison which could be handled as an attribute in 'data', if we really wanted it
05:55 allison cotto: aggregates of strings or PMCs, yes
05:55 allison you could have an aggregate of, say, integers that manages a chunk of memory directly instead of GC allocating its children
05:56 cotto ok
05:57 cotto What uses _metadata?
05:57 allison that's properties
05:58 allison set_prop and get_prop
05:58 allison setprop and getprop vtable function
05:59 cotto Ok.  So it's implementation-dependent how properties are used, but if you want them you need need_ext.
06:00 allison well, sneakily, Parrot will add pmc_ext if you call setprop and don't have it
06:01 allison so, even if you don't set need_ext, you'll get it
06:01 cotto I saw a function that looked like it could dynamically add PMC_EXT to a PMC.  It's nice that Parrot dtrt there.
06:02 cotto So it's not strictly necessary for properties, although a generally good idea.
06:02 allison it could be argued that the _metadata pointer should live in the core struct, but properties aren't common enough yet
06:02 allison aye
06:03 allison it's a short cut if you know you're going to need pmc_ext anyway
06:13 allison I don't see the usual "go ahead and start committing again" message on the mailing list
06:14 cotto fperrad said it was fine earlier
06:14 allison but, I do see fperrad tagged the release
06:14 allison okay, I'll go ahead then
06:15 dalek parrot: r38266 | allison++ | trunk/tools/util/release.json:
06:15 dalek parrot: [cage] 1.1 lives in the 'devel' directory. (And so will the next few
06:15 dalek parrot: releases, so might as well go ahead and update it.)
06:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38266/
06:21 iblechbot joined #parrot
06:23 cotto allison, I've got a patch that removes _synchronize.  The build works and I'm running make test.
06:24 cotto If make test passes, do you have time to give the patch a once-over?
06:24 allison sure
06:24 uniejo joined #parrot
06:27 Tene allison: I have some questions about load_language...
06:27 allison aye?
06:27 purl I!
06:27 Tene allison: it looks like the standard is to have languages with uppercase names and pbc files with lowercase names, yes?
06:27 Tene perl6.pbc
06:28 Tene compreg 'Perl6'
06:28 allison seems to be
06:28 Tene Right?
06:28 allison yes
06:28 Tene So should the hll downcase the arg to load_language, or should load_language downcase its arg?
06:29 allison load_language doesn't do compreg
06:29 Tene Right.
06:29 Tene I know.
06:29 nopaste "cotto" at 96.26.202.243 pasted "patch to remove _synchronize from PMC_EXT" (223 lines) at http://nopaste.snit.ch/16371
06:29 cotto allison, incoming
06:29 allison but you're suggesting the name passed to load_language should look the same as the one passed to compreg?
06:30 Tene allison: I'm asking whether it should or not.
06:30 allison (or at least should be able to look the same)
06:30 Tene Right.
06:30 allison (thinking...)
06:30 allison I'm okay with adding downcasing
06:31 Tene Or, perhaps, compreg should be case-insensitive?
06:31 Tene regardless, I think we need some standards here.
06:31 allison maybe case-insensitive, or maybe we should just standardize on one case everywhere
06:32 Tene Right.
06:32 allison so, it's 'Perl6' everywhere, or 'perl6' everywhere
06:32 Tene I'd also be okay with Perl6.pbc, for example
06:32 allison but not swapping between the two all the time
06:32 allison and 'Perl6' as the name of the namespace
06:32 allison (the HLL namespace)
06:32 Tene iirc, hll namespaces are already specced as case-insensitive
06:33 allison blech :(
06:33 * allison has been bitten by case-insensitive file-systems
06:33 * Tene also
06:34 allison on the whole, I'm happier with asking HLLs to pick a case and stick with it
06:34 allison than messing with downcasing (and maybe also upcasing) in various locations
06:34 allison but, it's a question to put to the general pool of HLL developers
06:35 * Tene nods
06:35 Tene perhaps someone should post to the list.
06:36 allison a summary of this irc conversation would do
06:36 Tene allison: if I can get a partial port of rakudo to its own HLL namespace, up to the part where it breaks due to PMC HLL issues, will you have tuits to work on it sometime soon, or are you pretty booked?
06:36 allison yes, I can take a look
06:37 dalek rakudo: fd0a4d5 | (Stephen Weeks)++ | src/builtins/control.pir:
06:37 dalek rakudo: Use load_lang opcode for eval with :lang
06:37 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​d0a4d581d8df767af5c5cecce5fa6c567ca8b39
06:37 shorten dalek's url is at http://xrl.us/bepvhp
06:38 allison cotto: the patch looks good
06:39 allison cotto: I'm not sure how good our threading tests are, so might want to run a few thread test examples aside from our official test suite
06:40 cotto as in write some new ones?
06:40 allison just to be sure shared variables still work (that is, to make sure it was only STM that was using _synchronize)
06:41 allison cotto: yeah, or just take a quick skim of the existing ones and see if they cover the common cases (specifically, if they cover shared variables)
06:41 Tene okay, sent.  LEt's see if my mail to the list actually goes through this time.
06:42 Tene (often doesn't)
06:42 Tene oh, went straight through, no problem
06:42 Tene huh
06:43 chromatic joined #parrot
06:44 dukeleto joined #parrot
06:44 allison Tene: your address might have been on the "needs approval" list, and I might have set it to "always accept" (I don't remember doing it with your address specifically, but I've certainly done it with a number of other addresses)
06:44 Tene ah
06:44 Tene :)
06:58 cotto allison, what would a proper test for shared variable synchronization look like?  modify a shared aggregate rapid-fire and make sure it doesn't end up corrupted?
06:58 cotto s/aggregate/aggregate PMC/
06:59 allison I'm not even sure we're testing basic synchronization, create a variable, modify it from two different threads
06:59 allison but, yes, stress testing would be a good addition
07:00 cotto The thread tests seem a little sparse.  I'll add some more before committing the patch.
07:03 cotto It's funny how many tangents updating docs/pmc.pod has involved.
07:15 allison :)
07:36 rblasch joined #parrot
08:00 fperrad joined #parrot
09:06 mikehh joined #parrot
09:23 dalek tracwiki: v91 | fperrad++ | Languages
09:23 dalek tracwiki: Update with Parrot 1.1.0
09:23 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​Languages?version=91&amp;action=diff
09:23 shorten dalek's url is at http://xrl.us/bepvvu
09:48 cotto allison, are you still up?
09:48 cotto or anyone who knows how to use threads in pir
09:49 he left #parrot
09:49 dalek tracwiki: v92 | fperrad++ | Languages
09:49 dalek tracwiki: More update with Parrot 1.1.0
09:50 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​Languages?version=92&amp;action=diff
09:50 shorten dalek's url is at http://xrl.us/bepwre
09:51 nopaste "cotto" at 96.26.202.243 pasted "attempt to get two threads reading/writing a shared PMC" (51 lines) at http://nopaste.snit.ch/16374
10:17 bacek cotto: threads in parrot are pretty useless because of disabling GC...
10:21 cotto goodie
10:27 cotto so can stuff be shared between threads at all more than from parent to child?
10:39 cotto Hmmm.  Threads don't seem to be on either roadmap.
10:43 bacek cotto: try it with PARROT_CLONE_DEFAULT ( or just use "run_clone" which is equivalent)
10:45 cotto bacek, no dice
10:48 cotto I get the feeling that this isn't something Parrot wants me to do.
11:05 * bacek really want to create "pmc_pct" branch to rewrite pmc2c in PCT.
11:06 cotto you'd be loved and your name would be held in high esteem
11:07 bacek Even for just creating branch? :)
11:08 cotto we have low standards around here
11:09 bacek my own standards are little bit higher...
11:12 dalek parrot: r38267 | bacek++ | branches/packfile_revamp:
11:12 dalek parrot: Removed packfile_revamp branch. It was merged into trunk
11:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38267/
11:15 dalek rakudo: d0a5de5 | (Moritz Lenz)++ | src/setting/Match.pm:
11:15 dalek rakudo: Match.perl: work around RT #64952
11:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​0a5de55a1da8c7307e6c486fd9b548fcbc0b727
11:15 shorten dalek's url is at http://xrl.us/bepwu6
11:16 dalek parrot: r38268 | fperrad++ | trunk/config/gen/makefiles/root.in:
11:16 dalek parrot: [build] fix warning on Windows (introduced by r38256)
11:16 dalek parrot: makefile:638: warning: overriding commands for target `.s.o'
11:16 dalek parrot: makefile:636: warning: ignoring old commands for target `.s.o'
11:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38268/
11:30 cognominal joined #parrot
11:35 ruoso joined #parrot
11:50 mikehh Method 'log10' not found for invocant of class 'Complex' after ok 27 - got the log10 of -i (complex unit)
11:51 moritz mikehh: I just fixed the test
11:51 mikehh sorry wrong channel
11:52 moritz happens to me all the time
11:54 mikehh moritz: jolly good show and all that sort of stuff :-}
12:05 Gerd joined #parrot
12:07 dalek parrot: r38269 | fperrad++ | trunk (2 files):
12:07 dalek parrot: [chm] add pdd15_object_metamodel image
12:07 dalek parrot: Patch from bsdz++ (See TT #572)
12:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38269/
12:07 Gerd Hello Allison!
12:09 Gerd Allison: Do you already read my last email?
12:31 coke_afk (case) yes, pick a case and stick with it.
12:37 rg1 joined #parrot
12:59 rdice joined #parrot
13:03 gryphon joined #parrot
13:12 wayland_ joined #parrot
13:13 dalek parrot: r38270 | pmichaud++ | trunk/compilers/pct/src (2 files):
13:13 dalek parrot: [pct]:  loadinit handling in PAST/POST compilation now works for 'compiler' nodes
13:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38270/
13:27 iblechbot joined #parrot
13:28 particle1 joined #parrot
13:46 Coke pmichaud: you about?
13:46 pmichaud Here.
13:46 gryphon joined #parrot
13:48 Coke messages eraseblahblahboo
13:48 Coke (thanks, purl. =-)
13:48 Coke pmichaud: was wondering on the status of some very old PGE tickets. let me findz them.
13:49 pmichaud in all probably they are still significant.
13:49 pmichaud *probability
13:49 PacoLinux joined #parrot
13:51 Coke turns out there's more than I thought. 8 RTS with PGE in the subject.
13:52 Coke Yah, I figured you'd have rejected them by now if they weren't relevant.
13:52 pmichaud I can see about moving them to Trac, though.
13:52 pmichaud and comment on them that "yes, this is still relevant."
13:52 Coke eh.
13:52 pmichaud Although I think a couple of them got closed this past weekend :-)
13:53 Coke We don't have to move to trac. I've done that for a few tickets where there's no history and we can just cut and paste the original post.
13:53 Coke have to move to tracy *immediately*, anyway.
13:53 Coke http://rt.perl.org/rt3/Tic​ket/Display.html?id=53464 would be a fine candidate to move, e.g., esp if it's not getting closed anytime soon.
13:54 pmichaud oh, I might be able to resolve that one soon.
13:54 Andy joined #parrot
13:54 pmichaud I might even be able to delegate it to someone who did some PGE hacking at NPW
13:54 Coke that would be awesome. (delegation)
13:54 Coke right now our PGE bus number is somewhere between 1 and 2.
13:59 he joined #parrot
14:03 nopaste "he" at 158.38.152.119 pasted "...and another architecture tested, ref. smolder 20336, diff to PLATFORMS" (12 lines) at http://nopaste.snit.ch/16376
14:06 Coke he?
14:06 purl well, he is Havard Eidnes <mailto:he@NetBSD.org>
14:06 dalek rakudo: 04ee8d0 | pmichaud++ | docs/spectest-progress.csv:
14:06 dalek rakudo: spectest-progress.csv update: 374 files, 10467 passing, 0 failing
14:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​4ee8d0e08db9ec3634e1ded6b3b271c30ed33a6
14:06 shorten dalek's url is at http://xrl.us/bepxas
14:07 Coke he: committed.
14:10 dalek parrot: r38271 | coke++ | trunk/PLATFORMS:
14:10 dalek parrot: [docs] another platform passing
14:10 dalek joined #parrot
14:12 he Coke: thanks.
14:21 Infinoid he: I've split your netbsd-alpha patch into two issue-focused patches, and created two tickets: #573 and #574.  I didn't have time tonight to do any actual fixing, but I think I've got the current state of things documented.
14:22 Infinoid oh... I see you already found #574.  nevermind :)
14:25 he :)
14:37 he left #parrot
14:37 * Coke now gets to write some RE stuff in cf. gah.
14:43 masak joined #parrot
14:50 Coke ... I can't seem to find a substring variant in CFMX that /replaces/, only extracts.
14:51 Coke (I do find a very long thread where someone asks this question and is told they'd be fired if they worked for the repsonder.)
14:57 rg1 the things we've come to expect from our favourite language ;)
15:05 Infinoid fired for asking about search and replace, or fired for using CF in the first place?
15:07 Infinoid Coke: When will parrot get CF? :)
15:09 Coke Infinoid: for asking the question without checking the docs.
15:09 Coke and while the OP was vague in what it wanted, the obvious (to cfmx people) answer was pretty obvious.
15:09 Coke Infinoid: Never?
15:09 purl Well, hardly ever!
15:10 Coke Infinoid: If there were no licensing concerns, it'd be doable.
15:10 Coke except for the part where CFMX has tight integration with flash & pdf because it's adobe, and that it's written in Java currently.
15:12 * Infinoid wants lolfusion
15:15 slavorgn joined #parrot
15:22 Infinoid allison: As we discussed yesterday, src/pmc/class.pmc:338 calls Parrot_pcc_build_sig_object_from_varargs with a NULL va_list argument, which fails to build on platforms where va_list is a struct type and not a pointer.  It then calls Parrot_pcc_invoke_from_sig_object() with the result, but it doesn't look like I can pass PMCNULL there.
15:23 Infinoid Unfortunately, I don't know PCC at all.  How much of what we discussed yesterday is already there and ready for use, and how much infrastructure do we still need to add for the PMCNULL_SIGNATURE stuff you suggested?
15:24 he joined #parrot
15:24 Infinoid There's a ticket for this, #573, but I'm hoping for a little guidance to find a better fix (the current patch changes a bunch of APIs)
15:30 cspencer joined #parrot
15:33 Theory joined #parrot
15:46 allison Infinoid: the solution is to not call Parrot_pcc_build_sig_object
15:48 allison Infinoid: at the moment, the system isn't set up to handle a PMCNULL in place of a sig object, but a sig object with no arguments or returns will work just fine
15:49 allison that is, just "pmc_new(interp, enum_class_CallSignature)"
15:49 allison no build or extensions
15:49 Infinoid ah, cool.  I'll try that in place of the Parrot_pcc_build_sig_object_from_varargs, thanks!
15:52 Coke allison: you'd probably know the answer to this question: are there any legal ramifications to implementing a coldfusion-alike on top of parrot?
15:53 Coke Not, mind you, that I'd advocate that insanity.
15:54 allison as long as we aren't using their code, no legal problems at all
15:54 allison copyright doesn't protect them from someone implementing the same interface
15:55 allison (I could see someone wanting it)
15:56 particle you're both sick.
15:57 Coke allison: I do wonder if their online docs have any kind of eula.
15:58 Coke "if you read these, you agree not to harsh our buzz."
16:01 davidfetter joined #parrot
16:08 nopaste "tene" at 166.70.38.237 pasted "full bt for Match issue" (15 lines) at http://nopaste.snit.ch/16377
16:09 Khisanth docs with eula? O_o
16:12 rblackwe joined #parrot
16:15 HG` joined #parrot
16:16 davidfetter Khisanth, it's not the wackiest thing i've seen :P
16:18 nopaste "Infinoid" at 75.140.33.106 pasted "Patch implementing allison++'s suggestion for TT #573, unfortunately it doesn't quite work (error message included)" (29 lines) at http://nopaste.snit.ch/16378
16:22 allison Infinoid: set the string value of the sig_object to a CONST_STRING "->", that should take care of it
16:23 allison Coke: very possible, though those sorts of limitations are usually put on "using" the software
16:26 Infinoid with "->" I get "too few arguments passed (0) - 1 params expected"
16:27 allison is it a method or a sub?
16:27 davidfetter hi allison. how'd the talk go last night?
16:27 davidfetter <-- couldn't make it :P
16:27 allison Infinoid: if it's a method, then it needs the invocant added as an argument
16:28 allison davidfetter: it went well, good crowd, good questions
16:28 davidfetter cool :)
16:28 allison (I have two more talks at Bay Area user groups in the next couple of months)
16:28 Infinoid I think it's trying to call init() on a base class, so it must be a method
16:29 davidfetter where?
16:29 allison Infinoid: okay, I have to go catch a plane, but will be back online in about 3 hours and can look at it then
16:29 davidfetter bon voyage :)
16:29 Infinoid I'll rtfm and see if I can figure it out
16:30 Infinoid thanks!
16:30 allison davidfetter: PenLUG and SVLUG
16:30 allison adios
16:38 Infinoid he: I'm concerned that there may be other build failures caused by the va_list type issue.  But I've got a patch to fix this particular NULL case, are you able to test?
16:38 nopaste "infinoid" at 75.140.33.106 pasted "TT #573: This patch builds and tests successfully on Linux/x86-64." (25 lines) at http://nopaste.snit.ch/16379
16:39 dalek parrot: r38272 | fperrad++ | trunk/t/codingstd/copyright.t:
16:39 dalek parrot: [t] revert r38202 (release done)
16:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38272/
16:45 braceta joined #parrot
16:58 fperrad joined #parrot
17:01 flh joined #parrot
17:05 jan joined #parrot
17:21 darbelo joined #parrot
17:22 japhb joined #parrot
17:25 helozjisky joined #parrot
17:36 LylePerl joined #parrot
17:39 LylePerl I'm having an issue with parrot Configure.pl and ActiveState 5.8
17:39 particle 5.8.what?
17:39 LylePerl ActivePerl 5.8.8 is compiled with MSCV++
17:40 LylePerl So parrot is assuming MSVC++ and failing (most people with ActivePerl wont have MSVC++)
17:40 LylePerl ActivePerl 5.10 is compiled with gcc so it's not an issue
17:41 LylePerl I was wondering if it's worth my writing a patch so that it'll check for MSVC++ and if not available default to MinGW instead...
17:41 particle no
17:41 jhorwitz joined #parrot
17:41 particle you need to specify the compiler on the command line
17:42 particle perl Configure.pl --cc=... etc
17:42 particle see --help
17:42 LylePerl yes, but I thought it's be easier for people if it just worked straight away?
17:42 cspencer is anyone here familiar with the parrot "compose" unicode normalization opcode?
17:42 particle what if msvc and mingw are available?
17:43 LylePerl Then default to msvc like it is already
17:43 particle LylePerl: maybe compiler detection is broken... hrmm.
17:44 LylePerl As far as I could see it picks up the compiler from Perl
17:44 LylePerl Is there a detection module that overrides it?
17:44 rg i believe there isn't really such a thing as compiler detection. short of specifying the compiler, it's "use whatever was used to compile perl"
17:45 LylePerl config/init/defaults.pm get's it from Perl's Config
17:46 particle does perl built with msvc work with xs modules built with mingw gcc?
17:46 LylePerl Yes, for the most part
17:47 LylePerl I read a post about it on the ActiveState list, there are only some specific windows XS modules that have issues
17:47 LylePerl But they may well have been fixed now, with 5.10 using mingw
17:48 particle well, if you want to monkey with compiler detection, feel free, but i can't imagine too many users with AS perl 5.8 and mingw gcc compiling parrot
17:48 particle i just don't want to be the guy supporting it, is what i'm trying to say.  it's not that i don't think it's not valuable, as i like it when things Just Work.
17:49 rg well i could build a similar scenario on solaris, but i'm contempt with just specifying the compiler on the command line
17:50 LylePerl I'm just thinking that most the Win32 hosting companies that I've come across who support Perl are using AP 5.8.x
17:51 barney joined #parrot
17:52 LylePerl If they gave parrot a try, it would be good if it just worked
17:53 particle they're more likely to try rakudo than parrot
17:53 particle but, yeah.
17:53 rg i'd also expect most windows users to look for a binary or even installer package
17:54 particle yes, which we have, too
17:54 * Tene entertained by s/content/contempt/
17:54 rg happy to be of service ;)
17:54 LylePerl Yes, and rakudo just trys to run Configure.pl with defaults to install parrot (that's why I was trying to do)
17:54 Infinoid Contempt-type: application/x-foadiafoa+xml
17:55 HG` joined #parrot
17:58 moritz LylePerl: rakudo's Configure.pl  can pass arguments to parrot's Configure.pl
17:59 szabgab joined #parrot
18:01 NotFound What will be a good compiler detection stratregy: try all .exe in the system? ;-)
18:01 Infinoid Did the new parrot tarball ever get uploaded to the ftp site?
18:01 Infinoid NotFound: In sha1 order
18:02 Tene pmichaud: I'd love to get comments from you on the HLL name case issue on the list
18:02 NotFound If we implement a compiler detection we must provide a way to overrida if it fails... hey, we already have that
18:04 NotFound So the detection will only be useful for people stupid enough to install C compiler without even knowing.
18:04 rg lyleperl: seems like a lot of people here seem to think your time could be better spent elsewhere ;)
18:04 rg notfound: no the detection will be useful for people who get a perl binary from someone using a compiler they don't have.
18:05 LylePerl I'm trying to think Windows mentallity
18:05 NotFound rg: 99% of that people will not have any C compiler. At least 50% of them even doesn't know what is a compiler
18:06 Infinoid and 85% of those 50% don't know or care about parrot, they just want rakudo
18:06 LylePerl Most of them will probably struggle to open a command prompt. People usually give up if there isn't an install.exe or setup.exe
18:06 NotFound Then point them to a binary
18:06 particle ...which we have.
18:07 fperrad see http://parrotwin32.sourceforge.net/
18:22 Coke yah. packing FTW.
18:22 Coke ... sigh.
18:22 Coke "packaging"
18:32 * davidfetter wonders whether Coke's packing
18:33 Tene It's interesting having a boss who open-carries.
18:34 * davidfetter wonders if every finite open carry has a finite sub-carry
18:34 davidfetter er, if every open carry*
18:37 iblechbot joined #parrot
18:43 Coke given my line of work, open carry would be very wierd.
18:46 davidfetter what line is that?
18:46 purl line that is, like, dying is actually IN the bash script. SilverStr is wondering if I should be forking there instead
18:46 davidfetter open the pod bay doors, purl
18:46 purl I'm sorry, davidfetter, I'm afraid I can't do that.  I still have the utmost confidence in the mission.
18:47 whoppix joined #parrot
18:47 * davidfetter finds open carry pretty weird in light of its universal and explicit threat of death
18:49 wayland_ Modern people have a historically unusually high fear of death
18:49 PerlJam davidfetter: it's the same policy the USA and Russia have been following.  "I know you can hurt me and you know I can hurt you, so let's not hurt each other even though we can"
18:49 wayland_ (I suspect, anyway)
18:50 wayland_ For a while, this was referred to a "Mutually Assured Destruction"
18:50 wayland_ However, I think "Mutually Assured Non-destruction" is probably a better term now :)
18:51 wayland_ And I'll have to remember the acronym for future reference :)
18:59 rblasch joined #parrot
19:00 pmichaud phone, today?
19:00 pmichaud I guess that wouldn't be for another 60 mins, though.
19:07 HG` joined #parrot
19:17 dalek parrot: r38273 | coke++ | trunk/t/compilers/imcc/syn/regressions.t:
19:17 dalek parrot: [t] add a test for TT #575
19:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38273/
19:17 Coke pmichaud: trying out the obvious fix. Will let you know.
19:21 Coke changing LEXICAL STRINGC to LEXICAL any_string still fails the same way.
19:23 pmichaud I could understand it failing;  failing "the same way" is a bit surprising, though.
19:24 Coke it still says it's expecting a STRINGC.
19:24 Coke doesn't look like .y needs any special protection for sub rules. (so that any_string should be self contained when I use it in the LEXICAL rule)
19:25 Coke trying 2 explicit rules, just to see...
19:26 Coke nope.
19:30 Coke something odd, since if I just replace STRINGC with USTRINGC there I get the same error.
19:31 Coke AH! multiple lexical rules. wtf. I wonder how this other one ever gets called. =-)
19:32 Coke # Lexical '$βοο' not found
19:32 pmichaud ah, that's getting closer, then.
19:33 rblasch1 joined #parrot
19:34 Coke I suspect IMCC's set_lexical needs to be smarter about strings.
19:35 Coke hurm. this might be fixable...
19:41 szabgab joined #parrot
19:47 allison joined #parrot
19:51 Coke pmichaud: passing that TODO, running a 'test' now.
19:51 pmichaud yay!
19:51 Coke allison;functions used only internaly by IMCC are changeable with no notice, neh?
19:52 Coke or anyone. =-)
19:52 Coke pmichaud: I was changing the /pasm/ rule originally which I why I got nowhere. =-)
19:53 pmichaud a-ha
19:53 pmichaud interesting (and amusing)
19:53 pmichaud me, I would've been lost for most of it.  :-)
19:54 Coke eh. not like I know what I'm doing, really.
19:54 Infinoid Coke: if it's something that isn't tagged with PARROT_EXPORT, I wouldn't hesitate to change it
19:55 Coke bah. I only changed C code. now running perlcritic.t ...
19:57 jhorwitz pmichaud: having a mod_perl6 regression failure. i create a class in PIR and register it w/ P6metaclass.  but then in rakudo Foo.new() tries to invoke Foo() before calling the 'new' method, which fails miserably. ideas?
19:58 jhorwitz i can paste if necessary
19:58 dalek parrot: r38274 | coke++ | trunk (4 files):
19:58 dalek parrot: [imcc] - allow unicode lexical identifiers. (Fix TT #575)
19:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38274/
19:58 pmichaud Sounds like Rakudo is reading Foo as a listop instead of a typename.
19:58 jonathan jhorwitz: The registration of the class is being done *before* Rakudo gets to parse Foo.new(), right?
19:58 jonathan jhorwitz: If not, that would need fixing.
19:58 jhorwitz jonathan: hi there!  correct.
19:58 jonathan OK.
19:59 jonathan Is it in a different HLL's namespace?
19:59 jhorwitz wait...
19:59 jhorwitz actually...
19:59 pmichaud my guess is that it doesn't have the Abstraction role.
19:59 jhorwitz i'm precompiling that particular module, so it would be parsed BEFORE the registration
19:59 pmichaud oh.
19:59 jonathan pmichaud: At the moment, I'm pretty sure we check if it's a proto explicitly.
19:59 pmichaud (do all protoobjects automatically get the Abstraction role?)
19:59 pmichaud jonathan: okay.  Good.
20:00 jonathan (Since I figured we can't rely on external types automatically getting Abstraction.)
20:00 pmichaud jonathan++
20:00 jonathan jhorwitz: OK, that's...tricky. :-(
20:00 jonathan jhorwitz: Basically because Rakudo at parse-time needs to know what is a type and what is not.
20:01 jonathan If it can't find a type in the namespace under that name, then it presumes it's a post-declared list-op.
20:01 jonathan (This isn't just Rakudo, it's what STD.pm does as well.)
20:01 jhorwitz precompiling has exposed all sorts of interesting bugs.
20:01 jhorwitz and features.  :)
20:01 jonathan I guess that you are not having a "use" directive that registers these?
20:02 jonathan (I figure you probably can't because we don't have importing from non-Rakudo modules worked out yet...)
20:02 jhorwitz that too.  :)
20:02 jonathan (Well, just use'ing...)
20:02 jhorwitz mod_parrot does the registering.  mod_perl6 just assumes that "Foo" is a registered class.
20:02 jhorwitz no "use"ing or anything else.
20:03 particle phone
20:03 jonathan I wonder if the Best Thing would be for me to get class stubs in.
20:04 jonathan So you can 'use' something in the script that pulls in the stubs or means they are at least identified as type names...
20:04 jhorwitz if that makes my problem go away, then +1  ;-)
20:04 jhorwitz shall i open a ticket?
20:04 jonathan Yeah, that'll serve as a reminder for me. :-)
20:04 jhorwitz excellent.  ITMT i'm going to try it w/o precompiling
20:05 jonathan Provided you compile after the symbols are registered, you should be fine.
20:05 jhorwitz it's part of the mod_perl6 build process, so that's not gonna happen.  :)
20:07 dalek parrot: r38275 | chromatic++ | trunk (20 files):
20:07 dalek parrot: Merged the headercleanup branch to trunk as of r38254.
20:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38275/
20:08 Coke is there a test/spectest for http://rt.perl.org/rt3/Tic​ket/Display.html?id=64878
20:08 Coke (I can't easily type in greek.)
20:10 Infinoid there's probably a spectest, let me look
20:12 Infinoid S02-lexical-conventions/unicode.t has unicode variable names
20:12 Infinoid also function names.
20:13 moritz I should fudge that
20:13 Infinoid is greek treated any differently than any of the other stuff in that file?
20:13 Infinoid (I don't think it should be.)
20:13 jonathan Probably not.
20:14 Coke moritz: if you can check out [perl #64878] in re: testing, that'd be good. =-)
20:14 moritz Infinoid: not different than other non-latin1-stuff
20:14 jonathan If other non-ASCII and non-Latin-1 stuff works, greek probably should.
20:14 jonathan I guess all of us who know some of a language with non-Latin-1 chars could contribute some tests though. ;-)
20:16 Infinoid I know monty python, but the test already covered that.
20:17 moritz not even Latin-1 non-ascii work
20:18 Coke moritz: should work with latest parrot.
20:18 Tene I just tested it
20:18 allison Coke: yes, it's the public API that's subject to deprecation cycles
20:19 moritz Coke: I'll svn up and try
20:19 Coke allison: good, since I already committed that. ^_^
20:19 nopaste "tene" at 97.117.72.236 pasted "fail for Coke++" (18 lines) at http://nopaste.snit.ch/16383
20:19 allison Coke: (I just wandered over to the laptop running IRC, catching up)
20:19 Coke Tene: can you reduce that to a parrot failure? =-)
20:22 samlh joined #parrot
20:23 Tene hmm
20:24 Tene ... but maybe it does work?
20:24 Tene it doesn't work with -e, but does work in a file??
20:25 bsdz joined #parrot
20:25 nopaste "tene" at 97.117.72.236 pasted "Weird failure..." (23 lines) at http://nopaste.snit.ch/16384
20:26 Tene that's creepy
20:26 bsdz hi, any easy way to disable #line directives being created during *.pmc -> *.c creation ?
20:26 he Infinoid: tested with http://nopaste.snit.ch/16379 and my alternative workarounds de-applied, and it builds and tests OK still.
20:27 jonathan Tene: How is Parrot handling unicode passed in ARGC?
20:27 Tene jonathan: enoclue
20:28 NotFound Last time I checked parrot does nothing, but rakudo assume they are latin1
20:28 Tene This doesn't work in rakudo, even in a file:
20:28 Tene sub ☂ { ... }
20:28 Coke I just fixed lexicals. =-)
20:28 Coke "fixed"
20:29 Tene malformed routine definition
20:29 NotFound Tene: have you tried quoting it?
20:29 moritz Tene: is  ☂ an identifier character?
20:29 Tene Apparently not
20:29 moritz perl 5 conforms that
20:30 Tene NotFound: you can't quote sub names.
20:30 Tene in rakudo
20:30 moritz in Perl 6 in general
20:30 NotFound Make rakudo quoting the,m then
20:30 moritz that still doesn't make ☂ a valid Perl 6 sub name ;-)
20:31 NotFound Thanks god ;)
20:31 Tene moritz: but it could be an operator...
20:31 moritz Tene: sure
20:32 NotFound Urgh. You're giving a new sense to the saying: "The language that looks like line noide"
20:32 NotFound noise
20:32 Tene jonathan: this is what you were asking, I think...
20:32 Tene $P1 = $P0.'command_line'(args_str, 'encoding'=>'utf8', 'transcode'=>'ascii')
20:33 gryphon joined #parrot
20:33 fperrad allison: have you some news from ftp-osl.osuosl.org ?
20:40 Infinoid he: great, thanks, I'll apply it then
20:44 Infinoid So that just leaves the SIGFPE stuff
20:45 dalek parrot: r38276 | Infinoid++ | trunk/src/pmc/class.pmc:
20:45 dalek parrot: [netbsd] netbsd-alpha fails to compile due to passing NULL in place of a va_list argument.
20:45 dalek parrot: va_list is not always a pointer type, this is not a requirement of C89.
20:45 dalek parrot: This patch implements allison++'s suggestion to more cleanly build a null CallSignature object.
20:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38276/
20:54 Infinoid Forgot to mention, that last commit fixes TT #573.
20:55 bsdz fyi: ops2c.pl --no-lines disables #line directives
21:01 rblasch joined #parrot
21:18 Coke moritz: any more passing tests in that spectest now?
21:19 particle fperrad: they've asked us to provide ssh keys.  looks like each of the release managers will need to do so.
21:22 moritz Coke: yes. Works with greek now
21:27 moritz but other parts of the file still fail, and it's hard to make out which part it is
21:29 Ademan joined #parrot
21:30 Coke moritz: whee.
21:35 moritz Coke: I'm working on it, but the tests use outdated stuff in many places
21:43 Coke moritz: approximately how many tests do you think you'll end up with?
21:43 Coke (passing)
21:43 gerd joined #parrot
21:43 pmichaud By the time Rakudo sees the command line arguments, Parrot will have already placed them in strings and given them an encoding.
21:43 moritz Coke: 28 in that test file
21:43 pmichaud So Rakudo doesn't really control the encoding of the command line arguments -- that comes from Parrot.
21:44 pmichaud (in response to:  20:28 <NotFound> Last time I checked parrot does nothing, but rakudo assume they are latin1
21:44 jonathan pmichaud: I was guessing it would be something like that.
21:44 jonathan May need a Rakudo fix.
21:45 jonathan erm
21:45 pmichaud I'm thinking it should be a Parrot fix.
21:45 jonathan a Parrot fix.
21:45 jonathan Yeah
21:45 jonathan I thought one and typed the other.
21:45 NotFound Last time was some time ago ;)
21:45 janus hm, 1.1.0 hasn't hit the ftp yet?
21:46 moritz pmichaud:  t/spec/S02-lexical-conventions/unicode.t now mostly passes, but there are some details that don't work with Unicode, it seems
21:47 Whiteknight joined #parrot
21:47 pmichaud moritz: example?
21:48 moritz pmichaud: a named param :$äöü
21:48 moritz in a lexical sub, that is
21:48 pmichaud I wonder if Parrot accepts unicode named parameters.
21:49 moritz pmichaud: and the hindi identifiers don't get parsed
21:49 moritz perl 5 confirms that they match ^\w+$
21:50 moritz but PGE does not
21:50 pmichaud ...checking.
21:51 moritz actually I have a test file that runs in both Rakudo and perl-5.10 without modifications
21:52 nopaste "moritz_" at 91.10.248.48 pasted "Hindi test" (8 lines) at http://nopaste.snit.ch/16385
21:53 jdv79 left #parrot
21:54 pmichaud try with  /^<isL>+$/  in rakudo?
21:54 moritz also false
21:55 pmichaud That's odd.
21:55 pmichaud Maybe  <isLo>+  ?
21:55 moritz also false.
21:57 pmichaud &#2370 is given as a "non spacing mark"
21:57 moritz that thing is made of \N{DEVANAGARI LETTER DA} and \N{DEVANAGARI VOWEL SIGN UU}
21:58 moritz and Perl 5 thinks that all marks match \w
21:58 moritz because that way most regexes DWIM
21:58 moritz Perl 6 won't need that, once it works on graphemes
21:58 moritz it just has to respond with with "yes" to \w if the base char is a letter
21:59 Coke someone should open a trac to get the 1.1.0 docs out on docs.parrot.org and I'll get to it tomorrow if no one else has.
22:08 particle we need a way to submit trac tickets from irc
22:09 ingy hi
22:09 rg particle: if we can get submitting tickets by mail fixed, maybe we can write (or extend) a bot ;)
22:09 particle sigh.
22:09 particle heya ingy
22:09 rg moritz: can you close #63922 (perl6 ticket)
22:09 ingy hi particle. how's seattle?
22:10 moritz rg: done, thanks
22:10 particle wet, again.
22:10 particle where are you these days?
22:10 ingy I heard you had some sun
22:10 ingy I was just in oslo with pmichaud et al
22:10 particle yeah, it was awesome, while it lasted.  got a nice sunburn on a long bike ride
22:11 ingy now I'm back in Chamonix
22:11 ingy to UK on May 5th, then Seattle on May 27th
22:12 ingy then Pittsburgh
22:12 ingy planning to drive from seattle to PA
22:12 particle i'm sure i'll see you there.
22:12 particle ride or drive?
22:12 ingy drive I think
22:12 ingy I don't have the bike for that kind of riding
22:13 particle ought to be a nice ride, until chicago/indy
22:13 ingy drive
22:13 ingy ;)
22:13 particle then it's a bit trafficky
22:13 particle er, drive :)
22:14 ingy I've driven coast to coast many times
22:14 particle twice for me. 10k miles in 5 weeks.
22:14 particle of which, 3k miles was in 4 days.
22:14 ingy anyway thinking about just driving for the summer
22:14 ingy that's a lot
22:15 Infinoid that's an accelerated particle
22:15 particle indeed i was
22:15 ingy I drove 1200 on a motorcyle in one go
22:15 particle my longest day was billings->seattle
22:15 ingy got off 4 times for gas
22:15 ingy this was boulder->chicago
22:16 particle wait, maybe that's not my longest day...
22:16 ingy I drove portland to boulder in 27 on motorcycle
22:17 ingy but pull over to sleep 3 hours in a field
22:17 particle too much for me.
22:17 ingy my typical car driving day is 750 miles
22:18 ingy that's usually like 18 hours
22:18 ingy er 16
22:18 jonathan That's...a lot of driving.
22:18 * jonathan can't drive, but can't quite imagine being able to concentrate enough for that long either.
22:18 ingy then I recline the seat, sleep 8 hours, get up, pee, and repeat
22:19 ingy hi jonathan!
22:19 jonathan hi ingy!
22:19 pmichaud I did St. Louis to Pittsburgh once in a single stretch.
22:19 pmichaud Not quite 750 miles, but it's up in the high 600s I think
22:20 pmichaud eh, Google says 601.  Oh well.
22:20 ingy I've done chicago to stl (5 hours), and chicago to pitts (10 hours) a lot
22:20 * jonathan has done 1000km+ in a day on train, but that's rather less effort on my part. ;-)
22:20 ingy chi->pitts is like 450 iirc
22:20 pmichaud my longish drives were typically Lafayette to Corpus Christi (7.5 hours) every two weeks.
22:21 rblasch1 joined #parrot
22:21 ingy I'm just glad gas is back to normalish
22:21 pmichaud indeed.  :-)
22:21 Infinoid I've tried and failed to do Lake Tahoe to Phoenix in one stretch... twice
22:21 * Infinoid burns out too easily from driving.
22:22 jonathan I barely travel in a car these days. When Jeremiah++ drove us from Gothenburg up to Oslo for NPW, I realized it was my longest car journey so far this year. And it was just 3 hours.
22:22 jonathan I actually don't dislike it, particularly if there are decent views to be had.
22:25 jonathan TBH, I think folks from the US tend to have a different concept of "a long drive" to many Europeans.
22:26 rob joined #parrot
22:26 rob hey just been reading http://www.pmichaud.com/2009/pr​es/npw-pct/slides/slide41c.html
22:26 shorten rob's url is at http://xrl.us/bepzkf
22:27 rob does the $<something>.ast'method mean that $($<something>) is now depreciated?
22:28 Whiteknight pmichaud and jonathan, I was wondering if you two saw my response to TT #218?
22:28 jonathan rob: Yes.
22:29 rob ah ok, it reads better I guess. will have to update porcupine
22:30 particle ingy: i did my nyc->chi in 11 hours (880mi)
22:30 ingy leadfoot
22:30 particle yep :D
22:30 ingy :)
22:31 jonathan Whiteknight: Just read it.
22:32 jonathan Whiteknight: get_pointer is _meant_ to return some kind of address that represents the PMC.
22:32 cotto If you had a delorean, you'd only have to go 88 MPH for the last few seconds.
22:32 Whiteknight jonathan: but get_pointer has different semantics for all PMCs
22:32 Whiteknight for some PMCs it returns the SELF pointer, for other PMCs it returns a pointer to the underlying data
22:33 Whiteknight I'm saying for encapsulation, FixedPMCArray should use the later semantics, not the former
22:34 jonathan Yeah, but even within that the tests that pmichaud added should hold.
22:34 jonathan That is, the underlying data should be different.
22:35 Whiteknight Not necessarily, if the two PMCs are pointing to a NULL array, or are shallow copies of each other
22:35 pmichaud Two empty arrays should not have the same address if they are different PMCs.
22:36 cotto I don't think we have cow arrays either.
22:38 jonathan I fear that patch also makes assumptions about what subclasses of get_pointer will do also.
22:38 Whiteknight pmichaud, not necessarily. There are two different semantics at play here
22:38 jonathan erm, subclasses will do with get_pointer
22:38 Whiteknight one is the location of the PMC structure itself, and one is the location of the underlying data.
22:38 Whiteknight The second can be the same between for two new PMCs if the data is NULL in both
22:39 Whiteknight the former obviously can't be
22:39 Whiteknight I want to separate the two semantics and give a separate opcode to each that can both be used consistently
22:39 pmichaud That requires a deprecation cycle.
22:40 jonathan Additionally, it's wrong.
22:40 jonathan "Please give me your guts." Yeah, bye encapsulation, hi future segfaults...
22:40 Whiteknight jonathan: I don't agree. It's wrong to shoehorn to different semantics into the same get_addr op
22:40 Whiteknight lots of other PMCs already use get_pointer and set_pointer for various other uses
22:41 jonathan Yeah. At least one of them last time I saw it has "KLUDGE ON THE CHOPPING BLOCK" written above it too...#
22:42 Whiteknight okay, back up and look at the current situation: Several PMCs define all sorts of custom behaviors for get_pointer, and that's directly exposed by the get_addr opcode
22:42 jonathan I always saw get_pointer as useful if, for example, you were proxying for another PMC and wanted to hand back the address or something else you were proxying.
22:42 Whiteknight we can't expect get_addr to be used to return the unique memory address of the PMC if it doesn't do that for all types
22:43 jonathan In general, I also am rather fearful of get_pointer as a vtable generally.
22:43 Whiteknight I don't always like it either, I definitely don't like that it's so easily exposed to PIR through the get_addr op
22:43 Whiteknight It has plenty of legitimate uses internally
22:44 jonathan Imagine I override it in a PIR subclass (if possible). I return 0. Something else grabs it and dereferences...boom.
22:44 pmichaud at any rate, we need some way of uniquely identifying a PMC
22:44 jonathan From what I can see, your legitimate use was "breaking a PMC's encapsulation".
22:44 Whiteknight well the easy solution to that is not to allow get_pointer (or set_pointer) to be overridden from PIR
22:44 Whiteknight pmichaud: yes. I am proposing a second single-purpose opcode for that
22:45 pmichaud but not "get_addr"?
22:45 Whiteknight PMCs like Sub and Continuation use get_addr to point to the underlying opcode_t offsets
22:45 Whiteknight so you would have those PMCs not returning unique values from it either
22:45 jonathan Grr.
22:46 Whiteknight as it is, we absolutely can't guarantee that get_addr will return anything unique, so I say we add a new op that does make that guarantee
22:47 pmichaud fair enough.  Just let me know what it becomes so we can fix Rakudo to match.
22:47 Whiteknight do you have a preference for what to call it?
22:48 jonathan Aye. Looking around, I concede that get_pointer is used for all kinds. :-|
22:48 pmichaud "get_addr"  seems most appropriate .  :-)
22:48 pmichaud but if that isn't available, then "get_pmc_addr"
22:48 cotto get_self_addr?
22:48 pmichaud theres no "self" here.
22:48 jonathan If get_pointer is going to stay, I'd really like it to be as hidden from PIR as possible...
22:48 Whiteknight pmichaud, that's fair, We'll just have to rename all other uses of get_addr (like for Continuation PMCs) to something else, which beggs the question about what to call that
22:49 pmichaud well, I suspect any renaming is likely to be problematic.
22:49 Whiteknight jonathan: I agree with that
22:49 jonathan Do we *need* the current semantics of get_addr from PIR?
22:49 Whiteknight jonathan: that I am aware of, only for the Sub and Continuation PMCs
22:49 Whiteknight and the ExceptionHandler, I think
22:49 pmichaud I suspect the bigger question is whether or not anything uses set_addr
22:49 jonathan I just saw that...
22:50 pmichaud currently it's used for exception handler setting.
22:50 pmichaud We don't have a way to set the return address of an exception handler except via set_addr
22:50 jonathan erm.
22:50 jonathan Ouch.
22:50 Whiteknight if we kill set_addr, we could make a method on the ExceptionHandler/Continuation PMCs to set the addres offset
22:50 pmichaud I don't think address offsets can be passed to method calls.
22:50 pmichaud or subroutine calls.
22:50 purl subroutine calls are pretty slow in Parrot right now, comparatively speaking.
22:51 pmichaud I could be wrong about that, though.
22:51 jonathan VTABLE_set_pointer(INTERP, context->lex_pad, context);
22:51 jonathan (In sub.pmc)
22:52 pmichaud set_addr seems to have been used extensively for getting offsets into pmc registers.
22:53 pmichaud I have to head off to my soccer game.
22:53 pmichaud I'll be back later tonight.
22:53 Whiteknight okay, later
22:54 nopaste "jonathan" at 85.216.157.73 pasted "segfault as a result of set_addr and set_pointer usage" (9 lines) at http://nopaste.snit.ch/16386
22:54 jonathan That's exactly where set_pointer/get_pointer and their exposure to PIR is going to get us.
22:54 contingencyplan_ joined #parrot
22:55 jonathan (That is, I can look at a usage of it quite randomly picked and craft a program to make Parrot segv in about a minute...)
22:55 Whiteknight jonathan: I agree with you 100%. If it weren't for the Sub PMC problems I would have removed the PIR-facing uses of them
22:55 Limbic_Region joined #parrot
22:55 jonathan We'd need a deprecation cycle, but I suspect it's something we should push for.
22:55 Whiteknight I'm willing to do all the pushing, I just wanted to talk to you guys to make sure my ideas were sane
22:55 jonathan I do still worry about get_pointer's encapsulation breaking behaviour, mind...
22:56 cotto particle, ping
22:57 Whiteknight jonathan: I worry too, but get_pointer isn't always used to "get my guts". Instead it's often used for "get my data that isn't something nice like a INTVAL or PMC*"
22:59 Whiteknight so it *generally* preserves encapsulation well enough, in most cases
22:59 Whiteknight <insert disclaimer about potential abuse>
23:01 jonathan It's not my call really, I just worry that the potential for abuse is a little high...
23:08 Whiteknight right, but we're going to fix it in baby steps
23:12 LylePerl Infinoid: I just tested for the realclean issue on XP/Strawberry Perl and I had the same problem with files being left... I thought you tested on XP/Strawberry and found it to be ok?
23:21 tetragon joined #parrot
23:31 bacek_ joined #parrot
23:44 kid51 joined #parrot
23:52 Infinoid msg lyleperl I did.  I think I need a list of exact steps to reproducd it
23:52 purl Message for lyleperl stored.
23:55 Infinoid msg lyleperl To be specific, I tried all kinds of combinations, with and without rakudo and realcleaning in random orders, and in each case, the parrot checkout no longer had a blib/lib and no longer had a src/ops/*.c.
23:55 purl Message for lyleperl stored.

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

Parrot | source cross referenced