Perl 6 - the future is here, just unevenly distributed

IRC log for #rakudosketch, 2010-03-24

| Channels | #rakudosketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
18:18 _ilbot2 joined #rakudosketch
18:22 bkeeler joined #rakudosketch
18:23 lue joined #rakudosketch
18:42 espadrine joined #rakudosketch
19:00 bkeeler OK, it's the appointed hour.  Who's got the gavel?
19:00 mberends joined #rakudosketch
19:03 * bkeeler grabs lue and uses his head as a gavel
19:03 bkeeler *bang*
19:03 * TimToady comes from disorder
19:03 lue OWWWWWWWWWWWWWWWWWWWWWWWWWWWwWW
19:04 lue h-h-heere's th-th-th-e g-g-g-g-gav-v-veh..
19:04 * moritz_ appears out of thin air
19:04 TimToady last week's task was to parcel out pm's tasks to other people
19:05 TimToady is there something to do this week?
19:05 mberends must have missed the #rakudosketch of about an hour ago. --commute :-(
19:05 lue (I have half a mind to open up a couple other of my IRC clients and show up as Phoenix Wright and Edgeworth :) [bkeeler's fault])
19:05 * moritz_ tried to get JSON::Tiny run on Rakudo master
19:05 jnthn I'm back I'm back!
19:05 mberends hooray!
19:05 moritz_ sadly it's blocking on some regexy stuff
19:05 jnthn Sorry...they'd refactored the supermarket.
19:05 bkeeler When is the next parrot release supposed to be?
19:05 jnthn And it took me ages to find noms.
19:06 moritz_ bkeeler: April 19
19:06 bkeeler Ah, nice a ways off
19:06 moritz_ my biggest problem is that the Match objects are very parrot-y and not very Perl 6-y
19:06 bkeeler Got some nqp-rx fixes I'm hoping to get in
19:07 bkeeler moritz_: how so?
19:07 moritz_ but I fear that needs pm for fixing... or could bkeeler give it a try?
19:07 moritz_ bkeeler: for example %($/) shoudl return a Perl6 hash
19:07 moritz_ but it returns a Parrot hash
19:07 bkeeler Ah yes I see
19:07 moritz_ so .kv on it won't work, etc.
19:07 jnthn IIRC, the plan was to subclass the Parrot-y one and give it Perl6-y feelings.
19:08 jnthn I'm not sure how we tell the grammar engine to make one of the subclass.
19:08 bkeeler All the submatch objects would need coercing too
19:08 moritz_ maybe we can re-bless
19:08 moritz_ hrm
19:08 jnthn My impression is that it's meant to make them the right kind of thing in the first place anyway.
19:08 moritz_ anyway, I might give it a try tomorrow; have some tuits
19:08 bkeeler Or $/.keys would work, but $<foo>.keys would not
19:08 TimToady does rakudo use parrot's single dispatcher or one of its own?
19:09 jnthn I'm just not sure if (a) there's a way already to say to the grammar engine to make the right thing, or (b) what it should look like if not.
19:09 jnthn TimToady: For method dispatch or sub?
19:09 TimToady single dispatch is method dispatch
19:09 jnthn TimToady: For method its own. For sub, we just go through Parrot's find_sub op.
19:09 jnthn OK
19:10 jnthn Then custom.
19:10 TimToady sub dispatch is multi dispatch to me
19:10 jnthn What if there's only one of them? :-)
19:10 TimToady then it's a short candidate list :)
19:10 jnthn I kinda saw them as orthogonal, anyways. :-)
19:10 TimToady well, you may be thinking of .() as sub dispatch
19:10 jnthn Particularly as multi-method dispatch takes the per-inheritance-level route.
19:11 TimToady anyway, it seems odd to me that parrot types would be popping up as the parent of a Perl type, when it seems more like delegation to a different dispatcher
19:12 jnthn TimToady: The object actually decides its dispatcher, fwiw, so Parrot ones end up with the Parrot dispatch semantics.
19:12 jnthn Maybe the "subclass match" is the wrong way to go though.
19:12 bkeeler We certainly do need an elegant way to take hashes and arrays that come from parrot or some other HHL and use them in a perly way
19:12 lue .oO(I'm assuming right now is for anything related to the advancement or rakudo)
19:13 moritz_ aye; will be important for cross-HLL interop
19:13 jnthn Indeed.
19:13 TimToady but that's probably post-*
19:13 moritz_ presumably.
19:13 TimToady except for Blizkost, of course :)
19:13 jnthn To some degree yes.
19:13 jnthn There are some bits that are easy or already done.
19:14 jnthn Calling methods on Parrot objects works fine.
19:14 bkeeler Can probably punt on $/ for now.  We can add some methods to Match in the mean time?
19:14 jnthn The bigger problems are them not having the methods in Any.
19:15 moritz_ bkeeler: src/cheats/match-bool.pm adds methods to Match
19:15 moritz_ which is actually Regex::Match in rakudo right now
19:15 TimToady jnthn: which a thin delegator of Hash role might solve
19:15 jnthn TimToady: It may well do, yes.
19:16 bkeeler That sounds like a good approach
19:16 TimToady I see most cross-language dispatches as probable delegations, actually
19:16 jnthn OTOH, taking a Parrot Hash and calling CREATE_LOW_LEVEL_HASH and passing the Parrot Hash in already gets you a good wrapper.
19:16 jnthn Because Rakudo hash uses the Parrot Hash PMC for its underlying storage, just as an attribute.
19:17 moritz_ s:first/Parrot/Rakudo/ ?
19:17 jnthn moritz_: No
19:17 TimToady "internal delegation" :)
19:17 jnthn moritz_: You pass a Parrot Hash to CREATE_LOW_LEVEL_HASH and it makes a Rakudo Hash.
19:17 jnthn It's kinda badly named.
19:17 moritz_ aye :-)
19:18 jnthn I wonder which fool called it that.
19:18 jnthn If I find him, I'll give him a telling off.
19:18 jnthn :-)
19:18 moritz_ just before we get lost in this matter... are there other topics to be discussed here today?
19:18 jnthn OK, so I think we're agreed that Match objects are a weak point / blocker.
19:18 lue isn't it parrot->rakudo? Then why create LOW level?
19:18 jnthn We'll work out specifics of a way forward on #perl6
19:19 moritz_ +1
19:19 jnthn lue: 'cus somebody sucks at naming things.
19:19 jnthn ;-)
19:19 jnthn Are there any other worries / big blockers that it could be good to try and address in the next week?
19:19 lue good thing it's not me. (I'd've named it CREATE_JAPANESE_HASH :) )
19:19 bkeeler Well, may as well give a quick status re interpolation in regex
19:19 jnthn Go for it. :-)
19:20 bkeeler I'm on my third go at it now.  First was a quick proof of concept that only interped literal strings
19:20 bkeeler Second was more ambitious and worked for interpolating block results, but it was starting to get clumsy
19:21 bkeeler Third approach is a new PAST::Regex node type that knows how to handle interpolation properly
19:21 bkeeler I'm confident that it's the way to go
19:21 moritz_ pm seemed to agree
19:21 bkeeler For now, I'm putting it in Rakudo, since it needs to be able to compile regexes from strings that it gets back from evaluating the interpolatee
19:22 jnthn If pm agreed, it's likely right.
19:22 moritz_ I don't really understand the problem, but it feels as if it should go into nqp-rx with the right amount of genericity
19:22 bkeeler Though it occured to me that I could get around that and put it in nqp-rx with the other PAST::Regex types if I simply have rakudo pass its compiler object in as one of the child nodes
19:22 TimToady long run, I think we'll have a fairly rich set of AST types, at least for the most abstract representation
19:22 jnthn bkeeler: That works. Just because the underlying regex engine supports it and Rakudo too doesn't mean NQP also has to too. There's an argument for NQP to stay lightweight.
19:22 colomon o/
19:23 bkeeler Could go either way, really
19:23 TimToady and we'll want AST types to be extensible in any case to support language extensibility
19:23 jnthn bkeeler: Can't this be handled however embedded closures are now?
19:23 jnthn Or am I missing something?
19:24 bkeeler Embedded closures don't currently do anything with the result of the closure
19:24 bkeeler For <{ ... }> types we're supposed to interpolate the result, compiling it if necessary
19:24 TimToady and you don't want to desugar *too* soon or you take info away from the optimizer(s)
19:24 lue hi colomon
19:24 bkeeler And we need to use Rakudo's regex compiler for that
19:25 jnthn bkeeler: OK, I see the difference.
19:25 jnthn o/ colomon
19:26 mberends speaking of potential blockers, the recent symptoms of Parrot memory consumption and poor management are a warning of probably worse problems to come. Today was the first day that Rakudo would not build for me on a machine with 1GB RAM :-(
19:26 jnthn .oO( did the word memory get lost after "poor"? )
19:26 mberends yes :)
19:27 lue No! The Norweigan Blue is dying! Quick, make Rakudo self-sufficient!
19:27 jnthn ;-)
19:27 mberends forgot memory
19:27 colomon I was wondering if we have some sort of O(N^2) memory issue.
19:27 bkeeler Let's put 4000 volts through it, that'll make it VOOM
19:27 lue It's stone dead!
19:27 jnthn There's certainly something rotten there. Last week I got the impression that the Parrot team had an idea of what it was.
19:27 colomon so the faster we add new feature, the faster we run out of memory.
19:27 jnthn May be good to get an update.
19:27 jnthn colomon: The problem does *feel* like it's got worse non-linearly.
19:28 jnthn colomon: Trouble is we're also constantly bumping Parrot versions too.
19:28 lue /o\ parrot memory overflow hitting my head like a comet ☄
19:28 mberends colomon: it's either O(N^2) or O(a^N)
19:28 colomon mberends: I like to be optimistic in my pessimism.  ;)
19:28 mberends heh
19:28 jnthn So it can be hard to tell if we're hitting on Parrot regressions or just growth problems.
19:29 jnthn What's for certain is that there's a problem.
19:29 lue colomon++ quantum superpositions
19:29 mberends ack found over 300 mentions of realloc in Parrot source files
19:29 * jnthn wonders how concerning that is.
19:30 jnthn Sounds like...a lot.
19:30 jnthn Especially as it leads to a lot of copying.
19:30 jnthn Depends what's being realloc'd.
19:30 bkeeler Is that a lot of string growth?
19:30 * lue thinks of how Parrot may need to ask Sun how to write a virtual machine :)
19:31 mberends maybe an RPA is realloc'ed when it gets resized
19:31 jnthn That's very possible.
19:31 pmichaud joined #rakudosketch
19:31 TimToady Perl 5.10 has *six* references to realloc
19:32 lue oooh (ouch)
19:32 jnthn :-/
19:32 lue bad parrot! *smack*
19:32 jnthn 300 seems very much like progress in the wrong direction.
19:32 lue oh no! it's joined the Choir Invisible
19:32 TimToady well, there are wrappers
19:32 mberends hi pmichaud!
19:32 pmichaud log?
19:32 moritz_ http://irclog.perlgeek.de/rakudosketch/today
19:32 pmichaud viewing now (thanks!)
19:32 TimToady but seems like a memory pool should get a realloc, not individual memory elements
19:32 moritz_ can anybody obtain op to set the channel topic?
19:33 TimToady but realloc is a rathole
19:33 jnthn I think the Parrot memory consumption issue is now a much bigger deal than the speed issues.
19:33 jnthn The other problem is that we leak.
19:33 * lue everybody leave #rakudosketch, then have 1 person join, to get ops
19:34 moritz_ lue: let's do that after the metting
19:34 moritz_ *meeting
19:34 jnthn So over a long-running compile of something like the setting, that could be adding up quite a lot.
19:34 bkeeler Is parrot going to a static readonly string model?  I seem to recall that being discussed
19:34 jnthn bkeeler: I've seen that discussed too.
19:34 lue alright.
19:34 ash_ joined #rakudosketch
19:35 pmichaud (from earlier) -- my expectation is that the regex engine in nqp-rx will be able to create HLL-specific arrays and hashes
19:35 pmichaud haven't added that in yet.
19:35 jnthn I'm really not sure what the best course of action is here. I feel more and more that Parrot issues are currently one of our biggest liabilities for Rakudo *.
19:35 mberends pmichaud: is it permissible to use $(patsubst ...) in Rakudo's Makefile, or is that potentially non portable in your experience?
19:35 pmichaud in reality, it's fairly simple to do that, because the part that actually builds the match object is a per-cursor overridable method
19:36 pmichaud mberends: I'd expect it to be non-portable.
19:36 mberends :-(
19:36 lue jnthn: agreed. That's why I'm getting more and more hyper about being self-sufficient
19:36 PerlJam joined #rakudosketch
19:36 bkeeler So we subclass the cursor and make it do the right thing?
19:36 jnthn lue: Yes, but looking at Rakudo * timescales, we're kinda stuck with Parrot.
19:37 lue for now anyways :)
19:37 jnthn Beyond that, yes, I'm all for additional backends.
19:37 moritz_ I can write a message to parrot-dev with a call for aid on our memory problems
19:37 jnthn moritz_: That would be helpful. I think that's a good first step.
19:37 bkeeler Ruby seems to be doing well on both JVM and DLR
19:37 lue 1) we live with it 2) we become self-sufficient 3) we storm #parrot all at once and demand solutions
19:37 pmichaud bkeeler: we're already subclassing the cursor
19:37 pmichaud (or we should be)
19:38 bkeeler Ah good
19:38 pmichaud all regex matches are likely subclasses of Grammar
19:38 bkeeler Hmmm, I don't recall seeing that
19:38 pmichaud or we might want/need a Perl 6 Cursor class for it.  Either way, we'll have a subclass to work with
19:38 jnthn While I and @other could muck in and try to track down the Parrot issues too - after all, I did used to be a core Parrot hacker - there's also an awful lot of Rakudo land stuff to be doing. :-/
19:38 Coke joined #rakudosketch
19:38 bkeeler I'll take a look at it later
19:39 lue jnthn: let's just go and demand answers. That would be fun :) (and potentially rude...)
19:39 jnthn lue: Being rude to the Parrot folks will achieve nothing.
19:39 jnthn lue: They're also a team with limited resources too.
19:40 TimToady and a worse set of too-many-cooks problems
19:40 pmichaud bkeeler: the method that builds the match object is  Regex::Cursor.MATCH (in nqp-rx)
19:40 bkeeler Oh, also I sent in the Perl foundation paperwork so it will be on file for whenever you feel comfortable enough with my work to flip my bit
19:40 lue yeah, which is why I'm not actually doing it...
19:40 pmichaud currently it hard-codes Parrot Hash and ResizablePMCArray
19:40 pmichaud I'll likely want to change that to allow HLL-specific hash/array types
19:40 pmichaud but if we don't want to do that, we can always overload the method itself
19:41 jnthn lue: Sure, I just thought it was important to clear up for anyone reading the logs and humor impaired. :-)
19:41 pmichaud (it's a bit of a long/involved method, so probably better to solve it in nqp-rx)
19:41 jnthn OK, so we have this week regex focus and try to get Parrot help on memory issues. Any other issues?
19:41 moritz_ pmichaud: how would allow HLL-specific array/hash types? by passing type objects to it that it calls .new on?
19:42 lue too bad there's no magic program that would allow you to see the memory leaks and where they come from...[cue]
19:42 pmichaud moritz_: we'd parameterize it some way, yes.
19:42 pmichaud Another possibility would be to have private "make hash/array" methods on Cursor
19:43 moritz_ lue: it will tell you that all the leaks happen in Parrot_mem_alloc or some such
19:43 pmichaud so then the subclass of cursor simply overloads whatever it wants for creating the hash/array
19:43 jnthn lue: Just 'cus Valgrind says it leaks doesn't make it immediately obvious how to fix it sadly.
19:43 espadrine joined #rakudosketch
19:45 pmichaud alas, looks like I have to run again. bbl.
19:45 lue it's obvious! Have someone make a patch :P
19:45 jnthn pmichaud: Thanks for the input!
19:46 bkeeler take care, pmichaud
19:46 lue Ah, I ought to take a look at Parrot code sometime, eh?
19:46 jnthn OK...so I think we have some focus for this week. Looking at the ROADMAP, I think we've not done bad over the last week too. :-)
19:47 colomon jnthn++
19:47 jnthn One priority 1 task got marked done, item assignment is done AFAIK and just needs assign.t being fudged and turned on. Don't know if anyone is up for that little task? :-)
19:47 jnthn Once we have test coverage of it, I think we can also mvoe it to done though.
19:48 moritz_ maybe I find tuits for that tomorrow
19:48 jnthn \o/
19:48 moritz_ but don't call it 'little', please
19:48 jnthn moritz_: It's not little, I grant you that.
19:48 lue speaking of ROADMAP (http://xkcd.com/461/)
19:49 jnthn I think bkeeler++ has a good handle on "lexical variables in regexes"
19:49 bkeeler Yep
19:49 jnthn "operator overloading" we've got some decent progress on.
19:49 jnthn There's two big problems left with it.
19:49 jnthn (1) Pre-compiled modules. (2) Interaction with meta-operators.
19:50 moritz_ (3) lexical multis
19:50 jnthn I know how to fix (1), just didn't get to it yet. (2) needs a tad more effort.
19:50 mberends what's the problem with pre-compiled modules?
19:50 jnthn moritz_: That's a whole problem of its own. :-)
19:50 jnthn mberends: The parser tweaks don't make it into them.
19:51 moritz_ uhm, they sholdn't
19:51 moritz_ unless imported
19:51 jnthn moritz_: Hm. Good point.
19:51 jnthn moritz_: That still needs implementing though.
19:52 jnthn But yes, you're right...that's an importer issue to some degree.
19:52 colomon what's the difficulty on the interaction with meta-operators?
19:52 jnthn colomon: AFAIK you had to define operators as "our" to then use them with meta-operators?
19:52 jnthn Or has that just got fixed amongst other things?
19:53 jnthn moritz_: They may still have to make it somehow into the pre-compiled module...if it does an "eval" I guess the eval'd code needs the parser tweaks too.
19:53 jnthn Well, needs a tweaked parser... :-)
19:54 jnthn colomon: I see on #perl6, still an issue. :-(
19:54 lue I'm not sure how to call #65546 (i lean on rejected, but I'm nervous of making this decision...)
19:55 colomon Nope, needs our.
19:56 jnthn I think my main concern in terms of ROADMAP items right now is probably "complete lazy lists in Seq and Array", fwiw.
19:56 colomon nod
19:57 colomon not only needs to be done, but seems like it needs to be done ASAP, because a lot of other things will depend on it.
19:57 jnthn Aye.
19:57 jnthn I still need to get a better grasp on the issues there, tbh.
19:58 bkeeler I had hoped to start looking at it, but got bogged down in this regex stuff
19:58 jnthn There's probably some re-reading of logs I need to do to catch up.
19:58 jnthn bkeeler: That's fine, the regex stuff is important also. :-)
19:58 TimToady I tend to view the bogus package alias requirement as more crucial, in the sense of make rakudo * a non-subset of Perl 6
19:58 TimToady *making
19:59 TimToady Seq and Array without laziness is more of a proper subset of Perl 6
20:00 TimToady sixperl phone call now
20:00 jnthn TimToady: I totally agree with you in that it's important. I'm also less concerned on that in the sense that I understand the problems, and the relevant bits of Rakudo (and Parrot) rather better.
20:00 colomon TimToady: the real problem isn't non-lazy Seq and Array, it's the related issues with passing iterators.
20:01 colomon A lot of things that should just work regarding iterators in Perl 6 are dodgy to outright broken at the moment.
20:02 PerlJam What is this "bogus package alias requirement"?
20:02 TimToady the need for our
20:02 TimToady nearly everything having to do with function calling should be lexical, period
20:04 jnthn moritz_++ # thanks for the parrot-dev post
20:04 jnthn TimToady: Sure, it just takes some effort to get there.
20:04 mberends I've *got* to reduce the build memory requirements to remain productive. I hope pmichaud++ considers $(CORE_SOURCES:.pm=.pir) to be a portable enough Makefile expression. If not, there is a more laborious alternative. This would be used to avoid concatenating all the core/*.pm into one file, that currently creates the biggest compile overhead
20:05 moritz_ mberends: I worked on splitting the setting compilation some time ago
20:05 moritz_ mberends: there is a discussion on p6c about that, which is probably worth reading for you
20:05 mberends moritz_: what problems did you encounter?
20:06 jnthn mberends: I'm a little fearful about what this is going to mean for the idea of the setting forming the outer lexical scope of the user's program.
20:06 moritz_ mberends: 09/05/2009
20:06 mberends moritz_: will look in p6c archives
20:06 bkeeler How hard would it be to rewrite make in Perl?  We could have a known, sane make then
20:07 jnthn mberends: If there's no single file there's no single lexical scope to use. And while we could make one by doing an import of all the bits.
20:07 colomon scons?
20:07 jnthn Please no! :-)
20:07 mberends bkeeler, colomon : make is not letting us down
20:07 jnthn oops, sentence fail... all of the bits, that's going to hit us at startup on every run for now.
20:07 |espadrine| joined #rakudosketch
20:08 bkeeler It seems that have to assume lowest-common-demoninator of make features though
20:08 mberends jnthn, moritz_ : what about concatenating or '.including' all the .pir files after they have been generated?
20:08 moritz_ mberends: http://www.mail-archive.com/perl6-compiler@perl.org/msg04770.html
20:09 moritz_ mberends: there are other problems... like lexical interdependencies
20:09 bkeeler You'd have to tweak all the :outers to make one lexical scope
20:09 jnthn mberends: Not that simple...what bkeeler said.
20:09 mberends aargh!
20:09 moritz_ mberends: however class stubbing is implemented now, thanks to jnthn++
20:09 bkeeler Not that it's impossible mind you
20:10 jnthn It's not impossible.
20:10 moritz_ couldn't that be done later on by importing everything from the setting?
20:10 jnthn moritz_: It could, but then we have to do that at every single startup.
20:10 jnthn But maybe that's not going to cost us badly.
20:10 moritz_ ouch.
20:11 jnthn It's going to cost though
20:11 bkeeler Could try it and see expensive it is
20:11 jnthn And our startup time is bad enough already, and it's not quite the way STD, as I understand it, sees it working.
20:11 jnthn OTOH the memory needed to compile also sucks epicly.
20:12 jnthn bkeeler: We could, yes.
20:13 jnthn mberends: I think what maybe the best thing to do is: if you want to work on this, go for it. Let's see if we can make it work. However, I can't promise that it won't have to be undone at some point in the future.
20:13 jnthn As in, in the pre-R* future.
20:14 jnthn (Yes, I'll go to some effort to not need to.)
20:14 mberends jnthn: good idea. Thanks moritz_ for the background info.
20:15 jnthn mberends: So long as you're working on it knowing the risks, that's fine. :-)
20:15 mberends wfm
20:15 jnthn Cool.
20:15 jnthn OK, anything else?
20:16 jnthn I think we've #rs'd for long enough if nobody has any more. :-)
20:16 bkeeler Nope
20:16 mberends ok
20:16 * bkeeler bangs lue's head again
20:16 TimToady o/
20:16 lue Ow! what was that for? I gave you a gavel
20:16 jnthn :-)
20:16 jnthn Thanks all!
20:16 bkeeler gavels aren't as much fun
20:16 TimToady 8==
20:16 PhoenixWright Objection!
20:16 moritz_ let's call it a day
20:17 chromatic joined #rakudosketch
20:17 bkeeler Ah, typical
20:17 PhoenixWright (what other Phoenix Wright things could I (lue) say...)
20:17 bkeeler chromatic waits until we're done kvetching about parrot memory usage to appear
20:17 chromatic TT #1489
20:17 jnthn moritz_: Sadly, you and chromatic are here and masak ain't...
20:18 jnthn moritz_: Though a few moments on book could still be good anyway.
20:19 PhoenixWright yeah, we should redo tomorrow just to include masak :)
20:19 jnthn ;-)
20:19 sorear Is that the only Rakudo memory problem?
20:20 jnthn sorear: Unlikely, but it's the most painful one at the moment.
20:22 jnthn moritz_: Is http://github.com/perl6/book/blob/master/outline.pod up to date as far as you know?
20:22 PhoenixWright ==[ ] here be your gavel bkeeler
20:23 mberends moritz_: are you happy to let me use the split-gen-setting-2 branch for further investigation? (its existing content is pre-ng)
20:24 moritz_ sorry, just crashed my computer
20:24 moritz_ mberends: sure, feel free
20:24 moritz_ re book
20:24 moritz_ I'm trying to get my JSON parser running on alpha
20:25 moritz_ so that I can overhaul the grammar chapter a bit
20:25 moritz_ because {*} is gone
20:25 moritz_ and we want to use proto regexes
20:25 sorear people still use alpha?
20:25 jnthn moritz_: OK. I fixed one bug for you yesterday on that. Let me know if there's a next one.
20:25 moritz_ jnthn: the regex stuff I was talking about earlier
20:25 jnthn moritz_: It seems that chapter 2 has...sort of started to exsit..
20:25 jnthn moritz_: Ah, OK. The match object issues.
20:25 jnthn And so forth.
20:26 mberends sorear: curiously, yes. masak++ has not managed to port much yet either.
20:26 moritz_ aye, I've start with chapter two
20:26 moritz_ somebody badly needs to write about subs
20:26 moritz_ it's tough to find a good example
20:27 sorear a good example of a sub?
20:27 moritz_ we use subs every day, but still it's hard to find an example that demonstrates them well
20:27 lue afk
20:27 moritz_ all interesting aspects
20:27 jnthn I'm happy to write about all the signatures stuff.
20:27 * mberends wants to make a decent book contribution :)
20:27 moritz_ so masak++ and me kinda agreed to use many small examples instead
20:27 jnthn But an overriding good example is quite tricky.
20:27 jnthn Ah, OK
20:27 jnthn I can go with that too
20:27 moritz_ and don't have a leading, big example up front
20:28 jnthn Forcing an example and having a bad one is probably worse than not having one.
20:28 moritz_ oh, forgot to send the signed contract to chromatic++
20:28 jnthn (and going for several)
20:28 jnthn Oh, me too. D'oh.
20:28 jnthn moritz_: I'll try and start on chapter 3.
20:29 jnthn At the weekend at the latest, maybe some evenings.
20:29 moritz_ jnthn: cool
20:29 moritz_ jnthn: I'll try to chime in :-)
20:29 PerlJam heh, now I don't feel bad for forgetting to send chromatic my signed copy for so long  :)
20:32 moritz_ we should all feel bad.
20:33 colomon joined #rakudosketch
20:33 PerlJam I feel bad because I was going to work on the book last week while on vacation, but the vacation won.
20:34 moritz_ anyway, taking a bath &
20:37 colomon ]][
20:37 colomon p'];l
20:39 TimToady kids these days...
20:39 moritz_ kids or cats :-)
21:09 mberends left #rakudosketch
22:02 bkeeler left #rakudosketch
22:08 espadrine joined #rakudosketch
23:04 lue left #rakudosketch
23:38 colomon joined #rakudosketch

| Channels | #rakudosketch index | Today | | Search | Google Search | Plain-Text | summary