Parrot 0.9.0 | parrot.org/ | 468 RTs remain
Set by moderator on 11 February 2009.
NotFound I think I understood before that that will not be deprecated. 00:00
allison Tene: on the whole, we don't want the "don't catch exceptions thrown from the EH" behavior
Tene nods.
rg uhm. regarding tene's example for me: shouldn't that sub be a different scope? if i throw a new exception in there, i still get the recursion :( 00:04
Tene rg: That's right. That's why you just don't catch exception types you don't want. 00:05
Or rethrow them.
Or filter on severity
rg that doesn't work for HLLs
dalek rrot: r36609 | whiteknight++ | branches/rename_pccinvoke/src:
[rename_pccinvoke] update the calls in src/oo.c. Fix a weird place where a pointer to a PMC pointer was getting marked before it was instantiated. Don't know why this error didn't manifest with Parrot_PCCINVOKE, but whatever
Tene No?
jonathan The Belgian Perl Workshop has a drinking game on the schedule. This sounds good! :-)
rg no. for one, most HLLs don't have rethrow.
dalek rrot: r36610 | allison++ | branches/pcc4:
Removing calling conventions refactor branch from the repository
rg you just throw the exception you just handled again to pass it to the next handler 00:07
Tene rg: that doesn't work in Parrot?
i thought it did.
NotFound I think that using that way you have not a proper context, you're just faking the address of the opcode pointer. 00:08
rg nope, doesn't work. take your example and replace r() with throw ex 00:09
00:09 AndyA joined
Tene nods. 00:09
dalek rrot: r36611 | allison++ | branches/pcc5:
Creating branch for refactoring calling conventions, removing the old PCCINVOKE and streamlining the rest.
Tene Generaly, you generate code to do the rethrow. 00:10
rg i don't think that will work. 00:12
also, i think rethrow should ignore the handler in a backtrace like it was never called, whereas a new throw will get listed. 00:13
Tene Yes. That's a bug. Nobody has fixed it yet. 00:14
00:14 Limbic_Region joined
rg we need to get exceptions working first anyway 00:15
with working i mean in a way that doesn't give everyone a headache ;) 00:16
allison?
purl well, allison is Allison Randal <mailto:allison@perl.org>
rg the way allison explained it, i would have expected that the sub handler in your example is in a different context. did i get that wrong or how did you understand that? 00:19
dalek rrot: r36612 | whiteknight++ | branches/rename_pccinvoke/src:
[rename_pccinvoke] update src/scheduler.c, and make sure to initialize a few variables in src/oo.c
00:20
Whiteknight this branch is going swimmingly 00:23
...of course as soon as I say that I start getting test failures 00:25
Infinoid Whiteknight: that'll teach ya 00:27
Whiteknight and of course, the test that fails is too rediculously complex to debug reasonably 00:28
allison rg: yes? 00:29
Whiteknight allison: I think I may have finally found the cause of that t/compilers/pct/complete_workflow.t test error we got last time 00:32
rg allison: can you look at tene's example in nopaste.snit.ch/15589 and tell me if sub handler should have sufficiently different scope? 00:33
Tene rg: it's a nested scope.
rg how is that nested? it's not marked :outer or anything 00:34
Tene exception handling looks at the call chain
just like when you call a sub
allison rg: a sufficiently different scope for what? 00:36
Whiteknight: okay, good
Whiteknight I GOT IT!
fixed the error! smooth sailin from here!
Tene He's still trying to get his exceptions thrown from an EH to ignore the EH, without using either rethrow or filtering.
rg to not have itself as an exception handler 00:37
Whiteknight I don't know why it's an error here and not with Parrot_PCCINVOKE, but I fixed it anyway. understanding is overrated
dalek rrot: r36613 | whiteknight++ | branches/rename_pccinvoke/src:
[rename_pccinvoke] fix the test failure that was blocking my work months ago, and convert src/debug.c
00:38
allison rg: why? 00:42
rg you said in response to me asking about try { throw a; } catch { throw b; }: "rg: that's all about scope". "rg: parrot doesn't currently support scopes smaller than a .sub". so either it needs a scope smaller than sub to work, or there is a way that i can't figure out. 00:43
our of course i completely misunderstood that ;)
s/our/or
allison rg: any exception handler will be in the dynamic scope of the place where the exception was thrown
rg: and so will have the exception handler chain of that scope in its own exception handler chain 00:44
making the handler a separate sub doesn't change the dynamic scope where it was thrown
Limbic_Region pmichaud ping 00:45
Tene That's necessary so that the handler has access to the dynamic scope where the error occurred. 00:46
allison rg: that is, for the purposes of execution of scope, what you actually have is try { throw a; catch {throw b;} }, no matter what the high-level syntactic sugar is surrounding it 00:47
rg now that looks a lot like the perl6 syntax. i was thinking more of java/javascript syntax, where the catch block does not catch its own exceptions. 00:49
Tene rg: that's what parrot exception handlers are 00:51
If you want it to behave differently, you'll have to build your own construct. 00:52
Whiteknight allison: I have a question for you. In Parrot_io_open, what happens when "mode" is NULL? 00:54
allison Whiteknight: it treats it as if mode were 'r', that is read-only
Whiteknight the parameter list has it declared as ARGMOD_NULLOK, and eventually it gets passed to Parrot_str_set which is declared as ARGIN (not NULLOK) 00:55
allison (read-only is the default
Whiteknight okay, thanks
this conversion process seems to be uncovering a number of errors that Parrot_PCCINVOKE seems to have been covering up or glossing over 00:56
allison Whiteknight: that's a good thing, overall :)
rg tene: i don't think i do, but if you're not interested in supporting other languages that's fine with me.
allison rg: if you can define the exact semantics for java, we'll support them, but it's more than just "doesn't catch exceptions for itself" 00:57
Tene rg: I didn't mean you specifically. I just meant that if someone wants an exception handler not in the dynamic scope of the error, that doesn't exist in Parrot right now.
allison rg: I expect Java is using exception handlers on static scope lines, rather than dynamic scope
rg: which would mean generating different code 00:58
rg: (still possible, but static features are not Parrot's default) 00:59
jonathan rg: I suspect Java's expection handlers etc are along the lines of those in .Net. I've made that work in Parrot before now. 01:00
Whiteknight do we have an equivalent of PMCNULL for strings?
jonathan rg: It was a non-trivial transformation, but seemed to work.
Whiteknight like a STRINGNULL or something?
jonathan Whiteknight: No. It's...well...NULL. :-|
Whiteknight: Which is (OMG SURPRISE) a source of segfaults.
Whiteknight yeah, I'm getting segfaults in src/pmc/cpointer.pmc:mark 01:01
which, as one might expect, is a very dangerous piece of code
jonathan rg: www.jnthn.net/papers/2006-cam-net2p...tation.pdf - I likely scribbled something about it in there...
shorten jonathan's url is at xrl.us/ty3j
rg it may well be considered static scope. is javascript considered static scope aswell?
jonathan -> sleep 01:02
dalek rrot: r36614 | allison++ | failed to fetch changeset:
[load_language] Adding the load_language opcode, with supporting library changes.
allison rg: static scope is the scope of the block structure as defined in the source code. dynamic scope is the scope of execution. All languages have both, some use one more than the other. 01:04
rg ok, then i guess that's all static scope. i'll check jonathans work and paper and see what he did :) 01:05
allison rg: javascript likely is using static scoping for exceptions (since it was inspired, in part by Java/C)
Whiteknight I always thought javascript was more similar to perl in many respects then to java or c 01:07
put sigils on the variables, and s/function/sub/, it's very cose 01:08
and both have lousy object systems :)
rg whiteknight: but perl doesn't have much in the sense of exception handling, so you can't compare them in that respect ;) 01:09
perl being perl5 here
NotFound I think in javascript static scope even doesn't exist 01:10
rg: in tene's example there is not a different scope, you have not entered the sub, you just faked the opcode address 01:12
rg i wonder, if you don't have continuations, how much difference is there between static and dynamic scope?
allison rg: continuations don't make any difference 01:13
rg; static scope is static scope and dynamic scope is dynamic scope
rg: en.wikipedia.org/wiki/Scope_(progra...ic_scoping 01:14
shorten allison's url is at xrl.us/pw8v
rg yes, i'm already reading that ;)
allison afk, finding food 01:18
Whiteknight my firefox is borked 01:21
I updated it, restarted it, borked
rg on windows? 01:23
(not that i'm any good with windows, but) iirc i needed to kill firefox hard (in process manager) and try the update twice, then it worked. i attributed it to general windows instability ;) 01:25
Whiteknight nope, I'm on Ubuntu 01:31
rg sorry, i don't have that at all 01:33
01:54 bacek_ joined
Whiteknight absolutely hates cpointers 01:55
these things are evil
bacek_ rakudo: my $a = 41; $a++; say $a 01:56
polyglotbot OUTPUT[42␤]
mikehh Whiteknight: I upgraded earlier but on Kubuntu - mine's ok 01:57
I have been using a fress installation of Kubuntu Intrepid for the last couple of days 01:59
I have separate root partitions for Ubuntu 1386 and AMD64 and Kubuntu AMD64 but haven't switched recently 02:00
same /home partition 02:01
different user names but all accessible to each other 02:03
Whiteknight i may just have to restart the computer. I think there were some libc6 updates in the group too 02:07
make test is giving me failures that I absolutely cannot reproduce any other way 02:10
mikehh I got some earlier but when I tried again I could'nt reproduce - from perl Configure.pl --optimize --test 02:12
02:16 japhb joined
dalek rrot: r36615 | whiteknight++ | branches/rename_pccinvoke/src:
[rename_pccinvoke] update src/io/api.c nd a few other files that need to be fixed to make this work. 3 weird test failures that I'm having trouble reproducing outside of make test. will debug tomorrow
02:16
Whiteknight and on that note, goodnight! 02:17
Infinoid All right! We've got 5 days ± some before the release, and I've got a burrito and some spare tuits. Who wants some? 02:26
(Victim here, victim here!)
mikehh depends what is needed? 02:30
Infinoid That's what I'm asking.
02:31 s1n joined
mikehh I have some time acailable - can do testing and probablt ok on doc stuff - not so sure about pir and that sort of thing 02:32
available
Infinoid I've got some spare time too
Infinoid cleans up some tickets 02:41
02:47 mib_bchlgo joined
jimmy hey, galf. 02:49
Infinoid oi, jimmy 02:57
happy Thursday
jimmy Good morning, Infinoid. 03:05
dalek Duzy Chan | Parrot: 03:12
link: www.perlfoundation.org/parrot/index.cgi?parrot
03:12 ron joined 03:24 leto_ joined
ron Anyone available for suggestions on an mmd problem with a vtable override seeming to confuse the return context? 03:25
03:32 ask joined
Infinoid ron: I'm not an mmd expert, but more details couldn't hurt 03:36
ron I am doing an a vtable override of the init function in a class. Then I do a call to the sub operator which is mmd and sets up a context for a return value. When sub (subtract) allocates a result pmc it calls the overriden init function and as a side effect clears the results_signature. Question to follow in a moment ... 03:43
btw - the final symptom is a core dump 03:44
Infinoid is this a PIR subclass overriding the init function from a PMC, by any chance?
ron yes 03:45
Infinoid all MMD issues aside, I think there's an open trouble ticket for that, one moment
ron I looked for vtable on rt and didn't find it - do you have a better idea how to look it up? 03:46
Infinoid yeah. we actually have two ticketing systems at the moment, RT is the old one. trac.parrot.org is the new one, we're slowly migrating stuff over 03:47
03:48 janus joined 03:49 tetragon joined
Infinoid there are a few tickets related to PIR subclasses of PMCs generally. trac.parrot.org/parrot/ticket/299 is one of them 03:49
TT #218 and #203 are a couple of others 03:50
I'd love to look at a backtrace, if you have one 03:53
(a test script would also work)
ron bear with me a moment - trac-299 doesn't seem to fit but am doing some other double checking ... 03:54
Infinoid no problem. this isn't my area of expertise, I don't really understand all the issues involved, so I might be spitting bogons here 03:57
nopaste "ron" at 200.67.68.192 pasted "test for vtable core dump" (23 lines) at nopaste.snit.ch/15593 04:21
Infinoid nice crash! 04:22
something obviously wrong there. 04:23
608 sig_pmc = ctx->constants[*pc]->u.key;
*pc is 140733315992448, which doesn't look like a valid array index to me
nopaste "ron" at 200.67.68.192 pasted "backtrace from test for vtable core dump" (44 lines) at nopaste.snit.ch/15594 04:24
"Infinoid" at 75.28.75.73 pasted "Here's the same backtrace on linux/x86-64, with debugging symbols enabled." (41 lines) at nopaste.snit.ch/15595 04:26
04:28 ron left 04:36 particle joined 04:55 tetragon joined 05:11 elmex joined 05:39 jimmy left 05:40 TonyC joined
dalek rrot: r36616 | cotto++ | trunk:
[gc] update names of DOD_RUNS and LAZY_DOD_RUNS and some comments
05:57
rrot: r36617 | cotto++ | trunk:
[gc] rename DOD_block_level to gc_mark_block_level and GC_block_level to gc_sweep_block_level
06:11
cotto Is "sweep" or "collect" a better term for the part of GC where memory gets freed for reuse? 06:36
06:37 leto_ joined
cotto "collect" seems to be more common, so I guess I'll go with that. 06:40
06:42 alvar joined 06:51 alinbsp joined
dalek rrot: r36618 | cotto++ | trunk/docs:
[gc] replace most references to "DOD" in the docs
06:59
07:05 uniejo joined 07:33 alvar joined 07:42 iblechbot joined 07:47 alinbsp joined
dalek rrot: r36619 | cotto++ | trunk:
[gc] various variable, member and macro name changes to get rid of "DOD"
07:59
cotto The bird is wacky atm. I'm getting periodic build failures with the message "argument doesn't hash". 08:00
make reconfig seems to make the build work temporarily 08:01
I also saw a phantom failure in t/op/string_mem.t 08:02
08:02 ask joined 08:24 mj41 joined 08:32 iblechbot joined 08:33 TiMBuS joined 08:35 leto_ joined 08:36 mberends joined 08:55 masak joined 09:57 dalek joined 10:07 kj joined 10:24 iblechbot joined
Coke grumbles at a work mixup that has him in the office 3 hours early with nothing special to do. 10:28
cotto when's three hours early? 10:51
dalek rrot: r36620 | fperrad++ | trunk/compilers/tge/tgc.pir:
[TGE] fix load_bytecode in install tree
11:04
rrot: r36621 | fperrad++ | trunk/languages/pynie/TODO:
[codingstd] fix SVN properties
11:19
rrot: r36622 | fperrad++ | trunk/src/inter_create.c:
[codingstd] remove trailing space
rrot: r36623 | cotto++ | trunk/src/ops:
[gc] more DOD removals in docs/comments
11:22
rrot: r36624 | cotto++ | trunk/t:
[gc] remove most DOD references in tests
11:26
masak make failure when making Parrot: gist.github.com/62587 11:27
PGE dies with the error 'argument doesn't hash' 11:29
dalek rrot: r36625 | cotto++ | trunk/src/pmc:
[gc] remove/replace DOD references in core PMCs
11:30
rrot: r36626 | cotto++ | trunk/include/parrot:
[gc] remove/replace all DOD refs in headers (comment changes only)
11:36
rrot: r36627 | kjs++ | failed to fetch changeset:
[pirc] remove deprecated .HLL_map directive and all supporting code.
11:40
rrot: r36628 | cotto++ | trunk/src/gc:
[gc] remove most references to DOD in the GC code (comment-only changes)
11:50
cotto masak, that's an ugly one. I don't know what causes it, but make reconfig && make seems to succeed. 11:51
masak cotto: trying. 11:52
cotto: getting a different error now. 12:00
'../../parrot: error while loading shared libraries: libparrot.so.0.9.0: cannot open shared object file: No such file or directory'
cotto I didn't see that one. 12:02
particle parrot build broken on win32 also 12:16
..\\..\\parrot.exe ..\\..\\runtime\\parrot\\library\\PGE\\Perl6Grammar.pir --output=PGE\\builtins_gen.pir PGE\\builtins.pg
argument doesn't hash
masak and on feather. trac.parrot.org/parrot/ticket/261
masak notices the new patch and tries it on 12:17
particle i'm glad it's the same behavior on both platforms.
r36628 doesn't build here 12:18
dalek rrot: r36629 | cotto++ | trunk/src:
[gc] replace/remove "DOD" in comments in most files in src/
12:19
particle rebuilds with doughera++'s patch
cotto particle, that appears to be an intermittent build failure 12:20
particle unacceptable! 12:21
cotto sometimes it works, sometimes not
btw, are you still in Seattle? It's kinda early/late to be up.
particle well, it's failing on multiple platforms now, days before a release
yep, i'm in seattle
yes, it's early.
masak which one is it, 'perl Configure.pl' or 'perl Makefile.PL' ?
particle doesn't matter 12:22
the latter calls the former
Makefile.PL is there for CPAN
masak ok. sometimes I'm told it matters.
but maybe others have also been confused by intermittent failures.
particle we may remove Makefile.PL since we're not distributing to cpan anymore 12:23
cotto particle, the "doesn't hash" problem it may just be some stale code that make doesn't know to remove.
particle doesn't hash comes from a check of does() somewhere 12:24
cotto now that I think about it, I didn't see it after running make clean
masak hates URLs which look like they lead to the raw form of a file, but serve a HTML version
particle cotto: if the patch doughera attached is accurate, you need to reconfig, so realclean
cotto there's only one place where that warning exists: src/call/pcc.c:676 12:25
which tt?
purl which tt is, like, it
masak 261.
cotto no, tt is <reply>
purl okay, cotto.
particle i'm rebuilding, but nmake-- only lets me build with one core, and 1.86GHz isn't fast anymore :( 12:26
cotto neither is 1.66 12:29
dalek rrot: r36630 | cotto++ | trunk/languages/dotnet/pmc:
[gc] update comments with "DOD" in dotnet
rrot: r36631 | cotto++ | trunk/languages/PIR/src/pasm/pasm_core.pg:
[gc] remove reference to DOD
12:30
particle it built with the patch! 12:31
particle commits
masak no such luck here...
but I will try with a clean checkout also.
12:31 rg1 joined
particle does feather use jit? 12:31
masak knows not 12:32
the error happens in PGE, and says "argument doesn't hash"
particle hrmm, the patch isn't related to windows build failures, it seems
masak so, in summary, the patch didn't work, and things are still broken on feather? :/ 12:44
we have November running there, so we're fairly keen on seeing this fixed.
12:46 mberends joined
dalek rrot: r36632 | cotto++ | trunk:
[gc] various changes to remove/replace DOD in comments and macros
12:47
particle yeah, lemme see if i can log in to feather 12:49
'telnet' is not recognized as an internal or external command, operable program or batch file. 12:50
uggh.
cotto particle, ping 12:51
particle i'm right here!
cotto can you check if sleep works on win32/mingw? 12:52
particle in pir?
cotto (in pir, like in #53458)
particle sleep has 1s resolution on win32
so sleep 2 may sleep 2.999s
cotto but shouldn't sleep 1 sleep for non-zero time? 12:53
particle yes, it should
cotto does it?
particle isn't there tests for that? 12:55
masak: where is the broken parrot build on feather? 12:56
12:56 tetragon joined
particle cotto: i'm updating and rebuilding parrot with strawberry perl now 12:59
cotto: it does sleep with msvc 13:01
masak particle: not sure the is one 'the', but they all fail. 13:04
particle ok, looking for one at head
whichever is used for p6eval
masak p6eval is not on feather, it's on timtowtdi.org
particle ah 13:05
13:05 gaz joined 13:28 Whiteknight joined
Whiteknight hates piper 13:28
rg you're channel op, you can always kick and/or ban it ;) 13:29
Whiteknight don't tempt me 13:37
rg something else then: ch03_pir_basics.pod around line 994: Unterminated C<...> sequence 13:38
dalek rrot: r36633 | fperrad++ | trunk/config/gen/makefiles/root.in:
add a target 'pirc'
13:39
rrot: r36634 | fperrad++ | trunk:
[install] add pirc
13:40
13:44 gryphon joined
Infinoid masak: I saw an "argument doesn't hash" build failure lastnight on my laptop, it had something to do with VTABLE_does("hash") returning false on a Hash PMC, but it went away after a realclean 14:22
it was weird.
masak mine doesn't go away after a realclean.
Infinoid well, I guess I'm seeing it intermittantly then 14:23
masak if you want to have it consistently, try and build on feather :/ 14:24
Infinoid it occurs for you while trying to build PGE, right?
masak aye.
Infinoid strange... I got the error trying to build TGE
masak ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg 14:25
make[1]: *** [PGE.pbc] Segmentation fault 14:26
from a clean checkout.
particle Infinoid: that's not so strange, they both use some of the same code to build 14:28
could be an anchoring problem 14:29
maybe it's an attribute hash pmc that disappears before its time
--gc-debug might help it appear regularly... 14:30
masak particle: as an argument to what? 'make' ? 14:31
particle cd compilers/pge
../../parrot --gc-debug ...
hrmm, i'm getting it with tge now, not pge 14:32
Infinoid since it's consistent on feather, has anyone bisected it there? 14:33
particle no, haven't done that, was going the gdb route
i can't replicate it on windows with --gc-debug :( 14:35
masak bisects on feather 14:40
14:47 ron joined
Infinoid ron: Hi, I created trac.parrot.org/parrot/ticket/321 for your issue last night 14:48
14:49 slavorg joined 14:50 gryphon joined
ron Thanks, I saw it - I may add some comments about the return from an mmd call checking the context results_signature and then overwriting it later. 14:52
Infinoid please do
15:07 rg joined
masak svn.parrot.org is down. 15:11
...and back. 15:12
particle somebody burped 15:15
PerlJam It was a network burp I think as I lost contact with feather around the same time. 15:19
masak r36175 builds on feather, r36176 fails. 15:24
and lo and behold, so says trac.parrot.org/parrot/ticket/261
I'm glad we agree on that. :)
particle trac.parrot.org/parrot/log/trunk?rev=36176 15:26
it's a big one :(
masak quite an ambitious commit.
oh well, some people like 'em big. 15:27
Infinoid did Andy D's patch (attached to #261) have any effect? 15:35
(someone should probably respond to it, either way.) 15:37
particle i'm trying that patch on feather now 15:40
this has been a painful month for parrot stability 15:42
nope, doesn't fix
necessary, but not sufficient
argument doesn't hash
i wonder if .sub 'register' :method in P6object.pir should have the options param be :optional too 15:45
no, likely not 15:46
15:52 szabgab joined
Infinoid well, if it's necessary, I'll try grepping for other cases needing fixing 16:03
(painful month) not really surprising, given how many things are on the roadmap this month. next month will be more of the same 16:04
wait. does it segfault (as reported by #261), or does it throw an "argument doesn't hash" exception and not segfault? 16:09
particle ah, after the patch i'm seeing argument doesn't hash 16:11
which is better, indeed
Infinoid sounds like progress 16:16
purl rumour has it sounds like progress is being made on the latter, though
mberends urghh, parrot r36634 doesn't build on linux-amd64. /usr/bin/perl -e "" >PGE/builtins_gen.pir 16:20
../../parrot -o PGE.pbc --output-pbc PGE.pir
../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg
argument doesn't hash
16:21 rurban joined
mberends same as Infinoid etc 2 hours ago 16:22
Infinoid I hit that last night... haven't been able to reproduce it since though 16:23
a few realcleans later everything worked
rurban I have a major win32 linking cleanup for particle to review 16:24
particle rurban: hit me with the patch
mberends r36632 was fine here, realclean has not helped. a few?
rurban will do. I try it first on my linux machines, now that i arrived at home
Infinoid yeah, realclean, build, argument doesn't hash. realclean, build, argument doesn't hash. realclean, build, argument doesn't hash. realclean, build, all tests successful
rurban Finally it's cleaned up, but there's still work to do for make install 16:25
Infinoid mberends: the only reason I tried it so many times was that I was building in a tree I *know* used to work, so I was wondering if I had some local changes somewhere
rurban particle: trac.parrot.org/parrot/ticket/312 16:26
mberends okay, I'll just realclean once again as usual ;) 16:28
particle infinoid: argument doesn't hold water, either :/ 16:29
mberends particle: but water realcleans 16:34
argument doesn't hold water or hash either after svn up --revision 36632 :( 16:37
meaning realclean is not clean enough, probably 16:38
rurban it is
svn revert-R . might help 16:39
svn revert -R .
mberends will try that, thanks
rurban this reverts all local modifications, cleans all svn status M files 16:40
Infinoid not in my experience, I had no local patches when I was getting that error
Coke_afk particle: you can use mingw32-make if you have it installed. that allows -j2 16:51
rurban dmake is also parallel
purl okay, rurban.
Whiteknight dmake?
purl dmake is, like, a borland thing or at search.cpan.org/dist/dmake/ or <reply>it's just like make, except it's totally gay or parallel
Whiteknight HA! 16:52
rurban solaris also favors dmake
mberends rurban, Infinoid: 'svn revert -R' did not help. 'rm -rf parrot' did. Sorry, old joke. Life's too short to worry about little annoyances when they can be avoided. 16:57
rurban And my machine rebooted during the day and now my solaris vm does not boot anymore... 16:58
mberends which vm environment?
rurban vmware on xp: failed to get ramdisk from boot. nice grub message 17:00
mberends maybe host os has less free ram after reboot, some other process grew. 17:01
Windows_Update-- for example 17:02
rurban Not really, clean reboot when I arrived. I' ll just test without 64bit
All the other vm's do work fine.
But I did a nasty rm -rf /usr/X11R6/bin 17:03
moritz not so nasty if you use x.org ;-)
mberends you may be able to use another runlevel for text-only on Solaris 17:04
moritz can I disable the MANIFEST check during configure somehow?
there's no need to perform that step on this particular machine, and it takes tons of time 17:05
particle perl Configure.pl --nomanicheck
moritz particle: thanks 17:06
17:06 Theory joined
rurban mberends: sure. grub command-line mode. But I'll rather fix my win32 specifics for the other platforms now 17:07
mberends good idea
purl mberends: Good Idea: Singing Christmas carols to your neighbors. Bad Idea: Singing Christmas carols to your neighbors on the Fourth of July.
rurban aah, solaris is up now in text-mode. it just needs 10times longer than any other os, including windows xp 17:08
mberends strange, Solaris LiveCD natively boots faster than Ubuntu 17:10
rurban ubuntu is also a god, yes 17:11
purl okay, rurban.
rurban a dog
mberends rurban, give VirtualBox a try. From The People Who Brought You Solaris. 17:13
rurban not another vm sw, one is enough.
particle: trac.parrot.org/parrot/attachment/...ng.2.patch is better 17:14
shorten rurban's url is at xrl.us/befzbq
jsut|work my($e,$c);print "$e $c \\r"while($c=1234567890-($e=time.int))>=0 17:17
rurban -g3 produces a huge lib, but I don't get at the macros like NREG(1) 17:18
anyone has a nice .gdbinit ?
nopaste "rurban" at 212.183.55.23 pasted "my current .gdbinit. my gdb does not grok macro" (68 lines) at nopaste.snit.ch/15599 17:19
Coke if there is a gdbinit worth checking into the repository, that would be nifty. 17:26
rurban "worth"
Coke (tools/dev/gdbinit or something)
well, is yours worth more than <NULL> ? 17:27
=-)
rurban depends fully on how good your gdb is. my mingw and cygwin gdb is awful. on solaris I even have only dbx, which is the worst crap
If I would have a working gdb with --gdb3 and macros then I wouldn't need that .gdbinit alltogether 17:28
Unfortunately I have to debug msvcrt limitations so I need that crap 17:29
Whiteknight ubuntu? 17:32
purl ubuntu is xkcd.com/178/ or a god, yes
17:34 rdice joined 17:39 ask joined
mberends rurban: now you've confused purl 17:44
rurban yep, But I rather fix -0 now
Andy D gave me enough hints to solve it
Shit. Again TT #276 is rising its ugly head 17:47
particle rurban: patch didn't apply cleanly, but cleaned it up and rebuilding now 17:54
rurban I'm not sure if it's 100% ready ditto. I need more tests 17:55
I found out that we have the machinery to detect the -0.0 problems since Fri, 2 Apr 2004, but nobody fixed it so far! RT#28170 18:04
18:05 ask joined
NotFound rurban: wellcome to parrot X-) 18:05
rurban Ok, I think I can fix RT#30737 also now. 18:06
why does all this ugly PGE "argument doesn't hash" error come up again and again?
particle wonders if it's a pcc bug 18:11
rurban believe it's a make realclean problem. Some additional file which should not be there 18:12
a "make svnclobber" candidate 18:13
All this signbit discussion from 2004 only cares about one non-conformant platform; openbsd. Now we also have win32. The argument that the detection code is not platform safe is moot. RT#30737 18:20
Infinoid rurban: actually, you might be right. It looks like src/call/pcc.str isn't cleaned up properly by realclean (pcc.c is where the crash occurs) 18:22
particle aha, a pcc bug, and a make realclean problem! :) 18:23
rurban I cleaned up and I'm through
And I almost fixed the -0.0 printing problem! 18:24
particle fixed as in it will print -0.0 everywhere?
rurban yes
particle fab.
rurban #ifndef PARROT_HAS_NEGATIVE_ZERO if (Parrot_is_nzero($1)) Parrot_io_printf(interp, "-0\\n"); workaround code 18:25
But I cannot confirm it on openbsd. I can only test two failing win32 platforms: mingw and msvc6 18:26
particle commit it, and the openbsd smoker will confirm it for you
i deleted src/call/pcc.str, and rebuilt fine. infinoid++ 18:27
Infinoid particle: The main worry on my mind is, will it build correctly every time? 18:30
dalek rrot: r36635 | Infinoid++ | trunk/config/gen/makefiles/root.in:
[config] Realclean should remove src/call/pcc.str.
18:31
rurban particle: looks good. only 3 remaining t/op/arithmetics 9-11 failures
particle Infinoid: note in the trac ticket that r36635 might fix the seggy 18:32
Infinoid Andy D's patch is still necessary, isn't it? 18:33
Has that been checked in yet?
Infinoid tries to figure out which ticket it was again 18:34
particle tt#276? tt#278? 18:35
necessary, and not yet committed
Infinoid ah, #261 18:36
particle eh, sorry.
Infinoid Too many failures, my stack leaks
rurban particle: the latest TT #312 patch of mine should be stable now. trac.parrot.org/parrot/attachment/...ng.3.patch 18:37
shorten rurban's url is at xrl.us/befzo4
rurban Infinoid: The solaris long double patch?
particle rurban: did you lc if(IMPORTLIB) in config/init/defaults.pm? 18:38
Infinoid rurban: No, I was talking about trac.parrot.org/parrot/attachment/...test.patch . I'm going to commit that now
shorten Infinoid's url is at xrl.us/befzo8
rurban particle: yes
particle t/src/embed.t fails for me with 2.patch
...and my mods... 18:39
rurban yes, good catch
TT #261 I mean
18:40 jan joined, barney joined
dalek rrot: r36636 | Infinoid++ | trunk/config/auto/jit.pm:
Apply exec_test.patch from doughera++ in TT #261. Fixes some fallout from r36176, and it might fix TT #261.
18:42
Infinoid How do things look on feather now? 18:43
dalek rrot: r36637 | NotFound++ | trunk/src/debug.c:
[debugger] fix interpreter usage in PDB_info
18:47
Infinoid rurban++ # credit where credit is due, for suggesting the realclean problem 18:50
rurban t/src/embed.t is a different beast
Infinoid Yeah.
rurban particle's t/src/embed.t failure
But I think on non long-double platforms the ugly head of -0.0 is now beaten. msvc6 also passes all tests 18:51
Someone said 5 years ago on arm it might fail also... 18:52
may I put multiple lines with if into an inline op ? 18:54
nopaste "rurban" at 212.183.55.23 pasted "Is inline valid here?" (13 lines) at nopaste.snit.ch/15601
particle i don't know if ops2c parses inline 18:56
it sure does.
moritz meh, still no reliable build on i386 18:57
particle moritz: svn up, config, realclean
moritz particle: I did already
particle realclean was broken, so you need the new one
rurban rm src/call/pcc.str is faster
moritz ok, I'll try again... 18:58
particle rurban: sure, but that doesn't test svn :)
rurban I think long double will not make it for 0.9.1. Not enough time 18:59
19:01 mikehh joined
rurban How I love "All tests successful." 19:02
particle parrot built on feather, testing now 19:03
Warning: Building a shared parrot library may conflict with your previously-installed /usr/local/lib/libparrot.so
19:03 chromatic joined
particle didn't expect to see that on feather 19:03
rurban :)
particle :) indeed
rurban But for special tested platform hints we could skip this warning really. 19:04
Almost all --rpath enabled platforms should build fine now. But I need to crosscheck 19:05
Infinoid I think it's a good warning. It's a common source of breakage I think, and we don't always have control over the linker order
which platforms don't have --rpath? 19:06
NotFound The mention of inline has inspired me. I dropped the inline qualifier from the atan NUM NUM NUM opcode and that solves TT #201
rurban win32, mingw and cygwin are also now safe with the latest patches in the queue
Infinoid: really don't know
NotFound Now some jit guru must explain it
rurban darwin/ppc I assume
Infinoid does msvc have it (or something equivalent)? 19:07
If all our core supported platforms have it, the warning might be downgraded to something like "Depending on where you install me, that library over there might get in the way" 19:08
Or do we use --rpath in that case too?
Coke note that darwin/ppc and darwin/x86 have pretty identical build processes. the actual metal is well hidden. 19:09
Coke cringes as a peer of his has his contract terminated. 19:10
Coke is safe, for now.
rurban Oh! I also fixed "Inf/NaN - basic arith" for msvc by an unexpected side-effect 19:11
particle feather fails t/src/extend.t 12-13, 15, 17
nopaste "particle" at 76.121.106.245 pasted "feather failures" (43 lines) at nopaste.snit.ch/15602 19:13
rurban make realclean? 19:14
purl somebody said make realclean was sometimes need in parrot to work against missing dependencies
rurban looks like the great string branch merge 19:15
Infinoid particle: that test passes here. Is that your /usr/local/lib/libparrot.so getting in the way?
particle iunno, it's feather, and i never log in here 19:16
Infinoid LD_LIBRARY_PATH=blib/lib perl t/src/extend.t 19:17
Hmm. You know, I kinda wish the TODOed test syntax required a regex for the failure message. That way you'd know if it *changed*, not just if it passed. 19:20
19:20 rurban_ joined
particle 1;1 particle@feather:~/parrot/trunk$ make svnclobber 19:22
/usr/bin/perl5.10.0 tools/dev/svnclobber.pl
1;0 particle@feather:~/parrot/trunk$ svn st --no-ignore
I blib
I lib/Parrot/OpLib
that doesn't seem right
chromatic Parrot::OpLib::core is a generated file. 19:23
particle svnclobber.pl - delete all files that are not checked into SVN 19:26
NotFound What's that "argument doesn't hash" thing? 19:29
Infinoid Good question, but it's been popping up everywhere 19:30
NotFound: src/call/pcc.c:676
rurban That means that rm src/call/*.str must be done
Infinoid The PMC in question is a Hash PMC.
Whiteknight what you don't see is that the argument also doesn't jive, and it doesn't chill
Infinoid rurban: I'm not really sure it's been fixed yet 19:31
dalek rrot: r36638 | rurban++ | trunk:
Fix TT #313, printing -0.0 on older win32 MSVCRT dlls

  - add has_negative_zero feature,
  - fix print_n and say_n for the platforms failing the new has_negative_zero
   configure test
  - enable the failing tests again
This -0.0 is a long-standing problem and finally fixes [perl #28170],
  [perl #30737], [perl #19183], [perl #60312].
Note that special yet untested platforms, like arm might also fail the has_negative_zero test and might fail the signbit workaround we use. long double -0.0 will also need a workaround code like this. There's a patch to generate the signbit() fallback at RT #30737. Many thanks to Andy Dougherty for pointing me to the old tickets and for the solution which was there for 5 years.
NotFound A Hash doesn't hash?
NotFound This is a commit or a wikipedia article?
Infinoid rurban++ # excellent commit message
Thing is, if it's a bad src/call/pcc.str, then where did that bad pcc.str come from? It shouldn't change from one build to the next if the source file wasn't changed, right? 19:32
moritz NotFound: sometimes things need to be said.
Infinoid so I'm worried that there may still be an intermittant cause
rurban This is a commit for about 5-6 tickets
Inf/Nan is also solved by this. Forget to mention it.
particle rurban: on which platforms? 19:33
rurban Inf/Nan failed on mingw+msvc. Also a msvcrt issue
Infinoid NotFound: correct, apparently VTABLE_does("hash") returned false for a Hash that looked perfectly valid, as far as I could see 19:34
that's what I concluded after poking around in gdb last night
rurban openbsd shoudl also be fixed, but I left the tests as todo and look at the smolders
Infinoid NotFound: so does removing src/call/pcc.str and rebuilding fix it for you?
I guess it must be the "hash" string constant then
NotFound If that thing must be removed, why make realclean does not delete it? 19:35
Infinoid NotFound: It does now, see r36635 19:36
the old Makefile didn't have that, so you'd have to reconfigure to get the updated makefile, and then realclean again to remove the dead file 19:37
rurban Any chance to get the TT#312 win32 linking patch in also? 19:38
Infinoid though you don't really need realclean, a normal clean would do.
NotFound It worked, thanks 19:42
GeJ Good morning everyone 19:44
Infinoid hi GeJ
rurban Good evening
Infinoid (for once, it actually is morning here... must be early where you are)
GeJ Infinoid: 6:44 AM 19:45
which is too early if you ask me 19:46
Infinoid is it a good idea for our Makefile to detect when config/gen/makefiles/root.in is newer, and do a reconfig automatically?
Whiteknight Infinoid: yes
cotto Infinoid, go for it. 19:47
Whiteknight anytime somebody edits the root makefile template, it causes problems because people don't know to realclean
cotto I'm a little surprised that's not the current behavior.
NotFound GeJ: does the stdout redirecting solved your problem?
Infinoid education would be my first answer to that problem, but this might be a helpful stopgap measure
Whiteknight education is for the wusses. I demand technical solutions! 19:48
NotFound Infinoid: giving some information about what is doing will be nice, in that case
particle Infinoid: changing anything under config/ could need a reconfig 19:49
or some things under lib/, or tools/
GeJ NotFound: didn't try it yet. $work got in the way and I was too tired to do anything productive last night. I will however give it a try this week-end 19:50
Infinoid NotFound: Yeah. The normal behavior at that point is to do the reconfig, and then echo "Your Makefile was busted, I fixed it, please rerun make kthx" and then error out (because make is still using the old makefile it parsed at start time)
NotFound If you are going to be drastic, we'll need a --no-reconfig option
Infinoid I'm not in a very drastic mood at the moment.
NotFound Infinoid: this was for particle comments
Infinoid oh ok 19:51
particle i don't want reconfig automatically, really.
i see config/init/hints/cygwin.pm changed, and so did root.in
but it's not my platform, and it takes 10 minutes to build parrot after reconfig
i just want a 2m recompile
i'll do a full rebuild later 19:52
Whiteknight Ha! Two things that I mistakenly though were test failures last night actually ended up being TODO passes unexpectedly succeeding
I just didn't pay close enough attention to see that
Infinoid Yeah, and I don't care about cygwin hints, here on linux. So now I have to figure out which config files are relevant on the current platform. And this thought is quickly growing out of hand
dalek rrot: r36639 | fperrad++ | trunk/languages/lua/src/pmc:
[Lua] remove VTABLE_morph
Whiteknight that's why I shouldn't code after 8pm 19:53
NotFound If someone wants to speed rebuilds here is a suggestion: don't update generated .str if the existent version is equal to the new generated one, and make the Makefile work correctly with that
Infinoid particle: You're absolutely right. How about just saying "Ok, looks like your Makefile needs to be regenerated, do the reconfig yourself, I'm bailingD[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D." and erroring out?
rurban particle: thanks
Infinoid erk, something's wrong with my terminal
particle rurban++ 19:54
rurban I also spotted 3 minor issues with t/op/os.t on windows. need to lowercase the filename checks
NotFound There is some way to add negative zeroes to the karma? ;)
Infinoid NotFound: that's the easy form of the strcache idea I've been toying with
I think pmccache will have a bigger benefit though 19:55
rurban I wonder who needs those beasts anyway. causing such trouble with so little gain
particle t/pmc/os.t readdir test is failing on win32
rurban upper/lowercase issue
NotFound Infinoid: make Makefile deal with that type of things is no exactly easy
Infinoid leaving them on a realclean and checking timestamps to see if they need to be regenerated is pretty easy 19:56
especially in a makefile
NotFound Infinoid: yeah, but the rebuild without clean will be trickier
Infinoid why? you edit the file, the .c file is now newer than the .str file, so you regenerate it
is it more complicated than that? 19:57
NotFound Infinoid: look at the stuff automake generates for yacc files, for example
Infinoid eew, do I have to? :)
NotFound I hope not 19:58
Infinoid automake does *everything* the hard way
rurban particle: TT #325 case-sensitivity test issues on win32
Infinoid or maybe it just seems hard to me because I'm biased against m4
rurban solaris on the other hand failed os tests 6 and 9. 19:59
NotFound There is some rason to have a test that the directory hard links that nobody in his sense is going to ever use? 20:01
Infinoid someone 5 years from now who isn't in his right mind will file a bug if we don't 20:03
20:03 geof joined
moritz then it's still time to add that 20:04
NotFound Interesting... foul oriented design X-)
fool
Infinoid if its something we wrote code to do, it should be tested where we support it
NotFound The code is for doing hard links, plain simple. 20:05
Infinoid then if the code doesn't differentiate between files and directories, I don't think the test needs to either (sounds like it's testing the OS and FS, not parrot) 20:06
NotFound And is a shame to maintain the code for a test that nobody use and does not have any practical purpose.
Infinoid well, it sounds like it would be a portability problem to me 20:07
NotFound Infinoid: is testing the stupidity of somenone that executes a test battery as root
Infinoid Checking for stupid user........ ok, found. 20:08
NotFound if 1 X-)
moritz Infinoid: and I thought you'd write "Checking for stupid user........ ok, NotFound" *SCNR* 20:10
NotFound Grrrr 20:11
Infinoid ouch!
rurban: thanks for config/auto/neg_0/test_c.in, but it fails t/codingstd/c_code_coda.t, t/codingstd/copyright.t, t/codingstd/svn_id.t 20:14
NotFound I've choose that nick many moons ago in a Fidonet BBS to confuse people: "searching for user..... NotFound"
moritz ;-)
Infinoid heh. I chose "paranoid" when I was 6 years old and logging into a BBS for the first time... it was the biggest word I knew how to spell. I got divided by zero at some point since then 20:15
20:17 zostay joined
rurban Infinoid: do you want to fix that? I'm just busy with fixing the failing pmc/os.t tests 20:17
Infinoid I can, sure
I'm just not very comfortable putting copyright notices on other people's files, so I like to ask first 20:18
szbalint I guess I'll call you NaN then ;)
Infinoid I'm the anti-NaN!
NaNfinoid I'm the anti-Inf! 20:19
NaNfinoid != NaNfinoid
moritz the anti-Inf is spelled "Fin"
antiNaN collides with NaNfinoid and annihilates, producing a burst of Inf 20:20
rurban just give it the Parrot foundation :) Ok, I'll do.
Infinoid anti-NaN is spelled in reverse 20:21
Whiteknight nanitna 20:24
Infinoid rebmuN a toN 20:25
NotFound: got a patch to handle negative NaN yet? :)
rurban I think I already solved it with my patch 20:29
Are there problems on linux also?
Infinoid rurban: all tests pass here 20:30
NotFound Infinoid: i must first send the technical proposal to some iso commitee
Infinoid rurban: (negative NaN was a joke from yesterday) 20:31
NotFound rurban: we have negative 0 and negative inf. Why not a negative nan? Is discriminatory
particle (NaN+Infi) 20:32
rurban Yes, world is unfair 20:33
Infinoid NaN + -NaN annihilates and takes the universe with it. Though I'm not sure we can destroy the universe and still support C89
chromatic Can we destroy MSVC and thus move up to C99? 20:34
Infinoid Sounds good to me.
particle heads to the post, two client sites, and maybe lunch, ignoring chromatic all the way &
NotFound Can we do that before 2099?
rurban BTW: I have NaN failures almost everyday with my customers. Some have old motorola flotingpoint units which could not handle some specialNaN formats.
So we added special exception handling for that 20:35
(Stupid checp embedded systems)
msvc has good warnings!
NotFound "Warning: you're using me"
chromatic "Warning: C99 only a decade old and still unsupported, have you tried the Mojave experiment?" 20:37
NotFound BTW, someone has been crazy enough to build parrot with msvc in c++ mode? 20:38
Coke_afk (regen the makefile) ISTR it used to do that and was removed. 20:39
Infinoid wonders if the ISO C committee will follow their 10-year release cycle and issue a C109 standard this year 20:40
dalek rrot: r36640 | rurban++ | trunk/t/pmc/os.t:
- Fix TT #325 (3 randomly failing os.t tests on win32)
Coke particle: if the makefile is /wrong/, I'm not sure we should let you use it, even if rebuilding DOES take that forever. 20:42
if you see root.in get updated, you can always touch Makefile to show you know what you're doing.
rurban make reconfig is my friend 20:43
Coke hey, a patch from some guy we've never seen before. Someone test that out and apply it. =-)
chromatic Patch looks solid to me ;) 20:47
Now I'm going to take some head medicine and a nap for winking back to Coke.
rurban Infinoid: A copyright for a one-liner? 20:48
Infinoid rurban: That's what the coding standard enforces. I've got a patch to add all those things, if you'd like to work on something more important 20:49
rurban no, just did it.
Infinoid ok, thanks
opbots, trust rurban 20:50
clunker3 But I do not trust you Infinoid
slavorg Ok
slavorgn Ok
Infinoid (long overdue)
Coke purl, clunker3?
purl i guess clunker3 is an OpBot running on Tux' old workstation at work
Coke Tux?
purl rumour has it Tux is H.Merijn Brand tux.nl mailto:h.m.brand@xs4all.nl and maintains HP-UX binaries for Perl (with DOR!) and other free software at mirrors.develooper.com/hpux/
rurban opbots, trust Infinoid 20:51
slavorg But I already trust infinoid
clunker3 But I do not trust you rurban
slavorgn But I already trust infinoid
rurban catch 22
purl hmmm... catch 22 is it's a good idea yet the scripts are so trivial that most who'd be good enough to do it right are completely uninterested in doing it.
Coke purl, clunker3 is also useless.
purl okay, Coke.
Coke karma catch
purl catch has karma of -1
Infinoid slavorgn?
purl, slavorgn?
purl i don't know, infinoid
Infinoid slavorgn is run by Infinoid 20:52
Coke if we have a parrot hacker running an opbot in here, do we need merjin's?
Whiteknight opbots, trust rurban
slavorg But I already trust rurban
clunker3 But I do not trust you Whiteknight
slavorgn But I already trust rurban
NotFound chromatic: have you seen my comment on the atan jit thing?
chromatic Which ticket?
purl Which ticket is this now?
Whiteknight clunker is just antisocial 20:53
Infinoid Coke: merijn's would be fine, if it actually knew about anyone in here.
I just added slavorgn to give slavorg some backup (which it needs from time to time)
Coke slavorgn, help? 20:54
NotFound chromatic: TT #38
dalek rrot: r36641 | rurban++ | trunk/config/auto/neg_0/test_c.in:
[cage] codingstd for a one liner increases the size by 10
20:55
Whiteknight clunker3, trust?
chromatic No inlining, interesting. 20:56
Coke chromatic: if you still feel dirty, you could fix rt.perl.org/rt3/Ticket/Display.html?id=57088
Infinoid rurban: I guess the alternative is to put the oneliner into a heredoc 20:57
rurban naa
chromatic I keep promising to fix that one.
Coke rurban: rt.perl.org/rt3/Ticket/Display.html?id=57486 (cygwin failure)
rurban Thanks, we can close this. 20:58
dalek rrot: r36642 | chromatic++ | trunk/src/embed.c:
[src] Added an explicit close of packfile file if reading fails, so as not to
20:59
rurban The reason is that cygwin uses use64bitint
dalek rrot: r36643 | chromatic++ | trunk:
[misc] Tidied some code; no functional changes. Yes, it's all over the place.
21:02
rurban wrong reasoning in irc, but right on RT rt.perl.org/rt3/Ticket/Display.html?id=57486 21:04
when does our shop close for release testing? 21:05
Cause I want to deprecate Parrot_readbc and friend 21:06
Infinoid you can add things to DEPRECATED.pod just before the release is cut, in fact, it seems like most things are 21:07
rurban Ok, will do tommorrow
I want to test it properly first 21:08
Infinoid sounds good. If you have a patch you can link to, I'm happy to test it too
chromatic Hm, some make testj failures. 21:09
rurban Sure. I have: tt308-long-double16.patch
tt312-win32-linking.patch
tt322-readline-popup.patch
tt238-install-devel.patch
tt277-test_exec.patch -p0
tt258-pbc_disassemble-options.patch
tt266-todo-read_pbc.patch
t238 is for particle's goal and not quite ready yet
tt266-todo-read_pbc is the deprecation (no macros yet) 21:10
Good thing: I also have the bignum.pmc implementation somewhere. This needs a ticket I guess for the feature and API discussion. 21:11
Infinoid imports all those into his stgit stack 21:13
rurban I use quilt. For tt322 I have no patch yet. 21:14
dalek rrot: r36644 | Infinoid++ | trunk/compilers/imcc/main.c:
Apply patch from (Dany Arbelo)++ in RT #46503:
21:15
Infinoid stgit was apparently modeled after quilt
which tt312 patch? all 3?
rurban Hey, I always use parrot -b 21:16
tt312 only the newest
.3
purl 0.3
Coke I shortened the test case for rt.perl.org/rt3/Ticket/Display.html?id=57764
(chromatic, another small PIR case that segfaults/bus errors)
rurban tt312 is a big and important one.
Coke we still have tickets open regarding the Storable fiasco. 21:17
Infinoid raw tt266 patch or tt226+258 patch?
rurban It is for installed versions and for linking with already installed lib so.
This is my series order
Infinoid s/226/266/
rurban so first tt258, and then tt266 21:18
Infinoid there's a second patch attached to tt266 that says tt266+258
rurban but those at the end are not so uptodate, needs some merging work probably
Wait a sec, I'll update those. The tt266+258 was good
Infinoid no problem. if you want to just mail me your stack, that works too 21:19
rurban I found some codingstd problems with my macro hackery also in packfile.c
And I need to add floattype #defines to packfile also. This is for the weekend. 21:20
21:22 HG` joined
rurban t/op/debuginfo...setline and setfile fails. wasn't this fixed already by annotations? 21:22
I remember now. It was fixed but the test needs to be updated.
Infinoid tests 308+312+277+258 21:23
chromatic Hm, ./parrot -DD causes segfaults. 21:24
Interesting.
rurban Infinoid++ 21:26
nopaste "Infinoid" at 96.238.213.50 pasted "Undef warnings from auto_neg test on linux/x86-64" (7 lines) at nopaste.snit.ch/15603 21:28
dalek rrot: r36645 | chromatic++ | trunk/lib/Parrot/Harness/Options.pm:
[lib] Added option remapping to Parrot::Harness::Options to use the recommended
rurban yes, I know. will fix later
I didn#t understand why
maybe kid51 has an answer
Infinoid it seems fairly common to fix that kind of thing by returning "" instead of undef
rurban Ah, thanks 21:30
dalek rrot: r36646 | NotFound++ | trunk:
[debugger] re-enabled the debug_init opcode functionality
chromatic Which file returns undef?
rurban config\\auto\\neg_0.pm obviously but I see no error 21:31
chromatic You need to run config::init::defaults in the test first, otherwise nothing else is present in the configuration object. 21:35
rurban parrot_debugger.exe [main]bin is missing in MANIFEST.generated btw 21:36
chromatic I'll check it in.
rurban Tjos sanity checks are missing and may harm the installer
pdb => parrot_debugger
dalek rrot: r36647 | chromatic++ | trunk/t/steps/auto_neg_0-01.t:
[t] Fixed unintialized value warnings generated by auto_neg configuration step
21:37
21:38 mj41 joined
szabgab chromatic, I looked at Parrot::Embed and now it seems to be broken at t/languages.t line 30. 21:39
dalek rrot: r36648 | jkeenan++ | trunk/config/auto/neg_0.pm:
Eliminate warning re "Use of uninitialized value $_ ... at

Parrot::Configure::Compiler::cc_clean() was called inside auto::neg_0::runstep(). In this probe, we're not creating any new files, simply printing to STDOUT. So there's nothing to be cleaned up and no reason to call cc_clean().
  rurban++ for contributing step tests along with new config
step class.
chromatic szabgab, right -- the namespace in abc is wrong.
It uses old-style namespaces, and Parrot::Embed uses new style namespaces. 21:40
rurban kid51++ but I just found it now also :)
Coke wonders if it's better to /always/ call cc_clean
(r36648)
szabgab so how can I help to fix it? 21:42
chromatic Ask the authors of abc if they want to switch namespaces.
Then we need to fix the argv/main don't behave like regular sub parameters mess in Parrot. 21:43
szabgab that's pmichaud as I can see
rurban t/op/debuginfo 7-8 fails on testf if someone wants something to fix
chromatic yes, pmichaud 21:44
purl hmmm... pmichaud is www.pmichaud.com/ or "Patrick R. Michaud" <mailto:pmichaud@pobox.com> or in charge of toaster experiments
szabgab chromatic, I don't even understand what I need to ask him but I hope he'll see these few lines and answer something 21:45
chromatic pmichaud, ping
dalek rrot: r36649 | Infinoid++ | trunk/include/parrot:
[cage] Updates from "make headerizer".
21:46
szabgab btw I really don't understand the question, if they don't switch namespace then it stops working soon right ?
pmichaud pong 21:48
Coke chromatic: I think there's an RT that relates to the argv mess.
chromatic Right.
Right now, abc's namespace identifier is a string.
Parrot::Embed expects namespaces to be keys (think an array of strings). 21:49
pmichaud Looking.
Coke rt.perl.org/rt3/Ticket/Display.html?id=39844 :: #39844: [BUG] Parrot doesn't do args checking for a sub without params
(one of the remaining issues on that was :main. 21:50
pmichaud chromatic: I think the only thing that is affected is 'abc::Compiler' in abc.pir, yes?
chromatic Yes.
pmichaud we should be able to change that 21:51
I don't think anything depends on it.
chromatic I didn't want to change it without asking first.
szabgab chromatic, looking at the log I see you have implemented at least some of the stuff I asked for, right ?
pmichaud feel free to change it and see what breaks. Nothing should.
chromatic szabgab, some of it yes.
Oh, how I hate tickets which end with a patch from me and no other comments.
szabgab great, then I try to use it and let you know where I get stuck
21:52 Whiteknight joined
chromatic szabgab, I think you'll get stick on RT #39844. 21:52
... but I'm looking at that.
pmichaud The ['abc::Compiler'] is likely left over from an incomplete string-to-key conversion. Since nothing depended on it, it never got switched.
szabgab ok, I have to go to sleep now anyway
I'll try it tomorrow 21:53
chromatic I wouldn't expect it to change anything beyond anything which loads abc from its PBC and not compreg.
Arguably Parrot::Embed should use a compreg approach. 21:54
dalek rrot: r36650 | chromatic++ | trunk/languages/abc/abc.pir:
[abc] Changed abc's compiler to use a real multi-part namespace.
nopaste "infinoid" at 96.238.213.50 pasted "rurban: add this to tt308-long-double16.patch to pass codetest" (50 lines) at nopaste.snit.ch/15604 21:55
21:58 HG` joined
NotFound t/embed.t is completely broken, will be better to drop it and restart from scratch 22:01
rurban Infinoid++ thanks
NotFound t/src/embed.t
purl i think t/src/embed.t is renamed from t/src/compiler.t, if it helps
NotFound purl: no, it doesn't help
purl NotFound: what?
NotFound TF
Infinoid t/src/embed.t, you mean? Yeah, it's a starting point for TT #306, it worked fine when it included parrot.h and extend.h as well, but we need to be able to do useful things with parrot without those 22:02
purl++ is correct
NotFound Infinoid: yeah, it works fine when used in a completely wrong way. Nice testing
Infinoid indeed. it's a starting point, nothing more 22:03
NotFound It looks like a negative starting point to me.
Infinoid If it's garbage, then maybe we should start with a simplified version of what mod_parrot does, instead. (but they include parrot.h and extend.h too, of course) 22:04
NotFound If it includes parrot.h is wrong. 22:05
Infinoid ...it includes parrot.h because there's no other way to get useful stuff done at the moment. That's the point of the ticket, I think
we need to improve embed.h to the point where you can embed parrot with it 22:06
NotFound Well, the I'll start to see if I can embed parrot 22:07
Infinoid NotFound++
NotFound But I still don't see the point of having a test file that unconditionally skips all 22:08
Infinoid it's better than a test file that passes everything but uses tricks we're trying to get rid of 22:09
NotFound svn delete is cheap
Infinoid so is svn mv, which is what particle++ did 22:10
NotFound I'll buy you one, if you don't have ;)
And with a free negative NaN as special offer 22:11
Infinoid ooooh
rurban: I've got a followup patch for tt258-pbc_disassemble-options.patch build warnings too 22:17
just waiting for test first 22:18
rurban thanks. I'm just working on long double and quad double support
nopaste "infinoid" at 96.238.213.50 pasted "rurban: fix const warnings from tt258-pbc_disassemble-options.patch" (68 lines) at nopaste.snit.ch/15605 22:20
Infinoid rurban: 312+277+258+fixup+308+fixup builds cleanly and tests successfully on linux/x86-64 22:27
rurban Infinoid++
and the features? esp. the new option?
the deprecation has also to be added
Infinoid are they tested? :)
rurban sure
Infinoid if its in make test, it works
rurban for disassemble there's already a test, the roundtrip might need some more tests, but the roundtrip fails because of internal limitations 22:28
rurban loves make headerizer 22:29
Infinoid Andy++
rurban do we plan to support quad int soon? 22:31
INTVAL_SIZE = 16 22:32
Infinoid is that ... long long long?
rurban just quad
eh, no long long
Infinoid doesn't work in gcc
rurban INTVAL_SIZE == 32 is quad 22:33
there are better compilers out there :)
Ok, I'll leave it out
Infinoid heh. 22:34
test.c:4: error: 'long long long' is too long for GCC
rurban But I added binary128 support (FLOATVAL_SIZE = 32), or quad double, 128bit double
Infinoid I have no int128_t either. :( 22:35
rurban native only of course, no converters
Infinoid there are some 128-bit MIPS processors out there, I'll happily test on it if someone sends me one.
rurban double, not integer 22:36
en.wikipedia.org/wiki/Quadruple_precision
Infinoid my long doubles are 128 bit 22:37
gcc doesn't understand quad though
rurban I hope "long double" would be the proper type for those compilers
ah good. so you can test it :)
Infinoid set P0["hugefloatval"], "long double" 22:38
set P0["hugefloatvalsize"], "16"
rurban 16*8 = 128?
Infinoid 16*8 22:39
purl 128
rurban So I just invented 256bit doubles. shit. I'll remove it then
Infinoid 32 bytes would be 256 bits, I don't think I have any of those types
rurban But I already wrote the be<->le converters for those...
Infinoid heh. rurban++ 22:40
rurban maybe I'll call it future-safe and let it in...
Infinoid long far time_t *future; 22:41
22:44 darbelo joined
Infinoid Oh, man. Arithmetic on far pointers in 16-bit C doesn't adjust the segment type, so they wrap at the 64k boundary despite being far pointers. Somebody actually *specified* this. 22:49
s/type// 22:50
rurban what in the flat memory model or segmented?
nopaste "NotFound" at 213.96.228.50 pasted "Embedding parrot, hello world" (52 lines) at nopaste.snit.ch/15606
Infinoid segmented
rurban I once read 16-bit dos assembler books. This reminds me of that. 22:51
NotFound Less than one hour, not so bad 22:52
Infinoid I realize x86 doesn't have an easy way to check the carry bit and increment a segment register, but still.
rurban Not specifiying far ptr wrap ups on arithmetic sounds faster to me. 22:53
TonyC you could always use huge pointers/huge model
rurban for this kind you have normal ptrs anyway. far is unsafe and fast
oops, midnight: I'll have to sleep, bye 23:01
Infinoid NotFound: nice.
rurban: goodnight
rurban I'll commit the pbc_read stuff tommorrow
Infinoid NotFound: maybe we should just convert the code in docs/embed.pod into tests. though those include parrot.h too, and the first one doesn't need to 23:02
without parrot.h, the final example gets a warning about not finding imcc_main() 23:03
s/imcc_main/imcc_init/ 23:04
dalek rrot: r36651 | Infinoid++ | trunk/docs/embed.pod:
[docs] embed.pod's first example includes parrot.h, though it has no reason to.
NotFound imcc_main must die
NotFound imcc_init must die in a most painful way 23:06
Infinoid agreed, it seems like something that would be nice to be done internally by Parrot_new() or whatever 23:12
NotFound Well, in the meantime I'll put a Hello world test in embed.t to at least make some real test 23:13
Infinoid particle: It would be nice to have some more details about the work involved in fixing #306. Right now the ticket is a bit vague 23:14
NotFound++
particle: what constitutes a "fix"?
NotFound Infinoid: I suppose the fix is: make parrot embeddable an test that capability in some way 23:15
Infinoid we can almost get rid of all mentions of parrot.h from docs/embed.pod, if it weren't for that call to imcc_init() in the final example
NotFound make - make sure is
Infinoid I've yet to see any useful example that uses embed.h but not extend.h. I'm starting to wonder if it's even useful to distinguish between the two 23:16
NotFound Infinoid: that is a philosophical dicussion that generates lot of noise in other interpreters discussion sites and wikis. Please don't start such thing in parrot. 23:17
pseudo-philosophical, better said 23:18
chromatic I don't think it's a useful distinction between the two either. 23:19
Infinoid Ok, I can say it in another way. PDD10 says "extending" is when you want to write your own PMCs or do something that NCI can't do. NotFound++'s example (nopaste.snit.ch/15606) and the examples in docs/embed.pod don't try to do those, so they shouldn't need to include extend.h
NotFound Infinoid: I included extern.h because of printf
extend 23:20
23:20 cognominal joined
NotFound And printf is used in the example just a fast way of checking that the interpreter works. 23:21
23:21 idemal joined
Infinoid for what it's worth, it seems like TT #306 might just be there to track the PDD10 task on the roadmap for 1.3 23:23
chromatic Yeah, I don't expect we'll get all of this sorted out until 1.5. 23:24
dalek rrot: r36652 | NotFound++ | trunk/t/src/embed.t:
[test] test something in embed.t
23:25
23:25 Limbic_Region joined
NotFound BTW all tests in extend.t uses embed.h and have main, so they are all emebdding tests 23:28
Infinoid Right. The extend API seems to be a superset of the embed API 23:29
23:29 mberends joined
NotFound From a quick look, the only function in embed.h that seems useful only for embedding and not for extending is Parrot_set_executable_name 23:34
Parrot_new is used both for crate a new interprter and for child interpreters, so is not just for embedders 23:35
23:35 bacek_ joined 23:46 Tene_ joined
chromatic The DarkPAN support policy is insane: url.ie/16nn 23:59
Let's avoid those mistakes.