% Partizx_ has joined #parrot
% Partizx has left Partizx!~Partizx@220.110.142.38
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1096740991.dsl.bell.ca
% barney has joined #parrot
<svnbotlt> r25492 | petdance++ | trunk:
<svnbotlt> : delete_ins() no longer takes a flag saying whether to delete its argument or not.  It assumes yes, and a lower-level flunky function does the work.
<svnbotlt> r25493 | petdance++ | trunk:
<svnbotlt> : delete_ins() no longer takes a flag saying whether to delete its argument or not.  It assumes yes, and a lower-level flunky function does the work.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25493
% iblechbot has joined #parrot
<svnbotlt> r25494 | petdance++ | trunk:
<svnbotlt> : the mk_* functions now all take const char *  name parameters, and will not free their arguments.  str_dup()ing is now done in the mk_* funcs if necessary.  Calling functions now must free the memory if necessary.  This work has not all been done yet, so as of this commit, there are MORE leaks than before
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25494
<svnbotlt> r25495 | petdance++ | trunk:
<svnbotlt> : Pruning the str_dup() calls to mk_* functions that no longer need to exist.  Leaked memory in my test case from 122 blocks down to 78.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25495
% Andy has left Andy!~Andy@64.81.227.163
<svnbotlt> r25496 | kjs++ | trunk:
<svnbotlt> : [cardinal] 
<svnbotlt> : * implement BEGIN and END blocks. 
<svnbotlt> : * stolen from rakudo.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25496
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-196-95.dynamic.mnet-online.de
% cognominal_ has left cognominal_!~cognomina@82.67.232.89
% alvar has joined #parrot
<svnbotlt> r25497 | kjs++ | trunk:
<svnbotlt> : [cardinal]
<svnbotlt> : * add 'module' grammar support
<svnbotlt> : * add test for this, but doesn't run yet.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25497
% cognominal_ has joined #parrot
% cognominal_ has left cognominal_!~cognomina@82.67.232.89
% Partizx has joined #parrot
% HG` has joined #parrot
% Partizx_ has left Partizx_!~Partizx@220.110.142.38
% alvar has left alvar!~alvar@sub87-230-120-57.he-dsl2plus.de
% mj41 has joined #parrot
% kjs_ has joined #parrot
% iblechbot has joined #parrot
<svnbotlt> r25498 | kjs++ | trunk:
<svnbotlt> : [cardinal] add 'and' and 'or' operators.
<svnbotlt> : + set cmdline banner+prompt (initial, just to get a ruby feel)
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25498
% DarkWolf84 has joined #parrot
% DarkWolf84 has left DarkWolf84!~dwolf@89.215.234.147
% wknight8111 has joined #parrot
% barney has left barney!~bernhard@p549A21E2.dip0.t-ipconnect.de
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% AndyA has left AndyA!~andy@82.152.157.85
% wknight8111 has joined #parrot
% man_in_shack has joined #parrot
* man_in_shack waves
<man_in_shack> i was at a presentation on parrot at linux.conf.au
% Andy has joined #parrot
<man_in_shack> made me rather interested in the project :)
<lathos> Excellent!
* purl zwooshes
<man_in_shack> i'm wondering, is there an doc/tutorial on defining your own funky language using parrot? :)
<kjs_> man_in_shack: get your own funky language up and running within 10 seconds: tools\dev\mk_language_shell.pl
<kjs_> and then start customizing :-)
<lathos> Crib mercilessly from languages/abc/, and read docs/pdd26_ast.pod. And ask here. :)
<kjs_> and docs/past_building_blocks.pod :-)
% alvar has joined #parrot
<kjs_> a lot of smileys going on here. I guess we're all very happy :-)
<man_in_shack> no, i'm really depressed :)
<kjs_> get out of your shack ;-)
<man_in_shack> :P
% AndyA has joined #parrot
% Andy has left Andy!~Andy@64.81.227.163
% Partizx has left Partizx!~Partizx@220.110.142.38
<Coke> no one has announced the logging on list yet, haz they.
<moritz> which logging? ;-)
% Coke has left #parrot
% Coke has joined #parrot
* man_in_shack gets out the axe and starts attacking the forrest
<kjs_> i'm working on a quick getting started document for PCT.
<kjs_> when running mk_langauge_shell, a complete language dir is created with all necessary files. However, how to get a Makfile from that root.in that is created?
<kjs_> I always edit config/gen/makefiles/languages.pm (I think it's that file), but is there any simpler way?
<Coke> not yet.
<kjs_> ok, then i'll stick to this.
% cognominal_ has joined #parrot
% gryphon has joined #parrot
% Andy has joined #parrot
<kjs_> ok, done. All interested have a look at docs/pct_for_dummies.pod
<svnbotlt> r25499 | kjs++ | trunk:
<svnbotlt> : [docs] add beginers guide for the PCT to docs directory.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25499
% Andy has left Andy!~Andy@64.81.227.163
<svnbotlt> r25500 | kjs++ | trunk:
<svnbotlt> : [docs] fix pod thingie with an url and some other bit.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25500
% grim_fandango has joined #parrot
% cognominal_ has left cognominal_!~cognomina@cac94-1-81-57-150-201.fbx.proxad.net
<svnbotlt> r25501 | kjs++ | trunk:
<svnbotlt> : [docs] add more info about generated files in pct for dummies doc.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25501
% cognominal_ has joined #parrot
% amoore has joined #parrot
% cognominal_ has left cognominal_!~cognomina@cac94-1-81-57-150-201.fbx.proxad.net
<svnbotlt> r25502 | coke++ | trunk:
<svnbotlt> : [docs]
<svnbotlt> : Use shiny mail alias.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25502
<Coke> kjs?
<purl> i guess kjs is Klaas-Jan Stol <mailto:parrotcode@gmail.com> from The Netherlands or KHTML (read Safari/Koqueror)'s JavaScript engine...
<kjs_> someone stole my nick :-(
<Coke> hate that.
<Coke> We should probably avoid the name "for dummies".
<kjs_> i guess my name is kjsunderscore now :-/
<kjs_> why' that?
<kjs_> a copyright thing?
<kjs_> or tm
<Coke> for dummies is also http://www.dummies.com/WileyCDA/Section/Legal-and-Copyright-Notices.id-100099.html
<kjs_> it could be renamed pct_getting_started
<shorten> Coke's url is at http://xrl.us/bfnr3
<particle> how about docs/pct/getting_started.pod
<Coke> +1
<purl> 1
<kjs_> yep, then the other past doc can also move there
<particle> yep
<kjs_> which i added earlier this weekend
<particle> also, it may be nice to have these docs on a wiki
<particle> (while they're being built)
<particle> then on the website (when they're "done")
<Coke> they can still be in the repo in the meantime, too.
<particle> yep
<Coke> I find I get more feedback at the moment on stuff in the repo than on the wiki.
<particle> i find it's easier for contributers to update docs in the wiki than supply patches to docs
<Coke> YMMV, apparently.
<Coke> I would expect better updates via wiki, they just don't seem to happen for me.
<particle> sheesh, busy weekend. i feel like i'm a month behind
% Andy has joined #parrot
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<svnbotlt> r25503 | kjs++ | trunk:
<svnbotlt> : [docs] rename a file and move pct files into directory
<svnbotlt> r25504 | kjs++ | trunk:
<svnbotlt> : [manifest] update manifest after rename+move of docs.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25504
<kjs_> particle: I sent a patch yesterday for handling the child representing the object for PAST::Vars with :scope('attribute'). Could you check it out sometime this week?
<particle> yep
<kjs_> k thnx
<Coke> kjs++ # docs, cleanup
<kjs_> particle: the document docs/pct/gettingstarted.pod contains a list of common error messages when using pct. if you encounter any new issues while hakcing on rakudo, and you have time, could you add the issue/solution pair there?
<kjs_> (the current list has 1 item, so it's not really a list yet)
<particle> sure
<kjs_> thanks! I think having a list of solutions for common issues can help newcomers, which saves a lot of time answering questions here.
<Andy> Who can recreate stuff from imcc.l?
<Coke> kjs_: when you moved those files, did you use "svn mv" or did you do it manually?
<Andy> I don't know what to do with it.
<Coke> Andy: <handwave> Config with the --maintainer option?
<svnbotlt> r25505 | coke++ | trunk:
<svnbotlt> : [distro]
<svnbotlt> : pass t/distro/*.t
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25505
% zaphod has joined #parrot
<Andy> Coke: I don't know.
<kjs_> Andy: I can if you want
<kjs_> Coke: i use tortoisesvn
<Andy> kjs: Or, tell me what to do.
<Coke> kjs_: so did you use svn to do the rename, or did you do it with windows?
<kjs_> I move files just by dropping them in explorer
<kjs_> windows
<Coke> ... don't do that.
<kjs_> how to move a file?
<Coke> you lose history, and metadata.
<kjs_> renaming I can
<kjs_> oooh
<kjs_> ok
<kjs_> sorry
<Coke> NP.
<Andy> oh loo, right there in the Configure --hepl
<kjs_> Andy: you on linux right?
% peeps[work] has joined #parrot
<kjs_> in parrot/ :
<kjs_> flex -ocompilers/imcc/imclexer.c compilers/imcc/imcc.l
<kjs_> note there's NO SPACE between the -o and its argument value
<particle> kjs_: perl Configure.pl --maintainer # should take care of regenerating imc*.[ch]
<particle> no need to call flex yourself
<kjs_> ooh ok. never knew that
<kjs_> i'm not on linux
<kjs_> i use cygwin
<Andy> yah, I just have to install flex
<kjs_> for flex/bison
<kjs_> 2.5.33 is the latest version I think
<particle> kjs_: that shouldn't matter, as long as configure detects them
<kjs_> at least a good version
<kjs_> particle: yeah but I configure on windows
<kjs_> so i think things go wrong
<kjs_> I think i tried.. it's been a while
<particle> i don't get it. you config on windows, and build on cygwin?
<kjs_> no
<kjs_> i build on windows
<kjs_> but I have put parrot in a directory accessible from cygwin
<kjs_> so I can use the cygwin's flex to generate the lexer
<particle> ok.
<kjs_> so building is alwasy done in cmd.exe, while regenerating in cygwin's shell
<particle> sure would be nice if there was an up-to-date windows port of flex/bison
<kjs_> yeah. especially if we want to create a reentrant lexer, at some point
<particle> it's supposed to be reentrant already
<kjs_> imcc?
<purl> i think imcc is the c of parrot or the problem or the intermediate code compiler
<kjs_> or flex-generated?
<particle> that's why we moved to the versions of flex/bison we have today
<Andy> It fails for me, but I can't see why.
<kjs_> what's the error?
<Coke> particle: there is a ticket for removing globals from imcc that's still open, IIRC.
<Andy> oh wait, I found it.
<kjs_> removing globals from IMCC is a pain. THey're everywhere
<particle> ok, i thought we'd consolidated the globals already
<kjs_> nah, they'ere here and there in imccs backend code
<kjs_> I gave up hope on that already
<particle> kjs_: what's up with pirc? does it run everything imcc does?
<kjs_> it runs all syntactic sugar, but not the ops
<kjs_> because it doesn't know which identifier is an op and which is not
<kjs_> imcc uses "is_op()"
<kjs_> I tried to link to libparrot but somehow couldn't get things properlylinked
<kjs_> so I hardcoded a few ops; they are recognized as ops
<kjs_> just for testing
<particle> ok
<kjs_> but for the rest, it's parsing everything.
<kjs_> I more or less am waiting for a proper API for bytecode
<particle> that's been on jonathan's list a long time
<kjs_> once bytecode+PMC integration/representation works, i can take a look
<particle> ok, then we can benchmark the two, and pick a winner
<kjs_> yeah. Not sure if it's actually faster; it has 3 parts: a heredoc preprocessor; a macro preprocessor, and a Pure PIR parser
<particle> actually, if we're really measuring parsing speed, we don't need to run anything
<particle> do pirc and imcc have parse-only modes?
<kjs_> I wrote a compiler driver which connects the three phases with pipes
<kjs_> pirc only parses currently
<Coke> imcc: no.
<kjs_> well, it builds a datastructure
<Coke> I think the closest you can get is parrot foo.pir -o /dev/null
<particle> imcc will do parse-only on pasm if your first instruction is 'end'
<kjs_> it still executes all the parse actions
<particle> -o should be parse-only.
<particle> it won't run :main or :load or :init
<kjs_> ok. didn't know that. Well, IMHO, speed it not the only quality attribute to be considered. Maintainability is also important
<kjs_> as long as the speed penalty is not too big
<particle> yes, pirc is much more maintainable
<particle> if there's not much speed difference, we should focus on replacing imcc with pirc
<particle> that's what i'm getting at
<kjs_> and the generated lexer doesn't optimize yet i think (there are flex options for that)
<kjs_> yes I 'd like that very much
<kjs_> but the task is just too big for me
<particle> so, we can hook pirc in as an alternate compiler for parrot
<particle> then we could call parrot --compiler=[imcc|pirc] foo.pir -o /dev/null
<particle> et viola. benchmarks.
<kjs_> right. but I think imcc is really close-connected to parrot guts
<kjs_> it's hard to refactor
<kjs_> when you're talking about pirc, I take it you talk about pirc/new (the bison-based impl.), right?
<kjs_> Not the recursive-descen, hand-written one
<particle> iunno
<kjs_> heh :-)
<particle> whatever you came up with
<kjs_> i came up with both :-)
<particle> i just know i guided you towards a nice maintainable design
<particle> it's been a long time since i've looked closely
<kjs_> first the hand-written one, which is hand-written. but later I added pirc/new which is bison/flex based
<kjs_> s/hand-written/recursive-descent/
<particle> src/main.c seems to suggest that replacing imcc is straightforward
<kjs_> good luck :-)
<particle> well, the api is simple. one function initializes the compiler, another runs it.
<kjs_> sure, but the code generation of imcc is a bit tougher
<kjs_> so replacing the parser might not be difficult
<particle> we're talking about parse-only
<kjs_> oooh
<kjs_> right
<kjs_> i've also been thinking about patching imcc heavily, slowly transforming into pirc, but there's some big things that cannot be done in small steps
<kjs_> so IMHO that's not an option
<particle> it is for a branch
<particle> imcc doesn't change much, except for const and PARROT_API etc
<kjs_> good point.
<purl> Thanks, kjs_, I'm glad you agree with me.
% jhorwitz has joined #parrot
<kjs_> there's a lot of code in imcc that is not really clear to me. it might be a good idea to re-implement byte-code generation altogether for pirc
<kjs_> i think imcc has a lot of old code that does stuff which is no longer of interest
<kjs_> or was there for old conventions, old behavior
<particle> i'm sure of it
<kjs_> anyway, pirc already does generate PASM, kinda
<kjs_> but not really runnable pasm; there's no register allocator
<particle> well, that's solvable.
<particle> not trivial, but not terrible
<particle> we already have more than one register allocator implemented
<peeps[work]> could the optimizer do something like this: if there is a branch, and the code on either outcome of the branch starts with the same statements, then put that code before the branch and remove the duplication.  (as long as they are not acting on the register/whatever that the branch is testing?).  i guess it would be more of a space opt. than speed.
<particle> sure, optimizers can move branch instructions around
<particle> they can also modify them to help the cpu with branch prediction by making sure the common case is the one with no branching
<peeps[work]> does that sound like an opt that is worthwhile to do though?
% jjore has left jjore!~jjore@c-24-16-241-176.hsd1.wa.comcast.net
<peeps[work]> i don't really know much about compiler optimizations, was just reading the doc and had that idea.
<particle> what compiler are you talking about?
<peeps[work]> IMCC optimizer i mean
<peeps[work]> http://www.parrotcode.org/docs/dev/optimizer.html
<particle> ok. we have more than one compiler here :)
<kjs_> i think the optimizer could use some work, but imcc must first be fixed (or possibly replaced by pirc) to solve the core functionality
<particle> peeps[work]: so, are you interested in particular in optimizing compilers?
<peeps[work]> i'm interested in optimizing everything :P
<particle> yay!
<peeps[work]> my mind wanders all over the place, i find it hard to stick to particular subjects sometimes.  i'm still reading up a lot on perl and compilers in general
<particle> do you know of ssa and tree-ssa?
<peeps[work]> no
<particle> ssa is static single assignment
<particle> ok. gcc uses tree-ssa to do some wonderful optimisations, and i'd like to implement it for pct
<particle> that would benefit all hlls on parrot
<particle> you can google for 'gcc tree ssa gimple'
* Coke has a copy of the muchnik compiler book and keeps meaning to apply some of the ideas there to parrot.
<Coke> There are a rather scary number of places where optimization could occur for parrot.
<particle> yep
<particle> i'd like to see the optimizations occur at the PAST level
<particle> because then it also benefits other run-time systems
<particle> (if somebody writes a PAST-to-some-other-AST converter)
<particle> in effect, we'd get optimized rakudo-on-dotnet free
<particle> if we have tree-ssa optimizations and a past -> dotnet-ast (i forget what it's called) transform
<zaphod> PAST will need to get some richer nodes in it for that to work well, but I don't see why it wouldn't be possible
<particle> right-o. it's something to work towards
<moritz> do PAST nodes have the type information that you need for cool optimizations?
<zaphod> has anyone looked into the CPS literature for optimizations that can be done?  Parrot uses CPS doesn't it?
<particle> yes, parrot uses cps
<particle> moritz: the type info right now is PAST::Block | PAST::Op | PAST::Val etc
<moritz> ok
<particle> ooh, where did i put that serialized past parser i was working on....
<zaphod> are there any tests for PCT?  I looked a bit and didn't find any.  I wanted to try making a change (the one that I described on the mailing list), but I feel uncomfortable making changes without tests.
<particle> i don't think we have any tests for the compiler/emitter part of pct
<zaphod> hmm, ok
<zaphod> maybe I'll try to put some together if I have some time then
<particle> that'd be wonderful
<zaphod> and what is the relationship between past-pm and pct?
<zaphod> is there something there that I should pay attention to if making changes?
<particle> iirc past-pm is an older implementation of past
<zaphod> ok, so doesn't need to be kept in sync or anything then
<particle> correct.
<purl> no, it's not!
<particle> it seems only lua is using past-pm at this point
<particle> ah, there are some tests for past-pm, perhaps those could be adapted for pct
<particle> see t/compilers/past-pm
<zaphod> thanks, I'll take a look at those!
% cosimo has left cosimo!~cosimo@pat-tdc.opera.com
<svnbotlt> r25506 | petdance++ | trunk:
<svnbotlt> : Don't dup the literal passed into mk_ident().  Also did some consting.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25506
<Andy> YEAH BABY MUCKIN' W/LEX FILES
% HG` has left HG`!~wells@user-514c092e.l1.c5.dsl.pol.co.uk
<jonathan> Woo. One month, three conferences. (GPW, UPW, DPW)
* jonathan likes the look of his February.
% teknomunk has left #parrot
% zaphod has left #parrot
% HG` has joined #parrot
% cognominal_ has joined #parrot
% cognominal__ has joined #parrot
% cognominal_ has left cognominal_!~cognomina@cac94-1-81-57-150-201.fbx.proxad.net
% cognominal__ has left cognominal__!~cognomina@cac94-1-81-57-150-201.fbx.proxad.net
% silug has left silug!~steve@38.104.162.2
<svnbotlt> r25507 | kjs++ | trunk:
<svnbotlt> : [docs] add a common error message+solution to pct docs.
<svnbotlt> r25508 | kjs++ | trunk:
<svnbotlt> : [cardinal] finish operator table and a bit more.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25508
% Student1 has joined #parrot
* Coke suggests that all configure tests go under t/configure ; we have, what, 3 config directory tests now?
% cognominal_ has joined #parrot
* Coke also wonders how t/stress/gc.t is testing our gc.
<svnbotlt> r25509 | kjs++ | trunk:
<svnbotlt> : [cardinal]
<svnbotlt> : + add prefix ops
<svnbotlt> : + add hash constructor
<svnbotlt> : + add parameter declaration
<pmichaud> (reading scrollback) past-pm is deprecated
<pmichaud> iirc, the tests in t/compilers/past-pm were simple sanity tests...nothing that actually tested the output
<particle> seems only lua needs to be migrated
<particle> maybe a note to francois would be enough to get it done by 0.6.0
<particle> so we can rip it out
<kjs_> Francois also wrote his own past->post conversion I think
<kjs_> would that have any consequence for converting?
% cognominal_ has left cognominal_!~cognomina@82.67.232.89
<pmichaud> it might.
<kjs_> pmichaud: yesterday I sent a patch to list for handling objects for :scope('attribute'); I asked particle to have a look at it.
<pmichaud> yes, I'm catching up on email today
<pmichaud> I've been out with the flu :-(
<kjs_> ohw, too bad
<kjs_> flu sucks
% integral has left integral!bsmith@adsl-212-20-244-147.lumison.co.uk
% integral has joined #parrot
* Coke ponders if tcl was using past-pm.
<particle> a recent ack for past-pm suggests it's just lua
<particle> but please check!
<particle> coke: consolidating config tests is a good idea
<kjs_> I strongly get the feeling that a complex grammar can slow down a generated parser... could that be true?
<Coke> ... plumhead...
<Coke> perl6/ROADMAP
<pmichaud> until we get some of the longest-token matching/dfa stuff implemented in pge, it can be a bit slow.
<Coke> pheme...
<purl> pheme is probably a Parrot-based implementation of Scheme
<pmichaud> especially if there are a lot of tokens
<kjs_> can it be becuase of a lot of ? quantifiers?
<pmichaud> ? by itself shouldn't slow things down
<pmichaud> depends on what is being ?ed
<particle> add more ':'
<kjs_> those are do not backtrack markers, right?
<particle> yep, : :: and :::
<pmichaud> tokens and rules don't backtrack already, though
<particle> right, it's only regexen
<particle> s/n$/s/
<kjs_> ok, well i don't use thm
<kjs_> regex
<pmichaud> although '::' could speed things up slightly
<particle> does : operate the same with | and || ?
<kjs_> ruby is really really similar to perl and python. never knew that. Makes writing cardinal easier :-)
<pmichaud> particle:  afaik, it's basically the same
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-204-180.dynamic.mnet-online.de
<svnbotlt> r25510 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Duplicate some strings in the parser so as not to free passed-in strings.
<svnbotlt> : This adds a few leaks temporarily, but they're pluggable.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25510
<svnbotlt> r25511 | kjs++ | trunk:
<svnbotlt> : [cardinal]
<svnbotlt> : + add grammar for meth.calls and stuff
<svnbotlt> : + not working yet.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25511
<pmichaud> kjs:  iirc, :scope('attribute') already exists in PAST.  I think jonathan++ added it.
<jonathan> pmichaud: Get well soon.
<pmichaud> I think I'm in good shape now... but this weekend was pretty bad
<jonathan> Ugh. But glad you're recovering.
<pmichaud> me too.  fortunately we didn't have the kids this weekend -- that would've been rough.  (otoh, I probably caught it from the kids, so...)
<pmichaud> jonathan: got your email on OO implementation -- I need to catch up on other things (and make oscon proposals), so will try to get to it tomorrow.
<jonathan> pmichaud: OK, sure. Do you think the re-ordering in past -> post is a bug, or do I need to work around it myself, or is that too hard to answer right off (if so I can wait :-)).
<pmichaud> I'm not sure it's a bug... more like "something we haven't dealt with yet"
<jonathan> OK.
<pmichaud> handling class creation in PIR is still a bit of a black art, I fear
<pmichaud> gotta run for a bit... bbl
<pmichaud> (I hope)
% silug has joined #parrot
<kjs_> msg pmichaud: ('attribute' already exists) yes, but not the handling of the object for the attribute; it currently only works for "self"
<purl> Message for pmichaud stored.
% Schwern has joined #parrot
<Schwern> Hi folks.  How has parrot solved the Y2038 problem?  I want to try and steal it for Perl 5.
<TimToady> well, Perl 6 solves it by specifying all times in floating point. Can't speak for parrot though.
<Schwern> Yeah, I saw pugs has it licked.
<particle> i'm not sure we've attacked that yet
<Schwern> I'm trying to find a license-compatible C implementation of localtime_r() really
<particle> iirc we're using platform-dependent values for dates
<Schwern> ouch
<particle> ya.
<Coke> (floating point)... I can't help but think that's gonna bitecha.
<particle> that's what oracle does, innit? DATE.TIME
<Schwern> Hmm, Parrot's perl6 doesn't appear to implement localtime() yet
<particle> nope, doesn't.
<Schwern> Oooh, libtai is public domain
<Schwern> As terrifying as the idea of using djb-ware is.
<Schwern> "TODO: support time zones"  <<--- nuts
<particle> seems everybody's waiting for some intrepid developer
<svnbotlt> r25512 | kjs++ | trunk:
<svnbotlt> : [cardinal] extend grammar for rule lhs, with indexed and member fields. no proper actions yet.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25512
<Schwern> Well, I'm getting more trepid by the day.
<Schwern> Sometimes I feel like that guy when the ask for volunteers to step forward and everyone else steps backward. :)
<Schwern> ciao
% Schwern has left Schwern!schwern@mungus.schwern.org
% cognominal_ has joined #parrot
<TimToady> Coke: when I say "floating point" I mean double precision at least
<TimToady> but the integer part is plenty adequate to represent many millenia of seconds
<TimToady> and time is a "real" quantity, so we need a datatype that doesn't have to be scaled explicitly every time you use it
<TimToady> or combined with milliseconds, or microseconds or whatever fooseconds the computer measures time in
<TimToady> Doubles are the closest thing we have to continuous values
<TimToady> and it's my feeling that by the time doubles aren't big enough, we'll be using 128-bit floats, or 256, or...
<kjs_> pmichaud: (class handling as black art) maybe it's an idea to have a ".class" directive that takes a key as argument (exactly as .namespace), but in addition to .namespace, the class is created automatically (this code is generated, as opposed to writing it manually) Not sure about how to handle inheritance.
<svnbotlt> r25513 | kjs++ | trunk:
<svnbotlt> : [cardinal] add more grammar stuff. do a bit of refactoring here and there.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25513
<kjs_> (ehm, if it wasn't clear, that would be a PIR directive)
<Coke> (continuous values) I would argue about time being a continuous value. =-)
<moritz> I'd say that you can't really be sure
<Coke> TimToady: ... not that that would help my previous assertion.
<particle> coke: which way do you argue?
<Coke> ISTR from quantum that there is a plank time; it's not obvious that time is continuous below that.
<Coke> (analogous to the plank length)
<Coke> ... none of which has anything to do with whether or not floats work for time. =-)
<Coke> er, and that's spelled "Planck", of course.
<particle> yep
<pmichaud> well, technically floats are quantum as well :-)
<Coke> planck time is http://en.wikipedia.org/wiki/Planck_time
<pmichaud> of course, the float quanta are probably different than the time quanta :-)
<particle> there are energy quanta, too
<Coke> lesssee... one planck time is about 5.4 x 10-44 s. I think we're safe for now.
<Andy> has anyone looked at my memory stuff?
<pmichaud> kjs: (class) right now the way we have to create classes is to do it in a :load/:init (or possibly :immediate) sub of some sort.  And once we get into inheritance, we have to make sure the classes are being created in the correct sequence
<Coke> Ob: I was going to, but I forgot.
<particle> andy: stop being overly descriptive.
<Coke> Seriously, which memory stuff now?
<pmichaud> (more on classes)  and also Parrot likes to throw exceptions if we attempt to create a class that already exists, so we have to guard against that possibility as well.
<kjs_> pmichaud: i know about the current setup for creating classes, and you're right in wanting to guard it. It just seems that many parrot-targeting languages define classes as perl does
<kjs_> so for all of them we have to do the same tricks to get things working
<pmichaud> right
<kjs_> looks like an opportunity for a shorter huffman code to me ;-)
<pmichaud> I do intend for PAST to make that relatively straighforward
<pmichaud> you and jonathan are just moving a week or so ahead of me on that :-)
<kjs_> oh right, past can also do it :-)
<kjs_> yeah, you got my message?
<pmichaud> yes
<pmichaud> I didn't realize that :scope('attribute') was tied to self.  You're correct that it needs to be available for any object.
<kjs_> it is with the supplied patch :-)
<kjs_> the code may be a bit crappy, but this was the best i could come up with
<pmichaud> well, we really need a way to represent 'self' in PAST
<kjs_> (there's an unnecesssary goto somewhere i think)
<svnbotlt> r25514 | kjs++ | trunk:
<svnbotlt> : [cardinal] add hash stuff. 
<svnbotlt> r25515 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Updating IMCC header, which somehow lost its generated file warning from
<svnbotlt> : a previous commit.
<svnbotlt> r25516 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Removed one memory leak from the lexer.  More remain.
<pmichaud> I haven't decided if that's a PAST::Val, PAST::Var, or what.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25516
<pmichaud> or even a PAST::Op
<kjs_> sure, but I figured having a default to "self" if you don't specify an object would be good
<kjs_> yes, particle also said something like that yesterday: either val or var
<Andy> particle: YOu know, the memory things.
<Andy> The stuff!
<purl> the stuff is in scope because the methods are _written_ in that scope
<Andy> Am I the only one who reads what I send to p2?
<Andy> AM I?
<Andy> AM I ALL ALONE HERE?
<pmichaud> default to 'self' might work
<pmichaud> I'll have to think about it a bit more
<Andy> Why didn't Drivin' 'n' Cryin' get any bigger?  It's a sham.e
<kjs_> at least for the 'attribute' scope setting thingie
<pmichaud> I don't think there are many defaults in PAST::Var to begin with, so I'm not sure this is the place to add one
<kjs_> I meant default to self , if PAST::Var( :scope('attribute') does not have a child
<pmichaud> right, I took it that way.
<kjs_> ok
<kjs_> i see your point of making exceptions
<kjs_> or, rather not making them
<pmichaud> just aiming for foolish consistency
<particle> 's not so foolish
<kjs_> but OTOH, it seems to be a bit inefficient to create nodes if it's not necessary; it's yet another object..
<kjs_>  i know i know, don't optimize yet :-)
<pmichaud> well, 'not necessary' depends on how often it actually occurs in hll compilation
<pmichaud> for example, there are a ton of opcodes in Parrot that PAST never makes use of, but which were added because a compiler might find them useful :-)
<kjs_> ok, well FYI, I added some bits to pdd26 describing 'attribute', and it also mentions defaulting to self. so if that's going away, maybe i should remove that
<pmichaud> I'll review it and make a decision this week.
<kjs_> yep, well maybe we can use them later when past is optimized
<pmichaud> iirc from my graduate studies on RISC vs. CISC architectures, what often tends to happen is that it's too much work for the compiler to find the cases where the specialized opcode is of any benefit
<kjs_> that may especially be true for dynamic languages, where compiletime is often runtime
<pmichaud> compilers like to have regular instruction sets without lots of special cases
<kjs_> well, iirc, the idea is that in a risc arch. the instructions are highly optimized (fewer instructions but faster); for parrot it doesn't matter; all instructions are in software
<kjs_> ohyaa, I was thinking lately of tailcalls. with subs possibly consisting of several nested PAST::Blocks, does tailcalls still work?
<kjs_> I mean, the whole advantage of tailcalls is stack stuff efficiency; if returns are implemented as exceptions, there's a lot of overhead, no?
<particle> risc vs cisc still matters for security
<particle> only certain PAST::Block objects will have return handlers
<particle> specifically, 'immediate' won't
<particle> however, they may have loop handlers
% jhorwitz has left jhorwitz!~chatzilla@pool-68-163-25-103.phil.east.verizon.net
<kjs_> mmm ok. I don't know that much about it :-) Just thought about the difference between a program in pure PIR and generated PIR from PAST ,which is much more complex
<kjs_> well, time to sleep. good night
% kjs_ has left kjs_!~IceChat7@ip565fd420.direct-adsl.nl
% amoore has left amoore!~amoore@65.165.109.82
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% davidfetter has joined #parrot
% Student1 has left Student1!~chatzilla@139.147.232.198
% skids has left skids!bri@charon.clarku.edu
% Limbic_Region has joined #parrot
% sjansen has joined #parrot
% Ademan has joined #parrot
<svnbotlt> r25517 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Fixed another IMCC memory leak related to the great I Won't Free Your
<svnbotlt> : Strings If You Call Me update.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25517
<svnbotlt> r25518 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Whacked one more memory leak.  All coretests and Rakudo tests still pass.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25518
% Schwern has joined #parrot
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% wknight8111 has joined #parrot
% kid51 has joined #parrot
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% alvar has left alvar!~alvar@sub87-230-120-57.he-dsl2plus.de
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
% kid51 has left kid51!~jkeen@pool-71-247-56-8.nycmny.east.verizon.net
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<svnbotlt> r25519 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Clean up the formatting of this supplementary file.  Now it's slightly
<svnbotlt> : easier on the eyes.
<svnbotlt> : If you read very carefully, you'll notice that I deleted a free() called on a
<svnbotlt> : passed in string.  Yikes.
% Limbic_Region has joined #parrot
% AndyA has left AndyA!~andy@82.152.157.85
% AndyA has joined #parrot
* Coke finally has 2 seconds to announce the logging on list.
% petdance has joined #parrot
% Theory has left Theory!~Theory@dsl093-038-250.pdx1.dsl.speakeasy.net
% Ademan has left Ademan!~dan@h-68-164-171-226.snfccasy.dynamic.covad.net
% Ademan has joined #parrot
<svnbotlt> r25520 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Plugged a few more memory leaks.  These are not the big ones, but even
<svnbotlt> : the little ones add up over time.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25520
% HG` has left HG`!~wells@user-514c092e.l1.c5.dsl.pol.co.uk
* Coke updates the website a smidge.
<Coke> ... is RT dead slow for anyone else atm?
* particle won't use rt again until it has a nice ui
<particle> *cough* hint *cough*
<Coke> ... would you care to setup an RT instance for me? Oy.
<particle> as easy to set up as combust?
<Coke> that's the other thing I need to do.
% Partizx has joined #parrot
<Coke> As anyone who looked at the website 12.3 minutes ago noticed.
% HG` has joined #parrot
* Coke gives up his one claimed parrot ticket to work on less fun stuff.
<svnbotlt> r25521 | coke++ | trunk:
<svnbotlt> : [docs] Add reference to YART in this method.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25521
* Coke grabs apache, mod_perl, and a cup of coffee.
<Coke> tanjit. mod_perl requires a perl you can muck with. (so I can't just use whatever's available on feather.)
<man_in_shack> hmm
% tcoppi has left tcoppi!~thisnukes@dhcp-west-76.resnet.nmt.edu
% tcoppi has joined #parrot
* Tene goes to search for caffiene, to hopefully do some language hacking tonight.
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% apple-gunkies has joined #parrot
<svnbotlt> r25522 | petdance++ | trunk:
<svnbotlt> : bonked a few more memory leaks
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25522
* Coke drinks a CokeZero
% Theory has joined #parrot
% HG` has left HG`!~wells@user-514c092e.l1.c5.dsl.pol.co.uk
<svnbotlt> r25523 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Plug another small handful of memory leaks.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25523
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% davidfetter has joined #parrot
<petdance> anyone wanna eyebal a proposal?
<Coke> sure.
<petdance> http://nopaste.snit.ch/12275
% Andy has left Andy!~AndyL@host3130.follett.com
% petdance is now known as Andy
<man_in_shack> i'm very, very new to this project, but it seems to me that all of those questions have already been addressed
<Andy> man_in_shack: Sorry, it's not about Perl 6.
<Andy> It's a proposal for a talk at OSCON
<man_in_shack> ah ok
<man_in_shack> in that case, go for it ;)
<Coke> Looks good. one minor nit: "guided by the same rules running businesses". I think you're missing a "as those for" or some other connector.
<Coke> Having been to your technical debt talk, I'd probably go to that one.
% jjore has joined #parrot
<Andy> Coke: Thanks.
<Andy> It's not the people who already like me I want to sway, though. :-)
<svnbotlt> r25524 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Plug yet another memory leak.  This one's much closer to the
<svnbotlt> : mysterious big ones.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25524
<Coke> ... You presume too much!
* Coke gives up on trying to install combust on feather for now.
<Andy> Bye bye combust
<Andy> yet another reason for starting a new website.
<Andy> It's fine for Ask & Robrt, but I feel like I'm too puny to grasp it.
<svnbotlt> r25525 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Plugged most of the larger leaks in IMCC.  It leaks about half as much
<svnbotlt> : memory as when Andy and I started today.
<svnbotlt> : These mem_sys_free() calls are mostly bandages on the real problem, which is
<svnbotlt> : the str_dup() call for the STRINGCONSTANT lexing rule in imcc.l.  Something in
<Coke> Once it's setup, it's ignorable. You just need to be something closer to a sysadmin than I am today to set it up.
<Andy> I'm trying to think of a way to turn ack into a 45-minute talk.
<Tene> So, .arity() doesn't provide the information I need to implement expression handling for lolcode.
<Andy> I need an angle.
<Coke> 269 degrees.
<Tene> I could probably add something like min-arit(), max-arity(), has-slurpy() to sub.pmc, but I don't know if that's the right approach.
* particle hurls $P0.arity( PARAMS_SLURPY | PARAMS_OPTIONAL );
<particle> ...suggested api...
<Tene> That looks a lot nicer.
<Tene> return value for something with slurpy args?  -1?
<particle> right now, arity is positional only. you want to be able to do slurpy only, optional only, combinations, etc
<particle> correct?
<Tene> Right.
<Tene> Well, all I really need is the minimum and maximum number of possible arguments.
<particle> with Inf being maximum for slurpy?
<particle> do you need to differentiate named from positional?
<particle> hrmm. ok. here's the thing:
<particle> let's ignore named for the moment
<Tene> I don't right now, as lolcode can't pass named.
<particle> .arity() gives you positional. that's your minimum.
<Tene> Right.
<particle> optionals don't count towards minimum
<particle> slurpy gives max of infinity automatically
<particle> optionals count towards max
<particle> does lolcode have slurpy?
<Tene> I would imagine PARAMS-OPTIONAL would also include optionals, and PARAMS-SLURPY would return Inf if any exist.
<particle> well, .arity() doesn't return (min, max) now
<Tene> It can call slurpies just fine, but can't create.
<Tene> VISIBLE is slurpy
<particle> ah, right.
<particle> so, no user-defined
<Tene> Right.
<particle> ok, that means you can special-case them
<Tene> Hm?
<particle> they're all "known knowns"</rumsfeld>
<particle> all the slurpy functions are keywords
<particle> or ops, or whatever you call them
<Tene> particle: until you have someone mixing lolcode with code in another language.
<particle> there's a defined set.
<particle> oh, please! keep it simple.
<particle> we'll build that in incrementally
* particle starts writing two more talk submissions for oscon *sigh*
<Tene> Simplest really would be if I could discover if a sub has slurpy params.
<Coke> tene: it is desirable to allow inter-HLL calling; but there's no real working code doing that now.
<Tene> Coke: you don't anticipate more methods to look at the param list of a sub being useful?
% Schwern has left Schwern!schwern@mungus.schwern.org
<Coke> Sure.
<Coke> I'm suggesting that you don't need to solve everything at once if that makes it hard. If it doesn't make it hard, nevermind, go ahead. =-)
<particle> it seems we can solve this by passing args to .arity()
<Tene> I agree.
<Andy> WHO WOULD LIKE TO SEE THE HAPPIEST KID IN THE WORLD?
<Tene> Have it return required+optional if :optional is passed, and return Inf if :slurpy is set and a slurpy param exists?
<particle> .include 'call_bits.pasm' ; .sub 'test' :main ; ... ; $I0 = my_sub.'arity'( PARROT_ARG_INTVAL | PARROT_ARG_STRING | PARROT_ARG_PMC | PARROT_ARG_FLOATVAL )
<Coke> Andy: ... Ok, I do.
<Coke> particle: you can't do that in one line in PIR, canya?
% skids has joined #parrot
<particle> what do you mean, .'arity'() ?
<particle> oh, i see the pipes
<particle> i guess not
<Andy> http://www.flickr.com/photos/petdance/2238371942/
<particle> it'd be $I0 = ... | ... ; $I1 = my_sub.'arity'($I0)
<Coke> Andy: cute.