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