6.2.11 released! | pugs.blogs.com | pugscode.org | pugs.kwiki.org | paste: sial.org/pbot/perl6
Set by audreyt on 1 February 2006.
00:03 lisppaste3 joined 00:26 frederico joined 00:38 avar joined 00:51 azuroth joined 00:53 stevan joined 01:01 xinming joined
xinming seen audreyt 01:16
obra andreyt mentioned to me yesterday that she is largely offline dealing with work and life these days 01:19
01:22 bsb left 01:31 stevan_ joined
xinming obra: How about the seenbot? go with audreyt ? :-P 01:35
01:35 drbean joined
obra heh 01:35
01:42 b00t joined 02:01 vel joined 02:02 frederico joined 02:09 putter joined
putter stevan: ping? 02:09
Anyone up for a chat by the imaginary whiteboard? Topic: How to get perl6 by April 1st (yes, _this_ year - 6wks) 02:14
02:15 b00t joined
azuroth the imaginary whiteboard, eh? 02:15
putter yes, the one over there. next to the pub. and the munchies. good for brainstorming. 02:16
interested?
azuroth sure. I'm not sure just how much input I could have, though 02:17
obra putter: how do you propose to get the spec finished by then?
putter really needs someone to say "what?!? 6 week? you must be insane!: ;)
obra I believe that's what I said ;)
putter azuroth: awesome 02:18
obra: "perl6" is many things. I mean...
obra waits for it 02:19
putter something which runs everything we believe it should. not as fast as one might wish, but sufficient to use it as the platform in which to rectify that. I don't mean...
that the spec is finished, or that there has been any kind of release process, or anything like that. simply that ever line in the spec actually runs. 02:20
make sense?
obra ah.
that'd be a very cool effort.
putter waits for "but 6 weeks?!?"... ;) 02:21
or "I don't believe that's possible - explain"? 02:23
azuroth I like the second one
putter thinks best with a foil, someone point out bugs and areas which need clarification (like with the "what is p6") 02:24
obra putter: the biggest problem is making sure that you have a good test suite 02:25
do you have any sense of how close pugs is yet?
02:28 drbean_ joined
putter The pugs test suite? distant. how distant depends on what one means by "good". coverage is uneven. some things, eg parser constructs (eg, token, statement_control) are completely absent. somethings, like objects, are quite superficial. some things, like say arrays, aren't too bad. nothing is very intense. 02:29
re "the biggest problem"...
only if you're doing TDD. (test driven development - write test before code). otherwise... the absence of code is a bit of an issue ;) 02:31
given a full language coverage but perhaps buggy p6 implementation, which passes the existing suite, the current limitations of that suite would seem a secondary issue? no? 02:33
though i should note that a subsequent part of this argument is that the implementation is largely written in p6 itself. so one can be fairly confident that at least those idioms used by the implementation are working correctly if the thing can past the test suite. 02:35
kattana_ in 6 weeks there may simply not be enough time to right all the tests, righting higher level test, that require more things to be working to pass might encourge things to speed up?
*writing 02:36
02:36 kattana_ is now known as Kattana
obra I'd argue that writing the tests is the best way to make sure that we have an implementation 02:37
and doing it without tests, I think it just won't happen at all
putter i'm not sure what you just said... ok, "6 wks isnt enough time to write all the tests", and... a question on whether writing "higher level tests" would speed pugs development?? 02:38
obra Sorry. I meant that if you don't think the relevant tests can be written in time, I don't think there's any way the implementation can 02:39
putter obra: re "the best way to make sure that we have an implementation", ah, but I don't claim that (or maybe I did, but I don't just now). simply 1- coverage (everything in the Snn runs), and 2- the existing suite passes. or I suppose and 02:40
obra how is 1- different than what I'm describing?
putter 3- that the implementations use of objects and parser constructs would itself serve as a test of these currently less tested features. 02:41
obra: ah, i see. all the _code_ in the Snn works. confirmation of sentence by sentence compliance would indeed require a non-trivial increase in test size. I guess... 02:43
I'm thinking of sentence-level conformance as being less interesting than coverage, if only because so much isn't specced that even a happily working implementation is likely to become non-conforming with every other sentence added. 02:45
obra putter: yeah. but that's also tests that a lot of people could get involved to write. 02:46
it's a lot easier to write tests than haskell ;)
putter yes.
obra it might help with nothingmuch's concerns that pugs development is slowing
putter but...:)
02:46 rantanplan_ joined
obra even if you start with one syn ;) 02:46
putter my argument is basically going to be that we should do a complete p6 implementation _in_ p6.
obra well, that's certainly audrey's intent 02:47
putter so there is no shortage of p6 writing opportunities...
right. my understanding is the pugs path is basically...
move stuff out of the hs core into p6... unfortunately, 02:48
painful compile time on the Prelude.pm blocked unloading Prim.hs to there, as was the original plan... hmm... 02:49
there was, more that half a year ago(?), the follow up task of making the existing prelude compilation mechanism work with multiple files... I'm not sure if that proved technically impossible, or if the task was just forgotten...?? 02:50
any way, so slow Prelude compilation killed that effort to unload Prim. Unloading Prim is now on the todo list of PILn. Beyond unloading Prim, and likely moving most of the p6 prelude (Array's etc) into p6 as well (I think), there is the question of a p6 implementation of the p6 runtime core. That I think 02:53
is a ways out on the pugs intent timeline. 02:54
My proposal / "hand wavy thingy", is it be moved right up front.
there is a lot of overlap with what will be needed (I want to say soon, but a PIL which understands classes has been "rsn" for quite a while... sortof soon, but probably not in time for an Apr 1 win)... needed for piln. 02:56
the whole object space basically. 02:57
I want the rest of a p6 implementation too (parser, namespace, dispatch) 02:58
etc
because given that, it is *easy* to transform it into a equivalent code in a similarly dynamic and wizzy language (ruby or common-lisp basically). by hand. and write a simple p6 ast crawler which emits say ruby. 03:00
obra, Kattana, azuroth: still around? 03:02
Kattana pong!
putter :)
azuroth I'm listening
obra sorry. busy
putter tnx. np :) 03:03
ok...
Kattana I have absolutly no clue about whats going on with anything or I would say more.
putter ok. but if you have any questions at all, just jump in. explaining things is a great way to think...
azuroth so basically we want all the code in S* to compile without errors, and maybe even do something useful? 03:04
putter yes :) 03:05
p6 being hands-down the best language around for implementing languages. better than ruby or CL or ML or ... . it's one nagging flaw being non-existance. 03:06
we have a language we want to implement. so we try to fudge the non-existence part.
then we can get on with implementing it 03:07
Kattana where is the bottleneck there, not enough fudge packers?
putter on the path through backends like pil2js and the old pilrun on p5, the bottleneck is pugs's pil not providing any class information. mostly. on the path through pure pugs, 03:08
it's the broken class implementation (partially due to some type inferencer bugs I believe). 03:10
so for a while it looked like one might add information on class decls to pil, and the backends could do the right thing. that was the original vision for pil2. now for piln. 03:11
azuroth hmm, okay 03:12
putter the prelude compilation issue I mentioned. So that's why a lot of p6 writing hasnt happened yet, incrementally on existing implementations.
if we had say an unstuck pil2js tomorrow morning... well, there is a lot to be said for building on working code... but the object stuff is only the _start_. ideally, you want to write 03:14
p6 code which cleanly describes the spec. but you have an obstacle course. pugs has to be willing to parse it, and emit it as pil, and then you get to play with it in the backend. and... 03:16
the code you really want to write has things like statement_control:<while> rather than having it built in and hardwired in your parser. so orchestrating the nature of the p6 code, the pugs parser and typesystem and pil emitter, and the backend's implementation, is... performance art. 03:17
BEGIN, \d in regexps, for/while/unless... they are all traits/roles/parser directives. 03:19
most everthing is, since the idea is p6 should be able to evolve.
azuroth up 'til now, I thought I vaguely understood what you were saying 03:20
putter so I'm suggesting that it could be (much) faster to write the code for a p6 on p6, using lots of eyeballs and discussion, and then transcode it, than to fight an incremental battle. 03:21
azuroth: let's see...
take \d in regexps.
azuroth as in, [0-9] in p5? 03:22
putter there is actually a (I dont remember what's called without checking) general \SOMELETTER hook, so one writes... err, macro?... macro mumble:<d> { [0-9] } or some such.
yes
its the same in p6 03:23
but is simply declared in the prelude.
azuroth gee
that's crazy. I guess it makes sense
putter :) 03:24
the key point is, most all of p6 is like that.
while, as in while true { say "hi" }, is simply... something vaguely like... macro statement_control:<while> err... (Match $m) is parsed(rx:w/while <expr> { <statement>* }/) { ... } or something vaguely like that. 03:25
basically, you are filling in the rule statement { ... } part of the p6 grammar dynamically. 03:26
azuroth hmm. I like it. 03:27
putter you do somehting similar with <expr>, where you add tokens (with grammar category token, token:<whatever>, and with the familiar infix:, postfix: etc).
azuroth and it will put out an AST for the thingy to change to whatever backend is necessary? 03:28
putter ok, let's see, ast and backends...
azuroth or my real question I guess was more like, "how do you define if without using if" 03:29
putter first, all backends arent created equal. if we already had a language like p6, env and temp and hypothetical variables... 03:30
ok, will work around to that in a sec...
and compatible multi methods and inheritance and parameter/argument handling, etc, then it would be very very easy to do a backend for it. just crawly the ast, emitting the equivalent code in imaginary language X, and you're done. a few pages of code. 03:31
if one's backend is C... then, well, you have a several man-year project. though perhaps notably faster by _first_ booting p6 on a more appropriate language, and only _then_ attempting the compile-to-C, writing it _in p6_. 03:33
as for if,
azuroth writing the C-emitter in p6? :D 03:35
putter in the p6-written-in-p6 file, the <if> implementation deals with everthing like extracting simple boolean from random objects, and then handwaves. or just calls the usual if. when you do the transliteration to say ruby, 03:36
you just splice in ruby's if there, in the handwave. more generally re bootstrapping...
azuroth hmm, okay
putter the idea is for the p6-in-p6 to be... executable spec, but not necessarily executable in bulk. hmm, perhaps compilable but not necessarily executable. so the ruby implementation can stomp on <if> with it's own prelude, or perhaps just special case if's ast node when doing the compiling... one still has to worry about 03:39
bootstrap, but I'd like to separate it from getting a p6-in-p6 "spec". the spec is hard enough without worrying about bootstrapping. and you wont know just how you want to bootstrap until you see it, and compare it with what your, say ruby, has to offer. 03:40
Kattana It all sounds overly complicated.. though thats the whole problem isnt it. 03:41
putter eg, the spec would just say class Object is Class{} and class Class is Object{}; and multi sub trait_mumble:<is>(...){...}. and once you have all that, you can figure out how to fudge the bootstrap. 03:42
Kattana: just as given p6, it would/will be easy to do ruby/javascript/basic/apl/etc/etc front-ends and runtimes, given p6, it would be easy to do p6. 03:43
03:44 mtgh joined
putter so we currently have the two challenges of 1- writing p6, a non-trivial language, perhaps the most complex of those just listed, and doing it without a working implementation or language standard, and 2- finding some way to run it. ;) 03:46
I'm suggesting that now, perhaps unlike a year ago, one could write a complete p6 in p6. no doubt with a lot of "fill in the unspecced gaps". but still something recognizable as the form of the ultimate p6 implementation 03:48
and the key, vis the "by apr 1", is writing that is completely parallelizable, and requires only p6 knowlege.
so a bunch of people could plow through the spec, talking on irc, generally avoiding (or batching) the slow path of p6l questions by "plausibly filling in the gaps". 03:50
azuroth we can try, I suppose
putter "spec says BEGIN etc are all traits, ok, based on the prototype LEAVE that means...<spew code>" 03:51
azuroth how do we start, then. ;-p 03:54
probably by printing out all the synopses
putter some are larger chucks, like do quick framework for the rules engine (say procs taking global state and a "continuation" similar proc). then lots of folks can fill in the conjunction, the "take longest match rather than first" generator, the backtracking operator-precedence rule generator, the definition-may-change-dynamically rule generator, etc, etc 03:55
hmmm, how to start then...
03:56 reZo joined
azuroth hmm. will rules be a huge priority? we have PGE 03:56
putter my understanding is pge doesnt currently do any of the dynamic specification stuff. so while one might give it say the default p6 grammar (hasnt been tried yet), it's not really taking the approach a p6 parser would. at least currently. so as a bootstrap tool it could be quite valuable. but I don't think it ends up in the final "thing working on apr 1". 03:59
azuroth ahh, okay
putter re huge priority, well, one _could_ write the p6 implementation in an s-exp form of p6...:) but it's kind of painful. 04:00
azuroth s-exp? 04:01
putter and the things that make writing a rules engine not too hard, hypothetical variables for instance, have to be done anyway. once one has all of p6 without a rules engine, the residual amount of work to do a rules engine isn't that big.
azuroth okay then. excellent 04:02
putter (multisub ((category infix) (name "+")) (.... 04:03
azuroth ohhh
putter s-expression. think lisp. without all the extra bits which make real lisp non-trivial to parse.
I suppose you could write the code in yaml... *shudder* ;) 04:04
Kattana you could put it on punch cards if you *really* wanted to. 04:05
putter I'm pretty sure it ends up easier just to do the rules engine. even if some bits make your head hurt for a while (write a operator precedence parser, which you can fail back into to change what is considered end-of-string, and you can fail back into the longest-token-first selector, and...:) 04:06
putter wonders, if you combined p6 with punchcards, how productive would you end up being...?? 04:07
Kattana thinks it would depend on the speed with which you could move punchcards around 04:09
putter Kattana: having to retype lines when you make a typo really sucks. and dropping and having to resort the stack. and changing anything is painful. run away, run away.
ok, re how to start... 04:10
the fast, apr1 form of the exercise, probably requires several people. or one skilled but insane person with no life. 04:11
azuroth apr1?
oh, right 04:12
putter so a group formation process, of bashing around the idea to make sure it isn't cracked, and what its real shape is and how best to approach it, and thereby getting group buyin, and working out how much time and when people can contribute, ie, some real project planning...
azuroth sounds good 04:14
Kattana putter: that 2nd requirement, i think i would fit it, but I still have yet to figure out whats going on.
putter well, tonight's whiteboard exercise is the beginning of "bashing around the idea"... 04:15
04:16 vel joined
putter with your feedback, maybe I'll put together an email "How to have perl6 by Apr 01... 2006". 04:17
I'll see what other folks think as the backlog. 04:18
s/the/they
basically, I think there are lots of people who would like to contribute, if they could see a way to. 04:19
so if a plan was sufficiently bashed at that it seemed likely, drawing people my just happen. leaving the "minor matter" of orchestrating them. 04:20
??? 04:21
azuroth !!!
putter ;)
Kattana where does PGE fit in, and what is its role exactly? im just looking at parrot and PGE at the moment, and there is some very familar stuff.. eerily familiar 04:22
putter I'd probably be more gung ho if I didn't have a $job search to do. Trying to write p6 in a couple of weeks would be fun... but not what I should be doing just now. :/ 04:23
04:23 joepurl joined
azuroth heheh. I'm all for helping, when I can. it looks like this semester of TAFE will be busy, but I should have time to spare 04:24
putter azuroth: neat
Kattana: re pge...
;)
well... 04:25
Kattana putter: you are the one that was encouraging questions. 04:26
Khisanth for parsing perl6 :)
well that was the idea anyway 04:27
putter it's the most working p6 rules engine in existence... (well, in use? Text.Rules exists but isnt wired in)... and thus figures large in incremental development schemes (which the apr1 project isn't)...
and on a parrot backend, one might be able to use it rather than a compiled-from-p6 rules engine... 04:28
but, compiling to pir is _nontrivial_. both inherently, and in that it still requires a dual track of debug generator, debug parrot.
azuroth hmm. good point 04:30
putter for this exercise, the objective is an "easy as humanly possible" bootstrap. which i think technically means ruby or common-lisp, and thus socially means ruby. which means targetting parrot is something which happens later, once one can write it in p6. under the apr1 senario.
so I'm not sure pge helps much with an apr1 project. 04:31
skimming it's code can give some ideas perhaps... 04:32
Kattana: basically, I think gluing to pge, and extending pge in pil, would be far more difficult than simply writing an engine from scratch it in p6, and then transcoding to ruby. 04:35
sound plausible? 04:38
Kattana very, like I said, pge is eerily familiar, I think I could do that if I knew what I was doing ;)
putter right. and that's one aspect of doing a quick push. it would make it easy to 04:41
have one person grovel through the Snn to find the \d definition syntax, another? to hit the rules Snn for a list of the \d \s etc, maybe hit pge to grab the regexps for them, though I'm not sure pge is doing the unicode versions yet, and spew the p6 definitions for them (using a macro or not). but the definition of this 04:44
plan of action, and the selection of some of the design choices, is something easy to do if there are people about, and rather less so in a "go off and do X by yourself" mode. 04:45
04:46 drbean joined
putter also, it would be nice to have some of the folks who follow p6l around, so you can ask "i'm defining uintN as subset uintN of ValueType where { $^o ~~ Int and 0 <= $^o <= 2**N }; does that look plausible?" 04:48
rather than having a much higher-latency loop of writing the code, and then getting feedback hours/days later. 04:49
stevan: btw, what do types look like? Any does Type? is there a subset ValueType of Type where { $^x !~ Object }; ? role Any does Type{} role Type does Any{} class Class does Type{} class Range does Type{} ?? 04:54
Kattana: reading, or rather, repeatedly skimming the Snn, and the few Ann sections they reference, is in the "always a useful thing to do" category. :) 04:56
doing little exercises like, ok, it says LEAVE is a trait/role, where does that role get does()ed, etc. though that kind of exercise is more fun if you're working with someone else. the study group approach to learing stuff. 04:59
I suggest skimming-loop rather than straight reading because random access to answer questions isnt a strength of the current docs, so one may be best off skimming, accumulating questions, which then later get answered in passing. rather than a top down approach. 05:03
putter contemplates having/writing an index to the synposes...
ah well. end of day for me. good night folks & thanks for all your help. 05:05
azuroth good night. hopefully we can get rolling sometime soon 05:06
putter yeah. but in which direction? ;) 05:07
&
05:13 Southen joined
Khisanth eval? my @a = (1..10); 05:27
azuroth ?eval my @a = (1..10);
05:27 evalbot_8956 is now known as evalbot_8958
evalbot_8958 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] 05:27
Khisanth d'oh
?eval my @a = (1..10); [+] @a 05:28
evalbot_8958 55
azuroth I always forget what it is too. @eval, ?eval,... so many choices
Khisanth ?eval my @a = (1..10); ([+] @a)/@a.elems
evalbot_8958 11/2
Khisanth hrm that is not so useful!
azuroth ?eval my @a = (1..10); +(([+] @a) / @a.elems); 05:29
evalbot_8958 11/2
azuroth ?eval my @a = (1..10); ~(([+] @a) / @a.elems);
evalbot_8958 "5.5" 05:30
azuroth hmm. that's interesting
06:00 weinig joined 06:09 stennie_ joined 06:11 Khisanth joined 06:14 r0nny joined 06:20 stennie joined
spinclad putter and whiteboarders: I'd be inclined to target PIL2/PIL^N, already intended to be the point of fanout to various backends. 06:21
(already the second generation design in pugs, based on first-gen backends, and steven and audrey's object model work.) 06:25
PIL2 and/or PIL^N serve as nothingmuch's Perl6Core layer nicely, I think. 06:30
azuroth I like them apples 06:31
PerlJam idly wishes he'd kept up with the PIL work
spinclad we have -- luqui I think? -- working on a port of pge to the pugs arena. not sure which language: Haskell (parsec), PILN, or some higher level of P6.
PerlJam spinclad: audrey was working on a PGE-in-Haskell (using Parsec) 06:32
06:33 drrho joined
spinclad ah, that must be it... 06:33
06:34 GeJ joined
PerlJam It's utterly amazing that a "non-existant" language like perl6 has such a huge following ;) 06:37
spinclad I could see looking to translate that to PILN, then in whatever-perl6-we-can-currently-parse...
a similar sized bootstrap knot to the meta-object one, just maybe... 06:39
I'd call Apr 1 insane; my only question there is _is it insane *enough*?_ 06:43
(and then just go ahead and let deadlines fall where they may)
(oh, and: _am I insane enough to match?_) 06:45
__END_ 06:46
_
lypanov __DATA__ 06:47
spinclad __SPEC__
__CODE__
lypanov "
Khisanth PerlJam: depends on how you look at it :) 06:48
07:17 drbean joined 07:35 szbalint_ joined 07:36 scook0 joined 07:48 pdcawley_ joined 07:57 szbalint joined 08:23 stennie_ joined
Supaplex __SLEEP__ 08:25
08:26 G2 joined 08:45 stennie joined 09:28 j0sephi joined 09:29 gaal_ joined 09:33 Cryptic_K joined 09:41 kanru joined 09:43 gaal_ is now known as gaal 09:51 xern joined 10:09 feng123 joined 10:21 xinming joined 10:37 elmex joined 10:48 ValeFiona joined 11:01 Aankhen`` joined, iblechbot joined 11:16 SamB joined 11:33 bsb joined 12:07 feng joined 12:09 penk joined 12:12 chris2 joined 12:21 dada joined 12:32 theorbtwo joined 13:22 avar joined 13:27 kolibrie joined 13:34 hexmode joined 13:42 feng123 joined 13:46 avar joined 14:04 wilx joined
stevan_ putter++ # your make all use look sane ;)\ 14:04
14:04 stevan_ is now known as stevan 14:10 avar joined 14:15 avarab joined 14:16 icman joined, icman left 14:26 Qiang joined 14:30 bsb_ joined 14:38 rantanplan_ joined 14:41 wilx joined 14:42 vel joined 14:46 drbean left 15:04 ingy joined, gugod joined 15:18 TMTOWTDIt joined 15:25 iblechbot joined 15:46 robkinyon joined 16:29 grayson joined
svnbot6 r8959 | bsb++ | Add env and ::ENV to quickref/namespace. 16:39
r8959 | bsb++ | Fix "let" example to match S04/"Definition of Success".
16:48 sahadev joined
Juerd rafl: Have you arranged travelstuff to .be yet? 17:10
rafl: It's about time we picked a place to stay, by the way
17:32 Steve_p joined 17:37 putter joined
putter stevan: ping? 17:37
I realized falling asleep last night that the organizational difficulties I had with the "p6 prelude to flesh out piln" code was exclusively a limitation of implementations, not p6. Given that sub foo(){ multi sub *bar(){} } only defines bar _when foo is called_, (and using a "redefine" or whatever it's called trait to avoid errors), one can 17:39
can say sub p6_my_way () { sesame_bun_lightly_tosted(); burger_medium_rare(); onions_but_only_if_fresh() } BEGIN { p6_my_way } 17:41
:)
add a sub foo($pkg) { multi sub ::($pkg)::bar ...} and you can inject it anywhere you want. yay.
that of course also makes import very easy to write 17:42
stevan hey putter 17:43
stevan wonders what kind of orange juice putter drinks.. and if it is legal in his state ;) 17:44
putter If the official line is/becomes that bar should be defined at compile time, then one can workaround by simply doing sub foo { my multi sub bar ...; FIRST { *bar := bar } } or some such.
hey stevan
does that look plausible? it makes the "assemble the p6 prelude out of assorted alternate implementations ad backend-specific pieces" quite straightforward, no? 17:46
stevan putter: i think the goal should be to have a universal prelude first
ignoring for the moment the back-end specifics 17:47
stevan is actually pondering giving up PIL^N for PIR
putter *shudder* putter cries "don't do it stevan!"
but taking it in order... 17:48
stevan queues the booming nationalistic music
putter: someone has to ;)
putter re universal relude,
laugh
stevan putter: chromatics point about cost of entry has got me thinking
and I think that if we follow nothingmuch's plan about breaking things up,.. but all the while making sure to keep the implemenations acessible,.. then we might get back the momentum which does (I hate to say it) seem to be lost 17:49
17:49 hachi joined
putter say you are fleshing out the Array methods. there is often a non-obvious choice of building foo on top of bar or on hee. key point: just making that choice, _even if it's always right and never has to be changed_, is harder than just spewing out the two versions. do I build this on splice, or on push/pop? doing both is a seconds work, trying to decide 17:51
which way the Array impl should go is _hard_. and then as just shown, combining the pieces is trivial.
so it's actually _easier_, faster, to write a mix and match prelude, than to try and get a unified set of choices all lined up. 17:52
stevan putter: I dont think we need to make unified set of choices
I think we need to ignore the idea of the multiple backends and create a single prelude for a single puporse 17:53
s/pupose/backend/
putter Ok. then I think we are in violent agreement. ;)
stevan after which it will be much easier to tweak it for a particular backend
:)
Perl 6 has enough facilities to redefine ANYTHING, so we need to worry about boxing ourselves in
putter re recent thread on p6l, I haven't read it. though I backloged irc. 17:54
I agree momentum is lacking
stevan putter: read it if you are procrasinating on your job search,.. but otherwise probably worth ignoring
other than Yuval's mails
which are about the "what we can actually do" part
putter and cost of entry argument is valid, even if not in some particulars, certainly in the "there are lots and lots of people who would contribute if they could, but dont see a way to". 17:55
a people-resource under-utilization state seems clear 17:56
stevan yup
stevan is definitely under utilizing putter
putter one of the things I liked about the apr1-spike idea is that _everyone_ wants to learn p6, and all the work is in p6 17:57
stevan I am not clear on that idea
just ran full force to write it in p6?
what will it run on
what will we test it on?
17:57 iblechbot joined
stevan how do we know its not all broken 17:57
many assumptions will need to be tested,.. approaches hacked out, etc etc etc
stevan dodges peices of falling sky ... 17:58
putter transcode a core of it into a semantically similar language (ruby or CL).
re many assumptions, etc, could you give an example?
stevan hmm
I think only CL would give us the right amount of flexibility 17:59
putter one counter arg to the spike idea is "but we _can_ write a complete p6 implentation in p6 because... something".
stevan but there is our barrier to entry again,.. I mean not as high as Haskell,.. but higher than most
18:00 r0nny joined
Khisanth just do it in C! ;) 18:01
stevan runs screaming from the room... noooooottttt CCCCCeeeeeeee
I would sooner do it in PIR ;) 18:02
putter in thinking ruby v CL, my thoughts were: rb - no macros - makes tree transforms more of a pain. CL - much more verbose; larger appearance divergence vs p6, making transcoding harder. Neither has unification or even good pattern matching. CL has env. but that's easily faked. rb will run sllooooowwweer. so
obra . o O { Perl6 in rails }
stevan :D
obra Just because I want to be difficult, putter: am I missing the bit where you discarded perl5?
stevan hell yeah,.. I mean you can write anything in RoR
obra grins
Khisanth so how many different interpreters and compilers are peopel going to need to install to build perl6? :)
obra is building Jifty 2.0 in rails. 18:03
obra is also pulling your leg
stevan putter: CL has great pattern matching cl-pcre is supposed to be very fast
putter the first order of business for a p6-on-rb is likely to do a p6-to-CL compiler or somesuch. Though rb may be close enough to p6 semantically to do a p6-to-rb compile with not horrible performance (if one can map a lot direct to ruby wo an abstraction layer).
putter backlogs
stevan slips some valium into putters coffee in hopes to slow him down just a little 18:04
oh hey,.. I just realized,.. obra is in boston too,.. we now have our third member of the first NE P6 monger group 18:05
PerlJam stevan: great! Now perl6 will be even *more* delayed!
putter back from call, backlogs
stevan PerlJam: slow and steady wins the race ;)
obra stevan: who else is in boston? 18:06
stevan putter:
and I am in CT
just down the road
putter awesome, NE P6 Monger group established! :) 18:07
re CL pattern match, sorry, I meant structure match. for more declarative tree transforms w/o having to grovel around. but actually, under the current senario, that doesn't matter at all. because p6 doesn't (yet) have it, and the only CL code which get's written, at least in the first/only "let's get p6 running" phase, is transcoded from p6 18:09
obra: re p5 18:10
stevan bangs his gavel - I call the first meeting of the NE P6 mongers group to order,.. who brought the pizza
putter mutters, "oops, I knew I forgot *something*..." 18:11
18:12 bsb_ left
putter p5 clearly has the lowest barrier to entry for our potential-helper pool. 18:12
stevan I am not sure p5 is a good language to write a compiler in though 18:14
that is always been my concern
is P::RD up to the task?
or do we need a Parsec port?
putter but... ok, two parts: ugly/broken/slow, and the transcoding should be a small number of people, short duration, throw away the code afterward exercise.
stevan or even better a Perl6::Rules port? 18:15
putter ugly- both ruby and cl have better metaprogramming. ruby will also be syntactically much clearer. since bug hunting at the "transcode and bootstrap" phase will likely be very painful to deal with, clarity is quite important. 18:16
broken - well, that's too strong. but we'd have to take p5, add a one or more of the class and/or multimethod libraries, and ... at which point one might have a poorly speced version of rb or cl's out of the box capabilities. (oh yeah, rb disadd vs cl - lack of native multimethods) 18:18
obra note also there was the whole p6c effort way back when 18:19
PerlJam was? 18:20
you mean in p5?
putter slow - the regexp engine should use exceptions extensively. it p5... ouch. rb is quite bad enough. (that's another cl add, but oh well). but actually, this is all just rationalization. the _real_ motivator is...
Juerd putter: Ruby has clean syntax, but surprising symantics. I'm not sure if it's good for writing a compiler. In addition, it's slow.
PerlJam How much does slow matter to a bootstrap? 18:21
Juerd PerlJam: Obviously a great deal, as that's the most important argument against using pugs for it.
GeJ hum, pardon me, but when talking about "CL", you mean? Common Lisp?
putter I am confident I can quickly transcode large bunches of p6 code into rb/cl which is no more buggy than the original p6. I am not at all confident, indeed dont think I can, do the same into p5. But maybe that's just me.
PerlJam Juerd: I think that a foolish argument. 18:22
Juerd PerlJam: I see. Then why not use Pugs?
stevan GeJ: yes that is correct
putter GeJ: yes
GeJ thanks
Juerd It has much of the language already implemented, which gives things away for "free", reducing the "cost"
PerlJam Juerd: Is it "complete" enough though?
Juerd Which makes having a somewhat higher "entry level" less of a problem
PerlJam hasn't looked at pugs in a while. 18:23
Juerd PerlJam: I think it is, and those things that need implementation badly, can perhaps be prioritized.
putter stevan/obra: am i synced with you? missed anything? backlogs...
stevan attempts to read putters mind and check......
maybe we need to look at the smalltalk model 18:24
put it all on top of the object model and just compile code method by method to the VM 18:25
obra putter: mostly, I'm just making trouble. I haven't had the cycles to think hard here.
Juerd I think that in any case, it's probably a good idea to wait until Audrey is back. She can estimate better than any of us, if Pugs will be suitable for bootstrapping.
PerlJam 30+ years later and unix is still the best OS model and smalltalk the best OO model ;)
Juerd: I agree.
stevan Juerd: I dont know if it is a suitability issue,.. I think it is (like chromatic said) a barrier to entry model 18:26
work stalls without audrey around
putter Juerd: re surprising semantics, slow. yes. but quite good metaprogramming. semantics - the oddities tend to be avoidable with care. this would be quite stereotyped code. re slow, undoutably. but basically, the only thing it will ever have to run is p6-ast-to-something-else (direct to rb, or cl, or whatever is faster) compiler, "once", over the p6 implementation. then it's trash.
Juerd stevan: But what is worse? Having to re-implement everything that pugs already did, or having that somewhat higher level of entry?
stevan: I don't think that what was done with Haskell in a year can be redone in any other language in two. 18:27
stevan Juerd: pugs is already re-implementing everything pugs did ,.. that is the whole new runcore idea
PerlJam stevan: *pugs* work stalls, but perl6 work doesn't have to.
stevan Juerd: you may be right on that point (the time point)
PerlJam: I know,.. but that is a seperate issue
putter obra: trouble is most valuable. forces things to be explained/thought through. my worst case fallback for "cant find anyone to have a design discussion with" is sometimes (well, once or twice) to fire up Eliza. :) 18:28
Juerd stevan: I equate time to "cost", for easier discussion. This common business model may perhaps not work for open source. I'm not sure.
stevan PerlJam: I do think that speed of work on Perl 6 (the design) is directly releated to speed of pugs development though
obra putter: mostly, I worry that this implementation will take effort away from the other two, which is why I see the test suite work as so valuable 18:29
stevan somet things just need to get tried out before descisions can be made
Juerd I think it'll be valuable to search for optimizations in Pugs.
From what I've heard, there's lots of opportunities to be explored.
stevan Juerd: very true
Juerd I found gaal's FPS suggestion very interesting.
stevan really enjoys spring cleaning :)
PerlJam stevan: sure, but now that there's enough of pugs working, I think there's only a small factor in the relation.
stevan: i.e., there's a direct relation, but the pugs end of it isn't as big as it once was and is, in fact, quite small 18:30
stevan PerlJam: not true re: object model,.. there are some questions I have which had not been answered and I dont think will be answerable until someone (probably me) make a prototype to test it out
Perl 6 is an OO engine - so sayeth S02 ( i think thats the one ) 18:31
Juerd stevan: Why a prototype? I believe that no time is wasted by starting on the real thing, and skipping prototypes, which is quite the same as starting with prototypes and then using them in production, only it results in much higher quality of work.
PerlJam stevan: yes, I know, I was being flippant. It's the mood of my Friday. :-)
stevan PerlJam: :)
Juerd: a prototype is sometimes easier to write because you can hyper focus and not worry about effecting other parts of the system with your proddings 18:32
18:32 DesreveR joined
putter obra: one key point is the "write p6 prelude (Prim.hs plus objects(Array,etc)) in p6" task is both on the piln "next steps todo list", and similarly on a apr1-spike. so one could do that first ;) though the social dynamics of the two are very different. so while it's worth, say me, doing first to explore whether a spike 18:32
Juerd stevan: So can you in the real thing.
stevan Juerd: meta-models have a tendency to dive into infinitely recursive recusion if you poke them the wrong way 18:33
Juerd putter: whether a spike$
putter is posible, I wouldn't want to drum up group activity unless people had examined and bought into a spike model. getting lots of people excided, and then hitting "but piln can't really run it, and pugs can't really parse it", would be a no-no.
Juerd stevan: Then perhaps making mathematical models out of them mathematically proving them is a good idea. I think luqui is strong in that area.
stevan Juerd: $proof != $working_code though 18:34
Juerd stevan: No, but if you have proven something, you probably know what way to poke it :)
stevan Juerd: most of the details which I am talking about are closer to implementation details anyway,. and not theoretical anyway 18:35
Juerd I see
stevan Juerd: its the meta-circularity that gets you,.. which is not very math-like (or so I have been told)
putter stevan:Juerd: perhaps I shouldn't say "p6". how about, an acceptably performing bootstrapped implementation of pX. where pX can tightly follow the changing spec. 18:36
I think of the details as less important than bootstrapping. In fact, one idea for an apr1-spike is _no requests for clarification_. Perhaps no great effort even to extract clarity from the Snn. What matters is a _flexible_ (ie, pX) implementation _running_. Then the rest, syncing with Snn, etc, becomes easy. 18:38
Juerd putter: I fear you're speaking on a somewhat higher language than my parser can handle. 18:39
putter Hmm, maybe that's a core argument: "we have enough to bootstrap now, and a bootstrapped pX is the most appropriate place for rapid further development".
stevan Juerd: I think we all feel that way about putter sometimes ;) 18:40
stevan wanders off to handle some $work business ... be back later
PerlJam putter: you'd better get more of a concrete noun than "pX" if you vet this on p6l :) 18:41
putter Juerd: ok, and stevan: :) the argument is 1-we can currently, with reasonable effort and good use of people resouces, create a self hosting (implemented in itself) implementation of pX, where pX is a language similar to that currently in the p6 spec docs. and 2- such a language and implementation is a good (best?) platform for developing p6. 18:42
audreyt putter: I parsed you, and I agree. :-) but it's 2:41am and I'm totally burnt out from $job, so I'm afraid I can't help you much on elaborating this though stream :)
s/though/thought/
putter Bascially the "p6 is platform for developing hypothetical ideal language p7" argument shifted. "pX is the platform for developing a hypothetical nifty language p6". ;) 18:43
PerlJam putter: s/pX/pugs/ and we're good to go :)
putter audreyt: lol :) neat! 18:44
stevan putter: I totally agree, the question is what will pX run on?
putter has to go off for lunch soon anyway. but I'd love to hear your thoughts at some point.
audreyt (I parsed you as: "instead of limiting ourselves to prelude, write _everything_ in the p6 as supported by pugs, and focus pugs's Hs toolchain to compile that subset into something that runs in reasonable space/time"
)
Juerd putter: And why could this pX not be p5 with additions? 18:45
PerlJam Juerd: because there would be too much work to do in p5.
audreyt where the everything includes but not limit to the object space, parser, semantic analyzer, etc.
Juerd I see
PerlJam Juerd: and it would be like starting form scratch again with a slightly broken (perhaps mismatched is a better word) tool 18:46
in other words, I (at least) don't think p5 is the right tool for this job.
audreyt putter: although, to fruitfully write the compiler (tree transformation) part in perl6, we still need to get 6.281.x level support -- i.e. with sane roles and rules support
putter audreyt: ah, no, there's a key divergence/point. I'm proposing that discarding the limitation of "p6 as supported by pugs" buys so very much, that it's worth losing the ever valuable "keep the code running" and doing a pure p6, unconstrained by implementation, spike. and then transcoding bits of it at the end, to get back to something running.
audreyt putter: I think we are in vehement agreement. 18:47
I meant:
pretend we have 6.281.0.
and write a p6 compiler in p6 targetting that.
PerlJam audreyt: so putter's "implementation spike" == 6.281.0 ? 18:48
audreyt and meanwhile, either improve pugs's support, or (as you said) selectively desugar it in adhoc ways back to something (ruby? parrot? clos? pugs?)
to get it running in the end
putter ah, yes :)
audreyt PerlJam: I think it makes sense. writing a compiler in a dynamic language that has no typechecking semantics is possible 18:49
and the compile-time type semantics is too unreliable at this moment
s/unreliable/unspecced/ 18:50
PerlJam works for me.
18:50 dduncan joined
audreyt that even if the spike is to be written with advanced type features, we wouldn't agree enough to make it work productively 18:50
(unlike the OO/rules part, where we could agree how they should work on the surface)
PerlJam though it suddenly feels like we're talking about bootstrapping perl6 by using N languages rather than just 1 and that's a little weird.
audreyt PerlJam: but in effect, each milestone of Pugs is a different language 18:51
(or at least that's how I perceived it to be)
dduncan gree tings
PerlJam audreyt: yes, that's the way to look at it.
audreyt: I just didn't get there until a few minutes ago. :-)
audreyt putter: so... this is very exciting :) 18:52
putter PerlJam: it's more, just write p6 in p6. including a compiler to whatever-easy-target. then handwave magic briefly. and then it's running, and self hosting, and you can forget about the magic.
audreyt putter: but the p6 you write p6 in is p6-as-we-understand-today
that is, without luqui's type magicks 18:53
or advanced ast-transforming macros
but with everything else
putter yes. but the parser and oo multi models seem flexible enough to arbitrarily evolve pX, no?
audreyt sure... we are in vehement agreement. :)
putter :) 18:54
PerlJam And pmichaud and Allison's work provides a nice counterpoint?
putter pictures the amount of work involved and wishes for someone with an insightful "but that wont work / doesnt make sense because..."
;)
audreyt PerlJam: counterpoint to what? :)
PerlJam to putter's imagined workflow. 18:55
audreyt is feeling very rejuvenated -- just finished reading a draft "history of haskell" paper by Hudak/Hughes/SPJ/Wadler
titled "Haskell: the dream that stuff is made of" 18:56
putter oooh, neat. online? or behind the evil ACM DL event horizon?
PerlJam Perhaps it's just me, but I see what pmichaud is doing as more of "traditional compiler writing" and what putter/audreyt just described as "post-modern compiler writing" (if I can borrow from Larry ;-)
audreyt putter: no, private copy :)
and GHC went through this early imaginative-bootstrap (over a very slow and very leaky LML-hosted bootstrap) long ago 18:57
putter oh, draft. neat. look forward to it.
audreyt with help from some very adhoc desugaring evail scripts written in p5
s/evail/evil/
18:58 r0nny joined
putter ah, I was wondering where the p5 involvement in ghc came from 18:58
audreyt it would be like your planned use of ruby ;)
not yet convinced it'd be neccessary, but I'm cool if it turns out to be useful. 18:59
putter: ok. so, how's your cycles looking like in the next 40 days? :) 19:00
putter yeah. it would be simpler if one could transcode to p6-as-running-in-pugs. I'm specing ruby mostly because it has lower risk / "gotcha" potential. It seems clear one can do a rb transcode. with a pugs transcode, one might hit something which requires non-trivial pugs implementation changes to work around. rb is a more distant, but firmer platform. 19:01
re cycles... I really have to think about that one. I'm just not sure. 19:02
audreyt I'm thinking of transcode to yarv. 19:03
maybe we can get sasada or matz on the yapc::tokyo hackathon.
(which would dramatically speed up this)
s/tokyo/asia/
19:03 binary42 joined
audreyt putter: in any case... I'd like to make p6 a good language to write compilers with :) 19:04
(which would be this spike's primary contribution to the ongoing design evolution, if nothing else) 19:05
putter I suspect (I think) that the transcode target mostly affects the "oh, no, try to keep that section of code simpler since we'll have to transcode it" choices of simpler. I'm not sure how much variation that actually introduces. and the transcode target needn't be the first pX compiler target.
audreyt no, but it makes more sense (and is more smooth) if it could be. 19:06
putter yes
err, yes, to earlier line, re "no, more sense"...
audreyt (and as long as you are transcoding, p5+MOP is no worse than ruby really.) 19:07
19:08 penk left
audreyt since you wouldn't touch the surface syntax; it's all codegenned 19:08
and ruby isn't that easier to gen than p5.
(as compared to read/write by humans, which it could be significantly easier)
obra MOP?
audreyt meta-object protocol. 19:09
obra ah
putter re "no, more sense"... I'm not sure. the constraints the two operate under (human transcode of small bits and eyeball similarity, vs easy to write in working p6) are quite different. also maybe the time frame for when they get written. the main thing they could share is the design discussion/though of how to target the platform. 19:10
audreyt right. so whatever works works :)
putter: are you going to write this up in a more structured english text? 19:11
putter :) re code gen, codegen leaves me with a "it should work, but I wouldnt really bet my arm on it" kind of feeling. I was thinking that the bit which needed to be transcoded was small enough that one could actually type it by hand.
audreyt putter: ah, but there is this gray zone between full-parse-compile-codegen and transcode-by-hand 19:13
namely, adhoc rewrite rules, with regexes
(think your average html scraper.)
putter re write, this up... yeah, I should. ok, I'll try to get something out today. we still haven't talked about the social and logistical stuff of trying to make it happen fast. actually, what aspects would you like written up? putter ponders...
19:13 rantanplan_ joined
putter audreyt: re rewrite, agreed. 19:13
but yes, I can sketch out the argument I've been running. then we can fiddle from there. 19:15
audreyt I'd like a problem statement; a requirement statement; an overview of the spike's architecture (i.e. plan of attack); and then it's a matter of writing up the docs/interfaces for the components.
the latter part I already agreed to do with nothingmuch/gaal in israel; I'd also love to annotate it with spike p6 code.
putter isnt sure there are docs/interfaces or components ;) 19:16
audreyt the spike p6 code... is the docs/interfaces ;)
at least that's how I write my CPAN modules.
this one wouldn't be different :)
(to elaborate: I think the toplevel API, as expressed in p6 module syntax, makes good interface spec.) 19:17
putter it would be nice if the implementation could be kept "light weight", few files in flattish directories. so it would be easy for anyone to copy a couple of them, mutate them, and say, "this is what I had in mind". almost a linux like process. 19:19
stevan is back from doing $work stuff
putter: why is transcode better than codegen?
stevan ponders a set of p5 scripts to desugar p6 code and what that might ential 19:20
audreyt stevan: codegen implies full semantic parsing of the px
which is considerably harder
stevan true
what if we did several desugaring passes
audreyt so transcode (via adhoc regexes and/or wetware) is a mean of winging it
aka champagne prototyping 19:21
(which is another SPJ paper -- this one is sillier, but still fun)
stevan and eventually arrived at something that looked like the p5 object prototype code??
putter I guess I'm also thinking of a more bottom-up than top-down design approach. we know what, say, the declaration of \d for regexps should look like, it's in the spec. so writing a little macro and fleshing out all of the \X's can be done, without having any idea how that will get integrated into the regexp engine.
audreyt stevan: er, that's what I meant by "p5+MOP is as valid as ruby as transcode target"
putter The regexp engine can just assume it's given a list of such things. and the final rxmumble:<X> macro can glue the two together. 19:22
audreyt putter: yup
stevan audreyt: BTW - Class::MOP now does Scala style mixins (although that version is not on CPAN yet)
audreyt stevan: you're crazy
stevan audreyt: very simple actually,... easier than roles ;)
audreyt it's easy to implement something when you know what you are implementing l;)
stevan i needed something to avoid metaclass incompatibility issues
so audreyt before you go to sleep,.. what is the rough .il hackathon schedule,.. I want to carve out some time in my schedule 19:23
audreyt let's see 19:25
putter so rather than components and apis, I was thinking more along the lines of pour spec into p6 code, which should be implementation-design independent. and then fill in the gaps with something plausible. some chunks like the overall architecture of the parser could use a doc.
audreyt starts at 15th
is the prehackathon
putter: but those are components and apis :) 19:26
anything that is relatively independent of other chunks should be split out
putter yeah, but they are emergent, they don't get speced before hand.
audreyt and what I was saying is, that the emergent p6 spike code would serve as the defacto spec/interface. 19:27
putter and one can imagine having simultaneous - "oh, we need a lexical namespace system. who feels like sketching one... ok, C looks good, lets add mumble from B, and go...". 19:28
audreyt stevan: the real hackathon is 21-25
putter: yup
putter: basically, force^Wnudge^Wencourage p6l to talk in code. 19:29
which, $deity be blessed, would be a Good Thing.
putter ah, ok. thought you were looking for api's and component breakdown in the hypothetical thing to be written today.
gaal hola
audreyt putter: er no, "then it's a matter of writing up" means "after you write this thing today, we can start playing with"
gaal backloggeth 19:30
stevan hey gaal
audreyt sorry for the mistextgen
gaal hey mr stevan!
audreyt stevan: conf is 26-28; if I get visa in time, GPW will follow and then it's a 10-day hackathon with leo
stevan cool
putter there _are_ advantages to being unconstrained by an implementation. paper vs metal airplanes an all (design phase vs construction phase). I haven't been involved enough in p6l to comment on whether the balance could fruitfully be different..
audreyt stevan: if I don't, then it's another 12-day israel posthackathon 19:31
gaal and if you get it at the last minute, it's a packathon!
audreyt heh
gaal is .il secured?
audreyt yup
single entry
gaal whew
audreyt ok... I need to sleep really. it's 3:30, and I have this laser operation thing booked in the morning. 19:32
I'll check back later :)
gaal laser operation? eyes?
audreyt nah, removal of facial hair
gaal take sunglasses with you on your trip if so
obra my friend rachel's been doing that. "fun"
audreyt waves & 19:33
gaal night!
stevan nice
thanks for the dates audreyt :)
putter good night & (and I'm about to be distracted for a bit)
gaal thinks it'll be possible to get away with visas from here 19:34
19:53 arcady joined 19:57 hcarty joined 20:08 larsen joined 20:28 hcarty left 20:38 cm joined
cm yo 20:38
ingy seen whiteg?
PerlJam I just looked at the PyCon schedule and it seems they only have development stuff after Sun Feb 26. The conference proper is from Thu Feb 23 to Sun Feb 26 20:52
oops 20:53
21:15 rantanplan_ joined 21:29 Shillo joined
Shillo Hullo, all! 21:29
21:31 kanru joined 21:32 KingDiamond is now known as KingDiamond|away 21:39 DesreveR joined
rafl Juerd: Not yet arranged, but it's planed and I'll be there. 21:40
21:40 DesreveR is now known as r0nny 21:45 Medvekoma joined 21:47 jsrn joined
putter ok, I'm going to grab some dinner, and then draft up a pX project sketch. hopefully run it by anyone who is still awake for comments. 21:55
21:58 diotalevi joined
putter goes to briefly read the "streamlining" thread on p6l. realizes "briefly" isn't going to cut that... 22:01
Shillo putter: :) :)
22:12 justatheory joined
putter audreyt: I note www.nntp.perl.org/group/perl.perl6....uage/24658 didn't like your email encoding ;) 22:12
nothingmuch++ 22:16
nothingmuch: I realize you are probably off snowboarding by now, but it would be great to talk. 22:17
pX and your proposal have the same objectives and motivation I think. my very quick impression is the divergence is part technical (sacrifice "keep the code working" to avoid "have to implement in haskell first") and one social (do an intense short-term project with flexible code "ownership" independent of 22:21
section-of-perl6 (eg, no foo owns Bar::Hee, the thingamagic implementation), vs doing the more traditional project decomposition you describe). 22:23
s/one social/part social/
ideas on social scheme will be in pX sketch. though if anyone is around who wanted to ask questions...? ;) 22:24
guess not. ah well. bbl & 22:28
oh, and social/techical - a non-monolithic code set. think you have a better way to implement widgits, code it and toss it into the pile. it looks like extracting a coherent set of code from that pile is something that can happen whenever convenient, even as late as compiletime. 22:31
btw, if anyone, at all, doesn't buy any part of this, or has any questions, however "dumb", please please please say something. it will, at a bare minumum, help us understand what we are doing, and thus help us do things differently/better. thanks. 22:35
dinner. bbl
will backlog :)
Shillo putter: Er.... 22:36
putter: Can't read my normal email now... where's that document?
Ick, too late. :) 22:40
22:45 pdcawley_ joined 22:51 Shillo left 22:54 knewt joined 23:03 DigitDuke joined, DigitDuke left 23:28 drbean joined
Juerd I made the same syntax mistake 5 times in Perl 5 today. 23:36
map { }, list
wilx :) 23:39
You need to take a break.
23:47 drbean left 23:48 Cryptic_K 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!