Parrot 0.9.1 Released | parrot.org/ | 451 RTs left!
Set by moderator on 24 February 2009.
00:09 AndyA joined
dalek rrot: r36987 | NotFound++ | trunk/examples/embed/Makefile:
[examples] embed/Makefile fix
 00:13
01:00 HG` joined 01:22 TiMBuS joined
dalek kudo: 5944501 | pmichaud++ | t/harness:
Updated harness that doesn't rely on Parrot::Test::Harness.

to re-add that feature. Also needs testing on Win32.		 02:45
shorten dalek's url is at xrl.us/behgac
dalek tracwiki: v53 | jimmy++ | WikiStart 02:52
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/behgbm
02:56 jimmy joined 03:12 dukeleto joined 03:32 kid51 joined 03:41 janus joined
dalek rrot: r36988 | jkeenan++ | trunk/examples/embed/lorito.c:
Enforce C coding standards re (a) no space between function name and opening
 04:25
04:38 Nom joined
Coke_afk allison++ # patches for partcl. 04:43
allison Coke: I figured the best way to test building from an installed parrot was on real languages :) 04:46
dalek tracwiki: v54 | coke++ | WikiStart 04:52
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/behgqb
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
(even after escaping the /'s)
jimmy let me do that
Coke file://foo/bar/baz.pod works. Good enough for now. 04:58
dalek tracwiki: v55 | jimmy++ | WikiStart 04:59
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/behgqs
allison Coke: podchecker is b0rken 05:00
Coke: linking to a file path is fine
Coke is it going to HTMLify properly?
(right now I have L<file://docs/project/support_policy.pod>)
should that just be L<docs/project/support_policy.pod> ?
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
Coke: include the .pod, the rest should be fine
Coke which podchecker
/usr/local/bin/podchecker
which doesn't seem to respect -v or --version.
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.)
allison Coke: if it's pre 5.10.0, then it's Pod::Parser, which is really broken
dalek tracwiki: v1 | coke++ | Deprecation 05:03
tracwiki: trac.parrot.org/parrot/wiki/Deprec...ction=diff
shorten dalek's url is at xrl.us/behgqu
dalek tracwiki: v56 | jimmy++ | WikiStart
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/behgqw
dalek rrot: r36989 | coke++ | trunk/DEPRECATED.pod:
[docs] Eliminate some developer-specific verbiage; this is meant to be our user-facing deprecation notice.
 05:07
rrot: r36990 | coke++ | trunk/docs/project/release_manager_guide.pod:
[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
rrot: r36991 | coke++ | trunk/DEPRECATED.pod:
[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
Coke allison: that change to DEPRECATED.pod look ok to you? 05:28
hopefully more clear.
allison Coke: what does eligible in 1.4 mean? 05:31
Coke eligible for removal.
allison Coke: can be removed before the 1.4 release or after the 1.4 release?
Coke I can add a note to the top of the doc.
I mean in, so "just before"
it's from a user's standpoint, not a developers.
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
allison because those features can be removed at any point after 1.0
Coke ... not as I understand things.
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
allison chromatic or pmichaud had a good write up
Coke ok. I officially give up. =-)
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
allison but, chromatic added a note that we may delay deprecations in some cases if they were entered late in the cycle
Coke then what is the point of the stable releases?
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
if they do that, then they got the deprecation notice in 1.0, and know to expect a change in 1.4
(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:36
the tricky part is that we're dealing with two completely different audiences 05:37
the developers (who track monthly releases) and the users (who track stable releases)
Coke If you're referring to a discussion or meme that occurred at the PDS (different audiences), I have no idea.
developers of... parrot?
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
developers of parrot or developers of languages who want to hug close to the wire
Coke I would posit that the explanation should probably be documented somewhere.
developers of parrot I would expect to still track svn.
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.
allison it's a good development cycle, keeps us moving, gives a good point for bug fixing, etc
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.
allison the full sentence "This feature is eligible to be removed after the 1.0 release, but may be removed later" makes sense
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"
Coke so that doc reflects my (wrong) understanding.
allison ah, okay, that understanding is probably because we've mostly been talking about deprecations in terms of the deprecation releases 05:42
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
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.
allison nice for users too
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.
allison the last thing you want is to make major changes to the code just before a bit release
we don't expect users to upgrade every month
users should be using 1.0 or 1.4, not the monthly releases
Coke that really should be written down somewhere, no?
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.
(I was looking for others before replying to your request0
but that's a pretty big one.
you say that they are devel releases; he says they are stable.
that's a HUGE difference.
allison what, the monthly releases? 05:46
Coke yes.
allison okay, he's using the terms differently
(not in the perl 5 way)
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.
allison and 1.0 and 1.4 will go in the "stable" directory of the ftp server, the monthlies won't
then we haven't explained it well enough
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
pmichaud or, we could say "development release"
allison pmichaud: sounds good
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. =-)
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.
allison Coke: I tried explaining it, and people are still confused :)
Coke and on list.
purl well, on list is a good place for such things (mailto:perl6-internals@perl.org)
allison purl: forget on list
purl allison: I forgot on list
jimmy like ubuntu? rc1,rc2? alpha2? 05:50
allison jimmy: ? 05:52
jimmy follow it: we could say "development release"
allison jimmy: yes, I think "development release" is clearest 05:53
nopaste "pmichaud" at 72.181.176.220 pasted "proposed text revision for first section of support_policy.pod" (10 lines) at nopaste.snit.ch/15712 05:54
pmichaud (working on the deprecation section next) 05:55
allison pmichaud: looks good 05:58
purl O_O
05:59 eternaleye joined
jimmy Emphasizing 'development release' or 'stable release' ++ 05:59
nopaste "pmichaud" at 72.181.176.220 pasted "proposed deprecation text" (12 lines) at nopaste.snit.ch/15713
pmichaud Coke: do my versions of the text make sense to you? 06:00
Coke s/That is/For example/
I think having all the examples is probably too verbose. 06:01
hang on.
purl hang on. is this actually "session is still there but user has been deleted" ?
dalek rrot: r36992 | coke++ | trunk/DEPRECATED.pod:
[docs] Update to match info from allison on IRC; my earlier interpretation was flawed.
Coke honestly, keeping chromatic's first 2 sentences and deleting the rest of the paragraph is fine. 06:02
especially if stable in /that/ sentence means what stable means in allison's doc.
pmichaud I'm not a fan of the term "milestone release", though.
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.
We will regularly deprecate features and remove them. All deprecations must
have an announcement in at least one stable release before removal.
pmichaud oh, I kept once sentence too many.
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")
the person. that's the word I meant.
perhaps a small explanation, ala:
pmichaud yes, I follow the difference.
I agree, "we" is better. 06:05
(in keeping with the rest of the document)
Coke I don't mind either way as long as it's consistent. I don't think we're consistent through the docs.
pmichaud well, since it's a "support policy", "we" seems appropriate here.
since support comes from people or a team or something. 06:06
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 nopaste.snit.ch/15714
pmichaud (I'm not saying eliminate version numbers, I'm just saying don't use them in the support policy at this time)
coke: that works for me.
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".
but I can see the other side of that coin.
Coke if the plan is for users to not install them in prod, I'd stick with dev.
monthly is neutral in terms of quality, so I default to "just as good."
We will regularly deprecate features and remove them. All deprecations will 06:11
be announced in at least one stable release before they are removed. Once a
stable release announces a deprecated feature, it is eligible for removalin any subsequent release, whether development or stable.
gah.
sorry.
diakopter removalin
Coke docs/project/*rel*/ uses different terminology, calling them "deprecation points"
pmichaud if we do that, then the first paragraph I proposed needs some additional text (just a sec)
allison Coke: it's fine to change that to "stable release" if we're standardizing terminology 06:14
stable release == deprecation point
nopaste "pmichaud" at 72.181.176.220 pasted "proposed deprecation text" (12 lines) at nopaste.snit.ch/15715
allison pmichaud: well, the thing about "monthly release" is that the stable releases are also monthly releases 06:15
pmichaud sure, I get that.
Coke deprecation point is a confusing name.
pmichaud agreed on confusion of "deprecation point"
allison Coke: agreed, we can eliminate "deprecation point"
pmichaud my last nopaste is actually proposed for the first paragraph, introducing the notion of "development release" 06:16
another term for the non-stable releases might be "interim release"
06:16 mberends joined
Coke if we mention january and july, we should mention that 1.0 is 'special' 06:17
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
Coke inverting the release numbering is very confusing. 06:19
I have to go to bed.
allison Coke: something like "1.0 in March, and the subsequent releases in January and July"
06:19 Tene joined
pmichaud I need sleep also. 06:21
afk for a while -- bbl.
06:28 cotto joined 06:29 cotto joined 06:30 cotto joined 06:36 Ademan joined 07:03 mohan joined, mohan left 07:11 uniejo joined
cotto allison, ping 07:23
allison cotto: pong 07:24
cotto I Coke correct that the Slice and Bound_NCI PMCs can be excised after 1.0?
allison the way the deprecation cycles work, it they can be removed immediately after the "stable" release that includes the deprecation notice, yes
cotto got it 07:25
For some reason I thought it'd have to wait until after 1.4.
allison they might not be removed until after 1.3, but they're eligible to be removed at any point after 1.0
cotto understood
purl Roger Roger.
cotto thanks 07:26
allison cotto: the explanation isn't entirely clear yet, we're still working on it
07:40 masak joined 07:50 mj41 joined 08:17 szabgab joined
dalek kudo: 7f8ba6f | (Moritz Lenz)++ | (5 files):
Merge branch 'move_split_to_any_str'
 08:25
shorten dalek's url is at xrl.us/behg33
08:46 Eevee_ joined
dalek rrot: r36993 | fperrad++ | trunk/tools/dev/mk_inno_language.pl:
[inno-setup] rakudo is a special case, because perl6.exe
 08:57
09:05 khatar joined 09:06 cotto joined 09:26 mberends joined 10:23 mberends joined 10:29 elmex joined 10:49 pancake joined
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
is this a known issue?
(svn)
10:51 contingencyplan joined
moritz not known to me (but that doesn't mean anything) 10:51
10:52 samlh joined 11:33 PacoLinux joined 11:46 s1n joined
dalek rrot: r36994 | fperrad++ | trunk (3 files):
[doc] allow creation of a Compiled HTML Help (.chm) from docs/html
 11:54
kudo: d912db6 | jnthn++ | src/classes/Protoobject.pir:
Make proto-objects respond more correct to WHICH, which fixes === on proto-objects and thus resolves RT#62902.
 12:07
shorten dalek's url is at xrl.us/behhfi
dalek rrot: r36995 | fperrad++ | trunk/tools/docs/mk_chm.pl:
[chm] add a Title
 12:10
kudo: 23e8e02 | jnthn++ | src/classes/Whatever.pir:
Whatever isa Any, not Object (per S02).
 12:12
shorten dalek's url is at xrl.us/behhfx
12:15 PacoLinux joined
dalek kudo: 798236b | (Moritz Lenz)++ | build/Makefile.in:
since t/harness now uses ./perl6, we should depend on it for 'make spectest'
 12:20
shorten dalek's url is at xrl.us/behhgb
dalek kudo: bad46f7 | (Moritz Lenz)++ | build/Makefile.in:
[build] 'make test' should also depend on the fake executable
 12:24
shorten dalek's url is at xrl.us/behhgw
12:32 rg1 joined 12:42 mberends joined 13:16 jimmy joined
dalek kudo: a5bad9a | jnthn++ | src/parser/ (2 files):
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
kudo: dfe942d | jnthn++ | build/Makefile.in:
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/behhon
shorten dalek's url is at xrl.us/behhop
14:17 gryphon joined
dalek kudo: f9b9041 | jnthn++ | src/classes/List.pir:
Fix zip operator when there's a list containing a range on one side. Patch courtesy of bacek++.
 14:39
shorten dalek's url is at xrl.us/behhqk
14:48 Andy joined
Coke only obstacle to removing random is to cleaup a test in t/op/gc.t 14:54
15:03 rafl joined 15:05 Tene joined 15:19 cas joined 15:22 masak joined
dalek kudo: 59fcc4e | jnthn++ | src/classes/Grammar.pir:
.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
shorten dalek's url is at xrl.us/behhue
dalek rrot: r36996 | NotFound++ | trunk/examples/embed/lorito.c:
[examples] indentation fix
 15:26
15:53 Theory joined 16:09 contingencyplan joined 16:59 bacek joined
dalek rrot: r36997 | coke++ | trunk/docs (3 files):
RT #49001 - update some uses of 'compilation unit' to 'subroutine'
 17:02
jonathan purl, alester?
purl i don't know, jonathan
jonathan purl, andy lester?
purl andy lester is already backing that change, so it's just a "does it actually work everywhere" quarantine period right now
jonathan ...I kinda wnated the email address, but anyway...
rg try petdance.com/ 17:03
Andy jonathan: andy@petdanc.ecom
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 nopaste.snit.ch/15716 17:04
pmichaud oh, it's the *contexts* that get double-freed?
I didn't know that. I know a little about those. 17:05
jonathan pmichaud: Yes.,
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.
dalek rrot: r36998 | coke++ | trunk (2 files):
Track a language specific RT so we can clean up parrot's queue.
pmichaud (I'm very familiar with the context code after having done the lexicals re-impl)
Tene pmichaud: what's involved in getting commit privs on rakudo? 17:08
pmichaud Tene: you have commit to Parrot already, yes?
Tene Yes.
pmichaud I just need to know your github id.
Tene 'tene'
pmichaud Added. 17:09
Tene sweet
dalek rrot: r36999 | coke++ | trunk/examples/embed/Makefile.msvc:
[distro] Fix properties on recently added file
 17:10
17:12 japhb joined
pmichaud jonathan: the following of the caller_ctx chain is bogus in destroy_context -- we currently don't refcount caller_ctx 17:12
I think that's left over from when contexts were more stacklike. 17:13
dalek kudo: f43750a | jnthn++ | src/ (2 files):
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
shorten dalek's url is at xrl.us/behh8e
pmichaud also, destroy_context appears to be missing any outer contexts that need freeing. 17:15
17:15 davidfetter joined
pmichaud I can come up with a different patch to try -- just a sec. 17:16
jonathan pmichaud: OK, awesome.
17:17 geof joined
nopaste "pmichaud" at 72.181.176.220 pasted "my version of avoiding double-free" (17 lines) at nopaste.snit.ch/15717 17:19
pmichaud untested as yet.
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. :-)
Parrot_free_context also frees any contexts that the current context might have been referencing. 17:21
jonathan FTW
Compiles, testing it...
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.
jonathan Me either until today
It was annoying me, so I was like, "right, out comes the C debugger"
pmichaud of course, all of this goes away when we have gc-able contexts, sometime in 2012.
jonathan And when it broke, it was right there in that bit of code... 17:23
In fact under the debugger it crashed with the double free rather than hung.
Yeah, I'd rather like to think that we can have a non-segv-ing Rakudo before 2012. ;-)
pmichaud It still bugs me somewhat that my laptop is 33% faster than my desktop. 17:27
jonathan pmichaud: Initial signs are good.
Heh. You know what *my* laptop is like.
Tene My old desktop was punted to basement server duties a few years ago. 17:28
I haven't had a desktop in ages.
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
when I ordered it I also ended up with a docking station somehow.
jonathan I sorta want a new laptop. 17:30
But they're so uncomfortable for me to use that I only do it when I'm doing conferences and hackathons.
Which means I only notice the slowness now and then.
And thus never get irked enough to shell out for something new.
pmichaud well, my laptop supposedly outputs 2048x1536 @ 75Hz, so display quality isn't an issue. 17:32
it might be very interesting to move my desktop to full-time server duty. 17:33
17:34 mikehh joined
jonathan pmichaud: OK, your patch rocks. :-) 17:34
pmichaud glad to know I've done something right this month :-)
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:38
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.
jonathan OK, great. :-)
Getting this sorted out before the release makes me *very* happy.
pmichaud same here.
jonathan And we can keep on using the fakeexecutable. 17:41
For make spectest.
pmichaud does the fakecutable pass all of the spectests on your box?
jonathan No 17:43
But it passes the same number as parrot perl6.pbc does.
(Some NaN related failures still.)
pmichaud okay.
jonathan So there's nothing specific to the fakeexecutable any more.
pmichaud all (parrot) tests pass, so committing fix. 17:48
jonathan Yay! 17:50
pmichaud++
pmichaud heh. r37000 . Nice round number.
jonathan Good number, for a good patch. 17:51
dalek rrot: r37000 | pmichaud++ | trunk/src/gc/register.c:
[core]: Eliminate double-free problem with contexts in fakecutables

  * jonathan++ for tracking down the source of the problem
pmichaud tests bumping up PARROT_REVISION
jonathan That might even be something we can tick off on the 1.0 todo list. ;-) 17:52
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:55
dalek rrot: r37001 | fperrad++ | trunk/config/gen/makefiles/docs.in:
[doc] add a target 'book' that generate a HTML output (with Pod::PseudoPod)
 17:59
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.
dalek rrot: r37002 | fperrad++ | trunk/tools/docs/mk_chm.pl:
[chm] add the content of book
18:05 darbelo joined
Coke pmichaud: there's a deprecation ticket that I think is yours: any chance you can resolve trac.parrot.org/parrot/ticket/168 ? 18:05
pmichaud Coke++ # yes, I can resolve it. 18:07
dalek rrot: r37003 | fperrad++ | trunk/tools/docs/mk_chm.pl:
[chm] CSS & logo are embedded in no relative path
 18:08
18:10 mberends joined
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]
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
jonathan purl msg Tene if you get a spare moment, any chance you could take a peek at rt.perl.org/rt3/Ticket/Display.html?id=63430 ? kplzthx 18:20
purl Message for tene stored.
18:31 Eevee joined 18:38 jsut|work joined
dalek kudo: f1f722e | (Patrick R. Michaud)++ | build/PARROT_REVISION:
Bump PARROT_REVISION to r37000, to avoid double-free issues in fakecutable.
 18:38
shorten dalek's url is at xrl.us/behijo
18:44 mberends joined
Coke gets rakudo building from git. 18:45
Coke accidentally builds it as root. 18:50
should there be a SPECTEST_REVISION ala the PARROT_REVISION ? 18:52
18:52 mberends joined
PerlJam Coke: why exactly? Shouldn't all the spec tests pass always? 18:54
18:55 cas joined
Coke yes, but parrot should also work for you all the time, too. 18:56
18:57 barney joined
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.
Coke: And we have a white-list of ones we run. 18:58
Coke jonathan: (white list) ah, ok.
so someone adding a test isn't going to randomly fail you.
jonathan Right.
Well, adding it to a test file we do run and not fudging it may.
Coke I miss TEST_JOBS=3 :|
jonathan But a new test file for a feature we don't do at all yet, no, we don't notice that.
It seems to work out fairly well so far. 18:59
sjn jonathan: have you heard from Linpro yet?
jonathan sjn: Yes - they're arranging my hotel.
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
great
jonathan Might just say "OK, find me a flight back and I'll look after getting there" :-)
Anyway, things are getting worked out. :-) 19:01
Thanks for organizing.
sjn np
dalek kudo: 7abe283 | jnthn++ | src/builtins/guts.pir:
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
shorten dalek's url is at xrl.us/behipg
dalek kudo: 3484985 | jnthn++ | build/PARROT_REVISION:
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/behipz
dalek kudo: f934f32 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 314 files, 7007 passing, 0 failing
 19:09
shorten dalek's url is at xrl.us/behiq8
19:24 chromatic joined
dalek rrot: r37004 | fperrad++ | trunk/lib/Parrot/Docs/File.pm:
[doc] find Title when modern style POD
 19:51
Coke ho, chromatic. 20:05
chromatic pong
20:05 cas_ joined
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:06
(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:07
chromatic Users will do what users will do. 20:08
I don't think we can predict that. 20:09
Coke I'm trying to get a handle on what that means for our support policy. 20:12
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
so we could, theoretically, add something in 1.1 and remove it in 1.2 with no warning.
(she didn't say that. I'm extrapolating) 20:14
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)
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.
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'? ;)
chromatic Grr, no, she just said "They're developer releases."
Coke "regard"
purl "regard" is a good one.
Coke chromatic: www.parrot.org/news/vision-for-1_0 refers to them as 'development' releases. 20:19
(it also has the older .5 releases)
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.
Coke chromatic: which now?
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
20:22 cas joined
jonathan Also, we're running make spectest with the fakeexecutable now. Lots of leak testing. ;-) 20:23
NotFound jonathan: great!
jonathan Well, shutdown testing.
chromatic jonathan, I just talked to pm about that. 20:27
good work 20:28
Tene pmichaud: should pasttype "try" explicitly ignore return exceptions? 20:29
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.
Tene Okay.
pmichaud or we need to augment the 'try' pasttype to be able to specify the things we want to catch.
Tene Are there any other exceptions that try {} doesn't get? 20:32
Also, do we need to consult timtoady to confirm that return passes through try?
pmichaud probably. But I suspect it has something to do with 'return' being tied to the enclosing sub's scope. 20:34
i.e., so a 'try' wouldn't see it anyway.
rg i think last i looked rakudo wasn't generating pasttype try, but pushing handlers on blocks
Tene rakudo.past: try { say "foo" } 20:35
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (164 lines) at nopaste.snit.ch/15718
rg ah nice. i guess it does :) 20:36
Tene rakudo.past: { say "foo"; CATCH { say "wtf" } }
compare with that
I'm not sure what the difference should be.
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (212 lines) at nopaste.snit.ch/15719
Tene Also compared to:
rakudo.past: try { say "foo"; CATCH { say "wtf" } }
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (221 lines) at nopaste.snit.ch/15720
jonathan Isn't it that control exceptions are generally not caught by try? 20:38
But by CONTROL instead?
Tene So try ignores all control exceptions?
I can do that.
From what I remember of the specs, try() is equivalent to adding a CATCH { $! = $^a} 20:39
to the block
approximately?
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.
jonathan Though if you have a CATCH within it, that is what gets run.
But try { ... } will suppress any excetions from being thrown further an just put it into $!, AFAIR.
bbs - dinner
dalek kudo: 9f3d289 | (Andy Lester)++ | build/Makefile.in:
Add a perlcritic target to the makefile
 20:49
kudo: f9cb35e | (Andy Lester)++ | Configure.pl:
modernize some code, and add error checking
shorten dalek's url is at xrl.us/behi5k
shorten dalek's url is at xrl.us/behi5n
Coke wonders how tene did that. 20:59
Tene Coke: github.com/rakudo/rakudo/forkqueue
jonathan Did anyone else notice that if you say fork queue out loud quickly it...never mind. 21:00
Coke nose hit.
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
"What is your favorite snack: cookie, chips, candy, or cupcake?"
rg votes cookie 21:06
NotFound chips 21:07
Coke coke votes chips
pmichaud (thanks to all for participating)
Coke also wonders if there is a writein!
pmichaud Matthew says "no writeins", sorry.
Coke curses. 21:08
cotto cookie
pmichaud votes cookie
cotto (assuming he doesn't mean the HTTP-related kind) 21:09
dalek kudo: 766d5d5 | (Vasily Chekalkin)++ | src/classes/Range.pir:
Anonimize VTABLE methods in Range
 21:10
shorten dalek's url is at xrl.us/behi9z
pmichaud need two more votes
okay, just need one more 21:11
actually, we can get the last vote from his sister. Thank you all for participating!
jonathan
.oO( Am I really the only one who voted candy?! )
21:12 mikehh joined
Coke (freak) 21:13
pmichaud jonathan: yes, you're so far the only one who voted candy. But it was a good vote. :-) 21:14
maybe Rakudo releases should be named after different snack foods :-)
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.
dalek kudo: eecbb2c | (Duke Leto)++ | src/classes/Complex.pir:
Add some basic docs to Complex.pir
 21:15
shorten dalek's url is at xrl.us/behjao
jonathan Andy: :-P 21:16
pmichaud: There's...quite some patches to review.
dalek rrot: r37005 | NotFound++ | trunk/examples/embed/lorito.c:
[examples] more options and some refactor in lorito
NotFound Can someone explain that fork queue thing to non native-english people? 21:17
Coke NotFound: f**k you 21:18
NotFound You are a bunch of perverted ;) 21:19
Coke It's a fair cop.
dalek kudo: e3f2de0 | (Chris Dolan)++ | src/builtins/match.pir:
Add POD for 'make' builtin
shorten dalek's url is at xrl.us/behjbx
pmichaud I'll look at the queue.
jonathan Oddness... Why do I see other people's patches in certainly people's fork queues?
pmichaud Some of the patches I was intentionally holding off on.
I hadn't seen the fork queue feature until Tene showed it either.
jonathan Me either! 21:20
There is something bad about it though.
You don't get karma for applying other people's patches through it.
;-)
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?
Coke (other people's patches) because they approved them, I think. 21:22
so leto's patch was approved by petdance, so you see it in his queue.
(presumably because if you trust petdance, you trust his trust)
Coke is just guessing, though.
Andy ooh, that's a bad thing.
Coke Andy: that's what you get for liking people!
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.
NotFound Aren't we going to make a party celebrating the 37000? 21:24
jonathan Meh. We'll have one at 40,000. ;-) 21:25
pmichaud does green mean "applied" and red mean "not applied"? 21:26
jonathan No 21:27
Green means "you can apply this now cleanly"
Red means "won't apply cleanly"
pmichaud okay.
jonathan It seems to me that the patches are in order of date of submission
Latest last.
And in some cases, applying an earlier one would seem to then make a later one appliable too. 21:28
Though it doesn't show those dependencies.
Andy this is a nice view too github.com/rakudo/rakudo/commits/master
pmichaud petdance's patches aren't latest last, though.
Andy sometimes applying greens turn red to green 21:29
jonathan oh, hmm
21:29 rjbs joined
pmichaud so, how do we apply a commit to master? 21:29
jonathan pmichaud: Tick it
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
pmichaud got it
Andy rjbs here knows everything.
rjbs Hi.
Andy that's why I asked him in here.
pmichaud Andy: actually, we have a lot of committers for rakudo.
Andy He's also a great kisser.
rjbs :^"
Andy But not just one called "rakudo"?
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.
rjbs If you're talking about patch application using the fork queue, I will give you one bit of warning:
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?
jonathan Andy: I *think* so...
rjbs If you log in as 'pmichaud' and go to github.com/rakudo/rakudo/forkqueue and apply things, they will appear to have been committed *by rakudo* instead of by pmichaud.
Andy I guess I dont' see how, but I'm not a committer, either.
rjbs This is a known bug.
pmichaud Andy: if the commit messages are showing up here, they're being applied to rakudo/rakudo .
rjbs Andy: If you go to 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 ?
OK, I get it.
pmichaud Andy: because I'm looking at the fork queue for rakudo/rakudo ?
dalek kudo: 0316676 | (Chris Dolan)++ | Test.pm:
Make Test.pm's proclaim return a boolean, like Test::More
pmichaud Andy: as opposed to the FQ for pmichaud/rakudo ?
shorten dalek's url is at xrl.us/behjdz
Andy pmichaud: Yes, I understand now.
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.
but as long as you know and don't care, hoorah!
Andy Mostly I'm glad to get my stuff merged in there. 21:35
dalek kudo: 9fe6dfd | (Duke Leto)++ | src/builtins/any-num.pir:
Make log(0) return the correct result, -Inf
 21:36
shorten dalek's url is at xrl.us/behjd9
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!
rjbs ciao!
21:37 rjbs left
Andy Once again, my job of bringing appropriate people together has been fulfilled. 21:41
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:43
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? ;-)
pmichaud jonathan: stuff for moritz, mostly. 21:46
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.
jonathan pmichaud: that's only true if people discover *and* patch a bug themselves. 21:47
pmichaud I don't understand.
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.
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.
i.e., if someone adds a new feature, we'd like there to be a test for it.
jonathan Yes, true.
Agree totally.
Maybe we can ask people to specify where the tests that it makes pass are, in the commit message, too?
pmichaud maybe I just need to write a comment that says "awaiting confirmation of spectest" before the commit gets applied.
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
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.
Basically a set of patch submission guidelines.
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?
jonathan I'm pretty sure there'll be cases where we want to apply it locally for testing first. 21:53
Which is fine too.
pmichaud is there an easy way for "apply locally"?
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.
I think you can select which branch you put it into.
pmichaud sure, I'm more curious about the functional patches as opposed to the auxiliary ones.
jonathan Rather than master. 21:55
pmichaud iwabni my comments on patches went to a mailing list.
so that everyone can see the discussion, and not just the requestor.
jonathan Yeah
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
They can link to github in the RT
And mention the spectests that are applicable.
pmichaud that feels like "extra work" to me somehow.
jonathan Then we keep discussion there.
It's no more than we already did.
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.
jonathan Following a link to github isn't that more of a burden, is it?
Especially when application might potentially be a click away if you trust the patch enough.
pmichaud it's a burden for the person composing the rt ticket to include the link. But perhaps not that much of a burden.
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.
But then we're back to how to facilitate open discussion on the patch.
pmichaud right.
jonathan Or are the comments posted publicly?
pmichaud I think they're public, but I don't know how one would get to them.
jonathan Do they not just appear on the page with the patch? 21:59
pmichaud if someone goes looking for them, yes.
the nice thing about a mailing list is that one doesn't have to go looking for it.
it shows up in the inbox.
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.
jonathan Thus why I suggested sticking with RT for patch discussion.
Aye.
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 rrot: r37006 | NotFound++ | trunk (3 files):
[core] add a wrapper function to call PackFile_fixup_subs PBC_LOADED from embedding
pmichaud otoh, being able to privately reject a proposed commit is nice -- it has less of a "public rejection" about it.
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.
jonathan Aye 22:02
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?
pmichaud well, someone should only request pulls for things they think ought to be applied.
Coke *they
jonathan Yes.
pmichaud if it's a work in progress, they shouldn't request a pull.
jonathan Agree - I'm talking more about just browsing the fork queue for stuff to apply. 22:04
pmichaud I don't follow.
jonathan For if we're only going to look at things people mention in RT or request a pull from, that's fine.
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.
pmichaud oh, does the fork queue show all of the work that anyone has done?
oh.
jonathan I'm not sure.
pmichaud that would be a bit weird. 22:06
jonathan My impression was that it just showed almost anything.
Tene pmichaud: you can change the branch you're committing to in the gui. Have an 'integration' branch or whatever.
NotFound ./objectref.c: In function ‘void Parrot_ObjectRef_class_init(parrot_interp_t*, int, int)’:
./objectref.c:3611: error: conversión inválida de ‘void (*)(parrot_interp_t*, PMC*, INTVAL)’ a ‘void (*)(parrot_interp_t*, PMC*, PMC*)’
Tene pmichaud: you can also add other people's repos as remotes in your local git checkout
and work with the commits through git or a git gui locally.
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++
pmichaud so "adding other people's repos" doesn't sound like a queue.
Tene pmichaud: you were asking about how to confirm spectest passes before committing.
you could just check out their branch directly in your local checkout
pmichaud Tene: well, "confirm spectest passes" sounds like a command-line sort of thing.
Tene: would checking out their branch get all of their commits to that branch? 22:08
Coke nick Coke_afk
Tene pmichaud: yes.
pmichaud: well, whatever you want it to do, I guess
pmichaud right, I'm usually interested in cherry-picking commits. 22:09
Tene And you could make a local branch, cherry-pick it in
pmichaud as opposed to grabbing someone's entire branch. Especially since folks tend to put multiple separate items in a single branch.
right, I'm looking for easier ways to do the cherry-picking.
my current mental model for processing patches goes something like: 22:10
(1) start with a clean version of head
(2) apply a proposed patch
(3) run 'make spectest'
(4) push patch to head
it's the "apply a proposed patch" step that I haven't quite figured out yet. 22:11
Tene git cherry-pick XXXXX
pmichaud where XXXXX is a url?
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.
I'd prefer to not have to maintain tha tlist.
Tene How's that?
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:13
Tene Hmm. 22:14
pmichaud I'd prefer to be able to grab commits out of the fork queue directly.
Tene investigates. 22:15
pmichaud or have git/github be smart enough to figure that out.
anyway, I have to take kids to dinner and other errands -- bbl.
22:15 Whiteknight joined
Tene pmichaud: you could pull them into a new branch in the rakudo repo 22:16
click on the 'change it' link by the top of the fq page.
That will cherry-pick them into that branch
pmichaud it still feels like I'm having to do a lot more commit management than ought to be necessary. 22:18
move to a branch, test the branch, move to master
etc.
especially if I'm having to do all of this on github. I ought to be able to do it in my local repo.
anyway, I do have to go.
bbl
jonathan btw report use.perl.org/~JonathanWorthington/journal/38550 22:22
cotto does make headerizer take care of the ASSERT_ARGS macros? 22:28
jonathan I believe so. 22:29
cotto yup
that makes life a little nicer
we need to add "make dtrt" 22:33
22:36 rurban joined
chromatic pmichaud, candy 22:37
jonathan YAY 22:38
See, it's not just me...
chromatic Even though I was late, I had to show solidarity. 22:43
dalek rrot: r37007 | NotFound++ | trunk/examples/embed/lorito.c:
[examples] fix lorito C build
 22:53
cotto Would it be ok to rewrite the Sub_comp_* macros to operate directly on a Parrot_sub rather than a PMC? 23:06
There are only a handful of instances that'd need to be updated. 23:07
NotFound cotto: will be better to make them const-aware 23:09
His current implementation force some const casts completely unneeded 23:10
cotto I saw that in a comment.
If it's not a hard fix, I could easily do it while I'm in there.
</tautology> 23:11
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.
NotFound There is some reason to have config.o out of libparrot? 23:14
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:17
dalek rrot: r37008 | NotFound++ | trunk/examples/embed (2 files):
[examples] link and use parrot_config in lorito
 23:22
cotto NotFound, there's a little too much yak shaving involved for me to do that fix with this commit. 23:28
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.
PacoLinux arlosmar: es cierta la noticia esa que han pegado por aqui ?
NotFound PacoLinux: no :D
PacoLinux jejeje
si dijeran algo malo de mi, por lo menos intentaria defenderme .. 23:31
NotFound PacoLinux: wrong channel
PacoLinux sorry ...
23:35 kid51 joined, bacek_ joined 23:39 Limbic_Region joined
NotFound Oh, the messages are due to the Parrot_setwarnings(interp, PARROT_WARNINGS_ALL_FLAG); in lorito 23:42
I CAN HAZ LOLCODE EMBEDED 23:43
jonathan I HAZ A LOLCODECOMPILER ITZ WIN 23:46
BTW THAT'S AWESOME 23:47
NotFound Now you can try to add LOLCODE macros to vim ;) 23:51
jonathan I suppose it's lighter on the parentheses keys than writing lisp macros for emacs... 23:52
NotFound It's strange that nobody has written yet a parrot vm in elisp 23:53
Tene a VM in elisp?
NotFound Don't say that too loud, they can hear us ;) 23:54
Tene What's lorito?
purl it has been said that lorito is "little parrot" in spanish or examples/embed/lorito.c
NotFound Tene: examples/embed 23:55
Hey, even purl knows
nopaste "tene" at 148.87.66.57 pasted "cd examples/embed ; make" (16 lines) at nopaste.snit.ch/15721
NotFound Tene: look at the Makefile comments 23:56
Tene Wait, you mean I need to READ?
I don't like the sound of this project.
NotFound It's in examples for some reason ;)
dalek rrot: r37009 | jkeenan++ | trunk (4 files):
Applying documentation fixes found in patch submitted by ronaldws in trac.parrot.org/parrot/ticket/377.
 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!