|
Parrot 2.0.0 "Inevitable" released! | parrot.org | Priorities: deprecated core PMCs, ops -> dynops, GC tuning and implementation | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs Set by moderator on 2 February 2010. |
|||
|
00:04
tetragon joined
|
|||
| Coke | I have no idea. =-) | 00:08 | |
|
00:15
cotto_w0rk joined
|
|||
| Whiteknight | cotto_w0rk: not too hard. I've set it up a few times | 00:20 | |
|
00:21
payload joined
|
|||
| bacek_at_work | Aloha! | 00:56 | |
| cotto_w0rk | hi bacek_at_work | ||
| bacek_at_work | hi cotto_w0rk | 00:57 | |
| dukeleto | o hai | ||
|
00:58
patspam joined,
hiroyuki_y joined
01:03
abqar joined
01:06
cognominal joined
|
|||
| Whiteknight | hello bacek | 01:19 | |
| cotto_w0rk | anyone feel like fixing headerizer? | 01:22 | |
| chromatic | Should be simple; I can poke at it in 90 minutes if no one beats me. | ||
|
01:23
particle joined
|
|||
| Whiteknight | oh no...must rush to try and beat chromatic to fix headerizer... | 01:25 | |
|
01:47
theory joined
01:49
kid51 joined
02:02
sjn joined
02:14
ash_ joined
|
|||
| bacek_at_work | Whiteknight, can you rush to fix gc_encapsulate? :) | 02:26 | |
|
02:26
chromatic joined
|
|||
| Whiteknight | what needs fixin? | 02:30 | |
| building now | 02:31 | ||
| dukeleto | hola | 02:32 | |
| purl | what's up, dukeleto. | ||
| Whiteknight | hello duke | 02:33 | |
| bacek_at_work | Whiteknight, everything! | 02:36 | |
| purl | rumour has it whiteknight, everything is building now, but when t/op/annotate.t runs, the above happens | ||
| cotto_w0rk | botsnack | ||
| purl | thanks cotto_w0rk :) | ||
| Whiteknight | gdbing now | 02:37 | |
| dukeleto | Whiteknight: howdy, fine sir | ||
| dukeleto is playing with new embedded hardware and researching how to get parrot on it | 02:38 | ||
| Whiteknight | i'm going to have to read through this diff | 02:45 | |
| damnit, no clean diff | 02:50 | ||
|
02:54
dalek joined
|
|||
| kid51 heard a talk tonight on systems programming on embedded hardware | 02:56 | ||
|
02:57
KatrinaTheLamia joined
|
|||
| Whiteknight | bacek: Nothing I can do tonight. More looking tomorrow | 03:07 | |
| bacek: one thing I noticed is that we have an Object getting collected prematurely. Suggests that either a CallContext isn't getting marked completely or another Object isn't getting marked properly | 03:08 | ||
| anyway, Whiteknight out! | 03:09 | ||
|
03:23
dalek joined
03:37
cxreg left,
cxreg joined
03:39
dalek joined
|
|||
| bacek_at_work | slacker... | 03:47 | |
| purl | hmmm... slacker is like lazy bum | ||
| eternaleye | cotto_w0rk: Trac is pretty darn easy. Set it up on my laptop once just for kicks, spent more time learnign how apache config files work than setting up trac itself. | 04:08 | |
|
04:20
eternaleye joined
04:32
chromatic joined
04:39
Austin_away joined
|
|||
| Austin | Well, a segfault is nice. | 05:42 | |
| cotto | a segfault? | 05:52 | |
| purl | it has been said that a segfault is xkcd.com/371/ | ||
| cotto | a segfault is also nice | 05:53 | |
| purl | okay, cotto. | ||
| Austin | cotto: Yeah, 2.0.0 | ||
| cotto | I guess it may not be so nice then. | ||
| Austin | Heh. I'm trying to debug by dumping arguments. Naturally, dumping arguments causes a segfault. :( | 05:54 | |
| cotto | d'oh | ||
| Austin | Heh. I'm trying to debug by dumping arguments. Naturally, dumping arguments causes a segfault. :( | 05:59 | |
| Whoops. Lost track of the current window. | |||
| Hoo hah. | 06:05 | ||
| It segfaults in scalar concat called on a HashIteratorKey | 06:06 | ||
| The Hash in question is an automatically created :named:slurpy parameter hash. :( | 06:07 | ||
|
07:03
bacek joined
|
|||
| Austin | Significantly, if I set the wayback machine to 1.7, I get a segfault from an exception raised by PObj_is_PMC_TEST(sig_pmc), whatever *that* means. | 07:16 | |
|
07:28
fperrad joined
|
|||
| cotto | Is it just me or is this line not sane: trac.parrot.org/parrot/browser/trun...rge.c#L616 | 07:34 | |
| It seems to have been added during a merge. | 07:36 | ||
| Austin | Why do you think it's not sane? | ||
| cotto | because it's adding an unrelated value to a char* | 07:37 | |
| Austin | Knowing nothing at all about the code... | 07:38 | |
| It looks like mapping is allocated empty, then copied from somewhere. | |||
| The offset is bumped by line numbers, but I don't know what that signifies. Is offset a line-number type? | 07:39 | ||
| The filename is bumped by the const_start value of what looks like the current input - that is, the same data structure mapping was copied out of. | 07:40 | ||
| cotto | It's odd. | 07:43 | |
| I guess it makes sense though. | |||
| Austin | There's lots of other places in the code where inputs[...]->const_start gets added. | 07:44 | |
| I assume the filename is an offset of some kind. | |||
| So const_start is where the constant data for that segment starts, which would have been relatively 0 before the merge began.. | 07:45 | ||
| cotto | In most cases it's clear why const_start is used. | ||
| Austin | But considering that my segfault is in code that has been pbc_merged (and similar code, not merged, does not segfault) I encourage you to eliminate bugs in there. | 07:46 | |
| cotto | yeah. Don't use pbc_merge right now. | ||
| Austin | LOL. I'm counting on it. | 07:47 | |
| cotto | It's definitely broken. | ||
| a workaround is to .include the files you need and compile that to a pbc with parrot | |||
| Austin | Yeah. | ||
| That's what I don't want to do. | |||
| cotto | My goal right now is to get pbc_merge to the point where it can become a part of Parrot's build process. | 07:48 | |
| Once it's there, it'll be safe for you to use too. | |||
| Austin | Is there some kind of -Dname=value supported by pir? | ||
| cotto | only if you want to add it | 07:49 | |
| Austin | laugh | ||
| cotto | (not that it'd be a bad idea, but I'm pretty sure that's not what you're hoping for) | 07:50 | |
| Austin | Much of the point of Kakapo is to provide a run-time library for nqp code, etc. | ||
| Which requires "library-ness", which I interpret to mean "link against this separate binary". | |||
| I'm okay with loading bytecode, but I hate the idea that every program has to have a .pir top level. | 07:51 | ||
| cotto | which won't be doable until pbc_merge doesn't cause mysterious and wonderful failures | ||
| cotto gets back to work | |||
| Austin | Well, get back to work, then. | ||
| :0 | |||
| I'm glad you were here, cotto. Now I can go to bed with a clear conscience. | 07:53 | ||
| :) | |||
| Niterz. | |||
| cotto | .o0( It's nice to see that the problem I'm working on will forestall someone's eventual insanity. ) | 08:00 | |
| dalek | rrot: r43714 | cotto++ | trunk/src/pbc_merge.c: [pbc_merge] Use arrays to map input constants to their location in the output file. |
08:03 | |
|
08:07
jan joined
08:51
ZeroForce joined
08:58
chromatic joined
09:03
payload joined
09:04
payload joined
09:06
payload joined
09:08
riffraff joined
09:44
eternaleye joined
|
|||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32053), fulltest) at r43714 - Ubuntu 9.10 amd64 (gcc with --optimize) | 09:53 | |
| cotto | good times | 09:57 | |
| purl | DON'T OPEN IT! IT'LL CRASH AOL! | ||
| cotto opens it expectantly | |||
|
10:20
payload joined
10:40
cosimo joined
11:00
mj41_ joined
11:27
adu joined,
mj41_ joined
12:13
payload joined
12:23
bluescreen joined
12:25
bluescreen joined
12:27
payload1 joined
13:17
whiteknight joined
|
|||
| whiteknight | good morning #parrot | 13:29 | |
|
13:35
daqing joined
|
|||
| daqing | hi, everyone! parrot 2.0.0 compiles failed on Mac OS X 10.6 | 13:36 | |
|
13:41
daqing joined
|
|||
| daqing | Parrot 2.0.0 compiles failed on my Mac OS X 10.6 machine, look at pastie.org/809296 for screen output. I | 13:43 | |
| My gcc version: | |||
| gist.github.com/c18d37eaba4da7c3bb44 | 13:44 | ||
| anyone there? | |||
| moritz takes a look, but it not very familiar with mac | 13:45 | ||
| daqing: how did you configure parrot? | |||
| Infinoid | the "\\c" at the end of the compilation command line looks suspicious | 13:46 | |
| daqing | perl Configure.pl | ||
| moritz | Infinoid: aye | ||
| daqing | Infinoid: yes, but i don't know how to fix it | 13:47 | |
| maybe the "\\c" should just be "\\" ? | |||
| or "-c"? | |||
| Infinoid | that's a linker line, so probably not -c | ||
| moritz | but why is it using c++ as a linker? | 13:48 | |
| I don't think it does that by default | |||
| Infinoid | my parrot-fu is lacking, these days. but what's the \\c magic in Parrot::BuildUtil for? | 13:49 | |
| daqing | I looked at the generated Makefile, only found this line: ICU_SHARED := -lpthread -lm -L/opt/local/lib -licuuc -licudata -lpthread -lm \\c | 13:50 | |
| was ended with "\\c" | |||
| Infinoid | is there a \\c elsewhere in that file? | 13:51 | |
| daqing | no | ||
| is "\\c" a typo? | 13:52 | ||
| Infinoid | I suspect it's a regular expression "control character" match, that was taken literally by mistake | 13:53 | |
| the ICU_SHARED stuff in 2.0 is generated by config/auto/icu.pm | |||
| daqing | however, parrot 2.0.0 compiles perfectly on my ubuntu virtual machine, so this is weird. | ||
| Infinoid | Does your mac have libicu installed? Does your ubuntu have libicu installed? | 13:54 | |
| (I think this can be seen in the configure output.) | 13:55 | ||
| daqing | auto::icu - Is ICU installed....................................yes. | 13:57 | |
| yes | |||
|
14:01
payload joined
|
|||
| daqing | I just found out that the Make file generated on ubuntu had no "\\c" character on that line.. | 14:04 | |
| Infinoid | yeah, doesn't happen on my gentoo box either | 14:10 | |
| adu | hi all | 14:15 | |
| Infinoid | daqing: Any chance you can nopaste the output of "perl Configure.pl --verbose"? | ||
|
14:15
d4l3k_ joined
|
|||
| daqing | wait a moment.. | 14:15 | |
| OK, I know the reason... | 14:19 | ||
| I run "icu-config --ldflags" and get: -lpthread -lm -L/opt/local/lib -licui18n -licuuc -licudata -lpthread -lm \\c | |||
| Infinoid | oops :) | ||
| daqing | thank you guys | 14:20 | |
| Infinoid | daqing++ | 14:21 | |
|
14:23
cognominal joined
14:30
iblechbot joined
14:37
particle joined
|
|||
| Coke | the \\c bug is one that has been biting people on OSX on and off. | 14:43 | |
| for some reason the generated makefile ends up with them. | |||
| moritz | maybe we should manually remove it from the output of icu-config | 14:44 | |
| Coke | oh, it's from Icu? | ||
| yay. | |||
| moritz | according to irclog.perlgeek.de/parrot/2010-02-04#i_1956595 yes | 14:45 | |
| Coke | yes, check out config/auto/icu.pm, presumably there's a good spot there to strip out the \\\\c | ||
| moritz | there is indeed | 14:49 | |
| redbrain | hey guys have you done much more on jit support? I've been playing with llvm jit seems one would have to write a llvm jit driver in C++ then just have it callable from c code | 14:52 | |
| dalek | rrot: r43715 | moritz++ | trunk/config/auto/icu.pm: [config] remove \\c that is sometimes returned from icu-config on MacOS |
15:12 | |
|
15:22
particle joined
15:30
Psyche^ joined
|
|||
| whiteknight | If I add a new project to the Modules page on the Tracwiki, it should get picked up by dalek? | 15:39 | |
|
15:40
bubaflub joined
|
|||
| Coke | redbrain: I don't think anyone has touched llvm integration since we decided "yay, that's nice." | 15:42 | |
| Infinoid | whiteknight: yes, assuming dalek knows how to find and parse its rss feed | 15:44 | |
| whiteknight | yeah, it's a standard github project | ||
| Infinoid | cool, should work. May take dalek a couple hours to notice it tho | ||
| dalek | tracwiki: v5 | whiteknight++ | Modules | ||
| tracwiki: trac.parrot.org/parrot/wiki/Modules...ction=diff | |||
| tracwiki: v6 | whiteknight++ | Modules | |||
| tracwiki: PLA is in use by Matrixy and is mostly stable for now. Bump to Beta stage | |||
| tracwiki: trac.parrot.org/parrot/wiki/Modules...ction=diff | |||
| whiteknight | Infinoid: how often does dalek scrape that projects page? | ||
| "Modules" page* | 15:45 | ||
| Infinoid | it polls once per hour, I think | 15:46 | |
| NotFound | Impatience the Dark Side is ;) | 15:47 | |
|
15:47
Andy joined
15:48
Andy joined
|
|||
| dalek | nxed: r401 | julian.notfound++ | trunk/winxedst1.winxed: tiny optimization of const statements in stage 1 |
15:57 | |
| redbrain | Coke: yeah its alot of work i think but its interesting :) | 16:03 | |
|
16:08
ruoso joined
|
|||
| darbelo | dukeleto: ping | 16:12 | |
|
16:19
davidfetter joined
16:27
hercynium joined
16:31
allison joined
16:33
cotto_working joined
16:46
PacoLinux joined
|
|||
| darbelo | whiteknight: ping | 16:50 | |
| whiteknight | darbelo: pong | 16:51 | |
| darbelo | I tried to build parrot-linear-algebra and it failed with sh: ./probe: not found | 16:52 | |
| whiteknight | hmm... weird | ||
| darbelo | Is the repo missing a file? | ||
| Or should I stay away from the setup.pir file? | 16:53 | ||
| whiteknight | how did you try to build it? | ||
| setup.pir is the way to do i | |||
| it | |||
| darbelo | "parrot setup.pir" | ||
|
16:53
cotto_working joined
|
|||
| whiteknight | you're on FreeBSD, right? | 16:53 | |
| darbelo | OpenBSD | 16:54 | |
| whiteknight | okay, you probably need to add configuation settings o system_linker_settings in setup.pir | ||
|
16:54
theory joined
|
|||
| darbelo | If you point me in the right direction I can probably do that. | 16:55 | |
| whiteknight | does OpenBSD have ldd? | ||
| darbelo | Yep. | 16:56 | |
| whiteknight | okay, so you just need to figure out the install path where cblas or atlas is on your machine | ||
| /usr/lib/libblas.so or /usr/lib/atlas/libcblas.so are the paths i have see in linuxland | 16:57 | ||
| darbelo | And incorporate to system_linker_settings? | ||
| whiteknight | exactly | 16:58 | |
| it should be straight-forward, I just wasn't sure what "$S0 = sysinfo 4" is on a BSD system | |||
| darbelo | Oh, crap. I didn't have cblas on this box. | 17:00 | |
| darbelo facepalms | 17:01 | ||
| Still, I don't know where that reference to 'probe' came from. | |||
| whiteknight | yeah, that's a weird one | ||
|
17:02
plobsing joined
|
|||
| darbelo | And, we should move the place where the lib-detection takes place. | 17:02 | |
|
17:03
particle joined
|
|||
| darbelo | Right now that happens even if I try parrot "setup.pir update" | 17:03 | |
| eh "parrot setup.pir update" | |||
| plobsing | am I correct in thinking that RPA shift/unshift are going to suck for the forseable future? | 17:06 | |
| whiteknight | plobsing: yes | ||
| plobsing: but take a look at github.com/Whiteknight/parrot-data-structures/ | |||
| started a new project with higher-performance single-purpose PMCs | 17:07 | ||
| plobsing | whiteknight: then we should find all places in core that use RPA and make sure they don't shift/unshift | ||
| I just did it for freeze/thaw in r43716. | |||
| whiteknight | plobsing: that is probably a good idea | ||
| NotFound | Emmmm... main args | 17:10 | |
| whiteknight | plobsing: freeze/thaw use an ImageIO PMC, not an RPA | 17:11 | |
| NotFound | Any program that uses GetOpts use shift. | ||
| darbelo | That has an RPA inside. | ||
| whiteknight | darbelo: it doesn't need to. It's encapsulated, we could fill it with whatever we want, eventually | ||
| NotFound | You shift argv before passing it to GetOpts | 17:12 | |
| darbelo | whiteknight: It has an RPA now ;) | ||
| plobsing | whiteknight: it doesn't make sense to have ImageIO manage it's own list when we have a type whose responsibility is to manage lists | ||
| whiteknight | plobsing: we have a type whose responsibility is to provide maximum flexibilities in managing all sorts of lists | ||
| darbelo | But, in my opinion, ImageIO has one list too many. | 17:13 | |
| whiteknight | when ImageIO only needs a very specific type of list | ||
| plobsing | whiteknight: last time we wanted tunable lists like that, we wound up with src/list.c | ||
| darbelo: which is the one list too many? | 17:14 | ||
| darbelo: are you talking about merging todo and id_list? | |||
| whiteknight | plobsing: list.c was the wrong approach, but was not born from a bad idea | ||
| sparse arrays do have some benefit, and arrays implemented as linked-lists have benefit | |||
| plobsing | darbelo: I've considered that. The visit loop would have to change and would likely not be compatible with the freezing logic. | 17:15 | |
| darbelo: if you separated the freezing and the thawing, you could do that | |||
| whiteknight | improved shift/unshift/push/pop performance in exchange for worse direct indexing and higher memory requirements | ||
| plobsing | whiteknight: my main point is that an external library doesn't help core usages | 17:17 | |
| darbelo | plobsing: I've been thinking about that. And separating freeze from thaw looks like a win all around. | ||
| But doing that right probably means adding a vtable. | 17:19 | ||
| dalek | rrot: r43716 | plobsing++ | trunk/src/pmc/imageio.pmc: use push/pop with imageio todo list instead of shift/unshift. |
17:21 | |
| Coke | 100 what? | 17:22 | |
| purl | 100 is the reference | ||
| plobsing | 100 times | ||
| Coke | ah. 100x would have been more clear to me. | ||
| plobsing | 17s becomes 0.12s for me | ||
| Coke | might be worth adding a note to RPA's pod docs about that. "if you're using this as a stack/queue/blah, prefer <foo> over <bar>" | 17:23 | |
| NotFound | I like the C++ approach: you have vector, deque and list, choose what's better to each task. | 17:26 | |
| darbelo | NotFound++ | 17:27 | |
| Coke | huh. I'd never heard of deque before. | ||
| Infinoid | queue? | 17:28 | |
| purl | queue is FIFO | ||
| NotFound | You almos never use it directly, but is the default container for stack and queue. | ||
| Supposedly it has not bad direct access and not bad pop and shift. | 17:29 | ||
| In practice, check your standard library implementation. | 17:30 | ||
| Coke | certainly that 100x speedup is a good reason to either 1) fix RPA or 2) split it out. | 17:31 | |
| whiteknight | plobsing: the external library does help if it is really good and we can make the case to merge it into trunk eventually | 17:34 | |
| Coke | certainly easier to prototype stuff out of core. | 17:35 | |
| whiteknight | exactly | ||
| Coke | I wonder how much of a speed up partcl could get if it were smarter about its RPA usages. | ||
| (ditto nqp-rx) | |||
| NotFound | "This may seem like a joke, but it's not. The US Patent and Trademark Office will not accept patent filings faxed in if they arrive upside down. That's right, the home of innovation of the federal government is incapable of rotating an incoming fax file, whether electronically or on paper." | 17:39 | |
| Ups, wrong channel. | |||
| Coke | ... still, funny. | 17:44 | |
| plobsing | whiteknight: it all depends on when eventually is? 2.3? 3.0? my grand children might see it? | 17:46 | |
| whiteknight | true | ||
|
17:49
ruoso joined
17:53
cognominal joined
|
|||
| plobsing | what's the best way to get a stacktrace of everywhere RPA.shift or RPA.unshift is called in the testsuite? | 17:58 | |
| Coke | ... a stacktrace? | ||
| plobsing | I'm looking for internal usages. I don't really care about calls from PIR, so I plan to filter out calls from src/ops/* | 17:59 | |
| Coke | if you don't care about PIR or PASm, the number of times it's invoked should be pretty miniscule. | ||
| (explicitly) | 18:00 | ||
| plobsing | this morning it was being called in freeze/thaw. I'm looking for similar cases. | 18:01 | |
| low hanging fruit | |||
| Coke | I don't know an easy way to do that, no. | ||
| If I were looking for someone, I'd probably ping chromatic or cotto. | |||
| dngor | Anyone still have svn projects they'd like to convert to git? | 18:07 | |
| cotto_working | Parrot. | 18:08 | |
| cotto_working ducks | |||
| Coke wonders why opensolaris.org's website looks awful in every browser except firefox. | 18:09 | ||
| dngor | Parrot... ducks... what next? Flamingos? | ||
| szbalint | crocoduck | ||
| dngor | I've got snerp vortex working on a single repository (2700 commits) reasonably well (diff -r vs. svn checkout is identical) and somewhat fast (800 seconds to convert). | 18:10 | |
| It's only a single test case, though. | |||
| szbalint will probably convert $work repo to git this month | 18:11 | ||
| dngor | If people have some idle time to evaluate it, I'd love some bug reports. | ||
| dukeleto | 'ello | 18:14 | |
| cotto_working | hi dukeleto | 18:15 | |
| dukeleto | are we talking about converting to git again? | ||
| dngor | Oh, you know what, I'm in the wrong channel. I recently re-sorted my windows. | 18:16 | |
| Epic ww fail. Sorry. | |||
| dukeleto | dngor: :) | ||
| szbalint | pretty funky :) | 18:17 | |
| dngor wanders one window over to #perl. | |||
| szbalint | anyone attending FOSDEM from here this weekend btw? | ||
|
18:19
joeri joined
18:20
ruoso joined
18:23
payload joined
|
|||
| whiteknight | plobsing: locally, modify the VTABLE_shift() macro to print __FILE__ and __LINE__ to stderr | 18:45 | |
| plobsing | whiteknight: that's too coarse, that gets all shifts. I could just grep for VTABLE_shift, but there are legitimate places to shift. | 18:46 | |
| whiteknight | plobsing: how many types do you suspect are using shift/unshift? | 18:47 | |
| cotto_working | You could further modify it to only print based on vtable->base_type. | ||
| darbelo | dukeleto: ping | 18:48 | |
| whiteknight | #define VTABLE_shift(i, p) (fprintf(stderr, ((p->vtable->type == enum_class_ResizablePMCArray)?("%s, %d"):("")), __FILE__, __LINE__), p->vtable->shift(i, p)); | ||
| plobsing | cotto_working++ whiteknight++ | ||
| whiteknight | It's been a long time since I used that comma operator, so I might have put things in the wrong order | 18:49 | |
|
18:57
kurahaupo joined
|
|||
| Coke | purl? | 19:19 | |
| purl | yes, Coke? | ||
|
19:20
mikehh joined
19:28
hercynium joined
|
|||
| dukeleto | darbelo: pong | 19:47 | |
| szbalint: davidfetter will be at FOSDEM | 19:48 | ||
| darbelo | dukeleto: I'm thinking of starting a branch to improve our cross-compilation capabilities? Would you be willing to be a guinea pig? | 19:54 | |
| dukeleto | darbelo: yes | 19:55 | |
| darbelo++ | 19:57 | ||
| darbelo: i am doing research on my new BUG toy | |||
| darbelo: how much do you know about OpenEmbedded? | |||
| darbelo | dukeleto: Not much. Skimming their site now. | 20:03 | |
|
20:04
chromatic joined,
kurahaupo1 joined
|
|||
| szbalint | dukeleto: oh, he's even giving a postgres talk, excellent :) | 20:11 | |
|
20:14
clinton joined
|
|||
| dukeleto | darbelo: i have an embedded linux device that runs PokyLinux, which is a distro of OpenEmbedded | 20:23 | |
| Coke | Anyone here using Padre? | 20:24 | |
| (for working on parrot?) | |||
| dukeleto | szbalint: yes, and he will be telling people about PL/Parrot as well | ||
| szbalint | excellent :) | 20:29 | |
|
20:30
davidfetter joined
|
|||
| dalek | tracwiki: v24 | kurahaupo++ | ArrayTasklist | 20:39 | |
| tracwiki: trac.parrot.org/parrot/wiki/ArrayTa...ction=diff | |||
|
20:40
bluescreen joined
|
|||
| dalek | rrot-linear-algebra: a050c24 | Whiteknight++ | setup.pir: editor auto-removed some whitespace |
20:43 | |
| Coke | array tasklist shows "depreation of array" as a task item; already ripped out. | 20:47 | |
| chromatic | Parrot VM: Can't stat ext/nqp-rx/nqp-rx.pbc, code 2. | 20:54 | |
| whiteknight | oh that looks wonderful | 20:55 | |
| nqp-rx didn't get deleted from the repo, right? | |||
| chromatic | No Makefile in that directory either. | ||
| ... which isn't a problem. | 20:57 | ||
| Maybe I should use parrot-nqp.pbc instead. | 20:58 | ||
| whiteknight | does the new nqp build in the repo, or are the .pbc files just dumpd there? | ||
| Tene | whiteknight: build in the repo. | 20:59 | |
| whiteknight | ok | 21:02 | |
| chromatic | NQP generated code does a fair amount of RPA unshifting for exception handlers. | ||
| It doesn't lead to array resizing though; one RPA and one EH per invocation, so far. | 21:04 | ||
| cotto_work | easy karma if someone feels like ripping out the malloc return value checks from src/pbc_merge.c | 21:30 | |
| The malloc functions already handle failed allocations. | 21:31 | ||
| chromatic | I have a fresh master checkout. | ||
|
21:33
bluescreen joined
|
|||
| chromatic | make: *** No rule to make target `include/parrot/list.h', needed by `src/string/api.o'. Stop. | 21:36 | |
| Hm. | |||
| Coke | wasn't that ripped out recently? checking... | 21:37 | |
| cotto_work | The list code was removed recently with the Array excision iirc. | ||
| Coke | You would think someone would have noticed that by now, though. | 21:38 | |
| cotto_work | You'd think. | ||
| chromatic | It's strange. | ||
| Let me reconfigure. | 21:39 | ||
| dalek | rrot: r43717 | chromatic++ | trunk/src/gc (3 files): [GC] Don't run a full mark and sweep when a constant pool is out of free benchmarks. |
21:40 | |
| Coke | WFM with a fresh checkout. | ||
| purl | benchmarks are like college lab reports....often fudged to achieve the desired results | ||
| Coke | you're using git-svn, yes? | ||
| chromatic | Yes, like God and queen intended. | ||
| Coke | no, they meant for git. | 21:41 | |
| git-svn is evil. =-) | |||
| chromatic | I'm no royalist. | ||
| God and Queen (without Paul Rodgers) want me to use git. | 21:42 | ||
| The monarchy... well, they're pragmatic. That's the difference between established positions of power and artists who play the piano and sing high. | |||
| A reconfigure and rebuild fixed things. La plus ca change... | 21:43 | ||
| dukeleto | did someone say git? | 21:44 | |
| and yes, git-svn is evil | |||
| i have found out that my embedded hardware is a "Freescale i.MX31 ARM-based processor" | 21:45 | ||
| darbelo | dukeleto: /me thinks he know how to enable cross-building. | 21:46 | |
| dukeleto | darbelo: go ONNNNNNNN | ||
| darbelo | dukeleto: does your new hardware have perl ported to it? | ||
| dukeleto | darbelo: yes | ||
| darbelo | Then we just have to convince Configure to ingore what the perl used to run is tells it and to feed it data from the other perl. | 21:48 | |
| dukeleto | darbelo: interesting | ||
| darbelo: quite a nice little trick | |||
| darbelo | That and a medium sized hints file should give us a makefile that can cross build most of the c code. | ||
| I guess we might be alble to get as far as miniparrot on that. | 21:49 | ||
| dukeleto | this boot loader gets a prize for having a cool name: en.wikipedia.org/wiki/Das_U-Boot | ||
| darbelo: sounds like a plan. do you want to make a branch for it? | |||
| cotto_work | chromatic++ | ||
| chromatic | Where'd dalek go? | ||
| cotto_work | bot vacation | 21:50 | |
| chromatic | bot trek | ||
| cotto_work | probably to 01 | ||
| dukeleto | botbattical | ||
| chromatic | walkabot | 21:51 | |
| darbelo | dukeleto: I'll bran myself when I get some code written. | 21:53 | |
| s/bran/branch/ | |||
| dukeleto | darbelo: sounds good! let me know if you need testing | 21:56 | |
| dalek | rrot: r43718 | chromatic++ | trunk/src/pbc_merge.c: [pbc_merge] Removed malloc() checking, because libparrot's malloc() wrappers |
||
| GeJ | Good morning everyone. | 22:03 | |
| dukeleto | GeJ: o hai | 22:08 | |
|
22:22
Whiteknight joined
|
|||
| Whiteknight | I would like to write a parrot plugin for xchat\\ | 22:23 | |
| darbelo | I don't use xchat, but will offer moral support to the endeavor ;) | 22:25 | |
|
22:29
elmex joined
|
|||
| dalek | nxed: r402 | julian.notfound++ | trunk/winxedst1.winxed: time and floattime predefs in stage 1, quick fix for float * operator |
22:33 | |
|
22:36
patspam joined
|
|||
| dalek | nxed: r403 | julian.notfound++ | trunk/examples/opengl.winxed: opengl example |
22:38 | |
| japhb | NotFound++ # OpenGL examples, w00t! | 22:50 | |
| dalek | tracwiki: v7 | cotto++ | Modules | ||
| tracwiki: typo fix | |||
| tracwiki: trac.parrot.org/parrot/wiki/Modules...ction=diff | |||
| NotFound | japhb: just one more incarnation of the infamous triangle ;) | ||
| japhb is considering porting his old Perl 5 Doom Classic level viewer to Parrot. I was thinking PIR or NQP, but maybe Winxed is dying for some OpenGL hackery .... | 22:51 | ||
| NotFound | I'll support such noble goal | 22:52 | |
| japhb is currently reading a code review of Carmack's recent "official" port of Doom Classic to the iPhone. | 22:53 | ||
| NotFound | Looks like Doom is on the wave right now, there is even an iphone port. | ||
| japhb | :-) | ||
| dukeleto | wowzers | ||
| NotFound | japhb: I've readed it this morning. | ||
| japhb loves the fact that Carmack has been respecting the spirit of his GPL release by starting all his recent iPhone ports from community releases (iPhone Doom Classic is I believe based on prBoom, for example, and iPhone Wolfenstein 3D is based on Wolf Redux), and then re-releasing the upgraded source .... | 22:55 | ||
|
22:56
joeri left
|
|||
| tewk | What can't RPA just have a start pos and a length field and be a circular buffer that only moves data when it overflows, That should support shift, unshift, pop and push in constant time. | 22:56 | |
| What does perl5 do internally? its fast right? | 22:57 | ||
| Whiteknight | circular buffers can't be easily resized | 22:59 | |
| japhb | Whiteknight: why not? | ||
| tewk | Whiteknight, sure they can, its just two memcpys | ||
| Whiteknight | "easy" | ||
| that's worse then current wit one memcpy | 23:00 | ||
| japhb | A little pointer fiddling and an extra memcpy do not argue against a vastly faster implementation. | ||
| And the memcpy is amortized well if you do exponential resizing. | |||
| (or heck, any decent resizing scheme) | 23:01 | ||
| Plus, you can save a memcpy invocation by simply checking whether one of them is zero length. | |||
| tewk | two memcopies are performance bounded by total memory moved not by two vs one function calls | ||
| japhb | What tewk said | ||
| Whiteknight | memcpy tends to be higy optimized. biggest part of it is the call and setup | 23:02 | |
| japhb | Speaking of performance improvements, | ||
| Whiteknight | fewer calls == less overhead == better performance | ||
| tewk | no the malloc before the memcopies is the bottle neck | ||
| Whiteknight, thats not true | 23:03 | ||
| japhb idly wonders if there's a way to reserve a register for interp. Might be a win on 16+ register arches. | |||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32058), fulltest) at r43718 - Ubuntu 9.10 amd64 (g++ with --optimize) | ||
| darbelo | japhb: There is no portable way to do anything to registers ;) | 23:04 | |
| chromatic | Any decent compiler should already realize that where it matters. | ||
| tewk | performance on modern processors is almost always a function of cache misses not ops. | ||
| japhb | Whiteknight, I agree with generally trying to save calls, but in this case as I said most of the time one of the memcpys can be avoided anyway. | ||
| chromatic, I disbelieve that "any decent compiler" will notice that we use a param called 'interp' freaking everywhere and realize it ought to be a register, and stop thrashing the stack with it. | 23:05 | ||
| Whiteknight | can't be avoided in a threade app | ||
| darbelo | japhb: it's always called 'interp' but it's not allways the same interp ;) | 23:06 | |
| Whiteknight | true, especially in interp cloning routines | ||
| japhb | Whiteknight, there's no reason that reserving a register would be a problem with a threaded app, because the thread switch will save and restore all registers. It *would* be a problem if it was a memory global. | 23:07 | |
| Whiteknight | what we could do to save effort is set the compiler to use fastcall for calls by default. | ||
| japhb | Interp cloning would be a special case. | ||
| Whiteknight | but then we would need to add _declspec(cdecl) to PARROT_EXPORT | 23:08 | |
| that would save on stack thrashing | |||
| chromatic | If a compiler can't recognize that the first parameter passed to a function gets used as the first parameter for every sub function call, it's not a decent compiler. | ||
| tewk | x86_64 calling convetions already pass it in a register all the time. Just wait for 32bit to die. | ||
| japhb | chromatic, fair enough ... but we're talking about gcc (which fails to recognize all sorts of things) and msvc (which still can't manage to update to a C spec over a decade old) | 23:09 | |
| Whiteknight | tewk: when's the heat death of the universe again? | ||
| chromatic | I don't recall calling GCC or MSVC particularly "decent", no.... | ||
| Whiteknight | I like ICC, good optimizations (on some platforms) | ||
| I'm also liking clang when I use it | 23:10 | ||
| japhb | 32-bit never dies, it just moves downmarket (and gains orders of magnitude more devices, sigh) | ||
| tewk: ooh, I hadn't read a calling conventions spec since the dark ages. Didn't realize x86_64 did the "first 4 params in registers" optimization. Very nice. | 23:12 | ||
| Whiteknight | I'm surprised I can't find any 16-bit PCs at best buy | ||
| darbelo | dukeleto: nopaste.snit.ch/19478 | 23:13 | |
| chromatic | That's because they haven't upgraded their sales droids from 8-bit. | ||
| japhb | They're all over in the "truly embedded" space ... but at this point I think a million transistors (a 486) is so freaking small that you're completely swamped by packaging costs, so why not go 32-bit? | ||
| Hell, a modern Intel chip contains a 486-equivalent embedded in it just to compute power saving states. Cause when a million transistors is .1% of the die, why not? | 23:14 | ||
| darbelo | japhb: Actually, that's what happening. The embedded market is abandoning 8-bit and 16-bit and going to ARM this days. | ||
| japhb | darbelo, nodnod. I knew that, I just worded my comment poorly. | 23:15 | |
| chromatic | I wonder if we could shove __attribute__((fastcall)) in the PARROT_INTERP macro. | ||
| No, that's not where it goes. | |||
| japhb | I still have a few freaky friends in my Perl Mongers group (dominated by EE types) that still do PIC-controlled devices, but I think they just do it for the retro fun. | 23:16 | |
| darbelo | japhb: Well, I was part of an embedded-control project two years back that was built around an 8-bit uC. Not for the retro fun, but becouse of the costs. | 23:17 | |
| tewk | Also I'm guessing the microcode on x86 32bit cpus tears apart stack parameter passing instructions and highly optimizes them, but I may be wrong. | ||
| japhb | darbelo, reduction in board traces and layers? | 23:18 | |
| darbelo | Not really, it was a thorougly dumb device in a small control loop with no need for speed. And most of the sensors were off-board. | 23:20 | |
| The most coplicated part in it was a small 64x128 pixel screen. | 23:21 | ||
| japhb has visions of 8-by-8 sprite blocks | |||
| chromatic | We could try regparm(3). | 23:22 | |
| darbelo | You can't go cheaper than a 8051-alike with those constraints. | ||
| japhb | chromatic, not in my manpages ... what OS? | 23:23 | |
| japhb wonders if Debian decided not to include one of the base manpages again | |||
| chromatic | GCC should have it since at least 3.0. | 23:24 | |
| It's a function attribute, not a syscall. | 23:25 | ||
| japhb | ah. The (3) confused me. | 23:28 | |
| chromatic | Yeah, I realized that as soon as you asked. | ||
| It segfaults nicely, at least. That indicates that *something* is working. | 23:34 | ||
| dalek | rrot: r43719 | darbelo++ | trunk (3 files): Make the used hints file overridable on the Configure.pl command line. |
||
| chromatic | Hm, that naive patch made things slower. | 23:41 | |
| japhb | Maybe gcc is defaulting to doing something similar already? | 23:45 | |
|
23:47
plobsing joined
|
|||
| cotto_work | Whiteknight, your blog post has an unusually entertaining typo: "PriorityPMCQueue: This is a queue type where each element has an ass" | 23:53 | |
| Whiteknight | I copy+pasted that from wikipedia :) | 23:54 | |
| cotto_work | That doesn't make it true. | ||
| Whiteknight | lies! | 23:55 | |
| cotto_work | I know of very few queue ATDs that have asses. | ||