Camelia, the Perl 6 bug

IRC log for #parrot, 2010-03-17

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:06 * lucian is going to sleep
00:06 davidfetter g'night, lucian
00:09 treed night
00:09 japhb joined #parrot
00:15 dalek rakudo: 3a03034 | jonathan++ | src/Perl6/ (2 files):
00:15 dalek rakudo: Get the $bottle ~~ s[full] = 'empty' syntax working too.
00:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​a030342f62ca44da2130f19f75e19e4ee169f33
00:15 dalek rakudo: 05086a3 | jonathan++ | docs/ROADMAP:
00:15 dalek rakudo: Add 'basic s///' to the done section of ROADMAP. One priority #1 item down for Rakudo Star.
00:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​5086a3f56479416b294a04adf27c1c37c3b7448
00:16 Whiteknight purl msg Austin in t/Program.nqp, test_global_at_start_fails and test_global_at_exit_fails don't hang anymore if I comment out the try/CATCH blocks. seems like something in there is throwing an exception and gtting into a loop
00:16 purl Message for austin stored.
00:18 Whiteknight purl msg Austin I get this exception when I comment out the try/catch blocks: Running test: test_global_at_start_fails not ok 3 - test_global_at_start_fails # A previously-registered Program instance has unprocessed marshalling queues
00:18 purl Message for austin stored.
00:21 nopaste "Whiteknight" at 68.46.29.192 pasted "example t/Program.nqp test failures for Austin++" (24 lines) at http://nopaste.snit.ch/19969
00:21 Whiteknight purl msg Austin http://nopaste.snit.ch/19969
00:21 purl Message for austin stored.
00:22 chromatic joined #parrot
00:23 theory joined #parrot
00:38 snarkyboojum joined #parrot
01:02 hiroyuki_y joined #parrot
01:02 Whiteknight I can't do any more debugging tonight. Lost.
01:12 dalek rakudo: c053d61 | jonathan++ | src/pmc/p6invocation.pmc:
01:12 dalek rakudo: Fix .can.Bool.
01:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​053d6160564e3a844775b3cbfd3aeb4f7fe3323
01:12 dalek rakudo: 1120182 | jonathan++ | src/ (2 files):
01:12 dalek rakudo: Re-enable infix:<Z> and infix:<X> with a tweak so Z- style meta-ops still parse correctly.
01:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​120182ed2f364bc0a6a2a5b844abea3b70d8ff9
01:26 cotto HELO INTERNETS
01:52 dalek rakudo: e3937f7 | (Solomon Foster)++ | build/PARROT_REVISION:
01:52 dalek rakudo: Bump Parrot to 2.2.0.
01:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​3937f789264507d584a2211b616b5ec8fcbf263
01:52 dalek rakudo: 72046f9 | (Solomon Foster)++ | src/core/Any-list.pm:
01:52 dalek rakudo: Don't assume that a Code block will know how to .count.
01:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​2046f9cf5adbee29b29d57302718ab554817677
01:59 dukeleto cover?
01:59 purl cover is not at link?
01:59 brooksbp joined #parrot
02:01 allison joined #parrot
02:02 dukeleto purl, cover is http://tapir2.ro.vutbr.cz/cover/cover-results/
02:02 purl ...but cover is not at link?...
02:02 dukeleto purl, forget cover
02:02 purl dukeleto: I forgot cover
02:02 dukeleto purl, cover is http://tapir2.ro.vutbr.cz/cover/cover-results/
02:02 purl OK, dukeleto.
02:05 hudnix joined #parrot
02:13 Austin Whiteknight: The funky try/catch blocks are intended to drain the component marshalling queues, which is why you occasionally get those exceptions when you comment out the blocks.
02:18 cotto coverage?
02:18 purl coverage is http://cv.perl6.cz
02:18 snarkyboojum joined #parrot
02:38 JimmyZ joined #parrot
02:51 dalek parrot: r44977 | cotto++ | branches/ops_pct/compilers/opsc (6 files):
02:51 dalek parrot: [opsc] revert a batch of pod fixes that don't apply to nqp, fix the opsfile test
02:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44977/
03:03 Austin chromatic: ping
03:19 bacek_at_work cotto, ping
03:22 hiroyu___ joined #parrot
03:24 dalek parrot: r44978 | coke++ | trunk/DEPRECATED.pod:
03:24 dalek parrot: Add reference to TT #1427
03:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44978/
03:27 _2x2l joined #parrot
03:30 sorear hmm, was the 2.1.1 release announcement deleted?
03:31 Coke no, just not sticky, apparently. fixing.
03:32 Coke there.
03:32 sorear I see it again
03:35 * sorear upgrades
03:35 purl upgrades are good!
03:54 janus joined #parrot
04:22 Coke guybrush?
04:23 Coke guybrush is <reply>I'm guybrush threepwood, mighty pirate. (TM)
04:43 pmichaud http://use.perl.org/~pmichaud/journal/40248
04:43 pmichaud (for those who are wondering about my absence from Perl 6 and Parrot)
05:47 chromatic joined #parrot
05:53 chromatic Austin, pong.
06:20 cotto bacek_at_work, pong
06:31 cotto . o O (I need to work on those ping times)
06:36 cotto clock?
06:36 purl cotto: LAX: Tue 11:36pm PDT / CHI: Wed 1:36am CDT / NYC: Wed 2:36am EDT / LON: Wed 6:36am GMT / BER: Wed 7:36am CET / IND: Wed 12:06pm IST / TOK: Wed 3:36pm JST / SYD: Wed 5:36pm EST /
06:59 sorear Where is the list of functions that are kosher to call from a dynpmc?
07:00 sorear Parrot functions, I mean
07:00 cotto PARROT_API is the marker we use (or should be using) iirc
07:01 sorear ah, I was under the impression that was for embedding and there was a separate list for extenders
07:02 cotto It could be.  My track record for getting things right is pretty bad this week.
07:04 chromatic There are separate headers named embed.h and extend.h, but that's a historical artifact we've never yet fixed.
07:07 cotto did particle ever figure out what broke rakudo on win32?
07:09 * cotto needs to get to bed.
07:11 chromatic I didn't hear anything other than the memory usage.
07:15 fperrad joined #parrot
07:29 dalek parrot: r44979 | cotto++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Grammar.pm:
07:29 dalek parrot: [opsc] tighten grammar to avoid capturing whitespace surrounding macros
07:29 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44979/
07:29 dalek parrot: r44980 | cotto++ | branches/ops_pct/compilers/opsc (2 files):
07:29 dalek parrot: [opsc] pass oplib to Ops::File new_str, fix emitter test
07:29 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44980/
07:57 jan joined #parrot
08:07 bacek joined #parrot
08:07 bacek aloha
08:07 bacek seen chromatic
08:07 purl chromatic was last seen on #parrot 56 minutes and 4 seconds ago, saying: I didn't hear anything other than the memory usage.
08:07 sorear hello
08:07 purl hello, sorear.
08:09 bacek chromatic, 2% slow down of pcc branch vs trunk related to "poor man polymorphism" in fill_params. We did a quite good job of optimising after previous round of PCC refactoring...
08:10 bacek msg chromatic, 2% slow down of pcc branch vs trunk related to "poor man polymorphism" in fill_params. We did a quite good job of optimising after previous round of PCC refactoring...
08:10 purl Sorry, I've never seen chromatic, before.
08:12 bacek msg chromatic 2% slow down of pcc branch vs trunk related to "poor man polymorphism" in fill_params. We did a quite good job of optimising after previous round of PCC refactoring...
08:12 purl Message for chromatic stored.
08:14 chromatic Getting rid of the linked list in CallContext should take care of the rest.
08:26 bacek yeah. It will help a lot.
08:26 bacek But it's task for different branch
08:26 bacek . o O ( Is it possible to have normal branching in svn? )
08:28 chromatic You have git and I have git; there's no reason we have to do this in svn.
08:29 bacek we are still using svn as "exchange point"
08:29 bacek let me try to branch of branch
08:30 chromatic Should work.
08:31 chromatic It worked in CVS, in so far as you could do it in CVS.
08:32 bacek bacek@icering:~/src/parrot$ git svn branch pcc_megrecells -m "Sub-branch to replace CallContext's cells linked list with array"
08:32 bacek Copying https://svn.parrot.org/parrot/​branches/pcc_hackathon_6Mar10 at r44974 to https://svn.parrot.org/parr​ot/branches/pcc_megrecells...
08:32 bacek Looks like it will work
08:33 chromatic What's your plan?  Or do you want my plan?
08:34 dalek parrot: r44981 | bacek++ | branches/pcc_megrecells:
08:34 dalek parrot: Sub-branch to replace CallContext's cells linked list with array
08:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44981/
08:34 bacek Your first
08:35 iblechbot joined #parrot
08:35 chromatic I think we need a pointer to the cells and a pointer to the first free cell.
08:36 chromatic If we don't have a free cell, we double in size and copy.
08:36 bacek Erm...
08:37 chromatic Yeah, there's a flaw in that.  How do we know when we've used all of the cells?
08:37 chromatic Okay, we track the number of positionals already.  That's the number of used cells.
08:38 bacek Why don't have Cell*, cell_size, cell_treshold and resize it (same as R*A)?
08:38 chromatic We also track the number of allocated cells.
08:38 chromatic Yeah, same strategy.
08:38 bacek fill_params just use VTABLE_push_foo
08:39 bacek everything else is encapsulated in CallContext
08:39 chromatic Works for me.
08:39 bacek We have freedom to use any strategy we want to
08:39 bacek Deal :)
08:44 chromatic First, I sleep.
08:46 bacek It's a good habbit
08:51 uniejo joined #parrot
08:59 cosimo joined #parrot
09:02 AndyA joined #parrot
09:05 sorear the documentaion for the destroy() vtable function states that the called function must not make new references to the doomed value
09:05 sorear what hook should I use, if I cannot control the results?
09:06 sorear e.g. Perl5 DESTROY semantics, runs arbitrary code
09:24 bacek_ joined #parrot
09:24 bacek_ sorear, in the nutshell - you should't put pointer to "doomed" pmc into some other live object. But you can run any other arbitrary code
09:24 bacek_ sorear, in the nutshell - you should't put pointer to "doomed" pmc into some other live object. But you can run any other arbitrary code
09:25 bacek_ sorear, for example check FileHandle.destroy
09:25 sorear yes
09:25 sorear that much is clear to me
09:25 sorear but I want to run code which I have no control over
09:27 sorear hmm
09:27 sorear on second thought
09:27 sorear does "arbitrary" code extend to "calling back into the Parrot runloop and allocating memory while traversing PMC structures"?
09:27 sorear how does the garbage collector take to recursion?
09:28 bacek_ it should be fine afaiu. If it's not it's a bug.
09:33 he_ joined #parrot
09:47 payload joined #parrot
09:53 dalek rakudo: fc02ce6 | moritz++ | t/spectest.data:
09:53 dalek rakudo: run more test files
09:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​c02ce680e57bab12a23e2c69ebc6a84e3f5b2ed
09:57 payload joined #parrot
09:59 payload1 joined #parrot
10:09 riffraff joined #parrot
10:16 payload joined #parrot
10:21 smash joined #parrot
10:21 smash hello everyone
10:23 payload1 joined #parrot
10:54 lucian treed: hi
10:54 purl hola, lucian.
10:54 lucian purl: shut up
10:54 * purl goes on and on about how much shutting up she's doing
11:02 he_ Tried today's build, worked better, but t/compilers/pge/03-optable.t test fails, ref. http://smolder.plusthree.com/ap​p/projects/report_details/32720
11:49 contingencyplan joined #parrot
12:01 whiteknight joined #parrot
12:01 Austin Good morning, Whiteknight.
12:02 whiteknight good morning Austin, get all my messages last night?
12:02 Austin yeah
12:02 whiteknight I was feeding the kid and only had one hand free, so I figured it would be easier to write you a bunch of long explanatory messages than it would be to just fix the problems
12:02 Austin The one is directly correlated to the other - those funky try/catch blocks are there to drain the marshalling queues, so removing them will cause problems.
12:02 whiteknight on the bright side, I've gotten much better at typing with one hand
12:03 Austin Boy, there's a joke there...
12:04 whiteknight blah blah blah, internet pornography, blah blah blah
12:04 whiteknight ...and then we all chuckle uneasily
12:05 Austin blah blah blah ParrotQuotes blah blah blah
12:05 whiteknight purl msg Coke: Your patch in TT #1427, any idea how that is going to affect performance?
12:05 purl Message for coke stored.
12:06 Austin So I've got nqp generating trampolines to assemble multisubs.
12:07 Austin And I've come across what I think is a bug.
12:07 Austin (Whooo, what a surprise..)
12:07 whiteknight I'm not sure I'm entirely clear about what a trampoline is
12:07 whiteknight I had read about them a while ago, and I'm not sure I took the time to really get it then
12:07 Austin It's internal, so don't worry.  But it's a sub, whose purpose is to bounce you over to another sub.
12:08 dalek tracwiki: v52 | Austin_Hastings++ | ParrotQuotes
12:08 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=52&amp;action=diff
12:08 Austin You know how websites have landing pages?
12:08 Austin You come to one because of google, or because they put it in a tv ad
12:08 Austin And then you get redirected to where they "really" want you to go?
12:09 whiteknight yeah
12:09 Austin Well, that's a trampoline.
12:09 Austin You hit it, it bounces you over to where you're really supposed to go, maybe after fixing your args or something.
12:09 whiteknight okay
12:10 whiteknight The wikipedia article on the topic is turning out to be mostly unhelpful
12:10 whiteknight http://en.wikipedia.org/wiki​/Trampoline_%28computers%29
12:10 Austin In my case, multisubs, there's no way to dynamically attach multi signatures to a live sub.
12:10 Austin (Wikipedia: I think it's one of those things where you have to know the answer before you ask the question.)
12:11 whiteknight Ah, I see what you're saying: Put together a thunk with a multisig that is a closure calling the sub you want
12:11 whiteknight why can't you attach a multisignature to an existing Sub?
12:11 whiteknight you should be able to add the Sub to a MultSub with the signature
12:12 Austin Yeah, but the mmd stuff queries the sub about what it wants to compute the score, I think
12:13 Austin Umm, "not quite" on the whole thunk/closure thing.
12:13 Austin There's no data.
12:13 Austin It's just a redirector.
12:14 Austin Anyway, let me tell you a little story, and you tell me if this is a bug.
12:14 Austin I've got a multisub with three subs in it.
12:14 whiteknight yay! story time
12:14 Austin One of them isn't relevant, so I'll ignore it.
12:15 Austin The other two have multi-signatures (they're methods) of (_, _) and (_, String).
12:15 Austin The _ is, as I understand it (and I may *very* well be wrong here) sugar for "Any PMC type"
12:15 whiteknight it's any PMC type, but matching with the least closeness
12:16 Austin I call the multisub using 7  $foo.append("a")
12:16 Austin The NQP generated preserves the literal-string in the code, so the pir looks like $Pxx.'append'("a")
12:17 Austin Which of the multisubs should get called?
12:17 whiteknight I think (_, _)
12:17 Austin Heh.
12:17 whiteknight I don't think the invocant counts towards the multisig
12:17 Austin Actually, he does.
12:18 whiteknight maybe neither gets called, since the arity of the call is 1, but the arity of the multisigs are both 2
12:18 Austin Because a multisub is a multisub. You can write add(Float, Int) and add(Int, Float) differently, blah blah dispatch
12:18 Austin Making it a method just means that the invocant is the first param.
12:19 whiteknight are you sure about that?
12:21 nopaste "Austin" at 68.39.12.202 pasted "t/pmc/multidispatch.t" (17 lines) at http://nopaste.snit.ch/19970
12:21 whiteknight ah, okay then
12:22 Austin So down in the bowels of src/multidispatch.c, there's this function called mmd_distance
12:23 whiteknight more like the colon
12:23 Austin And there's a loop at about line 762 that iterates over all the args/multisig
12:23 Austin Larry gets the colon.
12:23 he_ Hm, why does "./parrot -o runtime/parrot/library/PGE.pbc compilers/pge/PGE.pir" result in a parrot bytecode file with bc_major = 5 and bc_minor = 3, while the current values are 6 and 5 respectively?
12:23 whiteknight he_: Do you have an older installed version of Parrot?
12:24 he_ At least that's what tools/dev/pbc_header.pl tells me (after I fixed it to work via a minimal patch)
12:24 Austin And that loop updates a variable called "dist"
12:24 whiteknight ok
12:24 Austin Which purports to be the mmd_distance between the args as passed and the sig as-wanted
12:25 Austin (Obviously, this sub gets called once for each entry in the multisub)
12:25 he_ whiteknight: no older parrot installed on this machine as far as I can see.
12:26 Austin he_: Are you on unix/linux?
12:26 whiteknight he_: I don't know then. Try make realclean, reconfigure, rebuild
12:26 nopaste "he" at 158.38.152.80 pasted "patch for tools/dev/pbc_header.pl to make it work again" (18 lines) at http://nopaste.snit.ch/19971
12:28 he_ Austin: I see this problem on NetBSD/macppc and NetBSD/sparc64, but not on NetBSD/i386.
12:29 Austin run 7    od -t x1 FILENAME | head -1
12:29 Austin look at the last two bytes on the first line, what are they?
12:31 Austin (Where FILENAME is your .pbc file
12:31 he_ Says "0000000   fe  50  42  43  0d  0a  1a  0a  04  01  00  02  02  00  05  03" which agrees with my patched tools/dev/pbc_header.pl
12:31 Austin Okay, so your file really is 5/3.
12:32 Austin how about ./parrot -V
12:32 Austin Does that say 2.2.0?
12:34 ruoso joined #parrot
12:36 Austin Anyway, whiteknight, the mmd_distance function checks explicitly for string/String (and int/Int and...) promotion, and if the difference between the arg and the param is an autobox, that gets a dist++; continue.
12:36 Austin So the mmd distance between (_, string) and (_, String) is 1.
12:37 Austin Otherwise, there is an explicit check for _:  if type_sig==PMC, dist++;continue
12:37 he_ Trying the realclean route, did "distclean" earlier.
12:38 Austin Which to me says that the distance between _ and any "lowercase type" (int, string, float, short, etc.) is 1.
12:39 he_ parrot -V says 2.2.0-devel
12:39 Austin So the dispatcher is presented with (_,_) which has a distance 1, and (_, String) which also has a distance 1.
12:39 Austin he_: That's bad.
12:40 Austin he_: Create a x.pir file with two lines:      .sub foo  ; .end   and compile that with  ./parrot -o x.pbc x.pir
12:41 Austin he_: Then run   od -t x1 x.pbc | head -1  and see if the bytecode revision is correct.
12:41 Coke msg whiteknight: I have no idea how it will affect performance; you should ask bacek, who opened the ticket.
12:41 purl Message for whiteknight stored.
12:42 he_ On sparc64 I see 6/0 instead of 6/5, and parrot version 2.0(!)
12:42 Austin Lucky for you, Coke will be finished reading the backscroll shortly.
12:42 he_ And compilers/pge/PGE.pbc is oldish, Jan 20.  Not re-generated, not cleaned, apparently.
12:42 whiteknight Austin: Okay,I see what you are saying
12:43 he_ Missing dependency / cleanup?
12:43 Austin he_: Sounds that way.
12:43 whiteknight so a string matches (_,_) just as well as matches (_,String)
12:43 tetragon joined #parrot
12:44 Austin whiteknight:  Yes, and with the same mmd distance.
12:44 Austin (1)
12:44 Austin It seems that there are two separate rules - the switch and the if statement below it - that both are trying to say "to box costs 1"
12:45 Austin But in this case, it's not a question of boxing vs. not boxing, but a question of boxing with an explicit rule (string->String) an boxing with an implicit rule (string->_)
12:45 Austin I'm not sure if this is a bug, or not.
12:47 Austin (Except of course that any failure to DWIM is automatically a bug...)
12:50 Coke I don't think anything should be generating that file atm.
12:50 Coke (the PGE one.)
12:51 he_ ok, that made NetBSD/macppc succeed.
12:51 Coke check the make rule for compilers/pge and see if it generates the file in that directory or if it puts it elsewhere - that might just be a remnanat of an old build.
12:51 Coke *remnant
12:52 whiteknight Austin: it seems to me it should hit both cases: First boxing string->String has a distance of one, and then the implicit match is another distance of one
12:54 Austin So I should expect what, a junction of behaviors?
12:54 dalek parrot: r44982 | gerd++ | trunk/docs/pdds/pdd30_install.pod:
12:54 dalek parrot: Add a missing slash
12:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44982/
12:54 whiteknight basically, yes. A string should match a String more closely than it matches a _
12:57 Austin Because this is a manhattan distance computation, there is always the possibility of conflict. That is, of foo(b, x) having a distance of 3 from signature (a, z) and having a distance 3 from signature (d, y)
12:57 whiteknight right
12:57 Austin So I can understand a sort of "well, suck it up" approach.
12:57 whiteknight I don't know what it does in those cases
12:57 Austin But in this case (it's *ME* and I'm *special*) I'm trying to use _ as "anything I haven't mentioned explicitly"
12:58 Austin So I want to say that String is closer than _
12:58 Austin and call it a bug.
12:58 whiteknight Austin: I'll tell you what. If you put together a pure-PIR test case to exercise what you want, I'll try to makeit happen
12:58 whiteknight I think that String should definitely be closer than _
12:59 Austin I'll put in a ticket, but this is (a) low priority  (I've got a work-around - Kakapo ROCKS!); and (b) subject to counter-argument from chromatic, allison, etc. since there might be some aspect I haven't considered.
13:00 whiteknight speaking of Kakapo rocking, are the test failures fixed? I haven't had a chance to test it yet this morning
13:00 nopaste "Austin" at 68.39.12.202 pasted "Kakapo rocks\!" (6 lines) at http://nopaste.snit.ch/19975
13:01 Austin No. I didn't say "Austin rocks!"
13:01 Austin I was chasing this bug, instead of yours.
13:03 parthm joined #parrot
13:05 Austin Deja freaking vu.
13:05 Austin whiteknight: You know, some dude found this same bug and opened a ticket (TT#1144) 5 months ago.
13:06 Austin Heh.
13:06 Austin Complete with pure pir example.
13:06 whiteknight saves you some effort then
13:07 Austin No, just pisses me off. It's my ticket.
13:09 he_ OK, I see a little more what's going on.  compilers/pge/PGE.pbc got created at some point, but was not deleted after a subsequent update.
13:09 he_ t/compilers/pge/03-optable.t does load_bytecode 'compilers/pge/PGE.pbc'
13:09 atrodo joined #parrot
13:10 he_ Absent the PGE.pbc file, PGE.pir will be used.
13:10 he_ Currently there doesn't appear to be code to recreate the PGE.pbc file.
13:10 he_ It appears that "realclean" won't remove the PGE.pbc file either, it must be manually removed (ugh)
13:11 Austin he_++
13:12 Austin find . -name '*.pbc'
13:13 he_ There's quite a few oldish files lying around.
13:16 whiteknight he_: you may need a fresh checkout. There have been lots of makefile changes lately and it sounds like your working copy is in an inconsistant state
13:18 he_ Well, I've continually updated with "svn update".
13:18 he_ Typically at least once per release.
13:19 he_ t/native_pbc/integer_5.pbc is in SVN, created with parrot 1.0, bytecode file format version 4.0
13:19 he_ "that's not going to work", I guess.
13:21 plobsing he_: make svnclobber (make sure you don't have any local changes worth saving first)
13:21 Coke yes. svn update, realclean, configure, build, is not guaranteed to put you in a usable state.
13:21 he_ oh, that violates the principle of least astonishment...
13:22 Coke he_: when you're changing the build system, it's hard to guarantee. =-
13:22 Coke )
13:22 Coke a file may become no longer used nor removed, so if you do the build first and regen the makefile, it'll never be removed from that point on, leaving a dead file.
13:27 he_ but if I always do "make distclean" before perl ./Configure.pl (which I do), it *should* have cleaned up.
13:27 nopaste "he" at 158.38.152.80 pasted "leftover pbc files in the svn repository" (22 lines) at http://nopaste.snit.ch/19980
13:28 he_ Of these, t/tools/install/testlib/run​time/parrot/library/TGE.pbc doesn't really appear to be a pbc file, and the others are created by various old versions of parrot, and have not been updated.
13:31 Coke he_: no. distclean cleans things it /knows/ about.
13:32 Coke if we change the list of known files between svn revisions, the old ones are no longer known, and therefore no longer cleaned.
13:32 Coke whoops.
13:32 Austin find . '(' -type d -name '.svn' -prune ')' -o -name '*.pbc' \! -name 'pbc_merge_t*.pbc' -print
13:32 Coke yes.
13:32 plobsing svnclobber the files from space. It's the only way to be sure.
13:32 Austin If only we could get that on windows.
13:32 Coke Austin: ... 'make svnclobber'
13:33 Coke he_: you're right; if you do the distclean first, you'll be in a much better positions.
13:33 Coke Sorry, was stuck in "broken record" mode. =-)
13:33 Austin Should that be part of realclean or distclean?
13:33 Coke Austin: hell no.
13:33 Coke it's the nuclear option.
13:33 Austin Huh?
13:33 plobsing Austin: no! I like my untracked files!
13:33 he_ Well, the Makefile(s) were generated by the old version, so it should know at that point what to clean up after itself.
13:34 Austin And if you just typed "make realclean" it seems like you're saying "I don't like my untracked files much any more"
13:34 Coke he_: modulo bugs, yes.
13:34 Coke Austin: no.
13:34 Coke I love my untracked files.
13:34 * Coke notes that 'svnclobber' is the nuclear option, not austin's script.
13:36 Coke but austin's script still removes things I wouldn't want removed on a realclean.
13:36 Austin How so?
13:36 Austin (Actually, since my script doesn't include '| xargs rm -f', it doesn't remove anything...)
13:36 Coke Austin: thbbthp.
13:37 Coke we should only be removing files our build generated, unless we go to 'svnclobber'. (I'm pretty sure distclean is an alias for realclean atm.)
13:37 Austin But IIUC, the pbc files other than the various special testcase flavors are all generated from pir, no?
13:37 Coke that doesn't mean we shoudl remove ones the /user/ created.
13:39 Austin Well, clearly what you need is for IMCC to copy the value of the PBC_ORIGIN environment variable into each pbc, so we can tell the difference between build-generated ones and user-compiled ones.
13:39 Austin Or we could figure that realclean means "yeah, rm stuff"
13:40 Austin :)
13:40 mls joined #parrot
13:41 mls Hi, src/packfile.c looks suspicious in line 4446:
13:41 mls self->groups = self->groups = mem_gc_realloc...
13:42 mls gcc complains about "causes undefined operation"
13:47 Coke ooc, which version of gcc is complaining about that?
13:47 Coke (fixing shortly)
13:48 mls gcc version 4.5.0 20100311 (experimental) [trunk revision 157384]
13:49 Coke spif.
13:51 Coke let me know if there's any thing else that shows up on that compiler. =-)
13:51 Austin whiteknight: I think I've got a Program fix. Best part: fix is in the t/
13:52 Coke mls?
13:52 purl mls is Master of Library Science or Minnesota Language Systems or Multiple Listing Service (real estate) or mailing lists
13:52 mls Well, it also complained about the no-return-in-nonvoid-function in src/pmc.c, but there's already a comment in svn, so you probably already know about it
13:54 Coke packfile.c updated. Thanks.
13:54 theory joined #parrot
13:54 Austin msg whiteknight I pushed a src/Program and t/Program bundle to master just now.
13:54 purl Message for whiteknight stored.
13:55 mls (The no-return... was in Parrot_pmc_new_init_int, I guess it just needs to return the result of the VTABLE_instantiate() call)
13:57 whiteknight nice
13:58 Coke mls - that's a relatively new function
13:58 Austin You might get some bonus crap if you pull, but the fix is that I explicitly reset the global registry, rather than trying to drain the queues.
13:58 dalek kakapo: 91fa256 | austin++ |  (2 files):
13:58 dalek kakapo: Modified src/Program.nqp to remove inheritance from Library. Modified t/Program.nqp to reset globals before running tests. I think this fixes the intermittent hang that seemed to be test-order dependent.
13:58 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
13:58 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/91fa2566bc6330dbecb118aa47de695ba205063a
13:59 mls Who uses parrot_config's optimize var? It doesn't seem to be used by pbc_to_exe. Is that a bug?
13:59 Coke very likely.
13:59 dalek parrot: r44983 | coke++ | trunk/src/packfile.c:
13:59 dalek parrot: remove useless self-assignment, courtesy mls++
13:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44983/
14:00 Coke msg tewk - can you fix the XXX comment in src/pmc's new_pmc_init_int ? needs an explicit return in there, but I don't know what it should be returning.
14:00 purl Message for tewk stored.
14:05 whiteknight mls: I don't hink it's a bug. Just because parrot was optimized doesnt necessarily mean you want to optimize everything else
14:05 Coke whiteknight: pbc_to_exe uses "whatever parrot did" to build.
14:05 whiteknight Coke: and that's what we want?
14:05 Coke so we should try to pass through as many of those compiler option as possible.
14:05 Coke whiteknight: unless you want to build a second config system, yes. =-)
14:06 whiteknight okay, I won't argue it then. Giving pbc_to_exe some commandline args to control optimizations might be nice
14:06 whiteknight a -O option would pull Parrot's optimize flags
14:06 Coke ... of course, if parrot wasn't compiled with optimization, it'd be useless.
14:06 Coke I think having a second set of options there is overkill.
14:07 Coke DRY (unless you really need to)
14:07 * Coke tries something:
14:07 * coke_at_work drifts off into the corner.
14:07 patspam joined #parrot
14:07 coke_at_work SPAMMER!
14:07 purl Spammer, spanner. Spanner, spammer. "Ow!"
14:08 coke_at_work patspam?
14:08 coke_at_work purl, bad bot.
14:08 * purl chuckles evilly
14:09 parthm left #parrot
14:14 coke_at_work (optimize) - it probably used to work this way until I factored out the warnings & the the optimize flag to make them overridable. I missed this usage because it's in PIR, not a makefile.
14:14 coke_at_work where this way == using the optimize flags.
14:15 coke_at_work the config flags are 'ccwarn' and 'optimize', and they should be includable like the other cc flags if someone wants to fix that.
14:15 bubaflub joined #parrot
14:23 dalek TT #1513 created by Austin_Hastings++: Test::Builder formats TODO tests wrong/poorly
14:31 davidfetter joined #parrot
14:35 nopaste "Whiteknight" at 173.12.37.77 pasted "Current test results after t/Program.nqp fix for Austin++" (89 lines) at http://nopaste.snit.ch/19982
14:35 Austin Looks just like mine. Whiteknight++
14:36 whiteknight nice
14:36 whiteknight good progress is good
14:36 Austin You haven't found out yet that you're boned.
14:36 Austin Crap.
14:37 Austin I forgot you were depending on Nqp
14:43 Austin whiteknight: You need to pull again to get a re-added File.nqp, which should make the Nqp.nqp testcase work, which I think you need for your external testcase class.
14:46 coke_at_work (yo, I heard you like nqp, so I put some nqp in your nqp?)
14:46 dalek kakapo: 8151d15 | austin++ |  (3 files):
14:46 dalek kakapo: Reinstated File.nqp to get Nqp.nqp working, for Whiteknight++
14:46 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
14:46 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/8151d15a1ac612d3db3899ef280acb05b5285aee
14:46 Austin Hell, yeah.
14:47 Austin (Also, here's at least one function for interacting with the NQP compiler from within nqp code...)
14:47 Austin Nqp::compile_file( 'foo.nqp' )
14:49 dalek rakudo: 02ba26c | snarkyboojum++ |  (3 files):
14:49 dalek rakudo: An attempt at getting .rotate working
14:49 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​2ba26c5bb4fba4b4bd47d02ffbc42be2779b1eb
14:49 dalek rakudo: d0f934f | (Solomon Foster)++ | src/core/Seq.pm:
14:49 dalek rakudo: Delete trailing whitespace.
14:49 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​0f934f0e7f733f4ff6fb035abceed42f2ba5223
14:55 whiteknight Austin: I've posted a patch to fix TT #1144. Assuming no complaints, I'll apply it today
14:55 Austin I saw that. Do all the parrot testcases pass?
14:56 PacoLinux joined #parrot
14:57 Austin okay
15:02 whiteknight yeah, all tests pass
15:02 whiteknight so barring complaints from the powers-that-be, it's in
15:02 whiteknight too bad I can't retroactively apply it to 2.2
15:03 whiteknight or "2.0" as the locals call it :)
15:03 Austin Heh.
15:03 Austin My birthday's in April, so it'll make a nice gift.
15:04 whiteknight As a present, I'll play your personal code monkey and try to fix some of these millions of tickets you're filing
15:05 Austin Just using Kakapo has been doing a bunch of good for me, in terms of getting some real-world exposure.
15:07 coke_at_work if there's a 2.2.1 to fixup rakudo build issues, we can cherry pick some post 2.2 commits.
15:10 Austin whiteknight, fyi: I just pushed a Loader fix. You probably don't need it (the way you *need* the File.nqp fix) but it makes that testcase pass.
15:11 whiteknight nice
15:11 whiteknight coke_at_work: that's cool, but I would be hesitant to change too much in the 2.2.1
15:11 Austin BTW, did you read the diagnostic on the MockFS failure you nopasted?
15:12 Austin oh, never mind
15:12 Austin It was the wrong test...
15:12 Austin I just got this:   t/Cuculinae/MockFS.nqp ................ 1/2 # Don't know how to check if String exists. Use a String or Path
15:12 Austin Because of the _ versus String thing...
15:19 bubaflub i don't know if cardinal people have seen this, but ruby 1.9.2 has passed all the RubySpec tests and the 1.9.2 spec itself will be frozen on March 31st.
15:24 Austin Heh.
15:24 Austin Ironically, the OS.pmc won't tell me what OS I'm using.
15:24 Austin How do I do OS-based behavior in Parrot?
15:25 coke_at_work Austin: what are you trying to do ?
15:25 Austin Create a different class to support different filesystem semantics
15:25 coke_at_work ok. we don't probe for the fs type yet, I don't think.
15:26 coke_at_work but you might want to check File.pmc to see if it gives you the methods you want. If you have to roll your own, ,you can key off the config object to at least figure out what OS you're on.
15:26 Austin This is at runtime, not build time. But maybe looking in %config is the right thing?
15:26 coke_at_work s/right/closest/, yes.
15:27 coke_at_work kind of like us peeking into perl5's build config is the closest parrot has in some places.
15:27 coke_at_work but since we don't really support x-platform yet, it's probably good enough for some time.
15:28 Austin What's the origin of the config <osname> key?
15:29 Austin Mine says 'linux', but uname reports 'Linux'...
15:35 Psyche^ joined #parrot
15:37 coke_at_work Austin: you can figure that out by acking through the config dir for osname. checking...
15:37 coke_at_work I don't see anything that explicitly sets 'osname', so it's probably coming from P5's Config.
15:38 Austin auto/arch.pm
15:38 Austin which comes from get('archname')
15:38 coke_at_work ah, it was a multiline. =-)
15:39 Austin which appears in p5_keys_whitelist?
15:42 Austin Which appears to mean it gets passed through
15:43 coke_at_work it's not a straight passthrough.
15:43 Austin heh
15:43 coke_at_work auto/arch.pm processes it.
15:44 coke_at_work not sure what the whitelist is doing there.
15:44 coke_at_work but the source is, ultimately, p5.
15:44 whiteknight joined #parrot
15:44 Andy joined #parrot
15:51 Austin Woot. Contextuals look for both caller lexicals and namespace globals.
15:51 Austin Pmichaud++
15:53 davidfetter hello
15:53 purl hey, davidfetter.
15:54 davidfetter so i'm confused about the latest in pdd16 (nci)
15:54 janus joined #parrot
15:55 davidfetter in particular plobsing's patch for same, which appears to change docs so far. does the code need to change along with?
15:56 Austin Changing the PDD implies that any behavior that does not conform to the PDD is in error.
15:56 Austin Which is why it's a mailing list discussion, and not a 3am commit...
15:56 Austin :)
15:58 he_ joined #parrot
16:09 plobsing Austin: it will turn into a 3am commit unless someone provides some feedback, it's not much of a "discussion" at the moment
16:12 Austin Peter, I've seen a few messages go by - maybe 10-15. Maybe you haven't got them, yet?  (I sometimes get mail a week late from the list :(
16:14 davidfetter oh, the person in quesion :)
16:14 * plobsing runs and hides
16:14 davidfetter heh
16:14 davidfetter do you have any interest in postgres?
16:15 plobsing I don't have much skill with databases. So not directly.
16:16 bacek joined #parrot
16:16 plobsing the PL/Parrot stuff just happens to be running into the same problems I've run into a couple times now.
16:17 davidfetter this all came up because we're trying to make parrot (eventually) pg's language engine
16:17 davidfetter :)
16:17 davidfetter who's, "we?"
16:17 davidfetter er, where are you running into these problems?
16:18 davidfetter <-- ETOOLITTLECOFFEE
16:18 plobsing 1.) frame builder 2.) Parrot::Embed 3.) vim-parrot (personal project, not yet published)
16:19 davidfetter <-- vim user :)
16:24 cotto_work bacek or bacek_at_work, ping
16:25 kjeldahl joined #parrot
16:32 jsut joined #parrot
16:33 plobsing davidfetter: also I have a vendetta against varargs
16:33 Austin D'oh. Storing contextuals doesn't check for dynamic vs. global.
16:33 * davidfetter sends plobsing up the nung river in a pt boat
16:38 whiteknight joined #parrot
16:40 whiteknight internet connection is teh suxxor
16:41 whiteknight allison: ping
16:41 dalek kakapo: 70ee5af | austin++ |  (3 files):
16:41 dalek kakapo: Fixed ordering test in Loader.nqp
16:41 dalek kakapo: Fixed issue #10: Add ordering support for testcase execution.
16:41 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
16:41 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/70ee5afe85c65bd7d2f3ba94c0e7abcf1bb872a5
16:47 Mokurai1 joined #parrot
16:49 dukeleto 'ello
16:50 bubaflub afternoon duke
16:50 dukeleto bubaflub: howdy
16:50 dukeleto plobsing: yes, PL/Parrot is running into lots of sharp corners of the Parrot embedding API :)
16:52 plobsing dukeleto: embedding parrot, its hard not to run into sharp corners.
16:52 chromatic joined #parrot
16:52 dalek TT #1514 created by Austin_Hastings++: NQP-rx doesn't check storage mode for contextuals
16:53 whiteknight I would like it if dalek would print a link to the ticket
16:54 Austin You know, I suggested making that a bot
16:54 Austin But they told me, "Oh, that's in the irclogs."
16:55 whiteknight what's in the logs?
16:55 Austin Apparently, nobody but us suxxors actually follows IRC. Everyone else follows the logs.
16:55 darbelo Austin: That's not the same as 'no'.
16:55 Austin The TT# -> link converter
16:55 whiteknight Ah, that would be a cool bot
16:55 plobsing or you could add a script to your irc client to match patterns like that and make links
16:55 whiteknight even cooler if it were written in Parrot
16:55 whiteknight an IRC library would be a cool project
16:56 whiteknight plobsing: I use at least two IRC clients
16:56 Austin plobsing: Or I could use firefox's built-in keyword expansion stuff to make tt# xxx work.
16:58 plobsing whiteknight: that just means you get to do *more* scripting! scripting is fun right?
16:59 dukeleto Austin: i would very much like a link to the TT as well
16:59 dukeleto dalek ?
16:59 purl dalek is #parrot's spammy little rss bot or (see: dalek plugins)
17:00 dukeleto dalek plugins ?
17:00 purl i heard dalek plugins was http://github.com/Infinoid​/dalek-plugins/tree/master
17:03 Austin I was thinking more of a live rewriter, that would translate anyone's tt# into a link.
17:03 Austin I say tt#2
17:04 Austin and ttbot says: TT# 2 is at http://trac.parrot.org/parrot/ticket/2
17:04 Austin (Or whatever)
17:04 darbelo ttbot?
17:04 purl ttbot is TapTinder build bot owned by mj41 and reporting http://tt.taptinder.org/bui​ldstatus/pr-Parrot/rp-trunk build errors.
17:04 Austin I wonder if purl is smart enough for that
17:05 Austin So ttbot is already taken...
17:05 Austin It was the obvious name..
17:05 Austin purl help?
17:05 purl #perl is not a help channel, and I'm not a help bot.  If you want Perl help, try #perl-help or #metallica. or (see the 'help channel' factoid as well) or
17:05 Austin fna
17:05 bubaflub we had something like that for our companies ticket system
17:05 bubaflub i might be able to resurrect the code
17:06 bubaflub all i'd need is a server to run it on so it could listen in the chanel
17:06 bubaflub everytime we'd say #1234
17:06 bubaflub it would spit out the link to our internal tracker
17:06 Austin I'm wondering if purl is smart enough for that..
17:06 whiteknight I had a bot like that for Wikipedia. Long time ago
17:06 Austin What software is she running?
17:06 cotto_work infobot
17:07 cotto_work probably with many additions
17:08 Austin If this is magnet, she's flooterbuck.
17:14 cosimo joined #parrot
17:16 dalek parrot: r44984 | gerd++ | trunk (5 files):
17:16 dalek parrot: add the option: "perl Configure.pl --pkgconfigdir=DIR"
17:16 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44984/
17:25 Austin tinyurl http://example.com/test
17:25 purl Your tinyurl is http://tinyurl.com/4o6x2s
17:25 Austin Thanks, purl.
17:28 ruoso joined #parrot
17:29 allison whiteknight: pong
17:29 whiteknight allison: can you take a look at my patch for TT #1144
17:30 whiteknight fixes the ticket and passes all tests, but I want an eye to double-check the approach
17:30 whiteknight there's a question about whether this is even the intended behavior, which I think it should be
17:30 allison sure
17:31 whiteknight thanks!
17:31 ash_ joined #parrot
17:33 allison whiteknight: looks great!
17:33 whiteknight awesome, thanks!
17:33 whiteknight allison++
17:34 dukeleto i thinks making dalek spew the TT link when it announces a new ticket would be the best + easiest
17:35 Austin It's a start.
17:42 dalek kakapo: 5c3b3a6 | austin++ |  (2 files):
17:42 dalek kakapo: Got the string-oriented parts of Path working, tested.
17:42 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
17:42 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/5c3b3a661edc9a8323fd4a42796c9b1271d84afd
17:44 chromatic +1 on the MMD patch.  I'm not sure why it didn't work that way before.
17:47 whiteknight thanks. I'll commit it in a few minutes
17:47 whiteknight I'm working on a patch right now for the RO stuff in tt389_fix
17:47 whiteknight looks like it fixes at least a few broken tests
17:48 chromatic The fact that the RO vtable doesn't have the proxy in pmc_class?
17:48 whiteknight yeah
17:48 whiteknight I'm basically sharing it. vt->ro_variant_vtable->pmc_class = vt->pmc_class
17:48 brooksbp joined #parrot
17:48 whiteknight a little ugly, but workable
17:49 coke_at_work Would anyone care if I removed all the docs-specific targets?
17:49 chromatic That was my best idea too for now.
17:50 whiteknight I'm doing a comparison right now to double-check that I'm fixing tests and not regressing anywhere
17:51 whiteknight I'm still seeing plenty of places in the code where things are being looked up in vtable->_namespace
17:51 whiteknight and those are leading to Null PMC access errors
17:51 whiteknight I think if we find and hunt down the rest of those we will be in better shape
17:53 chromatic Places that look up methods?
17:53 whiteknight yeah
17:53 whiteknight also, the issue with inheritance
17:54 whiteknight If you could throw together a function like you were talking about a while ago to walk the MRO and look for methods, we could plug that in to the places that need it
17:54 whiteknight probably a bunch of cut+paste from Object.pmc:find_method
17:55 chromatic Can probably do that.
17:55 dukeleto looks like http://github.com/Infinoid/dalek-plugins/bl​ob/master/modules/local/parrotticketlog.pm needs to be slightly modified to emit a TT URL
17:57 bubaflub dukeleto: i think it's calling the emit_karama_message in karmalog.pm
17:58 bubaflub http://github.com/Infinoid/dalek-plugins/b​lob/master/modules/local/karmalog.pm#L167
17:58 bubaflub right after that
18:02 coke_at_work aooga:
18:02 coke_at_work The OSUOSL will be performing an IOS upgrade on our primary Cisco router
18:02 coke_at_work this coming Wednesday, March 24, 2010 between 7:00-7:30PM PDT (0200-0230
18:02 coke_at_work UTC). Networking for *ALL* of the OSUOSL will be down for approximately
18:02 coke_at_work 5 minutes during the outage and will be restored once the update is
18:02 coke_at_work complete.
18:02 purl Nothing ever is.
18:02 coke_at_work (this means us)
18:03 Austin Heh. 5 minutes.
18:04 whiteknight yeah, 5 minutes in IT time is damn near all day
18:04 * cotto_work panics
18:06 dalek parrot: r44985 | whiteknight++ | branches/tt389_fix (2 files):
18:06 dalek parrot: share pmc_class between a vtable and the ->ro_variant_vtable. Fixes 6 tests in t/dynpmc/rotest.t
18:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44985/
18:06 dalek parrot: r44986 | whiteknight++ | trunk/src/multidispatch.c:
18:06 dalek parrot: [mmd] change the mmd distance calculating algorithm to count autoboxing as one step, and implicit type matching as a second. calling with an S register should match (String) more closely than (_). Fixes TT #1144
18:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44986/
18:06 dukeleto bubaflub: mad props to you if you add TT URLs :)
18:14 dalek TT #1144 closed by whiteknight++: MMD incorrectly matches _ instead of String
18:15 whiteknight yay karma!
18:16 bubaflub dukeleto: i've got a patch for it to show TT URLs (which I *think* should work); where should i send it?
18:16 bubaflub or should i just do a pull request from github?
18:17 whiteknight ah, my last tt389_fix commit fixed more bugs than I thought. the dynpmcs don't rebuild when we make changes to Pmc2c
18:18 dukeleto bubaflub: Infinoid. yeah, a pull request is probably best
18:18 bubaflub "Hardcore Forking Action". ah, github.
18:19 dukeleto bubaflub: yeah, that always makes me happy :)
18:21 bubaflub ok, pull request sent to Infinoid through github
18:21 bubaflub we'll see what happens
18:21 Austin bubaflub: What's the modified structure of the dalek messages?
18:22 bubaflub Austin: just a second line below the first
18:22 bubaflub with the URL
18:22 Austin Okay.
18:22 bubaflub http://github.com/bubaflub/​dalek-plugins/commit/37807a
18:22 bubaflub to see the changes, pretty simple really.
18:22 Austin Moritz' irclog stuff processes the contents to make #123 into a link, so you'll want to make sure that stays in.
18:23 bubaflub okey dokey
18:24 bubaflub if we wanted to get the ticket URLs from other places i could make some quick edits as well
18:24 whiteknight chromatic: I think all remaining test failures in tt389_fix are because of inheritance issues
18:24 whiteknight we get that worked out, everything should be fixed.
18:25 Infinoid bubaflub: thanks for the patch.  Any objection to including $prefix on the link line too?
18:25 bubaflub Infinoid: not at all.
18:26 bubaflub (at least from me)
18:26 bubaflub so something on the second line like:
18:26 Infinoid cool.  I'll try it out tonight and merge it if it looks good
18:26 bubaflub TT #1513: http://trac.parrot.org/parrot/ticket/1513
18:26 dukeleto +1 to making the TT link on the next line
18:26 Infinoid yeah.  I think I may need some special : handling, but it'll look close to that
18:26 dukeleto Infinoid++ bubaflub++
18:26 Infinoid should be trivial :)
18:27 iblechbot joined #parrot
18:36 chromatic whiteknight, are the inheritance failures obvious from the failing tests?
18:37 whiteknight chromatic: I think all the remaining failures are inheritance failures
18:37 whiteknight the only one I think might be a different issue is the failure in t/pmc/objects.t
18:38 chromatic I see.
18:38 whiteknight It's not finding a vtable override in a subclass of Integer, and I suspect it might be stored in a namespace somewhere
18:38 dalek parrot: r44987 | whiteknight++ | branches/tt389_fix/t/pmc/resizablepmcarray.t:
18:38 dalek parrot: [tt389_fix] add exception handlers to one RPA test. When this test throws an unhndled exception the rest of the test file doesn't run at all. Now we see the one failure, and we also see that all other tests in the file pass
18:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44987/
18:38 whiteknight or, the mechanism to find the vtable override isn't searching in the proxies correctly
18:39 chromatic Oh, right.
18:39 chromatic That might be a case where :vtable and :method interact badly.
18:39 whiteknight likely, yes
18:39 chromatic Did you fix something like that in trunk or on the branch?
18:39 dukeleto mj41++ # Code coverage on tapir2.ro.vutbr.cz now has GMP support
18:39 whiteknight in trunk. I fixed it so :anon :vtable was entered into the namespace correctly
18:40 whiteknight this one isn't :anon, but I'm sure a similar mechanism is at play.
18:41 chromatic Right.
18:41 ash_ for nci, is parrot planning on using libffi?
18:41 whiteknight brb. VisualStudio demands the computer restart for an update
18:43 chromatic libffi is an option for an NCI backend.  We haven't decided on one.
18:43 plobsing chromatic: are we going to decide on only *one*?
18:43 chromatic I don't know that.
18:43 plobsing althought if we were to choose 1, can't complain about libffi
18:44 chromatic The cost of supporting multiple might be significant.
18:44 chromatic See also: runcores, JITs, garbage collectors, PIR compilers, STRING subsystems....
18:44 ash_ i just heard that libffi doesn't work with win32, (well it does work with cygwin and ming) so i was wondering
18:45 plobsing ash_: url?
18:45 lucian ash_: i don't think that's true. for example python's ctypes works just fine on windows
18:45 chromatic If that's true, that's a point against it (or a point for us to encourage it to work well with Windows).
18:46 ash_ http://sourceware.org/libffi/ says Windows/Cygwin and Windows/MingW as supported platforms, i took that as it won't work with the windows compiler...
18:46 ash_ i could be wrong though
18:47 cotto_work msvc support is important on windows
18:47 lucian ash_: python-win32 is compiled with msvc and its ctypes (based on libffi) works fine
18:48 ash_ lucian: that may be, i am just saying thats what the libffi site says, i don't have a windows computer to test that though
18:48 lucian ash_: right. a quick google suggests that there's a set of patches maintained for msvc compat
18:49 lucian and http://code.google.com/p/libffi-msvc/
18:49 dukeleto +Inf to libffi
18:51 plobsing since we're talking about nci, has anyone had a look at my proposal for pdd16?
18:51 bubaflub libffi on msvc: http://sourceware.org/ml/libf​fi-discuss/2010/msg00049.html
18:51 bubaflub sent earlier this month from the maintainer of that google code project; seems like things are working
18:52 lucian bubaflub: so it really is a non-issue
18:52 bubaflub lucian: the follow up emails said they wanted to merge it in
18:53 lucian bubaflub: even if it doesn't get merged, maintaining a libffi patch is much easier than using anything else
18:53 bubaflub "I tried these patches on mswin32/MSVC9 and it works fine, though current github/atgreen/libffi/master doesn't work on my env."
18:53 bubaflub is in the follow up email;
18:54 bubaflub i think it's safe to say that MSVC stuff works for libffi and there are active commits in the google code project i.e. commits this month
18:55 bubaflub though we should still investigate, i think it's premature to say that it *doesn't* work with MSVC
18:58 cotto_work "It's also possible to build libffi on Windows platforms with
18:58 cotto_work Microsoft's Visual C++ compiler." from http://github.com/atgreen/libffi
18:58 cotto_work smells like a winner
18:59 bubaflub that's a bingo
19:02 whiteknight joined #parrot
19:07 eric_j joined #parrot
19:19 TiMBuS joined #parrot
19:23 lucian allison: ping
19:23 AndyA joined #parrot
19:36 dalek TT #895 closed by NotFound++: Towards automatic allocation and deallocation of PMC attributes
19:36 dalek TT #1493 closed by NotFound++: Avoid repeated STRING constans with the same value
19:37 NotFound sdl?
19:37 purl sdl is Simple Directmedia Layer aka DirectX for Unix except with 59% less evil.  There's Perl bindings.  Frozen Bubble is written using it. or or allows that nifty doom game to run on ayrnieu's *Zaurus*
19:41 AndyA joined #parrot
19:43 whiteknight chromatic: I think I may have the tt389_fix issue figured out
19:43 whiteknight and it's much much easier than I expected
19:44 eric_j joined #parrot
19:44 whiteknight lib/Parrot/Pmc2c/PMCEmitter.pm:get_mro_func, the generated vtable->mro for a built-in type is an RSA of type names. I'm converting that to an RPA of PMCProxies. src/oo/find_method_direct_1 should now walk the MRO correctly and find methods as appropriate
19:46 chromatic Ah, that sounds reasonable.
19:47 coke_at_work whiteknight++
19:47 whiteknight that might also explain a handful of other bugs if subclasses are inheriting that "MRO" and not being able to lookup methods in it
19:47 chromatic Right.
19:47 chromatic We'll probably be able to delete a lot of code too.
19:48 whiteknight of course, it may create some bugs if anybody is relying on this lousyness
19:48 whiteknight ...and miniparrot segfaults. So, there's my answer
19:49 allison lucian: pong
19:49 lucian allison: it seems i was somewhat wrong about parrot's objects described in PDD 15
19:50 allison lucian: how so?
19:50 lucian allison: they're less than ideal (as in i'd love to see some changes), but it should be possible to implement python objects on top without horrible hacks or perf hits
19:51 allison lucian: excellent!
19:51 purl EGG-see-lent!
19:51 lucian allison: the description makes them sound like java objects and not fitting everything-is-an-object languages at all
19:51 lucian allison: but they expose their vtables, so it should be fine
19:52 allison lucian: well, in Parrot we have to deal with many different kinds of languages
19:52 lucian allison: yes, which is odd that the object system is so perl-oriented
19:52 allison lucian: some are everything-is-an-object, some aren't
19:52 allison lucian: is it perl oriented? it was designed to be pretty generic
19:53 lucian allison: it's less generic than it should be
19:53 allison (and the folks developing Perl say it's not perl oriented)
19:53 lucian oh. then i probably don't know perl enough (which i don't)
19:53 NotFound lucian: I don't see 'bless' in parrot ;)
19:53 allison Rakudo is prototype-based, so using a different overlay on top of Parrot objects
19:54 joeri joined #parrot
19:54 allison lucian: but, I'd agree it's not strictly Python objects, and may need overlays there too
19:54 lucian allison: i'm thinking python's object will inherit Object and for example python's str will inherit both object and String
19:55 lucian allison: in any case, it seems parrot's objects are a mix of high and low level objects
19:56 lucian allison: i think i should just start trying to implement object and see how it goes
19:57 lucian allison: what i don't understand is how interop will work with parrot's objects as they are now
19:59 allison lucian: interop is via vtables
19:59 allison at least "interop" in the sense of accessing attributes, calling methods, etc
20:00 allison take a look at docs/pdds/draft/pdd31_hll.pod for the broader sense of interop
20:00 TimToady phone, I guess
20:00 allison lucian: loading modules across languages, etc
20:00 allison TimToady: dialing
20:00 cxreg joined #parrot
20:00 whiteknight chromatic: ah, I see what's going on. Parrot_*_get_mro is creating an RSA of type names, then Parrot_create_mro is walking that list and creating namespaces and PMCProxies from that list
20:01 chromatic Seems like two steps that could be one.
20:01 lucian allison: so each object/class puts things it might want others to call in its vtable?
20:01 whiteknight that's what I'm thinking, but will require some rewriting
20:02 chromatic lucian, are you familiar with message passing?
20:02 lucian chromatic: yes
20:02 whiteknight chromatic: I'm heading home from work now. I'll tackle this more when I get home. Talk to you then
20:02 lucian chromatic: so it's smalltalk-style?
20:03 chromatic No, but I was going to explain by analogy.
20:04 lucian chromatic: i meant smalltalk-style as in you call a method on an object and it decides what to do
20:04 chromatic Yes, like that.
20:05 chromatic Except that "find a method" is also a method.
20:06 lucian chromatic: right. so you could even handle conversions between naming conventions?
20:06 chromatic Sure, however you store and look up methods depends on your object/class.
20:10 Tene you'd need to be able to subclass Class to have a class that handled that differently than Class.pmc does, though.
20:10 Tene Which we can't do.
20:11 lucian Tene: then how are metaclasses implemented?
20:13 lucian allison: i wasn't sure how i could implement this http://gist.github.com/335672
20:24 bacek joined #parrot
20:25 cotto_work bacek, what was that ping about?
20:25 bacek o hai
20:25 cotto_work helllo
20:26 bacek cotto, about your last commit into ops_pct. You changed number of parsed ops in test.
20:27 cotto_work That could have been an incorrect change.
20:28 cotto_work I'd like to make that test less brittle.  It's non-trivial to verify if the test is failing or if it's just broken.
20:29 bacek If no ops were removed test should pass.
20:29 cotto_work all tests pass with the opsc-built core_ops.c so I'm inclined to blame the test.
20:29 bacek :)
20:29 cotto_work That also makes me suspicious.
20:32 allison lucian: wasn't sure you could implement which? Do you mean "A.print2 = f"?
20:32 lucian allison: that and print3
20:33 NotFound Someone took a look at TT #857 ? I'm checking with Strawberry perl in XP Home and the result of the snippet looks good to me.
20:35 lucian allison: in fact, that's how class definition works in the first place, the rest is sugar
20:37 allison lucian: adding a method to a class at runtime is the 'add_method' vtable function
20:37 lucian allison: yes, i found that out in the meantime
20:41 cotto_work unfortunately the way to verify it is to make ops2c process those files and see how many ops it generates
20:42 cotto_work btw, initial (if rough) self-hosting is accomplished by the bootstrap-ops makefile target.  That item can be taken off the TODO list.
20:43 lucian allison: also, i'd like to see pynie as self-hosted as possible
20:43 cotto_work For verifying that the proper number of ops were produced, it'd probably be best to have a dedicated .ops file in t/ .
20:43 allison lucian: self-hosting as in written in python?
20:43 Austin Allison: what's the position on duplicate named arguments? I'm seeing arguments from calling, e.g., foo( :a(1), :a(2) ), but it strikes me that this is the obvious way to provide and override defaults...
20:44 allison lucian: or self-hosting as in not using NQP?
20:44 lucian allison: for example, all objects should be written in pynie
20:44 cotto_work bacek, could you update the TODO with that?  I'm not sure how soon I'll have tuits.
20:44 lucian allison: i can't see how nqp could be avoided for the compiler
20:44 Austin *seeing arguments = seeing errors
20:44 allison lucian: if we went that route, we should just use PyPy
20:45 lucian allison: i just want to avoid nqp use if possible
20:45 allison lucian: not sure we're going to get the speed that way, though
20:45 allison lucian: aye, I'd like to use Pynie as an excuse for more advanced compiler tools
20:45 lucian allison: with object implemented, dict and the like should be doable in python
20:45 brooksbp_ joined #parrot
20:45 allison lucian: as in, parse the Python3 grammar directly and generate the compiler from it
20:45 lucian allison: there would be a need for an interface to parrot from pynie, like a fake module
20:46 allison lucian: I suspect they'll be slow, though
20:46 allison lucian: they're faster as low-level objects
20:47 lucian allison: why? they'd inherit parrot's Hash and ResizablePMCArray
20:48 lucian allison: something like this http://gist.github.com/335708
20:48 allison lucian: sure, but right now they're written in PIR, as a thin overlay
20:49 lucian allison: would compiled python be much slower than pir?
20:49 allison lucian: at the moment, yes, because parsing python is slow
20:49 allison lucian: the parser is slow in general
20:49 lucian allison: parser aside, why would it be slow?
20:49 allison lucian: down the road it probably won't make much difference
20:50 allison lucian: but choosing between reimplementing features that are already working, and implementing more features, the second is a higher priority
20:50 lucian allison: dict and friends would have to be reimplemented anyway after objects exist
20:51 allison lucian: well, somewhere down the road try it out and benchmark the two
20:53 lucian allison: i don't much see the point of rewriting dict in pir to inherit from python's object than rewriting it in python directly
20:53 eric_j hi all, i would like to work on pynie. i would like to call set_key_type and set_value_type for the dictionary, but i can't figure out the syntax
20:55 allison lucian: honestly, I was thinking of moving all the Python core types to C, but didn't figure it was worth it yet, until we nail down the semantics further
20:55 allison lucian: figured PIR was good for prototyping
20:56 lucian allison: a good jit would have about the same performance as writing it in C
20:56 allison lucian: aye, which we may have by then anyway
20:56 lucian allison: the PyPy folks have showed that extensively with micronumpy and other microbenchmarks
20:58 lucian allison: btw, i've read the jit page, has anything been decided?
21:00 allison lucian: it's been decided to try multiple toolkits and see which serves our needs best
21:00 allison lucian: still leaning toward LLVM, especially with the work the unladen-swallow team has put into it
21:00 lucian allison: well, the u-s guys have run into a lot of issues
21:00 lucian allison: and there's no chance of u-s being anywhere near as fast as PyPy for example
21:01 allison lucian: they've resolved most of their issues
21:02 chromatic LLVM still has to address memory usage.
21:02 allison lucian: and the speed could be considerably enhanced by caching the compiled code
21:02 lucian allison: most of their, but not llvm's. it's still really bad at patching code
21:02 allison lucian: yup, so you can see why we're not committing to it
21:02 allison lucian: the other options are not much better
21:03 lucian allison: it may well be possible that with a mid-level layer (parrot) would make it possible to generate fast static binaries out of high level languages
21:03 lucian using llvm
21:03 NotFound Talking about python and speed? Someone wants to revenge the pie in the face? X-)
21:03 lucian NotFound: what pie?
21:03 purl i heard pie was true. or http://www.piecouncil.org/national.htm or http://london.randomness.org.uk/wiki.cgi?action=in​dex;format=map;index_type=category;index_value=Pie or http://www.austinthirdgen.org/upload/piechart.jpg or http://www.weebls-stuff.com/wab/ or http://flickr.com/photos/cowfish/3137913195/ or http://dilbert.com/fast/2009-03-07/ or position-independent executable (like PIC libraries but more so)
21:03 lucian purl: bad bot
21:03 * purl chuckles evilly
21:03 allison lucian: part of it is, state-of-the-art JIT techniques tend to focus on static languages
21:03 allison LLVM, for example makes all sorts of bad assumptions about whether code will be modified later
21:04 lucian allison: it would also be possible to rewrite parrot in RPython and use PyPy's jit :D
21:04 NotFound lucian: an old parrot tale
21:04 atrodo allison> I'm curious how so
21:04 allison lucian: yes, implementing a JIT once in Parrot is a potential advantage to a number of languages
21:04 allison lucian: ha-ha :)
21:06 lucian allison: i'm semi-serious about that :)
21:06 lucian allison: it would be fast, but it's a LOT of work
21:07 allison lucian: seriously, though, implementing RPython in Parrot is a good goal
21:07 lucian allison: no, parrot in RPython :)
21:07 lucian allison: actually, a RPython variation might be useful as a NQP-for-python
21:08 allison lucian: I'm entirely confident we can do better than PyPy in Parrot
21:08 lucian allison: performance-wise?
21:09 allison lucian: yup
21:09 lucian allison: i'm still skeptical. PyPy does loads of very interesting and hard things
21:09 lucian allison: but having that mid-level abstraction layer might help
21:10 allison lucian: aye, those are interesting and hard things anyone can do, even Parrot
21:11 allison lucian: but, that's down the road
21:11 allison lucian: first, full feature support
21:12 allison (in the language implementations)
21:12 lucian allison: i know, i was just saying they have a head start]
21:12 allison lucian: in some areas, yeah
21:12 allison lucian: they've done great work
21:13 lucian allison: (they did the same thing, first a slow python-in-python, then a translation framework to C, then automatic JIT addition)
21:13 allison lucian: and, they're happy to share too
21:13 lucian allison: yes, i can't wait till we can run py.py on pynie to stress-test it
21:13 Whiteknight joined #parrot
21:14 lucian allison: i'd love to see PyPy become the reference implementation (especially since the interpreter is written in pure python)
21:14 allison lucian: aye, one of the reasons I'd steer clear of python-on-python in Pynie, is that PyPy has already done it so well
21:14 allison lucian: kind of "been there, done that"
21:15 lucian allison: yes, python-on-python would be better as a parrot backend to pypy
21:15 allison lucian: Parrot's competitive advantage is the middle-layer
21:15 lucian allison: but that would be a double interpreter
21:15 allison lucian: and keeping the individual language implementations as thin as possible on top of that middle-layer
21:15 lucian allison: yes, but i still think as much of the core types should be python :)
21:16 eric_j speaking of the full implementation, can someone help me calling set_key_type from PIR? i will add the answer to the wiki...
21:16 allison eric_j: got distracted in the conversation. what do you mean by set_key_type?
21:18 eric_j allison: in dictobject.pir, i am trying to make parrot not coerce the keys to be strings. i understand that parrot's "hash" object has a method called set_key_type that will let you change the key type to be objects, but i can't figure out how to call it
21:18 allison lucian: in the long-term, it doesn't much bother me either way whether they're in Python or PIR or C. In the sort-term, it's a waste.
21:19 lucian allison: a waste to write them in C, true
21:19 allison eric_j: there is no way to do that at the moment in Pynie, as Parrot's core dict-like type only stores string keys
21:19 eric_j hmm
21:19 allison eric_j: so, we'll have to make extensions to that type
21:19 chromatic I thought bacek fixed that.
21:20 lucian allison: but since dict, list and type have to be rewritten in terms of objects anyway (and they're small), why not write them in python? i don't see the waste
21:20 eric_j i was hoping that that was what set_key_type does
21:20 allison chromatic: we talked about it, not sure that it happened
21:21 allison chromatic: it's at least not there in 2.0, which is what pynie runs on
21:21 bacek It was in 1.6 I think.
21:21 bacek hash = .Hash_key_type_int
21:22 bacek or .Hash_key_type_PMC
21:22 allison bacek: dicts have mixed string and integer keys
21:22 allison bacek: and preserve the types of those keys
21:22 eric_j in python, dicts can have any hashable key
21:23 bacek Then use PMC with autoboxing/unboxing
21:23 allison bacek: aye, we can do that
21:24 bacek Actually, Hash will autobox/unbox keys automatically.
21:25 bacek ETOOMANYAUTO
21:25 eric_j bacek: can you help me with the PIR? i'm trying to write $P0.set_key_type (Hash_key_type_int), but evidently i'm in the wrong rabbit hole
21:25 allison bacek: is there a way to set that once for the subclass?
21:25 bacek allison, no afair.
21:26 allison bacek: that option seems to be set once you've already instantiated the object
21:26 lucian eric_j: $P0.'set_key_type' Hask_key_type_int
21:26 bacek eric_j, $P0 = .Hash_key_type_PMC
21:26 lucian eric_j: ignore me, i assumed something wrong
21:27 NotFound In a init vtable override in the subclass?
21:27 Austin eric_j: .include 'hash_key_type.pasm' ; $P0 = new 'Hash'    ;  $P0 = .Hash_key_type_PMC
21:27 bacek eric_j, $P0."set_key_type"(.Hash_key_type_int) should work as well
21:27 allison bacek: I can do it in the dictmaker function, which is what instantiates most dicts
21:27 eric_j thanks guys
21:28 bacek allison, should work. Or override SubclassedHash.init to do it always.
21:31 dalek TT #1515 created by Austin_Hastings++: Duplicate named args cause fatal error in subs
21:34 allison bacek: those constants are defined in 2.0, or at least aren't installed
21:34 allison bacek: *aren't*
21:35 bacek allison, runtime/parrot/include/hash_key_type.pasm
21:35 bacek you have to manually include it.
21:35 allison bacek: aye, the file doesn't exist in a 2.0 install
21:35 bacek Ah, may be...
21:35 allison bacek: (found it in the current trunk no problem)
21:36 allison bacek: it's a generated file, might not be listed in the MANIFEST.generated
21:36 nopaste "NotFound" at 213.96.228.50 pasted "Setting hash key type in subclass init, winxed example" (17 lines) at http://nopaste.snit.ch/19988
21:37 cotto_work bacek, any thought on/objections to adding a fixed .ops file to compilers/opsc/t for use as data?
21:37 allison NotFound: what language is that?
21:37 purl I'm not sure... but it doesn't sound like any kind of English I know.
21:37 brooksbp joined #parrot
21:37 bacek cotto_work, nope
21:38 NotFound allison: Winxed
21:39 allison NotFound: interesting language
21:39 NotFound allison: thanks
21:40 nopaste "NotFound" at 213.96.228.50 pasted "Setting hash key type in subclass init, pir generated by the winxed example" (52 lines) at http://nopaste.snit.ch/19989
21:42 lucian NotFound: looks a bit like C#. not aesthetically nice, but interesting
21:43 NotFound lucian: the syntax is borrowed from javascript with bits of c++ and bits of C#
21:43 lucian NotFound: reading the code.g.c page
21:44 allison bacek: that was it, hash_key_type.pasm wasn't listed in MANIFEST.generated, so wasn't being installed
21:45 allison lucian: we love all kinds of languages here :)
21:45 bacek allison, "installed parrot" is totally unknown beast to me.
21:45 lucian allison: i'm not saying it's not nice, it just looks bad :)
21:46 lucian allison: since most people are used to C-like syntax, it's a necessary evil
21:47 allison bacek: it's a good idea to use it installed whenever possible. Though, what we need most is to be able to run the full test-suite on an installed Parrot
21:47 NotFound lucian: specially when the language creator belongs to that group of people.
21:48 lucian NotFound: heh. i'm half-used to it myself. but i think syntax matters, and C syntax is a bad idea
21:49 NotFound lucian: so bad that it dominates during decades ;)
21:49 allison lucian: all syntacies have a place and a use
21:49 lucian NotFound: yes, it's unfortunate
21:50 lucian allison: that doesn't mean they encourage good practice or they're readable
21:51 kjeldahl joined #parrot
21:51 allison lucian: I don't know, I've found people can write good or bad code in any language
21:51 NotFound lucian: No one person has yet asked what a winxed snippet posted here means. To me that qualifies as readable.,
21:52 allison lucian: and readability is partly a matter of writing good code, and partly a matter of what you're familiar with
21:52 lucian allison: of course. but why not help the programmer write better code if at all possible?
21:53 lucian readability is relative to experience, yes. but any syntax has an inherent readability
21:53 allison lucian: absolutely, and for one programmer Python may be the answer to that, and for another programmer C, or Haskell, or Go might be the answer to that
21:53 dalek rakudo: fed4687 | jonathan++ | docs/ROADMAP:
21:53 dalek rakudo: Tweak the ROADMAP with the results of The Meeting.
21:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​ed46878c492186a006c7a5a8500befda962714c
21:54 allison lucian: the polyglot programmer is on the rise
21:54 lucian allison: that doesn't make C syntax an more helpful
21:54 dalek parrot: r44988 | allison++ | trunk/MANIFEST.generated:
21:54 dalek parrot: [install] Adding the hash-key type definitions to the manifest of
21:54 dalek parrot: generated files so they will be installed.
21:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44988/
21:54 lucian allison: it's terse where it shouldn't be, it has too much noise
21:55 allison lucian: so it's not the language for you, no problem
21:55 NotFound lucian: if you want to rewrite C, you need a flux condenser or something,
21:55 allison lucian: I have spent far more time writing C than high-level languages the past 6 years, and it's grown on me
21:55 allison lucian: for specific kinds of tasks
21:56 allison lucian: though, I wouldn't recommend it as someone's first language
21:56 NotFound Yeah, Z80 assembler is much better X-)
21:56 lucian allison: almost everything about C is nice except part of the syntax
21:56 allison lucian: maybe an acquired taste, like black coffee, or 99% dark chocolate
21:57 lucian allison: for example, ; at the end of lines. there's no real reason for that
21:57 NotFound Mmmm... coffee, good idea.
21:57 lucian NotFound: mmm, dark chocolate
21:58 allison lucian: <shrug> character-delimited statements are easier to parse than newline delimited statements
21:58 allison lucian: and for a low-level language, I'm okay with some syntax decisions made for ease of implementation rather than ease of use
21:59 lucian allison: parsing isn't really an issue. and i don't think ease of implementation should ever dictate syntax
22:00 lucian allison: perhaps at the time it made sense. but nowadays, it doesn't, at all
22:00 he_ joined #parrot
22:00 NotFound I don't think that ending a sentence without puntuaction is more readable. Books use it from hundred of years ago.
22:01 allison lucian: PIR, for example has no statement terminators, but it's also so dead simple that there are no compound statements
22:02 allison lucian: when a language has compound statements and multi-line statements, a character to mark off the end of a statement is pretty handy
22:02 lucian NotFound: books also don't use { } for paragraphs
22:02 allison lucian: the worst use of closing semicolons I've ever found is Matlab
22:02 * lucian goes to read about matlab
22:02 allison lucian: where they're optional, but determine whether the result of the statement is automatically printed
22:03 allison lucian: language design is all about balancing
22:03 lucian allison: oh. that's bad
22:04 NotFound lucian: books uusally doesn't have loops.
22:04 lucian allison: i know, and i don't think C syntax is quite as well balanced as it could be
22:04 allison lucian: certainly annoying to someone who's working primarily in C and Python lately :)
22:04 allison lucian: I should send you a book chapter I once wrote about language design
22:05 allison lucian: it's an absolutely fascinating topic
22:05 lucian allison: indeed
22:05 allison lucian: it's like going from loving Rembrandt, to understanding the choices all painters make
22:06 allison (while still loving Rembrandt)
22:06 lucian NotFound: true, but in code you delimit statements with line breaks anyway, for style
22:06 lucian allison: i do like several languages, while preferring python
22:07 cotto_work joined #parrot
22:08 NotFound lucian: yes, I like to put line breaks where I think looks good, not where some language designer wants to force me.
22:08 lucian NotFound: in this case you're the language designer
22:09 lucian NotFound: and you can put line breaks anyway, but since breaking the convention is more rare than not, \ for line continuation is less noisy than ; for line break
22:09 lucian s/line/statement/
22:09 NotFound lucian: yes, and I don't want to make to others what I don't want others make on me.
22:09 NotFound lucian: oh... \ for line continuation... just like C preprocessor? ;)
22:10 lucian NotFound: a bit, i guess
22:12 NotFound Anyway, the main reason for me to joining parrot is to avoid syntax wars. Write your code in the language you like, and use modules written in any other.
22:13 lucian NotFound: true. very nice
22:13 lucian NotFound: not just syntax wars, but it's DSLs done right
22:14 lucian NotFound: for example i'm fine with either ruby or python, even though most of their differences are syntactical
22:14 NotFound lucian: that's what some religions says: no religion wars, just follow the right god ;)
22:14 lucian NotFound: you have have read me right, i meant that you get real DSLs on parrot, not semi-DSLs as in ruby
22:15 lucian s/you have read me right/you haven't read me right/
22:16 NotFound Oh, I don't follow much the discussions about DSL, and don't know enough Ruby to understand the recent posts on that subject,
22:17 cotto_work joined #parrot
22:17 lucian NotFound: basically ruby syntax allows you to write stuff that's ruby, but looks a bit like another language
22:17 NotFound Yes, with parrot is easy to write your own langauge, either DS or general purpose.
22:17 lucian NotFound: yes, that's what i meant
22:18 NotFound I hope Winxed is a good example of the later.
22:19 lucian NotFound: i sure looks that way :)
22:20 lucian s/i/it/
22:20 NotFound At least is useful to write parrot features examples a lot shorter than in pir.
22:21 NotFound And with better runability than seudocode :D
22:22 GodFather joined #parrot
22:40 eric_j allison, just tried the set_key_type, it works pretty well. however, it looks like __init__ is not automatically being called. i.e., i have to do x={}; x.__init__() because i put the set_key_type in __init__
22:41 lucian NotFound: a language that targets parrot's low level types is indeed useful
22:41 lucian NotFound: i believe there was another such language, Close
22:41 NotFound lucian: yes, but looks like there is not much activity in it these last months.
22:47 allison eric_j: I'll get it built-in to pynie soon
22:48 allison eric_j: have the patch, but it won't work until Parrot 2.3
22:48 * allison afk
22:53 eric_j allison: no problem, i'm working from subversion. if you have an unstable branch in subversion i'll switch to that
22:54 tetragon joined #parrot
22:59 dalek parrot: r44989 | NotFound++ | trunk/CREDITS:
22:59 dalek parrot: fix my entries in CREDITS
22:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44989/
23:06 japhb plobsing, just sent a review of your NCI PDD patch to the list.
23:17 dukeleto japhb: nice writeup
23:17 japhb dukeleto, thanks!
23:30 chromatic dukeleto, could we have a configure step for configure build directory?
23:32 dukeleto chromatic: that sounds nice
23:33 dukeleto chromatic: how would one go about doing that?
23:33 chromatic I'd ask kid51.
23:33 dukeleto chromatic: ok. i will make a TT
23:34 dukeleto chromatic: that very well may help with the RTEMS port as well
23:35 chromatic I think so.
23:35 cotto_work joined #parrot
23:55 Whiteknight chromatic: I'm getting pretty close on tt389_fi
23:56 Whiteknight the new code is much smaller, probably faster
23:58 chromatic Good, I should have some spare time late tonight and tomorrow.
23:59 dalek TT #1516 created by dukeleto++: Allow a build directory to be specificed to Configure.pl
23:59 patspam joined #parrot

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced