Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Thursday July 30, 2009
08:39 PM

Perl 6 Design Minutes for 03 June 2009

[ #39380 ]

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:

  • that was kinda crazy

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:

  • and you require ICU

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:

  • that's my top priority

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:

  • that's try

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
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.