"Tuesday at 20:30 UTC"
Set by moderator on 20 August 2010.
00:31 whiteknight left 00:45 bluescreen joined 02:35 contingencyplan left 03:10 tcurtis joined, bluescreen left 03:26 contingencyplan joined 03:28 Coke left 05:48 gottreu joined 05:50 cotto left, cotto joined 06:06 gottreu left 06:44 contingencyplan left 06:57 contingencyplan joined 07:59 contingencyplan left 08:12 tcurtis left 12:47 eternaleye_ joined 12:49 eternaleye left, pmichaud left, PerlJam left, sorear left 12:51 pmichaud joined, sorear joined, PerlJam joined 14:16 dukeleto joined
dukeleto What I did: 14:23
* Kept parrot.git in sync
* Ran Rakudo spectests and found coredump in icu-less Parrrot, which got fixed
* Added some spectests to roast.git
* Hacked on leto/git_docs and leto/kill_svn_tests branches on github
* Only a few tools are left to convert
* I would guess i am 70% done with documentation 14:24
What I will do:
* Attempt to port the last few tools this week
Blockers:
* Jury Duty (which I will be at today)
.EOR
15:42 mikehh joined 16:10 contingencyplan joined 16:21 kid51 joined
kid51 kid51's report 16:37
CODE STUFF 16:38
* 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++.
* The usual coding standards corrections.
DIRECTORIAL STUFF
* 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.
* Plan to meet with whiteknight Sat Sept 18.
COMMENTS
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
* 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.
What steps can we take to remedy these problems before, say, 2.9 (Oct 19 2010)? Discuss.
EOR
16:58 luben joined
luben What I did: 17:10
* helped hunting for a bug that affected amd64 optimized builds
* hash: inlined hashing and comparison functions. This moves runtime
indrection to compile-time indirection - generally faster.
* merging the branch reverted some previous commits - it's my fault.
I fixed this mis-merge.
* hash: moved memory allocations for small hashes from system malloc 17:11
to fixed size memory allocator. Also, hash buckets/index space is
now lazy allocated
What I will do:
* Look in our GC and figure out how it works
.EOR
17:35 contingencyplan left 17:38 contingencyplan joined 18:41 kid51 left 19:11 whiteknight joined
whiteknight WHAT I DID: 19:18
* Sent out a call for new release managers. Luke-warm response, but enough to get us through the end of the year.
* Finished up my PLA work and am prepared for a release after 2.8.0 comes out.
* On IRC, chatting and answering questions
WHAT I WILL DO:
* Looking to put together a prototype of Chandon's green threads on Win32, since his work was posix-only.
* Chandon mentioned some potential problems involving the intersection of threads, exceptions, and inferior runloops. Examining that.
* 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.
* 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.
* Meeting with kid51 in person next weekend, planning for that.
WHAT I AM BLOCKING ON:
* Nothing
19:23 NotFound joined 19:32 whiteknight left
NotFound What I did: 19:46
-parrot
* Fought the amd64 problems with many others
* Avoided infinite catching of exceptions while dying from exception
* Fixed some $Id that were getting expanded by svn inapropiately
* Added a check for duplicate vtable entries in PMCs. 19:47
* Killed several things that had reached the end of its deprecation cycle.
* Added more core pmc tests.
* Other minor fixes and cleanups.
-winxed
* Allowed use of $ sign in identifiers.
* Added $load directive.
* Improved class declarations, new operator and constructor calling.
* Anonymous functions, they are not closures yet but allows some usages.
* Using several of the new features in the compiler and tools.
* Several bug fixes
* Working on a module that wraps Gtk2 via blizkost, looks promising.
Provisional name: glueglass
What I wil do:
No fixed plan.
EOR
19:47 plobsing joined
mikehh What I did since my last report: 19:51
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* installed Ubuntu 10.10 beta amd64 with Perl 5.12.2 using gcc-4.5.1
(rather than default 4.4.4) and got parrot to build/test with
it (gcc-4.5 and g++-4.5)
What I intend to do in the next week:
* testing and fixing
.eor
plobsing What I Did: 19:52
* eliminated cruft left over after dynops_mapping
* bughunting
What I Plan:
* no plan
EOR
19:54 kid51 joined 19:57 atrodo joined
cotto #done: 20:08
- a little digging into git conversion, not much else
- wrote up a manual test for the github plugin
- ended contract for $dayjob, many tuits expected to follow
#to do:
- netflix instant queue
#eor
20:08 nwellnhof joined
nwellnhof what i did 20:10
- charset_massacre merge and related work 20:11
- bug fixes
plans
- more string encoding related cleanups
- work on configure scripts 20:12
eor
Util # Recently done:
* Converted kid51++'s Win32 report to Report {26}
* Wrangled RT#77778 - Rakudo spectest fail on non-ICU nee 64-bit.
# Plan to do:
* TT#1570 - update with strategy, and behind-release info
= T2 @ Parrot 2.3, MacPorts,CygWin,Debian @Parrot 2.6
* Perl 5-to-6 migration code (name: Blue Tiger) -> GitHub, though very incomplete
# Blockers:
* Tuits short but >0 this week.
# Ticket changes in the last week:
curl -s 'trac.parrot.org/parrot/timeline?day...ticket=on' | perl -wlne '/<em[^>]+\\(([^"]+)\\)">/ or next; $h{$1}++; END {printf "%7d\\t%s\\n", $h{$_}, $_ for sort keys %h}'
2 closed: done
27 closed: fixed
1 closed: invalid
18 new
2 reopened
( -10 total )
.end 20:13
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:15
20:25 allison joined 20:28 Paul_the_Greek joined
Paul_the_Greek Hello everyone. 20:28
20:29 chromatic joined
cotto hio 20:30
pmichaud hello
mikehh hello
NotFound Hola
kid51 hello 20:31
Util Hello
allison hi 20:32
nwellnhof servus
chromatic hello
let's review the past week
How's our bug count?
cotto we definitely hit our goal for closed bugs, but we got some new ones too 20:33
mikehh looks good
kid51 629 by my count; down from 675-ish a month ago
chromatic ~50/month is a very good rate.
nwellnhof 280 of them are bugs, down from about 310 two or three weeks ago 20:34
dukeleto hola
chromatic How'd we do with branch merges?
nwellnhof charset_massacre has been merged 20:35
Paul_the_Greek sleeker_boolean merged; thank you kid51
(causes a problem with Rakudo)
chromatic hash_inline merged, had some problems there, but sorted now
That leaves (by my estimation) the docs revamp and the gc massacre, as big branches we'd targeted. 20:36
(as well as the GSoC branches)
Anything else related to branches and merges to report?
cotto When I tried to test the gc massacre branch after bacek++'s recent sync, my machine became unresponsive.
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
chromatic The string compactor there does not work well with NQP-rx.
NotFound There is a problem with a backwards-incompatible change in ByteBuffer from the charset massacre
A method that took two parameters and now only wants one. 20:38
chromatic Let's table the deprecation question for a moment.
Anything else on branches?
mikehh there seem to be problems with consting since immutable string = some thing that should be const are not 20:39
holdovers AFAICS
chromatic There are probably some places where we assume STRINGNULL == NULL pointer too.
nwellnhof i found some of those in src/dynext.c 20:40
mikehh this generally causes problems with g++ builds
nwellnhof patch coming up soon
chromatic Placeholder question regarding branches for question time: were our merge problems this week bad luck, bad planning, or something else?
How's the Git migration planning?
dukeleto Well.
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.
Paul_the_Greek The sleeker_boolean branch causes problems with Rakudo.
cotto progress and goals are on GitMigration on the wiki
Tene deprecation question also applies to rakudo's problems here
dukeleto I just ported mk_manifest_and_skip.pl to git
chromatic How much work is left on the migration plan before we can set a concrete date? 20:42
dukeleto chromatic: good question
chromatic: i think only 2 tools are left to translate 20:43
chromatic Post 2.9 is possible then?
dukeleto chromatic: mk_language_shell and create_language
chromatic: that gives us about a month? that sounds reasonable
chromatic Just a thought. 20:44
dukeleto it is mostly logistics and finishing up docs at this point
cotto very reasonable
dukeleto yes, let's plan for just after 2.9
chromatic Let's set some goals for this week. Ticket number?
cotto I'm very confident that'll work.
20:45 whiteknight joined
mikehh let's try the same again 20:46
chromatic 25?
mikehh yeah
Paul_the_Greek Go for it.
cotto it's worked well so far. +1
dukeleto +1 to closing 25 tickets this week
cotto fun for the whole family
chromatic Okay, same song third verse.
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.
chromatic Deprecation removal and deprecation listing? +1
Util Smolder server
mikehh well let's not go for things that might break anything, but small fixes
Paul_the_Greek I have a question about the debugger. 20:48
cotto after Saturday, at least
NotFound mikehh: the purpose of the deprecation cycle is being able to kill.
cotto We want a solid release, but we don't need to be too conservative for a devel release.
dukeleto smolder++ 20:49
mikehh kill, kill, kill, veins in the teeth etc.
chromatic Other thoughts on making deprecations a priority?
cotto we have one on parrot.org. Does anyone (hi particle) know its status?
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.
dukeleto chromatic: we need to make HLLs author feel that we don't hate them
kid51 So that we can sort out all those issues.
mikehh w3e need to point to it 20:50
NotFound The CodeString issue: fix things that depends on it as soon as possible.
Notably, json.
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
pmichaud on the other hand, I couldn't find anything that depended on data_json
whiteknight I suggest we use pmichaud's version, if we can make the interface compatible
chromatic +1
cotto +1
dukeleto +1
cotto let's use some of those fancy tools 20:52
Paul_the_Greek Question about the new Boolean?
chromatic Now onto Smolder: who's watching that?
dukeleto chromatic: particle and I 20:53
chromatic: particle needs OSUOSL to allow him to add smolder users
chromatic: currently he cannot, so we are stalled there 20:54
chromatic alright, we'll keep asking then
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
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
particle++ dukeleto++
chromatic Branch merge question then: what happened and why was it so difficult for Rakudo?
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.
cotto One problem was that we didn't realize that Boolean not subclassing Integer would constitute an api break.
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.
chromatic ... not that I'm arguing for breaking Rakudo without warning.
Paul_the_Greek Does it rely on inheriting Integer, or simply test that it does?
whiteknight mikehh: Sure! Any requested dates? I think we have 2010 filled
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?
chromatic If this is something we think the deprecation policy should cover, yes.
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.
Filthy hack ahoy.
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.)
Paul_the_Greek Who do I talk to to find out what Rakudo relies on in Boolean?
cotto is just a little too late today
pmichaud Paul_the_Greek: it wouldn't have helped in this case (more)
whiteknight the inheritance chain of a built-in type does smell to me like it's not really part of an "API"
chromatic #perl6 on freenode, but that's just asking someone to run tests against the branch
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
Paul_the_Greek whiteknight: I'd agree, but you know my opinion on booleans being integers. :D
pmichaud in fact, "Boolean" appears in Rakudo's source exactly once.
er, twice.
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?
pmichaud We don't expect any.
That's not what broke.
Paul_the_Greek What broke?
pmichaud mmd dispatch 21:03
because Boolean is no longer an Integer, it ends up dispatching to an entirely different function
Paul_the_Greek Why would there be a dispatch that expected to match a boolean argument to an integer?
pmichaud you can ask "why" and there will be no answer.
chromatic Because it used to work that way, and someone assumed that was the way it should work.
pmichaud no 21:04
because it used to work that way, and it didn't cause any problems that caused someone to say it should be different
Paul_the_Greek Now I'm lost.
pmichaud there was no overt planning or recognition that boolean needed integer capabilities whatsoever
chromatic I don't see an effective difference in explanation.
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?
pmichaud at no time in the rakudo implementation process did someone say "aha, this Integer case will cover the Boolean case as well"
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.
chromatic Sure, someone just wrote code with an assumption that we broke.
pmichaud right
Paul_the_Greek Ah, okay.
pmichaud the person who wrote code didn't recognize that an assumption was being made.
it worked, and that was good enough.
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?
whiteknight exact reasons are not so much important as making sure we have a working release next week
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?
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.
pmichaud Rakudo will adapt around it without too much difficulty.
I'm not at all requesting the hack on Rakudo's behalf.
whiteknight I don't want to put strain on rakudo unnecessarily. This is our mess after all
Paul_the_Greek chromatic: How do we know that? How do we know it doesn't expect to be able to add a Boolean?
pmichaud it's not a strain (more)
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
I was totally surprised when Rakudo broke.
whiteknight pmichaud: that said, with the release coming up and a decision being made here, what would you like to see happen?
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.
whiteknight if you were ruler of the universe
Paul_the_Greek He is sounds like a benevolent ruler.
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.
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.
so I'd prefer to see the existing non-hacky code stay somehow.
whiteknight okay. That does make the most sense 21:10
Paul_the_Greek Shall I do some polling of other HLLs?
whiteknight Paul_the_Greek: Can we back out the branch changes, keep the branch around, and merge it later?
chromatic -1 to keeping the branch around for later
pmichaud -1 here also
plobsing proposal: if HLLs want Boolean to be isa Integer, can they just .hll_map it to Integer?
Paul_the_Greek Ouch. I'd rather add a hack or two. But kid51 will testify to my concern.
pmichaud plobsing: hll_map doesn't work that way.
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?
pmichaud and again, I don't think it's at all the case that any HLL _wants_ Boolean to be an Integer.
chromatic I agree.
pmichaud Rakudo certainly doesn't care about it. The question is simply one of "how far does the deprecation policy extend?"
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.
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.
pmichaud *where deprecation failure occurs
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!"
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.
chromatic Proposal: no branch merges to trunk until trunk is safe for Rakudo.
Paul_the_Greek But sometimes the fact that A inherits from B is a feature.
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
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?
or just not the one we have now?
pmichaud whiteknight: I don't know a good answer to that.
whiteknight I ask you because you're the point person on one of our biggest dependent projects 21:16
pmichaud right.
whiteknight so you're the most effected by the policy
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
whiteknight the spectest does take a hell of a long time to run
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.
whiteknight (I'm not arguing against it, really, just saying)
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?"
NotFound nwellnhof: if the parrot developers spend its time doing that frequentrly, they can't develop.
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
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
kid51 NotFound: But we need to do test against HLLs in an *automated* way *much* more than we do now.
cotto and gripe in #parrot when a failure pops up?
whiteknight cotto: buildbot +1
cotto though separating signal from noise may be tricky
chromatic ... add a policy to merge no branch until trunk is green for Rakudo.
plobsing buildbots are great, but when preparing branch merges, buildbots on trunk don't really help
luben buildbot +1
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
cotto pmichaud, zing!
dukeleto i am very +1 to smoking all branches
Util New option needed in Rakudo? `perl Configure --gen-parrot-HEAD` ?
pmichaud I'll happily add a --gen-parrot-HEAD if that helps.
mikehh It would be nice to have more buildbots like taptinder
cotto How about "all *recent* branches"?
(commits within the last week or so) 21:21
mikehh especially on different platforms
plobsing how about specially marked branches? most of the time I don't care about those results yet
chromatic Let's worry about Rakudo HEAD and Parrot HEAD first, then get more creative.
cotto how would they be marked? buildbot instructions over irc?
+1 21:22
mikehh marked when ready for testing
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.
so then it would be --gen-parrot=HEAD
cotto this sounds great
Util +1
cotto we need more visibility for Rakudo spectest failures
whiteknight getting them posted on smolder, when it gets working, would be killer 21:23
21:23 tcurtis joined
chromatic Does this begin to address concerns? 21:23
Util cotto: bot announce on #parrot / #rakudo of spectest fail?
cotto yes
for parrot head vs rakudo head 21:24
chromatic Any specific changes to the deprecation policy come to mind besides this?
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
NotFound ack PARROT_API still doesn't show anyhing relevant. 21:26
chromatic We could exclude "inheritance details" from API details.
NotFound So in theory we can change almost snything X-) 21:27
Paul_the_Greek But sometimes the inheritance is a feature, no?
chromatic If it is, we document it as part of the interface and write tests for it. 21:28
Maybe that's the change we need to the documentation policy.
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."
pmichaud that helps if we know we're relying on something :)
even if inheritance isn't part of the API, inherited methods ought to be.
21:29 allison left
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.
If you wnat it able to be used were a Handle is expected, that is. 21:31
chromatic Let's move on to other questions. 21:33
plobsing?
kid51 leaves; will backscroll 21:34
21:34 kid51 left
Paul_the_Greek I have a debugger question. 21:34
plobsing generational gc, as I understand it, requires some extra stuff around reference assignments
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)
chromatic Our pointers are already opaque.
Except in the cases of dynpmcs.
plobsing dynpmcs are the main problem. 21:36
chromatic We'd need to figure out the upgrade path then.
whiteknight we had barriers at one point and never enforced them. We may still have them
nwellnhof it would be a big help if everyone would use SET_ATTR
whiteknight saying we're going to enforce something we already should have been doing isn't really a matter for deprecation
plobsing but we already provide interfaces to circumvent this 21:37
PARROT_IMAGEIO(SELF)->unsafe_attribute_access
whiteknight for internal-use only 21:38
chromatic when it breaks, don't report GC bugs
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
NotFound Use the infinite memory gc, and buy more memory.
chromatic If there's consensus to document those macros as safe, let's do it. 21:40
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.
The impact of that can be noticeable. 21:42
chromatic Do we have a volunteer to do some research?
plobsing research how?
chromatic What are we likely to deliver by 3.0 and what do we need to recommend for deprecation-safe source before then? 21:43
plobsing I can try to do that. 21:44
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:45
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
why do bad things happen to good people?
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.
dukeleto whiteknight: they are an easy target ;) 21:47
Paul_the_Greek Question about debugger?
chromatic Go ahead, Paul_the_Greek.
NotFound pmichaud: One time I built rakudo with the infinite memory GC, that almost qualifies as "some other gc"
Paul_the_Greek I've cleaned up a lot of bits and pieces in the debugger.
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.
Paul_the_Greek Someone mentioned something last night, but I can't remember what it was.
Oh yes...
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.
Paul_the_Greek A debugger that would be implemented in Parrot and run like a normal programmer.
pmichaud NotFound: (infinite gc) yes, that's why I later qualified to "non-trivial gc" :-)
dukeleto Paul_the_Greek: where are your changes to the debugger?
Paul_the_Greek s/programmer/program/
I've cleaned up the source file loader and lister, along with all the breakpoint commands.
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
chromatic +1 to cleaning up the debugger
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
chromatic especially in conjunction with the instrumentation project
Paul_the_Greek I have to learn all about the debug segment.
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
Paul_the_Greek Right, and annotations.
So I think I'll clean up one or two more things and commit it, then move on to the tough part.
NotFound Paul_the_Greek: +1 21:52
Commit it before trunk diverges too much.
Paul_the_Greek Will do. So far, only changes to two files.
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
Paul_the_Greek Oh, wiat, good point ... 21:54
Many debugger tests rely on the exact content of displayed messages.
I propose to eliminate those tests.
NotFound Don't make a branch, we've just said we don't want too much merges soon.
Paul_the_Greek But I don't know what to do instead.
NotFound Commit
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.
can't
Paul_the_Greek Okay.
chromatic Should we mark the debugger as experimental? 21:56
plobsing +1
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.
chromatic Let's make it explicit if it isn't. 21:57
With that, let's wrap up here. Close bugs.
NotFound If someone has patience, there was some #ps were I asked permission fo work freely on it an was granted.
Many moons ago.
21:58 luben left 22:02 NotFound left 22:03 plobsing left, dukeleto left 22:06 Paul_the_Greek left 22:14 nwellnhof left 22:31 tcurtis left

Powered by Cro and the Raku® Programming Language.

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

Thank you!