r25928 | fperrad++ | trunk: : [Lua] : aligned with Lua 5.1.3 (part 3) diff: http://parrotvm.org/svn/parrot/revision/?rev=25928 % dwolf_ has left dwolf_!~dwolf@89.215.234.147 % ewilhelm has joined #parrot % HG` has joined #parrot % IllvilJa has joined #parrot % mire__ has left mire__!~Frodo@80-169-222-85.adsl.verat.net % mire__ has joined #parrot % davidfetter has joined #parrot hello privet, davidfetter. anybody going to FOSDEM? % SCalimlim has left SCalimlim!ImustDIE@cpe-67-49-40-137.socal.res.rr.com % particl1 has joined #parrot % particle has left particle!~particle@c-24-19-3-148.hsd1.mn.comcast.net % particl1 has left particl1!~particle@c-24-19-3-148.hsd1.wa.comcast.net % wknight-away has joined #parrot % particle has joined #parrot % rdice has joined #parrot % wknight-away has left wknight-away!~nobody@c-71-230-33-251.hsd1.pa.comcast.net davidfetter: I'm going to FOSDEM (I'm presenting there) afk # making breakfast for kids % UltraDM has joined #parrot % kid51 has joined #parrot % davidfetter has left davidfetter!~chatzilla@start.fetter.org % kid51 has left kid51!~jkeen@pool-71-247-46-160.nycmny.east.verizon.net % cognominal_ has joined #parrot r25929 | petergibbs++ | trunk: : Fix typo in r25897 i.e. changed INTERP to interp. diff: http://parrotvm.org/svn/parrot/revision/?rev=25929 % rdice has left rdice!~richarddi@CPE001217e365c7-CM00159a01d44c.cpe.net.cable.rogers.com % diakopter is now known as diakopte1 23:59:47 <@pmichaud> okay, will do. ugh; accidental paste % Coke has joined #parrot % diakopte1 is now known as diakopter * Coke ~~ good morning morning jackass purl, I think you have me confused with my brother. pmichaud: i'm not following you... arguing with a bot is like wrestling with a pig -- you still get dirty. And the pig likes it. heh pmichaud++ fixing tags. (svn++ cheap copies) Coke: need a copy of the announcement? please let kid51 know what happened, so he can be careful not to do it again I'm still not sure what happened. :-) I'm guess he did an svn del of tags/ instead of tags/some_tag normally we don't delete things in tags/, though ... he does all the time, sir. kid51 uses tags to mark his branches all the time *branches*, yes. tags/ ahhhh okay he should mark his branches in branches, then (imo) it's not a bad system. beats manually keeping track of where you branched from. er, s/branched from/merged last/ If you can come up with a better system, by all means. Honestly, I don't think one accidental rm is the end of the world; we are using version control. =-) anyway, I'm likely to be afk most of today (on a plane), so maybe someone else can mention it. but yes, someone should mention it. ... ok. I'll volunteer. I agree, it's not the end of the world -- I wasn't even going to say anything about it. anyone have the ability to change module ownerships in PAUSE? the module owner. I haven't been able to index the release tarball in CPAN because rgrjr owns three of the modules. pmichaud: one of us will track him down. (I sent him email last night but no response yet) ah. well, then, he'll get to when he does. it's not a showstopper. well, I'm *hoping* to have some form of network access at various points throughout the day. % Andy has left Andy!~Andy@64.81.227.163 % gryphon has joined #parrot % Andy has joined #parrot r25930 | petergibbs++ | trunk: : In tonumber, wait until we have finished with the C string before releasing it. : This significantly improves the 'make test' results for lua. diff: http://parrotvm.org/svn/parrot/revision/?rev=25930 petergibbs? coke++ for the c macro args test i believe i have a ticket for that effort. oh and the copyright is wrong in the nopaste % kj has joined #parrot % rdice has joined #parrot particle: yes, I claimed the ticket. the copyright'll be updated before commit. my one concern is that the test should not force extra unneeded parens however, i don't know if that'll happen we have so many c scanning code snippets. we should really have a c scanning library instead particle: so far the test is catching two things that are actually broken, but the RE I used is naive. Coke: there are some tickets that seem to be forgotten, and imho, could be closed. Shall I send a mail to list describing them, so that others could have a look and comment on them? yeah. right. it'd be nice to use languages/c99/ to parse our c kj: sure. You could also reply to the individual tickets. Coke: yes that's what happens most of the time with these tickets... that's the whole point. There's no feedback. i only found 5 or so; but at least it's a start to clean up a bit % Andy has left Andy!~Andy@adsl-75-11-88-206.dsl.chcgil.sbcglobal.net the only difference doing it outside of RT is tha there's then no record of this meta-conversation about the ticket. which is, IMO, not a good difference. yes, you're right. I'll reply on the tickets. % uniejo has left uniejo!~uniejo@langebro.adapt.dk (cc the list, of course. =-) aye particle: shouldn't we use c89 to parse parrot's c? well... we should enforce c89 standards we need a c parser right. but wouldn't it be better to implement a c89 parser? instead of a c99? a c parser with 89/99/etc modes sounds more flexible but anything that works is what we need now r25931 | petergibbs++ | trunk: : luastring.pmc: The %S shortcut for %Ss fails at the end of the format string : os.t: Correct expected output for year 1000 to match lua's output diff: http://parrotvm.org/svn/parrot/revision/?rev=25931 off to the airport -- bbl r25932 | coke++ | trunk: : [codingstd] : Add a (naive?) test to check that args in macro definitions are wrapped. : RT #47109 : There are currently 2 failures when running this test hurm. that test is wrong. I didn't check the error messages; those failures are near unwrapped args, though. damnit. % cognominal_ has left cognominal_!~cognomina@AAmiens-157-1-119-141.w86-215.abo.wanadoo.fr r25933 | particle++ | trunk: : [t] ws fixup diff: http://parrotvm.org/svn/parrot/revision/?rev=25933 particle: ping. my Re was more than naive. =-) pong yep, seems pretty darned broken :) I have a better one now, but it's still not quite right. commit early! I'm getting 56 failures atm. "coke" at 72.228.52.192 pasted "small patch, better results" (13 lines) at http://nopaste.snit.ch/12377 But I'm still missing a few failures. (at least) yep. i say commit it. we need line numbers, too actually, we don't macro name should be enough So what was the bummer with 6.say? I can totally see why the parser would be confused. % AndyAway is now known as Andy * particle doesn't know what's up with 6.say yet % UltraDM has left UltraDM!~george@dasapass.avira.com I can't see how we could reasonably expect the parser to be happy w/that. why not? everything in perl 6 is an object say is a method. and because "s" isn't a digit, parser should know that the . isn't a decimal, but a method caller Hi folks. Friendly neighborhood oper here. I was wondering if it was possible to get the owner of svnbot1 to add just a bit of throttle on how fast that bot spits lines to irc. the bot keeps accidently setting off network flood alerts. Obviously it's not a real flooder. kismet: i thought we did add throttling. i'll look into it what's the limit? the limit is, like, very implementaiton specific I think it's over 4 lines in 3 seconds or so wow. that's low. ok well, just limit it a bit, and we'll see if that helps. More than happy to work with you. roger, wilco. thanks. I'll go back to idling now. :) % Theory has joined #parrot particle: committed, then. % bphillips has joined #parrot r25934 | coke++ | trunk: : [codingstd] : A definite improvement to the regular expression checking for unwrapped : macro args. : Still not perfect. diff: http://parrotvm.org/svn/parrot/revision/?rev=25934 r25935 | petdance++ | trunk: : fix the "say " diff: http://parrotvm.org/svn/parrot/revision/?rev=25935 purl, forget the limit Coke: I forgot limit % Theory has left Theory!~Theory@dsl093-038-250.pdx1.dsl.speakeasy.net % DarkWolf84 has joined #parrot % BinGOs has joined #parrot % BinGOs has left #parrot % jhorwitz has joined #parrot % sjansen has joined #parrot the problem with 6.say is that PCT keeps the '6' as an integer constant, instead of making it into a PMC thus it generates PIR like 6.'say'() this is rt#51052 the signature used to generate the children nodes in PAST::Compiler needs to take into account the difference between 'call' and 'callmethod' and make sure that the invocant is a PMC I'll try to fix it from the airport (while eating lunch) pmichaud: this is something I struggled with in tcl; I pretty much never get to use the non PMC registers. :| well, in this case it's not a problem of non-PMC registers -- it's actually generating a constant i.e., the PIR literally reads 6.'say'() however, PCT is smart enough to be able to know when it has to convert things to a PMC, and when it can leave them as a constant or register constant is no different than $I0 there. (PCT smart enough) ah, that's cool. I just have the signature wrong for callmethod, which needs to force the invocant into a PMC Enjoy your trip. plane doesn't leave for another 90 mins. right now I'm having fish and chips -> errans -> errands, even. r25936 | pmichaud++ | trunk: : [pct]: : * Fix 'callmethod' nodes so that they coerce the invocant into a : PMC instead of sometimes using a constant. : * Resolves RT#51052, reported by Tene++ and Andy++ . % nnunley has joined #parrot pmichaud++ there's a test that can be changed now, andy tene: btw we use [rakudo] instead of [perl6] now in bug reports, and they can be submitted to rakudobug@perl.org that's all pretty new. i still screw it up. Thanks. actually, if submitted to rakudobug@, you don't even need [rakudo] pmichaud: any specific hacking plans on the planes? test committed woohoo! c99 parses a simple struct :-) r25937 | particle++ | trunk: : [include] ws cleanup r25938 | petdance++ | trunk: : "6.say" : now works diff: http://parrotvm.org/svn/parrot/revision/?rev=25938 particle: was mostly going to clean up stuff. perhaps play with .HLL as I've been meaning to for a while. I might also catch up on some sleep and save the hacking for the ord->bru flight (hacking sleep)++ I'm inordinately tickled that I wrote a test that turned up a bug. % rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com (tests that expose bugs)++ andy: tickle yourself more often. write more tests! (self tickling)++ er...hrm. % rdice has joined #parrot I just don't know what's been done yet. which is why I wanna get the list together of "This is done, this isn't/" that list is in the pugs repo. we call it t/ actually, t/spec/ well, eventually it'll be t/spec/ oh, I might also play with listop parsing I don't have a pugs repo but there's some conversion yet to do our testing Great Need is converting tests to t/spec/ s/converting/migrating/ are there people around who are very much attached to the current c99 implementation in languages/? svn co http://svn.pugscode.org/pugs/t/ pugs-tests kj: nobody. particle: I started a clean implementation using the mk_language_shell script and I start to get things running now excellent! Smithers, release the hounds! the current implementation is not working at all. so I guess I can overwrite it? yes, please or if you want, create languages/c89/ c99 was initially created with the ability to parse c++ headers in mind so t/spec is in the Pugs repo? andy: yes and rakudo's 'make spectest' does svn co although doing 'make spectest' in languages/perl6/ (parrot repo) will also check out a copy of t/spec maybe I'll review tests on the plane particle: but it's based on a reference for c99... although sleep is starting to seem far more likely kj: okay, then. anyway, time to head to the gate safe trip! * particle will likely hack perl6doc more, and migrate some tests to t/spec/ Surprised there's no branches/trunk in pugs andy: yes, it's a problem with that repo, imo * spinclad 2 % Theory has joined #parrot % Theory has left Theory!~Theory@dsl093-038-250.pdx1.dsl.speakeasy.net particle: were you ever able to match the contents of a POD block? jhorwitz: yes. particle++ * jhorwitz checks his working copy... "particle" at 24.19.3.148 pasted "a brief example of perl6doc" (89 lines) at http://nopaste.snit.ch/12378 that's with a small local patch there, patch committed now the bodies can be reformatted to squash whitespace r25939 | particle++ | trunk: : [rakudo perl6doc]capture pod bodies, and process pod options diff: http://parrotvm.org/svn/parrot/revision/?rev=25939 and of course the actions are wrong now, as you can't emit html etc so $ contains the meaty goodness? indeed * jhorwitz is off to play --target=parse is your friend don't i know it... ../../../../parrot perl6doc.pbc --target=parse foo # generates and displays the parse tree from file foo --target=[parse|past|post|pir] PCT is the greatest thing since sliced arrays. ;-) % Ron has joined #parrot mm. c's grammar is not as straightforward as I thought :-/ % destiney has joined #parrot r25940 | petergibbs++ | trunk: : Add tag to newly-added struct in line with coding standards. diff: http://parrotvm.org/svn/parrot/revision/?rev=25940 r25941 | kjs++ | trunk: : [c99] : add new action/grammar for c99. : update MANIFEST diff: http://parrotvm.org/svn/parrot/revision/?rev=25941 r25942 | kjs++ | trunk: : [c99] : -update main file : -add builtins file and directory : -update MANIFEST % mire__ has left mire__!~Frodo@68-168-222-85.adsl.verat.net r25944 | kjs++ | trunk: : [c99] : fix root.in; I forgot to change a few "c"s into c99. r25945 | kjs++ | trunk: : [c99] % mire__ has joined #parrot % HG` has left HG`!~wells@user-514f4552.l3.c3.dsl.pol.co.uk % HG` has joined #parrot particle: what was your idea with the c99 language? what kind of back-end, one that checks for Parrot coding standards? kj: there's a few things we want to do. one is coding standards. another is generating nci stubs from headers. r25946 | kjs++ | trunk: : [c99] : + finish operator table : + finish some other rules. : + grammar mostly complete now. Needs testing and refactoring a bit. C::Critic ala Perl::Critic would be great mm .ok. I don't know what the latter does, but I'm sure it can be done :-) * particle is currently working on a yaml dumper for past at least languages/c99 is building now, which is better than when I started :-) * jonathan has made it to Ukraine. yes, definitely better :) I'm hoping for <%hash> to be working sometime in PGE that would fix one ambiguity in C's grammar. Oh, interesting. I have a half-finished patch that attempts to implement indirect method calls... * jonathan wonders when he coded this jonathan: it's from the future. Can the future send me more half-complete patches, so I only have to do half the work? you'll have to wait and see. On PAST::Var nodes, you can only set :name to a string constant? How will we support indirect (dynamic) lookups? r25947 | kjs++ | trunk: : [c99] : It's important to set the precedence of "term:" special rule tighter than the tightest operator; otherwise this won't work. Note to self: add this to operator table guide. diff: http://parrotvm.org/svn/parrot/revision/?rev=25947 Should PAST::Var with no name take a first child which gives the name> s/'>'/'?'/ jonathan: that would make the :name attribute rather special. Of course, one could argue that the name is the most important thing of a Var but there's also a :scope attribute, that is obligatory. Yeah. Hmm. Not sure what a Good Solution is. :-) IMHO, it's not really the same as a PAST::Op :pasttype('call'), where the first child is the sub to be invoked Sure. but what do I know :-) Would be good to have some way to do this. OTOH, if it solves your problem % cout has left cout!~cout@c-68-58-247-49.hsd1.sc.comcast.net it's no longer an exception, is just The Way To Do It (whatever you're doing) I mean, if it's a common language construct where common is used by at least one language :-) s/is/means/ % chromatic has joined #parrot afk for a bit % sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com % PacoLinux has joined #parrot % cout has joined #parrot % sjansen has joined #parrot % Ron_ has joined #parrot % Ron has left Ron!rblasch@M1607P024.adsl.highway.telekom.at % davidfetter has joined #parrot there. i think the c_macro_args tests is now usable. * Coke finally finds U+236A, and asks larry for a patch to APL on Parrot. crap, ww, ws, ... % slightlyoff has left slightlyoff!~slightlyo@204.14.154.209 r25948 | coke++ | trunk: : [codingstd] : Instead of writing a single RE that catches the bad case while ignoring the : good cases, remove all the good cases first, and whatever's left is broken. : This brings us to a more reasonable and accurate 50 incorrect #defines. Coke: metathesis is one of the few prohibited operations on Unicode characters :) % Andy is now known as AndyAway r25950 | kjs++ | trunk: : [docs] : add a note about is tighter in 'term:' special rule in optable. diff: http://parrotvm.org/svn/parrot/revision/?rev=25950 question: in define foo(a) (*a) is the *a allowable there? or should that be: *(a) ? *(a) seems righter sorry, don't know... *a should be fine as it's just straight text substitution, but *(a) is probably "safer" ok. just wondering how smart the dumb macro catcher has to be. sounds like it's dumb enough. perljam: the parens are necessary for safety Remember how dumb the preprocessor is in C. r25951 | chromatic++ | trunk: : [Lua] Cleaned up the LuaAny PMC. It shouldn't leak any memory now. diff: http://parrotvm.org/svn/parrot/revision/?rev=25951 chromatic: your mother's prepocessor is sooooo dumb... % Ron__ has joined #parrot if you have define foo (a,b) (a)[b] is the b safe? or should that be (a)[(b)] ? the latter well, the latter is better % Ron_ has left Ron_!rblasch@M114P011.adsl.highway.telekom.at Coke, are you planning to update the website, or should I stab it? ah, crappity. please do. I had meant to do it and was distracted. % cognominal_ has joined #parrot r25952 | chromatic++ | trunk: : [PMC] Minor cleanups of the LuaNil PMC. diff: http://parrotvm.org/svn/parrot/revision/?rev=25952 % HG` has left HG`!~wells@user-514f4552.l3.c3.dsl.pol.co.uk oh. hee. fixed another macro arg checker bug... bringing us to 502 errors. ah, that's better. are you skipping generated files? I'm just getting a list of C files. if the C file were generated by perl, we'd have no way of checking the perl code. yes. some of which are generated. yes. and we should be checking them. =-) right, but not fixing them inplace. r25953 | coke++ | trunk: : [codingstd] : ... Might be nice to warn about all the errors in a file, not just the first. diff: http://parrotvm.org/svn/parrot/revision/?rev=25953 that's all i'm saying anyway, it's looking like a much better test now actually, I think were only reporting errors if the first define if the file happened to have an error; and there were *still* 50. % Ron__ has left Ron__!rblasch@M174P022.adsl.highway.telekom.at there. I gave up #47109 for now in case anyone wants to fix the macro errors now that there's a test to narrow down the search. awesome. coke++ % wknight-away has joined #parrot meh. I dislike spending time on things that aren't features, but better I do it and leave the features to someone who can implement them. :| http://groups.google.com/group/bsdmailinglist/browse_thread/thread/5182e6eeab833de4/3a47f3b7d4e985da?hl=en&q=parrot+-site%3Aperl.org+-site%3Aparrotcode.org+-site%3Acpan.org+-perl.perl6+-perl.cvs#3a47f3b7d4e985da Coke's url is at http://xrl.us/bgjv7 % mdiep has left mdiep!~mdiep@v-adsl-fh-178-170.umnet.umich.edu % kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl Did FreeBSD send us a bug report? % Theory has joined #parrot % chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net % chromatic has joined #parrot What should be done about http://rt.perl.org/rt3/Public/Bug/Display.html?id=46635 ? raising an overflow error would probably make the most sense Silently promote to BigInt? * davidfetter hands chromatic a copy of the source for libdwim.so ;) should likely be controlled by a pragma or we should have separate Integer PMCs, one that promotes, one that doesn't or perhaps s/pragma/attribute/ depending on whether you want to make it scope controlled or object controlled see? there are lots of possibilities that's why i didn't want to submit a patch yet % wknight-away is now known as wknight8111 Hey, silent truncation is the source of a great deal of suck in C and its derivatives. ok, well how about this... the least surprise for today's current behavior is what? overflow exception, probably. so move forward with that, based on 'least surprise' (re)design is definitely warranted. if you want to take a stab at designing a better solution, try that next okay, i'll work on a patch that calls an overflow error actually, an overflow type exception can be caught and can cause a promotion so, try generating an exception object and throwing it so it shall be, now and forevermore % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk what would be the best way to do that here, real_exception()? see what the 'throw' opcode does ...or use it. okay where are the opcode actions defined? src\ops\*.ops % Theory has left Theory!~Theory@dsl093-038-250.pdx1.dsl.speakeasy.net yeah, that's what i figured. i'll find it all from there AHA a bug in Lua! A GC bug no less. anchoring? r25954 | chromatic++ | trunk: : [Lua] Minor cleanups to the LuaFunction PMC. diff: http://parrotvm.org/svn/parrot/revision/?rev=25954 LuaThread stores a Parrot coroutine PMC in PMC_pmc_val, then sets the mark flag. mark() marks PMC_struct_val. Goodbye, coroutine. That doesn't fix the strange string problem, but it fixes one problem. % PacoLinux has left PacoLinux!~paco@139.Red-80-36-122.staticIP.rima-tde.net % rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com (refactoring code to coding standards)++ r25955 | chromatic++ | trunk: : [Lua] Fixed a GC bug in LuaThread -- mark() marked the wrong thing as live. diff: http://parrotvm.org/svn/parrot/revision/?rev=25955 Are there any autovivification tests in the Array code, because I'm not sure it does what it thinks it does. % diakopter is now known as diakopte1 % diakopte1 is now known as diakopter % Limbic_Region has joined #parrot % iblechbot has left iblechbot!~iblechbot@ppp-62-216-198-33.dynamic.mnet-online.de % chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net cotto_: ResizablePMCArray tests should include autovivification hrmm, seems Hash always stores values as PMCs.... % davidfetter has left davidfetter!~chatzilla@start.fetter.org What about vanilla Array? it says it does in the source, but the implementation doesn't look like it would work % chromatic has joined #parrot i don't know anything that uses Array. we recommend using Fixed* or Resizable*Array I was just looking at the code as an example Perhaps the other arrays would serve me better Array PMC is *very* old. and mostly deprecated, however unoffical now I find out are the others better? iirc Array may have some sparse handling in it, others don't yet. otherwise, the others are much better ResizablePMCArray is widely used by HLLs