Parrot 1.0 Released | parrot.org | 333 RTs left!
Set by moderator on 20 April 2009.
cotto LylePerl, I can confirm that rakudo builds fine on my system from a fresh checkout, but fails if there's old stuff. It's definitely something make realclean is leaving behind. 00:00
Whiteknight All tests pass on my system, Ubuntu 9.04 x86_64 00:06
00:09 AndyA joined
LylePerl I've updated my ticket with the findings 00:09
I have a new found hatred for realclean
infinoid, I've tracked the problem down to realclean 00:10
infinoid: I've updated the ticket. Seems those 2 files being dropped weren't such a red herring after all
Infinoid Subject: realclean is insufficiently real
LylePerl It's an issue with Rakudo's realclean, so I should take my frustrations out on #perl6 tomorrow, lol 00:12
Infinoid heh
is there an ordering dependency between the rakudo/parrot realcleans to reproduce this?
or will either order do?
cotto It's nice to know my commit only exposed existing brokenness instead of causing it. 00:13
LylePerl either will do as far as I know
cotto Does anyone know what time fperrad is planning on cutting the release? 00:14
Infinoid no idea. I think he's in western europe, so probably pretty early by our standards
LylePerl To reproduce exactly what I had you'd need to build a pre r38030 parrot against a rakudo from 2 weeks ago
then realclean and update both and try to build again 00:15
Infinoid I actually have the path "config/gen/makefiles/root.in" memorized by now. I'm not proud of that
LylePerl++ # but really I should see the "dll and ops files still exist" symptom with any checkout 00:16
LylePerl oh yeah, you'll get that with any checkout. But if you want that wierd build error... 00:17
wierd = weird 00:18
Infinoid thanks, but I've already seen plenty of weird build errors :)
thanks, you've given us something much more concrete
LylePerl Felt really bad that I'd wasted every ones time earlier, but I knew there was a problem somewhere... 00:19
Hopefully this makes up for it :)
Most importantly this version of Rakudo finally has the IIS CGI fix you did :) 00:20
Infinoid LylePerl++
00:20 bacek_ joined
Infinoid You've never stopped helping us, don't worry about it. 00:20
LylePerl Infinoid++
time I went to bed. thanks everyone 00:21
Infinoid sleep wel 00:22
l
mikehh looking at docs/book/ch09_pasm.pod - the failures seem to be incomplete .pasm 00:33
00:33 hudnix joined
mikehh and probably shouldn't have the =begin PASM / =end PASM 00:34
00:49 darbelo left 01:07 silug joined
mikehh what is or was the find_type opcode? 01:13
01:17 Fayland_logger joined 01:20 jdv79 joined 01:23 wayland_ joined 01:50 LimbicRegion joined
kid51 mikehh: find_type has ceased to be 01:50
... though how long ago it went away, I couldn't say
mikehh ze problem being is dat it isa used in docs/book/ch09_pasm.pod in 5 places 01:53
and of course imcc doesn't like it 01:54
what would you use in it's place> 01:55
s/>/?/
kid51 I've no idea. 01:57
I'm grepping the log for it. Definitely long gone.
Documentation bug, which definitely qualifies for a TT. 01:58
01:58 petdance joined
nopaste "kid51" at 70.85.31.226 pasted "svn log . | grep -C5 find_type" (171 lines) at nopaste.snit.ch/16343 02:01
Whiteknight There's a problem with chapter 09? 02:05
wasn't any last time I ran the tests
nopaste "kid51" at 68.237.8.99 pasted "pge_examples.t fails on make testj on Darwin/PPC (same as last night)" (28 lines) at nopaste.snit.ch/16344 02:08
02:08 dmknopp joined
mikehh and also 'newsub', 'new_pad', 'compile', 'classoffset' 02:09
kid51 In that same chapter?
mikehh yes - it fails 31 out of 121 tests 02:10
kid51 I'm snagging the entire log so that I can grep it for those terms. 02:11
Of course, grepping for 'compile' is probably not going to be fruitful.
Are those all supposed to be ops?
mikehh That's what it fails on eg error:imcc:syntax error, unexpected IDENTIFIER, expecting PARROT_OP ('compile') 02:13
rg have you tried trac search? that should include log messages
mikehh not all of the failures are ops though 02:14
hang on I'll paste it
02:15 dmknopp left
nopaste "kid51" at 70.85.31.226 pasted "new_pad opcode is long gone" (71 lines) at nopaste.snit.ch/16345 02:16
"mikehh" at 90.209.236.67 pasted "errors in perl t/examples/pod.t docs/book/ch09_pasm.pod" (326 lines) at nopaste.snit.ch/16346
Coke msg fperrad: that file had NO failures the last time I touched it. Everything was properly todo'd. 02:17
purl Message for fperrad stored.
Coke msg fperrad - still passes 100% here.
purl Message for fperrad stored.
Coke msg fperrad r38240. 02:18
purl Message for fperrad stored.
nopaste "kid51" at 70.85.31.226 pasted "newsub opcode is long gone" (272 lines) at nopaste.snit.ch/16347
"kid51" at 70.85.31.226 pasted "classoffset opcode is long gone" (90 lines) at nopaste.snit.ch/16348
Coke You can easily make chapter09 pass by converting the failures to PASM_INVALID blocks instead of PASM. 02:20
(that will effectively skip them).
Obviously, fixing up the sample code is better, but that might be tough to do in the time remaining.
mikehh for eg the first failure should not have =begin PASM / =end PASM and the last is due to 'find_type' opcode 02:21
I am working on it at the moment and will see how much I can fix in the next hour or so 02:26
02:42 janus joined
Coke danke. If you end up updating the pasm blocks, please give a shot at updating the surrounding text that refers to it where that makes sense. 02:45
02:57 eternaleye joined
mikehh There is a whole bunch of code under Inheritance starting at line 3091 which is incomplete, refering to stuff which comes before 03:04
actually even before that eg ok 113 - docs/book/ch09_pasm.pod:3073 is an inc P3 - which is meaningless on its own 03:11
some of the failures are due to code that would have set up in previous snippets and oters due to removed op-codes 03:16
s/oters/others/
should have said missing code 03:17
allison the code with setup in previous examples shouldn't be marked for auto testing
mikehh should I remove the =begin PASM / =end PASM there 03:18
03:27 japhb joined 04:17 tetragon joined
allison mikehh: yes, that seems to make the most sense 04:21
Infinoid hrm, I still can't reproduce LylePerl's realclean issue
04:26 eternaleye_ joined 04:29 eternaleye__ joined
cotto I thought we'd decided to drop Makefile.PL 05:00
nopaste "mikehh" at 90.209.236.67 pasted "Patch for docs/book/ch09_pasm.pod to get t/examples/pod.t working" (507 lines) at nopaste.snit.ch/16350 05:03
mikehh that gets perl t/examples/pod.t docs/book/ch09_pasm.pod to pass 05:04
cotto mikehh, wouldn't it be better to fix the code?
mikehh sure - but it would take longer than a couple of hours as a lot of the opcodes used have been removed 05:06
and we want it working for release - you might be able to do that quickly - but I couldn't 05:07
cotto it's worth a shot. I should be able to at least get a couple working.
Is t/examples/pod.t run by default for make test? 05:08
mikehh damn - I missed a failure in ch03_pir.pod - otherwise the rese op make examples_tests is ok 05:09
rest of
cotto: no - make examples_tests or make fulltest 05:10
cotto ok. It'd be higer-priority if it caused make test failures, although it's still important. 05:11
Have you filed a ticket?
mikehh no - because I wanted to see if I could fix them properly first - but not in time for the release 05:12
It would probably take me a day or two to get it sorted out properly 05:15
btw Failed test 'docs/book/ch03_pir.pod:1654' 05:17
error:imcc:syntax error, unexpected ADV_INVOCANT, expecting '\\n' (':invocant')
from: .param pmc item :invocant # "self" is now called "item" at line 1662 05:18
cotto I like that we have a formal way to ensure that all the code samples actually run. 05:21
even if they don'y right now
*don't
mikehh one of the problems in ch09_pasn,pod is that a lot of the later examples are not complete and depend on some of the earlier snippets 05:23
cotto That is a downside. 05:25
05:30 Theory joined
mikehh gotta take a break for a bit - bbl 05:41
dalek rrot: r38241 | cotto++ | trunk/docs/book/ch09_pasm.pod:
[book] fix some code examples
 05:51
cotto Wow. Some of that code has cobwebs. 05:54
I don't think classoffset was valid when I started contributing to Parrot. 05:55
06:11 uniejo joined 06:44 amoc joined 06:53 iblechbot joined 07:11 tuxdna joined
he Hm... src/call/pcc.c:2453: error: used struct type value where scalar is required 07:23
That's ASSERT_ARGS in set_context_sig_returns_varargs(), when I try to build on NetBSD/alpha. 07:24
And... that's probably the va_list returns which is "guilty". 07:26
Apparently, there's no guarantee that va_list is a scalar or a pointer type. 07:35
07:36 salts joined
cotto particle-, ping 07:46
07:49 masak joined
pmichaud hello, all 07:54
moritz hi pmichaud
pmichaud is it too late to get some commits in prior to release? 07:55
(wireless at hotel wasn't working lastnight/this morning)
moritz I think it's still a few hours until release, and I haven't see a "don't break things now" post :-)
pmichaud well, my commit won't break anything. But I do need to test it on latest trunk before commit. 07:56
07:56 riffraff joined
riffraff hi everyone 07:57
purl Howdy, riffraff, you fantastic person you.
fperrad I'll start release after #ps 08:01
moritz so it's 11.5 hours still 08:02
pmichaud well, we'll see how many spectests I can get in before my airplane has to board.
I wanted to do all of this last night, but the hotel network was kaput. 08:03
riffraff I as trying to use parrot-1.0.0 to write a small article about it, but when I execute perl tools/dev/mk_language_shell.pl it ends with 08:06
Can't open perl script "/usr/local/lib/parrot/1.0.0/tools/dev/gen_makefile.pl": No such file or directory
Any ideas?
doe I need to run make install before everything works?
fperrad riffraff, make install-dev 08:07
nopaste "he" at 158.38.152.119 pasted "There's no guarantee va_list is integral or pointer, so don't do PARROT_ASSERT_ARG on it; found on NetBSD/alpha" (22 lines) at nopaste.snit.ch/16353
pmichaud riffraff: perhaps try tools/dev/create_language.pl instead 08:09
but if you did "make install" or "make install-dev" it might not be installed yet.
nopaste "he" at 158.38.152.119 pasted "Add NetBSD/sparc64 5.0 to the PLATFORMS list, ref. smoketest 20265" (12 lines) at nopaste.snit.ch/16354 08:11
riffraff ok I'll install 08:15
I just remembered I did not need to do it with the svn version :)
thanks everyone
cotto cla? 08:16
purl rumour has it cla is Contributor License Agreement or www.perlfoundation.org/contributor_..._agreement or www.parrot.org/foundation/legal
cotto cla is also www.parrot.org/files/parrot_cla.pdf
purl okay, cotto.
riffraff I do not see create_language.pl anyway, even after make install-dev, maybe it is a post 1.0 addition? 08:19
bacek_ riffraff: it is. But 1.1 release is in less than 12 hours. 08:20
08:21 tuxdna joined
cotto karma darbelo 08:25
purl darbelo has karma of 3
riffraff ah I see thanks :) 08:26
08:27 particle joined
dalek kudo: 0e73267 | pmichaud++ | docs/ChangeLog:
Update ChangeLog.
 08:28
kudo: 69b3180 | pmichaud++ | src/ (2 files):
Restore prefix:<=> to provide a useful error message (moritz++)
shorten dalek's url is at xrl.us/bepq7n
shorten dalek's url is at xrl.us/bepq7p
08:51 bobke joined
pmichaud yay, got my commit in. 08:51
time to board.
see you all later.
moritz have a good flight 08:52
dalek rrot: r38242 | pmichaud++ | trunk/runtime/parrot/library/P6object.pir:
[p6object]: Adjust .ACCEPTS on protoobjects to handle junctions again.
09:08 he joined, rblasch joined
dalek rrot: r38243 | fperrad++ | trunk/PLATFORMS:
[PLATFORM]
 09:12
he Non-portable: #define PARROT_FLOATVAL_INF_POSITIVE floatval_divide_by_zero(interp, 1.0) 09:31
On alpha, doing that will land you a SIGFPE.
cotto darbelo? 09:33
purl darbelo is probably Daniel Arbelo Arrocha <mailto:dany.arbelo@gmail.com> or into bonding or mailto:arbelo@gmail.com
09:35 ascent_ joined 10:09 bsdz joined 10:29 Ademan joined 10:35 ascent_ joined 10:36 pjcj joined 11:38 iblechbot joined 12:05 Whiteknight joined 12:28 Infinoid joined
Coke_zzz msg cotto we still do cpan, so makefile.pl is still useful. (we could hide it or something, but still useful) 12:34
purl Message for cotto stored.
Coke msg cotto we still do cpan, so makefile.pl is still useful. (we could hide it or something, but still useful)
purl Message for cotto stored.
Coke dislikes IRC.
Coke ponders running an xmpp server at parrot.org :| 12:35
12:36 rg1 joined
wayland_ Coke: IRC is useful for drawing others into the conversation :) 12:38
Infinoid its user interface can vary a lot, but I don't think IRC itself is bad 12:47
LylePerl Infinoid: You couldn't re-create my realclean issue? 12:49
Infinoid: on what machine? XP?
bsdz Re:IRC I've found mibbit invaluable when I'm behind a firewall or have no local client installed www.mibbit.com/ 12:51
LylePerl bsdz: That's what I use :) 12:54
Infinoid LylePerl: winxp/strawberry/mingw, yes 12:55
two different machines, but more or less the same software.
I've tried various combinations of building everything, doing a realclean, and seeing whether blib/lib and src/ops/*.c still exist (they didn't) 12:57
LylePerl: What is $RM_RF defined to in your makefile? 12:59
hmm, looks like that's a call into ExtUtils::Command on all platforms 13:01
For realclean to work, it needs to keep removing even if there are some arguments in the middle of the list which it can't find. 13:02
It should be the very last command run by "make realclean". Does it emit any error messages for you?
rg he++ # cross platform testing on rare hardware 13:05
13:06 gryphon joined
rg he: if 1.0 / 0.0 (with vars) doesn't work on alpha, how do you get an inf value? on x86 hardware, the floating point exceptions/interrupts are masked by default. maybe is there a way to do that on alpha aswell? 13:08
bsdz Probably unrelated but occasionally I've realcleaned after an svn update and configure.pl and it went off into an infinite loop. i think the trick was to realclean before reconfiguring.
13:09 tuxdna joined
he rg: #include <math.h>, and use INFINITY? 13:09
NaNs also need special treatment.
...because if I do (f == 0.0) and f is a NaN, I get a SIGFPE as well. 13:11
rg he: it's also an indication that some math operations wouldn't work the same. I don't know if there are tests dividing by zero, but if there are, i'd suspect them to also give you a SIGFPE
so what we really want is to either ignore SIGFPE on alpha, or not have it signaled. 13:12
dalek rrot: r38244 | Infinoid++ | trunk/PLATFORMS:
Add netbsd5.0-sparc64-gcc-4.1.3 to PLATFORMS, courtesy of he++
he rg: yep. Relying on that nothing happens if you divide by zero or do other stuff which I think gives undefined results is not portable.
13:13 Infinoid joined
he I'm re-running tests after having made my third or fourth patch to parrot 1.0.0 for the day. 13:13
"We'll see"
Infinoid he: Are there any other nopastes? I've just woken up, wondering if I missed anything. 13:16
Coke does rakudo currently work against an installed parrot?
he rg: or rather... what I wanted to say: parrot should not be doing anything which invokes undefined behaviour.
rg since parrot is just providing the means, i don't think we can do that 13:17
he Infinoid: No, I don't think I have anything outstanding.
Infinoid: ...or... rather, I had one diff for NetBSD/alpha, but it was premature. I'll return later with a more complete set if/when I get there. 13:18
Coke checks the ticket report for 1.1 ...
Infinoid he: nopaste.snit.ch/16353 is ... interesting. Those are autogenerated by "make headerizer" from the ARGIN/ARGMOD/ARGOUT tags in the function declaration
Does the argument's type change? If so, we might want to find a better fix for that.
13:18 tuxdna joined
Coke trac.parrot.org/parrot/query?statu...estone=1.1 is pretty big. :( 13:19
shorten Coke's url is at xrl.us/beprnj
he It's not so much that it changes, "va_list" is an opaque type which is not guaranteed to be an intval or a pointer, and on NetBSD/alpha it's a struct.
Infinoid If it's always a pointer but is just not reliably non-null, we can add a _NULLOK suffix
oh, ok. hmm 13:20
he I obviously didn't know where that came from originally.
Infinoid Maybe we can hide that behind PARROT_VA_LIST and force parrot to pass around a pointer to it... but probably not in time for 1.1 13:21
he va_list is a little special, and care is needed to not do something which is undefined by the standard. 13:22
Infinoid yeah
he But at least as far as I can see from the std (iso C), taking a pointer to va_list and passing it around is allowed. 13:24
Infinoid did rurban leave? if so, that's sad, but we probably need to steal his tickets
he: If so, then we can probably make things a little more consistent. 13:25
Coke there are plenty of non-assigned tickets to work on. =-)
he Oh, one of the tests print (in addition to what's expected): parrot in free(): warning: page is already free.
dalek rrot: r38245 | fperrad++ | trunk/t/codingstd/c_function_docs.t:
[t] fix this test on Windows
Infinoid true, but I tend to ignore the ones that someone else has already taken... out of sight = out of mind
Coke that's fine. fix all the unassigned ones first! =-)
Infinoid he: That sounds like a bug :) 13:26
rg uh duplicate free. i wonder where that comes from
he Infinoid: no kidding! :)
Infinoid he: does valgrind run on your platform?
he Infinoid: I'll try to track it down.
Infinoid: not sure, doubtful.
Infinoid too bad, it's good at things like that.
he Gah: devel/valgrind/ is there, but ONLY_FOR_PLATFORM= Linux-*-* 13:27
Infinoid I guess it has to explicitly emulate portions of the OS and CPU, so there's a high cost for porting it
hmm, breakfast, what a wonderful idea. 13:29
dalek tracwiki: v146 | coke++ | ParrotRoadmap 13:35
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/bepro7
13:35 tuxdna joined
Coke Infinoid: was your #504 meant to be the roadmap ticket ? 13:37
Infinoid yes
Coke ok. on the roadmap it's assigned to jonathan. 13:38
Infinoid yes
Coke ok.
he Bah, when I try to separate out the part of the test which triggers the "already free" bug, I don't get it. When the whole test is run under perl, the "already free" is printed.
I get the feeling that one is going to be hard to debug.
Infinoid same command line arguments?
dalek tracwiki: v147 | coke++ | ParrotRoadmap 13:39
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/beprph
rg he: is parrot or perl printing the already free message?
he Part of it is I don't know how parrot is run.
rg: oh, that I can find out.
Infinoid suspects the perl harness is adding --gc-debug to the parrot command line
rg infinoid: it definitely is
Coke Infinoid: updated the (soon to disappear) roadmap to mark you as the owner, killed the duplicate I just opened. 13:40
Infinoid eew, responsibility
13:40 tuxdna joined
Coke when it disappears, your name is on the ticket, anyway. 13:41
he rg: it's parrot which prints it.
Infinoid he: When parrot is run with the --gc-debug argument, it will cause the GC to destroy everything the hard way. this is very likely the cause of your error message 13:42
or rather, --gc-debug found a GC bug on your platform
which test is it?
rg infinoid: EXTRA_TEST_ARGS := --gc-debug --running-make-test
he Hmm, of course one of the tests is doing $N0 = 'Inf'; $N0 -= $N0 -> kaboom 13:45
Infinoid that's what tests are for :) 13:46
Coke: I honestly don't think I can commit to getting the packfile roadmap item done right now.
I was helping out with the pmcs portion of the task, but I haven't done any work on it in a long time 13:47
he "./parrot --gc-debug pared-down-testfile.pir" still didn't show the "already free" part. 13:48
Infinoid also, I was originally led to believe part of the task was reviewing/updating the pdd, but the wording seems to have changed since then.
Coke Infinoid: changed owner to jonathan.
Infinoid thanks
he: which test was it?
he The one with "already free" is t/pmc/packfiledirectory.t
rg is running perl t/harness --gc-debug t/pmc/packfiledirectory.t printing it? 13:49
Infinoid (it doesn't here) 13:50
he rg: yep, both with and without --gc-debug prints it. 13:51
rg does running ./parrot t/pmc/packfiledirectory.t print it?
he rg: doesn't work: error:imcc:syntax error, unexpected IDENTIFIER, expecting $end ('use'), in file 't/pmc/packfiledirectory.t' line 5 13:54
(no surprise, really)
rg works here
oh but you're still on 1.0.0
Infinoid he: I think you must be using 1.0.0, not svn head 13:55
he Yep, still on 1.0.0.
rg there have been a lot of packfile changes on trunk
he (sorry, should have mentioned that)
Ah, ok.
Infinoid yes, and those tests were translated to pir
rg you did, i just forgot, sorry
he ok, time to bring up svn on this test platform as well, I guess.
rg i wonder if we shouldn't just ignore it then. it may not even be happening anymore.
Infinoid he++
he For now, though, I'll nopaste the diffs I have so far. 13:56
Infinoid it was very likely fixed. bacek++ did all of that work for the specific purpose of cleaning up this kind of problem
he They're not intended to be committed directly (although they could...).
nopaste "he" at 158.38.152.119 pasted "diffs for porting to NetBSD/alpha, 2 test failures remain" (95 lines) at nopaste.snit.ch/16363 13:59
"pacolinux" at 80.36.122.139 pasted "weird error building rakudo (gcc bug ? )" (35 lines) at nopaste.snit.ch/16364 14:02
PacoLinux Im having a very weird error building rakudo in my main machine that seems to be a gcc 4.1.3 bug - solved using --optimize while building parrot
rg i'd love to know if your include/parrot/datatypes.h isn't the better solution in general.
infinoid: can you test how well it would work on windows? 14:03
moritz PacoLinux: --optimize + rakudo stopped working for me shortly before the 1.0 release
PacoLinux moritz: without --optimize I cant build rakudo .. now runing spectest 14:05
moritz PacoLinux: did you try a 'make clean' in rakudo after building parrot? 14:06
14:06 tuxdna joined
PacoLinux moritz several times, and in several directories (new downloads) 14:07
moritz PacoLinux: please report the build failures (without --optimize) to rakudbug@perl.org, if you haven't already.
PacoLinux moritz: seem to be a lot of special case (I tried in several linux under virtualbox and the error is not reproducible) 14:09
I think is more a gcc problem than rakudo/parrot
he Say, if I wanted for this particular platform to set SIGFPE to SIG_IGN, where would I do that? 14:17
Infinoid rg: not for several hours, gotta go to work now 14:23
rg he: i don't know. for testing you could stick it right into main.c 14:24
14:24 bsdz joined
dalek tracwiki: v148 | Infinoid++ | ParrotRoadmap 14:25
tracwiki: reassign packfile item to jonathan
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/beprvy
14:34 gariani joined
he Hmm, if I read correctly, ISO C mandates FP trapping or stopping be disabled on program startup. 14:37
14:37 danielgrafael joined
rg which seems to be what the other platforms are doing 14:42
Coke via something in the platform config/ ? 14:43
rg coke: no, the os does it. 14:44
NotFound he: note that strict iso compatibility may need some option in some compilers 14:45
PacoLinux moritz: reported 14:46
Coke Infinoid: ah, forgot the wiki. 14:52
(I am trying to kill that page, so please forgive me. =-)
Infinoid Coke++ # using the features trac is good at
he rg: yep, setting SIGFPE to SIG_IGN made the arithmetic tests succeed. 14:54
rg with or without the patches you already had to work around the signal? 14:55
he oh, with them all.
hrm, should try to revert some of them, I guess...
Infinoid hmm. if config/gen/platform/netbsd/math.c had an init function that was called at parrot startup, this would be a great place to drop a SIGFPE=SIG_IGN workaround 14:57
rg infinoid: is there a place for platform specific startup? i haven't run across any yet. 14:58
he OK, trying to build now with most of the other fp-related patches out of the way, still with 1.0.0. It'll take a while, though, and I'll leave for a couple of hours too. Later, guys.
15:00 he left
Infinoid rg: src/global_setup.c looks like the right file for it, even though I can't point to a particularly relevant function 15:00
ah, it calls Parrot_platform_init_code() when PARROT_HAS_PLATFORM_INIT_CODE is defined 15:01
(currently only used by win32.)
rg good to know. 15:10
purl good to know. is there an ETA for dust starting to settle, or is it just finished when its finished?
rg purl: forget good to know
purl rg, I didn't have anything matching good to know
rg purl: forget good to know.
purl rg, I didn't have anything matching good to know
Infinoid rg++ # beat me to it
rg if only :( 15:11
Coke good to know.
you just have to know how to talk to the girl.
rg just doesn't understand women ;) 15:14
Infinoid Neither do they.
has anyone else encountered the issue with strawberry perl on athlon xp machines, where libgmp was built with SSE2 instructions and it pops up a windows crash dialog during Configure.PL? (RT #50212) 15:20
I just found a workaround, rg++ for getting me to look at Parrot_platform_init_code()
particle doesn't have any athlon machines 15:21
Infinoid I've been using one for parrot/mingw testing for a while. It's slow.
Coke wonders when the call for proposals began for yapc10 15:29
(since the deadline is friday) 15:30
ah, back in march, according to the website. Must have missed an email. 15:31
particle deadline friday! oot! 15:33
Coke guess I need to decide if I'm going. 15:34
15:34 eiro joined
Coke is not liking the lack of information on the site. :| 15:35
nopaste "infinoid" at 75.140.33.106 pasted "RT #50212 workaround, will commit this after the release" (28 lines) at nopaste.snit.ch/16365 15:38
15:38 cognominal joined 15:48 uniejo joined 15:59 Theory joined
Coke Infinoid: would it make more sense to have all our c functions just call Parrot_platform_init_code ? 16:05
Infinoid it's per binary, not per function 16:06
Coke s/functions/tests/
yah, I screwed up there.
Infinoid That probably wouldn't hurt, but it's a little more invasive than I intended
Coke perhaps there's a place for boilerplate already on the C stuff. Iunno. 16:07
Infinoid Maybe we could concatenate in config/gen/platform/win32/misc.c when generating the test .c file 16:08
then all you'd have to do is call the function, without duplicating the init code
I dunno.
if we're talking about extending the init interface to trap SIGFPE on netbsd, it might be good to keep that code common, rather than adding win32-specific fixups directly 16:10
LylePerl got caught up with £work£
Infinoid: I'll check $RM_RF, I need to build parrot again first... 16:13
cotto confirmed the same problem as me last night, but I'm not sure what system he was on 16:14
Infinoid LylePerl: Thanks, I've checked and I'm sure $RM_RF is set the same on all platforms, but I'd still like to know if it barfs on your machine
it's actually just a call into a perl library 16:15
LylePerl I've got a Perl meet tonight, but when I get back I'll do tests on some other machines and write a proper bug report with steps to re-creating the issue 16:16
Infinoid thanks 16:17
16:25 uniejo joined 16:37 rdice joined 16:59 contingencyplan joined 17:20 kj joined 17:21 he joined
Infinoid fperrad: How are things looking for the release? Does anything need work? 17:33
fperrad all seems ok except t/examples/pod.t 17:34
i don't think it's a blocker 17:35
Infinoid ok, good to hear. I agree 17:36
17:41 Whiteknight joined
Coke fperrad: I can mark all those invalid ones invalid if you like. 17:48
(and therefore skip them.)
17:49 uniejo joined
Coke fperrad: meh. not worth it for this release, ne'ermind 17:50
he ok, with SIGFPE set to SIG_IGN, now only the packfiledirectory.t test fails. Now to try svn head.
18:04 allison_ joined
Infinoid he: Thanks. I'm hatching an evil plan to make a config/gen/platform/netbsd/misc.c and put that in Parrot_platform_init_code() so it's called at init time (win32 has a similar fixup), was going to work on that this evening when I get home from $job 18:07
You're welcome to beat me to it. :) 18:08
18:08 barney joined
he Infinoid: :) 18:08
Infinoid Is this a cpu-specific netbsd issue or does it occur on all cpu types? 18:09
he It's cpu-specific.
Infinoid Out of curiosity, which cpu? 18:10
he This is alpha. 18:11
Infinoid Judging from PLATFORMS, you're the first one to have tested on alpha in a while. The fix might be valid on some other unices, too
he That's quite possible. 18:12
Infinoid You've increased our tested "extra platforms" list by 50%. he++ 18:13
18:17 davidfetter joined
dalek rrot: r38246 | fperrad++ | trunk/NEWS:
[release] final NEWS
 18:19
18:21 masak joined, darbelo joined
he Hmm, another varargs fallout: 18:24
./src/pmc/class.pmc:338: error: incompatible type for argument 4 of 'Parrot_pcc_build_sig_object_from_varargs'
"va_list isn't by necessity compatible with a pointer" 18:25
Infinoid no, but &va_list should be, perhaps we should convert that interface 18:28
(if we want to pass NULL like that caller is doing)
he Yep.
Hm, is src/call/pcc.c generated from something else?
Infinoid the stuff within the /* HEADERIZER BEGIN: static */ and /* HEADERIZER END: static */ comments is, otherwise no. 18:29
he ok.
Infinoid Hmm, changing the Parrot_pcc_build_sig_object_from_varargs interface would require a deprecation cycle, we probably couldn't change that interface until a few months from now 18:30
cotto LylePerl, I'm on Ubuntu Hardy i386
Infinoid allison, do you have any better suggestions? 18:32
18:32 darbelo_ joined 18:33 chromatic joined
allison we have to be able to pass pointers to varargs some distance, but it doesn't have to be far 18:33
(no more than 1 function call in the new model)
Infinoid is there something we can call that will get the same result as calling Parrot_pcc_build_sig_object_from_varargs with a NULL va_list?
(since we're not actually passing any varargs, I have to wonder if there's a better function.)
moritz it's #ps time!
... and I'm late :/ 18:34
allison well, if it's a null varags list, then we don't need to call it at all
Infinoid moritz: me too, thanks for mentioning it
in that case, ./src/pmc/class.pmc:338 should hopefully be easy to fix
allison Infinoid: We'll likely want a singleton (PMCNULL_SIGNATURE) for subs that pass no arguments and return no values 18:37
Infinoid: PMCNULL would do for now, but it'd be nice to know it was intentional 18:38
Infinoid Ah, that makes sense 18:39
18:45 rblasch joined 18:47 darbelo joined
Util Coke, for future reference, you can use /NAMES to see everyone on the #ps channel. 18:49
Coke yes.
I have a list of people in the channel. I don't have a list of committers. =-)
Util Oh, I see. 18:52
Infinoid Whiteknight++ # inciting peasant uprising 18:57
18:57 szabgab joined
Whiteknight I figured the suggestion wouldn't fly, but I do want everybody to start thinking seriously about major JIT changes 18:58
because we need a major rebirth of that system for Parrot to continue maturing in a reasonable way 18:59
Infinoid I'm worried that gsoc jit branches will quickly diverge from trunk to the point that they'll be as unmergeable as gc branches
chromatic One of the problems of the GC branch is that the current GC is entangled throughout the system.
If we'd had more encapsulation there, replacing it would have been easier. 19:00
he oh, lookie, it built. Now to test.
pmichaud hello, everyone.
Infinoid is there anything we can do to improve JIT encapsulation to prepare for this?
moritz I think another problem is that it's simply a huge task, so it takes time, and much other stuff will happen in the mean time in trunk
Infinoid or is it just nci and a runcore and that's all we have to worry about?
Whiteknight encapsulation++ 19:01
allison It is encapsulated in the runcore 19:02
so, Util is right, anyone can make an alternate JIT runcore
Infinoid Ok, I won't worry about it then
cotto That's very good to hear.
NotFound We must also take into account jitted nci 19:03
Whiteknight My worry is that people will be complacent about keeping the current system if it works on their platform, when we really should be striving for more platform equality 19:05
Infinoid oh!
Whiteknight saying that it works on x86 and ppc is not the same as saying "it works"
Coke Whiteknight: it doesn't work on x86. =-) 19:06
allison the partially working JIT isn't the biggest obstacle to working on a new one, the biggest obstacle is that JITing is a non-trivial task
Whiteknight well, it does when we get all the cards stacked back up
chromatic Sure, and when I donate blood it doesn't work on silicon based lifeforms.
cotto Coke, You're welcome.
NotFound We must make it work even on platforms that are not designed yet ;)
Coke NotFound: yagni.
Whiteknight allison: yes, I don't want to downplay that. It is difficult. that's why I'm scraping and scrounging for motivation 19:07
Coke (!x86) I'm referring to darwin/x86, but as chromatic says, we're wierd.
Infinoid We had someone in here (hi LylePerl!) a couple weeks ago asking about redirecting stderr to a file, for debugging a CGI app under IIS. We looked at the "setstderr" op, which worked fine for the PIO level, but it was useless for capturing the exception he was seeing. But do we have any plans to override the stdio level stuff?
Whiteknight I want everybody to have JIT on the brain until we finally get a solid, working, portable version implemented 19:08
allison at the moment, any object that has the right methods can be a drop-in replacement for a "core" I/O object
Infinoid right, but that doesn't help for assertion failures and the like
allison Infinoid: I think I'd need a code example
Coke Whiteknight: finding someone to /work/ on JIT is probably more helpful than generic agitprop. 19:09
NotFound An assertion failed is a symptom of a big mistake in the code, we can't hope to be able to capture that
Infinoid allison: he was seeing an ASSERT_ARGS failure due to a NULL IO PMC, r37986 fixed it
dalek rrot: r38247 | chromatic++ | branches/headercleanup (5 files):
[runcore] Moved a header out of src/runcore/ into parrot/include/.
Infinoid If the answer is "make sure every possible C crash uses the right I/O routines to output their error messages", that's good enough for me. 19:10
Whiteknight Coke: We have people to work on it. What we don't have is the people to keep trudging through the mess of the current system everytime something breaks there
JIT broke on i386 when we removed that UnionVal stuff, and it took days to fix it
chromatic That's because the current approach to JITting is completely wrong. 19:11
NotFound Infinoid: my answer is: don't let it crash. Fix any branch in the code that leads to the crash, make it throw exceptions where appropiate
Infinoid Whiteknight: Hey, I did some trudging too :)
Whiteknight chromatic: Exactly! Exactly! What we have is wrong, we should clear it out and make way for bigger and better
chromatic Okay, let's apply that argument to the GC.
<crickets> 19:12
Infinoid NotFound: Happy to. The problem is, it's a pain to debug such crashes to get said fixes.
Whiteknight it's like saying "I'll just wear these concrete shoes while I go swimming because they're my size"
allison Infinoid: setting STDIN to PMCNULL is an unusual solution
Whiteknight chromatic: GC isn't the big-ticket du jure anymore
:)
NotFound Infinoid: that is the reason to have such assertions: to avoid even painfull crashes 19:13
Infinoid allison: setting stdin to PMCNULL allows the stdout and stderr assignments to go through (and yes, there's a typo, fixed by r37990), so writing to stderr works later on
chromatic Okay, let's apply that argument to IMCC.
allison Infinoid: there is a separate exception path for failures when it's known that the regular file handles will be closed, or the failure will be too catastrophic to allow an exception to be caught 19:14
Whiteknight chromatic: IMCC and GC aren't optional systems, they can't be removed without killing parrot. JIT can be
it's apples and oranges
chromatic The problem with the JIT isn't the JIT. It's everything around the JIT that makes the design of the JIT troublesome. 19:15
You can't remove all of that in one swell foop and have Parrot continue to work.
Infinoid allison: My question was about whether we're ever going to allow stdio level overrides, or if the solution is to use PIO for more error messages
dalek kudo: e31a6f8 | pmichaud++ | src/ (2 files):
Remove obsolete fish operator ("=<>"). It didn't work anyway.
kudo: 6ea0aa1 | pmichaud++ | src/classes/ (2 files):
More fixes to Match objects.
shorten dalek's url is at xrl.us/beps64
shorten dalek's url is at xrl.us/beps66
Whiteknight I won't argue with that, but you pull out the JIT and you'll have much better access to the troublesome interface. You'll be able to fix individual problems without a cascade effect 19:16
allison Infinoid: it's to use PIO for more error messages
chromatic We'll never fix the JIT until we fix the underlying problem with ops and PMCs.
Whiteknight Work up a sane interface, and then build a sane JIT on top of that
Infinoid ok, thanks
Whiteknight chromatic: what's the underlying problem with Ops and PMCs that you're referring to?
chromatic Any JIT anyone writes, no matter how good their intentions, is doomed until we fix those problems.
Infinoid Can we remove the doom beforehand? 19:17
chromatic They're big wads of C code we have to translate manually to macroized platform-specific assembly code to JIT.
(or we compile *all* of Parrot, the whole thing, to LLVM bytecode and hope its whole program analysis can clean up some of the mess for us)
TimToady calls that the "Sweeping it under someone else's rug theory of optimization". 19:18
Whiteknight chromatic: on that note, I've been thinking more about your idea of using custom operations primitives to implement ops instead of writing them in C
pmichaud Coke: #47970 hasn't been an issue for me for quite a while. I think we can close it until it appears again. 19:19
Whiteknight And then a step in the build could translate them into C and JIT generators automatically
chromatic allison and I talked about that a while ago. 19:20
We seemed to agree that writing a self-hosted little language in which to write ops and PMCs was useful.
Whiteknight it would take some careful design to make a language that's powerful enough but doesn't require too complex a parser, but it's doable 19:21
chromatic Emit C code for now, but if in the future we have L1 ops to target, write a new emitter.
Whiteknight maybe not "in the future", maybe that's the next logical step for us in preparation of new PMC and JIT systems
allison chromatic: aye, but we're talking 3.0 here 19:22
or even 4.0
chromatic Which part?
19:22 darbelo joined
allison making parrot PMCs, JIT, etc, self-hosting on a little language 19:23
dalek rrot: r38248 | fperrad++ | trunk (12 files):
[release] Changes to prepare for 1.1 release.
allison (if it'll even work, needs prototyping first)
Coke Whiteknight: at some point, we have to pay for the choices made by earlier developers. if that means we have to keep the old JIT on life support until we have a new JIT, thems the breaks.
Whiteknight allison: what if it wasn't a separate little language, what if it was a small subset of PASM with some C interface thunking added?
Coke: Paying down that debt involves removing the mistakes and replacing them, not living with them
chromatic How about making PMCs and ops self-hosting and emit C now? 19:24
allison Whiteknight: doesn't matter what the language is
it's the "self-hosting" part that's hard, no matter what syntax we use (we're good at parsing syntax of any variety)
Coke Whiteknight: I think that might contradict our support policy.
Whiteknight Anything we do to reduce manual synchronization between /src/ops/* and src/jit/* would be a major win
allison sure, but there's long-term planning involved 19:25
first, develop the system, prove it works and can replace the existing system
then we plan the deprecation cycle to replace the existing system
chromatic's right, I think self-hosting has a lot of potential 19:26
NotFound If we create a new way of writing pmc, surely we can have it working in parallel with the current one until all pmc are converted.
allison NotFound: two different simultaneous systems is a world of pain 19:27
chromatic Replacing Perl 5 as part of the PMC/ops build process is on the roadmap too.
Coke chromatic: I question that roadmap item.
allison chromatic: exactly, we have to do it anyway
Whiteknight I think I do too, we have a lot of complex build-time parsing that won't be easy to do with a different language
allison Coke: it's not that hard, everything we're currently doing in Perl 5 could be done in PGE 19:28
Coke ... except that PGE needs parrot.
cotto the parrot and the egg
allison Coke: it's not even platform-dependent, so we could have the C generated versions checked into source control and included in the tarball
chromatic Not everyone who builds Parrot has yacc/bison lex/flex installed.
allison chromatic: exactly
NotFound A Configure system for languages based only in parrot will be a nice start
Whiteknight some of the generated C code relies on constants derived from the Perl-based configuration system 19:29
Coke If I see a plan that's more than handwaving "replace perl5", i'll give it more thought. =-)
NotFound Whiteknight: and that is a big obstacle in the road to cross-compiled parrot
Whiteknight I don't want to poo-poo the idea, but replacing Perl 5 is going to be a lot of work and conceptually I don't see where all the pieces fit yet
allison Coke: it's a pile of smaller plans, not one big plan (since we're using Perl 5 in a number of different ways, for different reasons)
chromatic 1) Write a PGE grammar that can parse existing .pmc files and emit the same C code that the Perl 5 parser does. 19:30
Whiteknight NotFound: good point.
allison if it helps any, I've entirely eliminated Perl 5 in Pynie
we just don't need it
chromatic 2) Write a PGE grammar that can parse existing .ops files and emit the same C code that the Perl 5 parser does.
he whee: "All tests successful."
chromatic 3) Specify a new language in which to write existing code in .pmc files which the parser written in #1 can emit as the same C code as now.
nopaste "he" at 158.38.152.63 pasted "Current set of diffs (main.c is scheduled to go) for NetBSD/alpha" (266 lines) at nopaste.snit.ch/16366
chromatic 4) s/pmc/ops/ from #3
5) Write a new backend emitter which targets L1 ops for #3 and #4 19:31
Coke "L1 ops" ?
chromatic 6) Connect to the L1 op JITter
Shorthand for self-hosting opcodes.
NotFound chromatic: for bonus points, make it emit better C code that current ;)
allison I might put 5 before 3 & 4, but the general principle is sound
Coke what does "self-hosting opcodes" mean?
chromatic Imagine we had 128 opcodes which could replace every use of C in .pmc and .ops files.
Coke (also, please write this up on the wiki.)
allison Coke: chromatic has an idea for writing most of our ops in terms of a small set of jitted ops 19:32
chromatic Allocate/free a chunk of memory, call function, write to this chunk of memory, read from this chunk of memory, etc.
Those 128 opcodes are very, very easy to JIT.
allison Coke: think of it as changing most of our opcodes to be PIR functions
Coke allison: ok. so this depends on fixing jit on every core platform?
chromatic Now write the rest of our opcodes in terms of those Level 1 opcodes.
Whiteknight chromatic, I think we could do it in a lot fewer then 128 opcodes, if we used 3-argument commands that were type agnostic 19:33
allison Coke: actually, it doesn't, but it might make the JIT easier if we only had a very small number of opcodes written in C
chromatic Sure, it's probably more like 72 opcodes.
Whiteknight the generated C could would warn us about type mismatch insanity
allison Coke: and the rest were written in PIR (or some other simple language)
Coke (plan) Document plans.
allison Coke: the biggest problem now with the JIT is we have to write manual machine code for al 1,200+ opcodes 19:34
Whiteknight and we have to manually synchronize those definions with whats in src/ops/*
allison Coke: and this is not the official plan, or even close to it yet, but it's a good avenue for research and prototyping
chromatic The second biggest problem now with the JIT is that it *can't* improve performance for anything non-trivial.
Coke /is/ there an official plan, 'cause I don't know that one either. =-)
allison Coke: for the JIT? 19:35
Coke for the jit, for replacing perl5...
pmichaud I'm coming into the middle of this discussion (more)
Coke how jit would ever make something like "subclass" work...
(er, work faster)
pmichaud but it occurs to me that most PCT things, and especially Rakudo, would benefit most from something that can do very fast method dispatch
in particular, the number of opcodes that PCT tends to use is quite small.
Infinoid So, what can we do in the near term to reduce gsoc2009-llvm's chance of failure? 19:36
allison Coke: for replacing Perl 5, it's: Use PIR or HLL test files, write Test::Harness in PIR (or an HLL that runs on Parrot and can be compiled down to PIR)
rg needs more time to catch up on the logs to see what has been said about the jit discussion, but really wants it noted that the existing jit is incomplete, broken in parts and not well maintained already. sorry if that has been said already.
pmichaud it would be very interesting (and not very difficult) to do an analysis of what opcodes are being used in the PIR generated for Rakudo itself.
Infinoid rg: Yeah, it ended up turning into a discussion about how to redesign parrot well enough that the next jit will work better
allison Coke: write PGE parsers for the custom bits of parsing we do with Perl 5, and check in the generated versions of the files
Coke: for the JIT, the official plan at this point is keep improving and fixing the existing one, do some R&D on alternate strategies 19:37
Whiteknight Infinoid: In my opinion to help gsoc-llvm, we need to make the JIT interface as sane as possible 19:38
Infinoid I thought removing it would make it about 100% more sane :)
Whiteknight with a sane interface and good encapsulation, it will be easier to write any JIT core that we want or need
rg allison: i'd disagree there. spending time on improving and fixing the existing jit could be much better spent elsewhere. (i'm certainly not going to do it) 19:40
Infinoid Whiteknight: If you run across any tasks that need a strong back and a weak mind, lemme know. I've got some spare time in the next couple of weeks
Whiteknight Infinoid: If the task only requires a weak mind, I've got dibs :)
Infinoid heh
allison rg: then you should spend your effort on the R&D for alternate strategies :)
rg i might (or just fixing other bugs). the question then becomes what to do about the existing bugs. 19:41
Whiteknight allison: If you can think of any work that we could do to make the GSOC project run more smoothly, I think we have a few people here willing to work on it
Because I want that LLVM backend very badly
Coke chromatic: if we have opcodes that can be written in terms of other opcodes, wouldn't creating PIR syntax to generate the multiple simpler opcodes also be a viable strategy? 19:42
allison Whiteknight: that is a question for Kevin. But really GSOC is supposed to be an independent work. And we won't really know what needs to be done to core Parrot until he's made the experiments anyway.
chromatic I don't understand what "creating PIR syntax to generate the multiple simpler opcodes" means. 19:43
allison Whiteknight: that's what the project is about, experimenting
Coke PIR already has sugar to turn PIR into (multiple) opcodes, no?
allison chromatic: he means your "little bootstrapping language"
dalek kudo: a76abb3 | (Moritz Lenz)++ | src/setting/Match.pm:
fix .value confusion in Match.caps
 19:44
shorten dalek's url is at xrl.us/beptbe
Coke say, .get_results() ?
allison Coke: yes, it does
chromatic Oh.
allison Coke: an, in a sense this is an extension of that strategy
and
Coke ok. I wonder why the extension is necessary. =-) 19:45
allison hmmmm... yes, you're right, the compilation could be integrated into IMCC, or PIRC 19:46
chromatic I'm still not following.
Coke chromatic: you're suggesting that we have an opcode FOO that could be written in terms of opcodes BAR and BAZ, yes?
allison chromatic: well, it would mean we don't need a separate compiler
Whiteknight chromatic: he's saying that if all ops can be written in terms of a subset of simpler ops, then we could just replace complex ops with those sequences in IMCC
allison chromatic: some opcodes would be "pure" JITed opcodes, and others would be constructed from the pure opcodes 19:47
chromatic Okay. Sure, that can work.
particle sounds RISCy
allison it accomplishes the same thing, but with lower bootstrapping complexity
chromatic Except that it adds complexity if you want to define new ops as you go. 19:48
particle "as you go" == dynops?
allison depends on how the existing ops are created
it could be nothing more complex than ".sub myop :op"
chromatic They have to get registered with the compiler somehow.
allison and allow for dynamic extensions
that is, they're just simple subs, stored in some core namespace ('parrot'; 'ops') 19:49
particle an opcode segment in the bytecode?
allison or, at least some of them are
Coke if the PCC ever get fast enough, I will probably ditch dynops in partcl and just go for methods. 19:50
19:50 Infinoid_ joined
allison Coke: yes, that makes sense 19:50
chromatic The difference between dynops and methods is that you can always inline dynops.
At least, if they weren't big wads of C code.
Coke OOC, shouldn't inline op isne(out INT, invar PMC, invar PMC) just skip the check at the beginning and always call the VTABLE? 19:52
NotFound BTW, there is a real need for setstderr and such opcodes? I think that using interpreter methods can be good enough
Coke ah, the old opcode vs. method debate! =-)
NotFound Coke: vs. method and .vs pir directives. I won that in the HLL map case ;-) 19:54
Tene that wasn't an opcode, though 19:55
NotFound Was a pir directive
Uh, I mean "vs. opcodes and..." 19:56
dalek rrot: r38249 | chromatic++ | branches/headercleanup (5 files):
[runcore] Absorbed src/runops_cores.h into include/parrot/runcore_api.h.
 20:03
20:05 gryphon joined
allison going to catch a plane 20:06
20:10 bsdz joined
rg so i guess my answer on what to do about the existing jit bugs is "wait for someone to fix them properly"? 20:11
moritz well, it's always the same in open source - either you wait and hope, or do it yourself 20:12
rg well i have a workaround that just disables some of the existing code. a proper fix is way beyond my available time.
if that's not acceptable, i at least know what to focus my efforts on. 20:13
however some open source project prefer a working solution over a perfect fix. 20:14
chromatic It depends on the bug. 20:15
rg chromatic: in my case tt #530 and tt #551.
bsdz looking for some insight into pir inheritance issues. i notice that find_method looks though a pmc's methods but a lot of methods aren't methods and sit inside a namespace hash. here's a nopaste nopaste.snit.ch/16339 . should these multisubs be findable with find_method or are they not meant to be accesible to derived classes? 20:16
chromatic Ugh, I hate TT #530. 20:18
rg can you be more specific? 20:19
he Aand... Now lost the src/main.c diff, and still "All tests successful." 20:20
chromatic rg, I'm not sure not using float registers is the *right* approach, but in lieu of a better approach.... 20:21
rg like i said, it's not the *right* approach. that would be to remove all mappings before calling c. but it's the only approach i can manage. 20:22
dalek rrot: r38250 | fperrad++ | tags/RELEASE_1_1_0:
tagged release 1.1.0
 20:23
Infinoid Are we there yet? :)
rg and it's not that much of a hit, since c is called quite often. 20:24
chromatic If we document it and some thoughts on how to fix it the right way, if we ever get the chance, we'll know. 20:25
20:27 uniejo joined
Coke I would call c, but he changed his number after the stalking incident last yapc. 20:31
... you know, I really am not a fan of doing xml and text manipulation in Cold Fusion. :P 20:32
particle i know a language you can use to make that fun. 20:33
c!
pmichaud wow, running two sets of spectests in parallel really hits the battery 20:35
pmichaud looks for a power port.
Infinoid I've yet to find a language in which xml manipulation was fun. 20:39
confound LOLCAT 20:41
Infinoid shudders at the thought of doing xslt transforms in lolcode 20:42
chromatic You can remove "in lolcode" from that sentence and it's still true. 20:43
Infinoid Yeah, that's a big part of the problem.
dalek rrot: r38251 | chromatic++ | branches/headercleanup (6 files):
[runcore] Moved src/runops_cores.c to src/runcore/cores.c and fixed up all
20:43 HG` joined
he smolder.plusthree.com/app/public_pr...ails/20292 20:46
shorten he's url is at xrl.us/beptjz
particle Infinoid: you obviously haven't been introduced to LOLPATH 20:47
Infinoid he: Very nice. That's with the SIGFPE hack and nothing else? 20:48
rg also some varargs fixes
he Well, also with the workarounds for the assumption that va_args is integral or pointer.
Infinoid oh, ok
he Ref. the nopaste I gave a while earlier. 20:49
I did the platform misc.c / misc.h dance instead of the tweak in main().
sorry s/va_args/va_list/ 20:50
Changed prototype of Parrot_pcc_build_sig_object_from_varargs(). Is that one used by anything outside of parrot itself?
Infinoid Probably. 20:51
purl Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole.
Infinoid allison mentioned a better approach to that problem, earlier. I'll see if I can clean some of this stuff up tonight 20:52
Coke bsdz: I think you're conflating vtables and methods. 20:53
(at a quick read of your email.)
bsdz Coke: i admit there might be some conflation but really don;t understand what that namespace has is all about and why it's sucking in my methods. not sure why the methods has doesn't have them either :( 20:56
s/has/hash/
funny looks like message has disappeared. may be i started pointing to an unsynced google news server :/ 20:58
21:00 whoppix joined
bsdz must have been a strange google glitch. its come back 21:03
21:03 Whiteknight joined
chromatic Wow. The .str cleanup in make prog-clean is awful. 21:05
dalek kudo: 7c8346d | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 373 files, 10389 passing, 0 failing
21:05 dolmen joined
shorten dalek's url is at xrl.us/beptnw
Coke wonders what prog-clean is. 21:06
ah.
chromatic Fragile and broken, honestly! 21:07
Coke wonders, ooc, if the ext utils understand "*/*/*.str"
chromatic Or, like my imminent checkin will prove, we already have a perfectly good way to refer to all generated .str files: $(STR_FILES) 21:08
Coke ... mmmhehehe.
dalek rrot: r38252 | chromatic++ | branches/headercleanup/config/gen/makefiles/root.in:
[config] Improved cleaning of generated .str files; now it gets them all.
 21:09
particle notes root.in isn't a header 21:10
chromatic Sure, but it's only an issue right there because my header changes exposed breakage in that assumption.
It *may* be an issue on trunk, but that's only if people start moving around files with embedded CONST_STRINGs. 21:11
dalek rrot: r38253 | chromatic++ | branches/headercleanup (4 files):
[runcore] Moved src/trace.c to src/runcore/trace.c and its header to

runcore, so they're there now.		 21:13
kudo: ad73895 | (Moritz Lenz)++ | (2 files):
bump PARROT_REVISION to parrot-1.1 release
shorten dalek's url is at xrl.us/bepto7
moderator #parrot Parrot 1.1.0 Released | parrot.org/ 21:15
dalek tracwiki: v65 | fperrad++ | WikiStart 21:16
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/beptpm
Infinoid fperrad++ 21:17
fperrad fperrad needs help 21:20
on website www.parrot.org, I can't find "Create content" -> "Story"
just "Create content" -> "Scratch"
Infinoid there are 3 items in the Create content menu for me... Page, Scratch and Story 21:21
One moment, I think I can fix this 21:23
fperrad: try now?
particle you just gave fperrad editor?
Infinoid poster, actually
judging from the access control page, poster has "create story content" 21:24
particle should add this requirement to the release manager guide
fperrad "Story" now available, thank 21:25
Infinoid wow, parrot.org has a ton of registered users. 21:26
rg doesn't see it :( 21:27
chromatic fperrad, is it safe to commit to trunk now? 21:28
Whiteknight fperrad++
particle Infinoid: yeah, seems there's a bot registering users there 21:29
it's annoying
fperrad Yes, tag is created
chromatic Thanks.
Infinoid particle: as long as they aren't creating any spam content... 21:30
dalek rrot: r38254 | chromatic++ | branches/headercleanup (151 files):
[headercleanup] Brought the headercleanup branch up to date with r38253.
Coke chromatic: any issues with files changed after you moved them? 21:31
chromatic None.
That bothers me not a little.
Coke did the merge warn about anything skipped?
chromatic No.
Coke were one paranoid, one could run a double check. 21:32
chromatic Did I hear a volunteer? Someone who ran the original check and knows what to look for? 21:33
'cuz I read your diffs, but didn't entirely follow them.
Coke hurm?
purl Yes, Rorschach.
Coke now I'm confused. which diffs?
dalek rrot: r38255 | Infinoid++ | trunk/config/auto/gmp/gmp_c.in:
[config] Work around RT #50212, by disabling the win32 crash dialog for the test.
rrot: r38256 | Infinoid++ | trunk/config (2 files):
[jit] Apply patch from he++ to make sure platform assembler helper files are preprocessed on NetBSD, by using the .S extension instead of .s.
chromatic You made several commits to clean up things, some type and signature declarations. 21:34
Coke Presumably I knew what I was doing at the time.
I can review them in your branch if you like, but now's a bad time. 21:35
chromatic Do you remember which tests you were trying to make pass?
21:35 allison joined
allison fperrad: ping 21:35
Coke if I had a revision number, I could probably tell you. 21:36
or a file?
chromatic Coding standards tests, I think. 21:37
moderator Parrot 1.1.0 Released | parrot.org/ | 332 RTs left 21:37
Coke oh, no doubt. 21:37
chromatic svn: Working copy path 'docs/book/appb_patch_submission.pod' does not exist in repository 21:38
Joy.
fperrad allison, have you receive my email ?
chromatic That's almost enough to make me want to put on leather pants and let Git hit me in the head with a baseball bat again.
allison fperrad: yes, that's why I hopped on IRC
fperrad: did you get it sorted?
Coke renaming files is, according to a core svn developer, something you really want to do on trunk. when you have no branches. 21:39
allison (it doesn't work for me either)
Coke s/core svn developer/someone I met on #subversion/
I assumed he was a developer.
chromatic: if you don't have a lot of commits, it /might/ be easier (given the renames) to just replay them against trunk. 21:40
allison fperrad: I'm at the airport and about to hop on a plane
Coke gotta run.
bacek good morning 21:41
fperrad allison, not sorted
particle maybe i can help? what's broke? 21:42
allison fperrad: okay, looking into it
particle: the password to the FTP server
particle ah, hrmm.
21:43 darbelo joined
allison particle: I sent him the one from my password database, but not working 21:43
particle 530 This FTP server is anonymous only.
allison particle: it's used via ssh, not ftp 21:44
particle sigh.
fperrad chromatic, do you have account information about ftp-osl.osuosl.org 21:45
particle fperrad: i get access denied, too
time for a support ticket, i suppose
21:47 kid51 joined
allison particle: much appreciated, I'd do it but will be in the air for the next 2 hours 21:47
particle i'm sending ticket, copying francois
allison has to board 21:49
particle safe flight
allison particle: thanks!
dalek rrot: r38257 | cotto++ | trunk/src/pmc/exceptionhandler.pmc:
[PMC] remove ExceptionHandler's destroy, as the inherited one does the same thing
 22:00
cotto chromatic, when are you planning on merging headercleanup? 22:02
chromatic If and when SVN lets me.
particle if you're using svn 1.5, it should be less painful 22:03
...if it was also used to create the branch.
chromatic 1.5.1, yep 22:04
22:05 otto joined
particle svn merge --reintegrate svn.parrot.org/parrot/branches/headercleanup 22:05
chromatic Trying that. 22:06
dalek website: fperrad++ | Parrot 1.1.0 "Half-moon Conure" Released! 22:09
website: www.parrot.org/news/2009/Parrot-1.1.0
chromatic Some revisions have been merged under it that have not been merged into the reintegration target; merge them first, then retry. 22:10
This is clearly not something I'm going to accomplish before lunch.
fperrad Infinoid, on website, 22:15
I can't found "Publishing options"
See release_manager_guide item 10.d
I have no access to "Administer" -> "Site building" -> "URL Redirects"
See release_manager_guide item 10.e
otto I have some thoughts on versioning of modules as related to perl dist/mods/namespaces etc 22:17
see perlmonks.org/?node_id=758791
is it the responsiblity of parrot to read the bytes off disk prior to lexing'parsing? 22:18
dalek rrot: r38258 | cotto++ | trunk/src/pmc.c:
[PMC] call a PMC's destroy VTABLE function before reusing it
moritz otto: what part of parrot are you refering to? 22:20
otto: compilers that use parrot as a backend may do everything they want
though I think that PCT based compilers first read the whole string 22:21
otto is there a nice pic of where parrot fits in the process?
bottomline is if someone want to always calc a hash of the file that was being loaded, where would it be best done?
you're reading the bits to parse, why not calc the hash at that time? 22:22
moritz sure, that makes sense
otto issue leads to what is a 'version' of perl mods v. dist containing mod leads to why have a version on a mod part of dist 22:23
so then you simply want a good id of a mod, and something in the mod to get to the dist version which contained it 22:24
moritz I think that a single version for a distribution should be enough
otto so a hash of the mod is a good start, kinda like git
i agree on the single version number for a whole dist...
dalek rrot: r38259 | cotto++ | trunk/src/pmc.c:
[PMC] shuffle statements around so comments still make sense (no functional changes)
otto i started a discussion at perlmonks.org/?node_id=758791 and some related problems with versioning each mod 22:25
moritz and I answered, yes ;-) 22:26
otto ah thx
Infinoid fperrad: did that help? 22:27
fperrad Infinoid, thank, now, www.parrot.org is OK 22:30
Infinoid ok, great. sorry about the delay, I'm still at work 22:31
moritz fperrad++ Infinoid++ 22:32
Infinoid I can fix the release/current redirect if you want
bacek cotto: around? 22:33
fperrad Infinoid, yes 22:34
NotFound "For all the suggestions I've heard the past years to change the CPAN VERSION handling, yours is the most insane. By a long shot." --> Nice comment ;) 22:35
bacek purl: msg cotto Ignore my comment on #46703.
purl Message for cotto stored.
Infinoid fperrad: I will update it as soon as I see the new version on the ftp site 22:36
particle: FYI, sounds like the release manager guide requires the drupal "poster" bit for most of it, the "editor" bit for section 10.d and the "admin" bit for 10.e 22:43
22:45 Limbic_Region joined 22:58 tetragon joined
dalek rrot: r38260 | cotto++ | trunk/src/pmc/string.pmc:
[PMC] remove workaround that's no longer needed
 22:58
cotto bacek, will do
dalek rrot: r38261 | whiteknight++ | trunk/src (3 files):
a fix for TT #218. Use elements() and get_pointer() VTABLEs in the sort() method, so that it can be properly used by subclasses. Also, modify the semantics of the get_addr opcode to consistently return the memory address of the PMC, instead of returning whatever value get_pointer was returning (which is not consistent for all PMCs)
 23:11
kudo: 50f6111 | (Moritz Lenz)++ | src/setting/Match.pm:
handle quantified captures in Match.perl

because of another rakudobug (RT #64952).		 23:12
shorten dalek's url is at xrl.us/bept7j
dalek kudo: 581f573 | (Stephen Weeks)++ | src/parser/actions.pm:
Migrate actions.pm to use .ast instead of $()
 23:22
shorten dalek's url is at xrl.us/bept8t
23:28 particle1 joined
Infinoid Is there any reason not to enable optimization for core_ops_*.c if the compiler is gcc? Andy D has provided a patch (TT #571) which does so, and cleans up the (currently unhandled) core_ops_cgp.c case. 23:33
dalek rrot: r38262 | whiteknight++ | trunk/src (3 files):
undo the last commit because it exposes an error elsewhere that I didn't see. Posted a message to TT #213 to explain the problem and propose a solution
 23:41
tracwiki: v9 | Infinoid++ | ParrotQuotes 23:44
tracwiki: Moar quotes.
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/bepua5
dalek tracwiki: v10 | Infinoid++ | ParrotQuotes 23:47
tracwiki: You missed a spot.
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/bepubu 23:48
dalek kudo: 2665575 | (Stephen Weeks)++ | src/parser/actions.pm:
Fix actions.pm by replacing .ast() with .ast
 23:58
shorten dalek's url is at xrl.us/bepucv
fperrad particle, we've an answer 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!