From tracker at bugs.pypy.org  Sun Jan  1 09:14:58 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 01 Jan 2012 08:14:58 +0000
Subject: [pypy-issue] [issue967] itertools.imap significantly (order of
	magnitude) slower	than map or gencomps
In-Reply-To: <1324218386.21.0.607847720778.issue967@bugs.pypy.org>
Message-ID: <1325405698.81.0.0430604689607.issue967@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Indeed, there is a special case for list(generator).  It's a bit annoying that
the more general list(iterator) is not sped up by the JIT at all.  It's a known
issue that we may fix at some point, but it's not completely clear how.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue967>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  2 08:40:46 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 02 Jan 2012 07:40:46 +0000
Subject: [pypy-issue] [issue977] numpypy ndim attribute (patch attached)
In-Reply-To: <1325490046.35.0.138568210061.issue977@bugs.pypy.org>
Message-ID: <1325490046.35.0.138568210061.issue977@bugs.pypy.org>


New submission from mikefc <coolbutuseless at gmail.com>:

Currently numpypy lacks an ndim attribute, this patch adds it.

However, I couldn't get numpypy to throw the same error if you try doing an assign 
to ndim i.e. a.ndim=3 throws an AttributeError on numpy, but a TypeError on 
numpypy.

----------
files: numpypy_ndim.patch
messages: 3619
nosy: mikefc, pypy-issue
priority: feature
release: ???
status: unread
title: numpypy ndim attribute (patch attached)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue977>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  2 12:17:53 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 02 Jan 2012 11:17:53 +0000
Subject: [pypy-issue] [issue976] Implement numpypy.cross()
In-Reply-To: <1325370623.07.0.544643073222.issue976@bugs.pypy.org>
Message-ID: <1325503073.0.0.956548340419.issue976@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

I've had a go at implementing this with applevel code. Patch attached.

Note that the whole things is really a cut and paste from actual 
numpy/core/numeric.py with some slight changes because we don't have a few 
functions.

The main change is that it only works on 1-d arrays as we don't have a swapaxes() 
method yet.  We're also missing an ndim() method.

----------
nosy: +mikefc
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue976>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  2 12:32:37 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 02 Jan 2012 11:32:37 +0000
Subject: [pypy-issue] [issue976] Implement numpypy.cross()
In-Reply-To: <1325370623.07.0.544643073222.issue976@bugs.pypy.org>
Message-ID: <1325503957.21.0.356686923184.issue976@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Ooops.  "We're also missing an ndim attribute."

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue976>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  2 21:54:04 2012
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 02 Jan 2012 20:54:04 +0000
Subject: [pypy-issue] [issue964] numpypy.zeros([]) returns wrong result
In-Reply-To: <1323897912.33.0.627836648834.issue964@bugs.pypy.org>
Message-ID: <1325537644.17.0.0876536630063.issue964@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

Fixed in changeset 68dec1e17bd9149babafdc36eb109eb8d41c8a61, based on mikefc's
patch. At the same time fixed bug for showing dtype iff array is empty or not
(array.dtype is float or array.dtype is platform-sized-int)

----------
nosy: +mattip
status: chatting -> in-progress

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue964>
________________________________________

From tracker at bugs.pypy.org  Tue Jan  3 10:49:40 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 03 Jan 2012 09:49:40 +0000
Subject: [pypy-issue] [issue977] numpypy ndim attribute (patch attached)
In-Reply-To: <1325490046.35.0.138568210061.issue977@bugs.pypy.org>
Message-ID: <1325584180.01.0.448841734525.issue977@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Applied in ac51513392d3, thanks!

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue977>
________________________________________

From tracker at bugs.pypy.org  Tue Jan  3 22:25:04 2012
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Tue, 03 Jan 2012 21:25:04 +0000
Subject: [pypy-issue] [issue978] metainterp bug
In-Reply-To: <1325625904.37.0.729705518773.issue978@bugs.pypy.org>
Message-ID: <1325625904.37.0.729705518773.issue978@bugs.pypy.org>


New submission from Laurence Tratt <laurie at tratt.net>:

With the latest Converge RPython VM, it's possible to trigger this assertion in
the JIT:

  RPython traceback:
    File "jit_metainterp_resume.c", line 13973, in blackhole_from_resumedata
    File "jit_metainterp_resume.c", line 14109, in
ResumeDataDirectReader_consume_vref_and_vable
    File "jit_metainterp_resume.c", line 817, in
ResumeDataDirectReader_consume_vable_info
  Fatal RPython error: AssertionError

This can be triggered by:

  1) Removing @jit.dont_look_inside from either VM.execute_proc or
     VM.execute_gen.

  2) Compiling the VM with --opt=jit.
  
  3) Compiling the Converge system. On larger files, the compiler will
     trigger the above assert. [I assume this only happens when traces
     get to a certain size and / or go down a certain path that compilations
     of smaller files don't hit.]

----------
messages: 3624
nosy: ltratt, pypy-issue
priority: bug
status: unread
title: metainterp bug

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue978>
________________________________________

From tracker at bugs.pypy.org  Tue Jan  3 22:45:09 2012
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 03 Jan 2012 21:45:09 +0000
Subject: [pypy-issue] [issue964] numpypy.zeros([]) returns wrong result
In-Reply-To: <1323897912.33.0.627836648834.issue964@bugs.pypy.org>
Message-ID: <1325627109.78.0.425004348928.issue964@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

changeset merged to default.

----------
status: in-progress -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue964>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 15:52:14 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Wed, 04 Jan 2012 14:52:14 +0000
Subject: [pypy-issue] [issue975] A jit bug crashes my app
In-Reply-To: <1325350417.44.0.794309064675.issue975@bugs.pypy.org>
Message-ID: <1325688734.89.0.75104526357.issue975@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

Is there any way we could reproduce the bug? I've added some more debug prints to 
shed light on whats happening here. Maybe you could reproduce the 
PYPYLOG=jit:logfile with tomorrows nightly?

----------
nosy: +hakanardo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue975>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 17:32:23 2012
From: tracker at bugs.pypy.org (Simon Hova)
Date: Wed, 04 Jan 2012 16:32:23 +0000
Subject: [pypy-issue] [issue979] Pickle fails in pypy, works in CPython
In-Reply-To: <1325694743.04.0.41876802496.issue979@bugs.pypy.org>
Message-ID: <1325694743.04.0.41876802496.issue979@bugs.pypy.org>


New submission from Simon Hova <Simon at hova.net>:

When trying to use the shelve module, I noticed that it kept hanging while 
saving a rather large (~5 MB) object. I followed the source code, and found that 
it was simply pickling the object. When I tried to pickle it in pypy, it hangs 
in a loop (_batch_setitems), but it works perfectly in CPython. It pickles 
smaller objects normally. I can recreate the bug easily, but I don't know how to 
give documentation properly, so any tips would be appreciated.

----------
messages: 3627
nosy: SimonHova, pypy-issue
priority: bug
status: unread
title: Pickle fails in pypy, works in CPython

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue979>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 18:54:10 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 04 Jan 2012 17:54:10 +0000
Subject: [pypy-issue] [issue979] Pickle fails in pypy, works in CPython
In-Reply-To: <1325694743.04.0.41876802496.issue979@bugs.pypy.org>
Message-ID: <1325699650.28.0.587440792918.issue979@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

PyPy does not have cPickle, only pickle, so it's likely it's just a bug in pickle 
or it's slow. Can you provide an example, preferably short?

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue979>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 19:14:56 2012
From: tracker at bugs.pypy.org (Simon Hova)
Date: Wed, 04 Jan 2012 18:14:56 +0000
Subject: [pypy-issue] [issue979] Pickle fails in pypy, works in CPython
In-Reply-To: <1325694743.04.0.41876802496.issue979@bugs.pypy.org>
Message-ID: <1325700896.77.0.44480767446.issue979@bugs.pypy.org>


Simon Hova <Simon at hova.net> added the comment:

I am pickling a list of classes, and it only seems to choke on the big ones. I'll 
try to create a simple example for you now.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue979>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 19:33:35 2012
From: tracker at bugs.pypy.org (Simon Hova)
Date: Wed, 04 Jan 2012 18:33:35 +0000
Subject: [pypy-issue] [issue979] Pickle fails in pypy, works in CPython
In-Reply-To: <1325694743.04.0.41876802496.issue979@bugs.pypy.org>
Message-ID: <1325702015.93.0.431505368303.issue979@bugs.pypy.org>


Simon Hova <Simon at hova.net> added the comment:

I don't know how to submit my code without the problematic file, so I am going to 
dump it all.

Test program attached.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue979>
________________________________________
-------------- next part --------------
import EDI
from cPickle import Pickler, Unpickler
from cStringIO import StringIO

_file=EDI.file('ISA_14147844480_600004016.edi')

f = StringIO()
p = Pickler(f, -1)
p.dump(_file)

From tracker at bugs.pypy.org  Wed Jan  4 19:34:47 2012
From: tracker at bugs.pypy.org (Simon Hova)
Date: Wed, 04 Jan 2012 18:34:47 +0000
Subject: [pypy-issue] [issue979] Pickle fails in pypy, works in CPython
In-Reply-To: <1325694743.04.0.41876802496.issue979@bugs.pypy.org>
Message-ID: <1325702087.67.0.395700950189.issue979@bugs.pypy.org>


Simon Hova <Simon at hova.net> added the comment:

EDI module attached.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue979>
________________________________________
-------------- next part --------------
import logging

from array import array
from os.path import getsize, split
from datetime import date, datetime
from cStringIO import StringIO

class segment(dict):
	"""A list of elements."""
	def __init__(self, delimiters, text=None):
		super(segment,self).__init__() # Create a blank dictionary.
		self.closed=False # Initialize as open
		self._next=None
		self._delimiters=delimiters
		self._text=text
		
		if self.text:
			self.parse()

	def __hash__(self):
		return hash(tuple([self.text]))
	def __eq__(self, other):
		return other and self.text == other.text
	def __ne__(self, other):
		return not self.__eq__(other)
	def __iter__(self):
		return self

	def parse(self):
		self._text=self.text.partition(self.delimiters[0])[0] # take only the first segment!
		fields=self._text.split(self.delimiters[1]) # Splits our string into a list
		self._header=fields.pop(0)
		if self.FieldNames and self.header!=self.footer:
			if len(self.FieldNames)!=len(fields):
				raise TypeError('Expected {} field names, got {}'.format(len(self.FieldNames),len(fields)))
			super(segment,self).__init__(zip(self.FieldNames,(field for field in fields)))
		else:
			super(segment,self).__init__(zip(('{}{:02d}'.format(self.header,FieldNum) for FieldNum in range(1,len(fields)+1)),fields))
		# self._text=self.delimiters[1].join(self.values())
		# self._text=''
		self.closed=False
		
	def add(self, text, delimiters=None):
		if self.closed:
			return TypeError
		
	def next(self):
		if self._next and not self._next.closed:
			return self._next
		else:
			raise StopIteration

	def splitDate(self,datestring):
		try:
			if len(datestring)==10:
				return date(year=int(datestring[:4]),month=int(datestring[5:7]),day=int(datestring[8:10]))
			if len(datestring)==6:
				return date(year=int(datestring[:2]),month=int(datestring[2:4]),day=int(datestring[4:6]))
			elif len(datestring)==8:
				return date(year=int(datestring[:4]),month=int(datestring[4:6]),day=int(datestring[6:8]))
			else:
				raise TypeError
		except:
			logging.debug('Date error. Date string: ',datestring)
			raise

	def splitTime(self,timestring):
		try:
			if len(timestring)==10:
				return date(year=int(timestring[:4]),month=int(timestring[5:7]),day=int(timestring[8:10]))
			else:
				raise TypeError
		except:
			logging.debug('Date error. Date string: ',timestring)
			raise

	@property
	def text(self):
		return self._text
	@text.setter
	def text(self, value):
		if self.closed:
			raise TypeError
		else:
			self._text=value
			if self.delimiters:
				self.parse()

	@property
	def delimiters(self):
		return self._delimiters

	@property
	def header(self):
		return self._header

	@property
	def footer(self):
		return self._footer
	
	@property
	def FieldNames(self):
		return None

class document(object):
	"""A container holding contents of a single EDI envelope."""
	def __init__(self, _input=None, headersOnly=False):
		super(document,self).__init__()
		self.headersOnly=headersOnly
		if _input:
			self.input=_input
			self.start()
	def __str__(self):
		return self.interchange.__str__()
	def __hash__(self):
		return hash(tuple([self.interchange]))
	def __eq__(self, other):
		return other and self.interchange == other.interchange
	def __ne__(self, other):
		return not self.__eq__(other)
	@property
	def delimiters(self):
		return self.interchange.delimiters
	@property
	def closed(self):
		return self.interchange.closed
	@property
	def input(self):
		if not self._input or self._input.closed:
			raise OSError
		return self._input
	@input.setter
	def input(self, value):
		self._input=StringIO(value)
	def start(self):
		try:
			self.interchange=interchange(self.input.read(106))
		except:
			raise OSError('Could not find delimiters.')

		for segment in self.segments():
			self.add(segment)
	def add(self, seg):
		if self.interchange:
			if self.headersOnly:
				if self.Group and self.Document_Type:
					return
			self.interchange.add(segment(text=seg, delimiters=self.delimiters))
		else:
			if 'ISA' in seg[:106]:
				self.interchange=interchange(seg)
				if self.interchange.header!='ISA':
					raise TypeError
				return
			else:
				raise TypeError
	def segments(self):
		seg = array('c')
		for i in self.input.read():
			if i == "": break
			if i == '\0': continue
			if i == self.delimiters[0]:
			# End of segment found, exit the loop and return the segment.
				yield seg.tostring()
				seg = array('c')
			elif i != '\n':
				try:
					seg.append(i)
				except TypeError:
					raise self.BadFile('Corrupt characters found in data or unexpected EOF')
	@property
	def Document_Type(self):
		try:
			return self.Transactions[0]['Document Type']
		except:
			return
	@property
	def Interchange(self):
		try:
			return self.interchange
		except:
			return
	@property
	def Envelope(self):
		return self.Interchange
	@property
	def Group(self):
		try:
			return self.interchange.groups[0]
		except:
			return
	@property
	def Groups(self):
		return self.interchange.groups
	@property
	def Transactions(self):
		try:
			return self.Group.transactions
		except:
			return

class interchange(segment):
	def __init__(self, text):
		super(interchange,self).__init__(text=None, delimiters=None)
		self._text=text
		self._delimiters=self.delimiters
		self.parse()

		self.groups=list()
	def __str__(self):
		return '{}->{},Ctrl={}'.format(self['Sender ID'],self['Receiver ID'],self['Control Number'])
	def __hash__(self):
		return hash(tuple([self.Control_Number,self.Sender_ID,self.Reciever_ID,len(self.groups)]))
	def __eq__(self, other):
		return other and self.Control_Number == other.Control_Number and self.Sender_ID == other.Sender_ID and self.Reciever_ID == other.Reciever_ID and len(self.groups) == len(other.groups)
	def __ne__(self, other):
		return not self.__eq__(other)
	@property
	def FieldNames(self):
		return ('Authorization Information Qualifier','Authorization Information','Security Information Qualifier','Security Information',
			'Sender Qualifier','Sender','Receiver Qualifier','Receiver','Date','Time','Standard',
			'Version','Control Number','Acknowledgement Requested','Test Indicator','Subelement Seperator')
	@property
	def footer(self):
		return 'IEA'
	def add(self, segment):
		super(interchange,self).add(segment)
		if segment.header==self.footer:
			# if segment[1] == len(self.groups) and segment[2]==self.Control_Number:
			if int(segment['IEA01']) == len(self.groups):
				self.closed=True
			else:
				raise TypeError('Failed interchange check. Found {} groups but should have {}'.format(len(self.interchanges),int(segment['IEA01'])))
		else:
			try:
				self.next().add(segment)
			except StopIteration:
				self.groups.append(group(segment.text,self.delimiters))
				self._next=self.groups[-1]
	def parse(self):
		super(interchange,self).parse()

		# Map fields
		self['Control Number']=format(int(self['Control Number']),'>09')
		self['DateTime']=datetime.strptime(' '.join([self['Date'],self['Time']]),'%y%m%d %H%M')
		del self['Date']
		del self['Time']
		
		if self['Authorization Information Qualifier']=='00':
			del self['Authorization Information Qualifier']
			self['Authorization Information']=True
		
		if self['Security Information Qualifier']=='00':
			del self['Security Information Qualifier']
			self['Security Information']=True
		
		self['Receiver ID']='{}-{}'.format(self['Receiver Qualifier'],self['Receiver'].strip())
		del self['Receiver Qualifier']
		del self['Receiver']
		
		self['Sender ID']='{}-{}'.format(self['Sender Qualifier'],self['Sender'].strip())
		del self['Sender Qualifier']
		del self['Sender']
		
		del self['Subelement Seperator']
		
		if self['Acknowledgement Requested']=='0':
			self['Acknowledgement Requested']=False
		else:
			self['Acknowledgement Requested']=True
		
		if self['Test Indicator']=='P':
			self['Test Indicator']=False
		elif self['Test Indicator']=='T':
			self['Test Indicator']=True
		else:
			self['Test Indicator']=True
	@property
	def delimiters(self):
		if not self._delimiters:
			version = self.text[84:89]
			delimiters = [self.text[105], self.text[3], self.text[104]]
			
			if version >= '00405':
				delimiters = [self.text[105], self.text[3], self.text[104], self.text[83]]
				
			# Verify that the delimiters are valid.
			for delim in delimiters:
				if delim.isalnum():
					raise OSError('{} is not a valid delimiter'.format(delim))
				
			self._delimiters=delimiters
		return self._delimiters
	@delimiters.setter
	def delimiters(self, value):
		pass
class group(segment):
	def __init__(self, text, delimiters):
		super(group,self).__init__(text=text, delimiters=delimiters)
		self.transactions=list()
	def __str__(self):
		return '{}->{},Ctrl={}'.format(self['Sender ID'],self['Receiver ID'],self['Control Number'])
	def __hash__(self):
		return hash(tuple([self['Control Number'],self['Sender ID'],self['Receiver ID'],len(self.transactions)]))
	def __eq__(self, other):
		return other and self['Control Number'] == other['Control Number'] and self['Sender ID'] == other['Sender ID'] and self['Receiver ID'] == other['Receiver ID'] and len(self.transactions) == len(other.transactions)
	def __ne__(self, other):
		return not self.__eq__(other)
	@property
	def FieldNames(self):
		return ('Functional ID','Sender ID','Receiver ID','Date','Time','Control Number','Responsible Agency','Version')
	@property
	def footer(self):
		return 'GE'
	def parse(self):
		super(group,self).parse()

		# Map fields
		self['Control Number']=int(self['Control Number'])
		if self['Version'][2:6]=='3020':
			self['DateTime']=datetime.strptime(' '.join([self['Date'],self['Time']]),'%y%m%d %H%M')
		else:
			self['DateTime']=datetime.strptime(' '.join([self['Date'],self['Time']]),'%Y%m%d %H%M')
		del self['Date']
		del self['Time']
	def add(self, segment):
		if segment.header==self.footer:
			# if segment[1] == len(self.transactions) and segment[2]==self.Control_Number:
			if int(segment['GE01']) == len(self.transactions):
				self.closed=True
			else:
				raise TypeError('Failed group check. Found {} transactions but should have {}'.format(len(self.transactions),int(segment['GE01'])))
		else:
			try:
				super(group,self).next().add(segment)
			except StopIteration:
				self.transactions.append(transaction(segment.text, segment.delimiters))
				if len(self.transactions) % 5 == 0: logging.info('Wrote {} transactions'.format(len(self.transactions)))
				self._next=self.transactions[-1]
class transaction(segment):
	def __init__(self, text, delimiters):
		super(transaction,self).__init__(text=text, delimiters=delimiters)
		self.lines=list()
	def __str__(self):
		return '{} Ctrl={}'.format(self['Document Type'],self['Control Number'])
	def __hash__(self):
		return hash(tuple([self['Document Type'],self['Control Number'],len(self.lines)]))
	def __eq__(self, other):
		return other and self['Document Type'] == other['Document Type'] and self['Control Number'] == other['Control Number'] and len(self.lines) == len(other.lines)
	def __ne__(self, other):
		return not self.__eq__(other)
	@property
	def FieldNames(self):
		return ('Document Type','Control Number')
	@property
	def footer(self):
		return 'SE'
	def parse(self):
		super(transaction,self).parse()
		
		# Map fields
		self['Control Number']=int(self['Control Number'])
	def add(self, segment):
		if segment.header==self.footer:
			# if segment[1] == len(self.lines) and segment[2]==self.Control_Number:
			if int(segment['SE01']) == (len(self.lines) + 2): # add two lines for the header and footer lines
				self.closed=True
				self._next=None
			else:
				raise TypeError('Failed transaction check. Found {} lines but should have {}'.format(len(self.lines),int(segment['SE01'])))
		else:
			self.lines.append(segment)
			if len(self.lines) % 1000==0: logging.info('Wrote {} lines'.format(len(self.lines)))

class record(document):
	def __init__(self, headersOnly=False):
		super(record, self).__init__(_input=None, headersOnly=headersOnly)
	@property
	def Manafacturer_ID(self):
		if self.Document_Type == '852':
			return self.Groups[0]['Receiver ID']
		elif self.Document_Type == '856':
			return self.Groups[0]['Sender ID']
		else:
			return self.Groups[0]['Sender ID']
	@property
	def Retailer_ID(self):
		if self.Document_Type == '852':
			return self.Groups[0]['Sender ID']
		elif self.Document_Type == '856':
			return self.Groups[0]['Receiver ID']
		else:
			return self.Groups[0]['Receiver ID']

#	elif (elements[0] == 'XQ' and self.DocumentType == '852'):
#		self.StartDate=elements[2]
#		if len(elements) == 3: # If there is only one ship date.
#			self.EndDate=elements[2]
#		else:
#			self.EndDate=elements[3]
#		# break
#	elif (elements[0] == 'DTM' and self.DocumentType == '856'):
#		if elements[1] == '011': # This represents the ship date.
#			self.EndDate = self.StartDate = elements[2]
#			# break		# ignore the rest of the file.

	@property
	def Start_Date(self):
		return self.Groups[0]['DateTime'].strftime('%Y%m%d')
	@property
	def End_Date(self):
		return self.Groups[0]['DateTime'].strftime('%Y%m%d')
class file(record):
	def __init__(self, filepath, headersOnly=False):
		super(file,self).__init__(headersOnly)
		self._input=open(filepath,'rb')
		self.File_Path=filepath
		self.File_Size=getsize(self.File_Path)
		self.start()
	@property
	def Directory_Name(self):
		return split(self.File_Path)[0]
	@property
	def File_Name(self):
		return split(self.File_Path)[1]
	def __hash__(self):
		return hash(self.File_Path,self.File_Size)
	def __eq__(self, other):
		return other and self.File_Path == other.File_Path and self.File_Size == other.File_Size
	def __ne__(self, other):
		return not self.__eq__(other)
	def __str__(self):
		return self.File_Path

From tracker at bugs.pypy.org  Wed Jan  4 19:37:50 2012
From: tracker at bugs.pypy.org (Simon Hova)
Date: Wed, 04 Jan 2012 18:37:50 +0000
Subject: [pypy-issue] [issue979] Pickle fails in pypy, works in CPython
In-Reply-To: <1325694743.04.0.41876802496.issue979@bugs.pypy.org>
Message-ID: <1325702270.58.0.97820421772.issue979@bugs.pypy.org>


Simon Hova <Simon at hova.net> added the comment:

I'm not really certain how to show the problem without all the code, so I am 
including it.

Basically, my EDI module makes a mutable dict object from an EDI file. If I try 
to pickle the finished object, using the code found in the shelve class, it will 
work in Python 2.7.1 and 2.7.2, but hangs forever in pypy 1.7. Oddly, the 
smaller EDI file works fine.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue979>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 20:13:40 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 04 Jan 2012 19:13:40 +0000
Subject: [pypy-issue] [issue976] Implement numpypy.cross()
In-Reply-To: <1325370623.07.0.544643073222.issue976@bugs.pypy.org>
Message-ID: <1325704420.57.0.572920244123.issue976@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

I'm closing this issue as numpy.cross is implemented in pure python. We should 
just reuse it. The issue describing "reuse pure python parts of numpy" should be 
different though, feel free to create one.

----------
nosy: +fijal
status: chatting -> wontfix

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue976>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 20:16:31 2012
From: tracker at bugs.pypy.org (lesshaste)
Date: Wed, 04 Jan 2012 19:16:31 +0000
Subject: [pypy-issue] [issue980] Loop with small number of iterations much
	faster after	unrolling
In-Reply-To: <1325704591.17.0.672544760762.issue980@bugs.pypy.org>
Message-ID: <1325704591.17.0.672544760762.issue980@bugs.pypy.org>


New submission from lesshaste <drraph at gmail.com>:

In the following examples, the function hamdistX is called many times. If it is
implemented as a simple loop then it is 3 times slower than if the loop is
unrolled. In the case attached, the hamdistX loop only iterates 5 times.  The
slow version is

def hamdist2(pattern, index, unknown):
    """Count the # of differences between equal length strings str1 and str2"""
    diffs = 0
    for i in xrange(l):
        if pattern[i+index] != unknown[i]:
           diffs += 1
    return diffs  

and the fast version is


def hamdist3(pattern, index, unknown):
    """Count the # of differences between equal length strings str1 and str2"""
    diffs = 0
    i = 0
    if pattern[i+index] != unknown[i]:
        diffs += 1
    i += 1
    if pattern[i+index] != unknown[i]:
        diffs += 1
    i += 1
    if pattern[i+index] != unknown[i]:
        diffs += 1
    i += 1
    if pattern[i+index] != unknown[i]:
        diffs += 1
    i += 1
    if pattern[i+index] != unknown[i]:
        diffs += 1
    return diffs

----------
messages: 3635
nosy: lesshaste, pypy-issue
priority: performance bug
status: unread
title: Loop with small number of iterations much faster after unrolling

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue980>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 20:19:02 2012
From: tracker at bugs.pypy.org (lesshaste)
Date: Wed, 04 Jan 2012 19:19:02 +0000
Subject: [pypy-issue] [issue980] Loop with small number of iterations much
	faster after	unrolling
In-Reply-To: <1325704591.17.0.672544760762.issue980@bugs.pypy.org>
Message-ID: <1325704742.88.0.540100220888.issue980@bugs.pypy.org>


lesshaste <drraph at gmail.com> added the comment:

Timing on my PC are 56 seconds for testham.py and 19 seconds for testham-unrolled.py

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue980>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 22:17:49 2012
From: tracker at bugs.pypy.org (cheecheeo)
Date: Wed, 04 Jan 2012 21:17:49 +0000
Subject: [pypy-issue] [issue974] channel is not iterable
In-Reply-To: <1325197954.47.0.841395160339.issue974@bugs.pypy.org>
Message-ID: <1325711869.57.0.231536023066.issue974@bugs.pypy.org>


cheecheeo <cheecheeo at gmail.com> added the comment:

You bring up a good point. In my use case, what I'm doing is:

while True:
    chan.recieve()
    ...

Which is essentially the same as blocking forever. I checked the source at
svn.python.org/project/stackless but was unable to find any additional
information. I've attached the patch which waits forever, let me know what you
think.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue974>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 22:27:43 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 04 Jan 2012 21:27:43 +0000
Subject: [pypy-issue] [issue961] Spurious (?) mercurial error messages from
	sandlib.py
In-Reply-To: <1323770170.93.0.478606769474.issue961@bugs.pypy.org>
Message-ID: <1325712463.81.0.694787640588.issue961@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Closing the bug, seems to fix the problem enough for people not to care :)

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue961>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 22:28:59 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 04 Jan 2012 21:28:59 +0000
Subject: [pypy-issue] [issue959] numpypy array operation improperly jitted
	away
In-Reply-To: <1323591319.1.0.0844617877376.issue959@bugs.pypy.org>
Message-ID: <1325712539.14.0.725253533522.issue959@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

There were other issues fixed in the meantime. I'll just close it unless someone 
wants to pursure

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue959>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 22:40:45 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 04 Jan 2012 21:40:45 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>


New submission from mikefc <coolbutuseless at gmail.com>:

Hi All,

Numpy is somewhat derived from another array library called 'Numeric'.  What were originally 
functions in 'Numeric' have been promoted to ndarray methods in numpy.  The implementation of 
this code in numpy is in numpy/core/fromnumeric.py. The list of functions that were promoted is 
listed at the end of this email.

However, these functions must be retained for compatibility, but all they should do is call the 
ndarray method.
e.g. "numpy.ravel(a)" is just a wrapper which returns "a.ravel()"

I have:
* copied all docstrings from numpy1.6 numpy/core/fromnumeric.py  into micronumpy/app_numpy.py
* for methods which we currently have (e.g. max, argmax), I have 
    * made the function just call the relavant method and return the value
    * written a test_fromnumeric_* using the docstring examples
* for methods which we don't have I have raised a NotImplemented Error

I realise that this is a lot of boring boilerplate code & docstrings, but I think it's to 
everyone's advantage to flesh out the micronumpy implementation a bit more so that we can see 
what has/hasn't been done. 

This will also be useful to newcomers - like me - who can now find obvious functions that need 
implementation.

Could someone please review, fix if necessary (or let me know what needs to be fixed) and commit.
Thanks.
Mike

======================
# __all__ = ['take', 'reshape', 'choose', 'repeat', 'put',
#            'swapaxes', 'transpose', 'sort', 'argsort', 'argmax', 'argmin',
#            'searchsorted', 'alen',
#            'resize', 'diagonal', 'trace', 'ravel', 'nonzero', 'shape',
#            'compress', 'clip', 'sum', 'product', 'prod', 'sometrue', 'alltrue',
#            'any', 'all', 'cumsum', 'cumproduct', 'cumprod', 'ptp', 'ndim',
#            'rank', 'size', 'around', 'round_', 'mean', 'std', 'var', 'squeeze',
#            'amax', 'amin',
#           ]

----------
files: numpypy_fromnumeric.patch
messages: 3640
nosy: mikefc, pypy-issue
priority: feature
status: unread
title: micronumpy 'fromnumeric' patch

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 22:47:21 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 04 Jan 2012 21:47:21 +0000
Subject: [pypy-issue] [issue982] micronumpy std()/var() patch
In-Reply-To: <1325713641.01.0.303957625766.issue982@bugs.pypy.org>
Message-ID: <1325713641.01.0.303957625766.issue982@bugs.pypy.org>


New submission from mikefc <coolbutuseless at gmail.com>:

Find attached a patch (to default branch) to add var and std to micronumpy 
BaseArray.  
Two simple tests were added, and all the micronumpy module tests still pass.

Feedback is welcome. Not sure if there's a better way of nesting the method 
calls in 
descr_var() - currently I have to do the calculation a bit at a time and after 
each 
calculation assert that what I get back is actually a BaseArray.

----------
messages: 3641
nosy: mikefc, pypy-issue
priority: feature
status: unread
title: micronumpy std()/var() patch

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue982>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 22:54:33 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 04 Jan 2012 21:54:33 +0000
Subject: [pypy-issue] [issue982] micronumpy std()/var() patch
In-Reply-To: <1325713641.01.0.303957625766.issue982@bugs.pypy.org>
Message-ID: <1325714073.66.0.854671297318.issue982@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

patch attached.

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue982>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 23:03:48 2012
From: tracker at bugs.pypy.org (Peter)
Date: Wed, 04 Jan 2012 22:03:48 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1325714628.47.0.354734244731.issue981@bugs.pypy.org>


Peter <p.j.a.cock at googlemail.com> added the comment:

This patch looks like it will address some of the missing NumPy functionality 
reported in issue 913

----------
nosy: +peterjc
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Fri Jan  6 21:11:06 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 06 Jan 2012 20:11:06 +0000
Subject: [pypy-issue] [issue983] Publish hashes for source archives
In-Reply-To: <1325880241.17.0.102890172075.issue983@bugs.pypy.org>
Message-ID: <1325880666.32.0.302353912048.issue983@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

fd0ad58b92ca0933c087bb93a82fda9e  release-1.7.tar.bz2
b4be3a8dc69cd838a49382867db3c41864b9e8d9  release-1.7.tar.bz2

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue983>
________________________________________

From tracker at bugs.pypy.org  Fri Jan  6 21:04:01 2012
From: tracker at bugs.pypy.org (Joshua Root)
Date: Fri, 06 Jan 2012 20:04:01 +0000
Subject: [pypy-issue] [issue983] Publish hashes for source archives
In-Reply-To: <1325880241.17.0.102890172075.issue983@bugs.pypy.org>
Message-ID: <1325880241.17.0.102890172075.issue983@bugs.pypy.org>


New submission from Joshua Root <jmr at macports.org>:

The download page currently lists hashes only for the binaries. Please provide 
hashes for the source archives as well. (GPG signatures for all of the above would 
be nice too.)

----------
messages: 3644
nosy: jmr, pypy-issue
priority: feature
release: 1.7
status: unread
title: Publish hashes for source archives

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue983>
________________________________________

From tracker at bugs.pypy.org  Fri Jan  6 21:23:37 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 06 Jan 2012 20:23:37 +0000
Subject: [pypy-issue] [issue983] Publish hashes for source archives
In-Reply-To: <1325880241.17.0.102890172075.issue983@bugs.pypy.org>
Message-ID: <1325881417.11.0.701296654522.issue983@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Closing either as "resolved" or as "wontfix", depending on your position.  I
suspect that the position of many pypy developers is "resolved".

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue983>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 07:36:18 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 07 Jan 2012 06:36:18 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1325918178.68.0.569238017316.issue981@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

This is v2 of the fromnumeric patch. (2 extra files are coming after this)

This version
* puts docstrings & adapted code from numpy/core/fromnumeric.py into 
micronumpy/app_fromnumeric.py  
* puts tests into micronumpy/test/test_fromnumeric.py
* moves the functions mean(), reshape() and sum() from app_numpy to 
app_fromnumeric.py (since they seem to originate from here in numpy)

The reason we can't just copy fromnumeric from numpy without changes is that none 
of the current BaseArray call signatures match numpy (e.g. axis arguments).  
Although, once the call signatures start to match a little better, the fromnumeric 
from python should be able to be copied across with only minor changes.  

I know that this does not move things to the lib_pypy/numpy as fijal has proposed, 
but I'm going to need some help to do that if that's the way numpypy is going.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 07:36:59 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 07 Jan 2012 06:36:59 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1325918219.95.0.929492076972.issue981@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

file = pypy/module/micronumpy/app_fromnumeric.py

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 07:37:37 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 07 Jan 2012 06:37:37 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1325918257.49.0.655474339743.issue981@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

file = pypy/module/micronumpy/test/test_fromnumeric.py

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 07:39:12 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 07 Jan 2012 06:39:12 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1325918352.18.0.340643986097.issue981@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

patch for current default branch:

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 11:32:57 2012
From: tracker at bugs.pypy.org (Chris Morgan)
Date: Sat, 07 Jan 2012 10:32:57 +0000
Subject: [pypy-issue] [issue984] 'make' can be 'mingw32-make' on MinGW
	platform
In-Reply-To: <1325932377.06.0.10518054436.issue984@bugs.pypy.org>
Message-ID: <1325932377.06.0.10518054436.issue984@bugs.pypy.org>


New submission from Chris Morgan <me at chrismorgan.info>:

On Windows when building with MinGW, the make command will sometimes be named
`mingw32-make.exe` instead of `make.exe`. This patch makes a check on the PATH
for mingw32-make first, and overrides make_cmd if it is there.

If this is considered a performance problem, the check could be delayed by
putting it in MingwPlatform.__init__.

----------
messages: 3651
nosy: Chris Morgan, pypy-issue
priority: bug
status: unread
title: 'make' can be 'mingw32-make' on MinGW platform

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue984>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 19:38:56 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 07 Jan 2012 18:38:56 +0000
Subject: [pypy-issue] [issue985] jit bug
In-Reply-To: <1325961536.04.0.318710394403.issue985@bugs.pypy.org>
Message-ID: <1325961536.04.0.318710394403.issue985@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

Running "pypy x.py" on the attached x.py throws it into an infinite loop. 
Tested on linux32, both the release 1.7.0 and the latest nightly build
(b67e65d709e1).

----------
files: x.py
messages: 3652
nosy: arigo, pypy-issue
priority: critical
status: unread
title: jit bug

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue985>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 19:48:46 2012
From: tracker at bugs.pypy.org (Dan Villiom Podlaski Christiansen)
Date: Sat, 07 Jan 2012 18:48:46 +0000
Subject: [pypy-issue] [issue986] Problems with timezones in datetime.datetime
In-Reply-To: <1325962126.17.0.405616334927.issue986@bugs.pypy.org>
Message-ID: <1325962126.17.0.405616334927.issue986@bugs.pypy.org>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

Try running the following little script:

=========
import datetime, os, time

os.putenv('TZ', 'GMT')

def bug():
  ct = time.time()
  delta = (datetime.datetime.utcfromtimestamp(ct) -
           datetime.datetime.fromtimestamp(ct))

  return delta.days * 86400 + delta.seconds

print ' '.join(str(bug()) for x in xrange(10))
===========

Under CPython I get:

===========
0 0 0 0 0 0 0 0 0 0
===========

Under PyPy 1.7 as well as the latest nightly I get something like:

===========
0 -1 0 -1 0 0 0 0 -1 0
===========

This is somewhat unexpected.

----------
messages: 3653
nosy: danchr, pypy-issue
priority: bug
release: 1.7
status: unread
title: Problems with timezones in datetime.datetime

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue986>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 19:53:27 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 07 Jan 2012 18:53:27 +0000
Subject: [pypy-issue] [issue986] Problems with timezones in datetime.datetime
In-Reply-To: <1325962126.17.0.405616334927.issue986@bugs.pypy.org>
Message-ID: <1325962407.09.0.0312936947488.issue986@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

This is (partly?) due to differences between datetime.py and the built-in
datetime of CPython.  If I replace "import datetime" with "import datetime1 as
datetime", with datetime1.py being a copy of datetime.py, then I get under
CPython a different list of -1's and 0's...

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue986>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 20:23:14 2012
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Sat, 07 Jan 2012 19:23:14 +0000
Subject: [pypy-issue] [issue987] AppTestSocket.test_unix_socket_connect can
	fail when	TMPDIR is long
In-Reply-To: <1325964194.81.0.726900366839.issue987@bugs.pypy.org>
Message-ID: <1325964194.81.0.726900366839.issue987@bugs.pypy.org>


New submission from Stefano Rivera <pypy at rivera.za.net>:

module/_socket/test/test_sock_app.py:

    def test_unix_socket_connect(self):
        import _socket, os
        if not hasattr(_socket, 'AF_UNIX'):
            skip('AF_UNIX not supported.')
        sockpath = os.path.join(self.udir, 'app_test_unix_socket_connect')
    
        serversock = _socket.socket(_socket.AF_UNIX)
>       serversock.bind(sockpath)
E       error: AF_UNIX path too long

module/_socket/test/test_sock_app.py:535: error

Patch attached.

----------
files: test_unix_socket_connect.patch
messages: 3655
nosy: pypy-issue, stefanor
priority: bug
status: unread
title: AppTestSocket.test_unix_socket_connect can fail when TMPDIR is long

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue987>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 21:03:19 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 07 Jan 2012 20:03:19 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1325966599.13.0.781196073915.issue981@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Hey. I created lib_pypy/numpypy which imports stuff from _numpypy that is a mixed 
module. Can you provide patch against the current trunk and move all the stuff 
there? That way we don't have to put things in appleveldefs and as well it's 
nicely changable after translation.

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 22:04:48 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 07 Jan 2012 21:04:48 +0000
Subject: [pypy-issue] [issue982] micronumpy std()/var() patch
In-Reply-To: <1325713641.01.0.303957625766.issue982@bugs.pypy.org>
Message-ID: <1325970288.96.0.961521499363.issue982@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Same as 981, please have a look at my addition to the discussion.

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue982>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 22:18:02 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 07 Jan 2012 21:18:02 +0000
Subject: [pypy-issue] [issue985] jit bug
In-Reply-To: <1325961536.04.0.318710394403.issue985@bugs.pypy.org>
Message-ID: <1325971082.76.0.0224913511597.issue985@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

For what is worth, it looks like it'll finish just very slowly. It's tracing with 
some absymal speed (and only tracing). We never reach the equivalent 
jit_merge_point somehow?

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue985>
________________________________________

From tracker at bugs.pypy.org  Sat Jan  7 22:25:32 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 07 Jan 2012 21:25:32 +0000
Subject: [pypy-issue] [issue985] jit bug
In-Reply-To: <1325961536.04.0.318710394403.issue985@bugs.pypy.org>
Message-ID: <1325971532.38.0.678991149259.issue985@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

The opcodes:


>>>> import dis
>>>> def f():
....  for c in x:
....   if c == '0':
....    pass
.... 
>>>> dis.dis(f)
  2           0 SETUP_LOOP              29 (to 32)
              3 LOAD_GLOBAL              0 (x)
              6 GET_ITER            
        >>    7 FOR_ITER                21 (to 31)
             10 STORE_FAST               0 (c)

  3          13 LOAD_FAST                0 (c)
             16 LOAD_CONST               1 ('0')
             19 COMPARE_OP               2 (==)
             22 POP_JUMP_IF_FALSE       28

  4          25 JUMP_ABSOLUTE            7
        >>   28 JUMP_ABSOLUTE            7
        >>   31 POP_BLOCK           
        >>   32 LOAD_CONST               0 (None)
             35 RETURN_VALUE        


It's slightly nonsense (2 JUMP_ABSOLUTES with the same target, and a POP_JUMP_IF_FALSE that goes to another jump, 
which is the same as the next opcode anyways), but I don't see why it would cause the backjump to be missed.

----------
nosy: +agaynor

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue985>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 00:35:14 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 07 Jan 2012 23:35:14 +0000
Subject: [pypy-issue] [issue982] micronumpy std()/var() patch
In-Reply-To: <1325713641.01.0.303957625766.issue982@bugs.pypy.org>
Message-ID: <1325979314.06.0.241072036393.issue982@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

This patch (v2) now only adds code for the ndarray var() and std() methods at the 
interp level.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue982>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 01:16:05 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 08 Jan 2012 00:16:05 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1325981765.68.0.471534473004.issue981@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

This patch (v3) puts a modified version of fromnumeric.py (from numpy/core) into 
lib_pypy/numpypy and adds tests in lib_pypy/numpypy/tests/.

(It is conditional upon the std()/var() patch from issue 981 already having been 
applied).

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 05:07:03 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 08 Jan 2012 04:07:03 +0000
Subject: [pypy-issue] [issue988] Fatal Rpython Error
In-Reply-To: <1325995623.87.0.0414919721821.issue988@bugs.pypy.org>
Message-ID: <1325995623.87.0.0414919721821.issue988@bugs.pypy.org>


New submission from mikefc <coolbutuseless at gmail.com>:

Fatal RPython error: AssertionError while testing a naive pure-python linalg cholesky 
function (attached).  Note: I'm running on latest OSX nightly.


============================================
RPython traceback:
  File "jit_metainterp_optimizeopt___init__.c", line 415, in optimize_trace
  File "jit_metainterp_optimizeopt_unroll.c", line 2712, in 
UnrollOptimizer_propagate_all_forward
  File "jit_metainterp_optimizeopt_optimizer.c", line 3789, in 
Optimizer_propagate_all_forward
  File "jit_metainterp_optimizeopt_pure.c", line 1564, in OptPure_optimize_default
  File "jit_metainterp_optimizeopt_fficall.c", line 1579, in OptFfiCall_optimize_CALL
  File "jit_metainterp_optimizeopt_fficall.c", line 7066, in OptFfiCall_do_getsetarrayitem
  File "jit_metainterp_optimizeopt_fficall.c", line 7654, in OptFfiCall__get_interior_descr
Fatal RPython error: AssertionError
Abort trap

----------
files: cholesky.py
messages: 3662
nosy: mikefc, pypy-issue
priority: bug
release: ???
status: unread
title: Fatal Rpython Error

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue988>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 05:25:55 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 08 Jan 2012 04:25:55 +0000
Subject: [pypy-issue] [issue989] Can't do ** on individual numpypy array
	element
In-Reply-To: <1325996755.5.0.946043909519.issue989@bugs.pypy.org>
Message-ID: <1325996755.5.0.946043909519.issue989@bugs.pypy.org>


New submission from mikefc <coolbutuseless at gmail.com>:

If a=numpy.array([1,2,3])  then a[1]**2 fails with a TypeError: operands do not 
support **

After looking at objspace/descroperation.py I figured that a[1]**np.array(2) works 
because the objects are of the same time.  I'm trying to see if I can fix it 
there, but don't hold your breath on my rpython expertise...

==================================
>>>> a = np.array([1,2,3])
>>>> a**2
array([1, 4, 9])
>>>> a[1]**2
Traceback (application-level):
  File "<inline>", line 1 in <module>
    a[1]**2
TypeError: operands do not support **
>>>> a[1]**np.array(2)
4

----------
messages: 3663
nosy: mikefc, pypy-issue
priority: bug
release: ???
status: unread
title: Can't do ** on individual numpypy array element

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue989>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 05:26:34 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 08 Jan 2012 04:26:34 +0000
Subject: [pypy-issue] [issue989] Can't do ** on individual numpypy array
	element
In-Reply-To: <1325996755.5.0.946043909519.issue989@bugs.pypy.org>
Message-ID: <1325996794.33.0.925554414047.issue989@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

s/same time/same type

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue989>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 11:01:43 2012
From: tracker at bugs.pypy.org (Dan Villiom Podlaski Christiansen)
Date: Sun, 08 Jan 2012 10:01:43 +0000
Subject: [pypy-issue] [issue986] Problems with timezones in datetime.datetime
In-Reply-To: <1325962126.17.0.405616334927.issue986@bugs.pypy.org>
Message-ID: <1326016903.07.0.616823010984.issue986@bugs.pypy.org>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

It's still a bug, though, isn't it?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue986>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 11:56:31 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 08 Jan 2012 10:56:31 +0000
Subject: [pypy-issue] [issue982] micronumpy std()/var() patch
In-Reply-To: <1325713641.01.0.303957625766.issue982@bugs.pypy.org>
Message-ID: <1326020191.9.0.145281827775.issue982@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Applied, thanks for the patch!

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue982>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 11:59:36 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 08 Jan 2012 10:59:36 +0000
Subject: [pypy-issue] [issue981] micronumpy 'fromnumeric' patch
In-Reply-To: <1325713245.85.0.375554978095.issue981@bugs.pypy.org>
Message-ID: <1326020376.55.0.304756269866.issue981@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Applied in 52ed6dd082e1, thanks!

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue981>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 14:16:24 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 08 Jan 2012 13:16:24 +0000
Subject: [pypy-issue] [issue988] Fatal Rpython Error
In-Reply-To: <1325995623.87.0.0414919721821.issue988@bugs.pypy.org>
Message-ID: <1326028584.72.0.266952520371.issue988@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Meh, took a while to find out :/ Seems the problem is really that some types are 
not implemented for the JIT to deal with (like C float) when accessing the 
arrays. And it seems assert False is not really a good way to signal an error.

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue988>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 14:16:47 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 08 Jan 2012 13:16:47 +0000
Subject: [pypy-issue] [issue988] Fatal Rpython Error
In-Reply-To: <1325995623.87.0.0414919721821.issue988@bugs.pypy.org>
Message-ID: <1326028607.39.0.290846684677.issue988@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Btw, feel like working on this? The example works just fine if you use float64 
instead of float32

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue988>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 14:32:00 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 08 Jan 2012 13:32:00 +0000
Subject: [pypy-issue] [issue989] Can't do ** on individual numpypy array
	element
In-Reply-To: <1325996755.5.0.946043909519.issue989@bugs.pypy.org>
Message-ID: <1326029520.88.0.472818321005.issue989@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

should be implemented in c14c5276c0e1, thanks!

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue989>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 14:34:12 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 08 Jan 2012 13:34:12 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1326029652.4.0.0180205286612.issue900@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

this is related to the fact that we don't know how to do processor pinning on 
windows, so we jump processors while still emitting RLTD or so

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue900>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 14:35:21 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 08 Jan 2012 13:35:21 +0000
Subject: [pypy-issue] [issue920] Lost data with async I/O
In-Reply-To: <1319482159.83.0.0983179975147.issue920@bugs.pypy.org>
Message-ID: <1326029721.15.0.941745827243.issue920@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Can we close it as not-a-bug?

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue920>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 16:20:56 2012
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Sun, 08 Jan 2012 15:20:56 +0000
Subject: [pypy-issue] [issue920] Lost data with async I/O
In-Reply-To: <1319482159.83.0.0983179975147.issue920@bugs.pypy.org>
Message-ID: <1326036056.46.0.14195914687.issue920@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

No, it's most certainly a bug. We ran across it in a testsuite that was failing 
weirdly on PyPy. I just haven't put time into trying to exercise all the code 
paths I was fixing in both cpython and pypy.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue920>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 21:18:17 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 08 Jan 2012 20:18:17 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1326053897.73.0.565516823432.issue900@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Added processor pinning in a7e8e37cbf30, can someone check whether this fixes the 
issue?

----------
status: chatting -> testing

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue900>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 22:09:34 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 08 Jan 2012 21:09:34 +0000
Subject: [pypy-issue] [issue988] Fatal Rpython Error
In-Reply-To: <1325995623.87.0.0414919721821.issue988@bugs.pypy.org>
Message-ID: <1326056974.27.0.193328099095.issue988@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Sure, I'll see what I can do.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue988>
________________________________________

From tracker at bugs.pypy.org  Sun Jan  8 22:15:28 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 08 Jan 2012 21:15:28 +0000
Subject: [pypy-issue] [issue988] Fatal Rpython Error
In-Reply-To: <1325995623.87.0.0414919721821.issue988@bugs.pypy.org>
Message-ID: <1326057328.35.0.969782299013.issue988@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

this is fixed now

----------
nosy: +agaynor
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue988>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  9 08:38:49 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 09 Jan 2012 07:38:49 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1326094729.52.0.295058289711.issue934@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

I'm running on latest OSX nightly and it does not hang, but I do get a 'build failed' error.


======================================
~/pypy-latest/bin/pypy ./waf configure clean build -p -j5
Setting top to                           : /Users/mike/python/bug934/build 
Setting out to                           : /Users/mike/python/bug934/build/out 
Checking for program g++,c++             : /usr/bin/g++ 
Checking for program ar                  : /usr/bin/ar 
Waf: Entering directory `/Users/mike/python/bug934/build/out'
Fatal error: pthread_cond_signal(&cond_gil)                                                                                  ]
[0.968s]
Fatal error: pthread_cond_signal(&cond_gil)                                                                                  ]
[1.594s]
[79/79][100%][\][===========================================================================================================>]
[2.603s]
Waf: Leaving directory `/Users/mike/python/bug934/build/out'
Build failed
 -> task failed (exit status -6): 
	{task 4354190936: cxx class_56.cpp -> class_56.cpp.1.o}
['/usr/bin/g++', '-I/Users/mike/python/bug934/build/out', '-I/Users/mike/python/bug934/build', '../lib_0/class_56.cpp', '-c', '-
o', 'lib_0/class_56.cpp.1.o']
 -> task failed (exit status -6): 
	{task 4354188808: cxx class_18.cpp -> class_18.cpp.1.o}
['/usr/bin/g++', '-I/Users/mike/python/bug934/build/out', '-I/Users/mike/python/bug934/build', '../lib_0/class_18.cpp', '-c', '-
o', 'lib_0/class_18.cpp.1.o']

----------
nosy: +mikefc
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue934>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  9 09:30:23 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 09 Jan 2012 08:30:23 +0000
Subject: [pypy-issue] [issue932] Python 1.7 slower on home maid path tracing
	than 1.6
In-Reply-To: <1321885098.48.0.0523238945198.issue932@bugs.pypy.org>
Message-ID: <1326097823.86.0.435797863886.issue932@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Confirmed on latest OSX nightly.  Just for comparison's sake - python takes 16 *minutes*

=================================================
time ~/pypy-1.6/bin/pypy smallpt.py 640 480 4
Rendering (4 spp) 99.84%
real	0m42.169s
user	0m41.967s
sys	0m0.123s

time ~/pypy-1.7/bin/pypy smallpt.py 640 480 4
Rendering (4 spp) 99.84%
real	1m3.213s
user	1m2.919s
sys	0m0.145s

time ~/pypy-latest/bin/pypy smallpt.py 640 480 4
Rendering (4 spp) 99.84%
real	0m57.183s
user	0m56.907s
sys	0m0.158s

time python smallpt.py 640 480 4
Rendering (4 spp) 99.84%
real	16m15.164s
user	16m9.654s
sys	0m1.109s

----------
nosy: +mikefc
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue932>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  9 10:04:51 2012
From: tracker at bugs.pypy.org (Ben Darnell)
Date: Mon, 09 Jan 2012 09:04:51 +0000
Subject: [pypy-issue] [issue990] pypy ssl module defaults to SSLv2 for
	client connections
In-Reply-To: <1326099891.63.0.494122499578.issue990@bugs.pypy.org>
Message-ID: <1326099891.63.0.494122499578.issue990@bugs.pypy.org>


New submission from Ben Darnell <ben at bendarnell.com>:

CPython's ssl module defaults to a hybrid mode that can connect to a server 
using SSLv3 or TLSv1.  pypy's ssl module appears to be defaulting to SSLv2, 
which is disabled on many servers.  This bug also has security implications, 
since SSLv2 has known weaknesses (especially when used client-side).

Steps to reproduce:
# generate a key
openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem
# start a TLSv1-only server
openssl s_server -cert cert.pem -msg -tls1
# in another terminal, try to connect
python -c 'import socket,ssl; 
ssl.wrap_socket(socket.create_connection(("localhost", 4433)))'
pypy -c 'import socket,ssl; 
ssl.wrap_socket(socket.create_connection(("localhost", 4433)))'

With cpython (2.7) it works (server shows a successful handshake followed by 
immediate close), but with pypy (1.7) the server says "SSL3_GET_RECORD:wrong 
version number:s3_pkt.c:350:" and closes the connection, and the client gets an 
exception.

----------
messages: 3679
nosy: bdarnell, pypy-issue
priority: bug
status: unread
title: pypy ssl module defaults to SSLv2 for client connections

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue990>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  9 10:05:05 2012
From: tracker at bugs.pypy.org (lekma)
Date: Mon, 09 Jan 2012 09:05:05 +0000
Subject: [pypy-issue] [issue991] [Feature Request]:
	Implement	PyErr_SetFromErrnoWithFilenameObject
In-Reply-To: <1326099905.08.0.543145843036.issue991@bugs.pypy.org>
Message-ID: <1326099905.08.0.543145843036.issue991@bugs.pypy.org>


New submission from lekma <lekmalek at gmail.com>:

Even though it's not documented on docs.python.org, it's a very useful CPython
function to associate an errno with a more detailed message (well, I abuse it
this way).

----------
messages: 3680
nosy: lekma, pypy-issue
priority: feature
status: unread
title: [Feature Request]: Implement PyErr_SetFromErrnoWithFilenameObject

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue991>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  9 10:45:21 2012
From: tracker at bugs.pypy.org (Ben Darnell)
Date: Mon, 09 Jan 2012 09:45:21 +0000
Subject: [pypy-issue] [issue990] pypy ssl module defaults to SSLv2 for
	client connections
In-Reply-To: <1326099891.63.0.494122499578.issue990@bugs.pypy.org>
Message-ID: <1326102321.82.0.614359645426.issue990@bugs.pypy.org>


Ben Darnell <ben at bendarnell.com> added the comment:

Nevermind, this difference is actually caused by the fact that on my system 
cpython is linked against a newer version of openssl than pypy.  Openssl 1.0 
changed the behavior of the default SSLv23 mode.

----------
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue990>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  9 22:21:12 2012
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Mon, 09 Jan 2012 21:21:12 +0000
Subject: [pypy-issue] [issue992] Manpage
In-Reply-To: <1326144072.92.0.766475322521.issue992@bugs.pypy.org>
Message-ID: <1326144072.92.0.766475322521.issue992@bugs.pypy.org>


New submission from Stefano Rivera <pypy at rivera.za.net>:

Debian likes having manpages for everything. Here's a very simple manpage (in 
RST, docutils can generate the troff manpage), if you are interested in including 
it.

----------
files: pypy.1.rst
messages: 3682
nosy: pypy-issue, stefanor
priority: wish
status: unread
title: Manpage

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue992>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  9 23:23:12 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 09 Jan 2012 22:23:12 +0000
Subject: [pypy-issue] [issue992] Manpage
In-Reply-To: <1326144072.92.0.766475322521.issue992@bugs.pypy.org>
Message-ID: <1326147792.62.0.0640473968816.issue992@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Would be cool if --jit describes briefly (or lists at least) parameters. it's --
jit v1=12,v2=13 btw

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue992>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  9 23:30:35 2012
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Mon, 09 Jan 2012 22:30:35 +0000
Subject: [pypy-issue] [issue993] threading.Lock.release performance
In-Reply-To: <1326148235.88.0.845507486958.issue993@bugs.pypy.org>
Message-ID: <1326148235.88.0.845507486958.issue993@bugs.pypy.org>


New submission from Vincent Pelletier <plr.vincent at gmail.com>:

I ran one of my projects[1] with pypy to check the performance increase compared
to cPython 2.7. pypy is at least 4 times faster. So far, so good.
When I ran cProfile under pypy, the functions using most time were Lock.acquire
and Lock.release.

A bit of background: 1480a is a usb protocol analyser[2], so it generates
traffic dumps which my module parses. It aggregates transactions using
"ply.yacc" pure python module. As I want to parse live capture and lpy.yacc
doesn't have an API allowing to push tokens individually, I use threads (one for
ply, and main interpreter thread for lower-level stream operations) and a custom
Queue.Queue variant (because profiling with cPython showed Queue locking scheme
to be very expensive, and I don't need the features it makes possible). See
iti1480a/parser.py:SimpleQueue for my implementation. As a test data set, I use
sample trace files provided with ITI's software (free as in beer, windows-only
but wine can install it fine).

Used command & output (timings provided as cross-reference between outputs):
$ time PYTHONPATH=/usr/lib/python2.7/dist-packages/ pypy-1.7/bin/pypy -m
iti1480a.bench < ~/.wine/drive_c/Program\ Files/International\ Test\
Instruments/1480A\ USB\ Protocol\ Analyzer/dvd_rw_drive.usb > /dev/null
real    0m4.147s
user    0m3.864s
sys     0m0.796s

Profiler stats, per thread:
Main thread (producer):
>>> p.sort_stats('cumulative').print_stats()
Mon Jan  9 19:59:59 2012    ../prof.out
         8238158 function calls (6884227 primitive calls) in 6.144 seconds
   Ordered by: cumulative time
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
  1122909    0.183    0.000    4.279    0.000 iti1480a/parser.py:634(__call__)
   521522    0.070    0.000    3.777    0.000 iti1480a/parser.py:668(rxcmd)
   260744    0.039    0.000    3.707    0.000 iti1480a/parser.py:590(__call__)
   260745    0.269    0.000    3.681    0.000 iti1480a/parser.py:28(put)
   260746    3.034    0.000    3.034    0.000 {method 'release' of 'thread.lock'
objects}
  1362123    0.772    0.000    1.478    0.000 iti1480a/parser.py:789(read16)
   601346    0.181    0.000    0.319    0.000 iti1480a/parser.py:663(data)
  1362290    0.293    0.000    0.293    0.000 {method 'read' of
'cStringIO.StringI' objects}
   260746    0.278    0.000    0.278    0.000 {method 'acquire' of 'thread.lock'
objects}
[...]

Second thread (consumer):
>>> p.sort_stats('cumulative').print_stats()
Mon Jan  9 19:59:59 2012    ../thread_prof.out
         5310276 function calls (4804628 primitive calls) in 7.947 seconds
   Ordered by: cumulative time
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
505629/260745    1.976    0.000    5.235    0.000 iti1480a/parser.py:20(get)
   489784    4.729    0.000    4.729    0.000 {method 'acquire' of 'thread.lock'
objects}
  1713792    0.489    0.000    0.489    0.000 {method 'append' of 'list' objects}
   856896    0.222    0.000    0.222    0.000 {method 'get' of 'dict' objects}
[...]

Here is my reading:
- ~2s of general imprecision from cProfile, as producer thread is supposed to
outlive consumer thread.
- total duration reported by cProfile (6 to 8s) shows similar imprecision
compared to "time" output
- producer thread main contention is lock.release
- consumer thread main contention is lock.acquire (though acquire is not a
bottleneck on producer side)
Generally, this means consumer spends most of its time waiting for producer
(this is what I expected). But also it means producer spends half of its run
time releasing the queue lock, and I find this surprising.
>From there, maybe acquire could be improved too, but it's harder to tell as it
is legitimate for it to block.

Asking on #pypy, I got the following answer:
< fijal> vpelletier: the problem is it is implemented in C and as such can't be
inlined by the JIT
< fijal> nor optimizations can be performed
< fijal> you could move parts of it to RPython
< fijal> and maybe even add some specialcasing to the JIT
< fijal> that would make things faster

Being new to pypy (and JIT in general), and after reading the code, I don't
think I can achieve anything by myself. So I decided to report this as a bug (as
fijal suggested too).

For completeness, I benchmarked Queue.Queue against my implementation (both
under pypy and without cProfile). To my great surprise, they are comparably fast:
Queue.Queue:
real    0m4.341s
user    0m3.976s
sys     0m1.060s
Custom implementation:
real    0m4.080s
user    0m3.920s
sys     0m0.644s

[1] https://github.com/vpelletier/ITI1480A-linux
[2] http://www.internationaltestinstruments.com/

----------
messages: 3684
nosy: pypy-issue, vpelletier
priority: performance bug
release: 1.7
status: unread
title: threading.Lock.release performance

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue993>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 10 10:08:37 2012
From: tracker at bugs.pypy.org (Twirrim)
Date: Tue, 10 Jan 2012 09:08:37 +0000
Subject: [pypy-issue] [issue994] significantly slow joins
In-Reply-To: <1326186517.7.0.712235447918.issue994@bugs.pypy.org>
Message-ID: <1326186517.7.0.712235447918.issue994@bugs.pypy.org>


New submission from Twirrim <paulgraydon at hotmail.com>:

I'm uncertain whether it's appropriate to raise this as a new bug.  It seems
tied to 866 (maybe?), but against 1.7 release and nightly (2012-01-10) this
particular case is significantly slower than python 2.7.2.

This started from what may be an ugly approach to problem 40 on Project Euler,
but after finding the speed problem I wanted to double check the cause so added
an extra benchmark:

slowjoin.py:
from time import time

start = time()
ir="0"
i=1
while (len(ir)<1000001):
    ir = ir+''.join(str(i))
    i=i+1
print time()-start

start = time()
ir="0"
i=1
# about the same number of loops
for i in range(1,185187):
    ir = str(i)
    i=i+1
print time()-start

CPython 2.7.2:
0.251733064651
0.0624940395355

PyPy 1.7:
23.9713470936
0.0105218887329

PyPy Nightly (2012-01-10):
24.7200191021
0.010559797287

----------
messages: 3685
nosy: Twirrim, pypy-issue
priority: performance bug
release: 1.7
status: unread
superseder: [PATCH] join is slow about 2x slower than Python
title: significantly slow joins

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue994>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 10 11:09:19 2012
From: tracker at bugs.pypy.org (timo)
Date: Tue, 10 Jan 2012 10:09:19 +0000
Subject: [pypy-issue] [issue994] significantly slow joins
In-Reply-To: <1326186517.7.0.712235447918.issue994@bugs.pypy.org>
Message-ID: <1326190159.34.0.158129698146.issue994@bugs.pypy.org>


timo <timonator at perpetuum-immobile.de> added the comment:

this is not about join being slow. in fact, this code:

start = time()
ir="0"
i=1
while (len(ir)<1000001):
    ir = ir+str(i) # without ''.join, which should be a no-op anyway
    i=i+1
print time()-start

which does exactly the same thing takes almost exactly the same time (although
my machine was under heavy, but constant load when I tried it - the pypy version
is quite old, too, though)

this is more about general string concatenation being slow on pypy.

----------
nosy: +timo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue994>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 10 11:28:08 2012
From: tracker at bugs.pypy.org (timo)
Date: Tue, 10 Jan 2012 10:28:08 +0000
Subject: [pypy-issue] [issue994] significantly slow joins
In-Reply-To: <1326186517.7.0.712235447918.issue994@bugs.pypy.org>
Message-ID: <1326191288.54.0.477688770207.issue994@bugs.pypy.org>


timo <timonator at perpetuum-immobile.de> added the comment:

FWIW, issue926 might be interesting to you. If translating your pypy with the
strbuf objspace option gives you an immense speed boost, you'll know what's up.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue994>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 10 13:19:40 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 10 Jan 2012 12:19:40 +0000
Subject: [pypy-issue] [issue995] jit bug with threads
In-Reply-To: <1326197980.33.0.665170552495.issue995@bugs.pypy.org>
Message-ID: <1326197980.33.0.665170552495.issue995@bugs.pypy.org>


New submission from Fijal <fijall at gmail.com>:

On branch look-into-thread running x.py yields: 
http://paste.pocoo.org/show/532768/ or sometimes a segfault

----------
messages: 3688
nosy: fijal, pypy-issue
priority: bug
status: unread
title: jit bug with threads

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue995>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 10 15:01:26 2012
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Tue, 10 Jan 2012 14:01:26 +0000
Subject: [pypy-issue] [issue992] Manpage
In-Reply-To: <1326144072.92.0.766475322521.issue992@bugs.pypy.org>
Message-ID: <1326204086.32.0.675470740306.issue992@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

Applied in e8239b6167fa

----------
assignedto:  -> stefanor
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue992>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 10 18:20:51 2012
From: tracker at bugs.pypy.org (Tristan Seligmann)
Date: Tue, 10 Jan 2012 17:20:51 +0000
Subject: [pypy-issue] [issue996] sqlite3 CREATE TABLE always fails
In-Reply-To: <1326216051.55.0.901484837189.issue996@bugs.pypy.org>
Message-ID: <1326216051.55.0.901484837189.issue996@bugs.pypy.org>


New submission from Tristan Seligmann <mithrandi at mithrandi.net>:

Attaching a script to demonstrate the issue; the CREATE TABLE fails with "table
already exists" in an empty database.

----------
messages: 3690
nosy: mithrandi, pypy-issue
priority: bug
status: unread
title: sqlite3 CREATE TABLE always fails

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue996>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 10 20:23:54 2012
From: tracker at bugs.pypy.org (Tristan Seligmann)
Date: Tue, 10 Jan 2012 19:23:54 +0000
Subject: [pypy-issue] [issue997] PyCrypto fails to build with pypy/cpyext
In-Reply-To: <1326223434.41.0.93637834694.issue997@bugs.pypy.org>
Message-ID: <1326223434.41.0.93637834694.issue997@bugs.pypy.org>


New submission from Tristan Seligmann <mithrandi at mithrandi.net>:

PyCrypto is an (optional) Twisted dependency. I'll attach the build log
demonstrating the failure.

----------
messages: 3691
nosy: mithrandi, pypy-issue
priority: wish
status: unread
title: PyCrypto fails to build with pypy/cpyext

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue997>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 10 23:20:11 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 10 Jan 2012 22:20:11 +0000
Subject: [pypy-issue] [issue997] PyCrypto fails to build with pypy/cpyext
In-Reply-To: <1326223434.41.0.93637834694.issue997@bugs.pypy.org>
Message-ID: <1326234011.05.0.982589510543.issue997@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Unfortunately PyCrypto accesses the internal representation of PyLong objects, which pypy cannot expose.  This part of 
PyCrypto (in _fastmath.c: mpzToLongObj and longObjToMPZ) has to be modified before pypy can compile this module.

Unfortunately the CPython API does not provide many alternatives.  _PyLong_FromByteArray() could be used, but it requires 
an additional copy and would be slower.

The best would be to invent a new CPython API: PyLong_GET_DIGITS() and PyLong_GET_SIZE(), which PyPy could implement like 
the string object and allow a mutable buffer until the object exits the function.

----------
nosy: +afa
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue997>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 01:06:46 2012
From: tracker at bugs.pypy.org (Richard Lobb)
Date: Wed, 11 Jan 2012 00:06:46 +0000
Subject: [pypy-issue] [issue960] Sandboxing for external function
	'pypy__float2longlong'
In-Reply-To: <1323769467.96.0.033518261053.issue960@bugs.pypy.org>
Message-ID: <1326240406.01.0.304346713212.issue960@bugs.pypy.org>


Richard Lobb <trampgeek at gmail.com> added the comment:

Many thank, Armin. I can't find that commit any more -- I assume it has been 
merged into the trunk -- but the problem has gone from the trunk. [Sorry about 
the delay in responding. Just back from holiday.]

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue960>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 02:55:26 2012
From: tracker at bugs.pypy.org (Richard Lobb)
Date: Wed, 11 Jan 2012 01:55:26 +0000
Subject: [pypy-issue] [issue961] Spurious (?) mercurial error messages from
	sandlib.py
In-Reply-To: <1323770170.93.0.478606769474.issue961@bugs.pypy.org>
Message-ID: <1326246926.44.0.669464246672.issue961@bugs.pypy.org>


Richard Lobb <trampgeek at gmail.com> added the comment:

Yes, thanks Armin and Fijal. That problem seems to have gone too.

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue961>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 05:29:57 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 11 Jan 2012 04:29:57 +0000
Subject: [pypy-issue] [issue998] numpypy app level module layout fix (patch
	attached)
In-Reply-To: <1326256197.34.0.850582918188.issue998@bugs.pypy.org>
Message-ID: <1326256197.34.0.850582918188.issue998@bugs.pypy.org>


New submission from mikefc <coolbutuseless at gmail.com>:

A simple patch to the applevel numpypy module.

* move fromnumeric into numpypy/core/  (as it is in numpy)
* add a __version__ string  "numpypy-1.6.1" (needed by numpy testing infrastructure)
* add a transpose function that calls the interp level method. (also added test for this)
* change NotImplemented()s to NotImplementedError()s.  oops.

----------
files: numpypy_app_layout.patch
messages: 3695
nosy: mikefc, pypy-issue
priority: feature
release: ???
status: unread
title: numpypy app level module layout fix (patch attached)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue998>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 05:34:27 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 11 Jan 2012 04:34:27 +0000
Subject: [pypy-issue] [issue998] numpypy app level module layout fix (patch
	attached)
In-Reply-To: <1326256197.34.0.850582918188.issue998@bugs.pypy.org>
Message-ID: <1326256467.68.0.169680013471.issue998@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

A few things:

a) Can we please use explicit relative imports, rather than implict ones.
b) It doesn't seem correct to me to have AppTests in lib_pypy.

----------
nosy: +agaynor
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue998>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 07:57:36 2012
From: tracker at bugs.pypy.org (Twirrim)
Date: Wed, 11 Jan 2012 06:57:36 +0000
Subject: [pypy-issue] [issue994] significantly slow joins
In-Reply-To: <1326186517.7.0.712235447918.issue994@bugs.pypy.org>
Message-ID: <1326265056.72.0.506121757227.issue994@bugs.pypy.org>


Twirrim <paulgraydon at hotmail.com> added the comment:

That would be it, translated using --objspace-std-withstrbuf:
0.0973238945007s for the ugly join method.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue994>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 09:44:05 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 11 Jan 2012 08:44:05 +0000
Subject: [pypy-issue] [issue960] Sandboxing for external function
	'pypy__float2longlong'
In-Reply-To: <1323769467.96.0.033518261053.issue960@bugs.pypy.org>
Message-ID: <1326271445.47.0.0293486790433.issue960@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

reclosing

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue960>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 09:44:25 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 11 Jan 2012 08:44:25 +0000
Subject: [pypy-issue] [issue961] Spurious (?) mercurial error messages from
	sandlib.py
In-Reply-To: <1323770170.93.0.478606769474.issue961@bugs.pypy.org>
Message-ID: <1326271465.71.0.540738169608.issue961@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

reclosing

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue961>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 10:37:29 2012
From: tracker at bugs.pypy.org (Garen Parham)
Date: Wed, 11 Jan 2012 09:37:29 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1326274649.26.0.632023565549.issue900@bugs.pypy.org>


Garen Parham <garen.p at gmail.com> added the comment:

The problem is still present as of 409a8b279f54 from the 1/10 nightly.  

I do see the affinity is set correctly (pypy.exe only shows CORE-0 active) but 
for whatever reason the negative tottime value still comes back in the results.  

Some side thoughts, based on:
  https://bitbucket.org/pypy/pypy/changeset/a7e8e37cbf30

* If the process affinity mask only has 1 bit set, no work needs to be done 
(means process can only run on at most 1 CPU)
* Return codes for GetProcessAffinityMask() and SetProcessAffinityMask() aren't 
inspected for error codes--there is a permission/privilege required (not 
relevant for my test though afaict).
* Won't work for systems with > 32 CPUs, need to use process groups. 
* IIRC I thought the "supported" way to do this is by first calling 
QueryPerformanceCounter() and QueryPerformanceFrequency() which presumably 
selects the best available hardware/instruction(s) for recording timestamps and 
accounts for frequency scaling issues (e.g. power management, turbo boost, speed 
step, ...)

This MS link seems to support using QueryPerformance*:

http://msdn.microsoft.com/en-us/library/windows/desktop/ee417693(v=vs.85).aspx

Hope that helps.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue900>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 17:08:10 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 11 Jan 2012 16:08:10 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1326298090.16.0.217485268428.issue900@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

QueryPerformanceCounter is definitely not the best. Right now we directly embed 
RTLD instruction in the assembler, which is much faster than have a call there. 
Inlined function calls can be very cheap on pypy - down to few assembler 
instructions. In this case having the overhead of two calls (for start and end) 
is not acceptable. It seems that affinity setting does not work, the x86 docs 
clearly state what RTLD will return and it has to be a monotonic counter for 
that processor.

Cheers,
fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue900>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 11 23:36:43 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 11 Jan 2012 22:36:43 +0000
Subject: [pypy-issue] [issue998] numpypy app level module layout fix (patch
	attached)
In-Reply-To: <1326256197.34.0.850582918188.issue998@bugs.pypy.org>
Message-ID: <1326321403.22.0.17441596736.issue998@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

A simple patch for the layout of the applevel numpypy module. Updated with Alex's 
suggestions.

* move numpypy/fromnumeric.py to numpypy/core/fromnumeric.py (as it is in numpy)
* move numpypy/test/test_fromnumeric.py to 
pypy/module/test_lib_pypy/test_numpypy/core/test_fromnumeric.py
* now using explicit relative imports
* add a __version__ string  "numpypy-1.6.1" (needed by numpy testing infrastructure)
* add a transpose function that calls the interp level method. (also added test for 
this)
* change NotImplemented()s to NotImplementedError()s.  oops.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue998>
________________________________________

From tracker at bugs.pypy.org  Wed Jan  4 19:35:15 2012
From: tracker at bugs.pypy.org (Simon Hova)
Date: Wed, 04 Jan 2012 18:35:15 +0000
Subject: [pypy-issue] [issue979] Pickle fails in pypy, works in CPython
In-Reply-To: <1325694743.04.0.41876802496.issue979@bugs.pypy.org>
Message-ID: <1325702115.13.0.873612458152.issue979@bugs.pypy.org>


Simon Hova <Simon at hova.net> added the comment:

EDI File parser.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue979>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 12 16:43:44 2012
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Thu, 12 Jan 2012 15:43:44 +0000
Subject: [pypy-issue] [issue999] rename virtualizable2 to virtualizable
In-Reply-To: <1326383024.25.0.72133139277.issue999@bugs.pypy.org>
Message-ID: <1326383024.25.0.72133139277.issue999@bugs.pypy.org>


New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:

to make things slightly less confusing

----------
messages: 3703
nosy: cfbolz, pypy-issue
priority: wish
status: unread
title: rename virtualizable2 to virtualizable

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue999>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 12 18:36:41 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Thu, 12 Jan 2012 17:36:41 +0000
Subject: [pypy-issue] [issue996] sqlite3 CREATE TABLE always fails
In-Reply-To: <1326216051.55.0.901484837189.issue996@bugs.pypy.org>
Message-ID: <1326389801.06.0.190272278843.issue996@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

Confirmed with PyPy 1.7.

If I change ':memory:' to '/tmp/foo.db', I still get the "table already exists"
error.

But then:
$ sqlite3 /tmp/foo.db
sqlite> .tables
foo
sqlite> .schema foo
CREATE TABLE foo (bar INTEGER);

shows that the table was actually created fine, and the error was incorrect.

----------
nosy: +dripton
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue996>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 13 12:25:22 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 13 Jan 2012 11:25:22 +0000
Subject: [pypy-issue] [issue985] jit bug
In-Reply-To: <1325961536.04.0.318710394403.issue985@bugs.pypy.org>
Message-ID: <1326453922.28.0.73386056282.issue985@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Hacked in b09a9354d977 a temporary workaround.  It works in that it solves the
issue.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue985>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 15 05:35:03 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 15 Jan 2012 04:35:03 +0000
Subject: [pypy-issue] [issue1000] creating numpypy array from list with None
	elements
In-Reply-To: <1326602103.1.0.102153689611.issue1000@bugs.pypy.org>
Message-ID: <1326602103.1.0.102153689611.issue1000@bugs.pypy.org>


New submission from mikefc <coolbutuseless at gmail.com>:

Creating numpypy array from a list with elements which are None fails on numpypy but 
succeeds on numpy.


=========  CPython & numpy
>>> import numpy as np
>>> np.array([1,None,3], dtype='float32')
array([  1.,  nan,   3.], dtype=float32)

========= pypy & numpypy
>>>> import numpypy as np
>>>> np.array([1,None,3], dtype='float32')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: expected float, got NoneType object

----------
messages: 3706
nosy: mikefc, pypy-issue
priority: bug
release: ???
status: unread
title: creating numpypy array from list with None elements

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1000>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 15 09:27:20 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 15 Jan 2012 08:27:20 +0000
Subject: [pypy-issue] [issue1000] creating numpypy array from list with None
	elements
In-Reply-To: <1326602103.1.0.102153689611.issue1000@bugs.pypy.org>
Message-ID: <1326616040.23.0.29638085104.issue1000@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Such an awesome feature, numpy doesn't stop to amaze me.

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1000>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 15 23:56:01 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 15 Jan 2012 22:56:01 +0000
Subject: [pypy-issue] [issue996] sqlite3 CREATE TABLE always fails
In-Reply-To: <1326216051.55.0.901484837189.issue996@bugs.pypy.org>
Message-ID: <1326668161.86.0.549687385627.issue996@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

For what is worth it's _sqlite3.py problem, not pypy's, looking

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue996>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 17 16:22:32 2012
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Tue, 17 Jan 2012 15:22:32 +0000
Subject: [pypy-issue] [issue1001] Improve RPython documentation
In-Reply-To: <1326813752.88.0.980636366886.issue1001@bugs.pypy.org>
Message-ID: <1326813752.88.0.980636366886.issue1001@bugs.pypy.org>


New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:

We should try to make the RPython documentation better. Here's a list of some
things that Laurie had a hard time figuring out:

- "The difference / relation between the various typing systems
  (rffi.INT, r_int etc.) are a mystery to me."

- exact semantics of lists, e.g. when things are resizable and how
  make_sure_not_resized is used, what about the negative indexes

- how does specialization work, and what can it be used for?

- what are the exact GC semantics?

----------
messages: 3709
nosy: cfbolz, pypy-issue
priority: feature
status: unread
title: Improve RPython documentation

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1001>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 17 16:22:46 2012
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Tue, 17 Jan 2012 15:22:46 +0000
Subject: [pypy-issue] [issue1002] Improve JIT documentation
In-Reply-To: <1326813766.47.0.664107100312.issue1002@bugs.pypy.org>
Message-ID: <1326813766.47.0.664107100312.issue1002@bugs.pypy.org>


New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:

Applying the JIT to an interpreter should have some better documentation. All
the information is basically there (in blog posts, papers, docstrings, tests
etc) but not really organized/approachable:

- which tools are there to inspect generated traces
- what are the basic hints that can be given via the jit driver?
- when is using unroll_safe a good idea?
- how to use virtualizables?
  - what are the exact restrictions on their use?
  - what to do when tracing stops most of the time due to a virtualizable escape
  - hint(self, access_directly=True, fresh_virtualizable=True)
  - how do virtualrefs work?

- what are quasi-immutable fields?

----------
messages: 3710
nosy: cfbolz, pypy-issue
priority: feature
status: unread
title: Improve JIT documentation

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1002>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 07:36:18 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 18 Jan 2012 06:36:18 +0000
Subject: [pypy-issue] [issue998] numpypy app level module layout fix (patch
	attached)
In-Reply-To: <1326256197.34.0.850582918188.issue998@bugs.pypy.org>
Message-ID: <1326868578.11.0.888079152819.issue998@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

changes pushed into default branch (by me)

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue998>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 11:38:20 2012
From: tracker at bugs.pypy.org (Peter)
Date: Wed, 18 Jan 2012 10:38:20 +0000
Subject: [pypy-issue] [issue913] Reduce-like *functions* for micronumpy
	missing, e.g. numpy.dot
In-Reply-To: <1318946612.94.0.137292123198.issue913@bugs.pypy.org>
Message-ID: <1326883100.93.0.260233074021.issue913@bugs.pypy.org>


Peter <p.j.a.cock at googlemail.com> added the comment:

Note in the original report I had a typo, I mean to reference Issue 785 not 758
for numpy array reduce methods.

----------
nosy: +peterjc
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue913>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 11:50:31 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 18 Jan 2012 10:50:31 +0000
Subject: [pypy-issue] [issue913] Reduce-like *functions* for micronumpy
	missing, e.g. numpy.dot
In-Reply-To: <1318946612.94.0.137292123198.issue913@bugs.pypy.org>
Message-ID: <1326883831.59.0.799894719364.issue913@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

If you try a nightly, some of these functions have been added - 
http://buildbot.pypy.org/nightly/trunk/

numpypy is a work in progress and I'm not sure that filing issues for all the 
things that are missing is going to do anything other than create a lot of items 
in the issuetracker. 

There is work in progress to have the status of numpypy thrown onto the web, so 
you'll be able to see which functions are currently available.  Stay tuned.

----------
nosy: +mikefc

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue913>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 15:57:42 2012
From: tracker at bugs.pypy.org (Paul Crowley)
Date: Wed, 18 Jan 2012 14:57:42 +0000
Subject: [pypy-issue] [issue1003] Sandbox code uses no-longer-working seccom
In-Reply-To: <1326898662.41.0.324668365239.issue1003@bugs.pypy.org>
Message-ID: <1326898662.41.0.324668365239.issue1003@bugs.pypy.org>


New submission from Paul Crowley <paul at lshift.net>:

If the os_level_sandboxing flag in pypy.translator.sandbox.sandlib.SandboxedProc 
is set to True, the sandbox tries to turn on "seccomp" for the sandboxed child 
process.  However, it attempts to do so by writing to "/proc/<pid>/seccomp", 
which has been removed from modern kernels.  Instead the child process must call 
prctl on itself to harden the sandbox at the OS level. 
http://en.wikipedia.org/wiki/Seccomp

----------
messages: 3714
nosy: ciphergoth, pypy-issue
priority: feature
status: unread
title: Sandbox code uses no-longer-working seccom

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1003>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 16:17:56 2012
From: tracker at bugs.pypy.org (Paul Crowley)
Date: Wed, 18 Jan 2012 15:17:56 +0000
Subject: [pypy-issue] [issue1004] Sandbox only works for single-threaded code
In-Reply-To: <1326899876.87.0.633218492473.issue1004@bugs.pypy.org>
Message-ID: <1326899876.87.0.633218492473.issue1004@bugs.pypy.org>


New submission from Paul Crowley <paul at lshift.net>:

In the sandbox, two remoted library calls cannot be "in flight" at once; the 
protocol between the sandbox process and the parent process gives no way to 
identify which reply applies to which call under such circumstances.  So there's 
currently no way to write a multithreaded sandboxed application.

----------
messages: 3715
nosy: ciphergoth, pypy-issue
priority: feature
status: unread
title: Sandbox only works for single-threaded code

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1004>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 16:37:50 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 18 Jan 2012 15:37:50 +0000
Subject: [pypy-issue] [issue1005] numpypy array constructor doesn't handle
	string dtype
In-Reply-To: <1326901070.8.0.263518291606.issue1005@bugs.pypy.org>
Message-ID: <1326901070.8.0.263518291606.issue1005@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> np.array([1,2,3],'float')
array([ 1.,  2.,  3.])

>>>> np.array([1,2,3],'float')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: data type not understood

----------
messages: 3716
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy array constructor doesn't handle string dtype

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1005>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 16:38:57 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 18 Jan 2012 15:38:57 +0000
Subject: [pypy-issue] [issue1006] numpypy array(1).reshape(1,1) fails
In-Reply-To: <1326901137.81.0.0583721843168.issue1006@bugs.pypy.org>
Message-ID: <1326901137.81.0.0583721843168.issue1006@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> np.array(1).reshape(1,1)
array([[1]])
>>>> np.array(1).reshape(1,1)
RPython traceback:
  File "interpreter_gateway.c", line 554, in BuiltinCode_funcrun_obj
  File "implement_22.c", line 26204, in
BuiltinActivation_UwS_BaseArray_ObjSpace_args_w_
  File "module_micronumpy_interp_numarray.c", line 51133, in BaseArray_descr_reshape
Fatal RPython error: NotImplementedError
Aborted

----------
messages: 3717
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy array(1).reshape(1,1) fails

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1006>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 16:55:49 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 18 Jan 2012 15:55:49 +0000
Subject: [pypy-issue] [issue1007] add "fill" method for numpypy array
In-Reply-To: <1326902149.59.0.425351764886.issue1007@bugs.pypy.org>
Message-ID: <1326902149.59.0.425351764886.issue1007@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

the method is quite easy to implement, yet very important - it is encountered
very often.
>>> a = empty((2,3))
>>> a.fill(0.5)
>>> a
array([[ 0.5,  0.5,  0.5],
       [ 0.5,  0.5,  0.5]])
b=empty(4,bool)
>>> b.fill(False)
>>> b
array([False, False, False, False], dtype=bool)

----------
messages: 3718
nosy: Dmitrey, pypy-issue
priority: wish
status: unread
title: add "fill" method for numpypy array

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1007>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 17:14:42 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 18 Jan 2012 16:14:42 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

Code in the attached file. I have wrote it without looking into numpy sources -
seems like the funcs are implemented somewhere in C or Cython code.

----------
messages: 3719
nosy: Dmitrey, pypy-issue
priority: feature
status: unread
title: numpypy: commit the code for empty_like, zeros_like, ones_like

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 17:23:04 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 18 Jan 2012 16:23:04 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1326903784.26.0.353014790884.issue1008@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

there is no attached file...

----------
nosy: +afa
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 17:26:20 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 18 Jan 2012 16:26:20 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1326903980.52.0.153511355912.issue1008@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

Somehow it doesn't want to be attached. I put it here:
http://pastebin.com/q7RYRnuS

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 18:15:40 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 18 Jan 2012 17:15:40 +0000
Subject: [pypy-issue] [issue1005] numpypy array constructor doesn't handle
	string dtype
In-Reply-To: <1326901070.8.0.263518291606.issue1005@bugs.pypy.org>
Message-ID: <1326906940.79.0.873017700732.issue1005@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Fixed in 923df65f2286

----------
nosy: +agaynor
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1005>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 18:53:06 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 18 Jan 2012 17:53:06 +0000
Subject: [pypy-issue] [issue1007] add "fill" method for numpypy array
In-Reply-To: <1326902149.59.0.425351764886.issue1007@bugs.pypy.org>
Message-ID: <1326909186.95.0.775497561517.issue1007@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Fixed in 36de78269626

----------
nosy: +agaynor
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1007>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 19:30:31 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 18 Jan 2012 18:30:31 +0000
Subject: [pypy-issue] [issue1009] numpypy ndarray bug "TypeError: 'flatiter'
	object is not	subscriptable"
In-Reply-To: <1326911431.89.0.640231229059.issue1009@bugs.pypy.org>
Message-ID: <1326911431.89.0.640231229059.issue1009@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

This bug prevents me to port numpy.diag(), creating walkaround here seems to be
bad idea.
>>> a=N.ones((4,4))
>>> a.flat[2]
1.0
>>>> a=N.ones((4,4))
>>>> a.flat[2]
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: 'flatiter' object is not subscriptable

----------
messages: 3724
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy ndarray bug "TypeError: 'flatiter' object is not subscriptable"

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1009>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 19:57:13 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 18 Jan 2012 18:57:13 +0000
Subject: [pypy-issue] [issue1009] numpypy ndarray bug "TypeError: 'flatiter'
	object is not	subscriptable"
In-Reply-To: <1326911431.89.0.640231229059.issue1009@bugs.pypy.org>
Message-ID: <1326913033.15.0.147765305027.issue1009@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Here's some tests for anyone interested in looking into this: 
http://paste.pocoo.org/show/536857/

----------
nosy: +agaynor
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1009>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 21:00:14 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Wed, 18 Jan 2012 20:00:14 +0000
Subject: [pypy-issue] [issue986] Problems with timezones in datetime.datetime
In-Reply-To: <1325962126.17.0.405616334927.issue986@bugs.pypy.org>
Message-ID: <1326916814.39.0.63892417314.issue986@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

dupe of 972

----------
nosy: +dripton

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue986>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 21:10:32 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Wed, 18 Jan 2012 20:10:32 +0000
Subject: [pypy-issue] [issue972] inconsistency with cpython (datetime?)
In-Reply-To: <1324497118.49.0.15609286849.issue972@bugs.pypy.org>
Message-ID: <1326917432.12.0.208488972771.issue972@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

pypy/lib_pypy/pypy_test/test_datetime.py has an existing failure in function
test_more_datetime_rounding, which casts doubts on the current implementation.

pypy_pypy/datetime.py's fromtimestamp and utcfromtimestamp have subtly different
rounding code.  If I change fromtimestamp's rounding code to be like
utcfromtimestamp's, or vice versa, then the problem goes away.

Which is more correct?  I believe fromstampstamp's is, based on ancient commit
comments in
http://svn.python.org/view/sandbox/trunk/datetime/datetime.py?view=log  I
believe Tim Peters tweaked fromtimestamp to be more correct in some obscure edge
cases, but failed to change utcfromtimestamp to match.

I think I have a good fix, but I will test it some more, and also fix the unit
test, then submit a patch or a pull request.

----------
nosy: +dripton
title: inconsistence with cpython (datetime?) -> inconsistency with cpython (datetime?)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue972>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 21:16:00 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 18 Jan 2012 20:16:00 +0000
Subject: [pypy-issue] [issue972] inconsistency with cpython (datetime?)
In-Reply-To: <1324497118.49.0.15609286849.issue972@bugs.pypy.org>
Message-ID: <1326917760.49.0.63104297937.issue972@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

CPython 3.2 also has a datetime.py.  Does it show the same behavior?  If yes, you 
could also propose your patch to the CPython bug tracker.

----------
nosy: +afa

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue972>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 21:42:16 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Wed, 18 Jan 2012 20:42:16 +0000
Subject: [pypy-issue] [issue972] inconsistency with cpython (datetime?)
In-Reply-To: <1324497118.49.0.15609286849.issue972@bugs.pypy.org>
Message-ID: <1326919336.66.0.400252378126.issue972@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

CPython 3.2 datetime.py has a fix to utcfromtimestamp, from 2010.  Copying that
function from CPython 3.2's version to lib_pypy's version works.

Here's a patch with that change.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue972>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 18 22:00:33 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 18 Jan 2012 21:00:33 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

Code has been taken from CPython numpy and a little bit reworked for current
numpypy implementation.
http://pastebin.com/9CN0k9Tx

----------
messages: 3730
nosy: Dmitrey, pypy-issue
priority: feature
status: unread
title: numpypy: commit the code for array_equal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1010>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 02:40:38 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 19 Jan 2012 01:40:38 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1326937238.61.0.876632761027.issue1008@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Some points for discussion:
* pypy is developed with TDD, so there will need to be test functions along with 
each new function/method.  (See 
pypy/module/test_lib_pypy/numpypy/core/test_fromnumeric.py for some simple tests I 
wrote).
* Are we going to want some of these functions at App level or interp level?  I 
know it's easy to write them at app level, but where do we want to draw the line 
between the two?  Where is the speed of interp level going to matter versus the 
speed of getting code written?
* There may need to be a refactor of the interp level numpypy layout.   
interp_numarray.py is going to get very crowded as more and more is added.  Should 
the numpy layout be mirrored here (as in the app level module)?

----------
nosy: +mikefc

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 02:48:34 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 19 Jan 2012 01:48:34 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1326937714.24.0.688851724346.issue1010@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Similar to issue1008,  this function may be better at the interp level rather than 
the applevel.

----------
nosy: +mikefc
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1010>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 09:25:50 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 19 Jan 2012 08:25:50 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1326961550.97.0.729666849195.issue1008@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

As for App vs interp level: I think currently numpypy should focus on
functionality (this is what it lacks), not speed (of course, I don't mean
something like committing O(n**2) algorithms where CPython numpy has O(n log
n)). Thus easier approach should be preferred (App level), when someone will
have better implementation, related commit always can be done.


As for mirroring numpy layout - I don't think exact mirroring will be a good
idea. In CPython numpy some funcs dwell in C code, some in CPython and some in
Python code, that's why that layout is so damned complicated (and is changed
from time to time, e.g. when some funcs are rewritten from C to Cython or Python
or vise versa). We'd better create our own layer0 (e.g. class ndarray), layer1,
layer2 etc.

As for TDD: I think rules of contribution have to be explicitly written
somewhere, for example, "no less that 2 tests per function". As you probably
have seen, I had created some tests for these funcs in the bottom of the url I
provided. In the explicit rules of contribution can be present strict format of
tests as well. But on the other hand, all those nuts spinning will essentially
reduce willing of volunteers (especially newcomers) to contribute. BTW, it's not
necessary for a code contributor to be contributor of tests for the func,
moreover, sometimes it's even better to use other person for this, because
former could live in his own world of delusions, e.g. forget that arrays with
dimension > 3 exist, and having 2nd (or just other) person involved increases
chances of revealing the bug. 

Overall you've mentioned numpypy is running mostly by enthusiasm, but for
creating quality code things cannot always be like that, someone has to do the
boring work with test coverage, improving docstrings etc (BTW AFAIK it's quite
usual for a project from early rapid studies of development by enthusiasm
migrate into slow studies of mostly bugfixes). I think for the particular case
best solution would be sharing a small fee for writing tests for recently
committed funcs (you can propose it on freelancer sites, I could be interested
in it as well) and other boring yet important work like that.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 12:15:58 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 19 Jan 2012 11:15:58 +0000
Subject: [pypy-issue] [issue1003] Sandbox code uses no-longer-working seccom
In-Reply-To: <1326898662.41.0.324668365239.issue1003@bugs.pypy.org>
Message-ID: <1326971758.03.0.36409489257.issue1003@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

That should be a relatively straightforward patch for someone who knows how to 
deal with POSIX. Feel like helping?

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1003>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 12:18:25 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 19 Jan 2012 11:18:25 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1326971905.82.0.719834293123.issue1010@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Hello.

I think we would be better off just implementing logical_and, it's relatively 
easy (we have bitwise_and already)

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1010>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 12:24:19 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 19 Jan 2012 11:24:19 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1326972259.78.0.978864023735.issue1010@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

I think using logical_and is bad idea here. I will perform calculation through
whole array, that may be very big or inside a big loop, while in many cases mere
comparing of first 2 elements could be enough to ensure that the arrays differ.
In CPython one can't use the "for" cycle, because it would be too slow (however,
I wonder why wouldn't they use it in C or Cython code), but in PyPy version I
guess things should definitely be this way.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1010>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 12:32:02 2012
From: tracker at bugs.pypy.org (Da_Blitz)
Date: Thu, 19 Jan 2012 11:32:02 +0000
Subject: [pypy-issue] [issue1003] Sandbox code uses no-longer-working seccom
In-Reply-To: <1326898662.41.0.324668365239.issue1003@bugs.pypy.org>
Message-ID: <1326972722.14.0.748027250375.issue1003@bugs.pypy.org>


Da_Blitz <pypy at pocketnix.org> added the comment:

There are upcoming changes to seccomp that may make it work with pypy. currently
a seccomp enabled version of pypy will not work due to calls to mmap and sbrk
failing (as these are not on the list of allowed syscalls) however with the new
extensions it will be possible to dynamically filter allowed syscalls with a
'syscall firewall' (links below)

i had plans to work on this once the feature hit the mainline kernel but don't
mind working with someone if they are interested, should be as simple as moving
to the prctl interface, writing a new policy and loading it via prctl and then
some testing to ensure we got all the syscalls in the policy

https://lwn.net/Articles/475043/
http://lwn.net/SubscriberLink/475678/655d35a19825fd7d/ (subscriber link as
content is not 'public' until next week)
https://lwn.net/Articles/475019/

----------
nosy: +dablitz

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1003>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 12:49:15 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 19 Jan 2012 11:49:15 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1326973755.11.0.729815850426.issue1008@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

> I think rules of contribution have to be explicitly written somewhere
http://doc.pypy.org/en/latest/faq.html#id40   "use test driven development" (although 
that faq is written in relation to rpython, it does seem to apply everywhere in pypy)

> it's not necessary for a code contributor to be contributor of tests for the func
..and..
> a small fee for writing tests for recently committed funcs

There is a definite preference that tests are written before funcs (see the definition 
of TDD). And funcs without tests are unlikely to be accepted.  So in practice it really 
does come down to a contributor writing tests.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 14:50:36 2012
From: tracker at bugs.pypy.org (Paul Crowley)
Date: Thu, 19 Jan 2012 13:50:36 +0000
Subject: [pypy-issue] [issue1003] Sandbox code uses no-longer-working seccom
In-Reply-To: <1326898662.41.0.324668365239.issue1003@bugs.pypy.org>
Message-ID: <1326981036.95.0.0427620454151.issue1003@bugs.pypy.org>


Paul Crowley <paul at lshift.net> added the comment:

Looks like this sort of thing is very much in flux at the moment - we should hold 
off until a stable system hits the mainline kernel. Thanks for the links! We'll 
have to wait and see whether the new system allows the work to be done in the 
parent process or whether it will have to be done in the child process.  Yes, 
would be fun to work on!

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1003>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 19:18:23 2012
From: tracker at bugs.pypy.org (Vetoshkin Nikita)
Date: Thu, 19 Jan 2012 18:18:23 +0000
Subject: [pypy-issue] [issue958] AMD Opterons don't specify their L3 cache
	size
In-Reply-To: <1323251857.3.0.418537247477.issue958@bugs.pypy.org>
Message-ID: <1326997103.19.0.9637416897.issue958@bugs.pypy.org>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Seems that lscpu looks through 
/sys/devices/system/cpu/cpuX/cache/indexX/{level,size}.

----------
nosy: +nekto0n

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue958>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 19 20:49:58 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 19 Jan 2012 19:49:58 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1327002598.85.0.511382344613.issue1010@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

numpypy ndarray.flat doesn't work properly with indexation, but a walkaround has
been implemented and is available at http://pastebin.com/tg2aHE6x
Some speed tests:
1) in CPython numpy for arrays of lenght 100000, 100 times:
classic numpy array_equal time elapsed (on different arrays): 0.07728
Alternative array_equal time elapsed (on different arrays): 0.00056
classic numpy array_equal time elapsed (on same arrays): 0.11163
Alternative array_equal time elapsed (on same arrays): 9.09458
2) in current PyPy:
Alternative array_equal time elapsed (on different arrays): 0.00133
Alternative array_equal time elapsed (on same arrays): 0.95038
Since usually different arrays come to the func array_equal, this approach (w/o
logical_and and allocating memory for its input) seems to be better.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1010>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 20 09:49:50 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 20 Jan 2012 08:49:50 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1327049390.65.0.580798233636.issue1010@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

logical_and can be lazy, there is really no problem with that. Look how all is 
implemented for an example

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1010>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 20 10:01:33 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Fri, 20 Jan 2012 09:01:33 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1327050093.08.0.832025329053.issue1010@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

You should be appreciated for your willing to produce fast code of high quality,
but could you commit at least "just works" code for now (since it is seems to be
free of bugs and its speed comparable to cpython)? You always could replace it
later by any other implementation, I guess it's better to focus on function
coverage for now. This and about a couple of dozens funcs prevent hundreds of my
OpenOpt Suite funcs being working in PyPy, as well as many other users code.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1010>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 20 10:27:20 2012
From: tracker at bugs.pypy.org (Jagadish)
Date: Fri, 20 Jan 2012 09:27:20 +0000
Subject: [pypy-issue] [issue1011] pypy slower than CPython for recursion
In-Reply-To: <1327051640.17.0.669316078056.issue1011@bugs.pypy.org>
Message-ID: <1327051640.17.0.669316078056.issue1011@bugs.pypy.org>


New submission from Jagadish <krshnam at gmail.com>:

The following simple example program is slower with pypy than with CPython.
In my machine(Dell Inspiron 6400, Arch Linux, Python 2.7.1, pypy 1.7.0 ), I get, 
for example, these numbers:
$ time python2 five_three_rec.py 12017
real	2m55.367s
user	2m53.129s
sys	0m1.290s

$ time pypy five_three_rec.py 12017
real	7m58.881s
user	7m56.239s
sys	0m0.830s

#five_three_rec.py
def findSequence(goal):
    def find(start, history):
        if start == goal :
            return history
        elif start > goal :
            return None
        else :
            return ( find(start + 5, "(%s + 5)" % history) or
                    find(start * 3, "(%s * 3)" % history))
    return find(1, '1')

if __name__ == '__main__' :
    import sys
    sys.setrecursionlimit(5000)
    input_num = int(sys.argv[1])
    print (findSequence(input_num) or
            'No sequence in terms of 5 and 3 for %d.' % input_num)

The non-recursive version below, however, is faster with pypy:
$ time python2 five_three_iter.py 12017
real	1m36.279s
user	1m36.187s
sys	0m0.013s

$ time pypy five_three_iter.py 12017
real	0m10.770s
user	0m10.703s
sys	0m0.040s


#five_three_iter.py
def findSequence(goal):
    node_list = [{'num':1, '5':False, '3':False}]
    op_seq_list = ['1']

    def printOpSeq():
        seq_str ='1'
        for op_str in op_seq_list[1:]:
            seq_str = '(' + seq_str + op_str + ')'
        print seq_str
        print eval(seq_str)

    while True:
        node = node_list[-1]
        if not node['5'] :
            node['5'] = True
            new_num = node['num'] + 5
            if new_num <= goal:
                op_seq_list.append(' + 5')
                if new_num == goal:
                    printOpSeq()
                    break
                else :
                    node_list.append({'num': new_num,
                        '5': False, '3': False})
                    continue
        if not node['3'] :
            node['3'] = True
            new_num = node['num'] * 3
            if new_num <= goal :
                op_seq_list.append(' * 3')
                if new_num == goal:
                    printOpSeq()
                    break
                else :
                    node_list.append({'num': new_num,
                        '5': False, '3': False})
                    continue
        else:
            if len(node_list) == 1:
                print "No solution"
                break
            else:
                node_list.pop()
                op_seq_list.pop()
                continue


if __name__ == '__main__':
    import sys
    sys.setrecursionlimit(5000)
    input_num = int(sys.argv[1])
    findSequence(input_num)

I am not an expert at Python and if there is something very bad with the code 
above, please do excuse me. I hope this is the place to report this thing.

----------
messages: 3744
nosy: jarav, pypy-issue
priority: performance bug
status: unread
title: pypy slower than CPython for recursion

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1011>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 20 14:34:58 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 20 Jan 2012 13:34:58 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1327066498.98.0.921854070187.issue1010@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

What I'm trying to say is that since order of commit does not matter (logical_and 
can be done before array_equal and both should be done), we should organize it in 
a way that creates the lowest amount of work. I don't think having "as much 
functionality right now" is that important compared to "having all the 
functionality as soon as possible".

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1010>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 20 15:33:11 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Fri, 20 Jan 2012 14:33:11 +0000
Subject: [pypy-issue] [issue952] try to use .hg_archival if .hg is not
	availiable
In-Reply-To: <1323082248.49.0.381991933314.issue952@bugs.pypy.org>
Message-ID: <1327069991.45.0.92344615707.issue952@bugs.pypy.org>


Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

fixed in 79770e0c2f93

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue952>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 11:51:21 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Sat, 21 Jan 2012 10:51:21 +0000
Subject: [pypy-issue] [issue1012] numpypy: bug with dot
In-Reply-To: <1327143081.01.0.052194766213.issue1012@bugs.pypy.org>
Message-ID: <1327143081.01.0.052194766213.issue1012@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

I had informed of the bug in mail list, but I see is still present in latest
build, let me put it here into bug tracker for more safety:
>>> np.dot([[1,2],[3,4]],[5,6])
array([17, 39])
>>>> np.dot([[1,2],[3,4]],[5,6])
56.0

----------
messages: 3747
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: bug with dot

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1012>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 12:08:24 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Sat, 21 Jan 2012 11:08:24 +0000
Subject: [pypy-issue] [issue1013] numpypy: all() and any() with axis
	argument give	incorrect result yet
In-Reply-To: <1327144104.3.0.522783751944.issue1013@bugs.pypy.org>
Message-ID: <1327144104.3.0.522783751944.issue1013@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

Folk, you keep so strict rules of code commit quality for newcomers, while your
own code yields incorrect result even on examples from func docstring. I haven't
found the bug on the bug tracker (although I don't know - maybe someone works on
it, but your development process makes it unclear to understand for non-core dev
people), so let me put it here. Also, maybe, temporary putting error like "the
func doesn't work along axis yet" worth to be done?
>>> np.all([[True,False],[True,True]], axis=0)
array([ True, False], dtype=bool)
>>> np.any([[True,False],[True,True]], axis=0)
array([ True,  True], dtype=bool)
(or just np.any([[True,False],[True,True]], 0))
>>>> np.all([[True,False],[True,True]], axis=0)
False
>>>> np.any([[True,False],[True,True]], axis=0)
True
(all() and any() along axis are used for tens of times in my code, that's why I
care so much about it).
Regards, D.

----------
messages: 3748
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: all() and any() with axis argument give incorrect result yet

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1013>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 13:00:29 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 21 Jan 2012 12:00:29 +0000
Subject: [pypy-issue] [issue1013] numpypy: all() and any() with axis
	argument give	incorrect result yet
In-Reply-To: <1327144104.3.0.522783751944.issue1013@bugs.pypy.org>
Message-ID: <1327147229.91.0.0828030058614.issue1013@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Thanks dmitrey, provided asserts wherever it's not supported. The problem is 
pure python copied code, we should somehow make sure it reflects the current 
state of art.

We should still support all and any over axis though, but it's not yet there and 
I have a cleanup to do first.

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1013>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 17:27:37 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 21 Jan 2012 16:27:37 +0000
Subject: [pypy-issue] [issue972] inconsistency with cpython (datetime?)
In-Reply-To: <1324497118.49.0.15609286849.issue972@bugs.pypy.org>
Message-ID: <1327163257.37.0.602368521567.issue972@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Merged

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue972>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 17:56:57 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Sat, 21 Jan 2012 16:56:57 +0000
Subject: [pypy-issue] [issue1014] numpypy sum() buggy with axis
In-Reply-To: <1327165017.38.0.48636399124.issue1014@bugs.pypy.org>
Message-ID: <1327165017.38.0.48636399124.issue1014@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

it doesn't handle correctly even its docstring examples:
>>>> np.sum([[0, 1], [0, 5]], axis=1)
6
>>>> np.sum([[0, 1], [0, 5]], axis=0)
6

----------
messages: 3751
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy sum() buggy with axis

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1014>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 17:59:13 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 21 Jan 2012 16:59:13 +0000
Subject: [pypy-issue] [issue1014] numpypy sum() buggy with axis
In-Reply-To: <1327165017.38.0.48636399124.issue1014@bugs.pypy.org>
Message-ID: <1327165153.31.0.575356695937.issue1014@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

It's fixed already. hg pull

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1014>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 18:02:03 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Sat, 21 Jan 2012 17:02:03 +0000
Subject: [pypy-issue] [issue1014] numpypy sum() buggy with axis
In-Reply-To: <1327165017.38.0.48636399124.issue1014@bugs.pypy.org>
Message-ID: <1327165323.55.0.792022753854.issue1014@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

thanks, I'll wait for todays build - it's better for me than building from
sources on my computer.

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1014>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 18:03:52 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 21 Jan 2012 17:03:52 +0000
Subject: [pypy-issue] [issue1014] numpypy sum() buggy with axis
In-Reply-To: <1327165017.38.0.48636399124.issue1014@bugs.pypy.org>
Message-ID: <1327165432.24.0.435631868162.issue1014@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

You can just update it and put pypy in say checkout/compiled but you also can 
test it on top of py.py

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1014>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 22:11:27 2012
From: tracker at bugs.pypy.org (Pilla Julien)
Date: Sat, 21 Jan 2012 21:11:27 +0000
Subject: [pypy-issue] [issue975] A jit bug crashes my app
In-Reply-To: <1325350417.44.0.794309064675.issue975@bugs.pypy.org>
Message-ID: <1327180287.26.0.370195431558.issue975@bugs.pypy.org>


Pilla Julien <vrlitwhai.kridanik at gmail.com> added the comment:

I'm "sorry", I'm unable to find a way to reproduce the bug today. If It happened 
frequently, it seems it has vanished with the nightly builds, about ten days ago.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue975>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 22:52:13 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 21 Jan 2012 21:52:13 +0000
Subject: [pypy-issue] [issue975] A jit bug crashes my app
In-Reply-To: <1325350417.44.0.794309064675.issue975@bugs.pypy.org>
Message-ID: <1327182733.9.0.594200218852.issue975@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

closing then? please reopen if you can

----------
nosy: +fijal
status: chatting -> wontfix

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue975>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 21 23:09:52 2012
From: tracker at bugs.pypy.org (Carsten Senger)
Date: Sat, 21 Jan 2012 22:09:52 +0000
Subject: [pypy-issue] [issue1015] Add build to run the benchmarks with
	python 2.7 tip
In-Reply-To: <1327183792.09.0.47130209624.issue1015@bugs.pypy.org>
Message-ID: <1327183792.09.0.47130209624.issue1015@bugs.pypy.org>


New submission from Carsten Senger <senger at rehfisch.de>:

The BuildFactory is implemented here:

https://bitbucket.org/csenger/buildbot

It pulls and builds python2.7 and runs the benchmarks.
It does not use the --upload option to runner.py currently.

----------
assignedto: fijal
messages: 3757
nosy: csenger, fijal, pypy-issue
priority: feature
status: unread
title: Add build to run the benchmarks with python 2.7 tip

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1015>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 07:59:56 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Sun, 22 Jan 2012 06:59:56 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>


New submission from Justin Patrin <papercrane at reversefold.com>:

I get:

RPython traceback:
  File "jit_metainterp_compile.c", line 136, in force_now_1
  File "jit_metainterp_compile.c", line 200, in 
ResumeGuardForcedDescr_handle_async_forcing
Fatal RPython error: AssertionError
Abort trap: 6

every time I run:

PYTHONPATH=.. pypy both.py

while in the examples directory of the unzipped tarball attached. This is on OSX 
10.7.2 with pypy from mercurial built with:

./pypy-c translate.py --opt=jit --continuation --thread --gc=minimark --listcompr 
--clever-malloc-removal --insist targetpypystandalone.py

I tried to create a simpler script which does the same things (bare_poll.py) but 
it runs forever with no problems.

----------
files: jevent_pypy_crash.tbz2
messages: 3758
nosy: papercrane, pypy-issue
priority: bug
status: unread
title: RPython AssertionError while running async io greenlet test

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From fijall at gmail.com  Sun Jan 22 11:19:26 2012
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 22 Jan 2012 12:19:26 +0200
Subject: [pypy-issue] [issue1014] numpypy sum() buggy with axis
In-Reply-To: <4F1BE08C.3040101@ukr.net>
References: <1327165153.31.0.575356695937.issue1014@bugs.pypy.org>
	<4F1BE08C.3040101@ukr.net>
Message-ID: <CAK5idxT1rEQyL2m0M6CF2tWT_V=BfJjzK_xOc7MK7X7cOcNewg@mail.gmail.com>

On Sun, Jan 22, 2012 at 12:10 PM, Dmitrey <dmitrey15 at ukr.net> wrote:
> On 01/21/2012 06:59 PM, Fijal wrote:
>>
>> Fijal<fijall at gmail.com> ?added the comment:
>>
>> It's fixed already. hg pull
>
> In today night build it's absent yet:
>
>>>>> N.sum([[0, 1], [0, 5]], axis=0)
> 6
>

It must have been fixed after midnight or something. It's certainly
done on trunk

From tracker at bugs.pypy.org  Sun Jan 22 12:23:42 2012
From: tracker at bugs.pypy.org (mattip)
Date: Sun, 22 Jan 2012 11:23:42 +0000
Subject: [pypy-issue] [issue1014] numpypy sum() buggy with axis
In-Reply-To: <1327165017.38.0.48636399124.issue1014@bugs.pypy.org>
Message-ID: <1327231422.73.0.694475488245.issue1014@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

Indeed, fromnumeric.py needs at the minimum this fix.

diff -r 5aa09e8483d3 lib_pypy/numpypy/fromnumeric.py
--- a/lib_pypy/numpypy/fromnumeric.py   Wed Jan 18 23:04:56 2012 +0100
+++ b/lib_pypy/numpypy/fromnumeric.py   Sun Jan 22 13:17:16 2012 +0200
@@ -1353,7 +1353,7 @@
     """
     if not hasattr(a, "sum"):
         a = numpypy.array(a)
-    return a.sum()
+    return a.sum(axis)


 def product (a, axis=None, dtype=None, out=None):

----------
nosy: +mattip

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1014>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 12:33:04 2012
From: tracker at bugs.pypy.org (mattip)
Date: Sun, 22 Jan 2012 11:33:04 +0000
Subject: [pypy-issue] [issue1014] numpypy sum() buggy with axis
In-Reply-To: <1327165017.38.0.48636399124.issue1014@bugs.pypy.org>
Message-ID: <1327231984.14.0.583258637057.issue1014@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

There is work underway to correct the fromnumeric problems, in the mean time 
perhaps try this patch, to completely remove it.
diff -r 5aa09e8483d3 lib_pypy/numpypy/__init__.py
--- a/lib_pypy/numpypy/__init__.py      Wed Jan 18 23:04:56 2012 +0100
+++ b/lib_pypy/numpypy/__init__.py      Sun Jan 22 13:29:59 2012 +0200
@@ -1,2 +1,2 @@
 from _numpypy import *
-from .fromnumeric import *
+#from .fromnumeric import *

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1014>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 16:37:15 2012
From: tracker at bugs.pypy.org (Carsten Senger)
Date: Sun, 22 Jan 2012 15:37:15 +0000
Subject: [pypy-issue] [issue1015] Add build to run the benchmarks with
	python 2.7 tip
In-Reply-To: <1327183792.09.0.47130209624.issue1015@bugs.pypy.org>
Message-ID: <1327246635.64.0.144895090864.issue1015@bugs.pypy.org>


Carsten Senger <senger at rehfisch.de> added the comment:

I've extended the runner and saveresults scripts to accept parameters for url,
executable and project so it can be used to upload to multible/other codespeed
instances with with other project or executable names:

https://bitbucket.org/csenger/benchmarks

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1015>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 18:38:18 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 17:38:18 +0000
Subject: [pypy-issue] [issue1014] numpypy sum() buggy with axis
In-Reply-To: <1327165017.38.0.48636399124.issue1014@bugs.pypy.org>
Message-ID: <1327253898.24.0.121417419056.issue1014@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Can you please not reopen this issue until it's really broken? Replying to mails 
reopens it

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1014>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:05:54 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:05:54 +0000
Subject: [pypy-issue] [issue567] Silence annrpython warnings for 1.5
In-Reply-To: <1290805371.33.0.180103059748.issue567@>
Message-ID: <1327259154.14.0.0944170366629.issue567@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Done, annotator does not produce warnings any more (I think)

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue567>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:06:33 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:06:33 +0000
Subject: [pypy-issue] [issue580] Broken pipe error during sandbox
	installation?
In-Reply-To: <1291073613.25.0.571907443112.issue580@>
Message-ID: <1327259193.39.0.559342084989.issue580@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

I think this is really working these days (or unreproducible)

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue580>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:07:52 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:07:52 +0000
Subject: [pypy-issue] [issue615] Errors when using urllib with SSL
In-Reply-To: <1293081017.1.0.915631179687.issue615@>
Message-ID: <1327259272.91.0.947171978176.issue615@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Works for me, probably improved stdlib version?

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue615>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:09:19 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:09:19 +0000
Subject: [pypy-issue] [issue617] range() slower than xrange()
In-Reply-To: <1293622569.28.0.68982879862.issue617@>
Message-ID: <1327259359.11.0.787012157554.issue617@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Still valid, we should look at it (22 Jan 2012)

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue617>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:10:08 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Sun, 22 Jan 2012 19:10:08 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327259408.93.0.646832585332.issue1016@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

I'm unable to reproduce with --opt=2 or --opt=3 (./pypy-c translate.py --
output=pypy-c.3 --opt=3 targetpypystandalone.py), so this seems to be an issue 
only when using the jit. I'll test without all of the extra options to the 
translator as well once it finishes translating.

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:13:51 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:13:51 +0000
Subject: [pypy-issue] [issue641] reading CSV files with csv module is much
	slower than	CPython 2.6.6
In-Reply-To: <1298466755.89.0.819503203326.issue641@>
Message-ID: <1327259631.71.0.491735925374.issue641@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

This one is still pretty bad, pypy-c is ~3x slower than my CPython

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue641>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:16:46 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:16:46 +0000
Subject: [pypy-issue] [issue714] Translating on top of pypy sometimes screws
	up mandelbrot
In-Reply-To: <1304525440.86.0.269839725466.issue714@>
Message-ID: <1327259806.6.0.61354558938.issue714@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Failed to see that one in a while :)

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue714>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:17:41 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:17:41 +0000
Subject: [pypy-issue] [issue709] pypy 1.5 crashes and fails when compiling
	pypy on OSX
In-Reply-To: <1304276490.9.0.130480453147.issue709@>
Message-ID: <1327259861.95.0.895012533645.issue709@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Resolved long time ago? Please reopen if not

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue709>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:32:14 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:32:14 +0000
Subject: [pypy-issue] [issue726] django-cms tests fail using pypy 1.5 but
	pass under	CPython 2.5, 2.6 and 2.7
In-Reply-To: <1306014491.51.0.504776032294.issue726@bugs.pypy.org>
Message-ID: <1327260734.66.0.626673490658.issue726@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

This now fails with:


Error: The version option is deprecated. Read about the change on 
http://pypi.python.org/pypi/djangorecipe/0.99

Can you update the branch?

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue726>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:32:35 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:32:35 +0000
Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install
In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org>
Message-ID: <1327260755.18.0.410129943371.issue735@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Fixed in twisted

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue735>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:33:40 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:33:40 +0000
Subject: [pypy-issue] [issue761] Cannot build an optional C extension in the
	Storm 1.8	package
In-Reply-To: <1309008092.87.0.698796204065.issue761@bugs.pypy.org>
Message-ID: <1327260820.52.0.559423307883.issue761@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Can anyone confirm/deny this? I'm going to close this ticket, if the problems 
persist, please reopen

----------
status: testing -> wontfix

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue761>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:34:18 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:34:18 +0000
Subject: [pypy-issue] [issue762] Error trying to build a C extension in the
	zope.proxy	3.6.1 package
In-Reply-To: <1309010123.83.0.488090929289.issue762@bugs.pypy.org>
Message-ID: <1327260858.54.0.513095671039.issue762@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Closing as wontfix as we won't implement cl_dict

----------
nosy: +fijal
status: chatting -> wontfix

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue762>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:36:16 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:36:16 +0000
Subject: [pypy-issue] [issue790] SSL and bz2 lib paths are broken on RHEL 5
In-Reply-To: <1310481590.34.0.804672541181.issue790@bugs.pypy.org>
Message-ID: <1327260976.25.0.0657227298394.issue790@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Closing as wontfix, linux does not support binary distributions. fortunately 
fedora ships pypy, that hopefully sorts the problem.

----------
nosy: +fijal
status: chatting -> wontfix

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue790>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:37:38 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jan 2012 19:37:38 +0000
Subject: [pypy-issue] [issue773] pyre2 fails import
In-Reply-To: <1309436018.13.0.321306729758.issue773@bugs.pypy.org>
Message-ID: <1327261058.05.0.72664717041.issue773@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

closing as it works

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue773>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 20:43:05 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 22 Jan 2012 19:43:05 +0000
Subject: [pypy-issue] [issue738] utcfromtimestamp handles time before the
	epoch differently	in pypy and cpython
In-Reply-To: <1307137027.04.0.840663501808.issue738@bugs.pypy.org>
Message-ID: <1327261385.11.0.863971947114.issue738@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

This was recently fixed with 235d8b8434a8

----------
nosy: +afa
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue738>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 23:46:45 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Sun, 22 Jan 2012 22:46:45 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327272405.48.0.0968485435475.issue1016@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

Running with --opt=0 (./pypy-c translate.py --
output=pypy-c.0 --opt=0 --gc=minimark targetpypystandalone.py) also did not 
crash. Running with a minimal --opt-jit did crash in the same way, so it appears 
to happen only with jit. (./pypy-c translate.py --
output=pypy-c.jit --opt=jit targetpypystandalone.py).

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 22 23:50:14 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Sun, 22 Jan 2012 22:50:14 +0000
Subject: [pypy-issue] [issue996] sqlite3 CREATE TABLE always fails
In-Reply-To: <1326216051.55.0.901484837189.issue996@bugs.pypy.org>
Message-ID: <1327272614.84.0.980340851665.issue996@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

I think I have a fix for this.  Pull request soon.

----------
assignedto:  -> dripton

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue996>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 00:09:40 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Sun, 22 Jan 2012 23:09:40 +0000
Subject: [pypy-issue] [issue996] sqlite3 CREATE TABLE always fails
In-Reply-To: <1326216051.55.0.901484837189.issue996@bugs.pypy.org>
Message-ID: <1327273780.58.0.485675651462.issue996@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

Here's a pull request with the fix (and some minor cleanups to _sqlite3.py) 
https://bitbucket.org/pypy/pypy/pull-request/23/fix-_sqlite3py-fix-for-issue996-with-test

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue996>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 00:19:37 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Sun, 22 Jan 2012 23:19:37 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1327274377.65.0.67177976877.issue934@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

pypy 1.7, on Linux x86-32.  Sometimes the process hangs.  Sometimes I get a
"build failed" like
=========================
...
Build failed
 -> task failed (exit status -11):                                                  
        {task 165307472: cxx class_79.cpp -> class_79.cpp.3.o}                      
['/usr/bin/g++', '-I/tmp/issue934/build/out', '-I/tmp/issue934/build',
'../lib_2/class_79.cpp', '-c', '-o', 'lib_2/class_79.cpp.3.o']

----------
nosy: +dripton

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue934>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 00:36:52 2012
From: tracker at bugs.pypy.org (ita)
Date: Sun, 22 Jan 2012 23:36:52 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1327275412.22.0.0417175692246.issue934@bugs.pypy.org>


ita <tnagy1024 at gmail.com> added the comment:

Pypy 1.7 on Linux x86-64: same thing here, the main process can hang, or a few
child processes will report the exit code -11 too

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue934>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 00:38:40 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Sun, 22 Jan 2012 23:38:40 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1327275520.35.0.326906259191.issue934@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

It behaves differently in a pypy-c built today.  (Still x86 Linux.)  Now the
attached test waf build succeeds some of the time, and makes it to 5049/5050
then hangs some of the time.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue934>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 03:14:22 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Mon, 23 Jan 2012 02:14:22 +0000
Subject: [pypy-issue] [issue996] sqlite3 CREATE TABLE always fails
In-Reply-To: <1326216051.55.0.901484837189.issue996@bugs.pypy.org>
Message-ID: <1327284862.48.0.882224422796.issue996@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

That pull request was merged, so I think this is fixed.

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue996>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 08:50:35 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 23 Jan 2012 07:50:35 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1327305035.79.0.761745908935.issue1008@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

These functions are implemented directly in applevel python in numpy and should 
simply be copied over. Tests are absolutely necessary for the contribution, 
precisely because we try to avoid "commit something first then spend time fixing 
bugs later", because noone wants to do that.

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 09:01:12 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 23 Jan 2012 08:01:12 +0000
Subject: [pypy-issue] [issue1011] pypy slower than CPython for recursion
In-Reply-To: <1327051640.17.0.669316078056.issue1011@bugs.pypy.org>
Message-ID: <1327305672.43.0.957514459446.issue1011@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

PyPy has some problems with recursion (it can be faster), but the latest nightly 
is already a bit faster than CPython, closing.

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1011>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 09:16:50 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 23 Jan 2012 08:16:50 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327306610.39.0.669396726802.issue1016@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

FYI to run without JIT, it's enough to run a jitted version of pypy like this:

pypy --jit off <args>

It's much easier than retranslating :)

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 09:19:55 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 23 Jan 2012 08:19:55 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327306795.02.0.241801036015.issue1016@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

I get an error: error: [Errno 11] Resource temporarily unavailable

any idea what that means?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 12:18:16 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Mon, 23 Jan 2012 11:18:16 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1327317496.6.0.0613892436465.issue1008@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

That time I proposed the implementation method ndarray.fill() was absent. Now
it's present and I could commit the copy-pasted code from numpy. Could you inform
where to put the sources for these funcs
where to put the related tests
(I mean which file and path)
and what is command prompt line for hg here (I have almost no experience with
committing to different truncs)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 12:39:40 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 23 Jan 2012 11:39:40 +0000
Subject: [pypy-issue] [issue995] jit bug with threads
In-Reply-To: <1326197980.33.0.665170552495.issue995@bugs.pypy.org>
Message-ID: <1327318780.91.0.173055557599.issue995@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

You forgot to attach x.py.

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue995>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 12:44:22 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 23 Jan 2012 11:44:22 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327319062.89.0.770810839592.issue1016@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

papercrane: can you give us one of the version numbers that you tried?  As a
mercurial identifier, i.e. 12 hexadecimal digits.  Thanks!

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 13:15:48 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Mon, 23 Jan 2012 12:15:48 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1327320948.9.0.307847396303.issue1008@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

here's numpy zeros_like func latest version with 3 new parameters (in Linux
channel it's still old-style 1-argument version):

def zeros_like(a, dtype=None, order='K', subok=True):
    """
    Return an array of zeros with the same shape and type as a given array.

    With default parameters, is equivalent to ``a.copy().fill(0)``.

    Parameters
    ----------
    a : array_like
        The shape and data-type of `a` define these same attributes of
        the returned array.
    dtype : data-type, optional
        Overrides the data type of the result.
    order : {'C', 'F', 'A', or 'K'}, optional
        Overrides the memory layout of the result. 'C' means C-order,
        'F' means F-order, 'A' means 'F' if `a` is Fortran contiguous,
        'C' otherwise. 'K' means match the layout of `a` as closely
        as possible.
    Returns
    -------
    out : ndarray
        Array of z    
    (examples)
    """
    res = empty_like(a, dtype=dtype, order=order, subok=subok)
    res.fill(0)
    return res

So, there are some questions about it:
1) Does parameter "order" have any sense for numpypy? Or we could just don't
take it into account?
2) subok=True is not mentioned in documentation of the func. AFAIK it's related
to subclassing - if set to False, return ndarray instead of its subclass on
input (I have checked it right now). Have you any remarks or suggestions on it?
3) empty_like is defined in c code, will it be ok to replace their code by our
python-written one, similar to the code mentioned below (+ the new missing yet
arguments)?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 14:03:12 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 23 Jan 2012 13:03:12 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327323792.91.0.0113793199667.issue1016@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

I also get "Resource temporarily unavailable" systematically, on Linux 64-bit. 
I can't test the original problem :-/

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 15:39:28 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 23 Jan 2012 14:39:28 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1327329568.55.0.169497868363.issue934@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

A Linux 64 version from today, 09532c746387, does not seem to have any problem
any more, neither built normally nor with lldebug.  I just got once a different
crash: clearly a rare case, fixed in c32fbc60b64c.  Can we close this report as
unknown-but-seems-fixed?

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue934>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 18:32:42 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Mon, 23 Jan 2012 17:32:42 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1327339962.77.0.244099159029.issue1008@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

I have pasted latest version of my empty_like to http://pastebin.com/yUznKBGV ,
as for ones_like and zeros_like - they were taken from numpy sources (empty_like
is somewhere in c code). All tests passes well. Can I commit it right now? There
is an issue with subclassing I marked as unimplemented yet (line 72), but less I
guess than 1% of projects use numpy.ndarray subclasses, and we always can
implement it later.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1008>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 20:19:53 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Mon, 23 Jan 2012 19:19:53 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327346393.33.0.798980057154.issue1016@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

Yep, that error comes up on Linux as the errno's are different on Linux than on 
OSX. I got a version working on Linux but was unable to get the AssertionError, 
even after a very long run. On OSX it happens within about 15 seconds.

The hg changeset I'm currently on is 51557:9adc55550ee8.

If none of you have OSX, is there anything I can do to get you better debug info?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 21:01:15 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 23 Jan 2012 20:01:15 +0000
Subject: [pypy-issue] [issue1004] Sandbox only works for single-threaded code
In-Reply-To: <1326899876.87.0.633218492473.issue1004@bugs.pypy.org>
Message-ID: <1327348875.41.0.0359997506761.issue1004@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

There are other issues with threads, including the fact that we are slightly
less sure that there are no attackable bugs in threaded code.  For this and
other reasons, the sandboxed pypy has no 'thread' module installed.  So the
problem you describe doesn't apply so far.

----------
nosy: +arigo
status: unread -> wontfix

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1004>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 23 21:50:57 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 23 Jan 2012 20:50:57 +0000
Subject: [pypy-issue] [issue995] jit bug with threads
In-Reply-To: <1326197980.33.0.665170552495.issue995@bugs.pypy.org>
Message-ID: <1327351857.57.0.226485078787.issue995@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Fortunately still in /tmp/x.py on tannit ;-) http://paste.pocoo.org/show/539462/

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue995>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 05:43:57 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Tue, 24 Jan 2012 04:43:57 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327380237.96.0.200129310989.issue1016@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

I've uploaded a new tarball which uses errno instead of hard-coding and runs fine 
on Linux as well as OSX. However, I still cannot reproduce on Linux, only on OSX.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 07:34:35 2012
From: tracker at bugs.pypy.org (Pavel)
Date: Tue, 24 Jan 2012 06:34:35 +0000
Subject: [pypy-issue] [issue1017] io.open compatibility error
In-Reply-To: <1327386875.31.0.279814198851.issue1017@bugs.pypy.org>
Message-ID: <1327386875.31.0.279814198851.issue1017@bugs.pypy.org>


New submission from Pavel <asl.pavel at gmail.com>:

io.open:
    If the object is in non-blocking mode and no bytes are available,
    None is returned.

but pypy raises:
    IOError: [Errno 11] Resource temporarily unavailable

simple unit test attached.

----------
files: pypy_io_error.py
messages: 3802
nosy: pypy-issue
priority: bug
release: 1.7
status: unread
title: io.open compatibility error

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1017>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 09:33:52 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 24 Jan 2012 08:33:52 +0000
Subject: [pypy-issue] [issue1017] io.open compatibility error
In-Reply-To: <1327386875.31.0.279814198851.issue1017@bugs.pypy.org>
Message-ID: <1327394032.69.0.653422365402.issue1017@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Fixed in 9901f428b3b1, thanks for the report!
Note that f.read() without argument was already correct.

----------
nosy: +afa
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1017>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 09:48:48 2012
From: tracker at bugs.pypy.org (Pavel)
Date: Tue, 24 Jan 2012 08:48:48 +0000
Subject: [pypy-issue] [issue1017] io.open compatibility error
In-Reply-To: <1327386875.31.0.279814198851.issue1017@bugs.pypy.org>
Message-ID: <1327394928.7.0.514846374821.issue1017@bugs.pypy.org>


Pavel <asl.pavel at gmail.com> added the comment:

Thank you for a fast fix!)

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1017>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 10:14:03 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 24 Jan 2012 09:14:03 +0000
Subject: [pypy-issue] [issue1017] io.open compatibility error
In-Reply-To: <1327386875.31.0.279814198851.issue1017@bugs.pypy.org>
Message-ID: <1327396443.83.0.736549989231.issue1017@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

last night I worked on the same files, so it was fresh in my head :)

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1017>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 17:19:18 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Tue, 24 Jan 2012 16:19:18 +0000
Subject: [pypy-issue] [issue1018] ones(shape, 'int') and zeros(shape,
	'int') doesn't work
In-Reply-To: <1327421958.09.0.643487914668.issue1018@bugs.pypy.org>
Message-ID: <1327421958.09.0.643487914668.issue1018@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> np.ones([1,2],'int')
array([[1, 1]])
>>>> np.ones([1,2],'int')
Traceback (application-level):
  File "<inline>", line 1 in <module>
    np.ones([1,2],'int')
TypeError: data type not understood

Same issue with zeros instead of ones and 'float' instead of 'int'

----------
messages: 3806
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: ones(shape,'int') and zeros(shape,'int') doesn't work

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1018>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 17:21:24 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Tue, 24 Jan 2012 16:21:24 +0000
Subject: [pypy-issue] [issue1018] ones(shape, 'int') and zeros(shape,
	'int') doesn't work
In-Reply-To: <1327421958.09.0.643487914668.issue1018@bugs.pypy.org>
Message-ID: <1327422084.22.0.279136079358.issue1018@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

I had committed similar issue with 'int16', it was fixed, but this 'int' without
number still buggy. I would reopened old ticket instead but I haven't found it
(maybe I used mail list that time instead)

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1018>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 18:37:59 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Tue, 24 Jan 2012 17:37:59 +0000
Subject: [pypy-issue] [issue1019] numpypy: zeros,
	ones and empty miss docstrings
In-Reply-To: <1327426679.56.0.693736643539.issue1019@bugs.pypy.org>
Message-ID: <1327426679.56.0.693736643539.issue1019@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

All the funcs 
>>>> help(np.zeros)
Help on built-in function zeros in module _numpypy:
zeros(...)
>>>> help(np.empty)
Help on built-in function zeros in module _numpypy:
zeros(...)
>>>> help(np.ones)
Help on built-in function ones in module _numpypy:
ones(...)

Also, I'm interested in 'order' argument - seems like it is absent:
>>> np.ones((1,2),order='F')
array([[ 1.,  1.]])
>>>> np.ones((1,2),order='F')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: ones() got an unexpected keyword argument 'order'

----------
messages: 3808
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: zeros, ones and empty miss docstrings

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1019>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 20:57:08 2012
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Tue, 24 Jan 2012 19:57:08 +0000
Subject: [pypy-issue] [issue987] AppTestSocket.test_unix_socket_connect can
	fail when	TMPDIR is long
In-Reply-To: <1325964194.81.0.726900366839.issue987@bugs.pypy.org>
Message-ID: <1327435028.8.0.795608851691.issue987@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

Fixed in r522114ac6c4a

----------
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue987>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 24 23:25:39 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Tue, 24 Jan 2012 22:25:39 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1327443939.96.0.526960528736.issue1016@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

Reconfirmed with hg changeset 51742:522114ac6c4a on OSX.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 00:42:35 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Tue, 24 Jan 2012 23:42:35 +0000
Subject: [pypy-issue] [issue1020] segfault when running test_greenlet.py
	through pypy	pytest.py
In-Reply-To: <1327448555.44.0.722948956012.issue1020@bugs.pypy.org>
Message-ID: <1327448555.44.0.722948956012.issue1020@bugs.pypy.org>


New submission from Justin Patrin <papercrane at reversefold.com>:

On Linux x64:

{default//pypy} $ PYTHONPATH=. pypy pytest.py 
pypy/module/test_lib_pypy/test_greenlet.py                                                            
(papercrane at rrlrrll:~/src/pypy/)
================================================================================ 
test session 
starts 
================================================================================
platform linux2 -- Python 2.7.1[pypy-1.7.1] -- pytest-2.1.0.dev4
pytest-2.1.0.dev4 from /home/papercrane/src/pypy/pytest.pyc
collected 19 items 

pypy/module/test_lib_pypy/test_greenlet.py zsh: abort      PYTHONPATH=. pypy 
pytest.py 
pypy/module/test_lib_pypy/test_greenlet.py

On OSX 10.7.2:
{default//pypy} $ PYTHONPATH=. pypy pytest.py 
pypy/module/test_lib_pypy/test_greenlet.py                                                       
(jpatrin at jpatrin-mbp-lol:~/src/pypy/)
/Users/jpatrin/src/pypy/_pytest/core.py:148: UserWarning: Module py was already 
imported from 
/Users/jpatrin/src/pypy/py/__init__.pyc, but /Users/jpatrin/src/pypy/site-
packages/py-1.4.6-
py2.7.egg is being added to sys.path
  from pkg_resources import iter_entry_points, DistributionNotFound
================================================================================ 
test session 
starts 
================================================================================
platform 
darwin -- Python 2.7.1[pypy-1.8.1] -- pytest-2.1.0.dev4
pytest-2.1.0.dev4 from /Users/jpatrin/src/pypy/pytest.pyccollected 19 items 

pypy/module/test_lib_pypy/test_greenlet.py zsh: segmentation fault  PYTHONPATH=. 
pypy pytest.py 
pypy/module/test_lib_pypy/test_greenlet.py

Works with python 2.6.7 or python 2.7:
{default//pypy} $ PYTHONPATH=. python pytest.py 
pypy/module/test_lib_pypy/test_greenlet.py                                                     
(jpatrin at jpatrin-mbp-lol:~/src/pypy/)
/Users/jpatrin/src/pypy/_pytest/core.py:148: UserWarning: Module py was already 
imported from 
/Users/jpatrin/src/pypy/py/__init__.py, but 
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-
packages/py-1.4.6-
py2.6.egg is being added to sys.path  from pkg_resources import 
iter_entry_points, 
DistributionNotFound============================================================
==================
== test session starts 
================================================================================
platform darwin -- 
Python 2.6.7 -- pytest-2.1.0.dev4pytest-2.1.0.dev4 from 
/Users/jpatrin/src/pypy/pytest.pycollected 
19 items 
pypy/module/test_lib_pypy/test_greenlet.py ...................

============================================================================= 19 
passed in 5.91 
seconds 
=============================================================================

----------
messages: 3811
nosy: papercrane, pypy-issue
priority: bug
status: unread
title: segfault when running test_greenlet.py through pypy pytest.py

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1020>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 01:07:57 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Wed, 25 Jan 2012 00:07:57 +0000
Subject: [pypy-issue] [issue1020] segfault when running test_greenlet.py
	through pypy	pytest.py
In-Reply-To: <1327448555.44.0.722948956012.issue1020@bugs.pypy.org>
Message-ID: <1327450077.88.0.224308276601.issue1020@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

Not sure if this is the same segfault but if I try to run my jevent both.py 
example (see Issue #1016 for tarball) through py.py now that the --continuation 
error is fixed (thanks fijal) I also get a crash.

PYTHONPATH=. python ~/src/pypy/pypy/bin/py.py --allworkingmodules -v 
examples/both.py

The output ends with:
[platform:execute] gcc -dynamiclib -undefined dynamic_lookup 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_9.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_10.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_11.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_12.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_13.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_14.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_15.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_16.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_17.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_18.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_19.o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/module_cache/module_20.o -arch x86_64 -Wl,-
exported_symbols_list,/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-
default-48/dynamic-symbols-6 -lssl -lcrypto -o 
/var/folders/qv/4vbv0p790d15tdmtlmncmsnr0000gq/T/usession-default-
48/shared_cache/externmod_2.dylib
Python(58429) malloc: *** error for object 0x7f950c30b6f8: incorrect checksum 
for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1020>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 13:19:56 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 25 Jan 2012 12:19:56 +0000
Subject: [pypy-issue] [issue1021] numpypy: incorrect dtype comparison (vs
	original numpy)
In-Reply-To: <1327493996.44.0.605801799157.issue1021@bugs.pypy.org>
Message-ID: <1327493996.44.0.605801799157.issue1021@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> a=np.array([1,2,3],'int64')
>>> a.dtype
dtype('int64')
>>> a.dtype=='int64'
True

>>>> a=np.array([1,2,3],'int64')
>>>> a.dtype
dtype('int64')
>>>> a.dtype=='int64'
False

----------
messages: 3813
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: incorrect dtype comparison (vs original numpy)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1021>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 14:10:00 2012
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Wed, 25 Jan 2012 13:10:00 +0000
Subject: [pypy-issue] [issue1022] dict.update significantly slower than
	series of	dict.__setitem__
In-Reply-To: <1327497000.97.0.209820064529.issue1022@bugs.pypy.org>
Message-ID: <1327497000.97.0.209820064529.issue1022@bugs.pypy.org>


New submission from Xavier Morel <bugs.pypy.org at masklinn.net>:

In CPython, as the number of keys grow dict.update settles at roughly half the 
speed of an 
equivalent bunch of dict[key]=value sequence:

    > python2.7 -m timeit -s 'd = {}' 'd["foo"] = 3' 'd["bar"] = 4' 'd["baz"] = 5' 
'd["qux"] = 6' 'd["quux"] = 7'
    1000000 loops, best of 3: 0.395 usec per loop
    > python2.7 -m timeit -s 'd = {}' 'd.update(foo=3, bar=4, baz=5, qux=6, 
quux=7)'
    1000000 loops, best of 3: 0.657 usec per loop

In Pypy, on the other hand, the difference in speed is on the order of 20x, even 
while 
setting 5 keys and dict.update is ~30% the speed of the equivalent call in CPython 
at 
almost 2?sec/loop to CPython's 0.66?sec/loop, while pypy's __setitem__ is more 
than 4 times 
faster than CPython:

    > pypy-c -m timeit -s 'd = {}' 'd["foo"] = 3' 'd["bar"] = 4' 'd["baz"] = 5' 
'd["qux"] 
= 6' 'd["quux"] = 7'
    10000000 loops, best of 3: 0.0877 usec per loop
    > pypy-c -m timeit -s 'd = {}' 'd.update(foo=3, bar=4, baz=5, qux=6, quux=7)'
    100000 loops, best of 3: 1.95 usec per loop

that kind-of bothers me, as I tend to use dict.update over long sequences of 
setitem for 
readability purpose. Now of course half a ?sec per call is not a big difference in 
absolute, but still?

Versions information:
* OSX 10.6.8
* CPython 2.7.2 (Macports)
* Pypy 1.7.0 Python 2.7.1 (?, Nov 24 2011, 10:57:50) (Macports)

----------
messages: 3814
nosy: masklinn, pypy-issue
priority: performance bug
status: unread
title: dict.update significantly slower than series of dict.__setitem__

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1022>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 14:11:58 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 25 Jan 2012 13:11:58 +0000
Subject: [pypy-issue] [issue1023] numpypy: empty() cannot handle
	dtype='object'
In-Reply-To: <1327497118.21.0.39568479379.issue1023@bugs.pypy.org>
Message-ID: <1327497118.21.0.39568479379.issue1023@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> import numpy as np
>>> np.empty((2,3),object)
array([[None, None, None],
       [None, None, None]], dtype=object)

>>>> import numpypy as np
>>>> np.empty((2,3),object)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: data type not understood

----------
messages: 3815
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: empty() cannot handle dtype='object'

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1023>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 14:13:47 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 25 Jan 2012 13:13:47 +0000
Subject: [pypy-issue] [issue1023] numpypy: empty() cannot handle
	dtype='object'
In-Reply-To: <1327497118.21.0.39568479379.issue1023@bugs.pypy.org>
Message-ID: <1327497227.73.0.395227562264.issue1023@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

dtype 'object' seems won't be supported according to dev team plans

----------
status: unread -> wontfix

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1023>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 14:45:48 2012
From: tracker at bugs.pypy.org (Carsten Senger)
Date: Wed, 25 Jan 2012 13:45:48 +0000
Subject: [pypy-issue] [issue1015] Add build to run the benchmarks with
	python 2.7 tip
In-Reply-To: <1327183792.09.0.47130209624.issue1015@bugs.pypy.org>
Message-ID: <1327499148.17.0.335261931341.issue1015@bugs.pypy.org>


Carsten Senger <senger at rehfisch.de> added the comment:

I went on and removed the guessing about what is the executable name, revision
and project from the interpreter path and turned that into explicit command line
arguments to runner.py. Then added the same options to upload the baseline
result and changed the build factories to use the new options.

I also added a dummy interpreter `nullpython.py` to circumvent running two real
benchmarks if we are only interested in the first and used it in the
CPythonBenchmark factory.

The --upload[-baseline]-urls parameter accepts comma seperated urls so we can
upload the results to both speed.pypy.org and speed.python.org (provided both
use the same 'project' and 'executable' names in codespeed).

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1015>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 15:02:44 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 25 Jan 2012 14:02:44 +0000
Subject: [pypy-issue] [issue1020] segfault when running test_greenlet.py
	through pypy	pytest.py
In-Reply-To: <1327448555.44.0.722948956012.issue1020@bugs.pypy.org>
Message-ID: <1327500164.63.0.943963954518.issue1020@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Sorry, I tried to debug it but I'm blocked by not remembering exactly how
asmgcroot interacts with continuations.  I may spend more time, but I may also
decide that it means that continuations don't really work in a default pypy. :-(

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1020>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 17:10:10 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 25 Jan 2012 16:10:10 +0000
Subject: [pypy-issue] [issue1024] numpypy: bug with type/dtype
In-Reply-To: <1327507810.23.0.824069274841.issue1024@bugs.pypy.org>
Message-ID: <1327507810.23.0.824069274841.issue1024@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

This bug prevents porting of numpy funcs concatenate, hstack, vstack, dstack and
may affect lots of other code (unrevealed yet).
code:
a = N.array((1, 2)).dtype.type
b = N.int64
print a, b
print a==b
print id(a), id(b)

CPython numpy result:

<type 'numpy.int64'> <type 'numpy.int64'>
True
140387833263232 140387833263232

PyPy result:

<type 'numpypy.int64'> <type 'numpypy.int64'>
False
39257824 39258752

----------
messages: 3819
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: bug with type/dtype

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1024>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 17:29:43 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 25 Jan 2012 16:29:43 +0000
Subject: [pypy-issue] [issue1024] numpypy: bug with type/dtype
In-Reply-To: <1327507810.23.0.824069274841.issue1024@bugs.pypy.org>
Message-ID: <1327508983.3.0.0106249786511.issue1024@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Fixed in 3890a6e149fa

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1024>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 21:09:45 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Wed, 25 Jan 2012 20:09:45 +0000
Subject: [pypy-issue] [issue1020] segfault when running test_greenlet.py
	through pypy	pytest.py
In-Reply-To: <1327448555.44.0.722948956012.issue1020@bugs.pypy.org>
Message-ID: <1327522185.32.0.672585076336.issue1020@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

Are you saying that greenlets may be set as a non-working module in the future? 
That would be a shame.... It's odd that running the greenlet test with CPython 
(which, to my knowledge, still runs them through py.py) but running them through 
pypy-c crashes.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1020>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 25 21:31:29 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 25 Jan 2012 20:31:29 +0000
Subject: [pypy-issue] [issue1020] segfault when running test_greenlet.py
	through pypy	pytest.py
In-Reply-To: <1327448555.44.0.722948956012.issue1020@bugs.pypy.org>
Message-ID: <1327523489.3.0.773452330751.issue1020@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

I think it works fine with "shadowstack", which is the default on OS/X and
Windows but not on Linux.  Maybe you can try with a version of pypy translated
with "--gcrootfinder=shadowstack".

The medium-term goal is to use only "shadowstack" on all platforms.  There is
still a small performance gain for using "asmgcc" right now, but it's buggy
enough that it doesn't really fully support the kind of gcc distributed with
OS/X nor Windows' MSVC.  If we reach the goal of making the performance gain
negligible, then this bug report will just fall into the not-relevant-any-more
category.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1020>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 26 07:42:30 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Thu, 26 Jan 2012 06:42:30 +0000
Subject: [pypy-issue] [issue1020] segfault when running test_greenlet.py
	through pypy	pytest.py
In-Reply-To: <1327448555.44.0.722948956012.issue1020@bugs.pypy.org>
Message-ID: <1327560150.33.0.705439700904.issue1020@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

On both OSX and linux:

$ PYTHONPATH=. pypy/translator/goal/pypy-c.min pytest.py 
pypy/module/test_lib_pypy/test_greenlet.py
..ends with..
pypy/module/test_lib_pypy/test_greenlet.py zsh: segmentation fault  PYTHONPATH=. 
pypy/translator/goal/pypy-c.min pytest.py

pypy-c.min translated with
./pypy-c translate.py --opt=jit --output=pypy-c.min --gcrootfinder=shadowstack 
targetpypystandalone.py


I'm unable to get that later error again now, but I'm getting segfaults when 
trying to run both.py through py.py with both python and pypy-c.min.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1020>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 26 18:22:09 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 26 Jan 2012 17:22:09 +0000
Subject: [pypy-issue] [issue1021] numpypy: incorrect dtype comparison (vs
	original numpy)
In-Reply-To: <1327493996.44.0.605801799157.issue1021@bugs.pypy.org>
Message-ID: <1327598529.44.0.377872721605.issue1021@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Fixed in b4faea8e796e thanks!

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1021>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 26 20:31:15 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 26 Jan 2012 19:31:15 +0000
Subject: [pypy-issue] [issue1025] numpypy: commit tests for vstack, hstack,
	dstack
In-Reply-To: <1327606275.43.0.276170308758.issue1025@bugs.pypy.org>
Message-ID: <1327606275.43.0.276170308758.issue1025@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

http://pastebin.com/G6VeykJ6

----------
messages: 3825
nosy: Dmitrey, pypy-issue
priority: feature
status: unread
title: numpypy: commit tests for vstack, hstack, dstack

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1025>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 26 22:31:12 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 26 Jan 2012 21:31:12 +0000
Subject: [pypy-issue] [issue1026] numpypy: incorrect shape of array with
	zero-shape coords
In-Reply-To: <1327613472.02.0.951420920979.issue1026@bugs.pypy.org>
Message-ID: <1327613472.02.0.951420920979.issue1026@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> np.array(np.ones((0,3,4))).shape
(0, 3, 4)

>>>> np.array(np.ones((0,3,4))).shape
(0,)

----------
messages: 3826
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: incorrect shape of array with zero-shape coords

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1026>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 27 21:31:43 2012
From: tracker at bugs.pypy.org (ita)
Date: Fri, 27 Jan 2012 20:31:43 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1327696303.23.0.687796324079.issue934@bugs.pypy.org>


ita <tnagy1024 at gmail.com> added the comment:

I have tried the Linux 64 version from today both jit and nojit and i am still
getting the build hanging either in the middle or near the end, and with g++
processes in zombie mode (pypy-c-nojit-51842-457e2166648c-linux64).

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue934>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 28 10:27:51 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 28 Jan 2012 09:27:51 +0000
Subject: [pypy-issue] [issue1020] segfault when running test_greenlet.py
	through pypy	pytest.py
In-Reply-To: <1327448555.44.0.722948956012.issue1020@bugs.pypy.org>
Message-ID: <1327742871.66.0.31205872689.issue1020@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Baaaah.  Closed as invalid.  It's a level issue: the test tries to run by
calling directly the C function stacklet_switch(), it's not a test that uses
greenlets of the host Python.  See 451261ed7b89.

----------
status: chatting -> invalid

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1020>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 28 12:17:26 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 28 Jan 2012 11:17:26 +0000
Subject: [pypy-issue] [issue1009] numpypy ndarray bug "TypeError: 'flatiter'
	object is not	subscriptable"
In-Reply-To: <1326911431.89.0.640231229059.issue1009@bugs.pypy.org>
Message-ID: <1327749446.7.0.675199766687.issue1009@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Fixed.

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1009>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 28 12:17:49 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 28 Jan 2012 11:17:49 +0000
Subject: [pypy-issue] [issue1006] numpypy array(1).reshape(1,1) fails
In-Reply-To: <1326901137.81.0.0583721843168.issue1006@bugs.pypy.org>
Message-ID: <1327749469.02.0.384141016749.issue1006@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Fixed

----------
nosy: +fijal
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1006>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 29 01:21:19 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Sun, 29 Jan 2012 00:21:19 +0000
Subject: [pypy-issue] [issue950] startup_hook in readline
In-Reply-To: <1322809376.17.0.935020797328.issue950@bugs.pypy.org>
Message-ID: <1327796479.21.0.811057090936.issue950@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

I applied hpaulj's changes, translated pypy, and verified that the fix made it
work like CPython on the test script from PyMOTW.

It's up as
https://bitbucket.org/pypy/pypy/pull-request/24/apply-hpauljs-patch-to-fix-issue950

----------
nosy: +dripton

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue950>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 29 02:49:09 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 29 Jan 2012 01:49:09 +0000
Subject: [pypy-issue] [issue1027] Do something with longs
In-Reply-To: <1327801749.1.0.844113427834.issue1027@bugs.pypy.org>
Message-ID: <1327801749.1.0.844113427834.issue1027@bugs.pypy.org>


New submission from Fijal <fijall at gmail.com>:

A bit no clue what, but performance of longs is fairly disastrous right now, so I 
suppose we should do something with it (not attaching any benchmarks, but 
*anything* is slow with them).

----------
messages: 3832
nosy: fijal, pypy-issue
priority: performance bug
status: unread
title: Do something with longs

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1027>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 29 02:52:08 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 29 Jan 2012 01:52:08 +0000
Subject: [pypy-issue] [issue950] startup_hook in readline
In-Reply-To: <1322809376.17.0.935020797328.issue950@bugs.pypy.org>
Message-ID: <1327801928.3.0.0446138711327.issue950@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

I hope fixed

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue950>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 29 12:03:31 2012
From: tracker at bugs.pypy.org (Pekka Y)
Date: Sun, 29 Jan 2012 11:03:31 +0000
Subject: [pypy-issue] [issue1028] Putting numpypy arrays to
	(multiprocessing) queue fails
In-Reply-To: <1327835011.23.0.769244311514.issue1028@bugs.pypy.org>
Message-ID: <1327835011.23.0.769244311514.issue1028@bugs.pypy.org>


New submission from Pekka Y <py at iki.fi>:

Queueing numpypy arrays fails within pickle.py. Attached code works with 
CPython/multiprocessing/numpy combination but breaks the PyPy/NumPyPy one.

----------
files: pypy_queue_numpy_arrays.py
messages: 3834
nosy: pypy-issue, ypekka
priority: bug
status: unread
title: Putting numpypy arrays to (multiprocessing) queue fails

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1028>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 29 12:15:12 2012
From: tracker at bugs.pypy.org (Garen Parham)
Date: Sun, 29 Jan 2012 11:15:12 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1327835712.72.0.297003189658.issue934@bugs.pypy.org>


Garen Parham <garen.p at gmail.com> added the comment:

In 1.7 and most recent win32 nightly (that built, from 1/22) pypy throws the 
following error pretty quickly:

Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File ".\waf", line 155, in <module>
    wafdir = find_lib()
  File ".\waf", line 152, in find_lib
    unpack_wafdir(dir)
  File ".\waf", line 109, in unpack_wafdir
    os.unlink(tmp)
WindowsError: [Error 32] The process cannot access the file because it is being 
used by another process.: t.bz2

No problems with cpython 2.7.2

----------
nosy: +Garen

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue934>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 29 12:46:34 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 29 Jan 2012 11:46:34 +0000
Subject: [pypy-issue] [issue1028] Putting numpypy arrays to
	(multiprocessing) queue fails
In-Reply-To: <1327835011.23.0.769244311514.issue1028@bugs.pypy.org>
Message-ID: <1327837594.01.0.206277793467.issue1028@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Not really a bug.

Numpypy arrays currently lack a __reduce__ method, so they can't be pickled.  Stay 
tuned.

----------
nosy: +mikefc
priority: bug -> feature
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1028>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 30 03:09:30 2012
From: tracker at bugs.pypy.org (Garen Parham)
Date: Mon, 30 Jan 2012 02:09:30 +0000
Subject: [pypy-issue] [issue1029] cpython test_subprocess.py fails
In-Reply-To: <1327889370.62.0.40349489632.issue1029@bugs.pypy.org>
Message-ID: <1327889370.62.0.40349489632.issue1029@bugs.pypy.org>


New submission from Garen Parham <garen.p at gmail.com>:

On Ubuntu Linux 11.10, pypy trunk currently fails one of the modified 
test_subproces.py unit tests like so:

garen at ubuntu:~/dev/bins$ ~/dev/bins/pypy-c-jit-51842-457e2166648c-linux/bin/pypy 
~/dev/bins//pypy-c-jit-51842-457e2166648c-linux/lib-python/modified-
2.7/test/test_subprocess.py
...
======================================================================
FAIL: test_executable_without_cwd (__main__.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/garen/dev/bins//pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/test/test_subprocess.py", line 163, in 
test_executable_without_cwd
    self.assertEqual(p.returncode, 47)
AssertionError: 1 != 47

======================================================================
FAIL: test_executable_without_cwd (__main__.ProcessTestCaseNoPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/garen/dev/bins//pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/test/test_subprocess.py", line 163, in 
test_executable_without_cwd
    self.assertEqual(p.returncode, 47)
AssertionError: 1 != 47

Also, the test_subprocess.py shipped with the latest cpython 2.7.2.5 has several 
new tests that also fail:

======================================================================
ERROR: test_communicate_epipe_only_stdin (__main__.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 617, in 
test_communicate_epipe_only_stdin
    p.communicate("x" * 2**20)
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/subprocess.py", line 729, in communicate
    self.stdin.write(input)
IOError: [Errno 32] Broken pipe: '<fdopen>'

======================================================================
ERROR: test_close_fd_0 (__main__.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 830, in 
test_close_fd_0
    self.check_close_std_fds([0])
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 821, in 
check_close_std_fds
    err = test_support.strip_python_stderr(err)
AttributeError: 'module' object has no attribute 'strip_python_stderr'

======================================================================
ERROR: test_close_fd_1 (__main__.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 833, in 
test_close_fd_1
    self.check_close_std_fds([1])
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 821, in 
check_close_std_fds
    err = test_support.strip_python_stderr(err)
AttributeError: 'module' object has no attribute 'strip_python_stderr'

======================================================================
ERROR: test_close_fd_2 (__main__.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 836, in 
test_close_fd_2
    self.check_close_std_fds([2])
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 821, in 
check_close_std_fds
    err = test_support.strip_python_stderr(err)
AttributeError: 'module' object has no attribute 'strip_python_stderr'

======================================================================
ERROR: test_close_fds_0_1 (__main__.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 839, in 
test_close_fds_0_1
    self.check_close_std_fds([0, 1])
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 821, in 
check_close_std_fds
    err = test_support.strip_python_stderr(err)
AttributeError: 'module' object has no attribute 'strip_python_stderr'

======================================================================
ERROR: test_close_fds_0_1_2 (__main__.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 850, in 
test_close_fds_0_1_2
    self.check_close_std_fds([0, 1, 2])
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 821, in 
check_close_std_fds
    err = test_support.strip_python_stderr(err)
AttributeError: 'module' object has no attribute 'strip_python_stderr'

======================================================================
ERROR: test_close_fds_0_2 (__main__.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 842, in 
test_close_fds_0_2
    self.check_close_std_fds([0, 2])
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 821, in 
check_close_std_fds
    err = test_support.strip_python_stderr(err)
AttributeError: 'module' object has no attribute 'strip_python_stderr'

======================================================================
ERROR: test_close_fds_1_2 (__main__.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 845, in 
test_close_fds_1_2
    self.check_close_std_fds([1, 2])
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 821, in 
check_close_std_fds
    err = test_support.strip_python_stderr(err)
AttributeError: 'module' object has no attribute 'strip_python_stderr'

======================================================================
ERROR: test_communicate_epipe (__main__.ProcessTestCaseNoPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 609, in 
test_communicate_epipe
    p.communicate("x" * 2**20)
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/subprocess.py", line 740, in communicate
    return self._communicate(input)
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/subprocess.py", line 1263, in _communicate
    stdout, stderr = self._communicate_with_select(input)
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/subprocess.py", line 1365, in _communicate_with_select
    bytes_written = os.write(self.stdin.fileno(), chunk)
OSError: [Errno 32] Broken pipe

======================================================================
ERROR: test_communicate_epipe_only_stdin (__main__.ProcessTestCaseNoPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 617, in 
test_communicate_epipe_only_stdin
    p.communicate("x" * 2**20)
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/subprocess.py", line 729, in communicate
    self.stdin.write(input)
IOError: [Errno 32] Broken pipe: '<fdopen>'

======================================================================
FAIL: test_executable_without_cwd (__main__.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 163, in 
test_executable_without_cwd
    self.assertEqual(p.returncode, 47)
AssertionError: 1 != 47

======================================================================
FAIL: test_wait_when_sigchild_ignored (__main__.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 860, in 
test_wait_when_sigchild_ignored
    " non-zero with this error:\n%s" % stderr)
AssertionError: sigchild_ignore.py exited non-zero with this error:
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "/home/garen/dev/bins/Python-
2.7.2/Lib/test/subprocessdata/sigchild_ignore.py", line 6, in <module>
    subprocess.Popen([sys.executable, '-c', 'print("albatross")']).wait()
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/subprocess.py", line 1247, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/subprocess.py", line 471, in _eintr_retry_call
    return func(*args)
OSError: [Errno 10] No child processes


======================================================================
FAIL: test_executable_without_cwd (__main__.ProcessTestCaseNoPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 163, in 
test_executable_without_cwd
    self.assertEqual(p.returncode, 47)
AssertionError: 1 != 47

----------------------------------------------------------------------
Ran 127 tests in 23.897s

FAILED (failures=3, errors=10, skipped=14)
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 1053, in <module>
    test_main()
  File "./Python-2.7.2/Lib/test/test_subprocess.py", line 1049, in test_main
    test_support.run_unittest(*unit_tests)
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/test/test_support.py", line 1138, in run_unittest
    _run_suite(suite)
  File "/home/garen/dev/bins/pypy-c-jit-51842-457e2166648c-linux/lib-
python/modified-2.7/test/test_support.py", line 1092, in _run_suite
    raise TestFailed(err)
TestFailed: multiple errors occurred

At least a few of these appear to be related to some previously filed issues:
https://bugs.pypy.org/issue934
https://bugs.pypy.org/issue828

----------
messages: 3837
nosy: Garen, pypy-issue
priority: bug
release: ???
status: unread
title: cpython test_subprocess.py fails

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1029>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 30 03:17:37 2012
From: tracker at bugs.pypy.org (Garen Parham)
Date: Mon, 30 Jan 2012 02:17:37 +0000
Subject: [pypy-issue] [issue1030] cpython test_subprocess.py fails on Windows
In-Reply-To: <1327889857.34.0.498001259809.issue1030@bugs.pypy.org>
Message-ID: <1327889857.34.0.498001259809.issue1030@bugs.pypy.org>


New submission from Garen Parham <garen.p at gmail.com>:

test_subprocess.py in lib-python/modified-2.7/ fails on current trunk of pypy 
like so:

======================================================================
ERROR: test_leaking_fds_on_error (__main__.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "U:\vcs\hg\bins\pypy-c-jit-51616-5aa09e8483d3-win32\lib-python\modified-
2.7\test\test_subprocess.py", line 579, in test_leaking_fds_on_error
    raise c.exception
WindowsError: Error

======================================================================
ERROR: test_no_leaking (__main__.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "U:\vcs\hg\bins\pypy-c-jit-51616-5aa09e8483d3-win32\lib-python\modified-
2.7\test\test_subprocess.py", line 511, in test_no_leaking
    data = p.communicate(b"lime")[0]
  File "U:\vcs\hg\bins\pypy-c-jit-51616-5aa09e8483d3-win32\lib-python\modified-
2.7\subprocess.py", line 740, in communicate
    return self._communicate(input)
  File "U:\vcs\hg\bins\pypy-c-jit-51616-5aa09e8483d3-win32\lib-python\modified-
2.7\subprocess.py", line 975, in _communicate
    stderr = stderr[0]
IndexError: list index out of range

----------------------------------------------------------------------
Ran 115 tests in 6.740s

FAILED (errors=2, skipped=58)
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "U:\vcs\hg\bins\pypy-c-jit-51616-5aa09e8483d3-win32\lib-python\modified-
2.7\test\test_subprocess.py", line 974, in <module>
    test_main()
  File "U:\vcs\hg\bins\pypy-c-jit-51616-5aa09e8483d3-win32\lib-python\modified-
2.7\test\test_subprocess.py", line 970, in test_main
    test_support.run_unittest(*unit_tests)
  File "U:\vcs\hg\bins\pypy-c-jit-51616-5aa09e8483d3-win32\lib-python\modified-
2.7\test\test_support.py", line 1138, in run_unittest
    _run_suite(suite)
  File "U:\vcs\hg\bins\pypy-c-jit-51616-5aa09e8483d3-win32\lib-python\modified-
2.7\test\test_support.py", line 1092, in _run_suite
    raise TestFailed(err)
TestFailed: multiple errors occurred

When run against the newer test_subprocess.py shipped with cpython 2.7.2.5, more 
test failures appear.  Many of the new test failures are also present when run 
under Linux, filed separately here:

https://bugs.pypy.org/issue1029

Hope that helps.

----------
messages: 3838
nosy: Garen, pypy-issue
priority: bug
status: unread
title: cpython test_subprocess.py fails on Windows

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1030>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 30 07:56:38 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 30 Jan 2012 06:56:38 +0000
Subject: [pypy-issue] [issue1026] numpypy: incorrect shape of array with
	zero-shape coords
In-Reply-To: <1327613472.02.0.951420920979.issue1026@bugs.pypy.org>
Message-ID: <1327906598.8.0.667345564638.issue1026@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

This seems to have been fixed in latest nightly.

============ python
>>> import numpy as np
>>> np.array(np.ones((0,3,4))).shape
(0, 3, 4)


============ pypy (latest nightly)
>>>> import numpypy as np
>>>> np.ones((0,3,4)).shape
(0, 3, 4)

----------
nosy: +mikefc
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1026>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 30 08:18:43 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 30 Jan 2012 07:18:43 +0000
Subject: [pypy-issue] [issue1026] numpypy: incorrect shape of array with
	zero-shape coords
In-Reply-To: <1327613472.02.0.951420920979.issue1026@bugs.pypy.org>
Message-ID: <1327907923.53.0.852965473543.issue1026@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

pasted the wrong output for numpypy

============ pypy (latest nightly)
>>>> np.array(np.ones((0,3,4))).shape
(0, 3, 4)

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1026>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 30 08:29:41 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 30 Jan 2012 07:29:41 +0000
Subject: [pypy-issue] [issue1029] cpython test_subprocess.py fails
In-Reply-To: <1327889370.62.0.40349489632.issue1029@bugs.pypy.org>
Message-ID: <1327908581.17.0.841848270918.issue1029@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

First, PyPy is currently at version 2.7.1.
And it's a bit unfair to run 2.7.2 tests without 2.7.2 stdlib (cf. the error about 
strip_python_stderr).

The first errors are interesting though, but I cannot reproduce them. OTOH this test is 
skipped by cpython, see http://bugs.python.org/issue7774 . PyPy should probably improve 
its sysconfig.is_python_build() function.

----------
nosy: +afa
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1029>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 30 09:01:19 2012
From: tracker at bugs.pypy.org (Garen Parham)
Date: Mon, 30 Jan 2012 08:01:19 +0000
Subject: [pypy-issue] [issue1029] cpython test_subprocess.py fails
In-Reply-To: <1327889370.62.0.40349489632.issue1029@bugs.pypy.org>
Message-ID: <1327910479.35.0.451042104156.issue1029@bugs.pypy.org>


Garen Parham <garen.p at gmail.com> added the comment:

The test_subprocess.py file in pypy isn't much different, except it comments out 
SET_BINARY near the top of the file, and the newer cpython test_subprocess.py 
adds some additional tests.

If I patch the local pypy test_subprocess.py by commenting out SET_BINARY and 
adding the new tests, I still see the same failures (though the strip_* errors 
being gone).

Attached is the updated test_subprocess.py that can be run with your local pypy 
to eliminate the 2.7.1 vs 2.7.2 stdlib issue.  

Can you repro the errors now?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1029>
________________________________________
-------------- next part --------------
import unittest
from test import test_support
import subprocess
import sys
import signal
import os
import errno
import tempfile
import time
import re
import sysconfig

mswindows = (sys.platform == "win32")

#
# Depends on the following external programs: Python
#

#if mswindows:
#    SETBINARY = ('import msvcrt; msvcrt.setmode(sys.stdout.fileno(), '
#                                                'os.O_BINARY);')
#else:
#    SETBINARY = ''


try:
    mkstemp = tempfile.mkstemp
except AttributeError:
    # tempfile.mkstemp is not available
    def mkstemp():
        """Replacement for mkstemp, calling mktemp."""
        fname = tempfile.mktemp()
        return os.open(fname, os.O_RDWR|os.O_CREAT), fname


class BaseTestCase(unittest.TestCase):
    def setUp(self):
        # Try to minimize the number of children we have so this test
        # doesn't crash on some buildbots (Alphas in particular).
        test_support.reap_children()

    def tearDown(self):
        for inst in subprocess._active:
            inst.wait()
        subprocess._cleanup()
        self.assertFalse(subprocess._active, "subprocess._active not empty")

    def assertStderrEqual(self, stderr, expected, msg=None):
        # In a debug build, stuff like "[6580 refs]" is printed to stderr at
        # shutdown time.  That frustrates tests trying to check stderr produced
        # from a spawned Python process.
        actual = re.sub(r"\[\d+ refs\]\r?\n?$", "", stderr)
        self.assertEqual(actual, expected, msg)


class ProcessTestCase(BaseTestCase):

    def test_call_seq(self):
        # call() function with sequence argument
        rc = subprocess.call([sys.executable, "-c",
                              "import sys; sys.exit(47)"])
        self.assertEqual(rc, 47)

    def test_check_call_zero(self):
        # check_call() function with zero return code
        rc = subprocess.check_call([sys.executable, "-c",
                                    "import sys; sys.exit(0)"])
        self.assertEqual(rc, 0)

    def test_check_call_nonzero(self):
        # check_call() function with non-zero return code
        with self.assertRaises(subprocess.CalledProcessError) as c:
            subprocess.check_call([sys.executable, "-c",
                                   "import sys; sys.exit(47)"])
        self.assertEqual(c.exception.returncode, 47)

    def test_check_output(self):
        # check_output() function with zero return code
        output = subprocess.check_output(
                [sys.executable, "-c", "print 'BDFL'"])
        self.assertIn('BDFL', output)

    def test_check_output_nonzero(self):
        # check_call() function with non-zero return code
        with self.assertRaises(subprocess.CalledProcessError) as c:
            subprocess.check_output(
                    [sys.executable, "-c", "import sys; sys.exit(5)"])
        self.assertEqual(c.exception.returncode, 5)

    def test_check_output_stderr(self):
        # check_output() function stderr redirected to stdout
        output = subprocess.check_output(
                [sys.executable, "-c", "import sys; sys.stderr.write('BDFL')"],
                stderr=subprocess.STDOUT)
        self.assertIn('BDFL', output)

    def test_check_output_stdout_arg(self):
        # check_output() function stderr redirected to stdout
        with self.assertRaises(ValueError) as c:
            output = subprocess.check_output(
                    [sys.executable, "-c", "print 'will not be run'"],
                    stdout=sys.stdout)
            self.fail("Expected ValueError when stdout arg supplied.")
        self.assertIn('stdout', c.exception.args[0])

    def test_call_kwargs(self):
        # call() function with keyword args
        newenv = os.environ.copy()
        newenv["FRUIT"] = "banana"
        rc = subprocess.call([sys.executable, "-c",
                              'import sys, os;'
                              'sys.exit(os.getenv("FRUIT")=="banana")'],
                             env=newenv)
        self.assertEqual(rc, 1)

    def test_stdin_none(self):
        # .stdin is None when not redirected
        p = subprocess.Popen([sys.executable, "-c", 'print "banana"'],
                         stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        self.addCleanup(p.stdout.close)
        self.addCleanup(p.stderr.close)
        p.wait()
        self.assertEqual(p.stdin, None)

    def test_stdout_none(self):
        # .stdout is None when not redirected
        p = subprocess.Popen([sys.executable, "-c",
                             'print "    this bit of output is from a '
                             'test of stdout in a different '
                             'process ..."'],
                             stdin=subprocess.PIPE, stderr=subprocess.PIPE)
        self.addCleanup(p.stdin.close)
        self.addCleanup(p.stderr.close)
        p.wait()
        self.assertEqual(p.stdout, None)

    def test_stderr_none(self):
        # .stderr is None when not redirected
        p = subprocess.Popen([sys.executable, "-c", 'print "banana"'],
                         stdin=subprocess.PIPE, stdout=subprocess.PIPE)
        self.addCleanup(p.stdout.close)
        self.addCleanup(p.stdin.close)
        p.wait()
        self.assertEqual(p.stderr, None)

    def test_executable_with_cwd(self):
        python_dir = os.path.dirname(os.path.realpath(sys.executable))
        p = subprocess.Popen(["somethingyoudonthave", "-c",
                              "import sys; sys.exit(47)"],
                             executable=sys.executable, cwd=python_dir)
        p.wait()
        self.assertEqual(p.returncode, 47)

    @unittest.skipIf(sysconfig.is_python_build(),
                     "need an installed Python. See #7774")
    def test_executable_without_cwd(self):
        # For a normal installation, it should work without 'cwd'
        # argument.  For test runs in the build directory, see #7774.
        p = subprocess.Popen(["somethingyoudonthave", "-c",
                              "import sys; sys.exit(47)"],
                             executable=sys.executable)
        p.wait()
        self.assertEqual(p.returncode, 47)

    def test_stdin_pipe(self):
        # stdin redirection
        p = subprocess.Popen([sys.executable, "-c",
                         'import sys; sys.exit(sys.stdin.read() == "pear")'],
                        stdin=subprocess.PIPE)
        p.stdin.write("pear")
        p.stdin.close()
        p.wait()
        self.assertEqual(p.returncode, 1)

    def test_stdin_filedes(self):
        # stdin is set to open file descriptor
        tf = tempfile.TemporaryFile()
        d = tf.fileno()
        os.write(d, "pear")
        os.lseek(d, 0, 0)
        p = subprocess.Popen([sys.executable, "-c",
                         'import sys; sys.exit(sys.stdin.read() == "pear")'],
                         stdin=d)
        p.wait()
        self.assertEqual(p.returncode, 1)

    def test_stdin_fileobj(self):
        # stdin is set to open file object
        tf = tempfile.TemporaryFile()
        tf.write("pear")
        tf.seek(0)
        p = subprocess.Popen([sys.executable, "-c",
                         'import sys; sys.exit(sys.stdin.read() == "pear")'],
                         stdin=tf)
        p.wait()
        self.assertEqual(p.returncode, 1)

    def test_stdout_pipe(self):
        # stdout redirection
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys; sys.stdout.write("orange")'],
                         stdout=subprocess.PIPE)
        self.addCleanup(p.stdout.close)
        self.assertEqual(p.stdout.read(), "orange")

    def test_stdout_filedes(self):
        # stdout is set to open file descriptor
        tf = tempfile.TemporaryFile()
        d = tf.fileno()
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys; sys.stdout.write("orange")'],
                         stdout=d)
        p.wait()
        os.lseek(d, 0, 0)
        self.assertEqual(os.read(d, 1024), "orange")

    def test_stdout_fileobj(self):
        # stdout is set to open file object
        tf = tempfile.TemporaryFile()
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys; sys.stdout.write("orange")'],
                         stdout=tf)
        p.wait()
        tf.seek(0)
        self.assertEqual(tf.read(), "orange")

    def test_stderr_pipe(self):
        # stderr redirection
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys; sys.stderr.write("strawberry")'],
                         stderr=subprocess.PIPE)
        self.addCleanup(p.stderr.close)
        self.assertStderrEqual(p.stderr.read(), "strawberry")

    def test_stderr_filedes(self):
        # stderr is set to open file descriptor
        tf = tempfile.TemporaryFile()
        d = tf.fileno()
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys; sys.stderr.write("strawberry")'],
                         stderr=d)
        p.wait()
        os.lseek(d, 0, 0)
        self.assertStderrEqual(os.read(d, 1024), "strawberry")

    def test_stderr_fileobj(self):
        # stderr is set to open file object
        tf = tempfile.TemporaryFile()
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys; sys.stderr.write("strawberry")'],
                         stderr=tf)
        p.wait()
        tf.seek(0)
        self.assertStderrEqual(tf.read(), "strawberry")

    def test_stdout_stderr_pipe(self):
        # capture stdout and stderr to the same pipe
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys;'
                          'sys.stdout.write("apple");'
                          'sys.stdout.flush();'
                          'sys.stderr.write("orange")'],
                         stdout=subprocess.PIPE,
                         stderr=subprocess.STDOUT)
        self.addCleanup(p.stdout.close)
        self.assertStderrEqual(p.stdout.read(), "appleorange")

    def test_stdout_stderr_file(self):
        # capture stdout and stderr to the same open file
        tf = tempfile.TemporaryFile()
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys;'
                          'sys.stdout.write("apple");'
                          'sys.stdout.flush();'
                          'sys.stderr.write("orange")'],
                         stdout=tf,
                         stderr=tf)
        p.wait()
        tf.seek(0)
        self.assertStderrEqual(tf.read(), "appleorange")

    def test_stdout_filedes_of_stdout(self):
        # stdout is set to 1 (#1531862).
        cmd = r"import sys, os; sys.exit(os.write(sys.stdout.fileno(), '.\n'))"
        rc = subprocess.call([sys.executable, "-c", cmd], stdout=1)
        self.assertEqual(rc, 2)

    def test_cwd(self):
        tmpdir = tempfile.gettempdir()
        # We cannot use os.path.realpath to canonicalize the path,
        # since it doesn't expand Tru64 {memb} strings. See bug 1063571.
        cwd = os.getcwd()
        os.chdir(tmpdir)
        tmpdir = os.getcwd()
        os.chdir(cwd)
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys,os;'
                          'sys.stdout.write(os.getcwd())'],
                         stdout=subprocess.PIPE,
                         cwd=tmpdir)
        self.addCleanup(p.stdout.close)
        normcase = os.path.normcase
        self.assertEqual(normcase(p.stdout.read()), normcase(tmpdir))

    def test_env(self):
        newenv = os.environ.copy()
        newenv["FRUIT"] = "orange"
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys,os;'
                          'sys.stdout.write(os.getenv("FRUIT"))'],
                         stdout=subprocess.PIPE,
                         env=newenv)
        self.addCleanup(p.stdout.close)
        self.assertEqual(p.stdout.read(), "orange")

    def test_communicate_stdin(self):
        p = subprocess.Popen([sys.executable, "-c",
                              'import sys;'
                              'sys.exit(sys.stdin.read() == "pear")'],
                             stdin=subprocess.PIPE)
        p.communicate("pear")
        self.assertEqual(p.returncode, 1)

    def test_communicate_stdout(self):
        p = subprocess.Popen([sys.executable, "-c",
                              'import sys; sys.stdout.write("pineapple")'],
                             stdout=subprocess.PIPE)
        (stdout, stderr) = p.communicate()
        self.assertEqual(stdout, "pineapple")
        self.assertEqual(stderr, None)

    def test_communicate_stderr(self):
        p = subprocess.Popen([sys.executable, "-c",
                              'import sys; sys.stderr.write("pineapple")'],
                             stderr=subprocess.PIPE)
        (stdout, stderr) = p.communicate()
        self.assertEqual(stdout, None)
        self.assertStderrEqual(stderr, "pineapple")

    def test_communicate(self):
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys,os;'
                          'sys.stderr.write("pineapple");'
                          'sys.stdout.write(sys.stdin.read())'],
                         stdin=subprocess.PIPE,
                         stdout=subprocess.PIPE,
                         stderr=subprocess.PIPE)
        self.addCleanup(p.stdout.close)
        self.addCleanup(p.stderr.close)
        self.addCleanup(p.stdin.close)
        (stdout, stderr) = p.communicate("banana")
        self.assertEqual(stdout, "banana")
        self.assertStderrEqual(stderr, "pineapple")

    # This test is Linux specific for simplicity to at least have
    # some coverage.  It is not a platform specific bug.
    @unittest.skipUnless(os.path.isdir('/proc/%d/fd' % os.getpid()),
                         "Linux specific")
    # Test for the fd leak reported in http://bugs.python.org/issue2791.
    def test_communicate_pipe_fd_leak(self):
        fd_directory = '/proc/%d/fd' % os.getpid()
        num_fds_before_popen = len(os.listdir(fd_directory))
        p = subprocess.Popen([sys.executable, "-c", "print()"],
                             stdout=subprocess.PIPE)
        p.communicate()
        num_fds_after_communicate = len(os.listdir(fd_directory))
        del p
        num_fds_after_destruction = len(os.listdir(fd_directory))
        self.assertEqual(num_fds_before_popen, num_fds_after_destruction)
        self.assertEqual(num_fds_before_popen, num_fds_after_communicate)

    def test_communicate_returns(self):
        # communicate() should return None if no redirection is active
        p = subprocess.Popen([sys.executable, "-c",
                              "import sys; sys.exit(47)"])
        (stdout, stderr) = p.communicate()
        self.assertEqual(stdout, None)
        self.assertEqual(stderr, None)

    def test_communicate_pipe_buf(self):
        # communicate() with writes larger than pipe_buf
        # This test will probably deadlock rather than fail, if
        # communicate() does not work properly.
        x, y = os.pipe()
        if mswindows:
            pipe_buf = 512
        else:
            pipe_buf = os.fpathconf(x, "PC_PIPE_BUF")
        os.close(x)
        os.close(y)
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys,os;'
                          'sys.stdout.write(sys.stdin.read(47));'
                          'sys.stderr.write("xyz"*%d);'
                          'sys.stdout.write(sys.stdin.read())' % pipe_buf],
                         stdin=subprocess.PIPE,
                         stdout=subprocess.PIPE,
                         stderr=subprocess.PIPE)
        self.addCleanup(p.stdout.close)
        self.addCleanup(p.stderr.close)
        self.addCleanup(p.stdin.close)
        string_to_write = "abc"*pipe_buf
        (stdout, stderr) = p.communicate(string_to_write)
        self.assertEqual(stdout, string_to_write)

    def test_writes_before_communicate(self):
        # stdin.write before communicate()
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys,os;'
                          'sys.stdout.write(sys.stdin.read())'],
                         stdin=subprocess.PIPE,
                         stdout=subprocess.PIPE,
                         stderr=subprocess.PIPE)
        self.addCleanup(p.stdout.close)
        self.addCleanup(p.stderr.close)
        self.addCleanup(p.stdin.close)
        p.stdin.write("banana")
        (stdout, stderr) = p.communicate("split")
        self.assertEqual(stdout, "bananasplit")
        self.assertStderrEqual(stderr, "")

    def test_universal_newlines(self):
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys,os;' + SETBINARY +
                          'sys.stdout.write("line1\\n");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("line2\\r");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("line3\\r\\n");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("line4\\r");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("\\nline5");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("\\nline6");'],
                         stdout=subprocess.PIPE,
                         universal_newlines=1)
        self.addCleanup(p.stdout.close)
        stdout = p.stdout.read()
        if hasattr(file, 'newlines'):
            # Interpreter with universal newline support
            self.assertEqual(stdout,
                             "line1\nline2\nline3\nline4\nline5\nline6")
        else:
            # Interpreter without universal newline support
            self.assertEqual(stdout,
                             "line1\nline2\rline3\r\nline4\r\nline5\nline6")

    def test_universal_newlines_communicate(self):
        # universal newlines through communicate()
        p = subprocess.Popen([sys.executable, "-c",
                          'import sys,os;' + SETBINARY +
                          'sys.stdout.write("line1\\n");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("line2\\r");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("line3\\r\\n");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("line4\\r");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("\\nline5");'
                          'sys.stdout.flush();'
                          'sys.stdout.write("\\nline6");'],
                         stdout=subprocess.PIPE, stderr=subprocess.PIPE,
                         universal_newlines=1)
        self.addCleanup(p.stdout.close)
        self.addCleanup(p.stderr.close)
        (stdout, stderr) = p.communicate()
        if hasattr(file, 'newlines'):
            # Interpreter with universal newline support
            self.assertEqual(stdout,
                             "line1\nline2\nline3\nline4\nline5\nline6")
        else:
            # Interpreter without universal newline support
            self.assertEqual(stdout,
                             "line1\nline2\rline3\r\nline4\r\nline5\nline6")

    def test_no_leaking(self):
        # Make sure we leak no resources
        if not mswindows:
            max_handles = 1026 # too much for most UNIX systems
        else:
            max_handles = 2050 # too much for (at least some) Windows setups
        handles = []
        try:
            for i in range(max_handles):
                try:
                    handles.append(os.open(test_support.TESTFN,
                                           os.O_WRONLY | os.O_CREAT))
                except OSError as e:
                    if e.errno != errno.EMFILE:
                        raise
                    break
            else:
                self.skipTest("failed to reach the file descriptor limit "
                    "(tried %d)" % max_handles)
            # Close a couple of them (should be enough for a subprocess)
            for i in range(10):
                os.close(handles.pop())
            # Loop creating some subprocesses. If one of them leaks some fds,
            # the next loop iteration will fail by reaching the max fd limit.
            for i in range(15):
                p = subprocess.Popen([sys.executable, "-c",
                                      "import sys;"
                                      "sys.stdout.write(sys.stdin.read())"],
                                     stdin=subprocess.PIPE,
                                     stdout=subprocess.PIPE,
                                     stderr=subprocess.PIPE)
                data = p.communicate(b"lime")[0]
                self.assertEqual(data, b"lime")
        finally:
            for h in handles:
                os.close(h)

    def test_list2cmdline(self):
        self.assertEqual(subprocess.list2cmdline(['a b c', 'd', 'e']),
                         '"a b c" d e')
        self.assertEqual(subprocess.list2cmdline(['ab"c', '\\', 'd']),
                         'ab\\"c \\ d')
        self.assertEqual(subprocess.list2cmdline(['ab"c', ' \\', 'd']),
                         'ab\\"c " \\\\" d')
        self.assertEqual(subprocess.list2cmdline(['a\\\\\\b', 'de fg', 'h']),
                         'a\\\\\\b "de fg" h')
        self.assertEqual(subprocess.list2cmdline(['a\\"b', 'c', 'd']),
                         'a\\\\\\"b c d')
        self.assertEqual(subprocess.list2cmdline(['a\\\\b c', 'd', 'e']),
                         '"a\\\\b c" d e')
        self.assertEqual(subprocess.list2cmdline(['a\\\\b\\ c', 'd', 'e']),
                         '"a\\\\b\\ c" d e')
        self.assertEqual(subprocess.list2cmdline(['ab', '']),
                         'ab ""')


    def test_poll(self):
        p = subprocess.Popen([sys.executable,
                          "-c", "import time; time.sleep(1)"])
        count = 0
        while p.poll() is None:
            time.sleep(0.1)
            count += 1
        # We expect that the poll loop probably went around about 10 times,
        # but, based on system scheduling we can't control, it's possible
        # poll() never returned None.  It "should be" very rare that it
        # didn't go around at least twice.
        self.assertGreaterEqual(count, 2)
        # Subsequent invocations should just return the returncode
        self.assertEqual(p.poll(), 0)


    def test_wait(self):
        p = subprocess.Popen([sys.executable,
                          "-c", "import time; time.sleep(2)"])
        self.assertEqual(p.wait(), 0)
        # Subsequent invocations should just return the returncode
        self.assertEqual(p.wait(), 0)


    def test_invalid_bufsize(self):
        # an invalid type of the bufsize argument should raise
        # TypeError.
        with self.assertRaises(TypeError):
            subprocess.Popen([sys.executable, "-c", "pass"], "orange")

    def test_leaking_fds_on_error(self):
        # see bug #5179: Popen leaks file descriptors to PIPEs if
        # the child fails to execute; this will eventually exhaust
        # the maximum number of open fds. 1024 seems a very common
        # value for that limit, but Windows has 2048, so we loop
        # 1024 times (each call leaked two fds).
        for i in range(1024):
            # Windows raises IOError.  Others raise OSError.
            with self.assertRaises(EnvironmentError) as c:
                subprocess.Popen(['nonexisting_i_hope'],
                                 stdout=subprocess.PIPE,
                                 stderr=subprocess.PIPE)
            # ignore errors that indicate the command was not found
            if c.exception.errno not in (errno.ENOENT, errno.EACCES):
                raise c.exception

    def test_handles_closed_on_exception(self):
        # If CreateProcess exits with an error, ensure the
        # duplicate output handles are released
        ifhandle, ifname = mkstemp()
        ofhandle, ofname = mkstemp()
        efhandle, efname = mkstemp()
        try:
            subprocess.Popen (["*"], stdin=ifhandle, stdout=ofhandle,
              stderr=efhandle)
        except OSError:
            os.close(ifhandle)
            os.remove(ifname)
            os.close(ofhandle)
            os.remove(ofname)
            os.close(efhandle)
            os.remove(efname)
        self.assertFalse(os.path.exists(ifname))
        self.assertFalse(os.path.exists(ofname))
        self.assertFalse(os.path.exists(efname))

    def test_communicate_epipe(self):
        # Issue 10963: communicate() should hide EPIPE
        p = subprocess.Popen([sys.executable, "-c", 'pass'],
                             stdin=subprocess.PIPE,
                             stdout=subprocess.PIPE,
                             stderr=subprocess.PIPE)
        self.addCleanup(p.stdout.close)
        self.addCleanup(p.stderr.close)
        self.addCleanup(p.stdin.close)
        p.communicate("x" * 2**20)

    def test_communicate_epipe_only_stdin(self):
        # Issue 10963: communicate() should hide EPIPE
        p = subprocess.Popen([sys.executable, "-c", 'pass'],
                             stdin=subprocess.PIPE)
        self.addCleanup(p.stdin.close)
        time.sleep(2)
        p.communicate("x" * 2**20)

# context manager
class _SuppressCoreFiles(object):
    """Try to prevent core files from being created."""
    old_limit = None

    def __enter__(self):
        """Try to save previous ulimit, then set it to (0, 0)."""
        try:
            import resource
            self.old_limit = resource.getrlimit(resource.RLIMIT_CORE)
            resource.setrlimit(resource.RLIMIT_CORE, (0, 0))
        except (ImportError, ValueError, resource.error):
            pass

        if sys.platform == 'darwin':
            # Check if the 'Crash Reporter' on OSX was configured
            # in 'Developer' mode and warn that it will get triggered
            # when it is.
            #
            # This assumes that this context manager is used in tests
            # that might trigger the next manager.
            value = subprocess.Popen(['/usr/bin/defaults', 'read',
                    'com.apple.CrashReporter', 'DialogType'],
                    stdout=subprocess.PIPE).communicate()[0]
            if value.strip() == b'developer':
                print "this tests triggers the Crash Reporter, that is intentional"
                sys.stdout.flush()

    def __exit__(self, *args):
        """Return core file behavior to default."""
        if self.old_limit is None:
            return
        try:
            import resource
            resource.setrlimit(resource.RLIMIT_CORE, self.old_limit)
        except (ImportError, ValueError, resource.error):
            pass


@unittest.skipIf(mswindows, "POSIX specific tests")
class POSIXProcessTestCase(BaseTestCase):

    def test_exceptions(self):
        # caught & re-raised exceptions
        with self.assertRaises(OSError) as c:
            p = subprocess.Popen([sys.executable, "-c", ""],
                                 cwd="/this/path/does/not/exist")
        # The attribute child_traceback should contain "os.chdir" somewhere.
        self.assertIn("os.chdir", c.exception.child_traceback)

    def test_run_abort(self):
        # returncode handles signal termination
        with _SuppressCoreFiles():
            p = subprocess.Popen([sys.executable, "-c",
                                  "import os; os.abort()"])
            p.wait()
        self.assertEqual(-p.returncode, signal.SIGABRT)

    def test_preexec(self):
        # preexec function
        p = subprocess.Popen([sys.executable, "-c",
                              "import sys, os;"
                              "sys.stdout.write(os.getenv('FRUIT'))"],
                             stdout=subprocess.PIPE,
                             preexec_fn=lambda: os.putenv("FRUIT", "apple"))
        self.addCleanup(p.stdout.close)
        self.assertEqual(p.stdout.read(), "apple")

    def test_args_string(self):
        # args is a string
        f, fname = mkstemp()
        os.write(f, "#!/bin/sh\n")
        os.write(f, "exec '%s' -c 'import sys; sys.exit(47)'\n" %
                    sys.executable)
        os.close(f)
        os.chmod(fname, 0o700)
        p = subprocess.Popen(fname)
        p.wait()
        os.remove(fname)
        self.assertEqual(p.returncode, 47)

    def test_invalid_args(self):
        # invalid arguments should raise ValueError
        self.assertRaises(ValueError, subprocess.call,
                          [sys.executable, "-c",
                           "import sys; sys.exit(47)"],
                          startupinfo=47)
        self.assertRaises(ValueError, subprocess.call,
                          [sys.executable, "-c",
                           "import sys; sys.exit(47)"],
                          creationflags=47)

    def test_shell_sequence(self):
        # Run command through the shell (sequence)
        newenv = os.environ.copy()
        newenv["FRUIT"] = "apple"
        p = subprocess.Popen(["echo $FRUIT"], shell=1,
                             stdout=subprocess.PIPE,
                             env=newenv)
        self.addCleanup(p.stdout.close)
        self.assertEqual(p.stdout.read().strip(), "apple")

    def test_shell_string(self):
        # Run command through the shell (string)
        newenv = os.environ.copy()
        newenv["FRUIT"] = "apple"
        p = subprocess.Popen("echo $FRUIT", shell=1,
                             stdout=subprocess.PIPE,
                             env=newenv)
        self.addCleanup(p.stdout.close)
        self.assertEqual(p.stdout.read().strip(), "apple")

    def test_call_string(self):
        # call() function with string argument on UNIX
        f, fname = mkstemp()
        os.write(f, "#!/bin/sh\n")
        os.write(f, "exec '%s' -c 'import sys; sys.exit(47)'\n" %
                    sys.executable)
        os.close(f)
        os.chmod(fname, 0700)
        rc = subprocess.call(fname)
        os.remove(fname)
        self.assertEqual(rc, 47)

    def test_specific_shell(self):
        # Issue #9265: Incorrect name passed as arg[0].
        shells = []
        for prefix in ['/bin', '/usr/bin/', '/usr/local/bin']:
            for name in ['bash', 'ksh']:
                sh = os.path.join(prefix, name)
                if os.path.isfile(sh):
                    shells.append(sh)
        if not shells: # Will probably work for any shell but csh.
            self.skipTest("bash or ksh required for this test")
        sh = '/bin/sh'
        if os.path.isfile(sh) and not os.path.islink(sh):
            # Test will fail if /bin/sh is a symlink to csh.
            shells.append(sh)
        for sh in shells:
            p = subprocess.Popen("echo $0", executable=sh, shell=True,
                                 stdout=subprocess.PIPE)
            self.addCleanup(p.stdout.close)
            self.assertEqual(p.stdout.read().strip(), sh)

    def _kill_process(self, method, *args):
        # Do not inherit file handles from the parent.
        # It should fix failures on some platforms.
        p = subprocess.Popen([sys.executable, "-c", """if 1:
                             import sys, time
                             sys.stdout.write('x\\n')
                             sys.stdout.flush()
                             time.sleep(30)
                             """],
                             close_fds=True,
                             stdin=subprocess.PIPE,
                             stdout=subprocess.PIPE,
                             stderr=subprocess.PIPE)
        # Wait for the interpreter to be completely initialized before
        # sending any signal.
        p.stdout.read(1)
        getattr(p, method)(*args)
        return p

    def test_send_signal(self):
        p = self._kill_process('send_signal', signal.SIGINT)
        _, stderr = p.communicate()
        self.assertIn('KeyboardInterrupt', stderr)
        self.assertNotEqual(p.wait(), 0)

    def test_kill(self):
        p = self._kill_process('kill')
        _, stderr = p.communicate()
        self.assertStderrEqual(stderr, '')
        self.assertEqual(p.wait(), -signal.SIGKILL)

    def test_terminate(self):
        p = self._kill_process('terminate')
        _, stderr = p.communicate()
        self.assertStderrEqual(stderr, '')
        self.assertEqual(p.wait(), -signal.SIGTERM)

    def check_close_std_fds(self, fds):
        # Issue #9905: test that subprocess pipes still work properly with
        # some standard fds closed
        stdin = 0
        newfds = []
        for a in fds:
            b = os.dup(a)
            newfds.append(b)
            if a == 0:
                stdin = b
        try:
            for fd in fds:
                os.close(fd)
            out, err = subprocess.Popen([sys.executable, "-c",
                              'import sys;'
                              'sys.stdout.write("apple");'
                              'sys.stdout.flush();'
                              'sys.stderr.write("orange")'],
                       stdin=stdin,
                       stdout=subprocess.PIPE,
                       stderr=subprocess.PIPE).communicate()
            err = test_support.strip_python_stderr(err)
            self.assertEqual((out, err), (b'apple', b'orange'))
        finally:
            for b, a in zip(newfds, fds):
                os.dup2(b, a)
            for b in newfds:
                os.close(b)

    def test_close_fd_0(self):
        self.check_close_std_fds([0])

    def test_close_fd_1(self):
        self.check_close_std_fds([1])

    def test_close_fd_2(self):
        self.check_close_std_fds([2])

    def test_close_fds_0_1(self):
        self.check_close_std_fds([0, 1])

    def test_close_fds_0_2(self):
        self.check_close_std_fds([0, 2])

    def test_close_fds_1_2(self):
        self.check_close_std_fds([1, 2])

    def test_close_fds_0_1_2(self):
        # Issue #10806: test that subprocess pipes still work properly with
        # all standard fds closed.
        self.check_close_std_fds([0, 1, 2])

    def test_wait_when_sigchild_ignored(self):
        # NOTE: sigchild_ignore.py may not be an effective test on all OSes.
        sigchild_ignore = test_support.findfile("sigchild_ignore.py",
                                                subdir="subprocessdata")
        p = subprocess.Popen([sys.executable, sigchild_ignore],
                             stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        stdout, stderr = p.communicate()
        self.assertEqual(0, p.returncode, "sigchild_ignore.py exited"
                         " non-zero with this error:\n%s" % stderr)


@unittest.skipUnless(mswindows, "Windows specific tests")
class Win32ProcessTestCase(BaseTestCase):

    def test_startupinfo(self):
        # startupinfo argument
        # We uses hardcoded constants, because we do not want to
        # depend on win32all.
        STARTF_USESHOWWINDOW = 1
        SW_MAXIMIZE = 3
        startupinfo = subprocess.STARTUPINFO()
        startupinfo.dwFlags = STARTF_USESHOWWINDOW
        startupinfo.wShowWindow = SW_MAXIMIZE
        # Since Python is a console process, it won't be affected
        # by wShowWindow, but the argument should be silently
        # ignored
        subprocess.call([sys.executable, "-c", "import sys; sys.exit(0)"],
                        startupinfo=startupinfo)

    def test_creationflags(self):
        # creationflags argument
        CREATE_NEW_CONSOLE = 16
        sys.stderr.write("    a DOS box should flash briefly ...\n")
        subprocess.call(sys.executable +
                        ' -c "import time; time.sleep(0.25)"',
                        creationflags=CREATE_NEW_CONSOLE)

    def test_invalid_args(self):
        # invalid arguments should raise ValueError
        self.assertRaises(ValueError, subprocess.call,
                          [sys.executable, "-c",
                           "import sys; sys.exit(47)"],
                          preexec_fn=lambda: 1)
        self.assertRaises(ValueError, subprocess.call,
                          [sys.executable, "-c",
                           "import sys; sys.exit(47)"],
                          stdout=subprocess.PIPE,
                          close_fds=True)

    def test_close_fds(self):
        # close file descriptors
        rc = subprocess.call([sys.executable, "-c",
                              "import sys; sys.exit(47)"],
                              close_fds=True)
        self.assertEqual(rc, 47)

    def test_shell_sequence(self):
        # Run command through the shell (sequence)
        newenv = os.environ.copy()
        newenv["FRUIT"] = "physalis"
        p = subprocess.Popen(["set"], shell=1,
                             stdout=subprocess.PIPE,
                             env=newenv)
        self.addCleanup(p.stdout.close)
        self.assertIn("physalis", p.stdout.read())

    def test_shell_string(self):
        # Run command through the shell (string)
        newenv = os.environ.copy()
        newenv["FRUIT"] = "physalis"
        p = subprocess.Popen("set", shell=1,
                             stdout=subprocess.PIPE,
                             env=newenv)
        self.addCleanup(p.stdout.close)
        self.assertIn("physalis", p.stdout.read())

    def test_call_string(self):
        # call() function with string argument on Windows
        rc = subprocess.call(sys.executable +
                             ' -c "import sys; sys.exit(47)"')
        self.assertEqual(rc, 47)

    def _kill_process(self, method, *args):
        # Some win32 buildbot raises EOFError if stdin is inherited
        p = subprocess.Popen([sys.executable, "-c", """if 1:
                             import sys, time
                             sys.stdout.write('x\\n')
                             sys.stdout.flush()
                             time.sleep(30)
                             """],
                             stdin=subprocess.PIPE,
                             stdout=subprocess.PIPE,
                             stderr=subprocess.PIPE)
        self.addCleanup(p.stdout.close)
        self.addCleanup(p.stderr.close)
        self.addCleanup(p.stdin.close)
        # Wait for the interpreter to be completely initialized before
        # sending any signal.
        p.stdout.read(1)
        getattr(p, method)(*args)
        _, stderr = p.communicate()
        self.assertStderrEqual(stderr, '')
        returncode = p.wait()
        self.assertNotEqual(returncode, 0)

    def test_send_signal(self):
        self._kill_process('send_signal', signal.SIGTERM)

    def test_kill(self):
        self._kill_process('kill')

    def test_terminate(self):
        self._kill_process('terminate')


@unittest.skipUnless(getattr(subprocess, '_has_poll', False),
                     "poll system call not supported")
class ProcessTestCaseNoPoll(ProcessTestCase):
    def setUp(self):
        subprocess._has_poll = False
        ProcessTestCase.setUp(self)

    def tearDown(self):
        subprocess._has_poll = True
        ProcessTestCase.tearDown(self)


class HelperFunctionTests(unittest.TestCase):
    @unittest.skipIf(mswindows, "errno and EINTR make no sense on windows")
    def test_eintr_retry_call(self):
        record_calls = []
        def fake_os_func(*args):
            record_calls.append(args)
            if len(record_calls) == 2:
                raise OSError(errno.EINTR, "fake interrupted system call")
            return tuple(reversed(args))

        self.assertEqual((999, 256),
                         subprocess._eintr_retry_call(fake_os_func, 256, 999))
        self.assertEqual([(256, 999)], record_calls)
        # This time there will be an EINTR so it will loop once.
        self.assertEqual((666,),
                         subprocess._eintr_retry_call(fake_os_func, 666))
        self.assertEqual([(256, 999), (666,), (666,)], record_calls)


@unittest.skipUnless(mswindows, "mswindows only")
class CommandsWithSpaces (BaseTestCase):

    def setUp(self):
        super(CommandsWithSpaces, self).setUp()
        f, fname = mkstemp(".py", "te st")
        self.fname = fname.lower ()
        os.write(f, b"import sys;"
                    b"sys.stdout.write('%d %s' % (len(sys.argv), [a.lower () for a in sys.argv]))"
        )
        os.close(f)

    def tearDown(self):
        os.remove(self.fname)
        super(CommandsWithSpaces, self).tearDown()

    def with_spaces(self, *args, **kwargs):
        kwargs['stdout'] = subprocess.PIPE
        p = subprocess.Popen(*args, **kwargs)
        self.addCleanup(p.stdout.close)
        self.assertEqual(
          p.stdout.read ().decode("mbcs"),
          "2 [%r, 'ab cd']" % self.fname
        )

    def test_shell_string_with_spaces(self):
        # call() function with string argument with spaces on Windows
        self.with_spaces('"%s" "%s" "%s"' % (sys.executable, self.fname,
                                             "ab cd"), shell=1)

    def test_shell_sequence_with_spaces(self):
        # call() function with sequence argument with spaces on Windows
        self.with_spaces([sys.executable, self.fname, "ab cd"], shell=1)

    def test_noshell_string_with_spaces(self):
        # call() function with string argument with spaces on Windows
        self.with_spaces('"%s" "%s" "%s"' % (sys.executable, self.fname,
                             "ab cd"))

    def test_noshell_sequence_with_spaces(self):
        # call() function with sequence argument with spaces on Windows
        self.with_spaces([sys.executable, self.fname, "ab cd"])

def test_main():
    unit_tests = (ProcessTestCase,
                  POSIXProcessTestCase,
                  Win32ProcessTestCase,
                  ProcessTestCaseNoPoll,
                  HelperFunctionTests,
                  CommandsWithSpaces)

    test_support.run_unittest(*unit_tests)
    test_support.reap_children()

if __name__ == "__main__":
    test_main()

From tracker at bugs.pypy.org  Mon Jan 30 11:09:35 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 30 Jan 2012 10:09:35 +0000
Subject: [pypy-issue] [issue1030] cpython test_subprocess.py fails on Windows
In-Reply-To: <1327889857.34.0.498001259809.issue1030@bugs.pypy.org>
Message-ID: <1327918175.26.0.635304444339.issue1030@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

http://buildbot.pypy.org/summary?builder=pypy-c-jit-win-x86-32

Known issue.  If this didn't fail translation (right now, because of
MemoryError), it would show the two failures in test_subprocess.  There is more
generally a number of cpython tests that fail on Windows (but less than at the
previous release), and we didn't investigate it all.  If you want to help, you
can try to figure out why we get these failures.

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1030>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 30 11:14:35 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 30 Jan 2012 10:14:35 +0000
Subject: [pypy-issue] [issue1029] cpython test_subprocess.py fails
In-Reply-To: <1327889370.62.0.40349489632.issue1029@bugs.pypy.org>
Message-ID: <1327918475.97.0.545032565862.issue1029@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Maybe you can try to look at the 'test_executable_without_cwd' failure more in
detail.  We cannot reproduce this one, so it's the only way to help: it works
for us on various other linux distributions, as shown by the fact that
pypy-c-jit-51842-457e2166648c's two testing columns are both green.

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1029>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 30 22:39:26 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 30 Jan 2012 21:39:26 +0000
Subject: [pypy-issue] [issue1031] Speed of a tiny arithmetic program
In-Reply-To: <1327959566.62.0.373732238148.issue1031@bugs.pypy.org>
Message-ID: <1327959566.62.0.373732238148.issue1031@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

http://paste.pocoo.org/show/543141/

This program is not much faster with pypy.  Even if I get rid of the obvious
inefficiencies using divmod(..,2) and replace 2**r*d with d << r, the program
ends up only twice as fast.  Why?

----------
messages: 3845
nosy: arigo, pypy-issue
priority: performance bug
status: unread
title: Speed of a tiny arithmetic program

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1031>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 31 20:02:06 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Tue, 31 Jan 2012 19:02:06 +0000
Subject: [pypy-issue] [issue614] Packaging PyPy: installation path for
	PyPy's libraries
In-Reply-To: <1293069242.66.0.789471767917.issue614@>
Message-ID: <1328036526.93.0.352038123844.issue614@bugs.pypy.org>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

FWIW, I just changed my rpms to follow antocuni's second proposal in msg2034, 
removing this patch.  [See https://bugzilla.redhat.com/show_bug.cgi?id=742641#c2 
for more details].

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue614>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 31 20:45:39 2012
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Tue, 31 Jan 2012 19:45:39 +0000
Subject: [pypy-issue] [issue614] Packaging PyPy: installation path for
	PyPy's libraries
In-Reply-To: <1293069242.66.0.789471767917.issue614@>
Message-ID: <1328039139.36.0.23217654038.issue614@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

I'm afraid that approach won't work for us in Debian we want to maintain
compatibility with Debian's cpython install layout (and its extra
--install-layout option)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue614>
________________________________________