Parrot 0.9.0 | parrot.org/ | 468 RTs remain
Set by moderator on 11 February 2009.
dalek rrot: r36701 | allison++ | trunk:
[cage] Removing old slide presenter example, and orphaned top-level directory that contained it.
 00:00
Whiteknight any time a GC run is triggered inside Parrot_pcc_invoke_method_from_c_args, it's like rolling the dice. Sometimes we segfault, ometimes we core dump, something it works perfectly 00:01
rurban Latest gdb 6.8.0 should be much safer with invalid accesses and hw watchpoints
chromatic Sounds like CPointer marking.
Whiteknight yeah, these CPointers are bastards
they're like red-headed step children, and I'm going to beat them
dalek rrot: r36702 | jkeenan++ | branches/update_pod:
Move opcode-doc.t to t/codingstd/.
rrot: r36703 | jkeenan++ | branches/update_pod:
With no tests remaining in t/doc/, we can delete it from repository (for now,
 00:03
Whiteknight what's funny though is that this last one segfaulted on a function that was "->I", so there wasn't a PMC or a STRING result stored in a CPointer anyway 00:04
chromatic Do you have a backtrace?
00:09 AndyA joined
nopaste "kid51" at 70.85.31.226 pasted "'make' failed quickly in rename_pccinvoke branch" (158 lines) at nopaste.snit.ch/15612 00:09
kid51 Wait a minute. that may be spurious. Am out of space. 00:12
time for ccache -C 00:14
... which freed up 27% of disk space 00:15
So ignore paste 15612
nopaste "Whiteknight" at 71.225.49.205 pasted "backtrace for rename_pccinvoke failure" (101 lines) at nopaste.snit.ch/15613 00:19
dalek rrot: r36704 | allison++ | trunk/lib/Parrot/Manifest.pm:
[cage] Remove special case from manifest generator for deleted directory.
Whiteknight it calls Parrot_pcc_invoke_method_from_c_args, which calls itself recursively later, which then triggers a GC run
it always seems to segfault in compact_pool, which leads me to believe it's a string problem 00:20
also, every failure I've seen so far has had a "S->*" signature
nopaste "kid51" at 70.85.31.226 pasted "'make' died, but not so quickly this time" (804 lines) at nopaste.snit.ch/15614 00:21
Whiteknight somewhere along the line we are losing a STRING 00:26
I tried registering the STRINGs to keep them from getting collected, and that actually made the error worse
00:27 TiMBuS joined
Whiteknight src/io/api.c =~ s/Parrot_pcc_invoke_method_from_c_args/Parrot_PCCINVOKE/g and everything works perfect 00:36
the IO subsystem seems to make a lot of recursive calls to it, which seem to be exposing the errors 00:40
dalek rrot: r36705 | whiteknight++ | branches/rename_pccinvoke/src/io/api.c:
[rename_pccinvoke] roll back changes in src/io/api.c, because it's causing all sorts of crazy problems.
 00:43
Whiteknight I'm just going to ignore the problem for now
dalek rrot: r36706 | jkeenan++ | branches/update_pod/src/io/win32.c:
Correct C parentheses error (already fixed in trunk).
kid51 goes for beer while perlcritic.t runs 00:48
dalek rrot: r36707 | jkeenan++ | branches/update_pod/lib/Parrot/Test/Pod/Util.pm:
Eliminate trailing whitespace.
 00:52
rrot: r36708 | jkeenan++ | branches/update_pod/lib/Parrot/Harness/DefaultTests.pm:
For the time being, temporarily exclude two files recently transferred into t/codingstd/ from the list of tests run during 'make codetest'.
 00:53
kid51 Whiteknight: That revert of api.c enabled 'make' to complete. Do I need to try 'make test'?
Whiteknight you can if you have time, the revert should have fixed all the problems 00:55
everything is passing on my computer 00:56
dalek rrot: r36709 | whiteknight++ | branches/rename_pccinvoke/src/pmc:
[rename_pccinvoke] rename all instances of Parrot_PCCINVOKE from src/pmc/*. All tests pass
 00:57
Whiteknight question: How do we get this to build with ccache?
kid51 Whiteknight: You talkin' to me? 00:59
My ccache problem had nothing to do with the test failure.
Whiteknight I'm talking to anybody. I just installed ccache and I want to use it when I build 01:01
Configure.pl --cc="ccache gcc", right?
01:02 mberends joined
kid51 Whiteknight: man ccache then look for INSTALLATION 01:07
You're attempting what they characterize there as the first method; I use the second.
c and coke told me how to do it >1 year ago; started doing it; haven't had to think about it since. 01:08
...errrrm, except when the cache fills up my disk.
So I get: 01:09
$ which gcc
That should have been: /usr/lib/ccache/gcc
Whiteknight thanks 01:10
kid51 And, in turn, ll /usr/lib/ccache/gcc 01:11
lrwxrwxrwx 1 root root 16 Aug 17 2007 /usr/lib/ccache/gcc -> ../../bin/ccache
Whiteknight: smolder.plusthree.com/app/public_pr...ails/18004 is make smoldertest on your branch at r36699 01:13
shorten kid51's url is at xrl.us/bef7pp
kid51 Everything passes.
purl add more tests
kid51 How do I teach purl a new reply (one that's not in "something is X" format)? 01:20
Whiteknight excellent! Thanks kid51++ 01:23
rg something is <reply> just say this 01:28
something
or not
purl: something?
purl rg: bugger all, i dunno
rg purl: something is <reply> just say this 01:29
purl ...but something is <reply>...
rg oh that was cleared already
kid51 I've been trying to figure out <reply>
rg but i liked that reply to everything passes :)) 01:30
bacek Everything passes. is <reply>You probably miss something.
Everything passes.
purl You probably miss something.
kid51 Everything passes
bacek rg: is should be no space between <reply> and phrase. 01:31
rg ok
purl, no, Everything passes. is <reply>You probably missed something.
purl okay, rg.
rg Everything passes.
purl You probably missed something.
rg better
bacek purl, no, Everything passes is <reply>You probably missed something. 01:32
purl okay, bacek.
kid51 Everything passes
purl You probably missed something.
bacek this is better :)
kid51 Yes: No wordspace after <reply>
bacek Everything passes.
purl You probably missed something.
kid51 Everything passes
purl You probably missed something.
kid51 Trailing period is ignored, which DWIMs 01:33
rg not sure, we've used both ways
purl, no, Everything passes. is <reply>Add more tests ;) 01:34
purl okay, rg.
rg Everything passes
purl You probably missed something.
rg Everything passes.
purl Add more tests ;)
rg sorry, it's different
bacek purl, no, Everything passes is also <reply>Add more tests! 01:37
purl okay, bacek.
bacek Everything passes
purl You probably missed something. or <reply>Add more tests!
bacek purl, no, Everything passes is <reply>You probably missed something.
purl okay, bacek.
01:45 particle joined
rg hmm i'm seeing a failure in t/op/trans.t on solaris in test atan, part 2. does anyone have a guess or will it have to wait until i have time to investigate? 01:48
chromatic JIT core or slow core?
rg solaris sparc, that is. a recent smolder in solaris x86 does not report it
kid51 Solaris is one of our less tested systems. I think we've received that report previously, but we don't get steady enough development there to correct it. 01:49
rg i was setting up this box, since 64bit big endian seemed to be one of the least tested systems. 01:51
01:57 particle joined 01:59 iblechbot joined 02:07 ask_ joined
dalek rrot: r36710 | jkeenan++ | branches/update_pod:
Rename sub in pod.t to be more self-documenting. Write result to disk via
 02:24
02:37 particle1 joined 02:41 particle joined 02:48 ask_ joined 03:00 TiMBuS joined 03:09 eternaleye joined 03:11 Theory joined
dalek rrot: r36711 | jkeenan++ | branches/update_pod:
Extract oreilly_summary_malformed() from t/codingstd/pod.t and place it in Parrot::Test::Pod::Util.
 03:12
rg ok, that solaris failure is a known bug documented in #34549 03:13
kid51 I think we've seen it on other platforms as well. 03:20
rg the ticket says openbsd, netbsd and cygwin are (or were at some point) also affected 03:21
also, the test is todo-ed on netbsd
03:22 jimmy joined
rg i'm somewhat surprised it doesn't fail on solaris/x86(_64) 03:24
dalek rrot: r36712 | jkeenan++ | failed to fetch changeset:
Move one test from pod.t to pod_syntax.t. Extract this test's 'second pass'

  .pod_examinable*.sto.		 03:34
rg ah, that's probably because they were not using gcc 03:35
03:36 janus joined, gravity joined 03:40 Andy joined
bacek msg pmichaud In sub 'fail' call to "'return'(result)" looks strange. Especially right before ".return(result)" 03:40
purl Message for pmichaud stored.
dalek rrot: r36713 | jkeenan++ | branches/update_pod:
Rename pod.t to pod_description.t to reflect fact that test of POD syntax has

  .pod_examinable*.stor files. Update list of test files skipped for 'make
codetest'.		 03:54
04:20 rurban_ joined 04:37 particle1 joined
dalek rrot: r36714 | allison++ | trunk:
[cage] Updating special tags generated on manifest files to fit a sane package

of use/not maintained).		 04:44
04:50 Andy joined 05:30 eternaleye joined 05:47 jimmy joined
dalek rrot: r36715 | petdance++ | trunk/src/pmc:
more consting
 06:04
06:46 jimmy_ joined 07:02 Tene joined
dalek rrot: r36716 | Infinoid++ | trunk:
[cage] Fix codetest failures.
 07:13
rrot: r36717 | allison++ | trunk/MANIFEST.generated:
[cage] Tag generated manifest files with the correct package names.
 07:20
rrot: r36718 | allison++ | trunk/compilers/imcc/main.c:
[cage] Cosmetic capitalization for -V flag output.
 08:07
rrot: r36719 | allison++ | trunk:
[install] Fix persistent install location problems with 'runtime' files. Use
 08:11
rrot: r36720 | allison++ | trunk/src/library.c:
[install] Search versioned install directories for runtime library, include,
 08:12
08:18 mikehh joined 08:42 barney joined
dalek rrot: r36721 | allison++ | trunk:
[install] Add an 'install-dev' target for installing necessary language build tools.
 09:38
rrot: r36722 | allison++ | trunk:
[cage] Further cleanups on manifest file categorization, particularly in
 09:42
09:44 alvar joined
dalek rrot: r36723 | allison++ | trunk:
[install] Clearly mark PGE as its own package, and also install it by default.
 09:45
nopaste "rurban" at 212.183.50.177 pasted "msg particle for ccache cl detection" (16 lines) at nopaste.snit.ch/15617 09:48
rurban msg particle smolder.plusthree.com/app/public_pr...st_failure 09:49
purl Message for particle stored.
shorten rurban's url is at xrl.us/bef9a7
rurban msg particle "fix ccache cl detection" at nopaste.snit.ch/15617
purl Message for particle stored.
rurban allison: I've added trac.parrot.org/parrot/attachment/...evel.patch 09:52
shorten rurban's url is at xrl.us/bef9bs
dalek rrot: r36724 | rurban++ | trunk/t/pmc/os.t:
[cage] fix failing "ccache cl" detection from smoke #18009
 09:56
allison rurban: okay, looks good 09:57
purl O_O
rurban but there are still issues in the installed linking steps
thanks for versioned parrot btw. big feature! 09:58
allison versioned libparrot should be used by default, that would resolve the libparrot.so problem 10:00
rurban i have it in cygwin also, but I think the DEVEL versions should skip the dll/so versioning 10:01
allison in fact, we should never install an unversioned libparrot.so
nopaste "rurban" at 212.183.50.177 pasted "skip DEVEL dll versioning" (21 lines) at nopaste.snit.ch/15618 10:02
allison even devel versions should use only versioned libparrot.so
rurban like -lparrot.0.9.0 10:03
allison like libparrot.so.0.9.0-devel
(not standard naming, but only used for devel versions)
rurban good
very good 10:04
allison and, it matches the versioning in the directories, and PARROT_VERSION #define
rurban uuh, someone did Parrot_trace_eprintf args to Parrot_trace_eprintf (args). this fails now with the varargs macro problem 10:10
dalek rrot: r36725 | rurban++ | trunk/include/parrot/packfile.h:
revert r36716. we need this trick here.
 10:14
10:37 jimmy joined 10:39 nihil joined 10:40 nihil left 11:24 masak joined 12:13 iblechbot joined 12:18 rurban_ joined
rurban icc failures on 32-bit 12:46
testing openbsd now 13:13
dalek rrot: r36726 | fperrad++ | trunk/tools/dev/install_dev_files.pl:
[codingstd] fix SVN properties
 13:15
rrot: r36727 | fperrad++ | trunk/tools/dev:
[codingstd] remove hard tabs
 13:32
13:33 IceGuest_7 joined 13:42 cognominal joined
rurban Shouldn't we note somewhere that we require TAP::Harness:Archive 13:51
aargh, openbsd is secure. so they don't even have rsync and wget 13:59
but they have lynx so I can at least download
14:13 kid51 joined
rurban hi kid51 14:13
kid51 good morning, reini 14:14
rurban tried openbsd, but just got 3.8 and nothing works there 14:15
kid51 3.8 is what version? 14:16
rurban openbsd 3.8
kid51 "nothing works" => Parrot can't configure? Parrot can't build?
I mean, is that the latest openbsd?
rurban no wget, no rsync, no editor, ... 14:17
pure bare raw
kid51 Ah.
rurban but I got perl and gcc and will check the openbsd specials now
kid51 I have no experience myself on OpenBSD, so I don't know what the environment feels like. 14:18
I've just been following the Smolder results.
.... and have been trying to meet OpenBSD people in NYC and talk to them about Parrot.
There's probably a minimum number of "ports" that you would have to install to get a comfortable working environment. 14:19
rurban I've got scp working so I can at least parrot over there
copy parrot
kid51 Since OpenBSD's philosophy is "secure by default", I'm not surprised that it comes bare bones. 14:20
I know when somebody gave me a Solaris account, many things I take for granted on Linux/Darwin were missing/different and adaptation was difficult, requiring too many tuits. 14:21
rurban I hope I can at least send smolders from there 14:24
14:31 rg joined, cognominal joined
rurban Oh, and it compiled all static. no space left on device 14:33
rg rurban: you realize that openbsd 3.8 is quite old and probably not even supported anymore by the openbsd people?
rurban sure
14:33 masak joined
rurban but it's the cheapest, 400mb and no symbols 14:34
we really have to check -shared for the cc and use it then 14:35
we only check for -DPIC and -fPIC and using it but without -shared makes no sense. 14:36
rg for me on freebsd parrot is properly linked against shared libs. did you configure with --parrot_is_shared? 14:40
rurban nope
rg i guess you'll need that 14:42
kid51 rg: How old is that version? Is it so old that it wouldn't fall into our OS support criteria? 14:44
rurban I just want to see another -0.0 problem 14:45
Because on msvc6 it reappeared after I though I've fixed it.
But only on printing pmc's, not numbers
and that should be handled just fine in our sprintf implementation 14:46
kid51 Per www.openbsd.org/: The current release is OpenBSD 4.4 which was released Nov 1, 2008.
rg 3.8 was Nov 1, 2005 14:47
rurban I see the problem: The latest change from LD to LINK broke building shared utils 14:48
14:52 cognominal joined
IceGuest_7 allison: ping 14:58
kid51 NotFound++ for handling those spammy TTs
kj allison: ping
15:06 NotFound joined
NotFound hi 15:06
purl what's up, NotFound.
15:08 Whiteknight joined
kj Whiteknight: ping 15:11
15:13 Limbic_Region joined
kj anybody around who knows about distro_tests? 15:17
lu_zero no clue ^^
rurban the new thing is testing the installed version
I did this by renaming the build-dir and checking a few things 15:18
but now you've also giot make install-devel and then you can run almost the whole testsuite on the installed version. theoretically 15:20
Whiteknight kj:pong 15:30
kj Whiteknight: hi
do you have a few minutes?
I'm preparing for the next parrot release 15:31
dalek rrot: r36728 | NotFound++ | trunk/t/src/embed.t:
[test] embed.h without extend.h
Whiteknight kj: of course. What do you need? 15:32
15:32 mikehh joined
rurban building shared fails for me on this old gcc-3.3.5/openbsd-3.8: /miniparrot[1]: syntax error: `(' unexpected statis is ok 15:32
static is okay. 15:33
kj well, in the release manager guide it says something about 'coordinate 4-5 platforms' to run mk_native_pbc
rurban I've added that :)
Whiteknight oh, that must be new. I didn't have to coordinate any platforms when I was release manager
kj ah ok.
rurban When they are not ready they are not. kid51 can provide the darwin/ppc stuff 15:34
I can provide the rest
BE 64bit will be missing. But these tests currently fail on cross 32-64 bit
Whiteknight kj: so you want me to do the tests on my computer? 15:35
kj Whiteknight: please :-) What platform you're on?
Whiteknight I've got Ubuntu-8.10-x86_64 and WinVista-x86_64 here
kj I'll start making a list of different platforms/people
rurban But I'll commit the natve_pbc's for 1,2+4,5 soon
kj does it make a difference what linux distributions are tested?
Whiteknight i have no idea to be honest 15:36
okay, so what tests do I have to run?
rurban the trick is to fake the version to 0.9.1 and create the pbc's there. OR use the tools/dev/pbc_header.pl tool
kj Whiteknight: well I think they only need be run near the relase
rurban The people/platform list already on the wiki 15:37
kj Coordinate 4-5 platforms to run C<tools/dev/mk_native_pbc>
to update the native tests
that's what the guide says
rurban the docs should point to that maybe
kj rurban: thanks
rurban I wrote that chapter, yes :)
If it's unclear I'll fix it. Just ask 15:38
kj rurban: you mean in the release guide?
rurban yes
Because these teste where never done, and they shoudl be sooner or later
kj rurban: so basically the release manager needs help of 4-5 other peo[ple (assuming 1 person/platform) for thesee tests? 15:39
rurban mostly just a macbook person is enough
if you get access to a normal multi-arch x86_64 platform with -m64 and -m32 you can make 4 of those pbc's by yourself. 15:40
But it's optional I would say 15:41
kj rurban: on windows, I can't run tools\\dev\\mk_native_pbc
it seems I need access to a linux box to do the release... 15:42
rurban yes, you need bash 15:44
cygwin is enough, or colinux
kj parrot doesn't build on my cygwin environment
not last time I checke
rurban or a vmware: www.thoughtpolice.co.uk/vmware/howt...guide.html
shorten rurban's url is at xrl.us/bef9rr
rurban but better get a x86_64 linux image if so. 15:45
dalek rrot: r36729 | fperrad++ | trunk/tools/install/smoke.pl:
[install] fix new install paths
rrot: r36730 | Infinoid++ | trunk/config/gen/makefiles/root.in:
[cage] parrot_debugger makefile rule uses src/parrot_config.o but doesn't
 15:47
kj nopaste?
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
rurban Infinoid: good catch! that was my dmake failure
Infinoid++
nopaste "kjs" at 193.120.116.183 pasted "cygwin output of 'make'" (4 lines) at nopaste.snit.ch/15619
Infinoid cages cleaned for fun and profit :) 15:48
kj rurban: I get a weird error immediately on cygwin
Infinoid racing sailboats &
rurban latest perl?
purl latest perl is whatever can be had at www.perl.com/CPAN/src/latest.tar.gz or 5.005_03
kj 5.8.8I think
dalek rrot: r36731 | fperrad++ | trunk:
[install] add a smoke test for external languages
kj I thought 5.8 should be enough no?
rurban cygcheck -c perl
perl 5.10.0-5
kj 5.8.8-4
rurban Older perls might have internals problems. I'm the packager
kj how do I update that?
dalek rrot: r36732 | fperrad++ | trunk/tools/dev:
[inno-setup] fix new install paths
rurban I can check with 5.8.8-4 also
Would be better to fix and and fix that
kj you mean, you can build with 5.8.8-4?
rurban Would be better to find the error and and fix that
Nope, Trying now.
Some regex problem maybe 15:51
kj seems so yes
do you know how to update the perl version?
on cygwin
rurban cygwin.com/setup.exe 15:52
kj I think I tried that, but the version won't update
rurban but then you'll get a whole bunch of updates...
kj there's no command to only update perl?
rurban yes, 5.8.8-4 had problems. 5.8.8-5 was latest there 15:53
no, sorry
5.8.8-5 15:55
- added missing Win32 for perl-libwin-0.27
- REGEXP0 - fix for UTF-8 recoding in regexps - CVE-2007-5116
- several CPAN vendor_perl updates
but perl-5.10.0-5 is much better
kj and I can get that one as well through cygwin installer? 15:56
ISTR I tried that before, and didn't work
rurban perl-5.10.0-5 is the default, yes 15:59
should I send a recipe how to install both parallel? 16:01
kj I'm running cygwin installer now
you mean, both as in 5.8.8 and 5.10?
rurban perl-5.8.8-5 works fine
kj I'll just try to update to 5.10
rurban: for a long time, miniparrot failed on cygwin; I understand that's fixed now? 16:02
(if you can remember what that error was..) 16:03
rurban sure
that was a PATH issue, blib/lib was missing
kj ... in parrot configureation?
rurban I moved the dll to the exe, that fixed all issues
kj what does that mean? 'moving the dll to the exe'?
(sorry, just curious what caused that)
rurban /usr/bin/perl5.8.8.exe tools/build/ops2c.pl C --core also works fine with 5.8.8-4 for me. strange
blib/lib/cygparrot.dll => ./cygparrot0_9_0.dll 16:04
so it works with already insalled parrot also and didn#t require the ugly hack: export PATH=`pwd`/blib/lib; perl Configure.pl && make 16:05
kj but this is no longer needed?
rurban nope 16:06
kj nice
rurban but I cannot reproduce your error, sorry
woudl be really nice to catch such a thing
kj $ /usr/bin/perl5.8.8.exe tools/build/ops2c.pl C --core 16:07
Parrot::OpsFile: Unrecognized line: 'inline op end() :base_core :check_event :flow {
'!
rurban: anyway, thanks for your help. Will attempt again to build parrot on cygwin after updating. 16:08
rurban debugging into it would be fine... 16:09
kj I have little knowledge of Perl, or cygwin for that matter :-S
rurban That's areally hairy regex in the OpsFile 16:10
$op_sig_RE is failing for you
It must be this line: ((?: \\:\\w+\\s*)*) # :flags 16:11
maybe I can reproduce it somewhen, and make it more stable
NotFound inter::progs - Determine what C compiler and linker to use...Compilation failed with 'g++' 16:12
kj well, once we have parrot 1.0, perhaps ops2c can be reimplemented using pge
rurban the ldflags <=> linkflags issue maybe
that changed recently 16:13
NotFound My fault there was an spurious character in the line 16:14
rurban btw. I had a strange icc bug today: TT #332 16:17
with icc and static I get nearer to the real error, not an internal idb bug anymore 16:25
16:39 Tene joined
rurban is there's a tutorial how to step into imcc crashes somewhere? -t does not help 16:39
./miniparrot -b -v -t -d=ffff config_lib.pasm Starting parse... Segmentation fault 16:43
17:00 particle joined
dalek rrot: r36733 | NotFound++ | trunk/src/pbc_disassemble.c:
fix: c++ need cast in int to enum conversions
 17:27
17:40 mberends joined 17:56 ask_ joined 18:20 mikehh joined 18:59 cognominal joined
kj rurban: I updated cygwin, perl is now version 5.10.0-5; still have the error 19:02
19:04 gryphon joined 19:05 Whiteknight joined
allison kj: wasn't awake yet, around now if you still have a question 19:18
kj allison: hi; for now it's fine, thanks
1 thing though: can i do a release on a windows platform?
allison kj: I imagine so, but would go through all the steps and produce a test release to make sure (then have other platforms try your test release) 19:20
kj ok, but some commands can't be run on windows 19:21
dalek rrot: r36734 | fperrad++ | trunk:
[doc] fix POD syntax
allison kj: then, no, you can't :) or, at least you'll have to run those steps on linux/mac 19:37
kj allison: thought so. I have access to moritz' liinux box, now running fulltest, lots of "not ok" 19:39
not sure whether that has anything to do with running tool/dev/mk_native_pbc
(wchih I did)
allison kj: post the failures? 19:40
kj yep, still running
it's slightly slower than expected
allison fulltest?
kj yes think so (it's been some time already, kinda forgot what I typed) 19:41
nopaste? 19:43
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
nopaste "kjs" at 193.120.116.183 pasted "make fulltest; snippet of output; not ok tests: TODO" (23 lines) at nopaste.snit.ch/15621 19:45
kj allison: just a random output sample with not ok tests
allison kj: okay, I'm running 'make fulltest' now on my box 20:00
kj on windows I've never seen this kind of output; perhaps it's skipping more on win due to missing libs or whatever 20:01
rurban kj: back I would skip tool/dev/mk_native_pbc if it doesnt work for you 20:03
kj rurban: on cygwin I still cant' build; now perl v 5.10
rurban kj: nopaste 14521 is okay. this is not yet implemented and marked as TODO 20:04
same error? 20:05
kj rurban: yes
so it's probably something else
rurban maybe you need to turn the files to unix eof on cygwin. d2u src/ops/*.ops
does it work in windows? 20:06
kj the d2u thing helped, but now a different error;
CONST_STRING split accross lines
in src/debug.c
rurban okey, so you have to unixify all source files.
kj will try now 20:07
I check out in a folder in windows, but accessible in cygwin
so 1 wc, but 2 environments
that's probably the culprit
rurban find . -name \\*.c -exec d2u '{}' \\;
okay, I use seperate folders. I'l nopaste my update script 20:08
nopaste "rurban" at 212.183.48.71 pasted "mingw folder update script (from cygwin)" (28 lines) at nopaste.snit.ch/15622 20:09
kj yes separate folders is better i think considering svn:eol-style = native
rurban I use unix eol on all my files, even on msvc
we have to document this somewhere later, in README_win32.pod probably 20:10
kj i think .pmc files need to be considered as well
not only .c files
rurban yes
*. files also
kj I just got the same error, but now for a .pmc file
rurban too fast: *.h files
yes, the string extractor needs the exact line number
kj *.* should do it 20:11
rurban pbc's probably not, hopefully they are skipped
allison shudders at hardcoded paths in generated perl scripts 20:12
rurban its my private script!
rurban things she meant something else probably 20:13
20:13 mberends joined
allison rurban: meant dynoplibs.pl 20:16
rurban yep, @build_dir@ 20:17
kj rurban: ok, seems my cygwin build problems was indeed due to eol style 20:18
(building now..)
allison rurban: yup, it's gotta go 20:19
20:20 rurban_ joined
allison kj: I only had one failing test on 'make fulltest'. try running 'realclean' and starting over again 20:20
kj allison: what defines 'failing'? if it says: not ok 13 # TODO escape_string: non-ascii 20:21
is that a failure?
allison TODO tests aren't failures
rurban_ no,
allison (they're expected failures)
rurban_ no failure
kj ok, so a failure is only if you see the panic-like output with 'expected xxx'
allison kj: if it isn't reported in the summary at the end, then it's not a failure
kj ok, haven't come to that point yet
allison kj: must be running on a slow linux box 20:22
rurban_ do have prove? if not use perl t/harness <path-to-t>/*.t
kj no not at all; it's moritz' box, it's extremely fast
rurban_ or just make test
kj way faster than my hardware
allison kj: hmmm... but I just ran a complete 'make fulltest', in far less time 20:23
kj allison: perhaps its because it's a putty session?
rurban allison: we should note down that the string extractor and ops/pmc parsre are not crlf safe. maybe I can fix this.
allison kj: could be, just a delay in the I/O
kj allison: but it does seem very slow; maybe there's some orphan processes or something that's slugging up the box 20:24
rurban++ # cygwin builds cleanly, thanks for help
rurban: perhaps upgrading cygwin wasn't even necessary, but was it the crlf thing all along. 20:26
rurban most likely. but I can reproduce this and come up with a fix. but not this night! tommorrow 20:27
kj a fix in the regexp?
rurban yes
kj ah that'd be very nice
rurban ha, I found the imcc crash with the icc build! 20:28
./miniparrot -v -D88 -d88 -t config_lib.pasm is the trick
kj where's it crashing on? 20:29
rurban at the beginning of the parsing 20:30
TT #332
kj and only when -t is on?
rurban but only with icc
no, all the time
kj ooh
so compiler bug?
rurban parser bug
most likely a icc setting which is missing 20:31
we will see soon
kj (cygwin) ok, this is very nice. I think release can be done on cygwin then
at least i have local access to stuff. 20:32
rurban bash is bash. nothing can beat it
kj mmm pirc doesn't build on cygwin; 20:35
20:36 gravity joined
rurban the only random cygwin eror is t/library/pg 13 20:36
20:38 cognominal joined
kj include/parrot/oplib/ops.h is missing on my cygwin 20:38
rurban I think this is created. make reconfig 20:39
kj rurban: what is make reconfig supposed to do? (oplib/ops.h isn't created) 20:44
rurban make reconfig is a shortcut for make realclean; perl Configure.pl <your args> 20:45
kj oh ok
rurban because of yourcrlf mess before the ops headers and c files were not created. so start afresh 20:46
kj I'll just get a fresh wc using cygwins svn, if that works
rurban sure, that's the best :)
but for sure the slowest of all 20:47
kj yeah, especially on a hspda wireless connection :-(
kj is looking forward to the internet connection of the future 20:48
Whiteknight I can't wait for this release to be over, I have so many changes and optimizations to make in the calling conventions that it's almost frightening 20:57
kj Whiteknight: you're just waiting to merge?
rurban until monday, or later?
Whiteknight no, I'm not ready to merge this branch yet
particle Whiteknight: that frightens me, that there's "so many" changes going in before 1.0 20:58
Whiteknight but I haven't done any major optimizations in the branch either
kj well, then no need to wait for the release then :-)
Whiteknight particle: I can always wait, but there is a lot of fertile ground here for making things smoother and faster
particle my target for 1.0 isn't either of those, it's "more stable and better documented" 20:59
kj (more stable)++
rurban a sound API 21:00
Whiteknight then I can wait to make major changes until after 1.0
rurban internal optimizations for sure
Whiteknight although a lot of people have been complaining about performance lately, and the biggest performance bottleneck right now is the calling conventions system
kj Whiteknight: I'd rather have performance issues than segfaults :-) 21:01
rurban well, then hurry on :)
Whiteknight kj: I've found the rest of my segfault issues, and I should be putting a fix for them through in a few minutes
kj oh I didn't even know you had segfault issues
particle rurban: i don't understand why -0.0 is still todo, it passes on win32 for me.
Whiteknight I intend to cut out a lot of code, especially old code that's riddled with errors
kj: I had a few of them in my branch, but I think I've got them all figured out now 21:02
rurban it depends on your msvcrt.dll
I have 4 systems, only on one it fails now
particle and that one is msvc6, which isn't officially supported.
rurban We can improve the test checking the new has_negative_zero 21:03
particle i'd rather have the test pass by default and fail on an unsupported platform, than be a bonus test on the other three
ok, good.
rurban it's not dependent on the compiler, its a libc issue
Whiteknight The calling conventions are definitely getting unified post-tuesday, and once that happens it's optimization city 21:04
rurban i wanted to test openbsd also today, but openbsd is mor broken than I tought. impossible to build shared
dalek rrot: r36735 | whiteknight++ | branches/rename_pccinvoke/src:
[rename_pccinvoke] finally make the conversion in src/api/io.c. temporary pmcs in Parrot_invoke_from_sig_obj were getting clobbered when we mixed recurssive PCC invokes and a GC run. Turning them into regular PMCs resolves this issue and everything goes smoothly
kj Whiteknight: what kind of unifications are coming?
Whiteknight kj: Unifying the various calling conventions. We've got about two dozen functions for invoking a PIR subroutine from C, and those are getting reduced down to about 2 or 3 with common logic 21:07
kj Whiteknight: I see. 21:08
Whiteknight: it would be nice if there would come some more replies on your self-proposal
Whiteknight Yeah, I was hoping more people would have an opinion about that one
kj ..meaning before Tuesday
Whiteknight once I'm done this current branch, I'm going to create another branch for that purpose and see if people like the result 21:09
kj because any decision for deprecation (of $P0.$P0() syntax) can then be made
Whiteknight I guess it's just waiting till post-1.0
kj yes it's not critical 21:10
rurban how else does icc? 21:13
not how, who else 21:15
kj rurban: I was trying to figure out what you were meaning :-)
Whiteknight: seems you got another reply on self :-) 21:28
dalek rrot: r36736 | particle++ | trunk/t/pmc:
[t] todo tests only on platforms that don't have negative zero support
 21:41
21:59 japhb joined 22:32 ask_ joined
dalek rrot: r36737 | particle++ | trunk/t:
[t] unskip some passing tests on win32
 22:39
22:45 HG` joined, HG` left, rdice joined
rurban ha, idb is broken, gdb works just fine on icc objects. and gdb --tui is even better! TT#332 22:57
23:03 eternaleye joined
nopaste "Infinoid" at 96.238.213.50 pasted "Warnings on x86-64 linux from src/packfile/pf_items.c" (7 lines) at nopaste.snit.ch/15623 23:06
Infinoid We could fix those by replacing the constant expressions with #if blocks 23:07
rurban I wanted to keep it short and make the logic obvious. the compiler shortcuts it anyway 23:08
we have always foreign <=> our pairs where ours is constant 23:09
and when 32-byte doubles will come it will be much shorter 23:10
of course we could flip it our <=> foreign, so the tha shortcut is really a shortcut optimizable by the compiler 23:11
but it's only called once
wait a sec, wrong precedence? 23:12
nopaste "infinoid" at 96.238.213.50 pasted "[PATCH] Maybe something like this?" (42 lines) at nopaste.snit.ch/15624 23:13
Infinoid you could keep the ifelse chains I suppose, but this seems a bit clearer to me.
rurban can you paste the new code only? or diff -c
but I see what you mean. A bit like duffs device 23:14
Infinoid k, one moment
you're right, the diff isn't very readable
nopaste "Infinoid" at 96.238.213.50 pasted "code block" (33 lines) at nopaste.snit.ch/15625 23:15
rurban and you took the shortesz section, where there is no native 12-byte section
Infinoid Oh, I have no idea whether my version is right, I was just wondering what you thought of this kind of code logic 23:16
Also, it fixes the warnings for me.
rurban looks also okay, I don't care. I think yours is clearer in the precedence. I thought in pairs, but this is also okay. 23:17
please apply if you care
and thanks! Infinoid++. but the (args) stuff broke the build :) 23:18
Infinoid Yeah, macro parameters are a pain
(though it built fine here... do I have to enable something to build that stuff?)
rurban it's a very old trick I use with DEBUG_PRINTF((list))
Infinoid So do you think my patch broke anything? (I'm not familiar with the usurrounding code at all, is checking nullness of pf->fetch_nv valid?) 23:19
rurban sure, TRACE_PACKFILE = 2 or such in the header
I use it to debug the reader, but I didn't want to pollute normal builds with all this debugging stuff 23:20
Infinoid makes sense
rurban but parrot should not print it either
only one of the tools, pbc_dump usually
I have to debug 64-bit alignment, which I suppose is wrong when dumped, but native 64-64 gets it right 23:21
very strange
Infinoid let me know if there's anything I can help test (but I think x86-64 is more forgiving with alignment than some other 64-bit platforms are) 23:22
rurban the aligned ptrs on 64bit are not aligned at all. ALIGN_16 is just a dummy on 64-bit
Infinoid rule of thumb: if you can make it work on ia64, you can make it work *anywhere* 23:23
rurban I have no idea why it works though.
Infinoid hmm
rurban I'll study the tracings when I have mor time
Infinoid ok
rurban btw. did you see #332 ? 23:25
maybe another init problem. or the data segments are at the wrong place. 23:26
the icc linker
Infinoid oh, that sounds like fun. I'll look now
rurban and forget about idb, this is broken at all. gdb works fine though. and statis is easier to debug than shared. same problem
purl rurban, I didn't have anything matching about idb, this is broken at all. gdb works fine though. and statis is easier to debug than shared. same problem 23:27
23:27 TiMBuS joined
rurban I guess the problem is 32-bit only. 23:28
Infinoid that means I might be able to test it if I can get icc to build in 32 bit mode
(I only have icc on a 64-bit box)
rurban it woudl be interesting if somthing broke icc at all, or just 32 bit, or I broke something 23:29
gui --tui btw is wonderful! never knew that 23:30
Infinoid zsh: command not found: gui
rurban sorry, gdb --tui of course 23:31
its the gdb gui (source browser)
Infinoid oh, that does look nice. not mentioned in the manpage either
rurban a bit like emacs M-x gdb
rg rurban: which test were you trying to run on openbsd? 23:32
Infinoid having to follow along in a source editor has always been one of my biggest time sinks with gdb...
rurban I wanted compile to parrot
the very first miniparrot call fails
rg you might want to try a more recent openbsd. i've just installed 4.4 in a vm and it works fine 23:33
rurban rg: thanks. 3.8 is very old indeed.
pushing the limits 23:34
rg we might want to update the hints file for the shared library, though 23:35
rurban rg: can you check t/pmc/float.t on openbsd? make smoke would be fine
sure. shared is hard to get right
rg i've just copied over the freebsd settings and it built fine
it's currently running tests 23:36
i'll nopaste the diff if it works
rurban particle just changed the test logic there
theoretically it should pass 100%
rg i'll check in a couple minutes. the vm isn't that fast ;) 23:39
rurban for me the bsd/linux vm's are at least 3x faster than windows
cygwin is super-slow 23:40
rg is trying to avoid windows wherever possible ;) 23:42
rurban is avoiding macintosh wherever possible :)
lu_zero should avoid computers wherever is possible =P 23:43
rurban I'll sleep now, bye
Infinoid, info gdb has the needed keys for TUI 23:45
rg i've already had r36736 and it's all fine. 23:54

Powered by Cro and the Raku® Programming Language.

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

Thank you!