"Parrot 0.6.4 "St. Vincent Amazon" Released | parrotcode.org/ | 15/648/80 new/open/stalled tix | logged in irclog.perlgeek.de/parrot/today".
Set by moderator on 15 July 2008.
00:07 donaldh joined 00:09 AndyA joined 00:22 Psyche^ joined 00:23 Zaba joined
kid51 I've got my coverage reports working again: thenceforward.net/parrot/coverage/c...erage.html 00:31
Whiteknight chromatic, you still here? 00:40
chromatic Briefly. What's on your mind? 00:49
Whiteknight just going to invite you, if you have some tuits, to take a look at my branch 00:50
chromatic Give me 15 - 20 to get back to my hotel and I will.
Whiteknight I gutted the sweep code, simplified it down to nothingness, and I'm still getting prematurely freed PMCs 00:51
no rush, but I'm basically blocked on this
chromatic Okay.
Did you follow my "How to debug GC problems" guide? (sorry, I have to ask)
Whiteknight Yeah, but I'll read it again and make sure I'm not missing anything 00:56
01:02 AndyA joined
Limbic_Region Whiteknight - they have pills for that 01:10
premature freeing that is
01:10 chromatic joined
Whiteknight it's the number one problem among male programmers 01:14
chromatic GC? 01:15
purl GC is the boehm conservative garbage collector at reality.sgi.com/boehm/cg.html or a really really bad perl "programmer" or GrandCentral.com
Whiteknight purl can be remarkably unhelpful sometimes 01:18
purl Whiteknight: huh?
Whiteknight purl, GC is also branches/gsoc_pdd09
purl okay, Whiteknight.
Whiteknight purl, GC is also a travesty against god
purl okay, Whiteknight.
Limbic_Region Whiteknight - consider that purl's factoid database is cross channel - so certain entries don't make sense out of context (#parrot) 01:19
Whiteknight it's my goal to ensure that none of them make sense to anybody
Limbic_Region Whiteknight++ 01:23
Whiteknight I'm failing all the PGE tests, which makes sense because I can't build PGE 01:28
a lot of other tests are passing though, so that's reassuring
01:31 Zaba joined, s1n joined 01:36 Zaba_ joined
chromatic Whiteknight, see t/op/string.t 01:39
Some interesting failures there; they look suspicious.
Whiteknight the string subsystem has been bonkers for a while though. I suspect the same kinds of offset failures from the compacting code are coming into the rest of the string system 01:40
you are right, lots of interesting failures 01:41
chromatic Did you re-enable compacting?
Whiteknight no 01:42
i am making the blind assumption that compacting isn't necessary for proper operation
01:42 Zaba joined
Whiteknight Certainly bad for efficiency to disable it, but I don't think it's strictly necessary 01:43
chromatic Agreed.
That means compacting isn't the problem here.
Whiteknight A good test might be to disable compacting in my trunk checkout and run the test suite there
but that's time I would rather not waste right now
chromatic The good news is that most of the string tests are small and self-contained, so they'll be easy-ish to fix. 01:44
Compared to PGE anyway.
Whiteknight Of course, disabling the compacting code doesn't necessarily fix that problem we were having with string pointers being messed up 01:45
so maybe it's just hiding a symptom, not the problem
chromatic Right. 01:46
Whiteknight with compacting enabled, it makes it to the same point in the build process. I'll debug to see if I am getting the same segfault 01:47
01:47 kid51 joined
Whiteknight ...yes, exact same error at the same point. The compacting code isn't affecting it at all 01:48
chromatic Good to know, but let's leave the compacting code off for now. 01:49
dalek r29503 | chromatic++ | gsoc_pdd09: 01:50
: [src] Fixed some codingstandards violations. No functional changes.
diff: www.parrotvm.org/svn/parrot/revision?rev=29503
chromatic ./parrot t/op/string_3.pasm
should print 4
If I set a breakpoint at Parrot_length_i_s and step into string_length, the string looks correct. 01:53
01:53 Zaba joined
chromatic If I set a breakpoint after that at Parrot_print_i and look at the contents of IREG(1), it's also correct. 01:56
Within PIO_printf, the string created for printing is also correct. 01:58
Hmm.
AHA 02:04
Whiteknight !!!?
chromatic if I add print "\\n" to the end of the code, it prints
so we're not flushing a buffer
PROBABLY
because the buffer gets flushed during destruction?
02:04 cjfields joined
Whiteknight You think that's the case? 02:04
chromatic That explains a lot of these failures. 02:05
02:05 Andy joined
chromatic PIO by default is line buffered, but when Parrot exits it needs to flush these buffers. 02:05
That's good though.
It means at least this part of strings isn't broken.
Whiteknight Sweep code for strings and the sized pools is disabled
and the finalization is caput
chromatic I think it's PIO finalization that we're missing here. 02:06
Whiteknight I can't enable finalization as-is without introducing new order-of-destruction errors
chromatic Even sweeping backwards?
Whiteknight it sweeps starting at the last arena 02:07
but in each arena, it sweeps back-to-front
I could redo that tonight/tomorrow and try it again
chromatic It works in trunk, so the algorithm can't be entirely wrong. 02:08
./parrot t/op/gc_4.pasm 02:09
There's a segfault.
src/scheduler.c:692
sched_struct->wait_index gets reaped early (its vtable is 0xdeadbeef) 02:10
Whiteknight yeah, that's like errors I was seeing
somehow, some PMCs are still being sweeped early
which means either my crippled sweep code is still wrong, or my mapping from card<->pobj isn't correct 02:11
chromatic Is pobject_lives calling mark appropriately?
Whiteknight it should be, it looks it to me
I'm thinking about ditching the separate cards and using the PObj flags like in PDD09
We lose some speed in the sweep (at least, when the sweep is running at full-speed), but other then that cache locality should keep the cost low 02:12
chromatic Let's benchmark it when we get it working. 02:13
02:13 Zaba joined
chromatic Interesting. 02:14
The scheduler gets marked and marks its kids, but they get swept and it doesn't. 02:15
How confident are you of your state transitions?
Whiteknight becoming less and less 02:16
chromatic The child PMCs of the Scheduler are mostly all ResizablePMCArrays.
Whiteknight I've kept state transitions to a minimum for this exact reason
those would trigger the PObj_data_is_PMC_array flag 02:17
chromatic I'm just waiting for something to click in your head again while I explore.
Whiteknight I'm racking my brain here, it all seems like it should work 02:18
chromatic Here's my strategy. 02:19
I'm going to look for a fork and see if there are still cookies in the lobby.
You (if you want) should set a breakpoint in Parrot_Scheduler_mark, grab the address of one of the child PMCs, and then set a conditional breakpoint somewhere in the sweep code to check for the conditions which trigger the sweep for that PMC. 02:20
And also hope that there are cookies in the lobby, because I want one and I don't really want to walk across the street to the grocery store.
Whiteknight Okay. I probably don't have the time tonight, but I can do that tomorrow
shit, if we can get this resolved I'll bake you a batch of cookies 02:21
quick question, in gdb if I have the address of a PObj, how can I look at the adjacent header? 02:22
can I do pointer arithmetic on it?
chromatic I believe so. 02:23
(no cookies, but I did find a microwave and plastic utensils, so not all a failure)
Whiteknight Okay, I'll play with that. If I can see the header, I can find the corresponding card and track when it gets updated
chromatic Looks like setting a conditional breakpoint on Parrot_dod_free_pmc will catch the point at which we collect the PMC. 02:24
Whiteknight right, but even for simple programs we call that function a hundred times or so 02:25
chromatic break Parrot_dod_free_pmc if pmc == 0x822a52c
Whiteknight can you do that? 02:26
Whiteknight is still a gdb newbie
chromatic You can and it's awesome. 02:27
02:28 Zaba_ joined
s1n conditionals rock 02:28
chromatic and it's getting called from gc_it_sweep_PMC_arenas 02:29
mark == GC_IT_CARD_WHITE is true
# define IT_HDR_to_PObj(p) ((PObj*)((Gc_it_hdr*)(p)+1)) 02:30
Is that right?
The PObj is one byte after the GC header?
Whiteknight it's pointer arithmetic, it's 1 Gc_it_hdr after it 02:32
Let me throw in some more parens there and see if that fixes anything 02:33
chromatic You don't need sizeof (Gc_it_hdr)?
Whiteknight no, in C pointers and arrays are interchangable, the compiler does the sizeof calculations for pointers automatically 02:34
p + 1 == p[1]
chromatic Where's the array though? 02:35
Whiteknight it doesn't matter where, C just does the pointer arithmetic as if it were an array 02:37
at least, it's supposed to
chromatic Right, but how does C know in this case that 1 means sizeof (Gc_it_hdr)?
Whiteknight because of the cast to (Gc_it_hdr*) I jammed in there 02:38
we cast the pointer to (Gc_it_hdr*), then add 1, and then cast the result to (PObj*)
The PObj_to_IT_HDR macro does the process in reverse 02:39
chromatic Ah, so that's why you wonder if adding more parentheses might help.
Whiteknight right
in (cast)p + 1, I can't remeber whether (cast) or + bind more tightly
chromatic I never trusted casts like that myself.
Whiteknight I assumed the cast did
chromatic /* Increase allocated space to account for GC header */
pool->object_size += sizeof (Gc_it_hdr);
Whiteknight right, I allocate the headers directly next to the objects, so the allocated space needs to be big enough for both of them 02:40
...and more parenthesis produces the same segfaults
chromatic I modified the macros. 02:41
Whiteknight that's fine, modify away 02:44
by the time I'm done debugging, not a shred of my original design is going to be left
of course, that's probably for the best
chromatic Hash problems.
Blah.
# define PObj_to_IT_HDR(o) ((Gc_it_hdr *)((o) - sizeof (Gc_it_hdr))) 02:46
# define IT_HDR_to_PObj(p) ((PObj *)((p) + sizeof (Gc_it_hdr)))
# define cPObj_to_IT_HDR(o) ((const Gc_it_hdr *)((o) - sizeof (Gc_it_hdr)))
02:48 cjfields_ joined
Whiteknight just to be sure, cast the arguments to (char*) to make sure it's all in bytes 02:49
((Gci_it_hdr *)((char*)(o) - sizeof(Gc_it_hdr)))
beyond that, I'm fine with the change 02:50
chromatic Ah, much better.
02:50 cjfields joined
chromatic That didn't fix anything though. 02:51
Whiteknight Okay, don't waste any more of your time. I'm going to bed. I'll get into gdb nirvana tomorrow after work and see if I can find anything 02:55
chromatic Okay.
Hmmm.
Here's a thought.
Whiteknight ?
chromatic Are you flipping all marked cards back to unmarked when you sweep?
Whiteknight yes, right during the sweep. If it's white, we free them, and if it's black we switch it to white 02:56
I could separate that out into two steps, but since I differentiate between free and white cards, I can't do a memset
chromatic Makes sense.
I see the code now. 02:57
Whiteknight I do that so in the sweep code I don't try to finalize anything that's already free 02:58
but I suppose i can determine that a different way
chromatic I ran into this when I was working with constants. 02:59
If something's already marked live, we don't mark its kids.
So if the Scheduler gets created and doesn't have its card flipped, the second GC run will sweep up its kids.
Whiteknight But every time the scheduler is marked, the kids should be marked during the trace too 03:02
I could be more aggressive marking the kids in pobject_lives or something
chromatic Let me try that. 03:03
Doesn't seem to fix it either. 03:05
Whiteknight I must have some mixup in the trace code, it must not be marking children black like I think it should be 03:06
chromatic Seems as plausible as anything.
Whiteknight Okay, i'm definitely heading to bed now. Thanks for everything tonight. I'll run with some of your suggestions tomorrow and see what happens 03:07
goodnight 03:09
chromatic good luck!
purl it has been said that good luck is all I can say.
03:23 tjh joined 03:42 cjfields joined 03:53 Zaba joined 04:08 Zaba_ joined 04:45 verve joined, Theory joined 05:09 Zaba joined 05:12 Ademan joined 05:24 iblechbot joined 05:25 Zaba joined
Tene I just pulled out all of the expr-parse and var-or-function mess in lolcode. 05:30
All tests pass.
purl Time to write more tests!
Tene purl++
05:32 verve joined
cotto_home purl++ indeed 05:38
05:40 Ademan joined 05:45 Psyche^ joined 05:50 teknomunk_ joined 05:52 Zaba_ joined 06:00 donaldh joined 06:12 uniejo joined 06:14 uniejo joined
dalek r29504 | fperrad++ | trunk: 06:21
: [install]
: - clean up test.php
diff: www.parrotvm.org/svn/parrot/revision?rev=29504
r29505 | fperrad++ | trunk:
: [Lua] shootout
: - more TODO & SKIP
diff: www.parrotvm.org/svn/parrot/revision?rev=29505
06:22 Zaba joined 06:23 bacek joined 06:32 UltraDM joined 06:35 Ademan joined 06:44 Zaba_ joined 06:54 barney joined 07:02 masak joined 07:06 Ademan joined 07:10 Tango_ joined 07:39 Zaba joined
dalek r29506 | bernhard++ | trunk: 07:42
: [build] remove directory OpLib with $(RM_RF) instead of $(RM_F)
diff: www.parrotvm.org/svn/parrot/revision?rev=29506
r29507 | bernhard++ | trunk: 08:08
: [test] Adapt test plan, as a test was removed.
diff: www.parrotvm.org/svn/parrot/revision?rev=29507
08:23 Zaba joined 08:35 Zaba_ joined
dalek r29508 | julianalbo++ | trunk: 08:45
: Fixed parrot_debugger test
diff: www.parrotvm.org/svn/parrot/revision?rev=29508
r29509 | julianalbo++ | trunk: 09:00
: Fix Revision.pm for non sh shells
diff: www.parrotvm.org/svn/parrot/revision?rev=29509
10:49 bacek joined 11:12 barney joined 11:13 kid51 joined 11:18 ruoso joined 11:25 iblechbot joined 11:26 bacek joined
dalek r29510 | bernhard++ | remove_getfd: 12:14
: #48312: [TODO] add get_fd method to ParrotIO
: add a TODO comment, referencing RT #48312.
diff: www.parrotvm.org/svn/parrot/revision?rev=29510
12:19 verve joined
dalek r29511 | jkeenan++ | parallel: 12:24
: Consolidate multiple test files per configuration step into a single file.
diff: www.parrotvm.org/svn/parrot/revision?rev=29511
12:31 masak joined 12:40 ruoso joined 12:41 Andy joined
dalek r29512 | bernhard++ | remove_getfd: 12:45
: [build] Some beautifications in Parrot::Ops2pm::Utils
diff: www.parrotvm.org/svn/parrot/revision?rev=29512
barney cotto_home: good point, there are too many unclosable tickets in RT 12:53
barney refered to cotto's reply to RT #40631 12:55
moritz aye, very good one 12:56
cotto_home thanks 13:07
13:09 gryphon__ joined
cotto_home I'd be glad to help find more such tickets 13:10
moritz I'm going through the perl6 queue 13:11
cotto_home do you have any suggestions on preventing them from being warnocked? 13:13
13:14 Zaba joined
moritz send at most 5 a day to the list ;-) 13:14
13:14 jhorwitz joined
masak what gets warnocked and what doesn't seems to be a very complex thing 13:15
I wanted to reply to pmichaud's closure mail, but I found I couldn't
so I took it up on IRC instead 13:16
moritz what prevent you from replying on list?
masak the fact that I thought that the answer was obvious :) 13:19
moritz ;)
masak even now, I have difficulty seeing the difficulty, even after pmichaud explained it to me
I wish it were as easy to implement the correct answers as it is to imagine them...
dalek r29513 | bernhard++ | remove_getfd: 13:21
: #48310: [TODO] remove the getfd opcode
: Remove the getfd opcode.
: Renumber the ops with tools/dev/ops_renum.mak
: Add implementation hints for method get_fd() in the ParrotIO PMC.
: Rewrite some tests in t/pmc/io.t, marking them as TODO, as there is get_fd method yet.
: Invalidate PBC by editing PBC_COMPAT.
: ===================================================================
: --- t/pmc/io.t\t(Revision 29488)
: +++ t/pmc/io.t\t(Arbeitskopie)
: @@ -1,10 +1,11 @@
: #! perl
: -# Copyright (C) 2001-2007, The Perl Foundation.
: +# Copyright (C) 2001-2008, The Perl Foundation.
: # $Id$
:
: use strict;
: use warnings;
: use lib qw( . lib ../lib ../../lib );
: +
: use Test::More;
: use Parrot::Test tests => 45;
:
moritz wtf?
szbalint hm
dalek : @@ -111,9 +112,11 @@
: a line
: OUTPUT
:
: -pasm_output_is( <<'CODE', <<'OUTPUT', "getfd/fdopen" );
: - getstdout P0
: - getfd I0, P0
szbalint I sense something went wrong with this one :)
dalek : +# RT#46843
: +pir_output_is( <<'CODE', <<'OUTPUT', "getfd/fdopen", todo => 'get_fd() not implemented yet' );
: +.sub main :main
: + getstdout P0 13:22
moritz anybody wants to kick dalek ?
dalek : + I0 = P0.get_fd()
: fdopen P1, I0, ">"
: defined I0, P1
: unless I0, nok
: @@ -122,14 +125,16 @@
: end
: nok:
: print "fdopen failed\\n"
: - end
: +.end
: CODE
: ok
: OUTPUT
:
: -pasm_output_is( <<'CODE', <<'OUTPUT', "fdopen - no close" );
: - getstdout P0
: - getfd I0, P0
: +# RT#46843
: +pir_output_is( <<'CODE', <<'OUTPUT', 'fdopen - no close', todo => 'get_fd() not implemented yet' );
: +.sub main :main
: + getstdout P0
: + I0 = P0.get_fd()
: fdopen P1, I0, ">"
: defined I0, P1
: unless I0, nok
: @@ -137,7 +142,7 @@
: end
: nok:
: print "fdopen failed\\n"
: - end
: +.end
: CODE
: ok
: OUTPUT
: @@ -454,22 +459,24 @@
:
: unlink("temp.file");
:
: -pasm_output_is( <<'CODE', <<'OUT', 'standard file descriptors' );
: +# RT#46843
: +pir_output_is( <<'CODE', <<'OUT', 'standard file descriptors', todo => 'get_fd() not implemented yet' );
: +.sub main :main
: getstdin P0
: - getfd I0, P0
: + I0 = P0.get_fd()
: # I0 is 0 on Unix and non-Null on stdio and win32
: print "ok 1
diff: www.parrotvm.org/svn/parrot/revision?rev=29513
cotto_home botfail 13:23
moritz no, barneyfail ;-) 13:24
szbalint actually, the bot just failed to limit the amount of text it's supposed to output from the commit log
cotto_home just noticed
moritz the commmit message contained the patch
jonathan ...well, that's one way to get more code review. 13:25
dalek r29514 | bernhard++ | remove_getfd:
: #48310: [TODO] remove the getfd opcode
: Adapt test description.
diff: www.parrotvm.org/svn/parrot/revision?rev=29514
r29515 | bernhard++ | remove_getfd: 13:28
: #48310: [TODO] remove the getfd opcode
: get rid of 'getfd' in languages/PIR.
diff: www.parrotvm.org/svn/parrot/revision?rev=29515
cotto_home moritz, what about a rt that depended on any uncloseable tickets 13:29
barney did everybody see the coding error? :=)
cotto_home that'd at least help with accounting
moritz cotto_home: make that dependency closable? 13:30
cotto_home barneyfail++
dalek r29516 | bernhard++ | remove_getfd:
: #48310: [TODO] remove the getfd opcode
: Get rid of 'getfd' in compilers/pirc. 13:31
diff: www.parrotvm.org/svn/parrot/revision?rev=29516
moritz ok, down to 45 tickets in the perl6 queue 13:32
cotto_home moritz, I don't know if such a ticket would be closeable, but it'd at least help get rid of other uncloseable tickets 13:34
it'd probably have to depend on itself ;) 13:35
masak is there a gsoc meeting today? in which channel is it? 13:36
moritz masak: it's in #perl6-soc on freenode 13:38
masak moritz: ah, thanks
moritz masak: yw. Mostly interesting for Perl 6 testing
masak I'm interested in Perl 6 testing 13:39
moritz good ;-)
masak what time will the meeting be?
moritz 19:30 UTC 13:40
which is 21:30 middle european time
masak excellent 13:43
cotto_home should unresolvable tickets be children or dependencies of the "too many unresolvable tickets" ticket? 13:47
barney children, they donÄt have to be resolved, in order to become resolvable 13:49
dalek r29517 | bernhard++ | remove_getfd: 13:54
: #48312: [TODO] add get_fd method to ParrotIO
: Add the method get_fd(), take code from the implemention
: of the removed opcode 'getfd'.
diff: www.parrotvm.org/svn/parrot/revision?rev=29517
cotto_home thanks 13:57
work &
dalek r29518 | coke++ | trunk: 14:00
: [tcl] use a tailcall
diff: www.parrotvm.org/svn/parrot/revision?rev=29518
r29519 | coke++ | tcl_pct: 14:09
: Remove experimental branch for converting tcl to PCT from scratch.
: A better approach will probably be to convert it in place to PCT,
: then begin adding optimizations, rather than starting over from
: scratch.
diff: www.parrotvm.org/svn/parrot/revision?rev=29519
14:34 Zaba_ joined 14:44 NotFound joined 14:52 sjansen joined
dalek r29520 | bernhard++ | remove_getfd: 14:53
: [codingstd] remove trailing spaces
diff: www.parrotvm.org/svn/parrot/revision?rev=29520
r29521 | bernhard++ | trunk: 14:58
: [docs] Rephrase recommendation of test before comitting.
: Especially mention 'make codetest'.
diff: www.parrotvm.org/svn/parrot/revision?rev=29521
15:04 cjfields joined 15:27 davidfetter joined
dalek r29522 | bernhard++ | trunk: 15:35
: Merge the changes from branch 'remove_getfd' back into trunk.
diff: www.parrotvm.org/svn/parrot/revision?rev=29522
15:39 cotto_work joined
davidfetter waves to cotto_work 15:41
dalek r29523 | tene++ | trunk: 15:42
: [lolcode]
: * Do everything at compile time. No more expr_parse.
diff: www.parrotvm.org/svn/parrot/revision?rev=29523
Tene That was a very satisfying commit
NotFound LOL! 15:43
moritz aye
do *everything* at compile time. Includes eating chicken at compile time ;-)
Tene Yes. 15:44
I need to do some crazy stuff for cardinal. 15:45
To get it to parse properly, I'll need to do similar lookups and symbol tables at *parse* time. 15:46
dalek r29524 | bernhard++ | trunk:
: Update TODO comment: RT#42373 is part of RT#48312.
diff: www.parrotvm.org/svn/parrot/revision?rev=29524
cotto_work davidfetter, hi 15:47
Tene I really should talk with pmichaud about it eventually.
moritz Tene: Perl 6 will need that too, for tracking type names 15:48
jonathan Tene: I think for Rakudo we'll...yes, moritz said it.
I want to do that in Rakudo soonish, but need to talk with PM first. 15:49
davidfetter cotto_work, any word from your cow orkers?
cotto_work no, but after lunch today will be a good day to ask them about it 15:50
davidfetter i'd really appreciate your help on this :) 15:51
cjfields jonathan: I found an odd issue when implementing match (method form of m//). Pretty sure it involves lexicals. 15:52
cotto_work one thing; your request is on how to make postgres more attractive to windows developers, right? 15:53
davidfetter yep
cotto_work that seems a little vague 15:54
davidfetter well, for example, it relies at the moment on automake, etc. for top-level developers
cotto_work so compatibility with windows build tools is a goal? 15:55
er, MS build tools
davidfetter compatibility is to some degree already there. "attractiveness" is a little closer
15:55 Theory joined
davidfetter as in, it's possible to build it using msvc 2008 or whatever it's called 15:56
oh, and apparently development *with* postgres (as opposed to *on* postgres) seems to have a few holes like lack of LINQ
any good refs on that?
davidfetter waves to Theory 15:57
jonathan cjfields: OK, either ticket it or write to perl6-compiler, and I or pmichaud can take a look.
Or anyone else with answers. :-)
cjfields I'll send it to p6-compiler then. May be something I'm not getting. 15:58
jonathan davidfetter: LINQ is awesome; I can hardly imagine .Net dev without it any more.
cotto_work davidfetter, I'm clue-poor in that area, but pgsql LINQ and building with MS tools sound like some good concrete goals.
dalek r29525 | bernhard++ | remove_getfd:
: Delete branch after merge with trunk.
diff: www.parrotvm.org/svn/parrot/revision?rev=29525
davidfetter cotto_work, thanks for helping me refine my questions :)
jonathan I know that the way LINQ is architected is meant to allow other DBs to be able to implement "drivers" for it.
Theory heya davidfetter 15:59
purl davidfetter is looking to put together PL/Parrot
cotto_work davidfetter, anything else you'd like to see happen?
davidfetter cotto_work, those would be gigantic by themselves 16:00
cotto_work, although of course sponsorship, inclusion in ms products, etc. would be nice, too ;)
cotto_work ok. I'll send of a mail and do a meatspace poke later today
davidfetter ms has a very long history of using bsd-licensed code :) 16:01
cotto_work It's very corporate-friendly.
davidfetter, do you know of someone who'd be able to implement either of those requests, or is finding those people the issue? 16:08
barney heads for Munich Perl Monger meeting 16:10
16:12 mj41_ joined 16:17 iblechbot joined 16:31 Tango_ joined 16:35 rurban joined
rurban parrot-0.6.3-1 is now officially included cygwin, 0.6.4-1 still needs some care (today or tomorrow) 16:35
NotFound rurban++ 16:43
rurban thanks for the new name parrot_debugger btw. 16:46
It came just in time for me. I still haven't checked if it was patched correctly. I found a lot of missing places in my first patch today. 16:47
man(1) pages somewhen planned? And how?
16:49 cj joined
rurban And I want to discuss the libparrot_shared name for cygwin: I found an very old patch (warnocked) which renames it to cygparrot$major_$minor.dll. I did it now too. 16:49
oops. even major_minor_subrelease.dll. I just do $dllsuffix = join("_",@parrot_version); 16:51
16:53 bgeron left
rurban My next work is now to remove the funky /usr/runtime/parrot/include /usr/runtime/parrot and /usr paths from the .include searchpath. I found this via strace and looks wrong. 16:54
NotFound rurban: open a ticket for discussing that. 17:01
The dll renaming, I mean. 17:02
rurban just did
17:03 masak joined
rurban hmm, subrelease is officially called PATCH in config_lib.pasm. I would expect PATCH to be the subversion revisionlevel (.parrot_current_rev) 17:13
Tene What was the problem with pdb? 17:15
Well, with "pdb"?
rurban that /usr/bin/pdb alrady exists
the python debugger, and on IBM machines the portable debugger
Tene ah
rurban of course you can always symlink it to pdb 17:16
(in case you avoid python :)
And disassemble was also a bit to broad for general packaging 17:18
NotFound rurban: PATCH is taken from the VERSION file. 17:19
17:19 chromatic joined
rurban NotFound: I know. Just a split of ".". But the key in the config hash is a bit strange. 17:20
Anyway. I'm not bothered too much. It just looked strange at first sight. 17:21
NotFound rurban: the intention, as I hear recently, is that svn release number are not included in distribution packages. 17:23
rurban perl5 names the third version digit PERL_SUBVERSION, and the PERL_PATCHLEVEL is the revision number.
NotFound: Empty svn release numbers are okay. This is the same everywhere. You have to see iin a bugreport if its a development version or a release. 17:24
particle if we include a revision number, it'll be called _REVISIONNUMBER and not _PATCHLEVEL
that's just silly
rurban hmm. 17:25
perl5 naming: version_patchlevel_string='version 11 subversion 0 patch 34136'
particle we have major minor patch 17:26
rurban perl6 naming: minor 6 patch 3 revision 29497
particle parrot naming, not perl 6 naming
rurban ah sorry, yes.
Anyway, too late. 17:27
particle sure
there's always next time :)
rurban It just looks odd.
NotFound The name 'subversion' is also confusing in the current development model.
rurban :)
particle perl5 uses perforce, so it's not confusing to them
but, yes, it's an unfortunate name
NotFound We can call it perforce number, to counter attack X-) 17:28
rurban The perl5 names are also questionable: it should be version_patchlevel_string='minor 11 subrelease 0 patch 34136'
NotFound We have enough own items to discuss, let perl5 ones alone. 17:29
rurban ok. I'll finish now the parrot-0.6.4 release for cygwin...
And then I'll start fixing the makefiles to add LD_RUN_PATH/PATH=pwd/blib/lib to each parrot call. This is the last quirks I see. 17:31
17:34 Theory joined
rurban Where can I set at perl5 Configure.pl breakpoint to fix auto::opengl::_add_to_libs() ? 17:45
japhb rurban: huh what? (This window just pinged me, probably because you mentioned OpenGL) 17:47
(And sorry I have not dealt with OpenGL issues in the last week, $real_life interfered)
rurban BTW: There are way too many gcc -W switched in effect. Most of them are already implied by -Wall and -Wextra. Should I open a ticket with my list?
japhb: I want to get rid of the logic preferring not existing native mingw libs over existing cygwin glut libs. 17:48
japhb OK, give me a sec to pull up auto::opengl and reacquaint my brain 17:49
particle rurban: config/auto/opengl.pm
rurban That's the easy part. I also provided a pach, but this doesn't work. 17:50
perl -d Configure.pl ....
NotFound rurban: not all gcc versions support -Wextra
japhb rurban: OK, right, was this about the fact that you and donald hunter chose different ways to get your OpenGL support? (One of you choosing X11, the other choosing native libs?)
NotFound: do we have to support those gcc versions? 17:51
rurban I can only take X11 because I only have them and I have to assume for the cygwin package that all others also have no native mingw libs.
Privately I'm fine with the native libs, because I'll need no X then.
NotFound japhb: if the price to pay is having some extra args, I will pay it.
rurban NotFound: I read info gcc => Invoke => Warnings and read that most of the switches are not needed. gcc-3.4.4 so quite old. 17:52
some paste: TODO: 17:53
remove warnings implied by -W -Wall:
-Wchar-subscripts -Wcomment -Wformat -Winit-self -Wimplicit-int -Wimplicit-function-declaration -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wswitch-default -Wtrigraphs -Wstrict-aliasing
-Wnonnull (implied by -Wformat also)
-Wimplicit (same as -Wimplicit-int -Wimplicit-function-declaration)
unclear: -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k
japhb NotFound: I wasn't arguing that. I was asking if we were supporting the old gcc's in one place (the flags list), but not in another (say, src/), for hysterical raisins. Just like we have discovered in the past that we were actually requiring newer perls, so sops to ancient perls were just historical cruft.
rurban ok -W -Wall -Wextra -Waggregate-return -Wcast-align -Wcast-qual -Wdisabled-optimization -Wendif-labels -Wimport -Winline -Winvalid-pch -Wno-missing-format-attribute -Wpacked -Wpointer-arith -Wno-shadow -Wsign-compare -Wstrict-aliasing=2 -Wundef -Wunknown-pragmas -Wno-unused -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wmissing-declarations -Wmissing-prototypes...
...-Wnested-externs
And I'm annoyed about the debugging into the Configure runstep hierarchy 17:55
DB<3> b Parrot::Configure::Step::auto::opengl::runstep 17:57
Subroutine Parrot::Configure::Step::auto::opengl::runstep not found.
Or cannot I just override the opengl libs that in hints/cygwin.pm? Ugly though. 17:58
japhb rurban: I don't think you need to breakpoint in runstep. You want _add_to_libs, which is in one of the superclasses. 18:00
Looks like Parrot::Configure::Step::Methods 18:01
rurban I see. I'm in the same boat as mingw. 18:02
win32_gcc is both
can I have a specialcase cygwin platform there? I'll write such a simple patch. The fallback for cygwin would be either win32_gcc or default. 18:03
japhb rurban: And I don't think this should be in hints/cygwin.pm, at least not directly. donaldh pointed out last week that cygwin can *either* use packages w32api + opengl *or* xorg-x11-* + libglut*. Which is a pain in the keister. And mixing them, as he pointed out, blows up. 18:04
rurban I'll rather prefer probing the libs as in a real Configure
As that done somewhere. So we can please everybody.
sorry: Is that done somewhere? 18:05
japhb rurban: how do you propose to probe the libs?
rurban well, bash magic :)
no, of course not. search some libpaths for my special platforms.
NotFound japhb: don't know about that, don't have any at hand to test. 18:06
18:06 Ron joined
japhb NotFound: "that" == what? 18:06
NotFound japhb: old gccs
japhb NotFound: ah, gotcha, wrong continuation. :-)
rurban but we already know the gcc version from Configure 18:07
japhb rurban: I don't relish the debugging when we change our warnings list based on gcc version (especially when a new version arrives). 18:08
NotFound rurban: I think redundant flags do not harm, and trying to avoid them will be a boring and error prone task.
japhb (... and someone gets a warning on a gcc none of us has, so can't replicate)
rurban hmm. my commandline looks pretty long now, I'm worried that it well get too long without noticing 18:09
NotFound rurban: Are you compiling in ms-dos or something? ;)
rurban stupid windows shells of course only
japhb Isn't the limit something fairly large like 4K?
rurban I'm on a bash on cygwin 1.5. cygwin-1.7 will be much better 18:10
Where should paste my -Wall findings to? perl6-internals? 18:11
So that the next will not have to wade through gcc docs again 18:12
NotFound rurban: I don't see the need to worry about that. We can just add a note "Don't worry about redundant flags" in the gcc config part. 18:14
rurban At my $ccwarn = $conf->data->get('ccwarn'); as comment in the code just? 18:15
NotFound In the section with the list of flags to add an test will be better, I think. 18:16
japhb rurban: (opengl) if you include a -lfoo on a cygwin or mingw gcc command line, and 'foo.dll' and 'libfoo.dll' don't exist, what happens? 18:17
rurban unresolved symbols error. I konw what you mean. you dirty... 18:18
put it all together... I'm testing this
japhb rurban: having any luck? 18:30
rurban wait a bit...
-licuuc -licudata -lpthread -lm -lnotexists -lopengl32 18:31
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lnotexists
collect2: ld returned 1 exit status
too bad.
No, I'm happy with fixing the lib detection logic. 18:32
For I've just removed the cygwin case for win32_gcc so thatI will fall back todefault, which is better for the package, but not for svn. 18:33
s/For /For now/
18:34 Theory joined
japhb rurban: explain? 18:37
You're doing something different in the cygwin package than what you have checked in?
rurban sure. my src.patch is already 53kb 18:38
japhb eww
rurban the 0.6.3 patch was just 46kb
It's so big because of all the binary renamings. The rest is tools/dev/install_files.pl which is broken 18:39
The ffi names pointing to non-existing dll's need also to be fixed for cygwin 18:40
And some improtant patches were forgotten in 0.6.4, such as the cygwin jit fix. 18:41
NotFound I've found that I still have a gcc-3.4 Not very old, but I tested building with it, and no problem. 18:42
rurban the implib patch (import library), the recent parrot_debugger renaming, ...
the cygwin dll naming, ... 18:43
particle i don't expect to support parrot on any gcc older that 3.4 18:44
chromatic and 3.x probably only because Mac OS X and OpenBSD haven't finished moving to 4.x yet. 18:45
particle yep
NotFound particle: you're luck that at my work they recently retired the last hp-ux 10.20 system, I had a 2.9 on them X-) 18:46
japhb chromatic: What are OS X and OpenBSD still using 3.x for, anyway? I thought OS X had run 4.x for a while now ... 18:48
chromatic japhb, I don't know about 10.5, but with 10.4 gcc 3.x was still an option.
rurban japhb: I have now a good opengl cygwin compromise patch. I'll add to to the tracker.
cjfields OS X 10.5 uses gcc 4.0.1
japhb rurban: cool, I'll look for it.
chromatic OpenBSD ... well, they're writing their own version of CVS. I'll stop there.
japhb squeezes his eyes shut in pain 18:49
That's just ... disturbing.
davidfetter chromatic, ugh
szbalint instead of letting CVS die a pensioner's death...
davidfetter and going with a DSCM would be bad is wrong because...?
japhb It's amazing how sometimes brilliant people have a mental block about something very, very wrong. 18:50
davidfetter er, s/would be bad//
japhb davidfetter: Just taking a random guess, perhaps because they don't feel they could do a full security sweep of something as big as a DSCM?
NotFound gcc-3.4 build pass all test. Want a smoke? 18:51
davidfetter thinks people who imagine they can do a "full security sweep" of *anything* are delusional
japhb davidfetter: OpenBSD does iterative sweeps. Every time a new class of bug is discovered, they sweep their entire code base for it. And any time a piece of code is too complex to feel like they can secure it properly, they rewrite. 18:53
davidfetter what happens when they find a class break in TCP? 18:54
or DNS?
purl rumour has it DNS is the way to hack the Internet
moritz davidfetter: pray they don't ;-)
japhb They're more than a bit nutters, but then again they often get to go 'nya-nya-nya-nya-nyaaaah' every time other distros say 'I didn't know you could do *that* to *that* ...'
davidfetter: You mean a fundamental design flaw? Like the one from last week? 18:55
davidfetter japhb, yep
moritz
.oO( they fix it? )
japhb davidfetter: half the time, their paranoia means that the bug could never have been exploited on their system. Just like djbdns was not exploitable, because DJB had long ago said 'randomizing source port is just good layered security, even though I don't know what I'm protecting against'. 18:56
davidfetter "security" like "meaning" is not context-free 18:57
japhb That's why, for instance, long ago OpenBSD went to randomized process IDs. Because too many people think a process ID is a good random seed, and they're wrong.
davidfetter so saying something is just generally "good security" is missing the point
randomizing process ids is good, but only in the context of that threat model :) 18:58
japhb davidfetter: Sure. But you can say 'fits a pattern of known good security practices in other places'
moritz but you have to admit that they have very good ideas from time to time ;-)
davidfetter fair enough
japhb OK, popping that discussion off the stack ... we clearly support gcc 3.4. How much older than that do we still support? 19:00
rurban 3.3 ?
particle no
davidfetter stack? i thought we used registers here ;)
particle and don't even ask about 2.7
NotFound Smoke passed and sended for 3.4 19:01
rurban 2.95 is still quite popular in academia
chromatic Academia should freakin' go outside once in a while.
japhb chromatic++
chromatic HELLO FROM THE 21ST CENTURY PLEASE JOIN US THE WATER IS FINE
rurban then they would get some fresh air. better not
NotFound What academia? Plato's one?
japhb davidfetter: OK, I mark the PMC holding that conversation continuation for garbage collection ... 19:02
davidfetter heh 19:03
rurban Another packaging thingo. I believe it's good to add a local_patches list to myconfig, as with perl5 local_patches[] 19:04
So that you (and I ) can identify bugreports
dalek r29526 | coke++ | trunk: 19:15
: [tcl] update XXX comment regarding HLL_map issue in [list]
diff: www.parrotvm.org/svn/parrot/revision?rev=29526
rurban I have to go now. Bye! 19:16
moritz #perl6-soc now (if pmichaud or particle are around) 19:31
19:35 Zaba joined 19:46 Ademan joined 19:54 donaldh joined 20:13 moritz joined 20:19 Zaba joined
dalek r29527 | julianalbo++ | trunk: 20:31
: add an assertion to src/debug.c
diff: www.parrotvm.org/svn/parrot/revision?rev=29527
20:38 sjansen joined, rurban_ joined 20:41 Zaba joined 20:47 Whiteknight joined
dalek r29528 | Whiteknight++ | gsoc_pdd09: 20:48
: [gsoc_pdd09] a few small changes I made while debugging
diff: www.parrotvm.org/svn/parrot/revision?rev=29528
20:49 Ademan joined
dalek r29529 | Whiteknight++ | gsoc_pdd09: 20:52
: [gsoc_pdd09] update to trunk r29527
diff: www.parrotvm.org/svn/parrot/revision?rev=29529
21:04 Zaba joined 21:05 bacek joined 21:17 Limbic_Region joined 21:25 cjfields joined
cjfields chromatic++ (and that's coming from an academic) 21:26
dalek r29530 | julianalbo++ | trunk: 21:38
: some more work in debugger
diff: www.parrotvm.org/svn/parrot/revision?rev=29530
21:49 AndyA joined 21:55 sjansen joined 22:01 slightlyoff joined
dalek r29531 | julianalbo++ | trunk: 22:02
: codingstd in debug.c
diff: www.parrotvm.org/svn/parrot/revision?rev=29531
22:05 slightlyoff left
Tene pmichaud: ping 22:06
22:08 Zaba_ joined
Limbic_Region pmichaud ping 22:09
Tene HAY I PINGED HIM FIRST
Limbic_Region FILO
NotFound drop icmp echo
Tene Limbic_Region: so if I ping him again, I get another spot on the stack? 22:10
chromatic No stack; it's asynchronous CPS. 22:12
22:14 YorkeAndVedder joined 22:16 teknomunk joined 22:17 YorkeAndVedder left 22:31 Zaba joined 22:38 kid51 joined 22:44 ruoso joined
dalek r29532 | jkeenan++ | parallel: 23:02
: Add inline comments to clarify what each section of file is doing.
diff: www.parrotvm.org/svn/parrot/revision?rev=29532
r29533 | Whiteknight++ | gsoc_pdd09: 23:07
: [gsoc_pdd09] Add in a new last-first finalizing algorithm. Segfaults worse then before.
diff: www.parrotvm.org/svn/parrot/revision?rev=29533
r29534 | jkeenan++ | parallel: 23:13
: Adjust POD in '=for' block.
diff: www.parrotvm.org/svn/parrot/revision?rev=29534
23:16 Ademan joined 23:23 bacek joined 23:27 teknomunk_ joined
dalek r29535 | coke++ | trunk: 23:36
: [tcl] Make this function more maintainable (get rid of old PASM style var
: names, splitting them up into saner chunks.)
diff: www.parrotvm.org/svn/parrot/revision?rev=29535
r29536 | coke++ | trunk: 23:38
: [tcl] code.google.com/p/partcl/issues/detail?id=58
: Rename to avoid many (but not all) '__foo' style names
diff: www.parrotvm.org/svn/parrot/revision?rev=29536
23:47 teknomunk__ joined 23:49 davidfetter joined
chromatic "Segfaults worse than before" made me laugh a sad, sardonic laugh. 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!