Parrot 0.6.3 "Beautiful Parrot" Released | parrotcode.org/ | 5/649/88 new/open/stalled tix | logged in irclog.perlgeek.de/parrot/today
Set by moderator on 26 June 2008.
dalek r29271 | jkeenan++ | parallel: 00:08
: Extract most object methods from Parrot::Configure and place them in
: Parrot::Configure::Base, whence they can be inherited by new class
: Parrot::Configure::Parallel as well. The latter has the same structure as the
: Parrot::Configure object.
purl i guess : parrot::configure object is now a singleton. So most tests have been put in a
dalek diff: www.parrotvm.org/svn/parrot/revision?rev=29271
00:09 AndyA joined 00:13 cotto_work joined
Whiteknight hah! i just got my first core dump! 00:21
cotto_work take a picture! 00:27
purl It'll last longer!
00:29 Limbic_Region joined 00:36 bacek joined
dalek r29272 | Whiteknight++ | gsoc_pdd09: 00:36
: [gsoc_pdd09] A few changes:
: * fix problem where sized pools are getting double-swept
: * improve (maybe not fix) card setting function to avoid overlapping
: * fix bounds-checking on cards in pool sweep code.
: * Update comments and readme
diff: www.parrotvm.org/svn/parrot/revision?rev=29272
Whiteknight slowly but surely, I'm getting this to work right 00:37
Limbic_Region Whiteknight: when does SoC end? 00:40
Whiteknight too soon
purl too soon is www.encyclopediadramatica.com/index.php/Too_soon
Whiteknight i dont know when exactly\\ 00:41
it doesn't matter, i plan to parrot for a long time
Limbic_Region well, that's good
particle aug17 iirc
Limbic_Region I was just wondering if there were required deliverables by a certain time frame
particle soccer &
00:57 Ademan joined 01:05 petdance joined 01:26 Ademan joined
TimToady there is no bool type in Perl 6, nor is there a true or false value. The type name is Bool, and its enum is False,True 01:42
you can say .Bool, but that's just a type coercion like .Int 01:43
dalek r29273 | cotto++ | trunk: 01:45
: [codingstd] wrap macro args in src/jit/mips/jit_emit.h
diff: www.parrotvm.org/svn/parrot/revision?rev=29273
pmichaud TimToady: so, S12 is incorrect about the built-in "bool" enum? 01:49
dalek r29274 | cotto++ | trunk: 01:55
: [codingstd] wrap macro args in src/jit/ia64/jit_emit.h
diff: www.parrotvm.org/svn/parrot/revision?rev=29274
02:10 teknomunk joined 02:28 particle1 joined 02:30 rdice joined 02:40 wknight8111 joined
dalek r29275 | jkeenan++ | parallel: 02:51
: Create pcfreeze() and replenish() as wrappers around Storable::nfreeze and
: thaw. Combine two test files into one, replenishing the Parrot::Configure
: object to do so.
diff: www.parrotvm.org/svn/parrot/revision?rev=29275
kid51 must sleep 02:53
purl $kid51->sleep(8 * 3600);
dalek r29276 | cotto++ | trunk: 03:32
: [codingstd] ignore token concatenation when looking for unwrapped macro args
diff: www.parrotvm.org/svn/parrot/revision?rev=29276
r29277 | cotto++ | trunk: 04:01
: [codingstd] Wrap macro args in src/jit/i386/jit_emit.h. Yes, all of them.
diff: www.parrotvm.org/svn/parrot/revision?rev=29277
bacek moritz: around? 05:10
purl nope.
05:20 baest joined 05:21 Psyche^ joined
baest identify spade 05:21
whoops
05:56 uniejo joined
dalek r29278 | cotto++ | trunk: 06:05
: [codingstd] wrap macro args in src/jit/hppa/jit_emit.h
diff: www.parrotvm.org/svn/parrot/revision?rev=29278
r29279 | cotto++ | trunk: 06:28
: [codingstd] wrap macro args in src/jit/arm/jit_emit.h
diff: www.parrotvm.org/svn/parrot/revision?rev=29279
06:46 barney joined, Ademan joined
dalek r29280 | cotto++ | trunk: 07:07
: [codingstd] wrap macro args in src/jit/amd64/jit_emit.h
diff: www.parrotvm.org/svn/parrot/revision?rev=29280
moritz bacek: now I'm around 07:09
good morning ;)
bacek moritz: I already started my friday night beer :)
moritz: I actually want to ask for apache rewrite rules for ilbot.
moritz bacek: aren't they in the repo? 07:14
svn.pugscode.org/pugs/misc/irclog/cgi/.htaccess 07:15
dalek r29281 | cotto++ | trunk: 07:16
: [codingstd] wrap macro args in src/jit/alpha/jit_emit.h
diff: www.parrotvm.org/svn/parrot/revision?rev=29281
bacek moritz: OSHI...
moritz perhaps I should have named it just htacess in there ;) 07:17
bacek moritz: good idea :) I didn't realize that it already here...
07:27 mire joined
dalek r29282 | cotto++ | trunk: 07:34
: [codingstd] wrap macro args in various files
diff: www.parrotvm.org/svn/parrot/revision?rev=29282
r29283 | chromatic++ | trunk: 08:01
: [OO] Made get_class and typeof return the same PMCProxy PMC. See RT #56816.
: There may be a further performance improvement available by caching the
: PMCProxy as needed for each built-in PMC, but it's only useful if you extend a
: built-in PMC from PIR.
diff: www.parrotvm.org/svn/parrot/revision?rev=29283
mj41 hi, 29277, 2008-07-11 06:00:54, cotto - breaks trunk? .... tt.ro.vutbr.cz/report/pr-Parrot/dif...e+selected
or anything odd with TapTinder? 08:03
08:04 iblechbot joined 08:06 jq joined
cotto_home mj41, I'll look into it. Thanks for noticing. 08:08
nopaste "mj41" at 147.229.5.124 pasted "to cotto, make error" (30 lines) at nopaste.snit.ch/13557 08:12
cotto_home how did you run Configure.pl? 08:14
nopaste "mj41" at 147.229.5.124 pasted "configure output" (88 lines) at nopaste.snit.ch/13558 08:16
mj41 $make_cmd = 'make'; 08:17
$conf_cmd = 'perl Configure.pl';
cotto_home I'm not getting that failure. 08:20
I'll look through the diff for something obviously broken I missed the first time. 08:21
moritz gets and error in t/tools/dump_pbc.t 08:22
cotto_home Something tells me my karma's not going to look very good in the morning. 08:23
mj41 imho it's ok, many commits, but only one broken and probably only for one/my machine configuration :-) 08:28
cotto_home found something suspicious 08:33
try lowercasing sTI on line 1141 of src/jit/i386/jit_emit.h and see if that fixes the break 08:34
or just svn up 08:36
dalek r29284 | cotto++ | trunk: 08:37
: [jit] fix a capitalization bug
diff: www.parrotvm.org/svn/parrot/revision?rev=29284
cotto_home you still there?
mj41++ #for finding and reporting the break 08:39
moritz captilization bug => captital punishment? ;-) 08:41
cotto_home It's almost 2:00 here and I need sleep. If it's still broken msg me via purl and I'll take care of it in the morning.
moritz, is your t/tools/dump_pbc.t failure related to mj41's? 08:42
moritz cotto_home: don't know, but don't think so 08:43
mj41 cotto, good night, see tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk at the morning
moritz cotto_home: go get some sleep ;-)
cotto_home sleep & 08:44
nopaste "mj41" at 147.229.5.124 pasted "r29284 - make error (broken in 29277)" (74 lines) at nopaste.snit.ch/13559 08:49
dalek r29285 | bernhard++ | trunk: 09:34
: [Rekudo] Some tidbits in docs/compiler_overview.pod and README
diff: www.parrotvm.org/svn/parrot/revision?rev=29285
r29286 | bernhard++ | trunk: 10:01
: [Pipp] Steal the quote-parsing code from Rakudo.
: But don't use it yet.
diff: www.parrotvm.org/svn/parrot/revision?rev=29286
10:14 Whiteknight joined 10:19 donaldh joined 10:21 Auzon joined 10:23 skv_ joined
dalek r29287 | bernhard++ | trunk: 11:01
: [Pipp] Use 'quote_expression' for single and double quoted strings.
diff: www.parrotvm.org/svn/parrot/revision?rev=29287
11:03 idemal joined
dalek r29288 | bernhard++ | trunk: 11:27
: [Pipp PCT] Merge the rules 'array_assign' and 'scalar_assign' into 'var_assign'.
: Support interpolation of keyed variables in a string.
diff: www.parrotvm.org/svn/parrot/revision?rev=29288
11:39 ruoso joined 11:40 uniejo joined, Whiteknight joined
dalek r29289 | julianalbo++ | trunk: 11:46
: Fix a typo in i386 jit_emit.h
diff: www.parrotvm.org/svn/parrot/revision?rev=29289
12:10 Infinoid joined 12:43 iblechbot joined 12:54 rurban joined
dalek r29290 | pmichaud++ | trunk: 13:05
: [rakudo]: spectest-progress.csv update: 95 files, 1691 passing tests
diff: www.parrotvm.org/svn/parrot/revision?rev=29290
13:14 Ademan joined
dalek r29291 | kjs++ | trunk: 13:15
: [docs] update pct docs a bit.
diff: www.parrotvm.org/svn/parrot/revision?rev=29291
r29292 | kjs++ | trunk: 13:25
: [pdd19] add :lexid, but description not complete yet (not sure about details).
diff: www.parrotvm.org/svn/parrot/revision?rev=29292
r29293 | kjs++ | trunk: 13:26
: [chitchat] add more action methods.
: * made some assumptions/guesses from memory about semantics because lack of internet access and thus no access to reference.
: * grammar might need some tweaks.
diff: www.parrotvm.org/svn/parrot/revision?rev=29293
13:41 gryphon_ joined 13:46 rdice joined
dalek r29294 | bernhard++ | trunk: 13:51
: [Pipp PCT] Try to add support for complex string interpolation with curlies.
: But on input like
: echo "{}";
: an infinnite loop may happen.
diff: www.parrotvm.org/svn/parrot/revision?rev=29294
13:57 Whiteknight joined 14:01 NotFound joined
NotFound Hello 14:01
Whiteknight hello 14:03
purl salut, Whiteknight.
pmichaud hello 14:09
purl hola, pmichaud.
NotFound hello 14:11
purl hola, NotFound.
NotFound Doesn't like caps?
pmichaud too lazy to shift this morning ;-0
jonathan *groan* 14:15
dalek r29295 | Whiteknight++ | gsoc_pdd09: 14:17
: [gsoc_pdd09] updating to trunk r29294
diff: www.parrotvm.org/svn/parrot/revision?rev=29295
pmichaud jonathan: how hard would it be to get an outer Sub PMC to maintain a list of all of the (inner) Closure PMCs that reference it via :outer ? 14:20
14:20 ron joined
jonathan pmichaud: To maintain it, or to build it at compile time? 14:21
pmichaud (phone) 14:22
well, primarily build at compile time, but I suppose it's also possible for a Closure PMC to be GCed 14:24
(still on phone -- bbiab)
jonathan Hmmm...which could be a problem, because if it's on a list that we scan, it'll never get GC'd. 14:26
Whiteknight in my branch, it's not really possible for anything to get GC'd yet 14:28
14:39 jhorwitz joined
tewk Does parrot support weak references? 14:40
cognominal tewk, you don't need them 14:43
weak references is are kludge because reference counting has problem with structures that contains loops. 14:44
Infinoid volunteers to port weaken() to rakudo 14:45
cognominal that would be a noop? :) 14:53
Infinoid yep!
we could implement it in lolcode
hmm. since we have pluggable GCs, is a refcounting GC an option? so far it sounds like the API prevents that
(an answer of "there's no way you would ever want to do that" is also acceptable.) 14:54
cognominal in our communauty, we want to do whatever we want 14:55
14:57 Andy joined
Whiteknight Infinoid, I suspect that true reference counting is not currently possible, no 14:57
at least, not without major modifications 14:58
Infinoid thought so, thanks
it occurs to me that there's a huge amount of code that simply drops a pointer and expects things to be cleaned up automatically. that does keep the code a *lot* cleaner. 14:59
cognominal community! # I always trip on that one
15:08 rdice_ joined
pmichaud (off phone) 15:10
I was thinking that we wouldn't need to follow the inner_sub list to mark its members as live
just that when a Closure PMC was destroyed, it removed itself from it's outer_sub's list 15:11
*its
jonathan pmichaud: I haven't had chance to read your mails to the list yet, which probably give some context to this discussion. :-) 15:12
pmichaud I think only the last one is worth reading :-)
jonathan That aside - we statically know within a compilation unit what references a sub as being one of its outers. So it's possible. 15:13
pmichaud but essentially the bottom line is that we need to make sure that every inner sub has a newclosure performed on it at the time the outer sub is invoked
jonathan Can we not turn it around and lazily newclosure it if the outer sub has been invoked since we last were? 15:14
pmichaud apparently newclosure on invoke is a real problem
for one, we can't always know that we're invoking the inner directly from its outer 15:15
15:15 barney joined
pmichaud the sub might be invoked several levels deep, which means we have to chase up the call stack to hopefully find the sub that this was intended to be newclosured in 15:16
s:1st/the sub/the closure/; 15:17
jonathan Ah, you're saying newclosure is transitive?
pmichaud from what I gather from what I think rgrjr is saying, newclosure at the point of invoke is an issue.
jonathan OK.
pmichaud I'm not certain he's absolutely right about that or that it's unfixable, but I'm looking for other options. :-) 15:18
jonathan So, to answer your question - it's messy, but possible, particularly handling it from a GC perspective.
As far as I can see, anyway.
pmichaud okay, that's good enough for me.
jonathan But I'm answering without reading this in any kind of context.
pmichaud yes, no problem. I just wanted to know if I was overlooking anything obvious before I investigated it further.
jonathan After my last attempt at trying to fix closure stuff up for you, and the fallout of it, I kinda got fed up of it and wanted to do something else for a while... 15:19
pmichaud again, I think my latest post summarizes the issues fairly well and concisely describes how I think we can solve it
jonathan Parrot guts, at times, can be highly frustrating.
pmichaud and yes, I agree with the frustration, which is why I was looking into possibly doing this myself instead of shoving the frustration off to you :-)
Whiteknight agreed!
(Parrot guts can be highly frustrating)++ 15:20
pmichaud your latest changes for lexid and closures gave me enough "oh, here's how it works" details that I think I could make the changes myself if necessary, or at least do an experimental branch with them.
jonathan OK, that's something at least.
And lexid is something we needed anyway and I guess is here to stay. 15:21
pmichaud oh, definitely -- it was very informative and helpful for me.
on another topic (Bool versus bool) -- very interesting conversation with TimToady on #perl6 last night 15:22
irclog.perlgeek.de/perl6/2008-07-11
I don't things are entirely resolved yet, but it did help me to understand .Bool, .true, prefix:<?>, etc., or at least the way the spec is leaning at this point 15:23
jonathan Ah, I saw his commit and not the discussion; the commit didn't to me look to address all of the issues.
pmichaud yes, the discussion is exactly because to me the commit didn't look to address all of the issues :-) 15:24
jonathan In fact, it confused me more - I'll read the conversation log though.
pmichaud i.e., the conversation was a result of the commit, not vice-versa
jonathan Oh, OK. What came first... :-)
pmichaud (commit was at 2:03, conversation started at 3:00 :-)
dalek r29296 | Whiteknight++ | gsoc_pdd09: 15:27
: [gsoc_pdd09] rearrange marking for child objects to account for pointer dependencies. Add a few break statements where GC and DOD blocking might need to be tested.
diff: www.parrotvm.org/svn/parrot/revision?rev=29296
jonathan pmichaud: Too distracted with $otherjob to read it properly now, but will look later; thanks. 15:30
pmichaud no problem, just wanted to make sure you were aware of it
15:47 Theory joined
dalek r29297 | cotto++ | trunk: 15:50
: [codingstd] fix macro args test, making it catch all token concatenations
diff: www.parrotvm.org/svn/parrot/revision?rev=29297
15:58 sjansen joined 16:10 AndyA joined 16:11 gryphon_ joined
dalek r29298 | cotto++ | trunk: 16:16
: [codingstd] whitespace fix and line length fix
diff: www.parrotvm.org/svn/parrot/revision?rev=29298
r29299 | Whiteknight++ | gsoc_pdd09: 16:26
: [gsoc_pdd09] fixed bad ordering in sweep code. hdrs swept front-to-back, corresponding to cards from back-to-front. Fixed premature freeing of some PMCs, but now exposes random segfault in hash code.
16:26 uniejo joined
dalek diff: www.parrotvm.org/svn/parrot/revision?rev=29299 16:26
cotto_home can anyone see tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk ? 16:37
jhorwitz cotto_home: no
timeout
cotto_home thanks. 16:38
work &
barney cotto_home: I see it 16:42
jonathan pmichaud: Just read the discussion and not feeling like it really answers much. :| 16:49
pmichaud it doesn't yet, other than to say that it's not answered yet :-) 16:50
jonathan Think it's worth me mailing p6l? 16:51
pmichaud Larry's aware of it, I suspect we'll see an update soon.
jonathan OK.
16:51 rurban joined
pmichaud I'm looking at namespace interpolations for jhorwitz -- unfortunately we've got a lot of changes to make to existing code in actions.pm 16:51
jonathan I can imagine that classes in some places ain't handling namespaces the Right Way. 16:52
And likely the same for roles too.
pmichaud it's not just namespaces, but also method names and routine declarators
and enums
jonathan We need to be able to stick namespaces on these too? 16:53
pmichaud $foo.XYZ::method(...)
jonathan sub foo::bar::baz() { ... }
jonathan wonders how $foo.XYZ::Mehotd() parses
pmichaud <methodop> takes a <longname> which takes a <name> which can contain namespaces 16:54
<name> is anything with colons
as opposed to <ident>
jonathan Ah
pmichaud quite a bit of existing code wants to treat <name> like ident
jonathan Yes
Aye 16:55
pmichaud I'm not worried about sub foo::bar::baz() as much as I am sub foo::($bar)::baz() --- if such a thing is even legal.
jonathan Ah, longname includes colo pairs.
*colon
pmichaud well, for now it's sufficient to get <name> to work
jhorwitz pmichaud: fyi, that namespace interpolation patch is now broken ($past.name(undef) no longer works for call nodes). i'll update the ticket with a working patch.
jonathan morename?!
pmichaud jhorwitz: don't worry about it too much 16:56
jhorwitz: since STD.pm now says how interpolations get parsed, we'll want to go that way
jhorwitz what, me worry? ;-)
pmichaud I just have to figure out how to represent run-time namespace interpolations in the PAST nodes
jhorwitz ok, if it's getting the proper treatment, i'll leave it to you guys :) 16:57
jonathan pmichaud: Another thing to handle that I am pretty sure will be wrong now, is nested classes.
I did some work in that direction.
pmichaud oh, I know nested classes are likely wrong. I'd like to get basic namespaces working first, though.
jonathan (Making sure attributes and methods ended up in the right class, or role, etc)
But the namespace side of them is almost certainly wrong. It was on my "we'll worry about that later" things.
dalek r29300 | bernhard++ | trunk: 16:58
: [Pipp PCT] Rename token 'circumfix' to 'curly_interpolation'.
: Remove support for Q:w, Q:ww, and Q:regex in quote_expression(),
: as these aren't PHP features.
diff: www.parrotvm.org/svn/parrot/revision?rev=29300
jonathan I think that it'd be good to review namespace stuff in general though.
16:58 ruoso joined
jonathan There are times when I've been writing stuff that I've thought, "hmmm...might have to re-visit that for namespace issues later". 16:58
pmichaud I'm thinking that the namespace attribute in PAST nodes will need to be updated
as well as name, for that matter. 16:59
jonathan To be able to take a PAST tree rather than just a list?
pmichaud yes, to take a PAST tree.
jonathan OK
pmichaud that either returns an array or a namespace (haven't decided)
jonathan namespace may give more flexibility, but array may be easier to code-gen.
(As in, easier for compilers to generate) 17:00
(Not easier for PCT)
pmichaud well, given an array, one can always do PAST::Op.new('get_namespace', $array_past)
er
:pirop('get_namespace')
barney Yes, i probably need PAST nodes for 'name', for supporting ${ $name_of_var } in PHP
jonathan We can probably do MY:: with them too. 17:01
For Rakudo.
So yes, name as PAST tree in PAST::Var sounds good.
pmichaud MY:: ? I figured that was going to have to return the LexPad
jonathan Perhaps. 17:02
pmichaud yes, there is always the option of always treating namespaces as hashes
jonathan I meant a lookup within that.
pmichaud instead of using the get_*_global opcodes
jonathan We still have to use one of them to get at the namespace in the first place, I guess. 17:03
pmichaud I'm pretty sure that the get_*_global opcodes require a NameSpace PMC
anyway, I figured that MY:: would have to be special cased to return a Hash and we use a :keyed PAST::Var node for it
I don't know that we can do pseudo-namespaces using the get_*_global opcodes. 17:04
we could always do namespace lookups with get_*_namespace, and then use those as the base for :keyed nodes 17:05
jonathan nod 17:06
Yeah, I think you're right.
pmichaud which one? ;-)
jonathan That we probably have to have MY:: returning a hash and keyed index into it. 17:07
pmichaud same for OUTER::, CALLER::, etc.
jonathan Aye.
CALLER:: may be a little more fun. :-)
Becuase it'll have stuff in from many lexical scopes (all those in the caller) 17:08
cotto_work NotFound++ #cleaning up the build
jonathan On the upside, at least we now have a way to know what is a Routine and what is a Block. :-)
What's your kinda "work plan" / priorities at the moment? 17:09
pmichaud I'm increasingly concerned that we're putting in too many 'advanced' features before the basics are in yet 17:10
lexicals are still broken 17:11
closure support is broken
namespaces are broken
parameter passing is broken
NotFound pmichaud: me also.
pmichaud HLL support is broken
NotFound pmichaud: unicode is broken 17:12
pmichaud actually, unicode I can deal with. It's relatively isolated and pluggable
NotFound Well, it's not unicode, is the encoding system in general.
pmichaud still, it's quite pluggable. it's not as if a change to Parrot's string handling system is going to force huge code changes in the HLL stuff we're doing 17:13
jonathan Of those, a bunch of them appear to be as much Parrot level issues as high level ones. Which gives resolving them that extra bit of difficulty.
pmichaud yes, they are Parrot level issues also.
NotFound That's the problem I see, a fail in a HLL can come from a variety of sources and is difficult to diagnose. 17:14
pmichaud but I've had too much experience (e.g., S05/PGE) where changes to the underlying model has caused huge rewrites in the code that depends on it
jonathan parameter passing - because the Parrot model doesn't give the Perl 6 semantics? 17:16
pmichaud and is broken on its own, as well.
jonathan And not especialy fast.
NotFound jonathan: because is broken, there are a lot of unresolved tickets about it. 17:17
pmichaud allison has already approved the design for a new param passing model that supports Perl 6 semantics better
we just need an implementation :-)
NotFound A not broken one, preferably ;)
jonathan "just" :-(
NotFound pmichaud: What about the return values? 17:18
jonathan I've not read the details of what Allison suggested, but I'm fearful of putting any more features into the current implementation.
Not to mention trying to understand it in the first place.
pmichaud I don't think it is (or should be) "adding features" as much as "rethinking the implementation altogether" 17:19
the syntax and basic semantics are backwards-compatible with what we have now
jonathan I dived in there last night for a while and saw things like structs in structs in structs...
pmichaud (with one minor exception that I don't believe anyone can possibly be using)
yes, the new approach is likely much simpler
NotFound I completely fail to understand the current implementation when looking at some of the related tickets.
pmichaud I think the existing code suffered from a bit of premature optimization (that really wasn't) 17:20
jonathan branch and re-write would appear to be one option
pmichaud I think branch and re-write is likely the only viable option.
NotFound: return values are handled basically the same as subroutine invocation -- i.e., it's the same code
jonathan The other "fun" in it is handling NCI and arguments from C.
NotFound pmichaud: there is a problem with the return values when doing a tailcall, as a recent ticket exposed. 17:21
pmichaud NotFound: I think that's an implementation bug more than a design problem
and if we re-implement the parameter passing altogether, we can likely solve that bug
NotFound The problem seems to be that the C level call depends that the return values are exactly that it expects to be, and the tail call broke that assumption. 17:22
pmichaud anyway, as to my priorities: they are (in no specific order) HLL support, namespaces, lexicals, list assignment 17:23
NotFound But I'm not completely sure. As I say, I don't understand well the implementation.
pmichaud next tier would be signatures, parameter passing
oh, first tier also includes pre-compiled modules
jonathan OK. 17:24
17:24 Zaba joined
pmichaud HLL support, lexicals, parameter passing are blocked on fixes or updates to Parrot 17:24
jonathan My (small) issue is that my MMD grant is for July/August.
And explicitly non-extendable.
pmichaud yes, I know.
that's why I'm a bit frustrated and concerned that we can't get Parrot issues resolved quickly enough. 17:25
jonathan I don't want to distract from important things; equally, I don't want to let a donor down by not delivering.
NotFound By the way, will be nice if the pir or pbc generated by rakudo will be capable of autoloading the required libs and autostart himself.
pmichaud NotFound: this is explicitly planned. In order for that to work I have to resolve the :load/:init issues
which is yet another Parrot bug.
17:26 cotto-work joined
pmichaud (:load/:init doesn't play well with lexicals.) 17:26
jonathan pmichaud: Isn't that fixed in Allison's branch?
pmichaud yes, but when will that branch merge?
Zaba I'm back!
jonathan Heck knows, but I have a hard time believing that this particular fix is related to the concurrency things that are the subject of the branch. 17:27
pmichaud actually, I think it is related (more)
jonathan Has Allison said it would be hard to port it back into trunk?
pmichaud because the problem has to do with the separate runloops that occur for :init/:load versus the mainline code
jonathan Oh.
pmichaud and in the branch we don't have those runloop issues 17:28
(if I understand what Allison has said about it)
it shouldn't be hard to port back into trunk. The problem is that Allison is the primary one doing it, and she's overloaded with non-Parrot work until at least the 25th
(OSCON)
jonathan Right, I was about to say, progress on that branch will be slow for a while. 17:29
NotFound I've also seen a runloops related problem in the way pdb step code.
pmichaud so, unless/until everything starts magically working in the branch, the merge likely won't occur until the 25th
NotFound Someone is actually using pdb?
pmichaud anyway, as far as your MMD grant goes, I think we can go ahead and plan to reserve hacking days at YAPC::NA for you and I to focus on it intensely, if need be 17:30
sorry, YAPC::EU
jonathan Yes, there is that option too.
In terms of Parrot stuff
pmichaud i.e., if we haven't made progress on signatures by then, then that's what we're doing in August to the exclusion of all else :-)
signatures/MMD, I mean
jonathan How serious are the various issues as blockers? 17:31
pmichaud lexicals: serious
HLL: not too serious, we can continue to live in the 'parrot' namespace for a while and get incorrect types back from time to time 17:32
using precompiled modules: not serious, but profoundly beneficial in numerous respects -- most notably, the time needed to run 'make spectest_regression' 17:33
we can cut approx 6 minutes out of the time needed to run spectest_regression if we get precompiled modules working 17:34
also it allows us to start writing builtins in perl 6
but precompiled modules depends on load/init depends on lexicals
so I'm looking at a workaround for that
parameter passing: livable for now, but we need signatures resolved soon for mmd issues and because I don't like the way they're current factored in actions.pm 17:35
namespaces: increasing in importance, because we need to make sure that PCT supports all of the funky ways in which we deal with namespaces 17:36
(and because a lot of actions.pl depends on being able to grab names)
jonathan You have Parrot bugs relating to namespaces filed too, or that's mostly PCT work? 17:37
pmichaud it's PCT work
jonathan OK
pmichaud mostly design, since I first started thinking about it in depth in the context of jhorwitz' patch
jonathan Just trying to get a sense of, if I'm going to throw some time at Parrot guts, where is it best spent.
pmichaud lexicals continue to be -- by far -- the biggest headache. Nothing works without them. 17:38
well, very little works right without them. It's all a bunch of workarounds.
jonathan I don't want to do anything more on those from a code point of view until something that works for us, bob and others is worked out design wise, though. 17:39
pmichaud agreed. I don't know who needs to bless a design, though.
jonathan I need to throw a lot more brain cycles at the thing to realy understand what both of you are saying.
Well, Allison, I'd think. 17:40
NotFound At least, that the code matches the design documents.
jonathan I don't really feel like I should be saying "yes we can change the design", even if I think we should, without her OKing it.
pmichaud NotFound: I believe the design documents are incorrect here.
NotFound: there's no point in implementing a defective design.
NotFound Or even, that the code matches his own comments and pods. 17:41
pmichaud jonathan: I don't think it would be you saying "yes we can change the design". I think it would be more of "Pm, jonathan, Bob, and chromatic all agree that this is a workable design for now (where the existing one is broken), so we're going to implement it and if Allison wants to change it later then we'll revisit it later)
NotFound pmichaud: yes, but in that case the document must be changed. 17:42
jonathan pmichaud: If we can get that kind of consensus on it, then I think that's OK. 17:43
pmichaud I just know that every time I go to fix something relatively fundamental, lexical bugs keep getting in the way 17:44
jonathan As NotFound says, we should fix the design doc and patch that, and I think ahead of the code changes, so there's a clear spec.
pmichaud I'm not sure we can a-priori know that a particular design works, given our collective experience levels.
I'd rather tinker with an implementation until we get one that works, and then document that. 17:45
:lexid being a prime example
(because pdd20 makes absolutely _no_ mention or inkling that something like :lexid is needed)
jonathan OK, but let's at least try and get a consensus on what we can work out. 17:46
NotFound Maybe a good solution is: cd docs/pdds ; mv *.pod draft ; ;)
pmichaud right now I have a consensus of one that I like what I just proposed. :-)
jonathan I'll read your and bob's mailing list posts at the weekend and try and feed into this. 17:47
pmichaud I'm eagerly waiting to see what rgrjr has to offer
jonathan Yes, I think he has a good understanding of these things.
pmichaud the first part of my proposal doesn't seem radical at all
jonathan Certainly, he's done stuff in that area of the code.
pmichaud the second part is more radical (where outer subs maintain lists of their inner closures), but I can completely live without it if we just do the first part 17:48
17:48 Ivatar joined
pmichaud if we try to stick with the existing newclosure design, either as implemented or as documented in pdd20, then we have a _lot_ of other design changes we have to start making. Most notably we have to completely re-think multisubs 17:48
also, after I wrote what I did last night, it occurred to me that it seems to match very closely many of the statements about closures in S04 17:49
even down to the notion of "cloning closures" 17:50
jonathan Which part? The first part?
pmichaud the whole design
purl the whole design is sketchy as fuck.
pmichaud purl, what the hell do you know?!? 17:51
purl i don't know, pmichaud
pmichaud the basic concept is that inner closures have to capture their lexical environment at the time the outer sub is invoked
the first part provides us with an explicit way to do that
the second part provides a way to have Parrot do that automatically
jonathan pmichaud: "So, I propose that we add a "capture" method to Closure PMCs 17:52
to set the outer_ctx for that PMC."
So basically, it sets the outer_ctx of that closure to the current context?
pmichaud as well as checks that the current context is in fact the outer_sub 17:53
i.e., you can only capture from the outer sub itself.
(the check is optional, but probably useful)
17:53 jq joined
pmichaud invoking a closure then *never* performs a capture 17:54
because that capture must have been already done
jonathan Yes, we should do the check, for sanity and to prevent weird hard to find bugs!
pmichaud i.e., the invoke vtable for captures becomes trivial.
it checks for an outer context, throws an exception if one hasn't been set, otherwise it proceeds to do the sub 17:55
jonathan Right.
Hmm. Things could work.
*this
pmichaud if parrot doesn't implicitly set the outer context for all of its inner subs, then compilers (i.e., PCT) will have to generate code at the beginning of each sub to do it explicitly
I'd prefer not to generate that code, but will do it if need be 17:56
what I really like is that we can potentially eliminate 'newclosure' altogether
because we just clone the Closure after its outer context has been set (whether implicit or explicit)
jonathan Yes, I get that bit. 17:57
pmichaud and that matches exactly what is written in S04
jonathan Can you explain your statement starting "if parrot doesn't implicitly set the outer context" a bit more to me?
pmichaud ideally (assuming it works), when I invoke an outer_sub I'd like it to automatically do a capture for all of its inner closures
i.e., it iterates through all closures that have the sub listed as :outer, and sets the outer context directly 17:58
jonathan Ah, and *that* is why you want to know what all of the inner ones are...
pmichaud yes.
if we don't have that
then the code generator needs to do a lot of
$P0 = get_hll_global 'inner'
$P0.'capture'()
$P0 = get_hll_global 'inner2'
$P0.'capture'()
at the beginning of each outer sub 17:59
the code generator can fairly easily generate this, though, since it knows all of the inner subs
spinclad will this clobber existing closures of those inner subs?
pmichaud spinclad: uncloned ones, yes.
spinclad: but this is what rgrjr has been indicating needs to happen 18:00
18:01 slightlyoff joined, slightlyoff left
pmichaud note that this approach means that the example in dev.perl.org/perl6/doc/design/syn/S..._a_closure works naturally 18:01
because assignment makes a copy (clone)
18:04 uniejo joined
spinclad ok, need to read the thread. (rereading S04 section now) 18:04
pmichaud correct url is dev.perl.org/perl6/doc/design/syn/S..._a_closure
jonathan pmichaud: I suggest wait for feedback on what Bob says. 18:05
pmichaud I agree. :-)
jonathan If he agrees it's a good idea, maybe we create a branch and try this out.
pmichaud but if it works, this proposal seems much simpler and more straightforward than the existing implementation
jonathan The first part of the mail looks like it may well be easily workable. 18:06
The keeping a list of inners bit worries me.
pmichaud I agree
jonathan And this may not play too wonderfully with MMD right off.
pmichaud oh?
jonathan But I can likely fix that up.
Well, the problem is that what are you invoking .capture() on? 18:07
pmichaud oh.
jonathan You're doing a get_.*global
Which looks in the namespace, ands hands you make a MultiSub
Which you then will call .capture on.
pmichaud in the mail I actually did a .const 'Sub'
jonathan Hmm, OK. 18:08
But does that distinguish different multis?
pmichaud but yes, we'd need a way to get the explicit cub
er, sub
jonathan I'd be more inclined
(hmm...maybe, this may not make sense...)
To have .capture on a MultiSub go through the options, and any closures with an outer sub that matches that currently being executed get the outer context set. 18:09
Hmm...or would that break things...
pmichaud ooh, I think that would work wonderfully.
jonathan Yeah, but what if you update the outer of multiple variants?
pmichaud that's okay
jonathan OK
pmichaud because it would mean that all of those multiple variants are inner closures of the outer sub 18:10
jonathan I haven't convinced myself of that yet, but you've thought this through a lot more than I.
OK, that reasoning makes some sense to me.
pmichaud and so they all need to have captures taken
that's far better than what I was thinking 18:11
jonathan++
jonathan It's also the most natural.
pmichaud yes, very natural.
jonathan As in, the most natural from an implementation point of view.
pmichaud that's also what convinces me that this approach is pretty good -- things fall out naturally without a lot of funky stack or context manipulation (other than possibly the need to identify the inner closures)
jonathan OK, if Bob isn't disagreeable, let's try and get the first part of this implemented in a branch soon. 18:12
I'm still not convinced the second part will fly.
Certainly, holding a list of GC-able items without making sure they are marked, feels scary to me. 18:13
spinclad .oO { 'inner closures of outer sub' or '.. of outer closure (ie, call?)'? }
jonathan But if we need to do that, we can maybe work out another way.
pmichaud I may decide that I prefer having a method on outer subs that takes a list of inner closures and performs captures on each 18:14
i.e., outer.'make_captures'(inner1, inner2, inner3, ...)
dalek r29301 | julianalbo++ | trunk:
: Allow concat of utf8 and iso-8859-1 without icu
diff: www.parrotvm.org/svn/parrot/revision?rev=29301
pmichaud but either way works for me 18:15
if inner.'capture'() is implemented, it's trivially simple to create outer.'make_captures'(...) :-)
or even just '!make_captures'() since we can infer outer 18:16
jonathan If you know what outer's inners are...
pmichaud I'd still have to do the inner lookups, yes
I don't see a way around that, unless outer somehow has a way of automatically getting the list itself
jonathan OK, so you're saying if the first part of your proposal is implemented, then you've got enough to work with and it will unblock things? 18:19
pmichaud yes.
assuming it works. :-)
jonathan OK. That gives me some hope we might be able to resolve this soon.
pmichaud the only thing I'm not sure of is the :load/:init issue with lexicals, but I think I can work around that.
at least far enough to keep progress moving until the branch comes in. 18:20
jonathan OK.
So we have a plan from here to try and get lexicals/closures sorted out. 18:21
For HLL - are there tickets for the current issues you have with it? 18:22
18:23 jjore joined, julian_ joined
pmichaud (have to run for about 15-20 mins... bbiab) 18:24
yes, there are hll tickets. There's even a meta ticket.
jonathan OK, good.
I need to go for a bit too, to eat...back later
pmichaud meta ticket is #49812. current outstanding bug is #56650 18:33
Whiteknight++ was working on #56650, and there's information in the irc logs about how I proposed to fix it
dalek r29302 | Whiteknight++ | gsoc_pdd09: 18:34
: [gsoc_pdd09] Remove some unnecessary garbage and cruft that I added for debugging, for problems which have since been resolved.
diff: www.parrotvm.org/svn/parrot/revision?rev=29302
Whiteknight Yeah, I'm probably not going to be able to get a solid patch up and running for that until sunday night 18:36
pmichaud I may go ahead and do it if I do any work on p6object, then.
Whiteknight I'm knee-deep in this damned GC. I fix one segfault and expose two more! 18:37
pmichaud are there any blessed GCs?
or are all GCs inherently the spawn of the underworld? 18:38
Whiteknight i'm starting to wonder 18:41
18:50 uniejo joined
NotFound pmichaud: after my last commit related to #39930 I'm testing to delete the workaround mentioned in #50092 and all looks good. Wan't to look at it? 18:57
pmichaud if it works and tests pass, feel free to commit a fix for #50092. I'll review the commit and if I see anything wrong I'll fix/revert. 18:58
NotFound Ok, I go to commit when some more test finish. 18:59
19:00 purl joined
dalek r29303 | bernhard++ | trunk: 19:09
: [Pipp PCT] Avoid infinite loop for curly string interpolation,
: but break some tests.
diff: www.parrotvm.org/svn/parrot/revision?rev=29303
Tene ICFP contest just announced. 19:13
dalek r29304 | julianalbo++ | trunk: 19:19
: Deleted PCT grammar workaround, RT#50092
diff: www.parrotvm.org/svn/parrot/revision?rev=29304
jonathan returns 19:25
cotto-work icfp? 19:27
purl icfp is probably international conference on functional programming or at pauillac.inria.fr/pli/icfp/ or sponsoring a programming contest at www.cs.virginia.edu/~jks6b/icfp/ or (see:icfp2007)
19:29 davidfetter joined
dalek Jeff Horwitz | mod_parrot: 19:48
link: www.perlfoundation.org/parrot/index...mod_parrot
19:53 Zaba_ joined 19:55 uniejo joined
NotFound Whiteknight: ping 20:39
spinclad icfp2008?
dalek r29305 | coke++ | trunk: 20:41
: [punie] resolve RT#56670 with an explanatory comment
diff: www.parrotvm.org/svn/parrot/revision?rev=29305
cotto-work NotFound, is there any reason to keep RT#50092 open? 20:42
NotFound cotto-work: waiting for pmichaud take a look on it. 20:43
pmichaud it looks fine to me.
I think the ticket can be closed.
NotFound++
NotFound I will close both tickets, then.
20:44 Z2Z joined
cotto-work tickets-- 20:45
NotFound++
spinclad just include 'Closes: #56670' in the changelog, it will autoclose. oh, wait. this isn't debian, is it? never mind.
NotFound ++ for who added the blue box on the public interface 20:46
karma tickets 20:49
purl tickets has neutral karma
NotFound I'm wondering why the const_cstring_hash is not marked, and supposing there is no reason why it does not brokes horribly. 20:55
jonathan NotFound: I don't think constants can get collected. 20:57
opes
*can't* get collected
NotFound jonathan: but the headers are, it isn't? 20:58
Ah, no, I was confused. 20:59
jonathan pmichaud: Read Bob's message?
pmichaud yes. I'm confused. Or he is. 21:00
jonathan I need to think it over more.
pmichaud I'm writing a response now.
jonathan OK.
pmichaud I think he misinterpreted what I wrote.jA
NotFound And the hash itself is not an object, I see now. 21:01
jonathan I'm writing a crappy evil ASP.NET output filter to translate .png to .gif to work around IE6 being unable to handle alphas transparency in PNGs. For a site that's meant to go production at the weekend. *sigh*
pmichaud yes, IE is horrible. 21:02
Tene jonathan: have you looked at pngfix? a solution in javascript? 21:03
homepage.ntlworld.com/bobosola/
pmichaud although, I'm a little tired of Bob writing things like "I would remove all use of autoclose from PCT and Rakudo, replacing it with a general solution" when he doesn't even tell me what the "general solution" is. 21:07
jonathan Tene: I looked at SuperSleight, which is a JavaScript solution also. It didn't help so much. And looking at pngfix, it's trying the same trick.
21:07 pac1 joined
pmichaud that's all I'm asking for -- "what's the damn general solution?" 21:07
particle the gloves are off!
the texan is mad!
jonathan Tene: But thanks the suggesting. :-) 21:08
particle quick... where's the dr pepper and doritos?
pmichaud: sorry i haven't paid close enough attention to help you more with that closure problem 21:09
pmichaud All I have been doing from the beginning is trying to get PCT and Rakudo to work with a general solution. I have no idea if I'm using autoclose or not -- that word means next-to-nothing to me. I'm just trying to follow the stupid documentation (which is wrong) or ask folks to tell me what the compiler is supposed to be generating so that things will work.
I'm just writing to write standard PIR code that makes lexicals work, and nothing I try works.
and the solution he offers also doesn't work. 21:10
(for multisubs)
particle mmd is yet to be redesigned
'course that doesn't help you today 21:11
jonathan particle: Huh? The spec isn't marked draft any more.
pmichaud or this month. or likely this summer at the rate things are being done.
21:12 donaldh joined
particle jonathan: but the implementation isn't done 21:12
cotto-work best line of code EVAR
#include <shellapi.h></shellapi.h>
Tene laughs.
editor autocompletion gone wrong?
cotto-work: where's that from?
cotto-work forums.thedailywtf.com/forums/p/924...spx#172728 21:13
jonathan particle: Last time I read the PDD, I found it vague enough that it seemed too incomplete to implement. And I posted some issues I had with the draft on the mailing list, and I don't think any of them were addressed in the final. 21:14
The useful bit in there is that you can subclass the MultiSub PMC to get your language's semantics. Which is what I will do for Rakudo. 21:16
But it doesn't state the standard multiple dispatch algorithm for Parrot, etc.
...let alone does it mention anything about closures and multis... 21:18
pmichaud and based on what Bob Rogers is saying in his thread, the idea that we can have a single symbol pointing to a MultiSub PMC is itself a problem. 21:24
because there's not a way to replace that symbol with the result of a newclosure
so, we have to have a MultiSub PMC that allows us to replace a specific entry with a newclosured one 21:25
which means we need a way to *locate* that specific entry so that it can be replaced
all of which says (to me) that for a vm that is supposed to make dynamic languages easier to implement, Parrot spectacularly fails at this aspect of it. 21:26
if Parrot's defaults can't handle standard closures and lexicals without HLL compilers having to go through a lot of hoops and symbol table manipulations to make it work, then it's really b0rken.
NotFound I fail to understand why a closure has to be treated like a stand-alone function. Is not an already binded thing? 21:27
jonathan pmichaud: If we make newclosure a method, then it can be implemented on MultiSub, just the way I specified for Capture (which maybe from what Bob says won't work), but replacing the entries that match. 21:28
Or the newclosure op changes to recognize multis.
pmichaud "replacing the entries that match" sounds very tricky. 21:29
I suppose one could determine "match" from lexid
jonathan That match = that have an outer that is the current sub.
Just as for newclosure on one closure.
(If we want to forbid calling newclosure when not in the outer) 21:30
pmichaud I don't think the problem that bob is referring to has to do with calling newclosure when not in outer
jonathan No. 21:31
jonathan thinks
pmichaud Bob's recommended solution to the closure issue is to do
.const 'Sub' inner_sub = 'inner_sub'
$P0 = new_closure inner_sub
set_global 'inner', $P0
....and then later
'inner'() # invoke inner sub
....so, each time the outer sub is invoked, we do a newclosure of inner_sub and store that in the namespace as 'inner' 21:33
(of course, if the inner_sub happens to be a method, then we need to replace a method)
NotFound pmichaud: What is the problem with that approach? Too much code? 21:34
pmichaud (and if the inner_sub happens to be a :multi, we have to make sure that 'inner' refers to a MultiSub and then replace whatever MultiSub (if any) was there from the previous invocation of outersub with the newly created closure)
jonathan Replacing a method would imply replacing it in the class vtable! 21:35
That *can't* be the right thing to do.
pmichaud I totally agree. But since methods are lexical as well, I can certainly come up with an example that uses methods instead of strict sub calls.
and so whatever we do for subs we'd have to do for methods
and thus my frustration that he keeps saying "use a general solution" but doesn't give one that is at all workable in Parrot. 21:36
NotFound What is the reason to have to store the closure in a global named var?
pmichaud NotFound: I'll no paste an example
21:39 jan joined
nopaste "pmichaud" at 76.183.97.54 pasted "example of global symbol table" (7 lines) at nopaste.snit.ch/13562 21:39
jonathan pmichaud: I think S04 is helpful where it says, "In particular, named subroutines in any scope do not consider themselves closures unless you take a reference to them." 21:40
pmichaud I pointed that out to Bob in an earlier message, yes. I have no clue what that exactly means.
jonathan And in that case, newclosure - the clone - is what the reference becomes.
pmichaud yes, that's what I had been thinking, but apparently Bob disagrees. 21:41
jonathan Ah, OK. I *think* I understand it...let me just make sure, before I confuse things more...
pmichaud NotFound: in my example, foo() is a global sub
(actually, global to the namespace -- a package-scoped sub)
NotFound pmichaud: Is global, or is scoped in the enclosing block? 21:42
pmichaud NotFound: the symbol itself is global
'sub foo' is equivalent to 'our sub foo' 21:43
if we wanted to limit it to the enclosing block, it would be 'my sub foo'
NotFound pmichaud: ok, but that applies to the sub, not the closure taken, it isn't?
pmichaud if we take a closure and expect 'foo()' to find it, then that closure has to be stored in the symbol table under 'foo' 21:44
jonathan pmichaud: I think what S04 is saying is that the only type a named sub needs to be newclosure'd, is if a reference is made to it. 21:45
only *time*
pmichaud jonathan: that's what I thought S04 was saying as well.
let me rephrase
when I read S04, that's what I think it's saying as well. 21:46
jonathan And that means that the result of the clone is _not_ replacing anything in the symbol table. Instead, it's what you get if you write &sub.
pmichaud agreed
NotFound That looks the reasonable thing to me.
jonathan Now, if it's an immediate block *that you're taking a reference to*, it always needs to be newclosure'd. 21:47
pmichaud and that's why I think I shouldn't have to be doing newclosure at all for the Perl 6 examples I've been doing
jonathan Note: taking a reference to. *not* invoking.
I wonder if that is the confusion here.
NotFound But that reference has to be taken inside the block, to have a correct context, I suppose. 21:48
jonathan Now it's just considering what happens under recursion.
pmichaud btw, I think that the existing implementation of newclosure is suspect, also. 21:49
I was very surprised to see how it's implemented
dalek r29306 | fperrad++ | trunk: 21:50
: [Pipp] doc
: - fix some links to PHP reference manual
diff: www.parrotvm.org/svn/parrot/revision?rev=29306
jonathan .sub 'foo' $P0 = whocares() .lex '$a', $P0 bar()
.end
.sub 'bar' :outer('foo') find_lex '$a' bar()
.endGrr
...wow, no newlines
pmichaud hint: nopaste :-)
jonathan Yeah, I wanted to have it in front of me while I talked about it!
NotFound .endGrr ? Nice way to end rant comments X-) 21:51
nopaste "jonathan" at 85.216.151.226 pasted "example" (9 lines) at nopaste.snit.ch/13563
dalek r29307 | fperrad++ | trunk:
: [install]
: - fix lolcode test
diff: www.parrotvm.org/svn/parrot/revision?rev=29307
jonathan In this case, when we invoke bar the first time, from foo, we want bar to capture (have it's outer set to) foo's current outer context. 21:52
I guess a call on bar.capture() inside bar would then want to be a no-op, since the outer hasn't changed 21:53
Or would you have not been emitting a capture there?
pmichaud we would never call bar.capture there
we call capture from the _outer_ sub.
jonathan Right.
So we'd just never emit it.
So that recursive example works with your scheme.
pmichaud all invocations of bar would end up using the same foo as an outer context
jonathan Right. Which is, I believe, correct.
nopaste "pmichaud" at 76.183.97.54 pasted "lexicals and recursion" (5 lines) at nopaste.snit.ch/13564 21:56
21:57 shamu joined
pmichaud 13564 is a more interesting recursive example 21:57
(that I gave in the mail thread)
jonathan I think the key thing in Bob's example is here 22:00
my $recur = sub {
Note - he takes a reference to an (anonymous) sub
NotFound pmichaud: but following the rule of taken a reference, it's still not a closure. 22:01
jonathan That captures the current outer - the clone of the way things are now.
And that's the point of the newclosure.
pmichaud so, you're saying his example actually works under my proposal?
or...?
I don't immediately understand his example. 22:02
jonathan I'm saying that if we are doing what you suggest *and* we are doing newclosure when a reference is taken to a block/sub (anything that compiles down to a .sub in Parrot), then yes.
Or at least, I think so.
pmichaud I already mentioned that 'newclosure' is effectively a clone.
jonathan nod 22:03
pmichaud and that assignment takes a clone
NotFound I don't know perl6 rules, but looks logical to me.
pmichaud (since assignment copies its rhs anyway)
NotFound pmichaud: it takes a sub and returns a closure, it isn't? 22:04
jonathan pmichaud: At this point, since we both think this may work, I wonder if it's worth us just making a branch, implementing your suggestion, along with making sure we put newclosure in the right place (when a sub/block gets referenced), then translating Bob's example to Perl 6 to actually try it... 22:06
22:06 pac1 left
pmichaud I'd rather see it translated to PIR, personally. 22:06
even a hand translation
NotFound But if is as you say in the thread just a synonym to call capture on the sub, the only reason for his existence is as optimization, I think.
pmichaud if you're correct, then my guess is that Bob doesn't recognize that my $recur = sub { ... } results in a newclosure
(or a clone) 22:07
jonathan pmichaud: working on it
(hand translation)
NotFound pmichaud: at pir level the anonymous is still anonymous, or must have a name assigned? 22:08
pmichaud NotFound: it has an internal name
but that name doesn't really mean anything, and we can even keep it from appearing in the symbol table
NotFound pmichaud: then I think it must be the same than a named one.
That is, taken a new closure on it at usage. 22:09
pmichaud jonathan: if you really need to be doing your $otherjob stuff, this can wait.
NotFound Maybe the problem is that Bob thinks that the sub is already a closure, not a sub. 22:10
jonathan Meh, $otherjob already got over 8 hours of me today
And I'll be doing stuff for them at the weekend.
pmichaud notfound: in Parrot, any sub that accesses its outer lexical context is a Closure PMC
in effect, all nested subs are Closure PMCs
er, all nested blocks are Closure PMCs 22:11
jonathan If I wasn't doing this I'd only be drinking beer and looking at lolcats...
pmichaud jonathan: okay, just wanted to let you know my sense of priority/urgency.
NotFound pmichaud: but that is at execution, not at declaration, I suppose.
pmichaud NotFound: no, it's at declaration in PIR
a nested block in PIR has an :outer(...) flag. That causes it to be created as a Closure PMC instead of a Sub PMC 22:12
of course, when the Closure PMC is created this way it doesn't have an outer context -- i.e., it hasn't captured its lexical environment yet
NotFound Mmmmm.... So a declared and an active one are the same type of object?
pmichaud so the discussion centers around "when does the inner closure captures its lexical environment?" 22:13
Closure PMC and Sub PMC really differ only in type
(and the implementation of invoke/freeze/thaw/etc.)
and the fact that a Closure PMC has a value for outer_sub 22:14
(outer_sub is NULL in a Sub PMC)
22:15 paco joined 22:16 paco left
jonathan I'm really glad we have compilers, because translating HLL code to PIR gets really tedious... 22:17
pmichaud well, I don't think it needs to be a literal translation -- just enough to show the same thread of execution
I'm going ahead and sending a message pointing out the my $recur = sub point, and then I'm done for the evening (dinner here and need to spend time with kids) 22:18
jonathan OK, 2 mins and I have a translation.
pmichaud Feel free to add it as a response to my previous message. :-)
NotFound Looks to me, according that explanation, that the problem is to distinguish between the static closure and the dinamic one. 22:19
pmichaud I'll look at the translation a bit later tonight
gotta run
NotFound If you don't make the newclosure thing, you don't have the dynamic context stored on it. 22:20
22:20 paco joined 22:24 teknomunk joined 22:48 kid51 joined
jonathan has got Bob's example to work in PIR by just taking newclosure whenever a reference is taken to a block. 22:52
NotFound I think I'm starting to understand... When calling directly, the context is taken directly by the current one. When taking the reference, is captured by the newclosure operation for later usage. 22:57
If that is correct, maybe having two different types will make things clearer. 22:58
dalek r29308 | jkeenan++ | parallel: 23:02
: P::C::Base, P::C::Parallel: YAGNI. No need for parallel object at this time,
: as two wrappers around Storable functions will suffice. Eliminate one test
: file whose tests have been moved to another file.
diff: www.parrotvm.org/svn/parrot/revision?rev=29308
r29309 | julianalbo++ | trunk:
: Reanme disassemble to pbc_disassemble by Reini Urban, RT#56542
diff: www.parrotvm.org/svn/parrot/revision?rev=29309
NotFound Nice typo. 23:04
jonathan Nah...nice typos are the ones that accidentally lead to rude words. :-) 23:13
NotFound: See my post to the list, which I hope helps clear things up a bit.
dalek r29310 | jkeenan++ | parallel: 23:15
: Consolidate multiple test files per configuration step into a single file.
diff: www.parrotvm.org/svn/parrot/revision?rev=29310
NotFound jonathan: yes, that confirms whay I was starting to understand. 23:17
$P0 = find_global 'anon_1' | $P1 = newclosure $P0 23:18
Maybe a help from the parrot side to the hll writers can be to make an operation that combines those two. 23:19
jonathan I'd rather leave it as two. You might not be doing find_global. 23:21
find_hll_global and all manner of other things are possible. 23:22
NotFound We can just expect to see what the more frequent usage will be, an then maybe add an operation to shorten it. 23:24
tewk is up over his eyebrows in parrot calling convention innards (src/inter_call.c) 23:26
I used to know this stuff by heart, two years later and I can't remember a thing. 23:27
jonathan tewk: I looked in there just a couple of days ago and...hate.
I'm sure I saw stuff like src.sig.sig->c[0].... 23:28
NotFound tewk: that's a clear sign of too complex code.
Well, not, the sign is clear when is just two monts X-) 23:29
jonathan tewk: You are working on the GSoC project doing NCI things, right?
tewk Well I think I got enough of it back in my head now.
Yeah I'm getting ready to jit nci calls, it really isn't going to be that bad. I just have to call a bunch of functions in assembly (src/jit_emit.h:build_call) 23:31
NotFound The jit is also a less than ideal example of clean code X-)
purl okay, NotFound.
NotFound jit? 23:32
purl jit is a Just In Time compiler. Or just more Java hype. or new Parrot hype! or a less than ideal example of clean code X-)
tewk the current Parrot_jit_build_call_func is at least 2 or 3 refactors out of date. 23:33
jonathan tewk: pmichaud and I were pondering changes to inter_call.c - I guess touching it now would be disruptive to what you are doing? 23:34
tewk NotFound: inter_call.c makes all the cool calling convention stuff work.
NotFound tewk: for some values of 'all'
tewk You should have seen inter_call.c two years ago. I did a major refactor to get it to look as good as it does. Chromatic has cleaned it up quite a bit more too. 23:37
jonathan: I'm not changing anything, just remembering how it works.
There are a lot of helper functions, and I'm just going to use those. 23:38
NotFound tewk: I don't say that is all bad, but is very hard to diagnose the known bugs.
tewk I know what you mean, I always say to my self that it doesn't need to be that complex. 23:39
But once I remember all the things it does, its hard to reduce the complexity. 23:40
It does boxing, unboxing, INSP conversion, slurpy, named, flat, NCI, PCCMETHOD, I just need a few more acronyms :) 23:42
jonathan: what were you goint to change, the optional vs named stuff? 23:43
jonathan Apparently there are some changes too. 23:48
Or maybe they are optional vs named related. I'm not completely sure.
I haven't been thinking about it much, pmichaud just mentioned it was something that needed doing. 23:49
And both of us find that chunk of the codebase more than a little hard to get into.
dalek r29311 | jkeenan++ | parallel: 23:52
: [configure] Refactor code from within runstep() into _handle_exec_protect(),
: then test it.
diff: www.parrotvm.org/svn/parrot/revision?rev=29311
kid51 Oooh, that last commit message was wrong. 23:54
dalek r29312 | jkeenan++ | parallel: 23:56
: Consolidate multiple test files per configuration step into a single file.
diff: www.parrotvm.org/svn/parrot/revision?rev=29312

Powered by Cro and the Raku® Programming Language.

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

Thank you!