Parrot 0.6.0 "P&P" released | Please mentor for SoC | parrotcode.org/ | YAPC::NA talks deadline is Mar 31 | tinyurl.com/2pmnlq
Set by moderator on 18 March 2008.
cotto_work Infinoid, yes afaict 00:00
Infinoid the patch looks awesome, but I'm wondering if it will catch some extra headers you didn't want
guess if it builds, that's proof that it didn't. :) 00:01
Coke why don't I want *all* the headers? 00:06
the pmc's depend on parrot/parrot.h - if that isn't included...
that patch is borked, btw. moment.
Infinoid Coke: depending on things in /usr/include/ is bad 00:07
Coke pastebin.com/d18e2f195 00:08
Infinoid (especially if you then prepend a "src/pmc/" to them)
Coke ok. moment. 00:09
Infinoid don't worry too much... if everything built, that means nothing depends on external headers, which is a good thing
Coke nothing does.
but moment.
00:15 Sartak joined
Coke one of these depends on a .str file. 00:17
one of them includes ../src/io/io_private.h - where is that path relative from? 00:21
Infinoid relative to the location of the source file 00:22
(or header file, whatever file contains the #include line)
Coke that's in one of the pmcs. 00:23
src/pmc/../src/io/io_private.h isn't right. =-)
Infinoid yeah, that does look wrong
Coke but it must compile or we'd have seen it before, neh?
oh. duh, it's relative to ./include 00:24
Infinoid is it split out by pmc2c? 00:25
or just relying on the -Iinclude?
00:26 darbelo joined
Coke the latter 00:26
purl the latter is better
00:27 rdice joined
Coke pastebin.com/de49c558 has an updated patch that builds on linux. 00:27
otto... I'm working on this right now. 00:28
cotto_work thanks
Coke oh, that's from 6 hours ago. =-) 00:29
cotto_work: try that patch. 00:30
that generates a proper dep line for src/pmc/role.o
(testing on windows...)
cotto_work did you notice that most of those includes are unnecessary/redundant? 00:32
Coke nope! =-) 00:33
checking.
like what?
include/parrot/parrot.h ?
cotto_work all the pmc_* includes except pmc_{object|class}.h in {class|object}.pmc 00:35
parrot make and make test run fine if all the other includes are commented out
s/parrot//
Infinoid cotto++ 00:36
Coke just because it's a dep on a static file doesn't mean it's not a dep.
I'm putting in *all* the missing deps that file has, regardless of whether it's a generated file or not.
doesn't matter for joe-parrot-builder, but for a developer who is changing one of the included .h files, that's important. 00:37
Infinoid for build deps, sure, but isn't cotto talking about the #include lines themselves? 00:38
Coke that's SEP. =-) 00:39
cotto_work yes, I'm talking about the explicit #includes in the .pmc files
Infinoid ok. but if it doesn't include the other file, it doesn't need a build dep either
Coke well, if those are removed, then the deps will vanish the next time someone builds the makefile. =-)
Infinoid ok :) 00:40
00:40 particle joined
tetragon Bleh, parrot stopped building 00:41
Coke recent revision? what os? 00:42
tetragon OS X 10.5.2, ppc
Current rev
Coke can you nopaste/pastebin the build error?
tetragon And I know the manual changes I have to do to the makefiles didn't kill the missing rule 00:43
Coke I did just change somethign that gens the makefile, so it's a likely culprit.
which revision?
(i mean, do you have a before and after?)
particle: can you test something for me on windows? applying a patch is murder. 00:44
particle k
tetragon Just after, it built a couple days ago
Coke pastebin.com/de49c558
tetragon pastebin.com/m47e4d2b8 00:45
Coke tetragon: you shouldn't be compiling jit at all, methinks.
tetragon I'm not explicitly telling it to do that
Limbic_Region Coke - I have access to Win32/MinGW and Win32/Cygwin if testing all variations is required 00:46
Coke I figured, but I'm fairly certain jit is still borked on ppc, so I'm not sure why it's building.
tetragon Hrm... some of the darwin stuff is using deprecated functions
Coke Limbic_Region: Doubtful, but if you're feeling paranoid...
tetragon: yup. open ticket on that somewhere. 00:47
(patches welcome, in a not at all snarky way.)
Limbic_Region nope, just offering what little contribution I provide these days
tetragon I was preparing to see if I could convince this thing to build without requiring manual Makefile edits
tetragon grumbles about Apple's /usr/bin/perl being built as a universal binary 00:48
Coke tetragon: you shouldn't need manual edits at all. :|
ah, is that why? 00:49
tetragon Back when builds still worked for me, it would trip over i386 assembly
Coke probably a matter of smartening up the darwin hints file to pick one or the other and not both.
cotto_work Coke, I'm not seeing any build failures so far.
tetragon Apple's perl includes '-arch i386 -arch ppc' in its build flags, which causes parrot to try to build itself as universal
particle coke: realcleaned, applied patch, configured, building now 00:50
Coke particle: danke. 00:51
particle build succeeds. testing now 00:55
particle bets the t/configure tests are as repetitive as the t/steps tests 00:56
Coke particle: if the build worked, it worked.
particle sure. commit it. i'm still gonna test it :)
course, i can't test nmake -j 00:57
that's not a valid option :(
Infinoid hmm, I should test -j on mingw sometime
dalek r26678 | chromatic++ | trunk:
: [GC] Fixed build for --gc=libc (Senaka Fernando, RT #52332).
diff: www.parrotvm.org/svn/parrot/revision?rev=26678
particle wonders when our svn revision will surpass our rt number 00:58
tetragon Coke: Some people would want both -arch flags 00:59
Coke tetragon: well, sure, if it built... but if it doesn't...
tetragon Coke: I haven't tested on my Intel yet... 01:00
Coke: I find universal builds tend to work there better than on ppc
cotto_work looks like the make race condition is gone
as am I
thanks for fixing that 01:01
dalek r26679 | coke++ | trunk:
: [build]
: Resolve #52316 ([BUG] undeclared dependency between role and namespace PMCs).
: cotto++ for diagnosis.
diff: www.parrotvm.org/svn/parrot/revision?rev=26679
Coke goes to find the old open ticket about the darwin deprecation so he can merge the new bug with the old one... 01:02
particle # Trailing space or tab char found in the following files: 01:08
# C:\\usr\\local\\parrot\\trunk\\config\\auto\\pmc.pm 131
Coke grumbles.
Coke can't find the old ticket he is sure that is a duplicate of. ah well. 01:13
Tene Coke: open a ticket about it. 01:15
Coke you funny. :p 01:16
Tene I certainly think so. :) 01:17
tetragon I found a build from a couple days ago. It has jit built 01:18
dalek r26680 | coke++ | trunk: 01:19
: [codingstd]
: remove trailing whitespace introduced by myself and other villians.
diff: www.parrotvm.org/svn/parrot/revision?rev=26680
Coke tetragon: hokay. 01:21
dalek r26681 | coke++ | trunk: 01:25
: [oops]
: Undo accidental commit included in r26680. Villians, indeed.
diff: www.parrotvm.org/svn/parrot/revision?rev=26681
Coke wonders if anyone has thought about how we're going to do MMD without type ids. 01:52
01:53 grim_fandango joined 02:17 arbingersys joined
wknight8111 what is MMD? 02:18
purl i think MMD is the media database...do not hurt
wknight8111 thanks purl, you're a lifesaver
Infinoid purl: no, MMD is multi-method dispatch 02:27
purl okay, Infinoid.
wknight8111 Multi-method dispatch? looking that up now.... 02:28
haha, it's reassuring when the documentation says "Part or all of this document is outdated" 02:29
Infinoid if you have multiple methods of the same name, MMD is the process of finding out which one to call, based on the types of arguments you've passed
wknight8111 oh. Suddenly I see what coke is worried about
without explicit data types, matching prototypes is going to suck mad nutz 02:30
Infinoid type ids would help, indeed
wknight8111 excuse my internet slang
Infinoid :)
making MMD as easy (and foolproof) as possible would seem like a good thing, to me.
purl, without explicit data types, matching prototypes? 02:32
purl well, without explicit data types, matching prototypes is going to suck mad nutz
Infinoid sorry, had to.
02:33 contingencyplan joined
dalek r26682 | duff++ | trunk: 02:42
: [config] git URL might not be https and it might not be of trunk
diff: www.parrotvm.org/svn/parrot/revision?rev=26682
02:42 grim_fandango_ joined
dalek r26683 | infinoid++ | trunk: 02:56
: [raduko] minor change to pass t/codingstd/trailing_space.t
diff: www.parrotvm.org/svn/parrot/revision?rev=26683
Infinoid Coke: should I check in your amd64 t/compilers/imcc/syn/regressions.t workaround? 02:58
Infinoid doesn't want to paper over the fact that something is weird on amd64, but maybe the open ticket is enough. 03:02
wknight8111 what is weird about amd64? 03:23
i guess i haven't read enough bug reports yet 03:24
Infinoid something is being optimized differently enough to break a test
see the last post on rt.perl.org/rt3/Ticket/Display.html?id=43048
I'm not too familiar with IMCC (thankfully), but apparently all situations where the "div_i_ic_ic" was to be useful are supposed to have been optimized away. so it was considered fair game to remove the op. which uncovered the fact that apparently it isn't being optimized away on amd64, though everything seems great on x86 03:26
or something like that.
wknight8111 that is weird that PIR would behave differently on the two platforms. 03:27
Infinoid sounds like a bug, doesn't it?
03:27 Ademan joined
wknight8111 maybe amd64 has some strange floating point bug, like a problem representing 0.0 03:28
of course, it's rarely productive to assume that the error lies in the hardware
Infinoid hah. well, this is an Intel chip, so I wouldn't put it past them
wknight8111 i would like to see a hex dump of the floating point results out of the imcc parser, see if it's generating the proper values for 0.0 03:29
Infinoid I would have thought such a bug would have been discovered, advertized and worked around by now.
but then again, very little of the stuff I do uses floating point at all. 03:30
if you give me a command line I can run, I will run it
(as I said, I'm IMCC-clueless)
wknight8111 i wouldn't know how to do it either, i'm not big on imcc internals either 03:31
Infinoid ./parrot --target=imcc-parse-results-thingy
wknight8111 and i dont have an amd64 laying around here, so i cant play with it
Infinoid that's odd. 03:46
nopaste?
purl i guess nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or paste.husk.org/ or poundperl.pastebin.com/ or paste.scsys.co.uk/ or don't bother me while I'm eating
Infinoid rafb.net/p/w27OrL16.html 03:48
apparently div_x_xc_xc is shorthand for a class of ops that includes div_i_ic_ic ? 03:49
with -D I can see that parrot did attempt compile time constant folding, and got a real_exception (Divide by zero) 03:50
so presumably it fell back on the runtime op 03:51
and the same thing happened on x86, except for the runtime failure
parrot's debugging flags aren't helping. time for gdb... 03:55
looks like gdb loves continuations almost as much as I do. 04:10
ok.... here's where behavior starts to diverge 04:20
compilers/imcc/parser_util.c line 648: ins = IMCC_subst_constants_umix(interp, unit, name, r, n + 1);
oops, try again 04:21
compilers/imcc/parser_util.c line 653: ins = IMCC_subst_constants(interp, unit, name, r, n + 1, &ok);
both x86 and amd64 return NULL
however, x86 sets &ok to 11, amd64 leaves it set to 0.
I'm actually not sure whether that ok=11 thing was a stack smash, or somehow valid. 04:25
longjmp--
04:30 liona29 joined 04:32 davidfetter joined
tetragon The make rule that my system is tripping over didn't exist a couple days ago 04:32
Infinoid which rule? 04:33
tetragon $(SRC_DIR)/exec_dep.c
Infinoid fixed some Makefile stuff for "make -j", and possibly broke some other stuff
tetragon It works in i386 since the file src/jit/i386/exec_dep.c exists, but there is no file by an equivalent name for ppc 04:34
Infinoid and jit is somehow being detected on your platform, despite being ppc? 04:35
tetragon There is a jit directory for ppc and it built on the weekend
Anyway, the build is proceeding smoothly with the new rule commented out 04:36
And if an equivalent rule gets pumped out no matter which platform, I can already see that ARM'll break 04:37
Infinoid when in doubt, blame chromatic. do you think it could have been r26636 ?
that's where i386/exec_dep.c was created, and a corresponding ppc/exec_dep.c wasn't. 04:38
and that's where the rule was added, too
tetragon Build didn't complete, fell over the missing object exec_dep.o 04:39
Infinoid www.parrotvm.org/svn/parrot/revision?rev=26636
tetragon Looks like chromatic can be blamed 04:40
That commit appears to fit the bill
Infinoid svn merge -r26636:26635 .
if that fixes it, flame away :)
(you'll need a realclean/reconfigure after that) 04:41
tetragon The majority of the commit looks to be moving exec_dep.h contents into exec_dep.c 04:42
Infinoid looks at RT#47289 04:43
aaw, I don't know that we can blame chromatic after all. not fully, at least. :( 04:44
04:44 petdance joined
Infinoid reopens it 04:45
tetragon notes that her build is now at jit 04:46
Infinoid any luck? 04:49
tetragon I determined that I forgot to clean the tree sufficiently before that build 04:50
(Where that build is the one that had just reached jit) 04:51
At the very least, my -arch flag stripping is working
I don't have to edit every generated makefile in the tree to remove them
But I'm back at jit 04:52
Infinoid ok. please post a followup to RT #47289 when you've finished your testing
tetragon It succeeded in building jit
Now I just have to wait the rest out
Infinoid I reopened that ticket and posted a description of the problem 04:53
04:53 chromatic joined
chromatic I think I can fix the JIT problem. 04:53
Infinoid great!
chromatic Which platform has the problem?
Infinoid ppc
chromatic Good.
tetragon There are others that do, but not encountered yet 04:54
Infinoid good luck with it, I'm outta here. 04:55
thanks for the quick response, chromatic
chromatic You're welcome. 04:56
tetragon With that merge, parrot built
04:56 jrockway joined
chromatic It looks like ARM will also have the problem. 04:56
tetragon The ARM I have laying around has neither Perl nor gcc on it 04:58
chromatic I know what the problem is there too, fortunately. 05:00
r26684 should work unmodified for you.
tetragon The appropriate .c files weren't created?
dalek r26684 | chromatic++ | trunk:
: [JIT] Fixed the JIT build on PPC accidentally broken in r26636. This also
: finishes more of what RT #47289 tried to accomplish. 05:01
diff: www.parrotvm.org/svn/parrot/revision?rev=26684
chromatic Right. 05:03
tetragon I'll test in a few minutes, need to relocate my computer
dalek r26685 | chromatic++ | trunk: 05:05
: [JIT] Fixed the JIT build on ARM accidentally broken in r26636. This also
: finishes more of what RT #47289 tried to accomplish.
diff: www.parrotvm.org/svn/parrot/revision?rev=26685
05:14 tetragon joined
tetragon chromatic: Build failed 05:21
Syntax error 05:22
pastebin.com/m4f813132 05:24
I'm taking a quick look at it
chromatic Me too. 05:25
tetragon Is it just me, or do both clauses of #if JIT_CGP in exec_dep.h have identical contents 05:27
chromatic What if you include "jit.h" in src/jit/ppc/exec_dep.h? 05:28
Good catch.
tetragon Same error, error message line numbers offset by one
chromatic How about also jit_emit.h? 05:29
tetragon Same error, offset two 05:30
chromatic It doesn't understand Parrot_jit_info_t, but that's defined in jit.h. 05:32
Can you do 'make realclean; perl Configure.pl; make' again? 05:33
make -j <n> should be fine
tetragon Don't worry, this little ppc only has one cpu
chromatic Still goes faster this way.
tetragon On this box, the thing that recently sped it up the most was tweaking it to automatically strip out the -arch flags it got from Perl 5 05:34
Same error 05:39
chromatic Bizarre.
purl vous avez dit "bizarre" ?
chromatic oui 05:40
I'll have to pull out my PPC and try it then. 05:42
ewilhelm when did parallel make start working?
tetragon Grr... When I went from "make -j2" to a plain old "make" it decided to rebuild
(Not rebuild as in start working)
chromatic Infinoid and Coke made it work in the past couple of days. 05:43
tetragon Actually, I'm trying a change to the file that I think will fix it
ewilhelm sweet. Infinoid++; Coke++
ewilhelm mentions distcc 05:44
chromatic Yeah, if you want to have multiple machines running simultaneously. 05:45
ewilhelm heh, does it work on ppc?
you could get about 10 of those for $200 now or so right? 05:46
chromatic If you want to burn that much electricity yeah!
tetragon And i386 works?
chromatic Yes. 05:47
ewilhelm (hmm... put a cross-compiler on your real machine and use the ppc just for disk) 05:48
chromatic Scratch-that Computing indeed! 05:49
tetragon It works now 05:50
I stuck #include "parrot/parrot.h" into exec_dep.c 05:51
pastebin.com/m7bddf9d2 05:52
chromatic That's all it took?
tetragon Yes 05:53
chromatic Alright, I'll patch the other files.
tetragon Wait... linker failed
ld: duplicate symbol _ppc_flush_line in src/jit.o and src/exec_dep.o 05:54
The symbol is definitely in both, text section 05:55
chromatic It's in jit_emit.h 05:56
tetragon I'll remove that #include from exec_dep.h
Now the compile fails 05:57
chromatic Remove both includes from exec_dep.h and copy the #include block from src/jit/i386/exec_dep.c into src/jit/ppc/exec_dep.c
lines 18 - 22 05:58
tetragon compile succeeds 05:59
Looks like the link succeeded 06:00
chromatic Now the real test
TEST_PROG_ARGS=1 prove t/op/*.t
(provided you're using bash or a bash-workalike)
tetragon I'm on a Mac, I get bash by default 06:01
And I get a whole stack of failing tests
chromatic It was tcsh for a while.
tetragon They switched to bash a couple major releases ago
chromatic Er, I mean
TEST_PROG_ARGS=-j prove t/op/*.t 06:02
tetragon Not nearly as many failing tests
chromatic That's better. 06:03
tetragon I got one sigbus so far
chromatic Not too surprising.
tetragon Either in t/op/interp.t or t/op/jit.t
And one test unexpectedly succeeded 06:04
chromatic info.t?
debuginfo.t?
tetragon Need to run them individually
Neither 06:05
Wait, it was debuginfo
chromatic I'll apply these changes for PPC and ARM, and hopefully that'll solve the compilation problem everywhere.
tetragon And the sigbus was interp.t 06:06
And I got the same sigbus before these changes (and it's on a TODO test) 06:07
chromatic What's the TODO message? 06:08
tetragon not ok 3 - runinterp - works with printing # TODO something funky here
chromatic There's a forehead slapper. 06:09
dalek r26686 | chromatic++ | trunk:
: [JIT] Really fixed JIT for PPC and ARM (thanks to Seneca Cunningham).
diff: www.parrotvm.org/svn/parrot/revision?rev=26686
tetragon I can put up the trace
pastebin.com/m6db3bd3f 06:10
And the prove -v output 06:11
pastebin.com/m7593b46e
chromatic The constant string is invalid for some reason. 06:12
... probably not getting copied correctly from the parent interpreter.
... due to some crazy system-dependent weirdness.
... because it works on x86.
tetragon You're the one on the funky little-endian box 06:13
06:13 TonyC joined
tetragon Time to drop some coredumps 06:14
chromatic I fully admit that the x86 is a patch on a patch on a patch on the 4004, which is the best engineering the '60s had to offer (despite coming out in the '70s), but might I just add that cross-platform arch-independent JIT sucks?
tetragon I now have a coredump of the crash 06:16
chromatic I'm pretty sure I know where it is. 06:24
Do you mind filing these crashes as bugs?
tetragon Even the TODOs? I think I currently have seven of them
chromatic If they succeed, bring them up here. 06:25
Otherwise they're groovy.
tetragon Most of the sigbus crashes are on TODO 06:26
I don't think there are any non-TODO ones left
chromatic That's probably good... but we should probably fix them at some point.
How about this.
If there aren't any RT numbers in the TODO descriptions, file them and I'll add the ticket numbers. 06:27
That way we'll *know* know they're there, instead of just thinking knowing.
dalek r26687 | chromatic++ | trunk: 06:28
: [pobj] Removed a blatant lie from the STRING struct comments.
diff: www.parrotvm.org/svn/parrot/revision?rev=26687
06:31 teknomunk joined
tetragon I'm outright failing t/compilers/imcc/syn/regressions.t 06:38
The non-TODO fails, and the TODO crashes
chromatic Coke made some recent changes there. 06:39
tetragon The TODO already has an RT number on it
Someone else had that one crash 06:40
chromatic Excellent.
tetragon That ticket doesn't have a stack trace, though 06:41
(41097)
chromatic Feel free to reply with one if you like.
06:56 iblechbot joined 08:44 Psyche^ joined
dalek r26688 | kjs++ | trunk: 09:33
: [NEWS] add news about added operators to NQP
diff: www.parrotvm.org/svn/parrot/revision?rev=26688
r26689 | allison++ | trunk: 09:34
: [pdd] Completed the core architectural component of the Strings PDD. Still
: adding API sections.
diff: www.parrotvm.org/svn/parrot/revision?rev=26689
cognominal someone can add to the perl6 status that hash composer is missing and array composer buggy 09:42
09:43 skv joined 10:32 ruoso joined 10:57 kj joined
diakopter notes that [the link to] feather is down. 11:05
11:07 dalek joined 11:08 PerlJam joined, wolverian joined 11:10 jonathan joined, pmichaud joined 11:11 Juerd joined 11:15 leo joined 11:40 kid51 joined 11:42 muixirt joined 11:48 contingencyplan joined 12:17 rdice joined 12:40 particl1 joined 12:41 Infinoid joined 13:06 wknight8111 joined 13:21 skids joined 13:29 IllvilJa joined 13:37 gryphon joined 13:41 ask joined 13:42 ruz joined
wknight8111 is parrotcode.org down? 14:29
pmichaud looks like the dns was hacked 14:30
pmichaud@orange:~$ nslookup parrotcode.org 14:31
Server: 192.168.1.1
Address: 192.168.1.1#53
oops, wrong address -- never mind
<-- tired
ping works to parrotcode.org, but no response on port 80 14:32
wknight8111 ok 14:33
Coke someone volunteer to report the issue (after verifying) to webmaster@perl.org ? 14:53
dalek r26690 | coke++ | type_ids: 14:54
: [tools]
: parrotbug requires a configure'd parrot to work. Be more gentle when
: informing the users about it.
diff: www.parrotvm.org/svn/parrot/revision?rev=26690
PerlJam I just loaded www.parrotcode.org just fine.
Coke particl1: does parrotbug ``work'' on windows? 14:58
14:58 sjansen joined
Coke (or anyone else with windows. =-) 14:59
If so, I think we can resolve RT41601
particle i guess i should ttake a look... 15:00
15:00 peepsalot joined
particle reconfigs and rebuilds 15:03
wknight8111 it appears to be working for me now 15:06
Coke notes that parrotbug just needs a config. 15:13
particle ==> Sending message to recipient...
I am terribly sorry, but I cannot find sendmail, or a close
equivalent, and the perl package Mail::Send has not been installed, so
I can't send your bug report. We apologize for the inconvenience.
So you may attempt to find some way of sending your message, it has
so, i gotta get a module or two 15:14
Coke I assume it tells you where the file was saved?
particle i'll retry after installing them
yep, i must have been throttled away
So you may attempt to find some way of sending your message, it has
been left in the file 'C:\\Users\\particle\\AppData\\Local\\Temp\\bugrep05840'.
that's the text of the message, but not any of the other info (category, severity, etc) 15:15
Coke presumably that's in the file. 15:18
I'd say that's "working". =-) 15:19
Coke finds another email address that might be the guy that owns the macport.
particle i've installed Mail::Send and am trying again 15:31
15:31 Theory joined 15:32 AndyA joined
particle ==> Sending message to recipient... 15:33
Died at C:/usr/bin/perl-5.10.0/site/lib/Mail/Mailer.pm line 284, <STDIN> line 7.
it's b0rk
Coke Ok. if you have time, a patch would be great, otherwise I can take a look at it at home at some point. 15:36
dalek r26691 | coke++ | trunk: 15:39
: [docs]
: "I am happy to report improvements for both cc and gcc since last time I
: ran a full 'make test'." -- Andy Dougherty (RT #52376)
diff: www.parrotvm.org/svn/parrot/revision?rev=26691
15:44 Andy left
Debolaz tries to run a binary perl6 and gets a coredump in his face. 16:07
16:11 jan joined
pmichaud Debolaz: what platform? 16:19
Debolaz Well, it did work for some things, but when I tried to declare a class with a method it went up in flames. 16:22
FreeBSD 7
pmichaud maybe try it with parrot perl6.pbc instead of the binary
or submit it to rakudobug@perl.org 16:23
and we can take a look
Debolaz perl6.pbc worked fine. 16:24
pmichaud hmmmm
must be something to do with compile/link. Or perhaps a GC issue.
I'd definitely report it to rakudobug then
kj using pbc_to_exe-generated executable also blew up my squaak compiler once
17:03 davidfetter joined 17:07 Psyche^ joined 17:08 barney joined
dalek r26692 | bernhard++ | trunk: 17:15
: Let svn ignore the generated, that is copied, file exec_dep.c.
: Clean up exec_dep.c
diff: www.parrotvm.org/svn/parrot/revision?rev=26692
Coke pmichaud: ping 17:42
pmichaud: can you take rt.perl.org/rt3/Ticket/Display.html?id=44447 ? 17:43
even if all you do is add a note about how to move forward? 17:44
17:45 barney joined 17:47 peeps[work] joined
pmichaud coke: sure, I'll take care of it. :-) 17:48
Done. 17:51
17:52 mncharity joined
Coke sehr gut, thanks. 17:52
Coke now has 30 rt tickets. 18:02
44+751+95 18:04
purl 890
barney 45 + 751 + 95 18:08
purl 891
Coke barney: that should refer to the similar ticket for perl6. 18:10
mncharity hi. I'm groveling over the PAST spec, and will likely leave a trail of comments as I go. Questions/comments would be welcome and appreciated. tnx. 18:15
in www.parrotcode.org/docs/pdd/pdd26_ast.html , Var scope() "package" refers to a possible 'namespace' attribute, which is otherwise unmentioned as a possible attribute of Var. 18:19
particle these are better sent to the list, so they're not forgotten.
dalek r26693 | bernhard++ | trunk: 18:20
: [HQ9+]
: No need to load non-existing 'hq9plus_group'.
diff: www.parrotvm.org/svn/parrot/revision?rev=26693
Coke PS in 9 18:21
particle coke: i'll likely be a bit late 18:23
shower &
Infinoid practices his inflection and tone. "Berift of life, it rests in peace! If you hadn't nailed it to the perch, it'd be pushing up the daisies!"
18:27 chromatic joined
chromatic #ps in 2 18:27
mncharity particle: re list post, please feel free? the exercise of <get on some list to be able to post; write post; get off list to return to no-more-cluttered-current state> seems rather a misson creep. 18:28
Coke mncharity: yes, but you're more likely to get results if you inconvenience yourself instead of us. =-) 18:29
mncharity re pdd26_ast.html , similar issue with Var slurpy() mentioning a 'named' attribute, which is not otherwise documented as a possible Var attribute. 18:30
Tene Oh, wow, I'm here again during #ps. 18:33
mncharity re inconvenience, ah, ok - my purpose is synthesizing an IR node set I can use for a few weeks from kp6/redsix/STD5/PAST. the "reports of PAST doc oddities" is a side effect. well, not entirely, also an opportunity to hear "oh, that's gone now, we punted that because x". but what gets done with the observations is out of my mission scope. ;) 18:34
they're basically fyi's. 18:35
particle mncharity: you don't need to join, you only need to mail p2 and wait for a moderator to approve 18:36
chromatic I'm still unclear as to the goal of redsix etc; mind enlightening me or at least attempting?
Coke particle: you back? 18:37
particle yep
PerlJam chromatic: to win! 18:38
oh ... that's probably something different :)
mncharity chromatic: sure, let's see... 18:39
redsix was a 2006 quick (order month) implementation of p6 in ruby. There's a history in svn.pugscode.org/pugs/misc/pX/Commo...006/README , but basically, pugs had gotten stuck, so redsix was written as a non-haskell pugs, set up to boostrap into p6. 18:42
shorten mncharity's url is at xrl.us/biqr5
chromatic What do you get out of the bootstrap?
pmichaud mncharity: named is an attribute for all PAST nodes, not just PAST::Var. (It may be undocumented, yes.) 18:43
mncharity: you're correct that PAST::Var is probably missing documentation for the namespace attribute.
mncharity the project ran over my time budget, and pugs got unstuck for a while, so it became inactive. it occasionally got dusted over the years, but basically hasn't been worked on since. so that's redsix.
re 'named', ah, ok. not just 'name', but 'named' too. got it. 18:44
tnx
pmichaud I agree it's a lot to put on one character difference -- but I went with named to match the parrot calling conventions (which also uses "named") 18:45
'name' is the name of the variable or block
'named' is how it's referred as a named parameter in a call
mncharity re 'What do you get out of the bootstrap?', the ability to work in p6. which is a much nicer language to write language implementation in than p5/ruby/common-lisp/smalltalk/etc/etc. 18:46
as well as being a nice target state.
chromatic You need to have a platform on which to run it though.
mncharity re need platform, indeed. and in so far as some platform doesn't quite match the intended use, there is cost. but there's also a world of effort invested in compilers for assorted languages, etc. some platforms will no doubt give much better performance than others for different aspects of p6. someone suggested yesterday a fortran backend for large-scale numerical computing. :) 18:51
chromatic Yeah, but someone has to write it.
mncharity re one character difference, oh, np, I was just repeating to make sure I understood. 18:52
re 'someone has to write it', or have written it. indeed.
chromatic Is redsix such a platform then? 18:53
mncharity re 'goal of redsix etc', one etc is elf, my current focus. it's a bootstrapped backend (using an external parser, while waiting for STD to become usable, to then become fully bootstrapped). it's intent it to provide people the ability to start creating large-scale p6 programs. pugs never quite got there. 18:56
chromatic What's the underlying platform?
PerlJam mncharity: Say I was such a person, how would I use elf to create large scale perl 6 programs? 18:57
mncharity re 'Is redsix such a platform then?', no. a ruby backend might be interesting, because the ruby object model is looks to be close enough to p6 to be able to use it fairly directly, and thus with fairly low overhead. but while some of the ideas from redsix might be recycled, the redsix codebase is dead. fairly thoroughly dead now that elf is working. 18:58
re elf underlying platform, the current one is p5. a Moose-ish p5 mostly. but a derivative which trades some Moose foundation-for-correctness for a more-hackish-but-faster p5 code, has been suggested. 19:00
re 'how would I use elf to create large scale perl 6 programs', wait a few days? :) svn.pugscode.org/pugs/misc/elf/elf_c_src/README shows how how elf_c, the most recent elf, compiles it self. basically whole-program compilation of the mentioned p6 files. the intent is to get that down to 19:03
something like ../elf_c -x -o ../elf_c1 ElfC.pm . but, 19:04
PerlJam mncharity: how much of STD does elf grok? Or, put another way, what's missing? 19:06
mncharity the dialect of p6 supported is currently quite narrow and kludgey. mostly characterized by "whatever was quick and easy for the bootstrap". vague plan is modularize (so people can easily resume work on the backends they were pursuing before hitting kp6, or longer ago, pugs, limits), less icky IR which can be lived with for at least a few weeks,
and start churning out Prelude, backends focused on conformance rather than convenience, and beginning the slog through the test suite. 19:07
chromatic Do you plan to build everything that Perl 5 doesn't support but Perl 6 needs in Perl 6 then? 19:08
mncharity re 'how much of STD does elf grok', zip. well, I haven't tested it - perhaps some code fragments. but it's using STD_red, a copy of STD hand translated badly into ruby, as an external parser. basically, as STD5 matures, it can become an alternate parser. As it matures enough to be plausibly translated back into p6 (eg, "metholate2"), it can use that. and in some distant day it may be up to parsing STD.pm directly. But very not 19:11
hmm, that was a long entry. if anyone got clipped, sing out.
chromatic "But very not..."
mncharity "But very not rsn." 19:12
19:12 kj joined
mncharity re "Do you plan to build everything that Perl 5 doesn't support but Perl 6 needs in Perl 6 then?", not I. Big picture is I'd like to build most everything in p6. p5 is not a backend which gives me warm fuzzies, but various other people care about it, and it was a plausible place to do the backend bootstrap. my objective with elf is to get other people unstuck. 19:16
chromatic To get people unstuck and able to write Perl 6, you need an AST emitted from a working Perl 6 parser which runs on a working Perl 6 backend? 19:18
mncharity yes. no? 19:19
19:20 allison joined
Infinoid allison: just curious, what's the timeline for concurrency? do we currently do any multithreading? (I'm wondering how effective our testing of Harmony GC will be.) 19:21
PerlJam mncharity: I think you're falling into the same trap as other implementations have. "I'll do all this work so that we can get a minimal Perl 6 going and *other people* can finish it off" is the impression I get from you now.
allison Infinoid: yes, we're currently multi-threaded 19:22
Infinoid: so what we're doing now is implementing the final spec, mainly a matter of refinement and cleanup
Infinoid great, thanks. 19:23
allison Infinoid: I don't know if Harmony's GC is going to work with Parrot, it may be too custom to Java's needs to be useful, but it's worth experimenting 19:24
Infinoid it sounds like they are actively trying to make it standalone. The question is how big the adaptation layer needs to be, right?
chromatic ... and how it finds live objects. 19:25
allison Infinoid: yes, well, or if an adaption layer is even possible
Infinoid: it depends on how great the mismatch of assumptions is
Debolaz It was mentioned earlier that it was at least hoped that version 1.0 of parrot would be ready this year, but when is it expected to be possible to write "real" applications with rakudo, even if not officially condoned and maybe with unstable results?
kj Debolaz: at least you can use the NQP Perl 6 subset :-) 19:26
Infinoid is parrot's 1.0 tied to raduko?
allison Infinoid: I suggested to the SoC student that he focus on developing Harmony's API for as a pluggable GC. That alone is a huge summer project
Debolaz Infinoid: Bound and gagged. :-P 19:27
pmichaud Debolaz: I expect people to be able to write "real" applications with rakudo by this summer
it would help if we knew what features are needed-but-missing
(i.e., for prioritizing)
allison Infinoid: well, having a usable implementation of 2 major languages is one of the 1.0 goals 19:28
Infinoid: currently rakudo and pynie are our top candidates
mncharity re trap, the hypothesis is indeed something like "the reason people are no longer writing p6 is the same reason *I* haven't been - you can't. attempting non-small code in pugs becomes an exercise in working around pugsbugs, which on the inactive codebase, can't actually be fixed. and kp6 is painfully slow (plus perhaps a couple of other issues)" plus the hypothesis
Infinoid allison: well, I'll make sure he doesn't get blocked on the parrot side of things :) 19:29
you're right, though, it does sound like a lot of work.
Debolaz pmichaud: So you would encourage me to try implementing things with rakudo and bitch about it when it doesn't work? :) (Or at least make a note of it:) 19:30
chromatic I'm not sure about it being that much work. A good GC only has a couple of entry and exit points in its API.
pmichaud Debolaz: yes, if you can handle a little frustration at times :-)
allison Infinoid: many thanks
mncharity "if you create a p6 implementation in which people can pursue the things they have already demonstrated interest in pursuing, but give them happy pragmatics (speed, easy customization and stability), then they will return and resume their work".
pmichaud Debolaz: unfortunately I've been distracted by non-rakudo items for a few months, but that appears to be resolving itself now 19:31
chromatic (now you may have to change all of the rest of the system to have lock points around acquiring GCable items, but that's a different problem)
Infinoid chromatic: one of the things that makes me nervous is: how tied are we to the current GC? the other plugins are in varying stages of functionality, and apparently, they have been for years.
chromatic Less so than last year.
pmichaud Debolaz: but I would be very happy to hear reports of "I wanted to do this in rakudo but it doesn't work yet" 19:32
Infinoid I expect some more bugs to crop up, and I look forward to fixing them.
19:32 pelagic joined
chromatic Without some careful thought (or a great deal of luck) I think we'll have trouble with any non-stop-the-world collection. 19:32
Infinoid It seems like I should learn a lot about GC internals sometime in the near future. at some point, I'd love it if you could elaborate on that. 19:33
mncharity PerlJam: avoiding "yet another dead-ish p6 implementation" was indeed the defining design objective of the exercise. I believe elf has the right properties, but we'll see. probably within a week or so, as a couple of people seem to be in a busy wait, so if they adopt it, at least someone is unstuck. 19:34
chromatic Mostly the problem is that if you move a GCable element (copying or compacting collector), you have to update all of the pointers to that element before they try to use it. 19:35
Infinoid I suppose that means they have to be scanned for, or have backreferences.
allison Infinoid: right, and currently there is no mechanism for backreferences, or intermediate pointers 19:37
mncharity I think that was everyone's questions. Others welcome. /me -> back to IR exploration.
chromatic mncharity, why build a new platform?
mncharity re "platform", same meaning a before, a compiler target? 19:39
*as
chromatic Right.
Every bootstrap needs to run on *something*, whether you emit C from Scheme or Smalltalk or Perl 5 from ELF or PIR/PBC from PCT.
Not that PCT is a bootstrap.
Infinoid allison: is such a mechanism proposed, or should I try a couple of halfbaked things and let you guys tell me how wrong I am? :) 19:40
Infinoid promises to spend a couple of days trying to wrap his head around all of this stuff, in any case.
allison Infinoid: it's not currently spec'd. In fact, we're not planning to implement a compacting or copying collector until after 1.0 19:41
Coke allison: note that we have a few SOC proposals re: gc. 19:42
chromatic Infinoid, a copying collector isn't too bad. If you're willing to live with stop-the-world, we could change pobject_lives() such that it copies or updates.
Infinoid well, Harmony is not a stop-the-world GC, so it sounds like things might break gloriously.
chromatic We have to pass in the pointer location, but that'll get rid of some boilerplate.
Harmony probably requires a read barrier. 19:43
mncharity re 'why build a new platform?', because new platform x gives you something you want that your current ones don't. eg, Moose p5 added for easier and eventually more conformant p6 compilation than the preceeding bare p5. ruby might provide faster method calls, an object system which might be wielded to implement true p6 oo without much overhead,
crude jit, and thus be faster and more correct than a p5 platform. a common lisp platform would provide mature and wizzy compilers. ... etc. 19:44
a 'not-very conformant but compiles to p5-compatible code' might provide the ability to write cpan modules in something like p6. 19:46
Infinoid ok. Thanks for the answers, guys.
chromatic And so you want people who're already working on such a platform that can actually run Perl 6 code today to dump out an AST so that people who are blocking on the non-existence of an as-yet-unwritten platform can ... wait a little longer for that as-yet-unwritten platform to get to the point where they can actually run Perl 6 code?
I mean, I can see the theoretical benefits of running on a mature Lisp platform or Smalltalk or Rhino or whatever, but none of those experiments have ever worked beyond "Hey, I can parse Perl 6 lexical variable declarations and simple if/else blocks!" 19:47
mncharity me puzzled by preceeding paragraph... let's see... 19:48
*previous
chromatic I'm reading a lot of "this platform might do this" and "that platform could do that", but practically speaking, where's the beef?
mncharity is "people who're already working on such a platform that can actually run Perl 6 code today to dump out an AST" a reference to earlier interest in getting a yaml dump of ast from rakudo? 19:49
chromatic Yes. 19:50
mncharity ah, ok. re yaml dump of ast, I ended up following pmichaud's suggestion to scrape the --target=parse output, and built a project elf_on_rakudo on it. the parsing ended up being rather slower than I was hoping for, and STD_red seemed to be working fairly well, and so an elf_on_STD_red was done. that then became the current elf. 19:51
also, yaml turned out to be a problematic interchange format. elf_on_STD_red hit both yaml bugs, and performance issues, eventually switching to a more "I know you are running p5 - here is a dump format you can just eval there" interchange approach. 'match("rule name",0,1,"the text which matched",{...})'. 19:53
which was much faster and less buggy.
chromatic You want to write Perl 6 in Perl 6, right? 19:54
mncharity so the "yaml from rakudo parse" is no longer of near-term interest. sorry I didn't gc that sufficiently.
yes 19:55
a dump of PGE matches would still be of interest however.
in whatever format
chromatic Well it's not *my* interest, but I'm only speaking for myself. I've no interest in telling other volunteers what to do.
mncharity I wasn't suggesting it was. 19:56
dalek r26694 | allison++ | trunk:
: [pdd] Clarification to Strings PDD from Jim Keenan.
diff: www.parrotvm.org/svn/parrot/revision?rev=26694
chromatic In your mind, the simplest/most desirable/easiest way to write Perl 6 in Perl 6 at this point is to use Rakudo to parse Perl 6 code into a parse tree, export that parse tree somehow, parse that exported tree into an application written in Perl 6 and running on Perl 5? 19:57
Coke mncharity: you can dump pge match objects atm. 19:58
wknight8111 that process seems awfully convoluted to me
chromatic That's why I'm asking. I feel like I'm missing something. 19:59
wknight8111 if it were me, and I know it's not, I would write Rakudo V 1.0 in PIR/NQP. Then write Rakudo V2.0 in Rakudo V1.0, etc. 20:00
that way you don't have to wait for a new tool/platform to be available before you can make a release
20:01 ruoso joined
dalek r26695 | kjs++ | trunk: 20:12
: [pdd29] check in initial pdd stub for compiler tools. update manifest. keywords are set.
diff: www.parrotvm.org/svn/parrot/revision?rev=26695
mncharity chromatic: no. but s/Rakudo/STD_red/, and that is what elf is currently doing. elf_on_rakudo did what you described - but I consider it dead code. 20:15
as for whether elf is 'the simplest/most desirable/easiest way to write Perl 6 in Perl 6 at this point', it's certainly letting me write p6 code which nothing other than pugs might run, without worrying about getting hung up on pugsbugs, and with a much faster edit-test cycle. so, yes. 20:17
chromatic Is STD_red a Perl 6 grammar parser written in Ruby?
mncharity STD_red is a kludge of a direct hand translation of STD.pm into ruby. it parses, buggily, p6. upside is its fast, and the coverage is much better than STD5 at present. 20:19
token foo { <bar> <hee> {...p6 code...} } -> def foo() { b=bar and h=hee and ...ruby code... and _make_a_match(..b..h..) } 20:21
chromatic What features does Rakudo need to support before it's a more viable platform than elf?
mncharity than elf itself, rather than the STD_red part of elf? hmm... 20:26
dalek r26696 | kjs++ | trunk: 20:27
: [pdd29] fix copyright year; add a reference and add an abstract line.
diff: www.parrotvm.org/svn/parrot/revision?rev=26696
mncharity so rakudo has a more real parser. you'd loose bootstrap, but for many things that doesn't matter. matters for backend and primitives work, somewhat for Prelude, not at all for much else. so after that, it's just performance? 20:29
chromatic Why would you lose bootstrap? 20:30
mncharity elf_c, the current "elf of Monday night, today, and hopefully move off it later this week", can compile svn.pugscode.org/pugs/misc/elf/elf_c_src/ in about 20 sec, and run it in doing the same task in 10 (the other half being the parser). rakudo needn't be that fast, and much work is on smaller things, and one can do makefile-like 'avoidance of compilation'. So while rakudo was too slow for elf_on_rakudo, it 20:32
may be fine to be viable, leveraging its other advantages.
re 'Why would you lose bootstrap?', because rakudo isn'
20:33 findlay joined
mncharity t implemented in p6? so one still faces a variant of the pugs "I really need to do x, my compiler won't let me, and there is nothing I can do about, so I spend time trying to find workarounds". 20:34
chromatic Do you think then that the complexity of bootstrapping is less a barrier to overcome than the complexity of learning, say, NQP? 20:36
ewilhelm ponders toggling the instruction set for nqp directly into the cpu's front-panel... 20:38
mncharity well, the backend portion of the bootstrap is done. cost paid. cost for the front end is mostly writing a "regex on regexp" implementation in p6. of which there is already a p5, so it shouldn't be too bad. vs NQP, the pain of maintaining STD_red should be included, though it's been at least slightly amortized over helping with STD.pm work. re barrier, 20:40
chromatic There's a conceptual cost of understanding the layers, and bugs in lower layers tend to be much more difficult to find and to diagnose. 20:41
mncharity the key question short-term, this week, will be "you got this dialect working, it's a dialect you personally understand and has what you most wanted. but as to whether *I* understand and can use it, and whether it has the features *I* need for comfortable development..." for a multiperson value of I, is unclear. the question which follows is how rapidly a feature set which makes people generally happy can be grown. 20:43
re layers, and expecially error reporting, agreed. currently taking advantage of the p5 layer being readable, but that doesn't scale. current story is that the/a emitter should rsn start inserting #line's refering back to the original p6 source. or let users toggle that. or some such. the info is available at emit time, it just hasn't been enough of an irritant (barely), to happen yet. 20:47
chromatic Your conjecture then is that there are more people willing to learn Perl 6 and how to write a bootstrapping compiler than there are willing to learn NQP? 20:51
20:52 rafl joined
mncharity re conjecture, no. that there are more people willing to learn Perl 6 than NQP seems clear. that [...] to learn some elf dialect of p6 than learn NPQ, of course depends entirely on how extensive the dialect support becomes, and when. Unclear. But that's not the near-term objective. That there are more _p6 compiler writers_ wishing to work in bootstrapped p6 rather than in NQP on parrot is the conjecture. well, hypothesis. 21:03
chromatic What's the near-term objective then? 21:04
mncharity support the '_p6 compiler writers_ wishing to work in bootstrapped p6 rather than in NQP on parrot'.
chromatic I thought that wasn't your near-term goal. What is your near-term goal *not*, then? 21:08
mncharity while pugs also supported a population of people writing "some random module" in p6, their (not) being able to get work done does not at present directly hurt a development critical path towards Christmas. And won't until we have enough of the language working that their language-design feedback becomes key.
ewilhelm notes parallel that squeak was written in a subset of smalltalk 21:17
(though smalltalk was already a mature language at that point)
Tene It really would be nice to be able to write Random::Perl::Module to use with Parrot. 21:22
chromatic Sure, but the open question is "Is bootstrapping a likely way to get there?" 21:27
My opinion is no secret: you'll end up reinventing something that looks very much like Parrot to do so. 21:28
ewilhelm Tene: use in what way? Couldn't perl5 be embedded (with limited connectivity ala inline) via C with a small matter of code? 21:29
21:29 ruz joined
ewilhelm of course, the squeak developers were apple employees :-/ 21:29
Tene ewilhelm: Perl 6 modules, I mean.
ewilhelm well, that sort of supposes that rakudo is done, no? 21:30
chromatic No, why? 21:32
People wrote modules for Perl 5.000 despite Perl 5.10 being a decade away.
ewilhelm well, what breaks if I write Random::Perl::Module (e.g. File::Fu) in perl 6 today? 21:33
chromatic I don't understand the word "breaks" in this context. 21:35
ewilhelm what doesn't work? 21:36
purl Look buddy, doesn't work is a strong statement. Does it sit on the couch all day? Is it making faces at you? Does it want more money? Is it sleeping with purl's girlfriend? Please be specific!
ewilhelm iiuc, operator overloading isn't fully specified
chromatic Sure, and that means for File::Fu to work as written, Rakudo needs to support that type of operator overloading. 21:37
Unless that's absolutely the last thing added to Rakudo, I'm not sure that Rakudo has to be done for you do port File::Fu. 21:38
ewilhelm s/done/in some satisfactory state of readiness/
i.e. everyone has their own threshold of ride-along vs wait vs contribute 21:39
chromatic Yeah, but not all of them are "It must be DONE". 21:42
That's why I like to ask for specifics.
ewilhelm www.perlfoundation.org/perl6/index....rl_6_today 21:43
shorten ewilhelm's url is at xrl.us/biq6w
ewilhelm is curious when the "3D graphics" stub will become a link 21:44
22:01 jan joined
davidfetter wonders whether ewilhelm is the same ewilhelm he heard on talk of the nation today 22:10
chromatic This one is a Josh, not a Kaiser.
davidfetter heh
davidfetter fails to note any early april stuff on parrotcode.org 22:11
it must just be too subtle
wknight8111 the site was down this morning, that counts 22:16
mncharity pmichaud: one more for the todo list, but it seems unambiguous. PAST::Op pasttype(for) mentions an otherwise unmentioned 'arity' attribute. --target=PAST shows it in Block, but only if explicit arguments are given (eg, "foo () -> $x {3}" but not "foo () {3}"). fyi. I think I'm all set. thanks for your help.
22:17 Limbic_Region joined
ewilhelm davidfetter: I think I'm the one you had a beer with several months ago in portland 22:20
davidfetter w00t!
cotto_work now that PDD17 renamed "does" to "provides", are the "does" and "does_pmc" VTABLE method names also going to change? 22:51
23:02 nopaste joined 23:08 skids joined
dalek r26697 | allison++ | trunk: 23:20
: [pdd] A few more clarifications to the Strings PDD, while responding to mailing
: list comments.
diff: www.parrotvm.org/svn/parrot/revision?rev=26697
23:20 tetragon joined
Infinoid cotto_work: they probably should 23:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!