|
Parrot 5.7.0 "Azure-rumped Parrot" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC Set by moderator on 31 August 2013. |
|||
|
00:08
TonyC joined
00:12
Psyche^ joined
00:26
kid51_ joined
|
|||
| Coke | in that foo is a sub that is immediately run, and is also saved for later? aye. | 00:33 | |
|
00:48
TonyC joined
01:08
kid51 joined
01:15
benabik joined
03:25
eternaleye joined
03:38
gtodd joined
04:00
preflex joined
04:04
preflex_ joined
05:14
eternaleye joined
05:41
denisboyun joined
05:50
PacoAir joined
06:35
FROGGS joined
06:41
denis_boyun joined
07:43
woosley joined
08:22
FROGGS joined
|
|||
| dalek | kudo/nom: 367963a | (Elizabeth Mattijsen)++ | src/ (20 files): Sync class attributes comments between BOOTSTRAP and P6 modules for convenience |
08:22 | |
|
08:23
woosley joined
09:13
woosley joined
09:28
FROGGS joined
09:52
denisboyun joined
|
|||
| dalek | kudo/nom: 36343bc | (Elizabeth Mattijsen)++ | src/core/Str.pm: We shouldn't be using deprecated methods in the settings ourselves |
11:39 | |
|
12:10
denis_boyun_ joined
12:33
rurban joined
13:08
benabik joined
13:13
PacoAir joined
|
|||
| dalek | kudo/nom: f4a21d6 | (Elizabeth Mattijsen)++ | src/core/ (4 files): Proof of concept for is DEPRECATED handling, in settings and outside of it |
13:18 | |
|
13:30
PacoAir joined
13:58
FROGGS joined
14:17
bluescreen joined
14:45
bluescreen joined
16:26
Tene joined
16:39
bluescreen joined
16:50
FROGGS joined
|
|||
| dalek | kudo/nom: 7e2d8bc | (Tobias Leich)++ | src/Perl6/Actions.nqp: support @() and %() shortcuts |
18:16 | |
| Util | Zefram: I am having trouble imagining a :immediate sub returning anything. Since it runs during compilation, who receives the return value? | 18:27 | |
| Would you please post a Gist or Nopaste of your code, trimmed down to just show this issue? | 18:28 | ||
|
18:30
denisboyun joined
|
|||
| Util | If your assumption is that an :immediate sub that returns a subref gets automatically *replaced* by that reffed-sub, then No, I do not believe that such a replacement occurs, not is supposed to occur. | 18:30 | |
| Coke | Util: there is a syntax for that, but I think it's .constant | 18:37 | |
| :immediate just runs now (but also leaves the compiled sub where you'd find it without :immediate). I think. | 18:38 | ||
| Util | Coke: .const ? | 18:52 | |
| Zefram | my issue was that the sub is available in *two* places, only one of which gets replaced by the result of the immediate execution | 19:20 | |
| paste.scsys.co.uk/269783 is the test case | 19:22 | ||
| it outputs baz/bar, whereas I'd naively expected baz/baz | 19:23 | ||
| close examination of the documentation reveals a difference in terminology, between "... replaces the sub in the constant table" and "... in current namespace", which is possibly referring to this difference | 19:26 | ||
| it'd be clearer to explicitly talk about the constant namespace, in which the :immediate sub gets replaced by its result, and to make clear that that's separate from the namespaces accessed by get_global | 19:28 | ||
| I'm still not clear on the extent and use of what I'm calling the "constant namespace". does it exist only in the assembler? | 19:29 | ||
|
19:45
Timbus|Away joined
19:47
PacoAir_ joined,
dngor_ joined
19:48
Liz joined
19:49
kshannon joined,
rurban joined,
ivan joined,
Khisanth joined,
szbalint joined,
Hunger joined
19:50
Tene joined,
patspam joined
19:51
cotto joined
20:09
Tene joined
|
|||
| Util | Zefram: Hmmm. Removing ":immediate" changes the output to bar/bar . I need to look at this deeper. | 20:16 | |
| Zefram | the behaviour without :immediate is simple and unsurprising. the description of :immediate led me to expect baz/baz, i.e. that the name "foo" would consistently refer to the sub that is principally named "bar" | 20:18 | |
| Util | Yes, I see that I was reading only from book/pir/ch06... , instead of pdd19. I am getting caught up now. Sorry for the confusion. | 20:19 | |
| Zefram | ah, I hadn't looked in docs/book at all yet. the description of :immediate there doesn't mention the replacement behaviour at all | 20:22 | |
| Util | Zefram: For another datapointcompiling your code to .pbc, then running it. I get baz \\n Null PMC access in invoke() | 20:35 | |
| Zefram: For another datapoint, try compiling your code to .pbc, then running it. I get baz \\n Null PMC access in invoke() | |||
| To compile then run: parrot -o foo.pbc foo.pir; parrot foo.pbc | 20:36 | ||
| Zefram | I get the same. interesting | ||
| some of the modifiers are explicit about having different behaviour between compilation/loading/running, but :immediate doesn't say anything about that sort of thing | 20:37 | ||
| Util | Zefram: It looks to me like a bug in PackFile_fixup_subs (and its kin). Will you file a bug report for us? | 20:39 | |
| Zefram | w00t | ||
| where's the bug tracker? | |||
| Util | (Hint: you can cut-and-paste this IRC conversation!) | ||
| Zefram: On GitHub, but please try the `parrotbug` program in your Parrot dir first. | 20:41 | ||
| Zefram | ok | ||
| Util | Zefram: For future reference: github.com/parrot/parrot/issues?state=open | ||
| Zefram | huh, severity defaults to critical. seems a bit pessimistic | 20:42 | |
| Util | Zefram: Indeed. I don't see any way to change that default, though. | 20:47 | |
| Zefram | oh, no filing by email? | 20:53 | |
| hrm, I'm not seeing an obvious submission form on the github web page that parrotbug pointed me at | 20:54 | ||
| "New Issue" link goes to a page that invites me to sign up, presumably to github | 20:55 | ||
| sorry, too much kool-aid | |||
| I'll happily email the report out if you give me an address, but I'm not going to create an account on anything just to report bugs | 20:56 | ||
| Util | Zefram: Fair enough. I am PM'ing you my email address, and I will be your filing-my-email bot :) | 21:01 | |
| Zefram | thanks | ||
| Util | yw | ||
| s/my/by/ | |||
| Thank *you* for finding the oddity, and following it through to the point that our community benefits. | 21:03 | ||
| Zefram | mailed | ||
|
21:19
bluescreen joined
|
|||
| dalek | p/lazy-vmhash: f7c396a | (Donald Hunter)++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/VMHash (2 files): Lazy allocation of HashMap for VMHash storage on JVM. |
21:54 | |
| p: f7c396a | (Donald Hunter)++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/VMHash (2 files): Lazy allocation of HashMap for VMHash storage on JVM. |
21:56 | ||
| p: ec8898f | donaldh++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/VMHash (2 files): Merge pull request #134 from perl6/lazy-vmhash Lazy allocation of HashMap for VMHash storage on JVM. |
|||
| Zefram | another issue: some of the documentation around errorson/errorsoff indicates that these flags are dynamically scoped (which my experimentation confirms), and says that's probably a bad idea | 22:14 | |
| I can tell you it's *definitely* a bad idea | |||
| whether arg count errors should be ignored is generally a question of HLL semantics, hence basically lexically scoped | 22:15 | ||
| to get the semantics it's expecting, with dynamic scoping of these flags a sub can't rely on its calling context, so it has to set the flags explicitly itself to whatever it needs | 22:16 | ||
| but if it calls another sub, in doing so it may have screwed up the flags for that other sub | 22:17 | ||
| the well-behaved way would seem to be to set the flags as one needs them oneself but change them back when calling other subs, to leave the dynamically-scoped state unchanged (so that the well-behaved sub is transparent) | 22:18 | ||
| this doesn't work for two reasons | |||
| firstly, the flags are write-only (absent extensions written in C), so restoration is impossible | 22:19 | ||
| secondly, I don't think you can separate the flag state that you pass to your callee from the flag state that will affect your reception of results from that callee | 22:20 | ||
| so it's a nasty misfeature | |||
| please change it so that the flags are attached to stretches of bytecode rather than to dynamic scopes | 22:21 | ||
| (it could have been worse, though. the documentation for the ops doesn't mention the scoping, giving the impression that they're interpreter-global) | 22:28 | ||
| Util | Zefram: Mail not yet received, but my forwardin service has been sluggish today; it should get here soon | 22:33 | |
| Re: errors(on|off), I see your point, but I have not spent enough time on it to be sure it is not in conflict with another design goal. | |||
| Zefram | hmm, think I've found another bug: args being supplied to a nullary sub don't generate an exception | ||
| Util | I will be glad to make a Enhancement ticket. Could you point to the doc you mentioned (to save me time)? | ||
| Also, can you provide code that demonstrates how wrong the current behavior is? | 22:34 | ||
| Code really helps everyone who reads such ticket up to speed quickly enough for them to *want* to participate in the enhancement. | |||
| Zefram | I'll send you parrotbug reports for these | ||
| Util | Zefram: Thanks. I will make tickets for the two discussed, and your nullary-sub-args too. | 22:35 | |
|
23:05
kid51 joined
|
|||
| Coke | nullary sub was a feature | 23:38 | |
| Zefram | oh? | ||
| Coke | back when the dispatch stuff was added. There is/was an old ticket about it. | ||
| and/or discussion | 23:39 | ||
| Zefram | I notice that nullary returns get strict checking, if result checking is enabled. failure of parity between the two types of continuation | ||
| Coke | github.com/parrot/parrot/issues/600 | ||
| 4 years ago == "when we switched bug tracking systems one of the 2 times we did it" | 23:40 | ||
| masak:perl6::old Coke::parrot | 23:41 | ||
| Zefram | Util: I've mailed you about nullary sub and error flags (with much more discussion in the latter) | 23:43 | |
| Coke | Util: see ticket 600 | 23:44 | |
| Util | Zefram: Thanks! Nothing received yet; will check back shortly | ||
| Coke: Thanks for the #600 pointer | 23:45 | ||
|
23:45
kid51_ joined
|
|||
| Zefram | the mail messages have left my system | 23:46 | |