Camelia, the Perl 6 bug

IRC log for #parrot, 2011-04-10

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 dngor left #parrot
00:06 whiteknight joined #parrot
00:12 whiteknight good evening, #parrot
00:18 bubaflub evening whiteknight
00:19 whiteknight hello bubaflub
00:29 mikehh left #parrot
00:37 dalek parrot: 6853f88 | petdance++ | include/parrot/compiler.h:
00:37 dalek parrot: close off unused the way clang likes it
00:37 dalek parrot: review: https://github.com/parrot/parrot/commit/6853f88b41
00:42 mikehh joined #parrot
00:51 mikehh left #parrot
00:59 loufoque joined #parrot
01:00 loufoque hi, i've looked at this document and was astonished http://www.parrot.org/dev/irc-logs
01:00 loufoque oops wrong link
01:00 loufoque http://docs.parrot.org/parrot/latest/​html/docs/pdds/pdd28_strings.pod.html
01:00 loufoque normalization forms apply to combining character sequences, not grapheme clusters.
01:01 loufoque therefore this NFG thing is just weird
01:02 loufoque does it store "\r\n" as an entry in the table too?
01:04 sorear It doesn't do any of that yet.
01:04 sorear Most of the PDDs are "wishful thinking"
01:04 sorear *yet (if ever)
01:05 whiteknight NFG was implemented as a GSOC project last year, but never merged
01:05 whiteknight loufoque: \r\n would probably not be in the table
01:05 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 #parrot
01:06 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
01:07 whiteknight The benefit is that we gain linear-time lookups by moving the grapheme complexity to the lookup table
01:15 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 loufoque e level.
01:15 loufoque just an idea, I don't know why it wouldn't be linear anyway
01:16 dalek Rosella: 9fff443 | Whiteknight++ | src/prototype/Protoclass.winxed:
01:16 dalek Rosella: 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 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/9fff4433b0
01:18 dngor joined #parrot
01:19 whiteknight loufoque: for details, you probably want to talk to darbelo. He implemented the NFG thing for GSoC last year
01:20 estrabd left #parrot
01:20 estrabd joined #parrot
01:28 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:29 loufoque plobsing: yes, the strings need to be normalized of course
01:30 loufoque or at least canonically ordered
01:30 loufoque yes they need to be normalized, be it NFC or NFD
01:30 plobsing which requires a preprocessing pass anyways. might as well build a table of characters.
01:37 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:38 whiteknight no normaliztion form solves every problem
01:39 whiteknight but NFG is an interesting tool to use, especially in a VM which commonly does operations on graphemes
01:41 whiteknight left #parrot
01:47 cotto bacek, ping
01:48 bacek left #parrot
01:59 bacek joined #parrot
02:03 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
02:06 dalek parrot: 49b5e9d | petdance++ | include/parrot/api.h:
02:06 dalek parrot: Added PARROT_ASSERTS_ON to tell if assertions are on
02:06 dalek parrot: review: https://github.com/parrot/parrot/commit/49b5e9d18f
02:06 dalek parrot: 9cb8686 | petdance++ | src/gc/gc_gms.c:
02:06 dalek parrot: quieting unused args.
02:06 dalek parrot: review: https://github.com/parrot/parrot/commit/9cb8686534
02:18 soh_cah_toa i just wanna make sure...we don't use svn anymore, right?
02:19 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
02:20 cotto languages used to live in the main repo.  They were kicked out of the nest a while ago.
02:21 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:23 cotto go ahead
02:23 cotto soh_cah_toa++
02:23 soh_cah_toa alright. btw, how long after i email the contributions cla can i get commit access?
02:24 soh_cah_toa b/c i have some changes i'd like to submit by tomorrow
02:25 cotto soh_cah_toa, you can always fork on github
02:25 cotto we love pull requests
02:26 cotto 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
02:27 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?
02:31 cotto have you read http://help.github.com/pull-requests/ ?
02:32 dafrito left #parrot
02:32 soh_cah_toa nopaste, but i think that is what i'm looking for
02:32 cotto lawl
02:32 soh_cah_toa agh...did it again
02:33 cotto your client might be configured to autocomplete words ending with a comma
02:33 plobsing left #parrot
02:33 cotto istr something similar with xchat
02:33 soh_cah_toa yeah
02:34 soh_cah_toa are pull requests any different than branches?
02:34 soh_cah_toa correct me if i'm wrong but it looks like pull request are specific to github, not git
02:35 cotto soh_cah_toa, right
02:36 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
02:36 cotto no
02:37 dafrito joined #parrot
02:37 woosley joined #parrot
02:41 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:42 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:44 soh_cah_toa alright i get it
02:44 cotto great, because I have to take off in a few minutes
02:44 soh_cah_toa okay
02:55 bubaflub soh_cah_toa: yes, i just merged in a pull request for cardinal earlier today
02:55 bubaflub 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
02:55 bubaflub soh_cah_toa: a parrot dev can come in and take a look, comment, and merge your commits
02:56 soh_cah_toa okay, so when i issue a git commit, it get pushed to the clone i made w/ the pull request?
03:03 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:06 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:07 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:08 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:09 soh_cah_toa should i put everything in one pull request or separate or what?
03:09 soh_cah_toa ooops, not #236
03:09 soh_cah_toa #1215 i think
03:12 bubaflub soh_cah_toa: two separate commits, if you please
03:12 bubaflub soh_cah_toa: that way it's easier to revert if someone needs to
03:12 bubaflub soh_cah_toa: not saying that we will, but make the commits logical chunks of work
03:12 soh_cah_toa i figured since they address two separate issues
03:12 bubaflub soh_cah_toa: exactly.  they aren't related to each other, can be applied separately
03:13 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
03:13 soh_cah_toa right
03:13 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
03:13 bubaflub soh_cah_toa: for small work, patches on tickets work just fine
03:14 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...
03:14 bubaflub soh_cah_toa: you can just commit directly
03:15 * 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
03:16 soh_cah_toa after the cla, you become a "trusted member"
03:18 soh_cah_toa cool
03:18 bubaflub soh_cah_toa: bingo
03:20 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:21 soh_cah_toa 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:26 bubaflub soh_cah_toa: at work, every commit i make is reviewed by another coder
03:26 bubaflub soh_cah_toa: it's real nice - learn lots
03:28 soh_cah_toa bubaflub: what kind of software do you develop?
03:29 soh_cah_toa bubaflub: at work, i mean
03:29 bubaflub soh_cah_toa: web development stuff in perl
03:29 bubaflub soh_cah_toa: which is to say all kinds of things - jQuery, HTML, CSS, Catalyst, DBIx::Class
03:30 soh_cah_toa bubaflub: wow, i didn't think perl was used much as an enterprise language
03:31 soh_cah_toa bubaflub: i'm jealous. i wish i had a job writing perl
03:33 woosley1 joined #parrot
03:34 woosley left #parrot
03:35 bubaflub soh_cah_toa: it ain't as sexy as other hip languages
03:35 bubaflub soh_cah_toa: but i love it
03:35 krunen left #parrot
03:36 soh_cah_toa yeah, perl's my little baby
03:41 Khisanth left #parrot
03:46 bubaflub goodnight #parrot
03:46 soh_cah_toa see ya
03:46 bubaflub left #parrot
03:47 plobsing joined #parrot
03:51 Khisanth joined #parrot
03:55 dalek tracwiki: v6 | soh_cah_toa++ | GSoCersStartHere
03:55 dalek 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.
03:55 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GSoC​ersStartHere?version=6&amp;action=diff
04:11 dalek tracwiki: v7 | soh_cah_toa++ | GSoCersStartHere
04:11 dalek tracwiki: Fixed mailto links. Also added link to GSoC page which I forgot before. It's overkill, I know.
04:11 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GSoC​ersStartHere?version=7&amp;action=diff
04:11 dalek tracwiki: v11 | soh_cah_toa++ | WhereIsIt
04:11 dalek tracwiki: Added link to GitHub repository.
04:11 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​hereIsIt?version=11&amp;action=diff
04:12 mikehh joined #parrot
04:14 mikehh left #parrot
04:18 bacek cotto, pong
04:23 mikehh joined #parrot
04:42 dalek tracwiki: v31 | soh_cah_toa++ | NewParrotDeveloperGuide
04:42 dalek tracwiki: Added some links to a few pages which I think are really important to newcomers (like me).
04:42 dalek tracwiki: http://trac.parrot.org/parrot/wiki/NewParro​tDeveloperGuide?version=31&amp;action=diff
04:55 * soh_cah_toa says goodnight to parrot
04:55 soh_cah_toa left #parrot
05:37 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
05:38 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
05:40 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.
05:41 cotto I wish melange would let me sort by which tasks have mentors and which ones I've voted on.
05:43 edu joined #parrot
05:43 edu is now known as Eduardow_
05:44 Eduardow left #parrot
05:45 Eduardow_ is now known as Eduardow
05:48 cotto I'd like to see the parser generator and the java bytecode translator happen.
05:51 bacek I'm not sure about "java bytecode translator". What the point?
05:52 cotto interesting potential for interop
05:53 bacek heh. Can we have "native-to-parrot-languages" interop happened first?
05:53 bacek e.g. rakudo<->cardinal<->particle
05:55 cotto touche
05:59 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
05:59 cotto seen bbantha
05:59 aloha Sorry, I haven't seen bbantha.
05:59 * Tene declines to repeat his traditional comments about interop.
06:00 cotto That every time you've done work, the rest of us haven't shown much interest?
06:03 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:11 sorear Who cares about interop?
06:11 Eduardow left #parrot
06:12 cotto sorear, was that serious?
06:14 cotto My ISP filters out the sarcasm bit.
06:14 Eduardow joined #parrot
06:14 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
06:14 sorear but I know the answer
06:14 sorear bacek: go...
06:16 bacek sorear, for example. I have something like (foo)(bar). How to distinguish between prefix<()>.circumfix<()> and circumfix<()>.postcircumfix<()>?
06:16 * bacek hates C...
06:17 sorear bacek: you can't.
06:17 sorear the C grammar is fundamentally ambiguous with casts
06:18 sorear 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?
06:18 sorear valid types always start with a type keyword (you know the list) or a typedef name
06:18 bacek "foo" can be typedefed. Which mean I need full "cpp"
06:18 sorear typedefs aren't part of cpp
06:19 sorear #define pie typedef
06:19 sorear pie int cow;
06:20 bacek yes. But for opsc it means I have to parse all parrot headers before parsing ops bodies
06:20 bacek which is kinda slow and painful
06:20 sorear C sucks like that
06:20 sorear ever notice how slow building parrot is?  gcc is suffering from the same problem you are
06:21 bacek opsc is few orders of magnitude slower than gcc.
06:22 bacek looks like I have to cheat somehow and bring "well known definitions" closer to opsc...
06:23 bacek next question about PASTing: what is best practise for PASTing postcircumfix/postfix without explicitly define them in Grammar?
06:23 bacek e.g. "foo(bar)". is term<identifier>.postcircumfix<()>
06:23 cotto bacek, can you restrict the C used by opsc to make parsing headers unnecessary?
06:24 bacek postcircumfix<()> will create PAST::Op(<call>). How "term<identifier>" can find that EXPR has postcircumfix part?
06:25 bacek cotto, " I have to cheat somehow and bring "well known definitions" closer to opsc"
06:25 cotto how clever of me
06:27 bacek sorear, any thoughts on "postcircumifix pasting"?
06:28 sorear bacek: I'm not sure what you're getting at.  This is what EXPR is for.
06:29 bacek sorear, I have to inverse order of evaluation. "foo(bar)" should produce PAST::Op(:name<foo>, PAST::Var(:name<bar>)).
06:30 bacek "(bar)" will create "PAST::Op(:type<call>, PAST::Var(:name<bar>))".
06:30 bacek method term:identifier (for "foo" part) have to check is there is postcircumfix exists and use it.
06:31 bacek or, let's rephrase - when I have to create PAST::Op(:type<call>) node?
06:42 theory left #parrot
07:02 sorear bacek: think about the function pointer case
07:02 bacek sorear, yes... My final goal is properly parse/past foo->bar->baz(quux)
07:04 bacek e.g. VTABLE_foo(interp, pmc) is actually pmc->vtable->foo(interp, pmc)
07:06 sorear bacek: in the general case "foo" needs to be parsed as an expression
07:06 sorear because it might be "int (*foo)();"
07:06 sorear in which case you want to generate a call with args (foo) and (bar)
07:06 bacek sorear, yes. But for now I want simple case done first.
07:07 bacek e.g. foo->bar() should produce something meaningful
07:07 bacek with postfix< -> >, postcircumfix<()>
07:10 bacek looks like I have to overridde "method EXPR" to handle postfixish things automatically
07:10 fperrad joined #parrot
07:12 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:14 benabik Erm.  User registration page: https://www.parrot.org/user/register
07:14 benabik I'm gonna pass out now though.
07:20 cotto awesome
07:20 cotto by which I mean the opposite of awesome
07:22 cotto benabik, it works fine for me
07:23 cotto I had to submit a form without the captcha once, but it appeared after that
07:24 cotto either way, you probably don't need a parrot.org account unless you're planning on having a blog there.
07:30 Themeruta joined #parrot
07:30 NotFound left #parrot
07:50 lateau joined #parrot
07:50 Themeruta is now known as NotFound
08:09 mj41 joined #parrot
08:43 contingencyplan joined #parrot
08:47 Eduardow left #parrot
09:46 lucian joined #parrot
10:09 lucian_ joined #parrot
10:11 lucian__ joined #parrot
10:12 lucian left #parrot
10:15 lucian_ left #parrot
10:39 ligne left #parrot
10:49 sirmacik left #parrot
11:01 whiteknight joined #parrot
11:08 whiteknight good morning, #parrot
11:10 dalek winxed: r944 | NotFound++ | trunk/winxedst0.cpp:
11:10 dalek winxed: some refactor in stage 0 Modifier classes to make them more like its stage 1
11:10 dalek winxed: versions
11:10 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=944
11:27 lucian__ left #parrot
11:34 gbacon joined #parrot
11:40 mtk left #parrot
11:43 * moritz gets some rakudo segfaults on newest parrot
11:43 moritz $ ./perl6 t/spec/S03-sequence/arity-2-or-more.t
11:43 moritz 1..19
11:43 moritz ok 1 - arity-2 Fibonacci
11:43 moritz Segmentation fault
11:45 nopaste "moritz" at 192.168.1.3 pasted "segfault" (28 lines) at http://nopaste.snit.ch/39787
11:45 lucian_ joined #parrot
11:48 mtk joined #parrot
11:51 lucian_ left #parrot
11:55 Patterner left #parrot
11:55 Psyche^ joined #parrot
11:56 Psyche^ is now known as Patterner
11:56 dalek winxed: r945 | NotFound++ | trunk/winxedst0.cpp:
11:56 dalek winxed: use an Argument class instead or raw Expr in ArgumentList in stage 0
11:56 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=945
11:56 kid51 joined #parrot
12:03 lucian joined #parrot
12:12 dalek tracwiki: v8 | jkeenan++ | GSoCersStartHere
12:12 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GSoC​ersStartHere?version=8&amp;action=diff
12:12 dalek tracwiki: v9 | jkeenan++ | GSoCersStartHere
12:12 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GSoC​ersStartHere?version=9&amp;action=diff
12:27 lucian_ joined #parrot
12:30 lucian left #parrot
12:38 whiteknight moritz: interesting
12:38 whiteknight moritz: is that a recent issue?
12:38 whiteknight I mean, is it from a change today, or earlier?
12:46 gbacon left #parrot
12:55 moritz whiteknight: I don't know
12:56 moritz I get excessive memory usage while trying to bisect parrot (and run rakudo on top of it)
12:57 moritz ie enough to OOM with my ulimit -v of 1.5G
12:58 NotFound moritz: Can you try winth a non optimized build, to get a more detailed backtrace?
12:58 dalek winxed: r946 | NotFound++ | trunk/winxedst0.cpp:
12:58 dalek winxed: argument modifiers in stage 0
12:58 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=946
12:58 moritz NotFound: I'm bisecting first, but will do that too
12:59 whiteknight shit, I hope thats not related to the imcc_compreg_pmc merge
13:04 dalek winxed: r947 | NotFound++ | trunk/winxed (2 files):
13:04 dalek winxed: now that stage 0 allow modifiers, use them in the non installed driver, and fix
13:04 dalek winxed: a bug found while doing that
13:04 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=947
13:06 dalek parrot: 99786be | Whiteknight++ | / (4 files):
13:06 dalek parrot: 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 dalek parrot: review: https://github.com/parrot/parrot/commit/99786be37e
13:06 dalek parrot: 9ec9ca8 | Whiteknight++ | src/ (3 files):
13:06 dalek parrot: 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
13:06 dalek parrot: review: https://github.com/parrot/parrot/commit/9ec9ca8e1c
13:14 dalek winxed: r948 | NotFound++ | trunk/winxedst1.winxed:
13:14 dalek winxed: remove the drivers helper methods in the compreg'ed compiler object that are no
13:14 dalek winxed: more needed
13:14 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=948
13:14 dalek winxed: r949 | NotFound++ | trunk/pir/winxed_compiler.pir:
13:14 dalek winxed: update installable compiler
13:14 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=949
13:14 moritz can somebody please run   git describe --tags  on HEAD and tell me the result?
13:15 NotFound moritz: RELEASE_3_2_0-344-g9ec9ca8
13:16 kid51 $ git describe --tags
13:16 kid51 RELEASE_3_2_0-334-gabe179c
13:16 NotFound kid51: My HEAD is more head than yours :P
13:18 moritz thanks
13:19 lateau left #parrot
13:19 moritz somehow my bisecting takes me to RELEASE_3_0_0-605-g19f0540 which makes no sense at all
13:19 moritz becasue I took 3.0.0 as the good and HEAD as the bad rev
13:21 moritz and another copy of parrot which I used for the unoptimized build was on an old branch :/
13:23 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 kid51 So I had to conduct the bisecting entirely manually.
13:23 kid51 Is that's what
13:23 kid51 's happening with you?
13:24 NotFound Bisecting non lineal structures can be hard.
13:27 lucian_ left #parrot
13:30 lateau joined #parrot
13:44 dalek parrot: 0f0dc31 | Whiteknight++ | src/pmc/imccompiler.pmc:
13:44 dalek parrot: comment out method stubs in IMCCompiler which have not been implemented yet
13:44 dalek parrot: review: https://github.com/parrot/parrot/commit/0f0dc315ea
13:48 lateau left #parrot
13:57 moritz kid51: seems like
13:57 moritz kid51: I had to skip one revision, guess it didn't like it
14:02 moritz without --optimize, rakudo build fails for me
14:02 moritz $ /home/moritz/tmp/rakudo/parrot_install/bin/parrot  src/gen/perl6.pbc --target=pr  \ src/gen/core.pm > src/gen/core.pir
14:02 moritz PackFile_unpack: Buffer length 0 is shorter than PACKFILE_HEADER_BYTES 18.
14:02 moritz make: *** [perl6.pbc] Error 1
14:04 moritz RELEASE_3_2_0-330-gae4f8e1 is bad
14:06 dalek winxed: r950 | NotFound++ | trunk/winxedst (2 files):
14:06 dalek winxed: refactor common parts of Return and Yield statements into a base class in stage
14:06 dalek winxed: 0
14:06 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=950
14:12 moritz on, first it segfaults during build (uoptimized), then when I restart it complains about an empty packfile
14:24 ambs joined #parrot
14:25 JimmyZ joined #parrot
14:47 kid51 left #parrot
14:58 particle1 is now known as particle
15:06 plobsing_ joined #parrot
15:08 JimmyZ left #parrot
15:09 theory joined #parrot
15:10 plobsing left #parrot
15:16 he left #parrot
15:16 he joined #parrot
15:18 dalek winxed: r951 | NotFound++ | trunk/winxedst0.cpp:
15:18 dalek winxed: refactor function parameters in stage 0
15:18 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=951
15:23 he left #parrot
15:23 he joined #parrot
15:24 mikehh left #parrot
15:29 woosley1 left #parrot
15:49 Eduardow joined #parrot
15:54 dalek forth: eb5a59d | plobsing++ | forth/forth.pir:
15:54 dalek forth: Exception isn't array-based
15:54 dalek forth: review: https://github.com/parrot/forth/commit/eb5a59d0fb
16:11 mikehh joined #parrot
16:26 mtk left #parrot
16:42 NotFound The rakudo problem seems to be caused by a GC error: a ResizablePMCArray data pointer is NULL.
16:42 NotFound Looks like it's been prematurely collected.
16:44 whiteknight damnit, that's the same kind of error I was seeing in the imcc_compreg_pmc branch
16:44 whiteknight I thought I had all those instances fixed
16:44 moritz NotFound: great that you found it. My attempts to bisect it have repeatedly killed several of my desktop applications (due to OOM)
16:44 whiteknight well, there was actually only one bug that I thought was fixed
16:45 NotFound moritz: I used the same backtrace you posted before, but in a non optimized build.
16:49 NotFound Uh, no, not the same backtrace, the same core dump during the build.
16:50 * whiteknight starts building rakudo with a fresh parrot
16:53 NotFound I'm thinking about using a PMC flag in debug builds, if set emit a diagnostic message when collected.
16:54 ligne joined #parrot
16:54 whiteknight hmm...I got a segfault during the rakudo build. I'm trying again without threads
16:55 NotFound whiteknight: the problem I've found is in that segfault.
16:57 whiteknight okay, that FIA has a NULL ->data
16:57 whiteknight and that is a problem
16:59 NotFound FIA? Mine was in RPA.
16:59 ambs left #parrot
16:59 ambs joined #parrot
17:01 whiteknight Mine is an FIA that's coming out of the constants table while saving bytecode to file
17:01 whiteknight which indicates to me that a packfile is being collected somewhere
17:02 NotFound Mine is the todo attribute in imageiosize.pmc
17:02 NotFound Also while saving bytecode.
17:03 ambs_ joined #parrot
17:03 ambs left #parrot
17:03 ambs_ is now known as ambs
17:23 whiteknight I think I have it fixed
17:23 whiteknight a little bit of a hack
17:23 whiteknight at this point we need to tread water until we have properly GCable packfiles
17:24 whiteknight ...no, nevermind. Not fixed
17:25 ambs_ joined #parrot
17:25 ambs left #parrot
17:25 ambs_ is now known as ambs
17:27 whiteknight the packfile PMCs are all being GC registered to prevent premature collection, so that's not the problem
17:33 cotto ~
17:42 dalek parrot: e53b5c5 | mikehh++ | src/packfile/api.c:
17:42 dalek parrot: fix codetest failure - add missing ASSERT_ARGS()
17:42 dalek parrot: review: https://github.com/parrot/parrot/commit/e53b5c597d
17:42 dalek parrot: 8869eca | mikehh++ | src/pmc/imccompiler.pmc:
17:42 dalek parrot: fix codetest failure - add missing documentation
17:42 dalek parrot: review: https://github.com/parrot/parrot/commit/8869eca378
17:46 dodathome joined #parrot
17:52 dalek parrot: 0573725 | mikehh++ | include/parrot/compiler.h:
17:52 dalek parrot: fix codetest failure - wrap macro argument
17:52 dalek parrot: review: https://github.com/parrot/parrot/commit/0573725f99
18:02 he left #parrot
18:03 he joined #parrot
18:08 ambs left #parrot
18:08 bubaflub joined #parrot
18:08 ambs joined #parrot
18:11 ShaneC left #parrot
18:13 petdance joined #parrot
18:28 ShaneC joined #parrot
18:29 hudnix left #parrot
18:36 mj41 left #parrot
18:47 whiteknight NotFound: ping
18:49 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
18:49 whiteknight NotFound: can you send me a copy of the backtrace you are seeing?
18:50 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
18:51 cotto which bug?
18:51 NotFound And more strange, supposedly in a debug build data should be set to 0xdeadbeef, not to NULL.
18:53 nopaste "NotFound" at 192.168.1.3 pasted "Backtrace of segfault during rakudo build" (31 lines) at http://nopaste.snit.ch/39930
18:53 whiteknight cotto: rakudo is segfaulting in random ways
18:53 cotto great
18:53 NotFound whiteknight: the line numbers in imageiosize are a bit shifted because of my debug statements.
18:54 whiteknight ok
18:54 whiteknight okay, no PackFile PMCs are ever being destroyed
18:54 whiteknight they are all properly registered like I thought
18:55 whiteknight 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:56 cotto that's the only big thing to happen recently
18:57 NotFound Uhhhh..... I've inserted PARROT_ASSERT(todo->data); in ImageIOSize init_pmc... and it fails.
18:57 whiteknight ...wat?
18:58 whiteknight that's not possible
18:58 whiteknight I mean, it's possibe
18:58 whiteknight but damnit
19:00 NotFound Something might be wrong in some macro.
19:06 whiteknight this bug is absurd
19:07 whiteknight on my machine, PMC constant #2596 / 2831 is corrupted
19:07 whiteknight but the first 2595 pmcs freeze just fine
19:10 whiteknight what's that command to randomize memory layout?
19:10 cotto you mean hash seed?
19:10 whiteknight no, chromatic had a command that you could use to cause linux to randomize the memory space
19:10 whiteknight so the next program run wouldn't use the same pages in the same order
19:10 lucian joined #parrot
19:11 cotto I didn't know about that.
19:11 NotFound whiteknight: the push_string vtables in the imageio PMC look suspicious.
19:12 benabik whiteknight: http://gcc.gnu.org/wiki/Randomization ?
19:12 NotFound whiteknight: looks like they don't return appropiately in some branches.
19:12 whiteknight NotFound: okay, that's weird
19:13 benabik whiteknight: Sorry, that _dis_ables randomization, sorry.
19:13 NotFound The ones that say 'TODO should really be: PANIC'
19:13 whiteknight NotFound: which PMC? imageiosize?
19:13 NotFound whiteknight: and imageiofreeze
19:16 he left #parrot
19:16 whiteknight yes, these vtables do look...weird
19:17 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:18 mikehh t/examples/pod.t fails - see TT #2088
19:18 mikehh 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)
19:18 NotFound Those uses of return just to avoid increse indentations are weird.
19:18 plobsing_ NotFound: what is odd about those?
19:19 he joined #parrot
19:20 NotFound Dont't know well how they are supposed to work.
19:21 Coke I prefer fail-early, myself.
19:22 Coke (rather than single-exit)
19:22 Coke think of them as asserts.
19:22 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
19:22 NotFound Coke: maybe, but in a lot of places they are not failures.
19:23 plobsing_ I'll do single-return, but only if liberal use of goto is acceptable.
19:24 NotFound plobsing_: then I don't understant the TODO: PANIC comments.
19:25 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 petdance left #parrot
19:25 plobsing_ and so we need to do an inefficient in-line string serialization
19:26 whiteknight plobsing_: I don't know if you've been following along. Rakudo is randomly segfaulting in places related to packfile serialization
19:27 whiteknight 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.
19:27 plobsing_ notably, :anon :immediate subs work this way.
19:27 he left #parrot
19:28 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.
19:29 whiteknight oh, does it? That's interesting
19:29 whiteknight I know it goes away with -G
19:29 whiteknight oh yes, --gc gms works for me too
19:29 moritz plobsing_: not confirmed. I always use --gc gms, and it still segfaults for me
19:36 mikehh NotFound: ping
19:37 NotFound mikehh: pong
19:38 mikehh NotFound: tried to build winxed - make: *** No rule to make target `stage2', needed by `all'. Stop.
19:40 mikehh 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:41 mikehh failed at the make all stage
19:44 NotFound mikehh: try make, without all
19:44 mikehh NotFound: 'k
19:44 whiteknight --gc=gms allows me to build rakudo without issue
19:45 NotFound mikehh: yes, is a bug, forgot to change the dependeces of that target in a recent reorganization of the Makefile.
19:46 moritz whiteknight: it builds for me too (optimized), but segfaults at a test (see backlog)
19:47 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:48 benabik (Just to add confusion to everyone backtracing rakudo...  :-/ )
19:53 dalek winxed: r952 | NotFound++ | trunk/Makefile:
19:53 dalek winxed: fix 'all' Makefile target, mikehh++
19:53 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=952
19:54 lucian left #parrot
19:57 mikehh NotFound: 'k that works ok - managed to build and test with make, just re-built
20:01 benabik But I also get sporadic segfaults on rakudo.  (Parrot master: --optimize --gc=gms --debugging=0 --ccflags="-DPARROT_GC_VALIDATE")
20:19 plobsing_ PARROT_ASSERT() appears to do nothing. It used to assert() when compiled without optimize. When did this change?
20:19 plobsing_ and was it intentional
20:19 plobsing_ ?
20:20 soh_cah_toa joined #parrot
20:20 dodathome left #parrot
20:21 whiteknight I thought PARROT_ASSERT was always a no-op with --optimize
20:21 NotFound plobsing_: I've used it a few hours ago.
20:22 plobsing_ whiteknight: it is. I'm not compiling with optimize. Just straight 'perl Configure.pl'. Yet the disassembly doesn't lie.
20:23 plobsing_ 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.
20:23 whiteknight plobsing_: that's weird. in an unoptimized build PARROT_ASSERT should do something
20:25 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.
20:26 plobsing_ odd. I wonder what is going wrong with mine then.
20:27 NotFound Maybe something not rebuilt because of lack of some dependence?
20:28 plobsing_ nah. I've realcleaned and retried a couple of times.
20:28 plobsing_ trying now with a fresh checkout.
20:29 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
20:31 whiteknight 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.
20:31 NotFound Odd
20:32 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
20:32 whiteknight then you are a better man than I
20:33 benabik I also get segfaults with gms
20:33 whiteknight okay. So it's all random
20:36 plobsing_ the inconsistency may be due to GC being sensitive to the amount of memory available on the system.
20:40 whiteknight yeah, that's what I figure too
20:40 whiteknight memory size and memory layout
20:41 * moritz is on 64bit, fwiw
20:41 whiteknight me too
20:42 whiteknight 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
20:42 plobsing_ yep, ccflags contains NDEBUG here too
20:43 whiteknight that's a bug
20:43 whiteknight and a serious concern
20:44 whiteknight plobsing_: what compiler are you on?
20:44 NotFound Maybe is imported from perl config?
20:44 whiteknight (not that it should make any difference)
20:45 plobsing_ gcc 4.5.2, linux 2.6.37, 64-bit
20:46 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.
20:47 NotFound moritz: if we add them, we'll get reports about segfaults during tests.
20:47 moritz NotFound: do assertion failures cause segfaults?
20:48 whiteknight SIGABORT
20:48 NotFound moritz: systems ususally doesn't make distictions between segafults and deliberated aborts.
20:49 NotFound Is an abnormal termination in both cases.
20:50 NotFound And even if the system logs enough information to make the distinction, people don't.
20:57 plobsing_ urg. my perl5's Config.pm doesn't have any entry with NDEBUG in it.
20:57 plobsing_ where is this NDEBUG comming from?
20:58 NotFound Are we importing flags from the pkg-config of some library?
20:59 plobsing_ is there a way to trace through the config step-by-step to figure out which step adds the NDEBUG?
21:01 whiteknight that's a kid51 question
21:05 plobsing_ uninstalling llvm fixed the problem
21:06 sirmacik joined #parrot
21:07 mikehh left #parrot
21:08 NotFound Weird.
21:16 dalek TT #2089 created by plobsing++: LLVM cflags prevent debug builds
21:16 dalek TT #2089: http://trac.parrot.org/parrot/ticket/2089
21:17 perlite_ joined #parrot
21:19 fperrad left #parrot
21:20 perlite left #parrot
21:20 perlite_ is now known as perlite
21:21 whiteknight this rakudo bug is flummoxing me
21:22 whiteknight I'm going to have to take a break for dinner
21:22 tcurtis left #parrot
21:22 athomason left #parrot
21:23 bacek left #parrot
21:25 TiMBuS left #parrot
21:26 TiMBuS joined #parrot
21:29 moritz this time t/spec/S06-operator-overloading/sub.rakudo segfaulted for me
21:42 ambs left #parrot
21:45 PacoLinux left #parrot
21:48 tcurtis joined #parrot
21:48 athomaso1 joined #parrot
21:50 bacek joined #parrot
21:58 dalek winxed: r953 | NotFound++ | trunk/winxedst1.winxed:
21:58 dalek winxed: refactor function modifier list into a derived class
21:58 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=953
22:12 mikehh joined #parrot
22:15 ligne left #parrot
22:28 mikehh left #parrot
22:32 bubaflub left #parrot
23:01 dafrito left #parrot
23:16 whiteknight it looks like PackFile_destroy is getting called a few hundred times, all of them with the same pf pointer
23:16 whiteknight I can't tell if that's sane or not
23:17 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
23:18 whiteknight maybe it's extremely weird coincidence that we are deleteing and then reallocating PackFiles with the same address
23:19 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
23:19 benabik Yeah, what they said.
23:19 sorear how many other objects does Parrot use that are the exact same size as struct PackFile?
23:20 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 whiteknight a few with the same address is reasonable, but several dozen, and possibly over a hundred?
23:21 whiteknight at that point, either something weird is happening, or we are using the world's worst algorithm
23:21 whiteknight and the packfile structures appear to be using malloc/free, not the fixed-size allocator
23:21 plobsing_ what function is calling these destroys?
23:21 benabik I'd think that even if that was the case then we shouldn't be creating and destroying that many PackFile structs.
23:24 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:26 plobsing_ now as to why we're creating hundreds of ImageIOThaw objects from strings... beats me.
23:28 plobsing_ never mind, some of them are ImageIOSize PMCs
23:34 whiteknight Parrot_ImageIOThaw_destroy
23:34 whiteknight so that actually makes sense. They would be reusing pointers
23:35 plobsing_ and I'm about to reduce your 100 packfiles down to 1
23:36 dalek parrot: 5d9afa0 | plobsing++ | src/pmc/imageiosize.pmc:
23:36 dalek parrot: eliminate unused 'pf' attribute from ImageIOSize
23:36 dalek parrot: review: https://github.com/parrot/parrot/commit/5d9afa0ad1
23:37 sigue left #parrot
23:37 cotto plobsing++
23:39 sigue joined #parrot
23:40 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 whiteknight so, is that better or worse?
23:41 plobsing_ I'mma go with worse. rebuild?
23:42 whiteknight all of parrot?
23:42 plobsing_ yeah. not sure why that would be required, but give it a shot.
23:43 bubaflub joined #parrot
23:47 whiteknight rebuilt parrot and rakudo. Same error
23:48 whiteknight PackFile_pack segment 'DIRECTORY' used size 561260 but reported 565536
23:49 hudnix joined #parrot
23:49 kid51 joined #parrot
23:49 whiteknight something weird is going on
23:50 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
23:50 whiteknight it's in the rakudo build sequence
23:51 plobsing_ yes, that's the command that I am debugging too. I see no error there.
23:51 plobsing_ well, other than the segfault
23:54 whiteknight my checkouts for both are clean
23:55 whiteknight 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

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced