Re: urgent parrot bug / PR opportunity

2005-08-04 Thread Michal Wallace

On Thu, 4 Aug 2005, Leopold Toetsch wrote:


Michal Wallace wrote:


And wouldn't you know it... A bug on the parrot
side cropped up out of nowhere to break them!



==17366== valgrind's libpthread.so: IGNORED call to: pthread_attr_destroy
==17366== Invalid read of size 4
==17366==at 0x43D5123E: Parrot_PyTuple_get_iter (in 
/home/lt/svn/parrot/leo/runtime/parrot/dynext/python_group.so)

==17366==by 0x8115576: Parrot_iter_p_p (ops/experimental.ops:231)

Unfortunately valgrind doesn't show line numbers from the shared lib, but 
PyTuple.get_iter() is short enough so that you should be able to track down 
the problem.


Thanks, Leo!!

I'm afraid this is gibberish to me, but I gave it a shot.

I compared the code for pytuple to pylist and pystring 
and noticed they use the python iterator instead of the 
enum_class one. Also, pylist references in there several

times but it only appears once for pytuple, which can't
change its length. It looks like the other length tests
for pytuple use PMC_int_val instead so I changed that.
Anyway, I have no idea what I'm doing here but it seems
to have fixed the tests. I don't have commit access.

Assuming you don't see anything horribly wrong here, 
would you mind applying this patch?


BTW, the problem is on red hat enterprise linux 3.0 with
a fresh build from subversion)

- Michal
http://withoutane.com/



Index: pytuple.pmc
===
--- pytuple.pmc (revision 8800)
+++ pytuple.pmc (working copy)
@@ -155,12 +155,12 @@
 */

 PMC* get_iter () {
-PMC *iter = pmc_new_init(INTERP, enum_class_Iterator, SELF);
+PMC *iter = pmc_new_init(INTERP, PyBuiltin_PyIter, SELF);
 PMC *key =  pmc_new(INTERP, enum_class_Key);
 PMC_struct_val(iter) = key;
 PObj_get_FLAGS(key) |= KEY_integer_FLAG;
 PMC_int_val(key) = 0;
-if (!((List *) PMC_data(SELF))-length)
+if (!((List *) PMC_int_val(SELF)))
 PMC_int_val(key) = -1;
 return iter;
 }



Re: urgent parrot bug / PR opportunity

2005-08-04 Thread Leopold Toetsch

Michal Wallace wrote:


+PMC *iter = pmc_new_init(INTERP, PyBuiltin_PyIter, SELF);


Done - r8801


-if (!((List *) PMC_data(SELF))-length)
+if (!((List *) PMC_int_val(SELF)))

~

Bogus. Changed to !SELF.elements()

leo



Re: urgent parrot bug / PR opportunity

2005-08-03 Thread Will Coleda

Suggestions for workarounds given the short time frame:

1) Use the last *released* version of parrot, which is from a month  
ago. If this is a new issue, just run the slightly older code.  
(releases are happening once a month now. This will give you fairly  
recent code with a little more stability.)
2) Try running with -G to see if it's a GC bug. If so, then just run  
without GC for the presentation and we can try to figure out where  
the bug is at a more leisurely pace. (I ran parrot with --gc-debug  
and didn't trip anything, though.)
3) for the latest version, did you do a make realclean;perl  
Configure.pl;make ? some changes require a realclean when they might  
not ought to.


FWIW, I tried it here with a variety of filenames, all generate the  
full list; as does piping the program to ./parrot -. (OSX, svn-latest)


Hope one of these helps.

On Aug 3, 2005, at 11:33 PM, Michal Wallace wrote:




Help! :)

Sam Ruby is giving a speech at OSCON tomorrow
about python on parrot.

The pirate tests run hourly against the latest
repository versions of pirate and parrot at:

  http://pirate.tangentcode.com/

And wouldn't you know it... A bug on the parrot
side cropped up out of nowhere to break them!


Watch closely:

[~/pirate]: parrot listcomp.pir
[16, 26]
[~/pirate]: cp listcomp.pir now_it_works.pir
[~/pirate]: parrot now_it_works.pir
[15, 25, 16, 26]


The correct output is [15, 25, 16, 26] but
depending on the *filename* we sometimes get
the short version.

The python source is:

print [x+y  for x in (1,2,3,4,5,6,7,8)
if x  4
for y in (10,20)
if x  7]

The generated pir code is at the end of this message.

Likewise, this code fails when the pir is read
from stdin (which is why pirate is failing). On Sam's machine the  
listcom.pir filename

doesn't trigger the bug.

My guess is that something about the filename or the argument list  
is changing parrot's behavior.


This is running against a freshly built copy
of parrot from subversion.

I don't have any clue where to look for this,
but if someone happens to know how to fix it
by tomorrow, I would really appreciate it, and
it would certainly leave the OSCON atendees with
a better impression of parrot!


- Michal
http://withoutane.com/




##

# generated by pirate on Wed Aug  3 23:02:54 2005

.sub __main__ @MAIN
new_pad 0
loadlib P1, 'python_group'
push_eh __py_catch
#
setline 1
new $P0, 'PyList' # (expressListComp:738)
new $P2, 'PyTuple'# (tupleExpression:354)
$P2=8 # (tupleExpression:355)
$P2[0]=1  # (tupleExpression:358)
$P2[1]=2  # (tupleExpression:358)
$P2[2]=3  # (tupleExpression:358)
$P2[3]=4  # (tupleExpression:358)
$P2[4]=5  # (tupleExpression:358)
$P2[5]=6  # (tupleExpression:358)
$P2[6]=7  # (tupleExpression:358)
$P2[7]=8  # (tupleExpression:358)
$P3 = iter $P2# (visitFor:994)
for0:
unless $P3 goto endfor0   # (visitFor:1000)
$P4 = shift $P3   # (visitFor:1000)
store_lex -1, 'x', $P4# (visitFor:1009)
setline 2
unless $P4  4 goto endif0# (tupleExpression:354)
new $P5, 'PyTuple'# (tupleExpression:354)
$P5=2 # (tupleExpression:355)
$P5[0]=10 # (tupleExpression:358)
$P5[1]=20 # (tupleExpression:358)
$P6 = iter $P5# (visitFor:994)
for1:
unless $P6 goto endfor1   # (visitFor:1000)
$P7 = shift $P6   # (visitFor:1000)
store_lex -1, 'y', $P7# (visitFor:1009)
setline 4
find_lex $P8, 'x' # (lookupName:176)
unless $P8  7 goto endif1# (infixExpression:423)
new $P9, 'PyObject'   # (infixExpression:423)
$P9 = $P8 + $P7   # (infixExpression:428)
push $P0, $P9 # (visitListCompExpr:766)
endif1:
goto for1 # (goto:158)
endfor1:
endif0:
goto for0 # (goto:158)
endfor0:
print_item $P0# (visitPrint:779)
print_newline # (visitPrintnl:787)
#
.return ()
__py_catch:
print_item P5
print_newline
.end









Re: urgent parrot bug / PR opportunity

2005-08-03 Thread Leopold Toetsch


On Aug 4, 2005, at 5:33, Michal Wallace wrote:


Watch closely:

[~/pirate]: parrot listcomp.pir
[16, 26]
[~/pirate]: cp listcomp.pir now_it_works.pir
[~/pirate]: parrot now_it_works.pir
[15, 25, 16, 26]


Which OS  architecture is this?

leo