Camelia, the Perl 6 bug

IRC log for #parrot, 2011-09-06

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:33 Patterner joined #parrot
01:04 woosley joined #parrot
01:32 cotto https://www.destroyallsoftware.com/blo​g/2011/one-base-class-to-rule-them-all
01:35 jsut_ joined #parrot
01:43 dalek parrot/nwellnhof/compiler_flags: 6f2c5c1 | jkeenan++ | config/init/hints/linux.pm:
01:43 dalek parrot/nwellnhof/compiler_flags: On Linux, use settings appropriate for gcc or g++ as defaults.  In
01:43 dalek parrot/nwellnhof/compiler_flags: effect, account for possibility that $cc symlinks to gcc or g++.
01:43 dalek parrot/nwellnhof/compiler_flags: review: https://github.com/parrot/parrot/commit/6f2c5c1dfe
01:43 dalek parrot/nwellnhof/compiler_flags: 017401c | jkeenan++ | config/init/hints/linux.pm:
01:43 dalek parrot/nwellnhof/compiler_flags: More debugging output for Linux hints file.
01:43 dalek parrot/nwellnhof/compiler_flags: review: https://github.com/parrot/parrot/commit/017401cef2
01:57 dalek parrot: 5537051 | jkeenan++ | config/init/hints/linux.pm:
01:57 dalek parrot: More debugging output for Linux hints file.
01:57 dalek parrot: review: https://github.com/parrot/parrot/commit/55370512dc
02:08 dalek parrot: e806062 | jkeenan++ | config/init/hints/darwin.pm:
02:08 dalek parrot: More debugging output for Darwin hints.
02:08 dalek parrot: review: https://github.com/parrot/parrot/commit/e806062a34
03:14 dalek rakudo/nom: c773a04 | Coke++ | t/spectest.data:
03:14 dalek rakudo/nom: track failure modes
03:14 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c773a04d75
03:36 cotto mls, ping
03:43 PerlJam cotto++ interesting email to parrot-dev.
03:46 cotto So far the responses have been positive.
03:47 cotto though throwing out the deprecation policy is very much the easy part
03:47 PerlJam "This sucks, let's fix it" can only be met with positive repsonses when it's true :)
03:49 dalek parrot/mls/sub-profiler: 8091027 | cotto++ | / (2 files):
03:49 dalek parrot/mls/sub-profiler: variable name clarification, struct commenting
03:49 dalek parrot/mls/sub-profiler: review: https://github.com/parrot/parrot/commit/80910275d7
03:49 dalek parrot/mls/sub-profiler: a5909f0 | cotto++ | / (8 files):
03:49 dalek parrot/mls/sub-profiler: add subprof as a distinct runcore, now needs to be run with -Rsubprof
03:49 dalek parrot/mls/sub-profiler: review: https://github.com/parrot/parrot/commit/a5909f0c16
03:54 logie joined #parrot
05:08 zby_home joined #parrot
06:14 SHODAN joined #parrot
06:16 moritz \o
06:18 cotto good morning, moritz
06:20 moritz I'm curious, everybody seems to be against the deprecation policy
06:20 moritz who is actually in favor of itß
06:20 moritz s/ß/?/
06:20 moritz I think allison was
06:21 cotto moritz, I think it's more that it seemed like a good idea at the time.
06:21 moritz but who else?
06:22 cotto I used to.  I suspect others did too (at least grudgingly).
07:05 nbrown joined #parrot
07:10 nbrown_ joined #parrot
07:13 mj41 joined #parrot
07:17 Kulag joined #parrot
07:21 contingencyplan joined #parrot
07:44 tadzik good morning #parrot
08:02 lucian joined #parrot
08:17 dodathome joined #parrot
08:43 mls morning parrot!
09:31 preflex joined #parrot
09:32 ligne joined #parrot
09:47 dukeleto ~~
09:47 dukeleto looks like trac.parrot.org has an expired SSL cert
09:50 dukeleto moritz: ping
09:50 moritz dukeleto: pong
09:51 dukeleto moritz: i would not say that i am against the deprecation policy, but i also think it could use some modification
09:51 dukeleto moritz: also, where you looking for me? I was visiting family off-grid for a few days
09:52 moritz dukeleto: -> /msg
09:59 moritz dukeleto: anything in particular you'd like to see changed in the deprecation policy
10:03 dalek parrot: 4e204ad | dukeleto++ | api.yaml:
10:03 dalek parrot: Clarify TT#1906 in api.yaml
10:03 dalek parrot: review: https://github.com/parrot/parrot/commit/4e204ad55c
10:04 dukeleto moritz: that is a good question. I know that I *don't* want us to get get lazier with api.yaml. I think parrot can change must faster if we have an extremely accurate api.yaml with automated tools to help HLL devs
10:04 dukeleto moritz: it can't find everything, but it sure can at least help with the easy 80% of deprecations
10:05 dukeleto moritz: perhaps the idea of having a stable release every 3 months is too rigid for parrot currently. Perhaps just attempting to increase awesomeness with each monthly dev release is what we need to focus on
10:06 dukeleto moritz: but i am not sure how to change the dep policy. Need to stew on it some more.
10:07 tadzik +1 on increasing awesomeness, one month at a time :)
10:07 moritz dukeleto: fwiw the only difference between "stable" and monthly releases that I see is that we recommend distributors to ship the "stable" ones
10:07 dukeleto moritz: i think in general, the problem with parrot "foundering" is not our dep policy. It is the fact that we haven't yet focused at being the best at something. Instead, we try to please everybody and end up pleasing very few.
10:07 moritz dukeleto: I didn't observe better quality, better stability, more awesomeness or anything else that warrants extra attention
10:08 moritz (in the stable releases, that is)
10:08 dukeleto moritz: i think we imply that HLL devs should use stable releases unless they want a feature in a dev release
10:08 dukeleto moritz: and if we don't, we should
10:08 moritz somehow that has never worked out for rakudo really well
10:09 moritz because parrot isn't as stable as we seemed to assume when making the dep policy
10:09 moritz I kinda agree on the trying to please everybody point
10:09 dukeleto moritz: we are much more conservative with branch merges before a stable release, which may be a hard feature to notice :) But it is there, nonetheless
10:10 moritz dukeleto: that would imply that stable releases are of better quality than the others. I can't confirm that.
10:10 dukeleto moritz: rakudo is like the student in the first row that has already read the whole book. Always asking hard questions :)
10:11 moritz dukeleto: specifically we had a huge performance regression in one of the stable releases that made us do another release. Never had such a breakage in a dev release.
10:11 dukeleto moritz: it is more like insurance. You pay some dude to insure you against a natural disaster, but you don't go around noticing the lack of one every 3 months
10:11 dukeleto moritz: that is just the lack of serious and automated performance testing on parrot. It randomly happened on a stable release, is my bet.
10:12 dukeleto moritz: 25% of releases are stable, so the odds aren't particularly rare
10:15 moritz well, if the quality difference between stable and dev releases is dominated by noise, it kinda emphasizes what I'm trying to say :-)
10:16 dukeleto moritz: it emphasizes that rakudo very much needs parrot to insure that successive parrot releases will get faster and not slower.
10:17 dukeleto moritz: as far as I know, we have never formally made that promiste, but we sure do try. We need better tools.
10:18 dukeleto moritz: with better tools, we could make that promise. But right now, it would be a hard promise to keep.
10:18 dukeleto moritz: i think we need to seriously consider what kind of performance requirements releases should have
11:06 autark joined #parrot
11:10 cosimo joined #parrot
11:12 JimmyZ joined #parrot
11:35 Infinoid joined #parrot
11:35 Psyche^ joined #parrot
11:42 plobsing joined #parrot
11:53 mls There's a bug in the Parrot_sub_get_line_from_pc function, it compares the op against the size of the debug segment instead of the size of the code segment
11:53 mls fix: https://gist.github.com/1197350
12:00 bluescreen joined #parrot
12:01 * moritz tests
12:08 mtk joined #parrot
12:09 dalek parrot: 64522d5 | moritz++ | src/sub.c:
12:09 dalek parrot: fix bug in Parrot_sub_get_line_from_pc
12:09 dalek parrot:
12:09 dalek parrot: It used to compare the op against the size of the debug segment, not
12:09 dalek parrot: against the size of the code segment.
12:09 dalek parrot: Patch courtesy by mls++
12:09 dalek parrot: review: https://github.com/parrot/parrot/commit/64522d5702
12:16 whiteknight joined #parrot
12:16 whiteknight good morning, #parrot
12:17 benabik joined #parrot
12:17 moritz o/ whiteknight
12:17 whiteknight hello moritz
12:17 benabik o/
12:17 whiteknight ...and benabik
12:17 bluescreen joined #parrot
12:18 tadzik good morning whiteknight . I'm not a bot, trust me.
12:20 * moritz disbelieves anybody who says "trust me"
12:20 moritz just as a habit
12:22 benabik moritz: It does mean they think you have a reason _not_ to trust them.
12:24 atrodo =~
12:30 whiteknight I'm going to merge the whiteknight/pmc_is_ptr branch and not_gerd's improvements to master in a minute
12:31 whiteknight unless anybody disagrees?
12:31 jnthn whiteknight: wfm
12:31 jnthn whiteknight: If nobody beats me to it, I'll bump the PARROT_REVISION we get in NQP/Rakudo once that happens.
12:31 jnthn So we get this and the mls fix.
12:31 whiteknight ok, awesome. Go teamwork!
12:33 whiteknight I love when branches merge without conflicts
12:33 mls msg cotto I've set up a parrot clone at https://github.com/mlschroe/parrot/ to work a bit on the sub-profiler branch
12:33 dalek parrot: e9d0322 | Whiteknight++ | src/gc/fixed_allocator. (2 files):
12:33 dalek parrot: Merge remote-tracking branch 'origin/whiteknight/pmc_is_ptr'
12:33 aloha OK. I'll deliver the message.
12:33 dalek parrot: review: https://github.com/parrot/parrot/commit/e9d03224ef
12:33 dalek parrot: 6f57d17 | Whiteknight++ | src/gc/fixed_allocator.c:
12:33 dalek parrot: Merge remote-tracking branch 'gerdr/whiteknight/pmc_is_ptr'
12:34 dalek parrot: review: https://github.com/parrot/parrot/commit/6f57d171a1
12:35 moritz mls: I'm sure you'll get a commit bit rather quickly if you submit a signed CLA
12:36 moritz then we don't have the hassle of copying&pasting patches, forked repos and pull requests etc.
12:37 whiteknight we parroteers rather like pull requests
12:37 moritz you do?
12:37 whiteknight yeah. They're awesome
12:37 moritz I mean, I like them better than patches by email
12:37 whiteknight we'll still give out commit bits as needed, but pull requests are great
12:37 moritz but I even more prefer good commits to the target repo right away
12:38 plobsing whiteknight: (re: pmc_is_ptr) that's a great stop-gap, but I feel a better solution would be to just stop all this stack-marking garbage and move to precise GC.
12:39 whiteknight plobsing: no question. You trace out the route on a map, and I'll start loading the sled and getting the dogs ready
12:39 whiteknight :)
12:39 dalek nqp: 8ad13af | moritz++ | tools/build/PARROT_REVISION:
12:39 dalek nqp: bump PARROT_REVISION to after the pmc_is_ptr merge
12:39 dalek nqp: review: https://github.com/perl6/nqp/commit/8ad13af138
12:39 whiteknight all joking aside, I'm not sure how we do it in pre-M0 parrot
12:39 jnthn Worth doing, but hard until m0, I suspect
12:42 plobsing finding all the places that need updating is going to be tough. I really need to become more adept with static analysis tools.
12:42 tadzik oooh, merge
12:42 dalek rakudo/nom: 860fe17 | moritz++ | / (2 files):
12:42 dalek rakudo/nom: bump nqp revision, remove memory leak from NOMMAP
12:42 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/860fe17159
12:43 tadzik we're not having memory leaks on our roadmap anymore? Snap :/
12:44 whiteknight plobsing: yeah, that's the biggest part of it. We're going to have to go through the whole parrot repo, the dynops, and extensions that use C code
12:44 moritz tadzik: should we?
12:44 whiteknight PLA uses C code, but I can keep that up to date if we have a good mechanism for doing it
12:45 whiteknight Rakudo is the biggie
12:45 tadzik moritz: of course not, just kidding
12:45 plobsing whiteknight: that's why I mention static analysis. doing it by hand is too big.
12:45 plobsing even with gen_gc we missed a few spots
12:46 jnthn tadzik: If you find a new way to leak, please add a compact example to nommap :)
12:46 jnthn tadzik: Or actually just an RT :)
12:46 ttbot Parrot e54106bb i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/48856
12:47 whiteknight plobsing: And once we find all spots, we need to implement a mechanism to anchor PMCs which are currently created on the stack
12:47 whiteknight There are plenty of good ideas, we just need to pick one and implement it
12:47 Coke cotto++
12:50 darbelo joined #parrot
13:04 atrodo cotto++ I agree
13:25 allison cotto/moritz: the deprecation policy was adopted on the assumption that we would be supporting large numbers of users after 1.0
13:25 allison cotto/moritz: if we *were* supporting large numbers of users, it'd be essential for managing the maintenance burden
13:25 allison cotto/mortz: but, we're not
13:26 allison cotto/moritz: so it was a matter of preparing for a scenario that didn't play out
13:26 allison cotto/moritz: (no plan survives first contact with the enemy :)
13:26 moritz allison: good to know, thanks
13:27 allison cotto: but, I am left with a question of which releases to package for Debian/Ubuntu
13:27 atrodo allison> Be progressive, 4.0
13:27 allison cotto: every month seems a bit rapid of a pace
13:27 moritz we can still have "recommended" or "supported" release, even in absence of a strict deprecation policy
13:28 allison cotto: and, I know that we have some releases that are more "conservative/testing" and some that are more "innovative"
13:28 allison moritz: aye
13:28 allison cotto/moritz: the versioning scheme of major/minor/sub is useful for indicating which to package
13:29 allison i.e. which are intended for widespread use, and which are not
13:30 allison maybe X.X.# increments are development releases and X.#.X increments are "supported"? dunno
13:30 allison doesn't really matter, as long as it's consistent
13:31 atrodo It does seem a little magical from the outside that a release that ends with 0, 3, 6 or 9 is supported
13:32 allison atrodo: yup, it was a side-effect of the 3 month schedule
13:41 whiteknight allison: I see no reason why we can't still have a few "supported" releases each year. X.0 and X.6 seem like good choices
13:41 plobsing_ joined #parrot
13:41 whiteknight allison: the only real difference is that the "supported" releases won't be tied to a deprecation policy, so each subsequent supported release may carry some surprises
13:42 whiteknight now that I say it that way, it seems like what we really need is something to help manage multiple versions of Parrot on a system, so users don't get caught in an upgrade pincer attack
13:44 JimmyZ whiteknight: ping
13:44 whiteknight pong
13:46 JimmyZ whiteknight: I patch this https://gist.github.com/1197562, and got Segmentation fault, I didn't know how to fix it
13:49 JimmyZ whiteknight: I want to optimize fixed_allocator.c
13:49 benabik whiteknight: I read the start of your e-mail to p-dev as "Off the top of my head, I want to slash and burn everything."
13:50 whiteknight benabik: It's  not far from the truth :)
13:50 benabik As a random note, I think that if we kill PIR, we should still have _some_ low level assembly-ish language.
13:50 atrodo benabik> I assume that's implied at the begining of every sentence from whiteknight
13:50 benabik And afk again
13:51 whiteknight JimmyZ: some of that doesn't look right
13:52 JimmyZ whiteknight:  I don't know what's wrong
13:53 whiteknight JimmyZ: I have to look at it more. I can't right now
13:53 JimmyZ whiteknight: thanks
13:54 benabik (As a note, I'm working in the sysadmin office this quarter, so I'll be on and off a LOT.)
13:55 whiteknight benabik: I want to get working on PACT too, if you think you have enough ideas there
13:56 benabik whiteknight: I'm just going to throw my current notes up on a gist.  I had tried to get a coherent blog post, but failed.
13:56 whiteknight benabik: that would be great. You put up the notes, I can make the blog post
13:58 benabik whiteknight: Arg.  meeting about to start, I'll get on that sometime today.
14:02 whiteknight benabi++
14:02 whiteknight benabik++
14:15 tadzik could someone grant a user 'pfusik' access to opening trac tickets?
14:15 tadzik He's a friend from my PM group, wants to file a bug
14:15 whiteknight let me look
14:16 benabik whiteknight: https://gist.github.com/05267b2b46beca86b8da  -- Trying to organize my thoughts
14:16 whiteknight tadzik: I don't see a user with that name in the system
14:16 tadzik hrm
14:17 tadzik ok, I'm mailing him back
14:17 whiteknight tadzik: oh wait. nevermind. Try again
14:18 tadzik granted? I'm just mailing him back
14:19 benabik whiteknight: And it even has reasonable formatting now.  Some of what I wrote may be pure bull, I was brainstorming.
14:20 whiteknight benabik: it's okay, I'll look at it
14:21 whiteknight tadzik: yeah, I think the permissions are granted
14:21 tadzik great, whiteknight++
14:25 not_gerd joined #parrot
14:25 not_gerd good afternoon, #parrot
14:26 tadzik 'afternoon, not_gerd
14:26 not_gerd saw the discussion on stack walking in the logs
14:27 not_gerd some thoughts on that: https://gist.github.com/1197666
14:31 whiteknight not_gerd: I merged the pmc_is_ptr branch and your changes to master this morning
14:31 whiteknight not_gerd++
14:34 whiteknight not_gerd: Yeah, we were thinking about something frame-based. The hard part is finding all the functions that need to get updated
14:35 bluescreen joined #parrot
14:35 whiteknight we're going to need something a little bit more dynamic too, because an exception can jump up multiple frames
14:36 benabik whiteknight: Associate frames with runloops?
14:37 whiteknight benabik: that's probably too course. We just need a mechanism that when we pop a frame, we pop all frames up to the current one
14:38 whiteknight so we really just need two new GC api functions: One to allocate a frame that the GC will trace, and one to pop a frame and all frames before it
14:38 whiteknight Then, a fancy macro to hide the details, and we all win
14:38 benabik fsvo win
14:38 whiteknight if we can add this and avoid stack walking, there should be some noticable performance gains
14:39 plobsing_ we need to be able to support multiple frame stacks. multiple native threads may access the same interpreter (even if not concurrently).
14:40 whiteknight plobsing: The GC is probably going to need a section of thread-local state data, in addition to global data. When we get there, this would just be part of the thread-local GC data
14:41 plobsing_ what other native-thread-local state (as opposed to parrot-thread-local state) would a GC need?
14:42 whiteknight If we want non-copying, we need to keep track of PMCs which are located in local arenas but are managed by foreign GCs
14:42 whiteknight actually, that could just be a flag or something
14:42 whiteknight so maybe nothing
14:43 plobsing_ non-copying is done at parrot-thread resolution, no?
14:43 whiteknight what do you mean?
14:43 plobsing_ well parrot threads may or may not map 1:1 to native threads
14:43 plobsing_ the thing I am talking about has to do with native threads only
14:45 plobsing_ even if 2 parrot threads exist in the same native thread, we still need to keep track of who owns what, or are we doing a multi-parrot-thread GC?
14:45 dalek TT #2190 created by pfusik++: Typos
14:45 dalek TT #2190: http://trac.parrot.org/parrot/ticket/2190
14:46 logie joined #parrot
14:48 tadzik the typos in ext/winxed/compiler.pir should probably be fixed someplace else
14:48 not_gerd btw, how does parrot deal with continuations in case of nested runloops?
14:49 not_gerd does it make a cpy of the stack like gnu guile or disallow that completely?
14:49 not_gerd ^copy
14:50 benabik I think we use longjmp, but I'm no expert on the C bits.
14:50 plobsing_ not_gerd: we stay nested until we return to C, or call 'finalize' (which means we're done with that portion of the C stack)
14:51 benabik plobsing_: Is finalize just for exceptions?
14:51 plobsing_ benabik: exceptions are just continuations
14:52 awwaiid that's what she said
14:52 benabik What does finalize mean outside the context of exceptions?  I thought it was "we're not returning to the exception".  Does it generally mean "we're not calling any continuations"?
14:53 plobsing_ It as implemented in the context of exceptions, but it generally means "we won't be calling into this continuation anymore, unwind the stack"
14:54 whiteknight yeah, it just jumps back up to the owner runloop
14:54 not_gerd plobsing_: is that enough to support full CPS semantics?
14:54 benabik Interesting.  An the continuation is marked "do not call", I hope?
14:54 whiteknight we don't use it much with normal continuations, because we don't use normal continuations much
14:54 not_gerd (which begs the question why the guile guys chose a different approach...)
14:55 plobsing_ not_gerd: guile chose a different approach because they want to integrate closely with C. parrot's relationship with C borders on hostile.
14:55 benabik plobsing_: That may explain some of our C code...
15:02 cotto ~~
15:14 dalek parrot: b9261ad | cotto++ | / (57 files):
15:14 dalek parrot: large batch of typo fixes, courtesy of pfusik++
15:14 dalek parrot: review: https://github.com/parrot/parrot/commit/b9261ad17c
15:18 dalek TT #2190 closed by cotto++: Typos
15:18 dalek TT #2190: http://trac.parrot.org/parrot/ticket/2190
15:38 ehks joined #parrot
15:46 Coke cotto-- #applying changes to historic Changelog and NEWS items before merging back my branch@!
15:47 Coke ;)
15:47 Coke cotto - there were changes to ext/* there also, which should have been pushed upstream. They'll just get overwritten on the next refresh.
15:48 whiteknight Coke: What's the ETA on that branch?
15:49 Coke notfound did the last thing weeks ago.
15:50 Coke I see no reason not to merge it back now (TT#2184)
15:51 whiteknight if it's good to go, merge it today
15:51 whiteknight or, as soon as possible
15:54 Coke do we have a preference for merging individual commits vs. a single merge commit?
15:55 whiteknight I don't think I have a preference. Whichever you think works best
15:57 dalek parrot/jimmy/gc_fixed_allocator_cleanup: 5f6ccb2 | jimmy++ | src/gc/fixed_allocator. (2 files):
15:57 dalek parrot/jimmy/gc_fixed_allocator_cleanup: various cleanup to fixed_allocator
15:57 dalek parrot/jimmy/gc_fixed_allocator_cleanup: review: https://github.com/parrot/parrot/commit/5f6ccb2a8a
15:58 Coke also, how do we feel about updating "historic" text as in Changelog?
15:58 Coke should I reapply those fixes?
15:58 Coke Despite my earlier protest, I don't really care.
16:08 whiteknight Coke; I'm ambivalent. I don't think it matters.
16:08 whiteknight I suspect cotto didn't go through the patch with a fine-toothed comb
16:26 dalek parrot/jimmy/gc_fixed_allocator_cleanup: 88f0795 | jimmy++ | src/gc/fixed_allocator.c:
16:26 dalek parrot/jimmy/gc_fixed_allocator_cleanup: revert some cleanups which is wrong
16:26 dalek parrot/jimmy/gc_fixed_allocator_cleanup: review: https://github.com/parrot/parrot/commit/88f0795224
16:26 dalek parrot/jimmy/gc_fixed_allocator_cleanup: a7ec805 | jimmy++ | src/gc/fixed_allocator.h:
16:26 dalek parrot/jimmy/gc_fixed_allocator_cleanup: forgot add top_arena
16:26 dalek parrot/jimmy/gc_fixed_allocator_cleanup: review: https://github.com/parrot/parrot/commit/a7ec805b1b
16:34 cotto_work ~~
16:35 cotto_work whiteknight and Coke, I just checked that the corrections were valid.  I spaced and didn't check whether they were in the right places.
16:35 whiteknight I don't think it's a big deal. the ones that aren't in the right places will be silently overwritten
16:36 cotto_work sure, just not optimal
16:37 whiteknight not optimal? It would have taken more effort for you to separate the wheat from the chaff, when the chaff will be dealt with automatically in later stages
16:41 dalek parrot/jimmy/gc_fixed_allocator_cleanup: 53b2df5 | jimmy++ | src/gc/fixed_allocator. (2 files):
16:41 dalek parrot/jimmy/gc_fixed_allocator_cleanup: removed some experimental code
16:41 dalek parrot/jimmy/gc_fixed_allocator_cleanup: review: https://github.com/parrot/parrot/commit/53b2df578d
16:44 dukeleto ~~
16:44 dalek parrot: 5f6ccb2 | jimmy++ | src/gc/fixed_allocator. (2 files):
16:44 dalek parrot: various cleanup to fixed_allocator
16:44 dalek parrot: review: https://github.com/parrot/parrot/commit/5f6ccb2a8a
16:44 dalek parrot: 88f0795 | jimmy++ | src/gc/fixed_allocator.c:
16:44 dalek parrot: revert some cleanups which is wrong
16:44 dalek parrot: review: https://github.com/parrot/parrot/commit/88f0795224
16:44 dalek parrot: a7ec805 | jimmy++ | src/gc/fixed_allocator.h:
16:44 dalek parrot: forgot add top_arena
16:44 dalek parrot: review: https://github.com/parrot/parrot/commit/a7ec805b1b
16:44 dalek parrot: 53b2df5 | jimmy++ | src/gc/fixed_allocator. (2 files):
16:44 dalek parrot: removed some experimental code
16:44 dalek parrot: review: https://github.com/parrot/parrot/commit/53b2df578d
16:44 dalek parrot: 1a54763 | jimmy++ | src/gc/fixed_allocator. (2 files):
16:44 dalek parrot: Merge branch 'jimmy/gc_fixed_allocator_cleanup'
16:44 dalek parrot: review: https://github.com/parrot/parrot/commit/1a547637af
16:45 cotto_work good morning, dukeleto
16:45 dukeleto cotto_work: how goes it?
16:46 cotto_work glad to have that message sent, now wondering what the best next step is.
16:46 cotto_work #ps later today should be fun
16:47 dukeleto cotto_work: indeed. I was visiting family, so I didn't get to read the thread until late last night
16:47 ttbot Parrot 88f07952 i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/49226
16:48 dukeleto JimmyZ: src/gc/fixed_allocator.c:327: error: 'Pool_Allocator' has no member named 'top_arena'
16:48 whiteknight cotto_work: git rm docs/project/support_policy.pod && git commit -a -m"MUAHAHAHAHA" && git push
16:48 whiteknight that's the next best step
16:49 cotto_work whiteknight: sure.  That's the obvious one. ;)
16:49 whiteknight anything less is not "best"
16:49 dukeleto From what I can read, I don't see any actualy details about how to change the dep policy, only that it is disliked
16:50 whiteknight the change he's recommending is to "scrap" it
16:50 whiteknight take it out and shoot it
16:50 dukeleto also, the term "deprecation policy" is slightly ambiguous. What exactly do we mean by that?
16:50 whiteknight burn the ashes. Pee on the embers
16:51 dukeleto cotto_work: what about api.yaml ?
16:52 JimmyZ dukeleto: that's odd, I didn't remove top_arena
16:53 cotto_work dukeleto: for now I don't think it'll be needed.  The new policy will be to run tools/dev/all_hll_test.pl frequently and fix things as we break them.
16:53 JimmyZ dukeleto: ttbot  was too early to compile, she didn't pull all commits
16:54 Coke dukeleto: I prefer "Support Policy", I think.
16:54 cotto_work mls: ping
16:55 * JimmyZ sleeps
16:55 dukeleto whiteknight: the ssl cert being expired is teh suxors
16:56 not_gerd JimmyZ: Pool_Allocator_Free_List and Pool_Allocator_Arena are different things, you shouldn't unify them...
16:56 whiteknight dukeleto: I sent an email to OSUOSL. They handle certs
16:56 dukeleto whiteknight: ah, awesomesauce.
16:56 Coke dukeleto: I believe Jerry was our primary contact for SSL stuff back in the dark ages.
16:56 Coke oh. we actually paid some external agency for one pre-OSU
16:56 whiteknight Coke: Yes, we did the same
16:57 whiteknight we bought the cert, and gave it to OSUOSL
16:57 * Coke wonders if any of the current board is planning on running agian.
16:57 JimmyZ not_gerd:  I din't see any difference
16:58 mls hey cotto!
16:58 cotto_work mls: it gladdens my heart to see some documentation in the subprof code.  Could you add/correct documentation for the other functions too?
16:58 not_gerd JimmyZ: they may be structurally equal if you change arenas to be singly-linked, but thes do different things
16:59 mls sure!
16:59 not_gerd JimmyZ: one lists arenas, the other items...
16:59 mls But I'm currently changing the code quite a bit, so that it also supports annotation segment profiling
16:59 cotto_work mls: if you give me a commit bit, I can "fix" some of my documentation.  Some of the code made me crabby.
16:59 mls of course. what's your github id?
17:00 cotto_work cotto
17:00 mls (should have known...)
17:00 cotto_work better to ask anyway
17:00 mls yes, mls was already taken, so I have mlschroe as id...
17:00 JimmyZ not_gerd:  yeah
17:01 JimmyZ not_gerd:  I will revert tomorrow,
17:01 cotto_work I have a love/hate relationship with that code.  I love that it's useful for Rakudo, but the implementation is a bit raw.
17:01 JimmyZ good night
17:01 cotto_work JimmyZ: 'night
17:01 mls cotto: you're now a collaborator
17:02 cotto_work with great power comes great something something
17:02 mls ;)
17:03 cotto_work mls: is implementing hashing functionality your long-term plan or was it an expedient?
17:05 mls the code was just a quick hack I did on an evening. I did my own hashing because I didn't want to spend much time learning the parrot way
17:05 cotto_work ok.  So if I wrote a patch to use Parrot's hashing, you wouldn't mind?
17:05 mls I never expected the code to become a part of parrot
17:06 mls of course not. Please change anything you like to make it more parrotish
17:06 cotto_work Great.
17:07 cotto_work mls: what timezone are you in?
17:07 cotto_work aloha: clock?
17:07 aloha cotto_work: LAX: Tue, 10:07 PDT / CHI: Tue, 12:07 CDT / NYC: Tue, 13:07 EDT / UTC: Tue, 17:07 UTC / LON: Tue, 18:07 BST / BER: Tue, 19:07 CEST / TOK: Wed, 02:07 JST / SYD: Wed, 03:07 EST
17:07 cotto_work istr BER+1
17:07 mls I'm located in germany, i.e. CEST
17:07 cotto_work ok
17:10 nine whiteknight: what's the status of kill_threads? Do you have anything I could do?
17:14 whiteknight nine: I think I have most of the details sorted out and most functionality-based tests are passing now. My last commit was an 'orrible hack, but that shouldn't stop a merge
17:14 nine whiteknight: except that it doesn't build for me :)
17:14 whiteknight nine: Which compiler?
17:14 whiteknight It might have problems with a g++ build. I'm notoriously bad at keeping g++ happy
17:15 nine whiteknight: it is g++. So I'll try to clean up
17:15 whiteknight oh, thanks!
17:15 whiteknight besides that, and a merge to master, there's probably not much to do in that branch
17:15 whiteknight next step is in getting a replacement set up
17:16 mls afk -> home
17:16 nine whiteknight: I read that there's already some greenlet implementation from a GSOC student?
17:16 zby_home joined #parrot
17:16 whiteknight nine: Never completed.
17:17 whiteknight nine: the gsoc_threads branch
17:17 cotto_work whiteknight: there's already some code to return a static interp.  look for "emergency_inter".
17:17 whiteknight nine: you're welcome to cannibalize that branch as much as you want
17:17 dukeleto cotto_work: what are your thoughts about api.yaml + changes to the dep policy?
17:17 cotto_work *"emergency_interp".  I use it to print a backtrace when Parrot explodes horribly.
17:17 whiteknight I think there's enough momentum building behind implementing a precise GC and skip stackwalking. That should do a lot towards thread-safety
17:17 dukeleto nine: you need something to hack on?
17:18 dukeleto cotto_work: my thoughts are: if we decide to scrap most or all of the dep policy, api.yaml becomes *even* more important
17:18 whiteknight dukeleto: We still want a record of changes so users can keep abreast of them
17:18 whiteknight dukeleto: We just don't want wait periods and rigid procedure for making changes
17:18 whiteknight api.yaml seems like a good enough record of things
17:18 nine dukeleto: something threading/concurrency related, since I try to improve the Perl 6 spec/Rakudo in that regard
17:18 cotto_work whiteknight: I hadn't thought of it like that.
17:18 dukeleto whiteknight: i agree. So I think what we want is more flexibility *and* more transparency about api-breaking changes
17:19 cotto_work That does imply that we have something we call an api though.
17:19 darbelo joined #parrot
17:19 whiteknight dukeleto: Right. The way I see it, there's no functional difference whether we put in a notice 3 months ahead of time, or 3 days ahead of time. Users don't tend to notice until they try to upgrade anyway
17:19 dukeleto nine: whiteknight has some very nice blog posts about new ways of implementing concurrency stuff. Reading through those and trying to implement some of them may interest you
17:19 whiteknight what we need is a record of what changes, and a willingness to fix things that break
17:20 nine dukeleto: that's where I read about that GSOC greenlet implementation :)
17:20 dukeleto and automated tools to make it dead simple for HLL devs to figure out why their code stops working
17:20 cotto_work I don't see as much value in a record of what's changed, but I don't mind keeping such a record around.
17:21 dukeleto i really want to see a web interface that ties into api.yaml, uses info from plumage about each parrot-related project and lets us know where code will break
17:22 dukeleto cotto_work: i see a lot of value in it. Some HLL devs may only choose to use every other supported release or something like that. They will want to know what all the recent api-changes are
17:22 cotto_work dukeleto: that assumes we'll still have supported releases.
17:22 cotto_work I'm anticipating a lot of turbulence in the coming months.
17:22 dukeleto cotto_work: not really. The argument still stands for the dude that tries to update their HLL every 6 months
17:23 dukeleto which is not unreasonable
17:48 ilbot2 joined #parrot
17:48 Topic for #parrot is now Parrot 3.7.0 "Wanda" | http://parrot.org | Log: http://irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
17:49 pyrimidine joined #parrot
17:50 nine whiteknight: sent a pull request
17:51 whiteknight nine++
18:01 fperrad joined #parrot
18:03 contingencyplan joined #parrot
18:06 nine whiteknight: I did a merge of master into kill_threads and cleaned up the conflicts. Want that as well?
18:24 whiteknight nine: sure, if there are lots of conflicts
18:25 whiteknight dukeleto: here's a rough draft: https://gist.github.com/1198521
18:33 pmichaud_ whiteknight: I just now saw your "sub_problems.html" post.  It has a major error.
18:33 whiteknight pmichaud_: only one?
18:33 Coke git question. I merge, I git a conflict. I fix the conflict, use git rm or git add to mark it as fixed... then what? how do I continue the merge?
18:33 pmichaud_ at least one.
18:33 whiteknight Coke: the merge is done. Push
18:33 pmichaud_ you propose making Closure a subclass of Sub.  That's wrong wrong wrong
18:33 nine Coke: commit
18:33 whiteknight pmichaud_: did I?
18:33 pmichaud_ In fact, Parrot used to have it that way, and it caused no end of trouble.
18:33 pmichaud_ "Closure should be either a subclass of Sub or, if we want more flexibility, it should be a mixin."
18:34 whiteknight oh, right. Yes
18:34 pmichaud_ In Perl 6, every HLL sub is a closure.
18:34 whiteknight Closures currently are subs, but are cloned in a very haphazard way
18:34 pmichaud_ Indeed, for many dynamic languages, "Closure" is the primitive.
18:34 Coke whiteknight, nine - many other files showing as modified under 'git st'
18:35 Coke "Changes to be committed"
18:35 nine Coke: that's how it'S supposed to be
18:35 pmichaud_ I'm not sure it makes sense (for us) to have subs that aren't aware of lexical scoping.
18:35 nine Coke: it shows you all the changes that are gonna merged. If you commit now it should preseed the commit message and list the conflicted files
18:35 Coke nine: so I'm clearly missing something. ;)
18:36 pmichaud_ the real problem is that Parrot confuses static subs with dynamic invocation
18:36 Coke ah.
18:36 nine Coke: looks scary at first, but one gets used to it :)
18:36 whiteknight pmichaud_: In Parrot today, a closure is little more than a Sub with an ->outer_ctx set
18:36 pmichaud_ whiteknight: I know -- I suspect I'm the last person to have worked on that code.
18:37 whiteknight the new_closure opcode clones the Sub and sets ->outer_ctx to interp->current_ctx, which itself is also a problem
18:37 whiteknight pmichaud_: my point was that a closure seems like it could become a light-weight pairing of Sub+OuterCtx
18:37 pmichaud_ Closure is really "CallFrame", or "CallContext" as we have it now
18:38 pmichaud_ a Closure needs to capture its outer context and the state of its own variables.
18:38 whiteknight pmichaud_: so then what we currently call a "Closure" in Parrot, and what the new_closure opcode is returning isn't really a closure
18:38 Coke nine - if I had no conflicts, there would have no need to commit there, eh?
18:39 pmichaud_ it's a closure, in that it's the thing that captures the dynamic context.
18:39 pmichaud_ I agree that that thing shouldn't be a Sub.
18:39 Coke nine,whiteknight ; retesting and pushing shortly.
18:39 pmichaud_ I go farther in saying that it shouldn't be a subclass of Sub.
18:40 whiteknight pmichaud_: my motivation, of course, is that the Sub is currently responsible for far too many disparate tasks, and we need to separate out concerns. If lexical scoping is a fundamental component of an "invokable thing" so be it
18:40 nine Coke: no, git would just do the commit for you automatically
18:40 whiteknight pmichaud_: It strikes me as being extraneous to core invocation, but maybe I am ignorant of some prior art
18:41 dmalcolm joined #parrot
18:41 whiteknight pmichaud_: so a closure would be completely separate from Sub?
18:41 pmichaud_ I think that could be ideal, yes.
18:41 dalek parrot: 3db97f6 | Coke++ | / (8 files):
18:41 dalek parrot: Merge branch 'tt_2184'
18:41 dalek parrot:
18:41 dalek parrot: deleted NEWS, updated ChangeLog with recent typo fix.
18:41 dalek parrot:
18:41 dalek parrot: Conflicts:
18:41 dalek parrot: ChangeLog
18:41 dalek parrot: NEWS
18:41 dalek parrot: review: https://github.com/parrot/parrot/commit/3db97f6ec4
18:41 pmichaud_ but there's also the fact that it needs to be possible to get from a Sub reference to its currently (or most recent) active closure
18:42 whiteknight pmichaud_: okay, so a hypothetical new Closure PMC type would has-a Sub and has-a parent context?
18:42 whiteknight why would we need the current or most recent one?
18:42 pmichaud_ i.e.,   if I say   &foo  in Perl 6, I need to be able to reference the sub as well as its most recent closure
18:42 Coke are we still killing branches-merged-back?
18:42 cotto_work Coke: I try to.
18:42 pmichaud_ my $xyz = &foo;   #  &foo is both a reference to a sub and to its most recent Closure
18:43 whiteknight oh wow
18:43 pmichaud_ my $stuff = { ...code... };
18:43 pmichaud_ if I ask about $stuff, it's a Code object that has somehow captured its state
18:43 pmichaud_ so it has both a static component (the Sub) and a dynamic one
18:43 whiteknight pmichaud_: so $stuff is a tuple of state+code?
18:44 pmichaud_ I'd need to review to see how 6model currently handles this.  I do know (and agree) that Parrot's model is wrong, but moving the Closure stuff out of sub will also be wrong as well).
18:44 * Coke tries to read lamia's email and is confused.
18:45 * Coke wonders if that's what parrot docs look like to outsiders.
18:45 cotto_work #ps in 45
18:45 whiteknight pmichaud_: I can push that part of the refactors towards the end when we have a clearer idea of what the end result should be
18:45 pmichaud_ another problem with having Closure as a separate object is that Methods and Coroutines need to be able to handle lexical scoping as well
18:45 pmichaud_ at one time, Parrot has   Closure is Sub,  Coroutine is Sub
18:46 cotto_work Coke: I started reading and decided I have better things to do.  I'm glad to work with people who can put effort into making themselves understood.  I didn't feel like the author of that message tried hard.
18:46 pmichaud_ which meant that Coroutines could never have lexical scoping
18:46 pmichaud_ because the lexical capture stuff was all embeded in Closure
18:46 whiteknight pmichaud_: so that's what I'm saying is we create a new Closure type that has a Sub ref and a Context ref. Then creating a new closure means " new Closure(sub, context) ", not " sub.clone( :context(context) ) "
18:46 Coke cotto agreed. that said, no doubt our docs need work.
18:47 whiteknight the later is what we currently have, more or less
18:47 pmichaud_ whiteknight: I guess I'm saying that whoever works on a Sub redesign needs to study the Perl 6 spec very carefully first.
18:48 cotto_work or talk with someone who has
18:48 pmichaud_ because closures have to be created and taken before a Sub is ever invoked
18:48 whiteknight pmichaud_: well, it's probably going to be me. If you can point me to the best documents to start my studies, I would be most appreciative
18:49 pmichaud_ all of those "capture_lex" instructions that PCT generates are setting the outer context for the nested static subs
18:49 pmichaud_ if you're proposing to make that into   new Closure(sub, context)    that sounds like it will get to be very expensive
18:50 pmichaud_ synopsis 4 has the lexical stuff
18:50 whiteknight there's a difference between a closure object that's bundled up and passed around, and what the world looks like from inside an executing Sub
18:51 whiteknight if the Closure were invoked, it could set up the outer ctx for the context, and pass that context to the Sub
18:51 pmichaud_ outer_ctx for a Closure has to be set long before it's invoked.  Indeed, that's the point.
18:51 pmichaud_ my $closure = { ... };   return $closure;
18:51 pmichaud_ then later
18:51 pmichaud_ $closure()
18:51 whiteknight right. Closure would be a tuple of the sub and the parent context. Invoke the Closure, the closure applies that parent context to the context then calls the sub
18:52 pmichaud_ parent context might work.
18:52 whiteknight I'll definitely read synopsis 4 before touching any of that code
18:54 Coke we have a branch that is 46K commits behind.
18:55 Coke (ah, some autogen'd github thing)
18:56 whiteknight gh-pages?
18:57 Coke aye
18:58 whiteknight yeah, that's a completely detached branch. I don't know why they aren't smarter about showing that it has no shared history
19:03 whiteknight I actually want to play with that a bit more
19:13 pmichaud_ whiteknight: in https://gist.github.com/1198521 where you identify things that "we should be doing", could you perhaps identify the HLL benefits that you think will accrue, especially for the items marked "large/high priority"?
19:13 pmichaud_ for example, I don't see how rewriting packfile loading is going to benefit NQP/Rakudo, although it apparently will require major updates to both.
19:15 whiteknight pmichaud_: sure thing.
19:15 whiteknight pmichaud_: I'll try to update it tonight
19:27 cotto_work back in 3 minutes
19:30 cotto_work #ps time
19:35 dalek winxed: e32101d | NotFound++ | winxedst1.winxed:
19:35 dalek winxed: refactor a bit if/unless emision
19:35 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/e32101dee8
19:44 plobsing joined #parrot
19:54 dalek parrot: a5e4c18 | cotto++ | config/gen/makefiles/root.in:
19:54 dalek parrot: add allhlltest as a makefile target
19:54 dalek parrot: review: https://github.com/parrot/parrot/commit/a5e4c184c8
19:56 mikehh joined #parrot
19:57 mikehh \query aloha
20:31 dalek winxed: 6e9ce8b | NotFound++ | winxedst1.winxed:
20:31 dalek winxed: fix breakage of new with qualified name unkown at compile time
20:31 dalek winxed: introduced in recent changes
20:31 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/6e9ce8b868
20:39 darbelo_ joined #parrot
20:40 zby_home joined #parrot
20:40 jsut joined #parrot
20:43 wknight-phone joined #parrot
20:59 dalek rakudo/nom: fe590ef | moritz++ | src/core/Str.pm:
20:59 dalek rakudo/nom: implement $limit in Str.lines
20:59 wknight-phone joined #parrot
20:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/fe590ef357
21:01 PacoLinux_ joined #parrot
21:03 wknight8112 joined #parrot
21:23 dukeleto oy vey. #ps just seems like a free-for-all of complaining today
21:26 PerlJam dukeleto: that's not quite how I see it.
21:27 dukeleto PerlJam: that must be pleasant
21:28 PerlJam dukeleto: no, it wasn't, but it's getting there.
21:28 cotto_work quite
21:28 bluescreen joined #parrot
21:31 dukeleto i see a lot of finger pointing and hurt feelings and very few actionable changes
21:31 Tene Huh; I haven't seen anything that looked like finger pointing or hurt feelings.
21:31 dukeleto cotto_work: perhaps you can underail #ps and point other discussions in here?
21:32 dukeleto cotto_work: un-derail
21:32 dukeleto that hyphen makes a big difference
21:32 PerlJam heh
21:32 * cotto_work wonders about under-ailing
21:33 cotto_work dukeleto: I don't think there's anything else that needs covering.  I was going to let it burn itself out.
21:34 dukeleto cotto_work: hokey dokey. we didn't make a weekly goal, though. We seem to have been letting that slip.
21:35 cotto_work dukeleto: good idea
21:35 PerlJam cotto_work: make sure to explicitly invite pmichaud, jnthn, moritz, etc. to #ps.   I don't think they've been participating in a long while.
21:36 pmichaud_ I won't speak for the others, but #ps became largely a waste of time for me.  the conversation was always focused on things that didn't help or impact what I was doing.
21:40 PerlJam pmichaud_: do you think that could change?  Are you willing to give it a try for a few weeks?  (or if #ps doesn't look like it will work, be available to help figure out what will?)
21:41 pmichaud_ indeed, lately I've stopped hanging out on #parrot because I've found discussions here to be more frustrating than anything else.
21:47 perlite joined #parrot
22:15 cotto_work pmichaud_: do you have any idea when about pct will get merged into nqp?
22:21 cotto_work 1, 6, 12, 18 months, etc
22:24 pmichaud_ cotto_work: >1 < 6
22:24 pmichaud_ 1 < n < 6
22:24 pmichaud_ I think jnthn++ and I figured on an october timeframe.
22:24 pmichaud_ might be november
22:24 jnthn Oct/Nov would fit well.
22:26 cotto_work so after that, hll interop work would be likely to not break?
22:30 pmichaud_ much less likely to break.
22:30 pmichaud_ it would then depend on where we are with targeting other vms
22:35 Tene pmichaud_: To be specific, my concern is that when I worked on hll interop in the past, I would get it working and then you would break it in parrot or drop it in rakudo.  After redoing that work three or four times with apparently nobody else caring, I'm not interested in doing it again to the same result.
22:35 pmichaud_ Tene: I understand your concern exactly.
22:35 pmichaud_ Since I can't guarantee it won't happen again, I won't.
22:36 dmalcolm_ joined #parrot
22:36 Tene I appreciate that.
22:36 pmichaud_ Right now the Rakudo user base clearly says that speed is much more important than just about anything else we can do.
22:37 Tene There was apparently some confusion over this in #ps; I just wanted to make sure I didn't misunderstand your response to me.
22:38 pmichaud_ I can guarantee that when I think it will be stable (or its priority has increased enough that we need to commit to it being stable), I'll let you know :)
22:38 pmichaud_ and that date is probably not too far off... but I'd like to see at least one more nqp-based language and some stability in pct before I could really speak to that.
22:40 Tene Maybe I'll see if I can get jnthn to help me with 6model for cardinal again.
22:41 dmalcolm__ joined #parrot
22:42 pmichaud_ Tene: sure thing.  and I still want to get partcl running on nqp.
22:42 pmichaud_ and it wouldn't bother me to do APL, or perhaps get NQR on the new nqp :)
22:42 pmichaud_ but right now we really have to get nom released.
22:46 plobsing_ joined #parrot
22:54 whiteknight joined #parrot
22:54 Util Coverity is complaining that the value for `except` is unused,
22:54 Util at line 749 of src/ops/core.ops in throw(invar PMC, invar PMC).
22:54 Util Comparing it to throw(invar PMC) just above it,
22:54 Util I wonder why `$1` is being used in line 752, rather than `except`.
22:54 Util Anyone have any thoughts from a casual glance at it?
22:55 Coke joined #parrot
22:57 dukeleto Util: looks like a bug. I would ask and verify that on parrot-dev
22:57 Tene Util: lemme look
22:59 Util afk 20 min; will backscroll. Thanks dukeleto and Tene
23:00 Tene Util: that looks like a bug to me.
23:00 Util Thanks
23:08 dalek TT #1895 closed by whiteknight++: [DEPRECATED] difference between :load and :init Sub flags
23:08 dalek TT #1895: http://trac.parrot.org/parrot/ticket/1895
23:09 Coke whiteknight: why "invalid" ?
23:09 whiteknight Coke: because why not? We decided not to pursue it
23:09 Coke (on tt 1895)
23:09 Coke whiteknight: could you say that in the ticket?
23:10 whiteknight I said it earlier. I'll say it again
23:10 Coke ah, that was six weeks ago.
23:10 whiteknight done
23:13 whiteknight cotto: ping
23:13 whiteknight or cotto_work, ping
23:13 whiteknight whichever answers first
23:14 NotFound We don't have a get_root_class opcode... maybe we need it.
23:15 cotto_work whiteknight: pong
23:15 cotto_work whiteknight: both nicks light up both irc clients
23:16 whiteknight cotto_work: any objections to a kill_threads merge?
23:16 cotto_work That was fast.
23:16 cotto_work whiteknight: how does allhlltest fare?
23:16 whiteknight haven't gotten that far yet
23:17 whiteknight not imminent, just wondering how we stand with respect to dep policy
23:17 cotto_work ah
23:18 cotto_work I love reviewing this branch.  tiny islands of green in a sea of red
23:21 cotto_work from a quick review, I like it.  From a deprecation pov, I'd say it's good if it doesn't mess up Rakudo.
23:22 cotto_work You might talk to pmichaud_ to show that we're doing that now. ;)
23:23 dalek TT #1283 closed by whiteknight++: rethrow should keep the backtrace of the original 'die'
23:23 dalek TT #1283: http://trac.parrot.org/parrot/ticket/1283
23:24 rfw joined #parrot
23:29 benabik joined #parrot
23:35 dalek winxed: 9926965 | NotFound++ | winxedst1.winxed:
23:35 dalek winxed: rearrange a bit class and namespace auxiliar classes and
23:35 dalek winxed: use HLL in class operator with qualified name
23:35 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/9926965ff8
23:47 benabik Looks like being in class for #ps meant I missed something interesting.  Shame I won't have time to read it until...?
23:51 cotto_work benabik: the short version is that we have the beginnings of a new support policy, but we need to start working more closely with Rakudo to figure out what serves us both best.
23:52 Util benabik: be sure to read the parrot-dev ML thread first: "Parrot is a foundering project on top of a wonderful vision"
23:52 benabik Util: Read that.  I have time to read e-mail.  :-)
23:52 Util :)
23:55 dalek TT #2136 closed by whiteknight++: libffi not detected when configured with clang
23:55 dalek TT #2136: http://trac.parrot.org/parrot/ticket/2136
23:58 dalek winxed: 96872ae | NotFound++ | winxedst1.winxed:
23:58 dalek winxed: Don't use tailcall optimization inside a try block
23:58 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/96872ae1da

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

Parrot | source cross referenced