Camelia, the Perl 6 bug

IRC log for #parrot, 2009-05-17

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 dalek parrot: r38855 | cotto++ | branches/pmc_pct/compilers/pmcc/pmcc.pir:
00:00 dalek parrot: [pmcc] re-add nqp's builtins, since they come in handy during debugging
00:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38855/
00:00 cotto bacek, do you think it makes more sense to put the vtable compiler in with pmcc or in a separate dir in compilers/ ?
00:01 bacek cotto, no preferences.
00:03 bacek I can't reproduce fail in packfileconstanttable.t...
00:04 bacek cotto: just keep it simple.
00:04 cotto always a good strategy
00:04 cotto afk
00:04 Infinoid bacek: Neither can I, any more.
00:04 Infinoid Thanks for testing
00:06 kid51 ping Infinoid
00:06 purl I can't find Infinoid in the DNS.
00:06 kid51 Infinoid ping
00:06 Infinoid hi kid51
00:06 kid51 So, I take it, we're somewhat at a standstill re the problem with config_pm.pm?
00:07 Infinoid The patch is backed out, for now, so it should build for everyone
00:07 kid51 k
00:07 Infinoid I have a patch in my stack that re-adds it, plus a whitelist, which should be safe to check in right now
00:08 kid51 Perhaps too close to monthly release ... ?
00:08 Infinoid I didn't hear any feedback from chromatic, yet, and I forgot to ask while he was here
00:09 Infinoid But it sounds like a good longterm solution for this is to split the config stuff into 2 parts... one minimal "needed to initialize parrot" part that's loaded during parrot startup, and one "kitchen sink" one that's loaded only when needed
00:10 Infinoid I don't think that's specced anywhere, yet.  It's just my opinion of the best way forward
00:11 kid51 And I see Smolder is still down.
00:24 bacek Infinoid: config and config-dev?
00:25 Infinoid Yeah, or init and config, or something like that.  I get the impression from http://groups.google.com/group/parrot-de​v/browse_thread/thread/d33ef7c89d50d84a that the more we can remove from the frozen hash we load at startup, the faster parrot will be in general
00:25 Infinoid config.pir is the slow (kitchen sink) path, init.pir would be the fast (but minimal) path
00:27 bacek +1
00:27 purl 1
00:43 dalek parrot: r38856 | bacek++ | branches/tt504_annotations:
00:43 dalek parrot: Branch for finishing Packfile PMCs
00:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38856/
00:53 Whiteknight joined #parrot
01:17 bacek joined #parrot
01:25 kid51 Does anyone know about this non-standard POD formatting I've spotted in two docs/books/*.pod files?
01:26 kid51 docs/book//ch01_introduction.pod:9
01:26 kid51 docs/book//ch02_getting_started.pod:3
01:26 kid51 grep -c 'U<'
01:26 kid51 Example:
01:27 kid51 U<http://www.parrot.org/download>. A binary installer for Windows is also
01:27 kid51 available at U<http://parrotwin32.sourceforge.net/>.
01:27 kid51 Is that something Allison is doing re book publication?  O'Reilly POD?
01:29 kid51 'podchecker' doesn't like it
01:30 kid51 *** ERROR: Unknown interior-sequence 'U' at line 10 in file docs/book//ch02_getting_started.pod
01:45 Theory joined #parrot
02:00 Coke kid51: yes. it's psuedo pod
02:01 Coke pseudopod?
02:01 purl rumour has it pseudopod is Jason McIntosh's cute name for O'Reilly's publishing extension to pod
02:01 Coke psuedopod is also Pod::PseudoPod
02:01 dalek parrot: r38857 | jkeenan++ | trunk/src/gc/gc_ms.c:
02:01 dalek parrot: Set SVN keywords and eol-style properties to match coding standards.
02:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38857/
02:03 kid51 Coke:  can you then take a look at TT #674?
02:03 Coke http://search.cpan.org/~arandal/Pod-Pseud​oPod-0.13/lib/Pod/PseudoPod/Tutorial.pod
02:03 Coke "don't use podchecker"
02:04 Coke I would just assign that ticket to allison or chromatic.
02:04 kid51 I've already CC-ed allison on it.
02:05 Coke there you go.
02:08 eternaleye_ joined #parrot
02:10 kid51 assigned to allison
02:18 dalek parrot: r38858 | whiteknight++ | trunk (2 files):
02:18 dalek parrot: [gc] Fix some function-level documentation in mark_sweep.c, a few small code changes but nothing significant.
02:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38858/
02:21 kid51 Whiteknight:  Can you look at the output of t/codingstd/c_arg_assert.t
02:21 Whiteknight why, did I break something?
02:21 kid51 # unused assert macros found:
02:21 kid51 # /src/gc/gc_ms.c: gc_ms_finalize
02:21 Whiteknight actually, I probaly did
02:22 kid51 I fixed some other codingstd problems with that file, but I don't know what an unused assert macro means.
02:23 Infinoid it means the function needs ASSERT_ARGS(gc_ms_finalize) at the top
02:23 Whiteknight yeah, I just added it
02:24 Whiteknight so many standards to forget, and with enough opportunity I will forget all of them
02:25 Whiteknight thanks kid51++ for cleaning up my mess
02:27 Whiteknight I added that line to the top, but now the test still fails
02:27 dalek parrot: r38859 | whiteknight++ | trunk/src/gc/gc_ms.c:
02:27 dalek parrot: [gc] Fix a codingstd problem that kid51++ pointed out
02:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38859/
02:28 Whiteknight # unused assert macros found:
02:28 Whiteknight # /home/andrew/Projects/parrot/src/gc/gc_ms.c: gc_ms_finalize
02:28 Whiteknight # 1 unused assert macros found in total.
02:32 Infinoid Whiteknight: No semicolon; it causes errors on msvc.
02:32 Whiteknight Okay, I figured it out
02:33 Whiteknight yeah, just got that
02:33 Infinoid Yes, I know, the test could be a bit more explicit about that.
02:33 Whiteknight thanks Infinoid__
02:33 Whiteknight Infinoid++
02:34 dalek parrot: r38860 | whiteknight++ | trunk/src/gc/gc_ms.c:
02:34 dalek parrot: [gc] ASSERT_ARGS apparently shouldn't be followed by a semicolon
02:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38860/
02:40 dduncan joined #parrot
02:40 dduncan left #parrot
02:42 janus joined #parrot
02:58 eternaleye joined #parrot
03:00 dalek parrot: r38861 | whiteknight++ | trunk/src/gc/gc_ms.c:
03:00 dalek parrot: [gc] small documentation change for line-ending
03:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38861/
03:07 dalek parrot: r38862 | whiteknight++ | trunk/src/sub.c:
03:07 dalek parrot: [gc] IF WE SEE SEGFAULTS IN THE NEXT DAY OR SO, LOOK AT THIS COMMIT. I removed some code that looked unnecessary, with a note that this was a 'work around' for a 'mysterious segfault' thing. If this actually does cause segfaults, we should have a ticket and start collecting information about it.
03:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38862/
03:10 eternaleye_ joined #parrot
03:20 donaldh joined #parrot
03:24 tetragon joined #parrot
04:01 Ademan joined #parrot
04:05 dalek parrot: r38863 | cotto++ | branches/pmc_pct (12 files):
04:05 dalek parrot: [vtdumper] start work on a PCT-based vtable.tbl parser/dumper
04:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38863/
04:09 dalek parrot: r38864 | Infinoid++ | trunk/src/gc/mark_sweep.c:
04:09 dalek parrot: [cage] Fix c_parens.t codingstd violation.
04:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38864/
04:15 dalek parrot: r38865 | cotto++ | branches/pmc_pct/config/gen/makefiles/vtdumper.in:
04:15 dalek parrot: [vtdumper] makefile fix
04:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38865/
04:48 dalek parrot: r38866 | cotto++ | branches/pmc_pct/compilers/vt​dumper/src/parser/grammar.pg:
04:48 dalek parrot: [vtdumper] grammar is working, now for actions
04:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38866/
05:55 cognominal starting on fresh repository copy, I get /Users/stef/git/rakudo/parrot/parrot  -o perl6_s1.pbc perl6.pir
05:55 cognominal Null PMC access in get_integer()
05:55 cognominal make: *** [perl6_s1.pbc] Error 1
05:56 cognominal I have not compiled parrot in month on my unibody mac
07:05 iblechbot joined #parrot
07:20 donaldh joined #parrot
08:53 bsdz joined #parrot
09:00 bacek joined #parrot
10:28 dalek parrot: r38867 | fperrad++ | trunk/lib/Parrot/Configure/Compiler.pm:
10:28 dalek parrot: [config] specify a comment type for PIR file generation.
10:28 dalek parrot: See result in runtime/parrot/library/config.pir
10:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38867/
11:15 HG` joined #parrot
11:20 donaldh joined #parrot
11:38 bacek joined #parrot
11:42 bacek cotto: ping
12:00 bsdz joined #parrot
12:39 rg1 joined #parrot
12:42 bacek joined #parrot
12:44 kid51 joined #parrot
12:53 Topic for #parrotis now Parrot 1.1.0 Released | http://parrot.org/ | 320 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets
13:10 Whiteknight joined #parrot
13:21 Infinoid hmm, ATTRs seem to throw pmc2c line numbering off
13:28 cotto easy karma if you can fix it
13:29 cotto well, normal karma ;)
13:29 cotto afk
13:30 Infinoid well, first step of that is done (I has a test case)
13:52 dalek parrot: r38868 | jkeenan++ | trunk (2 files):
13:52 dalek parrot: 'make' target 'check_source' should have been removed in r22249 2007-10-18
13:52 dalek parrot: when the underlying program tools/dev/check_source_standards.pl was removed.
13:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38868/
14:02 jhorwitz joined #parrot
14:05 dalek porcupinepascal: r68 | robin.ge++ | branches/oo-branch/ (5 files):
14:05 dalek porcupinepascal: * added support for attributes (without type checking)
14:05 dalek porcupinepascal: * broken TapTest module
14:05 dalek porcupinepascal: * done some general cleaning up
14:05 ruoso_ joined #parrot
14:05 dalek porcupinepascal: * more to come
14:05 dalek porcupinepascal: review: http://code.google.com/p/porcu​pinepascal/source/detail?r=68
14:25 cognominal joined #parrot
14:37 ruoso_ joined #parrot
14:38 rdice joined #parrot
14:42 iblechbot joined #parrot
14:44 Whiteknight does anybody around here know whether the src/stacks.c stuff is slated to be cut?
14:49 flh joined #parrot
15:01 Theory joined #parrot
15:09 Infinoid Whiteknight: judging from http://www.mail-archive.com/parrot-​dev@lists.parrot.org/msg01020.html, it sounds like we would if we had something to replace it with (it's the backend for the pushmark/popmark/pushaction ops)
15:10 Whiteknight right, I was planning to basically replace it all with an RIA PMC
15:11 Whiteknight so one GCable object instead of a series of them
15:11 Infinoid cool.
15:20 donaldh joined #parrot
15:24 dalek parrot: r38869 | petdance++ | trunk (2 files):
15:24 dalek parrot: using INTVAL instead of int for the function values that return INTVAL
15:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38869/
15:30 dalek parrot: r38870 | petdance++ | trunk/config/gen/makefiles/root.in:
15:30 dalek parrot: Dont' use -posix-strict-lib because it's far too strict.
15:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38870/
15:47 tetragon joined #parrot
16:11 mikehh joined #parrot
16:12 HG` joined #parrot
16:26 * Infinoid feels like he's playing whack-a-mole with these packfile pmc tests, and losing
16:34 Whiteknight what's wrong with them?
16:37 Infinoid some PackFileConstants are getting GCed sometime between when they were parsed and when they're added to the PackfileDirectory PMC's hash thingy
16:37 Infinoid so I guess that means they aren't being marked properly, which is a yak distracting me from implementing segment deletion
16:38 Infinoid direct symptom: SIGSEGV running ./parrot t/pmc/packfiledirectory.t, after the "ok 5"; Parrot_PackfileConstantTable_set_pmc_keyed_int() is called with a PMC whose vtable pointer is 0xdeadbeef.
16:38 kid51 joined #parrot
16:39 Infinoid yesterday I was seeing it from t/pmc/packfileconstanttable.t, either I'm remembering that wrong or it seems to have migrated
16:40 Whiteknight anything GC-related is going to jump around and might appear random
16:40 Infinoid The test runs fine when I pass the -G flag.
16:40 Debolaz joined #parrot
16:40 Whiteknight hmmm
16:41 benjaminvm joined #parrot
16:41 Whiteknight how are PackFileConstants managed? Who is supposed to be marking them?
16:42 Infinoid PackFile* (note: capital F) is all in src/packfile.c.  Packfile* is in src/pmc/packfile*.pmc, which wrap loosely around the C structures and avoid touching them whenever possible because they crash.
16:43 Infinoid I believe the marking is done by mark_1_seg()
16:43 jonathan PackFileConstant PMCs?
16:43 jonathan Is that just a PMC for the constants table?
16:44 Infinoid yeah
16:44 jonathan oh, phew :-)
16:44 Infinoid PackFile_Constant is a typedeffed struct containing a PMC
16:44 jonathan Wait, not one instane per constant though?
16:44 jonathan Well, I mean not an additional PMC representing each constant?
16:45 Infinoid No, the PackfileConstantTable PMC uses a couple of RIAs to manage the constants and their types
16:46 Infinoid err, one RPA for the PMCs and one RIA for the types
16:46 Infinoid so, no, there's no wrapping
16:46 jonathan OK.
16:47 Infinoid actually, now that I look at mark_1_seg...
16:47 Infinoid if (constants[i]->type == PFC_PMC) {
16:47 Infinoid I think we probably want to mark the PFC_KEY entries too
16:48 Infinoid That tweak didn't effect my segfault though. :(
16:50 Infinoid Do STRINGs have to be marked?
16:50 Whiteknight Infinoid: Yes
16:51 Infinoid Hmm.  Either this function is horribly wrong, or all that stuff must be marked somewhere else
16:54 he Hi, folks.
16:54 he I'm trying to build rakudo (for a change), and I'm falling over the error described in http://groups.google.com/group/perl.perl6.co​mpiler/browse_thread/thread/00d0bcd60aaba76d
16:54 jonathan Infinoid: If they're in the constants segment they're differently allocated and would not need marking afaik.
16:55 jonathan (That is, if they're in the constants segment loaded from some bytecode)
16:55 jonathan Thing is that if it's mixing constants in the constants seg with "constants" as in new PMCs the user has created and wants to freeze, well, that could get confusing...
16:56 he It turns out that rakudo is using parrot/tools/build/dynoplibs.pl to build this library, and gcc is failing because it's not given any -O flags(!) -- I'm seeing this with gcc 4.1.2 on NetBSD/4.0 i386
16:57 he So: two questions: 1) should dynoplibs.pl pass any -O flags and 2) if "no", can a user of dynoplibs.pl tell it to pass an -O flag?
16:57 Infinoid jonathan: Ok, I just pulled a PMC out of a (freshly loaded) PackFile_ConstTable which had a vtable pointer of 0xdeadbeef, so I guess it must have been allocated wrong or mistakenly GCed
16:58 jonathan Infinoid: Does the same code run under -G?
16:58 Infinoid jonathan: yes
16:58 he (the rakudo build is bombing later if I work around this problem, with a different error, of course)
16:58 jonathan OK, certainly it's not being marked when it needs to be somehow then.
16:59 Infinoid he: hi.  It should pass any -O flags if parrot itself was configured with --optimize (not the default)
16:59 Infinoid I'll double check that, one moment
17:00 he hmm... ok; need to look at how rakudo configures parrot, then.
17:00 jonathan he: If you're just doing the --gen-parrot thing, I'm about certain it configures it without any.
17:00 Infinoid (I build parrot by hand and only very rarely use --optimize, for what it's worth)
17:00 he The error I get later is "error:imcc:syntax error, unexpected STRINGC, expecting '(' (''$/'')"
17:00 jonathan he: That will happen for sure if you're missing dynops, yes.
17:01 he jonathan: I had to use --gen-parrot -- rakudo from git was not satisfied with my 1.1.0
17:01 jonathan he: No, Rakudo is syncing very closely against Parrot these dyas.
17:01 purl okay, jonathan.
17:01 jonathan *days
17:01 he ...and really, *really* wants to use stuff from parrot's build directory (bug?)
17:01 Tene Yes, bug.
17:02 jonathan I think there's two tools for building dynops and Rakudo is using the old deprecated one.
17:02 jonathan Just nobody had chance to update yet.
17:02 he I know too little parrot to make sense of the syntax erorrs, though.
17:04 jonathan he: It's cryptic.
17:04 nopaste "he" at 158.38.152.119 pasted "syntax errors from rakudo build" (34 lines) at http://nopaste.snit.ch/16576
17:04 he FWIW, here's a nopaste.
17:04 jonathan he: Means you're missing dynops.
17:05 jonathan (Since they didn't compile correctly, as you pointed out.)
17:05 jonathan Gotta go to the shops before they close - need some nom and pivo - bbiab
17:05 he hmm...  (Well, I cut-pasted the gcc, and re-did that part, but perhaps it constructed the lib with them missing...)
17:06 he (missing timestamp comparison for the component *.o files for the library?)
17:06 Infinoid The gcc error you got was "perl6.ops:218: error: unable to find a register to spill in class 'SIREG'", like that google groups link you pasted?
17:06 he Yep.
17:06 he Passing -O2 to gcc made the error go away.
17:07 Infinoid hmm, poor buggy gcc.
17:07 he indeed
17:07 deetah joined #parrot
17:07 deetah hi
17:07 deetah just wondering
17:07 Theory joined #parrot
17:08 deetah would it be possible to create a C to parrot compiler?
17:08 Infinoid he: well, if you're going to turn on optimization, you should do it at the parrot level
17:08 Infinoid deetah: yes, in fact we already have a partially written one in the languages repository, called "c99"
17:08 deetah sounds cool. would it make sense to make a parrotOS?
17:08 he Infinioid: sure, at the moment I'm just trying to see if I can get it to build with quick & dirty tricks.
17:09 Infinoid It's sort of an academic exercise, though, as it will never run as fast as native code and won't be able to use system headers
17:09 Infinoid he: Ok.  I think --optimize changes more than just the CFLAGS though, so I'd be wary of doing it on a per-object basis
17:09 Infinoid I would suggest --gen-parrot-option=--optimize
17:10 deetah Infinoid: sounds cool. would it make sense to make a parrotOS?
17:10 Infinoid deetah: I guess that depends on what you're trying to do.
17:11 he New error: "Parrot VM: PANIC: Out of mem!", apparently 256MB virtual was too small(?!?)
17:11 he Doubling...
17:11 purl i think doubling is a baffler
17:11 deetah Infinoid: a complete operating system that would run on variety of architectures.
17:11 deetah (with no recompiling of the binary code)
17:12 Topic for #parrotis now Parrot 1.1.0 Released | http://parrot.org/ | 319 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets
17:12 Infinoid every RT counts :)
17:12 Infinoid deetah: I think it's going to be very resource-heavy compared to the native stuff
17:12 deetah resources are getting cheaper
17:13 deetah is parrot mature enough?
17:14 Infinoid we're just getting to the point where some of the native language plugins are starting to think about ways to play with eachother, call into eachother, pass data back and forth, and stuff like that
17:14 Infinoid I think we definitely have some performance issues to work out before ideas like yours could really take off.
17:15 deetah i don't need performance at the point
17:15 PacoLinux Infinoid: the problem with gcc has a ticket : http://rt.perl.org/rt3/Publi​c/Bug/Display.html?id=64930
17:16 deetah Infinoid: just think it would be a nice toy, provided it'd be possible at the moment.
17:16 Infinoid he: The final stage of rakudo compilation is to link a perl6 binary.  That compiles a C file with a bootstrap function and a huge array, and gcc takes about a gig to do that on my linux/amd64 system
17:17 Infinoid deetah: Sure, it might be fun to play with.  It may be more useful or less depending on what kind of OS you wanted to make
17:17 he Infinoid: eek!
17:17 deetah Infinoid: one with a very extensive API that would help people avoid kde vs gnome-like conflicts.
17:18 he In other words "rakudo / parrot will never build on my m68k systems" :)
17:18 ruoso joined #parrot
17:18 deetah an inter-lingual VM sounds cool for that
17:18 deetah and I guess VM's the most advanced project in the category, isn't it?
17:18 he (the icu library already doesn't, for other and more embarassing reasons)
17:18 Infinoid he: the memory usage is a GCC issue; I think some of the of the folks in here have been working on a friendlier way to do it
17:18 he Whee, completed inside 512M on NetBSD/i386 4.0
17:19 he I think the worst pig was "/home/he/rakudo/parrot/parrot  perl6_s1.pbc --target=pir src/gen_setting.pm > src/gen_setting.pir", which peaked at 374MB
17:20 Infinoid deetah: Ok.  If you want to play with languages and spawning threads and stuff, you might want to look at jhorwitz++'s very nice mod_parrot work, which allows calling a bunch of languages in an apache plugin
17:20 deetah Infinoid: thanks for a tip.
17:26 masak joined #parrot
17:26 he Whee: Result: PASS (to rakudo's "make test")
17:27 Infinoid cool!
17:29 Infinoid he: So you're still able to build parrot (svn trunk) fine on NetBSD/i386?  (We're releasing 1.2.0 next Tuesday, and I'd like to update PLATFORMS.)
17:29 he Now checking whether "perl ./Configure.pl --gen-parrot --gen-parrot-optimize=--optimize" will give the same result.
17:29 he Infinoid: if that's what comes out when I try a current rakudo, then "yes".
17:30 Infinoid great, thanks
17:30 he I can re-try a couple of my other platforms as well, ppc being perhaps most interesting.
17:30 Infinoid that would be great.  I'd like to squeeze out any bugs before the release rather than afterwards :)
17:35 Infinoid By the way, turns out hpux/cc/ia64 is having the same issue you were seeing on netbsd/alpha with non-pointer va_list types.  You wouldn't happen to have a link to a guide for how to set up netbsd/alpha in qemu so I can test this stuff, would you?
17:38 he hm, no, sorry -- i've not seen alpha emulated (but that might be just me)
17:39 Infinoid No problem, was just a thought.
17:40 bsdz_ joined #parrot
17:41 he at least http://www.nongnu.org/qemu/status.html says "Dev only" for alpha emulation.
17:43 Whiteknight Infinoid: If the vtable pointer is 0xdeadbeef, it's probably been prematurely GCd
17:44 Whiteknight Also, it never hurts to re-mark things if you're unsure about them.
17:45 PacoLinux threre is an emulator for alpha called es40 : http://www.es40.org/Homepage (last time I used, i was able to run openvms and tru64)
17:45 Infinoid Ok.  I'm a little confused by what jonathan said, about how these packfile constant PMCs somehow magically don't need to be marked
17:45 he PacoLinux: interesting...
17:46 he (although I have my fair share of actual alpha hardware :)
17:46 Whiteknight Infinoid: They definitely need to be marked
17:46 Infinoid [09:54] <@jonathan> Infinoid: If they're in the constants segment they're differently allocated and would not need marking afaik.
17:46 Whiteknight Unless they're being allocated from the constant PMC pool, they definitely need marking
17:46 Andy joined #parrot
17:47 Whiteknight I think jonathan was thinking of something different. The PMCs definitely need a-markin'
17:47 Infinoid does it hurt anything to mark PMCs in the constant pool?
17:47 Whiteknight nope
17:49 nopaste "infinoid" at 75.28.74.203 pasted "[PATCH] Mark PFC_KEY and PFC_STRING elements as well (this patch has no effect on my crash)" (32 lines) at http://nopaste.snit.ch/16577
17:49 Infinoid I'm not sure this mark_1_seg function's even being called.
17:50 * Infinoid will trace around in gdb
17:52 Infinoid Parrot_gc_mark_and_sweep is run surprisingly often for such a simple test script
17:54 Whiteknight yeah, we definitely need to slow down the pace of that
17:55 Infinoid it's called 132 times during the course of 5 is() functions before it even gets to test 6 (the one I care about)
17:56 Infinoid I imagine loading a packfile creates lots of objects, but sheesh
17:57 dalek parrot: r38871 | allison++ | trunk/DEPRECATED.pod:
17:57 dalek parrot: [cage] Deprecation notice for the name 'Hash'.
17:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38871/
17:59 Whiteknight Well, it doesn't help that we're allocating arenas that only contain space for 64 objects to start
17:59 Whiteknight let me work on a patch for you to try and cut that down
18:00 Infinoid 64 does seem like a silly starting point, but if the allocation size increases exponentially, it shouldn't be too bad
18:02 Whiteknight Infinoid: Change the starting point to 1028, and see what that does to your numbers
18:02 purl Whiteknight: that doesn't look right
18:02 Infinoid purl, thanks for that
18:02 purl de rien Infinoid
18:02 Whiteknight ??? Did I just get told, by a bot?
18:02 Infinoid is it a #define?  I'm not sure where to find that
18:02 Infinoid nah, purl is just being useless
18:02 Whiteknight src/gc/pools.c:104
18:03 Whiteknight bump the number up to 1024, that should cut down the number of gc runs significantly
18:03 Whiteknight we really should be figuring out an optimal number based on native page size
18:04 Whiteknight but that's another project for another day
18:05 Infinoid as long as the chunk is page-aligned, I'm not so sure it matters
18:05 Whiteknight actually, that change won't do anything
18:05 Whiteknight i was looking at the wrong thing
18:06 Infinoid oh, I won't benchmark rakudo with it then :)
18:08 he NetBSD/macppc (powerpc) 5.0 parrot-current Result: PASS
18:10 he Tried to upload via "make smoke", but apparently smolder.plushtree.com is unresponsive.
18:10 Infinoid Yeah, it's been having problems
18:13 Whiteknight okay, apparently pool sizes for PMCs are allocated with size (10240/sizeof(PMC))
18:13 Whiteknight so that's a little bit weird of a number to use
18:14 Whiteknight I feel like it should be PAGESIZE/sizeof(PMC)
18:14 Whiteknight if we extend an arena beyond the size of a page we're going to lose a lot in virtual memory performance
18:16 * Infinoid goes and looks up what PAGE_SIZE is on amd64
18:17 Infinoid oh, still 4k.
18:17 Infinoid sizeof(struct PMC) is 48 on amd64, which means there are 85.3333 PMCs per page
18:18 Infinoid depending on the size of a cache line, that may or may not be a performance issue.
18:19 Infinoid anyway, 85 PMCs isn't much, the number of arenas is going to get rather huge
18:19 Infinoid so if we're tied to one page per arena, it is crucial to scale well to large numbers of arenas
18:20 Whiteknight true
18:20 Infinoid but if sizeof(struct PMC) wa a power of 2, I'm not really sure why we'd have VM overhead from having bigger arenas
18:20 Infinoid s/wa/was/
18:22 Infinoid the size of the map doesn't affect the time it takes to do a page table lookup
18:23 Infinoid nor should it affect the number of TLBs used in total, unless I'm misunderstanding something
18:25 Whiteknight it might not be too bad, I might be missing something too
18:25 Infinoid it's been a while since I've worked with page tables directly, linux generally does a good job of it on its own :)
18:27 Whiteknight okay I'm out. later
18:27 Infinoid thanks for the help
18:30 benjaminvm I have a flag I need to add to every c file, where do I add it?
18:30 dalek parrot: r38872 | allison++ | trunk/t/pmc/io.t:
18:30 dalek parrot: [cage] Unskipping test failure from Ubuntu 6.10.
18:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38872/
18:34 Infinoid benjaminvm: A compilation flag (command line), a #define, or what?
18:36 benjaminvm Compilation flag, -finstrument-...
18:36 Infinoid probably CFLAGS
18:38 Infinoid If it's something you want to enable always for a certain platform/compiler, you can put it in the hints file, e.g. config/init/hints/linux.pm has sections for icc and gcc flags
18:43 benjaminvm I also need to add a .c file to trace the call stack.
18:44 benjaminvm I add that to config/gen/makefiles/root.in? In what section?
18:44 Ademan_ joined #parrot
18:45 Infinoid benjaminvm: Try adding it to the INTERP_O_FILES list
18:45 Coke seen alias?
18:45 purl alias was last seen on #perl 22 minutes and 0 seconds ago, saying: The module being either Term::ReadLine, or possibly Term::ReadKey
18:45 benjaminvm Infinoid: Thanks for the help. I will try that.
18:50 flh some files (io.ops, ch10_opcode_reference.pod) refer to a "ParrotIO" PMC which doesn't seem to exist: shouldn't it be the FileHandle PMC instead?
18:53 flh well, I guess I found my answer in r33401
18:54 Infinoid flh: Yes, you're right.  Patches welcome.
18:55 flh I'll try to do that tonight
19:07 iblechbot joined #parrot
19:18 he Confirmed: "perl ./Configure.pl --gen-parrot --gen-parrot-option=--optimize" gave me a perl6 and completes "make test"
19:19 he Follow-up posted to http://rt.perl.org/rt3/Tic​ket/Display.html?id=64930
19:20 donaldh joined #parrot
19:32 kid51 joined #parrot
19:35 HG` joined #parrot
19:43 he Gah, rakudo / perl6 spectests needs more than 512m.
19:46 Infinoid ouch.  yeah, it's big
19:46 PacoLinux he for making perl6 maybe you want to try the Util patch (is not in the snv becouse fails in windows) http://irclog.perlgeek.de/p​arrot/2009-05-13#i_1138997
19:47 dalek parrot: r38873 | Infinoid++ | trunk/PLATFORMS:
19:47 dalek parrot: Update PLATFORMS for my own platforms and reports in #parrot.
19:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38873/
19:49 Infinoid msg bacek Is there any reason why the add_new test in t/pmc/packfiledirectory.t was being skipped?  (There's a goto directly above it.)  I've added support for deleting segments and a test for that (r38874), and reenabled the add_new test at the same time... seems to work fine here.
19:49 purl Message for bacek stored.
19:50 Infinoid PacoLinux: sounds like it fails while running spectests, not building
19:51 Infinoid (but thanks, I was looking for a link to that earlier)
19:51 dalek parrot: r38874 | Infinoid++ | trunk (3 files):
19:51 dalek parrot: [pdd13] Spec says PackfileDirectory should handle deletions.  Add that vtable and test it.
19:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38874/
19:51 dalek parrot: r38875 | Infinoid++ | trunk (2 files):
19:51 dalek parrot: [pmc2c] Line numbering isn't quite right, fix it (and add tests).
19:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38875/
19:53 Infinoid Ok, that's all the parrot time I have for today, bye all
19:55 Theory joined #parrot
20:06 dalek rakudo: 2949868 | jnthn++ | perl6.pir:
20:06 dalek rakudo: Make sure backtraces are printed to STDERR; printing them to STDOUT outrages masak++^W^Wis very wrong.
20:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​94986872304dc2b441c68e7615c0a04ceb076c3
20:12 particle1 joined #parrot
20:18 he Infinoid: NetBSD/alpha 4.0 parrot-current Result: PASS
20:23 flh it doesn't seem to be possible to write a PIR Object which would behave as a FileHandle (I tried to define an object with a "read" method, then do a "read myobject" but it returns an empty string)
20:26 nopaste "flh" at 88.160.47.207 pasted "Custom Object instead of a FileHandle" (16 lines) at http://nopaste.snit.ch/16578
20:26 flh should this code work?
20:28 Infinoid he: thanks, I'll update the file
20:29 Infinoid flh: I think you might also need a bool eof() :method, and a bool get_bool() :vtable :method, both of which return true if your handle has reached eof, and false otherwise
20:29 Infinoid judging from the filehandle pmc, at least.  If it still doesn't work then, I think that's a bug (or at the very least, an indication that we need more docs)
20:31 bacek joined #parrot
20:32 flh Infinoid, adding eof and get_bool doesn't change anything
20:33 Infinoid Okay, that's a bug then.  Please create a ticket for it at https://trac.parrot.org/parrot/
20:45 Coke is this already covered by our various "can't subclass a PMC" tickets?
20:45 Coke (man, is checkout out the parrot repo via tortoisesvn slow)
20:45 Coke s/checkout/checking/
20:45 Coke man, would it be faster if I just got trunk.
20:46 * Tene makes a new branch
20:47 Coke hey, don't you already have a branch going? =-)
20:47 Tene I do?
20:48 flh Coke, I'm not sure it's a "cannot subclass PMC" problem, since I'm not subclassing anything there
20:50 Coke oh, I assumed you were subclassing the PMC.
20:50 Coke ticket away, then.
20:50 Infinoid Surprisingly, subclassing FileHandle isn't a prerequisite.  The "read" op doesn't check the object's type, it just calls Parrot_io_reads(), which tries to call the "read" method via PCCINVOKE
20:50 Infinoid which seems like it should work
20:51 Infinoid (though I have to wonder why we have ops for this at all, considering we already got rid of similar socket-specific ops)
20:51 flh StringHandle doesn't subclass FileHandle either
20:52 dalek rakudo: 1203649 | masak++ | t/spectest.data:
20:52 dalek rakudo: [spectest.data] added S13-overloading/operators.t
20:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​203649deb39b5bd6caea24106acd1c032146263
20:53 Coke Infinoid: because the design is only done in chunks.
20:53 Coke IME, most of the reasons things are where they are is "historical.". :|
20:54 Coke (but we respond well to change. open an RFC. =-)
20:54 Infinoid I was under the impression that I/O was new and relatively un-dust-covered
20:55 Infinoid It would make sense if we forced these objects to do things like does "io", does "seekable", does "connection-oriented", does "open", but I don't think we necessarily have to enforce subclassing
20:55 Infinoid If we do, I'd prefer to see something P5-like, with a base class of IO::Handle.
20:55 Infinoid Seeking isn't valid for network sockets (though an HTTP 1.1 client class could does "seekable" and translate the seek() values to Content-Range headers, that would be neat)
20:56 Infinoid And eof() is only meaningful for SOCK_STREAM and SOCK_SEQPACKET, not SOCK_DGRAM or SOCK_RDM
20:58 Infinoid Guess it's something to ask allison about, later.
20:58 Coke we had an IO "system" for some time. I thought the read opcode hailed from back in the day.
20:58 Infinoid Ah, could be
20:58 Coke not from the rewrite that occurred in the past few years.
20:58 Infinoid flh could just call the "read" method on his shiny new class directly, but I don't think that would prove much
20:58 Coke be interested to see if it worked.
20:58 Coke s/ed/ing/
20:59 Infinoid anyway, I need to work on other things right now, but a brief glance into the op and underlying functions indicated that his class should work that way too
20:59 Coke tene: is pct_hll still needed?
20:59 Coke (the branch)
21:00 Coke make -j is borked.
21:00 Tene Coke: very dead
21:01 Coke tene: can you rm it?
21:01 nopaste "tene" at 166.70.38.237 pasted "inter-language library loading sketch for jonathan++ (and others?)" (43 lines) at http://nopaste.snit.ch/16579
21:04 dalek parrot: r38876 | tene++ | branches/pct_hll:
21:04 dalek parrot: Remove old branch. Coke++
21:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38876/
21:04 dalek parrot: r38877 | tene++ | branches/report_hll_info:
21:04 dalek parrot: Remove old branch. Coke++
21:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38877/
21:05 bacek morning
21:05 bacek Infinoid: (packfile test) Erm. Looks like it was my mistake.
21:06 nopaste "tene" at 166.70.38.237 pasted "inter-language library loading sketch - now with more linebreaks" (46 lines) at http://nopaste.snit.ch/16580
21:06 Coke infinoid, did you just fixup pmc2c line directives?
21:07 Coke tene, I didn't even get to bug you about the other branch!
21:07 Coke you're no fun. =-)
21:07 Tene Coke: want me to put it back?
21:07 Coke "I had no idea it would be so much, I won't pay."
21:07 Infinoid Coke: yes, did it break anything?
21:08 Infinoid bacek: cool then, 2 new tests for the price of 1.
21:09 Tene Anyone else feeling opinionated that I can con into looking at my plan for inter-language library loading?
21:09 Coke Infinoid: no, but I have an RT for you to steal.
21:10 Coke Infinoid: can you glance at RT#56792 ?
21:11 Coke Tene: I glanced at it; Looks like it will be work for tcl to participate in that scheme, but I imagine you could facilitate a bit of the work via PCT for languages that use it.
21:11 Coke ... but since tcl is dead, meh.
21:13 Infinoid Coke: Heh, good catch on the part of the reporter.  I honestly didn't know __FILE__ and __LINE__ even worked in perl 5.
21:16 Infinoid I suppose the easiest way to fix that is to take the number of lines in the heredoc, and subtract that from __LINE__
21:18 cotto Andy, ping
21:19 nopaste joined #parrot
21:20 cotto msg Andy It looks like a makefile template change snuck in with r38869.  Was that intentional?
21:20 purl Message for andy stored.
21:20 Whiteknight joined #parrot
21:26 bacek cotto: If you are working on VTables in pmc_pct branch can you change VTableInfo to be PAST::Node?
21:27 cotto ok
21:28 cotto any particular reason?
21:28 purl any particular reason is there any inherent flaws im not seeing just yet?
21:28 bacek Look in default.pm. If VTableInfo is PAST::Node we can just .clone it and add body.
21:30 cotto sounds nice
21:31 bacek Or you can add .to_post method to VTableInfo. Flip the coin to choose :)
21:31 cotto I'll play around with it.
21:31 cotto nap time
21:31 purl i heard nap time was perl -e 'say "Zz" x 99 and sleep 3600'
21:32 bacek wow.
21:32 bacek purl: good girl :)
21:32 purl :)
21:33 bacek Infinoid: what is deprecation policy for PackfileAnnotationKeys? It wasn't implemented in 1.0. Just stubs.
21:34 dalek parrot: r38878 | bacek++ | branches/tt504_annotations/src/pmc (2 files):
21:34 dalek parrot: Proposed changes to PackfileAnnotations/PackfileAnnotation.
21:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38878/
21:37 allison joined #parrot
21:38 Infinoid bacek: I'd say go for it.  It never worked, so noone will be relying on it
21:39 bacek Infinoid: ok.
21:40 dalek parrot: r38879 | bacek++ | branches/tt504_annotations/d​ocs/pdds/pdd13_bytecode.pod:
21:40 dalek parrot: [docs] Update pdd13 PMCs.
21:40 dalek parrot: Remove PackfileAnnotationKeys. Hide all it guts in PackfileAnnotation.
21:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38879/
21:41 bacek msg jonathan Any objections about r38879? I dropped PackfileAnnotationKeys and hide guts in Annotation.
21:41 purl Message for jonathan stored.
21:42 Topic for #parrotis now Parrot 1.1.0 Released | http://parrot.org/ | 310 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets
21:42 Coke Surely we can close or transfer 10 more RTs before the release!
21:44 allison how about that language example tests one?
21:45 allison Coke: my main question was, should we move the existing tests to t/examples/languages? or add them to the examples_tests where they are now
21:46 allison I kind of like having examples/languages/squaak have a t/ directory, as an example to new language devs
22:07 ruoso joined #parrot
22:10 Tene allison: mind looking over http://nopaste.snit.ch/16580 ?
22:13 allison Tene: sure
22:14 Tene allison: specifically, think that would work for pynie?
22:15 allison If fetch-library is a method, why not have it accept named arguments, instead of manually building a hash?
22:16 Tene allison: what happens in parrot calling conventions if I pass a named argument to a function that doesn't accept that argument?
22:16 Tene i guess we could require fetch-library to have a slurpy named param...
22:18 allison I'm not quite sure what this is doing. Is it Export, or load_bytecode?
22:19 Tene allison: a language's fetch-library will locate the appropriate file, read and compile it, and construct a list of symbols to return (probably just returning a namespace)
22:19 allison compile it and load it?
22:19 Tene fetch-library would be called from another language's "use" or "import"
22:19 Tene Yes.
22:19 allison then, let's call it 'load_library'
22:19 Tene OK
22:20 Tene the reason I chose 'fetch' over 'load' is what it returns.
22:20 Tene and if a language caches libraries, there might be no loading going on.
22:20 allison how is the return value used?
22:20 Tene by the calling language, to import symbols into its local namespace
22:20 Tene use Foo::Bar:lang<python>;
22:20 dalek parrot: r38880 | bacek++ | branches/tt504_annotations (2 files):
22:20 dalek parrot: Reimplement unpack Annotations using new PMCs API
22:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38880/
22:21 allison and, yes, it might not be loading if it was already loaded, but you're requesting it to be loaded
22:21 allison (as in, that's the main thing you're asking for)
22:21 gryphon joined #parrot
22:21 Tene the main thing I'm asking for is the symbols, which will probably require loading. :)
22:21 Tene But, sure.
22:22 Tene I don't object to 'load_library'.
22:23 allison agreed on having name as a key, rather than a string (each language has different delimiters)
22:23 allison thinking about the export interface...
22:24 allison is it intended that the only way to call a function from another HLL is to import it into your HLL?
22:25 Tene I don't think so.  As long as you have a way to get at the HLL namespace, you can call it that way.
22:25 Tene Or eval.
22:25 allison good
22:26 Tene eval($whatever, :lang<python>);
22:27 allison namespaces already have an 'export_to' method, which is preferable to this way of importing
22:27 allison it even accepts a list of symbols
22:28 Tene I expected that some languages might have a different way of registering which symbols to export... we could certainly require that the values of the 'symbols' key are namespaces, though.
22:28 rob joined #parrot
22:28 allison I'm not sure any language except Perl even uses exports this way
22:29 Tene Neither am I, but I'm very much not confident on my knowledge of esoteric languages.
22:29 Tene That's why I was trying to avoid unnecessary restrictions.
22:30 allison well, requiring 'DEFAULT' and 'ALL' of languages that don't use exports is probably too much
22:30 Tene Yes, but I also want to make it possible for other languages to accurately use Perl libraries.
22:30 allison rather than 'symbols', I'd rather see a pointer to 'namespace'
22:31 allison namespace already has a language-neutral way of looking up symbols
22:31 allison so, we don't need to duplicate it
22:31 Tene OK
22:32 Tene rakudo, then, should just set the ::EXPORT::ALL namespace as the namespace returned?
22:32 Tene I guess that's not too bad.
22:32 allison mmmmm... I don't know what the current problems are with other languages using Perl libraries
22:33 allison Are they loading symbols they shouldn't, or not importing symbols they should?
22:33 Tene allison: right now there is *no* way for languages to load each other's libraries.
22:33 allison mmm... well, the look up the namespace, and then look up a sub
22:33 allison it's not convenient
22:33 allison and definitely needs work
22:34 Tene No HLLs provide a way of doing that.
22:34 dalek parrot: r38881 | bacek++ | branches/tt504_annotations/t​/pmc/packfileannotations.t:
22:34 Tene Except maybe eval.
22:34 dalek parrot: [t] Split Annotations.test_unpack into loading and checking parts.
22:34 dalek parrot: Second part will be used for test pack/unpack combo.
22:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38881/
22:34 dalek parrot: r38882 | bacek++ | branches/tt504_annotations/​t/pmc/packfileannotation.t:
22:34 dalek parrot: [t] Update packfileannotation.t
22:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38882/
22:34 dalek parrot: r38883 | bacek++ | branches/tt504_annotations/t/​pmc/packfileannotationkeys.t:
22:34 dalek parrot: [t] Remove packfileannotationkeys.t
22:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38883/
22:34 allison Tene: ah, the HLLs aren't using the feature, okay, makes sense
22:34 allison Tene: and, making it more convenient will make them more likely to use it
22:34 Tene Yes.
22:35 Tene There needs to be a standard API for a language to ask for another language to load a library and point to the right namespace.
22:35 Tene if not, every language needs to know the details of how every other namespace defines a library, the search path, etc.
22:35 Tene Foo::Bar vs Foo.Bar vs Foo\Bar wtc.
22:35 Tene etc.
22:36 allison yup
22:36 allison I like the idea of requiring a method on the compiler object
22:36 allison (which HLLCompiler will provide by default)
22:37 Tene Yes.
22:38 allison overall this looks workable
22:38 allison oh, side question, why the 'getinterp'?
22:38 Tene to get the caller's namespace to put the symbols in.
22:39 Tene Is there a better way of retrieving that?
22:39 allison 'get_namespace'?
22:39 Tene how do you know which namespace you were called *from*?
22:39 Tene Not your current namespace, but the namespace of your caller.
22:40 Tene module Foo { use Bar; }
22:40 allison ah, you're digging back on the stack to the last namespace
22:41 Tene the symbols from Bar should be exported to the Foo namespace, not whichever namespace 'use' is defined in.
22:41 Tene Right.
22:41 allison that's icky
22:41 allison we need to encapsulate that
22:41 Tene Is there a better way to get that information?
22:41 allison Tene: no, there isn't
22:41 allison but there should be :)
22:41 contingencyplan_ joined #parrot
22:41 Tene Ah, OK.
22:42 Tene allison: is this scheme workable with pynie?  If so, are you okay with me implementing it?
22:42 Tene also, is today too soon before the release to be adding this stuff to HLLCompiler?
22:42 allison yes, generally workable
22:42 allison and, yes, wait til after the release to commit
22:42 rob Just implemented namespace support in porcupine
22:42 Tene OK
22:42 Tene rob: what's porcupine?
22:42 rob although its only single tiered
22:43 allison I don't want to cannonize having people poke into the guts of the interpreter for making calls to other libraries
22:43 rob a rather flakey object pascal implementation
22:43 allison Tene: so, we'll have to fix that at the same time
22:43 Tene allison: this isn't for other libraries... this is what rakudo currently uses for "use".
22:44 Tene allison: how does pynie do imports, if not this?
22:44 allison Tene: pynie doesn't really do imports, not like Perl. Python is different
22:45 allison but, if we're going to be using caller information this way, it needs a better interface
22:45 allison Does Rakudo actually loop over the symbols in the namespace to export them rather than using 'export_to'?
22:45 Tene Yes.
22:46 allison Does 'export_to' not work for Rakudo, or was there some other motivation?
22:46 allison (the first might mean it needs fixing)
22:46 Tene No idea.  I didn't write it.  I suspect whoever did just didn't remember it.
22:46 bacek Whiteknight: (TT#685) "perl Configure.pl --no-line-directives" was implemented few weeks ago. Or you want more fine grained switching?
22:46 Tene Lemme change it and see.
22:48 Tene building...
22:49 allison Tene: how about 'get_caller_namespace'? one version with one PMC argument that just goes one-level back, and another version with an additional integer argument that goes X levels back?
22:49 Tene allison: 'export_to' doesn't work without specifying what to export.
22:49 Tene "NOTE: exporting ’default’ set of items is not yet implemented."
22:50 allison yes, it needs a list of names, which is what you have there
22:50 allison imports = library['symbols']['DEFAULT']
22:50 allison (at least, I'm assuming that's a list of names)
22:50 allison what's Rakudo iterating over, if it's not a list of names?
22:50 Tene allison: I assumed that it was something that implemented a hash interface, probably a namespace.
22:52 allison then we'd need multiple copies of the namespace object, with different symbols
22:52 allison is that what Rakudo does now?
22:53 Tene allison: rakudo stores all exportable objects in a subnamespace, EXPORT::ALL, with the default set in EXPORT::DEFAULT
22:53 Tene so yes, it has different namespaces with keys that point to the same objects.
22:54 Tene allison: export_ns.'export_to'(import_ns) doesn't work without a list of everything in export_ns.  Is there a way to get that?
22:55 allison well, that's what I expected Rakudo to be storing in EXPORT::ALL, just a sec, looking at namespace
22:55 Tene EXPORT::ALL is a namespace.
22:55 Whiteknight bacek: I never heard of that one. I'll test it
22:56 Tene allison: AFK
22:56 Tene Thank you for input. :)
22:56 allison Tene: looks like a null argument to 'export_to' does the 'default' set of exports
22:57 allison Tene: which is not implemented :)
22:57 allison Tene: okay, later
22:59 allison Tene: (Rakudo has some strange ways of doing things, largely, I guess because they're trailblazers trying out the experimental edge. often leaves me wondering if we should struggle to support it, or provide a cleaner standard that does the same thing)
22:59 bacek Whiteknight: it was implemented couple of weeks ago
22:59 Whiteknight thanks bacek++
23:00 bacek Whiteknight: It wasn't implemented by me :)
23:01 Whiteknight i don't care who implements it, I care about the people who points it out to me
23:01 bacek :) Fair enough
23:04 bacek Can you close ticket?
23:05 rob does examples/tcl/tcltkdemo.pir work for anyone?
23:10 Infinoid Whiteknight: Hmm, I thought I just fixed #line in pmc2c output.  Is it still busted?
23:11 Whiteknight I don't know if it is "fixed" or not, I just want it not to exist
23:11 Whiteknight bacek: Yes, I will close the ticket
23:13 Infinoid I do think it's useful to see the original location of any given piece of code, as I'm debugging, so I know what to edit
23:13 Infinoid Even though it's never been perfect, it's a maintenance burden, and everyone keeps breaking it
23:14 Infinoid Comments would have the same problem.  But at least you wouldn't get stuck with gdb trying to tell you that you got a segfault while trying to execute a line of POD
23:14 Infinoid (which is what annoyed me enough to fix it this morning, at least for code coming from the .pmc file itself)
23:16 Infinoid If we do get rid of the line annotations for PMCs, we should do the same for ops
23:20 donaldh joined #parrot
23:21 Infinoid pmc2c.pl also has a --no-lines option.
23:27 he Hm, ./Configure --optimize fails on NetBSD/shark (arm) 4.0 with a gcc ICE
23:28 Infinoid Got a log?
23:28 he Sure.  I'll nopaste the tail of it.
23:30 he Hm miss WWW/Mechanize.pm on this host.  One moment.
23:30 nopaste "he" at 158.38.152.119 pasted "NetBSD/shark (arm) 4.0 build failure" (50 lines) at http://nopaste.snit.ch/16581
23:31 Infinoid I've got some arm (le and be) hardware I can test on, but I haven't run parrot on it for a while
23:31 Infinoid what's a gcc ICE?  sounds like an interesting trick... native is slow.
23:31 Infinoid oh, my, looks like gcc fail
23:32 he ICE = Internal Compiler Error
23:32 Infinoid oh.  (for some reason I thought of In-Circuit Emulator, my bad)
23:32 he heh
23:32 Whiteknight Infinoid: I thought the same thing
23:32 he I'll re-try without optimization.
23:33 he Only the second gcc bug rakudo or parrot has uncovered today at this end.
23:34 Infinoid "To boldly crash where noone has crashed before"
23:53 Whiteknight how do we tell from C if a particular PMC is a PIR-defined class?
23:53 Whiteknight or, an object of a PIR-defined class
23:55 Whiteknight I was going to use "if (p->vtable->pmc_class->vtable->base_type == enum_class_Class)", but that seems so inelegant
23:56 Infinoid hmm, good question
23:56 purl Yeah, it is. I'm stumped.
23:57 Whiteknight actually, that code snippet wont even work because built-in PMCs won't have a class pmc in the vtable
23:58 Whiteknight if(p->vtable->pmc_class && p->vtable->pmc_class->vtable->base_type == enum_class_Class)
23:58 Whiteknight and tell me that's not some smelly code
23:59 Infinoid That's the kind of thing I'd want to hide deep in some header file and use a macro for
23:59 Whiteknight there has to be an easier way
23:59 Infinoid in the scheme of things, that code is a lot cheaper than calling through PCC would be

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

Parrot | source cross referenced