Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-09-14

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

All times shown according to UTC.

Time Nick Message
00:31 whiteknight left #parrotsketch
00:45 bluescreen joined #parrotsketch
02:35 contingencyplan left #parrotsketch
03:10 tcurtis joined #parrotsketch
03:10 bluescreen left #parrotsketch
03:26 contingencyplan joined #parrotsketch
03:28 Coke left #parrotsketch
05:48 gottreu joined #parrotsketch
05:50 cotto left #parrotsketch
05:50 cotto joined #parrotsketch
06:06 gottreu left #parrotsketch
06:44 contingencyplan left #parrotsketch
06:57 contingencyplan joined #parrotsketch
07:59 contingencyplan left #parrotsketch
08:12 tcurtis left #parrotsketch
12:47 eternaleye_ joined #parrotsketch
12:49 eternaleye left #parrotsketch
12:49 pmichaud left #parrotsketch
12:49 PerlJam left #parrotsketch
12:49 sorear left #parrotsketch
12:51 pmichaud joined #parrotsketch
12:51 sorear joined #parrotsketch
12:51 PerlJam joined #parrotsketch
14:16 dukeleto joined #parrotsketch
14:23 dukeleto What I did:
14:23 dukeleto * Kept parrot.git in sync
14:23 dukeleto * Ran Rakudo spectests and found coredump in icu-less Parrrot, which got fixed
14:23 dukeleto * Added some spectests to roast.git
14:23 dukeleto * Hacked on leto/git_docs and leto/kill_svn_tests branches on github
14:23 dukeleto * Only a few tools are left to convert
14:24 dukeleto * I would guess i am 70% done with documentation
14:24 dukeleto What I will do:
14:24 dukeleto * Attempt to port the last few tools this week
14:24 dukeleto Blockers:
14:24 dukeleto * Jury Duty (which I will be at today)
14:24 dukeleto .EOR
15:42 mikehh joined #parrotsketch
16:10 contingencyplan joined #parrotsketch
16:21 kid51 joined #parrotsketch
16:37 kid51 kid51's report
16:38 kid51 CODE STUFF
16:38 kid51 * Poked around in older tickets to see which might be closable; communicated about those with other devs via list, email, IRC and IRC private message.  Closed about 6 myself.  Applied patches submitted in various tickets by ash++ and ronaldws++.
16:38 kid51 * The usual coding standards corrections.
16:38 kid51 DIRECTORIAL STUFF
16:38 kid51 * On list and blog, posted proposal for a one-day F2F gathering of Parrot devs to be held in Portland OR USA Sat Oct 16.  5 people have expressed interest so far.  Need to start discussing venue with dukeleto and other Portlanders.
16:38 kid51 * Plan to meet with whiteknight Sat Sept 18.
16:38 kid51 COMMENTS
16:39 kid51 We have a lot of dynamic activity in core source coding from both older (e.g., bacek, chromatic, cotto, fperrad, NotFound) and newer developers (e.g., luben, Paul_the_Greek, nwellnhof).
16:39 kid51 * But our ability to *test* this coding is in a funk:  No smolder server.  Inadequate testing against important projects built on top of Parrot.  Frustration among HLL developers when changes to Parrot core break their builds or cause their spec tests to fail.
16:39 kid51 What steps can we take to remedy these problems before, say, 2.9 (Oct 19 2010)?  Discuss.
16:39 kid51 EOR
16:58 luben joined #parrotsketch
17:10 luben What I did:
17:10 luben * helped hunting for a bug that affected amd64 optimized builds
17:10 luben * hash: inlined hashing and comparison functions. This moves runtime
17:10 luben indrection to compile-time indirection - generally faster.
17:10 luben * merging the branch reverted some previous commits - it's my fault.
17:10 luben I fixed this mis-merge.
17:11 luben * hash: moved memory allocations for small hashes from system malloc
17:11 luben to fixed size memory allocator. Also, hash buckets/index space is
17:11 luben now lazy allocated
17:11 luben What I will do:
17:11 luben * Look in our GC and figure out how it works
17:11 luben .EOR
17:35 contingencyplan left #parrotsketch
17:38 contingencyplan joined #parrotsketch
18:41 kid51 left #parrotsketch
19:11 whiteknight joined #parrotsketch
19:18 whiteknight WHAT I DID:
19:18 whiteknight * Sent out a call for new release managers. Luke-warm response, but enough to get us through the end of the year.
19:18 whiteknight * Finished up my PLA work and am prepared for a release after 2.8.0 comes out.
19:18 whiteknight * On IRC, chatting and answering questions
19:18 whiteknight WHAT I WILL DO:
19:18 whiteknight * Looking to put together a prototype of Chandon's green threads on Win32, since his work was posix-only.
19:18 whiteknight * Chandon mentioned some potential problems involving the intersection of threads, exceptions, and inferior runloops. Examining that.
19:18 whiteknight * Looking into the GC. I want to start pushing the gc_massacre branch into high gear and get some kind of framework merged into trunk for future development. Merge probably won't happen this week, there looks to be a lot of work to be done.
19:18 whiteknight * luben++ made a commit to trunk that mirrored what I was planning in the hash_allocator branch and appears to bring a nice speedup. Examining that.
19:18 whiteknight * Meeting with kid51 in person next weekend, planning for that.
19:18 whiteknight WHAT I AM BLOCKING ON:
19:18 whiteknight * Nothing
19:23 NotFound joined #parrotsketch
19:32 whiteknight left #parrotsketch
19:46 NotFound What I did:
19:46 NotFound -parrot
19:46 NotFound * Fought the amd64 problems with many others
19:46 NotFound * Avoided infinite catching of exceptions while dying from exception
19:46 NotFound * Fixed some $Id that were getting expanded by svn inapropiately
19:47 NotFound * Added a check for duplicate vtable entries in PMCs.
19:47 NotFound * Killed several things that had reached the end of its deprecation cycle.
19:47 NotFound * Added more core pmc tests.
19:47 NotFound * Other minor fixes and cleanups.
19:47 NotFound -winxed
19:47 NotFound * Allowed use of $ sign in identifiers.
19:47 NotFound * Added $load directive.
19:47 NotFound * Improved class declarations, new operator and constructor calling.
19:47 NotFound * Anonymous functions, they are not closures yet but allows some usages.
19:47 NotFound * Using several of the new features in the compiler and tools.
19:47 NotFound * Several bug fixes
19:47 NotFound * Working on a module that wraps Gtk2 via blizkost, looks promising.
19:47 NotFound Provisional name: glueglass
19:47 NotFound What I wil do:
19:47 NotFound No fixed plan.
19:47 NotFound EOR
19:47 plobsing joined #parrotsketch
19:51 mikehh What I did since my last report:
19:51 mikehh * building and testing parrot on amd64/i386, with gcc/g++
19:51 mikehh * some fixes
19:51 mikehh * installed Ubuntu 10.10 beta amd64 with Perl 5.12.2 using gcc-4.5.1
19:51 mikehh (rather than default 4.4.4) and got parrot to build/test with
19:51 mikehh it (gcc-4.5 and g++-4.5)
19:51 mikehh What I intend to do in the next week:
19:51 mikehh * testing and fixing
19:51 mikehh .eor
19:52 plobsing What I Did:
19:52 plobsing * eliminated cruft left over after dynops_mapping
19:52 plobsing * bughunting
19:52 plobsing What I Plan:
19:52 plobsing * no plan
19:52 plobsing EOR
19:54 kid51 joined #parrotsketch
19:57 atrodo joined #parrotsketch
20:08 cotto #done:
20:08 cotto - a little digging into git conversion, not much else
20:08 cotto - wrote up a manual test for the github plugin
20:08 cotto - ended contract for $dayjob, many tuits expected to follow
20:08 cotto #to do:
20:08 cotto - netflix instant queue
20:08 cotto #eor
20:08 nwellnhof joined #parrotsketch
20:10 nwellnhof what i did
20:11 nwellnhof - charset_massacre merge and related work
20:11 nwellnhof - bug fixes
20:11 nwellnhof plans
20:11 nwellnhof - more string encoding related cleanups
20:12 nwellnhof - work on configure scripts
20:12 nwellnhof eor
20:12 Util # Recently done:
20:12 Util * Converted kid51++'s Win32 report to Report {26}
20:12 Util * Wrangled RT#77778 - Rakudo spectest fail on non-ICU nee 64-bit.
20:12 Util # Plan to do:
20:12 Util * TT#1570 - update with strategy, and behind-release info
20:12 Util = T2 @ Parrot 2.3, MacPorts,CygWin,Debian @Parrot 2.6
20:12 Util * Perl 5-to-6 migration code (name: Blue Tiger) -> GitHub, though very incomplete
20:12 Util # Blockers:
20:12 Util * Tuits short but >0 this week.
20:12 Util # Ticket changes in the last week:
20:12 Util curl -s 'http://trac.parrot.org/parrot/timeline?daysback=7&amp;ticket=on' | perl -wlne '/<em[^>]+\(([^"]+)\)">/ or next; $h{$1}++; END {printf "%7d\t%s\n", $h{$_}, $_ for sort keys %h}'
20:12 Util 2 closed: done
20:12 Util 27 closed: fixed
20:12 Util 1 closed: invalid
20:12 Util 18 new
20:12 Util 2 reopened
20:12 Util ( -10 total )
20:13 Util .end
20:15 Tene The only parrot-related work I've done is thinking about going to the hackathon in portland posted to the mailing list.  EOR.
20:25 allison joined #parrotsketch
20:28 Paul_the_Greek joined #parrotsketch
20:28 Paul_the_Greek Hello everyone.
20:29 chromatic joined #parrotsketch
20:30 cotto hio
20:30 pmichaud hello
20:30 mikehh hello
20:30 NotFound Hola
20:31 kid51 hello
20:31 Util Hello
20:32 allison hi
20:32 nwellnhof servus
20:32 chromatic hello
20:32 chromatic let's review the past week
20:32 chromatic How's our bug count?
20:33 cotto we definitely hit our goal for closed bugs, but we got some new ones too
20:33 mikehh looks good
20:33 kid51 629 by my count; down from 675-ish a month ago
20:33 chromatic ~50/month is a very good rate.
20:34 nwellnhof 280 of them are bugs, down from about 310 two or three weeks ago
20:34 dukeleto hola
20:34 chromatic How'd we do with branch merges?
20:35 nwellnhof charset_massacre has been merged
20:35 Paul_the_Greek sleeker_boolean merged; thank you kid51
20:35 Paul_the_Greek (causes a problem with Rakudo)
20:35 chromatic hash_inline merged, had some problems there, but sorted now
20:36 chromatic That leaves (by my estimation) the docs revamp and the gc massacre, as big branches we'd targeted.
20:36 chromatic (as well as the GSoC branches)
20:36 chromatic Anything else related to branches and merges to report?
20:36 cotto When I tried to test the gc massacre  branch after bacek++'s recent sync, my machine became unresponsive.
20:37 mikehh didn't get a chance to work on html_cleanup, will do so this week
20:37 cotto ulimit is highly recommended when testing
20:37 chromatic The string compactor there does not work well with NQP-rx.
20:37 NotFound There is a problem with a backwards-incompatible change in ByteBuffer from the charset massacre
20:38 NotFound A method that took two parameters and now only wants one.
20:38 chromatic Let's table the deprecation question for a moment.
20:38 chromatic Anything else on branches?
20:39 mikehh there seem to be problems with consting since immutable string = some thing that should be const are not
20:39 mikehh holdovers AFAICS
20:39 chromatic There are probably some places where we assume STRINGNULL == NULL pointer too.
20:40 nwellnhof i found some of those in src/dynext.c
20:40 mikehh this generally causes problems with g++ builds
20:40 nwellnhof patch coming up soon
20:40 chromatic Placeholder question regarding branches for question time: were our merge problems this week bad luck, bad planning, or something else?
20:40 chromatic How's the Git migration planning?
20:40 dukeleto Well.
20:41 cotto quite well
20:41 NotFound The consting problem is hard to solve unless we change vtable interface declarations to take const in all STRING * args.
20:41 Paul_the_Greek The sleeker_boolean branch causes problems with Rakudo.
20:41 cotto progress and goals are on GitMigration on the wiki
20:41 Tene deprecation question also applies to rakudo's problems here
20:41 dukeleto I just ported mk_manifest_and_skip.pl to git
20:42 chromatic How much work is left on the migration plan before we can set a concrete date?
20:42 dukeleto chromatic: good question
20:43 dukeleto chromatic: i think only 2 tools are left to translate
20:43 chromatic Post 2.9 is possible then?
20:43 dukeleto chromatic: mk_language_shell and create_language
20:43 dukeleto chromatic: that gives us about a month? that sounds reasonable
20:44 chromatic Just a thought.
20:44 dukeleto it is mostly logistics and finishing up docs at this point
20:44 cotto very reasonable
20:44 dukeleto yes, let's plan for just after 2.9
20:44 chromatic Let's set some goals for this week.  Ticket number?
20:44 cotto I'm very confident that'll work.
20:45 whiteknight joined #parrotsketch
20:46 mikehh let's try the same again
20:46 chromatic 25?
20:46 mikehh yeah
20:46 Paul_the_Greek Go for it.
20:46 cotto it's worked well so far.  +1
20:46 dukeleto +1 to closing 25 tickets this week
20:46 cotto fun for the whole family
20:46 chromatic Okay, same song third verse.
20:47 chromatic Other suggestions for work?  Remember, next week is 2.8.
20:47 NotFound Easy targets: there are things that ended its deprecation cycle waiting for some nice killing.
20:47 chromatic Deprecation removal and deprecation listing?  +1
20:47 Util Smolder server
20:47 mikehh well let's not go for things that might break anything, but small fixes
20:48 Paul_the_Greek I have a question about the debugger.
20:48 cotto after Saturday, at least
20:48 NotFound mikehh: the purpose of the deprecation cycle is being able to kill.
20:48 cotto We want a solid release, but we don't need to be too conservative for a devel release.
20:49 dukeleto smolder++
20:49 mikehh kill, kill, kill, veins in the teeth etc.
20:49 chromatic Other thoughts on making deprecations a priority?
20:49 cotto we have one on parrot.org.  Does anyone (hi particle) know its status?
20:49 kid51 While 2.8 may be just a devel release, there was enough breakage, particularly in HLLs, in past week that I would recommend code slush start soon.
20:49 dukeleto chromatic: we need to make HLLs author feel that we don't hate them
20:49 kid51 So that we can sort out all those issues.
20:50 mikehh w3e need to point to it
20:50 NotFound The CodeString issue: fix things that depends on it as soon as possible.
20:50 NotFound Notably, json.
20:51 pmichaud I already wrote a version of data_json that doesn't need pge/tge/codestring if anyone wants to adopt it.
20:51 plobsing q1q
20:51 pmichaud on the other hand, I couldn't find anything that depended on data_json
20:51 whiteknight I suggest we use pmichaud's version, if we can make the interface compatible
20:51 chromatic +1
20:51 cotto +1
20:51 dukeleto +1
20:52 cotto let's use some of those fancy tools
20:52 Paul_the_Greek Question about the new Boolean?
20:52 chromatic Now onto Smolder: who's watching that?
20:53 dukeleto chromatic: particle and I
20:53 dukeleto chromatic: particle needs OSUOSL to allow him to add smolder users
20:54 dukeleto chromatic: currently he cannot, so we are stalled there
20:54 chromatic alright, we'll keep asking then
20:54 dukeleto chromatic: when he can add users, he will add a smolder user with the exact same user/pass our code expects, and then things will Just Work
20:55 chromatic To review then: close 25 tickets, revew deprecations (remove/record), fix the CodeString mess, and make a great 2.8 release.
20:55 whiteknight +1 I'm very very happy to hear we're getting a smolder server set up soon
20:55 whiteknight particle++ dukeleto++
20:55 chromatic Branch merge question then: what happened and why was it so difficult for Rakudo?
20:56 mikehh whiteknight: BTW you can add me to do another release some time
20:56 Paul_the_Greek Regarding Boolean, we broke some tests that assume it inherits from Integer.
20:56 cotto One problem was that we didn't realize that Boolean not subclassing Integer would constitute an api break.
20:57 chromatic I have trouble considering that an API break.
20:57 Paul_the_Greek I think we realized this, but we chose to ignore it.
20:57 chromatic ... not that I'm arguing for breaking Rakudo without warning.
20:57 Paul_the_Greek Does it rely on inheriting Integer, or simply test that it does?
20:57 whiteknight mikehh: Sure! Any requested dates? I think we have 2010 filled
20:58 mikehh whiteknight: next year then
20:58 Paul_the_Greek So should we fix it by hacking Boolean to pass the tests, then deprecate those hacks?
20:58 chromatic If this is something we think the deprecation policy should cover, yes.
20:59 Paul_the_Greek I think the documentation said it inherits from Integer, so I guess it was part of the API.
20:59 chromatic If it's documented, then yes.
20:59 chromatic Filthy hack ahoy.
21:00 luben About hash_inline_func merge, I reverted already commited change. It was my fault
21:00 cotto (Another Rakudo break was due to a mis-merge that unreverted a change, which luben took care of.  This sort of thing can be expected to go away after git o'clock.)
21:00 Paul_the_Greek Who do I talk to to find out what Rakudo relies on in Boolean?
21:00 * cotto is just a little too late today
21:00 pmichaud Paul_the_Greek: it wouldn't have helped in this case (more)
21:00 whiteknight the inheritance chain of a built-in type does smell to me like it's not really part of an "API"
21:00 chromatic #perl6 on freenode, but that's just asking someone to run tests against the branch
21:01 pmichaud you can ask "does Rakudo rely on Boolean being a subclass of Integer", and we could've searched for all of our uses of Boolean and not discovered this particular breakage.
21:01 whiteknight the break in MMD semantics is the big issue, and I think we can fake that reliably
21:01 Paul_the_Greek whiteknight: I'd agree, but you know my opinion on booleans being integers. :D
21:01 pmichaud in fact, "Boolean" appears in Rakudo's source exactly once.
21:01 pmichaud er, twice.
21:02 Paul_the_Greek I see your point. I guess the question is, which integer operations do you expect to be able to perform on booleans?
21:02 mikehh was it the tests that made the assumption?
21:02 pmichaud We don't expect any.
21:02 pmichaud That's not what broke.
21:02 Paul_the_Greek What broke?
21:03 pmichaud mmd dispatch
21:03 pmichaud because Boolean is no longer an Integer, it ends up dispatching to an entirely different function
21:03 Paul_the_Greek Why would there be a dispatch that expected to match a boolean argument to an integer?
21:03 pmichaud you can ask "why" and there will be no answer.
21:03 chromatic Because it used to work that way, and someone assumed that was the way it should work.
21:04 pmichaud no
21:04 pmichaud because it used to work that way, and it didn't cause any problems that caused someone to say it should be different
21:04 Paul_the_Greek Now I'm lost.
21:04 pmichaud there was no overt planning or recognition that boolean needed integer capabilities whatsoever
21:04 chromatic I don't see an effective difference in explanation.
21:04 whiteknight NotFound posted a patch to that ticket that overrides ISA to make boolean look like an Integer in those cases. Does that patch fix Rakudo's broken tests?
21:04 pmichaud at no time in the rakudo implementation process did someone say "aha, this Integer case will cover the Boolean case as well"
21:05 Paul_the_Greek That's interesting. The old Boolean was careful to allow -bool, for example.
21:05 pmichaud what happened is that the Integer case was implemented, and then when we started using booleans nothing failed so nobody realized there was a potential problem to fix.
21:05 chromatic Sure, someone just wrote code with an assumption that we broke.
21:05 pmichaud right
21:05 Paul_the_Greek Ah, okay.
21:05 pmichaud the person who wrote code didn't recognize that an assumption was being made.
21:05 pmichaud it worked, and that was good enough.
21:06 chromatic Nor did anyone who made Boolean inherit from Integer either.  Lots of assumptions all around.
21:06 Paul_the_Greek So how do we know what hacks to add to Boolean, or do we go back to inheriting from Integer?
21:06 whiteknight exact reasons are not so much important as making sure we have a working release next week
21:07 pmichaud as I said, from Rakudo's perspective it's perfectly okay if Boolean doesn't emulate its Integer behavior
21:07 whiteknight so the question is this: do we back out the integer changes, add a hack to make it appear to work the same way, or ignore it and let Rakudo fix it?
21:07 chromatic The only hack we seem to need to add to Boolean--if this is a deprecation policy issue--in this case is adding the hack that Boolean isa Integer.
21:07 pmichaud Rakudo will adapt around it without too much difficulty.
21:07 pmichaud I'm not at all requesting the hack on Rakudo's behalf.
21:07 whiteknight I don't want to put strain on rakudo unnecessarily. This is our mess after all
21:07 Paul_the_Greek chromatic: How do we know that? How do we know it doesn't expect to be able to add a Boolean?
21:07 pmichaud it's not a strain (more)
21:08 pmichaud my ticket was filed not on behalf of Rakudo, but on behalf of any other dark-parrot users that might also be relying on the behavior.
21:08 pmichaud I was totally surprised when Rakudo broke.
21:08 whiteknight pmichaud: that said, with the release coming up and a decision being made here, what would you like to see happen?
21:08 pmichaud and fixing Rakudo (which we'll have to do in a month anyway) is far less work than the hack to get Boolean to act like an Integer again.
21:08 whiteknight if you were ruler of the universe
21:08 Paul_the_Greek He is sounds like a benevolent ruler.
21:09 NotFound I proposed that hack as a last resource, not as a beautiful thing, I have to say ;)
21:09 Paul_the_Greek You made that clear, NotFound.
21:09 pmichaud Personally, if Boolean is not going to be derived from Integer in the long run, and we can come up with a clean way to minimize impact on any (non-Rakudo) users, that'd be fine with me.
21:09 pmichaud so I'd prefer to see the existing non-hacky code stay somehow.
21:10 whiteknight okay. That does make the most sense
21:10 Paul_the_Greek Shall I do some polling of other HLLs?
21:10 whiteknight Paul_the_Greek: Can we back out the branch changes, keep the branch around, and merge it later?
21:10 chromatic -1 to keeping the branch around for later
21:10 pmichaud -1 here also
21:10 plobsing proposal: if HLLs want Boolean to be isa Integer, can they just .hll_map it to Integer?
21:10 Paul_the_Greek Ouch. I'd rather add a hack or two. But kid51 will testify to my concern.
21:10 pmichaud plobsing: hll_map doesn't work that way.
21:11 NotFound Winxed has no problem. It can break usages from winxed, but winxed has not deprecation police for a now.
21:11 Paul_the_Greek Perhaps I should contact other HLLs and report back next week?
21:11 pmichaud and again, I don't think it's at all the case that any HLL _wants_ Boolean to be an Integer.
21:11 chromatic I agree.
21:11 pmichaud Rakudo certainly doesn't care about it.  The question is simply one of "how far does the deprecation policy extend?"
21:12 chromatic If we can't change internal only details of the implementation because of the deprecation policy, -1 to the deprecation policy.
21:12 pmichaud as ruler of the universe, I'd want to see a structure for nicely handling the cases where deprecation occurs (i.e., handle failures gracefully) rather than to proclaim that they will never happen.
21:12 Paul_the_Greek Here's what the documentation says: Albeit the Boolean PMC is derived from the Integer PMC, it doesn't morph to other types.
21:12 pmichaud *where deprecation failure occurs
21:13 Paul_the_Greek No other mention of Integer.
21:13 chromatic Nice documentation.  "Hi, here are specific implementation details -- oh, and we're telling you specifically we've never heard of the LSP!"
21:14 pmichaud imo, Parrot is going to have too many substantive changes over the next year to expect that the deprecation policy will be followed without mistake.
21:14 NotFound The problem is that we don't have a documentation good enough to draw a clear line between internals and public.
21:14 chromatic Proposal: no branch merges to trunk until trunk is safe for Rakudo.
21:14 Paul_the_Greek But sometimes the fact that A inherits from B is a feature.
21:14 whiteknight Well, I've always hated the deprecation policy, and would like to light it on fire and do horrible things with the ashes. So any changes to the policy will be welcomed
21:15 pmichaud indeed, last night I made a personal decision to just not report deprecation failures in the future, because I don't believe in the policy in the first place.
21:15 whiteknight pmichaud: do you believe we should have *any* deprecation policy?
21:15 whiteknight or just not the one we have now?
21:15 pmichaud whiteknight: I don't know a good answer to that.
21:16 whiteknight I ask you because you're the point person on one of our biggest dependent projects
21:16 pmichaud right.
21:16 whiteknight so you're the most effected by the policy
21:17 pmichaud I think I'm still in a mode where "seeing significant improvements to Parrot" outweighs "don't break Rakudo", as long as no individual monthly release irreparably breaks Rakudo.
21:17 nwellnhof the parrot developers should simply run Rakudo's make spectest more often
21:17 whiteknight the spectest does take a hell of a long time to run
21:17 pmichaud i.e., we'd like to make sure that Rakudo can build against Parrot monthly releases -- even if that means Rakudo has to adapt quick to an unanticipated Parrot API change.
21:17 whiteknight (I'm not arguing against it, really, just saying)
21:18 kid51 One of the problems we have is judging the "significance" of various proposed improvements to Rakudo -- whereas "Rakudo has broken" is very clear-cut.
21:18 chromatic It's not about "Does this change Rakudo's spectest status?"
21:18 NotFound nwellnhof: if the parrot developers spend its time doing that frequentrly, they can't develop.
21:18 whiteknight kid51: agreed. What would be ultimately nice to have is a weighted list of wants vs don't-wants, and what people would be willing to trade
21:19 cotto Can we get a buildbot to run Rakudo's spectest with the latest parrot at regular intervals?
21:19 whiteknight so a new feature that brings great bonuses and causes minor failures could get the greenlight
21:19 kid51 NotFound: But we need to do test against HLLs in an *automated* way *much* more than we do now.
21:19 cotto and gripe in #parrot when a failure pops up?
21:19 whiteknight cotto: buildbot +1
21:19 cotto though separating signal from noise may be tricky
21:19 chromatic ... add a policy to merge no branch until trunk is green for Rakudo.
21:19 plobsing buildbots are great, but when preparing branch merges, buildbots on trunk don't really help
21:19 luben buildbot +1
21:20 pmichaud btw, if Rakudo's spectest is taking too long, you folks are the ones that can most help with that :-P
21:20 luben +1 for what chromatic said
21:20 cotto pmichaud, zing!
21:20 dukeleto i am very +1 to smoking all branches
21:20 Util New option needed in Rakudo?  `perl Configure --gen-parrot-HEAD` ?
21:20 pmichaud I'll happily add a --gen-parrot-HEAD if that helps.
21:20 mikehh It would be nice to have more buildbots like taptinder
21:20 cotto How about "all *recent* branches"?
21:21 cotto (commits within the last week or so)
21:21 mikehh especially on different platforms
21:21 plobsing how about specially marked branches? most of the time I don't care about those results yet
21:21 chromatic Let's worry about Rakudo HEAD and Parrot HEAD first, then get more creative.
21:21 cotto how would they be marked?  buildbot instructions over irc?
21:22 cotto +1
21:22 mikehh marked when ready for testing
21:22 pmichaud actually, I'll probably change it to be  --gen-parrot=<revision>   , to be able to easily grab any revision of Parrot.  The default with no = value will be the existing default.
21:22 pmichaud so then it would be --gen-parrot=HEAD
21:22 cotto this sounds great
21:22 Util +1
21:22 cotto we need more visibility for Rakudo spectest failures
21:23 whiteknight getting them posted on smolder, when it gets working, would be killer
21:23 tcurtis joined #parrotsketch
21:23 chromatic Does this begin to address concerns?
21:23 Util cotto: bot announce on #parrot / #rakudo of spectest fail?
21:23 cotto yes
21:24 cotto for parrot head vs rakudo head
21:24 chromatic Any specific changes to the deprecation policy come to mind besides this?
21:25 cotto As an aside, I'm very happy to see others adding upgrade paths for upcoming deprecations.
21:25 whiteknight clarifications about what exactly constitutes an API would be nice
21:26 NotFound ack PARROT_API still doesn't show anyhing relevant.
21:26 chromatic We could exclude "inheritance details" from API details.
21:27 NotFound So in theory we can change almost snything X-)
21:27 Paul_the_Greek But sometimes the inheritance is a feature, no?
21:28 chromatic If it is, we document it as part of the interface and write tests for it.
21:28 chromatic Maybe that's the change we need to the documentation policy.
21:29 NotFound Supposedly we have "does" for particular needs.
21:29 chromatic "If you rely on this and there aren't tests for it, you should let us know so we can write tests for it."
21:29 pmichaud that helps if we know we're relying on something :)
21:29 pmichaud even if inheritance isn't part of the API, inherited methods ought to be.
21:29 allison left #parrotsketch
21:30 chromatic Anything else on this discussion?
21:30 NotFound For example, all Handles in the repo have isatty, the unworded assumption is that you write a Handle type that doesn't inherit from Handle you should provide that method.
21:31 NotFound If you wnat it able to be used were a Handle is expected, that is.
21:33 chromatic Let's move on to other questions.
21:33 chromatic plobsing?
21:34 * kid51 leaves; will backscroll
21:34 kid51 left #parrotsketch
21:34 Paul_the_Greek I have a debugger question.
21:34 plobsing generational gc, as I understand it, requires some extra stuff around reference assignments
21:35 Paul_the_Greek Barriers?
21:35 plobsing if we want to get this in the next couple of months, we need a dep notice, since this is likely to affect all parrot native users (extend, embed, pmc2c, ops2c)
21:35 chromatic Our pointers are already opaque.
21:35 chromatic Except in the cases of dynpmcs.
21:36 plobsing dynpmcs are the main problem.
21:36 chromatic We'd need to figure out the upgrade path then.
21:36 whiteknight we had barriers at one point and never enforced them. We may still have them
21:36 nwellnhof it would be a big help if everyone would use SET_ATTR
21:36 whiteknight saying we're going to enforce something we already should have been doing isn't really a matter for deprecation
21:37 plobsing but we already provide interfaces to circumvent this
21:37 plobsing PARROT_IMAGEIO(SELF)->unsafe_attribute_access
21:38 whiteknight for internal-use only
21:38 chromatic when it breaks, don't report GC bugs
21:39 whiteknight I say, don't report GC bugs anyway. They're a hassle :)
21:39 plobsing if it's already an explicit requirement that is simply not checked, great - no deprecation. but we should scream this loudly somehow so users unaware of the requirement (I was unaware) don't get hard to debug gc problems
21:39 NotFound Use the infinite memory gc, and buy more memory.
21:40 chromatic If there's consensus to document those macros as safe, let's do it.
21:41 whiteknight for the current GC, those macros are empty. Can't get more safe than that
21:41 NotFound If gc is going to be pluggable, that macros should dispatch at runtime, not depending on configure choosen options.
21:42 NotFound The impact of that can be noticeable.
21:42 chromatic Do we have a volunteer to do some research?
21:42 plobsing research how?
21:43 chromatic What are we likely to deliver by 3.0 and what do we need to recommend for deprecation-safe source before then?
21:44 plobsing I can try to do that.
21:45 pmichaud <naive> I would think a good first step would be to have a Parrot that uses generational gc (or some other gc) period, disregarding deprecation issues for the moment.  We don't even seem to have been able to get that far. </naive>
21:46 chromatic any other questions?
21:46 whiteknight That's my feeling. The faster we can get that particular feature in, the better off everybody wil be
21:46 whiteknight why do bad things happen to good people?
21:46 pmichaud once we can get a parrot that can run with some other non-trivial gc (likely in a branch), then we can address "okay, what does this imply for deprecation" and get a path from there.
21:47 dukeleto whiteknight: they are an easy target ;)
21:47 Paul_the_Greek Question about debugger?
21:47 chromatic Go ahead, Paul_the_Greek.
21:47 NotFound pmichaud: One time I built rakudo with the infinite memory GC, that almost qualifies as "some other gc"
21:47 Paul_the_Greek I've cleaned up a lot of bits and pieces in the debugger.
21:48 Paul_the_Greek Now the hard part comes. Should I tackle it, or is this debugger going to be replaced?
21:48 whiteknight I'm not aware of a pending replacement.
21:48 Paul_the_Greek Someone mentioned something last night, but I can't remember what it was.
21:48 Paul_the_Greek Oh yes...
21:49 whiteknight I'm sure the debugger could be far better than it currently is. You could reimplement it if you think you have a better design in mind
21:49 NotFound Is someone planning to merge the instrumentation SoC? It was related to debugger internals.
21:49 Paul_the_Greek A debugger that would be implemented in Parrot and run like a normal programmer.
21:49 pmichaud NotFound: (infinite gc)  yes, that's why I later qualified to "non-trivial gc"  :-)
21:49 dukeleto Paul_the_Greek: where are your changes to the debugger?
21:49 Paul_the_Greek s/programmer/program/
21:49 Paul_the_Greek I've cleaned up the source file loader and lister, along with all the breakpoint commands.
21:50 Paul_the_Greek The problem is that the matching of source lines to code PCs doesn't work.
21:50 NotFound Paul_the_Greek: that was a bunch of ideas partly discussed, there is no work done AFAIK
21:50 chromatic +1 to cleaning up the debugger
21:50 whiteknight NotFound: That's something we can look at. We need to make sure it isn't a performance drain for the common, non-instrumented case
21:50 chromatic especially in conjunction with the instrumentation project
21:50 Paul_the_Greek I have to learn all about the debug segment.
21:51 whiteknight Let's get a few eyes on that branch and see what we can do with it. Then, Paul_the_Greek will have all sorts of new toys to work with
21:51 NotFound Paul_the_Greek: and the annotations segment
21:51 Paul_the_Greek Right, and annotations.
21:51 Paul_the_Greek So I think I'll clean up one or two more things and commit it, then move on to the tough part.
21:52 NotFound Paul_the_Greek: +1
21:52 NotFound Commit it before trunk diverges too much.
21:52 Paul_the_Greek Will do. So far, only changes to two files.
21:53 chromatic Anything else for today?
21:53 dukeleto Paul_the_Greek: please make a branch of some kind, or just commit to trunk if all the tests pass
21:54 Paul_the_Greek Oh, wiat, good point ...
21:54 Paul_the_Greek Many debugger tests rely on the exact content of displayed messages.
21:54 Paul_the_Greek I propose to eliminate those tests.
21:54 NotFound Don't make a branch, we've just said we don't want too much merges soon.
21:54 Paul_the_Greek But I don't know what to do instead.
21:54 NotFound Commit
21:55 Paul_the_Greek Is it okay if I put off figuring that out?
21:55 NotFound Paul_the_Greek: if you can figure a good way to replace that tests, todo or skip them.
21:55 NotFound can't
21:55 Paul_the_Greek Okay.
21:56 chromatic Should we mark the debugger as experimental?
21:56 plobsing +1
21:56 NotFound chromatic: it was considered as such before dep. policy, so I think it's already de facto experimental, but we can document that fact.
21:57 chromatic Let's make it explicit if it isn't.
21:57 chromatic With that, let's wrap up here.  Close bugs.
21:57 NotFound If someone has patience, there was some #ps were I asked permission fo work freely on it an was granted.
21:57 NotFound Many moons ago.
21:58 luben left #parrotsketch
22:02 NotFound left #parrotsketch
22:03 plobsing left #parrotsketch
22:03 dukeleto left #parrotsketch
22:06 Paul_the_Greek left #parrotsketch
22:14 nwellnhof left #parrotsketch
22:31 tcurtis left #parrotsketch

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