% zostay has left zostay!~Hanenkamp@75.39.134.250 % Ademan has joined #parrot % zostay has joined #parrot % teknomunk_ has left teknomunk_!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net r29789 | fperrad++ | trunk: : [Lua] OpenGL, fix constants diff: http://www.parrotvm.org/svn/parrot/revision?rev=29789 % iblechbot has joined #parrot % iblechbot has left iblechbot!~iblechbot@ppp-62-216-204-154.dynamic.mnet-online.de r29790 | fperrad++ | trunk: : [Lua] OpenGL, fix glut.Init() diff: http://www.parrotvm.org/svn/parrot/revision?rev=29790 % workbench has joined #parrot % Schwern has left Schwern!~schwern@069-064-236-003.pdx.net % bacek has left bacek!~bacek@122.110.86.26 r29791 | fperrad++ | trunk: : [Lua] OpenGL, fix demo diff: http://www.parrotvm.org/svn/parrot/revision?rev=29791 % bacek has joined #parrot % Casan has joined #parrot % masak has joined #parrot are the first two items in languages/perl6/ROADMAP ('list context, list assignment', and 'return and control exceptions') only partly implemented, or is ROADMAP out-of-date? rakudo: my @a = (1,2,3); say @a # this counts as list assignment to me OUTPUT[123␤] rakudo: sub foo { return; say "world" }; say "hello"; foo # and return seems to work fine OUTPUT[hello␤] time to update ROADMAP? masak: I believe things like ($a, $b) = 1,2; will not yet work, so list assignment ain't really done yet. ah. And return isn't 100% there either, not are other control exceptions. I see. So both items have progress, but aren't complete. what is it about return that isn't 100%? I think returning more than one thing. rakudo: sub f { return 1,2 }; say f OUTPUT[too many arguments passed (2) - at most 1 params expected␤current instr.: 'f' pc 96 (EVAL_13:41)␤called from Sub '_block11' pc 17 (EVAL_13:11)␤called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)␤called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1088 ..(src/PCT/HLLCompiler.pir:610)␤called from Sub 'parrot... seems so. so the list assignment thing and the return thing are actually a bit related? I suspect so, yes. ($a, $b) = f(); # with the f in your example above is this functionality far off? what's blocking it? I think it may need PGE changes. why? I'm not entirely sure, and I may be mis-remembering that. I'm just trying to think through how to implement it... I know it's on Patrick's todo list, so I haven't given it a whole load of thought. I think it's something to do with knowing you parsed a list on the LHS so you can parse the RHS in a different context. masak: BTW, willl you be at YAPC::Europe::2008? yes. Cool. :-) aye, I look forward to it :) Patrick and I are hacking the day before and after. we'll be there. Awesome. (viklund is coming too) vilund? *viklund you met him and me at NPW2008 Yes, I'm trying now to put a face to the name... Anyway, looking forward to the conference and hacking. Need to write my talks, still! :) jonathan: http://www.flickr.com/photos/jooon/55661136/ I'm only going to show examples, that will run already in Rakudo. viklund is "some guy with ear muffs" :) Aha! Yes, I remember now. Can we check instead of interpinfo .INTERPINFO_RUNTIME_PREFIX . "/runtime/parrot/include/config.fpmc" also for "/lib/parrot"... This is in parrotlib.pir and config.pir rurban: I expect that would work out for UNIX-y systems, yes. We need something probably more generic though, to handle Win32. I dont want to set PARROT_RUNTIME_ROOT for installed versions all the time. even on unix systems /usr/runtime is non-FHS compliant Hmm --prefix=/usr * jonathan knows nothing about FHS in Cygwin I did setting a symlink from /usr/runtime to /usr/lib but on debian e.g. we will not be allowed to do so. Yes, of course. Indubitably. purl: Is that even a word? Should we not be installing with a configuration where INTERPINFO_RUNTIME_PREFIX is set to the right thing? Or is that not settable at "make install" time? It'd seem we know what it's going to be at that point... but after INTERPINFO_RUNTIME_PREFIX there comes runtime/parrot Geck, yes. and runtime/parrot is only valid from source Meaning we'd have to install to /lib/parrot/runtime/parrot to get that to work! uness you hide it behind /usr/lib/parrt/runtime or somewhere. Yeah yep. Ugly. --prefix=/usr/lib/parrot Maybe including the runtime/parrot in the build (non-install) INTERPINFO_RUNTIME_PREFIX would do it? or better --prefix=opt/parrot So INTERPINFO_RUNTIME_PREFIX is "...what it was before.../runtime/parrot" I rather think of checking prefix.lib/parrot first and then for the runtime/parrot path I'm just testing it. OK I'm afraid I'm likely not the best person to ask on this - I can help with Parrot guts-ish stuff, but I'm not at all familiar with Linux/UNIX packaging-ish things. The mailing list is good - if anyone replies. ;-) INTERPINFO_RUNTIME_PREFIX is the same as Env PARROT_RUNTIME_ROOT or just "/usr", the prefix Ok, I added my patch at http://rt.perl.org/rt3/Ticket/Display.html?id=56996 % Ademan has left Ademan!~dan@h-67-101-47-36.snfccasy.dynamic.covad.net % Ademan has joined #parrot % jan has left jan!~chatzilla@217-210-56-147-no52.tbcn.telia.com % ruoso has left ruoso!~ruoso@201009045132.user.veloxzone.com.br Cannot we persuade parrot;PCT::HLLCompiler;initnot to load config.pir at runtime on a language pbc. the config hash is already linked unfortunately we don't know at run-time if the config hash is loaded or not. _config returns just a hash but does not side-effects, like creating a global symbol % bacek has left bacek!~bacek@122.110.76.89 % rurban has left rurban!~chatzilla@212-183-55-198.adsl.highway.telekom.at % kid51 has joined #parrot % rurban_ has joined #parrot % rurban_ is now known as rurban r29792 | fperrad++ | trunk: : [Lua] OpenGL, add glut.DestroyWindow() diff: http://www.parrotvm.org/svn/parrot/revision?rev=29792 r29793 | fperrad++ | trunk: : [Lua] OpenGL, check config diff: http://www.parrotvm.org/svn/parrot/revision?rev=29793 % jan has joined #parrot % Whiteknight has joined #parrot r29794 | jkeenan++ | parallel: : [configure] Fine-tuning of tests for configuration steps. Clarify POD. : Provide inline comments functioning as subheads where tests previously found : in multiple files have been moved into a single file. Use : Parrot::Configure::Test::test_step_constructor_and_description() to eliminate : repeated code. Delete outdated comments. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29794 r29795 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] turn off iterative behavior to expose some underlying problems that need fixin' diff: http://www.parrotvm.org/svn/parrot/revision?rev=29795 r29796 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] update to trunk r 29793 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29796 % Whiteknight has left Whiteknight!~Whiteknig@pool-72-78-158-31.phlapa.east.verizon.net r29797 | jkeenan++ | parallel: : [configure] Fine-tuning of tests for configuration steps. Clarify POD. : Provide inline comments functioning as subheads where tests previously found : in multiple files have been moved into a single file. Use : Parrot::Configure::Test::test_step_constructor_and_description() to eliminate : repeated code. Delete outdated comments. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29797 r29798 | fperrad++ | trunk: : [Lua] OpenGL, refactor glut callback diff: http://www.parrotvm.org/svn/parrot/revision?rev=29798 r29799 | jkeenan++ | parallel: : [configure] Fine-tuning of tests for configuration steps. Clarify POD. : Provide inline comments functioning as subheads where tests previously found : in multiple files have been moved into a single file. Use : Parrot::Configure::Test::test_step_constructor_and_description() to eliminate : repeated code. Delete outdated comments. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29799 % kid51 has left kid51!~jkeen@pool-70-107-8-165.ny325.east.verizon.net % jhorwitz has joined #parrot % iblechbot has joined #parrot % kid51 has joined #parrot r29800 | jkeenan++ | parallel: : Provide inline comments functioning as subheads where tests previously found : in multiple files have been moved into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29800 r29801 | jkeenan++ | parallel: : Restore incorrectly deleted subroutine import. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29801 % davidfetter has joined #parrot Can someone merge #57296: [TODO] make install -C languages with #56554: [TODO] add languages/*/Makefile install targets please? The second is a duplicate but has a better description and a patch. % cognominal has left cognominal!~cognomina@82.67.232.89 r29802 | jkeenan++ | parallel: : [configure] Fine-tuning of tests for configuration steps. Clarify POD. : Provide inline comments functioning as subheads where tests previously found : in multiple files have been moved into a single file. Use : Parrot::Configure::Test::test_step_constructor_and_description() to eliminate : repeated code. Delete outdated comments. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29802 % cognominal has joined #parrot rurban: Which do you want to be the surviving ticket? #56554 please. But add the desc and patch from the newer to the older. I forgot that I already submitted this as TODO The patch is still about 50%, but it is getting bigger and bigger. % Andy has joined #parrot Done. kid51++ thanks rurban: BTW, I don't like having our installed lib prefix be anything other than /usr/lib/parrot. If the problem is that we will get /usr/lib/parrot/runtime/parrot/, then that is what needs to be fixed. (Though I have realized what may be the reason for the seemingly pointless runtime/parrot -- someone's ancient expectation that languages would put their runtimes in runtime/ as well? I'm happy to get rid of runtime/parrot at run-time, but I will not change the src layout The languages put their runtimes into runtime/parrot/dynext In that case, /parrot/ should go away. Mostly needed is just runtime/parrot/include/config.pir, from PCT::HCTCompiler I realize you don't want to do this, but enter a ticket for it. I will happily vote +1. % cognominal has left cognominal!~cognomina@82.67.232.89 The ticket already exists: #56996 [TODO] remove non FHS-compliant searchpaths % masak has left masak!~user@130.238.45.242 I finished now my final cygwin package for 0.6.4 and will evaluate eventual problems there. Then I will change the runtime paths to favor /usr/lib/parrot over /usr/runtime/parrot I believe there are still some more problematic errors in the run-time. Why does compiler/PCT/HLLCompiler loads config.pir at runtime? _config is already linked to the language. _config() should set some side-effects so that the run-time can detectd an already linked conf_hash and not try to load config.pir at runtime. problem is that config() is a function and no global hash I see no problem changing that from a function to a global hash This should help building with installed parrot also. % cognominal has joined #parrot rurban: Two things: 1) As I mentioned in ticket 56996, we should prefer /usr/lib/parrot over /usr/runtime/parrot *NOW*. 2) I meant that you should enter a ticket for changing the source tree to get rid of /parrot/ under runtime/. You don't have to be the one to implement it (I understand your reticence to make large changes to the repo), but it definitely needs a ticket. Do you really want to go this way? What I want is not to change the src layout and just fix the run-time behaviour for an installed parrot. This installable_perl should never check /usr/runtime But to accomplish this I must get rid of run-time access to config.pir wbecause I want only loading config.fpmc, and for installable@exe this is not needed at all, because config.fpmc is already linked to the binary. Checks in the build_dir should safely still access runtime/parrot/... That's why I suggest a ticket. My preference would be to change the source tree, so that runtime/parrot/foo becomes runtime/foo, and we don't get an ugly installed version of /usr/lib/parrot/runtime/parrot/foo/, and there are no hacks in the code that try both .../runtime/parrot/foo and .../runtime/foo. That's just wasted stat()s. It is possible someone may disagree with me, but we can argue that in the ticket. Ok. let's suggest changing the src layout, but this needs higher powers than me. So you would have to add this ticket :) Huh? Anyone can enter the ticket. Do you think it is good if I suggest such a major change? "As discussed with japhb in IRC ..." And then I will happily jump on the bandwagon. :-) japhb: It looks like you're the one who's eager to have this new ticket. Why don't you open it? well oh well. I'd rather keep it this way. OK, sheesh. fine, will do. :) What I want is just to clean out cornercases where the linked install_config.o is not used at all, and some lib still wants to access runtime/parrot/include/config.pir or such. And get rid of all runtime/ paths in the linked installables. That's a separate question. Some architect like Allison should explain that And I found cases where languages want to access compilers/... which are never installed. (lua) nod I wonder how debian,fedora, gentoo test their languages packages. japhb: Actually I dislike the idea to mv runtime/parrot/* to runtime/ why? Righ now I have the simple workaround to symlink /usr/runtime to /usr/lib, which works fine for some months. % Ademan has left Ademan!~dan@h-67-101-96-146.snfccasy.dynamic.covad.net As you mentioned, that workaround is just wrong. Debian would, as you said, never allow it. When all the langas haev been fixed I can remove the symlink rurban: It's not just the languages, it's load_bytecode yeah. I still have to read the differences between .include and load_bytecode though And load_bytecode either has to know that in some places it will use .../runtime/parrot/foo, and in others use .../runtime/foo, or we have to accept .../parrot/runtime/parrot/ in the installed space. Which is wrong. I want load_bytecode and .include to know if there's a global conf_hash around. Maybe that's what interpinfo .INTERPINFO_RUNTIME_PREFIX is for. % cognominal has left cognominal!~cognomina@82.67.232.89 OK, ticket submitted * japhb sends a good-natured raspberry in the general direction of kid51 Ok, and I'm now fighting to get rid of unnecessary stats in config.pir, because _config should already be loaded. Fight the good fight, rurban! % cognominal has joined #parrot % Ademan has joined #parrot r29803 | jkeenan++ | parallel: : [configure] Fine-tuning of tests for configuration steps. Clarify POD. : Provide inline comments functioning as subheads where tests previously found : in multiple files have been moved into a single file. Use : Parrot::Configure::Test::test_step_constructor_and_description() to eliminate : repeated code. Delete outdated comments. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29803 rurban: Your work has certainly elevated the visibility of Cygwin in these parts. I hope some day you do a conference presentation on Cygwin -- about which many, including myself, are very ignorant -- and on Cygwin in Parrot. well, Cygwin is irrelevant for these topics. debian and fedora should have also detected those problems. Just Win32 is a little bit different conferences: my day job doesn't allow me to travel too much. I work in Formula 1 and I'm very busy. I can't recall a presentation on Cygwin at any YAPC::NA. A perl.com article, perhaps? Well, from time to time I help out Indycar and nascar in the states. Then I'm in the area. Or at least a posting on use.perl.org. use.perl.org is fine. I update my journal from time to time anyway. installation for pugs on cygwin e.g. or the latest cygwin release for parrot, and my progresses with the perl5 compiler B:C For the real hairy stuff you have to boot into a linux VM anyway to do some valgrind checking or some dtrace But basic strace or gdb sessions do work find for cygwin. Analyzing coredumps not so. % DietCoke has joined #parrot * DietCoke yawns. japhb: What's your ticket id? I just wrote a new use.perl journal hurm. in my working copy of partcl, I have a test that fails with 'make test', but works when run directly with prove t/cmd_vwait.t. bah. http://use.perl.org/~rurban/journal/37023 % kid51 has left kid51!~jkeen@pool-71-247-58-198.nycmny.east.verizon.net rafl: ping fhs I can't find fhs in the DNS. r29804 | coke++ | trunk: : [tcl] http://code.google.com/p/partcl/issues/detail?id=59 : Part of the eventual switch to PCT involves changing how we attempt to compile. : This reverts tcl to a pure runtime dispatch for each command; The ".tmt" : files we had been using to generate PIR to use in place of the runtime call : are now gone. : In most cases, just used the version that had been automatically generated by : the original system. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29804 r29805 | coke++ | trunk: : [tcl] bring documentation closer to reality. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29805 % Theory has joined #parrot r29806 | coke++ | trunk: : [tcl] rename make target 'tcl-test' to 'spectest' : (in harmony with ../perl6) diff: http://www.parrotvm.org/svn/parrot/revision?rev=29806 % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.wa.comcast.net * jonathan wanted coke to rename it to test-tcl * DietCoke wonders how to do this in C: http://www.tcl.tk/man/tcl8.5/TclCmd/tclvars.htm#M26 * DietCoke has an approximation in languages/tcl/src/pmc/tclfloat.pmc //get_string DietCoke: pointerSize ? jonathan: *blank stare* DietCoke: Which bit of the document are you referring to? jonathan: tcl_precision That link showed up with the pointerSize entry at the top of the page for me. Aha. * jonathan reads whoops. http://www.tcl.tk/man/tcl8.5/TclCmd/tclvars.htm#M27 * DietCoke bets they renumbered the entries in the past 4 years. DietCoke: Isn't it a sprintf formatting thing? I hope so; that would simplify the code. =-) hurm. I wonder if this was left in an over-complicated state. DietCoke: %.*f or similar may do it (you invoke it as I guess something like printf("%.*f", THE_LENGTH, value) I think) the printf code in tclfloat is currently: buff = Parrot_sprintf_c(INTERP, "%.*vg", precision, PMC_num_val(SELF)); But you'll need to handle the default 0 case specially. Aha. So is precision not just the tcl_precision value? ... at one point, using 0 for the precision did not have the desired result. * DietCoke is trying to find out if that is still the case, or if something chnaged in the N years since this was written In that case, I guess you need to test for that having a 0 as the tcl_precision and if so, do something different. ... yes, but -what-. =-) precision of 0 for parrot seems to mean "show only one sigfig" Is what Tcl wants for the default value of 0 not the default if you just use %g? ah, that's better. =-) ah, here we go. Yes, %g gives results likeE: # got : '0.785398' # expected : '0.7853981633974483' for tcl_precision=0, which now implies a simple %g. % Paul has joined #parrot Hey everybody everybody is depraved (I am trying to figure out if there is a %lg or %Hg or something that will work, but lg dies, and Hg gives me a lot of nans. i have a question i am developing my own scripting language and i am trying to decide on a VM so i ask what does parrot give me that the JVM does not already have depends on your scripting language. Paul: parrot is designed for dynamically typed languages Paul: JVM is higly optimized for statically typed ones it is dynamically typed ahhh thats very useful to know how is it optimized for dynamically typed languages? it doesn't require you to declare types on your variables ;-) :-P Paul: maybe you might be interested in http://en.wikibooks.org/wiki/Parrot_Virtual_Machine/Squaak_Tutorial There are also a bunch of features that are supported in Parrot that dynamic languages often use, without needing to re-invent the wheel, which may well happen if compiling a dynamic language down to run on a static VM. moritz: that's misleading. :| DietCoke: yes, it is For example, runtime of eval of code (calls back into compilers) are pretty trivial. moritz: What about mozilla rhino though? You don't have to declare types in javascript Paul: dunno, never played with that rhino thing Paul: may I ask what kind of language do you want to implement? Paul: There are languages running on Parrot that allow and enforce type constraints/declarations, and there are many more that don't. They also have things like jython and a LISP compiler for the JVM I'm writing my own language for academic purposes % Ademan has left Ademan!~dan@h-67-101-148-197.snfccasy.dynamic.covad.net that will have the features that I've always wanted in a language Sure. I'm not sure if the JVM has a common framework for dynamic languages, like the .Net DLR (Dynamic Languages Runtime for the .Net CLR), to help factor out some of the common bits that dynamic languages need. % Schwern has joined #parrot Another attraction Parrot offers is its compiler toolkit. Which means you end up mostly just writing the front-end of the compiler and not having to worry at all about code-gen. (Because there's a common AST format, and a backend to transform it into the intermediate code) moritz: You going to be at YAPC::EU, by the way? moritz: Thanks for that wikibooks link. I'm going to implement Squaak now and then work on my language afterwards. jonathan: sadly not :( moritz: Ah, shame. :( indeed. Hopefully next year In Soviet Russian, the YAPC attends you. ;-) If they get it! btw I've seen your various bug fixes, jonathan++ http://perlgeek.de/blog-en/perl-6/huffman-tree-with-rakudo.html I fear if they do, we'll have an entire conference of In Soviet Russia jokes. On the other hand, last time there was a YAPC in Portugal, it was three days of Perl programmers wearing fishnets... moritz: Nice link! :-) thanks ;) jonathan: I threw my question out to p2. % Ademan has joined #parrot DietCoke: Cool. I'm afraid my printf not-exactly-fu was exhausted... thanks for trying. =-) moritz: Seeing things like this makes me feel like we're getting somewhere. jonathan: I should start trying the various modules in ext/ in the pugs repo and speaking of "getting somewhere", I hope you've seen that STD.pm now parses 99% of the spec tests? moritz: For sure. It'll be good to know what we're missing, if anything. No, where is that written about? % Andy is now known as AndyAway But wow, that's good progress. http://www.perlmonks.org/?node_id=700400 Now we just need to get Rakudo to parse STD.pm. :-) TimToady sometimes annotated with commit messages with the percentages, the last one was 98% s/with/his/ and I tried it a few hours ago, one test looping, one test failed, all other parsed correctly Great. We need more spectests. ;-) and more larrys ;-) well, Auzon is working on that (more spectests) and I'm too, from time to time % cesar has joined #parrot Yes, I've noticed we're getting more and more. I'm trying to make sure whenever I fix something or add something there's no tests for, I at least add some basic tests for it. * Auzon is working on a monstrous regex test at present :) Nice! Auzon++ with a plan of 500odd tests, iirc Well, making it so Rakudo can run it, then adding more tests to fill it out. 535, yes. % AndyA has left AndyA!~andy@ca93nt.hexten.net Tene: ping % cesar has left cesar!~pcalcina@143.107.45.13 % AndyA has joined #parrot % rurban has left rurban!~chatzilla@212-183-83-63.adsl.highway.telekom.at If anyone's looking for stuff to do, I have some stuff over in partcl that could use some attention. lemme know. =) (knowing tcl isn't really necessary) DietCoke, what did your comment on #56548 mean? % Limbic_Region has joined #parrot jonathan: maybe you want to take at look at t/spec/S06-multi/type-based.t - it has some basic tests, and rakudo dies on the first of them with "no applicable methods." jonathan: for somethings as complicated as Str moritz: Str has issues. Str as a type constraint doesn't work so great in a couple of places. I should try and work out why. But I'm happy to see that test file - it's new, right? yes, just moved it to spec/ a few minutes ago ok, dispatching to Int works but not to Num and Str uhm, because the test is wrong ;-) it assumes that +'4' is Num, not Int I'm currently correcting and fudging the test DietCoke: pong moritz: Num should accept anything that Int does. Rakudo probably gets that wrong right now. jonathan: yes, but that test is still wrong, because there's an Int multi as well tene; just wondering if you're looking for more work. =-) (on the off chance you are: compileTcl in tcl currently returns a bunch of PIR that all goes into a single, top level .sub; for each command, it needs to generate an :immediate sub. (That seems to be the easiest way to switch us over to the current tcl behavior which runs every command as soon as it's parsed. I also expect it to speed up tcl, since we won't be beating the hell out of the register allocator. % Ademan has left Ademan!~dan@h-67-101-149-223.snfccasy.dynamic.covad.net moritz: Ah. Makes sense. Tene: http://code.google.com/p/partcl/issues/detail?id=2 % Ademan has joined #parrot r29807 | coke++ | trunk: : [tcl] make [incr] autovivify, unTODOing some internal & spec tests. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29807 % Schwern has left Schwern!~schwern@71-34-64-109.ptld.qwest.net DietCoke, nm. I didn't realize you had top-posted. % iblechbot has left iblechbot!~iblechbot@ppp-62-216-206-111.dynamic.mnet-online.de % bacek has joined #parrot r29808 | moritz++ | trunk: : [rakudo] added S06-multi/type-based.t to spectest_regression : +5 pass, +13 skip diff: http://www.parrotvm.org/svn/parrot/revision?rev=29808 % Theory has joined #parrot % verve has left verve!a5847f73@67.207.141.120 % Ademan has left Ademan!~dan@h-67-101-146-212.snfccasy.dynamic.covad.net % Ademan has joined #parrot % teknomunk has joined #parrot % jhorwitz has left jhorwitz!~chatzilla@96.245.16.64 % bacek has left bacek!~bacek@122.110.21.48 % paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net % Paul has left Paul!~chatzilla@c-24-62-67-165.hsd1.ma.comcast.net % TiMBuS has joined #parrot % teknomunk_ has joined #parrot % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net DietCoke: looks like fun. I might look at it tomorrow. Tene: excellent. =-) I have trouble getting interested in work on tcl, 'cos I've never really used it for anything. I've tried a few times. Although, no, that can't be the reason. I've never used lolcode or ruby either. Maybe they have different reasons to be interesting? dunno. part of the problem might be that the codebase is so different. if it were more PCT-like, would that make it easier? or is it just that "tcl is wierd"? =-) That would help a lot, yes. Perhaps you should rewrite tcl using PCT. ;) % Whiteknight has joined #parrot r29809 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] update to trunk r29808 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29809 % bacek has joined #parrot % ewilhelm has joined #parrot r29810 | coke++ | trunk: : [tcl] http://code.google.com/p/partcl/issues/detail?id=29 -- first pass at [lsort -command], with a test. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29810 r29811 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] few changes : * Better maintenance of pool->num_free_objects in my allocators/deallocators : * remove some unused cruft from smallobjects.c : * Maybe some other stuff I don't remember diff: http://www.parrotvm.org/svn/parrot/revision?rev=29811 r29812 | coke++ | trunk: : [tcl] don't catch and throw our own error, let the 'raw' error percolate out. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29812 r29813 | coke++ | trunk: : [tcl] adhere to the coding standards so we don't break the build. Sorry about that.