Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 25 August 2011.
00:33 Patterner joined 01:04 woosley joined
cotto www.destroyallsoftware.com/blog/20...e-them-all 01:32
01:35 jsut_ joined
dalek rrot/nwellnhof/compiler_flags: 6f2c5c1 | jkeenan++ | config/init/hints/linux.pm:
On Linux, use settings appropriate for gcc or g++ as defaults. In
 01:43
rrot/nwellnhof/compiler_flags: 017401c | jkeenan++ | config/init/hints/linux.pm:
More debugging output for Linux hints file.
rrot: 5537051 | jkeenan++ | config/init/hints/linux.pm:
More debugging output for Linux hints file.
 01:57
rrot: e806062 | jkeenan++ | config/init/hints/darwin.pm:
More debugging output for Darwin hints.
 02:08
kudo/nom: c773a04 | Coke++ | t/spectest.data:
track failure modes
 03:14
cotto mls, ping 03:36
PerlJam cotto++ interesting email to parrot-dev. 03:43
cotto So far the responses have been positive. 03:46
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 :)
dalek rrot/mls/sub-profiler: 8091027 | cotto++ | / (2 files):
variable name clarification, struct commenting
 03:49
rrot/mls/sub-profiler: a5909f0 | cotto++ | / (8 files):
add subprof as a distinct runcore, now needs to be run with -Rsubprof
03:54 logie joined 05:08 zby_home joined 06:14 SHODAN joined
moritz \\o 06:16
cotto good morning, moritz 06:18
moritz I'm curious, everybody seems to be against the deprecation policy 06:20
who is actually in favor of itß
s/ß/?/
I think allison was
cotto moritz, I think it's more that it seemed like a good idea at the time. 06:21
moritz but who else?
cotto I used to. I suspect others did too (at least grudgingly). 06:22
07:05 nbrown joined 07:10 nbrown_ joined 07:13 mj41 joined 07:17 Kulag joined 07:21 contingencyplan joined
tadzik good morning #parrot 07:44
08:02 lucian joined 08:17 dodathome joined
mls morning parrot! 08:43
09:31 preflex joined 09:32 ligne joined
dukeleto ~~ 09:47
looks like trac.parrot.org has an expired SSL cert
moritz: ping 09:50
moritz dukeleto: pong
dukeleto moritz: i would not say that i am against the deprecation policy, but i also think it could use some modification 09:51
moritz: also, where you looking for me? I was visiting family off-grid for a few days
moritz dukeleto: -> /msg 09:52
dukeleto: anything in particular you'd like to see changed in the deprecation policy 09:59
dalek rrot: 4e204ad | dukeleto++ | api.yaml:
Clarify TT#1906 in api.yaml
 10:03
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
moritz: it can't find everything, but it sure can at least help with the easy 80% of deprecations
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:05
moritz: but i am not sure how to change the dep policy. Need to stew on it some more. 10:06
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
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.
moritz dukeleto: I didn't observe better quality, better stability, more awesomeness or anything else that warrants extra attention
(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
moritz: and if we don't, we should
moritz somehow that has never worked out for rakudo really well
because parrot isn't as stable as we seemed to assume when making the dep policy 10:09
I kinda agree on the trying to please everybody point
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
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 :)
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
moritz: that is just the lack of serious and automated performance testing on parrot. It randomly happened on a stable release, is my bet.
moritz: 25% of releases are stable, so the odds aren't particularly rare 10:12
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:15
dukeleto moritz: it emphasizes that rakudo very much needs parrot to insure that successive parrot releases will get faster and not slower. 10:16
moritz: as far as I know, we have never formally made that promiste, but we sure do try. We need better tools. 10:17
moritz: with better tools, we could make that promise. But right now, it would be a hard promise to keep. 10:18
moritz: i think we need to seriously consider what kind of performance requirements releases should have
11:06 autark joined 11:10 cosimo joined 11:12 JimmyZ joined 11:35 Infinoid joined, Psyche^ joined 11:42 plobsing joined
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
fix: gist.github.com/1197350
12:00 bluescreen joined
moritz tests 12:01
12:08 mtk joined
dalek rrot: 64522d5 | moritz++ | src/sub.c:
fix bug in Parrot_sub_get_line_from_pc

It used to compare the op against the size of the debug segment, not against the size of the code segment. Patch courtesy by mls++		 12:09
12:16 whiteknight joined
whiteknight good morning, #parrot 12:16
12:17 benabik joined
moritz o/ whiteknight 12:17
whiteknight hello moritz
benabik o/
whiteknight ...and benabik
12:17 bluescreen joined
tadzik good morning whiteknight . I'm not a bot, trust me. 12:18
moritz disbelieves anybody who says "trust me" 12:20
just as a habit
benabik moritz: It does mean they think you have a reason _not_ to trust them. 12:22
atrodo =~ 12:24
whiteknight I'm going to merge the whiteknight/pmc_is_ptr branch and not_gerd's improvements to master in a minute 12:30
unless anybody disagrees? 12:31
jnthn whiteknight: wfm
whiteknight: If nobody beats me to it, I'll bump the PARROT_REVISION we get in NQP/Rakudo once that happens.
So we get this and the mls fix.
whiteknight ok, awesome. Go teamwork!
I love when branches merge without conflicts 12:33
mls msg cotto I've set up a parrot clone at github.com/mlschroe/parrot/ to work a bit on the sub-profiler branch
dalek rrot: e9d0322 | Whiteknight++ | src/gc/fixed_allocator. (2 files):
Merge remote-tracking branch 'origin/whiteknight/pmc_is_ptr'
aloha OK. I'll deliver the message.
rrot: 6f57d17 | Whiteknight++ | src/gc/fixed_allocator.c:
Merge remote-tracking branch 'gerdr/whiteknight/pmc_is_ptr'
moritz mls: I'm sure you'll get a commit bit rather quickly if you submit a signed CLA 12:35
then we don't have the hassle of copying&pasting patches, forked repos and pull requests etc. 12:36
whiteknight we parroteers rather like pull requests 12:37
moritz you do?
whiteknight yeah. They're awesome
moritz I mean, I like them better than patches by email
whiteknight we'll still give out commit bits as needed, but pull requests are great
moritz but I even more prefer good commits to the target repo right away
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:38
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
:)
dalek p: 8ad13af | moritz++ | tools/build/PARROT_REVISION:
bump PARROT_REVISION to after the pmc_is_ptr merge
whiteknight all joking aside, I'm not sure how we do it in pre-M0 parrot
jnthn Worth doing, but hard until m0, I suspect
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
dalek kudo/nom: 860fe17 | moritz++ | / (2 files):
bump nqp revision, remove memory leak from NOMMAP
tadzik we're not having memory leaks on our roadmap anymore? Snap :/ 12:43
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?
whiteknight PLA uses C code, but I can keep that up to date if we have a good mechanism for doing it
Rakudo is the biggie 12:45
tadzik moritz: of course not, just kidding
plobsing whiteknight: that's why I mention static analysis. doing it by hand is too big.
even with gen_gc we missed a few spots
jnthn tadzik: If you find a new way to leak, please add a compact example to nommap :) 12:46
tadzik: Or actually just an RT :)
ttbot Parrot e54106bb i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/48856
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
There are plenty of good ideas, we just need to pick one and implement it
Coke cotto++
12:50 darbelo joined
atrodo cotto++ I agree 13:04
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
cotto/moritz: if we *were* supporting large numbers of users, it'd be essential for managing the maintenance burden
cotto/mortz: but, we're not
cotto/moritz: so it was a matter of preparing for a scenario that didn't play out 13:26
cotto/moritz: (no plan survives first contact with the enemy :)
moritz allison: good to know, thanks
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
allison cotto: every month seems a bit rapid of a pace
moritz we can still have "recommended" or "supported" release, even in absence of a strict deprecation policy
allison cotto: and, I know that we have some releases that are more "conservative/testing" and some that are more "innovative" 13:28
moritz: aye
cotto/moritz: the versioning scheme of major/minor/sub is useful for indicating which to package
i.e. which are intended for widespread use, and which are not 13:29
maybe X.X.# increments are development releases and X.#.X increments are "supported"? dunno 13:30
doesn't really matter, as long as it's consistent
atrodo It does seem a little magical from the outside that a release that ends with 0, 3, 6 or 9 is supported 13:31
allison atrodo: yup, it was a side-effect of the 3 month schedule 13:32
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
13:41 plobsing_ joined
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:41
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:42
JimmyZ whiteknight: ping 13:44
whiteknight pong
JimmyZ whiteknight: I patch this gist.github.com/1197562, and got Segmentation fault, I didn't know how to fix it 13:46
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."
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.
atrodo benabik> I assume that's implied at the begining of every sentence from whiteknight
benabik And afk again
whiteknight JimmyZ: some of that doesn't look right 13:51
JimmyZ whiteknight: I don't know what's wrong 13:52
whiteknight JimmyZ: I have to look at it more. I can't right now 13:53
JimmyZ whiteknight: thanks
benabik (As a note, I'm working in the sysadmin office this quarter, so I'll be on and off a LOT.) 13:54
whiteknight benabik: I want to get working on PACT too, if you think you have enough ideas there 13:55
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
benabik whiteknight: Arg. meeting about to start, I'll get on that sometime today. 13:58
whiteknight benabi++ 14:02
benabik++
tadzik could someone grant a user 'pfusik' access to opening trac tickets? 14:15
He's a friend from my PM group, wants to file a bug
whiteknight let me look
benabik whiteknight: 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
tadzik hrm
ok, I'm mailing him back 14:17
whiteknight tadzik: oh wait. nevermind. Try again
tadzik granted? I'm just mailing him back 14:18
benabik whiteknight: And it even has reasonable formatting now. Some of what I wrote may be pure bull, I was brainstorming. 14:19
whiteknight benabik: it's okay, I'll look at it 14:20
tadzik: yeah, I think the permissions are granted 14:21
tadzik great, whiteknight++
14:25 not_gerd joined
not_gerd good afternoon, #parrot 14:25
tadzik 'afternoon, not_gerd 14:26
not_gerd saw the discussion on stack walking in the logs
some thoughts on that: gist.github.com/1197666 14:27
whiteknight not_gerd: I merged the pmc_is_ptr branch and your changes to master this morning 14:31
not_gerd++
not_gerd: Yeah, we were thinking about something frame-based. The hard part is finding all the functions that need to get updated 14:34
14:35 bluescreen joined
whiteknight we're going to need something a little bit more dynamic too, because an exception can jump up multiple frames 14:35
benabik whiteknight: Associate frames with runloops? 14:36
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:37
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
Then, a fancy macro to hide the details, and we all win
benabik fsvo win
whiteknight if we can add this and avoid stack walking, there should be some noticable performance gains
plobsing_ we need to be able to support multiple frame stacks. multiple native threads may access the same interpreter (even if not concurrently). 14:39
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:40
plobsing_ what other native-thread-local state (as opposed to parrot-thread-local state) would a GC need? 14:41
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
actually, that could just be a flag or something
so maybe nothing
plobsing_ non-copying is done at parrot-thread resolution, no? 14:43
whiteknight what do you mean?
plobsing_ well parrot threads may or may not map 1:1 to native threads
the thing I am talking about has to do with native threads only
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
TT #2190: trac.parrot.org/parrot/ticket/2190
14:46 logie joined
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?
does it make a cpy of the stack like gnu guile or disallow that completely? 14:49
^copy
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)
benabik plobsing_: Is finalize just for exceptions? 14:51
plobsing_ benabik: exceptions are just continuations
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"?
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:53
whiteknight yeah, it just jumps back up to the owner runloop 14:54
not_gerd plobsing_: is that enough to support full CPS semantics?
benabik Interesting. An the continuation is marked "do not call", I hope?
whiteknight we don't use it much with normal continuations, because we don't use normal continuations much
not_gerd (which begs the question why the guile guys chose a different approach...)
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...
cotto ~~ 15:02
dalek rrot: b9261ad | cotto++ | / (57 files):
large batch of typo fixes, courtesy of pfusik++
 15:14
TT #2190 closed by cotto++: Typos 15:18
TT #2190: trac.parrot.org/parrot/ticket/2190
15:38 ehks joined
Coke cotto-- #applying changes to historic Changelog and NEWS items before merging back my branch@! 15:46
;) 15:47
cotto - there were changes to ext/* there also, which should have been pushed upstream. They'll just get overwritten on the next refresh.
whiteknight Coke: What's the ETA on that branch? 15:48
Coke notfound did the last thing weeks ago. 15:49
I see no reason not to merge it back now (TT#2184) 15:50
whiteknight if it's good to go, merge it today 15:51
or, as soon as possible
Coke do we have a preference for merging individual commits vs. a single merge commit? 15:54
whiteknight I don't think I have a preference. Whichever you think works best 15:55
dalek rrot/jimmy/gc_fixed_allocator_cleanup: 5f6ccb2 | jimmy++ | src/gc/fixed_allocator. (2 files):
various cleanup to fixed_allocator
 15:57
Coke also, how do we feel about updating "historic" text as in Changelog? 15:58
should I reapply those fixes?
Despite my earlier protest, I don't really care.
whiteknight Coke; I'm ambivalent. I don't think it matters. 16:08
I suspect cotto didn't go through the patch with a fine-toothed comb
dalek rrot/jimmy/gc_fixed_allocator_cleanup: 88f0795 | jimmy++ | src/gc/fixed_allocator.c:
revert some cleanups which is wrong
 16:26
rrot/jimmy/gc_fixed_allocator_cleanup: a7ec805 | jimmy++ | src/gc/fixed_allocator.h:
forgot add top_arena
cotto_work ~~ 16:34
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
cotto_work sure, just not optimal 16:36
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:37
dalek rrot/jimmy/gc_fixed_allocator_cleanup: 53b2df5 | jimmy++ | src/gc/fixed_allocator. (2 files):
removed some experimental code
 16:41
dukeleto ~~ 16:44
dalek rrot: 5f6ccb2 | jimmy++ | src/gc/fixed_allocator. (2 files):
various cleanup to fixed_allocator
rrot: 88f0795 | jimmy++ | src/gc/fixed_allocator.c:
revert some cleanups which is wrong
rrot: a7ec805 | jimmy++ | src/gc/fixed_allocator.h:
forgot add top_arena
rrot: 53b2df5 | jimmy++ | src/gc/fixed_allocator. (2 files):
removed some experimental code
rrot: 1a54763 | jimmy++ | src/gc/fixed_allocator. (2 files):
Merge branch 'jimmy/gc_fixed_allocator_cleanup'
cotto_work good morning, dukeleto 16:45
dukeleto cotto_work: how goes it?
cotto_work glad to have that message sent, now wondering what the best next step is. 16:46
#ps later today should be fun
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 tt.taptinder.org/cmdinfo/49226
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
that's the next best step
cotto_work whiteknight: sure. That's the obvious one. ;) 16:49
whiteknight anything less is not "best"
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
whiteknight the change he's recommending is to "scrap" it 16:50
take it out and shoot it
dukeleto also, the term "deprecation policy" is slightly ambiguous. What exactly do we mean by that?
whiteknight burn the ashes. Pee on the embers
dukeleto cotto_work: what about api.yaml ? 16:51
JimmyZ dukeleto: that's odd, I didn't remove top_arena 16:52
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
Coke dukeleto: I prefer "Support Policy", I think. 16:54
cotto_work mls: ping
JimmyZ sleeps 16:55
dukeleto whiteknight: the ssl cert being expired is teh suxors
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
dukeleto whiteknight: ah, awesomesauce.
Coke dukeleto: I believe Jerry was our primary contact for SSL stuff back in the dark ages.
oh. we actually paid some external agency for one pre-OSU
whiteknight Coke: Yes, we did the same
we bought the cert, and gave it to OSUOSL 16:57
Coke wonders if any of the current board is planning on running agian.
JimmyZ not_gerd: I din't see any difference
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?
not_gerd JimmyZ: they may be structurally equal if you change arenas to be singly-linked, but thes do different things
mls sure! 16:59
not_gerd JimmyZ: one lists arenas, the other items...
mls But I'm currently changing the code quite a bit, so that it also supports annotation segment profiling
cotto_work mls: if you give me a commit bit, I can "fix" some of my documentation. Some of the code made me crabby.
mls of course. what's your github id?
cotto_work cotto 17:00
mls (should have known...)
cotto_work better to ask anyway
mls yes, mls was already taken, so I have mlschroe as id...
JimmyZ not_gerd: yeah
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.
JimmyZ good night
cotto_work JimmyZ: 'night
mls cotto: you're now a collaborator
cotto_work with great power comes great something something 17:02
mls ;)
cotto_work mls: is implementing hashing functionality your long-term plan or was it an expedient? 17:03
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?
mls I never expected the code to become a part of parrot
of course not. Please change anything you like to make it more parrotish 17:06
cotto_work Great.
mls: what timezone are you in? 17:07
aloha: clock?
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
cotto_work istr BER+1
mls I'm located in germany, i.e. CEST
cotto_work ok
nine whiteknight: what's the status of kill_threads? Do you have anything I could do? 17:10
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 :)
whiteknight nine: Which compiler?
It might have problems with a g++ build. I'm notoriously bad at keeping g++ happy
nine whiteknight: it is g++. So I'll try to clean up 17:15
whiteknight oh, thanks!
besides that, and a merge to master, there's probably not much to do in that branch
next step is in getting a replacement set up
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
whiteknight nine: Never completed. 17:16
nine: the gsoc_threads branch 17:17
cotto_work whiteknight: there's already some code to return a static interp. look for "emergency_inter".
whiteknight nine: you're welcome to cannibalize that branch as much as you want
dukeleto cotto_work: what are your thoughts about api.yaml + changes to the dep policy?
cotto_work *"emergency_interp". I use it to print a backtrace when Parrot explodes horribly.
whiteknight I think there's enough momentum building behind implementing a precise GC and skip stackwalking. That should do a lot towards thread-safety
dukeleto nine: you need something to hack on?
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
dukeleto: We just don't want wait periods and rigid procedure for making changes
api.yaml seems like a good enough record of things
nine dukeleto: something threading/concurrency related, since I try to improve the Perl 6 spec/Rakudo in that regard
cotto_work whiteknight: I hadn't thought of it like that.
dukeleto whiteknight: i agree. So I think what we want is more flexibility *and* more transparency about api-breaking changes
cotto_work That does imply that we have something we call an api though. 17:19
17:19 darbelo joined
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
whiteknight what we need is a record of what changes, and a willingness to fix things that break
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
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.
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:21
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.
I'm anticipating a lot of turbulence in the coming months.
dukeleto cotto_work: not really. The argument still stands for the dude that tries to update their HLL every 6 months
which is not unreasonable 17:23
17:48 ilbot2 joined
moderator Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
17:49 pyrimidine joined
nine whiteknight: sent a pull request 17:50
whiteknight nine++ 17:51
18:01 fperrad joined 18:03 contingencyplan joined
nine whiteknight: I did a merge of master into kill_threads and cleaned up the conflicts. Want that as well? 18:06
whiteknight nine: sure, if there are lots of conflicts 18:24
dukeleto: here's a rough draft: gist.github.com/1198521 18:25
pmichaud_ whiteknight: I just now saw your "sub_problems.html" post. It has a major error. 18:33
whiteknight pmichaud_: only one?
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?
pmichaud_ at least one.
whiteknight Coke: the merge is done. Push
pmichaud_ you propose making Closure a subclass of Sub. That's wrong wrong wrong
nine Coke: commit
whiteknight pmichaud_: did I?
pmichaud_ In fact, Parrot used to have it that way, and it caused no end of trouble.
"Closure should be either a subclass of Sub or, if we want more flexibility, it should be a mixin."
whiteknight oh, right. Yes 18:34
pmichaud_ In Perl 6, every HLL sub is a closure.
whiteknight Closures currently are subs, but are cloned in a very haphazard way
pmichaud_ Indeed, for many dynamic languages, "Closure" is the primitive.
Coke whiteknight, nine - many other files showing as modified under 'git st'
"Changes to be committed" 18:35
nine Coke: that's how it'S supposed to be
pmichaud_ I'm not sure it makes sense (for us) to have subs that aren't aware of lexical scoping.
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
Coke nine: so I'm clearly missing something. ;)
pmichaud_ the real problem is that Parrot confuses static subs with dynamic invocation 18:36
Coke ah.
nine Coke: looks scary at first, but one gets used to it :)
whiteknight pmichaud_: In Parrot today, a closure is little more than a Sub with an ->outer_ctx set
pmichaud_ whiteknight: I know -- I suspect I'm the last person to have worked on that code.
whiteknight the new_closure opcode clones the Sub and sets ->outer_ctx to interp->current_ctx, which itself is also a problem 18:37
pmichaud_: my point was that a closure seems like it could become a light-weight pairing of Sub+OuterCtx
pmichaud_ Closure is really "CallFrame", or "CallContext" as we have it now
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
Coke nine - if I had no conflicts, there would have no need to commit there, eh?
pmichaud_ it's a closure, in that it's the thing that captures the dynamic context. 18:39
I agree that that thing shouldn't be a Sub.
Coke nine,whiteknight ; retesting and pushing shortly.
pmichaud_ I go farther in saying that it shouldn't be a subclass of Sub.
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
whiteknight pmichaud_: It strikes me as being extraneous to core invocation, but maybe I am ignorant of some prior art
18:41 dmalcolm joined
whiteknight pmichaud_: so a closure would be completely separate from Sub? 18:41
pmichaud_ I think that could be ideal, yes.
dalek rrot: 3db97f6 | Coke++ | / (8 files):
Merge branch 'tt_2184'

deleted NEWS, updated ChangeLog with recent typo fix.
Conflicts:
  \tChangeLog
  \tNEWS
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
whiteknight pmichaud_: okay, so a hypothetical new Closure PMC type would has-a Sub and has-a parent context? 18:42
why would we need the current or most recent one?
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
Coke are we still killing branches-merged-back?
cotto_work Coke: I try to.
pmichaud_ my $xyz = &foo; # &foo is both a reference to a sub and to its most recent Closure
whiteknight oh wow 18:43
pmichaud_ my $stuff = { ...code... };
if I ask about $stuff, it's a Code object that has somehow captured its state
so it has both a static component (the Sub) and a dynamic one
whiteknight pmichaud_: so $stuff is a tuple of state+code?
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.
Coke wonders if that's what parrot docs look like to outsiders. 18:45
cotto_work #ps in 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
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
at one time, Parrot has Closure is Sub, Coroutine is Sub
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
because the lexical capture stuff was all embeded in Closure
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) ) "
Coke cotto agreed. that said, no doubt our docs need work.
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.
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
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
pmichaud_ all of those "capture_lex" instructions that PCT generates are setting the outer context for the nested static subs 18:49
if you're proposing to make that into new Closure(sub, context) that sounds like it will get to be very expensive
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
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.
my $closure = { ... }; return $closure;
then later
$closure()
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
pmichaud_ parent context might work. 18:52
whiteknight I'll definitely read synopsis 4 before touching any of that code
Coke we have a branch that is 46K commits behind. 18:54
(ah, some autogen'd github thing) 18:55
whiteknight gh-pages? 18:56
Coke aye 18:57
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 18:58
I actually want to play with that a bit more 19:03
pmichaud_ whiteknight: in 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
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.
whiteknight pmichaud_: sure thing. 19:15
pmichaud_: I'll try to update it tonight
cotto_work back in 3 minutes 19:27
#ps time 19:30
dalek nxed: e32101d | NotFound++ | winxedst1.winxed:
refactor a bit if/unless emision
 19:35
19:44 plobsing joined
dalek rrot: a5e4c18 | cotto++ | config/gen/makefiles/root.in:
add allhlltest as a makefile target
 19:54
19:56 mikehh joined
mikehh \\query aloha 19:57
dalek nxed: 6e9ce8b | NotFound++ | winxedst1.winxed:
fix breakage of new with qualified name unkown at compile time
 20:31
20:39 darbelo_ joined 20:40 zby_home joined, jsut joined 20:43 wknight-phone joined
dalek kudo/nom: fe590ef | moritz++ | src/core/Str.pm:
implement $limit in Str.lines
 20:59
20:59 wknight-phone joined
21:01 PacoLinux_ joined 21:03 wknight8112 joined
dukeleto oy vey. #ps just seems like a free-for-all of complaining today 21:23
PerlJam dukeleto: that's not quite how I see it. 21:26
dukeleto PerlJam: that must be pleasant 21:27
PerlJam dukeleto: no, it wasn't, but it's getting there. 21:28
cotto_work quite
21:28 bluescreen joined
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.
dukeleto cotto_work: perhaps you can underail #ps and point other discussions in here?
cotto_work: un-derail 21:32
that hyphen makes a big difference
PerlJam heh
cotto_work wonders about under-ailing
dukeleto: I don't think there's anything else that needs covering. I was going to let it burn itself out. 21:33
dukeleto cotto_work: hokey dokey. we didn't make a weekly goal, though. We seem to have been letting that slip. 21:34
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.
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:36
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:40
pmichaud_ indeed, lately I've stopped hanging out on #parrot because I've found discussions here to be more frustrating than anything else. 21:41
21:47 perlite joined
cotto_work pmichaud_: do you have any idea when about pct will get merged into nqp? 22:15
1, 6, 12, 18 months, etc 22:21
pmichaud_ cotto_work: >1 < 6 22:24
1 < n < 6
I think jnthn++ and I figured on an october timeframe.
might be november
jnthn Oct/Nov would fit well.
cotto_work so after that, hll interop work would be likely to not break? 22:26
pmichaud_ much less likely to break. 22:30
it would then depend on where we are with targeting other vms
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.
Since I can't guarantee it won't happen again, I won't.
22:36 dmalcolm_ joined
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.
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:37
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
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.
Tene Maybe I'll see if I can get jnthn to help me with 6model for cardinal again. 22:40
22:41 dmalcolm__ joined
pmichaud_ Tene: sure thing. and I still want to get partcl running on nqp. 22:42
and it wouldn't bother me to do APL, or perhaps get NQR on the new nqp :)
but right now we really have to get nom released.
22:46 plobsing_ joined 22:54 whiteknight joined
Util Coverity is complaining that the value for `except` is unused, 22:54
at line 749 of src/ops/core.ops in throw(invar PMC, invar PMC).
Comparing it to throw(invar PMC) just above it,
I wonder why `$1` is being used in line 752, rather than `except`.
Anyone have any thoughts from a casual glance at it?
22:55 Coke joined
dukeleto Util: looks like a bug. I would ask and verify that on parrot-dev 22:57
Tene Util: lemme look
Util afk 20 min; will backscroll. Thanks dukeleto and Tene 22:59
Tene Util: that looks like a bug to me. 23:00
Util Thanks
dalek TT #1895 closed by whiteknight++: [DEPRECATED] difference between :load and :init Sub flags 23:08
TT #1895: trac.parrot.org/parrot/ticket/1895
Coke whiteknight: why "invalid" ? 23:09
whiteknight Coke: because why not? We decided not to pursue it
Coke (on tt 1895)
whiteknight: could you say that in the ticket?
whiteknight I said it earlier. I'll say it again 23:10
Coke ah, that was six weeks ago.
whiteknight done
cotto: ping 23:13
or cotto_work, ping
whichever answers first
NotFound We don't have a get_root_class opcode... maybe we need it. 23:14
cotto_work whiteknight: pong 23:15
whiteknight: both nicks light up both irc clients
whiteknight cotto_work: any objections to a kill_threads merge? 23:16
cotto_work That was fast.
whiteknight: how does allhlltest fare?
whiteknight haven't gotten that far yet
not imminent, just wondering how we stand with respect to dep policy 23:17
cotto_work ah
I love reviewing this branch. tiny islands of green in a sea of red 23:18
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:21
You might talk to pmichaud_ to show that we're doing that now. ;) 23:22
dalek TT #1283 closed by whiteknight++: rethrow should keep the backtrace of the original 'die' 23:23
TT #1283: trac.parrot.org/parrot/ticket/1283
23:24 rfw joined 23:29 benabik joined
dalek nxed: 9926965 | NotFound++ | winxedst1.winxed:
rearrange a bit class and namespace auxiliar classes and
 23:35
benabik Looks like being in class for #ps meant I missed something interesting. Shame I won't have time to read it until...? 23:47
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:51
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. :-)
Util :)
dalek TT #2136 closed by whiteknight++: libffi not detected when configured with clang 23:55
TT #2136: trac.parrot.org/parrot/ticket/2136
nxed: 96872ae | NotFound++ | winxedst1.winxed:
Don't use tailcall optimization inside a try block
 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!