|
Parrot 2.6.0 | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | fix 'make html' (talk to Coke), merge gc_* branches, fix/replace/optimize hashing Set by moderator on 3 August 2010. |
|||
| kid51 | In the other TT, I want to do refactoring on headerizer.pl. But that's second in the queue. | 00:00 | |
| sorear: Melvin Smith was a Parrot contributor back in ancient times, like 2002. Somehow his personal copyright notice got stuck on many files in IMCC -- which poses licensing problems. Cf. trac.parrot.org/parrot/ticket/304 | 00:02 | ||
| Austin | Whiteknight: Merged and pushed. It doesn't work now. I don't know if the merge caused it, or if it's a timing problem. | ||
| whiteknight | either way, anything is good | ||
| Austin | gitorious kakapo master | ||
|
00:04
wagle joined
|
|||
| Austin | WTF? How did all that get commented out? | 00:08 | |
| whiteknight | ? | 00:09 | |
| Austin | kakapo_top.pir_tmpl is suddenly all commented. | ||
| That's why some stuff isn't working | |||
| whiteknight | ...I may have done tht | 00:10 | |
| that | |||
| Paul_the_Greek | Question about .loadlib: None of the tests that do a .loadlib can find the specified file. | 00:11 | |
| Austin | What file? | ||
| Paul_the_Greek | Is there something I missed doing? | ||
| sys_ops, bit_ops, debug_ops, etc. | 00:12 | ||
| Austin | What os? | ||
| Paul_the_Greek | Windows XP. | ||
| dalek | kapo: 70e7a3e | austin++ | (27 files): Paying the taxes on invisible methods and a bunch of other idiotic changes in 2.3-2.6. |
||
| kapo: 56c7fac | austin++ | : review: gitorious.org/kakapo/kakapo/commit/...3014d3c5e0 |
|||
| Austin | Look in $PARROT/config_lib.pir, check the value of the [build_dir] setting. | ||
| Paul_the_Greek | It points to my top-level build directory. | 00:13 | |
| Austin | Well, I'm out of ideas. | 00:14 | |
| Are you running the tests from that dir? | |||
| Paul_the_Greek | Tests without a .loadlib work fine. | ||
| Yes. | |||
| The weird thing is that the .loadlib specifies, say, sys_ops, but the file is called sys.ops. | 00:15 | ||
| Austin | Yea | ||
| But the dll is sys_ops.dll | |||
| Paul_the_Greek | I have no such file. | ||
| cotto_work | .ops files are postprocessed into C | 00:16 | |
| Paul_the_Greek | I have no ops DLLs at all. | ||
|
00:16
aloha joined
|
|||
| Paul_the_Greek | I have no bit.c, either. Hmm. | 00:17 | |
| Perhaps I should remake my system. | |||
| Austin | look in $PARROT/runtime/parrot/dyn* | 00:20 | |
| Paul_the_Greek | Remaking produced the files. Now let me try the test. | 00:21 | |
| Much better. | |||
| And my new test works so much better. Thanks, Austin. | 00:22 | ||
| Austin | Whiteknight: Another push, this one makes the bootstrap test run | 00:26 | |
| tcurtis | pmichaud: ping | 00:30 | |
| dalek | rrot: r48373 | mikehh++ | branches/tt1726_pmc_pod/t/codingstd/pmc_docs.t: fix codetest failure - trailing spaces |
00:34 | |
| Chandon | Good job Parrot. Somehow you just managed to deadlock signaling a condition variable. | 00:40 | |
| Paul_the_Greek | It appears that I need GMP to get bigints. | 00:48 | |
| mikehh | Paul_the_Greek: yes | 00:49 | |
| Paul_the_Greek: what platform etc are you working on? | |||
| Paul_the_Greek | Windows XP | ||
| Does this look good? cs.nyu.edu/exact/core/gmp/ | 00:53 | ||
| mikehh | Paul_the_Greek: afraid I can't help there, I have been mostly working on Ubuntu distros for the last couple of years | 00:54 | |
| Paul_the_Greek | I'll check around. | ||
| mikehh | Paul_the_Greek: that looks ok though | 00:55 | |
| Paul_the_Greek | I'll deal with it tomorrow. Take care, folks. | 00:56 | |
| Austin | Whiteknight: Beware of occurrences of Array::new in the code. These can be replaced by either [ ... ] for simple cases (no splat), or by calls to R*A.new( ... ) for cases with splats. Note that 'splat' in this case is spelled |@foo | 01:11 | |
| or |<a b c> | |||
|
01:14
dngor_ joined
|
|||
| cotto | ~ | 01:17 | |
| dalek | rrot: r48374 | Chandon++ | branches/gsoc_threads (18 files): [gsoc_threads] Just need a couple less explosions... |
01:24 | |
|
01:25
plobsing joined
|
|||
|
01:26
mj41_ joined,
baest joined
01:27
workbench joined,
Austin_Hastings joined,
dmagnus_ joined
01:28
dalek joined,
wagle joined
|
|||
| dalek | kapo: d4fd7b0 | austin++ | : review: gitorious.org/kakapo/kakapo/commit/...0a84371ee5 |
01:31 | |
|
01:35
dalek joined,
dmagnus__ joined,
Austin_Hastings joined
01:37
s1n joined,
Austin joined
01:38
rurban_ joined,
sjn joined,
dmagnus_ joined,
dalek joined
01:39
ascent joined,
mikehh_ joined,
ttbot joined
01:40
preflex joined
01:42
Austin_Hastings joined
|
|||
| kid51_at_dinner | What are the HTML tags you use when you want to have some inline characters rendered in a monospace font? | 01:43 | |
| GeJ | kid51: <pre> ... </pre> | 01:44 | |
| kid51 | Will <code> work as well? | ||
| Austin_Hastings | also <tt> | ||
| kid51 | (this is inline, not whole paragraph) | ||
|
01:45
slavorg joined
|
|||
| kid51 | Well, at least on chromatic's blogs, none of those 3 work properly. Only <pre> changes the font ... but it imposes a paragraph. | 01:49 | |
| mikehh | opbots, names | 02:00 | |
| dalek | rrot: r48375 | jkeenan++ | failed to fetch changeset: [codingstd] Merge tt1726_pmc_pod branch into trunk. Adds new file t/codingstd/pmc_docs.t to flag functions lacking documentation in .pmc files. |
||
| rrot: r48376 | jkeenan++ | branches/tt1726_pmc_pod: Branch has been merged into trunk and is no longer needed at HEAD. |
|||
| purl | i already had it that way, dalek. | ||
| rrot: r48377 | jkeenan++ | tags/tt1726_pmc_pod-48342: Branch corresponding to tag has been merged into trunk; tag may be deleted. |
|||
|
02:01
davidfetter joined
|
|||
| Austin | kid51: www.w3schools.com/tags/tag_font_style.asp | 02:02 | |
| GeJ | kid51: an alternative would be to encapsulate your code inside a <span> et specify a style for it. | ||
| Austin | But beware of style sheets that might override the formatting | ||
|
02:12
mikehh joined
|
|||
| kid51 | GeJ: Thanks, but that's too much work for a simple blog response: tinyurl.com/28qg9o5 | 02:17 | |
| Austin: Thanks for link. But perhaps the problem is that that blog's software only supports a limited number of HTML tags. | 02:19 | ||
| Austin | Seems like it | 02:21 | |
| purl | somebody said Seems like it was creating a conflict somewhere, which then creates a requires condition | ||
| kid51 must sleep | 02:24 | ||
| purl | $kid51->sleep(8 * 3600); | ||
| cotto must sleep | 02:31 | ||
| purl | Sleep is for the weak. | ||
| cotto | much better | ||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48377 - Ubuntu 10.04 i386 (g++) | 03:18 | |
| t/op/exit.t - TODO passed: 6 in testf | |||
| darbelo | mikehh: Do you, by any chance, test on non-x86 (and non-amd64) arches? | 03:25 | |
|
03:32
riddochc joined,
janus joined
|
|||
| darbelo | purl, msg bacek From some eyeball-and-wallclock testing it looks like the unshared buffers branch make the rakudo build go slower and eat more memory. My guess is heavy 'substr' use in PCT, but I'm not sure how to properly account for that. | 03:33 | |
| purl | Message for bacek stored. | ||
| cotto | wasn't that the expected result? | 03:34 | |
| sorear | darbelo: have you optimized compact_pool yet? | 03:36 | |
| riddochc | I've been reading up on how to implement a new language targeting parrot. I just wanted to drop by and thank the people who have put so much work into the documentation. It's good stuff. | 03:37 | |
| sorear | Haha. | ||
| Great timing there. | |||
| cotto | riddochc, thanks for the feedback. You can blame tcurtis for the shape of the squaak tutorial. He did most of the work to get it up-to-date for the 2.6 release. | 03:38 | |
| sorear | About two weeks ago. | ||
| Actually the documentation has been improved a lot in the last couple months | 03:39 | ||
| riddochc | Nice. Maybe I'm crazy, but I'm really liking Clojure, except for the Java parts. ;) | 03:41 | |
| tcurtis | riddochc: If there's anything wrong with or that could be improved in the Squaak tutorial, please let me know. | 03:42 | |
| riddochc | I'm seriously thinking about Clojure for parrot. Maybe I'd call it 'pleajure'. I'll let you know, tcurtis. That's specifically what I've been looking at. | ||
| Actually, I doubt I'll have the time or energy to do it. But it's a fun idea, anyway, and an excuse to see what's new with parrot. | 03:45 | ||
| tcurtis | riddochc: I feel obligated to warn you that Parrot's threading/concurrency support is rather lacklustre. Although one of the GSoC students has been working on it, so maybe that will change soon. | 03:46 | |
| riddochc | tcurtis: Good to know. Oh, well. Perhaps it's a good idea in the long-term. | 03:48 | |
|
03:50
GeJ joined
|
|||
| mikehh | darbelo: I only have x-86 hardware at present, and can only test on that | 03:51 | |
| darbelo: I also had problems installing a a VM so need to reboot to test on another distro etc, so I stick to various versions of Ubuntu (usually the latest) | 03:54 | ||
| darbelo | mikehh: Not a problem, I asked out of curiosity, mostly. I know we have testers on various OSes, but I don't really what variety we have on the hardware front. | 03:58 | |
| sorear: Not yet, really. The only 'optimization' I've done to the gc is remove the flag checking and twiddling. | 04:00 | ||
| The compact_pool logic is still as... sub-optimal as it is on trunk. | 04:01 | ||
|
04:02
TiMBuS joined
|
|||
| mikehh | darbelo: darbelo: TapTinder does some nice testing - tt.taptinder.org/ | 04:03 | |
| bah getting too late for me, my typing is getting erratic | 04:04 | ||
| darbelo | sorear: But I'm not sure that acounts for most of the runtime penalty, really. Or the memory, for that matter. | ||
| mikehh: Yeah, but that's still mostly x86 and x86-64 AFAICT. | 04:06 | ||
| sorear | darbelo: AFAIU, the only real reason to bother with unsharing strings is compact_pool improvements | 04:07 | |
| mikehh | darbelo: I know kid51++ has an older Mac (pre x86) that he test on and AndyA++ does some solaris testing | ||
| riddochc | It's getting pretty hard to find hardware that isn't x86, x86-64, and ARM these days. | ||
| darbelo | It depends on your environment. In some places, SPARC boxes are still pretty common. | 04:09 | |
| sorear | riddochc: it's getting pretty easy to get *very* good emulators these days | 04:11 | |
| darbelo | And there's those chinese mips64 laptops I can't remember the name of right now. | 04:12 | |
| Austin | Loongson | 04:13 | |
| mikehh | I have some $work scheduled later in the year on a new IBM Power 780, maybe I can con^W, suggest that we can test parrot on that | 04:16 | |
| darbelo | Austin++ # Yep, those. | 04:17 | |
| riddochc | sorear: that's true, the emulators are decent. | ||
| mikehh | has anyone done any parrot testing on ARM? | 04:19 | |
| riddochc | certainly good enough for testing Parrot. | ||
| darbelo | mikehh: To my knowledge, we don't have anyone *building* on ARM on a regular basis. | ||
| It worked at some point, and it probably still does. | 04:21 | ||
| But we don't have regular testers, so we don't know for sure. | |||
| riddochc | Aren't a lot of the phones out there these days running ARM? | 04:22 | |
| sorear | Yes, but most phones don't have access to the several trillion Hz-seconds required to build Parrot | 04:23 | |
| darbelo | And, parrot doesn't do cross-builds at the moment. | 04:24 | |
| riddochc | That's unfortunate. Though understandable - cross compiling is tricky stuff. | 04:25 | |
| darbelo | Enabling cross-development was a big part of the parrot-on-RTEMS GSoC, but I don't know how far along that is. | ||
| sorear | Especially when the build system involves running tools written in PIR | ||
| darbelo | That can be solved by judicious use of a host-side parrot. | 04:26 | |
| plobsing | we would have to distinguish between $(HOST_PARROT) and $(TARGET_PARROT) in the makefile. we don't do that ATM. | 04:27 | |
| riddochc | Well, I know some people who specialize in cross-builds, but they don't really have a lot of copious free time to help out with parrot, sadly. | 04:29 | |
| mikehh | We still have problems relating to a built parrot and installed parrot | ||
| darbelo | And since we're asking for ponies, our build could be made smarter about some of the bootsrap steps too. | 04:30 | |
| riddochc | Ouch. | ||
| mikehh | darbelo: very much so | ||
| sorear | riddochc: Fortunately, we have someone being payed to do this thankless job. | 04:31 | |
| dalek | kapo: da37fc8 | austin++ | (5 files): Fixed accidental delete of Parrot:: namespace sub exports |
||
| mikehh | anyway gotta go, it's 5:30 am here and I seriously need a nap | 04:32 | |
| darbelo | sorear: Well, we have some student's getting paid to do *some* thankless jobs. I don't know of anyone outside of the GSoC getting paid to hack on parrot. | 04:33 | |
| riddochc | fwiw, I think the parrot and perl 6 projects have managed to avoid the biggest problem in the industry - being in too much of a hurry to do anything well. I know you've gotten a lot of flack for the timelines of the projects, but I think you're better off doing it this way. | 04:35 | |
| I've had enough of barely-working software getting shipped too early. So, cheers to parrot and perl 6. | 04:36 | ||
| Have fun, everyone. I'm off for now. | 04:40 | ||
|
04:40
riddochc left
|
|||
| dalek | rrot: r48378 | plobsing++ | branches/dynop_mapping/src/pmc (2 files): rework OpLib and Opcode to fit new model better. |
04:54 | |
| rrot: r48379 | plobsing++ | branches/dynop_mapping/t/pmc/pmc.t: fix test - OpLib now requires an initializer |
|||
| Austin | msg whiteknight Just pushed some fixes that get the UnitTest library passing bootstrap. Replaced all method with our-method, which is probably stupid in the long run. | 05:25 | |
| purl | Message for whiteknight stored. | ||
| dalek | kapo: 0075f45 | austin++ | (108 files): Got Testcase's working (bootstrap). Replaced all methods with our-method |
05:27 | |
| Austin | msg whiteknight prove -r --ext=nqp -e parrot-nqp t/bootstrap # this works for me - all bootstraps pass. | 05:45 | |
| purl | Message for whiteknight stored. | ||
| dalek | kapo: a46ea16 | austin++ | (3 files): Got all bootstrap tests working (String::isa) |
05:51 | |
| Andy | Thanks moritz++ perlbuzz.com/2010/08/im-glad-to-hea...-slow.html | 05:54 | |
| dalek | rrot: r48380 | plobsing++ | branches/dynop_mapping (3 files): check for core_ops (doesn't occur as a loaded dynoplib). |
06:05 | |
|
06:21
uniejo joined
|
|||
| dalek | TT #1735 created by plobsing++: Pmc2c line numbering confuses gdb | 06:21 | |
| TT #1735: trac.parrot.org/parrot/ticket/1735 | |||
|
06:30
jsut_ joined
06:36
LoganLK joined
|
|||
| dalek | rrot: r48381 | plobsing++ | branches/dynop_mapping/src/pmc/oplib.pmc: include appropriate header for fetching core_ops lib |
07:14 | |
| rrot: r48382 | plobsing++ | branches/dynop_mapping/t/pmc/oplib.t: update oplib tests to use initializer |
07:30 | ||
|
07:54
Casan joined
08:45
arnsholt joined
08:46
arnsholt_ joined
08:50
AndyA joined
09:27
bacek joined
09:35
aloha joined
09:37
rurban_ joined
09:41
cognominal joined
10:16
clinton joined
10:23
AndyA joined
|
|||
| dalek | kapo: 9bac5a4 | austin++ | (2 files): Checkpoint. Trying to get FileSystem up. DepQ may not be running |
10:42 | |
| kapo: 5f2617b | austin++ | src/ (24 files): Got UnitTest library restored, at least somewhat. Reverted damage to Matchers |
|||
|
10:55
GeJ_ joined
11:07
GeJ joined,
luben_work joined
11:11
lucian joined
11:14
slavorgn joined
11:45
wagle joined
11:46
rurban_work joined
11:50
whiteknight joined
11:59
clinton joined
12:09
rurban_work left
12:15
kid51 joined
12:41
lucian_ joined
12:44
lucian__ joined
|
|||
| Coke | riddochc++\\ | 13:01 | |
| riddochc++ #even | 13:02 | ||
|
13:04
Andy joined
|
|||
| Coke | is TT#1735's bug that the line number needs to be fixed? | 13:09 | |
| (because there's already a ticket for that. | |||
| ... that I cannot find. ah well. | 13:10 | ||
| Andy | Oh sure, Coke. Make ME do the modeline development. | 13:16 | |
| Do we have an existing .t that would be good to check for it in? | |||
|
13:18
bluescreen joined
|
|||
| Coke | codingstd/*coda*.t | 13:24 | |
| which has a check for existing ones. | |||
| but I'd make it a patch, because it's going to cause "make codetest" to fail. | |||
|
13:41
bluescreen joined
13:48
plobsing joined
|
|||
| bluescreen | ~prod support | 13:52 | |
| jdv79 | i hadn't realized how much nqp had progressed since last i looked. nice work. | 14:03 | |
|
14:04
bubaflub joined
14:07
ruoso joined
14:25
Paul_the_Greek joined
|
|||
| Paul_the_Greek | Hello everyone. | 14:25 | |
| Does anyone have an idea which file has to be where in order for configure to decide I have GMP installed? | |||
| moritz | typically the GMP development files | 14:27 | |
| ie headers | |||
| Paul_the_Greek | So gmp.h has to be somewhere? Do you know where? | 14:28 | |
| moritz | where the compiler can find it. | ||
| Paul_the_Greek | And a .dll somewhere, I presume (I'm on Windows). | 14:29 | |
| moritz | it's /usr/include/gmp.h for me | ||
| Paul_the_Greek | I would think putting it somewhere in the MinGW tree would do the trick. | ||
| moritz | Paul_the_Greek: write the simplest program you can think of that uses GMP. Try to compile it. If it works, your installation is fine | 14:30 | |
| or maybe use an example program from the gmp documentation | |||
| Paul_the_Greek | Configure doesn't see it. I'll keep futzing. | ||
| moritz | if you want to burn your time, sure go ahead fuztzin | 14:31 | |
| Paul_the_Greek | Trying to figure out how to compile a program is exactly as difficult as trying to figure out where Configure wants it. | 14:32 | |
| That's because I have absolutely no idea where to put the GMP files. | |||
| moritz | IME that's not the case. If you try to compile stuff, the compiler actually says what's missing | 14:33 | |
| whereas configure.pl just says "no." | |||
| though maybe with verbose output... | |||
| Paul_the_Greek | It's installed with Strawberry Perl, too, but that doesn't help. | 14:35 | |
| I'll try what you suggest, but I don't know why I couldn't compile a program if the .h file is in include and the .dll file is in bin. | 14:40 | ||
| Coke | the test configure runs is to add -lgmp to the compile options and try to run a c program. | 14:41 | |
| moritz | that's what the compiler is going to tell you :-) | ||
| Coke | there's no check for any libs or executables. just "does this program compile and generate the output I expect." | 14:42 | |
| Paul_the_Greek: are you adding the lib to the command line for the compiler? | |||
| Paul_the_Greek | Sorry, I haven't tried to compile a standalone program using GMP. I will do that. I just thought someone would know where to install GMP on Windows. | 14:44 | |
| Coke | I'd ask jnthn or particle. | 14:50 | |
| but If this was unix, I'd just install it, and it's either in the right spot, or I'd have to tell parrot where it was when I configured. | 14:51 | ||
|
14:54
mikehh joined
|
|||
| Paul_the_Greek | I can't find a Windows installer, only a gzipped file. | 14:55 | |
| Okay, compiling with -l has no problem with the include, but then complains about entry points. That makes sense. | 14:59 | ||
| When I use the -lgmp option, what file is it going to look for? | 15:03 | ||
|
15:05
theory joined
|
|||
| Andy | Coke: Or I can both update codingstd/*coda*.t AND update the codas. | 15:05 | |
| Coke | Andy: that would be ideal, yes. | 15:06 | |
| I was trying to provide smaller work-chunks. | |||
| Andy++ | |||
| Andy | I DO NOT NEED SMALL WORK CHUNKS | ||
| dafrito | haha <3 | 15:10 | |
| mikehh | Hey Andy, you see we have this small problem with parrot, it is called Garbage Collection, gc foir short, and if you are looking for a smallish chunk of work .... | 15:11 | |
| Andy | mikehh: I NEED WORK CHUNKS THAT I AM SUFFICIENTLY SMART ENOUGH TO HANDLE. | ||
| mikehh | Andy: ah well it was worth a try :-} | 15:12 | |
| Paul_the_Greek | Can you tell me what the -lgmp option does and what file it looks for? There is no documentation on -l from gcc --help --verbose. | 15:15 | |
| Coke | -l<library> | 15:17 | |
| atrodo | it tells gcc to link to the gmp library, which under unix would be libgmp.a (pretty sure) | ||
| Coke | gcc.gnu.org/onlinedocs/gcc/Link-Opt...nk-Options | ||
| Paul_the_Greek | When I installed GMP on Windows, I got libgmp-3.dll and libgmp.la | 15:18 | |
| Oh, that documentation helps, perhaps. Thanks Coke. No such option display with gcc --help --verbose. | 15:20 | ||
| atrodo | the key is that those two files should be found in ld's library path. You can try a "export LDFLAGS=<path>" before you configure | 15:22 | |
| Coke | atrodo: he's on windows. | 15:23 | |
| atrodo | hehe, i saw mingw and went the extra mile to assume bash. I would assume mingw checks env variables as well | 15:24 | |
| Paul_the_Greek | Success! | 15:29 | |
| purl | well, success is finding king size papers | ||
| Paul_the_Greek | That was much harder than it needed to be. | 15:30 | |
| Thanks, folks. | |||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48382 - Ubuntu 10.04 amd64 (gcc with --optimize) | 16:19 | |
|
16:22
theory joined
16:27
robin-gvx joined
|
|||
| cotto_work | ~~ | 16:55 | |
| atrodo | hey cotto_work | ||
| purl | cotto_work is, like, always at work or cotto's employed alter ego | ||
| atrodo | it makes it so difficult to actually say hello to someone sometimes | ||
| cotto_work | you mean purl? | 16:56 | |
| atrodo | Yep | 16:57 | |
| Paul_the_Greek | Well, that was lovely, but it's GMP 4.1, which is worthless. | 17:10 | |
| No chance anyone here runs on Windows, is there? | |||
|
17:22
bubaflub_ joined
17:37
rurban_ joined
|
|||
| Coke | Hello, Reini. | 17:56 | |
|
17:57
theory_ joined
|
|||
| dalek | kudo: 22a11d0 | moritz++ | (22 files): Merge branch 'master' into match-call src/core/Match.pm |
18:00 | |
| kudo: 77d4761 | moritz++ | src/core/Match.pm: fix wrongly resolved merge conflict |
|||
| kudo: 9412433 | moritz++ | src/ (3 files): !~~ now topicalizes too |
|||
| kudo: 87c82c2 | moritz++ | src/ (4 files): Merge branch 'match-call' sets the topic for negated smartmatch (!~~) |
|||
|
18:08
bubaflub joined
18:13
Paul_the_Greek joined
18:30
robin-gvx joined
|
|||
| cotto_work | #ps in 118 | 18:33 | |
| dalek | kudo: fcf4f36 | moritz++ | (3 files): adverbs for m// |
18:35 | |
|
18:39
luben_work left,
Chandon joined
19:27
smash joined
|
|||
| smash | hello everyone | 19:27 | |
| moritz | smash! | 19:28 | |
|
19:34
lucian joined
19:36
theory joined
19:38
mikehh joined
19:40
tcurtis joined
|
|||
| Austin | pmichaud++ #'multi' works in nqpr | 19:58 | |
| x | |||
| dalek | kapo: b9c38b8 | austin++ | (4 files): Got FileSystem working with multi methods (pmichaud++) |
20:00 | |
| cotto_work | It's nice to have multis in nqp | 20:01 | |
| dalek | rrot: r48383 | Chandon++ | failed to fetch changeset: [gsoc_threads] Merge from trunk. |
20:07 | |
| smash | nominations for next parrot foundation board of directors are up, as soon my e-mail hits parrot-members | 20:20 | |
|
20:21
chromatic joined
20:25
theory joined
20:26
AndyA joined
|
|||
| mikehh | #ps time | 20:30 | |
|
20:32
AndyA_ joined
|
|||
| GeJ | Bonjour everyone. | 20:40 | |
| chromatic | aloha | ||
| Coke | ho. | 20:41 | |
| tcurtis | Hello. | ||
| cotto_work | mro? | 20:43 | |
| purl | mro is the Digital sitecode for Marlboro, MA or Method Resolution Order or www.python.org/2.3/mro.html or one solution to the 'Diamond Problem' at en.wikipedia.org/wiki/Diamond_problem or Method Resolution Order or a pragma, see the 5.10 docs for details | ||
| cotto_work | Paul_the_Greek: ^ | ||
| chromatic | When you dispatch a method, which class's variant of that method gets called | ||
| Coke | MMDRO! | 20:44 | |
| moderator | Parrot 2.6.0 | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | merge html_cleanup (talk to Coke), merge gc_* branches, fix/replace/optimize hashing | 20:45 | |
| darbelo | chromatic: In my case: (0) Point at the area where we need to dig. (1) Explain what we need to do (2) Give a 'easy' way to determine success of the task. (3) Prod periodically. | 20:46 | |
| (iv) Make me stop talking on the wrong chanel. | 20:47 | ||
| Coke | msg bacek I'll buy you a beer if you finish gc_massacre! | 20:56 | |
| purl | Message for bacek stored. | ||
|
21:03
whiteknight joined
|
|||
| cotto_work | Shipping might be pricey. | 21:12 | |
| chromatic | seen plobsing | ||
| purl | plobsing was last seen on #parrot 16 hours, 45 minutes and 9 seconds ago, saying: we would have to distinguish between $(HOST_PARROT) and $(TARGET_PARROT) in the makefile. we don't do that ATM. | ||
| whiteknight | hash_allocator branch is a priority? | 21:13 | |
| dalek | rrot: r48384 | darbelo++ | branches/unshared_buffers/src/string/encoding/utf8.c: Make utf8 not depend on str_new. |
||
| rrot: r48385 | darbelo++ | branches/unshared_buffers/src/string/encoding/utf16.c: Make utf16 not depend on str_new. |
|||
| rrot: r48386 | darbelo++ | branches/unshared_buffers/src/string/encoding/ucs2.c: Make ucs2 not depend on str_new. |
|||
| rrot: r48387 | darbelo++ | branches/unshared_buffers/src/string/encoding/ucs4.c: Make ucs4 not depend on str_new. |
|||
| rrot: r48388 | darbelo++ | branches/unshared_buffers/src/string/encoding (5 files): Add smarter handling of constant and external strings. |
|||
| smash & brb | 21:17 | ||
|
21:22
luben joined
|
|||
| Util | Paul_the_Greek: where did you find 4.1.3 binaries? | 21:22 | |
| luben | hello guys | 21:27 | |
| Paul_the_Greek | Util: cs.nyu.edu/exact/core/gmp/ | 21:28 | |
| cotto_work | hi luben | 21:30 | |
| luben | I have seen that hash table rework is a high priority task. I was looking at he hash.c code and have a pretty good understanding of ist internal logic | ||
| I have some quick optimizations that could get us around 3-4% | 21:31 | ||
| cotto_work | luben: by all means, nopaste a patch or file a ticket | 21:32 | |
| luben | but the current code is ok as it is | ||
| I have some design questions | 21:33 | ||
| dukeleto | luben: that sounds awesome, maybe you can create a svn/git branch for that work | ||
| luben | if we want to gradually redesign the hash logic, this optimisations will be reverted (that depends on the new design)) | 21:34 | |
| whiteknight | luben: what kind of redesign are you thinking? | 21:35 | |
| luben | Also I would like to talk about the overall principles | ||
| Paul_the_Greek | I'm interested in listening in on the hash issues. | 21:36 | |
| luben | but I am not quite sure that it will not break parrot in other parts | ||
| dukeleto | luben: that is what our test suite is for :) | ||
| luben | that poke with the hash internals | ||
| Util | Paul_the_Greek: Any reason not to jump ahead to GMP 5.0.1? | 21:37 | |
| dukeleto is surprised to hear that GMP 5.x is out | |||
| Paul_the_Greek | I don't think so. The BigInt tests check for >= 4.1.4 | ||
| luben | so, first, one quick question: I have seen that hash_table struct has a pointer to its container | ||
| and on each update it checks if the container is defined as constant and refuse the operation in such a case | 21:38 | ||
| chromatic | Seems backwards, doesn't it? | 21:39 | |
| luben | It is used in such a manner by OrderedHash.pmc and Namespace.pmc | ||
| My logic is that enforcing the policy of the container is work of the container, not the underleing data structure | 21:40 | ||
| chromatic | Agreed. | ||
| dukeleto | bubaflub: things proceeding? stuck on anything? | 21:41 | |
| bubaflub | dukeleto: yeah, i'm actually hacking on it as we speak | ||
| dukeleto | bubaflub: goodly :) | ||
| bubaflub | dukeleto: just a bummer knowing that i won't make my original target | ||
| NotFound | luben: killing that pointer to the container will be good. | ||
| dukeleto | bubaflub: it happens. don't think about that, and let's see if we can get out-of-dir compiling working, that is a big step in the right direction | 21:42 | |
| luben | the fast optimisations: we could remake hash_mark_keys,hash_mark_values and hash_mark_both to walk lineary the buckets | ||
| bubaflub | dukeleto: i still want to finish what i set out to do, but it just might take a while | ||
| luben | and we destinguish occupied buckets by key!=NULL | 21:43 | |
| chromatic | luben, I think that only works if the bucketlist/freelist are linear. | ||
| luben | yes. but most of the time they are (if we do not have a lot of deletes) | ||
|
21:44
bacek joined
|
|||
| dukeleto | bubaflub: that is what everyone wants. Let's try to get something tangible by the hard-pencil date, and then we can work on this a bit more leisurely :) | 21:44 | |
| luben | hash buckets are allokated lineary from the top to the tail | ||
| cotto_work | bubaflub: whiteknight didn't get his original gsoc target either. Don't worry too much about it. | ||
| bubaflub | dukeleto: indeed. the first half is tangible - i've got the secret sauce to do a minimum libparrot for cross-compiling. | ||
|
21:45
aloha joined
|
|||
| dukeleto | bubaflub: you will pass as long as everyone thinks you tried your best. We all know you are dealing with some hairy internals across two very different projects, which ain't easy. | 21:45 | |
| luben | As I said that I am not so sure about long term viability of this aproach | ||
| The other idea i have is a little more complex | 21:46 | ||
| mikehh | Paul_the_Greek: gmplib.org/ | ||
| luben | it is not local optimisation, but a whole (gradual) rework of the hash data structure | ||
| bubaflub | dukeleto: well, the good news is i'm unstuck from that problem i reported on tuesday. | 21:47 | |
| Paul_the_Greek | mikehh: They have no binaries for Windows. Not sure they have binaries at all. | ||
| bubaflub | dukeleto: Configure.pl now will handle making the dir's necessary in the build directory. Now, gotta hack the Makefile to reference the source dir where appropriate | ||
| chromatic | Reworking the whole hash seems reasonable. | ||
| mikehh | Paul_the_Greek: just the source | ||
| luben | My curiousity was provoked by 75% rule that was removed by chromatic | ||
| smash back | 21:48 | ||
| luben | because there is such a rule in hash tables design | ||
| Paul_the_Greek | Yes, but it can't be built on Windows. At least not that I can figure. | ||
| luben | but this is not our case (we use separate chaining with pre-allocated space) | 21:49 | |
| chromatic | The rule as I understood it was "Reallocate when you're 80% full" | ||
|
21:49
bubaflub joined
|
|||
| mikehh | Paul_the_Greek: maybe you should install Ubuntu 10.04 LTS, it can be installed within Windows if you like | 21:49 | |
| luben | yes, not it does not concern separate chaining hash implementations | ||
| s/yes, not/yes/ | 21:50 | ||
| Paul_the_Greek | mikehh: Ouch. I'm a Windows guy. Anyway, we have to get binaries for our users, no? | ||
| luben | And I nave a rather radical idea | ||
| in the situation now we have the same size of hash buckets and hash_indexes | 21:51 | ||
| mikehh | Paul_the_Greek: I know saome of the rakudo developers use Windows, jnthn for example, you could check with him maybe | ||
| Paul_the_Greek | mikehh: I will check. | 21:52 | |
| tcurtis needs to get around to figuring out how to get Parrot's configure to recognize his libgmp installation at some point. | |||
| luben | indexes store a pointer to a bucket: i = hash(key)%N = index[i] = *bucket | 21:53 | |
| could we eleminate the entire hash indexes and address directly the buckets | |||
| chromatic | Makes sense. | ||
| dukeleto | tcurtis: you may need to add some directories to LD_LIBRARY_PATH if you installed libgmp in a non-standard place | 21:54 | |
| luben | we will have a 2/3 of our size | ||
| and my profiling the previous 2-3 days have shown that the size of the data structures is primal factor to hash table performance | 21:55 | ||
| example: just adding additional field in bucket struc could lower the performance with 5-6% | |||
| chromatic | Rakudo creates some 44,000 hashes to start up. | 21:56 | |
| Paul_the_Greek | Wow. | ||
| luben | yes, I have seen in the callgring/cachegrind profiles... it's huge | ||
| my concerns are: | 21:57 | ||
| there are some other pieces of parrot that seem to poke with current hash_indexes: | |||
| OrderedHash and args.c | 21:58 | ||
| (probably for performance reasons) | |||
| chromatic | Right. | ||
| luben | if we eleminate indexes they could use straight addressing and have the same benefit | 21:59 | |
| chromatic | I'm all for this. | 22:00 | |
| Paul_the_Greek | So there is a block of buckets and then also a vector of indexes into them? | ||
| luben | if we make such a elemination, we have something that is known as "coalesced hashing" or "coalesced chaining" | ||
| here is quick overview en.wikipedia.org/wiki/Coalesced_hashing | |||
| Paul_the_Greek | I believe Lua uses coalesced hashing. | 22:01 | |
| luben | it is very efficent memory-wise, with very fast inserts and lookups | ||
| but with slower deletes | 22:02 | ||
| and more complex expanding algorythm | |||
| Paul_the_Greek | I implemented a coalesced hash table for a language I was working on. You can take a look at it if it would be of any help. | ||
| luben | I have some prototypes | 22:03 | |
| just to get the idea | |||
| Paul_the_Greek | It also moves an entry that is not in its home position if a new entry comes along with that home position. | ||
| luben | but my understanding is thet we should gradually morph our hash in the desired type | 22:04 | |
| chromatic | If we can get rid of container before the 2.7 release, we should see modest performance and memory improvements. | ||
| Paul_the_Greek | luben: How can I send you a small chunk of text, the description of my hash table? | 22:05 | |
| cotto_work | Paul_the_Greek: nopaste | ||
| Paul_the_Greek | nopaste? | ||
| purl | nopaste is nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl) or paste.scsys.co.uk or www.extpaste.com or gist.github.com or App::Nopaste or codepeek.com/paste/ or (: pastebot) | ||
| luben | actually it is not a lot of work: just mouve i check and exception raise from hash.c to corresponding PMCs | 22:06 | |
| chromatic | Sounds easy to do. | ||
| luben | yes, it is used only in src/pmc/orderedhash.pmc and src/dynpmc/dynlexpad.pmc | 22:07 | |
| also, if we move now to liner scan in mark functions, they will work as is without indexes | 22:09 | ||
| chromatic | Can you make two patches for those? | ||
| luben | a could send a patch tommorow | ||
| yes | |||
| I have done it and revered, just to explore other routes | 22:10 | ||
| chromatic | Thanks! | 22:13 | |
| bubaflub | dukeleto: i've confirmed that my changes work; all that remains for out of directory building is fixing the Makefile to point to the source dir explicitly. i'll be working on it a bit tonight. | ||
| luben | after elimination of bucket indexes (this will gain us some performance) we could gain more performace if we need it (compromising memory) | 22:14 | |
| with allocation of overflow area | |||
| elemination bucket indexes will speed the hash put/get functions because we will have one less indirection | 22:16 | ||
| and will reduce the memory size | |||
| I will send the patch for mark functions in an hour | 22:17 | ||
| Also 1 question: full hash revamp is not planned for 2.7 release | 22:20 | ||
| chromatic | Right. | ||
| dalek | rrot: r48389 | darbelo++ | failed to fetch changeset: Sync with trunk. |
||
| luben | ok:) because I am plannong a 2 week vacation from next monday | 22:21 | |
| tcurtis | What's the proper way to make a PAST::Val produce a Float rather than an Integer? :returns<Float> doesn't appear to work. | 22:23 | |
|
22:40
bacek joined,
aloha joined
|
|||
| luben | ok, here is a patch for linear scanning of the buckets on gc_mark : pastebin.com/m6KAsbw5 | 22:44 | |
| it gives me a moderate improvement in rakudo startup benchmark: from 690ms to 660ms | 22:46 | ||
| by my calculation it improvement of 4% | 22:48 | ||
| chromatic | Let me use Callgrind. | 22:49 | |
| luben | my benchmark is : $time parrot --hash-seed=D3C21BCF466DA1 ../rakudo/perl6.pbc -e '' | 22:50 | |
| dukeleto | luben: are you doing multiple runs or is that % improvement from a single run? | 22:52 | |
| luben | we should consider also CPU cache misses, not only instructions executed | ||
| yes, it is not from a single run | |||
| chromatic | I'll run Cachegrind too. | ||
| luben | first run is discarded because of the disk IO | 22:53 | |
| then I make 10 runs | |||
| and discard the extremes | 22:54 | ||
| dukeleto | luben: sounds great, just checking :) | ||
| dalek | rrot: r48390 | chromatic++ | trunk/src/call/args.c: [PCC] Tidied code; no functional changes. |
||
| rrot: r48391 | chromatic++ | trunk/src/pmc/hash.pmc: [PMC] Reordered some Hash code for clarity. |
|||
| luben | and make an average of the rest | ||
| chromatic, I use this: valgrind --tool=callgrind --cache-sim=yes --branch-sim=yes | |||
| valgrind Release 3.5.0 | 22:55 | ||
| chromatic | I haven't used --cache-sim, good idea. | ||
| luben | and than analyze data in kcachegrind | ||
| this simulates an avarage CPU cache | 22:56 | ||
| you could set as an options the exact parameters of the CPU cache hierarhy, but I hope that they have picked a reasonable defaults | 22:57 | ||
|
22:57
jsut_ joined
|
|||
| Paul_the_Greek | How would I contact a Rakudo person named jnthn? | 22:59 | |
| luben | jnthn? | ||
| purl | i think jnthn is giving a lecture at the uni friday afternoon i think | ||
| cotto_work | ping him here or ping jonathan in #perl6 in freenode | ||
| tcurtis | cotto_work, Paul_the_Greek: I'm fairly certain jnthn is jnthn both here and in #perl6. | 23:00 | |
| Paul_the_Greek | join #perl6 | ||
| Oops. | |||
| cotto_work | for some reason I thought otherwise | ||
| my mistake | |||
| chromatic | So far that patch looks like an improvement, luben. | 23:01 | |
| Paul_the_Greek | When you guys leave a message for someone here, where does it show up? | 23:02 | |
| chromatic | msg Paul_the_Greek Here's how purl works. Respond to me in channel. | 23:03 | |
| purl | Message for paul_the_greek stored. | ||
| dalek | parrot: e9bcd4a | (Jonathan "Duke" Leto)++ | html/docs.html: Link to the PGCon website, which has the presentation and audio |
||
| chromatic | luben, it's an improvement here of modest performance (0.657% on Callgrind, about that for Cachegrind). | 23:06 | |
|
23:06
aloha joined
|
|||
| luben | it is possible, my calculation was based on wall clock (64bit linux) | 23:13 | |
|
23:13
lucian joined
|
|||
| dukeleto | luben: yeah, wall clock isn't very useful for benchmarking purposes, since it is a function of the load of the machine | 23:14 | |
| luben | there is no other load | 23:16 | |
| or not considerable load | |||
| Austin | Paul_the_Greek: say something | 23:19 | |
| purl | something | ||
| Paul_the_Greek | Hey ho! | ||
| Austin | And purl says, "You have a message!" | ||
| Util | Paul_the_Greek: Did you try to build GMP with MinGW+MSYS, or just plain MinGW ? | 23:20 | |
| Austin | Then you say, "purl, messages" | ||
| Paul_the_Greek | Plain MinGW. Except I couldn't convince myself that the makefile would even work on Windows. | ||
| I must admit I didn't try too hard. | 23:21 | ||
| mikehh | Paul_the_Greek: you can try a ping, as in name: ping, which may gender a response, or otherwise msg | 23:23 | |
| Austin | engender or generate | ||
| (or produce or yield or elicit) | 23:24 | ||
| mikehh | I think I meant to say render :-} | ||
| Austin | You didn't, really. | ||
| Yes! That worked. | 23:25 | ||
|
23:26
hercynium joined
|
|||
| mikehh | Austin: early hours of the mornin' for me at present :-} | 23:26 | |
| Austin | :-) | ||
| clock | 23:27 | ||
| clock? | |||
| purl | Austin: LAX: Tue 4:27pm PDT / CHI: Tue 6:27pm CDT / NYC: Tue 7:27pm EDT / LON: Wed 12:27am BST / BER: Wed 1:27am CEST / IND: Wed 4:57am IST / TOK: Wed 8:27am JST / SYD: Wed 9:27am EST / | ||
| mikehh am on BST | 23:28 | ||
| Austin | Yoiks | ||
| mikehh at least so they tell me | 23:29 | ||
| Austin | We are EUROPEANS! You may take our currency, but you'll never take our ... TIME ZONES!!! | ||
| mikehh | you colonials don't seem to appreciate these things ... | 23:31 | |
| Austin | Heh. Don't point the finger at us. Did you see the Sovie^W Cissi^W Russians are talking about legislating away about 2/3ds of theirs? | 23:32 | |
| (Admittedly, we only use two...) | 23:33 | ||
| mikehh | right, like when I was in Hawaii , that time... | 23:35 | |
| luben | chromatic, it is a step in the direction of eleminating hash_index and the code is more simple, but it assumes certain properties of the bucket allocation (linear from the top) | 23:36 | |
| chromatic found a 4.383% performance improvement in Parrot startup. | |||
| Austin | Yeah, they don't even use clocks, I think. | ||
| But all the ones they do have are set to Pacific time, so they know when the next planeload of tourists is taking off.. | 23:37 | ||
| Ahh, multi-methods. You were doing so well until I tried to actually CALL you... | 23:38 | ||
| luben | I think cachegrind defaults are very conservative (something like P3). now I am running some passes to compare the default with the cache hierarchy of current CPUs | 23:40 | |
| sorear | chromatic: Do you feel TODO is a failing test? | 23:47 | |
| chromatic | I only TODO expected failures. | ||
| For example, an unimplemented feature I want to test anyway gets a TODO. | 23:48 | ||
| sorear | Also, what do you recommend we do about the 2 hour Perl 6 testsuite, it's driving me up the wall | ||
| chromatic | NQP-rx profiling and optimization. | 23:49 | |
| Paul_the_Greek | Take care, folks. | 23:50 | |
| chromatic | My intuition says that there are a handful of hotspots there that need optimization at the PIR/PCT level, not the Parrot level. | 23:53 | |
| (Setting aside the fact that improving Parrot hashing, register allocation, and GC performance will improve Rakudo dramatically.) | |||
|
23:54
ruoso joined
|
|||
| chromatic | Rakudo's runtime isn't super speedy, but something in the parsing stage has the feel of an algorithmic problem. | 23:55 | |
| ttbot | Parrot trunk/ r48393 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/365428.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) | ||
|
23:59
Psyche^ joined
|
|||