Parrot 3.8.0 "Magrathea" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 21 September 2011.
dalek kudo/optimizer: fa826a0 | jnthn++ | src/binder/multidispatch.c:
Greatly weaken the 'could never work' analysis - the initial version was wrong. Add a note about how we probably can catch a bunch of obvious cases.
 00:45
kudo/optimizer: 055835c | jnthn++ | src/ (2 files):
Start to do the compile time multi-dispatch analysis. At the moment, we don't actually use the 'I identified the candidate' result, but there's a stub for doing so. We do complain about dispatches that are identified as impossible though, with the result that a bunch of spectests that checked things like '&end requires an argument' now fail to compile.
00:56 woosley joined 01:12 davidfetter_ joined 01:20 jkitazawa joined
cotto dukeleto, ping 01:39
02:01 cottoo joined 02:09 jeffreykegler joined 02:11 jeffreykegler left 02:31 alvis joined 03:24 rfw joined
cotto seen dukeleto 03:52
aloha dukeleto was last seen in #perl6 2 days ago joining the channel.
06:21 nbrown joined
dalek kudo/nom: ca5f34b | Coke++ | t/spectest.data:
run fudged test!
 06:53
07:14 mj41 joined 07:34 SHODAN joined 07:40 aloha joined 08:03 lucian joined 08:18 contingencyplan joined
dalek kudo/nom: c5fc397 | moritz++ | src/core/Buf.pm:
[Buf] <=> should really be cmp, TimToady++
 09:31
09:43 dod joined 09:44 bacek_at_work joined 09:52 lucian joined 09:58 woosley left 10:08 particle1 joined 10:15 arnsholt joined 11:09 woosley joined 11:13 arnsholt joined
dalek rrot/mls/pct_exceptionhandlers: ddab786 | mls++ | compilers/pct/src/PAST/Node.pir:
move handle_types/handle_types_except from PAST::Control to PAST::Node

This is done for two reasons:
  - allow 'try' pirtype node to generate specialized exception handlers
  - allow to have PAST::Stmts nodes as block handlers		 11:20
rrot/mls/pct_exceptionhandlers: a44e056 | mls++ | compilers/pct/src/PAST/Compiler.pir:
refactor exception handler setup into a push_exception_handler function, change pirop=try nodes to use it
rrot/mls/pct_exceptionhandlers: 03a775d | mls++ | compilers/pct/src/PAST/Compiler.pir:
change pirop=try to work more like pirop=if regarding the return value

The old code return an unspecific value if an exception was caught.
11:32 preflex_ joined 11:35 plobsing joined 11:36 Psyche^ joined 11:49 lucian joined 12:00 bluescreen joined 12:10 whiteknight joined
whiteknight good morning, #parrot 12:10
nine good morngin whiteknight 12:11
Felipe good morning 12:13
atrodo =~ 12:22
dalek kudo/nom: bfc3a42 | moritz++ | src/core/Rat.pm:
BUILD should be a submethod
 12:23
kudo/nom: 00c8180 | moritz++ | src/core/Buf.pm:
fix Buf thinko; fixes .[] indexing into Buf
12:30 lucian joined
whiteknight hello nine, Felipe, atrodo. How are you all doing today? 12:34
nine whiteknight: looking forward to start fixing tests, now that green_threads builds :) 12:39
whiteknight oh, it builds? What was the problem?
nine whiteknight: I have no idea :)
whiteknight: did the only thing I could do: ignore the problem and continue with merging the current master including kill_threads. After that the error disappeared. 12:40
whiteknight works for me
12:51 plobsing joined
dalek kudo/nom: 530c04f | moritz++ | t/spectest.data:
run new S06-signature/unpack-object.t
 12:56
13:10 alvis joined
dalek kudo/nom: 1108715 | moritz++ | t/spectest.data:
run new test type-object.t
 13:23
13:26 arnsholt joined 13:51 PacoLinux_ joined
dalek kudo/nom: 6551282 | moritz++ | src/core/Mu.pm:
in .* dispatch, do not turn all method calls into calls on the type object
 13:53
kudo/nom: fce1d9b | moritz++ | t/spectest.data:
run calling_sets.t
 14:14
14:37 slavorgn joined
dalek kudo/nom: ef6536f | moritz++ | t/spectest.data:
run S06-multi/proto.t
 14:38
mls seen tene 14:58
aloha tene was last seen in #perl6 20 hours 16 mins ago saying "MAIN vs LOAD or something".
15:19 alester joined
dalek kudo/nom: 16cb2b6 | moritz++ | src/core/Parameter.pm:
return Perl 6 strings from Parameter.named_names, japhb_++
 16:18
mls anybody here that has time to look at the mls/pct_exceptionhandlers branch? 16:42
whiteknight mls: in a little bit. What does the branch do? 16:44
mls it generalizes exception handling in PCT a bit 16:45
it's just three commits to look at
whiteknight okay. I'll take a look at it in a bit 16:49
mls thanks!
16:57 PacoLinux joined 17:06 dmalcolm joined
mls whiteknight: I've to leave now, so take your time. talk to you tomorrow... 17:11
whiteknight okay, thanks
mls afk -> home
17:21 nbrown joined 17:34 dodathome joined 17:45 fperrad joined
nine whiteknight: did anyone do any benchmarks before and after kill_threads? Would be interesting if removing the locking calls improved things 17:49
whiteknight nine: locking has been removed for months. Maybe years 17:53
Most of the functionality of threading has been removed over time. What was left before kill_threads was a hollow shell
the performance impacts are negligible. One or two API calls on startup, a few API calls on certain thread-related PMC methods, etc 17:54
nine ah ok
17:55 jeffreykegler joined
whiteknight yeah, so when I say I removed threads, I really mean I stopped pretending that we used to have them 17:55
according to the old deprecation policy, we had to continue pretending for several months, so people could update other imaginary software to stop pretending to use it 17:57
17:58 benabik joined
benabik o/ 17:59
nine sounds horribly efficient ;)
whiteknight what I would like to do is have a system that doesn't require active imagination to use 18:00
benabik I like to imagine we have a more sensible lexical system. I'll get around to that someday. 18:02
whiteknight it has gotten much better with the addition of native types recently 18:03
it has much more ground to cover
benabik Scopes need to not be linked 1:1 to subs. We need a hint based lookup ($I0 = get_lex_hint 'foo' ; $P0 = get_lex $I0) to avoid string comparisons... 18:04
Those are my primary concerns ATM.
whiteknight scopes aren't linked 1:1 to subs in the case of tailcalls
of course, the scope gets very well recycled
benabik I want a nested scope inside a sub.
whiteknight I'm not sure I understand that 18:05
benabik int x; while (x) { int y; } should not require a sub for inside the while loop.
whiteknight benabik: that's a design decision of NQP. Winxed doesn't do it that way 18:06
so it's not a fundamental limitation of parrot
benabik How do you remove y from the lexpad at the end of the loop?
whiteknight it's not in the lexpad in the first place
benabik Assuming x and y are lexical.
whiteknight they just get mapped to different registers in the current lexpad 18:07
the compiler makes sure we don't try to access variables in the wrong places. Compile time checks instead of runtime checks
benabik Yes, but y should not be accessible outside the loop. So it would have to be removed.
whiteknight no, the compiler just doesn't emit code that can access it
benabik And if it was int x; { int x; }, we need to shadow and restore x. 18:08
whiteknight no, the two of them get mapped to different registers
and it's a bad idea to shadow anyway
C# disallows that, and I think that's a fantastic idea
benabik *sigh*
It's not invalid. It's defiantly not invalid for all HLLs we might want to run. 18:09
And not removing it from the lexpad means it might happen to get accessed by closures or other strange lookups.
whiteknight only if that closure has code emitted to look it up
if you emit code to access storage that is out of bounds, you get the results
benabik Arbitrary code written in possibly other languages?
What if I do { my $*BLOCK; } func(); in NQP and $*BLOCK is looked up in func? 18:10
whiteknight so you're saying that the other HLLs would do absolutely zero analysis about the lifespan of variables, and will emit any sorts of random code in all sorts of weird situations, and Parrot should somehow work around that in an intellegent way?
benabik NQP currently has to create a new sub because of that case and I don't think it makes sense to make it has to.
whiteknight I don't think NQP has to. I think that was a design decision 18:11
I think you could make an NQP compiler which didn't do that
benabik Because it stores all its variables in our lexpads.
And you can't do that with our lexpads.
(AFAICT)
whiteknight right, but the code to access those variables has to be generated, and doesn't have to be
benabik Nested scopes are _commmon_ and should be easy.
whiteknight right. In winxed they are easy 18:12
benabik Because winxed doesn't use lexicals by default.
whiteknight NQP has made certain decisions, and those decisions don't need to be copied by other languages
benabik We have these lovely lexical lookup ops that _can't_ match all language semantics. 18:13
sorear you're calling our lexical lookup ops "lovely"??!?
benabik Being able to create a inner lexpad shouldn't be difficult and would allow people to do these things.
sorear: In concept.
whiteknight benabik: sure, that's a solution, and something like it will probably be necessary to cover edge cases in some languages 18:14
but in the vast majority of code examples, that functionality won't be necessary or even preferred
benabik whiteknight: It would help NQP/Rakudo today, I think.
It would simplify code gen.
whiteknight sure, but even a rudimentary optimizer could simplify further 18:15
benabik Nested lexical scopes _require_ nested subs today. I just want to change that.
whiteknight if you don't shadow variable names, you don't even need a second lexpad
benabik whiteknight: So HLLs can't shadow variables unless scope == sub? :-P
(Why is it that I end up in arguments whenever I mention lexicals?) 18:16
whiteknight right now, no. But again, you could cut out a hell of a lot of subs if you recognize that the subs don't contain shadowed variable names
I'm saying that your proposal works fine, but I don't think it's the best improvement we could make
an optimizer that recognizes when certain scopes can be inlined would likely be much better for most code 18:17
benabik Optimizers are all well and good, but requiring them isn't.
whiteknight what we're talking about here is an optimization, making existing code run faster
benabik I just want the lexical lookups to match the concept of lexical scopes.
So HLL sub == sub, HLL scope = lexpad. 18:18
whiteknight yes, I'm saying that's a fine and good idea
benabik I'm not talking optimization, I'm talking conceptual matching.
whiteknight I don't suspect breaking the Sub implementation up from the LexPad would be too time intensive 18:19
and adding in two new ops to push/pop lexpads wouldn't be too hard. Getting them to play nicely through exception handlers etc might be 18:20
throwing an exception would need to unwind the lexpad stack, etc
benabik If current lexpad is attached to continuation, not really.
And I'd like to do that and a hint system where Lexpads cache lookups and can provide integer indexes for speed. 18:21
whiteknight adding integer hinting would probably be very easy to do, and would likely have a nice optimization effect
actually, that might be a little bit tricky, because you would need a map somewhere to show which scope the lexical was in, and what register number from that scope 18:23
you could break up a 32-bit integer so the first 16 bits would be the scope number, the next 14 would be the register number, and the last two would be the register set 18:24
benabik I'd probably try to make it pointer based or something. index into a pointed to register set. *handwaves* 18:25
whiteknight then when you're looking up the value, loop up X scopes, find register set Z, and store value in slot Y, no questions asked
benabik whiteknight: That's the general idea. Exact data in cache is whatever it needs to be.
whiteknight benabik: sure, that works too, so long as sizeof(INTVAL) == sizeof(opcode_t*)
If we go that route, we need to start making that relationship more formal 18:26
benabik No, I'd keep a cache of looked up things. Lexpad has an array of things looked up.
I dislike accepting integers that mean funny things from users.
18:26 mj41 joined
whiteknight there's a difference between code entered by joe-schmoe user and a well-tested code generator 18:27
benabik Yes, well... 18:28
Assembly tends to get hand-written somewhere. :-D
I also dislike packing things into magic numbers unless I have to. 18:29
18:34 jeffreykegler joined 18:42 zby_home joined 19:03 contingencyplan joined
whiteknight I've hand-written assembly before. Very very few bits of it and in very very few occasions. Trust me, we don't need to make a system that expects users will be writing anything in assembly 19:07
most users will revolt if it's even occasionally necessary 19:08
19:10 jeffreykegler joined 19:46 bluescreen joined 20:03 ambs joined 20:04 perlite joined 20:15 soh_cah_toa joined 21:08 soh_cah_toa_ joined
dalek kudo/nom: 570bc95 | jnthn++ | src/core/Routine.pm:
Make Routine.candidates_matching work on only routines as well as multis for japhb++.
 21:23
kudo/nom: 870306b | jnthn++ | src/Perl6/Actions.pm:
Don't create a thunk that does a smart match for literal value constraints; the binder simply calls .ACCEPTS anyway, so we can just use the literal. Faster, and introspects better.
 21:41
kudo/nom: 3e8911a | jnthn++ | src/core/Parameter.pm:
Implement Parameter.constraints; fix NPMCA in Parameter.named_names.
21:59 bluescreen joined
cotto_work PHP's testing culture makes me sad. 21:59
benabik … PHP's testing culture?
cotto_work It's just what you'd expect.
except that it exists 22:00
tadzik they go full hardcore
as in "THE FAIL CANNOT STOP ME FROM RELEASE"
dalek kudo/optimizer: d34c4e3 | jnthn++ | src/pmc/mdthunk.pmc:
Set flag to make sure that inlined protos don't end up with us re-running type checks.
 22:02
22:21 not_gerd joined
not_gerd hello, #parrot 22:21
benabik o/ NotFound 22:22
o/ not_gerd, too. :-/
not_gerd on a Parrot with 32-bit integers, do you need to go through FFI for 64-bit arithmetics? 22:33
benabik Haven't tried it myself, but I'd imagine so.
cotto_work hio not_gerd 22:34
not_gerd hello, cotto_work
benabik Because the I registers will be 32b wide, and we don't support anything like $I0, $I1 = add $I2, $I3, $I4, $I5. I suppose we could extend the Integer PMC to support it, but blah. 22:35
cotto_work That's out of scope for a generic Integer class.
benabik Yeah.
sized_int dynpmcs… Byte, Int16, Int64, etc etc etc 22:36
But that's no less obnoxious than FFI, I think.
cotto_work not_gerd: Do I understand correctly that the big value proposition of M0+/- fast translation to something low-level? 22:37
not_gerd cotto_work: the general idea is that there should be an intermediate representation of higher level than any target instruction sets and a low-level representation for interpretation 22:42
dalek rrot: 4388681 | soh_cah_toa++ | tools/dev/pbc_to_exe.pir:
In pbc_to_exe, casted 'bytecode_size' argument to Parrot_api_load_bytecode_bytes() as a Parrot_Int since that's what it expects.
 22:43
cotto_work not_gerd: would the translation between m0+ and m0- require a register allocator? 22:44
not_gerd cotto_work: not the way I've implemented it 22:46
cotto_work Interesting. How does that work?
not_gerd m0+ registers reside in memory, and m0- just loads/stores the values
cotto_work Won't that be expensive?
not_gerd a JIT should probably have to do its own allocation
cotto_work: on x86, you need to round-trip to memory anyway because there just aren't enough general-purpose registers available, especially if you use 64bit integers... 22:53
m0- as the lowest common denominator can't really do any better than that 22:55
what you can do during the tranlation m0+ -> m0- are peephole optimizations, eg keep immediately re-used values around instead of reloading from meory 22:56
cotto_work that's true 22:57
not_gerd perhaps relevant: that's what the m0- interpreter (or at least the implemented part) looks like on x86 on the refactor branch: gist.github.com/1243575 22:59
there are 8 m0- registers, and there's already some spilling 23:00
23:00 whiteknight joined
soh_cah_toa looks like i missed something. what's m0+ and m0-? 23:00
not_gerd however, it's far better than what the master branch generates
cotto_work soh_cah_toa: gerdr.github.com/on-parrot/rethinking-m0.html
not_gerd soh_cah_toa: and github.com/gerdr/m0-pm 23:01
soh_cah_toa interesting...
not_gerd soh_cah_toa: there's a lot of handwaving in that article, and what I'm actually implementing is slightly different from that 23:02
soh_cah_toa ok
i like this :) 23:03
dalek rrot/whiteknight/gc_precise: fc619a6 | Whiteknight++ | / (4 files):
Add in the naive basics of GC anchoring for precise GC
rrot/whiteknight/gc_precise: a2f669b | Whiteknight++ | / (2 files):
Add in a header flag for whether we turn on the precise GC or not.
rrot/whiteknight/gc_precise: 117bd2e | Whiteknight++ | / (3 files):
Add in support for anchoring strings. Parrot builds and runs fine in GC_USE_PRECISE modes 0 and 1
rrot/whiteknight/gc_precise: add0f24 | Whiteknight++ | / (2 files):
In GC_USE_PRECISE==1, print out some debug messages in trace_system_areas when we find an unanchored PMC or STRING. We can use that output to help narrow down occurances.
whiteknight msg plobsing checkout the whiteknight/gc_precise branch. I need to redo the macros because I am not happy with them, but it's a start
aloha OK. I'll deliver the message.
not_gerd soh_cah_toa: some more comments on m0+/-: github.com/gerdr/on-parrot/commit/9940dce7 23:05
soh_cah_toa ok
sorear wonders how a generational imprecise GC is even possible 23:06
whiteknight sorear: stackwalking 23:07
basically differentiated by how we find the root set. Either we know where the pointers are, or we don't know
right now we don't know, so we have src/gc/system.c. 23:08
dalek kudo/optimizer: f910191 | jnthn++ | / (3 files):
Infrastructure to support calling a multi candidate determined at compile time, and not repeating arg type checks.
kudo/optimizer: 031a827 | jnthn++ | src/ops/perl6.ops:
Write barriers.
whiteknight and to keep that file sane, we need plenty of garlic and holy water
kudo/optimizer: f9d86d1 | jnthn++ | src/Perl6/ (2 files):
First cut of just calling straight to a multi candidate picked at compile, and skipping any bind-time type checks (since we know they aren't needed). Note that it finds barely anything at compile time yet, probably since we hardly have any type information in the tree.
23:16 jeffreykegler joined
dalek p: b9715f1 | jnthn++ | src/PAST/SixModelPASTExtensions.pir:
Enable us to set :type(...) on any PAST node, not just PAST::Var.
 23:29
kudo/optimizer: ad5f98c | jnthn++ | src/Perl6/SymbolTable.pm:
Flag various literals as being able to dispatch as native types (which calls back to their boxed forms); spots a few more things. S06-multi/lexical-multis.t falls victim to a 'could never work' detected at compile time.
 23:30
rrot/whiteknight/gc_precise: 4e40dc3 | Whiteknight++ | / (2 files):
Add in a new macro which I think looks prettier. Several fixes. Convert two functions in namespace.c to use the new system, even if they aren't good, representative functions to have converted.
 23:41
23:41 p6eval joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!