Pugs t-shirts www.cafepress.com/pugscode | Pugs 6.2.9 released | pugscode.org | pugs.kwiki.org | paste: sial.org/pbot/perl6 | www.geeksunite.net Set by stevan on 15 August 2005. |
|||
putter | Anyone here know why my %h=(a=>11,b=>12); class C{has $.a; has $.b;} C.new(*(%h.pairs)) doesn't work? thanks | 00:03 | |
svnbot6 | r6666 | putter++ | PIL-Run - class C{method f(){13}} C.new.f #=> 13. But that's about all that works. | ||
putter | new PIL-Run smoke... 12.67% ! fglock++ | 01:27 | |
svnbot6 | r6667 | putter++ | PIL/Node_pm_gen.pl: introduction of a parallel set of "self type-checking" nodes. some cleanup. | 01:52 | |
r6668 | dudley++ | Perl6::MetaModel 2.0 docs - Minor speeling/grammer fixes. | 01:58 | ||
Pete_I | why is it called 'Pugs'? | 02:05 | |
perl user groups? | |||
dudley | Perl6 User's Golfing System | 02:10 | |
It's a play on Hugs, the Haskell User's Golfing System, an interactive haskell interpreter | 02:11 | ||
Pete_I | ah | 02:12 | |
putter | ?eval class C{has $.x; method new($x){say $x; BUILD(x => $x);}} C.new(3) | 02:23 | |
evalbot_6652 | 3 Error: No compatible subroutine found: "&BUILD" | ||
putter | Am I missing something obvious? | ||
A request: could someone write | 03:02 | ||
class C{}; class C::D{method new($d){...}}; sub f($d,$cls){ ::C::($cls).new($d) } say f(3,"D"); | |||
with the ... filled in. | |||
I'll backlog to pick it up. Right now PIL/Node_pm_gen.pl is stuck until it's figured out. | 03:03 | ||
thank you for your help. | |||
end of day. good night all & | 03:04 | ||
03:26
sleepster is now known as typester
|
|||
luqui | ?eval my %h = (a => 1, b => 2); say +%h | 06:51 | |
evalbot_6652 | 2 bool::true | ||
luqui | ?eval class C { has $.x; method new ($x) { say $x; ./BUILDALL(x => $x)}} C.new(3) | 07:01 | |
evalbot_6652 | 3 Error: No compatible subroutine found: "&BUILDALL" | ||
luqui | ?eval class C { has $.x; method new ($x) { say $x; ./BUILD(x => $x)}} C.new(3) | ||
evalbot_6652 | 3 Error: No compatible subroutine found: "&BUILD" | ||
luqui | ?eval class C { has $.x; submethod BUILD ($x) { $.x = $x } method new ($x) { say $x; ./BUILD(x => $x)}} C.new(3) | 07:02 | |
evalbot_6652 | 3 \3 | ||
luqui | ?eval class C { has $.x; submethod BUILD ($x) { $.x = $x } method new ($x) { say $x; my $s = ./BUILD(x => $x); $s}} C.new(3) | 07:03 | |
evalbot_6652 | 3 \3 | ||
luqui | huh... | ||
probably have to bless manually, which is probably unsupported | |||
ods15 | ./ ? | 07:06 | |
luqui | ods15, that's "call on self" which may or may not exist | 07:08 | |
but does exist according to pugs at least | |||
ods15 | heh | ||
luqui | hmmm, and that makes sense why that doesn't make any sense now | ||
?eval say('smiley :') | 08:34 | ||
evalbot_6668 | smiley : bool::true | ||
nothingmuch | autrijus: deep magic on p6l | 08:46 | |
please have a crack at it | |||
luqui reads | |||
nothingmuch | it's in response to the lexically and temply overriding &prefix:<+> | ||
in short: i think there's a place for the everything-inferencing in p6l at the language definition level | 08:47 | ||
luqui | nothingmuch, before value inference, we should probably get type inference working at all | 08:50 | |
nothingmuch | luqui: this can be overlooked temporarily | ||
luqui | also, keep in mind that value inference should be a halting problem | ||
nothingmuch | but i think that for sane semantics of overriding &pprefix:<+> we need full inferencing, even if it's weak | ||
or to disallow rebinding the prelude at all | 08:51 | ||
luqui | you mean sane optimization? | ||
nothingmuch | s/at all/completely/ | ||
no, i mean the ability to decide via inferencing whether code can be executed at all | |||
or whether it's a circular definition | |||
since &prefix:<+> or something like that was rebound to a sub that makes use of global &prefix:<+> | |||
luqui | that sounds like the screaming definition of the halting problem | 08:52 | |
nothingmuch | not quite | ||
look at the implementation strategy | |||
luqui | you must allow recursion | ||
nothingmuch | you can't guarantee that your code won't get stuck or anything | ||
luqui | but I haven't finished reading | ||
nothingmuch | it's a more basic question - where is the line between the runtime's primtive's and your language's definition drawn | ||
and this being perl 6, the answer is determined by excessive handwaving | 08:53 | ||
and i think that inferrencing is necessary to draw the line where it's safe to draw it | |||
to make sure that code can be run at all | |||
luqui | ooh, handwaving? now i'm listening :-) | ||
nothingmuch | anyway, the prelude is completely recursive, and portable across ruuntimes | 08:55 | |
luqui | another thing that we could say is that in the standard dialect you're only allowed to lexically rebind builtins | ||
nothingmuch | the runtime prelude is an annotation to the portable prelude | ||
providing native alternatives for "pure" functions | 08:56 | ||
some things are '...' in the prelude since they rely on the runtime | |||
and absolutely must have the native alternative to work | |||
luqui | you also note that your proposal is completely contrary to separate compilation | ||
nothingmuch | no it isn't... this is link time ;-) | ||
luqui | we have to keep so much information around, and we do so much at link time | 08:57 | |
that basically link time == compile time, as it did in perl 5 | |||
nothingmuch | inferrencing then takes the native loop holes, and tries to use them wherever they can safely be used | ||
uh, we can't both be dynamic and static | |||
as I see i this is as separate as we can get without ruling out some language features | 08:58 | ||
luqui | okay, the root of my uneasiness with this (not having thought about it much), is that everybody seems to think that global inferrence is bad | 08:59 | |
in every single paper I've read that addressed the issue | |||
so I figure smart people have their reasons | |||
but I haven't stuck it in my own brain yet | |||
nothingmuch | well, i think it's a choice that the user should have: | 09:00 | |
no overly dynamic rebinding of "builtins", and an actual notion of builtins | |||
or a langauge which pretends to be completely defined within itself | |||
except where inferrencing let's it cheeat | 09:01 | ||
luqui is intrigued by your implementation strategy, though | |||
nothingmuch | i think that leaving the metacircular option TODO for a long while is a viable option | 09:02 | |
i think that 99% of the time i'd like to run that way | |||
luqui wonders how many implicit parameters a call into a complex module would have | |||
nothingmuch | luqui: initially thousands | ||
but constant folding and parameter inlining should solve that | |||
and furthermore this work is already being done | |||
luqui | yeah... kindof | ||
nothingmuch | compile time resolving of "globalish" functions is something that perl 5 does | ||
luqui | it'd be nice to be able to compile perl without 2G of memory... | 09:03 | |
but we have moore on our side | |||
nothingmuch | 'time(); use SomeModule qw/time/; time()' # not the same time() being called | ||
luqui | right | ||
nothingmuch | well, i think that it's a good feature, left optional | ||
luqui | that's essentially a lexical rebinding... but only kinda | ||
when you're compiling, it looks to see if time is overridden... | 09:04 | ||
and only puts in one of two alternatives | |||
nothingmuch | well the problem is that in perl 5 CORE::GLOBAL:: and CORE:: are special cases | ||
luqui | you can never get three different behaviors of time() in the same module | ||
nothingmuch | which perl 6 is pretending to do away with | ||
right | |||
luqui likes static binding, mostly because he has had to use opengl | 09:05 | ||
so I'm with you there | |||
you just want it to be really smart, and I think it will be fine if it's relatively dumb | |||
nothingmuch | well, i'll reiterate: | 09:06 | |
it's dumb by default, because it's Good Enough | |||
but since the language pretends to be meta meta | |||
then there is the option to use the slow smart way | |||
(slow compilation) | |||
this may be useful for several things: | 09:07 | ||
safe compartments | |||
domains pecific languages | |||
environment emulation | |||
very very evil workarounds | |||
it's dangerous though | 09:08 | ||
and in this sense i'd rather have 'no you can't do that' by default | |||
with 'use meta circular mega inferrencing' as a lexical pragma to get around that | |||
luqui | re: safe compartments | ||
you're talking about putting code that was compiled before you knew that it had to be safe | 09:09 | ||
nothingmuch | yes | ||
uh, no | |||
luqui thinks that's pretty rare | |||
nothingmuch | code that wasn't compiled with the megainferrencor can't be mega inferred | ||
luqui | safe compartments can be done with lexical rebindings, no? | ||
... | |||
n | |||
no | |||
nevermind | |||
nothingmuch | anyway, more than that | 09:10 | |
safe compartments not only in the permission sense | |||
but also in the auditing sense | |||
luqui | ? | ||
nothingmuch | oh, and obfuscated code | ||
well, sometimes you just want to rule out certain opcodes | |||
luqui | hmm? | ||
obfuscated? | |||
nothingmuch | i was kidding ;-) | 09:11 | |
luqui | oh | ||
I thought you were referencing something like the java obfuscator | |||
to hide source from reenignes | |||
nothingmuch | but 'temp &*prefix:<+> := &say.assuming("Just Another Perl Hacker")' could be nice | ||
oh, no, that stuff sucks | |||
anyway, sometimes you don't want to just rule out opcodes, but you want to meter, augment, or otherwise change or wrap builtin opcodes | 09:12 | ||
for just a part of the system | |||
luqui | nothingmuch, yeah, I understand that | ||
and that part of the system is often dynamically scoped | |||
not lexically | |||
nothingmuch | and the domain of the solution should move away from the runtime, towards the language definition, when it becomes that complicated | 09:13 | |
luqui | let the users use modules, but don't let the modules do Funny Stuff either | ||
nothingmuch | right | ||
luqui | the other way to do Safe, of course, is to use something akin to Parrot's slow core | ||
nothingmuch | right | ||
luqui | just assume that everything has gone to hell and execute with negative one optimizations | ||
nothingmuch | anyway, house work is calling | 09:14 | |
luqui | call him back | ||
nothingmuch | i think that @Larry will need to: | ||
luqui | :-p | ||
nothingmuch | a. decide when the line is drawn | ||
b. decide whether several lines can be drawn | |||
c. decide where the line will be drawn when it is drawn | |||
d. | 09:15 | ||
whether the user gets to make a choice | |||
ciao | |||
luqui expects a lot of that just depends on how much the faithful implementors of perl 6 (i.e. us) get done | |||
nothingmuch | autrijus: backlog please, you know much about this | ||
luqui: i think this issue is more all encompassing than we think | |||
and that it's a language designer's decision to mark it as 'todo' or 'won't fix' | 09:16 | ||
luqui | nothingmuch, yeah, but you're essentially talking about a strategy that has never been done | ||
and there have been many sucessful self-implementing languages | |||
anyway, ciao | |||
nothingmuch | luqui: self implementing compilers for languages | 09:17 | |
luqui points to scheme | |||
nothingmuch | but at some point the chip on your has to do some boolean logic | ||
even if you've implemented church integers | |||
luqui understands the problem | 09:18 | ||
luqui will think about it some, but he thinks that it's less all-encompassing than you think :-) | |||
nothingmuch | and the prelude, as well as overriding things like &infix:<&&>, &prefix:<+>, &infix:<+>, and so forth is not changing the compilation down to the chip doing some boolean logic | ||
it's overriding it | 09:19 | ||
and the mega inferrencer is, IMHO, the only way to determine when it's safe to still use the chip, to bootstrap the part that no longer uses the chip | |||
(except that it does, behind the scenes | |||
anyway, *poof* | 09:21 | ||
nothingmuch is now high on paint, paint thinner and sawdust | 11:48 | ||
posts to p6l may become more interesting | |||
la la la | 13:38 | ||
svnbot6 | r6669 | Stevan++ | Perl6::MetaModel 2.0 | 13:43 | |
r6669 | Stevan++ | * adding in the _('$.x') instance attribute | |||
r6669 | Stevan++ | accessor/mutator macro | |||
luqui | nothingmuch, thanks for the summary | 13:49 | |
I understand what you're getting at better here | |||
I was looking at it as more of an optimization problem gone wrong | |||
nothingmuch | yeah, i hoped that'd be the acheived effect | ||
oh, no, i don't care only about optimization ;-) | |||
luqui | You want overriding operators to be correct *everywhere*, even inside builtins | ||
or rather, your proposal wants that | 13:50 | ||
nothingmuch | yes | ||
luqui | you understand that if you throw optimization out the window, that this inferrence becomes possible and easy at runtime | 13:51 | |
and you get the same effect | |||
but it would be slower than Class::Multimethods::Pure :-) | |||
nothingmuch | right | ||
optimization for such a complicated language is a requirement, IMHO | |||
and furthermore, dynamic, continuous, incremental and reversable optimization is also necessary | 13:52 | ||
luqui | well, I keep figg'ring that (like you said at the end of your summary) global overriding of builtins should not be possible | ||
only lexical... | |||
nothingmuch | otherwise there is just too little balance between runtime and compile time | ||
luqui | nothingmuch, "reversible" optimization is impossible | ||
talk to Dan sugalski about that one, he understands it well | 13:53 | ||
nothingmuch | yes it is, you just keep snapshots of previous states, or a log | ||
luqui | you can't | ||
nothingmuch | and throw away what you did here when it becomes: | ||
worthless | |||
problematic | |||
uh, wtf? | |||
luqui | hang on while I concoct an example | 13:54 | |
nothingmuch | let's say we have executable byte code called 'a' | ||
it's slow | |||
luqui | sub foo { bar(); baz(); } sub bar() { *baz = sub { "but it doesn't work" } } sub baz() { "I like this optimization" } | ||
nothingmuch | the runtime says "this is unoptimized code, but and we have only spent 1% of the last minute optimizing" | ||
luqui | you can't inline baz()... ever | 13:55 | |
nothingmuch | so it stops for a second, and derives an optimized tree, 'b' out of 'a' | ||
i'm not saying you can | |||
wait | |||
you can | |||
you just have to make the *baz container know about all inlined instances | |||
luqui | so that it can... | 13:56 | |
nothingmuch | and zap them, reverting to "normal" calls, whenver it changes | ||
think of inlining as a cache | |||
luqui | but you see, you're *already* inside an optimized function | ||
when you decide that the function shouldn't have been optimized | |||
nothingmuch | hmm | ||
at the call level i think there is enough abstraction that it is okay | 13:57 | ||
but at the opcode level you are right | |||
luqui | how so? | ||
nothingmuch | putter: ping | ||
luqui | I'm not sure what you mean by the call level | ||
nothingmuch | okay, foo is optimizeed | 13:58 | |
luqui | are you saying that we already have enough indirection there to manage it | ||
nothingmuch | and the calls to bar and baz are already resolved to be a pointer to some code | ||
luqui | (even though we're not discussing any implementation in particular... which has me.. confused) | ||
nothingmuch | in the most extreme solution the opcode and the string are actually inlined into 'baz' | ||
the call to thereof, that is | |||
anyway, bar is executed, and it replaced 'baz' | 13:59 | ||
the baz container was magicified by the runtime | |||
it overwrote the inlined call to baz with code to lookup baz and apply that | |||
worst case scenario - it makes a closure that will do that, an inlines a call to that | |||
and then remembers to reoptimize foo when we're done using it | |||
luqui | buying you nothing over not inlining | 14:00 | |
nothingmuch | no, because the level of indirection is in the baz container | ||
not in the code where baz was inlined | |||
so there is no overhead in executing that code | |||
luqui | oh, you're saying that the assignment to *baz would actually modify the currently executing optree of foo? | 14:01 | |
nothingmuch | yes | ||
luqui | why don't you design a runtime that can do that, because I'm not aware of one :-) | ||
nothingmuch | you make it sound like a bad thing, but let me remind you that inlining in a dynamic system is a bad thing ;-) | ||
luqui | well, I didn't really mean to focus on this particular problem | ||
it was just the case for nonreversible optimizations | 14:02 | ||
nothingmuch | okay | ||
luqui | in most runtimes, you can't undo that one | ||
nothingmuch | then such a runtime is not suitable for a system that needs to be both fast and eval friendly | ||
luqui | taking the standpoint that code in evals need to do basically what they would if they had been evaluated at compile time | 14:03 | |
if you know what I mean | 14:04 | ||
nothingmuch | not that it's that important, if the mega inferrencer detects that *baz is assigned at runtime in code which is not eliminated by the dead code eliminator, then baz should never be inlined | ||
luqui | As far as Larry is concerned, it's okay to allow optimizations that forbid certain kinds of things going on in evals later | ||
as long as you can turn them off | |||
nothingmuch | i agree | ||
or rather, as long as they're off by default | |||
luqui | nope | ||
that's what I thought too | 14:05 | ||
nothingmuch | okay, convince me =) | ||
luqui | I don't have an argument | ||
I think Larry's main argument is a social one, if I picked up on it right | |||
nothingmuch | isn't it dangerous for newbies to be bitten by the "oh, you can't do that unless you 'no optimize eval_wizardry'? | ||
luqui | "I want Perl to be fast out of the box, so it doesn't get a reputation of being slow" | ||
nothingmuch | hmm | ||
okay, that's pretty much the same as my argument | |||
except with different parameters ;-) | 14:06 | ||
luqui | yep | ||
nothingmuch | yeah, i guess speed is more important than corner case flexibility, as long as it doesn't go too far | ||
luqui | the people who are going to be corner-casing are the people who already know a lot of the language | ||
nothingmuch | but anyway, in this specific example, baz() should never be inlined on a runtime that doesn't allow unoptimizing | 14:07 | |
luqui | and know about how perl does optimizations | ||
probably so | |||
nothingmuch | yes, i see, and I think you converted me | ||
luqui | runtime-overriding a function is common enough | ||
that it should be pragmatic to inline rather than pragmatic not to | |||
nothingmuch | hmm | 14:08 | |
you could also make things that are probably not going to be overridden into things that are semi inlined: | 14:09 | ||
an inlined structure that has a cache | |||
or use a cache table indexed by caller position instead of name | |||
luqui | or some kind of lightweight flag | ||
nothingmuch | and have &*baz invalidate that instead | ||
right | |||
that is almost inlining, but not as "hard" | 14:10 | ||
luqui | basically turn bar() into $bar_overridden ?? bar() :: inlined_bar | ||
nothingmuch | i was thinking more along the lines of bar() into $bar.() instead of bsr $bar_addr | ||
where $bar is &bar until the cache is invalidated | 14:11 | ||
luqui | same diff... | ||
nothingmuch | when it is overwritten to be sub { bar() } | ||
no, mine is cooler ;-) | |||
luqui | yours has more abstraction | ||
and less cache locality | |||
luqui points out that he really doesn't know anything about cache locality | |||
unfortunately, one of the nice things you can do with inlining is fold the inlined versions up | 14:12 | ||
and if it's conditional inlining, then you don't get that | |||
you just halve the function call overhead or so... | |||
nothingmuch | right | 14:13 | |
but it's still safe | |||
luqui | (which would have been good enough for Glop, believe me) | ||
nothingmuch | and for where we know that it absolutely is safe to inline, we can still do that | ||
after all &*baz is probably not in the compiled code for every function | |||
luqui | under "use early" ;-) | ||
nothingmuch | 99% chance that none of the prelude is overridden | ||
'use early'? | |||
luqui | hypothetical "use early binding" | 14:14 | |
nothingmuch | uh, why? | ||
luqui | because I like perl for a lot of reasons | ||
and when I don't care to like it for its dynamicity, I can still use it for all those other reasons | |||
nothingmuch | nonono | ||
why only under 'use early'? | 14:15 | ||
luqui | no, we know that it is safe to inline under "use early" | ||
I'm not sure where, but it might be possible other times too | |||
nothingmuch | oh | 14:16 | |
luqui | &::('*baz') = ... | ||
nothingmuch | one time: no instance of 'eval' or 'require' opcodes in runtime code | ||
luqui | breakfast, brb | ||
nothingmuch | this means that any code that is never assigned to, or marked read only, can be inlined | ||
putter | nothingmuch: pong | ||
nothingmuch | which is very good for incremental optimization of one liner scripts that may have to eat huge wads of data | ||
by the time they do 1mb or so, they should be optimized more aggressively | 14:17 | ||
putter: putting parrot dir in $PATH did not solve smoke issues | |||
putter | :( | 14:18 | |
putter wonders if I have ever tried smoke on a non-embedded-parrot pugs | 14:20 | ||
nothingmuch: it's less critical now with the smoke repositiory - I can point folks who need a public smoke of rules to that. | 14:22 | ||
nothingmuch | putter: i'm trying to submit to it =( | ||
but yes, I agree | |||
bbiab | |||
(watching slides of presentation) | 14:23 | ||
putter | hmm... it was you who deleted your automated smoke from the pugs wiki, wasnt it? | ||
nothingmuch | yes, it was | ||
putter | ok | ||
nothingmuch | haddock should still be there | ||
but i think that using iblech's service is better for the community | |||
since my smoke loop is flakey | |||
the problem is that it's the play machine in the house | |||
autrijus | hi from blazingly fast 33.6k modem (for the next 40 hours) | ||
nothingmuch | it gets rebooted every once in a while | ||
and I don't work on it at all | |||
hi autrijus! | |||
putter goes to check wiki... some hacking for high schoolers site apparently announced "unsecured site! you can hack into it by clicking on Edit". apparently never heard of wikis. sigh. | 14:24 | ||
bmonty | can anyone help me with how to determine if there is a file on STDIN with perl? | 14:26 | |
putter | biggest impact of the repository for me is it allows things like pilrun to be smoked, which is still "run make smoke-perl5... check on it later, kill the non-terminating test..." ;) | ||
autrijus | bmonty: not (-t STDIN) | ||
nothingmuch | -t | 14:29 | |
uh, ×××¤× | |||
damnit | |||
that was supposed to be "oopS" | |||
putter | what was that? | ||
nothingmuch | changed lang in the middle to hebrew | ||
putter | lol | ||
scook0_ | oh, the irony! | ||
14:30
scook0_ is now known as scook0
|
|||
nothingmuch | anyway, physical labour is calling... the sun is down, the air is no longer hot and sizzly | 14:30 | |
luqui | 33.6... that's the fast kind right (as opposed to 28.8) | ||
nothingmuch | 56k was the fastest | ||
autrijus | it's the supposed-to-be-56k-but-noise-gets-in-the-way kind | ||
luqui remembers | |||
darn that noice | 14:31 | ||
scook0 | not that anybody EVER got 56k | ||
luqui | noise | ||
well, assuming a noiseless line it's 56k | |||
and noise is something that's not supposed to happen | |||
because physics doesn't exist | |||
putter | bbl & | ||
bmonty | autrijus: can I use your suggestion with if? I want to do if (file on STDIN) { run this code} else {run other code} | 14:35 | |
autrijus | if (-t STDIN) { ...interactive... } else { ...batch... } | 14:36 | |
but this is a #perl question not a #perl6 one :) | |||
(although curiously that should also work with perl6, with STDIN replaced by $*IN) | 14:37 | ||
bmonty | autrijus: ok, thanks....sorry about being in the wrong channel | ||
autrijus | no prob | ||
luqui | ?eval sub foo() { "outer" } sub bar() { my sub foo() { "inner" } foo() } bar() | 14:41 | |
evalbot_6668 | 'inner' | ||
luqui | hmmm... | 14:42 | |
I could have sworn that was broken | |||
oh, it's only wrt operators | 14:43 | ||
sub infix:<@@> ($x,$y) { "$x outer $y" } sub bar() { my sub infix:<@@> ($x,$y) { "$x inner $y" } 3 @@ 4 } say bar() | 14:44 | ||
?eval sub infix:<@@> ($x,$y) { "$x outer $y" } sub bar() { my sub infix:<@@> ($x,$y) { "$x inner $y" } 3 @@ 4 } say bar() | |||
evalbot_6668 | 3 inner 4 bool::true | ||
luqui | uh... | ||
wait | |||
uh | |||
IIRC, I am running evalbot, so it is the same pugs | |||
and it's doing two different things based on whether it's on the command line | |||
luqui is completely perplexed | 14:46 | ||
holy crap | 14:48 | ||
it says "outer" in normal code, and it says "inner" if it's within an eval | |||
wtf | |||
autrijus, do operators not fit in lexical pads? | 15:00 | ||
autrijus | I think it does | 15:02 | |
luqui | well operators cannot be lexically scoped | 15:04 | |
I'm looking into it | |||
and I think I've found the problem (but I'm not too sure) | |||
luqui loves hoogle | 15:05 | ||
autrijus | cool! :) | ||
I'll bbiab. _still_ had not downloaded pugs | |||
luqui | ouch | ||
autrijus | I'm resorting to remotely sync and copying tbz2 over | ||
luqui | oh, btw | ||
autrijus | but even that is ridiculously slow | ||
luqui | is there a "substr" function in haskell | ||
autrijus | sure | ||
luqui | called... | 15:06 | |
autrijus | take 3 drop 4 | ||
or rather, (take 3 . drop 4) | |||
luqui | Oops | ||
I'm an idiot | |||
sorry, is there a "issubstring" function | |||
String -> String -> Bool came up blank | 15:07 | ||
autrijus | [a] -> [a ] -> Bool | ||
luqui | isPrefixOf and isSuffixOf | ||
that's all | |||
well, I'll go ask in #haskell | |||
nothingmuch | luqui: you can recursively apply isPrefixof | 15:09 | |
svnbot6 | r6670 | rafl++ | * Fixes for the PIL2JS README. | ||
r6671 | rafl++ | * Explained the anatomy of the debian/ dir in pugs::hack. | |||
nothingmuch | putter: make clean in parrot tree seems to have fixed it. | 15:14 | |
luqui | ?eval sub <+> ($x) { $x } | 15:43 | |
evalbot_6668 | undef | ||
luqui | that, um, doesn't look like a valid sub name to me | ||
putter | nothingmuch: :) | 16:07 | |
nothingmuch | putter: i thought I had that in the script =/ | ||
putter | ah yes. up there with "I was sure I had that filesystem on the backup list..." | 16:12 | |
putter plays with search.cpan.org/~salva/Language-Pro...aswi-0.08/ | 16:13 | ||
and www.cs.sfu.ca/people/Faculty/camero...p-plg.html Perl Style Regular Expressions in Prolog | 16:17 | ||
geoffb | nothingmuch, ping | 16:53 | |
luqui | autrijus! | 16:54 | |
Eval isn't a monad? | |||
I can't use transforms on it: Type synonym `Eval' should have 1 argument, but has been given 0 | 16:55 | ||
16:59
_SamB_ is now known as SamB
|
|||
autrijus | luqui: Eval is a type synonym | 17:00 | |
luqui: if you want to transform on it, transform on EvalMonad | |||
which is another type synonym with the correct kind | |||
luqui | okay | ||
otherwise it looks exactly the same? | 17:01 | ||
autrijus | yeah | ||
type synonyms are not types | |||
luqui | okay, thanks | ||
autrijus | they are like C macros | ||
so you can't curry them as you can with type constructors | |||
they are of fixed fixity | |||
luqui | :-( | ||
autrijus | er I mean arity | ||
luqui | arity you mean | ||
EvalMonad is not exported from Pugs.AST.Internals | 17:03 | ||
okay to add it to the exports? | |||
hooo-ly crap, I just wrote 30 lines of haskell using monad transforms and stuff and it compiled on the first try! | |||
I fear I'm learning this language... | 17:04 | ||
SamB | whats to fear? | ||
luqui | nothing :-) | ||
Just Fear | Nothing | |||
SamB usually gets loads of type errors, but things that aren't insanely complicated often work on the first succesfull compile | 17:05 | ||
usually, even | |||
even the insanely complicated things work fairly often... | 17:06 | ||
I figured out how to use Data.Generics today... | |||
geoffb | luqui, that looks like a T-shirt, or hat, or something | ||
luqui | geoffb, ? | 17:07 | |
geoffb | "Just Fear | Nothing" -- that's just screaming to be put on swag | ||
luqui | ahh | 17:08 | |
geoffb | Something for autrijus to put in the cafepress store | ||
:-) | |||
nothingmuch | geoffb: pong | 17:38 | |
stevan | @PugsLand = (Fear & Loathing); | ||
nothingmuch | =) | 17:41 | |
loathing is provided by python, fear by weird extensions to haskell | 17:42 | ||
SamB | so who is doing the loathing, and who is fearing? | 17:45 | |
stevan | SamB: it's a junction... and so autothreaded | 17:46 | |
loathing and fearing at the same time | 17:47 | ||
SamB personally experiences more incomprehension the fear about weird extensions to haskell | 17:50 | ||
stevan | luqui: you forgot to update your changelog for C::MM::Pure 0.08 | ||
SamB | s/the/then/ | ||
luqui | oh, was that one of the modules I had a changelog for? | 17:51 | |
okay, I'll have to do that | |||
geoffb back | 18:04 | ||
dangit, I knew as soon as I went and did something, nothingmuch would pong | 18:05 | ||
nothingmuch, what's the darcs address for your harrorth repo? | |||
luqui | geez, it's hard to make nontrivial changes to pugs | 18:13 | |
because running the test suite takes so long! | |||
wilx | I bet that GCC testsuite runs much longer :) | 18:15 | |
And still they are able to do stuff with it. | |||
geoffb | luqui, How long does it take for you, and what are your build options? | 18:16 | |
luqui | let's see, it's been about ten minutes, and I'm up through t/builtins/want | 18:17 | |
coral | given a makefile with each test file as a target whose build command was the pugs test command line, then make -j8 could multithread 8 tests at a time | ||
luqui | though half of the source files are optimized and half aren't | ||
think it's worth putting in the -O time? | |||
autrijus | probably yes | 18:20 | |
coral | regarding an earlier discussion about caching precompiled files on a per-platform basis, a shell script precursor to ccache is here: www.erikyyy.de/compilercache/compil....10.tar.gz | ||
luqui | pugs has a smoke right? | 18:23 | |
yes | |||
nothingmuch | geoffb: feather.perl6.nl/~nothingmuch/harrorth | 18:26 | |
geoffb | ah, cool | 18:37 | |
thank you | |||
I hadn't realized that (like subversion) darcs used the same url for web browsing as for pulling . . . guess I should have tried that, duh. | 18:39 | ||
I blame sleep deprivation. | |||
svnbot6 | r6672 | luqui++ | r548@feather: fibonaci | 2005-09-03 20:40:28 +0200 | 18:44 | |
r6672 | luqui++ | Rewrote findSyms to do real shadowing instead of returning all possible symbols. That is, if | |||
r6672 | luqui++ | there is a matching name in the lexical, it returns no global names. This solves the lexical | |||
r6672 | luqui++ | operator bug. | |||
autrijus | ooh. luqui++ indeed | 18:50 | |
nothingmuch | geoffb: care to help with forth a bit? | 18:51 | |
or actually, anyone? | |||
luqui | what sort of help? | ||
nothingmuch | tests for the return stack | ||
luqui | I suppose it would help if I knew forth | ||
pasteling | "geoffb" at 69.110.115.185 pasted "Earliest beginnings of a Forth interpreter -- starting in Perl 5, will translate to Perl 6 when I have the structure figured out" (286 lines, 8.4K) at sial.org/pbot/12906 | 18:54 | |
geoffb | I wish pasteling's output was in a decent font | ||
anyway, nothingmuch, I figured the best way I could understand enough forth, was to write my own forth interpreter -- and use yours and pforth as sanity checks | 18:55 | ||
It's just at really early stages now (simple interpretation, that's all), but it's a blast | |||
nothingmuch | it's lots of fun | ||
geoffb | NODNOD | ||
nothingmuch | yours is perl 5 cemntered | 18:56 | |
nothingmuch is trying to emulate a real machine, with a heap and stuff | |||
geoffb | As the paste comment says, I'm hoping to convert it to Perl 6 once I have the structure worked out | ||
nothingmuch | i like your way =) | ||
geoffb | :-) | ||
nothingmuch | well, perl cenetered | ||
unfortunately my plans are to compile down to assembley eventually | |||
so I gave up the luxuary of abstract anything ;-) | |||
geoffb | yeah . . . I figured that was the easiest way to start, but as I read in the ANS Forth spec, | ||
nothingmuch 's heap is an array of integers | 18:57 | ||
geoffb | many Forths have two dictionaries, one of clean implementations for interpretation, and one of machine code for optimized compiles | ||
nothingmuch | btw - the input buffer is line oriented | ||
geoffb | nothingmuch, yeah, I know that -- last night I left off in the midst of refactoring the parser to be real. :-) | 18:58 | |
nothingmuch | well, if you like, submit that to the harrorth repo, and share my test cases | ||
geoffb | Let me get it a bit farther, and then I definitely submit it. | ||
nothingmuch | yummy | ||
call it geoforth | |||
geoffb | If I get it to be Perl 6, I may just submit it to the pugs repo. :-) | ||
It's currently "gjbforth" :-) | 18:59 | ||
nothingmuch | fairynuff | ||
=) | |||
geoffb | Although geoforth or geofforth has a nice ring . . . . | ||
nothingmuch | i pronounce it as 'jefforth', but 'geoforth' has a sort of globality to it ;-) | 19:00 | |
geoffb | yeah, that's why I can't decide which spelling I like better. | ||
nothingmuch | have you dealt with VARIABLE and DOES yet? | ||
geoffb | Maybe geoforth as you did it, because of the multiplicity | ||
nothingmuch | those are what made me break down and make a real heap | ||
geoffb | No. As of last night I had: | ||
nothingmuch | (that is, array of integers) | ||
geoffb | 1) a crude repl, | ||
nothingmuch | oh, no IF/ELSE either ;-) | 19:01 | |
naughty naughty | |||
geoffb | 2) a small library of primitives and another libary of preludes | ||
3) a data area, | |||
4) a data stack | |||
The rest is all lies. | |||
nothingmuch | data area? | 19:02 | |
geoffb | There can't easily be if/else without a compile mode, which isn't there yet. | ||
@DATA is an array of ints | |||
nothingmuch | for ! and @? | ||
geoffb | nod | ||
nothingmuch | ah | ||
do you know how ELSE is implemented? | |||
geoffb | Yeah, from the blurb about control structures in appendix A | ||
(Trying to understand it from just the normative stuff in section 6 is not so easy) | 19:03 | ||
nothingmuch didn't read the ANS stuff | |||
wasn't patient enough | 19:04 | ||
it drove me mad with boredom | |||
geoffb | You notice I created the number picture words, basically so that I would have a structure to wrap my mind around when I went to implement control structures and compilation. | ||
yeah, it's very long, but there is a LOT of good info in there. | |||
Especially the rationales and appendices | |||
One of my goals is to have a near-minimal primitive set, so almost everything is defined in the prelude, for obvious reasons. | 19:05 | ||
pasteling | "nothingmuch" at 82.81.247.180 pasted "nuffinforth if/then" (10 lines, 91B) at sial.org/pbot/12907 | ||
nothingmuch | geoffb: mine too | ||
my rationale is user ne optimizer | 19:06 | ||
and since it's open, it might as well be accessible too | |||
geoffb | CM might disagree. ;-) | ||
nothingmuch | CM? | ||
geoffb | nodnod | ||
nothingmuch | oh, right | ||
well, I have very evil plans for optimizer with haskell later | |||
geoffb | yeah, I'm all for open to user base | 19:07 | |
nodnod | |||
:-) | |||
nothingmuch | all i have to do is get that far | ||
geoffb | heh | ||
"nuffinforth"? | |||
Real or a joke name | |||
? | |||
nothingmuch | joke name | ||
geoffb | ok, cool | 19:08 | |
nothingmuch | want to define do/loop for me? i don't feel like it | ||
geoffb | all right, we can chat more about forth later, if you don't mind -- I've got some stuff to do while $toddler is asleep | ||
:-) | |||
nothingmuch | ah, okay | 19:09 | |
have fun | |||
geoffb | Anything you don't define, I will eventually -- I plan to have at least all of CORE and CORE EXT words defined. | ||
thanks! | |||
nothingmuch | oh, biggest hint: | 19:10 | |
implement the diff between immediate and regular as early as possible | |||
it makes you think in terms of IMMEDIATE | |||
luqui | nothingmuch, did you end up writing forth in haskell? | 19:12 | |
nothingmuch | yes, some bits | ||
luqui | cool | 19:13 | |
svnbot6 | r6673 | luqui++ | r552@feather: fibonaci | 2005-09-03 21:49:38 +0200 | 19:53 | |
r6673 | luqui++ | The erroneous "sub <foo>" no longer parses. Sub parameters may now be operators, | |||
r6673 | luqui++ | eg. "sub foo(&infix:<+>) {...}". | |||
nothingmuch | geoffb: i'm 80% done writing my forth's runloop in forth | 20:08 | |
luqui | so you're 40% done eh? | 20:10 | |
autrijus | or 64%? | 20:22 | |
luqui | hmm, did I accidentally break smart match? | 20:26 | |
no.. | 20:27 | ||
what the heck... | 20:28 | ||
has anyone seen this error before: | 20:29 | ||
pugs: *** Language "perl6" unknown. at tmp-Prelude.pm | |||
autrijus | hm looks like you've been mixing prelude and nonprelude compilation. | 20:30 | |
luqui | well I don't think my change touched anything of the sort | ||
so... what could be happening | |||
this is after a make clean; perl Makefile.PL; make | |||
autrijus | hm weird. | 20:37 | |
luqui | do you have the most recent pugs, or are you too slow | 20:38 | |
autrijus | just synced, making unoptimised | 20:42 | |
luqui: it worksforme | 20:50 | ||
try removing the PreludePC files? | |||
luqui | well, it worksforme too | 20:51 | |
try pugs -MNet::IRC | |||
autrijus | got that error | 20:53 | |
strange, it's almost as if the 'lc' didn't work or something | |||
or the 'when' does not | |||
in src/perl6/Prelude.pm | |||
luqui | it's the 'when' | 20:54 | |
I tried lowercasing it elsewhere (literal "perl6" instead of "Perl6"); still didn't work | |||
autrijus | what if you replace when with a series of if? | ||
luqui | strange thing is: ./pugs -e 'eval "<hi>"' works | ||
autrijus | maybe given/when is borken | ||
luqui | well, the tests pass | ||
autrijus | very weird then | ||
luqui | trying if | 20:56 | |
using an if cascade worked | 20:59 | ||
autrijus | I wonder if somehow given/when did not survive -CPugs. | 21:01 | |
unlikely as it seems | |||
luqui | how do I compile a test module with -CPugs in a manner similar to prelude | 21:03 | |
is it fairly easy? | |||
autrijus | -BPugs should do that for you | 21:04 | |
oh | |||
# precompile_modules: [ ext/Test/lib/Test.pm ] | |||
in config.yml | |||
rafl: pugs::hack entries are directories not files | 21:05 | ||
rafl: so I'm not sure your debian/ descriptions belong | |||
rafl: if you feel that they should stay, though, that's fine with me. I fixed your 4-width tabs though | 21:06 | ||
luqui | it seems as though my recent change broke it | 21:09 | |
svnbot6 | r6674 | autrijus++ | * expandtab on rafl's pugs::hack additions. | 21:11 | |
autrijus | mm it's past 5am again | 21:16 | |
probably needs to sleep | 21:17 | ||
autrijus waits for the slow connection to use.perl.org to get through | |||
putter | good night autrijus :) | 21:19 | |
luqui | good night aut | 21:20 | |
autrijus waves & | 21:28 | ||
luqui nap & | 21:34 | ||
masak | i have read the new perl5/Perl6-MetaModel2.0/docs/10_000_ft-view.pod | 21:35 | |
what happened to metaclass? | |||
svnbot6 | r6675 | fglock++ | * perl5/Code - added comments, TODO | 21:42 | |
putter | weary woot - p5 embedded prolog regex engine returning (somewhat bogus but sometimes correct) Match objects. | 21:48 | |
putter evening & | 21:50 | ||
geoffb | OK, lemme get this straight, you've got prolog embedded in P5, and are using that to handle regular expressions in PIL-RUN? | ||
putter | oh, | ||
yes, up until the PIL-Run part. and a very weak value of "handle". | 21:51 | ||
objective is not so much to add regexs to pilrun, but to have some engine, any engine, which actually does non-trivial p6 regex. this would get the grammar-for-perl6 folks unstuck. | 21:53 | ||
p5 is stable. prolog is stable and tolerably fast (even doing interpreted, not compiled, regexes). the interface so far seems moderately stable. unless there are gotchas, it looks like a straight development path. the result isnt something most folks will want to use (linking swi-prolog), but it will get us our first working p6 rules engine. | 21:56 | ||
though... if we're thinking about runtimes using it, pil2js, running under Perl6::Run::JS, could use it equally well... ;) | 21:57 | ||
Juerd | How is PGE coming along then? | ||
dduncan | so, as promised on thursday or friday, I'm going to start expanding any tabs in pugs files today | 21:58 | |
putter | pm had non-PGE work until(?) recently. someone stopped by a couple of days ago wondering if we had heard from him, as he was apparently somewhat out of touch. last I heard, he had a block of time coming up. there was a concept of doing an alternate engine design (as the PGE approach was proving slow). other than, PGE development has not been visibly progressing. | 21:59 | |
Juerd | That's too bad, really | 22:00 | |
Lots of things depend on a rules engine | |||
And I depend on going to bed | 22:01 | ||
putter | A native p6 engine is not difficult to write... but pugs just isnt up to handling it yet. | ||
Juerd | Good night | ||
Be careful with "not difficult"s ;) | |||
putter | g'night | ||
Juerd | afk | ||
putter | :) | ||
also can do partial p6 on PCRE... | |||
"not difficult" compared to the pain so far experienced attempting workarounds... | 22:03 | ||
;) | |||
good night all & | |||
22:15
enilb is now known as bline
|
|||
rafl | autrijus: Hm. Any idea how to tell vim to use tabs or spaces for identing per directory? | 22:28 | |
wolverian | rafl, autocmd BufRead /foo/bar set ... | 22:30 | |
(:h autocmd-patterns) | 22:31 | ||
rafl | wolverian++; #Thank you. | 22:32 | |
wolverian | you're welcome :) | ||
rafl | wolverian: Does it know about regular expressions? | 22:34 | |
wolverian | rafl, :h file-pattern | 22:36 | |
rafl | Yay! | 22:37 | |
autrijus: I think important files should also be described, don't you? | 22:39 | ||
geoffb | rafl, sure, but you have to be willing to keep it up to date (or make sure someone else does), otherwise it becomes worse than useless. Second-level directories was about the best I thought we could manage. | 23:29 | |
The other thing is figuring out not to have it devolve into an unhelpful mess. | 23:30 | ||
Perhaps the best thing is just to put a very good README in the directory in question. | |||
"how not to have it devolve into a cluttered, unhelpful mess" even. Missing a couple words there. | 23:31 |