|
#parrot Parrot 2.2.0 Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Tasks: Fix compact_pool shenanigans | Fix HLL bugs (TT #389, #1040) | Prioritize Rakudo Needs Set by moderator on 16 March 2010. |
|||
| lucian is going to sleep | 00:06 | ||
| davidfetter | g'night, lucian | ||
| treed | night | 00:09 | |
|
00:09
japhb joined
|
|||
| dalek | kudo: 3a03034 | jonathan++ | src/Perl6/ (2 files): Get the $bottle ~~ s[full] = 'empty' syntax working too. |
00:15 | |
| kudo: 05086a3 | jonathan++ | docs/ROADMAP: Add 'basic s///' to the done section of ROADMAP. One priority #1 item down for Rakudo Star. |
|||
| 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. | ||
| 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. | ||
| nopaste | "Whiteknight" at 68.46.29.192 pasted "example t/Program.nqp test failures for Austin++" (24 lines) at nopaste.snit.ch/19969 | 00:21 | |
| Whiteknight | purl msg Austin nopaste.snit.ch/19969 | ||
| purl | Message for austin stored. | ||
|
00:22
chromatic joined
00:23
theory joined
00:38
snarkyboojum joined
01:02
hiroyuki_y joined
|
|||
| Whiteknight | I can't do any more debugging tonight. Lost. | 01:02 | |
| dalek | kudo: c053d61 | jonathan++ | src/pmc/p6invocation.pmc: Fix .can.Bool. |
01:12 | |
| kudo: 1120182 | jonathan++ | src/ (2 files): Re-enable infix:<Z> and infix:<X> with a tweak so Z- style meta-ops still parse correctly. |
|||
| cotto | HELO INTERNETS | 01:26 | |
| dalek | kudo: e3937f7 | (Solomon Foster)++ | build/PARROT_REVISION: Bump Parrot to 2.2.0. |
01:52 | |
| kudo: 72046f9 | (Solomon Foster)++ | src/core/Any-list.pm: Don't assume that a Code block will know how to .count. |
|||
| dukeleto | cover? | 01:59 | |
| purl | cover is not at link? | ||
|
01:59
brooksbp joined
02:01
allison joined
|
|||
| dukeleto | purl, cover is tapir2.ro.vutbr.cz/cover/cover-results/ | 02:02 | |
| purl | ...but cover is not at link?... | ||
| dukeleto | purl, forget cover | ||
| purl | dukeleto: I forgot cover | ||
| dukeleto | purl, cover is tapir2.ro.vutbr.cz/cover/cover-results/ | ||
| purl | OK, dukeleto. | ||
|
02:05
hudnix joined
|
|||
| 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:13 | |
| cotto | coverage? | 02:18 | |
| purl | coverage is cv.perl6.cz | ||
|
02:18
snarkyboojum joined
02:38
JimmyZ joined
|
|||
| dalek | rrot: r44977 | cotto++ | branches/ops_pct/compilers/opsc (6 files): [opsc] revert a batch of pod fixes that don't apply to nqp, fix the opsfile test |
02:51 | |
| Austin | chromatic: ping | 03:03 | |
| bacek_at_work | cotto, ping | 03:19 | |
|
03:22
hiroyu___ joined
|
|||
| dalek | rrot: r44978 | coke++ | trunk/DEPRECATED.pod: Add reference to TT #1427 |
03:24 | |
|
03:27
_2x2l joined
|
|||
| sorear | hmm, was the 2.1.1 release announcement deleted? | 03:30 | |
| Coke | no, just not sticky, apparently. fixing. | 03:31 | |
| there. | 03:32 | ||
| sorear | I see it again | ||
| sorear upgrades | 03:35 | ||
| purl | upgrades are good! | ||
|
03:54
janus joined
|
|||
| Coke | guybrush? | 04:22 | |
| guybrush is <reply>I'm guybrush threepwood, mighty pirate. (TM) | 04:23 | ||
| pmichaud | use.perl.org/~pmichaud/journal/40248 | 04:43 | |
| (for those who are wondering about my absence from Perl 6 and Parrot) | |||
|
05:47
chromatic joined
|
|||
| chromatic | Austin, pong. | 05:53 | |
| cotto | bacek_at_work, pong | 06:20 | |
| . o O (I need to work on those ping times) | 06:31 | ||
| 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 / | ||
| sorear | Where is the list of functions that are kosher to call from a dynpmc? | 06:59 | |
| Parrot functions, I mean | 07:00 | ||
| cotto | PARROT_API is the marker we use (or should be using) iirc | ||
| sorear | ah, I was under the impression that was for embedding and there was a separate list for extenders | 07:01 | |
| cotto | It could be. My track record for getting things right is pretty bad this week. | 07:02 | |
| chromatic | There are separate headers named embed.h and extend.h, but that's a historical artifact we've never yet fixed. | 07:04 | |
| cotto | did particle ever figure out what broke rakudo on win32? | 07:07 | |
| cotto needs to get to bed. | 07:09 | ||
| chromatic | I didn't hear anything other than the memory usage. | 07:11 | |
|
07:15
fperrad joined
|
|||
| dalek | rrot: r44979 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Grammar.pm: [opsc] tighten grammar to avoid capturing whitespace surrounding macros |
07:29 | |
| rrot: r44980 | cotto++ | branches/ops_pct/compilers/opsc (2 files): [opsc] pass oplib to Ops::File new_str, fix emitter test |
|||
|
07:57
jan joined
08:07
bacek joined
|
|||
| bacek | aloha | 08:07 | |
| seen chromatic | |||
| purl | chromatic was last seen on #parrot 56 minutes and 4 seconds ago, saying: I didn't hear anything other than the memory usage. | ||
| sorear | hello | ||
| purl | hello, sorear. | ||
| 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:09 | |
| 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. | ||
| 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. | ||
| chromatic | Getting rid of the linked list in CallContext should take care of the rest. | 08:14 | |
| bacek | yeah. It will help a lot. | 08:26 | |
| But it's task for different branch | |||
| . o O ( Is it possible to have normal branching in svn? ) | |||
| chromatic | You have git and I have git; there's no reason we have to do this in svn. | 08:28 | |
| bacek | we are still using svn as "exchange point" | 08:29 | |
| let me try to branch of branch | |||
| chromatic | Should work. | 08:30 | |
| It worked in CVS, in so far as you could do it in CVS. | 08:31 | ||
| bacek | bacek@icering:~/src/parrot$ git svn branch pcc_megrecells -m "Sub-branch to replace CallContext's cells linked list with array" | 08:32 | |
| Copying svn.parrot.org/parrot/branches/pcc...hon_6Mar10 at r44974 to svn.parrot.org/parrot/branches/pcc...recells... | |||
| Looks like it will work | |||
| chromatic | What's your plan? Or do you want my plan? | 08:33 | |
| dalek | rrot: r44981 | bacek++ | branches/pcc_megrecells: Sub-branch to replace CallContext's cells linked list with array |
08:34 | |
| bacek | Your first | ||
|
08:35
iblechbot joined
|
|||
| chromatic | I think we need a pointer to the cells and a pointer to the first free cell. | 08:35 | |
| If we don't have a free cell, we double in size and copy. | 08:36 | ||
| bacek | Erm... | ||
| chromatic | Yeah, there's a flaw in that. How do we know when we've used all of the cells? | 08:37 | |
| Okay, we track the number of positionals already. That's the number of used cells. | |||
| 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. | ||
| Yeah, same strategy. | |||
| bacek | fill_params just use VTABLE_push_foo | ||
| everything else is encapsulated in CallContext | 08:39 | ||
| chromatic | Works for me. | ||
| bacek | We have freedom to use any strategy we want to | ||
| Deal :) | |||
| chromatic | First, I sleep. | 08:44 | |
| bacek | It's a good habbit | 08:46 | |
|
08:51
uniejo joined
08:59
cosimo joined
09:02
AndyA joined
|
|||
| sorear | the documentaion for the destroy() vtable function states that the called function must not make new references to the doomed value | 09:05 | |
| what hook should I use, if I cannot control the results? | |||
| e.g. Perl5 DESTROY semantics, runs arbitrary code | 09:06 | ||
|
09:24
bacek_ joined
|
|||
| 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 | |
| sorear, for example check FileHandle.destroy | 09:25 | ||
| sorear | yes | ||
| that much is clear to me | |||
| but I want to run code which I have no control over | |||
| hmm | 09:27 | ||
| on second thought | |||
| does "arbitrary" code extend to "calling back into the Parrot runloop and allocating memory while traversing PMC structures"? | |||
| how does the garbage collector take to recursion? | |||
| bacek_ | it should be fine afaiu. If it's not it's a bug. | 09:28 | |
|
09:33
he_ joined
09:47
payload joined
|
|||
| dalek | kudo: fc02ce6 | moritz++ | t/spectest.data: run more test files |
09:53 | |
|
09:57
payload joined
09:59
payload1 joined
10:09
riffraff joined
10:16
payload joined
10:21
smash joined
|
|||
| smash | hello everyone | 10:21 | |
|
10:23
payload1 joined
|
|||
| lucian | treed: hi | 10:54 | |
| purl | hola, lucian. | ||
| lucian | purl: shut up | ||
| purl goes on and on about how much shutting up she's doing | |||
| he_ | Tried today's build, worked better, but t/compilers/pge/03-optable.t test fails, ref. smolder.plusthree.com/app/projects/...ails/32720 | 11:02 | |
|
11:49
contingencyplan joined
12:01
whiteknight joined
|
|||
| Austin | Good morning, Whiteknight. | 12:01 | |
| whiteknight | good morning Austin, get all my messages last night? | 12:02 | |
| Austin | yeah | ||
| 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 | ||
| 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. | ||
| whiteknight | on the bright side, I've gotten much better at typing with one hand | ||
| Austin | Boy, there's a joke there... | 12:03 | |
| whiteknight | blah blah blah, internet pornography, blah blah blah | 12:04 | |
| ...and then we all chuckle uneasily | |||
| 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? | ||
| purl | Message for coke stored. | ||
| Austin | So I've got nqp generating trampolines to assemble multisubs. | 12:06 | |
| And I've come across what I think is a bug. | 12:07 | ||
| (Whooo, what a surprise..) | |||
| whiteknight | I'm not sure I'm entirely clear about what a trampoline is | ||
| I had read about them a while ago, and I'm not sure I took the time to really get it then | |||
| Austin | It's internal, so don't worry. But it's a sub, whose purpose is to bounce you over to another sub. | ||
| dalek | tracwiki: v52 | Austin_Hastings++ | ParrotQuotes | 12:08 | |
| tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff | |||
| Austin | You know how websites have landing pages? | ||
| You come to one because of google, or because they put it in a tv ad | |||
| And then you get redirected to where they "really" want you to go? | |||
| whiteknight | yeah | 12:09 | |
| Austin | Well, that's a trampoline. | ||
| You hit it, it bounces you over to where you're really supposed to go, maybe after fixing your args or something. | |||
| whiteknight | okay | ||
| The wikipedia article on the topic is turning out to be mostly unhelpful | 12:10 | ||
| en.wikipedia.org/wiki/Trampoline_%28computers%29 | |||
| Austin | In my case, multisubs, there's no way to dynamically attach multi signatures to a live sub. | ||
| (Wikipedia: I think it's one of those things where you have to know the answer before you ask the question.) | |||
| 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 | |
| why can't you attach a multisignature to an existing Sub? | |||
| you should be able to add the Sub to a MultSub with the signature | |||
| Austin | Yeah, but the mmd stuff queries the sub about what it wants to compute the score, I think | 12:12 | |
| Umm, "not quite" on the whole thunk/closure thing. | 12:13 | ||
| There's no data. | |||
| It's just a redirector. | |||
| Anyway, let me tell you a little story, and you tell me if this is a bug. | 12:14 | ||
| I've got a multisub with three subs in it. | |||
| whiteknight | yay! story time | ||
| Austin | One of them isn't relevant, so I'll ignore it. | ||
| The other two have multi-signatures (they're methods) of (_, _) and (_, String). | 12:15 | ||
| The _ is, as I understand it (and I may *very* well be wrong here) sugar for "Any PMC type" | |||
| whiteknight | it's any PMC type, but matching with the least closeness | ||
| Austin | I call the multisub using 7 $foo.append("a") | 12:16 | |
| The NQP generated preserves the literal-string in the code, so the pir looks like $Pxx.'append'("a") | |||
| Which of the multisubs should get called? | 12:17 | ||
| whiteknight | I think (_, _) | ||
| Austin | Heh. | ||
| whiteknight | I don't think the invocant counts towards the multisig | ||
| Austin | Actually, he does. | ||
| 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 | ||
| Making it a method just means that the invocant is the first param. | |||
| whiteknight | are you sure about that? | 12:19 | |
| nopaste | "Austin" at 68.39.12.202 pasted "t/pmc/multidispatch.t" (17 lines) at nopaste.snit.ch/19970 | 12:21 | |
| whiteknight | ah, okay then | ||
| Austin | So down in the bowels of src/multidispatch.c, there's this function called mmd_distance | 12:22 | |
| whiteknight | more like the colon | 12:23 | |
| Austin | And there's a loop at about line 762 that iterates over all the args/multisig | ||
| Larry gets the colon. | |||
| 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? | ||
| whiteknight | he_: Do you have an older installed version of Parrot? | ||
| 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" | ||
| whiteknight | ok | ||
| Austin | Which purports to be the mmd_distance between the args as passed and the sig as-wanted | ||
| (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. | ||
| Austin | he_: Are you on unix/linux? | 12:26 | |
| whiteknight | he_: I don't know then. Try make realclean, reconfigure, rebuild | ||
| nopaste | "he" at 158.38.152.80 pasted "patch for tools/dev/pbc_header.pl to make it work again" (18 lines) at nopaste.snit.ch/19971 | ||
| he_ | Austin: I see this problem on NetBSD/macppc and NetBSD/sparc64, but not on NetBSD/i386. | 12:28 | |
| Austin | run 7 od -t x1 FILENAME | head -1 | 12:29 | |
| look at the last two bytes on the first line, what are they? | |||
| (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 | ||
| Austin | Okay, so your file really is 5/3. | ||
| how about ./parrot -V | 12:32 | ||
| Does that say 2.2.0? | |||
|
12:34
ruoso joined
|
|||
| 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 | |
| So the mmd distance between (_, string) and (_, String) is 1. | |||
| Otherwise, there is an explicit check for _: if type_sig==PMC, dist++;continue | 12:37 | ||
| he_ | Trying the realclean route, did "distclean" earlier. | ||
| Austin | Which to me says that the distance between _ and any "lowercase type" (int, string, float, short, etc.) is 1. | 12:38 | |
| 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. | ||
| he_: That's bad. | |||
| he_: Create a x.pir file with two lines: .sub foo ; .end and compile that with ./parrot -o x.pbc x.pir | 12:40 | ||
| 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. | ||
| purl | Message for whiteknight stored. | ||
| 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. | ||
| he_ | And compilers/pge/PGE.pbc is oldish, Jan 20. Not re-generated, not cleaned, apparently. | ||
| whiteknight | Austin: Okay,I see what you are saying | ||
| he_ | Missing dependency / cleanup? | 12:43 | |
| Austin | he_: Sounds that way. | ||
| whiteknight | so a string matches (_,_) just as well as matches (_,String) | ||
|
12:43
tetragon joined
|
|||
| Austin | whiteknight: Yes, and with the same mmd distance. | 12:44 | |
| (1) | |||
| 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" | |||
| 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 | ||
| I'm not sure if this is a bug, or not. | |||
| (Except of course that any failure to DWIM is automatically a bug...) | 12:47 | ||
| Coke | I don't think anything should be generating that file atm. | 12:50 | |
| (the PGE one.) | |||
| 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. | ||
| *remnant | |||
| 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:52 | |
| Austin | So I should expect what, a junction of behaviors? | 12:54 | |
| dalek | rrot: r44982 | gerd++ | trunk/docs/pdds/pdd30_install.pod: Add a missing slash |
||
| whiteknight | basically, yes. A string should match a String more closely than it matches a _ | ||
| 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 | ||
| Austin | So I can understand a sort of "well, suck it up" approach. | ||
| whiteknight | I don't know what it does in those cases | ||
| Austin | But in this case (it's *ME* and I'm *special*) I'm trying to use _ as "anything I haven't mentioned explicitly" | ||
| So I want to say that String is closer than _ | 12:58 | ||
| and call it a bug. | |||
| 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 | ||
| I think that String should definitely be closer than _ | |||
| 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. | 12:59 | |
| 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 nopaste.snit.ch/19975 | ||
| Austin | No. I didn't say "Austin rocks!" | 13:01 | |
| I was chasing this bug, instead of yours. | |||
|
13:03
parthm joined
|
|||
| Austin | Deja freaking vu. | 13:05 | |
| whiteknight: You know, some dude found this same bug and opened a ticket (TT#1144) 5 months ago. | |||
| Heh. | 13:06 | ||
| Complete with pure pir example. | |||
| whiteknight | saves you some effort then | ||
| Austin | No, just pisses me off. It's my ticket. | 13:07 | |
| 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 | |
| t/compilers/pge/03-optable.t does load_bytecode 'compilers/pge/PGE.pbc' | |||
|
13:09
atrodo joined
|
|||
| he_ | Absent the PGE.pbc file, PGE.pir will be used. | 13:10 | |
| Currently there doesn't appear to be code to recreate the PGE.pbc file. | |||
| It appears that "realclean" won't remove the PGE.pbc file either, it must be manually removed (ugh) | |||
| Austin | he_++ | 13:11 | |
| find . -name '*.pbc' | 13:12 | ||
| he_ | There's quite a few oldish files lying around. | 13:13 | |
| 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:16 | |
| he_ | Well, I've continually updated with "svn update". | 13:18 | |
| Typically at least once per release. | |||
| t/native_pbc/integer_5.pbc is in SVN, created with parrot 1.0, bytecode file format version 4.0 | 13:19 | ||
| "that's not going to work", I guess. | |||
| 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. | ||
| he_ | oh, that violates the principle of least astonishment... | ||
| Coke | he_: when you're changing the build system, it's hard to guarantee. =- | 13:22 | |
| ) | |||
| 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. | |||
| 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 nopaste.snit.ch/19980 | ||
| he_ | Of these, t/tools/install/testlib/runtime/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:28 | |
| Coke | he_: no. distclean cleans things it /knows/ about. | 13:31 | |
| 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 | ||
| whoops. | |||
| Austin | find . '(' -type d -name '.svn' -prune ')' -o -name '*.pbc' \\! -name 'pbc_merge_t*.pbc' -print | ||
| Coke | yes. | ||
| plobsing | svnclobber the files from space. It's the only way to be sure. | ||
| Austin | If only we could get that on windows. | ||
| Coke | Austin: ... 'make svnclobber' | ||
| he_: you're right; if you do the distclean first, you'll be in a much better positions. | 13:33 | ||
| Sorry, was stuck in "broken record" mode. =-) | |||
| Austin | Should that be part of realclean or distclean? | ||
| Coke | Austin: hell no. | ||
| it's the nuclear option. | |||
| Austin | Huh? | ||
| plobsing | Austin: no! I like my untracked files! | ||
| he_ | Well, the Makefile(s) were generated by the old version, so it should know at that point what to clean up after itself. | ||
| 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. | ||
| Austin: no. | |||
| I love my untracked files. | |||
| Coke notes that 'svnclobber' is the nuclear option, not austin's script. | |||
| but austin's script still removes things I wouldn't want removed on a realclean. | 13:36 | ||
| Austin | How so? | ||
| (Actually, since my script doesn't include '| xargs rm -f', it doesn't remove anything...) | |||
| Coke | Austin: thbbthp. | ||
| 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? | ||
| Coke | that doesn't mean we shoudl remove ones the /user/ created. | ||
| 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 | |
| Or we could figure that realclean means "yeah, rm stuff" | |||
| :) | 13:40 | ||
|
13:40
mls joined
|
|||
| mls | Hi, src/packfile.c looks suspicious in line 4446: | 13:41 | |
| self->groups = self->groups = mem_gc_realloc... | |||
| gcc complains about "causes undefined operation" | 13:42 | ||
| Coke | ooc, which version of gcc is complaining about that? | 13:47 | |
| (fixing shortly) | |||
| mls | gcc version 4.5.0 20100311 (experimental) [trunk revision 157384] | 13:48 | |
| Coke | spif. | 13:49 | |
| 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/ | ||
| Coke | mls? | 13:52 | |
| purl | mls is Master of Library Science or Minnesota Language Systems or Multiple Listing Service (real estate) or mailing lists | ||
| 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 | ||
| Coke | packfile.c updated. Thanks. | 13:54 | |
|
13:54
theory joined
|
|||
| Austin | msg whiteknight I pushed a src/Program and t/Program bundle to master just now. | 13:54 | |
| purl | Message for whiteknight stored. | ||
| 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:55 | |
| whiteknight | nice | 13:57 | |
| 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. | ||
| dalek | kapo: 91fa256 | austin++ | (2 files): 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. |
||
| 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. | ||
| dalek | rrot: r44983 | coke++ | trunk/src/packfile.c: remove useless self-assignment, courtesy mls++ |
||
| 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. | ||
| 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. | ||
| whiteknight | Coke: and that's what we want? | ||
| Coke | so we should try to pass through as many of those compiler option as possible. | ||
| whiteknight: unless you want to build a second config system, yes. =-) | |||
| whiteknight | okay, I won't argue it then. Giving pbc_to_exe some commandline args to control optimizations might be nice | 14:06 | |
| a -O option would pull Parrot's optimize flags | |||
| Coke | ... of course, if parrot wasn't compiled with optimization, it'd be useless. | ||
| I think having a second set of options there is overkill. | |||
| DRY (unless you really need to) | 14:07 | ||
| Coke tries something: | |||
| coke_at_work drifts off into the corner. | |||
|
14:07
patspam joined
|
|||
| coke_at_work | SPAMMER! | 14:07 | |
| purl | Spammer, spanner. Spanner, spammer. "Ow!" | ||
| coke_at_work | patspam? | 14:08 | |
| purl, bad bot. | |||
| purl chuckles evilly | |||
|
14:09
parthm left
|
|||
| 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 | |
| where this way == using the optimize flags. | |||
| 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 | ||
|
14:15
bubaflub joined
|
|||
| dalek | TT #1513 created by Austin_Hastings++: Test::Builder formats TODO tests wrong/poorly | 14:23 | |
|
14:31
davidfetter joined
|
|||
| nopaste | "Whiteknight" at 173.12.37.77 pasted "Current test results after t/Program.nqp fix for Austin++" (89 lines) at nopaste.snit.ch/19982 | 14:35 | |
| Austin | Looks just like mine. Whiteknight++ | ||
| whiteknight | nice | 14:36 | |
| good progress is good | |||
| Austin | You haven't found out yet that you're boned. | ||
| Crap. | |||
| I forgot you were depending on Nqp | 14:37 | ||
| 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:43 | ||
| coke_at_work | (yo, I heard you like nqp, so I put some nqp in your nqp?) | 14:46 | |
| dalek | kapo: 8151d15 | austin++ | (3 files): Reinstated File.nqp to get Nqp.nqp working, for Whiteknight++ |
||
| Austin | Hell, yeah. | ||
| (Also, here's at least one function for interacting with the NQP compiler from within nqp code...) | 14:47 | ||
| Nqp::compile_file( 'foo.nqp' ) | |||
| dalek | kudo: 02ba26c | snarkyboojum++ | (3 files): An attempt at getting .rotate working |
14:49 | |
| kudo: d0f934f | (Solomon Foster)++ | src/core/Seq.pm: Delete trailing whitespace. |
|||
| 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
|
|||
| Austin | okay | 14:57 | |
| whiteknight | yeah, all tests pass | 15:02 | |
| so barring complaints from the powers-that-be, it's in | |||
| too bad I can't retroactively apply it to 2.2 | |||
| or "2.0" as the locals call it :) | 15:03 | ||
| Austin | Heh. | ||
| My birthday's in April, so it'll make a nice gift. | |||
| 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:04 | |
| Austin | Just using Kakapo has been doing a bunch of good for me, in terms of getting some real-world exposure. | 15:05 | |
| 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:07 | |
| 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:10 | |
| whiteknight | nice | 15:11 | |
| coke_at_work: that's cool, but I would be hesitant to change too much in the 2.2.1 | |||
| Austin | BTW, did you read the diagnostic on the MockFS failure you nopasted? | ||
| oh, never mind | 15:12 | ||
| It was the wrong test... | |||
| I just got this: t/Cuculinae/MockFS.nqp ................ 1/2 # Don't know how to check if String exists. Use a String or Path | |||
| Because of the _ versus String thing... | |||
| 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:19 | |
| Austin | Heh. | 15:24 | |
| Ironically, the OS.pmc won't tell me what OS I'm using. | |||
| How do I do OS-based behavior in Parrot? | |||
| coke_at_work | Austin: what are you trying to do ? | 15:25 | |
| Austin | Create a different class to support different filesystem semantics | ||
| coke_at_work | ok. we don't probe for the fs type yet, I don't think. | ||
| 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? | ||
| coke_at_work | s/right/closest/, yes. | ||
| kind of like us peeking into perl5's build config is the closest parrot has in some places. | 15:27 | ||
| but since we don't really support x-platform yet, it's probably good enough for some time. | |||
| Austin | What's the origin of the config <osname> key? | 15:28 | |
| Mine says 'linux', but uname reports 'Linux'... | 15:29 | ||
|
15:35
Psyche^ joined
|
|||
| coke_at_work | Austin: you can figure that out by acking through the config dir for osname. checking... | 15:37 | |
| I don't see anything that explicitly sets 'osname', so it's probably coming from P5's Config. | |||
| Austin | auto/arch.pm | 15:38 | |
| which comes from get('archname') | |||
| coke_at_work | ah, it was a multiline. =-) | ||
| Austin | which appears in p5_keys_whitelist? | 15:39 | |
| Which appears to mean it gets passed through | 15:42 | ||
| coke_at_work | it's not a straight passthrough. | 15:43 | |
| Austin | heh | ||
| coke_at_work | auto/arch.pm processes it. | ||
| not sure what the whitelist is doing there. | 15:44 | ||
| but the source is, ultimately, p5. | |||
|
15:44
whiteknight joined,
Andy joined
|
|||
| Austin | Woot. Contextuals look for both caller lexicals and namespace globals. | 15:51 | |
| Pmichaud++ | |||
| davidfetter | hello | 15:53 | |
| purl | hey, davidfetter. | ||
| davidfetter | so i'm confused about the latest in pdd16 (nci) | 15:54 | |
|
15:54
janus joined
|
|||
| davidfetter | in particular plobsing's patch for same, which appears to change docs so far. does the code need to change along with? | 15:55 | |
| Austin | Changing the PDD implies that any behavior that does not conform to the PDD is in error. | 15:56 | |
| Which is why it's a mailing list discussion, and not a 3am commit... | |||
| :) | |||
|
15:58
he_ joined
|
|||
| 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:09 | |
| 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:12 | |
| davidfetter | oh, the person in quesion :) | 16:14 | |
| plobsing runs and hides | |||
| davidfetter | heh | ||
| do you have any interest in postgres? | |||
| plobsing | I don't have much skill with databases. So not directly. | 16:15 | |
|
16:16
bacek joined
|
|||
| plobsing | the PL/Parrot stuff just happens to be running into the same problems I've run into a couple times now. | 16:16 | |
| davidfetter | this all came up because we're trying to make parrot (eventually) pg's language engine | 16:17 | |
| :) | |||
| who's, "we?" | |||
| er, where are you running into these problems? | |||
| <-- ETOOLITTLECOFFEE | 16:18 | ||
| plobsing | 1.) frame builder 2.) Parrot::Embed 3.) vim-parrot (personal project, not yet published) | ||
| davidfetter | <-- vim user :) | 16:19 | |
| cotto_work | bacek or bacek_at_work, ping | 16:24 | |
|
16:25
kjeldahl joined
16:32
jsut joined
|
|||
| plobsing | davidfetter: also I have a vendetta against varargs | 16:33 | |
| Austin | D'oh. Storing contextuals doesn't check for dynamic vs. global. | ||
| davidfetter sends plobsing up the nung river in a pt boat | |||
|
16:38
whiteknight joined
|
|||
| whiteknight | internet connection is teh suxxor | 16:40 | |
| allison: ping | 16:41 | ||
| dalek | kapo: 70ee5af | austin++ | (3 files): Fixed ordering test in Loader.nqp Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com> |
||
|
16:47
Mokurai1 joined
|
|||
| dukeleto | 'ello | 16:49 | |
| bubaflub | afternoon duke | 16:50 | |
| dukeleto | bubaflub: howdy | ||
| plobsing: yes, PL/Parrot is running into lots of sharp corners of the Parrot embedding API :) | |||
| plobsing | dukeleto: embedding parrot, its hard not to run into sharp corners. | 16:52 | |
|
16:52
chromatic joined
|
|||
| dalek | TT #1514 created by Austin_Hastings++: NQP-rx doesn't check storage mode for contextuals | 16:52 | |
| whiteknight | I would like it if dalek would print a link to the ticket | 16:53 | |
| Austin | You know, I suggested making that a bot | 16:54 | |
| But they told me, "Oh, that's in the irclogs." | |||
| whiteknight | what's in the logs? | 16:55 | |
| Austin | Apparently, nobody but us suxxors actually follows IRC. Everyone else follows the logs. | ||
| darbelo | Austin: That's not the same as 'no'. | ||
| Austin | The TT# -> link converter | ||
| whiteknight | Ah, that would be a cool bot | ||
| plobsing | or you could add a script to your irc client to match patterns like that and make links | ||
| whiteknight | even cooler if it were written in Parrot | ||
| an IRC library would be a cool project | |||
| 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. | ||
| plobsing | whiteknight: that just means you get to do *more* scripting! scripting is fun right? | 16:58 | |
| dukeleto | Austin: i would very much like a link to the TT as well | 16:59 | |
| dalek ? | |||
| purl | dalek is #parrot's spammy little rss bot or (see: dalek plugins) | ||
| dukeleto | dalek plugins ? | 17:00 | |
| purl | i heard dalek plugins was github.com/Infinoid/dalek-plugins/tree/master | ||
| Austin | I was thinking more of a live rewriter, that would translate anyone's tt# into a link. | 17:03 | |
| I say tt#2 | |||
| and ttbot says: TT# 2 is at trac.parrot.org/parrot/ticket/2 | 17:04 | ||
| (Or whatever) | |||
| darbelo | ttbot? | ||
| purl | ttbot is TapTinder build bot owned by mj41 and reporting tt.taptinder.org/buildstatus/pr-Parrot/rp-trunk build errors. | ||
| Austin | I wonder if purl is smart enough for that | ||
| So ttbot is already taken... | 17:05 | ||
| It was the obvious name.. | |||
| purl help? | |||
| 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 | ||
| Austin | fna | ||
| bubaflub | we had something like that for our companies ticket system | ||
| i might be able to resurrect the code | |||
| all i'd need is a server to run it on so it could listen in the chanel | 17:06 | ||
| everytime we'd say #1234 | |||
| it would spit out the link to our internal tracker | |||
| Austin | I'm wondering if purl is smart enough for that.. | ||
| whiteknight | I had a bot like that for Wikipedia. Long time ago | ||
| Austin | What software is she running? | ||
| cotto_work | infobot | ||
| probably with many additions | 17:07 | ||
| Austin | If this is magnet, she's flooterbuck. | 17:08 | |
|
17:14
cosimo joined
|
|||
| dalek | rrot: r44984 | gerd++ | trunk (5 files): add the option: "perl Configure.pl --pkgconfigdir=DIR" |
17:16 | |
| Austin | tinyurl example.com/test | 17:25 | |
| purl | Your tinyurl is tinyurl.com/4o6x2s | ||
| Austin | Thanks, purl. | ||
|
17:28
ruoso joined
|
|||
| allison | whiteknight: pong | 17:29 | |
| whiteknight | allison: can you take a look at my patch for TT #1144 | ||
| fixes the ticket and passes all tests, but I want an eye to double-check the approach | 17:30 | ||
| there's a question about whether this is even the intended behavior, which I think it should be | |||
| allison | sure | ||
| whiteknight | thanks! | 17:31 | |
|
17:31
ash_ joined
|
|||
| allison | whiteknight: looks great! | 17:33 | |
| whiteknight | awesome, thanks! | ||
| allison++ | |||
| dukeleto | i thinks making dalek spew the TT link when it announces a new ticket would be the best + easiest | 17:34 | |
| Austin | It's a start. | 17:35 | |
| dalek | kapo: 5c3b3a6 | austin++ | (2 files): Got the string-oriented parts of Path working, tested. |
17:42 | |
| chromatic | +1 on the MMD patch. I'm not sure why it didn't work that way before. | 17:44 | |
| whiteknight | thanks. I'll commit it in a few minutes | 17:47 | |
| I'm working on a patch right now for the RO stuff in tt389_fix | |||
| looks like it fixes at least a few broken tests | |||
| chromatic | The fact that the RO vtable doesn't have the proxy in pmc_class? | 17:48 | |
| whiteknight | yeah | ||
| I'm basically sharing it. vt->ro_variant_vtable->pmc_class = vt->pmc_class | |||
|
17:48
brooksbp joined
|
|||
| whiteknight | a little ugly, but workable | 17:48 | |
| 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. | ||
| whiteknight | I'm doing a comparison right now to double-check that I'm fixing tests and not regressing anywhere | 17:50 | |
| I'm still seeing plenty of places in the code where things are being looked up in vtable->_namespace | 17:51 | ||
| and those are leading to Null PMC access errors | |||
| I think if we find and hunt down the rest of those we will be in better shape | |||
| chromatic | Places that look up methods? | 17:53 | |
| whiteknight | yeah | ||
| also, the issue with inheritance | |||
| 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 | ||
| probably a bunch of cut+paste from Object.pmc:find_method | |||
| chromatic | Can probably do that. | 17:55 | |
| dukeleto | looks like github.com/Infinoid/dalek-plugins/b...cketlog.pm needs to be slightly modified to emit a TT URL | ||
| bubaflub | dukeleto: i think it's calling the emit_karama_message in karmalog.pm | 17:57 | |
| github.com/Infinoid/dalek-plugins/b...og.pm#L167 | 17:58 | ||
| right after that | |||
| coke_at_work | aooga: | 18:02 | |
| The OSUOSL will be performing an IOS upgrade on our primary Cisco router | |||
| this coming Wednesday, March 24, 2010 between 7:00-7:30PM PDT (0200-0230 | |||
| UTC). Networking for *ALL* of the OSUOSL will be down for approximately | |||
| 5 minutes during the outage and will be restored once the update is | |||
| complete. | |||
| purl | Nothing ever is. | ||
| coke_at_work | (this means us) | ||
| Austin | Heh. 5 minutes. | 18:03 | |
| whiteknight | yeah, 5 minutes in IT time is damn near all day | 18:04 | |
| cotto_work panics | |||
| dalek | rrot: r44985 | whiteknight++ | branches/tt389_fix (2 files): share pmc_class between a vtable and the ->ro_variant_vtable. Fixes 6 tests in t/dynpmc/rotest.t |
18:06 | |
| rrot: r44986 | whiteknight++ | trunk/src/multidispatch.c: [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 |
|||
| dukeleto | bubaflub: mad props to you if you add TT URLs :) | ||
| dalek | TT #1144 closed by whiteknight++: MMD incorrectly matches _ instead of String | 18:14 | |
| whiteknight | yay karma! | 18:15 | |
| 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 | |
| or should i just do a pull request from github? | |||
| 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:17 | |
| dukeleto | bubaflub: Infinoid. yeah, a pull request is probably best | 18:18 | |
| bubaflub | "Hardcore Forking Action". ah, github. | ||
| dukeleto | bubaflub: yeah, that always makes me happy :) | 18:19 | |
| bubaflub | ok, pull request sent to Infinoid through github | 18:21 | |
| we'll see what happens | |||
| Austin | bubaflub: What's the modified structure of the dalek messages? | ||
| bubaflub | Austin: just a second line below the first | 18:22 | |
| with the URL | |||
| Austin | Okay. | ||
| bubaflub | github.com/bubaflub/dalek-plugins/commit/37807a | ||
| to see the changes, pretty simple really. | |||
| Austin | Moritz' irclog stuff processes the contents to make #123 into a link, so you'll want to make sure that stays in. | ||
| bubaflub | okey dokey | 18:23 | |
| 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 | ||
| we get that worked out, everything should be fixed. | |||
| Infinoid | bubaflub: thanks for the patch. Any objection to including $prefix on the link line too? | 18:25 | |
| bubaflub | Infinoid: not at all. | ||
| (at least from me) | 18:26 | ||
| so something on the second line like: | |||
| Infinoid | cool. I'll try it out tonight and merge it if it looks good | ||
| bubaflub | TT #1513: trac.parrot.org/parrot/ticket/1513 | ||
| dukeleto | +1 to making the TT link on the next line | ||
| Infinoid | yeah. I think I may need some special : handling, but it'll look close to that | ||
| dukeleto | Infinoid++ bubaflub++ | ||
| Infinoid | should be trivial :) | ||
|
18:27
iblechbot joined
|
|||
| chromatic | whiteknight, are the inheritance failures obvious from the failing tests? | 18:36 | |
| whiteknight | chromatic: I think all the remaining failures are inheritance failures | 18:37 | |
| the only one I think might be a different issue is the failure in t/pmc/objects.t | |||
| 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 | ||
| dalek | rrot: r44987 | whiteknight++ | branches/tt389_fix/t/pmc/resizablepmcarray.t: [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 |
||
| whiteknight | or, the mechanism to find the vtable override isn't searching in the proxies correctly | ||
| chromatic | Oh, right. | 18:39 | |
| That might be a case where :vtable and :method interact badly. | |||
| whiteknight | likely, yes | ||
| chromatic | Did you fix something like that in trunk or on the branch? | ||
| dukeleto | mj41++ # Code coverage on tapir2.ro.vutbr.cz now has GMP support | ||
| whiteknight | in trunk. I fixed it so :anon :vtable was entered into the namespace correctly | ||
| this one isn't :anon, but I'm sure a similar mechanism is at play. | 18:40 | ||
| chromatic | Right. | 18:41 | |
| ash_ | for nci, is parrot planning on using libffi? | ||
| whiteknight | brb. VisualStudio demands the computer restart for an update | ||
| 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*? | ||
| chromatic | I don't know that. | ||
| plobsing | althought if we were to choose 1, can't complain about libffi | ||
| chromatic | The cost of supporting multiple might be significant. | 18:44 | |
| See also: runcores, JITs, garbage collectors, PIR compilers, STRING subsystems.... | |||
| ash_ | i just heard that libffi doesn't work with win32, (well it does work with cygwin and ming) so i was wondering | ||
| plobsing | ash_: url? | 18:45 | |
| lucian | ash_: i don't think that's true. for example python's ctypes works just fine on windows | ||
| chromatic | If that's true, that's a point against it (or a point for us to encourage it to work well with Windows). | ||
| ash_ | 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 | |
| i could be wrong though | |||
| 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 | ||
| 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 | ||
| and code.google.com/p/libffi-msvc/ | 18:49 | ||
| dukeleto | +Inf to libffi | ||
| plobsing | since we're talking about nci, has anyone had a look at my proposal for pdd16? | 18:51 | |
| bubaflub | libffi on msvc: sourceware.org/ml/libffi-discuss/20...00049.html | ||
| sent earlier this month from the maintainer of that google code project; seems like things are working | |||
| lucian | bubaflub: so it really is a non-issue | 18:52 | |
| bubaflub | lucian: the follow up emails said they wanted to merge it in | ||
| 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." | ||
| is in the follow up email; | |||
| 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:54 | ||
| though we should still investigate, i think it's premature to say that it *doesn't* work with MSVC | 18:55 | ||
| cotto_work | "It's also possible to build libffi on Windows platforms with | 18:58 | |
| Microsoft's Visual C++ compiler." from github.com/atgreen/libffi | |||
| smells like a winner | |||
| bubaflub | that's a bingo | 18:59 | |
|
19:02
whiteknight joined
19:07
eric_j joined
19:19
TiMBuS joined
|
|||
| lucian | allison: ping | 19:23 | |
|
19:23
AndyA joined
|
|||
| dalek | TT #895 closed by NotFound++: Towards automatic allocation and deallocation of PMC attributes | 19:36 | |
| TT #1493 closed by NotFound++: Avoid repeated STRING constans with the same value | |||
| 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
|
|||
| whiteknight | chromatic: I think I may have the tt389_fix issue figured out | 19:43 | |
| and it's much much easier than I expected | |||
|
19:44
eric_j joined
|
|||
| 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:44 | |
| chromatic | Ah, that sounds reasonable. | 19:46 | |
| 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 | ||
| chromatic | Right. | ||
| We'll probably be able to delete a lot of code too. | |||
| whiteknight | of course, it may create some bugs if anybody is relying on this lousyness | 19:48 | |
| ...and miniparrot segfaults. So, there's my answer | |||
| allison | lucian: pong | 19:49 | |
| lucian | allison: it seems i was somewhat wrong about parrot's objects described in PDD 15 | ||
| 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 | ||
| allison | lucian: excellent! | 19:51 | |
| purl | EGG-see-lent! | ||
| lucian | allison: the description makes them sound like java objects and not fitting everything-is-an-object languages at all | ||
| allison: but they expose their vtables, so it should be fine | |||
| 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 | ||
| allison | lucian: some are everything-is-an-object, some aren't | ||
| lucian: is it perl oriented? it was designed to be pretty generic | |||
| lucian | allison: it's less generic than it should be | 19:53 | |
| allison | (and the folks developing Perl say it's not perl oriented) | ||
| lucian | oh. then i probably don't know perl enough (which i don't) | ||
| NotFound | lucian: I don't see 'bless' in parrot ;) | ||
| allison | Rakudo is prototype-based, so using a different overlay on top of Parrot objects | ||
|
19:54
joeri joined
|
|||
| 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 | ||
| allison: in any case, it seems parrot's objects are a mix of high and low level objects | 19:55 | ||
| allison: i think i should just start trying to implement object and see how it goes | 19:56 | ||
| allison: what i don't understand is how interop will work with parrot's objects as they are now | 19:57 | ||
| allison | lucian: interop is via vtables | 19:59 | |
| at least "interop" in the sense of accessing attributes, calling methods, etc | |||
| take a look at docs/pdds/draft/pdd31_hll.pod for the broader sense of interop | 20:00 | ||
| TimToady | phone, I guess | ||
| allison | lucian: loading modules across languages, etc | ||
| TimToady: dialing | |||
|
20:00
cxreg joined
|
|||
| 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:00 | |
| 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? | ||
| whiteknight | that's what I'm thinking, but will require some rewriting | ||
| chromatic | lucian, are you familiar with message passing? | 20:02 | |
| lucian | chromatic: yes | ||
| whiteknight | chromatic: I'm heading home from work now. I'll tackle this more when I get home. Talk to you then | ||
| lucian | chromatic: so it's smalltalk-style? | ||
| chromatic | No, but I was going to explain by analogy. | 20:03 | |
| 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. | ||
| Except that "find a method" is also a method. | 20:05 | ||
| 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. | ||
| 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 | |
| Which we can't do. | |||
| lucian | Tene: then how are metaclasses implemented? | 20:11 | |
| allison: i wasn't sure how i could implement this gist.github.com/335672 | 20:13 | ||
|
20:24
bacek joined
|
|||
| cotto_work | bacek, what was that ping about? | 20:25 | |
| bacek | o hai | ||
| cotto_work | helllo | ||
| bacek | cotto, about your last commit into ops_pct. You changed number of parsed ops in test. | 20:26 | |
| cotto_work | That could have been an incorrect change. | 20:27 | |
| 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:28 | ||
| 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. | ||
| bacek | :) | ||
| cotto_work | That also makes me suspicious. | ||
| allison | lucian: wasn't sure you could implement which? Do you mean "A.print2 = f"? | 20:32 | |
| lucian | allison: that and print3 | ||
| 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:33 | |
| lucian | allison: in fact, that's how class definition works in the first place, the rest is sugar | 20:35 | |
| 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 | ||
| cotto_work | unfortunately the way to verify it is to make ops2c process those files and see how many ops it generates | 20:41 | |
| btw, initial (if rough) self-hosting is accomplished by the bootstrap-ops makefile target. That item can be taken off the TODO list. | 20:42 | ||
| 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/ . | ||
| allison | lucian: self-hosting as in written in python? | ||
| 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... | ||
| allison | lucian: or self-hosting as in not using NQP? | 20:44 | |
| lucian | allison: for example, all objects should be written in pynie | ||
| cotto_work | bacek, could you update the TODO with that? I'm not sure how soon I'll have tuits. | ||
| lucian | allison: i can't see how nqp could be avoided for the compiler | ||
| Austin | *seeing arguments = seeing errors | ||
| allison | lucian: if we went that route, we should just use PyPy | ||
| 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 | ||
| lucian: aye, I'd like to use Pynie as an excuse for more advanced compiler tools | |||
| lucian | allison: with object implemented, dict and the like should be doable in python | ||
|
20:45
brooksbp_ joined
|
|||
| 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 | ||
| allison | lucian: I suspect they'll be slow, though | 20:46 | |
| lucian: they're faster as low-level objects | |||
| lucian | allison: why? they'd inherit parrot's Hash and ResizablePMCArray | 20:47 | |
| allison: something like this gist.github.com/335708 | 20:48 | ||
| allison | lucian: sure, but right now they're written in PIR, as a thin overlay | ||
| lucian | allison: would compiled python be much slower than pir? | 20:49 | |
| allison | lucian: at the moment, yes, because parsing python is slow | ||
| lucian: the parser is slow in general | |||
| lucian | allison: parser aside, why would it be slow? | ||
| allison | lucian: down the road it probably won't make much difference | ||
| 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 | ||
| allison | lucian: well, somewhere down the road try it out and benchmark the two | 20:51 | |
| 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 | ||
| 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 | |
| lucian: figured PIR was good for prototyping | |||
| 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 | ||
| lucian | allison: the PyPy folks have showed that extensively with micronumpy and other microbenchmarks | ||
| allison: btw, i've read the jit page, has anything been decided? | 20:58 | ||
| allison | lucian: it's been decided to try multiple toolkits and see which serves our needs best | 21:00 | |
| lucian: still leaning toward LLVM, especially with the work the unladen-swallow team has put into it | |||
| lucian | allison: well, the u-s guys have run into a lot of issues | ||
| allison: and there's no chance of u-s being anywhere near as fast as PyPy for example | |||
| allison | lucian: they've resolved most of their issues | 21:01 | |
| chromatic | LLVM still has to address memory usage. | 21:02 | |
| allison | lucian: and the speed could be considerably enhanced by caching the compiled code | ||
| lucian | allison: most of their, but not llvm's. it's still really bad at patching code | ||
| allison | lucian: yup, so you can see why we're not committing to it | ||
| lucian: the other options are not much better | |||
| 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 | |
| using llvm | |||
| NotFound | Talking about python and speed? Someone wants to revenge the pie in the face? X-) | ||
| lucian | NotFound: what pie? | ||
| purl | i heard pie was true. or www.piecouncil.org/national.htm or london.randomness.org.uk/wiki.cgi?a..._value=Pie or www.austinthirdgen.org/upload/piechart.jpg or www.weebls-stuff.com/wab/ or flickr.com/photos/cowfish/3137913195/ or dilbert.com/fast/2009-03-07/ or position-independent executable (like PIC libraries but more so) | ||
| lucian | purl: bad bot | ||
| purl chuckles evilly | |||
| allison | lucian: part of it is, state-of-the-art JIT techniques tend to focus on static languages | ||
| LLVM, for example makes all sorts of bad assumptions about whether code will be modified later | |||
| 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 | ||
| atrodo | allison> I'm curious how so | ||
| allison | lucian: yes, implementing a JIT once in Parrot is a potential advantage to a number of languages | ||
| lucian: ha-ha :) | |||
| lucian | allison: i'm semi-serious about that :) | 21:06 | |
| allison: it would be fast, but it's a LOT of work | |||
| allison | lucian: seriously, though, implementing RPython in Parrot is a good goal | 21:07 | |
| lucian | allison: no, parrot in RPython :) | ||
| allison: actually, a RPython variation might be useful as a NQP-for-python | |||
| allison | lucian: I'm entirely confident we can do better than PyPy in Parrot | 21:08 | |
| lucian | allison: performance-wise? | ||
| allison | lucian: yup | 21:09 | |
| lucian | allison: i'm still skeptical. PyPy does loads of very interesting and hard things | ||
| allison: but having that mid-level abstraction layer might help | |||
| allison | lucian: aye, those are interesting and hard things anyone can do, even Parrot | 21:10 | |
| lucian: but, that's down the road | 21:11 | ||
| lucian: first, full feature support | |||
| (in the language implementations) | 21:12 | ||
| lucian | allison: i know, i was just saying they have a head start] | ||
| allison | lucian: in some areas, yeah | ||
| lucian: they've done great work | |||
| 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 | ||
| lucian | allison: yes, i can't wait till we can run py.py on pynie to stress-test it | ||
|
21:13
Whiteknight joined
|
|||
| 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 | ||
| lucian: kind of "been there, done that" | |||
| 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 | ||
| lucian | allison: but that would be a double interpreter | ||
| allison | lucian: and keeping the individual language implementations as thin as possible on top of that middle-layer | ||
| lucian | allison: yes, but i still think as much of the core types should be python :) | ||
| 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? | ||
| 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. | ||
| 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 | ||
| eric_j | hmm | ||
| allison | eric_j: so, we'll have to make extensions to that type | ||
| chromatic | I thought bacek fixed that. | ||
| 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 | ||
| allison | chromatic: we talked about it, not sure that it happened | ||
| 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. | ||
| hash = .Hash_key_type_int | |||
| or .Hash_key_type_PMC | 21:22 | ||
| allison | bacek: dicts have mixed string and integer keys | ||
| bacek: and preserve the types of those keys | |||
| eric_j | in python, dicts can have any hashable key | ||
| bacek | Then use PMC with autoboxing/unboxing | 21:23 | |
| allison | bacek: aye, we can do that | ||
| bacek | Actually, Hash will autobox/unbox keys automatically. | 21:24 | |
| 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 | ||
| allison | bacek: is there a way to set that once for the subclass? | ||
| bacek | allison, no afair. | ||
| 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 | ||
| bacek | eric_j, $P0 = .Hash_key_type_PMC | ||
| lucian | eric_j: ignore me, i assumed something wrong | ||
| 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 | ||
| bacek | eric_j, $P0."set_key_type"(.Hash_key_type_int) should work as well | ||
| allison | bacek: I can do it in the dictmaker function, which is what instantiates most dicts | ||
| eric_j | thanks guys | ||
| bacek | allison, should work. Or override SubclassedHash.init to do it always. | 21:28 | |
| dalek | TT #1515 created by Austin_Hastings++: Duplicate named args cause fatal error in subs | 21:31 | |
| allison | bacek: those constants are defined in 2.0, or at least aren't installed | 21:34 | |
| bacek: *aren't* | |||
| bacek | allison, runtime/parrot/include/hash_key_type.pasm | 21:35 | |
| you have to manually include it. | |||
| allison | bacek: aye, the file doesn't exist in a 2.0 install | ||
| bacek | Ah, may be... | ||
| allison | bacek: (found it in the current trunk no problem) | ||
| 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 nopaste.snit.ch/19988 | ||
| 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? | ||
| purl | I'm not sure... but it doesn't sound like any kind of English I know. | ||
|
21:37
brooksbp joined
|
|||
| bacek | cotto_work, nope | 21:37 | |
| NotFound | allison: Winxed | 21:38 | |
| allison | NotFound: interesting language | 21:39 | |
| NotFound | allison: thanks | ||
| nopaste | "NotFound" at 213.96.228.50 pasted "Setting hash key type in subclass init, pir generated by the winxed example" (52 lines) at nopaste.snit.ch/19989 | 21:40 | |
| lucian | NotFound: looks a bit like C#. not aesthetically nice, but interesting | 21:42 | |
| 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 | ||
| allison | bacek: that was it, hash_key_type.pasm wasn't listed in MANIFEST.generated, so wasn't being installed | 21:44 | |
| lucian: we love all kinds of languages here :) | 21:45 | ||
| bacek | allison, "installed parrot" is totally unknown beast to me. | ||
| lucian | allison: i'm not saying it's not nice, it just looks bad :) | ||
| allison: since most people are used to C-like syntax, it's a necessary evil | 21:46 | ||
| 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. | ||
| lucian | NotFound: heh. i'm half-used to it myself. but i think syntax matters, and C syntax is a bad idea | 21:48 | |
| NotFound | lucian: so bad that it dominates during decades ;) | 21:49 | |
| allison | lucian: all syntacies have a place and a use | ||
| lucian | NotFound: yes, it's unfortunate | ||
| allison: that doesn't mean they encourage good practice or they're readable | 21:50 | ||
|
21:51
kjeldahl joined
|
|||
| 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., | ||
| 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? | ||
| 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 | ||
| dalek | kudo: fed4687 | jonathan++ | docs/ROADMAP: Tweak the ROADMAP with the results of The Meeting. |
||
| allison | lucian: the polyglot programmer is on the rise | 21:54 | |
| lucian | allison: that doesn't make C syntax an more helpful | ||
| dalek | rrot: r44988 | allison++ | trunk/MANIFEST.generated: [install] Adding the hash-key type definitions to the manifest of |
||
| lucian | allison: it's terse where it shouldn't be, it has too much noise | ||
| 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, | ||
| allison | lucian: I have spent far more time writing C than high-level languages the past 6 years, and it's grown on me | ||
| lucian: for specific kinds of tasks | |||
| lucian: though, I wouldn't recommend it as someone's first language | 21:56 | ||
| NotFound | Yeah, Z80 assembler is much better X-) | ||
| lucian | allison: almost everything about C is nice except part of the syntax | ||
| allison | lucian: maybe an acquired taste, like black coffee, or 99% dark chocolate | ||
| lucian | allison: for example, ; at the end of lines. there's no real reason for that | 21:57 | |
| NotFound | Mmmm... coffee, good idea. | ||
| lucian | NotFound: mmm, dark chocolate | ||
| allison | lucian: <shrug> character-delimited statements are easier to parse than newline delimited statements | 21:58 | |
| lucian: and for a low-level language, I'm okay with some syntax decisions made for ease of implementation rather than ease of use | |||
| lucian | allison: parsing isn't really an issue. and i don't think ease of implementation should ever dictate syntax | 21:59 | |
| allison: perhaps at the time it made sense. but nowadays, it doesn't, at all | 22:00 | ||
|
22:00
he_ joined
|
|||
| NotFound | I don't think that ending a sentence without puntuaction is more readable. Books use it from hundred of years ago. | 22:00 | |
| allison | lucian: PIR, for example has no statement terminators, but it's also so dead simple that there are no compound statements | 22:01 | |
| 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 | ||
| allison | lucian: the worst use of closing semicolons I've ever found is Matlab | ||
| lucian goes to read about matlab | |||
| allison | lucian: where they're optional, but determine whether the result of the statement is automatically printed | ||
| lucian: language design is all about balancing | 22:03 | ||
| lucian | allison: oh. that's bad | ||
| 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 | ||
| allison | lucian: certainly annoying to someone who's working primarily in C and Python lately :) | ||
| lucian: I should send you a book chapter I once wrote about language design | |||
| lucian: it's an absolutely fascinating topic | 22:05 | ||
| lucian | allison: indeed | ||
| allison | lucian: it's like going from loving Rembrandt, to understanding the choices all painters make | ||
| (while still loving Rembrandt) | 22:06 | ||
| lucian | NotFound: true, but in code you delimit statements with line breaks anyway, for style | ||
| allison: i do like several languages, while preferring python | |||
|
22:07
cotto_work joined
|
|||
| 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 | ||
| 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 | ||
| s/line/statement/ | |||
| NotFound | lucian: yes, and I don't want to make to others what I don't want others make on me. | ||
| lucian: oh... \\ for line continuation... just like C preprocessor? ;) | |||
| lucian | NotFound: a bit, i guess | 22:10 | |
| 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:12 | |
| lucian | NotFound: true. very nice | 22:13 | |
| NotFound: not just syntax wars, but it's DSLs done right | |||
| 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 ;) | ||
| lucian | NotFound: you have have read me right, i meant that you get real DSLs on parrot, not semi-DSLs as in ruby | ||
| s/you have read me right/you haven't read me right/ | 22:15 | ||
| 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:16 | |
|
22:17
cotto_work joined
|
|||
| 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. | ||
| lucian | NotFound: yes, that's what i meant | ||
| NotFound | I hope Winxed is a good example of the later. | 22:18 | |
| lucian | NotFound: i sure looks that way :) | 22:19 | |
| s/i/it/ | 22:20 | ||
| NotFound | At least is useful to write parrot features examples a lot shorter than in pir. | ||
| And with better runability than seudocode :D | 22:21 | ||
|
22:22
GodFather joined
|
|||
| 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:40 | |
| lucian | NotFound: a language that targets parrot's low level types is indeed useful | 22:41 | |
| NotFound: i believe there was another such language, Close | |||
| NotFound | lucian: yes, but looks like there is not much activity in it these last months. | ||
| allison | eric_j: I'll get it built-in to pynie soon | 22:47 | |
| eric_j: have the patch, but it won't work until Parrot 2.3 | 22:48 | ||
| allison afk | |||
| eric_j | allison: no problem, i'm working from subversion. if you have an unstable branch in subversion i'll switch to that | 22:53 | |
|
22:54
tetragon joined
|
|||
| dalek | rrot: r44989 | NotFound++ | trunk/CREDITS: fix my entries in CREDITS |
22:59 | |
| japhb | plobsing, just sent a review of your NCI PDD patch to the list. | 23:06 | |
| dukeleto | japhb: nice writeup | 23:17 | |
| japhb | dukeleto, thanks! | ||
| chromatic | dukeleto, could we have a configure step for configure build directory? | 23:30 | |
| dukeleto | chromatic: that sounds nice | 23:32 | |
| chromatic: how would one go about doing that? | 23:33 | ||
| chromatic | I'd ask kid51. | ||
| dukeleto | chromatic: ok. i will make a TT | ||
| chromatic: that very well may help with the RTEMS port as well | 23:34 | ||
| chromatic | I think so. | 23:35 | |
|
23:35
cotto_work joined
|
|||
| Whiteknight | chromatic: I'm getting pretty close on tt389_fi | 23:55 | |
| the new code is much smaller, probably faster | 23:56 | ||
| chromatic | Good, I should have some spare time late tonight and tomorrow. | 23:58 | |
| dalek | TT #1516 created by dukeleto++: Allow a build directory to be specificed to Configure.pl | 23:59 | |
|
23:59
patspam joined
|
|||