Parrot 1.1.0 Released | parrot.org/ | 322 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets
Set by moderator on 13 May 2009.
dalek rrot: r38855 | cotto++ | branches/pmc_pct/compilers/pmcc/pmcc.pir:
[pmcc] re-add nqp's builtins, since they come in handy during debugging
 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/ ?
bacek cotto, no preferences. 00:01
I can't reproduce fail in packfileconstanttable.t... 00:03
cotto: just keep it simple. 00:04
cotto always a good strategy
afk
Infinoid bacek: Neither can I, any more.
Thanks for testing
kid51 ping Infinoid 00:06
purl I can't find Infinoid in the DNS.
kid51 Infinoid ping
Infinoid hi kid51
kid51 So, I take it, we're somewhat at a standstill re the problem with config_pm.pm?
Infinoid The patch is backed out, for now, so it should build for everyone 00:07
kid51 k
Infinoid I have a patch in my stack that re-adds it, plus a whitelist, which should be safe to check in right now
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
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:09
I don't think that's specced anywhere, yet. It's just my opinion of the best way forward 00:10
kid51 And I see Smolder is still down. 00:11
bacek Infinoid: config and config-dev? 00:24
Infinoid Yeah, or init and config, or something like that. I get the impression from groups.google.com/group/parrot-dev/...c89d50d84a that the more we can remove from the frozen hash we load at startup, the faster parrot will be in general 00:25
config.pir is the slow (kitchen sink) path, init.pir would be the fast (but minimal) path
bacek +1 00:27
purl 1
dalek rrot: r38856 | bacek++ | branches/tt504_annotations:
Branch for finishing Packfile PMCs
 00:43
00:53 Whiteknight joined 01:17 bacek joined
kid51 Does anyone know about this non-standard POD formatting I've spotted in two docs/books/*.pod files? 01:25
docs/book//ch01_introduction.pod:9 01:26
docs/book//ch02_getting_started.pod:3
grep -c 'U<'
Example:
U<www.parrot.org/download>. A binary installer for Windows is also 01:27
available at U<parrotwin32.sourceforge.net/>.
Is that something Allison is doing re book publication? O'Reilly POD?
'podchecker' doesn't like it 01:29
*** ERROR: Unknown interior-sequence 'U' at line 10 in file docs/book//ch02_getting_started.pod 01:30
01:45 Theory joined
Coke kid51: yes. it's psuedo pod 02:00
pseudopod? 02:01
purl rumour has it pseudopod is Jason McIntosh's cute name for O'Reilly's publishing extension to pod
Coke psuedopod is also Pod::PseudoPod
dalek rrot: r38857 | jkeenan++ | trunk/src/gc/gc_ms.c:
Set SVN keywords and eol-style properties to match coding standards.
kid51 Coke: can you then take a look at TT #674? 02:03
Coke search.cpan.org/~arandal/Pod-Pseudo...torial.pod
"don't use podchecker"
I would just assign that ticket to allison or chromatic. 02:04
kid51 I've already CC-ed allison on it.
Coke there you go. 02:05
02:08 eternaleye_ joined
kid51 assigned to allison 02:10
dalek rrot: r38858 | whiteknight++ | trunk (2 files):
[gc] Fix some function-level documentation in mark_sweep.c, a few small code changes but nothing significant.
 02:18
kid51 Whiteknight: Can you look at the output of t/codingstd/c_arg_assert.t 02:21
Whiteknight why, did I break something?
kid51 # unused assert macros found:
# /src/gc/gc_ms.c: gc_ms_finalize
Whiteknight actually, I probaly did
kid51 I fixed some other codingstd problems with that file, but I don't know what an unused assert macro means. 02:22
Infinoid it means the function needs ASSERT_ARGS(gc_ms_finalize) at the top 02:23
Whiteknight yeah, I just added it
so many standards to forget, and with enough opportunity I will forget all of them 02:24
thanks kid51++ for cleaning up my mess 02:25
I added that line to the top, but now the test still fails 02:27
dalek rrot: r38859 | whiteknight++ | trunk/src/gc/gc_ms.c:
[gc] Fix a codingstd problem that kid51++ pointed out
Whiteknight # unused assert macros found: 02:28
# /home/andrew/Projects/parrot/src/gc/gc_ms.c: gc_ms_finalize
# 1 unused assert macros found in total.
Infinoid Whiteknight: No semicolon; it causes errors on msvc. 02:32
Whiteknight Okay, I figured it out
yeah, just got that 02:33
Infinoid Yes, I know, the test could be a bit more explicit about that.
Whiteknight thanks Infinoid__
Infinoid++
dalek rrot: r38860 | whiteknight++ | trunk/src/gc/gc_ms.c:
[gc] ASSERT_ARGS apparently shouldn't be followed by a semicolon
 02:34
02:40 dduncan joined, dduncan left 02:42 janus joined 02:58 eternaleye joined
dalek rrot: r38861 | whiteknight++ | trunk/src/gc/gc_ms.c:
[gc] small documentation change for line-ending
 03:00
rrot: r38862 | whiteknight++ | trunk/src/sub.c:
[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
03:10 eternaleye_ joined 03:20 donaldh joined 03:24 tetragon joined 04:01 Ademan joined
dalek rrot: r38863 | cotto++ | branches/pmc_pct (12 files):
[vtdumper] start work on a PCT-based vtable.tbl parser/dumper
 04:05
rrot: r38864 | Infinoid++ | trunk/src/gc/mark_sweep.c:
[cage] Fix c_parens.t codingstd violation.
 04:09
rrot: r38865 | cotto++ | branches/pmc_pct/config/gen/makefiles/vtdumper.in:
[vtdumper] makefile fix
 04:15
rrot: r38866 | cotto++ | branches/pmc_pct/compilers/vtdumper/src/parser/grammar.pg:
[vtdumper] grammar is working, now for actions
 04:48
cognominal starting on fresh repository copy, I get /Users/stef/git/rakudo/parrot/parrot -o perl6_s1.pbc perl6.pir 05:55
Null PMC access in get_integer()
make: *** [perl6_s1.pbc] Error 1
I have not compiled parrot in month on my unibody mac 05:56
07:05 iblechbot joined 07:20 donaldh joined 08:53 bsdz joined 09:00 bacek joined
dalek rrot: r38867 | fperrad++ | trunk/lib/Parrot/Configure/Compiler.pm:
[config] specify a comment type for PIR file generation.
 10:28
11:15 HG` joined 11:20 donaldh joined 11:38 bacek joined
bacek cotto: ping 11:42
12:00 bsdz joined 12:39 rg1 joined 12:42 bacek joined 12:44 kid51 joined
moderator Parrot 1.1.0 Released | parrot.org/ | 320 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets 12:53
13:10 Whiteknight joined
Infinoid hmm, ATTRs seem to throw pmc2c line numbering off 13:21
cotto easy karma if you can fix it 13:28
well, normal karma ;) 13:29
afk
Infinoid well, first step of that is done (I has a test case) 13:30
dalek rrot: r38868 | jkeenan++ | trunk (2 files):
'make' target 'check_source' should have been removed in r22249 2007-10-18
 13:52
14:02 jhorwitz joined
dalek rcupinepascal: r68 | robin.ge++ | branches/oo-branch/ (5 files):
* added support for attributes (without type checking)

  * done some general cleaning up
  * more to come		 14:05
14:05 ruoso_ joined
14:25 cognominal joined 14:37 ruoso_ joined 14:38 rdice joined 14:42 iblechbot joined
Whiteknight does anybody around here know whether the src/stacks.c stuff is slated to be cut? 14:44
14:49 flh joined 15:01 Theory joined
Infinoid Whiteknight: judging from www.mail-archive.com/parrot-dev@lis...1020.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:09
Whiteknight right, I was planning to basically replace it all with an RIA PMC 15:10
so one GCable object instead of a series of them 15:11
Infinoid cool.
15:20 donaldh joined
dalek rrot: r38869 | petdance++ | trunk (2 files):
using INTVAL instead of int for the function values that return INTVAL
 15:24
rrot: r38870 | petdance++ | trunk/config/gen/makefiles/root.in:
Dont' use -posix-strict-lib because it's far too strict.
 15:30
15:47 tetragon joined 16:11 mikehh joined 16:12 HG` joined
Infinoid feels like he's playing whack-a-mole with these packfile pmc tests, and losing 16:26
Whiteknight what's wrong with them? 16:34
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
so I guess that means they aren't being marked properly, which is a yak distracting me from implementing segment deletion
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
16:38 kid51 joined
Infinoid yesterday I was seeing it from t/pmc/packfileconstanttable.t, either I'm remembering that wrong or it seems to have migrated 16:39
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
Whiteknight hmmm 16:40
16:41 benjaminvm joined
Whiteknight how are PackFileConstants managed? Who is supposed to be marking them? 16:41
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:42
I believe the marking is done by mark_1_seg() 16:43
jonathan PackFileConstant PMCs?
Is that just a PMC for the constants table?
Infinoid yeah 16:44
jonathan oh, phew :-)
Infinoid PackFile_Constant is a typedeffed struct containing a PMC
jonathan Wait, not one instane per constant though?
Well, I mean not an additional PMC representing each constant?
Infinoid No, the PackfileConstantTable PMC uses a couple of RIAs to manage the constants and their types 16:45
err, one RPA for the PMCs and one RIA for the types 16:46
so, no, there's no wrapping
jonathan OK.
Infinoid actually, now that I look at mark_1_seg... 16:47
if (constants[i]->type == PFC_PMC) {
I think we probably want to mark the PFC_KEY entries too
That tweak didn't effect my segfault though. :( 16:48
Do STRINGs have to be marked? 16:50
Whiteknight Infinoid: Yes
Infinoid Hmm. Either this function is horribly wrong, or all that stuff must be marked somewhere else 16:51
he Hi, folks. 16:54
I'm trying to build rakudo (for a change), and I'm falling over the error described in groups.google.com/group/perl.perl6....d60aaba76d
jonathan Infinoid: If they're in the constants segment they're differently allocated and would not need marking afaik.
(That is, if they're in the constants segment loaded from some bytecode) 16:55
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...
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:56
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
jonathan Infinoid: Does the same code run under -G? 16:58
Infinoid jonathan: yes
he (the rakudo build is bombing later if I work around this problem, with a different error, of course)
jonathan OK, certainly it's not being marked when it needs to be somehow then.
Infinoid he: hi. It should pass any -O flags if parrot itself was configured with --optimize (not the default) 16:59
I'll double check that, one moment
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.
Infinoid (I build parrot by hand and only very rarely use --optimize, for what it's worth)
he The error I get later is "error:imcc:syntax error, unexpected STRINGC, expecting '(' (''$/'')"
jonathan he: That will happen for sure if you're missing dynops, yes.
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.
purl okay, jonathan.
jonathan *days
he ...and really, *really* wants to use stuff from parrot's build directory (bug?)
Tene Yes, bug.
jonathan I think there's two tools for building dynops and Rakudo is using the old deprecated one. 17:02
Just nobody had chance to update yet.
he I know too little parrot to make sense of the syntax erorrs, though.
jonathan he: It's cryptic. 17:04
nopaste "he" at 158.38.152.119 pasted "syntax errors from rakudo build" (34 lines) at nopaste.snit.ch/16576
he FWIW, here's a nopaste.
jonathan he: Means you're missing dynops.
(Since they didn't compile correctly, as you pointed out.) 17:05
Gotta go to the shops before they close - need some nom and pivo - bbiab
he hmm... (Well, I cut-pasted the gcc, and re-did that part, but perhaps it constructed the lib with them missing...)
(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?
he Yep.
Passing -O2 to gcc made the error go away.
Infinoid hmm, poor buggy gcc. 17:07
he indeed
17:07 deetah joined
deetah hi 17:07
just wondering
17:07 Theory joined
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
deetah: yes, in fact we already have a partially written one in the languages repository, called "c99"
deetah sounds cool. would it make sense to make a parrotOS?
he Infinioid: sure, at the moment I'm just trying to see if I can get it to build with quick & dirty tricks.
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
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
I would suggest --gen-parrot-option=--optimize
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.
he New error: "Parrot VM: PANIC: Out of mem!", apparently 256MB virtual was too small(?!?) 17:11
Doubling...
purl i think doubling is a baffler
deetah Infinoid: a complete operating system that would run on variety of architectures.
(with no recompiling of the binary code)
moderator Parrot 1.1.0 Released | parrot.org/ | 319 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets 17:12
Infinoid every RT counts :) 17:12
deetah: I think it's going to be very resource-heavy compared to the native stuff
deetah resources are getting cheaper
is parrot mature enough? 17:13
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
I think we definitely have some performance issues to work out before ideas like yours could really take off.
deetah i don't need performance at the point 17:15
PacoLinux Infinoid: the problem with gcc has a ticket : rt.perl.org/rt3/Public/Bug/Display.html?id=64930
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
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!
deetah Infinoid: one with a very extensive API that would help people avoid kde vs gnome-like conflicts.
he In other words "rakudo / parrot will never build on my m68k systems" :) 17:18
17:18 ruoso joined
deetah an inter-lingual VM sounds cool for that 17:18
and I guess VM's the most advanced project in the category, isn't it?
he (the icu library already doesn't, for other and more embarassing reasons)
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
he Whee, completed inside 512M on NetBSD/i386 4.0
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:19
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
he Whee: Result: PASS (to rakudo's "make test") 17:26
Infinoid cool! 17:27
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.
Infinoid: if that's what comes out when I try a current rakudo, then "yes".
Infinoid great, thanks 17:30
he I can re-try a couple of my other platforms as well, ppc being perhaps most interesting.
Infinoid that would be great. I'd like to squeeze out any bugs before the release rather than afterwards :)
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:35
he hm, no, sorry -- i've not seen alpha emulated (but that might be just me) 17:38
Infinoid No problem, was just a thought. 17:39
17:40 bsdz_ joined
he at least www.nongnu.org/qemu/status.html says "Dev only" for alpha emulation. 17:41
Whiteknight Infinoid: If the vtable pointer is 0xdeadbeef, it's probably been prematurely GCd 17:43
Also, it never hurts to re-mark things if you're unsure about them. 17:44
PacoLinux threre is an emulator for alpha called es40 : 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
he PacoLinux: interesting...
(although I have my fair share of actual alpha hardware :) 17:46
Whiteknight Infinoid: They definitely need to be marked
Infinoid [09:54] <@jonathan> Infinoid: If they're in the constants segment they're differently allocated and would not need marking afaik.
Whiteknight Unless they're being allocated from the constant PMC pool, they definitely need marking
17:46 Andy joined
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?
Whiteknight nope
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 nopaste.snit.ch/16577 17:49
Infinoid I'm not sure this mark_1_seg function's even being called.
Infinoid will trace around in gdb 17:50
Parrot_gc_mark_and_sweep is run surprisingly often for such a simple test script 17:52
Whiteknight yeah, we definitely need to slow down the pace of that 17:54
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:55
I imagine loading a packfile creates lots of objects, but sheesh 17:56
dalek rrot: r38871 | allison++ | trunk/DEPRECATED.pod:
[cage] Deprecation notice for the name 'Hash'.
 17:57
Whiteknight Well, it doesn't help that we're allocating arenas that only contain space for 64 objects to start 17:59
let me work on a patch for you to try and cut that down
Infinoid 64 does seem like a silly starting point, but if the allocation size increases exponentially, it shouldn't be too bad 18:00
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
Infinoid purl, thanks for that
purl de rien Infinoid
Whiteknight ??? Did I just get told, by a bot?
Infinoid is it a #define? I'm not sure where to find that
nah, purl is just being useless
Whiteknight src/gc/pools.c:104
bump the number up to 1024, that should cut down the number of gc runs significantly 18:03
we really should be figuring out an optimal number based on native page size
but that's another project for another day 18:04
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
i was looking at the wrong thing
Infinoid oh, I won't benchmark rakudo with it then :) 18:06
he NetBSD/macppc (powerpc) 5.0 parrot-current Result: PASS 18:08
Tried to upload via "make smoke", but apparently smolder.plushtree.com is unresponsive. 18:10
Infinoid Yeah, it's been having problems
Whiteknight okay, apparently pool sizes for PMCs are allocated with size (10240/sizeof(PMC)) 18:13
so that's a little bit weird of a number to use
I feel like it should be PAGESIZE/sizeof(PMC) 18:14
if we extend an arena beyond the size of a page we're going to lose a lot in virtual memory performance
Infinoid goes and looks up what PAGE_SIZE is on amd64 18:16
oh, still 4k. 18:17
sizeof(struct PMC) is 48 on amd64, which means there are 85.3333 PMCs per page
depending on the size of a cache line, that may or may not be a performance issue. 18:18
anyway, 85 PMCs isn't much, the number of arenas is going to get rather huge 18:19
so if we're tied to one page per arena, it is crucial to scale well to large numbers of arenas
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
s/wa/was/
the size of the map doesn't affect the time it takes to do a page table lookup 18:22
nor should it affect the number of TLBs used in total, unless I'm misunderstanding something 18:23
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 :)
Whiteknight okay I'm out. later 18:27
Infinoid thanks for the help
benjaminvm I have a flag I need to add to every c file, where do I add it? 18:30
dalek rrot: r38872 | allison++ | trunk/t/pmc/io.t:
[cage] Unskipping test failure from Ubuntu 6.10.
Infinoid benjaminvm: A compilation flag (command line), a #define, or what? 18:34
benjaminvm Compilation flag, -finstrument-... 18:36
Infinoid probably CFLAGS
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:38
benjaminvm I also need to add a .c file to trace the call stack. 18:43
I add that to config/gen/makefiles/root.in? In what section? 18:44
18:44 Ademan_ joined
Infinoid benjaminvm: Try adding it to the INTERP_O_FILES list 18:45
Coke seen alias?
purl alias was last seen on #perl 22 minutes and 0 seconds ago, saying: The module being either Term::ReadLine, or possibly Term::ReadKey
benjaminvm Infinoid: Thanks for the help. I will try that.
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:50
well, I guess I found my answer in r33401 18:53
Infinoid flh: Yes, you're right. Patches welcome. 18:54
flh I'll try to do that tonight 18:55
19:07 iblechbot joined
he Confirmed: "perl ./Configure.pl --gen-parrot --gen-parrot-option=--optimize" gave me a perl6 and completes "make test" 19:18
Follow-up posted to rt.perl.org/rt3/Ticket/Display.html?id=64930 19:19
19:20 donaldh joined 19:32 kid51 joined 19:35 HG` joined
he Gah, rakudo / perl6 spectests needs more than 512m. 19:43
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) irclog.perlgeek.de/parrot/2009-05-13#i_1138997
dalek rrot: r38873 | Infinoid++ | trunk/PLATFORMS:
Update PLATFORMS for my own platforms and reports in #parrot.
 19:47
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.
Infinoid PacoLinux: sounds like it fails while running spectests, not building 19:50
(but thanks, I was looking for a link to that earlier) 19:51
dalek rrot: r38874 | Infinoid++ | trunk (3 files):
[pdd13] Spec says PackfileDirectory should handle deletions. Add that vtable and test it.
rrot: r38875 | Infinoid++ | trunk (2 files):
[pmc2c] Line numbering isn't quite right, fix it (and add tests).
Infinoid Ok, that's all the parrot time I have for today, bye all 19:53
19:55 Theory joined
dalek kudo: 2949868 | jnthn++ | perl6.pir:
Make sure backtraces are printed to STDERR; printing them to STDOUT outrages masak++^W^Wis very wrong.
 20:06
20:12 particle1 joined
he Infinoid: NetBSD/alpha 4.0 parrot-current Result: PASS 20:18
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:23
nopaste "flh" at 88.160.47.207 pasted "Custom Object instead of a FileHandle" (16 lines) at nopaste.snit.ch/16578 20:26
flh should this code work?
Infinoid he: thanks, I'll update the file 20:28
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
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
flh Infinoid, adding eof and get_bool doesn't change anything 20:32
Infinoid Okay, that's a bug then. Please create a ticket for it at trac.parrot.org/parrot/ 20:33
Coke is this already covered by our various "can't subclass a PMC" tickets? 20:45
(man, is checkout out the parrot repo via tortoisesvn slow)
s/checkout/checking/
man, would it be faster if I just got trunk.
Tene makes a new branch 20:46
Coke hey, don't you already have a branch going? =-) 20:47
Tene I do?
flh Coke, I'm not sure it's a "cannot subclass PMC" problem, since I'm not subclassing anything there 20:48
Coke oh, I assumed you were subclassing the PMC. 20:50
ticket away, then.
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
which seems like it should work
(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
dalek kudo: 1203649 | masak++ | t/spectest.data:
[spectest.data] added S13-overloading/operators.t
 20:52
Coke Infinoid: because the design is only done in chunks. 20:53
IME, most of the reasons things are where they are is "historical.". :|
(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
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
If we do, I'd prefer to see something P5-like, with a base class of IO::Handle.
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)
And eof() is only meaningful for SOCK_STREAM and SOCK_SEQPACKET, not SOCK_DGRAM or SOCK_RDM 20:56
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.
Infinoid Ah, could be
Coke not from the rewrite that occurred in the past few years.
Infinoid flh could just call the "read" method on his shiny new class directly, but I don't think that would prove much
Coke be interested to see if it worked.
s/ed/ing/
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?
(the branch)
make -j is borked. 21:00
Tene Coke: very dead
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 nopaste.snit.ch/16579
dalek rrot: r38876 | tene++ | branches/pct_hll:
Remove old branch. Coke++
 21:04
rrot: r38877 | tene++ | branches/report_hll_info:
Remove old branch. Coke++
bacek morning 21:05
Infinoid: (packfile test) Erm. Looks like it was my mistake.
nopaste "tene" at 166.70.38.237 pasted "inter-language library loading sketch - now with more linebreaks" (46 lines) at nopaste.snit.ch/16580 21:06
Coke infinoid, did you just fixup pmc2c line directives?
tene, I didn't even get to bug you about the other branch! 21:07
you're no fun. =-)
Tene Coke: want me to put it back?
Coke "I had no idea it would be so much, I won't pay."
Infinoid Coke: yes, did it break anything?
bacek: cool then, 2 new tests for the price of 1. 21:08
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.
Infinoid: can you glance at RT#56792 ? 21:10
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
... but since tcl is dead, meh.
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:13
I suppose the easiest way to fix that is to take the number of lines in the heredoc, and subtract that from __LINE__ 21:16
cotto Andy, ping 21:18
21:19 nopaste joined
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
bacek cotto: If you are working on VTables in pmc_pct branch can you change VTableInfo to be PAST::Node? 21:26
cotto ok 21:27
any particular reason? 21:28
purl any particular reason is there any inherent flaws im not seeing just yet?
bacek Look in default.pm. If VTableInfo is PAST::Node we can just .clone it and add body.
cotto sounds nice 21:30
bacek Or you can add .to_post method to VTableInfo. Flip the coin to choose :) 21:31
cotto I'll play around with it.
nap time
purl i heard nap time was perl -e 'say "Zz" x 99 and sleep 3600'
bacek wow. 21:32
purl: good girl :)
purl :)
bacek Infinoid: what is deprecation policy for PackfileAnnotationKeys? It wasn't implemented in 1.0. Just stubs. 21:33
dalek rrot: r38878 | bacek++ | branches/tt504_annotations/src/pmc (2 files):
Proposed changes to PackfileAnnotations/PackfileAnnotation.
 21:34
21:37 allison joined
Infinoid bacek: I'd say go for it. It never worked, so noone will be relying on it 21:38
bacek Infinoid: ok. 21:39
dalek rrot: r38879 | bacek++ | branches/tt504_annotations/docs/pdds/pdd13_bytecode.pod:
[docs] Update pdd13 PMCs.
 21:40
bacek msg jonathan Any objections about r38879? I dropped PackfileAnnotationKeys and hide guts in Annotation. 21:41
purl Message for jonathan stored.
moderator Parrot 1.1.0 Released | 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:42
allison how about that language example tests one? 21:44
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:45
I kind of like having examples/languages/squaak have a t/ directory, as an example to new language devs 21:46
22:07 ruoso joined
Tene allison: mind looking over nopaste.snit.ch/16580 ? 22:10
allison Tene: sure 22:13
Tene allison: specifically, think that would work for pynie? 22:14
allison If fetch-library is a method, why not have it accept named arguments, instead of manually building a hash? 22:15
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
i guess we could require fetch-library to have a slurpy named param...
allison I'm not quite sure what this is doing. Is it Export, or load_bytecode? 22:18
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?
Tene fetch-library would be called from another language's "use" or "import"
Yes.
allison then, let's call it 'load_library'
Tene OK
the reason I chose 'fetch' over 'load' is what it returns. 22:20
and if a language caches libraries, there might be no loading going on.
allison how is the return value used?
Tene by the calling language, to import symbols into its local namespace
use Foo::Bar:lang<python>;
dalek rrot: r38880 | bacek++ | branches/tt504_annotations (2 files):
Reimplement unpack Annotations using new PMCs API
allison and, yes, it might not be loading if it was already loaded, but you're requesting it to be loaded
(as in, that's the main thing you're asking for)
22:21 gryphon joined
Tene the main thing I'm asking for is the symbols, which will probably require loading. :) 22:21
But, sure.
I don't object to 'load_library'. 22:22
allison agreed on having name as a key, rather than a string (each language has different delimiters) 22:23
thinking about the export interface...
is it intended that the only way to call a function from another HLL is to import it into your HLL? 22:24
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
Or eval.
allison good
Tene eval($whatever, :lang<python>); 22:26
allison namespaces already have an 'export_to' method, which is preferable to this way of importing 22:27
it even accepts a list of symbols
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
22:28 rob joined
allison I'm not sure any language except Perl even uses exports this way 22:28
Tene Neither am I, but I'm very much not confident on my knowledge of esoteric languages. 22:29
That's why I was trying to avoid unnecessary restrictions.
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.
allison rather than 'symbols', I'd rather see a pointer to 'namespace'
namespace already has a language-neutral way of looking up symbols 22:31
so, we don't need to duplicate it
Tene OK
rakudo, then, should just set the ::EXPORT::ALL namespace as the namespace returned? 22:32
I guess that's not too bad.
allison mmmmm... I don't know what the current problems are with other languages using Perl libraries
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.
allison mmm... well, the look up the namespace, and then look up a sub
it's not convenient
and definitely needs work
Tene No HLLs provide a way of doing that. 22:34
dalek rrot: r38881 | bacek++ | branches/tt504_annotations/t/pmc/packfileannotations.t:
[t] Split Annotations.test_unpack into loading and checking parts.
Tene Except maybe eval.
rrot: r38882 | bacek++ | branches/tt504_annotations/t/pmc/packfileannotation.t:
[t] Update packfileannotation.t
rrot: r38883 | bacek++ | branches/tt504_annotations/t/pmc/packfileannotationkeys.t:
[t] Remove packfileannotationkeys.t
allison Tene: ah, the HLLs aren't using the feature, okay, makes sense
Tene: and, making it more convenient will make them more likely to use it
Tene Yes.
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
if not, every language needs to know the details of how every other namespace defines a library, the search path, etc.
Foo::Bar vs Foo.Bar vs Foo\\Bar wtc.
etc.
allison yup 22:36
I like the idea of requiring a method on the compiler object
(which HLLCompiler will provide by default)
Tene Yes. 22:37
allison overall this looks workable 22:38
oh, side question, why the 'getinterp'?
Tene to get the caller's namespace to put the symbols in.
Is there a better way of retrieving that? 22:39
allison 'get_namespace'?
Tene how do you know which namespace you were called *from*?
Not your current namespace, but the namespace of your caller.
module Foo { use Bar; } 22:40
allison ah, you're digging back on the stack to the last namespace
Tene the symbols from Bar should be exported to the Foo namespace, not whichever namespace 'use' is defined in. 22:41
Right.
allison that's icky
we need to encapsulate that
Tene Is there a better way to get that information?
allison Tene: no, there isn't
but there should be :)
22:41 contingencyplan_ joined
Tene Ah, OK. 22:41
allison: is this scheme workable with pynie? If so, are you okay with me implementing it? 22:42
also, is today too soon before the release to be adding this stuff to HLLCompiler?
allison yes, generally workable
and, yes, wait til after the release to commit
rob Just implemented namespace support in porcupine
Tene OK
rob: what's porcupine?
rob although its only single tiered
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
allison Tene: so, we'll have to fix that at the same time
Tene allison: this isn't for other libraries... this is what rakudo currently uses for "use".
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
but, if we're going to be using caller information this way, it needs a better interface 22:45
Does Rakudo actually loop over the symbols in the namespace to export them rather than using 'export_to'?
Tene Yes.
allison Does 'export_to' not work for Rakudo, or was there some other motivation? 22:46
(the first might mean it needs fixing)
Tene No idea. I didn't write it. I suspect whoever did just didn't remember it.
bacek Whiteknight: (TT#685) "perl Configure.pl --no-line-directives" was implemented few weeks ago. Or you want more fine grained switching?
Tene Lemme change it and see.
building... 22:48
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.
"NOTE: exporting ’default’ set of items is not yet implemented."
allison yes, it needs a list of names, which is what you have there 22:50
imports = library['symbols']['DEFAULT']
(at least, I'm assuming that's a list of names)
what's Rakudo iterating over, if it's not a list of names?
Tene allison: I assumed that it was something that implemented a hash interface, probably a namespace.
allison then we'd need multiple copies of the namespace object, with different symbols 22:52
is that what Rakudo does now?
Tene allison: rakudo stores all exportable objects in a subnamespace, EXPORT::ALL, with the default set in EXPORT::DEFAULT 22:53
so yes, it has different namespaces with keys that point to the same objects.
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:54
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.
Whiteknight bacek: I never heard of that one. I'll test it
Tene allison: AFK 22:56
Thank you for input. :)
allison Tene: looks like a null argument to 'export_to' does the 'default' set of exports
Tene: which is not implemented :) 22:57
Tene: okay, later
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
Whiteknight thanks bacek++
bacek Whiteknight: It wasn't implemented by me :) 23:00
Whiteknight i don't care who implements it, I care about the people who points it out to me 23:01
bacek :) Fair enough
Can you close ticket? 23:04
rob does examples/tcl/tcltkdemo.pir work for anyone? 23:05
Infinoid Whiteknight: Hmm, I thought I just fixed #line in pmc2c output. Is it still busted? 23:10
Whiteknight I don't know if it is "fixed" or not, I just want it not to exist 23:11
bacek: Yes, I will close the ticket
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
Even though it's never been perfect, it's a maintenance burden, and everyone keeps breaking it
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
(which is what annoyed me enough to fix it this morning, at least for code coming from the .pmc file itself)
If we do get rid of the line annotations for PMCs, we should do the same for ops 23:16
23:20 donaldh joined
Infinoid pmc2c.pl also has a --no-lines option. 23:21
he Hm, ./Configure --optimize fails on NetBSD/shark (arm) 4.0 with a gcc ICE 23:27
Infinoid Got a log? 23:28
he Sure. I'll nopaste the tail of it.
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 nopaste.snit.ch/16581
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
what's a gcc ICE? sounds like an interesting trick... native is slow.
oh, my, looks like gcc fail
he ICE = Internal Compiler Error 23:32
Infinoid oh. (for some reason I thought of In-Circuit Emulator, my bad)
he heh
Whiteknight Infinoid: I thought the same thing
he I'll re-try without optimization.
Only the second gcc bug rakudo or parrot has uncovered today at this end. 23:33
Infinoid "To boldly crash where noone has crashed before" 23:34
Whiteknight how do we tell from C if a particular PMC is a PIR-defined class? 23:53
or, an object of a PIR-defined class
I was going to use "if (p->vtable->pmc_class->vtable->base_type == enum_class_Class)", but that seems so inelegant 23:55
Infinoid hmm, good question 23:56
purl Yeah, it is. I'm stumped.
Whiteknight actually, that code snippet wont even work because built-in PMCs won't have a class pmc in the vtable 23:57
if(p->vtable->pmc_class && p->vtable->pmc_class->vtable->base_type == enum_class_Class) 23:58
and tell me that's not some smelly code
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
Infinoid in the scheme of things, that code is a lot cheaper than calling through PCC would be

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!