weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
Set by moderator on 24 July 2010.
04:02 ash___ joined, jnthn joined, eternaleye joined, [particle] joined, [Coke] joined, PerlJam joined, Tene joined, TimToady joined, ascent_ joined, moritz_ joined, sorear joined 04:05 ash___ joined, jnthn joined, [particle] joined, [Coke] joined, TimToady joined, ascent_ joined, moritz_ joined 04:08 Tene_ joined, ash___ joined, jnthn joined, [particle] joined, [Coke] joined, TimToady joined, ascent_ joined, moritz_ joined 04:14 Tene_ joined, ash___ joined, jnthn joined, [particle] joined, [Coke] joined, TimToady joined, moritz_ joined, ascent_ joined 04:18 Tene_ joined, ash___ joined, jnthn joined, [particle] joined, [Coke] joined, TimToady joined, ascent_ joined, moritz_ joined 13:01 Util joined 16:01 Tene_ joined 16:13 eternaleye joined 16:34 masak joined 17:22 pmichaud joined 17:27 bphillips joined 18:52 colomon joined 18:55 masak` joined 18:57 mberends joined 18:59 lue joined 19:01 frettled joined, patrickas joined
moritz_ #phasers... now? 19:01
or in 28? 19:02
lue 19:00 UTC is noon for me, and it's noon right now. So...
19:02 ltyr joined, ltyr left
jnthn Now, I believe. 19:02
masak o/
jnthn Oh hai, fellow phasees. 19:03
moritz_ \\o
masak oh hai!
lue BEGIN { # ?
jnthn yaymasakisback!
PerlJam greets
masak eager to be phasing back. 19:04
frettled we're entering a new phase?
jnthn :-)
moritz_ masak: can you start with your gsoc report? 19:05
masak: and report of everything else, of course
masak sure.
I've been away for four days.
before I left, I did some work on enums for the Rakudo release.
moritz_ revert it :/
19:06 isBEKaml joined
masak moritz_ wisely reverted the important half of those commits, because it caused failures that I didn't detect. 19:06
that's OK -- I'm diving into the cause now.
as for GSoC/Buf/IO, I've talked a bit with cono++, who seems interested in test-driving pack and unpack with me.
for the coming week, that's mainly what's planned: ironing out some encoding issues in Buf IO, and pack/unpack. 19:09
I'm overdue for a GSoC blog post. will try to rectify that as things settle down.
.eor
moritz_ masak++
I guess I'll go next
What I did for Rakudo:
* implemented adverbs to s///. pmichaud++ for fixing the parser to allow it.
* changed s/// to call (was an object before), jnthn++ for providing the prereqs 19:10
* applied various patches
* now working on :i and :s for s///
For star:
* hacked together a build script (work in progress)
* worked on injecting modules into pls' cache dir (injecting works, building fails)
For the book: * debugged the build process with pronik++ * made him merge the layout_basic branch * updated the regex syntax to use <&foo>
General:
* blogging
* panicking
.EOR
while we are at the m's... mberends?
pmichaud (here, btw) 19:11
moritz_ \\o
mberends ENOREPORT # sorry..
moritz_ no problem
pmichaud: do you want to go next?
pmichaud sure
19:11 molecules joined
pmichaud let's start with today 19:11
right now I'm working on the build system for star
I have a good Configure.pl script in place, and I'm working out some of the other details 19:12
it's a bit tricky because the star repo ends up containing the tools to build a distribution, and not the distribution itself.
but that's probably how it should be.
moritz_ agreed
pmichaud now for the past
Converted the 'for' statement to use .map . 19:13
.map now understands next/last/redo exceptions.
Refactored Block.arity and Block.count so that they calculate the values once, as part of the signature, instead of each time they're invoked.
(this was necessary because .map currently uses .count, which in turn had been implemented using for, which is now using .map) 19:14
moritz_ hilarity ensured :-)
pmichaud fixed the double-gather bug
attended OSCON, gave presentations on Perl 6 and Rakudo Star
the Rakudo Star presentation was nicely attended and seemed to have good feedback/enthusiasm :-) 19:15
so, my plan between now and Thursday is to complete the build system for R*, and write various announcements and the like
I have lots of items for discussion, but will wait until others have reported and it's question time.
EOR
moritz_ (Renee BƤcker asked if there'll be a press announcement or so) 19:16
PerlJam btw, I started playing with using Dist::Zilla to produce a R* distribution. It's at github.com/perlpilot/rakudo-star (for those that have never used Dist::Zilla, the dist.ini file contains information about the distribution and how to put it together)
moritz_ colomon: do you have a report? 19:17
colomon sure
moritz_ then go ahead 19:18
colomon Fixed the hideous Rat performance bug, pmichaud++ for noticing it.
Added .isNaN method. 19:19
Random minor series patches (patrickas++ provided most of it and I just merged)
Ported LastOfTheCarelessMen's Vector.pm and Polynomial.pm to current Rakudo, made separate packages for them. 19:20
Wrote and submitted grant report.
EOR
moritz_ colomon++
jnthn?
jnthn This Week 19:21
* $_ is now set to the LHS of a smart-match while we evaluate it's RHS, and restored afterwards.
* Importing multis now compliments the set of existing candidates in outer lexical scopes, not just blows 'em away.
* Tracked down and fixed the Rakudo bug that broke Zavolaj, which also helps towards .wrap in trait_mods, but not got to that
* Been trying to fix the role outers bug. I've so far founds lots of things I can do that don't fix it. :-/
* Some work on my YAPC::EU presentation
* Some grant manager bits for colomon++
* A bit more thinking about meta-model stuff
Next couple of days
* Try yet more to fix the role outers bug
* Rip into pls and Zavolaj makefiles and try to make them function on nmake
* Give the * build process a good going over on Win32 and try to make sure it works
colomon jnthn++
jnthn * Blog something about R*
After R*
* Finish my YAPC::EU presentation
* Prepare for the hackathon, and think about stuff I need to discuss with people in meatspace, while there's a chance to do so
* Whatever fixes and other work I have energy for, but I want to rest some ahead of YAPC::EU to make the most of it :-)
.EOR
frettled o_O
jnthn** 19:22
masak jnthnāœ©āœ©
jnthn Putting chars not in my font after my name is teasing. :P
lue Unicode is awesome. 19:23
masak jnthn: your OS needs an upgrade.
jnthn So long as it wasn't U+1F4A9.
moritz_ has anybody else a report for us?
frettled o/ 19:24
moritz_ frettled: you have?
frettled EOR { Submitted a documentation patch for README }
See, that was quick. But it was the first Rakudo contribution.
mberends yay! 19:25
jnthn frettled++
colomon frettled++
jnthn frettled: The first patch is like a gateway drug... ;-)
isBEKaml frettled++ :)
colomon can quit any time. honest.
frettled heh
moritz_ colomon: right, you just NOT WANT 19:26
jnthn colomon: Nooooo!
:-)
moritz_ so, anybody else got any reports?
lue if I could only find something else as fun as := was...
isBEKaml ehh? colomon, was that you speaking? :)
lue : nothing to do for `report'. 19:27
moritz_ I guess there will be discussions
isBEKaml erm.. well, not a report. I was thinking, maybe I could do something towards making a rakudo star package disribution for Slackware linux. You already have debian, fedora packages. ..
moritz_ like for example: pmichaud, is there anything we can do to help with packaging of star? 19:28
isBEKaml: sure, go for it!
isBEKaml yeah, will you be packaging parrot along with perl6-rakudo star or will that be a separate dependency download?
moritz_ isBEKaml: parrot will be packaged, but for distribution it's probably better to provide a separate parrot package 19:29
pmichaud star will come with a copy of the parrot sources 19:30
frettled I suppose it's important that such packages require strict version compliance rather than just a minimum version of parrot.
lue is preparing for R* celebrations and considering a hextime module.
pmichaud here's the storyboard I have thus far
Alice downloads rakudo-star-2010.07.tar.gz
Alice unpacks rakudo-star-2010.07.tar.gz into rakudo-star-2010.07 dir
cd rakudo-star-2010.07
perl Configure.pl
at this point 19:31
if Alice already has a sufficient parrot installed, Configure.pl detects it and uses that
otherwise, Configure.pl says 'your parrot isn't recent enough, try again with --gen-parrot if you want to use the parrot that came with rakudo star'
masak does "sufficient" mean "at least this version" or "exactly this version"?
pmichaud "at least"
masak ok.
lue why not a prompt "would you like to use the version of parrot that came with rakudo star?" ? 19:32
pmichaud if using --gen-parrot, the parrot gets installed in the "install/" subdir of the rakudo-star dir
lue: prompts are a little harder to work with
moritz_ prompts are hateful.
lue ok. Just thinking.
isBEKaml why not make gen-parrot the default option if no parrot installation was detected?
pmichaud isBEKaml: because I don't think that configuration scripts should make too many assumptions 19:33
[particle] i'm not sure i like "at least this version" as a permanent solution, but it'll work for R* release 1
isBEKaml we could just echo a message that it does such and such..
pmichaud isBEKaml: it'll scroll up and be missed
moritz_ could we continue with the storyboard, and ask questions later?
pmichaud the --prefix option to Configure can also be used to set where parrot/rakudo are installed. 19:34
at the end of the Configure.pl script, we have a valid parrot installation somewhere, and makefiles configured to make use of that
so then, "make"
this builds Rakudo (calling its Configure.pl in turn), which creates a perl6 executable, which is then copied into the dist dir
it may also go ahead and do the steps for building the bundled modules. I haven't gotten to that stage yet (yes, they'll be built somewhere in the process) 19:35
I plan to have a sample tarball ready sometime today.
at that point I need people to test the tarball :)
after "make", one can do "make install" to put everything in the right place. 19:36
PerlJam the modules probably have to be built in a specific order.
pmichaud PerlJam: that's fine, if so.
I'm playing with several possibilities for driving the build. At the moment I'm using a Makefile, since it's pretty straightforward. I may end up switching to a perl script if I need things that can't be handled in the Makefile 19:37
in several places the Makefile just calls a perl script to do fancy things when needed (as Rakudo does now)
[particle] s/fancy/portable/ in other places
jnthn pmichaud: So long as the Makefile stays quite simple / doesn't use "advanced features" should be workable. 19:38
pmichaud jnthn: right, I'm pretty aware of that. :)
jnthn pmichaud: I'm pretty free tomorrow to give it a workout on Win32.
pmichaud I tend to want to stay away from "advanced makefile features" in general.
makefiles are just more concise than perl scripts for build steps
jnthn Same, but sadly pls generates Makefiles that use 'em, as does Zavolaj's Makefile.
pmichaud we likely should fix that. 19:39
jnthn I'll try and simplify them a bit.
Certainly.
pmichaud I've always kept makefiles on the simple side.
moritz_ pmichaud: what about a site-wide parrot install where the user doesn't have privs to install rakudo to?
pmichaud moritz_: then "make install" will likely fail.
isBEKaml I don't quite like that parrot makes for a site-wide install when it's just a non-root user without privs.. 19:40
pmichaud isBEKaml: there's little I can do at this point about Parrot's build/install system. 19:41
mberends if a Makefile needs the help of a Perl 5 script, would it not make sense to eliminate the 'make' dependency and just create a bigger Perl 5 script? It would surely make Win32 building easier. 19:42
pmichaud mberends: that hasn't been my experience
mberends ok
pmichaud mberends: I find makefiles that call perl 5 scripts to be much easier to maintain than having everything in a perl 5 script
maybe I'm just writing them wrong... but see "more concise" above.
mberends yes 19:43
frettled was always a bit miffed about various programs requiring a Configure.pl.
lue it (the tarball) is a good chance for me to see if I can compile rakudo on this old thing :)
frettled However, autoconf with configure changed that a bit.
Technically, though, I'd favour make config(ure) 19:44
[particle] mberends: you'll need both perl 5 and make to build parrot anyway
(on windows)
moritz_ pmichaud: will there be a point rlease of rakudo? if yes, when?
pmichaud I wasn't necessarily planning on a point release.
isBEKaml pmichaud: yes, I second the point release. We'd want to do a dry-run anyway before the actual release. 19:45
moritz_ pmichaud: what do you want to do instead?
jnthn pmichaud: Just taking a version from git?
PerlJam pmichaud: will R* be based off of 2010.07 or whatever is in master at the time?
jnthn pmichaud: +1
pmichaud since Rakudo Star bundles its own copy of rakudo, I was just going to use that
moritz_ so, HEAD?
pmichaud well, whatever freeze point we end up declaring for this
moritz_ ok 19:46
pmichaud communicating a point-release to the outside world seems like more trouble than it's worth
jnthn Indeec
moritz_ ok
jnthn It buys us nothing
pmichaud i.e., I think it'll just make even more confusion.
jnthn And costs us time.
moritz_ maybe just tag it in git
pmichaud tag in git works.
which brings me to my other question -- when can I call a freeze on Rakudo for purposes of R*?
what features should we hold on? 19:47
[particle] if you use the rakudo release, you don't need to
jnthn pmichaud: I'll make another try tonight to fix the roles outer bug.
moritz_ from my POV, at any time
jnthn [particle]: ETOOBROKEN
moritz_ [particle]: rakudo release was broken
pmichaud [particle]: the rakudo release is missing some important features/bugfixes
[particle] oh, sad face.
pmichaud yes, I wanted to use the release, but got overruled by events :)
PerlJam jnthn: what if you can't work it out tonight-ish? 19:48
pmichaud PerlJam: then we ship with the bug.
jnthn I'll cry.
And what pmichaud said.
pmichaud and jnthn will cry.
isBEKaml well, from my POV, we can't use the rakudo release since that'd mean there's no difference between a rakudo release and a Rakudo *! :)
pmichaud isBEKaml: not true
Rakudo * holds a lot more than just the compiler.
frettled jnthn: good thing we have hugme
PerlJam frettled: indeed 19:49
isBEKaml pmichaud: ok.
pmichaud anyway, if I get a tarball done early-ish today, I may take another crack at the outer bugs.
frettled \\o/
isBEKaml do you have some doc anywhere on what will be included in the dist? 19:50
PerlJam pmichaud: so ... it sounds like there should be a freeze tomorrow no matter what.
moritz_ isBEKaml: the book, if people want it my 5to6 series
pmichaud PerlJam: sure, I'm just wondering when I should call the freeze, or what people might want me to wait on.
isBEKaml moritz_: great! :)
PerlJam pmichaud: whenever jnthn reports success/failure sounds like a good time to freeze to me.
isBEKaml I'll pack that in too. :)
jnthn pmichaud: IMHO, I'd call it tomorrow, and that gives us time to focus purely on the distribution. 19:51
pmichaud jnthn: "tomorrow" is a bit fuzzy. How about 20h00 utc tomorrow?
that means you all have 24hrs :-) 19:52
PerlJam +1
jnthn +1
pmichaud and iwbni there aren't any radical changes that introduce highly visible bugs
moritz_ wfm
colomon +2
masak +1
pmichaud so please test thoroughly if you can :)
jnthn pmichaud: I've nothing planned beyond the role fix.
moritz_ pmichaud: I'm still working on s:i///, but I'm not too disappointed if that doesn't work... and it's unlikely that it breaks anything else 19:53
[Coke] ~~
masak I still want to try hard to get the roles stuff in.
I now have four commits pending.
moritz_ masak: s/roles/enums/? 19:54
jnthn masak: "the roles stuff"?
masak jnthn: sorry, enums. 19:55
masak is slightly distracted
[Coke] has a one line belated report. 19:56
moritz_ [Coke]: go ahead
jnthn masak: The last enum patch broke stuff quite badly, although I don't see why it woulda done. Am a little nervous about more going in unless there's some serious testing against the stuff that got broken last time around.
[Coke] I released rakudo star with some borkedness, and worked sporadically on the RT queue.
PerlJam s/rakudo star/rakudo 2010.07/ :) 19:57
[Coke] GAH. Yes, what he said.
pmichaud Coke++ 19:58
isBEKaml thinks the excitement leads to distraction. ;)
moritz_ [Coke]: the brokenness really wasn't your fault
[Coke] Still. =-)
moritz_ still [Coke]++, you're right 19:59
isBEKaml [Coke]++
colomon [Coke]++ 20:00
[Coke] (RT) and we're at 645 tickets.
moritz_ anything else we want to discuss?
jnthn Is the plan for module installation to call out to pls? 20:01
I spotted something like pls_rstar_hacks or something...
pmichaud jnthn: ideally, yes.
I'm still working that out. The existing build script for star failed on my system.
(as far as module installation goes)
jnthn OK, my question is kinda what I should be editing in order to affect the pls that goes into R* 20:02
masak jnthn: I also don't see why things would have broken. I intend to find out.
jnthn e.g. where to put my Windows fixes.
moritz_ failed here too - haven't got it working yet
pmichaud jnthn: just edit/fix as if star didn't exist
jnthn That is, should I put them into the proto repo's pls branch, or into some copy in the star repo and we backport them, or?
OK.
pmichaud it's entirely okay if the tarball for this first release ends up being handcrafted to some extent. 20:03
we don't want it to be that way forever, but for a first release, it doesn't all have to be automagic
isBEKaml handcrafted? do you plan to distribute binary releases too? 20:04
I think not.
pmichaud isBEKaml: I don't plan to do it, but others will (hopefully) use the tarball to create binaries
isBEKaml ok
pmichaud another piece/question to all of this is that R* will apparently be available _only_ via its tarball.
i.e., there's not a git repository that one can clone that contains the equivalent files. Is that okay? 20:05
moritz_ yes
PerlJam pmichaud: certainly
isBEKaml yes, I expected that.
jnthn Yes, that's fine.
pmichaud okay, one last point. are we mentally prepared for the torrent of "god this is awful" comments that will likely come out after the release? ;-) 20:06
moritz_ you mean, like, on reddit? :-)
pmichaud I mean, like, everywhere.
isBEKaml Oh, no, pls don't bring reddit here... :|
moritz_ will just /leave #perl6 for a while :-)
lue
.oO(There are many great hiding spots. The (no longer) Lost Moon of Poosh, Barcelona (the planet), Space Florida...)
 20:08
pmichaud sounds like yes, or else everyone just ran off to hide for a week. :) 20:10
I think that's all I have for today. 20:11
lue
.oO(We could also set up a Taunting Frenchmen bot to detect disparaging remarks about R*/P6 and taunt the person back...)
Tene backscrolls.
jnthn lue: No, we'll leave purl in #parrot. :-)
pmichaud: I figure the release annoucement is going to be fairly clear about what people can expect/not expect?
pmichaud jnthn: sure. but many won't read the announcement (more)
jnthn I know. :-/
pmichaud and many will be looking to dump on Perl 6 regardless of what an announcement says
masak \\o/
jnthn Sure, that's nothing new.
pmichaud I just think it's likely to be a bit stronger than usual. 20:12
mberends pmichaud: I'm confident there will be more +ve comments than -ve
moritz_ if they ignore us from that point on, fine :-)
pmichaud mberends: I hope you're right.
masak moritz_: don't bet on it.
pmichaud mberends: but I'd rather be prepared for the -ve ones
isBEKaml moritz_: they can't un-see us once they have "seen" :)
I bet it'll be more positive than negative. 20:13
lue PLEASE READ THE ANNOUNCEMENT <- "You didn't see this on rakudo.org, perl6.org, #perl6 topic, the README, or the first-use welcome screen!?"
pmichaud I'm sure a very common refain will be "Perl 6 takes 10 years, runs on geologic time scales, has more bugs than a petri dish)
[particle] but it's -Ofun!
lue .oO[ A petri dish contains bacteria, not "bugs" :) ] 20:14
mberends pmichaud: I believe you have a sort of stage fright!
pmichaud mberends: I'm rarely accused of stage fright. :)
jnthn mberends: No, I think he's being realistic.
colomon release fright
PerlJam after R* it'll need to be -Ofast before too long
colomon The important thing to remember is that the point of R* is to get more people using it. 20:17
I'd expect a huge wave of bug reports....
jnthn It'll be as if a thousand masak's up sent email at once.
*all
;-)
colomon and for the people who aren't predisposed to hate us, how we respond to those bug reports will be very important.
jnthn Seriously though, people using it and caring enough to submit a wave of bug reports is a *good* thing.
[Coke] I am planning on spending some quality time on RT post-release. :P
moritz_ ++[Coke]
lue
.oO( anyone here have camelias in their stomach for R*? )
moritz_
jnthn
lue
.oO(CTCP-ACTION request?)
isBEKaml oh, no. Camelia won't be happy holding back people. ;) 20:18
PerlJam lue: Larry said Camelia has about 2 meter wing span IIRC ... that won't fit in my stomach :)
pmichaud 3m, iirc 20:19
mberends Camelia is whatever size the video projector can make her. We've seen one over 3m.
pmichaud I'll be very happy to worry about bug fixes more than feature development for a while.
lue baby camelias then :) 20:20
pmichaud after getting closures, lists, regexes, etc. I could use a few "minor fixes"
we could use updated lists of "things known to not work" 20:24
20:25 isBEKaml left 20:26 molecules joined, lue joined, colomon joined, bphillips joined, Util joined, Tene joined, jnthn joined, [particle] joined, [Coke] joined, TimToady joined, ascent_ joined, moritz_ joined
colomon I expect pmichaud is right about hostile reactions to R*. 20:27
oh, they're back!
20:27 pmichaud_ joined
lue .oO[<100 on #perl6 again] 20:27
20:28 pmichaud_ joined, molecules joined, lue joined, colomon joined, bphillips joined, Util joined, Tene joined, jnthn joined, [particle] joined, [Coke] joined, TimToady joined, ascent_ joined, moritz_ joined
[Coke] oh, reminds me, I have the profiling stuff from parrot vaguely working on rakudo (easy to set up, just slow). Happy to try to figure out where certain apps are spending their time. 20:30
colomon [Coke]++
moritz_ I'm trying to keep perl6.org light on content that needs frequent updating
but a separate faq.perl6.org would work for me
20:30 pmichaud_ joined, molecules joined, lue joined, colomon joined, bphillips joined, Util joined, Tene joined, jnthn joined, [particle] joined, [Coke] joined, ascent_ joined, moritz_ joined
PerlJam If everyone looks to perl6.org for information, perhaps it should also have information prominently displayed about how to submit a bug report and how to locate known bugs. 20:32
pmichaud_ I'll definitely look at speeding it up. The RangeIter implementation is particularly slow at the moment.
colomon RangeIter should almost certainly just go away, no?
pmichaud_ NO
why would you want RangeIter to go away? in favor of series? I'm willing to bet that series will be even slower than RangeIter as it exists now.
much less an optimized RangeIter
moritz_: what's the timing for 'for (1,2 ...1000) {}' ?
moritz_ PerlJam: we have no easy way to submit Perl 6 bugs
colomon because RangeIter's results have to be the same as series's.
and series is the construct people will be using very often.
shouldn't we be optimizing series and then just implementing range iteration in terms of it? 20:33
moritz_ PerlJam: people just have to "get" the language/implementation distiction at some point
pmichaud_ we do have a place for Perl 6 bugs
moritz_ pmichaud_: real 0m8.339s
pmichaud_ perl6-bugs@perl.org
Tene for me, series is 4.5s, range is 3.0s
moritz_ pmichaud_: and what does that do?
pmichaud_ moritz_: sends tickets to RT
same as rakudobug@....
moritz_ that's less-than-useful though 20:34
pmichaud_ why is that?
the perl6 queue on RT isn't reserved for just rakudo
moritz_ but it's used mostly for that
pmichaud_ that's why there are bug reports that say "[spec]"
they indicate spec bugs
[Coke] rakudo has basically taken over that queue. we can worry about segregating by implementation when another implementation causes us to.
PerlJam [Coke]++ 20:35
pmichaud_ colomon: if series ends up being faster than RangeIter, I'm in favor of getting rid of RangeIter. But not before then.
[Coke] (either into separate queues or with a new piece of metadata.
pmichaud_ The common range simply occurs far to frequently.
[Coke] ... that said, i'd advertise rakudobug for now.
pmichaud_ And I expect people to write 1..10000 far more often than 1 ... 10000
[Coke] (and we can use that to segregate later.)
moritz_ we should really optimize Range with two ints
pmichaud_ moritz_: right 20:36
moritz_ that would already be a *huge* win
pmichaud_ that's why I think we should expect to keep an optimized RangeIter
I also think we'd get a huge performance boost if RangeIter batched up its results
instead of always producing values one-at-a-time
...but we can't always do that with series. 20:37
jnthn pmichaud_: Ah - that probably explains a lot why benchmark.pl runs slower now 20:39
pmichaud_: Because it uses for 1..5000 { stuff }
lue goodbye all o/
jnthn So probably method dispatch etc didn't get slower, it's just the overhead of the loop.
pmichaud_ jnthn: right, you're likely being dominated by the cost of counting
colomon I dunno, my understanding of the drift of the spec is that you really want series for iteration, not range, which can only handle the most common case. Seems like we should be focusing on improving series instead.
jnthn DOMINATE_ME_ITERATOR
pmichaud_ colomon: yes, that's the drift of the spec. but it's also the case that one of the reasons Range exists is to be able to optimize the common case that may be slow with series 20:40
if you can get the series iterator to be faster than an optimized RangeIter, I'm in favor of switching. not before then.
Tene pmichaud_: although, series could just detect the common case and make a rangeiter in that case.
pmichaud_ Tene: yes, that's entirely valid.
And RangeIter can become a little smarter in that it can do things more than just simple .succ 20:41
masak fwiw, the "...in Rakudo" that I append RT tickets with are a tacit acknowledgement of the RT queue being not-only-for-Rakudo in the long run.
pmichaud_ masak++ and +1
it's *also* the case that the series spec is *still* undergoing a lot of change at the moment (see recent thread on p6l). So I'm not willing to commit Range to it just yet. 20:42
as PerlJam++ pointed out above, at some point (soonish) our focus is going to need to be on -Ofast 20:43
otherwise Rakudo will have a reputation for slowness (like Ruby) that will be very hard to shake 20:44
so let's not get rid of our optimization potentials.
and please let's not introduce things that make common things *slower*
(even if they're arguably "correcter" in a design sense) 20:45
jnthn Indeed.
moritz_ the burden of having users... :-)
jnthn moritz_: Rakudo being slow harms developers too.
pmichaud_ we still need to fix numeric constants, for example. building all of our constants at runtime (repeatedly) is a serious lose.
moritz_ jnthn: I know. I was joking, like 80% 20:46
jnthn moritz_: :-)
Tene The PAST optimization stuff being worked on is potentially useful there.
moritz_ thinks that it can be done otherwise too, with not much more effort 20:47
pmichaud_ Tene: potentially, but we could more easily do it in Actions.pm
Tene Sure.
Also, clearly advertising "THIS IS VERY VERY SLOW!!!" with R* falls under "underpromise and overdeliver" 20:48
patrickas is the next distribution release after R* supposed to start focus on speed or not yet ?
Tene We can at least avoid people being *surprised* by the speed.
pmichaud_ I'm devoting a paragraph to slowness
it's likely to be right after the part that says "THIS IS NOT A PRODUCTION RELEASE" :-)
patrickas Maybe Rakudo Star 2010-07-28 could be code named "Slow Arcturus" :-)
Tene patrickas: at least one answer to that is tha work on speed is going to happen as soon as someone decides they're interested in working on performance. 20:49
pmichaud_ patrickas: speed at this point is more a function of compiler than distribution, but yes, I expect us to see more focus on speed.
I suspect the first release after R* will be primarily bugfixes
Tene patrickas: Parrot folks are starting to drift towards performance optimization these days.
jnthn news.perlfoundation.org/2010/07/hag...ta-m.html, if approved, is going to see me doing a lot of speed. 20:50
er, erm...not like that.
*on speed
I'm optimistic of a notable win.
PerlJam pmichaud_: what happens when there's *not* a flood of bug reports? We don't know if it's because no one is using it or if because they aren't hitting the bugs or what. :)
pmichaud_ PerlJam: I find that highly unlikely. But if there's not a flood of bug reports, we have a nice pool to be working on already. 20:51
and we can focus on speed.
moritz_ PerlJam: i guess the blogosphere and people joining the channel will give us some feedback
masak I believe there'll either be a non-flood of bug reports, or a flood of mostly non-bug reports (dupes, misunderstandings etc) 20:52
moritz_ masak: I think it's going to be the latter
PerlJam masak: yeah, I kind of lean towards the latter
pmichaud_ okay, so after someone builds rakudo, what should happen next? 'make install'? 20:53
rakudo can't really run until it has been installed. :-(
Tene IMO yes, "make install" 20:54
pmichaud_ should that happen automagically? or should we tell someone "next you need to 'make install'"?
and should there be a 'make test' step in there somewhere?
Tene pmichaud_: I prefer a separate 'make install' 20:55
pmichaud_ me too
I can move this discussion go #perl6
Tene if I were installing system-wide, build as user, install with sudo
frettled If Ā«make installĀ» also implies a build, that's fine3.
s/3//
mberends f1n3
Tene 'make test' is spectest? Include snapshot of /t/spec/ 20:56
?
I'd like that.
moritz_ against it. Takes too long. 20:57
Tene I'd be for including spectest as an option, at least.
colomon something in between? generate a couple of test files which are a good representative sample of things you can do in Rakudo, and add them to "make test" for the distribution? 20:58
(and yes, make spectest ought to be an option, IMO.)
20:58 patrickas left
mberends colomon: nice idea, perhaps use the existing integration tests 21:00
frettled I'm not sure that the spectests should be part of R*, it seems that spectests are more interesting to regulars on #perl6 than the wider audience.
mberends: +1
colomon frettled: might be good to have for our sake.
that is, if someone's R* build is doing crazy crap, if they can run the spectest it might be a significant help for our debugging effort. 21:01
PerlJam If we include the spec tests people will also have a handy bit of Perl 6 code to look at 21:02
But I agree with moritz_, they shouldn't be run by default.
frettled I like those two points.
pmichaud wfm 21:10
[Coke] +1
pmichaud I do like the idea of including the spectests 21:11
(but not running by default) 21:13
[particle] hrmm, will the spectests be updateable?
pmichaud generally we don't do that for a release, no. 21:14
[particle] (will you bundle the .svn dir?)
good.
actually, i think i take that back. they won't get installed, so nobody will ever run them. 21:15
PerlJam might want to explicitly mention somewhere that it's a snapshot of the spectests as of such-and-such date such-and-such revision.
pmichaud right now one of the pieces I'm struggling with is that many of the make targets one might like to do from the distribution dir end up having to simply forward to Rakudo's makefile. 21:17
that feels... wrongish. 21:18
I'm calling an end to #phasers for me and moving all discussion to #perl6 (too much trouble to switch between chans right now)
jnthn Aye, good call. 21:19
[Coke] there was a call too!?
jnthn :P
mberends a tail call at exit
21:26 mberends left 23:26 PerlJam joined, Util joined 23:30 pmichaud 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!