www.parrotcode.org/
Set by moderator on 12 July 2009.
00:32 lordk joined
lordk Hello? 00:33
purl Raise your hand in the back if you can't hear me.
lordk i cant here yous
Ello dare
*there
do you know if any parrot devs are here
00:33 brooksbp joined
lordk beacuse i cant find a graphics libary 00:34
and that annoys me
badly
purl i cant here you if your usein a audio chat system
purl lordk: i'm not following you...
lordk oh
well i need a libary to write stuff to the screenbuffer 00:35
you know
like images
and text
and fractias
like the print command
except for png
... 00:36
soo tiering
bacek_at_work lordk: purl is bot. Sometime very annoying :)
purl: good girl 00:37
purl :)
lordk ah
dam
thats annoyin
but do you know of the elsuive lib im serchin for
because trying to rewrite a dead dialect of basic is hard when its for graphics
purl bad dog 00:38
purl lordk: excuse me?
lordk purl die or die
purl lordk: i'm not following you...
lordk purl log off
purl lordk: sorry...
lordk purl DO IT
purl lordk: i'm not following you...
lordk .. 00:39
this place is dead...
brbrooks seen Whiteknight 00:40
purl Whiteknight was last seen on #parrot 1 hours, 43 minutes and 20 seconds ago, saying: it goes down pretty often unfortunately
brbrooks hah 00:41
jdv79 what is "it"? 00:43
purl "it" is almost never used as a noun, so who cares what its plural is?
Coke purl, forget it 00:46
purl Coke: I forgot it
00:54 chromatic joined
dalek rtcl: r533 | coke++ | wiki/SpecTestStatus.wiki:
Update SKIP notations, including some new regressions.
 00:58
01:01 hiroyuki_y joined 01:08 patspam joined 01:15 Whiteknight joined
brbrooks Whiteknight: any update since the gc_inf patch yesterday? 01:17
Whiteknight brbrooks: It's committed to trunk now 01:19
so, I guess that qualifies as "news"
and I fixed the bug I was running into last night
01:21 patspam joined
brbrooks What's with the headerizer? Does it just automatically create function defs? and the ASSERT_ARGS macros? 01:26
01:40 kid51 joined
dalek rrot: r40040 | jkeenan++ | trunk/tools/dev/install_files.pl:
Small regex correction.
 01:43
01:46 szabgab joined
dalek rrot: r40041 | jkeenan++ | branches/io_cleanups/src/pmc/handle.pmc:
Conform to coding standards: c_parens.
 01:59
rrot: r40042 | jkeenan++ | branches/io_cleanups/src/pmc/handle.pmc:
Improve some POD formatting.
 02:06
rrot: r40043 | jkeenan++ | branches/io_cleanups/src/io/unix.c:
Provide minimal documentation for one function so that file conforms to coding standard: c_function_docs.
 02:13
kid51 Infinoid: ping 02:14
msg Infinoid Did some codingstd cleanup in io_cleanups branch, please 'svn up'. src/io/socket_unix.c and src/io/socket_win32.c fail the c_indent test (preprocessor) -- but that's as much a deficiency of the test as of the code. 02:16
purl Message for infinoid stored.
Infinoid thanks 02:19
02:42 janus joined 02:53 eternaleye joined, Andy joined
dalek cnum-dynpmcs: r107 | darbelo++ | trunk/ (8 files):
Some changes to the testing infrastructure.

   Change all #! lines to something a bit more useful.
   Change the include path for the library.
If you have an installed parrot available on your $PATH variable, then you're all set up for make test.		 03:14
purl dalek: that doesn't look right
purl dalek: that doesn't look right
cotto < purl-- > 03:20
botsnack
purl thanks cotto :)
cotto feels sneaky
not that it's hard to trick purl or anything
darbelo cotto, ping 03:23
cotto darbelo, pong 03:28
cotto is learning himself a Haskell
darbelo I just commited some changes to the tests and the way they run. If you get the time try out make test and msg (or nopaste) me the results. 03:30
cotto The nice thing about your project is that make realclean && perl Configure.pl && make takes so little time 03:31
darbelo If I did this right all you need to test (or build) are "parrot" and "parrot_config" executables on your $PATH. 03:32
cotto The tests are failing pretty epically. Let me check if it's possibly my fault.
darbelo We're still failing 176/3689, I'll star TODO-ing them once I'm sure they're library issues and not my fault 03:33
nopaste "dabelo" at 190.3.141.124 pasted "This is actually the closest we've come to succsess." (19 lines) at nopaste.snit.ch/17236 03:35
cotto I'm seeing 72 failures.
darbelo I have 72 failures just on subtract.t over here. 03:36
cotto Failed 72/647 tests, 88.87% okay
darbelo Hmm. That's what it prints after it finishes a file. You should get something similar to my nopaste after that. 03:38
cotto I seem to be running a lot fewer tests than you.
darbelo, you're right
Failed 4/6 test scripts. 176/3689 subtests failed.
looks good 03:39
darbelo Now I just have to manually verify and TODO 176 tests. Lucky me! 03:40
cotto Yay!
darbelo Oh, and while you are still here. I'm going to start writing some basic user-level docs. Do you think the google code wiki is a good place to put them? 03:43
cotto Personally I'd stick them in with the source but the wiki works too. 03:44
darbelo The google code wiki is also accessible from svn, look at code.google.com/p/partcl/source/browse/#svn/wiki 03:48
cotto It's your call. I'm happy as long as the docs exist and are reasonably up-to-date. 03:51
Also, thanks for being responsive to my msg. The test changes should make life better for users. 03:53
darbelo++
What are you thinking about a PCT-based test suite? 03:54
darbelo I'm still not sure wether I want to convert decTest files to PIR or a decTest interpreter. I wake up wanting a different one every week. 03:56
03:58 cottoo joined
darbelo Right now I want to translate to pir and have a bunch of generated .t files in the repo. 04:00
cotto irclogs 04:02
irclogs?
darbelo realizes that it's been Monday for and hour on his timezone.
purl it has been said that irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
cotto It's your call how to do it. An interpreter would mean fewer troubles with PCT (since that's closer to what it's been designed for). 04:05
Actaully, there's no compelling reason I can think of to have a test->pir converter. If the user's running make test, he's already got a working Parrot install. 04:06
but if it's 0100 in your corner of the world, you should probably wait for sleep to make the decision.
darbelo Having an interpreter means users have to build the interpreter just to test the PMCs, with the decTest->PIR converter they get the generated file and just run them. 04:08
I think I'll go to sleep and see what I wake up wanting this week :) 04:11
cotto The test suite is already pretty big. I don't think the extra time will be much of a burden.
do that
good night 04:12
darbelo Unrelated thought: has tewk (he was the other GSoCer, right?) resurfaced? Midterm evaluations close this week.
cotto I know. I haven't heard anything about his project. I'm not optimistic.
darbelo Ouch. 04:14
cotto It'd be a pity because he's obviously capable.
I guess it'll make a good #ps question. 04:17
04:17 Zak joined
dalek rdinal: 430ad39 | (Ted Reed)++ | src/classes/Array.pir:
Fix Array.uniq to use a hash.
 04:45
rdinal: f022fb8 | (Ted Reed)++ | src/classes/Array.pir:
Add the ability to pass a block to uniq to munge the items before matching. Apparently this is a feature only otherwise found in Ruby SVN. Ah, well.
 06:08
06:12 uniejo joined 06:34 iblechbot joined 06:54 mokurai left 07:06 jan joined 07:21 patspam joined 08:09 barney joined 08:36 janus joined 09:10 Eevee joined
mikehh All tests PASS (pre/post config, smolder, fulltest) r40043 - Ubuntu 9.04 amd64 09:19
09:31 donaldh joined 09:38 bacek joined 09:41 mikehh joined 09:50 Eevee joined
bacek o hai 10:02
dalek rrot: r40044 | bacek++ | branches/ops_pct/src/pmc/fixedstringarray.pmc:
[pmc] Implement FSA.get_number.
 10:03
mikehh hi bacek 10:04
bacek hi mikehh 10:05
purl somebody said hi mikehh was still getting some weird results on Kubuntu Intrepid Amd64 - TT#412
bacek purl: forget mikehh
purl bacek: I forgot mikehh
mikehh :-}
Infinoid forget hi mikehh 10:07
purl Infinoid: I forgot hi mikehh
Infinoid hi mikehh
:)
mikehh hi Infinoid 10:08
10:10 masak joined 10:31 Khisanth joined 11:08 TiMBuS joined 11:09 gaz joined 11:20 donaldh joined 11:22 cognominal joined
dalek rrot: r40045 | fperrad++ | trunk/config/gen/makefiles (2 files):
[build] files generated by Configure.pl must be removed only by target 'realclean'
 11:26
11:33 AndyA joined 11:37 skids joined
dalek rrot: r40046 | bacek++ | branches/ops_pct/compilers/nqp (2 files):
[nqp] Fix quoting of multi-words. Add more tests
 11:43
rrot: r40047 | bacek++ | branches/ops_pct (2 files):
[opsc] Split opsc.pir into 2 parts for simplify testing.
rrot: r40048 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
[opsc][t] Add test for future ops files parsing.
11:46 kid51 joined 12:03 Whiteknight joined
Whiteknight good morning #parrot 12:11
kid51 good morning whiteknight 12:13
dalek rrot: r40049 | bacek++ | branches/ops_pct/compilers/opsc/ops/oplib.pm:
[opsc] Remove redundant call to parse_ops_file.
 12:14
bacek good morning Whiteknight, kid51
Whiteknight good morning, bacek and kid51
bacek Bah! "good mor<tab>" expands to "good moritz". Bad sign... :) 12:15
dalek rrot: r40050 | bacek++ | branches/ops_pct/compilers/opsc/builtins.pir:
[opsc] Add slurp to builtins
 12:17
rrot: r40051 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
[opsc] Initial implementation of parse_ops_file
bacek msg cotto Look! trac.parrot.org/parrot/browser/bra...arse_ops.t It's beautiful :) 12:24
purl Message for cotto stored.
12:31 HG` joined 12:48 Andy joined
dalek rtcl: r534 | coke++ | trunk/docs/spectest- (2 files):
Doc latest spectest run - several test file regressions and a slowdown.
 13:03
moderator www.parrot.org/ | 292 RTs left | Next release: 2009-07-21 13:10
dalek rrot: r40052 | bacek++ | branches/ops_pct/compilers/nqp/src/Grammar/Actions.pir:
[nqp] Implement regex quoting.
 13:18
rrot: r40053 | bacek++ | branches/ops_pct/compilers/opsc/builtins.pir:
[opsc] Borrow old PIR based "split" from Rakudo.
rrot: r40054 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
[opsc] Borrow code from Ops2pm for parsing ops.num and ops.skip files
rrot: r40055 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
[opsc] Implement parsing of skip file
 13:36
13:41 MoC joined 13:49 Andy joined
dalek rrot: r40056 | bacek++ | branches/ops_pct/compilers/opsc/ops/oplib.pm:
[opsc][cage] Remove commented-out code.
 13:53
13:56 PacoLinux joined
Coke (anyone who has fixed a memory leak)++ 13:58
bacek Coke: which one? 13:59
Coke I don't know.
bacek Anyway. It wasn't me. I spent time trying to keep memory from angry GC. 14:00
Coke But I was just able to run a tcl spec test that previously leaked.
(to death)
dalek rrot: r40057 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
[opsc] Add hash() to builtins. Made OpLib.BUILD more perlsish
bacek Coke: btw, #776 can have some good progress. A lot of GC related stuff was fixed recently. 14:04
Coke bacek: 776 isn't GC related is it? 14:06
bacek "segfault in Parrot_str_equal..." looks like closely related to GC. 14:07
But I can be wrong.
Very wrong.
As usual.
*sigh*
bacek start crying and moving to bed. 14:08
Coke I can double check it later.
bacek Sleep time. It's tomorrow already
Coke ~~
bacek msg cotto Jump on ops_pct! It's waiting for some love :) 14:10
g'night Coke
purl Message for cotto stored.
14:14 skids joined
Coke is there some way I can tell the GC to show me where everything is rooted? 14:22
something in tcl is holding onto PMCs too long, I think. 14:23
14:23 iblechbot joined
Whiteknight Coke: not at the moment, no 14:24
although some sort of visualization plugin might be very cool to have
Coke Whiteknight: in the meantime, feel free to track down these segfaults for me. :| 14:25
Whiteknight what segfaults?
purl No whammies!
Coke partcl's dict.test and expr.test spectests. 14:26
they segfault after 5 or 10 minutes without completing.
Whiteknight urg 14:27
Coke rerunning expr.test under gdb now, will check back in 20m. :|
14:35 Theory joined 14:47 mokurai joined
Coke if anyone can suggest more information to extract for TT #831, I'd appreciate it. 15:09
dalek TT #831 created by coke++: segfault in clone_key_arg
15:20 donaldh joined
Coke Whiteknight: there, a segfault in *malloc. =-) 15:39
Whiteknight w00t 15:40
so that means the heap is getting corrupted somewhere
dalek TT #832 created by coke++: segfault in _int_malloc 15:41
Coke I still have that gdb session open, if I can get anything from it, let me know.
Whiteknight nothing that I can think of right now 15:56
16:04 Psyche^ joined
mj41 Whiteknight: Another odd result on my 64bit Linux machine. t/op/gc.t test 4 start failing in r39993 ... tt.ro.vutbr.cz/report/pr-Parrot/do?...un-5982=on 16:21
Whiteknight mj41: that's in trunk right now with the MS collector activated? 16:22
pmichaud good morning, #parrot
Whiteknight good morning pmichaud 16:23
dalek kudo: 03bc9da | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 415 files, 11796 passing, 0 failing
 16:31
pmichaud Memo to all of the gc bug hunters.... "Thanks!!!" 16:32
pmichaud points at "0 failing" and does a celebration dance.
Coke pmichaud: now it's my turn. =-)
16:32 ujwalic joined
Whiteknight holy shit, is it fixed? 16:33
It was still failing when I checked it yesterday
pmichaud Whiteknight: for the past two days I haven't been seeing any obvious gc-related bugs
Whiteknight I wonder what was happening about that one bug I was trying to track down?
pmichaud we still have the abort-on-exit failures, but I think those are exception bugs and not gc ones
the one you were trying to track down is the abort-on-exit one 16:34
it's still there, but my bug-counting-script doesn't treat it as a failure
Whiteknight oh, okay
pmichaud (all of the tests passed, so it counts them as such. It's just that Parrot dies on exit)
(so we don't consider that a Rakudo bug at the moment for spectest purposes)
Whiteknight is there a ticket for this abort-on-exit thing? I have information I can probably add to it
pmichaud I don't think there's a ticket. But I was able to narrow it down to a simple test case 16:35
Whiteknight I CAN HAZ SIMPLE TEST CASE?
:)
pmichaud looking
Whiteknight Because I've been using failing spectests in my work, and that's a pain
pmichaud nopaste.snit.ch/17227 16:36
that seems to always produce the abort-on-exit
Whiteknight okay, yeah, I was using a snippet like that for a while
what's interesting is that both of those two statements need to be there, although can be in any order 16:37
pmichaud the problem has to do with errors in evals for code that also has BEGIN semantics
Whiteknight either one by itself doesn't fail
pmichaud right
Whiteknight okay
what's interesting is that the failure does indeed happen towards exit time, but the failure happens inside IMCC 16:38
so something is calling into IMCC after the script has completed
pmichaud ....failure happens inside IMCC? 16:39
oh!
it's probably not finding 'self'
Whiteknight yeah, let me see if I can find the backtrace that I nopasted 16:40
irclogs?
purl hmmm... irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
pmichaud so, I wonder...
Whiteknight nopaste.snit.ch/17216 16:42
16:42 bruce joined
Whiteknight you can see the PIR snippets passed into IMCC during the error, which happens after those segments are already compiled and executed (because the test prints "ok") 16:43
nopaste.snit.ch/17220 <-- And this is one of the PIR snippets being passed into IMCC that starts the fail train in motion 16:44
pmichaud ...that's the whole bit of PIR that is being compiled?
or just an excerpt ?
Whiteknight the whole thing 16:45
purl the whole thing is, like, confounded
16:46 ruoso joined
Whiteknight I don't think it appears in the backtrace, but in gdb I compared the string lengths to make sure it was the entire string 16:46
pmichaud I don't see anything there that would cause IMCC to fail
perhaps it's failing from within the load sub 16:47
hmmm.
Whiteknight well yes, it's failing in the :init sub
pmichaud which :init sub ? ;-)
Whiteknight (which is the :load sub, but gets executed because of the :init flag)
pmichaud and :init shouldn't matter
:init only matters for files run from the command line, which this one isn't.
16:48 Bruce joined
Whiteknight maybe that's the only time it *should* matter 16:48
but the function is being executed because of the :init flag in IMCC when it's compiled
pmichaud that's wrong.
purl pmichaud is channeling thoth!
pmichaud or I'm misremembering. One second. 16:49
(I'm probably misremembering.)
Whiteknight this then causes a segfault because the contexts are screwed up and it can't find the signature object
I think you're thinking about :immediate
or :postcomp
pmichaud no
:load subs get executed when something is done via :load
:init subs get executed ... 16:50
okay, you're correct
including when compiled from memory
for some reason I _always_ get that backwards :-)
so yes, because of the :init flag
Whiteknight right, so the :init function executes (I don't know which of the two in that snippet), it goes to handle the return value but can't find the signature object and crashes 16:51
now, I tried out a patch that prevented searching for return values from an :init sub, but then there was a segfault
so somewhere the context stack is getting corrupted 16:52
pmichaud okay, I have a PIR example.
Whiteknight !!!
pure PIR, or PIR with Perl6 PMCs and runtime and stuff?
pmichaud pure PIR
Whiteknight oh w00t 16:53
nopaste "pmichaud" at 72.181.176.220 pasted "Pure PIR example showing abort-on-exit failure" (74 lines) at nopaste.snit.ch/17242 16:54
Whiteknight oh wow, that's bizarre 16:55
I have a suspicion that we can even trim that example down a little bit
pmichaud oh, we probably can 16:56
Whiteknight well, maybe it wouldn't be as instructive
pmichaud but the problem has to do with exceptions being thrown from within imcc
Whiteknight ah, that makes more sense then 16:57
how did you figure that out? 16:58
I'm probably missing some necessary information about the Perl6 runtime
nopaste "pmichaud" at 72.181.176.220 pasted "more abort-on-exit-failure description" (88 lines) at nopaste.snit.ch/17243 16:59
pmichaud I figured it out based on what you just said about the failure happening inside of IMCC
Whiteknight pmichaud++
pmichaud that's the piece that I hadn't recognized yet
in nopaste 17243, I just halt execution after the first eval and before the second one, then print out a backtrace 17:00
you can see that the previous imcc run is still in the execution stack
Whiteknight whoa whoa, that's rediculous!
the exception is jumping from IMCC directly to the next runcore without unwinding the stack? 17:01
pmichaud exceptions don't normally unwind the stack
that's Parrot's exception model
Whiteknight well, if they cause a longjmp back up to the previous runcore it would
for a very liberal definitoin of "unwind" 17:02
pmichaud anyway, if there's something that needs to be done to cause an exception to say "okay, handled it" and unwind up the stack, I'm curious to know what that is.
Whiteknight this is absolutely bizarre 17:03
NotFound: ping
NotFound Whiteknight: pong 17:04
Whiteknight NotFound: got a very interesting exception-related backtrace here if you want to look at it
nopaste.snit.ch/17243
NotFound Yes, I'm looking
Whiteknight okay, I think what is happening is that we have a runloop in IMCC handling the :init function, which throws the exception. There is a PIR handler for it, so THAT runloop executes the exception directly, not the uppermost "parent" runloop 17:05
and then it continues execution after the handler, which brings us to your debug 0 statement 17:06
so when that terminates, the stack unwinds back to the parent runloop, which continues execution and creates problems after the program appears to have run to completion 17:07
pmichaud exactly.
bingo.
Whiteknight so the test "passes", but then we get a failure at the end that looks like it's coming from the middle of the test file
pmichaud Whiteknight++ 17:08
Whiteknight so we need a way to specify that certain runloops cannot execute certain exception handlers from parent runloops 17:09
or maybe we need to not execute :init functions inside the PIR compreg
Coke I wonder if this is related to...
Whiteknight Or better yet, add init functions from the PIR compreg to the scheduler so they still get executed but in the parent runloop 17:10
Coke rt.perl.org/rt3/Ticket/Display.html?id=38432
17:10 chromatic joined
Whiteknight Coke: I'm sure it's very related to that bug, yes 17:11
same recursion mechanism
NotFound I was thinking about using for pir throws/pir handles the sam way I introduced for the C throws/pir handles, but I'm not tested that yet.
Whiteknight What we need now is to figure out which method we want to use to solve this, and then it should be relatively straight forward 17:12
particle the scheduler option seems best to me, but i can't put my finger on why yet 17:14
Whiteknight yeah, that's what I'm leaning towards now
this has the benefit that it should resolve many of our "inferior runloop" issues
pmichaud I'm wondering if 'pushmark' is actually what is needed here, though.
Whiteknight what's pushmark?
purl pushmark is the first step of a list operator or subroutine call
pmichaud purl, forget purhsmark 17:15
purl pmichaud, I didn't have anything matching purhsmark
particle wasn't pushmark deprecated and removed?
pmichaud purl, forget pushmark
purl pmichaud: I forgot pushmark
pmichaud let's look at the code I'm running for a sec
I create an exception handler
then do an operation (compile some PIR)
that operation throws an exception, which my handler catches
I'd like to have a way to say "okay, roll everything up and continue execution from the point where I expected to be catching an exception 17:16
(because I've handled it)
Whiteknight ok
pmichaud right now there's no way for me to say "roll up"
17:16 HG` joined
pmichaud I can try resuming after the exception -- but that's wrong. I don't want to resume execution from the point where the exception was thrown 17:17
I want to resume execution in my runloop from the point where I expected to catch the exception
that's kinda what the pushmark and popmark opcodes do, iirc
right now we handle "continue execution from the point where I expected to be catching an exception" by use of a goto -- but that leaves the original place in the call stack chain, because no rollup occurred. 17:18
I think I can come up with a simple example. 17:19
NotFound So this failure can be, in addition to an exception handler problem,a 'imcc is not reentrant' problem? 17:20
Whiteknight NotFound: no, it's larger then that. Not just IMCC 17:22
it's not that we are re-entering into IMCC, it's that we never leave IMCC when we execute a handler from outside it 17:23
NotFound Whiteknight: yeah, but supposedly the code must work even with that undesired behavior. 17:24
pmichaud I suspect the problem will arise anytime we end up throwing an exception from an inferior runloop 17:27
dalek ose: r74 | Austin++ | trunk/t/02-adverbs.t:
Updated test #s, reordered adv tests
 17:28
Whiteknight The question really is one of design then, what do we want to happen in these cases?
because it should be easy enough to detect it, we just need to know what to do
do we allow exceptions from an inner runloop to be handled by handlers in an outer "scope"? 17:29
pmichaud you have to allow them to be caught by an outer scope, yes.
17:30 darbelo joined
Whiteknight okay, that's what I was thinking 17:30
pmichaud otherwise we end up with uncatchable exceptions.
NotFound One problem is that 'push_eh label' is not so simple as it looks. Is not a goto, is calling an exception handler that just happen to be using the same sub block. 17:32
chromatic and you can't tell when the exception handler has ended.
pmichaud push_eh label creates an ExceptionHandler PMC and sets it to the address of 'label' 17:33
NotFound And the ExcpetionHandler isa Continuation 17:34
pmichaud correct
it almost makes me want to have a "rollback label" opcode or method on the ExceptionHandler, which causes the stack to rollback to the frame in which the ExceptionHandler was created and continue execution at the given label 17:37
NotFound And we can't do some unwinding before invoking it, because we must preserve context, C stack, et al. for a possible resume.
chromatic allison and I wrote up a quick design to denote when an exception handler should return, but she hasn't yet had time to post design notes to the list. 17:39
Mostly we need a way to mark the control scope of an exception handler.
Coke chromatic: I just opened some hard to reproduce segfaults. I still have those gdb windows open, if I can provide any more information on the segfaults, I'm happy to. 17:40
chromatic Coke, what does *string show in the int_malloc segfault in callframe #29? 17:41
up 29; p *string
sorry, p *meth instead
17:44 fdorothy joined
NotFound I wondering if we must able excpetions to propagate out of do_sub_pragmas. Did we expect to be able to sanely resume an exception from an init or load sub? 17:47
s/able/allow
Coke chromatic: is there an easy way to jump to that callframe?
damnit: Program terminated with signal SIGSEGV, Segmentation fault. 17:48
The program no longer exists.
re-running...
chromatic up 29 should do it 17:50
Coke chromatic: ok. give me another 5m to get to the segf again.
thanks.
chromatic: the stack is slightly different this time; Are you interested in Parrot_run_meth_fromc_args ? 17:56
nopaste "coke" at 72.228.52.192 pasted "stack trace this time" (55 lines) at nopaste.snit.ch/17244
chromatic Yes; it'd be good to know which PMC and which method it's trying to invoke. 17:59
cotto good beforenoon 18:00
Coke DAMMIT
after poking around again (up, down, l)... the program exited again.
re-re-running.
dalek rrot: r40058 | cotto++ | trunk/lib/Parrot/OpsFile.pm:
[ops2c] more cleanup of existing code; no functional changes
 18:02
Coke the method is "get_string" 18:07
chromatic p obj->vtable->whoami
p *obj->vtable->whoami
Coke Object 18:08
it's /probably/ a TclDict
chromatic How certain are you?
Coke > 50% 18:09
(given the nature of that test file)
chromatic Okay. Hm. That doesn't tell me anything.
How much memory is the process using?
Coke looks like 152m 18:10
if it /is/ tcldict, then its get_string is: code.google.com/p/partcl/source/bro...ict.pir#22 18:11
(though I do wonder why it would be invoking that as a method) 18:12
chromatic Yeah, that doesn't sound quite right. 18:13
dalek rrot: r40059 | cotto++ | trunk/lib/Parrot/OpsFile.pm:
[ops2c] remove debugging messages
 18:16
Coke chromatic: I can get a maximum recursion depth exceeded with the failing test if I tweak it slightly. Going to see if I can make /that/ go away, and see if that avoids the segf. 18:20
chromatic Do you have a per process memory limit? 18:21
Coke chromatic: whatever the default on feather is.
(yes)
oooh. I can duplicate the actual segfault with just that test case. that should narrow it down a bit. 18:22
chromatic I'm surprised it segfaulted then.
Coke I don't think it's running out of memory - parrot is pretty good about PANIC'ing then.
chromatic But it's segfaulting within malloc, which is strange. 18:23
Whiteknight that's probably indication that the heap is corrupted 18:24
which suggests that somebody is writing more data then they have allocated space
dalek rrot: r40060 | pmichaud++ | trunk (4 files):
[pge]: Add <?> and <!> to Perl6Regex syntax.
 18:37
18:46 japhb joined
NotFound I think we can have a manageable compreg 'PIR', and other imcc invocations, by catching exceptions in do_sub_pragmas, returnning an error code from him, propagate it to his callers, and checking it in imcc_compile. This requires to change the signature of several functions, though. 18:50
chromatic That seems sensible to me for now. 18:51
NotFound I'll give it a try, then.
Whiteknight that's a nice workaround for now, but it really ignores the larger problem 18:55
after all, IMCC is not the only place were this problem manifests 18:56
NotFound Whiteknight: one problem at a time.
chromatic It's not, but we're not going to solve this problem while we have mixed runloops.
Whiteknight I'm just saying, is all I'm saying
purl i already had it that way, Whiteknight.
NotFound Is not just a workaround, inhability to detect that problems inside imcc compiling is a real problem.
Whiteknight a little voice in my head keeps telling me that the real long-term solution is called "L1" 18:57
but then I take my medication and silence
dalek TT #833 created by whiteknight++: Exception from :init sub in PIR compreg causes problems
NotFound Whiteknight: surely, but I don't think L1 will solve imcc problems, or even pirc ones.
Whiteknight NotFound: it solves the problem that we don't recurse into child runloops
one runloop means zero problems due to runloop recursion 18:58
and phasing out our reliance on PIR means we don't need to worry about bugs inside the PIR compiler 18:59
NotFound Whiteknight: I'm not sure we can solve all, unless we forbid calling parrot code from C extensions. 19:00
chromatic The less C code they have to write, the better.
Whiteknight NotFound: the exceptions can "call" into the existing runloop with a longjmp 19:01
NotFound Whiteknight: try to implement callbacks that way.
Whiteknight or we can sandbox extensions so exceptions thrown from a child runloop in an extension do not propagate back to the parent runloop
NotFound That's the point. We need to do some things, L1 or not. 19:02
Whiteknight some things, yes
NotFound L1 can solve a lot, but not all. 19:03
Whiteknight if L1 is powerful enough, extensions won't be written in C 19:04
they will be written in a Parrot language, and won't need to recurse
the only C code will be libraries through NCI and callbacks
NotFound Maybe. In that case, we just need to do that things for reentrances from NCI. 19:06
19:43 AndyA joined
Coke Whiteknight: for another runloop ticket, see also: rt.perl.org/rt3/Ticket/Display.html?id=57088 19:50
Whiteknight yeah, nice 19:51
NotFound An interesting note: just adding a exit instruction at the end of TT #833 example avoids the segfault. 19:55
Coke note that exit throws an exception.
cotto darbelo, ping 19:58
darbelo cotto: pong 19:59
cotto darbelo, If you write a PCT-based decTest interpreter, you can always use --target=pir to generate tests instead of running them directly. That' 20:00
ll give you the simplicity of using HLLCompiler as intended while also not requiring that users build the compiler to run the test suite.
It'll mean a bit of trickery to generate the tests, but I don't think it'll be too onerous. 20:01
thoughts? 20:06
purl Moonlight shines through the dark night / clouds move overhead, casting shadows / dancing in the firelight
NotFound And another funny note: adding a :main qualifier to the sub, it fails on a different way
darbelo Sounds good to me, especially since I woke up on the interpreter side of the bed this morinig :) 20:10
cotto Start coding before you change your mind! 20:11
darbelo Heh. I think I was heading in the other direction when I wrote the grammar, but I'll dive back into that now. 20:14
I don't think I was making any deep-reaching assumptions there. Not intentionally. 20:15
cotto btw, you can get nice syntax highlighting if you install perl6.vim and add a coda for vim (unless you're using the other editor) 20:22
20:23 Bruce1 joined
darbelo Neither. I'm using a less bloated clone of the other editor :) 20:26
20:28 Bruce joined
cotto There are other editors? Who knew! 20:35
dalek rrot: r40061 | NotFound++ | trunk/include/parrot/interpreter.h:
[cage] delete no longer used piolayers member from interpreter
 20:41
21:21 bacek joined 21:23 brbrooks joined
brbrooks seen Whiteknight 21:23
purl Whiteknight was last seen on #parrot 1 hours, 31 minutes and 57 seconds ago, saying: yeah, nice
21:24 hercynium joined 21:29 sekimura joined 21:31 Khisanth joined, Whiteknight joined
bacek Good morning #parrot 21:44
brbrooks Whiteknight: have you read this: portal.acm.org/citation.cfm?id=224182 21:45
Tene "I like both kinds of music, country and western" 21:46
Whiteknight brbrooks: no, my acm subscription expired months ago 21:48
brbrooks citeseerx.ist.psu.edu/viewdoc/summa....1.84.4100 21:49
heavy, but informative 21:50
NotFound r40061 fails without a realclean. There is some lack of dependency on include/parrot/interpreter.h somewhere 21:54
chromatic interpreter.h is too big. Yuck.
21:55 Limbic_Region joined
dalek rrot: r40062 | bacek++ | branches/ops_pct/compilers/opsc/ops/oplib.pm:
[opsc] Add little bit more docs to Ops::OpLib
 22:08
NotFound I say realclean? No, it was clean. 22:11
Whiteknight brbrooks: yes I have read that second one 22:16
but I don't have a copy here
bacek always with that "make realclean" will generate special parrot. With clean design, clean GC implementation and clean of bugs... 22:17
always wish
chromatic And you should win stuff for using it.
brbrooks second one was just non-ACM access to the original link
bacek chromatic: :) 22:18
Any volunteers to smoke tt761_keys_revamp branch on something different from Debian/Lenny/i386?
dalek rrot: r40063 | pmichaud++ | trunk/compilers/pct/src/PCT/HLLCompiler.pir:
[pct]: Fix deprecated use of '.item' on match object
 22:19
rrot: r40064 | pmichaud++ | trunk/t/compilers/pge/perl6regex/rx_subrules:
[pge]: Omit tests for deprecated built-in rules (TT #460).
 22:22
rrot: r40065 | pmichaud++ | trunk/compilers/nqp/src/Grammar/Actions.pir:
[nqp]: Fix use of deprecated ".text" method (TT #460).
darbelo bacek: I can try it on OpenBSD/amd64 22:25
dalek rrot: r40066 | pmichaud++ | trunk/compilers/pge/PGE/Perl6Regex.pir:
[pge]: Fix use of deprecated ".text" method (TT #460)
 22:26
bacek darbelo: please. And if you have Rakudo - "make spectest" as well.
darbelo bacek: don't have rakudo, sorry. Should I just do a make smoke, or do you need anything special? 22:31
bacek darbelo: nothing special. Just smoke. 22:34
darbelo bacek: Okay, I'll smoke it. This might take a while. 22:35
22:35 rg joined
moritz bacek: sent result to the list (Lenny/amd64) 22:36
22:36 whoppix joined
bacek pmichaud: any plans for bringing ~~ to NQP? Or I have to use "/ foo /($str)" only? 22:36
dalek rrot: r40067 | bacek++ | branches/ops_pct/compilers/nqp/t/30-interpolate.t:
[nqp] Add test for regexp quoting.
bacek moritz: thanks
22:36 kid51 joined
bacek moritz: yak... packfiles... 22:37
darbelo bacek: smolder.plusthree.com/app/public_pr...ails/24873 22:41
that's the branch. And a smoke from trunk from a few hours earlier is at smolder.plusthree.com/app/public_pr...tails/2486 if you want to compare. 22:42
bacek darbelo: thanks. I forgot to regenerate PBCs... And t/compilers/pct is expecting to fail. 22:44
Bah! I also forgot to dcommit latest changes... 22:46
dalek rrot: r40068 | bacek++ | branches/tt761_keys_revamp (15 files):
Bring brunch up-to-date with trunk.
bacek facepalm.jpg
rrot: r40069 | bacek++ | branches/tt761_keys_revamp/src/pmc/hashiterator.pmc:
[pmc] Add more description into HashIterator.
rrot: r40070 | bacek++ | branches/tt761_keys_revamp/t/native_pbc (4 files):
Regenerate native pbc. moritz++ darabelo++
bacek darbelo: and mistyped your nick... 22:47
moritz darbelo++ then ;-)
bacek darbelo++ indeed :)
moritz: can you some spectest against updated branch? 22:50
moritz bacek: the smoke is already running 22:51
t/compilers/pct/past.t (Wstat: 512 Tests: 10 Failed: 2) Failed tests: 7, 9
t/compilers/pct/post.t (Wstat: 256 Tests: 6 Failed: 1) Failed test: 5
bacek moritz: those are expected failures... 22:52
Test of PAST/POST rely on Hash keys order.
(And I asked for help in maillist :)
moritz right 22:53
nopaste "bacek" at 114.73.12.50 pasted "partcl test failures on keys_revamp branch" (8 lines) at nopaste.snit.ch/17246 22:57
bacek msg Coke Are failures from nopaste.snit.ch/17246 expected on trunk? Or I broke something (as usual)? 22:58
purl Message for coke stored.
nopaste "darbelo" at 200.49.154.172 pasted "Failures on OpenBSD/amd64 after "svn up && make test" for bacek." (12 lines) at nopaste.snit.ch/17247 22:59
bacek darbelo: packfile again??? Doh! 23:00
23:00 skids joined
bacek darbelo: can you run "prove -v t/pmc/packfilerawsegment.t" and nopaste output? 23:01
23:02 Bruce left
nopaste "darbelo" at 200.49.154.172 pasted "Output of "prove -v t/pmc/packfilerawsegment.t " for bacek." (13 lines) at nopaste.snit.ch/17248 23:02
bacek hrm... 23:03
It's... impossible... 23:06
ok, time to $dayjob. I'll try to review packfile PMCs tonight. 23:07
nopaste "darbelo" at 200.49.154.172 pasted "bacek: You're going to love this :)" (51 lines) at nopaste.snit.ch/17249 23:08
rg bacek_at_work: smoke for tt761_keys_revamp on freebsd/amd64: smolder.plusthree.com/app/public_pr...ails/24878 23:09
darbelo msg bacek Look at nopaste.snit.ch/17249 the error comes and goes as it damm well pleases.
purl Message for bacek stored.
rg unfortunately it seems branch detection in Smoke.pm is broken, so it doesn't say so :( 23:10
darbelo msg bacek_at_work Look at nopaste.snit.ch/17249 the error comes and goes as it damm well pleases.
purl Message for bacek_at_work stored.
darbelo rg: you were the other victim of tt807, right? 23:12
rg darbelo: i believe so. looks like it got fixed, though. 23:18
darbelo It stopped manifesting on OpenBSD/amd64, if FreeBSD isn't failing anymore you should probably comment on the ticket so it can be closed. 23:20
dalek TT #786 closed by jkeenan++: config step auto::gettext throws warnings on Darwin/PPC 23:21
rg i can just close it if you agree. 23:22
jdv79 is there any gc instrumentation at the moment? 23:25
darbelo rg: fine with me, I just wanted to see if it was fixed for you too. 23:28
rg darbelo: you can also look at my smoke reports. unless i need the machine for something else, it should submit one 3 times a day. 23:29
dalek TT #807 closed by rg++: t/pmc/eval.t: freeze/thaw test not passing on OpenBSD/AMD 64 23:31
Whiteknight nopaste? 23:50
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo
nopaste "whiteknight" at 69.248.162.161 pasted "test failure for bacek++. amd64, ubuntu9.04, gcc4.3.3" (14 lines) at nopaste.snit.ch/17250
Whiteknight purl msg bacek nopaste.snit.ch/17250 amd64 ubuntu9.04 test results 23:51
purl Message for bacek stored.
23:52 bobke joined
Whiteknight (I don't envy how many msgs he's going to have when he gets back) 23:55
pmichaud:ping
23:56 sekimura_ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!