|
Parrot 3.2.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot is accepted for GSoC 2011! Student application deadline is Apr 8 Set by moderator on 27 March 2011. |
|||
|
00:02
dngor left
00:06
whiteknight joined
|
|||
| whiteknight | good evening, #parrot | 00:12 | |
| bubaflub | evening whiteknight | 00:18 | |
| whiteknight | hello bubaflub | 00:19 | |
|
00:29
mikehh left
|
|||
| dalek | rrot: 6853f88 | petdance++ | include/parrot/compiler.h: close off unused the way clang likes it |
00:37 | |
|
00:42
mikehh joined
00:51
mikehh left
00:59
loufoque joined
|
|||
| loufoque | hi, i've looked at this document and was astonished www.parrot.org/dev/irc-logs | 01:00 | |
| oops wrong link | |||
| docs.parrot.org/parrot/latest/html/...s.pod.html | |||
| normalization forms apply to combining character sequences, not grapheme clusters. | |||
| therefore this NFG thing is just weird | 01:01 | ||
| does it store "\\r\\n" as an entry in the table too? | 01:02 | ||
| sorear | It doesn't do any of that yet. | 01:04 | |
| Most of the PDDs are "wishful thinking" | |||
| *yet (if ever) | |||
| whiteknight | NFG was implemented as a GSOC project last year, but never merged | 01:05 | |
| loufoque: \\r\\n would probably not be in the table | |||
| loufoque | plus dealing with variable-width encodings does not necessarily require expensive lookaheads, you can just work at the code point or even code unit level and check the match lies on the right boundaries, which is pretty cheap. | ||
|
01:06
contingencyplan left
|
|||
| loufoque | \\r\\n is a single grapheme though | 01:06 | |
| whiteknight | loufoque: I don't remember the details, but each grapheme was treated as a tuple with the character and combiners | ||
| The benefit is that we gain linear-time lookups by moving the grapheme complexity to the lookup table | 01:07 | ||
| loufoque | if you want to search for "foo" in "foo<some_combining_character> bar foo baz" you could just look for foo, test if it lies on the boundaries you want, and if it doesn't discard the match and keep searching. So you'd find the first foo but discard it, but then you find the second one. This is basically just adding a boundary check (which is constant-time) as part of your comparison criterion. And everything can be done at the byt | 01:15 | |
| e level. | |||
| just an idea, I don't know why it wouldn't be linear anyway | |||
| dalek | sella: 9fff443 | Whiteknight++ | src/prototype/Protoclass.winxed: Add in a new mechanism for handling prototypes using a more JavaScript-like model. The basic idea is based on code posted by NotFound++, with a few additions like invokability for sub-like objects |
01:16 | |
|
01:18
dngor joined
|
|||
| whiteknight | loufoque: for details, you probably want to talk to darbelo. He implemented the NFG thing for GSoC last year | 01:19 | |
|
01:20
estrabd left,
estrabd joined
|
|||
| plobsing | loufoque: I'm not sure of the details, but it seems your scheme would not properly match characters with multiple combiners in different orders | 01:28 | |
| loufoque | plobsing: yes, the strings need to be normalized of course | 01:29 | |
| or at least canonically ordered | 01:30 | ||
| yes they need to be normalized, be it NFC or NFD | |||
| plobsing | which requires a preprocessing pass anyways. might as well build a table of characters. | ||
| loufoque | yes, you can, but the NFG system isn't necessarily necessary, nor is it necessary the best solution, nor is it a silver bullet that solves everything | 01:37 | |
| whiteknight | no normaliztion form solves every problem | 01:38 | |
| but NFG is an interesting tool to use, especially in a VM which commonly does operations on graphemes | 01:39 | ||
|
01:41
whiteknight left
|
|||
| cotto | bacek, ping | 01:47 | |
|
01:48
bacek left
01:59
bacek joined
|
|||
| cotto | aloha, clock? | 02:03 | |
| aloha | cotto: LAX: Sat, 19:03 PDT / CHI: Sat, 21:03 CDT / NYC: Sat, 22:03 EDT / UTC: Sun, 02:03 UTC / LON: Sun, 03:03 BST / BER: Sun, 04:03 CEST / TOK: Sun, 11:03 JST / SYD: Sun, 12:03 EST | ||
| dalek | rrot: 49b5e9d | petdance++ | include/parrot/api.h: Added PARROT_ASSERTS_ON to tell if assertions are on |
02:06 | |
| rrot: 9cb8686 | petdance++ | src/gc/gc_gms.c: quieting unused args. |
|||
| soh_cah_toa | i just wanna make sure...we don't use svn anymore, right? | 02:18 | |
| cotto | soh_cah_toa, not for parrot. The languages repo is still svn. | 02:19 | |
| soh_cah_toa | languages repo? never heard about that before | ||
| cotto | languages used to live in the main repo. They were kicked out of the nest a while ago. | 02:20 | |
| soh_cah_toa | alright. well, i was just just readin the GSoCersStartHere wiki and it still mentioned svn. i was gonna replace it w/ git but i wanted to make sure first | 02:21 | |
| cotto | go ahead | 02:23 | |
| soh_cah_toa++ | |||
| soh_cah_toa | alright. btw, how long after i email the contributions cla can i get commit access? | ||
| b/c i have some changes i'd like to submit by tomorrow | 02:24 | ||
| cotto | soh_cah_toa, you can always fork on github | 02:25 | |
| we love pull requests | |||
| CLAs need to be verified and you need to have someone propose that you get a commit bit at a #ps meeting. | 02:26 | ||
| soh_cah_toa | yeah i did that. i'm gonna need some help w/ that tomorrow | ||
| bubaflub | soh_cah_toa: the pull request? | 02:27 | |
| soh_cah_toa | well maybe i can figure it out now...so i've made a pull request made changes. once i commit, what's my next step? | ||
| cotto | have you read help.github.com/pull-requests/ ? | 02:31 | |
|
02:32
dafrito left
|
|||
| soh_cah_toa | nopaste, but i think that is what i'm looking for | 02:32 | |
| cotto | lawl | ||
| soh_cah_toa | agh...did it again | ||
| cotto | your client might be configured to autocomplete words ending with a comma | 02:33 | |
|
02:33
plobsing left
|
|||
| cotto | istr something similar with xchat | 02:33 | |
| soh_cah_toa | yeah | ||
| are pull requests any different than branches? | 02:34 | ||
| correct me if i'm wrong but it looks like pull request are specific to github, not git | |||
| cotto | soh_cah_toa, right | 02:35 | |
| soh_cah_toa | so pull request == branch? | 02:36 | |
| cotto | If you think you'll make more than one pull request, it's good practice to have one branch per pull request | ||
| no | |||
|
02:37
dafrito joined,
woosley joined
|
|||
| soh_cah_toa | okay i think i got it now...a pull request is like an "almost commit". it show everybody what i'm going to change. then one of you guys makes the actual commit. close? | 02:41 | |
| cotto | you commit and push to a clone of parrot.git, use github to submit a pull request for whatever commits you want pulled, then we'll review and commit/push to parrot/parrot | 02:42 | |
| soh_cah_toa | alright i get it | 02:44 | |
| cotto | great, because I have to take off in a few minutes | ||
| soh_cah_toa | okay | ||
| bubaflub | soh_cah_toa: yes, i just merged in a pull request for cardinal earlier today | 02:55 | |
| soh_cah_toa: basically, you branch, hack away, and then when you do a pull request that's a signal to parrot devs that this is good to merge | |||
| soh_cah_toa: a parrot dev can come in and take a look, comment, and merge your commits | |||
| soh_cah_toa | okay, so when i issue a git commit, it get pushed to the clone i made w/ the pull request? | 02:56 | |
| Tene | soh_cah_toa: "pull request" is a pretty normal git workflow, it's just that github has specific UI around the process. The kernel devs use pull requests, just done through email instead of a web UI. | 03:03 | |
| soh_cah_toa | okay. that's for general changes though, right? if i fix something in a trac ticket, i just submit a patch by attaching it to the ticket. right? | 03:06 | |
| Tene | soh_cah_toa: that works fine too. Simple things aren't much harder to deal with through patches. It's for the complicated stuff involving multiple commits where working with it via git natively is a big win. | 03:07 | |
| soh_cah_toa | okay. b/c i have two things to fix. i have some changes i've made to some docs and i have some changes to fix ticket #236 | 03:08 | |
| should i put everything in one pull request or separate or what? | 03:09 | ||
| ooops, not #236 | |||
| #1215 i think | |||
| bubaflub | soh_cah_toa: two separate commits, if you please | 03:12 | |
| soh_cah_toa: that way it's easier to revert if someone needs to | |||
| soh_cah_toa: not saying that we will, but make the commits logical chunks of work | |||
| soh_cah_toa | i figured since they address two separate issues | ||
| bubaflub | soh_cah_toa: exactly. they aren't related to each other, can be applied separately | ||
| soh_cah_toa | right | 03:13 | |
| bubaflub | soh_cah_toa: and the main idea is that we never break the build on the master branch | ||
| soh_cah_toa | right | ||
| bubaflub | soh_cah_toa: for bigger work, open up a new branch and hack away on that. when you're done, send a pull request | ||
| soh_cah_toa: for small work, patches on tickets work just fine | |||
| soh_cah_toa | alright, i think i understand | 03:14 | |
| bubaflub | soh_cah_toa: great. and once you get your CLA in, all of this won't matter... | ||
| soh_cah_toa: you can just commit directly | |||
| Coke finally catches up | 03:15 | ||
| soh_cah_toa | oh okay. that's just for people who aren't necessarily apart of the dev team yet who'd like to submit various changes | ||
| after the cla, you become a "trusted member" | 03:16 | ||
| cool | 03:18 | ||
| bubaflub | soh_cah_toa: bingo | ||
| soh_cah_toa | i always liked being a lone coder but i'm actuualy finding the whole process of collaborating w/ others to be pretty neat | 03:20 | |
| i mean, i've read books on git before but i never really had a use for it. now i do and it all makes sense. very effecient and organized. i like it | 03:21 | ||
| bubaflub | soh_cah_toa: at work, every commit i make is reviewed by another coder | 03:26 | |
| soh_cah_toa: it's real nice - learn lots | |||
| soh_cah_toa | bubaflub: what kind of software do you develop? | 03:28 | |
| bubaflub: at work, i mean | 03:29 | ||
| bubaflub | soh_cah_toa: web development stuff in perl | ||
| soh_cah_toa: which is to say all kinds of things - jQuery, HTML, CSS, Catalyst, DBIx::Class | |||
| soh_cah_toa | bubaflub: wow, i didn't think perl was used much as an enterprise language | 03:30 | |
| bubaflub: i'm jealous. i wish i had a job writing perl | 03:31 | ||
|
03:33
woosley1 joined
03:34
woosley left
|
|||
| bubaflub | soh_cah_toa: it ain't as sexy as other hip languages | 03:35 | |
| soh_cah_toa: but i love it | |||
|
03:35
krunen left
|
|||
| soh_cah_toa | yeah, perl's my little baby | 03:36 | |
|
03:41
Khisanth left
|
|||
| bubaflub | goodnight #parrot | 03:46 | |
| soh_cah_toa | see ya | ||
|
03:46
bubaflub left
03:47
plobsing joined
03:51
Khisanth joined
|
|||
| dalek | tracwiki: v6 | soh_cah_toa++ | GSoCersStartHere | 03:55 | |
| tracwiki: Originally only meant to remove svn references. Ended up editing the whole thing. Added a few links, though I don't think the mailto link are working. No biggie. | |||
| tracwiki: trac.parrot.org/parrot/wiki/GSoCers...ction=diff | |||
| tracwiki: v7 | soh_cah_toa++ | GSoCersStartHere | 04:11 | ||
| tracwiki: Fixed mailto links. Also added link to GSoC page which I forgot before. It's overkill, I know. | |||
| tracwiki: trac.parrot.org/parrot/wiki/GSoCers...ction=diff | |||
| tracwiki: v11 | soh_cah_toa++ | WhereIsIt | |||
| tracwiki: Added link to GitHub repository. | |||
| tracwiki: trac.parrot.org/parrot/wiki/WhereIs...ction=diff | |||
|
04:12
mikehh joined
04:14
mikehh left
|
|||
| bacek | cotto, pong | 04:18 | |
|
04:23
mikehh joined
|
|||
| dalek | tracwiki: v31 | soh_cah_toa++ | NewParrotDeveloperGuide | 04:42 | |
| tracwiki: Added some links to a few pages which I think are really important to newcomers (like me). | |||
| tracwiki: trac.parrot.org/parrot/wiki/NewParr...ction=diff | |||
| soh_cah_toa says goodnight to parrot | 04:55 | ||
|
04:55
soh_cah_toa left
|
|||
| cotto | bacek, do you think you'd have the tuits to mentor the newPOST gsoc project? | 05:37 | |
| bacek | cotto, I hope so. I even added my self to melange's "I would like to mentor this project" list | ||
| cotto | bacek, great. If you don't I can, but I think you're better qualified. | 05:38 | |
| bacek | I'll mentor it. No worries | ||
| cotto | I'll take the debugger task then. I saw on the gsoc list that a major determinant of how many slots we get is how many tasks have potential mentors. | 05:40 | |
| bacek | I think we have mentors for all valuable tasks. | ||
| cotto | I wish melange would let me sort by which tasks have mentors and which ones I've voted on. | 05:41 | |
|
05:43
edu joined,
edu is now known as Eduardow_
05:44
Eduardow left
05:45
Eduardow_ is now known as Eduardow
|
|||
| cotto | I'd like to see the parser generator and the java bytecode translator happen. | 05:48 | |
| bacek | I'm not sure about "java bytecode translator". What the point? | 05:51 | |
| cotto | interesting potential for interop | 05:52 | |
| bacek | heh. Can we have "native-to-parrot-languages" interop happened first? | 05:53 | |
| e.g. rakudo<->cardinal<->particle | |||
| cotto | touche | 05:55 | |
| Tene | I never looked closely at the java bytecode project, but did they look at jnthn's previous work on the subject? | 05:59 | |
| cotto | I pointed it out in the melange comments | ||
| seen bbantha | |||
| aloha | Sorry, I haven't seen bbantha. | ||
| Tene declines to repeat his traditional comments about interop. | |||
| cotto | That every time you've done work, the rest of us haven't shown much interest? | 06:00 | |
| Tene | cotto: it's not very useful for me to continue to be grumpy over things that happened years ago, and were entirely reasonable. I need to get over it. | 06:03 | |
| sorear | Who cares about interop? | 06:11 | |
|
06:11
Eduardow left
|
|||
| cotto | sorear, was that serious? | 06:12 | |
| My ISP filters out the sarcasm bit. | 06:14 | ||
|
06:14
Eduardow joined
|
|||
| bacek | sorear, I have another question about Grammars, NQP, Universe and everything. | 06:14 | |
| sorear | I'm not sure whether it counts as "sarcasm" or not | ||
| but I know the answer | |||
| bacek: go... | |||
| bacek | sorear, for example. I have something like (foo)(bar). How to distinguish between prefix<()>.circumfix<()> and circumfix<()>.postcircumfix<()>? | 06:16 | |
| bacek hates C... | |||
| sorear | bacek: you can't. | 06:17 | |
| the C grammar is fundamentally ambiguous with casts | |||
| I think the sensible thing to do is to check if foo is a valid type | 06:18 | ||
| bacek | sorear, sigh... Any ideas about how to workaround this? Or I have to to some "magical checks" after parse? | ||
| sorear | valid types always start with a type keyword (you know the list) or a typedef name | ||
| bacek | "foo" can be typedefed. Which mean I need full "cpp" | ||
| sorear | typedefs aren't part of cpp | ||
| #define pie typedef | 06:19 | ||
| pie int cow; | |||
| bacek | yes. But for opsc it means I have to parse all parrot headers before parsing ops bodies | 06:20 | |
| which is kinda slow and painful | |||
| sorear | C sucks like that | ||
| ever notice how slow building parrot is? gcc is suffering from the same problem you are | |||
| bacek | opsc is few orders of magnitude slower than gcc. | 06:21 | |
| looks like I have to cheat somehow and bring "well known definitions" closer to opsc... | 06:22 | ||
| next question about PASTing: what is best practise for PASTing postcircumfix/postfix without explicitly define them in Grammar? | 06:23 | ||
| e.g. "foo(bar)". is term<identifier>.postcircumfix<()> | |||
| cotto | bacek, can you restrict the C used by opsc to make parsing headers unnecessary? | ||
| bacek | postcircumfix<()> will create PAST::Op(<call>). How "term<identifier>" can find that EXPR has postcircumfix part? | 06:24 | |
| cotto, " I have to cheat somehow and bring "well known definitions" closer to opsc" | 06:25 | ||
| cotto | how clever of me | ||
| bacek | sorear, any thoughts on "postcircumifix pasting"? | 06:27 | |
| sorear | bacek: I'm not sure what you're getting at. This is what EXPR is for. | 06:28 | |
| bacek | sorear, I have to inverse order of evaluation. "foo(bar)" should produce PAST::Op(:name<foo>, PAST::Var(:name<bar>)). | 06:29 | |
| "(bar)" will create "PAST::Op(:type<call>, PAST::Var(:name<bar>))". | 06:30 | ||
| method term:identifier (for "foo" part) have to check is there is postcircumfix exists and use it. | |||
| or, let's rephrase - when I have to create PAST::Op(:type<call>) node? | 06:31 | ||
|
06:42
theory left
|
|||
| sorear | bacek: think about the function pointer case | 07:02 | |
| bacek | sorear, yes... My final goal is properly parse/past foo->bar->baz(quux) | ||
| e.g. VTABLE_foo(interp, pmc) is actually pmc->vtable->foo(interp, pmc) | 07:04 | ||
| sorear | bacek: in the general case "foo" needs to be parsed as an expression | 07:06 | |
| because it might be "int (*foo)();" | |||
| in which case you want to generate a call with args (foo) and (bar) | |||
| bacek | sorear, yes. But for now I want simple case done first. | ||
| e.g. foo->bar() should produce something meaningful | 07:07 | ||
| with postfix< -> >, postcircumfix<()> | |||
| looks like I have to overridde "method EXPR" to handle postfixish things automatically | 07:10 | ||
|
07:10
fperrad joined
|
|||
| benabik | I should be very asleep but the CAPTCHA image on parrot.org's drupal reg is broken: error on line 1 at column 14: String not started expecting ' or " | 07:12 | |
| Erm. User registration page: www.parrot.org/user/register | 07:14 | ||
| I'm gonna pass out now though. | |||
| cotto | awesome | 07:20 | |
| by which I mean the opposite of awesome | |||
| benabik, it works fine for me | 07:22 | ||
| I had to submit a form without the captcha once, but it appeared after that | 07:23 | ||
| either way, you probably don't need a parrot.org account unless you're planning on having a blog there. | 07:24 | ||
|
07:30
Themeruta joined,
NotFound left
07:50
lateau joined,
Themeruta is now known as NotFound
08:09
mj41 joined
08:43
contingencyplan joined
08:47
Eduardow left
09:46
lucian joined
10:09
lucian_ joined
10:11
lucian__ joined
10:12
lucian left
10:15
lucian_ left
10:39
ligne left
10:49
sirmacik left
11:01
whiteknight joined
|
|||
| whiteknight | good morning, #parrot | 11:08 | |
| dalek | nxed: r944 | NotFound++ | trunk/winxedst0.cpp: some refactor in stage 0 Modifier classes to make them more like its stage 1 |
11:10 | |
|
11:27
lucian__ left
11:34
gbacon joined
11:40
mtk left
|
|||
| moritz gets some rakudo segfaults on newest parrot | 11:43 | ||
| $ ./perl6 t/spec/S03-sequence/arity-2-or-more.t | |||
| 1..19 | |||
| ok 1 - arity-2 Fibonacci | |||
| Segmentation fault | |||
| nopaste | "moritz" at 192.168.1.3 pasted "segfault" (28 lines) at nopaste.snit.ch/39787 | 11:45 | |
|
11:45
lucian_ joined
11:48
mtk joined
11:51
lucian_ left
11:55
Patterner left,
Psyche^ joined
11:56
Psyche^ is now known as Patterner
|
|||
| dalek | nxed: r945 | NotFound++ | trunk/winxedst0.cpp: use an Argument class instead or raw Expr in ArgumentList in stage 0 |
11:56 | |
|
11:56
kid51 joined
12:03
lucian joined
|
|||
| dalek | tracwiki: v8 | jkeenan++ | GSoCersStartHere | 12:12 | |
| tracwiki: trac.parrot.org/parrot/wiki/GSoCers...ction=diff | |||
| tracwiki: v9 | jkeenan++ | GSoCersStartHere | |||
| tracwiki: trac.parrot.org/parrot/wiki/GSoCers...ction=diff | |||
|
12:27
lucian_ joined
12:30
lucian left
|
|||
| whiteknight | moritz: interesting | 12:38 | |
| moritz: is that a recent issue? | |||
| I mean, is it from a change today, or earlier? | |||
|
12:46
gbacon left
|
|||
| moritz | whiteknight: I don't know | 12:55 | |
| I get excessive memory usage while trying to bisect parrot (and run rakudo on top of it) | 12:56 | ||
| ie enough to OOM with my ulimit -v of 1.5G | 12:57 | ||
| NotFound | moritz: Can you try winth a non optimized build, to get a more detailed backtrace? | 12:58 | |
| dalek | nxed: r946 | NotFound++ | trunk/winxedst0.cpp: argument modifiers in stage 0 |
||
| moritz | NotFound: I'm bisecting first, but will do that too | ||
| whiteknight | shit, I hope thats not related to the imcc_compreg_pmc merge | 12:59 | |
| dalek | nxed: r947 | NotFound++ | trunk/winxed (2 files): now that stage 0 allow modifiers, use them in the non installed driver, and fix |
13:04 | |
| rrot: 99786be | Whiteknight++ | / (4 files): remove some cargo-cult nonsense in the packfile api. Since the packfile PMCs are GC-protected, use them more and don't pass raw PackFile* pointers back from the compiler |
13:06 | ||
| rrot: 9ec9ca8 | Whiteknight++ | src/ (3 files): fixup the IMCCompiler.compile method. compile method and invoke vtable return an Eval PMC. compile_file returns a PtrObj PMC for a PackFile*. this situation isn't ideal, but we need other fixes in the system before we can saneify it |
|||
| nxed: r948 | NotFound++ | trunk/winxedst1.winxed: remove the drivers helper methods in the compreg'ed compiler object that are no |
13:14 | ||
| nxed: r949 | NotFound++ | trunk/pir/winxed_compiler.pir: update installable compiler |
|||
| moritz | can somebody please run git describe --tags on HEAD and tell me the result? | ||
| NotFound | moritz: RELEASE_3_2_0-344-g9ec9ca8 | 13:15 | |
| kid51 | $ git describe --tags | 13:16 | |
| RELEASE_3_2_0-334-gabe179c | |||
| NotFound | kid51: My HEAD is more head than yours :P | ||
| moritz | thanks | 13:18 | |
|
13:19
lateau left
|
|||
| moritz | somehow my bisecting takes me to RELEASE_3_0_0-605-g19f0540 which makes no sense at all | 13:19 | |
| becasue I took 3.0.0 as the good and HEAD as the bad rev | |||
| and another copy of parrot which I used for the unoptimized build was on an old branch :/ | 13:21 | ||
| kid51 | moritz: I had a situation a few months ago where 'git bisect' took me to a revision that was *before* the older of the two revisions from which I was starting. | 13:23 | |
| So I had to conduct the bisecting entirely manually. | |||
| Is that's what | |||
| 's happening with you? | |||
| NotFound | Bisecting non lineal structures can be hard. | 13:24 | |
|
13:27
lucian_ left
13:30
lateau joined
|
|||
| dalek | rrot: 0f0dc31 | Whiteknight++ | src/pmc/imccompiler.pmc: comment out method stubs in IMCCompiler which have not been implemented yet |
13:44 | |
|
13:48
lateau left
|
|||
| moritz | kid51: seems like | 13:57 | |
| kid51: I had to skip one revision, guess it didn't like it | |||
| without --optimize, rakudo build fails for me | 14:02 | ||
| $ /home/moritz/tmp/rakudo/parrot_install/bin/parrot src/gen/perl6.pbc --target=pr \\ src/gen/core.pm > src/gen/core.pir | |||
| PackFile_unpack: Buffer length 0 is shorter than PACKFILE_HEADER_BYTES 18. | |||
| make: *** [perl6.pbc] Error 1 | |||
| RELEASE_3_2_0-330-gae4f8e1 is bad | 14:04 | ||
| dalek | nxed: r950 | NotFound++ | trunk/winxedst (2 files): refactor common parts of Return and Yield statements into a base class in stage |
14:06 | |
| moritz | on, first it segfaults during build (uoptimized), then when I restart it complains about an empty packfile | 14:12 | |
|
14:24
ambs joined
14:25
JimmyZ joined
14:47
kid51 left
14:58
particle1 is now known as particle
15:06
plobsing_ joined
15:08
JimmyZ left
15:09
theory joined
15:10
plobsing left
15:16
he left,
he joined
|
|||
| dalek | nxed: r951 | NotFound++ | trunk/winxedst0.cpp: refactor function parameters in stage 0 |
15:18 | |
|
15:23
he left,
he joined
15:24
mikehh left
15:29
woosley1 left
15:49
Eduardow joined
|
|||
| dalek | rth: eb5a59d | plobsing++ | forth/forth.pir: Exception isn't array-based |
15:54 | |
|
16:11
mikehh joined
16:26
mtk left
|
|||
| NotFound | The rakudo problem seems to be caused by a GC error: a ResizablePMCArray data pointer is NULL. | 16:42 | |
| Looks like it's been prematurely collected. | |||
| whiteknight | damnit, that's the same kind of error I was seeing in the imcc_compreg_pmc branch | 16:44 | |
| I thought I had all those instances fixed | |||
| moritz | NotFound: great that you found it. My attempts to bisect it have repeatedly killed several of my desktop applications (due to OOM) | ||
| whiteknight | well, there was actually only one bug that I thought was fixed | ||
| NotFound | moritz: I used the same backtrace you posted before, but in a non optimized build. | 16:45 | |
| Uh, no, not the same backtrace, the same core dump during the build. | 16:49 | ||
| whiteknight starts building rakudo with a fresh parrot | 16:50 | ||
| NotFound | I'm thinking about using a PMC flag in debug builds, if set emit a diagnostic message when collected. | 16:53 | |
|
16:54
ligne joined
|
|||
| whiteknight | hmm...I got a segfault during the rakudo build. I'm trying again without threads | 16:54 | |
| NotFound | whiteknight: the problem I've found is in that segfault. | 16:55 | |
| whiteknight | okay, that FIA has a NULL ->data | 16:57 | |
| and that is a problem | |||
| NotFound | FIA? Mine was in RPA. | 16:59 | |
|
16:59
ambs left,
ambs joined
|
|||
| whiteknight | Mine is an FIA that's coming out of the constants table while saving bytecode to file | 17:01 | |
| which indicates to me that a packfile is being collected somewhere | |||
| NotFound | Mine is the todo attribute in imageiosize.pmc | 17:02 | |
| Also while saving bytecode. | |||
|
17:03
ambs_ joined,
ambs left,
ambs_ is now known as ambs
|
|||
| whiteknight | I think I have it fixed | 17:23 | |
| a little bit of a hack | |||
| at this point we need to tread water until we have properly GCable packfiles | |||
| ...no, nevermind. Not fixed | 17:24 | ||
|
17:25
ambs_ joined,
ambs left,
ambs_ is now known as ambs
|
|||
| whiteknight | the packfile PMCs are all being GC registered to prevent premature collection, so that's not the problem | 17:27 | |
| cotto | ~ | 17:33 | |
| dalek | rrot: e53b5c5 | mikehh++ | src/packfile/api.c: fix codetest failure - add missing ASSERT_ARGS() |
17:42 | |
| rrot: 8869eca | mikehh++ | src/pmc/imccompiler.pmc: fix codetest failure - add missing documentation |
|||
|
17:46
dodathome joined
|
|||
| dalek | rrot: 0573725 | mikehh++ | include/parrot/compiler.h: fix codetest failure - wrap macro argument |
17:52 | |
|
18:02
he left
18:03
he joined
18:08
ambs left,
bubaflub joined,
ambs joined
18:11
ShaneC left
18:13
petdance joined
18:28
ShaneC joined
18:29
hudnix left
18:36
mj41 left
|
|||
| whiteknight | NotFound: ping | 18:47 | |
| NotFound | whiteknight: pong | 18:49 | |
| whiteknight | NotFound: this rakudo bug is definitely GC related. If I run parrot with -G I don't see segfault | ||
| NotFound: can you send me a copy of the backtrace you are seeing? | |||
| NotFound | whiteknight: the bizarre thing is that I don't see any call to destroy on that pmc. | 18:50 | |
| whiteknight | really? that is weird | ||
| cotto | which bug? | 18:51 | |
| NotFound | And more strange, supposedly in a debug build data should be set to 0xdeadbeef, not to NULL. | ||
| nopaste | "NotFound" at 192.168.1.3 pasted "Backtrace of segfault during rakudo build" (31 lines) at nopaste.snit.ch/39930 | 18:53 | |
| whiteknight | cotto: rakudo is segfaulting in random ways | ||
| cotto | great | ||
| NotFound | whiteknight: the line numbers in imageiosize are a bit shifted because of my debug statements. | ||
| whiteknight | ok | 18:54 | |
| okay, no PackFile PMCs are ever being destroyed | |||
| they are all properly registered like I thought | |||
| cotto: and it's dealing with packfiles, at least in the versions NotFound and I are seeing. I have to suspect the imcc_compreg_pmc merge | 18:55 | ||
| cotto | that's the only big thing to happen recently | 18:56 | |
| NotFound | Uhhhh..... I've inserted PARROT_ASSERT(todo->data); in ImageIOSize init_pmc... and it fails. | 18:57 | |
| whiteknight | ...wat? | ||
| that's not possible | 18:58 | ||
| I mean, it's possibe | |||
| but damnit | |||
| NotFound | Something might be wrong in some macro. | 19:00 | |
| whiteknight | this bug is absurd | 19:06 | |
| on my machine, PMC constant #2596 / 2831 is corrupted | 19:07 | ||
| but the first 2595 pmcs freeze just fine | |||
| what's that command to randomize memory layout? | 19:10 | ||
| cotto | you mean hash seed? | ||
| whiteknight | no, chromatic had a command that you could use to cause linux to randomize the memory space | ||
| so the next program run wouldn't use the same pages in the same order | |||
|
19:10
lucian joined
|
|||
| cotto | I didn't know about that. | 19:11 | |
| NotFound | whiteknight: the push_string vtables in the imageio PMC look suspicious. | ||
| benabik | whiteknight: gcc.gnu.org/wiki/Randomization ? | 19:12 | |
| NotFound | whiteknight: looks like they don't return appropiately in some branches. | ||
| whiteknight | NotFound: okay, that's weird | ||
| benabik | whiteknight: Sorry, that _dis_ables randomization, sorry. | 19:13 | |
| NotFound | The ones that say 'TODO should really be: PANIC' | ||
| whiteknight | NotFound: which PMC? imageiosize? | ||
| NotFound | whiteknight: and imageiofreeze | ||
|
19:16
he left
|
|||
| whiteknight | yes, these vtables do look...weird | 19:16 | |
| NotFound | Sometimes I think that strict structured programming, only one function entty and only one function exit points, is not such a bad thing. | 19:17 | |
| mikehh | t/examples/pod.t fails - see TT #2088 | 19:18 | |
| all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#14321) fulltest) at 3_2_0-348-g0573725 - Ubuntu 11.04 beta i386 (gcc --optimize --gc-gms) | |||
| NotFound | Those uses of return just to avoid increse indentations are weird. | ||
| plobsing_ | NotFound: what is odd about those? | ||
|
19:19
he joined
|
|||
| NotFound | Dont't know well how they are supposed to work. | 19:20 | |
| Coke | I prefer fail-early, myself. | 19:21 | |
| (rather than single-exit) | 19:22 | ||
| think of them as asserts. | |||
| plobsing_ | exactly as they do. if we are in the context of a packfile, lookup the string index. if the string index is found, push it and return; otherwise push '-1' and do the context-less string freeze | ||
| NotFound | Coke: maybe, but in a lot of places they are not failures. | ||
| plobsing_ | I'll do single-return, but only if liberal use of goto is acceptable. | 19:23 | |
| NotFound | plobsing_: then I don't understant the TODO: PANIC comments. | 19:24 | |
| plobsing_ | NotFound: ideally, the string table should be populated with all the strings the PMCs will want. we hit that code when the string table does not contain the pushed string. | 19:25 | |
|
19:25
petdance left
|
|||
| plobsing_ | and so we need to do an inefficient in-line string serialization | 19:25 | |
| whiteknight | plobsing_: I don't know if you've been following along. Rakudo is randomly segfaulting in places related to packfile serialization | 19:26 | |
| NotFound is seeing segfaults in one place, I'm seeing them in another | 19:27 | ||
| plobsing_ | the PANIC would identify this as undesirable behaviour. unfortunately, IMCC does this more than enough times to make me give up for the time being. | ||
| notably, :anon :immediate subs work this way. | |||
|
19:27
he left
|
|||
| whiteknight | I can't rule out that the segfaults are GC-related, and just happen to occur in packfile serialization code | 19:28 | |
| plobsing_ | whiteknight: I've read the backlog and am playing around with it myself. The problem goes away if you use --gc gms. | ||
| whiteknight | oh, does it? That's interesting | 19:29 | |
| I know it goes away with -G | |||
| oh yes, --gc gms works for me too | |||
| moritz | plobsing_: not confirmed. I always use --gc gms, and it still segfaults for me | ||
| mikehh | NotFound: ping | 19:36 | |
| NotFound | mikehh: pong | 19:37 | |
| mikehh | NotFound: tried to build winxed - make: *** No rule to make target `stage2', needed by `all'. Stop. | 19:38 | |
| I usually do something like cd winxed, make clean, svn update, set path to installed parrot, make all, make test1/2/3 then run some example tests | 19:40 | ||
| failed at the make all stage | 19:41 | ||
| NotFound | mikehh: try make, without all | 19:44 | |
| mikehh | NotFound: 'k | ||
| whiteknight | --gc=gms allows me to build rakudo without issue | ||
| NotFound | mikehh: yes, is a bug, forgot to change the dependeces of that target in a recent reorganization of the Makefile. | 19:45 | |
| moritz | whiteknight: it builds for me too (optimized), but segfaults at a test (see backlog) | 19:46 | |
| benabik | Are failures in extend_vtable.t known? I get tests 2, sometimes 3, 8, 11 & 13 failing. Saw a trac ticket for extend_vtable in g++, but I'm using gcc. | 19:47 | |
| (Just to add confusion to everyone backtracing rakudo... :-/ ) | 19:48 | ||
| dalek | nxed: r952 | NotFound++ | trunk/Makefile: fix 'all' Makefile target, mikehh++ |
19:53 | |
|
19:54
lucian left
|
|||
| mikehh | NotFound: 'k that works ok - managed to build and test with make, just re-built | 19:57 | |
| benabik | But I also get sporadic segfaults on rakudo. (Parrot master: --optimize --gc=gms --debugging=0 --ccflags="-DPARROT_GC_VALIDATE") | 20:01 | |
| plobsing_ | PARROT_ASSERT() appears to do nothing. It used to assert() when compiled without optimize. When did this change? | 20:19 | |
| and was it intentional | |||
| ? | |||
|
20:20
soh_cah_toa joined,
dodathome left
|
|||
| whiteknight | I thought PARROT_ASSERT was always a no-op with --optimize | 20:21 | |
| NotFound | plobsing_: I've used it a few hours ago. | ||
| plobsing_ | whiteknight: it is. I'm not compiling with optimize. Just straight 'perl Configure.pl'. Yet the disassembly doesn't lie. | 20:22 | |
| and parrot_config shows NDEBUG being used. | 20:23 | ||
| NotFound | Note that now it tries to emit a backtrace, and then the process can segfault in a completely unrelated position. | ||
| whiteknight | plobsing_: that's weird. in an unoptimized build PARROT_ASSERT should do something | ||
| plobsing_ | can someone confirm this? if this is happening, it is a *huge* problem. | 20:25 | |
| NotFound | plobsing_: I've told you, I unconfirm it. | ||
| plobsing_ | odd. I wonder what is going wrong with mine then. | 20:26 | |
| NotFound | Maybe something not rebuilt because of lack of some dependence? | 20:27 | |
| plobsing_ | nah. I've realcleaned and retried a couple of times. | 20:28 | |
| trying now with a fresh checkout. | |||
| NotFound | plobsing_: In what file is the problem? | 20:29 | |
| whiteknight | with --gc gms I can't reproduce any segfaults in build, test or spectest for rakudo | ||
| I'll have to take moritz's word for it that it's still a problem | 20:31 | ||
| plobsing_ | NotFound: I'm throwing asserts left, right, and center. none of them seem to have effect. | ||
| NotFound | Odd | ||
| whiteknight | plobsing_: as a sanity check, are you running the parrot you are building and not an installed one? | 20:32 | |
| plobsing_ | never install parrot | ||
| whiteknight | then you are a better man than I | ||
| benabik | I also get segfaults with gms | 20:33 | |
| whiteknight | okay. So it's all random | ||
| plobsing_ | the inconsistency may be due to GC being sensitive to the amount of memory available on the system. | 20:36 | |
| whiteknight | yeah, that's what I figure too | 20:40 | |
| memory size and memory layout | |||
| moritz is on 64bit, fwiw | 20:41 | ||
| whiteknight | me too | ||
| I'm going to throw on a ulimit, see if I can get a new failure mode | 20:42 | ||
| plobsing_ | fresh checkout; perl Configure.pl; make corevm => PARROT_ASSERT() compiled away | ||
| yep, ccflags contains NDEBUG here too | |||
| whiteknight | that's a bug | 20:43 | |
| and a serious concern | |||
| plobsing_: what compiler are you on? | 20:44 | ||
| NotFound | Maybe is imported from perl config? | ||
| whiteknight | (not that it should make any difference) | ||
| plobsing_ | gcc 4.5.2, linux 2.6.37, 64-bit | 20:45 | |
| moritz | lemme guess... we have no tests for assertions being triggered in debug builds. | 20:46 | |
| plobsing_ | NotFound: looks like you may be right on that count. the only place Configure.pl adds NDEBUG does not get called. | ||
| NotFound | moritz: if we add them, we'll get reports about segfaults during tests. | 20:47 | |
| moritz | NotFound: do assertion failures cause segfaults? | ||
| whiteknight | SIGABORT | 20:48 | |
| NotFound | moritz: systems ususally doesn't make distictions between segafults and deliberated aborts. | ||
| Is an abnormal termination in both cases. | 20:49 | ||
| And even if the system logs enough information to make the distinction, people don't. | 20:50 | ||
| plobsing_ | urg. my perl5's Config.pm doesn't have any entry with NDEBUG in it. | 20:57 | |
| where is this NDEBUG comming from? | |||
| NotFound | Are we importing flags from the pkg-config of some library? | 20:58 | |
| plobsing_ | is there a way to trace through the config step-by-step to figure out which step adds the NDEBUG? | 20:59 | |
| whiteknight | that's a kid51 question | 21:01 | |
| plobsing_ | uninstalling llvm fixed the problem | 21:05 | |
|
21:06
sirmacik joined
21:07
mikehh left
|
|||
| NotFound | Weird. | 21:08 | |
| dalek | TT #2089 created by plobsing++: LLVM cflags prevent debug builds | 21:16 | |
| TT #2089: trac.parrot.org/parrot/ticket/2089 | |||
|
21:17
perlite_ joined
21:19
fperrad left
21:20
perlite left,
perlite_ is now known as perlite
|
|||
| whiteknight | this rakudo bug is flummoxing me | 21:21 | |
| I'm going to have to take a break for dinner | 21:22 | ||
|
21:22
tcurtis left,
athomason left
21:23
bacek left
21:25
TiMBuS left
21:26
TiMBuS joined
|
|||
| moritz | this time t/spec/S06-operator-overloading/sub.rakudo segfaulted for me | 21:29 | |
|
21:42
ambs left
21:45
PacoLinux left
21:48
tcurtis joined,
athomaso1 joined
21:50
bacek joined
|
|||
| dalek | nxed: r953 | NotFound++ | trunk/winxedst1.winxed: refactor function modifier list into a derived class |
21:58 | |
|
22:12
mikehh joined
22:15
ligne left
22:28
mikehh left
22:32
bubaflub left
23:01
dafrito left
|
|||
| whiteknight | it looks like PackFile_destroy is getting called a few hundred times, all of them with the same pf pointer | 23:16 | |
| I can't tell if that's sane or not | |||
| benabik | If it's not ref-counted, that doesn't sound sane. | 23:17 | |
| whiteknight | does not appear to be ref-counted. At least, not in that function | ||
| maybe it's extremely weird coincidence that we are deleteing and then reallocating PackFiles with the same address | 23:18 | ||
| plobsing_ | if we're using malloc() to do the job, and the allocation occurs right after the deletion, it isn't a huge surprise - the free()d space should be at the start of the free list | 23:19 | |
| sorear | whiteknight: the fixed-size pools tend to reuse memory blocks | ||
| benabik | Yeah, what they said. | ||
| sorear | how many other objects does Parrot use that are the exact same size as struct PackFile? | ||
| whiteknight | I'm not saying it's impossible, but I saw several dozen calls to PackFile_destroy in a row with the exact same pf pointer | 23:20 | |
| a few with the same address is reasonable, but several dozen, and possibly over a hundred? | |||
| at that point, either something weird is happening, or we are using the world's worst algorithm | 23:21 | ||
| and the packfile structures appear to be using malloc/free, not the fixed-size allocator | |||
| plobsing_ | what function is calling these destroys? | ||
| benabik | I'd think that even if that was the case then we shouldn't be creating and destroying that many PackFile structs. | ||
| plobsing_ | ah. I know the source. If ImageIOThaw is invoked on a string (not from packfile), it needs to create a dummy packfile. These get destroyed with the ImageIOThaw object. | 23:24 | |
| now as to why we're creating hundreds of ImageIOThaw objects from strings... beats me. | 23:26 | ||
| never mind, some of them are ImageIOSize PMCs | 23:28 | ||
| whiteknight | Parrot_ImageIOThaw_destroy | 23:34 | |
| so that actually makes sense. They would be reusing pointers | |||
| plobsing_ | and I'm about to reduce your 100 packfiles down to 1 | 23:35 | |
| dalek | rrot: 5d9afa0 | plobsing++ | src/pmc/imageiosize.pmc: eliminate unused 'pf' attribute from ImageIOSize |
23:36 | |
|
23:37
sigue left
|
|||
| cotto | plobsing++ | 23:37 | |
|
23:39
sigue joined
|
|||
| whiteknight | okay, this is interesting. I pulled plobsings last commit and tried again. I don't get a segfault,but now I get this error : "PackFile_pack segment 'DIRECTORY' used size 561260 but reported 565536" | 23:40 | |
| so, is that better or worse? | |||
| plobsing_ | I'mma go with worse. rebuild? | 23:41 | |
| whiteknight | all of parrot? | 23:42 | |
| plobsing_ | yeah. not sure why that would be required, but give it a shot. | ||
|
23:43
bubaflub joined
|
|||
| whiteknight | rebuilt parrot and rakudo. Same error | 23:47 | |
| PackFile_pack segment 'DIRECTORY' used size 561260 but reported 565536 | 23:48 | ||
|
23:49
hudnix joined,
kid51 joined
|
|||
| whiteknight | something weird is going on | 23:49 | |
| plobsing_ | whiteknight: what are you building to see that? | 23:50 | |
| whiteknight | /usr/local/bin/parrot -o src/gen/perl6.pbc src/Perl6/Compiler.pir | ||
| it's in the rakudo build sequence | |||
| plobsing_ | yes, that's the command that I am debugging too. I see no error there. | 23:51 | |
| well, other than the segfault | |||
| whiteknight | my checkouts for both are clean | 23:54 | |
| this whole situation is weird. There is something majorly wrong going on | 23:55 | ||
| plobsing_ | We're seeing corrupted memory, so it is possible that is causing runaway seriailization | ||