Camelia, the Perl 6 bug

IRC log for #parrot, 2009-02-25

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:13 dalek parrot: r36987 | NotFound++ | trunk/examples/embed/Makefile:
00:13 dalek parrot: [examples] embed/Makefile fix
00:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36987/
01:00 HG` joined #parrot
01:22 TiMBuS joined #parrot
02:45 dalek rakudo: 5944501 | pmichaud++ | t/harness:
02:45 dalek rakudo: Updated harness that doesn't rely on Parrot::Test::Harness.
02:45 dalek rakudo: This version doesn't honor the --jobs option; patches welcome
02:45 dalek rakudo: to re-add that feature.  Also needs testing on Win32.
02:45 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​944501430c79ff16647469d383750c4a301bd16
02:45 shorten dalek's url is at http://xrl.us/behgac
02:52 dalek tracwiki: v53 | jimmy++ | WikiStart
02:52 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=53&action=diff
02:52 shorten dalek's url is at http://xrl.us/behgbm
02:56 jimmy joined #parrot
03:12 dukeleto joined #parrot
03:32 kid51 joined #parrot
03:41 janus joined #parrot
04:25 dalek parrot: r36988 | jkeenan++ | trunk/examples/embed/lorito.c:
04:25 dalek parrot: Enforce C coding standards re (a) no space between function name and opening
04:25 dalek parrot: parenthesis; (b) no hard tabs.
04:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36988/
04:38 Nom joined #parrot
04:43 Coke_afk allison++ # patches for partcl.
04:46 allison Coke: I figured the best way to test building from an installed parrot was on real languages :)
04:52 dalek tracwiki: v54 | coke++ | WikiStart
04:52 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=54&action=diff
04:52 shorten dalek's url is at http://xrl.us/behgqb
04:57 Coke what is the proper way to link to another pod document? podchecker is giving me crap about L<foo/bar/baz.pod>
04:57 Coke (even after escaping the /'s)
04:57 jimmy let me do that
04:58 Coke file://foo/bar/baz.pod works. Good enough for now.
04:59 dalek tracwiki: v55 | jimmy++ | WikiStart
04:59 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=55&amp;action=diff
04:59 shorten dalek's url is at http://xrl.us/behgqs
05:00 allison Coke: podchecker is b0rken
05:00 allison Coke: linking to a file path is fine
05:00 Coke is it going to HTMLify properly?
05:00 Coke (right now I have L<file://docs/project/support_policy.pod>)
05:00 Coke should that just be L<docs/project/support_policy.pod> ?
05:01 Coke or even s/\.pod//?
05:01 allison Coke: oh, is that the Pod::Simple that's checked into Parrot? because that version is about 6 years old
05:01 allison Coke: include the .pod, the rest should be fine
05:01 Coke which podchecker
05:01 Coke /usr/local/bin/podchecker
05:01 Coke which doesn't seem to respect -v or --version.
05:02 allison Coke: so, probably whatever was installed with perl, in whatever version system perl is
05:02 Coke /usr/local/bin is probably a custom one I installed. (Osx prefers /usr/bin for sys stuff, IIRC.)
05:02 allison Coke: if it's pre 5.10.0, then it's Pod::Parser, which is really broken
05:03 dalek tracwiki: v1 | coke++ | Deprecation
05:03 dalek tracwiki: https://trac.parrot.org/parrot/wiki/D​eprecation?version=1&amp;action=diff
05:03 shorten dalek's url is at http://xrl.us/behgqu
05:03 dalek tracwiki: v56 | jimmy++ | WikiStart
05:03 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=56&amp;action=diff
05:03 shorten dalek's url is at http://xrl.us/behgqw
05:07 dalek parrot: r36989 | coke++ | trunk/DEPRECATED.pod:
05:07 dalek parrot: [docs] Eliminate some developer-specific verbiage; this is meant to be our user-facing deprecation notice.
05:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36989/
05:15 dalek parrot: r36990 | coke++ | trunk/docs/project/release_manager_guide.pod:
05:15 dalek parrot: [docs] remove old list of stable release versions, just point to recently added list; also remove now-incorrect line about version #'s depending on features. They're just numbers.
05:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36990/
05:23 dalek parrot: r36991 | coke++ | trunk/DEPRECATED.pod:
05:23 dalek parrot: [docs] all the old development releases no longer matter; we'll remove them if we can before 1.0, or else we'll update this file before the release to mark them as [eligible in 1.4] (a change from [post 1.3])
05:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36991/
05:28 Coke allison: that change to DEPRECATED.pod look ok to you?
05:28 Coke hopefully more clear.
05:31 allison Coke: what does eligible in 1.4 mean?
05:31 Coke eligible for removal.
05:31 allison Coke: can be removed before the 1.4 release or after the 1.4 release?
05:31 Coke I can add a note to the top of the doc.
05:31 Coke I mean in, so "just before"
05:31 Coke it's from a user's standpoint, not a developers.
05:32 allison hmmm...  may be clearer to say "AFTER 1.0"
05:32 Coke so in svn, at any point after 1.3 is cut but before 1.4 is. from a user's standoint, it'll be in 1.3, but might not be in 1.4
05:32 allison because those features can be removed at any point after 1.0
05:32 Coke ... not as I understand things.
05:33 allison (we're not delaying things until just before the release)
05:33 Coke as I understand it anything deprecated when 1.0 is cut CANNOT be removed until 1.4
05:33 allison chromatic or pmichaud had a good write up
05:33 Coke ok. I officially give up. =-)
05:34 allison if it was deprecated before 1.0, it can be removed immediately after 1.0
05:34 Coke then docs/project/support_policy.pod should be updated to be less optimistic
05:34 allison but, chromatic added a note that we may delay deprecations in some cases if they were entered late in the cycle
05:34 Coke then what is the point of the stable releases?
05:35 allison the point is that someone can go on using 1.0 until 1.4 or 2.0, and ignore all the monthly releases
05:35 allison if they do that, then they got the deprecation notice in 1.0, and know to expect a change in 1.4
05:36 allison (if they didn't get the deprecation notice in 1.0, then we have to wait until they get the deprecation notice in 1.4, and then they'll see the feature is gone in 2.0
05:37 allison the tricky part is that we're dealing with two completely different audiences
05:37 allison the developers (who track monthly releases) and the users (who track stable releases)
05:37 Coke If you're referring to a discussion or meme that occurred at the PDS (different audiences), I have no idea.
05:37 Coke developers of... parrot?
05:38 allison no, not an earlier meme, I'm just trying to explain why the releases are slightly more complex than the average project
05:38 allison developers of parrot or developers of languages who want to hug close to the wire
05:38 Coke I would posit that the explanation should probably be documented somewhere.
05:38 Coke developers of parrot I would expect to still track svn.
05:39 allison yes, but we make monthly releases anyway
05:39 Coke I think my notice of "eligible" still makes sense if I bump it to the next monthly release /after/ the ``stable'' release.
05:39 allison it's a good development cycle, keeps us moving, gives a good point for bug fixing, etc
05:40 allison maybe it's just the word eligible that's confusing me
05:40 Coke no, my understanding didn't match what you're saying here.
05:40 allison the full sentence "This feature is eligible to be removed after the 1.0 release, but may be removed later" makes sense
05:41 Coke I thought that the plan was that 1.0, 1.1, 1.2, and 1.3 would not have ANYTHING removed, but perhaps mark things. If we were going to remove them, we'd remove them for the 1.4 release.
05:41 allison or "This feature is eligible to be removed at any point between the 1.0 release and the 1.4 release, but may be removed later"
05:41 Coke so that doc reflects my (wrong) understanding.
05:42 allison ah, okay, that understanding is probably because we've mostly been talking about deprecations in terms of the deprecation releases
05:42 allison but, for the most part, I'd like to have as many months of testing as possible after removing a feature before the next stable release
05:43 allison so, I'd actually prefer most removals to happen soon after 1.0, rather than just before 1.4
05:43 Coke Yes, that's nice for /developers/, sure.
05:43 allison nice for users too
05:44 pmichaud the key feature about deprecation notices is not that we say when it will be removed, but the minimum time it will remain.
05:44 Coke not if you expect the users to upgrade every month, I'd wager.
05:44 allison the last thing you want is to make major changes to the code just before a bit release
05:44 allison we don't expect users to upgrade every month
05:44 allison users should be using 1.0 or 1.4, not the monthly releases
05:44 Coke that really should be written down somewhere, no?
05:45 allison I'd say it's pretty clear from the fact that 1.0 and 1.4 are "stable" releases while the others are "devel" releases
05:45 Coke allison: that's one of the differences between your wording and chromatics.
05:45 Coke (I was looking for others before replying to your request0
05:45 Coke but that's a pretty big one.
05:45 Coke you say that they are devel releases; he says they are stable.
05:45 Coke that's a HUGE difference.
05:46 allison what, the monthly releases?
05:46 Coke yes.
05:46 allison okay, he's using the terms differently
05:46 allison (not in the perl 5 way)
05:47 allison but, the simple fact is that 1.0 and 1.4 will be packaged, the monthly releases won't
05:47 Coke ok. this is all news to me.
05:47 allison and 1.0 and 1.4 will go in the "stable" directory of the ftp server, the monthlies won't
05:47 allison then we haven't explained it well enough
05:48 pmichaud I recommend we simply use the terms "monthly release" and "stable release"
05:48 allison Coke: if you can explain it better, please do
05:48 pmichaud or, we could say "development release"
05:48 allison pmichaud: sounds good
05:48 Coke allison: every time I think I understand what's going on, I'm wrong. I'm NOT the person to explain what YOU are thinking. =-)
05:49 allison Coke: ah, but if you explain it as you understand it, then we can revise as a group
05:49 Coke you have my input here.
05:49 allison Coke: I tried explaining it, and people are still confused :)
05:49 Coke and on list.
05:49 purl well, on list is a good place for such things (mailto:perl6-internals@perl.org)
05:49 allison purl: forget on list
05:49 purl allison: I forgot on list
05:50 jimmy like ubuntu? rc1,rc2? alpha2?
05:52 allison jimmy: ?
05:52 jimmy follow it: we could say "development release"
05:53 allison jimmy: yes, I think "development release" is clearest
05:54 nopaste "pmichaud" at 72.181.176.220 pasted "proposed text revision for first section of support_policy.pod" (10 lines) at http://nopaste.snit.ch/15712
05:55 pmichaud (working on the deprecation section next)
05:58 allison pmichaud: looks good
05:58 purl O_O
05:59 eternaleye joined #parrot
05:59 jimmy Emphasizing 'development release' or 'stable release' ++
05:59 nopaste "pmichaud" at 72.181.176.220 pasted "proposed deprecation text" (12 lines) at http://nopaste.snit.ch/15713
06:00 pmichaud Coke: do my versions of the text make sense to you?
06:00 Coke s/That is/For example/
06:01 Coke I think having all the examples is probably too verbose.
06:01 Coke hang on.
06:01 purl hang on. is this actually "session is still there but user has been deleted" ?
06:01 dalek parrot: r36992 | coke++ | trunk/DEPRECATED.pod:
06:01 dalek parrot: [docs] Update to match info from allison on IRC; my earlier interpretation was flawed.
06:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36992/
06:02 Coke honestly, keeping chromatic's first 2 sentences and deleting the rest of the paragraph is fine.
06:02 Coke especially if stable in /that/ sentence means what stable means in allison's doc.
06:02 pmichaud I'm not a fan of the term "milestone release", though.
06:03 pmichaud it's not defined if we use the version of the text I just gave for the first section.
06:03 Coke pmichaud: if you delete the remaining sentences, "milestone" doesn't appear.
06:03 Coke We will regularly deprecate features and remove them.  All deprecations must
06:03 Coke have an announcement in at least one stable release before removal.
06:03 pmichaud oh, I kept once sentence too many.
06:04 pmichaud is it clear without the examples?  or are people likely to not accept what it says on face value and try to read more into it?
06:04 Coke (your version also changes the subject from "we" to "parrot")
06:04 Coke the person. that's the word I meant.
06:04 Coke perhaps a small explanation, ala:
06:04 pmichaud yes, I follow the difference.
06:05 pmichaud I agree, "we" is better.
06:05 pmichaud (in keeping with the rest of the document)
06:05 Coke I don't mind either way as long as it's consistent. I don't think we're consistent through the docs.
06:05 pmichaud well, since it's a "support policy", "we" seems appropriate here.
06:06 pmichaud since support comes from people or a team or something.
06:09 pmichaud anyway, if we eliminate the version numbers from the supprt policy document, it makes a _lot_ more sense.
06:09 nopaste "coke" at 72.228.52.192 pasted "longer than I thought" (4 lines) at http://nopaste.snit.ch/15714
06:09 pmichaud (I'm not saying eliminate version numbers, I'm just saying don't use them in the support policy at this time)
06:09 pmichaud coke:  that works for me.
06:10 Coke I would rather just refer to stable and development, if we now agree on what they mean. =-)
06:10 pmichaud I somehow prefer "monthly" to "development".
06:10 pmichaud but I can see the other side of that coin.
06:10 Coke if the plan is for users to not install them in prod, I'd stick with dev.
06:10 Coke monthly is neutral in terms of quality, so I default to "just as good."
06:11 Coke We will regularly deprecate features and remove them.  All deprecations will
06:11 Coke be announced in at least one stable release before they are removed. Once a
06:11 Coke stable release announces a deprecated feature, it is eligible for removalin any subsequent release, whether development or stable.
06:11 Coke gah.
06:11 Coke sorry.
06:11 diakopter removalin
06:11 Coke docs/project/*rel*/ uses different terminology, calling them "deprecation points"
06:11 pmichaud if we do that, then the first paragraph I proposed needs some additional text (just a sec)
06:14 allison Coke: it's fine to change that to "stable release" if we're standardizing terminology
06:14 allison stable release == deprecation point
06:14 nopaste "pmichaud" at 72.181.176.220 pasted "proposed deprecation text" (12 lines) at http://nopaste.snit.ch/15715
06:15 allison pmichaud: well, the thing about "monthly release" is that the stable releases are also monthly releases
06:15 pmichaud sure, I get that.
06:15 Coke deprecation point is a confusing name.
06:15 pmichaud agreed on confusion of "deprecation point"
06:15 allison Coke: agreed, we can eliminate "deprecation point"
06:16 pmichaud my last nopaste is actually proposed for the first paragraph, introducing the notion of "development release"
06:16 pmichaud another term for the non-stable releases might be "interim release"
06:16 mberends joined #parrot
06:17 Coke if we mention january and july, we should mention that 1.0 is 'special'
06:18 jimmy pmichaud: Were there any news about rakudo like parrot news file?
06:18 Coke See, I've been thinking of the releases as /beginning/ with a .0 and ending with a .12; but they really start with .1 and end with .0
06:19 chromatic joined #parrot
06:19 Coke inverting the release numbering is very confusing.
06:19 Coke I have to go to bed.
06:19 allison Coke: something like "1.0 in March, and the subsequent releases in January and July"
06:19 Tene joined #parrot
06:21 pmichaud I need sleep also.
06:21 pmichaud afk for a while -- bbl.
06:28 cotto joined #parrot
06:29 cotto joined #parrot
06:30 cotto joined #parrot
06:36 Ademan joined #parrot
07:03 mohan joined #parrot
07:03 mohan left #parrot
07:11 uniejo joined #parrot
07:23 cotto allison, ping
07:24 allison cotto: pong
07:24 cotto I Coke correct that the Slice and Bound_NCI PMCs can be excised after 1.0?
07:24 allison the way the deprecation cycles work, it they can be removed immediately after the "stable" release that includes the deprecation notice, yes
07:25 cotto got it
07:25 cotto For some reason I thought it'd have to wait until after 1.4.
07:25 allison they might not be removed until after 1.3, but they're eligible to be removed at any point after 1.0
07:25 cotto understood
07:25 purl Roger Roger.
07:26 cotto thanks
07:26 allison cotto: the explanation isn't entirely clear yet, we're still working on it
07:40 masak joined #parrot
07:50 mj41 joined #parrot
08:17 szabgab joined #parrot
08:25 dalek rakudo: 7f8ba6f | (Moritz Lenz)++ |  (5 files):
08:25 dalek rakudo: Merge branch 'move_split_to_any_str'
08:25 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​f8ba6fbb8c098666a6061d640f7fb6a051a5607
08:25 shorten dalek's url is at http://xrl.us/behg33
08:46 Eevee_ joined #parrot
08:57 dalek parrot: r36993 | fperrad++ | trunk/tools/dev/mk_inno_language.pl:
08:57 dalek parrot: [inno-setup] rakudo is a special case, because perl6.exe
08:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36993/
09:05 khatar joined #parrot
09:06 cotto joined #parrot
09:26 mberends joined #parrot
10:23 mberends joined #parrot
10:29 elmex joined #parrot
10:49 pancake joined #parrot
10:50 pancake im getting segfaults on many languages in parrot at 0xb7b93d18 in do_thaw (interp=0x804f040, pmc=0x8151e78, info=0xbfac6a64) at src/pmc_freeze.c:1402
10:50 pancake is this a known issue?
10:50 pancake (svn)
10:51 contingencyplan joined #parrot
10:51 moritz not known to me (but that doesn't mean anything)
10:52 samlh joined #parrot
11:33 PacoLinux joined #parrot
11:46 s1n joined #parrot
11:54 dalek parrot: r36994 | fperrad++ | trunk (3 files):
11:54 dalek parrot: [doc] allow creation of a Compiled HTML Help (.chm) from docs/html
11:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36994/
12:07 dalek rakudo: d912db6 | jnthn++ | src/classes/Protoobject.pir:
12:07 dalek rakudo: Make proto-objects respond more correct to WHICH, which fixes === on proto-objects and thus resolves RT#62902.
12:07 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​912db646a294e6d579a6b768bf283718c84fab0
12:07 shorten dalek's url is at http://xrl.us/behhfi
12:10 dalek parrot: r36995 | fperrad++ | trunk/tools/docs/mk_chm.pl:
12:10 dalek parrot: [chm] add a Title
12:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36995/
12:12 dalek rakudo: 23e8e02 | jnthn++ | src/classes/Whatever.pir:
12:12 dalek rakudo: Whatever isa Any, not Object (per S02).
12:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​3e8e0240ca2952fe93382f43d6f1b00ce09d821
12:12 shorten dalek's url is at http://xrl.us/behhfx
12:15 PacoLinux joined #parrot
12:20 dalek rakudo: 798236b | (Moritz Lenz)++ | build/Makefile.in:
12:20 dalek rakudo: since t/harness now uses ./perl6, we should depend on it for 'make spectest'
12:20 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​98236bac9ae86135c6e6c3023f3c7a7a9e9d01b
12:20 shorten dalek's url is at http://xrl.us/behhgb
12:24 dalek rakudo: bad46f7 | (Moritz Lenz)++ | build/Makefile.in:
12:24 dalek rakudo: [build] 'make test' should also depend on the fake executable
12:24 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​ad46f7ddb41f3bd73d57e4496552161d84c7738
12:24 shorten dalek's url is at http://xrl.us/behhgw
12:32 rg1 joined #parrot
12:42 mberends joined #parrot
13:16 jimmy joined #parrot
14:16 dalek rakudo: a5bad9a | jnthn++ | src/parser/ (2 files):
14:16 dalek rakudo: Allow bare sigils in a signature, which gets some more spectests passing, resolves RT#63146 and brings us another tiny step closer to STD.pm.
14:16 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​5bad9a6bf4b1676c8e4a3199d3fe356602c26cc
14:16 dalek rakudo: dfe942d | jnthn++ | build/Makefile.in:
14:16 shorten dalek's url is at http://xrl.us/behhon
14:16 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
14:16 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​fe942d5790ee9e162ac0fa5613fdb3bd2e1ef58
14:16 shorten dalek's url is at http://xrl.us/behhop
14:17 gryphon joined #parrot
14:39 dalek rakudo: f9b9041 | jnthn++ | src/classes/List.pir:
14:39 dalek rakudo: Fix zip operator when there's a list containing a range on one side. Patch courtesy of bacek++.
14:39 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​9b90413a7a3bca69c3d715eba495a565bc01500
14:39 shorten dalek's url is at http://xrl.us/behhqk
14:48 Andy joined #parrot
14:54 Coke only obstacle to removing random is to cleaup a test in t/op/gc.t
15:03 rafl joined #parrot
15:05 Tene joined #parrot
15:19 cas joined #parrot
15:22 masak joined #parrot
15:24 dalek rakudo: 59fcc4e | jnthn++ | src/classes/Grammar.pir:
15:24 dalek rakudo: .parse needs to pass along the fully qualified name of the grammar to PGE. (.WHO should make this easier in the future, OTOH maybe PGE needs to change and take the grammar class itself, so it can handle anonymous grammars too). Either way, this resolves RT#63462.
15:24 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​9fcc4e8ff37414071cf72b0643fcc483858ac34
15:24 shorten dalek's url is at http://xrl.us/behhue
15:26 dalek parrot: r36996 | NotFound++ | trunk/examples/embed/lorito.c:
15:26 dalek parrot: [examples] indentation fix
15:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36996/
15:53 Theory joined #parrot
16:09 contingencyplan joined #parrot
16:59 bacek joined #parrot
17:02 dalek parrot: r36997 | coke++ | trunk/docs (3 files):
17:02 dalek parrot: RT #49001 - update some uses of 'compilation unit' to 'subroutine'
17:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36997/
17:02 jonathan purl, alester?
17:02 purl i don't know, jonathan
17:02 jonathan purl, andy lester?
17:02 purl andy lester is already backing that change, so it's just a "does it actually work everywhere" quarantine period right now
17:02 jonathan ...I kinda wnated the email address, but anyway...
17:03 rg try http://petdance.com/
17:03 Andy jonathan: andy@petdanc.ecom
17:04 nopaste "jonathan" at 85.216.157.73 pasted "this patch works around double frees and infinite loops when we do exit destruction - review please..." (37 lines) at http://nopaste.snit.ch/15716
17:04 pmichaud oh, it's the *contexts* that get double-freed?
17:05 pmichaud I didn't know that.  I know a little about those.
17:05 jonathan pmichaud: Yes.,
17:06 jonathan pmichaud: I make it through the tests without hangs and segfaults with that patch.
17:06 pmichaud jonathan: yes, I can see why we were getting double-frees on contexts.  I thought the double-frees were coming from somewhere else.  Looking.
17:06 dalek parrot: r36998 | coke++ | trunk (2 files):
17:06 dalek parrot: Track a language specific RT so we can clean up parrot's queue.
17:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36998/
17:06 pmichaud (I'm very familiar with the context code after having done the lexicals re-impl)
17:08 Tene pmichaud: what's involved in getting commit privs on rakudo?
17:08 pmichaud Tene: you have commit to Parrot already, yes?
17:08 Tene Yes.
17:08 pmichaud I just need to know your github id.
17:08 Tene 'tene'
17:09 pmichaud Added.
17:09 Tene sweet
17:10 dalek parrot: r36999 | coke++ | trunk/examples/embed/Makefile.msvc:
17:10 dalek parrot: [distro] Fix properties on recently added file
17:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36999/
17:12 japhb joined #parrot
17:12 pmichaud jonathan: the following of the caller_ctx chain is bogus in destroy_context -- we currently don't refcount caller_ctx
17:13 pmichaud I think that's left over from when contexts were more stacklike.
17:14 dalek rakudo: f43750a | jnthn++ | src/ (2 files):
17:14 dalek rakudo: A bunch of changes to multiple dispatch, resolving a memory leak per cache-miss call and fixing multi method dispatch to walk the MRO as it should, which resolves RT#63442.
17:14 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​43750a41b22549bfaffd0c9526312e2eb5edca0
17:14 shorten dalek's url is at http://xrl.us/behh8e
17:15 pmichaud also, destroy_context appears to be missing any outer contexts that need freeing.
17:15 davidfetter joined #parrot
17:16 pmichaud I can come up with a different patch to try -- just a sec.
17:16 jonathan pmichaud: OK, awesome.
17:17 geof joined #parrot
17:19 nopaste "pmichaud" at 72.181.176.220 pasted "my version of avoiding double-free" (17 lines) at http://nopaste.snit.ch/15717
17:19 pmichaud untested as yet.
17:20 jonathan pmichaud: That's shorter than mine. ;-)
17:20 pmichaud yes, since Parrot_free_context already knows how to avoid double-free, just use it.  :-)
17:21 pmichaud Parrot_free_context also frees any contexts that the current context might have been referencing.
17:21 jonathan FTW
17:21 jonathan Compiles, testing it...
17:22 jonathan We might be able to close rather a lot of tickets with this... ;-)
17:22 pmichaud I totally never realized that the double-free issue was a context issue.
17:22 jonathan Me either until today
17:22 jonathan It was annoying me, so I was like, "right, out comes the C debugger"
17:22 pmichaud of course, all of this goes away when we have gc-able contexts, sometime in 2012.
17:23 jonathan And when it broke, it was right there in that bit of code...
17:23 jonathan In fact under the debugger it crashed with the double free rather than hung.
17:23 jonathan Yeah, I'd rather like to think that we can have a non-segv-ing Rakudo before 2012. ;-)
17:27 pmichaud It still bugs me somewhat that my laptop is 33% faster than my desktop.
17:27 jonathan pmichaud: Initial signs are good.
17:27 jonathan Heh. You know what *my* laptop is like.
17:28 Tene My old desktop was punted to basement server duties a few years ago.
17:28 Tene I haven't had a desktop in ages.
17:29 PerlJam pmichaud: sounds like you need to get a new desktop then to ease your mind :)
17:29 pmichaud actually, Tene's comment makes me realize that it would be incredibly simple to switch to using my laptop as my primary system
17:29 pmichaud when I ordered it I also ended up with a docking station somehow.
17:30 jonathan I sorta want a new laptop.
17:30 jonathan But they're so uncomfortable for me to use that I only do it when I'm doing conferences and hackathons.
17:30 jonathan Which means I only notice the slowness now and then.
17:30 jonathan And thus never get irked enough to shell out for something new.
17:32 pmichaud well, my laptop supposedly outputs 2048x1536 @ 75Hz, so display quality isn't an issue.
17:33 pmichaud it might be very interesting to move my desktop to full-time server duty.
17:34 mikehh joined #parrot
17:34 jonathan pmichaud: OK, your patch rocks. :-)
17:34 pmichaud glad to know I've done something right this month :-)
17:38 jonathan Yeah, given how many "X gives a great error AND THEN SEGFAULTS" tickets we have, you've probably just let us close as many RT tickets in one patch as I have in a months worth. :-P
17:40 jonathan pmichaud: If you have a clean "make test" from Parrot too, I'd say go ahread and apply it.
17:40 pmichaud I didn't do a 'make test' yet -- doing that now.
17:40 jonathan OK, great. :-)
17:40 jonathan Getting this sorted out before the release makes me *very* happy.
17:40 pmichaud same here.
17:41 jonathan And we can keep on using the fakeexecutable.
17:41 jonathan For make spectest.
17:41 pmichaud does the fakecutable pass all of the spectests on your box?
17:43 jonathan No
17:43 jonathan But it passes the same number as parrot perl6.pbc does.
17:43 jonathan (Some NaN related failures still.)
17:43 pmichaud okay.
17:43 jonathan So there's nothing specific to the fakeexecutable any more.
17:48 pmichaud all (parrot) tests pass, so committing fix.
17:50 jonathan Yay!
17:50 jonathan pmichaud++
17:50 pmichaud heh.  r37000 .  Nice round number.
17:51 jonathan Good number, for a good patch.
17:51 dalek parrot: r37000 | pmichaud++ | trunk/src/gc/register.c:
17:51 dalek parrot: [core]:  Eliminate double-free problem with contexts in fakecutables
17:51 dalek parrot: * ...and probably other places as well
17:51 dalek parrot: * jonathan++ for tracking down the source of the problem
17:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37000/
17:51 * pmichaud tests bumping up PARROT_REVISION
17:52 jonathan That might even be something we can tick off on the 1.0 todo list. ;-)
17:55 PerlJam I've been getting "fatal: read error (Connection reset by peer)" quite a bit when I do "git pull" for rakudo.  I wonder if github is having problems.
17:59 dalek parrot: r37001 | fperrad++ | trunk/config/gen/makefiles/docs.in:
17:59 dalek parrot: [doc] add a target 'book' that generate a HTML output (with Pod::PseudoPod)
17:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37001/
18:04 Coke msg fperrad i would recommend removing the explicit 'book' target and just having it built by default with 'make html'.
18:04 purl Sorry, I've never seen fperrad before.
18:04 dalek parrot: r37002 | fperrad++ | trunk/tools/docs/mk_chm.pl:
18:04 dalek parrot: [chm] add the content of book
18:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37002/
18:05 darbelo joined #parrot
18:05 Coke pmichaud: there's a deprecation ticket that I think is yours: any chance you can resolve https://trac.parrot.org/parrot/ticket/168 ?
18:07 pmichaud Coke++  # yes, I can resolve it.
18:08 dalek parrot: r37003 | fperrad++ | trunk/tools/docs/mk_chm.pl:
18:08 dalek parrot: [chm] CSS & logo are embedded in no relative path
18:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37003/
18:10 mberends joined #parrot
18:17 Coke seen tewk?
18:17 purl tewk was last seen on #parrot 5 days, 20 hours, 18 minutes and 33 seconds ago, saying: LOL  [Feb 19 21:58:21 2009]
18:18 Coke msg allison Regarding the deprecation policy; if we do not expect users to use interim releases, then we only need deprecation warnings for items that were available in milestone releases; if we add something in 1.1 and remove it in 1.2, no harm, no foul.
18:18 purl Message for allison stored.
18:19 Psyche^ joined #parrot
18:20 jonathan purl msg Tene if you get a spare moment, any chance you could take a peek at http://rt.perl.org/rt3/Tic​ket/Display.html?id=63430 ? kplzthx
18:20 purl Message for tene stored.
18:31 Eevee joined #parrot
18:38 jsut|work joined #parrot
18:38 dalek rakudo: f1f722e | (Patrick R. Michaud)++ | build/PARROT_REVISION:
18:38 dalek rakudo: Bump PARROT_REVISION to r37000, to avoid double-free issues in fakecutable.
18:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​1f722edd9ee6cccfbf7cb0fbbe08188b7b8a382
18:38 shorten dalek's url is at http://xrl.us/behijo
18:44 mberends joined #parrot
18:45 * Coke gets rakudo building from git.
18:50 * Coke accidentally builds it as root.
18:52 Coke should there be a SPECTEST_REVISION ala the PARROT_REVISION ?
18:52 mberends joined #parrot
18:54 PerlJam Coke: why exactly?  Shouldn't all the spec tests pass always?
18:55 cas joined #parrot
18:56 Coke yes, but parrot should also work for you all the time, too.
18:57 barney joined #parrot
18:57 Coke if failures in spectest are ok, then it doesn't matter. It's certainly less critical than marking the parrot revision.
18:57 jonathan Coke: The spectests are fudged per implementation.
18:58 jonathan Coke: And we have a white-list of ones we run.
18:58 Coke jonathan: (white list) ah, ok.
18:58 Coke so someone adding a test isn't going to randomly fail you.
18:58 jonathan Right.
18:58 jonathan Well, adding it to a test file we do run and not fudging it may.
18:58 Coke I miss TEST_JOBS=3 :|
18:58 jonathan But a new test file for a feature we don't do at all yet, no, we don't notice that.
18:59 jonathan It seems to work out fairly well so far.
18:59 sjn jonathan: have you heard from Linpro yet?
18:59 jonathan sjn: Yes - they're arranging my hotel.
19:00 jonathan And I'm still trying to work out various other bits on transport (e.g. what I want...going to drop in on a couple of other places en route to the conference)
19:00 sjn ok
19:00 sjn great
19:00 jonathan Might just say "OK, find me a flight back and I'll look after getting there" :-)
19:01 jonathan Anyway, things are getting worked out. :-)
19:01 jonathan Thanks for organizing.
19:01 sjn np
19:05 dalek rakudo: 7abe283 | jnthn++ | src/builtins/guts.pir:
19:05 dalek rakudo: Some tweaks to subsets, making sure they get their own metaclass and proto-object and respond as desired to .defined (with false). Other than that no intentional functional changes - the spectests don't point to any, at least.
19:05 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​abe283f528014b6a47111eefd85a90dc584a50e
19:05 shorten dalek's url is at http://xrl.us/behipg
19:05 dalek rakudo: 3484985 | jnthn++ | build/PARROT_REVISION:
19:05 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
19:05 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​484985276d05984975362512879a33a824a6f08
19:05 shorten dalek's url is at http://xrl.us/behipz
19:09 dalek rakudo: f934f32 | pmichaud++ | docs/spectest-progress.csv:
19:09 dalek rakudo: spectest-progress.csv update: 314 files, 7007 passing, 0 failing
19:09 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​934f322ff0ce83dafbf54432701908b47ae0097
19:09 shorten dalek's url is at http://xrl.us/behiq8
19:24 chromatic joined #parrot
19:51 dalek parrot: r37004 | fperrad++ | trunk/lib/Parrot/Docs/File.pm:
19:51 dalek parrot: [doc] find Title when modern style POD
19:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37004/
20:05 Coke ho, chromatic.
20:05 chromatic pong
20:05 cas_ joined #parrot
20:06 Coke had a conversation with allison last night about post-1.0; sounds like she is expecting end users to not install non-milestone releases; does this fit with your expectations?
20:07 Coke (so, a user might get a packaged 1.0 or 1.4, but 1.1 is mainly for folks doing development (of parrot or HLLs)
20:08 chromatic Users will do what users will do.
20:09 chromatic I don't think we can predict that.
20:12 Coke I'm trying to get a handle on what that means for our support policy.
20:13 Coke it sounds like allison's take is that if it's not a milestone release, we have no self-imposed restrictions other than our deprecation policy described in the support doc.
20:13 Coke so we could, theoretically, add something in 1.1 and remove it in 1.2 with no warning.
20:14 Coke (she didn't say that. I'm extrapolating)
20:16 chromatic I'm not sure that's the case.  I'll ask her.
20:16 Coke (one of the major differences between her vision document and yours is that you refer to stable releases, while she refers to development releases)
20:17 NotFound Coke: I think 'users' may mean 'distribution packagers'
20:17 Coke NotFound: yes. And as chromatic pointed out, there's no stopping them from doing whatever they want.
20:18 Coke but allison seemed to attach some weight to the milestone release in that regar.
20:18 NotFound Remember when redhat included a gcc version explicitly labeled as 'developers only'? ;)
20:18 chromatic Grr, no, she just said "They're developer releases."
20:18 Coke "regard"
20:18 purl "regard" is a good one.
20:19 Coke chromatic: http://www.parrot.org/news/vision-for-1_0 refers to them as 'development' releases.
20:19 Coke (it also has the older .5 releases)
20:20 NotFound It's sad that my proposal about using unix timestapms to mark deprecation dates was not acepeted ;)
20:20 chromatic I think that's silly and arbitrary.
20:20 Coke chromatic: which now?
20:22 jonathan chromatic: pmichaud and I managed to patch what was making Rakudo double-free on exit earlier today, if you didn't notice. :-)
20:22 cas joined #parrot
20:23 jonathan Also, we're running make spectest with the fakeexecutable now. Lots of leak testing. ;-)
20:23 NotFound jonathan: great!
20:23 jonathan Well, shutdown testing.
20:27 chromatic jonathan, I just talked to pm about that.
20:28 chromatic good work
20:29 Tene pmichaud: should pasttype "try" explicitly ignore return exceptions?
20:30 Tene pmichaud: or should rakudo be generating something other than pasttype try?
20:30 pmichaud Tene: I'm going to guess that rakudo should generate something other than pasttype try.
20:30 Tene Okay.
20:30 pmichaud or we need to augment the 'try' pasttype to be able to specify the things we want to catch.
20:32 Tene Are there any other exceptions that try {} doesn't get?
20:32 Tene Also, do we need to consult timtoady to confirm that return passes through try?
20:34 pmichaud probably.  But I suspect it has something to do with 'return' being tied to the enclosing sub's scope.
20:34 pmichaud i.e., so a 'try' wouldn't see it anyway.
20:34 rg i think last i looked rakudo wasn't generating pasttype try, but pushing handlers on blocks
20:35 Tene rakudo.past: try { say "foo" }
20:35 nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (164 lines) at http://nopaste.snit.ch/15718
20:36 rg ah nice. i guess it does :)
20:36 Tene rakudo.past: { say "foo"; CATCH { say "wtf" } }
20:36 Tene compare with that
20:36 Tene I'm not sure what the difference should be.
20:36 nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (212 lines) at http://nopaste.snit.ch/15719
20:36 Tene Also compared to:
20:36 Tene rakudo.past: try { say "foo"; CATCH { say "wtf" } }
20:36 nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (221 lines) at http://nopaste.snit.ch/15720
20:38 jonathan Isn't it that control exceptions are generally not caught by try?
20:38 jonathan But by CONTROL instead?
20:38 Tene So try ignores all control exceptions?
20:38 Tene I can do that.
20:39 Tene From what I remember of the specs, try() is equivalent to adding a CATCH { $! = $^a}
20:39 Tene to the block
20:39 Tene approximately?
20:40 jonathan It caches all exceptions, yes
20:40 pmichaud last I read the specs, 'try' itself was just syntactic sugar -- any block containing a CATCH can act as a try.
20:40 jonathan Though if you have a CATCH within it, that is what gets run.
20:40 jonathan But try { ... } will suppress any excetions from being thrown further an just put it into $!, AFAIR.
20:40 jonathan bbs - dinner
20:49 dalek rakudo: 9f3d289 | (Andy Lester)++ | build/Makefile.in:
20:49 dalek rakudo: Add a perlcritic target to the makefile
20:49 dalek rakudo: Signed-off-by: Stephen Weeks <tene@allalone.org>
20:49 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​f3d2892d6ccb6f92a35772ab8dea37c4235f91e
20:49 dalek rakudo: f9cb35e | (Andy Lester)++ | Configure.pl:
20:49 shorten dalek's url is at http://xrl.us/behi5k
20:49 dalek rakudo: modernize some code, and add error checking
20:49 dalek rakudo: Signed-off-by: Stephen Weeks <tene@allalone.org>
20:49 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​9cb35e0721f1462f545747ccc3182144862b40f
20:49 shorten dalek's url is at http://xrl.us/behi5n
20:59 * Coke wonders how tene did that.
20:59 Tene Coke: http://github.com/rakudo/rakudo/forkqueue
21:00 jonathan Did anyone else notice that if you say fork queue out loud quickly it...never mind.
21:00 Coke nose hit.
21:05 pmichaud my son has a math homework problem where we need to survey ten people on the following question.... so you guys are it.  :-)
21:05 pmichaud "What is your favorite snack: cookie, chips, candy, or cupcake?"
21:06 * rg votes cookie
21:07 * NotFound chips
21:07 Coke coke votes chips
21:07 pmichaud (thanks to all for participating)
21:07 * Coke also wonders if there is a writein!
21:07 pmichaud Matthew says "no writeins", sorry.
21:08 Coke curses.
21:08 cotto cookie
21:08 * pmichaud votes cookie
21:09 cotto (assuming he doesn't mean the HTTP-related kind)
21:10 dalek rakudo: 766d5d5 | (Vasily Chekalkin)++ | src/classes/Range.pir:
21:10 dalek rakudo: Anonimize VTABLE methods in Range
21:10 dalek rakudo: Signed-off-by: Jonathan Worthington <jnthn@jnthn.net>
21:10 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​66d5d5d98221075672e2a3e8adc880de7c166ed
21:10 shorten dalek's url is at http://xrl.us/behi9z
21:10 pmichaud need two more votes
21:11 pmichaud okay, just need one more
21:11 pmichaud actually, we can get the last vote from his sister.  Thank you all for participating!
21:11 jonathan .oO( Am I really the only one who voted candy?! )
21:12 mikehh joined #parrot
21:13 Coke (freak)
21:14 pmichaud jonathan: yes, you're so far the only one who voted candy.  But it was a good vote.  :-)
21:14 pmichaud maybe Rakudo releases should be named after different snack foods :-)
21:14 Andy jonathan: No, nobody has EVER noticed that about fork queue.  Not a one.  I'm CERTAIN it was not a design feature of the name.
21:15 dalek rakudo: eecbb2c | (Duke Leto)++ | src/classes/Complex.pir:
21:15 dalek rakudo: Add some basic docs to Complex.pir
21:15 dalek rakudo: Signed-off-by: Jonathan Worthington <jnthn@jnthn.net>
21:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​ecbb2c780aa32c59b80e53f7788d4e889a31309
21:15 shorten dalek's url is at http://xrl.us/behjao
21:16 jonathan Andy: :-P
21:16 jonathan pmichaud: There's...quite some patches to review.
21:16 dalek parrot: r37005 | NotFound++ | trunk/examples/embed/lorito.c:
21:16 dalek parrot: [examples] more options and some refactor in lorito
21:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37005/
21:17 NotFound Can someone explain that fork queue thing to non native-english people?
21:18 Coke NotFound: f**k you
21:19 NotFound You are a bunch of perverted ;)
21:19 Coke It's a fair cop.
21:19 dalek rakudo: e3f2de0 | (Chris Dolan)++ | src/builtins/match.pir:
21:19 dalek rakudo: Add POD for 'make' builtin
21:19 dalek rakudo: Signed-off-by: Jonathan Worthington <jnthn@jnthn.net>
21:19 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​3f2de0f261d2d0c28faa40fb4442413d9ea4962
21:19 shorten dalek's url is at http://xrl.us/behjbx
21:19 pmichaud I'll look at the queue.
21:19 jonathan Oddness... Why do I see other people's patches in certainly people's fork queues?
21:19 pmichaud Some of the patches I was intentionally holding off on.
21:19 pmichaud I hadn't seen the fork queue feature until Tene showed it either.
21:20 jonathan Me either!
21:20 jonathan There is something bad about it though.
21:20 jonathan You don't get karma for applying other people's patches through it.
21:20 jonathan ;-)
21:21 rg jonathan: you could submit a patch to dalek that parses the Signed-off-by to infinoid ;)
21:21 NotFound Because of the bad karma sounding of the feature?
21:22 Coke (other people's patches) because they approved them, I think.
21:22 Coke so leto's patch was approved by petdance, so you see it in his queue.
21:22 Coke (presumably because if you trust petdance, you trust his trust)
21:22 * Coke is just guessing, though.
21:22 Andy ooh, that's a bad thing.
21:22 Coke Andy: that's what you get for liking people!
21:23 Andy Because my understanding of the FQ is it lets me go and pull commits from other people so we can work on them together, without having to wait until they get committed to master
21:23 Coke Andy: I'm merely guessing here.
21:24 NotFound Aren't we going to make a party celebrating the 37000?
21:25 jonathan Meh. We'll have one at 40,000. ;-)
21:26 pmichaud does green mean "applied" and red mean "not applied"?
21:27 jonathan No
21:27 jonathan Green means "you can apply this now cleanly"
21:27 jonathan Red means "won't apply cleanly"
21:27 pmichaud okay.
21:27 jonathan It seems to me that the patches are in order of date of submission
21:27 jonathan Latest last.
21:28 jonathan And in some cases, applying an earlier one would seem to then make a later one appliable too.
21:28 jonathan Though it doesn't show those dependencies.
21:28 Andy this is a nice view too http://github.com/rakudo/rakudo/commits/master
21:28 pmichaud petdance's patches aren't latest last, though.
21:29 Andy sometimes applying greens turn red to green
21:29 jonathan oh, hmm
21:29 rjbs joined #parrot
21:29 pmichaud so, how do we apply a commit to master?
21:29 jonathan pmichaud: Tick it
21:30 Andy someone has to be logged in as rakudo
21:30 jonathan And then in the dropdown at the top of that user's area, select Apply
21:30 pmichaud got it
21:30 Andy rjbs here knows everything.
21:30 rjbs Hi.
21:30 Andy that's why I asked him in here.
21:30 pmichaud Andy:  actually, we have a lot of committers for rakudo.
21:30 Andy He's also a great kisser.
21:30 rjbs :^"
21:30 Andy But not just one called "rakudo"?
21:30 pmichaud there is a rakudo user, yes, but that's for maintaining the repository.  commits can be applied by any committer, as we saw Tene++ do above.
21:30 rjbs If you're talking about patch application using the fork queue, I will give you one bit of warning:
21:31 jonathan Andy: I'm able to apply from the fork queue and my account ain't called rakudo :-)
21:31 Andy but back to rakudo/rakudo?
21:31 jonathan Andy: I *think* so...
21:31 rjbs If you log in as 'pmichaud' and go to http://github.com/rakudo/rakudo/forkqueue and apply things, they will appear to have been committed *by rakudo* instead of by pmichaud.
21:31 Andy I guess I dont' see how, but I'm not a committer, either.
21:31 rjbs This is a known bug.
21:31 pmichaud Andy:  if the commit messages are showing up here, they're being applied to rakudo/rakudo .
21:32 rjbs Andy: If you go to http://github.com/$user/$projet/forkqueue and are a collaborator on the project, you can apply patches.
21:32 Andy But how does it know to commit to rakudo/rakudo, and not pmichaud/rakudo ?
21:32 Andy OK, I get it.
21:32 pmichaud Andy:  because I'm looking at the fork queue for rakudo/rakudo ?
21:32 dalek rakudo: 0316676 | (Chris Dolan)++ | Test.pm:
21:32 dalek rakudo: Make Test.pm's proclaim return a boolean, like Test::More
21:32 dalek rakudo: Signed-off-by: pmichaud <pmichaud@pobox.com>
21:32 pmichaud Andy:  as opposed to the FQ for pmichaud/rakudo ?
21:32 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​316676fe5a8ee68c1f464bbf165f3fe8f1854fb
21:32 shorten dalek's url is at http://xrl.us/behjdz
21:32 Andy pmichaud: Yes, I understand now.
21:33 pmichaud rjbs: thanks for the warning -- the fact that the patches appear to be committed by rakudo isn't a big issue, I don't think.  The commit message tells me who actually did the apply.
21:33 rjbs Yeah, it bugs me because it shows up in the RSS as "by pobox" which is, you know, not very useful for me.
21:33 rjbs but as long as you know and don't care, hoorah!
21:35 Andy Mostly I'm glad to get my stuff merged in there.
21:36 dalek rakudo: 9fe6dfd | (Duke Leto)++ | src/builtins/any-num.pir:
21:36 dalek rakudo: Make log(0) return the correct result, -Inf
21:36 dalek rakudo: Signed-off-by: pmichaud <pmichaud@pobox.com>
21:36 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​fe6dfd0563110d4b7be2fd950254e138d817a7a
21:36 shorten dalek's url is at http://xrl.us/behjd9
21:37 rjbs Okay, popping back off again.  Feel free to ping me in the future.  I'm becoming a pretty heavy GH user.
21:37 pmichaud rjbs: thanks a bunch!
21:37 rjbs ciao!
21:37 rjbs left #parrot
21:41 Andy Once again, my job of bringing appropriate people together has been fulfilled.
21:43 pmichaud so, what happens if I comment on a proposed pull and then 'ignore' it?  Does the original pull requestor get a message or notification of some sort?
21:45 pmichaud I wish there was a way to assign commits to a specific person for review.
21:45 jonathan pmichaud: Anything you want me to review? ;-)
21:46 pmichaud jonathan: stuff for moritz, mostly.
21:46 pmichaud the downside of applying patches from the github fork queue is that we don't have a ticket on which to hang "awaiting spectest" notes.
21:47 jonathan pmichaud: that's only true if people discover *and* patch a bug themselves.
21:47 pmichaud I don't understand.
21:47 jonathan It'd be good to encourage people if they are submitting something that fixes a bug in RT to include the RT number in the commit message.
21:48 jonathan pmichaud: For bugs we do have an RT ticket.
21:48 pmichaud it's not just bugs though, new features should be that way also.
21:48 pmichaud i.e., if someone adds a new feature, we'd like there to be a test for it.
21:48 jonathan Yes, true.
21:48 jonathan Agree totally.
21:48 jonathan Maybe we can ask people to specify where the tests that it makes pass are, in the commit message, too?
21:48 pmichaud maybe I just need to write a comment that says "awaiting confirmation of spectest" before the commit gets applied.
21:49 pmichaud of course, the downside to that is that the spectest has to be marked as todo/skip until the commit is applied.
21:49 jonathan Well, it's not just the spectest existing, it's that it gets unfudged too.
21:49 AndyA joined #parrot
21:51 pmichaud right.  So if we're going to use github's fork queue, we need a bit of a process for managing accepted/rejected/need spectest items.
21:51 jonathan Aye.
21:51 jonathan Basically a set of patch submission guidelines.
21:52 jonathan I think github doesn't take away the need to manage the process at all, it just means the actually application of a patch is a tad easier.
21:52 pmichaud well, even that concerns me a bit -- when I apply the patch, how do I know that 'make spectest' still passes?
21:53 jonathan I'm pretty sure there'll be cases where we want to apply it locally for testing first.
21:53 jonathan Which is fine too.
21:53 pmichaud is there an easy way for "apply locally"?
21:54 pmichaud or perhaps we need a separate branch for local testing?
21:54 jonathan But for things like, say, documentation patches, or when you can look at a patch, know it looks reasonable, and trust that the submitter does send high quality and spectested patches, it's probably OK to just apply. Guess it's a judgement call.
21:54 jonathan I think you can select which branch you put it into.
21:54 pmichaud sure, I'm more curious about the functional patches as opposed to the auxiliary ones.
21:55 jonathan Rather than master.
21:55 pmichaud iwabni my comments on patches went to a mailing list.
21:55 pmichaud so that everyone can see the discussion, and not just the requestor.
21:55 jonathan Yeah
21:56 jonathan I wonder if we should request RT tickets along with each patch that people want to be applied that is a functional one?
21:56 jonathan They can link to github in the RT
21:56 jonathan And mention the spectests that are applicable.
21:56 pmichaud that feels like "extra work" to me somehow.
21:56 jonathan Then we keep discussion there.
21:56 jonathan It's no more than we already did.
21:57 jonathan With svn, people sent a ticket with a patch attached.
21:57 pmichaud the main difference being that with rt the patch was part of the ticket directly.
21:57 jonathan Following a link to github isn't that more of a burden, is it?
21:57 jonathan Especially when application might potentially be a click away if you trust the patch enough.
21:57 pmichaud it's a burden for the person composing the rt ticket to include the link.  But perhaps not that much of a burden.
21:58 pmichaud especially when people are going to be tempted to just do "request pull" from github in the first place and bypass rt altogether.
21:58 jonathan Yes, true.
21:58 jonathan But then we're back to how to facilitate open discussion on the patch.
21:58 pmichaud right.
21:58 jonathan Or are the comments posted publicly?
21:58 pmichaud I think they're public, but I don't know how one would get to them.
21:59 jonathan Do they not just appear on the page with the patch?
21:59 pmichaud if someone goes looking for them, yes.
21:59 pmichaud the nice thing about a mailing list is that one doesn't have to go looking for it.
21:59 pmichaud it shows up in the inbox.
22:00 jonathan Yeah
22:00 pmichaud if I review a requested push, comment on it (saying it's not appropriate), and then "ignore" it, I don't think anyone ever sees my comment.
22:00 jonathan Thus why I suggested sticking with RT for patch discussion.
22:00 jonathan Aye.
22:01 jonathan tbh I think we just need to pick a procedure that we think will work and make sure it's documented and clearly linked to on rakudo.org
22:01 dalek parrot: r37006 | NotFound++ | trunk (3 files):
22:01 dalek parrot: [core] add a wrapper function to call PackFile_fixup_subs PBC_LOADED from embedding
22:01 pmichaud otoh, being able to privately reject a proposed commit is nice -- it has less of a "public rejection" about it.
22:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37006/
22:01 pmichaud well, now that I've found it, I'll review the outstanding items in the fork queue and we'll see how that works out.
22:02 jonathan Aye
22:03 jonathan The other thing is, I don't always know if people's things in the forkqueue are stuff they feel is ready for application or have submitted. AFAICT, it could be a "work in progress"
22:03 Coke would that have submitted a WIP?
22:03 pmichaud well, someone should only request pulls for things they think ought to be applied.
22:03 Coke *they
22:03 jonathan Yes.
22:03 pmichaud if it's a work in progress, they shouldn't request a pull.
22:04 jonathan Agree - I'm talking more about just browsing the fork queue for stuff to apply.
22:04 pmichaud I don't follow.
22:04 jonathan For if we're only going to look at things people mention in RT or request a pull from, that's fine.
22:05 pmichaud correct, I'm not going to go searching in other people's repos for things to apply.
22:05 jonathan OK, but all I mean is that I don't think the fork queue just lists things that have been explicitly "submitted" as it were.
22:05 pmichaud oh, does the fork queue show all of the work that anyone has done?
22:05 pmichaud oh.
22:05 jonathan I'm not sure.
22:06 pmichaud that would be a bit weird.
22:06 jonathan My impression was that it just showed almost anything.
22:06 Tene pmichaud: you can change the branch you're committing to in the gui.  Have an 'integration' branch or whatever.
22:06 NotFound ./objectref.c: In function ‘void Parrot_ObjectRef_class_init(parrot_interp_t*, int, int)’:
22:06 NotFound ./objectref.c:3611: error: conversión inválida de ‘void (*)(parrot_interp_t*, PMC*, INTVAL)’ a ‘void (*)(parrot_interp_t*, PMC*, PMC*)’
22:06 Tene pmichaud: you can also add other people's repos as remotes in your local git checkout
22:06 Tene and work with the commits through git or a git gui locally.
22:07 pmichaud Tene: I'm more interested in working through a 'queue' of requested changes.
22:07 NotFound I've got this error building rakudo with g++
22:07 pmichaud so "adding other people's repos" doesn't sound like a queue.
22:07 Tene pmichaud: you were asking about how to confirm spectest passes before committing.
22:07 Tene you could just check out their branch directly in your local checkout
22:07 pmichaud Tene: well, "confirm spectest passes" sounds like a command-line sort of thing.
22:08 pmichaud Tene: would checking out their branch get all of their commits to that branch?
22:08 Coke nick Coke_afk
22:08 Tene pmichaud: yes.
22:08 Tene pmichaud: well, whatever you want it to do, I guess
22:09 pmichaud right, I'm usually interested in cherry-picking commits.
22:09 Tene And you could make a local branch, cherry-pick it in
22:09 pmichaud as opposed to grabbing someone's entire branch.  Especially since folks tend to put multiple separate items in a single branch.
22:09 pmichaud right, I'm looking for easier ways to do the cherry-picking.
22:10 pmichaud my current mental model for processing patches goes something like:
22:10 pmichaud (1) start with a clean version of head
22:10 pmichaud (2) apply a proposed patch
22:10 pmichaud (3) run 'make spectest'
22:10 pmichaud (4) push patch to head
22:11 pmichaud it's the "apply a proposed patch" step that I haven't quite figured out yet.
22:11 Tene git cherry-pick XXXXX
22:11 pmichaud where XXXXX is a url?
22:12 Tene No, a commit id.  You can add other people's repositories as remotes in your local git checkout.
22:12 pmichaud it's that "other people's repos" that bugs me a bit.
22:12 pmichaud I'd prefer to not have to maintain tha tlist.
22:12 Tene How's that?
22:13 pmichaud i.e., if every time someone new submits a pull request I need to add their repo as a remote... that's a pain.
22:14 Tene Hmm.
22:14 pmichaud I'd prefer to be able to grab commits out of the fork queue directly.
22:15 * Tene investigates.
22:15 pmichaud or have git/github be smart enough to figure that out.
22:15 pmichaud anyway, I have to take kids to dinner and other errands -- bbl.
22:15 Whiteknight joined #parrot
22:16 Tene pmichaud: you could pull them into a new branch in the rakudo repo
22:16 Tene click on the 'change it' link by the top of the fq page.
22:16 Tene That will cherry-pick them into that branch
22:18 pmichaud it still feels like I'm having to do a lot more commit management than ought to be necessary.
22:18 pmichaud move to a branch, test the branch, move to master
22:18 pmichaud etc.
22:18 pmichaud especially if I'm having to do all of this on github.  I ought to be able to do it in my local repo.
22:18 pmichaud anyway, I do have to go.
22:18 pmichaud bbl
22:22 jonathan btw report http://use.perl.org/~Jonath​anWorthington/journal/38550
22:28 cotto does make headerizer take care of the ASSERT_ARGS macros?
22:29 jonathan I believe so.
22:29 cotto yup
22:29 cotto that makes life a little nicer
22:33 cotto we need to add "make dtrt"
22:36 rurban joined #parrot
22:37 chromatic pmichaud, candy
22:38 jonathan YAY
22:38 jonathan See, it's not just me...
22:43 chromatic Even though I was late, I had to show solidarity.
22:53 dalek parrot: r37007 | NotFound++ | trunk/examples/embed/lorito.c:
22:53 dalek parrot: [examples] fix lorito C build
22:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37007/
23:06 cotto Would it be ok to rewrite the Sub_comp_* macros to operate directly on a Parrot_sub rather than a PMC?
23:07 cotto There are only a handful of instances that'd need to be updated.
23:09 NotFound cotto: will be better to make them const-aware
23:10 NotFound His current implementation force some const casts completely unneeded
23:10 cotto I saw that in a comment.
23:10 cotto If it's not a hard fix, I could easily do it while I'm in there.
23:11 cotto </tautology>
23:12 jonathan cotto: I did a bunch of stuff a while back to make places that expected a Sub PMC work with subclasses of that too. Be careful not to break such things.
23:12 cotto I am.
23:14 NotFound There is some reason to have config.o out of libparrot?
23:17 NotFound It doesn't make sense to me to have to link and call a function for it in almost any conceivable parrot tool or embedding.
23:22 dalek parrot: r37008 | NotFound++ | trunk/examples/embed (2 files):
23:22 dalek parrot: [examples] link and use parrot_config in lorito
23:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37008/
23:28 cotto NotFound, there's a little too much yak shaving involved for me to do that fix with this commit.
23:30 NotFound With this last commit I've been able to run rakudo from lorito, but it print a lot of "Stringifying an Undef PMC" messages
23:30 cotto It's already going to be quite sizeable.
23:30 PacoLinux arlosmar: es cierta la noticia esa que han pegado por aqui ?
23:30 NotFound PacoLinux: no :D
23:30 PacoLinux jejeje
23:31 PacoLinux si dijeran algo malo de mi, por lo menos intentaria defenderme ..
23:31 NotFound PacoLinux: wrong channel
23:31 PacoLinux sorry ...
23:35 kid51 joined #parrot
23:35 bacek_ joined #parrot
23:39 Limbic_Region joined #parrot
23:42 NotFound Oh, the messages are due to the Parrot_setwarnings(interp, PARROT_WARNINGS_ALL_FLAG); in lorito
23:43 NotFound I CAN HAZ LOLCODE EMBEDED
23:46 jonathan I HAZ A LOLCODECOMPILER ITZ WIN
23:47 jonathan BTW THAT'S AWESOME
23:51 NotFound Now you can try to add LOLCODE macros to vim ;)
23:52 jonathan I suppose it's lighter on the parentheses keys than writing lisp macros for emacs...
23:53 NotFound It's strange that nobody has written yet a parrot vm in elisp
23:53 Tene a VM in elisp?
23:54 NotFound Don't say that too loud, they can hear us ;)
23:54 Tene What's lorito?
23:54 purl it has been said that lorito is "little parrot" in spanish or examples/embed/lorito.c
23:55 NotFound Tene: examples/embed
23:55 NotFound Hey, even purl knows
23:55 nopaste "tene" at 148.87.66.57 pasted "cd examples/embed ; make" (16 lines) at http://nopaste.snit.ch/15721
23:56 NotFound Tene: look at the Makefile comments
23:56 Tene Wait, you mean I need to READ?
23:56 Tene I don't like the sound of this project.
23:56 NotFound It's in examples for some reason ;)
23:59 dalek parrot: r37009 | jkeenan++ | trunk (4 files):
23:59 dalek parrot: Applying documentation fixes found in patch submitted by ronaldws in https://trac.parrot.org/parrot/ticket/377.
23:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37009/

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

Parrot | source cross referenced