6.2.11 released! | pugs.blogs.com | pugscode.org | pugs.kwiki.org | paste: sial.org/pbot/perl6 Set by audreyt on 1 February 2006. |
|||
szbalint | hehe | 00:05 | |
00:15
larsen joined,
TMTOWTDIt left
00:32
azuroth joined
|
|||
putter | back. | 00:51 | |
Shillo: no email, I've just started scribbling. well, it's been a few minutes now. I'll paste what I have so far... | 00:52 | ||
hmm, do we have a backup paste server? sial is erroring... | 00:53 | ||
01:10
theorb joined
01:22
stennie_ joined
|
|||
putter | anyone around? | 01:53 | |
obra | not very | ||
putter | ;) | ||
can I quickly run an idea buy you? (drat, I should really paste it. wonder where there's a working paste...) | 01:54 | ||
obra | paste.husk.org | ||
putter | hmm. doesnt look like it has p6... oh, paste.lisp.org has it | 01:56 | |
lisppaste3 | putter pasted "pX strawman" at paste.lisp.org/display/16673 | ||
putter | so, I'm wondering what you think of the misc/pX/ with Common/ and obra/ and attempting collaborative coding. | 01:57 | |
or any other thoughts/questions/observations/comments you might have too | 01:58 | ||
02:07
feng joined
|
|||
obra | ok back now | 02:08 | |
putter | :) | ||
obra | So, the "draw a line in a sand" implementation is a feature of all the current plans ;) | ||
but actually drawing that line is useful | 02:09 | ||
putter | "line" apropos changing spec? hmm, yes. pX would be a complete uncertainty waveform collapser. :) | 02:10 | |
02:11
justatheory joined
|
|||
obra | yes | 02:11 | |
putter | not vis p6 of course. but it would establish an anchor point somewhere between p5 and p6. | ||
even if modules/roles/classes vanish or mutate into something else, most all of the code could be reused. | 02:12 | ||
and that's a rather extreme senario. i think. | 02:13 | ||
obra: any thoughts on the whole misc/pX/Common/ idea? | 02:14 | ||
or questions? | |||
obra | still parsing | 02:15 | |
putter | ;) | ||
obra | I don't understand the point of not just having a common codebase | 02:17 | |
putter | Basic objectives are to have very low overhead contribution, and permit tiny bitsized contribution, and permit collaboration, while simultaneously retaining the ability for people to pursue... (a question! :) | 02:18 | |
common codebase as in monolithic? single Array.pm ? | |||
universally applied set of design choices? | 02:19 | ||
obra | I think it'll make more work and promote duplication of work | ||
putter | oh, not having private playpens? | ||
or the whole ownership concept itself? | |||
Basic objectives are to have very low overhead contribution, and permit tiny bitsized contribution, and permit collaboration, while simultaneously retaining the ability for people to pursue incompatible visions, and avoid the "committee needs to reach consensus - which is way costly" problem. | 02:21 | ||
Basically, I hypothesize people will converge if given the chance, but mechanisms to force "early" convergence will just raise barriers to entry. eg, "single copy means you care about it's quality which means you have to be careful about changing it which means if your a newby you dont want to do anything and if experienced the cost of a partial fork to | 02:24 | ||
try something better is high". | |||
eg, arguing about which of two things is the "right thing" can often take longer than just coding both and finding out later who was right. and often the right thing ends up being "a bit of both". | 02:27 | ||
the private directories are just there because... sometimes you just want to fiddle, and we get more synergy if that happens in the common tree where people can see it rather than at home; some folks have reluctance to do "public coding" and i thought private-control-but-visible might help. | 02:29 | ||
if everything ended up untagged in Common, that would be great. I just don't want the p6 namespace or components to be a proxy for zones of editorial control. | 02:30 | ||
02:33
scook0 joined
|
|||
putter | hopefully the visibility (eg, "what do you mean you didn't see luqui's draft regexp engine core in ext/Perl6/something/mumble/frotz?") and folks' disinclination to duplicate work would keep waste down. | 02:35 | |
obra: sound plausible? | |||
One possible problem is I'm not sure how well it deals with folks who approach complexity by creating hierarchies of little files. When things are in flux, I tend to suck everything whose edges are unclear into a few large files. I don't have a clear idea how messy or (un?)usable a Common might become. | 02:39 | ||
obra: was that the kind of think you had in mind as creating more work, and duplication of work? | 02:40 | ||
obra | backish | 02:57 | |
I think that an official policy of collective code ownership will help deal with the issues | 02:58 | ||
Anyone can always create a personal branch | 03:00 | ||
but continuous integration is a win | |||
putter | agreed | 03:07 | |
what would you do differently? do all development in ext/? | 03:08 | ||
obra | I'd argue for collaboration to be the default. All dev goes in ext/Px. | 03:09 | |
putter | what is in ext/Px? a lib/ and a usual Foo/Bar/Hee.pm tree? | 03:10 | |
putter was just about to hit return on committing a strawman misc/pX/... :) | 03:11 | ||
obra | dunno. | 03:12 | |
putter | k | ||
hmm... | |||
obra | i bet you should start by just committing enough code to eval say 'hello'; | ||
putter | err... huh? | 03:14 | |
putter wonders if he has been just soooo completely unclear... | |||
the current pX senario has nothing running until the very end. (that's an oversimplification, but sortof) | 03:15 | ||
write a p6 spec as text which just happens to be phrased in p6. "only" when it's done does it get massaged and magiced and start running. | 03:17 | ||
obra | oh god | ||
putter | *lol* loudly | ||
obra | I think that's a scary concept | ||
no validation until the end | 03:18 | ||
putter | yes | ||
obra | people need to be able to see results in order to contribute | ||
putter | good, someone to share the fear with. ;) | ||
"results" consists of converting fuzzy Snn to concrete code? | |||
no? | 03:19 | ||
obra | runnable tests | 03:20 | |
putter | dont think people with feel they contributed if they dont see runnable tests? or think without running tests it will be impossible to maintain quality control? or both? | 03:22 | |
obra | the latter certainly | 03:23 | |
putter | yeah... it would certainly require some... oversight... | 03:27 | |
but that's the pX idea. sacrifice having running tests for being able to use full p6 (in which it is soooo much easier to write p6 than in the currently implemented subdialects) and not having to keep an implementation working along the way. use the thus lower barrier to entry to get more people, and that and the effort freed up | 03:31 | ||
to be more disciplined about code reviews and such. | |||
03:34
grayson joined
|
|||
putter | obra/anyone: other thoughts? | 03:44 | |
I think I'm going to just re paste an edited strawman, incorporating that last bit of our conversation, and wait until tomorrow (now+12ish hrs) to see whether to commit a strawman misc/pX/. | 03:45 | ||
obra | I'd just start writing code. | 03:46 | |
show people how easy and rewarding it is | |||
rather than look for consensus, lead with code | |||
putter | hmm... ok... | 03:48 | |
03:48
stennie joined
|
|||
putter | too late tonight for me to do much code, but I'll commit the strawman misc/pX/ . it can always be mv'ed or rm-rf'ed if in the light of day it doesnt seem like the right thing. | 03:50 | |
Steve_p blinks | 04:24 | ||
svnbot6 | r8960 | putter++ | Strawman misc/pX/ created. Mostly just to illustrate/explore the concept. Note that the concept of a pX project, and of a misc/pX/ directory/development-style, are distinct concepts. | 04:41 | |
putter | audreyt: well, it's nowhere near to being "a problem statement; a requirement statement; an overview of the spike's architecture (i.e. plan of attack)", but here are some scribbles, pasted: | 04:42 | |
lisppaste3 | putter pasted "some pX notes" at paste.lisp.org/display/16677 | 04:44 | |
audreyt | I second obra's idea; waiting for consensus never works without code | ||
obra | audrey! good morning! | ||
putter | audreyt: shouldn't you be, like, sound asleep? | ||
audreyt | and even with running code, rough consensus is better than full consensus | ||
putter: no, it's 1pm for me | |||
putter is sooo confused. | 04:45 | ||
audreyt | I slept for 5.5 hours, woke up and went to do the laser operation thing, and just went back home | ||
obra | audreyt: alex and I would greatly like to do some perf work on Jifty. Do you have sage words of wisdom for dealing with DProf's craziness? | 04:46 | |
audreyt | obra: don't use it? | ||
putter confused the state of an unrefreshed irc log with world time. go figure. | |||
audreyt | (Devel::Profiler) | ||
obra | Devel::Profiler seems to give...less than accurate results | ||
audreyt | hrmph | 04:47 | |
obra | yeah | ||
"no, jifty is not spending all its time in App::CLI" | |||
audreyt | Devel::Profile? | ||
obra | That was what I was just trying, but it seems to break standalone entirely | 04:48 | |
audreyt | or, more esoterically, Devel::OpProf? | ||
obra | heh | ||
audreyt | havn't used that myself though | ||
Devel::SmallProf may be promising | 04:49 | ||
I mean Devel::FastProf | |||
obra | Oh. I think Devel::Profile may break STDOUT | ||
audreyt | FastProf is perline | 04:50 | |
and as such may work better | |||
obra | I haven't tried FastProf. I'll have a look | ||
audreyt | another thought is to disable M::Refresh | ||
"bootstrap early, bootstrap often" | |||
obra | Apparently, the issue is the dispatcher | ||
with "last" exiting a sub | |||
Khisanth | putter: you thought time stopped because of IRC? :P | 04:51 | |
audreyt | obra: ahh, I'm guilty of that | ||
obra | :P | ||
audreyt | obra: you can convert it to CPS, or just use exceptions | ||
exceptions may be easier | |||
obra | *nod* | ||
audreyt | though CPS has the advantage of not confusing the $@ state | ||
obra | was hoping not to have to recode | ||
audreyt | use die/eval{} then | ||
should be a three-line change | |||
obra | *nod* | 04:52 | |
audreyt | putter: the "wait no TDD" answer is weak | 04:53 | |
putter: pugs's t/* _is_ the TDD | |||
putter: and it's not unimaginable to have part of the components running and hook it to pugs core | |||
putter: like your &rx_ thing | |||
putter | audreyt: yeah (# re concensus #). but running code mostly happens only at the end in the pX senario. :/ Anyway, there is are some pX notes, apparently rather opaque, just pasted. also a copy in a strawman misc/pX/ . comments on either (from anyone - hint hint) most welcome. almost end of day for me. | ||
audreyt | putter: then we can test that with t/ | ||
putter: I think it's a valid approach | |||
part of the good thing about pugs is that it's very bridge happy | 04:54 | ||
thanks to FFI-enabled embedded interpreters -- we can also shuffle RPC via YAML if needed | |||
putter: so i'd argue it is in general plausible | 04:55 | ||
putter | re being able to use t/ before bootstrap... yeah. I'm just not sure how much of the pX implementation one will be able to do that with. or how much massage it would take. it seems more like the potential for reality checks, rather than TDD... no? | 04:56 | |
audreyt | true. | 04:57 | |
I'd call the project p6p6. | |||
easier to type than pX | 04:58 | ||
and is clear about what it does | |||
putter | p6p6?? err... clear... no doubt I'm missing something obvious... but, huh? | 04:59 | |
obra | putter: see pypy | ||
putter | ahhhhh | ||
:) | |||
audreyt | or maybe p6boot. | ||
I think p6p6 is cuter | 05:00 | ||
obra | sixonsix | 05:01 | |
audreyt | 6on6 | ||
p46656 | |||
putter | lim -> 6.. lim6 | ||
audreyt | p6+i | 05:02 | |
or just p6i | |||
but that conflicts with the mailing list | |||
so maybe still p6p6 :) | 05:03 | ||
putter | lol | ||
audreyt | in any case... I'm excited :) | ||
two more days until I'm free to hack on this | 05:04 | ||
putter++ | |||
now I need to go back and finish translating Luna | |||
deadline is in 48 hours :) | |||
obra | good luck | ||
audreyt | *wave* & | 05:05 | |
putter | the "pX" got introduced when it was clear the objective of the project was not to produce a runninng p6, which is as yet undefined, but rather some p6-like language, which could eventually evolve into p6. it seems somewhat odder to say, yes mumble is in the p6 spec, but were not doing it in p6p6, but it will be done after p6p6 is done, and can then evolve towards p6. eep | ||
s/was clear/proved unclear/ | 05:06 | ||
Kattana | p69 ..booting itself | ||
putter | *wave* | ||
midnight here | |||
Kattana: re irc... yeah, rather than figuring out everyone's timezones, I sometimes just fall back on irc log deltas. so the log says N, and audreyt was going to sleep at M, and N-M is small, so... | 05:08 | ||
audreyt | putter: pypy doesn't implement the full python spec in the first either *shrug* | ||
putter | which sort of breaks if the log freezes at N | ||
audreyt | s/in/at/ | ||
putter: as long as p6p6 is not actively breaking the spec in deliberately incompatible ways | 05:09 | ||
calling it p6 is justified, imho | |||
putter | true. I guess I was thinking in terms of naming the project, which goes away, rather than the artifact created, which contines. | ||
audreyt | if I learned anything... your project goes away far later than you'd hoped | 05:10 | |
putter | *lol* | ||
audreyt | so a name that sticks is important :) | ||
as an aside, in their paper SPJ calls p6 a "ferociously difficult to implement" language | |||
putter | true. and more than a little frightening. | ||
audreyt | coming from the renowned wizard language implementor, that was also a bit frightening :) | 05:11 | |
Kattana | but think of the fame and fortune to be gained taming the beast. | 05:12 | |
putter | awww. that's mostly just because the state of parsers is still a 1970's-ish unmitigated disgrace. | ||
audreyt | putter: actually... I don't think so | ||
putter | otherwise we could have been bootstrapped on say CL years ago. | ||
no? | |||
05:12
drbean joined
|
|||
audreyt | mixing lazy and eager evaluation, static and dynamic typechecks, as well as prototypes vs interfaces | 05:12 | |
are all active research problems which has no clear solution | 05:13 | ||
(or indeed prior arts that works) | |||
putter | true. tunnel vision - I was just thinking about the initial bootstrap. in which a lot of that needn't work, and nothing need be fast. | ||
audreyt | GHC pioneered type-based compilation by using Fw as its internal calculus; p6's semantics has no easy mappign to existing calculus | ||
putter | long road ahead... | 05:14 | |
audreyt | yeah. which is why choosing only the dynamic part of it -- the ruby-compatible part, so to speak -- makes sense | ||
to write p6p6 with | 05:15 | ||
putter | it's taking time for that to sink in... SPJ calls p6 a "ferociously difficult to implement" language... oh my, what have we done? ;) | ||
audreyt | one of the main drawback of writing a compiler in dynamic language is that you lose compiler validation | ||
but for p6p6, that drawback is inherent | 05:16 | ||
putter | right | ||
audreyt | since we don't have a compiler that can validate 6.2831 p6 anyway | ||
so it makes perfect sense | |||
05:17
penk joined
|
|||
putter | you had to go, so feel free... re p6p6, | 05:17 | |
audreyt | anyway... you should sleep and I should work :) | ||
ttyl tomorrow | |||
putter | ah, ok. | ||
quick point is just that one could do a p6p6 like thing, without taking the "detach from testing to use full p6" approach. one could instead try to leverage of pugs into a pil2js or ruby impl. | 05:18 | ||
s/of pugs/off of pugs/ | 05:19 | ||
eg, teach pil2js to parse. | |||
so agreed targeting a dynamic platform is a good idea. it's less obviously clear whether being non-incremental is the best way to do it. that part of the argument hinges on social issues as much as technical ones. | 05:21 | ||
audreyt | I have an epiphany | 05:23 | |
a voice tells me that the project's right name is p6p5 | |||
putter | anyone who wants to svn up and look at what's currently called misc/pX/, or just look at rt.openfoundry.org/Foundry/Project/...pX/Common/ , (putter pauses for epiphany) | 05:24 | |
audreyt | I can explain, but the holistic realisation nuked my verbal cortex | ||
putter | *lol* | ||
obra | audreyt: wasn't p6p5 better known as p6c? | 05:25 | |
audreyt | obra: this is a perl 6 compiler that compilers perl 6 code to perl 5 written in perl 6 | ||
putter | sounds like fun. but perhaps not the best thing to happen when headed out to $work ;-) | ||
audreyt | obra: not a perl 6 compiler that compielrs perl 6code to parrot written in perl 5 | ||
05:26
vborja joined
|
|||
putter rubs his eyes and tries those sentences again... | 05:26 | ||
obra | nor a p6 compiler written in perl5 | ||
audreyt | yup | ||
it's the same idea as putter's | |||
just replacing the "easy target language" from ruby to p5 | |||
and "temporary transcoded language" from $anything to p5 | |||
targetting perl 5 (with Class::MOP and other runtime parts in perl5/) has practical values, namely letting perl6 code that uses perl5:DBI work seamlessly | 05:27 | ||
plus, the p6p5 compile is free to use CPAN modules for glue parts instead of logic parts | 05:28 | ||
the idea is to not write any of the compiler in p5, but free to use existing p5 modules | |||
which is how I envision any reasonably sized p6 application to work in real world anyway | 05:29 | ||
Daveman | hooary! freedom :P | ||
putter | intriguing... | ||
obra | I did say this yesterday, putter ;) | 05:30 | |
audreyt | this path was forbidden largely because previously "p5 as a p6 vm" hadn't been thought of or specified | ||
obra | but not as convincingly | ||
audreyt | but our perl5/ and related modules is now at a stage that's mature enough | ||
so much that I was originally planning to write -CPerl5 for Pugs's Haskell CodeGen in israel | 05:31 | ||
but writing the same thing in p6 is much more fun | |||
to me personally and I think to other people as well | |||
not the least because using perl5 modules from haskell via Antibuddha is painful | |||
but using perl5 modules from p6 via use perl5:Foo is fun. | |||
end of epiphany | |||
putter ... | 05:33 | ||
audreyt | (plus, it doesn't inhibit the eventual run-this-real-thing via transcoding to p6-as-supported-by-pugs, as pugs has p5embed support as well.) | ||
putter really needs to think about this when closed eyes dont become head on table. sounds very neat. I have to think it though, but that's not going to happen just now. :/ | 05:35 | ||
audreyt | sure. sleep on it :) | ||
putter | nifty epiphany. | ||
will do. thanks, fun. | 05:36 | ||
05:36
penk left
|
|||
scook0 | audreyt: `in their paper SPJ calls p6 a "ferociously difficult to implement" language` -- what paper is that? | 05:36 | |
audreyt gets excited thinking that she can reuse her hundreds of CPAN modules for writing the p6p5 compiler with | |||
scook0: "Haskell: The dream that stuff is made of", a 20-year-retrospective overview of haskell's story | 05:37 | ||
scook0: private copy, to be published later this year | |||
scook0 | audreyt: oh, ok -- thanks anyway | 05:38 | |
Daveman | whee | ||
audreyt | putter: we should work on your perl6-announce article more when you wake up tomorrow | 05:40 | |
Khisanth | audreyt: you sound like a mad scientist from one of those actions movies "ah ha! I finally have a use for all these weird stuff I have been inventing over the years!" :) | ||
audreyt | Khisanth: which... is exactly what it is :) | 05:41 | |
<- came from the CPANfolks people, not p6folks people, contrary to chromatic's impression in his previous #perl6 rant | 05:42 | ||
Daveman | Khisanth :P | ||
Daveman runs away | 05:43 | ||
audreyt | Apr 1st sounds like a good target date. | ||
but I really need to run to get Luna translated :) | 05:44 | ||
bbl & | |||
Khisanth | wow ... this has to be one of the dumbest behavior in an app I have encountered so far... | ||
Daveman | Khisanth, some how, in three lines of code, I broke all telnet clients - hahaha | ||
worst... client app... ever... | |||
ahahah it comes on, and all the other connected telnet clients get broken heehee | 05:45 | ||
Khisanth | been spitting out warnings for days except instead of printing them and forgetting about them, it buffers several days worth of message | ||
Daveman | Khisanth, yikes | ||
Khisanth | well at least not as bad some one in #gtk-perl, one of his program created several gigs of error messages :P | 05:46 | |
05:47
penk joined
|
|||
svnbot6 | r8961 | Darren_Duncan++ | r2393@darren-duncans-power-mac-g4: darrenduncan | 2006-02-10 21:45:35 -0800 | 05:47 | |
r8961 | Darren_Duncan++ | /ext/Rosetta : removed some SEE ALSO items | |||
Daveman | Khisanth, bahahahahah | 05:52 | |
awesome | 05:53 | ||
05:53
br4in joined
|
|||
Khisanth | I think he kept deleting all the while finding he had no space... | 05:55 | |
05:56
pasteling joined
|
|||
Daveman | haha | 05:58 | |
poor guy | 05:59 | ||
when will noobs every learn :P | |||
speaking of which... you ready for this weekend Khisanth? :P | |||
06:00
stennie_ joined
06:05
drbean left
|
|||
Khisanth | Daveman: sure | 06:09 | |
Daveman | heh, alright :) | 06:12 | |
06:49
pdcawley_ joined
06:57
stennie joined
07:31
putter joined
|
|||
putter | a couple of thoughts from putter's sleeping mind... | 07:31 | |
I haven't / am not going to yet backlogged, but re p6a, | |||
07:33
drbean joined
|
|||
putter | re p6a, so no. because 1- I can't commmit to being project lead on this, 2- it's quite unclear which "this" this is ;) and 3- for several values of "this" one wants a ramp up preriod to shake down before having to deal with a large influx of people... so premature I think, no? | 07:34 | |
ok, thoughts... | |||
main thought - we really need to step back and look at the project design space (ie, how to organize going forward). just what are the key constraints, the options for addressing them, their adds/disadds. | 07:35 | ||
re p6p5... something is not quite right there. pX is a "hail mary" pass. a "abandon running code" because while running, it's unusable. but if p5 makes a good target because of lots of p6 support... then that the whole premise of pX becomes questionable. if p5's p6 stuff is usable, we should be building there, no? | 07:39 | ||
the kind of question we need to look at is: why isn't <foo> the running foundation on which to build. for a foo of pil2js, it's support for many things is(was?) better than pugs. and it has a working object system internally. but it's never be able to do non-hardwired objects. why not? that information isnt in pil. so, how could it get it? | 07:42 | ||
well, a bit kludgy, but it could preparse p6 code with regexps and pull out class info before handing code to pugs to parse. the approach has limitations, and was considered way back when, but was put on hold pending pil getting class info. (how hard would it be, etc) ok, what other approaches? well, pil start containing class info (how hard would it be, etc). | 07:44 | ||
what others? if -CParse-YAML has class info, one might use that instead of preparsing to augment existing pil. or given a parse tree, just how hard is it to do pil creation? say written in p6, and handed to pil2js? | 07:46 | ||
07:48
elmex joined
|
|||
putter | and so on. p5 side, what stands between current state an "use v6;" working for some value of working? do we need a P::RD p6 grammar? extend P::RD in some way? reimplement the "plan to throw one away" code of perl5/Perl6::Value and Container on the now solid? p6 like class systems available in p5? | 07:48 | |
pugs side, what really stands between current state and being able to write a compiler for p6 to something in p6? pge has dramatically improved. I tried once to write a Perl6::Compiler set of ast nodes, hit issues, but perhaps gave up to easily. with some haskell side debugging support, perhaps pugs object and rules supprot is just about good enough? | 07:51 | ||
07:52
kanru2 joined
|
|||
putter | not only is the implementation state complex, and the implementation opportunity space, but I'm also unclear on the dependencies between milestones. | 07:52 | |
take a parser. there's a range from hardwired p6-standard but you cant add stuff, through somewhat tweakable, through full p6 spec. pugs is in the middle there. we dont have another parser. a pge on grammar solution will likely be towards the static end of things for a while. which parts do we really need now, and for what? | 07:55 | ||
PIL^N addresses a bunch of stuff. bootstrap object system on simple core. simple core to simplify backends. more? which of these free up what dependencies that we need to accomplish what? | 07:57 | ||
07:59
vborja left
|
|||
putter | bottom line: I think we need to sketch the big hairy graph of the milestones we want, the pieces we have, the capability dependencies of our problem space, and our senarios for getting through it. and then, when that's non-fuzzy, plot a path through it. | 08:00 | |
xinming | there is a question comes up to my mind. If we use a perl 5 module within perl 6, will the speed slow down? | ||
Or, It will run as fast as we write it in perl 6. :-/ | 08:01 | ||
xinming is out for something to eat. | 08:02 | ||
putter | so one possibility (come morning for me) is to pull out large sheets of drawing paper, and try to graph what's going on. an attempt which will undoubtably generate a great number of questions, about what various things we have can and cant do. and... well, that's for another day (for me - feel free;). | 08:06 | |
'night & | 08:07 | ||
opportunity rich environment is good... | 08:08 | ||
08:18
iblechbot joined
08:42
elmex joined
09:24
pdcawley_ joined
09:28
grayson` joined
09:42
Medvekoma joined
09:43
G2 joined
09:46
kanru2 is now known as kanru
10:15
r0nny joined
10:44
chris2 joined
10:57
larsen joined
10:59
larsen joined
11:11
iblechbot joined
11:52
bsb joined
11:57
drbean joined
12:27
iblechbot joined
12:32
elmex joined,
stevan joined
|
|||
wolverian | does pugscode.org work for anyone? | 12:47 | |
bsb | not me | 13:01 | |
spinclad | nor me. failed for me on thursday morning too. | 13:05 | |
audreyt | fixing. | 13:29 | |
(maybe I should move it to feather? hmm.) | |||
13:33
ilogger2 joined
|
|||
audreyt | ok... it should get propagated within an hour or so | 13:47 | |
thanks for the reminder :) | |||
clkao | greetings audreyt. | 13:49 | |
audreyt | yo | 13:50 | |
clkao | leaving lovely taiwan tomorrow morning | 13:53 | |
audreyt | you? | ||
nice, I leave the day after | |||
bbl :) & | 13:55 | ||
14:16
SamB joined
|
|||
Juerd | audreyt: Feel free to move it to feather | 14:19 | |
audreyt: If you do, let me know, as from that point forward, I'll have to make sure the box is backed up automatically :) | |||
14:28
chris2 joined
14:48
binary42 joined
15:00
joepurl joined
15:44
GeJ joined
16:09
integral joined
16:50
putter joined
|
|||
putter | good morning folks | 16:50 | |
of course, usually the right thing is to work backwards from one's objectives. | |||
often much simpler | |||
I'm about to start scribbling. new note shortly | 16:51 | ||
tewk | So the new p6 compiler will be written in a reduced set of p6 running on p5 as the vm, did I get that right? | 17:00 | |
17:10
grayson joined
|
|||
stevan | we decided on p5 for the vm? | 17:37 | |
tewk | Well that is audreyt last great thought, backlog to about midnight last night | 17:38 | |
stevan suddenly realizes there is a gap in his local backlog :) | 17:40 | ||
I must have lost network for a bit | |||
integral | tewk: what language for the reduced p6 to p5 compiler? p5 itself? | 17:43 | |
stevan | Eak! SPJ calls p6 a "ferociously difficult to implement" language | 17:44 | |
stevan is suddenly filled with dread instead of hope ;) | |||
tewk | integral: from what I can gather. a full p6 compiler written in reduced p6 running on a p5 vm, get it | 17:45 | |
wolverian | stevan, where? | 17:46 | |
integral | hmm, interesting idea then, and sounds rather hard due to a lack of tools in p5 :-/ | ||
stevan | wolverian: in (which I believe is) an unpublished papaer which (i think) audreyt is reviewing for him | 17:47 | |
wolverian: see the backlog (colabti.de/irclogger/irclogger_log/...=118#l189) | |||
a perl 6 compiler that compilers perl 6 code to perl 5 written in perl 6 | 17:48 | ||
:) | 17:49 | ||
wolverian | augh my brain melted | ||
stevan | my dog tries to chase his tail all the time.. he hardly ever gets it,.. and when he does it is not quite what he expected ;) | 17:50 | |
that said,.. i think this might be the best approach | |||
it is certainly the most hackable by the largest group of people | |||
17:51
mtdms joined
17:52
mtdms joined
|
|||
mtdms | im novice in perl programming language, how good is it? | 17:53 | |
tewk | integral: Reduced set of p6 being defined as the portion of p6 that pugs currently supports. | 17:56 | |
So OO will end up being bootstraped on the p5 vm using Class::MOP ? | 17:57 | ||
stevan | tewk: I am not sure Class::MOP is what audreyt thinks it is | 18:01 | |
it might serve as a good p5-p6 compatability layer though | |||
or at the very least a plaform to re-write the metamodel on | 18:02 | ||
putter: we should meet in real-life,.. for a day and hack this out,.. maybe with obra too | 18:03 | ||
stevan has to run and do errands,.. but will remain in #perl6 in spirit :) | 18:04 | ||
18:05
justatheory joined
18:10
cm joined
|
|||
rafl | Stepping a word forward, b is backward, t swaps the last two words | 18:20 | |
putter | oo, backlog :) paste going up. | 18:21 | |
lisppaste3 | putter pasted "strawman walk through design space" at paste.lisp.org/display/16692 | 18:26 | |
putter | fiddle, fiddle | ||
stevan: re dog, lol | 18:27 | ||
stevan: re meeting, that would be neat. real whiteboard, yay. | 18:28 | ||
first meeting of the US NorthEast Perl6 Mongers? ;) | 18:29 | ||
given the (recurring) interest in a p5-based p6, it would be worth looking at it's design space more closely. | 18:31 | ||
I think we understand enough to sketch out exactly what would have to be done to create a pugs-equivalent in p5. | 18:32 | ||
retrospectively, my impression is Perl6::Rules was abandoned because the p5 regex engine was not recursive. though maybe also because it's been unstable. and perhaps P6::R complexity. | 18:34 | ||
If P6::R had worked, I suspect p6 on p5 would have been an already working no-brainer. | 18:35 | ||
but it didn't, so it isn't. | |||
putter tries to remember if pcre is reentrant... goes to check... | 18:36 | ||
well, it's thread safe, so in this context that likely means reentrant. | 18:39 | ||
18:40
robkinyon joined
|
|||
putter | No pcre module on cpan. Sigh. | 18:40 | |
I'd mention www.geocities.jp/kosako3/oniguruma/ (ruby 1.9's new engine) but no callbacks as yet. :( | 18:42 | ||
putter idly wishes someone would write a PCRE cpan module, just for the heck of it. | 18:43 | ||
for the "now p5 regexs can be reentrant" heck of it. | |||
Kattana | a pcre like p6 regex implementation would be nice.. | 18:44 | |
putter | you mean pcre implemented in p6? yes. not too hard to do on full working p6. rather harder when objects aren't quite working. absence of hypothetical vars adds cruft, but can be worked around. i think. | 18:46 | |
Kattana | I mean a working library of apocalypse 5, it does not matter what language it is written in, it would be usefull. | 18:49 | |
putter | but the question is then, where do you run it? on pugs, pge or Text.Rule would be faster. though a p6 version might be easier to extend into a parser. compiled to p5 or js, just how slow are you willing to go? | ||
isn't that what libparrot/pge is? ;) | 18:50 | ||
Kattana | is it? you would know more about it than me. | 18:51 | |
putter | that's basically how we're using pge for rules. I don't know if pge has callback hooks yet, so more a oniguruma than a pcre. ie, doing a Snn flexible parser, with longest token matching and operator precedence parser nodes, can't (currently) easily be done? | 18:53 | |
oh, the other big downside of a non-p6 rules engine, is if that's your parser, it gets more hairy to do dynamism. eg, a lexically scoped "oh, here's a new type of statement, and some more tokens and operators... end of scope, now they're gone". | 18:55 | ||
but with callbacks and reentrancy it can be done. | |||
oh, wait. maybe I decided it couldn't be, not really. hmm... | 18:56 | ||
18:56
larsen joined
|
|||
putter | the engine has to be able to fail back into the callback. | 18:56 | |
so a callback which, say, implements a+ , can try matching one less a. | 18:57 | ||
pcre "callouts" don't. :( | 19:02 | ||
19:06
Amnesiac joined
|
|||
putter | not only does one need such a general node, but the regex optimizer has to recognize it, and... not optimize. because anything-in-the-universe may change going through that node. so yes, for Snn level flexibility, a p6 implementation would be nice. ;) | 19:07 | |
for pugs(current)-level flexibility... well, we already have pugs. I'm not sure if it is "known to be buggy" or "known to work just great, with flexibility room to spare". I believe it would take some, perhaps non-trivial, work to get pge to do pugs-level flexibility. but maybe not. pge certainly might be capable of a less flexible parse. | 19:10 | ||
though that hasn't been tested. | |||
19:13
larsen joined,
dduncan joined
|
|||
putter | once upon a time my thought was "create Rul objects this afternoon, to remember the regex pattern and provide a place to hang pattern ast's, and and a type for multi sub rule engines. Then tomorrow I'll do the ast, and start bootstrapping a regex parser. Then I'll write a simple alternate recursive decent engine, and we'll see where to go from there". | 19:14 | |
19:17
larsen joined
|
|||
putter | Rul creating got unnegotiably stopped by type inferencer issues. Things changed, but Rul is still blocked (t/pugsbugs/smartmatch_rx_obstacle.t). If that were fixed, i'm not sure whether the ast would be straightforward or not. my one attempt at a big ast tree on pugs p6 didn't work, but I didn't really try hard, let alone attempting targeted pugs hs-side fixes. | 19:18 | |
but for the short term, getting objects working... somewhere... the parser is not an issue. as long as -CParse-YAML can be used. | 19:20 | ||
for objects, it seems basically: | 19:21 | ||
pugs parser -> pugs compiler -> PIL(extended) -> PIL backend | |||
pugs parser -> -CParser-YAML -> backend compiler | 19:22 | ||
pugs parser -> pugs compiler(changed?) -> pugs runtime(extended) | |||
also | 19:24 | ||
pugs parser -> -CParser-YAML -> backend class handling | |||
-> pugs compiler -> PIL(as is, no classes) -> backend PIL handling | |||
key quetions: | 19:26 | ||
how difficult would it be to do a minimum modification of the existing PIL so that it was non-lossy with respect to class info? with that, pil2js could be extended to pugs-level capability, and prelude-written-in-p6 version of a p5 backend could be done. | 19:27 | ||
(or alternately, how difficult to do a -CParser-YAML "second channel" to get the class info) | 19:28 | ||
that would get us uncontrained by the pugs runcore, but not from the pugs parser or compiler. | 19:29 | ||
sufficient to do a pugs-equivalent (likely, yes?), but not necessarily to easily develop from there. | 19:30 | ||
you then need to improve or replace the compiler and parser, perhaps in that order. | 19:31 | ||
integral | putter: have a look in src/Pugs/CodeGen/YAML.hs, you just need to make sure the data structure you want is YAML dumpable by DRiFT and add a line to dump it | 19:33 | |
putter | Though there is an element of "just choose a path, any plausible path, and get people motivated, and we'll get there". vs not moving. The old "any decision is better than no decision" argument. | ||
integral: looking... but what context? | 19:34 | ||
integral | context? | ||
putter | why am I looking at this? :) | 19:35 | |
integral | you said "how difficult to do a -CParser-YAML "second channel"" | ||
and this is how difficult :) | |||
putter | :) | 19:36 | |
so... ./pugs -CParse-YAML -e 'class A{has $.b}' currently reports on A, but not on $.b. ($.b does show up, in a way, on -CPIL. but not A;). so can -CParser-YAML be extended to mention $.b? | 19:38 | ||
integral | if the data is somewhere, sure :) | ||
hmm, actually let's see if my local mod does it | 19:39 | ||
nope | 19:40 | ||
putter | :/ | ||
any idea how easy/hard it would be? bascially, there are two motivations, | 19:41 | ||
you want to write backends using a p6 prelude, which obviously requires class info which has been lacking. | 19:42 | ||
integral | if you know where pugs stores the data, it's easy if you know do you hook up drift, since it's then a one line change to that YAML.hs | ||
putter | and then, but perhaps secondarily, it would be nice if users could write classes (which work on the backends;) | ||
integral: hmm. should I take that as a "maybe"? ;) | 19:43 | ||
integral | yep | ||
putter | ok, | 19:44 | |
basically with a yaml tree with class/attribute info, my next step would be to cry "stevan! how goes the p5-based p6 class-like things. can I easily drive it from a class attribute tree?" then given a object system skeleton, then if yaml had a full parse, I might contemplate trying a simple compiler, and if not, back to -Cpil. | 19:47 | ||
putter wonders if he has drift installed... maybe not...? | 19:48 | ||
integral | hmm, if drift is a command 'drift' it's not on feather | 19:49 | |
putter doesn't remember... checks makefile... | 19:50 | ||
util/drift.pl and a hugs library (an optional one I thing, but not sure) | 19:51 | ||
so, big picture, this is a "get objects working on a p5 backend" path. a p6 prelude poured though -CPIL and/or -CParser-YAML. tree walked into Class::something-or-other and Class::MmbleMethods calls, and p5 code. | 19:55 | ||
19:56
elmex joined
20:07
pdcawley_ joined
20:14
putter joined
|
|||
putter waits to see if his irc client syncs... | 20:16 | ||
guess not. | |||
I'm just going to cut and paste. | 20:17 | ||
rather than rephrase. sorry. | |||
Parts are p6 prelude (some bits written, could be written now, not being so perhaps mostly because it's not fun to write stuff that doesnt run (hmm, but some could run on pugs??)); CParser-YAML, needs extension as currently discussed. perhaps minor extension to get class info, more extensive to get full parse. | |||
tree walks, been there, done that, can do it again. | |||
Class::mumbles, well, they're on CPAN, so of course they work, no? ;) | |||
oh, so could be doing a PIL walker now. basically a cleaned up / rewritten PIL-Run. hmm, I actually have the beginnings of one of those around here someplace... | |||
(got bogged down in trying to fake class parsing and such, I think) | |||
maybe | 20:18 | ||
big point is, we've done this before (PIL-based backend, even on p5). the non-prelude portion of it is a task measured in days, or at most a couple of weeks. and with the cpan modules, we're now in an even better place to do it than we were previously. so if we can use -CParser-YAML to get around the "-CPIL just doesnt tell | |||
us what we need to know", then this whole development path get's unstuck. | |||
assuming a working class substrate, the prelude portion of the task is also just not a very big deal. especially if you can actually see the code run. ;) | |||
***putter goes to dig up his old pil-run rewrite... | |||
hmm. though -CPIL doesn't quite get you to pugs-equivalence. you can look at a smoke of pil2js. maybe an older one, my very fuzzy impression is it's been slipping. some test files just dont -CPIL'ify. | |||
END. sorry again. | |||
misc/pilrun2-leftovers/ is in. | 20:38 | ||
svnbot6 | r8962 | putter++ | Created misc/pilrun2-leftovers/. It contains some leftovers from an old effort to clean up PIL-Run. It's an non-running development snapshot, provided as junkyard scavenging material. Since it looks like a p5 backend may again be pursued, with -CParser-YAML to work around -CPIL limitations, and improved CPAN-based class and multi-method handling. Some of it is of little interest. pil.pl might be useful. | ||
putter | for whatever it's worth | ||
the prelude stuff from pilrun2 is in a less scavengable state. but I'll pop it in leftovers if anyone asks. if we go down this path, we can combine it with the stuff in src/PIL/misc/, Prelude.pm, etc. | 20:41 | ||
if someone get's -CParser-YAML to report class and role attributes and inheritance (is and does), I'll endeavor to plug it into stevan's Class:: module on p5. and if that works, I'll likely dust off "pilrun2", aiming for "objects as working as the pugs compiler permits". A "two channel" -CParser-YAML plus -CPIL front end, and a pure p6 prelude with a p6 backend-specific overlay. | 20:50 | ||
I'm afraid, for me, the drift part would quite non -Ofun. So I'll leave that for someone else. | 20:52 | ||
integral: sound plausible? | 20:53 | ||
20:54 | |||
anyone have any comments on the "where do we go from here? - walk through design space" paste? | 20:55 | ||
anyone here? | 20:56 | ||
;-/ | |||
putter goes to look at stevan's CPAN modules. and luqui's... | |||
Class::Role, Class::Roles, Perl6::Roles... weee | 21:00 | ||
obra | Role::Role | 21:01 | |
21:03
GeJ_ joined
|
|||
putter | oo, missed that one ;) | 21:03 | |
err, on cpan? | 21:04 | ||
obra: don't see it on search.cpan... ? | 21:05 | ||
there is Role and Pugs::Role in misc/Perl-MetaModel/lib/ | 21:06 | ||
obra | Sorry. Being useless. | ||
obra needs a "bad attempt at humor" flag for irc | |||
putter | ah, np. nice to hear someone else's voice. felt like I was talking to myself for a while... for the backloging, but still... | 21:07 | |
src/PIL/Native/Bootstrap/Roles/ and Role.pil | 21:08 | ||
maze of twisty little passages | |||
obra | :) | 21:10 | |
putter | audreyt: is adding class/role attribute/is/does info to -CParser-YAML something you could knock of in a few minutes? ideally module and package declarations too (ie, just module_declared: name) | 21:14 | |
tewk has been following along. | |||
putter | :) | 21:15 | |
tnx | |||
s/knock of/knock off/ | 21:16 | ||
does p5/cpan have a backtracking parser?? (P::RD doesn't backtrack) | 21:23 | ||
search.cpan.org/~lpalmer/Parse-Earl.../Earley.pm looks nice, but no backtrack. | 21:26 | ||
search.cpan.org/~gslondon/Parse-Native-0.02/ is kind of neat, even if "prerelease, doesnt do anything". | 21:36 | ||
21:39
DesreveR joined
21:44
GeJ_ is now known as GeJ
|
|||
gaal | FYI: there's a bug in Syck, it doesn't quote ":" and "," scalars, so that when we emit e.g. Syn , the data doesn't roundtrip | 21:48 | |
Hadn't the tuits to fix it myself, but I did send in a report to Why. | |||
FYI II: precompiling Prelude.pm with YAML takes about nine times as long on my machine as -CPugs, but the output is only two-thirds as long. | 21:49 | ||
FYI III: I tried s/type VStr String/type VStr FastString/ and following the inferencer errors from there, but punted when I reached the parser. Maybe when Audrey arrives. :-) | 21:50 | ||
fixing #3 will make #2 much better, I'm sure. | 21:51 | ||
and #1 can be workarounded with a simple fixup in gen_prelude | 21:52 | ||
but then there's still the question of how expensive loading the YAML is; will it have to be done on every pugs instance load? | 21:53 | ||
zZ& | 21:54 | ||
putter | good night gaal. thanks for the fyis :) | ||
22:03
bsb joined
|
|||
putter | ok, I want the following cpan module(s). a purely descriptive grammar ast. nodes for literals, regexs, alternation, etc. named rule with arguments. then I'd like a function api to construct these trees. eg, seq(lit("a"),lit("b")) . ideally a sub which builds a tree from a p5 or p6 regex string. though I can build that if i need to. then, | 22:06 | |
I want a module which crawls that tree, and gives me the eval'able source for a backtracking, recursive decent parser, made out of subs which take a single continuation (another sub) argument. having been given textual templates for lit/re match, and pre/post-success/post-fail recursion. I can then | 22:08 | ||
set up a local() match/search object, and call one of these subs, to get a nice parser. or wire them together dynamically with $f1->(sub{$f2->(noop)}). | 22:10 | ||
I think you could also compile them together. | |||
not only do you have a nifty little parser, in which arbitrary perl code can participate fully, but you've both accidentally written a p6 rules engine, and most of a p6 parser. | 22:12 | ||
subs returning undef on failure might be fastest. I suspect the relay costs (return undef if not $ret) are less than the cost of throwing exceptions. | 22:13 | ||
especially if "run after recursion failure" code appears a lot. | 22:14 | ||
local() gives you p6 temp(). let()... hypothetical variables require some work. but you could add a let node and constructor to the tree, which handles the messiness. | 22:17 | ||
22:17
drbean joined
|
|||
putter | you would think someone over the years would have gotten around to the first part, but my searches at least havent turned it up on cpan... | 22:18 | |
then again, nothing I do ends up on cpan, so if that's typical, then it may have been reimplemented n times already, and just hasnt made it yet. ;) | 22:19 | ||
stevan | putter!!!!!!!!!!!! | 22:22 | |
putter is on a roll | |||
putter | search.cpan.org/~pinyan/YAPE-Regex-3.02/Regex.pm | ||
hey stevan :) | 22:23 | ||
stevan | putter: all current Roles implementations are incorrect | ||
Class::Role(s) are based on old specs | |||
Perl6::Role is fairly close (written by my co-worker with some of my tests) | |||
and the Perl6-MetaModel and PIL^N ones are wrong too | 22:24 | ||
Class::Trait is actually got the closest to correct model right now | |||
as far as working metamodels, Perl6-MetaModel is not bad but needs updating, and the Perl6-ObjectSpace is too specific to the objectspace backend right now to be useful for us (unless we use that as the base VM) | 22:26 | ||
the biggest problem with all the metamodels has been metacircular issues (as I am sure you recall, the "infinitily recursive recursion" stuff) | 22:27 | ||
however, I have been testing Class::MOP with Class::C3 (which DBIx::Class actually uses right now with (suprisingly to me) great sucess) | 22:28 | ||
and the two work fine together ,.. so maybe that is a route | |||
putter pops up from exploring the wonderful world of cpan modules which manipulate re's... | 22:29 | ||
stevan | it should not have the same metacircular issues and actually runs pretty fast cause there is no AUTOLOAD usage | ||
but alas,.. I really need to run,.. going to dinner with the inlaws | |||
Kattana | putter: find anything like what you want? | ||
stevan | putter: I will try and get some time online tonight and we can talk some details,.. | 22:30 | |
although the ideal is to engineer free time when audreyt will be in .il | |||
stevan vanishes in a *ppof* | |||
putter | stevan: ah well. enjoy dinner. we'll touch base at some point. and plan a get together too. | ||
stevan | yes, definitely | ||
putter | a "*ppof" ? | ||
lol | |||
:) | 22:31 | ||
cheers & | |||
Kattana: YAPE-Regex looks like it did the "generic tree". I haven't looked at it closely yet. Does do parse p5 re. :) doesn't look like it does dsl (but I guess I can live without that). | 22:32 | ||
currently am grovling through the various optimizers, though they seem to be close world so far. | 22:33 | ||
Kattana | dsl? | 22:35 | |
integral | domain specific language | ||
fwiw, japhy can very occasionally be sighted in #perl on this network | |||
(and japhy wrote YAPE) | 22:36 | ||
putter | search.cpan.org/~jdutton/Parse-RandGen-0.202/ | 22:47 | |
integral: ah, thanks. and perhaps here? the nick looked familiar... | |||
Kattana: the seq(lit(),lit()) thing. | 22:48 | ||
RandGen has a data based one, eg, prod=>[ cond=>"token", cond=>"'/'", ] | 22:49 | ||
integral | oh, probably :) | ||
putter | looks like the ast has collapsed a lot of nodes. but i havent looked at internals yet. | ||
:) | |||
bsb | putter, do you have HOP? It had parsers and a partial regex iirc | 22:51 | |
partial regex engine | |||
integral | there is HOP::Parser on CPAN | 22:52 | |
putter | bsb,integral: do I, do I, nope. looknig at cpan... | 22:54 | |
after seeing "Elsevier", why am I not surprised to see two screens of license text. blech. but continuing... | 22:58 | ||
bsb,integral: thanks | 23:01 | ||
integral | np | ||
bsb | welcome | 23:03 | |
putter | ok, hop uses subs taking a single argument, input. no tree - the alt() etc return bare subs. no continuations or general backtracking unfortunately. | 23:09 | |
so current state is YAPE and RandGen provide trees, but I haven't yet see anyone providing a backtracking recursive decent core w continuations. | 23:11 | ||
continuing to explore cpan... | |||
integral | I actually have a parser. It's not on CPAN though | ||
it's quite fast, but it's unfinished, but it can backtrack | |||
putter | continuation based? ie, | 23:14 | |
integral | no, not as such, but it can save arbitrary state over backtracking | ||
putter | composable? | 23:15 | |
integral | sorry, I don't understand how to apply composability to continuations in a parser | 23:16 | |
putter | ie, | ||
thing_matching_a + thing_matching_b -> thing_matching_ab | |||
integral | sure, you'd just construct the program "BRANCH ( A ) ( B )" | 23:17 | |
putter | i suppose if you're passing along the arbitrary state that'd be no problem. ah | ||
integral | it's got a rudimentary rules like frontend on it | ||
putter | at choice points you deep copy the state? | 23:18 | |
integral | some of the state | ||
putter | like before trying each branch of ... ah | ||
integral | it's got all the different types :) state that doesn't get saved over backtrack, so branches can remember which to try next, and state that does | ||
anyway, fwiw, integral.ig3.net/svn/mirror/parse/trunk/nge/ is the code | 23:19 | ||
putter | ah, neat. will look. | ||
integral | I did develop it while looking at perl6 so it should cover all the stuff rules have to do | ||
putter | re things, can thing_b fail back into thing_a, so thing_a can shorten or lengthen its match? | 23:20 | |
looking at code... | |||
integral | yep, it's got two call opcodes implemented, one that backtracks over the call, and one that doesn't | ||
23:20
oylenshpeegul joined
|
|||
integral | actually, it *is* basically continuation based :) It's "activation records" are just call frames, and they form singled linked lists | 23:22 | |
putter | Like stage 20 ;) | ||
integral | ooh, wow, I included memoised calls, so it remembers how a subrule matches at a given point. (eg. the grammar: "<a> <b> <c> | <a> <c>" only needs to execute <a> once) | 23:23 | |
putter | lol :) | 23:29 | |
integral | ah, doc/mkgrammar.pl has the grammar for it's own language, that's neat. self-hosting is always a good sign I guess | 23:30 | |
putter | gather it's been a while since you looked at this? :) | 23:31 | |
23:31
oylenshpeegul left
|
|||
integral | last checkin was march last year :) I wrote it just soon after pugs started in the general perl6 malaise that filled that period | 23:32 | |
putter | (aside: search.cpan.org/~sadahiro/Unicode-R....02/Set.pm looks potentially useful - some set ops on unicode charsets) | ||
ah, yes :) | 23:33 | ||
any thoughts on how to easily get one of these critters working? did you consider a (simpler?) "assemble subs" or (less simpler) "assemble source code for subs" and discard it for performance reasons? | 23:35 | ||
or....? | 23:36 | ||
integral | putter: I'd written another thing that used code generation to build parsers, and I thought it sucked because of our lack of quasiquoting | ||
So I started with the basic idea of opcodes chained together doubly, built the loop for that, optimised the hell out of it, and uh, ended up with that :-/ | 23:37 | ||
the concession to readability is the "microcode", all those little subs inside the StdOps | |||
putter | :) | ||
integral | oh, actually that was another reason: too difficult to generate code for backtracking | 23:38 | |
(at least without using the perl call stack) | 23:39 | ||
putter | right. why not call stack? | 23:40 | |
integral | overflow, the annoying recursion too deep warning | ||
I mean, if you're matching a very backtracking regexp against a 1k string... | |||
(like you are when parsing source code) | 23:41 | ||
23:42
rantanplan_ joined
|
|||
putter | i've been hit by "recursion too deep warning", but don't have a feel for it. can it be turned off? | 23:42 | |
integral | it can | ||
but some operating systems do still have limited stacks | |||
putter | i fuzzily recal pil2js being decorated by "dont warn about recursion" pragmas. maybe. | ||
integral | (hint, I've got -Mre=debugcolor style tracing when you turn NGE_DEBUG on, it's scarily complex to debug this stuff :-/) | 23:43 | |
putter | how thick is p5 sub call? | ||
integral | can be quite big I think | ||
I just decided to be more resilient, and it gives you a continuation system too with your own frames | |||
it's easy to implement FENCE ( that's (?>) in p5re) for example | |||
putter | sigh. is this a show stopper for a call stack based parser, or just a "we know we are going to suffer from/be limited by this"? | 23:44 | |
integral | hmm, it really depends what the call stack equates to | 23:45 | |
in Parse::RecDescent it's the nesting of rules calling each other, so probably not | |||
putter is trying for simplicity... adopting a scarily complex to debug vm seems not so much in that spirit...;) | |||
integral | In a regexp engine, very possibly if depth equates to backtracking | ||
putter | frotz. | 23:46 | |
integral | But in a grammar for perl6 where backtracking is quickly resolved (or so I thought the design goals said...) | ||
putter | worse, in a continuation base... oh, no, p5 has tailcalls. so as long as you dont need success/failure code run, that wont contribute to stack use. though trying to avoid success/failure code complicates other things. :/ | 23:47 | |
integral | ooh, I wrote an interactive debugger for it. anyway, I need to sleep now :) Good luck with thinking of ideas to get the perl5 impl going | 23:54 | |
putter | hmm, so 1GB virtual gave me 1.5M deep recursion with a very simple sub. hmm... | ||
integral: ok, thanks for your help. 'night & | 23:55 | ||
23:55
elmex joined
|
|||
putter | anyone know if p5 does/doesnt optimize away my $doesntescape = sub {...} subs? | 23:57 |