|
Parrot 1.2.0 released | parrot.org/ | 303 RTs left | Weekly Priority: Profiling Set by moderator on 28 May 2009. |
|||
|
00:07
snarkyboojum joined
|
|||
| Austin_Hastings | Okay, I'm reading this paper: www.soi.city.ac.uk/~ross/papers/FingerTree.pdf on Finger Trees, and my head just exploded. | 00:10 | |
| And FWIW, finger trees are not O(1). They are O(1) amortized for deque operations. (The perl list ops). For other operations, they have to be annotated (an O(n) operation) before becoming O(log n) objects. | 00:20 | ||
| Now I am a fraction more knowledgeable. Thanks, dan + darbelo. | 00:21 | ||
|
00:24
bacek_ joined
|
|||
| Austin_Hastings | rehai, bacek | 00:29 | |
| bacek_ | rehai Austin_Hastings | 00:30 | |
| Austin_Hastings | FYI: Okay, I'm reading this paper: www.soi.city.ac.uk/~ross/papers/FingerTree.pdf on Finger Trees, and my head just exploded. | 00:31 | |
| Now ur brane will hurts too | |||
| cotto | It feels like forever since I've looked at an actual academic paper. | 00:35 | |
| I look forward to the head 'splodage. | |||
| Austin_Hastings | Not long enough. I invested a lot of money in booze and drugs to get those brain cells killed off. | ||
| cotto | I don't look at them often because I get lost really quickly, but that's beside the point. | 00:36 | |
| ping gandi.net | 00:49 | ||
| purl | 10 packets transmitted, 10 received, 0% packet loss, time 9011ms, rtt min/avg/max/mdev = 115.286/115.300/115.319/0.012 ms | ||
| cotto | and yet I don't get to connect | 00:51 | |
| Hmmm. A lightning talk about pmc_pct and making Parrot more self-hosting might be interesting. | 00:57 | ||
|
01:05
snarkyboojum joined
|
|||
| Austin_Hastings | I just realized that class attributes are untyped. | 01:06 | |
| How lame. | |||
| dalek | rrot: r39398 | whiteknight++ | branches/io_rewiring/src/io/api.c: [io_rewiring] Convert most occurances of my lousy pseudoroles to using base_type checks with PCCINVOKE fallbacks. |
01:07 | |
| TT #738 created by grantbow++: ICU download URL change in README | 01:21 | ||
| cotto | trac does not win at url preservation | 01:22 | |
|
01:52
preflex joined
01:55
kid51 joined
02:41
janus joined
04:30
Austin_Hastings left
04:42
tetragon joined
05:08
snarkyboojum joined
|
|||
| Infinoid | bacek_: eh, I think branch commits deserve full karma too | 05:25 | |
| I wouldn't mind using the #perl6 pugsbot format, except that some folks here do use the review links (and I want to encourage that) | 05:27 | ||
| cotto | I use and like them | 05:40 | |
|
06:06
eternaleye joined
06:16
viklund joined
|
|||
| dalek | rrot: r39399 | fperrad++ | trunk (2 files): [doc] update ICU download URL |
06:23 | |
| TT #738 closed by fperrad++: ICU download URL change in README | 06:25 | ||
| rrot: r39400 | cotto++ | branches/pmc_pct/compilers/vtdumper/vtdumper.pir: [vtdumper] rename frozen vtable dump to vtable.frozen to avoid conflicts with the perl-generated vtable.dump |
07:06 | ||
|
07:11
barney joined
|
|||
| cotto | All this self-hosting is going to make for some interesting makefile dependencies. | 07:11 | |
| Are frozen PMCs cross-platform? | |||
| i.e. if I checked in a frozen past, would other platforms be able to use it? | 07:13 | ||
| cotto goes off to investigate | 07:14 | ||
| cotto hopes someone will pipe up before he has to dig into the freeze/thaw code too much | 07:16 | ||
| cotto hears crickets | |||
| Hmm. I'm not confident that freeze/thaw will work. It doesn't appear to be very cross-platform. | 07:21 | ||
| can someone on non-x86 (x64 would be fine) checkout the pmc_pct branch, build it, compile vtable.tbl and post the md5sum of the resulting vtable.tbl? | 07:34 | ||
| s/dump/frozen/ | 07:35 | ||
| Once it's built, you just need to run ./parrot compilers/vtdumper/vtdumper.pbc src/vtable.tbl | |||
| and post the md5sum of the vtable.frozen, not vtable.tbl | 07:36 | ||
| smolder? | 07:37 | ||
| purl | smolder is probably sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or smolder.plusthree.com/app/public_pr..._reports/8 | ||
|
07:46
masak joined
|
|||
| dalek | rrot: r39401 | cotto++ | trunk/src/pmc_freeze.c: [freeze] minor freeze code readability improvement |
08:02 | |
|
08:23
AndyA joined,
donaldh joined
08:30
riffraff joined
08:42
bacek joined
08:44
krunen joined
08:47
snarkyboojum joined
09:04
cognominal joined
09:18
bacek joined,
viklund_ joined
|
|||
| cotto | bacek, do you know if a PMC's frozen representation is portable? | 09:21 | |
| bacek | cotto: it's not. | 09:22 | |
| cotto | ok. in that case the vtable dump will probably have to use json | ||
| bacek | we don't have anything "portable"... Even PBC isn't portable | ||
| +1 for JSON | 09:23 | ||
| cotto | Good. I just finished writing a json dumper. | ||
|
09:24
pjcj joined
|
|||
| cotto | karma json | 09:24 | |
| purl | json has karma of 29 | ||
| bacek | btw, why do you need portable vtable dump? | 09:28 | |
| cotto | chicken and egg problem: | ||
| a vtable dump is needed to build Parrot, but Parrot is needed to build the vtable dumper. | 09:29 | ||
| bacek | but for parsing json dump you still need parrot | ||
| cotto | Perhaps I should be sleeping instead of thinking through build dependencies. | 09:30 | |
| bacek | and there is no conceptual difference between parsing vtable.tbl and vtable.json | ||
| cotto needs to think through what the eventual build process will look like | 09:31 | ||
| dalek | rrot: r39402 | cotto++ | branches/pmc_pct/compilers/vtdumper/vtdumper.pir: [vtdumper] use JSON as the dump format since frozen PMCs aren't portable (yet?) |
||
| bacek | cotto: sleep on it :) | ||
| cotto | yes | ||
| good night | |||
| bacek | good night | 09:32 | |
|
10:10
eiro joined
10:13
eiro joined
10:28
snarkyboojum joined
11:04
HG` joined
11:20
donaldh joined
11:45
burmas joined
11:50
snarkyboojum joined
|
|||
| nopaste | "bacek" at 114.73.179.59 pasted "Victory! (Almost...) Emitting real PBC from within Parrot in NQP." (168 lines) at nopaste.snit.ch/16791 | 11:53 | |
| bacek | Hooray! | ||
| Infinoid: what about implementing PIR compiler in PCT? :) | |||
|
12:11
rdice joined
|
|||
| Infinoid | bacek: What about it? :) | 12:27 | |
| bacek | It's possible now :) | 12:28 | |
| Infinoid | awesome. bacek++ | ||
| bacek | Check nopaste | ||
| nopaste.snit.ch/16791 | |||
| Infinoid | I can check it tonight; have to leave soon | ||
| This week has been crazy, sorry. I will have time this weekend | |||
| bacek | No worries. | 12:29 | |
|
12:30
bkuhn joined
|
|||
| bacek | Infinoid: did you found new $dayjob? | 12:30 | |
|
12:52
skids joined
13:02
rdice joined,
Whiteknight joined
|
|||
| dalek | rrot: r39403 | bacek++ | branches/pmc_i_ops (4 files): Merge branch 'master' into pmc_i_ops |
13:06 | |
| rrot: r39404 | bacek++ | branches/pmc_i_ops/src/pmc/bigint.pmc: [pmc] Reimplement most of BigInt math ops in terms of i_ops |
|||
| rrot: r39405 | bacek++ | branches/pmc_i_ops/src/pmc/bigint.pmc: [pmc] BigInt bitwise ops use i_ops now. |
|||
|
13:22
whoppix joined
13:31
AndyA joined
13:35
gryphon joined
|
|||
| dalek | kudo: 056847f | pmichaud++ | src/classes/Grammar.pir: Add .parse to base Perl6::Grammar and other non-Rakudo grammars. Fixes #66270. we can inherit that one and omit this one. |
13:39 | |
| rrot: r39406 | bacek++ | branches/pmc_i_ops/src/pmc/scalar.pmc: [pmc] Scalar ops reimplemented in terms of i_ops. |
13:46 | ||
|
13:57
gaz joined
13:58
ruoso joined
14:09
snarkyboojum joined
14:14
davidfetter joined
14:15
Andy joined
|
|||
| dalek | TT #739 created by gerd++: path of installed config.fpmc file on a 64bit system | 14:27 | |
| kudo: 636a2b6 | jnthn++ | src/parser/actions.pm: Fix one half of what is reported in RT#65128 - our T1 T2 sub f() { ... } now gives a compile time error like STD. |
14:31 | ||
| kudo: 7a40779 | jnthn++ | src/setting/ (2 files): Fix up various return type constraints in teh built-ins. |
|||
| kudo: 8c09b53 | jnthn++ | src/parser/actions.pm: Refactor setting of return types to eliminate duplicate code, and implement checking of implicitly returned values for the my T sub foo() { ... } and sub foo(--> T) { ... } cases. |
|||
| kudo: a89161f | jnthn++ | : Merge branch 'master' of git@github.com:rakudo/rakudo |
|||
|
15:07
iblechbot joined
15:20
donaldh joined
|
|||
| dalek | kudo: fb2fd43 | jnthn++ | src/parser/actions.pm: Make sure we type check implicit return values for of and returns also. Completely resolves RT#65128. |
15:24 | |
|
15:57
Theory joined
16:00
Austin_Hastings joined
|
|||
| Austin_Hastings | w00t! Not every namespace contains code. | 16:01 | |
|
16:19
darbelo joined
16:25
gryphon_ joined
|
|||
| darbelo | Is there a way to make tokens case-insensitive in PCT grammars? | 16:30 | |
| Whiteknight | I don't know if PCT supports it, but normal P6 grammars should have the :i flag | 16:32 | |
| what kinds of case-insensitivity do you need, just the first letter? | |||
|
16:33
Psyche^ joined
|
|||
| particle | :i is supported by pge | 16:33 | |
| darbelo | I have "token context_field { [ 'maxexponent' | 'minexponent' ] }" | ||
| In want 'minExponent' to match too. | 16:34 | ||
| particle | token foo { :i 'm' [ 'in' | 'ax' ] 'exponent' } # just for fun :) | ||
| Austin_Hastings | token m{<[Mm]>} token e{<[Ee]>} token foo { <.m> in <.e> xponent } | 16:36 | |
| darbelo | He, I trimmed the example a bit, ":i" is what I wanted. | ||
| Austin_Hastings | :) | 16:37 | |
| Does anyone know to what extend the wrong reporting of pir line numbers is a "known bug" versus something else? | |||
| darbelo | Now you've told them, they know the bug is there ;) | 16:38 | |
| Austin_Hastings | That's what I'm afraid of. | 16:39 | |
| darbelo | I would search for a TT. | ||
| Whiteknight | it's so hard to keep up with the list of supported features because development happens so quickly | ||
| darbelo | Whiteknight: There's a simple solution to that. But i doubt you'd like it. | 16:41 | |
| Whiteknight | and what's that? | 16:42 | |
| purl | that is probably about the level that you were asking for | ||
| Austin_Hastings | Why not? It's working for me. | ||
| darbelo | Whiteknight: develop slower :) | ||
| Austin_Hastings | Oh. | 16:43 | |
| My approach was just to ignore what else is going on. | |||
| They're doing it wrong, anyways. | |||
| Whiteknight | darbelo: Oh, I thought you were going to say that I needed to pay more freaking attention | 16:44 | |
| darbelo | "Paying attention" is not on the 'easy' category of my book :) | 16:45 | |
| NotFound | I think there is a RT, not a TT | 16:46 | |
| The pir line numbers thing | |||
| Austin_Hastings | NotFound: Really? | 16:47 | |
| How do I search rt's? | |||
| NotFound | Not sure, let me check... | ||
|
16:50
clinton joined
|
|||
| Austin_Hastings | Found this RT page. I'll search here. rt.perl.org/rt3/Public/Search/Simpl...talled%27) | 16:50 | |
| NotFound | rt.perl.org/rt3/Public/Bug/Display.html?id=38594 | 16:51 | |
| Uh, no, this is solved | |||
| This one: rt.perl.org/rt3/Public/Bug/Display.html?id=40204 | |||
|
16:52
clinton left
|
|||
| Austin_Hastings | Not quite the same problem I'm having, I think. But it's good to know that life sucks for other people, too. | 16:54 | |
| NotFound | Austin_Hastings: feel free to add a comment to that ticket, or to create one in TT | 16:59 | |
| Austin_Hastings | Yeah, I'm a little leery. There's always the chance that the error was "somewhat right", since the bogus number in this case points to a die inside an exception handler. Maybe the line numbers are right and the exception handling stack is wrong. :( I've snapshotted the code, so I think I can post an overbloated test case if need be. | 17:01 | |
| And what does "positional inside named args" mean? | 17:07 | ||
| dalek | TT #740 created by doughera++: [PATCH] PLATFORMS update for 1.3 release for Solaris 8/SPARC | 17:27 | |
|
17:55
PacoLinux joined
|
|||
| dalek | TT #741 created by Austin_Hastings++: Line numbers in backtraces are substantially wrong. | 18:04 | |
|
18:07
PacoLinux joined
|
|||
| cotto | Austin_Hastings++ for filing that | 18:10 | |
|
18:12
sekimura joined
18:25
Austin_Hastings left
18:37
Theory joined
|
|||
| NotFound | Someone here reads german Linux Magazine ? | 18:39 | |
|
18:53
ruoso joined
18:54
rdice joined
18:57
masak joined,
burmas joined
19:06
burmas joined
19:21
PacoLinux joined
19:24
particle joined
|
|||
| cotto | L1? | 19:32 | |
| purl | L1 is a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or irclog.perlgeek.de/parrot/2009-04-21#i_1083550 or rt.perl.org/rt3/Ticket/Display.html...txn-471982 | ||
| nopaste | "tene" at 97.117.57.131 pasted "example of importing in PIR for japhb++" (8 lines) at nopaste.snit.ch/16793 | 20:37 | |
| dalek | rrot: r39407 | tene++ | trunk/runtime/parrot/languages/parrot/parrot.pir: Add a utility method to the parrot compiler to load libraries into the local namespace |
20:45 | |
|
20:50
particle joined
20:58
Austin_Hastings joined
21:29
burmas joined
21:32
eternaleye joined
21:33
Whiteknight joined
21:45
mikehh joined
|
|||
| Coke fails to review | 21:46 | ||
|
21:46
particle left,
burmas joined
21:51
bacek joined
|
|||
| cotto | bacek, ping | 22:02 | |
|
22:16
snarkyboojum joined
|
|||
| bacek | cotto: pong | 22:24 | |
| cotto | I'd appreciate your comments on my post to parrot-dev about the build process | ||
| bacek | good morning | 22:25 | |
| purl | Here I am, brain the size of a planet, and all they say is 'Good Morning' | ||
| bacek | Just read it. Thinking in progress... | ||
|
22:32
rg1 joined
|
|||
| bacek | cotto: I think second approach is more sane | 22:34 | |
| and simpler | |||
| cotto | Can you think of anything that needs to be addressed or fleshed out better? | 22:35 | |
| bacek | not now. I didn't have my coffee yet... | 22:36 | |
| cotto | no rush. it's worth taking time to figure it out well | 22:37 | |
| Austin_Hastings | Umm, how about "why?" | ||
| bacek | Austin_Hastings: "why" what? | ||
| purl | "why" is yet unanswered. | ||
| Austin_Hastings | Why does the pmc compiler need to be parrot hosted? | ||
| cotto | Austin_Hastings, a couple reasons: | ||
| First, we're trying to get rid of perl5 as a build dependency. | 22:38 | ||
| Second, having a legitimate compiler will make it much easier to switch to L1 | |||
| Austin_Hastings | What's L1? | ||
| purl | L1 is probably a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or irclog.perlgeek.de/parrot/2009-04-21#i_1083550 or rt.perl.org/rt3/Ticket/Display.html...txn-471982 | ||
| Austin_Hastings | Ok. | 22:39 | |
| So again, why? There's already a working programming language at the bottom of the build stack: C | |||
| cotto | By using L1, we can generate either C, LLVM bytecode or something else. | 22:40 | |
| bacek | Austin_Hastings: think about JIT | ||
| Tene | Writing PMCs in terms of Parrot ops allows for JIT. | ||
| Austin_Hastings | That's not my question. My question is, why write another PMC compiler; (you say: remove perl5 from build stack, okay) and given that, why write it in something other than C? | 22:42 | |
| cotto | We've got some nice compiler tools. Why not use them? | 22:43 | |
| Austin_Hastings | Because your target environment doesn't have them, but you know it does have a C compiler? | ||
|
22:45
snarkyboojum joined
|
|||
| cotto | If you want to write one that's fine, but it's *much* easier to use Parrot | 22:46 | |
| 's tools, since we know we'll have them. | |||
| s/you/someone/ | |||
| Austin_Hastings | Speaking as someone who's trying to implement a language using parrot's tools now, I'm not sure I entirely agree with that statement. :-X | 22:47 | |
| cotto | There's a learning curve, but it's easier. ;) | 22:48 | |
|
22:48
kid51 joined
|
|||
| bacek | cotto: btw, after bootstrapping we can replace IMCC with PCT based PIR compiler :) | 22:48 | |
| cotto | and involves fewer segfaults | ||
| bacek, that'd be a pretty cool | 22:49 | ||
| although kj would be disappointed | |||
| bacek | why? | ||
|
22:49
eternaleye joined
|
|||
| bacek | We will use his pir compiler as base | 22:50 | |
| cotto | he's been working on pirc, which is (was?) meant to replace imcc as a from-scratch less crufty alternative | ||
| bacek | He also implemented PCT base PIR parser :) | ||
| s/base/based/ | |||
| So, we can merge two approaches - reimplement kj' pirc in NQP using kj's PIR grammar | 22:52 | ||
| ... | |||
| 3. Profit! | |||
| cotto | so we'd have two pir compilers? | 22:54 | |
| or we'd require a working parrot to bootstrap? | |||
|
22:56
tetragon joined
|
|||
| Tene | He hasn't been working on pirc in quite a while. | 22:57 | |
| bacek | imcc will be used to bootstrap only. | 22:58 | |
| PCT based PIR compiler for everything else | 22:59 | ||
| Tene | I started trying to work on pirc, but ran into some issues and los tmomentum. | 23:00 | |
| cotto | pirc does have the disadvantage of a very low bus number. | 23:01 | |
| dalek | TT #733 closed by jkeenan++: Branch cleanup: pdd30install_stage4 | 23:02 | |
| Tene | argh... I hate composing mails to parrot-dev | ||
| cotto | reply oddness? | ||
| Tene | anybody want to do it for me? | ||
| cotto | "Tene was going to say something." | 23:03 | |
| Tene | about segfaults! make sure to mention segfaults! | ||
| And GC! | |||
| cotto | The segfaults are causing GC. | ||
| How's that? | |||
|
23:05
Theory joined
|
|||
| kid51 | Good evening. | 23:05 | |
| If I could get some feedback on trac.parrot.org/parrot/ticket/266#comment:9, I could (re-)close that ticket. | |||
| Tene | GC is causing segfaults. | 23:06 | |
| Austin_Hastings | Tene, aside from parrot-dev, who cares about this? | ||
| Tene | kid51: I can confirm. | ||
| Austin_Hastings | Pretend you're leaving them a message on here. | ||
| dalek | rrot: r39408 | chromatic++ | trunk/src/embed.c: [src] Tidied code; no functional changes. |
23:07 | |
| rrot: r39409 | chromatic++ | trunk/src/gc/alloc_register.c: [GC] Added code to null out array elements when free()ing contexts from the wonder if there's a potential double free problem here. As it is, paranoia rules. |
|||
| rrot: r39410 | chromatic++ | trunk/src/packfile.c: [src] Freed PackFile members that might get overlooked. |
|||
| rrot: r39411 | chromatic++ | trunk/src/pmc/eventhandler.pmc: [PMC] Hoisted a SUPER() call in EventHandler's mark entry into an if block |
|||
| Tene | Mostly, I'm hoping chromatic will swoop in from the skies and fix it. | ||
| ... that's a lot of GC-related commits from chromatic. | |||
| o.O | |||
| Tene updates parrot | |||
| Austin_Hastings | Perhaps he has... | ||
| dalek | rrot: r39412 | chromatic++ | trunk/src (3 files): [src] Tidied code; no functional changes. |
23:11 | |
| Tene | Nope, it still breaks. | 23:13 | |
| cotto | bacek, is the idea about using imcc only to bootstrap and using the PCT-based PIR compiler for everything else yours? | 23:14 | |
| bacek | cotto: ahm. May be mine. But it is pretty obvious idea | 23:15 | |
|
23:16
chromatic joined
|
|||
| darbelo | bacek: You mean maintaning to separate compilers or turn IMCC into a 'Not Qite PIR" of sorts? | 23:16 | |
| bacek | darbelo: actually turn pirc to nqp. imcc is awful... | 23:17 | |
|
23:17
skids joined
|
|||
| darbelo | s/IMCC/"The one written in c"/ | 23:18 | |
| cotto | karma imcc | 23:19 | |
| purl | imcc has karma of -1 | ||
| darbelo | karma pirc | ||
| purl | pirc has neutral karma | ||
| darbelo | That's all the evidence I need of pirc's superiority. QED | 23:20 | |
| dalek | rrot: r39413 | chromatic++ | trunk (4 files): [misc] Fixed references to runcore command-line option (TT #639, Klaus). |
23:21 | |
| bacek | darbelo: just check the code :) | ||
| chromatic | I wouldn't use IMCC or a C-based compiler to bootstrap. | ||
| We could distribute generated files, as noted, or even cross-platform PBCs if necessary. | 23:22 | ||
| dalek | TT #639 closed by chromatic++: Usage information for command line options | ||
| bacek | chromatic: our pbc isn't very stable. But I prefer to have single PCT based compiler too | 23:23 | |
| chromatic | When Allison and I last discussed this, she seemed comfortable checking in generated files as a fallback. | 23:24 | |
| bacek | "generated pbc" and "generated C" are slightly different | 23:25 | |
| But... We can generate C from PIR :) | |||
| Tene | chromatic: I'm getting a segfault somewhere in the GC right now... I've been having trouble tracking it down. Think you'll have a chance to look at it if I pos tto parrot-dev? | ||
| chromatic | We have to generate C for now. | 23:26 | |
| Tene, I'm working on TT #730 right now, but I can look at yours next. | |||
| Tene | chromatic: you want me to send to parrot-dev, or where? | 23:29 | |
| cotto | So if we use a PCT-based pir compiler without a C-based compiler too bootstrap, would the parrot binary be just a pbc interpreter? | 23:30 | |
| s/too/to/ | |||
| chromatic | If you have a test case, nopaste it and if I can't get to it soon, parrot-dev is fine. | ||
| cotto, it'll also need all of the backing libraries in src/ | |||
| cotto | right, but nothing about compiling will be built-in | 23:31 | |
| that raises the importance of portable pbc | 23:32 | ||
| chromatic | I don't follow. | ||
| Oh. I see what you're saying. | 23:33 | ||
| I don't think we can get rid of the C code to implement ops and PMCs until we have working L1. | |||
| Until then the Parrot binary won't be just a PBC interpreter. | |||
| bacek | we can't checkin generated PBCs into svn because thay are not very portable | ||
| chromatic | Right. | 23:34 | |
| bacek | chromatic: it's not about ops, it's about PIR... | ||
| implementation of ops and pmcs in terms of L1 is different task | 23:35 | ||
|
23:35
Limbic_Region joined
|
|||
| nopaste | "tene" at 97.117.57.131 pasted "GC segfault with steme and rakudo for chromatic++" (101 lines) at nopaste.snit.ch/16796 | 23:35 | |
| Tene | chromatic: is that enough of a test case for you? | ||
| chromatic | One sec. | 23:36 | |
| Does anyone find this code sane? | |||
| $P1.unicode:"foo\\x{b1}"() | |||
| Tene | Is that "Do you know if this works with the current imcc?" or "Does this sound sane conceptually?" ? | 23:37 | |
| chromatic | The latter, because I can change the answer to the former depending on answers to the latter. | 23:38 | |
| Infinoid | chromatic: How would you feel about reducing the INITIAL_BUCKETS #define from 16 to 4? It causes a significant improvement in perl6 -e 'my $i = 0; while ( $i < 1000000) { $i++ }' and seems to have either positive or no effect on every other benchmark I can find. | ||
| Tene | It looks fine to me. | ||
| chromatic | Infinoid, no argument here. | ||
| cotto | +1 to the unicode method call as long as we don't end up with a lot of code that looks like that | 23:41 | |
| chromatic | Okay, that's three votes for. I'll make it work. | ||
| dalek | rrot: r39414 | Infinoid++ | trunk/src/hash.c: [core] Tweak initial hash buckets (from 16 to 4). |
23:44 | |
| rrot: r39415 | Infinoid++ | trunk/PLATFORMS: [PLATFORMS] Apply patch from doughera++ in TT #740, to remove sol8-sparc-gcc from PLATFORMS. |
|||
| rrot: r39416 | jkeenan++ | trunk/t/compilers/imcc/syn/file.t: Delete DIR => cwd() key-value pair from one instance of create_tempfile(), in hope that this clears up a testing problem on Cygwin. |
|||
| TT #740 closed by Infinoid++: [PATCH] PLATFORMS update for 1.3 release for Solaris 8/SPARC | 23:45 | ||
| Infinoid | flight & | 23:46 | |
| dalek | TT #742 created by jkeenan++: Parrot::Test::Util::create_tempfile() cannot handle DIR option on Cygwin | 23:49 | |
| japhb | I cannot manage to subscribe myself to parrot-dev ... any mail admins around? | 23:51 | |
| kid51 | japhb: I am not a mail admin ... but what is the specific problem? | 23:53 | |
| japhb | I never get the subscribe confirmation email ... even though I'm using the same address that I subscribe to all the perl6-* lists, so it's not like it's failing across the board. | 23:55 | |
| particle1 | see you again soon, infinoid.... | ||
| particle | finally, no more of that - suffix. | ||
| kid51 | japhb: Hmm, yeah, maybe there's a mail problem. FWIW, if you prefer a news interface, you can subscribe to gmane.comp.compilers.parrot.devel at news.gmane.org. | 23:58 | |