The Perl 6 design team met by phone on 03 June 2009. Larry, Allison,
Patrick, and chromatic attended.
Larry:
- a radix-based number with bad digits fails now, instead of silently producing the wrong answer
Patrick:
- returns a Failure at runtime?
Larry:
- at runtime, if it's not knowable at compile-time
- playing with declarators
need and define, what use uses
need just pulls in modules- changed the spelling of "MONKEY_PATCHING" to "MONKEY_TYPING" because it spells funnier
Patrick:
- is that what we get when we end up with the results of Shakespeare?
Larry:
- that's why it's funny
- MONKEY_TYPING you end up with random results
- worked on the semantics of
$!
- documented how action tags work with sharp equals
- refactored viv's action routines for operator precedence reduction
- the opp reduces things and rearranges nodes
- has to get those right to allow correct translation down the road
- STD now disallows the parenthesized form of rand as a term
- don't want people thinking of it that way
use v6 now allows a version number- unified the trait mod categories
- switched my cursor5 implementation
- now implements actions as specified, converging with Rakudo which is a good thing
Patrick:
- it's been an interesting week
- lots of different things
- started playing around with Parrot's support to build against an installed version
- looks promising
- ready to make those conversions -- build against a build tree or an installed tree
- we'll have that for the next release (Rakudo #18)
Allison:
- we can finally make Rakudo packages
- that'll make people happy
Patrick:
- had a lot of relevant posts talking about Rakudo's speed on a simple increment loop
- the increment took an incredibly long period of time
- had a lot of discussion in #parrot
- turned out that our initial ideas weren't correct
- it was
postfix:++ in Rakudo being incredibly slow
- refactored that to make it faster
- that was incredibly difficult, for many reasons
- I did work that out
- the autoincrement operator is now 80% faster than it was
- that just tells you how slow it was
- it's not fast now, but it's a lot faster
- it has to return the value before the increment takes place
- you have to clone it before you increment it
- that clone routine was incredibly expensive
- it's expensive in the general case
- you may be cloning something with attributes
Larry:
- Perl 5 optimizes that to a pre-increment in void context
Patrick:
- I don't know how to detect that in Rakudo now
- probably needs to take place at the compiler level
- I could optimize that
- also turns out that doing
isa checks are incredibly expensive
- we had an optimization to check if it's an Int
- but that optimization slows it down
- Parrot's
isa opcode always creates a new ProxyPMC on every call
Allison:
Patrick:
- we'd fixed that for
new and other things
- there was a case that leaked through in a specific order of optimizations
- Julian and I have cleaned that up for good, at least until core PMCs live outside of the root Parrot namespace
- that lookup occurs right there now
- Rakudo treats Parrot's integers and floats like Ints and Nums
- we didn't have HLL mapping
- I tried to add HLL mapping, but that slows things down by a factor of three currently
- we do it at runtime now
- we'll live with the shadowing for a while longer
- Vasily helped me improve parsing speed as we can translate most programs to iso-8859-1 form
- tried this before, but there was a bug in comparing STRING hash keys between iso-8859-1 and UTF-8
- tried converting to UCS-2, but there's a bug in numeric conversions there
c:
Patrick:
- that too
- managed to get the Latin-1 conversion working
- Vasily fixed the one bug remaining there
- that gave us parsing speed improvements for spectests which contain Latin-1 characters
- quite a few spectests contain non-breaking spaces
- quite a few contain one non-breaking space, between
Perl and 5
- that single space meant we couldn't convert to ASCII for parsing, which made it slow
- the assign.t test went from taking 2 minutes to 30 seconds
- all of which was due to one non-breaking space in a comment in that file
- fixed up symbol imports, importing from other modules
- specifically from the
Setting
- the previous code didn't work quite right
- discovered that when moving things into the
Setting
- we can move even more stuff from pure PIR code there now
- closed about eight tickets yesterday
- fixed handling of method calls in self in a method
$.method() through the accessor interface now works correctly- figured out but haven't implemented
BEGIN
- changing how Rakudo tracks
ro versus rw
- shouldn't be too big a refactor
- updating the postcircumfix brackets and braces code (needed it anyway)
- fixing those will mean that I can fix autovivification of array and hash elements
- an ongoing bug in Rakudo
- will allow us to make lazy Ranges
- they're currently quite eager
Allison:
- working on the PIR book
- almost finished with the last chapter now
c:
- you probably need me on that soon
Allison:
- I'll be gone for a week
- will hand them off to you for editing
- did some more Debian packaging work
- someone wanted it to work on Debian GNU/FreeBSD
- looks like a quick config change was necessary there
c:
- working on a grant proposal to write PIR-level profiling tools
- fixing memory leaks
- working on performance
Patrick:
- we desperately need that PIR profiler
- the simple loop case, for example
- the problem turned out where nobody expected it
- it took me an hour to find it
- I'm concerned about calling conventions landing before 1.4
Allison:
- I'm not sure it is
- at the moment, the most critical thing for 1.4 is to build from an installed Parrot
Patrick:
- I'm comfortable that that will happen
Allison:
Patrick:
- Rakudo is close
- Tcl is doing it now; once again Tcl has paved the way
Allison:
- Tcl still can't build if you remove the build directory
- I'm pretty sure we can do that
Patrick:
- I should report for Jonathan
- he did impressive stuff this week
- he re-wrote Rakudo's dispatcher
- method dispatch avoids Parrot right now
Allison:
- that's intentionally overrideable
Patrick:
- the fact that it's working is impressive
- our dispatcher now handles MMD issues
- some of the other funny things Parrot's default dispatch can't do
- our bottleneck now is parameter passing
Allison:
- marshalling and unmarshalling?
Patrick:
- also type checking
- we want to do that in C instead of in PIR
Allison:
- you don't have the hooks to do that at the C level?
Patrick:
- right
- unmarshalling may use a dynop
- whatever we build today will blow up when the calling conventions at the C level change
- I'll work on getting an installable Rakudo against an installable Parrot
- in a week, it'll either work or I'll have a list of things we need to resolve
- we want to have that a week before the 1.3 release
- I'll prioritize that
- hopefully that'll free Allison up for other things
- if you check in what you have on the calling conventions branch, maybe c and others can start on it
- it's not a killer if that doesn't land by 1.4
- it'll hurt
Allison:
- it pushes them out to 2.0
- we can check them in in 1.5
- but it pushes them out of packaged releases until 2.0
Patrick:
- we'll work against 1.5 etc
- but Jonathan will have to work around things
- last week I asked about semicolon versus comma in
zip
- now I ask about it in postcircumfix brackets
- that is,
@a[1,2,3] versus @a[1;2;3]
- how does it see them differently?
Larry:
- that's a good argument for me to reverse my previous decision
Patrick:
- I didn't think about it until last night
Larry:
- ... a single slice in one dimension
- something has to tell us whether there were semicolons
- last week's answer is no longer operative
- recursive descent looks in there for statements in STD
- we have the tree nodes to deal with that
- ... but how it's represented at runtime
Patrick:
- is
rand() now a function call?
Larry:
- to a non-existent function
rand is a term parsed like pi or e- it's a term that returns a different result when evaluated
Patrick:
- if I have a string that looks like a radix coversion without the closing brackets
- someone numifies that
- do I get back 0 or a Failure of some sort?
Larry:
- if it had its final bracket truncated, it may have had trailing numbers truncated too
- bad number
- it ought to fail
Patrick:
- what's the criteria for that?
- string-to-number conversions convert what they can and ignore the rest
- if I had a string that started with
:2 and didn't match, what'd I get back?
- same question for things that look Complex but really aren't
Larry:
- we want to distinguish things that are malformed from things with trailing garbage
- if you have a base-ten number with trailing alphanumerics, you ought to return a number with a warning
- other than that, my feeling is a Failure
Patrick:
- I can make a prototype
- we should figure out where we should fail
Larry:
- if you're going to do a numeric conversion and nothing looks numeric, that should be a warning
Patrick:
- we can warn on any conversion that doesn't look like a number
Larry:
- that's in the spec somewhere
Patrick:
- numifying a string that doesn't contain anything numeric-looking produces a warning
Larry:
- the spec only allows leading and trailing whitespace
- you get a warning otherwise, at least
Patrick:
- would you get that same warning for
123 Easy Street?
- you get extra stuff besides the number?
Larry:
- yes
- may want to distinguish that from a malformed number
Patrick:
- I like that
- we can try it and see how it works
Larry:
- do you want to blow up the rocket now or later?
Patrick:
- I can see people wanting an adverb that says "I don't care!"
Larry:
Patrick:
- PHP has the prefix-@ which suppresses the error you'd otherwise get
Larry:
- I've thought about something like that
- "I know I'll get an error, but throw it away"
Patrick:
- I can always do
expr // 0
- but I want something short -- one character long
try is a little long
Larry:
\ is available- more inclined for a prefix listy thing to suppress errors from its arguments
c:
- upside-down exclamation point!
Larry:
- mix that with complex numbers
Patrick:
- the idea came up of getting swag with Camelia on them
- that's interesting
- but there may be a perceived conflict with TPF on that
- thinking of doing the same thing for the Rakudo-pseudo logo
Allison:
- just committed my outstanding changes to the PCC rewiring branch
- not all tests pass
